A piece by Raphael Pontual in this months .net magazine led me to think about what it is I do, and how I expect to compete in a marketplace filled with those who spend far more time than me keeping up with current techniques and technologies.

I’m only just starting to really get into jQuery and design patterns, and I have to make an effort not to keep reverting to old tried and trusted old skool strategies that have worked for me in the past.

The piece I believe was more aimed at design, but a relevant excerpt is: “It might seem crazy, but the older and busier you become, the less time you have to find out about the latest trends and adapting to the new graphics software. Meanwhile, there’s always a new generation that spends hours learning everything about the latest creativity suite.”

I’m a developer, not a designer, but I get what he’s saying, that successful professionals concentrate on identifying and solving problems, rather than just throwing gadgets and glitz at a project. A design for the sake of it is nonsense, it has to solve the problem, and the best solution is often the simplest whether it uses the latest whizzbang2.0 bling or not.

A good friend Sujvala kindly left a comment on an old post of mine ‘I want to be Clarkson‘ and one opinion he has is that I have an ‘infantile enjoyment of new toys‘ yet I’m ‘old enough to keep the safety catch on whatever is being tinkered with‘. I really like that.

Yes I do like toys, especially well thought out ones, but there’s a big difference between a toy and a tool. A tool has to earn a living.

The challenge when developing for the web, or making a fibreglass mould, or fitting a satellite dish (or most of my other previous employments) is to identify what it is you’re trying to do, what the challenges are, and what the most appropriate methods are to solve those problems.

Tried and tested (and safe) often beats bleeding edge, although you always have to be open to the idea. As Confucius said “It does not matter how slowly you go so long as you do not stop.“

It’s been a long time since I’ve been on Happisburgh beach, which is a real shame since I live less than a mile away, but I often walk the dog heading inland which takes me half an hour, rather than the two hours or so if I go to the cliff because I get carried away.

There was more than the usual amount of flotsam washed up at Low Light, reminding me of David Shukman’s article on BBC news about the new battle for Midway - plastic rubbish washing up and killing Alabatrosses (Albatrosii?)

It is absolutely disgusting the amount of crap we leave behind in our environment - I often return from walks with hands full of plastic bags and such like found in hedges and on the side of the road. That we’re also polluting somewhere so remote is horrifying!

I don’t know what the answer is, but there must be a way to reduce our consumption of plastic, to recycle more, and to better dispose of what we don’t / can’t recycle.

Whatever the reason behind it, there’s no doubt that Happisburgh has a bit of a problem. The fact is that without maintained coastal defences, the sea is reclaiming land it has been denied for so long, and those unlucky enough to be living there at the time are paying the price for the decision to stop maintenance of the defences.Many cite Happisburgh as an example of the impact of Climate Change - sea level rise obviously means that in years to come we will have a different relationship with the coastline than we do now. However others suggest that what’s happenening at Happisburgh doesn’t have anything to do with Climate Change and everything to do with isostatic rebound after the ice age causing the east coast to fall while the west coast rises.

But to claim that ‘stories like this are constantly peddled by the leftist media‘ also misses the point. For whatever reason, our government now feels unable to continue funding defence of the majority of our coastline, but is neglecting it’s moral responsibility to mitigate the cost of that decision on those it affects.

If we get more publicity for the injustice by saying the root cause is climate change - guess what my opinion is?

I can remember when I first started developing oh-so-many years ago, instinct and common sense told me I should implement some sort of version control, even though at the time I was writing simple MS-DOS Basic applications, and working by myself. At strategic intervals, if I remembered, I took a copy of my source code, renamed it and put it somewhere ’safe’. In reality I didn’t, but I knew I should so that if all else failed I had something to go back to.

As my applications started getting more complicated, as the business risk of getting it wrong increased, and especially when I started working collaboratively with other developers, the need for a ‘better way’ grew. I was aware of systems like CVS, but they didn’t seem entirely suited to our web development environments and the challenges we faced. We needed something which didn’t unduly get in the way of our work, and helped with as many problems and risks as possible:

• Audit trail - who changed what, when, to get the code get into the current state?
• Comparison - what changed between two versions
• Collaboration - assisting multple developers working on the same files
• Branching and Merging - the ability to create parallel threads of development, and combine them back together if required
• Disaster recovery - assistance reconstructing sites in a hurry
• Code migration - keeping envirnoments in sync, and moving changes between them

The break came, as with most things, with the opportunity to spend a bit of time ‘playing’ with possible solutions. First thing was giving Subversion a go - although similar in many ways to CVS, I found it much more suitable for my needs in that it was more usable, a ‘version’ represents the entire codebase rather than a specific file, and commits are atomic meaning if something fails it cancel the entire transaction rather than leaving a working copy ‘broken’ or inconsistent.

Now I had a tool I liked, how to apply it to our needs? My primary concern was moving sets of amends between environments - I wanted to get this automated and as safe and foolproof as feasible. Yet it had to be an easy process that anyone (within reason) could do.

So the files on the webserver, or any other environment which needs to be covered by version cnotrol, should be a working copy - that is checked out from a repository using a Subversion client. The new method to get changes to the live site is to make them in a dev environment, commit them to the repository (with a suitable log message of course) then ’svn up’ the live site.

One stumbling block was that different environments tended to need different configuration - whether it was filesystem path, url of the web root, or database connection details. Like all well structured applications this configuration was already in a single global include file - but this was a very risky file to have under version control. It was too easy to have a locally modified file overwritten, or even worse to accidentally commit a dev server’s config and update (and break) a live site.

The solution - don’t version environment configuration!

Put all your environment specific code in a file named for instance .config.local ( the dot prefix prevents Apache from serving requests for this file which would be a bit of a security loophole) placed in the sites DOCUMENT_ROOT and setting a global ignore on *.local in all svn client config. Now in every script you can ‘include ($_SERVER['DOCUMENT_ROOT'].’.config.local’);’ and you’re away, safe in the knowledge that you don’t have to keep an eye out for this dangerous file.

Of course that’s a simplification of the task for safe management of sites, but it demonstrates the point. Neither does it take into account all the potential issues surrounding managing websites - changes in the unprotected config file, filesystem permissions and database schemas to name but a few; but with a bit of thought and some good working practices Subversion can usually help out to some degree, if only to keep manual documentation of such things in the same place as the code.

But that’s another post someday … what is for certain is that properly used and suitably configured, Subversion is most definitely worth the effort, and it could save your life one day - or at least your job.

I’m working on a page which is using jQuery to show one block of content at a time from a group of blocks, managed by a navigation. It’s working very nicely, but geting to the later stages I start trying to get print styling working.

Ordinarily, I’d attach a print stylesheet and hide irrelavant things like navigation, and show anything that I want to print that is hidden as per Eric Meyer’s classic article in A List Apart ‘Going to Print‘ - in this case it would be ideal to have all the content blocks printed. But jQuery has rewritten all styling so the print stylesheet which loaded with the initial page rendering can’t help. Or can it?

After much research, herad scratching and good old ’suck it and see’ experimentation, I’ve determined that yes the theory still holds, you just have to apply a bit more brute force.

jQuery manipulates page styling through use of inline styles. Linked stylesheets can still override inline styles if given a ‘!important’ suffix. So for instance: <style media=”print”>.switchable {display: block !important;}</style> should keep content hidden by $(”.switchable”).hide(); visible.

Every now and then I come across a new product or technique that causes a lightbulb to come on - suddenly I know I will never code the same way again.

Landmark events over the years might include the realisation that PHP is a proper programming language (although I did keep Perl up my sleeves for the odd task), how to use Subversion to version control a website (must write that one up sometime), reading Zeldman’s “designing with web standards” …

Not quite in the same league perhaps, but I’ve finally got around to having a good play with jQuery, and doesn’t that open up whole new fields of possibility?

Having ‘bought into’ Standards there has always been an internal conflict with any superfluous markup that has to go on a page for eye candy or other frippery, such as the dreaded rounded corners problem. Suddenly, there is a simple way to tinker with the DOM to make such effects possible, without having to put anything more in the base code than a few calls to JavaScript includes. But it sounds too good to be true. It can’t be legal can it?

I suppose the answer to that is that there isn’t one answer - it all depends how you wield the tool. If you disable JavaScript and the page still ‘works’ - then all jQuery is doing is adding some glitz and if it’s keeping the markup etc. cleaner and more semantic then that has to be a good thing.

But what is the definition of ‘works’? It depends what the page is meant to do. It could be an informative page so ‘works’ is can you access the content in the correct context and get appropriate meaning from it. Or it might be a bit of functionality - a form or a blog or whatever.

With the power comes responsibility, and the temptation to run riot and get all inappropriate. I’ve seen some pretty dubious examples of the use of jQuery - putting ‘back to top’ links on a page, or altering anchors if they link to external resources - that starts risking Accessibility and potentially usability. Use of AJAX without a non-js method of doing the same thing - form validation and submission for instance. Face it you could use it to construct a whole site on the fly if you wanted. But that would be a Bad Thing in my book unless there was exceptional reasoning behind it and some sort of mitigation for non JavaScript users.

I’m sure I will be making a lot of use of jQuery in the future, but I will be keeping a close check on myself to make sure it’s appropriate. For reference, here’s a simplistic view of how I tend to approach a new build currently:

• Analyse what the page is about and prioritise requested / identified features in a sort of MoSCoW list
• Design html structure to represent it, check it makes sense in text browser
• Analyse ‘look and feel’ requirements and design css / JavaScript to implement them
• If necessary adjust html to make the presentation layer easier / possible, but as little as possible (argue negotiate with client / designers as appropriate)
• Never forget a print stylesheet, and probably nowadays it would be good to consider mobile devices
• Do everything server-side to deliver the page and handle any actions the page produces
• Complete content population & coding
• Test degradation from latest browsers with everything turned on through old browsers, text browsers, phones, anything I can get my hands on until I get bored- ensuring ‘must have’ features work in all, ’should have’ and ‘could have’ work in as many as is feasible.

http://xkcd.com/386/

So dotMobi have finally launched their mobile device database offering as discussed by Andrea Trassati at the Future of Mobile event a few months back.

Called DeviceAtlas, it claims ‘to become the world’s most comprehensive source of mobile device information.’

Other than a slightly daunting looking licencing model, and potentially more data contributed directly from manufacturers, I don’t see much of a difference from WURFL, and that’s a project I really like.

Of course I should give the thing a go first to make an informed decision, and that’s something I hope to do in the near future.

As posted earlier, I’m going back to my roots after 6 years in the relatively comfortable life of an employee of a large agency, and specifically as someone who has had a sabbatical from mainstream development whilst managing a team of developers.

Now I’m back on my own again I’m reviewing my skills and experience, the current state of the industry and best practice, and sorting my tools and techniques out ready to get busy (hopefully).

It’s amazing how much has changed in the intervening years and yet how much is the same. Packing up my desk and hunting down the books I took to Soup, many are well thumbed from regular use despite their age they are still relevant. I’ve also been compiling a wishlist on Amazon of titles bought for the company library that I will want to get copies of, but to be honest there aren’t many essentials - good references for PHP, MySQL, CSS, Apache, JavaScript etc. But even then can be found online - it’s much easier to type http://uk.php.net/explode to remember what order to pass parameters to explode() for instance than to find the book - but I digress.

I’ve been rebuilding a few sites I first built oh-so-many-years-ago - one was even still using Dreamweaver Templates <hangs head in shame> - but they are still doing the business for the owners and all they want is a quick design refresh and a bit of new content. “Oh, and while you’re at it could you just add a news section we can update ourselves?” So the quandary begins - how much do you reuse and how much do you rebuild, and what technologies do you use?

Perhaps unlike many working by themselves on ’smaller’ sites, my recent background has exposed me to all shapes and sites of web content delivery technologies, from full on Enterprise level Content Management Systems such as Vignette and Stellent, other commercial ones like RedDot, or open source ones like Drupal or Joomla! or in between like Expression Engine, and then of course there’s all the custom applications that get written for specific applications, or reusable frameworks and libraries that can give advantages in rapid deployment / development.

And then there’s the platform to build on - once is was a choice of flat html (with some help from Dreamweaver perhaps) or Perl (or the new kid PHP) or ASP. Now there’s all the Java based technologies, Python based (I still reckon Zope should have become more mainstream) ASP.NET, Ruby on Rails, and of course my old favourite PHP is going from strength to strength. And it doesn’t stop server-side, with the advent of AJAX and frameworks such as jQuery, so much more can be done on the browser.

I understand and buy into Standards Compliance, Accessibility, Search Engine Optimisation, Usability and all the other buzzwords. I’m able to gather requirements, write specifications, manage projects and carry out quality reviews. I’ve been involved in projects that have been great successes, and others that have spectacularly failed, enough to know how to avoid the pitfalls.

But does all that knowledge and experience help in my current situation and perhaps give me an advantage over someone only just starting in the industry? It’s a mixed blessing because although I rarely have to say “I have no idea how to do that or what’s involved”, the opposite is also a problem because I know of perhaps too many possibilities and alternatives, and how things could be done ‘properly’.

As a little aside, I’ve often observed that any sort of development or design or construction or problem solving that is done in a constrained environment is likely to have a much more creative and pleasing outcome than if done with the luxury of infinite possibilities - it makes you focus and think and consider relative merits of alternatives with a clearer vision of the ultimate goal rather than being dazzled or distracted by niceties.

So how have I tackled these rebuilds? Well the Dreamweaver Templates site is hopefully a textbook example of how to use PHP to make a relatively simple brochureware site more maintainable. The templating features of Dreamweaver (ah yes, I remember them well!) have been replaced with PHP includes - so common elements like html <head>, top level page layout, navigation etc. are all shared. A ‘page’ is represented by a PHP file which sets variables such as page title, navigation state, calls the relevant includes for the top of the page, have the body content hard coded, then calls the footer includes. The one dynamic page is the news section which calls content from a MySQL database, with a little utility script allowing the client to manage news stories.

Why didn’t I use my first project as a freelancer again to flex my muscles and show off all my skills? Because the requirements didn’t need it. This application is beautifully simple, very easy to host and maintain, blisteringly fast, and hopefully will go another five or six years before its next rebuild. Any half competent developer could look at the source and figure out how to make any changes within minutes of getting access to the source. And it only took a couple of days to complete - including me trying to come up with some sort of new visual design and I’m no designer!

This approach has been used by me and my team for many years with great success, from small 6 page site to large corporate sites for FTSE100 companies. If it meets all key requirements what’s the advantage of making life more complicated? Admittedly the finer details of how to implement it have changed - using css for layout rather than tables for instance, good clean semantic markup, secure against XSS and SQL Injection (hopefully) and obscuring email addresses from spambots, with a sitemap.xml and Google Analytics tagging, and it’s all under version control …

I’m starting planning a much bigger site that needs more content management, and have reviewed several frameworks and applications to make life easier, but have still settled on the approach above with one small change - using Smarty to separate logic from presentation, and moving more of the content into the database. But it’s still clean, simple, fast and reliable.

KISS - if it’s getting too complex it’s probably wrong.

I like to think I know a little bit about most things surrounding the Internet, and whilst not claiming to be an expert I like to think I’m at least competent in most things I turn my hand to.

But every now and then I get caught out, and reminded how dangerous it can be to tinker with things you don’t fully understand - there are some people out there with far too much time on their hands.

As part of my Trundle project, I attempted to make a webserver running on the beast’s eventual operating system available to the public Internet - not for public consumption mind, but so I can see it when I’m out and about. Now I didn’t want to put the whole thing on a public IP address, just a little bit of it - and apart from anything else I’ve already got an externally available webserver on my Internet connection.

So my idea was to use mod_rewrite to proxy a set of urls to the internal server’s private IP address. I’m sure it’s something I’ve done before in other Apache instances, and it sounded feasible, but for once Ubuntu fought back a bit. Still, I felt I’d prevailed.

Now it turns out I’d opened up a vulnerability to someone, somewhere, to do something with my network. It was cunningly disguised in that the traffic wasn’t enough to be hugely obvious, but I was playing with awstats and got curious about some odd traffic.

It turns out I’d unintentionally configured my webserver to allow anyone to use it to proxy requests to anywhere else. Short of cloaking the eventual source (or destination?) of the traffic I can’t see what was gained - the requests seem mostly to have been for banners or clickthrus in flash game sites. I wasn’t hosting the files so nothing was gained in terms of bandwidth, and it doesn’t seem like a ddos attack.

Anyway, I’ve disabled the proxying functionality now, and checking the logs although I’m still getting the requests they now get a 403 response. I hope they’ll die out eventually, or will I have to get my fixed IP address changed do you think?