I don’t have anything to add to the arguments, at least not right now.
But if you haven’t, call your rep.
-
Archives
APIs should have test error endpoints
Dec 13, ’11
5:34 PM
Most of the time, when you start coding against an API, either with or without an API client, you end up producing enough errors that your error-checking is fairly robust. However, sometimes most or even everything “just works.” Which produces a conundrum:
You now have no idea how robust your error handling is (or is not).
As an example, that – ahem – may or may not have just inspired this blog post:
Say you are polling something to check for an update, every 60 seconds or so. If it fails, you want to know that and decide whether or not you should keep polling the endpoint. Everything works great. Until you get a 500 which you haven’t handled correctly (or there was a bug in your logging call or… something, ahem). Now you have an exception in your own code which breaks out of your loop independently of your API error handling. So your polling has stopped and you’ve cutoff your own ability to see what went wrong on the other end.
What I propose, is that we as API providers should include error test endpoints. Something like:
/tests/errors/500
/tests/errors/503
etc
(note: 404 is obviously easy)
In theory RESTful APIs would all return errors in the same way with HTTP error codes and the like, but the practical reality is that this just isn’t the case. Some even return 200s with JSON strings that include errors. Even if they we’re all perfect, you still might want to wrap them in behaviors (like sending an email notification) depending on the message contents, which really leaves you in a predicament if the errors are hard to intentionally produce. You can even make a compelling argument that API client development should start with these endpoints.
I’ve opened an Issue to add these endpoints for YourTrove’s API and I will follow this up with a blog post on the Trove blog when those endpoints are deployed.
Thanks Steve
Oct 5, ’11
9:23 PM
I don’t generally care much at all about the deaths of famous people, but I feel profound sadness at the passing of Steve Jobs. As I type this on my Macbook Air and my iPhone buzzes next to me with texts and calls and GroupMe messages, I find myself thinking back to playing Zork on my first computer, an Apple II.
That was my first experience with a personal computer and although I didn’t realize it at the time, I was already hooked and destined to spend a large portion of my life in front of, tinkering with, and writing software for, computers. While a game was my first experience, it wasn’t long after that I was fiddling with Basic and Logo and logging into BBSes and manually upgrading an Apple IIgs to 768kb of ram (you had to insert the chips -no simms or dimms – yourself back in those days, kids).
I disagreed with a tremendous amount of Jobs’ philosophies and decisions (most recently with a lot of how iCloud works), but in many ways, that’s great: the things I thought he was wrong about helped as much in forming my own opinions and mental constructs for the “new,” as the things I thought he was right about. And those stances showed me the value of sticking your neck out and being passionate, even when sometimes it might be unpopular or even wrong.
People throw the word “visionary” around an awful lot with Steve Jobs and I feel like only some of them have really absorbed what that means. It’s much more about imagination than it is about technology. It’s incredibly difficult to envision something new in your mind’s eye and then communicate that to others and get everyone on the same page to go out and actually make that idea into a reality. He did that. It’s hard to think of many people who have had as profound an effect on human civilization in the last 30 years (yes, I just said that). Certainly not many (any?) politicians, even though in theory that’s kind of their job.
I am unaware of Jobs ever saying anything to this effect, but one of the things I learned from watching Apple over the years is that it’s incredibly important to try and make the complex into the simple. Or the easy. And doing that is way harder than it sounds. When our tools are simpler and easier to use it frees us up to not have to think about using them or how they work. 20 years ago we had to memorize phone numbers. Now we tap on someone’s photo to call them. Think about that. That’s completely fucking incredible. But we actually have to take a step back to appreciate it because it’s so simple that we’ve stopped having to think about it. We’ve been freed up to focus on the next thing. We’ve been moved forward.
It’s hard right now not to think about this quote that Jobs made at the 2005 Stanford commencement:
No one wants to die. Even people who want to go to heaven don’t want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life’s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.
Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by dogma — which is living with the results of other people’s thinking. Don’t let the noise of others’ opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.
Steve Jobs died way too young and a colossus has been stolen from us, leaving a hole in the worlds of technology, software, communications and innovation. When the mourning has passed, the best thing the rest of us can all do to try and honor what Jobs accomplished is to try to be that New: Go out and try to make great things that change the world and make it a better place.
The Big East and Big 12 should merge anyway
Sep 21, ’11
1:25 PM
So, (as of this writing) as it’s apparently played out, the Pac-12 will not be raiding the Big 12 for the Red River schools (Tx, Ok, OSU, TT) and WVU will not be leaving for the SEC. Saving Missouri still possibly bolting for the SEC or UConn for the ACC, it would seem that the realignment stuff has stabilized a bit and the Big 12/Big East “survivor” combo scenario has died down a bit.
I say “so what?” They should still merge with their full membership. Then you’ve got a 16 team football and 24 team basketball conference that opens both former conferences up to a lot more TV markets. The membership looks like this:
Football Schools:
Baylor
Iowa State
Kansas
Kansas State
Missouri
Oklahoma
Oklahoma State
Texas
Texas Tech
Connecticut
Cincinnati
Louisville
Rutgers
South Florida
TCU
West Virginia
Other sports (basketball):
Georgetown
Providence
Villanova
Seton Hall
St. John’s
Notre Dame
Marquette
Depaul
Now all of the sudden you have a much more survivable and desirable conference for all parties. I’ll grant you, the basketball schedulers will have a nightmare on their hands and the conference would have the carbon footprint of the Chinese coal industry, but this theoretical conference has a lot going for it.
It’s much less scary if a UConn, Rutgers or Missouri leaves. So What? Just go grab Boise State or Central Florida. Or use your new size and leverage to actually get Notre Dame to join for football.
And despite having to figure out how to schedule that many teams in basketball, can you say Wow! That’s putting a lot of basketball power into one conference.
Or maybe they merge only for football. That’s okay too, it’s still a much more robust, solid situation for the schools.
Also, you could call the divisions Red and Blue instead of East and West.
NYC 2011 disaster schedule
Aug 26, ’11
1:08 PM
Prepare accordingly…
August 23rd – Earthquake
August 28th – Hurricane
September 2nd – Volcano
September 7th – Meteor strike
September 12th – Zombie apocalypse
September 17th – Alien invasion
September 22nd – Black hole
Python logging tutorial | Pingbacks
Jul 15, ’11
11:34 AM
This is the easiest-to-follow of the various Python logging guides/posts/docs that I’ve seen:
Identity, SSO, and networked namespaces
Jul 13, ’11
9:54 PM
Jud Valeski had a notable observation about how potentially powerful an OS level namespace and single sign-on capability could be for internetworked applications:
Everyone’s talking about the power of Twitter and Apple’s native single sign-on model in iOS 5. While this is a phenomenal coup for both Twitter and Apple, it’s only the tip of the iceberg. Having a widespread, networked, account namespace (Twitter) baked in at the operating system level is one of the few things that can truly revolutionize the network again.
I am certainly not going to be one to criticize this desire at all. But (of course there’s a “but”), I have no real reason to believe that a big company team-up is going to actually enable this desire. The history of big software companies’ attempts at some kind of unified, distributable identity is littered with bungles, with everything from Passport to Apple’s own MobileMe.
There, is of course, the big advantage that there are already a lot of integrations and knowledge about Twitter auth and users, but is that enough?
I’ve always thought that “user-awareness” was incredibly key to making applications powerful and much more user-friendly, but I don’t write about it enough. So, here goes the following…
I still think the solution to this “who is the user/omfg passwords everywhere” nightmare has to be something that provides “connectedness” and an extra layer of security that is used pretty rarely at the moment.
What does that mean? Glad you asked. I think it looks something like this:
- A user connects to an Internet service (through a browser, mobile app, desktop app, anything).
- A hashed key is provided to the service along with that request. The hash initially blinds the service from the user’s identity.
- The service sends the hash off to a third party.
- The third party then contacts the user, most likely through a mobile app: “The service MyHotNewThing wants to connect with your information, do you want to share the following info?…”
- The user says Yes (or No and the process stops and the user gets a “not logged in” view of the service), makes any customizations to what info they want to share with the service, and the third party then provides a key to the service that allows them to access the user’s information.
- The user is logged in to the service and any approved content or other connections(!) are also now available to the service.
Boom. It’s a bit similar to OAuth, but not the same: No browser required, no bouncing through URLs, no confusion about who is asking for what.
A few additional key points:
- Those hashes have to include, behind the scenes, devices. In normal language this means something like “User X has approved access to Service Y from Device Z.” Now, implicitly, the user is probably approving this for all the user’s devices, but all of those keys are different. This lets a user completely disable access from a (stolen, lost, broken) device for everything in one action. It also lets the user disapprove access from an unknown (hacker) device.
- This also makes all the keys and hashes different for the triple combo of service/user/device as opposed to most current schemes, which are just service/user.
- By handing off the approval process to a third-party this opens the door to things like social authentication (my friends trust this, so I will too) and content-sharing without conflict of interest.
Getting back to the original post, I’m not saying that possibility isn’t there, but I don’t see the big players thinking about this problem in this way.
Thoughts?
Is the sorry state of American education actually good for software innovation?
Jul 12, ’11
11:22 PM
The following is a bit in the realm of pointless mind games and Devil’s Advocate, so grain of salt applies.
It struck me that America’s currently abhorrent state of education may, in an odd, counterproductive way actually be helping to fuel software innovation. Imagine you’re a smart student being put through the low-expectations, rote-memorization wringer that is America’s current state of public education. In other words, you’re bored senseless and completely unchallenged in school. Yet, you possess a curious mind and enjoy learning and figuring out how things work and making things that do things.
So what do you do? Well, you turn to the Internet of course. And sure, there’s Facebook and porn and sexting and reddit and political flamewars. But there’s also Wikipedia and open source software and entire datacenters of videos and blog posts about how to do things and how they work.
And you get curious and start fiddling with some of this stuff and then you start making things. And the things you make, do things. Maybe they even do useful things. And so you share them and discover that other people, even if its only one or two, find the stuff you made useful.
And suddenly you’re hooked. Now you want to make even more useful and complex and interesting things.
So, the question is: does this happen if you aren’t bored senseless at school? At some level, absolutely this question is completely irrelevant beyond the individual. But at the same time access to good programming education, fast Internet and computing equipment is no longer primarily an American or even Euro perk. We’re seeing good software and startups from all over the world.
Despite all this, there is a distinctly cultural “thing” to American software innovation. There’s a drive and passion that is more prevalent here. I’m not saying it doesn’t exist elsewhere, it absolutely does, I’m saying that this is at a critical mass in America that you don’t really see anywhere else and it irks me as to why.
I’m really not trying to be a rah rah American here (I’m attributing this on our crap education!), I think our country is a mess. But the one thing that’s undeniably working is our leadership in software innovation and I find it a curiosity that exists in spite of all our other problems.
And, of course, the easy counter to this entire argument is the volume of great stuff that comes out of Stanford, MIT and elsewhere. But there are also an awful lot of really good developers who never bothered with, or dropped out of school. And there are an awful lot of CS grads who are crap developers and even worse innovators.
GOP debt ceiling strategy: How to be greedy, stupid and crazy all at once
Jul 12, ’11
12:26 PM
I’ve been struggling to put into words just how upsetting the GOP’s debt ceiling strategy really is and I think it has to be broken down into three categories:
1. It’s insanely greedy. Refusing to raise taxes on the rich while insisting on cuts to things like social services and college loans is just baldfaced class warfare. America is already too oligarchic, but these negotiating demands are a small step for Boehner and a giant leap for neofeudalism.
2. It’s stupid. It’s just dumb. I don’t know how else to say it. The economics they’re arguing make no sense whatsoever and even setting that aside, only 1 in 5 Americans agrees with their strategy.
3. Finally, let’s just say it: it’s fucking crazy. You’re going to risk sending the world economy into a depression over some tax hikes on the rich??? Really?!?!?! That’s like poisoning an entire city’s drinking water cause you got a parking ticket.
A few great things to read on REST (technical)
Jun 28, ’11
5:21 PM
I’m not sure how I missed this post by Jacob Kaplan-Moss, where he’s throwing the kind of REST question out there that has, in the past kept me thinking for hours:
It seems like URIs like /people/{my-uid}/photos and /people/{my-uid}/photos/{photo-id} are more “pure.” But now that’s weird because only one single user ever has access to a given URI (e.g only user #7 gets to access the entire space under /people/7). And the information in the URI is redundant with the information in the Authorization header.
Then things get really interesting in the comments, with links to two great posts (which I also missed):
The last constraint is incredibly simple, but nobody actually does it. It’s named Hypertext As The Engine Of Application State. I still haven’t decided how to pronounce the acronym, I always try to say “Hate ee ohs,” which sounds like a breakfast cereal. Anyway, let’s break this down. We’re using Hypertext, fine, that makes sense. But what’s it mean to be an engine? And application state?
…
Now, when I said ‘nobody’ does this, what I meant was ‘for APIs.’ This is exactly how the Web works. Think about it. You start off on the homepage. That’s the only URL you have to know. From there, a bunch of links point you towards each state that you can reach from there. People would consider it ludicrous if they had to remember a dozen URLs to navigate a website, so why do we expect the consumers of our APIs to do so as well?
Haters gonna HATEOAS
Finally, comes an elegant, much more RESTful solution to the API version dilemma:
You can simply define a new media type – say
application/vnd.mycompany.myapp-v2+xml– and associate new multi-email format with it. Clients can then request whichever format they want. Older clients don’t know the new media type so they get served the older single email format.…
Newer clients do know the new media type so they can have access to the new functionality.
VERSIONING REST WEB SERVICES
All three of these posts/discussions are worth reading, but if you only read one, read Steve Klabnik’s HATEOAS post.