Lost two of my heros

This month I lost two of my heros: Steve Jobs and John McCarthy. As a child, I dreamed of being Steve Jobs. I admired him for what he accomplished and his impeccable showmanship. I learned so much from him and his vision. I'm sad that I will never be able to meet him.

When I got older and learned about how Xerox Parc and John Engelbart inspired the Mac, I found Lisp. My love affair with Lisp goes back to college when I didn't quite understand it, but thought it was strange yet elegant. The light eventually went on and the true power of macros and functional programming was eventually revealed. To this day, there is a source of amazement that comes with Lisp and I thank John McCarthy for that. I wish I could have met him as well.

I can't express how I much these men touched my life without ever meeting them. They both hit the ball so far out of the park that they will be revered for generations to come. The bar has been set and I plan on standing on their shoulders. Thank you.

The days of templates are over

When I first started to work with web applications, it was just servlets and then came JSPs. At the time, I didn't like JSPs (and to this day I still don't). They seemed like a necessary evil that got the job done. The thing I found repulsive about them was the mix of server and client code together. The switching of contexts just made both look ugly and hard to maintain. But, it was easier than generating pages directly from servlets by hand. Of course, there were other solutions that I looked for, but nothing got away from the horrid markup. Then, I fell in love with Seaside which did away with markup and generated content through a custom DSL. It felt better to me and loved it until I realized that it was only for the developer, not the web page designer. It made their life harder. Now, we all know we should use minimal content and have CSS do the layout. But, in this modern world, you need folks who are experts at web page design. You can not and should not alienate them.

Fast forward to now. Currently, I've been using Javascript frameworks and working mainly from the front-end. The project I'm currently working on is pure HTML/Javascript/CSS for the front-end with RESTful calls to the backend. I must admit, I had my reservations about this arrangement, but after working with it; it is the right thing to do. No more ugly markup. The separation of concerns is well in place. And finally, the web designer is allowed to concentrate on making a rich user experience and the developer to concentrate on business logic. Perfect.

My feeling is that the days of template engines are over. It's a waste of time and all of them are a pain to debug. A pure Web 2.0 AJAX solution allows each to utilize their tools and do things separately. To me that is exciting and I will gladly leave ugly code behind.

App Dev Today

I'm pleased to announce the start of a new venture. It's a new company to launch new mobile applications. The ball is just starting to roll and exciting times are ahead. We have some cool stuff up our sleeves and will be showing soon.

Easier Memory Release In Objective C with Blocks

I've been getting my head around Objective C recently and remembering all that is great about about manual memory management. I found myself repeating code that either a) autoreleased or b) released with try finally loops. The autorelease puts a drag on your pool so you want to use it sparingly (with APIs where you don't know who will be calling it) and it's mentioned in several places in the Apple documentation to favor "release" over "autorelease". So, that leaves me with option b in most of my code with a lot of boilerplate code. And I hate boilerplate code. Well, did some more reading and found out that blocks are a new thing in Objective C and I quickly whipped this up:

typedef void (^Monadic)(id value);
typedef id (^Niladic)();

-(void)use: (Niladic)calc during:(Monadic)monadic {
    id toUse = calc();
    @try {
        monadic(toUse);
    }
    @finally {
        [toUse release];
    }
}

Basically, it allows you to send in one block to get the allocated object and then use it in a try finally. It automatically cleans up after itself! I then decided to try it out on some code:

-(IBAction)calculateClicked:(id) sender {
    [self 
     use: ^() { return [[Cents alloc] initWithString: [startView text]]; } 
     during: ^(id startAmount) {
         [self 
          use: ^() { return [[Cents alloc] initWithString: [eachYearAmountView text]]; }
          during: ^(id eachYearAmount) {
              [self
               use: ^() { return [[NSDecimalNumber alloc] initWithString: [interestView text]]; }
               during: ^(id years) {
                   Cents *answer = [startAmount
                          atRetirementAdd: eachYearAmount 
                          earning: years 
                          for: [[yearsView text] intValue]];
                   [resultView setText: [answer description]];
               } ];
          } ];
     } ];
}

I think I made it too generic in that I now have to type "^() { return [blah blah blah]; } every time. I realized I could get rid of those blocks and just pass in the object I want to clean up. Remove Niladic block and take two looks like this:

typedef void (^Monadic)(id value);
-(void)use:(id)toUse during:(Monadic)monadic {
    @try {
        monadic(toUse);
    }
    @finally {
        [toUse release];
    }
}

And this is what it looks like when you use it:

-(IBAction)calculateClicked:(id) sender {
    [self 
     use: [[Cents alloc] initWithString: [startView text]]
     during: ^(id startAmount) {
         [self 
          use: [[Cents alloc] initWithString: [eachYearAmountView text]]
          during: ^(id eachYearAmount) {
              [self
               use: [[NSDecimalNumber alloc] initWithString: [interestView text]]
               during: ^(id years) {
                   Cents *answer = [startAmount
                          atRetirementAdd: eachYearAmount 
                          earning: years 
                          for: [[yearsView text] intValue]];
                   [resultView setText: [answer description]];
               } ];
          } ];
     } ];
}

As long as the Monadic blocks stay on the stack we don't need to do the copy autorelease business on block objects. I like this code better than nested try finally code because I'm not repeating the name of my variable to release in the clean up code. I'm still not 100% happy with the code, but I'll keep playing around with other things until then. I do like the fact that it is simple. Just something I wanted to share as I learn Objective C.

Singleton Pattern in Dojo

Recently, I needed to have a singleton object. So, I came up with the following implementation to give me just that.

var makeSingleton = function (aClass) {
    aClass.singleton = function () {
        var localScope = arguments.callee;
        localScope.instance = localScope.instance || new aClass();
        return localScope.instance;
    };
    return aClass;
};

When declaring my class in Dojo, I did the following:

makeSingleton(dojo.declare(...));

Then, to use it:

var instance = myClass.singleton();

I like the fact with this implementation that it's obvious that I'm creating a singleton object up front around the dojo.declare. Of course, there's nothing preventing someone from creating the class with new, but we could easily get around that with throwing an exception in our constructor after our singleton has been initialized.

Functional Programming In Python 2

I gave a talk this month to the Tampa Bay Python User Group on functional programming in Python. It's actually the second part of the talk. I've put the slides up for all to enjoy here. If you have any questions or complaints, feel free to contact me. I welcome all comments.

Collaboration Not Pairing

One of the tenants of Extreme Programming is pairing on all production code. At first, it seems to make perfect sense. Four eyes on all code is better than two, right? There is another partner to help solve issues, take over when one is tired, and to keep each other honest. What could be wrong with that? Plenty. I feel that pairing is good in spurts of time or as I like to say, "Collaborate not pair".

I want someone to help me on the hard problems. I don't need someone peering over my shoulder to make sure I'm coding a for loop correctly. I think big picture. I want a pair to help with the design and make sure it is sound. The physical act of coding might have some hard problems too and I would like a pair for that as well. But, for the mundane boilerplate code, I don't need to watch someone type that.

I believe you need a mix of alone time on a problem and together time to exchange ideas. Pairing constantly stops that and it's easy to fall prey to a stronger partner's ideas even if those ideas are bad. The stronger personality wins. This should not be the case. But, I've seen it many times on XP projects. A pair put into production code that was clearly not good and hard to maintain. The very thing pairing is supposed to prevent.

This doesn't mean I don't want four eyes on all code either. I think a collaborator should read over every line of code that is written in isolation and ask questions. This is where time away is helpful. The partner brings an outside perspective than if the pair was sitting side by side. This prevents group think or one partner overbearing another. There's also the case where some developers are intimidated working with someone all of the time. They need to have space to properly think. These developers can be prone to letting a stronger partner always have their way. Again, not what we want.

As you can see, I'm not against pairing, but against constant pairing. Collaborate when necessary and make sure to leave time to think in isolation. You need both. You can't be all one side or the other. Either one all of the time is not healthy. But, how much collaboration versus alone time is needed? This is where you have to use your best judgement. Agility is about thinking and finding the right solution for the right situation. It's not a one size fits all world.

Domain Driven Design Immersion

I've been meaning to write about my experience at the Domain Driven Design Immersion training that I took back in November. But, I've been so busy that I haven't had the time to put down my thoughts on it properly until today. First off, I had a great time; met many wonderful and intelligent people; and learned quite a few new techniques. Just given that, it was well worth the time. The course was simply fantastic.

I read Domain-Driven Design when it first came and fell in love with it. I've read it several times and consider it one of the greatest books on design. It's a tome of knowledge on being practical in design and getting closer to mapping user language to code. There are no silver bullets, just great advice and a road map of thought to get there. Despite the book being well-written, there were questions I've had when applying DDD throughout the years. I jumped at the chance to spend a week immersed in DDD and learn a few more tricks.

The training was excellent: well-paced, interactive, and loads of discussion. DDD is something that you must practice and the training provides a lot of it. From hands on coding to white board design sessions, you get your mind in the middle of the whole process. The trainers guided discussion and encouraged us to be creative in our solutions: messy whiteboards are good! I've been to a lot of training and seminars. Normally, little thought was given to pacing of the material. This was not the case with DDD Immersion. I felt there was an excellent mix of lecture, hands-on, and discussions. Each day felt like it went by too fast. Four days is not a lot of time to cram the amount of material that the DDD book covers, but the course materials provided abbreviated documents to bullet point the important ideas. I personally thought the materials made the course all worth it.

Even if you have read the DDD book, I still think the training is worth it's weight in gold. I work with Eric on his Time and Money library and I still got new ideas out of it. The training does add new material to the book and expands on Eric's new ideas concerning DDD.

The one thing that I took from the training is it's all about practicing to get better at design. Eric has laid out a path of thought on design. It still takes ingenuity and playing around with ideas to be successful. Design is a creative process and it takes hard thinking to match the language of users into code. The training brings that home. I whole heartily recommend the training and would go again given the chance. The real world keep giving me problems where questions arise to the best way to tackle them. You can never stop learning.