Last night, I was doing some work in MATLAB related to matrices. What was I doing? I don't know, clearly I need some hobbies. Specifically, I was trying to compute the eigenvalue for a matrix closest to a certain value. There's a formula for this that's well understood, the shifted inverse power method. I had a hard time translating that method into an algorithm, however. After many hours of typing, cursing, and weeping, I hit upon the answer. I will thus present it here, so the nerds of the world can soak it in.
%Modified Shifted Inverse Power Method
%Adoped from Dr. Kincaid's pseudocode, UT CS dept.
%Supply a matrix A, a vector x, the number of iterations
%desired, and the value for which you want the closest
%eigenvalue.
format long;
%set up the matrices.
[n,n] = size(A);
B = A + abs(near)*eye(n);
C = inv(B);
%perform the iterations.
for k=1:steps
y = C*x;
r(k) = x(2)/y(2);
x = y/norm(y);
end
%In case the series is slowly converging, we do some Aitken
%acceleration here.
for k=3:steps
s(k) = (r(k-2)*r(k)-r(k-1)^2)/(r(k)-2*r(k-1)+r(k-2));
end
eig = s(steps) - near;
Man, who among us doesn't feel the adrenaline when viewing that function? To verify, A*x should equal eig*x. If not, either your computer is broken or I messed something up. One is much more likely than the other.
In the past, I've tried to experiment a lot with Linux. Invariably, these experiments fail, mainly because I have no idea what I'm doing. I'll get 90% of the way to a working desktop, but in trying to get my sound card to work, I'll trash the entire hard drive. Woops. And then I repeat those steps a few times until I relent and turn my hard drive over once again to Windows Solitaire. Like washing my car, it's something I do twice a year like clockwork.
For a project I'm currently working on, I needed Redhat Fedora installed on my machine. There was great gnashing of teeth when I first heard that; history has shown I can't control anything more powerful than an etch-a-sketch. However, I soon learned that someone else, an honest-to-goodness expert, would there to do all of the hard installation stuff and I immediately began to ungnash my teeth. And you know what, after he installed it, everything worked immediately. My USB mouse worked, my sound card worked, my network card worked. I was living the dream, brothers and sisters.
And then I took the box home so I could do some work there, and this is where the fun begins. Once I loaded GNOME up, I noticed that it didn't seem to be repainting things correctly. Whenever I tried to pull down a menu, it'd be transparent. The same thing happened with buttons, and I wouldn't be able to see either until I moused over those UI elements. It was very, very odd. So odd, in fact, that I quickly went from pleasantly bewildered to pants-wettingly confused.
I tried a hundred different video card/monitor combinations, but I couldn't get anything to work. I begged for mercy at the feet of my guru friends, and they were baffled as well. For whatever reason, it looked like there was a blood feud between Redhat and my Intel 810 video card.
Eventually, after one hundred billion searches on Google, I stumbled across a newsgroup posting that contained the answer. I share it here in case anyone else has a problem with their Intel video card and the window managers contained in Fedora Core.
In /etc/X11/xorg.conf, you need to make a small edit. There's a block of the file that looks like this:
Section "Device"
Identifier "Videocard0"
blah blah blah
EndSection
Somewhere before that EndSection, you need a line that says
Options "noaccel"
Once you have that, restart GNOME/KDE/whatever and get ready to have your pants blown off. Not literally, but computationally, as a brand new world of viewable menus and buttons will open itself up to you. It's a powerful experience, and one I never would've figured out without a whole lot of help. So, if Linux wants to scare me off this time, it's going to have to try something a little different. For example, it will have to prevent me from installing any new applications, as I'm currently experiencing. I'm convinced this is just a minor stumbling block, though. With buttons and menus on my side, who can stop me?
As I mentioned a while back, I've been getting more serious about using a scripting language for some of my programming duties. I've done a few simple scripts, but nothing to wet my pants over so far. Until today, that is. And today's pants wetting had absolutely nothing to do with an actual script, but a really cool use for a scripting shell and a way to eliminate the plague that is the Windows calculator from my daily routine.
Like a few other developers, I have to write a lot of number crunching code. I'm not modelling the explosions from Dom De Luise's bathroom or anything complicated like that, just munching on a few formulas. I soon discovered that no matter how good I thought I was at mental math, I still had to check the results of the formula with an honest-to-goodness calculator. Well, since my development machine is a Windows box, I have always used the calculator that's bundled with Windows to check my results. Let me tell you this right now: if the folks at the Apollo project had used the Windows calculator to get us to the moon, there'd be a bunch of monkey corpses in orbit around the planet.
The Windows calculator works okay for really simple calculations, but it's a complete donkey when you get to "complicated" things like negative numbers and parentheses. Also, it's very mouse intensive, which doesn't work well for a keyboard fiend like myself. To prove all of this, just try typing in -1 - -2; I wouldn't exactly be betting my life's savings on the results of the Windows calculator.
Today, the formula I had to check was a pretty simple one:
x - abs(z - y)
That's not exactly something that would keep Euler up at nights, but I knew it would cause the Windows calculator to foam at the mouth until animal control could put it down. In fact, looking at the program now, I can't even see how I would do absolute value. What I wanted was just a simple, command-line calculator, but I didn't really feel like searching and then downloading one, or writing one myself. What could a single, pathetic, shadow of a man like myself do?
Here, inspiration struck. I started up Python Interactive Shell (aka Python.exe). When you're in Python's shell, you can run individual statements interactively. That's exactly what I did, first assigning a few variables and then running the formula. It worked perfectly the first time. At least I think it did; it was hard to see through the tears of joy.
Today, I found a benefit of scripting languages that I had never previously considered: quick mathematical evaluations. It might not sound like much, but to those of us who have been slogging through the Windows calculator ghetto for years, it's like a lobster buffet.
I said I was working on a massive entry and I still am, but it shall be superceded today because I just can't keep this to myself. Much like finding the Wolf Man hiding in your bath tub, it's too weird for me to keep this to myself.
As part of a project I'm working on, I needed a specialized installation of Fedora on one of my development machines. Thankfully, a fellow member of the project had already scripted the whole installation out and written it to DVD, thus making it one of the easiest Linux installations I've ever participated in. It's funny how easy things get when I'm no longer allowed to touch the keyboard.
Anyway, after we got everything installed and operating, I brought my machine home and booted it up so that I could do some poking and prodding. It booted up great into GNOME, and then took my username and password with nary a hiccup. And at this point, the machine elected to soil itself. After I logged in to the desktop, I couldn't seem to do anything. I would click on a menu, and nothing would appear. Or I'd double click on an icon, and the outline of a window would appear but I wouldn't be able to see anything inside that icon.
Compounding the weirdness, UI elements would start to appear if I moused over a certain part of the window. Example: I'd be looking at this blank window, and then I'd move my mouse over the corner of the window and suddenly I'd see an OK button right under my cursor. Menus worked the same way, in that if I were to move my mouse down where the menu should be, the menu items would start to appear. Kind of weird, but I've certainily had stranger things happen to me before (I refer back to the Wolf Man in my bath tub).
At this point, I figured I could probably solve this problem by myself. After all, I have the INFORMATION SUPERHIGHWAY at my finger tips! I fired up a trusty web browser, and searched for "gnome docs". From that, I derived no prosming results. I fine-tuned my query a little bit, changing it to "gnome help". Again, no luck. I seriously began to wonder whether GNOME was a piece of software, or a product of my own delusional mind.
It occurs to me that if anyone wants a reason why users aren't flocking to open source for their personal operating systems, they may want to reread the preceding paragraph. I tried the two most obvious web searches for help, and I got nothing. Then I tried the project's website, and even I couldn't find anything approximating documentation. This is one of the most popular pieces of software in the world; why make it so hard to read about it? Is the project run by the Freemasons or something?
After a few hours of searching, my problem is no closer to being solved. I have, however, found the GNOME docs. And just in case Google happens to be watching, let me do that again: GNOME docs.
Okay, I'm working up a monster post, but I wanted to do something shorter first. And by monster post, I mean it. This post will eat your young and then storm the Count's castle. But first, a little something to do tide you over.
I was stuck in an unlikely situation lately, where I had to transfer a lot of data from MySQL to SQL Server. If you search online, you'll see a lot of results for that, but not in that order. Everyone has written about going from SQL Server to MySQL, not the other way around like I wanted. In fact, the only real bit of info I could find was on the Microsoft website (big surprise). It was certainly useful, but it was way too long. I've decided to simplify it in a few short steps.
Step 1. Install the ODBC adapter for MySQL off of MySQL.com. Create an ODBC connection to your MySQL database.
Step 2. Create a new DTS package in SQL Server. You'll two connections: one to an ODBC datasource, and the other to your SQL Server.
Step 3. Create a Transform Data Task, going from the ODBC connection to SQL Server.
Step 4. Select the appropriate Source tables in MySQL, and point them to the correct Destination tables in SQL Server (you can instruct the DTS package to create these tables if needed).
Step 5. Let it rip.
Hey-o, that's some simple stuff! And for those of you in the Windows/SQL Server world who aren't familiar with DTS packages, you should definitely give them a look. They're a really simple, powerful way to transfer and transform data from one db to another. The best intro I ever stumbled across was in Robert Vieira's SQL Server book.
Yes, you could certainly write the code yourself to do this transfer, but I have better things to do with my time. I have cookies to eat, corndogs to burn, and monster posts to create. Here are some good DTS resources:
DTS Best Practices
SQLDTS.com
Good day, gentlemen and gentleladies, I'd like to discuss a little bit about installation packages today. If I had to pick the one thing I like the least about my job, it's cleaning out the hogs' slop bucket. I hate to say it again, but why does a software company even need a hog pen? Anyway, a close second on that list is making the installation packages for the software that I write. Those setup.exe's are certainly important to create; if the users couldn't use my software, I'd essentially then be getting paid for blowing my nose. The irony is that as important as those installs are, they're a complete pain in the rear to make. There are a myriad of tools you can use to create these setups, but in my professional opinion, they are all converge on crappiness.
One of the most popular tools for creating install packages for Windows is InstallShield. I don't have any numbers on this, but it seems to be the most prevalent tool from my own experience. Speaking for all InstallShield users everywhere, how on earth did this happen? To me, that's like licorice-flavored jelly beans taking the country by storm; there's just no reason why something so lame should be so popular.
I realized this the first time I ever used InstallShield to create an install. It was a little complicated, but I managed to get something built after a couple of hours. I did a test install of the package, realized something I had done wrong, and then went back to InstallShield to fix it. So far, InstallShield and I were as thick as thieves. Once I made the fix, I tried to build the setup again, and here's where InstallShield lobbed a pie at my face. Apparently, InstallShield Developer can't create a setup.exe in a directory if you have that directory open in Explorer. That may not sound bad, but in actuality it's like french kissing Darth Vader. Allow me to explain.
I rarely do InstallShield; my time spent there may average out to half a work day each month. So, each time I build a new package, it usually takes a few times for me to get it right. I suspect this is the case for a lot of other InstallShield develoeprs. By instituting that completely bizarre rule about not having certain directories open in Explorer, InstallShield makes a difficult process even more onerous. If I'm going to be rebuilding this package several times in a row and then installing it, it's only logical to keep that directory open in Explorer. Perhaps I wouldn't if InstallShield placed the setup.exe file somewhere other than at the bottom of 10^100 subdirectories, but that's just the way InstallShield rolls: slowly and with total disregard for others, like a 90 year old at the wheel of her Cadillac.
Does any other compiler work that way? Compile something with Visual Studio .NET, or gcc, or Java. Does the compiler give a flying foofoo what directory you have open? Why on earth would it care? If they don't work that way, why does InstallShield? Someone get me Encyclopedia Brown; I'll never solve these mysteries on my own.
On top of all of this, I return to my original question: why InstallShield? How did something so intolerable rise to greatness in the world of software development? Does the InstallShield CEO have incriminating pictures of Bill Gates and his french maid? Or is it possible that creating setup packages is really that difficult? If anyone would like to beat me over the head with a cluestick here, I'd really appreciate it. And until someone does so, I'll be tending to the hogs.
A colleague made an interesting point today. At work, we're supposed to be delivering a new piece of software in the near future, and so the task was assigned to a small team. Over a span of a few days, these folks sat down with a whiteboard, a laptop, and a projector, and worked through what this software would do. They had ideas for all of the screens and functions, and they even started pseudocoding some. Once they were finished, they thought that most of the work was completed. True, they didn't have any code yet, but they had the ideas and the structure in place. Prepare the cradle, because that baby's ready for beddy-bye time.
The end result of these meetings was a big document that detailed everything about the software. Just translate the document into code and everyone could move on to something new and sexy, like how to make robots mud wrestle. However, it turned out that translating that document into code wasn't exactly easy. In fact, it was just hard enough to make the process frustrating.
Apparently, working sequentially through a spec document like that isn't very conducive to programming. A lot of times when someone is programming something, they'll carve off a chunk of functionality and work on it until it's done. That's what the developer here wanted to do, but that wasn't how the document was laid out. Instead, all of the functionality was interspersed throughout the document. There could be three consecutive documented functions, and the functions could be for vastly different parts of the package. Perhaps one was for button handling, one was for inserting records into a database, and the last was for stripping characters from a string.
All of those are valuable functions to have, but if you were coding without sucha document, you usually wouldn't do those three in succession. Instead, you might do the button handling with the rest of the UI code, then all of the database functions, then the string functions. It's much easier to get on a roll like that. If you constantly jump from one functionality group to another, that flow is interrupted because you have to continuously refamiliarize yourself with that part of the code. I feel a metaphor coming on.
It's like making a salad. When I make a salad (which admittedly isn't very often), I tend to focus on one part of the salad at a time. I don't tear off a piece of lettuce, chop one slice of tomato, drop in a few specks of pepper, mix all of that together and then repeat 50 times. No, I tear all of the lettuce at once, then chop all of the tomatoes at once, etc. It's a lot quicker that way; I minimize the lost time that comes with switching tasks. And then, when I'm done making the salad, I dump it all in the trash. Health food and I get along like Bill O'Reilly and Flava Flav.
There's no question that thorough specs like that make the developer's job easier. However, if they're not organized very well, they can also be a hindrance. The key idea, I think, is to be flexible enough to work those documents into our regular working routines. Allow the developer to change the structure of the document as she sees fit, and give the document creator a few tips on the best way to organize the functionality. Otherwise, working from the specs could take just as long as not working from the specs.
I will be honest: lately, I've been neglecting the vlog a little bit. Unfortunately, real life often gets in the way of shaking my web thang, and I end up treating the vlog like a rented burro. Oh, but you are much more than a rented burro to me, vlog! I will vow to do better.
Recently, I managed a free subscription to ACM Queue by filling out a form on their website. That's awesome; Queue is one of the best programming magazines out there, and I got tired of waiting for all of the articles to become available online. Well, the March issue is all about patching, which is pretty interesting in itself. Since I am completely incompetent on the subject though, I have nothing to say about it. What I would rather comment on is the editorial at the end of the issue by Jef Raskin (who sadly passed away quite recently; the technical world is surely worse off without him).
The title of the piece is "Comments Are More Important Than Code", and it lays out the idea that the best way to go about development is to document first, then code. It's a good idea, I think. It forces the developer to think through what she's doing, and discourages a "shoot from the hip" mentality. Also, it makes maintenance much, much easier because a thorough explanation would exist for each piece of complex code. I like the idea a lot, but I don't think it would work well in practice.
Let's assume we all shift to this mode, where we're commenting first and coding second. What happens the first time an emergency occurs? Let's assume it's something really critical like a stock trading system, and each minute of downtime represents a cost of thousands. That's a lot of halibut. Let's say you're the guru of the system, and you could implement a fix in 2 minutes. Maybe it's a tricky fix that only a fellow guru would understand, so in order to hold true to Raskin's idea, the comments would have to be lengthy and thorough; perhaps it'd take 3 times as long to comment your change as it would to actually perform the change. How do you justify that additional downtime? Would you be comfortable going to your boss and explaining the loss of thousands to her? I wouldn't. I get antsy going to my boss when we're out of Kleenex, so telling him I intentionally lost thousands more than what was necessary is enough to give me the vapors.
Most of us would probably just make that change, and let the comments slide that one time. But what happens then? Your comments, which are supposed to be the heart of the system, are no longer current; they don't reflect the current system, so Raskin's whole concept of commenting is undermined. Each time you looked at the comments, you'd have to compare the explanation to the actual code to see if they're correct that time. Now your job is twice as complicated. To me, that's not a viable solution.
Now, Raskin certainly knows what he's talking about more than I do. He was, after all, the guy who started the Macintosh project, whereas my biggest accomplishment is winning Wimbledon on Very Hard in Virtua Tennis for PS2. I think his idea is a good one, and would almost certainly result in better software products. I just don't know how feasible it is in reality, though. It's hard to justify another level of complexity in an emergency, and it's during these emergencies that our jobs are the most visible. It's critical there to deliver quickly and adequately, not necessarily to deliver brilliantly.
As developers, we invest a lot of time into creating these great processes, only to discover these processes aren't helpful during times of crisis, when a process should matter most. How do we fix that? Do these great processes lack the flexibility that our duties necessitate? I don't know the answers to these questions, but I try to give them an honest effort here on this site. Virtua Tennis is another matter entirely; any questions there could be answered in two shakes of a lamb's tail.