# Jake Yesbeck Jake Yesbeck's Technology Blog inspired by Open Source Projects. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Why You Should Avoid Models in Rails Migrations DevFeed: [Why You Should Avoid Models in Rails Migrations]() Original publisher: [Read original article]() Published: 2021-04-10T12:00:00Z Content type: article Language: en Sources: [Jake Yesbeck]() Topics: [Rails](), [migration](), [Code](), [Databases](), [App]() Tags: [activerecord](), [code](), [database](), [migration](), [rails](), [us]() ### AI overview This article explains why Rails migrations should avoid relying on application models. A model rename can cause an older migration that calls the model to fail when another developer runs it later. It recommends using SQL through the base database connection or defining a temporary model inside the migration so migrations depend on stable database structure rather than changing application code. ### Source excerpt Humble Beginnings A simple Rails application exists with two models, Books and Authors. class Book < ApplicationRecord belongs_to :author end class Author < ApplicationRecord has_many :books end After some domestic success, this simple Rails app goes international. A new column is required on the books table: country to denote which country published the Book. A Reasonable Migration To preserve data integrity, the country column should not allow null since null isn't a country. Existing books also need to have a country set. This is all accomplished within a single migration in 3 steps: Add a column Update column for existing books with a reasonable value Add a constraint that the column can not be null class AddCountryToBooks < ActiveRecord::Migration[6.1] def up add_column :books, :country, :string, length: 2 Book.update_all(country: 'US') change_column_null :books, :country, false end def down remove_column :books, :country end end This migration does the job but has hidden implications. A developer working in isolation may never run into the trap lurking in this code, but a team could. Working with Others Two developers work on this application, divvying up the wild world of books and authors but maintaining healthy work life balances. One developer goes on vacation and has a surprise waiting for them when they return. Developer 1 👩💻 Developer 2 👨💻 Day 1 Write Code Write Code Day 2 😎 Time Off 🏗 Create Migration Day 3 😎 Time Off 📛 Rename Class Day 4 😎 Time Off Write Code Day 5 Run Migrations -> 🔥 Error Write Code While Developer 1 was away, the Developer 2 was busy. They wrote the above migration, updated existing data and then a new feature request was completed: A model rename. Developer 1 returns, updates their local environment, and runs rake db:migrate: == 20210407191819 AddCountryToBooks: migrating =================== -- add_column(:books, :country, :string, {:length=>2}) -> 0.0015s rake aborted! StandardError: An error has occurred, this and all la ## Making RSpec Tests More Robust DevFeed: [Making RSpec Tests More Robust]() Original publisher: [Read original article]() Published: 2020-07-19T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [RSpec](), [Ruby](), [Testing](), [Mocking](), [API](), [client](), [HTTP]() Tags: [api](), [code](), [framework](), [mocking](), [ruby](), [testing](), [tests]() ### AI overview This article explains how an RSpec test for Ruby API client code can pass even after the tested method is removed. It shows that mocking the method under test may override its implementation and hide a broken contract. The article recommends stubbing the HTTP client response so the test verifies the request behavior without making a real HTTP request. ### Source excerpt RSpec is a popular framework for testing Ruby code. With an expect assertion, a developer can make sure their code calls the proper method or an acceptable result is returned. The expect().to receive matcher in a test overrides the default implementation and can cause some unintended side effects. To demonstrate this potential problem, assume a very simple API client exists that can update models. Testing an API Client An example api_client.rb class defines a single put method that calls the underlying API with a Faraday connection. # api_client.rb class APIClient def put(url, body) client.put(url, body) end private def client Faraday.new('https://some-cool-api.com') end end Inheriting from api_client.rb is my_model.rb which defines an update method. # my_model.rb class MyModel < APIClient def update(payload) put('/my_models/1', payload) end end A typical test for the update method on MyModel in RSpec might look like: # my_model_spec.rb describe MyModel do describe 'update' do it 'updates the model' do expect(subject).to receive(:put) subject.update({ foo: :bar }) end end end The subject in the above test is MyModel.new and is expected to receive the method put. Since MyModel#update calls the put method, this seems like a reasonable test. $: rspec my_model_spec.rb . Finished in 0.0054 seconds (files took 0.07101 seconds to load) 1 example, 0 failures Running the test produces a passing result, the MyModel class calls its parent method correctly and all is well. Until something changes that the test is unable to detect. Breaking the Contract If MyModel's contract changes, the test should fail. If, for instance, the put method on the APIClient class is removed or commented out, the update method on MyModel would no longer work. # api_client.rb class APIClient # def put(url, body) # client.put(url, body) # end private def client Faraday.new('https://some-cool-api.com') end end However, the test still passes despite this method being removed. $: rspec my_model_spec.rb . ## Ruby Processes and Threads - Configuring a Web Server DevFeed: [Ruby Processes and Threads - Configuring a Web Server]() Original publisher: [Read original article]() Published: 2019-06-18T12:00:00Z Content type: article Language: en Sources: [Jake Yesbeck]() Topics: [Ruby](), [Processes](), [Concurrent Programming](), [Server](), [Rails]() Tags: [api](), [concurrency](), [concurrent-programming](), [cpu](), [database](), [processes](), [rails](), [ruby](), [server]() ### AI overview This article explains how Ruby web servers use threads and processes to handle concurrent requests. It covers I/O blocking, Ruby's Global Interpreter Lock, process-based parallelism, and the CPU, memory, and database-connection tradeoffs involved in server configuration. ### Source excerpt Multiple popular Ruby web servers exist. Each Ruby application is different and the ultimate tl;dr for configuring a web server is: it depends. This post will not prescribe one web server or configuration over another and will instead explain internal components most popular servers contain. In order to facilitate more than one request at a time, a Ruby web server implements Threads, Processes, or both. These tools are used to enable concurrency and are beneficial in different ways. Threads Threads in Ruby are a solution for concurrent programming and can alleviate slow downs due to blocking code. This blocking is usually referred to as "I/O" or Input/Output blocking and occurs when a program must reach out for additional information. External API calls, reading from disk, and querying a database are all examples of blocking operations. When using multiple Threads, an application can continue to function while one Thread is waiting. Most Ruby code in the wild is running on MRI (if you're not sure what you're using, there is a good chance this is what you use). Because of this, Ruby Threads are subject to the Global Interpreter Lock or GIL. The GIL prevents any two threads in the same process from running at exactly the same time making true parallelism not possible. Processes One way to allow for true parallelism in Ruby is to use multiple Processes. A Ruby Process is the instance of an application or a forked copy. In a traditional Rails application, each Process contains all the build up, initialization, and resource allocation the app will need. Running multiple Proccesses can enable more efficient usage of some server resources like the CPU but is not without its downsides. Because each process must boot and provision an entire app, memory usage or database connection saturation can become a limiting factor. Tempering the Metal When configuring on a web server, an application's request shape is the most important factor to consider. Web application requests can ## Improving Remote Work as a Software Engineer DevFeed: [Improving Remote Work as a Software Engineer]() Original publisher: [Read original article]() Published: 2018-02-18T12:00:00Z Content type: opinion Language: en Sources: [Jake Yesbeck]() Topics: [Software Engineering](), [Messaging](), [Development]() Tags: [communication](), [remote](), [remote-work](), [software-engineer](), [team](), [tips](), [work](), [workflow]() ### AI overview This article shares practical lessons for remote software engineers, especially those who are the only or one of few remote members of their team. It focuses on maintaining presence through consistent, relevant communication, such as concise chat updates or brief daily status emails covering progress, blockers, and deadlines. ### Source excerpt After working in the Bay Area for many years, I decided that being able to afford a house was something I'd like to do. That and family led me back to the East Coast and a new chapter of my career began: Remote Software Engineering. Transitioning to working remotely in any profession has its challenges. After a few years as a remote software engineer, I have learned many things that don't work and a few that do. Most of the things that didn't work helped point me in the direction to those that do and hopefully these bits of insight can help others. These tips are most relevant to someone who is the only or one of few remote engineers on their team. Presence The largest and most obvious challenge one will face as a remote software engineer is a lack of presence. In an office, people can have small side conversations, ask about one another's weekends, or simply say "hello" in the hallway. While seemingly inconsequential, these tiny interactions establish presence. Maintaining presence is important if an engineer is a member of a team or has many stakeholders in their work. Presence can make the difference between being perceived as "a member of team" as opposed to "that one person who works on... What is it they do again?". The former helps a person feel unified with the team they work for, the mission they are striving towards, and the product they are building; the latter is hollow and temporary. So how does a remote software engineer maintain presence? With consistent yet relevant communication. Whether a company uses Hipchat, Slack, Google Hangouts, or another chat application, instant communication should already be baked into an organization's workflow and can be utilized to establish presence. While over-communication is rarely valuable, sending short and well constructed messages about current progress or next steps helps keep team members informed and questions answered. If instant messaging isn't on the menu, status emails might do well in its place. There is ## A Few RSpec Helpful Hints DevFeed: [A Few RSpec Helpful Hints]() Original publisher: [Read original article]() Published: 2017-07-12T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [RSpec](), [Testing](), [Ruby](), [Code]() Tags: [code](), [developer](), [ruby](), [testing](), [tests]() ### AI overview This tutorial presents practical RSpec techniques for writing Ruby tests that are readable, reusable, and easier to maintain. It covers subject and let variables, loose expectations, argument matchers, and hash matchers. ### Source excerpt Two main frameworks dominate the Ruby testing world: Rspec and MiniTest. RSpec is a very expressive testing framework with many great features and helpers to make tests readable. When writing RSpec tests, here are just a few not so obvious hints that could make tests even easier to write, read, and maintain. Assuming a system exists with Books and Authors, let's utilize these hints to make testing easy. class Book attr_reader :title, :genre def initialize(title, genre) @title = title @genre = genre end end class Author attr_reader :books def initialize(name, books) @name = name @books = Array(books) end def has_written_a_book? !books.empty? end end subject and let Variables A great way to keep specs DRY and readable are via subject and let variable declarations. For example, if we want to assert an Author has a name, a test without let and subject variables might look something like: describe Author do before do @book_genre = 'Historical Fiction' @book_title = 'A Tale of Two Cities' @book = Book.new(@book_genre, @book_title) @author_name = 'Charles Dickens' @author = Author.new(@author_name, [@book]) end describe '#name'do it 'has a name set' do expect(@author.name).to eq(@author_name) end end end While correct, additional tests asserting number of books, a different name, or other things about this Author could become very verbose. Instead, we can introduce subject and let variables to keep things DRY and reusable: describe Author do let(:book_genre) { 'Historical Fiction' } let(:book_title) { 'A Tale of Two Cities' } let(:book) { Book.new(book_genre, book_title) } let(:book_array) { [book] } let(:author_name) { 'Charles Dickens' } subject { Author.new(author_name, book_array) } describe '#name'do it 'has a name set' do expect(subject.name).to eq(author_name) end end describe '#books' do context 'with books' do it 'has books set' do expect(subject.books).to eq(book_array) end end context 'without books' do context 'books variable is nil' do let(:book_array) { nil } ## A Successful Year of Commits DevFeed: [A Successful Year of Commits]() Original publisher: [Read original article]() Published: 2016-04-26T12:00:00Z Content type: article Language: en Sources: [Jake Yesbeck]() Topics: [Open Source](), [Ruby](), [Rails](), [Programming](), [Development](), [Maintainers]() Tags: [github](), [maintainers](), [open-source](), [open-source-software](), [programming](), [rails](), [ruby]() ### AI overview The author recounts completing a year-long commitment to make at least one commit every day to an open source repository, beginning and ending on April 26. Limited free time made contributions to other people's repositories difficult, so the author also worked on personal projects and built libraries, while continuing to contribute to projects on GitHub. The experience improved the author's programming ability and exposed them to different coding styles. ### Source excerpt At Rails Conf 2015, I met a lot of great people from the Ruby community. These people had a profound effect on me, instilling in me a new motivation to become part of something larger than myself. A year ago today, I embarked on a journey to better myself as a Software Engineer. I decided to commit to open source software every day for a year. Even though open source software has been around for decades, up until a year ago I had thought it mostly magic and far beyond my reach. After Rails Conf 2015, it became clear to me that contributing to and becoming part of the open source community was not so far fetched. The Plan The word "plan" might be a bit generous for what I decided to do. I was going to "just keep doing commits for a year". Surely doing something over and over again will yield good results...right? It has to have at least some effect on some aspect of my programming ability. And so that is what I did. For one year, I made at least one commit to an open source repository (someone else's or my own) every day: I started this endeavor on April 26th 2015 and ended it today, April 26 2016. Reality Check At the beginning of the year, I was under the impression that I was going to be able to contribute to other people's repositories every day without too much effort. That idea was soon shattered due to the short time constraints I had to work with. After all, I am happily employed and unable to devote more than a few hours a day to open source work. Exploring someone else's code base, reproducing an issue and finding a solution can take more than a few hours. It became clear that I needed to fill in gaps of time with my own projects. This ended up being much more fun than I had anticipated and I got to build some cool libraries that people would actually use: Passages validates_type Rescue Groups validates_subset Honest Renter However, this does not mean that my only contributions were to my own projects. Oh no, far from it, I forked repositories on Github like ## How to Diagnose Ruby on Rails N + 1 Query Problems DevFeed: [How to Diagnose Ruby on Rails N + 1 Query Problems]() Original publisher: [Read original article]() Published: 2016-04-17T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [Rails](), [Query (disambiguation)](), [Ruby](), [Database](), [Heroku](), [Development]() Tags: [activerecord](), [analysis](), [database](), [how-to](), [performance](), [production](), [rails](), [ruby](), [ruby-on-rails]() ### AI overview This tutorial explains how to diagnose Ruby on Rails N + 1 query problems that may be hidden in development but become visible under production traffic. It uses New Relic, including its Heroku add-on, as the primary diagnostic tool and also discusses analyzing application log files. The example demonstrates an application whose controller and view access users, posts, and themes through ActiveRecord, producing more database queries than necessary. ### Source excerpt Diagnosing performance problems in a production Ruby on Rails application can be deceptively complex. When constructing a new application or expanding the features of an existing one, development environments that are not subject to typical production web traffic may not make performance issues evident. In those instances, the use of some simple (and mostly free) tools can help diagnose performance issues in production. If an application is hosted on Heroku, the New Relic add-on can be added to the application for free. Despite it having a few limitations, the free version of New Relic can be extremely valuable for diagnosing some common performance issues. New Relic will be the primary tool used in this post for analysis, but an application's log files can prove to be just as valuable when analyzed correctly. Setup The example application has the following database structure and respective models: create_table :users do |t| t.string :email t.string :first_name t.string :last_name t.timestamps(null: false) end create_table :posts do |t| t.integer :user_id t.integer :theme_id t.string :content t.timestamps(null: false) end create_table :themes do |t| t.string :name t.timestamps(null: false) end class User < ActiveRecord::Base has_many :posts end class Post < ActiveRecord::Base belongs_to :user belongs_to :theme end class Theme < ActiveRecord::Base end An example controller, home_controller.rb has a single action: class HomeController < ApplicationController def show @user = User.find(params[:user_id]) end end The above action renders a single simple view, show.html.haml: %h3= "Posts from #{ @user.first_name } #{ @user.last_name }" - @user.posts.each do |post| .theme= "Theme #{ post.theme.name }" .content= post.content Additionally in the application's Gemfile, the New Relic Ruby gem has been added: source 'https://rubygems.org' # ... gem 'newrelic_rpm' On a development machine under no contention, this action will quickly render a page consisting of a User's name inf ## Things to Consider when Metaprogramming in Ruby DevFeed: [Things to Consider when Metaprogramming in Ruby]() Original publisher: [Read original article]() Published: 2016-04-10T12:00:00Z Content type: article Language: en Sources: [Jake Yesbeck]() Topics: [Ruby](), [Code]() Tags: [code](), [developers](), [examples](), [performance](), [readability](), [ruby]() ### AI overview An overview of Ruby metaprogramming that examines its benefits, costs, effects on code discovery and readability, and performance considerations in frequently executed code. ### Source excerpt Metaprogramming in Ruby is a polarizing topic. The most common purpose of Ruby metaprogramming is for code to alter itself at runtime. Metaprogramming can be used to achieve terse and more flexible code. However, it is not without its cost. As with most things, nothing of value is free, even metaprogramming. Undoubtedly, there is a time and place for metaprogramming; but, awareness of concessions that need to be made to support a metaprogrammed solution is important. Code Discovery and Readability One problem with metaprogramming solutions are their obstruction of code discovery. When entering a new project or simply trying to re-familiarize oneself with an existing one, tracing code execution in a text editor can be quite difficult if method definitions do not exist. For example, we can assume that a User class exists with a set of metaprogrammed methods: class User [ :password, :email, :first_name, :last_name ].each do |attribute| define_method(:"has_#{attribute}?") do self.send(attribute).nil? end end end Although a little contrived, this code is a list of simple convenience methods on a User class. This solution is easily extended to include additional attributes without a full method definition per attribute. However, these methods can not be found using grep, silver searcher, or other "find all" tools. Since the method has_password? is never explicitly defined in the code, it is not discoverable. A Work Around: To combat this issue, some developers choose to write a comment listing the defined method names above the metaprogramming block. This simple solution can greatly help the readability of the code: class User # has_password?, has_email?, has_first_name?, # has_last_name? method definitions [ :password, :email, :first_name, :last_name ].each do |attribute| define_method(:"has_#{attribute}?") do self.send(attribute).nil? end end end Performance Depending on the amount of times a piece of code is executed, performance considerations can be extremely importa ## How to Deal with Timezones the Active Support Way DevFeed: [How to Deal with Timezones the Active Support Way]() Original publisher: [Read original article]() Published: 2016-04-03T12:00:00Z Content type: article Language: en Sources: [Jake Yesbeck]() Topics: [Rails](), [Ruby](), [DateTime](), [Databases]() Tags: [database](), [how-to](), [rails](), [ruby](), [ruby-on-rails](), [time](), [timezone]() ### AI overview This tutorial explains how to handle timezones with Ruby on Rails' ActiveSupport. It covers supported timezone lists, parsing timestamps with Time.zone, safely applying temporary zones with Time.use_zone, and converting timestamps between zones, including displaying UTC database timestamps in a user's local time. ### Source excerpt "Well the code is bad because we had to..." is a phrase one might hear when discussing timezone offsets or daylight savings time considerations. Unless a developer is fortunate enough to work at a company whose userbase is entirely located in the UTC timezone, writing software aware of different timezones can be a daunting task. Luckily, Ruby on Rails' ActiveSupport library has some very nice built in features that can prove invaluable when facing time related issues. Built-in Timezones ActiveSupport in Ruby on Rails 4.0+ has a built in list of all supported timezones on the TimeZone class: ActiveSupport::TimeZone.all.map(&:name) #=> ["American Samoa", "International Date Line West", "Midway Island", "Hawaii", "Alaska", "Pacific Time (US & Canada)", "Tijuana", "Arizona", "Chihuahua", "Mazatlan", "Mountain Time (US & Canada)", "Central America", "Central Time (US & Canada)", "Guadalajara", ...] This list of timezones can be used when parsing strings into Time objects and converting an existing Time object from one timezone to another. For working with timezones in the United States, a handy us_zones method is also available on the same class. One interesting detail about this list of timezones is the lack of daylight savings time qualifiers. Keeping the timezones agnostic of daylight savings helps simplify their use. A developer does not need to worry about using one timezone object over another due to the time of the year. Time.use_zone The ActiveSupport library adds some functionality to built in Ruby classes. One of those additions is the ability to set and retrieve the zone attribute on the Time class. After a zone is set, it can be used when parsing strings into Time objects: Time.zone = 'Pacific Time (US & Canada)' Time.zone.parse('2016-04-01 10:00:00') #=> Fri, 01 Apr 2016 10:00:00 PDT -07:00 This code takes a timestamp string without a timezone specified and uses the value of Time.zone to correctly represent the time in the Pacific timezone. However, an immedia ## Five More Active Record Features You Should Be Using DevFeed: [Five More Active Record Features You Should Be Using]() Original publisher: [Read original article]() Published: 2016-03-27T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [Rails](), [Ruby](), [Databases](), [Code]() Tags: [activerecord](), [code](), [databases](), [rails](), [ruby](), [ruby-on-rails]() ### AI overview This tutorial presents additional ActiveRecord features for Ruby on Rails applications. It explains how pluck can reduce memory allocation when retrieving selected columns, how transactions can preserve atomic behavior when updates fail, and begins discussing model callbacks. The supplied article is truncated during the callbacks section. ### Source excerpt In a previous post, I illustrated a few helpful ActiveRecord features. The entire API of ActiveRecord cannot possibly be contained within a single or even a handful of digestible posts; but, here are at least five more pieces of that massive API that some might find useful. Just like before, the example application used to demonstrate these features will be an imaginary Ruby on Rails application: "booksandreviews.com": class Book < ActiveRecord::Base belongs_to :author has_many :reviews end class Author < ActiveRecord::Base has_many :books end class Review < ActiveRecord::Base belongs_to :book end 1. pluck Introduced in Ruby on Rails 4.0, the pluck method helps keep memory allocation to a minimum when returning results from ActiveRecord queries. A great use case for the pluck method is when a database table backing an ActiveRecord object has a very large number of columns. In this situation, returning an object's full dataset can be cause unnecessary memory allocation and potentially expensive deserialization (in the case of custom or JSON serialized columns). To get a list of book_ids from the 'fantasy' genre, the pluck method is a simple to use: Book.where(genre: 'fantasy').pluck(:id) # SELECT "books"."id" FROM "books" WHERE "books"."genre" = 'fantasy' => [1, 3, 45, ...] An important thing to recognize about the pluck method is its return value. Unlike its cousin, select, the pluck method does not return an ActiveRecord instance. Multiple column names may be passed to pluck and the values of these columns will be returned in a nested Array. The returned Array will maintain the order of columns to how they were requested: Book.where(genre: 'fantasy').pluck(:id, :title) # SELECT "books"."id", "books"."title" FROM "books" WHERE "books"."genre" = 'fantasy' => [[1, 'A Title'], [3, 'Another One']] While possible, it might not always be the best idea to request multiple columns in a single pluck call. Too many columns can produce an unruly result and nullify the performa ## How to Build a Ruby on Rails Engine DevFeed: [How to Build a Ruby on Rails Engine]() Original publisher: [Read original article]() Published: 2016-03-20T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [Rails](), [Ruby](), [App](), [Routing (disambiguation)]() Tags: [app](), [applications](), [building](), [generate](), [generators](), [how-to](), [plugin](), [rails](), [routing](), [ruby](), [ruby-on-rails](), [structure]() ### AI overview A tutorial on building a Ruby on Rails Engine, a miniature application that supplements a larger Rails application. It covers generating an Engine or creating its directories and files manually, defining the Engine, isolating its namespace, and organizing it as a gem. ### Source excerpt Ruby on Rails Engines are miniature applications whose purpose is to supplement a larger Ruby on Rails application. If functionality can exist independent from a main application, an Engine can provide a wonderful degree of encapsulation. Recently, I created the and "gemified" the Passages Ruby on Rails Engine to help alleviate some routing frustration. This gem will be the be used as the example for demonstrating what goes into creating a Ruby on Rails Engine. Revving Up There are two ways to start building an Engine. One option is to use the built in generators to create directories and dummy classes. These generators behave in the same way as standard Rails generators. To generate an Engine in this way, use the plugins built in generator: $ rails plugin new passages --mountable Note: Engines and Plugins are not exactly the same in the Ruby on Rails world but the --mountable flag tells the plugin generator to generate a full Engine. The other approach is to simply create the needed directories and files by hand. This is was the way the Passages Engine was built, resulting in the following directory structure: |-app |--controllers |---passages |---- |--views |---passages |---- |-config |--routes.rb |--initializers |---assets.rb |-lib |--passages |---engine.rb Some directories that the rails generator would have added are missing (i.e. models, helpers, mailers). These directories might be necessary for some projects, but the Passages Engine did not have use for them. The file at the heart of it all is engine.rb. This file is responsible for defining the engine and will also be utilized later to add optional enhancements an Engine can take advantage of: module Passages class Engine < ::Rails::Engine isolate_namespace(Passages) end end An interesting line in this file is the isolate_namespace method call. This method helps ensure encapsulation for the Engine by isolating its controllers, helpers, views, routes, and any other ## The Power of Arel DevFeed: [The Power of Arel]() Original publisher: [Read original article]() Published: 2016-03-13T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [Rails](), [Object-relational mapping](), [Ruby](), [SQL](), [Databases](), [web applications]() Tags: [activerecord](), [orm](), [rails](), [ruby](), [ruby-on-rails](), [sql](), [web-applications]() ### AI overview This tutorial explains how Arel, the relational algebra library underlying ActiveRecord, helps Ruby on Rails developers construct complex database queries in pure Ruby. It compares Arel-based query composition with raw SQL, including filtering by dates and disambiguating columns when joining tables. ### Source excerpt Many modern web applications have at least a few overlapping responsibilities. One of these responsibilities deals with maintaining state. A common choice for storing this state is by way of a relational database. Ruby on Rails applications assume the presence of a database by default and communicate with it via ActiveRecord. ActiveRecord is an Object Relational Mapping (ORM). Under the hood, ActiveRecord uses a relational algebra library called Arel to compose queries for execution. Arel is a very powerful library readily available for when ActiveRecord falls short. The Basics Keeping up with tradition, assume a standard Ruby on Rails application exists with at least two models, User and Post: create_table "posts" do |t| t.integer "user_id" t.string "category" t.datetime "created_at", null: false t.datetime "updated_at", null: false end create_table "users" do |t| t.string "first_name" t.string "last_name" t.string "email" t.datetime "created_at", null: false t.datetime "updated_at", null: false end class User < ActiveRecord::Base has_many :posts end class Post < ActiveRecord::Base belongs_to :user end Ask: Find all posts within a category belonging to a user. For such a simple query, ActiveRecord is capable of generating the appropriate SQL statement: Post.where(user_id: 123, category: 'news') .to_sql # => SELECT "posts".* FROM "posts" WHERE "posts"."user_id" = 123 AND "posts"."category" = 'news' However, if the query needed to be more complex, this simple where clause is not sufficient. For example, instead of all posts within a category for a user, only the posts which have a created_at in the current month are desired. A naive ActiveRecord only solution might look like: beginning_of_month = Date.today .beginning_of_month Post.where(user_id: 123, category: 'news') .where('created_at >= ?', beginning_of_month) .to_sql # => SELECT "posts".* FROM "posts" WHERE "posts"."user_id" = 123 AND "posts"."category" = 'news' AND (created_at >= '2016-03-01' ) This query will ## The Real Cost of Technical Debt DevFeed: [The Real Cost of Technical Debt]() Original publisher: [Read original article]() Published: 2016-03-06T12:00:00Z Content type: opinion Language: en Sources: [Jake Yesbeck]() Topics: [Code](), [Software](), [App](), [web applications](), [Mobile]() Tags: [communication](), [complexity](), [financial](), [implementation](), [reduce](), [scope](), [shortcuts](), [software-engineer](), [technical](), [web]() ### AI overview The article explains technical debt as the future work created when software teams use shortcuts to meet immediate time or external pressures. It argues that unchecked debt increases complexity, expands the scope of seemingly simple changes, and can seriously damage a software application. The article recommends communicating the long-term cost of fast solutions and planning regular efforts to reduce accumulated overhead. ### Source excerpt Writing software is an iterative process. Rarely is software written and then never revisited. When this iteration occurs, a software engineer is presented with multiple options. Usually, a single objectively correct option is present but may not be chosen due to time constraints or other outside pressures. When shortcuts are taken to alleviate these external pressures, technical debt is often accrued. Permit Today, Pay Tomorrow Technical debt is referred to as such due to its similarities with financial debt. A credit card enables a person to complete a purchase they may not otherwise be able to, resulting in a bill to be paid by that person in the future: a debt. Technical debt is the same concept; a current feature or product is completed faster than previously possible at the cost of future work: a technical debt. If not apparent from name alone, technical debt is not a desired feature in a healthy software system. This debt can often appear benign, giving no cause for alarm or prompt resolution; however, I believe that thinking to be in error. Technical debt can severely damage a software application and may even cause its destruction. Solution: Communicate the Importance of the Correct Approach Open communication about why a solution might be slower to accomplish now, but result in a healthier system for the future can be very important. A conversation about the amount of technical debt a "fast" solution will generate might help reduce pressure. Ongoing Overhead Left unchecked, technical debt can become a constant complexity or time increasing abscess for an otherwise healthy software application. Suddenly, every task that must interact with or touch technical debt affected code is not as simple as it should be. The "simple change" that a product team might request can have its scope increased due to technical debt overages. For example, we can assume that a typical web application decides that its new mobile friendly version should be a parallel implementatio ## Ruby Spaceship \<=\> Operator DevFeed: [Ruby Spaceship \<=\> Operator]() Original publisher: [Read original article]() Published: 2016-02-28T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [Ruby](), [Programming](), [Sorting](), [Code]() Tags: [code](), [programming](), [ruby](), [sorting]() ### AI overview A practical introduction to Ruby's <=> spaceship operator, explaining its -1, 0, and 1 comparison results and showing how to use it for ascending, reverse, grouped, and compound sorting. ### Source excerpt Adhering to the law of trichotomy, the <=> operator (sometimes called the "Spaceship Operator") works by comparing two elements and returning a -1, 0, or 1. While the original mathematical criteria applies to only real numbers, many programming languages implement the law of trichotomy as a general comparison between equivalent types. Basics At first glance, the return value of the <=> operator can be a bit confusing. A simple way to remember the significance of these return values is to break an expression down from left to right: 1. < -> -1 if a < b, then -1 is returned 2. = -> 0 if a = b, then 0 is returned 3. > -> 1 if a > b, then 1 is returned Example: > a = 3 > b = 5 > a <=> b # => -1 > a = 3 > b = 3 > a <=> b # => 0 > a = 10 > b = 3 > a <=> b # => 1 Sorting The <=> operator can be used alone for comparison or its contract honored within a block following the sort method. By default, the <=> operator behaves as described above: list = [8, 3, 1, 4, 0, 3] list.sort { |a, b| a <=> b } # => [0, 1, 3, 3, 4, 8] Following this pattern, it is easy to sort a list in reverse by swapping operand positions: list = [8, 3, 1, 4, 0, 3] list.sort { |a, b| b <=> a } # => [8, 4, 3, 3, 1, 0] The sort method is extendable beyond explicit use of the <=> operator. A block passed to sort must only return either -1, 0, or 1 for sorting to work effectively. If the same list were to be ordered in odds then evens: list = [8, 3, 1, 4, 0, 3] list.sort { |a, _| a.odd? ? -1 : 1 } # => [3, 3, 1, 4, 8, 0] Also, since -1, 0, and 1 are simple integers, creating compound <=> blocks is possible. If the same list were to be sorted odds then evens, with all odd and even numbers sorted in ascending order, it might look like this: list = [8, 3, 1, 4, 0, 3] list.sort do |a, b| if a.odd? if b.odd? # both are odd, default <=> behaviour is used a <=> b else -1 # a < b end else # a is even if b.even? # both are even, default <=> behaviour is used a <=> b else 1 # a > b end end end # => [1, 3, 3, 0, 4, 8] ## Four PostgreSQL Tips DevFeed: [Four PostgreSQL Tips]() Original publisher: [Read original article]() Published: 2016-02-21T12:00:00Z Content type: article Language: en Sources: [Jake Yesbeck]() Topics: [PostgreSQL](), [Databases](), [SQL](), [Command-line interface](), [Object-relational mapping](), [web applications]() Tags: [command-line](), [database](), [open-source](), [orm](), [postgresql](), [production](), [sql]() ### AI overview This article presents PostgreSQL tips for detecting duplicate rows with window functions, filtering queries by time ranges, and executing queries remotely through the command-line interface. It also introduces PostgreSQL as an open-source object-relational database commonly used by production web applications. ### Source excerpt PostgreSQL is an open source object-relational database used to power many production web applications. While many web applications interact with relational databases through Object Relational Mappers (ORM), direct SQL queries via a command line interface or graphical client are still common. When writing these queries, these four tips may come in handy. All examples will assume the presence of a simple users table: Column | Type ---------------+----------------------------- id | integer first_name | character varying(255) last_name | character varying(255) email | character varying(255) created_at | timestamp without time zone updated_at | timestamp without time zone password | character varying registered | boolean registered_at | timestamp without time zone Indexes: "users_pkey" PRIMARY KEY, btree (id) 1. Finding Duplicate Rows A common mechanism for defending against duplicate rows in database tables are unique indexes. However, at the time of table creation, a unique index or two may have been forgotten. Duplicates in a table must be removed before a unique index may be added. A great way to detect duplicates in PostgreSQL is by using window functions. Window functions are similar to aggregates; but, instead of grouping rows for the response, it maintains each row's individuality. Desired query: Find all duplicate users with the same first_name, last_name, and email, returning duplicate ids only (do not return the oldest id). SELECT id from ( SELECT id, ROW_NUMBER() OVER( PARTITION BY first_name, last_name, email ORDER BY id ) AS user_row_number FROM users ) duplicates WHERE duplicates.user_row_number > 1 This query will identify all the rows of the users table which share the same defined columns and return the primary key (id) of rows after the first via the duplicates.user_row_number > 1 condition. The result of this query can then be fed into a DELETE query to remove the duplicates. The ROW_NUMBER() built-in function returns an incremented value assigned to ## Ruby Threads and ActiveRecord Connections DevFeed: [Ruby Threads and ActiveRecord Connections]() Original publisher: [Read original article]() Published: 2016-02-14T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [Ruby](), [Concurrent Programming](), [Concurrency](), [Database](), [API]() Tags: [activerecord](), [api](), [concurrent-programming](), [database](), [ruby]() ### AI overview This article explains how Ruby threads can process large datasets concurrently while sharing memory within a process. Using ActiveRecord, it demonstrates batched email validation through an external API and discusses the accumulation of database connections created by spawned threads. ### Source excerpt Processing large data sets is a common problem faced by many production web applications. One solution is to divide the work amongst multiple processes and have each responsible for a single or significantly smaller batch of data. However, this solution is not without its problems. Machine provisioning limitations or financial barriers may invalidate this solution for a very large N. Within the same vein as "divide and conquer" exists another solution, one which requires far fewer parallel processes: Threads. In the Ruby programming language, a Thread is a built-in object for concurrent programming. Unlike independent processes, all Ruby Threads within the same process share memory, enabling each individual Thread to consume or process objects and elements from the same data store. For this example, a database will be queried, results manipulated and finally returned to same database via ActiveRecord. First Pass Given a User model backed by a simple users table: class User < ActiveRecord::Base end class CreateUsersTable < ActiveRecord::Migration def change create_table :users do |t| t.string :first_name t.string :last_name t.string :email t.boolean :validated, default: false t.timestamps null: false end end end The problem to solve is fairly straight forward: All User records that are not already validated should be fetched and an external API hit with their email address for validation, then saved. If a User's email address is not valid, it should be removed. Fast forwarding through time, it can be assumed that a completely serial solution has been written and deemed unsatisfactory. Then, during a second iteration, a bit of concurrent code was written: class UserEmailValidator def self.run User.where(validated: false) .find_in_batches(batch_size: 30) do |user_batch| validate_emails(user_batch) end end def self.validate_emails(user_batch) threads = user_batch.map do |user| Thread.new do email_validator = EmailService.new(user.email) email_validator.validate user.ema ## How to Remove a Column with Zero Downtime in Ruby on Rails DevFeed: [How to Remove a Column with Zero Downtime in Ruby on Rails]() Original publisher: [Read original article]() Published: 2016-02-07T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [Rails](), [Ruby](), [Object-relational mapping](), [Database](), [Persistence](), [PostgreSQL](), [Deployment](), [Continuous integration]() Tags: [activerecord](), [continuous-deployment](), [continuous-integration](), [database](), [how-to](), [orm](), [postgresql](), [rails](), [ruby](), [ruby-on-rails](), [uptime]() ### AI overview A tutorial explains how removing a database column affected production Ruby on Rails applications before Ruby on Rails 4.0.0, focusing on ORM behavior, uptime, and the multi-phase deployment process used to avoid downtime. ### Source excerpt For a production Ruby on Rails application, uptime is paramount. Altering the structure of an application's persistence layer is an operation that competes directly with uptime. Specifically, removing a table column within a relational database causes issues with the ActiveRecord ORM (the default relational mapping within a Ruby on Rails application). However, this particular pain point has been removed as of Ruby on Rails 4.0.0, saving developers a lot of headache and greatly reducing the need for structural change coordination. Old and Busted To demonstrate the problem, a simple Ruby on Rails 3.2 application is created with a User model: class User < ActiveRecord::Base end Supporting the User model is a PostgreSQL database table created with a migration: class CreateUsers < ActiveRecord::Migration def change create_table :users do |t| t.string :first_name t.string :last_name t.string :email t.timestamps null: false end end end To ensure this application has as close to 100% uptime as possible, it can be assumed that it is behind some kind of pre-loader. As in, when code is deployed, existing requests are given time to complete before new requests are shepherded over to the new version of the code. In a Ruby on Rails 3.2 application, a problem will arise when a column is removed from the database and the ORM does not have time to restart. In this case, even the pre-loader will not save an application from throwing an error about the missing column. To emulate this problem, a rails console is run in the production environment and a User is created: RACK_ENV=production rails console > User.create(first_name: 'test', last_name: 'test') # => # In parallel, the psql command line client is used to connect to the same production database used by this server, all still running locally. Within this psql prompt, the email column from the users t ## Nine Months of Commits DevFeed: [Nine Months of Commits]() Original publisher: [Read original article]() Published: 2016-01-30T12:00:00Z Content type: opinion Language: en Sources: [Jake Yesbeck]() Topics: [coding](), [Open Source](), [GitHub Issues](), [GitHub](), [Development](), [Pull Request](), [Ruby]() Tags: [coding](), [development](), [github](), [github-issues](), [open-source](), [pull-request](), [ruby]() ### AI overview A personal reflection on nine months of participating in open source development through a Year of Commits. The author discusses increased coding confidence, the subjectivity of software feedback and pull-request reviews, and the use of GitHub Issues to find projects needing help. The article also celebrates other developers engaging with the author's project and the author's growing connection to the open source community. ### Source excerpt It is hard to believe that already nine months have passed since the onset of my Year of Commits. In these past nine months, I have experienced a wide range of new aspects of open source development. This has truly been an eye opening experience, with many facets I doubt I would have experienced otherwise. Confidence An unexpected and fortuitous side effect of my Year of Commits has manifested as a significant boost in my overall coding confidence. Confidence is a very important aspect of anyone's life. Without confidence, a person may place objectives out of reach or deem them too arduous to achieve. Believing in one's self and having the confidence to stand up when knocked down is a trait that carries a lot of weight, especially when writing software. Writing software can be a very subjective endeavor. Especially in languages like Ruby, there are many solutions to the same problem. These subtle differences can spark myriad conversations or criticisms of a person's code. For those fortunate enough to write code for a living, think back to the times a pull request saw the most attention and accrued the most comments. Chances are, those comments pointed out style choice discrepancies or "we do not do it that way" assertions. Maintaining a steady level of confidence in the midst of such feedback is paramount. I am lucky enough to have received feedback from many different people in many different situations. This feedback and perspective help inoculate a developer and encourage them to remember they are not their code. Github Issues Another exciting event since my last year of commits update pertains to Github issues. Github is a fantastic piece of software responsible for managing git repositories and enabling collaboration amongst developers. An issue may be opened by anyone with a Github account on any public repository of their choosing. These issues have been the primary avenue I have used to find which projects need help and what I can do to help them. My excite ## Ruby Private Class Methods DevFeed: [Ruby Private Class Methods]() Original publisher: [Read original article]() Published: 2016-01-24T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [Ruby](), [Programming](), [Code](), [Programming language]() Tags: [code](), [programming](), [programming-language](), [ruby](), [ruby-programming-language](), [syntax]() ### AI overview This tutorial explains Ruby method visibility, focusing on how to define private class methods. It contrasts instance methods, class methods, public, private, and protected visibility, then shows why a direct private declaration can fail for a class method and introduces eigenclass syntax as an alternative. ### Source excerpt In the Ruby programming language, defined methods come in two variants: instance methods and class methods. Instance methods are available after an object has been initialized, creating an instance. Class methods, on the other hand, are available without creating an instance of the class they are defined upon. Ruby methods can vary in visibility. Public methods are available in any context, while private methods' availability is restricted within the instance of a class and its descendants. A third visibility scope, protected, behaves similarly to private methods, but protected methods can be called by other instances of the same class. For a quick refresher, public and private instance methods look like this: class Dog def do_trick bark end private def bark puts 'woof woof' end end When the public method is called: > dog = Dog.new > dog.do_trick # => woof woof And the private method: > dog = Dog.new > dog.bark # => NoMethodError: private method `bark' called for Private class methods might not be as common as private instance methods, but they still have their place. For instance, a class method may require internal helper methods to complete its function. Whatever the reason, defining private class methods has value but is not always intuitive. This example Dog class needs to maintain a list of tricks that will be used within the other public class methods. This list should not be accessible to any callers outside the Dog class. The wrong way A first pass at writing the private tricks method could look like: class Dog private def self.tricks [:bark, :roll_over, :fetch] end end However, when testing the visibility of the tricks method: > Dog.tricks # => [:bark, :roll_over, :fetch] Uh oh, no error was thrown indicating a that a private method was called, this method is completely public. Why? The reason that the above code did not produce a private method has to do with Ruby's object hierarchy, interactions amongst internal classes, instances of those classes, ## Contributing to Open Source in 7 Steps DevFeed: [Contributing to Open Source in 7 Steps]() Original publisher: [Read original article]() Published: 2016-01-17T12:00:00Z Content type: article Language: en Sources: [Jake Yesbeck]() Topics: [Open Source](), [GitHub](), [Maintainers](), [bug](), [Ruby](), [Library](), [Tooling]() Tags: [bug](), [contribute](), [github](), [library](), [maintainers](), [open-source](), [ruby](), [tooling]() ### AI overview This article introduces contributing to open source through a seven-step process. The supplied text covers finding repositories with open issues, using CodeTriage and GitHub Explore to discover projects, reviewing a Ruby library example, and reading project contribution guidelines. ### Source excerpt Making contributions to open source repositories is a great way to give back to the community. Open source software has a rich history and is a crucial component in many successful software applications. Most open source projects are maintained by either one or many developers for free. Since "free" is not usually the price of food and shelter, these maintainers are not available to work on their projects at all hours, most of them have day jobs so they can eat and buy clothing. To help keep open source projects up to date and bug free, members of the community regularly contribute a portion of their own free time. Since the start of the Year of Commits project, I have made quite a few contributes to open source software and distilled the process down to these seven basic steps. 1. Find a repository that has some issues A great way to get a foot in the door in an open source repository is by solving one of its open issues. A project is much more likely to accept code that addresses an open issue as opposed to code that is added "just because". Open issues are either bugs or feature requests and are tracked on Github. Some really great tools exist for exploring Github's vast index of repositories for relevant projects. CodeTriage is one of these awesome tools. CodeTriage enables a user to narrow down Github's list of repositories by programming language. CodeTriage has a very nice UI, ordering a very large amount of Github projects in descending count of open issues. Alternatively, Github has their own tooling around discovering projects with their explore feature. Trending repositories from this week or this month are available on a per programming language basis. The explore feature is great for popular projects but exposes far fewer projects than CodeTriage. To demonstrate a typical contribution's life cycle, the fetching-gem project has been chosen. The fetching-gem library is a convenience Ruby library for accessing elements of nested hashes and arrays with dot ## How To Parallelize Ruby HTTP Requests DevFeed: [How To Parallelize Ruby HTTP Requests]() Original publisher: [Read original article]() Published: 2016-01-10T12:00:00Z Content type: tutorial Language: en Sources: [Jake Yesbeck]() Topics: [Ruby](), [Rails](), [API](), [HTTP](), [Development](), [web applications](), [Back end]() Tags: [api](), [development](), [how-to](), [http](), [rails](), [ruby](), [web-development]() ### AI overview This tutorial explains why managing and parallelizing Ruby HTTP requests matters in a Ruby on Rails web application backed by an external or internal API. It presents a history page whose user, favorite, wishlist, and transaction data require separate API requests, and describes how sequential retrieval can make the page slow as request counts grow. ### Source excerpt It turns out that managing web requests is quite important when doing web development. A web application backed by an external or internal API can issue a lot of requests when rendering a seemingly simple web page. How those requests are made and in what order is very important. With improper parallelization, an end user's entire experience can go from delightful to horrific in a matter of seconds. The Build Up A basic Ruby on Rails application might have the following features: A User can create a favorite of an item, creating a FavoriteItem. A User can add an item to their wishlist, creating a WishlistItem. A User can buy an item, creating a TransactionItem. Each model this system uses is backed by an API. User, TransactionItem, WishlistItem, and FavoriteItem models all require a remote HTTP request for their information. As a web application experiences growth, this structure is not uncommon. The same API might back a mobile app, website, and any other internal tooling to help this company with its day to day affairs. The API that this application uses works in a two phase manner: A user can be requested by their id. /users/:id returns a User corresponding to the given id. Each supporting model is requested with the same user_id. /users/:id/favorite_items will return an array of FavoriteItems for the specified User. The contract of this API is for all intents an purposes, non-negotiable. In-lined data or other request saving patterns are not available, the client must use the API as provided. Sequential Approach Within this example application, the most request intensive page is the User's history page. The history page consists of everything the user has done. Items a user has added to their favorites resulting in FavoriteItems, Items bought by the user resulting in TransactionItems, and Items added to a user's wish list resulting in WishListItems. To complement the (ex/in)ternal API, two helper methods exist on each model: remote_find which accepts an id or arr ## Passages Rails Engine DevFeed: [Passages Rails Engine]() Original publisher: [Read original article]() Published: 2016-01-03T12:00:00Z Content type: article Language: en Sources: [Jake Yesbeck]() Topics: [Rails](), [Routing (disambiguation)](), [Ruby](), [API](), [Documentation]() Tags: [api](), [documentation](), [http](), [rails](), [routing](), [ruby]() ### AI overview Passages Rails Engine is presented as a Ruby on Rails engine for exposing application routes during or outside development mode and searching route information such as HTTP verbs, controllers, and paths. It is intended to make route inspection easier for internal and external APIs when documentation is incomplete or outdated. ### Source excerpt Routing in the Ruby on Rails world can, at times, be a tad confusing. The official Rails guide is very helpful for the basics; but, as an application grows, it can become hard to remember specific details about every single route. Existing Routing Tools To remedy the issue of route complexity, a few helpful tools already exist. The most useful one is rake routes, which can be executed in the working directory of a Rails application. This tool requires that the application be on the developer's local system, which is fine for applications that a developer owns, but what about services that the developer does not own? While this problem might not exist for everyone, chances are at least one poor software engineer has been slapped in the face with a 404 page and shouted: "I know that route exists! Why doesn't this work?" Another helpful tool in development mode is this screen: This page provides the ability to enter search terms that match words in the paths of specfic routes. However, similarly to rake routes, this screen is only accessible in development mode. While this tool is still extremely useful, there could be cases when route inspection would be helpful without running the server locally. New Hotness The Passages Rails Engine was created to fulfill two main purposes: 1. To expose routes of a Ruby on Rails application either during or outside development mode. 2. Enable searching on multiple pieces of a route's information (HTTP verb, controller, path, etc). Some might wonder by 1 would even be valuable. Imagine for a moment that a team of engineers decides that they need an internal API to power their various applications. Perhaps while developing this API, some basic documentation is written but never actually kept up to date. Maybe the API changes so fast that documentation just falls behind. Whatever the reason, it becomes laborious for the consumers of that internal API to constantly ask which route does what and which parameters are expected in each URL. ## Things I Wish I Knew When I Started Programming DevFeed: [Things I Wish I Knew When I Started Programming]() Original publisher: [Read original article]() Published: 2015-12-27T12:00:00Z Content type: opinion Language: en Sources: [Jake Yesbeck]() Topics: [Programming](), [Learning](), [Software](), [Tech Debt](), [Code]() Tags: [bug](), [competition](), [efficiency](), [learning](), [patterns](), [process](), [programming](), [software](), [software-engineer](), [speed](), [stress](), [tech-debt](), [work]() ### AI overview This advice article reflects on starting a career in software engineering. It encourages new programmers to work steadily instead of competing on speed, explaining that rushing can increase stress, bugs, and technical debt. It also recommends continuous learning and asking questions without fear of judgment or impostor syndrome. ### Source excerpt If by some magical event I could go back in time to the day before I started my first job as a software engineer, this is what I would say. Drive Slow I mentioned a similar message in a previous post and I believe it is worth repeating. When starting a new job or a new career, it is easy to place external pressures on ourselves regarding time. This is a common issue that can arise when comparing one's own work with those around them. As the new employee, noticing and measuring your own speed and efficiency against existing personnel can feel like the correct thing to do; however, chasing the "competition" or "proving that you are just as fast as them" will only result in high stress levels and bug riddled software. The people who seem "fast" or come off as a "10x engineer" were not born that way. They took their time and learned their craft. And with that, they have slowly accelerated their process and patterns to make them appear extremely quick and efficient. Deadlines should be thought of as real and valid; however, working at lightning speed to try and meet those deadlines will end up causing more work in the long run. What would be better, missing a deadline by a day or making a deadline and incurring so many bugs and tech debt that it takes two weeks to clean everything up? ABL Glengarry Glen Ross's iconic scene has very clear message: Always Be Closing, meaning that one should constantly strive to be in the process completing a sale. When starting out writing software and even after years of doing it, a similar attitude can be extremely helpful: Always Be Learning. From day one to day one thousand, learning and absorbing new information is very important. A key to learning new things is in asking questions. When starting a new job or a new career, there seems to be a stigma attached to asking questions. We are all under the impression that "they hired me to do this job, they must assume I know exactly what I'm doing." This mentality can inhibit our natural in ## Introduction to Rails 5 Attributes DevFeed: [Introduction to Rails 5 Attributes]() Original publisher: [Read original article]() Published: 2015-12-20T12:00:00Z Content type: article Language: en Sources: [Jake Yesbeck]() Topics: [Rails](), [Persistence](), [Code](), [Transactions]() Tags: [activerecord](), [migration](), [persistence](), [rails](), [ruby](), [ruby-on-rails](), [sql](), [transactions]() ### AI overview This article introduces ActiveRecord Attributes in Rails 5. The feature lets developers declare an attribute's type and optional default value, providing explicit type coercion for model attributes. The article demonstrates converting a string-backed success field to a boolean without changing a large database column, and discusses using typed attributes for both persisted and object-lifecycle data. ### Source excerpt Shortly after the tenth anniversary of Ruby on Rails 1.0, Rails 5.0 Beta has been announced. While the main character of this release was without a doubt ActionCable, other really great features have made their debut. Types of Changes One feature that particularly stood out is the introduction of ActiveRecord Attributes. This feature allows a developer to assert a specific type for a given attribute and an optional default value. It is not strict type validation (which I have a very strong affinity for), but it does define explicit type coercion that can be very useful. Given an example application that deals with Transactions, a single table and model might exist: class CreateTransactions < ActiveRecord::Migration def change create_table :transactions do |t| t.integer :user_id t.string :item_name t.integer :quantity t.string :success t.decimal :price t.timestamps(null: false) end end end class Transaction < ActiveRecord::Base end This structure, like most in the wild, could have been created before all edge cases were thought through. For some reason, success is a String instead of a Boolean. While this problem might seem trivial, imagine a system where hundreds of millions of transactions exist. In such a system the entire column might not be able to change without incurring downtime. This is a perfect example problem that Attributes can help remedy. Starting simple, a single line can be added to the Transaction class definition to coerce success to a boolean: class Transaction < ActiveRecord::Base attribute :success, :boolean end Using the same logic that ActiveRecord uses for database column coercion, we can see attributes in action! transaction = Transaction.new(success: 'yes') transaction.success # => true transaction = Transaction.new(success: 'f') transaction.success # => false transaction = Transaction.new(success: 0) transaction.success # => false Just like that, the schema has been improved. Aside from raw SQL update statements, this code now prevents str [Next page]()