Entries Tagged 'Beginning Programming' ↓

I’m now diving into XCode 3, thanks in no small part to my new black MacBook! One thing I had been looking forward to is the syntax highlighting that shows you the scope of the function or method or code block. Beautiful stuff. I had envisioned it myself several years ago, when I first learned CSS. (I’m sure I’m not the first and obviously not the only…)

Now that XCode 3 finally has code folding, though not as slick as TextMate’s code folding, it will flash the scope depth highlighting colors. But it goes away quickly. Here is how to turn it on to stay (it isn’t obvious or self-apparent).

View>Code Folding>Focus Follows Selection

Or a picture …

What’s the secret to getting good results from Icon Composer?

That’s actually very easy to answer. Most of all, a good design that follows the ideals set forth in Apples HIG (Human Interface Guidlines). But aside from that, you need to use Photoshop for the final image. Regardless of how you design the initial image, in Photoshop, create two layers. One for the image, one for a black shape that is the same outline as the image. Make sure you’ve got a square canvass in Photoshop also. Then, Save As… select TIFF as the format, with no compression and preserve layers.

Now drop that tiff file onto icon composer. You’ll get as good as possible at this point.

So, you, like me, want to make your own buttons in interface builder? I too struggled with this. Sometimes the help menu in Interface Builder just sucks. Well, generally it sucks. The problem you may have had, the problem I have had, is simply that your button graphic when clicked gets a white rectangular background during mouse down. Well, I finally figured it out! (This is for XCode 2.x and I don’t know how it goes in XCode 3, but I imagine it is similar.)

First off, of course, you need a graphic of your own. PNG format is best. Make it pretty in Photoshop, export it as a PNG with transparency, and at the desired size. Now, drag it into the XCode window, into the Resources group. Next, open your NIB file in Interface Builder. Add a button to the window. In the inspector palette, with the button selected, you need to change a few options. For Type: choose Square Button. Now, click on the Images tab in the window that holds Instances, Classes, etc… Drag your image onto the button you created. Then, with the button selected, uncheck the Bordered checkbox. Next, change the inspector from Attributes to Size, and resize the button to take up the amount of space you like. Finally, change the inspector palette back to Attributes, and change Behavior: to Momentary Change.

Try it out with command+R. Click your button and see it change the way you expected! No more white background on mouse down!

As an aside, if you don’t want the default shaded button on mouse down, create the alternate appearance in Photoshop. Save it like before as a PNG of the same size, but with a slightly different name. (just append ‘down’ to the end of the name) Add the button to the XCode project’s Resources group like before. In Interface Builder, it should now appear in the Images. Select your button. In the inspector palette, just copy the image name as it is in the Icon: field and paste that into the Alt. Icon: field and append ‘down’. Or, just type the name of the image minus the .png extension. Test it out. Your button should change exactly as you like with a mouse down action.

If you want more complex changes or animation, you’ll probably do well to use the Core Graphics API and build it yourself with that.

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)

Working on the RaiseMan application in Cocoa Programming For Mac OS X 2nd Ed, I kept getting ” ‘ClassName’ may not respond to ‘-methodName’ “warning messages on successful builds. The warnings were obviously stupid compiler warnings. Trouble is this: Objective-C (and thus Cocoa) does not care what order you implement methods in your .m file, BUT the compiler is just not clever enough to realize this and wait until later to generate warnings like this.Annoying. Especially so, when you consider, I knew this long ago, but had forgotten it. But to be sure, even though you can put methods in any order, when you get such erroneous warnings, check to see if the method flagged in the warning does not call a method that is defined later in the .m file. If you find this to be true, simply reorder your methods so you can build without warnings. Ideally, you should build successfully with few or no warnings. No warnings is always ideal. Compilers are clever tools but not perfect. The upside of this annoying defiance of the language? When you do get your methods in an order that generates no warnings, your code will be more readable and maintainable because no method will call another method that does not come before it!Finally, I don’t know if this has changed in XCode3. I doubt it, but I have not taken the plunge into Leopard, because I can’t afford to buy a new Mac capable of smoothly running Leopard. (and because I still don’t really like Leopard as much as Tiger and Panther, even though I use it at work every day… maybe another dot-update or two will bring me into the fold…) 

Duh?! Physical access to any machine makes it highly vulnerable to accessing the contents of its storage media. Apple knows that. Any IT manager worth spitting on knows that. Steve Ballmer probably knows that. George Bush might even know that! These guys who developed the cold memory dumper are butt stupid because it’s a waste of time and effort. This is no big secret or mystery. If you have an OS X install disk that is not older than that particular Mac, you can simply put the disk in, force power down, restart booting from the install disk, from the Utilities menu launch Reset Password Utility. This allows you to change the password for any account on any connected bootable volume as well as enable the Root account! That’s a hell of a lot easier than this bullshit attack.Apple’s not stupid and this is no secret.If you really, really need more security, you simply do not allow physical access to the computer. Need more? Do not allow network connectivity. Need more? Enable a firmware password on the drive. Need more? Get custom firmware that disables startup keys normally available on the Mac OS. Need more? Be a Luddite.Security is always a trade-off with any connectivity. The old phrase Boot Access IS Root Access exists for a reason. 

Some Ruby Gems are better than others. Some are great once they are working, but how to get them working is not always obvious… BlueCloth (the Ruby implementation of Markdown) is one of these. Unfortunately, simply doing sudo gem install BlueCloth is not enough. The BlueCloth home page, a Trac site, does not tell you squat about it either. So what do you do? Well, as with any gem that doesn’t just install easily and work with a simple require 'gem_name_here', the first thing to do is look in the gem’s directory!!If you do not know where your gems are, at the command line do gem environment and you will see the path to your gems. Copy that path and cd to it. Then do ls and you will see you’re still not there. cd gems will get you into the proper directory for the gems.Once there, you will notice that each gem has a directory with the name and version number of the gem itself. In this case, cd BlueCloth* should be enough to get you into the BlueCloth directory. If you do have more than one version, you will need to add the version number to that.Once inside the BlueCloth directory, you will see a README and install.rb, first read the README. Hmmm… it is not real clear language, but it does indicate you will need to run install.rb. OK. In the same directory, run ruby install.rb and you should see a few lines:Cloth Installer Revision: 1.3 Testing for the StrScan library...foundTesting for the Devel-Logger library...foundInstalling   If you get any error message, you either need to use sudo to do it, or you just do not have enough permissions/privileges on that machine.  If you get no error message, then you can now use BlueCloth for converting Markdown to html!In any normal Ruby code, simply be sure to add:
require 'rubygems'
require 'bluecloth' In a Rails application, simply add the second require line in application.rb and you will be ok to use BlueCloth from within your Rails application. You can actually use both require lines there, but the require for rubygems is just taking up space on the page at this point. If Rails is working, then RubyGems has already been required somewhere else! The beautiful thing is, BlueCloth is easy to use and very effective!  One more thing… this information is true on Linux, OS X, and any *NIX installation. On windows… I have no idea. Personally, I cannot see why people go through the pain of programming on windows, except that it can pay the bills…? 

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>

Scotty is branching out and kind of bringing others on board… Late Night Cocoa is now part of the Mac Developer Network. But there’s more! A new podcast from Scotty, Mac Developer RoundTable is out and is as excellent as Late Night Cocoa, but with the different dynamic of multiple developers on together and interacting, sharing stories and bouncing ideas around! ( tune in for each episode to see what way they’ll geek out in the end when things start to break down at the end…)
Boris has also joined the Mac Developer Network, with his also great podcast, Cocoa Cast. Boris is also soon bringing us something new called Cocoa Cast Express.

And, if anybody is wondering where that very cool artwork for Late Night Cocoa, Mad Developer Roundtable and Cocoa Cast Express came from… me! So all of you developers out there, if you want some cool design work done for your application, you can always contact me and we can certainly work something out. And if you’re still reading at this point, rest assured, that my blog (you’re reading it now) is not the finest example of my artistic skills, but you may find some tidbits in here…

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…