boogdesign posts

I'm more of a web developer than a 'Microsoft developer', but I use a lot of the MS stuff at work and I really enjoyed WebDD last February so I thought I'd give the more .Net focussed parent event a try.

Why IronRuby? (Presentation) Dave Verwer - I'd been to a couple of Dave's talks at the WebDD event and enjoyed them tremendously, so I went in to this one with high expectations. The talk started with some of the benefits of Ruby - a dynamic language with elegant syntax designed for simplicity and productivity, before going on to discuss how IronRuby and the DLR are implemented in .Net. The DLR is basically a layer for dynamic languages on top of the standard CLR, it is an abstraction of the what was developed in the course of getting IronPython up and running. At this point Dave admitted that IronRuby wasn't yet ready for use, so the rest of his talk would be about (C based) Ruby 1.8 - which IronRuby is targeting for compatibility. This was a bit of a disappointment for me, because really I was after a more practical demonstration of IronRuby than another presentation on Ruby - but it's possible I was in the minority given the audience. Check out the IronRuby website if you want to learn more.

Entity Framework (Presentation) James Winters - I had no idea what this was before the talk, but the title sounded more interesting than the others available in this slot, and it saved me leaving the room when I knew I wanted to see the talks either side. In the event, I was glad I stayed. To give a simple sound bite - Entity Framework is like an ORM on steroids, which will allow transparent mapping to non-relational stores, such as LDAP, as well as the more usual SQL stuff. The plan is for all MS server products to move to Entity Framework for their data access, though at the time of the talk the only backend available was SQL Server and all the examples were basic ORM stuff. The logical model of Entity Framework is made up of three levels:

• O-SPACE - the object model, eg. LINQ
• C-SPACE - the conceptual model, eg. Entity Client
• S-SPACE - the store - eg. ADO.Net.SqlProvider

All levels are scoped by an entity container, which defines a namespace and an object model, and the goal of the MS Visual Studio team is to be able to generate the lower levels using visual tools.

Entity Framework supports multiple querying methods:

• ESQL - very similar to HQL in Hibernate
• Object Query - a generic object interface with caching and lazy loading, which can either be read only or mergeable
• Use Entities directly
• LINQ

There are some limitiation, there is no locking by default and, while it's going to be possible to map stored procedures the visual tools aren't going to support it for some time so you have to write up the XML manually. Generally, though it has a slight whiff of the architecture astronaut, it looks like an interesting addition to the .Net toolbox (Slides available here).

Why do I need an Inversion of Control Container? (Presentation) Mike Hadlow - I'd heard of Inversion of Control (IoC), but hadn't really understood what it was for. The presenter, Mike, had been in a similar position until he started studying it seriously, and now he was here to share his epiphany. The main problems IoC is trying to address is that the relationship between component size and complexity is not linear - double the size of your components and you quadruple the complexity - but breaking components into smaller pieces tends to lead to increased dependencies. Inversion of control reduces the complexity of large components and manages the dependencies between them. The principals of inversion of control (paraphrased from Robert Martin) are:

• High level modules should not depend on low level modules
• Abstractions should not depend on details
• Details should not depend on abstractions

Typical problems of OO code without IoC are:

• Difficult to unit test
• Tightly couple components
• Violates the single responsibility principal
• Violates the open/closed principal

Inversion of control helps with all these by allowing constructor injection and property injection. If these can be injected into components at runtime, rather than hard-wired into the components, then it becomes possible to modify the behaviour of components without having to modify the components thus satisfying the open/closed principal and reducing the coupling (property injection) and also to easily mock objects for unit testing (constructor injection). Mike then moved on to some detailed demonstrations using the Windsor component from the Castle project, before concluding that IoC is really just the thorough application of design patterns and other OOP best practices. Therefore you should only start considering inversion of control once you're already familiar with these and have already implemented things like unit testing (Slides available here).

Dynamic Languages on .NET (Presentation) Michael Foord - My first session of the afternoon and by this point I was flagging a bit after having to get up early and make the trip out to Reading. Michael is one of the authors of Resolver, a spreadsheet based application environment, aimed at the financial markets and written in IronPython. The app is approximately 30000 lines of code, thus refuting the myth that it's impossible to write large applications in a dynamic language, and it's spreadsheet model is implemented in a Python hash table, making it very easy to extend Resolver with new types and operators. After a discussion of what constitutes a 'dynamic language' and the overall benefits of Python and IronPython in particular, Michael moved on to some practical examples based on his IronPython Web IDE (Slides available here)

Testing Your Applications With MbUnit Gallio (Presentation) Ben Hall - unit testing is a popular topic on programmer blogs these days, and this was reflected in a fairly full room for one of the 'minor' talks (ie. we weren't in one of the big rooms). Ben covered some best practices of automating unit testing on .Net with MbUnit and Gallio, starting at the database layer (use transactions and rollbacks or COM+ transactions), the business object layer (mocking and inversion of control) and the user interface (don't try and automate it!). An interesting if slightly hurried talk which I was unfortunately too tired to pay full attention too (Slides available here)

Overall a good day, I definitely learned more than one new thing per talk and the Microsoft conference room facility is a good venue for these sorts of things, so 4 out of 5, and I'll almost certainly try and get to the next one.

I went to this BCS North London branch event because they usually have an 'enterprisey' slant and this one was supposed to be about Web 2.0 and mashups, which is not something I regularly associated with enterprise IT. Andy Mulholland was a very good speaker, it seems like we got the same presentation he regularly gives to boards of directors, the slides are available from the link in the previous paragraph. From now on I'm going to assume you've looked at them and list some of the things Andy discussed while he was showing the slides that stuck in my mind (ie. for an overview of the whole talk, read the slides).

The key trend affecting enterprise IT in the drive to web 2.0 is that users and consumers are now driving technology adoption, they get used to things at home and start to ask themselves why they can't use similar tools at work. As the proportion of tech-literate vs tech-illiterate clients and workers shifts in each industry, we pass an 'inflection point' past which businesses have to change to remain competitive. There are some businesses where this has already happened: travel; retail; music. The traditional business view of IT products is characterised by: "If I purchase this, I can work more cheaply." The user led change of priority is from the perspective: "If I purchase this, I can work more effectively."

There are some common traits of businesses which 'get it' which can easily be contrased with more traditional business practices:

New: Amazon leads with the most popular items responding to external demand
Old: Barnes and Noble leads with its internally defined offers

Right: eBay allows external demand to create new markets and indexes
Wrong: CommerceOne failed as it defined the markets that it would make available

Aware: Google business model continuously improves, people explore for the new
Adaptive: Traditional Software business model depends on set upgrade offers periodically

Innovative & Money Making: Second Life participants create over 7 million lines of code a week to improve environment. As of December 2006 456 people earn over $500; 29 over $5000; 2 over $25000 Every month from participating in Second Life. About 500,000 Chinese work in “gold farms” creating superior players and selling them.

Web 1.0 was characterised by content, web 2.0 is characterised by contacts or community, this reflects a general shift for the knowledge worker: 20 years ago 80% of the knowledge they needed to do their job was in their heads, now only 20% is in their heads and the rest depends on them exploiting the vast information resources available, which is too vast for them to do by themselves.

Finally Andy discussed how to build a business case for mashups (and web 2.0):

• Not all valuable business interactions involve a transaction
• Front office to back office integration depends on open standards
• We are fixated on productization. Move the value proposition from the box to the knowledge.
• Wrong question: "If I had Google Apps, what would I save over MS Office?"
• Right question: "What can I do with Google Apps that I can't do with MS Office?"

Overall this was an excellent talk, 5 out of 5, which may not be obvious from my potted summary. If you have a chance to see Andy Mulholland speaking in person I recommend you take it.

My final talk of the day was title on the signup page 'Developing for the mobile', which led me to believe it would be a discussion of web applications for mobile devices, but the title of the talk on the day was as above, and focussed mostly on web content rather than application type interactivity. Despite not fully meeting my expectations, this was perhaps the talk where I learned the most new stuff.

Gummi started with a discussion of why mobile website development has been so much more difficult than standard web development. Mainly this comes down to standards - although 'desktop' web developers complain about inconsistencies between popular browsers, this is nothing compared to the great variety of mobile browsers and devices and also the different standards that have been implemented. He recommended that these days it was best to concentrate on cHTML for the Japanese market and XHTML for the rest of the world.

Mr Hafsteinsson's golden rule for mobile websites - KISS. Generally that cunning feature you've thought of which would be 'neat' rather than useful to users is a feature you don't need on your mobile site. There were then a sequence of slides with more specific tips:

• Use well formed markup - use the correct XML preamble and DOCTYPE declaration, validate your markup and specify character encoding. While it is feasible for a desktop browser to do a lot of processing to correct your markup mishaps, most mobile devices don't have enough spare processing power to deal effectively with invalid input
• Send Google a Mobile Sitemap - on the mobile web people don't (generally) type in URLs, because typing options are usually fairly restricted and/or awkward on mobile devices, there is a much greater reliance on search engines so you need to do everything in your power to help the search engines out
• Understand best practice - two sites specifically mentioned were the W3C's Mobile Best Practices and the dotMobi portal
• Test in emulators - it's not feasible for you to obtain every mobile device on the planet, so testing in emulators is a good shortcut. Some of the specific emulators mentioned were the NTT DoCoMo i-mode HTML Simulator, the wmlbrowser extension for Firefox, the OpenWave emulator and the NetFront emulator (which has a Linux version) and, of course, Opera which can emulate the phone browser in the desktop version.
• But don't just test in emulators - sites should be usable on entry level phones and provide an effective experience on mid-range devices. Be aware that these devices have far more limited physical features than your desktop development machine, things that work fine in the emulator on your desktop with 2Gb of RAM and a broadband connection might not work well, or at all, on a GSM phone with 64K of RAM. Again, don't overload your websites with features that overload more basic phones.

That was the bulk of the talk (actually relatively short), but there was a long question and answer session which covered the use of XHTML Mobile profile (and not Basic, as shown on the slide at the beginning) on .mobi websites and quite a lot of discussion on the merits and pitfalls of user agent sniffing (using, for instance, the WURFL device database). Gummi's advice was not to blindly adopt a sniffing approach, use standards for the most part and use sniffing to get round incompatibilities where appropriate for your users - generally think about your users rather than about the devices. Hopefully increasing use of standards in mobile websites will lead to better support of standards in mobile devices. The questions went on with some discussion of the Google mobile search and content transcoding (where Google automatically converts a website to mobile compatible format when you click on the link rather than sending the page directly), how this would become less necessary as more sites provided mobile versions of their content, and also a meta tag you could put in your head element to direct Google to the mobile version of a particular page (though I can find no mention of this elsewhere on the web, so if anyone locates it please leave a comment).

Overall an excellent talk despite being short, a bit high level and lacking code examples (which I know I've criticised other talks for, but in this case the high level information was very useful to me). Also the question and answer session covered a lot of extra ground, so 5 out of 5. If you are planning to get involved in the development of mobile websites I would recommend spending 45 minutes viewing this talk.

Since I'm now a few weeks behind on my reviews (the date of this post is when I started writing it...), probably everyone who cares about Google Gears has heard about it by now, so I'll keep this short. Chris talked about the design goals for Gears, for both end users and developers. For end users it boiled down to providing a seamless experience between periods of online and offline activity. For developers the goal was to build incrementally on existing skills and techniques - leveraging all those newly learned Ajax skills rather than replacing them, "preserve existing knowledge and momentum" was the exact phrase. Google themselves plan to support all the major desktop browsers with extensions and plugins, but the implementation is an open standard (an open source) so if you feel the need to have it implemented on your platform of choice you can go ahead and do it yourself.

On to the technical details, Gears has three major components:

• Local Server - basically a local proxy, your application files go into a ManagedResourceStore, which has a manifest, so all your app files can be versioned together, and ResourceStore for any other random web resources your user may access
• Database - an SQLite database with a javascript API
• WorkerPool - a method for supporting javascript concurrency through Erlang-style lightweight processes, no shared memory and communication through message passing

If it was just the LocalServer by itself, this would still have been a useful extension - that's all that's really needed to make your web app work offline, but the Database and WorkerPool components enable a whole different approach to web application development. WorkerPool makes it much easier to write applications which do client side data intensive processing, and Database allows you to build applications which sync back to a central server periodically (similar to how .Net CF + SQL Server Compact applications are intended to work now). Expect to see some startups with innovative products based on Gears in the next few months.

Several code examples and clear explanations, an excellent talk as befits what is obviously a key technology for Google - 5 out of 5.

I spent most of the afternoon fannying around with Safari on Windows in one way or another, so I thought I'd write up my first impressions. First off, things I liked:

• Fast Javascript - javascript heavy web pages (for example, GMail) worked really quickly and were very responsive
• Fast rendering with position:fixed and iframes - this seems to be a combination that really slows down Firefox (and remember, anything which has a GoogleAd unit on it has on iframe, I ended up re-redesigning this website as a result), just scrolling up and down the page becomes an effort, but in Safari everything remains smooth
• 
  It's pretty - there's no getting around it, not just the overall look of the browser, but the little icons in alert windows and the semi-transparent configuration popups are all very nice
• 
  Excellent default view of RSS feeds - even better than IE's, and loads better than Firefox
• Snapback - this is nifty, can be used as a short term bookmark thing but, by default, will 'snap you back' to the first page you visited on a site, or your search results if you were visiting a site from Google
• 
  Bug reporting tool - looks nice and easy to use, allows you to attach a screenshot and the page source by ticking checkboxes
• Resize text field - a great idea, but I could only get it to resize textarea elements rather than any text input. It also had an interesting effect on the post page of this blog
• 
  Activity window - shows the file size of every page element, very neat, though of course with Firefox it's a simple matter of getting an extension to do this

But there's also a list of things I didn't like:

• 
  Can't make all links open in tabs - links which open a new window, open a new window, in Firefox everything opens in a tab. There is a 'merge windows' option, but I'd rather it just opened the links into a tab in the first place
• 
  Can't 'choose where to save every file' - I have a whole hierarchy on my hard drive for saving files into, so that I can find them later, but Safari makes me first save the file and then manually move it where I want it to go
• Single or double click doesn't select whole address - on Windows clicking on the address bar selects the whole text (on Linux, double click does the same), in both Firefox and IE, and then you can immediately start typing knowing you'll replace it, Safari only selects to the nearest full stop either side, so you have to click and drag to select the whole address
• Auto-complete sometimes interferes with typing address in - this happened to me a couple of times, I assume it's really a bug, but Safari would become so obsessed with providing me with autocomplete options in the address bar that it wouldn't let me type a new URL in (first noticed after I'd visited the Washington Post website, couldn't type a second 'w' into the address bar sometimes)
• Can't resize window by border - although it's nice that the chrome doesn't waste any screen real estate, I'm used to being able to resize my app windows from any border
• 
  Can't detach bookmark manager, and ctrl+click doesn't work - in fact I couldn't get any tab to detach, maybe I was doing it wrong, but according to the help file ctrl+clicking the bookmarks icon was supposed to open it in a tab instead of over the top of whatever you have open, it didn't
• No extensions - this is the killer for me as far as everyday browsing is concerned, I've gotten used to the seven or eight extensions I use regularly in Firefox and it seems unlikely they would all be replicated in Safari, though it seems there's some activity in the Safari extensions area, and also the possibility of doing your own development with Apple and WebKit components

Overall, I'm probably not quite as underwhelmed as most Apple developers seem to be, also the security exploits, discovered within hours of the launch immediately detract from the twelfth reason why Apple thinks we'll love Safari. Also, while the browser is fast (and it's still only a beta, remember) I don't think that alone will be enough to garner significant market share - after all Opera has been faster than both IE and Firefox for a long time but lacks the ubiquity of the former and the customisabilty of the latter. Certainly I don't see myself using it as a regular browser in the near future - 3 out of 5.

The GData APIs are a uniform interface into almost all the Google applications (Blogger, Mail, Calendar, Spreadsheets etc.). They're all based on an extended version of Atom Publishing Protocol, a REST style interface (though there is some difference of opinion on whether or not it's a best practice implementation of APP (see also some discussions on Reddit and this followup). In general this is an exciting development and I could imagine a number of practical applications for my day job, and having a unified API across all the Google Apps should make it easy to build applications which integrate with all of it.

Unfortunately, I didn't really enjoy this talk much at the time, mainly I felt there weren't enough code examples. Watching the video of the talk again now I see far more example code than I remember which indicates that I wasn't really taking it in. Most of the example code was in XML files, most of which were pretty hard to read from where I was sitting, or logs of HTTP interactions for high level descriptions of how it would work, but none of the code shown was associated with the demos in the second half of the talk. I think my expectation going into the talk was more along the lines of "here's some lines of Java code which insert an event in the calendar." Perhaps that was a little unrealistic, given the number of languages Google supply libraries for, not wanting to either show examples in several different languages or stick to one and risk alienating people, but it coloured my impressions. Though the fact that the talk was also the shortest one of the day indicates that perhaps there was room for some analysis of the code associated with the examples. Generally, unlike the previous talk, I didn't feel like I came away with enough information from this talk to dive right in and start trying stuff, so 2 out of 5. On the plus side, because this talk ended early I was able to catch the end of the KML / Google Earth talk.

The talk started with a history/overview of Google Maps API - this was quite useful to me, because I wasn't that familiar with API to start with, but I imagine there were plenty of folk in the audience for whom this was stuff they already knew. It also made it more difficult to me to spot the actual new bits, but this is what I spotted:

• API for directions - a simple javascript function, called with a div to return the results into, and the option to add a traffic overlay
• Adsense for Maps - to allow developers 'to monetize their applications', not yet released but 'coming soon'
• Mapplets - as mentioned in my first post, except this time there were several different examples and some code to look at

Andrew then went on to talk about KML and GeoRSS, specifically taking your geographic data out of your javascript, where it is locked away and hidden from the world, and putting it in KML and GeoRSS files which can be indexed by Google. The talk concluded with some more demos of Mapplets and using the API, using the preview version of Google Maps, followed by a question and answer session. There were some useful answers, my favourite tip - type the url of your KML file into the search box on Google Maps to have your content rendered on it.

Overall a very interesting session, especially considering my relative lack of knowledge, the large number of simple examples with sample code helped me follow along very well, so 5 out of 5.

Chris Dibona started us off with a potted history of Google's 'API' activities, up to and including Google Maps, and how that linked in with this, their first large scale developer event. Then he went on to talk about the culture of openness (and open source) at Google using as an example the sitemaps protocol. He explained how they wanted the protocol to be open, and they wanted to encourage other search engines to use it, so that's why they took the unusual step of releasing the specification under a Creative Commons license. This led to what I thought was the key slide of Chris's part of the talk, entitled "But, why?":

• What's good for web developers is good for Google
• Open Source and CC are good for web development
• We use Third Party, trustable, licenses that are above reproach so that developers know that they can trust that which we are providing
• And it allows Google to iterate APIs faster
• And open source makes standards possible

Apart from the rather hackneyed attempt to get 'trust' into the middle point twice, this was a very interesting position. Google is good at the web, so anything which makes the web more useful, and by implication increases web usage, is good for Google. Although this attitude does have a bit of underlying arrogance, it's hard to see many other companies making a similar claim (eg. swap 'Google' for 'Microsoft' and 'web' for 'desktop platform', or perhaps even 'IBM' and 'IT Consultancy'). Chris then went on to explain how all this applied to Google Gears (or, as we were told it was originally called, 'Scour' - as in "scouring the web with ajax" - yes, think cleaning products ) - there was no intention for Google to implement for every browser on every platform but, because it was all open source, they fully expect people to implement it themselves if their own favourite browser isn't supported.

Next we heard from Ed Parsons, a self described 'manic geographer'. He talked about how deeply embedded geographical information was in the world's data and how Google Maps API would help us developers exploit that. He made the claim that 80% of the world's information is either explicitly or implicitly geographical, though the evidence for this was somewhat apocryphal. He also showed the 'long tail' of potential geographical information and talked about how Google saw their role as providing tools to allow people to fill in that long tail with useful (crawlable and indexable) geographic information. He then gave us a potted tour of these tools - Google Earth and Maps, Mapplets, StreetView and Sketchup plus KML. This was followed by a question and answer session, not all of which were strictly development questions - licenses and privacy featured strongly, but Chris and Ed dealt well will all of them and were quite happy for anyone with concerns to contact them directly after the event.

Not a lot of technical content in this session, but enough to keep me interested all the same - 4 out of 5.

OK, so it's cheating a bit to do a review of the free lunch, but this was probably the best free lunch I've ever had at one of these developer event things. Lots of sandwiches, each plate had a different selection (which I didn't realise initially), plus baguette style things and other fancy bread stuff. Each table also had a selection of fruit including, for some reason, pineapples even though there was no cutlery. There was a 'smoothie bar' with various fruit based drinks, fruit juice, tea and coffee, and various yoghurt and nut based desert things as well as actual cake type deserts. Even if you have no intention of using any of Google's technology in your development, it's probably worth singing up for the next event just to get fed - 5 out of 5.

Erik started with a discussion of what motivates people towards agile practices. He quoted a recent study (I'm not sure, but I think he meant this one from the IEEE) which arrived at the conclusion that 15% of 'waterfall' projects 'succeeded', whereas 40% of 'agile' projects 'succeeded' (gratuitous quotes because he wasn't sure what the words were actually defined as in the context of the study). It's nice that agile practices can result in such a big improvement in success rates, but Erik didn't think this was the main reason why they were embraced, he thought the motivation came more from self interest as a result of the threat of outsourcing. If coding is a commodity, then it can be outsourced, and it makes sense to outsource to the cheapest supplier. But if software development is a process which relies on regular face to face meetings between developers and customers (ie. agile) then that's much more difficult to outsource.

After this short introduction, he had ten slides for his top ten (in no particular order!) reasons why agile teams fail. It's fair to say that a lot of the reasons, like agile practices themselves, reinforce one another:

#10 Believing in Myths
There are a lot of myths which have built up around agile methodologies - pairing costs twice as much; no documentation is required; agile practices are 'cowboy coding'; Scrum is agile. Erik went into each item one by one and dismissed them, for example reducing the amount of documentation is not the same as having no documentation - just produce the documents which will actually get read, there is more to just pair programming than just one person doing nothing and if you're following a recipe out of a book then you're not really doing agile. His main point was that believing in the myth is likely to cause the myth to become reality.

#9 Using Controversial Terminology
Common agile buzzwords are actually quite frightening to managers - say 'extreme development' and they hear 'risk'. T