The more I code in Smalltalk, the more I find the flow of developing in Ruby annoying. What I really miss is a good way to navigate code, the debugging facilities and the runtime aspect of a Smalltalk dialect.

Code navigation

The browser is the standard way to browse code in Smalltalk. While it can be seen as cumbersome and ugly (in the look and the feel) compared to a native UI or a text editor, experienced smalltalkers have a love-hate relationship with their browser.

When using it, you do not need to have 45 tabs opened in your web browser. Almost all the documentation you need is right there in front of you. Browsing the senders and implementors of a method is so easy and convenient. When you come back to a text editor and Ruby code it’s just a pain in the ass to perform changes in your code.

As a developer you will spend (by far) much more time debugging and reading code than writing it, why not have a dedicated tool to browse it ?

Runtime

One of the most frustrating point when developing in Rails is how slow it becomes when your Gemfile grows. Running the test suite is so slow, it feels like the old ‘code-compile-run’ cycle is back again. It’s not the tests that are slow per se but loading the environment. Each time you run a test, you wait for Rails to start while the actual time spent in the test(s) is negligible. Very frustrating when doing TDD.

There are some tools to overcome this problem but it’s sometimes quite hard to get them working (more on this in a later post).

Debugging

Take the browsing tools and the always-runtime feature and you get easy debugging. The TDD flow get much better when you can create methods on the fly, navigate the stack and change the state of your object on the fly. In Rails, I’m used to run the test, see it fails, switch to my text editor and re-run the test. Tools like Pry makes things much more smooth but they are quite far from a live debugger.

Closing

This post is already far too long for and probably not very well illustrated but I hope you get the idea. I’m not saying that Smalltalk is better; all the goodness mentioned before have their drawbacks, mainly when it comes to deployment. As your code is always running, it can be quite cumbersome to deploy it on a server in a fresh state. There are tools to help but they are not as nice as what you get in the Ruby world. A lot of smalltalkers seem to have their own recipes to deploy. It can be quite disturbing for someone coming from Ruby.

Anyway, I gonna try to illustrate my arguments in the next posts. Thanks for reading !

Web development is a quite hot topic for developers these days. Some think that the web is the future and that native apps are a relic of the past. I would not say that it is that simple (iPhone/iPad apps anyone?) but it is clear that webapps work well for many tasks.

Some years ago frameworks started to appear in order to facilitate the development of web applications. They promise faster development time, more robust application and easy maintenance. We all know that a silver bullet does not exist in software development but it's kinda funny to see what all those frameworks promise. Here are some excerpts from some website of them.

Spring (Java)

Spring delivers significant benefits for many projects, increasing development productivity and runtime performance while improving test coverage and application quality.

CakePHP (PHP)

CakePHP enables PHP users at all levels to rapidly develop robust web applications.

iliad (Smalltalk)

Iliad is a Smalltalk web application framework. It is designed to be simple and make web development as effective as possible.

Catalyst (Perl)

Catalyst will make web development something you had never expected it to be: Fun, rewarding and quick.

Symfony (PHP)

It [Symfony] provides an architecture, components and tools for developers to build complex web applications faster.

Ruby on Rails (Ruby)

Ruby on Rails is an open-source web framework that's optimized for programmer happiness and sustainable productivity. It lets you write beatiful code by favoring convention over configuration.

Pylons (Python)

Pylons is a lightweight web framework
emphasizing flexibility and rapid development

Django (Python)

Django makes it easier to build better Web apps more quickly and with less code.

Seaside (Smalltalk)

Seaside provides a layered set of abstractions over HTTP and HTML that let you build highly interactive web applications quickly, reusably and maintainably.

Wow with all those promises, you have no excuse to deliver crappy webapps. I like those headlines have no meaning at all. Do not trust someone who is pretending that everything will be easy with his tool/framework. Except when the tool in question is Clojure or Smalltalk of course :)

Interacting with a well design API is a pleasure. When an interface is consistent and works in the way I expect it to work I feel good. Gregory T. Brown wrote an excellent chapter on this subject in his (now freely available) book 'Ruby Best Practices'.

Something struck me in jQuery last week: map() and each()'s parameters.

From jQuery's documentation:

.map( callback(index, domElement) ) .each( function(index, Element) ) jQuery.each( collection, callback(indexInArray, valueOfElement) ) jQuery.map( array, callback(elementOfArray, indexInArray) )

Ok, what's the deal ?
Look at the parameters of the callback of jQuery.map(). The order is different than all the others. Why?

This kind of things drives me nuts.