techno.blog("Dion")

Wow it keeps on coming (and ironically I am adding to it). This last slew of postings on Rails vs. Java came after Patrick Peak Rails: Where are the Implications for “No Deploying”?.

As soon as that came out we saw:

• Dave Thomas: Rails and FUD
• DHH: Letting cooler minds prevail
• Jamis Buck: Application Deployment with Rails
• James Duncan Davidson: Rails: Sandbox, Develop, and Deploy
• Patrick Lightbody: It’s the tools, stupid!

The funny thing is that it is hard to know what we are really arguing about :)

Scalability

Can Rails scale? Sure. As Brian McCallister just said, scalability isn’t about a particular language.

Do the different languages/platforms give you different implementation choices for scaling? Sure. Scaling with FCGI clusters is different to using Tangosol Coherence in a J2EE cluster.

In some ways it is much simpler to scale a web app with shared nothing. However, on really huge enterprise systems (not web apps), tools *like* Coherence really help you out. It is nice to have the many levels and buttons available in your architecture.

Again, Slashdot? Scales like a champ with Perl. There are a lot of huge enterprise Java systems that take in billions of transactions.

So, conclusion? You can make both scale. You can make both run like a dog :)

Tools

Patrick has some good points in his post. I am not sure if he has checked out Textmate for doing Ruby development. It is quite nice indeed, although I do miss IDEA for some things (can’t beat its refactoring etc).

With Ruby you really don’t need as MUCH tooling though. It is a nice concise language which doesn’t need as much scaffolding in the tools area. You can be very productive with Ruby – IDEA.

However, IDEA really does do a good job of getting you closer to the productivity. I notice this a lot in Groovy world, and I am excited about GroovyJ.

Tool support is only one leg on the chair though. There are many other components that matter as much, more-so, and maybe not as much.

Refresh, Reload

Tools can help get around the dev cycle that we have in Java, but we aren’t there yet. Patrick is correct in spotting the potential with dynamic languages on the JVM, where we could get the best of both. But we aren’t quite there yet.

It is painful to jump to the Java world once you are used to hitting SAVE and refresh for every type of change (we can get far w/ JSP, etc etc).

Both are beautiful, both can be ugly

I love both platforms in many ways. I don’t like both platforms in others.

• Java Dion: I wish we had the Ruby language on the JVM.
• Ruby Dion: I wish Ruby had a nice VM to run on (the JVM would be really nice).

Or maybe I will just do everything in JavaScript 2.0? ;)

Oh, and David Geary had too much caffeine at the Rails Cafe? :)

JavaScript Embedded in Java 6A brief view into the history via this Sun Java 6 announcement, shows us that in the next Java 6 build, we will have Mozilla Rhino baked in.

Another language-related JSR planned for Mustang is JSR 223. This defines a framework to allow scripting language programs to access information developed in the Java platform. We currently plan to integrate this into Mustang for b40. Aside from the framework, we will also include a JavaScript engine based on the Mozilla Rhino implementation. Later, we hope to include a scripting shell that is script language independent. This will be a very cool way to create a prototype, do some exploratory coding, and learn new APIs.

First, we had a client (browser), that had both a Java VM and a JavaScript interpretter. Now, we have the same on the server-side of things.

This is pretty huge, and will spark more development in scripting languages, and JavaScript itself. Now there is no barrier to install anything, and you will had JS out of the box.

ECMAScript 4 XML is in Rhino. This means that we can leave the DOM (and friends) behind, and can use E4X right away!

It was good to hear that IntelliJ IDEA 5.0 is coming soon.

I am excited about some of the features like native SVN support etc, but to be honest what I really am into, is the JavaScript support.

At the moment, Visual Studio (Whidbey) has an awesome HTML/JavaScript story. You can select what browsers/standards you want to target and completion filters to the features supported by your set.

Now I won’t have to leave the world of IDEA to get my JavaScript support!

A lot of developers ‘poo poo’ any code that is written in JavaScript.

• “JavaScript isn’t a real programming language”
• “JavaScript is just about browser hacker scripts”
• “You can use it to focus(). Big deal.”
• “JavaScript is for the HTML designers, not for REAL coders”

Giving thought to your JavaScript code

As such, any JavaScript code in a project, doesn’t get the thought that it deserves. Why would you be anal about unit testing your Java code, and ignoring your JavaScript code?

You no longer need too, as we have JsUnit, and other tools.

Dependencies are dependencies

As soon as you stop thinking of your JavaScript code as a bastard step-child, you can apply the same practices that we have in our other worlds (e.g. Java).

One of the problems with Java web applications, is that you can often do a search for files on a developers hard drive, and see MANY of the same files.

For example, you search for struts.jar, and there are 23 instances of it on the file system. Of course, they are not all the same size, since they are various versions (but you don’t know).

We get around that problem by using a tool such as Maven, or Ivy.

Now, we can define our project dependencies, and the correct versions are tracked, and downloaded automatically. Very nice.

WEB-INF/lib == /scripts

Why don’t we do this with JavaScript code? We have the same problem with commonscript.js as we do with struts.jar. So why not manage it?

Maven JS type

Maven has the base framework that we need to make this quite trivial. First, we can just agree on the ‘type’ of dependency. I am using js. Then you can just add dependencies as per normal:

<dependency>
<groupId>adigio</groupId>
<artifactId>xhr-test</artifactId>
<version>0.1</version>
<type>js</type>
</dependency>

This means that maven will try to grab:

/[groupId]/[type]s/[artifactId]-[version].[type]

or in the example above:

/adigio/jss/xhr-text-0.1.js

from the various repositories that you have setup in your project.properties:

maven.repo.remote=http://adigio.com/maven,http://www.ibiblio.org/maven,http://www.codeczar.com/maven,http://xdoclet.sourceforge.net/repository,http://dist.codehaus.org

NOTE: ‘[type]s’ is hard-coded. There is no way to map “when you see type ‘js’ look in directory ’scripts’, or something like that. This means that ‘jss’ looks a lil’ silly :).

maven-war-javascript

So, we didn’t have to do anything to get Maven to start grabbing dependencies for us. But, in our projects we don’t just want to grab some JavaScript modules and put them in your local repository. We want to use them :)

Rather than writing some manual goals to handle this, I wrote a Maven plugin which piggy-backs on the war plugin.

The maven-war-javascript-plugin offers a war:js / war:js:copy-scripts goal. This manually looks through your dependencies, and copies any JavaScript modules to your web app (in the scripts directory by default. To change, use the maven.war.javascript.dir property).

However, although you have a goal in which you can kick off this task, in practice you don’t need to use it. The plugin registers itself with the war module, and whenever it is invoked, it sneaks in and does the copy. So, it is a seemless introduction!

Installation

To download and install the plugin, you can simply:

• Add: http://www.adigio.com/maven to maven.repo.remote
• Run the commmand: % maven -DartifactId=maven-war-javascript-plugin -DgroupId=adigio -Dversion=0.1 plugin:download

Conclusion

So, now I can take JavaScript more seriously, and can start managing my JS dependencies with the care and loving touch that I do with the immense amount of open source library bloat :)

From Ajaxian.com

A friend pointed me to a (seemingly old) project called XMLTerm. XMLTerm is a mozilla based “A graphical command line interface”.

At first you may laugh, and ignore some of the security implications for now, but this could actually be quite cool.

Ajax could also come in to really help this out.

Some thoughts:

• % du: When you do a ‘du’, wouldn’t it be cool to show a pie chart usage as well as the numbers?
• % ssh [TAB]: tcsh came up with the ‘complete’ command, which lets you get smart with your tabbing. We can take that to a new level with a bit of UI integration. If you hit TAB after typing a command that needs a host (e.g. ssh, scp) then a select list can appear with your list of hosts
• % history: Since we can place cool widgets in places, we could have a history bar which would allow you to click on an item to rerun it. Command Line Suggest could also get pulled up if you TAB at the beginning of a command, showing a drop down on history.

The XMLTerm site itself has ideas on graphical ls which shows thumbnails, and a special cat which groks HTML, images, etc.

In theory, this could be an interesting marriage of the command line interface (power), and richer functionality (not just text).

Ben and I have had great feedback from the presentations that we have given on Ajax, so we created Ajaxian.com, as a place to talk about all things Ajax.

For instance, today we wrote about Handling usability concerns, such as the back/forward buttons, and bookmarking in the browser.

The entry talks about the opensource Dojo Toolkit, and its new bind() mechanism.

If you check out Instant Edit you see an example of changing a couple of pieces of content on a web page.

What if you extrapolate that a little, and think of a Confluence Wiki?

Wouldn’t it be amazing, if I could be viewing my Confluence install, and on any page I can just double click, or ctrl-click, or something… to open up the area that I am on in edit mode.

Then I type in my changes, drag an image to the area, and it is all saved.

This is a holy grail of Wiki for me. No software needed. WYSIWYG. Simple enough for non-techies to work with (even CamelCase is too much for some ;).

Another example is Live Preview. Right now, there could be a preview pane, and as you type, it groks your Wiki Syntax and converts to the HTML view… all on the fly!

I made a prediction around Google AdSense and their usage of XHR.

I also see some interesting things revolving around offline clients with JavaScript.

One of the goals of RSSBling, was that Ben and I wanted to show that you could cut the plug and it would still continue to work. This is a problem that many people have worked on, including Adam Bosworth with Alchemy (where did that go?) when he was still at BEA.

With JavaScript, and the right signed code with permissions, you can actually really go offline mode.

Imagine if you could use GMail in offline mode? That would be killer. The biggest problem with that context is the size of the data, so it would actually be harder there than other apps where you could really just save out the state to disk in JSON format, and read it right in again later!

I currently never see a Google Ad from AdSense. This is because I have installed AdBlock for Firefox.

I have blocked the iframe, and nothing from the google ad servers is shown.

How can Google get around this problem? One solution would be to use XmlHttpRequest:

• Have XHR go back to the servers to get the ad content
• Add this content to a <div> dynamically

Of course, this isn’t a solution. We could then block those div elements based on IDs. So, Google would probably want to randomly create div ids for the content.

Also, there are many other possibilities. The ads could change dynamically based on:

• Where you are on the page
• If you are mouse over a div with a given rel tag, the ad could change to something relevant to that area even
• “Those who were here, also went there”
• etc..

You tend to see a lot of copy ‘n paste reuse in JavaScript usage. It just seems to be that kind of mentality. One example of this, is asking for ‘permissions’ from the browser that you may do when building a rich application.

For example, Ben and I had to do this for RSSBling (rich javascript RSS viewer with dynamic offline capabilities).

Security Management with Mozilla

Mozilla needs permission to open up the platform (such as reading from disk, writing to disk, talking to different hosts, etc).

This is where you can sign your code.

You need to ask permission to use these features, which can look something like:

try {
if (netscape.security.PrivilegeManager.enablePrivilege) {
netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead');
}
} catch (ex) { // eat it
}

Security Code Duplication

You often see duplication such as:

function getFeeds() {
try {
if (netscape.security.PrivilegeManager.enablePrivilege) {
netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead');
}
} catch (ex) { // eat it
}

var xhr = new XMLHttpRequest();
xhr.open("GET", ((useProxy) ? proxyBaseUrl : "http://") + baseUrl + "/listsubs", true);
xhr.onreadystatechange = function() {
parseFeeds(xhr);
};
xhr.send(null);
}

function buildFeeds(feedXML) {
showLoading();

try {
if (netscape.security.PrivilegeManager.enablePrivilege) {
netscape.security.PrivilegeManager.enablePrivilege('UniversalBrowserRead');
}
} catch (ex) { // eat it
}

var outlines = feedXML.getElementsByTagName('outline');

...
}

etc etc, duplicating the security piece

Security Code Encapsulation

Firstly, we don’t want to have all of those lines of code. You could fall into the trap of coming up with:

function securePrivilege(priv) {
// insert the try/catch code from above, plus anything for the other browsers
}

Then you could make sure that you call securePrivilege('UniversalBrowserRead') before you need it. This will not work at all, as the way that enablePrivilege does its job, is that the privilege that you secure, is only applied in that scope. This means that the priviledge is only even around INSIDE securePrivilege(priv), and is thus useless :)

Security Code Encapsulation with Closures

Luckily, JavaScript has some nice features which allow us to get around this problem. What you can end up doing, instead of calling securePrivilege(..), you call a method which:

• Takes the function to call
• Sets up the priviledge
• Calls the function

This could look something like this:

function applyPriviledge(priviledge, functionCallback) {
// -- enablePriviledge first
try {
if (netscape.security.PrivilegeManager.enablePrivilege) {
netscape.security.PrivilegeManager.enablePrivilege(priviledge);
}
} catch (ex) { // eat it
}

// -- Call the function itself
functionCallback()
}

// -- Helper functions for particular priviledges
function applyReadPriviledge(functionCallback) {
applyPriviledge('UniversalBrowserRead', functionCallback);
}

You would use this with something like:

function getCount() {
applyReadPriviledge(setupXHR);
}

function setupXHR() {

var xhr = new XMLHttpRequest();
xhr.open("GET", "http://sqlaop.com/xhr/counter.jsp", true);
xhr.onreadystatechange = function() {
countCallback(xhr);
}
xhr.send(null);
}

function countCallback(xhr) {
if (xhr.readyState == 4) {
if (xhr.status == 200) {
applyReadPriviledge(function() {
updateCountDom(xhr.responseXML)
});
} else if (xhr.status == 401) {
alert("Username or password incorrect");
} else {
alert("Some kind of HTTP-related glitch occured.");
}
}
}

Encapsulated, but not rid of the cross cutting concern

This is certainly a lot nicer than copying and pasting the lines of code all over, but wouldn’t it be nice if I could say:

Whenever I make a call to XMLHttpRequest, or working with a DOM back from it, or … then please apply the security first

What am I asking for? Well. JavaScript AOP of course! ;)