“Few outside the technological field even knew his name, yet his work has impacted every person who has ever touched an electronic device. And I mean that quite literally.
—Gene Yuh on the death of Dennis Ritchie.
John Gruber on the threat of Google:
A different perspective would be that Google is the bigger threat, and that using Apple products is a way to better protect our privacy and personal information.
This was in response to Dave Winer suggesting why he uses Android:
If there is no alternative to iOS then Apple will have exclusive control over what makes it to market. That is a future none of us should want to live in.
I agree that both threats are very real. Which is why I hope neither wins, but that they continue to compete, forcing each other to be less evil.
Star Wars: The Old Republic launches next week, and I’ve long looked forward to this game. I know what I’ll be doing as the year ends.
I was slowly working on an add-on to block social buttons on websites, but I recently just found Ghostery. They have an extension for Chrome and Firefox, and it rocks.
A lot of sites are using widgets more, be it for ads, or these terrible social buttons that have emerged. Besides not wanting to spend time downloading the social buttons that I won’t use, what I hate the most is that they all have this in common: If they lag, they stall the rest of the page.
That’s because they document.write their contents into the page, which prevents all further rendering until they’ve loaded. Don’t do that. Read this from Rich Thornett about how to make your widgets suck less.
A great post by Alex McCaw, creator of the Spine MVC JavaScript1 framework, about how front-end developers do Ajax interactions wrong. Users shouldn’t be stopped because we’re waiting on the server to respond. The interface should respond immediately, and a background sync action should be kicked off.
I’ve been thinking about this for the past year, and wanted to reflect these ideas in Shipyard, and make them come alive in the Add-on Builder, myself.
I refuse to use CoffeeScript, so it’s off limits to me. ↩
Last month I got to start working on Shipyard almost full-time, as I need it to make Add-on Builder work by the end of the quarter. I’m not ready to call Shipyard 1.0 until I’m confident with the API for Models, Controllers, and Views. Models are largely done, Views need some work, and Controllers need a start. Besides that, though, what has happened to Shipyard in the past month?
Here follows a changelog-ish list.
addListener returns a Listener object with attach and detach methods.onceaddListener, removeListener, and emitbrowser and platformIf commit lists are more your thing, you can look to GitHub. The next month should see event delegation, and more work on the View/template system.
When people ask me why they should use Chrome or Firefox, I tell them that feature-wise they’re pretty competitive. This sums up the difference greatly:
This is a Google product and it has to benefit Google. It isn’t merely about making the web better, it is also about promoting Google products and giving them an advantage over competing services. […] Even if it requires violating your privacy.
Firefox wants the web to be better, and Chrome wants Google to be better.
Joshua Topolsky about Ice Cream Sandwich:
I want to note that moving around all of these screens is buttery smooth. There’s no lag, no stutter. Animations are fluid, and everything feels cohesive and solid. It’s like Ice Cream Sandwich is more “there” than previous versions of Android.
I’m very excited for this new version. However, as neat as the Galaxy Nexus seems, why does it have to be almost 5-inches? I want something to fit in my pocket, not a sad attempt of tablet.
I used to think say you should use that in the question “What variable should I name this for closures?” This was because self is already a variable that points to window. However, I’ve since revised my opinion on what is a good variable name in this case.
I now find that and self to be too vague.
Instead, I think the variable should be named after the Class that you are currently coding in. As always, it’s easier to explain with code:
var PackageController = new Class({
doSomething: function() {
var controller = this;
someEl.addEvent('click', function(e) {
controller.react();
});
}
});
The reason is because once you start delving a couple nested functions deep1, I find myself sometimes wondering if I bound that to the value I wanted. This way leaves little to wonder about. And since you read code far more than you write it, best to write the most readable code you can.
I know, some of that can be solved by moving the functions to named methods on other objects, but you’d be lying if you said you never happened to have a function for a .forEach loop, and then another inside for an .addEvent, or something similar. ↩
My name is Sean McArthur, I'm a web developer at Mozilla, and enjoy JavaScript, Python, Android, writing and Star Wars.
