software_dev

My day-to-day work often consists of writing web applications that aggregate data from a number of sources. Corporate constraints frequently dictate that I cannot use languages that make crunching of collections easier so I am forced into an old-fashioned for-loop frenzy. Ugh. On a recent java project my pairing buddy (Jules - thank you) suggested that we look at lambdaj. From the lamdbaj site: “lambdaj is a library that makes easier to address this issue by allowing to manipulate collections in a pseudo-functional and statically typed way”....

One of the best descriptions of the hierarchy of tests that I have seen comes from "Growing Object-Oriented Software, Guided by Tests" by Steve Freeman and Nat Price. 1. Acceptance Tests: Does the whole system work? 2. Integration Tests: Does our code work against code we can't change? 3. Unit Tests: Do our objects do the right thing, are they convenient to work with? Can we now get on with some work, rather than discussing definitions ad nauseam?...

For a while now I've been flying the flag for using a post-redirect-get design pattern when writing web applications. In my opinion the current crop of web frameworks still make it very easy to do the "bad" thing since to do PRG properly you need to think what kind of an interaction you want with users and not cop out saying its technically very difficult in . If you resort to ActiveX controls, popups without navigation bars and/or weird javascript hacks to stop users from clicking refresh or back buttons then perhaps you should have written a better web application....

I've been saving this rant for a while now: 1. Test everything at the front-end, in exquisite detail - every project sponsor understands what tooltip 0 really means. Also a great idea if you like long-running and fragile tests that require deployments, browsers, testing frameworks and the kitchen sink. Testing at different layers, and perhaps even without a browser or (in java) a servlet container is for the weak. 2. Perform a database cleanup before and after every test, whether it needs to be done or not....

I like non-sequential identifiers for resources. Easy to do in Java (with java.util.UUID) and in Python (using the uuid module). This has been a bit of a pain in Rails, until now - check out Ariejan de Vroom's post. I especially like his solution as it plays well with RSpec, although to be picky I would have chosen UUID.random_create rather than UUID.timestamp_create....

The Jersey JAX-RS project provides bindings for springframework and google-guice. However I wanted to see what it would take to use PicoContainer as an IoC container within Jersey. Verdict: not much at all. Nicely extensible. To see what I mean please take a look at my jersey-pico project on GitHub. I can now create JAX-RS services in Java or Groovy with a very simple IoC container....

Last year I blogged about a neat trick in Django to have multiple views per HTTP verb. Since then I’ve been playing with RESTful applications and decided to see if there was a nicer way to expose “resources” in Django. The following is what I’ve come up with so far. Listing: router.py from django.http import Http404, HttpResponseNotAllowed def get_handler_method(request_handler, http_method): try: handler_method = getattr(request_handler, http_method.lower()) if callable(handler_method): return handler_method except AttributeError: pass class Resource: http_methods = ['GET', 'POST', 'HEAD', 'PUT', 'DELETE', 'OPTIONS', 'TRACE'] @classmethod def dispatch(cls, request, *args, **kwargs): request_handler = cls() if request....

Recently I’ve been playing with some old Java Swing applications and I found myself wishing that I could replace all the anonymous inner-classes with some clean Groovy closures. The job of converting a java source file to a groovy source file is pretty simple and eminently scriptable. Here’s my take on a python script to do just that: from optparse import OptionParser from subprocess import Popen, PIPE import os def rename(src, dest, use_svn): if use_svn: output = Popen(['svn', 'rename', src, dest], stdout=PIPE)....

Logging - this is something we as developers do very badly - perhaps we need to ban the debugger. Unless you've worked in first-line support or in OPS, the only time you ever look at a log file is as a last resort. This is unfortunate, since the last resort may occur when you are trying to figure out why someone has lost money or when your company is about to be sued by a client (usually for losing their money, video, kids photo, etc)....

The following is just a reminder to stop me from getting confused ;-) GET Used to fetch a resource. The server sends back a representation of the resource in the response body. Safe operation (see below). DELETE Used to delete a resource. The response from a server may contain a status message or nothing at all. It is usually nice to send back at least a 204 (No Content). Idempotent operation (see below)....