Development | Josh Babetski : Quixotic Bravado

Josh's Posts Tagged ‘development’

« Older Scribblings

Newer Ramblings »

Delicious Bookmarks (2009-01-26 - 2009-01-29)

Recent links posted to Delicious:

How to do Basecamp-style subdomains in Rails - (37signals)
Building an interactive map with jQuery instead of Flash | Raleigh Web Design & Development | New Media Campaigns
iLife Tip: Enable Multi-Touch maps in iPhoto '09 - The Unofficial Apple Weblog (TUAW) open Terminal.app (/Applications/Utilities) and type (or copy/paste) the following statement and press enter:
defaults write com.apple.iphoto MapScrollWheel -bool YES

When you restart iPhoto, you will notice that you are now able to scroll in/out of the Places maps with ease. If it turns out that you don't want the scrolling feature, just retype the statement, replacing "YES" with "NO."
Encoding for Apple TV | Mac 911 | Macworld
Enable Emoji Icon on iPhone 2.2 without Jailbreak | Simon Blog

Posted: Thursday, January 29th, 2009 @ 5:07 pm

Twitter Rate Limiting API Uproar

So Twitter is going to begin rate limiting requests to their API soon. Some developers are upset over this. Some of the reasons they are upset include:

They feel Twitter should “fix” the existing API, citing it as a reason they need to make so many requests currently
They feel Twitter shouldn’t have a rate limit at all. This is of course ignorant. Yes, let’s not safeguard against some dude’s poorly coded app and let it bring down or slow the Twitter infrastructure for other devs.
They’re investing time and effort into building applications which depend on these APIs. As the apps gain popularity, they’ll begin or would already exceed these limits.
They’re building a business on a service using Twitter APIs; that business is now at risk

Here’s the real reason some of them are upset:

They feel an unjustified sense of entitlement.

Twitter’s Point-of-View

Now, I’m not unsympathetic to the position this now puts many devs in. I know people who are building cool things using Twitter’s API, but I can also see things from Twitter’s perspective.

They need to control costs. Pinging the crap out of their servers costs money and many of these services are putting heat on these servers without cutting Twitter a check or otherwise being mindful of resource consumption.
They need to monetize their service. People are monetizing something Twitter hasn’t yet. If Twitter can’t make money, eventually neither will anyone building applications that piggyback off of them. Meanwhile, getting overhead costs under control is prudent. See above.
They offered these developers no agreement as to how available they must make their API service and no guarantees. So you spent six months in your basement building a cool Twitter service. I sincerely feel for you, but Twitter didn’t ask you to do it. Using the Twitter API to archive your tweets is one thing, attempting to build a business on top of it is another.
This policy change likely impacts only a very small percentage of developers.

But They Need Us

Somewhere a righteous dev is saying to themselves: “But all these applications we made helped make Twitter the popular service it it today.”

Of this I have no doubt. I’m sure the gang at Twitter HQ is aware of this too. There’s already reasonable speculation if this move will hurt Twitter’s growth, but maybe they want to now better control that growth. Still, now will begin the uneasy dance between developers and Twitter over where the ROI line is for both. Developers want to make applications built on Twitter and potentially profit. Twitter needs usage and popularity to stay high, in addition to initiating this monetization strategy we’re all curious about. Instead of complaining how devs have been wronged by Twitter, they should ask themselves some questions:

What is the value proposition of your application to Twitter?: The service is already crazy-popular so you can’t really offer the value proposition that their app will increase users substantially. I would speculate that most people onramp with Twitter on the web site, then migrate to third-party apps later. How do you help keep people using Twitter?; Is it popular enough that your users will reduce their Twitter usage, make their dissatisfaction loudly known to Twitter or not use it at all if your application went away?
Is the value of Twitter availability such that it’s worth paying to have higher rate limits? Enough users to make Twitter think twice?: If so, instead of irking the Twitter team with bitching, start a constructive dialogue with them over what kind of arrangement you can make to maintain a higher rate limit.

But the API Sucks!

It certainly can be improved, but flush with cash or not, Twitter is a start-up and focused on making that service sustainable in order to eventually return value to their investors. If you can articulate how fixing their current API accomplishes that and warrants a higher priority than other tasks in front of them, I’m sure they’ll be happy to listen to you.

Bottom Line

If you still feel so wronged by Twitter’s actions, consider it a cautionary tale and something to consider when building an application that has a dependancy on a service you’re getting for free and without an SLA.

Posted: Thursday, January 22nd, 2009 @ 6:18 am

My Delicious Bookmarks (2008-08-14 - 2008-08-20)

Recent links posted to Delicious:

Ajaxian » A simple solution to the “other” problem with select boxes A simple tutorial on using jQuery to solve a “select-to-input toggle” that shows and hides a text field when you select “Other”.
Make your 404 pages more useful
Form Elements: 40+ CSS/JS Styling and Functionality Techniques
The Complete Guide for You to Become an Almighty jQuery Developer | Effectize

Posted: Wednesday, August 20th, 2008 @ 12:14 pm

My Delicious Bookmarks (2008-08-12 - 2008-08-14)

Recent links posted to Delicious:

Ajaxian » iPhone Safari Flick Navigation By Example .divSlide {
-webkit-animation-name: "slide-me-to-the-right";
-webkit-animation-duration: 1s;
}
@-webkit-keyframes "slide-me-to-the-right" {
from { left: 0px; }
to { left: 100px; }
}
To Title Case | Individed JavaScript for converting text to title case.
Terminal Tip: Burning a disc did you know that you can burn discs right from the Terminal window with a simple command and a drag/drop? Just enter the following command followed by the path to a folder or disk image:
drutil burn filehere

Don't type the "filehere" — that's where you put the path to the file/folder that you wish to burn. You can either type the location manually or drag and drop the file onto the Terminal window. But that's not all you can do with drutil; you can also eject media from the optical drive by typing "drutil eject." To see all of the available drutil options, just type in drutil for a quick list or man drutil for a full description.