bemaniac

For some context: This is the first app I've ever gotten onto the App Store. I have an engineering background, but I spent the summer learning Swift, and this was the fruit of that effort.

I'm an avid weight lifter, but I found that while logging my workouts resulted in faster gains, all of the methods for logging those workouts was cumbersome. I tried several apps, pen and paper, and keeping a note on my phone. They all fell short in a number of ways, and I'd often give up fairly shortly.

I set out to build an app that could knock one simple thing out of the park: simply logging individual exercises. I wanted everything else—like calculating PR's—to be done passively.

I did a lot of iteration on that front, and had a beta program with about 40 participants to hone the experience. I'm pretty happy with the result.

That said, I'd still love feedback if there are any fellow lifters out there willing to give this app a shot!

They're not welcome to the club when they're taking actions to strip the rights of another individual. Opinions are one thing, concrete actions are another.

If sexual orientation is a choice, then why aren't there throngs of "straight" male scientists choosing to be gay for a while, fucking a bunch of dudes, enjoying it (that's the key part), then writing papers on it?

I think for someone who already loves CoffeeScript, this stuff shouldn't be review. This post is intended for people who have specific objections to using it.

Anyway. To each his/her own.

I wasn't defining a function in that example, I was calling a function that contained a closure as an argument (in both JS and CS). This is perfectly valid JavaScript.

I've edited the post to be more clear on this.

To rephrase, we found that most logic in our app was view/event/interaction-related, and we found that keeping that stuff in the views made more sense for us.

Ah I see what you mean. No, we generally don't unbind events on models/collections, but this is mostly because we don't remove views/subviews from a page that often. We try to cache as much stuff as possible so subsequent clicks between tabs are really fast.

Yeah, it seems weird, but that's the way it works in Backbone (at least for us). Views are more similar to iOS' UIViewController than a Rails view.

Backbone views handle event binding and rendering, so they're more similar to Rails controllers, if anything.

I didn't go into much detail because I could have gone on and on forever.

We keep our models and collections very bare. They essentially just have methods that communicate with our API and that's it.

We handle subviews by appending them in the render method. For instance, in a post list, we append each post list item in the post list's render method.

I'm sorry if that doesn't answer your question. I guess the essence of it is we append subviews in the render method. Is there anything specific about this you want to know?

I guess it just depends on your definition of "big". I'm curious to see how many views they have. We have many, many views.

Our new Posterous Bar -- http://blog.posterous.com/introducing-the-new-posterous-bar -- was also built using a few Backbone views for those interested. We love Backbone.

Your ideas are intriguing to me and I wish to subscribe to your newsletter.

In my experience, these recruiters just grep for words like "Ruby" and "Javascript" and blindly send out form letters.

I will say though, when I was looking for a job, a recruiter helped me set up quite a few interviews in a short period, and I ended up being placed somewhere awesome.

Inline styles. For shame.

The main difference is that these buttons require no images, while the Zurb ones still require an image. The lack of images makes the buttons highly scalable.