William Cameron | Beyond the Keyboard

As Christmas approaches, many ecommerce sites look to optimise their sites so they can be found in search engines, increase conversions and ultimately boost sales.  One of the most obvious ways to do this is update (or write) product descriptions across the site.  Usually if you're an ecommerce site, you sell products online, and the item or product page is where most customer decide to add that product to their cart. Here are some ways not to write product descriptions. 1) Focus on features - Many retailers focus on the features of a particular product. This doesn't sell your product, you should instead focus on benefits.  Why do I need this 48" LCD TV?  You might be tempted to write on your product page, 'Amazing 48" LCD TV, Flatscreen, 4 HDMI ports, USB and flashing lights..".  Yes this is useful, but is it making me want to buy it? may be... but what if you focused on the benefits? 'Stunning 48" HD Flatscreen LCD Television, perfect for wat...

Every developer should be running some form of static code analysis on their code regularly. A recent article I read about how this is done at Etsy makes for what I believe should be a minimum standard of code analysis for any team of developers work on a shared codebase. We shall assume you are committing your codebase to some form of version control on a regular basis. The 3 layers can be summarised as: Sanity Checks Formal Checks Security Checks Sanity and Syntax Checks In Stage 1 we perform basically a sanity check of the code. Are there any errors, missing semi-colon's or just plain stupid things being committed to our repository and code base. This is essentially a case of running php -l against all our files being checked in or changed to make sure we catch these before they are committed and let you fix them before they are picked up by the wider team. Formal Checks This stage involves a more global analysis of the source code files, checking for thin...

PHP 5.4 introduced the concept of traits. Until Traits PHP used a classical inheritance model in which one class could inherit only one class. In simple terms; before PHP 5.4 PHP used the single inheritance model which made it difficult to reuse the code. Traits allow developers to reuse sets of methods freely in several independent classes living in different class hierarchies. Traits are a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance by enabling a developer to reuse sets of methods freely in several independent classes living in different class hierarchies. The semantics of the combination of Traits and classes is defined in a way which reduces complexity, and avoids the typical problems associated with multiple inheritance and Mixins. A Trait is similar to a class, but only intended to group functionality in a fine-grained and consistent way. It is not possible to instantiate a Trait ...

Account Management should be methodical. A process to work through to ensure nothing is missed.  The best way to do this is to remember 4 key stages. The four key stages in account management are: Recognise – The needs of the business, the customers' requirements and the role of the account manager Evaluate – Our current customer base, prospect list, category and planning process Act – On our plans, the sales process and required resources Learn – From what we've done, sharpen the axe and move forward

If you are wondering how account management could cause you to lose a client, please pay close attention. In my experience, account management is almost as important as results. Clients typically terminate accounts when they are confused or just plain frustrated with you. What are the common account management mistakes you should avoid? What are the best tips for success? Account Management Mistakes You Should Avoid 1. Not writing a fresh email One of the biggest mistakes I see people making is sending an email to their client with all of their internal correspondences included. In other words, they went back and forth a few times with colleagues, and instead of writing a fresh new email, they just replied to the client from the last email they received from their colleagues. This allows the client to see what you are saying back and forth to one another. Depending on what was said, you could really end up with your foot in your mouth. 2. Not being prepared It's so easy to ju...

Dear Reader, Client: "I just need a blog." "It's just a website." "I just need a shopping cart." In our industry “just” is a red flag, especially when it is coming from a non-technical person like a client or manager. When you hear “I just…” in a discovery meeting, immediately stop and dive deeper. Unpack their entire idea until you are clear what they are asking for and you can described it back to them. Ask for clarification. Keep digging until you have explored exactly what they are “just” asking for. Software development is a process of details. “Just” helps someone gloss over details and only look at the big picture. Like the iceberg that sunk the Titanic, most of the details of any software project is beneath the surface. The next time you are tempted to say “I just need…”, just stop. Amazon.co.uk Widgets

Somewhere, right now, a project manager is compiling estimates on a software project and coming up with a completion date based on “velocity” and “scope”. When they’re done, they’ll take their completed work and show it to their boss, who will look it over, and set a “hard date” for delivering the project. There will be a team meeting, the developers will be gathered, the plan will be presented to great fanfare, and everyone will go off to work, expecting that they’ll actually meet the hard deadline in three months. Three months will go by. The deadline will come and go. And in most cases, the deadline will be sorely missed. You can probably guess what happens next. Executives will be furious. Project managers will blame the “lazy” developers. Developers will blame the over-zealous estimates of the project managers. There may even be a death march. At the end of it all, much if not most of the developer team will quit, the executives will vow “never again”, and the resulting proje...