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.

So first off, why do we care about front end optimization? Take a look at the breakdown for Amazon.com as an example (click the image for a larger view):

The red bar represents the time it took to serve and download the core page from the server (920ms in this case). The rest of the 6.34s is spent downloading images, css, js, and rendering/executing it all. Clearly there is plenty of room for optimization on the front end. (Note: many of the requests have been stripped from the screen shot – limited only to HTML requests – for brevity.) This is just for Amazon – many other sites are even worse ratios for front end vs. back end load time.

Now that it’s clear that there is optimization to be done, how does one get started? I’d recommend getting started with a couple basic tools right off the bat. Here’s my short list:

• Firebug – great addon for Firefox with tons of features helpful for front end optimizing (among other things)
• YSlow – an addon to an addon, YSlow extends Firebug to give it a new tab with a bunch of handy features. It also has some tips built right in and will tell you which you’re doing and which you’re not
• HttpWatch – an HTTP traffic sniffer for IE.

In my next post I’ll start covering some basic techniques to improve performance. Got a tip of your own? Let me know in the comments.

Let’s get the punch line out of the way: cloud computing is coming…so deal with it.

Skeptics cite a handful of reasons why this is purely “hype” as opposed to the way of the future. Mainly the issues around reliability, accessibility, security, and performance. I’ll deal with each of these points individually.

Reliability is no doubt an issue currently. When one looks at sites like Twitter and the issues surrounding it, it is no wonder that this is a major concern of the skeptics. It’s important to remember, however, that we’re in the early stages of this transition. Looking back on the initial digital revolution the computers of the day weren’t very reliable either. Computers would crash and lose the active document, hardware would fail losing all the documents on the computer, and we still constantly face issues around viruses and data corruption. As time has gone on, however, we’ve found solutions to most of these problems. Word (and many other applications) have periodic auto-save and document recovery features, software has gotten more stable over time, hardware has built-in monitoring to warn of pending failures, and anti-virus has matured while data-redundancy options have begun to go mainstream. Similarly, the reliability issues around cloud computing will evolve over time. The network will become more reliable, the individual sites will be held to a higher standard of up-time, and data redundancy will become a trivial task built in to the libraries the applications are built on top of. There are possible early examples of this already available using solutions like Amazon S3 and Google AppEngine that aggregate the needs of many applications to take advantage of economies of scale. As the cloud computing applications mature and become more wide spread the issues around reliability will diminish until web apps are no more or less reliable than their desktop counter parts.

Accessibility is another commonly cited example. What will we do when we don’t have access to the internet? How will we use these applications? My answer to this: A long time ago, we didn’t have laptops. Instead desktops (and their corresponding data) was trapped in that single location on that single machine. As the technology matured we got cheaper desktops that we could buy for personal/home use and laptops that we could take with us anywhere. This freed users to use their applications wherever their hearts desired. It’s easy to see that internet connectivity is getting more and more wide spread. Wifi is everywhere and access to cellular networks is filling in the gaps. As this trend continues it’s easy to see that internet connectivity will one day be available wherever electricity is available (which we often take for granted now). In the transition, however, we’ll continue to see development around projects like Gears that allow users to take their web app experience offline and re-sync when the internet becomes available. Accessibility is an issue fading fast and will fade even faster as the trend continues.

The issues around security are real and worth noting. Having data accessible via the internet means it’s accessible to everyone on the internet if the proper security isn’t in place. Although the internet isn’t exactly built for security there have been huge leaps in this area over the last few years. As encryption becomes more prevalent and new systems of multi-authentication become widespread we’ll see many of the same types of security issues we’ve faced with laptops come and go in the web space. Ultimately many of the security issues will come from user-error and social engineering, not software failure. While this is significant, it’s important to note that these same issues would be faced on a traditional desktop application and/or even pre-digital revolution data storage (old school papers and files). The biggest holes in security will continue to be in the people accessing the data, not the systems in place to protect it.

And lastly, performance is a commonly mentioned issue. Web apps have a reputation as being a bit slow and clunky. This mostly stems from the fact that these applications are built in JavaScript which is a powerful, but dated system. JavaSscript is interpreted, which makes it run much slower than compiled counter parts. As the technology matures, however, we’ll see the same trends we saw in the desktop space: initially the improvements will come from clever programmers and minor improvements in the processing of the code itself, but over time the hardware improvements will out-pace the software changes allowing the same applications to run faster on the new hardware/platforms (in this case it’ll most likely be a combination of hardware improvements and browser enhancements). The performance woes will subside as we see the line between the client and the server blending (as made possible by the technical enhancements previously mentioned).

In summary, although there are some real issues around the current state of cloud computing many of these issues aren’t all that different than the issues we faced in the initial digital revolution. And, just like in the previous revolution, these concerns are far out-weighed by the advantages of the cloud computing model. The accessibility of having your data and your application available from any internet enabled device is very powerful. Add to that the advantages of direct, digital distribution (software updates are seamless and immediate…dramatically lower distribution costs as everything moves to digital downloads) and you’ve got a real force behind this movement. Watch for clients to become simpler, more prevalent, and the emphasis to move more to form factor and usability as opposed to power and performance.

The cloud computing revolution is coming…might as well embrace it.