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

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

みんなでわいわい。「Kaigi on Rails のプロポーザルを考える会」をやりました

最近読んでいる RFC は 791 な @yucao24hours です。

ことし 10 月 3 日に開催される予定の Kaigi on Railsの CFP が、7 月 31 日をもって締め切られました。みなさん、悔いなく提出できましたでしょうか?

利用者数が多い Rails に特化した新たなカンファレンスという事実も然ることながら、オンライン開催となり参加に際して物理的位置に縛られなくなったのもあり、間違いなく多くの方が参加を前提に大注目しているカンファレンスであろうと思われます。

今回アジャイル事業部では、RubyRailsアジャイル開発に関する講演で数多くの登壇経験がある koic さんのアイディアにより、「Kaigi on Rails のプロポーザルを考える会」というものを実施しました。これがまた期待以上にとっても楽しかったので、その様子をお伝えします。

どんなことしたの?

会の参加の目的は以下のような感じで…

  • 実際にプロポーザルを書いてきてクロスレビューする
  • 他の人の書くプロポーザルや講演テーマに触発されたい
  • それらがどんなものか会自体を社会見学する

登壇に興味のあるメンバーは任意で事前にプロポーザルの下書きを esa に投稿しておいたうえで、当日は Meet でつなぎながら、その esa を見てみんなでクロスレビューをしました(== お互いがお互いにレビューしあう)。

また、プロポーザルを作る過程での悩みごとや迷っていることをその場で相談して、発表方針の改善に役立てることもできました。大勢の観点を交えることのメリットが活きたのではないかなと思います。

会は全部で 3 回開催されましたが、「プロポーザル出すぞ!!!!!1」というメンバーや「みんながどんなことを話してるのか聞いてみたいな」という有志のメンバーがたくさん集まりました。

やってみてどうだった?

わたしの感想としては、なによりもまずこの会自体がすごく楽しくて。

時間の限られた「発表」となると必然的に話題と主旨を distilled することになりますが、それによって発表内容にそれぞれの個性がはっきりと反映されていて、それらを眺めるのがとてもおもしろかったです。

また、プロポーザルと聞くと何となく敷居が高い気がして、自分からは遠いところにある到達点のように感じていましたが、こうしてワイワイ好きな技術の話をすることの延長線だと考えれば実はとっても身近でトライしやすいものなのかもしれない、と思えるようになったのも収穫でした。好きなことの話はいくらでもしたいですからね、たとえば DNS の話とか。

結果として、わたしもプロポーザルを仕上げて提出することができましたので、本当に「プロポーザルを考える会」サマサマです!

成果のほどは...?

気になる実施の成果ですが、最終的に、弊社からはわたしを含め 6 名のメンバーがプロポーザルを提出することができました。

さて、審査の結果やいかに…次回、「スピーカー、決定。」乞うご期待!!!

Git 2.27.0 から git pull をすると表示されるようになった "Pulling without specifying how to reconcile divergent branches is discouraged." について

最近の趣味はもっぱら L7 より下のお勉強、な @yucao24hours です。

梅雨入りもどこ吹く風の暑いある日、いつものように git pull を実行すると、以下のような警告が出るようになりました。

$ git pull
warning: Pulling without specifying how to reconcile divergent branches is
discouraged. You can squelch this message by running one of the following
commands sometime before your next pull:

  git config pull.rebase false  # merge (the default strategy)
  git config pull.rebase true   # rebase
  git config pull.ff only       # fast-forward only

You can replace "git config" with "git config --global" to set a default
preference for all repositories. You can also pass --rebase, --no-rebase,
or --ff-only on the command line to override the configured default per
invocation.
$ git --version
git version 2.27.0

警告を見ると

Pulling without specifying how to reconcile divergent branches is discouraged.

ということで、「分岐したブランチの解決のしかたを指定しないで pull するのはやめましょう」といったことが示唆されています。

どうして警告が出るようになったのか?

こちらは、2020 年 6 月 1 日にリリースされた Git 2.27.0 で新たに表示されるようになった警告のようで、以下はリリースノートからの引用です。

  • "git pull" issues a warning message until the pull.rebase configuration variable is explicitly given, which some existing users may find annoying---those who prefer not to rebase need to set the variable to false to squelch the warning.

github.com

以下が対象のコミットです。

https://github.com/git/git/commit/d18c950a69f3a24e1e3add3d9fc427641f53e12b

コミットメッセージによれば:

Often novice Git users forget to say "pull --rebase" and end up with an unnecessary merge from upstream. What they usually want is either "pull --rebase" in the simpler cases, or "pull --ff-only" to update the copy of main integration branches, and rebase their work separately. The pull.rebase configuration variable exists to help them in the simpler cases, but there is no mechanism to make these users aware of it.

とのことで、 pull --rebasepull --ff-only のふるまいを期待しているにも関わらずそれらの指定をしないまま pull してしまったユーザが、意図しないマージコミットを作ってしまうケースを避けるための警告のようです。

git pull のふるまいを紐解いてみる

git pullを実行したとき、Git はまず git fetch を実行し、そのあとに current branch に対して 事前に git fetch で取得したヘッドをマージするように git merge を実行します。

このとき、Git の設定ファイルの中で pull.rebasetrue もしくは false と明示的に設定されているか、 実行時に --rebase などのオプションが指定されていれば、リモートブランチとの差があったときにはそれらに従って差分が解決されます。

従来は、 pull.rebase の設定がなくて且つ pull 実行時のオプションも指定されなかった場合にはマージコミットを作って解決するというふるまいだったのですが、慣れないユーザがこれを意図しないふるまいとして困らないように、今回の修正をもって明示的に差分の解決方法を Git に教えてあげる方針となったということのようです。

(Git に慣れていないころ、 git pull をしたら突然エディタが開かれてマージコミットのコミットメッセージを編集するよう促され、何が起きたかわからずびっくりした方もいらっしゃるのではないでしょうか。ちなみにわたしはそうでした。)

なお、git pull の詳しい動作については、公式ドキュメントをご覧ください。

git-scm.com

どうするとよい?

先の警告メッセージにもあるとおり、pull したときにリモートブランチと差があった場合のふるまいとして、以下のいずれかの設定を用いて指定するようにすれば警告は消え、Git の意図する状態となります。期待するふるまいにあったものを選びましょう。

git configの公式ドキュメントの pull.rebase の説明 にもありますが、 rebase の動作をじゅうぶんに理解しないまま pull.rebase 設定を使って暗黙的にリベースに関する指定をしておくことは危険な場合があるとされています。ちなみに、わたしは暗黙的な動作によって影響を把握しきれないといけないので pull.rebase false にしましたが、社内には pull.rebase true にしている人もいますし、後述の pull.ff only にしている人もいます。どのような設定が良いかは各自の理解度やユースケースに合わせて決めましょう。

--rebase したいときは実行時に明示するスタイルがいい

こちらを設定すると、デフォルトの pull の挙動のままになります。

$ git config pull.rebase false

実行時の --rebase なしで pull --rebase になってほしい

$ git config pull.rebase true

差分があったら fast forward してほしい (fast forward できないときは失敗してほしい)

$ git config pull.ff only

なお、ここで指定する設定内容をすべてのリポジトリにおいてデフォルトの設定にしたい場合は、 上記の git configgit config --global とすることでグローバルな設定とすることができます。

先ほどのコミットのコミットメッセージにも

This will inconvenience those who never want to "pull --rebase", who haven't had to do anything special, but the cost of the inconvenience is paid only once per user, which should be a reasonable cost to help a number of new users.

とあるように、Git を使い慣れている方々にとってはちょっと冗長に感じられるかも知れませんが、一度設定すればその後は気にしなくてよくなりますので、シュッと設定してしまいましょう!

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

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

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

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

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

amatsuda and kamipo: Rails

github.com

koic: Faker

github.com

okuramasafumi: RubyGems

github.com

unasuke: Itamae

github.com

yahonda: ActiveRecord Oracle enhanced adapter

github.com

今回、全体の話題としては RubyKaigi 2020 の中止や、Ruby 2.7.2 でのキーワード引数の分離への警告の動向などがありました。

esa-pages.io

discuss.rubyonrails.org

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

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

idobata.io

特に募集ページなど設けませんが、上記理由から Idobata のアカウントと (TV 会議システムによっては Google アカウント) が必要になると思います。

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

gist.github.com

【入社ブログ】新卒で入社した9sako6です

はじめまして。2020年4月に新卒で入社した@9sako6 (くさころ)と申します。ご挨拶を兼ねて、簡単に自己紹介をします。

これまで

沖縄県で生まれ、名古屋大学・大学院で育ちました (学食の台湾味噌ラーメン中毒者でした、大変恋しいです)。大学院では自然言語処理を学び、これを応用したアプリケーションの研究と開発をしていました。研究室の教授がRubyで書かれたバックエンドを触ったり、フロントエンドをReactで書いたりしていました。研究よりもこの辺の開発が楽しかったです。 こうした経験が徐々に積み重なって、自分で手を動かしてモノを作るエンジニアになりたいと思うようになりました。

2020年現在、自然言語処理といえばPython一択な時代ですが、私の所属していた研究室ではRubyが主力言語の一つでした。ロックですね。Rubyは文字列の扱いに長けているので一定の合理性があると思います。ちなみに教授は手練れのRubyistで、私はかなり刺激を受けました。ここで私はRubyと出会い、Web開発に目覚め、ついには職まで得てしまったというわけです。

現在

特殊な情勢ゆえ、入社してからずっと在宅で基本の学習をしています。具体的には、完全にオレオレだった部分 (コミットの粒度やメッセージの書き方、テストの書き方)を矯正したり、新しくSQL, Railsを学んだりしています。@koicさん、@colorboxさんをはじめとする先輩方にサポートしていただいています。Idobataでいつでも質問できる環境にあり、リモートながら丁寧に指導していただいています。加えて、定期的にオンラインで質問タイムを設けてもらっています。やはり、直接のコミュニケーションによる学びは濃いです。早く一緒に仕事ができることを願っています。その時になって困らないように、今やれることをやっておこうと思います。

これから

ありきたりですが、自分の技術的な個性を作っていきたいです。というわけで今年は、自分の色を探る年にしたいと思っています。

以上、くさころでした!

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

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

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

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

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

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

idobata.io

特に募集ページなど設けませんが、上記理由から Idobata のアカウントと (TV 会議システムによっては Google アカウント) が必要になると思います。

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

gist.github.com

デプロイ直後Railsアプリへの一部のアクセスが非常に遅かった問題に関する調査の流れ

こんにちは、@color_boxです。 仕事中に見つかったちょっとした問題とその解決の道程について書いてみようかと思います。

どなたかの参考になれば幸いです。

続きを読む

Rails/OSSパッチ会 2020年4月休止のお知らせ

2020年4月の Rails/OSS パッチ会は新型コロナウィルス (COVID-19) への感染症対策のため休止します。

5月以降の開催と日程は現状で判断できないため、少し先に検討した上で別途アナウンスします。

このパッチ会の Idobata を公開しておりますので、オンラインで何かしら相談したいことがある場合などにご活用ください。

idobata.io

再開したら自宅で書いているパッチについて話し合いましょう。