It’s been a strange week – it seems that I decided, once I was almost done with the search engine, that it was time to start some more crazy projects. The disease is catching – Eric has his own project, not yet approved, that even I consider to be extreme. We won’t go into it here.

My three projects are, in order of dubiousness of completion: an in-house listserv to be hosted on ogodei, an IRC server, and an analysis system for FIRST team data (not yet online). The first two will both be linked to the Eric’s “Team Management System” – which is what makes them especially challenging. The third is designed to find patterns (defined by me as a lack of randomness) in team data, including sponsors, team size, geographic location, and performance at competition. Obviously there are some trivial patterns with which I can test the system: “hey! most teams in the D.C. region go to the D.C. regional!” My hope is to find something slightly more useful than that: “hey! everytime ARL decides to sponsor a team, Microsoft joins them the next year!”

ListServ

Truthfully, the listserv is not an entirely new idea – we’ve been working on getting it to work for the past few weeks, only in 20-second installments. The complication is that we want to have postfix look in our mysql database of users to figure out where to forward messages. As of this writing, you can send an email to an address like aardvark@team.robot.mbhs.edu and it will be received by everyone specified as an aardvark. There are just a few problems.

First of all, team.robot.mbhs.edu is hosted on ogodei, whereas robot.mbhs.edu is on binx. So to get an emailing address aardvark@robot.mbhs.edu, the DNS server has to forward one port but not the other.

In addition, as it is now, the reply-to header in the email is the original person, not the listserv. That means that when you just hit ‘reply’, most people aren’t going to be able to see your message. The fix is to use canonical, not virtual, redirecting.

IRC Server

Although the IRC server is not the least-likely-to-be-successful project, it is the one for which plans are the fuzziest. Right now, all I know is that I’m going either going to find an IRC server and modify it so that the login information comes from mysql, or write my own. Either one is perfectly “doable” in a few weeks – its a very finite project. But the plans are still worryingly fuzzy.

Furthermore, the IRC server on ogodei has only been approved “on a trial basis”. In other words, there is a lot of worry that people will abuse it (inappropriate content, chatting during class, etc…), and it will have to be taken down. Programming in restrictions, and moderating the system, are both going to be rather difficult to do.

Team Data Analysis System

And now for the least-likely-to-be-succesful project of all, which I’ve named CTDA in the absense of a better name. The “Comprehensive Team Data Analysis” system would be a system whereby everybody can query a central source of data stored on ogodei. The point would be to find patterns in this data, which might prove useful for scouting, getting more sponsors, or maybe something else.

This project is unlikely to be very successful both because of the extreme complexity of the coding involved, and because there may not be many patterns that are really that interesting. As an example of the first, consider that if multiple people make long-term queries at once, the server will die between the five threads each trying to use 100% CPU power. I therefore have to set it up so that the query scripts are executed with long breaks in between commands – which may mean hacking at the B module – perl’s backend. Not a pretty sight.

At least some of the coding is spared – the kind folks at the blue alliance have an API in php, ruby, and C#.net for their databases (I plan to write a perl port). So I don’t have to write bots for their site.

Related posts: