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.
