Use Greasemonkey to extract your Facebook Phonebook

7/19/2010 UPDATE: There is a BRAND NEW version of the script available on Userscripts here.
10/12/2009 UPDATE: Added fixes from Marcel Chastain
UPDATE: It looks like the version that got uploaded was missing a * in the trigger URL! That might be the issue everyone is having.
UPDATE: Video of the process: fbimport

Facebook’s API + FBConnect is great but it has some severe limitations. Notably, it doesn’t expose all the functionality available on the Facebook  site. Tonight in particular, I wanted to be able to copy a dump of my friends’ names and phone numbers off the site to load into a fresh cell phone. Unfortunately, looking at the API this isn’t possible.

Never fear – Greasemonkey provides enough of a hook into Firefox that it would be possible to write a UserScript to accomplish this loans-cash.net.

Continuing beyond this point is probably against the Facebook TOS and will probably severely void your warranty.

You have been warned.

The following describes how to use this userscript to extract your Facebook “Phonebook”. It produces of a CSV of your friends’ names and phone numbers. Fair warning – this is a rough prototype and does almost no error handling. Also, since the “Phone” field is a free text field I can’t promise people will have formatted their numbers in any sane fashion. But either way it’s a good start to revering lost numbers.

займы онлайн на карту круглосуточно

So here is what you need to do to use the script:

1. Install Greasemonkey – https://addons.mozilla.org/en-US/firefox/addon/748

2. Follow these instructions to install the script – http://userscripts.org/about/installing

Edit: The script is also on Userscripts at http://userscripts.org/scripts/show/43681

3. Navigate over to http://m.facebook.com/friends.php? (You’ll have to login)

4. Answer yes to the prompt and sit back – the script will move through your phonebook and eventually dump you a CSV of the results.

5. Copy/Paste the CSV wherever you want.

6. Un-install the Greasemonkey script.

So that’s it, one less walled garden to worry about. And hopefully one less “I lost my cellphone!” event/group on facebook!

The script:

Facebook Phonebook Exporter

Gmail fail

Looks like someone at gmail forgot to make sure the system won’t display negative time for future timestamped emails. I’m not sure where/how this email got a bad timestamp but gmail is displaying it as being sent in the future!
See it!

Client side RSS aggregator

One of our clients came to us a few days ago asking us if we could build something to aggregate several RSS feeds and then display it on their site.

Easy enough. Except the caveats were 1) This had to be done on a shoe string budget and 2) We had no permission to script on the server side (only client side scripting allowed kids).

We put our heads together and realized that Yahoo Pipes would provide the functionality to easily combine several RSS feeds, sort them, filter them, ect. And best part? It’s all built and all free. Pipes also provides the functionality to export a pipe as a JSON feed (as opposed to RSS).

So that takes care of problem 1 and almost fixes problem 2. Of course the remaining problem is getting around the cross domain XHR restrictions on the JSON. I did some poking around the Yahoo Pipes documentation and it turns out you can add a _callback parameter to the URL and bang it wraps the JSON in a JS callback!

Issues solved. The final part was to mix in a little jQuery to load the JSON+callback feed into a <script> tag and then display it.

Total lines of code: 27 lines of javascript.

EDIT. Now with code!

Hello Android!

In the last few weeks the battle and buzz over the smart phone market seems to have seriously intensified.

First there was the usual iPhone buzz, news about the Android powered HTC Magic, the Windows Mobile marketplace, and of course the obligatory ridiculousness at Microsoft.

I’d been considering experimenting with a mobile platform for sometime and finally decided to take the plunge. I decided to give Android a whirl primarily because I don’t have easy access to OSX or Visual Studio and my Java is less rusty than my .NET.

Anyway, getting going with Android was deliciously simple – download the SDK+Emulator and Eclipse plugin and you’re off.

After the necessary “Hello World” application I tried to write something a bit more substantive. Personally, one of the coolest facets of mobile development is the ability for applications to be location aware (GPS). Mix this together with some openly available geo tagged data and the result is probably going to be interesting.

With this in mind, the plan became to mash together Android’s GPS coordinates with flickr’s geotagged photos.

Getting access to Android’s location service is fairly straightforward. You basically register to receive updates either when the device moves a certain distance or on some time interval:

The biggest “gotcha” with this is that you NEED to remember to modify the default Application security settings to allow you to access the device’s location. In Eclipse, edit AndroidManifest.xml and add “UsesPermission” for the following: android.permission.ACCESS_MOCK_LOCATION, android.permission.ACCESS_COARSE_LOCATION, android.permission.ACCESS_FINE_LOCATION

So on to part II – using the device’s location to pull down Flickr photos. I’d used the Flickr API before so I knew how to do it but I’d never used it from Java. I tried loading the JAR for the flickrj client library but the Android JVM was having some strange issues with it. I was under the impression you can link to external JARs from Eclipse but I may be wrong (anyone?).

Anyway, the Flickr requests were un-authenticated and pretty straightforward so I decided to use Java’s URL class. Accessing sockets was another “gotcha” – Android requires your application to have the “UsesPermission” android.permission.INTERNET to use sockets. The exception when the permission isn’t set is notably cryptic – “unknown error”.

I decided to download all the Flickr photos to the device so that the UX would be generally smoother. This introduced threading to the project so that the UI wouldn’t freeze up while the photos were downloading. Android threads work just like traditional Java threads and the process was generally painless:

With the photos pulled down the final task was displaying them. After poking around the Android documentation I discovered the Gallery widget. It basically allows you to display a set of items in a list and specify a “renderer” for the gallery. I’m not sure if there is a default way to make it “fisheye” (like on an iPhone) but I rolled a quick n dirty solution for that. I also couldn’t get it to look really sexy but that’s also probably possible.

So that’s about it. Here are some screen shots of the application running in the emulator:

And without further a due here is the code as an Eclipse project.
geoflickr

Anyway, before the bashing starts – I know I’m a terrible Java programmer and that this project isn’t really engineered beautifully. It was just supposed to be a way to get my (and anyone else’s) feet wet with Android. Any comments/thoughts/improvements are of course welcome!

sfPropelPager and GROUP BY criteria

So for one reason or another (actually a few bad ones) I ended up having to use a Criteria object looking like this:

It makes SQL that looks something like this:

“SELECT tag_id, tag_model, id, COUNT(*) AS the_count FROM sf_tagging WHERE tag_id IN (1,2,3) GROUP BY taggable_model, taggable_id HAVING the_count > int”

The query sucks but whatever it works.

My issue came when I tried to use it with a sfPropelPager. I set up the pager per usual but for some reason the results that were coming back weren’t correct. For some reason, the COUNT being returned by the sfPropelPager was completely wrong. It turns out the offending lines are here in sfPropelPager.class.php :

For whatever reason, sfPropelPager clears the GROUP BY clauses before it calculates the COUNT for a criteria object. I’m not sure why it does this – but it certainly is unexpected and breaks my query in particular.

There are a handful of posts about this on the Symfony forums and it looks like the Propel people know about the issue to.

The solution to this is to use the setPeerCountMethod() from sfPropelPager. The setPeerCountMethod() function allows you to specify a custom COUNT() method inside the peer for your Criteria. I went ahead and added a new function to put the GROUP BY columns back in:

This solution works but it is extremely rigid. Since the custom count function has to be static you’d really be out of luck if you had variable columns or other dynamic requirements.

I’d love to know if someone has a cleaner/better/more elegant solution for this.