Team 449

Configuring postfix is well-known to be the hardest, least intellectually stimulating task any IT person will ever pass off to a hapless subordinate. I, unfortunately, would seem to be that hapless subordinate. Eric recommended (and, in fact, convinced me) that I write a perl script to act as a delivery agent for postfix. This would offer grate flexibility, customizability, blah, blah, blah. Not to drag out the story, I got to a point where I realized I had a 200 line mess that didn't work half of the time, wasn't properly interacting with postfix, and needed another 1000 or so lines to do what was really required of it. So I dropped the project, and fell back to using mysql aliases, which looked to me like the easiest option when I need relatively dynamic mailing lists integrating with custom software that uses mysql.

After various delays of the server-is-down sort, I've finally finished fixing the indexing software, and FIRSTSearch is ready for (beta) release. It's by no means an incredible piece of software - it has some bugs, it wants some features, the display of results is less than perfect, and I have my doubts that it's really finding the most relevant results. But it's working, and it's ready forr other people to start to use.

I expect to have a non-beta release within a few weeks.

From an initial glance, it appears more new members came today than last week. Though that does help the team, the room's limited space fits only so many people. Mechanics demonstrations such as tapping and sawing took place in the main room while Eric instructed inventor to veterans in the computer room. Scott and his tech crew were in the backroom as usual. But, the Labview introduction transpired in the hallways with Winifred resting on top of a recycle bin (Well, it IS getting old and slow). Since Daniel was out sick, Jacob had to improvise on the tutorial. It seemed the flu got to him though as he was more calm than usual. Maybe he should have gotten a cookie.

In the third after-school robotics meeting of the year, I ventured into that frightening and mysterious land of operating system development. It's the hardest thing you'll ever fail to do - and I started it while listening suggestions for the name of this OS. I think Freddy ultimately decided on "Sloth". Great day. Interestingly enough, the only hard-core programmer who I told about this project who did not inform me that it would be an utter failure was also the only person I know who has ever worked on writing his own OS (although it wasn't very successfull). So I'm hopeful - probably more so than I have a right to be.

Briefly, I can now start up the computer and print an 'A' to the screen. That means that I can claim to be 3 months ahead of schedule, since I wasn't planning on starting this project until early January (I got bored). Of course, when I tried to print an 'A' to the second line, I got a blue rectangle instead. But hey, that's pretty cool too!

Now for the long story. Walking in today, I had made progress: I had acquired several computers to be used for this project and some other (all the meantime fighting back the greed of my bosses, who actually wanted to use them for things that were - god forbid - practical *shudder*), I had acquired a floppy disk on which to write the OS, and... well yeah, that's about it. I also knew nothing about how to write an OS.

First, I set up grub. It turned out to be pretty simple. Next, I started figuring out how to write the OS to the disk (no, I didn't have an OS yet - did I mention that I've never done this before?). At this point, Freddy pointed out that I could just store the file on the hard drive, and have grub read it. Oh. Right. Thanks. And I spent 45 minutes acquiring that floppy disk why?

Next I went to my favorite wiki, and looked up the boilerplate OS code. Pretty simple, so I copied it onto qweffor and ran it. Well, actually, I told qweffor to reboot, but I was logged on via SSH, so I had to walk over to the room with qweffor in order to watch what was happening. Freddy had already started up the right OS. So, yeah, it had printed out an 'A'. Grub had also printed out some stuff. I specified that grub should be 'quiet', and retried, but that didn't fix it. So I got a message like:

Aooting from (hd0,0)...

I decided to let that message appear, and print out the rest of the stuff to the following lines. So instead of just setting the first character to be 'A', I set it to be a newline, and set the second character to be 'A'. Result: a blue square with a white circle in the middle. Then I had to catch my bus.

Result: its time to actually read the documentation. And for those of you who were planning to look on, you didn't miss much.

Oh, and today was the first day of training for freshmen. Not that that's unimportant, but it was somewhat less than exciting...

I recently completed a manual migration of my data for CTDA (an analysis system for team data collected from thebluealliance.net and other sources) to PostgreSQL from MySQL (see my comparison for why). By 'manual', I do not mean that I typed the data in by hand - I mean that for each table, I wrote a separate script to transfer the data, instead of writing (or finding online) a single script to copy a whole database. My advice to you, if you are planning to migrate data to PostgreSQL from MySQL, is this: don't do it by hand.

Let's assume I would have been unable to find a workable script online to transfer the database for me. This is unlikely at best, but if I couldn't, I could probably have written one that would cover all the cases needed for my database in about 3 or 4 hours (I'm rather new to postgres). So I sit down one day, write the script, test it a bit, and set it to run overnight, and I'm done.

But that's not what I did. I decided that it would be 'easier' to write a script for each table. Perhaps it saved me some thinking - but the process ended up taking me two weeks, and much more than 4 hours. I would estimate that, because of this delay, CTDA will be released 3 weeks later than it would have been if I had written a good script to do this for me.

Oh, and in case you can't guess. My advice to those who are planning to migrate from PostgreSQL to MySQL: don't.