Juri's TechBlog: 06/01/2009

My name is Juri Strumpflohner and this is my technical blog. I'm a kind of jun. software architect, .Net, Android, Web and Java dev, TDD and best practices promoter and martial arts practitioner.

Firefox 3.5

Here's a short video of the director of the Firefox development team showing the new features in version 3.5 which should be available soon (these days actually).

MIDlet for downloading image from the web

J2ME provides several ways for creating an Image object:

Image.createImage(String)
Image.createImage(byte[], int, int)
Image.createImage(InputStream)

If you want to download an image from the web to your local J2ME application, you - of course - have to establish an HttpConnection and retrieve the image with a simple GET.
As I noticed, most programmers then open the InputStream by calling httpConn.openInputStream() and process it inside a while loop, storing the read bytes in a ByteArrayOutputStream or similar for then being able to create the image, using the 2nd method illustrated at the beginning. This approach is shown here for instance.
But knowing the 3rd method for loading an image directly from an InputStream, this could be achieved in a much easier way:

public void run() {
 HttpConnection connection;
 try {
  connection = (HttpConnection) Connector.open(this.imageUrl);
  connection.setRequestMethod(HttpConnection.GET);
   
  Image img = Image.createImage(connection.openInputStream());

  //do something with the image
 } catch (IOException e) {
  // TODO Auto-generated catch block
  e.printStackTrace();
 }
}

Note, the operation of establishing an HttpConnection, fetching the image etc is done within a separate thread (see best practices). Of course the code above needs some tuning, this is just a simple example to demonstrate the topic.

Here's a MIDlet which follows this approach:

package com.tests.images;

import java.io.IOException;
import javax.microedition.io.Connector;
import javax.microedition.io.HttpConnection;
import javax.microedition.lcdui.Command;
import javax.microedition.lcdui.CommandListener;
import javax.microedition.lcdui.Displayable;
import javax.microedition.lcdui.Form;
import javax.microedition.lcdui.Image;
import javax.microedition.lcdui.TextField;
import javax.microedition.lcdui.Ticker;

public class ImageForm extends Form implements CommandListener {
 private TextField imageUrlField;
 private Command loadImage;

 public ImageForm() {
  super("Image Viewer");
  init();
 }

 private void init() {
  imageUrlField = new TextField("Image URL", "", 999, TextField.URL);
  this.append(imageUrlField);

  loadImage = new Command("Load Image", Command.SCREEN, 1);
  this.addCommand(loadImage);

  this.setCommandListener(this);
 }

 public void showLoadedImage(Image image) {
  if(this.size() == 2)
   this.delete(1);
  this.imageUrlField.setString("");
  this.append(image);
  this.setTicker(null);
 }

 public void commandAction(Command c, Displayable d) {
  if (c == loadImage) {
   this.setTicker(new Ticker("loading image"));
   
   ImageLoaderManager imgMan = new ImageLoaderManager(imageUrlField.getString(), this);
   Thread t = new Thread(imgMan);
   t.start();
  }
 }

}

class ImageLoaderManager implements Runnable {
 private String imageUrl;
 private ImageForm parent;

 ImageLoaderManager(String imageUrl, ImageForm parent) {
  this.imageUrl = imageUrl;
  this.parent = parent;
 }

 public void run() {
  HttpConnection connection;
  try {
   connection = (HttpConnection) Connector.open(this.imageUrl);
   connection.setRequestMethod(HttpConnection.GET);
   
   parent.showLoadedImage(Image.createImage(connection.openInputStream()));
  } catch (IOException e) {
   // TODO Auto-generated catch block
   e.printStackTrace();
  }
 }
}

iGoogle Gadget: Stackoverflow Profile View

Are you a member of Stackoverflow.com and you want to track your profile such as your reputation or earned badges? A couple of days ago I've submitted an iGoogle gadget that makes this easy. Here's a screenshot and some further links.

Gadget project site
Official iGoogle directory entry

Did you know the "Joel Test"?

First of all, who is "Joel"? Joel Spolsky is a software developer in the US. I came across his interesting blog about a year ago. He started his working career at Microsoft and left it in 2000, founding (together with Michael Pryor) his own company: Fog Creek Software (take a look at the pictures there...this is what I call a nice working environment :) ).
One of my favourite quotes from him:

[...]We didn't start with a particular product in mind: our goal was simply to build the kind of software company where we would want to work, one in which programmers and software developers are the stars and everything else serves only to make them productive and happy.[...]

He is the one of the creators of Stackoverflow.com which in my opinion is one of the best developer sites available on the net. The idea of letting developers vote is amazing since in this way the system corrects and balances itself (the same concept as behind Wikipedia). People just writing bad stuff will just get voted down or even removed. The next site Serverfault.com is also in beta which is most for system admins.

But let's return to the topic. What is the "Joel Test"?

[...]It's a fairly esoteric system for measuring how good a software team is.[...] The great part about it is that it takes about 3 minutes.[...]

Here you find a more detailed description and here are the questions:
The Joel Test

Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule?
Do you have a spec?
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do new candidates write code during their interview?
Do you do hallway usability testing?

About Scrum - in under 10 minutes

Here's a nice video that explains Scrum in under 10 minutes. It was quite useful when preparing for the exam in Software Quality Management. Some of you might be interested in it.

http://aboutscrum.com/

Mashup editor about to shut down

According to a note on the official Google Mashup Blog, they're about to shut down the Google Mashup Editor product. They took the valuable info they got from a numerous of Mashup developers to develop their AppEngine which will somehow replace the Mashup editor, although it is a different, much more complex product (with more features of course).

It's a pity to see it go, also because I had some projects hosted there and moreover it was quite useful for developing and hosting iGoogle gadgets:

News Mapper
Quite interesting product which got even mentioned on the official Google blog and appeared under the popular mashups of the unofficial Google Mashup gallery blog.
Pharmacy Locator
Still not finished. The data has been added manually but I planned to retrieve it in an automated fashion from some source. I guess this could have become quite interesting.

Too bad...

Btw, Google Page Creator is also being shut down during June and July. Everything will be moved to Google Sites which is much more advanced (my project site is hosted there). Most bloggers (myself included) however host their external files on Page creator such as CSS, javascript and images. Although your Google Page will be automatically moved to Google Sites, your external files won't be moved. So be aware that you have to host them on some other provider (Dropbox may be an option).

HowTo: Getting started with JUnit testing for Liferay portlets with Netbeans (for Eclipse users)

Besides at work, where I'm developing in .Net using Visual Studio, I'm a heavy Eclipse user. I use it for a lot of things, programming J2ME, J2EE, when developing Java desktop clients (using Eclipse RCP) or even when writing LaTeX documents. With its dozens of plugins it provides a very handy environment. This semester however, I switched to using Netbeans for my project for the Advanced Web Programming course, mainly because Netbeans was the professor's choice. Anyway, it may never be bad to see some other environments too :)

Basic portlet project setup

But let's switch to the topic of this post. What I want to address in this post here is to give some instructions/hints on how to setup the environment for writing JUnit tests. The setup and configuration is mainly targeted to the project structure of Liferay portlets which are created as Free form projects in Netbeans. So first lets take a look at the project structure of the portlet project. The folders are arranged as follows:

docroot

WEB-INF

classes (output for compiled java files)
jsp
lib (contains all of the jar libraries that are being used)
src
tld
portlet.xml
web.xml

nbproject (created by netbeans when you import the project)
build.xml

So to not mix test cases with the source code that is compiled and deployed on the portal server, I decided to modify the structure like this

docroot

WEB-INF

classes (output for compiled java files)
jsp
lib (contains all of the jar libraries that are being used)
src
tld
portlet.xml
web.xml

nbproject (created by netbeans when you import the project)
unitTests

lib
output
src

(package structure: com/..../....)

build.xml

Just some brief explanation on the choice of my folders (note, there may be better arrangements):

lib
You may wonder why I created another "lib" folder, since I already have the one in the WEB-INF folder. Well that's because I thought it may be useful to do so, since there may be libraries specific to the unit testing as for instance mock libraries or the JUnit library itself.
Note however that your unit tests may also need the libraries from your WEB-INF/lib folder because you use of course classes from the WEB-INF/src folder which are the objects for your test cases. The libraries are however not copied, but just referenced in the classpath of your Ant scripts (we will see later)
output
This folder contains the compiled test cases from the "unitTests/src" folder. Moreover it also needs to contain the compiled java src files from the WEB-INF/classes folder because you reference these objects in your test case (you actually test them there ;) )
src
Finally, this folder contains the java packages containing your unit tests. I recommend names such as "..." and the test case name.
So, if you have a class MyService in the com.lifepin.services package and you create a test case, you would create an according package com.lifepin.unittests.services (in your unitTest folder) where you would put your MyServiceTest test case. (this is just a recommendation)

Let's go on. To acutally use your unitTests folder, you have to declare it as a source folder, actually more specific as a "Test package folder" (right-click on the project + Properties). Note this is specific to Netbeans and doesn't exist in Eclipse which makes no distinctions between test folders and normal src folders.

If you accidentally declare your unitTests folder as source folder you'll get the error message "No test root folder was found in the selected project"...

...when creating a new unit test case.
After you have done this, you should now see your folder

The next step, if you didn't do yet, is to download the JUnit library. You can get it from here. Once downloaded, place it into the "unitTests/lib" folder.

Configuring Netbeans for unit tests
Let's switch to the real stuff now, the configuration of your Netbeans IDE and your Ant build file. Before starting I strongly recommend you to backup your project. The best is if you zip your entire project folder s.t. you can quickly restore it if something went wrong.

The first thing to do is to modify the original build file created by the Liferay portlet to handle the compilation and deploying of our unit tests as well as the copying of the compiled source files of our project into the unit test output folder ("unitTests/output").
If you created your portlet by using the Liferay-SDK's create scripts, you should have a very simple build.xml file:

<project name="portlet" basedir="." default="deploy">
    <import file="../build-common-portlet.xml" />
</project>

In order to avoid typing always the same path names - which also adds bad redundancy - let's add some properties to the build.xml that reflect our project structure:

<project name="portlet" basedir="." default="deploy">
    <import file="../build-common-portlet.xml" />

    <property name="src.dir" value="${basedir}/docroot/WEB-INF/src"/>
    <property name="classes.dir" value="${basedir}/docroot/WEB-INF/classes"/>
    <property name="lib.dir" value="${basedir}/docroot/WEB-INF/lib"/>

    <property name="test.src.dir" value="${basedir}/unitTests/src"/>
    <property name="test.classes.dir" value="${basedir}/unitTests/output"/>
    <property name="test.lib.dir" value="${basedir}/unitTests/lib"/>

</project>

Next we have to add the proper Ant targets for compiling our tests, for cleaning them and another Ant "path" element for identifying the unitTest's classpath. So at the end, the final build.xml should look as follows:

<project name="portlet" basedir="." default="deploy">
    <import file="../build-common-portlet.xml" />

    <property name="src.dir" value="${basedir}/docroot/WEB-INF/src"/>
    <property name="classes.dir" value="${basedir}/docroot/WEB-INF/classes"/>
    <property name="lib.dir" value="${basedir}/docroot/WEB-INF/lib"/>

    <property name="test.src.dir" value="${basedir}/unitTests/src"/>
    <property name="test.classes.dir" value="${basedir}/unitTests/output"/>
    <property name="test.lib.dir" value="${basedir}/unitTests/lib"/>

    <target name="compile-tests" depends="compile, clean-tests">
        <mkdir dir="${test.classes.dir}"/>
        <javac classpathref="test.class.path"
                destdir="${test.classes.dir}"
                srcdir="${test.src.dir}"
                debug="true"
                target="${ant.build.javac.target}">
            <include name="**/*"/>
        </javac>
        
        <!-- 
            compiled src files into the testing output directory since our tests will of course
            reference them
        -->
        <copy todir="${test.classes.dir}">
            <fileset dir="${classes.dir}"/>
        </copy>
    </target>

    <target name="clean-tests">
        <delete dir="${test.classes.dir}"/>
    </target>

    <path id="test.class.path">
        <pathelement location="${classes.dir}"/>
        <fileset dir="${lib.dir}">
            <include name="*.jar"/>
        </fileset>
        <pathelement location="${test.classes.dir}"/>
        <fileset dir="${test.lib.dir}">
            <include name="*.jar"/>
        </fileset>
    </path>
</project>

The only probably not immediately obvious task is the "compile-tests" task. So what does it do? It basically first creates the output folder "unitTests/output" where the compiled unit tests will be placed. Then it uses the "javac" task to compile all of the unit tests. Finally it also copies the compiled source files of our project to the unitTest's output folder (note: the "compile-tests" depends on "compile", so it will be guaranteed that the source files will be compiled properly).

Unfortunately we're not yet finished. The next thing is to adapt the Netbeans project.xml file. You may want to make another backup of your project folder to not loose the steps till here.
What we want to reach now is to be able to select a unit test case in the Netbean's project view, right-click on it and run it ("Run file" or "Shift+F6). To enable this a file called "ide-file-targets.xml" has to be created in the folder "nbproject", just beside the project.xml, with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<project basedir=".." name="LifePin-IDE">
    <import file="../build.xml"/>

    <!-- runs the selected file in the unitTest source folder as JUnit test -->
    <target name="run-selected-file-in-unitTests">
        <fail unless="run.class">Must set property 'run.class'</fail>
        <mkdir dir="${test.classes.dir}"/>
        <junit dir="${test.classes.dir}" fork="true" printsummary="true" showoutput="true">
            <classpath refid="test.class.path"/>
            <formatter type="brief" usefile="false"/>
            <formatter type="xml"/>
            <test name="${run.class}"/>
        </junit>
    </target>

</project>

Then switch to the project.xml and exchange the "ide-actions" with the following:

<ide-actions>
    <action name="build">
        <target>compile</target>
        <target>compile-tests</target>
    </action>
    <action name="clean">
        <target>clean</target>
        <target>clean-tests</target>
    </action>
    <action name="rebuild">
        <target>clean</target>
        <target>compile</target>
    </action>
    <action name="run.single">
        <script>nbproject/ide-file-targets.xml</script>
        <target>run-selected-file-in-unitTests</target>
        <context>
            <property>run.class</property>
            <folder>unitTests/src</folder>
            <pattern>\.java$</pattern>
            <format>java-name</format>
            <arity>
                <one-file-only/>
            </arity>
        </context>
    </action>
    <action name="debug.single">
        <script>nbproject/ide-file-targets.xml</script>
        <target>debug-selected-file-in-unitTests</target>
        <context>
            <property>debug.class</property>
            <folder>unitTests/src</folder>
            <pattern>\.java$</pattern>
            <format>java-name</format>
            <arity>
                <one-file-only/>
            </arity>
        </context>
    </action>
</ide-actions>

Now as a last step we have to configure Netbeans to be able to build correctly. This has nothing to do with your build scripts, but just that Netbeans correctly recognizes the different source files and compiles when you type the code in the editor. Go to the project properties and reference your needed libraries as shown in the screenshot below (of course you'll have different jars). Note: save your project.xml before, since it will be modified by Netbeans when you change the settings here.

Oh, I forgot one thing: test debugging :) . That's really essential 'cause when a test fails you want to debug it and step through the code in order to find the root of your trouble. To do so there are two important steps to follow. First add the following target to your "ide-file-targets.xml":

<target name="debug-selected-file-in-unitTests">
    <fail unless="debug.class">Must set property 'debug.class'</fail>
    <nbjpdastart addressproperty="jpda.address" name="LifePin" transport="dt_socket">
        <classpath refid="test.class.path"/>
    </nbjpdastart>
     <junit dir="${test.classes.dir}" fork="true" printsummary="true" showoutput="true">
        <classpath refid="test.class.path"/>
        <jvmarg value="-Xdebug"/>
        <jvmarg value="-Xrunjdwp:transport=dt_socket,address=${jpda.address}"/>
        <formatter type="brief" usefile="false"/>
        <formatter type="xml"/>
        <test name="${debug.class}"/>
    </junit>
</target>

Then you have to correctly configure the output path of your unitTests test folder, otherwise the compiler will not stop:

Coding a test, creating a test suite
You should now be ready to write your first unit test and run it. For convenience reasons I always usually create a test suite which groups the different test cases. Here's an example for JUnit 4:

@RunWith(Suite.class)
@Suite.SuiteClasses({AnotherTest.class, PinboardServiceTest.class})
public class TestSuiteAll {

    @BeforeClass
    public static void setUpClass() throws Exception {
    }

    @AfterClass
    public static void tearDownClass() throws Exception {
    }

    @Before
    public void setUp() throws Exception {
    }

    @After
    public void tearDown() throws Exception {
    }

}

You should get something like this:

So that concludes this tutorial. I hope I was able to help someone. Feel free to leave any comment if you have problems.

Page Speed: Firebug add-on for analyzing web page speed

Google just released Page Speed, a Firefox add-on for analyzing web pages in terms of speed. The tool directly integrates into Firebug and automatically verifies your page against a set of best practices rules. Here's a description on how to use it.

What is Page Speed?
Page Speed is an open-source Firefox/Firebug Add-on. Webmasters and web developers can use Page Speed to evaluate the performance of their web pages and to get suggestions on how to improve them.

How does Page Speed work?
Page Speed performs several tests on a site's web server configuration and front-end code. These tests are based on a set of best practices known to enhance web page performance. Webmasters who run Page Speed on their pages get a set of scores for each page, as well as helpful suggestions on how to improve its performance.

Why should you use Page Speed?
By using Page Speed, you can:

Make your site faster.

Keep Internet users engaged with your site.

Reduce your bandwidth and hosting costs.

Improve the web!

http://code.google.com/speed/page-speed/

Image search: Bing vs. Google Image

Bing does a great job in displaying images. You get all of them displayed in the center of the page within a separate scrollable container. So the search field as well as the search options on the side are always clearly visible and easily accessible. When moving the mouse over an image it becomes bigger, with some additional infos etc. By clicking on the image you get the related content in a different view...really nice and well structured. When you scroll down, further images are fetched automatically without the need for paging. Also the main interface is cool, always showing a different image.
But what about the "correctness" of the search results? Well correctness is quite relative, what I intend is the results expected by the user. Let's give it a try. Assume I see the following image somewhere and I want to perform a search for it.

So I'd enter a query like "bloggers dilemma" (since that's what's written in the image).
Searching on Google Images gives be on the first page containing 18 images, 9 correct results. Here's the query.
Searching on Bing (here's the query), I scrolled over about 500 images without 1 (expected) hit. That's bad, not what I expected given the nice interface etc. But ok, it's still in beta (being officially online just for a couple of days now), so I expect better results in the near future.

These queries bring slightly better results for Bing, but still...

Google
Bing

QSB - Google Quick Search bar for the Mac

And voila, the 1st Mac-related post :) Just a quick one, I have to continue with my studies so..
When I switched over to the Mac (2 weeks ago now) I started to get productive as quick as possible (due to my exams). So one application which made me very productive on Windows was Launchy. It is simple and still powerful. It indexes your folders, documents, applications, whatever you want. And when you want to launch an app for instance, you just press Alt+Space and a window will pop up, letting you to quickly write its name and hit enter.
On the Mac there are other kind of utilities. Spotlight, for instance, is Mac OSX's default search service. It indexes also your applications and folders etc, like Launchy does it. And similarly, you can use the Cmd+Space key to launch it.

Today I found another option, QSB (Quick Search Bar) from Google. It opens a Google Desktop similar popup window where you can also start applications, folders, documents - just like Spotlight - plus search on Google or your GDocs documents and spreadsheets.

\\Edit: Google Mac Blog post

Here are some screenshots:

Google Wave - Collaboration et excellence

Some days ago I just quickly scrolled over my Google Reader friends' items and saw Manfred's blog entry about Google Wave. It kept my attention since I didn't yet hear anything about that new Google product. Unfortunately I didn't have the time to immediately watch the video, but today I did...and it just blew me away. That product is amazing. Not just from the product point of view in terms of features etc..but on how the different features have been realized from a technological point of view. This certainly again shows what you can take out of HTML (5) and JavaScript (GWT), impressing.

I already use Google Docs for collaborating simultaneously on taking notes or creating draft documents for university courses and its great. You can write on the same document on the same time with your colleagues and you'll see (nearly real-time) your colleagues contributions and editing. But those things shown at the preview video really beats all. As they mentioned, it perfectly merges instant messaging and email writing or collaborative document building. And as usual, a really neat UI. You have to take a look at it, it's great.
Another great feature is the way of being able to add extensions that can be seemlessly integrated in the main UI.

Take a look at the video, not bad...and as also Manfred mentioned, watch out when the automatic translation robot comes to work ;)

Here's a longer story by Lars Rasmussen, one of the lead engineers at Google Wave which also built Google Maps.

Links:
http://wave.google.com

http://code.google.com/apis/wave/
http://www.waveprotocol.org/

Juri's TechBlog

Recent Posts Subscribe