JAW Speak

At a recent client of ThoughtWorks’, I was writing complex GWT views. If you’ve ever worked with Google Web Toolkit, you know the pain that this can involve. Instead of creating HTML files of templates, you need to build the DOM programatically with your own widgets, 3rd party widgets, or the basic widgets GWT gives you. I wrote a simple templating system to meet my needs. Maybe it will help you too, please feel free to request features and share if it helps you.

If you try JAW’s Very Simple GWT Template, all you need to do is follow a few conventions and you get the following.

1. Create a html file with your complex layout. For instance a really fancy 12×12 html table with all sorts of colspans and rowspans for displaying detailed tabular data.
2. Create a value object (in Java, on the GWT side) that you want to automatically use to dump some attributes into the template.
3. In the html template, use ${valueObject.someProperty} style notation where you want automatic setting of values into the template.
4. In the html template, use $${specialDoubleDollarSign} notation where you want to manually bind the template values.

Really, it is very simple and no frills. It solved my need of presenting data in a visually rich way, into html that a designer could produce without any knowledge of GWT. Also, you can embed it into other widgets, or other widgets into it.

I think it’s cool in two ways:

1. Automatic data binding from your value object, into the ${myObj.property} template slots.
2. Ability to manually attach complex widgets (with GWT defined event behavior), into the $${doubleDollarSignSlot} template slots.

I’ve created a Google Code project with the source code and some examples (as tests). Please take a look and leave criticism and feedback.

If you’re curious how this is implemented, it’s all with defered binding and generators in GWT. As all code I actually want to work, I’ve test driven it and you can look at the tests for details.

I had the great pleasure of collaborating with Miško Hevery and Russ Rufer in creating the Guide for Writing Testable Code. Please feel free to check it out, and leave comments here or on his blog.

Here’s a peek at the different flaws to watch out for, and warn your co-workers about. If you see this in code that is getting checked in, bring it to the attention to your team. See Miško’s post for the full list.

Flaw #1: Constructor does Real Work (link)

• If you have a constructor that is doing “work” you’ve established a contract that everyone who wants to create this object also is forced to wait for that “work” to happen. This becomes a huge problem in small unit tests. Frequently unit tests create many, many instances of the object under test - and any work you do in the constructor slows down tests.
• The solution? Break up the responsibility into two objects: a builder of factory to do all the heavy lifting to construct the object, and whatever the original object was that had the heavy constructor. When you split the responsibilities up you will have a better object oriented design, and make it easy for more flexible construction. If you’re tempted to create an init() method and put the work in there - avoid this siren song. It’s a smell of mixed responsibilities and a poorly behaving object that isn’t really ready when the constructor completes.
• Warning signs are:
  • new keyword in a constructor or at field declaration
  • Static method calls in a constructor or at field declaration
  • Anything more than field assignment in constructors
  • Object not fully initialized after the constructor finishes (watch out for initialize methods)
  • Control flow (conditional or looping logic) in a constructor
  • Code does complex object graph construction inside a constructor rather than using a factory or builder
  • Adding or using an initialization block

Flaw #2: Digging into Collaborators (link)

• Jumping from one object to another to another to get what you want makes for hard to test and hard to refactor code. This is commonly viewed as the Law of Demeter violation, however you can dig into collaborators without breaking the letter of the law. This is hard to work with in tests, because your tests need to do a great deal of setup stuffing objects in objects into other objects, or else you’ll get null pointers.
• Warning signs are:
  • Objects are passed in but never used directly (only used to get access to other objects)
  • Law of Demeter violation: method call chain walks an object graph with more than one dot (.)
  • Suspicious names: context, environment, principal, container, or manager

Flaw #3: Brittle Global State & Singletons (link)

• Global state (usually made possible through the static keyword in Java) creates hard to test and modify code. Parallelizing tests is often impossible, and tests that forget to clean up the global state after running interact undesirably with other tests (causing unexpected failures).
• Warning signs are:
  • Adding or using singletons
  • Adding or using static fields or static methods
  • Adding or using static initialization blocks
  • Adding or using registries
  • Adding or using service locators

Flaw #4: Class Does Too Much (link)

• Object oriented design allows you to split responsibilities into individually tested objects. Using an object oriented language does not prevent people from writing procedural code. In fact, most times when someone does not want to write tests it is because their code is hard to test.
• Warning Signs:
  • Summing up what the class does includes the word “and”
  • Class would be challenging for new team members to read and quickly “get it”
  • Class has fields that are only used in some methods
  • Class has static methods that only operate on parameters

There’s typically no magic wand to wave and make hard to test code instantly testable. Engineers need to have an open mind and learn how to write code designed for testability. (In my experience 90% of the time this involves test driven design and test driven development.) These ideas above, and many of Miško’s other posts are a fantastic starting point for adopting that new way of thinking.

Please link it up with your favorite testability mindset readings.

I’m using etckeeper to keep my /etc directory in version control (git).

When you make changes to a server, there are always risks. And even if you have a great backup strategy (I recommend backupninja), sometimes you change a config in the wrong way, which can ruin an otherwise great night. Why don’t we have an easy way to version control this very important configuration directory? (Ubuntu is working on it).

Here’s what $ sudo gitk will show you after a few changes in your /etc.

It’s no surprise that this comes from Joey Hess, who also wrote how to keep your life in svn. I was going to check into subversion all of /etc, but this has been a better experience so far: it has automatic hooks to do pre and post apt-get update commits. So you can more easily see what each package does to your configuration. Also, etckeeper takes care of permissions where svn can’t.

If you’re ready to install, here’s how you do it. I didn’t use the deb distribution because it is quite out of date, instead I pulled down the newest directly from Joey’s git repository.

$ sudo apt-get install git-core gitk
$ cd ~/
$ git://git.kitenet.net/etckeeper
$ cd etckeeper
( read the README and INSTALL files )
( possibly edit etckeeper.conf if you want to use bazaar or mecurial instead of git )
$ sudo make install  ( It's okay if it warns that bzr support not installed if you're not using it )
# sudo etckeeper init
$ cd /etc
$ sudo git status
$ sudo git commit -m "Initial checkin"

That’s it! Check out the README for day to day examples.

Whenever you use apt to install a program, it checks in any uncommitted changes, and then checks in the /etc after apt finishes. /etc is just a regular git repository (except for security permissions require using sudo), so you can also commit changes anytime you want.

Here’s another person’s take on etckeeper. New to Git? Check out Git for Computer Scientists.

If you are using Hibernate with an existing (ahem, “creative”) database schema sooner or later you will be stuck with a field that Hibernate can’t parse. Say there is a Dimension column which stores the integer dimensions as a string “003X001X010″. That would be 3 by 1 by 10 units.

You can implement UserType to transparently convert a proprietorially formatted field into first class objects of your choice.

And you can do it in a testable manner.

I’ll show the tests first, then the custom UserType. Right after the bump. (Click the post permalink to read the rest).

Read the rest of this entry »

If you have an iPhone but have trouble figuring out how to send people text messages with pictures, or MMS messages, here’s a fix.

Go to the camera app and view the picture you want to send, click the send button and email it to one of the special email addresses below, based on their phone number and carrier. These are the SMS gateways from the carriers so the picture will be converted into a picture mail message and you’ll make somebody’s day (-;

I hope this helps you.

Podcasts are to real-unabridged-books as a raindrop is to a punch in the face. It takes a team of dozens of people to write a really awesome book. And I find them more satisfying and thought provoking than several short podcasts.

There is nothing so precious as your time. I am only more convinced of this every day.

In the last 3 weeks, I listened to:

• Confessions of an Economic Hitman - even though I don’t agree with his conclusions, it is an excellent memoir. It was personally thought provoking to listen to a man’s entire career life unfold in 5 days on my work commute. Takeaway: life can be very exciting, and some people are very powerful. Move faster, driving for results.
• Banker to the Poor - fantastic book. If you don’t know about microfinance, this is your introductory course. Imagine in your mind what the marriage of finance and social justice would look like. I read it with friends–which led to great conversation–and scheduled a tentative meeting with the great folks at Kiva.org for my friend with an NGO in India.
• Travels of a T-Shirt in a Global Economy - So far it’s entertaining. It is a story telling format asking “where did your T-Shirt come from?” And the government-subsidy-enabled-irony of the cotton planted in Texas, woven and sewn in China, and imported back to Florida.

To effective time.

UPDATE (10/26): Listening to more of the last book tonight. Around the 3h 30min mark, I learn the key driver our present industrial economy: the Spinning Jenny. This was a big deal. One person used to have one spinner to make the yarn. In 1764 they suddenly had eight spinners: a tremendous productivity boost in an under supplied marketplace. By 1800, spinning jenny’s had 80 spinners. And by the 1830’s the price was 1/20th of the 1700’s price.

This breakthrough –mechanized yarn production– propelled the world into the industrial age, and brought consumers into expecting constantly improving technology and quality of life. To me the parallels of present day high tech are remarkable, and the “so what” factor noteworthy.

Two “so what” takeaways:

1. The invention of the spinning jenny came because of great bottlenecks in yarn production. In the 1760’s mostly farmers produced cotton yarn, and this was a cottage industry. When harvest time came the families were far too busy harvesting, and weavers had a great difficulties buying yarn. Often they had to walk six miles each day to gather up enough material for that same day’s weaving. This bottleneck –as all bottlenecks– created a great pressure. A pressure that burst forth in invention, and technological revolution.
2. In the face of such bottlenecks, Britain sanctioned a contest of which the spinning jenny was an entrant. An example from the past of how using prizes compelled innovation. See the X Prize Foundation for present day contests in medicine, automotive, education, or (Google’s just announced) Lunar X Prize.

I’m a ThoughtWorker. ThoughtWorks is changing the way that enterprise software is delivered. And with that we take firm stances on heavily debated topics. In previous jobs I’ve tried to push test driven development, unit testing, code coverage metrics, continuous integration… all controversial ‘best practices’. Results were mixed.

A few weeks ago I was at a large web 2.0 social networking site working with selenium grid automation. They were great clients, fully receptive to automated testing. Next week I’ll be heading to another leading internet company to work triage:

1. Work on troubled teams whose code is poorly tested
2. Enable groups to test legacy code
3. Attempt to spread a pervasive test driven mindset.

I’m joining a senior team of ThoughtWorkers and in preparation I’ve thought of various arguments I’ve heard (or used myself) against testing code. I’ll be challenged working with these very experienced people, but I am eagerly looking forward to the experience.

Argument #1

Adding all these tests only makes more code to maintain, debug, and write. This can’t be good - I want less work, not more!

Rebuttal: Would you agree code and requirements often change? Would it be valuable if something could automatically and accurately catch bugs introduced with changes? How about if the original developers are no longer on the project? Testing can enable less work — in a dynamically changing environment. Immediately the work is greater, but over time it is less.

Argument #2

Ok, fair enough, there are some good reasons to do this. BUT, when I want to change something later, I now have two points of failure - the code I’m changing, and all the tests that depend on that code. I haven’t really bought myself all that much security, because if my tests don’t catch the problem well, I’m just as hosed as if I had no tests. ^{Source: first comment from here}
Rebuttal:

1. You get better and faster with tests the more you write them.
2. By writing tests you further understand the business domain and craft a better thought out solution.
3. Whenever making changes in the future you actually have 1 + n points of failure. That which you are changing plus the other interacting systems within the code. By writing tests you will automatically catch the interactions, as well as the initial point of failure. Sure the tests need maintaining, but now with two things to maintain, you catch (almost all) these failure points.

Argument #3

I generally think testing is a good idea. But I’m stressed out, I’ll get to it later… tomorrow I’ll add tests… as soon as I get this working
Rebuttal: Take a page from Agile Software Development: Principles, Patterns, and Practices by Robert C. Martin.. He argues for refactoring but since the two concepts are so tightly entwined, I think the argument applies here:

“Refactoring is like cleaning up the kitchen after dinner. The first time you skip it, you are done with dinner more quickly. But that lack of clean dishes and clear working space makes dinner take longer to prepare the next day. This makes you want to skip cleaning again. Indeed, you can always finish dinner faster today if you skip cleaning, but the mess builds and builds. Eventually you are spending an inordinate amount of time hunting for the right cooking utensils, chiseling the encrusted dried food off of the dishes, and scrubbing them down so that they are suitable to cook with. Dinner takes forever. Skipping the cleanup does not really make dinner go faster.”

Skipping testing does not really make software development faster, because changes are guaranteed. (You’ll have to cook another dinner eventually). Without an easy way to baseline and build upon existing code, time is spent bugfixing that could instead be adding features or writing new tests.

Argument #4

I’m awesome. I don’t write bugs. So I don’t need tests.
Rebuttal: Great. I’m excited to be working with you. I’m sure I’ll be able to learn a great deal. I imagine you like fresh challenges. And in six months or a year this current project won’t be as interesting to you as it is today. In fact, you’ll be on to something more challenging and worthy of your awesomeness.

So that means someone else — possibly a junior developer — will be maintaining and working on this code. Without tests, they will be frequently seeking your assistance and guidance to prevent bugs. This is not what you want, is it? You want new challenges, not constantly being hassled by old code. So write the tests now to ensure your ego and intellect can move forward to bigger and better things.

Elaborating and paraphrasing, Neal Ford argued at eRubycon 2007:

Now I look at not testing as professionally irresponsible. I’m paid to create software, to deliver on a client’s business needs. If I don’t rigorously and automatically ensure I have accomplished this with the minimum amount of bugs — I am committing malpractice.

What arguments have you encountered, and how have you responded?

I’ve really, really missed the really smart people I used to work with.

I believe working full time, with great people, and doing my own projects on the side will be vastly more productive than having full time for my own projects.

After leaving FeedBurner with the Google acquisition, I gave myself 2 months of running my own business full time. After that period, I would either be hiring folks, giving myself a few more months, or getting more experience at a startup or consulting.

Second Valley’s revenues are up a healthy 25-40% compared to May. I’ve been spending time in Ruby on Rails, and have started rebuilding the full ecommerce and delivery platform for one of Second Valley’s sites. But I missed the smart coworkers.

My decision Wednesday was to email ThoughtWorks and continue my interview process I started prior to joining FeedBurner. Well, thanks to the amazing Carrie McComb, I interviewed Thursday and had an informal offer that night. Friday morning I signed and it’s official.

In 10 days I’ll be off to India for ThoughtWorks Immersion training, and then I’m relocating to San Francisco.

Photo credits: meaux, and artview (my previous trip to India)

Yes, I am well.

1. I left the botique enterprise content management software consulting company, Technology Services Group. ^[1]
2. I joined FeedBurner, as an engineer in February.
3. I did some really cool ad serving optimization code. My IE degree let me do some fun multivariate linear regressions to prioritize ad serving into their feed ad network. The code base was great to work in. Plus the team was great and I’ll really miss them. This leads to #4.
4. Thanks to the Chicago PHP users’ group, as well as my Chicago tech event calendar site Techsocial, I was able to attend php|tek. The presentations are now available. ^[2]
5. Google acquired FeedBurner in July. I don’t have much to say here, other than I learned a ton living through the acquisition process.
6. Meanwhile, I incorporated a side business that I’ve been working on since 2003. It’s been profitable since the launch in September ‘06. The entity is Second Valley, Inc, but I”m operating under another name. ^[3]
7. I pretty much had the perfect opportunity to ramp up my business by working on it full time. I’ll spend a few months at marketing, product development, (more) SEO, statistical analysis enhancements, and rebuilding the PHP app in Ruby on Rails.

Notes:

I’m migrating one of my main e-commerce sites from php to Rails. Coming from a few years of Java and php makes me really appreciate this framework’s rapid development cycles, as well as strict MVC approach.

Note: this is a technical post, it assumes you’re interested in, and familiar with Rails.

Rails wants to be RESTful. Many sites and books go into depth explaining REST. Last year’s Railsconf keynote by DHH can give you the big picture of CRUD and RESTful applications. (Be sure to follow along with the pdf slides, while you watch the video).

Look at an existing mature project (Beast) to learn how to make RESTful models

Nitty gritty RESTful implementation details have been hard to find. So I started searching out open source projects that are known for good design. And I read the code.

Beast is a forum program written in Rails by Rick Olson and Josh Goebel. Best of all, it’s a great example of a REST application.

I’m a visual person, so I created the chart below to help me get the hang of what the Models and relationships look like in Beast. Big bold squares are actual database backed objects. Dotted squares are just regular models.

Please contact me if you catch an error or omission.

Here’s how you use the diagram

Right now, browse here: http://svn.techno-weenie.net/projects/beast/trunk/app/models to the Subversion source of Beast. Back already? My you’re fast. Read over the different model objects. See how they relate. Think about what’s been abstracted into additional Resources, rather than creating actions willy nilly in the controllers.

Then check it out and run it in your local environment. Even if you couldn’t care less about the (quite nice) forum software that it is, it’s good to learn by taking it for a spin.

But I think I need more actions than CRUD gives me!

As DHH said in the 2006 Railsconf keynote, sometimes you think you need another non-CRUD verb to your controller. Say you have a Forum that has Users and Topics. Some users want to monitor topics. At first blush, you may want to add an action to Topic. You’d then post to /topic/monitor/123 to start monitoring topic 123.

There is another way.

Relationships, events and states can all be models. When a new topic is to be monitored, you’ll GET to /monitorships/new to get the new Monitorship object form. Then POST to /monitorships to actually create it.

Models are more than things.