Wednesday, September 15, 2010

Sending text like a pro

These are great tools for sending chunks of text around to others. If you are a developer and used to using IM then tools like these are invaluable since they make your content readable or protect it from prying eyes.
  1. Pastebin (
    Full featured, well supported, and fast. Pastebin has been around for awhile and has some very nifty options like automatic support for subdomains (e.g., format highlight support, expiration, and even limited privacy settings.
  2. Privnote (
    This is great for sending someone a password, id number, or anything that you do not want to send over the open wire or via email. Once the user clicks the link and views the content it is deleted.
    The formatting of the text is lost here though so it is not good for sending formatted text.
  3. Private Paste (
    An excellent tool for sending along large blocks of formatted text that you do not want others to see. This supports expiration, format highlights and line numbering, and security key auth.

Wednesday, March 03, 2010

EuroSakai: Sakai QA and How to get Involved

Alan Berg, Anthony Whyte, Jean-François Lévêque, and I finished our final two presentations at the EuroSakai Valencia 2010 conference today. The overall theme of these presentations was "Get Involved". The presentations are What is Sakai QA and 10 ways to make a good Sakai release (my apologies to the attendees but 8:30am is just too early for a session). I hope that our main point got across and I hope we provided helpful information for those brave enough to attend.
A few highlights for those who could not make it:
  • Alan did another Mexican wave
  • I (and others) was still half asleep during the morning session
  • Jean-François made a lot of food related jokes
  • lolcatz were involved
Our major theme was "Blood and Treasure" (stolen from Anthony Whyte). If you have assets (people) then you have blood to contribute. If you are looking for ways to get involved please consider these opportunities. If you answer yes to any of these questions, or even if you don't, you may want to sign up to participate in one of these teams.
  • Sakai Maintenance Team - are you a java developer? an SVN wizard? want to learn more about Sakai codebase? do you love issue management and/or JIRA? do you like to write unit tests?
  • Release Management - are you a master of subversion? do you have a passion for merging code? are you running a 2.*.x branch in production?
  • Quality Assurance - can you use a web browser? do you like trying every little thing in software? are you tired of hearing complaints from users after you upgrade?
The other primary and very critical way to get involved is with treasure. If you have some money you can spend on open source and/or Sakai then you have treasure. Consider putting this money into foundation dues or buying into commercial support. Check out the end of the What is Sakai QA presentation for a few options to get involved when you have money but no people (or if you have money AND people).
One final point from our talk. If you are involved, thank you. If you see others who are involved, please thank them.

Tuesday, March 02, 2010

EuroSakai Bootcamp

Anthony Whyte and I presented the programmers cafe bootcamp at EuroSakai Valencia 2010 on Monday March 1st. This also coincided with my first official act as a Uniconer (short for Unicon employee) and my first presentation as the Sakai Maintenance Team lead.
We had around 30 people in attendance with the majority from Spain. I felt like it went as well as these 1 day technical introductions to Sakai can reasonably go (i.e. a major overload for the participants) and I hope that the attendees had a good experience and learned something valuable. Anyone who wants to let us know what they thought of it can fill out our survey.

EuroSakai presentation - Sakai Best Practices

Alan Berg and I just finished our presentation on Sakai Best Practices at EuroSakai Valencia 2010. It started with a mexican wave (all Alan's fantastic idea) and included tips for creating JIRA tickets, an overview of best ways to take advantage of foundation resources, and some development best practices.
One key point we made during the presentation bears repeating. In many ways the Sakai community is a do-ocracy.
A do-ocracy is an organizational structure in which individuals choose roles and tasks for themselves and execute them. Responsibilities attach to people who do the work, rather than elected or selected officials.
I have also heard people refer to Sakai as a meritocracy and perhaps in some ways it is. But much more than that I think it is driven forward by those willing to act. I hope that we are encouraging people to get involved and act because that is the lifeblood of community source.

Friday, August 28, 2009

Helpful online tools

These are a bunch of online tools which I find indispensable when I need to do some quick validation, encoding, or formatting/indenting.
  1. XML escaping -
  2. XML indenting (critical when trying to read ugly XML) -
  3. JSlint (javascript code checker) -
  4. JSONlint (JSON validator and formatter) -
  5. W3C HTML validator -
  6. W3C CSS validator -
  7. WDG tools (web validators) -
  8. XHTML/CSS page validator -
  9. shell tools (xml, base64, md5/sha1, and more) -
Hope this list of tools is helpful!

Saturday, August 08, 2009

Easy license headers with maven

If you are like me you probably hate trying to maintain license headers on your source code files. It has to be done for pretty much all of my projects (since I deal in open source 99% of the time) but it is pure drudgery. I found a great plugin for maven 2 which makes this a piece of cake (very easy). The maven-license-plugin can (optionally) check your source files for headers (you control which ones or just use the defaults) and add in or replace the headers for you. Forget about doing this manually anymore; those days are over. You just specify a license header template like this (i.e. create a file, I use LICENSE_HEADER):

Copyright (C) ${year} ${holder} <${contact}>

This file is part of ${name}.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
See the License for the specific language governing permissions and
limitations under the License.

Then add something like this to your project pom.xml (in the build section under plugins):

<holder>Aaron Zeckoski</holder>

You need to add in the plugin repo in the pluginRepositories section:


That config will cause the check to run on every build (ignoring properties files is a good idea since the plugin has trouble with them). Files with a missing license header will cause the build to fail ensuring you remember to run the command to format them. The properties you set there will fill in the ${field} vars in the license header template.

Now run the maven command to check for license headers:
mvn license:check
or simply do a build (which will also run the check):
mvn clean install
You should get a report about the files missing license headers.
Run this command and all the license headers will be added or updated to match your template:
mvn license:format
One final note, you can remove all the license headers using "mvn license:remove". Very cool.

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:

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:

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:
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):
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.

Saturday, July 04, 2009

Sakai AppBuilder Plugin updated to 0.8.7

The Sakai AppBuilder Eclipse Plugin is updated to a new version ( 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)