Looking through the web for standards on how to make your web pages more performant (i.e. using tools like YSlow!), one of the things that is mentioned is to put your css at the top and your javascript at the bottom. The reason to do this is so that your content will render faster (and be styled) and not have to wait for the parsing of the javascript in order to display.

Recently I have been getting into using jQuery UI a lot more. I like the common look and feel, the ability to theme it easily, and am excited for all of the new enhancements and widgets that are coming. The issue that I have found is that when jQuery UI initializes your widgets it adds the theming classes from the javascript. This causes the page content to render (in a very ugly unstyled fashion) and then it "pops" into the nice styled page. As a user also, I tend to hate this effect and find it very annoying. So I set out to see what I could do to fix this and still keep the site performant.

First attempt - pure CSS

At first I thought, well what if I just put the jQuery UI classes on the elements that I know will already receive those classes when jQuery UI ran? This worked well for some of the page but there were still issues:

1. Some of the jQuery UI widgets add in extra DOM elements to accomplish the look they are going for, so this still had the jumping effect
2. I was now bound to a specific version of jQuery UI because if they ever changed or tweaked their class names I would have to update all of my elements with the changes
3. By adding the classes on the server I increased the page size and content that needed to be downloaded to the browser

Second attempt - rearrange the JS

Since the CSS way wasn't ideal and would cause a lot of maintenance I decided to see what would happen if I rearranged where I loaded the JS. I put all of the JS back in the head tag, so it would load (and parse) the JS before any content would display to the user. This solution was better, however, there was still a little jumping of the page before it was fully styled.

Third attempt - tweaking the JS calls

Finally, I took a look at how I was calling the jQuery UI widget initializers. I found that I was calling them inside of jQuery(window).load call. I then did some research and realized that the difference between jQuery(window).load and jQuery(document).ready is actually pretty significant if you have a lot of images. This is due to the fact that window load waits for the images to finish before being called where as document ready is called when the DOM is finished loading. Changing those calls to be inside of a jQuery(document).ready block did the trick and the page loads without any jumping.

So from this exercise I found that as the web world moves towards more and more javascript based UI's we will need to look more closely at these blanket performance statements and include usability in those measurements.

Extra nugget:

The pages in question above also load various content through ajax after the page loads. I found a small performance gain when I kept the jQuery UI initializers in the document ready block and moved the ajax calls into the window load block.

The other day my project took on the task of upgrading our (fairly new) rails application from Rails 2.3.5 to Rails 3. Everything was going great until we got to the part of actually trying to run our application under WEBrick.

Our application has some services that it connects to that require secure connections so in order to comply and still develop we had modified the WEBrick configuration under 2.3.5 to make it run under SSL. This turned out to be very easy to accomplish with 2.3.5, we just cracked open the script/server file and added the appropriate SSL options that WEBrick already knows about.

Rails 3 proved to be a little bit more difficult to modify. This is due to the fact that the script folder only contains a rails script now and all of the old scripts are now contained deep in the rails build. I didn’t really want to crack open rails and start modifying (especially not when it is only for development), so I was looking for another option. I spent a few days searching the internet with no luck. Today I came into work and after 6+ hours and some pair programming a solution was figured out. You can find the solution that we came up with below, and if there is a more elegant solution out there I would love to hear about it.

All you have to do to get WEBrick running in SSL is modify the script/rails file and add the following lines (above the APP_PATH variable declaration):

require 'rubygems'
require 'rails/commands/server'
require 'rack'
require 'webrick'
require 'webrick/https'

module Rails
    class Server < ::Rack::Server
        def default_options
            super.merge({
                :Port => 3000,
                :environment => (ENV['RAILS_ENV'] || "development").dup,
                :daemonize => false,
                :debugger => false,
                :pid => File.expand_path("tmp/pids/server.pid"),
                :config => File.expand_path("config.ru"),
                :SSLEnable => true,
                :SSLVerifyClient => OpenSSL::SSL::VERIFY_NONE,
                :SSLPrivateKey => OpenSSL::PKey::RSA.new(
                       File.open("path/to/key").read),
                :SSLCertificate => OpenSSL::X509::Certificate.new(
                       File.open("/path/to/crt").read),
                :SSLCertName => [["CN", WEBrick::Utils::getservername]]
            })
        end
    end
end

My current project (a web application) has a module that is almost entirely written in Groovy.  Note: We are using the latest version 1.6.5 of Groovy.

In one of the methods we had some logic similar to the following:

def myMethodToProcessTheList(def listOfThings) {


if (listOfThings && listOfThings.size < 0) {
    //Do my logic
}


}

When the above code is run using Java 5 everything works wonderfully.  However when we pushed the code out to our server running Java 6 we got an interesting error stating that it couldn't compare java.util.ArrayList to java.lang.Integer.

The problem is actually that the size method needs the parens after it (Note: The Groovy docs actually do state that methods with at least ONE param can omit the parens).  I realize now that it would make sense that parameter-less methods would need parens because how else would Groovy distinguish between methods and property accessors?  I did find one forum post that indicated that in Groovy, lists have special properties that act like the spread-dot operator.  That is why the listOfThings.size returned the ArrayList instead of a number.

So why does this work in Java 5 but not Java 6?  That is a great question, one of which I really don't have a definitive answer.  I'm not completely sure if this purely a Java 5/Java 6 difference or simply a difference between the IBM Java 5/Java 6 JVM.

If anyone has a theory as to why it would work one way on Java 5 and the other in Java 6, I would love to hear it.

I have recently been taking some graduate classes in the field of Information Technology Management.  After the first few core classes, I have come to the conclusion that there are WAY too many higher education institutions that are avoiding Agile methodologies when they begin teaching software development practices.

To give some background on where I'm coming from, the program that I had started included a class on project management.  The semester had a week or two going into detail about the standard software development life cycle (SDLC).  The way they described it was exactly the way waterfall works.  All work was done in phases, requirements, design, development, test, deployment, all of which revolves around mountains of documentation and paperwork.

Seeing as I have been working on an Agile based project for over 3 years, I thought I would inject some of my thoughts for the class on how things could be better.  I couldn't believe how much negativity I got from other students and even the professor.  I was told numerous times how the Agile methodologies (in general, not specific implementations) wouldn't work for large projects and is only good for prototyping functionality.  The professor even made the comment that Agile was too restrictive when it comes to the time constraints (this I had a good laugh at).

To make matters worse, if I was to continue the program, the last 5 classes are all different steps in the waterfall process.  There is a class on Requirements, there is a class on Design, etc., all leading up to a final course that puts it all together.  I don't see a problem with teaching students different ways to gather requirements or how to go about thinking about and designing a system.  What I do have a problem with is that these higher education institutions are still forcing a specific system down the throats of students when they should be training the students on how to be most effective in their jobs and provide them with as many tools to accomplish that goal.

Agile isn't just a new fad, it has been around for quite a while now and has taken some of the best practices from years of experience and made those the focus.  Furthering oneself through education should benefit the student not waste their time.  My hope is that one day there will be a reform in the software development education programs so that new software development managers will have the necessary tools to be effective rather than being restricted out of the gate.  If there isn't some change soon, the industry is going to pass the education system by and getting a masters isn't going to do anyone any good.

Introduction

Processing is a basically a proprietary Java-like language compiled into Java bytecode and used for generating dynamic and interactive data visualizations. Though still in its infancy, it seems to be a very nice intuitive way to build visualizations of data into an application. The download for Processing contains the compiler, library and an editor. The file format for Processing files is .pde. Inside of these files you can treat the language just like a scripting language. For instance:

size(400,400);
background(192, 64, 0);
stroke(255);
line(150, 25, 270, 350);

This block of code is from the book "Visualizing Data" by Ben Fry and will just set the window size, set the background color, set the line color and draw a line. The output will look like:

There are 2 methods that processing will look for to do initial setup and then the refreshing of the canvas. Adding those methods and adding some mouse interaction we get the following code:

void setup() {
   size(400, 400);
   stroke(255);
   background(192, 64, 0);
}


void draw() {
   line(150, 25, mouseX, mouseY);
}

The output from this block of code will look like:



There are a lot more convenient functions and properties available when using the Processing API but that will have to wait for another blog. The editor that comes with Processing is functional, but is lacking in features that many of the more modern editors contain. So I wanted to try and see if I could use my standard editor and still build Processing apps.

Eclipsing the IDEA

Processing so nicely comes with a jar core.jar. This jar then can be added to a project in the editor of your choosing. Once you are in Java world there are couple of things that need to change with your Processing code. Mainly you have to now adhere to Java programming rules. Our code from above in the Java world would look like the following:

import processing.core.PApplet;


public class BlogExample extends PApplet {
    public void setup() {
        size(400, 400);
        stroke(255);
        background(192, 64, 0);
    }


    public void draw() {
        line(150, 25, mouseX, mouseY);
    }
}

As you can see, the code becomes a little lengthier. We need to add all of the modifiers on and the class definition and all of that, but we are at least in the IDE of our choice now and can just run this file and get the same output as the Processing editor. Now lets say we we want to add boxes to our output. We can add a class called Box to the project (Processing editor supports multiple classes as well). The code for the Box class would be:

public class Box {
    private String title;
    private String boxText;
    private int width;
    private int height;
    private String backgroundColor;
    private String textColor;


    public int getWidth() {
        return width;
    }


    public void setWidth(int width) {
        this.width = width;
    }


    public String getTitle() {
        return title;
    }


    public void setTitle(String title) {
        this.title = title;
    }


    public String getBoxText() {
        return boxText;
    }


    public void setBoxText(String boxText) {
        this.boxText = boxText;
    }


    public int getHeight() {
        return height;
    }


    public void setHeight(int height) {
        this.height = height;
    }


    public String getBackgroundColor() {
        return backgroundColor;
    }


    public void setBackgroundColor(String backgroundColor) {
        this.backgroundColor = backgroundColor;
    }


    public String getTextColor() {
        return textColor;
    }


    public void setTextColor(String textColor) {
        this.textColor = textColor;
    }
}

Then we add some code to our main class to use the Box.

public class BlogExample extends PApplet {
    public void setup() {
        size(400, 400);
        stroke(255);
        background(192, 64, 0);
    }


    public void draw() {
        line(150, 25, mouseX, mouseY);
        List boxes = getBoxes();
        
        int xPos = 0;
        int yPos = 0;
        for (Box box : boxes) {
            drawBox(box, xPos, yPos);
            xPos += box.getWidth() + 5;
            yPos += box.getHeight() + 5;
        }
    }
    
    private void drawBox(Box box, int xPos, int yPos) {
        //Draw the box on the screen;
    }


    private List getBoxes() {
        List boxes = new ArrayList();
        
        Box box = new Box();
        box.setTitle("Box 1");
        box.setBoxText("Text in Box 1");
        box.setBackgroundColor("blue");
        box.setTextColor("white");
        box.setWidth(100);
        box.setHeight(100);
        boxes.add(box);
        
        //Add more boxes here
        
        return boxes;
    }
}

Now you can see we have added a lot of code to do some simple processing of boxes. This isn't very script-like anymore. I was thinking of how to get this code base a little smaller. I then thought of what would happen if I added Groovy to it.

Groovifing the Code

After adding the groovy jar, I could change my .java files to .groovy files and start shrinking the code base. Here is what the above code became:

class BlogExample extends PApplet {
    void setup() {
        size(400, 400)
        stroke(255)
        background(192, 64, 0)
    }


    void draw() {
        line(150, 25, mouseX, mouseY)
        def boxes = getBoxes()


        def xPos = 0
        def yPos = 0;
        boxes.each {box ->
            drawBox(box, xPos, yPos);
            xPos += box.width + 5;
            yPos += box.height + 5;
        }
    }


    private void drawBox(def box, def xPos, def yPos) {
        //Draw the box on the screen;
    }


    private List getBoxes() {
        return [
                new Box(title:"Box 1", boxText:"Text in Box 1", backgroundColor:'blue', textColor:'white', height:100, width:100)
                //Add more boxes here
        ]
    }
}


class Box {
    String title;
    String boxText;
    int width;
    int height;
    String backgroundColor;
    String textColor;
}

Making the code a little Groovier has reduced the amount of lines that I need to write to get my visualization up and running. So now I've got the simpler syntax of a scripting language and all the power of my IDE and all of my Java libraries. I know that this example is very primitive and you don't necessarily get as much bang for your buck on something this small, however, as this application grows into something bigger the gains will become more apparent.