Photos From Hawaii


There's a mix of photos from my camera, and from Sanaz's, with whom I was travelling. It was amazing and surprising how much better her camera was: especially in low light situations, but also in general, taking brighter, sharper photos. Here is a comparison:

"Bad" camera "Good" Camera

I used to believe that all point-and-shoot cameras were more-or-less interchangeable, and that composition mattered over quality of the camera. The photos we took on this trip caused me to re-evaluate this view.

English/Transliterated Persian Translator

UPDATE: Not even a week after I made this, Google announces that they will be shutting down or deprecating all of the APIs used in this project. This is slightly frustrating.


Quick, pronounce this:

هاورکرافت من پر مارماهى است

This is Persian. It uses the Perso-Arabic alphabet. If you're like me (that is, you don't know Persian), you can't pronounce this easily, so tools that translate from English to Persian aren't of much use. Instead, you want an English to transliterated Persian translator; unfortunately, these don't exist.

So I made one.

How it Works

Google provides APIs for translation, English to Persian transliteration, and Arabic diacritization.

Transliteration is the act of converting the alphabet used to represent a languge from one to another. Transliteration to English (from, for example, Arabic-based alphabets) is well-studied. Often a user will have access to only a western keyboard, but want to type in Persian, or Chinese, or Russian. Tools like Google Transliteration will do this, but they don't go the other way.

Transliterating well is enormously difficult, as hard as translation: word meaning and intent is important. For example, how do you pronounce "bow"? It's not clear, because the word for the thing that shoots an arrow is pronounced differently from the word for bending at the waist. In other alphabets, these could have different transliterations.

However, transliterating poorly is often not hard: make a one-to-one letter map from one alphabet to the other. However in Persian, the written form has no vowels--doing this naively would result in a mess of consonants. Diacritization, the act of adding the vowel pronounciation marks to Persian, can provide the vowels.

To translate from English to transliterated Persian, the tool first translates to Persian, diacritizes the result, and then transliterates the diacritized Persian-alphabet text back to English. The first two steps are done using Google's APIs, and the last step here is implemented, in rudimentary fashion, by me. The first two steps also tend to make errors--after all, translation and diacritization are hard problems. Nonetheless, the end-result seems to be OK: for simple sentences, the end result is readable and either correct or close to correct. Often, the translation itself will be poor, which is a limitation of translation being such a hard problem.

The other direction, transliterated Persian to English, is easier implementation-wise, because Google's will transliterate the "pinglish" back to real Persian (transliteration API) and then to English (translation API). It's just a matter of stringing the APIs together.

(The pronunciation of the phrase at the top? "havercrafte man pore marmahi ast")

How to Add a Facebook Login Icon to your Website

The Facebook developer page can be daunting at first glance: the documentation can be contradictory and confusing, and seems to be constantly changing. A big part of the problem is that they have so many APIs. Some are listed as deprecated, but seem to have no proper replacement.

In this post I'll discuss some of the steps I took when adding a Facebook login button to a site I'm making, and the approach I ended up taking. Our goal is to end up with the facebook id number associated with the user.

Client-Side flow

Facebook's documentation for adding a login button proposes the following code (also based on boiler-plate example code from Facebook):


Let's go over what happens here: This happens purely on the client side, in javascript. The <script> tag inclusion of all.js passes two parameters to that script: the app ID (1234512345), which gives the ID of our and the xfbml=1 flag, which indicates that XFBML should be parsed. When the script is loaded by your client, FB.Init will be called, and the XFBML in the page will be parsed. It will discover the <fb:login-button> element, and parse it to replace it with proper HTML and Javascript for a login button.

When this login button is pushed, it will transparently make the Javascript API calls to authenticate the user. You may subscribe to the login event using FB.Event.Subscribe. Once the user is logged in, you may get their session information using FB.getLoginStatus.

By default, the appearance of the login button after login is not very appealing. The page will either show other friends that have also used this app (this seems too invasive), or show the same login button unchanged (this seems potentially confusing for the user). This would need to be customized by subscribing to the login event.

Server-side flow

The above flow is what Facebook suggests, and is quite simple. However, we may also want the server to have the Facebook session information. The PHP SDK provides a means to do this. A Facebook login will automatically create a cookie for your site, which means that if any session information is present, it will be available on your server.

I came up with the following code:

PHP checks for a currently active session. If one exists, we get it and emit A "currently logged in" state with a logout button. The session is now available both on the server using the PHP API, and to the client. If no session exists, we instead emit the client-side login code from above. Additionally, we set a hook to reload the page when login occurs. When the page reloads, the session will exist.

This approach takes more code, but seems more flexible than the first client-only flow above.

Graph Drawer

Graph Drawer is the example app I built on top of my Graph.js graph drawing API, and is actually pretty fun. You can share the graphs you draw (the link above goes to my drawing of the Petersen graph.

The tool also provides a way to create graphs, which can then be accessed using the API in other contexts. This is how the graphs in the Graph.js demo were created.

iPhone 3GS Music Player Battery Usage

In theory, a phone should double as a great music player. In practice, my iPhone 3GS goes through batteries at an incredible rate: often, I'll listen to it for a few hours, and the batteries will have gone down by 50% or more. This isn't normal for music players. IPods and Zunes last for multiple days without needing a recharge, and there's nothing about the IPhone that should make playing music harder. The most likely culprit is that the phone is sending or receiving data while playing music.

So I ran a few tests. Each test involved playing music for half an hour, and recording the change in battery level. From these, it's easy to calculate a battery lifetime for the task. The results:

Music Player Battery Lifetime by Enabled Data Mode:

  • 3G network (no wireless): 5 hours
  • Edge network: 10 hours
  • Wireless network: 12.5 hours
  • Airplane mode: ~100 hours

Because of the inaccurate methodology [1], these numbers should be taken as ballpark figures. The battery usage in all of these modes when no apps are running is close enough to zero to be ignored, so the battery drain here is primarily from music playing and associated tasks. 

So the questions are, what is it doing, and how do I stop this? I don't particularly care to send Apple usage information, or to fetch lyrics and artist info (these settings were disabled for the the tests). I just want to listen to music, without disconnecting my phone from the internet. This doesn't exactly sound like a niche requirement.

Phone configuration:

  • Jailbroken iPhone 3GS running on Rogers' network, software 4.0.1
  • Constant "medium" volume for all tests
  • "Lyrics and Podcast Info" IPod app setting disabled, along with all other IPod app settings
[1] This is only accurate to within 1%, so particularly for the tests with low battery usage, the extrapolated battery lifetime can be quite inaccurate. For the tests with data enabled, the phone is still checking email and doing other background tasks that might introduce a small battery overhead.