Manager: “Hey journeyman can you fix this address on this page so that it knows to take a system configuration?”

Journeyman:  “Sure, give me a second for an estimate.”

You find the code:

public class AddressService {

      public String getFormattedAddress(Datasource ds, int yourFormat) {
           if (yourFormat == 1) { /* do this format */ }
           else { /* do this format */ }
           return addressString;

         }
 }

Now go in and track down the code to change .   Hmm interesting function called getFormattedAddress().  Let’s see, before I touch it do a code search in Eclipse : used in 147 places!!!!!  Ugh . . .

You shan’t dare change the function call in ALL those places, nightmare, just for one of the calls.

So here’s one way to do avoid this messy situation:

1. Add a new property, yourConfig, with getters and setters.
2. Override the function getFormattedAddress so that it takes your new parameter
3. Set that parameter in the overriding function.
4. Modify the original function to check the parameter, using a default if the value is empty.
5. Call the original function form the overriding function
6. Don’t forget to reset the default value!

Something like this:

public class AddressService {
      private String yourConfig = "";

      public String getFormattedAddress(Datasource ds, int yourFormat) {
           String localConfig =
                   (getYourConfig == "") ? "default" : getYourConfig();
           setYourConfig("");
           if (yourFormat == 1) { /* do this format +localConfig */ }
           else { /* do this format + localConfig */ }
           return addressString;

         }
     public String getFormattedAddress(Datasource ds, int yourFormat, String inYourConfig) {
           setYourConfig(inYourConfig);
           return getFormattedAddress(ds,yourFormat);
     }

    public String setYourConfig(String inStr) {this.yourConfig = inStr;}
    public void getYourConfig() {return this.yourConfig;}
 }

Now you can call the function from either its original state, or, pass in a config.

We were trying to debug some Hibernate rich objects we had converted from hbm files to annotations, and the objects were blowing up.  One of our more expertish developers with some Hibernate experience insisted that default fetching was lazy.  We decided to accept that as the word and left certain objects with their hbms attributing their failure to annotations not doing something mysterious correctly.

Well, I started to write some unit and integration tests on one of the newer annotated objects and was stubbing the data out with HSQL.  I noticed that there were errors in running the tests of the nature of  failure to hydrate objects.  It smelled like eager fetching. 

So I made the fetching on the many-to-one relationships explicity lazy in an annotation.  I couldn’t believe it.  Searching through the documentation I found this.  Who would have thought that Hibernate and JPA have taken two different approaches!

Fetch strategies and types

In native Hibernate, many-to-one association are lazy by default.
This means that selecting a list of objects with an HQL query will not
initialize the objects at the other end of the many-to-one association.
In JPA the default fetch type is eager (i.e. non-lazy), with separate
selects. This means that any JPAQL query for an entity that has
many-to-one associations in it will result in an N+1 SELECTS problem
even if those associations are not used. To eliminate the unnecessary
queries, simply set the fetch type to LAZY using:

<font color="#000066"><i> @ManyToOne(fetch=FetchType.LAZY)
</i></font>

Then, in any JPA query the association can be eagerly fetched using left join fetch.

   FOR i IN 1 .. tokenLength
   LOOP
      SELECT SUBSTR (tokenString, i, 1) INTO tokenChar FROM DUAL;

      IF tokenChar = tokenDelimiter OR i = tokenLength
      THEN
         IF i = tokenLength
         THEN
            tokenIzed := tokenIzed || tokenChar;
         END IF;
          –> DO YOUR INTERESTING STUFF HERE
         DBMS_OUTPUT.PUT_LINE (tokenIzed);
         tokenIzed := ”;
      ELSE
         tokenIzed := tokenIzed || tokenChar;
      END IF;
   END LOOP;
END;

Anyway, one thing they wanted was batch commits . . . so I wrote this quick little piece:

It creates a temp table, populates it, and puts a DBMS_OUTPUT line for whatever number I set the commit at . . . pretty self explanatory.

CREATE   GLOBAL  TEMPORARY TABLE temp_Cursor_Count  (
testNumber Number(10)
) ON COMMIT PRESERVE ROWS;
commit;

DECLARE

curVariable Number;

cursorCount Number(10) := 0;
cursorCommit Number(10) := 1000;
cursorMod Number(10) := 1;

CURSOR tt is
select * from temp_Cursor_Count;

begin

–populate temp table
For i in 1..9999
Loop
insert into temp_Cursor_Count(testNumber) values (i);
end loop;
commit;

FOR record_tt IN tt LOOP
–INITIALIZE Cursor values
curVariable      :=record_tt.testNumber;

cursorCount := cursorCount + 1;

select MOD(cursorCount,cursorCommit) into cursorMod from dual;

if cursorMod=0 then
–Normally this is where your COMMIT would occur.
DBMS_OUTPUT.PUT_LINE(cursorCount);
end if;

END LOOP;
end;

truncate table temp_Cursor_Count;
commit;
drop table temp_Cursor_Count;
commit;

Some reasons not to use TDD if the conditions warrant are:

• More code is higher risk for bugs.  Bottom line.
• More expensive.  TDD translates into stories/function points/developer time.  I don’t care what anyone says, I still like TAD a little better to get repeatable regressive costs over time.

Use TDD if you are designing things that will benefit from it.  Don’t if it will not.

Object Design?

TDD is a design pattern, nothing more nothing less. While I have read a few books about TDD . . . I wonder, if true TDD people refuse to do up front object design.  The methodology demands refactoring; and therefore following a Fowler idea that design will emerge, TDD practitioners must let objects emerge via refactoring.  I mean, if they are TRULY doing TDD that’s what they would do.

Timeboxing is Agile’s David

Its an interesting experiment to me; I do refactors and look for patterns.  Then I pull them out if needed.  Unless I come up with an estimate, and the project deadline and my manager says “no way jsut build it quick.”  If you get on one of those projects using TDD (I was on one) a LOT of spaghetti code, with lots of test cases, gets written.  Its about as bug proof as any other design style, that is, in those conditions TDD brings no value.

I think its a failure of a lot of Agile methods . . . ignores the reality of timeboxed projects.  I have never worked on anything but; even being relatively young as my first computer class was on a Tandy PET and my first Basic program on a Vic 20.

A Use Case Where TDD would Fail – SUV Analogy

I am actually using TDD do do some PL/SQL conversion scripts right now.   I have to do it old school; and its taking time.  Sometimes I just write the conditions.  Since the scripts are throw away it we can’t store the unit tests in any sort of DB repository (but that would be great for stored procs etc.).  I ran into a bit of a problem though . . . that writing code in TDD style sometimes causes more problems, depending on what you are trying to accomplish.

Talking with a friend I came up with this real-life analogy of where TDD would fail.

TDD thinks it addresses quality but one thing it introduces is possible defects  due to itself.   You have to make a judgement call based on your input factors of time, money, and risk as to whether its worth it to use this design pattern.  For example, it would absolutely be worth it if designing space shuttle software.  And, you had an unlimited budget.

But here’s an analogy where it would fail:

Suppose you are designing an SUV for extreme conditions.  In one case, it’s a highly wet cool condition and in another, is a hot temperature condition.

The designers decide that testing of everything is very important.  So they design in a hole in the engine that let’s you test sludge buildup in one of the cylinders:  you unscrew something and get a physical look.  Basically, a test has become part of the design.

But now the cylinder head is weakened because of the test.  You have introduced a few failure conditions:  possible weakened gasket that will let in contamination and cause engine failure.

• In the wet condition this may be worth while.  Sludge buildup and moisture may be something causes buildup and there would be value to check the state of the cylinder periodically to make sure you don’t need to run a cleaning process, etc.
• But in the hot condition, the gasket could keep failing and contaminants could be introduced via the testing port.  The strategy is just follow a maintenance schedule (TAD – test after), which you would have done anyway, because everyone has to do maintenance.

It’s just a hypothetical but there are a ton of other things in our life just like this.  Vehicles are easy . . . even now they are building all kinds of testing into the vehicles as part of the design (TDD): emissions, mixture, electric etc.  The payoff is that this is very expensive to pay for, and also in increase costs due to specialized maintenance because your every day Joe or Jane auto mechanic can’t work on their own vehicle.  Do vehicles really last any longer?  I’d argue that they do not.  TDD just extended the period between maintenance’s — i.e. you paid for your time up front instead of over time.

I’m not motivated enough to throw away a methodology if it may be useful, and TDD can teach us some things, but I guess the mantra is:  “TDD: do it only if necessary.“

So I started digging through the commands and found SUBST. It associates a path with a drive letter.

Just open up a command line and type in the following syntax:


subst (virtual drive letter): (actual path)


So, for instance, say I want to mount a folder “\\atlas\shrugged” from a network drive as drive letter “q:” on my local -

subst q: \\atlas\shrugged


And a local folder as “x:” -

subst x: C:\journeyman


Disconnecting the virtual drives is simple enough, use the “/d” flag for delete:

subst x: /d


I haven’t found a ton of use cases for this yet, but it’s a nice little command line tool for any automated tasks you might think of someday.

Funny enough, when I was going through the PortableApps setup it now allows you to install to a folder — as I remember the older versions needed a drive — chuckle.

• On your machine, install jdk 1.6 and change your environment path variables to point to the 1.6 directories.
• In Eclipse, Under Windows->Preferences->Java->Installed JREs make sure jdk 1.6 is  added, and select it.
• In Eclipse, Under Windows->Preferences->Java->Build Path->Classpath Variables make sure jdk 1.6 is added for JRE_LIB and JRE_SRC.
• In Eclipse, Under Windows->Preferences->Java->Compiler set compliance level to 1.6.
• In Eclipse, Under Windows->Preferences->Ant->Runtime set classpath variables 1.6.
• Update your JBoss server/web server to use the 1.6 runtime.
• In each project, change the compiler, the classpaths, the facets, and the runtimes for your servers (as applicable) to use jdk 1.6.

Then you should be good to go.  Build using both the Eclipse and the Ant methods to test . . . remember, the Hudson build server (or any build process) uses the ant scripts so if you check in the app with broken scripts you’ve checked in a bug!

For a while recently at a place called Ingenix (United Health Group) I was a development manager dropping in Scrum and Agile practices.  I came to a few realizations:

• Many say they know how to do Agile, but they do not.  They have not experienced it, and they have read to little about it and reinterpreted what they read into their own understanding (thus learning nothing).
• The struggle at most organizations is to get the correct tooling to support doing Agile.  This can be CI servers or even the availability of freakin’ meeting rooms.  Without these basic simple things the modern practices of Agile, or any new way of doing things, will fail.  Again it ties back to the simple pattern of learning just enough to be dangerous, but not enough to really understand.

Simple as that.

This stuff is difficult too.  If you want to use Maven on a project, it can take months.  Try telling a VP you want to drop his investment in CVS to switch to Mercurial.  Sit in a scrum with scrum-inexperienced team and watch the waste of time add up.  At my first United gig the scrum master made us report to the business in non technical terms for 45 minutes each day.  We were not allowed to talk to each other as developers . . . we had to do it after, another 15-30 minutes.  Yeah . . a big WTF … One hour everyday of meetings versus the old waterfall one hour every week?  And this person was certified!  (Maybe sometime I’ll discuss the “spirit” of all this, which seems to be more dangerous than just plain ignorance of methodology.)

I am currently working a gig trying to assist a bit in adding Agile practices to their structure, but it has been near impossible.  People get all pissy if you try to “coach” them as to simple meanings of things.  And then, they say the processes fail.

Examples:

• One developer started listing things like “gather requirements for migration” and “code daos” as spikes.  Spikes are proof of concepts, not actual tasks.  Spikes are like “see if Mercurial will offer something that CVS can’t.”  Etc.  I got my head bit off.
• TDD.  Oh how I hate it for fuzzy logic workflow/user gesture driven software.  But you ask any of the developers around my current place and they are “experts” on TDD.  “Yeah we’re writing unit tests.”  That’s not TDD!  If they have not done it for real, just read a one-up wikipedia page, then nothing is brought to the table.  TDD is a design methodology – you write a test, then write code that breaks it, then fix the test with the code.  Its not by any means the same thing test-after-development; and it has to actually be experienced day in and day out to fully appreciate its pro’s and cons.
• Same with pairing.  Pair all day for a few weeks, see what that’s like.  Pair when you do not want to pair, pair with someone you do not like . . . until you do, its just something you read.

My advice is this: remain open minded about these until you’ve actually experienced these things. If you lie about it you are damaging the project and the relationships around you at your gig.    After all, we are supposed to be the modern day rationalists, right?

What darcs is:

• It’s an easy to use, distributed, code repository.  It falls into the same category as Mercurial,GIT or Bazaar.
• Distributed?  Yes, patches are exchanged between repositories and there is no one single “mother”repository.
• Super lightweight; runs locally, super portable, cross platform, and easy to learn. The download is 4 megs.
• A great introduction to the world of distributed reversion control.
• Doesn’t do anything to your existing folder and file structures (non-invasive).

What is a distributed respository?

Hmmm . . .this definition is different depending on where you look.  Even as of this date (nov 6 2009) Wikipedia doesn’t have a good definition.

Here is my definition:

• Not tied to a central repository.
• It’s faster.
• Easier to branch.
• Work offline and still create commits.
• Distributed backups — everything is a working copy.
• Collaboration between developers without checking into central copy.
• It can run locally, easily (especially darcs).
• Useful if you are working on a module with a small team within a larger team, and want to revision/track changes with each other but not the full build.

I think subversion is a rock solid repository, and quite honestly, I am not a proponent of using technology for its own sake.  The simpler the better. But the future seems to be distributed repositories and maybe with teams working remotely from each other, the advance of SOA, etc. these types of tools will make more sense.  I suggest trying out darcs just because it gives you an idea very quickly what these are all about.

Repository Workflow

1. Clone a repository to your own repository.
2. Work in the clone — which is now your working copy.
3. Check in and out of your working copy from your IDE/cmd line.
4. When you are ready, commit those changes to another (or original) repository.

One way to look at this is, the “central” repository is the build server’s repository, and you have your own.  But just remember, the only thing central about that repository is that everyone agrees its the place where production bound code must end up.

Maybe this sounds disturbing.

In the “old” days the shops were so used to having copies of everything out of fear of a developer “getting hit by a bus” (which is code for: corporate culture does not trust anyone at all).    Honestly, I have yet to see that scenario. But it does lead us to something I haven’t seen discussed too much:

Best Practices Using Distributed Reversion Control

I haven’t thought about this much until now, but here are some of the guidelines I use for a distributed system.

• Refresh/rebuild in the morning.
• Check in when you get a meaningful amount of work done.
• Physically back up your directories
• Exchange your patches with your team (distributed backups).

Sometime when working in a continuous build environments, I will check things in with my feature sets turned off . . . but usually not, if they are not ready.  Also, you can keep a backup of workin progress in another of your own distributed repositories on a network drive (in addition to your local).

Back to Darcs
The scenario I describe here would be using darcs to sync files from an html blog between your local machine and a usb stick. Let’s assume you have some files at x:\usb\blog and locally, you want to work on them at c:\local\blog. (I actually use this method for a tiddlywiki “getting things done” piece.)

Download darcs and decompress to a desired location.  Add the directory to your path.

Create your first repository.  Navigate to x:\usb\blog and type:

darcs init

Next, recursively add all the files and folders from there:

darcs add -r *

Notice that it skipped all the _darcs files created from the init command!

Run this:

darcs whatsnew

And you can see all the new files and folders you added. But we haven’t saved yet, we have to do this:

darcs record -a

You get asked a few questions (which can be set on the command line as you get better with the tool) and its all checked in!

Time to get a copy of this repo to the local.

Navigate to c:\local\blog (which should be empty) and type:

darcs get x:\usb\blog

You have a local copy! Make changes in your existing files there (on c:\local\blog) and when you are ready, check in your changes:

darcs record -a

And then run this to propogate those changes to your usb stick — first change directories to x:\usb\blog and run:

darcs pull c:\local\blog

And both repositories are sync’d up.  I wrote a little batch file in my case to automate this.

You are probably wondering why in the world I would want to do such a thing.  Well, I can access the files in my tiddlywiki from several spots, and I don’t want a brute force copy over of the file least I lose information.  I need the granular capability  Also I also use it to branch — for instance at year end — very easy!!!

Of course there are a whole slew of other functions but that’ll do.  Darcs is the simplest tool to get your feet wet in the world of distributed version control.