[someObject doSome:stuff for:reasons];

Ever wondered what’s really happening inside those square brackets? Polymorphism!

Polly want a morphism

Great. Fancy words. Thank you! As every Introduction to Object-Oriented Programming book tells you, polymorphism comes from the Greek words “poly”, meaning “many”, and “morph”, meaning shapes. We have a bunch of shapes (a pile of assorted Lego bricks). Or, it can mean we have something that can take on many shapes (a Lego brick that can change from a 2×2 into a 1×4.). These days it pretty much means “I’m sending a message to an object, and the behavior caused by that message will happen. But I don’t really create precisely what it does.” You can ask an NSArray its count. You can ask an NSSet its count. The implementation of -count can be radically different between the two, but you get each one’s count by sending the same message. What problem is it solving, though? Why have polymorphism? Back in the Old Days of contrived programming straw-men (straw-persons?), you might be implementing a graphical toolkit, and you might have code like this which draws all the views in a window:

void DrawViews (View *views[], int count) {

    for (int i = 0; i < count; i++) {
        View *view = views[i];

        switch (view->kind) {
          case kButtonView:
            printf ("Drawing a button!\n");
            ButtonDraw (view);
            break;

          case kSliderView:
            printf ("Drawing a slider!\n");
            SliderDraw (view);
            break;

          case kPonyView:
            printf ("OMG PONIES!\n");
            PonyDraw (view);
            break;
        }
    }

} // DrawViews

Where views is an array of pointers to Views, which a “kind” flag to tell what kind of view is what:

typedef struct View {
    ViewKind kind;
    Rect   bounds;
} View;

The Kind is just an enum:

typedef enum {
    kButtonView,
    kSliderView,
    kPonyView
} ViewKind;

It’s pretty readable. You could ship this and not feel sad. The problem comes when you need to update the software, say by adding an Image View. You’d need to touch the ViewKind enum, add an ImageDraw function (which isn’t too bad), and also add a new case to DrawViews. If you had other code (hit-test view) that used views, you’d need to update that code as well. That’s actually bad. Would anyone actually design code like this? Not really. But it does highlight the Open/Closed principle (invented by Bertrand Meyer, and later evangelized by Robert C. Martin). Robust code should be open to extension but closed to modification. It’d be nice to write DrawViews once in such a way where we could add new kinds of views (open) without doing violence to the code that makes the views draw (closed). Something like this pseudocode:

void DrawViews (View *views, int count) {
    for (int i = 0; i < count; i++) {
        View *view = views[i];
        YoViewDrawYourself (view);
    }
} // DrawViews

If Only We Had that YoViewDrawYourself, that no matter what view is passed in, it could figure out what the code behind the view is. Why is that good? Bugs tend to congregate where code changes happen. Got a weird bug? Oftentimes the most recent code change either introduced it or exposed it. Touching a central loop like DrawViews every time we add a new kind of view is courting disaster. Maybe your wife’s brother’s second cousin who “Knows how to program those phone things” isn’t the world’s greatest software enginerd. Do you want him messing with one of the most-called routines in your toolkit?

Indirection To The Rescue

A truism in the programming biz is “any problem can be solved by adding a layer of indirection.” Of course, this doesn’t mean that adding a layer of indirection is the only solution, or the best solution, but a lot of times it’s true. Especially in a case like this: rather than having DrawViews call functions directly, we add a bit of indirection. Instead of using the function name, bounce off a function pointer. Where would be a good place for that function pointer? Put it in with the view. Let’s make the views a little more interesting. They can be drawn, hit-tested, and described. Here’s some function pointers types that describe the different features:

typedef void (*DrawCallback) (View *view);
typedef bool (*HitTestCallback) (View *view, Point mouseClick);
typedef char * (*DebugDescriptionCallback) (View *view);

C function pointer syntax is kind of annoying. The name of the pointer type is in bold here. The the return type is to the left, and the stuff on the right are the arguments to the function. Thus, DrawCallback is a pointer to a function that takes a View pointer, and returns nothing. HitTestCallback takes a View and a Point, and returns true or false if the mouse click is inside or outside of the view. Actually using function pointers is pretty easy. Once you have them typedef’d, you can assign them. Here’s a function that corresponds to the DrawCallback signature:

static void ButtonDraw (View *view) {
    printf ("Drawing a button!\n");
}

You can have a variable that points to the function:

DrawCallback drawer = ButtonDraw;

Notice ButtonDraw doesn’t have any parens after it here. A paren-less function means “give me the address of the function, where the object code lives in memory, but don’t call it.” You jump through the function pointer by adding arguments (if there are any) in parentheses:

drawer (someView);

This will call ButtonDraw, passing it someView. It is effectively identical to calling ButtonDraw directly except you’re bouncing off of a variable—adding that little bit of indirection.

The Vtables Have Turned

So, back to view drawing. How can you use these function pointer types to your advantage? If you can put a table of function pointers at a well-known location in a View, DrawViews can find each view’s individual DrawCallback and call it. A common term for such a list of function pointers is a “virtual method table”, or vtable for short. Here’s the vtable for Views:

typedef struct ViewVTable {
    DrawCallback             draw;
    HitTestCallback          hitTest;
    DebugDescriptionCallback description;
} ViewVTable;

It’s just a struct with three function pointers. Buttons will have draw, hitTest, and description functions:

static void ButtonDraw (View *view) {
    printf ("Drawing a button!\n");
}

static bool ButtonHitTest (View *view, Point point) {
    printf ("Hit testing a button!\n");
    return false;
}

static char * ButtonDebugDescription (View *view) {
    static char s_unsafeBuffer[1024];
    snprintf (s_unsafeBuffer, sizeof(s_unsafeBuffer), "Button at %p", view);
    return s_unsafeBuffer;
}

And Slider will have a similar set of functions. Here’s the draw:

static void SliderDraw (View *view) {
    printf ("Drawing a slider!\n");
}

Rather than having a view type constant, replace it with the vtable:

typedef struct View {
    ViewVTable vtable;
    Rect       bounds;
} View;

Here’s what the object looks like in memory once everything is populated.

(Side note—the function pointers are duplicated in each View. For realsies, you’d construct a table once in memory, and have Views point to that table.) Setting up the button is pretty easy:

View button;
    button.vtable.draw = ButtonDraw;
    button.vtable.hitTest = ButtonHitTest;
    button.vtable.description = ButtonDebugDescription;
    button.bounds = (Rect) { 0.0, 0.0, 100.0, 200.0 };

Just assign the functions-that-do-stuff to the corresponding function pointers.

Draw Them Views

So, that’s a lot of work and kind of weird indirection. What does it buy us? Here’s an updated DrawViews:

void DrawViews (View *views[], int count) {
    for (int i = 0; i < count; i++) {
        View *view = views[i];
        printf ("drawing %s\n",
                view->vtable.description(view));
        view->vtable.draw (view);
    }
} // DrawViews

It takes an array of View pointers and a count, and then chugs through the views, fishing out the description and draw function pointers and jumping through them. Running our button through this function yields:

View *views[] = { &button };
    DrawViews (views, 1);

    drawing Button at 0x7fff6ad6e720
    Drawing a button!

So, does this version of DrawViews adhere to the Open/Closed principle? Let’s check. First, openness—how do you extend it with other view types? Add a slider. First, some functions to do the slidery stuff:

static void SliderDraw (View *view) {
    printf ("Drawing a slider!\n");
}

static bool SliderHitTest (View *view, Point point) {
    printf ("Hit testing a slider!\n");
    return false;
}

static char * SliderDebugDescription (View *view) {
    static char s_unsafeBuffer[1024];
    snprintf (s_unsafeBuffer, sizeof(s_unsafeBuffer), "Slider at %p", view);
    return s_unsafeBuffer;
}

Populate a View with these function pointers:

View slider;
    slider.vtable.draw = SliderDraw;
    slider.vtable.hitTest = SliderHitTest;
    slider.vtable.description = SliderDebugDescription;
    button.bounds = (Rect) { 150.0, 77.0, 300.0, 32.0 };

Call DrawViews:

View *views[] = { &button, &slider };
    DrawViews (views, 2);

And get this output:

drawing Button at 0x7fff6ad6e720
Drawing a button!
drawing Slider at 0x7fff6ad6e6f8
Drawing a slider!

So, we’ve added a new View type, so DrawViews is open to extension. Now for closed-ness. You added a slider, but didn’t have to touch DrawViews. That means it’s closed to modification. Looks like a Win. In case you didn’t notice, View can be thought of as a class, with draw, hitTest, and description being methods of that class. An individual View struct floating around memory is an instance of that class.

So, What about Objective-C?

This model, using vtables, is similar to what C++ does, as well as any number of do-your-own-OOP toolkits written in straight C. It’s very fast. Just pointer+offset to get a function pointer (in this case), or pointer+offset to get the vtable, and then another pointer+offset to get the actual function (when you have your vtable separate from the object). Still, that’s very fast. The tradeoff in speed is flexibility. The vtables are defined at compile time, whether manually like with the Views, or by the compiler. The offsets from the table pointers are baked-in at compile time too, making it problematic to upgrade libraries without requiring a recompile. (This is similar to the Fragile Base Class Problem.) Objective-C takes a different approach. Rather than just having a pile of function pointers, it has a dictionary of function pointers, stored under a name. That doesn’t sound like a big difference. Instead of invoking a view’s drawing code with someView.vtable.draw, you’d actually do someView.dictionary.GetFunctionPointerForName("draw");

No, Really. It’s Huge.

Turns out this is a massive difference in behavior. It adds another layer of indirection. Using a function pointer is one layer of indirection. Now the function pointer lookup is another layer of indirection. The big thing is it’s deferring the decision “where do I look for the function to draw with” from compile time (pointer + offset in a struct) to run time (grovel around in a dictionary). You trade some efficiency and safety (e.g. a C++ compiler will guarantee that any View will implement draw) for flexibility.

What is this added flexibility? It has two aspects. The first is you can ask an object questions. “Do you know how to draw?” or “Do you know how to hit test?” or “Can you be a Table View data source?”. This is a familiar operation if you’ve ever used -respondsToSelector. The second aspect is you can change stuff. “Hey Button, even though you didn’t know how to animate a badger running across the screen, here’s a function you should store under the name badgerRunningAcrossScreen.” This is familiar if you’ve ever used categories.

Why can’t we do that stuff using a vtable-style way of finding implementations? All of the interesting information about “Button’s DrawCallback is implemented by the static function ButtonDraw” is gone. If you recall the discussion on symbol visibility, static functions lose identity. There’s no way you can ask “is ButtonDraw used anywhere?” Similarly, assignments to the ViewVTable, and subsequent access, are all pointer+offset. The compiler doesn’t care any more that “DrawCallback” is the first entry in the table. Also, if you have two different “objects” with different vtable layouts—say draw is the first function pointer in View‘s vtable, and draw is the last function pointer in Cowboy‘s vtable, there’s no way of saying “hey, here’s an arbitrary vtable, give me the one that has a struct element named draw.”

Because Objective-C defers the “draw -> someFunction” mapping til runtime, it can expose all sorts of interesting information (a.k.a. metadata). Walk up to any Objective-C object and ask it “Hey do you -draw?”. The runtime will then look at the object, grab the pile of name-to-function maps, and see if draw is in there. If so, it’ll return YES. This is what allows us to have delegates and data sources that aren’t members of a particular subclass.

Languages like C++ require you to declare a particular class/template heritage for delegate objects so it can place the delegate function pointers at knowable places in the vtable, as well as guarantee that you can call those functions without worrying that they might not be implemented and crashing at runtime. One of the favorite never-ending programming discussions you’ll find is the suck/rule status of both of these approaches. The C++ way is faster and safer, but not as flexible. The Objective-C way is slower but flexible, but you can die unexpected horrible deaths at runtime. Objective-C is what it is, so I won’t get into this discussion.

Back Inside the Bracket

OK, after that fascinating (eye-roll) discussion of polymorphism strategies, how does that apply to this line of Objective-C code:

[someObject doSome:stuff for:reasons];

This says : look at someObject. Find its bag of name->function mappings. Look for doSome:for: in the bag. If found, call that code. (Another aside : There’s the whole additional world of inheritance which I haven’t touched on. Subclasses in vtable language just copy the superclass’s function pointers. There’s no penalty if you invoke a member function that’s implemented in a superclass. It’s still pointer + offset + jump. Objective-C, if it can’t find a method implementation, will look at the bag of name->function mappings of the superclass if it can’t find an implementation of the object that got sent a message.) How does this work under the hood? All Objective-C objects have a pointer in a well-known offset from the beginning of the object, called **isa**. This is a pointer to a “class object”, which you can think of as the bag of name->function mappings, a pointer to the superclass, and the metadata for the class. Want to send -doSome:for: to an object? Grab that object’s isa, look up -doSome:for: in the bag, and jump to that code.

objc_msgsend

Objective-C, in its first incarnations, was not a stand-alone compiler. It was a preprocessor that read your .m files and emitted C code, which would then get compiled by a C compiler. There was a runtime component that would take objects, pointer+offset them to get the isa pointer, and then look up function pointers. This preprocessor would turn bracketed calls:

[someObject doSome:stuff  for:reasons];

into calls to objc_msgSend:

objc_msgSend (someObject, @selector(doSome:for:), stuff, reasons);

objc_msgSend is where all the lookup work happens. Nowadays, the compiler doesn’t have to go through a C intermediary, instead it can emit objc_msgSend directly. Don’t believe me? You can always look at what the compiler is emitting:

int main (void) {
    @autoreleasepool {
        SomeObject *obj = [[SomeObject alloc] init];
        [obj doSome: @"stuff"  for: @"reasons"];
    }

    return 0;
} // main

Run it through a disassembler, and see that it’s the case:

You can see it putting obj (var_32) and the selector, along with @”stuff” (var_16) and @”reasons” (var_8) into place, and then finally calling objc_msgSend at the end. objc_msgSend is a brilliant piece of engineering, a real example of the power and utility of a little bit of hand-crafted assembly language in the right spot. Bill Bumgarner has a dissection of objc_msgSend as it existed in OS X 10.6, and since then it’s been optimized even more.

Tying it Together

That’s a lot of concepts and detail. What do we know now about this code now?

[someObject doSome:stuff  for:reasons];

• It gets boiled down to objc_msgSend
• objc_msgSend looks at someObject’s isa pointer to get the bag of selector->function mappings.
• If it finds a function, it’ll jump to it, otherwise it walks up the superclass chain.

And why is it going going through all of these gyrations to look up a function to call? Amongst lots of other things, it gives us that layer of abstraction that lets us write code that adheres to the Open/Closed principle. The caller of someObject doesn’t care what actually happens when it’s asked to do stuff, so long as it does it. By hiding the details behind this layer of abstraction, it allows the code sending this message to operate at a higher, more abstract level. We now have flexibility to have core code working on abstract entities to not worry about the details, allowing more flexible (if sometimes harder to follow) code and architectures. Up next, into the Objective-C runtime.

The post Inside the Bracket, part 1 – Open for business appeared first on Big Nerd Ranch Blog.

If you haven’t already, I can’t recommend enough reading Part 1 and Part 2 of Mark Dalrymple’s excellent two-part series about Objective-C’s literal/boxing/subscripting syntax. The code in those posts can be found on GitHub as a Gist.

Recap

When the literal syntax for creating dictionaries and arrays (and numbers) was announced, we as a developer community sang the praises of short, concise code. Then we were introduced to the subscripting syntax for the same, and many of us squealed with joy.

In case you’ve been living under a very large rock, I’m talking about our ability to read a value (and store one) in an NS(Mutable)Array using C-array-like syntax:

NSMutableArray *cultOfSkaro = [NSMutableArray arrayWithObjects:@"Sec",@"Caan",@"Thay",@"Jast",nil];
Dalek *leader = cultOfSkaro[0]; // The new hotness
cultOfScaro[0] = [NSNull null]; // We can also write values!

And don’t forget dictionaries!

NSMutableDictionary *theGuide = [NSMutableDictionary dictionary];
theGuide[@"Earth"] = @"Mostly harmless."; // ...mostly.

This “new” subscripting syntax is super-duper wonderful for sparing us lots of typing.

The problem, of course, is that it’s still new. Subscripting is only supported at runtime in iOS 6 and OS X 10.8, and while we can dream, most clients are not yet ready to drop support for iOS 5 and OS X 10.7.

What makes this feature not backward-compatible? Consider that:

cultOfScaro[0]

doesn’t equate to:

[cultOfScaro objectAtIndex:0]

as we’d expect. It instead equates to:

[cultOfScaro objectAtIndexedSubscript:0]

and that method doesn’t exist on NSArray in iOS 5 or OS X 10.7. We get the same raw deal with dictionaries, where

theGuide[@"Earth"] = @"Mostly harmless.";

is short for:

[theGuide setObject:@"Mostly harmless." forKeyedSubscript:@"Earth"];

So what do I do about it?

If you want to be able to use array and dictionary subscripting syntax with older versions of iOS and OS X, you’re in luck!

If you’re already familiar with Objective-C categories, you can just add the subscript-related methods to NS(Mutable)Array and NS(Mutable)Dictionary yourself!

For example, you could implement a cheap -objectAtIndexedSubscript: in a category on NSArray, like so:

- (id)objectAtIndexedSubscript:(NSInteger)index
{
    NSAssert(index >= 0, @"If you want negative indices, see Mark's posts linked above.");
    return [self objectAtIndex:index];
}

And there you have it. This implementation isn’t particularly robust, but it would get you back to level ground for being allowed to use subscripting syntax for reading values.

But wait, there’s more!

Unfortunately, there are two problems with this approach. One is more technical and one more practical.

The technical problem is that when a category is loaded, its methods are installed onto their appropriate classes, which is a good thing. If you implement a method in a category that was already present on the class, however, you replace that method. It’s generally poor form to replace a method whose implementation you didn’t write (or don’t fully understand). On devices running iOS 5, we’d be adding the method, but under iOS 6, we’d be replacing it. Harrumph.

The practical problem is that we’d be wasting our time to begin with! Apple has already provided us with a mechanism for utilizing subscripting syntax with older deployment targets.

You’re welcome to try it yourself. Take a new command line project, set its deployment target to OS X 10.7, and give it a basic test:

#import <Foundation/Foundation.h>

int main(int argc, const char * argv[])
{
    @autoreleasepool {
        NSArray *strings = @[@"E",@"G",@"B",@"D",@"F"];
        NSString *eString = strings[0];
        NSLog(@"%@",eString);
    }
    return 0;
}

You’ll find that this (tiny) app will build and run just fine, even on a Mac running OS X 10.7. It just works! Magic!

Welp, that was a short blog post. Cheers!

Not so fast, Bub.

Nerds tend not to like magic. Oh, we love to see a good trick. But things that we can’t explain really tend to get under our skin.

“Now, Mikey,” you might ask, “what in tarnation is going on that makes this work?”

First, I’d laugh at you for using a word like “tarnation”. Then, I’d tell you a short story about a small library called ARCLite.

When ARC was first introduced, our minds were blown. We could feel years being added to our lives at the thought of not having to write -retain and -release calls anymore. Even better, it turned out that ARC was backward-compatible! But how?

Apple had provided a build shim in the form of a static library called libarclite. Xcode 4.2 and later knew to link against this library anytime you built a project with a deployment target of iOS 4 or Mac OS X 10.6 with ARC enabled. This library provides ARC support for older systems.

It turns out that the-little-lib-that-could has also taken up the torch of providing older systems with support for container subscripting, while also solving our technical problem above: libarclite provides implementations of -objectAtIndexedSubscript: and friends to the container classes on iOS 5 without replacing the implementations provided by iOS 6.

libarclite does this by waiting until runtime to decide whether or not to add the method, by first finding out whether the method already exists.

Waiting until whattime?

If you’ve ever swizzled a method, go ahead and move on. If you haven’t, you’ll want to be seated for this bit. We’re going to talk about the Objective-C runtime library, and use it to understand a bit about how Apple’s pulling off the feat of only adding a category method when it doesn’t already exist.

The Objective-C runtime is the beating heart of a Cocoa application. It’s the low-level bit that puts the “Objective” in Objective-C by teaching C how to be object-oriented. The runtime library is also almost completely open source! We’re interested in one particular and integral header, however: runtime.h.

If you take a moment to browse this file, your imagination will start to run wild with possibilities. With these functions, you can define an entire class after your program has started running! There’s not really much practical use for such a thing (in our position), but when has that ever stopped us from trying? In fact, runtime class definition is how KVO works! But that could be a totally separate post.

There’s a specific function of interest to us in runtime.h:

OBJC_EXPORT BOOL class_addMethod(Class cls, SEL name, IMP imp, const char *types)

This function allows you to attach to a class an entirely new method that didn’t appear in the class’ header or implementation file. Of course, the method must be defined somewhere in your code, but this function allows you to attach it to a class that didn’t have it before.

The class_addMethod() function takes four parameters:

• a Class to which the method should be added, such as that returned by [NSString class]. Just as @"Hello" is an instance of type NSString*, NSString itself is of type Class.
• a selector that names the method—yes, the same sort of selector that you use with NSTimer
• a function pointer to the actual implementation of the method you wish to add, and
• a C character array describing the types of arguments the method accepts

The function returns a BOOL indicating the success or failure of the method addition. The function will fail and return NO if the target Class already has a method with the specified selector.

So what now?

How can we use class_addMethod() for ultimate science?

Let’s do it. Step zero? Import runtime.h so that we can use the functions declared there:

#import <objc/runtime.h>

First, we’ll go ahead and create our NSArray+Subscripting category, as we discussed at the beginning of the post:

@implementation NSArray (Subscripting)

- (void)bnr_objectAtIndexedSubscript:(NSInteger)index
{
    return [self objectAtIndex:index];
}

@end

You’ll notice immediately that I’ve changed the name of the subscripting method. Remember that if I’d named it:

- (void)objectAtIndexedSubscript:(NSInteger)index

then this method would be installed on NSArray as is, regardless of the OS version. We don’t want that, so we define the method using a fake/temporary name.

For this same reason, we should always namespace our category methods like this (prefixing the method name with an identifier of some sort, such as bnr_ above) so that we don’t accidentally replace methods that we didn’t even know existed.

The second step is to find a place to put our call to class_addMethod(). We want to implement or override a method that we know will execute very early in an application run.

When an application launches, one of the very first things that happens (even before main() is called!) is that each class that the application will use is loaded into the runtime. Each class is sent the +load message (and, because it’s special and doesn’t play by the usual rules, to each category on each class). This is a dangerous place for most types of activity, but it’s the perfect place to make changes to the runtime. That’s not to say that making runtime changes is always safe, mind you.

So, here’s our NSArray+Subscripting.m:

#import "NSArray+Subscripting.h"
#import <objc/runtime.h>

@implementation NSArray (Subscripting)

+ (void)load
{
    class_addMethod([NSArray class],
                @selector(objectAtIndexedSubscript:),
                method_getImplementation(bnr_objectAtIndexedSubscript:),
                method_getTypeEncoding(bnr_objectAtIndexedSubscript:)
                );
}

- (void)bnr_objectAtIndexedSubscript:(NSInteger)index
{
    return [self objectAtIndex:index];
}

@end

There are some fantastic bits at work here. First, class_addMethod() will fail if a method already exists with the passed-in selector. Second, arguments that initially looked incredibly daunting when we saw this function’s declaration (what on earth is an IMP or a type encoding?) are satisfied by calling other runtime functions from runtime.h! It feels like cheating!

I challenge you now to spend some time looking through the documentation for the various functions in runtime.h, and experimenting on your own.

Excellent, so this is all I need to get subscripting in iOS 5?

Not so fast. Remember, Apple is already doing this (or something like it) for you with libarclite! We’ve meandered down the runtime’s rabbit-hole as an exercise in pulling away the magic curtains, as it were.

There are certainly plenty of runtime hacks at varying levels of evil and danger that you may find useful in your own application, but this one’s already been done for you.

If you’re interested in learning more about the Objective-C runtime and its dark secrets, sound off in the comments.

Also, check out these excellent resources: *

• Mike Ash’s Friday Q&A (particularly his article on method swizzling)
• Colin Wheeler’s excellent and deep treatise on the runtime

The post Illuminating ARCLite appeared first on Big Nerd Ranch Blog.

OK, maybe they don’t, which is probably why there was a big push at Google I/O this year for developers to optimize their apps for devices larger than phones. Google even announced a featured section of the Google Play Store for tablet-optimized apps. Of course, Android developers have powerful tools that can be used to create applications that gracefully scale to different screen sizes. Last week, Google added another tool to our arsenal: SlidingPaneLayout.

Sliding What?

You may have seen the new Hangouts application released last week. This app is designed around the SlidingPaneLayout, which is a new addition to the support library.

A SlidingPaneLayout consists of two panes: the master pane and the detail pane. In the Hangouts application, the master pane contains a list of ongoing hangouts and the detail pane contains the actual hangout conversation. Selecting an item in the master pane will update the detail pane.

The really cool thing about SlidingPaneLayout is that the rightmost pane, the detail pane, can be dragged horizontally to uncover the master pane below. On a screen that is large enough to display both panes, the user will see both simultaneously. On a small screen, the user will see a single pane at a time and can slide the detail pane to reveal the master pane.

I’m Sold, How Does It Work?

Good news! SlidingPaneLayout is incredibly easy to use. SlidingPaneLayout is a ViewGroup, so it is designed to contain child views. However, this particular ViewGroup is intended to have only two children. To make use of this Layout, simply add its tag to your layout XML file for an Activity:

<android.support.v4.widget.SlidingPaneLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent" >

    <textview android:layout_width="250dp"
        android:layout_height="match_parent"
        android:background="#CC00FF00"
        android:text="Pane 1" />

    <textview android:layout_width="400dp"
        android:layout_height="match_parent"
        android:layout_weight="1"
        android:background="#CC0000FF"
        android:text="Pane 2" />
</android.support.v4.widget.SlidingPaneLayout>

That’s it. You are now using SlidingPaneLayout and you have a tablet-optimized app!

There Must Be More

Of course, a real app would have something more complex than two TextViews in each of the panes. Fragments would be a great fit here.

A master Fragment and a detail Fragment could be used, and would encapsulate all of your app’s custom controller code into reusable classes. If requirements change and you decide to do things the old-fashioned way (without SlidingPaneLayout), you would have to change only the Activity that is hosting your Fragments, not the Fragments themselves.

The Catch

As you would expect, SlidingPaneLayout works just fine with Fragments. I highly recommend using a Fragment for each of the panes.

However, there is one problem. Options menus (the items that show up in the Action Bar or when hitting the menu hardware button on some devices) do not work correctly. Since the SlidingPaneLayout is just a ViewGroup, it is not in control of the options menu and the user will always see the menu items from both fragments, even when you’re looking at just a single pane.

In an ideal world, I would like to see the SlidingPaneLayout show only the options items that are available for the currently selected Fragment in the layout (of course, seeing menu items for both fragments is fine, if the user is on a device that is large enough to show both panes). Obviously, there are ways to implement this yourself, but it does require a little extra work. The Hangouts application is clearly doing that extra work to update the options menu and the rest of the Action Bar when panes become selected.

What’s The Verdict?

SlidingPaneLayout is not a natural fit for all applications, and it’s certainly not a replacement for the new Navigation Drawer paradigm. It is a handy Layout, though, especially when creating applications that work well on any size device. Of course, there are downsides, like the Fragment options menu problem from above. SlidingPaneLayout is also marked as experimental in the documentation, so its future is uncertain. Like ViewPager, though, this will cause a problem only if/when you decide to update to a new version of the support library.

I’m excited to see the Android team take components that they use internally and encourage developers to include them in their own apps. Components like these as well as those contributed by other Android developers allow us to make better Android apps with less work.

The post Exploring SlidingPaneLayout appeared first on Big Nerd Ranch Blog.

I was chatting with one of my Ranch cohorts the other day. He said, “Hey MarkD, how do I learn all those details? I feel like I’m kind of stuck in limbo land, just using tableviews and whatnot.” Talk about a daunting question. Especially coming from an engineer of considerable skill. “Uh, you just do stuff?” isn’t a good answer.

I’ve been programming professionally (that is, actually making a living at it) for 23 years now. That’s longer than some of my coworkers have been alive. That’s a scary thought. Get off my lawn. Over the years I’ve fallen into a style of learning and exploration that’s paid some pretty good dividends. Of course, everyone is different, but here’s how I would answer his question.

Read

Read a lot. Throw information at your brain. There are a lot of books and blogs out there, especially compared to the old days when all of the Mac programming books would fit on a single shelf in a small IKEA bookcase. My favorite book of the moment is Rob Napier and Mugunth Kumar’s iOS 6: Pushing The Limits. I also must pimp Advanced Mac OS X Programming : The Big Nerd Ranch Guide because it digs into some of the lower-level details of OS X, many of which apply to iOS too. Don’t forget Amit Singh’s massive OS X Internals book (The ebook version will make your Kindle heavier). Some parts are out of date, but it’s fascinating the kinds of details a real-live operating system kernel takes care of.

We live in a wealth of information online was well. In addition to this humble weblog, you should be reading Mike Ash’s NSBlog. I also regularly read NSHipster and fellow rancher Jeremy W. Sherman’s blog.

Don’t forget to read the official documentation. Browse the Cocoa / UIKit docs in Xcode. I have DocSets on my iPad so I can skim stuff while I’m waiting for something. Don’t limit yourself to the classes that you use all the time. Spend all your time in NSTableView? Give IOService a read. You’ll probably never use it, but maybe you’ll find some topic that’ll inspire further learning.

I try to read through the compiler and debugger docs on a regular basis. gdb is well documented. gdb is still relevant these days – lldb is still somewhat unreliable running on a device. The lldb website has some supporting documentation, so check its built-in help to learn all the available commands. Be sure to read all the things. If you see an esoteric feature, try to figure out why it exists.

The lowdown on the compiler can be found at http://clang.llvm.org. Don’t forget the header files too. There’s lots of useful information are buried in them.

I don’t remember everything. I don’t remember most anything these days. But I do retain shadows of “I think I read something like this before. Now where was it.” and a little cogitation reminds me “oh yeah, Jeremy blogged about his reimplementation of all of Cocoa in 12 lines of code, and he had a cool higher-order-messaging category that might turn out to be useful.”

Dissect

To learn how things work, I like to see how things work. Knowing who-calls-whom can be illuminating. “Who is creating this undo manager?” was the key to solving a program bug. Maybe seeing the notifications that fly around an app can help you discover what MPMusicPlayerController is doing when it moves from song to song in a playlist.

We have a lot of really powerful tools to peek into our programs and libraries. You probably won’t use every one of them every day. Some you might only use once a month or once a quarter, but they’re good to have in your utility belt.

The source: The source to clang and lldb are easily obtained, so you can download them and build them. Have a question about how something works in the language? Poke around the source and see if you can find it. You can also get a decent subset of the Core Foundation source (amongst a lot of other stuff) at http://www.opensource.apple.com. The really interesting parts are “xnu”- the kernel, “CF” – Core Foundation, and objc – the objective-C runtime. Also, dig through the Cocoa headers and find something you might not understand, like NSAssert. Then figure out what makes it work.

The debugger: You can place breakpoints on any visible symbol, whether it’s your own code where you have file and line information, or functions and methods inside of binary-only libraries. You can enter breakpoints directly in Xcode by adding a “symbolic breakpoint”. Here’s one I added that will break on a private method in UIApplication called _performMemoryWarning:

You can trigger a memory warning in the simulator and see that it gets handled:

Notification spying: Notifications are a common way of decoupling code. Something interesting happens and a notification gets posted. NSNotificationCenter and friends are so convenient that pretty much everything uses it. You can add a notification spy to print out all notifications that float by.

DTrace: I know folks wish I’d stop talking about DTrace. How did I find that _performMemoryWarning symbol? It’s obviously not in any of Apple’s documentation, with that leading underscore being the giant “this is Private API” hands-off flag. I DTraced a program in the simulator, triggered a memory warning, and saw what was happening. During Clash I wanted to answer some other questions too, like “where did UITouches get created and dispatched?” and “what actually hits the file system when loading a nib file?”. Thus was born a little utility script, spy.d (available at this gist).

spy.d is a simple script that traces Objective-C messages using the objc provider, ignoring messages on a list of common messages, and displaying full stack traces for methods on an “especially interesting” message list. I ran spy.d and triggered a memory warning in the simulator:

# ./spy.d  61271
...
UIApplication -didReceiveMemoryWarning
NSNotificationCenter +defaultCenter
NSNotificationCenter -postNotificationName:object:
...
UIImage(UIImageInternal) +_flushCache:
UIViewController +_traverseViewControllerHierarchyWithDelayedRelease:
UIViewController -didReceiveMemoryWarning
UIViewController -_traverseViewControllerHierarchyFromLevel:withBlock:
RMScheduleVC -didReceiveMemoryWarning

UIApplication gets the memory warning. It posts a notification. UIImage flushes its cache in response. Then UIViewController's class method walks the controller hierarchy and tells each one that it received a memory warning, and then it bubbles down to my code in RMScheduleVC.

class-dump: The Objective-C runtime is very rich in metadata. You can, at runtime, poke around classes and their methods and find all sorts of cool toys to play with. That information is actually stored in the application binary (and object files, and libraries), and can be extracted. Steve Nygard’s class-dump will extract this metadata and generate @interfaces for all the classes it finds. For example, from UIApplication:

...
- (void)_purgeSharedInstances;
- (void)setReceivesMemoryWarnings:(BOOL)arg1;
- (void)_receivedMemoryNotification;
- (void)didReceiveMemoryWarning;
- (void)_performMemoryWarning;
- (BOOL)_isHandlingMemoryWarning;
- (void)_processScriptEvent:(struct __GSEvent *)arg1;
- (void)_dumpScreenContents:(struct __GSEvent *)arg1;
- (void)_dumpUIHierarchy:(struct __GSEvent *)arg1;
- (void)setSystemVolumeHUDEnabled:(BOOL)arg1;
...

There’s all sorts of fun stuff going on. These are places you can put breakpoints and poke around the call stack. You can also dig into the implementation, too.

Hopper Disassembler: The Hopper Disassembler is a tool that reads object code and displays the corresponding assembly language. Here it is looking at UIKit, the method implementation of _performMemoryWarning on UIApplication:

?

What’s neat is Hopper can convert the assembly to pseudo code so you can better suss out the code flow.

It’s also a neat way to learn an assembly language by example. Be warned you’ll be looking at code generated by a compiler, so it might not make a lot of sense at times when things get optimized.

Instruments: Instruments isn’t just for finding performance problems. It can be used to find locations in all the program’s code, both the code you wrote and the code from libraries, that you can start attacking with other tools. Wondering how UISlider does its live tracking? Point Instruments at an app with a slider, move it around for 10 seconds, and then see what’s at the top of the call stack. Then you can start applying DTrace in the simulator, or disassembling, and see what’s going on.

Just a quick warning – be very careful how you apply information you learn from these tools. They’re great for debugging and figuring out how things work. Relying on implementation details and private API in the stuff you ship can lead to fragile software that breaks with major or minor OS releases. If you’re shipping software to paying customers, or customers are using your software for non-trivial things, you are a professional programmer. Be sure to act like one.

Experiment

Now that you have a fleet of tools, it’s time to learn stuff. I learn best by actually doing. Get dirty and make mistakes! Interested in learning UITableView in depth? Write a bunch of table view code. Browse the docs. Look at the header for API you might not have used before, and use it and see what happens. Read some blogs. Class-dump it and look for some intriguing private API and see if you can trigger it from the regular interface. DTrace it and see the flow of messages. Add the notification spy and see what the toolkit is trying to tell you. If something doesn’t work, apply your usual debugging techniques and figure out why it’s not working. See if you can re-implement it yourself.

I tend to play around in the world of code below UIKit / AppKit, so I write a lot of little programs that exercise some data structure or language feature. Steve Sparks, my partner in Clash Crime, has his Playgrounder, an Xcode project with tab views and navigation controllers where he can throw a new experiment in there at any time. Want to muck around with some UIScrollView violence? Toss in a new view controller, hook it up, and now you can play with it in the simulator or on a device. Keep it under source code control and you can have a record of all of your experiments.

Assimilate

You decided on something to learn. You’ve written a bunch of code. You’ve debugged. Maybe you’ve taken a lot of notes. Now it’s time to let it all digest. Sleep on it. Take a bike ride. Go take an hour-long shower. Let all the new stuff you’ve exposed yourself to settle into patterns. See if you can build abstractions from those patterns, and apply them to other classes. Much of software development these days can be mechanical – there’s a set of features that need to be implemented, and a usual set of classes you glue together.

This assimilation step is where the real fun starts happening as your brain starts building relationships. Many of the examples here came out of a simple question that came up while working on our Clash entry: “We want to trigger memory warnings in the app on-demand”, to help debug memory and caching problems. The investigation process went like this:

• We can trigger memory warnings in the simulator
• Use the notification spy to see if there’s notifications that fly by. Why yes there are. We can hook into that and respond to them.
• Posting the notification didn’t actually trigger stuff. Bummer. I wonder why.
• What methods are getting triggered? Use spy.d and see what’s happening. Oh look, _performMemoryWarning looks pretty interesting.
• Are there other memory warning methods I might look at? Pull out class-dump and see what’s there.
• Sending _performMemoryWarning to the current UIApplication instance seems to kick in all the memory warning machinery. Why didn’t posting the notification?
• Just for fun, fire up Hopper and see what it’s actually doing. Oh look, it has that view controller hierarchy and sqlite thing, which don’t get hit just by posting the memory notification.
• Add a memory warning trigger button to the debugging console, wrapped in an #if block to prevent it from getting released to the world.

Integration By Parts

And that’s pretty much my secret strategy to honing my nerdskills:

• Read – Throw a lot of facts at the brain. Some may stick. I find that kind of stuff fun to read, so it’s an enjoyable pastime.
• Dissect – Get comfortable with a wide range of tools, from high to low level, and don’t be afraid to use them. And don’t be afraid to use them in weird ways. DTrace can be a big hammer. But sometimes you can smash a bug into tiny little pieces with it. Use these tools to dig into software to see how it works. Promise you will use this knowledge for good, not evil.
• Experiment – Write code. Write a lot of code. Experiment. Play with all the new found toys. Tease out the patterns.
• Assimilate – Reflect. Lather, rinse, repeat. Then keep doing it for the next twenty years. Building deep skills is a long-term work in progress.

The post Leveling Up appeared first on Big Nerd Ranch Blog.

Well, yesterday morning my colleague Chris Stewart and I walked down to Google I/O and waited in line for the privilege of doing just that. No doubt you’ve seen a lot of talk about the many announcements they packed into this beast of a session. Thirty minutes into the Android portion, though, I was already leaning over to Chris and saying: “We’re going to have to write a blog post about this stuff.”

Oh, you didn’t see anything exciting? You weren’t looking with the right rose-colored shades on, then. As Android developers, we saw major movements in some fundamental problem areas within our ecosystem.

Doubling Down on Libraries

The first shift is more in what we conspicuously didn’t see yesterday: a new version of Android. And yet we got a bunch of new APIs! What’s up with that?

This is something I have been talking about more and more in my classes: these days, the version of Android you’re programming against matters very little. You can see this idea throughout our Android Programming Guide, too.

It was a slow process getting here, a process that started tentatively a couple of years back with the introduction of the support library, and continued with community acceptance of cross-version libraries like ActionBarSherlock. Slowly but surely, these libraries have become the focus of mainstream app development.

Well, now we have reached the point where Google actually prefers introducing new APIs outside of a minor version release. The new Maps API, the new Locations API (!), cross-platform single sign-on, games services, the new slider drawer in the support library—all of this, and no new version of Android. No doubt we’ll see more revisions of Android, but don’t be surprised if the exciting API and tools action happens elsewhere.

Nifty External Libraries

That has an interesting consequence: technically, third-party libraries are standing on the same ground as the latest hotness from Google itself. As a result, the Android ecosystem is shaping up to look more like the Ruby community than the iOS community, relying more on an array of third-party libraries than solely on code coming out of Mountain View. Even now, a baseline, best-practices Android app at square one includes a raft of third-party libraries like event buses and ABS.

The most interesting talk I saw yesterday was actually exactly that—a third-party library. Granted, it came from Google, but it is not part of the standard library. Volley is an asynchronous networking and caching library, meant to replace ad hoc solutions stitched together out of HttpClient, HttpURLConnection, AsyncTask, HandlerThread or others.

Can you write an app without a library like this? Yes, you can. Would you ever want to? Other unnamed platforms (ahem) include asynchronous magic like this as part of the core APIs. They’re not part of the core for us yet, but in our own practice we should treat them as close to fundamental.

So Long, Eclipse

I would not be surprised if the importance of third-party libraries motivated the most eye-catching bit of news we saw: Android Studio, the new IDE from the Android tools team.

Managing third-party libraries is not pleasant in Eclipse. Out of the box, there’s no declarative way of saying what your dependencies are and where to get them. Maven does this, but it does not integrate very well with Eclipse.

The headlines are calling this the “Android Studio IDE,” but don’t be fooled—this is more about moving away from Eclipse, and towards IntelliJ. IntelliJ handles maven better than Eclipse does right now, but it’s also free of the years of cruft Eclipse has accumulated.

It looks like this lack of cruft has allowed the Android team to move more quickly than they have in the past. So if Android Studio looks more like a dedicated Android IDE than ADT did, it will not be because the Android Tools team are suddenly more ambitious. It will be because they are able to get more done by extending IntelliJ than with Eclipse.

What Now?

So what do all these changes mean for you?

First, you should stay aware. So much development is happening outside of the core Android libraries that critical APIs are now coming from outside the core Android team and release cycle. So keep an eye on places like the Android Developers Blog, the Square blog, and #AndroidDev Weekly to find out about the latest and greatest goings on.

And what about Android Studio? Well, don’t jump just yet. As of today, everything in our Android Programming Guide is still the right way to go. Android Studio is 0.1, so it’s not stable enough for day-to-day development. If you want to go ahead and switch to IntelliJ, go ahead and switch to the current community edition with Android support, but don’t feel compelled to do so. Eclipse support hasn’t been discontinued.

As small as these developments seem to a user, they are very exciting to me as a developer. Developing Android is steadily growing into its own peculiarly pleasant experience. Maybe for our next edition of our guide, we’ll have to replace our cover photo with one of those self-balancing unicycles.

The post Google I/O: Lots Of Android Love appeared first on Big Nerd Ranch Blog.

There were balloons.

And there was coffee.

But mostly, what we found was a group of smart, talented women. Though the day is challenging, full of learning new concepts and trying new things, the workshop participants rose to the challenge and learned designing, prototyping and coding of their own web apps.

They also learned from the lightning talks given by members of the Ruby community, including one from Blithe Rocher, who attended our first Rails Girls workshop just last December and is now not only a coach, but also a Big Nerd Ranch intern.

We are grateful to be part of a community committed to helping others succeed. In addition to our volunteer speakers and coaches, we couldn’t have done it without our sponsors:

• The Phuse sponsored the installation party on Friday.
• BackboneRails.com treated our coaches to dinner.
• Engine Yard was our materials sponsor, covering the costs of printed items and our mugs.
• Rocket Whale provided Saturday’s breakfast.
• MailChimp sponsored lunch.
• Octane donated espresso beans to keep us caffeinated.
• Big Nerd Ranch not only hosted the event, but also sponsored the after-party.

Want to be a part of our next workshop? Follow @RailsGirlsATL on Twitter and keep an eye on the Rails Girls ATL website.

The post Rails Girls ATL: Building ideas appeared first on Big Nerd Ranch Blog.

The interview was admittedly nerve wracking, as most are, but it is rare that the CEO drops in to ask a question or two. Or that candidates are evaluated for culture fit as well as their credentials. But afterward, I found this reassuring. I knew that that being a Nerd was taken seriously, because so many people took an interest.

I got the job as a mobile UX designer, and ninety days of design, dignity and doughnuts have flown by.

Design

While I had done design before starting at Big Nerd Ranch, it was never like this. The design team at Big Nerd Ranch is small but growing, so there’s a ton of flexibility as to what projects we’re on and what we get to delve into. We’re surrounded by extremely sharp developers who aren’t afraid to share their knowledge in order to make projects better. It’s been incredibly satisfying to combine UX, UI and visual principles with an agile approach to give deep consideration to everything we touch. We get to shape what design at Big Nerd Ranch means and spread the word that we’re open for business.

Dignity

We get our hands on amazing projects with customers who understand what it takes to make great products. A bias toward action and experimentation means that we can contribute to whatever we’re interested in, without fear. In fact, I think that’s part of the genius of Big Nerd Ranch: the removal of distractions. That focus enables people to establish flow in their lives.

As soon as I was made part of the team, I was trusted with responsibility and given the tools and time to rise to the occasion. I’ve been treated like an adult. I can work wherever and whenever I want as long as I get it done, and this has freed me to figure out how I work best. It’s fostered more experimentation in my life, and it’s inspiring.

Doughnuts

Doughnuts are simple pleasures: single-serving snacks in chewy yeast or crumbly cake. A dreary, rain-soaked Friday morning in April is no special occasion, but a few of us found reason to drive down the street and bring back a dozen or so doughnuts. And sharing little unexpected pleasures has pervaded my experience here. I can think of no better way to explain all the touches that make working here genuinely great. This level of comfort is hard won by those who have worked and continue to work to make Big Nerd Ranch what it is. I can only say thank you and do my best to contribute.

Three months has flown by. I left a group of friends to join Big Nerd Ranch and found so many new ones. I have a faint idea of what the future holds, but I’m confident that whatever it is will be faced properly, and with a bit of icing. Hopefully strawberry.

The post Design, Dignity and Doughnuts: My First 3 Months at the Ranch appeared first on Big Nerd Ranch Blog.

It was a very tough call, but Raisin’ Elevens was the top team, with a project they named Krëndler. Team members Mark Dalrymple, Gregg Rothmeier and Steve Sparks took home the trophy and some pretty sweet prizes. They were followed by team Daedalus (Eric Jeffers, Darren Pottinger and Chris Stewart) and The Wynners (the prescient Brian Hardy, Zac Stewart and Paul Turner).

We knew you’d want the nitty-gritty from the top team, so we asked them a few questions.

NerdBlog: What did you build?
Raisin’ Elevens: We built a toolkit that developers can drop into their applications and invoke on demand to help explore their application as it is running. Kind of like do-it-yourself endoscopic surgery. It’s a generic framework upon which we built some specific tools:

• View hierarchy visualization
• Built-in console viewer
• Tap/screenshot recording and playback (You can see what the user is doing to your app, not only where they’re tapping and dragging, but how quickly—or slowly—they’re doing it.)
• Forced memory warnings
• App kill
• Cloud support: Data is sent to a web service for archiving, processing and analysis off the device. The device log, notifications and touch tracks are correlated, letting you see where real users are having difficulty with your app.

We had a lot of ideas for features, the end result of which is essentially a web-based remote debugger for developers.

NB: That’s really impressive! Where did the idea come from?
RE: Chris Aquino showed us a feature in Firefox that allows you to visualize HTML layers in 3D, which is a really cool developer tool. Steve of course wanted it in his own apps. A few weeks later, he was working on a client app that required view scaling and discovered the CATransform3D API. Immediately the visual hack jumped to mind.

He created a test project, morphed some views and knew he’d found his Clash project. He immediately turned to Mark, and we came up with the team name effortlessly and right away.

NB: We’ll bite. What’s the story behind the team name?
RE: As part of the ground rules, Aaron stipulated, “Your team will need an amusing or terrifying name.”

We’re not much for self-aggrandizement, feeling that actions speak louder than words ever can, so we wanted something beyond “CODE KRUSHERS.” We also like self-deprecation, so we were thinking something along the lines of “We are Team Adequate and we crash a lot.” Then Steve made the connection between the Unix signal for a segmentation violation (signal 11), which you can send to yourself by using the raise function. So Raisin’ Elevens is basically us crashing due to pointer errors. Also, eleven is a magic number thanks to Spinal Tap, so the team name was born.

In the course of making Krëndler, we raised a lot of elevens, and not all intentionally. In fact, our “terminate the program rather than background it” feature raises eleven:

NB: You’re two iOS developers and a Ruby developer. Why did you team up?
RE: Mark and Steve were giddy about having web-based recording and playback of touches in iOS, so they reached out to Gregg. He had great ideas and suggestions, as well as thoughts about how stuff on the iOS side could be transmitted to the Rails side. He had a JSON schema already sketched out before we wrote a single line of code, so we hit the ground running.

How did you overcome the challenges of being in different locations?
RE: We were aided by a few things. Working remotely is already such a core part of our workflow that we were used to using technology to bridge the distance. Before we started, we created a Google doc for our list of ideas and had our goals and expectations clearly laid out. We used Google hangouts for face-to-face meetings, and our Campfire room was the war room. Campfire maintains a transcript even when you’re not signed on, so we could leave questions for another who might be offline.

To celebrate major milestones, we sent images and screen recordings, like this morph of eClicker:

And most importantly, we trusted one another. This is a huge part of the work we already do at Big Nerd Ranch, but it was key for a hackathon like this. We each needed to be able to trust that the others would go off and do their thing, and come back with good, working code. We could make big changes and add features without micromanagement, because we trusted one another and knew each others’ expectations.

NB: What put you ahead of the other teams?
RE: We were ruthless. Got a feature to do and you’re not sure how long it’ll take? Do a 30-minute attempt and see how it goes. If it looks like it’ll take a long time, jettison it for something easier.

Being so focused meant a lot of sleep loss. We all wrote code until we dropped. Steve crashed at 3 a.m. on Thursday morning and slept four hours, worked until 1 a.m. on Friday and slept two hours, then caught a two-hour nap before the party. The others didn’t sleep much more.

With a few exceptions, we shot right through our technical challenges and wrote pretty bug-free code. And having a killer presentation didn’t hurt—Steve even channeled his inner Billy Mays a little.

So there you have it. A solid plan, deep expertise and a great presentation of your app will help you rise to the top at Clash of the Coders.

Want more coverage? TUAW reporter Erica Sadun joined us for the event and wrote a series of articles about her experience. For a retrospective of the first Clash of the Coders, check out Bill Phillips’ post on his big win with Chris Stewart.

Photos courtesy of our Birmingham office, Chris Kelly (ckdake.com) and our Netherlands office.

The post Clash of the Coders 2013: Winners Announced appeared first on Big Nerd Ranch Blog.

To keep doing what you love, you must maintain your own systems—not just the ones you write code for.

In order to concentrate, learn and remember (all of which are important for programmers), you need exercise and a healthy diet. In this talk from Joe Kutner, you’ll learn exercises that will make working at a computer more comfortable, as well as how to change your work habits and develop a plan to stay fit.

The post The Healthy Programmer appeared first on Big Nerd Ranch Blog.

What I found at Railsberry, which is advertised as the conference for “curious” Ruby on Rails developers, was far from formulaic and typical. It was one of the most unique, fun and well-organized conferences I’ve attended in my career as a developer.

A different kind of conference

So how did Railsberry show me a different kind of conference experience? First off, ask yourself this question: Have you ever been invited to attend a contemporary dance performance by the conference organizers? Odds are that you haven’t, unless you’ve attended Railsberry.

Have you been able to swing back and forth while watching a lightning talk? Odds are, again, that you’ll have to say no. But this is what the modus operandi is at Railsberry; in fact, upon arrival at the conference, you’re inundated with a different look and feel. The conference itself is an experiment, meaning that the organizers try different, new ideas and see if they work. They embody a curiosity towards everything that permeates the entire two-day, single-track event. I was actually initially greeted and welcomed by conference staff wearing laboratory coats! (Were they experimenting on me?) When a conference speaker wasn’t able to attend the conference, it was no big deal. The conference organizers simply opened the floor for more lightning talks.

Learning something new

Let’s not forget the reasons we attend conferences: to learn something new. And there was a slew of great talks by a variety of speakers from various professional positions. We listened to Gregg Pollack walk us through the current state of the online education business as it pertains to learning code. We were enlightened by Fred George’s talk on implementing Agile methodology for any development team. As a 40-year industry veteran, his insight into how a company “should” do Agile was eye-opening, to say the least. He even called out some of the practices that we currently use at Big Nerd Ranch (our ego is not damaged; indeed, we love learning from others as much as we love teaching). The most outstanding and thought-provoking presentation was Joseph Wilk‘s talk called “Creative Machines,” where he explored the ways that computers can produce music.

All in all, this event is a standout amongst the global collection of technical conferences a Ruby on Rails developer could attend. It was entertaining, thought-provoking and fun. I can’t recommend this conference more highly.

The post Railsberry: A Different Kind of Conference appeared first on Big Nerd Ranch Blog.