Bill de hÓra

Finished reading the Prags new C# testing book yesterday. It's very good.

I found it easy to read. They say it's designed for onscreen reading, and it is if you use Acrobat Reader 6. Then it's very readable (5 blew goats, so I upgraded). The type face is a serif*, and it ascendent and descendent strokes are quite narrow, but that's ok. They contrast strongly enough with the background. The code samples have pretty colours, and are in a very readable tiny-text. Overall, the book looks good online. No need to buy a print copy.

* Yes, everyone does this, but please, consider using a sans-serif font onscreen. PDF sans serif looks really good since I upgraded the reader.

Posted by Bill de hÓra at 12:23 AM | Permalink | Comments (1) | TrackBacks (0)

Le Big Maque:

Really should get one, someday.

Posted by Bill de hÓra at 12:17 AM | Permalink | Comments (0) | TrackBacks (0)

Posted by Bill de hÓra at 11:01 PM | Permalink | Comments (3) | TrackBacks (0)

Robert Sayre commented on my WS stack:

Seriously, why is RDF in there?

RDF is in there, because I know people are using it, but aren't talking about it so much (it's a bit like the problem JXTA/Jini has).

At the moment, RDF works well for "normalizing" content across administrations - in English, creating shareable keys. For example we use RDF:

1. to help manage reliable delivery over HTTP - each message exchange is assigned a URI and we can make assertions about the delivery state as RDF. As well as that all the messages have their own IDs which are linked to the exchange URI. This is proving extremely useful for tracking.
2. In a pubsub system to log messages. In this system subscribers have the the option to receive batchs of enveloped messages, wrapped in a envelope - this helps them manage their downloads. Each individual message has an identity, but when one gets swallowed inside a batch it would "vanish" from the audit trail. To track where messages went we used RDF assertions about containership.
3. I haven't done this yet, but I'm very, very close to writing an RDF n-triples appender for log4j. I have a bunch of components that have identity and I would love to be able to log their activity as RDF instead of eyeballing and grepping through "[time][name][event]" traces to build what is essentially a call graph. If anyone has done this, give me a shout.

I think the problem with "seeing" RDF being used, aside from obvious issues like syntax are:

1. the lack of a query language that will work outside someone's toolkit or product (tho' RDQL would be my choice right now). At the moment most RDF seems to be about data capture. The W3C are at requirements stage on this, but I'm hoping they don't go off the deep end as happened with the RDF-MT and XQuery.
2. the fact that most people still are not identifying things in way that can live outside the scope of a single database or filesystem. Everybody is declaring property-value pairs of some kind, but not enough people are using shareable keys identifying the thing the property-value applies to. We're either using pure context (filenames, root elements) or auto incrementing primary keys. The point is we are already identifying things, but not as usefully as we could be.
3. Uninformed press. I don't see RDF used so much for designing vocabularies or ontological work - the use-cases which seem to get the most press. Certainly that's not what I'm using it for. I've never written an RDF schema for production use.

So for me, RDF is part of the stack. My RDF needs are relatively low level (think operations, systems management) compared to most of the talk around RDF (ontology, content management). It can be summed up as follows - "what is it, where is it?". "Why is it, how is it" isn't on the radar yet. When you use RDF this way, it proves to be cheap and cost-effective - no agonizing about models, no pollution of your XML vocabularies. Just useful data.

Posted by Bill de hÓra at 11:43 AM | Permalink | Comments (4) | TrackBacks (4)

Tim Bray joins the party:

I think somebody needs to stand up and start waving a flag that's labeled 'WS-Simplification' or 'Real Web Services' or something, that's all about building applications with what's here today and what works today: XML, HTTP, URIs, SOAP, WSDL*, and that's about it.

People already are. Mark Baker, Sean McGrath, Paul Prescod, Don Box, even myself, have been pointing this out in one way or another for some time. Mark Baker in particular took a lot of stick for not being on message with WS orthodoxy. Paul Prescod was disembowelling SOAP-RPC and UDDI two years ago. It's a pity the W3C's TAG hasn't been the group taking the leadership role and waving that flag.

Almost everything you need to do in this space, well someone is probably already doing it with a combination of SMTP, HTTP, FTP, RDF, URI, MIME, XML. That's the WS stack. Perhaps Atom/RSS will enter that set.

* I have my doubts about WSDL/SOAP - good for demos tho'. I'm probably being unfair at this stage, but SOAP/WSDL to me is tainted with all that RPC, WXS, protocol neutrality, and by Infoset weasel wording. Some of the WSDL-driven tools are very cool, but cool does not a system make.

Posted by Bill de hÓra at 11:50 PM | Permalink | Comments (6) | TrackBacks (2)

Eric Sink is forgiven for writing life support for VSS:

The bulk of their time should be spent writing code and fixing bugs. But every developer also needs to be involved in other areas such as the following:

* Spec documents
* Configuration management
* Code reviews
* Testing
* Automated tests
* Documentation
* Solving tough customer problems

Using my terminology, these things are the difference between a programmer and a developer. The developer has a much larger perspective and an ability to see the bigger picture. The programmer writes code, throws it over the wall to the testers and waits for them to log bugs. The developer knows it is better to find an [sic] fix bugs now, since he just might be the one talking to the customer about it later.

[via Erik]

Posted by Bill de hÓra at 12:04 AM | Permalink | Comments (0) | TrackBacks (0)

Update: installing acrobat reader 6 made the book read just fine - couldn't get any joy from reader 5.

Been reading the Prags new C# testing book. It's very good.

But I'm finding it hard to read. They say it's designed for onscreen reading, but it's not. The type face is a serif*, and it ascendent and descendent strokes are too narrow. They appear gray and don't contrast strongly enough with the background (possibly this font was anti-aliased). The code samples have pretty colours, but are in tiny-text. Overall, the book looks slightly like a fax. I'll be buying a print copy next time.

Sorry trees.

Yes, everyone does this, but please, consider using a sans-serif font onscreen.

Posted by Bill de hÓra at 09:36 PM | Permalink | Comments (3) | TrackBacks (0)

Tabs versus Spaces: the tab is a presentation macro, not a character - the fact that some bearded idiot made it an ascii character is an unfortunate decision we're stuck with. If you're too young to know what ascii is, tab is a bit like the bold or font tag in HTML - also unfortunate decisions. Tab characters don't belong it source code, ever - only idiots put tabs in source code. Map the tab key to multiple whitespaces instead - I don't care how you do it, just get it done. No, I don't care what you do with bold tags in HTML. No. No. No.

;)

Posted by Bill de hÓra at 10:07 PM | Permalink | Comments (15) | TrackBacks (0)

Darren Hobbs thinks about using using SMTP and NNTP for messaging.

I'll have what's he's having. I think XMLPP (Jabber) might be an option for pubsub.

Posted by Bill de hÓra at 09:28 PM | Permalink | Comments (5) | TrackBacks (1)

Be all that you can be.

Posted by Bill de hÓra at 09:22 PM | Permalink | Comments (0) | TrackBacks (0)

Endless hours of fun.

Now, for the horror themepark remix: open these in new windows.

Posted by Bill de hÓra at 09:19 PM | Permalink | Comments (0) | TrackBacks (0)

I've enjoyed reading Dan Creswell's Weblog over the last few weeks. I hope Jini folks are following it.

Posted by Bill de hÓra at 12:59 PM | Permalink | Comments (0) | TrackBacks (0)

The Margaret Thatcher Illusion: Now I know why people start to look creepy upside down, if you look at them long enough...

Ahem. But if you tilt your neck slowly the face will flip from normal to freakish. Minutes of endless fun, right there.

Posted by Bill de hÓra at 01:24 AM | Permalink | Comments (1) | TrackBacks (1)

...there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

Enough already, we all know that bit. Now, here's the rest of it, which most no-one quotes:

The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature. It also requires a willingness to accept objectives which are limited by physical, logical, and technological constraints, and to accept a compromise when conflicting objectives cannot be met. No committee will ever do this until it is too late.

Posted by Bill de hÓra at 12:04 AM | Permalink | Comments (0) | TrackBacks (0)

Which Princess Bride Character are You?
this quiz was made by mysti

Posted by Bill de hÓra at 08:16 PM | Permalink | Comments (1) | TrackBacks (0)

So, what could be simpler than looping through an array of integers in C#? Which way would you do the loop?

   1. foreach (int i in foo) {}
   2. for (int i = 0; i < foo.Length; i++) {}
   3. int len = foo.Length; for (int i = 0; i < len; i++) {}

[...excellent analysis...]

- Joshua Allen

Maybe this is stupid... but doesn't the problem go away when there is only one way?

Posted by Bill de hÓra at 03:19 PM | Permalink | Comments (8) | TrackBacks (0)

"XML is like Cardboard [...] I thought that this was a great analogue. Pity he did not try to think of one for XML schemas..."

Just kidding!

Posted by Bill de hÓra at 01:32 PM | Permalink | Comments (1) | TrackBacks (0)

[From the It Takes Ages To Get A Taxi Via IM Department]

A colleague of mine next to me is currently handling half a dozen IM conversations, but he's topping out. I guess his attention span is being slashdotted but in IM. SpanDotted, or maybe the SpanDot Effect. Email would be easier at this point, assuming he could find the email amidst the spam haystack of his inbox. The lesson? Synchronous systems are nicely interactive but don't scale; aynschronous ones scale, but are overrun with spam. Or something like that.

Posted by Bill de hÓra at 11:41 AM | Permalink | Comments (0) | TrackBacks (0)

Damn, I love XML over HTTP.

There's a twisty maze of conversation around an entry from Dan Creswell that was picked up by Dale Asberry. Dale:

I think the discussion is pointing out some very big reasons why Jini isn't taking off: people don't get distributed computing. They just don't get it.

Dale again:

Never claimed that there were any magic bullets. Only that distributed application design isn't really as hard as most people think [..].

So it's not that hard, but people don't get it. Ok, I guess they're not mutually inconsistent statements. But they don't explain much; it's not like Jini is the only distributed technology at hand. I would agree that distributed computing doesn't have to be as hard as people think, given the right technology. But I think people think right - with industry standard frameworks (DCOM, CORBA, J2EE, WS, CUPS) distributed computing is hard.

Todd Blanchard is close:

Probably the root cause of the unfortunate disconnect you bemoan is the modeling of services as objects. Objects have state (ivars). Services, ideally, don't. Objects without state are just bundles of functions - which is a much better model for a service than a class. I rather suspect that this is the source of much bad design - services are NOT best modeled as objects.

Services do have state, but they don't expose it, they accept it. Which Dale had pointed out:

This means to me that any state needed by a service will be included in the request either directly by including it as a request parameter, indirectly through a parameter containing a global reference, or implicitly through some asynchronous mechanism.

But then:

My practical solution to this is to perform remote method calls, or groups of calls, within a Jini transaction that also contains any and all JavaSpace entries representing service state. This buys me consistency in state for all distributed participants AND fault-tolerant fail-over for when a service becomes unavailable.

Aka a transactional blackboard. Which is maybe about as well as you can do for object invocations. In all this discussion, it seems objects are an artefact of Java, not the nature of distribution. Nonetheless, if we were doing Java middleware over tommorrow, Jini/JXTA would be where to start, not J2EE.

You see, when it comes to distributed computing, I think all object oriention does is obscure matters. We end up talking about transactions, parameters, references, interfaces, when we should be talking about messages, state, names, protocols. And if that doesn't fit with object thinking, so much the worse for it - distribution and decentralization is becoming the norm.

But object wonks might object because that separates behaviour from data - bad, bad, bad. Which is what Todd is talking about when he says objects are not a good model for services. I've yet to me a J2EE advocate who didn't see DTOs and the like as essentially latency optimization/workaround instead of proper network design (DTOs being degenerate messages) [utter bunk, sorry about that...]. I even see object advocates today insinuating that a service layer is some kind of dirty hack.

I haven't even talked about how you're supposed to manage or integrate the arbitrary interface signatures an object model allows. Or versioning. And I'm not going to either.

I don't know. I just wouldn't start with an object model and then figure out how to negotiate their consistent state once I'd flung them around the network. I'd look for an application protocol that fitted my needs. The closest I'd get to an object model is a generative or associative model (a la JavaSpaces, or content based routers). But for that I don't need objects in the design - I need data tuples.

[calexico: whipping the horse's eyes]

Posted by Bill de hÓra at 01:11 AM | Permalink | Comments (4) | TrackBacks (1)

Asked on David Boxenhorn's blog:

Amritas: What kind of name is Bill de hÓra?

Not sure. O'Hora is probably the same name.

Update: not much in a name, or so I thought. Ladies and Gentlemen, I give you Jon Hanna:

- It clearly seems to be an Anglo-Norman name given the "de". However the "de" was an 18th century variation on the name ("de Hore" and "de Hora", later still "de Hora" was Gaelicised into "de hÓra"). Earlier variations include "le Hore", "la Hore", "le Horhe" and "the Hore".

The "de" invention was done with some knowledge of genealogy though, for the name is indeed Norman. The earliest example of the name in Ireland traditionally being Phillipe le Hore, who was one of Strongbow's men.

However some of those names also came to Ireland as Cromwellian officers or adventurers, the Co. Cork line in particular are more likely to be descendents of later arrivals to the country.

"O'Hora is probably the same name"

- Probably not. The O'Horas are related to the Haras, Harras, Ó Haras and O'Haras. Of course given the similarity of the names and the relative frequency with which we alter our surnames here it's likely that some O'Horas are really from the le Hore/la Hore/le Horhe/the Hore/de Hore/de Hora/de hÓra line and some de hÓras are really from the Haras/Harras/Ó Haras/O'Haras line.

"Northern Ireland, where the Normans (with a huge French influence) "colonised"."

- The Normans colonised throughout the island. Northern Ireland doesn't really become differentiated in terms of where one can trace one's ancestors to until the Ulster Plantation under Elizabeth I when Scottish Protestants were imported in great numbers. Ironically the motivation for this was that at the time Ulster was the province with the least loyalty to the English Crown. Today Ulster-Scots names (like mine) are found throughout the island.

"Why is the Ó cApitalized?"

- Irish orthography distinguishes between letters that are always part of a word and letters that are part of a word mutating depending on how it's used. The word is being written as if it were an irish word "Óra" which is mutated when following "de" to "de hÓra" (in all lower-case it would be "de h-óra", and if one were using a Gaelic like those at http://www.evertype.com/celtscript/csmain.html then it would be "de h-Óra" in that case as well).

The distinction can be significant, "ár nAthair" means "our Father", "ár Nathair" means "our Snake", the lower-case difference between "ár n-athair" and "ár nathair" making this a bit clearer.

In this case though it is a deliberate Gaelicisation of de Hóra in this case, rather than the effects of an Irish etymology.

"you will see buttons for adding letters with fadas. They are not capitalized"

They don't need to be given that it's the UI of a case-insensitive search. Irish never adopted the practice of omitting diacriticals on capitals to cope with technical limitations like the French did (and this became the normal French orthography, though diacriticals on capitals are making a tentative comeback). However Irish did completely lose the dot on some consonants, replacing it with a following h (hence the name Saḋḃ became Sadhbh, and so on).

I'm speechless.

Posted by Bill de hÓra at 12:17 AM | Permalink | Comments (10) | TrackBacks (1)

I do hope folks realize that when RDF goes mainstream, lock-in via rules engines will be the order of the day.

Norm Walsh is working out negation: Not in RDF. Go and look at it, the example is cool. But it could have been better titled "Using cwm rules to express not". [Which is not as snappy and I'm such a pedant. But I want to scream every time I see cwm/N3 conflated with RDF.]

[beastie boys: sabotage]

Posted by Bill de hÓra at 09:02 PM | Permalink | Comments (1) | TrackBacks (1)

There are a few things in life I have done that are or were remotely like building software systems:

1. Gardening.
2. Farming.
3. Oil painting.
4. Cooking.
5. Raising children.

This is counter to much orthodox thinking, and that is troubling. To be honest it's not what I expected starting out. Nor are these stock for juicy metaphors. I appreciate that the current metaphors have much more cachet - try going into a boardroom are describe what you're going to be to doing as gardening rather than architecting.

But, the disciplines we look to for metaphorical inspiration are racing headlong to become 'soft', to transcend their physical limitations. As Ralph Johnston pointed out, there are real difficulties in altering a bridge or any physical thing after its been made - theoretically no such difficulties exist in software. Many of them use computers and buy our software just for that purpose, most notably for simulation, and they are I think dissatisfied with our ability to give them the softness they want. Whereas we seem to be desperately hungry for a physics, any kind of hardness. It's the oddest thing.

Programming seems problematic, because it seems impossible to control. So - more process, more architecture, more tools, in the hope someday that programming will simply disappear in a puff of abstract modelling. I've talked about demonizing programming before as being a bad idea. It's like a physicist hating physics because he sees wave functions everywhere, and wills them into particles by writing down equations. Maybe that's not good architecture thinking in some people's books - sorry but I can't begin to talk about software architecture without taking programming and development into consideration. I don't think there's any getting away from practice.

Posted by Bill de hÓra at 06:08 PM | Permalink | Comments (1) | TrackBacks (0)

It is impossible to design a system so perfect that no one needs to be good - T.S. Eliot

I liked the first issue of the Journal. I liked the second one less. What bothered me is the lack of focus on implementation or engineering and almost total emphasis on abstract architecture. How do I execute? What do I build?

Over half the issue was dedicated to SOA, but I'm still none the wiser above what I already knew myself from building in that style. There's nothing to indicate how one would can create an SOA system. Perhaps it's just that my notion of proper automation and care in software is not informed by building houses, factory production, engineering bridges, or questionable abstractions. I believe the EMEA Journal has sound goals - make systems more valuable to business, perform a leadership role on Windows platforms; but the publication should consider mixing up some balance in its articles. Any one or two of these articles would be fine, but not all five. After five, the good ideas become vapourware.

Pat Helland's Metropolis is featured in the Journal and is the best of the bunch. This is a remarkable opus. I think it's probably the ultimate expression of software as Building, as the construction of an Architecture. It's the last word on the matter - you will not find a better essay on the subject. There are strong economic pressures to go and think this way. It's comforting to think that we are reaching some kind of critical inflection point of commodization, productization (perhaps most accurately, Walmartization) of software, when society and industry has spent and is spending such frightening amounts of capital on software. Nonetheless, to me the city is not a good metaphor for software, and never has been. Writing software has not felt like designing and building a house. Using software is not like using a house - a program is not a habitat. Changing software is not like demolition (if it is, you're in trouble). I've built houses, I've built SOAs, and the processes have nothing much to do with each other as far as I can see. The problems in software are down to complexity, expediency in engineeering and duplication much more than insufficient architecture. We can call making and thinking about software systems building and architecture if we want, but that's as far as it goes. I like organic and growth metaphors over physical construction or industrial ones - they ring true to me.

And yes, my business title is Technical Architect. But lets be careful about aggrandizing ourselves with direct comparisons to Architects in other disciplines. We are not architects or engineers like those folks are - they have a richer deeper background to draw from. The likes of Marcus Vitruvius, Bruneschelli or Thomas Slade don't exist in software. But - it doesn't matter what your process, technical and architectural leanings are. At some point, if you want a system that will do useful work and grow with your needs, you will need to find competent people to write the code.

• For an alternative view on what it might mean to be a software architect or think about software read Ralph Johnston or Luke Hohmann (or his interviews).
• For some facts on software process instead of blind faith read Robert Glass.
• To see what it might be like to live in software garden, rather than a city, read Ward Cunningham, Tim Berners Lee or Pete McBreen.
• To understand why programming is intimate to design, read Jack Reeves or Kent Beck.
• To appeciate technical leadership read Joel Spolsky or Martin Fowler.
• To find out what modern factory systems and supply chains really do and have been doing for the last twenty years read the Poppendiecks.
• To find out about Service Oriented from people who are instrumental in actually building them subscribe to Don Box or Sean McGrath.

That is kind of of material I would like to see mixed into the next issues of the Journal.

Posted by Bill de hÓra at 05:18 PM | Permalink | Comments (0) | TrackBacks (0)

I really don't understand why PHP, etc. dominates the free/cheap hosting solutions. Tomcat is a production class Servlet Container and JBoss easily holds it own against the commercial application servers. Then for database you can always choose MySql although personally I'd go for Postgres (this has the benefit of being similar to Oracle should the client want a transfer). - Mike Cogan

I'll take a stab. It's because Java/JVM wasn't designed with multi-user environments in mind. LAMP solutions leverage the (usually *NIX) operating system to manage user processes.

The JVM by comparison is a single user environment - code is running pretty much as root, which is what you'd expect given its use-case evolution (devices, websites, middleware). I think it would be too easy to hose a server running on a JVM if anyone could deploy code in it. My hosting provider emails me if I have more than two processes running for a period, that's fairly easy to do from the OS. Not so easy is to email me if I have more than two Java threads running or if I have deadlocked the JVM altogether. The (usually *NIX) operating systems have been doing this well for decades so that's entirely sensible to build on them. But Java only has the JVM, so you have to build all the user controls again from the ground up.

The alternative, to run multiple JVMs won't fly - memory gobbling plus you have to manage inter-JVM comms from the server to your Servlet and back again (Servlets are not designed for this, in fact, quite the opposite - their initial selling point was running them in the same process as the server). Tomcat, JBoss and friends (UCL? For multihoming? With that reputation? Are they quite mad?) strike me as too flaky for multiuser environments until the JDK ships with Isolates.

I'd love to know how the few Java hosting providers that do exist manage to keep things running at all.

Posted by Bill de hÓra at 05:16 PM | Permalink | Comments (13) | TrackBacks (1)

I've spent two days writing server admin scripts in Java to be run via Ant. I think the only way to do it and not go insane or build a YAFF is via Command objects. You get some measure of recomposition/reuse from your function chunks that way. Otherwise everything turns into single class hairball. Always split iteration from function. I despair that Java can't pass methods around. A little Java, a few Patterns is the best book on writing commands in Java - if you look at that and go "That's not Java", I don't blame you (tip: eat before you read it). Assuming the things you're dealing with have names, RDF makes for a kicking log/journal format. If they don't have names, give them some. The DOM: uurrghhhhh. The next time I do this I'm using Groovy. And XOM.

Posted by Bill de hÓra at 04:14 PM | Permalink | Comments (0) | TrackBacks (0)

Cool Firefox tips from Jon Udell: More Firefox search plugins

I once described Eclipse as a $40M port of Emacs to an IBMer - which didn't go down too well. But it occurs to me that Firefox with its plugin approach is not a dissimiliar way of manging things to Eclipse. Now, you can make deep alterations in Emacs, given its Lisp-fu nature. Powerful, but you might end up mortally wounded. The Eclipse/Moz approach to this seems to be different - don't muck with the core and make sure you don't have to by keeping it very small and manage extensibility via plugins. I think you can characterize that as more directing and structured than the Emacs approach.

I wonder if we're not compensating limited flexibility in the programming languages by building flexible and reflective containers instead, that you manage through a ConfigurationLanguage. And I think we're well aware by now that one way to tie someone into a container based on an open standard is through the ConfigurationLanguage. Perhaps we should ask if this the right road to go down - at what point does the kernel become an interpreter?

Maybe what we need is not a middleware container, but a middleware interpreter.

Which brings me onto micro-kernels and lightweight containers in Java. I wonder if there's any real difference between a deployment and a plug-in, and whether we can't compare containers to interpreters in that case. Here's a question. Which of the current crop of Java container/kernel architectures do you think supports the plugin model well?

Posted by Bill de hÓra at 03:37 PM | Permalink | Comments (1) | TrackBacks (0)

Found via Patrick Logan:

On time to market:

Whirlpool - they can finish a design and the R&D of a product, and it takes them a year to get the product on the market. You know what happens during that year? All the Koreans get to the market before them. Why? Because they copy their designs -they see them in a show, on the floor, and they copy them -and they have a three-month time to market.
Same thing happened to Philips. Philips invented all the key innovations in the consumer electronics space, and they always were three months behind Sony. Even on stuff they invented, DVDs, they came in after. Manage that time to change, and you become Dell. You don't manage it, you become dealt. - Shai Agassi

On optimization:

Always XML, because when I go outside my company, I don't know what's on the other side. Now, if the two of them can actually do a handshake and say, 'Hey, by the way, we can optimize this,' great. I don't believe that outside the company, optimization is so big. When I look outside, the big latency is network latency. Compressing, decompressing XML is not going to make a huge difference.
Inside the company, I can build a huge pipe between my business processes written in ABAP, which I can't change- it runs my business, it's been tested, I can't touch it-and my Java infrastructure so I can do my customization. That pipeline, which is getting crossed a hundred thousand times every second, can be optimized. Excellent- you gave me something that nobody else can do. That's what we can dig underneath our own town to do this. But when I go outside the company, or between divisions, there is no value in changing this. - Shai Agassi

Posted by Bill de hÓra at 02:39 PM | Permalink | Comments (0) | TrackBacks (0)

Anthony Eden has done some serious blogging on the MySQl Conference; well worth a look.

Posted by Bill de hÓra at 09:17 PM | Permalink | Comments (0) | TrackBacks (0)

Mark Baker has followed Mark Nottingham's list with one of his own, including Rohit Kahre's thesis (I knew I'd forgotten something - Must. Get. Better. Metadata). He also has an interesting take on Marshall Rose's RFC.

[calexico: pepita]

Posted by Bill de hÓra at 08:46 PM | Permalink | Comments (0) | TrackBacks (0)

XML 1.1 is an abomination. You don't need it and you shouldn't use it. - Elliote Rusty Harold

That'll make for a short book.

Posted by Bill de hÓra at 07:15 PM | Permalink | Comments (3) | TrackBacks (0)

Out my window, I see there is a clear blue sky, with hailstones crashing onto the yard. In April. Unbelievable.

Posted by Bill de hÓra at 05:51 PM | Permalink | Comments (1) | TrackBacks (0)

Inspired by recent discussion on dark v light page schemes, I decided to switch to a dark scheme for a while. Having everything in CSS is a godsend - the switch didn't take long. This place using to look a lot like this.

But - I'm upset at Miller and Brunning for having more tasteful schemes.

[calexico: crumble]

Posted by Bill de hÓra at 01:53 PM | Permalink | Comments (3) | TrackBacks (0)

In case I forget again:

    // xmlns:re="urn:foo"
    //  |    |    |
    //  |    |     -- getValue 'urn:foo'
    //  |    |
    //  |     -- getLocalName 're'
    //  |
    //  -- getPrefix 'xmlns'
    //
    //  |      |
    //  --------
    //    |
    //     -- getName 'xmlns:re'
    
    
    // xmlns="urn:foo"
    //  |    |    |
    //  |    |     -- getValue 'urn:foo'
    //  |    |
    //  |     -- getLocalName  null
    //  |
    //  -- getPrefix  null
    //
    //  |      |
    //  --------
    //    |
    //     -- getName  'xmlns'

The DOM: a stupid evil plot.

[calexico: guero canelo]

Posted by Bill de hÓra at 01:29 PM | Permalink | Comments (0) | TrackBacks (0)

XP rhetoric is characterized by broad and sweeping generalizations about software development practice, projects and developers. A classic example is the following, from Kent Beck:

Unacknowledged fear is the source of all software project failures [1]

It takes a special kind of person to make such claims - specifically, one that is breathtakingly arrogant. - Hacknot

I wonder. Does anyone think that Kent Beck's claim is arrogant? More importantly, does anyone think it's wrong?

Posted by Bill de hÓra at 11:48 AM | Permalink | Comments (6) | TrackBacks (0)

Bruce Schneiers Crypto-Gram RSS Feed.

Posted by Bill de hÓra at 10:13 AM | Permalink | Comments (0) | TrackBacks (0)

So. Here's a quote:

1. Processes have 'share nothing' semantics. This is obvious since they are imagined to run on physically separated machines.
2. Message passing is the only way to pass data between processes. Again since nothing is shared this is the only means possible to exchange data.
3. Isolation implies that message passing is asynchronous. If process communication is synchronous then a sodware error in the receiver of a message could indefinitely block the sender of the message destroying the property of isolation.
4. Since nothing is shared, everything necessary to perform a distributed computation must be copied. Since nothing is shared, and the only way to communicate between processes is by message passing, then we will never know if our messages arrive (remember we said that message passing is inherently unreliable.) The only way to know if a message has been correctly sent is to send a confirmation message back. - Joe Armstrong (Making reliable distributed systems in the presence of software errors) [pdf]

That greatly impressed me when I read it first. Not because of SOA or REST or any of that stuff. But because it's a quote about the archictectural constraints of a programming language - Erlang. It still impresses me - Joe Armstrong's PhD is a tour de force, required reading for those of us working on top of virtual machines and networks.

I've been following the discussion going on between Steve Loughran, Ted Neward and Patrick Logan regarding the granularity of the SOA model. The conversation has gotten around to Erlang:

Patrick Logan implies that the solution to having an SOA model inproc is Erlang. I shall have a look at this. I was debating looking at learning a new language, as I am finding Java dev too, slow, these days, even with a refactoring IDE. I was trying to decide between Python and Ruby though :) - Steve Loughran

I come firmly down on the inproc SOA side. I would find it hard to believe anyone could read Armstrong's thesis and decide that the message passing style is only for computing in the large. But we should be talking about interproc. mesage passing seems suitable for any system with interprocess communications that needs to be flexible, robust and scale. Joe Armstrong describes Erlang as a concurrent pure message passing language *, which sounds like some of the core constraints of an SOA, or at least a good start.

Java is getting there. Isolates (JSR-121) when they arrive (1.6), will offer some of the constraints needed to build decent inter-process systems on the JVM. Plus the sadly underused JavaSpaces has shown us how to really design a protocol/service oriented API. The Jini folks have been banging the services drum for years. There is also the E language, one the first languages built on the JVM. Finally the 1060 net kernel stuff is a REST/URI oriented approach and supplied as a jarfile.

* Which might be characterized as Smalltalk on steroids. There's a lot of confusion around what is meant by 'message passing' in Smalltalk. Conceptually I think Smalltalkers are talking about message queue type messaging and in some cases asynchrony, but physically I understand Smalltalk works like Java or C++, i.e. it's jumptables, and pointers all the way down. Hence the confusion, but I trust someone will correct me if I'm wrong about this.

Posted by Bill de hÓra at 04:05 PM | Permalink | Comments (4) | TrackBacks (0)

Monopolies are sacrifices of the many to the few. Where the power is in the few it is natural for them to sacrifice the many to their own partialities and corruptions. Where the power, as with us, is in the many not in the few, the danger can not be very great that the few will be thus favored. It is much more to be dreaded that the few will be unnecessarily sacrificed to the many. - Thomas Jefferson

Just so I've got this straight, let me read this back. I go to the store and pay $30 for a DVD and place it in a player. I don't modify the DVD, I simply play it back in a different way than it was placed on the DVD. The Director's Guild thinks I shouldn't be able to do that because I am messing with the "intent" of the director. I guess that the "random" button on my CD player ought to be illegal as well then since I'm clearly changing the intent of whoever laid out the tracks on the CD by playing them back in a different order. If this isn't about the clearest example of hubris then I don't know what is. - Phil Windley

Posted by Bill de hÓra at 03:44 PM | Permalink | Comments (0) | TrackBacks (0)

Not a WS spec in sight: Implementing "Bob's Listening To".

Posted by Bill de hÓra at 03:28 PM | Permalink | Comments (0) | TrackBacks (0)

A few folks have asked me how my home network is laid out. Here's the diagram as of yesterday:

The WiFi doesn't use WEP encryption, but does use MAC filtering. Maybe that's not too clever, but WEP is insecure as well as being slow, plus the link seems to be flaky when it's on. The SMC acts as a print server out of the box, which saves me having to set things up via SMB or whatnot (both servers are linux). The DMZ in gray isn't done yet, but I'd like to be able to log back in while not exposing the entire LAN (The Eircom plan I'm on is for dynamic IP, but there are ways around that). First tho' I need to harden the network.

Here's the kit:

• Netopia Cayman router (supplied by Eircom)
• SMC Barricade router (comes in wifi and non-wifi versions)
• 2 x SMC2835W 54Mbps cardbus adapters
• 1 x EZ Connect Turbo SMC2455W access point
• Crossover cable for the router link
• Patch cable for the servers
• 4 port switch

All in all, assuming you had the kit, it shouldn't take more than rainy morning to set things up. Most of that would be in installing wifi drivers on the laptops and running cable. Strictly speaking you don't need the switch as the barricade has four ports available. And if you go for the newer wifi Barricade you won't need the access point. All this stuff can be got at Komplett.

Previously I'd been unable to make the Cayman router supplied with Eircom ADSL work with my SMC Barricade. Turns out there were two problems. First I was telling the SMC to dial into the Cayman using PPOE instead of just taking an IP address from it. Second I wasn't using a crossover cable between the two (orange in the dia. above). That last one was a bit embarrassing. Rule no 1 of networking: always check your cable (thanks Hugh!).

This would be so cool: a Squeezebox running on the LAN.

Posted by Bill de hÓra at 03:17 PM | Permalink | Comments (0) | TrackBacks (0)

I completely agree with Tim O'Reilly's assessment of the privacy concerns around Google GMail. Mark Nottingham has made similar observations. It's a red herring, that can be dispelled by explaining how email works. What I wanted to pick up was an almost casual observation Tim made on data migration:

The big question to me isn't privacy, or control over software APIs, it's who will own the data. What's critical is that gmail makes a commitment to data migration capabilities, so the service isn't a one way door to the future. - Tim O'Reilly

The free flow of data across applications just isn't happening today. It is essential, and I think inevitable that the way we manage our information changes, given the way we work and live.

Outside the consumer space of GMail I work in integrating systems, using web technology, XML and SOA. "Systems Integration" is not really systems integration; it's information itegration. When you move, reroute and repurpose information, a business can benefit from either a new service or an existing service at lowered cost with heightened quality. That's what it's all about. It's expensive, but becoming less so, in part due to the commoditization of software through open source and standards. Most business systems are not designed with data accessibility in mind. Yes, we've had XML for years, but XML's real impact so far has been down in the protocol/plumbing space. It's true value for data has not been realized - all that XML lying around is as yet, untapped potential.

I'm telling you this, because I think what's happened in business systems over the last 5 years can inform what's going to happen in the consumer space. To appreciate the consumer application space, replace "systems" with "applications" and "business" with "customer" in the above paragraph and we might see that things are going to change. The same commoditization of data formats will have consequences for current consumer software business models, just as the commoditization of plumbing and networking has had for business systems.

Tim again:

The ability to search through my email with the effectiveness that has made Google the benchmark for search. How many times have people asked, "When can I have Google to search my hard disk?" That's a hard problem, as long as it's just your disk, on your isolated machine. But it's solvable once Google has lots and lots of structured data to work with, and can build algorithms to determine patterns in that data. Gmail is Google's brilliant solution to that problem: don't search the desktop, move the desktop application to a larger, searchable space where the metadata can be collected and made explicit, as it is on the web.

I don't know - this is what stops GMail looking like innovation to me. I agree with Jeremy Zawodny that this is incremental improvement. Google are ultimately loading your email into a database, as they've done with the Web. It's a centralized model, not an edge model. To me that's highly dissonant with the network OS vision. And it's just email - personally, email is a fraction of the information I need coherency for. We need search that ranges across protocol and application information space.

I believe anyone who can distribute search away from the centre to the edges will win big.

Where Google is showing huge innovation is in technology management - by the sounds of things the ratio of admins to servers over there is impressive. You really, really, want these guys running your data centres. This is much like pointing out that where Amazon innovated was not technology but logistics management combined with a new sales channel. And there's only so much excitment to be had in optimizing the data centre ;)

Tim mentions Chandler with regard to the desktop and sounds almost disappointed. But open source could be a driver in making data application independent because open source is where the momentum for change can be maintained. What needs to happen here as much as anything is to get the open source community (especially the Java community given the portable nature of Java), off its focus on server-sided networking and start looking at users and their needs. We don't need any more web frameworks. Projects like Chandler, and less directly Eclipse, are the start of that. Like using open source for middleware, this will be only advantageous for some prime movers - if everyone does it then the economics change drastically and companies whose model is traditional product and not services will start to feel the pain of lower and lower margins until they re