Alexander Shagov alexshagov

The "IO to the Boundary" principle

In software architecture, many principles and patterns have emerged over time. However, a lot of these can be boiled down to a single idea: the "IO to the Boundary" principle. This principle suggests that all input/output operations, like database queries, API calls, or file system interactions, should be pushed to the edges (or boundaries) of your application.

Let's look at what some other ideas tell us:

Functional Core, Imperative Shell: This principle suggests keeping the core of your application pure and functional, while handling side effects (IO) in an outer layer. This is basically another way of saying "IO to the Boundary."
Clean Architecture: Proposed by Robert C. Martin, this architecture emphasizes separating concerns and having dependencies point inwards, which fits with keeping IO at the edges.
Command Query Responsibility Segregation (CQRS): While not mainly about IO boundaries, CQRS often leads to separating read and write operations. This separ

Ruby on Rails: Rethinking Service Objects

In the Ruby on Rails community, service objects have gained popularity as a way to encapsulate business logic and keep controllers and models lean. However, there's a growing trend of misusing service objects, particularly those with "-er" or "-or" suffixes. This article aims to shed light on poorly implemented service objects and provide guidance on creating more effective, domain-focused alternatives.

Many developers tend to name their service objects with suffixes like -er or -or, such as ArticleCreator or UserAuthenticator. While this naming convention may seem intuitive, it often leads to a procedural style of programming rather than embracing the object-oriented nature of Ruby.

It's becoming evident that service objects the way we often see them are not actually "objects", but just a procedures.. or better to say, processess.

It might be overwhelming to dive into the Nix world, but this little glossary should help refine your understanding of the tools you might encounter when starting your journey.

Nix Package Manager – The core tool that allows declarative and reproducible package management.

NixOS – A Linux distribution built entirely on the Nix package manager. It's better to start with nix package manager alone before switching to NixOS completely.

Home Manager – Manages user packages, dotfiles, environment variables, shell configurations, and more. Allows for portable user environments across different machines.

Install GNU Emacs (26.3+)

brew install emacs && brew link emacs

Download the development branch

git clone -b develop https://github.com/syl20bnr/spacemacs ~/.emacs.d

	require 'rails_helper'

	RSpec.describe User, type: :model do
	subject { described_class.new(params) }

	let(:params) do
	{
	name: 'John'
	}
	end

	# frozen_string_literal: true

	### Usage

	# Helps to understand how operation run affects the database state
	# DatabaseChangesLogger.call(filename: 'output') { Operation.perform }

	module DatabaseChangesLogger
	EVENTS_TYPE = 'sql.active_record'
	OPERATION_REGEX = /Update\|Create/.freeze

	# ./spec/user_spec.rb

	require_relative '../../lib/user.rb'
	require 'ostruct'

	RSpec.describe User do
	subject { described_class.new(name: name, payment_service: payment_service) }

	let(:name) { 'John Doe' }
	let(:success_result) { true }

	# homework.rb

	class Homework
	attr_reader :title, :content, :completed

	def initialize(title:, content:)
	@title = title
	@content = content
	@completed = false
	end

	### lib/user_input.rb

	class UserInput
	class InvalidUserInput < StandardError; end

	def initialize(input)
	@input = input
	end

	def to_s