Why so slow?

Many of the methods rely on getting NSDateComponents from a date via the NSCalendar. Each sends an independent call to [NSCalendar currentCalendar]. Unfortunately, getting the current calendar seems really slow. The latest SalesBag release will feature a very robust set of calendar views to help salespeople schedule their meetings. This means a ton of calculations on NSDate inside tight loops. Using the NSDate-Utilities methods and the time profiler, I found the app spending nearly half a second in [NSCalendar currentCalendar]. This is not good.

Diagnosis

The NSDate-Utilities methods that spend time with NSCalendar all call out to [NSCalendar currentCalendar] independently. For general use, this is probably fine and leaves the app a little leaner on memory. It also (seems to) guarantee that the calendar will always be right if the user changes it mid stream in the app. For Salesbag, this won’t be a problem. We assume that salespeople in the US will be using the gregorian calendar.

Fixing

To speed things up I first created a static NSCalendar variable at the top of the m file that we’ll use in place of grabbing NSCalendar fresh every time.

static NSCalendar *curCalendar = nil;

Then I replaced the #define for current calendar with my static variable

#define CURRENT_CALENDAR curCalendar

Lastly, I need to create the calendar when needed. For this I created a new macro that I placed at the head of any method using the CURRENT_CALENDAR macro:

#define INIT_CURRENT_CALENDAR if (curCalendar == nil) curCalendar = [[NSCalendar currentCalendar] retain];

// later ...
- (BOOL) isSameYearAsDate: (NSDate *) aDate
{
    INIT_CURRENT_CALENDAR
	NSDateComponents *components1 = [CURRENT_CALENDAR components:NSYearCalendarUnit fromDate:self];
	NSDateComponents *components2 = [CURRENT_CALENDAR components:NSYearCalendarUnit fromDate:aDate];
	return ([components1 year] == [components2 year]);
}

Improvement

The time profiler showed the time spent in [NSCalendar currentCalendar] dropped to a measly 35ms. Something I can certainly live with. Of course there’s no such thing as a free lunch and any developer would point out that my static won’t be deallocated until the app terminates. In this case though, the memory trade off was worth it for the speed increase.

The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 12,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 4 sold-out performances for that many people to see it.

Click here to see the complete report.

Dunno.  I’ve never had much use for resolutions related to an arbitrary day of the year.  I tend to see goal setting as an ongoing thing and goals as more of a continual series of milestones rather than a single achievable event.  Why new years resolutions anyway?  Why not 6-month resolutions?  Or monthly resolutions?  Monthly resolutions in agile sprints?  Maybe I’m onto something . . .

Most of the stuff I put up here is highly technical in nature.  Tutorials on how to do this or that in iOS or XCode.  I was tempted to go technical on this one too.  A rambling list of technologies I’ve worked with.  Another xxxKit.framework I intend to plod around with.

Boring.  Who cares.

That in itself isn’t really interesting to anyone (not even me really).  So in a different direction I’m taking stock of what I’m good at, what I’m not good at, and what I want to be better at on a very general level.  I think these could apply to anyone working as developer whether working on an indie project (as many people reading iDevBlogADay probably are) or working on client work (as I do).

Things I’m Good At:

Watching the details – It came to me in an epiphany this year.  Strangely.  I am a detail oriented person.  I was never the kid with a clean room.  I never meticulously organized my closet by color.  I never had the border-line OCD, must-organize-everything kind of personality.  I still don’t.  On some level I separate ordinary details from Details That Matter.

At any rate, I have a penchant for the details when it comes to my work.  I like this.  I love this.  I used to be envious of the detail oriented folk.  I’m pleased to count myself among them in some regard.  I think this is necessary for people who work as developers.  Your job is detail oriented.  “The computer will only do exactly what you tell it”, my dad used to say.  To a fault.  I take pride in the craftsmanship of my work.  I always have.  2012 will be no different.

Making a plan – 2012 was one of my first forays in developing a real, honest-to-god software engineering plan.  I thought I’d nailed it.  Turns out I was about 75% of the way there (the gaps really showed up during development).  Regardless the parts that were planned well went off without much of a hitch and came in under-time against the project plan.  This is something I want to expand upon in 2012.  You’d be amazed what you can figure out ahead of time before you write one line of code.  Every 15 minute interval spent mulling over a problem before you start will save probably hours in development when the same problem inevitably comes up.  As mine and Mindgrub’s projects grow ever larger this will become increasingly more important.

Things I Suck At (and want to improve upon):

Automating the mundane – Shame on me as a developer, but there’s a lot of things for which I don’t have automation in place.  Simple stuff.  Dumb stuff.  Stupid stuff I still do manually like pushing a build to test flight or setting up a UITableView.  I think there’s a couple reasons I haven’t delved into this more.

1. Time is not always on my side, in that the pressure to just get the client work out the door is high to where I don’t think I’ll have time to find/write a script or an automator action or make an XCode template.  Usually by the time I notice that I should have automated it I’m already 75% done with the task.
2. Fear of the tools – What if automator jacks the upload to testflight?  What if the deployment script fails?  Dumb fear.  Paranoia.  I need to get over this one.
3. Lack of knowledge – In no way can I count myself as a bash guru.  I couldn’t write a Perl script to save my life.  Granted automator is a huge help here.  In some ways you can put this under “fear of the tools”

Not sure if there’s an easy solution here.  First would be to learn the tools: automator, a little bash.  I think I’ll leave Perl until 2013.  I also have a mind to make a slew of Xcode templates to use with my development team as it always seems there’s a bunch of things we have to add to any UIViewController.  Third for me is to try out tools and scripts that get posted to various places like HackerNews and Twitter, see what other folks are doing and try to adopt them into my and my team’s workflow.

Branch Out – I’ve been working with iOS almost exclusively in 2011.  It’s great and I love it but I’ve been feeling the need to branch out lately.  I believe it’s important especially in the current job market to be versatile as a developer.  Learning new programming languages will make you better at whichever language you use everyday.  Learning new frameworks will make you think differently about the frameworks you already use.  And if you don’t learn anything new, technology will pass you by.  For 2012 I want to get a release of a cocoa app.  While it’s still objective-c, there’s a lot of nuanced differences between the two.  I’ve got a couple of ideas rattling around, just gotta get up and get going on one.

Making every moment count – I feel like I need a little more get up and go in my life.  Not that I’m lazy.  Far from it.  But I want to make more of my free time that I have.  That doesn’t necessarily mean more work or side projects but more about getting the feeling that I’m getting most out of every minute.  This year I want to work on paring down distractions and focus more on important things.

So, maybe this process was a little more cathartic than I thought looking at the tone of the post from the top to the bottom.  At any rate I want to wish those few regular readers and folks from iDevBlogADay a great new year.  Happy Coding!

Check out the original post from David Hamrick here.

This presented numerous challenges as 1.0 got out the door and we started work on the first set of updates. Aside from our internal testing team, Wheelhouse has a team of their own. They want to be able to show the app store version off while still testing our updated builds to them. To keep the development and live builds totally separate we decided the best course was to create separate target for the dev version that they would use for their testing. To iPad, these would look like entirely different apps, so we’d never run the chance of damaging the live data during testing. In the rest of this post I’ll detail how to create a separate development target for testing purposes some of the added benefits you’ll get out of doing this.

Step 1 – Create a new app id and provisioning profile.

In the provisioning portal, create a new app id and ad hoc provisioning portal. I assume that everyone reading knows how to do this. For Salesbag we created a com.wheelhouse.salesbagDev app id.

Step 2 – Create a duplicate target

Duplicating the target is simple. Simply right click the build target in the project details and select “duplicate”.

Step 3 – Create a duplicate info plist

In order to use the new app id, we’ll need to duplicate and modify the info.plist to include the new app id.

You can also change other build settings like the bundle display name to make your dev version distinguishable from the production app.

Step 4 – Modify the target build settings to include the new plist

The new target must know to use the new the info.plist. Open the build settings for the target, search for info, and change the name of the info.plist.

Step 5 – Create a new scheme to build the new target

The last thing to do is to create a new scheme to build the new target. Under the schemes drop down at the top of the Xcode window and select manage schemes to bring up the scheme manager. You select duplicate from the actions (gear) menu at the bottom of the window.

Once your new scheme is created, click edit to open the new scheme. All you need to do next is replace the old target with your dev target and hit ok (this is in the “build” section).

You should now see the new scheme in the schemes drop down.

BONUS – Setup target specific code

In the dev version of salesbag we added some features for testers to be able to wipe out old data from previous iterations of Salesbag (in our case local eventkit calendars from development on the earlier versions). With your new target you can easily create custom preprocessor directives to dynamically include code in dev versions that you give to your testers.

Step 1 – Create a new preprocessor macro

In the build settings for the dev target search for preprocessor and double click the section called Preprocessor Macros under the target. Add a new parameter in here. We chose “DEV_VERSION=1″.

Step 2 – Use your new macro in code

To include code specifically for your dev version, simply use the macro you created in step 1:

#if DEV_VERSION
NSLog(@"cool testing feature");
#endif

That’s it!

Hopefully the process above will help some other developers in their longer term projects.  Also be sure to drop a comment if you have any feedback.  Happy coding!

Greg Wilson – What We Actually Know About Software Development, and Why We Believe It’s True from CUSEC on Vimeo.

static void *p = &p;

[someObj addObserver:self forKeyPath:@"aPath" options:NSKeyValueObservingOptionNew context:p];

// ...

- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context
{
    if (context == p)
    {
        // do stuff
    }
    else
    {
        [super observeValueForKeyPath:keyPath ofObject:object change:change context:context];
    }
}

Seems like a lot of magic at first, but by specifying a context every time and using one that’s not only unique to your object but also to the file containing your subclass you can ensure that the message sent to you is actually for you and you avoid potentially stepping on the toes of your super class. Neat stuff! It’s also worth noting that checking the context pointer first is a super-fast way to see if you need to care about the observation method.

Side note: if you’re not subscribed to Mike Ash’s Friday Q&A blog (link above), you definitely should. I learn something new there every week.

Language:

The language for working with Cappuccino is objective-j.  Objective-j is to javascript what objective-c is to c in that you get object orientedness without it mucking up the foundations of the base language.  According to its creators, this is exactly why they chose the smalltalk style syntax of objective-c over other constructs when deciding how to craft their language.

Coming from iOS development, picking up the syntax was a breeze.  Having had a background with javascript didn’t hurt either, but I haven’t yet run across any particular problem where I’ve had to lean on that knowledge to move forward.  Some things are different though and might trip up would be adopters:

1. No .h files – Javascript has no notion of separate compilation (or compilation at all for that matter).  As a result there is no .h file, only your .j which contains your @implementation block.  The @implementation block serves as both the @interface and @implementation from objective-c containing instance variables and full method implementations.
2. No properties – I know there’s some haters of the @property directive in the community.  To those folks, I don’t know how you ever lived without dot syntax, as it’s the one thing I miss from objective-c.  Typing things like [[[self view] subviews] objectAtIndex:0] and the like gets a bit tedious after a while.  That said, you can still have objective-j generate accessors for you with the @accessors directive.    Why the lack of dot syntax?  For the same reason objective-j was chosen: not breaking javascript.  Javascript is object oriented in its own way, so supplanting its existing dot syntax would break the language.
3. Variable naming – iVars in the interface are still named with their type, but without the ‘*’ or pointer to it.  Local variables cannot be typed (probably what still trips me up the most).  The keyword for a local variable is “var” from javascript syntax.  All this really means is that you need to be extra careful naming variables so you know what they are later in code.

Frameworks:

I can’t help but be impressed with how thorough the Cappuccino folks have been in duplicating the Cocoa frameworks.  Virtually all the foundation classes you might need are there as well as much of the Cocoa UI components.  This is probably the greatest benefit to using Cappuccino is the sheer number of controls available out of the box without having to get into the nitty gritty of HTML and CSS manipulation required to get things like scrolling table view and outline views.  Cappuccino keeps the API to very close to their Cocoa counterparts so using them is easy if you’re already familiar.

Installing:

To get started learning Cappuccino provides a starter package that let’s you play around with the frameworks.  For a full fledged installation, the simplest thing is to build the frameworks from source.  There’s an installation script that will download the sources and compile them.  The included jake tool (think make, but for javascript) makes it very simple to build all the frameworks you need and deploy your application later.  All this work is done on the command line, so you’ll want to be comfortable in terminal before you dive in.

Development Tools:

This is probably where Cappuccino is lacking the most at the moment.  There is an Xcode plugin but I’ve found it’s crashy and unreliable in Xcode 4.  So far the best set of tools I can find are TextMate and Xcode’s Interface Builder with XCodeCapp which converts the xib files to cib (Cappuccino interface files) on the fly.  Coda has support for objective-j though I haven’t tried it out yet.

Debugging has its own set of challenges as well.  It’s supposedly possible to set breakpoints in either firebug or safari’s web developer window, but I haven’t seen how to do that yet.  So far console.log has been my best friend for debugging my application.  Additionally, since there is no compiler you don’t get the benefit of compiler errors and warnings to help you along.

I’m hoping the state of the tools improves as Cappuccino chugs closer to 1.0.  I’d love to see a full blown Xcode plugin with code completion, debugging, and building and deployment.  That is a tall order of course, especially when Xcode itself sometimes feels more like a beta than a fully tested application.  280North, the team behind Cappuccino seemed to have something strong going with Atlas, a web based interface builder and IDE, but there hasn’t been any movement on that since they were bought out by Motorola a couple of years ago.

Results:

Tools aside, the amount you’re able to produce with very little code (especially if using interface builder) is pretty profound.  Having worked on web applications in the past it’s refreshing to be able to focus on the logic of the app rather than being worried about the ins and outs of HTML, CSS, and raw javascript.  Cappuccino seems to make intelligent decisions about how rendering a given view should be handled, whether with a div or HTML 5 canvas.  Having a proper abstraction for the DOM is invaluable in this regard and most of the default controls look great right out of the box.

Conclusion:

If nothing else it’s fantastic to be able to use my objective-c skill set and jump into developing a modern web application quickly using cappuccino.  It requires you to develop your own workflow; it’s not as integrated as iOS / Xcode is.  The tools, however, seem to be improving as the Cappuccino approaches 1.0.  In all, I left web development because I didn’t like having to deal with both the application logic and HTML/css drudgery simultaneously to get anything done.  Cappuccino solves that problem for me and has allowed to me to produce some promising stuff very quickly.

As a new platform, (good) documentation is pretty scant. Here’s a couple of links where you can learn more and get started.

Cappuccino Homepage
Github repo (don’t follow these install instructions, they didn’t really work for me).
THE tutorial that actually helped me get it installed.

Much of the install process requires you be at least pretty comfortable on the command line. Additionally you’ll want to create .bash_profile file in your home directory if you don’t already have one since there are a couple environment variables the installer will want to create. Overall the framework looks like it’s pretty simple to get rolling for someone like me who’s used Javascript in the past but has spent the past couple years in objective-c. Lot’s more to come!