Gavin King: “If you think that relational technology is for persisting the state of your application, you’ve missed the point. The value of the relational model is that it’s democratic. Anyone’s favorite programming language can understand sets of tuples of primitive values. Relational databases are an integration technology, not just a persistence technology. And integration is important. That’s why we are stuck with them.”
Amen to that. If there’s one thing that we need to learn is that data lives much longer than applications.
“ORM makes it easy to work with objects and databases most of the time. Compared to five or six years ago, ORM has solved most of the problems of data access in online applications. It is no longer anywhere near as painful as it used to be.”
I have to admit I haven’t been using Hibernate or any other ORM solution for the past year or more, but some of the pain is still there, and sometimes the pain makes you think that you’d be better off with plain, old SQL rather than a full-fledged ORM.
In any case, there is probably something that is even more painful than either plain SQL, an ORM or an object database: it’s using RDF as a persistent storage medium just because it’s more flexible than a RDBMS. Trust me, you don’t want to do that ;).
GdataServer - Lucene-java Wiki: “GData-Server is a lucene sandbox project started in June 2006. The first 2 1/2 month of the project this has been a one man show due to Google’s SummerOfCode. In fact of that the server is still in high development status but offers all features described in the GData protocol. Generally speaking, the Lucene GData Server is an extensible syndication format server providing CRUD actions to alter feed content, authenticaton, optimistic concurrency and full text search based on Apache Lucene.”
James Gosling: “There are real wars. And it’s really hard to be friendly to the open-source community because if you’re friendly to this camp then you’re viewed as an enemy by that camp. And one of the things we got stuck on was that we really like the Apache folks, but we also rather liked the GPL guys. And the Apache folks were very angry at us for picking GPL. But we had to pick something. If we’d picked the Apache license, the GPL crowd would be upset with us.”
I’m with Geir on this one: Sun could be friendly to everyone. It’s not like “the enemy of my enemy is my friend”. Moreover, painting the relationship between the ASF and FSF as a kind of war is a bit over the top, isn’t it?
Gosling confirms again that he’s not particularly smart when talking about Open Source, as already mentioned here and here. However I’m happy to learn that he changed his stance from this:
We’ve got several thousand man-years of engineering in [Java], and we hear very strongly that if this thing turned into an open source project—where just any old person could check in stuff—they’d all freak. They’d all go screaming into the hills.
But it feels like we’ve gotten to a point where the developer community is strong enough and feels strongly enough about consistency and interoperability and quality that market pressures will keep things on track. And those that try to misbehave will have issues with the market.
Assaf Arkin: “That, in a nutshell, is how we went from the deeps of frustration to a build system that … hold on a second … is actually fun to use. And dead easy to customize. And works repeatedly.”
I don’t hate Maven with the same passion as Assaf has, but that’s probably only I haven’t yet used Maven in anger for a big project. My latest big project started with Maven, but moved quickly to Ant+Ivy.
Still, Ant is not at all fun to use. I find most of our Ant scripts unreadable (pointy brackets don’t help) and the maze of includes that were put in place to provide some kind of code reuse too confusing and impossible to debug.
Mind you, this is not an indictment of the fine people who wrote those scripts. They did the best job possible, given the limitations of the tool.
Anyway, neither Ant nor Maven seem to be any fun to use, so I’d welcome anything that promises to bring back some fun to the process. We all know that writing stuff in Ruby can be fun—again—but my worry is that adopting a build system that nobody else uses is bound to give you problems, like not being able to find people who are already expert with your tool of choice.
However, if nobody ever tried anything different, we’d be stuck with make, I think.
Regarding the recent brouhaha over RedHat®’s cease and desist letters against people and companies offering JBoss® and Hibernate® training, here’s my two (Euro) cents:
RedHat® is perfectly in its rights to ask that people use their trademarks in the proper way, so as not to dilute it. IANAL, but should I ever offer Hibernate® services, I’ll be careful to do it under the moniker of “Support (or training) for the Hibernate® Object Relational Mapping Software” or somesuch, just to be safe.
Lawyers, as usual, are a bunch of wankers. First they send out threatening letters asking that companies do not use the Hibernate® and JBoss® names at all, then they backtrack and change their stance, hoping those who received the C&D letter will never read Bill’s blog.
Having said that RedHat®, as a company that needs to make a profit, after all, can behave as any other “evil” corporation, if it pleases them, let me add the following: I might be an idealist, but I believe Open Source companies should act differently. Otherwise all this talk of community is just lame and hollow.
GData uses either of two standard XML-based syndication formats: Atom or RSS. It also has a feed-publishing system that consists of the Atom publishing protocol plus some extensions (using Atom’s standard extension model) for handling queries.
Each of the following Google services provides a Google data API:
Google Apps Provisioning
Google Base
Blogger
Google Calendar
Google Code Search
Google Notebook
Google Spreadsheets
Picasa Web Albums”
As DeWitt Clinton wrote on the atom-protocol mailing list:
What never ceases to amaze me is that APP was applicable in so many cases. A true testament to the power of the protocol.
It’s indeed noteworthy the amount of buy-in and mindshare the Atom Publishing Protocol has gained in such a short time. And it hasn’t even reached RFC status yet.
I just installed the Krugle plug-in for Eclipse (beta) and I have to say that it is quite good. Now when I’m working in Eclipse and using some Open Source library, I can look up its code and load it in the editor, without switching to the browser.
TO be honest, I would like to always have a Maven or Ivy repository complete with sources and javadocs for all the libraries I’m using, but that is often not the case, so I welcome Krugle plug-in.
Dave Winer discussesYahoo! Pipes and in the process says something so wrong that I don’t even know where to start picking it apart.
In this case, the target is the huge, rich base of RSS feeds, which is designed to work with one kind of aggregator, a River of News, and if you structured Pipes around that — a filtration process for a river, it might bear some immediate fruit, but its built on a different model.
This might be true if you limit yourself to RSS, which is not very useful beyond aggregators. Maybe if you started using Atom instead, you might discover it is suited to a much larger category of applications.
It assumes that each feed can be dealt with as a procedure call, which according to the REST philosophers, it can, but in practice, feeds don’t take parameters, so they’re the least interesting kinds of procedures, like clock.now in UserTalk. Sure there are some verbs that build on that verb, date.month, date.year and date.dayOfWeek, but nowhere near as much as verbs that have rich parameter lists, which are like the gateways that Tim O’Reilly and Jon Udell are so excited about.
Equating feeds to procedures? Is this supposed to be consistent with REST, in Dave’s mind? Reality check: There are only four verbs in REST: GET, POST, PUT and DELETE.
See XML-RPC for Newbies for background; a Pipes that could do XML-RPC could be interesting, esp because the Metaweblog API is an XML-RPC application, and is widely supported by blogging tools and CMSes.
XML-RPC? Talk about flogging a dead horse.
In the RSS world, and therefore in Pipes, there’s no way to tell if items in two feeds are talking about the same thing. The best you can hope for is keyword serendipity, which all the demos so far do, and those make for unsatisfying demos, because you know you couldn’t deploy a useful app out of the concepts they illustrate. Very much like the early demos for HyperCard, Marimba, and my own Frontier.
Now it’s possible that a company like Yahoo, with its diverse flows of information, and nearly universal support of RSS, could add enough metadata to their feeds to be sure two items in different feeds were talking about the same thing, and then we’d be somewhere interesting.
Once again, if you used Atom, you could rely on every item having a unique identifier, and a universally unique one, being a URI. You could also reasonably expect that two copies of the same item, no matter which feed they were found in, had the same id. Unfortunately, RSS offers no such guarantees.
Looks like Dave is just whining here because Yahoo! Pipes is not like XML-RPC and RSS is too weak for doing anything besides aggregating news. If he had the courage to look beyond what he invented many years ago, he might find something actually useful was invented in the meantime.
Living software has a command shell, since you need a way to talk to it like a grown-up. It has an extension language, since you need a way to help it grow. It has an advice system, since you need a way to train and tailor it. It has a niche, since it needs users in order to thrive. It has a plug-in architecture, so you can dress it up for your party. And it is self-aware to the maximum extent possible given the external performance constraints. These features must be seamlessly and elegantly integrated, each subsystem implemented with the same care and attention to detail as the system as a whole.
If you ignore the nonsense about consciousness, I think Stevey pretty much nails down the defining characteristics of software that is designed to last for a long time and doesn’t require rebooting every time you introduce a trivial change.
One of my proposals has been accepted for the upcoming ApacheCon Europe 2007 conference, so it’s highly probable that I’ll be entertaining people there about “An Architecture of Participation for Open Source”, whatever that means ;). The conference program is not yet online, so you’ll have to wait until it is before reading the abstract and deciding whether it’s worth attending or not.
It’s nice that this year ApacheCon Europe is in Amsterdam, a city where I’ve recently spent only a few weeks in all ;). I could have appreciated a less familiar location, but all is not bad: looking at the calendar the timing looks perfect for a family trip, considering that April 29th is a Sunday and May 1st is Labor Day holiday in Italy. We’d just need to take April 30th off from work and be able to spend four days (including Koninginnedag) as tourists. Since every time I’ve been to Amsterdam has been for work, I was never able to visit places like the Rijksmuseum or the Van Gogh Museum, which have the nasty habit of closing down at 6 PM on weekdays.
Coming to a more local event, I’ll be speaking about “Ruby for Java Programmers” at the next Milan Java User Group meeting on Feb 22nd, to be held at our offices. Also in this case, the program doesn’t seem to be online yet, but it’s the same talk I already did at OSCCON 2006, RailsConf Europe 2006 and ApacheCon US 2006. I wonder if I should do it in English, as I probably know it by heart in that language already.
Steve Vinoski: “A significant advantage of the uniform interface constraint lies in the area of scalability. For a client to correctly interact with a SOA service, it must understand the specifics of both that service’s interface contract and data contract. But for a client to invoke a REST service, it must understand only that service’s specific data contract: the interface contract is uniform for all services.”
This is an interesting article if you want to get a deeper understanding of the difference between the SOA and the REST application styles. I have to admit I wasn’t totally aware of the “uniform interface” aspect of REST, but now that I am, it just makes me like REST even more.
There’s only one drawback: these files are big. Even though this should pose no problem to most users, I wonder whether it would be possible to have a reduced-resolution version.
Jonas is a well known speaker, architect and open source developer, founder of the AspectWerkz project and committer of AspectJ. He’s Senior Software Engineer at Terracotta.
The title of his talk will be Distributed Computing Made Easy: How To Build a POJO-based Data Grid:
Abstract
In this session you will learn how to build a highly scalable Data Grid using standard JDK 1.5 and POJOs.
We will start with a discussion of the Master/Worker pattern — one of the most useful parallel programming design patterns in use today. You will learn about the identifying characteristics of the pattern and how best to use it in the real world.
It is a very practical, “hands-on” session in which we will present how to build the Master/Worker pattern using standard JDK 1.5, and how to turn it into a distributed grid implementation by using Open Terracotta’s* JVM-level clustering technology. Following that, we will cover the production implications of operating and scaling a reliable work management framework, and give examples on how to address real-world challenges such as dealing with very high volumes of data, handling work or worker failure, ordering, routing schemes etc.
Check out this page for all the details about the meeting.
This is the second edition of Merril R. Chapman’s best-seller In Search of Stupidity. To the first edition’s collection of episodes of strategic blunders, marketing disasters and outright hubris on part of various high-technology companies during the 80’s and the 90’s, the new edition adds a few notable episodes. Companies listed include: IBM, Digital Research, Apple, Microsoft, MicroPro, Ashton-Tate, Siebel, Borland, Intel, Motorola, Google, Novell, Netscape, and various dot-coms from the Internet bubble times.
Apart from being a fun and enjoyable read, In Search of Stupidity is also a valuable resource for high-tech entrepreneurs, marketers and geeks wanting to turn their technical prowess into a profit. There’s nothing like learning from the mistakes of others in order to avoid repeating them, and one of the merits of this book is that it does not limit itself to making fun of clueless companies, but extracts and digests from their tales a number of immediately useful advice.
So you can expect to learn how to avoid the same sort of positioning mistakes that doomed MicroPro, how not to inimicate the developer community that constitutes the lifeblood of your products, like Ashton-Tate constantly did, how to avoid damaging your relationships with the press, and many other useful tidbits. In this respect, the Stupid Analysis chapter at the end of the book is especially useful, in case you missed some of the more subtle lessons that were contained in the narrative presented in previous chapters.
In summary, this books is valuable both to entrepreneurs and managers, and to geeks who want to enter marketing, management or start their own company. Even if you are content with keeping a purely technical role, should you start recognizing the signs of stupidity on part of your company, you could at least be prepared to polish up your resume.
To be honest, it could be argued that some of the most egregious screw-ups described in the book were, at least in part, due to sheer bad luck, and that hindsight is always 20/20. Still I think that the stories told here teach some extremely valuable lessons. External circumstances alone cannot account for all that happened; it takes much stupidity and arrogance to turn unfavorable events into total disasters.
If you want to be picky, there is a couple of instances where the message of the book sounds a bit off. The first one can be found in the story of Google’s fight with CNET.com over the issue of privacy, and its supposed bowing to the censorship imposed by the Chinese government. You can argue how much you like that Google acted stupidly in these circumstances. Its behavior might have tarnished its ethical image—”Don’t be evil”, remember?. However, it doesn’t seem to have affected Google in any serious way; few people remember the episodes and Google is going as strong as ever. Compared to the other examples found in the book, this is a case of very mild stupidity, if at all, and it looks like Chapman seriously wanted to pick on Google but couldn’t find any real damning evidence.
The second point is in chapter 12, The Strange Case of Dr. Open and Mr. Proprietary, where the author traces the beginnings of the Free Software movement to the first hackers who started out by illegally copying Microsoft’s Altair BASIC. If one didn’t know better, one might start to think that Free Software pioneers were just a bunch of freeloaders, if not thieves. In the rest of the chapter, however, Chapman makes it abundantly clear that the only example of stupidity, in this case, can be found on the side of proprietary companies who failed to understand the Open Source/Free Software movement and its effect on the software industry.
To sum it up, In Search of Stupidity is a very good book, especially if you missed the first edition. Five stars are well deserved.
Attending the live talk would have been great, but even form the slides only (PDF version here), there are many important lessons in there, particularly regarding scalability. Some of them are nuggets of often repeated wisdom, like “Keep application tier completely stateless” and “Cache where possible”. Others are more unexpected, like:
Throw out most of J2EE, and
No business logic in database (no stored procedures and only very simple triggers).
All signs pointing to 2007 as the year of dynamic languages on the Java platform? It really seems likely.
On an unrelated note, I am also pleased to announce the relase of Apache Abdera 0.2.0 (incubating). Nothing revolutionary here, but an impressive number of features already for a 0.2 version. Very stable and surprisingly bug-free also.
I think I should be happy that he’s not sending MS Office documents, and cannot really in good conscience recommend the exclusive use of Apple products like iWork, in preference to a true Open Source solution, no matter how much I love Keynote. Moreover, we still need to get him a Mac.
The only problem I had, to be honest, was that I didn’t have Open Office installed on my MacBook Pro, and didn’t want to install and run X11 just to open a few documents. So I thought of using NeoOffice. After all, I’ve seen Simon Phipps use it on his Mac when he did his presentation at OSBA, so if it’s good for Simon it must be good for me.
Problem is, the main download site for NeoOffice appears to be down. Looking for an alternative location, I came upon a torrent for NeoOffice 2.0 Aqua Beta 3 for Intel Macs which led to a speedy download and now I can open ODF files without having to suffer X11.
To make this post a little less self-serving, I’m linking to the torrent here, for the benefit of those that might be searching for it. Personally, though, I think I will continue to use Keynote for doing my own presentations.
Starting today, Giovanni is our new boss. If you wonder what happened to Gianugo, don’t worry: he’ll be moving higher to be the head of our European operations. I’m not sure what this mean in practice. I think he doesn’t know either, exactly ;). We’ll have to figure it out as we move along, as things here are happening at an incredible pace, which just makes it all more exciting.
Back to Giovanni, he’s one of the leading figures in the Italian Java landscape, having started with it while at Sun, back in 1995. I’m sure working with him will be a great source of motivation and knowledge, while we could teach him some of the ins and outs of the Open Source landscape.
So here is my most heartfelt welcome to him, together with an invitation to start a blog. I need someone to link to.
Apache Labs are the place where ASF committers can work on innovative, blue-sky and off-the-wall ideas, without having to worry about fitting in an existing project bylaw or building a community around it, but unlike other external venues that can offer similar hosting services, as a place where fellow committers can offer suggestions and help.
I think this is a great idea and an interesting innovation in the way Apache tries to manage and grow Open Source communities. I’m sure we’ll see many labs flourish soon.
I just installed the 
As a Java architect, I’ve always been curious to learn about what makes large, enterprise Java systems tick. One of the biggest Java systems out there is certainly eBay, and if you want to know more about its architecture, now you can read the slides of an SDForum presentation titled 
You know what happens when you get 
