In Ruby on Rails it worked pretty well out of the box, but with a catch. File uploads are stored in memory, so if you are letting users upload large files, the server will quickly run out of memory.

To solve this I discovered a new (as of 2.3) component of Rails called Metal. Metal is a thin wrapper around Rack, a minimal piece of middleware that handles HTTP requests for Rails. While Metal is a part of Rails, it lets you bypass Rails for the most part, and work at a lower level for those performance-critical bits. Happily, Metal lets you grab an uploaded file without making a copy of it in memory.

Here is an example of a Metal class that does file upload. To test this you’d just need to throw it in a /app/metal directory for your Rails project, then navigate to http://example.com/uploadtest to try it out.

 
class Uploadtest

  def self.call(env)

    if env["PATH_INFO"] =~ /^\/uploadtest$/

      request = Rack::Request.new(env)

      # Get temp file from request
      # Format: {:filename, :type, :name, :tempfile, :head}
      file = request.POST["file"] 

      # Make sure we have the parameter
      if !file.nil?

        # Create new file path
        directory = File.join("uploads", "uploadtest")
        FileUtils.mkpath(directory)
        path = File.join(directory, file[:filename])

        # Copy the uploaded file
        FileUtils.cp file[:tempfile].path, path

        # Response
        [200, {"Content-Type" => "text/html"}, ["Upload Complete"]]

      else
        # Show an example submission form
        [200, {"Content-Type" => "text/html"},
              ['<form method="post"
                      action="/uploadtest"
                      enctype="multipart/form-data">
                <input type="file" name="file"/>
                <input type="submit" value="Upload"/>
                </form>']]
      end
    else
      [404, {"Content-Type" => "text/html"}, ["Not Found"]]
    end
  end
end

I hope this helps someone who runs into the same situation I was in!

What good is this thing in practice? For awhile I figured this would be an awesome way to correct typos while typing, since the context menu has corrections. Mistype, menu key, enter, keep typing. But alas, spell checkers notice misspellings after the word has lost focus, so the Menu key isn’t really practical for this use.

So what is this thing for? Does anyone use their Menu key? Was it just another button to add to already-overcrowded keyboards along with the overwhelmingly useful ones like “open web browser” and “shut down”? Maybe that’s why the delightfully simple Apple keyboards don’t have it?

[Image Credit]

Incubators have a clear sense of deadlines, gets things done on time, and produce quality work. Before performing an important task, such as writing a term paper, they engage in an incubation phase that is necessary for their process. It looks like slacking off, but their mind is constantly brewing, preparing information for the outpouring of effort to come.

I always knew that I work this way, and that other people are like me. What I like about this article, though, is that Robert decided to give a name to it. From the article:

For most incubators, having a label that is less pejorative than “procrastinator” can be a breath of fresh air.

[image credit]

“On the back of this paper, write out every keystroke and mouseclick you would take to add five spaces at the beginning of the first 10 lines of a file in a text editor.”

Naturally, some people protested. But he insisted that the literal meaning of the question was to be carried out.

Some students assumed it was a trick question that they didn’t understand, and wrote nothing. Some students write out the entirety of what was necessary to do this in Notepad:

space, space, space, space, space, down, home, space, space, space, space, space, down, home,space, space, space, space, space, down, home,space, space, space, space, space, down, home,space, space, space, space, space, down, home,space, space, space, space, space, down, home,space, space, space, space, space, down, home,space, space, space, space, space, down, home,space, space, space, space, space, down, home,space, space, space, space, space

At the time, I had been learning Vim at the professor’s advice. So, feeling very clever, I wrote this on the back of my paper:

:1,10s/^/     /

In a few days, when the exam was returned, students noticed that the this question had not been graded. The professor answered them:

“Your reward for getting it right is not having to write out an entire page of text to do something trivially simple. If you haven’t followed my advice and learned a good text editor, you waste this much time a hundred times over every time you write a program.”

Invaluable advice for any programmer. Use good tools, and get really good at using them.

[Image Credit]

Alright. I want to show an example he used that doesn’t seem to be included in any of his articles online. This may not be exactly the same, but is close to how I remember it.

Everyone argues about where to put the starting curly-brace of a block.  Usually they don’t have any substantial cause to pick one over the other, but everyone agrees one technique should be used consistently in a given program.  There is a reason to choose one style over the other in JavaScript. Check out this example:

function test1() {
    return {
        foo: "bar"
    };
}

function test2()
{
    return
    {
        foo: "bar"
    };
}

alert(test1() === undefined); // false
alert(test2() === undefined); // true

These two functions appear to only differ in their formatting. Surprised by these results?

The first function does exactly what it looks like it should. In the second, 4 different language design problems cause the program to do something unexpected while providing no errors.

1. Semi-colon insertion causes the return to be a return;
2. A line that starts with { starts a block. There is no block-level scope, so in this case the block does nothing. This “feature” is only there because C has it.
3. The foo: looks like part of an object literal, but we’re in a block, not an object literal. This should be an error, right? No, it’s a label. Even though we’re not in code where a label could do anything, such as a for loop.
4. The rest of the line after the label is the value “bar”. A value by itself counts as a statement, even though it doesn’t do anything.

Wow. That function does something wildly different than what it appears to do. The point Crockford was making here was that in JavaScript, unlike in most languages, preferring the first type of curly-brace placement helps you avoid mistakes like this one.

He also mentioned that JSLint,  his free JavaScript code quality tool, is able to pick up on this kind of mistake. Try running my example through it!

[Image Credit]

Never Sometimes catch the top-level “Exception” class.

There are times when it is definitely appropriate.  Imagine some controller code in a web application.  An underlying system has produced an unexpected exception.  Controller code can’t do anything to fix it, but allowing the exception to continue up the call stack would cause a 500 error.  Catching any thrown exception can allow the Controller to do something better, like output a message to the user notifying them of the error and making a suggestion on what to do next.

In short, catch the top-level Exception class if you know for sure that every thrown exception will be handled more poorly by your caller than you can handle it, and you can’t improve the caller’s behavior.

Always When appropriate catch the most  specific exceptions thrown.

Catching the most specific exceptions thrown is meant to create error handling specific to the problem that was raised.  For example, a “DatabaseConnectionLost” exception would be caught, and in the catch block the connection would be repaired.  It seems reasonable to always want to do this, but in practice, some exceptions are thrown in cases where you can’t do anything about it.  Lets say a method throws “DatabaseConnectionLost” and “DatabaseQueryInvalid”, both of which are children of “DatabaseException.”  In a situation where the calling code can’t repair the connection or fix the query, catching the parent is appropriate, rather than handling each specific case without anything specific to do.  If the code can do something like email the DBA, catching DatabaseException seems useful.

In short, you should always catch the most specific exceptions that you can actually do something about.

Never leave a catch block empty (if you can help it)

This is actually one of those rare never-ism that I’m OK with.  But sadly, when interfacing with poorly thought out code, sometimes you are forced to do this.

Lets say you want to create User objects and add them all to a list, and you know their IDs.  You can get users by ID from a piece of library code that you cannot change.  However, you cannot check if a user ID is valid: there is no method for it.  Further, the getUser method throws UserIdInvalidException when you try to get a user by an invalid ID.  For you, an invalid ID is not an exceptional circumstance, but the library code assumes it is.  Sadly you might be forced to write something like this:

for (id : userIds) {

    try {

        users.add(UserLib.getUser(id));

    }

    catch (UserIdInvalidException e) {

        // If ID is invalid don't include it on the list

    }

}

It is very rare that you actually can’t find a better way.  For the most part, consider a catch block like this to be a mistake unless proven otherwise.

Conclusion

Forget all these “always” and “never” rules.  A rule to live by would read more like this:  Exceptions should always be handled as best they can by the code best suited to handle them.

[Image credit]

This is fun because you can see this on any website. I have only tried this in Firefox and Internet Explorer 7 on Windows, but compare these URLs:

Page with short URL

Same page with long URL parameters added

The WMP APIs are pretty embarrassing, but for me, this one takes the cake.

var text = "Any reviewer who expresses rage and loathing for a novel" +
           " is preposterous. He or she is like a person who has put" +
           " on full armor and attacked a hot fudge sundae." +
           " -- Kurt Vonnegut"

var count = 0

var newVersion = text.replace(/ (\w+) (is)/g, function(match, g1, g2,
                                                       position, input) {

    count++

    document.write("Match: [" + match + "]. Found [" + g1 +
                   "] before [" + g2 + "] at position [" +
                   position + "].<br/>")

    return " " + g1 + " " + " REALLY is"

})

document.write(count + " matches found<br/>")
document.write("New version:<br/>"
document.write(newVersion)

This code will output:

Match: [ novel is]. Found [novel] before [is] at position [50].
Match: [ she is]. Found [she] before [is] at position [79].
2 matches found
New version:
Any reviewer who expresses rage and loathing for a novel REALLY is preposterous. He or she REALLY is like a person who has put on full armor and attacked a hot fudge sundae. — Kurt Vonnegut

There is a lot going on in this example, but I think it demonstrates what you can do with this function that is definitely not possible if you only use a string for the second argument to replace.

Here are what appear to be the arguments to the function passed to replace:

Match: The current substring that was matched by the regex.

Group 1: The first parenthesized group in the regex.

…

Group N: The Nth parenthesized group in the regex.  There can be an arbitrary number of these.

Position:  The numeric position in the text where this match occurs.

Input: The entire input text with changes that have ocurred so far.

The power to customize your replacement based on a variety of factors, as well as have an unrelated behavior happen for each match, is definitely useful.  Another JavaScript secret revealed!

Never mind the terrible file name.  Notice how it finds it even though I didn’t know it had an underscore in the name.  Making the search do exactly what you expect would have been fine, but a real programmer thinks about what is really useful, even if it defies expectations.

The task: write an HTML parser in one week.  A good programmer gets it done.  A great one explains why the project is better off using an existing HTML parser.

The task: write a function to export a data structure to XML in three days.  A good programmer gets it done.  A great programmer asks why, finds out the reason for the task is irrelevant, and spends three days doing something useful.

The task: write a class that encapsulates some inventory business logic in a day.  A good programmer gets it done.  A great programmer thinks about it, nods, then gets it done.

If you’re worried that if you followed this process you’d often get the response “Just do it!” then your management may have some serious problems.