David Van Couvering 's Blog

December 2006 Archives

Moving to NetBeans

After five years working with the Database Technology team at Clustra and here at Sun, I'm changing jobs and will now be working with the NetBeans team, focusing on (you guessed it) database tooling.

I'm not sure exactly what I'll be doing yet, but I know what I'll be doing first: pulling down the code, getting it to build, reading architecture and design docs, meeting with lots of people.

I've already checked out the code and got it to build -- pretty darn easy, Coming from Derby where we use subversion, it was kind of hard moving back to cvs -- I'm hoping at some point NetBeans will migrate over.

One thing I like already about the NetBeans code base is it is very consciously structured into independent modules. This is an approach I have always liked, it helps keep the coupling between areas in your system very loose and light. I have tried to sell this model to other teams I have worked with, but with limited success -- restructuring an existing code base into modules is hard.

Another interesting thing is that NetBeans is built with NetBeans. Each module has its own nbproject directory that contains the project for that module. I tried pulling the db project into NetBeans 5.5 but it failed. I was informed that right now you have to use a NetBeans build from the trunk to build NetBeans from the trunk. Hm... that all feels a little risky and circular to me, but I guess it works... There is always ant if nothing else works.

Anyway, I'm excited to be in this new area, it's actually more in line with my own interests. I also get the opportunity to bring expertise into the team while at the same time having the chance to learn a lot of new technology. I've been a back-end guy most of my career, and all these phrases like "container" and "layout manager" and "panel" are a bit Greek to me. Wish me luck!

Market Prediction of Schedule Dates

Mark Hedlund of O'Reilly recalls the great story I heard once before of a Microsoft team that used an anonymous trading market to predict the release date of the product.

I tentatively tried suggesting this once to my project team and was laughed out of the conference room. But I do wish we would do this more, I think it would give our release dates a lot more predictability and reliability, and management could plan much better.

It's funny how sometimes people think you're joking when you're serious...

Window shopping and Java web applications

In a previous post I talked about the potential for using a rich client runtime like Java to provide a better experience for web users and a simpler and more productive experience for web developers. But this can raise a concern: what do you do about Google spiders and getting attention from search engines? If your "web site" is embedded in Java, how does Google find you?

Anne Zelenka recently discussed some myths about Flash. One of them is the concern that Flash "hides" your content, thus disabling search engines from finding your site. This problem exists for any web application that provides functionality dynamically (JavaScript, Flash, Java, ActiveX/.Net) rather than pure HTML content.

Anne refers to an article that discusses this issue in more detail and gives you tips on how your dynamic app can still be available to search engines.

The main point is that you can (and probably should) keep your content separate from your style and behavior. You can then make this content available for web clients that don't use or look at Java, Flash or JavaScript (like a Google spider crawling your site).

For example, if you have a rich-client calendaring app, then if a spider goes to your URL, you provide an HTML version of your calendar. You can have a rich-client music player, but a spider or someone just "checking you out" can go to your URL and find a nice presentation of your service with updated content.

I think of it as the difference between someone walking down the street window shopping, versus someone going into your store and wanting to try on clothes, push buttons, taste the fruit, and interact with your salespeople. For web applications, the browser and HTML can be used for "window shoppers" while a rich client model can be used for committed users who want to have a richer, more interactive experience of your service.

Some care must be put into how you migrate a window shopper to a committed user with as little effort as possible, so they don't just walk away. It should be as easy as opening a door and walking in.

Java has not been very good at this transition -- it's been more like having to wait in line and pass through a security checkpoint before you can enter the store. This has improved significantly, particularly with Java Web Start, but there is still a ways to go until Java has the same level of graceful transition as Flash and JavaScript, I believe the Java VM is ultimately the better platform, and I believe we can fix these remaining barriers to entry. That's the vision I'm holding, anyway. Now that Java is open source, I'm even more hopeful this can happen.

Glassfish, Ruby on Rails and Derby

Thanks to a plug from Ludo I found out that Ashish and the JRuby folks have done some interesting work to show how you can run Ruby on Rails in Glassfish.

What I like is that in this environment, because JRuby is written in Java, it's very easy for you to use Derby as the database for your RoR application.

What will they think of next?!

P2P a major force in Internet Traffic

This blog in the Long Tail shows an impressive trend of P2P traffic, where it is growing in leaps and bounds and in 2004 was 60% of all Internet traffice, with BitTorrent in the lead at 30% of this traffic (in 2005 eDonkey has taken over as the leader).

During the World Cup, I tried to use Azureus to do a BitTorrent download of a game I missed. I was stunned at how I had to leave my computer naked to the world - turn off firewalls, open up ports. I actually was never able to get it to work, but I also was turned off from P2P because of the security risks involved.

Am I missing something, or are folks doing P2P file sharing (all legal, of course) willing to bare themselves to all the insidious trojan horses and worms constantly seeking unprotected computers on the Internet?

Web 2.0 Without the Browser

Tim O'Reilly recently had a very interesting blog as a followup to his comment on Kathy Sierra's blog about why Web 2.0 is not a buzzword. The point that Tim made here that got me thinking was his comment that Web 2.0 is just the latest in a series of names, and the vision stays the same. Tim says "what I'm really talking about isn't the web at all, or not just the web, but the movement of technology towards the global internet as platform, and all that means."

I totally agree. The principles behind Tim's definition of Web 2.0 has very little to do with AJAX or DHTML or even the browser. It has to do with a way of building and delivering applications that is enabled by these technologies, but which is not defined by them.

That got me thinking, well, how can we envision another way of delivering "Web 2.0" functionality? To me the current way of building web apps is pretty broken. It's complex, it's heavyweight, it requires understanding a vast amount of technology, from HTML to JavaScript to PHP/JSP/Perl/Ruby/Java. It's just a huge spaghetti of stuff to learn. As a result, frameworks have proliferated to try and handle this complexity. It also doesn't make any sense to me that web servers are mostly in the business of delivering dynamically generated text markup. And what's the reason behind all of this? As far as I can see, the primary reason is because the browser was not initially intended to serve up dynamic applications.

In the meantime, the user experience has degraded significantly. AJAX and other technologies have made the browser much more dynamic and engaging, but it's still just trying to catch up with what we already had before with standard "thick" client applications.

With an architecture where the presentation code is written purely in code, and not a combination of code and markup, and is delivered as a single simple download to run in a real language runtime, then things can be simplified significantly. The communication between the client and the server won't be these masses of presentation markups and scripting, but basic business operations. The server can do what it does best: pump through thousands of business operations a second. The client CPUs can be put to work rendering the user interface and providing dynamic interaction with the user. Applications written this way can make much better use of server resources and as a result yield significantly more scalable solutions.

What's stopping this from happening today? I think there are two major issues. First of all, getting client-side code deployed to the server has been slow, complex, and broken. Java Web Start and Flash are solving this, and I think this can only improve over time (especially now that Java is open-source).

The other reason is that 3GL languages like Java have been unpopular in the web space because the kind of person who builds web apps generally does not have the background or patience to learn a 3GL. They want to get something up and running fast. I would love to see our IDEs focus on delivering thick client apps using drag-and-drop application building as well as a combination of 3GL and scripting languages. We need to make it easy for web developers to quickly build rich, dynamic apps that do not rely on the browser and all its limitations.

Just a plug: having a local data store like Apache Derby or dojo.storage is also key to this approach, as it allows the client to manage local state locally, rather than having to depend upon the server to do it. This allows the client/server communication to stay focused on what really needs to be sent to the server: transactions, rather than the little steps along the way that lead to a transaction.

Web 2.0 is a great thing. A read-write Internet platform and the power of collaboration and community to create value is still a huge benefit and a major change in the way we use computers and the Internet. But that doesn't mean we have to continue to build applications in this strange arcane way that has evolved since the late nineties because we're trying to shove dynamic content into a vehicle that was built for static text.

Dealing with the Devil

I discovered Robert Cringely's column/blog when I saw a link to his blog talking about Project Blackbox and how he had predicted something like this last year.

His latest blog is a mixture of great topics, but the part that made me laugh and sort of cry was his experience dealing with big ISPs. His experiences rang true for me, as I was sucked into the Earthlink maelstrom about four years ago because my local service, slip.net, was acquired, and then that company was acquired by Earthlink. It's like being pulled into the Death Star by a tractor beam.

My experiences with Earthlink can confirm that they would do such a thing as Cringely claims: lose email and not tell you. My hair got 20% grayer the year I had Earthlink and regularly had to deal with their support. After a consistent thirty to forty minute wait, I would get a level one support person with no experience and with a robot-like approach to problem-solving. Just as an example, every time I worked with them they required me to unplug my Linksys router and install their insidious networking software (that basically took my machine to its knees) before they were willing to help me, even if my problem was obviously unrelated to the router. I think they hated that I could have two machines connected to the same ISP connection.

And then there was my experience with AOL when I was at a home exchange last year. I found myself at one point in a three-way conference call between myself, AOL in India and Linksys in the Phillipines, and they were arguing with each other over thousands of miles about whose fault it was. I felt I was in one of Dante's levels of hell.

The sun was shining and the birds were singing the day I finally switched to , a local ISP based up in Sonoma County. I found them through the excellent site, dslreports.com. Their ratings were so high that I found it hard to believe. The folks at Sonic are amazing. When they signed me up, they sent me daily emails telling me of the status. I would call support, and in three rings I had an actual knowledgeable expert on the phone who had the tools at his or her fingertips to diagnose and fix my problem. And downtime? I think I've ben down twice, once because my own telephone wire went on the fritz, and they helped me track that one down too.

I regularly see Comcast offering amazing deals and speed. Phone, cable and Internet combined. Or AT&T/Yahoo! DSL for just $25 a month. Sometimes I think about switching, but not for long. I think of my experiences, and the experiences of others, with the Big Guys, and I just shudder. So I stay with Sonic, pay the slightly higher prices, and pray to the God of Mergers and Acquisitions that they will never get acquired.

They are one of the members of the Rebel Alliance, fighting the Empire of Bad Support. May the Force be with you.

This work is licensed under a Creative Commons License.