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

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

@kasumi8ponと@ima1zumiのインタビューが公開されました

弊社エンジニアの @kasumi8pon@ima1zumiのフィヨルドブートキャンプ卒業生インタビューが公開されました。

bootcamp.fjord.jp

この記事は、インタビューを受けた2人のコメントを載せたライナーノーツになっております。インタビュー本編とあわせてお楽しみください。

@kasumi8pon コメント

今回のインタビューを受けて、フィヨルドブートキャンプで学習していた時代のことを思い出しました。自分の経験の話が、今学んでいる人や学ぼうとしている人が未来を描くのに役に立てば嬉しいです。

また、自分自身のふりかえりにもなりました。当時わからなくて苦労したプラクティスが、今では身について、仕事に活かせているなという自信を持てたり、当時楽しいと感じたチーム開発について、今も変わらず仕事でのチーム開発を楽しんでいることに気がつけました。そして、フィヨルドブートキャンプで学んだときを思い出して、これからも同じように学んでいきたいと思うことができました。 とてもよい機会をいただき、ありがとうございました!

@ima1zumi コメント

今回のインタビューでは、フィヨルドブートキャンプで学習したことと、働きはじめて何をしているか、どう感じているかということを話しました。フィヨルドブートキャンプ卒業と永和システムマネジメント入社からほぼ1年という節目で、自分を見つめ直すいい機会になりました。フィヨルドブートキャンプで学んだ学習とアウトプットの姿勢を続けていこうと気持ちを新たにしました。

インタビューを受けるというのは初めての経験ですこし緊張しましたが、今の率直な気持ちを言葉に残せたと思います。フィヨルドブートキャンプの雑談タイムで話していたころと同じような雰囲気で懐かしくリラックスして話せました。

このインタビューが何かの参考になれば幸いです。ありがとうございました。


"フィヨルドというコミュニティ" で過ごす時間によって、ソフトウェアを作る技術だけではなく、人と人の繋がり方や関係性の大切さが伝えられていることが伝わるインタビューでした。ぜひご一読ください。

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

agile.esm.co.jp

ダブルチェックを低減する技術

@koic です。

運用上の作業を開発者が行うというのは、昨今の DevOps ではよく見る光景だと思います。そして、運用手順の実施などにおいてダブルチェックというものを聞いたことあるでしょう。いや、むしろプロジェクトのルールで必要とされ、聞いたことがあるというレベルではないケースもあると思います。

そんなダブルチェック文化について、個人的には「ダブルチェックと聞いたらまず必要性を疑って判断する」という立ち位置で、本稿はそういった音楽性の人が書いた記事となります。

なお、一口に「ダブルチェック」といっても定義は広いため、「リアルタイムでの2人以上の指差し確認」を本稿でのダブルチェックの定義として位置付けます。

そもそも人間は間違えうるもの

やるやらないの判断の前段に、ダブルチェックの際には懐疑的に接するという姿勢をしています。理由としては本来的に人間は間違えうるものなので、一人で起きていたミスが二人なら起きないかというと、別にミスが起きなくなるわけではなく、ミスが起きる可能性が減るということが期待になります。

では二人ではなく三人にしたらもっと減る?四人なら?となりますが、一定人数以上になるとミスの検出率は下がるといわれています。随分前でうろ覚えですが、たしか『ピアレビュー』あたりに記述があった気がします。

本稿で扱う「ダブルチェック」の本質はリアルタイムレビューです。ドライバーのセルフレビューは依然として必要ですし、作業者のいずれもダブルチェックが思考停止フラグにならないよう「この相手なら間違えても気付いてもらえるだろう」と気を抜かない方が良いでしょう。というのは理想論で、まあ人間なので気を抜いてしまって見落とす時もあります (実際、私自身が過去何度も見落としたことがある) 。

なので、リスク低減を目指すものの、そもそも間違えうる人間の瞬発性を前提とした作業が「ダブルチェック」というものになりそうです。難しいところです。

本番環境へのショートサーキット 👿

必要にせまられて、本番環境ログインでの直接コマンド操作をするような作業が必要になることがあるでしょう。そんなとき、手順へのレビューがあまりされていないような本番手法は極力控えましょう。データベース操作を伴うような作業で、「rails console を本番環境で直接叩く」といったケースはこのアンチパターンの一例です。

こういった作業を迫られた際の「不安」を感じる際は「ダブルチェック」はひとつの心理的安全性と、ワークアラウンドのリスク低減を得られる手法になりえます。

人間は感情の生き物でもあるので「心が折れそう」とか「不安がある」ときは、普段からのペアワークのこころで声をかけてみると良いでしょう。

https://www.slideshare.net/koic/attitude-of-mind/47

Ops でも Dev のレビューフローにする 👼

本番環境へのショートサーキットに対する正攻法としては、一時運用の作業手順をスクリプト化して GitHub で Pull Request レビューを通すことはひとつのアプローチになります。これは手順の確認や、ミドルウェアへのパフォーマンス影響などの観点レビューを事前に行うことになります。イレギュラーではない、いつもの開発ワークフローですね。

異なる観点によって問題検出率はあがります。緊急の対応だとしても、なるべく普段の開発フローに載せる形で進められれば、イレギュラーなアプローチによるリスクを低減することができるでしょう。

本番環境に入っているときの「ヒリヒリ」した精神下ではなく、非同期で落ち着いたタイミングでレビューできるというようになるので、精神面としてもできるときはこちらを選びたいものです。

仮に本番環境での作業がダブルチェックになったとしても、実行コマンド自体はレビュー済み、場合によってはテスト済みのスクリプト一発で行えるようになります。テスト済みのスクリプト一発実行だけであれば、ダブルチェックは不要になることもあるでしょう。

形骸化したただの着席プロセスになっていないか疑う

見てきた「ダブルチェック」で厳しさを感じるのは「単にルールだから」と十把一絡げに行うものです。

ダブルチェックはそれによって問題を見つけるためのものです。単なる「ルールで横に着席しました」になっていそうなときは、その意図やリスクを元に自動化やフローの改善ができないか疑ってかかってみると、本質的ではないダブルチェックへの手法を改善したり取り除くきっかけにできるかもしれません。

またミスが起きたときに、一人で作業していたものだと責められそうで、二人で作業していたらそこまで責められなさそうというのも不思議なもので、そもそも一人でもミスが起きづらいような仕組みを作る、人間ではなくシステムで行うようにするのが本質的な問題解決になるでしょう。いますぐはできなくても「いつかこの作業を自動化してやるんだ」の気持ちで、初手として未来を良くしていくためのイシューに起こしてみるのも改善への踏み出し方のひとつです。


「ダブルチェックを低減する技術」を紹介しました。ダブルチェックでどんなリスクを低減したいのかということをふりかえるキッカケになれば幸いです。続きはそれぞれの現場にて。

また永和システムマネジメント アジャイル事業部では、マンパワーでの問題解決をエンジニアリングでの解決に転換して進んでいきたいメンバーを募集しています。

agile.esm.co.jp

抵抗器のカラーコードは虹の色

どうも。 ハードウェア畑出身のe.mattsanです。 回路を相手にする仕事からプログラマに転向した一人です。

ちなみに、みなさんは電子回路をいじったことがありますか。

今はリモート勤務が日常となってしまい、出勤することもままならなくなりましたが、よく社内で電子工作をする光景を目にすることがありました。

我が社の東京オフィスは秋葉原に近く、昼休みにちょっと秋月電子まで買い物に…、と簡単に出かけられる立地も影響しているのかもしれません。

わたしも写真の抵抗器を秋月電子で購入しました。 5つか6つもあれば十分なのですが、ひと袋百個単位で売られているものですから、今でも手元に数百個の在庫があります。

このサイズの抵抗器は、見てのとおり数値でなく、色の帯が描かれていることをご存じの方も多いと思います。 これは抵抗器の値、抵抗値を表しています。 このそれぞれの色が一つ一つの数字に対応していて、ひと揃いで数値を表現するようにできています。

この抵抗器に描かれている色、じつは虹の色…とだいたい同じ色が使われています。だいたい。

「抵抗器に描かれている帯の色は虹の色なんだよ」と以前に知人と話をしたことがありますが、そのとき「いや、そもそも虹の色を覚えてないし」と言われてしまいました。

虹の色は、日本では7色に数えられますが、それぞれにどんな色が割り当てられているのか、あまり知られていないのかもしれません。

その色は「 (せき/とう/おう/りょく/せい/らん/し)」と言われています。

先ほど色が数字を表すと言いましたが、10進数を表現するには10種類の数字が必要なので、虹の7色だけでは足りません。

そこで10種類の数字を表現するために、虹の色のほかに彩度の低い「」の4色を補い、10種類の数字を表すようにできています。

さて、ここで4色を加えました。 虹の7色に4色を加えると11種類になってしまいます。

じつは虹の色と言われる色のうち、藍の色は使われていません。 これは青や紫と区別しにくいために使われないようです。 なので「だいたい虹の色」なのです。だいたい。

藍を除いた虹の6色の、前に黒茶を、後ろに灰白を加え、合計10種類の色を使って次のように数字を表現しています。

0 1 2 3 4 5 6 7 8 9

さて。 これで色が数字を表すことはわかりましたが、その数字を解釈できなければ値を読み取ることはできません。

そこは世の中の困りごとをプログラミングで解決するのがプログラマ。 ブラウザの上で色をポチポチするだけで抵抗器の値がわかるページを書いてみることにしました。

<!DOCTYPE html>
<html lang="ja">
  <head>
    <title>COLOR CODE</title>
    <script defer src="https://unpkg.com/alpinejs@3.x.x/dist/cdn.min.js"></script>

    <style>
      body {
        display: flex;
        justify-content: space-evenly;
      }

      .resistor-value {
        text-align: center;
      }

      .resistor-image {
        display: flex;
        justify-content: space-evenly;
        background-color: #fdb;
        width: 300px;
        height: 80px;
        border-radius: 50px/100px;
      }

      .first-digit, .second-digit, .multiplier, .tolerance {
        width: 40px;
      }
    </style>

    <script>
      document.addEventListener('alpine:init', () => {
        const colors = [
          'black', 'brown', 'red', 'orange', 'yellow',
          'green', 'blue', 'violet', 'gray', 'white',
          'inherit', 'silver', 'gold'
        ]

        Alpine.data('Resistor', () => {
          return {
            firstDigit: 0,
            secondDigit: 0,
            multiplier: 0,
            tolerance: 1,

            incFirstDigit () { this.firstDigit = (this.firstDigit + 1) % 10 },
            incSecondDigit () { this.secondDigit = (this.secondDigit + 1) % 10 },
            incMultiplier () { this.multiplier = (this.multiplier + 1) % 10 },
            incTolerance () { this.tolerance = (this.tolerance + 1) % 3 },

            getFirstDigitStyle () { return `background-color: ${colors[this.firstDigit]};` },
            getSecondDigitStyle () { return `background-color: ${colors[this.secondDigit]};` },
            getMultiplierStyle () { return `background-color: ${colors[this.multiplier]};` },
            getToleranceStyle () { return `background-color: ${colors[this.tolerance + 10]};` },

            getDigit () { return this.firstDigit * 10 + this.secondDigit },
            getTolerance () { return [20, 10, 5][this.tolerance] }
          }
        })
      })
    </script>
  </head>
  <body>
    <div x-data="Resistor">
      <div class="resistor-value">
        <span x-text="getDigit"></span>× 10<sup x-text="multiplier"></sup>Ω ± <span x-text="getTolerance"></span>%
      </div>
      <div class="resistor-image">
        <div class="first-digit" @click="incFirstDigit" :style="getFirstDigitStyle"></div>
        <div class="second-digit" @click="incSecondDigit" :style="getSecondDigitStyle"></div>
        <div class="multiplier" @click="incMultiplier" :style="getMultiplierStyle"></div>
        <div class="tolerance" @click="incTolerance" :style="getToleranceStyle"></div>
      </div>
    </div>
  </body>
</html>

フレームワークには、最近お気に入りの Alpine.js を使っています。 軽量で、小さな操作を簡単に書くのにとても重宝しています。

alpinejs.dev

冒頭の写真の中央にある抵抗器の色は「 」です。

「金」。

抵抗器に限らず、工業製品にはどうしてもばらつきが付いて回ります。 このばらつき ── 許容差(誤差)は、工業規格として定められています。

その許容差を表現するために、虹の色(の7色 - 1色 + 4色)の10種類以外に、いくつかの色が使われています。 その一つが「金」です。

許容差の表現には、よく目にする抵抗器では「金」の他に「銀」と色なしが使われています。 色なしとは、4番目の色がついていない状態、描かれている色の帯が3本のみのケースです。

値はそれぞれ次のようになっています。

色なし
±5% ±10% ±20%

(実際には許容差に他の色が使われたり、色の帯の数が5つや6つのこともあるのですが…今回のところは目をつぶってください)

上記のHTMLをファイルに保存しブラウザで開くと、抵抗器を模したイメージが表示されると思います。 今すぐ動きを見てみたいという方のために、bl.ocks.org を利用したページも用意しましたので、こちらのページをためしてみてください。 その色の帯をポチポチとクリックして「茶黒緑金」をそろえると、「10×105Ω±5%」と表示されます。

10×105Ω = 1.0×106Ω 、つまりこの抵抗器の抵抗値は「1.0MΩ(±5%)」と知ることができました。

抵抗器の色については、Wikipedia.orgなどにも詳しく書かれています。

en.wikipedia.org

電子回路は、とくにディジタル回路は、プログラミングと同じようにロジックを組み立てる面白さがあります。 一方で、物理的な制約や誤差といったプログラミングにはない要素も、多分に含んでいます。

電子回路に触れてみると、ソフトウェアとはまた違ったロジックの世界をのぞくことができのではないか思います。


世の中の困りごとを、プログラミングで解決する仕事をしてみませんか?

株式会社永和システムマネジメント アジャイル事業部では、エンジニアを絶賛募集しています。

さまざまな背景を持つ方々も歓迎です。 応募エントリお待ちしております!

agile.esm.co.jp

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

2022年5月の Rails / OSS パッチ会を 5月18日(水)に Discord でオンライン開催します。

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

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

開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。

Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です👇

discord.gg

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

koic: RuboCop

github.com

yahonda: rails-dev-box

github.com

yahonda: Active Record Oracle enhanced adapter

github.com

これからパッチ会に参加してみようという方も、ぜひどうぞ。Discord でお会いしましょう。


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

agile.esm.co.jp

イシューを閉じる技術

@koic です。

GitHub などでイシュー管理しているプロジェクトは多いと思います。プロジェクトで開いているイシューの数はいくつありますか?

私はいくつかのプロジェクトで 100 以上のイシューが開いているのを確認しています。Rust では 8,000 以上のイシューが開いているので全然大したことないかもしれませんが、いつまでも放置していても見通しが悪いままなので整理するのは悪くないアクションです。

これは人それぞれの好みもありますが、オープンソースのような自由時間で行っている活動で、地球の裏側から開かれた (良かれとオープンされた) イシューをクローズするのは精神力を使うので、Stale bot のようなものでクローズするのは「問題 vs 私たち」の構図にするひとつの選択です。一方で業務の方ではもう少しきめ細かくクローズできると良さそうという考えを持っていて、本稿ではそんなお仕事でのイシュークローズに対するパターンを取り上げます。

再発しないエラー

まず運用で起きたエラーは何らかの形でイシュートラッキングされますが、偶発的に起きたエラーについてずっと問題が起きていなければクローズできるものかもしれません。 偶発的に起きたエラーでも起きたら致命的なものであれば、本質的な問題を追求する必要がありますが、何年も再発せず困難かつ起きても軽微なものであればクローズします。

またエラーのリスク度合いの判断が難しいような場合は、『システム運用アンチパターン』の『運用の可視化』で言及されているリスク優先度番号 (RPN = Risk Priority Number) のような判断軸を使ってみるのもよいでしょう。

閉じずの作業ログ

システムへの新しいミドルウェアの導入や、問題の解析、手運用手順など、作業で行ったことのログとしてイシューが使われていることがあります。既にログとしての役目を終えているようであれば、クローズに進めることができるでしょう。

作業手順自体が次にその作業を行う際に有用なものであれば、Wiki などでドキュメント化しておくことを検討しておくとなお良しです。

Pull Request で解決済み

Pull Request で解決済みであるにもかかわらず、イシューだけが残っているケースがあります。対応するイシューがある場合に Pull Request を開く場合は Fixes #42, Closes #42, Resolves #42 などといった closing keyword でリンク付けておくとマージと同時にイシューがクローズされて便利です。closing keyword について、詳しくは GitHub のドキュメントを参照してください。

https://docs.github.com/ja/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword

動きがない

チーム開発で自分ではイシューの状態が判断できない場合は、イシューの起案者や問題を知っていそうなメンバーに ping をしましょう。例えば業務で3ヶ月以上イシューの動きがなければ、既に重要でない問題なのか、何かブロッカーがあるのか改めて聞いてみても、そんなに急かしている感じにはならないでしょう。

また、アクションとしての動きを強めたいような時は、担当と期限を作った具体的なアクションにするのも一法です。これは KPT で Try からアクションを出すときと同じ具体化です。内容によってチームのふりかえりに持っていって議論してみても良いでしょう。

すでに問題ではない

刻一刻と要件に応じて姿を変えるのが Web アプリケーション開発の特性のひとつです。過去の時点で問題だったことが、要件や実装の進んだ現在では問題となっていないことがあります。そういったイシューは見つけたらクローズしましょう。

誰もボールを持っていない

そのイシューについて担当している人がいないことを「ボールを持っていない」というメタファーで表現されることがあります。何ヶ月も放置されている重要でないイシューである場合、クローズされて困る人はいないでしょう。

小さなリファクタリング

Pull Request を作っているときが一番知識と熱量のあるタイミングです。小さなPull Request で「あとでリファクタリング」とされた状態で master / main ブランチにマージされた後に、数ヶ月経っても動きがないイシューはリファクタリングされる望みが薄いでしょう。リファクタリングでも受け入れ試験が不要そうな、小さなリファクタリングであればサッと隙間に実現してしまうのも手です。その時は closing keyword を添えておきましょう。

大きなリファクタリング

例えばクラスやテーブル構成を変えるような大掛かりなリファクタリングは、それなりの工数を使う上、リリースでの注意点が増えることもあるでしょう。イシューを閉じる技術をテーマにしている本稿ですが、こういった実現したいけれどいまがその時ではないものは、ラベル付けでフィルタリングできるようにして留めておくのはひとつのアプローチです。ラベルを見るだけでクローズ対象でないと分かるだけでもイシューの整理作業は効率化します。

データのトリミング

バリデーションの漏れなどで、実害がないものの余分なゴミがついたデータが存在する場合があります。これらを運用でトリムする作業がイシューとして残っているとき、未実施の場合は改めて議題に挙げると良いでしょう。一方で順次データが洗い替えされているケースであれば、洗い替えが終わっているような時期であれば用済みとしてクローズできます。

クローズには理由を添えて

すべてのイシュークローズに共通することとして「なぜクローズされたのか」をまわりや将来の自分が把握するため、クローズ理由をコメントに添えておくことを強くおすすめします。こういったひと手間の積み重ねで情報トラフィックの交通整理が向上してきます。


「イシューを閉じる技術」をぱっと浮かぶ範囲で紹介しました。この他にも閉じることができるイシューを見つけるタイミングはあると思いますので、続きはそれぞれの現場にて。本稿がそれぞれの現場のイシューを整理するきっかけになれば幸いです。

また永和システムマネジメント アジャイル事業部では、世の中に無限に存在するイシューを一緒に解決するメンバーを募集しています。

agile.esm.co.jp

対応を先送りにするという選択

こんにちは、kasumi8pon です。

先日、仕事で調査をしているときに将来エラーが起こりそうなバグを見つけました。それに対して「今は対応しない」という選択をした話をします。

将来起こりそうなエラー

将来エラーが起こりそうなことがわかったのは、全文検索エンジンを利用している箇所でした。ある ID の集合を指定しその ID のデータを結果から除く処理をしていましたが、その除外対象の ID はサービスの成長と共に増えていくことが見込まれています。 いくつかの全文検索エンジンではクエリに含められる句の最大数を設定することができますが、除外対象の ID の数がその設定の値を超えたときにエラーが生じて検索ができなくなります。 対象のデータは今後も増えていくことが予想されますが現在は上限値より遥かに小さく、データの増加ペースから見積ると、少なくともこの先数ヶ月ではエラーは発生しそうにありませんでした。

どんな対応を取るか

データが増えてもエラーが起こらないようにする方法を検討した結果、以下の二つの方法が候補にあがりました。

  1. クエリに含められる句の最大数の設定を変更し、上限を上げる

  2. ある条件の ID の集合を除くのではなく、その ID の判断基準に使った情報も検索エンジンにインデックスし、一つ一つを句として追加するのをやめる

一つ目の方法は、変更するだけなら値を設定し直すだけなので、簡単です。 しかし、上限値が設定されているのは1クエリに含まれる句が多すぎる場合のパフォーマンス低下を防ぐためなので、その上限を上げることで、エラーの代わりにパフォーマンスの問題が生じる可能性があります。 また、このまま除外する ID の数が増え続けたとき、再度上限値を上げる必要が出てくるかもしれません。サービスの成長と共にその数は増え続けることが予想されますが、それを毎回最大値を上げることで対応するのはいたちごっことなり、有限のマシンスペックでは対応しきれません。

二つ目の方法は正攻法です。除外したい ID の条件を他から取得して ID を直接指定するのではなく、その条件も含めて検索エンジンで検索します。クエリ内の句の数が増えることがないため、今回の問題は解決できそうです。 しかし、この方法はコードベースの変更だけでは済まずすべてのデータの再インデックスが必要なため、大きな作業になります。 プロジェクト内では最近全文検索エンジンのリプレースをする案が上がっており、問題が起きる前にリプレースを行うかもしれませんでした。また、未来のことはわからないので、もしかしたらこの機能が削除される可能性もあります。すべてのデータの再インデックスの処理を実行したが結果的に不要だった、という結末になることも考えられそうでした。

すぐには対応しないという選択

これらを踏まえて、わたしたちは第三の選択肢の「どちらの対応もしない」という方法を取りました。 一つ目の方法は根本解決にならないし、二つ目の方法は今現在起こっていない問題に対してかけるエネルギーが大きい上に無駄になるかもしれないため、今はどちらの選択肢も取りなくなかったからです。 しかし、何も対応しなければいつかは実際にエラーが発生することになります。 安心して対応を先送りするために、以下の二つを準備しておくことにしました。

「いつ対応が必要になるのか」をわかるようにする

対応を先送りにしたといっても、忘れたころにバグが起こってサービスに影響が出てしまっては元も子もありません。 それを防ぐため、対象となるデータ数の増加を監視することで、対応すべきタイミングがわかるようにしました。 人の手で監視を行うのではなく、監視を自動化し、そのときが来たら通知がくるようにしました。

「その時がきたら何をすればよいのか」をわかるようにする

先送りにしても、いざその時になにも情報がなければ対処しようがありません。 どんな問題だったのか覚えていればよいですが、忘れてしまう可能性があります。人間はよく忘れますし、そのときが半年後、一年後になるかもしれません。そうなると正確に覚えていることは困難になります。そもそもその時に自分がその場にいない可能性もあります。 そのため、誰でもわかるように、起こりうる問題ととるべき対応方針また、その選択をした背景などを、後から確認できるようにします。 具体的には、上記の監視のための変更のコミットメッセージやコードコメントに情報を残しました。

まとめ

まだ起こっていない問題について、「今は対応しない」という選択をした話をしました。 バグを見つけるとすぐに直したくなってしまいます。実際わたしも二つ目の方法を取ろうとしていました。しかし、チームメンバーのアドバイスを聞いて今回は先送りにするのがよいと判断しました。 現在問題が起きていない、かつ、今後状況が変わる可能性がある場合は先送りにすることも一つの選択肢になりそうです。

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

2022年4月の Rails / OSS パッチ会を 4月22日(金)に Discord でオンライン開催します。

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

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

開催時間は 17:00-19:00 となりますがご都合のあう方はぜひご参加下さい。

Discord の Rails/OSS パッチ会サーバーへの招待 URL は以下です👇

discord.gg

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

yahonda: Active Record Oracle enhanced adapter

github.com

github.com

これからパッチ会に参加してみようという方も、ぜひどうぞ。Discord でお会いしましょう。


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

agile.esm.co.jp