LinLog

This week I started dabbling in Ruby on Rails. After reading Scott Hanselman's and Mike Gunderloy's coverage of RailsConf, I almost felt like I had to. So far, I'm impressed.

For anyone who hasn't been paying attention, Ruby on Rails is the current "big thing" in developing web applications. Ruby is a dynamic, object-oriented programming language from Japan. So far, it seems to read like the bastard child of Python and Perl. But in a good way, if that's possible. Rails is an MVC web application framework for Ruby. Through the magic of Rails, you can literally create a working, if extremely basic, database application in less than 10 minutes. No joke.

I haven't had much time to play with RoR yet, but it seems really, really nice. It basically takes all the pain out of building data-driven web applications. Rather than spend your time messing around with database access - buidling the plumbing, designing insert/edit screens, and so forth - rails lets you automatically generate all that stuff. For example, in the tutorials, they just have you create a new Rails application, create a new MySQL database and table, and run a couple of commands. Then you can fire up a web browser and add records to the database. All without writing a single line of code!

The thing that's really nice about RoR is that it encourages good system design. The default Rails application has a proper model/view/controller architecture, includes testing infrastructure, and other good stuff. In other words, it gives you a good starting point. Contrast this with Visual Basic. Bask in the VB 6 days you used to see tutorials on data-bound controls that showed you how to build database applications without writing a single line of code. All you had to do was drag and drop a bunch of controls in the VB designer and voilà - instant application. The only problem was that VB 6 seemed to actively encourage writing really crappy code. For instance, it generated brain-dead default names for all those drag-and-drop controls - why name a control DataSource1 and force the user to change it when you can just prompt him] for th econtrol name? It also made no attempt separate the interface, data access layer, and business logic. In fact, doing that made the magical drag-and-drop features less helpful. And unit testing? Was that even possible in VB 6?

My only complaint about RoR so far is that there doesn't seem to be a lot in the way of documentation yet. Sure, there's the API reference, but not much in an instructional vein. And so far, I'm unimpressed with the two tutorials I've looked at. But I suppose I can let that slide. After all, RoR is quite new - building up a good documentation base takes time. Of course, by the time we get some good tutorials, I won't need them, so what do I case?

Well, I'm back to fatblogging. The last couple of weeks have been kind of busy, so I hadn't gotten to it. Actually, what happened is that I was getting wierd weight readings. I'd be 194 in Thursday morning, 190 in the afternoon, 193 Friday morning, and so forth. My plan was to average out the readings over a few days and post on the weekend. But then I was busy on the weekend and kept forgetting to weigh myself. Hence I never got around to posting about it.

Anyway, I this morning's reading was 189 even. That makes a grand total of 44.2 pounds so far and only 9 pounds left to my original goal weight. Yay!

Eugenia at OSNews ran an editorial today regarding password storage in the popular Pidgin IM client (formerly known as Gaim). Her complaint was that Pidgin stores the user's passwords as plain text, which is obviously insecure. However, the developers strenuously object to her proposed solution: obfuscation.

Basically the situation is that Pidgen does not have an encryption scheme for IM account passwords. Some people have submitted patches, e.g. to use gnome-keyring, but the developers don't want to tie themselve to any particular keyring implementation. So, in the absence of any real security, some users have suggested adding fake security, such as ROT13 encoding the passwords. Their argument is essentially that such obfuscation is better than nothing. The Pidgin devs, on the other hand, argue that this does nothing but provide a false sense of security, which is actually worse than being insecure.

I think the Pidgin developers have a good point here. For one thing, the use-case for obfuscation seems to be a little shakey. The general idea is that obfuscation would keep your passwords safe from nontechnical users who would have local access to your machine, such as a parent or co-worker. Presumably they would be able to find the accounts file, but not figure out the obfuscated password. The problem with this is that tools and methods to "recover" IM passwords are all over the net. All you have to do is Google it. Obfuscation would only stop people who are too stupid to use a search engine and those who are too unmotivated to use one. And for those types of attackers, proper file permissions and locking your terminal when you get up from the desk would be sufficient anyway.

To me, this sounds like a "shut up" feature, i.e. the kind of feature a developer implements not because it is actually good or useful, but because the customer thinks it is good and useful. "Fine, I'll do it if it'll shut you up!" This doesn't add any real security and it's not clear that it would stop even non-technical users who actually want your password, but it would make users feel better. That's the kind of thing you do in the commercial world for a whiney customer. I don't think it has any place in the open-source world.

You know what sucks? Office meetings. And I'm not talking about "office meetings" in the sense of meetings that take place in a room full of cubicles populated by people who die a little inside every day. Although those suck too. No, I'm talking about meetings about Office. Microsoft Office. Specifically, my employer migrating from our current, hideously out-of-date Office 97 plus Outlook 2000 setup (don't ask me why the two versions) to Office 2007.

We've been having these meeting every Friday since the beginning of April. The first one was an entire hour on Microsoft Outlook. The second was 45 minutes on Word and Excel. The third was half an hour on Access. Since then, the meetings have been on the order of 10 minutes a piece and have consisted mostly of someone from the help desk saying that the new version had been installed on so-and-so's PC.

Believe it or not, there is a matematical reason why we continue to waste our time on these pointless meetings even though we've run out of things to talk about. You see, in any bureaucratic organization, the number of total meeting associated with a project is given by the equation:

Here, m is the number of meetings, d is expected project duration, i is perceived importance by management, and s is the sanity quotient of the organization. Note that there is no factor relating to the need for discussion.

In our case, the Office 2007 installations will take a while because we have to do it all by hand - having an automated deployment system would make far too much sense. And since the new version of Office affects every department and is highly visible to users, my boss thinks it's extremely important. And as for the final factor, as a government agency we necessarily have an extremely low sanity quotient. Thus we have a standing meeting, even though it's completely pointless. Ain't bureaucracy grand?

Here's a weird one. For some reason, my Digitalway MPIO FL100 MP3 player can't see files that are copied onto the removable SD card from Windows. But files copied from Linux show up fine. Is it just me, or does that seem a little backwards?

What happened was that I wanted to listen to a few podcasts this morning. I didn't feel like running downstairs to get the SD card out of the MP3 player, and I didn't want to download them from work, so I just dumped the files on my USB thumb drive before I left the house. When I got to work, I whipped out my portable USB SD card reader, copied the files from the thumb drive to the SD card, and slapped the SD card back in my MPIO. I turned the player on, started browsing the playlist and...nothing. The files just weren't there.

My frist thought was that something must have gone wrong. Maybe I disconnected the card too early and the files didn't copy. So I hooked the SD card back up to my Windows XP workstation and checked. Hmm.... The files were definitely there. Were they corrupt? Didn't seem to be. The file sizes looked right and they played in Windows Media Player.

Maybe it was because the card was almost full. It's a 1GB SD card and there were only 6MB left. Maybe the MPIO can't quite address a full gigabyte. So I moved the files I was trying to play off the card, deleted a few old files, and moved the new ones back. OK, now I've got about 50MB free, which has always been enough before. But when I plugged the card back into the MPIO, it was still a no-go.

After a few more unsuccessful variations on this same process, I started to wonder if the problem was with the SD card reader or even Windows itself. After all, this never happened with my internal SD card reader on my home Kubuntu system. So just for the heck of it, I fired up a copy of Kubuntu running in VMware. I plugged in the SD card reader, moved the MP3s off the card, unmounted and remounted, and moved them back on. This time, when I put the card back in the MPIO, it saw the files. I was able to select them in the playlist and they played perfectly.

At this point, the question is: What the hell happened? According to fsck.vfat, the SD card uses a FAT32 filesystem with long filename support and doesn't show any errors. Theoretically, Windows should be able to read and write that with no problems. And it can - but not in a way the MPIO can read. Is there some extension to FAT32 that Windows uses but Linux and the MPIO don't? Is this due to some implementation-specific detail where the MPIO agrees with Linux but not Windows? There's got to be some rational explanation for this. Does anybody have any ideas?