Skip navigation

Category Archives: Code

Stuff that is directly related to coding.

I handle a lot of code review and code feedback requests these days. However, it’d be great to get more people doing this for a number of reasons:

  • More people exposed to more parts of the code base
  • More review bandwidth so more work can be checked into the tree
  • Less dependence on a small set of people

In order to get more people doing this, it would be good to document to look for, and how to make sure the code is sound. I’m sure every reviewer does things a bit differently, but I’m going to share my process. There are two types of review I do these days: feedback and review.

Feedback

Feedback is pretty simple to do, and I can usually fly though any patch (even large ones) quickly. This isn’t very thorough (in fact, I tend to keep it to general comments), but I look for the following things:

  • correct API usage (XPCOM, jsm, whatever)
  • internal invariants are not violated
  • any new APIs created make sense and aren’t confusing
  • code style matches what’s there, or follows the style guide

Review

Review is more important because once a patch gets r+, it can generally land in the tree. Consequentially, I tend to spend a lot more time on any given patch. In addition to all the things I do for a feedback request (which are looked at more closely for a review), I’ll also look at the following:

  • evaluate how well tested is the code that is being added/modified. If it isn’t well tested, I’ll generally suggest a set of test cases that I feel are the bare minimum this needs to land.
  • evaluate how this might impact other work going on in this area of the codebase
  • ensure this doesn’t add any I/O on the GUI thread
  • apply the patch and run the tests
  • if the patch looks like it might regress performance, ask for the author to verify that it does not

Note that a number of these things may not be done if I know what the patch author has already done to ensure the patch is safe.

PHP is a powerful and easy language to learn. As a developer, you must use that power in a safe and effective manner. While being easy to learn means that it is easy to pick up, it also means that you may not have any experience with writing secure code. Writing secure code is a must, however, if you do not want your server to be compromised, user data stolen, your site destroyed, or quite possibly worse. In this article, you will learn about writing more secure PHP code.
Read More »

I’ve recently picked up the task of implementing part of the Web Forms 2.0 spec from the WHATWG. So far I’ve got some work done on the RepetitionEvent Model and the RepetitionElement interface.

Well, my initial plans were to use XBL to implement a large portion of the code as per conversations with my co-conspirator Alex. Well, bz brought up an intersting point – XBL isn’t applied to elements that have a CSS property of display:none. Well, seeing as how repetition templates are supposed to be hidden with that CSS property, I couldn’t use XBL.

As a result, I get to test my knowledge of C++. Yey! I’d like to state right now that my skills in C++ are not great. In fact, I have very little expereice with it. I mean, I only have had two classes in C++, and one was a very basic course. I feel it goes without saying that I really have my work cut out for myself.

All is not lost, however. There are some really useful tools that are making this so much easier. For example, lxr lets me easily look at existing code and see how things are done the “right” way. Then, there is always a ton of documentation available on Devmo, XUL Planet, and occasionally Google comes into play. Then of course I always have the wonderful folks on irc in #developers. Folks like biesi, bz, and timeless have helped me countless times, and I am really greatful.

This is going to be a long and and winding road, but it will be very beneficial for me. I’ve already learned a lot, and I’ve got a lot more to learn.

C++ is fun!

#include
using namespace std;

class Babies {};

int
main()
{
  try {
    throw Babies();
  } catch(class Babies e) {
    cout << "Congratulations.  You caught the babies." << endl;
  }
  return 0;
}

I mean, come on...where else can you legally throw Babies?

That’s right! My first bug reported for Firefox, bug 331807.

The bug has to deal with a security error that isn’t an error in the current version of Firefox, but is an error in Bon Echo, the alpha release of Firefox 2.0. It’s a good thing that I test these things, as that would have been a big monkey wrench once 2.0 came out. I’ve found a workaround for it, but I fear that the workaround leaves the same security hole open that was patched in Bon Echo.

Regrettably, it also happens to be bug that kills the main feature of my most popular extension, RTSE. It will also kill the main feature in an extension I’ve been planning to make. Can we say ‘Curses’ anyone? Of course, this won’t affect Firefox 1.5.0.*, so those of you who uses the stable builds of Firefox will have nothing to worry about for some time.

I’ll keep updating this in the comments for anyone that is interested.