Mess Up Early Mess Up Often

"We make mistakes often, we plan for it and we adjust to it.  If you don't make mistakes you never do anything new."

- Pete Doctor (director of Up and Inside Out, writer on Toy Story and Wall-e)

This quote resonated with me because I make a lot of mistakes.  Or maybe I should say I like taking chances.  Finding a new and better way of doing something, innovating, and exploring are all exciting and creative.

This article is about refactoring by the way.  If you're not a developer then ignore this and skip to the next paragraph.  I'm hoping the ideas here are applicable to programming but general enough to be interesting to non-geeks as well.  Refactoring didn't used to be a word...we used to rewrite or rework a program.  But refactoring is a good word to have in our vocabulary, with its implication  of improving, rethinking and intention.

There are certain tasks that do not lend themselves well to taking chances and making mistakes.  Surgery is an example, building a bridge is another.  We can rarely make big mistakes in those tasks and try again.  (Though even there, the best new discoveries have often been through happy mistakes or lessons learned from unhappy mistakes.)  Programming, however is another story.  We don't build a program once...we build it over and over.  As often as possible in fact.

There are concepts and tools that help you make mistakes and recover from them.  Unit testing is probably the most important.  Test driven development lets you safely try out possibilities and immediately know if you've succeeded or failed.

Continuous build is another.  It tells you how well your changes are interacting with other people's changes.  It helps keep you from making really big mistakes.

I'm a lazy programmer.  I recognize this...in fact I may be a good programmer because I'm lazy.  I will spend hours looking for a way to make things a little easier.  Watch out for programmers who like working.  They will make work for themselves at the cost of consistency.

Also watch out for programmers who do too much work up front.  They will write code that covers every possible event...which is great if you are sending your code to Mars with no way to update it.  Otherwise you end up with code that is overly-complicated, prone to bugs and worst of all, difficult to refactor.  Make the code do the minimum, then figure out where things could go seriously wrong and test those cases.

Once you've created your code and gotten it working, set aside time outside of the scope of your sprint/waterful to look at your code, make sure it's doing everything you expect and look at refactoring it to make it:

1.  Clearer
2.  More reusable
3.  More robust
4.  Faster

Code Coherence Is Cool

Some interesting ideas from JOHANNES BRODWALL.

Boiled down a little, he says there are opposing forces in modern code.  Two of these are:

coherence <--> decoupling
reuse <--> decoupling

If you've ever tried to follow the code through a severely decoupled program you didn't write, or wrote a long time ago, you know what losing coherence means.  Instead of just following a couple function calls you get function call -> Spring configuration -> function -> rest service -> Spring configuration -> function -> Hibernate configuration.

In his article Johannes says coherence > decoupling > reuse.  This is not a hard and fast rule but it makes sense.  A program that's coherent can make the difference between a 5 minute fix and an all day goose chase.  I've seen a lot of premature decoupling...when it's unnecessary it just becomes the architecturally correct version of spaghetti code.

Avoiding reuse is awesome, but to avoid reuse you can end up with code that's overly coupled and complicated.

Google App Engine Pitfalls 2.0

Logging - add this:

 private static final Logger log = Logger.getLogger(GreetingServiceImpl.class.getName());  

...and this...for some reason...

 log.setLevel(Level.INFO);  

...and of course.

 log.info("The query returned " + pq.countEntities() + " entries.");  

Google App Engine and Datastore Pitfalls

Working with Google App Engine and hit some interesting "learning opportunities":

 private void persistData(String[] input, User currentUser) {  
   String weeklystatusName = "weeklystatuslist";  
   Key statusKey = KeyFactory.createKey("WeeklyStatus", weeklystatusName);  
   Date date = new Date();  
   Entity status = new Entity("Status", statusKey);  
   status.setProperty("userid", currentUser.getNickname());  
   status.setProperty("date", date);  
   status.setProperty("name", input[0]);  
   status.setProperty("date_begin", input[1]);  
   status.setProperty("date_end", input[2]);  
   status.setProperty("client_name", input[3]);  
   status.setProperty("accomplishments", input[4]);  
   status.setProperty("risks", input[5]);  
   status.setProperty("next_week", input[6]);  
   status.setProperty("hours", input[7]);  
   status.setProperty("pto", input[8]);  
   status.setProperty("distribution", input[9]);  
   status.setProperty("submitted", input[10]);  
   DatastoreService datastore = DatastoreServiceFactory.getDatastoreService();  
   datastore.put(status);  
 }  

Running a query on the datastore didn't return anything though I could see my data while browsing.  And...the query didn't work in GQL either.  Finally I discovered that what I thought were Strings saved to the datastore were actually User objects.  Datastore doesn't care what you pass to it...it'll save that object.  But just because it looks like a string doesn't mean it is.

One getNickname() later...query worked.  Added a sort...

select * from Status where userid='user1' order by date desc

Query broke.  Gah.  No wait...it says I need to add an index.  Added that to WEB-INF and redeployed.

 <?xml version="1.0" encoding="utf-8"?>  
 <datastore-indexes autoGenerate="true">  
      <datastore-index kind="Status" ancestor="false" source="manual">  
           <property name="userid" direction="asc"/>  
           <property name="date" direction="desc"/>  
      </datastore-index>  
 </datastore-indexes>  

Still failed.  Eventually I realized that "kind" has to be the name of my table.  (My table was called "Status" not "Statuses".)  It sort of makes sense but not really, since you might expect an index could be applied to multiple tables or at least that I'd get an error message if I tried to create an index that wasn't connected to an existing table-space.

Datastore seems to be designed as Fisher-Price My First Database in some ways but then it uses unusual standards (by Oracle/DB2/mySQL standards) and doesn't provide detailed documentation.  Still though, very cool once you get used to it.

Ruby Tricks - Listing time spent in code

<some code>

@@t = ::Time.now

<more code>

puts "Time: " + (::Time.now-@@t).to_s +  "\n"

Note: the ::Time is only there because I ran into a conflict between the Time class in Ruby and the Time class in one of the gems I'm using.

Truncate vs Delete in Oracle

Database 101 says...always truncate instead of doing a delete from on tables. It's faster and more efficient. Well, everything you learn in a beginning class is wrong sometimes.

We had a set of Junit tests that truncated a set of Oracle tables a few thousand times. It took a long time. Changing those truncates to deletes made the tests run about 10 times as fast. So apparently truncate has some overhead that delete does not.

Lesson: the stuff you learn in Anything 101 should be verified.

Googley

We've been re-architecting our application from Swing to GWT and it's been working quite well. GWT is surprisingly stable and non-quirky. In general. It has some visual issues with IE6 but then IE6 has some issues with IE6.

One thing we did was use an event bus to pass events around. This solved a number of issues for us. Sometimes an event in one view would need to trigger a change in another view, or multiple views and this pattern allowed us to easily trigger those changes without having to clutter up the interfaces of parent classes.