What I wish I’d known
Posted by Jon on Apr 24, 2008
Josh Fraser and I were discussing the other day the little tidbits of knowledge that we wished someone would’ve told us on day one instead of having to learn them on our own (later than we would’ve liked). He wrote a post here which highlights 5 specific things he wished someone would’ve told him. I’m going to chime in on the 3 he mentions that I also learned the hard way and then add in a few of my own to round it all out and add a tiny bit of originality rather than just steal his post 
So first off, his three that I’m stealing.
1.) UTF-8…just do it! It’s surprisingly easy to get your application to handle utf-8 encoding. Spend the extra 15 minutes up front to figure it out and save yourself the headache because you’ll have an international audience much sooner than you think.
2.) Memcache…it’s a beautiful thing. Memcache is a drop dead simple caching system. This is another one that’s worth spending the 15 minutes to learn how to set it all up as it will be hugely valuable down the line. I agree with Josh that it’s not a must have on your initial prototype, or even when you first roll out into production, but plan for it like you will so that when you do need it it’s as simple as possible to integrate. Many people use memcache in different ways, and there isn’t one use case for it that you have to follow. Just spend the time to think through what the items that would benefit the most from caching would be, and then leave an easy integration point (a specific function call comes to mind) for later on when you do want to implement it.
3.) Email is slow…send it later. Especially if you outsource your email, there will often be a noticeable latency when you go to send your email. When you’re just showing off your product to your friends this probably won’t be a big factor, but as you start to send more and more mail this latency begins to become a problem. Instead, setup a mail queue for post-precessing from the get go and send out the mail that way so that the latency isn’t as big of a factor.
Now for my own contributions:
1.) If you make a widget, the hosts file is your friend. This is a bit hard to explain, but basically, the idea is that you setup a devel server and then when you’re testing, modify your hosts file to resolve your real hostname to the devel server instead. So for us, we redirect www.intensedebate.com to our devel server via the hosts file to do testing. The advantage of this is it allows you to load the devel code on someone else’s blog (provided they’ve installed your widget of course) so that you can do real world testing before it’s ever released. I can’t over emphasize how valuable this is for a widget based product. You can see how all the other crazy js, css, etc on their blog will affect your application without your users ever knowing. Awesome.
2.) If you make a widget, spend some time learning basic JS optimization techniques. For example, is it fastest to create elements using the dom, use the innerHTML property, or document.write? How does the number of individual HTTP requests affect the load time? Etc. These simple techniques, if applied up front, can save you a ton of headaches down the line as speed and performance are critical in a widget.
3.) 90% < 0. Ok, so the math major in me had a really tough time learning this one. What I mean by that is that if your product/feature works 90% of the time, it’s worse than if you didn’t have it at all. The reason for this is that people expect stuff to work. So when your product/feature works, no one writes about it and nobody cares. If your product/feature doesn’t work, however, people freak out. Most are a lot faster to write a blog post complaining about something not working than about how it worked as expected. So if you can only get 90% accuracy, don’t release it…it may seem that it’s better to please the 90%, but in the end it’ll get you no where.
So that’s my take. Got another tidbit you wish someone had told you? Leave it in a comment for everyone’s benefit.
Greasemonkey to save time
Posted by Jon on Apr 6, 2008
I’ve been playing with Greasemonkey again. For those that don’t know already, Greasemonkey is a Firefox add-on that lets you run javascript scripts in the browser to execute on various web pages. The scripts can be excluded to only run on certain pages, allowing you to modify the page’s contents, perform actions, etc.
I played with Greasemonkey a while back, and thought it was really interesting, but I couldn’t come up with a lot of practical applications for it at the time. The add-on came up in a conversation I was having with someone, and as a result I decided to revisit it. I still haven’t come up with anything amazing to do with it, but I have been finding it increasingly helpful to cutout a few clicks in my daily web browsing. For example, I now have it submit forms on login pages to automatically log me into sites I visit often. I also have it setup to navigate to a page from a site if I often go to the same page after login. For example, maybe you get dumped to a landing page when you first login, but you always want to go to a specific section right after that. In this case, I’d setup a script to run on the page that I land on that automatically takes me to the second page (that I really wanted to go to) instead. These kind of things might sound silly, but most often they’re a single line of js and they can save me a couple clicks a day. Those clicks add up! Not to mention the ease of use factor, since I don’t have to be annoyed by the fact that I have to find the silly link every time I login.
For any of you out there that know even a hint of JS I’d really recommend checking it out. It can be a great time saver on these little, trivial things and make your web browsing that much easier.
Entries RSS