The calls I am using to record and retrieve these cookies are based on the old REST API:
$facebook->api_client->data_setCookie(user_id, cookie_name, value, expiry_time)
$facebook->api_client->data_getCookies(user_id, cookie_name)

The proper data format that Facebook is supposed to return looks like this:

[
{
"uid": "542432762",
"name": "test",
"value": null,
"expires": null,
"path": null
}
]


However, for the last few days, Facebook seems to be returning the data as a numerically-indexed array and not a array of hashes as above:

[99990041857023, "cookie_name", "value", "expiry", "path"]


You can temporarily fix your app by translating this array into the equivalent hash, like this PHP snippet does:


if( !isset($c['name']) )
{
$c = array(
'uid' => $c[0],
'name' => $c[1],
'value' => $c[2],
'expires' => $c[3],
'path' => $c[4]
);
}


Typically, the guid in the database will look something like this:

http://blog.bit-matrix.com/?p=2411

You can use this perfectly fine but it will hurt your SEO since search sites prefer descriptive links such as:

http://blog.bit-matrix.com/2010/02/10/google-buzz-a-privacy-disaster

As it turns out, you can easily construct this link from the database yourself. Wordpress will recognize the format of the link and display the appropriate post. The query to construct this is quite simple, all we need is a little date formatting:

SELECT CONCAT(DATE_FORMAT(post_date,’%Y/%m/%d/’),post_name) AS permalink FROM wp_posts WHERE post_status=’publish’;

This will return all the published post guid’s in the following format:

2010/02/10/google-buzz-a-privacy-disaster

That’s all!

Uncaught exception – load.c(232) : Failed to load library : std.ndll (std.ndll: cannot open shared object file: No such file or directory)

The solution is simple, you just need to install neko and neko-dev:

sudo apt-get install neko neko-dev

Now simply run the setup:

sudo haxelib setup

Happy haXe-ing!

“If you have something that you don’t want anyone to know, maybe you shouldn’t be doing it in the first place.”

- Google CEO Eric Schmidt

“…doing a privacy change for 350 million users is not the kind of thing that a lot of companies would do. But we viewed that as a really important thing, to always keep a beginner’s mind and what would we do if we were starting the company now and we decided that these would be the social norms now and we just went for it.”

- Facebook CEO Mark Zuckerberg

“There was of course no way of knowing whether you were being watched at any given moment… It was even conceivable that they watched everybody all the time.

But at any rate they could plug into your wire whenever they wanted to. You had to live – did live, from habit that became instinct – in the assumption that every sound you made was overheard, and except in darkness, every movement scrutinized.”

- George Orwell, 1984

Et tu, Google?

Why is it that the default modus operandi of every Internet company is to blatantly violate your privacy as a first rule of business? Google, surely, is a company that should not need a cheap trick like this in order to promote their product. A company whose “Do no evil.” slogan seems to only apply as far as showing you the most targeted ads and not blatantly deceiving you. Google has embraced Facebook overnight revelation that people don’t want or expect and seems to have launched Buzz as an example of this brave new vision.

Buzz outdoes Facebook when it comes to airing all your dirty laundry to the searchable metaverse. The privacy controls in Buzz are all strictly opt-out. You might miss this fact, as I suspect most people will, unless you are naturally suspicious of any site that has access to too much information about you. And yes, we should all be suspicious of them.

Buzz will show your real name and make it searchable to everyone. It will also show the world who you are following and who is following you. Since it populated your follow list from your email contacts, it essentially reveals your contact list to the world. It also shows your Buzz messages on this publicly searchable profile so if you have something private to say to your friend or spouse, make sure you use Gmail and not Buzz. Of course, they both show up in the same Inbox so mistakes are likely.

What makes Google’s actions more inflammatory than Facebook’s is that your GMail data is used to generate this public content. As an email system, GMail implies privacy and strict control over who your messages go to and who can see them. Therefore, all contacts and data in GMail were added by users with the expectation of full privacy. Buzz will, however, happily tell the world who you’ve been emailing the most. Beware.

There has already been a lot of complaints about this so-called privacy flaws. But can anyone really believe that this was a mistake in the design? That Google didn’t know the implications of making Buzz operate like this? They only need to look at Beacon and other privacy scandals Facebook has gone through to know where this leads.

One would think that launching a product like this that will expose the information of millions of users should take a bit of care and preparation. However, as of this time, Buzz doesn’t even have a Privacy Policy listed on Google’s Policy by Product page!

There is no doubt that Google knew exactly what it was doing when they made Buzz work the way it does. I predict that they will run it for a few weeks as is, making it accumulate users, and then they will “fix the problem” due to user complaints. By this time the damage will be done and this privacy “flaw” will have served its purpose.

Should you decide to turn Buzz off, there is microscopic link at the very bottom of the page that will allow you to do this.

In this case we want to re-direct our users and any bots to the same version of the URL (i.e. all lowercase). If you are running Apache, make sure mod_rewrite is installed and make the following changes to your configuration.

1. In your server config or virtual host file:
RewriteMap lc int:tolower

2. In your .htaccess file at the root of your site:

# Lower-case and 301 all requests
RewriteEngine On
RewriteCond %{REQUEST_URI} [A-Z]
RewriteRule ^(.*)$ /${lc:$1} [L,R=301]


Note: Beware that some standard files are mixed case and might be broken by doing this (such as AC_RunActiveContent.js).

For this we will use the CentOS testing repository:

cd /etc/yum.repos.d/
sudo wget http://dev.centos.org/centos/5/CentOS-Testing.repo
sudo rpm --import http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing


Now we can fetch package information about PHP using the new repository:

yum --enablerepo=c5-testing info php


Check the version number. If it is what you need you can go ahead and install it using yum:

sudo  yum --enablerepo=c5-testing update php


Assuming that worked, you can now restart Apache and be on your way:

sudo /etc/init.d/httpd restart


Memcache

If, like me, you were using memcache you might run into a problem where memcache never got updated to the proper version because it did not exist in the CentOS testing repository. The memcache module on the system ends up with a different PHP API version than is required by the new version of PHP you just installed.

Upon starting PHP you might see a warning similar to this:

Module compiled with API 20040429
PHP compiled with API 20060613


Again, we will add a new repository from Remi Collet. The steps should be as follows:

cd /etc/yum.repos.d/
wget http://rpms.famillecollet.com/remi-enterprise.repo
wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
wget http://rpms.famillecollet.com/enterprise/remi-release-5.rpm
rpm -Uvh remi-release-5*.rpm epel-release-5*.rpm


Now we can install the newest memcache library:

sudo yum --enablerepo=remi install libmemcached\*


Build the PHP module using Pecl (you might have to install php-devel packages for this):

pecl install memcache


Edit /etc/php.d/memcache.ini and add:

extension=memcache.so


Restart Apache:

sudo /etc/init.d/httpd restart


With a little bit of luck you will now have PHP 5.2.x and Memcache!

However, looking into the running processes via SHOW FULL PROCESSLIST I noticed that the thread reading the binary log data from the master has disappeared mysteriously.

Normally you should see two threads related to replication running on a slave server under the system user. One for reading the binary log data from the master and the other one for executing fetched data from the relay log:

mysql>SHOW FULL PROCESSLIST;
+--------+-------------+---------------------+------+---------+---------+-----------------------------------------------------------------------+-----------------------+
| Id     | User        | Host                | db   | Command | Time    | State                                                                 | Info                  |
+--------+-------------+---------------------+------+---------+---------+-----------------------------------------------------------------------+-----------------------+
|  37550 | system user |                     | NULL | Connect | 5878076 | Waiting for master to send event                                      | NULL                  |
|  37551 | system user |                     | NULL | Connect |       0 | Has read all relay log; waiting for the slave I/O thread to update it | NULL                  |
| 119738 | you         | 127.0.0.1:37540 | NULL | Query   |       0 | NULL                                                                  | SHOW FULL PROCESSLIST |
+--------+-------------+---------------------+------+---------+---------+-----------------------------------------------------------------------+-----------------------+
3 rows in set (0.17 sec)

mysql>

Restarting the slave would work for a short while until the same silent failure occurred.

In order to counter this, I looked into the variables related to networking and replication. modified the global variable ’slave_net_timeout’. The default variable for this is 3600 seconds (ie. 1 hour). The slave timeout sets the number of seconds to wait for the master to send more data before aborting the read. I set it to a short, 10 second period:

SET GLOBAL slave_net_timeout=10;

This improved the situation and the incidence of replication mysteriously stopping dropped dramatically. Additionally now the slave IO thread would actually stop running which, at least, given an indication that something is wrong.

Overall, the number of these failures dropped to almost zero just as suddenly as they had appeared. This leads me to believe that there might have been something in the network connection between the master and slave servers (in different datacenters) that was causing this.

Weeding out comments daily can be a real nuisance and, if you’ve missed a few days, the spam can pile up until it becomes a real time waster. Using the Akismet plugin for Wordpress goes a long way to rid you of spam and I would recommend that everyone use it. If, for some reason, you are looking for a standalone solution, I have hacked up a quick script to mark Wordpress Comments as spam based on the number of links in the comment. It is quite crude but if you have thousands of spam messages pilled up, you will appreciate it.

You will need Perl and the DBI module (if you don’t know what this is you should probably get the Akismet plugin ).

#!/usr/bin/perl
#
# wp_spam_kill.pl - brute force spam killing script
#
# Kill spam comments in WordPress based on the number of links in the comment
#
# date   : 2009.01.31
# http://bit-matrix.com
# license: GPL

use strict;
use DBI;

$| = 1;

# Configure your blog database
my $db = "DATABASE_NAME";
my $host = "DATABASE_HOST";
my $username = "DATABASE_USERNAME";
my $password = "DATABASE_PASSWORD";
my $comments_table = 'comments';
my $port = "3306";

# If a comment has more than this many links, mark it as spam
my $spam_level = 4;

sub query($$){
    my $dbh = shift;
    my $pre_bind = shift;

    my $sql = $dbh->prepare($pre_bind);
    return $sql->execute() ? $sql : undef;
};

# Connect to database
print "Connecting to $db...\n";
my $dsn = sprintf "DBI:mysql:database=%s;host=%s;port=%s;",$db,$host,$port;
my $dbh = DBI->connect($dsn,$username,$password);

# Fetch all unapproved comments
print "Getting comments...\n";
my $query = 'SELECT * FROM '.$comments_table.' WHERE comment_approved="0";';
my $c_sql = query($dbh,$query);
printf "%d Comments not approved yet\n",$c_sql->rows();

# Check each comment for number of links and mark it as spam if it has more links
my $spam_killed = 0;
while(my $c = $c_sql->fetchrow_hashref()){
    my @links = $c->{comment_content} =~ /(http:\/\/)/gs;
    if( $#links+1 >= $spam_level ){
        printf "SPAM - %d links in comment\n",$#links+1;
        query($dbh,'UPDATE '.$comments_table.' SET comment_approved="spam" WHERE comment_ID="'.$c->{comment_ID}.'" LIMIT 1;');
        $spam_killed++;
    };
};

printf "Marked %d messages as spam\n",$spam_killed;

0;

__END__

The issue at hand is the amount of power (as in electricity) that your code will consume when running on a large number of users’ computers (since you write awesomely popular software) or over a long period of time (if your software will be in use for years).

Hacks. Free(-as-in-beer)?

Suppose you hacked together a quick Flash widget to go on the front page of your up-and-coming website. Your code is nasty and the widget takes up almost all CPU power on a single core but you have no time to fix it and release it as-is.

Lets run some very basic numbers. A normal user might spend 10 seconds viewing your front page before navigating to another page without the widget. Lets also say that a typical Intel Core 2 CPU will consume about 33W when operating one of its cores at 100% load because of your crappy code. For those 10 seconds on the site, your widget has consumed 33W x 10s / 3600 s/h = 0.092 kW·h.

Let us now assume that you site got mildly popular and received a million visitors over the course of a year, each of which spent only 10 seconds on pages containing the widget. Now your widget has consumed about 92,000 kW·h, or 92 MW·h.

Garbage In – Carbon Out

The average household in the United States uses about 11,000 kW·h (11 MW·h) of electricity, each year. Congratulations! Your inefficient code has used up enough electricity to power almost 8 homes for a full year!

If you live in the United States, half of this electricity is likely to come from coal. Coal has en energy density of about 2.0 kg / kW·h meaning that the amount of coal burned to power your inefficient code is 0.5 * 92,000 kW·h / (2.0 kg / kW·h) = 92,000 kg = 92t. Yes, that is 92 tons of coal!

Given that producing energy from coal also releases CO2 at a rate of about 0.950 kg / (kW·h), your code will have resulted in 87.4 tons of CO2.

These numbers seem quite depressing. What if your widget ends up on the front page of a big site with tens or hundreds of millions of visitors a year? How much environmental destruction can one nested for loop cause? How many dead penguins will you be responsible for? Gasp!

Save The Planet?

But let’s be realistic, code will always consume power and you can only do so much to reduce that. Some applications will have a net benefit of reducing energy consumption by making people more productive and efficient with their time and energy (your punch-the-monkey widget might or might not be one of those).

The point of the matter is that, even when programming, one can consider the environment. If that consideration provides you with the impetus to sit down and properly re-write a power-hungry piece of code then you have made a real physical change in the world. And now, you can put a number on it.

Safe the CPU cycles – save the world.