Ruby Off the Rails

Ruby off the rails

One of the huge benefits of Ruby is the ability to create DSLs very easily. Ruby allows you to create "business rules" in a natural language way that is usually easy enough for a business analyst to use. Many Ruby apps outside of web development exist for this purpose.

I highly recommend Googling "ruby dsl" for some excellent reading, but I would like to leave you with one post in particular. Russ Olsen wrote a two part blog post on DSLs. I saw him give a presentation on DSLs and it was very good. I highly recommend reading these posts.

I also found this excellent presentation on Ruby DSLs by Obie Fernandez. Highly recommended reading!

Ruby (off the Rails) Hosting

First, if you want lightweight, Sinatra is usually my first pick. Pair it up with rack and Passenger for best results. It's not CGI, but realistically speaking, CGI is rarely a good match-up with Ruby.

Here's the "Hello World!" Sinatra app from the main page:

require 'rubygems'
require 'sinatra'
get '/hi' do
  "Hello World!"
end

Hard to get more lightweight than that.

As for providers, anybody that supports Passenger (mod_rack) should be able to handle Sinatra. I'm a big fan of Slicehost personally, but they're a VPS host, which means you need to be able to install and manage the entire stack yourself. If you don't mind paying a tiny bit extra for the infrastructure, Heroku makes installation and deployment dead simple, so long as your needs don't exceed what they provide (sounds like they won't). In the unlikely event that you're only using 5MB or if you're using an external storage mechanism like Amazon RDS, Heroku may actually be free for you.

Update:

Passenger is an Apache module that allows Rack applications to be run inside of Apache.
Rack is a middleware layer that separates the web server and the web framework from each other. This allows web frameworks to run on any web server for which there is an adapter.
Sinatra is a lightweight web framework that runs on top of Rack.

Once Passenger and Rack are installed (gem install rack, gem install passenger) you just need to edit the Apache vhost to point at the config.ru file for your Sinatra app and create the required directories as per the Passenger docs and you'll be good to go.

what is ruby used for BESIDES rails?

Firstly, PHP was built to be a server language, first and foremost. That's one of the primary reasons it's not usually used for anything other than web applications - it's not designed for it and therefore can't match up to the requirements of, say, a scripted desktop application.

Ruby was designed as a general-purpose scripting language, and thus has a wide support for a number of different applications. It has been used across the board for everything from web applications, to web servers themselves, to intelligent graphing libraries, to picture recognition engines, to threaded database servers, to low-level system utilities. It has a wide spectrum of use throughout computing.

Rails has most certainly boosted the popularity of Ruby by a huge amount, brought it up into the forefront of scripting languages, spawning 40+ books, 18 conferences, distribution with nearly all the major operating systems and 7 different implementations to boot!

To begin with, all of Rails' internals are written in Ruby itself, but all of the Rubygems, libraries, snippets or anything else that is used by Rails developers is written in Ruby too, and is most likely built to work outside of the Rails stack.

Having said that, the popular web framework is not the reason why Ruby is popular. Sure, it has helped bring much-needed attention to the language, but it's not the reason why people use it day to day. It's used for everything from web applications to desktop GUI applications because of it's simple, elegant syntax, it's clean, sensible and complete standard library, it's wide ecosystem of community code, support and toolchains.

Ruby is used because it rocks.

Ruby without Rails

How can I build GUI applications with it?

It's possible to use GTK with it?

Where to download?

Pros and cons of Ruby compared to Perl and Python?

Where to be updated with the lastest news (podcasts and blogs) of the Ruby world?

I hope you realize what the problem is with your post.

How is the market of Ruby (without Rails) today?

Ruby isn't that widespread in the professional world even with Rails being considered. Outside of Rails it's going to be rather tough to get a position using it.

Ruby off Rails FactoryGirl ArgumentError: wrong number of args (0 for 1)

I believe the issue is with your player model requiring an argument at initialization.

Try this instead:

class Player
  attr_accessor :name

  def initialize(options={})
    @name = options[:name]
  end
end

When FactoryGirl initializes the model, it will initialize with a nil name attribute like this:

1.9.3p448 :013 > Player.new
#<Player:0x000000017acff0 @name=nil>

You can then define the name as you intend in your commented out line. This will also allow you to initialize a Player with a hash like:

1.9.3p448 :012 > Player.new(name: "something")
#<Player:0x00000003b53008 @name="something">

Database Changes Outside Ruby/Rails Migration

I can tell you from experience that this is not the best idea, one that you will eventually regret and later, inevitably, reverse. But I know that it does come up. I've had to do them (against my will or in case of extreme emergencies).

Given the option, I'd push back on it if you can in favor of any solution that bring the SQL closer to the repository and further away from a "quick fix" to the database directly. Why?

1) Your local/testing/staging/production databases will diverge, eventually rendering your code untestable in a reliable way

2) You won't be able to regenerate your database from "scratch" to match production

3) If the database is ever clobbered, you won't be able to re-create it in any sensible way.

DBA's generally don't care about these things until something in the code breaks, and they want you to figure it out. But, for obvious reasons, that now becomes quite difficult.

One approach I have taken that seems to make everyone happy is to do the following:

1) Commit to having ALL database changes, big or small, put into a repository with the code. This means that everything that has happened to the database is all together in one place.

2) Each change, or set of changes, should be a migration. A migration can be simply running an SQL file. But, it should be run from within a migration for all the testability benefits.

So, for example, let's say you have a folder structure like:


- database_updates
-- v1
--- change_1.sql
--- change_2.sql
-- v2
--- change_3.sql
--- change_2_fix.sql

Now, let say you want to make a change or set of change via SQL. First, create a new version folder, let's call it "v1". Next, put your SQL scripts in this folder. Finally, create a migration:

def change
  # Read all files in v1 folder, and run the SQL
end

(I have code that does this, happy to share the gist if you find yourself using this approach)

Since each migration is transactional, any of the scripts that fail will cause all of them to fail.

Now, let's say you have the next set, v2. Same exact thing. And, we have a history of these "versioned" changes, so we can look at the migration history and see what's been run, etc.

As a power user note, this set up also allows for recourse if things fail; in these cases, we can opt to go back to v1:

def up
  # run v2 scripts
end

def down
  # run v1 scripts
end

For this to work, v1 and v2 would need to be autonomous -- that is, they can destroy and rebuild entities without any dependencies. If that's not what you want, just stick with the change method.

This would also allow you to test for breaking changes. Let's say it is reported that something doesn't work anymore with v6. You can rollback your database migrations to v5, v4, etc (because you are doing a migration per folder) and test to see when the test broke, and correct it with v7.

Anyway, the end game of it all is that you can safely check out this project from a repository, create your database, run rake db:migrate and know that your database structure resembles exactly what is deployed elsewhere. And, worst case, if your database gets clobbered, you can just run all your scripts from v1 - vN and end up with your database back again.

For DBA's everything remains SQL for them, they can just send you a file or set of files for you to run.

If you want to get fancy, you could even write a migration generator that knows how to handle a line like rails g migration UpdateDBVersion version:v7 to take care of the repetitive boilerplate.

Can the delayed_job gem be used outside of Rails?

I don't know why this person never posted this.

It's easy. Two steps:

http://brkrd.com/post/45269754283/delayed-job-without-rails

UPDATE Looks like the link is broken.

You will need Active Record, but not Rails. You will have to mock a Rails object, and load your database information, environment, and root into the Rails object so that DelayedJob thinks it's in the Rails environment.

Rails-way to execute one-off task on Rails server startup

Can be achieved with Foreman by running in the same process as daemonized task (e.g. with rails server).

If one-off taks is rake lego:update_all

Then corresponding Procfile is

web: rake lego:update_all && rails s
sidekiq: bundle exec sidekiq