I 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.
Archive for the ‘Best Practice’ Category
Coding things the quick way – often a false economy
Wednesday, August 4th, 2010Collective 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.
