Technovangelism

Not trying to kill anyone, but here is the refresh my blog so badly needed. The old theme made it far too difficult to find the RSS feed link. I typically use the special Firefox or Safari link to grab the RSS url, but finally realized Chrome does not do this, so a link that is a little more in your face will fix that.

I did not do anything fun to design, but have been planning this for quite some time. I drew a lot of inspiration from the lightword theme. Feel free to comment and tell me if it does not look right in Windows or IE.

At JavaOne, I attended a session given by David Pollak the creator of the Lift Web Framework. In his hour session David built, from scratch, a functional, comet-based chat application. Although short, and relatively simple, David’s talk was compelling enough for me to at least investigate Lift.

I purchased The Definitive Guide to Lift while at the conference and was able to read (note I didn’t say understand) through most of it on the plane ride home. One chapter deals specifically with adding AJAX and Comet to your application enabling push support. It covers almost everything needed to complete the Comet app but it is missing a few important lines, most notably the call to start in ClockMaster.scala.

I posted a fully working copy of the code on Github for anyone trying to use the code from the book. Hopefully it will help anyone else who got stuck in the same place I did.

I have been reasonably happy with Webbynode, where HappierHour is hosted, both in functionality and service and was happy to see some new features the last time I logged in. While poking around the new pages, I found this on the “Close Account” page:

Bad dialogs and button combinations have always existed and will probably continue for quite some time, but this one surprised me coming from Webbynode. It is not so bad, but I am disturbed by “Otherwise, click cancel.” There is not a “Cancel” button, and the only button with the word cancel on it does the opposite of what the user wants.

Luckily for Webbynode, it is probably not an oft-visited page, but one accidently canceled account will make it an expensive mistake.

In the first chapter of every beginner’s Java book, the reader is introduced to code like this:

public class MyClass {

    public static void main(String[] args) {
        System.out.println("Hello world!");
    }
}

Its simplicity is important to not discourage the reader and its brevity allows for quick and continuous enhancement. But within the first line, it has started the reader down the wrong path in what is considerably more important long term.

Later, a code snippet like the following might be used to explain some features in greater detail:

MyClass myObject = new MyClass();
myObject.myMethod();

Again, the deterioration of good programming skills has started before those skills were allowed to develop.

Why are beginners taught these bad habits when it is just as easy to teach with proper programming styles? The use of the prefix “my” does not provide any insight to what that class/object/method actually does. Despite the difficulty of naming things, it is far better to demonstrate good programming practices and have a 90% intuitive name, than to have a name that is simple but meaningless.

Java is the most notorious for this, but other languages are equally guilty. If you are writing a tutorial somewhere, especially if it is for beginners, take extra care to ensure your code is portraying proper style, so first-time programmers will not have to dig themselves out of any deeper of a hole.

When developing a software project in a short amount of time (less than 6 months), demonstrating often that you are providing value to your customer is essential. Of course it is important for long-lasting projects, but if you only have three months to complete your project, you cannot afford to miss a demo.

I have learned this over the last two major software projects I have completed. On both projects, the team did not just “demo often,” but we demoed every week. (When you only work 2 hours a day, that is a bigger feat than it might seem.) We were not following the extreme programming methodology or specifically trying to program quickly, we simply found that we could provide enough value in one week’s time that it was worth presenting to the customer. These constant demos had some other beneficial side effects like keeping the build in an extremely stable state. Some people use an automated test suite for that kind of security, but having to demo the code once a week forced us to do more manual user testing that uncovers usability issues that an automated test suite is incapable of discovering.

Agile methodologies preach having shippable code at the end of each iteration/sprint, but how often is that the true outcome? When you demo your code to customers, you are essentially shipping your code. The customer has a chance to look at and try out the code and provide some instant feedback. In the most recent project, we actually did ship the code to the customer each week and they performed their own user testing on site. The amount of benefit gleaned from these each week was incredible and no doubt increased the success of the project. From now on, all projects I am apart of will have regularly scheduled demos in front of the customer or stakeholder. They are that important.

Meta programming is one of the most difficult, but rewarding styles of programming I have ever tried. It comes as second to nature to a language like ruby, but to me, it requires an incredible amount of mental strength to accomplish some of the simplest tasks. My first non-tutorial attempt was for a rails plugin auto_html. I added some of the easiest meta programming one can do; write out new methods as strings and have them transformed into regular methods. From auto_html_for.rb:

  suffixed = raw_attr.to_s + AutoHtmlFor.options[:htmlized_attribute_suffix]
  setter = %|
    def #{suffixed}=(val)
      @#{suffixed} = val
    end
  |
  getter = %|
    def #{suffixed}
      if @#{suffixed}.nil?
        self.auto_html_prepare
      end
      @#{suffixed}
    end
  |
  class_eval getter
  class_eval setter

Everything between %| and | is one string, and then class_eval evaluates that string and adds a new method to the class it is working in. Now that it is all finished, it looks so simple, but it took some effort to get right. What got accomplished with this code block though, is remarkably powerful, but only the tip of the iceberg when it comes to meta programming.

If you need to flex some serious brain muscle, start up irb and start getting meta.

When working in a community that is constantly changing with new features coming out every week, there are a lot of different plugins, mini-frameowrks, and other packages that are worth using in your projects. One can spend more time researching new tools to use than doing actual work. One always hopes the time spent finding tools and frameworks to make development faster will make up for the time lost from not developing.

My latest research involved the testing frameworks for Rails. Although there are plenty of them out there, I focused on RSpec and Shoulda. Besides Test::Unit, they are the two biggest players in the Rails testing world. I could have spent weeks trying to figure out which best fit my needs, but I enforced some time-boxing on myself and refused to spend more than four hours on this. With so few hours to determine which framework is for me, I really focused on the parts that are most important to me. Within those few hours, I finally decided on Shoulda. RSpec may or may not have more momentum behind it, but Shoulda fits the way I think and is (hopefully) the best solution right now.

When evaluating frameworks or plugins for yourself, always remember to time-box. Choosing the right one is certainly important, but spending the right amount of time choosing is just as important. You have to have time before you can start saving it.

In the original implementation of my forum site, times were all displayed as absolute times. The server sits in the Central Time Zone and at least 90% of the users, including me, are in the same time zone. I never found this a problem, until I spent a few months outside Central Time. My first reaction was to let users set their own time zone and then adjust the times automatically for them. Before implementing this, I found this post from http://blog.stackoverflow.com and decided to rethink my plan. Relative times would provide a simple solution to my problem and would help users in the future as more and more move out of the Central Time Zone.

Everything was working great until a few months in, when old posts were marked as made “about 3 months ago.” By itself, this was not a problem, but edited posts are tagged as edited and would read “about 3 months ago and edited about 3 months ago.” Users are only allowed a 30 minute window to edit posts after they are made, so old, edited posts will always read like they were posted and edited at the same time. Fixing this now requires even more relative time. By marking posts as made “about 3 months ago and edited 4 minutes later” I can still provide the important information that a user is looking for, and not have to worry about time zones.

In my latest attempt to fight burnout, I began experimenting with iPhone development. Joining the developer program was no sweat and there are plenty of articles and tutorials online to help you get coding. But the biggest problem when learning a new language or framework is knowing what to code. Building a Hello World application is great and all, but it hardly teaches you anything you want to learn.

My process for solving this perpetual dilemma is to build something that I actually need or want. For my iPhone project, I chose a Power Hour application. Before deciding this was the right project, I had searched for one in the App Store and was unsuccessful. This either means Apple is against such an app (unlikely), or no one has though of it yet. Either way, it is a simple enough that I can code it within a day, and it will teach me far more about iPhone development than a brief tutorial. Unfortunately, getting the app to my iPod Touch requires it to be put in the App Store which requires a $99 fee. Perhaps others would be willing to pay $0.99 for such an app and could cover the cost for me?

Before the iPhone app was started, I wrote a version in javascript as I had an emergency need for one. Feel free to enjoy an hour of it.

Thanks to #30:30:30, my motivation for blogging has increased significantly. The first few (ok, maybe first 15) posts were difficult and I had trouble convincing myself to actually write them. Lately writing has been significantly easier and I am enjoying it and finding some value in it. Now that I am writing consistently I have seen my subscribers climb a little (from 0 to the single digits) thanks to FeedBurner. I have yet to really promote my blog myself; Nate and Nick are doing a good job of that. But if my blog ever does get past three readers, a FeedBurner chicklet might be in order.

What impact does a FeedBurner chicklet have on a blog and its subscribers? If I put a chicklet on this site, I’m guessing it would cause more laughter than new subscribers, but maybe someday it could be of value. What is the threshold for a chicklet to help gain subscribers? Is a blog with 100 readers less enticing than a blog with 10000 readers? 1000 readers? A blog with many readers convinces me that not only has it been around for a while, but it will continue to exist and be updated. Unless the author really enjoys blogging, which he absolutely should, not having many readers is a good excuse to put off writing your next post until tomorrow.