To successfully achieve a comfortable review friendly working practice will take effort from both reviewers and reviewees. Some practice is also required until the reviewing process is just right. If the reviewer is too soft there is a danger that poor quality code could make it into the codebase, whereas if they are too hard the coder could become unnecessarily defensive or upset.

When a “review before check in” process is first introduced there is usually some frustration from the coder because it seems like time is being wasted before they can complete their work. In the long run I have found the time spent on reviews to be worth every second as they often catch defects before the testing process and help to improve a coders knowledge.

To help resolve the personal issues that invariably arise from reviews you can adopt the Ten Commandments of Egoless Programming as a way of resolving any hurt feelings. It is vital that reviewers use language that does not express disappointment, blame or general negativity as this will create a negative attitude toward reviews.

Tools I have used for code review include Smart Bear Code Collaborator and Jupiter for Eclipse. I recommend Smart Bear if you are serious about reviews and have the budget, otherwise Jupiter may be sufficient. It’s worth noting that Smart Bear may offer a free licence if your project is free and open source.

It is not the critic who counts; Not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better.

The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; Who strives valiantly;

Who errs, and comes up short again and again, because there is no effort without error and shortcoming; But who does actually strive to do the deeds; Who knows the great enthusiasms, the great devotions; Who spends himself in a worthy cause;

Who at the best knows in the end the triumph of high achievement, and who at the worse, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who know neither victory nor defeat.

-Theodore Roosevelt

-vmargs -Xms256M -Xmx512M

Shortcut Example: "C:\Program Files\eclipse\eclipse.exe" -vmargs -Xms256M -Xmx512M

Alternatively, you can update your eclipse.ini file.

More information can be found on Ryan Phelan’s site.

These examples have been tested on a Windows XP PC with 2GB RAM.

The system cannot find the file specified.
svn: Can't create tunnel: The system cannot find the file specified.

Typically, you experience it when using a url with the following structure:

svn+ssh://myfancy.svnserver.com/repo

Thankfully there is a very simple fix. All you need to do is adjust one of the settings in the “Window->Preferences” menu.

Navigate the tree to “Team->SVN” and you will notice a section called “SVN Interface”. If the client is set to “JavaHL (JNI)” then change it to “SVNKit (Pure Java)”.

Thanks to Mark Phippard for this gem.

Alternatively, you can search for “Cosmic Corridors” on iTunes.

This article lists the steps to create a bare bones BlazeDS server configuration using the turnkey solution.

What You’ll Need

First I’ll assume you have already downloaded and installed the following:

• Eclipse
• Flex Builder (or Flex Builder plugin for Eclipse)
• BlazeDS turnkey

If you followed all of the instructions for installing and running the basic BlazeDS turnkey, then you currently have a tomcat server running a demo on localhost (port 8400). If successful, you should see the BlazeDS index page by clicking here. If you see an error at this point, then you can go and check your server logs and try to correct it. Do not proceed with this guide until you see the functioning index page.

Now you have successfully installed Tomcat and BlazeDS turnkey, you will need to turn it off as you won’t be using it from here. Yes that’s right, turn it off! Shutdown the tomcat server using any method you choose (i.e. ctrl-c, shutdown.bat, stop the service, catalina stop, etc.). This will free up port 8400 and allow you to run the server from Eclipse after we have configured it.

Setting up Tomcat in Eclipse

These are the steps for creating a connection to the tomcat server:

1. Start Eclipse and select the “Java EE” perspective
2. In the bottom panel, select the “Servers” tab
3. Right click on the panel and select “New->Server”
4. Select the server settings and point them to your newly installed tomcat server. The installation directory should be “<base turnkey installation dir>\tomcat” (in my case this is “C:\blazeds\tomcat”).
5. Click Finish

Once you have completed these steps, you should see a new server created in the “Servers” panel, plus a new tree entry in the Project Explorer (also called “Servers”). Your environment should look a bit like this.

Creating a Project

The next step is to create the server side project.

1. Create a new “Dynamic Web Project” with the following settings:
   • Project name: myBlazeProject
   • Target Runtime: “Apache Tomcat x.x” (this is the server you created in the last section)
   • Configuration: Default Configuration for Apache Tomcat x.x
2. Click “Finish”

After creating the project, your environment should look a little like this.

Creating the Bare Bones BlazeDS Configuration

Ok, we now have the server set up and a basic project. The next steps set up the BlazeDS libraries and configure the environment to auto-update the server when the project is built.

1. Overwrite the contents of your “WebContent” directory with the BlazeDS directory structure “<base turnkey installation dir>\tomcat\webapps\blazeds”.  The result should look a little like this.
2. Right click on your newly created “myBlazeProject” project and select “Properties”
3. Select “Java Build Path” from the list in the left hand panel.
4. Set the “Default output folder” to “myBlazeProject/WebContent/WEB-INF/classes”. This will cause your web server to automatically update every time you rebuild your project.

Create a Basic Remote Class

Great! We’re nearly there… now let’s create and configure a Java class so we can test our configuration.

1. In the “myBlazeProject/WebContent/WEB-INF/src” directory, create a new class called HelloWorld.java.

public class HelloWorld {
    public String sayHello(String name) {
        return "Hello, " + name;
    }
}

2. Configure BlazeDS to allow remoting requests to the HelloWorld class by adding a destination to the “remoting-config.xml” file found in the “myBlazeProject/WebContent/WEB-INF/flex” directory. Use the following destination configuration:

<destination id="HelloWorld">
    <properties>
        <source>HelloWorld</source>
    </properties>
</destination>

3. Start your application server by clicking on the green “play” button. Verify your web application is configured by going to the following URL (The url and port may vary depending on your application server configuration and what you named your project): http://localhost:8400/myBlazeProject/
   If your server is not configured to display directory contents, you might see a 404 error. This is OK, but failure to connect errors are not.

Create a Flex Project

Whether you use the Flex Builder 3 plugin for Eclipse or standalone Flex builder 3 installation is entirely up to you. It’s possible to manage your Flex and Java code in one IDE if you use the plugin, but you may prefer the standalone IDE instead.

These steps create the Flex project and link it to your server:

1. Create a new Flex Project
   • Project name: testHelloWorld
   • Application server type: J2EE
   • Use remote object access service: enabled (with “LiveCycle Data Services” selected)
2. Click “Next >”
3. Use these settings:
   • Root folder: point this to your “WebContent” directory in the Java project
   • Root URL: http://localhost:8400/myBlazeProject/
   • Context Root: /myBlazeProject
4. Click “Validate Configuration”
5. Click “Finish”

Create a Client Test Application

Finally, let’s update the Flex project to use our BlazeDS Server so we can test our remote object:

1. Update the testHelloWorld.mxml file with the following code:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml">

    <mx:RemoteObject id="ro" destination="HelloWorld"/>
    <mx:TextInput id="n" change="ro.sayHello(n.text)"/>
    <mx:Label text="{ro.sayHello.lastResult}"/>

</mx:Application>

2. Build and Run!

If all went well, then you should have a working Flex app that connects to your remote service and responds with “Hello, <your name>”.  Something like this.

Troubleshooting

If you for some reason your components don’t talk to each other after following all the steps, try cleaning the projects and restarting the server.

Server Side Debugging

Now that we have created the bare bones server in this manner, we can use the fantastic debug functionality provided by Eclipse in the Java server code as well as the Eclipse client code!

To use the Java debug mode, just add your breakpoints to your source files and make sure the server is running in debug mode. Then when your Flex apps call the remote objects, they will trigger the debug mode and Eclipse will automagically put you into Java debug mode.

Further Reading

This article was inspired by the excellent in depth articles provided by the following sources:

• Bare Bones BlazeDS Object Remoting – by Dustin Marx
• Building Web and Desktop Applications with BlazeDS and AMF – by James Ward and Shashank Tiwari