Continuous Integration

Release Schedule

May 2020
S M T W T F S
« Nov    
 12
3456789
10111213141516
17181920212223
24252627282930
31  

Branches

Twitter

© 2020 The Sober Build Engineer | Simply ship. Every time.

Simply ship. Every time.

Introducing QuickRelease

07/14/2011

Writing, they say, is never done, it’s just due; as it is with software.

I’m happy to announce a project I’ve been working on for some time now: QuickRelease.

QuickRelease is a lightweight harness1 with a focus on automating build and release-related activities.


Searching Google Images for “quick release”
returns some… interesting results…

It’s designed to fit snuggly into your build and release process, between the existing build system-proper2 and the continuous integration system3, freeing you from being tied to a particular continuous integration system, but also allowing you to define processes (release processes, especially) that don’t belong in the build system and don’t make any sense to put in the continuous integration system. It also supports “unit tested” processes, which aren’t the main focus of build or continuous integration systems.

Pros

  • This is a production-level project: it’s being used by projects and companies to build and ship their software today.
  • And they’re doing this on all the major platforms: Linux, Mac, and Windows.
  • Extremely lightweight. By design. The only dependency is Python 2.x4
  • Designed to provide a framework to help guide the design of and clearly describe build/release processes and steps, but places very few restrictions on the build engineer; steps are implemented in pure-Python; few assumptions are made once execution is handed off to those classes5.
  • Prompts the design of “unit-testable” processes… but doesn’t force it (see above principle).
  • Promotes common build/release-related concepts—deliverables, for instance—to first-class, manipulable objects
  • Supports both re-running and re-verification of defined processes.

Cons

  • None; it’s totally wonderful!
  • Ok, ok, there is a TODO list in the README
  • And a few open issues6…
  • Like many software projects, it could use more documentation. A lot more documentation. For now, there are some examples to look at.

cvs co

You can get the source code directly from github.

(It turns out they have a spiffy download link for the last release, too.)

And there’s a Google group for discussion and help.

If, like me, you spend your days designing release processes, take a few moments, check it out, and join the dev group and let us know what you think!

_______________
1 Quick release harness… get it?
2 Makefiles, build.xml, etc.
3 buildbot, Bamboo, Hudson
4 We don’t have time to spend installing twister-this and zorp-interface-that on entire build-farm; we figured you didn’t either…
5 No “got unexpected keyword argument(s)”-garbage
6 Feel free to file more!

Honesty’s Net Worth

07/06/2011

I recently told a friend of mine I had discovered James Altucher.

He said “Oh, he’s a great read! I love reading his stuff. He’s totally crazy.”

At the time, I didn’t understand. But after reading more of Altucher’s work, I realized what he was referring to: Altucher’s frankness1.

As I’ve continued to enjoy his work, including his new book, a question started to burn in my mind, growing with each post and chapter.

Today’s Altucher-post answered it: Do You Have To Be Rich To Be Honest?

It’s a great read. You should go read it.

Right. Now.

***

I had been struggling with exactly this question for some time.

I learned The Hard WayTM that so-called open door policies may not, in fact, actually be about the open and honest communication of ideas.

As a bright-eyed, bushy-tailed build engineer2, I made the mistake of taking that particular managerial concept at face value and assumed that “Please post your feedback” actually meant “We want to know what everyone is thinking” not “Everyone needs to submit their agreement in writing, so it can be later referenced, in case there is any dissent.”

And so, like a dumbass, I gave my opinion. My full and honest opinion. Sincere, too. On any issue that was asked.

I assumed that’s what they wanted; they asked for it, after all.

Right?

Of course, since that’s not what the exercise was about, that failed.

In an ill-fated attempt to “fix” it, I tried espousing the official line.

That, too, failed: as Altucher points out, people can totally tell when you’re doing that. (It turns out: both the people telling you to repeat what they’ve said, and the people listening.)

That lesson really stung.

It was probably exacerbated by the fact that I didn’t get the right take away at the time; Altucher explained today what it actually is:

If you are going to lose a job by being more honest, should you stay in that job? My guess is you’ll be a lot happier in another job. Will you lose your girlfriend if you tell her the truth? My guess is you probably would be happier with someone different if she really would leave you upon hearing the truth. Or maybe you honestly don’t know her (or him) as well as you think you do.

He’s spot on, but like so many of his posts, I think what he’s really saying is “You need to have faith.” In this case, faith in the idea that being honest to yourself and to those around you will, over the long term, work out for the better3.

Having faith is really hard work4. Whenever Altucher discusses it, he never for a moment implies that it isn’t arduous and difficult.

But then… I guess so is lying constantly5.

_______________
1 Which, if his frankness is any indication of how he lives his life, leads—predictably—to crazy stories
2 Are build engineers ever bright-eyed or bushy-tailed?
3 Probably for everyone
4 A lesson I’ve only recently begun exploring
5 Or telling everyone “Yes sir, your idea is perfect; thank you sir.”

Considering Crucial Criticisms

07/01/2011

My communication was supposedly so poor,
it necessitated “gifting” me this book…

One of the worst mistakes I have ever made was letting my manager-at-the-time convince me I was a poor communicator.

Quality communication is hard, certainly1, and we could all be better at it.

But I’d been in the workforce for some time at this point, and my communication skills had never been criticized before2.

At first, I found it a little surprising, but… maybe he was right? He even gave me a book, claiming that he’d given it to many people, and it had helped them with their poor communication skills.

Not wanting to rock the boat—I had only recently started reporting to him—I decided to really examine this whole “You say stuff that sense doesn’t make”-criticism I was receiving3: I really tried to pay attention what I said and how I said it.

I proofread things three or four times4. I rehearsed conversations in my head endlessly, right up to the point before they were to take place. I read about these “crucial conversations” I was having, how I was clearly and obviously (I was told) screwing them up, and how I could fix it.

I didn’t end up working with him very long: it turns out you can’t really work with someone you can’t communicate with.


This individual, on the other hand, may indeed have…
an “issue” with his workplace communication skills.

I spent a ton of time reflecting on how I could have done better. I reviewed so many interactions in my head, they all started to blur together. But no matter what, my lacking communication skills were to blame, right?

Obviously.

After letting it simmer for a few months, I came to an interesting conclusion: he was totally, utterly, and completely wrong.

I was able to facilitate this conclusion, in part, because over ensuing months, I’d heard story after story from others about how every single conversation with this critic-of-mine was “like a teeth-pulling trip to the dentist.”5

The only thing more surprising than the number of confirmations of these experiences was the viscerally painful descriptions: dragging meetings off point, taking thirty minutes to say something that could have been said in two, or just plain not grokking the words that were coming out of people’s mouths.

It was a real wakeup call for me.

***

Clearly, not all criticism is bad.

But when someone feels it’s their place to criticize something so fundamental to who and what you are as your ability to string words into a coherent sentence or your style of putting words on a page6, that authority had better be derived from something more than the workplace-equivalent of a military dictator overthrowing some small South American country.

And when someone does give you “constructive criticism” or “helpful feedback” or downright orders you to change and shows you the proverbial stick they’ll beat you with until you do, that advice had better pass your personal smell test before you take it to heart.

If it doesn’t, beware. Only if you’re lucky, like I was, do you eventually realize that smell is your soul rotting.

Ignore that acrid odor at your own peril.

_______________
1 A good one-and-a-half serious relationships of mine have fallen apart over that very issue…
2 I’d been told I could be a bit… abrasive when I was first out of college, but… that’s style, not content
3 Repeatedly, pretty much every single day; this shortly becomes relevant to our story
4 Mostly for content and tone
5 Not my words
6 Or screen

Rapid Release Redux

06/29/2011

I had commented on Mozilla’s new “rapid release process” before the PR storm, but it in tweet form, so I figured I’d expound on it a bit.

A lot of the focus has been on Dave Winer’s post (and his followup). His post has been tarred as “incomprehensible” by some1.

I tweeted a (humorously-intended) translation of his post, which Asa quickly rebuked, so let me clarify:

The root of this issue is this fundamental disconnect: Mozilla sees Firefox as a “lever” to “move the Web“: JS as the computer lingua franca, WebGL, plugin-less audio/video playback, and native audio/video recording2 are all initiatives they think are important, and they see Firefox as the vehicle to make3 those things happen.

Some of their users agree with them.

But a lot of users do not.

Those users, like Dave Winer, think the browser4 is feature complete5: they can do everything they need or want to do online and they’re generally happy with the product.

So when Mozilla forces these new features on their users’ daily browser experience, and especially when those users can’t perceive a benefit6, making them pawns in the browser wars, they become—reasonably, I might add—annoyed. They just wanted to read their email with AdBlock. Or play Farmville.

Twice now—first with Out Of Process Plugins7 and secondly with Firefox 4′s EOL proclamation—Mozilla made sweeping changes Firefox users weren’t prepared for, didn’t expect, and most importantly in this discussion, affected their daily usage and interaction with the Web in a negative way8.

Coverage of this issue has been framed as a “corporate support” argument (which Mozilla claims it never really cared about) or vilifying users who are comfortable with the functionality and stability of their older browser9.

But these are proxies for and distractions from the actual issue: Mozilla Corporation decided to change the way it had released Firefox since… well Firefox was conceived. It did so without doing an adequate job of informing users10, without seeking buy-in from users, and without giving them the option to do anything else.

To be fair, Mozilla is in a tough position: Microsoft provides “enterprise support” for its older (but still-modern-for-some-values-of-modern) browsers and a more predictable (if longer) support schedule because that’s what its customers—who pay them a lot of money—expect. And Google doesn’t provide any promises about Chrome’s releases or schedules (and, in fact, does a pretty good job of keeping users in the dark about what version they’re using), but the extension ecosystem on Chrome is still pretty nascent, so breaking extensions (if that even happens) doesn’t seem to be as big a deal to their user base.

The thing that hamstrings Mozilla is extensions are a core part of the Firefox experience, but it’s difficult to corral hundreds11 of extension developers together every three months to get their extensions updated12. And when you have promoted and built your core base out of users who rely on extensions, that becomes difficult to manage successfully13,14.

Unfortunately, the loser here is the end-user: their personal user experience with Firefox is degraded, they’re frustrated, all they hear from Mozilla Corporation is a canned-soundbyte about how wrong they are and how they’re holding a gun to the Web’s head. That’s not even in the ball park of any response that would be productive15, so in turn, those users lose faith in Firefox. And its stewards.

To be clear—I fully expect this detail to be ignored/forgotten—I’m not making any comment on whether “rapid release” is good or bad, how it could/should be made better, or whether or should be abandoned altogether.

Those are good questions, and they’re apparently being discussed.

But that’s not really the issue.

The issue is the disconnect between Firefox users’ expectations of their beloved browser, which have been established through six years and as many16 major releases, and Mozilla Corporation’s use of Firefox as an instrument to push change.

The strategy of addressing user frustration by shouting over your users and blowing them off when all they wanted to do was use your product as they had been for the last seven years merely exacerbates the situation.

And Winer hits this nail on the head when he says “Mozilla doesn’t have a problem communicating, it has a problem listening.”

_______________
1 A statement for which no explanation has been given—I asked—and which sure sounds like an ad hominem attack to me!
2 And a not-entirely veiled desire to kill Flash completely
3 Force?
4 And maybe the Web?
5 I disagree with Winer on this
6 And may see it as a bloat-ifit
7 The “I updated to 3.6.4 and Flash stopped working”-debacle
8 This, based on both my own experience and anecdotes others have shared with me
9 As if they were holding a gun to the web’s head
10 As evidenced by the backlash
11 Thousands?
12 And this is exacerbated by the fact that even though there may not be a lot of code change, a major version number bump has historically been a complex process for extension developers
13 Mozilla Corporation’s Gavin Sharp tells me they did bump extension compatibility
14 Mozilla Corporation’s Paul Biggar tells me tells me this only affected a “small portion” of users, but when challenged to provide evidence for that claim with AMO data, everyone got really quiet
15 Much less a response which is user-oriented, something Mozilla Corporation says it strives for
16 Depending on how you count

Ever Onward [C.H.M.]!

06/20/2011

I went to the Computer History Museum this weekend, in part, to work on a mini-project.

Since it had been the first time I’d been there in probably over a year, I was excited to see what had changed.



Ever Onward I.B.M.!

I was totally blown away by the transformation.

My first couple of visits to the Museum made its roots quite obvious: housed in an old SGI building, the purple was pervasive, but that was about all that remained. They had exhibits… sort of. The actual “museum” consisted mostly of their “visible storage” room.

It basically looked like a warehouse of old junk—one of the exhibits was famously covered in bullet holes1—that someone had cut a path through. The layout was well-suited to illustrate the progression of computer history, from abacuses to today’s video game systems.

But even for a geek like me who was genuinely interested in artifacts like racks of vacuum tubes, the room really didn’t come alive unless you went on a docent-led tour. (It was totally a bonus that many of their docents were ex-employees of the various companies’ whose products were on display, and had many personal anecdotes that one would never hear in another museum2.)

But if you weren’t lucky enough to have that experience, it could get kind of… well… boring. The significance of all of the awesome artifacts they have wasn’t immediately palpable.

That has been totally addressed in the last year!

We got to the museum too late for a docent-led tour this visit. I had expected to be dumped in the warehouse-esque room again, and started trying to dig up from my memory what I had gleaned during my two earlier docent-led tours. But to my pleasant surprise, this visit started with an introductory video that not only did a great of setting the stage for what we were about to experience, but pleaded the case why the Computer History Museum as an institution is important.

We then walked into the exhibit hall, and I was utterly blown away.

This concept of the path through the history of computing remained, but that was about it. I recognized many of the exhibits from my previous tours, but they had been set on display, professionally lit, and had tons of placarded information surrounding them. I would have loved to have had a docent led tour, but the lack of one no longer translated to a difficult-to-impossible to digest set of artifacts and a disappointing visit.

While I was totally blown away by these positive changes, there were still a couple of things I hope the museum will address:

  • It always bothered me the discussion on IBM’s rise as a business omits the “minor detail” of their involvement in the Holocaust. None of the docent-led tours ever mentioned it, and I didn’t see a display that made reference to it… which is odd, since there were at least two displays discussing how wonderfully effective the “C-T-R machines” were at the United States census.

    To be fair, during IBM’s recent 100 year celebration, they “kinda forgot” about it in the review of their corporate history as well, so… the Computer History Museum is in… well… company…
  • Ditto any discussion of the environmental impact of early chip-makers’ activities; this is especially ironic given that most of the land surrounding the museum had long been superfund land, because Intel, IBM, and Fairchild Semiconductor dumped the industrial acids and heavy metal runoff in the Valley’s backyard for years.

I understand these topics are hard to address, especially since the museum gets a lot of donations from these companies3, but they’re a part of history and I can’t imagine a better institution to fairly tell those stories in the context of the history of computers and the Silicon Valley than the Computer History Museum.

With these recent changes that make the Computer History Museum feel “all grown up,” omitting difficult topics seems passe and detracts from the Museum’s (hard earned and well deserved) credibility.

Despite these minor areas for improvement I still consider the Computer History Museum a gem of Silicon Valley, and feel a personal connection to it that many feel to SFMOMA or the Academy of Sciences.

The Museum will remains one of my top recommendations for anyone visiting the Bay Area, but with these recent improvements that really bring the history of technology to life, being a hard core geek is no longer a prerequisite for admission to a fun, engaging time.

_______________
1 Someone’s son thought it looked useful for target practice
2 I really fear these will be lost to time; I would love to see the museum undertake a spoken history project to collect interviews with these individuals
3 Of both money and artifacts

p4 conference -o

06/11/2011

I started using Perforce in 2003, for my first post-collegiate job.

Coming from a CVS-centric world1 it was weird and confusing to me.

But as I used it, I began to really like its workflow and the tool’s conceptual consistency.

Fast forward eight years, and I’m using Perforce again3. I convinced the Powers That Be of the utility in sending our team to this year’s the Perforce Conference. I was very interested to see what had changed with Perforce in a market that’s seen surprising interest over that time.

The 2011 conference, “Roadmap to Innovation,” certainly fulfilled that desire. For me, I found the following stops on the highway most interesting:

  1. A new mantra of “Version Everything.” Putting everything in version control is old hat to configuration management engineers4. What’s interesting is that Perforce is making this a new cornerstone of both their product and their marketing message, thus reinventing themselves as a platform to do versioning.

    You can see this with their new Chronicle offering. It’s a great move. So many tools5 have weak versioning functionality that seems tacked on as an afterthought6, so to take a tool that has proven itself time and again to bring rich, mature versioning functionality to other markets is a great direction to see Perforce moving in.
  2. As soon as I heard about it, I tweeted “Perforce Streams + Sandbox is distributed version control that doesn’t bite developers.”

    I can’t count the number of times I’ve heard developers complaining their fancy DVCS of choice acted in a way they didn’t intend, destroying hours’7 worth of their work8. These two features feel like a culmination of Perforce stripping away the DVCS hype and looking at the features developers really use in those systems… and then building that, with Perforce’s famous attention to detail.

    Sandbox brings offline operations to the Perforce world; there were some good questions asked at the presentation, and there are some corner cases to still be worked out, but it brings the common workflows developers care about to Perforce, with a usage model they’re used to9.

    Streams, on the other hand, brings CM patterns many of us have been performing by hand—sparse branching and merge-down/copy-up branch patterns—to the P4V UI, and available directly to developers, so you don’t need to involve your overworked-build team.

    Frankly, I’d been worried about Perforce with respect to the movement around DVCS tools for awhile, but the combination of these features makes me confident not only that Perforce has an answer, but that it’s the right one.
  3. The diversity in attendees at the conference demonstrated Perforce continued flexibility in the configuration management space: the myriad use cases, environments, artifacts versioned, and installation sizes illustrate the ways in which Perforce performs well against all sorts of workloads, in all sorts of environments: everything from Google versioning its world to Pixar versioning its production assets to the NYSE versioning entire machine configurations10.

    And for every huge customer that we see presentations for11, there are hundreds of Perforce customers that have installations humming along every day with minimal administration and effort, and they perform wonderfully.

In short, the conference’s more than delivered on a “Roadmap to Innovation.” As someone who’s watched the Perforce ecosystem grow since 2003, I’m very pleased to see it’s thriving today.

I’m already looking forward to next year’s conference, if only to remind Michael Shields that we have a bet… a friendly, fun side effect of one-too-many p4 obliterates…

_______________
1 Unlike many college students, I’d been using source control for all of my school projects2
2 This, after an incident where I came home smashed from a party and thought that was a perfect time to “finish up” a mostly-working project
3 This detail was, in fact, one of the reasons I looked forward to starting at SYMC
4 Today’s developers mostly seem to be on board that train too
5 Wikis especially
6 The lack of annotate ability in modern wikis is both amazing and rage-inducing…
7 Sometimes days’
8 The fact that they often continue to blindly espouse these tools has prompted me to call them “The Ike Turner of version control systems
9 No more git resets eating code
10 SEC audits are, apparently, how do you say… “a bitch”
11 Google, famously, has its repository still on one server

“And off our left wing, the Grand Canyon!”

06/04/2011

Has it really been over three months since I said I’d provide “more information for y’all when we reach our cruising altitude…”

Time, it does fly.

Astute stalkers observers may have noticed my LinkedIn profile a few weeks ago: I’m now a Principal Release Engineer in Symantec’s Data Loss Prevention division.1

It may seem like a large shift for someone coming from a sub-20 person startup or an environment like Mozilla, both of whom are focused on short release-cycle, consumer software products. And in some ways, it is a huge change: DLP is very much an “enterprisey product” with the associated long release cycles (and even longer support cycles).

What I’ve found really interesting as I’ve come up to speed is how my new team has been moving itself toward a “lean,” agile organization, just like Songbird is and Mozilla is becoming. The requirements, size, and final products are very different, but the path all three take to ship have striking similarities.

It’s also been nice to step back into designing solutions for enterprise release engineering requirements; it was often a hard sell to get resourcing for certain aspects when “the next big release” was two or three months away. But when you have to support a version for three or four years, those conversations tend to go much more quickly. It reminds me a lot of life back in my VMware days, which perhaps also has to do with the fact that I’m on a release team again, which is something I didn’t realize how much I missed and am ecstatic about2. Plus, I get to use Perforce again3.

Of course, as with anything change, there’s been some amount of “Y U NO WORK?!“, but the change in technology stacks—an interesting mix of native C++ on multiple platforms and multi-platform Java-based server components4—has me looking at new things that I haven’t worked with since college. In software, a change of scenery is pretty much always a good thing.

DLP is one of those technologies that churns away quietly in the background, keeping credit card numbers and mothers’ maiden names safe. It does so day in, day out, 24 hours a day, 7 days a week, 365 days a year. It’s not the sexiest of technologies and you can’t script it with Coffeescript. Most people aren’t even aware it exists, but they’d feel the effects if it didn’t.

Not unlike, perhaps ironically, good release engineering teams, infrastructure, and processes.

_______________
1 Some may also know this division by its pre-acquisition name, “Vontu”
2 Someone whose job it is to also know how to run an official build?! YES PLZ!
3 Which, despite what certain ex-VMware coworkers think, I really did miss
4 Amusingly, I saw a copy of the Gecko SDK kicking around in the source tree the other day…

Getting Back On Message

05/31/2011

In another life, I would’ve been a journalist.


It’s unclear which is more tragic here:
the column’s title… or my hairstyle.

During my junior and senior high school years, I wrote a column, published weekly in the local newspaper, on issues teenagers face in a standard, mid-sized western town.

In retrospect, the writing wasn’t great: my point often got buried in loquacious verbiage. But one of my mentors said years later “it was an important perspective that was not being covered… and it needed to be.”

The thing that always surprised me the most was how… emotional people could get about a particular article: reactions ranged from letters to the editor1 to veiled threats on during the school announcements. One article even resulted in the student body president beating me up.

***

I don’t remember how exactly2, but I found James Altucher’s blog3.

While clicking around, I came across his 33 Unusual Tips for Being a Better Writer. I forwarded it to a couple of friends who can actually claim writing as their career5.

It took a couple of weeks of pondering-on-the-back-burner to figure out why this particular post struck such a chord: Altucher had reminded me, in a very visceral way, of a couple things I’d forgotten… things that you need to remember if you want to write.

***

I can’t even tell you how many conversations I’ve had with friends that start with “I should really blog about…” and end with them saying “Oh, man; you can’t write that!”

In some sense, they’re probably right, but that sentiment never sat well with me.

I understand the genesis of the concern: in the last decade, we’ve seen unprecedented media consolidation, narrowing the field of idea expression. Combine this with the recent development of the idea that controlling the context of a conversation is almost more important than controlling its substance6,7, and you have an environment that’s ripe to breed the idea that certain topics and questions are just “off limits”: you don’t remark upon the emperor’s tailor and you never ask God what he needs with a starship.

Online, areas that were considered a community’s public commons are turned into feeds of similarly verbiaged and vetted content about the same projects.

Getting “off message” by introducing doubting questions is not acceptable.

***

The reason Altucher’s post on writing struck such a chord with me is because it pointed out the trap I had fallen into:

For each single person you worry about, deduct 1% in quality from your writing. Everyone has deductions. I have to deduct about 10% right off the top. Maybe there’s 10 people I’m worried about. Some of them are evil people. Some of them are people I just don’t want to offend.

It had gotten so bad at one point that I actually asked managerial permission to post something on my own blog. That’s how much intellectual honesty I was prepared to throw away.

The irony of being in that hole is when you feel like you have to ask permission to be honest, all in the name of joining The Message of the particular RSS cycle, you’ve already lost: that you even had to ask proves that you’re not really a part of that particular community8, and immaterial of a grant of approval, there is no way to get back the integrity you just forfeited.

Realizing that is one of the best things a writer can do… and if Altucher is right, has an added bonus of instantly-better-writing9.

Besides, even the most benevolent of dictators and gods need to be asked about shoes and starships from time to time.

_______________
1 Both complimentary and critical
2 Probably Twitter?
3 You could spend hours reading all of his cross-linked posts4
4 I know, because I (accidentally) have
5 They both liked it, except the tea drinker disputed James’ coffee claims…
6 Frank Luntz has done some fascinating work in this area
7 “Death panels” anyone?
8 Or what it’s turning into
9 Or he’ll refund all your money!

“Cleared the OFFSHORE FIVE departure; Birder transition; then as filed”

02/23/2011

Last Friday was my last day at Songbird1.


The San Francisco OFFSHORE FIVE Departure,
a common departure for birds flyin’ south…

I meant to get this written earlier, but the last few weeks have been insanely busy, trying to get all the loose ends tied up to make sure things keep humming along.

It is not an understatement to say that my experiences at Songbird over the past three years have been among the best in my career to date. It was both a privilege and a pleasure to work with such talented coworkers, across the entire spectrum of the organization.

For me, Songbird represents a collection of firsts that will be etched into my memory: my first real startup; my first experience with the the myriad ups and downs that go with a true Silicon Valley startup; my first experience with sitting around with my coworkers, talking about where the company could go… and should go; my first experience with an agile software development organization.

Songbird was also the first place where I really saw the non-core engineering teams, like QA and release engineering, integrated into the software development process, not “tacked on” as an afterthought or assumed to be an impedance to shipping software. And Songbird was the first job where I found myself, quite by surprise actually, tearing up3 on the closing moments of my last day.

I’ve been working with the Mozilla technology stack for going on five years4 now. While it’s a great stack5, it’s time to work on something new.

I’m not falling off the planet entirely; I’ll be around on IRC6 and in (both Songbird and Mozilla’s) Bugzilla, shuffling a few last patches around and generally cleaning up any bird poop I left.

And as they say: “I’ll have more information for y’all when we reach our cruising altitude…”

_______________
1 Or, depending on who you ask, Pioneers of the Inevitable2
2 I always did think that was a clever name…
3 Ok, ok… crying
4 Depending on how you do the math; it could be as high as 13 years…
5 Especially if you’re building web browsers
6 Hi #foxymonkies!

Last Minute Wikileaks Present

12/24/2010

Looks like the Wikileaks isn’t taking the holidays off, and has released one more secret document from the United States government, just in time for Christmas.

Unlike the previously released diplomatic cables, this document was released without much fanfare or press attention.

While it’s understandable that the government wouldn’t want to publish this information1, this document provides fascinating insight into holiday operations of the National Airspace System and of one pilot in particular; it’s too important to be kept secret in a free society:

Unlike the other leaked documents, mostly diplomatic cables, this document appears to concern a Federal Aviation Administration Defense VFR flight plan.

The pilot of november five-alpha-november-tango-four apparently files this flight plan with the agency every year on or about December 24th.

While this is the first document we’ve seen with this level of detail, this is far from the first time the government has hinted that it is working with Santa: see the NORAD Santa Tracker and the FAA-charted North Pole NDB or GPS-A approach plate.

Let us hope, for the pilot’s sake, that he isn’t subjected to the TSA’s “increased security measures” when embarking on his first stop.

For those celebrating Christmas tonight, Merry2 Christmas, from me to you.

And, of course, happy holidays to all!

_______________
1 Especially since the terror threat-level is currently something like polkadotted puce
2 Please use this regex if it’s relevant to you

Newer Posts
Older Posts