Thoughts about App.net

I’m sure you have heard of App.net by now. The paid, non-advertisement-supported “live social stream” (read: Twitter). They set a $500,000 goal, and raised more than $800,000 – a clear indicator that some level of demand is there for such a service.

There are two levels of membership, the $50 “User” level and the $100 “Developer” level. A developer account will give you the necessary API keys to build apps that connect to App.net. I was very interested in how these prices were chosen, and thankfully App.net published their logic (“How did you come up with the pricing tiers?” in the FAQ).

I agree with Marco Arment that $50 a year is too expensive for regular users, but he didn’t have anything to say about the developer tier. Here’s an excerpt from the FAQ that irks me:

The developer price is inspired by the amount charged by the Apple Developer Program, $99. We think this demonstrates that developers are willing to pay for access to a high quality development platform.

The decision using the Apple iOS Developer Program as inspiration for the App.net developer tier is, I believe, fundamentally flawed – there are too many differences and not enough parallels:

  • The iOS Developer Program includes hosting of your app.
  • The iOS Developer Program introduces your app to all iOS users
  • Et cetera..

For App.net to convincingly (using their present argument) charge $99 for their developer tier, I believe that the following services are necessary:

  • A central repository of App.net-enabled apps (this looks like a beta)
  • A much larger user base – there were approximately 8,000 “User” tier backers. At $1.99 (revenue of $1.40) of 20% of these users, you can expect $2,240 of gross income. With over 2,000 registered developer accounts, 20% is extremely optimistic.

Of course, if you believe that App.net will balloon, the developer tier is moderately priced. Otherwise, it’s just another lucrative investment.

(Yes, I did back App.net)

Becoming a better PHP developer

There’s no denying that PHP is not the optimal language. But at least code in good PHP. Here’s my pet peeve for the day:

Relative paths in include(_once)? or require(_once)? statements.

// WRONG
require_once("./include_me.php");
// RIGHT
require_once(dirname(__FILE__) . "/include_me.php");

Why? Basically, performance. PHP doesn’t look through all its search paths for absolute paths, saving those precious system calls. This effect is compounded when you’re using the APC cache with apc.stat = 0 (it won’t even cache files that are referred to with a relative path)

text-rendering: optimizeLegibility;

Basically, do not use text-rendering: optimizeLegibility; with Japanese. At least, not yet. Why not? Here are some examples.

The top line has text-rendering: optimizeLegibility; applied, and the bottom line use the browser defaults. As you can probably tell, optimizeLegibility has indeed optimized the legibility, and the type looks much nicer. However, there is a fatal bug in rendering Japanese characters with optimizeLegibility: It seems that the actual optimization is taking place after the length of the line is calculated. As you can imagine, this is a problem. Here’s a screenshot with an underline applied:

Because length-of-line calculations are used to determine line breaks, this bug will also make your sentences break in weird places.

Screenshots taken with Chrome 21 on Mac OS X 10.8. I was able to reproduce this in all WebKit browsers.

Font Smoothing

This is what text (more or less) looks like in Windows! Just do:

“`css
* {
-webkit-font-smoothing: none;
}
“`

To enable Windows Emulation mode. Great stuff.

There’s a few resources about -webkit-font-smoothing in English, but I was wondering what it would look like in Japanese. Here we go.

none;

おはようございます。僕の名前は敬太郎です。東京にうまれ、アメリカのメイン州育ちです。大学は国際基督教大学、3年間の後で退学しました。今は、東京武蔵野市の吉祥寺に住んでて、Flagship LLCでエンジニア・プログラマーとして働いています。よろしくお願いします。

subpixel-antialiased;

おはようございます。僕の名前は敬太郎です。東京にうまれ、アメリカのメイン州育ちです。大学は国際基督教大学、3年間の後で退学しました。今は、東京武蔵野市の吉祥寺に住んでて、Flagship LLCでエンジニア・プログラマーとして働いています。よろしくお願いします。

antialiased;

おはようございます。僕の名前は敬太郎です。東京にうまれ、アメリカのメイン州育ちです。大学は国際基督教大学、3年間の後で退学しました。今は、東京武蔵野市の吉祥寺に住んでて、Flagship LLCでエンジニア・プログラマーとして働いています。よろしくお願いします。
 

Source: Max Voltar

Retina, Please!

A few days ago, I posted a small JavaScript snippet.

Retina, Please! is that JavaScript snippet on steroids. It is a combination of JavaScript and PHP to allow your Retina users to only download Retina images, while non-Retina users only download the standard-resolution version.

Check it out: https://github.com/keichan34/KKRetinaPlease

WordPress Theme Writers: just require it in your functions.php. I may package it into a real plugin later on.

I’ve tested it with CakePHP as well.

Varnish: Debrief

Today, we just released the Varnish-ed site I posted about a few days ago. A few things to be careful about in your Varnish deployment (that I had originally overlooked):

  • Make sure you’re 301 redirecting traffic to your canonical name (http://www.example.com/example to http://example.com/example, or vice versa)
  • Do this redirecting within Varnish! I had strange problems when applying this logic within Apache.
  • If you insist on applying the redirection logic within Apache, you may run into a problem where the Varnish health-check “probes” will fail (and deem your backend “sick”, throwing 503 errors at everyone after the grace period has expired).