Monday, July 27, 2009

Keys to High Performance Web Applications

I know web application performance has been discussed about 100 times before, but it bears repeating (if only briefly and mostly with links) since it is such an important topic.

If you have never tried to ensure your web application will run well then my rule #1 is to not change your application architecture. Program performance is a separate issue that rarely is a problem compared to network latency and server request overhead. I am not saying it is never a problem but you should try things that are much easier first before diving into a restructuring or a rewrite of your app (in most cases buying more hardware is cheaper and safer). As Donald Knuth says, "Premature optimization is the root of all evil (or at least most of it) in programming"

Now that you have done nothing to start (so far so good right?) it is time to do something. Get the YSlow analyzer for Firebug and run it against your web application. It will provide you with a report which you can use to identify possible performance issue. The Firebug network monitor and to a lesser extent the Safari Web Inspector are also good tools for profiling the requests on a page.
Here is a list of a few more performance apps from the RazorSpeed blog and around the web:
No discussion of web app performance would be complete without including a link to Steve Souders' blog. While you are there check out compare. Some of the results are surprising and others not so much.

Many tuning option are in the hands of your system administrator so if that is not you then you can relax a little bit. However, as a web application developer (frontend/web developer or backend engineer), you should at least know where the common problems lie and this is where the bible of web application performance (Yahoo performance rules) comes in. It is a list of best practices which can be roughly summarized as reduce requests, spread the load, utilize caching and compression, and structure pages for efficiency. If you want the shorter list then check out 14 Rules for Faster-Loading Web Sites (it is just a list of rules taken from the bible with samples). If you prefer an alternative list then try the PageSpeed rules.

If you are lucky you are using an environment that has performance tuning built in (like the grails ui performance plugin or the RockStarApps eclipse/aptana plugin) which will do most of what the performance rules suggest automatically (what can be done in the app anyway). Most web servers provide support for compression so that usually is best handled at that layer anyway. For the rest of the best practices, you will just have to learn and apply the performance rules best practices. In most cases it will be well worth your time.

Monday, July 20, 2009

JavaForge requires authn to access SVN

I went to setup an account on JavaForge for Steeple today. Everything went pretty smoothly with the initial setup. It was easy to create an account and setup a new project. The site allows for fine-grained permissions which are easy to configure and has a very nice wiki. It also included code analysis and build tools (which are why I decided to try it out in the first place).

I hit the first bump after creating the SVN repository. I could not find the URL to the respository anywhere. After searching around for ahile I figured out that the URL was:
http://svn.javaforge.com/svn/steeple

The next issue, which ended up being insurmountable, was related to access to the SVN respository. Try as I might there was no way to allow public access to it. Anyone trying to access the public URL will receive a basicauth challenge. Just to view the respository a user has to enter in the username of "anonymous" with a password of "anon". As a result I had to drop javaforge and go with my backup of google code for now.

I did post a question on the javaforge forums about this but from reading the other forum messages I think it is just not possible.

Thursday, July 16, 2009

My first week with Groovy and Grails

I spent time over the last week learning about Groovy (a dynamic language for the JVM) and Grails (a code by convention web application framework built on Groovy) so I thought I would write up my impressions and some of the fun things I learned.
So you have a sense of where I am coming from, I am a long time Web applications and Java/PHP/Javascript/Perl developer. I am somewhat newer to Python and Ruby but I prefer Python. I am a REST and Open Source advocate when I am in the right mood.

If you are totally unfamiliar with Groovy then I recommend you take a look at this post as it lays out the reasons why you might want to learn more about it:
http://codetojoy.blogspot.com/2009/06/case-for-groovy.html

If you know you are going to be writing web-apps then just skip Groovy and go straight for Grails. If you are looking to do some JSR-223 (Java Scripting) stuff (with Groovy) then Groovy is the place to focus on. Either way, you will need to get familiar with the basics of Groovy so look at these:
http://groovy.codehaus.org/Quick+Start
http://groovy.codehaus.org/Collections
Feel free to checkout some sample Groovy scripts I made which illustrate many of the key concepts.

The Getting Started Guide for Groovy is huge and not really a very good place to try to get started unfortunately. That said, the Beginners Tutorial is pretty good, especially the section on closures.

If you want to get going with Grails then it is a little bit easier since it mostly builds on Groovy. Grails borrows heavily from Ruby on Rails so if you are familiar with it then things will come to you quickly. This is the best place to start (not surprisingly):
http://www.grails.org/Quick+Start
I really liked the screencasts (which are oddly located here also). They provided a nice introduction to Grails without much effort. When you are ready for a little more the tutorials are a good next step.

Things I learned in no particular order:
  • Maven and Grails do not get along - There is some really weak maven integration available but it does not work very well. The structure of grails (e.g. src/groovy) does not match the maven standard structure (e.g. src/main/groovy). Mostly maven just allows you to run the grails build commands which is easier to do with grails itself. I struggled with this for awhile before just giving up on using maven. The Grails team recommends using Ivy if you want to add dependency management (or Grails plugins which are preferred if they are available).
    The grails and groovy artifacts are available in maven repositories which is nice.
  • Grails and Eclipse don't easily integrate - The Groovy plugin is pretty good (not great) but the build integration is pretty poor and requires you to jump through hoops. It seems like the integration with IDEA is a lot better and recommended by the Grails team.
  • Groovy supports closures - The closure support in groovy is great and very easy to use. I found myself writing closures like crazy (even more than in Javascript) and it made the code very clean.
    NOTE: I ran across one weird bug where passing in a String[] to a closure causes it to be misinterpreted as a collection of separate arguments for each array entry. There are hacks to get around this but be aware that it may bite you.
  • Grails has a great plugin system - Grails has a pretty powerful plugin system which allows easy extension of a grails app. The plugins seems to be very easy to install and fairly easy to write. There is a complete guide if you are interested in developing your own plugins.
  • Grails app creation puts in too much stuff - The structure generated by grails create-app has a lot of stuff in it which you will probably want to cleanup (like the hibernate plugin by default for example). There is no uninstall for plugins so just remove the dir of the plugin to get rid of it. Be careful to not leave in a lot of things you are not going to use and clean out the sample stuff under web-app as well.
  • Grails convention is not very flexible - Grails prides itself on "code by convention" and "convention over configuration" and it does a good job of establishing a lot of conventions. It takes a little while to get used to them but if you follow them then things are pretty easy. Unfortunately, this implies that it is possible to override the convention using configuration if needed and in many cases it is not. I have been bitten a few times already when I tried to do things that are not "on the rail".
  • Grails uses prototype.js by default - The built in javascript engine in Grails is the portal/multi-framework unfriendly prototype.js. I can't use it so I am playing around with using jQuery instead (so far this is proving to be manageable). There is a jQuery plugin which helps make this easier.
I am still getitng used to things but I am not sure what Groovy/Grails gains me over using Jython/. It seems like Jython does everything Groovy does plus it has the massive Python community for support.
As far as scripting languages go I think I prefer PHP, Javascript, Python, and Perl (in that order) over Groovy but this may just due to a lack of familiarity on my part.

Friday, July 03, 2009

Sakai AppBuilder Plugin updated to 0.8.7

The Sakai AppBuilder Eclipse Plugin is updated to a new version (0.8.80.8.7) which includes updates for Sakai K1 and support for Wicket. Many thanks to Steve Swinsburg who did all the heavy lifting on this update. You can install the plugin using instructions here or update it to the new version from within eclipse if you have installed it before.
The Sakai AppBuilder is a RAD tool that allows you to quickly create Sakai webapp projects in Eclipse that will work in the Sakai Framework. Use these as a basis for the projects that you want to make without all the busy work of creating the structures and adding in all the dependencies. You can choose various UI layer options and implementation types to get you started quickly.
NOTE: Updated for the 0.8.8 release (minor fix from 0.8.7)

Wednesday, July 01, 2009

Aptana Studio 1.2 crash and upgrading to 1.3

I recently upgraded Java to version 1.6 (build 1.6.0_13-b03-211) on my macbook pro running OSX 10.5.7 (leopard). It was a bit of a chore but it mostly sped things up and allowed me to run some of the newer apps that require Java 6.

I had a major casualty though when Aptana Studio stopped working. It would simply crash without even giving a decent error message and the logs were not helpful.I normally run the standalone version of Aptana Studio (1.2.7) which is built on eclipse 3.2. This seems to no longer run on OSX and Java 6 so I went in search of a fix. After lots of forum browsing, tweaking configurations, and reinstalling I ended up retiring version 1.2 and trying out version 1.3 (still in beta). It was hard to find the 1.3 downloads page so here is a link.

It installs quite easily and ran which was a major improvement. However, when I tried to install the features (plugins) I am used to, they all indicated that they were incompatible and would not install. This seemingly hopeless situation was actually easily fixed by updating Aptana Studio (Help -> Software Updates). Once that was done (definitely restart here) I installed the features (php, pydev, git) and plugins (epic) that I like and everything seems to work fine again.

Hopefully this will save someone a little pain.