DEV Community: Pavel Tkachenko

How NOT to Make Your Second Indie Game

Pavel Tkachenko — Fri, 13 Sep 2024 18:24:11 +0000

Our game is finished and will be released on October 22, 2024. But, this isn’t a typical success story. Since my previous post gained some attention, I decided to share my experience with this game. Hopefully, it will be helpful to someone out there.

Backstory

There was a gap of several years between my first attempt at making a game and this second one. I was working as a web developer, but my thoughts always lingered on game development. At the beginning of 2023, my teammates and I decided to give it another shot. We thought we’d become a little wiser and opted for a simpler genre—Match3. We thought it would be easy...

We were inspired by Puzzle Quest 2, a Match3 game with RPG elements where the AI plays against you, and you build strategies with skills. We also looked at The Mirror, a simple Match3 game with lots of nude characters. Also it has unique mechanic of Harem (which we doesn't have). But seeing that the quality of NSFW games on Steam wasn’t very high, we thought we could try to compete by mixing Puzzle Quest 2 with The Mirror.

First Attempt at the Story

For two weeks, I worked on an MVP to test our concept. I used Unity, grabbed some assets online, and created one playable level with predefined skills. To our surprise, it worked, and it was fun! So, we pushed forward.

We brainstormed a story: Alex, our main character, is an inventor and time traveler from the 1970s, with a car-mobile home that resembles the DeLorean from Back to the Future. Alex would travel through different eras, fighting enemies and collecting items to decorate his mobile home.

And thus, the name of the game was born -- Chronobabes.

We hired a talented artist who designed our game’s characters. However, we quickly realized that the 70s-style UI clashed with the different time periods, and the mobile home mechanic wasn’t as fun as we thought. It also consumed a lot of development time, so we scrapped it.

Our first enemy, Ai'Nu, a matriarch from the Prehistoric Epoch, was well-designed, but the artist wasn’t satisfied. The character lacked the vibrancy he envisioned.

Second Story Iteration

After some brainstorming, we revamped Alex’s background—now he’s from the 1920s, traveling in a red telephone booth, a nod to Doctor Who. This new concept aligned well with all the epochs we had in mind: Prehistoric, Ancient Egypt, Hellenistic Greece, the Fairy East, and Ancient China.

Ai'Nu was redrawn, and this time she was both adorable and alluring. We loved the style and used it for all the other enemies. We also used Cubism2D for the animations—such a satisfying moment for the team!

New Mechanics

I initially stuck to the "develop within constraints" rule, but I couldn’t resist adding more features. After playing Slay the Spire, I thought it’d be fun to incorporate a deck-building system. So, we added it, along with tokens like poison and regeneration, and artifacts! This brought unique mechanics to the game but introduced balancing and testing nightmares. Also each mechanic is another brick to localization complexity.

The development process became more complex—each mechanic had to be tested, balanced, drawn, programmed, and animated. I was on the verge of falling into the trap of feature creep again, but luckily, I caught myself in time.

We also added puzzle-like battles where the player can’t use skills and has to defeat the enemy under special conditions. There are four of these battles in the game, and they’re worth trying!

Balancing

The game now has over 70 skills, with both players and enemies having their own. We also added special abilities to enemies, giving each battle a unique twist. Every skill had to be drawn, programmed, and animated. But that wasn’t the hard part—balancing was.

Each battle, skill, and enemy needed to be tested multiple times. Actually, many, many times. And still, you’ll never get it perfectly balanced. After dozens of iterations, we finally reached a point where we felt it was fun. We even added some difficult but solvable battles where the key is to exploit the enemy’s weaknesses.

Scenario Editor

As development progressed, we needed a way to manage the growing complexity of the story, dialogues, and events. Unity’s interface wasn’t cutting it, so I created a scenario editor—a custom tool that allowed us to easily build and connect story nodes. This made the process much smoother and faster.

Interested in how I made it? Let me know if you’d like a tutorial!

Steam is against us

When our first epoch was ready, we set up a Steam page—uploaded the video, screenshots, and description—and were promptly rejected. Steam required the entire game to be completed before allowing NSFW games to have a page. We were disappointed since the Steam page is crucial for marketing, but we pressed on.

It took nearly another year to finish the game, and after several back-and-forth rejections and fixes, we finally received approval. Our Steam page went live—what a moment!

Steam is for us

Although our Steam page wasn’t approved until September 2024, causing us to lose valuable marketing time, Steam’s marketing tools are excellent. We used curators, wishlists, discounts, and events, and finally started gaining some attention. Right now, we’re getting 10-15 wishlists per day, and we’re hoping for a boost during the October Steam Fest!

Conclusion

Here we are. The game is finished, but I’m not expecting it to be a huge success in terms of sales. I’d be happy to sell at least 2,000 copies, but more than anything, I want positive feedback. That’s what keeps me passionate about making games. Next time, though, I’m starting with marketing, not development. I hope my story helps someone. Here are a few key takeaways:

Avoid NSFW games, especially for your first project.
Keep your game’s scope narrow.
Focus on gameplay first! If your game isn’t fun with basic elements, it won’t be fun with great graphics.
Match3 games are more complex than they seem, especially when combined with RPG mechanics.

10 tips to successfully create a Unity game MVP

Pavel Tkachenko — Fri, 04 Aug 2023 06:18:43 +0000

Hey there! I'm back! Game development is a tough process, and many games fade away even before reaching the MVP stage. MVP stands for Minimum Viable Product – something playable that can be showcased to others.

🚀 Here are 10 tips to successfully create an MVP for your Unity game:

1. Concentrate on core gameplay

You have to make sure that your core gameplay is fun. It may be just circles, triangles, and squares, but if you like to play it, then the idea is worth being developed. Content, animations, and other stuff can be added later.

2. Create constraints

The natural tendency of each game developer is to add more and more features (Feature creep) until you lose focus and energy to continue. Try the opposite approach, and reduce them all the time. Here is a great video on how to develop your game using constraints from FTL and Into the Breach developers: https://www.youtube.com/watch?v=s_I07Iq_2XM

3. Create what you play

If you don't like shooters, don't create them. If you don't play mobile games, don't create them. Concentrate on genres and platforms you are familiar with. Your gaming experience is one of the most important things in game development. Your mental health is even more important, so do what you like.

4. Save your time

Game development is not free. Even if you don't spend your money, you spend your time, which is more valuable. Try to save your time by buying ready-to-use assets. If you need a dialog system in the game, don't spend time creating it; buy it on the Unity Asset Store for the price of one dinner.

5. Duplication is better than wrong abstraction

Do not try to create a perfect architecture for your game at the MVP stage. It's better to have imperfect code for MVP rather than spending hours on something that is not playable. You can always refactor your code later.

6. Don't polish

Polishing is a great way to waste your time. You can spend hours creating a perfect animation for your character, but it takes 80% of your time for 20% of the result. MVP is like an Impressionist painting; it's better to have a rough sketch than a perfect picture. Impress people with overall gameplay, not with details.

7. Learn from others

Try to find a game that is similar to yours and play it. Developers of these released games have already solved a lot of problems you will face. You can learn from their mistakes and successes.

8. Don't be afraid to fail

It's okay to fail at any stage; the next try will be better. Now I'm able to create MVPs fast, but my first game attempts were disastrous. Here is my story of my first game development attempt: https://dev.to/pashagray/how-not-to-make-your-first-indie-game-39l8

9. Don't be afraid to throw away

If you see that the game is not playable, just put it in the trash. That's why MVP is needed – to test your idea. You can have several MVPs before you find a good one.

10. Eat, sleep, walk

It's easy to forget about your health when you are focused on your game. Take time for healthy food, 8 hours of sleep, and a bit of exercise. It takes time, but you will be more productive if you are healthy. This is your main asset, don't forget about it.

Conclusion

MVP is a great way to test your idea. It's better to spend 1 month on an MVP and understand that your idea is not good, than spend 1 year on a game that nobody will play. Create your MVP, show it to other people, and start to work on a full game if people like it. Otherwise, start from the beginning until you are satisfied with the result.

Tell me about your MVP experience in the comments!

P.S. I'm working on Chrono Babes game now. Follow for updates if you like the game!

Rails tricks you may not know

Pavel Tkachenko — Mon, 03 Oct 2022 05:57:39 +0000

I see a lot of new Rails developers struggling with some of the basics of the framework. I've been using Rails for a while now, and I've picked up a few tricks along the way. I thought I'd share these tricks with you.

One action, many methods

Sometimes it is usefull to have one action, but make it work with both get and post (or any other). For example, if you have a page where user can generate a report. User requires to select some dates in range, and then click button to generate report. And what I often see is that people create two actions inside the controller:

# app/controllers/reports_controller.rb
class ReportsController < ApplicationController
  def super_report
    # render form
  end

  def super_report_post
    # generate report
  end
end

# config/routes.rb
get 'reports/super_report', to: 'reports#super_report'
post 'reports/super_report', to: 'reports#super_report_post'

But there is a better way to do this. Choose the style you like:

# config/routes.rb

# Option one
get 'reports/super_report', to: 'reports#super_report'
post 'reports/super_report', to: 'reports#super_report'

# Option two
match 'reports/super_report', to: 'reports#super_report', via: [:get, :post]

And in controller:

# app/controllers/reports_controller.rb
class ReportsController < ApplicationController
  def super_report
    if request.post?
      # generate report
    else
      # render form
    end
  end
end

Now we don't split our logic into two actions, but we have one action that works with both get and post. It looks nicer, easier to read and maintain.

Namespacing

Namespacing is a way to group controllers and routes. It is usefull when you have many controllers and you want to group them. For example you have controllers: PostsController, Admin::UsersController and Admin::PostsController. You want different views for admin and want authentication for it.

# config/routes.rb
resources :posts

namespace :admin do
  resources :users
  resources :posts
end

Now you can access Admin::UsersController with url /admin/users and Admin::PostsController with url /admin/posts. You should also use namespace inside the controller:

# app/controllers/admin/users_controller.rb
class Admin::BaseController < ApplicationController
  layout "admin" # special view layout for admins

  before_action :authenticate_admin!
end

class Admin::UsersController < Admin::BaseController
  # ... Only admin can work with it
end

class Admin::PostsController < Admin::BaseController
  # ... Only admin can work with it
end

# Views structure
app/views/layouts/admin.html.erb
app/views/posts/
app/views/admin/posts/
app/views/admin/users/

Scoped associations

Let's say we have two models: User and Post. And we want to get all posts for user. We can do this:

class User < ActiveRecord::Base
  has_many :posts
end

class Post < ActiveRecord::Base
  belongs_to :user
end

user = User.first
user.posts

But what if we don't ever want to include posts for user which are published? Often I see people doing this:

class User < ActiveRecord::Base
  has_many :posts
end

class Post < ActiveRecord::Base
  belongs_to :user

  scope :published, -> { where(published: true) }
end

user = User.first
user.posts.published

And this is fine, but you can somehow forget to add published scope to your query. And then you will get all posts, even unpublished. And this is not what you want. Some people use default_scope for this, but it is not good idea. So what we can do? We can use scope in association:

class User < ActiveRecord::Base
  has_many :posts, -> { published }
  has_many :not_published_posts, -> { not_published }
end

class Post < ActiveRecord::Base
  belongs_to :user

  scope :published, -> { where(published: true) }
  scope :not_published, -> { where(published: false) }
end

user = User.first
user.posts # only published posts here

Migrations are not only for schema building

You can use migration to add some data to your database. For example you have model User and you want to create admin with id -1 to database, so anywhere, in any environment you want to be sure, that such user exists. You can do this:

class AddAdmin < ActiveRecord::Migration
  ADMIN = User.find_by(id: -1)

  def up
    User.create(name: 'Admin', id: -1, admin: true) unless ADMIN
  end

  def down
    ADMIN.destroy if ADMIN
  end
end

Wrapping up

I hope you will find these tricks useful. If you have any other cool examples, please share them in the comments.

P.S. Cover image is generated using DALL·E 2

How NOT to make your first indie game

Pavel Tkachenko — Thu, 23 Dec 2021 10:53:39 +0000

This is definitely not a success story, but an example of how to fail a project, despite on good enough programming skills and a big desire to create games. This topic will be useful for people want to be indie-game developers or already started to create The Big Dream Project.

The beginning

As almost every software developer, my passion for programming started when I opened the door to beautiful world of videogames. When I was a schoolboy, I was spell-bounded by all magic happening in buzzing box under my table. At first you just enjoy the game, but after a while you want to investigate how it works. And I started to make first step to puzzle out this mystical world.

In the early 2000s, there were no game development courses yet, there were no mentors, and only a select few had the Internet (Especially in Kazakhstan, where I was born). My acquaintance with game development began with WarCraft, which was released in 2002. After going through the campaign and playing multiplayer with friends (we had a local network between houses), I found the "World Editor" icon in the game files. It turned out to be a map editor, and most importantly, it has its own programming language JASS, with which it is possible to do almost anything, limited only by the developer's imagination. This is how the first Dota was made by the way.

At that time, I did not know what variables, loops and functions are. I sat in front of the monitor for hours and on an intuitive level tried to figure out all these things. In the end, I even managed to make an analogue of Diablo directly on the WarCraft engine, which my friends later played. Time passed, I mastered 3D Studio Max, Photoshop, Flash, but I didn't seriously develop games. I got an excellent book on programming "How to Program in C ++" by Deitel, where I already plunged headlong into the world of computer software development. Studied C ++, finished several books on Java, mastered HTML/CSS and javascript. Afterall, despite on passion for Computer Science, after graduating from school, I went to college in a completely different specialty and programming was just a hobby for me. (There were no good Higher Education CS programs in Kazakhstan in 2006).

The Second Attempt

Kazakhstan lagged behind the world in the field of IT for several years. I returned to the software development industry in my second or third year of studying in University, it was a time of active growth of Internet speed, various startups appeared. Having a good basic understanding of how to write code, but not having an understanding of how to make a "Product", I realized that I needed a mentor. And I was very lucky, I met a person who took me under his wing. I have mastered Ruby and successfully burst into the world of software development. Several years passed. Ultimately, there was a desire to plunge into the world of computer games again, excellent tools appeared, such as Unity, Unreal Engine, Godot. In addition, I was motivated by the successful case of my friends, Katata Games, a family development studio, who released the "Top Run" mobile game, which reached 100,000 downloads in the AppStore and Play Market.

And I started to create my first game. From previous web programming experience, I knew that you can't grasp the immensity, that you need to start small. As a result, the idea was born to create a mobile game about a drill, on which you need to reach the core of the planet. With each next attempt, the drill can be improved, increasing your piloting experience and gradually reaching ever greater depths. My main goal was to create a product, albeit small, albeit simple, but complete. As a result, I fell into a trap. I have never played mobile games, I have always been interested in the PC with its hardcore and multifaceted games. And I decided that since I know the PC games market well, it won't be difficult for me to make a game specifically for PC.

I have connected different ideas into one blanket. As a result, the idea of a game was born, which I called Shoot.Pray.Run., A top-down action-rpg about a war monk who descends into hell to defeat the main evil, simultaneously destroying all enemies along the way. The "Priest" movie made a big impression on me with its style, so I took it as a basis. I took the system of dungeons from Diablo 1, where you have to constantly go lower and lower into hell, and game mechanics were taken from "Enter the Gungeon". Everything was simple in my head, I improved skills in pixel art, also found a good artist for characters.

All sketches were made by me to simplify the explanation of tasks to the artist (e.g. main character, skeleton and banshee):

Unity conquered me, I quickly figured it out and it seemed that with it I would do almost any project (Dunning-Kruger Effect). The code flowed like a river, and the game started to take it form. And then I made a mistake, I decided to leave my main job to male the game from morning to evening, every day. If you do not have experience in game development, then by no means do this, there are too many pitfalls in this industry. As soon as I started working on game full-time, the thought came to me that I could do more than I had planned. And here I again fell into the trap of a large project, it was not small anyway, and I began to wind up a lot of different mechanics there.

First I made volumetric light, then I came to 3D with 2D imitation. I wanted to keep the pixel art, but give it a depth. This required rewriting the camera so that it did not distort the textures of the walls and floor at an angle of 45%, but left them pixel-perfect drawn. I dived into shaders, started expanding the game with these beauties, created water, steam, heat effects, etc. The cherry on top is the object destructibility system. I wanted everything in the game to be destroyable. This not only made the code and art more complicated, but would also lead to game design problems in the future. The result was a huge monster, the project grew larger and larger, I had already spent several months, but it was not yet possible to play the game. It was just a collection of all sorts of technical wow-effects, but there was no gameplay itself.

Depression knocked to my door and I started to understand that I was trying to bite off too large a piece, but I did not stop. Despite the awareness of the problem, I walked like a tank into the abyss. Continued to complicate minor things, not paying attention to the gameplay itself. Added gender selection so that you can play as a woman. We prepared various cool arts for twitter and reddit, but there was still no game. In total, I have already spent about five months, but I did not even have the first level.

My financial reserve provided me for a year of work, but I understood that at this pace I would be making the game for a couple of years, no less (and this was an optimistic forecast). The development did not bring any pleasure or satisfaction any more. Only the fear grew that I would be left with nothing. I had the will to stop developing the game and return to my usual job as a web programmer.

Now

In my free time, I continue to work with Unity, make some small games and mechanics. I am improving my skills in various aspects of game development: game design, programming, art. I may return to serious game development in the distant future, but I will definitely try not to make the same mistakes again.

Lessons I learned:

Do not quit your main job if there is no finished game project yet
Focus on game core. The game should be interesting even if it is assembled from squares and other primitives. Complexity and beauty can always be added later.
Create a fully working product, albeit small, albeit crooked and oblique. The ability to complete a project is the most useful thing in game development, and in any other industry.

"Back to the future" or how to test time-based logic in Rails

Pavel Tkachenko — Tue, 21 Jul 2020 15:54:02 +0000

"Back to the future" or how to test time-based logic in Rails

If time travel is possible, where are the tourists from the future? - Stephen Hawking

Almost every app works with time-based logic. How can you test that the post is outdated, bills are already expired or user is late for the plane. In this post you will learn RSpec approaches to test such a time-rich logic.

Let's start from simple example. We have model Post with attribute published_at and we want a method outdated?, which returns true if post was published more than one week ago.

class Post < BaseModel
  def outdated?
    published_at < Time.current - 7.days
  end
end

Let's try to test it properly. The simplest solution is to create post, which is published more than 7 days ago and invoke this method.

describe Post do
  describe "#outdated?" do
    context "when more than a week has passed since publishing" do
      subject { Post.create(published_at: Time.current - 8.days) }

      it "returns true" do
        expect(subject.outdated?).to eq(true)
      end
    end
  end
end

But sometimes it is hardly achievable, especially when we need to be at the particular point in time. Let's assume that post can not be published on Friday. Everyone is drinking and can publish something what one will regret all their life, I am sure you know.

def can_be_published?
  !Time.current.friday?
end

And now to test such case for false return, we need to be in the particular point in time -- a Friday. You can achive that with a help of timecop gem.

describe Post do
  describe "#can_be_publised?" do
    context "when current date is friday" do
      # Set current time to friday
      Timecop.freeze(Time.new(2020, 6, 10)) do # 2020/06/10 is a Friday
        it "returns false (can't be published)" do   
          expect(subject.can_be_publised?).to eq(false)
        end
      end
    end
    context "when current date is Saturday" do
      Timecop.freeze(Time.new(2020, 6, 11)) do # 2020/06/11 is a Saturday
        it "returns true" do                 
          expect(subject.can_be_publised?).to eq(true)
        end
      end
    end
  end
end

As you can see we can jump to the particular point in time with timecop gem. Isn't that cool? I suggest to rewrite spec for outdated? method using timecop.

describe Post do
  describe "#outdated?" do
    subject { Post.new(published_at: Time.current) }
    context "when more than a week has passed since publishing" do
      Timecop.freeze(Time.current + 8.days) do
        it "returns true" do                     
          expect(subject.outdated?).to eq(true)
        end
      end
    end
  end
end

Looks much more natural. We don't stuff our post attributes with other values but simply jump in time to check time-based logic. It becomes especially useful when time logic is really tricky and you need to show other developers that you are testing something in the future or in the past.

Another interesting feature is scaling the time. We can make it flow faster or slower. Imagine that you have some method which calls sleep for a limited time.

class ExternalApi
  def emulate_throttling
    # some logic
    sleep(5)
    # another piece of logic 
    sleep(5)
    # and another one piece
  end
end

You definetelly don't want to wait for 10 seconds for test to complete. With TimeCop we can reduce that time.

describe "#emulate_throtling" do
  it "run some external API without bloating it with requests" do
    Timecop.scale(100) # 100x speed up of time
    subject.emulate_throttling
    Timecop.scale(1) # return back
  end
end

Look, we increased the speed a hundred times, so our test passes not in 10 seconds, but in 0.1 seconds. Awesome, isn't it?
As we can see time in Ruby is flexible and you can control it. TimeCop is a must have tool for testing your time-sensitive logic.

GitHub auto README with ruby, github-actions and dev.to API

Pavel Tkachenko — Fri, 17 Jul 2020 05:44:03 +0000

A brand new cool thing from github: you can create your own unique readme. And the ability to do this automatically is generally a gift for any software engineer. I'v read How I Built A Self-Updating README On My Github Profile article and it impressed me a lot. Thanks Michael! In this article Michael Hoffmann provided ready-to-use JS script, but this script parses his own site and doesn't use dev.to API. Also this article doesn't provide step-by-step guide for beginners. And finally, the biggest problem here is JS. Everyone loves ruby, not JS, it is an indisputable fact! That's what I want to fix.

Today we will be creating an automated README update with your recent posts from scratch using github-actions, ruby and dev.to API. At the end you will have a basic understanding of how github-actions works, how to use it properly with ruby (including gem installation) and how to handle secret ENV variables.

DEV.TO API

To work with API, we need to get API key. Go to https://dev.to/settings/account, find "DEV API Keys" section and generate your personal API key with any description you like (I called it "Auto update my GitHub Readme"). Keep it in secret please!

Now you can go to DEV.TO API Documetation. There is a lot of cool stuff here. We need User published articles page. It allows you to fetch your published articles. That's what we are looking for! Let's check if API is working and key is valid. Open your terminal and paste:

curl -H "api-key: YOUR_API_KEY_HERE" https://dev.to/api/articles/me/published

If everything is ok, you will receive a JSON with all your published posts. We need title, url and description from this JSON.

Personal README

Open GitHub and create public repo with the same name as your GitHub account name. Don't forget to initialize README.md to let magic happen. You should see that your account page github.com/your_account/ has README with "Hi there 👋" message. Now you have basic README that you can edit, but we are going to automate this process.

GitHub Secrets

Now we need to provide our DEV.TO API key to GitHub environment. Open Settings tab in your_account_name/your_account_name/ and tap "Secrets" link. Add a new secret, name it DEV_TO_API_KEY and paste your API key as the value.

Create you first script

Clone your repo. Add folders scripts/rb/ and create file update_readme.rb. We will use faraday gem to fetch posts from API. You can use ruby built-in NET::HTTP module, but I want you to show how to handle gem process installation with github actions.

# ./scripts/rb/update_readme.rb
require "json"
require "faraday"

# Get all posts
# Take a look how we obtain our secret key by using ENV[]
response = Faraday.get(
  "https://dev.to/api/articles/me/published",
  {},
  { "api-key": ENV["DEV_TO_API_KEY"] }
)

# Retrieve `title`, `url`, and `description` and
# wrap it to markdown syntax
posts = JSON.parse(response.body).map do |article|
  <<~EOF
  __[#{article['title']}](#{article['url']})__
  #{article['description']}
  EOF
end

# Generate your own layout and paste posts in it
# Don't forget to change text and name =)
markdown = <<~EOF
# Hello friends!
I'm a fullstack ruby and js developer. Follow me on [Dev.to](https://dev.to/pashagray)
My last publications:
#{posts.join}

Script is provided by https://github.com/pashagray
EOF

# Write you markdown to README.MD
File.write("./README.md", markdown)

That's all! git push all your changes back to GitHub.

GitHub Actions

Open Actions tab in your_account_name/your_account_name repo and create new workflow. There are a lot of templates, but you can initialize any or empty and paste code I provided below. Don't worry, every line has a comment.

# Name of your workflow
name: README Update
# Triggers to run workflow
on:
  # workflow_dispatch allows to run your workflow manually
  workflow_dispatch:
  # Run workflow based on specific schedule
  schedule:
  # This workflow will run every day at 00:00 UTC.
  # You can use https://crontab.guru/ if cron syntax is
  # looking weird for you
  - cron: "0 0 * * *"

jobs:
  # This workflow contains a single job called "perform"
  perform:
    # The type of runner that the job will run on
    # ubuntu-latest is default
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
    # This line to work properly with repo
    - uses: actions/checkout@v2
    # This one to activate ruby magic
    - uses: actions/setup-ruby@v1
      with:
        ruby-version: '2.7'
    # First we need to install Faraday gem. You can use ruby built-in NET::HTTP
    # class, but I want to show you how to work with gems in github-actions
    - name: Install gems
      run: gem install faraday
    # And now we run our script
    - name: Run script
      # Here we are setting our secret API Key
      # Details: https://docs.github.com/en/actions/configuring-and-managing-workflows/using-variables-and-secrets-in-a-workflow
      env:
        DEV_TO_API_KEY: ${{ secrets.DEV_TO_API_KEY }}
      run: ruby ./scripts/rb/update_readme.rb
    # Our script updated README.md, but we need to commit all changes
    - name: Commit and push if changed
      run: |
        git add .
        git diff
        git config --global user.email "github-action-bot@example.com"
        git config --global user.name "GitHub Action Bot"
        git commit -m "Updated README" -a || echo "No changes to commit"
        git push

Save your action and check it. Go to Actions, find your update README action and push "Run workflow" button.

After workflow will be finished, go to your account page and enjoy it!

You can follow my repo and grab all ready to use code:
https://github.com/pashagray/pashagray

Simple pub/sub pattern (OOP) using pure Ruby

Pavel Tkachenko — Thu, 16 Jul 2020 07:20:37 +0000

Pub/Sub is a popular pattern for reducing coupling and increasing system modularity. In the Publish-Subscribe model, subscribers await for events they are interested in, and get notified of any event generated by a publisher that matches their registered interest.

To simplify, imagine a radio station (publisher). You (subscriber) tune into the wave of this radio station (subscribe) and start to sing along when you hear a Blink-192 band song (react to event).

In details

This is a very convenient pattern when you have many parts of the program that must respond differently to an event. For example, imagine a site where user is registered. In this case, an email should be sent, the service of collecting information on the user in social networks should start and many other things. If everything is done in one place, then you will get high coupling and this monster will be hard to maintain. In the pub/sub pattern, you have a service that creates a user and broadcasts a message to everyone who is interested in user creation. All other services isolated from each other will perform the necessary work as soon as they receive the event they need.

There are a lot of solutions providing Publish-Subscribe capabilities. From small libraries (One of them a wisper gem), to huge projects like RabbitMQ or Kafka. But to understand how it works, we will build our simple personal solution and investigate.

Our demo

We are building our own Walmart. Let's start with three classes (Item, Checkout and Printer). When cashier scans an item, it should be added to checkout and immediatelly printed. Read the code below carefully. Here is the classical solution. We inject Printer as dependency to our Checkout and call print on it every time item is added. What problem we have here? Checkout needs to now how Printer works, that it has print method. When you have a lot of classes and interactions, that can be problematic.

class Item
  attr_reader :code, :title

  def initialize(code:, title:)
    @code = code
    @title = title
  end

  def to_s
    "#{@code} #{@title}"
  end
end

class Checkout
  attr_reader :items

  def initialize(printer: Printer.new)
    @printer = printer
    @items = []
  end

  def add(item)
    @items << item
    @printer.print(item)
  end
end

class Printer
  def print(message)
    puts "[#{Time.now}] #{message}"
  end
end

How we can solve this problem with pub/sub pattern. First, let's introduce Publisher module.

module Publisher
  def subscribe(subscribers)
    @subscribers ||= [] # if @subscribers is nil, we initialize it as empty array, else we do nothing
    @subscribers += subscribers
  end

  def broadcast(event, *payload)
    @subscribers ||= [] # @subscribers is nil, we can't do each on it
    @subscribers.each do |subscriber|
      # If event is :item_added occured with payload item itself
      # we send method :item_added to subscriber and bypass payload as argument if subscriber
      # responds to it.
      subscriber.public_send(event.to_sym, *payload) if subscriber.respond_to?(event)
    end
  end
end

And that's it. Let's refactor our business logic to work with Publisher module

class Checkout
  include Publisher

  attr_reader :items

  def initialize(subscribers:)
    @items = []
    subscribe(subscribers)
  end

  def add(item)
    @items << item
    broadcast(:item_added, item)
  end
end

class Printer
  def item_added(item)
    print(item)
  end

  private

  def print(message)
    puts "[#{Time.now}] #{message}"
  end
end

Let's check it

item1 = Item.new(code: "DRP", title: "Dr.Pepper")
item2 = Item.new(code: "CCL", title: "Coca-Cola")

checkout = Checkout.new(subscribers: [Printer.new])

checkout.add(item1)
checkout.add(item2)

#=> [2020-07-16 12:08:49 +0600] DRP Dr.Pepper
#=> [2020-07-16 12:08:49 +0600] CCL Coca-Cola

And now our Checkout class doesn't know anything about Printer implementation, it just sends event :item_added to it. You can say that it is looking more complex, but you will start to collect benefits with scaling the system. Imaging we add SoundManager class, which works with our sound card.

class SoundManager
  def item_added(_)
    beep!
  end

  def beep!
    print "\a"
  end
end

item = Item.new(code: "DRP", title: "Dr.Pepper")
checkout = Checkout.new(subscribers: [Printer.new, SoundManager.new])
checkout.add(item)

#=> [2020-07-16 12:08:49 +0600] DRP Dr.Pepper
# And you should hear "Beep" sound!

Again, our Checkout class doesn't know anything about SondManager implementation and internal logic. You just send event to it and SoundManager knows how to handle it!

You can find full final code here: gist.github.com

Pros and Cons of pub/sub

👍 Less coupling between classes
👍 High level of scalability
👍 Compact system tests for each isolated module
👍 Easy to implement
👎 Full process logic is not visible (You won’t be able to understand what happened with Checkout#add method call by simply looking at the class)
👎 You still need full integration tests to check system as a whole

Conclusion

We built the simplest example of such an architecture. There are many more complex solutions, for example, when Publisher needs to make sure that the subscriber received an event. Or when you need to send events asynchronously or after some time. It's a huge topics covering message brokers, data bus, queues, etc. If you are interested in it, I can go further and provide deeper tutorials.

How to impress employer at ruby technical interview with a help of Keanu Reeves [Fibonacci sequence]

Pavel Tkachenko — Fri, 10 Jul 2020 11:15:45 +0000

Classical puzzle for every junior developer is to find n in the fibonacci sequence. To be specific, it is a sequence where a number is the sum of the two preceding ones, starting from 0 and 1. So if you need to find 7-th element in sequence, the answer is 13.

0, 1, 1, 2, 3, 5, 8, 13, 21, 34

Let's solve this exercise using 3 popular movies with Keanu Reeves.

The Day the Earth Stood Still

In most cases interviewer want to see your understanding of recursion. This is one of the first headaches of novice developers (second is C pointers I guess).

The most simple expected solution is here:

def fib(n)
  return n if n <= 1

  fib(n - 1) + fib(n - 2)
end

fib(7) #=> 13

This solution is not effective. The time taken by recursive Fibonacci is O(2^n) or exponential. For more details follow this beginner friendly Big O notation guide A Rubyist's Guide to Big-O Notation. In our solution we calculate all numbers in range 0..n again and again for every n in sequence. For big numbers (>80) the quanity of computation steps can be more than there are atoms in our universe! At this point it would freeze not only your computer, but all Earth computation resorces forefer.

Let's loot at our call stack. When you call fib(7), it recursevery calls fib(6) and fib(5). fib(6) cals fib(5) again with all calculations from the start.

Johnny Mnemonic

If you are more experienced developer, you would probably add memorization to reduce number of calculations. And in most cases interviewer will be happy with such solution.

module Fib
  @memo = [0,1]
  def self.calc(num)
    return num if num < 2

    @memo[num] ||= self.calc(num - 1) + self.calc(num - 2)
  end
end

Fib.calc(7) #=> 13

Here we save every new number in sequence to @memo and do not calculate it again. What about complexity? It'll be O(n) where n is the number of numbers generated. Good enough.

The Matrix

But what if you want to impress your interviewer and provide O(log n) solution? Follow the White Rabbit!

require "matrix"

def fib(n)
  (Matrix[[1,1],[1,0]] ** n)[1,0]
end

fib(7) #=> 13

A lot of math here! Relax, the key point is that you can simply raise [[1,1][1,0]] matrix to the power of n. And extract your answer from new matrix at [1,0] or [0,1].

You can show that you did not skip classes of higher mathematics in college and most likely impress the interviewer with your solution. But always remember that you may be required to explain your matrix solution. Therefore, arm yourself with a math book, because it is not always boring, but often very useful and fun!

How to RSpec your sidekiq-scheduler

Pavel Tkachenko — Sat, 04 Jul 2020 13:07:39 +0000

sidekiq-scheduler is a pretty awesome tool to cron your sidekiq jobs. All you need is to add a schedule to your sidekiq.yml file.

Let's look at simple job with sidekiq-scheduler and yaml schedule itself.

# hello-scheduler.rbs
class HelloWorld < ApplicationJob
  def perform
    puts "Hello world"
  end
end

# config/sidekiq.yml

:schedule:
  hello_world:
    cron: '0 0 * * * *'  # Runs every hour
    class: HelloWorld

But how you can test it to be sure that schedule does't have errors, cron syntax is correct and job class exists? You know that it's very easy to mess up your cron syntax! I will show and explain a snippet you can copy-paste to your project which will automatically check your sidekiq.yml file for errors.

Create file sidekiq_schedululer_spec.rb in spec/jobs folder. Sidekiq-scheduler uses fugit under the hood to evaluate cron schedule. We will use it too, but for cron syntax checking. You don't need to add it in your Gemfile, because it's already included as a dependency in sidekiq-scheduler. The only thing is that you have to require it. Then we need to load our sidekiq.yml file and parse it to ruby hash and store in schedule variable.

require "rails_helper"
require "fugit"

RSpec.describe "sidekiq-scheduler" do
  sidekiq_file = File.join(Rails.root, "config", "sidekiq.yml")
  schedule = YAML.load_file(sidekiq_file)[:schedule]

  describe "cron syntax"
  describe "job classes"
  describe "job names" # optional
end

Here I defined three specs. We need to check that cron syntax (0 0 * * * *) is correct, job class (HelloWorld) exists and job name in schedule (hello_world) is similar to job class.

First is cron. We just take every value in the file and pass it to Fugit. If Fugit raises error because it is not able to parse cron string, test fails.

describe "cron syntax" do
  schedule.each do |k, v|
    cron = v["cron"]
    it "#{k} has correct cron syntax" do
      expect { Fugit.do_parse(cron) }.not_to raise_error
    end
  end
end

Second, we need to check that job class exists. We just need to constantize our class string and if it raises error, test fails.

describe "job classes" do
  schedule.each do |k, v|
    klass = v["class"]
    it "#{k} has #{klass} class in /jobs" do
      expect { klass.constantize }.not_to raise_error
    end
  end
end

Third, we can check that job name (hello_world) is similar to class name(HelloWorld). It can be easily done by underscoring class name and compare it with job name.

describe "job names" do
  schedule.each do |k, v|
    klass = v["class"]
    it "#{k} has correct name" do
      expect(k).to eq(klass.underscore)
    end
  end
end

Full snippet is here. You can just copy and paste it in your project.

require "rails_helper"
require "fugit"

RSpec.describe "sidekiq-scheduler" do
  sidekiq_file = File.join(Rails.root, "config", "sidekiq.yml")
  schedule = YAML.load_file(sidekiq_file)[:schedule]

  describe "cron syntax" do
    schedule.each do |k, v|
      cron = v["cron"]
      it "#{k} has correct cron syntax" do
        expect { Fugit.do_parse(cron) }.not_to raise_error
      end
    end
  end

  describe "job classes" do
    schedule.each do |k, v|
      klass = v["class"]
      it "#{k} has #{klass} class in /jobs" do
        expect { klass.constantize }.not_to raise_error
      end
    end
  end

  describe "job names" do
    schedule.each do |k, v|
      klass = v["class"]
      it "#{k} has correct name" do
        expect(k).to eq(klass.underscore)
      end
    end
  end
end

This technique is usefull not only for sidekiq-scheduler. You can parse and test any yaml/json files in your projects in this way. Good luck with your RSpec experiments!

Your own stimulus-like framework in 10 minutes [Part 1]

Pavel Tkachenko — Tue, 30 Jun 2020 11:10:47 +0000

Basecamp introduced very simple and powerful framework to make cool JS stuff. It is awesome to use, especially when you don't need the overwhelming React/Vue/Angular and you don't like jQuery spaghetti code. At first glance it looks like Rails magic, because many things are implemented using convention-over-configuration principle.

Let's call it Stimulator

I want you to build your own Stimulus-like framework right now with me. It's not a replacement of Stimulus, it has a lot of under-the-hood troubles, but we will implement all features of Stimulus and add more (which will be released in Stimulus 2.0). I will try to show you the simplest solution, step by step, so any JS beginner can understand the flow. Each step has a snapshot on github, where you can look it up in case you're lost.

If you are not familiar with Stimulus, please refer to https://stimulusjs.org/ and read small guide. I don't want to overwhelm this article with Stimulus concepts, so I expect that you already know them.

Ok, let's define what we want to implement. I took the very basic example from https://stimulusjs.org/ and adapted it a little bit to the structure that we will implement. Let's name our framework Stimulator!

<div data-controller="Hello">
  <input data-target="Hello.name" type="text">

  <button data-action="click->Hello#greet">
    Greet
  </button>

  <span data-target="Hello.output">
  </span>
</div>

// We will not use modules and import to simplify this tutorial
// import { Controller } from "Stimulus"

class extends Controller {
  // In stimulus you have to define targets like this
  // static targets = [ "name", "output" ]
  // but we will do it automatically

  greet() {
    this.outputTarget.textContent =
      `Hello, ${this.nameTarget.value}!`
  }
}

File structure

Let's start to build gradually. You don't need node_modules, gulp, yarn and all these heretic stuff. Create folder stimulator, and one file in it: index.html. Create html for our controller:

<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Stimulator</title>
</head>
<body>
  <!-- Our empty controller -->
  <div data-controller="Hello">

  </div>
</body>
</html>

Register controller

Now we need our Stimulator to find our Contoller. Create three files index.js, Controller.js and HelloController.js in script folder;

// script/Controller.js
// Here we will have all our logic
class Controller {

}

// script/HelloController.js
// Every controller you define in html page
// must have appropriate class.
class HelloController extends Controller {

}

// script/index.js
// We need it now only to initialize HelloController
new HelloController();

Don't forget to include your scripts in index.html. Set attribute defer, it will initialize your scripts after DOM will be ready.

<head>
  <!-- ... -->
  <script src="script/Controller.js" defer></script>
  <script src="script/HelloController.js" defer></script>
  <script src="script/index.js" defer></script>
</head>

Current code snapshot: https://github.com/PavelTkachenko/stimulator-dev-to/tree/file_structure

As you remember we need to find our controller on index.html page.

class Controller {
  constructor() {
    // Set our controller name
    this._setControllerName();
    // Find it (node) on the page
    this._setContainer();
  }

  // We just take our class name (e.g. HelloController) and
  // remove word "Controller" from it.
  // So our this._name is "Hello" now
  _setControllerName() {
    this._name = this.constructor.name.substr(0, this.constructor.name.length - 10);
  }

  // After we obtained name of the controller, we can find it on the page
  _setContainer() {
    this._container = document.querySelector(`[data-controller="${this._name}"]`);
  }
}

As you can see I use lodash(_) before properties and methods. It's a convention of declaring private properties and methods, because JS doesn't have them by design.

Open your index.html in browser, enter the developer console and initialize your HelloController by printing new HelloController();. You can see that controller successfully registered name and container.

Register targets

Next we need to register our targets. Expand your HTML part of controller.

<div data-controller="Hello">
  <input data-target="Hello.name" type="text">

  <button data-action="click->Hello#greet">
    Greet
  </button>

  <span data-target="Hello.output">
  </span>
</div>

Now we have two targets Hello.name and Hello.output. We need targets to easily find them in our Controller class.

Add new method _registerTargets to Controller base class:

  _registerTargets() {
    // Find all nodes with data-target attribute
    const targetElements = this._container.querySelectorAll("[data-target]");

    // Loop over nodes 
    Array.from(targetElements).forEach(element => {
      // Get value from data-target and add ability to define
      // more than 1 target separating them with ","
      // e.g. data-target="Hello.name,OtherController.foo"
      const dataTargets = element.getAttribute("data-target").split(",");
      // Loop over such targets
      dataTargets.forEach(dataTarget => {
        // Extract controller and target name
        const [controller, target] = dataTarget.split(".");
        // Assign target to controller if it belongs to it
        if (controller === this._name) {
          // e.g. For hello.name we now have
          // nameTarget property
          this[`${target}Target`] = element;
        }
      })
    });
  }

Don't forget to invoke method in your constructor

constructor() {
  this._setControllerName();
  this._setContainer();
  // Register our targets
  this._registerTargets();
}

Now check that your Controller can handle targets. Go to browser console, type new HelloController(), and you will see all targets in it.

Current code snapshot: https://github.com/PavelTkachenko/stimulator-dev-to/tree/register_targets

Register actions

Almost done. Finally we need to register our actions. Add method _registerActions to Controller.js. It is very similar to _registerTargets:

_registerActions() {
  // Very similar to _registerTargets, but
  // we also need to extract trigger to create
  // appropriate event listener
  const actionElements = this._container.querySelectorAll("[data-action]");
  Array.from(actionElements).forEach(element => {
    const dataActions = element.getAttribute("data-action").split(",");
    dataActions.forEach(action => {
      const trigger = action.split("->")[0];
      const funcName = action.split("#")[1];
      element.addEventListener(trigger, (e) => {
        // If function is defined in your Controller
        // it will be called after event triggered
        if (this[funcName] !== undefined) {
          this[funcName](e);
        }
      });
    })
  });
}

Don't forget to invoke method in constructor:

  constructor() {
    this._setControllerName();
    this._setContainer();
    this._registerTargets();
    // Register our actions
    this._registerActions();
  }

Now our framework is ready. Let's test it with our HelloController. Add method greet to it:

class HelloController extends Controller {
  greet() {
    this.outputTarget.textContent =
      `Hello, ${this.nameTarget.value}!`
  }
}

Current code snapshot: https://github.com/PavelTkachenko/stimulator-dev-to/tree/register_actions

Go to browser and check how it works!

Color mixer

Let's test our framework with a more difficult task. It will be color mixer, which produces color from Red, Green and Blue inputs. Also it has "Random" button to generate random color.

Let's start with our layout.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Stimulator</title>
  <script src="script/Controller.js" defer></script>
  <script src="script/ColorController.js" defer></script>
  <script src="script/index.js" defer></script>
  <style>
    .field {
      width: 200px;
      text-align: right;
    }

    .result {
      height: 200px;
      width: 200px;
    }
  </style>
</head>
<body>
  <div data-controller="Color">
    <div class="field">
      <label for="red">Red</label>
      <input name="red" type="number" min="0" max="255" data-target="Color.red">
    </div>
    <div class="field">
      <label for="green">Green</label>
      <input name="green" type="number" min="0" max="255" data-target="Color.green" >
    </div>
    <div class="field">
      <label for="blue">Blue</label>
      <input name="blue" type="number" min="0" max="255" data-target="Color.blue">
    </div>
    <div class="field">
      <button data-action="click->Color#mix">Mix colors</button>
      <button data-action="click->Color#random">Random</button>
    </div>
    <div class="result" data-target="Color.result"></div>
  </div>
</body>
</html>

Add our controller with logic.

class ColorController extends Controller {
  mix() {
    const r = this.redTarget.value;
    const g = this.greenTarget.value;
    const b = this.blueTarget.value;

    this.resultTarget.style.background = `rgb(${r},${g}, ${b})`;
  }

  random() {
    this.redTarget.value = this.randomInt(0, 255);
    this.greenTarget.value = this.randomInt(0, 255);
    this.blueTarget.value = this.randomInt(0, 255);

    this.mix();
  }

  randomInt(min, max) {
    return Math.floor(Math.random() * (max - min + 1)) + min;
  }
}

Look! Works like a charm:

Current code snapshot: https://github.com/PavelTkachenko/stimulator-dev-to/tree/color_mixer

That's all for today folks. Next time we will add storage using data attributes (props), add auto-detect changing for our props, lifecycles and even more. As you can see implementation is very simple, it is not suitable for production of course. Main point here is that you can easily experiment and prototype different cool things. Maybe some day you will create a next-gen JS framework, which will be used by developers in every part of planet Earth and beyond.

You probably don't need these gems

Pavel Tkachenko — Mon, 29 Jun 2020 11:29:25 +0000

Gems are fun! They simplify your development process a lot. But sometimes programmers bundle their project with gems they even don't need. I often see projects where complexity is increasing dramatically by trying to solve simple problem using heavy gems. This article is devoted to beginner Rails developers, who copy-paste gems to their Gemfile without any doubt.

You probably don't need config gem

https://github.com/rubyconfig/config

Popular gem for handling configuration of your app and global data. This gem in very cool and is maintained regularly. It's included in many project bundles. But maybe you can replace whole gem with 3 lines of code?

# Ensure file has lodash before filename to be loaded before other initializers
# which can use settings data.
# config/initializers/_settings.rb
settings_file = File.join(Rails.root, "config", "settings", "#{Rails.env}.yml")
settings_string = File.read(settings_file)
SETTINGS = YAML.safe_load(settings_string).deep_symbolize_keys

And now just create folder with different environments

/config
  /settings
    development.yml
    production.yml
    test.yml

# config/settings/development.yml
site:
  title: "My awesome site"
  contact_mail: "tpepost@gmail.com"

Now you can use SETTINGS in any part of your project.

SETTINGS[:site][:title] #=> My awesome site

Of course it's not a full functionality that config gem provides, but in many cases people use it in this way, nothing more.

You probably don't need local_time gem

https://github.com/basecamp/local_time

Despite the official support of Basecamp, it is not supported anymore as I'm aware. Gem has been updated last time 2 years ago. Also the included strftime JavaScript implementation is not 100% complete. And finally it requires sprockets. And you remember that Webpack is now default for Rails.

I think it is better to use popular JS library for this. You can use date-fns (I try to avoid moment.js due to it's large size (329KB)). The whole replacement of locale_time gem are two files: rails helper and in app/helpers, which creates necessary tag, which is then used by a small JS file.

First of all, install date-fns via yarn/npm or whichever you prefer. Rails expects you to use yarn (so am I).

yarn add date-fns

Then create helpers for your view. When you call the helper, it will create span tag with all required data for date-fns to convert its text to proper format. If JS is disabled, default Rails date string will appear.

# app/helpers/time_helper.rb
module TimeHelper
  def format_time(time, format = "yyyy-MM-dd'T'HH:mm:ss.SSSxxx")
    content_tag(
      :span,
      time,
      data: { "time-format": format, "time-value": time.to_json }
    )
  end

  def relative_time(time)
    format_time(time, :relative)
  end

  def year(time)
    format_time(time, "yyyy")
  end
end

Finaly add appropriate JS file to find all timehelpers in your views and set time to requested format.

// app/javascript/your/custom/path/timeHelper.js
// Don't forget to import into your pack

import formatDistance from "date-fns/formatDistance";
import format from "date-fns/format";

// Ensure it works with turbolinks
document.addEventListener("turbolinks:load", function() {
  const timeHelpers = document.querySelectorAll("[data-time-format]");

  Array.from(timeHelpers).forEach(function(timeHelper) {


    const timeFormat = timeHelper.getAttribute("data-time-format");
    const value = timeHelper.getAttribute("data-time-value");
    const datetime = Date.parse(JSON.parse(value));

    if (timeFormat === "relative") {
      timeHelper.textContent = formatDistance(datetime, new Date());
    }
    else {
      timeHelper.textContent =  format(datetime, timeFormat);
    }
  });
});

Now you can use it in your views

  <p>Posted <%= relative_time(@post.created_at) %><p>
  <p>Created at: <%= format_time(@post) %><p>
  <p>Year: <%= year(@post) %><p>
  <p>Custom format: <%= year(@format_time, "MMMM") %><p>

  <!-- Custom formating: https://date-fns.org/v2.14.0/docs/format -->

As you can see, the workaround is very simple. Now you can expand this functionality further and forget about Sprockets.

You probably don't need devise + devise-jwt gems

https://github.com/heartcombo/devise
https://github.com/waiting-for-dev/devise-jwt

Rails is a popular solution as the API server only. And when you need authentication, developers bundle monstrous devise to their project. Often in API workflow people use JWT authentication process. This causes them to add devise-jwt to empower devise functionality, which is huge even without any plugins. In API mode developers use only small part of devise, they need only encrypting, JWT issuing and sign-in/sign-up functionality. For this purpose it's better to use a simple gem - knock.

It provides everything you need for JWT authentication process. It's very thin and simple. It doesn't have view generators, included ready-to-use controllers, recovering letters and many other staff. Of course such functionality is very important for many apps, but when you act only as API server, you probably will write your custom logic anyway, that will have conflict with devise.

You need to add has_secured_password to your model

class User < ActiveRecord::Base
  has_secure_password
end

Include knock logic to controller

class ApplicationController < ActionController::API
  include Knock::Authenticable
end

And before_action everywhere you need.

class SecuredController < ApplicationController
  before_action :authenticate_user

  def index
    # etc...
  end
end

That is all. Now you have current_user - same as in Devise. Simple and fast.

Your probably need these gems!

This article is not about proving that gems we discussed are bad or not suitable for your project. They solve specific problems in a convenient way. Moreover, I insist on using them to reduce onboarding pain for new developers, because they are most likely familiar with these gems and not familiar with your custom codebase. You don't need to write your own code everywhere, you just need to ask yourselves a question before bundle install command: "Do I really need this gem? Maybe I can solve it in a simple way without bloating my dependency graph?".

Be wise, use gems in a smart way!