Month: March 2013

A few weeks ago, “Uncle Bob” Martin put up a great post on the 8th Light blog, about the value of disciplined software development being just as important, if not more important, for start-ups as for established companies. – The Start-Up Trap:

“As time passes your estimates will grow. You’ll find it harder and harder to add new features. You will find more and more bugs accumulating. You’ll start to parse the bugs into critical and acceptable (as if any bug is acceptable!) You’ll create modules that are so fragile you won’t trust yourself, or anyone else, to modify them; so you’ll work around them. You’ll build a festering pile of code that, with every passing week, requires more and more effort just to keep running. Forward progress will slow and falter. It may even reverse as each release becomes buggier and buggier, and less and less stable. Catastrophes will become more and more common as errors, that should never have happened, create corruptions and damage that take huge traunches of time to repair…

“… If you want to go fast. If you want the best chance of making all your deadlines. If you want the best chance of success. Then I can give you no better advice than this: Follow your disciplines! Write your tests. Refactor your code. Keep things simple and clean. Do Not Rush! You hold the life-blood of your start-up in your hands. Don’t be careless with it!

If you’re an indie developer, working on a startup, or come to think of it if you’re doing any software engineering at all, go read it.

And while you’re at it, have a listen to David Smith’s interview with Brent on Developing Perspective, where he talks about technical debt in NetNewsWire as the iPhone and iPad versions’ deadlines loomed. (Bonus: Identical Cousins innagural episode, Software Is Hard.)


There are probably only a few people in the world who would care about this anymore, but today I got sick of having to browse through my calendar to find links to past posts that I wanted to link to from new ones.

So I added a macro to my template that lists the last 35 posts underneath my pending news items list. Here’s the snippet:

In your site’s Template (not Home Page Template), right after the {bodytext} macro, add

{if method=="GET" and (path=="/newsItems/" or path=="/newsItems/default") {"<h2>Recently Posted</h2>" + viewNewsItems (35, newsItemTemplate:"<a href='{permaLinkUrl}'>{title}</a><br />")} else {""}}

Note: You’ll have to first make both {path} and {method} legal with no parameters via your server’s Legal Macros settings page for this to work properly.

What it does is add a list of links to the 35 most recent news items (a.k.a. blog posts) underneath the pending news items, but only on that page, and only on a GET (not a POST). Of course you can change 35 to some other value if you want to.

See also: Docs for the viewNewsItems Macro

I also used the {viewNewsItems ()} macro to make a page listing all posts on this site.


Some of Apple’s classes like to throw exceptions, log a message to the console, and then crash your app, taking your stack trace with it.

Needless to say, this makes debugging extremely difficult, since you can’t inspect memory or even see who called what to cause the crash.

Thankfully, you can fix this! Here’s how:

  • Open the Breakpoint Inspector (Cmd-6).
  • Click the little + button in the lower-left corner.
  • Choose Add Exception Breakpoint…
  • Leave the defaults alone, and click Done.

Now whenever your app causes an exception, you’re dropped into the debugger, with a full trace, and access to all of your in-memory objects. Yay!

Thanks to Sean on Stack Overflow – though I also heard this in class once or twice and failed to implement it. (Whoops!)


Marco Arment has a great post on the meta-issue surrounding Google Reader’s shutdown, on the issues around “free” in the tech industry:

“If you try to play by the traditional rules and regulations, you run the risk of getting steamrolled by someone who’s perfectly willing to ignore them. Usually, that’s the biggest potential failure of the tech world’s crazy economy, which sucks for you but doesn’t matter much to everyone else. But sometimes, just like unregulated capitalism, it fails in ways that suck for everyone.”

Go read it.


love-rss-icon-sm.jpg: Seen on Brent Simmons’ new RSS-Sync mailing list:

On Sun, Mar 17, 2013 at 10:13 PM, Will wrote:
“It seems like W3 Community groups are designed to structure the development of this sort of web standard… it seems like integrating with their process would help add credibility to the protocol this group settles on…”

I think this is the wrong approach.

We already have a de-facto standard in Google Reader’s API. Tens, if not hundreds of mobile and desktop apps are built to speak this API, and don’t currently have an alternative.

Involving a standards body, with all the negotiating, politics, and gnashing of teeth that comes along with that, could take years and might still not result in a useful protocol.

Given that there’s a matter of months before Reader is turned off and hundreds of apps break, slowing down now is not an option.

A couple of examples

De facto standards count, especially when they’re widely adopted.

Here are a couple of examples where there was a large push to get the standard supported by a standards body, which haven’t panned out so well:

The Atom format was an IETF standard that arrived after RSS was already established. It took at least 18 months to be published as an IETF proposal.

Atom has never been as widely adopted as RSS, and the RDF-based RSS 1.0 has even less footprint than Atom does today.

I worked for months on SOAP 1.1 interoperability while at UserLand in the early 2000’s. SOAP was a W3C standard.

Getting everyone to agree on what it should be was enormously time-consuming, and arguably yielded a spec that as of v1.1 when my involvement ended, still had many ambiguities, and favored some programming languages over others.

Today JSON prevails, and SOAP is limited mostly to apps that need to interop with legacy services, and large enterprise service-oriented architectures.

(JSON was an informal standard for years before it was published as an IETF standard.)

Why this matters

Users shouldn’t have to care
Users don’t know, and couldn’t care less what protocol or wire format is used for this stuff.

They want their feeds to stay in sync across all of their devices. And they want their favorite apps to keep working after Google turns off the lights.

Users couldn’t care less whether the way this works has a stamp of approval from a standards body, and they’ll never glimpse the blood, sweat and tears that developers will invest in the systems they rely on.

They just want their stuff to work.

Developers shouldn’t have to care either
A new standard means that the tens or hundreds of apps that are already in the ecosystem, would have to have one of their most important components rewritten. And that’s assuming that whatever the new standard were, it would even be compatible with those apps without a major rewrite in other areas.

Apps by developers who can’t (or won’t) make the investment to move to the new standard would die, and that would be nothing but bad for users, bad for competition and diversity, and bad for RSS.

And when those apps die, who will the majority of users blame?

(Hint: It’s not Google.)


Chuck Shotton: Google Reader’s Real Value (via Dave Winer)

“Google Reader was at best an average RSS reader. But it excelled at keeping all of my other 3rd party RSS reader apps in sync… When Google Reader shuts down, what is going to do that for me? The answer right now is ‘nothing.'”

Yep – this is a big hole. One that will hopefully be filled soon.

I wrote a bit last month about what Syncpocalypse would mean for bloggers, after the last brief outage.


From The Old Reader blog:

“Paid accounts will have some additional features, but the basic free accounts will still be 100% usable. We are not in this game to make money, but we want to give something special back to the people who are going to be supporting us…

“We reworked the plans according to the news today. Creating an API for mobile clients is the number one priority in our roadmap. We would love to collaborate with any developers who were making Google Reader clients. Please, spread the word about this if you can.”

This is the right move, in my opinion, however I do have two bits of unsolicited advice:

  1. Please clone the Google Reader API, even if you are going to create your own. By doing this you’d immediately make it possible for app developers to migrate their users from Reader to your service.
  2. Re-position your API as a more general service, not just targeted at Mobile. While there are many more mobile apps that depend on the Google Reader API, there are still desktop apps that use it too.

For now their web UI is under quite some strain. It took many seconds to load when I tried it just now (but it did load). They’re adding capacity as I write this, and I bet they’ll get it under control.

(Bonus link – Rob Fishman on BuzzFeed: Google’s Lost Social Network. “How Google accidentally built a truly beloved social network, only to steamroll it with Google+.” Amen, brotha.)

Blogging RSS Web

Dave Winer: Google Reader’s demise, part 2

“I don’t doubt that people will be well-served by a newly revitalized market for RSS products, now that the dominant product, the 800-pound gorilla, is withdrawing.”

Om Malik: Google Reader lived on borrowed time: creator Chris Wetherell reflects

“[It] was Google Crawler that gave the system ability to make lightning-fast connections and bring up recommendations. It is one of the main reasons it cannot be open sourced. The systems are too intertwined with Google’s search and other infrastructure to be sold as well.”

Marc Canter: Do they expect us to just stop using RSS?

“Here’s another thing – they’re saying we’re supposed to utilize Takeout to export our subscriptions. Well when I went to do that – the archive being built included all my YouTube videos – which are like 50G.” (I agree – Takeout pretty much sucks.)

Laura Hazard Owen: Google Reader, please don’t go – I need you to do my job

“… Flipboard is a lean-back kind of service. I use it when I want to curl up and read. In the mornings when I’m looking for stories, I don’t want to tap through a pretty magazine-like interface on my iPad. I just want to scan headlines and text fast, and I want to do it on my laptop.”

Quora: Why is Google killing Google Reader? (via Dare Obasanjo on Twitter)

Brian Shih, Former Google Reader Product Manager wrote, “I suspect that it survived for some time after being put into maintenance because they believed it could still be a useful source of content into G+.”

Todd Bishop on GeekWire: Bye, Google Reader: Don’t let the door hit you in the RSS (pretty terrible pun, IMHO)

“This is the third time Google has axed one of my favorite services or apps. But whatever. I’m already over it.”

Mat Honan on Wired: RIP: Google Reader Meets Its Inevitable End

“Google Reader was notable not only for its features, but for the active community it fostered for which Reader wasn’t just another tool.”

Feedly is building a Reader API clone: Transitioning from Google Reader to feedly

“We have been working on a project called Normandy which is a feedly clone of the Google Reader API – running on Google App Engine. When Google Reader shuts down, feedly will seamlessly transition to the Normandy back end.”

Blogging RSS Web

Google Reader has been a quite popular, if geek-centered service, with a social bent…

With the announcement that the service will shut down on July 1st, and all the millions of dollars, hours spent, and investment in competing with Twitter and Facebook, I find myself wondering:

If Google had invested more in Reader as a social networking platform, would they have done better than they did with Orkut, Dodgeball, Jaiku, Wave, Buzz and Google+?

(Time: A Brief History of Google’s Social Networking Flops)

Blogging RSS Web

Marco Arment: Google Reader shutting down July 1

“Now, we’ll be forced to fill the hole that Reader will leave behind, and there’s no immediately obvious alternative. We’re finally likely to see substantial innovation and competition in RSS desktop apps and sync platforms for the first time in almost a decade.”


See also: NetNewsWire Cloud

“By implementing a suitable syncing API for RSS, and implementing a reasonably useful web interface, Black Pixel could establish NetNewsWire Cloud as the de facto replacement for Google Reader.”