Why normal people don't like computer security

Today, I wanted to put some money on my Sun Dollars account (ASU's play money system), so I went to do it online. They had changed the system to add money (again), so I went through the hoops of figuring it out. During the process I noticed that anyone in their right mind would never think of putting their credit card number on this web page. As you can see in the screen shot below, there are a number of things that flagrantly violate "Internet common sense":



First of all, I'm handed off to some site that I've never heard of called "jsatech.com". I am doing business with ASU. I've never heard of any jsatech.com and I have no idea who they are. I certainly don't trust them. Fortunately, it is an SSL site, and I'm a nerd, so I can theoretically see some information from the certificate. In this case, however, the vendor has not chosen to purchase a certificate which does a rigorous identity verification. Again, since I'm a computer nerd, I know that probably the only thing they had to do was prove they owned the domain jsatech.com, which really says nothing about their business practices (or even the fact that they are a business that exists). And then they want me to type in both my ASU ID and my credit card number, both pieces of information that should normally be protected from parties we do not trust. I ended up entering the information because I wanted some Sun Dollars. So does everyone else, I'm sure.

This is not an uncommon situation. You want to do something online that requires sensitive data, so you end up passing it off to some third party you don't really trust. In this case, we expect users to deal with this. But then we go around complaining about how "dumb users" don't use common sense when dealing with computer security. I think as computer people, we should probably start following our own advice before we try to complain about other people.

Spring JDBC is awesome

I would like to just take a moment to express my love for Spring JDBC. I just deleted giant swaths of database connection handling code from an app I'm maintaining by replacing a DAO with a Spring JDBC version. If you haven't taken the time to learn about it, check it out here.

Google Health sort of sucks

It seems like Google Health was developed without much consultation with a domain expert. For example, it looks like they just got some sort of shotgun list of lab tests and dumped it into their database:


which of these should I select if I want to record an HDL value? They all seem the same to me.

Then, you have something like EKG which is way more complicated than having a single numeric unit value, and they expect you to just type in a number:



It's a good start, being able to get all of the data stored, but I just wish it were a little more intelligent about the data it is collecting.

Moving code from one SVN to another

I am currently working on merging some of the projects from two different SVN repositories to one repository. I don't want to do a full dump of one and restore to the other, because the organization is a bit different in each. The solution is something like this:

1. Dump the entire source repository
2. Use svndumpfilter to split the dump into separate files
3. Import each file separately into the right spot in the target repository

Here's a couple one-liners to split the dump file (I love Unix):

$ cat source_repo.dump |grep -a ^Node-path: | grep -v / |uniq | sed "s/Node-path: //g" > projectlist.txt
$ for i in `cat projectlist.txt`; do cat svn_oasis.dump | svndumpfilter include $i > $i.dump; done

The first command creates a list of top level directories, and the second does the splitting. Now, you have a separate dump file for each different top level directory in the source repo. This can be tweaked if you want to split it based on different criteria.

Once you have the dump file for a project and you want to import it, you use a command like this:

cat project.dump | svnadmin load /usr/local/svn/myrepo

Make sure that the path you are importing doesn't exist. I did not make sure, then I think svnadmin imported a bunch of stuff, but was unable to create the top level dir, so it probably left a bunch of orphaned crap in the repo. The load process seems pretty half baked, so be careful :)

PHP

Samson pointed out this PHP bug report to me:

http://bugs.php.net/bug.php?id=50696

It is an entertaining read. This illustrates a couple of problems with PHP that make me wary of using it for anything too serious. They seem to have a flagrant disregard for specification of their API, as well as backward compatibility. Additionally, the lack of strong typing appears to be the source of all of their issues. I'm not going to say weak typing is bad, I just find strong typing forces the programmer to resolve issues at compile time instead of at runtime (i.e. before the end user is actually running the code and the app blows up on them).

All of this culminates into this bug report, which erupts into a flame war, uncovering the underlying big egos that have probably led to the feeling that strict specification is unnecessary and developers can just "deal with" changes in the API in minor releases. Both of the PHP developers involved in the conversation were extremely unprofessional and resorted to such tactics as name dropping to argue their case.

It sucks, because I think PHP would be pretty nice if they were just a little more strict and professional about these things (both the technical and personal issues).

X Windows

Recently, I have heard several references to the term "X Windows". For all of you uninformed fools out there, here's the official word straight from the horse's mouth (see man X):

The X.Org Foundation requests that the following names be used when referring to this software:

X
X Window System
X Version 11
X Window System, Version 11
X11

So, as you can see, there is no reference to "X Windows". It has nothing to do with "Windows", so don't call it that.

Sometimes I feel like constructors should be removed from Java

Sometimes constructors in Java are convenient. You can instantiate your class with all the data you need with a simple one-liner:

Car car = new Car(numberOfWheels, color, engine, doors);

That code is fairly readable and concise, but things can quickly spiral out of control. Unless you use really descriptive variable names like those above, it's pretty easy to get lost. Eventually you end up with code like this (partially obfuscated to protect the innocent):

foo = new Bar(rs.getString(1),
rs.getString(2),
rs.getString(3),
rs.getString(4),
rs.getString(5),
rs.getString(6),
rs.getString(7),
rs.getString(8),
rs.getString(9),
rs.getString(10),
rs.getDate(11),
rs.getDate(12),
("Y".equals(rs.getString(13)) ? true : false),
("Y".equals(rs.getString(14)) ? true : false),
("Y".equals(rs.getString(15)) ? true : false),
("Y".equals(rs.getString(16)) ? true : false),
("Y".equals(rs.getString(17)) ? true : false),
("Y".equals(rs.getString(18)) ? true : false),
("Y".equals(rs.getString(19)) ? true : false),
rs.getTimestamp(20),
rs.getTimestamp(21),
rs.getString(22),
rs.getString(23),
rs.getString(24));

This is the point where I say you gotta just use a blank constructor and setter methods. Much more readable. And on a side note, when you are typing rs.getString(24), you should probably start thinking about how it might be more readable if you refer to your result set columns by name. That is all.