This post is largely a reply to David Parry’s post regarding my use of text-shadow for Lectio, my entry alongside Lachlan Hardy and David Goodlad for Node Knockout. I figured it makes for an interesting discussion though, so I’ve decided to write a short post on it.

The problem that I tried to address by using text-shadow is the fact that WebKit will wreck text rendering on elements that have hardware acceleration enabled (in our case, almost everything through -x-transition: all 0.25s linear). Narrower font faces are obviously more brutally affected by it.

David DeSandro proposed a solution in his blog. That would’ve been my go to solution if it wasn’t for the fact that we’re using an image for background noise. Which means I can’t set a background colour on the affected elements.

The other way to address the problem is by adding a blurred text-shadow (e.g.: text-shadow: 0px 0px 1px , any value of 1px or higher for blur will do). That seems to force it to render text nicely again. The downsides are many, including making the page a lot slower and memory-intensive, and in Firefox the text looks overblurred (but more on that later).

So my advice to you is, should the background of your text elements be a solid colour, go for Desandro’s solution. Otherwise, use text-shadow, and fine tune the distance between the colour’s shadow and the text’s colour so you don’t end up with something that in other browsers, such as Firefox, looks like you set everything to bold or nearly.

Since we did our last deploy I did experiment with font sizes and contrast a lot more. What I have on my computer is significantly better than what you can see right now in the live app.

P.S.: thanks David for the incredibly valuable feedback.

He is henceforth known as a person, independent of gender.

Software is expression. The more domain you have over a given programming language, the more freely you can give shape to your ideas.

Frameworks are tools built on top of languages to help you perform a given set of tasks more easily. The tradeoff is they get in the way of expressiveness. i.e.: they’re not your ideas anymore, but rather, pieces of other people’s ideas which you’re plugging into yours, to make software happen.

A programmer with little domain over a programming language is unable to adequately translate his ideas into software. He faces the same challenge that any of us would face when trying to write a letter containing instructions in a foreign language: no matter how well I know the instructions, I’m barred by my ability to convey what I know in words I’m not familiar with.

Hence, a programmer who’s striving to become masterful should use frameworks as much as possible, but with the purpose of deepening his understanding of the programming language and the underlying platform, so he can eventually be free of them should he choose to, or should the architecture call for it.

Understand that in this day and age, there are two kinds of programmers: the ones who use tools, and the ones bound to their tools. Be the former.

I’ve been getting a handful of emails offering me front-end jobs recently. Probably about time I admit that I like spending most of my time doing that, even though I ♥ my Rubies and I still believe developers who specialise end up worse off.

So I’ve decided to put down in words some thoughts that I had as I read through the job ads. This isn’t another post on how to hire developers in general (much), but on how to hire front-end developers specifically, and at the same time, get you to understand what sort of statements you’re putting out there when you say certain things in a job ad.

1) Figure out what you want to do with your hire beforehand.

This is pretty much like telling you that to beat poverty, you need to win the lotto first. But yeah, it’s valid, and the reason is because you can’t go out there and advertise that you’re looking for a front-end developer and then list 3+ back-end languages as experience required.

For instance:

Requirements: - Experience with Python, Ruby, Perl, Java, C++.

It tells me:

If shit hits the fan, we’ll get this guy to cover for one of our back-end developers.

And no, saying any of those isn’t cool either, and the reason is because I want you to tell me why you need me to know a language in particular.

This is way better:

We use mostly Ruby for our back-end, so it would be sweet if you’re acquainted with it as we might need you to help out every now and then.

Now you’re being clear. Should I like the idea of working with Ruby sometimes, I might take the job on the grounds that you’re being specific about what language, and how much chance there is I might be using it.

2) Don’t ask me to know XHTML/HTML4.1/HTML5

Markup is being consolidated into just HTML. Unless you happen to rely on your markup being parsable by a XML parser for any reason, asking me to know XHTML for instance says.

I’m spamming buzzwords to ensure we get the right guy.

Better way to say it:

We expect you to know HTML, use tags efficiently, and have a good grasp of the semantics behind each tag.

Protip: don’t let someone fool you saying they know HTML5 if all they know how to use is the doctype.

3) Asking for 3+ different JavaScript frameworks.

I often get this:

Experience with jQuery, Prototype, Ext.js, and Mootools.

JavaScript frameworks aren’t something you throw around like it’s nothing. If you’re saying I need to know Ext.JS for instance, this role means something entirely different than if you ask me to know jQuery. Instead, if I’m to work on an existing project, tell me which framework you’re using in it:

The project you’ll join uses Prototype (kinda sucks, we know), so we expect you to be familiar with the framework.

Excused if you do happen to have other projects that I might be working on that use other stuff:

We use jQuery for other projects, so you’d be working with it too at some stage.

Final on this subject, learn how precious it is to get the hell out of the developer’s way if you’re developing something from the ground up:

You’ll be working on a greenfield project. Any tool you use is fine as long as you know it REALLY well. Except of course for Ext.js. There’s just no excuse for using it ever.

Make sure you include the last two parts of the sentence.

4) Asking for JavaScript frameworks but not for JavaScript.

A framework developer is the kind of developer who, outside of a framework such as jQuery, is incapable of building anything useful. That’s as bad as hiring a “Rails developer” instead of a Ruby developer, or the equivalent for any other language.

A good JavaScript developer will know how to use frameworks. But not only that: he will know when to do it, and I’d argue that’s as important as the former. Chances he will also know a bunch of important stuff you don’t even know you should be asking about: code portability, degradation/enhancement, and performance.

5) Not disclosing what exactly I’ll be working on.

We’re getting into any job ad territory here, I know. Fact is so few people do disclose that I thought I’d mention it: selling a gig based solely on the technologies a developer will be able to use will net you the kind of nerd who cares way too much about that sort of thing to have any vision of the product itself, or desperate people who need a job. I’m guessing you don’t want either of those.

Any developer worth his salt will embrace a good idea. That’s important because it translates into productivity. I can’t embrace an idea that you won’t tell me in the first place. Also, not saying what you’re up to that carries this statement (potentially):

I’m not quite sure what I want to do, but I heard a lot of people became millionaires in this startup game, so I thought I’d give it a go.

6) Asking trick questions in an interview.

The inconvenient truth of web development is that we’re surrounded by hacks. And I’m not talking about getting things to work on IE. I mean the lot of web technologies are basically the scaled up versions of ideas that someone had many years ago. Because of that, there are lots of little JavaScript, CSS, and HTML quirks which are corner cases, or sometimes outright bad ideas that were kept around.

Some developers memorise that sort of thing so they can spring onto other people with questions, find out they don’t know the answer, and then feel proud on the inside. That’s stupid. It doesn’t mean you can get things done, or that your work is creative, or better in any way really.

If you get your senior developer in the interview, and he pulls that on me, this is what you’re telling me:

I’m gonna have to work with this dick and hear him say he wants to make sweet love to the ECMA spec all day long as if that translates into building something people will like better.

I’m not advocating ignorance, but making that a part of the interview process is too much. Leave it. I’ll know that sort of thing when I need to know it by googling.

That’s it!

Best of luck hiring!

TL;DR - I can’t sell you something I personally don’t believe in.

I’ve recently emailed Manning and informed them of my decision of not going ahead with writing a book, reverting from my original decision. For those who missed the discussion on Twitter a while ago, the title was going to be “Building Well-Structured JavaScript Applications”. I was approached by them about 3 months ago with the proposal after my presentation on Backbone.js at SydJS. At first I thought it was an extremely attractive idea, perhaps because the prospect of being a published author would ultimately bring on good things.

And then it struck me: I just never read computer/IT books. I spent about 80% of my time reading source code, and the rest is split between reading articles and the occasional README. GitHub is my playground, and I need to get my hands dirty if I’m to learn anything. I often advise other developers to do the same, in detriment of time spent reading books.

It also struck me that, from the perspective of the author, writing a book more or less translates into a similar kind of outcome than to writing open source software: you’ll learn from it, and you’ll gather some attention, in exchange for massive amounts of your personal time. While the outcomes can be significant in a best case scenario, these days I much prefer the approach that projects such as DocumentCloud and other companies take, where byproducts of their work are open sourced. That’s what I call the best of both worlds, and that’s where I want to be in.

My workshop, in contrast, proved to be an extremely valuable exercise, for both myself and the attendees (hey, the survey results were great!). People came and learned in one day what would’ve taken them easily a week to get to the same point if they had to get that information from a book. I can endorse that, but I can’t endorse investing that much time being required for one to just get a grasp of something that, as a matter of fact, it’s a simple subject.

Final, I think computer books are getting a good run for their money in the age of the web. Books are now competing with an endless flurry of atomic pieces of information. You can’t beat that, nor should you want to. Exceptions apply, but HTML/JS/CSS books are not among those.

You know what the problem with Rails Ajax helpers is? It’s not that they’re done wrong. Well, up until 3 they were done VERY wrong. But in the upcoming Rails 3, they adopted a set of practices popularly known as UJS (Unobtrusive JavaScript, I guess). Which is short for “JavaScript done right”, and nothing particularly groundbreaking since people who know their JS/HTML have been doing that for a while. Though it’s definitely a step in the right direction in you consider where things were before with embedded JS going all over the place.

But the problem is this: it’s still too much fucking abstraction. It seems like a good idea. It’s there so people who don’t know JS can use Ajax, right? Were Rails merely abstracting browser incompatibilities, for instance, I’d be buying Rails UJS t-shirts and wearing them at meetups. But that’s already done by libraries such as jQuery, or Prototype. And that is the level you want to work at.

These libraries are OK because 1) they abstract differences between browsers, specifically DOM and events related stuff, and 2) they give you a few constructs for building proper proper JS apps with less code. See what I coined when I said “JS apps”? You can’t build those with Ajax helpers. So if you only know JS through Rails helpers, make that your next objective as a developer: learn how to use either jQuery or Prototype properly.

Other frameworks such as ASP.NET, Spring, and GWT, also offer Ajax helpers, either directly or through libraries. Having worked with developers coming from all those 3 backgrounds, I have to say: it’s scary. If a task falls outside the realm of what the framework offers, either the fix will be VERY ugly, or they won’t be able to come up with one. That’s what happens when you’re out to build front-end centric applications without the slightest understanding of how the underlying tech works.

On a more philosophical level, this discussion illustrates a human problem: the more you abstract, the less you know. As a knowledge-hungry programmer though, you should strive to tune your throughput equation to stay as close as possible to the core concepts while retaining as much development speed as you can.

Koziarki’s recent post inspired me to share my opinions on the matter, seeing that throughout the years I experienced a handful of similar situations myself.

First of all, let’s understand the role per se. Someone gets hired for defining those requirements, generally by talking to the customers. That person is usually a software architect with some experience in development, which gives him/her the necessary understanding to anticipate when a requirement will have a big impact on the development timeframe and thus the final cost. During the consultation process, said person negotiates with the client so he will buy only the bare minimum he needs, and agree to further iterations based on real needs that develop over the course of actual usage of the software.

Right? No, not really.

Strangely enough, someone with next to zero experience with software architecture/development often ends up in that position, selling unrealistic expectations to a customer who’s even less informed on the topic, because whoever hired him/her went for a “people person”. That’s terrible because you’re going with the assumption that your customer’s expectations need  to be handled as opposed to looked after. Your business will have to do a lot less explaining if you get into the business of exceeding expectations. You’ll also make more money in the long run.

So here’s a crazy idea: If you’re out to hire a consultant who will bring in requirements for building software, hire someone who actually can give valuable advice based on personal experience. Go for an ex-software developer, or a designer with some development background. No such thing as crazy requirements will land on your developers because they won’t even leave that first conversation with the customer.

For the record, this isn’t about shielding the precious developers from the evils of the real world. It’s about not having your company enmeshed in one of these two situations: having to go back to the customer to explain that due to unforeseen circumstances, X amount of days/money extra will be required to complete the project, or having to squeeze your developers for extra time to cover for the mistakes of whoever brought in the plan.

From amconmag.com, which in turn quotes the original article on The New Yorker:

But, unlike authoritarian regimes, democratic governments hold secrets largely because citizens agree that they should, in order to protect legitimate policy.

That quote doesn’t make any sense. How can any judgment be established as to whether a secret works for legitimate policy or against it if it’s, by definition, not known?

Interesting times for Wikileaks. I’m personally glad that they’re getting publicity, good or bad.

I read this piece on the Guardian today: Texas schools board rewrites US history with lessons promoting God and guns.

Which made me think: at the head of every political religious authority group lies a mind that corrupts others. Don’t think for a second they need to believe in what they’re saying. Every contemporary religion converges on the subject of good morals, and a man of good morals would never subscribe to the thought of violence, cowardice, or more specifically, waging war against an already impoverished and miserable nation. In their own minds, they know themselves not to be what they tell others they are, and the religion that they so often use to back their points of view is nothing but a tool. And the masses of believers follow them, fooled by intentions that these men don’t genuinely have.

Beware of men who say they represent the beliefs of their religious icons through their actions.