One Laptop Per Child

http://www.xogiving.org/ is running a special promotion, give one, get one starting November 12th of 2007. If you purchase an XO laptop for one child, you may also purchase one for yourself. The project will allow developers to get their hands on what could become one of the most common computers on the planet.

I think David Pogue's video blog on the OLPC drives home this simple idea that is really about advancing education. Textbooks are expensive. The OLPC can act as a textbook reader even in harsh day light. The OLPC can charge off of solar panels.

Most shockingly, it exposes it's own operating system code to the end user in a unique way I've never seen. Control commands expose the Python code behind every screen. That's amazing... could this mean that there is a potential horde of newly minted Python coders on the horizon? What does that mean?


People you don't like...

I can't find an official quote but I once saw a televised question and answer session with Warren Buffet. When an audience member asked what it was like being one of the world's richest men.

In Warren's reply he said: "One benefit is, I don't have to deal with people I don't like." Warren then went on to explain with grandfatherly charm that his days were spent dealing with people he admired or otherwise liked because he could afford to select those people to surround him. He explained that finding good people and investing in them was one of his keys to success.

Only the most wealthy of people can seriously claim that they don't have to deal with people they don't like. For everyone else in the world dealing with people who annoy you is just a fact of life. There's no real way out. Few of us can afford to ignore or avoid our bosses, coworkers, or authority figures if we want to.

Not having to deal with people you don't like is an expensive luxury.


Some advice from a smart guy

"Any fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."
-- Albert Einstein
Make your software small, simple, and powerful.


Issues of Concurrency

I have a problem. I have two databases. One old one and one new one. The new one is fully normalized and the old one is not. Both databases drive their own front ends. One is a Perl front end the other is a Spring Java front end. The data between both interfaces has to stay in sync. Our DBA has elected to use triggers to keep the databases in sync.

Hibernate uses its own Version column to keep up with which version got committed to the database and when it happened. There are articles dealing with JPA, Hibernate, and Concurrency... my problem is a little different.

Here's my example of the problem.

Let's say you have a web application using an ORM engine like Hibernate. There is Entity version 1 in the database. User Alice checks out version 1. User Bob checks out version one.

Alice edits her copy of version 1 and sends it back. The ORM engine checks the object version against the database version and they match and on commit of Alice's changes the database version number is set to 2.

Bob makes changes to his copy of version 1 of the Entity and checks his version in. The ORM checks the database version and sees version 2 in the database. Version 1 is old and Bob gets an error reporting mid-air collision.

Now lets say you introduce a second database. This second database uses different Relational mappings but is itself an OLTP. Let's pretend both databases have exact copies of the data initially and an update trigger mechanism keeps the two OLTP's in sync.

If Alice checks out version 1 from the first database and the first interface and Bob checks out version 1 from the second database and the second interface. When Alice makes her change and creates first version 2 (2' or two prime) and Bob commits his changes to create second version 2 or (2'' or two double prime) the trigger from the first database to update the second will fire simultaneously as the trigger from the second.

In other words Alice's OLTP is unaware of changes made on Bob's OLTP and both changes are in route to the other's.

How should the two databases proceed?

Should last saved win? Should both databases error and roll back? Should the systems attempt to "merge" changes? Should one system be elected the "authority" for this data electing that Alice's interface and OLTP are always the right ones?


Linux Forgotten Root Password

Oh no, you've forgotten the root password to your laptop or other Linux desktop.

If they are set up with grub all is not lost. At the grub splash screen key in 'e' for edit. You'll now be able to edit the boot options. Select the line with the kernel on it and add the word 'single' as the last parameter. When you hit enter the edit mode will exit. Striking the 'b' for boot command will boot this configuration and your kernel will boot into the magical single user mode where you can type 'password' to change root's password without having to know what that forgotten original password was.

Now you can use the awesome power of root to change the other forgotten passwords on the system. If you think this presents a security hole and don't want to allow 'e' from the grub splash... you can secure grub with a password.


Symbol System Manipulation

If thought is just the manipulation of symbols. Then computers think. If thought is more than the manipulation of symbols... then how do you know people think?

If you can't accept that the mechanical manipulations of symbol systems carried out by a computer are thought... then how can you accept that the mechanical symbol manipulations carried out by organic beings are thought?

Artificial Intelligence beats real stupidity every time.

Waxing a tad philosophical, perhaps the mechanical symbol manipulations of any system be it a human brain or a computer are the echo of thought. In the case of the computer the program is the echo of a thought left by its programmer. In the case of a brain these are the echoes of thoughts begun in the minds of others and advanced or reproduced yet again.

The idea is that thought-stuff can move between noggins and that the computer offers a similar place of purchase for the thought-stuff as a rather simple minded noggin. So thought-stuff lives in noggins. Thought-stuff can be preserved in medium like a seed of an annual plant it lays dormant on a page. Thought-stuff gets planted in a noggin and sprouts.

Living thought stuff that bears fruit as action and turns to seed is shot across the divide between noggins in speech, on paper, or as code. The result is germinated. In the case of code the germination can occur in the artificial soil of a computer.


The new Alfresco

TriLUG last night had a special presentation from principal architect Jon Cox. Jon Cox had developed software for the Interwoven product suites and is now working for Alfresco which has released a new versioning engine based on Jon's work.

The new alfresco tool's new features include Native Office integration, multiple locking models, adaptive workflow engines based on jBPM, REST style API, a new Web 2.0 front end, web portal integration, and web content management features. The big win here is the long awaited Office integration. Unfortunately, this feature is apparently very new and doesn't have good documentation around it yet.

For a programmer the most common use of versioning is in source code version management with tools such as SVN. The difference between Alfresco and SVN was described by Cox using this analogy:

Imagine you have a window pane and you are looking at the Mona Lisa. You can draw on this pane, erase it, do what ever you want and no one but you can see it. Now imagine there are three of you... Alice, Bob, and Charlie. Charlie puts a mole on Mona Lisa, Bob puts a mustache, and Alice adds a goatee. If Charlie commits (permanently saves) his mole Alice and Bob will suddenly see the mole show up underneath their window panes.

This is very different from source code control in products like SVN and CVS. In source code the developers all have their copies that they work on. When they are done they commit their changes. In SVN if Charlie has committed that mole neither Alice nor Bob will see the mole until they go to commit. When they try to commit they get an error. Alice and Bob each have to update manually and then make changes to accommodate Charlie's mole addition.

This is inappropriate behavior for managing documents. And, that is why Alfresco can be set up with either pessimistic locking (source code type locking) or optimistic locking (everyone sees each other's changes immediately).

I took away these key concepts:

Alfresco versioning composed of three layers... The official copy, the working copy, and the preview.

The official copy is like the Mona Lisa under glass, the working copy you have is like a pane of glass that you can draw on and no one can see. The preview exists behind you as a preview that you can send "links" to other people who can then look "over your shoulder". This set of concepts allows people to play "what if" scenarios with their documents and web sites.

The working copy can pass through an approval process before it reaches the official copy. You may snapshot a working copy before you send a preview and only allow a preview of the snap shot. And all this can be used to version sets of documents or websites.

Toward the end of the talk Jon entertained the long term vision that the Alfresco object-version system could be used for source code control. It would allow for the implementation of different policies on how source code could be modified and worked with... and could be used to implement radically different software work patterns then what we use now.


Watching ProjectZero

I just saw this ProjectZero Demo and given that this is IBM developing the tool I'll be watching the development of this project over time. It seems that Project Zero competes with Spring. Unlike Grails which builds on top of Spring, Zero appears to create a new set of conventions and competes with Spring.

SunSpot + Lego + LeJOS + Groovy

A few ideas have been rolling around in my head for the last few weeks. For one I really like the idea of the SunSpot kit and I really like the idea of LeJOS which is Java for the Lego Mind Storm robotics kits. I am slowly finding myself becoming a Groovy fanatic too.

So, I've got this crazy idea of doing a Lego + LeJOS + Groovy + Sun Spot project just to prove it can be done. I'm just entertaining the idea right now... but I think I'll need several hundred dollars in hardware to pull off a project. I hope to turn this particular idea into more than a pipe dream but once again I'm severely resource constrained.

Anyone think I can get a grant to do this stuff?


Code Addicts in Java Land

Some one just sent me this Billy Hollis video. Billy asks us if we are "Code Heads" and although his solution is Microsoft based, it's and entertaining talk just the same. It is why we have 1.2 billion frameworks (a slight exaggeration) in the Java code space. Developers need frameworks and developers like writing them. The problem is developers don't seem to like using the other guy's framework.

Microsoft has the benefit of being "the one" and can dictate the community's direction. Few vendors have that luxury. That's one reason why Microsoft shops have an easier time making up their minds... they have no real choice.

Java shops have a myriad of choices and can decide to go any number of routes. You could go application server specific, Java standards specific, or with an open source framework. You could choose to write in a dynamic language on the JVM or in plain old Java.

The trick is to recognize when you can leverage the framework and to actually do it. Don't write the code for the sake of writing code. Use the tools in your frameworks for what they are good at.


GORM is a work of Art

I've been working in GORM a lot lately. And out of all the different ways I've ever had to make objects work with tables this is perhaps the most fun and straight forward.

My eyes kind of glaze over when people mention XML configurations and that seems to violate some deep down desire I have for all the things related to a thing... let's say a class Foo and its mapping and validation... to either be contained with in Foo or near by Foo. Spreading out validation and mapping between multiple objects related to Foo rubs me wrong.

GORM fixes this problem by using the Groovy language concepts to store this validation configuration inside the class definition. Which I like because my bias is nearly always toward code. The addition of code by convention means many of the pre-defined queries I would have been writing in EJB3 annotations are created when called.

It is the most pleasant way to do ORM I've ever seen.


Ruby on Rails: The Java web DSL

Technical evaluations aside, the longevity of a technology has more to do with the community behind it than it does with the suitability of the product. The "Sun surprise at railsconf Europe 2007" has shed some light on what the character of the Rails community may become. Justin seriously thinks this could lead to a hybrid Java/Ruby or JRuby coming of age in the near future.

That Ruby thunder is the Groovy rumbling we heard all summer. It looks like the "official" Sun Java camp may be backing the Ruby on Rails horse. In Open Source technology it isn't always the best, most feature rich, or advanced product that wins. This is probably the revelation that Sun is working from. Ruby on Rails is popular and Java can ride that train all the way into town.

The question is now, will JRuby ride its rails over Groovy or does Groovy still have a niche.

Moving from Java to Groovy is simple since most Java syntax works in Groovy. That means you only need to add on new language features and you're writing in Groovy. A very shallow and gradual learning curve for Java people. Is that enough? Is that everything?

JRuby's claim to fame will be the ability to work with EJBs and run in an "enterprise" environment. When that hype train comes into the station many things won't matter. When RoR is a full fledged member of the Java environment Ruby becomes one more Java DSL and Rails becomes one more Java web framework.

And that's a good thing. It means Ruby on Rails and Java are not mutually exclusive. It means both sides benefit. These are critical developments to watch right now because the fall out from these will greatly influence the political landscape of web development for years to come.

If Java can successfully bring Ruby into the fold we can reverse some industry killing fatal fragmentation.


Chad Fowler is my Hero now

The Big Rewrite... many koans, much wisdom, Chad is my hero now.

Ruby on Rails: Long term view

How viable is it long term?

Working in Java you know that there is a good chance that you could work in Java up to retirement. But, the nature of that job could change drastically. There is also a good chance the next ten to twenty years of that job could be spent maintaining banking software created in the last decade.

I have a rule: "Never fall in love with technology"

The reason you should never fall in love with technology is that it changes. The rules for what technology triumphs are not wholly rooted in market share, technical sophistication, or beauty either. So it is very hard to evaluate where a technology will land in the landscape of all things digital.

The one insurance policy for a developer is to "keep moving" so that they are always on to the greener fresher pastures. But this means never developing a depth of technical knowledge in any one technology stack.

Ruby on Rails is old hat by now. It has been around for several years now and has helped legitimise the LAMP stack in the minds of many traditional developers. Because Rails enforces good design standards such as MVC and Unit testing it sits well with Software Engineering types who like to see discipline in development projects. But, how is it long term? How does it look for someone deciding to build a career on it?

Let's look at why something like Java was able to enter the "Enterprise" business space.

Java was backed by Sun and Sun was big iron. The weight of Sun lent legitimacy to the Java development stack. The marketing of Java focused on "enterprise" quality solutions that conjured images of serious engineers building serious programs to with stand serious load under serious conditions. Java was serious. Seriously.

For just how serious Java was take a look at any fine book store selling computer programming books. If there is more than one shelf of "computer programming books" then you are probably going to be staring at mostly Java or Java related books. Java is everywhere. Java is in your cell phone... and that is a potentially powerful idea.

What gives Ruby any kind of weightiness in light of all that "enterprise" goodness behind Java?

Well, for one thing, look how serious Patrick Lenz is in the photo on this page for "Build Your Own Ruby on Rails Web Applications". And, then there's Amazon who uses it and they are no slouches. The other thing to keep in mind is that when we're talking Ruby we're talking open source and that changes the rules a little. After all, what is Linux? Did it have any big iron support?

So what I might actually ask when determining the long term viability of something like Ruby on Rails is not is "Ruby on Rails" viable but: is the "Ruby on Rails Community" viable? And that is a slightly different question and much more valid today.

Java has about 1.2 billion web frameworks to choose from. (A small exaggeration) The proliferation of choice means that there is enough community behind Java to create all those frameworks. Certainly enough wasted resource and talent in the community to convince someone that they were all needed whether they were wanted or not. And there is a depth of knowledge and wisdom in those development efforts that can be leveraged.

I think this is why Java is being "Open Sourced" today. It is probably an concession by Sun that it can't win the closed source battle against open source and that if the product is to survive it is on community. A vibrant open source community. A community that is leveraged by Ruby on Rails.

Every Java talk I've been to in the last year has had some mention of Ruby on Rails. It has captured the minds of many Java devotees based on its technical beauty. I think RoR actually benefits from its _lack_ of choice. Because there are fewer ways to get things done and fewer options the RoR community is more tightly focused even if they are smaller.

The bottom line is I can't say what the long term viability is for RoR. But I plan on devoting the next few days to studying it and getting a better feel for why it has taken the fancy of certain Java devotees. Why is RoR worth "burning the ships" for and never setting foot on Java land again?

Long term viability of a product in the internet age is not tied to big iron companies with crushing infrastructure. Long term viability of a product today is tied to the community. It is a fact of the internet age. So much so that Gartner believes that open source will be unavoidable.

So I don't have a conclusion for you because I haven't spent enough time in Ruby land. I'll be taking a tour this week and I'll try and render some kind of verdict on the health of the Ruby community. If someone wants to point me in a certain direction feel free.