I’ve released a new version of my S3DropBox. You can now right-click on any file to download it, delete it or create a public link to it. Comments, feedback and bugs are always welcome.
Update to S3DropBox
Mar 15
Post-Redirect-Get in Rails
Mar 11
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 <insert framework here>. 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.
Whenever I play with Rails, or for that matter any other web framework, I get stuck on trying to find a problem to solve (or a set of requirements). Fortunately the Agile Development with Rails book from the Pragmatic Programmers has a nice little bookstore application that I can develop iteratively. I’ve put my latest adaptation of their depot application to use post-redirect-get (even works with ActiveResource scaffolds), UUIDs as ActiveRecord primary keys, HAML, SASS and RSpec on GitHub. Feedback is always welcome.
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. For the truly adventurous add something about clearing out JMS queues and stopping scheduled tasks while you are running the cleanup tasks.
3. Always use the same data for tests, and better still use the same data for different tests. That way you will have do perform anti-pattern 2 with no questions asked. If anyone does ask about random or unique data just scoff sagely.
4. For those tied to java, run each test in its own JVM. If you happen to use a DI framework with lots of XML make sure it is initialised completely for each test. If anyone mentions forkmode=once just pretend to ignore them until they go away.
5. Write your application so that you need a JavaScript enabled browser before you can test anything at all. Progressive enhancement is only for those who cannot see.
Catharsis.