I’ve set out my goals, and done my research, so it’s time for me to actually start making some decisions for my iOS Shooter. This week, I’m picking my concept, themes and major elements of playing style. These ideas will be something of a road map for the rest of the design and planning process. [...]
Home » Archive by category "coding" (Page 2)
Archive for the 'coding' Category
iOS Shooter Project: Research
I’ve had a busy week of research for the iOS Shooter Project and boy, are there ever some interesting shoot ‘em ups out there! After a little bit of Googling and scouring the App Store, I picked 5 shooters to look at in detail. I spent a bit of time playing each one to get [...]
A New Project
The blogging’s been a bit slow of late. And I’ve been looking for a new technical project to sink my teeth into. So I’m going to kill two birds with one stone, and blog about writing a new mobile game! Working on Togolon was great fun, but terrible at promotion as I am, not many [...]
Java: Quick and Easy System.out Redirection
I recently found myself in the exciting position of having to put together some unit tests for a Java command-line utility, whose results of course all went straight to System.out. Handily, Java provides some neat functionality to redirect output streams. I fiddled around with a few output stream types and hit all sorts of trouble, [...]
Delete all writeable files from a folder heirarchy – Handy for Perforce users on Windows
Despite being a huge Mac fanboy (see the keyboard & mouse combo in the header pic), I use a PC running Windows XP at work. As such, I’m pretty used to bash-esque shells, and am continually frustrated by the Windows command-line being just that little bit different.
My build tree has been broken for a couple of days, and in the hope of saving it, I wanted to get rid of all the files that weren’t part of version control. We use Perforce for version control, which handily makes all the files it manages read-only (requiring you to explicitly check them out to work on them). So all I needed to to was delete all the writable files in my source tree.
If I were on my Mac or a Linux machine, I might do some complex series of piped commands in a crazily complex script…before discovering a specific command that could do what I wanted. Being on Windows, I had to read up on the syntax for the del command.
Hooray! All I needed to do was:
del /Q /S /A-r *
Bingo!
This is probably quite obvious to any Windows peeps who use the command-line a lot. But heck, if I write about it here, I might remember the command next time.
Dumb Stuff Not to do in Java: Synchronize on a Boolean
One of the great things about coding is that there’re always something new to learn: new techniques, new languages, and possibly most amusing of all, thousands of new ways to screw things up.
As a case in point, the other day, I wrote something a bit like the below:
I put this out for a code review (very useful practice – see The Joel Test), and within a few minutes, a colleague replied with the blunt, but informative "NO! You can’t synchronize on a Boolean". Being an inquisitive sort, I enquired as to why, did some reading around, and messed with the code to break it.
Why This is Dumb
The assignment jobRunning = true effectively points jobRunning at a pre-created Boolean object representing a true value. This means that jobRunning is no longer the same object as it is when it is false.
To run this through, let’s say a thread, T1 calls doJob() when jobRunning = false, then T2 subsequently calls doJob(). T1 will synchronize on jobRunning when it is false, then sets it to true. When T2 synchronizes on jobRunning, it will be a different object, so it won’t be blocked, even when T1 is still in the synchronized block of code – the synchronized statement effectively does nothing for these first two calls, and we could end up with two threads running the main body of doJob() at the same time.
Quick Fix
This isn’t a particularly difficult problem to fix, you just synchronize on a different object:
Not the most elegant of solutions, but pretty quick to implement in this case.
This is a fairly subtle consequence of the Java abstraction, and could have caused me a huge headache if it had gone unchecked – leaving one of those wonderfully annoying intermittent bugs floating around (the kind that take forever to track down and debug). So I figured it would be more than worth writing about, in the hope I might save someone else this trouble.
Bottom line: Don’t synchronize on Booleans.