We are pleased to announce the launch of www.sparesnextday.co.uk – a site offering consumables like hoover bags and moving on to a vast array of other domestic spares.

The challenge here has been in presenting products like vacuum bags for sale in a way that allows the customer to find their exact item easily, whilst offering a broad range of both genuine and compatible choices.  With an off-the-shelf ecom application, this becomes more and more of a challenge as the product range expands.

Simplifying Choices

Our work for Kiki James demonstrates this pretty clearly. We targeted this work to the two most popular areas of the site. Previously, viewing a given page within these areas didn’t fully demonstrate the range of products available. Much of this information was hidden within a dense hierarchy of product types, colours and sizes. By including the filter on the category page customers should get a much clearer idea of the choices available. It also makes exploring the products a much simpler affair.

There were a number of interesting challenges – most notably making sense of the data on the site, in order to be able to sort in a way that would be accessible, particularly to new users, who make up the majority of Kiki’s customer base.

Creating the options

A good example would be the colour selector. To date, there are something like 77 different swatches available on the site overall. We chose to simplify the selection; a smaller series of generic colours were chosen, and all the swatches in the category were organised under those, giving us 10 colours to choose from. We followed a similar process with the shape and size selectors, organising the data into a smaller set of user-friendly choices.

What was most interesting is that once the data was shown in a more open fashion by the filter page, it made it much clearer to our client that they needed to change some of the existing product titles, as well as add some extra information to make the data work with the filter.

Quick launch

We focused on getting this released as quickly as possible; we were confident that this would be a real improvement over the existing site. But also, by releasing early over a limited part of the site, we have a chance see how our current implementation works, and tweak it before we roll it out further.

You can see the filtering in action on the Leather Photo Albums and Leather Journals pages.

The various reports and discussions around HTML5 in the past year have been a source of much confusion. In order to do my bit to help clear that up, I thought I’d offer a broad overview of what it is, and what it represents for the web.

Should I care and why?

Yes. But why? Well, there are a few ways to answer that, which I’ve tried to elaborate for you below.

Process

One of the biggest differences between HTML5 and previous markup specifications, indeed between HTML5 and any other web standard, is the process that is being used to put it together. Generally web specifications are created by the W3C using working groups who draft specifications in a closed process that has left some people dissatisfied.

In a break with this convention, HTML5 has been developed externally to the W3C by a group called the WHATWG. This group developed as a response to dissatisfaction with the W3C’s direction with XHTML and “…apparent disregard for the needs of real world authors.”

Although still driven in the main by browser vendors, WHATWG does use a much more open process, developing the spec for HTML5 through a mailing list that anyone can participate in. This has lead to a process that is faster and better supported by the web development community as a whole. So much so that HTML5 has now been formally adopted by the W3C to the detriment of XHTML2, their chosen successor for existing markup standards.

The other key aspect of the process is that HTML5 is being implemented incrementally by browser vendors. So although the projected completion date for the specification is 2022, there are aspects of HTML5 available right now and more will become available as time goes on.

Applications

The explicit focus of HTML5 is on applications. HTML’s origins as a document markup language are in stark contrast to the rapid developments in functionality and complexity present in many modern day web applications. HTML5 represents an attempt to go beyond documents and create a markup specification for structuring applications as opposed to documents.

We can see this in many of the new elements being created within HTML5, such as section, nav, aside. These are based on common conventions that are currently implemented by using class and id attributes on HTML elements like div, ol, code which all pertain to elements of a written document. So where we might currently have

<div class="article">
  <div class="section">
    <h2>This is a section of a larger document</h2>
    <p>Here is some text in this particular section</p>
  </div>
</div>

in html5, we would structure it something like the following;

<article>
  <section>
    <h2>This is a section of a larger document</h2>
    <p>Here is some text in this particular section</p>
  </section>
</article>

Perhaps more significant are the number of new APIs being specified, which will allow greater access to browser functions for web developers, as well as extending browser functionality to allow web applications to take on more of the advantages of desktop apps.

Best known is canvas, a 2d drawing api, which is already implemented in recent versions of Firefox, Safari, Chrome and Opera. However, just as significant are APIs that will allow offline web apps, drag and drop, video and audio controls, cross document messaging and text editing. Again, like the new elements, these are things that currently exist in web apps, but mainly through cumbersome and insecure javascript implementations that often are highly non-standard.*

Openness

HTML5 is open in two ways; firstly its open in terms of how it’s details are discussed and written. However it’s open in much broader sense; no one person owns HTML5, or indeed CSS3, or Javascript. This is important as we consider how the web is progressing today. Basically, if you wish to make a complex web application, you have a few choices; web standards technologies, Silverlight, Flash, Java Applets. Ok, that last one was a joke, but you get the picture. But really these choices are just two; open web standards that are not the property of a single company, or proprietary technology which is owned by one company. I realise there are good arguments on either side of that particular debate, which I don’t have time to elaborate here, but my personal choice is for standards, mainly as I feel more confident that more of my target audience will be able to access them.

So, there are a few reasons why you should pay attention to HTML5. To be honest, before I took the time to investigate it for myself, I wasn’t convinced, but I’m glad I did. HTML5 is not perfect, but that’s the point. It’s the first web standard that admits of its own imperfection, makes room for change and addresses the realities of modern web development, which overall seems like a good thing to me.

I’m not going to go over installing Ruby, MySQL (you need version 5.0), Apache etc as there are a million and one tutorials out there. I will mention however that you can save yourself some time by simply connecting to your development server (remember, you will need to open up your SQL server for remote access). I’m also not going to go over setting up selenium profiles as I’m assuming you’ve already got your tests running under a *nix environment.

Now once you’ve got your applications installed and checked out a copy of your code you need to make sure you have the right gems – exactly the same set as you needed on your development server, although I would also recommend win32console as it will give you the text colouring on your test output (and also randomly remove all of the letter As. No, really!).

Now comes the fun part. There are a series of hacks you need to do to Ruby and its gems to get them working under Windows:

• Install MySQL 5.0 if you haven’t already and copy libmySQL.dll from the MySQL bin folder to the Ruby bin folder, overwriting the default version.
• Change any reference to IP ‘0.0.0.0’ to ‘127.0.0.1’ in the webrat gem. This is needed because Windows will not view ‘0.0.0.0’ as localhost.
• Add ‘start’ before the ‘mongrel_rails’ command in the ‘start_command’ function in ‘\selenium\application_servers\rails.rb’. This will cause the mongrel server to be run in a new console window which is needed because the mongrel *nix detach flag does not work in a Windows console.
• Add ‘-interactive -forcedBrowserMode iexplore’ to the start command in ‘\lib\selenium\remote_control\remote_control.rb’.
• Increase your timeouts
  • Add ‘config.selenium_browser_startup_timeout = 50’ to your selenium profile.
  • Timeouts also defined in ‘\selenium\selenium_rc_server.rb
• Make sure you have your browser set correctly in your selenium profile with the correct path. Something along the lines of:
  • config.selenium_browser_key = ‘*iexplore C:\Program files\Internet Explorer\ie.exe’

Then run your tests and you should find your tests running quite happily.

• Restricting your controller functionality in this way naturally prevents you from building bloated controllers
• It ensures that the layout of your code doesn’t become too obfuscated
• It allows you to make calls without having to specify your controller action explicitly in the request (as you do in a normal HTTP GET request).

Basically RESTful development is all about nouns, and a complete RESTful design will have the entire functionality of the website broken down into nouns that can be manipulated exclusively by CRUD operations. Each noun will be a controller (and often but by no means always it will also be a database model) and each controller will have up to four functions to represent each CRUD action.

For example take very simple online CMS with a database of users who can log in and change the text on various pages. A RESTful design might look something like this:

Noun – ‘user’
POST – Create new user
GET – Read user details
PUT – Update user
DELETE – Delete user

Noun – ‘page_text’
POST – Create new text
GET – Read text
PUT – Update text
DELETE – Delete text

As you can see, RESTful design where the nouns are models is very very straightforward and logical. But what about allowing the users to log in? We don’t have a ‘login’ model in the same way as the users and page_texts, but we can represent the action in a very similar way:

Noun – ‘login’
POST – Log a user in (create a ‘login’)
DELETE – Log a user out (delete a ‘login’)

And if we wanted the ability to preview new text before saving it:

Noun – ‘preview’
POST – Show (create) a ‘preview’

Now everyone knows how to send GET and POST requests but what about PUT and DELETE? Despite being part of the HTTP protocol since day one they are surprisingly under-used. All modern server-side languages should accept these as valid HTTP methods but in practice the PUT method is rarely used for an update operation as this can be distinguished from a create operation simply by the presence of a key relating to the noun that will be updated:

POST request with no key – Create
GET request with key – Read
POST data with key – Update
DELETE request with key – Delete

It really is that simple. It doesn’t take much thought to break down any operation into one or more nouns with one or more of the CRUD operations being performed on each. Do that and you’ll be programming RESTfully in no time.

We’re proud to announce that as of today one of our developers, Lee Hambley has taken over maintenance of capify.org. For many people involved in Ruby on Rails development, Capistrano is a vital tool, making the whole process of maintaining production environments that much simpler, by automating and combining many of the more laborious and repetitive tasks involved.

Having been an active member of the user group for sometime, when Lee heard the sad news that original developer Jamis Buck had to give up maintenance of the project, he offered to take it on.

I’m really excited about working with the other contributors to maintain and improve Capistrano and it’s documentation, watching the project gain speed now the code is a little bit more free is going to be awesome. – Lee

He will be hosting and maintaining the Capify.org site, as well as consolidating and hopefully coordinating new developments to the gem when a new code maintainer is selected. Find out more about Capistrano by visiting capify.org, or the Capistrano google group.

I must be a masochist or something. How do I know this? Because not only have I chosen to follow web standards, but I took it upon myself to become the advocate for web standards here at Setfire Media.

Having spent some time looking at standards, it occurred to me that one of the hardest aspects of the subject was just getting some basic overview of the whole thing. With that in mind, I present here the Setfire Media Simple Guide to Standards:

1. Make sure you use the correct doctype

There are few different flavours your can use, but your best bet would be either xhtml 1.0 transitional (you can use tables for layout) or xhtml 1.0 strict (tables for data only, thanks). However, it should be said that if you’re serious about developing to standards, you might be better off going for a strict doctype, as trying to keep a strict doctype valid will help you learn standards better Find the doctypes here.

2. Validate your markup

Assuming you’ve chosen the correct doctype, you’ll want to make sure your document validates. It’s probably best to do this regularly throughout the dev process. It’s a good way to familiarise yourself with standards, and a validating page should be a bit easier to debug when you hit problems with your css. Go direct to the validator page and insert your website’s url, or install something like the webdeveloper toolbar, which will allow you to send the page to the validator from a right click.

3. Markup for sense, not style

Jeffery Zeldman’s phrase, not mine, but I picked it out as it sums up much of what standards are about – that is trying to keep your markup free of presentational elements, and using tags to describe the content of the document, not it’s visual format. It’s worth repeating this as your mantra when you’re putting together a fresh piece of markup.

4. Use divs for marking out sections of documents.

As people got used to not using table tags for layout, divs became a popular tool instead. However it often transpires that too many divs are used, and in the wrong way. Divs are for splitting your content into meaningful chunks, and shouldn’t really be used for anything else(although sometimes people do).

5. Separate, separate, separate.

That’s once for content, once for style and once for behavior. Make sure you keep them apart, it’ll make your life easier, and separation is important if you want to optimise the loading time of your pages. The essence of this is, don’t use inline css, or inline javascript in your markup. You should also refrain from inserting inline css with javascript – try to aim for unobtrusive javascript instead.

6. Use class and id tags meaningfully.

These tags are a great way to add meaning to the document, as there’s only so much you can do with the html/xhtml tags. But make sure you use them effectively. Try to avoid here are presentational related tags like class=”top left” or plain incomprehensible acronyms like id=”nlp_id_32″. Use natural language that describes the content of the tags where possible. E.g. class=”illustration” or id=”main_content”. You and other devs who have to deal with your code will find it a lot easier to interpret these names when editing the content at a later date, and they’re less likely to go out of date if layout changes.

7. Use each id tag once, use class tags many times.

Id tags are supposed to be for unique elements on the page, for example the main navigation. Class tags are repeated, ideally for elements that share common properties.

8. Use tables for tabulated data

These days one of the biggest misconceptions around standards seems to be that you can’t use tables at all in standards markup. This isn’t true, you just need to use them for their intended purpose, i.e. tabulated data. In fact, you can even use them for layout if you want, as long as you’re using a transitional doctype. But don’t for the love of god use nested tables. And really, you shouldn’t need to use tables for layout at all, if you know what you’re doing.

9. Visit these websites:

If you need to learn more about standards, how to develop to them, or keep track of new developments, then you’ll find the following sites very useful:

• css-discuss
• alistapart
• 456 Berea Street – developing with web standards
• Opera Web Standards Curriculum
• For a Beautiful Web

That’s all for now

Well, there we go. Hopefully that’s going to help you get started on the road to standards-friendly markup, and reduced any associated stress and anxiety. I also hope that it goes some way to demonstrating that the basics of standards are not too hard to grasp(I mean, if I can do it, anyone can).

“Why would you do this?” you may ask. Well quite simply I am in a team building a new data management system to sit on top of a legacy system with its legacy database, we want to create something similar to https://docs.couchbase.com/server/current/learn/buckets-memory-and-storage/buckets-memory-and-storage.html. All the new code is new, shiny and streamlined and the old code is… well… crap but we have to keep both systems running concurrently so we have various tables in the legacy database we need to access from the new system. As it happens we need to access the legacy users table in a ‘has_many through’ from the new ‘orders’ table.

Set Up Your Secondary Database Connection

You can quite happily set up a model to connect do a database other then the default by setting the connection up in your ‘config/database.yml’ as follows:

legacy:
  adapter: <adapter>
  database: <database>
  username: <username>
  password: <password>

And then in any model you want to use with your secondary database:

<model>.establish_connection configurations['legacy']

Create Your ‘Through’ Model

Now a normal ‘has_many through’ just plain won’t work between models attached to two different databases but a normal has_many will. So we can create ‘has_many through’ functionality in the following way:

Set up your ‘through’ model on either database. It really doesn’t matter which and set it to ‘belong_to’ your two main models.

Set both main models to ‘has_many’ of your ‘through’ model.

Create Your ‘Through’ Relationship

Use the following code in each of your main models to mimic the ‘has_many through’ association. In this example I’m using ‘orders’ and ‘users’ and my ‘through’ table is ‘order_users’:

In ‘order’

def users
  user = []
  order_users.each do |ou|
    user << ou.user
  end
  user
end

In ‘user’

def orders
  order = []
  order_users.each do |ou|
    order << ou.user
  end
  order
end

And you’re done. Now the relationship will work just like any other ‘has_many through’.

So here’s a rundown of the top tips I can give for making your financial calculations that bit easier.

1. Always Work in Minor Units

I can’t stress enough how much this helps in terms of accuracy, rounding and speed. Working in major units may look better to you as you don’t have to reformat the numbers to display them but I hope I can make the case here for minor units.

a. Integer arithmetic is much much faster than floating point arithmetic.

Remember that even a single decimal place makes a number a float as far as your computer is concerned and all the processor overheads that go along with them suddenly arrive. I know it’s not a lot slower but in a complex financial system it all adds up believe me.

b. Floating point arithmetic can get its sums wrong.

Don’t believe me? Then pull up a Ruby console and try this:

a = "69.54".to_f
b = a * 100
b.ceil


Gives 6955 instead of 6954. This is because the limitations of floating point arithmetic have caused something like 0.0000000000000000000000000000000000000000000000001 to be added to 69.54. I spent a good 4 hours chasing this bug which manifested itself as a 1p discrepency.

c. Trailing zeros can cause problems for major units.

Think of trying to pass round £10.00 or £1.10 in major units. Storing it as a float you would keep losing the trailing zeros and would find yourself having to sprintf all over the place. I’ve seen plenty of systems in my time that store prices as decimal strings to get round these issues!

There are of course various decimal formats that can be used (decimal is a data type in MySQL and BigDecimal has been introduced in Ruby on Rails) but when it comes down to it, these are just wrappers around either floats or stings and majorly sub-optimal for the other reasons given.

2. Freeze the Exchange Rate

If your business works in pounds but you allow payments to be made in Euros then with every payment you need to store the current exchange rate with it. Exchange rates change by the day and if you don’t know exactly what rate you get for your transactions then you can kiss goodbye to any sort of accurate profit calculations.

3. Rounding: Pick a Direction and Stick With It

Often you will need to apply discounts, add markup etc and have to perform percentage calculations. If you are working in minor units this should be the only time (in normal day to day operations) that you ever have to handle fractions of pence. You will make your life so much simpler if, for all these calculations you decide the direction to round and stick with it. Do you want to keep the extra for yourself or be a nice guy and let the customer keep it? That’s what the decision comes down to.

If you don’t have consistency in this you really will find yourself spending days chasing 1p discrepancies.

From a coding point of view I tend to round down as preference because (as I demonstrate above) floating point arithmetic can get it wrong sometimes and, as it just wipes out everything after the decimal point, a ‘floor’ function is much more reliable that a ‘ceil’.

4. Use a Pre-Filter On Your Submissions

Of course your customers are always going to want to work in major units – no-one wants to see prices in pence splashed all over your website and it’s much more intuitive to type major units into form fields.

What I like to do is put a pre-filter on all input coming into my back end system (so in Rails you would run the filter on ‘params’ or in PHP you would run it on ‘$_REQUEST’) which pattern matches any string monetary amount (remember, all form submission values come through as strings) in a major unit and converts it to an integer minor unit.

In Rails it’s in the application controller and looks like this:

def filter_units (input)
 if [Array, Hash, HashWithIndifferentAccess].include?(input.class)
  input.each do |key, value|
   #recurse through the data structure
   input[key] = self.filter_units(value)
  end
 #match the string format for a major unit
 elsif not input.nil? and input.match(/^\d+\.\d\d)$/)
  #convert to a minor unit integer
  (input.to_f * 100.0).to_i
 else
  #return the value unchanged
  input
 end
end


This also has the added benefit of validating monetary amounts – if a monetary field doesn’t hit your back end as an integer then you know it has failed validation.

So there you have it. I’m not saying these are all the answers to a coding trouble-free finance system for your e-commerce store, but they’ll give you a solid starting point and hopefully avoid a few hours of head-scratching.

Correcting a bad installation will be extremely difficult, disruptive, or just impossible to do once you are up and running. Follow these tips in planning your rack before the first piece of equipment goes in and you will save not only time later, but you will be thanking me when the sh*t hits the fan.

1. Get Your Ventilation Right

Find out which way the servers vent, and mount them the right way round. According to the rather strict guidelines from https://path.network, if you get this wrong and not only will your servers run too hot, but you will likely be required to shut them down and turn them round – or they will be shut down for you.

Data centers have hot and cold isles. The air intake on the servers should be in the cold isle, and the exhaust should be in the hot one. All your servers should be mounted the same way round by airflow otherwise you can end up with the exhaust from one server feeding into the intake of another.

2. Choose the Right Switch

The more equipment you run, the less able you are to tell which equipment consumes which bandwidth. The best way to handle this is by using a managed switch. A managed switch will give you a facility to capture traffic statistics for each port and using a tool such as Cacti you can report on this.

3. Plan Where to Position Your Kit

Think about which equipment is likely to produce the most heat and put it near the top; not too high that its difficult to lift though. When mounting equipment on the back of the rack, think about where the servers will go and make sure you leave that space clear.

Plan networking to keep the cabling short and neat. Put the network switch at the top on the back where the servers have their networking on the rear. Then run the networking down
one side of the rack, and the power down the other.

4. Use the Proper Supports

It might be just you at the data center and if the server you need to get to is at the bottom of a stack of unsupported servers you might be in trouble.

If your servers come with rack rails, use them. Make sure your servers are properly supported so that each one can be removed independently; use rack shelves for servers without rails.

5. Plan Your Capacity

Think about the amount of equipment you will likely install in your rack, and size your network and power accordingly. By this I don’t mean bandwidth into the rack – this can easily be upgraded down the line.

What matters now is that you plan enough network ports for the equipment going in the rack. Make sure you take into account not just the servers, but other equipment such as Masterswitches, KVM etc. Its cheaper to put in a 24 port switch now, but it will be a real pain to swap it out for a 48 port one later.

6. Use Remote Power Management and Fuse It Correctly!

The ability to power-cycle your own servers either using on-board management or a remote power management unit such as the APC Masterswitch can be a godsend. For a small cost you can bypass the remote-hands of the data center and be in control of things. This is particularly important if the data center is not manned 24 hours.

If you install power distribution or management, make sure you fuse the supplies according to the load they are capable of drawing. Here in the UK, an 8-port Masterswitch is capable of handling 10 amps. Make sure its supply cable and fuse are capable of this. If your cable is fused at 5A, you won’t know about it until the fuse heats up and melts the plug; this will be a slow death and when it eventually fails, it will happen either at your busiest time, or in the middle of the night.

7. Run Dual PSU Servers off Dual Mains Supplies

If you are lucky enough to have servers with dual power supplies, make sure each supply is fed from a different power source. This could be two separate Masterswitches or even two separate incoming mains supplies to the rack. The server is designed to happily run on a single supply and so this arrangement will give you the best redundancy in the event of a failure.

To power cycle the server you will need to shut down the power to one PSU, and then cycle the other one, finally bringing the first supply back.

8. Keep Power (& All Cabling) Accessible

Once your rack fills up, the access you had to the spaces between the front and rear of the rack will be gone. Make sure the incoming mains supply and distribution will still be accessible, and your incoming cable feeds (most likely in the floor) are kept clear in case you need more cabling installed.

If your power distribution has been fitted in the middle part of the rack or behind the rear mounting rail, MOVE IT NOW – while you still can. Visualise your rack full of equipment and make sure you will still be able to access all power and network.

9. Program Network Equipment Before You Install It

Once your switch is installed and in use, you don’t want to discover it needs a reboot to configure it. Make sure switches are set up before you take them to the data center.

10. Label Everything, Front and Back

I can’t stress this too much. Invest in a Dymo and label everything on the front and the back, and if it has a cover, label that too. It might not be you visiting the equipment in the future, so it needs to be very obvious to someone who may not have seen your rack before which server you want them to look at. This will also help when you are there in an emergency and need to be sure the server you are messing with is the right one.

11. Maintain Up-to-date Documentation

Every time you make a change to your equipment, make a note of the change. If you alter power, update your Masterswitches. If you add some network, update your switch/monitoring. You can’t effectively manage your servers if you are not 100% sure you are looking at the right thing. Imagine power cycling a server, only to find you just killed the wrong one!

12. Get Your Own Monitor and Keyboard

Data centers usually provide a trolley with a keyboard, mouse and monitor – so you don’t need your own there … right? Wrong. Imagine you are there in an emergency needing access to one of your servers only to find you need a USB keyboard and the only one on the trolley is PS2. Or you turn up after a failure and there are half a dozen other engineers there fighting over the same trolley. It does happen.

Invest in your own; a number of companies make a 1U monitor with keyboard, so it won’t use up much space and its not expensive.

13. Use KVM / Server Management Over IP

It can be a very handy thing to know what’s on the console screen of the server in your rack. An IP KVM will allow you to be standing at the console of that server from the comfort of your own desk. This can be extremely useful in the diagnosis of problems, and will allow you to recover a server you just broke the network configuration on! Another way to accomplish this is with a management card installed on the server.

14. Keep Cables Tidy

Don’t just use the extremely long power cables which came with your server. Buy a range of lengths and aim to keep them as short as possible. Cable tie the power lead to the back of the server so that it can’t accidentally be dislodged. Make or shorten your own network cables so they are exactly the right length. Use plenty of cable ties to keep things neat and make sure the connectors are not under any strain.

15. Keep Tools and Spares on Site

If space allows, install a rack drawer in your rack, and keep a range of spares in it. These should include:

• power leads
• fuses
• network cables
• cable ties
• rack nuts and screws
• tool kit including screwdrivers, pliers and cutters
• documentation