Observe!

Details later. For now, sleep.

If you go to the website, you’ll notice that in the pictures of the product, this monstrous beast of a pillow-chair-thing has straps on the corners which snap together, allowing you to make it form into a chair. This is why I’d chosen this product. The versatility of having a crash pillow that turns into a chair, that can be picked up and chucked in a closet when not in use (so as to free up room), so that you can optimize for space or seating in the living room on the fly depending on how many people are over. This is what made the Sumo Omni Plus a theoretical masterpeice- All the reviews I read touted those straps as the killer feature, the thing that really set it apart from the regular omni. But what I received in the mail wasn’t that masterpeice. Instead, I got what amounts to a giant freakin’ pillow. Not that it isn’t an AWESOME pillow. It’s still comfortable (even though the foam inside hasn’t finished expanding/settling- it’s been less than 24 hours), and you can flip it on it’s side and sit on it in a comfortable, slightly goofy fashion.

After going over all the packaging twice to make sure that it wasn’t simply an external set of straps that I’d tossed aside accidentally, I called customer support this morning, and was pretty surprised to hear their explanation.

“The new model doesn’t come with straps.”

Excuse me? So I basically just paid 50 bucks more for a regular Omni, only a little smaller and with a microsuade cover instead of rip-proof nylon? The pictures on the website were still the model with straps. This is where I honestly started to feel gipped, as we were pretty much matching the definition of “not as advertised”. The next words out of my mouth were, as a software developer, words I never thought I’d ask. “Can I exchange it for the older version, then?” She said that the old version was sold out, but that she’d check with shipping to see if they had any left, and call me back. I specified that I didn’t actually need them to send me a full new Omni Plus- I only wanted a new cover, the one that came with straps.

I suppose, worst-case scenario, I can just exchange it for a Gamer instead. Since the primary role is going to be as a chair and not a pillow, this seems like the logical substitute (also since it’s the exact same price). However, I’m a little worried about the return policy, which states that returns must be pre-approved by the Customer Service Department (is “I was expecting your older model, not the new one where you took away the feature I most cared about”), not to mention instructions, which state that all returns must be made in original packaging. This is a problem because the original packaging was vacuum-sealed, and the exposure to air has ballooned the end product into something much larger than one could ever hope to fit back into the box without the proper machinery. To give you an idea, here’s a picture of the Omni, standing next to the box it was shipped in.

At the very least, I think they need to update the pictures on the website, and throw an article into their “news” section that specifies the change to the omni. I have no idea what else is different in the “new version” of the omni plus- God knows why they removed those straps, but having done so they at least have a responsibility to not advertise something with more features than what they’re actually providing. As for sumo customers out there- I’d ignore the omni plus until this gets addressed. If what you want is primarily a crash mat, rock the straight Omni and save yourself 50 bucks. If you want something that’ll primarily be used as a chair, you should probably lean toward the “gamer” model.

Still waiting on a response from customer service as to whether I can get the old cover, straps attached, that actually makes it worthy of the “Plus” moniker, or not. I’ll let you know how that turns out.

-Alex

We all know the internet is full of dumbasses. Newsflash, you’re one of them. Being smart isn’t enough to set you apart around here. Welcome to the party.

You type “M$” when referring to Microsoft.

Congratulations, you’re against the establishment! Way to be a rebel, just like everyone else. Showing contempt for a company that charges you for use of their hard work is kind of ridiculous, so if you’re a consumer, you’re being lame. If you’re a linux hacker, you’ve got a leg to stand on, but you’ve also got a day job where they pay your salary by charging other people money. And if you’re an Apple user, then, let’s face it, you’re being an epic hypocrite. Before you go off on another rant about how bloated a Microsoft OS is, check out your mac’s price tag.

You make constant references to anything someone with “geek cred” would know, in parantheses, ending in “anyone?” (slashdot/reddit commentors, anyone?)

Often the committer of this particular sin is masking it as an on-topic reference. This is not impressive. But it is annoying. It is especially egregious if you do this during one-on-one conversation.

BTW, I consider this to be Jeff Atwood’s only serious blogging sin. I love that blog, but every time he does that I wince a little, just because I think he’s better than that.

You Namedrop e-famous bloggers like Yegge, Atwood or Spolsky

I just got called out on this one, by a friend who saw point #3. Look, none of us are perfect. That’s why it’s a cliche :D

You’ve actually answered a “How do I do (this) in (this environment)?” question with “switch to (my environment of choice)”.

This one is pretty generic. So, examples!

Q: How do I do (x) in PHP?
A: Switch to Rails (In the history of the internet, the person who asked this one has never once gone “I talked to my boss, and convinced him you were right! We’re scrapping 3 years of development to switch to a language/framework none of us know, on your say-so! Everyone’s cool with it! Hooray!”)

Q: How do I do (x) in Windows?
A: Switch to *nix (Because there’s no way the learning curve is going to become a bigger issue than the original problem, right?)
Alternate A: Switch to Mac (Often, in this case, the real answer in windows is to right click on something. HA! I’m mostly kidding, though I’ve witnessed it in the wild)
Non-existent A: Worth mentioning, I’ve never seen anyone say “switch to windows” when asked the question in linux or apple forums. You can interpret that any way you want, but I think it’s at least partially because the reaction of a windows user is something along the lines of “I don’t know. I’m a windows user.”

Q: How do I make my ford truck stop making this noise?
A: Switch to Chevy
I’m not a car guy, but from I understand, in certain parts of the country, saying this out loud is a really bad idea. Ah, the anonymizing power of the interwebs.

We’re all guilty of something. Be it namedropping, inappropriate evangalizing, self-important rambling (Yeah, I’m talking to you!), none of us are perfect. But I think a goal we can all agree on, an ideal we should continue to strive for, is this.

Don’t be that guy

-Alex

I can only speak to Photo-related web services, as that would be the area where I have the most experience. But I think most web services “get it” with regards to an API- By publishing an API, and enabling and encouraging developers to interact with your webservice, you’ve effectively given yourself a dev team larger than you could ever hope to afford. Users passionate about your services, with ideas on how to extend and improve it, and the know-how to implement those great ideas. More applications related to your website means more ways for users to interact with it, which means more chance of a “killer feature” written by a user of your service that ends up driving thousands of new users to you, any one of which can be a developer that continues the cycle. It’s an upward spiral.

But it takes more than just publishing an API. You have to make your developers WANT to write stuff for your service. Make it easy and enjoyable for them, and remove as many roadblocks and speedbumps as you possibly can so that they can complete their brilliant idea before throwing up their hands in frustration, or slowly, quietly losing motivation amidst a sea of vicious bugs, counter-intuitive behavior and documentation that either looks like it was written by Hemingway or run through babelfish.

Given my relative experience in dealing with API’s en masse, I decided to compile a checklist for being developer-friendly. Some of it is necessary. Some of it is more along the lines of “helpful”. Some of it is just wishful thinking. But these steps will help you tenfold.

Let developers know your API exists

Publish a listing for your API on Programmable Web, effectively giving the internet a cheat-sheet for your API- Protocols (soap, json, etc), documentation links, fee information (free non-commercial, pay commercial?), 1st and 3rd party libraries. You’ll get legions of volunteer devs through this site, who might not have even known your service existed. Also, a “developers” link in the footer of your website is like gold. It should link to a page providing the basic information: API Sign-up process, documentation, etc. I don’t want to go trolling through support documentation or chat live with a customer service rep. Just let me hit the ground running.

The developer section of your site should be more than a couple pages. It should be a microsite.

In no particular order, this should include most (if not all) of:

• developer forums
• some of your own developers monitoring and answering questions in the forums
• API documentation
• links to working third-party applications that use your API, or third-party libraries that access it
• API news and updates, blog-style
• a “My Profile” section showing me my own API keys, stored app descriptions and (unusual, but I consider this a bonus) usage statistics.

Don’t half-ass your API

AOL Pictures API was little more than “Look at us, we have an API!” lipservice. There’s no way to programmatically log-in and access private pictures, there’s no way to upload via the API, and the system for returning information about those pictures was unintuitive bordering on useless. The API should be a programmatic reflection of what your web service is capable of. On the complete opposite end of the spectrum from AOL, Flickr has an AMAZINGLY comprehensive API. You can fine-tune not only what data, but how much of it you want returned. You could practically create a flickr clone using the flickr API as a backend. (Disclaimer: Morally and legally, that’s a really bad idea.) Another bonus-points case: Kristopher Tate (of Zooomr fame) once told me that the Zooomr website was a display layer built on top of the API. I’m not asking you to do that, it’s a decision you have to make. But we know for a fact that, in this case, it’s well-tested:D It’s also based off the Flickr API, which means it’s super-easy to modify a Flickr app to make it Zooomr-compatible.

Another point, try to provide a few different options in terms of protocol. At least two of SOAP, JSON, or straight-up REST. Recently I came across an API that’s accessed via SOAP, but doesn’t provide a WSDL file. That’s cruel. I mean it, it gives me the distinct impression they dislike me personally:P Seriously, though, different languages a way of making different protocols easier/harder. Giving the option of parsing XML vs JSON, or providing a WSDL file and letting a code generator handle all that for you (a serious perk of client development in .NET) makes your API more language-agnostic and universally accessible. To summarize, the API should be stable, complete, flexible, and not counter-intuitive.

API Documentation: People actually read it.

Again, Flickr comes to mind as a shining example. Every method you call via their API has documented behavior on whether it needs the user to be authenticated, parameters, example of the response sent from the server, and possible error codes. There should be a TOC of methods split up by category (for example: photos, albums, user groups, friend list, authentication) so I can quickly and easily hone in on exactly what I’m looking for. Provide links to every third-party library that someone has written for accessing your service in a particular language.

Provide tutorials and walkthroughs, and if a third-party dev writes one too, link to that. Throw in some sample code in a few popular languages (Java, c#, python, ruby, perl) so people know what the code should look like. You don’t have to do this for every method. I’d recommend doing this for the authentication step, as developers will be able to test this without getting anything else right first. The net idea is that I should be able to get rocking with your API as soon as possible in the language of my choice, provided it’s a relatively common language (I don’t expect there to be a “Flickr Haskell Library”, for instance. But I do expect a Java one). Good documentation means your dev forums will be manageable.

Dev Accounts

I’m a little biased on this one, given that I interact with so many different webservices. But of all the services I use, most have “pro” accounts that I need to be able to test against. Some sites (major props to SmugMug and Zenfolio) comp pro accounts to developers who have written software that interacts with their services, as a matter of practice. Others will give the developer a one-year coupon upon request, while others don’t give us anything at all. Software is going to need testing, and if I run into a free-account limit for uploading data to your webservice while testing my software, I’m either going to have to cough up money for the right to add value to your service, go through the lengthy process of clogging your database with test accounts, or wait a month until I can do more testing. These are all roadblocks. I’m trying to write something your users will appreciate. Please don’t leave me hanging like this!

One thing that I would *like* to see, that I haven’t yet, is a special developer account- Not just a comped pro account, but a user account specific to developers. This account could have behavior specific to testing my software, like

• API-Accessible switch between account types, like “free”,”standard”,”pro”,”super-mega-expensive-awesome-pro-account-of-extreme-justice”, in terms of toggling things like upload/download limitation that vary from account to account, to reproduce errors my users are seeing and test for different errors that might come up
• None of the things I do via the API show up in “Latest activity” bar on front of site. If I’m running tests, it would be good etiquette for me to be able to avoid what could be considered spamming
• 24-hour deletes or auto-rollbacks: If it’s a test account, It’d be nice for me to be able to keep the account empty when I’m done testing, without writing housekeeping code on my end that just deletes everything. This means I’m trying to take up less space on your servers. I’m not saying this should be automatic, just we’d both be happier if I had the option.

Sites that don’t hand out free pro accounts to developers could offer these up instead, and just cripple the accounts in ways that would only matter to an active user: the 24 hour deletes could be mandatory, all data posted on a social site could be kept private and not visible to the community, etc. The main point here is that while I totally dig on the incentives provided by the services whose API’s I interact with, it’s more important that I be able to test my software against theirs, fully and comprehensively.

All this really matters, and so do your developer-users

I know it sounds pretentious and self-important when I say that as a third-party developer, I’m adding value to your service just by coding something against your API, and thus you should make things as easy for me as possible. Like I’m the kind of guy who always types “M$” when I mean Microsoft, or leaves obscure, nerdy references in parentheses followed by “anyone?” (Slashdot/Reddit commenters, anyone?). But I swear I’m not being that guy. I’m basing the idea that I’m adding value (or, in the case that I suck, the idea that someone else is adding value) off of the services I’ve seen flourish, and the ones I’ve seen wither and die.

Yahoo Photos and AOL Pictures: Half-assed API (Yahoo’s was even web-only, so you couldn’t write a desktop application for it). Both deadpooled.

Imagestation and Epson Photos: No API. Both Deadpooled.

Flickr, SmugMug, Zenfolio, Phanfare, PicassaWeb: Comprehensive, well-documented API’s with active developer communities, responsive staff and a wealth of resources for helping you get stuff done. Thriving.

In summation, in the words of Jerry McGuire, “Help me help you.”

Come on. I had to say it. You know I did.

-Alex

Sorry for the lack of updates lately. I’ve been plugging away, but sometimes it’s hard to get to a stopping point where I can say “this is ready for release”. Will prob. have something up before the end of the year. And, as a sidenote / friendly reminder, AOL Pictures closes on Dec. 31, so all you who use that service have just under a month to get your pictures and get out:)

-Alex

return reduce(lambda l, r: l + seperator + r, (str(s) for s in values))

While I’m not going to claim to be some sort of industry expert on the subject, and there are probably wikipedia entries and blog posts and Knuthian essays I haven’t read on the subject, this is pretty easily the most simple, elegant fencepost solution I’ve ever seen in my life. There are no special cases, boundary case handling, seeding (ie, initialize the final string to the first element, then start the loop at the second). It’s flexible, straightforward, relatively easy to understand to someone with a sufficient familiarity of lambdas. It just does its thing and disappears.

And then it occurred to me, since lambdas had been brought to c#, that this was suddenly within my power to accomplish as well.

I had certain goals in mind, as the snippet provided to me had set a serious benchmark. I wanted it to be as general and flexible as possible- It shouldn’t take only arrays, or only lists. You should be able to throw any sort of collection at it that you want. You also shouldn’t be restricted to only sending it Strings- Might as well make it possible to send it a collection of numbers, or people, or pretty much anything you want. This was more of a “hey, while we’re at it.” Feature creep, I know, I know. But it’s my exercise, and I’ll rock it as I see fit:D

Next, I wanted it to be as simple, elegant, and straightforward as possible. To me, the most significant thing about the snippet was, as stated above, that there was no special case code, and no seeding. You can develop an inferiority complex trying to make c# code as elegant as python code, because c# is a more verbose language. It just requires you to be much more explicit about everything than python does- Especially when it comes to LINQ and collections. Brackets, parentheses and curly braces everywhere. Still, I felt a degree of elegance was possible, and I was determined to find it. What can I say, I was bored, have had minimal exposure to functional programming, and the idea intrigued me…

Here’s what I came up with.

public static String fencepost(IEnumerable values, String seperator)
{
    IEnumerable<String> strings = values.Cast<Object>().Select(x => x.ToString());
    return strings.Aggregate((x, y) => x + seperator + y);
}

By way of explanation, LINQ is more an attempt at emulating SQL than functional programming. So the rough FP -> .NET corollaries are “Map” -> “Select”, “Reduce” -> “Aggregate”. Also, as a one liner it got way too complex to really be readable, so I split it up into two- The first line creates a typed Enumerable of type String from a typed or untyped collection, for the second line to work with.

I also somewhat bundled up the whole thing as a full method, which you can copy-paste somewhere and call whenever you need it, choosing your seperator token on the fly (comma, period, space, whatever). If, on the other hand, an in-line snippet is more your style, here’s a very straightforward one-liner (that assumes you have a typed collection)

  string seperator = ","; //Or whatever else you want to use
  string result = (String)foo.Aggregate((x, y) => x.ToString() + seperator + y.ToString());

Not quite as zen-like as the python version, but it has it’s own strongly-typed schwerve to it. I consider this “Garage Sale” code- Not really complicated enough to license it, so just copy/paste to your heart’s content. Enjoy:)

-Alex

LOC As A Metric of Accomplishment or Project Size

This one is old, and most experienced programmers now officially reject it outright. But still, I feel it worth repeating: The number of LOC you write in a single day is worthless as a metric of what you accomplished that day. After all- If someone wrote a 1000 line class in a single day, and you wrote the same class in 500 lines (and maybe tossed in a little extra functionality while you were at it), who was more productive?

As a metric of project size, it makes a little more sense, but just barely- The Wikipedia article on LOC mentions that “Many useful comparisons involve only the order of magnitude of lines of code in a project.” That at least makes a little sense. One can reasonably assume that the same set of programmers, using the same language, will be able to accomplish more with 10000 lines of code than with 1000.

Ambiguity: Too Many Ways To Count

The next issue is this: How do you COUNT lines of code? That same Wikipedia article linked above has an interesting example:

for (i=0; i < 100; ++i) printf("hello"); /* How many lines of code is this? */

How many lines is that? One for the line? Two for logical seperation of forloop and print statement? What if you wrap the line in curly braces, one on each line, and move the comment to it’s own line, so it looks more like

for (i=0; i < 100; ++i)
{
/* How many lines of code is this? */
printf("hello");
}

Did you see that? I just took one line of code, and turned it into 5! Things get so much more confusing than stylistic issues like this, though. What about libraries? What about frameworks? Jeff Atwood wrote a post a couple of months ago wherein he mentioned that the original version of Basecamp had been written in only 600 lines of code. Given that Basecamp was written using Ruby on Rails, which handles all sorts of crazy things for you, I think the more honest metric would have to be the 600 lines of basecamp, plus however large the RoR framework is, plus the code RoR generated for them when they started the project. Money says it’s more than 600 lines.

I’ll give you another example. Currently, the amount of code I’ve written for Migratr is 5000 lines and change. However, Migratr uses FlickrNet, a popular .NET library for interacting with the Flickr API. FlickrNet, if you download the source, is more than 12,371 lines of code (according to the unix util “wc”). I’ve also incorporated a few other libraries, all of which are linked in Migratr’s “about” page. Why? Because I didn’t want to write those 12,000 lines. Someone already had, and they did a fantastic job of it, and I didn’t see any point in re-inventing the wheel. So the total code involved in Migratr is, at this point, more than 17,000 lines. I’ve written 5,000 of them, and I’m the sole developer of Migratr. But I wouldn’t dream of saying “I built this application that interacts with a whole slew of online photo services and migrates all your photos and does all this neat stuff, and it was only 5,000 lines!” No. MY contribution was 5000 lines, but Migratr depends on a lot more than that.

The point being, where do you draw the line? Is Migratr a 5000+ LOC project? or 17,000+? Do you only count LOC if you have access to the source of the library you’re using? Do you only count the code written for your specific project? Could I export Migratr’s backend as a library and let someone write

public void migrate(String filepath)
{
ImportFromSource(Services.Flickr, filepath);
exportToDestination(Services.SmugMug, filepath);
}

Did you see that? My whole project was just replaced! Some twerp in a garage somewhere just re-wrote Migratr in 5 lines of code! It doesn’t matter that it depended on my 5,000 line library, which depends on (among others) 12,000 lines of the Flickrnet library. You only saw 5 lines. It was only 5 lines.
But clearly, since 5,000 is more than 5, I can at least say that I was more productive.

The relationship between line count and bug count only goes so far

The idea that “Less lines of code mean less bugs” is some sort of universal absolute is the biggest of all the LOC myths. In a desperate effort to nullify your “oh snap, time for a flamewar” reflex, I’m going to add a couple of disclaimers before I get into this. Any reference I make to a programming language is not an attack on that programming language, just an attack on the abuse of that language. Also, I realize that reducing the amount of code required for a specific task can help reduce the bug count, but only so far. I’m saying there’s a limit to this. Here’s the line I want to draw for you.

Reducing the code involved in a task will only help reduce the bug count IF THE PROCESS MAKES THE CODE MORE READABLE. Past that, you’re probably creating lines of code that do more than one thing per line, and thus increasing the number of bugs possible per line of code.

Perl programmers are especially frightening in this regard. I really love PERL and use it instead of shell scripting languages such as BASH whenever possible, but there’s something in the PERL culture that demands it’s programmers to try and do something in the fewest number of characters possible. There’s even a name for this as a sport- It’s referred to as “Perl Golf”.

Really quick, can you tell me what this is?

-pl s!.!y$IVCXL426(-:$XLMCDIVX$dfor$$_.=5x$&*8%29628;$$$_=$_!egfor-4e3..y/iul-}/-$+ /%s''$';*_=eval

I’ll give you a hint- It’s not a cat walking across my keyboard. If that was your first guess, though, we’re at least on the same page. This was the winning entry in a game of Perl Golf: The problem was to write a Roman Numeral Calculator in the fewest characters possible. Submissions can be found here. Now, this is an amazing piece of code. The person who wrote it is clearly very skilled. The fact that Perl makes code like that possible is pretty impressive. The problem here is that people write code like this outside of PERL golf, and think to themselves, “it’s only one line, so it must have fewer bugs than a 50 line solution”. Really? Because if I had to debug one, I’d have definitely gone with the 50 line solution. And don’t tell me that that one line of code worked on the first, second, or 5th try. The 50+ line solutions might have, but not that catwalk.
Writing unmaintanable code does not reduce the bug count for a project. A friend of mine coined a term for code like that- “Write-Only Code”- a takeoff on the permissions you can set with chmod. Think about it: Readable, writeable, and executable. Shouldn’t code be all three?

Another quick example:

(0/:l)(_+_)

The first time I saw this snippet, I thought someone was, via emoticons, trying to re-enact the facial expression one wore when seeing “Goatse” for the first time. It’s not actually a story told by emoticon. It’s a piece of scala code that sums the elements in a list. And I just don’t see it as having been easier to write than a forloop. It’s definitely not as maintainable. This piece of code, actually, prompted a conversation with a friend about holding a “code or emoticon” contest, but we really couldn’t come up with any serious contenders to this one. Maybe some Perl Golfers could throw their hat in the ring?

I want to state too, that for this section, I’m well aware that I didn’t provide buggy one-liners. I provided working one-liners. This is because I was trying to emphasize, the point isn’t if it works or not- The point is if you can tell by looking at it what it should do. If you can’t, it’s unmaintainable. If it’s unmaintanable, then even if it works the first time, it’ll produce a slew of bugs as soon as anyone tries to modify it.

So, in essence- Stop paying attention to Lines of Code. They’re impossible to count in any useful way. They’re a crappy metric of project size or personal accomplishment. And they don’t control how many bugs your code has. You do.

-Alex

Adam: This seems to be common in microsoft tools and APIs.

Alex: With random pitfalls. “I’m sorry, but you’re exactly 2^8 – 1 pounds and the fly is a gemini. Please update your sledgehammer for compatibility.”

Adam: hahah

Adam: yeah

Adam: or worse, “Yeah that’s a known issue, but we’ll have it fixed for the next version and you can buy that.”

Alex: Months later Linus Torvalds posts an essay on his new project, a normal-sized hammer for swatting flies, which can easily be modified for swatting mosquitos, provided the mosquitos astrological sign has a compatible license, therefor sledgehammers are evil.

Adam: There’s also question of whether or not the normal-sized hammer infringes on one or more hammer-related patents, but nobody will talk about what those patents are. Flames fly, large businesses invest in the continued future of the normal-sized hammer. Meanwhile users and developers alike still don’t have what they need: a flyswatter.

Alex: lol

Adam: Bloggers claim the normal-sized hammer isn’t ready for the workshop.

Alex: Usability questions arise. The normal-hammer camp will cry that theirs is a “More lightweight solution”, and while normal users don’t have nearly the level of accuracy required to use it effectively without smashing their thumbs, evangelists will claim that “Well, they just need to bite the bullet and learn to swing a hammer effectively.” The sledgehammer camp will point out the greater surface area and imply that if you can’t swing it, you need to work out more until you have the necessary muscle mass to swing the sledgehammer effectively. At which point, as an added feature, you’ll be able to smash everything around you into oblivion.

Alex: They will also point out that flyswatters do not have this property.

Alex: And, through clever marketing, imply that all walls need smashing, and thus flyswatters simply don’t fulfill the user’s needs.

Adam: Plus, as everyone currently uses sledgehammers, they become frustrated when the normal-sized hammer doesn’t work quite the same way, yet they constantly complain about their sledgehammers holding their hands too much.

Adam: Sledgehammer “power users” are known for circumventing the thumb-smashing protections because they think it makes them work more effectively.

Adam: They complain that the thumb-protections are included at all because they don’t use them and things like that are why the sledgehammer is so bloated.

Alex: Apple will release homes outfitted with mosquito nets. Elitists will smugly claim that the problem has been solved. Both hammer camps will roll their eyes at the idea that buying a new house is the solution to a fly problem

Adam: The mosquito-net houses aren’t compatible with the new sledgehammer addon. Mosquito-net house owners don’t care because they don’t need it, but hammer aficionados continue to cite this incompatibility as a reason why mosquito-net houses are, and always have been toys.

Alex: Eventually a small independant developer releases a flyswatter. Panic-stricken, the sledgehammer company purchases the flyswatter IP from the developer, and adds the flyswatter mesh to the handle of the hammer. Evangelists rejoice, competitors once again roll their eyes. Users wonder what the hell just happened.

Adam: Meanwhile some guy in his basement publishes blueprints of how to build a normal-hammer modification making it compatible with the new sledgehammer accessory. Normal-hammer users rejoice and claim this as a strength of their platform. Sledgehammer users scoff and say, “you have to build it yourself?? Not ready for workshop!”

Adam: Mosquito-net house owners have been in their houses watching fly-free movies this whole time, but nobody listens to those elitist pricks anyway.

Alex: Normal hammer users ask the honest question of how the hammer head flying lose from the handle when swung can possibly be classified as “ready for workshop” in the first place. They are immediately dismissed as trolls

Adam: Because after all, if the hammer head flies loose from the handle you’re clearly an idiot for not knowing that you had to hold the third switch from the bottom with your pinky finger as you swing in order to make the hammer head stay in place.

Adam: Because come on, you’d have to be a total hammer n00b to not know that.

Alex: The normal-hammer camp announces that their hammer has no buttons. The sledgehammer camp cites this as a missing feature

Alex: After all, how do you keep the head on the handle without that button?

Adam: The button by the way is a third-party addon. Usually there’s a trial button shipped with new sledgehammers, but you have to pay a yearly subscription to keep it working right. The sledgehammer manufacturer would include the button to begin with if it weren’t for the fact that the third party would sue for abusing monopoly power.

Adam: Many sledgehammer users in practice don’t know this and continue to use their trial buttons past the expiration date, blaming the sledgehammer manufacturer when the hammer head flies off.

Adam: Sledgehammer power users dismiss them as idiots and say it’s not the sledgehammer’s fault.

Alex: The modding community releases an intriguing solution involving duct tape and industrial strength rubber bands. This leads to the sledgehammer company suing rubber band manufacturers

Alex: The duct tape community, on the other hand, is purchased. A layer of duct tape now covers the flyswatter mesh in the sledgehammer handle, or will once you upgrade to the next version.

Alex: The mosquito net manufacturer, to everyone’s surprise, releases a flyswatter. Unfortunately, you can only use it in a mosquito-net home.

Adam: Someone comes out of the woodwork claiming that he has a patent on wooden handles. The sledgehammer has long used wooden handles and faces a problem. The normal-hammer camp releases instructions the next day about how to replace your wooden handle with a piece of steel pipe from home depot, and all new normal-hammers will use this new method. Normal-hammer users complain that the slick metal gets sweaty and is hard to hold, but these claims are dismissed with, “if you want a hand grip, make it yourself.”

Alex: Everyone, the normal-camp-hammer users decide, either has the proper machining in their garage to make a decent rubber grip, or shouldn’t be using normal-hammers in the first place.

Alex: This is in direct conflict with “Everyone needs to bite the bullet and switch over to normal hammers because they’re free.”

Adam: Somehow normal-hammer users don’t see these two things as being mutually exclusive though and don’t see what the big deal is.

Alex: Cost-analysis by several third parties takes place, as a result of curiosity as to if, at this point, normal hammers are still a cost effective solution.

Alex: Everyone looks to the flyswatters that can only be used in mosquito-netted homes. Crumbling under public pressure, the license is reconsidered. You can now use the flyswatter in non-mosquito-net homes, but only three designated homes per flyswatter.

Adam: Cost analysis is later made even more muddled by the fact that the sledgehammer manufacturer has been selling “upgrade insurance”, promising ‘free’ upgrades to your sledgehammer for the life of the policy. Sledgehammer manufacturer then proceeds to release no new sledgehammer revisions for the life of a policy cycle.

Alex: Mosquito-net-home users rejoice and evangelize this as the perfect solution, because having no social lives (as a tragic side effect of being elitist wankers), they’ve never been to more than three homes.

Alex: Hammer optimization continues.

Or, it would be. I think, soon, it will be. But there are two major hurdles that need to be addressed before OpenID is free to fulfill its potential and change the way we use the internet. And I really mean that. Not in that AJAX way where “change the way we use the internet” meant we could finally stop hitting the refresh button. That was awesome. But that just changed the way we use our _browser_. I’m talking the internet.

ANYWAY: The two things that need amending.

* Sites need to step up and become consumers, not just providers.

* They need to understand the potential of decentralized

It seems like there are more OpenID providers out there than consumers. I think I have 4 at this point. “ClaimID”:http://www.claimid.com gave me one when I signed up for their service, whereas “Livejournal”:http://www.livejournal.com and “AOL”:http://www.aol.com simultaneously decided, “You can use us as your universal identity!”. ClaimID is the only one of the lot that’s a consumer. They’re the weirdest one. You sign up with an OpenID, get your account, and they GIVE you an OpenID. The openid I actually use is hosted “elsewhere”:http://www.myopenid.com and proxied through so I can use this site as my ID. But I can’t use it to login to the aol website. I can’t use it to login to my livejournal account and make posts (though I can set it up as a seperate identity to leave comments). Someday, I’d like to be able to write my posts in livejournal (or, WordPress, which thusfar has the same attitude on being a “consumer”. Etc.

The other major thing. This decentralized identity system, as awesome as it is… has so far been used primarily in a bunch of centralized services. Think how awesome it would be to create a decentralized social network. Have a list of people you know, and how you know them, attached to your OpenID. Then when you register for facebook, or myspace, or Vox, or Orkut, you login with your OpenID. And the service goes to that page, scans for your friend network, spiders a little to make sure the relationship is mutual, and BAM- All the friends who use that service are automatically added as your friends. Of course, some small degree of centralization is required. Myspace, for instance, would have to store how much you trust these people, to determine if they can view your private blog posts, whatever. But by and large, your network exists outside, and the service imports it. Possible. VERY possible. Not yet implemented. “Videntity”:http://www.videntity.org is one service that’s come close. They let you store your relationships with people WITH THEM. And that’s after you sign up for an account. Will they accept OpenID? No. But they’ll give you one.

But that goes against the _style_ of OpenID. You’re supposed to be able to store it where you want. Provide it yourself, or backend the technical side away. If Videntity were to adopt a more “WordPress” attitude towards the whole thing… You know, “Host it yourself. If that’s over your head, we’ll take care of it for ya.”, that would be a vast improvement. If Videntity let you log in to their service with someone else’s OpenID and didn’t try to make you use theirs- Another improvement. If their social network system (which you point out from the inside, but not in from the outside) could interact with other servers according to some api or protocol (Perhaps something more decentralized… But where, were would we find a decentralized authentication system?)… Than that would be perfect. That, that I would use.

If I’m wrong on any of this (As is often the case), please assault me in the comments below. Especially if you know of any services out there which utterly disprove my arguments. I really wouldn’t mind being wrong, here:P

Cheers,

-Alex

Actually, some of you had some really good points, and I’d like to address those. I’m going to combine hear and there, because some of the arguments are related.

_I never defined “better”, better is subjective, and ultimately this is really just my opinion_

This is all absolutely correct. I think I missed the mark on conveying my original intention, which was this: There are a lot of lists out there exactly like mine, but in the opposite direction. I’ve never seen a “top 5 alternatives to open source software” before, and had been noticing an increase in the amount of closed-source-company bashing that takes place, with claims of “buggy”, “bloated”, etc, and then listing, as an alternative, open source applications which were just as bad. It felt like people had stopped looking at the software, and just at the license. Judging the book by it’s cover, if you will. I thought it would be fun to parodize the trend a little bit, while simultaneously getting to play the devil’s advocate and rise to the defense of what I genuinely believe to be quality software.

_OpenOffice isn’t written in Java. Do your homework, you moron._

Okay, nobody called me a moron. Though, still, I kind of felt like one. In my defense, though, it’s a pretty widely spread rumor. Yes, I should have done my homework. But all I can ask is, if it had been suggested to you that you download “OpenOffice, written in Java”, OO’s wikipedia page had a section on Java controversy, and there were links on the OO website to Java API, and you didn’t know it was written in C++… Would you have looked at the source code to verify that it was, in fact, written in Java? Think about it. And not just in a “If I say yes, then you’re wrong, so, yes” kind of way. Really, in your head, go through the paces. If you still say yes at the end of it, then, well, I fold. You’re better than I.

_”Better Than I” doesn’t mean anything if you still haven’t defined better._

Shut up. Troll.

_I’m a troll_

You’re a troll times 10.

_Comparing Windows and *nix is like comparing apples and headphones, and I didn’t really explain Windows over OS X_

First, Windows VS *nix. Several compelling arguments, here. Some of this was a failing on my part- By trying to suppress a rant (I _did_ believe I said I could write a whole other entry on this) I didn’t convey my point in all this properly. When I chose Windows over unix/linux, I neglected to mention that I meant for the desktop, for day-to-day-use. As pointed out in comments, Linux is a great environment for developers. I’ll agree with that- It’s a very developer-centric platform. I’d go so far as to say Linux is like a virtual playground for developers. Its uptime and stability also lend itself exceptionally well to running servers. However, there are several elements of the user experience where it doesn’t measure up to Windows. While Gentoo might have me a little biased, it really feels like hardware support in Linux is a crapshoot, where you can tilt the odds slightly in your favor with a few hours trolling user forums and recompiling the kernel. With Windows, you look for the “Windows” symbol on the box, and you install the drivers that came in the box. 3rd party software installation is also a trip- You can either only use software popular enough to be in that distro’s repository, or you can download and compile source code through some arcane commandline voodoo unknown to non-developers. With Windows? You download the setup file. You execute it, you click okay a lot. And at the end of it all, there are no library conflicts. You can double click it. With Windows, you can do a whole lot and never, ever have to see a command line again. My reasons for choosing Windows over OS X, as pointed out, were more or less arbitrary. I’ll say it again… Like the lists I set out to parody, this one WAS subjective. There are a lot of things to like about OS X, but I find the implementation of Finder genuinely painful. I don’t like having to hit 3 or 4 buttons in order to copy the screen to the clipboard. I can’t copy/paste with my pinky and forefinger, and neither double-finger-tapping the touchpad nor command-click pass for (or even remotely excuse the lack of) a right mouse button on the laptop. Which would be okay if I could install OS X on a dell or something, but, so far, that’s just not possible.

_Textpad is not, in fact, the Bee’s Knees._

Lies and misconceptions! Kidding. I really did claim that I was a Textpad zealout. I know I’m totally biased in the matter, and I also know that when it comes to a “Programmer’s Editor”, every programmer has a favorite, and we all think that ours is somehow empirically the best. Aside from the swath of features considered prerequisite for any good “Programmer’s Text Editor”(syntax highlighting, multiple document support, line numbering, what have you), The main reasons I find Textpad superior are it’s _slick_ multiple document interface, multiple file search-and-replace, and above all, that external tool support. There was a little confusion on this last one, so pardon the zealoutry while I elaborate. I’ll try not to go all mac-zealout “shepard the lost” on you. The external tool support isn’t JUST compiling/running java with one click. It’s that you can point Textpad to any executable on your system, and have Textpad open the currently open file with that external tool. So if you have gcc, you can compile in textpad. If you have python/ruby, you can run a python or a ruby script from textpad. Not to mention it captures the output as a seperate textfile for you. And best of all, you can save that “run open file with this program” thing to a shortcut. Ctrl+number. It’s an amazing contribution to workflow. Vim is great if you don’t have a mouse. JEdit is, actually, pretty slick, and I think I’m going to look into it a little more. But my top spot for text editor really has to go to Textpad, for interface, featureset, simplicity and power. If you don’t agree, I totally understand. Feel free to write your own list:P

-Alex