• What is a Ruby gem?
• Gems vs. Plugins vs. Engines vs. Realties
• Create your first gem
• Use gem in Rails application
• Test gem
• Build a new version of gem
• Gems to build your own gem
• References

What is a Ruby gem?

A gem is a ruby library in a self-contained format.

The gems are handled by RubyGems, which is a package manager for Ruby that provides a standard format for distributing the gems. As of ruby 1.9 RubyGems comes with Ruby.

Someone can write their own library and then package it as a gem file so that it can be used in any Rails application. Another programmer can install and access its functionality as any other known gems (gem install mygem).

It means that a gem is a generic library, which can be easily installed, which are version-managed, have dependencies.

Gems vs. Plugins vs. Engines vs. Realties

Gems and Plugins:

- Gems and Plugins are identical in terms of the code and function you actually write, therefore creating a gem is often referred to as “packaging” something as a gem.

- Gems are version-managed, have dependencies. Gems can be easily installed.

- Gems are platform independent, which means you can use them in any Ruby environment (such as Rails or Sinatra)

- Plugins are Rails-only and you can’t manage or version them.

Rails has a plugin system where you type “script/plugin install <plugin-name>” but packaging it up as a gem is better because its cleaner and allows for better dependency resolution.

Realtie

// see http://edgeapi.rubyonrails.org/classes/Rails/Railtie.html

Railtie is the core of the Rails framework and provides several hooks to extend Rails and/or modify the initialization process.
Every major component of Rails (Action Mailer, Action Controller, Action View and Active Record) is a Railtie. Each of them is responsible for their own initialization. This makes Rails itself absent of any component hooks, allowing other components to be used in place of any of the Rails defaults.

Engine

An Engine is a sub-application of a Rails application.

Engines are miniature applications that live inside your application and they have structure that you would normally find in a typical Rails application.

If you have used Devise gem, which itself is an engine, you know the benefits of being able to add functionality to your application with just a few lines of code.

These are not full applications, but pages/views/controllers/models that can be added to any rails application.

A Rails::Engine is nothing more than a Railtie with some initializers already set.

Engines are already available prior to Rails 3 but it is not a core feature of the framework. As such, engine developers resorted to monkey-patching which, oftentimes, lead to engines breaking when Rails gets updated.

Since Rails 3 an engine can be packaged and distributed as a gem.

In Rails 3.1, engines are now supported by the framework and there is now a clearly defined place where to hook your engines into Rails.

Read this blog about creating your own Rails 3 Engine:

http://gregmoreno.wordpress.com/2012/05/29/create-your-own-rails-3-engine/

Create your first gem

Let’s name our first gem as ‘myfirst’.

- Create a new directory which will contain our new gem

- Create gemspec file
The first thing to do when creating a new gem is to create a file called gemspec that contains information about the gem. The gemspec file must be named ‘mygemname.gemspec’.

File ‘myfirst.gemspec’:

Source code

Gem::Specification.new do |s|
s.name = "myfirst"
s.version = '0.0.1'
s.date = '2013-04-06'
s.authors = ["Max Ivak "]
s.email = ["maxivak@gmail.com"]
s.summary = "My very first"
s.description = "Simple Hello World"
s.homepage = "http://github.com/maxivak/myfirst"
#s.files = ["lib/mygem3.rb"]
# or
s.files = Dir["{lib}/**/*.rb", "bin/*", "LICENSE", "*.md"]
end

Find all options here – http://guides.rubygems.org/specification-reference/.
Notice this line:
s.files       = Dir["{lib}/**/*.rb", "bin/*", "LICENSE", "*.md"]

It will include all rb files in lib directory.

- code for library

Let’s create ruby code for our library in file lib/myfirst.rb.

We create a simple class with a simple class method.

File ‘lib/myfirst.rb’:

Source code

class Myfirst
def self.hi
return "Hello world"
end
end

- build gem

Source code

gem build myfirst.gemspec

You should see the following result:

Source code

WARNING: licenses is empty
Successfully built RubyGem
Name: myfirst
Version: 0.0.1
File: myfirst-0.0.1.gem

Source code

gem list | grep myfirst

Use gem in an application

Use gem locally:
Install it locally

Source code

gem install ./myfirst-0.0.1.gem

Source code

gem 'myfirst'

Then you can access gem’s functionality:

Source code

s = Myfirst.hi

Source code

irb
irb(main):001:0> require 'myfirst'
=> true
irb(main):002:0> Myfirst.hi
=> "Hello world"
irb(main):003:0> puts Myfirst.hi
Hello world
=> nil
irb(main):004:0> quit

Publish to RubyGems

You can share your gem to Ruby community by publishing it to RubyGems.org.
- Setup your RubyGems account.
Go to rubygems.org and create a new account.

- Deploy gem to RubyGems:

Source code

gem push myfirst-0.0.1.gem

It will ask to enter your credentials (email and password).
After that the gem is published:

Source code

Pushing gem to https://rubygems.org...
Successfully registered gem: myfirst (0.0.1)

Note: If you don’t want to enter credentials all time to publish your gem, read  the tutorial – http://guides.rubygems.org/make-your-own-gem/

You can see your gem on RubyGems.org site in your account. The link will be like this:

https://rubygems.org/gems/myfirst

- Check that your gem is available:

Source code

gem list -r myfirst
*** REMOTE GEMS ***
myfirst (0.0.1)

Other developers can now install your gem:

Source code

gem install myfirst

Test gem

Gems support adding test files into the package itself so tests can be run when a gem is downloaded.

Below we will create a simple test using Ruby’s built-in test framework Test::Unit.

Create a new file ‘Rakefile’ and ‘test’ directory.

- Rakefile:

Source code

require 'rake/testtask'
Rake::TestTask.new do |t|
t.libs << 'test'
end
desc "Run tests"
task :default => :test

- Basic test for our class:

test/test_myfirst.rb:

Source code

require 'test/unit'
require 'myfirst'
class MyfirstTest < Test::Unit::TestCase
def test_hi
assert_equal "Hello world",
Myfirst.hi
end
end

- run the tests:

Source code

rake test
# Running tests:
.
Finished tests in 0.001000s, 1000.0000 tests/s, 1000.0000 assertions/s.
1 tests, 1 assertions, 0 failures, 0 errors, 0 skips

You should see that all the tests passed.

Build a new version of gem

Let’s modify our gem by adding a new method.

lib/myfirst.rb

Source code

class Myfirst
def self.hi
return "Hello world"
end
def self.sum(x,y)
return x+y
end
end

- gemspec
Modify the specification of the gem by changing the version to ’0.0.2′:

Source code

Gem::Specification.new do |s|
s.name        = "myfirst"
s.version     = '0.0.2'
s.date        = '2013-04-07'
s.authors     = ["Max Ivak "]
s.email       = ["maxivak@gmail.com"]
s.summary     = "My very first"
s.description = "Simple Hello World"
s.homepage    = "http://github.com/maxivak/myfirst"
s.files       = Dir["{lib}/**/*.rb", "bin/*", "LICENSE", "*.md"]
end

- Build

Source code

gem build myfirst.gemspec

After this you should see a new file myfirst-0.0.2.gem.

- publish
Now publish a new version to RubyGems

Source code

gem push myfirst-0.0.2.gem

- Check
Finally, check that a new version is available at RubyGems – https://rubygems.org/gems/myfirst.
You should see two versions of your gem: ’0.0.1′ and ’0.0.2′.

Gems to build your own gem

You use one of the gems that help you build a gem, including

gem-this, hoe, newgem, bones, gemhub, and echoe.

References

Read more details about creating a gem at official guide – http://guides.rubygems.org/make-your-own-gem/

* The Basics of Creating Rails Plugins – http://guides.rubyonrails.org/plugins.html

Realties

* Creating your Railtie – http://edgeapi.rubyonrails.org/classes/Rails/Railtie.html

Engines:

* Getting Started with Engines – http://edgeguides.rubyonrails.org/engines.html

* Create your own Rails 3 Engine – http://gregmoreno.wordpress.com/2012/05/29/create-your-own-rails-3-engine/

Create your own gem using jeweler

* Jeweler gem – https://github.com/technicalpickles/jeweler
* http://blog.galk.me/post/7443618295/getting-started-with-gems-how-to-create-a-gem-for

* http://kashirevanna.blogspot.com/2011/12/ruby-gem-jeweler.html

Change config in production.rb:

Source code

# serve all assets from CDN server
config.action_controller.asset_host = 'http://cdn.mydomain.com'
 
#or if your files in a folder on CDN server
config.action_controller.asset_host = 'http://cdn.mydomain.com/myfolder'

To use CDN server only for images (but not for stylesheets or javascripts):

Source code

# serve only images
config.action_controller.asset_host = Proc.new { |source|
if source =~ /\b(.png|.jpg|.gif)\b/i
"http://cdn.mydomain.com"
end
}

Examples on github:

https://gist.github.com/maxivak/5239159

For more flexible settings you can use this gem: https://github.com/cmer/rails-assets-cdn

To hide the messages, add this line to your config (config/application.rb or config/environments/production.rb or config/environment.rb):

Source code

1. config.assets.logger = false
config.assets.debug = false # optional
2. rake assets:precompile RAILS_ENV=production

Solution 2.

Place the following code in config/initializers/quiet_assets.rb

Source code

if Rails.env.development?
Rails.application.assets.logger = Logger.new('/dev/null')
Rails::Rack::Logger.class_eval do
def call_with_quiet_assets(env)
previous_level = Rails.logger.level
Rails.logger.level = Logger::ERROR if env['PATH_INFO'] =~ %r{^/assets/}
call_without_quiet_assets(env)
ensure
Rails.logger.level = previous_level
end
alias_method_chain :call, :quiet_assets
end
end

The code was found here.

Discussions:

* http://stackoverflow.com/questions/6312448/how-to-disable-logging-of-asset-pipeline-sprockets-messages-in-rails-3-1

* Benchmarking of performance – https://github.com/rails/rails/pull/3795

This example shows how to password protect the whole app in beta environment using a single login/password.

Modify ApplicationController. Change username and password to your own.

Source code

class ApplicationController < ActionController::Base
before_filter :authenticate if Rails.env.beta?
 
def authenticate
authenticate_or_request_with_http_basic('Administration') do |username, password|
username == 'admin' && password == 'password'
end
end
end

References:

* authenticate_or_request_with_http_basic
* Lock down a Rails 3 app on Nginx

Split out Fat Models

Split out your Fat Models into Services, Decorators and Presenters
The approach is to put:

- Business Logic into Services

- Human Data into Decorators

- Complex Data Manipulations into Presenters

This will follow the single responsibility principle.

So our Models, Controllers and Helpers really slim.

Ref.

http://reverbhq.com/blog/2012/08/building-web-apps-with-activeadmin/

Models

Models are used for data access, persistency and consistency.
Models are slim. They only take care of associations, validations, scopes and a few request & mutating methods.

Views

Views either display a Model, a Decorator or a Presenter. There is almost no logic in them. Logic should live in the Decorator or Presenter.

Controller Actions

The CRUD actions are managed by Active Admin through InheritedResources. Custom actions are delegated to a Service.

Services: Business Logic
A Service implements the Business Logic of the application. It can be tested via Unit or Integration Tests. A Service is likely to rely on ActiveRecord models or other Services.

Decorators: One Model Data for Human-Readable Data

A Decorator adds methods for reading by humans to a model.

Source code

class UserDecorator < Draper::Base
  decorates :user
 
  def full_name
    [user.first_name, user.last_name].compact.join ' '
  end
end

Presenters

Presenters gather data from multiple models and process it into an understandable data structure.

Gems

Creating your own gems – http://maxivak.com/how-to-create-your-own-gem-for-rails-3/

Code examples

* Password protecting pages of Rails App

ActiveRecord, Models:

- Get a list of IDs from database

Countries, Cities

- Select Tag with List of Countries

Read more:

- Rails Best Practices

send_file

send_file method can be used in a controller to download the file in browser:

Source code

send_file '/path/to/file', :type => 'image/jpeg', :disposition => 'attachment'

But in case when you have an url for the remote file (for example, an image stored in amazon cloud storage like Amazon S3) then this code

Source code

send_file 'http://someserver.com/path/to/file', :type => 'image/jpeg', :disposition => 'attachment'

will give an error “Cannot read file http://..”.

According to this documentation send_file expects the first parameter to be the path to your file, i.e. the file should be stored locally on this server.

send_file(path, options = {})

send_data

Instead of send_file you can use send_data method as follows:

Source code

require 'open-uri'
url = 'http://someserver.com/path/../filename.jpg'
data = open(url).read
send_data data, :disposition => 'attachment', :filename=>"photo.jpg"

All code examples are avaiable here on github:

https://gist.github.com/4430975

Python vs Ruby

General

Both languages are good, modern, well-designed, flexible, good for your productivity.

Philosophy

- Python really believes that code readability is the most important thing. Hence there is one-true way of writing code.
Python likes things to be structured, consistent, and simple

- Ruby believes in giving programmer the flexibility, freedom and power . It provides a better way to write concise and compact code.

More into the expressiveness of the code and writing code that is clever.

- Both Ruby and Rails have more ‘magic’ involved. This makes development very fast when you understand the magic, but frustrating when you don’t.

- Django is easier to learn and has less “magic”.

Python people like libraries to be transparent and obvious how they work, while Ruby people tend to provide clean and pretty interfaces with “magic” behind the scenes.

Convention over configuration

- The centerpiece of Rails’s philosophy is called convention over configuration(CoC). Rails provides you with more defaults.

- Django on the other hand let’s you specify most configuration details yourself.

Application

- Python is more mature, general purpose nature, vs Ruby’s more niche (Rails) usage.

- Ruby+Rails holds a slight edge over Python+Django for web development, and has more mindshare.

- Python is stronger for things like data manipulation, analytics, system administration, scientific programming,  etc.

Community

- There are two great communities behind both frameworks, which bring you plugins, extensions and so on.

Some people believe that Python has a more developed community. Python community has developed tons of libraries suited for data analysis, machine learning, natural language processing, scientific libraries.

But the number of gems and extenstions to Rails is growing fast.

It’s more a choice you’ll made between their philosophies than their (similar) features set.

Django vs. Rails (with ActiveAdmin or RailsAdmin)

Ruby on Rails and Python (Django) are two leading frameworks.

Both are great MVC frameworks on top of a great language.

General

Django is more declarative you’ll have a clearer understanding of what’s actually going on.
Rails prefers convention over configuration.

First application

Compared to Rails, Django creates a much simpler project structure.

Rails features

Convention over configuration (CoC)
CoC in Rails basically means that a Rails project has a predefined layout. All components (models, views, controllers, layouts, css, javascript, etc) have standard places where you should drop them and the application picks them up without any additional effort on your part.

DRY

Another centerpiece in Rails is the “Don’t Repeat Yourself”(DRY) principle.

MVC

Rails is a classical Model-View-Controller full stack web framework.
What separates it from most of the MVC frameworks around is the heavy emphasis on REST.

Model contains the application’s business logic, Controller invokes functionality from the model layer and feeds the resulting data to View, which display the data in a readable way to the user.

ORM
The model layer is the home of your domain objects and the business logic surrounding them.
Domain objects (a.k.a. entities) are mapped to database tables (at least in RDBMS).
Unlike most object relational mappers Rails’s ActiveRecord (the default ORM; could be substituted with something else if you wish) doesn’t require you to explicitly declare the structure of the objects, but rather extracts it automatically from your DB table definitions. A simple class, modeling an application user might look like this:

- Finders – Rails generates automatically for us “finders” that we can use to make queries about objects in pure Ruby.

- DSL to express relationships between various model classes (belongs_to, has_many, etc)

Views and HTML Templates

In the view layer Rails relies on HTML templates with Ruby code embedded in them (html.erb).

There are a lot of community contributed alternatives, however, with HAML being the most prominent one.

Rails allows you to use SASS as a replacement for traditional CSS.

Rails provides the following tools to be used in views to follow its philosophy (DRY and CoC): partial templats, layout, helpers.

Ajax and Rails

Rails features tight integration with JavaScript and AJAX. jQuery is the default JavaScript library.

Making and handling AJAX requests in Rails is generally very easy.

Testing 

Rails heavily promotes testing your code. All of the Rails generators would generate test stubs, that you’ll do good to fill in.

Rails supports all major Ruby test frameworks – Test::Unit, RSpec, Cucumber.

Features:

- fixtures support,

- test database support,

- the ability to run unit and functional test separately.

Rails really pays much attention to having tests.

Deployment

The most common deployment options for Rails are currently Apache HTTPD or NginX and Phusion Passenger (mod_rails).

Django features

MVC

Django calls its separation of domains MTV (model-template-view) instead of the traditional MVC. It uses templates instead of Rail’s views.

While Django is a MVC controller framework as well, it’s built around a different mindset.

Django is totally configurable and minimalistic framework that empowers the developers to tailor it to their needs.

A Django project is comprised of autonomous and reusable apps. Apps on the other hand are comprised of models, views and templates.

ORM

Django’s default ORM is somewhat reminiscent of frameworks like Hibernate. Entity classes declare explicitly the all the attributes. So you have to write more code than you do in Rails.

Like in Rails we get useful “finders” that can be used to query for model objects in pure python (as opposed to using sql).

View (template layer)

While ERB is basically HTML with Ruby embedded in it, Django features a custom templating language with it’s own (extendable) tag library. This generally means that Django templates tend to be a bit cleaner than Rails’s templates, since you’re not allowed to abuse them very much.

On the other hand you can do virtually anything by embedding code directly in a template, so as usual – each design decision has its pros and cons.
Django supports alternative templating libraries, so you’re covered in case you don’t like the default one.

Form generation

Django features a powerful form generation/handling facilities that integrate seamlessly with the templating layer. For instance – it very easy to generate a form matching the structure of a domain model object with automatic property validation.

Rails also has gems for helping generating forms (Formtastic gem) and client-side validations.

Javascript and Ajax

Unlike Rails, Django doesn’t bundle any JavaScript libraries. You have to pick a JavaScript framework yourself (which a trivial process).

The AJAX support in Django is both basic and extremely powerful in the same time – request.is_ajax(). What this means is that you can check if a request was regular or an AJAX request and respond accordingly.

Testing

- Environments
This is a feature that comes out of the box in Rails and doesn’t in Django. Django is explicit, and you can make your environment system.

Deployment

Python is quite mature technology and offers you many deployment options – Apache, Nginx and Google App Engine.
The also the possibility to deploy Django apps on Java or .Net infrastructure using Jython or IronPython.

Admin area

Django comes with authentication and extensible admin built in. It makes it easy to build standard pages for admin to manage your data.

It makes development of simple CMSs really easy.

It is one of the Django advantages – the automatic admin interface you get for free out-of-the-box.

Rails doesn’thave a built-in support of admin. But you have a choice to use several available extenstions (gems). Currently the two most populars admin UI ‘frameworks’’ are RailsAdmin and ActiveAdmin.

Read more about comparison of RailsAdmin with ActiveAdmin:

- http://batsov.com/articles/2011/11/20/admin-interfaces-for-rails-apps-railsadmin-vs-activeadmin/

- http://stackoverflow.com/questions/6542075/rails-admin-vs-activeadmin

References:

- Discussion on stackoverflow: http://stackoverflow.com/questions/91846/rails-or-django-or-something-else

- http://batsov.com/articles/2011/06/19/django-vs-rails/

- RAILS VS DJANGO

- Which should I learn: Django or Rails? (Discussion on Quora)

- Do You Believe In Magic?, written in 2009

I found out that Internet Explorer doesn’t set cookies for some reason.

I’ve tried many settings for session_store in my config like

Source code

config.session_store :cookie_store, key: '_sess', :domain => :all
 
config.session_store :cookie_store, key: '_sess', :domain => '.mysite.com'
 
config.session_store :cookie_store, key: '_sess', :domain => '.mysite.com', :secure => false

and many many others. But it didn’t help.

The problem was in the name of my subdomain – it had an underscore ( “_” ), for example, dev_rails.mysite.com.

IE has problems accepting cookies from subdomains that contain underscore.

In order to work in IE subdomains must meet the requirements of the URI RFC.

Read more:

http://stackoverflow.com/questions/794243/internet-explorer-ignores-cookies-on-some-domains-cannot-read-or-set-cookies

“On Tuesday the EFF filed a brief proposing a process for the Court in the Megaupload case to hold the government accountable for the actions it took (and failed to take) when it shut down Megaupload’s service and denied third parties access to their property. Many businesses used Megaupload’s cloud service to store and share files not related to piracy. The government is calling for a long, drawn-out process that would require individuals or small companies to travel to courts far away and engage in multiple hearings just to get their own property back.

Would this stop you from storing your data on the cloud?

The full news story – Megaupload and the Government’s Attack on Cloud Computing

Below is the solution how to prevent this, i.e. block showing your site content via iframe. The solution is pretty simple.

Put this javascript code on all your pages:

Source code

<script>if(self != top) { top.location = self.location; }</script>

If one site will show your site in iframe, it will redirect the browser to your site directlty, so that user will will your site in browser as it is.