Devalot - A weblog of hand-picked development content served hot.

Being explicit with your code

Peter Jones — Tue, 17 Apr 2012 21:29:42 +0000

Christian Heilmann has a well reasoned gripe for developers omitting semicolons in JavaScript:

Why would any intelligent person want to make it harder for others to understand what they've done, keep booby-traps in their code that will cause errors or deliberately write in a way that might make others stumble? Is this some kind of code-trolling I don't get?

I have the same exact complaints when people don't use parentheses in their Ruby code. You can argue all day about your reasoning but when you run your code through ruby -w you'll see all sorts of warnings about ambiguous code.

Tags: Developer Skills Ruby

RubyGem Version Specifiers

Peter Jones — Tue, 03 Apr 2012 19:41:23 +0000

When writing an application in Ruby it's likely that you'll make use of several open source libraries that come packaged as RubyGems. But do you know which versions of those gems are getting loaded into your application? Will all versions work with your application?

It doesn't matter if you are loading gems into your application directly using require statements or using a tool like Bundler, you should always use version specifiers to future proof your application.

Using Version Specifiers

It's often tempting to load a library without regard for which version you are about to use:

# In your application's source code
require('nokogiri')

# Or, in a Bundler Gemfile
gem('nokogiri')

But that's equivalent to using the following version specifiers:

# In your application's source code
gem('nokogiri', '>= 0.0')
require('nokogiri')

# Or, in a Bundler Gemfile
gem('nokogiri', '>= 0.0')

As you can see, version specifiers are comprised of a version operator and a version number. Omitting the version specifier or using the >= version operator is almost always a bad idea.

The code above means that you'll happily use any version of the Nokogiri gem. But is that a true statement? Will your code really work with any version? What about really old versions of Nokogiri? What about the version of Nokogiri that's going to be released in 2 years?

It's easy to imagine a situation where you upgrade a gem to support a new application and in the process break an old application. If the older application had a restrictive version specifier it would keep working as long as you had a compatible version of the gem installed.

I said it's almost always a bad idea to use >= because there's at least one legitimate use for it. RubyGems allows you to give more than one version specifier and Bundler supports this as well:

gem('nokogiri', '>= 1.0.0', '< 2.0.0')

Which means that you'll take any version of Nokogiri starting at 1.0.0 but not 2.0.0 or higher. Combining version specifiers like this gives you a lot of control over which version is going to be loaded into your application, but it's a bit cumbersome. If all you want to do is restrict a gem to a specific major release (e.g. 1.x but not 2.x) then you can use the pessimistic version operator (~>).

The Pessimistic Version Operator

The pessimistic version operator (~>) allows you to state that your application works with future versions of a gem in a safe way. Of course this only works if the author of that gem introduces changes that break backward compatibility in a predictable way (e.g. going from version 1.0.0 to 1.0.1 doesn't break your application).

For example, if you trust that the authors of the Nokogiri gem won't break backwards compatibility until version 2.0.0 you can load the gem using the pessimistic version operator:

gem('nokogiri', '~> 1.0')

But, if you only trusted them to maintain backwards compatibility in the 1.5.x releases you could specify the version as:

gem('nokogiri', '~> 1.5.0')

The pessimistic version operator can be controlled by how specific you make the version number. It works by stripping off the last digit you specify and incrementing the remaining version. So 1.5.0 becomes 1.6 and 1.0 becomes 2.0. It then restricts the version of the gem starting with the version you specified up to but not including the incremented version. Here are some examples:

Pessimistic Version	Range Restriction
`gem('nokogiri', '~> 1.0')`	`gem('nokogiri', '>= 1.0', '< 2.0')`
`gem('nokogiri', '~> 1.5.0')`	`gem('nokogiri', '>= 1.5.0', '< 1.6.0')`
`gem('nokogiri', '~> 1.5.3')`	`gem('nokogiri', '>= 1.5.3', '< 1.6.0')`

Available Operators

RubyGems provides a complete set of version operators that allow you to specify which versions of a gem your application can work with. If you don't use an operator and just use a version number you lock your application to that specific version, it's shorthand for using the equal (=) operator.

Here's a list of the of the operators supported in RubyGems:

Operator	Meaning
`=`	Equal to (default)
`!=`	Not equal to
`>`	Greater than
`<`	Less than
`>=`	Greater than or equal to
`<=`	Less than or equal to
`~>`	Pessimistically greater than or equal to

Tags: Ruby RubyGems

Ruby/Rails Compatibility Matrix

Peter Jones — Wed, 14 Mar 2012 21:36:09 +0000

I found myself needing to figure out which versions of Ruby on Rails run under which versions of Ruby. I couldn't find a compatibility chart so I put this together:

Rails Version	Possible Ruby Versions	Recommended Ruby Version
1.0--2.1	1.8.6	1.8.6
2.2	1.8.6 or 1.8.7	1.8.7
2.3	1.8.6, 1.8.7, or 1.9.1	1.8.7
3.0--3.2	1.8.7, 1.9.2, or 1.9.3	1.9.3
4.0--...	1.9.3	1.9.3

Tags: Ruby Ruby on Rails

Ruby's catch/throw, goto's little brother

Peter Jones — Fri, 09 Mar 2012 16:54:10 +0000

Last week Pat Shaughnessy discovered that there's a pre-processor definition in the Ruby 1.9 source code to enable goto and label statements in a rather ugly way:

The __goto__ statement will cause the MRI Ruby 1.9 interpreter to jump up to the __label__ statement on the first line, since they both refer to the same symbol :loop.

I don't think there's much use for goto in a language like Ruby considering that it's garbage collected and you can release resources using closures and ensure blocks. However, if you're dying to play with this, why not use goto's little brother, catch and throw:

class Test
  def foo
    throw(:label, "foo")
    "should never get here"
  end

  def bar
    "bar"
  end
end

test = Test.new

puts("foo -> " + catch(:label) {test.foo})
puts("bar -> " + catch(:label) {test.bar})

There's not much to know about catch and throw. You give a symbol and a block to catch, which acts like a goto label. Any code that uses throw in that block, no matter how deep, will unwind and cause the catch block to terminate, returning the value given to throw.

You can nest multiple catch and throw expressions using different values for the label symbol. Here's another example:

def thrower
  10.times do |i|
    10.times do |j|
      $stdout.puts("#{i}.#{j}")
      throw(:label, j) if i > 2 and j > 2
    end
  end
end

val = catch(:label) do
  thrower
  raise("should never get here")
end

$stdout.puts("val is #{val}")

Tags: Ruby

Fun stuff for Friday Feb. 24

Peter Jones — Fri, 24 Feb 2012 22:03:35 +0000

It's Friday, and an especially good one at that. At least for me since it marks the start of a much needed vacation. Hopefully this weekend will be good for everyone, and what better way to kick it off than some fun and geeky articles and videos.

If you're in the market for a new keyboard and think you want to create one yourself, look no further than the Humble Hacker Keyboard. This thing looks very cool. And if you think the layout is a bit crazy then you need to watch this video of Tim Tyler's keyboard. Via Hack a Day.
Nathan Rice posted some pictures comparing programming languages to cars which is cute.
Eric Moritz put together a list of books that every self-taught developer should read. It seems like a pretty reasonable list. Of course, I would add The Pragmatic Programmer.
There's a fairly interesting article over at the BBC about the myth of the eight-hour sleep. For whatever reason I've found that software developers seem to be interested in sleep patterns and sleep experiments.
Longtime fans of Apache will be glad to hear that version 2.4 has been release with some interesting features and performance changes that match up with Nginx.
Finally, you may want to remove your search history from Google before their new privacy policy goes into effect on 3/1.

As always, have a wonderful weekend. Recharge your batteries and prepare yourself for a return to hacking on Monday.

Tags: Fun Friday

Fun stuff for Friday Feb. 10

Peter Jones — Fri, 10 Feb 2012 21:43:28 +0000

This is going to be fun. I haven't written a Fun Friday article this year and my queue of things to share is sizable. To top it off, I haven't been keeping my self-imposed quota of at least one article a day, so my general queue of articles to comment on has grown out of control. This post will contain some fun things I want to share as well as a few backlogged articles that are pretty interesting.

Want to relive the fun of rebooting older operating systems? The Restart Page has you covered.
Developers are religious about the text editor they use, that's no surprise. Need to vent your anger for Eclipse? Look no further than I Hate Eclipse. If you're looking for a new text editor Sublime Text 2 Beta is out. Oh, and Emacs is the one true editor.
Parse has found an interesting way to filter through resume overload often accompanied by job postings. To apply you have to submit JSON to their API. Smart.
Ash Moran wrote an article to help you get your crap together instead of just throwing more developers at the problem.
If you're not up on your diff and patch ninja skills this article walks you through creating and applying patches.
Do you find the Java syntax to be too verbose? Eleftheria Drosopoulou says she likes the verbosity of Java because it forces you to understand the code you are using. I can see where she's coming from but I think the verbosity of the syntax actually impedes its readability.
Speaking of Java, Marc Kuo has wrote a series of articles about why he loves Common Lisp and hates Java. Part 1 and Part 2.
All Programmers Are Self-Taught is short post about how a computer science education doesn't actually teach you how to program. I tend to agree but the author is still a student, so maybe he needs to take a few more classes.

That should give you plenty to read over the weekend.

Tags: Fun Friday

Using Haskell to improve your C++

Peter Jones — Mon, 06 Feb 2012 20:00:23 +0000

I find myself drawn more and more to Haskell. Any language that helps a developer write solid code without making you feel like you're using training wheels is a huge plus in my book. Functional programming has also opened my eyes to all sorts of pitfalls with imperative programming.

Even if you're put off by Haskell or functional programming there's a lot you can learn and both can have a positive influence on your imperative programming skills. At least that's what they say.

The folks over at Valletta Ventures have a short blog post about how their C++ code has changed for the better after thinking about problems functionally:

There is no doubt that time spent playing with Haskell has taught me to exploit the type system when coding in C++, but the most lasting effect may be when I abandon C++ altogether.

I would have liked to see a lot more code and a more complete discussion on how functional thinking can improve imperative code. As I dig deeper into Haskell I'll post some thoughts on how it's making my daily imperative programming better or just different.

If you haven't exposed yourself to Haskell yet I highly recommend watching A Taste of Haskell the next time you have 3 hours to completely geek off. Make sure you download the slides and follow along.

Tags: C++ Haskell

Rails 4.0 will drop support for Ruby 1.8.7

Peter Jones — Thu, 02 Feb 2012 20:04:15 +0000

Back in 2010 when Ruby on Rails 3.0 was released the core team dropped support for Ruby 1.8.x except for version 1.8.7. With 4.0 scheduled for a release sometime in the Summer of 2012 all versions of Ruby 1.8 will officially be dropped:

There's not a lot of details about what we're going to include in Rails 4.0 yet as the primary purpose for bumping the major version number is to drop Ruby 1.8.7 support.

This coincides with the Ruby core team dropping support for 1.8 this Summer as well.

Tags: Ruby Ruby on Rails

Why estimating is hard

Peter Jones — Tue, 31 Jan 2012 19:49:17 +0000

Software developers are notoriously bad at estimating, to the point where project managers and bosses regularly double or even triple our estimates. Tools like calculating developer velocities help average out these errors but also tend to cover them up. So why is it so hard to estimate development work?

Diego Basch hits the nail on the head in his opposition to the idea that we get better at estimating over time because we're doing the same sort of things over and over again:

Real software development is about doing something that you've never done before. That's why all stupid analogies about routine real-life stuff break.

As a freelance software developer I tend to do a lot of the same things over and over again but with small changes in the details. This has probably given me a false sense of being a good estimator. I think I need better problems to solve.

Speaking of estimating, if software developers are so bad at estimating why do managers and stakeholders think they are so much better? How often does your boss/client suggest that your current task should only take you 30 minutes? What insight do they have that we don't?

I used to work in the cube next to my manager. I would hear him on the speakerphone with other managers committing me to tasks and giving them estimates. This guy could barely use a computer yet here he was saying stuff like "that should take a day".

Maybe that's why we have such a bad reputation for estimating.

Tags: Developer Skills

Fixing programming by besting current languages

Peter Jones — Thu, 26 Jan 2012 20:46:09 +0000

Jon BeltranDeHeredia's rant on why programming is broken has turned into a very interesting thought experiment. First, Jon describes why he thinks programming is broken:

Every step of the way, in every statement, line of code, function call or sequence-point, if you want to write good code, you need to think about all the different possible states of the whole program. This is invisible and impossible to define. Provably. Always. In all existing languages. That's the reason 100% code-coverage unit-testing doesn't guarantee bug-free code, and it never will. This is also the reason bad programmers don't become good: they just can't think about all those possible cases in a structured way.

Then he describes his vision for a new programming language that looks like the love child of Haskell and Prolog.

If you're looking for something geeky to spend your free time on I suggest taking some ideas from the comments on Jon's article. Readers are posting links to all sorts of interesting things such as executable specifications, the failures of Prolog, proof management systems, and the 4GL fiasco.

Tags: Declarative Functional Haskell Imparative Prolog Provable Code