It's the conclusion of Science Fair Week on the OhmsBlog! Yesterday's post is available here.

---

Another science fair has come and gone. Much like last year, I've decided to write some general observations about what I saw.

1. Originality - Unfortunately there were projects that lacked originality. When I say "originality," I don't mean "gee-whiz I've never thought of that before" originality. I'm referring to the creation of original content. Downloading a bunch of stuff off the internet does not make a science fair project. The best science fair projects have a core purpose, and everything that the student does to obtain conclusions to that purpose should be the student's own work. I saw lots of this last year, too.
   
2. Methodology - There were lots of methodology holes, some more significant than others. As a student it's easy to overlook something. It's useful to have some additional pairs of eyes take a look at the project to identify oversights. Confounding variables sometimes work their way into projects and they can call the results into question. Another issue was that some projects strayed too far from the three allowed project types: experiment, innovation, and study. Notice the absence of the word "demonstration" from that list. Students can demonstrate something as part of their presentation, but it should be related to the experiment/innovation/study. A demonstration on its own is not a science fair project. As another recommendation, judges want to know why a student did something as much as they want to know what and how. Every decision that is made over the course of the project needs to be justified reasonably.
   
3. Analysis - It is important to think carefully about what kind of analysis needs to be done on the data to make it applicable to the purpose. Sometimes taking an average isn't good enough.
   
4. Bibliography - Again, Wikipedia citations appeared all over the place. Where are the advisers to teach students that this is not a credible source of information for scientific enquiry? As another recommendation, I'd suggest that any claims made in a project that are not proved via the project itself must be cited.

It's Science Fair Week on the OhmsBlog! Yesterday's post is available here.

Today is the Kiwanis Regional Science Fair in Medicine Hat! Hatters, get your asses over to the College right now to check it out!

---

In case you haven't noticed, my science fair adventures are important to me. Even though my science fair career reached its pinnacle eleven years ago, I still consider it to be a vital contributor to who I am today. "So what?" you might be thinking. "It's just a kid or two standing there with a book and a backboard! How can that have any meaning a decade down the road?"

I intend to explain it.

1. Science Fairs provide tremendous opportunities for personal growth. They bring out the best, and sometimes the worst, in students. Both aspects become positive in the long run. The positives are mostly self-explanatory -- students gain valuable experience in self-directed research, public speaking, making friends, and time management. Indeed, one does not need to win anything to reap these gains. Unfortunately science fair experiences occasionally cause students to learn about humility "the hard way." This is not a bad thing.
   
2. Science Fairs take the training wheels off of learning. My school science experience involved experiments that were already designed for us. In the science fair, projects need to be designed from the ground up. I learned far more about scientific method from the science fair than I could ever have gained from a textbook experiment.
   
3. Top Science Fair projects contribute to society. Many of the CWSF-calibre projects out there are conducting valuable, innovative research that makes a difference. These projects aren't your baking soda and vinegar volcanoes - some of the stuff being done is comparable to graduate-level research in universities and private R&D facilities.
   

In my opinion I was able to take advantage of all of these benefits. I worked very hard to reach the CWSF, and even harder to win gold. I had my fair share of second place finishes to get to that point. Even as a winner, I experienced bitterness and resentment from students who didn't fare as well, as they came up to me and attempted to belittle my project to make themselves feel better. I don't feel bad about that at all - it was just one more learning experience. I came out of it with a thicker skin than I had going in.

My science fair experience played a pivotal role in obtaining admissions to university undergraduate programs. There were certainly other important factors, but as far as extra-curricular activities were concerned, my CWSF experience was hard to beat.

One day when I was off at university, I saw a fellow riding a bike down the street. He was wearing a familiar-looking sweater - from CWSF '97 in Regina. On another day I was wearing my CWSF '98 t-shirt at my co-op workplace. Lo and behold, the student in the cubicle next to me recognized it because he was there. The resulting friendship ended up being one of my most important at university.

Once I had finished my degree, I went searching for full time software development work. As it turned out, somebody at my future employer had heard about my software development exploits at the science fair. I have no doubt that the resulting interview discussions contributed to my hiring.

I still consider winning gold at the 1998 Canada-Wide Science Fair to be one of the most fantastic moments of my life. It is now so many years later, yet my science fair odyssey is still paying dividends. It might seem like a bunch of reminiscing about standing at a booth with a backboard and a couple of duo-tangs, but it defines and haunts me still. I guess that's why I have been coming back.

Tomorrow: A review of today's activities.

It's Science Fair Week on the OhmsBlog! Yesterday's post is available here.

This entry is adapted from a speech that I gave at the awards ceremony for the 2008 Kiwanis Regional Science Fair in Medicine Hat, Alberta. Don't be fooled by the humour; this anecdote is non-fiction.

---

When I was an exhibitor at the 1998 Canada Wide Science Fair in Timmins, Ontario, the CBC came to do a series of live broadcasts from the exhibition floor. Unfortunately they could only set up their equipment to broadcast from one particular aisle, so most of the exhibitors (myself included) would not be interviewed on TV.

Being curious and inquisitive science fair students, we were not content to let these CBC broadcasts proceed without seeing some of the action. I wondered over there with a couple of friends who were from British Columbia. We watched the interviews for a while, but I started to get bored and decided that I would walk back over to my project's booth. As I started to walk, I stumbled a bit and thought I felt somebody push me on my shoulders from behind. I didn't think anything more of it, and I sauntered back over to my project.

A few minutes later, one of my friends walked over to me, laughing. "Do you realize what you just did?" he asked.

Confused, I said, "No, what do you mean?"

It turned out that when I stumbled and was pushed, I tripped over the cables that were carrying the CBC's video feed from their camera out to the control van. "You just knocked out the CBC!" he exclaimed.

I might not have made it on TV, but I made my mark on TV.

It's Science Fair Week on the OhmsBlog! Yesterday's post is available here.

---

You'd think after my previous anecdotes about the Canada-Wide Science Fair that I was always the victim of other people's shenanigans. Unfortunately that wasn't always the case.

This story is another one that occurred during project setup in '98. Since I had already been to a CWSF in '97, by that point I was more experienced as to how the fair worked. The previous year, some of the Computer Technology exhibitors had flashy animated demonstration videos and techno music playing loudly on their computers. I don't know if this was supposed to attract TV reporters or influence judges, but it annoyed me immensely. This was a science fair, not a trade show, and I thought that the eye candy distracted observers (and other exhibitors, for that matter) from the real reason that we were there: the science.

Fast-forward back to setup day in 1998. I was sitting at my project's designated booth. All of a sudden I heard loud music coming from a project that was a couple of aisles down. "Great," I thought, "More flashy eye candy this year." I turned to the kid who was setting up beside me and voiced my displeasure with the noise coming from that project.

The kid beside me was from Edmonton. As it turned out, the group project that was making all the racket was also from Edmonton. My comments subsequently sent my neighbour scurrying over to his fellow members of the Edmonton contingent to tell them what I had just said. Even worse, I found out later that the purpose of their project was to build an amplifier and that the music was a legitimate part of their demonstration.

Oops.

It's Science Fair Week on the OhmsBlog! Yesterday's post is available here.

---

In 1997 I was an exhibitor at the Canada-Wide Science Fair in Regina. Since much of the science fair involves sitting at one's project, those of us in Computer Technology had the advantage of having our own computers on hand to alleviate some of the boredom.

I spent a few hours of my time playing a simple game that I had installed on my machine. The student sitting next to me took an interest in it, and asked him if I would mind giving him a copy. I copied the necessary binaries to a floppy that he had lent me. Justin, as I'll call him, took the floppy, copied the binaries onto his machine, and ran the game.

Since he had never played this game before, there were no high scores saved anywhere. He lost his first game quickly, but since the high scores were empty it prompted him to enter his name for the high scores list. Unfortunately the high scores dialog box came up looking like this:


He looked over at me with an expression of incredulity and asked, "What's this?" The best answer I could give him was, "I don't know!" I didn't copy any configuration data over to that floppy, just binaries. That game was a 16-bit Windows executable, so it probably wrote its high scores data to an .ini file somewhere. Since that game was part of a package, I suspect that at some other time he played a different game from that package that saved its scores to the same file. Somebody entered that phrase as a high score for the other game, causing it to be the default when he played the game that he got from me.

I'm not quite sure that he understood that, though. He didn't say much to me for the rest of the fair. He just played "No Rain" by Blind Melon over and over.

It's Science Fair Week on the OhmsBlog! Yesterday's post is available here.

---

When I was an exhibitor at the 1998 Canada-Wide Science Fair in Timmins, Ontario, we were allocated several hours in our busy schedule for setting up our projects. Most people don't need too much time to get their project going, but sometimes shit happens and people need extra time to get organized. I recall one group whose computer project ended up in limbo because their computer was left sitting out on the tarmac at Pearson International Airport for a few days. In heavy rain.

For most of us, setting up was not quite so hectic. I unpacked my backboard for Advanced Windows 95 Security Techniques, the title spanning across the top in bright red. I removed my computer from its box, plugged everything in, and made sure that everything ran properly. I was mostly content to sit at my project and observe the commotion from my chair. Some competitors that had finished setting up decided to wander around, taking a look at some of the other projects.

One moment I was standing up and was doing some kind of maintenance on my setup, so my back was turned toward the aisle. Suddenly I hear a young man's voice behind me declare, "Now this project, this one's a joke."

I turned around to see what he was talking about, and behold, one of the senior level (grades 11-13) exhibitors is standing in front of my project and is critiquing it with his friend! I couldn't believe that anybody, much less another exhibitor, would have the nerve to walk right up to somebody's work and start talking trash in front of him.

I was incredulous. "Excuse me?" I said.

"It's a joke. You can't add security features to Windows 95, it's inherently insecure. It's impossible."

I was enraged. Who the hell did this guy think he was? What gave him the right to go around and pass judgements on everybody else's stuff? I figured that getting into an altercation at a national science fair would be headline news in all the wrong ways, so I bit my tongue a bit.

I looked him right in the eyes and stammered, "You know, I think that you very naïve." This guy had no right to dispense such comments, especially without reading anything beyond the title.

He and his friend wandered away, presumably to tear down somebody else's project. At this point, I was angry enough that I had to go and check out his work. I figured that I should go over and find out how credible this guy was, or at least find out what it was about his project that made him feel so superior to everybody else. I skimmed through the writing on his backboard, when suddenly I stopped and saw this sentence:

"C++ is not an object-oriented programming language."

I smiled. Things were unfolding exactly as they should. It suffices to say that in the end my project scored very well. Even though I know otherwise, I'd like to imagine that it was karma.

Since this Saturday is the 2009 Kiwanis Regional Science Fair in Medicine Hat, I thought that I'd declare this week to be "Science Fair Week" on the OhmsBlog. I'm starting on a Monday because I'd like to conclude the week next Sunday with a post-mortem of Saturday's events.

---

I've been programming computers for a long time, and I've been using computers for even longer. When I started writing code I was about seven years old. By the time I was thirteen years old I had switched from BASIC to C and C++. I had a desire to learn how to write software with a GUI, and I wanted to use a "grown up" language to do it. Our home computer in 1995 was a 486 box that was running MS-DOS 6.0 and Windows 3.1, so I decided to write Windows programs in C and C++. As time progressed the technology changed as fast as I grew. I soon found myself hacking away at a Pentium 120 running Windows 95. My mind absorbed books by Windows spelunkers Andrew Schulman and Matt Pietrek.

As a student in high school in the spring of 1997, I had observed my peers cleverly discovering ways to bypass the system policies on our school computer systems. For example, there was a system policy in Windows 95 that would block the "display settings" control panel applet, thus preventing students from being able to modify the desktop wallpaper.

Or so the teachers thought...

It turns out that, right around that time, web browsers started shipping with a little feature that, when invoked, would set the desktop wallpaper to an image that the user selected from a web page. The system policies blocked the control panel applet, but not the underlying API function, which I knew by that time to be SystemParametersInfo(). "Would it be possible to intercept and block API calls?" I asked myself. That sounded hardcore to me. I had been doing science fair projects since the seventh grade, and I decided to make that question the focus of my 1998 science fair entry.

My favourite time of the year has always been the span of time from the last week of June to the third week of July. I'd relax and enjoy my summer for that duration, but I had made it a habit of commencing my science fair projects after that final week had concluded. I would do research and take plenty of notes over the summer, but I still had plenty of time for golf, cycling, Slurpees, and whatever shenanigans I could take part in.

The summer of 1997 was slightly different. I would be spending two weeks at a summer computer camp offered by the University of Calgary to brush up on my C++ skills. When I wasn't in class, I spent quite a bit of time researching. I studied in the university library. I spent countless hours browsing the aisles in computer book stores. I scoured software shops looking to score an educational pricing deal on a new 32-bit C++ compiler for Windows.

I spent several months searching for the best way to implement my elusive goal: To globally intercept calls to Windows API functions and block them if they did not conform to an administrator's security policy.

By December 1997 I had found something that almost worked. Several programs crashed, but at least I could successfully intercept an API call that was made by any 32-bit process that was running on the system. 16-bit processes in particular did not fare so well (there's another story about that, but that one will have to wait).

Science Fair Tip:
Sometimes things don't work as expected. That's OK if you can figure out why. If you can use this knowledge to find a solution to the problem, that's even better.

Unfortunately the very program that seeded my idea did not work. Netscape would crash when I ran my software. It turns out that several of the Netscape executable's sections were marked read-only, causing a general protection fault when my software tried to intercept its API calls. Fortunately my diagnosis allowed me to add some additional code to fix the permissions so that my program could run properly.

By the time I presented Advanced Windows 95 Security Techniques at the Southeast Alberta Regional Science Fair, my program worked but it had a very simple user interface. It had a one line static text field that displayed the program's status and a single button to toggle its enabling. This rudimentary GUI was good enough for the regional science fair, but it needed beefing up to look good at the Canada-Wide Science Fair.

In the months between the regional and national science fairs, I completed a fully-featured GUI that placed an icon in the taskbar notification area. Selecting that icon would prompt the user for an administrative password. A successful password entry would cause a configuration screen to be displayed that would allow for fine-grained control over which API calls would be intercepted under which conditions. I called this program "Captain Hook."

The 1998 Canada-Wide Science Fair in Timmins, Ontario had its ups and downs (there'll be more blogging to come about those), but my week peaked when I won the gold medal for Intermediate (grades 9-10) Computer Technology. One of the other highlights was when I met the Governor-General. I also met several interesting people during the day that the fair was open to the public. The people that came to talk to me about my work included a school district IT manager and an employee of the Communications Security Establishment.

The schedule for the week at the CWSF was very busy, to say the least. Even worse was the travelling involved to get to Timmins from Medicine Hat. I got back in the early hours of Monday morning (Victoria Day 1998), and I had to return to school on the Tuesday. Unfortunately the sleep that I needed so badly was denied: my family's phone started ringing off the hook at 9:00 AM. The culprits? Media organizations. Needless to say, I was more or less incoherent for the next week at school.

This past March I was a judge for a regional science fair. Having entered a regional science fair six times, travelled to the Canada-Wide Science Fair twice, and having won a gold medal at a Canada-Wide Science Fair, I think that I bought a unique perspective to judging. Having said that, there were some standout issues that I noted with the projects that I saw, and I'd like to put them up here in case anybody (perhaps an adviser to a science fair student) finds them useful.

1. Wikipedia is not an acceptable bibliography entry.
   
   I don't think that I saw a single project without a Wikipedia reference in the bibliography (I was rather startled to see this, but much has changed in the decade since my peak at the science fair). Why is this a problem? Let's start with the obvious: Anybody can edit Wikipedia. I know that there has been plenty of debate about whether Wikipedia is better than any other encyclopedia, but lets face it: its content is in a constant state of flux and is not always subjected to the same scrutiny as more authoritative sources -- such uncertainty is not welcome in a scientific endeavour. Furthermore, encyclopedias alone do not go into enough depth on a subject to provide sufficient research. Few projects had rich bibliographies containing credible books or papers related to their subjects. Especially at the high school level, I really think that the creator of a winning project needs to spend some time at a post-secondary library. I used to spend plenty of time at our local college library and, since I mostly did computer science projects, at computer book stores. Don't get me wrong: I'm not saying that the internet isn't a useful resource. I am saying that the internet resources need to be credible, and I am tremendously disappointed that the students' advisers did not point out these problems.



2. Science Fair projects need to show some science.
   
   This entry really applies more to students in the upper years whose projects might be considered for the Canada-Wide Science Fair. I witnessed this problem with engineering projects in particular, but it really applies to every category: It's great if the student is able to build something and explain how it works. On the other hand, why it works is just as (if not more) important than the how. I want to illustrate this in terms of a hypothetical project involving a mechanical device. Suppose that this mechanical device shoots a projectile. Doing trials to prove that it does (or does not) work is insufficient. For this project to really shine, it needs some scientific polish. The applicable kinematics equations are easily understandable by a ninth grade student. If the device is storing potential energy, spring constants are also easy to grasp. If the exhibitor were to combine the physics equations with the actual tests of the device, it would improve the project immensely. For example, the student could do some math to predict the results of the trials, and then attempt to confirm these predictions in the experiment.
   
   I was not immune from this issue. For my first science fair project in seventh grade, I built trusses out of match sticks. The purpose of the project was to determine if the strength of the trusses increased proportionally to the number of triangles in the design. In order to test the bridges, I placed lead weights on the trusses, increasing the mass until the truss broke. Unfortunately I did not answer some very important questions related to my work:
   
   
   • Why was lead a useful material for weights?
   • What kinds of forces were involved?
   • Mathematical formulas and calculations
   • Other issues (this list is not comprehensive)
   
   
   I guess that the point that I am trying to make is this:
   
   
   • If there are mathematical formulae related to the subject matter, learn them and use them (biology projects are not immune to this, no pun intended).
   • If your experiment behaves a certain way, explain why, even (or especially) if it doesn't work as expected.
   • If you make a decision, explain why you made it.
   • If you choose certain materials, explain why.
   • If you can measure something more precisely, do so. If you are unable to do so (perhaps it is too expensive), then mention that as an improvement in your future work.
     
   • If you have a feeling that a judge might catch you on something, fix the problem (the judges will notice it).



3. Watch those constants.
   
   Group projects, remember that it's not always a good idea to split everything 50/50. For example, let's suppose that Partner A and Partner B agree to do 20 repetitions of their experiment, but to keep it fair, each partner will do half of them at his/her respective house and then combine the results later. Hold on! Unless the location of the test is the manipulated variable, the experiment will be flawed. The location of the experiment isn't being held constant! I know it sounds like nitpicking, but it weakens an experiment when a "close enough" attitude is taken toward constants! It calls the results into question when more than one variable is being manipulated at a time.