An assumption: software programming and engineering is hard. Abstracting the world and put it in a computer is a complex task and the knowledge of the concerns of our job distinguish us from the script kiddies. The zone, or flow is the particular mental state in which a person is fully immersed in his activity, and reports great advance in his work, enjoying it. The flow is tipically killed by interruptions of the work and is difficult to reach before a quarter or even an half hour of working.
This post is inspired by Getting Things Done, the book from David Allen that teach techniques to enhance your productivity and your focus.
A simple collecting process
In an agile world, monolithic analisys of requirements and design has not place, but simply writing down in detail the actions you are going to take for a task accomplishment is a technique that has only advantages compared to the small time needed:
- it forces to search a way to do the task, and once a ten steps to ... is in place you will find easier to find the energy to do all those things. This is far the most important technical advantage: when you jump in coding you won't find a list with integrating a dojo grid, but writing a view helper for the datastore, writing a view helper for the grid itself, make sure it is tested on this particular use case, and so on. We'll talk later on how this affect the time you will spend to reach the zone.
- naming things gives man power over them: as philosophers says, finding early an ubiquitous name for the components of your software will help you to build a mental model of it.
- you can write details whenever you want, because little energy is required. The only constraint is to have mental focus on the problems you are watching, a thing that once you go further and further in a project is very likely to be automatic.
- you can find out if a task is impossible to do or it has to be postponed: if you can't find a step-by-step process to accomplish it, probably the reason is it will be impossible with this specific requirements, or it will be a great time-sucker while you can find an equivalent feature that can substitute it and do less.
- you can cancel out subtasks when you have completed them: when you're talking about high level goals there's not even a definition of done, while decomposing them gives you a medium sized list to write + on when you have write some tests or implemented a specific class.
- in general, jump right to the coding phase is not a good idea. TDD can help to stay in the zone while developing a specific class/component/unit/procedure, but firstly you have to define what the classes are. Obsiously there's no need to write a Uml-compliant diagram or a [insert buzzword here] model, but the power of plain text can help.
Find a way becomes easy if you refactor ideas
During the day I set up my todo list and write in plain text files every idea that comes to my mind, being sure that it will not be lost in the recess of my memory. I simply accept that I cannot find a road that leads to my feature at the very moment when I write its name on my list.
In the evenings, when I have still ideas but I am too exhaust to do real work, I read feeds and develop my todo list, applying the process described above. After every task (features or enhancements to Ossigeno for instance) I write an indented sublist that decompose the task in the steps needed. Then I repeat the process with the subtasks which I find interesting at the moment, and on whom I have much inspiration.
What I end with is a list with various steps that are very low level; when I wake up in the morning, I can focus on the project very quickly. I find this written notes very useful to keep an eye on the whole situation and to always know the next action I have to take. Like doing TDD, starting by doing low level tasks that tells you all step by step is a powerful way to reach and stay in the zone. In TDD the steps are red/green/refactor, while here they are read/implement/enjoy (and maybe writing a blog post about it).
A live example
Last week, I was wondering how to protect the /scripts folder of Ossigeno, that contains the installation scripts and other admin features. Before I jump in developing an authentication system against a Kerberos server, I write down this task in the to-do list of Ossigeno.
Later, I refined the task and see that this could be simply done with a couple of .htaccess/.htpasswd files in the scripts/ directory: the idea was producing a generated couple of files basing on an installation form data (username and password). This requires the two files or the folder to be writable, and the generation of .htaccess is also needed because the authentication system of Apache needs an absolute path to the .htpasswd file, that depends on the specific deployment. Moreover, the htpasswd file contain a crypted password and I also had to find its format.
With further refinement, it became clearer that some subtasks were not so hard but a bit longer to implement to be justified by the value they provide, and I deleted the generation of htpasswd and form part; please note, before to reallly write it. This is the most powerful refactoring, because it's done even before writing the code.
The final solution was to write on installation a generated scripts/.htaccess file to point to the realpath() of the htpasswd file, basing on a template. The user is free to substitute the included htpasswd file containing default password with what he wants. The coding was done and tested in five minutes, once I know how and what to code for.
And that's the point of idea refactoring: find the simplest way to develop a feature by leaving your subsconscious brain working on the problem during the day.
- findAll() and findOne*() does not hydrate the object. If you obtain a collection or a record with one of these methods, a subsequent access to a relation would raise a new query to the database. Hydration should be your repositories concern, and you have to decide what relation hydrate by default.
- you can generate table classes, with proper options set in Doctrine facade calls. "generateTableClasses" is the option needed, see the documentation for examples.
- fixture keys are unique throughout the whole set of files imported. This means that if you have a bunch of yaml files where you write fixtures, you have to make sure that the keys of the various records are all different, so don't use 1, 2, ... as keys, but meaningful names instead.
- unlink() is not permanent until saved. From version 1.1 of Doctrine, until you call save() on a record, unlinked relationship would not be reflected to the database. A more consistent behaviour than the previous 1.0 version one, where unlink() will automatically save changes when called. For a deep model introspection, it is better to have a single point of saving as we have now.
- Doctrine validation is turned off by default, so every save() might not saving all the data, resulting in truncated text fields...
- ...but if you turn it on, remember that a form value of "" on a integer field will result in a non valid record and save() will throw an exception().
- Doctrine many-to-many relations are bidirectional. So even if you don't define a side of a m-n relationship, it will be present in the record and will be listed by methods like toArray() when hydrated.
- The methods getRelations() and getColumns() of Doctrine_Table can give you a lot of introspection of the model from the script point of view. In my case, I was able to generate form elements and subforms according to the business object structure, for instance a dojo DateTextBox with a sexy calendar to represent a timestamp model column.
- __toString() is very useful in a Doctrine_Record subclass, putting together the identity fields of the object to represent it for various purposes like dumping or putting it in a list.
- __call() is also very handy in a decorator for a Doctrine_Record or Doctrine_Table object, used for proxying to the underlying instance methods.
Hope this tips help you to follow the Doctrine... :)
