Clean Coding

Consider the following source code:

$uSess = uLogin($uName, $pwd);

That’s a fictional piece of code that might exist in a login script. The uLogin function, short for “user login” versus, perhaps, aLogin for “admin login”, accepts two parameters: a username and a password and assigns the result to a session variable called “uSess”.

This sort of code is very common, and I hate it. By looking at the code, there are numerous problems with how the variables and function are named that can cause long term problems. The proper naming should be:

$USER_SESSION = userLogin($username, $password);

There are two primary changes I have made.

  1. Globals and constants should be capitalized. While technically $password is a global variable, in this context, I am referring to variables that are accessible in any function or class, which sessions are. Since the result is being assigned to some session variable (in my example), it should either be in all caps or use the $_SESSION global array.
  2. No abbreviations!!! Was it passwd? Pass? Psswd? Pwd? Password? Pword? You might remember now, but you won’t in three months. And if someone else in the same namespace decides to create another variable referring to another password, things can get VERY messy when you end up with code with $pwd, $password, $pass, and $pass2 all mixed together near each other. It would have made things much simpler had each person who added the variables used a fully qualified prefix and name such that, instead, you ended up with: $password (the original), $adminPassword, $systemPassword, $databasePassword, etc.

It’s only a few more letters to type that will save you hours some day in the future. It’s worth it.

The Future of iPods

In another blog prior to this one, I wrote about a prediction I have for iPods. Because I plan on fully retiring that blog in the near future, I thought I would port the post here to keep the prediction alive. Note: I wrote this post long before the recent flurry of iPhone headlines.

Here’s my prediction: The next iPod will be the new hook Apple will use to enter the cell phone market.

A little history:

  1. First Apple introduced an iPod. It played music well.
  2. Then Apple introduced color iPods with photo capabilities. A mostly useless upgrade, but still cool.
  3. Then Apple introduced a video iPod. Suddenly portable video became a hit.
  4. Then Motorola introduced the completely shitty Rokr iTunes phone. Nobody cared.

The reason why no cell phones have been successful with music playing integration is that the two tasks require use input methods that are starkly different. Making calls requires a number pad and the ability to browse through a phone book. Sending text messages requires typing abilities. Browsing music, on the other hand, requires volume control, music selection, and play control. Let’s not forget the entire device must be able to sync the music files too. Dumber people in the past have speculated Apple would release a phone iPod that had an old fashioned digital number dial type of thing that would superimpose over the click wheel. Wrong. Dead freaking wrong!

Let’s fill in the gap. Recently there have been very prominent rumors about a new version of the video iPod that has a giant touch screen with a digital click wheel that only appears as necessary. Sounds cool, right? Now you’ll be able to enjoy videos more than ever! But wait, there’s more.

Apple’s newly rumored screen-only interface is the key. No, not because they can superimpose numbers over it when you’re in “phone mode.” Like I said above, wrong! Rather, because when you go into “phone mode,” the click wheel disappears and is replaced by a cell phone style keyboard. That’s right. The new all-digital front panel allows Apple to overcome the problem of mixing two different devices with completely different input methods. The new iPod will simply drop the click wheel if you aren’t doing a music or video related action. It’s genius.

Imagine an iPod that has a small, albeit low-quality, speaker that allows you to use the iPod as a phone as well as hear your movies. Imagine newly upgraded iPod earbuds that allow you to make and receive phone calls without ever taking your iPod out of your pocket, all while simultaneously pausing your music. Imagine a phone where your ring tone could be any song you own.

Apple won’t be pushing this new idea forward any time soon. The world is not yet ready for an all-in-one device. But the day will come. The current big personal electronic devices are:

  • Camera
  • Music player (iPod)
  • Movie player (iPod)
  • Cell phone
  • PDA
  • Internet device

It’s clear that some devices are best left independent. Apple won’t want to make their pristine products murky by adding mediocre peripherals such as a crappy 3.0 megapixel camera; not to mention such a hardware extension will probably compromise the sleekness of an iPod. That said, cameras are likely off the list forever merging with the iPod unless they can integrate it without messing up the smooth curves on the device.

Apple could go another route by integrating Internet access, but I predict that Internet access has too many geek-only issues such as security that may confuse or annoy consumers — Apple will probably never merge Internet access with the iPod. However, they may integrate wireless networking functionality to allow syncing with iTunes on a computer located nearby. And maybe, just maybe, on some random whim, Apple could integrate Internet access simply to allow direct purchases from the iTunes store. However, a consumer who can’t trial samples of music is less likely to buy anyway, so, again, I predict Apple probably won’t introduce this feature in order to protect its “just works” iTunes music-purchasing experience.

Before the cell phone is introduced into the iPod, I predict Apple will test this different-interface idea by introducing a new sub-feature into the iPod that will make use of it. Potential applications are:

  • Ability to sync with your iCal program (PDA integration). This would introduce a new task managing/calendar interface.
  • A different interface to browse photos.
  • The ability to edit music tag information (such as artist or song name).

Apple will be careful about this. They will avoid the (noob) trap of creating 18 different interfaces for 18 different types of situations. Likely, there are only a few types of visual interface layouts they will introduce:

  • Buttons (like on a web page)
  • A number pad like on a phone
  • Yes / No / Cancel dialog

I predict this will be introduced in early 2007 and polished by year-end. Tell me I don’t sound right.

Strong Visions Can Cloud Judgement

A while ago, I was involved in a start up venture. The company invested its future in social networking. We had a business model, angel investments, employees, contracts, marketing plans, and a clear vision. It was over two years ago, and it was before Facebook was truly a mainstream phenomenon. To be fair, if any new social network had a chance to gain any traction, then was the time.

Looking back now, I can tell you a million and ten reasons why it was destined to fail, despite having a feature list that, at the time (and even today), were far ahead of most of the competition. Perhaps in another post I can elaborate on the many lessons I learned from that venture, but not today.

A variety of news outlets and blogs have covered Google closing its Answers service. They also cover how Yahoo came in late and cleaned up.

Well, two years ago, while I was still in the planning stages of the start up, my friend (Brian-Ji) pitched to me the idea of an answers service. He pitched it very convincingly and explained why it was destined to become awesome and fill a currently unsaturated market. I cited Google Answers as a reason why it would fail, despite the fact that my start up was competing against Facebook and Myspace. But where’s the fun in being naive if you can’t be a hypocrite, right? We chose to stick with our original social networking idea and abandoned the seemingly random questions idea.

Upon reading the news of Yahoo beating Google down in under a year, I exclaimed to my friend how I should have listened to him. But this is the very next thought that came out of my brain:

Of course, had we done that, it would have been a lame social networking questions hybrid and failed anyway. Ultimately, it would have been a social networking site first, and an answering service second.

At the time, my mind was so pre-occupied with one idea that I couldn’t see the full value of another. And even if I had seen the value, I would have screwed up the execution. At least I recognize that today. Let’s call that wisdom.

Left Join Snafu

How embarrassing. I learned something new today that I really should have known for some number of years now. Left joins can increase the result set size. 

Here’s what I thought left joins do: When you combine two tables together with a left join, the source table (the one on the left) becomes the “anchor” for the results, guaranteeing that each and every record in the left table shows up in the result. If there are results in the right table that don’t correspond, those results are omitted. If there are results in the left table that don’t have corresponding records with the right table, those records are shown either way. For example…

Let’s say table A has 10 records pertaining to people’s names. And table B has five records pertaining to where those people live. No people live in two places.

If you did a left join on these two tables, you’d end up with five people and their addresses and five people (NULL sets) with no address information.


Let’s say table A has 10 records pertaining to people’s names. And table B has 12 records pertaining to where those people live, where each person in A has a record in B. But two of those records don’t match up with anything in table A because some person records were accidentally deleted (oh no!).

If you did a left join on these two tables, you’d end up with 10 people with information about where each one lives. The extra records in B are simply ignored. 

Okay. That part was easy. Everybody knows that, even your grandmother. Let’s take this a few notches up.

Now if table A has 10 records pertaining to people’s names. And table B has 15 records pertaining to where people live. And this time, those extras are no mistake! Because a bunch of people live in two places, thanks to vacation homes.

If you did a left join on these two tables, what happens? Well, embarrassingly, I predicted this sucker wrong. Assuming all 10 people from A are mentioned in B with some mentioned twice or more, the result would have 15 records!! What!? 15!? Yeah, that was my reaction too. I thought MySQL would spit back 10 and ignore duplicates in B.

Let’s do one more example. How many records will we find if we join the following scenario:

Table A has 10 records pertaining to people’s names. And table B has 15 records pertaining to where people live. One guy has 15 vacation homes and everybody else is homeless (no records in B).

Ok. Do a left join. Not an inner join. Not a regular join. A left join. How many results do we get, huh?

Our result would be 24! Who the hell guessed that? Well, probably some of my more pretentious Computer Science readers, but certainly not me (so that’s what you learn in CS, huh?). It is 24 because you have 15 duplicate records for the one rich guy and 9 default records for the homeless saps. 

Thus, the maximum number of records a left join can yield is sizeof(record set A) + sizeof(record set B) – 1. Why is this never explicitly mentioned!

For a long time, I thought left joins meant the result set can never be more than the row count of the result set in the left table. I don’t know how I managed to go through this many years without realizing my error, but I suppose through good query structuring and table use, I never encountered a problem with this until now… And, to my credit, it wasn’t a query I wrote either.

I have never seen this behavior mentioned in any documentation (even MySQL documentation). It seems to be an implicitly assumed function of the command. In fact, I found several examples out in “tutorials” about left joins, that conveniently left out mentioning this fact, but still showed it as an unexplained portion of their results. Nice.

For all of you non-Computer Science gurus, I hope you learned something new from reading this post. Wasted about an hour of my time.

YouTube and Google?

Techcrunch just covered the possibility that Google is looking to buy YouTube for $1.6 billion.

I think this acquisition makes a lot of sense. While it was pointed out that Google would be unafraid of the copyright issues, I think another reason why the acquisition is a safe bet is that Google can support the infrastructure and bandwidth costs. Owning YouTube would not be a significant strain on a company’s hardware resources. Seeing as Google seems to have a genuine interest in the video market, signified by the presence of Google Video — which was NOT a free-time-project-gone-gold — I’d say this acquisition has a lot of potential to be true.

If the future of the web is in streaming media, owning the current #1 player would be the smartest way for Google to maintain their edge. What’s surprising is how little speculation there was of this acquisition until this post. It seems like a completely random shot in the dark.

I will say that the acquisition doesn’t sit right with me 100%. Google is not a content provider, and owning YouTube and investing $1.6 billion dollars pretty much guarantees they MUST focus on being a content provider as well as an ad broker. Perhaps they’re starting to realize that in order to keep Microsoft off their toes they need to own some of the content as well? Of course, then they’d be competing with AOL, Yahoo!, and MSN for content, but having YouTube certainly would help in that race.

Of course, this all assumes the rumor has any substance.