Entries Tagged 'Books' ↓

NSNotification and NSNotificationCenter are two super useful classes in Cocoa. Like so many things in Cocoa, they are well thought out. But notifications can be a source of hard to track down bugs. You will find them, because often they prevent your application from doing things that should be seen visually in the interface. The question is, how quickly will you find them…?

This code (from the Hillegass book, Cocoa Programming For Mac OS X, 2nd ed.) shows an NSDocument subclass implemented and registering each instance of itself as an observer of particular notifications:

 
@implementation MyDocument

- (id)init
{
    self = [super init];
    if (self) {
		employees = [[NSMutableArray alloc] init];
		NSNotificationCenter *nc;
		nc = [NSNotificationCenter defaultCenter];
		[nc addObserver:self
			   selector:@selector(handleColorChange:)
				   name:@"JJColorChange"
				 object:nil];
    }
    return self;
}

…

And here we have another object’s method that sends the notification our document class is interested in observing and acting on:

 
...
- (IBAction)changeBackgroundColor:(id)sender
{
	NSColor *color = [sender color];
	NSData *colorAsData;
	colorAsData = [NSKeyedArchiver archivedDataWithRootObject:color];
	NSUserDefaults *defaults;
	defaults = [NSUserDefaults standardUserDefaults];
	[defaults setObject:colorAsData
				 forKey:JJTableBgColorKey];

	NSNotificationCenter *nc;
	nc = [NSNotificationCenter defaultCenter];
	[nc postNotificationName:@"JJColorChanged" object:self];
}
…

I did take out all NSLog lines to make it a bit easier to follow the code itself. There is nothing special or spectacular or unusual about any of it. This is just an example of where naming things can be a big deal. NSNotifications can also indeed be a bit like the infamous GOTO statements. Let’s face it, eventually object orientation can lead to its own brand of spaghetti code, too. As convenient and useful as they are, they are a bit fragile, since the names are important, generally hard-coded, and I haven’t yet seen or come across a nice category/protocol style way of simply declaring an object to be an observer of some set of notifications. Even with it, you still need to act explicitly on a notification, so it does require some care to make sure things are spelled right.

Did you find it yet? I hope so. With a lot more code surrounding things, it can be a bit tougher to locate, but the difference is between:

    @"JJColorChange"

and:

    @"JJColorChanged"

Only one letter. Conceptually, they’re also very close. Observing both the action (noun) and the completed action (regular past tense verb). Either one could be a valid, short announcement! Both could be part of a larger English sentence respectively, and still express the same thing.

Perhaps this is why Cocoa engineers seem to use “Did” instead. A lot easier to spot the difference between:

    @"JJColorDidChange"

and:

    @"JJColorChange"

Why? It is a subtle effect of the way the human brain actually reads and recognizes words. We do not read each letter. Our brain scans text for the general shape of whole words and phrases. That’s the developmental difference between somebody who can read, and somebody who is
still
learning
to
read
and
reads
like
this.

Thus, if you have a choice you want to choose the added word in the middle that changes the shape of the whole thing. This same effect occurs with CamelCase or the_underscores_in_ruby. But look at these examples as well:

    @"CamelCase"
    @"CamelCased"

    @"CamelCase"
    @"CamelDidCase"
    @"CamelWillCase"
    @"CamelByCase"

Notice now, how the last bunch make a lot more sense and are easier to distinguish visually. What some people initially believe is verbose and hard to read is made with some thought in mind. So now you see classic Steve Jobs/Apple thinking in the design even of Cocoa. (ok, ok, NeXT, but even then, same bunch of brilliant people and same culture)

There is a pretty decent interview with Russ Olsen on his new book on design patterns in Ruby. In it he focuses on what is different and the same in Ruby design patterns. I’ve been thinking a lot about Ruby and what it represents, particularly when I’m (sadly) not working in Ruby.Mr. Olsen talks about how Rubyists just don’t bother with the factory patterns. As I understand it, the factory pattern has to do with object oriented classes that are called abstract classes and are developed as foundations for other classes. They’re then used to be sensible defaults that make descendent classes have lots of built-in goodness.Mr. Olsen wonders aloud why Rubyists don’t use them much. Well, it’s simple. Ruby itself has it built in for the most part. Ruby makes things clean enough that we don’t need to have our hands held and be told to stand in a straight line by somebody else most of the time. Sure, we make mistakes and duplicate things, but we can. And we can still make things work and get things done. Ruby also makes it a little bit pointless, since there are no truly private classes in Ruby. We can get at the core of anything and change it. There’s no company locking you in or limiting you with their private API. Ruby culture leverages the openness of the language as well as the old Perl attitude of “good enough for now, we can improve it later if needed.” 

Ruby also represents a new level of abstraction from the machine. These days, processing speed and power are at a surplus in most situations. There will always be some need for high-performance, low-level programming, but even there, what was once done in assembly language is now done in C or C++ and will someday be done in better languages. (better for humans, that is) With Ruby and modern computers (which will only continue to improve) most of us don’t need to worry about mucking around with all that low-level crap. Quite honestly, we should not be worrying about that low-level stuff unless it truly is warranted. Ruby culture here too is about knowing that it may not be the fastest, but knowing that we can have a working solution fast and have fun doing it.Ruby gives you a chance to be concise and expressive, while still thinking in human terms more than with many other languages. Python is close to this as well, but not in exactly the same way. Interestingly, there doesn’t seem to be any real contention or rivalry between Ruby and Python, or Perl for that matter. They happily coexist as different ways of <em>getting things done</em>.Ruby does deserve all the buzz it’s getting. Believe me, programming often turned me off completely when I was younger, but not because I was younger, because it was more tedious than it needed to be. Programming should generally be about being lazy. Making a machine do things for you. Ruby makes it intelligible enough to wrap your head around what you are doing so that you <em>can</em> do it.I’ll admit, I like to do quick and dirty with Ruby as well as any old Perl programmer would do. Yes, I’m talking duct-tape and quick-drying super-glue. You can optimize and refine later. Get things done today!And by the way, you don’t have to learn design patterns first. Ruby will naturally get you using a lot of them without thinking, but if you find Ruby is your cup of tea, <em>you will want more…!</em>

The long awaited book “The Rails Way” is finally out, and it’s chock full of good stuff and even includes (slightly pre-release) coverage of Rails 2.0 already. Aside from the CD Baby boondoggle, Obie IS a Rails Core guy, ( I think… ) so he should know a thing or two about a thing or two.

The only drawback: the Rails Way is a big honker. Back breaker. The same problem with Hal Fulton’s classic “The Ruby Way”, the book is TOO BIG and heavy. I really wish publishers would get smart and publish these things in smaller volumes with numbers on the spine. It would be a lot easier to carry around and they’d quickly find out what parts of a text are really driving sales…

I’m a huge fan of Macs, no doubt about that. But… Cocoa programming leaves a lot to be desired at times. Continue reading →

For all those eager to learn Cocoa programming, yet stuck (blessed?) with 10.5 and Xcode 3, you know who you are… there is no way to run older versions usually. However, you can actually run Xcode 2.5 on Leopard! I know, I know, you want to use garbage collection, right? Well, it’s not the panacea you think it is for everything.

But for those who are still trying to learn using the Hillegass book with Xcode 3, this come from the proverbial horse’s mouth in a post to the Cocoa-Dev list:

From: Aaron Hillegass
Subject: Using “Cocoa Programming for Mac OS X” with Xcode 3.0

Friends,

I am getting some emails that go something like this:
“Hey! I just bought ‘Cocoa Programming for Mac OS X, 2nd Edition’ and
none of your directions work on Xcode 3. I hate you, I hate you, I
hate you.”

I understand your frustration, and I am sincerely sorry if you feel
that you have been cheated. The tools have changed a lot, and the
third edition won’t be ready for several more months. Let me point
out, however, that the frameworks themselves have changed very little
and the ideas in the book are still useful.

To use the 2nd edition with Xcode 3, you need to know how the new
tools are used. In particular:
1) You don’t create classes in Interface Builder any more. Create the
class in Xcode, and type in the outlets and actions.
2) You don’t have to explicitly reparse the .h files — Interface
Builder will automatically reparse the file every time it is saved.
3) Instead of control-dragging for every pointer IB, you control-click
on an object to get its connection panel, and drag from there.

To get comfortable with these changes, I suggest that you do Apple’s
tutorial before starting on my book:
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjCTutorial/

Skip my Palettes chapter! It is hopelessly out-of-date and unusable.

It will still require some patience to get through the book. If you
don’t have the patience, return the book to wherever you purchased it
– the new edition with Core Data, more Bindings, Web Services, View
Swapping, NSTask, Xcode 3, and Objective-C 2 will be available in the
Spring or early Summer.

Will I destroy my apology/helpful email with something crass and
commercial? I can not resist: I will be using a draft of the 3rd
edition of “Cocoa Programming for Mac OS X” at the Cocoa Bootcamp, Jan
14 - 18. If you want a seat, call 678-595-6773 to reserve one:
http://www.bignerdranch.com/classes/cocoa.shtml
We can send an instructor to your company, if that is more convenient/
cost-effective for you.

Also, Big Nerd Ranch will be running its first WebObjects course in
Germany, March 10 - 14:
http://www.bignerdranch.com/classes/webobjects.shtml
To register for that, call +49 (931) 9911-485.

Sincerely,
Aaron HIllegass
Big Nerd Ranch, Inc.

Finally, a Ruby book on design patterns! Wow. Some languages never get a book like that.

At this rate, Ruby will be published into the mainstream. The number of Ruby books must surely outnumber Python books and soon outnumber Perl books.

Next up, RubyCocoa book?

Objective-C 2.0 is coming this month and some of the most important features are Properties, Garbage Collection, and Iterators. Continue reading →

I recently purchased the book, Beginning Ruby on Rails E-commerce : From Novice to Professional, from Apress publishing. I’ve been working through it and I have some good and bad to say about it.

First off, it is mostly well written. They style is clear and down-to-earth. That’s great. However, it spends a little too much time on test-driven development a little too early in the book, unfortunately with tests that do not all work. This is starting to be a trend too, which is disconcerting. Apress seems to have a habit of poor technical reviewing before publishing. Not as bad as WROX, but not as good as Pragmatic Programmers (who is?).

All in all, it’s not a bad book, but I still think the SitePoint book is best for beginners. This book seems to assume beginners to web development but quickly does things that are fairly tricky in Ruby. Not good for beginners, at least not without explanation.

The biggest problem with the book is it’s inconsistencies. They begin by saying Ubuntu Linux is their baseline installation for the book, and even mention using the Trail command-line tool (though not really practical or useful) and then all web-browser screenshots are Safari (os x). The inconsistencies don’t stop there, but I don’t want to go on in much detail.

What is important about this book? There are some nice chapters on hooking up your online store to a checkout/payment system! Pretty important and left out of most Rails books.

I’m finally really starting to get things in Rails. It takes time and doing. So here are my thoughts and I hope these are useful for others just starting out. Continue reading →

I’ve been learning Ruby on Rails. Who hasn’t? Right?

Well, I think it’s safe to say there are some caveats to be aware of for anyone who is considering learning Rails.

First of all, all those beautiful screencasts and demos of building a working web app in minutes are a cool and catchy, but a little bit misleading. The truth is, if you are new to Rails, it isn’t going to be so simple or easy. If you’ve built web apps a few times before (you’re experienced) in PHP, then some things will be easier. But Rails is a lot different. Ruby is a pretty different language also.

You will need to learn Ruby, and, you should learn Ruby before sticking your nose into Rails. Trying to program in Ruby by the conventions you may be used to in other languages is possible, but not in Rails. Rails itself is Ruby, but it is (like any programming framework) boxed in to a a particular approach.

So, you need to learn Ruby, then learn how Rails is different from more usual Ruby code. Rails establishes a truckload of things it will do for you, but you have to learn what they are and you have to do things the way Rails expects them in order to take advantage of its capabilities properly. This is how frameworks go. You must bend to somebody else’s paradigm. The Cocoa framework for programming GUI applications on OS X is an example of this.

There is a lot in Rails. A LOT. It’s been under development for a long time now and has grown and matured pretty well. That said, it is a framework and it means you will need to get used to reading the API and searching the internet and reading books for answers. A big caveat, is that many books already have outdated information, and many web sites as well. Rails is typical of Ruby development, it changes quickly, it’s a moving target sometimes.

If you are new to web app development, don’t expect the Agile Web Development With Rails book to make things clear for you at first. It’s a whirlwind tromp through a lot of technologies all at once. Ruby for Rails is a better book at holding your hand and explaining a lot of things. But before all of that, make sure you’ve read a book like Beginning Ruby: From Novice to Professional and you have the ‘pickaxe’ book, Programming Ruby, 2nd edition, as a reference book.

The Ruby Cookbook and the Rails Cookbook are also useful additions as are most of the Rails books out there. Every single one of them will show you different approaches to doing similar things. Rails Solutions: Ruby on Rails Made Easy, is another book that is very recent and has excellent info on setting your system up and getting things working well before you even start coding.