Categories

Category web

Entries 23 Total

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.

Comments

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.

Comments

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:

Python logging tutorial | Pingbacks.

Comments

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:

  1. A user connects to an Internet service (through a browser, mobile app, desktop app, anything).
  2. A hashed key is provided to the service along with that request. The hash initially blinds the service from the user’s identity.
  3. The service sends the hash off to a third party.
  4. 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?…”
  5. 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.
  6. 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:

  1. 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.
  2. 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.
  3. 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?

Comments

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.

Comments

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.

http://www.jacobian.org/writing/rest-wankery-question/

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 – sayapplication/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.

Comments

How to keep your software awesome

Jun 1, ’11 5:34 PM

tl;dr: Fix bugs quickly, write features and core slowly, use github. Or just scroll through the graphs.

We’re either at, or past, my 30 year anniversary (I was a kid, can’t remember okay?) of either using, writing or managing software. I have over those years, developed some impressions and, ahem, opinions. What follows is a framework for thinking about a piece of software’s awesomeness.

For the purposes of this post we’re going to define “awesomeness” as a very general sense of “useful quality,” meaning a qualitative appraisal of the overall balance of usability, utility, and bugginess. This is inherently a qualitative analysis, but I’m making extensive use of graphs for the purpose of providing a framework for visualizing and thinking about where a particular piece of software sits on the Awesomeness Curve.

So, what does the Awesomeness Curve look like?

This is a graph mapping software quality and usefulness over time

Essentially, we have the green area, which is early (or beta) software that is interesting and gaining users who are most likely early adopters and more likely to be adept at finding and utilizing working arounds for bugs or missing features.

The blue area represents software which has enough features to make it really useful, has few enough bugs to not make you want to toss your computer out the window and (hopefully) has large user-adoption and/or sales.

The red area is where you don’t want to be: bloatware. This is software that’s got more features than any one user could ever find, much less make use of. It’s most likely also slow because it’s trying to do more than it’s original design ever intended. Finally, software in the red zone is quite possibly even buggier than it was when it was the green zone. Simple things that used to work perfectly now suddenly cause it to crash or get slow in the latest version.

So, now that we’ve got our framework, let’s look at some examples. You may very well completely disagree with my assessments of one or more of these. That’s fine, this is a framework to think about software and guide its management. It’s okay to want to place particular software products or versions in different places. This is a qualitative framework.

Graphing how awesome the current versions of various software packages are, as of May 2011

It’s clear in the above that I am a big fan of Github and Etsy and not so much of Facebook and MS Office. Why?

Github and Etsy both have stable, extremely useful offerings for their audiences. Sure, they are not perfect but when I ask myself “what software do I think is the most awesome?” they are both at or near the top. Their bugs and/or outages are tolerably rare, their UI quirks are not impenetrable and, certainly in the case of github, I spend a good portion of my day using their software without any issues.

On the flipside would be something like Facebook, which I use every day and sometimes it works right… sometimes not. But it certainly always confuses and annoys me and it’s utility has decreased dramatically over time. It went from “oh wow, there’s such and such from jr high!” to “oh, someone I haven’t talked to in 20 years sent me a virtual tree.” Having said that, Facebook does, if nothing else, constantly – and without any warning I might add – evolve. For example, there is finally a My Apps button on the developer site so I know longer have to search Google (I literally used to do this) to find the FB apps I have created.

And then there’s Microsoft Office. Oh Office, you’ve changed so much and yet… so little over the years. Office, and Outlook in particular, may be on its way to becoming “the” case study on how to feature creep or uselessly revise software to death. Sure, there are worse offenders, but are there worse offenders that have so much market adoption? How many features in MS Office do you use that didn’t exist in say… 1998? Of those new features, how many do you think work well? How many things that used to be simple make you want to punch your monitor? And the interface changes! It’s like Microsoft is saying “Pay us to learn our confusing new interface!”

Okay, enough Office bashing, next up is another favorite target of mine: Photoshop.

Photoshop

When I first discovered Photoshop in college (circa 3.0 or 3.05) I thought it was the single most awesomely impressive software I had ever encountered (until Quake anyway, but that’s another story). Nowadays, it is the bane of my existence every time I have to open it. My copy of CS3 is so buggy it has never stayed open long enough for my preferences to actually get saved. Think about that. I have literally never closed the app, it has always crashed first. Which, of course, is compounding madness, since I then have to reset all the preferences (yes, I could just close it now, that’s not the point, the point is it crashes a LOT). I know a lot of web developers and designers and nearly all of them feel the same way: their old swiss-army-knife of web design started going horribly wrong around the “creative suite” change and has only gotten worse since.

Enough whining, let’s talk about what this all means and what we can do about keeping our software awesome.

I am making the argument that this is the natural evolution of a piece of software: In the same sense that Information Wants to be Free, I am arguing that Software Wants to Become Bloatware. As soon as software becomes interesting and useful it gets pulled in a lot more directions: Customers and users want features, investors want constant growth and sales, and developer turnover occurs.

If this is the natural state of things, then what is to be done besides just letting software die once it gets into the red zone? Well, that is “a” solution. And an important solution to note, because just as software can die in the red zone, it can also be killed when it’s in the red zone. The best example of this, of course, is the Friendster > MySpace > Facebook progression. Both Friendster and MySpace sped over the Awesome Curve into the red zone as fast as they could and got blown away by something better.

Happily, this is not the only way to combat the crapware trend. The simplest way is the self-reboot (or “software suicide reincarnation” if you want to stick with the metaphor). This is essentially what Steve Jobs did with Mac OS when he returned to Apple and, unlike with Office, this is essentially what Microsoft did with Windows recently. Let’s look at Windows, up and to, Vista:

You can make your arguments about where XP should fall on the curve, but only the most diehard MS’ folks will try to defend Vista. In fact, many people would argue that Vista was way down the page in the negative.

But, Microsoft fixed a lot of that with Windows 7:

They restarted their curve in such a way that Vista could be thought of as being Win7′s “green” precursor. This is the most simple and obvious way to avoid software death. I would argue that it is also, the least appealing. For one thing, it’s a bit like amputation: You’re taking a big risk to save the organism, but if you wait too long it might end up dying anyway.

So what’s better? Essentially you want to make the Awesomeness Curve smaller, both vertically and horizontally. Once you’re in the blue zone, you want to be jumping to the next green zone before you can get anywhere near the red. You also want those (now smaller) bumps to be over shorter intervals of time.

Ideal for awesomeness, more bumps that are shorter

How do you accomplish this? First, the four principles:

1: Resist new features.

There’s a whole school of thought that quantity of features is directly proportional to what you can charge for software. While clearly this is true in practice, that doesn’t mean that it’s not incredibly stupid. Every new feature makes your software more complex to use. If that lets you sell “training” then well, kudos to your current quarterly revenue, but somewhere along the way somebody is going to come out with a competitor product that’s easier to use and you’re going to find yourself in that red zone. And never, ever, ever impose a new feature on your entire user base because one big customer asked for it (more on this later).

I always feel like Apple’s new software presentations are campy and simplistic and, well, they are but they say something important about the company’s priorities. If Steve Jobs is bothering to walk you through seemingly simple features, that means they thought really long and hard about what features they were including and they “got rid of the crap.”

The one big exception to this rule is if many of your users are making the same complaint about something missing. I’m looking at you, lack of “Mark as Read” on the iPhone.

2. Attack bugs and slow performance like you are eradicating smallpox.

Per the above, if a new feature is taking priority over problems for your users, then your software is speeding its way into the red zone like a bad TV police chase.

3. Roll out changes fast.

There isn’t a whole lot of point in fixing bugs if you aren’t getting them to your users quickly and in the least intrusive way possible. Also: if you’re holding fixes hostage so you can “sell upgrades” with new features, I hate you.

4. Put yourself in a position to gather and measure as much data as you can.

Does anyone ever use feature X? If this button color is changed, do more people click on it? Can you, currently, answer these types of questions?

Okay, but how do I accomplish this?

First of all, the same formula isn’t going to work for every piece of software or organization. You simply have to experiment and tweak and tailor to your own needs and technology stack. Having said that, here are the seven practices I have found work pretty well:

1. Use an open source model

Even if your software isn’t licensed as open source, there’s no reason why you can’t follow the same open practices internally. Essentially this means having a really open and transparent process with good, integrated tools. It also means that your process should never, ever get in the way of someone wanting to make your software better. Do they have to ask permission or get approval to fix a bug? Really? Do they have to justify and sell their idea to you even if they’re willing to work on it in their own time? If the answer to any of these questions is “yes” then your process is working against, rather than for, your software. (Note: if you don’t trust your team at this level than either you shouldn’t have hired them or You Need to Let Go).

This essentially means making it as easy as possible for your team to check out, fork, commit, and do pull requests, as possible. If your software is complicated to run, this means keeping your docs and wikis up-to-date. If you fall under any kind of regulation, make it clear to your developers that they have to open a Bug Report/Issue and reference it in the code commit.

The other big advantage is that if you use your source control management well, you’re actively making multiple Awesome Curves that are running in parallel, so hopefully your users are only seeing the peaks.

2. Make your software extensible.

How do you resist writing a new feature for that customer who represents 20% of your sales but .5% of your installed base? You make your software extensible or modular. If your software is built to support this customization then you can simply write this feature just for this customer. But even better than that, you’ve enabled anyone to tailor your software to their needs. You have to set the ground rules and find ways to encourage good contributions, but you’re still better off working this way. An example of too much restriction is probably the iOS App Store. Too little restriction and modularization? Probably something like Drupal.

For websites, this means writing an API and client software. See any of Foursquare, Instagram, Twitter, etc.

If you’re really clever, you take the best of your module/component ecosphere and just absorb them into your main product. It’s like an achievement: “our feature was so useful, they bought us and made our feature part of the main software!” (Note that this is not dissimilar to the forking/pull request model in open source software.)

3. If at all possible, use interpreted languages

This point could be rewritten as “try not to use anything that’s compiled, built, or otherwise bottled up in a black box.” Obviously this isn’t an option for say, PC games, but it certainly is for websites and even lite desktop apps. If you do have to distribute compiled code, try to make use of app store type models such as Steam or Apple’s app stores. These models let the “store” handle the updating automatically and unobtrusively. Bouncing an icon on your user’s desktop every time they open your app is NOT unobtrusive. Obviously there are rare cases, but the point is that they should be rare, not every time the user opens the app. They’re trying to use your software for crying out loud, get out of their way!

On the web, you’re simply going to have more flexibility using Ruby or Python or PHP than you will having to say, put together a WAR, deploy it and pray. It’s 2011, the performance differences aren’t even worth discussing. Nearly everything has been shown to be scalable in some way or another. The value of those CPU cycles is pennies compared to the Ben Franklins of keeping your users happy.

Note that a lot of compiled programs make use of interpreted languages to manage or direct their compiled code. EVE Online and Firaxis’ games both make extensive use of Python to make easy, fast changes to gameplay (like changing an opponent’s hit points or something) that don’t have to involve say, the 3D rendering. This model can be, and has been, applied to the web world by writing core business logic in say, Scala and letting PHP or Django handle the actual web UI.

4. Stay focused on your stuff under the hood

If some core piece of your software is causing a lot of problems – either it’s causing bugs or making it hard to add (one of those that you thought long and hard about) features – then rewrite it! “But it’s stable, I don’t want to mess with it!” you say. To which I say, “okay, well it’s going to get worse, so you may as well minimize the pain by dealing with it now.”

One of the bigger design mistakes I have made in my career was using XML for a layout engine, essentially because the app was written in Java and everyone said “use XML!”. I think I can say, quite definitively, that the app was slower, buggier and MORE difficult to change in the future than if we had just used tables or even some kind of custom persistence object. Tons of time that should have been spent on cleaning up UI instead got spent on debugging and fixing moronic problems cross-platform parsing problems.

This type of work isn’t sexy for business owners or your sales force, but it still makes your product a lot better. Never lose sight of the fact that responsiveness and stability are every bit as much a part of your user experience as whether you used the glossy or the flat buttons.

5. Experiment

This may sound contrary to the “resist features” principle, but it’s actually not. You don’t want to resist trying features. You want to resist rolling every single one of those features out to your entire user base. You want to encourage your team to try new features and roll them out internally or to small user sets. This lets you test and experiment more and spend less time arguing about features in meetings.

The idea here is to try features quickly with small groups (or even just yourself) so you can rapidly identify and drop features that aren’t useful enough and spend lots of time awesomifying the ones that are, well, awesome. There are now “feature management” packages for most of the popular web frameworks. Pick one and use it.

6. Custom measurement and analytics

I really defer to Etsy on this. They do it really well and they’re happy to share how they do it.

7. Easy deploys

This only really applies to websites. Desktop software is its own world.

You want to make it as insanely easy and consistent to deploy code to production as possible. Last summer and fall, working on the Gardner Nelson + Partners website, we were deploying new code 10-20 times a day. That rapidly tapered off since the site isn’t that interactive (it’s essentially just a marketing site), but I wouldn’t hesitate to do that many deploys to the site if it had discussion or voting or some other high usage feature.

None of the tools out there are, as yet, perfect, but they’re a lot further along than Zip Up, FTP, Unzip, Cross Fingers. Look at things like Fabric or Capistrano or just role your own.

Deploy tools will help you with speed, but they won’t necessarily help you with consistency and predictability. For that, you want to run VMs locally. With the power of the modern desktop computer, you can replicate most production environments locally by running multiple Virtual Machines. The only things you should really need to change are CNAMES (locally via /etc/hosts) and mounting a drive to your dev workspace.

I hope this helps you think about your software, where on the Awesome Curve it lives as of today, and how to keep it in the Awesome zone.

Disagree? Did I make a factual mistake? Let me know in the comments!

Comments

Offline Identity is Broken Too

May 9, ’11 6:49 PM

I witnessed an interaction at the pharmacy today:

Pharmacist: Did your insurance change?

Patient: Yes.

Pharmacist: Can I have the card?

Patient: I’ve been coming here for 20 years, you can’t look it up?

Pharmacist: Nope, sorry

At first glance, well of course he needs the second card. But at second glance, the patient is right. We have the Internet. We spend way more money than anyone else on healthcare. And we can’t figure out how to notify his pharmacy of new insurance without resorting to plastic cards with numbers on them? Really?

Cause you know what makes something official: plastic cards.

Comments

Dear Apple and Google, Please Fix…

May 9, ’11 12:27 PM

A long overdue return to technical stuff…

If you use Google Analytics and actually look at your visitor data, you will be familiar with this phenomenon, which is the reported Safari browser version in GA:

Safari versions in Google Analytics

Those are in fact, not Safari version numbers, but WebKit version numbers. Now, you might just be saying, “oh, stop whining, you can just correlate those!”

But, in fact, you would be wrong: For example, the WebKit version 533.17.8 is used in both Safari 4.1 and 5.0.1. For my purposes, this is not the end of the world as I tend to care more about the WebKit version than the browser version.

However, I do occasionally need to explain these numbers to like… clients, in which case, the above sucks. And it’s been broken for awhile. People have posted up various filters and such that you can use to improve the situation, but seriously, that’s an epic waste of time, so I’m whining about it on teh interwebs.

Comments

Hammurabi was the first programmer

Mar 9, ’11 1:34 PM

Or someone working for him was. I was having dinner last night with my cousin (an SAP consultant) and we covered a range of topics, including lobbying and programming languages. And it struck us that laws are essentially programs.

Prologue of Hammurabi's Code, in the Louvre

Either you’ve already heard this analogy or you might be going “what??!?!” But it’s true. Laws and programs are both essentially linguistic expressions of applied logic: rules and processes, codified.

A program is a law, the data is a case, and the computer is a very, very strict judge. The computer really doesn’t care about intent, it’s going to do exactly what the program says.

So, we can think of Hammurabi’s Code (even the word’s the same!) as saying stuff like this:

if convict.crimes.theft == True:
convict.hand.delete()

Of course there are differences and laws are at a bit of a disadvantage when it comes to version control and testing, but as a way for non-programmers to think of programming, you could do a lot worse than thinking of it as very strict laws.

Comments