So, developing a Rails App on a PC is usually pretty straightforward. For the most part, my code on a test machine can be upload to a linux server and work fine. Further, most code examples found online also work.

There is only 2 gotchas I’ve found so far, and they both have to do with file uploads.

1. File would be corrupt on Windows

I was using some code I found online to write a file on the server. It was an image file uploaded to the rails server, but when the image displayed on the webpage, it was corrupted. So, how could I get rid of the corrupted image? Here’s the solution from http://wiki.rubyonrails.org/rails/pages/HowtoUploadFiles

Note for Windows: to avoid corrupting binary files, you must call File.open in binary mode. Change the “w” flag to “wb”, like this:

2. File would not always upload on a windows server.

I was raking my brain over this one, but fortunately someone else had already solved it (which so far has been a very common trend in the rails world):

http://www.railsweenie.com/forums/3/topics/1257

It turns out that the file handling in windows is a bit weird, so you just have to wait for it to catch up….

So, how to deal with these in the real world? After all, in development its fine to wait for a second for a file upload, but that is not okay on a production web server….

Well, the way I dealt with it is by using configurations. I have to environment.rb files. One is called environment.online.rb, and the other is environment.rb. This was suggested by my web host. Since it is a shared host, the way a rails app is set to production mode is the flag

ENV['RAILS_ENV'] ||= ‘production’

In environment.online.rb.

When I deploy an app, I just use the .online file by renaming it. This is slightly less than ideal, since it isn’t very DRY (don’t repeat yourself), but since I don’t control the web server on a shared host, I don’t have much choice… Since I have 2 files anyway, I set another flag for myself, in this case I just have the flag:

ON_WINDOWS = false //in envrionment.online.rb

ON_WINDOWS = true //in envrionment.rb

I’m sure that ruby has a way of checking the platform, but this was just easier and quicker…

Every time I go to a Rails meetup, I also get mac-envy… It seems I am one of the few rails develoeprs not using a Mac.

I thought about getting a Mac. In fact, my fiance has one, and I get to borrow it sometimes, but I’ve decided against getting a mac for myself. The reason? The end user experience…

Most of the big rails names use a mac, and most screencasts show textmate in use. Textmate looks very powerful. I thouight about this for a while, but decided to stay with a PC for development. Here’s the list I was weighing:

Benefits of Mac: The rails community seems more mac oriented, apples sense of design should taken on by most web developers, textmate.

Benefits of PC: Most end users of any web app I develop will be using a PC. I need to feel what they feel.

The PC won out. There are some good tools for PC rails development. As I said in my last post, InstantRails is amazing. For editors I’ve used both RoRad & RadRails – preferring RadRails by a fair bit. There are a few ‘gotchas’ to watch out for, which I’ll post in a very short while…

Great, you’ve decided Rails is worth learning, but you are completely new to it. How should you go about it?
Well, I looked back at the path I took, left out the bits that weren’t useful, and re-ordered things the way I think they would have been most useful.
Step 1 – Feel the buzz. You need the wow factor. The rails community has a ‘Show don’t tell’ mentality, so check out these cool and quick screencasts: http://www.rubyonrails.org/screencasts
Excited yet?
<yoda>You will be… You will be…</yoda>
Step 2 –> Next up: The view from 30,000 feet:
- If you are reading this, you may already have this view. But, just in case, here is a good introduction to Ruby On Rails. http://www.onlamp.com/pub/a/onlamp/2005/10/13/what_is_rails.html good overview
Step 3 – Get Amongst It!

Time to make an actual app! You’ll need to set some things up first though. I’m on Windows, so if you are using another environment, this won’t be too much help. You’ll find that a large portion of Rails developers are Mac users, but I think the number of Windows Rails developers will continue to grow. I’ll post more on that later.

Anyway, let’s get moving. You can find a good first tutorial here: http://instantrails.rubyforge.org/tutorial/index.html It is a modified version of another great tutorial, but is set to fit Instant Rails. It is slightly out of date so see some notes below. Instant Rails (http://instantrails.rubyforge.org/wiki/wiki.pl ) is a super awesome one click and you’re done Ruby on rails environment, complete with MySql. Two Notes:

• The tutorial mentions MySQL-Front (no longer available). Get HeidiSQL instead: http://www.heidisql.com/
• The tutorial also talks about webrick server. Instead, mongrel will be running, but that shouldn’t affect the tutorial at all.

Step 4 – Editor

You may also an editor. I’ve tried RoRad, RadRails, and Aptana (which actually bought and integrated RadRails). Aptana is easily the best though it’s constant updates occasionally break things for me, and some of the configuration options aren’t intuitive. You can get Aptana here: http://www.aptana.com/download_rails_rdt.php (follow the instructions on the right)

Step 5 – More In Depth:

So now you should understand the high level view of rails, and have made your first app.  Make a more fully featured app by following the 4 Days on Rails tutorial here:

http://rails.homelinux.org/ A good second tutorial

The next step is to buy, read, and follow the book Agile Web Development On Rails http://www.pragmaticprogrammer.com/title/rails/ This is a great resource and definitely worth the money.

I’ll post more about other resources soon, but that should be enough to get people started.

So, why did I choose Ruby On Rails?  Well, it’s all the love mostly.

I don’t come from a web development background.  I come from a windows client development background.  When I wanted to learn about web programming, I starting reading various blogs, talking to friends, and reading up on things.  There was a lot of buzz around rails, and some amazing claims (like 10x faster development).  And while you really don’t get 10x faster development, you do essentially get to start working on the real problem right away, rather than building up the infrastructure needed to do so.

That’s what Rails really is, a well thought our framework for developing web apps extracted from real world experience.  If you need to learn more about what it is, check this out:

http://en.wikipedia.org/wiki/Ruby_on_Rails

http://www.rubyonrails.org/

If you are starting a new project, or are new to web programming, I strongly recommend you start with Rails.  I’m very glad I did.  Rails constricts you to a set MVS (model, view, controller) framework but that constraint lets you focus on the real problem you are trying to solve.

The Top Reasons to Start On Rails:

-          It’s easy to learn! 

-          There are lots of resources to learn (books, blogs, online articles and tutorials)

-          It’s a good community. (Lots of plugins and gems make almost everything you want to do very easy)

-          You can develop real applications in a short amount of time.

The biggest complaints I’ve Heard Against rails

-          It’s slow (true, it’s slower than php, but the mantra is, hardware is cheaper than programmer time!. There are some major sites running on rails (like twitter.com).  No matter what technology you choose you are going to hit scalability and speed issues at some point, so the architecture is more important than the technology.

-          Okay – that’s about the only complaint I’ve heard.

For my application, I also considered .Net, PHP Cake, and perl.  They all had pros and cons. PHP Cake was the runner up, but it just didn’t’ seem as mature as Rails, nor did it have the same buzz.

So far, while learning Ruby On Rails, I’ve found about 95% of what I want to know through google.  The Rails community rocks like that.  But hey, the world could always use some more information right? This blog will go over the paths I have taken, and will continue to take while moving from rails beginner to a more experienced rails developer.  The way I see it is this - I’ve learned a lot just by googling, but there are still lots of those moments where I come to a realization and wish I had known about it earlier. Hindsight is always 20/20, but hopefully some bits of my hindsight can be used as someone else’s foresight… I’ll be posting about the following:

• What tools/resources I found useful (and what ones I did not)
• Commentary and looks back on the order I ended up learning things (with as many of the ‘I wish I had…’ thoughts as possible)
• Answers to problems that I couldn’t’ find on google so I had to figure them out myself…
• Good design practices (both rails backend as well as CSS, usability, and anything else come across)

 My goal with this blog is to share my experience learning rails, learning ruby (which I’m sure a lot of rails newcomers will be doing at the same time as they are learning rails)…