Software As She’s Developed

Robots, SEO, Sitemaps, Web

The good news is that an agreement has been reached on the Sitemaps protocol by Google, MS, and Yahoo! (via TechCrunch). The Google originally developed this protocol.

The bad news is … who’s using it? Supposedly Sitemaps improves ranking, but a quick sample - techcrunch, digg, odeo - found 0 out of 3 using it (404s for site.com/sitemap.xml and site.com/sitemap_index.xml).

Okay, but it’s kind of complex for a custom website to build in support … so maybe it’s down to CMSs to offer built-in sitemap support. Nup. Neither WordPress (according to this blog) nor MediaWiki (according to Wikipedia) support it. There’s a WP plugin, but …

Maybe this agreement will spur the CMS developers to support sitemaps. I’ve never really understood exactly what it offers that robots doesn’t, and I’m hoping the sparse Sitemaps website will illuminate at some stage.

Ivan Moore’s “Ten Years On” post reminds me of an anniversary I overlooked, it’s been five years since receiving my Photocopying Diploma, Professorship of higher Drinking, Programmership for Hypothetical Developments PhD - picked up five 339-page doorstops from the printer on the morning of September 8, 2001, signed the declarations, and it was accepted in October, 2001 (a formality as it had been through review earlier in the year).

My homepage at the time, notable for its inclusion of the charming tilde character (~) in the URL, is what my present homepage evolved from, in all its rude aqua glory, and the later stages were fortunately captured on the Wayback machine. Earliest archive is from 1998. I didn’t know much about blogging at the time (only robotwisdom which appeared in a usenet .sig), but it (along with pod/vod casting) would be a great tool for anyone performing research today.

The thesis was entitled “Design Reuse in Software Engineering and Human-Computer Interaction” - we looked at techniques for knowledge/design reuse that improve usability. The major problem in this area is a divide between disciplines. This continues to be the case in my experience - although usability is now at least a concern of some decision-makers, most organisations are still unable to do much about it because of the sensitive process requirements and the nature of the staff required. This thesis aimed to demonstrate how the issue could be improved with knowledge reuse techniques, i.e. design and process patterns, as well as other techniques like online knowledge repositories (i.e. the sort of application we now refer to as a wiki).

Here’s the abstract:

Practitioners of Human-Computer Interaction (HCI) have a wide range of techniques and methodologies at their disposal, but few avenues for reusing successful design solutions. A mature discipline of HCI requires a systematic approach to learning from past results. This thesis proposes a number of techniques for improving design reuse in HCI. Some apply specifically to high-level design while others also consider detailed software design.

The major focus is the adaptation of the pattern language concept which originated in building architecture and town planning. It is argued that the properties of pattern languages suit many concerns for HCI. This motivates an investigation concerning how pattern languages for HCI might be documented and used.

This thesis is especially concerned with highly-constrained pattern languages. Rather than producing a universal HCI pattern language, several languages are developed, each with a strong focus on a particular area. A tight scope, it is argued, provides a coherent language structure and therefore provides a strong degree of assistance to practitioners. Three such languages are documented: (a) The Safety-Usability Patterns language focuses on safety-critical systems and demonstrates how a pattern language can provide guidance for high-level design; (b) Multiple Model-View-Controller (MMVC) focuses on implementing a small set of tasks within the model-view-controller architecture, demonstrating how a pattern language can provide guidance on detailed software design and still address usability; (c) Planet focuses on internationalised systems and combines the previous approaches to mix high-level design guidance with detailed design guidance, demonstrating the interdisciplinary capability of pattern languages. Several other forms of reuse are also considered: (a) online repositories, which store knowledge about user characteristics; (b) generic tasks, which capture activities recurring across many applications; (c) reusable software components, which can be documented via design patterns.

Results of this work have been validated in several ways. An experiment with designers using generic tasks indicated that they are useful for rapid brainstorming of software functionality. A second experiment with designers using Safety-Usability patterns led to a set of guidelines for developers and pattern authors. The Online Repository concept has been demonstrated with a prototype website developed in conjunction with this project. Three programs have also been developed which exemplify most of the MMVC and Planet patterns. The results of this work are largely favourable for the techniques which have been proposed. They indicate that pattern languages can facilitate reuse of high-level design, detailed software design, and a style of interdisciplinary design that bridges the various levels of abstraction which HCI must address.

Ajax, Ajaxian, Java, Javascript, Phobos, Rails, Ruby

On Ajaxian, Dion points to Sun’s Phobos project, an attempt to build a new platform for server-side Javascript. Phobos came out six months ago, around the time of the May Ajax Experience.

No-one has taken server-side Javascript seriously since it died a premature death in the mid-90s. But there is great potential…

• Server-side Javascript would allow for code sharing between browser and server. The most obvious application being validation code, but since no-one really bothers with server-side Javascript, there are probably many other patterns as well. One pattern I came up with a while ago is Dual-Side Templating, where you have the same parametized HTML template on both the server (for initial page load) and the browser (for subsequent additions to the page). I implemented the server templating in Ruby, but it would have been a lot easier if the server was running JS. That’s just one example.
• Server-side Javascript would keep us Ajax types more sane. Right now, an Ajax developer has to constantly flip between JS and [insert favourite server-side language here]. True, you always have to flip over to other “languages” too, viz. HTML, CSS, SQL; but there’s always a special place in the programmer’s head for the core language of the day. With Ajax, you have two such languages. If those languages are quite similar (e.g. Javascript and PHP), it gets frustrating because of all the subtle differences (new Array() versus array()). If they’re different (Javascript and Ruby), you’re trapped in a Whirf-Brock disconnect, constantly flipping between two different worldviews. Slight exaggeration as it’s certainly do-able, but it would be a lot easier if programming in one main language.
• Server-side Javascript would pose less of an issue for IDEs. With new improved Javascript, IDEs are being forced to support Javascript in order to keep up. It’s far more important than supporting SQL etc; so basically, IDEs now have to provide solid support for at least two serious languages…it would be easier if it was only one.

Now a framework like Phobos has much to offer the world compared to the server-side Javascript of the mid-90s:

• Phobos is apparently inspired by new frameworks such as Rails. With the right libraries and improved patterns for OO, inheritance, etc, Javascript can compare admirably against Ruby. Not in every regard, but then there are actually some aspects of JS that are superior (e.g. functions as opposed to blockism; dynamic member creation).
• There’s a lot more known about Javascript now, and it’s almost certainly the most widely understood language in the industry, even though it’s not the primary language for many (cf. English).
• Because of all the JS code now running in the browser, there are probably a bunch of synergies with server-side JS - these could be exploited by a well-considered server-side JS framework.

As an open platform, Phobos has the best chance right now to make server-side flourish. But I agree with Dion, that there is reason for concern about whether it will happen.

Sun may already have this. Will they be able to market it? Unfortunately, the track record isn’t there, so it will probably languish. Buy maybe not.

DoTheseTagsActuallyWork, Folksonomy, ICal, Tags, Upcoming, Web2.0

Here’s a view of upcoming events in London at this time.

Three closely related topics with a number of web-savvy taggers (if attendees of events like this can’t tag, who can?). And yet, zero tags in common.

It would be very compelling to subscribe to events in your area and under a certain topic, so they automatically appear in ICal, GCal, etc. But the topic would have to be general enough to provide more than one event a year, and chances are there won’t be many “microformats” gigs in your local area on a regular basis. i.e. what’s obviously required is a tag like “geek” or “web” that’s general enough to be useful for the use case of a calendar subscriber.

Perhaps reflecting the tendency for people to think in concrete terms, the taggers here opt for very precise, specific, terms. The conventional wisdom on tagging is that people will come up with their own conventions and systems should stay out of it, but isn’t that a rather defeatist stance on our ability to create remotely intelligent software in 2006? Rather than force users to go against their nature and think abstractly, maybe the system could go all fuzzy and do some useful cluster analysis. I’d rather subscribe to a slightly inaccurate “web-ish” cluster than 20 different feeds covering every concrete concept related to the web. Granted, it’s also more work to develop, but it’s something that could easily be encapsulated in a library.

Agile, Ajax, AjaxPatterns, Firebug, Firefox, DHTML, IE, Javascript, TDD, Venkman, Web, Web2.0

Welcome to Ye Olde Ajax Patterns Podcaste, the final in this series that began twelve months ago. 3+4+4+1 = 12 podcasts in all, covering 71 patterns (the 70 patterns in the the book as well as Dyanmic Favicons). Find them all on the podcast category - www.softwareas.com/category/podcast/ or subscribe to the podcast feed at www.softwareas.com/podcast/rss2. Thanks for listening!

This podcast covers eight patterns on debugging/diagnosis of Ajax Apps, as well as testing Ajax apps, and I’m joined by Craig Shoemaker from Polymorphic Podcast, also a co-author of “Beginning Ajax with ASP.NET”. After some announcements, the interview begans at 6:00. The podcast overall is 60 minutes.

Ajax Diagnosis Patterns:

• Logging
• Debugging
• DOM Inspection
• Traffic Sniffing

Ajax Testing Patterns:

• Simulation Service
• Browser-Side Test
• Service Test
• System Test

With the series now complete, the podcast will now resume regular Sotware As She’s Developed topics including but not limited to agile development, Ajax, the web, and usability. Also, more conversations - please drop me a line at michael@mahemoff.com if you’d like to come drop in for a skype chat.

As always, credits on this podcast to My Morning Jacket for the lead-in track, “One Big Holiday”. All podcasts in this series licensed under CC.

AjaxPatterns, DesignPatterns, PatternLanguages

It’s cool to see Yahoo! posting a job for pattern curator:

CURATE THE YAHOO! PATTERN LIBRARY Yahoo!’s Platform User Experience Design team is looking for a new curator for the Pattern Library. The curator works with designers from across Yahoo! to develop new patterns and to eventually migrate a pattern to the public library. You will be responsible for spotting trends in the designs of our properties, for designing and crafting new additions to the library and for evangelizing the authorship of new patterns among your Interaction Designer colleagues. You will partner with our Platform Presentation Engineering team to create interactions and best practices that accompany the UI Widget Library. Additionally, you will own the external Public Pattern Library and develop the pattern lifecycle from internal to external libraries. And last but not least, you will be the spearhead and driver for a new addition to our Library suite - a new Terms Library and will work closely with our internal editorial team.

Patterns will become more important to organisations as companies realise there’s value in concrete advice based on real-world examples, to complement vague mission statements with stuff people can actually use day to day. This will be aided by the general trend towards wikis and more user-friendly document evolution. For several years now, Yahoo! has been using patterns in this more holistic sense, and the ad for a pattern curator suggests they’ve been more than happy with the results.

But, Perl, ProgrammingLanguages, Ruby, SelfDocumenting, Syntax

I often want to use an operator called “but”, the complete equivalent to “and”. It would let me say:

if guest.wants_to_see(report) but report.is_premium_content
    raise PremiumContentException
end

As opposed to:

if guest.wants_to_see(report) and report.is_premium_content
    raise PremiumContentException
end

The first example is easier to comprehend because it’s closer to the business rule and the way we think about it. You could argue it’s pointless to add redundant terms to a language, but 100101100101001010010111010101.

So there are times when “but” is clearer than “and”. Likewise, there are times when “and” is clearer than “but”, which implies that we need both. Here’s an example of the latter.

if guest_user.wants_to_see(report) and report.is_public
    show_report
end

I like how some languages include redundant words like “unless” and redundant constructs like “do … while”. Some say they create many ways to do the same thing (Perl argument), but that’s often not the case; there’s often one way that’s the clearest, as the examples above illustrate.

So do any languages have a “but”? I see that Perl does, but it apparently does something else. Also, can any Ruby gurus suggest a way to bake this into the Ruby syntax?

AjaxPatterns, BlueDot

The philosphy behind the Lazy Registration pattern is well depicted in this TechCrunch description of BlueDot.

The key is that Blue Dot is useful to readers immediately without registering for an account. Readers who click on the Blue Dot link to save an article on a partner site see a small pop up box from which they are able to send that article by email to anyone. The article is saved in an account automatically created for them without registering for Blue Dot. A cookie on the browser associates the user with that account and an email is sent to introduce Blue Dot’s full feature set and direct them back to the Blue Dot site to read friends’ comments about the emailed item.

Agile, Configuration, EJB, XML

Dion posted a story about Nokia's new mobile widgets. This will be very cool if it's as good as it sounds. However, what got me was the XML-based config - three separate files for config, skin, and widgets. The widget config:

My comment here isn't specifically about this project, because most APIs continue to use this convention. I don't get why APIs continue to come out requiring complex EJB-style XML config, in three different files no less. Learn from Rails and Pico and use code for config.

The arguments for XML config are fundamentally flawed:

• "Anyone can edit it, not just programmers". And if you believe that, you're still waiting for your manager to learn FORTRAN and COBOL, thus rendering programmers obsolete. Mwuhahah. Obselete, I'll tells ya.
• "It can be changed at runtime, no compilation required." This might occasionally be useful if the app's shipped off to another site, but that's a slim minority - it will either be a hosted app which you can easily re-deploy after re-compiling (as with these widgets) or a desktop app which will hopefully offer a nice config UI rather than requiring the user to hack some XML files! We like to develop standards to serve the vast majority, not the slim minority.
• "It's neater." In any modern language, you can easily develop an API that lets you perform configuration with a grammar resembling a domain-specific language. I don't consider the above XML to be particularly neat, nor most EJB descriptors I've come across.
• "It can be validated." True, you can check the file's grammar, but you can't validate that a given attribute must be a class in your program, for instance. With code-based config, you can.