Category Archives: Software

November 20, 2014

learnyounode

Learn You The Node.js For Much Win! An intro to Node.js via a set of self-guided workshops.

The single best interactive tutorial / guide to Node.js I’ve seen yet. I’ve fiddled around with it, and for beginners, I have only one tip: read each assignment carefully. It should go without saying, but personally, I’ve yet to heed my own advice.

November 19, 2014

Brent Simmons on native apps and web apps

… Which is just to say that the distinction between native and web apps isn’t a true distinction. Since native apps are also web apps, and since native apps may also use HTML, the true distinction is between native apps and browser-based apps.

See my earlier post on the subject for my two cents.

November 17, 2014

Font rendering issues when using CSS transitions in WebKit

A couple of days ago, I was messing about with CSS3 transitions and I noticed that, in Safari at least, text rendering gets messed up for the duration of the transition. WebKit uses sub-pixel anti-aliasing for font smoothing by default; apparently this gets disabled when a GPU-accelerated CSS transition is executed, causing the text to be rendered using “regular” anti-aliasing.

I haven’t found a satisfactory workaround. This Stack Overflow thread recommends using either -webkit-transform: translateZ(0px); or, curiously, explicitly setting sub-pixel smoothing (-webkit-font-smoothing: subpixel-antialiased) even though it should be enabled by default. Either way, you’ll end up with a) thinner (and uglier) fonts even before a transition or b) a slightly less noticeable change—but a change nonetheless—in font rendering during a transition. It’s not an ideal situation.

Feel free to comment on this post if you know of a workaround that eliminates the problem without one having to force regular anti-aliasing.

Update: I found the original bug report, first filed in 2009 (!): https://bugs.webkit.org/show_bug.cgi?id=23364

November 15, 2014

With no prior knowledge of OpenStack, I must say that as a user, it has proven to be a really nice experience. Was able to configure and start and instance with an extra attached volume in a few minutes. Good stuff.

November 7, 2014

Your Job is Not to Write Code

I know. You think you were hired to write code. In fact, your entire interview process centered around how well you could write code. And I’m sure you do it really well.

But it’s not your job.

Your job is to improve our product for our users. If you want to get technical about it, your job is to improve our product for our users in a way that improves the key metrics of the company. But honestly, you don’t always have a lot of control over that second bit. You do, however, have an enormous amount of control over the first bit!

First off, let me note that I wholeheartedly disagree with 95% of this article. An engineer’s/programmer’s job is absolutely to write code. That is what they excel at, and that is why they were hired in the first place. There is a reason why a programmer’s technical skills are assessed when he or she applies for a job. That reason should be self-evident. It’s, you know, their job.

Note that I’m not saying you should disregard your users. Knowing who you are developing software for is absolutely a good thing. Every programmer should think of the customer and/or user. But then again, so should every single person in an software-intensive company. Instead of saying an engineer’s job is to improve a product for users, one should say that an engineer’s job is to write code for the purpose of improving the user experience. There’s a clear distinction to be made here. No code is ever written without a reason.

For one thing, you need to make sure that the code you write (writing code is still one of the main things you will do when doing your job, by the way) runs the way it should, even on users’ machines.

Did you know that our users probably don’t have brand new MacBook Airs with giant Thunderbolt monitors set at the highest resolution possible and running the latest version of Chrome? I checked.

This comes off and incredibly condescending and I suspect, for most engineers, it would be perceived as insulting their intelligence. Trust me, we are painfully aware of legacy systems and device fragmentation. We also know that software should run as we expect it to. That goes without saying.

In fact, you’re going to need to make sure that the code you wrote runs in production, in general. I don’t really care if your code runs locally. If your code just runs locally, then my only option is to sell your computer so that our users can use our software, and that really doesn’t scale.

This, again, is insulting peoples’ intelligence. Are we expected to make sure that software we write runs properly in a production environment? Well I never.

Of course, in order to check your changes in production, you’re going to need to make sure that your code actually gets merged and pushed into production.

Damn, I knew I was doing something wrong. Code intended for production has to be pushed to production? By us? No wonder no one is using the software I develop.

I mean, you can’t really check your changes in production if you just let them sit unpushed for hours or days. Push your code. Get it into production. Then run it and check it.

I suspect the majority of programmers would welcome full scale adoption of continuous deployment. Unfortunately, it’s seldom our choice to make. It often comes down to the ignorance of higher-ups, or customer wishes. Many customers don’t want constant updates. For a post that’s all about thinking of the users, this remark is, well, remarkable.

Another thing to remember is that sometimes users do surprising things, which means that it’s not enough just to test that your code works under perfect conditions.

Again, we do know this. Don’t insult us. Here’s a fact: no matter how much you test, things break. Software is made by, and consumed by, human beings. Human beings are prone to making mistakes.

There’s one more important part to your job. You need to make sure that we can measure whether we’re all doing our jobs well. That means adding metrics and analytics so that we can test the effects of our changes.

Strictly speaking, implementing analytics solutions is our job if we are tasked to implement them. Not otherwise. As for analysing the data, that is not our job, nor management’s. It should be done by a data analyst, a person who is expert in statistical methods and mathematical models. In addition, data should be thoroughly validated by someone who actually knows what they are doing.

I know what you’re thinking. This will all take so long! I’ll be so much less effective!

I don’t know who the author has been talking to, but I assure you, no engineer or programmer I know thinks like this.

We need to spend less time demanding that you write features and more time asking you to improve our product for our users.

As far as I know, users like new features. Just saying.

I don’t know. I don’t mean to be rude, but this entire pieces reads like it was written by someone completely oblivious to what software engineering actually entails. It reeks of the type of ignorance one can find in people that are actually far removed from the realities of software development yet seem to think they are expert at it.