Archive for the ‘Development’ Category
Lazy Loading JavaScript
Most of us know it’s best practice to load your JavaScript at the bottom of the page for performance reasons. The Yahoo! developer network explains the reasoning as follows:
It’s better to move scripts from the top to as low in the page as possible. One reason is to enable progressive rendering, but another is to achieve greater download parallelization.
What typically is not discussed, however, are the potential issues that arise when you follow this development rule-of-thumb. I hope to talk a little bit about this issue and a nice workaround that I like to employ to side step the landmines.
Uh-oh, JavaScript errors
Consider the following code block:
<body> <div> <a onclick="foo(); return false;" href="...">click me</a> </div> <script src="...defines foo..." type="text/javascript"></script> </body>
This complies with best practices for performance, but the astute developer will note that there is a small interval of time between the rendering of the a tag and the script tag. This means for that interval of time, a user could click the link and trigger an undefined function. That’s no good.
This problem is actually more pronounced than you might think. If you’ve ever watched users over the shoulder, you’ll know that some of them can be very click-happy (and they’ve every right to be). They don’t expect to wait for the full page to load before taking an action. Why should they? Isn’t that the whole point of progress rendering?
Also, this is a bug that tends to slip through the developer radars. We tend to wait for the entire page to load when we’re going through our code, save, refresh RAD cycles, probably because something inside us knows to wait for the page to “stabilize” before attempting to test that one feature we just coded up.
Wrong answer (sorta):
Purists will note that the best solution to this is to remove the onclick attribute from the HTML and instead load it during the onload (or DOMLoad) event within JavaScript. This frees up the HTML so it is just content and moves all the interactive stuff into JavaScript (the application layer) where it really belongs.
I’m actually not opposed to this reasoning, but for the purposes of shaving off every millisecond of lag, this solution will not work. There is still an interval of time between the rendering of the link and when the JavaScript attaches the onclick handler. Clicks during this time won’t register JavaScript errors, but they’ll either trigger the actual link or do nothing, depending on what you have set in the href attribute.
If you’re happy with that, great. If not, read on.
An example workaround:
Supposing that foo is a hefty function, we really do want to load it last on the page. This is especially common when foo is part of a larger framework or rides on top of said larger framework. This is because beastly libraries like prototype ought to be loaded last on the page if possible.
We can try the following:
<head> <script src="workaround.js" type="text/javascript"></script> </head> <body> <div> <a onclick="bar(); return false;" href="...">click me</a> </div> <script src="...defines foo..." type="text/javascript"></script> </body>
and in workaround.js:
function bar() { var closure = function() { if (typeof window.foo == 'function') { foo(); } else { setTimeout(closure, 100); } } closure(); }
Oooh, self referencing closures. That’s got to solve the problem just from sheer awesomeness, right? Let’s break down what’s going on.
Instead of calling foo directly, we’re calling bar, a function that we hope is lighter-weight than foo, since we’re allowing bar to be the exceptional bit of JavaScript that is loaded in the header. bar simply checks for the existence of foo every 100 milliseconds until it is loaded, at which point foo is called. Alternatively, onload could be employed, which is typically not as fast as polling every 100 milliseconds. Yet another alternative would be to employ DOMLoad, but you’d have to include extra JavaScript to get a cross browser friendly version.
But wait, there’s more
bar and foo are cute for example purposes, but we really want to generalize the concept.
Try this instead:
function safecall(func) { var closure = function() { if (typeof func == 'function') { func(); } else { setTimeout(closure, 100); } } closure(); }
The calling HTML should be:
<a onclick="safecall(foo); return false;" href="...">click me</a>
If you want to pass parameters, you’ll have to employ closures, not that you don’t want to.
<a onclick="safecall(function() { foo(arg1, arg2)}; return false;" href="...">click me</a>
Geez. JavaScript is powerful. The closures I mean - not the part where I just spent several paragraphs detailing what is essentially a hack.
Conclusion
We’ve defined a function safecall that can be defined as the sole script in the head tag which can be used to protect unloaded JavaScript that is sitting at the bottom of the page. Hopefully this will solve someone’s development headaches trying to fix all those new JavaScript headaches when someone in the office decided it would be cute to move scripts to the bottom of the page.
Freelancing for Money
There was an interesting article I came across titled “12 Killer Ways to Make Extra Income On the Web“. The article is interesting because there was only really 1 killer way that is even worth mentioning, and that is “Freelancing”. All of the other recommendations are either a waste of time or require much more effort than simply getting paid to produce good work. The age old “do-work-for-money” will never go out of style. If you’re good at what you do, of course you should be getting paid well to do it.
However, like all marketable things, your personal time is something that you should price with careful consideration. Unfortunately, there is one business model that is cropping up across the web that is counter to this. These sites (typically targeted towards logo or web design) allow you to submit entries for a chance to win a small cash amount ranging from several hundred bucks to maybe a thousand dollars for a winning entry.
Without being religious about NOSPEC, my advice is to steer clear of these “contests” unless you are simply trying to get your feet wet with design (or whatever industry you’re jumping into). There are various reasons that people throw around, but in my opinion, if you don’t value your time and effort, why should the client? If you really undervalue your work that much, maybe it’s because you consider yourself an amateur and not a professional. Also, on the flip side, clients that flock to these sites typically have no appreciation for the good work that professional designers can produce. As a friend of mine once aptly described it, it is like these folks couldn’t tell the difference between interior design and interior decoration.
Show respect to your own profession, lest you sarcastically post a blog entry entitled “Why I hate freelancers.” Whether it is web design or software development the good clients out there are looking for real professionals, not amateurs.
The Seven Archetypal Software Projects
Throughout any given software developer’s career, I think he or she is bound to run into a few archetypal projects. Some are good projects to have experienced, others not so much. Either way, I find these are the projects that offer up the biggest smack-in-the-face lessons.
I also find that the order I’ve laid out below tends to mirror the progression of a software developers career chronologically as well.
The school project
I love this one, because this is where a large number of hackers become “software engineers”. Or so says the industry and HR people. The only reason I value this type of project is because it’s such a stark contrast to how development happens in the real world. Somehow, the particular mix of apathetic group members + hero group member + late nights in the computer lab makes for good memories to reminisce after you’ve been in the software industry for a while.
The “I can do that in a weekend” project
Don’t lie - the first time you saw twitter you said, “I can write that and more in a weekend.” Maybe not twitter, but we’ve all run into successful apps and scratched our heads pondering what the big deal happens to be. So go ahead, write it. Build that app. Then eat dirt. I find this is the fastest way to learn that 1. no, it’s not that easy, and 2. even if you built and launched a me-too app, no one cares.
The “I’ll build it from scratch” project
This is another one too many of us have had the guilty pleasure of partaking in. Instead of taking well-known and well-document open source solutions already out there, you decide you can do it better yourself. More often than not, you walk away with a new appreciation of that whole shoulder-of-giants saying. Then you start shopping.
The “other platform” project
Everyone gets curious about the greener grass on the other side. So appease the need. If you’re a *nix/apache type, give .NET a shot. If you’re the .NET type, give open-source platforms a shot. Loving Java? Try C#. RoR expert? Give Django a shot. Learning both sides is not so much for gaining actual experience as it is for gaining perspective. My personal experience has shown that you just might stay on that new platform. (Of course, most of my experience has been of the Microsoft camp going open source.) At worst, you’ll know you validated the choices you made going into your current setup.
The “coding as a job” project
If you haven’t already, get a job (at least once). It’s a quick shot of reality and harsh perspective. It helps you realize what engineering in the wild is like. Product managers, program managers, project managers, mid-level managers vs. you. It helps you realize whether working in a team is your strength or your weakness. It helps you learn to curb that ego of yours. It makes you appreciate just how difficult running a business is, aside from the technical side of things. Observe the sales people, watch the BD team. Learn their tactics, their way of doing things. It will make you a more well-rounded individual. If nothing else, you’ll learn what kind of software and services the suit-and-tie crowd really need.
The startup project
The beauty of software is that everyone’s got an invitation to start something up. This is more than just a “all the cool kids are doing it” thing - I feel that everyone should try to build a project (and eventually product) that brings real value to people. In fact, try charging for it. Nothing validates your ideas, concepts, beliefs, and ambitions more than getting others to give attention to what you’ve got to say or sell. If you fail, no big deal - you’ve learned something valuable and chances are you lost nothing but a few weekends and hosting money. If you succeed, well then it’s all the more rewarding.
The open source project
This is where the “end-game” of software development happens. You go through life looking for projects to be passionate about. You’ve gone through school and pulled through the grind. You’ve tried the whole day job thing and you’re either feeding your family or you’re looking for a new cause. You’ve done your own start up, for better or for worse. In the end, you begin to realize nothing is better than sharing your great hack, tool, technology, algorithm, framework, project, or application with the world. I find that the sense of accomplishment that comes with open source projects spans the spectrum from being the sole maintainer of tiny, obscure plugin to being a drop-in-the-bucket contributer to a massive framework.
Making Money, 1880 vs. Now
I ran into this little gem today: Golden Rules for Making Money by P. T. Barnum (1880). It just proves nothing changes when it comes to the fundamentals of making money. However, these days, there’s an extra word, instead of “Making Money”, it’s now “Making Money Online”. Just ask David Heinemeier Hansson, he was even compelled to give a talk on the subject.
Well let’s see what the new-age twists are on these Golden Rules. What changes to P.T. Barnum’s rules when we apply web 2.0 logic to it? Half-seriously, I call it Golden Rules for Making Money 2.0 (web entrepreneur edition).
- Don’t mistake your vocation -> Hackers should code, designers should draw stuff in Photoshop, and Businessmen should sell and give VC pitches.
- Select the right location -> Move to the valley. Or at least be in India or China.
- Avoid Debt -> Splurge on someone else’s dime. Get VC money.
- Persevere -> “Startups rarely die in mid keystroke. So keep typing!”
- Whatever you do, do it with all your might -> Stick with Ruby.
- Depend on your own personal exertions -> Take as few partners as possible. More sweat equity.
- Use the best tools -> Stick with Rails.
- Don’t get above your business -> Release early, iterate often.
- Learn something useful -> Learn Scala or Erlang on the side.
- Let hope predominate but be not too visionary -> Do something small …
- Do not scatter your powers -> … and do it well.
- Be systematic -> Switch to 4 day work weeks.
- Read the newspapers -> Read Blogs.
- Beware of “outside operations” -> Don’t blow your exit money on another venture. See rule 3.
- Don’t endorse without security -> VCs: invest in people with previous exits.
- Advertise your business -> Use Google Adwords.
- Be polite and kind to your customers -> Offer email and phone support.
- Be charitable -> Open source parts of your code.
- Don’t blab -> Get IP. Enforce it.
- Preserve your integrity -> Don’t comment spam or SEO spam to get traffic.
See? It’s basically the same thing nearly 130 years later.
8 tips for “scaling” CSS Development
Effective development of any project (whether web or otherwise) requires effectively “scaling” the code-base. The experienced shops like Amazon break their code into services - modular components that are easy to understand and maintain by a small group of developers. I don’t need to hark on the benefits of modularity, but one can never overstate the importance of having a “shallow” code-base. The best software architects know this, and the big shops apply these techniques effectively.
However, from my observations, CSS always tends to get left out of good code-base architecting. That’s probably because designers who work with CSS only do it as a means to and ends - getting a pretty and usable design, while developers who work with CSS couldn’t run away from it fast enough. It’s stuck in some void where people approach it with a 10-foot pole.
Oddly enough, it’s CSS that is often in most need of solid architecting. After all, the “language” (if you can call it that) sucks, was poorly designed, doesn’t work consistently in most browsers, isn’t DRY, and makes people want to take a sip of the old table driven kool-aid once in a while.
Here’s how I approach the problem:
- Break your CSS files down. Give your CSS files short, easy to understand names. “basic.css” is not a good name. What’s basic about it, exactly? “main.css” is a poor name. Is it the main CSS file or CSS for the page called main? I like to use “common.css” for CSS patterns (more on that later), “style.css” for styling only (more on that later) and “x.css” for pages called x.
- Use an asset manager. This goes with number 1. Breaking your CSS down into small chunks means more round-trips if you <link> each stylesheet. Go with an assest manager to bundle all those files for you. For example, try bundle-fu for Rails.
- Separate styling and layout. Styling is what your <em>s <strong>s <h1>s look like. Layout is probably specific to the page. Get detailed. “styling.css” can be for basic HTML elements, “styling-modules.css” can be for styling specific to reusable modules, etc. Developers call it separation of concerns. CSS designers call it sanity.
- Don’t put IE specific hacks into their own file. (Only do this if you don’t care about validation.) This flies in the face of convention wisdom. Well, the next time you’re wonder why something looks different in IE after pouring through your CSS, only to realize 30 minutes later that something’s inconsistent in “ie6.css”, don’t forget what I told you here. IE specific CSS files are un-DRY. Instead, put the hacks as close to the non-hacked CSS as possible and document it.
- Use common patterns. People spent countless hours on things like clearfix and the holy-grail so you don’t have to. Put these common patterns into their own file (I like common.css and common-layout.css) and don’t mess with that file.
- Use a reset. This is an extension of #5. Resets means your CSS works tabula rasa. No more wrestling with inconsistent browser defaults. Try these reset rules. Make sure you document any exclusions for bandwidth saving reasons.
- Use white-space effectively in CSS files. This one doesn’t work for me, but I’ve seen people swear by it. Use indentation to mimic the DOM hierarchy when you’re doing complex selectors.
- Document CSS like you would document code. And realize that sometimes the best documentation comes from having well thought out CSS in the first place, just like how good code documents itself. If you’re working in an environment where many people are touching the same CSS files, having everyone understand the organization (see #1) is the only documentation you’ll need.
I’m sure there’re are more best-practice approaches to “scaling” CSS so that more than one person can work on it without going bananas, but these work well for me. Heck Ronin only uses a subset of these rules, and it’s already saving me my sanity. Google around and maybe you’ll find more to add to this list.
Gathering user feedback
The mantra of the web 2.0 app is to release early, iterate often, and repeat. A big part of the “iterate often” though, can be confused for rolling on your own intuition. Even a great dog-food eating developer won’t be able to guess exactly what his or her customers want. After all, every individual is different.
This past week, the buzz in the developer world was/is Jeff Atwood and Joel Spolsky’s stackoverflow.com. One particular off-topic item that immediately caught my eye was the floating “Feedback” tab on the left side of the screen. I thought this was brilliant. It was an personal invitation for users of the site to express their opinions and cast their vote on suggestions for improvement.
After clicking on this Feedback tab, I realized that this was a service provided by UserVoice. The folks at UserVoice have come up with a simple, easy-to-install widget that every web service out there can take of advantage of to quickly gather valuable user feedback. Brilliant.
Being a big fan of gathering feedback for product direction, I decided to look into it for Ronin. By the time I hit publish on this blog entry, you’ll be able to find the Feedback tab in your Ronin account. Use freely.
Big things come from small ideas
I’ve been a part of quite a few startups with varying degrees of involvement. I’ve been a part of them, studied them, worked for them, observed my friends involved in them, heck, even started them. I’ve watched them grow, watched them plateau, watched them die. If I had to distill my entire experience with start-ups into one rule of thumb, it is that start-up life is a roller coaster. A manic-depressive roller coaster.
No seriously. You are not ready.
One minute you’re going to take over the world, and the next you’re doomed. The problem with feeling you’re doomed is not just that it makes you unhappy, but that it makes you stop working
This cliche metaphor about roller-coasters is not news for anyone who’s read anything about the scene - it pretty much goes in one ear and out the other for the entrepreneur. However, I find it only really hits people hard when they get a taste of the roller-coaster of emotions first-hand.
I’ll be the first to admit that I had very little understanding of just what this roller-coaster feels like. When I was 17, I had my first experience at “entrepreneurship” building a small Windows application that was simple music production tool. In retrospect, it didn’t stand a chance, but I was young.
At the time, it was project of love. I didn’t necessarily want it to become a business - I just wanted people to like it. But, I think somewhere along the way, ambition snuck-in and turned it into more than just fun. I would devote time every day to working on my code. I would scour the internet seeking best-practice advice from peers twice my age. I would dream about features to be added in between classes. I would gather feedback from close friends - all in a very self-assuring feedback loop. Being young, every line of code, every keystroke, was fueled with “what ifs” - tell-tale signs of foolhardy ambition.
What-ifs are always escalating. What if my friends really love my app? What if it gets the attention of a small group of people? What if garners the adoration of hundreds of users? Thousands? Tens of thousands? What if people like it so much, I’d be able to pay for college just on software sales? Maybe even make a living off of it? Maybe it’ll make it big and I’ll strike it rich? Ah, the possibilities. The upwards roller-coaster was in full effect.
The way down is a lot less fun. It sucks. You begin doubting things. You begin to doubt your creativity, your reasoning, your abilities. You start to wonder if all that hard work you put in was worthless. The proverbial cloud is draped all over you for a long time and you begin to do more second-guessing than hacking.
… And then something good happens. Either some new development arises or you’ve got a great new idea. Either way, you’re back on the roller-coaster.
Looking back on that experience (and the many between then and now), the greatest thing that came out of it was my growth as a person. I learned to appreciate the art of programming - setting me up for a future in computer science and software engineering. I learned to appreciate balancing personal life, with project life, with school life, and what eventually became career life. I learned that the rewards for writing software can be at a personal level - almost spiritual. I learned that the roller-coaster ride is tough. These learnings are constant; they’re everlasting. Good lessons are roller-coaster free.
The reality is, your wildest imaginations about the possibilities for your projects never come true. This is especially true in the current Silicon-Valley start-up climate. Everyone thinks that with a few lines of code, they’re going to be the next Big Thing. Dream on. If you’re thinking you’ve got some secret sauce that will take you to the top in one shot, you are just waiting for that roller-coast drop to bite you in the ass.
Instead, get real. Get realistic. The best way to avoid the fall is to never let your head get in the clouds. Start projects on small ideas with the realization that the most you can ask of it is that you’ll enjoy working on it, that you’ll learn a lot about your craft and your own abilities, and that you have a very good shot creating something great for like-minded individuals. The greatest success will eventually come from a series of small steps. But that takes the realization that sometimes, the greatest success is not financial, but personal as well.
In an oft-quoted blog entry, Chris Wanstrath of GitHub writes:
I didn’t just walk out of high school, pick up a Ruby book, meet Tom and PJ, then launch the site GitHub. Before GitHub came, in chronological order, Spyc, Ozimodo, my ozmm.org tumblelog, ftpd.rb, Choice, Err the Blog, acts_as_textiled, Cheat!, acts_as_cached, Mofo, Subtlety, cache_fu, Sexy Migrations, Gibberish, nginx_config_generator, fixture scenarios builder, Sake, Ambition, and Facebox. And that’s just the stuff I released.
In About Us, I described that “we want to do something small, something important, and something really well”. That describes Ronin as a culmination of the ideas I’ve described. Ronin is not a roller-coaster ride. Ronin is a labor of love - not a shot at a billion dollar business. I only ask that it provide me with more learnings, more experiences, and good people to work with. I hope that idea resonates with both the people who enjoy Ronin as a product and the people who read this blog entry with ideas for projects of their own.
