Book Review: Practices of an Agile Developer

Practices Of An Agile Developer
Venkat Subramaniam, Pragmatic Programmers.

Summary

I like this book - it's a keeper. It's the sort of book you'll read and then want everyone on your team to read. Agile methodologies feel natural to me as a web developer and this book is a great introduction to the general principals.

Quick introduction to Agile Development

Agile Development is a modern methodology for developing software. The core concept is that rather than developing a project to a fixed timeline (X-weeks design, Y-weeks coding, Z-weeks testing and so on), you develop in small iterations of N-weeks, where a mixture of design, coding, testing all take place.

At the end of an iteration you show the Customer what you've got and gather their feedback. You then set off on the next iteration... rinse and repeat until you're project is complete and the Customer is happy.

Agile for PHP

The techniques explained in this book feel very natural to me as a Web Developer. Coming from a self-taught background and learning web-scripting languages, I've not been exposed to "Proper Formal Development" methodologies but over the years my process has evolved towards an Agile style.

There comes a point, when the self-taught solo programmer needs to join a team or needs to formalise his/her development processes and Agile just seems to fit nicely. We use concepts like "test early" without even thinking about it (like running your script as you make changes for example).

I think many web developers will find that Agile Methodoliges is more about formalising their techniques and development environment rather than introducing a radical change in how they work; howerver this process of becoming organised and getting into the rhythm is likely to greatly improve productivity for very little real investment.

The Book

This is a very easy read. You won't get bogged down with code examples or have to think too much. It's less than 200 pages long which is about 1/2 an inch - this isn't a door-stop.

I think it's aimed at somewhere between junior and senior developer level: beginners without real-world experience might not appreciate the problems that get addressed (and perhaps should be mentored directly); lead developers should probably know all this stuff (although this is a nice refresher / reassuring read).

If you don't work in an environment with things like Unit Testing, Source Control, Documentation, Bug Tracking, Automatic Deployment... then it's definitely worth a read. If i was managing a team that didn't have these things setup then i'd buy everyone a copy of this book.

I think it's particularly good for developers who are self-taught and/or work in an environment where things are very... "loose". I think Agile is a great "next step" for developers that are down with PHP5 and OOP, and want more structure in how they code (the dev environment).

It covers a lot of ground but doesn't go into each area in depth - this is a nice introduction to Agile development.

There are nine chapters:-

1. Introduction (Agile Software Development)
   
2. Beginning Agility
3. Feeding Agility
4. Delivering What Users Want
5. Agile Feedback
6. Agile Coding
7. Agile Debugging
   
8. Agile Collaboration
9. Moving To Agility

Each chapter starts off by telling you what is in the chapter; it feels a little awkwardly written in some places, almost written for the sake of being written, but in others it lays down the motivation for the chapter and gives a taster of what is to come.

The chapters then are split into sub-topics that start with a "BAD" statement; proceed to explain the Agile way; then give you the "GOOD" version of the first statement; then "What it should feel like" (when you implement these techniques); followed lastly by a "keeping your balance" section, which are hints/tips to avoid over-using the practices and "keeping it real".

Eg:-

BAD WAY OF DOING SOMETHING!
The Agile Way! Explanation of techniques/concepts/ideas
GOOD WAY TO DO IT
(Ps, this is what it should feel like, so you know when you're doing it right...).
(... but don't get carried away, think about these things...).

I liked this consistent structure. There were also simple (trivial) "real world case studies" interspersed in the topics, which came across nicely to relate the concepts to concrete examples that made you go "AH!".

After reading the book you'll have a good idea of how an Agile Project works. It does lack depth in some areas, but i think that works in its favour overall (how easy it is to read).

Wrap Up

A good introduction to Agile development. It lacks depth but not in a bad way.

Definitely a great book for developers who don't do things "the agile way" and want to learn how.

Reduce Comment-Spam with CSRF protection?

CSRF (cross-site request forgeries) is security lingo for when a request (typically a POST form submission) is submitted to your site by someone NOT on your site. Read more about CSRF if you're not familiar with the concept.

Comment Spam is when a spammer automatically adds comments to your blog filled with links to their products. They do this by having their bots submit comments to your blog, via "add comment" form on your blog.

This is essentially a CSRF.

So, if one applies common anti-CSRF techniques (such as a hidden field with a session value) then the spammer's bot must first load the blog URL before submitting the field - and they must load the blog page again each and every time they wish to submit a comment.

Sure, this isn't a magic bullet for blog spam but i wonder how much it would reduce... (until the spammer wisens up of course).

http://jenseng.com/archives/000054.html made me think about this (He uses different submit url for the comments... which is similar to a token based approach).

Framework Data/ORM Abstraction Layer

Random late-night thought: how long before someone starts working on a PHP "Framework Data/ORM Abstraction" layer? By which i mean something like PEAR::DB but instead of abstracting a database the layer abstracts the ORM implementations of a framework.

Let's say i'm an application developer writing Some Cool Module that i want people to use in their own code, independent of the framework that they may or may not use. My code has to store/retrieve data from somewhere to populate its objects, but i don't want to tie the end-user-developer into my implementation. The idea is that my code "plays nicely" within its host environment and makes no assumptions about things like databases /connections/storage - it just needs to know how to CRUD an object.

I could maintain distributions of My Module for each framework (but that would suck big-time). Instead i design My Module so that it defers the CRUD operations to some other object - an object that is specific to the framework. That object would return a standardised "Model" object that my code could then carry on working with.

Tada! The Framework Data/ORM Abstraction Layer is born! We even have a cool acronym for it - FORMAL (haha). FORMAL is to Frameworks what PEAR::DB is to RDBMSes.

I'm pretty sure this is a really stupid idea, by the way. But - i do like the concept of not coupling ORM into My Module...