Finagles’ 8th Rule: Teamwork is essential; it allows you to blame someone else.
Today, we’re finally getting our breakout game into a playable state! Yes!!
See how to implement functionality to recognise when the ball hits a block, and make the block disappear. This is really the centrepiece of our program – from now on, everything else is detail.
Concepts discussed: collision detection, removing an object from the world
Download (scenario as of beginning of this episode): breakout-v7.zip
90% Rule of Project Schedules: “The first 90% of the task takes 90%
of the time, and the last 10% takes the other 90%.”
— (source unknown)
One more time, discussions of loops.
Loops are such an important concept, and there are so many variations, that it is really important to get practice with them and get them properly into your head. To this end, we’re looking one more time at loops here before moving on to some new concepts in the next episode.
Today, we’re using a really important, fundamental loop pattern: A while loop with a simple loop counter. It looks like this:
int i = 0;
while (i < NUMBER)
{
doSomething();
i = i + 1;
}
Watch the video, and try to memorize this pattern. It will come in handy later!
Concepts discussed: loops, while loop
Download (scenario as of beginning of this episode): breakout-v6.zip
Here they are:
The new Blackbox servers (and one more for BlueJ)
These are the two servers that will run the Blackbox project. They are two Dells, each with 12 cores (24threads), 32G RAM, 2x 500G HD to mirror OS and 4x 2TB HD to get a 6TB Raid 5.
In the picture are actually three machines: The two Blackboxes are at the top. Below that, somewhat smaller, is a new server for our research group. Currently, we are running one machine that serves the BlueJ website, the Greenfoot website (including the Greenfoot Gallery), the Greenroom, the Blueroom, the CAS public website, the CAS Online site, the two book websites, our source repositories (subversion) for BlueJ, Greenfoot, and other projects, our trac site, various mailing lists, and a whole lot more. And all that on a machine that’s about seven years old with a whopping 2GB of memory — my laptop has twice as much!
Great news: a few weeks ago, we were awarded a ACM SIGCSE special projects grant to support the Blackbox project. We had applied for this grant to help pay for two servers that will be central to the project. One of them will collect the incoming data, and the other one will host a mirror of the database for researchers to work on and run queries and other evaluations.
We did some worst case calculations (worst case here meaning: close to 100% opt-in ratio of our users, which — in another sense — is really a best-case scenario). According to this we could have up to about 40 incoming network connections per second and generate about 3TB of data per year. That’s more that our current BlueJ server can handle. Way more.
So, thanks SIGCSE!
A lot of people are very aware that programming education is still quite difficult. We are a young discipline, and pedagogical principles are not genrally very well established. Many people teach programming, and generally how they do it is based on gut feeling. There are many grey areas where we just don’t know what works and what doesn’t, or why something works, or — most importantly — how to improve our teaching.
For example, students often fall into a bimodal distribution in programming classes: Some learn programming quite easily, and some are really struggling to “get it”. So far, there are many theories why this may be, and a good number of studies, but nobody really knows why this is.
It’s similar for the design of educational tools and environments – do we really know which aspects have an effect and which don’t? No, we don’t. Our discipline is really only at a beginning of an understanding of how people learn to program.
There has been work in this area for some time. Many people have studied data about early programming interaction. Getting your hands on this data can be hard work. Often, researchers collect data (either interaction data from the computer system, or interview or observation data), and then evaluate it. If the class is small, it is sometimes hard to be sure how much the results can be generalised. Collecting larger data sets, however, is hard, because most teachers have access only to their own students.
In our BlueJ project group, we discussed some time ago that we are in a fairly unique position to be able to gather data. BlueJ has a large user community, and there is potential to make use of this to further our work. And not only BlueJ development specifically, but programming education research in general.
So, some time last year we decided to initiate a new project: Project Blackbox.
The Blackbox idea is to collect data about the way beginners interact with BlueJ, and to make this data available to any interested research group to conduct their own studies with it.
For BlueJ users, this would only happen with explicit consent (opt-in) even though the data collected will be entirely anonymous. For researchers, we hope that this may create a treasure trove of data that might spark research that was not previously possible.
BlueJ is currently being downloaded over 2 million times a year, and has over 200,000 active users every month. Even if only 10% of users were to opt in to our project, we are still looking at hundreds of thousands of sessions per month, generating millions of interaction events.
We presented this idea at a special session at the last SIGCSE conference (session abstract, subscription needed), and several people expressed an interest.
So, we have now started on the design and implementation of this system, and I will occasionally give you an update here on my blog. If you are interested to keep a closer eye on it or get involved in the design discussions, you are welcome to join our mailing list for the Blackbox project.
The First Law of Programmer Creativity: “The cost of software maintenance
increases with the square of the programmer’s creativity.”
— (source unknown)
We continue with our breakout scenario, an also with our investigation of loops. Jumping right ahead, I show you both how to write a nested loop, and why and how never to do it.
Concepts discussed: loops, while loop
Download: breakout-v5.zip
Whatever begins, also ends.
— Seneca
(Seneca obviously didn’t know about getting your loop condition wrong … — mik)
Today, we are introducing a new concept: loops. Or, if you want to know more precisely: the while loop.
But, as always, we’re not doing this by just talking about the theory in a vacuum – we actually need it to progress with one of our projects, the Breakout game that we have seen before.
Loops are a concept fundamental to all programming, so if you are a learner, pay close attention. You will need this again later!
Concepts discussed: loops, while loop
Time is an illusion. Lunchtime doubly so.
— Douglas Adams
We are starting a new, probably more or less regular, thing today: answering viewer questions.
In the first of the Q&A episodes, I am talking about timers: How to arrange something to happen after a specific time delay. This principle is generally useful for many games and simulations. We also get bit more practice with int variables.
Concepts discussed: time delay, variables, counting
If life gives you lemons – keep them. Because, hey. Free lemons.
— Anonymous
In this episode, we’re continuing from the last episode’s theme and investigate and compare an alternative structure for making our Ball and Counter objects cooperate. We also have a first brief look at casting.
Recognising alternatives is a good skill, and it slowly eases us into discussions about code quality, which we will get to in more detail later.
The download today (below) is the scenario as it is at the end of this episode. However, try to add a counter into one of your own scenarios to make sure you are fully taking in what’s going on here.
Concepts discussed: object interaction, casting, score counting
Download: breakout-v3.zip (the scenario at the end of this episode)
Daring ideas are like chessmen moved forward; they may be beaten,
but they may start a winning game.
— Goethe
In this and the next episode, we’re looking a bit more into how to set up object structures, and how to get them to interact. This is one of the most fundamental concepts of object-oriented programming, so you need to get your head around this.
We discuss this here with the example of integrating our counter object into a scenario.
Concepts discussed: object interaction, object references, score counting, constructors, fields
Download: breakout-v2.zip (the scenario at the end of this episode)