John Sheehan : Blog

Don't "Push" Your Pull Requests

Mon, 20 Feb 2012 12:33:00 -0800

Contributions are always welcome, but surprise patches are mostly just a burden. Yes, you are offering your help, but someone else will have to maintain your code over the long term - get their buy-in first, avoid surprises. Even worse, a localized change to address a specific problem will often miss the full implications to the project: other existing use cases, future roadmap plans, or overall architectural decisions. A good idea can be implemented inappropriately for the specific project; it can be invalidated by another effort that you may not even be aware of; the timing may be wrong, and a dozen other reasons can conspire against you.

This is so true. I’ve had this happen numerous times with RestSharp. Unfortunately more often than not this ends up with the (almost always first-time) contributor becoming disillusioned and giving up on participating in the project. A net loss for everyone.

Making Sense of Android

Wed, 15 Feb 2012 23:22:34 -0800

Making Sense of Android:

Dustin Curtis (an up and coming favorite blog of mine):

Android does prioritize scrolling to some extent now, but it still doesn’t feel as smooth as it does on iOS. An inordinate amount of time went into perfectly designing the physics simulations performed by iOS’s elastic scrolling and other touch event responses. Android’s initial development clearly did not include this attention to detail, because issues regarding the user experience appear to have been beyond the scope of the original vision. As a result, the fundamental engineering choices made during the initial stages of building Android’s interface layer were flawed. This is why Android feels “wrong” to so many people.

Including myself.

Bret Victor Will Blow Your Mind

Wed, 15 Feb 2012 10:06:27 -0800

By now you’ve probably seen this video of a talk Bret Victor gave at CUSEC 2012 called Inventing on Principle. If you haven’t yet, here it is. It’s worth an hour of your time. The demos are incredible.

Bret Victor - Inventing on Principle from CUSEC on Vimeo.

When you’re done, check out his impressive resume.

While perusing through his site I stumbled upon this gem in an article from 2006 called Magic Ink:

The primary question is, “What movies are showing today, at which times?” Given the two spatial dimensions available to us, this should suggest a graphic with movies along one axis and times along the other.

His proposed interface looks a lot like a popular travel site. I wonder if they read this first.

Reinventing Default Profile Pictures

Wed, 08 Feb 2012 10:40:28 -0800

Reinventing Default Profile Pictures:

I’ve never really been a fan of generic avatars but was never creative enough to come up with something better. I really like what 37signals ended up with.

Fixing "Previous Track"

Sat, 04 Feb 2012 17:20:38 -0800

Fixing "Previous Track":

Accidentally hitting the “Next Track” button is a minor annoyance, but its behavior is reasonable.

But the “Previous Track” button loses and resets my playback position, which is extremely frustrating and disruptive to listening. And there’s no “Undo”.

Marco’s criticism of how the playback buttons work is spot on. The software industry needs to spend more effort finding ways to shed legacy design that was a result of building physical devices. It’s why touch-only device games that use on-screen controls that replicate the style of physical gamepads never feel quite right. The more we let go of these preconceptions the more natural our devices will feel.

Promotion

Fri, 03 Feb 2012 15:28:37 -0800

Promotion:

Mikeal Rogers:

The best way to promote your project is to first promote that understanding of the problem. The better you are at sharing that understanding of the problem the more your audience can appreciate your solution.

In Mikeal’s case he’s talking about open source projects, but this also applies to products. If you define yourself by your competitors instead of sharing in your customers’ pain, all you’ll ever be is just an alternative to the competitor instead of a solution to a problem.

Voice

Fri, 03 Feb 2012 13:26:10 -0800

Voice:

Zach Holman:

Maintaining a standard voicing is hard for even one person. As your company grows, though, it becomes exponentially more difficult to maintain a consistent voice as each person contributing to your copy dilutes your initial vision.

At Twilio we’ve spent a lot of effort on maintaining a consistent voice as we’ve grown 10x in employees over the past two years. One great way to do this is ‘gold standards’ to refer to as Zach suggests. I think an even better way to do this is to have a rock solid, company-wide understanding and buy-in of the mission.

This starts at the top. We’re lucky to have a CEO who excels at getting everyone on the same page. This trickles all the way down through the ranks.

It’s also important to keep all the departments that actively talk to customers in tune with each other. If you progress through talking to a developer evangelist, then a sales engineer, then later a support person you should be getting the same message all the way through. Consistency builds trust.

Even within departments it’s important to have everyone on the same page. They do not have to use the same words, but they should be saying the same thing. If you’ve ever encountered different reps from the same company and got conflicting information you know how that affects your trust level with that company. It can also give you the impression that they don’t have their act together.

Consistent voice is one of the most important things I’ve tried to enforce at Twilio and based on the way I hear people talk about us, I believe it has paid off in spades.

finerios: The iPad’s split keyboard has phantom buttons. If...

Fri, 03 Feb 2012 13:14:44 -0800

finerios:

The iPad’s split keyboard has phantom buttons. If you’re used to typing Y with your left hand, you can.

F-ing brilliant.

I'd rather live in a one-button world

Thu, 02 Feb 2012 12:54:00 -0800

Jeff Atwood doesn’t like how his iPhone only has one button.

I have the same issue with the single button on the iPhone that I do with the single button mouse – it may be OK-ish at the very beginning, but over time it leads to absurd, almost comical overloading of functionality.

The overloading of one button leads Jeff into some unfriendly circumstances:

In particular I spend a lot of time double-clicking to get to the active apps list, and I often mis-tap which kicks me over to the home screen. I have so many apps installed on my iPhone that search is the only rational way to navigate. This means I search a lot, which requires clicking once to get to the default home page, pausing, then clicking again. Sometimes I click too long, which is then detected as click-and-hold, and I get the voice search app which I am … er, not a fan of, to put it mildly.

I think Apple is going to fix this in the next OS update, but regardless of these ugly edge cases, I’m still a big fan of the single iPhone button. For the most common things I need it works perfectly well and I’m willing to accept the very occasional unintended Siri summoning (though it is very annoying that even with the phone in mute, Siri still makes noise).

My preference for a single button was especially reinforced after a trip to London this past weekend that involved using a Samsung Focus Windows Phone 7 for four days. For a variety of reasons (random reboots, reboot loops that drained the battery in my pocket, frequent errors and app issues, lost pictures, non-responsiveness to taps, the list goes on) it was an infuriating experience. Atop the list of infuriating things: that damn back button.

You would think it makes sense to have a permanent back button. Atwood makes a good case:

While I’ll tentatively agree that not all phone apps have to behave like the Internet, the Internet is becoming more and more of a platform for bona fide applications every day. The back button is a UI paradigm that works like gangbusters for webapps, and I’d argue strongly in favor of that being a hard button on a device.

Unfortunately, apps are not as well suited for ‘Back’ buttons as web pages. Let’s go back to Jeff’s problem with the home button being too overloaded. The Windows Phone 7 back button suffers from the exact same problem, except the context is switching far more often. Let’s look at what the back button does in WP7:

Goes back to the home screen after launching an app
Navigates the web browser back a page, until the history stack runs out, then navigates back to the home page (this also appears to not save stack state consistently so if you open the browser, view some pages, go somewhere else and come back to the browser later and want to navigate to an earlier page in your history the back button will instead throw you back out to the home screen instead of the last page in your web history).
Press and hold to switch between ‘open’ apps
Switch between apps if, for instance, your email has a link to a web page in it
Sometimes switch between views within a single app
Sometimes it just does nothing at all

It does not go back to a previous ‘pane’ of a panorama view or whatever they’re called. So if you’re in one column, and you swipe to another, effectively changing the view and you hit back, you’ll either go up the view stack within the app, or back to the home page if you’re already at the top level.

All of this combines for endless confusion. I never knew where I was or where the unlabeled, generic back button would take me back to and what I was expecting rarely happened.

The bottom line on the WP7 back button is that there is zero reliable information available to you about what will happen when you press it. And this is the problem with elevating it to a permanent placement. No app or context has consistent back semantics.

A single button also forces app developers to think a lot more about how their apps are organized and navigated. There are platform conventions that Apple has gone a long way to espouse so that within every app the navigation experience is consistent. Good apps have the back button on the top left with the name of the previous screen so you always know where you’re going.

A lot has been written about the history of why the original Macintosh only had one button on the mouse. While this annoyed ‘power users’ like myself in the 90s, I have come to appreciate that this decision may have been one of the most important things Apple ever did for desktop computing user experience. Windows became a maze of context menus as it grew up and I rarely find the need to right click in OS X to this day. The entire experience feels more fluid to me because of that.

In the same vein, I think the single button iPhone set touch computing on the right track and forced the software UI to be far more intuitive and less confusing.

Google Search Algorithm, A History (Thanks to Nina Mehta for...

Wed, 25 Jan 2012 17:24:26 -0800

Google Search Algorithm, A History

(Thanks to Nina Mehta for the hardware support.)

Just a book seller with a $1B cloud infrastructure subsidiary

Mon, 23 Jan 2012 13:38:35 -0800

Just a book seller with a $1B cloud infrastructure subsidiary:

Joyent CEO, David Young:

“I don’t want to dump on Amazon, but I just don’t think you can look to a book seller and grocery store for cloud innovation.”

First off, he clearly did want to dump on Amazon. Second, calling Amazon a “book seller” is the current equivalent of using “Micro$oft”. No professional CEO should stoop to such sophomoric drivel.

Anyway, congrats to Joyent on their round of funding. We need more infrastructure providers. Amazon is far and away in the lead. More competition is good.

First Impressions of DynamoDB

Mon, 23 Jan 2012 12:09:38 -0800

I wanted to try out Amazon’s new DynamoDB service so yesterday while watching 14 hours of football and football games I wrote a script to track my Twitter followers and unfollowers. Here’s my first impressions.

Old habits die hard
I’ve played with various NoSQL stuff like Redis and Mongo in passing, but never really built anything beyond a hello world. I have a ton of experience with relational databases and it’s very hard for me to shift my mindset and break old habits. For instance, my data model for this script was ridiculously simple: a user ID in a table. I thought I would just use the scan functionality to return the whole table but table scans are not recommended. Instead I just used a common hash key and put the user ID into the range key. Queries over hash keys are fast and easy so it worked out fine.

boto is very nice
I wrote this script in Python which has a great third-party wrapper for Amazon Web Services called boto. It’s very complete and basic support for DynamoDB was added just a few days after it launched. It still has some feature gaps (like scan) but overall I was able to get what I needed out of it.

I still like Python a lot
Python syntax is pretty awesome, except for some of the self passing. I do miss LINQ from C# though. That would have made some of the list checking a lot easier. Between Google and Stack Overflow though I was able to find good short snippets to do what I needed to do when I got stuck. And requests for Python is my favorite HTTP client I’ve used on any platform.

SendGrid rocks
Dead simple REST API to send email. Since I plan on running this as a Heroku worker process I didn’t want to mess with SMTP. I have it set up to email the results when it’s done processing.

You can find the script on GitHub.

My .NET Open Source Project Management Nightmare

Wed, 18 Jan 2012 23:05:00 -0800

I’m still doing occasional maintenance on RestSharp because it’s my baby, I want to see it continue to thrive (preferably under the community’s tutelage) and the company I work for has a dependency on it.

RestSharp depends on JSON.NET and uses NuGet for distribution, listing JSON.NET as a dependency that gets automatically installed when you install RestSharp. I don’t specify a specific version of JSON.NET to depend on because they’re good about not breaking their API and it works from version to version just fine. Within the RestSharp projects themselves the reference to JSON.NET is managed via NuGet.

Or I should say, it did work. At some point recently I started getting innundated with support requests for both RestSharp and twilio-csharp that JSON.NET was throwing exceptions. Turns out when you add a reference via NuGet to a strongly-named assembly (a recent change for JSON.NET I can’t track down anywhere), your reference is tied to that specific version so if JSON.NET is updated to a newer version you start getting runtime errors.

As long as you install RestSharp when it was built against the current version of JSON.NET, no other projects depend on a different version of JSON.NET and never update your JSON.NET version out-of-band with RestSharp you won’t see this error. I could set a hard version dependency in my NuGet package, however JSON.NET is so popular (thanks Microsoft for including first-class JSON support in .NET! Not.) that’s almost assuredly going to cause issues if you have other packages installed that depend on it.

To keep the project working, every time JSON.NET releases an update (thankfully it’s not too often) I have to rebuild and distribute an updated RestSharp, which twilio-csharp depends on so that has to get updated and distributed too. twilio-csharp also depends on a JWT library I wrote that also uses JSON.NET so I have to fix and distribute that too before I can fix twilio-csharp. At any point JSON.NET can release an update that people manually update to and break everything that depends on it. It’s like Chaos Monkey for the project. At some unknown point any number of users could break, resulting in more support emails for me and another set of changes just to appease the dependency gods.

This is why I’m not able to work on new features for RestSharp. I have to spend all of the very little free time I have for the project dealing with this crap.

Love the simplicity and cleverness of this scorekeeping app by...

Thu, 12 Jan 2012 11:06:36 -0800

Love the simplicity and cleverness of this scorekeeping app by Matt Rix. While watching the video the sounds and colors felt familiar and it turns out that’s because Matt is also the author of the excellent Trainyard game for iPhone and iPad.

/via Shawn Parker via Tyler Galphin

Instacast is the iOS Podcast App I Actually Wanted

Mon, 09 Jan 2012 23:28:00 -0800

Instacast is the iOS Podcast App I Actually Wanted:

After posting about iCatcher and Podcaster last week, a few folks on Twitter pointed me to Instacast which is far better than both the other two. Clean UI (much, much, much better than iCatcher), stream-focused with option to download and cache, iCloud sync, etc. It’s got it all and it’s not ugly. There’s an iPad version too.

One Bad Piece of Documentation Does Not Make Fail

Mon, 09 Jan 2012 22:55:59 -0800

One Bad Piece of Documentation Does Not Make Fail:

Idan Gazit goes a little overboard over one piece of bad documentation for the Twitter API. The core of the issue is solid: bad docs make using APIs needlessly difficult and can be extremely frustrating for developers. This does not mean Twitter has universal “poor practices” as the title purports. At least the API works.

One important thing that I’d like to call out to anyone thinking of taking a dependency on an API. The first thing you should consider when using an API is, “Does the company I’m relying on need this API to be successful to sustain their business?” If your business interests are not aligned, the risk is very high and you’re likely to encounter a bad experience and most likely a maintenance nightmare.

"Why I Hate Android"

Mon, 09 Jan 2012 22:49:16 -0800

"Why I Hate Android":

MG makes some interesting parallels to net neutrality which may be a little out there, but otherwise I think this piece was solid. And the one thing I definitely with him agree on: the original iPhone was the biggest step anyone had taken to break the hold the carriers have over consumers and Android has stunted any continued progression in the right direction.

"The Path to Hacker School"

Fri, 06 Jan 2012 22:25:11 -0800

"The Path to Hacker School":

Hackruiter trains developers for free, turning them into even more desirable candidates, and then (optionally) places them into jobs at tech companies resulting in a finder’s fee, currently averaging about $20K.

Brilliant.

Sour Grapes

Thu, 05 Jan 2012 00:36:00 -0800

(These are my observations and opinions based on interactions with ASP.NET MVPs and ASP Insiders. I can’t speak for other MVP or Insiders programs.)

In response to Rob Eisenberg’s post about his travails with the Microsoft MVP program, I kicked up a dust storm on Twitter tonight with this series of tweets:

This take down of the MS MVP program by @EisenbergEffect should be required reading for anyone looking to achieve that award.

Don’t make the same mistake I did. Trying to become an MVP is a waste of time. Call it sour grapes because I didn’t get in if you want.

The same politics Rob talks about is how I became an ASP Insider, which is a disservice to real ASP.NET contributors.

Re-initiating my attempts to get out of ASP Insiders. If you’re a member, consider doing the same. Participation is an endorsement.

If you don’t want to support a corrupt system, vote with your feet.

I lucked out that in attempting to become an MVP I found something better. Not everyone else will be so lucky.

As predicted, this was interpreted as sour grapes, despite well documented proof that it turned out better for me not getting in the program. I’m genuinely not bitter that I didn’t get in. Doubt it if you want, I don’t really care.

What I am bitter about is that the MVP program disrespects the very developers it sets out to honor. There are a few well-documented problems the program has, most notably around selection criteria. I don’t want to rehash those, go read Rob’s post. But I do want to talk about some other aspects of the program that are damaging to the overall .NET community.

Club mentality segments the community

Before I was an ASP Insider (which I’ll cover below) I would go to user groups and conferences and talk to other developers about what they thought of the latest upcoming ASP.NET releases. I’d make my predictions or state opinions and they’d casually nod along. What I didn’t yet realize is that the MVP and Insiders of the group already knew the answers and weren’t able to discuss things openly because they were bound by an NDA. While this is a standard practice (the company I work for also gives early access under NDA to select customers), it turns out that this can create a rift between those who are in the know and those who are not. After I was granted access to the privileged group, I found myself stuck during conversations, not able to fully engage with those not under NDA. It was very uncomfortable to me to be hampered talking to other community members who are just looking to learn and network and become better developers. Eventually I couldn’t remember what was NDA and what wasn’t, who I could and couldn’t talk to openly, etc. It was exhausting to keep track of so I stopped trying to remember stuff. I broke my NDA a lot. Since I’m trying to give it back anyway, they can happily take it if this bothers them.

Wrong incentives lead to bad behavior

The MVP program also incentivizes bad behavior. In the yearly reviews, quantity is given priority over quality. Or at least it looks that way since there’s no clear acceptance guidelines to know for sure. This leads to a high volume of low quality content to boost numbers that look impressive at a glance. Or you’ll see one guy give the same lifeless user group talk over and over again to juice up the total instead of giving fewer, better talks. If the plural of anecdote is data I have a lot of data from people I’ve come across who have specifically mentioned reusing content in this manor specifically for their MVPs reviews, and not for, you know, helping better the community. The incentives are all wrong.

So the MVP program has outlived it’s usefulness and now does more harm than good but then we have the ASP Insiders program that just complicates matters further. Not that ASP Insiders is a bad program in isolation, it’s actually quite good. You get really direct access to product team, it’s a small, tight-knit group and it’s a lifetime appointment unless you forget to re-sign the NDA every few years. You also get voted in by other members of the group, so there’s no black box for acceptance. Just make 10 or so friends already in the group, do a little ASP.NET community work and don’t make enemies with Microsoft and you’re set. If you can deal with the few people in the group that would rather post the problems they encounter privately instead of on Stack Overflow where they would be embarrassed about publicly admitting there’s something about ASP.NET they don’t know, the mailing list is decent and you get to go to the MVP Summit (on your dime) and party with a bunch of really cool people which is insanely fun.

The problem with the ASP Insiders group is that most people trying to become ASP.NET MVPs believe what they’re after is what ASP Insiders offers. That’s how it’s pitched. It’s not how it works. And that’s unfair to people trying to become MVPs. You either work hard or game the system, get your MVP and then find out that you could have just become an Insider with all the same perks (and more) without as much hassle. I hope you read this and find it out before you go through all that.

I’ve asked to be removed from the Insiders. I got in through a back door (longer story) and don’t really do ASP.NET any more and it’s unfair to the people who really want to be there to have a non-participating zero (as far as the group goes) taking up space. Yeah, there’s no limit to how big the group can get (making it effectively easier to get in over time since the number of votes needed to get in is currently fixed at 10) but it’s still not fair that I’m in there and people who work on this stuff every day and would benefit from access aren’t. I’ll miss hanging out with friends at the Summit but I’ll find ways to meet up with them.

So why did I write all this? Mostly because I think it can be instructive for those working to build developer communities. When you institute classes, no matter how well-intentioned, it can have unintended negative side effects. You never, ever want to have a member of your community say this:

Looking over the last three years, I’ve definitely been a less happy, more frustrated developer. I’m sure it’s linked to the sort of fake “value” being a Silverlight MVP gave me. Basically, they give you a couple of cheep gifts, then they pretend to listen to your feedback, while not actually doing anything. Year after year of that and you get really unhappy. It’s demoralizing. You start to realize that you really are a commodity.

Is that how you want to treat people?

(Comments disabled for this post. Tweet at me or blog.)

Misconceptions About iOS Multitasking

Tue, 03 Jan 2012 23:04:32 -0800

Misconceptions About iOS Multitasking:

The only reason this explanation is needed is because we have built up years of baggage from software that required you to make unnecessary decisions to be useful. The people giving the explanations Fraser decries are working from a false set of assumptions because they cannot imagine a simpler mechanism that actually works because it has never existed before.