thoughts on software construction

To create a great user experience there is almost nothing more important than speed. According to Steve Souders, an expert in this area, 80-90% of the end-user response time is spent on the front-end.

Here is the list of best practices he recommends:

1. Make fewer HTTP requests
2. Use a CDN
3. Add an Expires header
4. Gzip components
5. Put stylesheets at the top
6. Put scripts at the bottom
7. Avoid CSS expressions
8. Make JS and CSS external
9. Reduce DNS lookups
10. Minify JS
11. Avoid redirects
12. Remove duplicate scripts
13. Configure ETags
14. Make AJAX cacheable

Watch this Video of Steve’s talk at the recent Google I/O conference:

Even Faster Web Sites (Google I/O Session Videos and Slides)

I can’t remember what bizzare series of clicks lead me there, but I just discovered an online copy of the original C-64 manual.  I flipped through it and relived all the emotions of entering and running every single one of the programs in it. I was 10 years old. One of my favorites was the bouncing ball program in Section 4 - Animation on pg. 30.

http://www.scribd.com/doc/40437/Commodore-64-Users-Guide

I’ve always thought that the ideal web development platform would be comprised of a dynamically typed language in the presentation tier supported by a statically typed language where the business and persistence logic lives. It just never made sense to me to use a statically typed language for building web user-interfaces considering that there’s very little gain to be had from type-safety.

The news today that Sun hired two key Python programmers makes me hopeful that they’re thinking what I’m thinking.

Dustin Bartlett, one of the developers on the team here at Point2, was just in my office asking me about Mock testing. It turned into an interesting discussion about when to use Mock objects and when not to. 

Ultimately I suggested he take a look at some of the material at xunitpatterns.com, a site developed by Gerard Meszaros while he was authoring the book xUnit Test Patterns. I was fortunate enough to be mentored by Gerard on several projects I worked on in Calgary, and have a tremendous amount of respect for him and his knowledge when it comes to testing software.

After looking at xunitpatterns.com Dustin and I realized the real question was what type of Test Double should be used. For the problem at hand, we decided to go with a Configurable Test Double. If you are stuck on a testing problem, or just want to improve your testing skills, I strongly recommend looking at Gerard’s site and picking up his book.

I just have to say, “I love Python!”

public void printPowers() {
    for (int r = 0; r < 100; r++) {
        int x = Math.pow(r, r);
        System.out.print(x);
        System.out.print(",");
    }
}

In Java - *with class definition and formatting left out

[r**r for r in range(100)]

In Python

Another thing I didn’t mention: The java implementation won’t work because int can’t store 99^99, but Python takes care of handling arbitrarily large numbers for you. It’s great.