At Torbit, we saw what other companies like Reddit and Craigslist were already doing and wanted to help other people participate in protesting SOPA. What we came up with is stop-sopa.js, which is an open source widget to add an informative modal window to your site with information about SOPA and how to contact your local representatives to tell them you oppose this new bill. By default it will only be displayed on January 18th from 8am–8pm EST (1300–0100 UTC). It’s available as a WordPress plugin, Blogger widget, Typepad widget, and a simple javascript snippet. Check out the screenshot below to see what it looks like or click here to try it out.

Help protest this threat to the internet. Notify your representatives, spread the word, and protest on your site. Stop censorship by stopping SOPA!

It was definitely a hard choice to make. I lived in the Boulder area for over four years and loved it. The community in and around Boulder is one of a kind. People truly want to help each other succeed and it’s very easy to get plugged in to the great people there. It’s also full of great views, hiking, and tons of sun. I still think it’s a great place to build a company and is an especially great community for first time entrepreneurs to find their legs. While getting started with Torbit, though, my partner and I had a tough choice to make. Where did we want to build this company?

There wasn’t any one reason we decided to move, it ended up being a mix of lots of different factors (both personal and professional). Josh and I wanted to grow our professional network in the Bay area, my wife and I were looking for a change in our personal lives, my wife was going through a bit of a career change, and we didn’t think there would be any better time to move out to CA (we don’t have kids or a house yet). In the end we decided this company would probably be a good fit for CA and we were personally ready to make that change.

It was fun for me to look back at my first post after I arrived in Boulder. The car was again packed pretty ridiculously, but this time we had two cars to drive out. My then girlfriend, now wife came along for the ride as well. And of course, the drive was mostly tedious and boring, but when we got here there was a lot of great stuff to see.

I look forward to meeting new people, finding new restaurants, and seeing what great opportunities CA will bring.

1. First, download the extension.
2. Next, find your Firefox profile folder.
3. In your profile folder, find and open the “extensions/ShortenURL@loucypher/defaults/preferences” folder.
4. You should then find a file named shortenURL_prefs.js – open it in any text editor.
5. You should see two large blocks of similar lines repeating – find the last one in the first block (as of writing this it is pref("extensions.shortenURL.name.145", "w3t.org"); and add a new line below it (incrementing the number) and swap out the name w/ whatever you want to reference your url shortener as. (in my case pref("extensions.shortenURL.name.146", "jfox.in");
6. Continue to the end of the file and you should find a matching url line pref("extensions.shortenURL.145", "http://w3t.org/?module=ShortURL&file=Add&mode=API&url=");. Add a new line below this one incrementing the number again (to match the one in the last step) and adding the url of the page to submit a url to shorten (the url will be appended to the end). For example: pref("extensions.shortenURL.146", "http://jfox.in/make-tiny.php?url="); (note the example here won’t actually work because my shortener is private).
7. Save the file and restart Firefox. Now go to Tools->Add-ons, find ShortenURL in the list and select “preferences”. You should now be able to find your custom shortener in the list using the name you provided above (in my case jfox.in). Select your preference and enjoy!

A quick trailing note: This all assumes that your shortener has an interface that allows a url to be passed as a GET parameter and returns the shortened url in plain text as a result of that request. This is straight forward to implement, but worth mentioning. You should now be able to shorten simply by right-clicking and selecting the “Shorten this page URL” option (which will also copy the short url to your clipboard and put it in the location bar). Enjoy!

• Full control of the data – I can get at it wherever, however, and whenever I want to. I can also move it into different formats and systems at will.
• Full control over the service – I can add whatever features I want in whatever interface I want and not have to worry about the 15 other features I’ll never use that clutter up my UI.
• Full control over the URLs themselves – I don’t have to worry about the domain shutting down, remapping my short URLs some time in the future, or what type of header redirect they’re using to make sure I get my Google juice.
• It was fun – Perhaps the biggest reason I wanted to do this was because it’s such a simple project and it was kind of a fun exercise for me.

Anyone that is code savvy and is considering doing this – whatever your reasons – I definitely recommend doing it. It was simple and something I enjoyed, and it gives me the control I want in such a simple application. Not every problem makes sense to roll your own solution for, but this is one that does in my mind since it’s so simple.

I honestly wouldn’t be surprised if we see more web services offering their own custom URLs. It allows a bit more brand recognition and all the control issues I mention above. It also seems that short URL services aren’t going away anytime soon.

Do you have any thoughts on the merits of short URL services? Have you written your own or considered doing so?

1. Ask for attendance at a meeting which we’re not really needed at.
2. Assign other work to us – we need more weight on our shoulders in these stressful moments!
3. Ask for some development work to be done on another project – if we have any available time it’ll be spent fixing the urgent issue, so by definition we don’t have time to work on anything else.
4. Ignore our requests for help solving the problem – it’s top priority for us, but your time is better spent asking for updates than helping…
5. Send us multiple emails pointing out how serious the bug is – if we’re working on fixing it already…as fast as we can…a reminder of how urgent it is doesn’t really help anything.

When I say follow through, what I mean is that you can be trusted to do what you say you will do – on your own. One very important lesson I’ve learned is that it’s critical to find people that you can trust to follow through with what they tell you they will do when choosing partners/employees in a startup. It’s also critically important that you can be trusted in this regard as well.

Startups by their very nature have limited resources. Because of this, it is more important than anywhere else that startups are as efficient as possible with these resources. The most valuable resource for a young company is the time of the employees/founders. Since everyone is forced to wear many hats and there is always more to be done, time is often a bottleneck.

If you can’t trust your employees/partners to do what they say they will, then you’re forced to spend cycles on their problems. Suddenly, you need to keep track of their tasks so that you can be sure that they complete them all. You spend extra time checking up on the status of items to make sure they’re being done on time. And most importantly, you can’t give them very much freedom to do their tasks and make them their own because you’re constantly having to check up on them. This ends up wasting a lot of your time and a considerable amount of theirs. You basically end up doubling up your resources on these problems, which is not an efficient way to do things.

Instead, make your first criteria when choosing partners/employees their ability to follow through with what they say they will do. If you can’t trust them enough to assume that they’re doing what they say they will do then you should probably start looking elsewhere. A young company simply can’t afford to have resources piled up on a single problem. You can’t be second guessing other people in the company constantly or you’ll find progress slowing to a halt over time.

Find people you can trust to follow through, then give them the freedom to do it. It’s the most efficient use of company resources, and a lot less likely to cause blow ups between coworkers stepping on each others’ toes.

Here are a couple quick things to test if you trust your coworkers/have follow through:
1.) Do you find yourself frequently doubling back on a task to check the status of an item? For example, do you send a lot of emails like: “What’s the status on ______? Did this ever get resolved?”.
2.) Do you find yourself often asking people to run stuff by you?
3.) Do you find yourself constantly worried about other people’s tasks?

These are solid signs that you don’t trust these people to “follow through” on their required tasks. So make you and your company more efficient; find people you can trust and give them the freedom to complete the tasks on their own. It’ll make all the difference…

A bit slower to rise was the ease of uploading, or contributing new things, to the web. Although downloading has been easy for the average guy for years, it’s really just now starting to get to a place where uploading is as easy. With the rise of WordPress, Flickr, YouTube, Twitter, and IntenseDebate (among others) it’s become progressively easier to upload your content to the web (in whatever form) and contribute.

So please, don’t just consume the internet – help build it by being an uploader too.

• Document.write() method
• element.innerHTML (before element is in the DOM)
• element.innerHTML (after element is in the DOM)
• DOM manipulations on the element (before element is in the DOM)
• DOM manipulations on the element (after the element is in the DOM)

So the first thing to note is that whenever you’re faced with the question of adding/editing html before or after adding it to the DOM you should always make any changes BEFORE adding it to the DOM. The performance difference of this is pretty significant as if the element is in the DOM the browser must immediately render the changes as the edits are taking place. If you modify the html before attaching the element to the DOM, however, the updates stay only in memory and don’t get rendered until the edits are in place.

This is the single most important factor for performance in this task. In fact, the difference is often so drastic (particularly in IE browsers) that in many cases it’s actually better to remove the element from the DOM, edit the contents, and re-attach it instead of editing it directly. This also allows you to sidestep odd inconsistencies in IE with the innerHTML method (in some cases editing the innerHTML attribut7e of an object can cause a browser cache in IE – in particular when the element is a child of a table element).

Now that we know to edit contents before attaching elements to the DOM, which method should we use? In general, the order of speeds of the methods is as follows:

1. document.write() method
2. element.innerHTML attribute
3. DOM manipulations

Document.write is consistently the fastest across browsers and is often the best method to use when it’s possible. The main drawback of this method, however, is that it can only be used during initial browser load/rendering. If the method is used after the page has been initially rendered it will have the undesirable effect of either crashing the browser or clearing the current page and replacing the entire page contents with the write statement instead. This makes it unusable for adding elements after initial page load or editing the contents of an element after page load, but the pure speed/flexibility (it basically allows you to write any html to the page including inline css and javascript – though javascript tags must be written as a combined string instead a standard script tag [for example "<scr"+"ipt>"]) make it an option worth using when possible.

The next fastest method is the element.innerHTML method. This method is very readable and easy to construct quickly in general. One other suggestion is when concatenating strings to form the innerHTML use a temporary variable and apply it to the element only once. For example:
var innerHTML = "<div>";
innerHTML += "Inner Contents";
innerHTML += "</div>";
element.innerHTML = innerHTML;

This speeds up rendering (since it only has to update the DOM/render the change once) and prevents some inconsistencies when using the concatenation/assignment operators in certain browsers.

The last, and by far the slowest, method is to do direct DOM manipulations. This is a broad categorization of using methods like the following:
var element = document.createElement('DIV');
var element2 = document.createElement('DIV');
element.appendChild(element2);
This technique has many disadvantages. It renders slowly as each element is added and styled as it is appended to the DOM. Although you can improve this drastically by waiting to attach the top level element to the DOM until all the inner elements are completed, it still doesn’t compare with the previous methods described above. This code is also much harder to read (in general) than the above methods as each style, class, and attribute of the element must be assigned individually. This also leads to much larger code than the previous methods which adds to download time and parsing time. This method is really only suitable when you’re editing specific attributes or doing very minor manipulations.

And that wraps up the 5 different methods. Hopefully someone out there finds this helpful.