Tuesday, February 27, 2007

JRDF 0.4.1 and GUI 0.3.1 Released

JRDF 0.4.1 and the GUI are now available.

The main things changes from the last release:
  • Initial SPARQL support that's been available in the JRDF GUI.
  • RDF/XML writer.
  • Push and pull RDF NTriples parser. In the future an RDF pull parser will also implement the RDFEventReader interface (which is similar to the StAX XMLEventReader).
  • Allows sorted results from a graph find() to be returned.

SVG Support

Recently, Adobe announced the End Of Life (EOL) for their SVG plugin (the way that most people view SVG). And more importantly, the plugin is not certified to be installed on Vista.

From what I can tell that's because of their acquisition of Macromedia and Flash:

The bomb, though expected by the people in the know, was Adobe's discontinuation of its SVG viewer plug-in, the dominant SVG viewer. It was the way to show SVG in any browser (which for most users means the Internet Explorer browser), and though as Adobe had paid good money to buy Flash, the terms struck everyone as stunningly harsh, if not directly hostile to SVG: By the first announcement the plug-in would be gone and unavailable by the end of this year. Later Adobe relented giving the plug-in, a longer lease of life, you can download the unsupported plus-in next year too. This was obviously taken as bad news, but personally I think this is advantageous in the long run, much like when AOL Netscape ceased ownership of Mozilla. This was commonly seen as the end of Mozilla, but I thought it was more likely to be the beginning and was proven right. Sugar daddies are only advantageous to a point. Worse than the loss of ASV is that authoring products like Illustrator are unlikely to provide useful SVG support.

For cross browser rendering of SVG (or something SVG like) some alternatives include:

Monday, February 26, 2007

You Had Me at Hello

iPhone advert

Patterns In Software - Part 3

Patterns of Software: Tales from the Software Community (freely available in PDF). I was going to talk about, "The Failure of Pattern Languages" but I thought that a little discussion on the preceding chapter, "Pattern Languages", is required. This is somewhat of a generalisation of the preceding chapters and a discussion on Alexandar's "A Pattern Language", which offered the template for the software pattern books.

A comparison is made between art and science - art is creation, science is description - and that there are few activities that combine both. The exceptions given are computer science and architecture (I'd suggest maybe biological science is another). Trying to avoid the separation of construction and design is a mistake in computer science. Much or almost all of computer science is design and that it is expensive because it does combine both aspects for example, "What is Software Design?".

So this is specifically what all the discussion was a few years ago about TDD - being Test Driven Design (not Development). And the focus on behaviour rather than testing, for example Tom's recent Instinct project.

I want to set the stage for the accepted view of how architecture is done, at least in the pre-Alexander world. Architects are hired to solve the problem of how to construct a building or buildings that meet certain constraints as specified by the future inhabitants or people in a position to specify what those inhabitants will need. The architect generally interviews those future inhabitants, studies the site, refers to the local building code, observes neighboring buildings, considers the building materials and construction protocols in the area, and then is inspired, in the manner of all artists, to create a set of drawings which a general contractor, in occasional conference with the architect, reduces to a physical object.

Following from the suggestion given in the book, that the inhabitants are the programmers, it's obvious that "software architects" should ask the inhabitants of the software the best way to solve their problems. But that's not enough, more often than not they dictate solutions without knowledge of any of the complexity that their "solutions" might bring. This aligns with Alexander's suggestion for architects.

The first of Alexander’s contributions to architecture was to reject the separate architect and builder model and to posit user-centered design—in which users (inhabitants) design their own buildings—and the architect-builder who would blend the activities of design and construction. This was viewed by architects as high treason enough, let alone the curious quest for an elusive quality that Alexander cannot name.

The mechanism he proposed to accomplish his new model was the pattern language. A pattern language is a set of patterns used by a process to generate artifacts. These artifacts can be considered complexes of patterns. Each pattern is a kind of rule that states a problem to be solved and a solution to that problem.

I recently started to read a copy of "A Pattern Language" and I was struck by the same thing that Gabriel was, especially in comparison with the GoF book:

One thing that strikes many readers of the pattern language is the degree to which Alexander talks about people and their activities in the patterns — the patterns are a response to his arguments about how life is best lived. Because of this, many regard "A Pattern Language" as a manual of how to live and how physical surroundings can support and enhance living.

The patterns discussed in Alexander's book are all about what makes an area good for people - side walks (foot paths), water features, stairs, the height of crossings, making a city accessible to bicycle and foot traffic, etc - all these things make the environment livable and most ideas are supported by empirical evidence. The world of software patterns, by comparison, seems much more barren and arbitrary.

So there are some obviously good things about patterns:

Patterns seem to be a partial solution to the over abstraction problem I talked about in “Abstraction Descant.” They are a way to take advantage of common patterns without building costly, confusing, and unnecessary abstractions when the goal is merely to write something understandable. That is, when there are more idioms to use, using them is far better than inventing a new vocabulary.

Patterns in software are a good idea, but I have rarely seen the attention to the human side—to living within software—that I see in Alexander’s patterns. One architect commented on Alexander that he regarded the patterns as providing information, sort of heuristics, about architecture, and I have to admit the patterns I’ve seen about software do that—they provide information that the software practitioner just plain ought to know.

But this also highlights one of the problems with patterns. They discuss the context of the solution to a problem without first defining and more closely examining the problem itself, especially in a more general way. While it's often discussed in this chapter that patterns interact with other patterns and that they must be free of "systematic variations" the problems themselves don't seem to require this property. When people are critical of patterns, this is what I think they are objecting to, rather than the patterns themselves. He quotes Alexander saying: "You see that the patterns are very much alive and evolving."

And in a foreshadowing of what's to come:

The worst thing is this: Alexander had the chance in the 1970s to try out his pattern language. He observed the results of others trying it out and he even tried it out himself several times. And guess what: It didn’t work.

The next chapter, "The Failure of Pattern Languages", discusses the failure to apply these pattern but also a proposed solution to the problem: that the process should also have "the quality without a name".

Tuesday, February 20, 2007

Ruby Interfaces and Design By Contract

Interfaces in Ruby (attempted summary)

Technically speaking Ruby does not need interfaces since it is dynamically typed. Any argument list that at least satisfies the arity condition can be handed into a method.

Since people appreciate the usage of interfaces and even more Design by Contract (DbC) some mechanics were developed that mimic interfaces and certain aspects of DbC. I list them in order of increasing complexity.

(1) Document which methods a method argument must implement or its expected type.

(2) Define a module containing the methods that all raise an exception like this:

module FooInterface
def bar(a,b) raise "bar(a,b) must be overridden"; end

class FooClass
include FooInterface

def bar(a,b) a+b; end

(3) Create a framework (like the one Paul Brannan suggested here [1]) for defining interface methods and for checking that a particular instance implements these methods.

(4) Try to support even more of DbC by dealing with preconditions and postconditions like I tried in [2].

Recently announced 0.1 version of Ruby Design by Contract and Java style interfaces for ruby.

Stone Soup

I was looking at "Unnatural postscript hacks" (which points to the original 1988 version of the postscript ray tracer) where various crazy hacks exist including one of the Mandelbrot Set with a familiar quote about the difficulty of simplicity.

A co-worker said that the image rendered reminded him of the Buddha (turn the output to portrait and see what he means). So I explained what it was, a bit about complex systems, fractals, the length of a coastline, Lorenz attractors, etc and that reminded me of Fractint which I played with ages ago and I was surprise to see that it is still maintained. It was written by the "Stone Soup Group" which I vaguely remembered was a fable.

Sure enough, Stone Soup is on Wikipedia and C2 Wiki and it's often used as a metaphor for some aspects of open source software. Which raises the question of deception:

The villagers deceive the soldiers (OK - they lie to them), and that's bad. The soldiers deceive the villagers (tricking them to bring out the hidden food) and everyone benefits - the soldiers get to eat, but so do the villagers (in the version I know, the villagers hide their food not just from the soldiers but also from themselves). So, at a deeper level, the story raises questions of morality. When is deception acceptable? What gives anyone the authority to claim to have 'the big picture?'

I doubt that the villagers are hiding a shared collection of food. If they were, when each of them were getting items for the soup you'd think they'd see other villagers getting other items and discover what the visitors were up to. If the villagers are individually hoarding the food then it makes more sense that they are unaware that by working together they could produce a meal. In this version, the villages aren't being deceptive and the visitors are allowing them to work together to produce something they couldn't otherwise.

Thursday, February 15, 2007

To Coin a Word

Tony makes Reddit again with a familiar term, Refunctoring.

Why ‘Refunctoring’? First, I refuse to reuse euphemistic terms that have served only to denigrate the standard of the software development industry, therefore, I cannot use ‘Refactoring’ (oooh! did I just say that!!?). To show this, consider the fact that the entire notion of ‘Refactoring’ is done away with one simple phrase ‘Functional Programming’ in the case shown and hundreds more. Of course, you might decide to redefine Refactoring to a different context, but then, redefining terms often leads to confusion (the term ‘function’ is itself a perfect example). To further demonstrate this point, open the book or catalog on Refactoring and turn to the section titled, ‘Replace Parameter with Method’. Then say out loud, ‘partial application’ — if you don’t know why you’re saying that, learn what partial application is, then perhaps it might dawn on you.

Anyway, Refunctoring is what most people really are doing. They are converting their code that is written in not-too-powerful programming languages to mimic the power that is already available in functional programming languages. They are representing higher-order functions with (importantly co-variant) polymorphic type parameters, refactoring out what partial application already provides and much more. This is being done, despite having been invented many, many years ago, but the fact that it is being done mandates a name, albeit how absurd it might be. I use the term Refunctoring, for no other reason than it was suggested to me by a bemused colleague (you know who you are :) ) one day and upon reflection, I have decided that it is entirely appropriate.

You don’t think the map function is a special case do you?

It's good to be known as bemused.

All Annotations

JSR-311: a Java API for RESTful Web Services?

I am still not so sure what they want to do exactly, but it seems to be based on JRA which has annotations of the form:

public List getCustomers();

For me a more interesting JSR would be one that would standardise the @rdf annotations the way so(m)mer is doing it.

The RESTlet framework was created because:

"I noted the lack of a REST framework in Java. The only project that came close to it was 1060 NetKernel developed by 1060 Research but it had too many features for my needs and I found that the mapping of REST concepts was not as direct as I was expecting."

It seems that annotations are an exceedingly useful tool, especially having used Elmo's annotations of interfaces to generate beans from RDF (link to PDF documentation). Annotating interfaces rather than classes, seems to be the way to go, given that interfaces can represent relationships like multiple inheritance. Elmo was inspired by subject oriented programming that provides a way "to group common behaviours and separate these different roles into unique interfaces and reusable classes." It's especially useful for unplanned extensions (through composition).

Googling for the various projects brought up, Tripresso looking at mapping RDF to OO (including Java, Ruby, Python and PHP projects). If object to relational mapping is the Vietnam of computer science, I wonder what object to RDF mapping is.

See the previous discussion, RDF on Rails ( mentioning ActiveRDF, RdfReactor, etc) and Henry Story's original, Java Annotations & the Semantic Web.

Wednesday, February 14, 2007

Behind Blue Links

Sunday, February 11, 2007

The Death of Applets and AJAX

Hybridizing Java

So here’s my question. Allow for a moment the possibility that, after 10 years, Java is not going to take over the world of RIAs. Further allow that Ajax is just “how JavaScript was supposed to work in the first place,” but that the limitations imposed by browsers, HTML and CSS committees seem unlikely to let it expand beyond its current bounds. What are we going to use to build RIAs?

And the answer is?

The only obvious solution is Flash. Flash has always been all about cross-platform multimedia experiences and user interfaces. People are very familiar and comfortable with Flash, and it is installed on almost all machines in the world. It’s trusted, stable and reliable.

Do we just forget every 10 years what's going on, does anyone remember Flash Generator from 1998? And I still remember the horrible, inconsistent Flash UIs from that era. Has anything changed with Flex?

Via, Bruce Eckel: Use Flex as the UI for Java Applications

Saturday, February 10, 2007

Why I May Never be Good at Scripting

In an effort to highlight my extreme ignorance I'll point out a recent bug I raised in the excellent Mochikit framework. In the end I came to the conclusion that Javascript libraries, while they can handle a great deal of incompatibilities between browsers, can't do it all.

I wrote the following Javascript:listMin([10,9,8,7,]);

This finds the minimum value in the list. In IE the result is undefined, in Firefox it is 7 and in Safari it's a syntax error. As I've found out, an array in Javascript as written above does a different thing in Firefox (an array containing 10, 9, 8, 7), IE (an array containing 10, 9, 8, 7, null) and Safari (syntax error). Checking this code against the specification (using something like JSLint) shows that the above code is really a syntax error (the extra comma after 7).

Part of the problem is that when comparing values in Mochikit a null or undefined is less than any other value. My expectation is either an exception or trying to make all browsers work the same way (not possible in Safari of course).

Now the result of these arrays were being passed around, in a functional way (which is part of why I liked Mochikit), and a more typical example is the second one given in the bug report:
map(function(x) {
if (!isUndefined(x)) return x[0];
}, [[10,10],[9,9],[8,8],[7,7],]).length;

Again, IE is creating an extra null object and returns 5 and it returns 4 in Firefox. The actual code using this was getting an exception in IE but not in Firefox because it was trying to treat a null object like an Array.

This is perhaps an example too, where functional passing style was more difficult to debug than if it was in a loop. But then you'd expect arrays to work the same (or at least I did) and that types are maintained (null not being an Array).

Now I'm generating code and allowing commas after each element in a list is a pretty familiar concept in heaps of languages. I can see why Firefox allowed this behaviour. I can also understand Safari following the specification. IE's behaviour though, doesn't make sense to me at all. It seems to have been purposefully created to cause problems.

All of this conspired to take many hours trying to debug code from a very lower level in several libraries, all the way back up to the highest where the arrays were being created.

A good API prevents these kinds of things from being processed - fail fast. I like Safari's behaviour the most - it would've saved me the most time (of course I was on a Windows machine so no help there).

Friday, February 09, 2007

Compliance Pays

Washington's $8 Billion Shadow "Another failed effort involves the F.B.I., which paid SAIC $124 million to bring the bureau, whose computer systems are among the most primitive in American law enforcement, into at least the late 20th century. The lack of information-sharing is one reason why the F.B.I. failed to realize that in the year leading up to 9/11 two of the future hijackers—including one with known "jihadist connections"—were actually living in the San Diego home of an F.B.I. informant. SAIC set to work on a system called the Virtual Case File. V.C.F. was supposed to become a central repository of data (wiretap transcripts, criminal records, financial transactions) from which all F.B.I. agents could draw. Three years and a million lines of garbled computer code later, V.C.F. has been written off by a global publication for technology professionals as "the most highly publicized software failure in history." The failure was due in part to the bureau's ever shifting directives, which points up the perverse nature of government-by-contract. When the government makes unrealistic demands, the contractors go along anyway: they are being paid not to resist but to comply."

Saturday, February 03, 2007

Relational SPARQL?

ARQ : what next? "What next? This release matches the published DAWG working draft but the working group is considering a SPARQL algebra the formalization of the semantic of SPARQL to be based on some like the relational algebra."

Friday, February 02, 2007

Within Specification

The definition of quality is that it meets a certain specification. What a bunch of bollocks! I have a Holden Vectra (a rebadged Opel which people say is a very bad brand in its own country, Germany) - it requires more oil (about 1 litre) every 3,000-4,000 kilometer ever since I've bought it. It has only done 30,000 kilometers in 3 years but in that time it's run out of oil 4 times (between services). Now I ring up Holden support and say that this is an unacceptable specification. They say the car is fine, it is within the oil consumption specification.

Quality is excellence and that's not Holden.

Update: So here's a bit more, based on what Matthew wrote in the comments.

So the quality of the specification comes out of a process. And if that process doesn't have "the quality of excellence" in it, at all levels, then you're not achieving quality yet.

One of these aspects to this quality is a sort of self similarity - like well designed code - each bit of code does a small bit and does it in an understandable way and is roughly the same as the other bits - independent of which level of the system you're at.

If you can't raise an "IT Strategy Defect" then your organizational processes (which your lower processes are a part of) lack that aspect of quality. Now maybe that has to come out of high costs, failed projects or whatever.

From the perspective of the software industry, it seems that we've got a much higher expectation on what can be done. There aren't that many industries where the customer, project manager, support, maintenance, engineer, tester, etc. are even able to say (let alone expected or encouraged) "there's something wrong, fix it".

The guy at Holden support says, "I wouldn't buy a car with those specs" and so on - they know it sucks but they can't change it.

Now that isn't to say software should produce the equivalent of bubble domed cars that play "La Cucaracha". I'd like a flying car but at the moment I'd settle for something that doesn't need to be checked every 3,000 km and isn't going to destroy the planet.

Thursday, February 01, 2007

Need for Speed

Bosworth On Why AJAX Failed, Then Succeeded links to which isn't the first time he has examined AJAX's success and failures or why other technologies fail such as RDF. Some commentary was interesting in the comments and a few blogs, including this summary:

All in all the speaker (intentionally) kept his talk simple and stupid but here are some points I think are worth noting:
  • Products fail because of [lack of] human psychology not poor engineering
  • Top 3 keypoints of UI:
    1. Speed
    2. Speed
    3. Speed
  • Your app should be a tool, it shouldn't leave the user feeling like one
  • Search isn't perfect but it is far better than any human can do so it is tolerable.
  • Analyze the frequency of use of feature and implement those first
  • If your app takes more than 2 seconds to load - forget about it
  • The Motorola RAZR was cool enough so the poor UI (narrow keypad) didnt matter