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).
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)
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:
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.
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):
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).
If you’re on a Retina-equipped device, your images with the autoRetina class will automatically be replaced with their Retina counterparts. If you’re familiar with iOS development, you’ll feel right at home. If you have no clue what I’m talking about, just append @2x at the end of the filename (before the extension).
Put simply, Varnish is a “reverse proxy” - a piece of software that goes between the main server and the client. Basically what it does is caches content, so PHP (or whatever backend you’re using) doesn’t need to run for every single request - this makes perfect sense with static content. For sites like WordPress, filled with mostly static content, Varnish will work out of the box (minor configuration changes are required for small things).
As many of you are aware, I have been working for about 6 months now, with 2 other people.
On July 4th, we are pleased to announce that we have officially become a company, Flagship LLC. We have some pretty cool projects lined up in the near future, I’ll be posting updates on our released projects (and maybe if you’re lucky, bits and pieces of unreleased projects) here!
Our goal as a company is multi-fold, but I feel that the most important facet of Flagship is to bring modern web development and standards to Japan. In a country where Japanese translations of English reference material is prominent, especially in technology, we strive to be the flagship of truly born-in-Japan material.