Additional profile information on Alfred Thompson at Google+
One of the great things in my job is the chance to make connections between people doing interesting things. Lately a lot has been happening in the world of educational uses for the Kinect Sensor utilizing the Kinect for Windows SDK. Johnny Kissko seems to be the center for a lot of this so I have been trying to make sure he knows about them. Johnny is building a real virtual team (real virtual team? Did I just write that) via his KinectEDucation website. He’s introduced a number of people who are working with him via his blog:
One of the highlights of this team so far is Doug Bergman’s video introduction to Kinect programming. This is one of several videos on the KinectEducation Channel on YouTube. Speaking of introduction and how to do as well as moving nicely into another introduction. Ray Chambers (from the United Kingdom) has started a series of lessons on his blog. So far there are four entries.
On the other side of the world (Australia), Lucas Moffitt is working on a Kinect enabled version of his Word Filler project. A lot going on. You can always search the Kinect keyword to find what I have been blogging about with regards to Kinect as well.
And last but not least don’t forget Microsoft’s home page for Kinect in Education!
A recent blog post by Ian Bogost (The Virtues of Long Compiles) has me thinking once again about the trouble with fast compiles. How would you program differently if you could only compile your project once an hour or perhaps once a day? Actually its more complicated than that. What would you do between compiles? Would you work on other programs or perhaps new modules for the compiling program? There are risks associated with working on modules that have to work with code that hasn’t actually been tested yet. Would you read the manual or textbook looking for new ideas? (That is one thing that comes up in Ian’s post BTW.) This is a hypothetical or theoretical question for most students today. For some of us old people it means trying to remember how did we do thing back in the day of card readers and line printers.
The first thing I remember is that I put a lot more thought into the code before I hit the compile button. Well actually before I gave the operator my card deck. I didn’t compile after each syntax error was corrected for example. Or even some few number of them. I tried pretty darn hard to identify and correct each syntax error that the last compile had reported. The trick here is that one really had to understand what the error was. There was no time to try random changes and see if they worked. One did some analysis and you were always looking for the one fix that would correct several (or many) errors. Forgetting to declare variables was a killer. Today good IDEs (well Visual Studio which is what I use for most everything) help with the syntax errors are you type. Once doesn’t always have to run a full compile to catch the missing variable declaration for example. That doesn’t mean that errors that are a combination of syntax and logic such as bad assignments with mismatches of type always get caught of course. But one doesn’t have to wait for a long compile to catch most syntax errors.
With long wait times between compiles there was also an incentive of sorts to write as much code as possible before submitting to compile. This is not so much a good thing. It is much easier to debug a small piece of code than a large complex piece of code. On the other hand you really wanted to make sure your logic was sound, your interfaces clearly defined, and expectations well mapped out. This may be a win for the fast compile crowd in the long run but I’m open to opinions.
Once one handed in their card deck to the operator there was time before you got the results. Depending on that facility or school that could range from under an hour (the small liberal arts university I attended) to the next day sometime (the larger NYC university my wife attended). So what to do? Sometimes that was time used to prepare test data for when you did get a clean compile. Sometimes it was spent going over the assignment and seeing if anything was missing. Sometimes designing yet another module. Often it was in discussion with others waiting for their run to return. Still other times it was on to some other project for some other subject entirely. In some ways that mental break was a good thing. All in all one did learn some patience. Patience is a noble and necessary virtue for software developers – and other people as well.
The instant edit, compile and run cycle of modern high speed compilers has changed the way we develop code. In many ways for the better but in the process I sometimes fear we have lost something as well. Patience, careful consideration, attention to detail, and maybe solid planning. Back in the card punch days we saw more women in software development than we do today with the fast edit/compile/run system. Coincidence? I wonder. Does today’s way lend itself less to the way women work than the “old way?” I have no idea. I know of no study. But it is something I just happen to wonder about.
[EDIT: See also Eugene Walligford's blog post at "I Love The Stuff You Never See"]
This is another of several recent “CSTA Blasts” that I am posting on my blog. If you are a member of the Computer Science Teachers Association you will have seen this and I apologize for the duplication. If you are a computer science educator, especially in K12, you should be a member. SIGCSE and the CSTA Computer Science & Information Technology conference are and away my favorite events of the year. Not that I don’t love TCEA and ISTE but the ratio of good CS conversations at these two events is just over the top cool for those of us interested in Computer Science education. As usual, the SIGCSE committee is trying to meet the needs of K-12 computing teachers and not just the higher education faculty that make up the majority of the attendees. Oh and yes Microsoft will be there. Right now it looks like I will be doing a lab on Kodu for the Kids Camp that has become a fixture at SIGCSE.
SIGCSE 2012 is coming to Raleigh, NC Wednesday February 29 through Saturday March 3. The SIGCSE Technical Symposium addresses problems common among educators working to develop, implement and/or evaluate computing programs, curricula, and courses. The symposium provides a forum for sharing new ideas for syllabi, laboratories, and other elements of teaching and pedagogy, at all levels of instruction. Information on SIGCSE 2012 may be found online at: http://www.sigcse.org/sigcse2012/attendees/
In recognition of the special circumstances many K-12 teachers face with respect to funding conference attendance, special rates are available for either Friday only or Friday and Saturday. The two day rate includes the Saturday Banquet Luncheon. The conference schedule has been created with K-12 educators in mind with many sessions available Friday and Saturday that are of interest to us.
Information on hotel accommodations is available on the SIGCSE website. The Clarion Raleigh Hotel State Capital provides a more economical option and is within easy walking distance (8 blocks) of the convention center. There is also a free city shuttle that provides transportation from the Clarion to the convention center. There are many restaurants in downtown Raleigh that are easily accessible on foot from the convention center or the conference hotels.
Online registration is available now. The early registration deadline is January 30, 2012. SIGCSE is a large conference and hotel space will book rapidly. You should make your reservations as soon as possible after registering for the conference.
This email is being sent to CSTA members. Please share it with your colleagues who may be interested in attending.
I look forward to seeing you in Raleigh for SIGCSE 2012.
SIGCSE 2012 High School Liaison