A Pragmatic Perspective by Nino D'Aversa

Lab 4: Working with Patches

Today was my first experience with patches. Obviously being involved with computers and programming for so many years I knew what a patch was, but it was very interesting to see how they are actually implemented.  I think it is a remarkable way to do things. It makes perfect sense to just have a change or ‘diff’ from the previous version to the new one.

I found the ability to specify how many context lines to be quite useful. I never really thought to deeply on how patching actually works, but when I got my mind on it during lecture I felt it was a natural and logical approach to the problem.

I think the lecture and lab gave me a good insight on how I could begin to customize Firefox to my liking. By applying patches from others or sending patches to friends you can truly customize every aspect of the application. I think I’m beginning to really appreciate the openness of open source, when you have the time and desire you can transform anything and customize it to no limit.

I think the Safe Browsing Bug is great as I heard about this new feature after Google Chrome was launched. The ability to add this patch to my custom build is nice and will give me a sneak peak of future. I wish I had more time to troll around bugzilla or write more customizations perhaps during study week or over the christmas break I will get some more time to poke around!

Lab 3: Source Code Reading Lab

Today we were asked to try and track down the code for a certain feature of the Firefox browser. I decided that I wished to find the code that runs when you click Tools->Clear Private Data. I found the tips that David gave us in the lecture useful. I was able to use the Mozilla Cross Reference tool to track down the code in the tabbrowser.dtd. From there I got the label for the function ‘clearPrivateDataCmd.label’ I than ran a search and found ‘Tools:Sanitize’ which lead me to the ’sanitize()’ function. It seems that sanitizing is what happens when you ‘clear private data’. I eventually tracked down the sanitize() which from inspection seems to do the work. It iterates through items and runs their respective clear() functions in order to perform the operation. It produces errors when santizing fails for an item.

I found this exercise interesting and useful. I can see how this would become important once you start implementing features or interacting with Firefox. The ability to tunnel down and find the exact code that runs when you click a certain button is a useful skill to have.

Lab 2: Firefox Build on Vista

I spent the last few hours downloading everything and reading over some documentation on how to build Firefox on my own system. I found the whole experience interesting. I think having David go over the steps in class to be an advantage (although I should have done the lab before class so that I could have contributed more). However I think I probably avoided a lot of pitfalls that others may have encountered after a few issues came up in class.

I also left my build time history on Patrick Lam’s wiki page so that he could make use of the data for his profiling of the build system (although I think my poor laptop specs may result in slow times, just because of hardware alone, I think I’ll do a build at home on my core 2 duo so he can have a more representative time).

What was hard?
I didn’t find anything particularly hard about the lab, but perhaps my prep from the class prevented that.

What did you learn that you didn’t know before?
I learned that Mozilla had their own build system and in order to build on windows you need to have the SDK and Visual Studio installed. I also found out how long it actually takes to build non-trivial piece of software and was quite surprised by it.

How would you do it differently next time?
I would have run the build on a quicker machine (perhaps the build machines in the research lab) since it would have taken much less time then on my puny laptop.

What advice would you give others trying this?
I would tell others to understand all the components involved and to read carefully along with the Mozilla Build Guide. Also I would like to note that it doesn’t matter if the file is called .mozconfig or mozconfig (without the period) I was unsure so I hopped on to the #seneca channel on moznet to find out the answer (ted__ helped me out, thanks again Ted).

Here is a screenshot of the about page of my build:

Lab 2: Firefox Build (About)

DPS909 – Lab 1: Ubiquity

I spent some time learning what Ubiquity was today and how to write my first command.

I think the concept is brilliant, I love the idea of the command line for firefox. I ran out of time today so I only made a simple command which allows you to jump quickly to a persons wordpress blog based on their username, but I plan to find some more time and code up more complex commands which interact more closely with the forms of a site (I really like what Hughes managed to put together, perhaps I’ll use that as a starting point).

I also need to brush up on my javascript a bit, I’m definetely a bit rusty, but overall I enjoyed the experience and look forward to hacking around with ubiquity more (I know a friend that is gonna love it when I show it to him).

The Cathedral and the Bazaar

“Given enough eyeballs, all bugs are shallow” -Eric Raymond

I particularly like this quote I believe it encapsulates the concept of the value of code review and diligent programming. I have found from personal experiences the difficulties in trying to build software like a cathedral. It becomes daunting trying to design something perfectly from the onset. Often I have found myself building something that works then going back and trying to find ways streamline things or implement design patterns. This to me is the beginning of what eventually becomes the bazaar. The idea that software is an evolution, the fact that it can never be perfected brings comfort.

I also found solace in the idea of code reuse. Starting with a partial solution and copying and pasting other code has always been my first reaction to a problem. I often say to myself, “I know I have written something like this”. I spend a few minutes tracking down the code and copying it over as a starting point. The reason I think this works so well for me is because it doesn’t bog down my thinking with syntactical detail which allows me to concentrate on the problem and adapting the code as a solution.

This leads to the concept that you don’t really understand a problem until you tried a least one solution. I have found this to be very true. I so often rewrite code, I think this fits with philosophy of just writing something that works. Trying to make something perfect on the first go is futile, much more is learned from rediscovering the problem and seeing it in a different light. That new light may put a lot of perfect code in the garbage which is why I gravitate to functionality over form a first. Once I see the patterns start to evolve in a solution that is when I start to tighten things up and start thinking about the big picture.

Lastly I would like to comment on the idea of smart data structures and dumb code. I have found this to be true as well. If you design the right classes and relationships code can become almost mundane. It often all falls down and ends up in a neat pile because if the structures are sound the other holes are easier to fill.

Well I think I have rambled on enough, let’s just say I found the article to be an interesting read with many truths.