This post presents a quick fix for the broken font rendering problem on Windows browsers. The quick fix disables @font-face CSS directives on Windows, using JavaScript. The next sections present the code, and describe the motivation behind this solution.
Code
All the code is standard JavaScript, except for $(window).load, which is jQuery's way of hooking into the onload DOM event. Replace that with your framework's specific method, if you're not using jQuery.
Motivation
I got bug reports stating that some fonts I chose look horrible on Windows. I looked into the problem, and saw that most downloaded fonts look much worse on Windows than on the other OSes. While playing with font choices, I also noticed that default fonts look decent, and I concluded that I shouldn't be downloading fonts via @font-face on Windows.
I didn't want to degrade the experience for all my other users, so taking out the @font-face directives from CSS was out of the question. Because of the way that Rails handles CSS optimizations, I couldn't produce a different CSS stylesheet just for Windows clients, so I decided to remove the @font-face directives in JavaScript.
Conclusion
The JavaScript above can be dropped into any Web application that uses @font-face, regardless of server-side language or framework, and it will make life better for Windows users. However, because it is JavaScript, Windows users may notice a viewport re-paint while JavaScript changes the page's stylesheet. This will only happen on the first visit to the site, as long as your Web application serves correct caching headers for the JavaScript and CSS.
The code is also very bad programming practice. It is entirely possible that Windows 2020 will have better font rendering, or that browser providers will take matters into their own hands. If that happens, you will have to do feature detection on the font rendering engine.
Thank you for reading this far! I hope that you have found the post useful, and I'm looking forward to your questions and suggestions for improvements!
Tuesday, February 8, 2011
Sunday, August 15, 2010
Helper Testing in Rails 3
This post shows how to test both simple and complicated testers in Rails 3. The method outlined here should work in Rails 2.3 as well, but it might not be the best method.
Summary
The skeleton helper testcase class generated by Rails 3 inherits from ActionView::TestCase. Simple helpers can be tested by comparing their return value with a golden string. For more complex helpers, use render :text to fill the view state with the helper return value, then use assert_select. assert_tag doesn't work.
Simple Helpers
Helpers that produce a single tag, or a string, are probably best tested simply by comparing their output with an expected value. Helpers can be called directly from the test class, as inheriting from ActionView::TestCase will set up an appropriate test environment, which includes a mock controller if necessary.
The code listing below demonstrates this.
Complex Helpers
To me, canonical example of a complex helper is one that includes a call to form_tag or form_for. These methods produce a div inside the form tag, and the contents of the div has been very brittle during Rails 3 development, mostly due to the snowman debate. A test shouldn't depend on the div contents, if all that matters is that there's a form in the helper's output.
Summary
The skeleton helper testcase class generated by Rails 3 inherits from ActionView::TestCase. Simple helpers can be tested by comparing their return value with a golden string. For more complex helpers, use render :text to fill the view state with the helper return value, then use assert_select. assert_tag doesn't work.
Simple Helpers
Helpers that produce a single tag, or a string, are probably best tested simply by comparing their output with an expected value. Helpers can be called directly from the test class, as inheriting from ActionView::TestCase will set up an appropriate test environment, which includes a mock controller if necessary.
The code listing below demonstrates this.
Complex Helpers
To me, canonical example of a complex helper is one that includes a call to form_tag or form_for. These methods produce a div inside the form tag, and the contents of the div has been very brittle during Rails 3 development, mostly due to the snowman debate. A test shouldn't depend on the div contents, if all that matters is that there's a form in the helper's output.
Monday, August 9, 2010
Replicating GitHub's Repository Serving Setup
This post describes my approach to replicating GitHub's awesome setup for hosting SSH repositories. GitHub's engineers already outlined the main ideas in their blog, so this post fills in the details by going over all the little roadblocks that I've stumbled on, and explaining the solutions I adopted for each of them.
Assumptions
GitHub allows you to create a git repository via a Web interface, then interact with the repository using a few protocols. I focused on git+ssh, because it's the only protocol that allows pushing to repositories.
I assume that the Git server is a Linux box, and I tested my work on Ubuntu. The setup will most likely require changes for MacOS. I use the already-available infrastructure, such as git and ssh. On Debian, you should have the git-core and openssh-server packages installed.
I assume you're not willing to change the OpenSSH server configuration, as you want to stick to the secure defaults on your production infrastructure.
My Web application is written in Ruby on Rails, and it uses the grit gem, also written by the GitHub engineers. While the code is specific to this technology, most of the article is relevant outside the Rails world.
To avoid edge cases in putting together shell commands, I assume repositories and Web users have very sane names (only letters, digits, underscores).
The code for this article is available here (GitHub). All the code links in this article reference a particular tree, so that the code would match the writing. Future revisions are available in the same repository, but they may be more optimized and harder to follow.
Big Picture
A GitHub blog post describes their SSH serving architecture (section Tracing a SSH Request). Scaling aside, these are the main components:
I use this script to set up the git user. The script accepts any user name, but to keep it simple, I'll use git in this article. The script's effects are undone by this script, which I won't cover here.
I don't expect that the Web application will run under the git account, so instead I set the git user's primary group to be the same as a group on the Web application's account. I assume that the Web application will run under its own user, and nothing else will use that user and group. It's also possible to create a git group, and add the Web application to it. What matters is that the Web application can write to the git user's home directory.
The git repositories are stored in the repos directory, under git's homedir. The repos directory must be writable by the Web application, so its permission bits are 770 (rwxrwx---).
Recent versions of sshd are very strict with the permissions on authorized_keys. I appease them by setting the git home directory bits to 750 (rwxr-x---), setting .ssh's bits to 700 (rwx------), and setting .ssh/authorized_keys bits to 600 (rw-------). So the Web application will not be able to change authorized_keys directly, which is a problem, since I'd like to manage authorized SSH keys in the Web application.
To compensate for the issue above, I create an install_keys setuid executable in git's homedir that overwrites authorized_keys with the contents of repos/.ssh_keys. Due to the setup above, only the Web application should be able to write to this file. Furthermore, install_keys's bits are 750 (rwxr-x---), so it can only be run by the Web application.
I encountered two more minor but annoying issues. install_keys cannot be a script, because the setuid flag doesn't work for scripts with shebang lines. My setup script writes out a C program and runs gcc to obtain a binary. The setuid bit is lost when a file is chowned, so chmod must be called after chown.
SSH Configuration and Integration
authorized_key has one line for each key. The code that generates the lines is here. I used all the options I could find to lock down git's shell. The command line points to a shell script in my Rails application, and passes the key's ID as an argument, so I can identify the Web application user.
My keys are standard Rails models, and I use the after_save and after_destroy ActiveRecord callbacks to keep authorized_keys in sync with the database. More specifically, for each key addition or modification, I re-generate the contents of authorized_keys, write it to /home/git/repos/.ssh_keys and then run install_keys to get the actual file modified. If response time becomes an issue, I can move this process to a background work queue.
git's restricted shell script (stub here, real code here, test here) is stored in my Rails application, for my development convenience. Once the implementation is crystallized, it could be moved in git's home directory, so the git user doesn't need read access to the Web application's directory. The script performs the following steps:
Web Application and Testing Considerations
An application user is modeled by a Profile, and a git repo is represented by a Repository. Both models use ActiveRecord callbacks to synchronize on-disk state: profiles correspond to directories under repos/ (sync code here) and repositories correspond to bare Git repositories created by grit (sync code here). The callbacks are slightly more complicated than for SSH keys, because I need the old name when a profile or repository's name changes, in order to rename the corresponding directory.
Unit tests stub out the methods that compute the path to repos/ (code here and here), so they can run without a full setup. This is desirable so I can get CI running later. I also have a giant integration test (code) that runs all the code described in this article. Since it creates a new user, it requires sudo access, which makes it unlikely that I'll ever be able to set up CI for it.
A particularly challenging for the integration test was pointing git to a SSH key to be used when pushing and pulling. Git doesn't take a command-line argument, and the easiest solution I found was to override the ssh command used by git with a custom wrapper (wrapper-generating code) that contains the options I need to point to a custom key. Overriding is achieved by setting the GIT_SSH environment variable (code). Also, the permission bits on the key file must be set to 600 (rw-------), otherwise ssh will ignore the key.
Motivation
I find GitHub's setup to be awesome, and I always wanted to have my own server implementation to play with. Since I read the team's blog post on how to do it, I wanted to give it a try. When I finally found the time, my experience was rewarding, but also frustrating. POSIX permission bits are limiting, and working around them is non-trivial, at least for me.
Conclusion
I hope you found this post useful, or at least interesting. I look forward to your comments and suggestions for simplifying the setup, or improving its security!
Assumptions
GitHub allows you to create a git repository via a Web interface, then interact with the repository using a few protocols. I focused on git+ssh, because it's the only protocol that allows pushing to repositories.
I assume that the Git server is a Linux box, and I tested my work on Ubuntu. The setup will most likely require changes for MacOS. I use the already-available infrastructure, such as git and ssh. On Debian, you should have the git-core and openssh-server packages installed.
I assume you're not willing to change the OpenSSH server configuration, as you want to stick to the secure defaults on your production infrastructure.
My Web application is written in Ruby on Rails, and it uses the grit gem, also written by the GitHub engineers. While the code is specific to this technology, most of the article is relevant outside the Rails world.
To avoid edge cases in putting together shell commands, I assume repositories and Web users have very sane names (only letters, digits, underscores).
The code for this article is available here (GitHub). All the code links in this article reference a particular tree, so that the code would match the writing. Future revisions are available in the same repository, but they may be more optimized and harder to follow.
Big Picture
A GitHub blog post describes their SSH serving architecture (section Tracing a SSH Request). Scaling aside, these are the main components:
- the server has a git user; git pushes and pulls get processed under that user account
- authorized_keys (the sshd configuration) for the git user contains all the public SSH keys in the Web application (GitHub modified openssh to query a database, since their authorized_keys would have been huge)
- authorized_keys also sets up sshd to run a restricted shell instead of the user's normal login shell (git provides git-shell for this purpose), so users can't use the git account to get shell access on the server
- sshd is not pointed to git-shell directly; instead, a proprietary wrapper checks that the SSH key's owner is allowed to access the repository and, if the operation succeeds, flushes or updates any Web application caches associated with the modified repository
I use this script to set up the git user. The script accepts any user name, but to keep it simple, I'll use git in this article. The script's effects are undone by this script, which I won't cover here.
I don't expect that the Web application will run under the git account, so instead I set the git user's primary group to be the same as a group on the Web application's account. I assume that the Web application will run under its own user, and nothing else will use that user and group. It's also possible to create a git group, and add the Web application to it. What matters is that the Web application can write to the git user's home directory.
The git repositories are stored in the repos directory, under git's homedir. The repos directory must be writable by the Web application, so its permission bits are 770 (rwxrwx---).
Recent versions of sshd are very strict with the permissions on authorized_keys. I appease them by setting the git home directory bits to 750 (rwxr-x---), setting .ssh's bits to 700 (rwx------), and setting .ssh/authorized_keys bits to 600 (rw-------). So the Web application will not be able to change authorized_keys directly, which is a problem, since I'd like to manage authorized SSH keys in the Web application.
To compensate for the issue above, I create an install_keys setuid executable in git's homedir that overwrites authorized_keys with the contents of repos/.ssh_keys. Due to the setup above, only the Web application should be able to write to this file. Furthermore, install_keys's bits are 750 (rwxr-x---), so it can only be run by the Web application.
I encountered two more minor but annoying issues. install_keys cannot be a script, because the setuid flag doesn't work for scripts with shebang lines. My setup script writes out a C program and runs gcc to obtain a binary. The setuid bit is lost when a file is chowned, so chmod must be called after chown.
SSH Configuration and Integration
authorized_key has one line for each key. The code that generates the lines is here. I used all the options I could find to lock down git's shell. The command line points to a shell script in my Rails application, and passes the key's ID as an argument, so I can identify the Web application user.
My keys are standard Rails models, and I use the after_save and after_destroy ActiveRecord callbacks to keep authorized_keys in sync with the database. More specifically, for each key addition or modification, I re-generate the contents of authorized_keys, write it to /home/git/repos/.ssh_keys and then run install_keys to get the actual file modified. If response time becomes an issue, I can move this process to a background work queue.
git's restricted shell script (stub here, real code here, test here) is stored in my Rails application, for my development convenience. Once the implementation is crystallized, it could be moved in git's home directory, so the git user doesn't need read access to the Web application's directory. The script performs the following steps:
- parses the command line to extract the git command to be executed, the repository path, and the key ID
- checks that the git command line matches the list of allowed commands, and determines whether the command does a pull or a push
- issues a HTTP request against the Web application to check whether the SSH key's owner has permission to pull or push to the repository
- runs the git command, prefixing the repository path with repos/
- if the command succeeds, pings the Web application so it can update its caches
- relays the git command's exit code
Web Application and Testing Considerations
An application user is modeled by a Profile, and a git repo is represented by a Repository. Both models use ActiveRecord callbacks to synchronize on-disk state: profiles correspond to directories under repos/ (sync code here) and repositories correspond to bare Git repositories created by grit (sync code here). The callbacks are slightly more complicated than for SSH keys, because I need the old name when a profile or repository's name changes, in order to rename the corresponding directory.
Unit tests stub out the methods that compute the path to repos/ (code here and here), so they can run without a full setup. This is desirable so I can get CI running later. I also have a giant integration test (code) that runs all the code described in this article. Since it creates a new user, it requires sudo access, which makes it unlikely that I'll ever be able to set up CI for it.
A particularly challenging for the integration test was pointing git to a SSH key to be used when pushing and pulling. Git doesn't take a command-line argument, and the easiest solution I found was to override the ssh command used by git with a custom wrapper (wrapper-generating code) that contains the options I need to point to a custom key. Overriding is achieved by setting the GIT_SSH environment variable (code). Also, the permission bits on the key file must be set to 600 (rw-------), otherwise ssh will ignore the key.
Motivation
I find GitHub's setup to be awesome, and I always wanted to have my own server implementation to play with. Since I read the team's blog post on how to do it, I wanted to give it a try. When I finally found the time, my experience was rewarding, but also frustrating. POSIX permission bits are limiting, and working around them is non-trivial, at least for me.
Conclusion
I hope you found this post useful, or at least interesting. I look forward to your comments and suggestions for simplifying the setup, or improving its security!
Thursday, May 6, 2010
URLs for Kindle Software Updates
This post contains links to the files needed for manually updating the firmware on Amazon Kindles.
Amazon replaced the previously useful Kindle Software Update page with an announcement for the 2.5 firmware which will be released in the future. In the process, they removed the download links for manual firmware upgrades.
I'm mostly putting up these links for my own reference, but maybe they will help others as well.
- Kindle 1: http://s3.amazonaws.com/G7G_FirmwareUpdates_WebDownloads/Update_kindle_1.2.bin
- Kindle 2: http://www.amazon.com/update_kindle2.bin
- Kindle DX: http://www.amazon.com/update_kindle_dx.bin
Amazon replaced the previously useful Kindle Software Update page with an announcement for the 2.5 firmware which will be released in the future. In the process, they removed the download links for manual firmware upgrades.
I'm mostly putting up these links for my own reference, but maybe they will help others as well.
Thursday, April 29, 2010
Ubuntu 10.04 on Mac Mini
This post describes a short procedure for installing Ubuntu 10.04 on a Mac mini. The instructions were initially written (and should still work) for older Ubuntu versions, down to 8.10. However, I haven't tested the old versions for a long time.
The process is roughly the same as my previous instructions for Ubuntu 8.04, but the write-up is more detailed to address the questions I have received last time. So don't the post length scare you!
The process is roughly the same as my previous instructions for Ubuntu 8.04, but the write-up is more detailed to address the questions I have received last time. So don't the post length scare you!
Outline
The article starts with a warning describing the shortcomings of installing Ubuntu on the newest Mac Mini model. That is followed by a step-by-step guide for installing Ubuntu which should work on any Mac (tested only on Minis though). The post ends with instructions on how to restore your dual-boot solution if Mac updates break it, and a list of (community-contributed) tricks for getting some hardware to work on the latest Mini.
Warning (skip if you're sure you want Ubuntu)
Ubuntu will not work seamlessly on the new Mac mini (model MacMini3,1 with 5 USB ports). This is based on the release version of Ubuntu 10.04.
Wireless does not work right after installation, so Ethernet is needed, at least for bootstrapping. Once the system gains Internet access, it offers to install a Broadcom STA wireless driver which offers good performance. Grub 2 will get stuck and not show the boot menu about one times in five. This is uncomfortable if you're planning to use your Mini as a server that sits somewhere far away. For desktop usage, you'll probably want to install the nVidia proprietary drivers. On the open-source nouveau drivers, my screen doesn't get recognized when using mini-Display Port, but it works reasonably well when connected via the mini-DVI port. Sound doesn't work out of the box, and you'll need to hack your configuration files to get it to work (see below).
Method
Getting Hardware to Work (community-contributed)
Warning (skip if you're sure you want Ubuntu)
Ubuntu will not work seamlessly on the new Mac mini (model MacMini3,1 with 5 USB ports). This is based on the release version of Ubuntu 10.04.
Wireless does not work right after installation, so Ethernet is needed, at least for bootstrapping. Once the system gains Internet access, it offers to install a Broadcom STA wireless driver which offers good performance. Grub 2 will get stuck and not show the boot menu about one times in five. This is uncomfortable if you're planning to use your Mini as a server that sits somewhere far away. For desktop usage, you'll probably want to install the nVidia proprietary drivers. On the open-source nouveau drivers, my screen doesn't get recognized when using mini-Display Port, but it works reasonably well when connected via the mini-DVI port. Sound doesn't work out of the box, and you'll need to hack your configuration files to get it to work (see below).
Method
- Use a Leopard or Snow Leopard (Desktop or Server) install disc to get your Mac in pristine form. This step is intended to undo anything that might have gone wrong in your previous attempts. You can skip it if you have a fresh install.
- Use Software Update to ensure you have all your updates installed. Update and reboot until there are no updates left.
- Start up Boot Camp Assistant (press Apple+Space to open Spotlight, then start typing the name until the application appears) and create a "Windows" partition.
- Do not let Boot Camp Assistant reboot your computer. Use Apple+Q to quit once it's done partitioning.
- Download and install the latest version of rEFIt (0.14 at the time of this writing) from http://refit.sourceforge.net/
- Open up Terminal (use Spotlight if you don't have it on your dock) and type the following commands:
cd /efi/refit
./enable-always.sh - Insert your Ubuntu CD, and shut down the computer, then power it back up.
- You should see the rEFIt boot screen.
- Select the Ubuntu CD (it should have a penguin on it) and go through the normal installation process. If rEFIt doesn't recognize the Ubuntu CD, power-cycle your Mac, and use Bootcamp to boot the Ubuntu CD - press and hold the Alt key as soon as the computer starts up, until the BootCamp screen shows up; select the CD image.
- When you have to do partitioning, choose Manual. Remove the Windows partition (the big FAT32 partition at the end). Create an ext4 partition (be sure to to allow for swap space) and set it to mount to /, then create a swap partition. If you're unfamiliar with partitioning a Linux system, read the recommendations below.
- Click on the FAT32 partition, then click the Delete Partition button.
- Click on the free space entry at the bottom, then click the New partition button. Select Ext4 journaling file system under Use as:, check the Format the partition: box and select / as the Mount point:. Now subtract twice your RAM size from the partition size. For example, if your partition size is 53575 Mb and you have 1Gb of RAM, you would write in 51527, which is 53575 - 2*1024. Press OK when you're done.
- Click on the free space entry at the bottom, then click the New partition button. Select swap area under Use as: then press OK.
- Unless you know what you're doing, do not change the Advanced settings on the last installation screen. Specifically, don't change the default Grub installation location (hd0).
- When the installation is done, the Mac will reboot (if you're lucky) or beep multiple times. If it beeps, turn it off (press the power button for 4 seconds) then turn it back on.
- When you get the rEFIt boot screen, go to Partitioning Tool (bottom row, second icon from the left). It will prompt you if you want to update the MBR to reflect the GPT. Press Y, and watch the system reboot.
- Power down the system by pulling the power cord. Then power up again.
- Select Macintosh HD, and make sure you can boot into OSX. If it doesn't boot after 2 minutes, power cycle (see previous step) again.
- Optionally, switch the boot default to Linux. Open up /efi/refit/refit.conf in TextEdit, and uncomment the line saying #legacyfirst (at the bottom of the file).
- Reboot your Mac mini, and enjoy choice!
- Open up Terminal (use Spotlight if you don't have it on your dock) and type the following commands:
cd /efi/refit
./enable-always.sh
Getting Hardware to Work (community-contributed)
The tips here should help if you want to go beyond Ubuntu's out-of-the-box hardware support. These were contributed by others, and I just put them together on one page.
Sound (by nonspeaking) - not needed after Ubuntu 9.10 Beta
To get the sound working, add the following line to /etc/modprobe.d/alsa-base.conf
options snd-hda-intel model=imac24
Motivation
If you're curious, the following reasons determined me to write this post
Please leave a comment if you find a shorter way, or if something is not working for you.
- My readers commented on my installation method for Ubuntu 8.04, and said it doesn't work for 8.10. Takeaway: please do comment! I listen :)
- I got a new Mac Mini (MB464LL/A, 5 USB ports) to replace the one that was stolen from me.
Please leave a comment if you find a shorter way, or if something is not working for you.
Wednesday, April 21, 2010
Rails 3 Development Setup for Ubuntu
This post describes the steps needed to set up a fresh Ubuntu installation so you can start playing with Rails 3 and contribute to it
Method
This method isn't the most conventional way of developing on Ubuntu (I do replace the Ubuntu-supplied RubyGems binaries, so that I can get the latest version, and get gem binaries on my path). It also is not the most secure method (you will create install a ton of packages and create some random users on your database servers). It's quite fast and effective for development, though.
I have tested the steps below on Ubuntu 10.04 (Lucid Lynx), and I have good reasons to believe that they will work on Ubuntu 9.04 (Karmic Koala) as well.
Start off by installing some Ubuntu packages:
sudo apt-get update; sudo apt-get dist-upgrade
sudo apt-get install ruby rubygems ri ruby-dev libopenssl-ruby build-essential mysql-client mysql-server libmysqlclient-dev postgresql postgresql-client libpq-dev sqlite3 libsqlite3-dev curl git-core git-completion git-doc git-gui
Override Ubuntu's crippled RubyGems with the proper version:
Create the rails user in MySQL:
Create a superuser in PostgreSQL:
Install rvm:
rm /home/$USER/.bashrc; mv /home/$USER/.bashrc2 /home/$USER/bashrc
Install the Rails-preferred VM and create a clean gem set:
Prepare to work on Rails (do this every time you start a shell):
Check out Rails and install its dependencies:
Run the Rails test suite. If it passes, your environment is all set up.
rake # This should be run in the rails directory.
If you want to create a test application, then you should install the gems from the edge Rails:
rake install # This should be run in the rails directory.
Happy hacking!
Motivation
At one of Boston.rb's hackfests, Dan Pickett held a workshop on contributing to Rails 3. I think I was the only one in the room not using OS X, and I had to follow a slightly different sequence of steps to get my setup working. I figured it's nice to summarize all the steps for future reference.
Conclusion
Thank you for reading! I hope the post above has been helpful, and hope you'll have fun playing with Rails 3. I look forward to your comments and suggestions for improving the method outlined here.
Method
This method isn't the most conventional way of developing on Ubuntu (I do replace the Ubuntu-supplied RubyGems binaries, so that I can get the latest version, and get gem binaries on my path). It also is not the most secure method (you will create install a ton of packages and create some random users on your database servers). It's quite fast and effective for development, though.
I have tested the steps below on Ubuntu 10.04 (Lucid Lynx), and I have good reasons to believe that they will work on Ubuntu 9.04 (Karmic Koala) as well.
Start off by installing some Ubuntu packages:
sudo apt-get update; sudo apt-get dist-upgrade
sudo apt-get install ruby rubygems ri ruby-dev libopenssl-ruby build-essential mysql-client mysql-server libmysqlclient-dev postgresql postgresql-client libpq-dev sqlite3 libsqlite3-dev curl git-core git-completion git-doc git-gui
Override Ubuntu's crippled RubyGems with the proper version:
sudo gem install rubygems-update
gem env | grep 'EXECUTABLE DIRECTORY'
sudo `gem env | grep 'EXECUTABLE DIRECTORY' | ruby -e "puts gets.split(': ', 2).last"`/update_rubygemsCreate the rails user in MySQL:
echo "GRANT ALL ON *.* TO 'rails'@'localhost';" | mysql -uroot
Create a superuser in PostgreSQL:
sudo -u postgres createuser --superuser $USER
echo "\\password $USER" | sudo -u postgres psql
Install rvm:
sudo gem install rvm
rvm-install
echo "if [[ -s /home/$USER/.rvm/scripts/rvm ]] ; then source /home/$USER/.rvm/scripts/rvm ; fi" | cat - /home/$USER/.bashrc > /home/$USER/.bashrc2rm /home/$USER/.bashrc; mv /home/$USER/.bashrc2 /home/$USER/bashrc
Install the Rails-preferred VM and create a clean gem set:
rvm install 1.8.7
rvm use 1.8.7
rvm gemset create rails3
rvm gemset use rails3
gem install bundler mocha
Prepare to work on Rails (do this every time you start a shell):
rvm use 1.8.7
rvm gemset use rails3
Check out Rails and install its dependencies:
git clone git://github.com/rails/rails.git
cd rails
bundle install
rake mysql:build_databases
rake postgresql:build_databases
Run the Rails test suite. If it passes, your environment is all set up.
rake # This should be run in the rails directory.
If you want to create a test application, then you should install the gems from the edge Rails:
rake install # This should be run in the rails directory.
Happy hacking!
Motivation
At one of Boston.rb's hackfests, Dan Pickett held a workshop on contributing to Rails 3. I think I was the only one in the room not using OS X, and I had to follow a slightly different sequence of steps to get my setup working. I figured it's nice to summarize all the steps for future reference.
Conclusion
Thank you for reading! I hope the post above has been helpful, and hope you'll have fun playing with Rails 3. I look forward to your comments and suggestions for improving the method outlined here.
Friday, March 12, 2010
Quick Way Out of Ubuntu's Rubygems Jail
This post offers a quick method for overwriting the system-supplied RubyGems binary on Ubuntu (and any other Debian derivative) with a pristine version from the RubyGems authors.
Method
The following commands will do the trick.
After installing the pristine version of RubyGems, you will have to re-install all your gems. This is because Ubuntu/Debian also modifies the path where RubyGems stores its gem data.
Motivation
Debian cripples RubyGems in various ways, to make it fit in with the overall Debian philosophy.
The most unfortunate change is that RubyGems will not update itself automatically, and we have to wait for Debian maintainers to package the updates. Another annoying change is that Debian's RubyGems will not install launcher scripts in /usr/bin, so we cannot use rails or rake by straight-forward gem installation.
While the path problem is easy to fix (sudo echo "PATH=/var/lib/gems/1.8/bin:$PATH" > /etc/profile.d/rubygems1.8.sh), there's no straight-forward solution for getting updated RubyGems. At the time of this writing, bundler (needed by the Rails 3 beta) requires RubyGems 1.3.6, and the version in Debian is 1.3.5.
I hope you have found this post to be useful, and I'm looking forward to your comments and suggestions.
Method
The following commands will do the trick.
sudo apt-get install rubygems-update
sudo /var/lib/gems/1.8/bin/update_rubygems After installing the pristine version of RubyGems, you will have to re-install all your gems. This is because Ubuntu/Debian also modifies the path where RubyGems stores its gem data.
Motivation
Debian cripples RubyGems in various ways, to make it fit in with the overall Debian philosophy.
The most unfortunate change is that RubyGems will not update itself automatically, and we have to wait for Debian maintainers to package the updates. Another annoying change is that Debian's RubyGems will not install launcher scripts in /usr/bin, so we cannot use rails or rake by straight-forward gem installation.
While the path problem is easy to fix (sudo echo "PATH=/var/lib/gems/1.8/bin:$PATH" > /etc/profile.d/rubygems1.8.sh), there's no straight-forward solution for getting updated RubyGems. At the time of this writing, bundler (needed by the Rails 3 beta) requires RubyGems 1.3.6, and the version in Debian is 1.3.5.
I hope you have found this post to be useful, and I'm looking forward to your comments and suggestions.
Subscribe to:
Comments (Atom)