techno.blog("Dion")

I read through Wired on the plane. In fact, I use Wired as a barometer on how much I am traveling. If I go to the airport and there IS NOT a new Wired for me to pick up, I know I am traveling too much.

Anyway, I perused the article on 37signals which did a good job on not being a total love-fest. It is one of those articles where you take out of it what you thought before. If you think they are arrogant gits you will say “yup, arrogant gits”. If you think they are doing great things for the industry, you will continue to think that too.

It did make me think about how great we had things a couple of years back when Rails was red hot. There was that brief time where you tons of people were saying “Wow, I am going to choose Rails for my next application”. The alpha masses from Java, PHP, ASP, all checked it out.

Now though? They are moving on to check out other solutions. Many frameworks have copied some of the good things from Rails that make sense in their worlds. Now when I think about the next toy to play with, I have a large set of potential “cool looking” frameworks to try.

For such a brief time, life was easy.

I hate the fear ads, and seeing the Clinton one was sad to see. Showing pictures of kids etc… are you kidding me?

I know Hilary is scrapping for her life, but still. I really don’t understand the experience line too, since she has only been a Senator for a few years. How she comes up with 32 years baffles me.

Anyway, it all reminded me of the fear-monging around Rails scaling.

I have been a long time follower of Steve Yegge and his long blog entries that manage to keep your attention. He has the opposite style to me (I know how curt and bad my writing style is!), so I envy it a little.

Ever since he presented on the ‘Google Rails Clone’ at FooCamp and posted about the internal Google Rhino on Rails project, people have been curious to learn more.

• What does it mean to port Rails to JavaScript?
• What can’t you do since JavaScript doesn’t have the same meta programming facilities?
• Rails = a group of Active*, so did you re-implement everything?
• What do you gain out of having JavaScript all the way down?
• Does it actually make sense to have jjs? Server side JavaScript generating client side JavaScript? Argh!
• What is the state of Rhino?
• Will Rhino support JavaScript 2?
• How does the JVM help you out?
• What are the ramifications of implementing ActiveRecord with Hibernate
• Fun other languages to play with

And of course, the big questions:

When do I get to see it!

I happen to be in Seattle at the Google offices, so I was able to ask all of these questions and more. Steve was a fantastic host, and I really enjoyed chatting with him.

This is the kind of video I want to explore at Google. We have many great developers working on cool technology. I want to get them on camera, participating with the community when I can. Sometimes we can talk about products and APIs, but sometimes we will talk about fun ideas and projects that we are working on such as Rhino on Rails.

Anyway, give it a watch and let me know what you think:

Michael Mahemoff has been playing with server side JavaScript too.

I too haven’t heard of half of the list of Server Side JavaScript frameworks on Wikipedia, although it is certainly interesting to remember that Netscape did JavaScript on the server waaaay back in time.

At the same time, Aptana is trying to define an “Ajax server” with todays release of Jaxer. At first glimpse you can see some of the other frameworks, but it certainly is doing a lot more.

Michael hits on one of the key points when he talks about deployment:

Try finding a virtual host that supports Javascript! You would practically need one that support Java, so you can run Rhino or whatever, and few virtual hosts do that. At least Python and Ruby were running on many virtual hosts before Django and Rails showed up. For that reason, the model pursued by AppJet seems worthy. If they can come up with a solid virtualisation environment for Javascript, they may be on to a big winner.

I want to be able to hit “DEPLOY” or “PUBLISH” and have that be the only way I interact with production applications from now on (with the ability to roll back and scale out). When someone nails that, we will see a lot of applications coming out.

Maybe TheServerSide.com should become “Your JavaScript Community”?

Brad was speaking on a panel at a recent conference and asked a couple of questions, and the answers visually said it all:

Raise your hand if your business relies on the Web in some way:

Raise your hand if you think that the Web is moving fast enough as a development platform:

One of the comments on the Notification API was by lunatix:

It would be really useful if we could set a background javascript process (via WorkerPool) that continue to run after browser is closed and which is able to send System Tray notification.

I would definitely like to see an API (or as part of the Notification API, or WorkerPool in general) that allows you to attach some work to a process that can always be running, or be scheduled to run (a la cron).

This can be particularly important with Offline and syncing that comes along with it. Imagine a world where Gmail worked offline. The need for a service that downloads email in the background may not be that important, as people tend to leave a tab with Gmail running in it.

But, if you take Zoho Writer as another example. You may not have Writer open all the time. You open it when you get a new document that you want to work with. Let’s take a look at a scenario:

• Bob edits a shared document that discusses the travel for the next quarter
• Bob closes the document and keeps working for the rest of the day
• Meanwhile, Harry, Linda, and Chou all edit the document
• Bob goes offline and heads to the airport
• Bob opens up the document on the plane

Does Bob just have the document with content from his step? If there was a service that was running in the background, it could detect the changes and bring them down. Then Bob would have the latest and greatest up to when he turned off his computer.

The obvious issues

Of course, a key issue here will be making sure that this isn’t abused, and what UI do we give users. I personally never like it when I find services running on my machine when I closed an app. You know the culprits…. Quicktime and the like. I want to be able to know about every service and prune the list, but also not be burdensome for the average Joe. Does this mean that the system tray notification system has a way to see all of the services?

Also, I don’t want some rogue daemon taking up my resources, and of course, it can’t have special access to things such as key logging ;)

You can write Gears too!

A few people have emailed me about potential Gears saying that they wish they could build a new Gear. Remember, Gears is a true open source project, so you CAN write your own Gears. If you want to implement a new API, start out by emailing the group with your proposal and then get to it!

Other Future APIs

• Notification API
• Crypto API
• Developer Tools
• Factory API updates
• Blob API
• Logging API
• Messaging API
• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

Disclaimer: This is me rambling about APIs and tools that I would love to see in Gears, or the Open Web as a whole. Do you have ideas for cool Gears that make the Web better? Let us know!.

Back in the day, I was the first person to know, and care about version 2.6.1 of FooBar, the open source framework that does everything that you need.

For one, as editor-in-chief of TheServerSide, it was my job to be on top of things.

For two, I actually cared. The playing field was fun, there was a lot of innovation. It was a brave new world.

Fast forward to 2006, and I am the anti-framework releaser. If I never see “YetAnotherMVC 1.2 Released” announcement on TSS and others, it will be too soon.

Isn’t it just so BORING? Partially, I think I hit the end of the road on keeping up with the Jones’. At the end of the day I want to get my job done. I want to produce business functionality for my clients. ROI and all that garbage.

Now, I am living part of my life in the land of the UI. What has excited me about this land, is that when I develop a great Web UI for a client I can:

- Show my wife, and she can see that it is cool. Telling her (totally non-technical thank god) that I refactored my 3-tier backend using ALL of the GoF patterns isn’t a turn on. Neither is showing her a web page, but at least she can get it.
- Same for the client: Watching clients say “wow” is worth it. The backend is very important, but the front end is big too.

So, I am officially bored of all of the server side framework crap. I do listen for some things. Every Dojo/Prototype/Scriptaculous release makes me look, as so much has been added, because they are so young.

Aren’t you kinda bored too?

Matt Raible is look for large sites powered by Java web frameworks.

Maybe I am in a cranky mood, but I wouldn’t worry about scaling out the web tier.

You can scale JSF just fine (although I may not like JSF at all ;)

Slashdot does just fine with Perl + memcached.

Your scalability concerns are going to come in with your architecture, and caching.

If the bottleneck is in taking the HTTP info in, parsing it into objects, and the on the back-end doing the opposite, then you have done an amazing job scaling the database and the network layers.

Of course we need to test our architectures etc, but I have just seen a PHP application that handles a massive load, with an average architecture :)

It handled everything just fine because of the caching they use.

This is why TheServerSide.com running on EJB etc was/is such a hilarious thing. Tapestry isn’t the bottleneck ;)

And with 64 processors each with 64-cores, CPU bound scalability probably won’t be the case often too!

Use the tech that gets out of your way and feels right to you. This is why Rails is doing so well.

The troops are showing signs of grouping together. Java has been under attack from other platforms. We have the ASP.NET side, and now the main source of discussion, the dynamic language side (principally Rails, but also Django/TurboGear/etc etc).

The Java side knows that in-fighting isn’t good anymore, so we are seeing more and more of the groups working together.

At first the troops gathered around the Java Web Alignment Group, a loose affiliation where nothing has really happened (it is very new).

I think it was a “we should work together!” cry, with no hard action items.

The Spring guys saw JBoss Seam, and talk of Clarity came together (along with other folks).

I certainly feel that there is room for common Java stacks, and Spring is a project that can pull this off.

Now, even more recently, a new force has entered the fray. It is the joining of WebWork and Struts. The WebWork guys have already been working with the Struts TI guys (using XWork), and I think it is a great fit.

Struts has the name. WebWork has the technology.

I can’t wait to see what comes out of the Struts Action Framework 2.0.

It is important times for Java frameworks, to see if they can compete with the simplicity and productivity of some of the other frameworks (including some of their own like RIFE).

Let the games begin.

It was great to see an email from Eddie O’Neil from BEA, announcing the Apache Beehive final 1.0 release.

I got to work on an Apache Beehive project, and was very impressed with certain parts and pieces. This may be a 1.0 release, but remember that it has been around for awhile in production projects such as Portal, and Workshop.

Nice work lads!

We are pleased to announce the v1.0 release of Apache Beehive!

This release provides the following major features:

• NetUI (Page Flow + JSP tag library)
• Controls framework
• System controls for accessing JDBC, JMS, and EJB resources
• Many bug fixes
• Significantly enhanced documentation
• Additional samples

Binary and source distributions can be downloaded via an Apache mirror from:

http://beehive.apache.org/releases/release-1.0.cgi

Documentation for v1.0 is here:

http://beehive.apache.org/docs/1.0

A few notes about this release:

* WSM and the web service control are not included as WSM has not passed the JSR 181 TCK yet. Both will be available in a subsequent release.
* v1.0 does not include XMLBeans due to licensing issues with the JSR
173 API JAR; however, XMLBeans can still be used with Beehive and is available from http://xmlbeans.apache.org
* Changes in v1.0 from v1.0m1 can be found here:
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10570&fixfor=12310123
* Thanks to everyone who submitted bug reports, patches, testing, and feedback. All of these contributed significantly to this release.
* Please send comments / questions about this release to user@beehive.apache.org and development-related issues to dev@beehive.apache.org
* Bugs found in 1.0 should be filed in JIRA at http://issues.apache.org/jira/browse/BEEHIVE
* This version was built at SVN change 291405.

We welcome your feedback.

On to v.next…

The Beehive Team