Archive for July, 2012

Effective Code Review (OSCON 2012)

Tuesday, July 17th, 2012

In approximately 24 hours, I will be speaking at OSCON 2012.

My talk is about code review, why you should do it, and how it can help you write (much) better code. We’ll talk about hidden benefits, how to do code review with distributed teams, code review tools, and much more.

Here are the details if you’d like to attend:

Effective Code Review

Wednesday, July 18th at 1:40 PM in room Portland 256.

Hope to see you there!

Things that are Awesome about AngularJS

Tuesday, July 10th, 2012

This post was so popular I wrote a book about ramping up on AngularJS. It’s available in eBook and paperback if you’d like a copy.

We host talks at Netflix every Monday, and today’s talk was from a couple of Google employees that work on AngularJS — one of those new-fangled Javascript frameworks (like Ember, Knockout, Backbone, etc).

In no particular order, here are some thoughts I happened to write down during the two-hour talk:

HTML5 Fallbacks

I noticed a couple of places where Angular seems to be doing something that I know is a planned feature in HTML5 (field-level validation, web history via JS).

At first, I thought this was kind of stupid. What are you going to do when those features become mainstream? I don’t want to have to choose between the proper, standards-specified way of doing something, and the way this framework wants me to do it. That would be super-lame.

Eventually I caught on that they’re providing a framework way to do it, but they seem to be falling back on the HTML5 versions when supported. This was very clear in the web history example, where the speaker mentioned they convert from hash-bang syntax to proper HTML5 history API calls, but I caught a bit of it during the validation example as well.

This is actually kind of cool. They’re making the features available right now, but putting the framework (and by extension, the apps built using the framework) in a position where transitioning to the standard HTML5 solution will be easy when that solution becomes widely available.

In short, you get to use soon-to-be-standard HTML5 features now, and it will be easy to convert your app to use HTML5 standards later. Neat!

HTML5 Future-Mindedness

Along the same lines, the team at Angular seems to have put a lot of effort into helping you get your application (and skillset) ready for the future of HTML5. Here’s an example:

One of the HTML5 features I’m most excited about is Web Components. We’re still at least 6 months away from seeing these in beta release channels (Aurora, Canary, etc), but they’re available in the Safari and Chrome nightlies right now.

Web Components are going to change how plugins and widgets are developed across the web. (It’s going to get a whole lot easier for everyone.) They’ll herald in a fundamental change from Javascript-based widgets (see most jQuery plugins) to HTML/CSS-based widgets that perform better, cause less naming conflicts, and integrate better into both standalone websites and Javascript applications.

What I love, love, love about reusable components in AngularJS is that they follow the same paradigm shift. The way you write and use reusable components in AngularJS looks and feels a whole lot like how you’ll write and use web components in a couple of years.

This is super-helpful for the web developer community. Web components are the future, and Angular’s reusable components are a very similar present.

Good Web Citizenship

My main gripe with a lot of frameworks these days is that they don’t play nice with the rest of their world.

Just today, for example, one of my coworkers went on a rant about how some Node-based packaging plugin he was looking at tried to force its own conventions on the content you’re trying to package. This is a huge no-no! A good framework goes out of its way to make sure it can work with as wide a range of content as possible.

AngularJS is one of the good guys.

Need your HTML to validate? They provide a slightly-more-verbose syntax for that. Want to minify your dependency injections? You can do that too, just add an extra line of code. Want to integrate with jQuery or Node or your favourite test framework? No problem!

The web is a heavily-interconnected place, and it’s nice to see frameworks put some effort into fitting in. People aren’t going to use your library if it conflicts with anything they’re already doing/using.

Dependency Injection!

Did your heart skip a beat when I mentioned this a second ago? It should have.

I’m not going to advocate that all JavaScript applications would benefit from dependency injection, but I bet most of the kinds of apps people build with frameworks like AngularJS absolutely will. You get to write less code, you don’t need to worry about the boilerplate of managing dependencies, and it’s just so much more fun to have a smart library handle this for you.

Even if you’re not a fan of dependency injection, I still think you should be excited about this. We need more experimentation with server-side features. If the success of Node has taught us anything, it’s that JS developers want to write server-ish code if it will help them get the job done quicker. Experimentation must be encouraged!

Unit Testing is a Big Deal

I didn’t count how many times our speaker mentioned unit tests, but I’m fully confident it was at least two dozen times.

I know what you’re thinking: Dan, every framework wants you to write unit tests.

You’re right, but most frameworks don’t put anywhere near this much focus on testing. It’s not some after-thought they tacked on to attract the TDD crowd. There’s support for testing in the docs, and every aspect of an Angular application is fully testable. Our speaker discussed integration with Jasmine, Testacular, and Selenium.

It’s always great to see frameworks (and their communities) encourage testing, and the level of testing support for AngularJS is especially notable for how new(ish) the framework is.

The Usual Suspects

Like every other JavaScript framework ever, AngularJS has all the staples:

  • Template support,
  • data binding,
  • work-in-progress documentation,
  • and a handful of useful UI components.

Next time I find time to build a fun little webapp, I’ll probably give AngularJS a shot. I was seriously impressed by all the thought they put into making their features HTML5-ready, and little extras like dependency injection and seriously overwhelming testing support are just icing on the cake.

I’ve been away from the JS framework scene for a little while now. Did I miss anything? Is this all old news? What are the all cool kids using these days?

Some Thoughts on Recruiting

Tuesday, July 3rd, 2012

There’s an excellent article called The Recruiter Honeypot that’s been making the rounds since it was published last week. It’s a downright fascinating read about the state of recruiting in high tech.

Grab a coffee and open it up. It’s worth a few minutes of your time.

Back? Great. Let’s see if I can supplement what you’ve just learned. Having just been poached myself, here’s my two cents:

1. Recruiters really do rely exclusively on LinkedIn.

One of the most common questions I was asked when I told everyone I knew that I was moving from Ottawa to California to join Netflix was “How did they find you?”.

I was bold enough to ask, and the answer was LinkedIn. Not this blog, where I talk frequently about Javascript and software development, not G+ where I maintained a weekly series of in-depth pieces about web browsers earlier this year, and not Stack Overflow, Twitter, or anything else.

In fact, other than candid prodding from friends, I don’t think I’ve ever been contacted about a job outside of LinkedIn. It truly is the go-to source for recruiters looking for talent.

2. Managers make better poachers than recruiters.

Netflix is not the first famous Silicon Valley name to grace my InMail. What made them special (well, one of many things) was who contacted me: the manager of the team I’ve since joined.

For the recruiting company, there is one major advantages to having a manager make contact as opposed to a recruiter:

Technical managers are former developers. Mine was in my position for five years before switching to management. He knew the role intimately, and could really explain how I’d be spending my time. He knew the team, he knew what technologies we were using (and not using), and he could sell the company as well as anyone in HR.

It’s not easy to leave a job that you love — and let’s be honest, everyone worth poaching loves their current gig — nor is it easy to move across a continent, or to another country.

Before I commit, I need to know what I’m getting myself into. And a manager is almost always going to be better suited for that task than a traditional recruiter.

3. Location matters. A lot.

The number of LinkedIn messages I get from recruiters has gone up by at least 3 or 4 times since I moved to the valley. I get that some of that is due to the Netflix brand, but I’m positive an even bigger chunk of it is location, location, location.

Here’s why I’m so sure: Since moving to California, despite the huge uptick in recruiter spam, every single message I’ve received has been from a bay-area company. Every. Single. One.

Despite how interconnected the world has become in the past couple decades, the recruiters that have contacted me have been massively biased towards location. I can’t help but think this is a trend, and also an opportunity for teams that are willing to hire remote workers, or invest in relocation costs.

There you have it…

If you want more recruiters to contact you, beef up your presence on LinkedIn.

If you’re trying to poach someone, send a manager instead of a recruiter.

If you’re looking to work in the valley, move to the valley.

(And because I’m sure someone will ask: Netflix is great, and I’m having a blast. Won’t be leaving anytime soon.)