Category Archives: Technobabble

Technobabble

Laid off from Skyfire

I’ve kept quiet about this for a couple days, in order for other layoffs @ Skyfire to not be surprised… but yeah, I was let go this past week.

So let me utter the only four-letter word I will about Skyfire: “Ouch.”

Skyfire was a wonderful company to work for – by far the best I’ve ever had. Now it’s time to update my resume and submit it to a few places, like the Mozilla Corporation and ActiveState.

On the plus side, it means for now I can go back to working on trunk code a little easier.

Technobabble

Giggle (or usability issue) of the day

I thought this was funny, and a true statement about the state of the Web today.

Fortunately someone at Mozilla is finally tackling problems like this, by implementing HTML 5 form controls and features. At a very shocking rate, I must say – it’s as if this has been his full-time job. I can’t keep up with him – I can only read the Bugzilla e-mails I get on it. Wow.

His name is Mounir Lamouri (volkmar on irc), and if you’re remotely interested in usability of web forms, you should keep an eye on him.

By the way, if you use a form on the web for anything: yeah, you should care. 🙂 He’s doing what I dreamed of doing three years ago, but never had the time to really do. (I was busy getting hired and learning C++ – so back then I was biting off more than I could chew.)

Technobabble

The strangest crash I’ve seen in a while

Last week, I wrote about a new logging infrastructure I built to track down
a bug. In the original post, I warned that logging wasn’t a panacea – that it
could cause more trouble than it solved. I was more right than I knew, as I
added a bit of logging which led inexorably to a crash by JS_ASSERT failure.
(For those who don’t know what a JS_ASSERT is, it’s an assertion inside the
JavaScript Engine that all is well. Since JavaScript is one of the primary
languages of the World Wide Web, these assertions are really important. If
JavaScript is misbehaving, it can’t be trusted. Fail one such assertion, and
the program aborts, forcing the developer to take notice.)

At first, the crash didn’t make a damned bit of sense. I prefer to write JavaScript,
not just because I entered into software engineering (and Mozilla development)
through JavaScript, but also because it’s super-stable. In fact, the only new
code I was introducing was in JavaScript. It shouldn’t crash. Through
an unlikely chain of events, it does.

This article details how I was able to analyze the crash itself, how logging
set up the conditions for the crash, and how other logging ultimately
proved that the crash resulted from a logging call. I’ve filed this as bug 543304. Ultimately, reducing
this test case to a usable bug report will not be easy – but worth it. More details in the extended entry. (Warning: technobabble content ratio is high. If you do not want to see how this
developer thinks and debugs Mozilla code, do not read on.)

Continue reading The strangest crash I’ve seen in a while →

Technobabble

Forking internally – suggestions?

2 Comments

Imagine the following: You’re working on a new feature for your application, dependent on XULRunner 1.9.1. It’s complex, but it ends up being all chrome & JavaScript components. You write tests for it as you’re developing, and you write a specification. Everything’s coming along nicely.

Then you start thinking about moving to XULRunner 1.9.2 beta x. You compile the code, and just to be sure everything’s fine, you run a test you wrote a few weeks ago. The test and the code it is testing haven’t changed at all. The test that passed in 1.9.1.x fails in 1.9.2.x.

Now, what do you do?

This is the situation I faced a few weeks ago. It’s not an idle question. Obviously I want to find out what regressed, but my test case isn’t minimal – it’s approaching maximal. On the one hand, since the bug isn’t in code I’m working on right now (far from it), I could simply ignore it for now and keep working on my feature. On the other hand, my confidence in my code is now badly shaken. Did I misuse an API? Did the API change without my knowledge? Did I make a change in between the 1.9.1 test and the 1.9.2 test? I have to know what broke, so I can work around it for supporting both versions of XULRunner.

(As it turns out, it was a regression in the Mozilla code base itself.)

I started thinking about how to make this a deterministic test: something that I can point to and say “In this set-up, everything works… but in the other set-up, something’s off.” When I think about it though, it’s a bigger problem than just A/B comparisons. My whole approach to developing software is too informal.

More in the extended entry.

Continue reading Forking internally – suggestions? →

Technobabble

“Why are you doing this?”

One of the hardest questions for me to answer is, “Why are you doing
this?” It’s also an excellent question, one that checks what I am
working on. I recently found myself asking this question when trying to use
something I’ve never tried to use before: weak references to DOM elements.

What are weak references?

For those of you coming from JavaScript-land, you know that once you hold
a DOM element as a property, it will last as long as the object you attached
that property to. (Depending on the usage, longer.) This is because XPConnect
generates a “strong” reference to the element, which through the magic of
XPCOM reference counting, requires the element not be deleted until all
strong references are gone – including yours. Weak references are different.
They are objects which hold a pointer to your real target, but they don’t
require the real target “stay alive”. In JavaScript pseudo-code, it looks a
little like this:

function getWeakReference(obj) {
var weakPtr = {
_realPtr: obj,
QueryReferent: function(aIID)
{
if (this._realPtr)
return this._realPtr.QueryInterface(aIID);
return null;
},
QueryInterface: function(aIID)
{
if (aIID.equals(Components.interfaces.nsIWeakReference) ||
aIID.equals(Components.interfaces.nsISupports))
return this;
throw Components.results.NS_ERROR_NO_INTERFACE;
}
};
return weakPtr;
}

There’s one thing this code can’t show you: Some time in the future,
weakPtr._realPtr could be destroyed, and set to null. That
doesn’t happen in normal code (thank heaven!). But with weak references, it
can happen at any time.

Why are you doing this?

There’s a long list of sub-projects and sub-sub-projects, etc., each of
which seems to require I look at something I hadn’t tried yet. Here’s the
current list, and how I started thinking (wrongly) I needed weak
references.

(Continued on the next page…)

Continue reading “Why are you doing this?” →

Technobabble

What do you need to know to do your job?

1 Comment

I mean, what languages and tools are requirements in your profession as a software engineer? What do you have to have in your toolbag?

I’ve been thinking about this a bit over the last few months, and the list, for me at least, is pretty long:

There are also a few I infrequently use:

  • Python
  • Perl
  • PHP
  • MySQL
  • Apache
  • GDB debugging (on occasion)
  • CVS
  • Macintosh operating system
  • MathML
  • SVG
  • RDF
  • HTTP

Now, I don’t need to be an expert in all of them. I do need to be an expert in a few of them (JavaScript, HTML, CSS, XUL, XBL, XPIDL, Makefiles, tests). The rest, I can look the details up when I need them.

Even so, it’s a lot – and I imagine Professor Humphrey’s students might be intimidated to see a list like this. The good news is you don’t have to learn it all at once! In the corporate world, for new professionals, there is a learning curve. The bad news is that this list is always changing. Two years ago, I doubt I’d have listed Python above – and I suspect in less than two years, it will move into the “must-know” list.

So here’s a new Internet meme for you software engineers: List out the languages and tools you need to do your job. Extra credit if you post it as an unified diff against my own list here, linking back to this post.

I just hope I haven’t missed anything terribly obvious.