I am all in on Appcelerator - it’s victory or death for me and this company now. We’ll see which one it is.

But assuming it’s the former and not the latter, I really want to run a software company and build out one of the many world-changing ideas floating around in my head. And to do that I’ll need to build a team of engineers I want to work with. I’ve read a lot on the topic of hiring engineers, interview questions, and all of those things. I also see how other companies view themselves and the types of people they’re looking for: ninjas, gurus, rockstars. Engineers that ride in on a unicorn with a mane of purple fire, slinging code and rocking out features in days. Engineers that have a PhD in software engineering and have the Java 1.6 standard library APIs memorized.

I don’t know that I want to work with those types of people necessarily. I want to work with people that are curious, and willing to explore new ideas and technologies. I want people that are craftsmen, that measure twice and cut once. I want people that care about beauty, form, and design (programming interfaces or human interfaces, which are not so very different). I want people that are practical, and favor the simplest solution to a problem. I want people that speak their mind, but listen to what others have to say.

So I guess I’m not looking for a team of Picassos or Einsteins. I am looking for a team of Bob Villa’s or Mike Holmes’. Give me a team of careful craftsmen who appreciate clean lines smooth edges, and we will build something amazing.

trevmex:

#railsconf 2011 Notes

Yehuda Katz (@wycats)

How do you build Rails apps that work with rich client-side applications?

Rails can be very useful, even if you are not rendering HTML, Rails makes making APIs really awesome. It can work well for machine-to-machine communication.

“If all I’m doing…

In the States, it is popular to assume higher taxes are always and in every situation bad for business. There is no statistical data to support such a claim, and there is compelling evidence to the contrary (or at the very least suggesting that personal income tax rates and business prosperity are not inextricably related, as many Republicans would have us believe). Our collective inability to have a rational discussion on tax policies is crippling and will eventually bankrupt our government. From the article:

There is precious little evidence to suggest that our low taxes have done much for entrepreneurs - or even for the economy as a whole. “It’s actually quite hard to say how tax policy affects an economy,” says Joel Slemrod, a University of Michigan professor who served on the Council of Economic Advisers under Ronald Reagan. Slemrod says there is no statistical evidence to prove that low taxes result in economic prosperity. Some of the most prosperous countries - for instance, Denmark, Sweden, Belgium, and, yes, Norway - also have some of the highest taxes. Norway, which in 2009 had the world’s highest per-capita income, avoided the brunt of the financial crisis: From 2006-2009, it’s economy grew nearly 3 percent. The American economy grew less than one-tenth of a percent during the same period.

Also, note the payroll differences in high-tax Oslo, Norway versus New York City. To employ a software engineer at a $100,000 salary costs $116,603 after taxes and benefits. In New York City, it costs $122,490 for a single person, and $138,314 for an employee with a family.

Had a person in class with a MacBook Pro with a corporate IT configuration. They ran the iOS simulator and were unable to get location services to work. Turns out that your Mac’s location services are used by the iOS simulator, and they need to be enabled for location services to work. This is in System Preferences » Security.

The symptom you’ll likely see in the simulator is an error related to location services being disabled for this device, or something along those lines. This is persistent despite resetting content and settings from the iOS Simulator menu.

Gorgeous site design generally, but classic example of getting too cute with the UI.

Here are the slides from my talk at Mobile March 2011 - thanks to Justin and the crew for putting on a great event!

Every day it seems like I see another tweet or plea for help from a developer flailing about trying to implement oAuth in their desktop or mobile application. This is because oAuth is probably the least user friendly technology I have encountered in my decade of software development. As frustrating as it is useless, I cringe every time I need to come near it. For the busy, here are the bullet points of my upcoming rant:

• oAuth doesn’t protect the end user’s password
• oAuth is a horrendous user experience
• oAuth is not impossible, but a pain to implement
• Using common sense in your web service API design, all the goals of oAuth can be realized

While oAuth is reasonably easy to implement in a browser-based application, it remains incredibly unwieldy for desktop, mobile, or any other type of client. With a bit of determination, the libraries exist to do oAuth in your client app today, the JavaScript version of which works in Titanium with a bit of massaging. For Titanium Mobile, there’s a welcome attempt from a community member to generalize the process out into a JavaScript library, which is so far looking promising, if a little rough around the edges. So without a doubt, there are many, many people who have successfully implemented oAuth in many different contexts, so clearly it is possible. It is also possible for me to swim from Saint Paul to Minneapolis in the Mississippi river in early December wearing a Speedo and a rakish grin, but that doesn’t mean it’s a good idea.

Here’s why oAuth is ridiculous, and should be banished from the face of the Earth. It should be said that these arguments largely pertain to non-browser web service clients:

oAuth does not protect the user’s password

The biggest fallacy of oAuth is that it prevents an end user’s password for Service A being retained by Service B, who uses Service A on behalf of the end user. By taking the end user to a login screen branded by Service A, the user is made to believe they are giving their password to trusted Service A (which most of the time is the case). However, if I am the developer of Service B, and I have a malicious intent to grab the user’s password, I have any number of ways to intercept the password being entered. Or maybe I just fool the user with a well-decorated login screen which mimics the look and feel of Service A.

I call shenanigans on this most ‘useful’ feature of oAuth - it’s no more secure than giving your Service A username and password directly to Service B.

oAuth is an awful user experience

I shouldn’t have to call out that opening up a random browser window, removing the user from your experience, is hardly an ergonomic means of authenticating users. Anyone who has used a Facebook-connected desktop app knows how weird the boxy blue CSS of Facebook looks inside an application that is neither blue, nor boxy. This is a minor gripe, but from a UX perspective I am diametrically opposed to disrupting the user’s interaction with my application by kicking them out to a browser window, embedded or not. Especially since, as noted earlier, it does not enhance their security.

oAuth is painful to implement

Yes, there are many client libraries out there for consuming oAuth services (so too are there for SOAP web services, maybe the next most reviled technology on my list). But there are just as many developers who struggle to implement these libraries in different languages and different runtime environments. oAuth is a weird abstraction layer dependent on a bizarre song and dance of hashing and string concatenation, none of which is ultimately necessary if you make different choices in your web service API design. And I am generally distrustful of any web service API that requires a sophisticated client library to even use (yes SOAP, again I am looking at you).

The goals of oAuth can be achieved differently

Maybe I am missing something, but as far as I can tell there are a few named benefits of oAuth from the perspective of the oAuth provider:

• Do not divulge username/password combos to third parties
• Do not require (or allow) the use of username/password combinations on every request
• Retain the ability to revoke the permission of a third party application to act on a user’s behalf

The first problem is essentially unavoidable for the reasons stated in the first bullet point - if a third party is going to ask for a username and password combination, they have the ability to grab and retain it if they act unethically. What you as the web service provider can do is design your web service API such that a username/password is exchanged for a token, which may have an expiration date and can be revoked if needed. In this case, the third party has no ethical reason to retain a username and password, which is the best you can hope for. A reasonable web service API will:

• Use SSL to protect the contents of a request and response
• Exchange a password for a token that can be revoked by the service provider or the end user
• Require the use of a token for authenticated requests, not a username/password combo
• Potentially, use an API key to have an understanding of who is using your API and why, and retain the ability to shut them down if they cause problems.

None of this requires the two or three legged oAuth BS that serves as a source of consternation for so many developers. Am I missing something? Taking crazy pills? If so, please set me straight in the comments. Otherwise, join with me in rising up against needless complexity in web service APIs.

zachwaugh:

Every time Apple releases a new product, it becomes more and more clear that no other company really gets it. The next war for winning consumers’ hearts - in both hardware and software - will not be based on tech specs, but on usability and user experience. Computers are already way faster than…

An excellent piece of start-up wisdom, in graphical form - note that LTV on the right must exceed CAC on the left, or your business dies.

I would maybe repurpose CAC to “cost to acquire and retain a customer” - ongoing support and relationship management likewise detract from the lifetime value of a customer.