Recently at Headscape we were setting up a new server ready to launch a redesign of a site. Whilst testing we were accessing the site using the server’s IP address which works fine for checking everything is working, apart from when we needed to install the SSL certificate.

The SSL certificate is based on a domain name so going to an IP address causes the SSL certificate to warn of an insecure connection. Not very helpful when you’re checking to see if everything has been setup correctly.

This is the solution we came up with.

Say our server is on an IP address of 123.456.78.9 and the domain name is reallysecure.com

Adding an entry to the hosts file of

123.456.78.9 reallysecure.com

will cause the browser to go to the new server when we request reallysecure.com

The server will see that the incoming request is for the domain name that matches the SSL certificate and, providing everything has been installed correctly, we will be accessing the site over https.

At Headscape we use TeamCity as our Continuous Integration server and I recently came across an error when trying to build Drupal Commerce Kickstart.

The main parts of the error message were

Failed to build patch for build... due to error: 'build patch' command failed.

stderr: The repository has a submodule in the commit '77b28273d1ebb08fd03ee254bbb20b6b476d16ec' at a path 'profiles/commerce_kickstart/libraries/jquery.bxslider', but has no .gitmodules configuration at the root directory

During my teens and twenties I spent a lot of time skateboarding. It’s quite a unique sport in the way it influences your life as a whole. For example, you begin to look at architecture in a new creative way. You also fall over, a lot.

In fact you get really good at falling over: jump down ten steps roll across the concrete, hop up and do it again. You actually spend a lot of time “failing” and it doesn’t bother you. You learn that failure is part of the learning process and something that you should not be afraid of.

Over time the feeling of failure decreases and you’ll gain confidence in the knowledge that you know how to deal with problems.

This attitude can be taken into every aspect of your life and especially something as dynamic as web development. Why not try writing a little app in a new language? If it doesn’t work out it’s not a big deal. What did you learn from it? Did you not enjoy using the new language or was it just not a good fit for what you were trying to do?

Maybe to start with you could try using a new JavaScript library to see how you fair. Then progress to trying harder things. You might fail at them first go, maybe even second, but don’t let it phase you.

Over time the feeling of failure decreases and you’ll gain confidence in the knowledge that you know how to deal with problems. This could even be a huge advantage if a critical problem occurs on a live server for example. If you’ve been playing around and breaking things locally you’ll be calmer and more methodical when fixing critical issues.

When learning tricks on my skateboard I would always start off on the safe flat ground. Once I’d become comfortable I’d try the trick down a curb, adding a bit of risk but knowing it wouldn’t be too catastrophic if I didn’t land it. Then finally, once I’d got very comfortable, I would try it down a set of steps… more risk and more reward. You can carry this analogy into your work by trying out your new idea on a personal project, then maybe on a friend or colleague’s project and finally unleash it on that million dollar website and revel in the excitement!

So next time you think you may fall over, go with it, learn to roll out of it and pop back up and try again. You may even find you start to enjoy it.

I’ve been using Codeception for some acceptance testing recently. The project has a large database and using the standard Codeception database module that rebuilds the entire DB from an SQL dump was too slow.

All I needed to do was run a few queries to put some tables into a known state. I made a helper module that will run all .sql files in a directory.

I have been working for The Marine Biological Association for close to five years now but the time has come to move on. I’m very proud to say I will be working for Headscape where I’m sure I will learn lots and continue to progress as a developer.

In the five years since I started the web and my skills have progressed exponentially. It’s been fun and nostalgic to talk about the early days and see how far the sites and applications have come since I began working with the MBA.

As with all good work places it’s not only the work but the people who make it special and I made some excellent friendships that I’m sure will continue.

I’m certain that this will continue to be the case in my new endeavors with Headscape.

I had tinkered with Node.js before but in a bit of an unstructured fashion. Reading the table of contents had me impressed then seeing the price for the Kindle version confirmed the deal. There is a lot of information here for very little money, around £7.50.

The book begins with an introduction to Node and setting it up. There are also some details about the difference between browser JavaScript and some APIs used by node.

We then move onto using Node for a command line app and then communicating over HTTP. With the slid foundations set the third section introduces some modules that will help us build actual websites.

The fourth section enhances the web apps ideas by introducing different databases, not just by name but by structure. Including MySQL and NoSQL such as MongoDB.

The final section shows how we can really use the code once use everywhere philosophy by allowing JS written for Node to also be executed in the browser. Then finally a chapter on testing to ensure our apps will behave as expected.

The book introduces the code in easy to understand segments and then often refactors this further into the chapter. This gave the examples a “real world” feel and helped show some best practices and why they should be used in that way.

There are also some nice interactions with other APIs such as the classic example of Twitter as well as Grooveshark.

If you are interested in getting started with Node.js or have just begun your learning and are seeking a more structured learning format I highly recommend Smashing Node.js.

I recently discovered Shop Talk, a live web design and development podcast by Chris Coyier and Dave Rupert. So I’ve been listening to the old episodes and in episode 9 with Ethan Marcotte. Andy Howells from the UK asked a question ,which is 15:38 into the episode.

He asked about an eCommerce site that could have twenty four additional images of a product and rightly expressed concerns about page load speed on mobile devices over slow network connections.

As I was listening I had the idea that this could quite easily be solved by just having one main image on the product page and then a link to view more images of the product. This could then be enhanced to load the additional images in using AJAX. The user clicks a link that pulls in the extra images and then displays them on the current page.

Another step could be to load an additional six or twelve images then the customer could continue loading more images until they have seen them all. Waiting for twenty four images to load could still be very slow even if the user has consciously chosen to perform this action.

The Downsides?

From an SEO perspective the reduction of images on the page means a reduction of alt tags with the product name. I feel this is probably a very small hit but if anyone knows different please let me know. The product name should be appearing in the body copy as a description and title etc which should provide the majority of your “SEO juice”.

On larger screens only seeing one image could reduce the visual impact when a user first sees the page. This could be overcome by triggering the AJAX request to fire when the page loads and a media query over a certain size is present. Using Modernizr this would look something like

Here is where the issues gets a little grey as we are assuming that a user on a larger screen has a better internet connection when it might actually be the case that someone has a large screen and only a dial up connection but a small screen device is connected to a high speed WiFi connection. If anyone knows of a good way to test bandwidth to replace the above media query test above please leave a comment.

This year I’m lucky enough to be attending Future of Web Apps London 2012. I’ve been to Future of Web Design before and found it hugely inspirational so I have expectations for it’s more technical sibling.

I’m looking forward to

Jeffrey Zeldman – Obviously a major influence in the web world and I’ve heard he is an amazing speaker.

Bruce Lawson – I’ve seen Bruce speak at FOWD and he is very engaging as a speaker and I admire his honesty and openness on standards.

Lorna Jane Mitchell – Not only am I interested in her API talk I also get to attend the API workshop with her. APIs are something I’ve been looking at and working with a lot more recently so the chance to pick the brains of someone as accomplished as Lorna is a fantastic opportunity.

Andrew Appleton – I’ve also been looking a lot more into the many JavaScript MV* frameworks lately so Andrew’s talk regarding Backbone.js is of interest to me.