The Flying Jalapeño Lives

This is just something I picked up over the weekend to interface with Terminal.app via AppleScript:

NSString *s = [NSString stringWithFormat:@"tell application \"Terminal\" to do script \"cd %@\"", folderPath];
NSAppleScript *as = [[NSAppleScript alloc] initWithSource: s];
[as executeAndReturnError:nil];


The intent is pretty easy to pick up (Also, please feel free to handle the error). The question and answer can be found on StackoverFlow.

The runtime has been a bit of a mystery to me.

To be sure, I have yet to explore some of the more dynamic aspects of Objective-C/Cocoa in my applications.

In fact, as many know, you can move along quite happily though your Cocoa/iPhone programming without directly daling with it. Others might not realize what’s “under the hood”.

If you really want to have some fun, you will need some fundamentals.

To this end, Mobile Orchard last podcast featured Rogue Amoeba’s Mike Ash who gave an overview of the runtime.

MDN also released episode 7 of the MDN Show which goes into more depth in an interview with Jonathan Dann of Sofa.

If these podcasts wet your appetite, Mike Ash has also produced a nice series of blog posts on the subject as well.

I’m sure you will find other great resources in the community as well, but this should give you a good head start.

The buttons in the iPhone SDK suck. There, I said it.

Almost everything on the iPhone round, glossy and “3Dish”.

Except the standard RoundRect buttons included in UIKit.

Of course we can go off and use one of many drawing apps to crank out some nice glossy buttons, but there a few problems with this approach.

First, you have to be at least competent in using some advanced drawing tool.

Second, any buttons you create are static and must be shipped as a resource in your app. It is acceptable to want to generate multiple colors on the fly.

To solve our dilemma, we can use the work of two other people.

Matt Gallagher posted a great article on generating gloss gradients a while back.

It’s quite informative in explaining and implementing the effect. You can run a OS X app and play around with the setting.

The code didn’t quite work on the iPhone because of the absence of NSColor.

So we have two problems. First, we need to adapt the code to the iPhone. Second, we need to add this code to UIButton as a category.

Good news everyone! It’s already been done.

More than that, you can follow a 5 step tutorial taking you through the process of building the code and some explanation behind it.

The first post of the series can be found here.

I would credit the author, but I think he (or she) has gone through great pains to omit his (or her) name from the blog. (Or maybe I’m just too dense).

Update: Michael Heyeck wrote in to claim his awesome work and updated his “About” page to be a little more forthcoming.

Anyways, try it out. It works good for making glossy buttons pretty quickly and it is tweak-able.

I find the manner in which programmers vehemently defend and deride coding style preferences absolutely fascinating.

I personally feel that dot syntax serves a worthwhile purpose.
In fact, I have been refactoring old code to conform to this convention.

In the end, I feel these types of debates speak to the health and growth of the Cocoa/Objective-C community.

I’ve used/repurposed several open source projects for use in my code.

If you’re not trying to use someone else’s code as much as possible, you’re not doing OOP.

I won’t call this a series, but I would like to showcase some of the great code that is out there waiting to be used. All you have to do is drop it in your project.

This time I’ll point out a framework that I use very frequently:

json-framework (available on Google Code)

It’s drop dead simple to use. You give it data, it gives you a Cocoa Object, end of story.

Here is how I use json-framework in some of my code.

The SBJSON class gives you back a NSArray, NSDictionary, or an NSError (pointer reference).

If you need to parse JSON data, check it out.

PlaceHolder

PlaceHolder

Full Disclosure: I am attending this conference as non-paying guest.

If you are like me, you really appreciate those nice, neat classes that make your most tedious work a little more bearable.

Billy Gray over at zetetic has done just that with his NSDate+Helper category.

if allows you to completely forget about NSDateFormatter and easily format dates in just about any format you need. it also has some nice convenience methods built in to it.

You can find it on here on GitHub.

Objective-C 2.0 properties are pretty useful.

They not only save you time, but also help “automate” memory management on the iPhone. They save you from screwing up your accessors.

Another benefit, is the orthogonal relationship with dot notation. Dot notation short hand makes it extremely quick to change the state of an ivar with minimal keystrokes.

There are (too) many debates about whether this syntax is “ugly”, “tacked on”, etc… This post makes a great case for using dot notation to differentiate the intent of your code.

In fact, properties used in concert with dot notation are so convenient that there is little excuse to ever access instance variables directly. Another bonus is the “automatic” memory management. Well as automatic as you can expect in a reference counting situation.

You may be opposed to creating a property for an ivar you want to be private since doing so allows unrestricted access. This creates an encapsulation problem, but one that is easily circumvented with another Cocoa trick: anonymous categories.

By declaring your private property within an anonymous category in the implementation file, you effectively hide it from other classes.

It is still true, that you can peek in the implementation and find these hidden properties. But it will be readily apparent to you, or anyone else, that they should be left alone since they reside within the implementation file.

I use this technique to clean up my interface files (along with placing private methods in the category as well). This gives your classes a nice, neat, and more importantly, easy-to-understand interface.

Another issue is when you need to react to state changes of an ivar. This can be mitigated using KVO. By observing properties, you can react easily such changes.

Do you use dot notation or do stick with brackets? Do you create properties for all of your ivars or do you prefer to handle their memory management in the implementation?

When you begin a new project, you always begin with an immense amount of passion. You work diligently, economically, and with sharp focus.

Such ambition, however, can quickly subside after a few snags or if monotony begins to set in.

Unlike those that work in a development shop with several employees, we may have no one to push us but ourselves. As an indy developer, you not only need to be focused and regimented, but also must find ways to maintain your sanity.

A common solution adopted my man developers is to work on more than one project at a time. Starting a new project can feel like a mini-vacation. You get to solve new and interesting problems making work less like work (the way it should be).

Unfortunately, many of us go on “permanent vacations” (Aerosmith pun intended). It is a seductive trap to fall into. The path to indy success is littered with the many carcasses of unfinished projects.

It is a fine balance. On one hand, you need to focus and work hard to push out a product. On the other, burning yourself out can be difficult, if not impossible to recover from, emotionally and financially. It is far better to distract yourself for a few days with a side project than to open yourself to mental and financial ruin .

Like everything else you do as a micro-ISV, you need to police yourself (you are “independent” after all). Use iCal and schedule yourself a “2 day break” to work on another project.

Try to prevent boredom from setting in, in the first place. Make sure you outline discrete tasks and complete them one at a time. Completion is a reward that does not receive enough credit.

One tool I like to use is Scrumy. It is very easy to visualize your progress on individual tasks (Note: this is a scrum web service, but you don’t need to be completely versed in scrum to use it)

Another great tip from Matt Gemmell (via the MDN Show) is to create new components in a blank Xcode project. This allows you to focus on the task at hand and not let the rest of the project to “weigh” you down. There are other benefits as well which you can get from listening here.

What tips do you have for staying focused? How many projects can you successfully juggle and still make concrete progress? Let me know down below (I like cheap rhymes as well as puns).

Edited: To correct Matt Gemmell’s last name. How I spelled that wrong after hearing his theme song, I’ll never know.

I sat down at the local Best Buy (unfortunately no local Apple Stores until I move back to Philly) and compared both the 15″ and 17″ MacBook Pros .

I currently work on a 13″ MacBook, so the 15″ would definitely be a step up. Extra screen space is not just welcome, it is needed. Although my MacBook is ultra-mobile, I could not handle the 13″ MacBook Pro anymore for development.

Instantly I realized that the MacBook Pro 15″ is a great balance between productivity and mobility.

The 17″ model is a different planet however. Xcode wasn’t installed on the demo machine, but I opened many application windows to help imagine my workflow.

The extra 2″ PLUS increased resolution makes the 17″ screen enormous by comparison. Where the 15″ feels like a laptop with a bigger LED, the 17″ is a workspace (to quote someone on some forum, I can’t remember quite where).

I couldn’t resist. I finally settled on the 17″ model.

I use Spaces heavily in my typical workflow. My workspace divided into 4 spaces, which really optimizes my screen real estate. I think I may be able to cut that down to just 2 Spaces with the 17″ (possibly just 1).

I’m not terribly concerned about the weight. it really isn’t that much bigger or heavier than the 15″ model. Both models are significantly bigger than my current MacBook and will require a new “wardrobe” regardless.

I did think long and hard about getting the 15″ and an external monitor. However, my work patterns aren’t set enough. I work mostly at home, but also coffee shops. I never know where I’ll be. I may also begin renting a workspace rather soon (indy hall).

My thinking is the 17″ machine best fits my unpredictability right now. I can worry about later when it comes. Maybe that is short sighted, but work only ever gets done NOW, nothing ever gets done later (but thats another post in itself).

Now if my shipment can ever make it out of Shanghai Anchorage.