Monthly Archives: October 2014

Luck being indie

When Gus Mueller recently linked to Paul Kim’s post on being indie, he called out the section on luck:

“One thing that I did learn is to have a healthy respect for randomness. Luck plays a huge role and you can’t always attribute one’s success or failure solely on their decisions and actions.”

Reminds me of the book Get Lucky by Lane Becker and Thor Muller. Like half the business books I’ve bought, I never finished reading the whole thing, but it’s in the stack on my bedside table and I pick it up every once in a while and read something new. I love the book’s premise and they’ve got some great stories.

Most of life is a series of random opportunities. Knowing which ones to skip and which to double-down on makes all the difference.

Listening to the latest episode of Vector, the only clear solution for iPhone 6 users who want a bigger screen but also want a small phone: Apple should bring back the flip phone. In a nod to Nintendo, they can call it the iPhone 6DS.

→ 2014/10/08 9:03 am

After getting bogged down in Monday morning email catch-up and other tedious miscellany, nothing brightens the day like my wife telling me to place an online order because she’s picking up Torchy’s.

→ 2014/10/06 11:00 am

Blogging every day

Matt Mullenweg on being challenged to blog every day:

“I thought blogging every day would be a burden, but it actually became a great source of joy. It was more a shift in mindset than anything β€” every day I read things I think are interesting, share links with friends, have thoughts that are 80% of a blog post, and write a ton privately, it was just a matter of catching those moments and turning them into something that was shared with the world.”

Whenever I get out of the habit of writing daily, it creates friction to get anything published. When you post every day, there’s no expectation that all posts have to be great. But when you wait too long, there’s an increasing feeling that the next post has to be perfect.

Tools that make writing effortless β€” like Twitter’s limited, fast UI β€” should be part of the next generation of blogging software. I think that’s going to be around microblogs. Just because traditional blogs initially failed to embrace microblogging doesn’t mean we can’t take that format back with better server apps and clients.

When people first started paying attention to Twitter, the criticism was that no one cared “what you had for breakfast”. But if you look at some of my earliest posts on this weblog, many are equally trivial. What appears unremarkable today β€” the first lunch you had with co-workers at a brand new job, the stop at REI to get a tent for an upcoming family campout, the missed flight on the way to a great conference β€” might carry important meaning in later years, looking back. It hurts the web to keep that locked in a silo.

Tweet Library 2.6

Tweet Library 2.6 shipped today after 13 days waiting for review from Apple. This release adds support for the iPhone 6 and iPhone 6 Plus screen sizes, as well as improvements to sharing so that iOS 8 extensions can be used, and a fix for an annoying random crashing bug.

I also finally dropped iOS 5 and 6 support for this release. I wanted to support the iPad 1 as long as possible because those were my very first customers when I launched Tweet Library 1.0 almost exactly 4 years ago. I hope they got an incredible value out of the app in that time (all upgrades have been free). It feels good to turn a corner and require iOS 7.

Remember when Halloween was a single night and not a full season? Some houses in our neighborhood already have Halloween decorations.

→ 2014/10/02 12:19 pm

Return to open APIs

In 2014, web app APIs basically look like this:

  • JSON or XML API layer for a web site’s content and functionality.
  • Potential client developers must register with the web site and get some kind of API key for access.
  • OAuth is used to grant access without giving out passwords.

A more cynical view of that last point could be rewritten as: OAuth is used to control and limit access so that the API is inaccessible without approval from the web site.

This all seems fairly normal today. I required an API key for Tweet Marker because that’s just what you did, especially if you wanted to charge or limit an API. But it didn’t always used to be this way β€” remember when you could hit the Twitter API with just a user’s password? β€” and it doesn’t have to be this way forever.

For my next web app I’m going to have an API that is more open, requiring no app registration. Instead it will be user-centric, with password tokens that a user can paste into their favorite compatible app for authentication. (My web app doesn’t have traditional passwords at all.)

Not having API keys removes a whole set of complexity: no need to write all the backend code to support managing them, no need for developers to register, no need for me to judge who should get access. Whenever possible, APIs should be nearly as open as the normal web, where Safari and “curl” don’t need to register with a web site just to download its home page. Users are in the best position to know which apps should get access to their account anyway.

If we can loosen APIs, I think it makes the web better. Dave Winer takes it one step further:

“What we really need, and I hope to help make happen, is a network based on open syndication of content. Then there is no one to ask for an API, because there’s no one in charge.”

I’ve been calling my latest project halfway decentralized. I’m still in charge, but just barely.