DEV Community: toooooooooomy

The introduction of Feature Flag into your system

toooooooooomy — Tue, 13 Jul 2021 11:53:57 +0000

Introduction

Feature Flag is a well-known technique to modify system behaviour without changing code.
As of today, besides Martin Fowler's blog, we have a lot of posts and youtube videos to know how Feature Flag looks like.
However, if you'd like to introduce it into the system, probably you will face some issues to consider and discuss to develop your own Feature Flag.

In this article, I am going to address what came up as the issues in front of my team, and show how I lead the first version of Feature Flag of the company with the Rails code example.

Feature Flag of a team or a company?

My company has several backend teams and frontend teams. So the first question is, each team can have its Feature Flag system or not?
The decision was NO at that time. Why it is better to have a unified, centralized Feature Flag system as a company? That is because it becomes out of our control soon if we have multiple flagging system.
For instance, let's assume we develop a new feature A by team 1 and team 2. If we have an independent Feature Flag system, we should make sure both A's flags are in a correct status in both of team 1 and team 2 Feature Flag system. But, what if we have feature B simultaneously? What if team 3 is also involved? Easily variables would increase right after starting the operation.
However, this decision has also a drawback. Once a certain team starts creating Feature Flag Service, other teams should wait until the team provides API to use Feature Flag.

What toggles should be included in the first version?

When you hear the word, Feature Flag, what comes up in your mind? It enables us to do the A/B test. It works like a circuit breaker. It provides premier features to limited users, etc.
Yes, if we say Feature Flag, it has a variety of features to be implemented. Especially if people have experienced to use sophisticated Feature Flag system like LaunchDarkly, the ideal Feature Flag would have rich functions.
To take a step forward, let's think the first implementation as simple as possible.
As mentioned in this article, it is better to focus on "Release Toggle" to allow deploying on-going code into production. Release Toggle enables us to deploy in-progress code into production. It reduces long held feature branches in your codebase.

How Release Toggle looks like

Let's see a simple implementation of Feature Flag which implements Release Toggle.

class FeatureFlag
  def self.enabled?(feature_name)
     case feature_name
     when 'awesome-feature'
        true
     else
        true
     end
  end
end

The simplest example would be like this, but it seems not practical to operate the real-world application. So, what should be considered to introduce it into our application?

1. Default return value

Else block of the above example is the default value that would be returned if the specified feature name doesn't exist. In this case, should we return true or false? Or, better to raise the exception?

The purpose of Feature Flag, especially Release toggle, is to make Deploy and Release independent. From that aspect, the codebase won't need to know what kinds of feature flags are defined. Meaning we should not raise the exception because the non-existence of a specified feature flag is not the exception. Further, it would be better to return false than true because in most cases, we would use a feature flag when we want to launch a new feature. If so, when the specified feature flag doesn't exist, nothing happens would be a preferable behaviour. Given that, returning false is safer to operate the real world application.

2. The number of flags

Feature Flag is magic. Once it is introduced into the product, everyone uses it to make their work easy. Eventually, there would be tens or hundreds of flags and our Feature Flag would be out of control. To prevent the worst-case scenario, having a limitation for the number of flags is a good practice. 5-10 would be a good start!

3. How to manage the flags

As you see in the example, hard-coding flags into the ruby file look not practical. What would be good to set them up then? RDB seems reasonable, they are reliable, add/delete operation is easy, and it's needed if we make UI. But this is the very first version of Feature Flag. Maybe we would expand what Feature Flag can do in near future. Given that, we want to avoid over-technology. From that aspect, YAML would be a good candidate to manage flags. And if that YAML file loaded during booting up the app, seems great. We can make it easy by using Rails legacy.

How the practical FeatureFlag looks like

Following the above aspects, let's refactor the code.

feature_flag.rb

class FeatureFlag
  def self.enabled?(feature_name)
    if @features.key?(feature_name.to_s)
      @features[feature_name.to_s]
    else
      false
    end
  end

  def self.load
    @setting = YAML.safe_load(File.read(config.setting_path))
    @features = @setting['features']

    raise "The number of flags is limited to #{config.feature_limit}" if @features.count > config.feature_limit
  end

  def self.config
    @config ||= Config.new
  end

  def self.configure
    yield config
  end

  class Config
    include ActiveSupport::Configurable

    config_accessor :setting_path do
      ''
    end

    config_accessor :feature_limit do
      0
    end
  end
end

config/initializers/feature_flag.rb

FeatureFlag.configure do |config|
  config.setting_path = Rails.root.join('config', 'feature_flag.yml')

  config.feature_limit = 5
end

FeatureFlag.load

config/feature_flag.yml

features:
  awesome-feature: true

Looks way practical, doesn't it?

What's next?

You would have two dimensions to expand this Feature Flag. 1. Adding new Toggles and 2. providing API for other teams. We now have the exact example as the code. It would make clear what we should do next, what we can, how long it would take. That enables to involve non-developers into the discussion!

Conclusion

Feature Flag is a very useful, powerful feature and it's discussed for a long time. However, there are few examples if you want to refer to implement your own Feature Flag.
Hope this article helps to solve your concerns, and can earn the huge benefits of FeatureFlag!

Work with Production Data Deletion

toooooooooomy — Mon, 15 Mar 2021 13:01:01 +0000

Introduction

The working process of production data deletion is completely different from development tasks.
We should take it as another kind of task, and think with another way. The coding examples are based on RoR in this article.

Estimate the workload

It is difficult to estimate without investigation to work through data deletion.
I can say, do not estimate via the usual development style estimation process.
As a rough estimation, it could take 2 weeks at least to complete the whole process.
Because we should answer the questions listed below in advance.
Furthermore, performance could be a problem after you finish up writing code.
I do recommend doing a sensitive investigation, discuss it with all involved people including QA developers before start working on it.
It would be the fastest way.

Questions we should answer before start coding

How much data do we have to delete?
How can we test the deletion?
What is the data to delete?
How many related resources belong to target data?
How can we estimate the deletion time?
Can we have an alternative approach if it's difficult to delete the whole data?

General coding tips to handle huge data to delete

I show the example via Ruby on Rails(RoR) code but it would be able to translate to other languages easily.
Let's say, you are working with an E-commerce app and we have orders, and order_items belong to each order.

Avoid N+1

Do not iterate all associated relations

If the target data amount is huge, using iteration could be a cause of a terrible performance problem.

Order.where(user_id: 10).all.each do |order|
  order.order_items.each do |order_item|
     ...
  end
end

In this example, if the order amount is millions, this leads significant N+1 problem.
We should consider the way not to use ORM magics.

Use delete_all instead of destroy_all

In RoR, there are basically 2 methods to delete records, delete and destroy. destroy methods calls callbacks defined on a model before deleting the object. On the other hand, delete doesn't see callbacks set up on the model, simply calling a delete SQL.
Given that, delete_all is way faster than destroy_all, and it makes a significant performance difference if the data is big.
And, it means we should take care of the operation we defined in the before_destroy or after_destroy callbacks manually.

Use batches

If it comes to delete even thousands of records, we should handle it carefully to use database resources sufficiently. Probably simply calling delete_all is not enough.
In that case, use something like built-in method find_in_batches or delete_in_batches gem.
The batch size should be around some thousands to prevent DB stuck. In find_in_batches, default is 1,000. In delete_in_batches, default is 10,000.

Order.find_in_batches(batch_size: 5000).each do |orders|
  orders.delete_all
  sleep(1) # throttle down DB
end

Set asleep to throttle down the DB

Like the above example, looks good to throttle down by using sleep in batches when we delete in batches. The RoR official website recommends it.

When the deletion is quite slow

Possibly you couldn't find this problem until using the full prod pruned data. That is why using prod pruned data is important.
Anyhow, in many cases, the cause of the slow query is full table scan due to no index as you know.

Case 1: No index on the column used in where SQL

DELETE users where email = 'something@localhost';

SQL tries to look for target records by email but there is no index on email so that it does a full table scan. It is simple and you are probably familiar with it.

Case 2: No index on the column to use constraint check

DELETE addresses;

                  Table "addresses"

   Column  | Type |     Modifiers
-----------+------+------------------------------
 id        | int  | not null default nextval(...
 street_no | int  | not null
.
.
.
Indexes:
    "idx_primary" PRIMARY KEY, btree (id)
Referenced by:
    TABLE "users" CONSTRAINT "fk_users_addresses" FOREIGN KEY (address_id) REFERENCES addresses(id) NOT VALID

                  Table "users"
    Column   |  Type  |         Modifiers
-------------+--------+--------------------------------
 id          | bigint | not null default nextval(...
 address_id  | int    |
.
.
.
Indexes:
    "idx_primary" PRIMARY KEY, btree (id)
Foreign-key constraints:
    "fk_users_addresses" FOREIGN KEY (address_id) REFERENCES addresses(id) NOT VALID

SQL tries to delete addresses but addresses referenced by users table, and it has a foreign key constraint on address_id. But because address_id does not have index, SQL does a full table scan for users when deleting addresses

When we need further consideration

If the target data has a lot of associations, we should consider deleting some of them tentatively.
For example, an order has some order_items, purchaced_users, addresses, items, etc...
But in this case, we will create orphan data which doesn't have the parent data(i, e. relations of orders and order_items, deleting only orders)
This would be tech debt, so when we take this solution, we should have common sense with the people involved.

Create to_be_deleted tables

To delete only required data and delete orphan data in the future, consider creating "to_be_deleted" tables which have ids of target data to be deleted. Those tables look like below.

-- orders_to_be_deleted
Table "orders_to_be_deleted"
  Column  |  Type   | Modifiers
----------+---------+-----------
 order_id | integer | not null
Indexes:
    "index_orders_to_be_deleted_on_order_id" btree (order_id)

By using these id tables, we can refer to deleted ids after deleting orders themselves for example.

Create a DB backup before starting the deletion

Thanks for this tip Raphael!
No matter how careful we prepare, unexpected situations always come in front of us. Make sure you can have the backup with your team.

Conclusion

Those are what we should consider when deleting data.
I'm glad if someone won't do the same mistakes as mine when working on data deletion projects.

Initialize Money::Currency on the test context

toooooooooomy — Sun, 11 Oct 2020 02:16:55 +0000

RubyMoney is a great gem to handle real-world money.
It provides the default setting, and we can overwrite it via business requirements.
On the production environment, if we set the setting up once(it could be in the initializer), no need to update it in many cases.
However, it could happen in the test context.

In this article, I explain how RubyMoney manages the currency setting and how to initialize it when we need it.

First of all, we can set the customized currency as below

cad = Money::Currency.find(:cad)

cad.name # => Canadian Dollar

Money::Currency.register(
  :priority            => cad.priority,
  :iso_code            => cad.iso_code,
  :name                => 'Something Different',
  :subunit             => cad.subunit,
  :subunit_to_unit     => cad.subunit_to_unit,
  :thousands_separator => cad.thousands_separator,
  :decimal_mark        => cad.decimal_mark
)

cad = Money::Currency.find(:cad)
cad.name # => Something Different

Money::Currency manages the currency setting as an instance variable called @table, then it should be ok to reset the instance variable.
But it provides the interface to access the table as a class method so that we should be able to reset the table like

 Money::Currency.instance_variable_set('@table', nil)
 Money::Currency.table # => reloading the initial setting

See? How easy it is! But wait, we still keep getting the overwritten setting.

cad = Money::Currency.find(:cad)
cad.name # => Something Different
Money::Currency.instance_variable_set('@table', nil)
Money::Currency.table
cad = Money::Currency.find(:cad)
cad.name # => Something Different. We still get the overwritten name!

Why does that happen?
That is because, if it is overwritten once, that setting should have consistency through a ruby process.
To handle it, the library manages the setting as a class variable, so that we do not need to care about the currency setting any more to develop the app.
Given that, we should initialize that class variable like below.

cad.name # => Something Different
Money::Currency.class_variable_set('@@instances', {})
Money::Currency.instance_variable_set('@table', nil)
Money::Currency.table
cad = Money::Currency.find(:cad)
cad.name # => Canadian Dollar

Yay! If you write it on the spec_helper or something, your tests don't depend on Money::Currency context.

The latest master of RubyMoney::Money provides API, Money::Currency.reset! to handle it!
This link is the PR of this feature.
If anyone wanna use it, pull the latest master, and there you go.
I hope the next version of RubyMoney::Money includes this update!

Be more sophisticated with Enumerable

toooooooooomy — Wed, 09 Sep 2020 03:17:09 +0000

What is Enumerable?

The Enumerable mixin provides collection classes with several traversals and searching methods, and with the ability to sort. The class must provide a method each, which yields successive members of the collection.

https://ruby-doc.org/core-2.7.1/Enumerable.html
Simply, Classes which have each method like Array, Hash, and String have Enumerable methods

Find code which uses each, consider using Enumerable methods

If you see the code which uses each, potentially you can re-write the procedure without using it. Try to look for it if you think up some parts of your codebase.
Furthermore, utilize appropriate Enumerable method makes your code sophisticate. Let's see and learn with the exact examples which I've ever seen.

Usecases

Case 1: select

Before

arr = [1, 2, 3, 4, 5]
new_arr = []
arr.each do |v|
  new_arr << v if v.odd?
end

p new_arr # => [1, 3, 5]

After

new_arr = arr.select(&:odd?)

p new_arr # => [1, 3, 5]

Case 2: map

Before

arr = [1, 2, 3, 4, 5]
new_arr = []
arr.each do |v|
  new_arr << v * 2
end

p new_arr # => [2, 4, 6, 8, 10]

After

new_arr = arr.map { |v| v * 2 }

p new_arr # => [2, 4, 6, 8, 10]

Case 3: inject

Before

arr = [1, 2, 3, 4, 5]
sum = 0
arr.each do |v|
  sum += v
end

p sum # => 15

After

arr = [1, 2, 3, 4, 5]
sum = arr.inject(:+)

p sum # => 15

Case 4: any?

Prerequisite

booking_statuses are defined as below and intend to validate the status transition

booking_statuses = {
  pending: 0,
  payment_requested: 1,
  paid: 2,
  cancelled: 3
}

Before


def validate_booking_transition(passed_status)
  if passed_status == booking_statuses[:cancelled]
    allowed = [
      booking_statuses[:pending],
      booking_statuses[:payment_requested],
      booking_statuses[:paid]
    ].include?(passed_status)
  elsif ...
  .
  .
  .
end

After

def validate_booking_transition(passed_status)
  if passed_status == booking_statuses[:cancelled]
    allowed = %i(pending payment_requested paid).any? do |v|
      passed_status == booking_statuses[v]
    end
  elsif ...
  .
  .
  .
end

Case 5: group_by

Before

arr = [{code: 'a', val: 1}, {code: 'a', val: 2}, {code: 'b', val: 3}, {code: 'b', val: 4}]
new_hash = {}
arr.each do |hash|
  k = hash[:code]
  new_hash[k] = [] if new_hash[k].nil?

  new_hash[k] << hash[:val]
end

p new_hash #=> {"a"=>[1, 2], "b"=>[3, 4]}

After

new_hash = arr.group_by { |h| h[:code] }.transform_values { |grouped_arr| grouped_arr.map { |h| h[:val] } }

p new_hash #=> {"a"=>[1, 2], "b"=>[3, 4]}

Consideration

Look at each use-case. Case 1-3 are general Enumerable methods' introduction.
Case 4 shows us utilizing appropriate Enumerable methods would be able to express what we intend to.
So, what can say about Case 5? Does it look smarter than before? Or it became more complex?
Let's see more details about each case.
In the loop,

Case 1: Extract params which fit the condition
Case 2: Multiply 2 to each param
Case 3: Sum up the params
Case 4: Check there are any params which fit the condition

From that, we can say they proceed 1 procedure within the loop.
The difference of Case 5 compared with others, is it does several procedures within the iteration.
They are

Generate a hash which has code as key
Generate val array per hash key

Furthermore, it executes map within transform_values method. It made the situation worse -- yes, from the Calculate order aspect, it generates a dual-loop from a single loop.
So that we can say, if we should handle several procedures within a single iteration, each could have initiative from both Calculation Order and Readability aspects.

Re-think the pros of using Enumerable methods

We can describe our intention more clearly by appropriate Enumerable methods rather than each.
And in many cases, readability and maintainability are the most important policy. So why not using it?
And if you aren't familiar with functional programming, it even could be a good opportunity to think about side effects.
But, as I demonstrate by Case 5, each could be the best approach after all. Make sure you do not generate nested iterations by refactoring.

Conclusion

Enumerable makes your programming fun. Enjoy!
In Japanese