04.23.12 |
∞
I liked developer Chris Coyier’s approach here; step back and examine how to serve up responsive imagery from a high level perspective. Chris touches briefly on all the proposed solutions, from creating new elements to client side Javascript.
On the not so cool side, Chris avoids taking a stance on which solution he’s siding with. I personally prefer a new image element or HTML5 based custom data attributes that the browser interprets to render the properly sized image. The other cross browser methods are admirable but ultimately make too many http requests for me to be comfortable with.
04.18.12 |
∞
Javascript based graphing libraries have been done before, but I’ve rarely seen graphing code this clean, straightforward or well documented. Worth a look.
04.17.12 |
∞
As a mostly front end web developer that dabbles heavily in design, I’ve stayed away from node.js. It’s just been something that’s I’ve associated as too server side and back end intensive; I roll with it myself to check my Javascript via JSHint, but little else. That opinion may be changing though with programmer Randall Degges essay here.
04.13.12 |
∞
David Hansson, 37signals:
Every line of code you write has a cost. It takes time to write it, it takes time to update it, and it takes time to read and understand it. Thus it follows that the benefit derived must be greater than the cost to make it. In the case of over-testing, that’s by definition not the case.
Think of it like this: What’s the cost to prevent a bug? If it takes you 1,000 lines of validation testing to catch the one time Bob accidentally removed the validates_presence_of :name declaration, was it worth it? Of course not.
I see a huge amount of admonishments online for developers who don’t test enough. David approaches the problem from the other side; when does testing get out of control?
04.12.12 |
∞
JavaScript engineer Rebecca Murphey:
Once upon a time, editing files, testing them locally (as best as we could, anyway), and then FTPing them to the server was the essential workflow of a front-end dev. We measured our mettle based on our ability to wrangle IE6 into submission or achieve pixel perfection across browsers. Many members of the community – myself included – lacked traditional programming experience. HTML, CSS, and JavaScript – usually in the form of jQuery – were self-taught skills.
Something has changed in the last couple of years. Maybe it’s the result of people starting to take front-end dev seriously, maybe it’s browser vendors mostly getting their shit together, or maybe it’s front-end devs – again, myself included – coming to see some well-established light about the process of software development.
Whatever it is, I think we’re seeing the emphasis shift from valuing trivia to valuing tools.
Impressive compilation of JavaScript tools, tutorials and more. Complete newbies should make a beeline for the in-browser developer tools section. If you aren’t debugging in the Chrome Developer Tools or Firebug, as far as I’m concerned, you’re not breathing as a front end developer.
04.12.12 |
∞
Like the author suggests, when deadlines are tight I can get lax on proper CSS sprite usage. Author Niels Matthijs helps remedy this problem with some best practices. I’m not entirely onboard with this article, as there’s heavy usage of LESS and Sass, two CSS preprocessing languages I have decidedly mixed feelings about. Nevertheless, I really liked the first section of this article which deals with splitting out the sprite in Photoshop, and the LESS/Sass material later on at least gets one thinking about sprites more programmatically.
04.09.12 |
∞
I'm increasingly seeing placeholder label free forms proliferate online; it's inevitable given the Apple Store's heavy usage and the form style's compact, minimal approach. Yet in the process, developers shouldn't forget the basics; nice tip here by 456 Berea Street.
10.19.11 |
Technology |
∞
Sometimes the smallest of changes can deliver a huge impact. In my case, several weeks ago I switched away from the popular Mac text editor TextMate to Sublime Text 2, giving a significant boost to my productivity in the process.
Some context is necessary here: any web developer can tell you that, with the profession’s focus on coding, text editors are generally the most important tool at hand. For the last five years, TextMate was my editor of choice and I depended on it for effectively everything at work: HTML, CSS, Ruby on Rails, even extended emails and design notes. I loved the speed, the keyboard shortcuts and its slick bundling system – macros, commands and templates came together in a unified package.
But ever since Mac OS X Lion came out, TextMate’s lost a lot of its luster. The downward spiral began with the program’s incompatibilities with much of Lion’s new functionality; this only amplified the nagging suspicion TextMate would never receive a significant upgrade (its last significant release was version 1.5 back in January 2006.) The TextMate team unexpectedly announced a public alpha of TextMate 2 for release before the end of 2011, but I think it’s a case of too little, too late.
Continue reading…