RailsConf always boasts an exciting variety of talks that highlight the creativity and interdisciplinary nature of the Ruby community. As a tech sector newcomer, I thought it would be fun to curate a series highlighting speakers whose stories about their experiences in tech captured my curiosity. Read on for today’s speaker spotlight…

Title of Talk:

10x your teamwork through pair programming

Speaker:

Selena Small

How Did you get into Ruby?

I was working as a bar tender in a night club and Tom the regular would come in, he started teaching to me to code - first Assembly 68k, then C, then Ruby and I never looked back!

What’s your favorite part about working on Open Source Software?

While I don't actively contribute, but developing the open means ideas can be easily shared and I rely on that.

What’s your least favorite part about working on OSS?

OSS doesn't promote pair-programming and doesn't always promote good TDD practices.

What inspired you to give this talk?

I've been working in a heavy pairing environment for the last 6 years and have learned the benefits - I want to share those with the world because there are a lot of misconceptions about what it is and what's involved. What makes a great pairing environment is what organisations often strive to be able to claim - a strong sense of psychological safety and collaboration to deliver better outcomes than what an individual can do alone.

What do you want people to take away from it?

Software is about people. Two heads are better than one. Be vulnerable and give it a try.

What are you most looking forward to at this conference?

Meeting some really cool people and enjoying some great social events.

Do you have any other fun plans in Atlanta during the in-person conference week?

What is there to do in Atlanta?

Thanks, Selena, for sharing a bit of your story. See you at RailsConf 2023!

Ruby 3.2.2 has been released.

This release includes security fixes. Please check the topics below for details.

• CVE-2023-28755: ReDoS vulnerability in URI
• CVE-2023-28756: ReDoS vulnerability in Time

See the GitHub releases for further details.

Download

• https://cache.ruby-lang.org/pub/ruby/3.2/ruby-3.2.2.tar.gz

  SIZE: 20467023
  SHA1: 670fce00d83771a1349b116e56a8a3b0ad323769
  SHA256: 96c57558871a6748de5bc9f274e93f4b5aad06cd8f37befa0e8d94e7b8a423bc
  SHA512: bcc68f3f24c1c8987d9c80b57332e5791f25b935ba38daf5addf60dbfe3a05f9dcaf21909681b88e862c67c6ed103150f73259c6e35c564f13a00f432e3c1e46
  

• https://cache.ruby-lang.org/pub/ruby/3.2/ruby-3.2.2.tar.xz

  SIZE: 15118856
  SHA1: 087af286b70b0e17f88c9c4469b471eca2010161
  SHA256: 4b352d0f7ec384e332e3e44cdbfdcd5ff2d594af3c8296b5636c710975149e23
  SHA512: a29f24cd80f563f6368952d06d6273f7241a409fa9ab2f60e03dde2ac58ca06bee1750715b6134caebf4c061d3503446dc37a6059e19860bb0010eef34951935
  

• https://cache.ruby-lang.org/pub/ruby/3.2/ruby-3.2.2.zip

  SIZE: 24615317
  SHA1: a1b6d57019d41dca269b4b16a80784755d34b81d
  SHA256: cc216ecb4f49064d8f44e10ecf9218cfd7b28cf4168bb79ecdf171e321db4af1
  SHA512: 569a68d89cc9a646cd0319d7cb8d57df3a55c0ac2c64f1f61607cc9c06b3aa8415eb8d38f7893ab3dbf072da9e919fbc454a9338e924c20a6a5110a1fa301d52
  

Release Comment

Many committers, developers, and users who provided bug reports helped us make this release. Thanks for their contributions.

Posted by naruse on 30 Mar 2023

Ruby 3.1.4 has been released.

This release includes security fixes. Please check the topics below for details.

• CVE-2023-28755: ReDoS vulnerability in URI
• CVE-2023-28756: ReDoS vulnerability in Time

See the GitHub releases for further details.

Download

• https://cache.ruby-lang.org/pub/ruby/3.1/ruby-3.1.4.tar.gz

  SIZE: 20917933
  SHA1: 38eddfc5a7536b6c8133183563009a4ed9bbe6db
  SHA256: a3d55879a0dfab1d7141fdf10d22a07dbf8e5cdc4415da1bde06127d5cc3c7b6
  SHA512: 41cf1561dd7eb249bb2c2f5ea958884880648cc1d11da9315f14158a2d0ff94b2c5c7d75291a67e57e1813d2ec7b618e5372a9f18ee93be6ed306f47b0d3199a
  

• https://cache.ruby-lang.org/pub/ruby/3.1/ruby-3.1.4.tar.xz

  SIZE: 15316604
  SHA1: 2e2fbf43b7db6f24280548a3544912535bed8212
  SHA256: 1b6d6010e76036c937b9671f4752f065aeca800a6c664f71f6c9a699453af94f
  SHA512: a627bb629a10750b8b2081ad451a41faea0fc85d95aa1e267e3d2a0f56a35bb58195d4a8d13bbdbd82f4197a96dae22b1cee1dfc83861ec33a67ece07aef5633
  

• https://cache.ruby-lang.org/pub/ruby/3.1/ruby-3.1.4.zip

  SIZE: 25241255
  SHA1: 1061632623caa82a68a04a35777ed8f1797a9f8f
  SHA256: 1fce1ab3d61d10a857dc821dab6e77fa41d0663c5dbbfaa5d9b9c2bdec5ce303
  SHA512: 3a334302df97c2c7fec3c2d05d19a40b1ec6f95fef52c85d397196ce62fac4834f96783f0ac7fcba6e2a670f004bcc275db6f1810ace6c68a594e7d2fd9b297b
  

Release Comment

Many committers, developers, and users who provided bug reports helped us make this release. Thanks for their contributions.

Posted by nagachika on 30 Mar 2023

Ruby 3.0.6 has been released.

This release includes security fixes. Please check the topics below for details.

• CVE-2023-28755: ReDoS vulnerability in URI
• CVE-2023-28756: ReDoS vulnerability in Time

This release also includes some bug fixes. See the GitHub releases for further details.

After this release, we end the normal maintenance phase of Ruby 3.0, and Ruby 3.0 enters the security maintenance phase. This means that we will no longer backport any bug fixes to Ruby 3.0 except security fixes.

The term of the security maintenance phase is scheduled for a year. Ruby 3.0 reaches EOL and its official support ends by the end of the security maintenance phase. Therefore, we recommend that you start to plan upgrade to Ruby 3.1 or 3.2.

Download

• https://cache.ruby-lang.org/pub/ruby/3.0/ruby-3.0.6.tar.gz

  SIZE: 21315725
  SHA1: 1052441f0abbb0302fb9f1481d2db99dfb4d4c29
  SHA256: 6e6cbd490030d7910c0ff20edefab4294dfcd1046f0f8f47f78b597987ac683e
  SHA512: d596bfd374ae777717379b409afe8ee1655ade0c0539ada7a10af4780b818efe25a28aa50a2a7226741d1776d744e10ad916641f9d12fb31c7444b0a01d0e0cc
  

• https://cache.ruby-lang.org/pub/ruby/3.0/ruby-3.0.6.tar.xz

  SIZE: 15864560
  SHA1: 7880c34d7193224e967163b12f33bf7aaf7304f6
  SHA256: b5cbee93e62d85cfb2a408c49fa30a74231ae8409c2b3858e5f5ea254d7ddbd1
  SHA512: abbf883cd9f3ddbd171df8f8c3cd35d930623c4c01a5e01387de0aee9811cca7604b82163e18e04f809773bf1ca5a450f13f62f3db14f191f610e116ae4fa6f8
  

• https://cache.ruby-lang.org/pub/ruby/3.0/ruby-3.0.6.zip

  SIZE: 25694359
  SHA1: e75d1bc14dd89c176145dc3968774e30f3a17652
  SHA256: 428d518d12f09df4146fc31dbed47c8d7e10fcccd2426948e5c0862d9321480d
  SHA512: 576d11c668acac57cf4952228b148d17f16ab1dc491145355a4f2068b15f6cab8a4007a84d9d1eda4c1b62837675c82be99ebe6379c314f46c6ebbbf89677b5e
  

Release Comment

Many committers, developers, and users who provided bug reports helped us make this release. Thanks for their contributions.

The maintenance of Ruby 3.0, including this release, is based on the “Agreement for the Ruby stable version” of the Ruby Association.

Posted by usa on 30 Mar 2023

Ruby 2.7.8 has been released.

This release includes security fixes. Please check the topics below for details.

• CVE-2023-28755: ReDoS vulnerability in URI
• CVE-2023-28756: ReDoS vulnerability in Time

This release also includes some build problem fixes. See the GitHub releases for further details.

After this release, Ruby 2.7 reaches EOL. In other words, this is expected to be the last release of Ruby 2.7 series. We will not release Ruby 2.7.9 even if a security vulnerability is found (but could release if a severe regression is found). We recommend all Ruby 2.7 users to start migration to Ruby 3.2, 3.1, or 3.0 immediately.

Download

• https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.8.tar.bz2

  SIZE: 14851891
  SHA1: 3e1c6a7bac0b7ea6becb94a1a8e8630173903387
  SHA256: 09ccf12051d86e5b3877c9e9db8b7eb6495bea180cab88a1fc99851434137c67
  SHA512: 3a9db8d9e79318f869417f2ebf3365907febc0d1428116eabf3253c51d8420f255782b32fa30a54802b9f5f4187fad80dab0611cc80436feec84db87b0456ec6
  

• https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.8.tar.gz

  SIZE: 16950365
  SHA1: 8779ab7cd912697d78dee62ea9f976acdf600c54
  SHA256: c2dab63cbc8f2a05526108ad419efa63a67ed4074dbbcf9fc2b1ca664cb45ba0
  SHA512: 23195d29cec81f54061db14fbc9d0d75aca71ca4de35da3d5712eb08d71fbe27a3f0f2594b58692cf20225188334879e413ac078d10d7b635af0200d02f25ecb
  

• https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.8.tar.xz

  SIZE: 12105320
  SHA1: 9e7c7b790652d6c81ce1157b18eab5f8b11b0a27
  SHA256: f22f662da504d49ce2080e446e4bea7008cee11d5ec4858fc69000d0e5b1d7fb
  SHA512: 4b49dff3e1c2e79d914e10418e4c03026f5d4c137dc337f5c720fe26cb9fcdcf4afc6b7c967356cf5fbe04cc5ef431174c48a035becf3e2322c2c45d3c9b2f59
  

• https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.8.zip

  SIZE: 20732352
  SHA1: c38d38d03d840599e152a2ec62567075cb6ca253
  SHA256: 9567ed0e9015f238ff6bbd5e4fd4ee9df39174eb7a29762beb8920788068661c
  SHA512: e7ad3380cc81ecfebccb39acad7364a20bc5ebf9ce74ca5d82225fe0dea76e2ee46aa97e49b975dd9a00c7ff60d94907d9a27acdbb5c5a48b88a3c58e0a998be
  

Release Comment

Many committers, developers, and users who provided bug reports helped us make this release. Thanks for their contributions.

Posted by usa on 30 Mar 2023

We have released the time gem version 0.1.1 and 0.2.2 that has a security fix for a ReDoS vulnerability. This vulnerability has been assigned the CVE identifier CVE-2023-28756.

Details

The Time parser mishandles invalid strings that have specific characters. It causes an increase in execution time for parsing strings to Time objects.

A ReDoS issue was discovered in the Time gem 0.1.0 and 0.2.1 and Time library of Ruby 2.7.7.

Recommended action

We recommend to update the time gem to version 0.2.2 or later. In order to ensure compatibility with bundled version in older Ruby series, you may update as follows instead:

• For Ruby 3.0 users: Update to time 0.1.1
• For Ruby 3.1/3.2 users: Update to time 0.2.2

You can use gem update time to update it. If you are using bundler, please add gem "time", ">= 0.2.2" to your Gemfile.

Unfortunately, time gem only works with Ruby 3.0 or later. If you are using Ruby 2.7, please use the latest version of Ruby.

Affected versions

• Ruby 2.7.7 or lower
• time gem 0.1.0
• time gem 0.2.1

Credits

Thanks to ooooooo_q for discovering this issue.

History

• Originally published at 2023-03-30 11:00:00 (UTC)

Posted by hsbt on 30 Mar 2023

React community is vast and growing rapidly. For the same business case, there are different ways to solve a problem.

And, whenever there are multiple solutions to do the same thing, the question arises - “When to use one over the other?”

The answer most of the time is - It depends on the use case.

One such most-asked question while handling states is -

When to use useReducer over useState hook?

Let’s understand these hooks in detail and discuss which one should be preferred and when.

The useState hook

The useState is a hook that allows us to have state variables in functional components. It takes the initial state as an argument and returns an array of two entries

• State value
• A function to update the state

The useReducer hook

The useReducer(reducer, initialState) hook accept 3 arguments:

• Reducer function
• Initial state
• Initializer function

The hook then returns an array of 2 items:

• Current state
• Dispatch function

  const [state, dispatch] = useReducer(reducer, initialArg, init?) 
 

Use-case of a state with JavaScript primitives

Using the useState hook

Let’s check out the example of setting up a locale using useState.

function App() {
  const { t,  i18n} = useTranslation();
  const defaultLocale = localStorage['locale'] ? localStorage['locale'] : 'en';
  const [currentLocale, setCurrentLocale] = useState(defaultLocale);

  const localeList = [
    { name: 'English', code: 'en', lang: 'English' },
    { name: '中文', code: 'zh', lang: 'Chinese' },
    { name: 'русский', code: 'ru', lang: 'Russian' },
    { name: 'Française', code: 'fr', lang: 'French' }
  ];
  const onChangeLanguage = (e) => {
    const selectedLocale = e.target.value;
    setCurrentLocale(selectedLocale);
    localStorage.setItem('locale', selectedLocale)
    i18n.changeLanguage(selectedLocale);
  }
  return (
    <div className="App">
      <select onChange={onChangeLanguage} defaultValue={currentLocale}>
        {
          localeList.map((locale, index) => (
            <option key={index} value={locale.code}>{locale.name}</option>
          ))
        }
      </select>
      <div className="translation">
      {t('hello_world')}
      </div>
    </div>
  );
}
 

Pretty simple, right?

Using the useReduce hook

Now, let’s look into the useReducer hook.

function localeReducer(state, action) {
    switch (action.type) {
      case 'CHANGE_LOCALE': {
        return {...state, locale: action.locale}
      }
      default: {
        throw new Error(`Unhandled action type: ${action.type}`)
      }
    }
  }
  function App() {
  // Other code same as the previous one  
  const onChangeLanguage = (e) => {
    const selectedLocale = e.target.value;
    dispatch({
      type: 'CHANGE_LOCALE',
      locale: selectedLocale
    })
    localStorage.setItem('locale', selectedLocale)
    i18n.changeLanguage(selectedLocale);
  }
  } 
 

This code looks a bit more complex than the useState code, isn’t it?

This example involves a primitive value ‘locale’(string) which is not a complex object or an array. So, this use case is more suitable for useState.

Use-case of a state with an object

Now, let’s consider an example of a form taken from the React docs.

We have a user object with two fields: name and age.

Using the useState hook

Firstly let’s write the example using useState.

export default function Form() {
  const [user, setUser] = useState({ name: 'Chetan', age: 30 })

  function handleButtonClick() {
    setUser(previousState => ({
      ...previousState, // Copy the old fields
      ...{ age: previousState.age + 1 }
    }));
  }
  function handleInputChange(e) {
    setUser(previousState => ({
      ...previousState,
      ...{ name: e.target.value }
    }));
  }
  return (
    <div>
      <input
        value={user.name}
        onChange={handleInputChange}
      />
      <button onClick={handleButtonClick}>
        Increment age
      </button>
      <p>Hello, {user.name}. You are {user.age}.</p>
    </div>
  );
}

If the logic of our code gets complicated then the setter function can be large and it will be difficult to handle it. Also, we have to take care of returning new items in every setter function using the spreading operator. This becomes very difficult to manage.

To simplify our lives, we have a useReducer hook to our rescue!

Using the useReducer hook

Now, let’s write the same example using useReducer.

//Calculates and returns the next state
function reducer(state, action) {
  switch (action.type) {
    case 'incremented_age': {
      return {
        name: state.name,
        age: state.age + 1
      };
    }
    case 'changed_name': {
      return {
        name: action.nextName,
        age: state.age
      };
    }
  }
  throw Error('Unknown action: ' + action.type);
}

export default function Form() {
  const [user, dispatch] = useReducer(reducer, { name: 'Chetan', age: 30 });

  function handleButtonClick() {
    dispatch({ type: 'incremented_age' });
  }

  function handleInputChange(e) {
    dispatch({
      type: 'changed_name',
      nextName: e.target.value
    }); 
  }

  return (
    <div>
      <input
        value={user.name}
        onChange={handleInputChange}
      />
      <button onClick={handleButtonClick}>
        Increment age
      </button>
      <p>Hello, {user.name}. You are {user.age}.</p>
    </div>
  );
}

Looks simple and clean.

Isn’t it?

useReducer is very similar to useState, but it lets us move the state update logic from event handlers into a single function outside of our component.

The point to note is when we have a type of state as objects or arrays, it is convenient to use useReducer.

Thumb rules to decide when to use useState or useReducer

Prefer useState if we have:

1. JavaScript primitives(string, boolean, number) as a state( eg. our first use case )
2. Simple business logic
3. Different properties that don’t change in any correlated way and can be managed by multiple useState hooks

Prefer useReducer if we have:

1. JavaScript objects or arrays as a state ( eg. our second use case )
2. Complicated business logic more suitable for a reducer function
3. Different properties tied together that should be managed in one state object

Final thoughts

We should consider incrementally adopting useReducer as our state and validation requirements begin to get more complex, warranting the additional effort.

While adopting useReducer for complex objects frequently, if there are many pitfalls around mutation, introducing  Immer  could be worthwhile.

React docs recommend using a reducer if we often encounter bugs due to incorrect state updates in some components, and want to introduce more structure to its code.

Using useState or useReducer is a matter of preference. We can convert between useState and useReducer back and forth: they are equivalent!

We don’t have to use reducers for everything. We can mix and match!

If the project has gotten to the point of state management complexity, we may want to look at some even more scalable solutions, such as Mobx, Zustand, or XState to meet our needs.

But let’s not forget,

Start Simple

and

Add complexity only as needed.

Most web applications need to store users' data, such as their username, email, or their preferences across multiple requests. In addition, once a user logs into your application, they need to remain logged in until they log out.

However, HTTP is a stateless protocol. In simple words, the server does not retain any information from one request to another. So how and where do we store this user-specific data that we need across multiple requests? The answer is: a session.

Sessions provide a way to store a user's information across multiple requests. Once you store some data in the session, you can access it in all future requests.

# store the username in the session
# when a user logs in
session[:user_id] = user.username

# read the username from the session
# when the user accesses the website again
username = session[:user_id]

Looks simple, right? Well, there's a lot that goes on behind the scenes to make it work. This article will show you how sessions work and how you can work with them.  

What You'll Learn

1. What is a session?
2. How Sessions Work
3. Session Storage
4. Working with Sessions
5. How Rails Implements Sessions
6. Resources to Learn More

Sounds fun? Let's dig in.

What is a Session?

A session can refer to one of two things:

1. A place where you store data during one request that you can access in later requests.
2. A time period between which the user is logged in to your application.

Once a user logs in, the application stores their information in a session (the place), and uses that information in subsequent requests to make sure the user is valid and logged in (the period).

Your application has a session for each user in which you can store small amounts of data that will be persisted between requests.

You can write some data to the session in one request:

class SessionsController < ApplicationController
  def store
    session[:user_id] = user.username
  end
end

and read it inside another request:

class SessionsController < ApplicationController
  def read
    username = session[:user_id]
  end
end

As you can see, Rails makes it extremely easy for you to work with sessions. You can simply treat it like a Ruby Hash.

How do Sessions Work?

At this point, you may be wondering: how do sessions help you maintain the state from one request to another?

The answer lies in a cookie.

When your browser requests a website for the first time, along with the response, the server sends a small piece of data back to the web browser. This data is called a cookie. Upon receiving this cookie, the browser stores this cookie and sends it back to the server for all future requests.

If you're curious to learn more about cookies, I recommend reading the MDN guide: Using HTTP cookies. In a nutshell, the server can set cookies using the Set-Cookie header and read cookies using the Cookie header.

The server sets a different cookie for different browsers, even if they're on the same computer. That's why cookies are typically used to tell if multiple requests came from the same browser. This lets the website remember useful information from previous requests (such as the user's unique identifier), despite HTTP being a stateless protocol.

Example: how you stay logged in on Amazon

Let's say you're logging in to Amazon for the first time. Once you log in, Amazon's back-end server will send a cookie in the response, and this cookie will be sent to the server every time you browse any pages on Amazon.

Upon receiving the cookie, Amazon's server checks if the user corresponding to that cookie is logged in, and displays a personalized web page.  

However, if you browse Amazon from a different device or even a different browser, it won't send the cookie to the server, as it doesn't have that cookie. Cookies are scoped to the browser. Hence you won't be logged in on a different device or browser.

So, how does that relate to the Sessions?

Sessions use cookies behind the scenes. Instead of you having to set and get data from the cookies, Rails handles it for you via sessions. Your Rails application has a session for each user, in which you can store data that will be persisted between multiple requests.

Rails identifies the session by a unique session ID, a 32-character string of random hex numbers. When a new user accesses the application for the first time, Rails generates this session ID and stores it inside the cookie. Once this session ID is sent to the browser, it sends it back to the server for future requests.

Session Storage

When you store some data in the session, Rails can store it in any one of the following four session stores.

1. CookieStore: Store all data inside a cookie, in addition to the session ID
2. CacheStore: Store data inside the Rails cache
3. ActiveRecordStore: Store the data in the database
4. MemCacheStore: Use a Memcached cluster of servers

All these stores can be accessed via a unified API, making it very convenient to switch from one to another.

One important thing to note here is that whichever store you use to store the session data, the actual session identifier always comes from the cookie. I feel this is a point that confuses many beginner Rails developers, and it confused me for a long time.

The server communicates the state with the browser by sending the session ID via a cookie. This cookie is used for all future requests to identify the session for that particular user, and to store additional data in any one of the session stores mentioned above.

For example, you can store that user's preferences inside the cookie (in addition to the session id), in the database, or the cache.

The best practice is to use the cookie only to store a unique ID for each session, and nothing else.

Cookies have a size limit of 4 KB. Since the browser sends cookies on each request, stuffing large data in cookies will bloat the requests. Hence you should only store the session ID in the cookie. Upon receiving the request, your application can use that identifier to fetch additional data from the database, cache, or Memcached.

Working with Sessions

I hope that by now you should have a solid understanding of what sessions are, why we need them, and how they work on a high level. In this section, we will explore how you can work with sessions in Rails on a day-to-day basis.

You can access sessions in only two places: controllers and views. Since a session (and cookies) is a concept related to HTTP, it doesn't make sense to access them inside your models, services, or anywhere else. The controllers are the entry point for all incoming HTTP requests and make the best place to access sessions.

There are two primary ways to work with session data in Rails.

1. Use the session instance method available in the controllers. It returns a Hash-like object, and you can use it just like a regular Hash in Ruby.
2. Use the session method on the request objects, which is useful if you need to access sessions inside your routes file.

Let's take a look at accessing sessions via the session method in the controllers. This is the most common way you'll be accessing sessions in your Rails applications.

class ProjectsController < ApplicationController
  def show
    # read data
    value = session[:key]
    name  = session[:name]
    
    # write data
    session[:key]  = value
    session[:name] = 'Akshay'
  end
end

In addition to the standard hash syntax in Ruby, you can also use the fetch method on the session. This lets you pass a default value while trying to read an item from the session. If the specified key doesn't exist in the session, Rails will return the default value you provided.

class ProjectsController < ApplicationController
  def show
    session["one"] = "1"
    session.fetch(:one) # 1
    
    session.fetch(:two, "2") # 2
    session.fetch(:two, nil) # nil
  end
end

You can also pass a block to the fetch method. This block will be executed and its result will be returned if the specified key doesn't exist. The key is yielded to the block.

class ProjectsController < ApplicationController
  def show
    session.fetch(:three) { |el| el.to_s } # "three"
  end
end

If you don't pass a default value or a block, Rails will raise an error.

class ProjectsController < ApplicationController
  def show
    session.fetch(:three) # raises KeyError
  end
end

Use the dig method if you have nested data in the session.

class ProjectsController < ApplicationController
  def show
    session["one"] = { "two" => "3" }
    session.dig("one", "two")   # 3
    session.dig(:one, "two")    # 3

    session.dig("one", :two)    # nil
  end
end

Update and Delete the Session Data

If you've already stored some data in the session and would like to update it, use the update method, providing the updated value.

class ProjectsController < Application Controller
  def new
    session["action"] = "NEW"
  end
  
  def create
    session.update(action: "CREATE")
  end
end

If you decide you don't need to keep some data in the session anymore, such as a user's ID aftere they log out, use the delete method to remove it.

class ProjectsController < Application Controller
  def new
    session.delete("action")
  end
end

Accessing Sessions Inside Routes

Sometimes, you may need to access sessions inside your routes.rb file. For this, you can call the session method on the request object available inside the route constraints.

get 'sessions', to: 'projects#sessions', constraints: ->(req) {
  req.session[:name] = 'akshay'
  true 
}, as: 'sessions'

Alternatively, you can create an instance of the ActionDispatch::Request using the env object yielded to the Rack application.

get 'sessions', to: -> (env) { 
  req = ActionDispatch::Request.new(env)
  req.session[:name] = 'Akshay'
  [200, {}, ["Success!"]] 
}

To learn more about router constraints and using a rack app inside the routes, check out this article that goes deep into routing in Rails.

Understanding the Rails Router: Why, What, and How

The router is the entry point of your Rails application. It acts as the gatekeeper for all incoming HTTP requests, inspecting and sending them to a controller action; even filtering and rejecting them if necessary. In this article, we’ll do a deep dive into the Rails Router to understand it better.

Akshay's BlogAkshay Khot

One final thing to remember: Sessions are lazily loaded. If you don't access sessions at all, they will not be loaded. Hence, you don't have to disable sessions if you aren't using them.

Digging Deeper: How Rails Implements Sessions

So far, you've learned that the session instance method provides access to the session inside the controller. Ever wondered where that method comes from?

Let's open the Rails codebase and take a peek at the ActionController::Metal class, the great-grandfather of all your controllers.

Metal Controller in Rails

The ActionController::Base is the great-grandfather of all Rails controllers, but doesn’t get much attention. In this post, we will examine this Metal class and how it works.

Akshay's BlogAkshay Khot

Here's a simplified version:

module ActionController
  class Metal
    delegate :session, to: "@_request"
  end
end

The delegate method forwards any calls to session to the @_request object, which is an instance of the ActionDispatch::Request class. Let's open it and see if we can find the session method in this class.

We can't!! There's no session method inside the ActionDispatch::Request class.

What's going on? 🤔

Let's see if it includes any modules. Yes, it does:

module ActionDispatch
  class Request
    include Rack::Request::Helpers
  end
end

Let's open the Rack codebase, go to the Rack::Request class, and there is our session method! All it does is check the value of the RACK_SESSION header variable and set it to the value returned by the default_session method.

# https://github.com/rack/rack/blob/main/lib/rack/request.rb

module Rack
  class Request
    module Helpers
      def session
        fetch_header(RACK_SESSION) do |k|
          set_header RACK_SESSION, default_session
        end
      end

      def default_session; {}; end
    end
  end
end

Let's get back to the Rails codebase. The ActionDispatch::Request class overrides the default_session method, providing its own implementation as follows:

module ActionDispatch
  class Request
    def default_session
      Session.disabled(self)
    end
  end
end

The Session.disabled method returns a new instance of the ActionDispatch::Request::Session class. Here's a simplified version of it.

module ActionDispatch
  class Request
    class Session
      def self.disabled(req)
        new(nil, req, enabled: false)
      end
    end
  end
end

And that's where the session object is created. We can go deeper, but I think we have a pretty good foundation so you can explore the Session class on your own, which I highly encourage. In a future article, we'll explore how different session stores are implemented.

Resources

• How Rails Sessions Work: This is the original blog post from Justin Weiss, that made the sessions 'click' for me. While you're there, I recommend reading other articles from Justin.
• Rails Guides on Sessions: Read them for more details on configuring different stores for the sessions, also tangential concepts such as the flash.
• Laravel Sessions: To learn how Laravel uses sessions. Rails and Laravel are very similar, and I always learn new things by reading the Laravel docs.

I hope this post helped you gain a deeper understanding of sessions in Rails. Typically, you'll use sessions to implement authentication for your application. However, you can also use them to store additional data such as user preferences or UI/theme settings for the website.

If you have any questions or feedback, didn't understand something, or found a mistake, please leave a comment below or send me an email. I look forward to hearing from you.

Please subscribe to my blog if you'd like to receive future articles directly in your email. If you're already a subscriber, thank you.

Someone asked me why I named my developer training site “Graceful.Dev“, so I thought I’d write about that.

The theme of “grace” has been an emergent one in my work for years. I think that grace is an essential quality of resilient systems, at any level. Here’s an explanation, adapted from one of my talks:

I don’t have a lot of hobbies left, but one thing I still do regularly is take myself out dancing. When I go dancing, I generally go to goth/industrial clubs and electronic dance music shows.

If you’re not familiar with these kinds of events, they aren’t known for their couples dancing. Everyone kind of does their own thing. So while I’ve been dancing for many years, I’ve never learned to dance with a partner.

Every now and then someone will try to dance with me. It’s never pretty when this happens. One time someone tried to dance with me and about 30 seconds in they stopped and said “dude, are you OK?”

But this one time, someone I had just met invited me to dance with them. And I yelled over the music “I warn you I have no idea what I’m doing”, but they were insistent.

And it was a fiasco. I really had no idea what I was doing. But…

Every time I did something clueless and awkward, every time I botched a twirl, they made space for it, flowed into it, and came around again with a big, kind smile. And by the end… well, I was still awful. But I was smiling too, and starting to pick up on their cues, and they were making us both look good.

You know, the word “grace” is interesting, because it has two different meanings. On the one hand, it means beauty in lines or in motion. But if you were raised with a religious background anything like mine, you know that grace is also something that saves you.

And in that  moment on the dance floor, I realized that these two meanings of grace are really one and the same thing. Because grace is something that makes space for you to screw up, and turns it into something beautiful.

Grace is taking the random stream of events that are thrown at you and creating meaning. Grace is being embodied, mindful and reflective. It’s knowing where you stand in space. Grace is starting where you are. Gracing is working with legacy, instead of trying to start fresh. Grace is falling forwards and missing the ground.

Grace is extreme late-binding of all things. It’s deciding what to do at the last possible moment. Grace is leaning into the people near you, and trusting them to catch you. Or at least give you a hand up.

Grace is living in the present moment, not the future. Grace is laughing at yourself. Grace is forgetting what you’re “solving for” and just knowing what you’re pulling towards.

And when everything has fallen apart, grace is what saves us.

So live gracefully. Build graceful systems. And don’t forget to dance.

Here’s a video of the talk where (I think) I said this stuff for the first time, along with more about what these things mean when building software systems:

The post Why Grace Matters (for Software Development) first appeared on avdi.codes.

Please check back soon.

In the mean time here are links to PRs in this episode:

active_record.destroy_association_async_batch_size configuration

Add Rails.env.local?

Accept composite primary key in id=

RailsConf 2023

RubyKaigi 2022

I’ll post links, snippets and transcripts by 23:00 CET.

Customizing exceptions is usually not a common concern during software development. But if you catch an error in an observability tool and can't correctly and quickly identify the problem, you may need more information and details about an exception.

This article will show you how to customize exceptions in Ruby and mitigate potential future problems due to a lack of error information.

Let's dive straight in!

A Quick Side-Note

This post is a natural progression to Debugging in Ruby with AppSignal, so we recommend reading that first for an overview of debugging and an introduction to custom exceptions.

How to Rescue an Exception with Ruby

Ruby has a class called Exception, from which error-handling classes inherit. In this section, we'll better understand Ruby's structural exception flow before we create our custom exception.

Exception is the main exception class in Ruby, and rescue Exception will catch all exceptions inherited from Exception. It isn't best practice to use this in our app, as it will catch all exceptions used internally by Ruby.

The easiest way to rescue an exception in Ruby is to create a begin ... rescue block of code like the example below:

begin
  call_some_method()
rescue Exception => e
  ...
end

Since Exception will catch all exceptions, we should try to use something more specific to filter and get only the error we want. One example is the StandardError class, a standard rescuer used to catch exceptions related to application code errors by ignoring Ruby's internal exceptions.

To catch a StandardException, you can use the example below:

begin
  call_some_method()
rescue StandardException => e
  ...
end

Or, if no exception class is stated, Ruby will return the exceptions handled by the StandardException class.

begin
  call_some_method()
rescue => e
  ...
end

To create a custom exception with Ruby, you'll probably create a class that inherits from StandardError. We'll cover that in the next few sections.

To learn more about exceptions and find the best one to inherit, check Ruby's exceptions list.

Adding Additional Information to the Ruby Exception

Creating a new exception without sending relevant information will not effectively help in debugging — identifying and fixing — the problem. You need to add the error details. Here, we will see how to pass information from objects to the custom exception.

Let's create a new custom exception just to receive the data we want to log. As mentioned in the previous section, the custom exception needs to inherit from StandardError.

You can use a simple Rails project to test this implementation. Create a new folder called exceptions inside the app folder and a class called custom_exception.rb in your Rails project.

# app/exceptions/custom_exception.rb

class CustomException < StandardError
  def initialize(code, name, msg, details)
    @code = code
    @name = name
    @msg = msg
    @details = details
  end
end

In this exception class, we can define all the information that needs to be shown in the logs and we use four attributes for our data:

• a code to enumerate the exception
• a name
• an informational message
• internal information details about the exception already provided by Ruby

And now we create a begin...rescue block to raise the CustomException and pass the parameters to the exception attributes.

# app/models/employee.rb

class Employee
  def calculate_fees
    begin
      nil.object # Any code that throws an exception.
    rescue => exception
      raise CustomException.new(
        333,
        "My customized exception",
        "A new exception occurred in the application",
        exception)
    end
  end
end

This looks useful, so let's continue the implementation and use this data to customize the exception log.

Extending an Exception in Ruby

Extending an exception allows us to elevate customization to a more specific and reusable level. Just as Ruby has several exceptions for different types of errors, we can also follow this line of programming in our systems.

Next, let's understand how to override our exception and use it in a context that demands an extension.

Finding information in logs is a painful activity. Developers often blame themselves for not including more information about errors or how to search and filter. If you are not using any monitoring tools that provide this, including meaningful data could save you in the foreseeable future.

Pro-tip: Check out the section on 'Debugging Exceptions in Ruby with AppSignal' in our post Debugging in Ruby with AppSignal for information about how to set up and track custom exceptions in AppSignal.

In the example below, we will customize the display of exceptions in the log. Initially, you might think that it's just a light and pretty way to show data. However, the keywords used in the data are key to finding an error and helping whoever will be monitoring the application.

Add the colorize gem to your project by including the code below in your Gemfile.

# Gemfile

gem 'colorize'

Run the bundle to install the colorize gem and launch your Rails application.

$ bundle install
$ rails s

Now, in your exception class, import the gem. Print the attributes in a formatted way, so it's easy to see and quickly find an important error.

# app/exceptions/custom_exception.rb

require 'colorize'

class CustomException < StandardError
  def initialize(code, name, msg, details)
    ...
    log_exception
  end

  def log_exception
    print_separator

    STDERR.puts "🚨🚨🚨 #{self.class} 🚨🚨🚨".colorize(:red)

    self.instance_variables.each do |attr|
      # All attributes will be printed.
      STDERR.puts "#{attr}: #{self.instance_variable_get(attr)}".colorize(:red)
    end

    print_separator
  end

  def print_separator
    85.times { print "-".colorize(color: :black, background: :red) }
    STDERR.puts "\n"
  end

  def to_s
    @name.colorize(:red)
  end
end

Check out the result of this visual customization and test some options to create your format and style.

Wrapping Up and Next Steps

In this post, we covered how to customize and highlight a Ruby exception in your logs. Many other customizations are possible, but what's most important is that you handle the exceptions relevant to your application. And remember, don't apply the same formatting style to all exceptions, as Rails already does.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

When Ruby Central was founded in 2001 it was a small operation focused solely on organizing RubyConf, now the world's largest and longest-running gathering of Rubyists, which launched the same year. Twenty-two years later, Ruby Central is in an era of expansion! New board member roles were recently announced and as we move toward some exciting new goals and plans this year, we thought it would be a good time to share a look at the role of the Ruby Central board, how it’s changed and where we’re headed.

A look back

The growth of Ruby Central has been steady and intentional. The board is made up entirely of volunteers, who are passionate Ruby community members. Over the last two decades team members have stepped in and out to support Ruby Central’s mission, and support one another (and prevent burnout!). As Ruby Central grows and changes its mission has been able to grow and change with it.  

2001 - 2011:  Founders David Alan Black and Chad Fowler, both organizers of the inaugural RubyConf in 2001 in Tampa, and Rich Kilmer, make the decision to establish Ruby Central as a nonprofit organization. They serve as its only board members until 2011.

2012: Ruby Central takes over show running of RailsConf. Previous to this, the conference was co-produced with O’Reilly Media.

Ruby Central brings on first staff member, Abby Phoenix who joins as its sole employee, to run both RubyConf and RailsConf. Prior to this, the board members ran all aspects of the conferences.

Ben Scofield who had been helping organize RailsConf, joins as a board member along with Evan Phoenix, who had been helping run rubygems.org, as Chad Fowler and Rich Kilmer step down from their board roles, and David Black steps back into an advisory role.

Ruby Central board grows to three members: Ben and Evan realize they need a third active board member and reach out to Marty Haught, who had been hosting a Rocky Mountain RubyConf event, and he agrees to join.

2014: Ben steps down from board and Sarah Mei joins to replace him.

2019: The Board decides to expand to six members, with an eye toward a more sustainable team and a greater capacity and potential for growth for Ruby Central as the organization seeks to do more for the Ruby community.

Barrett Clark, Allison McMillan, Fable Tales, and Max Tiu join Marty and Evan to round out the board. Sarah steps down.

2020: Ruby Central merges with Ruby Together, bringing support of the vital Ruby infrastructure development under its umbrella.

Former Ruby Together board members Adarsh Pandit, Valerie Woolard and Jonan Scheffler, join. Barrett steps down.

2020 - 2022:  

Max steps down. Chelsea Kaufman joins in October of 2022.

Ruby Central reimagines its role in the community. The pandemic makes it clear that conferences aren’t the only way to serve the Ruby community. The board sets new goals: On top of the conferences, what more can we do to support the growth of the community — not just in the US but all over the world — and the programming language?

How the current board runs

Here’s what your 2023 Ruby Central board have to say about how they run things:

The board of directors for Ruby Central are representatives from the community and are here to help make sure everything runs smoothly. We meet once a month and we all take turns working as co-chairs of the conferences.  

Here are some of the other key things we do:

We decide what the organization is all about: We set the mission and goals, and make sure everything the organization does lines up with those. We make sure the mission aligns with what the community needs.

We hire and keep an eye on the boss: We hire and evaluate the executive director, who runs things day-to-day.

We keep the organization's finances in good shape: We make sure there's enough money, set the budget, and make sure everyone is following the rules.

We follow the law and do what's right: we make sure the organization is doing things legally and ethically.

We bring in the cash: We find ways to raise money, like getting donations, applying for grants, and partnering with other groups.

We keep the board strong: We make sure it's made up of the right people, train them, and set rules for how it should run.

Basically, we are a group of people who make sure Ruby Central is doing what it's supposed to do, and doing it in a responsible way.

“The organization is here for the community,” said board president Chelsea Kaufman on a panel at RubyConf 2022. The board emphasized how important it is to them to receive feedback and collaborate with Rubyists as Ruby Central grows. “Tell us your thoughts. Your voices really matter to us,” she added.

This is a very exciting time for us at Ruby Central. If you have questions or ideas for the Ruby Central board as we expand in new directions, please don’t hesitate to reach out to us at contact@rubycentral.org.

Since 2017 we have been focusing on upgrading Ruby on Rails applications. It’s been quite a fulfilling learning process as we continuously improve our workflow best practices, and internal tooling.

In this article I will go into detail to explain how we determine the best approach to create the roadmap for a successful upgrade project.

Two Paths

Depending on the size of the application, our client, their workflow, their architecture, their practices, and the number of dependencies, we usually take one of two approaches with our client engagements:

1. The Roadmap
2. The Initial Engagement

1. The Roadmap

For medium to small applications we usually recommend The Roadmap to quickly understand the steps you need to take to upgrade your Ruby/Rails application.

The Roadmap usually takes two weeks of our time and answers a few key questions:

• What is the code coverage percentage for your application? How extensive is your test suite?

• What are the most complicated files in your codebase? What are the most complicated files which are not thoroughly tested?

• What are some of the known security vulnerabilities that are present in your codebase?

• How long is it going to take to upgrade your application to the next minor version of Ruby and/or Rails? How much effort and time are we talking about?

During these two weeks, our team performs analytical work, estimation steps, and static code analysis on your codebase.

We use our knowledge base and experience to identify what steps are needed to get you to the next minor version of Ruby/Rails. We always recommend you upgrade one minor version at a time. An action step in our roadmap usually looks like this:

Then we go through a blind estimation process that involves at least two software engineers assessing the complexity of every action step.

Each action step gets estimated with a worst/best case scenario mindset. For example: If everything goes well, it is a 1-point story. If we have to go down the rabbit hole, it is a 5-points story.

For this phase of the process we use our open source tool: Points.

This is what the blind estimation interface looks like:

Finally we translate complexity into effort/time. In order to do that, we use our historical database of time/effort spent in past Ruby/Rails upgrade projects.

In the final report, you will see: For every version jump, two estimates in terms of weeks. For example:

If our team were to work on this minor version jump, we would take between 3 and 5 weeks working with two senior software engineers.

We don’t invest any time doing exploratory work nor kickstarting the Rails upgrade branch.

1.1. Roadmap Deliverables

At the end of the two weeks you get these deliverables:

• A PDF Report with the following sections:
  • Known Vulnerabilities
  • Major Issues
    • Code Complexity
    • Test Suite
  • Action Plan
  • Estimates per Version Jump
• A One-Hour Presentation with this format:
  • We explain the main challenges of the upgrade project
  • We explain our methodology in detail
  • We answer any questions your team may have

This is what the code complexity vs. code coverage section looks like in the report:

This is what the vulnerabilities section looks like in a roadmap:

2. The Initial Engagement

For medium to large applications we usually recommend a 5-week initial engagement to:

1. Quickly understand the steps you need to take to upgrade your Ruby/Rails application

2. Kickstart your upgrade branch with some backwards-compatible changes

Compared to The Roadmap, an initial engagement provides more value in the form of backward-compatible changes, an upgrade branch that includes significant progress towards completing the upgrade, and an action plan with better insights and more accurate estimates.

At the same time, an initial engagement is more costly than a roadmap, because we are investing 5 weeks of development/exploration time (instead of 2 weeks) and actively shipping action steps (changes to production!) which are present in the roadmap.

In these 5 weeks we will:

• Set up your application locally. We will communicate with your team to try to determine whether your onboarding steps are accurate or not. For example, we often find that application setup steps in the README are out of date or incomplete.

• Kickstart the Ruby/Rails upgrade branch. We will set up dual-booting in that branch and we will start by running bundle install and next bundle install – thanks to next_rails!

• Get your application to boot with the next version of Ruby/Rails (think successfully running next bin/rails runner 'puts 1 + 1' in the console)

• Get the application branch to run the test suite with the next version of Ruby/Rails (for example next bin/rspec spec)

• After getting a complete output from your test suite (running with the next version of Ruby or Rails) we will record a number of failures to be included in the roadmap. If the root cause is not straightforward, we will dig deeper to determine the root cause.

• Ship small pull requests (with backward-compatible changes) to the main branch. You will get a series of tiny PRs that will be easy to review, test, and ship to production.

• Present the roadmap at the end of the first 3 weeks and answer any questions you may have

2.1. Initial Engagement Deliverables

At the end of the 5-week engagement you get these deliverables:

• A PDF Report with the following sections:
  • Known Vulnerabilities
  • Technical Debt Issues
    • Code Complexity
    • Test Suite
  • Action Plan
  • Estimates per Version Jump
• A One-Hour Presentation with this format:
  • We explain the main challenges of the upgrade project
  • We explain our methodology in detail
  • We answer any questions your team may have
• Code Changes
  • An upgrade branch that can run next bundle install
  • An upgrade branch that can run next rake test
  • Several, meaningful backwards-compatible pull requests shipped to production
  • Several, peer-reviewed fixes in the upgrade branch

Which approach is the best for your Ruby or Rails application?

As usual, the answer is: It depends! We need to assess the size of your application, development workflow, application’s architecture, best practices, and the number of dependencies.

We usually work with clients who have large monoliths that have been around for more than 5 years. More likely, our clients have applications that have been up and running in production for more than 10 years!

As a quick rule of thumb, if your application is beyond these parameters we will usually recommend an initial engagement:

• More than 150 models
• More than 300 total gems

If your applications is under these parameters we will recommend a roadmap:

• Fewer than 150 models
• Fewer than 300 total gems

This is a quick rule of thumb, sometimes we will consider these parameters but we will still recommend an initial engagement based on the state of your test suite, your development workflow, your application’s architecture, or your best practices.

For example, our open source Rails application “Points” would be a good candidate for a roadmap.

If we use bundle-stats, we can see the number of total gems is 147 gems:

✗ bundle-stats
+--------------------------------|------------|----------------+
|                           Name | Total Deps | 1st Level Deps |
+--------------------------------|------------|----------------+
|                          rails | 46         | 13             |
|                     sass-rails | 31         | 5              |
|                    rspec-rails | 28         | 7              |
|                         devise | 27         | 5              |
|                    web-console | 25         | 4              |
|                   dotenv-rails | 24         | 2              |
|              factory_bot_rails | 24         | 2              |
|                   jquery-rails | 23         | 3              |
|                jquery-ui-rails | 23         | 1              |
| omniauth-rails_csrf_protection | 21         | 2              |
|       rails-controller-testing | 18         | 3              |
|                       jbuilder | 15         | 2              |
|                     apparition | 14         | 2              |
|            capybara-screenshot | 13         | 2              |
|                omniauth-github | 12         | 2              |
|                     standardrb | 12         | 1              |
|                       capybara | 11         | 8              |
|               database_cleaner | 9          | 1              |
|                   acts_as_list | 7          | 1              |
|                     webdrivers | 7          | 3              |
|                         pundit | 5          | 1              |
|               shoulda-matchers | 5          | 1              |
|                 bootstrap-sass | 4          | 2              |
|                      mimemagic | 4          | 2              |
|                         listen | 3          | 2              |
|                      simplecov | 3          | 3              |
|                  coffee-script | 2          | 2              |
|                          faker | 2          | 1              |
|                        bourbon | 1          | 1              |
|                     next_rails | 1          | 1              |
|                           puma | 1          | 1              |
|             rack-mini-profiler | 1          | 1              |
|                     turbolinks | 1          | 1              |
|                       uglifier | 1          | 1              |
|                         byebug | 0          | 0              |
|                         matrix | 0          | 0              |
|                   newrelic_rpm | 0          | 0              |
|                             pg | 0          | 0              |
|          recursive-open-struct | 0          | 0              |
|                      redcarpet | 0          | 0              |
|                         spring | 0          | 0              |
+--------------------------------|------------|----------------+

      Declared Gems   41
         Total Gems   147
  Unpinned Versions   25
        Github Refs   0

And using the rails_stats gem we can see that the number of models is 6:

rake stats\[points/\]

Directory: /Users/etagwerker/Projects/fastruby/points

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Mailers              |     4 |     4 |       1 |       0 |   0 |     0 |
| Models               |   229 |   173 |       6 |      29 |   4 |     3 |
| Policies             |    67 |    50 |       3 |      12 |   4 |     2 |
| Jobs                 |     2 |     2 |       1 |       0 |   0 |     0 |
| Controllers          |   502 |   419 |      10 |      62 |   6 |     4 |
| Helpers              |    98 |    82 |       0 |      12 |   0 |     4 |
| Channels             |     8 |     8 |       2 |       0 |   0 |     0 |
| Javascripts          |   274 |   210 |       0 |      16 |   0 |    11 |
| Configuration        |   678 |   150 |       1 |       0 |   0 |     0 |
| Spec Support         |   328 |   165 |       0 |       6 |   0 |    25 |
| Feature Tests        |  1253 |   963 |       0 |       1 |   0 |   961 |
| Model Tests          |   296 |   242 |       0 |       1 |   0 |   240 |
| Policy Tests         |    37 |    29 |       0 |       0 |   0 |     0 |
| Controller Tests     |   662 |   528 |       0 |       0 |   0 |     0 |
| Helper Tests         |    10 |     9 |       0 |       0 |   0 |     0 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                |  4448 |  3034 |      24 |     139 |   5 |    19 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 1098     Test LOC: 1936     Code to Test Ratio: 1:1.8

If you want to know more about how we measure the size of a Rails application, we wrote an article about that: How We Estimate The Size of a Ruby Application

Conclusion

I hope that you found this article interesting and that you now know more about how we approach “Big Rails” upgrade projects. If you are interested in getting an action plan to upgrade your Ruby or Rails application, send us a message through our contact form! 🚀

We have released the uri gem version 0.10.0.1, 0.10.2, 0.11.1 and 0.12.1 that has a security fix for a ReDoS vulnerability. This vulnerability has been assigned the CVE identifier CVE-2023-28755.

Details

A ReDoS issue was discovered in the URI component. The URI parser mishandles invalid URLs that have specific characters. It causes an increase in execution time for parsing strings to URI objects.

The uri gem version 0.10.1, 0.10.2, 0.11.0, 0.12.0, and all versions 0.10.0 and prior are vulnerable for this vulnerability.

Recommended action

We recommend to update the uri gem to 0.12.1. In order to ensure compatibility with bundled version in older Ruby series, you may update as follows instead:

• For Ruby 2.7: Update to uri 0.10.0.1
• For Ruby 3.0: Update to uri 0.10.2
• For Ruby 3.1: Update to uri 0.11.1
• For Ruby 3.2: Update to uri 0.12.1

You can use gem update uri to update it. If you are using bundler, please add gem "uri", ">= 0.12.1" (or other version mentioned above) to your Gemfile.

Affected versions

• uri gem 0.12.0
• uri gem 0.11.0
• uri gem 0.10.0 or 0.10.1

Credits

Thanks to Dominic Couture for discovering this issue.

History

• Originally published at 2023-03-28 01:00:00 (UTC)

Posted by hsbt on 28 Mar 2023

A namespace is a way to group related functionality together in a modular way. Rails 7 has improved the support for the custom namespace, now there is a better way of adding the custom namespace to application components while autoloading.

Rails by default autoloads all the subdirectories in the app folder except assets, views, and javascript.

Even if there is a custom directory inside the app, for example, app/services, we don’t need to configure anything to autoload it, Rails does it automatically.

In a Rails application, file names have to match the constants they define, with directories acting as namespaces. For example, the file app/services/users/signup.rb has to define the constant like Users::Signup.

But what if we would like all our services in app/services under Services namespace, it means that we would want to define a constant like Services::Users::Signup.

One way to accomplish this is to create subdirectory like app/services/services and then we can put all our services under the services namespace.

But this doesn’t feel right, there should be a way to define file app/services/users/signup.rb constant like Services::Users::Signup

Before

Now there are two modes of autoloading files in Rails, one is the classic mode and the other is zeitwerk mode.

Classic

In classic mode we can define constant in both ways for a file app/services/users/signup.rb. It means that Services::Users::Signup and Users::Signup are valid constant names. But it creates ambiguity.

Zeitwerk

In zeitwerk mode we can only define Users::Signup but there is a workaround. Zeitwerk supports custom root namespaces and we can customize main autoloader.

# config/initializers/autoloading.rb

module Services; end

Rails.autoloaders.main.push_dir("#{Rails.root}/app/services", Services)

ActiveSupport::Dependencies.autoload_paths("#{Rails.root}/app/services")

In the above code, we created a Services namespace, we can create it like this or we can create it elsewhere and then require it here.

Next, we used the main autoloader to do the task. The push_dir method takes a module or class object as the second argument.

Applications running on Rails < 7.1 have to additionally delete the directory app/services from ActiveSupport::Dependencies.autoload_paths.

After

Now after this patch, we can add the custom namespace Services without creating a subdirectory like app/services/services.

We just have to customize the main autoloader like below and that is it.

# config/initializers/autoloading.rb

module Services; end

Rails.autoloaders.main.push_dir("#{Rails.root}/app/services", Services)

There is no need to delete app/services from ActiveSupport::Dependencies.autoload_paths. For more information about this patch, please go through this PR.

I continued to ask the question that Pragmatic Programmers asked last week:

Here are the answers I received:

It would be best if you also read the replies to Pragmatic Programmer’s question.

Update

The images are now clickable. I also wrote a longer post about an update I plan to do to the newsletter probably in April.

You can jump directly to a section:

👐 Our Community

👉 All about Code and Ruby

🧰 Gems, Libraries, and Updates

🤝 Related (but not Ruby-specific)

More content: 🎥 🎧 🗞 (articles, podcasts, videos, and newsletters)

🤗 Founding Members supporting this newsletter

✋ I am part of the organizing team for Friendly.rb conference:

There are early-bird tickets available and the call for speakers is still open in case you are considering submitting a talk proposal.

👐 Our Community

Ruby 2.7 might be EOL at the end of March 2023:

👐 Postmodern shared a possible explanation about why it seems that few people are learning Ruby:

👉Lucian Ghinda asked about the most significant advantage of using Rails today:

Here are five of the answers, but I collected them all here:

👐 Calvin Walzel announced that ruby-companies.org reached 20 companies:

👐 Andy Croll shared an open invitation to join as a mentor at firstrubyfriend.org

👐 Jason Swett announced that Code with Jason Meetup will have from April some Europe-friendly time slots. Register here

👐 Kevin Newton started a discussion about the sustainability of open-source projects:

👐 Joe Masilotti announced that RailsDevs Github Repo now has over 100 contributors:

🤞 Enjoy the free subscription to Short Ruby Newsletter! Subscribe to receive it weekly in your inbox:

Subscribe now

By becoming a paid subscriber, you can support this Ruby community for just $1.5/week ($6.5/month). Your contribution aids growth and maintains the quality of ShortRuby for everybody:

Support the newsletter for ~1.5$/week

If you consider upgrading and want more information, please read Why to subscribe to paid

👉 All about Code and Ruby

👉Will Cosgrove shared a code sample showing a helper for stimulus data attributes:

👉Nate Berkopec shared a performance tip about the recommended number of threads with Puma on MRI:

Volodymyr.Mykhailyk asked about the reason why this recommendation and Nate Matykiewicz explained

👉Joel Drapper shared a piece of code showing how Phlex can asynchronously render content:

👉Shiva shared a code sample showing how Policy Object Pattern can handle permissions, roles and policies:

👉David shared a code sample showing an active link helper:

👉Matt Swanson shared a code sample about how to use ActiveSupport::MessageVerifier:

👉Brad Gessler shared a code sample showing how to use Phlex inside a controller:

Brad also shared a code sample showing Phlex views with the same name as controller actions:

👉Josef Strzibny shared a tip about how to check generators from gems:

👉Janko Marohnić shared a comparison between Sequel and ActiveRecord:

👉Rishi Pithadiya shared a short Rails tip that reduces database calls:

👉 Shiva Kumar shared a thread about the Query Object Pattern:

👉Greg Navis shared a code sample showing how to implement final classes using in Ruby:

👉Eric Berry shared a command that helps showing the list of all gems in a Rails app:

👉Greg Navis shared a code sample showing how to implement lazy accessors:

👉Kirill Shevchenko shared a thread about the State Pattern:

And you can see here the implementation of parent class:

If you like this content and want to receive it every week by email

Subscribe now

🧰 Gems, Libraries, and Updates

🧰 Schwad announced the scarpe-team/scarpe: Scarpe - shoes but running on webview:

This is what Shoes were:

And this is what Scarpe is:

🧰 Kevin Newton announced that yarp: Yet Another Ruby Parser is 100% compliant on all test targets:

🧰 Petrik De Heus opened a PR to Include READMEs in main framework pages of the API documentation

🧰 Steve Polito announced they released a new gem called invisible_ink: Keep your private notes in plain sight

🧰 Janko Marohnić shared a gem called tus-server - a Ruby server for the tus resumable upload protocol.

🧰 Vinicius Stock shared a new release v0.4.2 of ruby-lsp

Vinicius also announced the release of v.0.2.2 of the VScode Ruby LSP extension. Read the release notes

🧰 Avo announced an update to their roadmap for Avo 3 → Avo Admin for Rails

🧰 Greg Molnar shared a PR that Adds documentation for Arel::Nodes::Node

🧰 Dima Fatko announced a new PR about Performance and memory optimizations ruby/rexml:

🧰 Kevin Newton shared a PR about Implement `_dump` and `_load` on ActiveRecord::Base:

🧰 Jeremy Evans announced a new release v 2.29.0 of Rodauth 2.29.0 Released

🧰 Mike Coutermarsh created a new PR in Rails project about Fix Rails generated index name being too long (this might be part of Rails 7.1 - but is not yet merged)

🧰 Ben Pickles announced a new gem parklife and also published an article about Introducing Parklife

🤝 Related (but not Ruby-specific)

🤝 Gabriel Arcangel Zayas shared a quote about legacy code

🤝Samuel Motal shared how learning changes as we gain more knowledge:

🤝Tobias Petry.Sql shared a SQL sample showing how to Delete Duplicate Rows - Database Tip

🤝Jason Swett shared tips about how to facilitate writing tests:

🤝 Nate Berkopec shared a brute force-like way to make SQL performance improvements that he calls SQL Shotgun method:

🤝Victoria Melnikova shared a thread about lessons learned while building communities:

Here are some of the points shared, but you should read the thread as it has concrete examples:

• “Start building your community as early as possible, but ONLY when you're ready to show up consistently”

• “Empower your community by giving them a voice in decision-making”

• “Break down barriers to participation by recognizing and rewarding novice and experienced contributors alike”

• “Create incentives for engineers to stick around and encourage senior members to educate less experienced ones”

• “Toxic community cannot unlearn being toxic”

• “A good community leader is honest, transparent, communicates with integrity, and is a good diplomat”

• “Running a community is hard”

• “Learn to leverage your community for major releases”

• “Cultivate a welcoming community”

• “Software engineers are tough customers”

🤝 Robby Russell shared a thread with multiple articles about interns experiences:

Here is the list of articles shared:

• Starting Over - A Career-Switcher’s Guide to Being an Intern

• Just the Beginning: How My Internship is Launching My New Tech Career

• Interning at Planet Argon: Expectations Vs. Reality

• Starting Over - A Career-Switcher’s Guide to Being an Intern

• Things I Learned as an Intern that I Did Not Learn in Code Bootcamp

• Now What? Thoughts from a Planet Argon Intern

• My Internship Experience: Learning Through Research and Reproducing Issues

• Rookie Mistakes (And What I Learned From Them)

• 5 Lessons I Learned from my Ruby on Rails Internship at Planet Argon

• From Student to Intern: My First Week at Planet Argon

• So...How Was Your First Week at Your Internship?

🤝Nate Berkopec shared a thread about reasons to work on performance on web applications:

If you like this content and want to receive it every week by email:

Subscribe now

More content: 🎥 🎧 🗞

Courses

👀 Graceful.Dev announced that their course Flawless Ruby is now free:

👀 Aaron Francis announced their free course MySQL for Developers — PlanetScale

👀 Eric Berry shared their intention to create a course about RubyMine. If you are interested reply to Eric. I think this is indeed needed:

👀 Avdi Grimm announced they are opening their Coaching & Counsel with Avdi

👀 Andrea Rocca announced a pre-order of their book about Learn Hotwire

🗞 Newsletters

🗞 Greg Molnar announced a new edition of This Week in Rails written by Wojciech Wnętrzak → Composite primary keys improvements and more

🗞️ Ruby Weekly published a new edition: ChatGPT makes a contribution to Rails

🗞 Ruby Radar published a new edition Ruby Radar #95 - Scarpe Diem!

🗞️ Ruby LibHunt published a new edition of the Awesome Ruby Newsletter

Podcasts

🎧 Tightly Coupled Book Club published their intro episode S01 - 0.5 The Prequel

🎧Rooftop Ruby published a new episode about 5: Vanilla Never Tasted So Hot — Rooftop Ruby

🎧 Indie Rails published a new episode Getting Started As An Indie Rails Dev, Diversifying Income & Outsourcing

🎧 The Ruby On Rails Podcast published a new episode about Episode 462: Scarpe Diem: Seize the Shoes (Brittany + Nick)

🎧 Ruby For All published a new episode about Career and ADHD Management with Celso De Sá

Videos

Talks

📽️ Jason Swett published a new episode of Code With Jason Meetup about Code review (2023-03-23)

📽️Adrian Marin shared a video hosted by EvilMartians about Dev Propulsion Labs — Ep. 1 Building communities around dev tools products

📽️ Eric Berry shared a conference talk Roda: Simplicity, Reliability, Extensibility, Performance by Jeremy Evans (2022)

Screencasts

🎥 Justin Searls published a new video about Searls After Dark #5 - Tailwind on Rails

🎥 Drifting Ruby published two episodes:

• Episode 393 - Chart.js

• This Week in Rails - March 24th, 2023

🎥 Adrian Marin published a video showing how they Add Avo admin on RubyAndRails.info

🎥 Deanin published new videos:

• Drag and Drop Speedrun with Stimulus Components | Ruby on Rails 7

• Bing's ChatGPT with Ruby on Rails is Here!

🎥 Matt Swanson published a video talking about single file principle - Building a feature in one single file

🎥Yaroslav Shmarov published two new episodes:

• #120 Active Record Encryption usage and troubleshooting

• #119 Trello Clone. Advanced Drag and Drop Sortable Lists with Hotwire

Articles

What’s new

• Ben Sheldon published an article explaining How GoodJob's mountable Rails Engine delivers Javascript importmaps and frontend assets

• Rishi Pithadiya shared an article about Eight Graphs that Explain Software Engineering Salaries in 2023 → “The numbers from job search firms Dice and Hired have been released. These 2022 numbers have been eagerly anticipated, given the turmoil generated by a spate of tech layoffs in the latter part of the year, which Dice estimates at more than 140,000”

• Paweł Swiątkowski published a new article about Modeling business logic with ECS in Ruby → “This blog post explores the possibility of using Entity Component System architecture to model business logic in a “regular business application”

• Joshua published an article about Rails deployment pipeline with Planetscale & Heroku

• I asked last week a question about What is the best article what you ever read about Ruby? - if you still want to contribute please add it there in comments.

How-Tos

• Kevin Murphy published a new article in their series about Anyone can play guitar called Programming Guitar Greatness → “Stevie Ray Vaughan is one of my favorite guitarists. Unfortunately, I can’t play anything like he can. To make up for it, let’s teach a computer to play guitar like him and see what we can learn.”

• Lucas Barret published a new article about Reversing DidYouMean Gem

• Any Cable published a new article showing AnyCable off Rails: connecting Twilio streams with Hanami

• Josef Strzibny published a new article about How to send emails in Rails with Postmark

• Paweł Dąbrowski published a new article How to not get into trouble with Active Record → “Improve the performance, produce fewer bugs, and make the code responsible for database communication readable and testable by selecting the right Active Record features for the given scenario”

• Harsh Patel published a new article about Basic Understanding of Webhooks with examples

• Steve Polito published an article showing How to encrypt files with Ruby and Active Support

• John Nunemaker published a new article about How to benchmark your ruby gem

• Aestimo Kirina published a new article on AppSignal’s blog about Authorization Gems in Ruby: Pundit and CanCanCan

• Phil Reynolds published a new article about Search and Select Multiple with Rails and Hotwire → “This post walks though a user selector for adding users to a chat. The key feature here is searching one model with the pg_search gem and then selecting objects from that search to add them to another model”

• Jason York published an article about Using ViewComponents with Turbo

Deep Dives

• Ollie Haydon-Mulligan published an article about Debugging Lock Wait Timeouts (in Ruby on Rails) → “I recently learned — through an investigation that rumbled on for a while — that it’s not always straightforward to work out what’s causing Lock Wait Timeouts. So here, I’m going to share how that investigation unfolded, focusing on the techniques that helped.”

• Akshay published a two new articles about Progressive Application Development with Hotwire and Understanding the Attribute Assignment API in Rails

Related

• Jeremy Smith shared an article about Numbers To Know For Managing (Software Teams) → “Learning how to manage is a long race - it takes many years and each lap offers new learnings. Along the way, anchors emerge that can help orient a manager when a number of other variables are in flux”

🤗 Founding Members supporting ShortRuby

• Drew Bragg, host of Code and the Coding Coders who Code it

• Avi Flombaum, the founder of Flatiron School, is a product engineer interested in full-time/contract work.

• Adrian Marin, creator of Avo - a Ruby on Rails application building framework

• Adam McCrea, creator of Judoscale (formerly Rails Autoscale)—the dead-simple autoscaler for Rails, Sidekiq, etc.

• Stephen Ierodiaconou from www.diaconou.com

• Harry Lascelles

• Jason Charnes from Remote Ruby

• Andy Croll from One Ruby Thing and FirstRubyFriend

• Kyle Keesling

Read more about what is a Founding Member or about Why pay for ShortRuby newsletter

Hello,

I am always thinking about how to make the newsletter to be easily read by everyone.

Thus there are two updates that I want to make:

Clickable images

Make images clickable.

This is already implemented in this week's edition (Edition 35). I think it helps to click on the image if you want to read the thread or to go directly to a repository mentioned in the image.

Splitting the newsletter in two sections

What

Because Substack has the option of sections, I am planning to split the newsletter in two:

• Short Ruby News - The code edition - this will contain what now is grouped under “👐 Our Community”, “👉 All about Code and Ruby”, “🧰 Gems, Libraries, and Updates”, “🤝 Related (but not Ruby-specific)”

and

• Short Ruby News - The content edition - this will contain what now is grouped under “More content: 🎥 🎧 🗞 (articles, podcasts, videos, and newsletters)”

This will mean you will receive on Monday two emails:

1. One with the title “Short Ruby News - The code edition #35”

2. One with the title “Short Ruby News - The content edition #35”

Why?

1. The newsletter is very long, and it becomes hard for me to give proper attention to all categories I include. I feel it gives you - the reader - more control over what and when you read something.

2. I also feel that there are a lot of good articles written, and putting them at the end of a very long article is somehow taking a bit of their light or inspiration. Moving them into their section/email, I can maybe put them more into the spotlight or summarise some of them so you can pick what to read.

When?

This will probably happen in April - maybe the first or second week of April. I want to take time to communicate more about this so that you will know that you will receive two emails on Monday.

Of course, this will be an experiment.

I kept thinking about it and postponed it for weeks. But I think now it is a good time to try it.

I would love to hear your opinion in the comments here, and let me know how it works for you.

Introduction

Let's dive into ruby! There is a really useful gem that we do not notice but is kind of the savior for us developers.

There is no suspense by the title it is obvious I talk about the DidYouMean gem which is now shipped into ruby directly.

So I wanted to dig into this Gem since sometimes it can feel a little bit magic. But any enough advanced technologies can feel like magic right?

Which Spell?

So first I was like how can ruby suggests to me some methods or attribute that I maybe mistypes else? I was like did he just guess it, is there a complex AI behind this?

No not at all just good ol' ruby code. But at least how can he guess which methods are in my object or things like that? Classes and object can be introspected you can get a look inside them and see what are inside them at any time.

For example, if you want to know the methods in the Object class you can do this in IRB :

irb(main):001:0> Object.methods

It will give all the methods that the Object class has. In the same way, if you have an object you call methods on it you will have the methods of your object.

Okay, cool now what, how can ruby guess the right methods if I made a typo or even just write methods instead of methods for example?

Black Magic aka Maths

Promise it won't be long and I will not dig into the algorithm it is not the purpose of this article. But I need to talk about it. In mathematics, we have some function which are called distances. They do what they look to do. They compute distances between "objects".

To compute the distance between 2 "objects" here 2 strings for our DidYouMean Gem there are 2 distances that are used :

• JaroWinkler' distance
• Levenstein' distance

There are several ways to implement these algorithms but again I will dig into that. Here is the code of the SpellChecker of the DidYouMean gem, I will highlight the most important part and try to decompose it.

require_relative "levenshtein"
require_relative "jaro_winkler"

module DidYouMean
  class SpellChecker
    def initialize(dictionary:)
      @dictionary = dictionary
    end

    def correct(input)
      threshold = input.length > 3 ? 0.834 : 0.77

      words = @dictionary.select { |word| JaroWinkler.distance(word, input) >= threshold }
      words.reject! { |word| input.to_s == word.to_s }
      words.sort_by! { |word| JaroWinkler.distance(word.to_s, normalized_input) }
      words.reverse!

      # Correct mistypes
      threshold   = (input.length * 0.25).ceil
      corrections = words.select { |c| Levenshtein.distance(normalize(c), normalized_input) <= threshold }

      # Correct misspells
      if corrections.empty?
        corrections = words.select do |word|
          length = input.length < word.length ? normalized_input.length : word.length

          Levenshtein.distance(word, normalized_input) < length
        end.first(1)
      end

      corrections
    end

  end
end

Dictionary

First, we have this part :

def initialize(dictionary:)
      @dictionary = dictionary
end

We define a dictionary for our spellchecker it is the list of strings that it will search against to 'guess' a correction.

Here the first part of our article take a lot of sense for example, our dictionary could be the list of methods of our object, we have with a.methods .

Filtering words from the dictionary

Then we have the correct methods that I am going to dive into.
We have this first part for the correct methods :

threshold = input.length > 3 ? 0.834 : 0.77

words = @dictionary.select { |word| JaroWinkler.distance(word, input) >= threshold }
words.reject! { |word| input.to_s == word.to_s }
words.sort_by! { |word| JaroWinkler.distance(word.to_s, normalized_input) }
words.reverse!

We have defined a threshold that depends on the length of the input we want to correct. I will come back to these thresholds a bit later and explain why they are here.

Then we have the filtering of the potential corrections of our word. We do that by computing the JaroWinkler distance of the input in the word in the dictionary.

So now why do we need these thresholds? When we compute the distance it will give us a score of 'proximity' of the compared strings. But from what I have seen in this commit with an input of size less than 3 the JaroWinkler distance does behave badly.

Picking the right correction

Once we have found the closest word that could be a good recommendation we have to suggest the best one.
It is the role of this part :

threshold   = (input.length * 0.25).ceil
corrections = words.select { |c| Levenshtein.distance(normalize(c), normalized_input) <= threshold }

We use a different threshold since the Levenstein distance is not normalized. And then we put pick the right one with the Levenstein distance.

Maybe you would be like me and ask yourself why we need both distances.

An assumption could be that JaroWinkler is fastest than Leveinstein but less precise. So we wanted to use JaroWinkler to pre-filter the nearest words and then between these words take the best suggestions.

Of course, it is only an assumption and if you have the answer or a better assumption please do not hesitate to share it with us.

Last Chance

For this part, it is only my assumption too but I think it is not much of a guess. The previous computation can eventually give us nothing because the threshold for the Levenstein distance was too small and nothing is as close as the threshold needs.

So we try again with this piece of code :

if corrections.empty?
  corrections = words.select do |word|
    length = input.length < word.length ? 
    normalized_input.length : word.length
    Levenshtein.distance(word, normalized_input) < length
        end.first(1)
end

We have defined a new threshold so we are able to find a suggestion at the end of the day.

Conclusion

This was the first article of I hope a cool series about a deep dive into the Ruby Language.
If you find any things wrong or want to add something please leave a comment.

I will be really happy to read your comments and improve the article if needed.
If you want more explanation about JaroWinkler and Leveinstein distance here are two articles.

Thanks for reading me and see you around!

Keep in Touch

On Twitter : @yet_anotherdev

There are so many discussions these days on all channels about so many topics that I feel the need to immerse myself in reading some good articles about Ruby and all.

Thus, inspired by Jeremy Smith let me ask you a question:

or

What is the best article you have ever read about Ruby or Rails, one that influenced your way of writing code or maybe the way you think about Ruby or Rails?

Please reply in the comments here on the ShortRuby website.

This way, all of us can see all recommendations.

I will love to gather a list of the articles you are suggesting.

PS: I plan to publish a question or announcement in this Community section once per week (but not every week).

If you don’t want to receive them, you can disable these specific emails by accessing manage your subscription section. I also added here a step-by-step guide about how to do this.

We’re just about a month away from RailsConf in Atlanta! We can’t wait to gather with you for this year’s exciting lineup of talks, workshops, and keynote speakers. You can still get a ticket here, although they are going very fast!

In the meantime, watch this space for the program schedule, and keep in mind these important dates and details to help you plan for your best conference experience:

Room reservation cut-off date

The last day to book a room at The Westin Peachtree Plaza, Atlanta, where RailsConf will take place, is Thursday, March 30 (5:00 PM ET).

Ticket sales and registration cancellation cut-off date

The last day to buy a conference ticket is Saturday, April 22 (11:59PM ET). The last day to receive a refund for a ticket you’ve already purchased is Friday, April 21 (11:59PM ET). You can learn more about our refund policy at the bottom of the page here.  

Lactation room deadline

The last day to request a time in the private lactation room at the conference is Friday, March 31 (5:00 PM ET).

COVID guidelines

Please make sure to read our COVID guidelines ahead of attending this year’s conference. They can be found at the bottom of the page here.

Workshop and social events sign-ups

Coming soon! Watch this space and stay tuned to our social media channels as we update with information on how to RSVP for conference workshops and our official social events.

As always, if you still have RailsConf2023 questions, please don’t hesitate to reach out to us at railsconf@rubycentral.org. We can’t wait to see you in Atlanta!

Here's a regular Ruby class with two properties and a constructor. To create a new instance of the class, you have to pass the arguments expected by the constructor, in the same order.

class Person
  attr_accessor :name, :age
  
  def initialize(name, age)
    @name = name
    @age = age
  end
end

# create a new object
akshay = Person.new('Akshay', 31)

However, if you've worked with ActiveRecord models in Rails, you must have noticed that they don't include the initialize method. Still, you can create them using the new method, passing in a hash of attributes in any order.

class Post < ApplicationRecord
end

# create a new post
post = Post.new(title: 'hello world', body: 'how are you?')

If you try this with a plain Ruby class, it throws an error.

akshay = Person.new(name: 'Akshay', age: 31)

# wrong number of arguments (given 1, expected 2) (ArgumentError)

So the question is: How does Rails make it work? 🤔

The AttributeAssignment Module

The answer lies in the ActiveModel::AttributeAssignment module, which includes the assign_atributes method. It allows you to set all the attributes by passing in a hash of attributes. The hash keys must match the attribute names.

class Language
  include ActiveModel::AttributeAssignment
  attr_accessor :title, :author
end

ruby = Language.new
ruby.assign_attributes(title: "Ruby", author: "Matz")

ruby.title # => 'Ruby'
ruby.author # => 'Matz'

ruby.assign_attributes(author: "Yukihiro Matsumoto")

ruby.title # => 'Ruby'
ruby.author # => 'Yukihiro Matsumoto'

Under the hood, the assign_attributes method calls the assign_attribute method for each key-value pair.

Here's the internal implementation of this method.

def _assign_attribute(k, v)
  setter = :"#{k}="
  if respond_to?(setter)
    public_send(setter, v)
  else
    raise UnknownAttributeError.new(self, k.to_s)
  end
end

Let's try to understand what's going on when we pass name: 'Akshay' when initializing the object.

1. The setter will be set to :name=
2. The respond_to? method checks if our class includes the name= method, which sets the name. If it does, it calls that method.
3. Since our class uses the attr_accessor :name directive, the name= method is present.  Hence it calls the setter method, setting the value 'Akshay' for the name attribute.
4. For attributes not defined via attr_accessor , attr_writer or via overridden methods, it raises the UnknownAttributeError.

That's nice, but how can you create new objects?

On its own, the AttributeAssignment module won't allow you to call the new method to create new objects. For that, you need the ActiveModel::API module.

The API module includes the AttributeAssignment module and provides an initialize method. This method takes an attributes hash as argument and calls the assign_attributes method, passing the hash.

module ActiveModel
  module API
    include ActiveModel::AttributeAssignment
    
    def initialize(attributes = {})
      assign_attributes(attributes) if attributes
      super()
    end
  end
end

If you include the ActiveModel::API module in your plain Ruby classes and remove the constructor, you can create new instances like Active Record models.

class Person
  include ActiveModel::API
  
  attr_accessor :name, :age
end

# akshay = Person.new(name: 'Akshay', age: 31)
=> #<Person:0x000000010d045b60 @age=31, @name="Akshay">

How Do Rails Models Get This Behavior?

All Active Record models inherit from the ApplicationRecord class, which inherits from the ActiveRecord::Base class. The Base class includes the ActiveRecord::AttributeAssignment module. Finally, this module includes the ActiveModel::AttributeAssignment module.

Now, the ActiveRecord::AttributeAssignment module provides its own internal implementation for the private methods, but that's a topic for another blog post.

I hope this post helped you gain a deeper understanding of the AttributeAssignment module. You can use it with plain Ruby classes to simplify your code. You can even use this feature outside Rails by only using the ActiveModel framework and including the ActiveModel::API module.

If you have any questions or feedback, didn't understand something, or found a mistake, please leave a comment below or send me an email. I look forward to hearing from you.

Please subscribe to my blog if you'd like to receive future articles directly in your email. If you're already a subscriber, thank you.

Today, many web applications will feature pages that are publicly available — like a homepage — and more secure ones where a user has to log in to get access. The process of user registration, logging in, and tracking user session state is called "authentication".

At the same time, when dealing with logged-in users, it's necessary to separate actions and resources that are available to them depending on their user roles. For example, "admins" generally have more access than normal users. This process of separating authenticated user access is termed "authorization".

In this post, we'll explore two of the most popular authorization libraries in Ruby so far: Pundit and CanCanCan.

Let's dive in!

Setup and Prerequisites

In this article, we'll use a simple Rails 7 app featuring users and posts. Users will be assigned an "editor" or "writer" role. Such a scenario is perfect for showcasing how authorization works.

Check out the code repos for our example app with:

• Pundit
• CanCanCan

Even though this article focuses on authorization, the companion subject of authentication cannot be ignored.

We won't get into the details of setting up authentication as that's outside the scope of this post. You can follow the installation instructions in the Devise gem documentation (we'll pair Devise with our authorization gems).

One more thing — whether you deal with Pundit or CanCanCan, the actual work of defining your app's user roles does not happen automatically when you install either of the authorization gems. You will need to set it up manually.

Let's do that.

Defining User Roles

Let's assume you've already installed the Devise gem and set up a user model. The next step is to decide what roles the app's users will have. In our case, we'll set out the following roles:

• Writer - This user role will be able to create, edit, update, and delete their own posts. At the same time, a writer can also view other writers' posts.
• Editor - A user with the editor role can edit, update, view, and delete any user's posts, but they cannot create their own posts.

Add a column to store a user's role (using a migration to modify the user's table):

bundle exec rails generate migration add_column_role_to_users role:integer

Then run the migration:

bundle exec rails db:migrate

And then modify the user model to include the roles we've just defined:

# app/models/user.rb

class User < ApplicationRecord
  # User role
  enum role: %i[writer editor]

  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :validatable

end

While we are on this, let's go ahead and set up a Post model with the attributes of title and body, as well as a reference to the user who writes the post:

bundle exec rails g scaffold Post title body:text user:references

We add the foreign key user_id into the Post model to associate every post that's created with a particular user. Since we have already set up user authentication using Devise, we can simply modify the create method of the Posts controller to automatically set the user_id to the currently logged-in user:

# app/controllers/posts_controller.rb
...

def create
    @post = current_user.posts.new(post_params) # automatically assign a post to the current user on creation

    respond_to do |format|
        if @post.save
        format.html { redirect_to post_url(@post), notice: 'Post was successfully created.' }
        format.json { render :show, status: :created, location: @post }
        else
        format.html { render :new, status: :unprocessable_entity }
        format.json { render json: @post.errors, status: :unprocessable_entity }
        end
    end
end
...

We can also modify the User model to make sure it's associated with the Post model:

# app/models/user.rb

class User < ApplicationRecord
  has_many :posts

  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :validatable

  enum role: %i[writer editor]
end

Finally, let's seed the database with some users, each with a different role:

# db/seeds.rb

User.create(email: 'writer1@example.com', password: 'example', password_confirmation: 'example', role: 0) # this creates a user with the writer role
User.create(email: 'writer2@example.com', password: 'example', password_confirmation: 'example', role: 0) # second writer
User.create(email: 'editor@example.com', password: 'example', password_confirmation: 'example', role: 1) # this creates a user with the editor role

Then seed the database:

bundle exec rails db:seed

So far, our app now has:

• Authentication set up using Devise.
• Two defined user roles of "writer" and "editor".
• A Post model.

With that, we now have everything we need to work properly with Pundit.

Authorization in Your Ruby App with Pundit

Pundit is an authorization library built around object-oriented architecture and plain Ruby classes. It gives you tools to build a solid authorization layer that can scale with your app.

Installing Pundit in Your Ruby App

Add the gem to your app's Gemfile:

# Gemfile

gem 'pundit'

Then in the terminal, run the command:

bundle install

Alternatively, run the following command:

bundle add pundit

Since authorization mostly deals with granting or denying access to controller resources, the next step is to add Pundit's authorization module to the application controller:

# app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  include Pundit::Authorization
end

And finally, generate a base policy class all other policies will inherit from:

bundle exec rails g pundit:install

Which gives you the following base policy class:

# app/policies/application_policy.rb

class ApplicationPolicy
  attr_reader :user, :record

  def initialize(user, record)
    @user = user
    @record = record
  end

  def index?
    false
  end

  def show?
    false
  end

  def create?
    false
  end

  def new?
    create?
  end

  def update?
    false
  end

  def edit?
    update?
  end

  def destroy?
    false
  end

  class Scope
    def initialize(user, scope)
      @user = user
      @scope = scope
    end

    def resolve
      raise NotImplementedError, "You must define #resolve in #{self.class}"
    end

    private

    attr_reader :user, :scope
  end
end

With that, Pundit is now properly set up and ready to go. Additionally, we have authentication and user roles set up.

Next, let's use policies to implement rules that define how each user role will access the Post resource.

Configuring Pundit Policies

In Pundit lingo, a "policy" is a plain Ruby class where you define all the rules for how a user role interacts with different resources.

These policies come with some notable features:

• Each policy is named after an existing model, suffixed with the word "Policy". For example, a policy defining how the Post model is accessed is called PostPolicy.
• An attr_reader: this takes two arguments - the first is a user, specifically, the currently logged-in user — current_user — and the second argument is the model that you'd like to define authorization rules for, in our case, post.
• Query methods that will map to the controller methods of the resource that has authorization rules set up. For organizational purposes, it's best to have all policies under the app/policies folder.

Since we know what access rules we need to define for the different user roles in our app, let's start with the writer role.

Defining a Pundit Policy for a Role

Let's use the writer role to see how this can be done. To begin with, we can outline the writer role's access to the Post resource as follows:

• Create their own posts
• Edit and update their own posts
• View (or read) their own posts as well as other user's posts
• Delete their own posts

With that in mind, go ahead and generate a new policy to control how posts are accessed:

bundle exec rails g pundit:policy post

This gives us the following generic policy class that inherits from the base policy we generated earlier:

# app/policies/post_policy.rb

class PostPolicy < ApplicationPolicy
  class Scope < Scope
    # NOTE: Be explicit about which records you allow access to!
    # def resolve
    #   scope.all
    # end
  end
end

Let's now add access rules for the writer role accordingly (these also override any rules that are inherited from the base policy class):

# app/policies/post_policy.rb

class PostPolicy < ApplicationPolicy
  ...
  def create?
    @user.writer? # a writer is able to create a post
  end

  def edit?
    @user.writer? # a writer is able to edit a post
  end

  def update?
    @user.writer? # a writer can update a post
  end

  def delete?
    @user.writer? # a writer can delete a post
  end
end

Here, we define what a writer can do when creating, editing, updating, and deleting posts which are corresponding actions on the posts' controller. If you have noticed, these rules apply to posts in general and not necessarily to a writer's own posts (we'll get to that in the section on scopes).

For now, let's see how we can use this policy.

Using a Policy in Pundit

To use a policy, call Pundit's authorize method on the controller's method where you want to check access rules. You instantiate the relevant policy class and, more specifically, the action that should be called based on where the authorize method has been called.

For example, let's call authorize on the post controller's create method:

# app/controllers/post_controller.rb
...

def create
    @post = current_user.posts.new(post_params)
    authorize @post

    respond_to do |format|
        if @post.save
        format.html { redirect_to post_url(@post), notice: 'Post was successfully created.' }
        format.json { render :show, status: :created, location: @post }
        else
        format.html { render :new, status: :unprocessable_entity }
        format.json { render json: @post.errors, status: :unprocessable_entity }
        end
    end
end
...

To test this, log in as an editor and try to create a post. Doing this will result in the following error:

Though this does what we want, showing such an error page is not good for the user experience. In the next section, you will learn how to rescue the NotAuthorizedError and serve up something more user-friendly.

Rescuing From Pundit's NotAuthorizedError

First, we'll need to edit ApplicationController as follows:

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  include Pundit::Authorization

  rescue_from Pundit::NotAuthorizedError, with: :user_not_authorized

  private

  def user_not_authorized
    flash[:alert] = "You are not authorized to perform this action."
    redirect_back(fallback_location: root_path)
  end
end

Here, we are basically telling Pundit to use the user_not_authorized method whenever the NotAuthorizedError is raised. It will simply redirect the unauthorized user to a specific page and also provide a relevant flash message explaining what has happened:

We now have a simple authorization system capable of handling a very generalized permissions case.

But what if we want more fine-grained permissions? For this, we need to utilize Pundit's scopes.

Pundit's Scopes

Pundit scopes are similar to ActiveRecord scopes. In the latter, you can use scopes to fetch records according to specific criteria. However, with Pundit's scopes, you manage access to specific resources according to certain rules you set.

Let's say we want to let editors edit any writer's posts, but only give writers access to create and edit their own posts. To achieve this fine-grained access control, we need to implement scopes like so:

# app/policies/post_policy.rb

class PostPolicy < ApplicationPolicy
  class Scope < Scope
    def resolve
      scope.where(user_id: @user.try(:id)).or(scope.where(@user.editor?))
    end
  end

  ...
end

This code says in plain English: "Check to see if the currently logged-in user owns this resource, or if the user has the role "editor" to authorize the resource."

Of course, scoping with Pundit can go way deeper than we've shown, but we'll leave it at that in this post. If you want, check out the Pundit documentation to see how you can use scopes in a more advanced way.

For now, let's go through how you can use the library with Rails' strong parameters.

Using Pundit with Rails' Strong Parameters

By combining Pundit's authorization rules with Rails' strong parameters, you can achieve lockdown access to a resource's attributes. Let's say you want editors to be the only ones with access to an excerpt field of the Post model. How would you go about it?

First, add an aptly-named block to the relevant policy:

# app/policies/post_policy.rb

class PostPolicy < ApplicationPolicy
...
  def permitted_attributes
    if user.editor?
      [:title, :body, :excerpt]
    else
      [:title, :body]
    end
  end
end

Then, modify the permitted params block in the controller:

# app/controllers/posts_controller.rb
class PostsController < ApplicationController
  ...

  private

  def post_params
    params.require(:post).permit(policy(@post).permitted_attributes)
  end
end

With that, you have made the excerpt attribute available to editors only.

We'll now shift gears to look at the other authorization library, CanCanCan.

Introducing CanCanCan for Your Ruby App

CanCanCan is an authorization library that uses an "ability" class to define who has access to what in a Rails app. Actual access control is achieved using an authorization module and various view helpers.

Installing CanCanCan

Installation is as easy as running the command below:

bundle add cancancan

Just like Pundit, with CanCanCan, you can define all access rules within a plain Ruby class object called an "ability" class. Let's do that next with the following generator command:

bundle exec rails g cancan:ability

Which generates the class object below:

# app/models/abilty.rb

class Ability
  include CanCan::Ability

  def initialize(user)
  end
end

Let's learn more about how the ability class can define access rules for our example Rails app next.

Defining and Checking CanCanCan Abilities

We'll use the same user roles as in the Pundit example: writers and editors. A writer can create, edit, update, destroy their own posts, and view other writers' posts; an editor can do everything except create a post of their own.

To use CanCanCan, first define what each user or role can access in the ability class, following this format:

# app/models/ability.rb

can actions, subjects, conditions

As an example:

# app/models/abilty.rb

class Ability
  include CanCan::Ability

  def initialize(user)
    can :update, Post, user: user # With CanCanCan, the update action covers both the edit and update actions
  end
end

Then, in the controller, check if an access rule exists for a particular action — using our example, the edit action:

# app/controllers/posts_controller.rb

...
def edit
    authorize! :edit, @post
end
...

With this in place, if we visit the edit post view as another writer, we get the error below:

And just like we did with Pundit, let's rescue this error and show the user a better error page.

Handling CanCanCan’s “Access Denied” Errors

Whenever a resource is not authorized, CanCanCan will raise a CanCan::AccessDenied error. The easiest way to catch this exception is by modifying the ApplicationController as follows:

# app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  rescue_from CanCan::AccessDenied do |exception|
    respond_to do |format|
      format.json { head :forbidden }
      format.html { redirect_to root_path, alert: exception.message }
    end
  end
end

Doing this makes for a good user experience. In the screenshot below, the unauthorized user is redirected to the home page and shown a relevant flash message:

You can even customize the error message shown to the user:

#config/locales/en.yml
en:
  unauthorized:
    update:
      all: "You're not authorized to %{action} %{subject}."
      writer: "You're not authorized to %{action} other writer's posts."

If your app serves XML as a response, or you just want to dive deeper into handling the CanCanCan::AccessDenied exception, check out CanCanCan's documentation. For now, let's see how we can combine CanCanCan's various abilities to create a more robust authorization layer.

Combining Multiple CanCanCan Abilities

You can define multiple access rules for a resource in the ability class. Taking the writer and editor roles, for example, we can do this:

# app/models/ability.rb

class Ability
  include CanCan::Ability

  def initialize(user)
    can :update, Post, user: user # only a post's author/owner can update or edit a post
    can :read, Post # any user can read a post or list of posts (access both show and index actions)
    can :destroy, Post, user: user # only a post's author/owner can delete it

    return unless user.editor?
    cannot :create, Post # an editor role cannot create a post
    can :update, Post # an editor can update any post
  end
end

The question is, why would you want to do this?

With CanCanCan, you can define all access rules in one ability file. This has both advantages and disadvantages.

Having all your rules in one place is very convenient for handling access rules since all rules are defined in one place.

However, if your app deals with many user roles or you have several resources that need authorization, the ability class can easily become too big and complex to handle. One way to handle this is by reorganizing the ability class to use method definitions, like so:

# app/models/ability.rb

class Ability
  include CanCan::Ability

  def initialize(user)
    anyone_abilities

    if user.writer?
      writer_abilities
    elsif user.editor?
      editor_abilities
    end

  end

  private

  def anyone_abilities
    can :read, Post
  end

  def writer_abilities
    can :update, Post, user: Current.user # we define Current.user in the application controller so that the ability class (which is a model) is able to pick up the currently logged in user
  end

  def editor_abilities
    cannot :create, Post # an editor role cannot create a post
    can :update, Post # an editor can update any post
  end

end

There's a lot more to CanCanCan than can be effectively covered in this article. Do check out the detailed CanCanCan documentation to learn more.

To wrap up, let's briefly touch on the features of each library and give reasons why you might choose one over the other.

Feature Comparison: Pundit vs. CanCanCan for Your Ruby App

• File organization - With Pundit, you can easily organize your app's authorization across multiple policy files. But with CanCanCan, authorization rules will live in one ability file. Working with multiple ability files is still possible, but this is not the default implementation style.
• Tests - Because permissions code will mostly reside within a single class compared to Pundit's multiple ability classes, writing tests for CanCanCan could be easier than for Pundit.
• Helpers - Both libraries provide a number of view helpers to check for permissions in the view layer. CanCanCan gives you the can? method to use in your views, while Pundit gives you relatively similar functionality with the policy helper.
• Devise integration - As you can see from the examples we have used in the article, both libraries integrate with Devise very well.

Wrapping Up

In this article, we looked at two of the most popular authorization gems in the Ruby and Rails ecosystem: Pundit and CanCanCan.

Both libraries offer a rich set of features for managing permissions in your Rails app. Because of this, it is nearly impossible to tell you which gem to choose — both can manage even the most complex permissions setups.

We encourage you to try out Pundit and CanCanCan in your app and see which one fits your needs best.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

This blog post explores a possibility to use Entity-Component-System architecture to model business logic in a “regular application”, like we work every day. It’s based on a talk I gave few months ago in a local Ruby users group. I’d like to stress that these are notes from an experiment, I’m not saying that you absolutely shoud use that in your main production application (you probably shouldn’t).

Let’s start

What is ECS?

Entity-Component-System is an architecture coming from game development industry. It is sometimes dubbed as an alternative to OOP. It concentrates on grouping traits and behaviours instead of putting things into (often fake) hierarchiesThis is one of the main “accusations” of a game dev world towards OOP - that it’s hard to build a hierarchy upfront, that it’s difficult to change once you have it and that it often feels not natural., like in class-based OOP. Some game developers also swear that it well supports the chaotic process of making games, where sometimes you need to add or adjust a big thing just before the release.

There are 3 main building blocks of ECS architecture:

• Entity – it is just “something” having an identifier and some components attached
• Component – just data, without any behaviour
• System – a behaviour for entities containing specific components

In a typical video game, let’s say Bomberman, we could have entities such as: player, wall, enemy, explosion, bomb. Next to them, we could have following components: position, animation, health points, movement (speed, direction), susceptibility to gravity. And finally, some systems:

• change animation frame
• update position
• substract health points from entities in the blast radius
• kill enitites with zero HP
• count down by one to bomb exposion
• check if all enemies are dead
• check if the player is alive

ECS in Ruby

I found a couple of Ruby libraries to model with ECS. Here are some of them:

• Baku – unmaintained (most commits from 6 years ago), poorly documented, created for Gosu framework
• Chione – hard to tell anything useful about it for me, only contains API docs
• FelECS – it was very new when I gave the talk initially, looked promising
• Draco – ECS for DragonRuby, which I eventually picked to write my examples; today it seems a bit abandoned

Sample code with Draco

# entity

player = Draco::Entity.new


# component

class Health < Draco::Component
  attribute :value
end

player.components << Health.new(value: 3)


# we can also define entity using a class

class Player < Draco::Entity
  component Position, x: 1, y: 1
  component Tag(:visible)
  component Health
end

player = Player.new


# finally, a system

class RenderSpriteSystem < Draco::System
  filter Tag(:visible), Position, Sprite

  def tick(args)
    camera = world.filter([Camera]).first

    sprites = entities.select { |e| entity_in_camera?(e, camera) }.map do |entity|
       {
        x: entity.position.x - camera.position.x,
        y: entity.position.y - camera.position.y,
        w: entity.sprite.w,
        h: entity.sprite.h,
        path: entity.sprite.path
      }
    end

    args.outputs.sprites << sprites
  end

  def entity_in_camera?(entity, camera)
    # ...
  end
end

Okay, this is all and nice, but how does it relate to our “serious” web application? Let’s see how we could apply it to an e-commerce project…

E-commerce with ECS

The heart of every e-commerce project is an orderOr a basket, which is often just an order in draft state. But let’s not go into this discussion right now…. Let’s see what an order may contain:

• Obviously, a list of products
• Coupons or vouchers
• Discounts (such as “buy 4, get 1 free”)
• Shipping
• Packaging
• First-purchase discount

The “things” above have following attributes / properties:

• Price
• Tax
• Quantity
• Weight
• Restrictions (e.g. you can only buy alcohol if you are 18)

Of course, not every item from the first list has all the attributes from the second one, but most attributes are shared among at least two items.

As you have probably guessed, the first list are our entities, the second are components. Now, it’s time for systems:

• Apply discounts
• Calculate final price
• Calculate taxes
• Calculate total mass
• Check if you can ship to the person who ordered

Let’s take calculating the price. In the “classic approach” it would probably look more or less like this:

def calculate_total_price
  calculate_products + # products.each { |p| p.amount * p.unit_price }
    calculate_shipping_price + # shipping.pickup? ? 0 : shipping.price
    calculate_packaging +
    apply_vouchers +
    apply_applicable_discounts
end

Let’s have a look at the ECS counterpart to this code:

Components:

require './draco'

class Description < Draco::Component
  attribute :name
end

class Price < Draco::Component
  attribute :value
end

class Weight < Draco::Component
  attribute :value
end

class Quantity < Draco::Component
  attribute :value
end

class Tax < Draco::Component
  attribute :name
  attribute :value
end

A product entity:

product = Draco::Entity.new
product.components << Description.new(name: "Sugar")
product.components << Quantity.new(value: 2)
product.components << Weight.new(value: 1)
product.components << Price.new(value: 12.5)
product.components << Tax.new(name: "Federal 7%", value: 7)
product.components << Tax.new(name: "State 7%", value: 7)

And finally, the system:

class CalculateTotalPrice < Draco::System
  filter Price

  # tick method gives away that we are taking a library designed for games
  def tick(summary)
    price = 0
    entities.each do |e| 
      q = e.respond_to?(:quantity) ? e.quantity.value : 1
      price += e.price.value * q
    end
    summary.total_price = price
  end
end

Now let’s put that all together:

summary = CartSummary.new
cart = Draco::World.new
cart.entities << product
cart.systems << CalculateTotalPrice
cart.tick(summary)
summary.total_price # => 12.55

Cool. We have done a lot of work just to not write a simple products.each { |p| p.amount * p.unit_price }, right?

Of course, to just model summing up the partial prices, using ECS would be a complete waste of energy. But remember what I quoted before, about being in line with a chaotic development environment? Let’s suppose you have your price calculation logic in place, you are almost ready to release, but then it turns out you cannot release without other things.

Let’s see some magic happening.

Magic: The Extending

“We absolutely need vouchers!”, shouts the PM.

Okay, here is vouchers implementationPrice calculation will still work, having a voucher will substract its value from the final price. And other systems, not relying on the price, will simply skip vouchers - for example the one to calculate the total weight):

voucher = Draco::Entity.new
voucher.components << Price.new(value: -10)

cart.entities << voucher

“And shipping! We forgot about shipping!”

Sure.

shipping = Draco::Entity.new
shipping.components << Price.new(value: 15.99)
shipping.components << Tax.new(value: 23)
shipping.components << Tag(:shipping)

cart.entities << shipping

“But what about the pick-up in person?!”

Okay.

pickup = Draco::Entity.new
pickup.components << PickupInfo.new(location: "main-square")
pickup.components << Tag(:shipping)

cart.entities << pickup

“Make sure that each order has either shipping or pick-up!”

class CheckShipping < Draco::System
  filter Tag(:shipping)

  def tick(summary)
    if entities.length != 1
      raise NoShippingException
    end
  end
end

“Hello, here’s Irene from legal. Did you make sure that you cannot sell alcohol to underage customers?”

class RestrictAlcoholSale < Draco::System
  filter Tag(:alcohol)

  def tick(summary)
    customer = summary.customer
    if entities.length > 0 && customer.under_18?
      raise AgeRestrictionsViolated.new(entities)
    end
  end
end

beer.components << Tag(:alcohol)
cart.systems << RestrictAlcoholSale

As you can see, the system built this way is extremely open for extension, while you don’t need to modify the coreIf it rings a bell it’s because it should.. We added vouchers, shipping and pickup without touching the code calculating the price - it just kept working. Similarly, we added a system for restrict the alcohol sale and all we need to make it work is to add :alcohol tag component to some products.

Some final comments

• ECS proved (for me) to be very elastic solution, with which we can add new things without having to adjust already existing functionality; and without the fear it will break. I think it might be especially useful in dynamic environments where requirements change often and we are still discovering a lot about the domain.
• Existing implementations in Ruby are very game-oriented (unsurprisingly) and it sometimes shows.
• Systems in ECS are designed to be run in parallel. This might not be always viable for “regular” (non-game) applications, but some parts of it can be for sure run independent of the otherFor example: age verification does not depend on price calculation in any way. But other checks might: for example first-time customers cannot buy for more than $1000.
• Of course, there’s a whole story of how to serialize it and store it in the database. It should be possible, but requires separate investigation.

To summarize, I think it was an interesting experiment and learning opportunity to see how other people are dealing with their stuff.

This is a series on setting up Kubernetes clusters in Amazon EKS.

In this post, we will setup Kubernetes Dashboard on AWS EKS Cluster.

Prequisites

Have Amazon EKS Cluster ready. For more information please visit Getting started with AWS EKS. This set up has been tested on Kubernetes Cluster V1.24

1. Deploy Kubernetes Dashboard

Apply the dashboard using the following-

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.4.0/aio/deploy/recommended.yaml

The output is as follows

namespace/kubernetes-dashboard created serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created secret/kubernetes-dashboard-certs created 
secret/kubernetes-dashboard-csrf created 
secret/kubernetes-dashboard-key-holder created 
configmap/kubernetes-dashboard-settings created 
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created 
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created 
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created 
deployment.apps/kubernetes-dashboard created 
service/dashboard-metrics-scraper created 
deployment.apps/dashboard-metrics-scraper created

2. Create an eks-admin Service Account

We need to create a service account with a cluster binding role to connect to the dashboard.

cat >eks-admin-service-account.yaml <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: eks-admin
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: eks-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: eks-admin
  namespace: kube-system
EOF

Apply the service account + cluster role bindings

kubectl apply -f eks-admin-service-account.yaml

3. Create an Authentication Token

To connect to the dashboard first we need to create a Token.

kubectl create token eks-admin -n kube-system

The output is the token itself, something like

eyJhbGciOiJSUzI1NiIsImtpZCI6IjI4NGNhNDY3MjMyOGQwOTJiYjBkMWViZjIxNDgxM2Y0MzU4ZDZkYjMifQ.eyJhdWQiOlsiaHR0cHM6Ly9rdWJlcm5ldGVzLmRlZmF1bHQuc3ZjIl0sImV4cCI6MTY3ODA5NDUyMiwiaWF0IjoxNjc4MDkwOTIyLCJpc3MiOiJodHRwczovL29pZGMuZWtzLnVzLWVhc3QtMi5hbWF6b25hd3MuY29tL2lkLzQwOTExMUExODU1NkJEOEEzRTUzQUUxOEU3RjA4MjVFIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsInNlcnZpY2VhY2NvdW50Ijp7Im5hbWUiOiJla3MtYWRtaW4iLCJ1aWQiOiJkYWQwYWQxNy0xZWUzLTRlMmMtYTcwOC1jN2RhOWM5YTExYzUifX0sIm5iZiI6MTY3ODA5MDkyMiwic3ViIjoic3lzdGVtOnNlcnZpY2VhY2NvdW50Omt1YmUtc3lzdGVtOmVrcy1hZG1pbiJ9.XD_MSrQTwoBB9Zg1_5R0fu1lZJjqDUNM8dX5yJyay3iDhcCI9SHP7Nx6OxA-tLJ78Mzav8UR56L_Ufhzm0-x2I5yCnDl4MaGzogoIE0NF6vDILL3ljA7U9PoPPMBT3O6GHycxIzXy3HgBsLTR_7M5exGmV3rdiCrQ-lJ2-JDp4KBvkYqDiWZ-eD-W9PVTpfk3kSoeWrynueavOKql1nuHHNgW6YPc8ckxcvrGP7JnVYqATVN7H7iYT5RJj3-IDRJBn3IjLJdWb0s7_LvW6WwoCFQeKyKd7dd3sFGH_-6NZU7ryk5VYVYmMIIbOL6gXgDPz1sPJKbEwYYZ27aYxIVTw

4. Connect to Dashboard

Start Kubectl Proxy

kubectl proxy

To access the dashboard, open the link in a web browser http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#/login

This will open the Kubernetes Dashboard in the Web Browser.

For more information on customising metrics please visit kuberneties docs.

This is a series on setting up Kubernetes clusters in Amazon EKS.

In this post, we will setup Elastic Block Store on AWS EKS Cluster.

EBS is required for EKS PVC.

1. IAM Policy for EBS

• Go to Services > IAM on the AWS Web Dashboard
• Select “Create a Policy”
• Select the JSON tab and paste it below

{
  "Version":  "2012-10-17",
  "Statement":  [
    {
      "Effect":  "Allow",  
      "Action":  [  
	      "ec2:AttachVolume",  
	      "ec2:CreateSnapshot",  
	      "ec2:CreateTags",  
	      "ec2:CreateVolume",  
	      "ec2:DeleteSnapshot",  
	      "ec2:DeleteTags",  
	      "ec2:DeleteVolume",  
	      "ec2:DescribeInstances",  
	      "ec2:DescribeSnapshots",  
	      "ec2:DescribeTags",  
	      "ec2:DescribeVolumes",  
	      "ec2:DetachVolume"  
	      ],
	      "Resource":  "*"  
	}  
  ]  
}

• Review the same in Visual Editor
• Click Review Policy
• Name: Amazon_EBS_CSI_Driver
• Click Create Policy

2. Associate with Worker Node IAM Role ARN

Use the following command to obtain the ARN from the aws-auth configmap

kubectl -n kube-system describe configmap aws-auth

From the output, note down the ARN Number

Name:         aws-auth
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>

Data
====
mapRoles:
----
- groups:
  - system:bootstrappers
  - system:nodes
  rolearn: arn:aws:iam::17913XXXXXXX:role/eksctl-eks-cluster-nodegroup-ng-NodeInstanceRole-M3LZJUUCOC10
  username: system:node:

In the above case, it is rolearn: arn:aws:iam::17913XXXXXXX:role/eksctl-eks-cluster-nodegroup-ng-NodeInstanceRole-M3LZJUUCOC10

Next, we need to associate the role

• Go to Services
• IAM Roles
• Search for a role with eksctl-eks-cluster-nodegroup
• Click on Permissions tab
• Click on Attach Policies
• Search for Amazon_EBS_CSI_Driver
• Click Attach Policy

3. Deploy Amazon EBS CSI Driver

Kubernetes-Sigs provides a deployment from the AWS EBS CSI Driver. We simply need to apply the deployment file.

kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/?ref=master" 

Verify ebs-csi pods running kubectl get pods -n kube-system

kubectl get pods -n kube-system

The output will be similar to

NAME                                  READY   STATUS    RESTARTS   AGE
ebs-csi-controller-5fd5966556-gt5v5   6/6     Running   0          4m
ebs-csi-controller-5fd5966556-z7bjb   6/6     Running   0          4m
ebs-csi-node-6rgpp                    3/3     Running   0          4m
ebs-csi-node-ncnzw                    3/3     Running   0          4m

We have successfully, set up EBS CSI Driver.

This is a series on setting up Kubernetes clusters in Amazon EKS.

In this post, we will setup Ingress Nginx Controller on AWS EKS Cluster.

AWS recommends using ALB Controller for EKS Cluster but in our experience we found NGINX to be more useful for the following reasons:

1. Ingress Nginx Controller is much simpler to setup then compared to ALB Controller
2. One Network LoadBalancer can be shared between multiple applications
3. Let’s encrypt SSLs using Cert-Manager are possible. For ALB you have to use Route53.

1. Add HELM Repository

$ helm repo add nginx-stable https://helm.nginx.com/stable
$ helm repo update

2. Install the Nginx Controller

helm upgrade --install ingress-nginx ingress-nginx \
             --repo https://kubernetes.github.io/ingress-nginx \
             --namespace ingress-nginx --create-namespace

Verify the controller is installed

kubectl get pods -n ingress-nginx

The output is similar to

NAME                                        READY   STATUS      RESTARTS    AGE
ingress-nginx-controller-89758f7c6-swwpf    1/1     Running     0           1m

Verify, the LoadBalancer is set up.

kubectl get services -n ingress-nginx

The output is similar to,

NAME                                 TYPE           CLUSTER-IP       EXTERNAL-IP                                                              PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.100.20.84     a4217761afdb3457683821e38a3d3de7-XXXXXXXXX.us-east-2.elb.amazonaws.com   80:31105/TCP,443:31746/TCP   3d18h

Note down the External-IP, this will be used to map the domain name to the LoadBalancer. In our case a4217761afdb3457683821e38a3d3de7-XXXXXXXXX.us-east-2.elb.amazonaws.com

3. Setup 2048 Games as a Demo App

2048 is a Simple Game https://github.com/gabrielecirulli/2048 we can use to test the Ingress Setup.

To install the Game as a deployment, create a deployment.yaml file.

apiVersion: apps/v1
kind: Deployment

metadata:
  name: deployment-2048
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: app-2048
  replicas: 5
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app-2048
    spec:
      containers:
      - image: alexwhen/docker-2048
        imagePullPolicy: Always
        name: app-2048
        ports:
        - containerPort: 80

Install the deployment on the Cluster.

kubectl apply -f https://raw.githubusercontent.com/skynet86/hello-world-k8s/master/hello-world.yaml

Create a Service, this will create an endpoint that we can connect to Nginx Ingress

apiVersion: v1
kind: Service
metadata:
  name: service-2048
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  type: NodePort
  selector:
    app.kubernetes.io/name: app-2048

4. Map the Domain 2048.example.com

First, we need to Update the DNS record for 2048.example.com and point it to the load balancer address we noted down in step 2.

CNAME     2048.example.com      a4217761afdb3457683821e38a3d3de7-XXXXXXXXX.us-east-2.elb.amazonaws.com

The Domain name has to be updated using the interface provided by your Domain Provider. Domain names, take about 10 minutes - 24 Hours to propagate.

To test the status of domain propagation use the dig command.

dig 2048.example.com

On opening 2048.example.com, you will be presented with an Nginx Page with a 502 error code, which means the domain is successfully pointing to our LoadBalancer.

5. Create an Ingress

Create an Ingress file called ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:

name: nginx-2048-ingress
annotations:
   kubernetes.io/ingress.class: nginx

spec:
  rules:
  - host: 2048.example.com
    http:
      paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: app-2048
             port:
               number: 80

Apply the Ingress Controller to the cluster

kubectl apply -f ingress.yaml

On opening http://2048.example.com you will be presented with the 2048 Game.

6. Install Cert-Manager

Cert Manager is used to provision SSL Certificates to Kubernetes Clusters (https://github.com/cert-manager/cert-manager)

To install cert-manager simply run -

helm install \
     cert-manager jetstack/cert-manager \
         --namespace cert-manager \
         --create-namespace \
         --version v1.11.0 \
         --set installCRDs=true

This takes a few minutes to set up. To verify the installation run

kubectl get pods -n cert-manager

The output is similar to:

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-85945b75d4-xxxx               1/1     Running   0          9m
cert-manager-cainjector-7f694c4c58-xxxx    1/1     Running   0          9m
cert-manager-webhook-7cd8c769bb-x  xxx     1/1     Running   0          9m

In the next step, we configure a Cluster Issuer LetsEncrypt in our case to issue SSLs on the Fly. Create a file called cluster-issuer.yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
  metadata:
name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
      - http01:
           ingress:
              class: nginx

7. Update the ingress to use SSL

Finally, we add the SSL to our Ingress Controller

Update the Ingress we created in Step 5, like so

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:

name: nginx-2048-ingress
annotations:
   kubernetes.io/ingress.class: nginx
   cert-manager.io/cluster-issuer: letsencrypt-prod

spec:
  rules:
  - host: 2048.example.com
    http:
      paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: app-2048
             port:
               number: 80
  tls:
    - hosts:
        - 2048.example.com
      secretName: tls-2048-kibana

Apply the updated, ingress

kubectl apply -f ingress.yaml

SSL takes a few minutes to issue. The issued Certificate is stored in the secret tls-2048-kibana. On opening https://2048.example.com you will be presented with the 2048 Game.

This is a series on setting up Kubernetes clusters in Amazon EKS.

In this post, we will set up Elastic Stack on AWS EKS Cluster.

We will be setting up

1. Elastic Stack (7.17)
2. Nginx Ingress Controller (Shared)
3. Certificates for all Ingress Services

ElasticStack installation will consist of

1. Elastic Search
2. Kibana
3. APM Server

Note: The same setup will work for the latest version of Elastic which is 8.6.2 at the time of writing. APM Server does not work with version 8, as Elastic has deprecated APM in favor of ElasticFleet

Prequisites

• AWS EKS Cluster
• EBS CSI Driver Setup for PVC
• Nginx Ingress Controller
• Cert Manager

1. Elastic Search Installation

We will be using HELM Charts to install ElasticSearch.

The documentation can seem tricky, as Elastic Search is used for a wide range of use cases. There are 3 core components required for ElasticSearch to work

• Master Node
• Data Node
• Client Node

For high-volume searches, it is recommended to install all 3 core components on different PODs. In our case, we are installing all 3 services on the same POD.

The roles a POD assumes can be customized using the roles variable in values.yaml

Let’s start the installation by adding the Elastic Helm Repo

helm repo add elastic https://helm.elastic.co
helm repo update

Download a copy of ElasticSearch Values

wget https://raw.githubusercontent.com/elastic/helm-charts/main/elasticsearch/values.yaml -O elastic-values.yaml

Update the following values in elastic-values.yaml

imageTag: "7.17.9"

# Increase based on the requirement. Following are the bare minimum limits for optimal performance
resources:
  requests:
    cpu: "1000m"
    memory: "1200Mi"
  limits:
    cpu: "1100m"
    memory: "1700Mi"

# Persistent Volume Claims
volumeClaimTemplate:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 10Gi
  storageClassName: gp2

# We will attach the following service to an Ingress at a later step
service:
  enabled: true
  type: ClusterIP

Install ElasticSearch through HELM

helm install elasticsearch --values elastic-values.yaml  elastic/elasticsearch

Verify the installation

kubectl get pods

The output should be similar to

NAME                                     READY   STATUS    RESTARTS   AGE
elasticsearch-master-0                   1/1     Running   0          6m
elasticsearch-master-1                   1/1     Running   0          6m
elasticsearch-master-2                   1/1     Running   0          6m

Add Ingress for ElasticSearch

Save the following in elastic-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-elasticsearch-ingress
  annotations:
   kubernetes.io/ingress.class: nginx
   cert-manager.io/cluster-issuer: letsencrypt-prod
   nginx.ingress.kubernetes.io/backend-protocol: HTTPS
   nginx.ingress.kubernetes.io/proxy-body-size: 20m

 spec:
   tls:
     - hosts:
          - elastic.example.com
       secretName: tls-elastic
rules:
- host: elastic.example.com
  http:
       paths:
       - path: /
         pathType: Prefix
         backend:
           service:
             name: elasticsearch-master
             port:
                number: 9200

Run the following to apply the ingress. Please ensure CNAME or A RECORD for the domain are set correctly to the Ingress LoadBalancer

kubectl apply -f elastic-ingress.yaml

2. Kibana Installation

Kibana sits on top of the Elastic Stack, providing search and data visualisation capabilities for data indexed.

Again, will be using HELM to install Kibana

Download a copy of Kibana Values

wget https://raw.githubusercontent.com/elastic/helm-charts/blob/main/kibana/values.yaml -O kibana-values.yaml

Update the following values in kibana-values.yaml

imageTag: "7.17.9"

# Following are bare minimum limits for optimal performance
resources:
  requests:
    cpu: "400m"
    memory: "700Mi"
  limits:
    cpu: "700m"
    memory: "1Gi"
 
service:
  enabled: true
  type: ClusterIP

Install Kibana through HELM

helm install kibana --values kibana-values.yaml  elastic/elasticsearch

Verify the installation

kubectl get pods

The output should be similar to

NAME                                     READY   STATUS    RESTARTS   AGE
elasticsearch-master-0                   1/1     Running   0          16m
elasticsearch-master-1                   1/1     Running   0          16m
elasticsearch-master-2                   1/1     Running   0          16m
kibana-kibana-6978bfcbbd-nchll           1/1     Running   0          4m

Add Ingress for Kibana

Save the following in kibana-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-kibana-ingress
  annotations:
   kubernetes.io/ingress.class: nginx
   cert-manager.io/cluster-issuer: letsencrypt-prod
   nginx.ingress.kubernetes.io/backend-protocol: HTTPS


 spec:
   tls:
     - hosts:
          - kibana.example.com
       secretName: tls-kibana
rules:
- host: kibana.example.com
  http:
       paths:
       - path: /
         pathType: Prefix
         backend:
           service:
             name: kibana-kibana
             port:
                number: 5601

Kibana dashboard is accessible at kibana.example.com

Username: elastic

Password: Stored in Kubernetes secret > elasticsearch-master-credential

3. APM Server Installation

APM server pipes, logs received from APM agents like Elastic APM agent for Ruby and pipes them to ElasticSearch. This data is readily indexed and is used in Kibana for visualizations.

Again, will be using HELM to install APM Server

Download a copy of APM Server Values

wget https://raw.githubusercontent.com/elastic/helm-charts/main/apm-server/values.yaml -O apm-values.yaml

Update the following values in apm.yaml

imageTag: "7.17.9"

apmConfig:
  apm-server.yml: |
    apm-server:
      host: "0.0.0.0:8200"
      secret_token: "YOUR_SECRET_TOKEN"
      write_timeout: 30s
      rum.enabled: true
      rum.event_rate.limit: 300
      rum.event_rate.lru_size: 1000
      rum.allow_origins: ['*']
    queue: {}
    output.elasticsearch:
      hosts: ["http://elasticsearch-master:9200"]
      username: "${ELASTICSEARCH_USERNAME}"
      password: "${ELASTICSEARCH_PASSWORD}"

imageTag: "7.17.9"

# Bare minimum limits for optimal performance
resources:
  requests:
    cpu: "100m"
    memory: "100Mi"
  limits:
    cpu: "600m"
    memory: "512Mi"
 
service:
  type: ClusterIP

Install APM Server through HELM

helm install apm-server --values apm-values.yaml  elastic/elasticsearch

Verify the installation

kubectl get pods

The output should be similar to

NAME                                     READY   STATUS    RESTARTS   AGE
elasticsearch-master-0                   1/1     Running   0          26m
elasticsearch-master-1                   1/1     Running   0          26m
elasticsearch-master-2                   1/1     Running   0          26m
kibana-kibana-6978bfcbbd-nchll           1/1     Running   0          14m
apm-server-apm-server-86c9cb8d5c-scr9x   1/1     Running   0          6m

Add Ingress for APM Server

Save the following in apm-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-apm-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
   cert-manager.io/cluster-issuer: letsencrypt-prod
   nginx.ingress.kubernetes.io/backend-protocol: HTTPS

 spec:
   tls:
     - hosts:
          - apm.example.com
       secretName: tls-apm
rules:
- host: apm.example.com
  http:
       paths:
       - path: /
         pathType: Prefix
         backend:
           service:
             name: apm-server-apm-server
             port:
                number: 8200                

Open apm.example.com and you should see something like

  
{
	"build_date": "2022-04-19T06:13:49Z",
	"build_sha": "d3dc31c5db912b297835f934292218c2af5ea7ba",
	"publish_ready": true,
	"version": "7.17.9"
}

publish_ready:true states the server is ready to receive data.

Once, the Agent is connected you can have ready-made visualization under Kibana > APM like

This is a series on setting up Kubernetes clusters in Amazon EKS.

In this post we will setup Root Level Redirection using Caddy Server.

Setting up root domain redirection can be rather tricky, given the following points:

• Root domains @ can only have an A-Record under DNS therefore can only point to an IP Address. This causes issues if you are using something like AWS and are not using their DNS Name Servers using Route53.

• With default Nginx Redirection, https redirection does not work, unless a custom SSL is installed.

• ALIAS records, do not work unless extra plugin’s are installed for SSL.

• SSL Certificates with Nginx requires extra installation and have to be and updated has to be updated regularly.

We want to achieve the following:

http://example.com => https://example.com => https://www.example.com

Caddy Installation Ubuntu

SSH to the Ubuntu Server and add the necessary dependencies with

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https -y

add the official Caddy GPG key

 curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg

Update Ubuntu Repository

curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list

Update apt:

sudo apt-get update

Install Caddy

sudo apt-get install caddy -y

Start and enable the Caddy service with:

sudo systemctl enable --now caddy

On opening the servers IP Address in the browser, you will be presented with the Default Caddy welcome page.

Update Caddy Configuration

We just need to add 2 re-directives for SSL redirection

1. Set the SSL using tls

tls admin@example.com

1. Set the redirection

redir https://www.{host}{uri}

Final, Caddy Configuration file

sudo nano /etc/caddy/Caddyfile

example.com {
tls admin@example.com
redir https://www.{host}{uri}
}

Reload Caddy Server

sudo systemctl reload caddy

On opening http://example.com it will redirect to https://example.com which, will redirect to https://www.example.com.

Hello! Welcome to the monthly update. During February, our work was supported by Zendesk and many others.

Ruby Central News

In February, Ruby Central's open source work was supported by 35 different companies, including Ruby member Zendesk.

In total, we were supported by 124 developer members. Thanks to all of our members for making everything that we do possible. <3

RubyGems News

This month in RubyGems, we released RubyGems 3.4.7 and Bundler 2.4.7.

The following improvements and fixes are included in these releases (see the changelog for more information):

• added a --gemfile flag to the bundle init command to configure the gemfile name to be able to generate a custom name - #6046.
• added a warning on self-referencing gemspec dependencies - #6335.
• fixed inconsistent behavior of zero-byte files in one of the archives - #6329.
• restored older (better) version of error message when locked ref does not exist, to improve clarity - #6356.
• fixed gem crashing when installing from a corrupted lockfile - #6355.
• fixed crash in PubGrub involving empty ranges - #6365.

Other improvements we worked on this month that weren't included in the February release are:

• adding an experimental feature for the gem exec command to run executables from gems that may or may not be installed - #6309.
• implementing safe load for all marshaled data - #6384.
• making the gemspec file generated by bundle gem properly exclude itself from packaged gem - #6339.
• preserving bundler-setup-relative paths if the :path option is set to relative in standalone setup - #6327.

In February, RubyGems gained 108 new commits, contributed by 16 authors. There were 1,744 additions and 217 deletions across 100 files.

RubyGems.org News

This month, we made significant progress on the backend admin dashboard. We implemented robust auditing of all changes and added support for resetting users' MFA, blocking a user, and deleting webhooks.

We announced the deprecation of the dependency API, and we plan to implement brownouts and remove the endpoint entirely. We also migrated all RDS instances to be managed by Terraform and tested the migration of managed node groups on the rubygems.org EKS cluster.

In addition to these updates, RubyGems.org saw several bug fixes and updates, some of which include:

• the addition of telemetry to capture MFA login durations - #3376.
• the integration of DataDog for application performance monitoring - #3461.
• the set up of GitHub OAuth to protect the new /admin namespace - #3388.
• an updated Rails test job name for stability across version updates - #3420.
• fixed test avo warnings (via removal of redundant rake tasks loading) - #3422.
• an added avo MFA reset admin action & view of audit entries - #3426.
• a fixed ERD CI (via an updated erd.dot) - #3490.
• an updated Terraform package: 0.13.7 -> 1.3.9.
• updated Terraform providers packages: AWS 2.51 -> 4.54, external 1.2 -> 2.2, Kubernetes 1.8 -> 2.18,template 2.1 -> 2.3.

In February, RubyGems.org gained 209 new commits, contributed by 17 authors. There were 7,602 additions and 1,071 deletions across 273 files.

Ruby Ecosystem News

Here we outline additional exciting updates made to other projects in the Ruby Ecosystem.

New: Ruby SSL Check

• we updated ruby-ssl-check to print a warning if you're using an unmaintained version of Ruby - #14.

As always, we continue to fix bugs, review and merge PRs and reply to support tickets.

Total Spent

In February we completed 978 hours of development work @$150/hour, and spent $146,653.05.

Thank you

Thank you to all the contributors of RubyGems and RubyGems.org for this month! Your contributions are greatly appreciated, and we are grateful for your support.

Contributors to RubyGems:

• @simi Josef Šimánek
• @martinemde Martin Emde
• @hsbt Hiroshi SHIBATA
• @deivid-rodriguez David Rodríguez
• @nobu Nobuyoshi Nakada
• @amatsuda Akira Matsuda
• @sambostock Sam Bostock
• @composerinteralia Daniel Colson
• @koic Koichi ITO
• @jhawthorn John Hawthorn
• @gustavothecoder Gustavo Ribeiro
• @mercedesb Mercedes
• @segiddins Samuel Giddins
• @indirect André Arko
• @luke-gru Luke Gruber
• @duckinator Ellen Marie Dash

Contributors to RubyGems.org:

• @simi Josef Šimánek
• @jenshenny Jenny Shen
• @bettymakes Betty Li
• @ericherscovich Eric Herscovich
• @arunagw Arun Agrawal
• @sambostock Sam Bostock
• @segiddins Samuel Giddins
• @hsbt Hiroshi SHIBATA
• @indirect André Arko
• @jchestershopify Jacques Chester
• @martinemde Martin Emde
• @javier-menendez Javier Menéndez Rizo

Ruby Central is a non-profit organization dedicated to Ruby support and advocacy of the worldwide Ruby community.

We organize the annual RubyConf and RailsConf software conferences, support community growth, and provide vital infrastructure for the Ruby programming language.

To support our conferences and programs, we're looking to hire a freelance graphic designer! We'd love to have you come work with our small but dedicated team.

Responsibilities

• Create a brand and style guide for each conference
• Applies to web and print design
• Style guide includes logo, color palette, typography
• Support team with social media assets
• Design and help build the conference web site (Framer)
• Conference print design includes:
  Signs
  Badges
  Welcome materials
  Swag - t-shirts, stickers, pins, etc.

Tools

• Figma
  Used for early design ideation, collaboration with team, feedback cycles, and production artwork
• Slack
  For communication and remote-first interactions with the team
• Framer (not necessary, nice-to-have)
  Used for our conference website
• Familiarity with project management platforms
  Used to help facilitate remote-first workflows and collaboration with the remote team
  

Description of conference timeline/contract duration

• 2 conferences / year
• Hourly. Variable and flexible "time on". Estimated average of 20 hours per week.
• Location: Remote!
• Length: 6 months initially, with the possibility to extend.

Apply before the end of March online

GoodJob is a multithreaded, Postgres-based ActiveJob backend for Ruby on Rails.

GoodJob includes a full-featured (though optional) web dashboard to monitor and administer background jobs. The web dashboard is included in the good_job gem as a mountable Rails Engine.

As the maintainer of GoodJob, I want to make gem development easier for myself by innovating as little as possible. That’s why GoodJob builds on top of Active Record and Concurrent::Ruby.

But, the frontend can be a beast. When thinking about how to build a full-featured web dashboard packaged within a Rails Engine within a gem, I had three goals:

1. Be asset pipeline agnostic with zero dependencies. As of Rails ~7.0, a Rails developer can choose between several different asset pipeline tools (Sprockets, Webpacker/Shakapacker, esbuild/jsbundling, etc.). That’s too many! I want to ensure what I package with GoodJob is compatible with all of them. I also don’t want to affect the parent application at all; everything must be independent and self-contained.
2. Allow easy patching/debugging. I want the GoodJob web dashboard to work when using the Git repo directly in a project’s Gemfile or simply bundle open good_job to debug a problem.
3. Write contemporary frontend code. I want to use Bootstrap UI, Stimulus, Rails UJS, and write modular JavaScript with imports. Maybe even Turbo!

And of course, I want GoodJob to be secure, performant, and a joy to develop and use for myself and the developer community.

Read on for how I achieved it all (mostly!) with GoodJob.

What I didn’t do

Here’s all the things I considered, but decided not to do:

• Nope: Manually construct/inline a small number of javascript files: I did not want to manually build a javascript file, copy-pasting various various 3rd-party libraries into a single file, and then writing my code at the bottom. This seemed laborious and prone to error, especially when I would need to update a library; and my IDE doesn’t work well with large files so writing my own code would be difficult.
• Nope: Precompile javascript in the repository or on gem build: I did not want to force a pre-commit step to build javascript, or to only package built javascript into the gem because that would make patching and debugging difficult. Over my career I’ve struggled contributing to a number of otherwise fantastic gems that use this workflow pattern.
• Nope: Compile javascript in the application: Rails has too many different asset pipeline patterns right now for me to consider supporting them all. I consider this more a result of a highly fragmented frontend ecosystem than an indictment of Rails. I can’t imagine supporting all of the different options and whatever else shows up in the future at the same time. (I’m in awe of the gems that do; nice work rails_admin!)

What I did do

As I wrote earlier: “innovate as little as possible”:

Serve vanilla JS and CSS out of vanilla Routes/Controller

GoodJob has explicit routes for frontend assets that wire up to a controller that serves those assets statically with render :file. Let’s break that down…

In my Rails Engine’s router, I define a namescape, frontend, and two get routes. The first route, modules , is for Javascript modules that will go into the importmap. The second route, static , is for Javascript and CSS that I’ll link/script directly in the HTML head.

# config/routes.rb
scope :frontend, controller: :frontends do
  get "modules/:name", action: :module, as: :frontend_module, constraints: { format: 'js' }
  get "static/:name", action: :static, as: :frontend_static, constraints: { format: %w[css js] }
end

In the matching controller, I create static constants that define hashes of files that are matched and served, which I store in a app/frontend directory in my Rails Engine. I want paths to be explicit for security reasons because passing any sort of dynamic file path through the URL could be a path traversal vulnerability. All of the frontend assets are stored in app/frontend and served out of this controller:

# app/controllers/good_job/frontends_controller.rb

module GoodJob
  class FrontendsController < ActionController::Base # rubocop:disable Rails/ApplicationController
    STATIC_ASSETS = {
      css: {
        bootstrap: GoodJob::Engine.root.join("app", "frontend", "good_job", "vendor", "bootstrap", "bootstrap.min.css"),
        style: GoodJob::Engine.root.join("app", "frontend", "good_job", "style.css"),
      },
      js: {
        bootstrap: GoodJob::Engine.root.join("app", "frontend", "good_job", "vendor", "bootstrap", "bootstrap.bundle.min.js"),
        chartjs: GoodJob::Engine.root.join("app", "frontend", "good_job", "vendor", "chartjs", "chart.min.js"),
        es_module_shims: GoodJob::Engine.root.join("app", "frontend", "good_job", "vendor", "es_module_shims.js"),
        rails_ujs: GoodJob::Engine.root.join("app", "frontend", "good_job", "vendor", "rails_ujs.js"),
      },
    }.freeze

		# Additional JS modules that don't live in app/frontend/good_job/modules
    MODULE_OVERRIDES = {
      application: GoodJob::Engine.root.join("app", "frontend", "good_job", "application.js"),
      stimulus: GoodJob::Engine.root.join("app", "frontend", "good_job", "vendor", "stimulus.js"),
    }.freeze

    def self.js_modules
      @_js_modules ||= GoodJob::Engine.root.join("app", "frontend", "good_job", "modules").children.select(&:file?).each_with_object({}) do |file, modules|
        key = File.basename(file.basename.to_s, ".js").to_sym
        modules[key] = file
      end.merge(MODULE_OVERRIDES)
    end

    # Necessarly to serve Javascript to the browser
		skip_after_action :verify_same_origin_request, raise: false
    before_action { expires_in 1.year, public: true }

    def static
      render file: STATIC_ASSETS.dig(params[:format].to_sym, params[:name].to_sym) || raise(ActionController::RoutingError, 'Not Found')
    end

    def module
      raise(ActionController::RoutingError, 'Not Found') if params[:format] != "js"

      render file: self.class.js_modules[params[:name].to_sym] || raise(ActionController::RoutingError, 'Not Found')
    end
  end
end