One of the things that gets me excited about the new features of browsers is the “HTML5” Web Storage module. I like it mostly because of its simplicity.
The Web Storage idea is to simplify storing of information for the user. I always hated using cookies because of all the domain issues. It was also a mess to check for them and then fall back to other things. Most of all people are paranoid about them and I know a lot of corporate computer users who have all cookies disabled.
Web Storage on the other hand is a simple object in the browser. You can set localStorage.foo to ‘bar’ and when you read out localStorage.foo next time you load the document it will be ‘bar’. That’s how easy it is. You can store 5MB of textual data which could be integers or strings. With JSON.stringify() you can easily store more complex information.
So I was wondering what you could use that for to get the most out of it and I realised that in a lot of cases I render simple HTML in PHP and then do some clever stuff in JavaScript to make it a different interface. If I wanted to retain the state of that interface I’d have to somehow store it in a DB so next time the user comes to the site, I re-render the last state of affairs.
With localStorage you could do that by simply caching the innerHTML of the main app (if you build it progressively):
If you’ve been on Twitter this morning you’ll have witnessed a bit of a discussion between Remy Sharp and me about his web site http://doesvalidationmatter.com/ which initially just said “no”. I didn’t agree with such a sweeping statement and I still don’t – if you make a statement like that then you need to quantify it. Therefore I called it “arrogant bullshit” which was eloquent enough for 140 characters.
The dangers of influential people making sweeping statements
As Remy and me are friends we just went to IRC and had a longer discussion about what each of us were thinking and I explained in detail the worries I have with luminaries like Remy making a one-off statement like this. I love Remy’s work and I envy his drive and his dedication to the newest technologies out there. That’s why my name is on the back of his and Bruce Lawson’s book where I praised their pragmatism and hands-on examples how to use HTML5 and all its cool APIs in today’s world.
The issue with a statement like “validation doesn’t matter” from someone respected and very much on the forefront of great publications right now is not that it might be wrong or right – it is that people will use it as an excuse without even understanding the subject matter: “Cool, Remy says validation doesn’t matter so let’s use table layouts and font tags – after all they work”.
The issue of validation being of any importance in a web development (and especially markup) context is not easy. The reason is once again the forgiving and undefined environment we as web developers build our products in.
If I put a syntax error in a JavaScript file, it breaks. If I put a syntax error in a PHP script the page doesn’t get rendered (or throws an error). If I write invalid HTML the browser either ignores it or – what is actually worse – tries to fix it for me. This is how browsers always worked as markup is not considered code and this is also why engineers still consider web developers designers. Imagine Word simply replacing everything it considers badly written or a typo when you save and email the document without telling you – this is what browsers do for us.
Markup and validation issues
Right now we re-invent markup as we want to build real applications rather than simulating them (every Ajax app is a hack, if you really look at it)
The official validators of the W3C are too strict and outdated
XHTML was born dead, not because it was a bad idea but because there was no support by the main browser in use at the time
XHTML2 and XHTML modules reminded me of scribbling of mad men on a prison wall – far too complex for the average mind and trying to solve issues that were either edge cases or just far in the future
We are used to having to write half-valid code to get things to work and we don’t get any punishment when we write invalid code.
Flagging up sensible extensions to the HTML namespace like WAI-ARIA as errors and disallowing a site to go live if it doesn’t validate holds us back in building better web applications.
All in all the need for validating markup seems arbitrary and part of an approach to web development that is over. The only time I cared about XHTML was when I had to use XML and XSLT to develop web sites for a certain CMS. I also learnt there that XML providers will never take your data if it doesn’t come with a schema or doesn’t validate. This was just a given.
Neither of the above reasons ever stopped me from writing clean code and validate my HTML. And here’s why:
Validating is part of a process
Validators are brutal and stupid machines. The results should be analysed and applied as they make sense. As Douglas Crockford says about JSLint: “it will hurt your feelings”.
Therefore validators for me are a first step to find and remove obvious flaws. When I was moderator on #html on IRCNet in the long long ago we never helped people who didn’t validate their code – the reason was that 90% of the problems vanished once the persons realised they had forgotten to close a DIV and the browser rendered whatever but not what they intended to get. This allowed us to help far more people with real problems.
Validating markup is the “have you tried turning it off and on again” you do with computers – it will solve a lot of your issues and give you some time to re-think your ways. Furthermore, it solves a lot of issues, some of them magically.
Most of the issues of validation are not about validating or the tools – it is about people misinterpreting the results. As there is such a gap between the standards and what browsers can do some errors being flagged up should be exceptions and not flagged up as show-stoppers.
This has been the bane of accessibility for years – the accessibility standards and validators based on them just spat out reports that people ticked off to abide to a standard and not to build sensible products. Some measures taken to make your site AAA compliant actually made them less accessible. The reason was not that people were such sticklers, the reason was that – at least in England – inaccessible web sites are against the law. So instead of really building accessible products people built sites that validate and stapled the results of an automated validation report to the handover – done.
Which of course is nonsense. You cannot validate semantics and you cannot automatically test if an alternative text for an image really makes sense. For this you need a human to check this. The accessibility standards had that in them. They also asked for testing with users with different abilities, but all of this became not important when you can show a cool report that means your site passed an automated test.
This attitude also spilled out to enterprise environments where the interface of a web app is less important than how it ties in with the business processes. There a validation report from the W3C validator meant the thing goes live or doesn’t. Regardless of what the HTML really is. And these kind of people and the poor developers who had to work for them started the whole animosity towards validation.
Validators check the syntax but not the meaning or the quality of the code. They are the start of a quality process, not the end of it. By saying validation doesn’t matter at all we neuter the whole process.
Let’s educate people about validating and debugging
Instead of telling flat out that validation is dead and we don’t need it we should educate people how to read and weigh validation reports. We should also help the W3C and others to write validators that result in more sensible reports and allow for exceptions and weighing of omissions. Then we have a powerful piece of the puzzle of creating clean, meaningful code.
The siren song of browser support
The bigger confusion about the need or sense of validation is that people say that it works “in all modern browsers” and therefore it is fine to use. The issue with that is that “modern” quickly becomes “holy shit, why did we ever use this” and “nobody uses that one any longer, let’s not support it”. Another issue of course is that if you see a browser as your main support and test platform then it is also up to you to test your code in all the browsers that are “modern” and in all their permutations across different systems.
A lot of the products that now keep us from getting rid of IE6 are the ones that were built back when IE6 was “the awesome” and supporting it was “building for the future”. A lot of what we achieved in the last years and the current communication between browser vendors was based on us fighting for standards support. Let’s be aware of the trap we fell into once and where thinking about standards got us before we condemn the tool that says how far you’ve come close to following a standard that should be the norm.
Remy will publish his thoughts soon, too. This is an interesting discussion. This now was only about validating – the more interesting question is if it is worth it to write valid code. Personally I think browsers have enough on their plate rendering the things we give them – why should they also fix what we did wrong?
Seems like the whole of Europe is currently up in arms against Google streetview showing their houses (let’s not even start with the sniffed wireless points and their data) and as friends in Google tell me there are queues in the Google Germany office where people request their houses to be removed.
The reason is privacy and people are worried about security. As my mom put it “Thieves only need to use that Streetview thing and see where there are nice houses to steal things” to which I replied that they could also use a technology like a bicycle or a car to do the same thing and they wouldn’t have to go far to steal things.
Now, today a friend of mine Christian Bräunlich had a damn good idea and put it on a mailing list:
Bestimmte Leute wollen ja ihre Haeuser nicht im Streetview haben. Mein
Vorschlag zur Loesung: es wird ein spezieller 2D-Barcode definiert. Jeder kann
sich den ausdrucken und über die Tür kleben. Dieses Haus wird dann verpixelt.
Vorteil: geringer Aufwand, erprobte Technik: das hat schon vor 6000 Jahren
funktioniert. Häuser können automatisiert verpixelt werden. Den Barcode sieht
man kaum, man könnte ja verschiedene je nach Hausfarbe, definieren.
Ich denke ja nicht, dass alle fristgerecht ihre Anträge einreichen koennen zur
Entfernung, und ausserdem bindet das doch viel Manpower bei Google.
In English:
Some people aren’t happy about seeing their houses in Streetview. Here’s my proposal for a solution: you define a 2D barcode that people can print out and display on their house. Houses with a bar code don’t added to Streetview. The benefits are: this is simple to achieve, the technique is old and already proven (6000 years ago, really). You can hardly see the barcode and you could offer several different ones according to the colour of the house. I don’t think that people will be able to send in their requests to be removed from Streetview in time and the overhead in manpower at Google to respond to removal requests is another problem.
This is the opt-out idea. You could also turn that around and make it an opt-in. If you want to have your house in – display a barcode.
The only problem I can see with this is when you have houses with several tenants. The other benefit of this is that Google could offer these barcodes and send them by mail. They could also create a generator that would allow for example shops to also add their names and product offers in the barcode data and thus enhance the Streetview information even further. What do you think?
I get very tired of people looking for rockstar and ninja developers. I find it arrogant and actually detrimental to the whole market of development. We are professionals and we should take our jobs serious. We should also make sure that people who start in a company don’t have to deal with a terrible mess rather than being able to contribute immediately.
During my whole career I concentrated not on bringing myself into the centre and be the rockstar of a department but instead try damn hard to build sustainable teams and departments. This might have been a wrong decision in terms of money but seeing people grow and processes improve gives me a bigger kick than being admired as the guy who knows it all. There is a lot of quick glory in being a “Ninja” or a “Rockstar” but it is actually bad for the company. It is also a problem for your own career as you make people dependent on you rather than being able to grow and change to what you want to be and do in the future.
One of the big mistakes I was part of in the past was that I was part of a team of rockstars. When I joined the company the mandate was to get the best people in front end development and build the coolest products. I was proud as punch to be able to hire people I had a boatload of respect for and always wanted to work with. We all had the best ideas, we had the talent and we were hungry to prove ourselves.
What we didn’t have was the insight into how to make a large company care as much about what we do as we did. What we also didn’t have is the patience to understand that people who don’t want to immediately support you don’t do that out of spite but because they have other things to worry about. A big part of work is politics and that means that things don’t move as quickly as engineers want to. This is a human issue – take too many people to make a decision and it will take longer. On the other hand this decision can become a much better one as it has been scrutinised from several angles. Sadly enough in most cases when it comes to decisions made across departments of companies they don’t turn out better. The reason is that people don’t talk to another but follow their individual agendas instead. A lot of companies made process the goal and not the way towards the goal.
I am right now preparing my talk for this year’s Paris Web and it will revolve around the issue of getting listened to in the company and the market if you are a technical person. We can delude ourselves into thinking that building great products will get us fame and insight and be listened to but in the end it will be the product managers who’ll be remembered being the people who brought these products to life and not the people who built them.
Being a real rockstar gets you the fame, the sex and the drugs. However it also robs you of your privacy, forces you to repeat over and over again what you’ve done in the past and it typecasts you:
It also means that unless you are clever and you start your own label or production company or do your own merchandise a lot of people will make a lot of money on top of your talent and you only get a small share of that.
Rockstar fame is very fleeting – people who are on top now can be amazingly quickly forgotten tomorrow. Popularity is quite a tough thing to keep up and any slip-up you have will be all over the news and misinterpreted to become headlines. At first this aids your bad boy image but later on when you get older it just appears pathetic.
In essence being a rockstar means burning out quickly with a lot of glory but not much sustenance. And if you don’t plan cleverly for your future you’ll end up playing carnivals and open up shopping malls. I have a hard time to find the equivalent for an IT rock star.
For a company it means you have a employee that is hard to work with and that you need to keep happy all the time. A diva that is very much aware of his or her temporary fame and makes ridiculous demands (check the rider of some rock bands or talk to some roadies or people who work in theatres for tales of woe). You also concentrate on a single person and thus cause jealousy in the rest of your staff which means that they either under-perform, try to sabotage the rockstar or leave.
It also means that you have to sort out the troubles your rockstar gets into. Unmaintainable products that have the handwriting of one genius developer and no documentation on them are the IT equivalent of trashed hotel rooms. Headhunters calling your rockstar are the equivalent of the paparazzi. The only thing that is less likely to happen is getting into troubles with groupies.
In essence I see the demand of rockstars as a flattering way of companies to find somebody to quickly burn out and get a quick product out of that can be hyped. Nothing sustainable and especially nothing that hints that there will be a chance of a career for you in that environment. You start at the top of your game and you are expected to over-perform. Any request to get official support to improve will be seen as a weakness.
The Ninja analogy
People calling themselves $technology-ninja has only recently become popular. John Resig was one of the first with the JavaScript Ninja mailing list (which has become very silent as of late) and Nicole Sullivan had an interview published that started with the notion of her calling herself a Ninja.
You know what? I forgive both of them this – both John and Nicole consistently worked in silence and out of a sudden released a deadly cool technique or product before they went off again to hone their skills on the next attack. They never celebrated themselves much but instead promoted technologies to use in a professional environment and to get quick results. I am friends with them and I admire them for what they did and what they are about to do. I am confident they have more and more cool things up their sleeves in the future.
Lately, however, the Ninja analogy runs rampant with 4606 of them being available on LinkedIn:
A lot of the self proclaimed Ninja know their trade but it is actually interesting to see what they have forgotten when it comes to being a Ninja:
Ninja attack silently and use the element of surprise
Ninja disguise themselves to blend in
Ninja are not seen or heard
Ninja use a series of passwords and own languages to talk to another to be more effective
As a company, hiring a Ninja only makes sense if you want to disrupt your competition as the main tasks of Ninja are:
Espionage – do you want to get rid of your secrets?
Sabotage – hire a rockstar instead, he’ll make sure your products will decay quickly
Assassination – not that applicable either.
When it comes to the JavaScript Ninja mailing list this made sense – a closed community with an own language that shares secrets with another and leaks them to the outside world to sabotage bad products and assassinate bad practices. And most people on it are rarely seen or heard (Dean Edwards and Stuart Langridge anyone?).
When it comes to people who call themselves a $technology-ninja the metaphor quickly crumbles to the same levels of “I am a social media expert” or “SEO wizard”.
Look for Sensei, Mercenaries and Padawan instead
If you really want to use an analogy (I don’t think we need to but hey, they sell like hotcakes) then I’d think you should focus on people who really will help your company:
Mercenaries – in the middle ages we had mercenaries who roamed the land offering their strength and skill with their weapon to anyone who could afford them. They also were masters of marketing and changed their names to impressive things like Schwerdtfeger (“The one who sweeps with his sword”). A mercenary is a single minded person doing the job without any regrets, values or beliefs. They get the job done and move on. There is no loyalty beyond the contract and there are no demands beyond what was agreed on. They are independent and bring all the tools they need and are not interested in sharing. If you want to build a product to make some noise and you don’t expect it to be scalable or stay the way it is anyway then these are the people you want. Mercenaries are rockstars with their own label. Or think of Jayne Cobb in Firefly
Sensei – are teachers, as simply as that. People who know their skills and know how to teach them to others. It ails me that in IT trainers are not paid as high as engineers. Being able to build something is one thing – being able to guide others to build the same so they don’t need you or your input in the future is a much less common skill. A good Sensei knows when to guide, when to explain, when to show and when to allow his students to fail and hurt themselves. It is strange but we learn more from making mistakes and avoiding them in the future than from doing things right. This should apply to companies, too. Lately when Google put Wave on the back burner a lot of people started writing sarcastic posts about it – just to learn after some research that there is no problem in failing when you analyse and salvage what was useful. A good Sensei is a developer with experience who knows what to keep away from his students and when to let them run free and show their skills. A good teacher makes himself not needed over time – for his students to become masters and then teachers themselves. Lead by example but leave space in your solutions for the creativity of your students and you will build working products that are ready for future improvements.
Padawan – are young talents that show a massive proficiency in a certain subject matter (in the case of the Star Wars movies the force and being able to not scream every time some guy calls them “Annie”). They don’t need to be amazing at it but they should show adaptability, a hunger to improve and be open and ready to listen to advice – even if it seems not fascinating and shiny at that time. These are developers who want to build things – to create systems as a team and partner with people who are passionate about the other skills necessary to achieve the goal. They also should question authority and find their own way but be driven by achieving peace with their environment rather than disrupting it for the sake of disrupting it. They are developers that you can coach, mentor and form and partner with other skilled people to rely on another and share with another. They are also developers that when they get bored with what they do should get the chance to switch departments, roles and train them up to become leaders and Sensei
What do you think? Is it worth to let vanity and arrogance run our markets and frustrate people who want to learn rather than shine or should we concentrate on building an empowered work force rather than a privileged few?
Addy Osmani’s Rocket Bar looks cool but needs a bit of tweaking to be smooth and of course event throttling for IE. The idea is cool though (not sure about the site design and the “Where Web Businesses Grow” tagline, but I guess that is why I am not a social media superninja)
True colors is a pretty insane Graffiti/Stop Motion project
Blackstar Warrior is a Blaxploitation spoof of Star Wars. The untold story of Lando. I also want to see that for Felix Leiter and James Bond. And yes, I like those Storm Troopers. More at Lando is the man.
HTML5 reset provides a template to start an HTML5 project from – maybe I’ll bundle that into TextMate
