Archives

I began 2007 as a front-end tech lead on a multi-million-dollar software project for a global travel company with a massively distributed waterfall development model. I ended it working in small, agile teams on R&D projects at a small outsourced software shop. I got involved in open source, became (yet another) tech blogger, and set in motion lots of other writing and speaking projects for 2008. It’s been quite a year.

I’m sure everybody is sick of year-end lists at this point, so let me present a slightly more personal and highly subjective list of the five most important things I learned this year about software development and technology writing:

Share/Bookmark

Every so often, someone scrawls a manifesto about why closed source is good and open source is bad. Usually the parties involved are technical ignoramuses (like in this Economist article) or industry hatchet men. But Jaron Lanier should know better. He isn’t a hatchet man and is far from a technical ignoramus, yet he engages in the same sort of sloppy thinking that characterizes those other brain-stain graffiti artists.

His article for Discover Magazine, entitled Long Live Closed-Source Software!, is a case study in bad examples in the service of a simple argument. His argument goes as follows:

1. Open Source == Linux
2. Linux is a derivative if qualitatively better version of the closed-source UNIX.
3. Therefore the open source movement can only produce derivative works, and nothing as breathtakingly revolutionary as the iPhone.

He goes on to speculate about some of the causes for this failing, likening closed source to cell walls that help organisms differentiate and speciate. Open source, by contrast, is like the primordial goo.

Share/Bookmark

I’m working on a small project and trying to use RSpec as the complete testing solution. First thing I did was copy over an existing custom FormBuilder which puts everything in a nice tabular layout. Then I tried to convert the existing Test::Unit tests to RSpec specifications.

I banged my head against this for a few hours, at least partly because the normally-infallable Google-based tech support failed to expose a clear example. So I figure I should at least get a blog post out of it.

The form builder is technically a helper, so it goes in app/helpers, and the test goes in spec/helpers. One problem — the custom form builder expects to have access to template object and calls content_tag on that object to format the output. Normally, the template object is automatically placed in @template during evaluation. But since RSpec is testing just the helper, and not an associated controller or view, there is no template object.

At first I created a mock template object that just imported the relevant Rails helpers, but then I actually read the documentation in more detail and learned that the RSpec HelperExampleGroup class, which manages helper tests, already imports all those helper modules. So, I can set up my specs like this.

before(:each) do
@object = mock_model(Project)
@object.stub!(:longname).and_return("Long Name")
@builder = TabularFormBuilder.new(:project, @object, self, {}, nil)
end

The first two lines of this just set up a mock object. The key line here is the last one, where the form builder is created with arguments representing the model, the instance, the template, and then options. The template is represented by self, meaning the RSpec HelperExampleGroup, which will respond to content_tag.

Now I was able to write all my specs against the template and use the have_tag and with_tag predicates to validate the output, like so:

it "should build input fields" do
@builder.text_field(:longname).should have_tag("tr") do
with_tag "td.tdheader"
with_tag "label[for *= project_longname]", "Longname"
with_tag "td" do
with_tag "input.text_field#project_longname[name *= longname][size = '30'][value = 'Long Name']"
end
end
end

One other nice feature of the helper specs in RSpec is the ability to directly evaluate ERB. This is designed to be used for validating helpers that take ERB blocks as arguments. Use as follows:

eval_erb("<% table_form_for (@object) { |f| f.text_field(:shortname) } %>")

The method being tested looks like this — it wraps a form inside an HTML table so that the custom form builder’s table layout will render properly:

def table_form_for(name, *args, &proc)
concat("<table>", proc.binding)
form_for(name, *convert_args(TabularFormBuilder, args), &proc)
concat("</table>", proc.binding)
end

The eval_erb method returns a string, which you can then validate. Note that if you are using it to test a form_for derivative like this, you also need to place the following stub method in your spec file’s describe block:

def polymorphic_path(args)
"http://a.fake.url"
end

The polymorphic_path method is used within Rails to convert something like form_for(@object) to the RESTful URL that the form should be submitted to. Normally it’s an method of the controller, but in the RSpec helper environment, there is no controller.

There’s another issue when validating this form builder. Unlike a typical ERB block, the custom form builder implementation of f.text_field explicitly uses the template object to write output. The eval_erb method does not seem to work as I expected in this case — the output from inside the block does not appear to be saved.

In other words, when running the eval_erb call above, the resulting string contains the table tag created by the table_form_for method, and the form tag created by form_for. The table rows that are built by the custom form builder itself, however, do not show up in the output. I was able to verify that the output is being generated, so either it’s not being stored by the RSpec object, or I still haven’t completely figure out how to tie these things together yet.

If you found this example helpful, you might also enjoy my upcoming book Professional Ruby on Rails, scheduled to be published in February, 2008.

Share/Bookmark

I’m sure you’re familiar with Duck Typing, in particular as espoused in the Ruby world: “If it walks like a duck and quacks like a duck, I would call it a duck.” Nothing is an unmitigated good, but Duck Typing, or designing against interfaces, is generally a good thing. It allows you to abstract away the implementation details, which is a very good thing in the OO world. One thing missing from Ruby, however, is Dead Duck Typing, i.e. when you cook the duck in the oven, you probably don’t want it walking and quacking.

Why wouldn’t you just have a different class or object, a “Roast” object that you construct when you kill a duck? Well, you might want to do that, sort of like a “Duck Transfer Object,” or DTO. But in some cases, creating a separate object, just so it can be used in a different context, adds unnecessary complexity to a system. Take the example of an accessor in Ruby. I may need to give some other Class the information on how long to cook the duck and at what temperature, but do I need to give that to the pillow manufacturer who is only interested in the feathers?

Paddling away from ducks for a moment, think of the typical business and persistence layers in an application. In the persistence layer, the implementation details need to be exposed, in the business layer, they really shouldn’t. In Ruby, you can’t hide methods in different contexts, so you end up with cluttered interfaces — monsters instead of ducks — that rely on good programmer behavior to prevent tight coupling and low cohesion from creeping in (see the GRASP patterns). Instead, we want High Cohesion, i.e. all of the methods of a Class should focus on one or at most a few responsibilities.

Some will argue this is a Java-ism creeping into Ruby. I say this is just plain old-fashioned good OO design.

Technorati Tags: ruby, OOAD, GRASP patterns, Duck Typing

Share/Bookmark

Oh, we’re doing predictions. Sure:

1. The blurring between desktop and web applications will continue. Especially watch for desktop applications specifically designed to enhance one specific web site (like the Mac applications Twitterrific and Mailplane). There are at least two other efforts to allow you to easily bundle an arbitrary web site into something that acts like a desktop app. I agree that Google Gears-like functionality has a strong place here.

2. On a related note, I’m kind of taken with the new Remember the Milk Firefox plugin, which adds GMail integration. It’s a plugin that assumes a specfic browser and ties together two web apps. Using the browser as the clearinghouse for tying together disparate web data feels like something I expect to see more of.

3. GWT will make some headway in porting existing Java apps to the web, but much of this will be on internal networks, so it will kind of slide under the radar. I don’t see it picking up vast numbers of new developers who aren’t already committed to a Java/Swing structure.

4. One of the zillion or two desktop app suites will go under, prompting some panic for people who have stored documents there.

5. For the Rails community, I expect the big issue for 2008 will be dealing with success and growth (RailsConf 2008 has more proposals for speakers than RailsConf 2006 had participants…). The tension is along the axis of developer efficiency vs. enterprise-y performance. Look for more attention to fall on smaller, more specialized Ruby frameworks like Merb.

6. On a more technical level, I expect (or maybe more accurately, hope) that there will be some attention paid to improving the Rails view layer. Possibly a consensus on some kind of Presenter or Decorator pattern.

7. My book, Professional Ruby on Rails, will be released. You will buy a copy. (Hey, I can hope…)

Share/Bookmark

As promised earlier, here is Markdown support in GWT.

1) Grab Showdown
2) Copy ‘showdown.js’ to the ‘public’ directory of your application.
3) Edit your module file:

    <module>        <!-- .... -->        <script src="showdown.js"/>        <!-- .... -->    </module>

4) Use JSNI to invoke Showdown.

    public static native String convert(String text) /*-{        var converter = new $wnd.Showdown.converter();        return converter.makeHtml(text);    }-*/;

5) Invoke ‘convert()’ as needed.  In my case, I wired it up to a KeyboardListener attached to a TextArea, and had the results placed on an HTML object.

And yes, it’s that simple.

Share/Bookmark

If you haven’t been able to tell yet, I like Groovy.

I was playing around with enabling some Markdown support in GWT (attempting to use Markdown-J from inside a TextArea instance widget).  Because Markdown-J relies on java.util.regex classes, it can not be invoked directly by GWT. I decided to take two approaches– the first being to invoke the Markdown-J processor via an RPC call, and secondly to do it all on the client-side (which I will address later).

The first approach meant I could do some interesting things along the way in Groovy.  First off, I wanted to extend the Markdown processor to support table markup similar to, say, a FitNesse test (i.e turning markup like this):

|com.some.fixture.DummyTestFixturePlusOne|| input | expectedOutput? || 10    | 11              || 44    | 45              |

Into HTML output like this..

Or other alternate (possibly interactive) representations of tabular data using GWT, if you get my drift (but that’s another show).

The implementation of Markdown-J is relatively straightforward.  It makes heavy use of regular expressions (java.util.regex can not be referenced by GWT), and thereby serves as a good illustration of the paradox of regular expression support in Java:  You can get the job done, but it’s rarely nice to look at.  Groovy makes it so much better.  Here’s my first attempt to extend Markdown-J’s “MarkdownProcessor” class from a Groovy class.  Nothing special up my sleeve here.

class MarkdownProcessorWithTableSupport extends MarkdownProcessor {
    private static final tableRegex = /\|([\d \w\.]+)\|[\n\r](.*\|)(?:[\n\r]?[^\|])/

    public TextEditor runBlockGamut(TextEditor text) {
        TextEditor editor = super.runBlockGamut(text)
        String content = editor.toString()

        content.eachMatch (tableRegex) { match ->
            String headerRow = match[1]
            String tableContent = match[2]
            // do something with this match..
        }
        return new TextEditor(content)
    }
}

This is enough code to extract the first two match groups in the regex and start doing something with them.  The only real item of value in this class is the regular expression.  That regex took me a bit of time to nail down, so obviously it’s rewarding to have it represented as closely as possible without any of the double-backslash marks you find with Java strings.  Notice that Groovy avoids the ‘\\’ hell when describing regular expressions with it’s “slashy” style strings.  ‘tableRegex’ is still a String, you see.  But unlike the double-quote delimiter, the ‘/’ delimiter allows things like unescaped backslashes.

Other than the regex, everything else in the code is rather boilerplate (iterate over each match, generate some HTML markup, yadda yadda… you get the idea).  Take note of the ‘eachMatch’ invocation on my String content though.  There’s more going on than you might imagine– Groovy actually takes the regular expression and compiles it down to a java.util.regex.Pattern instance before evaluating the closure.  Isn’t that nice?  After all, it’s what I would have done in Java anyway.

What’s next?  I think it makes sense to try something like Showdown and bake it into a GWT component.  This will be my first attempt to integrate some existing JS library and see how nicely it will play with GWT.  Stay tuned.

Share/Bookmark

I took time out this Christmas season to reformat my hard drive. Yes, it seems pitiful when you work with these machines all day, and have a chance to spend quality time with loved ones how machine maintenance would top the list of things to do. However, it did give me a chance to mull over a bit of design mystery which seemed a decent enough present to share with you all. Cozy up to the fire and let me tell thee about Windows Vista.
Being a Mac user, I do have a generally favorable impression of the Redmond efforts, I have a healthy background in their CMS system Sharepoint, and felt as long as you keep up to date on their latest and greatest (read beta) releases, you can almost forgive them for not being more mac-like. So armed with my copy of parallels, I installed versions of XP and Vista, and when my hard drive went belly up I decided to keep just the Vista version. Vista has a great deal of interesting abilities. I am a big fan of the voice dictation software/interface. In a quiet room, it is almost faster than typing. I think the paradigm of the ‘explorer bar’ is pretty well conceived mashup of a breadcrumb menu plus drop-downs. I’m surprised not to see a web version of this, since it really does have a fairly good affordance to the user of traversing a deep directory structure.

What really bothers me about the switch is the overall ‘blueness’ of the interface. It’s relentless, and of course being good web 2.0 citizens, they got their gradient on, so its basically blue gradients for miles. Now, giving them credit, aqua (mac os x’s first scheme) had the same problem, blue gradients for days, and the extraneous grey pinstripe thing, but yet it didn’t seem as gratuitous as Vista. This is coupled with the inability to ‘go grey’ as XP used to allow. So, by redecorating, vista has ‘painted’ itself into a corner, unless users are expected to select their own gradient mixes (yellow to orange, puce to purple) they are somewhat stuck with blue. Also knowing microsoft, these are just bitmaps, so no redecorating is possible without replacing a bunch of .BMP’s someplace deep in the WIN32 folder.

At the same time, Apple’s Leopard has removed all hints of ever styling the chrome of their windows, even the pinstripe thing is removed and has gone all grey. They have also been having some fun with drop shadows (the ‘other’ gradient), in early beta’s, and in Steve’s intro speech, they spoke of how active windows really stand out. That was because active windows had about 100 pixels of drop shadow built in – which they wisely dumped. Overall, no color seems the best choice, in a black text on grey world, it tends to de-emphasize things well enough to let the user focus on the content at hand, photos, and clickable things (hopefully blue).

So, overall, why blue? If we look to web design, its pretty much the default color. It is hard to find a site that does not use blue as a background or decorative accent. Of course it is the ‘real’ clickable link color, and it is the color of azure sky in deepest summer, which is not a bad thing at all. In fact, since red is out, and yellow is kind of tricky, you pretty much have blue as your only possible primary color choice. However, color wheel not withstanding, it is hard to understand why blue has so much power over our virtual lives. About.com claims it’s the color most preferred by men. It is also peaceful, tranquil, and productive. It is the least appetizing color- perhaps why foodtv chose green?

Perhaps web 2.0 has brought a reaction to this overall blueness, noting ebay has gone with yellow, but there will still be a strong reason to pick blue, it’s like choosing IBM (pun intended) or the reason Microsoft is still the best choice for many reasons, nobody got fired choosing blue. Every other color has strong emotions tied to it, and neutrality (read grey) while being most suited to ‘new’ web design tends not to excite people too much. I actually have a difficult time finding a site where blue is not the predominant non-meaningful color. So, while I’m scouring google scholar for some actual research statistics on this phenomenon, please leave your comments on what interfaces sucessfully break this blue flu, and have a happy 2008!

Share/Bookmark

I’m a little early this year for my 2008 predictions. No matter. I seem to have been a bit early with my 2007 predictions as well, and as they say in the venture capital biz, “too early is the same thing as wrong.” Some of my predictions did come true — Ajax is no longer such a big buzzword; a number of framework specific books (GWT, jQuery) have been published at the end of 2007; Microsoft’s Ajax stack continues to limp behind the rest. A few others did not, notably the ho-hum release of IE7 and the delay in FF3. So, let me try my hand at some more prognostication:

1. Elegant, good looking frameworks like Ext and myGWT will gain traction. The more out-of-the-box good looks you can give them with CSS and bundle images and icons, the more acceptance they will gain.
2. The JavaScript framework chaos will continue. The OpenAjax alliance will continue to be ineffectual in promoting things like widget interchangeability.
3. Security will become a big headache, as less sophisticated developers start to venture into the wonderful world of Ajax, littering the web with state and control logic on the client side.
4. Towards the end of 2008, FF4 and IE8 will start to change the landscape of Ajax and Web 2.0 with an update of JavaScript and new browser features.
5. MS Volta will do nothing. It is just a FUD shot across the bow of GWT.
6. Everyone except Craig’s List will have some form of Ajax on their site.
7. Desktop RIA’s through Google Gears, Adobe AIR, etc., will start to make an impact in the second half of 2008. Look for desktop/web hybrids of the office productivity tools, such as word processors and Powerpoint clones, to see greater use in the corporate IT space.
8. GWT’s compiler will produce more efficient code than 98% of JavaScript developers can do by hand.
9. With the new browsers, a cross platform Canvas/SVG will be a reality by the end of the year.
10. IE8 will still leak memory like a sieve.

Have any of your own predictions? Feel free to add them in the comments.

Technorati Tags: ajax, 2008 predictions

Share/Bookmark

When a company gears up to redesign its website, the question of screen resolution always seems to eat up tons of time and energy. Despite the long, slow evolution of the browser from a publishing medium to an application platform, many developers still think in terms of "web pages" – large units that require, if not fixed dimensions, then at least a fairly defined range of viewport mins and maxes. Rather than thinking of the browser window as an operating system full of work spaces, palettes and menus, we think of it in print terms, like a newspaper page full of columns and sidebars. This occurs despite a decade of education to the contrary from any number of software and visual design experts.

Share/Bookmark