go bold

I’ve been neck-deep in Cocoa / iOS / mobile work lately, trying to inhale everything as quickly and thoroughly as possible. Each discovery of a new way of doing things is exciting – in exploring a new ecosystem, it’s been a blast being exposed to different design patterns, best practices, and libraries.

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.

I’ve never been good at exercising regularly, despite lots of reminders, from many different sources, in various formats, explaining just how necessary exercise is for your { mental well-being, life span, quality of life, focus, self-image }. The last period of time in which I exercised regularly involved several very regimented systems (From Couch to 5K, Hundred Push-ups, and Groupon-spurred bikram yoga) and lasted for a total of about six weeks. This was a year ago. Before that, the last time I got regular exercise was the summer of 2006, during which I was interning in another city, and living with people who had much better habits than I.

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.

Most of the time, loading HTML files from the filesystem (with the file://localhost/Users/... sort of path in your URL bar) works fine – remote files are pulled in, Javascript can usually be run, and things are peachy.

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.

Per my previous post, I’m trying to be better about recording “Duh” / “Aha” moments in my experiments with Rails to 1) improve my learning / general consumer-of-open-source-software habits, and 2) in hopes that I don’t make similar same silly mistakes again.

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’ve been working closely with our intern Cory, and have now been put in the situation of having to explain why Rails is doing X or not doing Y more in the last couple weeks than the whole of the last several months. (It’s also worthwhile saying that it’s incredibly nice having someone to bounce thoughts off of again – no more coding in vacuum.) After each time one or both of us gets tripped up on something, I’m reminded to store that bit of knowledge somewhere useful.

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!

I’ve been having a ton of fun lately playing with ifttt, a service that lets you easily glue together different web services you use / rely on every day. If you remember Yahoo Pipes (wiki), ifttt is based off the same ideas – but is much easier to approach, think about, and use. There are a couple of other ifttt flow blog posts around, but my favorite blog entries are the ones that show instead of tell – so, here we go:

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!

With Heroku’s basic database plan, it’s easy to run heroku pgbackups:capture every once in awhile and save a pg_dump backup of your database – but it’s not as easy as it should be to set up automatic backups of your application’s shared database. By combining Heroku’s nifty Cron Add-On (runs a Rake task via rake cron daily for free) with its existing PG Backups support, you can pretty easily get the platform to help you back up your application.

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.

Some obscure-ish bits worth remembering while trying to navigate my way through this frontend mess (I wanted to stay a backend engineer…), dumped here for my records.

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.