• John Resig - HTML5 DOCTYPE
  It seems that IE7 will allow you to style elements it doesn’t ordinarily recognise if you create an instance of them using JS. John’s pondering whether that means IE7 can be forced to handle HTML5.
  (tags: doctype html5 ie7 javascript webstandards)
• stevenberlinjohnson.com: Outside.in and The Washington Post
  outside.in’s content will now appear on the Post’s website, and vice versa. A sensible connection.
  (tags: localisation maps newspapers washingtonpost)
• Version Targeting and JavaScript Libraries — All in the head
  Drew’s questions about what microsoft’s version targetting would mean for javascript libraries
  (tags: javascript library microsoft versiontargetting)

Recommend this post:

Such has been the flood of information since Aaron Gustafson broke the news of Microsoft’s radical new plans for Internet Explorer that I’ve mostly sat back and tried to absorb it all, waiting before contributing anything.

For those who haven’t been following the developments, Microsoft have said that future versions of Internet Explorer will support a new HTTP header and/or meta-tag which will indicate to the browser which version of IE the page is designed for. Unless the page specifies otherwise, all future versions of Internet Explorer will render it just like IE7 would. If you want IE8 to actually use the new features it brings with it, such as (we hope) improved standards support, you will need to explicitly ask it to do so.

There’s been a lot of response and people have fairly quickly become quite polarised. David Emery has a good list but a few I particularly noted were:

Eric Meyer and Jeffrey Zeldman explaining their support, Jeremy Keith suggesting that at the very least this is the wrong way round (the default should be the latest and greatest rendering engine), Drew McLellan (Web Standards Group Lead) pointing out that while members of the WaSP Microsoft Task Force had been involved in the initiative, this is not (currently) a WaSP-endorsed idea, comments from Ian Hickson,
and Sam Ruby and his commenting crowd considering the technical implications.

Reading all the debate it can be hard to separate feelings about this specific idea from a basic resentment against Microsoft that is harboured by most web developers I know. The failure of Internet Explorer to keep up with web standards has cost many of us, in aggregate, months of work, and our clients lots of money. The time we’ve spent supporting broken browsers could have been time spent improving the user experience or developing exciting new uses for the web. It feels very much as if the only way Microsoft can see to fix the mess they’ve created with their lacklustre browsers (and some very poor authoring tools) is to throw us a new type of confusion.

Regardless of it being Microsoft, though, even after reading all the debate I can’t help but feel that this is a very bad idea. Even if we get to the day that Internet Explorer 11 dominates and IE10 is the only other version used by a significant number of users, this would mean there would still be sites out there that are coded not to older standards than we may be used to, but to one of three or four older rendering engine and their unique set of bugs. That’s too much information for anyone to handle.

And then, of course, there’s the question of other web browsers. Sure, we can add a note that a site is designed for “safari 3, firefox 2.0, IE7 and Opera 9″, but that’s not a complete list even now. And we’re already seeing an explosion in the number of mobile devices, app-specific browsers, screen scrapers and other means of accessing the web. I find it hard to see this as anything other than a short-sighted form of browser lock-in.

So what should we do? Clearly the standards process is moving slowly and it’s taking browser developers several generations of their software to fully support the standards we do have. There’s already a lot of discussion of what should happen to the standards process to change that, but in the meantime I quite like the line of thought in David’s blog entry mentioned above suggesting we should have a way to test for support of various CSS properties. I’m not sure about the precise implementation details, but object detection got us a long way when we wanted to escape browser sniffing before, and maybe that’s still a fruitful line of enquiry?

Recommend this post:

• Consultation Feeds
  "This site, which is very much a work in progress, indexes the details of government consultations from the various websites upon which they’re published."
  (tags: consultation egovernment feeds governmentit)
• Support for BDD and Stories in PHPUnit 3.3 - Sebastian Bergmann
  PHPUnit is getting BDD support, but the syntax doesn’t look very inviting…
  (tags: bdd php phpunit testing)
• mnot’s Web log: Watching WADL (and other rambling thoughts)
  There’s a lot of talk about how we describe RESTful services at the moment
  (tags: rest services wadl)
• scope-out-rails - Google Code
  Very handy looking rails plugin for handling scopes with associations
  (tags: activerecord rubyonrails scope)
• jQuery.ScrollTo
  Nice jquery plugin that provides a number of ways to specify an area of the page to scroll to, and then animates the scrolling
  (tags: animation javascript jquery scrolling)
• GL Networks Inside » Bridging Rails to Amazon SimpleDB using ActiveResource
  This plugin provides a proxy allowing you to use ActiveResource as an interface between a rails app and a SimpleDB store.
  (tags: activeresource persistence rubyonrails simpledb storage)

Recommend this post:

According to wikipedia:

In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.

Design patterns, and particularly their application in dynamic languages can be a controversial topic, and every now and again another round of blog posts bubbles up appalled at the way a new group of programmers have become infatuated with design patterns. Applied without care design patterns can quickly lead to over-engineered code that seems designed as much to draw on as many of the established patterns as possible as to solve the intended problem. But if applied with care, and with consideration of how a pattern applies in the context of your chosen language they can be a helpful way to draw on the wisdom of the coders that came before you, and make your code easier to understand to those who may inherit it.

Written by Dustin Diaz (of Google) and Ross Harmes (of Yahoo), Pro Javascript Design Patterns builds on experience of building complex, high profile javascript applications. That experience shows as each pattern is introduced with solid examples and sample code and then refined to provide looser-coupling, more flexibility and/or better performance.

Early on in the book I was concerned that some of the solutions could become too heavy and the early introduction of interfaces hinted at something akin to the early approaches to pattern usage in PHP, which often looked more like an attempt to turn PHP into Java than a way to use PHP’s own features better. As the book goes on the usefulness of those interfaces, particularly for large development teams, becomes clear and most of those concerns are allayed, especially as the authors offer pros and cons for the use of each pattern and are clearly focussed on how these patterns can help produce more robust solutions.

Most of the patterns will have a fairly immediate impact for developers new to them, and even for those who have used them in other contexts it is helpful to see how they have been applied in JavaScript. Most modern JavaScript libraries rely on several of these patterns to abstract out handling of different browser quirks or adding new event types, and even if you rely heavily on one or more of the major libraries this guide may well help you understand their internals better.

I’ve sometimes been skeptical about books claiming to be targeted at an advanced target. Labels like “pro” are often handed out far too easily. But in this case it seems deserved. While the book does a good job of quickly introducing approaches to object-oriented programming in JavaScript, that’s based on an assumption of a solid knowledge of the language and of OO development in at least one language. If you’re a newcomer to JavaScript or just looking for a way to add a few fancy features to your web pages this isn’t be book for you. But if you have some serious JavaScript development experience and are needing a way to tighten up your code to make it more modular and more maintainable, this book is well worth your time.

Disclaimer: I was sent a copy of this book for review by the publisher. You can find it at apress, amazon US, amazon UK and all sorts of other places.

Recommend this post:

• Graceful Exits » FixMySpine
  Why an overblown government project would have been a lot better had it been built by/followed the approach of mySociety.
  (tags: enterprise governmentit mysociety nhs)
• ‘No one in government IT will have done this before’ | Technology | The Guardian
  A report on the Power of Information Review barcamp
  (tags: barcamp governmentit opendata powerofinformation)
• ruby-dtrace’s ruby-dtrace-0.0.4 Documentation
  Ruby bindings for dtrace. Could be handy for tuning code. It’d be nice to see it also make it easier to work out the trace commands.
  (tags: analysis dtrace ruby tuning)
• Yahoo! OpenID
  Yahoo’s explanation of OpenID
  (tags: documentation openid yahoo)
• stereogum: Trent Reznor Proposes Internet Tax
  Trent Reznor’s experiment with new distribution models is pushing him towards the "tax on service providers" line. He doesn’t seem to have given his experiments very long before jumping to this conclusion.
  (tags: distribution futureofmusic music musicindustry)
• Plugins - Validation Scenarios - Agile Web Development
  Nice syntax for setting different validations for different scenarios in ActiveRecord models
  (tags: activerecord rubyonrails validation)
• Lefsetz Letter » 2000/2008
  Looking at the drop in sales amongst the ten biggest selling albums of 2000 and 2008, and pointing out that just because the hits aren’t as big doesn’t mean the market is unhealthy.
  (tags: futureofmusic longtail music musicindustry)
• 20-Minute Quick Start Guide for RFacebook
  "showing you how to create a Facebook application from scratch using Ruby on Rails in 10 easy steps"
  (tags: facebook plugins rubyonrails)
• Dare Obasanjo - Myth: RESTful Web Services Don’t Need an Interface Definition Language
  "he examples of Atom service documents and link elements in HTML, highlight that there is real world value in describing the interfaces to your RESTful Web Service. In addition, Atom service documents show that you can define an interface definition
  (tags: atom rest webservices wsdl)
• Blogger in Draft: New feature: Blogger as OpenID provider
  Blogger blogs are also becoming OpenID providers. A lot of people now have OpenIDs. Hopefully we’ll be seeing more sites consuming OpenID as well as serving it.
  (tags: blogger openid)

Recommend this post: