Here’s a chiptune cover of Journey’s Don’t Stop Believin’ I made during some time off I had last December. I just haven’t gotten around to posting it until now (though I did make a few tweaks yesterday). I think we were watching Glee at the time and remember thinking a chiptune version would be even better than theirs. It was made with FamiTracker, and this video is of the song being played in FamiTracker:
You can listen to and download the MP3 from its 8bitcollective page. Or download the NSF (what’s an NSF?) and play it in an NSF player, such as my own Chip Player. Or perhaps something a bit more stable like Audio Overload.
The C99 language added some pretty neat features to the ANSI C we know and love (now known as C89). I used a construct called compound literals in my iPad Dev Camp presentation, and it seemed new to a lot of people. Here’s a summary of some lesser know features about C99 that are worth knowing. And, since Objective-C is a strict superset of C, all this applies to Objective-C, as well. Best of all, as of recent Xcode (3.0? 3.1?), C99 is the default C dialect for new projects, so you don’t need to do anything to start taking advantage of these.
First off, a big thanks to David Kinney (@dlkinney) for organizing this year’s iPad Dev Camp Chicago. Here are the slides to my Core Audio presentations:
The source code to the two projects I went over are up on BitBucket:
- A440: A Core Audio “Hello World”. Runs on Mac, iPhone, and iPad.
- Chip Player: A chiptune player using the Game Music Emu library. Runs on Mac and iPad and plays popular chiptune file formats, such as NSF and GBS.
Use the ipaddevcamp2010 tag to see what they looked like at the time of the presentations.
iPad Dev Camp Chicago is coming up this weekend, and I’m going to be giving two talks about Core Audio. One of the applications we are going to go over is called A440, a “Hello World” of Core Audio. It plays a simple a 440 Hz tone using both Audio Queue Services (AudioQueueRef and friends) and Audio Unit Processing Graph Services (AUGraph and friends). In order to keep the code as simple as possible, it does not use any of the “Public Utility” C++ APIs.
I’ve posted the code up on BitBucket if you want to check it out before hand or are unable to attend. I also hope to have a more complex and complete audio playing application ready to release by this weekend, too. Hint, it’ll have something to do with 8-bit chiptunes. So if you’re in Chicago, sign up! It’ll be fun!
This afternoon, I had to debug an issue that involved performSelectorOnMainThread:. This method is a great way to get a background thread to safely interact with the user interface. But when you set a breakpoint or crash nested down in one of these method calls, sometimes it’s useful to get a backtrace of who called performSelectorOnMainThread:. Unfortunately, by the time our method gets called, we don’t have that information. The same goes for performSelector:withObject:afterDelay:.
After some good suggestions on Twitter, and a bit of casual recreational coding, I’ve come up with a general purpose solution that involves, of course, method swizzling.
On Monday, I had a series of tweets ([1], [2], [3]) about what I like about Java that I miss in Objective-C/Cocoa that were probably better off in a blog post. I blame Jeff LaMarche for baiting me into the tweet rant, so here’s the the same thing, in blog post format with more detail and other points I forgot to mention.
What I Miss
Before settling in on Objective-C, I was a Java guy for about six years or so. Overall, I much, much prefer coding in Objective-C to Java, and have no intentions of going back to Java. But that doesn’t mean there’s some things I miss. Here’s a quick list, with more detail below:
- A flexible I/O class hierarchy
- Everything in java.util.concurrent
- Exceptions for errors
- Packages, a.k.a namespaces
- One file for interface/implementation
- Type safe enum classes
- Annotations
- Awesome IDEs (IntelliJ)
This is a follow-up to my post on why you should unit test Cocoa and iPhone applications. One reason I think Matt is against unit tests, at least given his particular examples, is that the tests themselves are quite large and confusing. They also use category smashing to override methods and inject mock objects and use runtime trickery to gain access to private instance variables.
These are all code smells that something isn’t right. Remember, TDD is about tests driving development; however you must remember to listen to the tests when they are crying out in pain. I’m going to take Matt’s Mac and iPhone projects with unit tests and re-work them so that they are much more manageable and cleaner.
Matt Gallagher, on his absolutely fantastic Cocoa with Love blog, recently wrote a series of posts about test driven development (TDD) and unit testing Mac and iPhone applications:
- A sample Mac application with complete unit tests
- A sample iPhone application with complete unit tests
- Quality control in application development without unit testing
However, I heartily disagree with a major point in the conclusion of his final post:
Unit testing an application is filled with difficulties and problems. In my development style, I consider the time cost of unit testing an application outweighs its benefits — especially since a unit tested application still requires system tests like user-interface and regression tests for proper validation.
Before I talk about why I disagree, I want to say that I do agree with the next part of the conclusion:
Regardless of whether you use unit tests, formalized system testing — either automated or manual and methodical — is required to fully validate an application and ensure the lowest possible low bug rates.
By and large, sudo on Mac OS X comes setup with some sane defaults. But here’s two lines I add to my /etc/sudoers file on a fresh install:
Defaults passprompt="%u@%h's password: "
Defaults timestamp_timeout=15
The first line changes the password from something generic:
% sudo whoami
Password:
root
To something a lot more useful:
% sudo whoami
dave@fuji's password:
root
The second line changes the time between needing to re-enter your password from 5 minutes to 15 minutes. This is handy if you’re confident you’re in a fairly secure physical environment, like an iMac at home, and you find sudo asking for your password too frequently. If you work in a more paranoid physical environment, you may want to keep the timeout at 5 minutes.
Remember to edit the file with visudo(8). Don’t edit it directly.
% sudo EDITOR=emacs visudo
One of my gifts to my wife, Nancy, for her birthday this year was the Happy Birthday song, chiptune style. It’s an actual NES program, hand-coded in 6502 assembly. This is the first original NES program I’ve written, and could be considered my first homebrew or even demo. While you can download the ROM and run it yourself, here’s a video of it running in Nestopia, an NES emulator [YouTube link]:
Some interesting stats about this program:
