AMinus.org - All Blogs

This past Friday I received a new feature request for our core business application. There's a report which nearly everyone on staff uses; it shows Mission Trips for a given set of dates. Most often, our staff will simply show all current and future Trips (and there's a one-click pathway for that common case). Each Trip gets its own row on the report, and each Trip has its own ID number printed on that row. The request I received was to make each printed ID a hyperlink to the data-entry page for the Trip.

Generally, people like to believe that "you get out what you put in"; that is, that the more effort you expend, the greater the reward. Baloney. I received more praise for implementing the hyperlinks than I have for any other feature in many moons. I spent months porting the app from VB4 to Python. In the process, I wrote an entire Object-Relational Mapper, including a DSL for processing data Sets, a mechanism for creating portable, early-bound Expression objects, and built-in analysis tools. I also wrote a web application framework, and an abstract Business Objects model independent of our specific business process. From the point-of-view of my users, all of that is par for the course—either completely expected, or completely obscured from their understanding. The response is decidedly underwhelming.

Total effort to implement the hyperlinks: open HTML file #1, select text, copy, open HTML file #2, paste. No reboots, not even a reloaded module. Perhaps 3 minutes if I throw in a test on the development platform before it goes "live".

Responses:

• "Do that, and wait for the cries of 'Hallelujah' from our users."
• "Bob's a genius."
• "We're not paying you enough." (Really! I have the email.)
• "An answer to prayer."

Unbelievable.

The issue, of course, comes down to pleasing your audience. There's a meme among working software developers like myself that you should write code worthy of the giants of computing. Larry Wall's quote ("The three chief virtues of a programmer are: Laziness, Impatience and Hubris") is often interpreted to mean "write code you want to show to your friends", meaning other developers. But let's face it: very few developers are going to be looking at my code, one or two of them are going to have any response to it, and 10% of them will be in a position to affect my life based on their opinion of my code. The return-on-investment vanishes rapidly.

Does this mean I should stop writing software which pleases gurus and concentrate solely on my users? No, because I fibbed a bit. There is at least one developer whose favors I want to court: my future self. So I do what I need to do to keep myself and my team happy. The true role of a software architect is learning how to please your developers (even if it's only you), your users, and management. Do that well, and the rest follows, often with a simple cut and paste. And if you're a solo developer, learn how to reward yourself for the Herculean code nobody but you will ever appreciate.

Link: http://illustmaker.abi-station.com/index_en.shtml

via Ned Batchelder

The New York Public Library has made their digital collection publically available.

Via Todd Blanchard at IWETHEY.

Over that last six months Bob (fumanchu) and I have been going to Sushi for lunch once or twice a week. I remember sitting at work talking about how we wished there was a good sushi restaurant near our work because we both like sushi. After a fruitless internet search I decided to grab a phone book. I didn't suspect to find anything near our work, but I couldn't help but hope.

Meijo Sushi is what I came up with. With no expectations Bob and I headed out to Imperial Beach in search of decent sushi. What we found was more than decent, it was WONDERFUL! Wonderful service, excellent prices, a great chef named Yuki, and a cute waitress named Mindy (she winked at me once ). Now that is our favourite place for lunch, and we are known by the staff there. Bob and I have even expanded our sushi adventures by inviting various co-workers here at Amor Ministries. Katie Gardner, Jennifer Leeper, the Larson Lovebirds, Jeff Ahlberg, Jen Weiss, Jon Wilson, Blair Illingworth, Ali Kaun, Steve Rollins, and Lydia Lozano are a few of the names that have come along.



Today is another Sushi Day, and I have invited the staff to join us again. If you like sushi, I highly suggest taking the trip over to I.B. for Meijo, and order a Meijo Roll (one of their specialties). If you haven't tried sushi, don't waste another minute of your life! I'm telling you, it is some of the best food you can consume!

I can't believe I'm the first staff member to blog about this--you all were at the party!

We headed off to Anthony's Fish Grotto at lunchtime today to celebrate the 25th anniversary of Amor Ministries! Our staff, some old friends, and several board members were present to tell some great stories about the early days, and to give congratulations to Scott and Gayla Congdon, our founders, in particular. We also heard a great report from Scott about the last board meeting in El Paso, and how thrilled they were when they recounted all of the milestones we attained this past year:

• We built our 10,000th home.
• We had over 22,000 participants working in Mexico.
• We became a $5 million company.
• We established a new "main camp" in Tijuana.

...and many more.

I want to take this opportunity again to thank Scott and Gayla for their years of dedication--to those about whom nobody else cared--this manifests the love of Christ more powerfully than any speech or sermon. Thank you for modeling Christ for me directly. And a big thanks to all who have lived, worked, and donated time, energy, money and labor to the building up of the church in Mexico. You are part of something great!

Sites I want to look at in more detail when I have time:

http://agiletesting.blogspot.com/2005/02/performance-vs-load-vs-stress-testing.html http://openload.sourceforge.net/ http://grinder.sourceforge.net/faq.html#g2vsg3 http://sourceforge.net/projects/deluge/ http://deluge.sourceforge.net/ideaforest_stress.pdf

I took a bunch of photos while in Mexico today for our new camp dedication service thingy. I know it is a lot, but I don't like having to pick which pics don't make the cut. So I am putting all the ones I like up. Enjoy, or should I say, "Disfruta".

Sorry for overriding your post, bob.

It had to happen sooner or later: I've been singing the praises of Firefox for quite a while now, and eventually I had to come across something that Internet Explorer does "better". [Update: it doesn't really, if you tweak Firefox. See last paragraph.]

That "something" is an asynchronous XMLHttpRequest, which is all the rage lately. Jesse James Garrett calls it "Ajax", which is as good a name as any, and one that I think will stick. I had the idea to try writing a webpage that would use async javascript + XML to stress-test a website, using only a browser. The initial prototype for that page follows:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 %s//EN"
    "http://www.w3.org/TR/xhtml1/DTD/%s.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>Frontload Stress Tester</title>
<style type='text/css'>

.graphpt {
    position: absolute;
    left: 0px;
    top: 125px;
    width: 1px;
    height: 0px;
    background-color: red;
}

</style>

<script type='text/javascript'>

if (typeof(XMLHttpRequest) != "undefined") {
    http = function() {return new XMLHttpRequest();}
} else {
    try {
        new ActiveXObject("Msxml2.XMLHTTP");
        http = function() {return new ActiveXObject("Msxml2.XMLHTTP");}
    } catch (e) {
        try {
            new ActiveXObject("Microsoft.XMLHTTP");
            http = function() {return new ActiveXObject("Microsoft.XMLHTTP");}
        } catch (E) {
            alert("Your browser doesn't support XMLHttpRequests");
        }
    }
}

totaltime = 0;
semaphore = 0;
loadlimit = 0;
url = "";

function makerequest() {
    var h = http();
    var start = new Date();
    starttime = start.getTime();
    h.onreadystatechange = function() {
        if (h.readyState == 4) {
            var response = h.responseText;
            var d = new Date();
            thistime = d.getTime() - starttime;
            document.getElementById('each').value = thistime;
            document.getElementById('eachbar').style.width = thistime + 'px';
            
            // Move one of the graph points onto the graph
            point = document.getElementById(semaphore);
            point.style.left = semaphore + 'px';
            point.style.height = thistime + 'px';
            
            semaphore += 1;
            totaltime += thistime;
            document.getElementById('avg').value = (totaltime / semaphore);
            document.getElementById('avgbar').style.width = (totaltime / semaphore) + 'px';
            if (semaphore < loadlimit) makerequest();
        }
    }
    h.open("GET", url, true);
    h.send(null);
}

function stresstest() {
    totaltime = 0;
    semaphore = 0;
    url = document.getElementById('url').value;
    loadlimit = parseInt(document.getElementById('load').value);
    for (i=0; i < loadlimit; i++) {
        point = document.createElement("div");
        point.className = "graphpt";
        point.id = i;
        document.body.appendChild(point);
    }
    makerequest();
}

// -->
</script>
</head>

<body>
Load: <input type='text' id='load' value='10' size='4' />
URL: <input type='text' id='url' value='http://localhost/mcontrol/index.htm' size='44' />
<a href='javascript:void(stresstest())'>GO</a>
<br />
Each (ms): <input type='text' id='each' value='' size='6' />
<div id='eachbar' style='background-color: #66FF66; border=2px solid black; width: 100px;'>Each</div>
Average (ms): <input type='text' id='avg' value='' size='6' />
<div id='avgbar' style='background-color: #8888FF; border=2px solid black; width: 100px;'>Average</div>
</body>
</html>

If you don't care to wade through that, it requests a URL n times. You get to tell it n and which URL. The idea was that, although Javascript doesn't do true threading, it at least allows asynchronous processing. I thought it might be possible to make multiple HTTP requests, and have the callbacks processed asynchronously (which doesn't work, by the way, even with setTimeout). I would then time each request (placing the start time in the callback closure), and dynamically show the times on-screen.

It turns out that IE and Firefox time quite differently. For most IIS pages, IE takes 10 or 20 milliseconds to fetch a minimal page, while Firefox takes 40 to 60 ms fetching the same page. With larger pages, the difference continues to be about 40ms per page. I can only assume at this point that the difference lies in the external objects used to make the requests: my IE uses the Msxml2.XMLHTTP ActiveX object, while Firefox uses the XMLHttpRequest builtin. Now the interesting part is that the gap between Firefox and IE narrows when I serve the same pages via Apache2 on Windows, instead of using IIS. IE takes an average of 7ms for the minimal page, and Firefox takes 16ms. For another, larger page, IE takes an average 227ms, while Firefox takes 233 (a difference of about 6ms, not the 40ms we had previously).

Hmmm. More tests to come...

Update: Okay, after making the pipelining tweaks described here, Firefox gets down to a more reasonable 20ms per minimal page on IIS; the Apache speeds are unchanged. Somebody should make those tweaks the default, given the buzz around Ajax these days.

I've got to add access control to "Mission Control" (our main business application), and I cannot decide where to do it.

There are two main components: a UI (built on a UI framework, Cation), and a Model layer full of business objects (built on an Object-Relational Mapper, Dejavu).

Part of me wants to build the controls into the business objects themselves, since that's really what needs to be protected. I don't care if someone can access a page if they can't see any data on it (or add any data through it). It wouldn't be difficult to enforce, because all the business objects already subclass dejavu.Unit, the base class for the ORM. The downside is that Dejavu doesn't currently have any concept of users or access controls. Any user context, therefore, would have to be passed into Dejavu from outside. This wouldn't be too hard, since every Dejavu session checks out its own Sandbox object--I could just stick a reference to the access-control library into the Sandbox. I'd probably end up leaving the default Sandbox as is, and write a new SecureSandbox class, then decide between the two via a config parameter.

Writing the locks into the Model would be nice, because, in general, those change less often than the View. When new features are added, having the locks in the View code means a higher probability of forgetting to test for permission.

It would also be nice for management by end-user admins--they tend to understand "you can see Mission Trips but not Projects" better than long lists of event descriptions like "Show the Zip Code of the Primary Addressee on a Group Scheduling Report (but not a Group Scheduling Calendar)".

But another part of me wants to put the locks in the View. It would allow finer-grained permissions, and allow locks on behaviors which don't involve persisted business objects. It would also be better-integrated, since the View layer already interacts with authentication code in the webserver. There's also a lot of precedent, in that most ORM's don't manage permissions.

Hmmmm...

Here is a pic of Josiah demonstrating his supreme balance while holding a shark in one hand and a lizard in the other! Wow! I can't say that I am capable of that. All the while Luke is intently working on his lesson for the evening's bible study.