underdevelopment

I recently had a project with xs2theworld to help create the mobile websites for intel asia. Because this project was quite important and I wanted to step up my game I created a proper deployment strategy. No more sweaty palms while running custom scripts, pressing svn up or switching symlinks. I wanted a fully automated deployment. A deployment I could test, run and always get the same result.

Because I’ve been hearing about phing and dbdeploy from dragonbe and harrieverveer I looked into them. They ended up being excellent tools to reach my goal.

Phing is a deployment tool in which you can create a deployment “script” made up out of a ant like syntax using xml.

<copy todir="${buildDir}" >
  <fileset dir="${projRoot}">
    <include name="**" />
  </fileset>
</copy>

DBdeploy is a tool that compares your patches to your database and creates a forward SQL patch and a backwards SQL patch, aggregating your SQL patches in the forward file and the undo statements in the backwards file.

In this blog post I will highlight some of the things I did.

I created an actual ‘build’ stage, where all the website elements were processed and copied into a separate build directory. The reason for this was two-fold. Firstly I wanted to be able to check the result of a ‘build’ without it being deployed, especially the SQL patches that dbdeploy generated. Secondly, I wanted to only copy those files that were needed for the site to run. So no .git directory, no sql patches directory, etc..
This has really been a great choice, because of the separate build stage i’ve at least had two instances in which i caught a problem before deployment. Saving me from the embarrassment of having to make quick fixes while the site was in offline mode.

I created separate phing property files for different environments. (production, staging, development) this combined with a simple wrapper script that called phing resulted in a very pleasant way of deploying by just issuing a command like “./deploy build development” or “./deploy rollout production” and the inevitable “./deploy rollback production”. Much better then “phing -Denvironment=staging build”.  Property files are basically ini files that contain key/value pairs that can be referenced from within your phing build file.
Then in phing you can say “<property file=”deploy/${environment}.properties” />” and it will read the property file. Please note that “${environment}” refers to a variable. which in my case was set when calling phing. (the -Denvironment=)

Dbdeploy is a piece of software that can read your SQL patch files, compare them to the database and create a single SQL file you can run to update your database. Unfortunately dbdeploy is very fussy about the separator you use between your patch and your undo patch. Yes, undo patch. At some point you want to rollback a deployment and at that time you really do not want to find out that you can’t because the new table structure breaks the old code.
It only takes very little time to create undo statements and you will avoid excruciating minutes of frantically applying changes manually when things break.
Also when creating undo statements be sure to set them in the reverse sequence of your normal sql patch statements.
e.g.

ALTER TABLE `myrecords`  ADD `rank` int NOT NULL;
RENAME TABLE `myrecords`  TO `myrecord`;
-- //@UNDO
RENAME TABLE `myrecord` TO `myrecords`;
ALTER TABLE `myrecords` DROP `rank`;

Also, that is how you should write the undo separator. Exactly like that. If you don’t dbdeploy will simply add the undo section to your deployment SQL file as well. Which is very much unwanted.
Also be sure to always, ALWAYS, ALWAYS! run both your forward SQL patch as well as your backwards SQL patch to make sure it works. Preferably not on production.

That’s about it I guess. There are many wonderful guides that will explain how to use phing and dbdeploy in detail, which is the reason I didn’t. I just wanted to pass along some things I used and thought worked nicely.
I would like to point people who want to read more about phing to the following blog posts that helped me heaps:
- Diving into Phing I http://groups.drupal.org/node/4363
- Diving into Phing II http://groups.drupal.org/node/5400
- Phing Build File http://sean.gravener.net/blog/web-design/phing-build-file/134/
- How To: Simple database migrations with Phing and DbDeploy (*this was a bit outdated*) http://www.davedevelopment.co.uk/2008/04/14/how-to-simple-database-migrations-with-phing-and-dbdeploy/

most important though.
http://phing.info
http://dbdeploy.com/

admin PHP, software development best practice, dbdeployment, deployment, phing

Designers. Can’t live with them, can’t live without them. More often then not, developers will have to work together with designers to create a website. Which most of the time means the designer will create a design and some HTML & CSS. Which the developer will then integrate and adapt to fit into his software to actually make the site work.

The problem however is; Developers normally didn’t go to design school and many of them have the artistic ability of your average garden rock. I’m certainly no exception to that. However, if you learn a few basic guidelines and rules, you can make the life of your designer buddy a lot happier by not screwing up his design.

So here are just a few general hints and tips to explain what is important when adding something to a existing design or when integrating it into the actual software of the site.

Aligning stuff

Stuff needs to be aligned, both horizontally and vertically. It must be aligned “visually” instead of accurately, which means that if you look at it, it should look aligned. Which could mean two pixels to the right or left of the point where two blocks where actually aligned.

however as rule of thumb you can pretty much aligned them accurately. The reason for aligning stuff is because it is visually pleasing for us to look at.

In some few cases the designer might actually want to purposefully have a few elements be misaligned, so if your doubting, just look at his designs or simply ask him.

Whitespace

Where saying less is more. Whitespace, as the name suggests, is the empty space around objects. As with alignment, everything should have a little bit of white space and for the most part, the amount of whitespace should be the same.

Whitespace brings some calm into a design. A design will look far less crowded with ample use. Also, whitespace will often be used to emphasise certain elements within a design. This is where the amount of whitespace will differ. Headers for instance will often have more whitespace around them then paragraphs.

It is also always a good idea to make sure there is a lot of whitespace around important elements for your website. When there is a lot of whitespace around a element in comparison to other elements on a page, your average human will read that element first.

If you want to know a lot more about whitespace, read this article from a list apart that deals exclusively with whitespace.

colours

Colours are not only pretty, but also important. Often companies and brands will have very specific colours associated with them. Coca Cola red, UPS gold&brown, etc… Now designers could probably bore you for hours about colour theory and all that stuff. However what’s important for us developers to know, is to never introduce new colours. A designer will have chosen a small select group of colours for use in the design.

You will have one or two base colours, and a accent colour. For instance, for the design of this site, the base colours are light grey and white. and the accent colour is blue, and perhaps black.

What this means is that if I should add some new element, it should be one of those colours. Not purple simply because I like purple. Your best bet, depending on the size of the new element, would be to use the accent colour. The use of the accent colour is to basically add some spice to a design and use it to draw the attention of viewers.

When using colours, be precise. You might think, blue is blue is blue. But if your designer used #7c95e7 in his design, then be sure to use #7c95e7 as well. You could even ask your designer to write down the used colours for you in HEX.

ask your designer

Above are just a few general tips to watch for, but the best advice I can give is to simply ask your designer when in doubt or even just to verify. Because basically, It is like you created the software for the site and then some amateur takes it and start modifying it in small ways. I think most developers would at least like steer how those modifications are made, explain a bit what the thoughts where behind how it was written and such.

I have to say though, not all designers will like explaining it to you. But just remember, your not doing the above to please the designer, your doing the above to please the client, to make a better website. If that means having to bother your designer for 5 minutes, then so be it.

admin usability best practice, design, text, usability

Well I figured a provocative title like that would catch your attention, so please read on to find out I am not as stupid as you might think.

Unit tests are great, they reduce unknown bugs and arguably lead to better object design. The reasons for this are simple; Well thought out unit tests will force you to think about the input and output of any method your objects may have, forcing you to correctly decomposition the needed functionality within your object, because methods that have too much responsibility are a pain in the ass to write unit tests for. Simple one task methods however are easy to write unit tests for. Because your writing unit tests you are (hopefully) actively thinking about what can go wrong so that methods can actually fail.

So taking for granted that the above is true, why does test driven development suck?
Well the answer to that is a market one and really only applies to professional business. When a client comes to your business and asks for a offer for his project, you will quote him X, where X is roughly the amount of hours it takes to create the unit tests and then fill in the code + other stuff.

A development house that doesn’t use test driven development will quote that same client only for the time it takes to write the code + other stuff. We all know that after that he will spend a few weeks/months bugfixing, but that’s not what he quotes or tells the client.

Naturally the client will more often then not choose your competitor, unless you can positively convince him that the extra hours you spend will actually save him money in the long run. Which from the clients standpoint is a bit of an unproven claim if he is not technically inclined. So from a business standpoint, test driven development sucks as a selling tool.

Secondly, while this heavily depends on the morality of your business, those bugfix hours can be profitable. Depending on how smooth your talk is, you could very well be billing the client for those hours.

Thirdly, test driven development often suffers when deadlines need to be met. We all know that estimated hours is an imperfect science and often goes wrong, be it overconfident developers or overselling sales people, deadlines tend to be missed in our industry. So when deadlines are creeping, unit tests are often one of the first things to be dropped off schedule. Yes, we all know that shouldn’t happen, but it does. Once this has happened and no extra time is allocated to bring the tests up-to-date again (good luck getting that approved), the test driven development has failed and you’re just plainly developing again.

So for these reasons I think test driven development sucks. I might sometimes use it for private projects or open-source projects (for which I think it is absolutely brilliant), but certainly not for business ones. With the possible exception of in-house developed products, but I haven’t had much experience with that.

For anyone who now still thinks TDD is a sound development methodology, I would be very interested to hear you thoughts.

admin PHP, software development best practice, object oriented programming, PHP, pragmatic programmer, TDD, test driven development, unit test

Now this piece of wisdom is actually not mine, but from a colleague at ibuildings. He basically states the following; “If a client or user ever finds a bug or a security hole, then don’t ever say ‘Oh, i knew about that’.”

Now the observation here is that sometimes while you are reading older code you will see a bug or security leak. Often enough you will think “Oh well, this is old code and has been running for years”. That however is not the right thought to have.

The right thing to do is to estimate how many hours would be needed to fix it and what the impact of the problem is. If you then have enough time, you fix it. If you don’t, you register it and escalate it to the person responsible of the project.

At least then, you don’t have to say “Oh, I knew about that”. This phenomena is closely related to that of the broken window effect*, which teaches us that it is human nature to not fix the window. It is therefore wise to always keep the above in mind, and consciously force yourself to do the right thing.

So next time you see a bug, don’t say to yourself that you will fix it next week, because we both know that will probably never happen.

* This effect is wonderfully described in the book ‘the pragmatic programmer‘, required reading for any programmer if it was up to me.

admin software development best practice, broken window, pragmatic programmer