Step-to-Rails-Expert.rb第13回を開催しました

11/27(月)にStep-to-Rails-Expert.rb第13回を実施しました。

step-to-rails-expert-rb.connpass.com

流れ

当日の流れは

• 自己紹介
• 会の概要説明
• レビュー会
• 懇親会

という形で進めました。

会の様子

今回は、主催者の他に参加者二人分のレビューを行いました（チャレンジして頂けてありがたい）。 結構いろいろな指摘・質問・議論が出てきました。主催者のebiのPRに対するコメントを以下に並べます。

• il8nの漏れ
• i18nをフルパスで書いている（t("task_files.index.task_file_name")）
• import Vue from 'vue/dist/vue.esm.js' → import Vue from 'vue/dist/vue.esm'で動くはず
• 表記揺れ（引数のカッコの有無など）
• factory girl内で遅延評価を使っておくべき箇所
  { confirmed_at DateTime.current }と書かないと読み込まれたタイミングの時刻になってしまう
• 特に理由がなければ、if !ではなくunlessを使う（Rubyスタイルガイドにのっている）
• dependent: :destroyが漏れている
• capybaraでsleepはなるべく使わず、capybaraのオプションで何とかしよう

特になるほど、と思ったのが

• is_doneとdoneどっち（タスクの終了を表すカラム）
  Railsの世界では、isは付けない方が良いが、カラム名は・・・と考えると悩ましいが、つけない派が多かったです。 予約語っぽいカラム名（例えばprivate）をつけるときはisをつけてごまかすという意見もありました。

• タスクの終了させる機能についての設計
  現在、Task.is_doneをtrueにするために、PATCH /task_stateを投げている（TaskStatesController#updateを実装している）が、

  • Completionを作成する、という考え方でPOST /tasks/:id/completionを投げるべきでは
  • また、影響範囲の最小化と可読性のため、トップレベルではなくネームスペースを区切る、すなわちTasks::ComplatesController#createに変更したら良いのでは

という意見を頂き、本当にその通りだなと思いました。2点の指摘両方とも汎用的に使える考え方なので気をつけていきたいですね。

また、私のレビューではないですが、clearance gemの作成するusersテーブルのemailカラムに、デフォルトではユニーク制約がついていないというハマりどころが発見されたのにびっくりしました。PR送った方が良い気がしますね・・・

主催者以外のレビューコメントは、以下のPRをご覧ください。conversationsを確認すれば、だいたいの内容が分かると思います。

• https://github.com/okuramasafumi/expert-todo/pull/5
• https://github.com/shiroemons/expert-todo/pull/9

議論の中で紹介されたリンクを貼っておきます。

• devise-i18n
• rails-i18n

ロケールファイルがきちんとメンテされているというのは非常に良いので、私も使おうと思いました。

次の仕様について

• Level 1 is: タスクの複製（ひもづけは不要・タスクのどの内容まで複製するか選べない）
• Level 2 is: タスクに優先度をつける
• Level 3 is: Googleカレンダー共有

不明点があればぜひお問い合わせください。

反省点

時間配分が難しいので課題ですね。時間が足りず延長してしまい申し訳なかったです。 ただ、レビューをきっかけにせっかく良い議論が起こっているときに話を切るのももったいなく、悩ましいです。

次回について

次回は12/21（木）で、ExpertTodoのもくもく会です！ 今まで参加したことない方は、雰囲気をつかむのに丁度良いのでぜひご参加ください。普段参加されている方もぜひ来てくださいね。 なお、途中参加も可能なので、既に最小実装をしてある人のリポジトリをforkするなどしてぜひご参加頂ければと思います。 ご興味ある方は、Step-to-Rails-Expert.rbのslackへこちらから招待を受けてください。

ところで

懇親会にて神速さんが書籍「CLEAN CODE FOR RAILS」（技術書展で販売）を持ってきてくださったので購入できました。 弊社LICTOORのメンバーも欲しがっていたので、購入でき非常にありがたかったです。ありがとうございました！

Rubyエンジニア(プロ)の書いた薄い本の内容が素敵すぎてヤバい！Webや本でRails一通り勉強し終わった人のステップアップにぴったりな一冊。まさにこんな本が欲しかった〜 @sinsoku_listy さんに感謝しつつ、明日会社持ってってうちの子たちに布教する(・∀・)！ pic.twitter.com/Qn3fS8IVTr

— Takahiro HAMAGUCHI (@tk_hamaguchi) 2017年11月27日

Step-to-Rails-Expert.rb第12回を開催しました

10/30(月)にStep-to-Rails-Expert.rb第12回を実施しました（祝1年:tada:）。

step-to-rails-expert-rb.connpass.com

お礼

Step-to-Rails-Expert.rbは開催一周年を迎えることができました。 現在会場提供頂いている株式会社Speee様、勉強会立ち上げ当初会場提供頂いていた株式会社アニメイトラボ様、実績もないコミュニティにロゴを提供してくださったセラリンさん、特に感謝申し上げます。これからもスタッフのtwo_sannとともに、実りあるコミュニティ活動を行っていくよう努力していきます。 また、参加者の方（特にいつも参加してくださっている方達）にもお礼申し上げます。みなさんから色々教わることで技術者としてもとても大きく成長することができました。これからも参加したくなるような企画を続けていきますので、ぜひ引き続きご参加頂けると幸いです。

流れ

当日の流れは

• 自己紹介
• もくもく会
• 懇親会

という形で進めました。

会の様子

作業&初参加の方への説明&雑談をしていました。 作業に集中されている方もいれば、「Heroku久しぶりに触るんだけどGithubと連携できるようになっているんだ」とか「コミットメッセージに絵文字入れるの良い」など、軽く雑談しながら進める方もいたり、好きに過ごされている感じが非常によかったです。 他にもRailsGirlsのコーチをやっている方が参加していたのでRailsGirlsについて色々教えてもらったり、GoRails良いよとか教えてもらったりもしました。

技術的なことに関しては、主催者のリポジトリ（ローカルでもPostgresを利用している）をforkして進める場合、MySQLやSQLiteを使うケースでconfig/database.ymlだけ直してrails db:migrateを行うとDeviseのTrackableの箇所でundefined method inet とエラーを吐いてしまうので、該当のmigrationファイルのcurrent_sign_in_ipとlast_sign_in_ipをstringに修正する必要があるということを知れて、勉強になりました。

反省点

以下の2点を改善しておこうと思います。

• README（ルールの記載）について、英語のものも用意しておく
• 必ず元リポジトリもしくは他の参加者のリポジトリをforkするルールをもう少し強調して書いておく

後者について、「Railsで何かを作るときに参考にできるものが少ない」という辛さを、forkされたリポジトリを追えるようにすることで改善できるという考えがあり、結構大事なルールなのでもう少し伝わりやすく書いた方が良かったですね。初参加の方がいると反省点が浮かぶので非常にありがたいです。

次回について

次回は11/27（月）で、ExpertTodoのレビュー会です！ 今アプリを作っている方は、ぜひ区切りの良いところまで完成させてレビューしてもらいましょう！次回初参加する予定の方は、アプリを作らなくても参加できますので、雰囲気をつかむ目的で参加して頂いても大丈夫です。 ご興味ある方は、Step-to-Rails-Expert.rbのslackへこちらから招待を受けてください。

Step-to-Rails-Expert.rb第11回を開催しました

9/25(月)にStep-to-Rails-Expert.rb第11回を実施しました。

step-to-rails-expert-rb.connpass.com

流れ

当日の流れは

• 自己紹介
• レビュー会
• 懇親会

という形で進めました。

会の様子

今回は、主催者とスタッフのtwo_sannの二人分のレビューを行いました（他にもチャレンジしてくださった方がいましたが時間が足りなかったそう）。 元リポジトリはこちら

github.com

結構いろいろな指摘・質問・議論が出てきました。一部を並べると

• nullを許容するようなカラムにはnull: false, default: '' の方が良いのでは
• 文字列とシンボル両方かならシンボルの方が（本当に若干）パフォーマンスが良い
• bulletで、N+1クエリがあったら例外投げる設定がある
• I18n#l便利
• I18nを使う場合、viewでplaceholder: trueにyamlに使用する文字列を定義することができる
• 1コミットはテストが通る状態がベスト（あくまでベスト）なので、rubocopのコミットはなるべく別コミットにしない方が良い
• Strong Parameterで、params.require(:task).permit(Task.columns.map(&:name).map(&:to_sym))（全てのカラムを許可する）はカラムが増えたときに危険
• POSIX準拠違反（See: https://www.slideshare.net/koic/stairway-to-the-pragmatic-rails-programmer#54）

I18n周りの機能について色々知れて勉強になりました。 また、nullを許容するか否かについて、個人的には「ない状態」を表すためにnullではなく""を使うと、場合によってはnullを使用し別の場合は""を使用するケースがあり、複雑性が増すのではと思っていたので、極力nullableなカラムを定義しないようにし（テーブル分割する）、やむをえない場合はnull可にするという方向性で考えていました。 ですが、そもそも意味論的にnullより""の方がふさわしいです。nullは不明な状態なので、""とは意味が違います（指摘され思い出した）。あとはGemでカラムを生やすものは、null: false, default: ""を使っているのが多いので、統一できるという利点もあると思い考えを改めました。あとは空文字だとユニーク制約にひっかかってしまうので、validates :hoge, uniqueness: true, if:のように:ifオプションをつけないとなぁと思うなどしました。 ところで、カラムにNULLを許可する弊害については以下の書籍がとてもわかりやすく解説しているので、ぜひ一読することをおすすめします。 gihyo.jp

議論の中で紹介されたリンクを貼っておきます。

• rubocopについて（sueさんの便利スクリプト）

  • onkcopの設定とコードの修正 by toyokappa · Pull Request #30 · toyokappa/knowledge-stocker · GitHub
  • rubocopでcop単位でコミットする - くりにっき

• コミットについて

  • 【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた - Qiita

次の仕様

必須以外はランダムで選びました。この中から、順番に解いても例えばLevel 3だけでも解いても良いです。 前回までの課題の最小仕様までを自分で実装して頂いても構いません。

• 必須: タスクの状態変更（単数タスク）
• Level 1 is: 通常ユーザーの作成時に確認メールを送信する
• Level 2 is: タスクへのファイルのアタッチ（複数）
• Level 3 is: タスクの状態変更（複数一括）

次回について

次回は10/30（月）で、ExpertTodoのもくもく回です！ 今まで参加したことない方は、雰囲気をつかむのに丁度良いのでぜひご参加ください。普段参加されている方もぜひ来てくださいね。 なお、途中参加も可能なので、既に最小実装をしてある人のリポジトリをforkするなどしてぜひご参加頂ければと思います。 ご興味ある方は、Step-to-Rails-Expert.rbのslackへこちらから招待を受けてください。

Step-to-Rails-Expert.rb第10回を開催しました

8/28(月)にStep-to-Rails-Expert.rb第10回を実施しました。

step-to-rails-expert-rb.connpass.com

流れ

当日の流れは

• 自己紹介
• もくもく会
  • 作業
  • 既にアプリが完成されていた方のレビューリハーサル
• 懇親会

という形で進めました。

会の様子

元々、どの位1人あたりの時間を取れば良さそうかの確認も兼ねて、レビューのリハーサルを主催者のアプリで実施しようと思っていたのですが、すでに完成させている方がいらしたのでご協力頂きその方のレビューを行うことにしました。 そこで色々見させて頂き、実際の進め方は以下のようにすることを決めました。

• 1人15分から20分の時間をとる（人数次第で調整）
• 事前にslackに入ってもらう。コミュニケーションの中で参考URLやコード例など残したいときはslackの当日チャンネル、githubのコメントで残す
• 参加時にレビュー希望の旨表明してもらう
  • 基本宣言したら守ってもらう
  • 宣言した人優先で時間配分を行い、当日に完成したのでレビューして欲しいと申告のあった人は時間が余ったら、もしくは懇親会等でレビューする（事前申告者が5人であったら、75分/5人で1人あたり15分を割り当てる。当日申告者が2人いたとしても、75分/7人という計算は基本的にはしない。事前申告者の人数によって変わることあり）
• 初回は最小実装のみなので問題ないが、2回目以降は実装幅が広がり時間がなくなることも想定されるので、事前に参加者が一人分をレビューし、そこで気になった点を本番で話しあう（時間的・実力的にレビューが難しかった場合は、本番でみんなでレビューを行うことでカバーし、その際レビューの仕方等のフィードバックができる）
• レビュー内容の紹介のためにリポジトリをブログやTwitterで紹介することがあることを断っておく
• 時間のない場合、その次の回に回す（もくもく回 → レビュー回という順番で行うので、もくもく回がバッファ）

この辺、ExpertTodoの実施ページにルールとして記載しておきます。

議事メモも合わせてご覧ください。

minutes/10th_20170828.md at master · Step-to-Rails-Expert-rb/minutes · GitHub

次回について

次回は9/25（月）で、ExpertTodoのレビュー回です！ 実際に参加者の作ってきたアプリをレビューし合い、開発手法、選定ライブラリのくせや選定時のコツ、実装のより良い方法など、実際の業務のみでは学べない分野の知見も得られると思いますので是非ご参加ください。

ExpertTodo（Todoアプリレビュー企画）について

以前から少しずつ触れてきたTodoアプリを作成してきてレビューしあう企画について、fixしたものをまとめておきます。
TODOの箇所について、「こうすれば良いのでは？」など案があれば、ぜひコメントください！
また、どなたでも入れるのでslackへの参加もぜひお願いします。

Join Step-to-Rails-Expert.rb on Slack!

ExpertTodoとは

Todoアプリを作成し参加者でレビューしあうという企画の名称、または本企画で使用されるアプリの名称を指します。 どういう経緯で本企画が企画されてきたのかは、以下のリンクをご覧ください。
http://biibiebisuke.hatenablog.com/entry/2017/05/26/115016 http://biibiebisuke.hatenablog.com/entry/2017/07/19/232203 http://biibiebisuke.hatenablog.com/entry/2017/06/29/121713

目的

同じ仕様のアプリを参加者で実装しレビューしあうことによって、RailsWayがどのような設計・実装によって実現できるかを参加者で議論しながら探求していきます。

背景

Gemやちょっとした機能を実装した知見はweb上にたくさんありますが、それらをRailsWayに乗って書くにはどのように書くべきか、という知見が少ないと感じています。Rubyに関してはOSSのコードを見ることで学べますが、RailsのOSSは少なく参考にできるプロジェクトがあまりないのが現状です。 そこで、ExpertTodoではRailsを使ってどのように設計・実装すべきかを、実際のアプリを作成し互いにレビューしあうことによって学んでいきます。その際、追加する仕様をランダムに設定し「仕様が天から降ってくる」実際の業務に近い状態を作り出すことで、変更に強い設計・実装を学ぶことができます。この意味で業務に直結する設計力・実装力の向上を期待できます。

参加することで学べる可能性のある事柄

• RailsWayを学べる
• 変更に強い設計・実装を学べる
• 実装だけでなく開発フローなどの指摘も得られる
• CI環境の設定方法・Paas/Iaasを使ったアプリプラットフォーム構築の知見を得られる
• 既存のアプリをメンテする勘所を学べる（他の参加者のアプリをforkして進めることもできる）

開発方法に関して

開発の流れ・開発のルールに関しては、ExpertTodoのREADMEをご覧ください。

仕様について

• 仕様は、仕様候補と呼ばれる仕様の集まりの中からランダムで選ばれます。
• 仕様は、レベル別に3つ用意する予定です（以下例）。
  • Lv.1 通常ユーザーの作成時に確認メールを送信する
  • Lv.2 タスクへのファイルのアタッチ（複数）
  • Lv.3 期限がすぎたタスクのweb上での通知
• 各回の仕様は、READMEに追記されます。
• レビュー対象は、初回は最小機能（READMEに記載）を実装したもの、2回目以降は仕様の中から任意のレベルの仕様を実装したものになります。

ExpertTodoの進め方・お願い

• 初回までは、レビューは当日の開催中に行う予定です。 ただし、初回は最小実装のみなので問題ないが、2回目以降は実装幅が広がり時間がなくなることも想定されるので、事前に参加者が一人分をレビューし、そこで気になった点を本番で話しあうということも計画しています（時間的・実力的にレビューが難しかった場合は、本番でみんなでレビューを行うことでカバーし、その際レビューの仕方等のフィードバックができる）。

• 実施方法として、参加申し込み時に宣言した人優先で時間配分を行い、当日に完成したのでレビューして欲しいと申告のあった人は時間が余ったら、もしくは懇親会等でレビューするという方法を取ります。事前申告者が5人いたら、75分/5人で1人あたり15分を割り当てます。当日申告者が2人いたとしても、75分/7人という計算は基本的にはしない予定ですが、事前申告者の人数によって変わります。なので、必ずレビューして欲しい方は参加申し込み時に宣言することをオススメします。

• 前述したランダムな仕様案を増やすため、アプリを作った作らないに関わらず、当日1人1つ仕様案を考えてきてください。

• 事前にslackへの参加をお願いします

（運営）必要なもの

• TODO: ランダムで仕様を選ぶやつ
• TODO: 質問・サポートの場（実装というよりは仕組みや運営の不備による不明瞭な事柄についての窓口）
• TODO: 無料でできる構成のサンプルを提供する（heroku&circleCIなど）

その他

本企画ExpertTodoは、非常に学びがある企画だと考えていますが企画の性質上あまり多くの参加者を受け入れるキャパシティがありません。実際にアプリを作っていなくても参加できる枠組み（オンラインの参加で議論の様子を聞けるなど）を考えてはいますが、運営リソース等の制限で実現できるかは定かではありません。そのため、他のコミュニティや集まりで本企画を実施して頂くのは大歓迎です。その際は、フィードバックを受けたい・場合によっては参加させて頂きたい等の理由から、Step-to-Rails-Expert.rb主催者のebiまで一声かけて頂ければ幸いです。

質問の回答

いくつか質問をもらったので、質問・回答を記載します。今後増えていく予定です。

• どこまで実装したらレビューしてもらえるの？
  レビュー対象は、初回は最小仕様の実装、2回目以降はレベル別仕様のうち一つでも仕様を実装したものとなります。

• 実装方法がわからずギブアップする場合はどうする？
  ギブアップは、fork先の実装を見ましょう。もしくはチャットor懇親会等で質問しましょう。特別な理由がない限り、他の人の実装を見て実装した仕様に関しては、レビュー不要の旨をPRに記載してください。

2017年8月21日追記

質問・回答を追記しました。
仕様についての説明を追記しました。
slackへの参加について追記しました。

2017年9月10日追記 ExpertTodoの進め方を編集しました（進め方の説明を追記。

Step-to-Rails-Expert.rb第9回を開催しました

7/31(月)にStep-to-Rails-Expert.rb第9回を実施しました。

step-to-rails-expert-rb.connpass.com

流れ

当日の流れは

• 自己紹介
• 議論
  • レビュー・教育について
  • Todoアプリレビュー企画のレビュー
• 懇親会

という形で進めました。

議論内容についての感想

• レビュー・教育については色々なところで議論されているため、方法論についてはある程度セオリーができているのだなと感じました。

• レビューの手間を削減する便利gemやサービスについて興味があり議題に記載したところ、Rubocop以外にあまり思いつかなかったのですが、

  • reek
  • rails_best_practices
  • brakeman
  • bullet
  • danger
  • SideCI

など色々教えて頂きました。 SideCIについて、静的解析ツールの設定方法に長けていなかったり、導入・設定運用のリソースがない場合には非常に魅力的な選択肢だと感じました。

また、 TODOアプリレビューしあう回の企画を相談させて頂きみなさんにレビューしてもらったので、近日中に公開します。

詳しい内容は議事メモをご覧ください。

github.com

反省点

• 自己紹介もPRで送ってもらうの準備が間に合わなかった

次回について

次回は8/28（月）にもくもく会形式で、「TODOアプリレビューしあう回」のアプリを作る作業や質問をする回にする予定です。 また、本番の回までに本勉強会の様子を体験してみたいという方の参加もお待ちしております。

Step-to-Rails-Expert.rbの7・8月開催回の位置付けと9月開催回の企画の概要について

本記事では、次回7/31のStep-to-Rails-Expert.rbと今後の企画についての関連について、募集要項に記載していない内容を補足します。 次回の募集要項はこちらです。

step-to-rails-expert-rb.connpass.com

7・8月開催回の位置付け

9月開催回（9月下旬実施予定）に「TODOアプリを作ってきてレビューしあう」という企画を実施予定です。

少人数の勉強会で気軽にアプリレビューをしてもらうという企画は、中級者から上級者までとても学びが多い企画と考えていますので、今まで本勉強会に参加したことのない方にも参加頂きたいと思っています。しかし、TODOアプリレビュー企画で本勉強会に興味を持って頂いたとしても、初参加で雰囲気も知らない中にアプリを持ち込み、レビューしてもらおうと思える人は多くないと想像します。
そこで、次回7/31と8月開催回についてはTODOアプリレビュー回の導入回（初参加の人が顔を出して様子を把握できる回）とすることに決めました。実際の内容として、まず次回7/31は「レビュー・教育について」というテーマで開催します。指導する側、される側どちらにしても業務で高確率で経験できる話題なので気軽に参加できることと、アプリレビュー回と親和性の高い話題だからです。
そして8月開催回ではもくもく会として開催し、アプリレビュー回のアプリを作成したり、その関連の話題について話すのをメインとする回にする予定です。その時に初参加の方は作業しつつ雰囲気をつかんでもらい、アプリレビュー回にお披露目させるか決めて頂くと良いと思います。

TODOアプリを作ってきてレビューしあう回について

実施方法

開催日までに公開されている仕様のアプリを作成し、当日実際に動かしたりソースを見ながらレビューしあいます。

目的

作ってきた人

• 普段指導されることが多い人向け
  • 社外の様々な人からレビューしてもらう機会を得る
• 指導することが多い人向け
  • 他の人がレビュー・指摘しているところを見て、注意すべき指摘点や指摘の仕方を学ぶ
  • 社外の様々な人のソースをレビューすることによって、「このような考え方（間違い方）をする人がいるのか」という気づきを得る
  • 改めて他の人からレビューされることで、自分の設計・実装方法に対する新たな気づきを得る

作ってきていない人

• 普段指導されることが多い人向け
  • 他の人が指摘されている点を普段の自分の設計・実装方法に生かすことができる
• 指導することが多い人向け
  • 他の人がレビュー・指摘しているところを見て、注意すべき指摘点や指摘の仕方を学ぶ
  • 社外の様々な人のソースをレビューすることによって、「このような考え方（間違い方）をする人がいるのか」という気づきを得る

なぜTODOアプリなのか

単純なものとても簡単に作れますが、

• リッチでインタラクティブなview
• タグ機能など多対多関連の設計・実装
• 期限到来の通知機能
• 一括削除
• todoの終了/削除などの状態管理
• 間違えて終了してしまったtodoを戻す

など、仕様を増やすとそれに従い難易度が増加するので、様々なレベルの人が楽しめるのでテーマをTODOアプリとしました。

最後に

TODOアプリを作ってきてレビューしあう回に興味を持って頂いた方もそうでない方も、次回7/31（月）は通常通りの議論形式で行うのでぜひご参加ください！