I wrote an article about getting started with HTML5 Boilerplate. It’s live at IBM. Check it out:

Kick-start your web development with HTML5 Boilerplate.

I’ve got some more content coming up on IBM over the next few months on some pretty exciting topics. I’m in the middle of a deadline for one right now, actually…

That begs the question- when will I sleep?

Answer: never.

Read the rest of this entry »

Two caveats before I dive into this one.

For starters, the following is what I’m generally interested in when doing an interview. It doesn’t represent in any official way what my current employer and my boss might be looking for in a candidate. It’s not my group, so this is only part of the picture.

Secondly, this is based on the “Front End Developer” role I outlined in my previous post. That’s what I do and what I’ve interviewed people for over the past few years, so if you’re looking for insights into interviewing for another role, adjust accordingly.

Also, and this should go without saying, the following is simply what I look for in a candidate. This is entirely personal and biased. If you look for other things or don’t care about some of the things that I value that’s cool. There are infinite ways to get to the same result here. We all want to hire good people.
Read the rest of this entry »

Following up on my previous post about the generic types of front end engineers, this post will deal with the common roles that I see people trying to fill. Unlike the previous list which was written solely from the perspective of a front end engineer, looking at the actual skill sets of the people whose resumes I’ve reviewed, people I’ve interviewed and folks I’ve worked with; this list is based on job descriptions and roles designed by people may not really understand what being a front end engineer means in 2011. Hopefully a few of those people (and maybe a recruiter or two) will visit this site and come away with a better sense of how to staff these roles.

I’ve seen examples of all of these over the past few years.
Read the rest of this entry »

This came up in a comment here, so I thought I’d bubble this little tip to the top.

To target multiple files for URL rewriting in the HTML5 Boilerplate build script (as of version 0.95) use the fileset element instead of the file argument in the “html” target:

<target name="html" depends="">
    <echo message="Clean up the html..."/>
    <!-- style.css replacement handled as a replacetoken above -->
    <replaceregexp match="&lt;!-- scripts concatenated [\d\w\s\W]*?!-- end concatenated and minified scripts--&gt;"
    	replace="&lt;script src='${dir.js}/scripts-${build.number}.min.js\'&gt;&lt;/script&gt;" flags="m">	
        <!-- grab everything html -->
       <fileset dir="./${dir.publish}/" includes="**/*.html"/>
    </replaceregexp>
    <replaceregexp match="&lt;!-- yui profiler[\d\w\s\W]*?end profiling code --&gt;" replace=" " flags="m">
        <!-- grab everything html -->
        <fileset dir="./${dir.publish}/" includes="**/*.html"/>
    </replaceregexp>
    <!--[! use comments like this one to avoid having them get minified -->
</target>

You then need to expand the fileset element in the next three targets (htmlbuildkit, htmlclean, htmlcompress) to include subfolders.

Replace

<fileset dir="./${dir.publish}/" includes="*.html"/>

with

<fileset dir="./${dir.publish}/" includes="**/*.html"/>

And that should do it.

As both a hiring manager and as a potential employee, I’ve seen both sides of the interview/hiring process and have noticed some definite categories when it comes to the type of people filling the roles and the roles themselves. This post deals with the types of people. I’ll follow up with a post outlining the types of roles and who (of the following) you should be looking hire if you’re looking to fill one of those specific roles.

The Three Types of Front End Engineers

Clearly, there are people that fall somewhere in between these broad categories. Still, I think these are pretty solid as general buckets.
Read the rest of this entry »

So… the site I’m working on has one of those “increase text size” controls. On this project it’s turned out to be one of those features that shows up in comps and somehow falls through the cracks until later on in the project cycle. Situation normal, really, as it isn’t a big feature. It’s just one of those things that needs to be buttoned up before the site can go live.

Anyway, I was thinking about how to do implement it the other day. I haven’t done one of these in a long time and the only other time I did one it involved crafting separate, albeit small, style sheets for the larger text sizes. I didn’t want to go that way again. Basically, I just didn’t want to write new style sheets- even small ones.

What’s a fella to do?

zoom

So, thinking about it a little bit, I seized upon using the non-standard CSS zoom property. Supported in Internet Explorer (zoom:1 is often used for a hasLayout toggle) and Webkit browsers, it would represent a simple (1 line!) CSS solution to this problem. It’s also one that I like better aesthetically as the site looks the same, just bigger. I figure there’s a reason all browsers have moved to this behavior when hitting ctrl+.

The problem was figuring out an equivalent for FireFox and Opera which don’t support zoom

Enter CSS 2D Transform

A little searching and experimenting later I came up with the idea of using CSS Transforms and the scale value to approximate zoom in browsers that lack support.

Let’s see how I did it.

As you go through the following keep in mind this hasn’t actually gone through testing yet so something weird could yet shake out. I just wrote this code yesterday, so you guys can be my sanity check.

Also, is anyone else doing this?

Read the rest of this entry »

We finally launched the new Isobar North America site. It had been in a soft-launch phase for several weeks as we worked out the kinks. Now it’s official.

I worked on it and, amazingly enough for an internal project I’m happy with it.
Read the rest of this entry »

And here it is:

CSS 101 from Matt Murphy on Vimeo.

Slides.

It’s pretty good- minus the difficult with actually showing the jsfidddle code on the projector.

I’m going to be writing a bit more about practical development topics here over the next few weeks. Code is fun to write about but code takes time. Sharing my experience and opinions on the day-to-day life of a front end engineer I can do with a little less effort. Also, since I’ve been doing it forever and have experience all over the place I feel like I just might have something to share.

Anyway, today I’m going to continue to talk about the technical interview process. This time with an anecdote culled from my time on the other side of the desk.

I was interviewed a while ago by someone who was significantly junior to me. I think he had maybe 3 years of experience. I was supposed to have been interviewed by someone who would have been a peer at the company, but that fell apart and it fell down to a junior resource. He asked me two questions over a span of ten minutes. Both were worth commenting on, but I’m going to focus on the first one as it illustrates something pretty important about who you have interviewing people and what they should be expected to be able to figure out about a candidate.

We get on the phone, trade pleasantries and then he gets started. He asks me the following question:

“You have a div with a width of 300 pixels. It’s got a margin of 10 pixels. How big is the box?”
Read the rest of this entry »

I’m a big fan of the Graded Browser Support table from the fine folks at Yahoo! It was the official foundation for our browser support policy at Cramer and I still look to it now for hints into what one of the most mass-market of all sites thinks about the browser landscape.
Read the rest of this entry »