We went through a ton of candidates. It amazed me the range of skills and knowledge people applying for a Web Developer position had. But in general, I ran a few common issues that soured me on many candidates.

Know what you don’t know

One of the first questions I ask candidates is how they rate themselves on a one-to-ten scale with HTML, CSS, JavaScript and Flash. Amazingly, most of the candidates rate themselves a nine or ten in HTML. Now I’m pretty sure only Ian Hickson, and maybe Anne Van Kesteren grok HTML in it’s fullness, but if you rate yourself a ten in HTML and cannot describe the differences between HTML and SGML, or the parsing irregularities between the four major browsers, it reflects poorly. Many candidates rated themselves a seven or higher, but could not describe the purpose of a <label> element.

JavaScript is not just frameworks

I wasn’t prepared for the number of people with little or no idea how to program professionally in JavaScript. While I don’t require an intimate knowledge of the various native objects or having the ECMA standard memorized, good Web Applications require understanding why framework makers have to work around quirks like the event model–not just that they do.

In addition, most self-taught programmers have little grasp of good programming patterns that save time and make self-documenting code. The best Web application in the world is useless to me if I have to re-write it form scratch a month later because it would take less time than learning how it works.

I had a number of candidates ask me how I came about my JavaScript knowledge, and I didn’t have much to offer them. I’ve never taken a JavaScript class, although my unsuccessful interview at Google could be considered one. I do, however, recommend two books: PPK on JavaScript by Peter-Paul Koch and Pro JavaScript Design Patterns by Dustin Diaz were invaluable resources. The first is a very low-level examination of the history of JavaScript, while the second is a high-level translation of classic programming methods to JavaScript.

Play

The people who stand out to me are the people who play with the discipline. If your resume is a Word Doc or PDF, you’re starting with a strike against you. Have interesting side projects and who show a curiosity in the medium. Own yourname.com or yourlameinternethandle.com and show me what interesting things you’re doing with the Web 2.0 API of the week. Even if it’s a horrible hack or you code is just plain bad, I’d rather have that than a code wizard on autopilot.

Just over HALF of all the support requests we get are about email. Everything else we offer, combined, doesn’t add up to the amount of trouble, expense, use, and effort that goes into “simple” old email.

And that’s kind of funny, because as far as I can tell, almost nobody CHOOSES a web host based on their email features. Everybody’s just looking at how much disk/bandwidth they get, what version of PHP they run, how good their support is, do they have a funny blog, is their CEO really studly, do the data centers have water beds, and so on…

They’ve been conditioned by Yahoo! Mail, Hotmail, and Gmail to give email no value. I mean, everybody gives it away for free… nobody gives (real) web hosting away for free.

And yet, in the end, the only thing (sadly?) that actually ends up getting used, is that “no-value” email! If a web server with maybe 750 customer sites on it were to go down for even as long as five hours, we’d probably get two angry messages about it. But if email goes down for the same number of customers for just five minutes we’ll have already received 50!

Amazing that people complain more about their obsessions than things costing them money. This came to mind after grumping about all the grousing I hear over Twitter’s downtime.

You always think yourself invincible. You read about it. you see it happen to others. But you think, “It could never happen to me.” You’re Internet savvy. You protect yourself. Sure, there was a little while—back in the 2.3.2 days—where you were a little risky, but you made it out okay, right?

Right?

And then it happens. Suddenly things look wrong. Down there—in the footer. Someone used a WordPress security hole to set your theme and upload locations to ../../../../../../tmp and they’re running PHP scripts from there.

You panic. You e-mail support. Your message is half in all-caps and its spelling only vaguely resembles English. When they reply it’s only to tell you that there’s nothing they can do. They suggest you change your passwords. Take two asprin. Call them if it gets worse.

It doesn’t. And time passes.

You don’t think about it much. You’re smart now; you’re secure. Your blog is up-to-date. You use SFTP, check your e-mail with SSL encryption and put passwords on your screen saver.

Sometimes, when you’re lying in bed, you wonder why your Technorati reactions are filled with smut, but of course you’ve read about them drowning in spam, so you don’t think too much about it.

Then it happens again.

How?!? You’ve been safe this whole time! But you can’t deny it when your Live search results show spam coming from your site. You check the URL and, sure enough, there are women being objectified in horrible, horrible ways.

Once you get control of your breathing, you check your server. Sure enough, there’s an index.php that you didn’t add that pipes in pr0n from another domain. And worse: the timestamp says this has been up for seven months. It’s your old mistakes coming back to haunt you.

So that’s when the research starts, and the awkward e-mails.

I just noticed some bad content coming from a blog reactions from Technorati. Please check the index.php file in the following directory:

wp-content/uploads/2007/02

I believe you site was hacked–I found a similar hack on my site.

You feel dirty. You begin the agonizing inspection of your entire code body. Sure enough, you find some spammy lumps: links to MP3 download services hidden from users with CSS. You ask yourself where you went wrong, how you could have been safer. You wondering if this Web 2.0 thing is worth the fanfare.

Uncomfortable and alone, you do the only thing you can think to soothe yourself: sit down at your laptop to blog about it.

1. Buzzwords
   Vertically-integrated, CPM-increasing social network leveraging monetized startup marketing.
2. 70% Calories from fat
   My kingdom for some oatmeal.
3. Lines
   Nothing sells a $4 beer like 300 people queued at the open bar.
4. Beards
   I’ve said it before. Stop scratching. Is it… is it moving? I don’t like sitting this close.
5. The integrated social community application sales force
   Did you go to our panel?
6. Standering room in front of a seated crowded
   It’s fine; don’t worry about it. Have you been working out?
7. Sport coats over tee shirts
   Buisness card reads: VP of JavaScript…Cheeseburgers?
8. Rawk
   I get it, you’re “creative.” Unless you have feathers, this is off limits.
9. Shyness
   Introduction lines always sound better when rehearsed in my head.
10. People introducing themselves as their-name-dot-com
    I’ll Google you if I’m interested.

Yahoo! Pipes is great for doing mash-ups like this, and so I’ve taken the step of fortifying my Atom feed with Vitamin Webernet—infused with tumblelogs, Flickr photos, and del.icio.us links (deprecated). I had thought about adding my Twitter tweets as well, but the result was a bit obnoxious. If this seems like way too much Ryan for your tastes, switch to the RSS feed instead.

Visionaries of HTML, CSS and JavaScript have been promoting this change—which they knew about before the rest of the world—with an odd sort of fanfare. Says Zeldman:

What’s really new is that by opting out of Microsoft’s version targeting … you get to skip testing in future versions of IE. If your site works in IE7 today, it will work in IE47, or so Microsoft has promised.

It’s the Microsoft has promised line that raises my hackles. Microsoft is somehow going to port every rendering mode since IE 5.5 into future versions of IE. How long will the cost of backporting IE7’s bugs and quirks to the latest Windows version will be seen as benefiting Microsoft’s shareholders? Methinks it won’t be 40 versions. My guess is two. Tops.

By taking the onus of maintaining sites off of Web developers and onto a fairly untrustworthy party—especially one with a business case for stagnating standards-based development and a means to force it into broad acceptance—we are making a deal with the devil. Version targeting is bad for the Internet.

Who are the unenlightened?

Worse, however, than betting on Microsoft to save us is that Zeldman blames the situation on some theoretical group of unwashed masses that are making bad Web sites:

Zillions of people who don’t know any better do tailor sites to the quirks of IE6. That’s why an improved IE7 “broke” old sites. And it’s why, in crafting a new switch, Microsoft must build its default to protect unenlightened developers.

PPK walks lock-step with Zeldman, using the same rationale as colonial Europe when pillaging Africa.

Noblesse oblige. Since we know more and can do more and better things with web sites, more is expected of us. If our ways are so much better, we should shoulder more responsibilities than those whose ways are wrong. Our shoulders are fit to bear these burdens; [standards-unaware web developers] aren’t.

Both of these articles assume that these unenlightened people are going to magically become enlightened, and not abuse this new property as they do the rest of HTML currently. What seems realistic to me is that these people will start new projects. They’ll want to use new IE features. They’ll use—because they’re not “enlightened”—IE=edge. And Microsoft will have to dream up some other scheme to prevent the Web from breaking, and this hubub will start all over.

We need to stop being elitist. The “problem sites” aren’t just being created by these “unenlightened” developers; they were created by developers—enlightened or not—and have been left fallow. Our industry is flush with hit-and-run agencies and freelancers that throw up a site and then dump it on understaffed, underpaid and under-experienced teams to manage. It’s easy to see that three agency guys might focus on sites created by novice Web developers or existing since the 20th century as the main problems, but I have a hard time believing every Happy Cog site would survive IE8 without some kinds of tweaks. Sites which are not actively maintained, but still have value to Internet users—these are the sites Microsoft is afraid of breaking. A fix is never simple if there is no one to do it.

My guess is that the IE7 update is not the one that fueled the version targeting decision: it was the rancor over Vista. A vast number of applications and device drivers would not function with Windows Vista’s new API’s, and as a result the operating system has had a fairly frosty reception. IE7’s release was a party in comparison. Apparently there exists a hearty core of people that desired to use applications and hardware years after they’ve stopped being maintained. The scripting and CSS updates alluded to with IE8 may bring similar Web sites down, and that’s ill will Microsoft can’t afford to engender.

In other words, updating IE without setting up version targeting to a current browser will break an unknowable number of Web sites which may still contain valuable content but have no means to upgrade and stay current. We need it.

Opting to opt out

Somehow, I’ve got to reconcile this conflict. I’m glad that Microsoft created a way to improve the state of their browser without throwing away the old Internet. That said, I don’t have a very high opinion of that company and am loathe to contribute a spare byte of mindshare to their products by inserting IE crutches in my code. I’m going to let it break. Refusing to use IE’s meta tag will lock their browser to a predictable set of features and bugs—or as predictable as such things will ever be, and for the foreseeable future, IE7’s Web standards support is passable enough for most work, and we’re going to have to support IE7 (the browser, not just the rendering mode) anyway.

I’ve long believed that Web Developers have been, as a group, too milquetoast about dealing with IE’s problems. We tediously work around a cranky browser and then, hypocritically, use buttons that read “this site requires flash,” and “download the PDF viewer.” For me no longer. Any site in beta, any site I develop for fun, and any site without a demonstrable need for IE8 features is going to stay in IE7 mode. At least, that is, until HTML5 is usable.

Notes

1. Mr. Meyer does cite some Web research, but both studies do not prove anything about the current state of Web development. Google’s statistics surveys the entire Internet with no regard to when a page was developed, while Marko Karppinen’s study assumes that validity has anything to do with standards-based design, which it clearly does not. ↩
2. If the IE team truly wanted to preserve the Internet, they’d make version targeting default to IE6 rendering, and not IE7, as IE6 has been actively targeted by Web developers for almost ten years, IE7 a fraction of that. Admitting this, however, makes me die a little on the inside. ↩

I mentioned previously how to set up an EVE Online-focused rails site. After reading through old Riding Rails posts, I noticed this excellent post on iPhone-optimising your rails project. This process is almost exactly the same for sharing views between EVE and a normal browser. In Rails 2.0 all you have to do is register the MIME Type.

config/initializers/mime_types.rb:

Mime::Type.register_alias "text/html", :eve

Then, in your application controller, use a before_filter to adjust the format as necessary.

app/controllers/application_controller.rb:

before_filter :isolate_eve_browser

private
  # EVE-specific data
  def isolate_eve_browser
    if eve?
      request.format = :eve
      request_trust unless trusted?
      end
    end
  end

Now everywhere you want to separate your EVE views from your standard browser views, simply use respond_to.

app/controllers/home_controller.rb:

class HomeController < ApplicationController
  def index
    respond_to do |format|
      format.html
      format.eve
    end
  end  
end

You can then use app/views/home/index.html.erb and app/views/home/index.eve.erb respectively. This means you can also request trust on the appliaction level instead of on the action level as I mentioned previously. Notice that request_trust method above? It should look something like:

app/controllers/application_controller.rb:

private
  def request_trust
    response.headers["eve.trustme"] = (
      “http://#{request.env['HTTP_HOST']}/” +
      “::Your custom message begging for trust.”
    )
    render :template => ‘trust_me’
  end

The action is rounded out by creating app/views/trustme.eve.erb, which is the template rendered above when the user declines to trust you. Happy coding!