Category: ideas

The next Twitter.

I don’t know Twitter’s mission statement, but to me it seems like it should involve enabling stream-of-consciousness communication. When I look at heavy Twitter users (especially those with iPhones), it is close to stream-of-consciousness — it seems like they’re sending every other thought to Twitter. But it’s not stream-of-consciousness for most people, there’s too much overhead in posting to Twitter.

It seems to me that if Twitter had some spare cash, it would be wise to look into developing some more advanced technology. The iPhone is very close to wearable computing, but I’m sure there’s some clever ideas in the wearable computing area that could be adopted and branded by Twitter. There’s a great opportunity for them to pull a trick like Apple did with the iPhone, and bring this technology to mass-market in a nice slick package. It’s a natural extension of their current business, and it’s a technology that’s coming — a nice time to catch the wave.

Learn to Map

As a follow-up to my previous post about how to create comma separated strings from arrays, here’s another array tip.

Let’s take the previous example of the Tags array. Except this time, Tags contains the IDs, which correspond to the textual string.

Tags[0] = 23
Tags[1] = 42
Tags[2] = 314

Rather than write a for-loop to look up each value, let’s pretend we’ve already got a function getTagTextByID(), which accepts the tag ID, and returns the tag text.

Tags = Tags.map(getTagTextByID)

Now tags has the text for the tags.

Map is a fairly common function for operating on arrays. As with the previous tip, Map is available in many languages. PHP offers array_map(), and JavaScript offers Array.map(). Check your favorite language for this function, it makes code cleaner.

As an added bonus, Map has a starring role in MapReduce, Google’s favorite technique. Shouldn’t you get to know Map too?

Comma, Separated, Values,

I recently realized how much of the art of programming is just lots of little tricks that you pick up along the way. I’m resolving to share these little tricks, in the hopes that others will do the same, either on their blogs or in the comments here.

Here’s one involving an array and building a string of comma separated values.

Let us pretend you have an array called Tags. It contains the tag names as strings.

Tags[0] = "awesome"
Tags[1] = "groovy"
Tags[2] = "existential"

You want to display these as CSV

awesome, groovy, existential

How do you do it? You might think “well, I want to print a tag, then a comma, then the next tag, and so on until I’m done”

for(i = 0; i < Tags.length; i++) {
    print Tags[i] + ', '
}

You probably see what’s wrong already. The above code prints

awesome, groovy, existential,

OK. Maybe you could get clever:

first = true;for(i = 0; i < Tags.length; i++) {
    if(!first) { print ', ' }
    print Tags[i]
}

or

for(i = 0; i < Tags.length; i++) {
    if(i == Tags.length - 1) { print ', ' }
    print Tags[i]
}

But ouch. Don’t do that.

Many languages provide a built in function for converting arrays into CSV strings. PHP calls it implode(), Javascript calls it Array.join(). Simply put, it returns a string consisting of the values of the array, with a delimiter in between the values.

Tag_string = Tags.join(', ')

Done.

Velocity, or v = dx / dt

I was coworking at Stardust today, and we got to talking about Agile Development, and the concept of velocity.

Disclaimer: I hate buzzwords. But, these terms have specific meanings, and although it sometimes sounds cheesy, there really is something to this Agile movement.

Basically, velocity is an Agile concept that is a self-calibrating method for estimating how much work can be done in a unit of time.

The trick is that velocity doesn’t really measure the work done, it measures how much estimated time it takes to fill an actual week of working. The trick behind velocity is that you track (per task) the estimated time of completion, and the total amount of estimated work completed in a unit of time (usually a week). As long as the developers who are on the project are always the same ones handling estimates,  if they have a tendency to overestimate or underestimate, it will be canceled out after the first week or two. Make sense?

If you haven’t tried Agile development processes, I strongly recommend it. There’s a game that was created to help explain how Agile/XP works,  calld The XP Game. It’s a reasonably entertaining way to learn business stuff (better than a pointy haired lecture!), and doesn’t take long.
I’ve still got lots to learn about the finer aspects of applying Agile/XP, but I’m happy to talk with anyone about these ideas — I might learn something new 🙂

“Do you know how long that’s going to take?”

When I read about ICANN’s proposal to let anyone register a TLD (top-level domain; the .com, .net, .edu part), I can’t help but think of the number of systems that check email addresses (or domains in general) for validity, and won’t accept any email address that ends in anything but the few most common TLDs.

It would have been better if they had done everything correctly upfront, right? There’s an established standard for emails that
has been around for years describing — in painstaking detail — how to tell if an email address is valid. Surely it’s not hard to do it right, right?

There are two ways to deal with an issue:

  • do it right the first time
  • do the best you can and deal with issues as they arise

It seems that there are characteristics of situations that make one option more appropriate than the other.

  • Is it is an established thing?
  • Is the “right way” easy to learn?
  • Is it something that will last over time (the foundation of a house, as opposed to the color of the paint), or is it inherent that the thing will change soon?

Possibly everything starts as “best you can” and eventually moves to “do it right”. When we are babies learning to walk, we don’t consult textbooks on human mechanics; we don’t visit specialized doctors who focus on the angle of the spinal column to the neck; we get up and fall down a lot. It’s a new thing, and any given sequence of steps is a momentary thing, we aren’t still reliant on the series of steps we took years ago.

When considering software, however, the characteristics blend a lot. Software stays around for a while; I read a great quote relating to this:

“Obsolete hardware gets replaced. Obsolete software goes into production every night”

There are easily millions of lines of code that are 30-40 years old that are still used today. That’s definitely a vote to do it right. However, software development is not established — at least, not in the sense of cooking, where professional chefs have existed for thousands of years and the art is well-defined. Software development is still changing. Even the standards I talk about will change as we have new needs. The people who are writing the standards are just doing the best they can!

I suppose most things aren’t clear cut either. The humor of this whole thing is that the decision between “do it right” or “best you can” itself requires you do just make the best decision you can. 🙂

So in the end, is the answer to do things as right as you can, to the best of your ability, and not worry about the rest?

Little digits

There’s this idea I’ve had rolling around my head for a while now. I call it the Law of Small Numbers, but it’s not really a law, and it’s apparently not called that either, at least according to Wikipedia.

Basically, it’s that small numbers increase easier than big numbers. It’s an idea that’s become popular with investors — small businesses can double your money easier than big ones. A tiny store can easily double it’s business, WalMart can’t.

Simply put, if you’ve got 2 units, and you increase that by 1, you’ve increased by 50%. If you’ve got 20 units, and you increase by 1, it’s only 5%. That’s the Law of Small Numbers. Maybe I should call it the Law of Increases of Small Numbers.

It’s something that’s popped into my head lately, thinking about gas prices. I’ve been trying to collect some gas mileages in my car, so that I can have hard data to look at. The way I see it, your gas mileage is a function of your gear, and your RPMs. Assuming constant gear (let’s say 4th — you’re cruising). If you are going from 2000 RPM to 4000 RPM when accelerating, you are literally cutting your gas mileage in half. If you can travel 55 MPH at 2000, but 60 MPH at 2500, is it worth decreasing your mileage by 25%? What if the corresponding speed increase only gets you there 90 seconds faster?

On a side note, one of the pages linked from that Wikipedia page discusses the Strong Law of Small Numbers

“There aren’t enough small numbers to meet the many demands made of them.”

I see this as the reason that things always seem to happen in twos and threes, but that doesn’t mean that they’re related.

A icon to save your ass

I just forwarded an email asking for an RFP around to the team at Cloudspace, and since I use address book autocomplete, I checked the email addresses very carefully before sending the email. I’ve heard of (and seen) too many instances where someone quickly sent an email, and addressed it to the wrong person. Funny how it seems to happen most when the person who actually receives the message is the one person who it should definitely have not gone to.

Ideally, my email client would have pictures of everyone, automatically grabbed from their Facebook/Myspace/Interblag Networking accounts. Humans are so visual that it would be immediately noticed if an email wasn’t going to who I wanted it to.

I think the next best thing — at least from a corporate email perspective — would be an highly noticeable icon in the mail window that would only display if all recipient email addresses matched a set of criteria. Some obvious ideas are:

  • All domains match each other
  • All domains are on a whitelist
  • All domains match the sender’s domain

It should be easy enough to hack together an extension for Thunderbird to implement the “highly noticable icon,” but I know that the photos of everyone is the killer of the two. I think it’ll be another few years before we have good enough pictures of everyone (in terms of being auto-grabbable, and not having to take their picture deliberately), but I think the concept will show up soon.