DEV Community: Josef Strzibny

How to implement AI agents in Rails with RubyLLM

Josef Strzibny — Fri, 24 Apr 2026 07:41:13 +0000

Chat-based agents are augmented LLM interfaces with access to a list of predefined tools. RubyLLM Agents are reusable AI assistants implemented as models with their configuration, runtime context, and prompt conventions. Let's see how we can start implementing custom OpenAI chat agents with access to SERP tools with the help of the RubyLLM gem.

💡 Note the difference between fully autonomous agents like Claude Code or Codex, and chat-based agents that still react to user input. This post is about the latter.

Simple chats vs agents

RubyLLM is a Ruby gem and an AI interface for GPT, Claude, and Gemini to give us an easy way to run LLM chat inside a Ruby application. It allows us to avoid writing JSON and lets us work with AI using beautiful Ruby DSL.

A regular RubyLLM chat is a conversation. A user sends a message, the model responds, and the exchange continues back and forth. It works but it's limited to what the model can do. Today's models can do way more than before as they often search the web and find up-to-date information. However, they still do a lot of guessing and cannot access your internal data. This means we need to be very specific and provide a lot of context for the LLM to understand our request.

Imagine we ask an LLM something more complex with a simple sentence:

# Choose any model you like, just make sure to set up
# the access token in the initializator
chat = RubyLLM.chat(model: "gpt-5.4-mini")
chat.ask "Is our 'Aeropress Coffee Maker' at $39.99 competitive?"

How could this LLM model know the answer?

Perhaps the agent could search our pages as well as our competitors' to gain a full understanding of our request. This usually requires some back and forth to ensure the LLM has all the context needed to give an accurate response. If we want more precision, access to application data, and better results, we need to give the chat agent access to the tools we control.

Now imagine what would happen if the chat agent has access to a local database and Google Shopping:

chat = RubyLLM.chat(model: "gpt-5.4-mini")
chat.with_tools(LookupProduct, SearchGoogleShopping)
chat.ask "Is our 'Aeropress Coffee Maker' competitively priced?"

# => "Your Aeropress Coffee Maker is listed at $39.99. Here are current
# Google Shopping prices:
# 1. Amazon — $34.95
# 2. Target — $37.99
# 3. Walmart — $33.49
# 4. Williams Sonoma — $41.95
# 5. REI — $39.95
#
# You're on the higher end. Three out of five retailers are under $38.
# Consider adjusting to ~$36-37 to stay competitive."

Suddenly it has everything it needs to answer such an ambiguous question. It can search for competitors products on Google Shopping and compare it with data we have in our product catalog. Not bad at all.

The concept of using tools is simple. We describe a set of tools to the model, each with a name, parameters, and what it does. When the model determines it needs specific information or wants to perform an action, it returns a structured tool call

instead of plain text which looks like JSON below:

{
  "role": "assistant",
  "content": null,
  "tool_calls": [
    {
      "id": "call_abc123",
      "type": "function",
      "function": {
        "name": "lookup_product",
        "arguments": "{\"name\":\"Aeropress Coffee Maker\"}"
      }
    }
  ]
}

Our code now needs to execute this function call and feed the result back which is all handled by RubyLLM in the background. The model then continues reasoning with the new information.

This loop which reasons, acts, and observes is what turns a language model into something that can actually get work done. And even better, we can wrap it all in a reusable agent class thanks to the RubyLLM Agents support. But first, let's implement the tools.

Tools

RubyLLM tools are interfaces for runnable code we control in an LLM chat. Both LookupProduct and SearchGoogleShopping tools would be implemented as Ruby classes inherited from RubyLLM::Tool. We name them using description, provide a set of acceptable params using param, and implement the execute method.

Here's an example of how this could look when searching a local product catalog for LookupProduct:

class LookupProduct < RubyLLM::Tool
  description "Looks up a product in our catalog by name"
  param :name, desc: "Product name to search for"

  def execute(name:)
     Product.where("name ILIKE ?", "%#{name}%")
            .select(:name, :price, :sku, :category)
            .map(&:attributes)
  end
end

And here's the code for SearchGoogleShopping that works with Google Shopping using SerpApi:

class SearchGoogleShopping < RubyLLM::Tool
  description "Searches Google Shopping for current market prices of a product"
  param :query, desc: "The product to search for"

  def execute(query:)
    search = SerpApi.search(q: query, engine: "google_shopping")
    search.shopping_results.first(5).map do |r|
      { title: r[:title], price: r[:price], source: r[:source] }
    end
  end
end

You can see that RubyLLM does all the heavy lifting, allowing us to write code as usual.

Agents

Once we have our tools ready, we can introduce them to the chat using the chat.with_tools call. We can also go one step further and wrap this up as a reusable class in an agent thanks to the RubyLLM::Agent interface.

An agent in this context is a class that couples instructions with a set of tools:

class PriceMonitorAgent < RubyLLM::Agent
  model "gpt-5.4-mini"

  instructions <<~PROMPT
      You are a pricing analyst. You help the merchandising team keep our product
      catalog competitively priced. You can look up our products, check current
      Google Shopping prices, and find products where we are significantly overpriced.
      Always show specific numbers when comparing prices.
    PROMPT

  tools LookupProduct, SearchGoogleShopping, FindUndercut
end

A PriceMonitorAgent like the one above could help the shop's merchandising team find products that are overpriced on the current market:

agent = PriceMonitorAgent.new
agent.ask "Which of our coffee products are priced more than 15% above market?"

# => "I found 3 coffee products above the 15% threshold:
#
# 1. Baratza Encore Grinder — Our price: $179.99, Market avg: $149.80 (20.2% over)
# 2. Fellow Stagg Kettle — Our price: $94.99, Market avg: $79.60 (19.3% over)
# 3. Chemex 6-Cup — Our price: $54.99, Market avg: $44.97 (22.3% over)
#
# The Aeropress ($39.99 vs $37.48 avg) and Hario V60 ($11.99 vs $11.20 avg)
# are within range and look fine."

Depending on the question, the agent can pick one tool to generate a response or use an additional tool from the list to find the right answer. Combining internal data with live SERP data is incredibly powerful.

Debugging

Sometimes we might not be sure if the agents are using our tools in the way we expected. Luckily, chats in RubyLLM let us see all the tool calls that were done:

chat.messages.each do |m|
  m.tool_calls&.each do |tc|
    puts "#{tc.name} #{tc.arguments.inspect}"
  end
end

If we want to specifically recheck what search queries were run using SerpApi, we can head to serpapi.com/searches after logging in, and find the searches that were done. We'll get a full Search Inspector including the returned page and JSON:

Conclusion

SerpApi makes it super easy to integrate search data from Google, Amazon, Bing, and other search engines into your application. And RubyLLM makes it easy to expose this API as a tool for your agents. Give SerpApi a try with 250 free searches/month.

Self-host SerpBear with Coolify

Josef Strzibny — Thu, 02 Apr 2026 08:47:23 +0000

Tracking organic positions on search engines is one of the main concerns of SEO. SerpBear is a SERP position tracking tool that will help you track how well you are doing in Google search. This post will take you through all the steps to start tracking your keywords with your own SerpBear instance on Coolify.

What is SerpBear?

SerpBear is an Open Source search engine position tracker. It allows you to track your or your competitors' keyword positions in Google and to also get notified of these changes. Some of the features include:

Unlimited keywords: You can add as many domains and keywords to track as you want. SerpBear will use a 3rd-party API such as SerpApi for actual tracking behind the scenes.
Flexible scraping strategy: Choose your scraping strategy to control how many Google pages are checked for each domain. It's built to handle the Google's 2025 removal of the num=100parameter.
Email notification: Get notified of all your keyword position changes via email with at the frequency of your choosing.
Keyword research: You have the option to do keyword research with the integration of Google Ads.
Google Search Console: You can see the actual visit count and impressions for each keyword. Discover new keywords thanks to direct integration with Google Search Console.
Exports: Export your domain keyword data in CSV files.

If you want to track your keywords, but don't want to use SerpBear, have a look how to do your custom SERP tracking in JavaScript.

What is Coolify?

Coolify is an Open Source Platform as a Service (PaaS) that will help you self-host SerpBear or any other self-hostable software out there. You can also deploy applications, databases, and one-click services.

I am assuming you already have Coolify installed on your server. If you don't, you can learn how to deploy Coolify on any VPS or take advantage of Coolify Cloud version where you don't have to host Coolify yourself.

💡 We are going to deploy SerpBear 3.0 on Coolify 4.0. Coolify 4.0 is still beta software for the time being.

Signing up for SerpApi

SerpApi is a service providing access to various SERP results with a simple API. SerpBear is free and open source software, but it uses SerpApi to do the heavy lifting of querying and parsing Google results. SerpBear cannot do this on its own due to the nature of managing proxies and solving CAPTCHAs, but you can still start with free searches to set everything up and see it working before committing to a paid plan.

So first of all, sign up for SerpApi and then note your private API key from serpapi.com/manage-api-key page:

We are going to use this API key from SerpBear, but you can also use it to integrating one the many SerpApi SDKs to build anything needing SERP API.

Configuring DNS

Head over to your domain registrar console and set the DNS A records for domains or subdomains you want to use for SerpBear:

coolify.example.com -> 178.104.25.112
serpbear.example.com -> 178.104.25.112

Choose "A" type records to directly connect a domain name or subdomain to the IP address (replace the values, the above is just an example). If you'll run SerpBear on the same host as Coolify, the IP address remains the same for both.

Adding SerpBear

If your Coolify instance is fully set up, it's time to add SerpBear. To run a new Coolify project head over to Projects (from the left menu) and click on + Add next to the Projects headline. Give it a name and description.

From Projects, click on + Add Resource next to your project name or select your project first and click on + New next to Resources. From here, we can select Docker Compose Empty under Docker Based on the right:

SerpBear provides Docker Compose configuration which Coolify supports. Since SerpBear uses SQLite to save SERP data, it's not necessary to spin up process-based databases and the Compose file is relatively simple:

services:
  app:
    image: towfiqi/serpbear:latest
    # Build from source instead of pulling the image:
    # build: .
    restart: unless-stopped
    ports:
      - "${PORT:-3000}:3000"
    environment:
      - USER_NAME=${USER:-admin}
      - PASSWORD=${PASSWORD}
      - SECRET=${SECRET}
      - APIKEY=${APIKEY}
      - SESSION_DURATION=${SESSION_DURATION:-24}
      - NEXT_PUBLIC_APP_URL=${NEXT_PUBLIC_APP_URL:-http://localhost:3000}
      # Optional: Google Search Console integration
      - SEARCH_CONSOLE_CLIENT_EMAIL=${SEARCH_CONSOLE_CLIENT_EMAIL:-}
      - SEARCH_CONSOLE_PRIVATE_KEY=${SEARCH_CONSOLE_PRIVATE_KEY:-}
    volumes:
      - serpbear_data:/app/data
    healthcheck:
      test: ["CMD-SHELL", "wget -qO- http://localhost:3000 || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 15s

volumes:
  serpbear_data:

The SerpBear service definition includes the official Docker image, container restart policy, ports, environment variables, volumes, and health check. The official guide suggests using the latest image (towfiqi/serpbear:latest) which will let you update the application with Redeploy at any later point, but you can choose a stable release to lock-in a particular version.

The required environment variables reference variables like {USER:-admin} and {SECRET} which let us manage the environment directly from the Coolify admin interface. Notice that SerpBear also supports Google Search Console, so if you can obtain these credentials as well. Finally notice the serpbear_data volume which is the future location of your SerpBear database.

Paste the configuration above. Click Save.

Adding the new resource should take you to the resource configuration. Under General we can change the resource name, under Persistent Storages we can check our persistent volume, and finally under Environment Variables we can go fill up the variables from the Compose file:

Here's the list of environment variables we should fill in:

USER_NAME: The username you want to use to login to the app.
PASSWORD: The password you want to use to log in to the app.
SECRET: A secret key that will be used for encrypting 3rd party API keys & passwords.
APIKEY: API key that will be used to access the app's API. This is not SerpApi account key!
SESSION_DURATION: The duration(in hours) of the user's logged-in session.
NEXT_PUBLIC_APP_URL: The URL where your app is hosted and can be accessed like https://serpbear.example.com

Note that every environment entry has its own Update button and they won't be saved all at once. You can add the Google Search Console credentials if you have them, but they aren't necessary to start tracking your keywords with SerpApi.

Restart the service.

Tracking keywords with SerpBear

If you carefully followed all the steps, you should be now able to access the SerpBear instance on the (sub)domain of your choosing. Log in using the chosen credentials from the previous step. You should see a red prompt at the top to configure your Scrapper/Proxy. Click on it to open settings, choose SerpApi.com as the Scraping Method and insert your SerpApi API token under Scraper API Key Or Token:

Click Update Settings to close the right sidebar and you'll be ready to add your first keywords to track. Start by adding a domain name. After entering your domain name you should end up on the Tracking tab for the domain.

Click Add Keyword and start adding keywords and phrases you care about. They should appear in a nice table with their last position, best position, history graph, volume, and URL. Here's an example of tracking "serp api" for serpapi.com in the Czech Republic:

And that's it! You can now add as many domains and keywords as you want to. Remember that SEO today is not just about tracking organic results in Google, so have a look at AI overviews as well.

Next steps

As next steps you can consider adding your Google Search Console data to SerpBear, handle external backups in Coolify, or exploring more of SerpApi. The Free tier comes with 250 free searches per month.

How to start self-hosting with Coolify 4 on a VPS

Josef Strzibny — Wed, 01 Apr 2026 11:57:51 +0000

Coolify is an open source Platform as a Service (PaaS) that can help you self-host a lot of different software from content management tools like Ghost to SEO tracking software like SerpBear. The only thing you'll need is a virtual private server (VPS) from a hosting provider of your choice and a little bit of set up which is exactly what we'll go through in this post.

💡

Coolify v4 is still beta software as of the time of writing of this post. If you need a little bit more stability, wait for the final release.

What is Coolify?

Coolify is a self-hostable alternative to Heroku, Vercel, or Netlify. It's an open source PaaS that allows developers to deploy their applications as well as manage 3rd-party services and databases.

Some of the biggest advantages include:

Self-hosted control: You own your data on your own servers which saves money and avoids vendor lock-in.
Hosting versatility: Hosts web applications, static websites, databases (PostgreSQL, MySQL, MongoDB, etc.), and services
Automated DevOps: Automatically installs dependencies, sets up databases, and handles deployments from GitHub, GitLab, or Bitbucket.
Web console: Offers a web-based dashboard for managing multiple servers, viewing logs, and monitoring resource usage like CPU and RAM.
Built-in tools: Features automatic S3-compatible backups, auto provisioning of SSL certificates, webhooks, or preview deployments.

You can run Coolify in various ways. You can use a single server for everything you host or do a separate deployment for the services you'll run.

Applications, databases and services

Coolify supports deploying custom applications and 3rd-party services. It generally distinguish between 3 different types of resources:

Applications come with a git source or are built using Docker from Dockerfile. You can deploy anything from PHP to Java.
Databases are preconfigured Docker images for running databases, like MySQL or PostgreSQL.
Services are deployments based on Docker Compose files that are stored directly on the server. You deploy well known software like Ghost.

You can mix and match any of these on a single Coolify instance.

Setting up the virtual server

There are two variants to self-hosting. One with physical servers that are usually dedicated to you and one with virtual servers where you share the underlying physical servers with others.

We'll set up a simple virtual server on Hetzner which is a provider praised for its affordable costs. You are free to use any other provider you like or already have. Some other popular providers include Digital Ocean, Vultr, or OVHcloud.

💡

Coolify currently offers $20 credit for deploying to Hetzner by following the https://coolify.io/hetzner link.

To create a virtual private server (VPS), you'll need an SSH key pair which you'll authenticate with in the future. You can optionally set a password for the private key as well. To generate a new one, run ssh-keygen:

ssh-keygen

The command will interactively ask you about your key details. If you name it coolify you should end up with two files inside the ~/.ssh directory, one for private key and one for public key (coolify.pub).

💡

Protect your SSH private key! You always provide others with your public key, not the private key. The private key should stay with you on your computer.

Once you have your key pair, it's fairly straightforward to spin up a new server with the provider of your choice.

On Hetzner, create a new project and on the project overview click Add Server.

Select a location close to you, Ubuntu 24.04 or your favorite operating system (Debian, SUSE, and Fedora based systems are supported), the size you want, and optionally enable full virtual machine backups. Under SSH Keys upload your public SSH key which should disable password-based access on most providers and let you use your private key instead.

As for the size of the box, Coolify recommends at least 2 vCPUs, 2 GB of RAM, and 30 GB of storage space. If you are going to self-host projects on the same instance, you generally need to increase the box size accordingly. For only running one or two extra applications, consider increasing RAM.

This is all that's needed for things to work, but we can also provide a custom cloud-init script under Cloud config. For example, we can set up automatic system updates and install fail2ban for extra protection of our SSH port:

# Do a system update
apt update;
DEBIAN_FRONTEND=noninteractive apt upgrade -y

# Install essential packages
apt install -y curl unattended-upgrades fail2ban

# Set up unattented updates
echo -e "APT::Periodic::Update-Package-Lists \"1\";\nAPT::Periodic::Unattended-Upgrade \"1\";\n" > /etc/apt/apt.conf.d/20auto-upgrades
/etc/init.d/unattended-upgrades restart

# Install fail2ban
systemctl start fail2ban.service
systemctl enable fail2ban.service

You can optionally install Docker at this step from the system package manager but do not install Docker from Snap as that's not supported by Coolify.

Finally, give the server a name (you can call it coolify, but do not use a domain name) and click Create & Buy now. Provisioning the server will take some minutes and once done you should be able to find the public server IPv4 address next to its name on the server page:

You should now be able to log in from your terminal as:

ssh-add ~/.ssh/path-to-your-key
ssh root@[IP_ADDRESS]

There is quite a bit more to running and securing servers. You should ideally choose a different user than root and/or disable public SSH access altogether in the cloud's firewall. If you want to do that, have a look at WireGuard or Tailscale.

Configuring DNS

Now that you have a public IP address, you can create DNS records to get nice URLs for accessing Coolify, SerpBear, and whatever else you decide to self host.

Head over to your domain registrar console and set the DNS A records for domains or subdomains you want to use for Coolify and the applications you want to host:

# For accesing Coolify web console (admin area)
coolify.example.com -> 178.104.25.112

# Example application
serpbear.example.com -> 178.104.25.112

Choose "A" type records to directly connect a domain name or subdomain to the IP address (replace the values, the above is just an example). You can use Porkbun or GoDaddy to register your first domain name if you don't have one yet.

Since we'll run everything on a single host, the IP address remains the same for all instances.

Installing Coolify

Now that we have our Linux box up and running, we can SSH into it and run the official installer script:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

You can change some installation details with environment variables, so go and review this list before running the script.

For example, you might want to choose the admin username, email, and password:

env ROOT_USERNAME=admin \
ROOT_USER_EMAIL=admin@example.com \
ROOT_USER_PASSWORD=SecurePassword123 \
bash -c 'curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash'

Once run, you'll see a Congratulations! screen with the list of the IP addresses, version as well as a log file:

____ _ _ _ _ _
  / ___|___ _ ____ _ _ ____ _| |_ _ _| | ___| |_(_)___ _ _____ | |
 | | / _ \| '_ \ / _` | ' __/ _` |__ | | | | |/ _` | __| |/ _ \| '_ \/__ | |
 | |__| (_) | | | | (_| | | | (_| | |_| |_| | | (_| | |_| | (_) | | | \__ \_|
  \ ____\___ /|_| |_|\ __, |_| \__ ,_|\ __|\__ ,_|_|\ __,_|\__ |_|\ ___/|_| |_|___ (_)
                   |___/


Your instance is ready to use!

You can access Coolify through your Public IPV4: http://178.104.25.112:8000
You can access Coolify through your Public IPv6: http://[2a01:4f8:1c19:f81a::1]:8000

If your Public IP is not accessible, you can use the following Private IPs:

http://10.0.0.1:8000
http://10.0.1.1:8000
http://2a01:4f8:1c19:f81a::1:8000
http://fdb0:c330:3639::1:8000

WARNING: It is highly recommended to backup your Environment variables file (/data/coolify/source/.env) to a safe location, outside of this server (e.g. into a Password Manager).


============================================================

[2026-03-19 11:02:44] Installation Complete
============================================================
[2026-03-19 11:02:44] Coolify installation completed successfully
[2026-03-19 11:02:44] Version: 4.0.0-beta.468
[2026-03-19 11:02:44] Log file: /data/coolify/source/installation-20260319-110120.log

After installation, you should find your self-hosted Coolify instance at http://[IP_ADDRESS]:8000:

You should see a Welcome to Coolify screen. Click Let's go!

Create your root account and on the next screen choose This Machine as your server type (we'll run everything on a single instance):

After the initial wizard, let's go to Settings (from the left menu) and input the instance URL with our (sub)domain we prepared for Coolify under General (make sure to include full URL including the leading https://).

Optionally you can also explore the Backup and Transactional Email tabs for setting up Coolify backups and transactional emails (for things like forgotten password).

Then head over to Servers (from the left menu) where you should see our localhost instance (running Coolify). Here you'll find settings for the Coolify components. Open it and go to the Proxy tab:

Checking that the proxy is running is important as it will route the traffic to the applications you'll self host. Even if Coolify is running and you are logged in inside the console, the coolify-proxy might not be.

In case the proxy is not running, open the logs and see what's wrong. In my case, the proxy wasn't running and I found the following inside the logs:

Creating required Docker Compose file.
Pulling docker image.
 Image traefik:v3.6 Pulling 
 Image traefik:v3.6 Pulled 
Ensuring network coolify exists...
Ensuring network havzqyfu212ybs9n5lg48gzy exists...
Starting coolify-proxy.
ParseAddr("fdb0:c330:3639::1/64"): unexpected character, want colon (at "/64")

There seemed to be an issue with parsing an IPv6 address. To resolve it I decided to turn off IPv6 support on the system. I opened an SSH connection to the server again to edit Docker's daemon.json file:

vi /etc/docker/daemon.json

I added an entry with "ipv6": false:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "default-address-pools": [
    {"base":"10.0.0.0/8","size":24}
  ],
  "ipv6": false
}

Then I restarted Docker:

systemctl restart docker

After that I could restart the proxy and see coolify-proxy container running on the system.

And that was it! If you can log in and see that the proxy is running, you are ready to start adding individual applications and services. You can still also use a hosted version of Coolify if you never set up a server before and all of this looks daunting.

Deploying resources

Resources in Coolify needs a project, so open Projects from the left side menu, and click + Add next to Projects. Then click + New next to the Resources headline. You should arrive on a New Resource page which lets you choose what you want to run. You can deploy directly from a git repository, Dockerfile or custom Docker Compose.

One-click services

One-click services are pre-configured Docker Compose templates provided directly by Coolify, skipping the complexity of manual setup and configuration. They are the easiest to start with.

Scroll a bit down and you should see them:

Coolify also maintains a directory for these services on the web. Some of services you can add are:

Internal tools: Appsmith, Budibase, NocoDB.
Chat & messaging: Matrix, Mattermost, Rocket.Chat.
Development & CI/CD: VS Code Server, Gitea, Jenkins.
Monitoring & analytics: Bugsink, CloudBeaver.
CMS: WordPress, Ghost.

They are all pretested, optimized, and coming with sensible defaults.

Custom services

Custom services in Coolify are those that you deploy with your own Docker Compose file. They require a little bit more work, but allow you to run almost anything. Have a look at how to deploy SerpBear, a SEO tool for keyword tracking as an example of a custom service.

Next steps

If you are new to self-hosting make sure to learn a little bit more about SSH, DNS, Linux, Docker, and related topics. You should also have a look at the Coolify documentation for even more information and tips.

I wrote a handbook for Kamal

Josef Strzibny — Fri, 05 Apr 2024 08:49:28 +0000

Kamal is an imperative deployment tool. It's basically a successor to Capistrano, but for a container era. It's a simple wrapper around Docker and that's the whole beauty of it. 37signals created Kamal to self-host Basecamp and Hey as part of their pull out of the cloud (running managed K8s).

I am always for simplicity when it comes to deployment and the truth is that lots of projects out there don't need the fully-featured Kubernetes to run. When Kamal was released I got intrigued and slowly adopted the tool. Nowadays I deploy all new projects with it.

Since the documentation is a little sparse at the moment and some people trying Kamal abandoned the effort when they faced their first issues, I decided to do something about it and wrote 'the missing manual' to Kamal called Kamal Handbook.

The book goes through all the important aspects of deploying with Kamal, describes the design choices and explains what's happening under the hood with illustrations. It's by design a small book you can read in a weekend. Hope you'll like it.

I just released InvoicePrinter 2.0

Josef Strzibny — Wed, 02 Oct 2019 11:50:08 +0000

InvoicePrinter is a Ruby library, server, and command-line client to make beautiful PDF invoices without browsers in no time. It's pure Ruby, but can be also used outside the Ruby world as a Docker container with a simple JSON API.

New features in 2.0:

New modern look & feel
More flexible buyer/seller boxes
Server is decoupled to a separate gem invoice_printer_server
New bundled fonts in a separate gem invoice_printer_fonts
Official Docker image
Prawn 2.2

Here is the project GitHub page, in the examples/ directory you can find a lot of code examples and how they look as PDFs. Follow docs/ to learn more about using it as a library, server or a command-line client.

Here is one example (download the final PDF):

And Ruby code to generate it:

#!/usr/bin/env ruby
# This is an example of a international invoice with Czech labels and English translation.

require 'invoice_printer'

labels = {
  name: 'Faktura',
  provider: 'Prodejce',
  purchaser: 'Kupující',
  tax_id: 'IČ',
  tax_id2: 'DIČ',
  payment: 'Forma úhrady',
  payment_by_transfer: 'Platba na následující účet:',
  account_number: 'Číslo účtu',
  issue_date: 'Datum vydání',
  due_date: 'Datum splatnosti',
  item: 'Položka',
  quantity: 'Počet',
  unit: 'MJ',
  price_per_item: 'Cena za položku',
  amount: 'Celkem bez daně',
  subtotal: 'Cena bez daně',
  tax: 'DPH 21 %',
  total: 'Celkem'
}

# Default English labels as sublabels
sublabels = InvoicePrinter::PDFDocument::DEFAULT_LABELS
labels.merge!({ sublabels: sublabels })

first_item = InvoicePrinter::Document::Item.new(
  name: 'Konzultace',
  quantity: '2',
  unit: 'hod',
  price: 'Kč 500',
  amount: 'Kč 1.000'
)

second_item = InvoicePrinter::Document::Item.new(
  name: 'Programování',
  quantity: '10',
  unit: 'hod',
  price: 'Kč 900',
  amount: 'Kč 9.000'
)

provider_address = <<ADDRESS
Rolnická 1
747 05  Opava
Kateřinky
ADDRESS

purchaser_address = <<ADDRESS
Ostravská 1
747 70  Opava
ADDRESS

invoice = InvoicePrinter::Document.new(
  number: 'č. 198900000001',
  provider_name: 'Petr Nový',
  provider_lines:  provider_address,
  provider_tax_id: '56565656',
  purchaser_name: 'Adam Černý',
  purchaser_lines: purchaser_address,
  issue_date: '05/03/2016',
  due_date: '19/03/2016',
  subtotal: 'Kč 10.000',
  tax: 'Kč 2.100',
  total: 'Kč 12.100,-',
  bank_account_number: '156546546465',
  account_iban: 'IBAN464545645',
  account_swift: 'SWIFT5456',
  items: [first_item, second_item],
  note: 'Osoba je zapsána v živnostenském rejstříku.'
)

InvoicePrinter.print(
  document: invoice,
  labels: labels,
  font: File.expand_path('../../assets/fonts/overpass/Overpass-Regular.ttf', __FILE__),
  logo: File.expand_path('../logo.png', __FILE__),
  file_name: 'promo.pdf',
  page_size: :a4
)

Before the final release I wrote a little background post on my blog.

Try it out and let me know what you think!

Django 2.2 polls app tutorial source code commit by commit

Josef Strzibny — Tue, 09 Apr 2019 22:47:01 +0000

TL;DR

I went through the famous Django "polls" app tutorial, and made it into a git repository which you can follow commit by commit:

GitHub link: deployment-from-scratch/django-2.2-polls

Tutorial link: Writing your first Django app

It's for Django 2.2.

Full Story:

Since the beginning of time (me wanting to leave PHP development) I was intrigued by Ruby on Rails and Django frameworks. I liked both for different reasons, but ended up doing mainly Rails because of Ruby the language (and living with a syndrome that I might made a mistake ever since).

Fast forward to 2019, and I am writing a book on deploying web application where I am trying to teach deployment of both Ruby and Python apps. There are pretty similar in that regards actually, but I needed some Python examples.

For this reason, I went to the Django site after many years (it's a lie, I keep watching Django space haha) and did the famous introductory tutorial of building "polls" app. I did it "commit by commit" so people can follow it easily while going through the tutorial.