Andrei Zmievski

I have not yet been to South by Southwest festivals. And every time I mention this to friends and colleagues, they make big eyes and say, “You have to go!”. Well, I finally cracked and submitted a panel proposal for the 2010 SXSW Interactive portion. The panel is titled “Travelog with Maps: When 1,000 Photos Aren’t Enough” and will present and discuss ways to preserve the memories and tell the stories of your trips using latest geolocation tools, social data, and a bit of code. Chris Shiflett will be my co-panelist. We decided to do this panel after trying to share our Iceland trip in real-time and discovering what is and isn’t there to support it.
If you like this idea, please vote for this panel. Thank you!

I will be leaving Digg at the end of this month.

The launching point for this decision was my visit in June to Iceland, where I had many opportunities in sublime surrounds to reflect on my life and aspirations. Standing on top of the world  at Sjónarsker, I realized that though my career has spanned some great companies, the next step in my professional life would have to involve building something of my own. Later on, watching a never-ending sunset from the hill at Stykkishólmur, I understood that this something has to happen sooner than later, and serendipitously, an opportunity to do just that has arisen recently. My friend Chris Shiflett, who visited Iceland with me, has similar aspirations and likes to say “good work, good people”, and that is definitely what I intend to do.

Thank you, Joe Stump, for recruiting me. My 8 months at Digg flew by quickly, but the friendships I made there will last for a lifetime, I hope. I have been privileged to work with and next to some of  the best and brightest people that I have met in my life. There is a great road ahead for Diggers as the company advances to stay on the cutting edge of the social news industry. I am sad to be leaving when some very cool developments are afoot, but excited for my own road ahead. By the way, Wine Wednesdays were the best.

I am planning to do a bit of traveling at the end of August and then start September afresh. There is plenty to be done to bring these ideas to life and I cannot wait to share the news when the time is right. Oh, and I’m still going to be involved in PHP, perhaps even more than usual.

Reset. Restart. Renew.

And, seriously, visit Iceland if you have a chance. It is another world.

What happened to gravitonic.com?
For a very long time, I’ve been downplaying my last name, deeming it too hard to pronounce or type for the majority of people out there. Well, no more. I am bringing it back and using it as part of my online identity. Gravitonic.com has served me well over the past 10 years, but from now on, my main domain will be zmievski.org. All the links to the old domain will silently redirect to the new one, so nothing should be broken. If you see that it is, please let me know.

This morning I released the first stable version (1.0.0) of the PHP memcached extension that I started soon after joining Digg. It’s been stable for a while actually, but some people were hesitant to use it in production while it still had the beta designation. Well, no more, go forth and use it.
As the underlying libmemcached library evolves, I plan to keep adding and exposing more features in the extension. Up next are probably memcached_dump() and server auto-ejection support.

Taking advantage of php|tek bringing a lot of people together, we had a PHP developers meeting over 2 days before the conference. Day 1 was dedicated to technical issues in PHP 5 and 6, and day 2 was spent discussing potential features, migration issues, current roadblocks, etc.
The notes from the meeting are available on the wiki. These notes are not necessarily “decisions”, but they do reflect the consensus of the group that was at the meeting and hopefully present a more structured and outlined list of things that we can follow for PHP 5.4/6.

May has come and gone and for me almost half of it was spent on the road. SFO-DEN-BNA, BNA-ORD, ORD-ZRH-TXL-ZRH-ORD, ORD-SFO. To decipher that for you, I first went to Nashville to visit my friend Raquel and see the land of the honky tonks. I was surprised to find an almost full-sized replica of Parthenon there, as well as a really great ƒood/drink scene. Some highlights include Prince’s Hot Chicken Shack (I dare you to order something more than medium hotness), a great beer place called The Flying Saucer (150+ beers on the menu), and especially The Patterson House (recommended by the awesome Steph Dub), where we spent a few hours snacking on tasty bits from the menu and drinking the awesome cocktails that the bartender mixologists prepared in front of us.
Then it was off to Chicago for php|tek 2009 conference. The first two days were dedicated to the first real PHP developers meet-up since November 2005. On Monday we discussed technical issues with regard to PHP 5.3 and 6, and on Tuesday the topic shifted more towards potential features aside from Unicode to entice people to move to 6 and how to ease this migration. Overall it was a productive meeting and the notes should be posted soon. The next day I gave the opening keynote on the present and future of PHP. I managed to throw in a few inside jokes and funny photos in there to lighten up the morning mood. The rest of the conference was productive as well—there were great talks on everything from utilizing HTTP status codes to multi-level caching to a talk that Cal gave on telecommuting. After the conference hours we stopped by the Map Room a couple times for some excellent beer flights (La Folie on tap, OMG).
 

After Chicago, I flew to Berlin for the International PHP Conference Spring Edition 2009. This year they accepted all 3 of my proposals, so I had my work cut out for me. Miraculously, I managed to make the German audience smile and even laugh a couple of times during my keynote. Success! The other two talks intl me this, intl me that on localizing and translating your pages, and All the Little Pieces on using PHP with memcached, mogilefs, and Gearman went well too. Funny enough, the RailsWay conference was going on at the same place—didn’t they know that Terry Chay is coming to town?! This was my first visit to Berlin, so Terry and I played tourists for a bit and went to see Checkpoint Charlie, the remaining pieces of the Berlin Wall, Brandenburg Gate, and Reichstag. It is really amazing to consider that the Berlin Wall used to be 150 km long and embedded a piece of Western Germany in the middle of Eastern one.
Finally, I had a long series of flights home, and despite a mishap at the immigration in Chicago, arrived to my apartment safely and almost on time. It was great to see old friends and new faces and to talk to the best development community out there.
For those of you who wondered where to get the I � Unicode t-shirt that I wore during my keynote, I put the design up on Zazzle, so you can get your own for the next gathering of the Unicode-minded folks.

Yes, it’s true.
A recent post on Twitter from @atourino pointed to my VIM for (PHP) Programmers slidedeck on scribd.com. The slidedeck has been really popular, gathering close to 50,000 views, 2,500 downloads, a few dozen favorites ratings, and a “Hot” award. Good deal, eh? Except that I didn’t upload this slidedeck—someone else did.
Scribd’s about page describes it as the place “where you publish, discover and discuss original writings and documents”. I’ve used it in the past to find all kinds of documents and there’s a lot to like about the site, but the keyword here is “original”. I really don’t mind sharing the slides—heck, I tell everyone at conferences to download them from my site—but on my Talks page I specifically ask people to obtain permission before re-publishing the slides elsewhere. It’s not a difficult thing to do. So far I’ve resisted putting a copyright notice on every slide, because I was hoping the common sense would apply, but apparently not for everyone.
I contacted Scribd’s customer support to see how I could take the ownership of the document in question. They replied that I would have to submit a DMCA copyright infringement notice and ask for the document to be taken down. I understand that this is their policy, but I think this is going overboard, especially for a case like mine. I really wanted to handle this in a polite manner and in such a way that people’s links to the document wouldn’t break instead of doing the dickish move of demanding it be removed completely. At the same time, I feel that the person who uploaded my slides without permission was wrong. Thus, I had no choice but to send the DMCA notice along with a request for the document to be re-assigned to me.
I would encourage everyone to be more careful in handling publicly available content. Please check for any restrictions on usage and publishing, and if in doubt—ask. This will help avoid resorting to heavy-handed stuff like DMCA notices.

A couple of months ago I saw a teaser post from iBuildings about the new Dutch PHP Conference in Amsterdam this year. I really like Amsterdam, so I started racking my brain to see what kind of proposal I could submit. Not a day had passed when I got an email from Cal Evans asking if I would like to give the opening keynote at the conference. Success! Of course I agreed and suggested an additional talk about distributed processing with PHP, titled “All the Little Pieces”.
The line-up for the conference looks great: Xdebug’s Derick Rethans, php|architect’s Marco Tabini, Zend Framework architect Matthew Weier O’Phinney, security guru Stefan Esser, “RESTful” Ben Ramsey, PHP core developer Scott MacVicar and many others. The early bird pricing is available until April 30, so I would encourage you to take advantage of it and come see what is bound to be a great event.

It’s been a couple of month since the release of pecl/memcached and I was getting the urge to write something else. At the same time, I was reading up on Bloom filters, but couldn’t find a PHP extension that implemented them. Thus, pecl/bloomy was born. Now, you may be wondering, what the heck is a Bloom filter why in the blooming sky would I want to use it? Well, read on.
A Bloom filter is a probabilistic data structure that can be used to answer a simple question, is the given element a member of a set? Now, this question can be answered via other means, such as hash table or binary search trees. But the thing about Bloom filters is that they are incredibly space-efficient when the number of potential elements in the set is large. The way that they achieve this is by allowing false positives with a certain error rate. Basically, a Bloom filter will give you either “no” or “maybe” as the answer and it’s up to you to determine the false positive error rate that you can live with. The smaller the rate the larger the size of the filter, of course, but it takes only 9.6 bits per element for 1% rate and every time you add 4.8 bits, the error rate becomes ten times smaller. Compare this to other structures that require storing at least the data elements themselves in the majority of implementations. However, the more elements you add to the set, the larger the probability of false positives becomes, so it is important to estimate the size of your data set properly.
Another nice thing about Bloom filters is that the time to store and look up the element is constant and does not depend on how many elements are in the set. Now that’s a pretty nice property to have, isn’t it?
So, what are they good for? Well, Google BigTable uses Bloom filters to reduce the disk look-ups for non-existent data; Cassandra also uses them to save IO; Digg might use them to implement checks for green tags on Digg buttons, i.e. have my friends Dugg this, etc. The possibilities are many.
The API of the extension is pretty simple. Create BloomFilter object and specify how many elements you expect to have in the set and what false positive rate you can tolerate. The extension will determine the optimal filter size and the number of hash functions to use. Then all do you is add and check elements.

$b = new BloomFilter(100000, 0.001);
$b->add('foo');
$b->add('bar');
$answer1 = $b->has('foo');
$answer2 = $b->has('zoo');
Here we say that we expect to store 100,000 elements with a false positive rate of 0.1%. Then we add a couple of elements and check a couple too. Now, $answer1 will be “yes”, but it may be wrong 0.1% of the time, i.e. if you check 1000 elements, you may expect to get “yes” for 1 of them when in fact it doesn’t exist in the set. The $answer2 will always be “no” because “zoo” was never added to the filter.
What’s the performance like? From a simple benchmark with 0.1% false positive rate, the time to insert 100,000 items was 0.12 seconds, and time to check 100,000 items was 0.11 seconds (this is on my Macbook Pro). The space used by filter? 179721 bytes.
I encourage you to download the extension, play around with Bloom filters and see what uses can come up with.
UPDATE: As Ryan pointed out in the comments, I misspoke when I said that $answer2 would always be “no” for “zoo”. It might be “yes”, but $answer2 would never be “no” for something that is in the filter, like “foo”.

In the previous post I mentioned that I was going to migrate to Google account on FeedBurner using a trick to avoid spamming the subscribers with old posts. The trick seemed to work fine, so here’s the explanation. I use WordPress (2.6), but this can be generalized to other systems. In wp-includes/feed-rss2.php, find the beginning of the post loop – the while( have_posts() ) line – and add another one after it to exclude the posts dated earlier than the migration date from the feed. It should look something like this:

 <?php while( have_posts()) : the_post();
 if (get_post_time() < strtotime('2009-03-01')) continue;

The end result of this is that your feed will contain only the items published after the specified date. This may be a bit strange for new subscribers, so I made a new blog post so as not to keep my feed completely empty, but for existing ones it should be transparent.
In general, I want to say that Google has completely mishandled this transition after their acquisition of FeedBurner. Chris Shiflett already explained what problems he saw with it, but I found one more: they broke the Awareness API. I noticed this because my feed statistics were all 0. Turns out that the old API URL (http://api.feedburner.com/) was gone, and you had to use the new one (http://feedburner.google.com/api). Breaking the legacy API URLs is a major violation of the contract you make with the users when you publish the API. At the very least, Google should have silently redirected the requests to the new API instead of doing the most egregious thing possible and simply removing the old URL. Shame on you, Google.