Silverlight

I was roaming around the web and ran into a web application that used Silverlight this weekend. I did a little investigating and this weems to be Microsoft's answer for Flash and Rich Internet Applications in general. They make a lot of interesting claims about cross browser compatibility (IE, Firefox, and Safari) and compatibility with existing backends and AJAX. The big score for it though seems to be the claim that it is fully accessible and that the toolkit helps you make your apps more accessible and l10n. Overall, it looks pretty compelling and fairly easy to learn so I plan to keep an eye on it and see where it goes.

Main websites:
http://silverlight.net/
http://www.microsoft.com/silverlight/

A really cool use of Silverlight:
http://www.microsoft.com/silverlight/halo3.aspx

A blog/analysis of it from a developer prespective:
http://www.gskinner.com/blog/archives/2007/05/a_flash_of_silv.html

A demo/interview of Silverlight on Youtube:
http://www.youtube.com/watch?v=JEUrQEj6Sd4

Linux related project (Moonlight):
http://www.mono-project.com/Moonlight

Related (competing) projects:
Adobe AIR: http://labs.adobe.com/technologies/air/
Google Gears: http://code.google.com/apis/gears/

Working with Twitter

I have been playing with Twitter a little bit recently. It is a service that allows you share what you are doing with people via little messages. I can just be used for fun, but it can also be a valuable way to keep up with coworkers and colleagues. Updates can be sent via the website, IM, or even SMS texts from your phone.
I have been experimenting with the facebook integration and it is pretty good (via the TwitterSync app). This is the best way I have found to keep your facebook status synced up with Twitter.
I am most curious to see how use of twitter in a professional setting evolves. I think it could be a great way for split project team members to keep up with each other.

Strings and StringBuilder optimizations

I keep running across code like this:

public String THIS = "this ";
...
StringBuilder sb = new StringBuilder();
sb.append(THIS);
sb.append("is ").append("a ");
sb.append("test: ");
sb.append(5);

It is hard to read and maintain, and wastes the time of the developer who wrote it because there is basically no benefit to writing it. The (Sun) Java compiler will do some optimizations which end up allowing coders to write nicer looking code and avoid lots of extra typing or copy and paste. Let's rewrite the same code the way we would like to if we were not trying to over optimize.

  String test = THIS + "is " + "a " + "test: " + 5;

That's easier to read and the compiler turns this into a StringBuilder anyway. It is easily prove n by runing this code through a debugger and tracing it.
There is another related trick that the compiler will do for Strings.

  String test = "this " + "is " + "a " + "test: " + 5;

That becomes "this is a test: 5" in the bytecode (this is in the language spec). Very easy to read and zero cost at runtime.

As always, the old rule of thumb applies. Always optimize last (or never). Readable and maintainable code is far more important that a minor optimization which possibly saves a few nanoseconds (and in this case saves none).

Before anyone gets the wrong impression, there are perfectly viable cases for writing StringBuilders in your code. Creating a string from a large number of smaller strings within a loop is the most common use case. For example:

StringBuilder sb = new StringBuilder();
sb.append("Counting: ");
for (int i = 0; i <>
 sb.append(" ").append(i);
}
String test = sb.toString();

In this case, using a single string and writing += would be more costly and should be avoided for any code that will run often.

NOTE: There is a pitfall here that one can fall into fairly easily. This example of what NOT to do shows how easy this is:

StringBuilder sb = new StringBuilder();
sb.append("Counting: ");
for (int i = 0; i <>
 sb.append(" " + i + " ");
}
String test = sb.toString();

In this case, there will be a new StringBuilder created for each iteration through the loop. Do not use "+" concatenation with variables inside the loop (as shown inside the inner append above). This will end up producing another StringBuilder if there is a variable (it is fine if you are using constants). The loss from the creation of many additional StringBuilder objects will offset the gains from using the outer StringBuilder.

sb.append(" " + i + " ");

is efficiently written (when inside a loop) as:

sb.append(" ").append(i).append(" ");

The rule of thumb I use is that if I am concatenating strings on a single line of code then I use "+", otherwise I use a StringBuilder. I sometimes break that rule if I am just concatenating on 2 or 3 lines and the code would be more readable if I used "+" (since the savings are so small in that case).

For those of you runing Java 1.4, the optimization is still there but uses StringBuffer instead.

The key takeaway here is that writing readable and maintainable code should always be a priority over writing optimized code and this is one case where the compiler makes that a little bit easier on the developer.

A few helpful related links for more in depth study:
http://nicklothian.com/blog/2005/06/09/on-java-string-concatenation/
http://java.sun.com/developer/JDCTechTips/2002/tt0305.html
http://www.precisejava.com/javaperf/j2se/StringAndStringBuffer.htm

Scaling Java with Grids and Clouds

There has been a lot of talk about using grids and spaces to handle large scale java applications at The Spring Experience 2007. The compelling thing about this for me is the idea that these applications allow architects to abstract the concept of clustering. Developers can effectively program as if they are running on a single server (with some minor APIs here and there depending on the solution). Most solutions scale up very well and provide failover support.

These solutions are being recommended as production ready solutions and apparently large companies (like banks) are already using them in massive scale production. It will be interesting to see how these impact Java enterprise development in the future.

Here are some of the solutions I heard mentioned at TSE 2007:
Terracota
OpenSpaces (API/aggregation site)
GigaSpaces XAP
Coherence
ObjectGrid

Spring Dynamic Modules

Adrian Colyer did an incredible demo of Spring OSGi at The Spring Experience on Friday, 14 Dec, 2007 to show the things that are up and coming. The demo included a 3 layer app (web, logic, dao) running with each layer as a separate module in OSGi. During the demo he intentionally shutdown the logic module, clicked a link on the web page, restarted the logic module, and then went back to the page which had magically worked without failing. Apparently Spring OSGi will proxy the layers until a timeout is reached or the module can restart. This allows some amazing things (like upgrades without server shutown). It can also control access to the modules so they can effectively operate in a hierarchy. I think they said it should be released in a few months.

On a side note, Adrian and Rob did a great keynote with some singing and roleplaying. It was easily the best keynote I have ever seen. Cheers to all who planned and executed it.

The Spring Experience and RSF

I am attending the Spring Expereience in Hollywood, Florida this week (Dec 14, 2007) along with Antranig. It is exciting and scary to be around so many really great developers. It feels like everyone we talk to is doing something impressive and advanced with Spring. It is pretty intimidating to be around and talk to all these really great developers.

The sesssions have been really great so far. It is really hard to decide which sessions to attend because there have been a few slots where I wanted to attend all five talks. The presenters have actually written code in front of people which is great to see. I have had a chance to learn about the new Spring annotations, AspectJ, @MVC, and Testing. The material is advanced but that is what I want.

Antranig and I presented a rapid fire session on RSF. It was a one hour introduction to the goals and basics of RSF. We had a bit of technical trouble and the talk before us ran long but overall I felt really positive about the session. There were lots of good questions and we had about 25 people in the session. We even got a compliment on the wiki and documentation. I hope we will have a chance to talk with more people about RSF during the remainder of the conference.

Validating CSS online

I recently had a problem with a webapp where things were showing up but I could not figure out why. The CSS seemed correct at a glance but someone else had written it so I was not very familiar with it. After struggling for awhile I did the smart thing and asked Gonzalo Silverio if he had any ideas (which of course, he did). He pointed me to this awesome CSS validator at http://jigsaw.w3.org/css-validator/. You can upload a css file or simply provide a URL to the file and it will give you a nice little report that tells you what is wrong.
A similar service for validating your markup is available at http://validator.w3.org/.

Roadmaps, Kernels, and Community?

There has been a bit of traffic on the mailing lists about Kernels and Sakai community processes recently. I personally hope that it will encourage more open communication in the community and more transparency around decision making. I have high hopes that some of the proposals I have posted in the Sakai Dev space on Sakai Confluence will spark conversations and encourage people to get involved in various framework improvement efforts.

In particular, I am hoping the following things are worked out BEFORE or AT the Sakai conference in December.
1) What does the Sakai Roadmap look like?
2) What is a framework team? What does it do? Who are the initial members?
3) How does the voting process work in Sakai and what kinds of things should be voted on?
4) Do we have a Sakai Kernel and if so, what does that mean (what is it)?
5) Should we have a code approval process for the Sakai framework and what should it look like?

What are the right answers to these questions? Frankly, that is outside my core area of expertise which is mostly designing and writing software. I have some proposals out there in the hopes that someone smarter will come along and rip them apart and replace them with something that is better. Even if that doesn't happen, I hope they will at least encourage discussion. Isn't that how we arrive at decisions that will benefit us all as a community? I mean, we don't really need someone to make all the decisions for us and tell us what to do... do we?

Sakai AppBuilder 0.82 available

Version 0.82 of the Sakai AppBuilder is now available on the Sakai eclipse update site (http://source.sakaiproject.org/appbuilder/update/). This version will now generate maven 1 project files and maven 2 pom files and will create the links to the local repository for the eclipse classpath for either maven 1 or 2. This also includes updates to the most recent jars being used with Sakai including the recent release of RSF 0.7.2RC1.

Cafe trunk using Maven 2

The cafe trunk distribution for Sakai is finally working and available for download. The cafe distribution is part of the Sakai programmers cafe and the primary goal is to create a smaller distribution which makes development in Sakai easy and reduces the memory footprint. This is the first cafe distro available which uses Maven 2 (like the rest of Sakai). The really notable thing about this cafe is that it is the smallest one yet (in terms of projects) and probably the smallest distribution of Sakai currently available.

Ian Boston and I have been tracking down intra-project dependencies in Sakai and removing them in order to create a small and clean kernel for Sakai. This cleanup has resulted in a better kernel and will eventually lead to a more solid service foundation in Sakai. The cafe distribution represents that kernel distribution plus the standard Sakai portal (charon). It should make development in Sakai easier and faster since restarts should take less time and there are less projects to checkout and keep up to date.

In order to make this distribution for Sakai with Maven 2 we had to create a special base pom that lists only the projects in the distribution. We are use svn externals to setup the download of the correct projects from the main Sakai source tree. There is one bit of hackery involved with getting this to work which is needed if only part of the project is desired (for example, we can only use parts of the user project since some parts pull in undesirable dependencies). This involves creating a new base pom for the main project (user) and then removing the modules from that pom file which are not included in the externals. We did this for 4 projects in the cafe distribution.