When I’m not blogging here (which is, like, all the time), I’m totally blogging elsewhere! If you’re curious what I’ve been doing since I joined SmugMug, check out my new blog post over on the SmugMug Sorcery blog, in which I describe how we made SmugMug Search faster.

Seriously, check it out. There are pretty charts.

Next week I start my new job at SmugMug!

This is old news if you follow me on Twitter. I plead laziness: I’ve spent much of the past two weeks sitting on the couch watching Magnum, P.I. on Netflix and generally avoiding any device with a physical keyboard.

During this time of reflection and relaxation, I’ve learned two things:

1. Magnum, P.I. is awesome.
2. iPads are awesome.

But seriously. SmugMug! I’m excited. This company is special in a way that’s hard to put into words.

On the day I visited, Beth the SmugChef surprised me with seven different kinds of pie. She had even scoured Felicity’s blog to find the recipe for my favorite, maple custard. When she set two plates full of pie in front of me at lunch, I knew I couldn’t possibly work anywhere else.

This feels right. I can’t wait to get started!

After five years, I will be leaving Yahoo! at the end of this month.

I’m not a fan of candy-coated, platitude-filled departure announcements that coyly avoid revealing actual opinions, so this is not one of those. I have many opinions about Yahoo!, and they have led to my decision to leave.

I’m not leaving to “explore new challenges” or “spend more time with my family”, and I’m not leaving because someone offered me a better job. I’m leaving because I no longer want to work for Yahoo!.

To be clear, I’m not leaving Yahoo! because I dislike my job, or my coworkers, or the projects I’ve been working on. I love my job. I love my coworkers. I love what I get to work on. For the past two years, I’ve had what is essentially my dream job working on YUI. Nothing I’ve ever done has been as much fun or as fulfilling as getting to wake up every morning and spend all day making one of the world’s awesomest open source JavaScript libraries a little bit awesomer.

What other job would pay me to write open source code, design, build, and perform sysadmin duties on a popular website, and even shoot and edit videos (one of my favorite hobbies)?

But as much as I love YUI, the team behind it, and the fantastic community of third-party contributors and users, I no longer believe in Yahoo! as a company. Yahoo!‘s corporate goals have taken some alarming turns recently, in particular with the reprehensible patent lawsuit against Facebook and the most recent round of senseless layoffs. Yahoo!’s actions violate my personal values and don’t reflect the values of the company I joined five years ago.

That said, my time at Yahoo! has been amazing, and I’m not exaggerating. When I joined Yahoo!, I thought I was hot shit. I wasn’t. I’ve learned and grown more as an engineer and as a person in the past five years than at any other time in my career. I’m grateful to have gotten to work on so many interesting projects with so many talented people. I don’t regret my time here.

Yahoo! has treated me well, both as an employee and as a human being. My managers and coworkers rewarded me and recognized me when I did great work and gave me honest criticism and guidance when I needed it.

When I told my manager in 2008 that living in the Bay Area wasn’t working out for me and Felicity and that I wanted to work remotely from Portland, Yahoo! was incredibly flexible and accommodating. They didn’t have to let me do that, but they did, and I’m very grateful.

When I’ve taken huge risks (like the time I developed and launched Yahoo! Search for iPhone — and announced it on my blog — without asking permission), Yahoo! has backed me up. Those gambles didn’t always pan out, and sometimes I got privately scolded, but I was never punished for pushing through the bureaucracy to do what I thought was the right thing, and in many cases I was rewarded. I respect Yahoo! for that, even though I wish it hadn’t been necessary.

I still think Yahoo! is a great place to work, and I mean that; the YUI team in particular (hint, hint). It’s just not the right place for me.

I don’t know what I’ll do next. I’m thinking about that now. If you’re looking for an awesome frontend engineer in the Portland area or are open to remote workers, get in touch.

The argument about whether or not it’s okay to extend JavaScript natives tends to focus too much on whether you should or shouldn’t, instead of on when you should and shouldn’t, which would be a much more useful discussion.

The ability to extend natives is a powerful feature of the language, and it’s one that can be used to do fantastic things. When used in the wrong places or for the wrong reasons, it can seriously fuck shit up and make developers cry.

Generally speaking, there are two kinds of JavaScript code that you run on any website you build: there’s the code you (or your team) write yourself, and there’s the code that comes from libraries someone else wrote.

Extending natives in your own code is a bit like decorating your living room. It makes perfect sense. You live there, you have opinions about how it should look and where things should go, and you’re the one who either benefits or suffers as a result of your choices, so you should feel free to go nuts.

Extending natives in library code that will be used on someone else’s pages is a bit like being invited into someone else’s house and — without asking permission — repainting the walls, moving furniture around, adding new furniture, breaking expensive vases, and just generally being an asshole.

You could argue that the person who invited you into their home knew you were an asshole before they invited you, so they knew what they were getting themselves into, but that would just make you a victim-blaming asshole, which is even worse than a normal asshole. So don’t argue that.

Sure, some libraries are so well-known for extending natives that anyone who uses them can be said to be opting into those risks. But later, when the developer adds another library to the page to help them build some new functionality and the second library expects natives to behave like real natives when they actually behave however the first library thinks they should behave, it’s the developer who suffers.

And that developer will inevitably file a bug against the second library, because things broke when they started using it. And then that library’s authors suffer.

And then the authors of the second library end up writing code like this to protect users from brokenness caused by the first library, and the fiery heat death of the universe draws just a little bit closer.

All because some asshole thought repainting someone else’s living room was a good idea.

I want to create a Google+ Page for YUI. I need other members of the YUI team to be able to edit and post to this page, so I can’t create it through my personal Google account. As far as I can tell, the only way to do this is to create it through a shared Google account.

But before I can do this, I have to create a “personal” Google+ profile for that shared account. Since this shared account isn’t actually a person, creating a personal profile for it would violate Google+’s policies and the profile would likely get suspended.

So, how are organizations supposed to actually create and maintain Google+ pages? Do they really just nominate one member of the organization to carry out all Google+ duties, and let the page go silent if that person goes on vacation or gets sick, and let the page die if that person leaves the organization?

I don’t get it. It seems like this wasn’t thought out at all.

Designing a flexible framework is tricky. Most framework users are blinded by choice and would rather just connect the dots. And boy do they hate it if the dots don’t connect up to create exactly the picture they want.

Framework designers need to understand this and at least provide clearly defined guideposts for the users who want to connect the dots, while also making it possible for more adventurous users to blaze their own trails without too much effort.

Framework users should strive to see beyond their immediate goals and look at the ways the framework can make their work easier, not just the ways it can do their work for them.

Guy holding a clipboard knocked on the door. Said something about jobs and times being tough. Asked me to put my name on his clipboard. I told him I wasn’t interested. He insisted. I reiterated.

He assured me no emails or mailings or consequences of any kind would result, he just needed my name. I suggested he just make a name up, since that’s what I’d do anyway if he kept insisting. He told me that if people didn’t do something, things would keep getting worse. I told him I still wasn’t going to put my name on his clipboard.

“Are you apathetic?” he asked.

“Um, yes,” I said. “Exactly.”

I’m glad he noticed.

I recently needed a quick and easy way to minify CSS and JS for the new YUI Library website (launching soon!). In the past I’ve written powerful and complicated tools for doing static asset management and minification, but this time I wanted something simple.

A good old-fashioned makefile turned out to be the perfect tool for the job. Here’s what I came up with. Feel free to use it in your own projects. This version requires the YUI Compressor, but that can easily be replaced with Closure Compiler, Uglify, or any other tool of your choice.

# Patterns matching CSS files that should be minified. Files with a -min.css
# suffix will be ignored.
CSS_FILES = $(filter-out %-min.css,$(wildcard \
	public/css/*.css \
	public/css/**/*.css \
))

# Patterns matching JS files that should be minified. Files with a -min.js
# suffix will be ignored.
JS_FILES = $(filter-out %-min.js,$(wildcard \
	public/js/*.js \
	public/js/**/*.js \
))

# Command to run to execute the YUI Compressor.
YUI_COMPRESSOR = java -jar yuicompressor-2.4.6.jar

# Flags to pass to the YUI Compressor for both CSS and JS.
YUI_COMPRESSOR_FLAGS = --charset utf-8 --verbose

CSS_MINIFIED = $(CSS_FILES:.css=-min.css)
JS_MINIFIED = $(JS_FILES:.js=-min.js)

# target: minify - Minifies CSS and JS.
minify: minify-css minify-js

# target: minify-css - Minifies CSS.
minify-css: $(CSS_FILES) $(CSS_MINIFIED)

# target: minify-js - Minifies JS.
minify-js: $(JS_FILES) $(JS_MINIFIED)

%-min.css: %.css
	@echo '==> Minifying $<'
	$(YUI_COMPRESSOR) $(YUI_COMPRESSOR_FLAGS) --type css $< >$@
	@echo

%-min.js: %.js
	@echo '==> Minifying $<'
	$(YUI_COMPRESSOR) $(YUI_COMPRESSOR_FLAGS) --type js $< >$@
	@echo

# target: clean - Removes minified CSS and JS files.
clean:
	rm -f $(CSS_MINIFIED) $(JS_MINIFIED)

# target: help - Displays help.
help:
	@egrep "^# target:" Makefile

To use this, save it as a makefile, customize it as necessary, and then run make minify to minify your .js and .css files. Minified files will be saved with a -min suffix alongside the originals. Only files that have changed since the last time you minified them will be processed.

This file is also available as a gist if you’d like to fork it and improve it. Enjoy!

Steve Jobs discussing programmer productivity in his keynote Q&A from the 1997 WWDC:

The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write.

The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.

This isn’t the only gem from that keynote. The entire thing is fantastic and worth watching, if only to see in hindsight what an amazing product visionary Steve is.

In this unrehearsed Q&A session (not a prepared presentation), he lays out many of the ideas that will chart Apple’s course for the next 15 years. Mac OS X, iLife, Xcode, MobileMe, iCloud, and even the iPhone and iPad—the seeds of all of these ideas were clearly already present in Steve’s mind.

Incredible.

Let’s say you have a website at https://buygadgets.example.com. Users shop for shiny gadgets on your website and then enter their credit card numbers to buy them.

Because you value the security and privacy of your users, you use SSL for all traffic. You paid top dollar for an SSL certificate signed by one of the most trusted certificate authorities in the world, so your users can always be certain that they’re communicating with your website and not some other site pretending to be yours.

To build your site, you used an open source JavaScript library called FooLib. FooLib is awesome, and it’s backed by FooCo, one of the world’s largest and most trusted technology companies. This company even provides hosted versions of FooLib on their super fast content delivery network (CDN), so that anyone who wants to can link to http://cdn.foolib.com/foo.js instead of having to host the JavaScript on their own servers.

Because browsers display a warning when you serve a page that has a mix of HTTP and HTTPS content, you want to serve FooLib over SSL. Nobody wants to annoy their users with scary security warnings. Luckily, FooCo’s CDN supports SSL! You can just load https://cdn.foolib.com/foo.js, and now your users don’t see that pesky security warning anymore.

Unfortunately, you’re now deceiving your users, and that fancy SSL certificate you bought from the world’s most trusted CA is worthless.

Why? Because you’re letting FooCo execute any JavaScript it wants on your website. You’re loading that JavaScript securely over SSL, so the browser isn’t displaying any scary warnings, but now your users aren’t just communicating with buygadgets.example.com. Now they’re also communicating with cdn.foolib.com, and since cdn.foolib.com can run JavaScript on your pages, they can also see any information the user reads or enters on those pages.

“But why would FooCo do something like that?” you ask. “After all, their motto is `Don’t be naughty`!”

Of course FooCo would never do that. They’re a solid, upstanding, trustworthy company with nothing to gain from stealing credit card numbers. They’re providing a valuable service to the community, and they genuinely do it out of the goodness of their hearts.

But you’re still deceiving your users.

Your SSL certificate says to the user “Hey, you’re safe. It’s only you and me talking here, and nobody else can decrypt our communications. And you can rest assured that I’m really who you think I am, because this trustworthy CA says so.”.

But when you load FooLib from FooCo’s CDN, you’re silently inviting FooCo into that conversation as well. FooCo has their own SSL certificate, which is also signed by a trustworthy CA, but your user doesn’t want to share their information with FooCo. They want to share their information with you. By inviting FooCo into this confidential conversation without even telling your user that you’ve done it, you’re breaking the contract that was implied by your site’s SSL certificate and by the soothing lock icon in the browser’s location bar.

The user thinks they’re only telling you their secrets, but they’re also telling FooCo their secrets. And that’s not cool.

If user trust is important to you, you shouldn’t load JavaScript from third-party CDNs on secure pages. Not even if those CDNs support SSL, and not even if they’re run by the world’s most trustworthy companies.

Now, let’s be realistic: security is always a tradeoff. You trade some convenience for some security. Some websites are willing to share their users’ private information with FooCo, because it’s more convenient to do that than to host a JavaScript library locally. That’s a decision you have to make for yourself.

But as a user, I can tell you that if I found out that a company I trusted was silently making my private information available to some other company without my knowledge, all while making me think they were keeping this information confidential, I’d be pretty pissed. Even if no harm came from it, and even if it was done with the best intentions, I’d consider it a violation of my trust. And I don’t like companies that violate my trust.

Obligatory disclaimer: I work on the YUI JavaScript library at Yahoo!, but these are my own opinions. Nothing in this post should be construed as representing the views of my employer or anyone else on the YUI team.