If you don’t have the source code that goes with your software then that software is a magic black box. You put things into the black box then something else comes out. It’s impossible to know what the black box is really doing, even if you are often told what will happen if you put different things in the box.

With Open Source software the box is transparent. You can open it up and change bits. The box is no longer magic. The box is science.

Allowing everyone to look in and modify the source code has its advantages. It’s much easier to see if there’s problems and anyone can create a fix. You don’t have to trust anyone because no one can hide anything from you any more.

The tech world is gradually moving to Open Source more and more. This means people are sharing their code – making it transparent – improving other people’s and forming support communities. Standards and specifications have been created so different source code is still compatible. People can still sell you a transparent box and you can still pay a company to provide support but you are no longer locked in to that company forever. Companies can also do more in-depth security audits when they can see inside the software.

The thread of Open Source runs though many parts of Base. I’ve used Ubuntu (Linux) instead of a Mac or Windows for a few years and Matt’s now using it too. Most of our web servers run on Open Source operating systems and software. We use WordPress for content managed sites extensively and combine it with front-end Open Source libraries such as jQuery.

At Base we work with whatever solution fits a client’s needs best. Sometimes we work with closed source software but whenever possible we lean towards Open Source. Having the source code to software we’re working with helps us to understand the software and make it bespoke to fit a client’s needs.

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.” — Tom Cargill

Generally, the remaining 90% is bug fixing. Everyone prefers working on exciting new code to fixing old code but part of managing a project well is making sure bugs are fixed faster than they are found. These days, when an issue report comes in, developers have lots of tools at their disposal to make finding and fixing code more fun.

At Base, our war on bugs is won thanks to our combination of weapons: version control and unit testing. A bug I had to resolve recently was related to some transactions crossing over midnight suddenly not working any more. Here’s how I won the battle:

1. Reproduce the bug

The first step is trying to reproduce the bug as simply as possible. The minimum required was to create a fake request with the time set to just before midnight and start an empty transaction. Using an empty transaction meant that any problems that came back must be the result of the transaction itself, not what was in it.

2. Write a test to make sure it fails

Unit testing means writing code that runs against a single part of a system and checks that the one part gets back the correct result. Once I’d written a test for midnight bug with PHPUnit, any developers at Base could run the test suite on their own systems and see that PHPUnit reported “FAILURES!” for my test.

3. Find the source of the problem

As I could recreate the bug whenever I wanted, writing and testing a fix was so much easier. This bug was a regression, meaning it was working fine until some new code came along to break it. We use the popular version control system “git“, which lets us become masters of (code) time travel and step back to any point we’d previously “committed” some code.

Git has the wonderful tool “bisect”, which helps you search through the code history, narrowing down on a specific commit. You tell git bisect that the current commit is currently “bad”, then you go to an old version and say its “good”. Git bisect then goes to a halfway point and the process starts again. This only takes a few steps, even if there have been hundreds of commits since the bug was introduced.

Whilst “git bisect” by itself is a bit of a black art, the true magic comes when you combine git bisect and PHPUnit together with a simple shell script. You tell git bisect to run PHPUnit and use the result of the unit test to automatically mark a commit as good or bad. Seeing the two working together is incredibly cool. It’s like having your own personal bug detective.

4. Fix it

I now had the precise commit where the bug was introduced. Git let me see the exact date and time of the commit and who had coded it. It turned out it was me. Fixing the bug involved changing just a couple of lines. The bug was fixed and committed after PHPUnit gave the nod by reporting “OK”.

Due to the fun of using PHPUnit and git bisect, I’m often tempted to code in extra bugs, just so I can watch the my bug detective do its thing. That’s my excuse anyway.

“You need to support [insert old browser here], so can’t use any new web technologies like HTML5 or CSS3″ — Made up 17th century  proverb

Part of the reason I like developing websites so much is that the web is arguably the most open and accessible platform there is. Someone in Japan can publish a website that can be viewed by someone in Brazil seconds later. Someone with loss of fine motor control can dictate a blog post that can be read by someone with a visual impairment. Someone can view the source of a web page I’ve made and get ideas from the code. This cannot so easily be said about TV, radio or print media.

One area that sometimes gets left behind, however, is people using older browsers. If you mention “Internet Explorer 6 support” to someone in the web industry then you better get ready to run!

There are 2 main methodologies of creating the front end of a website: Graceful Degradation and Progressive Enhancement. Although not mutually exclusive, people are moving away from Graceful Degradation and leaning towards Progressive Enhancement.

Graceful Degradation sounds worse than it actually is. Sites are created designing for the best browsers – usually this means Firefox and Chrome – then extra code is put in to catch problems that might occur with older browsers. For example, IE6 doubles margins of elements when they’re “floated”. Extra code is then put in to fix this problem for the 3% of visitors using IE6.

Unfortunately, the “Graceful” in Graceful Degradation is very subjective. An example of this is a video “degrading” to a static image for visitors without Flash. Though this is more graceful than having no content at all or a message saying “Please upgrade your browser”.

Progressive Enhancement is building from the bottom up. A site is coded (and sometimes even designed) to work well in older browser from the start then it is enhanced (progressively, of course) for browsers with more features. The most common example of this today is probably the Web 2.0 rounded corner design. All browsers but IE less than version 9 let developers code a rounded corner in 1 line of CSS. Designs are made to work in IE then the rounded corner code is added for all the other browsers. The beauty of this is as users gradually upgrade to IE9 then a higher percentage of visitors get to see the enhancements.

While the term Progressive Enhancement was coined back in 2003, developers have been doing it for even longer. The older ones among us may remember Internet Explorer 3 was the first mainstream browser to support CSS. Things like a link changing colour on hover were unheard of. As soon as us webmasters (as we were called back then) got our hands on IE3 we progressively enhanced our sites so that our orange links on green background turned pink, to the delight of the “0000007 visitors” visitors registered on our hit counter.

Progressive enhancement has come a long way since the days of IE3. Our work with Bournemouth University is a showcase of what can be done now. Turning off Flash player makes the site look and behave almost identically to when Flash player is enabled. Visitors with JavaScript disabled see the same result but with fewer effects. The site was actually first coded to work in a text-only browser such as Lynx, which meant the site would be usable for virtually every visitor.

Progressive Enhancement is obviously a step away from the pixel-perfect designs that were so common a few years ago. While this can be seen as a drawback for some designers, developers love the idea of a site that Just Works™ and can easily be enhanced in the future when browsers support new features.

HTML5 is a marketing term referring to New, Exciting Web Technologies. It used to be the name of the 5th version of HTML but that has been renamed to just “HTML”. When people say HTML5 they are referring to 1 or more technologies grouped under the HTML5 umbrella.

Using HTML5

The support for the different HTML5 technologies varies across browsers. Generally, Firefox, Chrome, Safari and Opera support most of HTML5 but the current version of Internet Explorer, 9, is lacking.

The lack of cross-browser support isn’t a big problem for 3 reasons:

• Most HTML5 features “progressively enhance” a website. That means older browsers still get a working website, just without some extra fancy bits
• JavaScript “polyfills” and “shims” can be used to recreate HTML5 features in older browsers; though they’re often not as fast as the browsers with native implementations.
• Browsers are updating quicker than ever before. Internet Explorer 10 and Firefox 5 are just around the corner. These browsers have much better support of HTML5.

What’s in HTML5?

• New semantic HTML elements. In HTML4, every block on a website is coded with <div> (meaning division). HTML5 brings things like <header>, <aside>, <article>, <footer> and others. This enables search engines and screen readers to work out what are the important bits of a web page.
• Better forms. HTML5 gives developers a standard way to make input boxes for dates, times, email addresses and sliders. It also has standard ways of validating user input. This means users get a consistent experience when using forms on the web but designers still have flexibility over appearance.
• Native video, audio, diagrams (SVG) and animations (Canvas and WebGL). As HTML4 really only supports images and text, 3rd parties made browser “plugins” to extend the web. The most common plugin is Adobe’s Flash. HTML5 features are gradually replacing the need for Flash and other plugins.
• CSS3. Rounded corners on a site used to require 4 images for every style; this can be done in CSS3 with 1 line of code. With CSS3, developers can recreate designs more easily and designers can even prototype complex designs live in a web browser. CSS3 allows background gradients, transparency and much more.
• Fonts. HTML5 brings a cross-browser way of using custom fonts without using plugins or relying on heavy JavaScript libraries. This means sites can look better whilst being faster, more accessible and more usable.
• Geolocation and other “device access” APIs. Web browsers are letting sites access more of a users hardware with JavaScript. You can already get a user’s current GPS position and soon you’ll be able to connect to webcams.
• JavaScript APIs such as History and Storage. For the programmers out there, HTML5 brings a whole load of fun APIs that allow web apps to behave much more like desktop apps.

Can I have an HTML5 website?

Yes. At Base we like using new technologies but choosing to load your website with as much HTML5 as possible just because it’s the New Thing™ isn’t a good idea. Deciding what parts of HTML5 would be useful for your site is a more complex matter. Users may be annoyed if you tried to find out their GPS coordinates when they were just browsing a shop but if they may like the convenience of not having to fill out their full address on an order form.

There are millions of people still using IE6 and IE7, even though IE8 has been out for a few years. IE is much harder to update as it is used for legacy applications and is part of the operating system. Microsoft should decouple IE from Windows and allow IT departments to deploy IE9 along side old versions of IE.

IE9 requires at least Windows Vista to run. The most popular version of Windows is currently XP. I’m sure Microsoft have their reasons for not supporting XP but there’s a huge chunk of the market that will be stuck on IE8.

All these points add up to IE9 not being able to take much of out of IE6/7/8′s market share. As sites will still have to be built to support Microsoft’s old browsers for many more years, there won’t be enough resources for many web agencies to invest in modern web technologies. If you need to make a fallback rounded corder image for IE8, you may as well not use CSS3′s border-radius and use the same image for IE9 and all other browsers.

Make so it’s easier to test and develop on IE9

IE9 now has pretty good developer tools. Once you’ve got IE9 running, it’s great for developing on (almost as good as Firefox with Firebug).

The problem is getting IE9 in the first place.

IE is just about the only browser that only works on one OS. Many developers and people in IT use Mac OS X or various Linux distributions. Microsoft currently provides time-bombed virtual machine appliances for IE6, 7 and 8 but not 9. Also, these appliances are for Microsoft VirtualPC, so Mac and Linux users have to use some jiggery-pokery to get them running in VirtualBox or VMWare. Microsoft should provide appliances for IE9 that run in other virtual machine programs.

If you have Windows Vista or above then you can install IE9 but you loose your install of IE8, which is currently the most popular version of IE. Windows users have to use a virtual machine too.

Release IE9.1, IE9.2…

HTML is an evolving spec and HTML5′s technologies are still in development. The last version of IE was IE8 was lagging behind the other browsers when it was released in March 2009. 2 years is a very long time with no new features. Google push new features to Chrome every 6 weeks, which seems a bit extreme, but if Microsoft had made a few incremental feature updates to IE8 they would have made a lot of developers happy. Most Chrome users already have the latest version, even though it hasn’t been out very long. If Microsoft could pull this off too then they could keep up with the web instead of playing catch-up most of the time.

Support more HTML5, CSS3 and JavaScript APIs

IE9 supports so much more of the web than IE8 did. Microsoft have been really hard at work but there’s a lot more they could do. Some of these features are not supported by current versions of Chrome, Firefox, Opera or Safari but there’s no reason why IE can’t lead the pack for once.

HTML5 form elements and validation

New form elements, types and attributes like <input type="email">,  <input type="date"> <input type="text" required="required"> make life easier for developers. No extra JavaScript is required for date-pickers or client-side validation and users get consistent form controls for their platform.

CSS3

IE8 supported CSS2.1 in its entirety. IE9 adds a bit of CSS3 support, for example opacity, but there some parts of CSS3 that have been “standard” across other browsers for many years now that IE9 does not support.

• text shadow
• columns
• border images
• flexible box layout
• CSS transitions
• CSS animation (Firefox 4 may not support CSS animations)

JavaScript APIs

IE9 does not support the following JavaScript APIs. These are increasingly used where the browser is known not to be IE (for example Adobe AIR apps and on mobile devices).

• history.pushState and history.popState methods
• Offline web apps
• Web workers
• File API
• classList
• Indexed DB
• WebGL