My junior CSU670 “Software Development” class with Matthias Felleisen at Northeastern will forever be one of the most tortuous ordeals I will have ever lived though – but also probably the most rewarding. To this day, I still wake up from nightmares of me sitting at one of the Solaris boxes in the CCIS computer labs talking with other classmates and they ask me what other classes I am taking that semester; lo and behold I can’t even remember one of the 3 or 4 other classes I am supposed to be taking that semester, all I can think about is Software Dev and that I LIVE in this computer lab!

After passing the class from hell, a few of my friends and I made a pact of sorts that we would (one day) continue on with our code from the class and improve on it, because it really was probably one of the largest projects we had ever worked on.

If you have never heard of Squadron Scramble, no worries, I don’t think anyone in the class had ever heard of the game either. It’s a rummy style game but you use aircraft cards with aircrafts from World War II (oh, so appropriate since our professor is German.) Our class rules were modified from the original game, but the basic premise is that you collect three of an aircraft type and can use that to “shoot down” other aircraft trios with a few other wild cards thrown in for good measure.

We were required to pick a programming language and work in pairs and practice paired programming. I had mixed results in past course with paired programming but in this course it was absolutely critical that you have a well functioning team to carry out each week’s assignments, otherwise you would be behind for next week’s tasks because every week built on the weeks before it.

The tasks finally built up to us creating our own game server and administration as well as clients to connect to our server and other student team’s servers. We also had to create dumb artificial intelligence and come up with “player” strategies to try and beat each other with our “players.” And this was all using ugly XML syntax and we were only allowed to use the aging and severely out-dated Solaris machines. We also had to come up with a GUI interface, and did I mention that yes, it all had to work on the grossly out-dated Solaris machines?! That means using Tcl/Tk instead of all the new flashy goodness of anything else developed within the last decade.

With that said and done, my buddy, Ventz, asked me earlier this week if I had time to develop a Ruby client and server and bring the project back to life. My one request was that instead of XML we use JSON instead to make our lives easier. He was going to take a stab at re-writing a Perl version of the code and hopefully get a few other ex-CSU670ers to chip in a Java version and whatever other version they’d want to contribute. My first task is probably to write out a proper spec and improve upon on some of the universally despised guidelines in Matthias’ original spec.

If you’re interested in seeing the final code I wrote in the class, hop on over to my Subversion repository: http://svn.rachelober.com/csu670/ I think this is pretty much the final version of the code that I submitted in the class. I’m almost certain this will not run on anything unless you can get your hands on one of CCIS’ old Solaris servers (which have since been “taken out back” and summarily assassinated,) but I’ll add a disclaimer anyway that the code is provided “as-is” and under no warranty. If it screws up something on your system when you try to run it, sucks for you!

Maybe one day we’ll get some kind of game server to run and we can all play some crappy aircraft card game over the internet.

The Xcode muckiness wasn’t as bitchy to overcome by just fiddling with some of the settings to get it to work with my company’s code – but the problem also was that the new Xcode that ships with Snow Leopard totally got rid of all the previous iPhone SDKs I had. My company still runs most of our iPhone apps off of 2.2.1 and Xcode for Snow Leopard only does 3.0. Unlike my co-worker who practice more forethought than I do (so what, call me ignorant), I didn’t have a backup of the previous Xcode stashed somewhere else. Adam showed me a tricky trick in the new Xcode and you are able to still use the new 3.0 SDK but set the deployment target to whatever the heck you want.

OF COURSE, with the new iPhone 3.1 SDK, they’ve included all the previous iPhone SDKs to work with the new Xcode 3.2, thus eliminating my rage, but a little too late for the heartburn I was experiencing earlier this week.

Now, getting ruby on rails and our projects running on my laptop has been a bitch and a half and I’m still pulling teeth just to get things working locally. I was being a tool and just deploying all of my test code to the integration server to test for the past week and a half just so I could get some actual work done before Labor Day. I’m sure my co-workers didn’t appreciate that. :-p

Getting PostgreSQL working with ROR and installing the proper gem. I used to use pg but that was not working. I’m instead using postgres-pr and that seems to get mongrel up and working on my local environment. Make sure to change your ARCHFLAGS to ‘-arch x86_64′ if you originally had it set to i386.

http://railsforum.com/viewtopic.php?id=34110

I had to totally uninstall things like my MacPorts and rubygems and postgres and install everything from scratch again. I also had problems with my paths and I was constantly pulling up the wrong version (i.e. Snow Leopard’s version) of ruby and postgres.

Originally I had thought that just by recompiling everything the Ruby on Rails guys suggested, I’d be golden. But that just didn’t work out for me.

I think I am just going to reformat everything this weekend and follow this guy’s advice. What a mess!

Oh well, rant over. Hopefully I can post about a more successful Snow Leopard install next week.