I wanted to set up the pre-commit hook so that commits with empty comment are automatically rejected.

All commit-hook example files that go with Subversion are written in bash (as unix servers tend to be the normal).

Here is a the pre-commit hook rewritten as a windows .bat file.

Earlier this year New York Times brought another interesting visualization: A Peek Into Netflix [rental] Queues, where you can explore where (by US postnumber) any top 100 movie gets rented. A standard US map is overlaid with a heatmap of the data, and combined with excerpts from the movie reviews. Very amusing.

I decided to import the data into a local database to ensure it could work offline.

Code from

file:

Now I can access municipalities in a grouped selectbox like so in the view code:

<%
 options = option_groups_from_collection_for_select(Region.all, :kommuner, :name, :id, :name)
%>

<%=
 f.select("kommune_id", options, {}, {:class => "short"})
%>

The final result rendered in the user interface:

This code is based on Rails 2.3.5.

A central quote:

If you give a good idea to a mediocre group, they’ll screw it up. If you give a mediocre idea to a good group, they’ll fix it. Or they’ll throw it away and come up with something else.

We think of ‘an idea’ – for movies, for products. It’s usually thought of as some singular thing. But the reality of these successful movies – as with all successful products – that they have got thousands of ideas. It’s all sorts of things necessary to make the film successful. And you have to get most of them right to be successful. That is why you need a team that works well together.

• Coding Horror: Cultivate Teams, Not Ideas (January 2010)
• Ed Catmull, Pixar: “Keep your crises small” (recorded January 2007)

The presentation was held in our usual Capgemini SmartLunch format: People can eat and learn in their lunchbreak. External visitors are welcome. Duration 30-45 minutes including questions.

• pres 2010-04-27-cucumber (573KB pdf format)
• pres 2010-04-27-cucumber.key (782KB keynote format)

Here is the explanation of the detailed mouseover view when zooming in on each request:

• The second request started 109ms after the start of the first request (since the beginning of the waterfall graph).
• There are two numbers for each request phase (5 phases). The first number on the left says when the phase started within the request. The second number on the right (closer to the phase label) says the time needed to complete each phase. In this case, the first three phases took zero time, and so the Waiting phase was the first real and it needed 32ms to complete. The Receiving phase started in 32nd ms of the request and needed 15ms to complete
• DOMContenLoaded event was fired 7ms after this request started. If this number is negative the event was fired before the request is started.
• load event was fired 189ms after this request started. If this number is negative the event was fired before the request is started.

Here are some notes about each request phase.

• DNS Lookup: DNS resolution time
• Connecting: Elapsed time required to create a TCP connection.
• Blocking (not on the screenshot): Elapsed time spent in a browser queue waiting for a network connection. Displayed only in the case where this situation happens (see also this post).
• Sending: Time needed to send request data to the server.
• Waiting: Waiting for the response (till the first byte is received from the server).
• Receiving: Time necessary to download response body.

I found myself reading up on this because I did a HTML5 offline experiment, where the “HTML5 .manifest files did not appear in Firebug net panel”

Jan Odvarko has two excellent posts explaining most functionality of the Firebug Net panel. The two posts are highly recommendable

• Firebug Net Panel Timings (March 2010)
• Introduction to Firebug: Net Panel (May 2009)

The hudson console only let’s you run Groovy script. To run commands on the machine, Groovy has the method

. So now I can use this snippet to test versions of Ruby, JRuby, etc:

def commands = ["ruby --version", "gem environment", "which ruby", "which gem", "jruby --version"]

commands.each{
  run(it)
}

def run(cmd) {
  //def proc = commands[1].execute()
  def proc = cmd.execute()
  proc.waitFor()

  // Obtain status and output
  println "return code: ${ proc.exitValue()}"
  println "stderr: ${proc.err.text}"
  println "stdout: ${proc.in.text}" // *out* from the external program is *in* for groovy

}

Example borrowed from and shrinkwrapped from groovy.codehaus.org/JN1015-Collections

In this case, I searched for “earth h….” and it suggests “earth hour 2010″ But on top of that, it inserts a link to the most relevant website directly. Smart and time-saving, i suppose.

Also, it does not clutter the suggestion box completely. Adding link to all suggestions would clutter the box, I think.

Also, I saw that google now shows real-time updates of news results inside the search result page:

Notice that scrollbar in the bottom of the screenshot: The result page keeps updating.

I did a small change to express my opinion better. Changed “JavaScript should generally be avoided” to “Don’t use JavaScript for general page layout rendering”.

Here is the modified advice from the article:

Long-term findings

• Don’t use JavaScript for general page layout rendering. Think really really hard if it can be done without JavaScript. One example: Print should be done with CSS
• If there is no way around it, use standard JavaScript libraries were browser bugs, etc are hidden for the programmer
• Tables used for layout are evil. Use tables for table-based content ONLY
• HTML code is really messy and hard to maintain. Should be cleaned up to avoid similar situations in the future. Clean up nested tables, table cells with transparent gifs. Use CSS where appropriate could shave up to 50-70% of HTML footprint
• Many HTML validation errors. Code improperly nested, forgotten end-tags: Ideally, the pages should have no validation errors. It’s an achievable work worth the effort and very educational way of working with the code

Long-term benefits

In general, several benefits could be gained by raising the knowledge of HTML, CSS, Javascript, web standards, and browser issues.

• Include easier maintenance
• Lower risk of change
• Lower risk of browser incompatibilities
• Lower risk of browser crashes

Read article: Why Web Standards Matter (Case Study)