I’ve been making a Facebook
iframe app recently, and I found that this little code »
just doesn’t work on Everyone’s Favorite Browser™ (Internet Explorer 8).
always returned “0” for me. So I had to end up using
is NOT correct!!!
(This only applies if you’re outside of UTC. What’s that, like 99% of the world?)
The origins of Twitter.
- Here you go, free service!
- Wow, thanks for all those users!
- Look, you were great, but we don’t (really…) need you anymore.
- Fuck you.
In related news, if you haven’t heard about it yet: Twitter API v1.1
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)
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
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)
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.
This is what text (more or less) looks like in Windows! Just do:
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.
Source: Max Voltar
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.
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).