I went to the ACM’s web site to fill out their form for ICPC participants. When I clicked submit, however, I was faced with this upsetting error message:

No matter how many times I clicked “Submit” or filled out the form, this dialog would pop up. Following my geek instincts, I was determined to figure out why. I looked at the source code for the web page. Immediately, I noticed the all the code for the Javascript client-side form validation was right there in the page. A couple of quick searches and I found the reason I was looking for.

In validating the form, the Javascript checks to see that you did in fact enter a Canadian province if you selected that your country was Canada. (That is, if you entered something like “Kentucky” it would tell you pop up the error dialog, since “Kentucky” is not a Canadian province). Fair enough. However the line of code they had for validating Québec was something like this:

if ( form.s_state == "PQ" ) { success = 1; } else { success = 0; }

However in the form itself, as part of a giant list box, was the following option:

<option value="QC">Quebec</option>

Obviously, “QC” and “PQ” are not the same thing. So the form validation fails. What’s a geek to do? So I opened up Firefox, installed Firebug and went back to the form. I used Firebug to modify the <option> tag so that it’s value was “PQ”, thus allowing the form to be submitted. I was met with a nasty error debugging page, since apparently “PQ” is not a valid key in their database. This means that the form isn’t ever being validated on the server side. The values that I fill out, passing the Javascript client-side validation, go straight to their database.

Sufficiently disgruntled, and realizing that there’s no server-side validation whatsoever (other than some foreign key constraints in the database), I opted to simply disable Javascript in my browser. This worked like a charm. My form was submitted successfully, I received a registration number and confirmation e-mail and everything. This is analogous to being locked out of a car, and managing to open the door by pressing the “bypass locking mechanism”-button that is located on the handle.

But I made a mistake. After disabling Javascript I forgot to select “Quebec” from the dropdown box. So according to the ACM, I live in Montreal, in the state of Alabama, in Canada.

Ridiculous. This is the society of programmers, computer scientists and software engineers — and they can’t even get a simple web form right. Forms should always, always, ALWAYS be validated on the server-side. This is elementary. This is basic. This is common-sense.

Don’t worry, though. I fully plan to notify the appropriate individuals to resolve the problem.

The bulk of the week was spent in our hotel room office, coding, testing fixing and coding. We didn’t have time for any fancy development practices or anything formal; we went for the iterative/last-minute model: get stuff working fast. We got a lot of input from our Microsoft mentors: Jaime, Mike and Justin who came by the hotel nearly every day (and got free dinner ;)), helped us organize ideas and practice our presentation. These guys volunteered plenty of their own time to helping us out, and it was much appreciated.

Yesterday was the big presentation day, where we had to show off what we’ve done to a panel of judges, which included Microsoft researchers, with backgrounds in physics, and engineering… It was kind of brutal. The picked apart every presentation to the point where we had no idea whom would win. Obviously, given the limited timeframe, a lot of the projects were in the same relative state of hastily-written code. There was one project that stood out, which was polished and clean, and had a great idea. This was ObjectSpace, which presented a 3D, interactive coding environment that would teach people how to program. We were sure they were going to take first place. Our presentation was pretty good, and we were confident that we’d be in the top 3.

When it came time to present the awards, however, ObjectSpace came in third. At this point my heart was pounding. We knew we were getting something for sure — because they brutally singled out the two teams that didn’t win anything before announcing the winners. And if ObjectSpace came in third, that meant we had a damn good shot at first place, and Korea. Then we called up for second place, or — as it says my trophy — “1st Runner Up”. (I think “2nd place” sounds better). This was more than we could’ve hoped for, and not bad for a weeks’ worth of work. ;)

I’m really glad I got the time to meet up with my friends who’ve moved out here to work at Microsoft, too. I took the time on Tuesday to check out Taphouse Grill with Vivian, and I went over to Nadia’s apartment to play some pool with her, Ahmed, Eric, and their friend Rosh. Vivian came back out to drink and eat sushi with us last night, too. Who knows when I’ll get to see these friends again — hopefully sooner rather than later. I kind of regret not being able to see much of downtown Seattle (we had one afternoon where we went to an arcade/bar and Scott and I defeated House of the Dead 4), but this week has been a blast nonetheless. You can bet I’ll register for Imagine Cup again next year.

And finally, I’d like to give a huge THANK YOU to all the organizers. Especially Stephanie, who had the stressful job of being a temporary Mom to some 24 geeks throughout the entire week. She made sure we got fed, met our mentors, had time to practice, and enjoyed ourselves throughout the week.

That’s it for now — I’ve got a plane to catch. :)

Java itself does force you to place things in objects, when maybe, an “object” is not always the best place for that thing. And while a Java program clearly reveals it’s architecture, it doesn’t do a very good job of revealing it’s intentions. I for one prefer intention-revealing code to anything else. I like being able to glance at a code fragment and say “I know what this does” – without having to look up a class reference API document.

Given all the Java programming I’ve been doing in one of our projects this semester, Stevey’s rant sure made me feel a bit better about being bitter. :)

Object Oriented Programming has some fundamental flaws. All the languages (and there are more and more languages coming out all the time) are simply bigger telescopes trying to address a similar problem. Dr. Grogono began describing a new programming paradigm and language that he has been working on in collaboration with Brian Shearing (who gave a seminar at Concordia on a similar topic during the summer). Their paradigm is called Malleable Software.

Their idea is to organize code in cells that have certain capabilities which may or may not be concurrent. (A lot of the talk involved concurrency issues in modern programming languages such as Java and C++ and how they are – by default or by design – insecure. However I have not had the opportunity to deal with the concurrency headache, so I’ve not fallen victim to those insecurities yet). Cells can only exchange data, instead of calling operations on each other. This avoids the problem of having ugly coupling problems, where one method in one class may call another method in another class which modifies the data in the first class …. and ugliness continues.

Another problem the duo intend to solve involves the use of import, include, etc. statements that so often muck up modern programs. Imagine a huge project where one class may need a number of different functionalities and has to import every single dependent class or header file whether or not you actually use them … In Malleable Software, a Cell would be given the capabilities to do certain functions (such as the ability to generate random numbers) although I have no idea who or what gives the Cell these abilities. (I remember asking this question to Brian Shearing when he mentioned a similar concept, but I can’t remember the answer).

Once the audio recordings are out on the CUSEC website, you should listen to this keynote and see what you can get out of it. I think a lot of the malleable software concept is still being played with in its creators heads, so some stuff probably hasn’t been figured out yet.

Either way, there’s a great play-by-play overview of the discussion in Ruby Advent Calendar Day Nine: Monkey Knife Fight! by Joey deVilla that sums up opinions from various other people and presents a lot of sides to the same discussion.

If you’re still thinking about it, it’s a great read :D