I recently took the time to play around with the beta of Adobe Edge. Edge is an animation package similar to Flash. But while Flash outputs swf files which run in the Flash VM, Edge outputs HTML, JavaScript and CSS capable of running in any modern browser.

Here are some of the things I found while playing with it:

• The generated code is surprisingly clean. The output consists of
  • an HTML file (with a few imports and a single div tag)
  • a CSS file (easy to read, with IDs that match the object names defined in the tool)
  • a Javascript file (reasonably easy to read, but with a lot of animation data in it)
  • JQuery dependencies
  • Edge Javascript dependencies
• You don't want to edit any of these files other than the HTML, but from the HTML, you can add your own CSS or Javascript if you want to make changes above and beyond what the tool does.
• No real drawing tools - The current version only offers 3 shapes: rectangle, rounded rectangle and text. I assume there are more on the way. In addition to a few CSS tricks, they could have provided some basic shapes by generating SVG (or maybe HTML 5 canvas). You can still do just about anything you need to by drawing your shapes in Illustrator and exporting them as SVG or rasterized images. There is no explicit Illustrator support other than 'import image', but it auto detects changes in files.

posted by Bryan at 10:18 PM | 0 Comments

My current employer runs Sonar's static code analysis on the continuous integration servers. I recently turned on an IDE plugin which integrates Sonar's results into my editor and noticed a warning that made me scratch my head. Sonar doesn't like that I sometimes reuse my parameter variables. Here's an example of what I mean:

    public void doSomething(int input) {
        input = Math.min(20, input);
        input = Math.max(0, input);

        for (int i = 0; i < input; i++) {
            doSomethingElse(input);
        }
    }

I went online to look for an explanation. I expected to find an academic paper explaining some details that I'm overlooking. Instead I found that everyone willing to speak seemed to be in agreement that this is a bad practice. Strangely, I could find little reasoning as to why. The best explanation I could find was Martin Fowler's Refactoring. In it he provides two reasons you shouldn't make assignments to parameters:
1) Java uses pass by value exclusively. "With pass by value, any change to the parameter is not reflected in the calling routine. Those who have used pass by reference will probably find this confusing"
2) Consistency - "It is much clearer if you use only the parameter to represent what has been passed in, because that is a consistent usage."

To the first point, I would say any Java developer (even a junior developer) who thinks reassigning a parameter will effect the reference passed into the method should be fired immediately. We shouldn't cater to that developer. They will eventually do severe damage to your program.

To the second point, I think creating a second variable for the same purpose of the first is the very definition of inconsistent. A parameter is nothing more than a method scoped variable that happened to have been assigned from outside the method. If James Gosling had intended them to be final, he would have made them that way.*

I believe I like re-assignment for the very reason Fowler's dislikes them: maintainability and readability. The result of refactoring the above code to Fowler's recommendation would result in this code:

    public void doSomething(int input) {
        int boundedInput = Math.min(20, input);
        boundedInput = Math.max(0, boundedInput);

        for (int i = 0; i < boundedInput; i++) {
            doSomethingElse(boundedInput);
        }
    }

I think this is less readable. We now have two variables of the same scope that have nearly the same meaning. The first (the parameter) should not be used anywhere in the method except to initialize the second variable. This seems error prone. Somone could easily use input in the method body where they meant to operate against boundedInput. Even if they don't, it's still there taking up space (and brain cells) without providing anything to the story of this method.

Maybe I'm alone in thinking reusing parameters can make for more readable code. What better way to find out than for me to post my thoughts for the world to read (and criticize)? Feel free to comment.

* I guess an argument could be made that it was a mistake not to make parameters final by default, but now is a little late to make that argument. I believe we should write in the language that we have.

posted by Bryan at 9:08 PM | 3 Comments

It's been on my todo list for well over a year now, but I've finally taken the time to redesign my blog. Since I switched to blogger I've been using an altered blogger theme that never really sat right with me (front image below). When I was using moveable type, I had created my design from scratch including a photo I had taken of a circut board (middle image). Considering myself a creative person, using someone else's website template really bothered me. It felt good to get this done.



Other than the actual photo of the cork (which I lifted from deviant art), everything here is original. I created all the artifacts from scratch in Photoshop and even took a picture of myself for the top corner. I'm using CSS and Javascript (JQuery) to make the flickr badge at the left look like images taped to the cork. There are a few rough edges I'd like to clean up, but overall I feel much better to have something original up again.

posted by Bryan at 11:11 PM | 0 Comments