This workweek was rather uneventful. I just worked very hard on pushing my project forward.

On Wednesday, I got a ride home by a colleague (travel time of 10 minutes instead of ±55…). He gave me a ride home before. This time he brought his other car.
A casual Porsche.

So I mentioned the commute to and from Facebook by public transport. I used to take the bus¹. It averages 55 minutes (doorstep to doorstep, so including walking).
Ever since moving in to my suite, now two weeks ago, I’d been taking the bus. That’s about 2 hours per day. Gone.
I hate wasting time. I hate it when a site takes 200 milliseconds longer to load than it should. Needless to say, I really hated this massive waste of time.

On the Tuesday of the second week, I started feeling very much at home here in the sunny Silicon Valley.

Not because the mobile phone reception is so poor here and because that reminds me of my parents’ place, which is probably the only spot in a wide area where you’re guaranteed to lose reception when you drive by.
The reception is very poor here though, apparently especially on AT&T’s network, with calls being dropped very frequently — I saw it happen three times with my own eyes.
That’s right, you peeps in Belgium envying me because I’m in Silicon Valley. It turns out that in Silicon Valley of all places, mobile reception is worse than in Belgium! (Although, when it works, mobile internet is much faster here.)

I failed to mention this in the blog post about my first week here, but at the Zen Hotel, I’ve also had the worst Wi-Fi access ever.

And more than once, my Skype video calls to my girlfriend back home from within the Facebook offices have been dropped. Call quality is generally pretty poor. ¹

Orientation at Facebook

While I obviously can’t publish the details here, the orientation was very cool. The guy who was doing orientation was very energetic and enthusiastic, and this definitely had a positive effect. He explained how the company functions (flatness for the win!), the rationale behind some of its core technologies and products.

What’s also very amazing, is that he’d only been there for 4 months!
In fact, as you talk to more and more Facebook employees, you’ll learn that most of them have actually joined in the past year or so. It’s amazing. It’s also very strange if you’re not used to the start-up culture and the optimistic atmosphere that’s seemingly inherent to Silicon Valley.

In the afternoon, we got our laptops (either MacBook Pros or Lenovo Thinkpads) and phones (iPhones, although you can request an Android device later on). Quite impressive, seeing dozens of new devices lined up in rows and waiting to be used productively.

After the orientation was wrapped up (which included a tour of the headquarters), there was a Happy Hour (i.e. beer), which I skipped to go and meet my manager, Okay Zed, and the rest of the Site Speed team.

Saying goodbye

I didn’t expect the goodbye to be easy, but I never expected it to be so hard, either. I think it was one of the hardest things I ever did, on that 23rd of September, 2011.

I was going to miss my friends and family back home, but that’s absolutely nothing in comparison with the goodbye to Anneleen (my girlfriend — she’s awesome!). It was very hard. We barely managed. I wish I could’ve taken her with me. The only way we managed was by telling ourselves that it’s too big an (career) opportunity to pass on, and that the experience I’d gain at Facebook would help my career and thus us for the rest of our lives.

The flight

Facebook booked the flight with British Airways. I’m used to flying with lowcost airlines such as Ryan Air, Brussels Airlines, and so on; so I expect to have to pay for everything.

Well, that simply doesn’t apply to British Airways. The flight booked for me by Facebook’s travel agent to London was in Economy class, but the one to San Francisco was in “Club World class”¹. More about that later.

Jacob Singh did a presentation at DrupalCon London about “How to have an open relationship … with software (and still make paper)”. I’m one of the people he interviewed for his presentation.

One of the questions he asked, was this one:

How do you use version control, spreadsheets, text files, napkins, etc to track your customizations to Drupal modules and core? Until the DOG project is done, what is the best worst practice here? On the Gardens team for instance, we used a PATCHES.txt file which listed the date, author, description and link for every patch to core or contrib. low tech, somewhat functional. How do you do this?

He liked my answer so much that he told me I should write a blog post about it — even if I’d just copy my answer verbatim. I’d been wanting to do that for years now. “Better late than never”, right? Although it’s actually too late now, because this system was actually designed to work when Drupal’s code still lived at http://cvs.drupal.org…

On July 1, 2011, I successfully defended my master thesis at Hasselt University’s Expertise Centre for Digital Media. As usual, it’s very hard to compress the entire spectrum of interesting things to explain in the small allowed period of time that we’re allotted (15 minutes this time). I spent a lot of time polishing my presentation to make sure it was as understandable as possible (despite the fast talking pace), but also as interesting as possible. And apparently it paid off!

Afterwards, I received a lot of very positive feedback my presentation from those attending the defense presentation. Fortunately, the content itself was also deemed interesting and solid: I received a score of 80% (16/20)! I’m of course very satisfied with this result :)

However, it doesn’t end here…

Update August 16, 21:30 CET

Now that Steve Souders tweeted about this, I think it’s necessary to link from this post to important related information:

The last blog post I wrote about my master thesis was on June 1st. The final blog post has been long overdue. To the (very few) readers interested in the technical details, I apologize for the long delay in writing about the last part.
That last blog post was about FP-Growth. This one is about FP-Stream. Whereas FP-Growth can analyze static data sets for patterns, FP-Stream is capable of finding patterns over data streams. FP-Stream relies on the FP-Growth for significant parts, but it’s considerably more advanced. So, in essence, this phase only adds the capability to mine over a stream of data. While that may sound like it is not much, the added complexity of achieving this turns it into a fairly large undertaking.

The previous blog post covering my master thesis was about the libraries I wrote for detecting browsers and locations: QBrowsCap and QGeoIP.
On the very day that was published, I reached the first implementation milestone, which implied that it was already finding causes of slow page loads, but not over exactly specified periods of time, but rather over each chunk of 4,000 lines that was read from an Episodes log file. To achieve this, an implementation of the FP-Growth algorithm was completed, which was then modified to add support for item constraints.

FP-Growth {#FP-Growth}

Thoroughly explaining the FP-Growth algorithm would lead us too far. Hence, I’ll include a brief explanation below. For details, I refer to the original paper, “Mining frequent patterns without candidate generation” by J. Han, J. Pei, Y. Yin and R. Mao which can easily be downloaded when searched for through Google Scholar.

I’m thrilled to announce that I’ll be joining Facebook’s Site Speed team in Palo Alto, California on September 26, 2011 for a 12-week internship!

After almost two months of being in contact with Facebook, I finally got the liberating call with the verdict yesterday evening: I’ve been accepted!

Backstory {#backstory}

For those of you who want to read it, here’s the full backstory.

Excitement {#excitement}

On February 24, I was contacted via the contact form on my website by Jason Sobel of Facebook. He’s a member of the Site Speed team and mentioned their article about BigPipe (which is the technology they developed to make Facebook load twice as fast). Apparently he had come across my master thesis and my website (i.e. this website) and was interested in my work on making websites faster. Jason asked if I was up for a chat some time to find out what I’ve been working on and so he could give a sense of what the Facebook Site Speed team does. There even was a mention of possibly joining Facebook: “maybe our team would be an interesting opportunity for you?”.

In December and January, I’ve continued working on my master thesis, while simultaneously preparing for my exams in January (which I passed without problems).
In a previous blog post, I had indicated that I ran into problems while parsing dates: Qt uses the system locale for this, but on Mac OS X there turned out to be a severe performance problem with that functionality. I solved that by developing QCachingLocale, which is a class that introduces a caching layer to prevent said performance degradations.

Further parsing {#further-parsing}

Now, parsing the date was of course only one tiny part of the problem: I also had to parse the episodes information embedded in each Episodes log file line (which is trivial), as well as map the IP address to a physical location and an ISP and map the user-agent string to a platform and actual browser.
Finally, we also want to map the episode duration to either duration:slow, duration:acceptable or duration:fast. This is called ‘discretization’: continuous values (in our case: durations) are mapped to discrete values.