Visit to Akihabara with Patrick and TOKYO WAY

A few months ago, I joined American expat Carl Kay in Japan as Web director and fanatic of Japanese popular culture in building TOKYO WAY. The new service offers people visiting Tokyo to experience the area in unique ways matching their hobbies and interests with local experts. Earlier this month, we were happy to open our new Web site at for people to browse and what we have to offer and sign up for events.

Akihabara station.

The creation of the Web site, combined with the subject matter, was a rare compelling experience. I’ll get into the technical details related to Web development on Rémi Code another day. For now, not only as a programmer, but also as a cosplayer who loves the otaku subculture and a traveller at heart, I thought I ought to at least try our Otaku Experience, set in Akihabara.

Cover of "The Moé Manifesto", with maid next to Patrick dressed up as Goku from "Dragon Ball."

Last week, with other guests interested in world of otaku, I joined local otaku expert, Patrick W. Galbraith, a Ph.D. student in Cultural Anthropology at Duke University and author of various works related to the phenomena of the area, including the latest title, “The Moé Manifesto: An Insider’s Look at the Worlds of Manga, Anime and Games.”

Hallway in Radio Center building.

After we gathered in front of a convenience store near Akihabara station, Patrick led the way around the station, beginning with a walk between little shops of radio, lighting, and electronic equipment nearby. He explained how Akihabara got the nickname Electric Town, as the area became famous for the tiny stores forming the compact two-floor market in which we were. Called Radio Center, reflecting the passion of radio the frequent shoppers there shared in the yesteryear, the shopping mall was formed after World War II and remains much unchanged since.

Akiba Shrine niche.

Historically, there was confusion whether or not a god, or kami, was present on the second floor of Radio Center. The uncertainty nevertheless turned into belief, exposed by a small niche over a fire hydrant, housing a local spirit of the nearby Akiba Shrine who protects the area against fire accidents. I’d say the entity is doing a good job so far.

Front of the Radio Kaikan building.

Before venturing further away from the station, we visited the floors inside Radio Kaikan. One of the first tall buildings in the area after the popularity of Radio Center, it closed in 2011 for renovations and finally re-opened in July.

Street with Radio Department Store.

Walking along the train tracks above us, then down one of the most crowded streets of the area, we peaked inside several stores of manga, arcades (or “game centers,” as they are called here), cosplay pieces, and boutiques selling second-hand items or material made by fans of popular anime series. Patrick explained how most places in Akihabara target men with some objectification of women, as opposed to Ikebukuro where women are usually targeted. This makes me think the police concerned about disturbances isn’t the only reason why taking photos is usually forbidden.

Sign for Animate store.
Animate, famous chain store of anime, manga, and cosplay items across Japan. This location is in the Akiba Cultures Zone building.
Sign at Maidreamin.
Maidreamin, popular chain of maid cafés with six locations in Akihabara, several others elsewhere in Japan, and one in Thailand.
Front of crane arcade.
If you’re lucky with these cranes, you can win some nice stuffed animals or figurines. For me, I bring a Mason jar, to store all the empty air I catch every time.
Sign pointing to a maid beauty salon.
T-shirts hanging in front of a store with all kinds of anime-like characters.
Store sign for Nadeshiko sushi.
Cute ladies prepare and serve you sushi at Nadeshiko, a twist on the typical sushi counter usually run by older men.

Canned oden in vending machine.
Opened can of oden.

All this walking made us hungry, just in time for the unique culinary experience of the trip: canned oden sold in a vending machine. The recipe for oden normally consists of konjac, daikon, boiled eggs, and fishcakes in broth, and usually varies by family and region. But this industrially-prepared oden, with its canned taste, was probably made by old rusty robots. Somewhat fitting, as people eating it are properly early-risers who have no where else to go for breakfast. For processed food, it’s passable — I wouldn’t expect the meal of a fancy restaurant in a can. Besides the taste, I did wonder if the meat was not actually a mix of tofu and konjac. What resembled a boiled quail egg had a strong yolk that spread itself down my oesophagus, and nothing seemed to wash it down. My oden experience was also diminished by the dispenser not giving me a tiny plastic fork like it should have, so I had to dip my fingers in the can to find that little toothpick poked in the piece of konjac inside. I certainly washed my hands since then, but rubbing those fingers extra hard to get the sticky oden broth off them formed into a habit of mine during my morning shower. I’m fairly certain the experience would have been greatly enhanced by that missing plastic fork. Damn you, greedy vending machine! At least, the konjac was nice.

Front of gachapon store.

Talking of things that look like eggs, a stop by a gachapon store was in our plan. The place welcomed us with rows and rows of colourful machines dispensing gachapon, little plastic shells with tiny toys, fake jewels, or mini figurines inside: put in a few coins, turn the dial, and see what you get!

A gachapon prize: a miniature dog wearing an alien mask.

One of the little things we won was a little dog disguising as an alien. Turns out even animals do cosplay here, it seems. Or was the dog getting ready for Halloween? I forgot to ask.

Front of cat café.
Cat café, where they won’t serve you cats, but they’ll let you pet them.
Front of Don Quijote store.
Don Quijote, a novel of chivalry to the Spanish, a famous store of cheap merchandise to the Japanese.

Sight of Hanabusa Shrine.

On our way back to the station, Patrick pointed to a shrine. Tucked inside a cluster of skyscrapers, the Hanabusa Shrine is currently visible through an open piece of land currently for sale. As everything around it is private property, including the narrow alleys leading to it, people without permission are forbidden to get there. In spite of that, it is good fortune, so it was kept intact. I was still hoping to prey there for the gods to help me get rid of that quail egg that slid down my throat, but I relied on more coffee instead.

Even if I lived in Japan for 5 years now, I still learned a lot from Patrick during our walk around Akihabara. Thank you, Patrick! He lived in Japan for twice as long as I have, and his knowledge of the surroundings showed that — the two-hour walk was only scratching the surface of how much he knows. For TOKYO WAY, Patrick is curating two regular events in Akihabara: the short one of two hours we participated in that day, and another one of four hours on weekdays, revealing more details and secrets of the electric town.

Tokyo Way

If you are curious to know how to join Patrick on his walk around Akihabara, check out the experiences offered by TOKYO WAY. And if you join him, there’s no need to bring a plastic fork for the canned oden — I’m sure that was only a fluke. Besides, food is clearly not the only thing Akihabara has to offer.

OS X Yosemite: Fixes for developers

Apple released OS X Yosemite to the public for free yesteday. So far, it isn’t bad. But, as a Web developer, I’ve hit a few bumps on the way, even during installation. Hopefully, if you’re a developer too, you’ll be wiser than me, do some research before installing, and maybe then this article will be of use to you.

This list isn’t meant to be exhaustive. I’m simply a Web developer often writing in Ruby nowadays, and I wish other Web developers will get back on track fast if they encounter the problems I have.

Unending installation

If you’re not a developer, the upgrade to OS X Yosemite will be quick and smooth. If you are a developer, and you’re using Homebrew to install packages, the installation may take longer, many hours longer.

Jim Lindley wrote about this issue in detail and what to do for a faster installation. The work around is simple: make sure you have a backup of your main volume, open the Terminal, and move the /usr/local directory away in your home directory:

$ mv /usr/local ~/usr-local

Once the installation is done and you complain how ugly the new Finder icon is, open the Terminal again and move that directory back:

$ mv ~/usr-local /usr/local

Alternatively, you can clean up Homebrew, removing several old packages you’re not using anymore. That way, you won’t move anything around, and the installation process won’t have too worry about dealing with a large amount of files:

$ brew cleanup

In my case, I was already in the middle of the installation. The progress indicated “About 2 minutes remaining” for 3 hours. I thought it froze, so I forced the computer to shut down by holding down the Power button.

After I complained about this issue online, I was told about this article by Jim, who recommends not to restart the computer if you’re already in the middle of the installation. Oops. Sorry about that, Jim, but thank you for the tip.

Nothing broke, luckily. After I interrupted the installation by forcing my Mac to restart, here are the steps I took to apply the workaround described above:

  • Held down Command-R on startup, before the Apple logo appears, for the OS X Recovery.
  • From the OS X Utilities window, opened Disk Utility.
  • Selected the main volume of my main media. (In my case, the greyed-out Macintosh HD.)
  • As the volume is encrypted with FileVault, clicked Unlock to unlock it using my user account password.
  • Once unlocked, clicked Mount to mount the volume, making the files accessible.
  • Quit Disk Utility.
  • From the menu bar, opened Utilities, and selected Terminal.
  • In Terminal, did the following commands (as the main volume just mounted is called Macintosh HD and my username is remi):

    $ cd "/Volumes/Macintosh HD"
    $ mv usr/local Users/remi/usr-local
  • Ah, but the directory wasn’t there! I had to look for it, and it was lodged in a system recovery folder. That was probably caused by my forced restart. Here’s the command I used to locate the usr/local directory:

    $ cd "/Volumes/Macintosh HD"
    $ find . -iname 'local' -type d | grep usr/local
  • Of course, I was smart enough to cd into the directory I found and out of it once I confirmed it was the Homebrew directory. Then, I moved it in Users/remi/usr-local, like I tried to do above.
  • Quit Terminal.
  • From the OS X Utilities window, selected Reinstall OS X.

This restarted the OS X Yosemite installation from the beginning. It asked me for my App Store account password, and redownloaded the package. That was inconvenient, but the installation went much faster than last time!

Once I started Yosemite, and looked at the Dock with the weird Finder icon in it, I moved the usr/local directory back in its place using the Terminal. (Or for me, iTerm 2.)

It’s all good. Now, on to more problems…

Xcode & Command Line Tools reinstallation

Since I’m using zsh with oh-my-zsh, starting a terminal like I have above will have a check for updates with git. That made OS X tell me the Command Line Tools needed to be installed, and offered to do so after downloading them automatically. After each upgrade of OS X, I knew I’ll have to install them again, but it used to be a manual process until now.

Although, what I didn’t expect was for Xcode to simply vanish. Maybe that was caused by my impatient restart during the installation. I had to reinstall Xcode from the App Store.

Upgrade Homebrew

You might as well do it now, after you just installed OS X Yosemite:

$ brew update
$ brew upgrade
$ brew cleanup

Although, I had problems updating Ghostscript and PhantomJS. For the earlier, the download connection simply kept dropping, so I only had to restart the upgrade over and over, and let Homebrew resume the download. As for PhantomJS, I have more details below.

Slow Ruby and Unicorn

One of my Ruby on Rails apps is using the Unicorn Web server in development, matching its production environment on Heroku. Yet strangely, Unicorn was so slow, connections to it from the Web browser kept timing out.

I found out Ruby needed to be recompiled. I’m using Ruby 2.1.2 for that Rails app. That’s not a problem, but it was compiled with Darwin 13 (OS X Mavericks) using rbenv. Assuming you’ve upgraded Homebrew like I described above, since you need the updated ruby-build package, I recompiled Ruby for Darwin 14 (OS X Yosemite) with the following:

$ rbenv install 2.1.2

It will tell you it’s already installed, but it’ll also give you the option to reinstall.

Once it’s done, calling ruby -v should show darwin14.0 instead of darwin13.0.

Naturally, I also had to reinstall my app’s gems with bundle install. However, thanks to the recompiled Ruby, Unicorn was working smoothly again.

PhantomJS cannot be compiled

If you try to upgrade PhantomJS with Homebrew on Yosemite, you’ll be disppointed to see it fail when trying to call qmake. The update for Qt in Homebrew, of which qmake is part, compiles just fine, but PhantomJS is using its own copy of Qt. As it sounds like the team behind PhantomJS is focusing on version 2 for the next update in Homebrew rather than fixing the current version, it’s unlikely there’ll be a fix for that soon.

That’s a real bummer, because I need PhantomJS to run my Cucumber tests in my Rails apps. Half of those tests are failing when PhantomJS is not available!

Luckily, you don’t really need Homebrew to get it, and you likely don’t need to recompile it. Just download the PhantomJS binary for OS X and copy it in usr/local/bin (or any other directory in your PATH), and phantomjs will work just fine. Now my Cucumber tests are all green again!

therubyracer won’t compile

Chances are you ran bundle for a new Ruby app with a Gemfile in it and you were slapped with an error message saying therubyracer couldn’t be compiled.

Don’t panic. (Like I do.)

If you ran into the other issues above, you probably have the correct versions of Ruby and GCC already installed, as well as the Xcode command line tools. You can verify, just to be sure:

$ ruby -v
ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-darwin14.0]

$ gcc -v
Configured with: --prefix=/Applications/ --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

$ xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates

If your version of Ruby is older, and you have RBEnv, maybe you forgot to switch away from the system version to the newest version first?

$ ruby -v
ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.4.0]

$ rbenv global 2.1.2

$ ruby -v
ruby 2.1.2p95 (2014-05-08 revision 45877) [x86_64-darwin14.0]

All you likely need to do is to update the libv8 gem, then try to install therubyracer again:

$ gem install libv8
$ gem install therubyracer

This should do it. Then, just bundle away!

These are the issues I experienced so far in OS X Yosemite. What problems have you run into? Do you dislike to new Finder icon as much as I do? Share your thoughts by leaving a comment below!

Ruby on Rails: Minify HTML, CSS, & JS, and compress with gzip

Update (2015-08-21): Do not use this. You will hate me for saying this, as this page is one of my most popular on the site, but after using my code on this page with Rails for quite a while, I came back on my own decision to use it. I knew compressing pages on every request would add some overhead, but I didn’t think it would be that significant – and it is, a lot.

While this would work with preprocessors like Middleman, which compresses all the files only once, doing so with an app generating pages on every request will slow down the application. You may install performance monitoring software like New Relic then toggle the compression to see the difference.

When optimising Web sites or apps for speed, any little bit helps. One of the easiest things to do is to “minify” all source files, removing all unncessary blank spaces, line breaks, and comments, and then compress them on the fly using gzip.

The simple initializer file below can be dropped in any Ruby on Rails app running via Rack (which includes Heroku) to minify all HTML, CSS, and JavaScript files, as well as compressing them with gzip for HTTP connections before sending them to the browser:

# config/initializers/compression.rb

Rails.application.configure do
  # Use environment names or environment variables:
  # break unless Rails.env.production? 
  break unless ENV['ENABLE_COMPRESSION'] == '1'
  # Strip all comments from JavaScript files, even copyright notices.
  # By doing so, you are legally required to acknowledge
  # the use of the software somewhere in your Web site or app:
  uglifier = output: { comments: :none }

  # To keep all comments instead or only keep copyright notices (the default):
  # uglifier = output: { comments: :all }
  # uglifier = output: { comments: :copyright }

  config.assets.compile = true
  config.assets.debug = false

  config.assets.js_compressor = uglifier
  config.assets.css_compressor = :sass

  config.middleware.use Rack::Deflater
  config.middleware.insert_before ActionDispatch::Static, Rack::Deflater

  config.middleware.use HtmlCompressor::Rack,
    compress_css: true,
    compress_javascript: true,
    css_compressor: Sass,
    enabled: true,
    javascript_compressor: uglifier,
    preserve_line_breaks: false,
    remove_comments: true,
    remove_form_attributes: false,
    remove_http_protocol: false,
    remove_https_protocol: false,
    remove_input_attributes: true,
    remove_intertag_spaces: false,
    remove_javascript_protocol: true,
    remove_link_attributes: true,
    remove_multi_spaces: true,
    remove_quotes: true,
    remove_script_attributes: true,
    remove_style_attributes: true,
    simple_boolean_attributes: true,
    simple_doctype: false

Also available as a gist on GitHub.


  • The code above uses environment variables by default, which I often use to enable or disable features instead of going by the environment name.
  • Despite the point above, no matter how hard you try, Rails will only allow Sass to compress the output on production.
  • As indicated in the code comments, enabling comments: :none for the JavaScript Uglifier will strip absolutely all comments, even copyright notices. When doing so, you are legally required to acknowledge the use of the software in a note somewhere on your site or app. Alternatives are to strip comments except legal notes with comments: :copyright or keep all comments with comments: :all.
  • There seems to be no way for Sass to strip out copyright notices, or any such comments usually beginning with /*!.