OS X Development

warning: Creating default object from empty value in /home/playtank/public_html/modules/taxonomy/taxonomy.module on line 1364.

Ruby on Rails - Getting Starting on OS X

This week I have been devoting some time to learning Ruby. I'm starting with the language itself so that I can come at Rails versed in the underlying architecture. I'm a big believer in building up a decent mental model of the lower levels of a system before I begin using higher level tools.

Which is why I spent quite a bit of time messing around with DarwinPorts, installing Ruby, Rails, RubyGems, MySQL, and lots of other software. One of the things that I've heard in complaints about Ruby, and frankly about many open source projects, is that installation can be tricky and sometimes downright painful. And I'd have to say that there are a few hiccups in getting Rails working on OS X.

Core MIDI and Threading

The "obvious" test cases failing, I poured over the Core MIDI documentation to discover that the MIDI read callback functions are called on a different thread than the main application. This makes quite a bit of sense. The upshot, however, is that I'll need to write a multi-threaded method of sending the data back to my application for use. The Apple sample code for MIDIReadProc, however, was carefully chosen to be self contained and does not need any UI synchronization. Which means they chose a sample that is technically correct but which misses the intended use of the function for 90% (or more) of their target audience.

Core MIDI - A poster child for my early Apple experiences

Submitted by Brian Marshall on Fri, 2005-07-29 02:00. Core MIDI

I've begun writing some Core MIDI code today. I'm still writing some test spikes to explore the API. But so far using Core MIDI is a microcosm of my Mac experiences so far.

-The user part of Core MIDI is sweet. I picked up a MOTU Micro Lite interface for my office, and it installed incredibly easily. Drive installation on OS X is far cleaner than Windows. And once the hardware was up, the "Audio MIDI Setup" program was another pleasant surprise. It took mere minutes to set up my entire MIDI topology with nice graphical elements representing the hardware. It's obvious that Apple cares about Pro Audio users, and has done everything they can to make the user experience slick and easy.

Unit Testing Core Data

When last we spoke, I was looking for a method of applying test-first development to Core Data. After some very Core Data specific initial code, heavy refactoring, and many adventures along the way, I've finally built the solution I need. As you'll see, it has used far beyond Core Data. If you're interested in more information on my solution, let me know. Here's the story of how I ended up where I did.

First, I wrote some hard-coded tests to load the root object of the Core Data Model (NSManagedObjectModel). I then found the child NSEntityDescription objects and their NSAttributeDescription objects. This allowed me to write a hard-coded test to make sure the model looked like I wanted it to look. Fine for phase one, but it was a real pain to add any new tests. It was several lines of code to add a single new Attribute, and very ugly to start testing the second entity.

Core Data and OCUnit

2005-06-06 02:00

I've been finding a scarcity of posts on how to write Unit Tests for generated code. Specifically, I've just started working with Core Data on OS X 10.4. It's a fantastic data modeling tool. But given it's GUI nature, it's not immediately obvious how you write test-first code for it. You're supposed to write tests before you write a line of code. But in this case, you need to write test code before you use the GUI to generate the code for you.

It turns out that model created by Core Data supports reflection. It's not that pretty, but I've got a start on it. If you need to write some of your own Core Data test code, hopefully this will help you get on your way:

Syndicate content