Skip to content

Software archeology

I presented this evening on J2ME for the kickstart meeting at BJUG, where Grady Booch was the featured speaker. After unknowingly knocking UML in his presence, I enjoyed a fine talk on software archeology. This discipline involves looking at larger, historical patterns of software development. Essentially, when we build software, we are building artifacts. And, just as the plans and meetings of the the slave foremen who built the pyramids used are not recorded, so there are aspects of present day software development that are simply lost when the project ends or the programmers die. One of Booch’s projects is to capture as much of that data as possible, because these architectures are full of valuable knowledge that many folks have sweated for. It needs to happen soon, because, in his words, “time is not on our side” when it comes to collecting this kind of data. Man, I could handle that kind of job.

Speaking of architecture, I stumbled on “Effective Enterprise Java” which looks to be a set of rules for enterprise java development. I really enjoy “Effective Java”, by Joshua Bloch, so I hope that Ted Neward’s book lives up to its name. And I certainly hope this project doesn’t get stranded like “Interface Design” apparently did.

First Monday

First Monday is a collection of peer reviewed papers regarding technology, “solely devoted to the Internet”. If you want a feeling for how Internet technology is affecting society, presented in a clear, reasoned format, this is one of the places to go. Topics range from “what’s wrong with open source” (which got slashdotted recently) to “how online education affects the balance of power at universities” to “how can we best keep track of information”. Fascinating stuff, and the academic nature of the discourse means that it’s got a solid foundation (as opposed to most weblogs, which are just some opinionated person rambling). You can even sign up for an email list to be notified when they post news articles (ah, listserv). Too bad they don’t have an RSS feed.

Is transparent access control worth unintelligible error messages?

Partly egged on by Rob and Brian, I just took a long overdue look at container managed security for web applications.

My conclusion: it’s nice, but there is one major flaw that dooms the whole premise. Users expect informative error messages when they ‘sign in’ and there’s no way to do that with container managed security.

I was using Tomcat 4.1, which is to say, I was examining the servlet 2.3 specification. (I just looked at the 2.4 specification and can see no amelioration of the above issue.) I also focused on the FORM method of authentication, as that’s the most customizable. (I imagine, for an intranet app obsessed with security, client certificates would be an worthwhile avenue of investigation.) I found the servlet specs to be very helpful in this process.

With the FORM method of authentication, you can customize the appearance of your login and error pages, to some extent. This is a huge win.

I really liked the automatic access control–no checking at the beginning of every ActionForm or JSP for any specific attribute. Additionally, you can protect different URL patterns easily, and for most of the applications I write, this is enough. If you need to protect buttons on a page, you can always resort to isUserInRole.

Also, you can protect the login and error pages, which should never be accessed directly in a separate /safe directory, to which you can prohibit all access.

For the times when the user is denied access to a resource, you you can create a custom 403 error page, using the error-page directive in web.xml. Unfortunately, you only seem to get three attributes: javax.servlet.error.message, javax.servlet.error.request_uri and javax.servlet.error.status_code, which limits the nature of your response. These were what Tomcat gave me–I don’t think it’s part of the spec. Regardless, IE, with default settings, doesn’t display any custom error messages, which makes this a rather moot point for general webapps.

Creating a logout page is fairly easy, just call session.invalidate() (though there seem to be some non standard methods of doing it as well).

However, as mentioned above, I just don’t think that users will accept the generic login error messages that you are forced to give. For instance, you can’t tell whether a user didn’t enter a password, or entered an incorrect password. You can’t redirect them back to a login page with helpful error messages around the incorrect box. These are fundamental issues with authentication–no serious webapp simply throws up its hands when a user doesn’t login correctly the *first* time.

Separate from user experience, but still related to authentication behavior, you can’t ‘lock out’ users who’ve attempted to login too many times. Sure, you can keep track of how many times they’ve tried to login, but the authentication process is out of your hands.

Additionally, the fact that you’re tied to a particular implementation for user/role definition means that writing custom authentication code that just accesses a RDMBS is actually more portable.

The answer, to the question posed in the title of this post: “is transparent access control worth unintelligible error messages?”, is almost always “no.” And folks accuse developers of not having any sense of user interface!

SimpleDateFormat and the 13th month

Wow. I just learned something about SimpleDateFormat, a class that I always resort to when I have to convert a String to a Date in java. Check out this bit of code:

import java.text.*;
import java.util.*;

public class foo {
public static void main (String[] args) throws Exception {
SimpleDateFormat sdf = new SimpleDateFormat("MMddyyyy");
System.out.println("12012000 "+ sdf.parse("12012000"));
System.out.println("13012000 "+ sdf.parse("13012000"));
System.out.println("12322000 "+ sdf.parse("12322000"));
}
}

and the output from that code:

$ java -classpath . foo
12012000 Fri Dec 01 00:00:00 MST 2000
13012000 Mon Jan 01 00:00:00 MST 2001
12322000 Mon Jan 01 00:00:00 MST 2001

Any overflow gets rolled into the the next higher, well, in addition, I’d call this a place. The 32nd day of December is the 1st of Jan, and the 13th month of any year is Jan. This is an implementation detail, as I found no mention of it in the SimpleDateFormat javadoc, nor the DateFormat javadoc, but others have noticed this too.

jalopy now closed source

Jalopy, which I wrote about here, is now closed source. It’s about $40 for a single user license. For more info, see the corporate website. I see that the open source version is still around, though there hasn’t been a release since 1.02, about 18 months (about the same as xdoclet actually).

I totally respect Hunsicker Marco (who is the developer, I think and certainly the owner of the corporate domain) and his right to earn a living. $40 certainly isn’t that much (in fact, he even has a link to the old, free version on his purchase page!), but I hope that he eventually rolls the improvements into the free version, a la ESR’s “Free The Future, Sell the Present” business model.

Three tech tips

Here are three items that I’ve found useful in the past, but aren’t worth an individual post because of their triviality.

1. Sometimes file archives are only available in .zip format. There are unix programs out there that can unzip such archives, and linux often ships with one. But sometimes it’s not installed. Lately, I’m almost always doing some kind of java development, in which case, you can use the jar command to extract the archive.

2. I generate an html page of all my rss feeds, using a custom perl hack (I wouldn’t go so far as to term it a script). (No newsgator for me! Did I mention I still use pine for email?) This can produce quite a big file, since I’m querying around 80 feeds. In an effort to reduce my bandwidth, which I pay for, I now gzip my rss feeds page, using CPU that I don’t pay for (well, not directly). And, while gzip may not be the most efficient of compressors, files in gzipped format can be transparently read in all the browsers I cared to test: Mozilla, Firefox, IE, and even lynx.

3. Sometimes you just want the data from a mysql query in an easy format that you can pull into a spreadsheet and manipulate further. In the past, I would have written a quick perl script, using DBI, but after investigating the client options, I found another way. mysql -u user -B -ppass -e 'select * from my_data' databasename gives you nice tab delimited output. I’ve used this with the mysql 4 client; since I couldn’t track down the mysql 3 manual, I’m not clear what version of the mysql client supports these features.

Book Review: Your Money or Your Life

Your Money or Your Life by Joe Dominguez and Vicki Robin, is a collection of simple, common sense observations about money. Perhaps because money is so fundamental to our lives, or because we associate it with work, often we don’t examine these simple truths. But the first step to making sound decisions, about money as about every other topic, is to gather all the facts so you can make a knowledgeable and concious decision. This book helps you do that.

The book takes you through 9 steps to Financial Independence, from cataloging all the money you’ve ever made to keeping a budget to their solution for non wage income. The lessons are told in a easy, simple manner, with ‘real life’ stories interspersed throughout. Some of their most profound ideas aren’t about money, but about work–what human beings look for in work that they used to look for in community and family.

I’m a single guy, and I felt this book was aimed at big spenders with families, mortgages and boats, but I still felt there were lessons to take away. Their end solution is something I’m still up in the air about, but the steps along the way were fabulous–every one simple enough to understand, yet powerful enough to change the way you thought about the concepts discussed. I liked this book and would recommend it.

Scripting languages and productivity

Bruce Eckel has some things to say about different languages and productivity. One quote in particular stood out:

“I didn’t have to look that up, or to even think about it [reading the contents of a file using python], because it’s so natural. I always have to look up the way to open files and read lines in Java. I suppose you could argue that Java wasn’t intended to do text processing and I’d agree with you, but unfortunately it seems like Java is mostly used on servers where a very common task is to process text.”

I agree entirely. I come from a perl background (it’s the language I cut my teeth on, which, I suppose, dates me), and unlike some, I’m unabashedly in favor of it. I’ve looked at python briefly, and it does seem to have perl’s flexibility and agility with less ambiguity. When you have to grab a file from the filesystem (or parse a file and stuff it into a database) there’s simply no comparison, and anyone who reaches for Java to solve such problems simply hasn’t experienced the joy of the freedom of scripting languages.

The problem with such free form languages arises when you start doing large scale systems. Java, for all its faults and complexity, forces choices about implementation to be done at a high level–which framework do we want to use, how do we architect this solution. Perl (note that I’m not talking about python, since I’m a python newbie), on the other hand, is more flexible, and hence allows more latitude. It requires more discipline to code OO perl, or, for that matter, readable perl, than it does to code readable java. (There are different ways to implement objects in perl–see Object Oriented Perl for more information.) By limiting some of the latitude of the developer, you gain some maintainability.

I was trying to think of trivial examples that illustrate this point, but I couldn’t. Perhaps it’s because I’ve been out of touch with perl’s evolving core libraries for so long, or perhaps it’s because all the perl I’ve ever had to maintain has been intensely idiomatic, where all the java I’ve had to maintain has been, though at times obtuse, fairly easy to read, but I just feel that perl is a harder language to maintain than java.

Now, how does this apply to Eckel’s statements? Well, he uses python as his example–stating that you just plain can get more done with python than you can with java. It’s hard to argue with that…. But the majority of code expense and lifecycle is not in the creation but the maintenance. How do the scripting languages stack up for large scale systems? My experience (which, granted, is primarily applicable to small to medium size systems) indicates that the very flexibility which allows Bruce such amazing productivity hampers further enhancements and bug fixing on the code he writes.

Firefox customization

Firefox, the lightweight browser based on Mozilla, has been garnering quite a bit of attention lately. I’ve been a Mozilla user since 0.5, but only use the browser component, so I thought I’d give Firefox a try. It works great, and is very similar to IE (by design, no doubt). But browsing is a habit of mine, and, like anybody else, I don’t like to change my habits. Luckily, it was easy to change Firefox to fit my needs.

1. Have the search bar respond to my shortcuts (i for google images, g for google search, q for qwestdex search). This was no different than setting it up for Mozilla.

2. Firefox by default saves form entries. I don’t like that–it’s the paranoid in me. Easily changed: go to Tools / Options / Privacy / Saved Form Information and deselect the “Save information…” checkbox.

3. Firefox blithely closes a window when there’s more than one tab open. Wow! I don’t like that at all–Mozilla gives me a warning and 99% of the time, I was aiming at the wrong window or had forgotten that I had multiple tabs open. Feedster handed me this post so I knew I wasn’t alone; a bit of searching on MozDev turned up this handy extension: tab warning. Installing this was a snap, and now my browsing experience is back to what I expected.

One problem I haven’t figured out how to fix: in Mozilla, when you open a link in a new tab, the new tab gains focus. In Firefox, the old tab remains in front.