So far in our discussion about what drives really good modular coding, I’ve presented override coding logic, and emphasized the importance of legibility and writing standards. I’ve found both concepts critical to my own coding for one big reason: they allow me to limit the number of assumptions I must make on the part of my users and fellow developers. Let’s back up a bit. Every coder has some understanding of how assumptions work in programming (or at least you should; if you don’t then listen up).
I’m a huge fan of Jeff Atwood and his blog, Coding Horror. He writes in a very approachable manner, using a down-to-earth tone and easy-to-follow examples. He offers useful information to new and experienced coders alike. It’s the one blog I am sure to check on a daily basis. On more than one occasion, Jeff has made an insightful post about a topic that was paramount to a project I was working on.
My last post discussed my conversion to JavaScript frameworks, and why you should be one too. I explained that I settled on jQuery because it simplified how I write JavaScript without strictly locking me into a set of features and effects. A core part of this flexibility comes from jQuery’s document ready wrapper. It works like window.onload(), but provides a quantum leap in functionality. You can find more details at the link.
For those of you who don’t know, “veterinarian” is Latin for “hellish education gauntlet.” Anyway, today was my wife’s last day of veterinary school. I just got a phone call from Jennifer saying that she is on her way home, which means she’s done! Congratulations, sweetheart, I’m so very proud of you.
We’ve been really into jQuery at our office for the past few weeks, and I have to say that I am absolutely in love with it. Coming from the world of writing “classical” JavaScript in “long-hand” format, jQuery appears damn close to magic; I half-expect a mystical gnome to pop out of my monitor when I use some of the more elaborate jQuery techniques. It’s that good. If you still do JavaScript old-school, I would urge you by any means necessary to pick up and learn one of the several standardized JavaScript support libraries.
In the first post of my modular code series, we talked about overrides and how they are an important, and often overlooked, feature to consider in any code project. Today we will discuss an equally even more important concept: Ensure that others can quickly and easily read and understand your code. What? Seriously? Yes. Writing clean code is much like any other type of writing exercise, but with slightly different rules.
This weekend is the first ever Zen Cart Developer’s Conference, and I am very happy to say I will be attending. Saturday is a meet ’n greet between the founders and some of the community developers. Sunday is a public forum for any Zen Cart enthusiast to come out and meet the team, the developers, and each other. If you plan on attending, I look forward to meeting you! I actually have the special privilege of presenting to the founders a new concept that could make its way into the Zen core code.
If you code long enough, you’ll eventually hear that you should write your code in a modular fashion. Problem is, the ivory tower sage who told you to do that can’t communicate beyond the proverb. So starting today, over a few posts, I’ll lay out in hardcore concrete terms what the heck it actually means to write modular code. People usually start trying to explain modular code from the perspective of object oriented design, or “OOP.
Though developer by trade, I think I can talk CSS fairly intelligently with any hardcore designer. But the one thing that always eluded me a bit was the “em” sizing element. I could never find a definitive description of just how the hell they actually worked. Today I put that one to bed, thanks a straightforward article on A List Apart…
Working from a default of 16px, the following styles should give the desired text sizes:
The latest trend in perfecting “the message” in the internet age has been to optimize content for search engine indexing, aggregation, and delivery through the voodoo of search engine optimization – SEO. Let me be plain: I think most sites and web services are spending too much time worrying about what the Google crawler sees. I can hear every one of you website statisticians howling at me right now. “We get so much traffic from Google results, it just doesn’t compare to direct hits.
