" /> Bill de hÓra: May 2007 Archives

« April 2007 | Main | June 2007 »

May 30, 2007

links for 2007-05-30

May 29, 2007

links for 2007-05-29

May 27, 2007

It's not a science project

Patrick Logan: "Software tends to "accrete" (in the worst way) rather than change, because we developers tend not to pay attention to the limitations we are imposing on our systems".

That's much too convenient. It's tedious to incessantly see developers or "IT", as groups, get the rap for shortsighted upstream decisions. Plenty of developers understand exactly the limitations they're imposing, but imposed schedule pressures dictate they have little or no choice. This notion that the "business" is the set of stakeholders that are not technical is something to be questioned. Non-technical stakeholders are often worst placed to make decisions about what software should and should not do.

Gateway

Keith Alexander said TheyWorkForYou.com markup "is a dataset that would really benefit from being available as RDF". If you don't know, TheyWorkForYou allows citizens to track their representatives in the UK Parliament, and other assemblies, by making things like the Hansard available online. TheyWorkForYou is a brilliant site, every democracy should have one.

Looking at the markup formats, I can see why Keith is interested in a mapping. It's attribute driven XML, not unlike a specialized OPML. Attribute driven XML tends to be markup that contains properties about a thing - the attribute/values being property value pairs about something, with one attribute usually designating the noun - the element itself tends to describe the class of the thing. In TheyWorkForYou's case that special attribute is called 'id' and you can see how that's a straight mapping onto rdf:about, once you resolve the ids into absolute URLs. The reasons developers tend to like attribute markup is that it can be slightly more convenient to program to initially - it avoids having to deal with significant whitespace, and processing of child elements, as there aren't any.

There are a few issues with attribute based markup however. One is extension; you keep adding attributes and eventually you end up either with co-occurrence constraints between the attributes, ordered evaluation of attributes, or a private subset of XML whose sole constraint is where you can put element content. Another is expression; ultimately how the thing is classified is just another property about the thing, and making the class an element is something of an optimization for a particular domain (something can be classified in many different ways). The markup then ends up sort of "inside out", where the elements are the classification scheme the authors cared about most; the entities tend to get duplicated under different elements. When it coems to integrating this data, you'll probably need to transform "outside in". Another is indexing. For larger datasets, you will need to do work to relate and index the ids (effectively these are joins to answer questions about the entity itself). Yet another issue is textual. Putting descriptions and general text into attributes is awkward; there's a fair bit of OPML out there that does this and it's not pleasant to look at Attributes really aren't designed for carrying text. In any case, these are technical nits about data formatting, and don't really detract from the fact that having this data openly available is wonderful.

So, can RDF help with all this? Absolutely. It's often easier to name things with URLs and and loosely tag them with classifications. This allows federation - others can classify and describe without having write access to the originating system, as each noun will have a global name. Then again, there's a straight mapping onto Atom; using atom:id to name the entities and atom:category for theyworkforyou's classifications and entity types.

Finally, there's TheyWorkForYou's "rest.cgi", an API into the data - long time REST proponents will appreciate naming a CGI 'rest' for all kinds of reasons.

Just use Atom

Rogers Cadenhead:

Really Simple Syndication Best Practices Profile

Editor’s Note: This profile contains a set of recommendations for Really Simple Syndication, a web syndication format documented in RSS 2.0 (revision 2.0.8). Public comments are welcomed at RSS-Public.

Copyright Notice

Copyright 2007 RSS Advisory Board. This is version 1 of this document, published May 24, 2007. The current version will always be available at this link and other drafts are available.

Recommendation

Just use Atom.

License

Copyright 2007 RSS Advisory Board. Redistribution and reuse of this document is permitted under the terms of the Creative Commons Attribution-ShareAlike 2.0 license.

Filed under courageous.

But do note that there are readers out there that can't handle namespace prefixed Atom; it will look like your feed is not updated. I've been bitten by this and so has Aristotle. Those readers suck, and there are tests to prove it.

Turtles

Mike Herrick: "I think the only way to make sense of this is to separate the two concepts as best you can. The integration architecture should be the interfaces you expose and events you generate from various large applications or sub-systems. The application architecture should be dedicated to defending the conceptual integrity of that application / sub-system & pushing the integration to the edges."

Makes sense to me. Sometimes I like to say that the real action is in between the boxes.The thing is, if the application is very large, it's either come into existence in one large iteration, or isn't large, but has grown to be large, which means it's possibly a lot of little applications talking to each other...

May 26, 2007

Wouldn't start from there

Harry Pierson: "So when I said 'simple scenarios' above, I meant 'scenarios that don't need transactions'. (I take it as a given that RESTifarians aren't hot for WS-AtomicTransaction.) ATOM Publishing is a simple scenario because the web resource authoring scenario doesn't need transactions to protect updates to multiple resources at a time. If it did, I don't believe the REST as CRUD approach they use would work."

Here's a counter-example that transactionally updates multiple resources. People really do get stuck on transactions as the be all and end all of business computing - thought for the day - value exchange != transaction.

I along with others been reading and following web/rest awareness growing in and around MSFT, and aside from disbelieving that some ostensibly intelligent people have only recently gotten it, I'm struggling to understand some of the posts. It must be very complicated stuff that they're trying to bring onto the web. Stuff like a "long running transaction updating multiple distributed stores". Why would you want to do that?

Update (26th May 07): David Ing was kind enough to respond in a comment: "I thought what I wrote would be understood to mean 'I wouldn't start from there', but in the back/forth with Harry (a long running transaction?), maybe that intent got lost?". Fair enough, I might have jumped the gun; yet it would be a concern if people come to discover the overnight success called REST, only to be disappointed to find it doesn't solve the wrong problems.


links for 2007-05-26

May 25, 2007

Python abstract classes

Brett Cannon, "Guido has now accepted PEP 3119: Introducing Abstract Base Classes." And a quote from PEP 3119 -- Introducing Abstract Base Classes tells us the key feature:

"The abc module also defines a new decorator, @abstractmethod, to be used to declare abstract methods. A class containing at least one method declared with this decorator that hasn't been overridden yet cannot be instantiated. Such methods may be called from the overriding method in the subclass (using super or direct invocation). "

For anyone involved in large Python code bases, or those working with languages like Java or C# (or Blub) that think Python requires inordinate discipline to scale up structurally on LOC, this is big news. The @abstractmethod decorator will allow the kind of signature based contracts that C# and Java programmers have relied on for years to organize their code.

One downside I see is that it seems you can now break your client users by adding new @abstractmethod to base classes after you release. That is, this feature will introduce the notion of API backward compatibility through method addition as well as deprecation. This is the same issue as adding a new method signature to a Java interface. a problem that C# notably doesn't have because it only provides abstract classes.

In passing I'll mention that Zope3 introduced the notion of interfaces a few years ago, after the lessons learned from Zope2, which is one of the bigger Python code bases out there. Zope3 seems to avoid the backward compatibility issue - you don't have to implement a method unless a NotImplementedException is declared in the base class' method body - at the expense of having its own inheritance hierarchy via "zope.interface". As PJ Eby said "where Zope leads, Python follows".

Something useful

You can track the the Irish election results on Twitter with IrishPolitics (via Bernie Goldbach)

May 24, 2007

links for 2007-05-24

May 23, 2007

links for 2007-05-23

May 22, 2007

QOTD

Jim Kane: "I don't kill my own chicken for Sunday dinner anymore, why should I provision my own server?"

Behind the stonewall

Pete Lacey: "I would develop Apollo applications if, and only if, my application was deployed inside the firewall and I had a set-in-stone requirement that could not be met by a browser-based app. But, again, that’s just me. YMMV."

For that problem space (corporate desktops), I still agree in spirit with Robert Sayre when he said "deploy your corporate or vertical apps on XUL".. With the other sane option being Eclipse (MSFT revving their client platforms every few years not being a good thing).

The real question is, what requirement cannot be met by a browser based app, *especially* if you include XUL? I mean fundamentally can't be met or utterly pointless, not just "difficult" (difficult is merely motivation). The benchmark used to be a word processor, now it seems to be Photoshop.

May 20, 2007

links for 2007-05-20

May 19, 2007

the wood from the trees

O'Reilly's State of the Computer Book Market for Q107 is out. Money quote: "Overall the Q1 '07 market for programming languages was down (9.10%) when compared with Q1 '06." After that figure, it's hard to get excited about relative growth or non-growth of pet languages if dominance means a growing share of a declining market.

links for 2007-05-19

May 18, 2007

Time passes

In an otherwise fine piece by Pat Helland, there was this, from out of nowhere: "Moving to SOA is like moving from Newton's Universe to Einstein's Universe.". As things stand, moving to SOA seems more like moving to a dark age. Otherwise, I'm hoping Helland follows up with a piece on CAP, which seems to distributed data as the Uncertainty Principle is to physics - a hard constraint.

Irrational Exuberance

Robert Cringely: "There is no downside."

links for 2007-05-18

May 17, 2007

Design for the real world

Jeff Newsom: "I find this interesting. So, basically, at the end of the day, there is a baseline understanding of how the web was designed and currently works that was largely ignored/dismissed in the soap world and specifically in the Connected Systems Division until this Biztalk SDK. Many of us, myself included, drank to kool-aid on soap early on, because we wanted to connect systems together, and we liked messaging or we liked distributed objects, and we didn't stop long enough to grok fully the web. As I did more web stuff, I realized that I didn't really care about a lot of the stuff that was layered into the SOAP/WS stack, and I did really need and love the beauty of GET and friends."

Adopting WS-* was always prone to being a faith based exercise, given the prior art it was based on. It's been obvious and well-documented for going on half a decade that that WS-* wasn't going to work out entirely. So, watching ex-WS-* stalwarts espousing REST and stumbling to the Web is well and good, but communities like rest-discuss, lesscode, fork and atom-wg deserve tremendous praise, and due credit for getting it early.

REST isn't even the real lesson; the real lesson is applying principled software design and architectural styles to problem spaces; it's about getting off fads and hype cycles that infect the industry. It's all in the constraints.

links for 2007-05-17

May 16, 2007

links for 2007-05-16

May 15, 2007

links for 2007-05-15

May 14, 2007

links for 2007-05-14

May 10, 2007

links for 2007-05-10

May 08, 2007

Hybrid methods, then

"Unifying Reasoning and Search to Web Scale".

Why do AI types keep having to discover hybrid methods and/or resource bounded agents?

May 06, 2007

links for 2007-05-06

May 05, 2007

links for 2007-05-05

May 04, 2007

links for 2007-05-04

May 03, 2007

Tip of the Iceberg

Jeff Bezos: "If you are going to build any kind of Web-scale application, 70 percent of your energy goes into things on the back end," he said. "If this heavy lifting isn't done at a very high-quality level, it can torpedo your successful project."

links for 2007-05-03

May 02, 2007

links for 2007-05-02

Small Pieces

Keith Fahlgren: "We’re trying to get a count of all of the element names in a set of 49 DocBook 4.4 books."

A glimpse into the future of integration, maybe.

May 01, 2007

links for 2007-05-01