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

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

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

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

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

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

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

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

idobata.io

特に募集ページなど設けませんが、上記理由からすでに Idobata のアカウントを持っている方は、当日の案内を Idobata にてご確認ください。 また Idobata はクローズ化されているため Idobata アカウントを持っていない参加希望の方は、@koic までメンションしてください。

パッチ会では、来月開催の RubyKaigi Takeout 2021 に関する話題などあるかもしれません。

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

Reboot Rails/OSS meetup online · GitHub

RubyKaigi Takeout 2021 に永和システムマネジメントから @koic と @ima1zumi が登壇します

2021年9月9日(木) から11日(土) の3日間にわたって開催される RubyKaigi Takeout 2021 に永和システムマネジメントから @koic (Day 1) と @ima1zumi (Day 3) が登壇します。

rubykaigi.org

ここでは、それぞれの登壇スケジュールと講演内容について軽く紹介します。

9月9日(木) 11:30-11:55 @koic 『RuboCop in 2021: Stable and Beyond』

2020年10月に RuboCop 1.0 がリリースされておおよそ1年が経過しようとしています。

前回の RubyKaigi Takeout 2020 では日々の OSS 活動のうち、RuboCop 1.0 への道のりからテーマを抽出したことに対して、今年は RuboCop 1.0 以降の RuboCop 開発で行っていることからテーマを抽出しました。

RuboCop 1.0 は安定したメジャーバージョンということで、Breaking Change を起こさないアップグレードを指向しています。この講演では、アップグレードのメリットや、その舞台裏における問題抽出の環境について紹介する予定です。また、現状の RuboCop の静的解析における限界に対する設計や実装ポイントについても取りあげつつ、今後の拡張に対するアイデアのいくつかをお伝えします。

RuboCop のライトユーザーから、カスタム cop を作っている RuboCop マニアまで何かしら Takeout してもらえると良いなといったコンテンツ作成を進めています。お楽しみに。

9月11日(土) 11:00-11:25 @ima1zumi 『Dive into Encoding』

文字コードとは何でしょうか。私は現実世界の "文字" を抽象化して計算機上で扱えるようにしたものだと思います。業務アプリケーションで現実世界の業務を抽象化してコードを書くように、文字コードもまた "文字" を抽象化して計算機上で扱えるようにしているのだと考えています。

Ruby で 'あ' というコードを書くと String のインスタンスが作られます。例えば 'あ'.bytes を実行すると という文字のバイト列が得られます。 私は「あ」という文字がバイト列になっているということを想うととても興味深く感じます。その間には一体どんなコードがあり、文字はバイト列になるのでしょうか?また、バイト列で表現された文字と文字コードとの関係、文字コードを変換するとは一体どういう意味なのでしょうか。Ruby は String のインスタンスそれぞれが文字コードを持っていますが、それはどういうことなのでしょう?

これらの疑問を解決するため、自作文字コード「いろは」を作ってローカルの Ruby でビルドし、その過程を追うことで Ruby の文字コードの取り扱いについて深く潜ってみることにしました。このセッションでは、文字コードの基礎から Ruby の文字コードの実装まで話します。これを機に文字コードの世界に興味を持っていただければ幸いです。


それでは、オンライン会場でお会いしましょう。

RubyKaigi Takeout 2021 に Platinum スポンサーとしても参加している永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと成長したいエンジニアを絶賛募集しています。

agile.esm.co.jp

XP祭り 2021 に永和システムマネジメントから8名が登壇します

2021年9月18日(土) にオンライン開催される XP祭り 2021 に、弊社CEO @hiranabe の基調講演はじめ、永和システムマネジメントから8名が登壇します。

弊社メンバーの登壇スケジュールとタイトルは以下です。

お時間のあう方はぜひ遊びに来てください。

xpjug.connpass.com


株式会社永和システムマネジメントでは、Ruby とアジャイルソフトウェア開発を通じてコミュニティと共生しながら成長したいエンジニアを絶賛募集しています。

agile.esm.co.jp

RubyKaigi Takeout 2021 に Platinum スポンサーとして協賛します

こんにちは、 @yucao24hours です。

私たち永和システムマネジメントは、2021 年 9 月 9 日・10日・11 日の 3 日間に渡って開催される RubyKaigi Takeout 2021 に Platinum スポンサーとして協賛することとなりましたのでお知らせします。

rubykaigi.org

新型コロナウィルスの猛威が依然として収まらぬ中、多くの困難を乗り越えてこのような素晴らしいカンファレンスの場を今年も作っていただけたことを大変ありがたく思っています。

状況の改善を願い "RubyKaigi" として一同に集まってのカンファレンス開催を企画してくださっていた関係者のみなさまの胸中は察するに余りあります。そんな大変な中でありながらも、素晴らしいスピーカーの方々をお迎えいただき開催されるカンファレンスを、参加者として今からとても楽しみにしています。


弊社は前回までの RubyKaigi でも、さまざまな形のスポンサーとして開催のお力添えをさせていただいてきました。

今回の RubyKaigi Takeout も、関わるみなさまにとってより充実した場となり、ひいては Ruby をとりまくコミュニティ全体が活気に溢れた場であり続けられるようにという想いを込めて、微力ながらサポートさせていただきます。

なお、Platinum スポンサー特典として、幕間後に CM を流させていただけることとなりました。現在、オリジナル CM を鋭意準備中です!ぜひお楽しみに。

ぼくがかんがえたさいきょうの Input object

こんにちは。最近筋トレにはまっている wat-aro です。

blog.agile.esm.co.jp で Input object が紹介されていますが、実際に使っていくとネストしたパラメータの扱いに困ったためその解決方法を紹介します。
この記事のコードはすべて https://github.com/wat-aro/input_object にあります。

ここでは題材として GitHub REST API の

POST /repos/{owner}/{repo}/pulls/{pull_number}/reviews

を扱います。
API の定義は以下です。
https://docs.github.com/ja/rest/reference/pulls#create-a-review-for-a-pull-request

type RequestBody = {
  commit_id?: string;
  body?: string;
  event?: string;
  comments?: Array<{
    path: string;
    position?: number;
    body: string;
    line?: number;
    side?: string;
    start_line?: number;
    start_side?: string
  }>
}

ネストしたパラメータ

題材にしたAPI定義の comments のようにリクエストパラメータがネストしている場合がよくあります。
Input object で API のリクエストパラメータを受け取るようにしていると、このネストしたパラメータの扱いに困ります。
先の記事に紹介されたように、 AtiveModel::Attributes API を使うと ActiveRecord と同じようにキャストした値が扱えるのですが、 ActiveModel::Type にはネストしたパラメータを扱えるようなものがありません。

class ReviewInput
  include ActiveModel::Model
  include ActiveModel::Attributes

  attribute :commit_id, :string
  attribute :body, :string
  attribute :event, :string, default: 'COMMENT'
  # attribute :comments, ここでネストしたパラメータを扱いたい
end

これを解決するためにハッシュや配列から別オブジェクトにキャストできるクラスを作成します。
まずは comment 用の Input object を用意します。

class Review::CommentInput
  include ActiveModel::Model
  include ActiveModel::Attributes

  attribute :path, :string
  attribute :position, :integer
  attribute :body, :string
  attribute :line, :integer
  attribute :side, :string
  attribute :start_line, :integer
  attribute :start_side, :string
end

この Review::CommentInputReviewInputattribute に指定できるようにします。
Input クラスを引数にとって initialize できる ActiveModel::Type を作成します。

class InputType < ActiveModel::Type::Value
  def initialize(input_class, array: false)
    @input_class = input_class
    @array = array
  end

  def type
    :"#{@input_class.to_s.tableize.singularize}"
  end

  private

  def cast_value(value)
    if array?
      if value.is_a?(Array)
        value.map {|v| to_input(v) }
      else
        []
      end
    else
      to_input(value)
    end
  end

  def array?
    @array
  end

  def to_input(value)
    @input_class.new(value)
  rescue ArgumentError
    nil
  end
end

InputType を使うと Review::CommentInputattribute で指定できるようになります。

  attribute :comments, InputType.new(Review::CommentInput, array: true), default: []

これでネストしたパラメータや配列になっているパラメータを Input object として扱えるようになりました。

ネストしたパラメータのバリデーション

ネストしたパラメータを扱えるようになりましたが、今のままだとバリデーションが少し不便です。
ReviewInput#valid? を呼び出してもネストした comments のバリデーションが実行されません。
バリデーションメソッドを使って comments のバリデーションを実行したとしても、そのままでは ReviewInput#errors に追加されませんし、どのフィールドでエラーがでているかを翻訳できる形で表示するには一工夫必要です。

ここではカスタムバリデータを作成してこの問題を解決します。
このカスタムバリデータは以下のように書いて呼び出します。

  validates :comments, input: true

これは、comments に対して valid? を呼び出し、errors に翻訳できる形でエラーを追加します。

class InputValidator < ActiveModel::EachValidator
  def validate_each(record, attribute, input)
    if input.respond_to?(:each)
      input.each do |i|
        validate_input(record, attribute, i)
      end
    else
      validate_input(record, attribute, input)
    end
  end

  private

  def validate_input(record, attribute, input)
    if input.respond_to?(:valid?)
      return if input.valid?

      input.errors.messages.each do |key, values|
        values.each do |value|
          record.errors.add("#{record.class.to_s.tableize.singularize}/#{attribute}.#{key}", value)
        end
      end
    else
      record.errors.add(attribute, :invalid)
    end
  end
end

翻訳ファイルについては

---
ja:
  activemodel:
    attributes:
      'review_input/comments':
        body: コメントの本文
        path: コメントのパス

のようにしておくとエラーがあった場合に

irb(#<Repositories::PullRequests::ReviewsController:0x00005634fe0e8a38>):003:0> e.record.errors.messages
=> {:"review_input/comments.body"=>["を入力してください"]}
irb(#<Repositories::PullRequests::ReviewsController:0x00005634fe0e8a38>):004:0> e.record.errors.full_messages
=> ["コメントの本文を入力してください"]

のようにエラーメッセージを出せるようになります。

さいごに

Input object を実際に扱う上で困るネストしたパラメータに対応する方法を紹介しました。
この記事がいいと思った方はチャンネル登録とグッドボタンをよろしくおねがいします。

agile.esm.co.jp

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

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

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

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

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

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

idobata.io

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

翌 7月30日(金) 締め切りの Kaigi on Rails 2021 の CFP や、最近の Ruby / Rails まわりの動向に関する話題などあるかもしれません。

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

Reboot Rails/OSS meetup online · GitHub

Mac から Windows マシンに移行して 9 ヶ月がたちました

こんにちは、 @yucao24hours です。ことし 3 月ごろから本格的にボディメイクにハマっていて、3 ヶ月間で筋肉量をほぼ変えず体脂肪率を 24% から 19% まで減らせました!今は筋肉量を増やすべく、もりもり食べてがんがんトレーニングしているところです。


さて、タイトルの件。

2013 年の入社以来ずっと Mac を使っていた私が Windows マシンに変えて 9 ヶ月が経過しましたので、ここに至るまでに私が実際に感じてきたことなどをまとめてみようと思います。(以下、特筆しない限り "Mac" は "macOS のマシン" を指します。)

過去の私がそうだったように、「今は Mac を使っているし、どれくらい影響があるかわからないので、なかなかふんぎりがつかないな...」と思われている方もいらっしゃるのではと思います。そのような方々の判断材料のひとつとしてお役に立てれば嬉しいです。

※ 対象読者としては、現在 Mac を使っていてお悩みのかたを想定しています。現在 Linux を使っている方は、Windows を消して Arch Linux なぞを入れれば問題ないでしょう。(ジョークだよ!)1

前提1: PC を移行する時点での私の開発環境

私がふだんのお仕事でどんなツールを使って何をしているか、ここ最近で参加した数プロジェクトの実績から代表的なものをまとめておきます。

  • コードを書くのは Vim
  • ターミナルの管理は Tmux
  • シェルは Zsh
  • 開発環境は Docker (on WSL2)
  • メインのブラウザは Chrome
  • 資料の確認のために Microsoft Excel, PowerPoint
  • チーム内、社内での連絡には Slack, Idobata
  • プロジェクト管理は Pivotal Tracker, Trello, Notion
  • ドキュメント管理は DocBase, esa, Notion, Google Docs
  • ソースコード管理は GitHub(Git の操作は CLI で)

前提2: 購入したマシン

参考までに、購入したマシンとスペックについても記載しておきます。

当時、社内の複数の先輩が既に業務で使っていたこと、私自身も某プロジェクトの検証機として使った経験があったことから、Dell XPS 13 を選びました。

  • マシン: Dell XPS 13 (9300)
  • OS: Windows 10 Pro (64ビット)
  • メモリ: 32GB
  • CPU: 第10世代 インテル® Core™ i7

で、どうだった?ファーストインプレッション

改めてこのことについて書いてみようと思ってここ一年弱の業務体験を思い返してみると、「Mac のころからあまり変わらない」というのが最初の印象です。

前述した、頻繁に利用するツールのリストをご覧いただいてもわかるとおり圧倒的にブラウザベースのツールが多いですし、ネイティブアプリがしっかり用意されているサービスばかりだというのが大きな要因かもしれません。

また、開発で使っているツールについては、WSL2 の Ubuntu 上で使っているというのもあって "このマシンは Windows である" ということを殊更意識するような場面はあまりなかったように思います。(私が VSCode 使いとかだったら、もしかしたらもう少しなにか違ったのかな...いや、そうでもないか...?)

なお、WSL2 のセットアップについては当ブログの以下の記事でも解説しています!が、最新の情報ではないので今からトライする方は必ず公式情報もあたってみてください。 blog.agile.esm.co.jp

WSL2 に関しての留意事項

私が作業している中においては、以下の WSL2 特有のふるまいに遭遇し影響を受けました。WSL2 を使っているシステム開発者はほぼみな関係してくることだと思うので、予め知っておいて損はないんじゃないかなぁと思います。

systemd がデフォルトでは動いていない

timedatectl を使おうとしたら動かなかったため「はて?」と思い、調べたところで知りました。

こちらの現象に対する対応は https://github.com/arkane-systems/genie というライブラリを導入するのが定石になっているようです。

VPN に接続するとネットワークが切断され、インターネットにアクセスできなくなる

私が関わる業務ではセキュリティ上の理由から VPN に接続した状態でないとアクセスできないように制限されている操作などがあるため、よく VPN に接続するのですが、そのたびになぜか git pullcap deploy ができなくなるという現象が起きていて大変困っていました。上記に書いたとおり、VPN に接続するときというのはたいてい「失敗するとちょっとこわい」操作なので、原因がわかっていない頃に接続できなかったときは焦ったものです。。

こちらは Microsoft のページで対応方法が解説されています。他にも現実的に運用しやすいワークアラウンドを考案している方もいるようなので、参考にしてみるとよいかもしれません。

Windows にしてよかったこと

さて、それではそろそろ「Windows にしてよかった!」と思ったことについてもふれておきましょう... それは、他でもなく「(WSL2 上で)Docker を使った開発が快適にできるようになったこと」です。実際、これを一番の目当てにしてマシンを変えたので、期待通りのメリットを享受できた点にはとても満足しています。

ここ数年で参画したプロジェクトの中で、開発環境に Docker を使っていないというプロジェクトはひとつもありませんでした(本番環境でもコンテナを使う、というプロジェクトも珍しくなくなりましたね)。

それくらい Docker 上で開発することが普通になった今、Mac の Docker for Mac の処理のスローぶりは私にとって致命的でした。

私は TDD が大好きなので、コードを書くときにはまずテストを書いて作業にエンジンをかけ、そこからドライヴしていくのがお決まりのスタイルです。ところが、Mac の Docker においてはそれを満足にできず、長いこと「なんとかしたいなぁ... 」と感じていました。

しかし、Windows (WSL2)に変えてからというもの、そういったストレスは一切なくなったのです!これは本当に感動的で、当時の日報にも

Docker 上でテストを流したり、ブラウザ操作をするたびに、お笑い芸人並のオーバーリアクションで「いや処理はやっ!!!!」と声が出るくらいである。

と書いていました。

これだけでも、フォントが Mac に比べて好みじゃないなどといった微妙なネガティブポイントを補って余りある利点だと感じています。WSL2 さまさまです。

気に留めておいたほうがいいこと

最後に、乗り換えるにあたって認識しておくと後悔が少ないであろうことを挙げてみます。(当たり前のことだと思われるかもしれませんが、そう思えた方はこちらを気にせず迷わず WSL に乗り換えてしまいましょう!)

(日本語の)情報が少ない

まず、WSL2 については利用者は徐々に増えているものの、Mac に比べたら圧倒的にマイナー側なので公に出ている情報は少ないです。

何かあったときには発生事象から自力で原因を突き止めたり、WSL の公式 repo の issues 等を見て状況を把握したりできる必要はあると思います...当ブログのような技術専門リソースにご興味のあるような方ならそんなの当たり前だと思われるでしょうが。

あ、あるいは弊社のように、なにかあったときにすぐに聞ける人たちが近くにいてくれるような環境だとよりよいですね!(宣伝)

気にすることが多くなる

学習をはじめて間もない方にとっては、WSL2 というものに加えて、ホスト OS / WSL2 上の OS / Docker 等とさまざまな要素が絡み合っている状態はトラブルシューティングに苦慮するところかもしれません。

なにかあったときの問題の切り分け作業が多岐に渡る可能性が高くなるため、これらの要素に不慣れな方は解決までの道のりがちょっとハードかもしれないということは認識しておくとよいでしょう。もしも Linux( や Docker )にまったくさわったことがないという方なら、それらについてを学びたいというのが作業の主眼でない限りはまずは Mac をお使いになったほうが、やりたいことにフォーカスし続けられてよいのではと思います。


以上、気がついたことをまとめてみました。

他にもご意見などがあればぜひ聞かせてもらえると嬉しいです!それでは、ごきげんよう~。


  1. 最近の弊社では Arch Linux を入れている人が多いようなのです。