Monday, December 24, 2007

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.

Saturday, December 22, 2007

Strings and StringBuilder optimizations

I keep running across code like this:
public String THIS = "this ";
StringBuilder sb = new StringBuilder();
sb.append("is ").append("a ");
sb.append("test: ");

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:

Saturday, December 15, 2007

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:
OpenSpaces (API/aggregation site)
GigaSpaces XAP

Friday, December 14, 2007

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.

Thursday, December 13, 2007

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.