Developing asychronously

Why it works for Github, but maybe not for the rest of us

These days, it’s not hard to find a Silicon Valley startup that claims, not so modestly, that it’s changing the world. And while it’s true that some startups are doing just that, the not-well-kept secret is that most of them aren’t doing anything productive, much less profitable, but still somehow find ways to get funding. But one startup, Github, is unique: not only is it changing the world, but it’s changing the way startups change the world. Github’s about page claims it hosts over two million repositories, which include the likes of the Facebook SDKs, the popular JavaScript framework jQuery, and the open-source release of Doom 3. It was even the primary home to arguably the most important open-source project ever, the Linux kernel, when its usual home was compromised earlier this summer.

And while Github is making a huge difference in how people write, store and track their source code, it’s also starting to affect how people develop software. This is an important distinction, and failing to optimize the processes and philosophies that you and your team take while developing software can lead to productivity losses just as severe as bad developers or bad bugs.

LESS is more

How you can have fun writing CSS by writing LESS

We recently finished up the latest major version of a project at work, a web application that allows our clients to view Facebook Page analytics that we generate and empower them to craft their future social media strategy. The project has seen a couple iterations, but for this one, in an effort to make the whole thing simpler, we reworked most of it from the ground up, including a brand new user interface.

But while CSS is a very powerful tool, this web app was going to require a lot of it, using features from every version of CSS. And while “graceful degradation” was our methodology to some degree, the last version of this product didn’t support any browser except Chrome (because of time constraints) and it was made clear that this time, we would need to support all major browsers. This would mean hundreds of rules, nested rules, exceptions to rules, and fixes for The Browser That Shall Not Be Named.

So in an effort to simplify our CSS develop/test/deploy cycle, we decided to employ LESS, an extended CSS with support for nesting, variables, imports, and expressions.

Codenamed “The Experiment”

New look, same brilliant writing! ... Oh, don't make that face. It's not like you were paying for it.

Welcome to the new Cleveland, Curveballs and Common Sense, codenamed “The Experiment”! Go ahead and take a look around, then come on back and I’ll show you around.

Last year, around this time, I started thinking about redesigning my blog. I was working on implementing a WordPress theme from scratch at work; with Stephen Stanton (and his boss Josh Laney) providing the graphics and creative vision, all I had to do was write the code that powered a new WordPress site for our Chasing Trophy Whitetails brand. On my end, there were some neat technical things with the theme like an HTML5 image gallery and automatic generation of OpenGraph tags. It seemed pretty fun and pretty easy at the time, and so I quickly became eager to write a theme for my own blog and transfer some of that new knowledge over.

But it’s not even close to that easy: it takes skill and talent to create and execute a WordPress theme design, and so I flustered for almost a year, coming up with various ideas but nothing good enough to make me want to switch.

A challenger appears

If you look on my company’s team page, you’ll find my picture captioned “Overrater”. I take this caption somewhat in stride, because being involved in developing many of the analytic algorithms at our office means that I’m spending a lot of my days “rating” client’s Facebook Pages and presences. The reason the caption is there though, is that I have a strong tendency to not be impressed with things most people seem to like (“Shark Week”, “Avatar”, “Top Gun”, college football, to name a few) and call them overrated.

Which brings me to Google’s new, much touted social network called, simply: Google Plus. Google+ isn’t Google’s first entry into the social arena, but it’s their newest and inarguably their strongest. And while Google enjoyed excellent early reviews as well as an early influx of 10 million enthusiastic users, my impressions of Google+ are much less enthusiastic. My initial impressions of what’s wrong with Google+, after the break.

Learn the code. Love the code. Be the code.

Just another day at the office.

When I was born, my Uncle Jim (who has since passed away), who was a newspaper columnist, wrote me a letter welcoming me to the world and introducing me to my family. It was a neat idea (and a tradition I plan to continue), and in the letter, he predicted that because of my genetic makeup, I’d be an All-American, All-Academic starting linebacker for the Ohio State Buckeyes.

My parents, who probably read the letter the night it was written as opposed to discovering it buried in family photos years later, probably read the letter and chuckled. Given the fact that my parents are both computer programmers, I can imagine one of them saying, “there’s no way that kid’s not a programmer.” (I’m not sure what this says about my sister, who will probably cure cancer one day but can’t defragment a hard drive to save her life.)

And if one of them said that, they were right. I’ve been fascinated with computers since I was in elementary school, launched my first website back when Albert Belle was slugging home runs for the Indians, started writing programs in middle school, wrote a full web app in high school, and never looked back.

Well, kind of. Because there was definitely a time over a period of the last few months and years where my computer science knowledge stagnated, where my interest in the field was at a low point, and where I just felt burnt out. But lately I’ve felt that drive again, that addiction to building awesome things that only software engineering can deliver.

A bug by any other name

I ran across this post today on TechCrunch (er, sorry, I guess it was on MobileCrunch). For those uninterested in reading the full article, I’ll speak a little bit about the bug, which has the potential to be very costly. Basically, the article states that when you’re viewing a motion-JPEG (a video format based on JPEG photos – often found in digital cameras or security cameras) file in Safari on the iPhone and then closing Safari, the browser actually stays open. Mobile Safari will continue to use up bandwidth as it loads the motion-JPEG at the specified interval, and if you’re on a pay-per-megabyte-downloaded plan, you could foot the bill for thousands of dollars.

The article kind of justifies this bug. After all, it states, it doesn’t affect you if you’re on an unlimited plan (because hey, if you have all that extra bandwidth, why not waste it?) and it only seems to occur if you’re viewing a motion-JPEG (which isn’t the most common file format, but it’s not unused either). So, fine. It’s a bug, it doesn’t really affect a ton of people that greatly, oh well, right?


The first comment on the article:

How is this a bug?

The website refreshes…it’s not apples fault the person would have a crazy bill, it’s the user for not closing out the page.

And here’s the real beauty of making an Apple product. No matter how bad it sucks, no matter what kind of problems it has, Apple users defend Apple products like they’re defending their children. This attitude either stems from or causes Apple’s ridiculous arrogance about its own products. (For an example, check out any of Apple’s recent commercials for any of their products.)

I’ll address the commercial first. Here’s the thing. Apple’s made a good operating system. It didn’t happen overnight. If you think this operating system has been rock solid from day one, look again. If you remember, OS X only really started even getting stable at around 10.3, and it got good at around 10.4. The OS has been really a work in progress since 2001, and it’s had its share of problems. That’s not to mention Mac OS 9 and below, whose codebase was, for all intensive purposes, abandoned when the company was on the brink of bankruptcy in the late nineties. But that’s an argument for another day.

Let’s get one thing straight: when you close a program, it should close completely or give you some indication that it’s still open: in OS X, an open program is a shiny light under the icon in your Dock, in Windows it appears in your taskbar or system tray, etc. ┬áNot only does Safari not give you any feedback that it’s remaining open, it’s the only application on the iPhone to do so. It’s far from expected behavior, and when using an electronic device, users prefer devices that they can guess what’s going to happen based on their actions.

If any users get a bill in the triple digits (in some cases, as noted in the article, over $3000 for an hour of unknown downloading), Apple should pay it themselves. This isn’t user error. It’s either by design (for whatever reason), or it’s a bug. Apple should fix it.

WWW is the new blog

A couple of quick programming notes (related to the content of this site, not my actual programming. Actually I guess it is related to my actual programming. So forget I said this.):

  • You may have noticed that now redirects you here, to I did this to create a more unified feel for my web presence, hopefully it’s more helpful for what you’re looking for. I’m still working on it, so let me know if you have suggestions or concerns.
  • Because I moved some files around I needed to rebuild certain projects so that they could be downloaded from the server off the installer, so I rebuilt Invaders and George In Space!. If you haven’t checked them out yet, you should – they’re probably the two most useful programs I’ve ever made.



As always, thanks for your feedback, and above all, thanks for reading!


This post was originally written as a guest post for RyboMedia on October 15, 2009. Thanks to Rybo for letting me post this! Hope you all found it enjoyable and informative.

ServersWe ran into a problem at work last week that was, at the same time, a nightmare and exactly the kind of problem you want to have.

The culprit was our latest Big Prize Giveaways promotion, and the problem was that our app had metaphorically gone from 0-60 in about two seconds, and it experienced the same thing your neck feels when it accelerates that fast: whiplash.

UPDATE: Developing Socially

Just a quick post to let everyone who’s interested know that I’ll be giving a talk tomorrow at Refresh Columbia. More details can be found in this post, but I’ll be talking about Facebook development and how it can impact your Facebook Page. I’ll post some source code and my slides on this post once it’s over. Hope to see you there!

UPDATE: Code and slides after the jump.

Two choices

I don’t normally write about higher level software design for a couple of reasons. For one, I don’t consider myself to be an expert in the field. I’m not sure there is any one expert in the field, actually; it’s a little bit like saying there’s an expert in string theory, a field that’s less that fifty years old and every bit as complex as software design. However, I don’t really consider myself above average at it either, and if I’m not above average at it, there’s not usually anything I could say that you couldn’t read somewhere else, better explained and more original.

The second reason I don’t normally write about software design is that since most of my projects are small (projects at work are either designed in collaboration or already designed), I don’t waste much time on design. Today I modified a GreaseMonkey script Mike wrote to remove ads from GrabUp posts; he wrote it because he was sick of looking at ads, I modified it because I was tired of the refresh caused by redirecting to the direct image. I didn’t write out a vision and scope document, I didn’t create a design document, I didn’t diagram it – I just wrote it. Another example is my recent weekend project It’s a little larger in scope, but rather than figuring out how everything was going to work beforehand by diagramming it out, designing a database, etc., I just started writing it and it all just kind of came together. Even back when I was writing McJournal, I had an idea in my head of how the final product would look but I never wrote it down anywhere, I just started writing.

Point is, it’s pretty easy to skip that design process which can greatly influence the success of your product. As I thought about it this evening, I realized that all software products fall into two categories.

The first category are the applications that are designed not to suck. We all use software for many different purposes, but a lot of times, we’re using it for work or productivity. Hence, products like Microsoft Office, Quicken, GMail, TextMate, etc. are designed as software that stays out of your way. Either it lets you perform tasks the way you want, or it gently nudges you once and then leaves you alone. Nothing is more annoying in this case than the application that’s trying to do too much (Clippy: “It looks like you are writing a letter…” anyone?). Applications that are designed for productivity usually fall into this category, because normally you want to get your work done, then get off the computer and head out to the golf course. The key word with these types of applications is intuition: it should be intuitive for the user to use.

The other category is the applications that are designed to rock. As you might imagine, these are normally entertainment applications like video games or multimedia applications. These are applications that the user wants to use, applications that the user wants to learn, and applications where the user may want helpful tips. For example, take Halo 3. The game would have been a bestseller without adding a bunch of new weapons, a bunch of new gadgets and a bunch of new customization options in multiplayer mode, but because the game added those little features, it was smash hit and is still played today. Entertainment applications can’t be simply functional to be successful; they’ve got to be immersive.

Ever wonder why Twitter is emerging as a more popular social networking tool for professionals and celebrities compared to Facebook? It’s simple. Using it is as simple as sending an SMS message from your phone or typing 140 characters in one form field on the web. Want to share a link? No problem! Just copy and paste it in there and done. No captchas, no conversion to “shared items” like Facebook likes to do, just shows the URL and makes it a link.

On the other hand, Facebook is complex enough already, and it’s gotten more confusing for the average user over the years. Over the last couple of months I’ve had the pleasure of introducing my dad and my aunt to Facebook (seriously, Mark, I’m fighting for you here, how about throwing some of that money my way?) and I’ve seen the site through new eyes: even with the wizards, hints, etc., a cautious user may feel overwhelmed when visiting the site for the first time. Facebook realizes this, that’s why they’re rushing out Facebook Lite to their 250 million users. Interacting with friends, profiles, streams and comments is hard enough; adding Pages and Ads to the equation makes it even more confusing. Thus, professional users or less computer-savvy users are using Twitter for their business communication.

Another example is in web browsers. As many of you may know, Internet Explorer 6 is still alive and kicking on the web. As someone who has faced a ton of IE 6 errors and quirks, I am definitely in favor of getting this browser out of circulation. But generally, people are using IE 6 for one of two reasons: a) it’s an office requirement, or b) it works for checking e-mail, news, etc. and that’s all it’s needed for. For these users, a browser is a productivity application, not an entertainment application, and IE 6 (unbelievably) “doesn’t suck” too much for them and it requires zero installing, configuring or tweaking to get up and running.

On the other side of the spectrum, Firefox is more of an entertainment browser. Clearly, users use it for productive purposes too, but it’s clear that Firefox is used as an application that rocks rather than an application that doesn’t suck: tabbed browsing, add-ons, and a prettier interface are just a few of the reasons younger users tend to use Firefox.

I guess the point of all this is, next time you’re writing an application, no matter how big or small, ask yourself the following question: do I want my application to rock or not suck, or better yet, do my users want my application to rock or not suck? Hopefully it helps you iron out your feature list and make it one that your users will expect.