FastAPI: The Modern Python Web Framework

 

Introduction to FastAPI: The Modern Python Web Framework

The world of web frameworks has always been competitive — from Django and Flask in Python to Ruby on Rails, Express.js, and Spring Boot. But in recent years, FastAPI has emerged as one of the fastest-growing Python frameworks.

So what makes FastAPI special? Why are developers choosing it for APIs, microservices, and AI-powered apps? Let’s explore.

---

What is FastAPI?

FastAPI is a modern, high-performance web framework for building APIs with Python 3.6+ based on standard Python type hints.

It was created by Sebastián Ramírez and quickly gained popularity for its speed, ease of use, and developer-friendly features.

👉 Think of it as Flask + Django REST + automatic docs — but faster.

---

Key Features of FastAPI

1. Blazing Fast Performance

   • Built on ASGI (Asynchronous Server Gateway Interface).

   • Powered by Starlette (web parts) and Pydantic (data validation).

   • Comparable to Node.js and Go in terms of API performance.

2. Automatic API Documentation

   • Generates Swagger UI and ReDoc automatically.

   • No extra setup needed — docs update as you code.

3. Data Validation & Serialization

   • Uses Pydantic for request validation and response models.

   • Strong type checking → fewer bugs.

4. Asynchronous Support

   • First-class support for async/await.

   • Handles thousands of requests concurrently.

5. Easy to Learn, Easy to Use

   • Minimal boilerplate (like Flask).

   • Clear, Pythonic syntax.

---

Getting Started with FastAPI

Step 1: Install FastAPI and Uvicorn

pip install fastapi uvicorn

Step 2: Create Your First App

# main.py
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"Hello": "World"}

@app.get("/items/{item_id}")
def read_item(item_id: int, q: str = None):
    return {"item_id": item_id, "q": q}

Step 3: Run the Server

uvicorn main:app --reload

• Open http://127.0.0.1:8000 → API is live.

• Open http://127.0.0.1:8000/docs → Swagger UI (auto docs).

---

When to Use FastAPI

✅ Building REST APIs & microservices.
✅ AI/ML model serving (popular in data science).
✅ High-performance backend systems.
✅ Applications requiring async operations (chat apps, real-time APIs).

Not ideal for:
❌ Heavy full-stack apps (use Django or Rails instead).
❌ When you need batteries-included features like admin panels, auth, ORM (Django is better here).

---

FastAPI vs Django vs Flask

Feature	FastAPI	Django	Flask
Speed (async)	⚡ Very Fast	🐢 Slower (sync)	🐇 Fast
Type Safety	✅ Built-in	❌ Limited	❌ Limited
Auto Docs	✅ Yes (Swagger)	❌ No	❌ No
Learning Curve	Easy	Medium	Easy
Best For	APIs, ML apps	Full-stack apps	Simple APIs

---

Final Thoughts

FastAPI is quickly becoming the go-to framework for modern Python APIs. Its speed, automatic documentation, async support, and Pythonic design make it a favorite for developers building microservices, ML model backends, and high-performance systems.

If you’re coming from Flask, you’ll love the simplicity with extra power.
If you’re coming from Django, you’ll appreciate how lightweight and fast it is for APIs.

👉 In short: If you’re building APIs in Python today, FastAPI is one of the best choices available.

Ruby on Rails Developer to Python/Django Developer

 

🔄 Transition from Ruby on Rails Developer to Python/Django Developer

If you’re a Ruby on Rails developer, you might have noticed how Python and Django are booming in today’s tech market — especially with the rise of AI, Machine Learning, and Data Science. While Rails remains a powerful and productive framework, many developers are looking to expand their skill set and enter the Python/Django ecosystem.

The good news? If you already know Rails, moving to Django is easier than you think. In this guide, I’ll walk you through how to successfully make the transition.

---

🐍 Step 1: Learn Python Basics

Since you already know Ruby, Python will feel simple. Focus on:

• Python syntax (functions, classes, loops).

• Package management (pip, pipenv, poetry).

• Virtual environments (venv).

• Python coding style (PEP8).

👉 Spend a couple of weeks writing small Python scripts to get comfortable.

---

🌐 Step 2: Map Rails Concepts to Django

Django was inspired by Rails, so many ideas are familiar.

Ruby on Rails	Django
rails new app	django-admin startproject app
MVC (Model-View-Controller)	MTV (Model-Template-View)
ActiveRecord ORM	Django ORM
config/routes.rb	urls.py
ERB / Haml templates	Django Templates (Jinja-like)
rake db:migrate	python manage.py migrate
Gems (Bundler)	Pip packages / requirements.txt
Sidekiq / ActiveJob	Celery / Django-Q

👉 Once you learn the syntax differences, the core concepts feel like home.

---

🛠️ Step 3: Build Your First Django Project

Start small:

pip install django
django-admin startproject blog
cd blog
python manage.py runserver

Then create your first app:

python manage.py startapp posts

This is similar to Rails engines/modules.

---

📦 Step 4: Learn Django Ecosystem

To be market-ready, you’ll also need:

• Django Rest Framework (DRF): APIs, like Rails API mode.

• Celery: Background jobs, like Sidekiq.

• Gunicorn + Nginx: Like Puma/Passenger for production.

• pytest: For testing, similar to RSpec.

• Poetry/Pipenv: Like Bundler for managing dependencies.

---

🔗 Step 5: Explore Python Beyond Web

Unlike Ruby, Python dominates multiple fields:

• Data Science & AI → Pandas, NumPy, PyTorch, TensorFlow.

• Automation & DevOps → Ansible, Fabric, scripts.

• APIs → FastAPI (great complement to Django).

👉 This makes you not just a web developer, but a multi-domain Python developer.

---

🚀 Step 6: Transition Plan

• Rebuild a Rails app in Django (blog, task manager, e-commerce cart).

• Contribute to open-source Django projects.

• Take small freelance projects in Django to build confidence.

• Market yourself as a full-stack developer with Rails + Django expertise.

---

📅 Suggested Timeline

• Month 1: Python basics + scripts.

• Month 2: Django core (models, views, templates, forms, auth).

• Month 3: REST APIs with DRF + deployment (Heroku, Docker, AWS).

• Month 4+: Celery, testing with pytest, async (FastAPI).

By 3–4 months, a Rails developer can confidently transition into a Python/Django developer.

Python Feel “Hot” While Ruby on Rails Feels “Dead”

 

Why Does Python Feel “Hot” While Ruby on Rails Feels “Dead”?

If you’ve been following tech trends, you’ve probably noticed something: Python is everywhere — data science, AI, automation, scripting, backend development. Meanwhile, people often say “Rails is dead”.

But is that really true? Let’s explore why Python seems to dominate the conversation while Rails quietly powers some of the biggest apps in the world.

---

🚀 Python: The Language of the Hype Cycle

Python’s growth story is incredible. Here’s why it feels “hot”:

• AI & Machine Learning: Libraries like TensorFlow, PyTorch, Pandas, and NumPy made Python the default for AI research, startups, and now Generative AI.

• Universities & Education: Python is taught as the first programming language in most schools, creating a constant pipeline of new developers.

• Multiple Domains: Web apps (Django, Flask, FastAPI), scripting, DevOps, data engineering, AI — Python is everywhere.

👉 Python isn’t just a language anymore, it’s an ecosystem that touches every part of the industry.

---

🌐 Ruby on Rails: The Specialist

Ruby on Rails, on the other hand, stayed focused: web development.

• It’s still one of the fastest ways to build SaaS, marketplaces, and e-commerce platforms.

• Rails apps power Shopify, GitHub, Basecamp, Hey.com, Airbnb (early years) and countless startups.

• Rails developers can build production-grade apps in weeks, not months.

👉 Rails chose depth over breadth — it’s not everywhere, but it’s very strong where it plays.

---

💼 Market Trends: Jobs and Perception

Why does it feel like Python = opportunity, and Rails = old news?

• Python jobs exploded because of AI/ML hype and funding.

• Rails jobs are concentrated in SaaS companies and established businesses.

• Startups today often default to Node.js + React (because of frontend dominance) or Python + FastAPI (because of AI integration).

👉 This creates the perception that Rails is dead — but in reality, it’s just not riding the AI hype wave.

---

📣 Community Energy

Another key difference:

• Python community is academic, research-heavy, and hype-driven → always publishing papers, open-source models, tools.

• Rails community is pragmatic, product-driven, and quieter → people are busy building businesses with Rails.

👉 Rails lacks the buzz, but not the impact.

---

🔥 Rails 8: The Quiet Comeback

Rails 8 proves the framework is far from dead:

• Kamal → built-in Docker-based deployment (no PaaS required).

• Solid Queue → native job system (no Redis needed).

• Solid Cache → built-in caching with ActiveRecord.

• Propshaft → modern replacement for Sprockets.

Rails is positioning itself as:

“The fastest way for small teams to go from idea → production without DevOps headaches.”

That’s powerful.

---

🎯 Final Thoughts

So why does Python feel hot while Rails feels dead?

• Python = hype, breadth, and AI-driven growth.

• Rails = stability, productivity, and shipping production apps fast.

Rails isn’t dead — it’s just mature and stable. It doesn’t chase every hype cycle, but it quietly powers some of the most important apps on the internet.

👉 If you want to build the next AI model, Python is a great choice.
👉 If you want to build the SaaS product that monetizes it, Rails is still one of the best bets.

New Feature in Ruby on Rails 8

 

What’s New in Ruby on Rails 8?

Ruby on Rails has always been about developer happiness and productivity. With the release of Rails 8, the framework takes another giant leap forward, making it easier than ever to build, deploy, and scale modern web applications.

In this post, we’ll explore the most exciting new features in Rails 8 and why it matters for developers and businesses.

---

🌟 1. Built-in Deployment with Kamal (No PaaS Needed)

Traditionally, deploying Rails apps required third-party services like Heroku or custom DevOps pipelines. Rails 8 changes this with Kamal (formerly “MRSK”), a first-class deployment tool included in Rails.

• 🚀 Deploy Rails apps to any cloud or VPS (AWS, GCP, DigitalOcean, etc.).

• 🐳 Uses Docker under the hood for consistent environments.

• 🔄 Rollbacks and zero-downtime deploys out-of-the-box.

👉 This means you can go from development to production without needing a PaaS provider.

---

🌟 2. Propshaft: The Next-Gen Asset Pipeline

Rails 8 introduces Propshaft, a modern replacement for Sprockets.

• Simpler, faster, and more reliable.

• Designed for modern JS & CSS tooling (ESBuild, Vite, Tailwind).

• No more config-heavy asset management headaches.

👉 With Propshaft, assets are leaner and the pipeline plays nicely with today’s frontend workflows.

---

🌟 3. Solid Queue: Built-in Background Jobs

Rails has had Active Job for years, but you still needed a backend like Sidekiq or Resque. Rails 8 introduces Solid Queue — a native, database-backed job queue system.

• 📦 No Redis required — works with just your database.

• ✅ Great for small to medium apps that don’t need a dedicated queue.

• 🔄 Still works with external job processors if you want.

👉 Background processing is now easier to set up and manage in any Rails app.

---

🌟 4. Solid Cache: Smarter Caching with Active Record

Caching has been supercharged in Rails 8 with Solid Cache:

• Stores cache entries directly in the database.

• Works well with horizontal scaling (multiple servers).

• Provides visibility and management through ActiveRecord.

👉 Caching is now simpler and more reliable without needing extra infrastructure.

---

🌟 5. Rails Defaults 8.0

Every major release updates Rails defaults to modern best practices. In Rails 8, new apps come pre-configured with:

• Latest security defaults.

• Zeitwerk mode as the standard.

• Propshaft instead of Sprockets.

• Optimized configs for production-ready apps.

👉 Less time tweaking configs, more time building features.

---

🌟 6. General Improvements & Enhancements

• Action Mailer improvements → better async delivery.

• Stronger ActiveRecord performance optimizations.

• Better support for Hotwire & Turbo out of the box.

• Minor DX (developer experience) improvements across generators, configs, and logs.

---

🎯 Why Rails 8 Matters

Rails 8 isn’t just an upgrade — it’s a statement:

• Developers get full-stack power without extra tools.

• Small teams can ship production apps without DevOps complexity.

• Rails remains one of the fastest ways to build modern web apps.

With Kamal, Propshaft, Solid Queue, and Solid Cache, Rails 8 gives developers the full power of a modern framework + deployment + infrastructure in one package.

---

✅ Final Thoughts

Rails 8 is all about simplicity, productivity, and independence. It removes external dependencies, makes deployment first-class, and improves the developer experience.

If you’re starting a new project, Rails 8.0.2.1 (latest stable) is the version you should be using. And if you’re on Rails 7, now’s the perfect time to plan an upgrade.

💡 In short: Rails 8 makes it easier than ever to go from idea → production with minimal friction.

Using GenAI in Ruby on Rails

 

🧠 What is GenAI?

Generative AI (GenAI) refers to AI systems that can generate content — like text, images, code, or even audio — rather than just analyzing or classifying data. Popular examples include ChatGPT, DALL·E, and Stable Diffusion.

In a Ruby on Rails project, you can use GenAI to:

• Build chatbots for customer support.

• Generate product descriptions or blog posts dynamically.

• Enhance search features with natural language understanding.

• Create summaries of long documents.

• Automate email replies or notifications.

---

⚙️ Using GenAI in Ruby on Rails

The most common way is to connect Rails with OpenAI’s API (or other GenAI providers like Anthropic, Cohere, Stability AI).

Example: Text Generation with OpenAI (GPT-4o-mini)

# app/services/genai_service.rb
require "openai"

class GenaiService
  def initialize
    @client = OpenAI::Client.new(access_token: Rails.application.credentials.dig(:openai, :api_key))
  end

  def generate_text(prompt)
    response = @client.chat(
      parameters: {
        model: "gpt-4o-mini",
        messages: [{ role: "user", content: prompt }],
        temperature: 0.7
      }
    )
    response.dig("choices", 0, "message", "content")
  end
end

Usage in a controller:

class GenaiController < ApplicationController
  def create
    prompt = params[:prompt]
    ai = GenaiService.new
    render json: { result: ai.generate_text(prompt) }
  end
end

---

Example: Image Generation with DALL·E

def generate_image(prompt)
  response = @client.images.generate(
    parameters: {
      prompt: prompt,
      size: "512x512"
    }
  )
  response.dig("data", 0, "url")
end

---

🚀 Benefits of GenAI in Rails Apps

✅ Saves time by automating repetitive tasks.
✅ Improves user experience with natural conversations.
✅ Personalizes content for users.
✅ Adds innovative features that differentiate your app.

Integrating OpenAI with Ruby on Rails

 

Integrating OpenAI with Ruby on Rails: A Step-by-Step Guide

Artificial Intelligence is transforming how modern web applications are built, and OpenAI’s models can be seamlessly integrated into your Ruby on Rails projects to add natural language processing, chatbots, content generation, and more. In this guide, we’ll walk through how to set up OpenAI in a Rails application.

---

🔧 Step 1: Add the OpenAI Gem

First, install the ruby-openai gem. This gem provides a simple wrapper around OpenAI’s API.

# Gemfile
gem "ruby-openai"

Run:

bundle install

---

🔑 Step 2: Configure API Key

Set your OpenAI API key as an environment variable (best practice is to use dotenv-rails or Rails credentials).

export OPENAI_ACCESS_TOKEN="your_api_key_here"

Or inside Rails credentials:

EDITOR="nano" bin/rails credentials:edit

openai:
  api_key: your_api_key_here

---

💻 Step 3: Initialize OpenAI Client

Create a service file for handling OpenAI requests, for example:

# app/services/openai_service.rb
require "openai"

class OpenaiService
  def initialize
    @client = OpenAI::Client.new(access_token: Rails.application.credentials.dig(:openai, :api_key))
  end

  def chat(prompt)
    response = @client.chat(
      parameters: {
        model: "gpt-4o-mini",
        messages: [{ role: "user", content: prompt }],
        temperature: 0.7
      }
    )
    response.dig("choices", 0, "message", "content")
  end
end

---

🚀 Step 4: Use OpenAI in a Controller

Example controller to call the service:

# app/controllers/ai_controller.rb
class AiController < ApplicationController
  def generate
    prompt = params[:prompt]
    ai_service = OpenaiService.new
    @response = ai_service.chat(prompt)

    render json: { response: @response }
  end
end

And add a route:

# config/routes.rb
post "ai/generate", to: "ai#generate"

---

🌐 Step 5: Test the Endpoint

Send a POST request with a prompt:

curl -X POST http://localhost:3000/ai/generate \
  -H "Content-Type: application/json" \
  -d '{"prompt":"Explain Ruby on Rails in simple terms."}'

Response:

{
  "response": "Ruby on Rails is a web framework that helps developers build web apps quickly..."
}

---

📊 Possible Use Cases in Rails

• Customer support chatbots

• Blog/content generation

• Code suggestions in developer tools

• Semantic search & recommendations

• Automating routine text tasks

---

✅ Final Thoughts

Integrating OpenAI with Ruby on Rails is straightforward using the ruby-openai gem. By following the steps above, you can add powerful AI-driven features to your Rails app and create a more interactive, intelligent experience for users.

datepicker with nested form field

Indeed, you will have to retrigger the datepicker plugin. You are probably doing something like

$('datepicker').some_function_to_do_your_datepicker_styling();

But of course, the dynamically added elements are not yet in the DOM.

So do something like:

$('form').on('cocoon:after-insert', function() {
  /* apply datepicker styling */ 
});

Intro to Docker for Developers: How to Run your Rails App on Docker

Docker in a Nutshell First of all what is Docker? Let’s chew on the Wikipedia definition to start: 

“Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux.[2] Docker uses resource isolation features of the Linux kernel such ascgroups and kernel namespaces to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines.[3]”

From a developer perspective Docker promises us the opportunity to forget about the “it works in my local environment but not in production” problem as well as the “it works on my Ubuntu machine but not on my buddy’s Mac three feet away” scenario. 

Now, with the magic of a definition file, it is super easy to port an app between environments: from local to lab, and later to production. Docker is incredibly fast and thanks to the use of some linux kernel features like namespaces, we have isolation for filesystem, networks and processes. 


This consistency is an incredible opportunity for developers, but it’s an especially big win for our users: with Docker we can reduce highly disruptive “environmental issues” to almost zero percent. 

Did I just say the word disruptive? Oh right, container revolution, blah blah. :)

Step #1: Prepare Your Infrastructure / Server Environment

Let’s “dockerize” a basic Rails app.This is what the app looks like. It was created using “Rails new Rails-App” (if you don’t have Rails you can just follow the installation instructions here) 

First, you need to have Docker running. To do so, you can just check the docker documentation, which is really quite easy to follow. Choose your platform, follow the instructions, and voilà! 

Once installed, check that the Docker daemon is running properly by typing:

$ docker -v

Docker version 1.7.0, build 0baf609 (this will probably change based on the installation type/platform you have chosen)

Step #2: Build Your Image

Next up we need to build our Rails image. Docker uses a definition file to describe what the environment will contain. Usually it’s named Dockerfile (you can use a different name also), so for simplicity let’s create a file in our app directory called “Dockerfile” and add a few lines in there (gist):

# Base image FROM ruby:latest 

ENV HOME /home/rails/webapp 

# Install PGsql dependencies and js engine 

RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs 

WORKDIR $HOME 

# Install gems 

ADD Gemfile* $HOME/ 

RUN bundle install 

# Add the app code 

ADD . $HOME 

# Default command 

CMD ["rails", "server", "--binding", "0.0.0.0”]

Okay...so what’s a “Docker image” for real? 

An image is a read-only template that Docker uses to run your code through a container. It contains a complete environment definition: it has the OS binaries, libraries, dependencies and all the applications that you need to run your code or application. All the magic is stuffed into it, so pay attention! 

Images contain layers (I won’t explain much about them here, since it’s a big topic that requires its own blog post). Every instruction creates a new layer in the filesystem. And thanks to the use of a union filesystem, those layers are “combined” into a single filesystem. Neat and tidy. 

An image can be built and pushed into a registry, like Docker Hub, or Quay.io (or even a custom one), just like you would do with GitHub. You can even have public or private repositories, so others can leverage your image / template, or you can re-use for other purposes.

Digging into your Dockerfile

To help us understand how this all works, let’s examine our freshly baked Rails Dockerfile.

FROM ruby:latest - This is the first instruction you have to have in your Dockerfile, with this instruction we are defining the base image. In our case, it will use this base image https://registry.hub.docker.com/u/library/ruby/, which actually has an interesting hierarchy:

• 
  
• Ruby is based on buildpack-deps:jessie which is based on buildpack-deps:jessie-scm which is based on buildpack-deps:jessie-curl, which is finally (!) based on debian:jessie.
• 
  
• As you can see, between images there exist some kind of “inheritance” concept where you can “extend” your images from others. It’s a great thing since you can build your environments based on trusted/stable (if you find them! and still be careful) images.

ENV HOME /home/rails/webapp - Just defining an environment variable.

RUN apt-get update -qq && apt-get install -y build-essential nodejs

• The RUN instruction executes a command in the docker container. So the “apt-get …” command will update the OS packages list and will install some libraries among nodejs.

WORKDIR $HOME - The WORKDIR instruction sets the working directory for any RUN, CMD, ENTRYPOINT, COPY and ADD instructions.

ADD Gemfile* $HOME

/RUN bundle install

• 
  
• Copy all the gem files definitions into the filesystem in the container and execute the command to install the gems. (I’ll explain why I’m doing this, in the next “Using Cache in Docker” post :) )

ADD . $HOME - Copy all the website files into the container.

CMD ["rails", "server", "--binding", "0.0.0.0"] - Specify the default command for when the container runs.

Step #3 - Build and Run Your Web App

Now that we have a better idea of our Dockerfile, let’s get our hands dirty! We need to build and run the web app:

$ docker build -t ruby-app .

Since we don’t have a Ruby image downloaded yet, it will pull the latest from Docker Hub and then run all the instructions from the Dockerfile. You should end up with something like this:

Later we can check the image using:

$ docker images

Let’s create a container and run the app.

$ docker run -d -p 3000:3000 rails-app

The command above will create a docker container using the “ruby-app” image you created in Step #2. The “-d” flag tells docker daemon to run this container in “daemon mode”.

Remember our CMD instruction in the Dockerfile? Well that is what’s running in the container “rails server --binding 0.0.0.0”

You can just open your browser at: http://localhost:3000 or you can get the container IP:

docker inspect 8f4fec2497f5 | grep IPAddress

(you can also run docker inspect --format '{{.NetworkSettings.IPAddress}}' 8f4fec2497f5 )

In my case it is: "IPAddress": "172.17.0.2"

So, just open the browser and point it to http://172.17.0.2:3000 and you will see the rails app running :)

One last interesting command about the run command we used is the -p flag.

docker run -d -p 3000:3000 ruby-app

When using the -p flag docker let us choose a port binding between the host and the container. Without this flag we could get into the rails app from outside the container. We could even choose a different port like: 

docker run -d -p 5000:3000 ruby-app

Or let docker choose a random port like

docker run -d -p 3000 ruby-app

To see what port docker has chosen, we can run “docker ps”

Or let docker choose a random port like docker run -d -p 3000 ruby-app To see what port docker has chosen, we can run “docker ps”

And in the port column you will see that the assigned port is 32769.

Also you could do:

$docker port 284bb5e37f44

Result: 3000/tcp -> 0.0.0.0:32769

And in the port column you will see that the assigned port is 32769. Also you could do: $docker port 284bb5e37f44 Result: 3000/tcp -> 0.0.0.0:32769

Using MongoDB With Ruby On Rails 5

In this post I am going to walk you through installing Ruby on Rails 5 using rbenv and use the Mongoid MongoDB driver for Ruby. MongoDB is a fantastic NoSQL database that is incredibly scalable and fast which makes a good combo with Rails. We will be using Linux Ubuntu 16.04 with MongoDB and Rails already installed.

Create a Rails App (Without Active Record)

rails new myapp --skip-active-record

Using the –skip-active-record option will create the app without the database.yml config file. We will use a mongoid config file instead. This will also prevent using the sqlite gem. We will add the Mongoid gem below

Edit Gemfile

Add the following to your Gemfile

gem 'mongoid', '~> 5.1.0'

Generate Mongoid Config File

rails g mongoid:config

This will create config/mongoid.yml

Thats It! you should now be able to run “rails s” and use MongoDB

rails g scaffold post title body author created

Now visit “http://localhost:3000/posts” and you should have CRUD functionality using MongoDB

If you did NOT use the “–skip-active-record”

Remove Gem “sqlite” from the Gemfile

Delete the database.yml file

Go to config/application.rb and remove “require rails/all” and replace with…


require "action_controller/railtie"
require "action_mailer/railtie"
require "rails/test_unit/railtie"

Comment out any line that has “active_record” in it in the following files

/config/development.rb
/config/production.rb
/config/initializers/new_framework_defaults.rb

Ruby packages for Ubuntu

Brightbox have been providing optimised Ruby packages for Ubuntu for years. We’re currently maintaining packages for Ruby 2.3, 2.2, 2.1, 2.0, 1.9.3, and 1.8.7. Our Ruby 1.9.3 and 1.8.7 packages are modified with various performance improvements.

Ruby 2.3

We provide Ruby 2.3 packages for Ubuntu Yakkety, Xenial, Trusty and Precise. Our Ruby 2.3 packages are built from unmodified versions of Ruby.

Ruby 2.2

We provide Ruby 2.2 packages for Ubuntu Yakkety, Xenial, Trusty and Precise. Our Ruby 2.2 packages are built from unmodified versions of Ruby.

Ruby 2.1

We provide Ruby 2.1 packages for Ubuntu Yakkety, Xenial, Trusty and Precise. Our Ruby 2.1 packages are built from unmodified versions of Ruby.

Ruby 2.0

We provide Ruby 2.0 packages for Ubuntu Yakkety, Xenial, Trusty, Precise and Lucid. Our Ruby 2.0 packages are built from unmodified versions of Ruby.

Ruby 1.9.3

We provide Ruby 1.9.3 packages for Ubuntu Yakkety, Xenial, Trusty, Precise and Lucid. Our Ruby 1.9.3 packages include some major performance improvements:

• Built with Google’s high performance memory allocator, tcmalloc
• Added Sokolov Yura’s performance patches
• Added Narihiro Nakamura’s Bitmap Marking garbage collector (backported by Sakolov Yura)
• Greg Price’s “require” performance fixes.
• Patched to export the right symbols to work with ruby-debug
• Updated rubygems to latest 1.8.x release

Ruby 1.8.7

We provide Ruby 1.8.7 packages for Ubuntu Xenial, Trusty, Precise and Lucid. Our Ruby 1.8.7 packages include some major improvements:

• Ruby Enterprise Edition patches for 1.8.7-358 (2012.02)
• Built with Google’s high performance memory allocator, tcmalloc
• Updated rubygems packages to latest 1.3.x release

Installation

All the above packages are available from our Launchpad package repository.

Adding the repository

If you’re using Ubuntu 14.04 (Trusty) or newer then you can add the package repository like this:

$ sudo apt-get install software-properties-common
$ sudo apt-add-repository ppa:brightbox/ruby-ng
$ sudo apt-get update

Or if you’re on Ubuntu 12.04 (Precise) or older

$ sudo apt-get install python-software-properties
$ sudo apt-add-repository ppa:brightbox/ruby-ng
$ sudo apt-get update

Installing the packages

Each version of Ruby has its own packages - just install the packages for the versions you’d like to use.

So to install Ruby1.8, Ruby 1.9.3 and Ruby 2.2

$ sudo apt-get install ruby1.8 ruby1.9.3 ruby2.2

And you’ll usually need the dev packages too, so you can build native extensions

$ sudo apt-get install ruby1.8-dev ruby1.9.3-dev ruby2.2-dev

Then you can run the different versions of ruby like this:

$ ruby1.8 -v
ruby 1.8.7 (2015-04-14 MBARI 8/0x6770 on patchlevel 375) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2012.02

$ ruby1.9.3 -v
ruby 1.9.3p551 (2014-11-13) [x86_64-linux] Brightbox

$ gem1.8 install bundler

$ gem1.9.3 install bundler

Switching the default Ruby version

You can also switch the default Ruby version back and forth between versions using theruby-switch tool:

$ sudo apt-get install ruby-switch

$ ruby -v
ruby 1.8.7 (2015-04-14 MBARI 8/0x6770 on patchlevel 375) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2012.02

$ ruby-switch --list
ruby1.8
ruby1.9.1
ruby2.0
ruby2.1
ruby2.2

$ sudo ruby-switch --set ruby1.9.1
update-alternatives: using /usr/bin/ruby1.9.1 to provide /usr/bin/ruby (ruby) in manual mode.
update-alternatives: using /usr/bin/gem1.9.1 to provide /usr/bin/gem (gem) in manual mode.

$ ruby -v
ruby 1.9.3p551 (2014-11-13) [x86_64-linux] Brightbox

(note that Ruby 1.9.3 shows as 1.9.1, due to a historical Debian thing about binary compatibility)

Gem binaries

Any binaries installed by gems (such as bundler’s bundle command) might not automatically use the current default version of ruby (preferring the version that was default at the time it was installed). In that case, you can explicitly run it under a specific version like this:

$ ruby1.9.1 -S bundle -v
Bundler version 1.6.3

If you’re using multiple versions of ruby on a server, it’s best to explicitly run any ruby binaries with the desired version of Ruby like this.

Ruby 1.8 gems

The ruby 1.8 packages on Lucid, Precise and Trusty don’t come with the rubygems libraries, so you need to install that separately if you need it:

$ sudo apt-get install ruby1.8 rubygems

You don’t need this on Xenial though.