esm アジャイル事業部 開発者ブログ

永和システムマネジメント アジャイル事業部の開発者ブログです。

Rails / OSS パッチ会オンライン 2021年3月のお知らせ

2021年3月の Rails / OSS パッチ会を 3月25日(木)にオンライン開催します。

この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS への upstream にパッチを送る会です。

会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。

開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。Zoom あたりのテレビ会議システムを使います。

当日の招待 URL は Idobata の esminc/rails ルームで共有する予定です。

idobata.io

特に募集ページなど設けませんが、上記理由から Idobata のアカウントが必要になると思います。

以下、前回の活動が関わる成果です。

ima1zumi: rurema/doctree

github.com

osyo-manga: Ruby

github.com

yucao24hours: seory

github.com

先日アナウンスされた RubyKaigi Takeout 2021 に向けた話題などあるかもしれません。

その他の開催方針については以下の Gist に記していますので、ご参照ください。

Reboot Rails/OSS meetup online · GitHub

仕様把握と開発をしやすくするためにコミット時に気をつけていること

こんにちは @color_box です。 チームとしてサービス開発に関わっていると、普段の開発の中で、自分の書いたものではないコードや、数年前に作成されたコードを修正する機会が多くあります。

そのような時に修正しやすいと感じたコミットやそれに関わる有用な心がけを紹介しようと思います。

TL;DR

開発しやすい環境のために下記2つを行う

  • コミットメッセージ内に関連するチケットへのリンクを記載する
  • 1つの修正は1コミットの粒度にして、コミットにテストを含める

前提

特定のコードを修正する時、その修正によって別の不具合が出ないようしなくてはいけません。 そのため、修正対象となるそのコードがなぜそうなっているかを把握する必要があります。 その時参照すべきものとして、コードそのものに加え、その機能の仕様書やテストなどがあります。

しかし、コードからそのような資料を探りづらいと、仕様の把握に時間がかかります。 チケットシステム内を検索したり、チャットの過去ログを漁ったりする必要が出てきます。 そして、そのような調査は時間がかかります。

それらの資料をコードから探せるようになっていると資料検索に使う時間が減ります。 無駄な時間が減り、開発に集中できるため、開発しやすくなります。

そのような開発をしやすい環境のために私がコミット時に心がけている事を書いていきます。

コミットメッセージにチケットへのリンクを書く

このルールはコード(コミット)から、関連資料に到達しやすくなるためのルールです。

git blameで、コードからコミットを辿れます。 その時、コミットメッセージにチケットへのリンクがあれば、機能修正or機能追加時に使用されたチケットを参照しやすいです。

チケット上では仕様変更についての議論が残っています。それらからコードのもととなった仕様の変遷を把握できます。 コードを修正する上で、この情報があると適切な修正や提案を行うことが可能です。

もちろん、コミットメッセージにそういった情報があるのが一番良いのですが、コードの細かい箇所となると、そういった情報がコミットメッセージに載っていないこともあります。 そういう時はチケットまでさかのぼって見に行く必要があります。

ひとつの変更理由は、一つのコミットで

このルールは1つのコミットが特定の1つの修正と紐付いていることを保証するためのルールです。 1つの修正とそれに関連するテストが1つのコミットにまとまっていると、どのテストがどの修正と紐付いているかが明確となります。

機能について理解を深める時、コードを読むのに加えてE2Eテストを読みます。 このルールが守られていると、読むべきテストをコードから探しやすくなります。

テストを仕様理解のための資料として捉え、コードからテストを補足しやすくするためのルールです。


この記事に書いたルールは、下記例外を除いて多くのプロジェクトで機能するルールだと思われます。

  • 仕様に関する議論が対面口頭で行われ、それに関する記録が殆ど残らないようなプロジェクト
  • 仮説検証が目的で、生存期間が短いことが確定している使い捨てプロジェクト

私がプロジェクトで開発しやすい環境にするために心がけているルールを紹介させていただきました。 どなたかのお役に立てば幸いです。

GitHub Actions との距離を縮めるツールたち

試行錯誤しながら何かを作っているとき、ひとつひとつの作業に対するフィードバックに時間がかかるとなかなか捗らないことがあります。特にCI/CDの設定では、リモートのサーバ上で何が起きているのかを把握するのに手間や時間がかかったりして思うようにいかないことがあったりするのではないかと思います。今回は、GitHub Actions の設定をするうえで、手元のマシンでやれることの幅を広げる便利なツールを紹介します。

Act

act を使うことで、手元のマシン上で GitHub Actions のYAMLファイルを読み込んで実行できます。act コマンドを叩くと .github/workflows 以下のYAMLファイルが読み込まれ、定義されている job が Docker コンテナ上で実行されます。act の提供する環境は GitHub Actions と100%互換性があるわけではないのでいくらか注意が必要ですが、すぐに結果が返ってくるので、記述方法を調べつつトライアンドエラーを繰り返す際に役立ちます。またデバッグ用途だけでなく、ローカル用の Makefile を用意する代わりに act を叩くといった task runner 的な使い方もできます。act の素晴らしさについて詳しくはリポジトリの README を確認していただくとして、ここでは act を使ううえで私がつまずいた箇所を中心にいくつかの注意点を紹介します。

ソースコードのチェックアウトに PAT が必要

GitHub Actions で定義する job としては、最初のステップとして actions/checkout でリポジトリからコードを clone してくるというのがよくあるパターンだと思いますが、 actions/checkout は GitHub の personal access token (PAT) に依存しているので、act から使う場合は自分で渡してあげる必要があります。act はデフォルトで .secrets ファイルを secrets として読み込みますので、手軽な方法としてはそのファイルに token を記述しておくことができます。

GITHUB_TOKEN=...

GitHub Actions との違いについて

act がデフォルトで使う Docker イメージには、GitHub Actions の用意する環境で提供されているものが含まれていなかったりします。例えば sudo や Docker が無くて act のときだけ失敗する、といったことが起こりえます。そのため、両方の環境に対応させるためにちょっとした変更が必要な場合があります。act の実行時には ACT という環境変数が設定されるので、それを元に環境ごとに動作を変える、ということが可能です。多用すると見通しが悪くなりそうなので悩ましいですが。

if [ -n "$ACT" ]; then
  # https://docs.docker.com/engine/install/debian/
  # https://docs.docker.com/compose/install/
  curl -fsSL https://get.docker.com | sh -
  curl -L "https://github.com/docker/compose/releases/download/1.28.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
  chmod +x /usr/local/bin/docker-compose
fi

docker-compose build...

別の手段として、より互換性の高い Docker image を使うという手段もあるようです。

User Namespace Remapping を有効にした Docker Daemon について

セキュリティ上の理由や コンテナ上で作られたファイルのパーミッション問題 のために user namespace remapping を有効にして Docker を起動している場合、act を走らせるには --userns=host を渡す必要があります。act は host network mode でコンテナを起動する都合上、 user namespace remapping を利用できません (詳細)。remapping を有効にしたまま act を実行しようとすると、次のような Docker のエラーメッセージが表示されてしまいます。

Error: Error response from daemon: cannot share the host's network namespace when user namespaces are enabled

remapping は、コンテナ作成時に --userns=host を渡すことで一時的に無効にできます。act からも同じオプションを渡せるように パッチを投げました。 取り込まれましたが、まだリリースされていないので、現時点 (2021/03/02) では master のコードをビルドして使う必要があります。

action-tmate

ここでもうひとつ別のツールを紹介します。act は便利な一方、完全な互換性は期待できないので、GitHub の runner 上で直接確認しなければならない場合もあるでしょう。Circle CI や Travis CI みたいに、一時的に SSH でつなげられると便利ですよね。 mxschmitt/action-tmateTmate を使って GitHub Actions の実行環境に SSH 接続する手段を提供します。手元には ssh があれば大丈夫。調査したい箇所の前後でこの action を呼ぶことで、Tmate のセッションが開始されます。

- name: Setup tmate session
  uses: mxschmitt/action-tmate@v3
  if: ${{ always() }}

GitHub Actions ではあるステップが失敗すると、後続のステップはデフォルトでスキップされるので、if: ${{ always() }} をつけておくとよいでしょう。また、この action はデフォルトで sudo を使うので、 sudo のないコンテナ上で呼び出す場合は、sudo: false をオプションとして渡す必要があります。

ちなみに act がデフォルトで提供する環境では、action-tmate が依存しているパッケージが足りなかったりで簡単には動かせそうにありませんでした。とはいえ、act の場合は手元から触れるコンテナ上で実行されるため、目的のコンテナ上でシェルを立ち上げれば済む話で、わざわざ ssh で接続する必要はなさそうです。

おわりに

GitHub Actions の実行環境をより身近にし、開発を助けるツールについて紹介しました。よりよい開発環境づくりのお役に立てれば幸いです。

Ruby組み込みライブラリの型を書くのはそんなに大変じゃなかった

aikyoです。

はじめに

Ruby3.0で、型定義を書けるRBSが導入されました。 私は以前にRubyのFileクラスの型定義を書いたので、Cで書かれたRubyの組み込みライブラリの型定義を書くのもそこまで大変ではないよということについて書いていきます。

現在のRBSの状況

ただ、現在のRBSでは、まだRuby本体に組み込まれているクラスについても型定義が書かれていないものがあります。 なので、型検査をしたいと思ってもRBSに型定義がなければ自分で書くことになります。

Fileクラスの型定義を書いたとき

型定義を書こうと思ったはいいものの。何を参考に型を書くといいのかよくわかりませんでした。現在は TypeProfで型定義を生成してくれたりしますが、正しく推定できない場合があります。 そうなると、やはりソースコードを読んで型定義を書くしかないと思いました。

私はそれまでにRubyのソースコードをほとんど読んだことがなく、Cも詳しくありませんでした。 そのため、Rubyのソースコードを読むのは心理的な抵抗がありましたが、やってみると意外と難しいものではありませんでした。 というのも型定義を書くためには処理を正確に知る必要はなく、関数の引数と戻り値の型がわかれば良いからです。 それであれば型が分かるところまで処理を追うだけで良いのでだいぶ楽でした。

具体例

例として、File.chmod について見ていきます。

File.chmodのドキュメントによると、chmod(mode, *filename) -> Integerのように、第1引数にmode, 第2引数以降にfilenameをとってIntegerを返すようです。

それではRubyのソースコードを見ていきます。なお、Rubyのソースコードは3.0.0を使っています。

/* file.c */
static VALUE
rb_file_s_chmod(int argc, VALUE *argv, VALUE _)
{
    mode_t mode;
    apply2args(1);
    mode = NUM2MODET(*argv++);
    return apply2files(chmod_internal, argc, argv, &mode);
}

第1引数

File.chmod の第1引数が NUM2MODET に渡されています。 NUM2MODETRB_NUM2INT のエイリアスで NUM2INT と同じです。

/* include/ruby/internal/arithmetic/mode_t.h */
#define NUM2MODET RB_NUM2INT

/* include/ruby/internal/arithmetic/int.h */
#define NUM2INT    RB_NUM2INT

NUM2INT はドキュメントに記載があります。https://docs.ruby-lang.org/ja/latest/function/NUM2INT.html NUM2INTFixnumFloatBignum または to_int で型変換できる値をとります。 念の為、さらに処理を追って引数の型を特定してもよいのですが長くなるのでここではこれで止めておきます。

File.chmod の使い方として Float はさすがに除いてよいとして第1引数は Integer または to_int で型変換できるものとなります。 RBSでは、to_int で型変換できるというものが既に定義されています。

# core/builtin.rbs
interface _ToI
  def to_i: -> Integer
end

type int = Integer | _ToInt

これらを使うと、File.chmodの第1引数の型は int とできます。

第2引数

次にFile.chmodの第2引数を見ていきます。

/* file.c */
static VALUE
rb_file_s_chmod(int argc, VALUE *argv, VALUE _)
{
    mode_t mode;
    apply2args(1);
    mode = NUM2MODET(*argv++);
    return apply2files(chmod_internal, argc, argv, &mode);
}

argvをインクリメントしているため apply2files に渡されているのはFile.chmodの第2引数以降となります。 File.chmod の第2引数が apply2files に渡されているのでその定義を見ていきます。 apply2files はここにのせるには長いので、File.chmod の第2引数にあたる argv に関する部分のみのせておきます。

/* file.c */
static VALUE
apply2files(int (*func)(const char *, void *), int argc, VALUE *argv, void *arg)
{
    ...
    for (aa->i = 0; aa->i < argc; aa->i++) {
    VALUE path = rb_get_path(argv[aa->i]);
        ...
    }
    ...
}

File.chmod の第2引数以降を順に rb_get_path の引数として渡していますので、 rb_get_path を見ます。

/* file.c */

VALUE
rb_get_path(VALUE obj)
{
    return rb_get_path_check_convert(rb_get_path_check_to_string(obj));
}

VALUE
rb_get_path_check_to_string(VALUE obj)
{
    VALUE tmp;
    ID to_path;

    if (RB_TYPE_P(obj, T_STRING)) {
    return obj;
    }
    CONST_ID(to_path, "to_path");
    tmp = rb_check_funcall_default(obj, to_path, 0, 0, obj);
    StringValue(tmp);
    return tmp;
}

rb_get_path に渡された引数は rb_get_path_check_to_string に渡されます。 rb_get_path_check_to_string では引数が String ならそのまま、そうでないなら引数に to_pathto_str があればそれを実行して String に変換しています。 これらのことから、File.chmod の第2引数以降は可変長でそれぞれは String または to_pathto_str を持つものとわかります。

戻り値

最後に戻り値の型を考えます。 apply2files については戻り値の部分だけのせておきます。

/* file.c */
static VALUE
rb_file_s_chmod(int argc, VALUE *argv, VALUE _)
{
    mode_t mode;
    apply2args(1);
    mode = NUM2MODET(*argv++);
    return apply2files(chmod_internal, argc, argv, &mode);
}

static VALUE
apply2files(int (*func)(const char *, void *), int argc, VALUE *argv, void *arg)
{
    ...
    return LONG2FIX(argc);
}

chmod の戻り値は apply2files と同じで、 LONG2FIX(argc) の戻り値と同じなので Integer とわかります。

最終的な型定義

結果として以下のような型定義を書くことができました。

def self.chmod: (int mode, *(string | _ToPath) file_name) -> Integer

まとめ

  • Cで書かれたRubyの組み込みライブラリでも型を書くだけなら気にするべきことは多くない。
  • Cに詳しくなくてもなんとかなる。

おわりに

Cで書かれたRubyの組み込みライブラリの型定義を書いたときのことについて紹介してきました。 これを読んだ方が型定義を書くときの参考になれば幸いです。

【Rails 6.1】AS 句で作ったカラムに DB の型情報はない

本記事の環境

  • Rails 6.1.1

結論

9sako6 です。突然ですが、

AS 句で作ったカラムに DB の型情報はありません。

次の例をご覧ください。スキーマに日時型で定義されている created_at カラムは TimeWithZone オブジェクトが返るのに対し、AS 句で作った latest_created_at カラムは文字列が返されます。

> Foo.select('created_at').first.created_at
  Foo Load (0.2ms)  SELECT "foos"."created_at" FROM "foos" ORDER BY "foos"."id" ASC LIMIT ?  [["LIMIT", 1]]
=> Mon, 08 Feb 2021 16:56:10.531831000 JST +09:00 # ActiveSupport::TimeWithZone

> Foo.select('MAX(created_at) AS latest_created_at').first.latest_created_at
  Foo Load (0.3ms)  SELECT MAX(created_at) AS latest_created_at FROM "foos" ORDER BY "foos"."id" ASC LIMIT ?  [["LIMIT", 1]]
=> "2021-02-08 07:56:10.591486"                   # String
# スキーマ
  create_table "foos", force: :cascade do |t|
    t.datetime "created_at", precision: 6, null: false
    t.datetime "updated_at", precision: 6, null: false
  end

さらに、AS 句で作ったカラムは、limit, precision, scale のようなカラム修飾子の情報も持ちません。

この挙動を把握していないと、次のような問題が起こってしまうかもしれません。

  • Rails アプリに設定したタイムゾーンではなく、DB のタイムゾーンで日付が表示される

なぜこの挙動になるのかに興味のある方は以降のおまけをご覧ください。

おまけ: コードリーディング

次のコードを実行したとき、なんのメソッドが呼ばれるか追っていきます。

# DB からデータを取ってくるフェーズ
foo = Foo.select('created_at, created_at AS created_at_clone').first 

# 値を取得するフェーズ
foo.created_at_clone                                                 

その過程で、AS 句で作ったカラムに型情報がつかない理由もわかります。 スキーマにないカラムはデフォルトで ActiveModel::Type::Value 型になるから、です。

※ 記事中で書いた foos テーブルが定義されているものとします。

環境

  • Rails 6.1.1
  • SQLite3

DB からデータを取ってくるフェーズ

Foo.select('created_at, created_at AS created_at_clone').first で何が起こるかを追っていきます。

select メソッドから始まり、おおよそ次の順に呼ばれていきます。

ActiveRecord::ConnectionAdapters::DatabaseStatements#select

ActiveRecord::ConnectionAdapters::SQLite3::DatabaseStatements#exec_query

ActiveRecord::ConnectionAdapters::AbstractAdapter#build_result

ActiveRecord::Result#initialize

次に、select の戻り値 Foo::ActiveRecord_Relation のインスタンスに対して first メソッドから次の順に呼ばれていきます。

ActiveRecord::FinderMethods#first

ActiveRecord::FinderMethods#find_nth

ActiveRecord::FinderMethods#find_nth_with_limit

ActiveRecord::Relation#to_ary

ActiveRecord::Relation#records

ActiveRecord::Relation#load

ActiveRecord::Relation#exec_queries

これが Foo のインスタンスを返します。上記の ActiveRecord::Relation#exec_queries の中で呼ばれる ActiveRecord::Querying#find_by_sql の中の ActiveRecord::Persistence::ClassMethods#instantiate_instance_offoo (Foo のインスタンス)のインスタンス変数 @attributes に DB からとってきたデータや型情報を格納しています。

ActiveRecord::Querying#find_by_sql

ActiveRecord::Persistence::ClassMethods#instantiate_instance_of

ここまでが DB からデータを取ってくるフェーズです。

まとめると、DB からとってきたデータやカラムの型情報などをfoo ( Foo インスタンス)のインスタンス変数 @attributes に格納しました。

@attributes は以下のようになっています。

> pp Foo.select('created_at, created_at AS created_at_clone').first.instance_variable_get(:@attributes)
  Foo Load (0.4ms)  SELECT created_at, created_at AS created_at_clone FROM "foos" ORDER BY "foos"."id" ASC LIMIT ?  [["LIMIT", 1]]
#<ActiveModel::LazyAttributeSet:0x00007feb86be6788
 @additional_types={},
 @attributes={},
 @casted_values={},
 @default_attributes=
  {"id"=>
    #<ActiveModel::Attribute::FromDatabase:0x00007feb82d6a9c8
     @name="id",
     @original_attribute=nil,
     @type=
      #<ActiveRecord::ConnectionAdapters::SQLite3Adapter::SQLite3Integer:0x00007feb8662a470
       @limit=nil,
       @precision=nil,
       @range=-9223372036854775808...9223372036854775808,
       @scale=nil>,
     @value_before_type_cast=nil>},
 @materialized=false,
 @types=
  {"id"=>
    #<ActiveRecord::ConnectionAdapters::SQLite3Adapter::SQLite3Integer:0x00007feb8662a470
     @limit=nil,
     @precision=nil,
     @range=-9223372036854775808...9223372036854775808,
     @scale=nil>,
   "created_at"=>
    #<ActiveRecord::Type::DateTime:0x00007feb82d6b378
     @limit=nil,
     @precision=6,
     @scale=nil>,
   "updated_at"=>
    #<ActiveRecord::Type::DateTime:0x00007feb82d6b378
     @limit=nil,
     @precision=6,
     @scale=nil>},
 @values=
  {"created_at"=>"2021-02-08 07:56:10.531831",
   "created_at_clone"=>"2021-02-08 07:56:10.531831"}>

値を取得するフェーズ

foo.created_at_clone で何が起こるかを追っていきます。 まず、ActiveModel::AttributeMethods#method_missing が呼ばれます。

ActiveModel::AttributeMethods#method_missing

    def method_missing(method, *args, &block)
      if respond_to_without_attributes?(method, true)
        super
      else
        match = matched_attribute_method(method.to_s)
        match ? attribute_missing(match, *args, &block) : super
      end
    end

次に、以下のメソッドが呼ばれます。

ActiveModel::AttributeMethods#attribute_missing

    def attribute_missing(match, *args, &block)
      __send__(match.target, match.attr_name, *args, &block)
    end

このとき、match.target'attribute'となっており、attributeメソッドが呼ばれます。 attributeメソッドの定義は ActiveRecord::AttributeMethods::Read#_read_attribute にあります。

ActiveRecord::AttributeMethods::Read#_read_attribute

      def _read_attribute(attr_name, &block) # :nodoc
        @attributes.fetch_value(attr_name, &block)
      end

      alias :attribute :_read_attribute
      private :attribute

次に呼ばれるのが fetch_value です。この fetch_value の戻り値が foo.created_at_clone の戻り値になります。

ActiveModel::LazyAttributeSet#fetch_value

  class LazyAttributeSet < AttributeSet # :nodoc:
    ...

    def fetch_value(name, &block)
      if attr = @attributes[name]
        return attr.value(&block)
      end

      ...

name'created_at_clone' です。attr = @attributes[name] に、created_at_clone カラムのデータをインスタンス化したものが格納されています。 そして、attr.value(&block) が、foo.created_at_clone として返ります。

ん...?ちょっと待ってください! 前節、「DB からデータを取ってくるフェーズ」で最後に記載した @attributes をもう一度思い出してみます。 前節で登場した @attributesfoo のインスタンス変数であり、 LazyAttributeSet のインスタンスです。

よく見ると、@attributes 自身もインスタンス変数 @attributes を持っています。そしてその中身は空の Hash です。

#<ActiveModel::LazyAttributeSet:0x00007feb864a16a8
 @additional_types={},
 @attributes={},       # HERE!!!
 @casted_values={},
 @default_attributes=
  {"id"=>
    #<ActiveModel::Attribute::FromDatabase:0x00007feb82d6a9c8
     @name="id",
     @original_attribute=nil,
     @type=
      #<ActiveRecord::ConnectionAdapters::SQLite3Adapter::SQLite3Integer:0x00007feb8662a470
       @limit=nil,
       @precision=nil,
       @range=-9223372036854775808...9223372036854775808,
       @scale=nil>,
     @value_before_type_cast=nil>},

 ...

話を戻します。

  class LazyAttributeSet < AttributeSet # :nodoc:
    ...

    def fetch_value(name, &block)
      if attr = @attributes[name]
        return attr.value(&block)
      end

      ...

ここで登場した @attributes は、前節で登場した @attributes のインスタンス変数です。つまり、foo.instance_variable_get(:@attributes).instance_variable_get(:@attributes) です。 そして、中身は空でした。

fetch_value@attributes[name] すると値は取れるので、どこかで値を格納しているはずです。

値の格納は、一番最初に呼ばれた method_missingmatched_attribute_method(method.to_s) で行われます。次の流れです。

ActiveModel::AttributeMethods#matched_attribute_method

ActiveRecord::AttributeMethods::PrimaryKey#attribute_method?

ActiveRecord::AttributeMethods#attribute_method?

ActiveModel::LazyAttributeSet#key?

ActiveModel::AttributeSet#[]

ActiveModel::LazyAttributeSet#default_attribute

      def default_attribute(
        name,
        value_present = true,
        value = values.fetch(name) { value_present = false }
      )
        type = additional_types.fetch(name, types[name])

        if value_present
          @attributes[name] = Attribute.from_database(name, value, type, @casted_values[name])

        ...

@attributes[name] = Attribute.from_database(name, value, type, @casted_values[name]) で値が格納されます。

typecreated_at_clone カラムの型です。types['created_at_clone'] が格納されます。

types は前節の @attributes のもつインスタンス変数 @types です。つまり、foo.instance_v ariable_get(:@attributes).instance_variable_get(:@types) です。

前節で @attributes が設定された際に @types も初期化されました。DB のもつカラムである id, created_at, updated_at の型情報が格納されています。

@types はただの Hash ですが、デフォルト値が ActiveModel::Type::Value のインスタンスになっています。スキーマにない 'created_at_clone' カラムの型は ActiveModel::Type::Value になるというわけです。

ちなみに、id の型は ActiveRecord::ConnectionAdapters::SQLite3Adapter::SQLite3Integercreated_at の型は ActiveRecord::Type::DateTime です。

以降、次のように呼ばれます。

ActiveModel::Attribute.from_database

ActiveModel::Attribute#value

ActiveModel::Attribute::FromDatabase#type_cast

ActiveModel::Attribute::FromDatabase#type_cast の戻り値が foo.created_at_clone です。

        def type_cast(value)
          type.deserialize(value)
        end

typeActiveModel::Type::Value が入るのでしたね。この deserialize メソッドは型ごとに定義されており、データベースから得た値を Ruby 型に変換します。

ActiveModel::Type::Valuedeserialize は、引数 value をそのまま返すメソッドです。 というわけで、foo.created_at_clone は文字列として返ります。

ActiveModel::Type::Value#deserialize

      def deserialize(value)
        cast(value)
      end

ActiveModel::Type::Value#cast

      def cast(value)
        cast_value(value) unless value.nil?
      end

ActiveModel::Type::Value#cast_value

        # Convenience method for types which do not need separate type casting
        # behavior for user and database inputs. Called by Value#cast for
        # values except +nil+.
        def cast_value(value) # :doc:
          value
        end

以上です。お疲れ様でした。

おまけのおまけ: コードを読んだ際の手の動き

EDITOR=code bundle open activerecord で、ランタイムで実際に動いている gem のコードを開きます。

明らかに呼ばれそうなメソッドに byebug を仕込み、up, down コマンドでスタックフレームを移動しながら呼ばれるメソッドを追います。これを繰り返します。

他にヒントが欲しければ Method#source_location で調べます。

最後に gem pristine activerecord して自分の編集箇所を残さないように掃除します。


永和システムマネジメント アジャイル事業部は Ruby とアジャイルの精鋭集団です。

一緒に働くことに興味をもってくださった方、ぜひ一度お話してみませんか!

agile.esm.co.jp

Rails / OSS パッチ会オンライン 2021年2月のお知らせ

2021年2月の Rails / OSS パッチ会を 2月25日(木)にオンライン開催します。

この会をひとことでいうと、日頃のお仕事で使っている Rails をはじめとする OSS への upstream にパッチを送る会です。

会には Ruby と Rails のコミッターである顧問の a_matsuda もいますので、例えば Rails に送るパッチのネタがあるけれど、パッチを送るに適しているかの判断やパッチを送る流れが悩ましいときなど a_matsuda に相談して足がかりにするなどできます。

開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。Zoom あたりのテレビ会議システムを使います。

当日の招待 URL は Idobata の esminc/rails ルームで共有する予定です。

idobata.io

特に募集ページなど設けませんが、上記理由から Idobata のアカウントが必要になると思います。

以下、前回の活動が関わる成果です。

koic: RuboCop

github.com

okuramasafumi: Audited

github.com

osyo-manga: Ruby

github.com

yahonda: activerecord-oracle_enhanced-adapter

github.com github.com

昨年末にリリースされた Ruby 3.0、Rails 6.1 の実プロジェクトへの導入状況や、開発版となる Ruby 3.1 や Rails 7.0 に向けた話題などあるかもしれません。

その他の開催方針については以下の Gist に記していますので、ご参照ください。

Reboot Rails/OSS meetup online · GitHub

BuriKaigi2021 で Emoji の話をしました

はじめに

はじめまして。 @ima1zumi と申します。2021 年 1 月に株式会社永和システムマネジメントに中途入社しました。好きな gem は Relineirb で、最近は文字コードに興味を持っています。どうぞよろしくお願いします。

さて、先日オンラインで開催された BuriKaigi2021 で Unicode Emoji の話をしました。Emoji についてはスライドを読んでいただくとして、ここでは BuriKaigi で Emoji の話をした経緯と準備について書きました。

この記事を書くにあたり、 kasumi8pon から「ima1zumi さんが普段どのようなことを考えているのか分かるような記事になっているとよいですね」とアドバイスをいただきました。そこで発表するまでにどのような準備をしたのか、何を考えていたのか、に焦点を当てて書いてみました。この記事が何かを発表する方の参考になれば幸いです。

BuriKaigi とは

富山のおいしいもの(鰤など)を食べながらITに関することを勉強する会です。 .NET, Java, Ruby などさまざまな言語のセッションがあります。懇親会でおいしいぶりしゃぶを食べることで有名です。 毎年富山県で開催されていますが、今年は新型コロナウイルスの影響でオンラインでの開催となりました。

【オンライン開催】Burikaigi2021 - connpass

f:id:imaizumimr:20210203172146p:plain

ちなみに、懇親会参加者向けに冷凍ぶりしゃぶセット(有料)の案内もありました。豪華ですね!

登壇するきっかけ

BuriKaigi の 6 日前に知人から「 BuriKaigi の登壇枠が空いているので登壇しませんか?」と誘っていただきせっかくなので話すことにしました。本来は 30 分の枠でしたが、準備期間が短いため 15 分枠なら登壇できそう、ということで調整していただき登壇が決まりました。

テーマ選定

登壇する時に、私は以下のような内容で何か話せないか?という観点でテーマを考えています。

  • 最近学んだこと・わかったことで面白く感じていること
  • ハマったことと解決方法
  • 登壇をゴールに開発する・調べる*1
  • 自分の経験をまとめる

また、そのテーマを選んだときにどれだけ情熱を持って話せるか、何か伝えたいことがあるのかという点を重視しています。 テーマについてよく知っていたり語りたいことがあると、モチベーションが上がります。モチベーションが高いと準備も捗りますし、話にも熱が入りいい話になるのではないかと思っています。

具体的なテーマ選定

例えば今回の場合はこのように考えていました。

  • 文字コードや Emoji の話は Reline を通して学んだため少し知見があるし面白いと思っている
  • Ruby の String の話もしたいが、 Ruby ユーザー以外も多く参加するのであまり合わないかもしれない
  • Reline の概要はどこかで話したいが、しっかり準備したいので今回は難しそう

これらのテーマを候補として考えつつ、BuriKaigi にどういう参加者が集まるのか、他の方がどういうテーマで話すのか運営の方に聞いてみました。 Ruby 以外の言語を使う人も多いことと、マニアックな話は歓迎ということでした。それなら Emoji の話が良さそうだと思い Emoji の話をすることにしました。

テーマの深堀り

まだまだスコープが粗い状態なのでもう少し具体的な内容を考えます。

最初はざっくりと何を話すか考えました。LT では何度か登壇したことがあるので、5 分 x 3 本ならどんなことを話せるかというイメージで決めていきました。

例えば今回は、5 分ずつ以下のテーマで話せそうだと思いました。

  • Emoji の歴史
  • よく問題になる Emoji
  • Emoji の仕様

その後もう少し肉付けして、

  • Emoji に興味を持ったきっかけ
    • Reline
  • Emoji の歴史・前提
    • エモティコン、顔文字
    • ドコモの Emoji
    • Unicode に入って普及
    • どんどん増える Emoji
    • Emoji の特徴
    • 書記素
  • よく問題になる Emoji
    • ZWJ
    • SKINTONE
    • REGIONAL
    • VALIATION
    • KEYCAP
  • Emoji の仕様
    • Unicode の technical standard
    • Emoji テーブル
    • Emoji 採択のプロセス
  • Emoji は面白い!

こういう内容で話そう、と仮決めしました。

スライドを作る

上の箇条書きをもとに、スライドを作っていきます。

スライド作成ツール

私はよく reveal.js を使っています。 Markdown で書けるので、さっと書けて書き心地がよいです。公式ドキュメントが充実しているため、こういうことをしたいときにはどうすればいいんだろう?と思ったときに迷わなくてよいので便利です。

revealjs.com

スライド作成と練習

私は初稿は思うまま書いて、後から修正を繰り返してブラッシュアップしていくスタイルです。最初は自分の素直な言葉でスライドを書いていきます。口語になっていたり、よくわからなくてもとりあえず言葉に起こしていきます。

途中で筆が止まったら一旦声に出して読んでみて構成におかしな点がないか、時間がどれくらいかかるか確かめます。 今回は 2/3 くらい書いたところで筆が止まったので、一旦声に出してみることにしました。すると思ったより時間がかかることがわかり、Emoji の仕様に関するスライドは作らないことにしました。

声に出して読み上げると、スライドに書いてある構成では話の流れがおかしい、というところがわかります。私はその場でアドリブで話を組み立てるのは苦手なので、スライドを見て読み上げれば自然と構成が正しくなるように、脱線しないように意識してスライドを書いています。そのため、一旦完成したら声を出して読みながら違和感があるところを修正する、を繰り返しながら仕上げていきます。

また、これは実践できていないことも多いのですが、スライドの情報だけ見て理解できるような要約を書くことも意識しています。そのようなスライドは、イベントが終わった後に参照しても役に立つからです。音声で補足しないと伝わらない情報があれば、できるだけ文字に書き起こすようにしています。

発表前にやること

オンライン登壇の発表前にやっていることです。

  • 画面共有できることを確認
    • 全画面を共有する場合、通知や映ってはいけないものが映らないように設定
      • Slack, Discord などを停止する、おやすみモードにする
      • ブラウザで共有する場合、ブックマークバーを非表示にする
  • マイクの音量を確認
  • カメラを確認
  • インターホンの音量を下げる、止める
  • ストップウォッチを準備
  • スライドをアップロードする
  • スマートスピーカーを切る

私は Amazon Echo Dot をデスクの上に置いているのですが、本番中に Alexa が桃太郎の解説を始める*2というトラブルがあり非常に焦りました。スマートスピーカーは本番前に止めておきましょう。

発表中にやること

ストップウォッチを見ながら時間を調整しつつ話します。

余裕があるときは Twitter やチャット欄を見ながら話しますが、余裕がない時はスライドに集中します。今回は練習量が足りず緊張していたので、スライドの他は何も見ず話していました。

発表後にやること

スライドを公開します。Twitter でイベントのハッシュタグをつけて tweet することが多いです。connpass でのイベントの場合はイベントページに資料のリンクを貼れるのでそちらからも貼ります。

発表を終えてみて

発表前は、15分聞いていただけるだけの内容にできるかとても不安でした。ですがなんとかまとまった内容を発表できてよかったです!スライドを作るにあたり Unicode の technical standard を読んで学んだり、Emoji の歴史について知ることができて良かったです。 Emoji への知識と愛がより深まりました。反省点としては、準備時間が足りず用語の使い方が怪しいところがあったことです。普段から正確な言葉を使えるよう意識していきたいです。

このようなしっかりした場で発表するのは初めてでしたが、なんとか無事終えることができました。誘ってくださった方、こんな機会をくださった BuriKaigi 運営のみなさま、ありがとうございました!いつかぶりしゃぶを食べに富山に行きたいです🐟

*1:いわゆる登壇駆動開発

*2:なぜ桃太郎なのかは不明