New Blog

New posts are here.

Facebook: The New Google?

For many years now, I've thought of Google as top dog in the software world. But Facebook is challenging that. Yes, the frequent UI changes are odd, but the back-end tech is innovative and impressive. Talk about scaling: hundreds of millions of users. Daily number of writes is probably at least that. Daily number of reads is probably a couple of orders of magnitude higher. Hell, just getting all those email alerts out is impressive.

They're pragmatic: they use everything from PHP to C++ to Erlang (the billion-msg-a-day chat server), and they open-source a lot of stuff.

Freedom to choose the right tool instead of the popular one: priceless.

What's In A Server Name?

In the beginning, the admins named the servers. So the servers got geek-culture names like gandalf and sauron, or enterprise and voyager. And it worked pretty well. People remembered the names, and they remembered that gandalf was the development box, and sauron was the production Oracle database.

Then some suit decided that the geek-culture names were unprofessional (whatever that means), so IT management stepped in. They came up with server naming conventions that embedded all sorts of useful information: data center, run-time environment, software configuration, server number, etc. And out came monstrous server names like NYCP3STDZ09. Which is a challenge to say out loud, and hard to remember, and doesn't connote much of anything unless you know the original conventions. Which hardly anyone does after a few years of turnover.

And NYCP3STDZ09 is a hard name to get right in a phone call, and an easy name to mistype in an email, and that's just so much extra fun in the middle of a production problem.

Meanwhile, sauron comes across clearly in phone calls and emails, even when you're frazzled because your boss's boss's boss wants to know when the fuck the system will be back up, even when your data center is offshore and your admin's accent is very different from yours, and you're on a conference call that sounds like a cell phone in a hurricane. It's a great server name when people need to communicate.

But it's unprofessional, and disorderly, and doesn't tell us anything about the server's role in the organization. So we have a winner: NYCP3STDZ09. Just be careful what you type. Don't want to get the wrong box rebooted again!

Interviews 2.0

I've been doing some J2EE screening interviews for my company, over the phone. Some trends:

• Candidates google as they go, so feature questions like What's the difference between a HashMap and a HashTable? have almost no value. All you're testing is how quickly and quietly the candidate can type.


• Candidates have found a quasi-ethical way to embellish their resumes: describe a project in detail, but don't say which pieces you worked on. List every tool/technology used in the project, whether or not you were the one using it.
  
  Of course, this is pretty easy to blow apart. I've gotten some amusing explanations of Ajax from people who maybe used it once to clean a sink. Which brings us to...


• Don't just ask people to explain a technology. Ask them how they've used it on a project. Any candidate who answers with an accurate general description of the technology probably hasn't used it much. A candidate who can tell you what he's done with the technology, the problems he ran into, how he worked around them - he's telling you the truth. Bonus points if he gets animated while he's talking about it.
  

Experience is hard to fake, even over the phone with a browser open.

It's The Framework, Stupid

I'm looking at Scala. It uses static typing, albeit in a sophisticated, type-inferred-when-we-can way. But still: plenty of syntax, and rules, rules, rules. The last static language I learned was Java, about ten years ago. Since then, I've been much more interested in dynamic languages like Python and Ruby.

So why Scala? Because of Lift. I think we're at a point where framework trumps language, and I want to give Lift a try. Hence, Scala.

So why Lift? Because the value of a framework is in the code you don't write, and the worries you don't have. I've been learning/thinking about web security lately, and it's not trivial. Passwords, for example: pretty much everyone knows that passwords shouldn't be stored as plain text. But do you understand why adding a salt to the hash matters? Why you should use a different salt for each password? Why storing the salts as plain text right next to the passwords is not a risk? Which hash you should use? (If you want to dive into all this, here's a good starting point. Read the comments, too.)

There's a lot to it, and that's just passwords. There are plenty more ways to screw up web security, and I'd just as soon hand all that off to the framework. So, when I read this blog post by David Pollak, the creator of Lift, the stuff under the Lift offers unparalleled security heading got me all excited. It sounds like Lift has security baked in.

Contrast that with Rails, where there's still no canonical authentication/authorization solution. Plugins? Sure. But this functionality is critical. It belongs in core. That makes the code better, because you've got more people using it, looking at it, poking at it. And everyone gets the fixes automatically when they upgrade. Then there's the unescaped HTML thing. Rails still leaves it up to you, the developer. Over-all, I'm left feeling that security just isn't high on the list for the Rails core team. But leaving it to us application developers is dangerous.

Lift looks like a potential big win. It'll take me a little extra time to get the basics of Scala into my head, but I expect to make that time up pretty quickly. Within a project or two, if Lift works out for me. After that, it's all upside.

Cleaner and Cleaner

Re: yesterday's post, I read a little more of the excellent and free Django book this morning, and I realized that template includes don't have to be hard-coded. They can use variables.

Woohoo! This lets me move all my special-case logic into the Python code. Instead of nested {% if %} statements in the template, I'm doing a simple list lookup in Python. Then I use one {% include d.template %} to pull the results into the template. This Django stuff cleans up real nice.

The Template Made Me Do It

I've been doing a little Django lately. Django's template language isn't Python; it's a somewhat Pythonic template language, and it's limited by design. At first, it frustrated me; after a brief battle, it surprised me.

My template was pretty simple: generate a monthly calendar page. Every day gets the same HTML, except for three special cases: first Wednesday of the month, other Wednesdays, and all Fridays.

In my first version, I passed a list of datetime.date objects in the context. The template for-looped through the list, and did things like

{% ifequal d.isoweekday 3 %}

All by itself, that's mildly evil - the hard-coded magic number, though I can probably remember that isoweekday() starts counting at Monday == 1. Then I started nesting the if-else tags, and things got messy quickly. The Wednesday case, the Friday case, the first-Wednesday case: frustration. I wanted Python at my fingertips, not this crippled template language.

Which, of course, was the answer. I needed better abstractions for the template, and Python was the right place to create them. I subclassed datetime.date and added the methods I needed: is_wednesday(), is_first_wednesday(), is_friday(), is_special()

Which let me write reasonable template code like

{% if d.is_special %}
    {% if d.is_first_wednesday %}

And then the surprise: I realized that fixing the messy template had also made my Python code cleaner. I ended up with a nice little app-specific date class, unit tests and everything. That was the right thing to do, but I hadn't bothered till I needed it for the template. The limitations of the template language drove the refactoring.

And that makes me think that limiting the template language was a very good idea indeed.