• Being explicit with your code

    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.

  • RubyGem Version Specifiers

    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.

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

  • Ruby/Rails Compatibility Matrix

    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:

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

    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:

    • By Peter Jones
    • |
    • |
    • Ruby
    • |
    • More

  • Fun stuff for Friday Feb. 24

    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.

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

  • Fun stuff for Friday Feb. 10

    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.

  • Using Haskell to improve your C++

    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:

  • Rails 4.0 will drop support for Ruby 1.8.7

    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.

  • Why estimating is hard

    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.

  • Fixing programming by besting current languages

    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.