FEED Validator

for Atom and RSS and KML

Congratulations!

This is a valid RSS feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 86, column 566: content:encoded contains bad characters (7 occurrences) [help]

... rn greats as Alan Hovhaness, Marcel DuprÃ©, Louis Vierne, and Olivier Me ...
                                             ^

line 138, column 40: title contains bad characters (2 occurrences) [help]

		<title>Hiring at Mozilla: Beyond ResumÃ©s and Interview Panels</title>
                                        ^

line 149, column 0: Invalid HTML: EOF in middle of construct, at line 2, column 4 [help]
```
<a style="display: block; text-align: center; font-size: 200%; border: 2p ...
```
line 272, column 0: style attribute contains potentially dangerous content: max-height (2 occurrences) [help]
```
1. On Jordanâ€<img src="https://s.w.org/images/core/emoji/12.0.0-1/72x72/212 ...
```

Source: http://benjamin.smedbergs.us/blog/feed/

<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
>
<channel>
<title>Page not found – Answers and Questions</title>
<atom:link href="http://benjamin.smedbergs.us/blog/feed/" rel="self" type="application/rss+xml" />
<link>http://benjamin.smedbergs.us/blog</link>
<description>Benjamin Smedberg's Thoughts</description>
<lastBuildDate>Thu, 19 Dec 2019 15:03:39 +0000</lastBuildDate>
<language>en-US</language>
<sy:updatePeriod>
hourly </sy:updatePeriod>
<sy:updateFrequency>
1 </sy:updateFrequency>
<generator>https://wordpress.org/?v=5.3.17</generator>
<item>
<title>Firefox Modularity and WebExtensions</title>
<link>http://benjamin.smedbergs.us/blog/2016-09-03/modularity-and-webextensions/</link>
<pubDate>Sat, 03 Sep 2016 12:50:10 +0000</pubDate>
<dc:creator><![CDATA[Benjamin Smedberg]]></dc:creator>
<category><![CDATA[Mozilla]]></category>
<category><![CDATA[addons]]></category>
<category><![CDATA[firefox]]></category>
<category><![CDATA[modularity]]></category>
<guid isPermaLink="false">http://benjamin.smedbergs.us/blog/?p=1066</guid>
<description><![CDATA[Last week, Andy McKay posted skeptical thoughts about whether Firefox system addons (also known as go-faster addons) should be required to use the WebExtensions API surface. I believe that all Firefox gofaster addons, as well as our Test Pilot experiments and SHIELD studies, should use WebExtensions. The explanation comes in three main areas: The core […]]]></description>
<content:encoded><![CDATA[Last week, Andy McKay posted <a href="http://www.agmweb.ca/2016-09-21-system-addons/">skeptical thoughts</a> about whether Firefox system addons (also known as go-faster addons) should be required to use the WebExtensions API surface. I believe that all Firefox gofaster addons, as well as our Test Pilot experiments and SHIELD studies, should use WebExtensions. The explanation comes in three main areas:
<ol>
<li>The core limiting factor in our ability to go faster while still shipping high-quality software isn’t the packaging and shipping mechanisms for our code. It’s the modularity and module boundaries of our codebase.
<li>The module structure and API surfaces of the Firefox/gecko codebase is hurting our product quality, hurting our teams and our ability to attract volunteer contributors, and hurting our ability to go faster. But there are some shining counter-examples!
<li>WebExtensions should be the future for module boundaries in the Firefox frontend. It’s worth planning carefully and going slow enough to get good module boundaries first, so that we can go blazingly fast later.
<li>Coda: by sticking to a single model for Firefox addons and builtin system addons, we can focus supporting work more effectively and make life better for both addon authors and Firefox engineers.
</ol>
<a href="http://benjamin.smedbergs.us/blog/wp-content/uploads/2016/09/05-016-DesignStructure-clustered-cost.svg"><img src="http://benjamin.smedbergs.us/blog/wp-content/uploads/2016/09/05-016-DesignStructure-clustered-cost.svg" alt="A diagram showing the "clustered cost" of Mozilla's module interdependencies from 1998-2000." class="alignright size-full wp-image-1068" /></a>
There is a long history of academic research about software modularity. I remember the <a href="http://conferences.oreillynet.com/cs/os2006/view/e_sess/9499">OSCON talk in 2006</a> when I first heard about <cite><a href="http://www.hbs.edu/faculty/Publication%20Files/05-016.pdf">Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code</a></cite>: this talk and paper has changed the way I think about software structure and open source and how to organize engineering teams including volunteers. (Incidentally, this seems like another way of saying “everything that’s important to me at work”.)
Quoting one of the followup papers that studies the impact of software modularity on change over time:
<blockquote>Specifically, we show that i) tightly-coupled components are “harder to kill,” in that they have a greater likelihood of survival in subsequent versions of a design; ii) tightly-coupled components are “harder to maintain,” in that they experience more surprise changes to their dependency relationships that are not associated with new functionality; and iii) tightly-coupled components are “harder to augment,” in that the mix of new components added in each version is significantly more modular than the legacy design.
<div>—Alan MacCormack, John Rusnak, and Carliss Y. Baldwin. <cite><a href="http://www.hbs.edu/faculty/Publication%20Files/08-038_187f1243-7d1e-464a-bddd-bf7c09873284.pdf">The Impact of Component Modularity on Design Evolution: Evidence from the Software Industry.</a></cite></div>
</blockquote>
The structure and connectedness of modules in a codebase determines what you can change easily (and therefore quickly) and what things have to change slowly. There is not a single design for a software project: you have to design the structure of your modules and interfaces based on what may need to change in the future. Even more fundamentally, the shape and structure of APIs and modules determines where teams can be innovative most successfully. Relatedly, module size and structure determines where <a href="https://www.computer.org/csdl/proceedings/hicss/2012/4525/00/4525e505.pdf">contributors can be most effective and feel most welcome</a>.
There are some shining success stories at Mozilla where good modular design has allowed teams to work independently and quickly. The devtools debugging API is a great example of carefully designing an API surface which then allowed the team to move quickly and innovate. The team spent a lot of time refactoring guts within the JS engine to expose a debugging API which wasn’t tightly tied to the underlying platform. And since devtools are isolated from the rest of the browser in an iframe, there is a natural separation which allows them to be developed as a unit and independently. The advantages of this model became quickly apparent when the team started reusing the same basic debugging structure for a desktop Firefox to debug content in Firefox for Android, or debug the Firefox chrome itself, or even debug content in Chrome!
A lot of the pain and slowness in Firefox development relates to our code not having well-defined, documented, or enforced module boundaries or interfaces. Within the Firefox frontend itself, we have many different kinds of functionality that runs in the single technical context of the main browser window. We sometimes pretend that there are relatively clean boundaries between the Firefox frontend and the underlying platform, but this is a myth. There are pervasive implementation dependencies between things like the tab browser in the frontend and the network/docshell/PSM validation in the platform which often have to be modified together.
Lack of clean modules and interfaces manifest themselves in many ways. It is notoriously difficult to write tests for Firefox. This is pretty natural, since good tests often focus on the interface boundaries between modules. It also makes it extremely difficult to “mock” unrelated modules cleanly for a test. The pervasiveness of “random oranges” is not because tests are written poorly: it is most related to tests being very difficult to write well.
Historically problems maintaining and building Firefox addons and the addon ecosystem is directly related to not having an API surface for addons. Because writing an addon usually involved hacking into the structure of the browser.xul DOM and JS, it was natural that addon authors were frequently affected by browser changes. And it was very difficult for anyone, Firefox hacker or addon hacker alike, to know whether or how any particular change would affect addons. The most common complaint from addon authors was that we didn’t have good API documentation; but this is not a problem with the documentation. It’s a problem of not having good APIs. Similarly, a major user complaint was that addons break too often. This is not a problem of addon authors being bad coders; it is more fundamentally a lack of stable API surfaces that would allow anyone to write code that continues working over time.
In order to make addon development fun and productive again, we’ve made big investments in WebExtensions. WebExtensions is a clearly specified, tested, documented, and maintained API surface targeted at addons. The WebExtensions system will allow addon authors to innovate and be creative within a structure that lets Firefox support them over time. Over the next year, we expect basically all Firefox addons to move to WebExtensions. We’ve already seen this energize the addon community and especially promote addon development by authors who gave up developing old-style Firefox addons.
Within Firefox development itself, we need this same combination of structure and innovation. Starting with the new system addons, we need to spend the time up front to build API surfaces that allow teams within Mozilla to experiment and build new systems safely, with the confidence that they aren’t going to break Firefox by accident. We need to have enough foresight to say where we want to experiment, so that we can make sure that we have the right API and module boundaries in place so that experiments can be successful.
If our system addons are still coded in a way that depends on the internal structure of browser.xul, or XPCOM, or the network stack, then they have inherently high testing cost. We need to re-validate them against each release, and be very cautious about pushing changes because we don’t know whether any change could break the browser.
If, on the other hand, we use WebExtensions and have technical guarantees that addons are isolated from other code, we have the ability to push new changes aggressively and actually independently. QA and release teams don’t need to test every change extensively and in all combinations: instead we can use the technical isolation guarantees of the WebExtensions API to allow teams to be more completely independent, the same way we want addon authors to be essentially independent.
As we start developing system addons using WebExtensions, there are going to be APIs which we don’t want to commit to, or that we’re not sure about. I think we will have to come up with APIs that are not exposed to all addons, but only to particular system addons where we understand the risks and experimental nature. We are going to need a way for many teams to be responsible for their own API surfaces, and not route every change through the addons engineering team. We should embrace these challenges as the cost of success.
Having more code use WebExtensions is a way to focus engineering efforts. We know that both addons and system code needs better support for profiling and performance monitoring, telemetry, unit testing, localization, and other engineering support functions. By having our system addons use the same basic API layer as external addons, we can build tools that improve life for everyone. The cost of building each of these things well is large, but through shared effort we can make our engineering investment return much greater dividends.
At the end of the day, I believe we should end up in a world where most of the Firefox frontend is made available via system addons and glued together using well-defined API surfaces. What would it be like to have our tabbed browser, location bar, search interface, bookmarks system, session restore, etc be independently hackable? It would be awesome! It would mean a higher quality product, with more opportunities for volunteer contributors to improve specific areas. It would likely mean reduced edit/build/run/test cycles. It might even give addon authors the ability to completely replace certain components of the browser if they so choose.
I shared a draft of this post with Andy and other tech leads and got some great feedback. In order for discussion to go to one place, please post any replies or thoughts to the <a href="https://mail.mozilla.org/listinfo/firefox-dev">firefox-dev</a> mailing list.
]]></content:encoded>
</item>
<item>
<title>Concert This Sunday: The King of Instruments and the Instrument of Kings</title>
<link>http://benjamin.smedbergs.us/blog/2016-06-02/concert-this-sunday-the-king-of-instruments-and-the-instrument-of-kings/</link>
<comments>http://benjamin.smedbergs.us/blog/2016-06-02/concert-this-sunday-the-king-of-instruments-and-the-instrument-of-kings/#comments</comments>
<pubDate>Thu, 02 Jun 2016 20:35:33 +0000</pubDate>
<dc:creator><![CDATA[Benjamin Smedberg]]></dc:creator>
<category><![CDATA[untagged]]></category>
<guid isPermaLink="false">http://benjamin.smedbergs.us/blog/?p=1057</guid>
<description><![CDATA[This coming Sunday, I will be performing a concert with trumpeter Kyra Hill as part of the parish concert series. I know that many of the readers of my site don’t live anywhere near Johnstown, Pennsylvania, but if you do, we’d love to have you, and it’ll be a lot of fun. Sunday, 5-June 2016 […]]]></description>
<content:encoded><![CDATA[This coming Sunday, I will be performing a concert with trumpeter Kyra Hill as part of the parish concert series. I know that many of the readers of my site don’t live anywhere near Johnstown, Pennsylvania, but if you do, we’d love to have you, and it’ll be a lot of fun.
<div style="margin-left: 10%">
Sunday, 5-June 2016 
2:30 p.m. 
Our Mother of Sorrows Church 
415 Tioga Street, Johnstown PA
</div>
<h2>Why you should come</h2>
<ul>
<li>You’ll get to hear what wise men riding camels sneaking away from Herod sounds like.
<li>If that’s not your thing, what about eight minutes of non-stop fantasy based on the four notes of the bell tower of Westminster?
<li>Or a trumpet playing Gregorian chant?
<li>During the intermission, there will be a pipe organ petting zoo. If you’ve always wondered what all those knobs and buttons are for, here’s your chance to find out!
</ul>
I am proud that almost all of the music in this program was written in the last 100 years: there are compositions dating from 1919, 1929, 1935, 1946, 1964, 2000, and 2004. Unlike much of the classical music world which got lost around 1880 and never recovered, music for organ has seen a explosion of music and musical styles that continues to the present day. Of course there is the obligatory piece by J.S. Bach, because how could you have an organ concert without any Bach? But beyond that, there are pieces by such modern greats as Alan Hovhaness, Marcel DuprÃ©, Louis Vierne, and Olivier Messiean.
It’s been a while since I performed a full-length concert; it has been fun to get back in the swing of regular practice and getting pieces up to snuff. I hope you find it as enjoyable to listen to as it has been for me to prepare!
]]></content:encoded>
<wfw:commentRss>http://benjamin.smedbergs.us/blog/2016-06-02/concert-this-sunday-the-king-of-instruments-and-the-instrument-of-kings/feed/</wfw:commentRss>
<slash:comments>3</slash:comments>
</item>
<item>
<title>Yak Shaving</title>
<link>http://benjamin.smedbergs.us/blog/2015-05-27/yak-shaving/</link>
<comments>http://benjamin.smedbergs.us/blog/2015-05-27/yak-shaving/#comments</comments>
<pubDate>Wed, 27 May 2015 20:22:56 +0000</pubDate>
<dc:creator><![CDATA[Benjamin Smedberg]]></dc:creator>
<category><![CDATA[Mozilla]]></category>
<category><![CDATA[yak-shaving]]></category>
<guid isPermaLink="false">http://benjamin.smedbergs.us/blog/?p=1047</guid>
<description><![CDATA[Yak shaving tends to be looked down on. I don’t necessarily see it that way. It can be a way to pay down technical debt, or learn a new skill. In many ways I consider it a sign of broad engineering skill if somebody is capable of solving a multi-part problem. It started so innocently. […]]]></description>
<content:encoded><![CDATA[<a href="http://sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html">Yak shaving</a> tends to be looked down on. I don’t necessarily see it that way. It can be a way to pay down technical debt, or learn a new skill. In many ways I consider it a sign of broad engineering skill if somebody is capable of solving a multi-part problem.
It started so innocently. My team has been working on unifying the Firefox Health Report and Telemetry data collection systems, and there was a bug that I thought I could knock off pretty easily: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1121013">“FHR data migration: org.mozilla.crashes”</a>. Below are the roadblocks, mishaps, and sideshows that resulted, and I’m not even done yet:
<dl>
<dt>Tryserver failure: crashes
<dd>Constant crashes only on Linux opt builds. It turned out this was entirely my fault. The following is not a safe access pattern because of c++ temporary lifetimes:
<pre>nsCSubstringTuple str = str1 + str2;
Fn(str);</pre>
<dt>Backout #1: talos xperf failure
<dd>After landing, the code was backed out because the xperf Talos test detected main-thread I/O. On desktop, this was a simple ordering problem: we always do that I/O during startup to initialize the crypto system; I just moved it slightly earlier in the startup sequence. Why are we initializing the crypto system? To generate a random number. Fixed this by <a href="https://bug1140132.bugzilla.mozilla.org/attachment.cgi?id=8598171">whitelisting the I/O</a>. This involved landing code to the separate Talos repo and then telling the main Firefox tree to use the new revision. Much thanks to Aaron Klotz for <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1140132#c10">helping me</a> figure out the right steps.
<dt>Backout #2: test timeouts
<dd>Test timeouts if the first test of a test run uses the PopupNotifications API. This wasn’t caught during initial try runs because it appeared to be a well-known random orange. I was apparently changing the startup sequence just enough to tickle a focus bug in the test harness. It so happened that the particular test which runs first depends on the e10s or non-e10s configuration, leading to some confusion about what was going on. Fortunately, I was able to reproduce this locally. Gavin Sharp and Neil Deakin helped get the test harness in order in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1138079">bug 1138079</a>.
<dt>Local test failures on Linux
<dd>I discovered that several xpcshell tests were failing locally on Linux which were working fine on tryserver. After some debugging, I discovered that the tests thought I wasn’t using Linux, because the cargo-culted test for Linux was <tt>let isLinux = ("@mozilla.org/gnome-gconf-service;1" in Cc)</tt>. This means that if gconf is disabled at build time or not present at runtime, the tests will fail. I installed GConf2-devel and rebuilt my tree and things were much better.
<dt>Incorrect failure case in the extension manager
<dd>While debugging the test failures, I discovered an <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1167204">incorrect codepath in GMPProvider.jsm</a> for clients which are not Windows, Mac, or Linux (Android and the non-Linux Unixes).
<dt>Android performance regression
<dd>The landing caused an Android startup performance regression, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1163049">bug 1163049</a>. On Android, we don’t initialize NSS during startup, and the earlier initialization of the addon manager caused us to generate random Sync IDs for addons. I first fixed this by using Math.random() instead of good crypto, but Richard Newman suggested that I just make Sync generation lazy. This appears to work and will land when there is an open tree.
<dt>mach bootstrap on Fedora doesn’t work for Android
<dd>As part of debugging the performance regression, I built Firefox for Android for the first time in several years. I discovered that mach bootstrap for Android isn’t implemented on Fedora Core. I manually installed packages until it built properly. I have a list of the packages I installed and I’ll file a bug to fix mach bootstrap when I get a chance.
<dt>android build-tools not found
<dd>A configure check for the android build-tools package failed. I still don’t understand exactly why this happened; it has something to do with a version that’s too new and unexpected. Nick Alexander pointed me at a patch on <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1162000">bug 1162000</a> which fixed this for me locally, but it’s not the “right” fix and so it’s not checked into the tree.
<dt>Debugging on Android (jimdb)
<dd>Binary debugging on Android turned out to be difficult. There are some great docs <a href="https://wiki.mozilla.org/Mobile/Fennec/Android/GDB">on the wiki</a>, but those docs failed to mention that you have to pass the configure flag –enable-debug-symbols. After that, I discovered that pending breakpoints don’t work by default with Android debugging, and since I was debugging a startup issue that was a critical failure. I wrote an <a href="https://ask.mozilla.org/question/1563/how-do-i-set-an-early-breakpoint-in-firefox-for-android/">ask.mozilla.org question</a> and got a custom patch which finally made debugging work. I also had to patch the implementation of DumpJSStack() so that it would print to logcat on Android; this is another bug that I’ll file later when I clean up my tree.
<dt>Crash reporting broken on Mac
<dd>I <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1166759">broke crash report submission</a> on mac for some users. Crash report annotations were being truncated from unicode instead of converted from UTF8. Because JSON.stringify doesn’t produce ASCII, this was breaking crash reporting when we tried to parse the resulting data. This was an API bug that existed prior to the patch, but I should have caught it earlier. Shoutout to Ted Mielczarek for fixing this and adding automated tests!
<dt>Semi-related weirdness: improving the startup performance of Pocket
<dd>The Firefox Pocket integration caused a significant startup performance issue on some trees. The <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1163512#c35">details</a> are especially gnarly, but it seems that by reordering the initialization of the addon manager, I was able to turn a performance regression into a win by accident. Probably something to do with I/O wait, but it still feels like spooky action at a distance. Kudos to Joel Maher, Jared Wein and Gijs Kruitbosch for diving into this under time pressure.
</dd>
Experiences like this are frustrating, but as long as it’s possible to keep the final goal in sight, fixing unrelated bugs along the way might be the best thing for everyone involved. It will certainly save context-switches from other experts to help out. And doing the Android build and debugging was a useful learning experience. 
Perhaps, though, I’ll go back to my primary job of being a manager.
]]></content:encoded>
<wfw:commentRss>http://benjamin.smedbergs.us/blog/2015-05-27/yak-shaving/feed/</wfw:commentRss>
<slash:comments>2</slash:comments>
</item>
<item>
<title>Hiring at Mozilla: Beyond ResumÃ©s and Interview Panels</title>
<link>http://benjamin.smedbergs.us/blog/2015-05-11/hiring-at-mozilla-beyond-resumes-and-interview-panels/</link>
<comments>http://benjamin.smedbergs.us/blog/2015-05-11/hiring-at-mozilla-beyond-resumes-and-interview-panels/#comments</comments>
<pubDate>Mon, 11 May 2015 11:32:30 +0000</pubDate>
<dc:creator><![CDATA[Benjamin Smedberg]]></dc:creator>
<category><![CDATA[Mozilla]]></category>
<category><![CDATA[hiring]]></category>
<guid isPermaLink="false">http://benjamin.smedbergs.us/blog/?p=1036</guid>
<description><![CDATA[The standard tech hiring process is not good at selecting the best candidates, and introduces unconscious bias into the hiring process. The traditional resume screen, phone screen, and interview process is almost a dice-roll for a hiring manager. This year, my team has several open positions and we’re trying something different, both in the pre-interview […]]]></description>
<content:encoded><![CDATA[The standard tech hiring process is not good at selecting the best candidates, and introduces unconscious bias into the hiring process. The traditional resume screen, phone screen, and interview process is almost a dice-roll for a hiring manager. This year, my team has several open positions and we’re trying something different, both in the pre-interview screening process and in the interview process itself.
<a style="display: block; text-align: center; font-size: 200%; border: 2px dashed #AAA; background-color: #AAA; border-radius: 5px; padding: 5px; margin: 10px;"href="https://careers.mozilla.org/en-US/position/oZgW0fwV">Hiring Firefox Platform Engineers now!</a>
Earlier this year I attended a workshop for Mozilla managers by the <a href="http://gender.stanford.edu/">Clayman Institute</a> at Stanford. One of the key lessons is that when we (humans) don’t have clear criteria for making a choice, we tend alter our criteria to match subconscious preferences (see <a href="http://gender.stanford.edu/news/2013/leveling-playing-field">this article</a> for some examples and more information). Another key lesson is that when humans lack information about a situation, our brain uses its subconscious associations to fill in the gaps.
<h2>Candidate Screening</h2>
I believe job descriptions are very important: not only do they help candidates decide whether they want a particular job, but they also serve as a guide to the kinds of things that will be required or important during the interview process. Please read the job description carefully before applying to any job!
In order to hire more fairly, I have changed the way I write job descriptions. Previously I mixed up job responsibilities and applicant requirements in one big bulleted list. Certainly every engineer on my team is going to eventually use C++ and JavaScript, and probably Python, and in the future Rust. But it isn’t a requirement that you know all of these coming into a job, especially as a junior engineer. It’s part of the job to work on a high-profile open-source project in a public setting. But that doesn’t mean you must have prior open-source experience. By separating out the job expectations and the applicant requirements, I was able to create a much clearer set of screening rules for incoming applications, and also clearer expectations for candidates.
ResumÃ©s are a poor tool for ranking candidates and deciding which candidates are worth the investment in a phone screen or interview. ResumÃ©s give facts about education or prior experience, but rarely make it clear whether somebody is an excellent engineer. To combat this, my team won’t be using only resumÃ©s as a screening tool. If a candidate matches basic criteria, such as living in a reasonable time zone and having demonstrated expertise in C++, JavaScript, or Python on their resumÃ© or code samples, we will ask each candidate to submit a short written essay (like a blog post) describing their favorite debugging or profiling tool.
Why did I pick an essay about a debugging or profiling tool? In my experience, every good coder has a toolbox, and as coders gain experience they are naturally better <a href="http://www.cs.unc.edu/~brooks/Toolsmith-CACM.pdf" title=""The Computer Scientist as Toolsmith" by Fred Brooks">toolsmiths</a>. I hope that this essay requirement will be good way to screen for programmer competence and to gauge expertise.
With resumÃ©s, essays, and code samples in hand, <a href="https://blog.mozilla.org/vdjeric/">Vladan</a> and I will go through the applications and filter the applications. Each passing candidate will proceed to phone screens, to check for technical skill but more importantly to sell the candidate on the team and match them up with the best position. My goal is to exclude applications that don’t meet the requirements, not to rank candidates against each other. If there are too many qualified applicants, we will select a random sample for interviews. In order to make this possible, we will be evaluating applications in weekly batches.
<h2>Interview Process</h2>
To the extent possible, the interview format should line up with the job requirements. The typical Mozilla technical interview is five or six 45-minute 1:1 interview sessions. This format heavily favors people who can think quickly on their feet and who are personable. Since neither of those attributes is a requirement for this job, that format is a poor match. Here are the requirements in the job description that we need to evaluate during the interview:
<ul>
<li>Experience writing code. A college degree is not necessary or sufficient.
<li>Expertise in any of C++, JavaScript, or Python.
<li>Ability to learn new skills and solve unfamiliar problems effectively.
<li>Experience debugging or profiling.
<li>Good written and verbal communication skills.
<li>Candidates must be located in North or South America, Europe, Africa, or the Middle East.
</ul>
This is the interview format that we came up with to assess the requirements:
<ul>
<li>A 15-minute prepared presentation on a topic related to the candidate’s prior experience and expertise. This will be done in front of a small group. A 30-minute question and answer session will follow. Assesses experience writing code and verbal communication skills.
<li>A two-hour mentoring session with two engineers from the team. The candidate will be working in a language they already know (C++/JS/Python), but will be solving an unfamiliar problem. Assesses experience writing code, language expertise, and ability to solve unfamiliar problems.
<li>A 45-minute 1:1 technical interview. This will assess some particular aspect of the candidate’s prior experience with technical questions, especially if that experience is related to optional/desired skills in the job description. Assesses specialist or general expertise and verbal communication.
<li>A 45-minute 1:1 interview with the hiring manager. This covers a wide range of topics including work location and hours, expectations about seniority, and to answer questions that the candidate has about Mozilla, the team, or the specific role they are interviewing for. Assesses candidate location and desire to be part of the team.
</ul>
During the debrief and decision process, I intend to focus as much as possible on the job requirements. Rather than asking a simple “should we hire this person” question, I will ask interviewers to rate the candidate on each job requirement and responsibility, as well as any desired skillset. By orienting the feedback to the job description I hope that we can reduce the effects of unconscious bias and improve the overall hiring process.
<h2>Conclusion</h2>
This hiring procedure is experimental. My team and I have concerns about whether candidates will be put off by the essay requirement or an unusual interview format, and whether plagiarism will make the essay an ineffective screening tool. We’re concerned about keeping the hiring process moving and not introducing too much delay. After the first interview rounds, I plan on evaluating the process, and ask candidates to provide feedback about their experience.
If you’re interested, check out my prior post, <a href="http://benjamin.smedbergs.us/blog/2014-10-02/how-i-hire-at-mozilla/" title="How I Hire at Mozilla">How I Hire At Mozilla</a>.
]]></content:encoded>
<wfw:commentRss>http://benjamin.smedbergs.us/blog/2015-05-11/hiring-at-mozilla-beyond-resumes-and-interview-panels/feed/</wfw:commentRss>
<slash:comments>8</slash:comments>
</item>
<item>
<title>Using crash-stats-api-magic</title>
<link>http://benjamin.smedbergs.us/blog/2015-04-20/using-crash-stats-api-magic/</link>
<comments>http://benjamin.smedbergs.us/blog/2015-04-20/using-crash-stats-api-magic/#comments</comments>
<pubDate>Mon, 20 Apr 2015 17:45:41 +0000</pubDate>
<dc:creator><![CDATA[Benjamin Smedberg]]></dc:creator>
<category><![CDATA[Mozilla]]></category>
<category><![CDATA[crash-stats-api-magic]]></category>
<category><![CDATA[socorro]]></category>
<guid isPermaLink="false">http://benjamin.smedbergs.us/blog/?p=1017</guid>
<description><![CDATA[A while back, I wrote the tool crash-stats-api-magic which allows custom processing of results from the crash-stats API. This tool is not user-friendly, but it can be used to answer some pretty complicated questions. As an example and demonstration, see a bug that Matthew Gregan filed this morning asking for a custom report from crash-stats: […]]]></description>
<content:encoded><![CDATA[A while back, I wrote the tool <a href="http://bsmedberg.github.io/crash-stats-api-magic/analyze-crash.html">crash-stats-api-magic</a> which allows custom processing of results from the crash-stats API. This tool is not user-friendly, but it can be used to answer some pretty complicated questions.
As an example and demonstration, see <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1156172">a bug</a> that <a href="http://blog.mjg.im/">Matthew Gregan</a> filed this morning asking for a custom report from crash-stats:
<blockquote>In trying to debug bug 1135562, it’s hard to guess the severity of the problem or look for any type of version/etc. correlation because there are many types of hangs caught under the same mozilla::MediaShutdownManager::Shutdown stack. I’d like a report that contains only those with mozilla::MediaShutdownManager::Shutdown in the hung (main thread) stack *and* has wasapi_stream_init on one of the other threads, please.</blockquote>
To build this report, start with a basic query and then refine it in the tool:
<ol>
<li>Construct a <a href="https://crash-stats.mozilla.com/search/?signature=~MediaShutdownManager%3A%3AShutdown&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform">supersearch query</a> to select the crashes we’re interested in. The only criteria for this query was “signature contains ‘MediaShutdownManager::Shutdown`. When possible, filter on channel, OS, and version to reduce noise.
<li>After the supersearch query is constructed, choose “More Options” from the results page and copy the “Public API URL” link.
<li>Load <a href="http://bsmedberg.github.io/crash-stats-api-magic/analyze-crash.html">crash-stats-api-magic</a> and paste the query URL. Choose “Fetch” to fetch the results. Look through the raw data to get a sense for its structure. <a href="http://bsmedberg.github.io/crash-stats-api-magic/analyze-crash.html?url=https%3A%2F%2Fcrash-stats.mozilla.com%2Fapi%2FSuperSearch%2F%3Fsignature%3D~mozilla%253A%253AMediaShutdownManager%253A%253AShutdown%26_columns%3Ddate%26_columns%3Dsignature%26_columns%3Dproduct%26_columns%3Dversion%26_columns%3Dbuild_id%26_columns%3Dplatform&rulecount=0">Link</a>
<li>The meat of this function is to filter out the crashes that don’t have “wasapi_stream_init” on a thread. Choose “New Rule” and create a filter rule:
<pre>function(d) {
var ok = false;
d.json_dump.threads.forEach(function(thread) {
thread.frames.forEach(function(frame) {
if (frame.function && frame.function.indexOf("wasapi_stream_init") != -1) {
ok = true;
}
});
});
return ok;
}</pre>
Choose “Execute” to run the filter. <a href="http://bsmedberg.github.io/crash-stats-api-magic/analyze-crash.html?url=https%3A%2F%2Fcrash-stats.mozilla.com%2Fapi%2FSuperSearch%2F%3Fsignature%3D~mozilla%253A%253AMediaShutdownManager%253A%253AShutdown%26_columns%3Ddate%26_columns%3Dsignature%26_columns%3Dproduct%26_columns%3Dversion%26_columns%3Dbuild_id%26_columns%3Dplatform&rulecount=1&rule0_action=filter&rule0_fn=function%28d%29%20%7B%0A%20%20var%20ok%20%3D%20false%3B%0A%20%20d.json_dump.threads.forEach%28function%28thread%29%20%7B%0A%20%20%20%20thread.frames.forEach%28function%28frame%29%20%7B%0A%20%20%20%20%20%20if%20%28frame.function%20%26%26%20frame.function.indexOf%28%22wasapi_stream_init%22%29%20!%3D%20-1%29%20%7B%0A%20%20%20%20%20%20%20%20ok%20%3D%20true%3B%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%29%3B%0A%20%20%7D%29%3B%0A%20%20return%20ok%3B%0A%7D">Link</a>
<li>To get the final report we output only the signature and the crash ID for each result. Choose “New Rule” again and create a mapping rule:
<pre>function(d) {
return [d.uuid, d.signature];
}</pre>
<a href="http://bsmedberg.github.io/crash-stats-api-magic/analyze-crash.html?url=https%3A%2F%2Fcrash-stats.mozilla.com%2Fapi%2FSuperSearch%2F%3Fsignature%3D~mozilla%253A%253AMediaShutdownManager%253A%253AShutdown%26_columns%3Ddate%26_columns%3Dsignature%26_columns%3Dproduct%26_columns%3Dversion%26_columns%3Dbuild_id%26_columns%3Dplatform&rulecount=2&rule0_action=filter&rule0_fn=function%28d%29%20%7B%0A%20%20var%20ok%20%3D%20false%3B%0A%20%20d.json_dump.threads.forEach%28function%28thread%29%20%7B%0A%20%20%20%20thread.frames.forEach%28function%28frame%29%20%7B%0A%20%20%20%20%20%20if%20%28frame.function%20%26%26%20frame.function.indexOf%28%22wasapi_stream_init%22%29%20!%3D%20-1%29%20%7B%0A%20%20%20%20%20%20%20%20ok%20%3D%20true%3B%0A%20%20%20%20%20%20%7D%0A%20%20%20%20%7D%29%3B%0A%20%20%7D%29%3B%0A%20%20return%20ok%3B%0A%7D&rule1_action=map&rule1_fn=function%28d%29%20%7B%0A%20%20return%20%5Bd.uuid%2C%20d.signature%5D%3B%0A%7D">Link</a>
</ol>
One of the advantages of this tool is that it is possible to iterate quickly on the data without constantly re-querying, but at the end it should be possible to permalink to the results in bugzilla or email exchanges.
If you need to do complex crash-stats analysis, please try it out! email me if you have questions, and <a href="https://github.com/bsmedberg/crash-stats-api-magic">pull requests</a> are welcome.
]]></content:encoded>
<wfw:commentRss>http://benjamin.smedbergs.us/blog/2015-04-20/using-crash-stats-api-magic/feed/</wfw:commentRss>
<slash:comments>1</slash:comments>
</item>
<item>
<title>Gratitude Comes in Threes</title>
<link>http://benjamin.smedbergs.us/blog/2015-02-17/gratitude-comes-in-threes/</link>
<comments>http://benjamin.smedbergs.us/blog/2015-02-17/gratitude-comes-in-threes/#comments</comments>
<pubDate>Tue, 17 Feb 2015 22:37:02 +0000</pubDate>
<dc:creator><![CDATA[Benjamin Smedberg]]></dc:creator>
<category><![CDATA[Mozilla]]></category>
<category><![CDATA[beltzner]]></category>
<category><![CDATA[johnath]]></category>
<category><![CDATA[leadership]]></category>
<category><![CDATA[mentoring]]></category>
<category><![CDATA[shaver]]></category>
<guid isPermaLink="false">http://benjamin.smedbergs.us/blog/?p=1004</guid>
<description><![CDATA[Today Johnathan Nightingale announced his departure from Mozilla. There are three special people at Mozilla who shaped me into the person I am today, and Johnathan Nightingale is one of them: Mike Shaver taught me how to be an engineer. I was a full-time musician who happened to be pretty good at writing code and […]]]></description>
<content:encoded><![CDATA[ Today Johnathan Nightingale <a href="http://blog.johnath.com/2015/02/17/home-for-a-rest/">announced</a> his departure from Mozilla. There are three special people at Mozilla who shaped me into the person I am today, and Johnathan Nightingale is one of them:
<img src="http://benjamin.smedbergs.us/blog/wp-content/uploads/2015/02/triumverate.jpg" title="Left to right: Shaver, Johnathan, Beltzner" width="386" height="360" align="right">
Mike Shaver taught me how to be an engineer. I was a full-time musician who happened to be pretty good at writing code and volunteering for Mozilla. There were many people at Mozilla who helped teach me the fine points of programming, and techniques for being a good programmer, but it was shaver who taught me the art of software engineering: to focus on simplicity, to keep the ultimate goal always in mind, when to <a href="http://quotes.burntelectrons.org/1077">compromise</a> in order to ship, and when to spend the time to make something impossibly great. Shaver was never my manager, but I credit him with a lot of my engineering success. Shaver left Mozilla a while back to do great things at Facebook, and I still miss him.
Mike Beltzner taught me to care about users. Beltzner was never my manager either, but his single-minded and sometimes pugnacious focus on users and the user experience taught me how to care about users and how to engineer products that people might actually want to use. It’s easy for an engineer to get caught up in the most perfect technology and forget why we’re building any of this at all. Or to get caught up trying to change the world, and forget that you can’t change the world without a great product. Beltzner left Mozilla a while back and is now doing great things at Pinterest.
Perhaps it is just today talking, but I will miss Johnathan Nightingale most of all. He taught me many things, but mostly how to be a leader. I have had the privilege of reporting to Johnathan for several years now. He taught me the nuances of leadership and management; how to support and grow my team and still be comfortable applying my own expertise and leadership. He has been a great and empowering leader, both for me personally and for Firefox as a whole. He also taught me how to edit my own writing and others, and especially never to bury the lede. Now Johnathan will also be leaving Mozilla, and undoubtedly doing great things on his next adventure.
It doesn’t seem coincidental that triumverate were all Torontonians. Early Toronto Mozillians, including my three mentors, built a culture of teaching, leading, mentoring, and Mozilla is better because of it. My new boss isn’t in Toronto, so it’s likely that I will be traveling there less. But I still hold a special place in my heart for it and hope that Mozilla Toronto will continue to serve as a model of mentoring and leadership for Mozilla.
Now I’m a senior leader at Mozilla. Now it’s my job to mentor, teach, and empower Mozilla’s leaders. I hope that I can be nearly as good at it as these wonderful Mozillians have been for me.
]]></content:encoded>
<wfw:commentRss>http://benjamin.smedbergs.us/blog/2015-02-17/gratitude-comes-in-threes/feed/</wfw:commentRss>
<slash:comments>2</slash:comments>
</item>
<item>
<title>An Invitation</title>
<link>http://benjamin.smedbergs.us/blog/2014-11-30/an-invitation/</link>
<pubDate>Sun, 30 Nov 2014 22:19:22 +0000</pubDate>
<dc:creator><![CDATA[Benjamin Smedberg]]></dc:creator>
<category><![CDATA[Mozilla]]></category>
<category><![CDATA[Catholic]]></category>
<category><![CDATA[Christian]]></category>
<category><![CDATA[Jesus Christ]]></category>
<guid isPermaLink="false">http://benjamin.smedbergs.us/blog/?p=988</guid>
<description><![CDATA[I’d like to invite my blog readers and Mozilla coworkers to Jesus Christ. For most Christians, today marks the beginning of Advent, the season of preparation before Christmas. Not only is this a time for personal preparation and prayer while remembering the first coming of Christ as a child, but also a time to prepare […]]]></description>
<content:encoded><![CDATA[I’d like to invite my blog readers and Mozilla coworkers to Jesus Christ.
For most Christians, today marks the beginning of Advent, the season of preparation before Christmas. Not only is this a time for personal preparation and prayer while remembering the first coming of Christ as a child, but also a time to prepare the entire world for Christ’s second coming. Christians invite their friends, coworkers, and neighbors to experience Christ’s love and saving power.
I began my journey to Christ through music and choirs. Through these I discovered beauty in the teachings of Christ. There is a unique beauty that comes from combining <a href="http://www.vatican.va/holy_father/john_paul_ii/encyclicals/documents/hf_jp-ii_enc_15101998_fides-et-ratio_en.html" title="Fides et Ratio - Letter of Pope John Paul II">faith and reason</a>: belief in Christ does not require superstition nor ignorance of history or science. Rather, belief in Christ’s teachings brought me to a wholeness of understanding the truth in all it’s forms, and our own place within it.
Although Jesus is known to Christians as priest, prophet, and king, I have a special and personal devotion to Jesus as king of heaven and earth. The feast of Christ the King at the end of the church year is my personal favorite, and it is a particular focus when I perform and composing music for the Church. I discovered this passion during college; every time I tried to plan my own life, I ended up in confusion or failure, while every time I handed my life over to Christ, I ended up being successful. My friends even got me a rubber stamp which said “How to make God laugh: tell him your plans!” This understanding of Jesus as ruler of my life has led to a profound trust in divine providence and personal guidance in my life. It even led to my becoming involved with Mozilla and eventually becoming a Mozilla employee: I was a church organist and switching careers to become a computer programmer was a leap of faith, given my lack of education.
Making a religious invitation to coworkers and friends at Mozilla is difficult. We spend our time and build our deepest relationships in a setting of on email, video, and online chat, where off-topic discussions are typically out of place. I want to share my experience of Christ with those who may be interested, but I don’t want to offend or upset those who aren’t.
This year, however, presents me with a unique opportunity. Most Mozilla employees will be together for a shared planning week. If you will be there, please feel free to find me during our down time and ask me about my experience of Christ. If you aren’t at the work week, but you still want to talk, I will try to make that work as well! <a href="http://benjamin.smedbergs.us/contact/">Email me.</a>
<blockquote>
1. On Jordanâ€<img src="https://s.w.org/images/core/emoji/12.0.0-1/72x72/2122.png" alt="™" class="wp-smiley" style="height: 1em; max-height: 1em;" />s bank, the Baptistâ€<img src="https://s.w.org/images/core/emoji/12.0.0-1/72x72/2122.png" alt="™" class="wp-smiley" style="height: 1em; max-height: 1em;" />s cry 
Announces that the Lord is nigh; 
Awake, and hearken, for he brings 
Glad tidings of the King of kings!
2. Then cleansed be every breast from sin; 
Make straight the way for God within; 
Prepare we in our hearts a home 
Where such a mighty Guest may come.
3. For Thou art our Salvation, Lord, 
Our Refuge, and our great Reward. 
Without Thy grace we waste away, 
Like flowers that wither and decay.
4. To heal the sick stretch out Thine hand, 
And bid the fallen sinner stand; 
Shine forth, and let Thy light restore 
Earth’s own true lovliness once more.
5. Stretch forth thine hand, to heal our sore, 
And make us rise to fall no more; 
Once more upon thy people shine, 
And fill the world with love divine.3
6. All praise, eternal Son, to Thee 
Whose advent sets Thy people free, 
Whom, with the Father, we adore, 
And Holy Ghost, forevermore.
—Charles Coffin, Jordanis oras prÃ¦via (1736), Translated from Latin to English by John Chandler, 1837
</blockquote>
]]></content:encoded>
</item>
<item>
<title>How I Do Code Reviews at Mozilla</title>
<link>http://benjamin.smedbergs.us/blog/2014-10-22/how-i-do-code-reviews-at-mozilla/</link>
<pubDate>Wed, 22 Oct 2014 16:00:41 +0000</pubDate>
<dc:creator><![CDATA[Benjamin Smedberg]]></dc:creator>
<category><![CDATA[Mozilla]]></category>
<category><![CDATA[review]]></category>
<guid isPermaLink="false">http://benjamin.smedbergs.us/blog/?p=978</guid>
<description><![CDATA[Since I received some good feedback about my prior post, How I Hire at Mozilla, I thought I’d try to continue this is a mini-series about how I do other things at Mozilla. Next up is code review. Even though I have found new module owners for some of the code I own, I still […]]]></description>
<content:encoded><![CDATA[Since I received some good feedback about my prior post, <a href="http://benjamin.smedbergs.us/blog/2014-10-02/how-i-hire-at-mozilla/" title="How I Hire at Mozilla">How I Hire at Mozilla</a>, I thought I’d try to continue this is a mini-series about how I do other things at Mozilla. Next up is code review. 
Even though I have found new <a href="https://wiki.mozilla.org/Modules">module owners</a> for some of the code I own, I still end up doing 8-12 review/feedback cycles per week. Reviews are only as good as the time you spend on them: I approach reviews in a fairly systematic way.
When I load a patch for review, I don’t read it top-to-bottom. I also try to avoid reading the bug report: a code change should be able to explain itself either directly in the code or in the code commit message which is part of the patch. If bugzilla comments are required to understand a patch, those comments should probably be part of the commit message itself. Instead, I try to understand the patch by unwrapping it from the big picture into the small details:
<h3>The Commit Message</h3>
<ul>
<li>Does the commit message describe accurately what the patch does?
<li>Am I the right person to make a decision about this change?
<li>Is this the right change to be making?
<li>Are there any external specifications for this change? This could include a UX design, or a DOM/HTML specification, or something else.
<li>Should there be an external specification for this change?
<li>Are there other experts who should be involved in this change? Does this change require a UX design/review, or a security, privacy, legal, localization, accessibility, or addon-compatibility review or notification?
</ul>
<h3>Read the Specification</h3>
If there is an external specification that this change should conform to, I will read it or the appropriate sections of it. In the following steps of the review, I try to relate the changes to the specification.
<h3>Documentation</h3>
If there is <a href="https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/index.html">in-tree documentation</a> for a feature, it should be kept up to date by patches. Some changes, such as <a href="https://wiki.mozilla.org/Firefox/Data_Collection">Firefox data collection</a>, must be documented. I encourage anyone writing Mozilla-specific features and APIs to document them primarily with in-tree docs, and not on developer.mozilla.org. In-tree docs are much more likely to remain correct and be updated over time.
<h3>API Review</h3>
APIs define the interaction between units of Mozilla code. A well-designed API that strikes the right balance between simplicity and power is a key component of software engineering.
In Mozilla code, APIs can come in many forms: IDL, IPDL, .webidl, C++ headers, XBL bindings, and JS can all contain APIs. Sometimes even C++ files can contain an API; for example Mozilla has an mostly-unfortunate pattern of using the global observer service as an API surface between disconnected code.
In the first pass I try to avoid reviewing the implementation of an API. I’m focused on the API itself and its associated doccomments. The design of the system and the interaction between systems should be clear from the API docs. Error handling should be clear. If it’s not perfectly obvious, the threading, asynchronous behavior, or other state-machine aspects of an API should be carefully documented.
During this phase, it is often necessary to read the surrounding code to understand the system. None of our existing tools are very good at this, so I often have several MXR tabs open while reading a patch. Hopefully future review-board integration will make this better!
<h3>Brainstorm Design Issues</h3>
In my experience, the design review is the hardest phase of a review, the part which requires the most experience and creativity, and provides the most value.
<ul>
<li>How will this change interact with other code in the tree?
<li>Are there edge cases or failure cases that need to be addressed in the design?
<li>Is it likely that this change will affect performance or security in unexpected ways?
</ul>
<h3>Testing Review</h3>
I try to review the tests before I review the implementation.
<ul>
<li>Are there automated unit tests?
<li>Are there automated performance tests?
<li>Is there appropriate telemetry/field measurement, especially for error conditions?
<li>Do the tests cover the specification, if there is one?
<li>Do the tests cover error conditions?
<li>Do the tests strike the right balance between “unit” testing of small pieces of code versus “integration” tests that ensure a feature works properly end-to-end?
</ul>
<h3>Code Review</h3>
The code review is the least interesting part of the review. At this point I’m going through the patch line by line.
<ul>
<li>Make sure that the code uses <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style">standard Mozilla coding style</a>. I really desperately want somebody to automated lots of this as part of the patch-submission process. It’s tedious both for me and for the patch author if there are style issues that delay a patch and require another review cycle.
<li>Make sure that the number of comments is appropriate for the code in question. New coders/contributors sometimes have a tendency to over-comment things that are obvious just by reading the code. Experienced contributors sometimes make assumptions that are correct based on experience but should be called out more explicitly in the code.
<li>Look for appropriate assertions. Assertions are a great form of documentation and runtime checking.
<li>Look for appropriate logging. In Mozilla we tend to under-log, and I’d like to push especially new code toward more aggressive logging.
<li>Mostly this is scanning the implementation. If there is complexity (such as threading!), I’ll have to slow down a lot and make sure that each access and state change is properly synchronized.
</ul>
<h3>Re-read the Specification</h3>
If there is a specification, I’ll briefly re-read it to make sure that it was covered by the code I just finished reading.
<h3>Mechanics</h3>
Currently, I primarily do reviews in the bugzilla “edit” interface, with the “edit attachment as comment” option. Splinter is confusing and useless to me, and review-board doesn’t seem to be ready for prime-time.
For long or complex reviews, I will sometimes copy and quote the patch in emacs and paste or attach it to bugzilla when I’m finished.
In some cases I will cut off a review after one of the earlier phases: if I have questions about the general approach, the design, or the API surface, I will often try to clarify those questions before proceeding with the rest of the review.
There’s an interesting <a href="https://groups.google.com/forum/#!topic/mozilla.dev.planning/whMYnn64UaY">thread in mozilla.dev.planning</a> about whether it is discouraging to new contributors to mark “review-” on a patch, and whether there are less-painful ways of indicating that a patch needs work without making them feel discouraged. My current practice is to mark r- in all cases where a patch needs to be revised, but to thank contributors for their effort so that they are still appreciated and to be as specific as possible about required changes while avoiding any words that could be perceived as an insult.
If I haven’t worked with a coder (paid or volunteer) in the past, I will typically always ask them to submit an updated patch with any changes for re-review. This allows me to make sure that the changes were completed properly and didn’t introduce any new problems. After I gain some experience, I will often trust people to make necessary changes and simply mark “r+ with review comments fixed”.
]]></content:encoded>
</item>
</channel>
</rss>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):

<a href="http://www.feedvalidator.org/check.cgi?url=http%3A//benjamin.smedbergs.us/blog/feed/"><img src="valid-rss-rogers.png" alt="[Valid RSS]" title="Validate my RSS feed" /></a>

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=http%3A//benjamin.smedbergs.us/blog/feed/

Home · About · News · Docs · Terms