In the last three entries in this series, we talked about the various technologies involved in Rails development, and walked through the installation of Ruby, Rails and MySQL. If you’re keeping score, there are still two files left in the list of downloads that we haven’t touched, and we’ll focus on those two now.
ImageMagick is the de facto standard in web-based image-handling, and there’s a very nice toolset written for Ruby called RMagick (download the ImageMagick/RMagick for Windows installer here) which allows us to use it in our Rails applications. Unfortunately, some incompatibility issues with Windows and the latest ImageMagick builds have caused the RMagick installation process to be a bit non-standard. We’ll go through the steps together now and see if we can’t muddle our way through it.
The ImageMagick installation process is simple enough, just leave everything at the defaults and let it install itself. Pay attention to the dialog right after the program files are copied over though. It should say something like this:
You have now installed ImageMagick. To test the installation select Command Prompt from the Windows Start menu. Within the window type:
convert logo: logo.miff
imdisplay logo.miffand the ImageMagick logo should be displayed in a window.
Do that now and see what happens. You should have an image like the one below appear on your desktop.
Now that we’ve confirmed that ImageMagick is working, we’ll need to install the RMagick gem to allow Rails to communicate with the ImageMagick engine. Ordinarily, all we would need to do would be to type “gem install rmagick” and the code would automatically be downloaded for us, but because of the Windows issues, we’ll have to use the provided gem in the installation pack we downloaded. (Don’t try the regular gem-installation method; it won’t work.)
Through the command prompt, navigate to the folder where you unzipped the various files inside the RMagick download. Type the gem install command with the “–local” switch (yup, that’s a double-dash) to tell RubyGems that you don’t want it to look for the gem in the remote repository.
gem install rmagick –local
After you press Enter, you should receive this response:
Successfully installed rmagick, version 1.14.1
Assuming you made it this far without any problems, you have just hurdled an installation issue that has driven several of us at syndeo::media partially insane. If you hit a problem though, you’ll want to check out the README.html document included in the package for troubleshooting ideas. (In case you’re thinking of reinstalling ImageMagick/Rmagick, you’ll need to pay extra attention to the uninstallation procedure, it’s also rather non-standard.)
The last step on our Rails installation is getting our subversion client up and running. Strictly speaking, svn isn’t required to start developing Rails applications, but it’s such a standard part of every developer’s toolkit, that it’s almost a no-brainer to include in this tutorial. (Also, if you’re reading this series as a new member of syndeo::media, all of our projects are managed via svn, so for us, at least, it’s a definite requirement.)
Because we’re using the TortoiseSVN client, installation should be fairly simple (the default values should suffice for most uses). The singular advantage of having Windows’ one-click installers is that you never have to compile anything. The disadvantage of course, is that it’s Windows :)
TortoiseSVN will ask you to restart your machine after it’s been installed, so let’s take this opportunity to familiarize ourselves with how version-control (and svn in particular) works.
=============
A Bit About Subversion
As we talked about in the first part of this series, version-control systems work by saving every single version of every file on a given application. In theory this means that your work will never be lost, even when another programmer comes along and rewrites the whole file you were working on. In practice, however, the usefulness of svn is dependent on how diligent you are when using it.
Let’s say we have a simple website, with only a single file index.html, to start off with. This file doesn’t yet exist on our local machine because someone else created it and has saved its Revision 0 on the company’s subversion repository. How do we grab a copy?
From the commandline, we would ordinarily type “svn co http://path/to/repository newfolder“. This tells subversion to “check-out” (co) all the files from the given http://path/to/repository. Most repositories will be protected by a username/password combo, so you will then need to type in the user information assigned to you. Once you’ve done that, svn will download the necessary files to new-folder. (You don’t need to create this folder beforehand, svn will do it for you.)
You will now have a working copy of everything related to your project (in this case, we’re assuming there’s only one file at the moment). Now let’s say that you edited index.html, and now want to send your changes back to the repository for safe-keeping.
There are two steps you would want to take. First, you’d need to navigate to new-folder, and type “svn up“. This command checks the repo for any updates to the code base while you were busy working offline. If someone else worked on index.html and committed it to the repository before you did, those changes will be downloaded and svn will attempt to merge it with your changes. If it can’t, it will trigger a Conflict. We’ll talk about handling conflicts later, but for now let’s assume everything was merged without issue.
Your next step will be to type “svn ci -m ‘message explaining your changes’“. CI is the svn command for check-in, in other words you are going to be sending your version of the code back to the server. The -m switch is for adding a brief message to inform your co-workers what exactly you were working on. This doesn’t have to be very verbose; even a simple “fixed header title” message will do. Once you hit Enter, your files will be uploaded automatically.
Now let’s say that you worked on your file some more after checking it in, and have decided to check in one more time. However, this time, you ran “svn up” and received a Conflict alert. Not only that but when you look at your project folder, you now have a lot of weird-looking filenames floating around, like this:
index.html
index.html.mine
index.html.r002
This is subversion’s approach to conflict resolution. index.html.mine is the file holding all your latest changes, and index.html.r002 is the file holding the latest changes someone else checked in. The original index.html is a combination of both versions, and it will look something like this:
<html><head><title>Project Index</title></head>
<body><<<<<<<<<.mine
<h1>Test Project Name</h1>
=======>>>>>>>>>.r002
<h1>Real Project Name</h1>
=======
The bold lines are svn’s attempt to show you where the differences in your code are. What you need to do is figure out which of the two versions you want to keep, your “Test Project Name” line, or the “Real Project Name” line. Let’s say you wanted to keep your version. All you’d need to do is delete the extra lines that svn inserted. Then on the commandline, you’d type “svn resolved index.html“. The other versions of the file that svn generated will automatically be removed. Now all that’s left for you to do is check in your corrected version, possibly with a message explaining why you chose “Test Project Name” over “Real Project Name.”
Now let’s say you decided that you’re ready to start expanding the website and adding some new pages. You create a page called about.html, saving it in the same directory as index.html. How do you let subversion know that this file needs to be checked in as well? Just type “svn add about.html” right before doing a check-in, and the new file will be committed to the repo along with everything else in the folder.
Does that sound like a whole lot of typing? The good news is that TortoiseSVN removes nearly all of the typing involved with version-control, and integrates directly into Windows Explorer. Most of the functionality explained above is only a right-click away. It’s important that you appreciate what’s going on first though, as a lot of people forget that svn can be just as easy to use from the command-line as from a GUI as long as you understand the rules.
IMPORTANT NOTE: If you installed just TortoiseSVN, the svn commands above will not work. You’ll need to get the barebones command-line version of svn from this page.
=============
Now that you’ve got all of this stuff installed, what’s the next step? syndeo::media team members will want to download some of the applications we’ve been working (mobiuslive is a good first step) and get it working on their local machine. For everyone else, it’s time to start learning Rails!
Quick links to other articles in this series:
PART ONE: Introduction to Ruby, Rails, MySQL and Subversion.
PART TWO: Ruby Installation and Language Primer.
PART THREE: Rails, MySQL and the Windows Command Prompt.
PART FOUR: RMagick and Subversion.