David Bolton Strikes Again

I suspect some Google searcher is going to find this useful one day…

In Rails, render_to_string cannot be used in a view or helper, as it’s an ActionController method, not an ActionView method.  Instead, you can use standard render commands.  But beware, using render :file will set the content type header to the type of the file. Rather, read the file into a local variable and use render :inline.

I’ve just confirmed this in Rails 2.2, and I suspect it’s a recent thing, as I don’t believe it always worked this way.

I was asked yesterday for advice on the best language between Objective C and Ruby to learn for someone new to programming, who is hoping to be employed working with that language in the near future (an important point).  Here’s my response:

These are two ‘hot’ areas generating a lot of buzz here and abroad.

For the Australian market, I’d recommend Ruby because its best use case is developing websites in Ruby on Rails and there is plenty of demand for websites at all levels, from small sites to large.  Plus working with the web will teach a set of skills that is transferable to other programming languages — such as using HTTP correctly and the ubiquitous HTML.  Ruby is syntactically reasonably simple, and makes a great language for learning the princuples of programming.

Objective C on the other hand has two main use cases currently: desktop software and iPhone applications.  Experienced developers can make serious money in these areas, but it is far more random, and not an area where you can build a career, particularly in Australia where the demand is minimal.  Objective C is could be interesting as a second or third language, but I’d advise against starting with it.

A couple of posts ago, I mentioned my concern that Merb could add too much flexibility to the Rails world, and that the abundance of options would increase the barriers to entry for new Rails programmers.  Having watched the Rails/Merb 3.0 commits so far, it seems that the aim right now is to fix things rather than add things, a good approach since it should be transparent for new and old Rails developers alike.

Anyway, Josh Susser thinks that we may be facing the issue of too many options and too much to learn already, and he could be right.

I have enough experience that I don’t have to spend much time pondering. But for someone new to Rails this all must seem pretty intimidating.

While I was thinking of framework options, the fact of the matter is that there are already a multitude of options for approaching almost any aspect of a web app in the Rails world now.  Java hit this state many years ago — Bruce Tate, a leading light in the Java world who moved to Ruby on Rails, had this to say:

Even if you do choose a popular stack such as Spring, your developers must learn potentially dozens of libraries that are specific to a given project. In this case, Java’s core strength, a plethora of libraries, works against it. In contrast, most Ruby developers know Rails.

It’s this last sentence that is under threat.  In a year or two, Rails development may be just as fractured as Java.

Now options are not a bad thing per se, but many options that are essentially the same add nothing to the game.  I’m thinking in particular here of testing, mocking, and fixture replacement solutions, of which there are bucketloads in Ruby right now.  As a group we’d probably be better off just letting one of them win and moving on with our lives.  For instance, it seems that by-and-large we will all be settling on Passenger as the main deployment platform for the time-being.  This is a good thing, and lets us speak in a common deployment language, and allows us to worry about other parts of the tricky business of web development.

Working with common options doesn’t stop new approaches and frameworks from emerging, but they will need to prove to be sufficiently better to make it worthwhile to move, which is a good thing.

All this is to say: it will be very interesting to follow the progress of the Ruby and Rails communities over the next couple of years.  With no dominant vendor (such as Sun with Java), organic growth is driven by community needs, but it would be good to see the philosophy of “convention over configuration” rule in most cases.

Like many programmers, I’ve been using JavaScript for years, without really understanding everything about it. Recently I’ve been working on a project which is exclusively JavaScript, which is to say exclusively browser DOM manipulation via JavaScript, so I’ve been doing as much learning as possible.

First, the thing most worth knowing is that browser DOM APIs are NOT synonymous with JavaScript.  As Douglas Crockford says: “The API of the browser, the Document Object Model is quite awful, and JavaScript is unfairly blamed”.  Once JavaScript the language is separated with the way it interacts with the browser, one can be a little more objective about the language itself.  To that end, the highest recommendation I can give is to Crockford’s “JavaScript: The Good Parts” book.  It is an excellent exposition on the most useful and reliable subset of JavaScript.  Crockford explains that there are many average and poor parts of JavaScript, but that used properly and in a restricted way, it is a versatile and practical language.

Other excellent resources for understanding the JavaScript way of doing things are, particularly in the context of the browser:

• A detailed talk on why the DOM causes so many headaches by the founder of the jQuery project, John Resig: The DOM is a Mess
• Douglas Crockford’s “Theory of the DOM” talk - parts 1, 2, 3

As Crockford mentions in his book,  most JavaScript references are not so useful, because they don’t differentiate between the bad parts and the good parts of the language, instead leaving them for you to figure out.  Nevertheless, it is probably worthwhile having a JavaScript reference, and O’Reilly’s guide by David Flanagan is probably a good start.  I’ve also got good mileage from Accelerated DOM Scripting with Ajax, APIs, and Libraries, which covers modern JavaScript in the browser reasonably well.

JavaScript can be quite neat, though it wouldn’t be a first choice for me unless it was necessary (essentially, if I was working on the client side, in a web browser).  I certainly wouldn’t use it server side for anything, though there’s plenty of effort in that area.

Another area gaining steam is Test-Driven-Development of JavaScript.  I’ve been using JsUnitTest, but there are a number of libraries out there, each with quirks of syntax and implementation.  JsUnitTest works well for me for the moment.

The Ruby world is abuzz with the news that Rails & Merb will be merging for version 3 of the Rails framework.  Big news!

We all realized that working together for a common good would be much more productive than duplicating things on each side of the fence. Merb and Rails already share so much in terms of design and sensibility that joining forces seemed like the obvious way to go. All we needed was to sit down for a chat and hash it out, so we did just that.

I think there’s a lot of potential for good here, but I’m also a bit concerned about added complexity… one of the attractions of Rails is that it is very quick to get started, and someone can get productive in a matter of weeks.  If we lose the convention over configuration idea too much, that low barrier to entry could be lost (God help us if we get to ‘a zillion ways to do things’ like Java web development hit many years ago… ouch.)

I’ve got a positive attitude to this merging, but I’m also a little circumspect.  Robby Russell articulates my thoughts the best in Rails 3 and Merb:

I’m curious about how the revised core team will incorporate the library-agnostic view points into Rails without increasing the complexity for configuration. For example, being able to use a different ORM is great, but at the same time, one of the things that I have really liked about Ruby on Rails was that it did make decisions ahead of time for you. Conventions over Configuration and all that jazz. While they intend to keep these defaults, I really wonder how much more configuration will be involved. Be that as it may, Rails and Merb are run by some of the best developers I’ve ever known… so I am sure these decisions will not be made without some deep consideration.

…

Having testing, consistency, and other best practices built-in did the world a huge favor. …and all it took was someone like DHH to throw his opinion out there and stick to it.

Anyway, wheels are in motion… though I suspect Rails 3 is greater than 12 months away.  I can’t wait to see what happens.

Thinking Sphinx is a beautiful interface to the Sphinx search engine.  One thing that I only saw mentioned in passing was setting up a config/sphinx.yml file.  This is necessary if you want to run multiple sphinxes on varying ports (say, if you were running multiple apps on the one host).  The format is:

development:
port: 13000
test:
port: 13001
staging:
port: 13002
production:
port: 13003


Jamis Buck’s influence on Ruby and Rails development cannot be overestimated, so I was excited this morning to read that he has switched back from Textmate to Vim.  I made a similar switch about six weeks ago, though unlike Jamis I don’t have a long history with Vim (some casual use over ssh connections, essentially), so there’s been a lot of learning for me.  But too many things annoyed me about Textmate to overlook.  For instance, no window splitting!  In 2008!

I’ve been an editor floosy over the last couple of years though — for Ruby work I’ve had love affairs with Eclipse, Netbeans, Textmate and now Vim, but Vim looks like it’ll be the one to stick — so much power and configurability, and all straight from the keyboard.

Next, to try out Jamis’s fuzzy finder extension, and NERD tree (a project drawer mentioned in the comments of his blog post).

I stumbled over an annoying set of refactorings this morning.

First, the site Refactor My Code, which I’ve heard about and seen a couple of times but never really investigated.  One of the refactorings showed DRY taken a bit too literally, and in a way which I see all too often.  The original poster quite rightly wants to reduce his ActionMailer code, but how to do it?

The first responder has the best solution: refactor the core of the methods to a standard ’send mail’ method.  The only improvement I would make is to add a yield, thus allowing customisation via a block.  Using this method incurs one line per a new variation (though this could be more if a block is used).

The next two refactorings are not so good.  One uses define_method to add the methods dynamically.  The other uses method_missing.  In both cases this is misguided.

Using define_method is pointless: it results in marginally fewer lines of code than the previous solution, but  loses flexibility.

Use method_missing is the same — using Ruby tricks where none are needed.  Since templates need to be defined for each email to be sent, there’s no real advantage to automagically processing with method_missing, since you’ll know which emails are going to be sent by the templates you’ve defined.

The define_method refactoring was voted higher than the first refactoring, which only goes to prove that programmers often prefer being tricky to being practical.  Ruby programmers unfortunately take DRY to extremes, and this is just another case in point.

Just a quick note to say that The Rubyist is a fantastic read for anyone interested in modern Ruby development.  The magazine format lends itself to a mode and tone that blogs couldn’t reproduce — obviously the articles can’t cover what is happening right now, so instead we’re treated to more general software topics and ideas.

I’d love to have a hard copy, but it appears that is only an option in North America right now.

Anyway, highly recommended!

Subversion ignore commands drive me up the wall.  Git’s ignore is much easier to use, and consistent.

Here is the process I followed to add svn:ignore to a newly added directory that hadn’t yet been committed to the SVN repo.  The magic here is the “-N” flag on the add command, since that stops the recursive add (which would add the git directories), and you can then set svn:ignore afterwards.

svn add active_scaffold_list_filters/ -N
svn ps svn:ignore ".git" active_scaffold_list_filters/
svn add active_scaffold_list_filters/*
svn ci