Jason in a Nutshell

All about programming and whatever else comes to mind

Archive for April, 2009

Make sure you use the right method

Posted by Jason Baker on April 29, 2009

Pop quiz:

What is the difference between HTTP POST and HTTP GET?

If your guess is that GET sends data via the query string while POST send data in the request’s body, you are… absolutely correct.  And I hate your guts.  Why is this?  It’s not that what you’re saying is wrong by any stretch of the imagination.

Idem-what?

I hate you because while GET and POST do send data differently, that’s not the biggest difference between the two.  The biggest difference is that POST methods are idempotent.  What does this piece of programmer-ese mean?  How many times have you seen something similar to this Chrome form?

 

confirm form resubmission

confirm form resubmission

On poorly designed websites, you probably see it a lot.  Web development newbies will often ask how to disable this page (or its Firefox equivalent).  There’s a really simple answer for this:  you don’t.  That warning is there for a reason.  You will see that warning every time you hit the back button to go to a page that was requested via HTTP POST.

The reason for this is that POST requests aren’t idempotent.  Idempotent is just a fancy word meaning that something won’t make changes.  As the HTTP 1.1 specification says:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

Suppose we’re writing software for a web forum, and we have a URI /forum/submit-message.  If we send data to this form, it will post a message.  Now, imagine that after submitting a message, the user visits /forum/view-message and then hits the back button.  They will go back to /forum/submit-message and send the same message over again if you were to use HTTP GET instead of POST.  However, if you were to use POST, that would be prevented by the maligned “Confirm Form Resubmission” page.  Sometimes annoying things can be useful, eh?

What’s the point?

The point is that nothing is more annoying than a website that uses GET and POST incorrectly.  And you don’t want to lose users by using the wrong one, do you?

Posted in Programming | Tagged: , , , , | Leave a Comment »

You need to worry about deployment

Posted by Jason Baker on April 29, 2009

Oftentimes, people used to using PHP or Classic ASP will give up on Python because deploying Python scripts isn’t just a simple matter of copying and pasting files.  Usually, this isn’t because Python is making their lives difficult.  It’s more a matter of not thinking about how to deploy your scripts ahead of time.

Now, I’m far from a highly experience programmer, but I can tell you one thing.  Deployment is a detail that will come back to bite you if you don’t spend a little bit of time on it up front.  So here are a few pointers I’ve come up with after experiences in deploying Python scripts for web apps.

  1. Batch/Shell scripts are your friends.  A common objection is that a person just doesn’t have time to learn a new tool for deploying.  I have two responses to this: 1)  Drop that attitude otherwise you’ll never get anywhere as a programmer and 2) Don’t use them if you really don’t want to!  While batch and shell scripts aren’t the prettiest options, they’re a lot better than having nothing to automate deployment at all.  In fact, for the basic one or two page webapp, you can’t really do much better.
  2. If you invest some time in Continuous Integration, you won’t regret it.  I know what you’re saying.  Continuous Integration is a Java thing.  It’s too complicated.  And you’d be right to a point.  However, I would argue that making sense of the complication is worth your time.  It’s way too easy to deploy something that doesn’t work because somebody forgot to run their unit tests.
  3. Site-wide packages are evil.  If you aren’t already, you should really be taking advantage of virtualenv.  That is, unless of course you enjoy troubleshooting weird ImportErrors because of that egg you installed using the setuptools develop command a month ago and forgot to remove.
  4. Don’t underestimate the value of good docs.  Having good documentation is just one of those things that don’t become obviously necessary until it’s too late.  Don’t leave yourself trying to figure out how that one function you wrote a year ago works.  Write documentation as you go and use a tool like sphinx to turn it into a webpage.  This ties in with point 2.  Using Continuous Integration will make doc generation that much easier.

Admittedly, doing this stuff can be a pain.  And you might get scorn from co-workers for not having something ready the next day.  But it will be worth it.  You’ll be surprised at how much time you’ll save in the long run.

Posted in Programming | Tagged: , , , , , , , , | Leave a Comment »

The magic of python decorators

Posted by Jason Baker on April 25, 2009

Decorators in Python are one of the language’s more “magical” features.  Personally, I’ve tended to glaze over decorators in code because they always seemed to be fairly self-explanatory.  But how do you make your own?  Personally, I think understanding the uses of decorators and being able to write your own is one of the points where a python newbie transitions to a knowledgeable pythonista.

But what is a decorator?

In actuality, there’s not an actual language construct to define decorators.  Any function that takes a function as a parameter and returns one as a result may be used as a decorator.  These are known as “higher-order functions” in functional programming circles.

Chances are, you’ve already seen decorators in use and maybe even used them.  I’ll give you a common example of decorator usage:

class SomeClass(object):
     @property
     def x(self):
         return 5

>>> var = SomeClass()
>>> var.x
5

For those of you familiar with the concept of properties, it should be pretty straight-forward what’s going on here.  But where the heck did property come from?  I’ll give you a hint.  The above code works identically to this code:

class SomeClass(object):
    def x(self):
         return 5

    x = property(x)

 

I can write my own?!

Yes you can.  A lot of well-written libraries make very good use of decorators.  And given the right situation, the little bit of syntactic sugar they provide can do a lot of good.  But decorators aren’t just there for others to define.  Once you wrap your head around decorators, they can save you a lot of copy-and-pasting (which you’re not doing anyway, right?) when used in your own code.  To illustrate this, I want to show you a couple of very much real-world cases that I’ve found decorators to be useful.

Those pesky connection objects

I have a library that needs to call a few particular stored procedures in a SQL Server database.  Because my ORM doesn’t support stored procedures, I have to use straight adodbapi.  The calls look something like this:

import adodbapi

def LookupPerson():
    conn = adodbapi.connect(CONNECTION_STRING)
    try: 
        #do stuff here
    finally:
        conn.close()

This is all well and good for just one function.  But what happens when you need 4 or 5 of these?   And what about the visual cruft that the try finally block is adding to the function (adodbapi doesn’t support with blocks before you ask)?  I’m sure you’ve already guessed the solution by now.  Here’s how you can solve this problem:

import adodbapi

def with_connection(func):
    def _exec(*args, **argd):
        conn = adodbapi.connect(CONNECTION_STRING) 
        try:
             func(conn, *args, **argd)
        finally:
             conn.close
     return _exec 

@with_connection
def LookupPerson(conn):
    #do stuff here

LookupPerson()  #conn argument is passed by the decorator

 I think that the simplification that happens with LookupPerson here should be obvious.  But what is the purpose of the *args and **argd shenanigans?  The documentation covers arbitrary argument lists in depth, so I won’t go into too much detail.  But what happens if I want to lookup a person by name?  The LookupPerson function would be transformed to this:

@with_connection
def LookupPerson(conn, name):
    #do stuff here

LookupPerson('Bob')  #conn argument is passed by the decorator
LookupPerson(name='Jill')

 In fact, I can decorate any function that takes any number of arguments either by keyword or by position.  Pretty neat, eh?

Error handling

When doing web applications, it’s pretty important to have decent error handling.  But setting this up can be a pain.  For instance, what if I wanted to make my django application print a wonderfully informative traceback to a log file?  I could do that like this:

from traceback import format_exc

def index(request):
     try:
          #do stuff
     except:
         logging.log(format_exc())
         return HttpResponseServerError('Error!')

But this definitely can become problematic.  What happens if you duplicate this code in all of your view functions and you want to make a change to your error handling?  The solution is simple:

def handle_errors(func):
     def _handler(*args, **argd):
          try:
               func(*args, **argd)
         except:
                logging.log(format_exc())
                return HttpResponseServerError('Error!')

@handle_errors
def index(request):
     #do stuff here

 As you can tell, this allows us to make our views worry about actually doing stuff instead of constantly handling errors.  Yes, there are also middlewares for doing this kind of thing.  But then I wouldn’t have a reason to make a blog post about python decorators, would I?

Conclusions

Ok, so I’ll admit something.  Python’s decorator syntax is ugly.  Its Java-like syntax alone may even be enough to scare some off.  But as I’ve show, there are at least a few real-world cases where they are useful.

What are some other decorators that you’ve found to be useful?

Posted in Programming | Tagged: , , | 2 Comments »

Software update hell part II

Posted by Jason Baker on April 24, 2009

I just wanted to point out that Kas Thomas has a very excellent blog post on automatic updates that is strangely similar to my own piece Software Update Hell.  As much as I’d like to use this as an opportunity to say “Great minds think alike,” I think this is more a case of software updates just being a total pain in the ass to install on some systems.

Posted in Programming | Tagged: , , , , , , , , | Leave a Comment »

Java vs C# vs Python vs Ruby: an “objective” analysis

Posted by Jason Baker on April 21, 2009

At my place of employment, we’re looking to migrate some of our old Classic ASP applications to something newer (yes, we still have actively maintained Classic ASP code). So my boss asked me to write up an analysis of the different options we have available.

Now before I give you the link, I have a few disclaimers and other random thoughts:

  • I tried to avoid editorializing so that this can be objective as possible, but it’s impossible to discuss these kinds of issues without being subjective.  Thus, don’t take this as the gospel truth.
  • There may be errors here.  In fact, I can almost guarantee that there are errors with Java and Ruby because I’m not terribly familiar with them.  If there are errors, feel free to leave comments.
  • My boss is a Java guy, so I left some blanks that I’m pretty sure he can fill in.
  • Some of these are blatant oversimplifications.  There’s only so much data that you can squeeze into a spreadsheet.
  • I’ll try and keep up with this for a while, but chances are that I won’t for long.  These languages are all being changed.
  • I’m biased towards Python.

Ok, without further ado, here’s the link:

http://spreadsheets.google.com/pub?key=p7efJLoHuYE-iw6JxBmpSQg&hl=en

Posted in Programming | Tagged: , , , , , , , | 12 Comments »