Thu, 01 Apr 2010 16:31:00 GMT

Breaking Newton's Third Law of Motion

Newton's third law is a wonderfully simplistic rule that has overwhelming implications. In a single sentence it describes the interactions between all the objects in the universe.

Every action has an equal and opposite reaction.

Humans even follow this rule to a certain extent. If a person hits you, you'll get angry. Getting angry is an equal and opposite automated reaction. These kind of responses can be useful. For example, touching something hot will cause you to pull your finger back. However, these reactions aren't always useful. Consider a person who skips an interview with a prestigious company because they're nervous. In this case, the automated reaction to avoid stress worked against the person.

The difference between a human and an inanimate object is the ability to turn off these automated responses. Our actions don't need to be equal or opposite. Between the forces acting on us and the actions we perform is a choice. You are the sole owner of that choice. We have no control over external actions that happen to us, but we do have control over the resulting actions. That choice makes every person infinitely powerful.

However, what happens when we rely on our automated reactions? We forfeit the power we have to the initiator of our automated response. We become very similar to inanimate objects. We are bound to the rules of determinism. If instead we choose our action we cause indeterminism because the universe isn't choosing how we behave anymore. We start our own chain of actions which the universe must react to.

With this kind of power you can never be defeated. You could be bound, shackled, and locked in a dungeon and still have power. Those are just external predicaments that prevent your external action. However, your power does not reside in your hands; It rests in your ability to make a choice. As long as you never forfeit that, the universe has no control over you.

Sat, 30 Jan 2010 21:39:00 GMT

BEncode Version 1.0 Released

Over the past two weeks I have been working on developing a BEncode library in ruby. BEncode is the protocol that Bit Torrent uses to communicate. Well today I just pushed the gem and posted the documentation. If you're interested in finding out more about this project you can check out my project page.

Fri, 25 Dec 2009 14:07:00 GMT

Fear of Committing

When I worked at my last company we used CVS. The central repository was holy and no one could commit changes until they had been reviewed. This led to a fear of committing. What that means is that developers would develop entire features without version control as a backup and a way to undo mistakes. If you went down one path and then decided it wasn't a good idea, you had to manually back out your changes. Also, with such large change sets, developers were almost certain to have conflicting changes. That meant merges were necessary, which could lead to more errors.

Not too long ago, I went to a talk about Git. Git is very different from CVS and even its successor Subversion. Git is distributed. What that means is that everybody has their own copy of the repository. If you want to commit you can. You no longer need to fear committing to the repository because you own it. That means you can commit more often. Git also tracks your history and keeps it intact between repositories. So if you've committed 50 times and another person pulls from your repository, they get all 50 commits. Compare that with CVS or Subversion, where everything is committed as one big change and it will become apparent why Git is much better at handling merges.

A lot of people will tell you Git is fast and Git is distributed. However, those answers are vague and don't describe why it is worth abandoning what you currently have. I think better selling points would be that Git allows developers to use their version control and makes merging the job of the version control rather than the developer. Those are what sold me.

Sun, 11 Oct 2009 17:42:00 GMT

Software That Talks

The other day in my Data Communication and Networks class my teacher asked us a very uninteresting question. What is necessary for a network application? The students in the class suggested a connection, a protocol to communicate, and data to transfer. The teacher said yes to each of those and then he opened up Firefox and downloaded a file. He asked us why does Firefox show a progress bar? Because network latency isn't zero.

He intended to teach us an important lesson about not assuming that communication is not instantaneous. However, every story has more than one moral and the one I got from his lecture was that software needs to communicate with the user. Why does Firefox show a progress bar? Because otherwise the user wouldn't know that something is going on, they would assume it was broken, and they wouldn't have faith in it.

Developers have the tendency to think of their software as a tool to accomplish a job. I think a better mindset would be to anthropomorphize your software. Pretend it is another person; one that your users will interact and communicate with and that will talk back. When I ask a person to do something I expect them to acknowledge what I said, give me feedback on what I asked them to do, and to tell me when they are done. If you treat your software like it is another person you begin to put constraints on it that you might not have done otherwise.

Mon, 14 Sep 2009 14:45:00 GMT

Conditioned Happiness

Ivan Pavlov is famous for his experiment where he trained dogs to salivate when they heard a bell. He did this by preceding every feeding with a bell ring. Eventually, the dogs began to associate the presence of a bell ring with the arrival of food and would start salivating even though no food was presented.

This is an extraordinary phenomena that is also present in humans. Pavlov's experiment was artificial, but we as humans have several natural associated responses. One that is especially useful is the association between smiling and happiness. The mind treats the feeling of happiness and the action of smiling as synonymous occurrences. Typically, happiness precedes smiling, however, it is not necessary that it happen in that order. When smiling happens first it can invoke a feeling of happiness without any other qualifying events.

This association can work wonders when doing things that you don't want to do or after a serious of unfortunate events. For example, when I was learning to snowboard I would always smile and laugh to myself whenever I fell. It allowed me to make it through the hard parts so that I could enjoy the fun parts.

So, smile more!

Thu, 10 Sep 2009 20:29:00 GMT

Where to Start?

When you run a race the rules are simple. You start at the start line and you finish at the finish line. Your only goal is to get from one point to the other. Software development is nowhere near as simple.

Yesterday an underclassmen friend of mine asked, "I want to build an application, where do I start?" Being in his position at one time, I can see where he's coming from. You have no defined start line or finish line and there are an innumerable amount of paths you could take. Schools do a very excellent job of showing you how to get between two points that they specify, but in the real world those points aren't nearly as well defined. That is why software development is more than just coding. Software development is about defining the constraints of the race and then, running the race.

Every project starts with a problem that needs to be solved. It is necessary to translate that problem into a set of goals. Once you have defined what your goals are, you have established a finish line. To pick your start line, select the most important goal that is the core of your project. For example, if you're creating a to-do list application, the most important feature is obviously the ability to create a list. Something like search may be nice, but it isn't critical. To build the path between start and finish, keep selecting a new start line after each goal is completed. Every goal is in essence its own race. Each race can be broken down into smaller goals. By breaking a project down into its most basic elements, it becomes much simpler to build than when thinking of the project as a whole.

Sat, 05 Sep 2009 23:38:00 GMT

Being Remarkable Does Not Equal Quality

Seth Godin often talks about building a remarkable product, which, by definition, people talk about. One thing that stuck out to me recently while reading Purple Cow is when Seth Godin says:
The opposite of remarkable is very good. Ideas that are remarkable are much more likely to spread than ideas that aren't. Yet, so few brave people make remarkable stuff. Why? I think it is because they think that the opposite of remarkable is bad or mediocre or poorly done. Thus, if they make something very good, they confuse it with being virus worthy. Yet, this is not a discussion about quality at all.
This is a very interesting concept. Being remarkable is not a measure of quality. Building a very good product is not the same as building one that people will talk about.

For instance, take Basecamp by 37 signals. In their book Getting Real, they talk about how they stood out from competitors by being the simplest web-based project collaboration tool. They explicitly excluded features that other's thought were required for project collaboration. They weren't successful by being better. They were successful by being different. If instead they had tried to be better than the competition, they would have been indistinguishable.

Don't waste your time trying to be better. There will always be someone better. Instead focus on being different; being remarkable. If people are talking about you then you have a better chance at success.

Tue, 01 Sep 2009 23:36:00 GMT

Word of Mouth With Added Weight

When I was in high school, my friends would recommend music to me. But they didn't stop there; they also burned me CD's to listen to. I discovered a lot of bands that I still listen to and patronize because of my friends recommendations. However, their recommendations alone would probably only have persuaded me to listen to a fraction of the music that I ended up liking. The real thing that pushed me over the edge was the fact that I could try out what they were recommending to me. I didn't have to go out and find it and I didn't have to risk spending the money on something I might not like.

As a marketer, the goal is to win over the majority with your product. The way you win over the majority is by making your product remarkable so that the early adopters will want to talk about your product. If you want your salesmen, the early adopters, to do a good job selling your product you have to equip them with the right tools. Someone is not going to buy a $500 dollar licence for software or spend 3 hours filling out forms just to use a product based on another persons recommendation. The barrier is too high. Make it easy for your salesmen. Give them the CD's to hand out. Upload your videos to YouTube so they are easy to link to. Only ask for the bare minimum for someone to register on your site. When you make it easier for your salesman to make the sale, you will benefit.

Mon, 31 Aug 2009 15:30:00 GMT

Setting Up a Repository on GitHub

GitHub offers free open source project repository hosting using the git protocol. Git is specifically designed for distributed development of software.

Creating the Repository
To create repositories on GitHub, you'll need to create an account. Once you have an account you can go to your GitHub homepage and click the link to create a new repository. Fill in the name of your project and optionally, a description and project URL. Now you have a repository.

Setting Up Shared Keys
Git connects much like ssh and uses shared keys to confirm the remotely connected computer is who they say they are. For your local git to connect to GitHub it is necessary to generate a shared key and tell GitHub what it is. To generate you own shared key, follow the instructions below:
cd ~/.ssh/
ssh-keygen -t dsa
You can hit enter through all of the prompts. You will now have two files: id_dsa is your private key and is your public key. The contents of is what GitHub need to know. On your GitHub account page there is a link to add a public key. Click that and copy the contents of into the key field and add a name to designate what computer the connection will come from. Then click the add key button. You can now connect to GitHub.

Setting Up Git
You will need to tell git your user name and email so that it can appropriately attribute your code contributions to the repository. You can do this with these commands, filling in your own information where necessary:
git config --global "My Name"
git config --global ""
Note: This has set the settings globally. It is possible to set this up per project.

Commiting to the Repository
Now you need to go to the root directory of your project. If you don't have one yet you should create it. Then you can use the following commands to commit your initial project to GitHub, replacing with your GitHub username and with your repository project name on GitHub:
git init
git add --all #only do this if you have files already
git commit -m 'first commit'
git remote add origin
git push origin master
You have officially set up your local repository and set the master to your GitHub repository.

Working with Git
From now on you can commit to your local repository with the following command:
git commit -m "A message explaining what you did"
Then, to push it to GitHub use the following command:
git push

Sun, 30 Aug 2009 14:24:00 GMT

Javascript Key Events

I just recently spent a while learning the mechanics of key events in javascript. There are many incompatibilities between each of the various browsers, which makes the task somewhat difficult.

Getting the Key
The first problem I encountered was how to get the key from the event. Internet Explorer uses event.keyCode to store the numeric representation of the key. Mozilla historically used event.which, but now uses either event.keyCode and event.charCode depending on the circumstance. However, event.which is still supported and always contains the key code, whereas only one of either event.keyCode or event.charCode contain the key code. Because of these oddities, it is necessary to use some logic to figure out exactly what has the key we want. For that we do the following:

We can check if event.which exists. If it does we are on Mozilla and will get the even.which property to get the key code. If it doesn't exist then that means we are on Internet Explorer and we need to check the event.keyCode property.

Difference Between Key Events
Keyup and keydown are rather different from keypress. Both keyup and keydown's key codes map to the specific keyboard that the user is using. Meaning there is no consistent way to determine the key between any two computers. However, the keypress event behaves differently. Instead of the storing the numeric representation of the keyboard key, it stores the UTF-8 encoding of the character which is easy to determine across different systems. The lesson here is that if you want to know if a key was pushed or released, but don't care what it is, you can use keydown and keyup. When you must know the key value that is being typed using keypress is the only reliable option.

Shift Key
All browsers have support to figure out if the shift key is being pressed for each of the event types. The problem is that there is no way to tell what the original unshifted key is, because the event will only tell you the shifted key code. For letters, it is simple to convert back to lowercase with String's toLowerCase() method, however, for the number and symbol keys, the only way I could think of is to have a translation table. As a result I came up with this:
However, I'm using an American standard keyboard. If another keyboard setup has other keys that are modified by the shift key, this will not solve the problem.

I discovered all of this while writing an extension to the Prototype framework. I'll be releasing this on GitHub under the name of blacksmith in the near future. The project home will reside here.