Slice the content of your pages into full-view sections.
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
- Xcode & Command Line Tools reinstallation
- Upgrade Homebrew
- Slow Ruby and Unicorn
- PhantomJS cannot be compiled
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-Ron 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
$ cd "/Volumes/Macintosh HD" $ find . -iname 'local' -type d | grep usr/local
- Of course, I was smart enough to
cdinto 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.
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
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
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/Xcode.app/Contents/Developer/usr --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
$ gem install libv8 $ gem install therubyracer
This should do it. Then, just
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!
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.
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: :copyrightor keep all comments with
There seems to be no way for Sass to strip out copyright notices, or any such comments usually beginning with
You have PostgreSQL installed with Homebrew on OS X. After you restarted your Mac, somehow Rails or other apps using PostgreSQL will report the server is not running while trying to start it with
launchctl will say otherwise.
Turns out, the
.plist file used by
launchctl is only checking for the existance of the
.pid file written by PostgreSQL when starting up. If you don’t shut down PostgreSQL before restarting the computer, that file will stay there. When your Mac starts up again,
launchctl will see that
.pid file and will assume PostgreSQL is already running while it’s actually not. Annoying, I know.
First, make sure PostgreSQL is actually not running:
$ ps aux | grep bin/postgres
Maybe except for
grep bin/postgres, the above command should display nothing. If that is the case, then PostgreSQL is not running.
Unload the launcher with
$ launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
$ rm /usr/local/var/postgres/postmaster.pid
Load the launcher with
$ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist
Check to see if PostgreSQL is running:
$ ps aux | grep bin/postgres
The above command should now display a process of PostgreSQL running.
That should bring your PostgreSQL server back up, and let Rails or whatever else use it.
Nowadays, your Web app likely needs security and encryption with SSL. Once your SSL certificate and Web server are set up, one good way to ensure SSL is used is to redirect all HTTP traffic to HTTPS.
In the world of Ruby, I’ll explain how to do it for any application running with Rack or anything built with Ruby on Rails. Your Ruby on Rails application is probably running on top of Rack anyway, so the odds are you just need one of the two methods below.
Both techniques are using environment variables to enable features as I explained in another article. In this case, I’m using the
FORCE_SSL variable: if it is set to
'1', it means the app should force the usage of SSL connections all the time.
Force SSL with Rack
All you need to do is use the rack-ssl gem and add a line in
Add this line in your
Update your installation of gems:
$ bundle install
Add this line to
use Rack::SSL if ENV['FORCE_SSL'] == '1'
Don’t forget to set
FORCE_SSLamong the environment variables for the app:
Chances are you want to go with this method. Many apps on different frameworks like Ruby on Rails or Sinatra is using Rack as the Web middleware between the actual application and what the Web server, such as nginx or Passenger for Apache. Heroku also uses Rack with the Unicorn Web server to serve Ruby on Rails apps.
This way, forcing SSL connections is handled by that intermediate layer rather than the app itself, so you generally won’t have to worry about making your app aware of SSL connections.
Additionally, rack-ssl is enabling a few other nice security features:
- Flag all cookies as “secure.”
Strict-Transport-Security(HSTS) header: a way to tell the browser to only use HTTPS connections and skip redirections on subsequent visits to the HTTP site.
Force SSL with Ruby on Rails
If for some reason you have a Ruby on Rails app, yet cannot use Rack, you can always set the app itself to force SSL connections. Simply add an initializer file:
Save the following in
Rails.application.configure do config.force_ssl = (ENV['FORCE_SSL'] == '1') end
Don’t forget to set
FORCE_SSLamong the environment variables for the app:
It is not as automatic as using rack-ssl, but you don’t need any extra gems for this. There are probably ways to implement HSTS and secure cookies with this too, but I didn’t have a need to look into doing so, as I always use Rack. These missing bits aside, it does the job just fine, which is to redirect all HTTP connections to HTTPS.
Now that you see redirecting HTTP traffic to HTTPS isn’t a hard thing to do with Rack or Ruby on Rails, you have no excuse not to do it now. 😛