Marcin's Dev Info

Integrating SyntaxHighlighter with Blogger

2008-01-15T00:08:00.000+00:00

I've just found a quick and easy way of integrating SyntaxHighlighter with Blogger. Go and check this blog entry and start posting coloured code snippets!

Two things to note though. If your theme uses background images for <li> elements, you will have to apply this patch to your CSS:


div.dp-highlighter li {
  background-image: none;
}

Otherwise each line of your code snippets will start with a background image as it is coded with an <li> element.

Finally, if you copy and paste the whole javascript from step 2 your syntax highlighting will only support the following languages:

Cpp
CShapr
CSS
Java
JScript
Sql
Xml

Syntax Highlighter supports more, for example Ruby, Delphi or VB. If you want to use any of them, you can do this by adding an extra line like this (for Ruby):


<script src='http://[YOUR HOST]/shBrushRuby.js' type='text/javascript'/>

Firefox 3 Beta 1 passes the Second Acid Test

2007-11-27T21:10:00.000+00:00

I was quite excited when Firefox 3 Beta 1 was released a few days ago - for at least two reasons.

The first thing I thought about the other day was the memory - I was hoping I will read something about it in the release notes, as the second version of the browser can consume lots of MB of RAM. By the way, I am not sure what the world record is, but here you can see Firefox at 1.8 GB. Therefore, it was really nice to find out that "over 300 individual memory leaks have been plugged"!

The first thing I did though after installing FF 3 Beta 1 was to see how it does with the second acid test and whether it can be as perfect as Opera is. And to my surprise, Firefox is actually perfect! Finally, it renders the correct 'face':

Just after that test I read about rendering improvements in CSS in the release notes. Well done the Firefox dev team! For me as a web developer that is a really good news.

How Many HTML Elements Can You Name in 5 Minutes?

2007-11-23T17:25:00.000+00:00

NetBeans 6.0 Beta 1 and custom Tomcat

2007-09-17T22:14:00.000+00:00

I've just installed the first beta version of NetBeans 6.0, which was released today. Just out of curiosity, to see how it looks, performs and whether or not there is something better than Eclipse has. It was the full pack including Java SE, Web & Java EE, Mobility, SOA, Ruby, C/C++ and GlassFish. I decided not to install Tomcat as I had it already. To be honest, I got surprised before I even started using it ...

The installation took a long while, about 3, maybe 5 minutes. It was the full installation, so fair enough, though still don't understand why it has to take so long. Eclipse can be installed just by unzipping it to a directory of your choice and that's it. +1 for Eclipse.

NetBeans 6.0 requires about 400 MB for the full installation, plus 140 for GlassFish, if you choose to install it. Quite a lot, however my Eclipse 3.3 takes about the same size with the latest patches and the following plug-ins: Subclipse, Spring IDE, Tomcat , Maven 2, Web Tools and PMD.

The biggest surprise, however, was Tomcat integration. As I mentioned before, I chose to use my own Tomcat, so the first thing I did after startup was to add it to the servers. Here I got an odd warning saying that I might have problems running Tomcat as the startup scripts are missing (due to the windows installation which does not include these). The 'add server' wizard closed down, Tomcat was added successfully. When I tried to start it I understood what the warning was all about:

You must be joking, I thought. That's ridiculous! Why the Tomcat plug-in in Eclipse can start any Tomcat since version 3.3 (including my Windows-based) without any startup scripts, and NetBeans simply can not?! I don't believe the NetBeans team don't know that they can use bootstrap.jar instead. And guess what, all the instructions how to use it are in catalina.bat!

After that, I decided not to play with NetBeans 6.0 Beta 1 any more. And if there is anything I am going to uninstall is definitely not Tomcat, but NetBeans.

Oh, and one more thing. Does anyone know why NetBeans reads my floppy disk on startup and exit? Does it search for the missing catalina.bat??

Learning GigaSpaces at Financial Times

2007-08-16T22:25:00.000+00:00

If someone had told me that I was going to work at Financial Times at one day, I would never have believed...

It is happening now, I've just joined a project for the FT where some of the work is going to be done at the client's office! The funny thing is that I have been passing FT's building on my bicycle for the last one year or so and have never even thought that I might work at that place.

Today I spent my first day at FT learning GigaSpaces and OpenSpaces. Yet another stuff I have never thought I might need to learn in my career! Especially that I am slowly thinking of doing RoR development (after a couple of years of Java). Now it looks like I will be doing Java for another couple of months, if not for a year. Even so, I think it is worth having GigaSpaces in my CV!

Anyway, I am not an expert here, but it sounds like a very promising solution for a highly performant, scalable and distributed application. Something the FT need!

Firefox at 1.8 GB of RAM

2007-07-15T22:07:00.000+00:00

One of the reasons why I hate Firefox is the memory that it uses. It needs about 100MB - 200MB for 10 tabs, or even more if one of these is Gmail or Google Reader. If you open more tabs and switch quickly between them etc, the browser just slows down and needs a restart.

But this is actually nothing compared to what Firefox managed to do today. I was navigating Google maps with about 10 other tabs opened at the same time, when this happend:

My box has 'only' 2 gigs of RAM. I guess Firefox would have used even more if there was more to use ...

Luckily, I didn't have to restart my box, just the browser ;-)

Grails 0.5.5 - testing controllers with Mocks and Expando

2007-06-03T23:13:00.000+00:00

In this blog entry I would like to show you how to unit test a typical 'update' action in Grails using Groovy Mocks and the ExpandoMetaClass.

Let's assume we have an action like this:

 
 def updateword = {
     def word = Word.get( params.word_id )
     if(word) {
         word.pl = params.word_translation
         if(word.save()) {
             render("OK")
         }
         else {
             render("Error updating word")
         }
     }
     else {
         render("Word does not exist")
     }
 }

In brief, it updates a Word instance by getting a Word from the database, modifying its 'pl' property and saving it back to the database.

Now, how would you unit test the execution path where the "Error updating word" message gets rendered? To do that, you need a scenario where a Word instance gets returned from the database but fails to save back after the update operation. Here is how you can do it using Mocks and Expandos:

 void testUpdateExistingWordSaveFailure() {
     def mock = new MockFor(Word)
     def fakeWord = new Expando(save: {false})
 
     mock.demand.get { fakeWord }
     mock.use {
         def wc = new WordController()
         wc.params.word_translation = "tak"
         wc.updateword()
         assertEquals "Error updating word", 
                      wc.response.delegate.contentAsString
     }
 }

The flow of the test is as follows:

Create a mock for the Word class
Craete a fake word instance (Expando) which replaces the 'save' method
Demand the Word class to return the faked word when the get method is called (exactly once)
Use the mock and call the updateword closure
Assert if the correct message was rendered to the browser

See the Unit & Integration Testing Controllers page to understand the last step - getting a text from the response.

Grails 0.5 Unit Testing - other issues

2007-05-26T17:04:00.000+00:00

I have mentioned already about slow unit testing in Grails 0.5. Apart from that, there are several other bugs:

Luckily, there are workarounds for all these bugs (good news if you are stuck). Check the grails-user group for more details (clicking one of the bugs above should take you to the description and solution).

The good news is, that all the issues seem to be fixed in the current 0.5.5 snapshot (downloaded on 26th of May)! Suggest that you give it a go, or even upgrade your projects to version 0.5.5.

Be careful however when upgrading to 0.5.5. Tests have been moved from 'grails-tests' to 'test' folder, therefore 'grails test-app' will give you:

No tests found in test/unit to execute ...
No tests found in test/integration to execute ...

As you can see, tests have been separated into two categories: unit and integration. I have noticed however, that unit tests for domain classes are being generated under the 'integration' test folder. Looks like a new bug, though more likely that the test separation has not been fully implemented (and tested :)) yet.

Update: Actually, it is not a bug. Typical unit tests for domain classes in Grails are in fact integration tests with all the dynamic methods and properties injected by the framework. Plain unit tests can be created, too by running the grails create-unit-test command. Read more on the Grails Unit Testing page.

Grails Unit Testing not agile

2007-05-21T20:54:00.000+00:00

Don't be surprised if you give Grails unit testing a try. I've done that recently and must say it is not agile at all. At least not yet (Grails 0.5).

As for now, it takes approximately 25 sec on a pretty fast box (my PC is a 3.2 GHz Dual Core with 2GB RAM, Os WinXp) to run a single unit test. Why so long? Surely, unit tests should run faster.

Update: I've just run grails test-app on my new Ubuntu 7.04. To my surprise, a single unit test run takes only 17 sec. That's a big difference comparing to 25 sec on WinXp.

I have found the answer on the grails user group. Graeme Rocher, the project lead of Grails, in reply to a similar issue says:

"We're separating out unit and integration tests so that unt tests will
run quicker. At the moment every test is an integration test, hence
why it takes long to bootstrap" (Graeme's post)

The slow unit testing should be improved in Grails 0.5.5, as Graeme is working on improvements to that. Can't wait to try this out as TDD on Grails can be really exciting then!

Apart from that there is another small issue, though. Some have already experienced that (see this post on the grails-user group), too. If a unit test fails it does not tell you what went wrong. All you can see is the 'test failed' message. Quite confusing, especially if you are used to JUnit's detailed error messages.

Luckily, you can find the cause. Again, the grails-user group is where I've found the answer. The detailed test reports sit under target/test-reports folder. They are available in different formats, including plain text, xml and html. You can find the detailed message there, plus a very long stack trace ;-) The only trouble is that you waste even more time finding the cause of a unit test failure...

And here I can give one hint that makes it faster. If you open one of the detailed reports in a text editor that checks for file modifications, it would reload the report automatically after each test run ;-)

Joke on Rails

2007-05-19T19:48:00.000+00:00

Just inside the gates of heaven, St. Peter sits at a desk checking people in.

Peter: .Welcome to heaven. Programming language?.

The man at the front of the line says, .Smalltalk..

Glancing at his clipboard, Peter says, .Room 33. Be very quiet as you pass Room Six..

The process repeats itself with the next person in line:

Peter: .Welcome to heaven. Programming language?.

Person #2: .Common Lisp..

Peter: .Room 17. Be very quiet as you pass Room Six..

The next person moves to the front of the line with a look of curiosity on her face.

Peter: .Welcome to heaven. Programming language?.

Person #3: .Python..

Peter: .Room 54. Be very quiet as you pass Room Six..

Person #3: .Why do you keep telling us to be quiet as we pass Room Six?.

Peter: .Because the Ruby on Rails People are in Room Six, and they think they're the only ones here.

Found here.

TDD on Rails on Mac

2007-05-10T23:16:00.000+00:00

Together with Andrew, we had an instructive TDD session on Rails yesterday. It was quite a new experience especially for me as I had never had a Mac in my hands before :). It took me about 2 hours to get used to it. However, there is still one thing I don't like and can't understand - where is the 'Del' button on Mac??!! Hope there is a good explanation for not having it ...

Anyway, we started from scratch repeating the 15 TDD steps to get the basic app running. The app itself is very simple - a kind of english/polish dictionary with the guess/learn option. The next thing after the 15th step was to add some content to the database so the user can play around and have fun guessing new words. Andrew talks in more detail in his last post how we tested and implemented that. I must admit however that it was a real fun for a (still!) Java programmer like me to switch to Ruby for a while. Just see how little code we had to write to achieve the following:

check if a Word has a translation


def translated?
  pl and en
end

return a random and translated word


def self.random
  (Word.find(:all).select {|word| word.translated?}.sort_by {rand})[0]
end

Can you imagine how would this code be implemented in Java?

Having done some TDD before I realized again what really matters when you test drive your application. TDD changes the way of thinking of the code you are going to write. As Andrew said, it is all about design, not necessarily about testing itself. The tests you write is some sort of (positive) side effect - you just get them as you go along.

The other thing I'd like to mention here is YAGNI (You Arent Gonna Need It). Perhaps a bit off topic, nevertheless that's what came to my mind yesterday, too.
Having written many lines of good looking and performing code I had to stop worrying about code like this:


(Word.find(:all).select {|word| word.translated?}.sort_by {rand})[0]

Certainly getting all the words from the database does not look nice at first glance. But have a think - is that really going to work very slow and cause any problems? Not really, unless you have hundreds or thousands of users, which doesn't happen so quickly. So don't bother until this becomes a real problem. And what is the most important here - be productive and don't waste your precious time for improvements that don't have any business value.

Groovy in System Tray

2007-01-16T23:30:00.000+00:00

As of Java 1.6 there is a cool feature available - System Tray. Actually, System Trasy plus nice notifications which look like a balloon on Windows. Now you can put Duke next to your favorite icons, if you like!

An example source code is available on the java docs page. Indeed, it is an example and even not a fully working one. I am not going to rewrite it - I believe Sun it works. Instead, I will try making the code more ... groovy ;-)

Here it is, System Tray example in Groovy:


import java.awt.Image
import java.awt.AWTException
import java.awt.MenuItem
import java.awt.PopupMenu
import java.awt.SystemTray
import java.awt.Toolkit
import java.awt.TrayIcon

def trayIcon = null

def exit = { e ->
  println "Exiting ..."
  System.exit(0)
}

def showMessage = { e ->
  trayIcon.displayMessage("Action Event",
                        "An Action Event Has Been Peformed!",
                        TrayIcon.MessageType.INFO)
}

if (SystemTray.isSupported()) {
  def tray = SystemTray.getSystemTray()

  def image = Toolkit.getDefaultToolkit().
                        getImage("duke16.gif")

  def popup = new PopupMenu()
  popup.add(new MenuItem(label:"Exit", actionPerformed:exit))

  trayIcon = new TrayIcon(image:image, tooltip:"Tray Demo",
                          popup:popup, imageAutoSize:true,
                          actionPerformed:showMessage)
  try {
    tray.add(trayIcon)
  } catch (AWTException e) {
    println e
  }
} else {
  prinltn "System Tray not supported"
}

As you can see it is possible to make Duke shout: Groovy did it! However, the code looks more like java. And what is worse, I am afraid we can't make it more groovy, using Swing Builder (the popup menu could be 'built'). The Tray functionality sits under java.awt package, which the Swing Builder does not support I think (well, it did not work for me). Luckily, we can still use Groovy's closures instead of Action Listeners.

Nevertheless, it works fine and - what is worth stressing here - it is platform independent! I have run the example successfully on GNOME, KDE and Win Xp desktops. Here are my screenshots:

GNOME

KDE

Windows Xp

And two Dukes, if you would like to run the example on your desktop

Oh, and one more thing. If you are curious what other dynamic languages support System Tray, my friend, Andrzej, shows how to do this in Iron Python. See his article here.

Groovy at work - developing a GUI build tool

2007-01-11T22:46:00.000+00:00

Suppose you have a complicated Ant build which builds your latest code from SVN. It is very complicated and running it requires a set of parameters to be passed into it. This involves creating and maintaining a set of properties files and probably also batch files which start the build as you don't want to manually type in all props every time. Also, source files need to be updated before running the build. Does it not sound like a tough manual and repeatable work?

How about a simple GUI where you could type in (or even choose from drop downs, if possible) required properties and run the build by clicking one button? Yes, why not, but we don't want to waste two weeks or more writing such a tool, in Swing for example. Ok, how about Groovy and its brilliant features, like SwingBuilder, AntBuilder and closures? Hmm, that sounds much better!

Recently I have developed such a GUI build tool using Groovy. It took me 2 days to code it. Now guess what features it has:

full checkout from SVN to a local directory
project update before each build
running the old Ant build, written in XML
intercepting build output for error messages
reading tool properties from an external XML config

All in about 350 lines of groovy code! Most of the code are SwingBuilder closures where I am building the GUI and AntBuilder doing the build job. The most interesting parts however are:

Defining external svn ant task
To get that to work some additional jars are needed. Assuming they are under local lib directory, the svn ant task can be defined like that:


def PATH = "task.path"
ant.path(id:PATH) {
  ant.pathelement(location:"lib/ganymed.jar")
  ant.pathelement(location:"lib/svnkit.jar")
  ant.pathelement(location:"lib/svnant.jar")
  ant.pathelement(location:"lib/svnClientAdapter.jar")
  ant.pathelement(location:"lib/svnkit-javahl.jar")
}
ant.taskdef(
  resource:"org/tigris/subversion/svnant/svnantlib.xml",
  classpathref:PATH)

Accessing SVN
Now, having the svn ant task defined, accessing svn (checkout, update etc.) is as easy as:


def svnCall = { task ->
  ant.svn(username:USER, password:PASS) {
   task()
  }
}

where the task can be svn checkout:


svnCall {
  ant.checkout(url:url, destpath:dest)
}

or svn update:


svnCall {
  ant.update(dir:dest)
}

As you can see there is no code duplication. The ant.svn call is common for all svn tasks. I am passing a closure as a parameter into it, which then can call ant.checkout or ant.update. Closures - it's brilliant, isn't it?

Running an external Ant build and reading output info.
The XML ant build needs to be started from command line (no, we are not going to rewrite it using Gant, not yet ;-) ). How do we do this in Grooovy?


def build = "cmd /c ant -f build.xml
        -propertyfile build.properties target".execute()

The build variable is actually a Process instance, so we can now intercept the in and err streams:


build.in.eachLine { line ->
  //consume each line
}

build.err.eachLine { line ->
  //consume each line
}

Why intercepting the err stream? Well, if the build fails Ant writes BUILD FAILED + the error to that stream. Then I can show an info message using JOptionPane as MsgBOX:


import javax.swing.JOptionPane as MsgBOX
...
MsgBOX.showMessageDialog(gui, message, title,
                     MsgBOX.INFORMATION_MESSAGE)

The build tool
To give you an idea what the build tool looks like, here is a screenshot (I have removed real labels/data) :

Title borders, drop downs, text fields, labels and box layout - all in 2 days? Yep, plus event handling for all the combo boxes, which make up some sort of hierarchy, actually. This makes the tool a bit complicated, but not the code! Event handling is as easy as clicking a button (actionPerformed as a closure):


def comboBox = swing.comboBox(items:items,
                          actionPerformed:action)

and the hierarchy is read from an external XML file, using Groovy's XML parser:


def XML = new File(xmlFile).getText()
root = new XmlParser().parseText(XML)

Nice and simple, isn't it?

Summary
It was such a pleasure writing the tool, in no time actually. I have to admit that it was my first bigger piece of Groovy code, which now really works fine in my company! What else can I say - thank you, Groovy! You saved me at least a week of swing coding in Java!