ZeroMQ can be a great tool, however, there a few things to keep in mind, especially if you are using it in conjunction with Celery (not as a message broker, I assume you’re using something else like RabbitMQ for this).

It’s not very well documented, but during launch, Celery uses multiprocessing to start the Python workers. On Unix-based systems, multiprocessing uses the fork() system call to spawn new processes. Forking copies the parent process into a new process, which causes an issue with open file descriptors (including sockets). This would also be a problem for Django’s database connection, but Celery will reset that by default.

So, if you are using ZeroMQ inside a Celery task (for logging for example), you need to force the worker to manually close and re-open the ZeroMQ context. You can easily do this using the built-in Celery signal worker_process_init. The following helper module takes care of this:

The sed syntax on OSX is somehow a little different than on linux and I keep forgetting it. To replace content within a bunch of files (recursively) on OSX:

Clearing a RabbitMQ (AMQP) queue is not as straightforward as it should be. Python’s amqplib makes this a bit easier:

Don’t (ever) call [self.view something] in a UIView’s -(id)init method. Why? Calling a UIView’s view will automatically load it if it isn’t already loaded. So in this case, ViewDidLoad will finish before the class is fully initialized (which can cause all kinds of weird bugs).

It makes sense and it’s obvious… after the fact. :)

Sometimes you get stuck, very stuck and nobody seems to be able to point you in the right direction. This was one of those moments. The gist of it goes as follows:

We are instantiating singletons using a very efficient approach as suggested in the book: iOS 5 Programming Pushing the Limits:

At the same time, we observe a property of this shared instance using KVO. Now here is the tricky part. iOS internally implements KVO using class swizzling. This basically means that when you first call addObserver:forKeyPath:options:context: on an object, the framework creates a new KVO subclass of the class and converts the observed object to that new subclass (as I found out after a while). Well, this doesn’t work in combination with the suggested +initialize method to create singletons. In fact, initialize is called twice (once for the superclass, and once for the internally generated subclass).

Conclusion: if you are using KVO, create a (non-strict) singleton using the approach below, it will save you some headaches.

There is a lot of speculation about Facebook’s $1bn acquisition of Instagram. Regardless of how much Instagram is actually “worth” (value is in the eye of the beholder), here is my perspective on how it might have gone:

Facebook realizes that in order to keep winning the social network game, they need to be much stronger in mobile than they currently are. Instagram today has one of the largests “mobile social networks”, a great team and clearly a very good understanding of how to grow and scale on mobile.

Realizing this, Facebook tried to acquire Instagram for, let’s say $300mln. Instagram respectfully declined, and went on to raise $50mln at a $500mln valuation. Zuck realized that they were at risk of losing their chance to win in mobile, and purchasing Instagram in 2 years would could cost them $4bn+ (look at Ebay/Skype). If Instagram is what’s needed for Facebook to successfully IPO and keep growing, then the wise thing to do was to purchase Instagram at the lowest possible price they would today accept: $1bn (so at least the investors got a nice return).

Not sure if this was the actual turn of events, but it sounds feasible.

“I would rather drink piss like Bear Grylls than log in with Facebook”
– Tiny Review user

Startups always face unexpected hurdles delivering a product. I wanted to write about one that we faced early on at Tiny Review. 

Background 

The Tiny Review iPhone app was launched in November 10th, 2011. It was a true minimum viable product (MVP), and the only way to use it was to login with Facebook. Our plans were to stay below the radar and iterate on product, but a week after going live, Apple featured Tiny Review prominently in the App Store.. We got a lot of downloads and attention, but supporting the traffic and community took up all of our attention from building product.

Why We Chose Facebook First

There were a few, very specific, reason we chose to require Facebook Login at first.

• There are only two of us working on the product, and only one working on the code. We needed a way to manage the quality of content, without devoting a lot of hours to developing a moderation system. We thought Facebook users would be less likely to post questionable content if their real identity attached. 
• We also wanted to limit brands from coming on the platform, until we had a more robust service for them. If a lot of businesses began using Tiny Review to promote themselves, it would be nearly impossible to nurture a community of real, authentic users. 

Initially, requiring Facebook login paid off. Content posted was high quality, and we didn’t see any body parts. Sign up conversion started out greater than 80%,  meaning that more than 80% of the people who downloaded our app, signed in with Facebook. But over the first 6 weeks conversion dropped to 50%. It bears repeating: almost half of the people who downloaded our app never used it because we required Facebook. And people LOATHED it! . We had a lot of five-star reviews from people who raved about the app,, and almost all of the one-star reviews were people lampooning the Facebook requirement. 

Why Facebook Only Was a Mistake

In the words of one user, “[He] would rather drink piss like Bear Grylls than log in with Facebook.” But why? Our user research revealed: 

1. People don’t trust Facebook.  Too many people have been burned by spammy Facebook apps that spammed their friends, stole their data, and provided no utility in return. Tiny Review of course didn’t do that and we went out of our way to tell them, but it didn’t matter. Users don’t trust Facebook.
2. It made changing login options after the fact much more difficult. Once you have an existing user base that has authenticated with Facebook, it is difficult to get them to switch to username/password authentication (they would have to create a new account, and force link this to Facebook after). The only way to avoid hairy account sync issues is to get users to create a username and password first, then link with external services like Facebook/Twitter. If I log in with Facebook first; and the next time I log in I use Twitter, none of my existing data will be there (it’s a new account). If you create a unique username for a user upfront, it becomes trivial to link accounts together.
3. Requiring Facebook lead to a lot of bad reviews. In fact, we mostly have 5-star ratings from users that love the app, and 1-star ratings from users that refuse to authenticate with Facebook. Reviews are important, and we take them seriously. They do not go away, and there is no way to reach out to those users to let them know that you acknowledge their issues and you are trying to resolve them. One of the ways that we tried to address Facebook trust issues is with a a page that explained in plain english how we use their data AND why we request each type of permission, and we put that link next to the Facebook login button. This is the way that we tried to capture the issues that the users might have had, so that they did not leave an anonymous rating in the App Store.

This is not to say that requiring other methods of authentication are any easier. Asking for a username and password on signup is one thing, but typically you would need more information like first and last name, email, profile picture, etc. Every extra field you ask users to complete in the signup process will lower your conversion ratio. Furthermore, with email signup we don’t know who your friends are so we can’t give you a social/more personalized experience. As a developer you want to get the first impression right, and the more data you have about a user the easier that becomes.

Adding Twitter Authentication on iOS applications is also a tough nut to crack. SSO with Twitter sounds simple, especially with the iOS 5 Twitter integration, but it’s anything but simple: 

• iOS 4 backwards compatibility is still a requirement. About 70% of Tiny Review users have migrated to iOS 5, but 30% is too large a number to ignore.    
• ‘Easy’ Twitter SSO on iOS 4 requires `XAuth` special permissions from Twitter. You have to email Twitter to get these. Getting these special permissions can take a while, in some cases a few weeks; in other cases you may not get them at all. 
• Single Sign On (SSO) with iOS 5 requires `Reverse Auth Permissions` from Twitter, so you need to email them again.This is only required if you need to have access to make authenticated calls on behalf of the user on your server. We need this.
• The app needs to support multiple flows for both iOS 4 and iOS 5.  A user that is still on iOS 4 will need to have a much different login flow, than a user that has is using iOS 5’s Twitter integration. Building additional login screens to accommodate both workflows is not always an easy or straightforward task.
• Twitter authentication doesn’t give email, so if you need the user’s email address you need to build out an additional signup step.

Conclusion

If you make a mobile or social product, and its success depends on growth, you must focus on removing ALL barriers to usage. Restricting login to one platform works against this basic idea. Even with your MVP, the login options must be thought out. This doesn’t mean that you need to require more than Facebook, but you need to have put thought into this and have a good reason for making the login choices you end up making. Once the product goes live and traffic rushes in, it becomes ever more difficult to focus on building, adapting, and iterating the product. You have to turn your attention to a host of other issues:  user feedback, scaling, content moderation, bug fixing, community management, press, investors, (and in our case) complicated localization, etc. 

Advice: If we could do it again, we would ask for username/password first. This hasn’t really been talked about, but we think there is definitely a best-practice for mobile-signup: always make users signup with email/password, and then have them link additional accounts (FB/Twitter, etc). You’ll save yourself a lot of headaches later. 

Other startups face similar issues. For example, Little Blag Bag, wrote a related blog post about Facebook Connect signup conversion. Conclusion: 30% refuse to authenticate, 30% don’t like it but eventually give in, 40% doesn’t care. check it out.

EDIT: there is a discussion on HN going on: http://news.ycombinator.com/item?id=3604981

A sad day. I just came across a few of his quotes that I love:

From his 2005 Stanford commencement speech:
“Remembering that I’ll be dead soon is the most important tool I’ve ever encountered to help me make the big choices in life. Because almost everything — all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.”

–

Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round pegs in the square holes. The ones who see things differently. They’re not fond of rules. And they have no respect for the status quo. You can quote them, disagree with them, glorify or vilify them. About the only thing you can’t do is ignore them. Because they change things. They invent. They imagine. They heal. They explore. They create. They inspire. They push the human race forward. Maybe they have to be crazy. How else can you stare at an empty canvas and see a work of art? Or sit in silence and hear a song that’s never been written? Or gaze at a red planet and see a laboratory on wheels? We make tools for these kinds of people. While some see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do.