Danny DeBelius

Andi Smith:

Historically developers have used Firefox’s Firebug add-on to develop and debug their websites, but more recently each browser has developed its own set of tools and each comes with its own advantages and disadvantages. Nowadays it seems hard to imagine ever building a website without one of these handy tools, which are normally accessible by either pressing “F12″ in Windows or “Cmd” ⌘, “Option” ⌥ and “I” on the Mac, or by right clicking on the page and selecting “Inspect Element”.

But are you using the developer tools to their full potential? The biggest positive about the developer tools is that they are incredibly easy to use, but as a result developers often miss out on a large proportion of the functionality provided. Inspired by a video talk by Paul Irish and Pavel Feldman, I’ve compiled a list of “secrets” of the developer console. I’m not expecting every one of these to be unknown to you, but hopefully some of these will help you to become an even better web developer.

My favorite Chrome trick is clicking to flip through the various methods of describing a color.

The guys at ZURB have built another nice responsive-grid framework to add to the rapidly growing list:

Foundation is a rock-solid, responsive framework for rapidly prototyping and iterating into production code. It includes a 12-column, future-friendly grid and tons of great tools and elements that’ll get you up and running in no time. Clone the repo to get the marketing site, docs, and base source. You can also visit http://foundation.zurb.com to download just the base source as a starting boilerplate.

Along with the responsive grid, Foundation features ZURB-flavored buttons, forms, tabs, pagination, tables, image sliders and modals. The global CSS also includes baseline typography, though this isn’t described in the documentation.

/via Yuri Victor

Jonathan Snook:

SMACSS (pronounced “smacks”) is more style guide than rigid framework. There’s no library within here for you to download or install. SMACSS is a way to examine your design process and as a way to fit those rigid frameworks into a flexible thought process. It’s an attempt to document a consistent approach to site development when using CSS.

Jonathan has generously shared some great tips for sane and disciplined large-site CSS architecture with this web book. I’m looking forward to absorbing what promise to be some very useful approaches.

Jeffrey Way:

I consider Sublime Text 2 to be the spiritual successor to TextMate – particularly when the likelihood of TextMate 2 coming to fruition becomes bleaker and bleaker. When Duke Nukem Forever is released before TextMate 2, you know you’re in trouble! But that’s okay, because Sublime Text 2 is one of the fastest and most incredible editors to come out in a long time! I’ll show you my favorite tips and tricks today.

I’ve been using Sublime Text 2 for the past few weeks and TextMate is fast becoming a faint memory. No, the feature set is not identical, but I am optimistic that the holes will be filled in short order once Sublime Text gains some traction in market share.

Stijn Debrouwere:

I have to admit, even for a zen-like chap such as me, it’s still quite the mental effort to repress knee-jerk reactions about the tools and programming languages other people use. Perl is for dinosaurs, Ruby for hipsters, Haskell is useless outside of academia, C is for masochists, C# for corporate drones. Computer programmers have probably been waging these kinds of petty religious wars since the dawn of computing. It’s harmless bickering, and not entirely unexpected since each of us has invested so much time into learning to properly use the tools we’ve chosen. Nobody likes to be told they’ve not chosen wisely, but everybody likes to tell everybody else about their own wise choice. It’s a silly but harmless social phenomenon.

Undoubtedly, we’ve all seen this pattern at work in ourselves or our peers, and a healthy awareness of our tendency toward religious devotion to our toolset will do us much good.

Don’t miss this great write-up of the new photoset functionality Tumblr recently rolled out:

Tumblr’s new Photoset feature was hinged on being able to quickly display high-res images in an interactive lightbox slideshow. You can check out an example with my dog.

After solidifying the design, we spent a couple days doing everything we could to improve the real and perceived responsiveness. Here’s what we learned along the way.

Fresh out of the oven from Mark Otto and Jacob Thornton, Twitter Bootstrap could significantly cut the lead time required when spinning up your next web app. The form elements and notifications are particularly gorgeous.

From Mark’s post on Twitter’s dev blog:

In the earlier days of Twitter, engineers used almost any library they were familiar with to meet front-end requirements. Inconsistencies among the individual applications made it difficult to scale and maintain them. Bootstrap began as an answer to these challenges and quickly accelerated during Twitter’s first Hackweek. By the end of Hackweek, we had reached a stable version that engineers could use across the company.

With the help and feedback of many engineers, Bootstrap has grown significantly to encompass not only basic styles, but more elegant and durable front-end design patterns. This release represents our first public 1.0 release and the open sourcing of many months of hard work.

It’s Christmas in August for all you Chrome-loving web devs:

Ever want to change the look of your Google Chrome Web Inspector? I personally love being able to customize the “theme” or “brush” of my favorite IDE and my Web Inspector is no different. If you’ve ever done some snooping around Google Chrome’s Web Inspector you may have noticed that it’s made of straight HTML + CSS + JavaScript. My buddy Paul Irish was the one to show me how you can “inspect” the Inspector (very Inception-esque).

Be sure to add this snippet from the comment thread to make the block expand indicators more visible.

/via Dave DeSandro

There are a few gems in this post by Chris Zacharias, formerly of YouTube, on the topic of finding quality front-end engineers:

3. Good front-end engineers list Javascript on their resume, not jQuery. I do not mean to pick on jQuery, but it certainly was the most popular Javascript library referenced on resumes from my experiences. Bad front-end engineers are dependent on jQuery and other libraries. Good front-end engineers make use of libraries like jQuery to empower themselves, but are not beholden to them.

In his experience, too many candidates went straight to plugins for the simplest of interactions. Working at the Sun has been educational for me on the scripting side since our library of choice (MooTools) doesn’t have the robust third-party plugin ecosystem of jQuery, so a lot of interactions have to be built from the ground up. I’m definitely working to become more proficient in Javascript independent of a library, but this can be tricky in the day to day at work since we are committed to MooTools for our applications.

4. Good front-end engineers are artists. Nearly every first rate web developer I have worked with had some kind of extracurricular, no matter how casual, that focused around some form of art. I have worked with painters, photographers, singers, writers, actors, musicians, sculptors, printmakers, and graffiti artists. One question I started to ask candidates was “Do you play an instrument?” If they did, it was usually a good sign. (Disclosure: I do not play any instruments and was not looking to start a band) My thought on this is that artistically-minded individuals derive personal value from expressing themselves through their work. Consequently, they become much more entwined in what they create and its success. They are often emotionally tethered to the product and will surface gripes long before they echo back from your users.

Count me among the musician/photographer/front-end engineers who struggle to enjoy their “hobbies” because of a keen awareness of the flaws in every frame and every measure. I love music and photography, and I hate them. I love the process of creating something in any of these mediums. I hate that the creation is never perfectly realized. Chris’ analysis of how this spills into the work of a front-end engineer is spot on.

5. If you want to find good front-end engineers, look to the newspaper and print industry. People who work in print media make excellent potential web developers as long as they have at least some technical skill to expand on. Consider the general environment of the print world and what is required of its workers. Workers often work on tight schedules, with very sharp deadlines that mean last-minute cuts may have to be made in order to ship their product.

From his mouth to God’s ears. Working for a newspaper means I understand that web design is 95% typography and that we live and die by our deadlines.

/via Cameron Moll