DEV Community: Stan

Roadmap for the code newbie / aspiring junior developer

Stan — Tue, 02 May 2023 13:53:17 +0000

Embarking on a journey to become a junior developer can be both exciting and challenging. The opportunities in the tech industry are vast, but it's important to have a clear roadmap to navigate your way to success. In this blog post, we'll outline a comprehensive roadmap for aspiring junior developers to follow, covering everything from identifying dream jobs to contributing to open source projects and enhancing essential skills.

Getting started

1. Identifying Your Dream Job and Requirements

The first step in your journey is to research and identify the type of development role you want to pursue. Look for opportunities that align with your interests and long-term career goals. Browse job listings, attend tech conferences, or join online developer communities to learn about different roles and technologies. Make a list of the skills and requirements needed for your dream job, which will help guide your learning process.

2. Starting a Project

Working on a project will give you hands-on experience and help you develop the necessary skills to succeed as a junior developer. Start by brainstorming ideas and choose a project that you're passionate about. Create a functional and production-ready app, even if it's not the most polished version. This will give you a solid foundation to build upon. Ensure that your app covers essential elements like backend and frontend development, database integration, and caching.

3. Collaborating with a partner

Team up with someone to build the app together, improving your teamwork and communication skills. Collaborating with a partner also helps you learn from their experiences and perspectives. You can find potential partners through developer communities, local meetups, or online forums.

4. Finding a Coach or Mentor

Get guidance from someone experienced in your desired field to ensure you're on the right track. A mentor can provide valuable advice, resources, and connections to help you succeed. Attend local tech meetups, conferences, or workshops to connect with experienced professionals in your field. These events are excellent opportunities to meet potential mentors and learn from their experiences.

5. Getting your code peer reviewed

Peer code review is the process of having fellow developers review your code to identify potential issues, suggest improvements, and share knowledge. This practice is essential for maintaining high-quality code, reducing errors, and fostering a culture of continuous learning within a development team.

For your project

Mastering Essential Technologies

To succeed as a junior developer, it's important to have a strong foundation in essential technologies. For backend development, learn popular technologies such as Spring Boot, Node.js with Express, Python, or Ruby. Familiarize yourself with databases like PostgreSQL or MySQL with an ORM, and implement caching using Redis. For frontend development, become proficient in HTML, CSS, and JavaScript, and learn a popular framework like React.

Learning System Design

Acquire skills in designing scalable and maintainable systems. Understanding system design principles will enable you to build robust and efficient applications. Study common system design patterns, read case studies, and practice designing systems on a small scale.

Using Version Control

Version control is crucial for managing code changes, collaborating with others, and tracking your development progress. Familiarize yourself with version control systems like Git, and learn how to create branches, merge code, and resolve conflicts.

Deployment

Learn how to deploy your app, using Docker if possible. Understanding deployment processes is essential for maintaining and scaling your applications. Study various deployment options, such as cloud platforms or traditional web servers, and learn how to configure and optimize your app for production environments.

Embracing Agile Methodologies

Learn and apply agile methodologies like Scrum to streamline your development process and adapt to changing requirements. Agile methodologies promote flexibility, collaboration, and continuous improvement, which are essential qualities for a successful developer. Attend workshops, read books, or take online courses to learn about different agile methodologies and how to implement them in your projects.

Pair Programming

Engage in pair programming with your partner to learn from each other and improve your coding skills. Pair programming encourages knowledge sharing, problem-solving, and fosters a collaborative working environment. Schedule regular pair programming sessions, either in-person or remotely, to maximize the benefits.

What else?

Documenting and Sharing Your Journey

As you progress through your project, make sure to document your experiences and lessons learned. Write a blog detailing the development process and the different features you've built. This will help showcase your skills to potential employers and allow you to reflect on your progress. Share your blog on social media platforms and developer communities to reach a wider audience and receive valuable feedback.

Always Practicing Data Structures and Algorithms

Data structures and algorithms are the building blocks of efficient software development. Regularly practice problems and challenges to sharpen your skills and develop a strong foundation in computer science. Use online resources, like LeetCode or HackerRank, to find practice problems and improve your problem-solving abilities. This will not only help you succeed in technical interviews but also improve your overall coding skills.

CV Review and Job Applications

Before applying for jobs, get your CV reviewed by mentors or experienced professionals. This will help you put your best foot forward when searching for your dream job. Tailor your CV to highlight your relevant skills, experiences, and accomplishments. Research common CV formats and best practices to create a professional and polished document.

Considering Companies with Minimum Barriers to Entry

As long as the pay is decent and the work culture is not terrible, consider joining a company with minimum barriers to entry. Working for such a company for a couple of years can give you valuable experience and boost your career. You'll have the opportunity to work on real-world projects, learn from experienced colleagues, and enhance your professional network.

Developing a Micro-SaaS App

As you gain confidence in your skills, think about developing a micro-SaaS app. While deployment and hosting may come at a cost, there are affordable options available, like Digital Ocean. Building a micro-SaaS app can help you gain experience in product development, marketing, and customer support. Research successful micro-SaaS products and identify a niche market where you can create value.

Contributing to Open Source

Begin contributing to open source projects to further hone your skills and build a strong developer portfolio. Open source contributions not only demonstrate your expertise but also showcase your ability to work with a team and follow best practices. Browse popular open source repositories on platforms like GitHub, and start by fixing bugs or adding small features.

Never Stop Blogging

Continue to document your journey and share your knowledge with others, even as you progress in your career. Regularly writing about your experiences, challenges, and learnings can help you reflect on your growth and inspire others in the developer community. Set a schedule for publishing new blog posts, and consistently share valuable insights with your audience.

This comprehensive roadmap provides a solid foundation for aspiring junior developers to follow. By focusing on these key areas, you'll develop the necessary skills, experiences, and connections to excel in your career. Remember, the journey to becoming a successful developer requires dedication, continuous learning, and a growth mindset. Keep pushing forward, and there will be a payoff down the line.

Interview experience of Junior Ruby and Rails developers

Stan — Thu, 27 Apr 2023 12:35:42 +0000

Dear Junior Ruby and Rails Developers,

Can you shed some light on your experiences applying for jobs and the interview process?

How did it go?
Where did you get stuck?
What was the result?
What did you learn,
What were you missing?
If you are aware, what did you have that helped you get the job?

Also, anything else that you think is worth sharing.

Book a Bookstore API using Rack, Sequel and Postgresql

Stan — Wed, 26 Apr 2023 16:01:20 +0000

In this article, we will build a simple Bookstore API using Rack and PostgreSQL. Rack is a lightweight web framework for Ruby that provides a minimal interface between web servers and Ruby applications. We will use PostgreSQL as our database backend.

We will create an API with two endpoints: a GET endpoint for retrieving all books and a POST endpoint for adding new books. Additionally, we will provide scripts to create and delete the bookstore database.

Prerequisites:

Ruby
PostgreSQL

First, create a new directory for your project:

mkdir bookstore_api
cd bookstore_api

Create a Gemfile to manage your project's dependencies:

# Gemfile
source 'https://rubygems.org'

gem 'rack'
gem 'pg'
gem 'sequel'
gem 'rack-cors'
gem 'json'

Run bundle install to install the required gems.

Create the database

Create a new file called db.rb to connect to the PostgreSQL database:

# db.rb
require 'sequel'

DB = Sequel.connect('postgres://postgres:postgres@localhost/bookstore')

Replace 'postgres:postgres' with your PostgreSQL credentials.

Create the API

Create a new file called bookstore_api.rb and define the BookstoreAPI class:

require 'rack'
require 'json'
require_relative 'db'

class BookstoreAPI
  # ...
end

Implement the call method to handle incoming requests:

def call(env)
  request = Rack::Request.new(env)
  response = Rack::Response.new

  case request.path_info
  when '/books'
    handle_books_request(request, response)
  else
    response.status = 404
    response.write('Not found')
  end

  response.finish
end

Implement the GET and POST endpoints

def handle_books_request(request, response)
  case request.request_method
  when 'GET'
    get_books(response)
  when 'POST'
    create_book(request, response)
  else
    response.status = 405
    response.write('Method not allowed')
  end
end

def get_books(response)
  books = DB[:books].all
  response.write(books.to_json)
end

def create_book(request, response)
  # ...
end

Implement the create_book method to handle book creation:

def create_book(request, response)
  book_data = JSON.parse(request.body.read)
  title = book_data['title']
  author = book_data['author']
  published_date = book_data['published_date']
  price = book_data['price']

  if title && author
    book_id = DB[:books].insert(title: title, author: author, published_date: published_date, price: price)
    response.status = 201
    response.write({ id: book_id }.to_json)
  else
    response.status = 400
    response.write('Invalid book data')
  end
end

Set up Rack

Create a config.ru file to run the Rack application:

# config.ru
require_relative 'bookstore_api'

run BookstoreAPI.new

Create scripts to manage the database

Add a script to delete the database in delete_db.rb:

# delete_db.rb
require 'pg'

def delete_database
  conn = PG.connect(dbname: 'postgres', user: 'postgres', password: 'postgres', host: 'localhost')
  result = conn.exec("SELECT 1 FROM pg_database WHERE datname = 'bookstore';")

  unless result.any?
    puts "Database doesn't exist"
    return
  end

  conn.exec("DROP DATABASE IF EXISTS bookstore;")
  puts "Db successfully dropped"
  conn.close
end

delete_database

Running the scripts

Run the setup_db script in order to create the bookstore database and the books table.

ruby setup_db.rb

You can also run the delete_db.rb script if you wish to delete the database. Additionally, you can add to the delete_db.rb script if you only wish to get rid of individual tables.

Run the API

To start the Rack server, run the following command:

rackup

The API should now be running on http://localhost:9292. You can use a tool like Postman or curl to test your endpoints.
Your POST request should look as follows:

{
    "title": "Animal Farm",
    "author": "George Orwell",
    "published date": "27-08-1945",
    "price": 22.5
}

When you click on the GET endpoint for /posts, you should be able to set an array that includes the newly created record.

Let's refactor

As we can see, our create_book method in the bookstore api has gone on a bit long. Let's clean this up a bit.

To begin, let's create a method to parse the request data.

def parse_request_body(request)
  JSON.parse(request.body.read)
end

We'll add another method to check if the request data is valid. Our API expects the title and author attributes to be present.

def valid_book_data?(book_data)
  book_data['title'] && book_data['author']
end

We will then insert the request data into the database using Sequel.

def insert_book_into_database(book_data)
  DB[:books].insert(
    title: book_data['title'],
    author: book_data['author'],
    published_date: book_data['published_date'],
    price: book_data['price']
  )
end

Finally, we will create methods to send valid / invalid responses.

def send_created_response(response, book_id)
  response.status = 201
  response.write({ id: book_id }.to_json)
end

def send_invalid_book_data_response(response)
  response.status = 400
  response.write('Invalid book data')
end

Our final code for the bookstore_api should look like this.

require 'rack'
require 'json'
require_relative 'db'

class BookstoreAPI
  def call(env)
    request = Rack::Request.new(env)
    response = Rack::Response.new

    case request.path_info
    when '/books'
      handle_books_request(request, response)
    else
      response.status = 404
      response.write('Not found')
    end

    response.finish
  end

  private

  def handle_books_request(request, response)
    case request.request_method
    when 'GET'
      get_books(response)
    when 'POST'
      create_book(request, response)
    else
      response.status = 405
      response.write('Method not allowed')
    end
  end

  def get_books(response)
    books = DB[:books].all
    response.write(books.to_json)
  end

  def create_book(request, response)
    book_data = parse_request_body(request)

    if valid_book_data?(book_data)
      book_id = insert_book_into_database(book_data)
      send_created_response(response, book_id)
    else
      send_invalid_book_data_response(response)
    end
  end

  def parse_request_body(request)
    JSON.parse(request.body.read)
  end

  def valid_book_data?(book_data)
    book_data['title'] && book_data['author']
  end

  def insert_book_into_database(book_data)
    DB[:books].insert(
      title: book_data['title'],
      author: book_data['author'],
      published_date: book_data['published_date'],
      price: book_data['price']
    )
  end

  def send_created_response(response, book_id)
    response.status = 201
    response.write({ id: book_id }.to_json)
  end

  def send_invalid_book_data_response(response)
    response.status = 400
    response.write('Invalid book data')
  end
end

Let's write some specs

Add the following gems to your Gemfile

gem 'rspec'
gem 'rack-test'

Add a bookstore_api_spec.rb file to test your API:

require 'rspec'
require 'rack/test'
require_relative 'bookstore_api'

RSpec.describe BookstoreAPI do
  include Rack::Test::Methods

  def app
    BookstoreAPI.new
  end

  describe 'GET /books' do
    before do
      # Clear the books table and insert test data
      DB[:books].truncate
      DB[:books].insert(title: 'The Catcher in the Rye', author: 'J.D. Salinger', published_date: '1951-07-16', price: 10.99)
      DB[:books].insert(title: 'To Kill a Mockingbird', author: 'Harper Lee', published_date: '1960-07-11', price: 12.99)
    end

    it 'returns a list of books' do
      get '/books'

      expect(last_response).to be_ok
      books = JSON.parse(last_response.body)
      expect(books.size).to eq(2)
    end
  end

  describe 'POST /books' do
    let(:valid_book_data) do
      {
        'title' => '1984',
        'author' => 'George Orwell',
        'published_date' => '1949-06-08',
        'price' => 14.99
      }
    end

    let(:invalid_book_data) do
      {
        'title' => 'The Great Gatsby',
        'published_date' => '1925-04-10',
        'price' => 10.99
      }
    end

    it 'creates a book with valid data' do
      post '/books', valid_book_data.to_json, { 'CONTENT_TYPE' => 'application/json' }

      expect(last_response.status).to eq(201)
      book_id = JSON.parse(last_response.body)['id']
      expect(book_id).not_to be_nil

      book = DB[:books].where(id: book_id).first
      expect(book[:title]).to eq(valid_book_data['title'])
      expect(book[:author]).to eq(valid_book_data['author'])
    end

    it 'returns an error with invalid data' do
      post '/books', invalid_book_data.to_json, { 'CONTENT_TYPE' => 'application/json' }

      expect(last_response.status).to eq(400)
      expect(last_response.body).to eq('Invalid book data')
    end
  end
end

Run the specs with the following command.

rspec .

All specs should be passing.

Our final tree structure should look as follows. Only 8 files for an API - pretty neat, right!?!

├── Gemfile
├── Gemfile.lock
├── bookstore_api.rb
├── bookstore_api_spec.rb
├── config.ru
├── db.rb
├── delete_db.rb
└── setup_db.rb

In this article, we built a simple Bookstore API using Rack and PostgreSQL. We created two endpoints for getting and adding books and provided scripts to manage the database. With this foundation, you can extend the API to include more functionality like updating or deleting books, and even add authentication.

Create a Ruby gem from scratch

Stan — Sat, 22 Apr 2023 10:27:30 +0000

If you've ever needed to add commenting functionality to a Rails project, you may have found yourself writing the same code over and over again. In this article, we'll show you how to create a gem that provides comments for any model in a Rails project. With this gem, you'll be able to easily add commenting functionality to any Rails project without duplicating code.

Create the gem

First, we'll create a new gem called commenter. To do this, run the following command in your terminal:

bundle gem commenter

This will generate a new gem with a basic file structure.

At present, we have the following file structure.

├── Gemfile
├── Gemfile.lock
├── commenter-0.1.0.gem
├── commenter.gemspec
├── lib
│   ├── commenter
│   │   └── version.rb
│   ├── commenter.rb
└── spec
    ├── commenter_spec.rb
    └── spec_helper.rb

We already have the following files present in the lib directory.

# lib/commenter.rb
require_relative "commenter/version"

module Commenter
  class Error < StandardError; end
end

# lib/commenter/version.rb
module Commenter
  VERSION = '0.1.0'
end

Update the commenter.gemspec file by replacing all the TODO: statements with relevant information.

Additionally, we will need 2 dependencies for this gem.

spec.add_dependency "rails"
spec.add_dependency "rspec-rails"

First, let's include the associated comments using ActiveSupport::Concern in the lib/commenter/commentable.rb file.

require 'active_support/concern'

module Commenter
  module Commentable
    extend ActiveSupport::Concern

    included do
      has_many :comments, as: :commentable, dependent: :destroy
    end
  end
end

We will then require this file in lib/commenter.rb.

require_relative "commenter/version"
require_relative "commenter/commentable"

module Commenter
  class Error < StandardError; end
end

Next, we will create a generator to setup up the migration for creating comments in the database in the lib/generators/commenter/comment_generator.rb file.

require 'rails/generators/active_record'
require 'rails/generators/named_base'


module Commenter
  module Generators
    class CommentGenerator < Rails::Generators::NamedBase
      source_root File.expand_path('templates', __dir__)
      def create_migration
        migration_file_name = "create_comments.rb"
        timestamp = Time.now.utc.strftime("%Y%m%d%H%M%S")
        destination = File.join('db', 'migrate', "#{timestamp}_#{migration_file_name}")
        template migration_file_name, destination
      end
    end
  end
end

Additionally, we will create a template for this migration in the lib/generators/commenter/templates/create_comments.rb file.

class CreateComments < ActiveRecord::Migration[6.1]
  def change
    create_table :comments do |t|
      t.text :body
      t.references :commentable, polymorphic: true, null: false
      t.timestamps
    end
  end
end

So far we have set up the gem to create a migration file in the db/migrate folder of your Rails application with the correct timestamp. As can be seen, the migration file contains a body attribute, timestamps as well as references to commentable which will be polymorphic.

Now, we will add the method to generate the model in the same generator.

# ...

module Commenter
  module Generators
    class CommentGenerator < Rails::Generators::NamedBase

      # ...

      def create_model_file
        template 'comment.rb', File.join('app/models', class_path, "#{file_name}.rb")
      end
    end
  end
end

We will also set up the template to create the model in the lib/generators/commenter/templates/comment.rb file.

class <%= class_name %> < ApplicationRecord
  belongs_to :commentable, polymorphic: true
end

Let's test

At this stage our code is ready. However, let's set up the specs to ensure that the generators and associations work fine.

For this purpose, we will add 2 more development dependencies to our gemspec.

spec.add_development_dependency "sqlite3"
spec.add_development_dependency "generator_spec"

For testing purposes, we will use the sqlite3 database.

We will also update the spec_helper.rb file to ensure that we have all the configurations and requirements set up for testing.

require "bundler/setup"
require "commenter"
require "rails"
require "action_view"
require "action_controller"
require "rspec/rails"
require "active_record"

ActiveRecord::Base.establish_connection(adapter: "sqlite3", database: ":memory:")

ActiveRecord::Schema.define do
  create_table :commentable_models do |t|
    t.timestamps
  end
end

RSpec.configure do |config|
  config.filter_run_when_matching :focus
  config.example_status_persistence_file_path = "spec/examples.txt"
  config.disable_monkey_patching!
  config.default_formatter = "doc" if config.files_to_run.one?
  config.order = :random
  Kernel.srand config.seed
end

Here, we have established a connection with the sqlite3 and created an ActiveRecord migration for our commentable models.

By default, we have the spec/commenter_spec.rb file. We can keep the spec for testing the version number, and get rid of the second placeholder spec.

Next, we will create spec/commenter/commentable_spec.rb file to test the association.

require "spec_helper"

RSpec.describe Commenter::Commentable, type: :model do
  class CommentableModel < ActiveRecord::Base
    include Commenter::Commentable
  end

  describe "associations" do
    it "has many comments" do
      association = CommentableModel.reflect_on_association(:comments)
      expect(association.macro).to eq(:has_many)
      expect(association.options[:as]).to eq(:commentable)
      expect(association.options[:dependent]).to eq(:destroy)
    end
  end
end

Next, we set up the specs for testing the generator in the spec/generators/commenter/comment_generator_spec.rb file.

require 'spec_helper'
require 'generator_spec'
require 'generators/commenter/comment_generator'

RSpec.describe Commenter::Generators::CommentGenerator, type: :generator do
  destination File.expand_path("../../tmp", __FILE__)
  arguments %w(Comment)

  before do
    prepare_destination
    run_generator
  end

  it 'creates the comments migration' do
    migration_path = File.join(destination_root, 'db/migrate')
    expect(File.exist?(migration_path)).to be true
    migration_files = Dir.entries(migration_path)
    expect(migration_files).to include(/create_comments/)
  end

  it 'creates the comments model' do
    model_path = "#{destination_root}/app/models/comment.rb"
    expect(File.exist?(model_path)).to be true
    model_contents = File.read(model_path)
    expect(model_contents).to match(/class Comment < ApplicationRecord/)
  end

  after(:all) do
    FileUtils.rm_rf(destination_root)
  end
end

In this spec, we prepare a temporary destination for the generated files which will be deleted on completion of the spec. The first spec tests the generation of the migration file, whereas the second one tests the generation of the model.

Now, let's get the spec ready for use in a Rails application.

First, let's build the gem.

gem build commenter.gemspec

Hook it up to rails

Next, let's add the gem to our Rails application Gemfile. At present, since we haven't uploaded it to the https://rubygems.org repository yet, let's source it locally.

gem 'commenter', path: 'path/to/commenter`

Once done, run bundle install.

With the gem added, let's use it to generate our migration and model files.

rails generate commenter:comment Comment

This command should create our migration file in db/migrate as well as our Comment model in app/models.

Next, let's create our comments_controller.rb file.

class CommentsController < ApplicationController
  before_action :set_commentable

  def create
    @comment = @commentable.comments.build(comment_params)
    if @comment.save
      redirect_to @commentable, notice: 'Comment was successfully created.'
    else
      redirect_to @commentable, alert: 'Error creating comment.'
    end
  end

  def destroy
    @comment = @commentable.comments.find(params[:id])
    @comment.destroy
    redirect_to @commentable, notice: 'Comment was successfully destroyed.'
  end

  private

  def set_commentable
    @commentable = find_commentable
  end

  def find_commentable
    params.each do |name, value|
      if name =~ /(.+)_id$/
        return $1.classify.constantize.find(value)
      end
    end
    nil
  end

  def comment_params
    params.require(:comment).permit(:body)
  end
end

The controller has 2 basic actions - create and destroy. Additionally, we have set up our find_commentable method to search for the commentable class based on the associated id provided.

We will also set up a couple of views. First, let's create a app/views/comments/_comment_form.html.erb view to create a comment.

<%= form_with model: [commentable, Comment.new], local: true do |form| %>
  <div class="form-group">
    <%= form.label :body, "Comment" %>
    <%= form.text_area :body, class: 'form-control' %>
  </div>
  <%= form.submit 'Add Comment', class: 'btn btn-primary' %>
<% end %>

Next, we create a app/views/comments/_comment.html.erb view for each individual comment.

<div class="comment">
  <p><%= comment.body %></p>
  <p>
    <%= button_to 'Delete Comment', [comment.commentable, comment],
                method: :delete,
                data: { confirm: 'Are you sure you want to delete this comment?' },
                class: 'btn btn-danger btn-sm' %>
  </p>
</div>

Let's assume we already have a model called Article that has been set up inside our Rails application. We will add the comments to our Article model.

class Article < ApplicationRecord
    has_many :comments, as: :commentable, dependent: :destroy
end

Next, we will plug in our comment and form into the show page of our article.

<p style="color: green"><%= notice %></p>

<%= render @article %>

<div class="comments">
  <h3>Comments</h3>
  <%= render partial: 'comments/comment', collection: @article.comments %>
  <%= render partial: "comments/comment_form", locals: { commentable: @article } %>

</div>

Finally, let's add comments to our article routes.

resources :articles do
  resources :comments, only: [:create, :destroy]
end

The final result

Our application is now ready to create comments. Let's spin up our Rails application and visit the show page of any of our articles e.g. http://localhost:3000/articles/1

If all has worked well so far, we should now be able to add and delete comments on this page.

SOLID: Open-closed principle in Ruby

Stan — Thu, 20 Apr 2023 15:40:41 +0000

The Open/Closed Principle (OCP) is one of the five principles of object-oriented programming and design known as SOLID. The OCP states that a class should be open for extension but closed for modification. In other words, you should be able to add new functionality to a class without modifying its existing code. This principle promotes a more robust and maintainable software design by reducing the likelihood of introducing bugs when adding new features. In this article, we will explore the Open/Closed Principle and demonstrate its application in Ruby.

Understanding the open closed principle

The OCP revolves around two primary concepts:

Open for extension: You should be able to add new features or behaviors to a class without affecting its existing functionality.
Closed for modification: The source code of a class should not need to be modified when adding new functionality.

By adhering to the OCP, you can create a more flexible and maintainable codebase that is less prone to bugs and more adaptable to changing requirements.

Applying the Open/Closed Principle in Ruby

Let's illustrate the Open/Closed Principle using a Ruby example. Imagine we have a system that generates reports in different formats, such as HTML and JSON.

We'll use the JSON and Nokogiri gems to create JSON and HTML reports, respectively. First, you'll need to install the gems:

gem install json nokogiri

Here's an initial implementation without considering the OCP:

require 'json'
require 'nokogiri'

class ReportGenerator
  def initialize(data)
    @data = data
  end

  def generate(format)
    case format
    when :html
      generate_html
    when :json
      generate_json
    end
  end

  private

  def generate_html
    builder = Nokogiri::HTML::Builder.new do |doc|
      doc.html do
        doc.head { doc.title 'Report' }
        doc.body do
          doc.h1 'Report Data'
          doc.table do
            doc.tr do
              data.keys.each { |key| doc.th key }
            end
            doc.tr do
              data.values.each { |value| doc.td value }
            end
          end
        end
      end
    end
    builder.to_html
  end

  def generate_json
    data.to_json
  end
end

The problem with this implementation is that whenever we need to support a new report format, we must modify the ReportGenerator class by adding a new method and updating the generate method. This violates the Open/Closed Principle.

To refactor this code and adhere to the OCP, we can use polymorphism and separate the report generation logic into different classes:

class ReportGenerator
  def initialize(data)
    @data = data
  end

  def self.generate(data)
    new(data).generate
  end

  def generate
    raise NotImplementedError, "'generate' method should be implemented"
  end
end

require 'nokogiri'

class HTMLReportGenerator < ReportGenerator
  def generate
    builder = Nokogiri::HTML::Builder.new do |doc|
      doc.html do
        doc.head { doc.title 'Report' }
        doc.body do
          doc.h1 'Report Data'
          doc.table do
            doc.tr do
              @data.keys.each { |key| doc.th key }
            end
            doc.tr do
              @data.values.each { |value| doc.td value }
            end
          end
        end
      end
    end
    builder.to_html
  end
end

require 'json'

class JSONReportGenerator < ReportGenerator
  def generate
    @data.to_json
  end
end

Now, when we need to support a new format, we can simply create a new class that implements the generate method without modifying the existing code:

class XMLReportGenerator < ReportGenerator
  def generate
    # add your own code to generate a report in XML format
  end
end

In this example, the HTMLReportGenerator class uses the Nokogiri gem to build an HTML report with a table containing the data. The JSONReportGenerator class uses the JSON gem to convert the data to a JSON-formatted string.

Now you can use the ReportGenerator class to generate reports in different formats:

data = { title: 'Sample Report', views: 100, clicks: 20 }

html_report = HTMLReportGenerator.generate(data)
puts html_report

json_report = JSONReportGenerator.generate(data)
puts json_report

xml_report = XMLReportGenerator.generate(data)
puts xml_report

This refactored code adheres to the Open/Closed Principle by allowing new report formats to be added without modifying the ReportGenerator class.

The Open/Closed Principle is an essential concept in object-oriented programming and design that promotes robust, maintainable, and flexible code. By applying the OCP in your Ruby projects, you can create a more adaptable and resilient codebase that is better prepared to handle changing requirements and less prone to bugs.

Challenges of a Junior Ruby Developer

Stan — Sat, 15 Apr 2023 09:34:16 +0000

While there are many job opportunities in Ruby development, it can be challenging for junior developers to get their foot in the door. This is causing a problem for the growth of Ruby as a language, as many potential developers shy away from the language, and move to some other language or some other career which offer more lucrative opportunities. I am writing this article in my effort to try to push for the revival of what I still consider one of the most enjoyable programming languages to work with in the world (hands down Ruby on Rails remains the best framework even today to build an quick MVP).

Let's go through the obvious

Here are some issues that you will commonly face as a junior developer.

Highly competitive scene: The tech industry is highly competitive, and many junior developers are vying for the same job openings. There are often a limited number of entry-level positions available, and the competition for these roles can be fierce. This makes it difficult for junior developers to stand out and land a job.

High experience requirement: Many companies prefer to hire developers with experience, even for entry-level positions. Junior developers may struggle to find job openings that are suitable for their level of experience. They may also struggle to gain the necessary experience to qualify for these positions.

Wide skillset required: While Ruby is a popular programming language, many companies require developers to have a wide range of skills in addition to Ruby. Junior developers may need to be proficient in other programming languages, frameworks, and tools, which can make it difficult to land a job.

Strong portfolio expectations: In addition to experience and skills, many companies also require junior developers to have a strong portfolio of work. This can be difficult for junior developers who are just starting out and may not have many projects to showcase. Building a strong portfolio can take time and effort, which can make it difficult for junior developers to get their foot in the door.

Internal and reference hires: Some job openings are not publicly advertised, and companies often rely on referrals and networking to find suitable candidates. Junior developers who are just starting out may not have an extensive network of contacts, which can make it difficult to find job openings and get their foot in the door.

What are the concerns of hiring a junior developer?

When we are hiring, we often lean towards a mid-level developer over a junior developer. Our thought process includes:

Can they work on legacy applications? The code here is often messy, and for a junior developer, fixing bugs and creating new features in these applications can be overwhelming.

How much time do they need to learn newer concepts? Learning is generally done on the job, and while bigger companies do provide dedicated time for learning, smaller and medium-sized companies cannot generally afford to do this.

Do we have the luxury of time to allow them to make mistakes? This is where internships (where junior developers are being paid a stipend or less) can still come at a higher cost, as senior developers would need to dedicate time to supporting them and guiding them through their mistakes.

Can we provide enough support for hand-holding them through the initial phase? Quite often, companies don't have a budget for this. We do pair-programming quite often, and here, it would help if we don't need to explain basic concepts to the developer.

Interview issues

Some issues that I have noticed during our interviews with junior developers:

Little to no testing knowledge / experience: Often, there is little to no knowledge of testing (using a framework like RSpec or otherwise)

Bloated CVs: The resume seems more bloated than reality. Applicants are not able to explain the skills and experience listed in their resume.

More talk and less action: Confidence levels are generally quite high until we get to technical questions.

Not enough knowledge of Ruby / Rails: Applicants get stuck on basic tasks during a technical assessment round.

Basic experience: Applicant experience doesn't highlight dabbling with much technical complexity (their knowledge and experience is on a very basic level)

What can be done to fix this?

Being a Lead Engineer myself, in regard to the apps I work with, I've also listed some of my own (slightly ambitious) expectations.

Good understanding of Ruby

You will need to have a solid understanding of the Ruby programming language. This includes understanding the syntax, control structures, data structures, and object-oriented programming concepts like classes, objects, inheritance, and modules. You should also be familiar with the standard Ruby library.

Design patterns

You should have a good understanding of several key design patterns, including the Strategy pattern, Polymorphism, Builder, Factory, and SOLID principles. These patterns provide a framework for organizing and designing code that is maintainable, scalable, and easy to understand

Ruby on Rails

You should have a good understanding of Ruby on Rails and its components, including the Model-View-Controller (MVC) architecture, routing, ActiveRecord, views, helpers, assets, and testing frameworks like MiniTest and RSpec.

SQL Databases

You should have experience working with at least one SQL database, such as MySQL or PostgreSQL. You should be familiar with concepts like data types, tables, primary keys, foreign keys, and SQL queries. You should also be familiar with tools like MySQL Workbench and pgAdmin for managing and querying databases.

ActiveRecord

You should have a good understanding of ActiveRecord and its features, including models, associations, validations, callbacks, scopes, and migrations.

REST API

You should be familiar with RESTful API design, including HTTP methods, URI design, request and response formats, authentication, and security.

Javascript

Now this would largely depend on the role you are pursuing, but quite often with Rails (unless you are working for a big entity), you are expected to be a fullstack developer, and therefore some frontend and Javascript knowledge is necessary. JavaScript is a programming language used to add interactivity and dynamic behavior to web applications. You should be familiar with concepts like DOM manipulation, event handling, AJAX, and ES6 syntax.

Git

You should be familiar with Git and its commands, including git init, git add, git commit, git push, git pull, and git merge. You should also be familiar with common Git workflows like branching, merging, and rebasing. Also understand how to create and review pull requests. Quite often, this is a very good source of learning and improving your code.

Docker

With the philosophy of Devops geting stronger in smaller and medium-sized teams, knowledge of some Docker is generally expected from a Ruby Developer. Docker is a platform used to build, ship, and run applications in containers. As a junior Ruby developer, you should have some experience working with Docker and its concepts, including containers, images, Dockerfiles, and Docker Compose. You should also be familiar with common Docker commands and workflows for building and deploying applications.

Soft-skills and other stuff

You don't need to be an orator, but you should be able to communicate well enough (your listening skills are very important). Get rid of all the fluff on your resume, and talk only about what you actually know. Companies do have culture rounds, and here you should let your personality as a team player shine. Get cracking on Leetcode, Hackerrank, etc. to get your knowledge of algorithms up to speed. While this is not always a requirement, many companies still commence their interview process by sending you some algorithmic problems to solve. Others might be interested in your problem solving skills rather than actually expecting you to solve the algorithms, and use the white-board method (if done locally) or some remote coding method if done remotely. Here, they would like at the questions you ask, and the approach you take.

Is all of this worth it?

Now, while this might seem like a tall order, trust me - it's worth it. You are now trying not only to get ahead of your competition, but are also working your way into becoming a mid-level developer. When you do join, you might also work on legacy applications that can be overwhelming, and it would definitely help to have someone mentor you inside your company, and hold your hand through the initial period where you get an understanding of how these apps work.

By building a strong portfolio, learning additional skills, networking, applying for internships, and being persistent, junior developers can increase their chances of landing a job in this exciting field. I am personally trying to figure out ideas that can provide opportunities for junior developers myself and get them to a point where they can get access to opportunities more easily.

Understanding and preventing race conditons in Ruby

Stan — Wed, 12 Apr 2023 18:02:15 +0000

Race conditions are a common issue in concurrent programming that can lead to unexpected behavior and bugs in applications. In this article, we will explore race conditions in Ruby, illustrate them with code samples, and discuss techniques to prevent them.

What is a race condition?

A race condition occurs when two or more threads access shared data simultaneously, and the outcome of the operation depends on the relative timing of these threads. This can lead to unpredictable results and make it difficult to identify and reproduce bugs.

Illustrating Race Conditions in Ruby

Let's consider a simple Ruby script that demonstrates a race condition. The script simulates a bank account with a balance, where two threads attempt to deposit money simultaneously.

# race_condition_example.rb
class BankAccount
  attr_accessor :balance

  def initialize(balance)
    @balance = balance
  end

  def deposit(amount)
    new_balance = @balance + amount
    sleep(0.1)
    @balance = new_balance
  end
end

account = BankAccount.new(100)

t1 = Thread.new { account.deposit(50) }
t2 = Thread.new { account.deposit(70) }

t1.join
t2.join

puts "Final balance: #{account.balance}"

In this example, you might expect the final balance to be 220 (100 + 50 + 70). However, due to the race condition, the output could be 150 or 170, depending on the relative timing of the two threads.

Techniques to prevent race conditions in ruby

1. Mutex

A Mutex (short for "mutual exclusion") is a synchronization primitive that ensures only one thread can execute a particular section of code at a time. In Ruby, you can use the Mutex class to protect the critical section of your code, as shown in the example below:

# race_condition_mutex_example.rb
require 'thread'

class BankAccount
  attr_accessor :balance

  def initialize(balance)
    @balance = balance
    @mutex = Mutex.new
  end

  def deposit(amount)
    @mutex.synchronize do
      new_balance = @balance + amount
      sleep(0.1)
      @balance = new_balance
    end
  end
end 

account = BankAccount.new(100)

t1 = Thread.new { account.deposit(50) }
t2 = Thread.new { account.deposit(70) }

t1.join
t2.join

puts "Final balance: #{account.balance}"

By using a Mutex, we ensure that only one thread can access the deposit method at a time, preventing the race condition and yielding the expected final balance of 220.

2. Monitor

The Monitor class in Ruby is an extension of the Mutex class that provides additional methods for managing synchronization, such as try_enter and wait. You can use the MonitorMixin module to include Monitor functionality in your class:

# race_condition_monitor_example.rb
require 'monitor'

class BankAccount
  include MonitorMixin

  attr_accessor :balance

  def initialize(balance)
    @balance = balance
    super()
  end

  def deposit(amount)
    synchronize do
      new_balance = @balance + amount
      sleep(0.1)
      @balance = new_balance
    end
  end
end

account = BankAccount.new(100)

t1 = Thread.new { account.deposit(50) }
t2 = Thread.new { account.deposit(70) }

t1.join
t2.join

puts "Final balance: #{account.balance}"

In this example, we have included the MonitorMixin module and used the synchronize method to protect the critical section of our code. This ensures that only one thread can access the deposit method at a time, preventing the race condition and producing the expected final balance of 220.

Ruby on Rails: Dealing with Race Conditions

In Rails applications, race conditions can occur when multiple threads or processes modify shared resources, such as database records. To prevent race conditions in Rails, you can use ActiveRecord's built-in methods, such as with_lock:

class Order < ApplicationRecord
  has_many :line_items
  belongs_to :user

  def update_inventory
    line_items.each do |line_item|
      line_item.book.with_lock do
        new_inventory = line_item.book.inventory - line_item.quantity
        line_item.book.update!(inventory: new_inventory)
      end
    end
  end
end

In this example, we use the with_lock method to lock the book record before updating its inventory. This ensures that no other thread or process can modify the book's inventory simultaneously, thus preventing race conditions.

Understanding and preventing race conditions is crucial for developing stable and reliable concurrent applications in Ruby. By using synchronization techniques such as Mutex, Monitor, and ActiveRecord's built-in methods, you can protect critical sections of your code and ensure that your application behaves predictably even when multiple threads or processes access shared resources. As you continue to develop your Ruby applications, keep these concepts and techniques in mind to prevent race conditions and maintain the integrity of your data.

You can read more posts on the Maki Sushi blog.