A fellow YCer introduced me recently to BlocksKit (and A2DynamicDelegate), two libraries that rejigger the standard delegate pattern of lots of the normal framework classes into a block. For example, consider the difference between the framework-standard code to show a UIActionSheet:

And the same logic, with BlocksKit:

This feels sturdier, more compact, and more straightforward – especially considering my Ruby background. In integrating BlocksKit into my project, though, I started running into whispers about retain cycles – specifically, a situation in which a class has a strong reference to a block, which in turn has strong references to the local variables (often members of the class!) it might use or call.

After reading a bunch of different blog posts and StackOverflow answers discussing the same issue, I wanted to consolidate / quote a few of the most useful sources. In short, whenever using blocks (especially in ARC-enabled code, which handles most of the memory management for you), developers need to watch out for retain cycles and break them if necessary.

Blocks in Objective-C have one more very important difference from blocks in C in handling variables that reference objects. All local objects are automatically retained as they are referenced! If you reference an instance variable from a block declared in a method, this retains self, as you’re implicitly doing self->theIvar.

source: Programming with C Blocks. Click through for code snippets, examples, and a deeper discussion of Memory Management in blocks (section 4.2).

The __block qualifier allows a block to modify a captured variable:

id x;
__block id y;
void (^block)(void) = ^{
    x = [NSString string]; // error
    y = [NSString string]; // works
};

Without ARC, __block also has the side effect of not retaining its contents when it’s captured by a block. Blocks will automatically retain and release any object pointers they capture, but __block pointers are special-cased and act as a weak pointer. It’s become a common pattern to rely on this behavior by using __block to avoid retain cycles.

Under ARC, __block now retains its contents just like other captured object pointers. Code that uses __block to avoid retain cycles won’t work anymore. Instead, use __weak as described above.

source: Mike Ash on ARC – scroll down to the section on blocks.

In retrospect, I read a good number of these posts when I was first exploring iOS and ARC – I suppose it’s a testament to how much content is in some of these articles (or the complexity of changing ecosystems?) that I didn’t make all of the connections / pick up all of the tips that I should have.

You can use lifetime qualifiers to avoid strong reference cycles. For example, typically if you have a graph of objects arranged in a parent-child hierarchy and parents need to refer to their children and vice versa, then you make the parent-to-child relationship strong and the child-to-parent relationship weak. Other situations may be more subtle, particularly when they involve block objects.

In manual reference counting mode, __block id x; has the effect of not retaining x. In ARC mode, __block id x; defaults to retaining x (just like all other values). To get the manual reference counting mode behavior under ARC, you could use __unsafe_unretained __block id x;. As the name __unsafe_unretained implies, however, having a non-retained variable is dangerous (because it can dangle) and is therefore discouraged. Two better options are to either use __weak (if you don’t need to support iOS 4 or OS X v10.6), or set the __block value to nil to break the retain cycle.

source: Use Lifetime Qualifiers to Avoid Strong Reference Cycles – click through for code examples. Unsurprisingly, Apple’s own documentation is the most thorough – if only I’d found it first!

Specifically, I wanted to know how best to handle the case in which I called -dismissViewControllerAnimated:completion: when the user, say, clicked the “Done” button on the toolbar:

Thanks to the Apple docs, we have instead:

Time for a code audit – I hastily (aka giddily, aka excitedly) integrated BlocksKit yesterday without researching this too closely, but I know that I use blocks often elsewhere in my code, and it’s time to make sure everything’s correct before I push my latest set of commits.

After beginning a startup and doing very little between working and sleeping, I’ve finally (about six months in) reached a point where my schedule has stabilized a bit, and I’ve found a routine / set of incentives that I feel like I’ll be able to stick to for awhile – at least, I’ve followed it for the last seven weeks (one week longer than my last attempt) and am still going strong. I’m tired of having the phrase “disgustingly sedentary” float up in my mind when people ask me how I’ve been, and I’m looking forward to maintaining my newfound awesomeness. Below, the usual excuses I use to avoid working out, and how I’ve managed to skirt around them.

Typical Excuse #1: My schedule’s too fluid, and I can’t find time to exercise at the gym

My schedule is a bit eccentric, but once I discovered that I have a 24 Hour Fitness one block away from my office, I’ve found that I tend to come to a natural stopping point at around 1am each night. With a 24 hour gym, I can rarely find a reason to skip the gym before heading home. Plus points: I hate working out around other people, and there are rarely more than 3-4 other people at the gym between 1 and 4am (sometimes, I have the place all to myself!)

Typical Excuse #2: Cardio bores the pants off of me

My most successful stint at exercising regularly (summer of 2006) involved reading lots of Ayn Rand on a stationary bike, also late at night. I realized recently that, by bumping up the font size on my Kindle, I could easily read while running on a treadmill – and can now run for a previously unimaginably long time without noticing. (And then go for another 20-minute jog because I need to know what happens next!)

Typical Excuse #3: I know exercise is good for me, but man it’s such a time sink

When you’re running a startup, you work. A lot. And one of the things that I’ve lost (or have been unable to justify) as a result is my time to read for pleasure. By combining something that’s good for me and feels productive (cardio/gym) with something that makes me really happy and that I always want to do more of (reading for pleasure), I genuinely look forward to going to the gym and will often spend way more time exercising than I planned.

I was surprised at first with how much happier I’ve been as a result. I’m not sure if it’s actually the endorphins, or the “badass”-ness I feel from coming back to the office at 3am and sitting down for another hour or two of work (I mentioned my schedule was nutty), or finally being able to move books off my reading queue, but I’ve noticed a definite uptick in my mood and body image as a result. I’ve run something like 75 miles over the last six weeks (I make it to the gym an average of three times a week), and I’m looking forward to my numbers (I love you, Runkeeper!) going ever upward.

Every once in awhile, though, you might run into a situation for which the file:// protocol is ill-suited — specifically, if/when you run into an error like this: Cross origin requests are only supported for HTTP.

In other words, I ran into this really cool snippet:


$ cd /home/somedir
$ python -m SimpleHTTPServer


… awhile ago, and needed it a couple of minutes ago, and could barely remember it (hat tip to LinuxJournal for being easily Googleable). So I’m posting it here for posterity, and to augment my clearly failing memory.

Running that command will make, by default, the index.html in /home/somedir accessible at http://localhost:8000.

Or you can pass in the preferred port (python -m SimpleHTTPServer 8080) into the command line instead.

Thumbs up. Onward!

* Also useful: tying this sort of thing to something like localtunnel, to brainlessly / painlessly broadcast something on your local machine to the interwebs.

This post: fields_for with a serialized has_many relationship

I’ve used plenty of nested forms recently, but always (and now, in retrospect, not always necessarily) with ActiveRecord-based has_many relationships.

Today, I was adding a new attribute to an existing model, and wanted to add some attributes that would simply be attached to the model via a serialized field, rather than any sort of join (similar to the setup in this post).

I wanted to store a set of BillItems on each User, but since they would be fairly isolated from anything else in the database and be tied strictly to each User, I decided to just attach it to each User.

And because each User could theoretically have many BillItems, we’d want to ensure :bill_items was serialized as an Array.

I was finding, though, frustratingly, that the following form was being generated incorrectly – only a single bill_item field was represented in the form, and even when sanity checking by iterating over bill_item records manually, the field markup was missing the indices necessary for the form to recognize each field as a separate form parameter. So when the template looked like this:

The output looked (sadly) like this:

What the docs missed out on saying (under One-to-many) is that: rather than the projects_attributes= attributes writer method just being 1) recommended, 2) worth considering, and 3) available to be replaced by a accepts_nested_attributes_for if :projects were already an association on the model, it’s actually required for fields_for to correctly nest the fields.

And, of course, :bill_items not being a proper association, I wasn’t able to use the standard accepts_nested_attributes_for helper and ran afoul of this. With the correct *_attributes method defined, the form finally displays perfectly, so that bill_items are passed through correctly, as an Array:

Lesson learned, and change committed.

I / we / anyone (me) serious about improving as a programmer needs to dive in and really understand how things are put together. With that goal in mind, I’ve got a couple resolutions to declare:

1. I’m going to be more diligent about reading Rails code – I’ve done my fair share of poking, but I’m going to be much more stringent about reading documentation and code to really understand what’s going on.

2. I’m going to stop lurking / being an isolationist on Github and be more proactive about submitting patches, which I’ve been improving at over the last few months (especially for documentation, as I encounter things that end up being “duh” moments).

First up, redirect_to:

redirect_to is an awfully common method in controllers, and most people use it without thinking or looking too deeply at the internals. Cory tried to be a little more correct with one particular redirect_to, though, by adding :status => :unauthorized, and we found that the controller, in fact, no longer redirected the user. Instead, it displayed a “You are being redirected.” message and simply sat there.

Digging into the source shows us that redirect_to works by returning a HTTP response status of 302 to the browser (of course) – which then knows to look up response’s location and fetch that instead.

So when a 4xx response code is passed in, it overrides the default 3xx redirect status code and the browser simply displays the response_body and (seemingly) chokes. I’ve committed a change on the docrails Github project to clarify this point for anyone staring at the documentation in the future.

More up in a second blog post!

The favorite use I found for it so far is my Game of Thrones task – I love The Atlantic‘s coverage but really couldn’t care less about their other Entertainment articles, and they don’t have category-specific RSS feeds. This way, I get things delivered straight to my inbox!

And, in the interest of keeping my inbox relevant, I have higher-frequency / immediate-action-required tasks tied to my GTalk, which makes sure that I can react quickly.

(I’ve noticed that more of my tasks are tied around consumption/notification rather than production. The other blog posts I’ve linked to above seem to tend toward duplicating/publishing content elsewhere, which is an interesting difference.)

The site is really nicely designed and is genuinely fun to use. Get on the invite list and start creating – I’m excited to see what other fun uses I find.

Note: Hah, if you look closely, my Rent reminder, the second task from the bottom has never fired. Clearly, the service is still in beta. I still use Resnooze for scheduled email reminders about things, but am looking forward to ifttt stabilizing enough for me to switch!

This assumes you have some amazon_s3.yml file in your config with your AWS credentials and your Heroku credentials set in your environment variables.

This currently works under Rails 3.06 and Heroku gem version 2.1.3.

While trying to get this all to work, I borrowed generously from http://librarymixer.posterous.com/40960547 (seemed to work under the Heroku gem version 1.19.1) and http://metaskills.net/2011/01/03/automating-heroku-pg-backups/, with lots of tweaking necessary to account for gem updates.

Ran into some issues with “clear: both” in one column affecting divs in the other, pretty early on. Remember:

When you clear a float you clear all floats above it in the html. That includes any floated columns you may have. (via pmob.co.uk)

Unless: The clear property is applied to an element inside a float itself. In these cases the clear will be restricted to the current parent float.

Or: The parent element has overflow defined other than visible (e.g. overflow:auto or overflow:scroll). In these cases the clear will also be contained within that parent.

Another issue – had a div full of tiles, each “float: left”ed to create a grid of tiles. I wanted an overlay to extend out of the bottom of each tile on mouse over, and kept seeing the overlay covered up by the tile in the next row.

If you have 2 elements A & B and element A has a z-index of 2 and B has a z-index of 102 then whenever the elements overlap, B will always be in front of A.

However, if you nest another element C inside element A (which has a z-index of 2) and give element C a z-index of say 500, you may think that element C will remain on top. This is not the case – element B will remain on top because it has a higher z-index than element A. Element C is a child of element A and all its children can never be higher than the status of its parent.

Everything inside element A will always be behind element B as they are placed on the z-axis as a group. (You can of course adjust the order of elements within element A in relation to each other.) (via webmasterworld.com, circa 2003 – wow)

And to think, when I was looking for a job at a 2-5 person startup, I explicitly asked for no frontend work. Le sigh.

It turned out to be a great decision to talk to my team members individually – people were able to be more candid about their opinions, and were also able to give advice more freely, knowing the context in which it was being given. What was also interesting was the range of opinions – some people were stoked for me and were privately envious; some were a little more disappointed by my impatience. After the first couple of conversations, I realized I’d be letting a lot of wisdom vanish into the ether (my brain) if I didn’t write them down. So, below are some of the most memorable sound bytes from my conversations:

“In the end, a startup is a business – and businesses succeed based on connections. You can write impeccable code, do lots of user testing, but in the end if you can’t sell your ideas, you can’t sell your product, then you’re sunk.”

“User testing is sort of a startup myth – [people think that if] you have a great idea, do lots of user testing, code it up, and you’ll be successful.” (not sure what the context of that was)

“The difference, I suppose, between doing something new outside Google is that if you don’t make it, you die. Here, if you don’t make it… you can come back tomorrow and complain about it.”

“You’ll have constraints anywhere. You say that within Google, there are frustrating constraints in the building of the product, but you also have all the building blocks that help you get past other constraints further on. Go talk to investors and see what sorts of constraints THEY place on you”

“[In the future], you should make an effort early on to be transparent with your managers if you’re dissatisfied… to see what they can do about it.” (In my defense, I had. There was little anyone on my team could have done.)

“We’ve sort of had our souls sucked out here, haven’t we?”

For a couple of the later conversations, when people asked me where I was headed next, I tried to answer, “Facebook.” I couldn’t last a second before bursting out laughing. One big reason I’m leaving is probably best described at the bottom of this article (headline: “One in Five Facebook Employees Has No Imagination Whatsoever”): “[A startup is] a different kind of fun, feeling like the whole place would keel over if you didn’t do your part.”

While it’s a little terrifying and definitely a bummer that I’ll no longer work every day with that particular extraordinarily talented team, I’m eagerly looking forward to the lessons I’ll learn on my own (trying to prevent everything from keeling over!)

Follow me there for now, and I’ll be back to update this blog soon enough.