DeBlog

Well the title has a lot of product names in it some which might not be familiar to all of you, so i’ll try to give short descriptions

• Groovy: An agile programming language inspired by ruby that compiles to Java classes, works on the JVM and integrates with existing  Java libraries. A must use for agile development and  / or prototyping.

• Ant: Apache’s build tool

• Team City: A great continous integration server by Jetbrains.

Groovy has Junit integrated with in it distribution and has the ability to run Groovy classes that extend the GroovyTestCase class directly as unit tests without the need for creating a Test Suit. This is great but when you use this method on Team City (or anyother CI server i presume) you cannot see how many tests passed, and how many faile. So here’s the work around I use to get over this issue:

• I create a target in my build.xml that compiles all the groovy source code and copies it to a test folder

• I have another target that compiles all the unit test code and copies them to the same test folder

• Then I have Ant’s Junit task batch test all off the code with the filter *Test.class. Using this filter is important because Junit will go around looking for Java files as default.

When you deploy this on Team City and use the ant build runner, TC will show you your test stats.

Here is an excerpt from the build.xml file

<target name="compile" depends="init">
<groovyc srcdir="." destdir="../sandbox" classpathref="classpath"/>
<groovyc srcdir="../tests" destdir="../sandbox" classpath="classpath"/>
</target>
<target name="test" depends="compile">
<junit fork="no" haltonfailure="yes" maxmemory="512">
<jvmarg value="-Xmx512m"/>
<classpath refid="classpath"/>
<formatter type="brief" usefile="false"/>
<batchtest>
<fileset dir="../sandbox" includes="**/*Test.class"/>
</batchtest>
</junit>
</target>


One of the primary goals of weblaster was to have a fast javascript based application to manage a media collection.
The amount of data we are talking about is an array with around 35.000 elements that contain something like this:

{
"id":"10098",
"track_name":"Sarah Yellin'",
"album_name":"Live Away From The Sun",
"artist_name":"3 Doors Down"
}

that’s around 110 bytes per element times 35K nearly 400K of Javascript. If you load this data with an ajax call, the browser will hog your CPU until Firefox goes gray and won’t recover. (Tested on a 4th generation Macbook Pro with 2 GB RAM, 2.4 Core duo. Believe me, even that can’t handle it). The slowness of eval() is to blame for this. You just can’t eval() such a large array, without blocking the browser. The solution that I used in weblaster for this problem was to embed the array into the page it self. The first few lines in the index.php file shows this.

<script type="text/javascript">
tracks = <?= echo json_encode(data); ?>
</script>

This way the array is loaded and parsed during the execution of the scripts on the page in the current runtime.

Another optimization technique that is well known is the reverse style array iteration. When iterating over large arrays, looking up the arrays length on the conditional check of the for loop is a large performance hit, especially if the array is a global variable.

So the iteration over the arrays are like this:

for (i=array.length-1;i>=0;i++) {
 do_something();
}

Not that I need it but just to squeeze every penny from my mac book pro 4,1 (Penryn):
First enable the MacTel repositories in your

/etc/apt/sources.list

file:

deb http://ppa.launchpad.net/mactel-support/ubuntu intrepid main

then a

apt-get update

and finally install the hal-applesmc for the mactel stuff.
Now add the applesmc to your

/etc/modules

file to load the module at boot time or just

modprobe applesmc

to load it now.
This should make the f1/f2 function keys adjust the LCD brightness. Pressing f5/f6 didn’t switch on the keyboard back light for me but

echo 100 | sudo tee  /sys/class/leds/smc\:\:kbd_backlight/brightness

seems to do the trick.