I’m nearly four years on from starting with my current employer. This is quite an interesting phase of my employment, in that sites that I worked on when I first started are all reaching the stage where they’re being refreshed, upgraded or completely rewritten. What this seems to be doing is highlighting to me that there really is such a thing as Technical Debt and it really can be as evil as people say it can.
Archive for the ‘Best Practice’ Category
Discouraging the accumulation of Technical Debt
Monday, December 12th, 2011A problem with forms submitting using AJAX: how to resubmit?
Tuesday, February 22nd, 2011I’m a fairly regular user of the twitter web front-end, and of Facebook. Both of these have tremendously wide audiences and are hugely popular. Twitter recently attracted a bit of negative press from the technical community for replacing the old, fairly standard URL structure with one that uses ‘hashbangs’ and is fully dependent upon Javascript to serve the correct content. But I’ve another more user-centred complaint about Twitter (and Facebook) relying heavily on Javascript for fundamental parts of their apps (e.g. the ability to tweet, and ability to comment on stuff). That is the removal of the ability to ‘refresh’ or ‘resubmit’ a request…
(more…)
Does your website still need to be functional with Javascript disabled or unsupported?
Wednesday, November 10th, 2010We have recently been reviewing the amount of development time spent on projects, and have identified one area where a fair chunk of extra time is spent for relatively little gain: Ensuring that web sites are 100% functional with Javascript disabled. The general concensus on the web is that year on year, the number of people (even those technical in nature that browse w3schools) with javascript disabled is falling – but is this a decent reason to consider removing the true graceful degradation that most front end developers have been obsessed with for the last few years?
(more…)
Commenting code – a minor but invaluable investment of time
Wednesday, November 3rd, 2010I’m a strong believer in code being written in such a way that it is self documenting, but would not use this as an excuse for not adding in English language comments to go alongside the code. After all, comments add a tiny amount to the size of a PHP file and don’t slow down the application at all. Also, the English language comments alongside the code can be used to justify decisions or assumptions you have made, which might make the next programmer’s visit to the file a lot quicker and more productive.
Coding things the quick way – often a false economy
Wednesday, August 4th, 2010I have recently been tasked with making some changes to the central ‘library’ of code that an E-Commerce platform is based on. Essentially, the ‘models’ for this application are all in a central, shared location, and all of the ‘installations’ of the e-commerce platform have their own set of controllers and views that interact with these models. The changes I am making involve making the deletion of products reversible; so instead of actually deleting products and associated assets, a flag is merely set in the database; is_deleted = 1. This, at first glance, seems to be quite a simple task; alter the database tables to add the extra column in, and make a change to the central models in Model_Product::deleteProduct and any product ‘getter’ functions, eg Model_Product::getProductsByCategoryId. However, due to the way that the platform has been developed and individual customisations to the installations of that platform have been made, things aren’t quite so simple.
Collective Ownership of Code: Anyone should be able to fix anything that is broken!
Friday, May 7th, 2010In reading up on programming practices and ideals, I have stumbled across a concept called “Collective Code Ownership”. This essentially means that *any developer* can fix bugs or write any new feature in *any project*. Bug fixing and project development should not be limited to the person that wrote the code in the first place. This introduces both advantages and disadvantages in to project management.
Simple steps towards accurate project estimates
Wednesday, May 5th, 2010A mistake that many developers (including myself) have made in the past is to over-promise and under-deliver in terms of the absolute deadline or the number of hours taken on a project. Getting to the “missing the deadline” or “being over budget” stage can be especially demotivating – you’re costing yourself (or your company) time, which is valuable, and also the client is likely to be getting slightly irritated (if you are late). The steps or methods to reduce the chances of this happening in the first place are simple, and easy to use.
(more…)
Should you sanitise your HTML before or after you save to your database?
Monday, April 19th, 2010In starting a new project completely from scratch we need to decide whether to sanitise html (that is, convert & to &, < to <, and strip out blacklisted html) before or after we saved to database. In projects I’d worked on in the past this had been done inconsistently in different areas of the application – ie, pre save in some areas and on select in others. After having thought through the problem I think I’ve decided on which option I prefer: Sanitise after selecting from the database, rather than before saving to the database.
How I organise my project information to save time.
Monday, April 12th, 2010It shouldn’t be news to anyone, but organising your projects (and assets within those projects) in an efficient manner will save you a load of time. Perhaps not immediately, but at some point in the future you’ll be thanking yourself hundreds of times over that you took the time to organise things in the first place.
PHP Developers (and Web Design companies): Consider using someone else to check your work!
Monday, March 22nd, 2010We’ve all been there. Working flat out on a project for day after day, to finally see the light at the end of the tunnel and start to consider launching. But wait! This is a dangerous situation to be in. Having looked at the same site for so long, you’re not going to be able to spot the mistakes that you’ve made. It’s worth spending an extra couple of hours to double-check your work – rather than have the embarassing situation of launching a site with mistakes present.
