colin dellow's bln

Brett really wanted to have a Craft party. And he got one... eventually. Unfortunately, we had 1 too many players for our existing network topology, so we ended up rigging up an abomination of a network.



Pictured above left: The tools we had to work with. Above right: The 200 foot Ethernet cable Brett made for the evening.

The final solution involved two really long Ethernet cords being run outside the house and our VoIP phone adapter being used as a bridge [For some reason, I hear Dr. Marvin Monroe: "People! This is not the way to get healthy!"]. Anyway, it worked out in the end and we had two good games. One thing I have learned: When you have the windows open so you can run cables between floors, you really don't want to have the lights on or else you will get lotsa-lotsa-lotsa-bugs.

Finite Simple Group of Order 2
Mario A Capella

As narrated by Daniel Marantz, on the topic of a vicious SE 240 assignment due that day at 6PM, and whose due date had already had 2 extensions applied to it:

I peel out of the driveway at 5:57 and start racing to school. I'm tailgating some jackass who won't drive faster, and some crazy woman is tailgating me.

I pull up to the service entrance to the MC [Math and Computer building - where the assignment is due] and double park a vehicle. The crazy woman triple parks that vehicle by double parking me -- turns out it's Andrew Scherkus from our class, with really long hair.

We head up to the drop boxes and have to fight through a crowd of about 15 people who are blocking the dropboxes from sight and trading answers as fast as possible. You can't help but get the feeling they've chloroformed the TA and tucked him in a closet just so they can finish their assignment.

Ah, SoftEng. They said our work habits would improve; they lied.

A friend of mine recently turned to Workopolis after investigating using a headhunting service. He simply felt the high commission charged by the service wasn't appropriate for his businss, as it was indeed still in the early stages of growth. He was open to using the service later on in his business... until he received this from the recruiter (I write from memory here, apologies for the paraphrasing):

Good luck with your job posting...just remember, you will never get top-quality candidates from postings!

Clearly this man wasn't there when God was handing out tact. The business opportunity has walked out the door, and here he is, twisting the knife, when he should be saying, "I'm sorry we didn't meet your needs at this time. Best of luck with your search for a candidate, and please get in touch if we can assist you in the future!"

The irony? My friend's business is training customer service representatives to prevent lost business opportunities such as these.

I have long held a special place in my heart for the programming language known as MOO Code. Developed by Pavel Curtis at Xerox's Palo Alto Research Centre, MOO was a language far ahead of its time -- but sadly restricted by having to be hosted within in its own server.

On a MOO I frequented, MOO Canada Eh?, one of the tests to become a programmer was to explain what the following chunk of code did [1]:


#3127:"duck" this none none
1: $msg:mtell(d = {args[1], player}[(iobj != args[1]) + 1], "duck_" + {"successful", "failed"}[((g = this.gonna_get_pied) == (this.gonna_get_pied = setremove(g, d))) + 1], this.owner:title(), d)

This code illustrates much of why I loved that language -- so flexible, so terse, so delicious! In the PickAxe, I have come across an absolute gem of Ruby code [2]:

def once(*ids) # :nodoc:
  for id in ids
    module_eval <<-"end;"
      alias_method :__#{id.to_i}__, :#{id.to_s}
      private :__#{id.to_i}__
      def #{id.to_s}(*args, &block)
        (@__#{id.to_i}__ ||= [__#{id.to_i}__(*args, &block)])[0]
      end
    end;
  end
end

I think I'm going to love this language.

[1] Code to allow would-be targets to duck pies thrown at them by villanous MOOers.
[2] Code to implement dynamic method-result caching in Ruby by invisibly altering the method table.

I recently purchased Programming Ruby (2nd ed.). I am richer for it.

Due to ambiguities and differences in marking styles, the class average on the lasagna problem was less than 50%. I am so pleased that I did not do this question.

...is becoming less of a crazy-academic-who-codes-in-LISP guy and more of an insightful-chap-whose-essays-are-interesting-and-who-I-might-possibly-want-to-emulate guy.

...no, not in residence, but in the computer labs.

It's apparently 40 degrees Celsius with the humidity (http://weather.uwaterloo.ca/). Midwood lacks air conditioning, but it does have 2 high-speed internet connections... I think I'll just work from home from the air-conditioned computer labs at school, thanks to the miracles of Remote Desktop.

...Buy this book!

I cannot believe that I have missed out on Ruby on Rails for so long. Not only is Ruby a wonderfully expressive language, but the Rails framework is incredibly powerful and cuts out much of the grunt work, the "heavy lifting" (as Shriram Krishnamurthi put it in his recent University of Waterloo talk about the Scheme-based web server for the modern era).

Dan and I are speccing out a project to be built with Rails - look for it!

Well, the CS course assignments are among us, and with them, the standard laundry list of complaints and bitches.

I skipped doing a question worth 1.2% of my final mark because it was taking the class, on average, about 4-5 hours to do. The question involved a lot of tedious repetition, which the instructors felt were somehow worth it since it was just so damned academic. Undoubtedly, this is a sign of how useless this course will be - 5 hours to produce a formal UML specification of how to make ... get this ... a lasagna.

The next assignment for the course is now out and the instructors are showing signs of cracking. Requirements are being revised. Holes in the assignment specifications are being exposed. They're cracking!

One aspect of the assignment included the flexibility to book an item for a specific Time. Now, a Time can be an Instant, or it can be a Period. A Period is a time-range from one Instant to another Instant. An Instant is one moment in time -- 10:30 on Tuesday. Here's what the course co-ordinator has to say about it, in her post to the CS246 newsgroup:

A period is a type of time, as is an instant. An instant is something
like 10:30am on June 2nd, 2005. A period is something like 10:30-11:30am
on June 2nd, 2005 (though obviously the dates could differ). So, a period
consists of two instants, a "start" and an "end" instant.

Now, it turns out the booking system really only uses periods, and not
instants, but it's more general to pass in parameters of type Time. You
can either blindly assume it'll always resolve to a Period, and hope nobody
ever messes up, or ensure it is a period in a reasonable fashion, but
frankly, I don't really care which you choose since that's not the point of
the question. The point is to get you to implement some simple classes in C++,
and read through some code to figure out what operations the classes need to
support.

Eventually, she realizes that its retarded to book something for an Instant (yes, I'd like to book a room for exactly one second.) and she changes the specifications:

Using Time gives us generality, though in practice we'll only be using
Periods. You are not required to support Instants. You may either assume,
or ensure, that the parameter is of type Period.

This annoys me. This smacks of a poorly thought-out assignment. You wanted to demonstrate that programming for the general case is better; but all you showed was that it's not always necessarily the correct thing to do. Think of your audience; think of your users: who will want to book something for an Instant? No-one!

CS courses at Waterloo need to get off their pedagogical high-horse and realize that although the theory is great, it's not always necessary. By shoehorning computer science concepts into awkward assignments, you will only cause an entire class of students to tune you and your ideas out.