DWITE — an online computer programming contest that Dan and I run has announced another season!

A new season of the DWITE programming contest is starting and we have picked the dates for the 5 rounds. This year we will start off with our first contest on October 23rd, which should give students enough time to get started in school, and learning, refreshing the programming skills, as well as us some time to get the site and judge up to shape for the new season.

What’s new for this season is that this year we’ve got stuff to give away — namely I’ve got a hold of 5 copies of Little Brother by Cory Doctorow. That’s one for each round of the contest. What is Little Brother all about?

Marcus, a.k.a “w1n5t0n,” is only seventeen years old, but he figures he already knows how the system works–and how to work the system. Smart, fast, and wise to the ways of the networked world, he has no trouble outwitting his high school’s intrusive but clumsy surveillance systems.

But his whole world changes when he and his friends find themselves caught in the aftermath of a major terrorist attack on San Francisco. In the wrong place at the wrong time, Marcus and his crew are apprehended by the Department of Homeland Security and whisked away to a secret prison where they’re mercilessly interrogated for days.

When the DHS finally releases them, Marcus discovers that his city has become a police state where every citizen is treated like a potential terrorist. He knows that no one will believe his story, which leaves him only one option: to take down the DHS himself.

Little Brother is the 1984 for the new generation. Surveillance, hacking, Japanese popular culture, Firefox, TOR, RFID… and that’s just the first chapter!

Cory Doctorow on XKCD

Cory Doctorow is a co-editor of BoingBoing.net and the former European Director of the Electronic Frontier Foundation (a kind of organization that we need to keep ourselves out of trouble), so he really knows this material well for his book. I think you guys will really enjoy this.

What’s super awesome is that you can download a copy of Little Brother for free (in just about every possible file format). The entire book is licensed under Creative Commons.

Though to get a hold of a hard copy, signed by the author, as well as Dan and myself, one has to take part in this year’s DWITE programming competition (you must be a Canadian high school student to be eligible to win). There are 5 rounds; 5 chances to win. Paul Butler has previously wrote a guest post with tips for preparing for a programming competition to check out.

So make sure that your high school (or some high school that you know of) knows of this.

Related posts:

1. DWITE – Fifth Season
2. DWITE – the Programming Contest
3. Catproofing your code. Also DWITE.

This makes me recall one of my all-time favourite programming webcomics from MacHall:

As a person controlling your (DWITE) grades, I too have some advice:

1. Sidestepping the assignment negates its purpose. You fail to learn a concept or demonstrate your ability.
2. In an academic setting, you simply fail.
3. You are almost there. Even the hard code values come from somewhere, perhaps from figuring things out on paper — put the same logic into the program.

Though I think I’ll let MacHall offer the final advice on writing hard code…

That is all.

Related posts:

1. Ways to spot plagiarized code

There are a few good reasons to write the CCC:

1. See how you rank among your peers across the country.

2. Get practice for local competitions — You may find that universities in your area run local competitions for recruiting prospective students. The CCC will give you some experience competing.

3. From what I've heard, the University of Waterloo likes applicants who have written their contests. This is especially important if you are applying for CS or Software Engineering, as they specifically ask about it on the AIF. Other universities will like it too, even if it is marginally relevant to your program.

4. Rumor has it, that a big company south-of-the-border is spamming contacting students with employment opportunities based on their CCC scores.

Here is what to expect:

1. There are two tests, one is Junior and the other Senior. The difficulty of the tests is fairly consistent from year to year, so you can look over past tests to decide which test to write.

2. Each test has five questions. The last few questions are generally harder than the first few.

3. For the first stage, the languages you can use are up to your school to decide — it depends what they are capable of testing.

If you decide to write the Canadian Computing Competition, here are some tips to get the most out of it. I don't claim to be any sort of expert on the CCC, but there are a few things that either I wish I knew, or things I did know that helped. Keep in mind that, although it is a competition, having fun and learning from the experience is more important than winning. It's fine to be competitive if that's what you enjoy, but unless you actually enjoy doing the things I am suggesting, there is no harm in spending your free time at something you enjoy more.

1. Practice helps a lot. Start by taking your time and then move to practice competitions where you take a past contest and go for three hours, and then test your results.

2. The book Programming Challenges is good, and it is not watered-down for High School students. The book is a valuable resource for competitive programming.

3. Learn to break all your good habits. Don't comment needlessly, and even consider naming your variables alphabetically. Not because it is shorter to type them, but because it is less time you have to think about naming your variables. Of course, if your algorithm is going to have too many variables to remember at one time, you will be shooting yourself in the foot to be naming them after letters. All I am saying is that you should keep in mind that the lifespan of the code is 30 minutes, not years or decades. Some would say that if you can't quickly think of a name for a variable you don't understand what it does well enough, but I find that I often waste time when I understand exactly what a variable does trying to find the English word that describes that. If you find yourself in this situation, remember that no one is going to be offended if your code includes int n = 1;

4. Consider learning to work without an IDE. You should at least be able to write a Hello World in your language of choice without an IDE. If your IDE underlines errors before you compile, turn that feature off while you practice. You can enable it for the competition if it makes you feel more comfortable.

5. The debugger and other development tools are generally too costly (in terms of time) to use on a contest, however they might come in handy so you should at least learn the basics.

6. Make sure you are comfortable reading and writing to files from your language of choice. The ability to parse strings and numbers out of files is crucial, as well as output formatting (printf or the equivalent in your language).

7. If you are in the habit of spitting out code and shaping it until it does what you want, get out of it. Ideally you want to be able to write a program with no bugs the first time. Not that you should expect to ever get to that level, but that's what you should aim for.

8. Use a pen and paper. Visualize the problem before you start coding. Try the sample input on paper and see if you understand exactly why the output is the way it is.

9. Pay a lot of attention to the input specification. The test data will test the limits of your program. Don't even think about what your program should do if you get data that does not fit the specifications; no one is judging you for your error handling. However, you will have cases with lots of input and you will have to put a lot of thought into solving the problem in an efficient way. If the problem specifications say the input graph will have n < 50,000 nodes, you should expect a graph with 49,999 nodes to show up in the test data.

10. When given a problem I would first make several test cases and try them on paper, then type them in and save them. This way I had some extra test cases, and I have ensured that I have a thorough understanding of the question. You will need extra test cases, the tests they give you usually only cover trivial cases. Even if you don't follow this method exactly, it will pay off to think before you start typing.

11. Get to know the string and array functions for your language well; they will come in handy.

12. If you are using an object-oriented programming language, don't bother defining extra classes unless you have a good reason to. Don't even think about using getters and setters if public properties will do the trick.

    Tony’s note:

    Here Paul is referring to setting up (or rather not) proper classes, structures, constructors, accessors, and all the other object-oriented terminology. Higher level object oriented languages such as Ruby or Python tend to perform incredibly well in programming competitions.

13. I made a class called CCC which contained all the code I wanted to reuse for each question (mainly opening the input and output file streams, with a switch so I could read and write from the console instead). I would suggest doing that in advance, so that you can code it again from memory — not that you should memorize it, but you should know the language well enough that you can re-code it without thinking.

14. Arrays, iteration, and dynamic programming tend to be over-represented (so learn them), data structures, recursion and sorting tend to be underrepresented (but still learn them).

15. Compsci.ca member klopyrev, who did much better on the last CCC than myself, has recommended USACO Training as the best way to practice for the CCC. Another good place for practice is compsci.ca's own DWITE programming contest — it is a great way to improve your skills, throughout the year.

16. Keep in mind that programming competitions test you on a certain area of programming and thinking skills. The questions are generally trivial to implement, but the challenge is coming up with a good algorithm.

Good luck, and have fun.

More programming competition tips on compsci.ca forums and more practice problems on dwite.ca contest website.

Related posts:

1. DWITE 2006 – now with Ruby
2. hard code
3. How to study for Computer Science exams

The fifth year of the Imagine Cup competitions will be holding its finals in Korea this year. Want to receive free travel and accommodations? You’ve got to make it into the finals, and AI Programming category is my personal favourite.

Project Hoshimi Programming Battle (you may skip the quote to just watch the video instead)

Imagine that you are the only one that can save a person, a city, or even a nation and that you can use the right combination of strategy and programming skills to do this. The Project Hoshimi – Programming Battle invitational brings to life the world of Professor Hoshimi and his faithful crew of scientists and programming experts in a fantasy of life and death. This popular competition uses a background story, comic style graphics, and very real challenges to test the skills of programmers everywhere and allow them to compete, directly online, with people all over their nation and eventually the world to see who has the fastest program to save the day. In Project Hoshimi – Programming Battle, you write the code representing the behavior and the strategy of a team of characters going through different types of missions. The results are not only fun to create but also fun to watch as the programs play out in a virtual 3D environment for all to see.

Lengthy description, I know.. so I found a 55 seconds video on YouTube that summarizes key points, and has a clip of the 3D environment involved. Background music and all.

Runthrough of competition details:

• Teams of up to 2 individuals
• Take-home challenge coded using one of the .NET family of languages (C#, VB .NET, etc.)
• March 1st, 2007 – First Round Closes and Registration Ends
• All competitors achieving qualifying mark
  will move on to round 2

Details and registrations are available at the category’s website. Further resources are available at Project’s dedicated website, including the SDK download.

It is really easy to get started, there are plenty of documentation, samples, and tutorials available. Most importantly it’s fun, there are even unofficial side competitions being hosted between the rounds for bonus practice! This year I have my own projects to keep me busy, but let me know if you are thinking of participating! We could organize something here or on the forums to match people looking to form a team.

No related posts.

If anyone needs some extra motivation to work on their dream game, then Dream-Build-Play Competition is it. So far just a teaser, the only published information is that the contest begins in January 2007, and involves developing video games for Xbox360 with the XNA framework.

your dream game – build it today – millions may play it tomorrow

Promises of “fantastic prizes” and “global envy” suggest large scale distribution of successful entries. This should sound excellent for anyone thinking of getting into video game development business.

Oh, and if anyone wonders if there’s some subliminal message encoded in all those dashes and dots at the bottom of the contest website – there is. The message is: “your world your game”, XNA Game Studio’s slogan.

I’ll try to publish more information as it becomes available, subscribe to RSS feed to stay up to date.

Related posts:

1. Inside the Great Games Experiment
2. full XNA source code samples
3. Thoughts on Video Game Programming jobs

A quick, but exciting update on the DWITE programming contest – it now supports Ruby! Running the current stable 1.8.5 version, it should make the contest much more interesting.

Ruby has a very neat syntax, making it easy and enjoyable to write. Code redability is vital, and since DWITE is a team competition, it is important for team-mates to read each other’s code with ease.

Ruby is also a very powerful Object Oriented language. It is excellent for data analyzing, processing and manipulations, with many methods build in and readily available, making it an excellent choice for a number of common DWITE problems. Mr. S. has asked for some sample solutions to test out the judge system, so here’s a very typical DWITE entry problem to consider:

Write a program that will calculate the square of a number rounded to two decimal places.

The input file, DATA11.txt, will contain 5 numbers, on separate lines, each between -32768 and 32767.
For Example:
0
23.45
-1234
-32760.789
999

And a solution:

[ruby]
outFile = File.new(”OUT11.txt”,”w”)
File.new(”DATA11.txt”,”r”).each_line{|num|
outFile < < sprintf("%0.2f", num.to_f*num.to_f) << "\n"
}
outFile.close
[/ruby]

Input/Output File handling is phenominal. In the previous contest a team has wrote a working solution to one of the problems in C, but due to a messup with inclusion of header files and file access flags, the solution was not accepted. But with Ruby, there is no need to consern with flags, counting for loops, pesky EOF conditions, or other details.

[ruby]
File.new(”DATA.txt”,”r”).each_line{|input| input.do}
[/ruby]

All of the file handling has been reduced to a clean, readable, single line of code. How is this not amazing?

The next DWITE contest is on Tuesday, November 28, 2006 3:00 pm – 6:00 pm – Eastern Time and the registrations are open. You’ve got nearly a month, so if you haven’t already – download Ruby, check out tutorials, ask lots of questions, and enjoy the contest. The next round should be very interesting.

– Tony

Related posts:

1. DWITE – Fifth Season
2. Catproofing your code. Also DWITE.
3. C ate my homework

So a couple of years back we had a competition over at the CompSci.ca forums, to see what could be accomplished in just a few lines of code – say no more than 20. The submissions were limited to Object Oriented Turing, and started off with some nifty looking effects and animations, but soon after full out games (types of which are suggested for grade 10 or 11 ISU projects) began to appear. All in 20 lines of code or less! Here are some highlights from the original competition.

beard0 has put together a full out TicTacToe game (top), with mouse controls, and checks for win/tie conditions in just 17 lines of code.

zylum developed greenspace (left) – all adjacent squares flip colour at a click, the objective is to make the entire screen green. 20 lines of code

My own submission at the time was a stripped down version of a Snake game (right). There was no actual food pellets for the snake to eat, but the game did include full controls, collision checks against the walls, and having the snake run into itself. The score was also kept, and reflected the life-span of this cruelly confined game sprite – all in 20 lines of code.

Though the most talked about game was Catalyst’s Pong (bottom). 2 player controls, bouncing ball, scores. The game was complete. The game had everything one would expect from a grade 10 or 11 ISU project submission. The game was 19 lines long…

The above was achieved by chaining a number of generic if-condition-assign-value into a single exit when statement.

fcn sa (cond : boolean, var a : int, b : int) : boolean
if cond then
a := b
end if
result false
end sa

The above was used as

loop
exit when sa(true, x, 0) or sa(chars('w'), x, x+1)
end loop

Since the function always returns false, the loop never exit, but the statement still needs to check every function to make sure. Passing true as a condition will always assign the value of b, to a, so in the above example the value of x will always be set to 0 at the beginning of the statement. Alternatively a condition statement could be employed, and so if key W has been recorded to have been pressed, the value of x will increase by 1.

This year we are revisiting the competition with another round. There is a month to put something together (the deadline is October 13th, 2006), and this time it is also open to your favorite programming language (any). I suspect that things could take an odd turn if any Perl Golf hackers show up, so I will be mainly watching for Turing submissions.

My prediction for this year is that while the above described methology of chained statements will still be a popular way to join lines of code, I hope that someone would raise a bar and employ some bitwise operations. Zylum has written an excellent tutorial on using bitwise operations in Turing.

if (player & (rign1 | ring2 | amulet)) > 0 then

A single condition to check if a player is wearing at least one piece of jewelery. Nifty.

Related posts:

1. iFactor – free XNA game with source code
2. Computer Science Projects are due this week

With up to four people per team, and only a single computer, DWITE promotes collaboration and teamwork. It also means that no particular student is required to carry the full weight of problem solving and implemintation, so the environment is excellent for both newcomers and hackers.

An automated online judge is set up to mark the submissions in a variety of different programming languages, and the current scores and rankings are updated on the website thoughout the competition. It is a whole different game when you are playing catch up, or are trying to keep a lead over your peers. DWITE rankings let you know exactly how your and other teams are doing, and open a possibility for friendly side-competitions.

The contest runs 5 to 6 times a year, letting students improve over time with practice. The first one is scheduled for Tuesday, October 3, 2006, followed by five more, about a month appart. If you are a Canadian highschool student, registration is now open!

The official website is – http://dwite.ca/

– Tony

Related posts:

1. Catproofing your code. Also DWITE.
2. DWITE – the Programming Contest
3. DWITE 2008-09 Contest Season

Mr. S. of DWITE is coming to a conclusion of the term he has set aside for himself to develop and run that contest. He is eager to pursue other projects and interests, and CompSci.ca has been selected to host and administer the contest, starting in Fall of 2006. We’ll be getting the much needed help and expertise from Mr. S. himself, to ensure a smooth translation; as well we’ll be inheriting the name of “DWITE” and have a head start with high-schools already familiar with this event.

Over the coming months I plan on making a couple of trips to London, Ontario to meet up with Mr. S. to discuss development, review rules and generally have him look over our progress of putting everything together. Additionally I’d like to get some insight from the people running CCC here at Waterloo, though that is appointment pending.

For now there is a lot of planning that needs to be done with Dan and interested members of the community.

Moeller Electric formerly known as Klockner Moeller

Related posts:

1. DWITE – Fifth Season
2. Catproofing your code. Also DWITE.
3. DWITE 2006 – now with Ruby