Ah, the rosy memories of Palm

I am an ex-Palm programmer. It's been years, but I loved the whole programming culture that Palm had created. I loved their UI design philosophies, their hardware, the conventions, the fantastic API support, I loved it all. I was a Palm freak. Then not too long after the IPO'd, it got kinda sad there at Palm, it seems. There was no more love being pumped into their wonderful products. The kool-aid had gone sour for me (that, and the project I was working on that I so adored got cancelled), so I bailed out and found other new-fangled toys to play with (which was never quite as enjoyable). But here, now, many years later, Apple has restored my faith in the idea that you can indeed have an exquisite, easy to use interface on a handheld device. And more importantly you can provide excellent developer support at the same time. Or at least that's how it seems to me for now... I reserve the right to be cynical. I've eaten from the Cupertino tree many times in the past; not all its fruit are sweet and delicious.

Music Scales

I was practicing my scales up until last night when I ever so smartly cut the tip of my finger. Now I can't play until the skin grows back. Oh, well.

But before that, I was practicing my major scales. I now finally understand the Circle of Fifths/Fourths. Basically, starting with C, you can move clockwise to determine the number of sharps or counterclockwise for the number of flats you'll have in the major scale. Moving clockwise, you determine the next note by the fifth of the previous note. So, from C, you get D (2), E (3), F (4), G (5). The scale of G has one sharp in it. Which note is sharp, then, you ask?

Well, the scale always takes the form of whole, whole, half, whole, whole, whole, half intervals. On the C scale, which has neither flats or sharps, this is: C D EF G A BC. See? C >> D >> E > F >> G >> A >> B > C, where >> is a whole interval and > is a half interval.

Let's do the same with G: G >> A >> B > C >> D >> E >> F# > G. Two wholes, one half, three wholes, one half. Since E to F is normally a semitone, we have to use F# instead to make a full interval. Thus G has one sharp, and that sharp is F#.

Similarly, going backwards in fourths from C, the next note in the circle (going counter clockwise is F: C (1), D (2), E (3), F (4). F has one flat in it: F >> G >> A > Bb >> C >> D >> E > F. Normally, B to C is a semitone. But to get from A to "B?" (where ? is either normal, flat or sharp), you must use a half interval, which is the note of A#/Bb. Since you have already used up the letter A in the scale alphabet, it is more clean to use Bb.

An additional point to not forget is that the circle progresses forward based on the the previous note. So in the above examples, the next note to consider from F is Bb (the fourth note) and from G is D (the fifth note) and that each progression adds an additional flat or sharp.

Here's an interesting tidbit: in musical notation, you can tell which key you are in by the number of sharps or flats that are drawn next to the clef symbol. Of course, you have to know which notes will be flat or sharp, but I haven't figured out how to easily memorize all of that yet. I just understand the patterns.

On Musical Triads

I'm teaching myself guitar. Today, reading "The New Complete Guitarist," I got to the part on scales and chord theory. I already know how to play basic open and barre chords, but I feel I need to learn the details before I can advance my skills. Not unlike how I learn how to program. I very much expect this to change as I learn more, but here is what I am starting with.

1st: Major scales have a "root" note. C is the typical main scale (due to characteristics to be described later) and so its root is of course: C.

2nd: Intervals on the major scale occur between the notes. This gives us either a "tone" or a "major second" such as C to D or a "semitone" or a "minor second" such as E to F. The concept of a "second" refers to the ordinal position relative to the base note being references (C and E in the above examples).

3rd: Interval jumps (second, third, fourth, etc) on the C major scale are organized thusly:

• A single tone jump is a "major second"
• A single semitone jump is a "minor second"
• A double (three notes total, including the base note) jump that is entirely made of tone is a "major third." If there is a semitone in it, it is called a "minor third."
• With four tones or semitones, it is called a "perfect fourth."
• With five tones or semitones, it is called a "perfect fifth."
• For six and seven tones or semitones, it is called a "major sixth" and "major seventh" respectively.

4th: Everything listed above gets mucked up when discussing a non-C scale. Reviewing this as a simple letter arrangement (where spaces represent tone intervals):

• A: A BC D EF G A
• B: BC D EF G A B
• C: C D EF G A B
• D: D EF G A BC D
• E: EF G A BC D E
• F: F G A BC D EF
• G: G A BC D EF G
  

It appears to me that the 6th and 7th intervals become "minor" if there are two semitones in it, whereas the C scale only has one semitone in it until you reach the octave. On the B scale, it gets strange because the fifth interval (B to F) has two semitones in it, where as both the C and A scales have only one. This appears to make it a "diminished fifth."

5th: The concept of the "dominant seventh" describes the addition of the seventh interval, though I am not sure why. "Dominant" refers to the fifth chord on the major scale.

Loathing of Emacs

I try to stay out of the editor wars; I'm a firm believer in the adage that you should pick a text editor for programming and stick with it. Learn it as best you can (and as it suits your needs) and use it everywhere. But a couple of recent experiences have caused me to really loathe Emacs. Okay, not really Emacs itself, since I know so little about it, but I really dislike the Emacs' "force it on you" attitude I've encountered recently.

First issue was in my attempt to gently learn Common Lisp. The book I was reading insisted on using Emacs... for the basic reason it allegedly helps in tracking parentheses. No. Don't write a book (or a programming language) on the assumption that a newbie will have to learn not only the new language, but also an entirely new (and non-intuitive) text editor.

Second issue was reading a book that used Oz (via Mozart) as its primary source for programming examples. Not a problem, so long as you teach me a little about the language. I even d/l the interpreter for my Mac OS. When I launched it, it insisted that I have Aquamacs installed. What? Why? And why that particular version of Emacs? I already have Emacs on my Mac to begin with! I don't want another one. So, I install Aquamacs and run it (independent of Mozart). Fine, now I see what it looks like. But how the hell do I exit? Why does't Cmd-Q work? Why is Aquamacs insistent on not letting me shoot myself in the foot and letting my Mac handle the quit routine? C-x C-c didn't work either. I had to force quit my way out of Aquamacs.

Anyway, the whole past couple of events have been really frustrating. I know how hard Vim is to learn, but I never, ever had a problem killing the app in a GUI environment, nor has any language book insist that I use it for that particular langauge. I also know I don't know Emacs itself at all, but why are there people out there so gung-ho on it that I can't possibly use an alternative? My hope in reading these books was to learn a new language or two, not struggle with installing software. So, I'm off to learn some other programming techniques instead. Maybe one day I'll come back to those books, after I've sufficiently learned Emacs on my own terms.

Objective C Doc

Found this link at another blog (fullof.bs; no seriously, that's the domain): http://ktd.club.fr/programmation/fichiers/cpp-objc-en.pdf. So far, it's been a good read. Thought I'd post it since I've been away from the blog for a bit. Work and life has taken away my time to program for the iPod. Hope to get back to it soon. The more I read of Obj-C, the more I like it.

Finally Displayed an Image

I'm not liking the Cookbook very much. It seems to try to be a combination of advanced-user-cookbook and beginner-tutorial and does neither very well. The author seems to take a huge number of short cuts, seeming to assume you went through the whole beta SDK process along with her. I didn't. I'm new to the game.

Anyway, since it wasn't really helping me, I decided to just try and draw a single picture on the simulator. What a pain, but then I had a similar problem with C#. UIImage:drawAtPoint doesn't actually draw at a point, for example, until you add it to a UIImageView. I was trying to draw the image raw, but that wouldn't happen. I suspect it's doable, but there's too much linkage with the .xib file that gets created in a basic project. Anyway, after much wailing and gnashing of teeth, I finally got it. Here it is, without the proper memory handling (because handling that's still new to me as well):

UIImage *myImage = [UIImage imageNamed:(@"Olga-Kurylenko-1.jpg")];
UIImageView *myImageView = [[UIImageView alloc] initWithImage:myImage];
[myImage drawAtPoint:(CGPointMake(50.0,50.0))];
[self.view addSubview:myImageView];

So there you are. I need to free up the "myImageView" variable and come to grips on who the heck frees the "myImage" variable. Oh, this goes into the "viewDidLoad:" method, by the way. The logic is that viewDidLoad: gets called and when the super viewDidLoad gets called, then the image view will also get displayed.

New iPhone/Obj C books

Bought two books on Friday:

• The iPhone Developer's Cookbook: Building Applications with the iPhone SDK
• Cocoa Programming for the Mac OS (3rd Edition)

Just now delving into them. I read some reviews on Amazon for each. The iPhone Cookbook got adequate reviews; I could readily see the points that some of the bad reviews were making. Nobody seem to notice the large number of misspellings in the book (like using "build" for "built"). I wonder if the author had an editor look at the book at all. I bought it primarily because it was the ONLY iPhone programming book at Barne's and Noble (the only close competitor was a book on programming for Safari for the iPhone; not quite the same thing).

The Cocoa Programming book starts out really well. I think it'll help dramatically in my understanding some of the more overwhelming aspects of learning this new programming language. I'll probably review both books later, after I've used them a bit more.