Atomic Spin :: Elements of Software

A short article in Scientific American entitled “Tough Choices: How Making Decisions Tires Your Brain” looks at “executive function.” A growing body of psychological and neurological studies demonstrates that the human mind has a limited amount of decision making juice available each day.

When said juice is used up decision making declines markedly in measurable ways. Given that software development is an all-day exercise in decision making, trade-off resolution, and implementation (all topics discussed in the article), the evidence cited in the article supports the idea of Sustainable Pace (the idea, nay fact, that programmer productivity goes down past about 40-50 hours of work per week).

The human mind is a remarkable device. Nevertheless, it is not without limits. Recently, a growing body of research has focused on a particular mental limitation, which has to do with our ability to use a mental trait known as executive function. When you focus on a specific task for an extended period of time or choose to eat a salad instead of a piece of cake, you are flexing your executive function muscles. Both thought processes require conscious effort-you have to resist the temptation to let your mind wander or to indulge in the sweet dessert. It turns out, however, that use of executive function—a talent we all rely on throughout the day—draws upon a single resource of limited capacity in the brain. When this resource is exhausted by one activity, our mental capacity may be severely hindered in another, seemingly unrelated activity.

So, scientific study is bearing out what good programmers know implicitly and what great programmers incorporate into their lives. Working longer actually leads to poor decisions and negative productivity; working at a sustainable pace optimizes productivity.

For my last Rails project, we went to a completely Ajax interface for everything. This meant that nearly every action on a controller would result in several lines of RJS calls, along with the logic of which partial to render depending on the state of updating or creating an object.

All that logic and RJS stuff was a pain to test in a controller spec, because so much setup is needed every time you call a controller action in a test (authentication, session, etc). Any branching you have in a controller action really becomes a nuisance to test, and when the customer wants to be able to change what happens on the page when a user saves some object, rewriting those tests and the controller are even less fun.

So we came up with the idea of moving all the presentation related logic out of the controller and into helper objects we call announcers. The purpose of an announcer is to make the actual rendering calls, based on state that is passed to it by the controller.

• Work on our application as developers
• Distribute our application as a single jar file to our users
• Compile the Ruby source files into Java class files
• Integrate third-party Ruby and Java libraries

This article includes an example project that demonstrates all of the above.

ActiveRecord is perhaps the most compelling component of Ruby on Rails. ActiveRecord makes it easy to create a record, or to find one, or even to migrate the database schema. Unfortunately those “find” methods can be a little too seductive. Let’s see why.

Atomic Object provides some fantastic benefits. For example, Atomic sends each developer to one conference each year. They pay the registration, air fare, and hotel. They also pay as if I had been actually working. It’s fantastic to have an employer that not only wants me to be a better developer, but takes the extra steps to help me improve.

This year, I attended the Google I/O conference in San Francisco. The first day’s keynote was essentially a bird’s eye view of the conference content. The overall theme was that Google wants to advance capabilities of web applications. They understand that their growth is tied to the growth of internet use at large. They understand that internet use will increase as web applications improve. They want to facilitate the improvement of web applications by providing tools for developers to use. As much as possible, these tools are open source, and not bound to Google, as that is the best way to empower the advancement of the internet.

Have you ever needed to display Unicode characters in a Win32 MessageBox from a Ruby script? My pair and I needed to do just that and so I thought I would share what we found.

There are a number of ways to access Win32 calls from a Ruby script. The code we were working with did the following:

1
2
3
4
5
6
7
8
9

require 'dl'
def show_message_box(message, title)
  mb_ok = 0
  mb_iconexclamation = 48
  
  user32 = DL.dlopen("user32")
  message_box = user32['MessageBoxA', 'ILSSI']
  message_box.call(0, message, title, mb_ok | mb_iconexclamation)
end

That works well until you need to display Unicode characters in the MessageBox. It turns out the MessageBoxA version of the function is for ASCII characters. There is another version of the API call, MessageBoxW, that can handle Unicode, or wide characters. So the issue becomes converting your Ruby string into a wide string so it can be passed to MessageBoxW. The MultiByteToWideChar Win32 call can do this for you. And the windows-pr gem (from win32utils) adds a nice ruby wrapper around the function.

gem install windows-pr

1
2
3
4
5

require 'windows/unicode' 
include Windows::Unicode 
$KCODE='UTF8'

str = multi_to_wide("This is a test")

This seemed to work quite well for the most part. However, from time to time we would see garbage text showing up at the end of our messages. It could easily be reproduced if the message was very short.

Having done enough C/C++ coding to recognize a string that was not being null terminated, we experimented with adding null characters to the end of the string. It turns out a wide null terminator (”\0\0”) is needed. The following code will properly display Unicode characters in a Win32 MessageBox:

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

require 'dl'
require 'windows/unicode' 
include Windows::Unicode 
$KCODE='UTF8'

def win32_wide(text)
  multi_to_wide(text) + "\0\0"
end

def show_message_box(message, title)
  mb_ok = 0
  mb_iconexclamation = 48
  
  user32 = DL.dlopen("user32")
  message_box = user32['MessageBoxW', 'ILSSI']
  message_box.call(0, win32_wide(message), win32_wide(title), 
                             mb_ok | mb_iconexclamation)
end

show_message_box "MessageBox displayed from Ρουμπίνι", "¡Alert!"

Allan Kelly draws some interesting conclusions about Agile software development methods as related to forming business strategy. The impetus for his post was a piece in the MIT Sloan Review entitled “Should you build strategy like you build software?.”

From Allan’s “Make strategy like you make software?”:

...for companies which use a lot of technology software and strategy are increasingly converging. Ultimately your software is your strategy – so much so that I sometimes imagine software code as liquid strategy.

...many of the practices and techniques used in Agile software development can be applied to strategy formation and execution. McFarland focus on techniques such as small iterations, collective ownership, overlapping phases, direction changes (i.e. refactoring), organising around people not tools and abolishing big up front design.

It is not only software development where managers and companies have suffered from the Illusion of Control it occurs in strategy formation and planning. Strategy formation is an emergent process, in the same way that software design is emergent.

More client news:

The idea came to Rick DeVos while he listened to church leaders describe how they were going to use email to help people get involved in church activities.

“It seemed like a nightmare of useless emails filling up everyone’s mailboxes, and an administrative nightmare,” DeVos says. The more he thought about it, the more he realized there was no online tool to help organizations connect people in need with the people who could help.

So DeVos talked to Ben Gott and the two created TheCommon.org, an online site that helps people lend a helping hand.

Grand Rapids innovators develop online ‘helping hand’

Client news:

So far the 2-year-old firm based out of Franklin has three full-time employees and has raised more than $1.3 million in seed money from venture capital firms and angel investors.

CircleBuilder, which offers Yahoo Groups-like services to churches, is about to bring in another “big chunk of change” as it prepares to close another round of seed money investing. The firm hopes to open its site to the general public this summer and hire 15-20 people by the end of next year.

“I am trying to do all of my business in Michigan,” Brown says. “My lawyers, CPA and technology firm [that’s us! -ed.] are in Michigan. You have got to start something in this state because we’re too reliant on the auto industry.”

CircleBuilder paces its growth, looks to add 15-20 jobs in two years

Rails convention calls for test data to be stored in fixtures. This works very well for the first few iterations, but this approach quickly becomes unwieldy. Often, many records are required, which can lead to poor record names like event_46. Even when naming conscientiously, it’s difficult to give each record a meaningful name in a global scope. When adding required fields to models, every record needs to be updated, which can be tedious for large test data sets, and very often the updates have an undesired impact on a broad set of tests.

We’d prefer to build up test data closer to home, in the test itself, so we can see the connection between the data and the expectations. Furthermore, if we structure our tests this way the data is isolated from other tests so we’re free to tinker with it without breaking those other tests. The drawback is that manual creation of ActiveRecord objects in your test code can become as tedious to write and maintain as fixtures.

Enter Generate – a technique that centralizes ActiveRecord model generation for test data, removes the need for fixtures, and avoids the tedium and verbosity of in-test model creation.