Most of us at Atomic probably qualified as nerds in high school. If you agree with Paul Graham’s observations in his essay How to be Silicon Valley, this is no bad thing.

Today I happened to observe something strange about our nest of nerds: our last names fall disproportionately into the first half of the alphabet. In fact, 77% of our last names start with a letter in the range [A-M].

A quick search didn’t turn up what the alphabetical distribution of last names in the US actually is, but I guess it must be a lot closer to evenly distributed than our data indicates. We don’t keep a paper phone book anymore, so I couldn’t measure that way. The only data I had readily at hand was our customer database. In this much larger set of names, 64% fall in the first half of the alphabet.

Maybe nerds are more near-sighted, have to sit closer to the front of the room, and actually learn more in school?

I love our morning stand-up meetings: short, low-stress, and effective. Besides agenda and news, we often share technical topics with the group.

Here’s a quick list of some recent projects we’ve noticed or discussed:

• Rango – a new web application framework in Ruby, influenced by the success of the Python project Django. There’s a nice overview in PDF form.
• Atomic Object’s github account was started, hosting a few of our open-source projects.
• jesus is a web interface to God.
• jaml is an HTML template library for JavaScript, influenced by Haml.
• Lawnchair is a JavaScript client-side document store.

• bundler – easily bundle gems within an application. This tech has spread like wildfire through the office – I think it is something we’ve been wanting at Atomic for a long, long time now.
• git-deploy – deploy new code with a single “git push” command. I’ve forked this project and made some modifications for to suit our project.
• cancan – “Simple authorization for Rails”
• gritter – jQuery code that gives growl-like notifications. It works well and has been well received by most of our users. (That said, I personally cannot stand growl and think notifications like this should die in a fire.)
• culerity – celerity hooks for cucumber. We’re definitely not the first project to use it, but Drew and I have made extensive modifications to improve culerity’s process management.

One of the nice things about kicking off a new application is that it’s the best time to integrate new, exciting technologies like these. Discovering and integrating them has helped make our development process better than ever.

I’ve just re-planted our VMWareFB OpenStep display driver to Github, and I’ve updated our existing web page accordingly. Precompiled, compressed configs are now available in the downloads section of the new Github project page.

Special thanks to Andreas Grabher and other folks over at www.nextcomputers.org for solving the chronic problem of running at resolutions higher than 1024×768. Andreas has provided an updated source tree and config file, so after 8 years we’re moving from 1.0.0 to 1.1.0.

It’s been almost 8 years since Bill Bereza first wrote this SVGA driver for our customers over at Valley City Linen and we’ve hardly tinkered with it since. Lots of people have found and used it over the years, and are still using it today. It’s a pleasant surprise that it continues to work reasonably well for people out there in NeXT land.

Now that the code is out where people can freely update and re-release it, I hope to pull in a few interested members of the NeXT/OpenStep community and let them take it from here. I know a few people have privately hacked or updated the driver to work better for their own installations; I’d love to have them fold those updates back into the public source.

(Thanks to Marissa Christy for the cool logo sketches!)

I have been working on a DataMapper adapter for a RESTful JSON web service. I put together a gem that includes the adapter implementation, as well as a few DataMapper::Resource classes that can be used as a starting point. I did not want to install my gem’s dependencies globally while developing it, so I ended up trying a couple of different things to manage my development environment.

The first thing I tried was rip. I had not used rip previously, but it looked like a good fit for gem development since you don’t need to distribute the dependencies with the gem. I set up a rip environment for my gem development, and at first it worked very well. I could use it when I was working on the gem or switch to an empty environment when working on something else. After running into some issues with my DataMapper adapter and a newer version of dm-core, I needed to reinstall several dependencies. Upon trying to re-install dm-serializer I was confronted with the following:

1
2
3
4
5
6

]rip install dm-serializer
undefined method `strip' for nil:NilClass
undefined method `strip' for nil:NilClass
undefined method `strip' for nil:NilClass
rip: install failed
-> undefined method `strip' for nil:NilClass

Google didn’t turn up anything, and I really didn’t have time to look into the problem. I think rip is a great project, but it was not going to solve my immediate problem without some debugging, so I moved on. Next I turned to Bundler.

I converted my deps.rip to the following Gemfile:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

source "http://gemcutter.org"
source "http://gems.github.com"

bin_path "vendor/gems/bin"

only :test do
  gem "rspec"
  gem "mocha"

  gem "dm-core", "0.10.1"
  gem "dm-serializer", "0.10.1"
  gem "dm-validations", "0.10.1"
  gem "json", "1.2.0"
end

disable_system_gems

I only need the runtime dependencies when running the tests, so everything goes in the only :test section. And I don’t want any bin scripts from my dependencies to end up as part of my gem, so I configure them to go in vendor/gems/bin. I also don’t want any of the dependencies to be included in the packaged gem, so I exclude them from the Jeweler configuration in the Rakefile:

1
2
3
4

Jeweler::Tasks.new do |gemspec|
  ...
  gemspec.files.exclude "vendor"
end

Finally the dependencies are loaded in the spec_helper.rb:

1
2

require File.expand_path(File.join(File.dirname(__FILE__), '..', 'vendor', 'gems', 'environment'))
Bundler.require_env :test

After making these changes I ran “gem bundle” and was able to continue development without needing to globally install any of my new gem’s dependencies. So far my experience with Bundler on this project and others has been excellent.

A long time ago, in my first career as a professor, I started a file of nice words. The file had compliments, positive comments from evaluations, thank-yous, etc—nice words people had written about me. I never found a use for the file, but it seemed like a good idea to collect the raw data. In 2005 I resurrected this practice for use at Atomic, with a slight twist: when a client says some nice words about someone at Atomic, I distribute these words to the whole company. I don’t know how important this is to individual Atoms, but it seems smart to acknowledge when clients go out of their way to say someone did an exceptional job.

The nice words are typically about extra efforts, smooth deploys, great communication, effective project management, personal caring or dedication, creativity, predictability, or responsiveness. Very rarely they contain a technical compliment (“awesome algorithm”, “great tests”). But those nice words are much less common than the actual frequency of technical excellence in our projects.

I think this is because the benefits from our technical work tend to accrue long after the work is done. By the time our testing has resulted in no downtime or no user irritation, everyone has moved on and takes quality for granted. No one thinks back to the root cause of the pain they don’t feel. There are new problems to solve, new features, or new projects. It’s very easy to miss a critical element of what got you to this point in the first place. Think about it. When was the last time you stopped and appreciated a piece of software that’s run smoothly for years?

By contrast, the stuff that does attract nice words is much more immediate. When you get a prompt mail or return call, you know it immediately. When you see a project managed effectively, you feel it right now. When someone makes an extra effort to hit a deadline, you’re aware of it. Creative solutions to problems shine as soon as suggested.

Something that accentuates the under-appreciation of technical excellence is that many of our customers are business people, not engineers or developers. The people who generate POs and sign checks might not even be able to directly evaluate the technical quality of our solutions. It’s an act of faith, unless they’ve been burned before, that good software design and testing will make their projects more successful and their lives easier.

Ironically, less disciplined developers who commonly let bugs out into the world may be more likely to get the technical kudos. After all, they’re performing the software heroics of late night, last-minute debugging and patching. It’s their technical ability that a customer is held hostage to and rescued by. Just like the actions that engender our nice words, these efforts are highly visible to customers. I suspect some developers even get addicted to the opportunity to be a hero and save the day through their technical prowess. This isn’t really in the best interest of customers, but if you’ve headed down the path of undisciplined, unpredictable development, you’re probably thankful for the effort.

Heroics are great when they’re needed, but it sure is better to not need them at all. Guess I should go spread some nice words about all this great code I’m surrounded by.

What is Cloud Computing

Cloud is a pretty nebulous term that gets applied in several different, but related situations. As a result, it is difficult to find an agreed-upon definition and not all usage will be consistent. Cloud web hosting means on-demand access to serving capacity in a pay-per-use model instead of owning or leasing a handful of servers.

The availability of cloud platforms is gamechanging for a number of reasons:

• Massive computing power available on-demand enables even small companies to react effectively to a rush of traffic.
• This cheap burst computing power can enable new business models that were previously limited by the expense of sufficient computing power.
• The pay-per-use aspect of infrastructure in the cloud means capital expense and risk can be outsourced to a public cloud like Amazon’s EC2 service.

Catalog Choice on Engine Yard Cloud

These properties of cloud computing are perfect fit for one of our customers in particular. Catalog Choice is a non-profit organization that needs to operate leanly but has a penchant for getting featured in national media. Features on the Today Show and in publications including the New York Times and the Wall Street Journal brought with them attendant bursts of traffic.

Engine Yard Cloud was a perfect fit for Catalog Choice. They were already running on EY’s infrastructure, exploiting the benefits of their optimized software stack and round-the-clock support by engineers with significant Rails expertise.

Catalog Choice needed to reduce costs while retaining the ability to handle rushes of traffic. Moving Catalog Choice to EY cloud allows them to trim excess capacity during slow times to cut costs without giving up Engine Yard’s software stack and support.

Catalog Choice’s Migration to Cloud

Switching to EY cloud meant making some adjustments.

We had to give up the GFS partition shared across our EY slices. We needed to move configuration into Chef to be able to bring up new instances of our application. These changes provide business value to Catalog Choice beyond the switch to EY Cloud. Server configuration steps that were documented in a wiki are now fully documented as an executable, repeatable and testable set of Chef tasks. With the switch to Cloud, Catalog Choice’s flexibility is increased, not diminished.

One of the most important questions at the start of a project is how much it will cost. It is vital to make sure that enough budget is available to allow for the development of a viable product.

The difficulty with setting a budget at the start of a project is that everyone is at the point of maximum ignorance. At the beginning of a project, all of the requirements have not matured. Scope may not be fully defined, the market approach may be a bit hazy, or the technical requirements may still be in flux. It is okay to move forward with a loosely defined project as long as the scope and budget are refined at several steps along the budget roadmap.

How big is the pie? After a project has been loosely defined, the profit generating, or cost savings, potential should be estimated. Refining scope and budget will cost time and money. Knowing the potential reward will ensure that the research, design and planning effort stays within perspective.

Early Estimation We use the early project requirements, historical data from previous projects, and our experienced intuition to initially estimate cost. At this point the estimate will have the broadest range. We might estimate that the project will definitely cost $50,000 but probably not go over $100,000. If the estimate is much higher than expected, we can revisit the requirements to make sure that scope expectations are aligned. We can redefine the scope and estimate again.

Research, Design and Planning If the initially estimated cost range is acceptable, we’ll move forward into a research, design, and planning (RDP) phase. This phase provides further definition of the product’s users and functionality. We will create a story map to define the user activities and tasks and use that map to define a minimum viable product. We then estimate the development effort, in ranges of days, to implement the features that allow users to complete the defined tasks. To aid in our estimation effort, we may create sketches or wireframes that roughly define the features. We’ll also qualify each feature as supporting the context or core of the product and how high or low the frequency of use may be.

More Decisions Our refined estimate coming out of RDP usually falls within the range of our initial estimate. Sometimes the estimated cost increases because we have learned more about the product. A higher estimated cost is okay. Money has been spent to gain knowledge. Risk has been reduced and we’re more certain about the cost of chasing the reward. At this point a decision is made to move forward with development or not.

Predictable Delivery We start development with the estimated budget from RDP as a constraint. We create a backlog of development stories. Stories to be completed in the near future are more defined than stories in the distant future. We track our progress through the backlog of stories on a weekly basis. We give weekly updates of the projected final cost. We define stories further when appropriate and negotiate scope to keep the project on budget. At the end of the project, we deliver a final release within a predictable time and budget.

Recently, a colleague and I were experimenting with SWFUpload, a popular flash based file upload tool. We quickly realized that SWFUpload cannot forward cookies; and since our rails application utilizes cookie based sessions we were unable to upload a file. After a little bit of research we stumbled across a blost post that offered a solution using rack middleware.

In short, it has you add the required cookies as form parameters and then insert a rack middleware object before the rails session store. This object is responsible for extracting the form parameters and then inserting them into the “HTTP_COOKIE” header before rails is invoked. After following the instructions on the blog post we were able to successfully upload a file using SWFUpload.

This particular problem inspired me to write a lightweight rack middleware library called Cookie Monster. It solves the very problem that was described above and is wrapped up in an easy to use gem (or rails plugin).

 gem install rack-cookie-monster

or

script/plugin install -f git://github.com/dewind/rack-cookie-monster.git

Configuring it for rails is easy:

1
2
3
4
5
6
7
8
9

# In rails initializer
  Rack::CookieMonster.configure do |c|
    c.eat :_session_id
    c.eat :user_credentials
    c.share_with /^(Adobe|Shockwave) Flash/
    c.share_with "Burt"
  end

  Rack::CookieMonster.configure_for_rails

No wonder we’re all a bit tired at the end of this year. A little digging through our CRM tells me that sales opportunities are up 30% and our success rate is identical compared with 2008. With revenue basically flat and spot-on with what I was expecting, it means we’ve sold and worked on 30% more projects this year than last.

The nice thing about this is all the new customers we’ve met and helped. But I hope everyone has saved some vacation time. I think we could all use a rest.

Last month Shawn Crowley and I attended the Business of Software Conference in San Francisco. This was one of the best software conferences that I have ever attended. It was unique because it brought together a strong collection of software company founders and top management. Most of these companies worked in B2B vertical markets that did not compete with each other. This lack of direct competition helped facilitate great conversations in which conference attendees openly disclosed company success and failure stories.

My favorite part about the conference was a key note talk given by Geoffrey Moore. Moore is widely known for his successful book Crossing the Chasm. During Moore’s talk he discussed a few types of software projects. I believe that the same principles apply to features of software products.

Differentiation – A differentiation project does something different than the competition. If done correctly it gives the organization enormous bargaining power.

Neutralization – A neutralization project focuses on meeting the market norm. It is not about outperforming your competition. The goal of this project is to make your organization competitive by offering a similar feature set.

After describing these project types he went on to discuss how it is very common for both of these types to lead to organizational waste. Moore used a similar image to the one below to describe this concept.

Differentiation Waste – A differentiation project becomes wasteful when it is not taken far enough. Since these types of projects require innovation and lead to high bargaining power they come at a high cost. Moore’s advice for these types of projects is that an organization should be willing to spend twice as much as they anticipated to really make this type of project a success.

Neutralization Waste – A neutralization project becomes wasteful when the project goes too far. Moore discussed that adding additional bells and whistles to a neutralization project will gain applause, but until it reaches a certain level of differentiation the customer will not pay more money for the extra effort.

An example of how a neutralization project can be wasteful could be a simple login feature in a web application. Most modern web applications have the ability to login and reset the password. In order for a product to compete it must invest in login functionality. Once the development for the login is complete it becomes very tempting to improve the feature. Perhaps, adding avatars would be interesting. Before investing the development resources in this additional feature the project team should consider if adding the avatar feature is a differentiation, or if it will take more than just the avatar feature to make the product more valuable to the end customer. If the team is not willing to take the feature far enough to differentiate then maybe it makes more sense to have the team work on something else instead. The area after neutralization but before differentiation is waste.

Understanding the difference between these two project types was very enlightening for me. Knowing what type of project or feature you are currently developing helps answer the question of how much is enough. Challenging our customers on this idea helps us provide maximum business value.

I recently attended JRubyConf in San Francisco. The conference definitely had a strong web presence, but it wasn’t without a few “web neutral” presentations. The JRuby State of the Union, The JRuby Testing Story, and some of the lightning talks were interesting and fun.

Phil Hagelberg gave a brief presentation on Clojure’s Software Transactional Memory and how it can be used within JRuby. He wrote a small library that exposes and wraps the necessary STM components in the Clojure Java implementation. I briefly experimented with library, and it appears to work quite well and could provide immediate value to multi-threaded applications.