" /> Bill de hÓra: March 2003 Archives

« February 2003 | Main | April 2003 »

March 29, 2003

Private methods, Texan APIs, standard interfaces

Charles Miller:

I don't test private methods. Being able to quickly create, move around, and change the functionality of private methods is vital to remaining agile while developing.

Sounds good. I've often upped a private method to public so that I could test it. Michael Feathers at ObjectMentor has a nice way of putting this- when you start wanting to test private methods, that's your design genius telling you the object interface needs to be adjusted. And this works fine so long as you haven't made it that the object can be called with a sequence of calls that is broken or non-intuitive and puts the code into an undefined state.

There is a significant cost involved in changing the behaviour of your public interface: you have to make sure each caller can cope with the change. Sometimes you even have to write new tests for each caller because you have introduced some new edge-case that wasn't there before

Maybe we can do that on a LAN or a middleware. If we're writing for clients we don't own or can't influence (as is often the case with webservices), fooling around with a public contract is a non-starter, as are expectations of synchronized upgrades across the clients. When Amazon or Ebay upgrade their sites, nobody expects or accepts that you have to upgrade your browser in kind. To take it a step further, we might have clients we not only don't own, but don't know about (such as an RSS reader).

Martin Fowler has talked about published versus public interfaces in the past and has suggested that languages need to cater for this distinction. Published interfaces might just push you out of the API realm and into that of application protocols. But maybe this is moving away from programming languages altogether. For web services, perhaps thinking about interface design nudges you away from an RPC style towards doc/literal or a direct binding to the underlying protocol's methods.

There's two aspects to this: behaviour and signature. Too large or too volatile a signature places an (unneccessary?) burden of cost on clients, and as RESTafarians like Mark Baker argue, just won't scale, which is why widely adopted application and data protocols (HTTP/SMTP/SQL) have controlled, stable interfaces. Behaviour is different again. But safe to say that if you are a client of an API whose behaviour is erratic across versions, it might be a good idea to find a new service provider or library.

But if we're staying on APIs, one option might be to stick with a uniform interface solely based around actions and avoid the 'doVerbToNoun' compound idiom (sometimes called computerEnglisch) as far as is practical. Now telling someone that any JavaBean only needs get() and set() instead of a series of getThis(), setThat() calls can produce skeptical responses, but there's a surprising amount of useful work you can get done with a handful of actions. After all there's only so many things you can ask an object to do, but there are any numbers of objects to ask. It's a matter of striking the right balance- at one end you pay in inefficiency, indirection and sometimes a limited ability to express your ideas; at the other, you wind up with ten gallon hat APIs that have big learning curves, big surface areas and likely as not, unintended and buggy call sequences.

For Java programming, plugins (something that Eclipse and IDEA have bullseyed), and service layer decorators at package and system boundaries can be a great help. Both these patterns are popular at work in Propylon and see plenty of use - it's great to be able to grab a package with a controlled, well-sized interface and run with it, knowing that it won't take days to understand and its contract won't break you two releases later. The same reasoning is applied in PropelX - there is one interface that every component in an XML pipeline shares, which is the same interface as the pipelines themselves. Standard, composable interfaces are a well worn road to scalable systems.

Donald Rumsfeld on change

Donald Rumsfeld:

If you don't like change, you'll like being irrelevant even less.

March 25, 2003

Inheritence: I've got blisters on my fingers

Darren Hobbs: Inheritance Sucks!

What about polymorphism you cry?

Not me.

Thats what interface inheritance is for. If you need to be able to polymorphically pass your composed object to methods that expect your contained object, implement a common interface and make your methods accept that instead. Your code will be cleaner, more modular and (most importantly) less coupled.

Inheritence was always a bad term for what is really better called type unification or even for logic wonks, quantifiers. Gibberish aside, all we're trying to do is to enable a function to work on a broader range of types and interfaces are great for that. Got an operation that's common across a range of classes? Have them be the same type by using an interface.

Most code uses inheritance more often than object composition, and much of the time composition would have been the better option. I suspect the reason is as prosaic as the fact that object composition involves more typing.

Yep, in the Java case, 'extends' is the son of #include. The best you can say about 'extends' is that it saves you keystrokes. It adds no power to a programming language. if anything it seems to make managing and changing programs more difficult, unless you're using it in a very controlled manner (ie, not like java.io.*).

Inheritence as macro inclusion:


class A {
void foo(){println("foo");}
}

class B extends A {
void bar(){println("bar");}
}

Alternatively:


interface A {
void foo();
}

class X implements A {
void foo(){println("foo");}
}

class B implements A {
void foo(){new X.foo();}
void bar(){println("bar");}
}

I would prefer the second. I suspect it's more flexible.

RedBarGreenBar is ShellEnvy

The TDD and XP communities talk a lot about red bars and green bars (failing tests and passing tests in tools like [JN]Unit). I suspect this is a poor man's interactive environment for statically compiled languages, what Lisp people call a read-eval-print loop and the rest of us call a shell. Support for XP/TDD is best when the language has an interactive top layer. Smalltalk IDEs had this insofar as there was no discernible compile step. Lisp, Python and Bash have this. Tools like VisualAge (which derives from Smalltalk) and more recently IDEA, attempt to coerce static languages into a scripting context. As Ward Cunningham puts it:.

They're complicated, and you have to learn how to work them - but boy, when you do, they make those languages start to feel like scripting languages.

The red-code-green loop in Junit and Nunit is a stab at interactivity and fast feedback. And one of the reasons IDEA is the best Java IDE on the planet is because it gets us Java/J2EE types further away from the C/C++ code-compile loop and nearer to an interactive coding environment.

March 24, 2003

Standards versus Standards

TheArchitect.co.uk - Jorgen Thelin's weblog: When do we get a real RSS Standard?

Jorgen Thelin:

I don't think any of the versions of RSS qualify as anything like real standards, using my rule-of-thumb guidelines:[...]

We can draw a different distinction, that of de jure and de facto standards:


  • de jure standards are produced by standards organizations. This includes the likes of UN/EDIFACT, BSI, ISO and ANSI. These bodies are often concerned with certification. This does not include vendor consortia, like the W3C, which I understand is why they don't use the term standard. I'm really not sure where bodies like IEEE, WS-I, OASIS and ECMA lie.
  • de facto standards are the ones that get used, irregardless of who produced them. This includes XML, RSS, SAX, PL/SQL and J2EE; maybe at the fringes it includes Linux and Windows.

De jure emphasises the makers of the standards artefact, whereas de facto emphasises the users of the standards artefact. It's not hard and fast; the J2EE is not a de jure standard, but does involve certification. SQL is a de jure standard, while Oracle SQL is a de facto standard. A good example of a de jure and de facto standard is C.

What Jorgen seems to be looking for in a standard are some basic rudiments of transparency, openness, versioning process and a consensus driven approach within the context of an organization. The downside of excluding de facto standards is we wind up asking initially odd sounding questions such as "when do we get a real Linux standard?", or "do we have a real Ant standard?" It can be all too easy for standards to lose touch with what is actually happening in the trenches - at the best of times these are worlds apart, causing confusion and misunderstanding in software projects (and software markets). What happens then is that a standard is usefully subsetted to close the gap; XML subsetting SGML being a prime example.

RSS 1.0 is strangely enough neither de jure nor de facto. Pig latin maybe.

Gary Reback on technology patents

Forbes.com: Patently Absurd

Gary Reback is best known for taking on Microsoft a few years back. but it seems from this article there's nothing new about using patents as a form of mutually assured destruction.

March 22, 2003

New W3C patent policy document

W3C Proposed Policy 19 March 2003

Python for OpenOffice

The Python-UNO bridge allows to use the standard OpenOffice.org API from the well known python scripting language.

Only works with Oo 1.1. Although the Oo APi is huge, there are some nice features worth getting at, particularly for using Oo as a file transformation engine.

March 15, 2003

sharkjumping: new category

In the grand tradition of Aristotle, Duns Scotus, Bacon (take your pick) and Dewey, I'm adding a new category of knowledge to weblog land - 'sharkjumping'.

Sharkjumping comes from the ontological representation of TV programs - it describes the moment when you know that TV program is no longer... you know what I mean. It's a sub category of 'rant', but expressed as a explanation as to why an entity which is cool or good is no longer cool or good, due to... you know what I mean.

Do add this category to your weblog. It will add value and richness to the weblog noosphere, capturing those defining moments that occur due to emergent phenomena, power laws, and amplified cybernetic feedback loops and so on.

Don't wait up for a formal semantics... you know what I mean.

[www.jumptheshark.com]

The Descent: WS-Eradicate, WS-NIH, WS-Extinction

About BEA adding and adding and adding to the WS-* jumble : Sam Gentile's Blog

But is the problem BEA going it alone on the authoring front (and releasing a supporting toolset with the Weblogic 8.1 beta, strategically a similar approach to BizTalk), or the fact that the sheer number of WS-* specs is becoming a joke? Don Box says he's had enough (who hasn't?), but he's the editor on WS-Addressing, and contributor to WS-ReliableMessaging, two more recently released WS specs.

With this many specs, divergence and non-interoperability seems a sure thing. I count going on half a dozen WS specs for reliable messaging; given that the organizations involved are supposed to be gung-ho for interoperation, how does that come to pass? Recall that there is no other reason to utilize WS, than to ease the pain of interoperation and application integration. But you only have to go onto SOAPBuilders or axis-user to find out that we can't even pass around basic data structures and types like maps, dates and floating point numbers yet. Does anyone believe for a moment that this WS-* corpus is consistent as a whole, or that it's even a corpus?

She's Supercalifragilisticexpialipointless!

Sean and Mark agree. This:

WS-Addressing

has no reason to be. Don Box agrees as well (he's also the editor).

Chris Winters: CVS commits as RSS

Chris Winters added this comment recently, but it's too good an idea to keep down there:

I just hacked something together to output our CVS commits as RSS. Once we hook in our bug/feature tracking system and the wiki we'll have quite a bit of information available for anyone in the company. I don't do this in the hopes that person A will have the information she needs, but rather that the available information will spark new ideas that we haven't even thought about.

RSS is so plastic. I was thinking yesterday - timesheets and RSS uploads... ?

March 12, 2003

Google: cead mile failte

Sean McGrath: Google coming to Ireland

Welll it's just been mentioned on the news here. So it must be true :)

RSS in JIRA

Raw Blog: There next for RSS.

Danny Ayers:

The same systems that are currently being used/developed for news and blogs can potentially be used for a wide range of other things, from 'semantic blogging' to domain-specific apps with news-like aspects. A good example is issue tracking - systems like Bugzilla and Scarab are topologically almost identical to blogging systems like Movable Type.

Yep. JIRA already pushes out RSS feeds.

FIPA ACL

::Manageability::

Carlos Perez:

I believe it was originally based on earlier work on KQML. Are these the atomic building blocks of interactions?

Yes and yes. The problem with KQML was that it wasn't specified formally enough (certainly not enough for machines to reason about what was being said to them). FIPA ACL has done more to tie down the semantics. The idea with speech acts for sofware agents has always been to compose conversations from well understood primitives. RDF btw, through its Model Theory tries to do something similar for facts and basic inference.

In an ideal world, an ACL is the content model for the stuff you put in a SOAP body. For anyone (like Don Box) who is sick of hashed out WS specs, the FIPA canon is stirling work, especially the Abstract Architecture. And it's interesting that some of the FIPA folk are starting to pop up on the W3C web services lists (rather than the semantic web ones).

An XML parser that ignores namespaces


Sparta.

via [::Manageability::]

March 03, 2003

New WS specs from BEA

Web Services

WS-Callback
WS-MessageData
WS-Acknowledgement

[via www-ws-arch@w3.org]

BEA Systems is very pleased to announce the availability of it's
Royalty-Free Specifications for asynchrony, reliable messaging, and general
message data... These specifications, and others, are supported in BEA Systems' flagship product, WebLogic 8.1, and the beta will be available later this week.

March 02, 2003

N3 isn't RDF

Dave Beckett - Journalblog: February 2003 Archives

I'm so tired of seeing morons confuse RDF, OWL and XML syntaxes so I'll record this rather than send it as email to the latest fool.

My favourite confusion is people thinking N3 is RDF. N3 does stuff that RDF just cannot. Confusing the two sets expectations about RDF that aren't justified. N3 is not RDF.

Resin on cygwin

It's been ages since I looked at Resin. It's not as simple as the readme says (just fire up httpd). I couldn't get Resin-3.0.0-beta to work on win2k via cmd.exe. Here's what I had to do to get it up on cygwin:

Copy the distro to cygwin's /usr/local/resin-3.0.0-beta to stop resin's perl scripts getting confused about /cygdrive/c on the classpaths (I put every java app under c:/java, but I gave up after 10 minutes with resin)

Edit httpd.sh to include:


JAVA_HOME=/usr/local/j2sdk1.4.1_01
export JAVA_HOME
RESIN_HOME=/usr/local/resin-3.0.0-beta
export RESIN_HOME

You might only need to add RESIN_HOME. I have an unorthodox setup for java in cygwin bash that allow me to change JAVA_HOME by changing the .profile. But note that this issue of Resin wouldn't run with a 1.3 JDK, I had to set JAVA_HOME to point to 1.4 to avoid a version mismatch (maybe its the jsp compiler; I used to get similar messages for Jasper).

Note to Java server builders. Please supply Ant files to startup your servers, .sh. perl and .bat files are quaint but... (I've done this for JBoss and Tomcat; one Ant script can be made to just work without the need to maintain 2 shell scripts).

Anyway, now I have to figure on why anthill.war is killing Tomcat and Resin on startup. It had better not be yet another log4j config issue, but that's what the stacktrace is looking like (not that I pay much that attention to OP stacktraces)...

Stop working on the semantic web

Eric Newcomer on ws-arch:

how and when are we going to get the W3C to stop working on the Semantic Web and take some leadership in Web services?

Or maybe the message here is that the W3C only wants to work on the Web and not on Web services?

Well, someone finally came out and said it. Good for Eric. This has been brewing since 2000. There are two houses in the W3C court when it comes to the web's future - webservices and semweb.

The irony is that that webservices and the semantic web are complimentary technologies if they would focus on their respective strengths, which they don't always do. The strength of web services is plumbing and transport packaging, the strength of the semantic web is in standard content models and metadata.

FIPA have organized their specifications to have a fairly clean division between the plumbing and the content. [and some special pleading: if you work in either webservices or the semantic web, do take a look at what FIPA are doing.]

March 01, 2003

fine grained access control: yes it's messy

Sean McGrath, CTO, Propylon

I've been playing around with some CMS/Portal systems lately and noodling the problem of providing fine grained access control. There seems to be a consensus of sorts around the core techniques (classifying logins, adding roles to them, putting them in groups etc.) However, my experience is that they are all implemented differently in different systems and the whole thing has an innate ability to become...well...ugly and complicated. Am I missing something?

Maybe coarse grained access control is the way to go. Most of what you would want to do in terms of manipulating content in a CMS could be described using generic methods, as you find in HTTP (or WebDAV, or CVS, or SQL, or chmod... ok, maybe not chmod). Don't want a principle to write to a particular document? Reject POST/commit/UPDATE requests to that document.

Are they quite mad?

ClydeHatter.com: Web Log

In any sane, user-friendly version of tomorrow, the PC of the future is ... no longer a PC. It's your mobile, your games console, your fridge, your video, your burglar alarm, all doing what they do best with simple, optimised interfaces, sharing processing power and services when they need to. Not an ugly, fantastically complicated piece of technology squatting in the corner extending its tentacles into every nook and cranny of your life.