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

5 general trends should be paid attention to in 2015. The world will be a Mobile-First World In the big smartphone times, more and more people are put more time on mobile. In the U.S., carriers' shelf-space for devices with 4.7-inch or larger screen displays increased from 4 percent to about a third in 2014 alone, matching a sales growth - larger-screen phones now account for more than one-quarter of all sales, according to NPD Group. Facebook's recent earnings report showed that while overall daily active users grew 8 percent in 2014, mobile daily active users grew 15 percent and mobile-only daily active users grew 34 percent. A Pay-to-Play Social World is coming Forrester recently reported that brand interaction on organic Facebook posts is now squeezed to 0.073 percent. Social advertising spend continues to rise, though as a whole it still doesn't match time spent overall on social. Only on Facebook has spending outstripped time spent - 6 percent of U.S. adults'

In the debate between developers and their employers, fixing technical debt is often seen as a cost centre, a time suck that takes away from feature work. After all, when there are features to ship and clients to satisfy, taking the team off such projects so that they can rewrite what already works is seen as silly, costly or foolish. But smart employers recognise that technical debt is more than an annoyance or a cost centre. They recognise that technical debt has a chance of costing them good developers. Developers hate technical debt. It's annoying, it's frustrating, and the struggle to find time to fix it is constant. Developers hate technical debt because it makes their jobs harder. It makes solving other problems harder. Technical debt, from a developer perspective, really sucks. The problem here is that frustrated developers are unhappy developers. Unhappy developers have a tendency to quit. And given the fact that hiring developers is tough under the best of circu

This refactoring is such a simple idea and you'll find yourself continually doing this as you work and build extra functionality into your web applications. There is also continual need to do this whole debugging and/or refactoring existing code. Take for example the below class: class person {   public $w;   function clchrlypr() {     // calculate hourly pay rate of employee     ...     return $var;   } } Now let's look at the below example: class employee {   private $wage;   public function calculateHourlyPayRate() {     // do some magic   } } Which was easier to read and follow?  I would hope the second snippet was clearer, however the first is an all to common sight in some projects and seeing this code makes you really have to think hard, and quite frankly wastes time  if we had written the second block of code in. The first place things would have been so much easier for our colleague.

When working with legacy code, it is very easy to get carried away and make a big bang refactoring (actually, 'code cleanup and pray' is a better term since we do not have any tests). In this case, we can try to eliminate the static cling by making the static method non static, and extracting the non-static method into an interface. Make the clients (all the call sites) use the interface. This would mean that we deal with potentially a few changes to the client code to a few hundreds in some worst case scenarios, all at one time. The result could be 'Object Reference not set to an instance of an object'. We want to be able to make this change in a phased manner in small manageable increments. Approach Pick one call site. Change in one call site. Bring it under the safety net of unit tests. Make sure the change works. Meanwhile, the other call sites continue using the original unchanged code and continue to work fine. Go back to step 1 till all the call sites ar

When your business is online, conversion rates are hot on the list of KPI's to watch month on  month, year on year.  But what are conversion rates, and how do we increase them? In terms of an ecommerce site, be this physical goods or e-goods, for example ebooks or services, the conversion rate on your site is essentially the percentage of your visitors who you manage to convert into paying customers.  People who visit your site and decide, you know what, I've just gotta have this!  And if you can make them impulse buy - even better. Here are some quick tips to increase your conversion rates: 1.  Explain the benefits - 3 C's Clear Concise Consistent Summarise the benefits and sell your product or services as clearly and concisely as possible.  Let your customers know what they are paying their hard earned cash for, and let them know quick.  Why waffle on for pages and pages?  When you meet someone in person, they make their mind up about you in the first 30 se

Previously we mentioned the pull up method we can use during refactoring our code. The push down method is the exact opposite. Let's start with some code: abstract class animal {   function bark(){     // bark here   } } class dog extends animal{} class cat extends animal{} $dog = new dog(); $dog->bark(); Maybe one day our cat had a bark about it, or maybe we've coded an if statement to do something different like return false if it's a cat.  abstract class animal {} class dog extends animal {   function bark(){     // bark here   } } class cat extends animal {} $dog = new dog(); $dog->bark();

As projects grow organically it is important to continually be refactoring your code base.  One simple refactoring technique which is often overlooked is called "pull up method". This is exactly what it says on the tin - pulling a method up in the hierarchy of its chain so it can easily be reused. Let's take an example: class vehicle { } class car extends vehicle {   function accelerate() {     // code here   } } class motorbike extends vehicle {   function accelerate () {     // code here   } } We can clearly see the duplication above of the 2 accelerate methods. What if e pull these up into the vehicle parent class?  Lets see how: class vehicle{   function accelerate (){     // code here    } class car extends vehicle {} class motorbike extends vehicle {}

All too often inheritance is used in the wrong scenarios. Inheritance should really be used when it makes logical sense, however we often see it used for convenience. Take this example: class sanitation {   public function washHands(){      return "cleaned";   } } class child extends sanitation {  } $child = new child(); $child->washHands(); In this instance child is not a "sanitation" So inheritance doesn't actually make sense here. We can refactor this to delegate handwashing by passing an instance of sanitation into the child constructor and calling it that way.   Now let's look at this example refactored child class: class child {   public function __construct($sanitation){     $this->sanitation = $sanitation;   }   public function washHands(){     $this->sanitation->washHands();   } } $child = new child(new sanitation); $child->washHands();