Roll With IT

tamakiのIT日記

チーム開発振り返り

チーム開発

はじめに

先日所属するフィヨルドブートキャンプ(以下FBC)にて、チーム開発のプラクティスを修了することができました。

FBCでは、実際の仕事と同じようにアジャイルでチーム開発を行うカリキュラムが用意されています。以下のWebサービスの開発をチームで行っていきます。

github.com

チーム開発に参加するとIssueが割り振られます。割り振られたIssueには、チームメンバーでプランニングポーカーを行い見積もったポイントが付与されており、20ポイント分のIssueのPull Requestがすべてマージされたら修了になります。

取り組んだIssueとレビュー対応したPull Requestの振り返りを、一言コメントを載せつつ振り返っていきたいと思います。学べたことや反省点など、これからチーム開発に取り組む方の参考になれば幸いです。

取り組んだ期間

  • 約4ヶ月（12月中旬にはIssueレビュー待ちにて作業自体は完了）
  • 平日：2〜4時間
  • 休日：6〜8時間

チーム開発ミーティング

  • 初回参加日：8月24日
  • 最終参加日：1月11日

ミーティングは皆勤賞を達成！

Issueの進捗がなく気持ちが落ちた時もミーティングには必ず参加すると決めていたので、このマイルールは達成できてよかったです。

各々のスケジュールの問題もあり難しいところではありましたが、もっとチームメンバーと関わり協力してIssueに取り組めればよかったと思いました。ペアプロ、モブプロなどを通して数名の方とは関わりを持てましたが、多くのチームメンバーとは接点が持てませんでした。4ヶ月の間に20名近くの方と参加時期が被っていたとは思いますが、仕事や生活スタイルもバラバラなので、さすがに全員と関わるのは難しかった...汗。

それでも、レビューを依頼し合ったり、毎週のミーティングにて顔を合わせることでチームで作業を進めている感覚は十分ありました。チームメンバーのみなさんには本当に感謝しかありません。

アサインしてもらったIssues

  • 11個のIssuesに取り組んだ
  • 合計21ポイント

担当提出物の未返信が0だった場合の文言変更。 · Issue #5008 · fjordllc/bootcamp

Good First Issue。実装内容は文言の変更のみ。このIssueの胆はIssue着手からPR提出までの手順を覚えること。チームメンバーと一緒に取り組みモブプロ形式で進めた。

ログイン失敗時のパスワード入力のlabelが英語なので日本語にしてほしい · Issue #5380 · fjordllc/bootcamp

既に解決済みだったIssue。調査のみので終了。プロダクトオーナー（POだけでなくチームメンバー全員）とのやり取りで、口頭やディスコードだけではなくIssueのコメントに記録を残すことが大事なことを学んだ。またはっきりしないIssue内容は「はっきりするまで確認を取ること」も大事。自分で勝手に解釈して進めてはいけない。

アドバイザーでログインしたときに提出物にアクセスをしたら、全ての提出物一覧が表示されてほしい。 · Issue #4651 · fjordllc/bootcamp

メンターさんにペアプロしてもらいルーティングのチェックからDevToolsを使用した問題の切り分け方など基礎的なことを教えてもらう。 このIssueでDevToolsを使ったデバッグ力が一気に上がった。

user.vue, users.vueをVueMounterに対応させる · Issue #5147 · fjordllc/bootcamp

VueMounter（npm）がテーマのIssue。Vue.jsを復習しつつ、Vue Componentのマウント方法について学べた。

[abstract_notifier] 研修生の日報作成の通知の実装を置き換えたい · Issue #4687 · fjordllc/bootcamp

abstract_notifierへ置き換えを学んだ。gemを理解するのに時間がかかった。コールバック機能を理解した。

[newspaper] お知らせの通知削除処理をnewspaperに置き換えたい · Issue #5493 · fjordllc/bootcamp

newspaper。Pub/Subパターンについて学ぶ。newspaperが薄いpub/subライブラリであることを理解した。

[参考書籍] 参考書籍一覧をプラクティスで絞り込みたい · Issue #4958 · fjordllc/bootcamp

Choices.jsを使用するIssue。長時間詰まってしまいペアプロを依頼。自分の中では上手く進めることができていると思っていたが、見当違いの実装をしていたり、だいぶ脱線していた。軌道修正し対処。すべてのIssueに当てはまる大事なことを学んだ。

  • Issueに書かれていない内容以外の実装は原則不要
  • 行間を読んだり憶測で勝手に判断してはダメ
  • 分からなくなったら常にIssueに立ち返る
  • Issueで求められていることが分からなければ必ず確認を取る
  • 万が一、Issueで提示されていない機能や変更が必要だと思われる場合は必ず確認を取る

ActiveRecord::RecordInvalid: バリデーションに失敗しました: Userはすでに存在します · Issue #5588 · fjordllc/bootcamp

バグ修正対応のIssue。APIテストを理解。コミュニケーションのミスも続き、色々と上手くいかなかったIssue。テキストコミュニケーションの難しさを痛感。

メンターダッシュボードに5日経過した提出物が0件の場合、5日経過した提出物はありませんと表示したい。 · Issue #5735 · fjordllc/bootcamp

システムテストは重いので、UI上でデータを作ることは避け、テストコード内で自分でデータを作る必要があることを学んだ。

[abstract_notifier] イベントの補欠への繰り上がりの通知の実装を置き換えたい · Issue #4686 · fjordllc/bootcamp

abstract_notifierのIssueは2回目。前回の復習も兼ねながら取り組む。

[メンター紹介]メンターの関連書籍に画像をアップロードしてもプレビューできない · Issue #5785 · fjordllc/bootcamp

最後に取り組んだIssue。当初は自分でjsファイルを用意してプレビュー機能を実装したが、別で同じファイルがあり、DRYにしたところ数行の修正で完成した。スッキリ！

レビューしたPull Request

  • 13個のPull Requestをレビューした
  • 合計31ポイント

フッターにブログへのリンクを追加 by fuwa-syugyo · Pull Request #5435 · fjordllc/bootcamp

Good First Issue。ちょうど同じタイミングでの参加だったチームメンバーと一緒にモブプロを企画し先輩らに助けてもらいながら取り組んだ。

user-practice-progress.vueをVueMounterに対応させる by choco0809 · Pull Request #5479 · fjordllc/bootcamp

VueMounterを利用したマウント方法になっているかどうかの確認方法を学んだ。DevToolsを使用してブレークポイントを指定する方法。

プラクティスの日報タブに表示される日報一覧にVueComponentを適用させた by yuma-matsui · Pull Request #5505 · fjordllc/bootcamp

VueComponentに関する内容。VueComponentの復習になった。

確認通知を[abstract_notifier]に置き換えた by choco0809 · Pull Request #5506 · fjordllc/bootcamp

gem letter_opener_webを使って通知メールを確認 する方法を学んだ。

タグ別ユーザー一覧ページの title タグを変更 by hikarook94 · Pull Request #5528 · fjordllc/bootcamp

Good First Issue。一緒にモブプロしてレビュー依頼までいただく。チームメンバーとわいわいと取り組めて楽しかった。

FirefoxでD&Dによる画像添付ができるようにした by siroemk · Pull Request #5613 · fjordllc/bootcamp

gemにPRを出して対応されていたPR。難しいレビューだった。gemへの対応はよくわからなかった。

提出物ページの「直近の日報」をVue化した by pachikuriii · Pull Request #5618 · fjordllc/bootcamp

Vue化の勉強になった。自分が取り組んでいるIssueの内容と近く参考になった。

みんなのブログ一覧ページを作成 by siso25 · Pull Request #5646 · fjordllc/bootcamp

大きめのIssueのPRレビュー対応。システムテストが不十分な気がしたが、結果的には最低限のテストを実装されており問題なかった様子。

管理ページにプラクティス一覧を追加した by fuwa-syugyo · Pull Request #5666 · fjordllc/bootcamp

テストが不十分かなと提案したが結果は不要だった。テストはどこまで必要か？レビュー難しい。

非画像ファイルがアップロードされた時リンクで表示されるようにした by keiz1213 · Pull Request #5659 · fjordllc/bootcamp

Issueで求められていることに対してnpmを使うことを検討し、PRのコメント内でスクラムマスターへ提案しているやり取りが参考になった。

Watchタブでも日報作成とマイプロフィールの確認をしたい by ksmxxxxxx · Pull Request #5758 · fjordllc/bootcamp

Good First Issue

フッターにFBC Contributorsのリンクを追加 by dowdiness · Pull Request #5901 · fjordllc/bootcamp

Good First Issue。ペアプロした。

[アンケート機能]アンケートを作成できるようにした by AyakaTakashima · Pull Request #5690 · fjordllc/bootcamp

ラストのレビュー依頼にして初めての5ポイントのIssueだった。ボリューミーなPRで大変だったが非常に勉強になった。今までで一番多くの項目でレビューすることができ、自身の成長を感じた。

おわりに

4ヶ月間、終わってみるとホントあっという間でした。数日詰まって手も足も出なかったり苦しい期間もありましたが、チームメンバーに助けてもらい乗り越えることができました。まだまだ力不足を感じますし反省点も多いですが、すべてのIssueのPull Requestが無事マージされとても嬉しいです。

bootcampアプリに自分が書いたコードが反映され、機能が追加され、そして使ってもらえていると考えると「ここまで長かったけど成長したな〜」と少しだけ自分が誇らしく思えました。

チームメンバーのみなさま、約4ヶ月と長い間大変お世話になりました！

「技術書」の読書術　〜技術書を血肉にする術〜

書評

はじめに

kakutanitalk2022で紹介されていた一冊。フィヨルドブートキャンプのチーム開発を終え一区切りついたので、これから新しく技術書を読む助けになればと思い読んでみることにしました。

【書評】「技術書」の読書術 達人が教える選び方・読み方・情報発信&共有のコツとテクニック

概要

www.shoeisha.co.jp

技術書にフォーカスし、選び方や読み方、読書管理やアウトプットなど、コツやテクニックをまとめた内容になっています。

イラストや図解なども多く、文面も平易な言葉で綴られており読みやすい内容でした。巷に読書術の本は多いですが「技術書」に対しての向き合い方に悩んでいる方には、読んで損はないオススメできる一冊です。

何を読んだらいいのかわからない？

著者も基本的には物理本での読書を推奨しており、人によって好みはあるとは思いますが私も同じ考えなので共感できました。

まず冒頭で「選び方」について書かれていますが、最近は書店で本を探す機会がめっきり減ってしまったので、書店での選び方のヒントは助けになりました。今は積読がまだまだあるし、読みたい本もたくさんあるので「何を読んだらいいのか？」と悩むことはないですが、選び方に悩んでいる方にはヒントになると思いました。

悪書・良書を気にする必要はない

湯水のように時間やお金があれば、いろんな技術書を試しに購入し読んでみたいとは思いますが、限られたリソースの中で本を選択する場合、どうしてもハズレは引きたくないという考えが頭をよぎります。そんなときに、多くの人が勧める本だから間違いないと思って購入した本が自分に合わなかったりすると「この本の良さがわからない自分はダメなやつだ〜」と自己嫌悪に陥ることがあります。でも実際はそんなことなく、自分にとって内容が難しすぎたり、「良書＝相性の良い本」が成り立たないことも多々あるはずです。この節ではそんな自分のネガティブな感情が代弁されており、「わかる〜」と共感できる内容でした。「悪書との出会いは避けられない」とも書かれていましたが、世界に存在する約1億3000万冊（Google調査）の中から選んで読書を続けていれば、悪書（自分にとって相性の悪い本）との出会いは避けることはできません。

最も避けるべきことは読書そのもを止めてしまうことです。

たとえ今悪書だと感じた本でも、時間が経てば良書になることだってあるし、99％の内容は役に立たなくても1%はキラリと光る何かがあるかもしれません。悪書に出会ったときにどう向き合うのかを考えることが重要だと思いました。

読書にかける時間

合わない本に時間をかけてもしかたがない

悪書の項目に繋がりますが、自分には合わない本、今読むべきではない本との向き合い方について学べました。サンクコストを例に説明がありましたが「今の自分と合っていない」と感じたらスパッと止めて次に行くことも大事だと思いました。ダラダラと読んでもしかたない。特に技術書の場合は尚更そうだと思いました。目的が読書になってはいけない。今自分は何を技術書から得たいのか？常に自問し読書にかける時間を意識していきたいと思いました。

読書ノートや読書記録

各種ツールやTipsなどが紹介されており、2022年11月出版の本なので情報も新しく参考にできる内容も多かったです。 実際試したことや現在進行形で使っている内容もあったので、自分が使っているツールなどを紹介。

Scrapbox

著者は読書ノートとして利用されているようですが、自分も1年ほど前から利用していますがとても便利で気に入っています。キーワードをリンクできるのが特徴で「リンクとリンクを繋ぐ = 知と知を繋ぐ」イメージで、知識が繋がっていく感覚があり、学んだ内容を忘れくいし思い出しやすいと感じます。

ブクログ

読書メーターも紹介されてましたが、私はブクログを読書記録として活用しています。SNS機能は使わず読書記録のみとして使っているのでブクログを選択していますが、SNS機能を使いたい方は読書メーターの方がオススメのようです。

たくさんアウトプットしよう

中国の欧陽脩が提唱した文章を上達させるための3つの条件です。

三多

  • 看多（かんた）：多くの本を読むこと
  • 做多（さた）：多くの文を作ること
  • 商量多（しょうりょうた）：多く工夫して推敲すること

この言葉にもあるように、たくさんインプットして、たくさんアウトプットして、そして改善する。シンプルですけどこれが難しい...。特にアウトプットして改善してとなると、面倒だな...と動きも鈍くなる。でもやっぱり本質はこれだし、とても大事なことなんだと改めて思いました。

アウトプットの結果を気にしない アウトプットに遅いということはない

今まさにブログを書きながら感じていますが、結果のことや今さらやっても意味がないとか、そんなこと気にする必要はない。ほんと大事なことですね。

いつでもどこでもアウトプットしよう

同じく欧陽脩の言葉が紹介されていました。

三上

  • 馬上：馬に乗った移動中
  • 枕上：布団で寝ているとき
  • 厠上：トイレの中

ここではアイデアを忘れず記録するために、色々とTipsが紹介されています。私はあまり細かいことはせず、デスクから離れた時はスマートフォン1台に集約してメモを取るしくみでやってますが、参考にして取り入れたいと思いました。

散歩でアイデアが降ってくる？

すべての最高の考えは、散歩することにより思いつく　ーフリードリヒ・ニーチェ

私も三上の中でも特に馬上時にアイデアが思い浮かぶことが多いです。散歩は気軽にできますし、何より健康にもいいしオススメです。本来なら歩くことで疲れるはずなのですが、逆に疲れが取れるたりするので意識して外に出るようにしています。そういえば、これから開発する自作サービス案も馬上時に思い浮かんだものです。

まとめ

既知の情報も多かったですが、技術書に対して向き合い方を改めて学べてよかったです。今回は取り上げていないですが、手を動かしながら読み進める方法やマーキング読書法、パラシュート勉強法など、定番の読み進め方もしっかりと網羅され丁寧に解説されており、読書術の最初の一冊として選んでもよい本ではないかと思いました。

「本は実質無料」とは言い得て妙であり、これからも本から学んだことを血肉とするべく、いろんな本との出会いを楽しんでいければと思います。

本をよく読むことで自分を成長させていきなさい。本は著者がとても苦労して身につけたことを、たやすく手に入れされてくれるのだ 　ーソクラテス

kakutanitalk2022 のオープニングトークに登壇しました

イベント LT会

はじめに

2022年12月19日に開催されたFJORD BOOT CAMP（以下FBC）主催のイベントに登壇しました。せっかくなので、その時の感想をブログに書きたいと思います。

角谷トーク2022

動画はこちら

youtu.be

2022年もオンラインで開催されました。

2020年から今年で3年目を迎える同イベント。角谷さんからFBC生に対してメッセージをいただくというのが会の趣旨になりますが、YouTube Liveでの配信ということもあり、FBC以外の方も多く参加されていました。

そして今回は前回と違い、卒業生と受講生によるオープニングトークが行われました。

光栄にもオープニングトークに登壇できたので、記念にブログに書いておこうと思います。

勢いは大事

確かオープニングトークを募集しているのを知ったのは告知から2日後だったと思いますが、登壇枠が早い者順と書いており「これは貴重な経験ができるチャンスだ！」と思い、そのまま何を話すのかも決めずに勢いで登壇を申し込みました。

トークテーマについて悩む

「オープニングトーク=前座」ということで、角谷さんのメイントークへ行くまでに場を温めることが前座として与えられた使命だ！と勝手に思い込み、トークテーマについて考えてみることにしました。

しかし勢いで申し込んではみたもののアイデアが浮かばず...。悩んでいたころ、同じく登壇予定の卒業生のトミーさんといっしーさんと一緒に壁打ちする機会がありました。そのとき、色々とアドバイスをもらえ、トークのメインのテーマであるgem開発のアイデアを得ることができました。トミーさん、いっしーさんありがとう！

gem開発

テーマが決まれば早速gemを開発しようということで、トミーさんに協力いただきgemの開発を進めていきました。オープニングトークのネタとして仕込むために開発したgemではありますが、開発過程において色々と勉強になりました。

トミーさんにはペアプロにて色々とアドバイスいただきホント感謝です！

kakutaniquiz

ちなみこちらが開発したgemです。以前に開発したnpmのYAZAWAをベースにgemに応用してみました。

github.com

スライド作成

FBCのプラクティスからは一旦離れ、すべての時間をスライド作成（gem開発も並行して）に注ぎました。

トークの主となるテーマが決まりましたが、さすがにこのネタ1本で10分弱の持ち時間に立ち向かうのは無謀過ぎると冷静になり、スライド全体を作成しながらトーク内容を練っていきました。gem開発を最後のオチに持っていくことは決めていたので、そこまでの前フリを意識しスライド全体を作成しました。

多くの方に聞いてもらえるチャンスということもあり、自分を少しでもアピールできればと思い自己紹介を多めにしました。

speakerdeck.com

いざ登壇へ

自分の発表は、46:20〜

結論から言うと…準備不足＆反省点の多いトークでした...。

トークも持ち時間の10分を超えてしまい2分もオーバーしてしまいました。改めて動画で見直しましたが、緊張から早口になったりと準備不足が見てとれました。特に前半部のダラダラと自己紹介しているトーク箇所は今思えば丸ごと削ってもよかったと思います（長すぎる...）。最後のクイズをインタラクティブに行うところも、コメントの流れにタイムラグがあり上手く拾えませんでした。

正直、自己採点はとても低い点数とはなってしまいましたが、観てくれた方の中から温かいコメントをいただけたのが唯一の救いでした。（コメントいただいた皆さん！本当にありがとうございました🙏）

先ほどイベントページを確認してみると、なんと221名！もの参加者が（驚）実際に発表している時は意識する余裕はなかったですが、こんな大人数の前で発表したのか...と、改めて変な汗が出てきました...😨

まとめ

反省点の多いイベント登壇でしたが、貴重な経験ができとても勉強になりました。LTやイベント登壇は「慣れ」が必要とは言いますが、今回イベントに登壇したことにより、だいぶ度胸が付いたのは間違いないです。またこの規模のイベントに参加できたのは大きな自信にもなりました。

そう言えば、落ち込んでいるときYAZAWAに悩みを打ち明けたらこんな答えが返って来ました。

何事も経験ですね。めげずに挑戦し続けたいと思います！

後日談

なんと、あのyancyaさんから、kakutaniquizにプルリクをいただきました！

これは嬉しかった！😆

情熱プログラマー 〜閉塞感をブチ壊そう〜

書評

はじめに

新年あけましておめでとうございます。

昨年関わった全ての人に感謝申し上げます。今年もどうぞよろしくお願いします！

2022年は1記事しか書かなかったブログを2023年は定期的に書いてみようと思います。そんな新年一発目のエントリーです。

昨年は、ブログの代わりにScrapboxで学習メモを中心に大量にアウトプットしていましたが、人に見られない前提なのもあり自分さえ分かればいいと構成も文脈もめちゃくちゃ。雑なアウトプットが多く、人に伝える文章力が落ちた気がしています。ブログはブログで書くならしっかりした内容のものをとつい意気込んでしまい、中途半端な下書きを乱発…。結局内容に納得できず、何も書き終わらずでした...（反省）

今年は、その反省として定期的にエントリーしてみようと思います。Scrapboxのレベルでのアウトプットは見るに堪えないですが、時間を掛けてしっかりと書き上げるブログとかにはせず、自分以外に伝わる文章を書くことを目的にまずは小さく取り組んでみようと思います。

まずは簡単で取り組みやすい書評ブログから。質と量は度外視でとにかく書いて投稿までをゴールとします。執筆時間は1時間を目標に（今回は3時間掛かった）

【書評】情熱プログラマー　ソフトウェア開発者の幸せな生き方

後で読もうと積読してあった情熱プログラマーを年末に一気に読んでみました。

読む前までは、達人プログラマーとなんだかタイトルも似ているし、同じ系統の少し難しい本かなと思っていました。しかし読んでみると技術的な話しはほとんどなく、技術書というよりはビジネス要素多めなエッセイに近い内容でした。もっと早く読めばよかったと思います。

プログラマーや技術者だけに限らず、多くのビジネスマンにも共感できる普遍的な内容になっています。仕事への向き合い方、心構え、キャリア形成の道筋などを学べます。

振り返ると、プログラマーとして第一線で活躍している方から間接的に聞いたことのある話しも多く、この本の影響力の高さが伺えます。

プログラマーを職業として選択するなら間違いなく読むべき重要な一冊だと思います。

概要

www.ohmsha.co.jp

構成

  • 第1章 市場を選ぶ
  • 第2章 製品に投資する
  • 第3章 実行に移す
  • 第4章 マーケティング...スーツ族だけのものじゃない
  • 第5章 研鑽を怠らない

上記のように5章に分かれているのですが、最初から読み進めてもいいし、興味のある章から順番に読んでも良いと思います。僕は、特に1、5章が好きです。

一番の下手くそでいよう

これは「いつも自分より優れた人たちと一緒に演奏する」という意味です。もちろん演奏に限らずあらゆることに当てはまります。

凄い人ばかりの中に飛び込むと、あまりの力の差に自信を失ったり、自分を惨めに思ったりすることも多いですが、その分とても大きく成長できるチャンスがそこにはあります。

過去の経験として自分の中にもあるのですが、これは本当に大切なことだと思います。そして逆についつい気を抜くとぬるま湯に浸かって成長のチャンスを逃してしまい後悔することもあります。環境ってホント大事だなと、この節を読んで改めて痛感しました。以前にkomagataさんがイベントで話されていた「漬け水に浸かる」がまさにそうですね。

speakerdeck.com

余談

この節のタイトルは、ジャズギタリストのパット・メセニーの言葉ですが、彼はピックを親指と中指でつまむ独特の持ち方をするようです。ちなみに、キース・リチャーズも真島昌利も親指と中指派で一緒ですね。

パット・メセニーはあんまり通っていないので詳しくないですが、パット・メセニーで思い出すのはやっぱジャコ・パストリアス！大好きな一曲。う〜ん、気持ちいい♪

www.youtube.com

ジャコのドキュメンタリー映画もぜひ

www.youtube.com

愛せよ、さもなくば捨てよ

この節は「情熱を持て」この一言に尽きます。

人生100年時代と言われる中、色々と考え方や意見の相違はあると思いますが、個人的には死ぬまで働きたいと思ってる方なので仕事に対して「情熱」を持てるかどうかは非常に重要なテーマです。情熱を持てる職業に就きたい。との思いからプログラマーを職業として選択した自分にとっては、とても胸に響く節でした。

昨日よりよく

このシンプルな方法のいいところは、プロジェクトの完了やソフトウェアの改善といった当面の目標に使えるだけでなく、もっと高次元の目標にも使えることだ。

先日のkakutanitalk2022を思い出しました。(イベントに登壇したブログも書こう)

「大きく考え、小さく始める」

www.oreilly.co.jp

以前と比べると小さく始め、少しづつできることも増えてきました。しかし当初は大きく考えていたことも小さくなり、そしてせっかく小さく始めて続けてきたことも止まってしまいそうで心折れそうな時もありました。

「昨日よりよりコードが読めるようになった」「昨日よりテストが書けるようになった」

何でもいい。昨日よりよくなっていると信じ続けること。「昨日よりよく、去年よりよく」前に進んでいきたいと思います。

まとめ

閉塞感

監訳者のあとがきに書かれているのですが「これって最近出た本だっけ？」と思うほど、昨今の世の中全体が閉塞感に包まれていると感じます。終わりの見えない新型コロナやウクライナ問題、止まらないインフレに円安、それから防衛費のニュースなど危機感も加わりこれからどうなっていくのだろうか？と不安は拭えません。

政府が悪い？役人が悪い？マスコミが悪い？.........（略）貧困が、社会が？

自己責任論とかいろいろと脱線して来るので言及はしませんが「現実に直面し、自ら行動しなくちゃ何も変わらない」これは普遍的な事実だと思います。

正直、自分の人生が拓けていないことに世の中の多くの問題と同様に閉塞感を感じ、不安や焦りが消えないのも事実です。しかしこの閉塞感をブチ壊すには、情熱を持って仕事に取り組み、幸せな生き方を選択できるようにこれからも日々精進していくしかありません。

今年は自分にも世の中にも良いニュースが流れることを願いつつ...

とにかくやれ。やれないはずはない

RubyMineを使ってgemを世界へ公開しよう！

Ruby

このエントリーは、フィヨルドブートキャンプ Part 1 Advent Calendar 2022 の15日目の記事になります。Part2のはるまきさん記事はこちらです！

昨日のエントリーは、

でした！

はじめに

フィヨルドブートキャンプ32期生のtamakiと申します。

今回のテーマは、RubyMineを使ってgemを世界へ公開しよう！ です！

gem開発のはじめの一歩のお役に立てれば幸いです。

対象読者

  • フィヨルドブートキャンプ生
  • gemの開発をしてみたい方
  • RubyMineを使ってgemを公開したい方

どんなgemを開発するの？

現在、gem開発を題材にしたプラクティスは発展編に移動されており必須ではありませんが、JavaScriptによる自作npmパッケージ開発を行うプラクティスが通常コースで用意されています。フィヨルドブートキャンプ生は、ここで自分の好きなnpmを開発しnpmパッケージサイトへアップロードし、世界へ公開するまでを行います。

個人的にこのプラクティスが凄く楽しくとても思い入れがあるため、今回はこのnpmを題材にgem版を開発していきたいと思います。

npmの紹介

まず先に開発したnpmを紹介したいと思います。

ところでみなさん、日々黒い画面を駆使しプログラミングを行うなかで、時には難解な問題が目の前で立ちふさがり前に進めなくなったことはないでしょうか？また黒い画面から離れても、人間関係、お金の問題、恋や夢、生きていく上でのさまざまな悩みを抱えたりしたことはないでしょうか？

そんな悩みにロックなアドバイスがもらえる！そんなnpmを開発してみました！

ぜひ！お使いのマシンへインストールしてもらい、黒い画面へ「yazawa」と入力してみましょう！きっとあなたの悩みはその瞬間から、YAZAWAのタオルのように宙に舞い消えていくことでしょう...！！

www.npmjs.com

Image from Gyazo

RubyMineを使ってgemを世界へ公開しよう！

環境

  • Ruby version: 3.1.2
  • Bundler version: 2.3.26

事前準備

bundlerをアップデート

開発に取り掛かる前に、bundlerをアップデートしておきましょう。

$ gem update bundler

ユーザー登録

RubyGems.orgにユーザ登録を済ませておくとよいでしょう。

gemの名前を決める

開発したgemを公開するにあたり、既存のgemと名前が被っていないか確認しましょう。今回は命名しようと考えていた名前「yazawa」がすでに登録されていたため、残念ですが「e_yazawa」として名前を付けることにしました。

gemの雛形を作成しよう

名前が決まったところで、まずはgemの雛形を作成しましょう。

RubyMineを立ち上げ、ホーム画面のNew Projectをクリックします。

以下の項目を選択し雛形を作成します。

すると、このようにgemの雛形を作成することができます。

❯ tree
.
├── CODE_OF_CONDUCT.md
├── Gemfile
├── LICENSE.txt
├── README.md
├── Rakefile
├── bin
│   ├── console
│   └── setup
├── e_yazawa.gemspec
├── lib
│   ├── e_yazawa
│   │   └── version.rb
│   └── e_yazawa.rb
├── sig
│   └── e_yazawa.rbs
└── spec
    ├── e_yazawa_spec.rb
    └── spec_helper.rb

5 directories, 13 files

gemのソースコードをGitHubと共有しよう

後ほどGitHubのリポジトリのURLが必要になるので先に共有を行います。

メインメニューから、Git > GitHub > Share Project On GitHub を選択します。

これで共有は完了です。

GitHubへアクセスし無事共有されているか確認してみましょう。

gemspecを編集しよう

コードを書いていく前にまずgemspecの編集が必要です。こちらを編集しないとbuildができず、またGitHubにpushもできないため事前に行います。

必須項目は、TODOと書いてある箇所になります。

  • summary : gem の要約
  • description : gem の説明
  • homepage : gem のホームページの URL。今はGitHubのURLを貼り付けておきます。RubyGemsへ公開後に差し替えます。
  • metadata["allowed_push_host"]: RubyGemsに公開したくない場合に設定する項目です。今回は公開するので削除しておきます。
  • metadata["source_code_uri"] : gem のソースコード URI。GitHubのリポジトリURLを貼り付けます。
  • metadata["changelog_uri"] : CHANGELOG.mdのURLを書く項目ですが、今回は用意していないのでGitHubのリポジトリURLを貼り付けておきます。

bundle installを実行しよう

今回のgem開発では、tty-promptという便利なgemを利用したいと思います。Gemfileに追記し、雛形で用意されているgemと併せてインスールを実行します。

# frozen_string_literal: true

source "https://rubygems.org"

# Specify your gem's dependencies in e_yazawa.gemspec
gemspec

gem "rake", "~> 13.0"

gem "rspec", "~> 3.0"

gem "tty-prompt"
$ bundle install

gem開発においてGemfile.lockをコミットするかどうか

bundle install 実行後、Gemfile.lockが生成されます。Gemfile.lockについては、コミットするかどうか議論の対象となっているようですが、今回のgem開発においてはコミットしない立場を選択したいと思います。.gitignoreへ追記しておきます。

参考

メイン機能を実装しよう

メソッドで使用するデータは、別ファイルで用意しておきました。

├── lib
│   ├── database.rb
│   ├── e_yazawa
│   │   └── version.rb
│   └── e_yazawa.rb

メソッドはこんな感じにしてみました。

# frozen_string_literal: true

require_relative "e_yazawa/version"
require "tty-prompt"
require_relative "./database"

module EYazawa
  class Error < StandardError; end

  def self.advise
    prompt = TTY::Prompt.new
    your_name = prompt.ask("ホワット ユア ネーム？")
    choices = Message.advise(your_name)
    question = "YAZAWAにアスクしたいことをセレクト！"
    answer = prompt.select(question, choices)
    puts answer
  end
end

実行コマンドを作成しよう

コマンドライン上で動かすには実行ファイルが必要になります。

exeディレクトリを準備し、その中に実行ファイルを作成します。

├── exe
│   └── e_yazawa

#!/usr/bin/env ruby

require 'e_yazawa'

EYazawa.advise

実行ファイルに権限を与えましょう。

$ chmod 755 exe/e_yazawa

$ ls -l
-rwxr-xr-x  1 username  staff  56 12 13 21:15 e_yazawa

実行してみよう

実行コマンド

$ bundle exec exe/e_yazawa

実行結果

Image from Gyazo

無事動きました！

buildしよう

gemspec ファイルを元にして Gem パッケージを作成します。buildすることでgemを使えるようにします。

メインメニューから、Tools > Gem > Build Gem を選択します。

/bin/zsh -c "bash -c 'env RBENV_VERSION=3.1.2 /usr/local/Cellar/rbenv/1.2.0/libexec/rbenv exec gem build e_yazawa.gemspec'"
  Successfully built RubyGem
  Name: e_yazawa
  Version: 0.1.0
  File: e_yazawa-0.1.0.gem

Process finished with exit code 0

e_yazawa-0.1.0.gemファイルが生成されます。

.gemファイルはGitで管理したくないので .gitignoreファイルに*.gemと追記しておきます。

公開しよう

メインメニューから、Tools > Gem > Push Gem を選択します。

実行ツールウィンドウに表示された指示に従い、EmailとPasswordを入力します。

RubyGemsへアクセスし公開されていることを確認してみましょう。

rubygems.org

バージョンアップ手順

追加機能を実装したり、バグ修正などを行った場合はバージョンアップしてRubyGemsを更新しましょう。手順は以下となります。

  • version.rbのバージョンを更新する
module EYazawa
  VERSION = "1.0.1"
end
  • 更新内容をcommitしGitHubへpushしておく
  • buildする Tools > Gem > Build Gem
  • RubyGemsへpushする Tools > Gem > Push Gem

参考

おわりに

最初は難しいかな？と思っていたgemの公開ですが、RubyMineを使うと一瞬で出来てしまいました。もちろん、コマンドライン上からも同じく実行できますので、気になった方はぜひお試しください！！

将来は誰かの役に立てるそんなgemを開発できるように日々精進してまいります！！

明日のアドベントカレンダーは？

せっかくなのでYAZAWAに聞いてみましょう！

Image from Gyazo

最後までお付き合いいただきありがとうございました！

それでは！メリークリスマス！！

おーい磯野、ペアプロしようぜ！

ペアプロ

フィヨルドブートキャンプ Advent Calendar 2021

このエントリーは、Part1の21日目の記事です。

昨日20日目のエントリーは、

でした。素敵な記事ありがとうございます〜✨

はじめに

フィヨルドブートキャンプの32期生のタマキと申します。現在はプログラマ転職を目指し、RailsとJavaScriptを学習中です。

テーマはペアプロです。以下（中島メンターと磯野くん）のやり取りをご覧いただき、その効果、楽しさを感じてもらえると幸いです。

著者がペアプロを経験し学んだこと、個人的な思いや考えがミックスされた記事ではありますが「ペアプロって楽しそうだな〜」「ペアプロやりたいな〜」と、興味を持っていただけると嬉しいです。

対象読者

注意事項

今回題材として扱うペアプロは、実務で行う実践的な内容（ペアプロによるソフトウェア開発）とは違い、スクールで学習している生徒側からの質問の延長線上に存在するペアプロを想定しています。プログラミングの他に、タスクの洗い出し、コードの設計など、ペア(メンターと生徒）になって行う活動全般を含みます。

本題

あらすじ

磯野ぴよるど君は、フィヨルドブートキャンプに通う生徒でプログラマを目指し日々学習中です。 そんな中、あるプラクティスで長い間詰まっており、日々悶々とひとり悩み苦しんでいました。 そんな彼を見かけ心配した中島メンターは、ある日、磯野くんへ電話を掛けたところから物語は始まります。。。

登場人物

🐔 中島メンター

フィヨルドブートキャンプのメンターを務める凄腕プログラマ

札幌市在住

趣味は野球で右投げ左打ち。日ハムとスープカレーが好き

🐤 磯野ぴよるど

フィヨルドブートキャンプに通う32期生

ノルウェー生まれの世田谷区在住

最近太り気味で乾燥肌なのが悩み。毎日の筋トレと角の保湿は欠かせない

ペアプロって何ですか？

🐔中島：おーい磯野、ペアプロしようぜ！

🐤磯野：あれれ！？中島メンターじゃないですか。急にどうしたんですか？

🐔中島：磯野くんの日報を確認してたら詰まっていてツラそうだったから、ペアプロでもどうかな〜って思って連絡してみたよ。

🐤磯野：ペアプロって何ですか？おいしいですか？

🐔中島：食べ物ではないよ...(汗) フィヨルドブートキャンプ Part 1 Advent Calendar 2021 、12日目のcafedomancerさんの記事に詳しく書かれているので読んでほしいんだけど、ペアプロは、ペアプログラミングの略で、磯野くんが抱えている問題を解決する手がかりになる魔法のようなプログラミング手法だよ。

🐤磯野：へー、初めて知りました。このようなプログラミング手法があるんですね。ぜひお願いしたいです！

🐔中島：ヨシ！それじゃあ一緒にペアプロしてみよう。以下、紹介している本の記事もお薦めなので時間あるときにぜひ読んでみてね。

🐤磯野：おぉぉ〜！これは、テスト駆動開発で有名なt_wadaさんが書かれているペアプロについての記事ですね！面白そう！

gihyo.jp

基本のスタイル

🐤磯野：ペアプロはじめてなのですが、どんなスタイルでやるのですか？

🐔中島：「ペアプロはこうでなければならない」という事細かな明確なルールはないけど、ある程度は以下のスタイルに沿って実施されることが多いよ

  • 1つのディスプレイ、マシン、キーボードを共有する
  • ロール（役割）を決める。ドライバーとナビゲーター
    • ドライバー：　キーボードを操作しコードを書き進めていく人
    • ナビゲーター：　ドライバーの横（画面の向こう側にいる人）に座り、ドライバーと会話しながら導く人
  • ペアの種類（3パターン）
    • 新人とベテラン
    • ベテランとベテラン
    • 新人と新人

🐤磯野：へー、なるほど〜。ちなみに中島メンターとはオフラインでは会うことは難しいので、今回はDiscordを使った画面共有でペアプロを行うのですね！

🐔中島：そうだね。ちなみにペアのパターンとしては、「新人とベテラン」の種類に該当するよ。フィヨルドブートキャンプの受講生同士のペアプロも可能だけど「新人と新人」のパターンは立ち往生して先に進めなくなることも多く、注意が必要だよ。

🐔中島：また、ロール（役割）を交代して行うと効果的だけど、新人とベテランのペアの場合は、新人が主にドライバーを務めるケースが多いかな。ドライバーは理解できなかったときにはブレーキを踏んでナビゲーターに助けてらもらえるし、手を動かすことでより理解が深まるからね。

時間はどれくらい？

🐤磯野：ちなみに、今夜は地域のRubyコミュニティに参加したいので、それまでの時間なら空いてますが、ペアプロはどれくらいの時間やるのですか？

🐔中島：いい質問だね。基本のスタイルでも伝えたように明確なルールはないので、時間もその時々によって変わるよ。ワシの経験則にはなるけど、短いと5分程度から、長いと3時間以上と、取り掛かるプログラミングの内容によって時間は変わってくるね。上で紹介した本の中でt_wadaさんは、2時間くらいで到達できそうな目標を設定しペアプロを実施されていることが多いようだね。ただワシの感覚では、フィヨルドブートキャンプの場合は、生徒からの質問の延長線上にペアプロが存在しているので、ガチガチにスタイルを決めてやることは少ないと思うよ。

ペアプロを申し込もう

🐤磯野：まだ朝の9時なので大丈夫そうですね！でも、中島メンターの貴重な時間を奪ってしまい心苦しいです…

🐔中島：そんなことないよ。もちろん、磯野くんが抱えている問題解決を目標に取り組むことにはなるので、新人（磯野くん）に大きなメリットがあるのは間違いないけど、ベテランのワシにも教えることで自分のスキルの棚卸しにもなるし、学べることも多いんだよ。

🐤磯野：そうなんですね…(嬉泣）

🐔中島：今回はワシから声を掛けたけど、今後は磯野くんから積極的にペアプロを申し込むといいよ。フィヨルドブートキャンプならDiscordに専用のチャンネルもあるしね！

🐤磯野：でも、例えば利害関係の少ないコミュニティでペアプロをお願いしたいときもあると思うのですが、そういう時はさすがに引け目を感じてしまいますね...

🐔中島：たしかにその気持ちはわかる。でも、あるコミュニティの主催者がワシと同じことを言っていたんだけど...

「誰しも最初からできる人はいない。最初はみんな初心者だ。我々も多くの先輩方にペアプロしてもらい成長してきた。今の自分があるのはRubyコミュニティの存在が大きい。今は自分が受けてきたものをコミュニティを通じて好きで返しているだけ。気にする必要はない」

🐔中島：磯野くんもコミュニティに参加してわかると思うけど、多くの人はプログラミングが好きだからやっているし、ペアプロをお願いして嫌がる人はコミュニティには参加してないんじゃないかな〜

🐤磯野：神！（嬉泣) そんなこと言われたら惚れてまうわぁ...

🐔中島：そうだね(笑) ペアプロは、現代の徒弟制度みたいなものかもね。磯野くんも成長したら、後輩らにペアプロをすることで、Rubyコミュニティを盛り上げていってね！

ペアプロをお願いする姿勢

🐔中島：『授人以魚 不如授人以漁』......

🐤磯野：んんん！？急にどうしたんですか？

🐔中島：ごめんごめん。中国の古い格言（諸説あり）でさ、こんな言葉があるんだよ。知ってるかい？

「魚を与えれば一日の飢えをしのげるが、釣り方を教えれば一生食べていける」

🐤磯野：魚は大好きですが、この言葉は知りませんでした...(汗)

🐔中島：正直なところ、答えを教えるほうが、聞き手も答える側も手短に済むよね。でもそれでは、聞き手側の成長には繋がらないんだ。ペアプロに限らずだけど、「魚をください」ではなく、「魚の釣り方」を教えてもらう。この姿勢はとても大事だから覚えておいてね。もちろん、ペアプロ以前にまず最初は「魚の釣り方」を自分で調べて何とか問題を解決できるように努力することはマストだよ。

🐤磯野：深いですね...胸に突き刺さります。ぼくはついつい気が焦ってしまい「魚をください」と質問していることが多いので、この格言は腕にタトゥーとして刻んでおきます...

🐔中島：腕じゃなくて心に刻んでね(笑) でも、フィヨルドブートキャンプで学習しているほとんどの生徒は、卒業、就職を目標としている人が多いので、この考え方はとても大事だね。komagataさんがブログでも書かれているけど、 戦力として計算できるエンジニアになるには、「魚の釣り方」を身につける必要がある。エンジニアとしては自走力が必ず必要になるからね。「なぜプログラミングを学んでいるのか？」その目的を見失わないようにね！

ペアプロ前の事前準備

🐤磯野：ペアプロをはじめる前に必要な準備はありますか？

🐔中島：Discordなどに繋いでの画面共有にて実施していくので、マイクやディスプレイ、エディタは問題なく使えるか？使い方に不安がある場合は事前に調べておくといいよ。あと、メモ用の紙やペン（iPadやWeb上のツールでもOK)、そして飲みものは用意しておくと安心だね。「冗談抜きで、水、だいじ」

🐔中島：それから一番大事なことだけど、ペアプロで扱う内容は事前に準備しておこう。必要であれば関連書籍、Webサイト、コードや現状の問題（エラーなど）、調べたこと、試したこと、考えたこと、詰まっていること、このあたりをペアプロ前にまとめておくとベストだね。

🐤磯野：準備大事〜。ペアプロの相手に伝えたい内容を事前に準備しておくと焦らずにスムーズに対応できますね。あと質問は、相手にエスパーさせないことも重要ですよね。

🐔中島：そのとおり！上手な質問については、こちらの伊藤さんのブログ記事もおすすめなので読んでみてね。

ペアプロの進め方（コードを書く前にやること）

🐤磯野：最初は何からはじめていくのですか？

🐔中島：まずは、基本的な進め方を説明するよ。

  • コードを書く前に方向付けを行う
  • 最終目標を定める。（ペアプロを行う時間内で目指す最終目標を決める）
  • ペアプロに入る前にTo-Doリストを作成しておく。
  • To-Doリストは、ナビゲーターが手にしている「地図」のようなもの。
  • 完璧なリストには拘らず、ざっくりしたものでOK。その都度、修正、更新していく。
  • ポイントは、タスクを小さくすること。

🐔中島：必ずしも上記のように進めていくわけではないけど、ひとつの指針として覚えておいてね。

コードを書きながら会話し考えを共有する

🐤磯野：今日のカツオのたたきはおいしかったな〜

🐔中島：旬だからね〜、っておい！......(困) それはさておき、ペアプロで一番大事なのは「会話」だよ。考えていることを口に出すこと。これから書こうと思っていることや、迷ってモヤモヤしていることをまずは言葉にしてみる。ひとりで悩まずにペアプロで取り組んでいる問題、悩みを共有するわけだね。

🐤磯野：独り言のようなものでもいいのですか？

🐔中島：もちろん！具体的なことに越したことはないけど。頭に浮かぶ言葉を口に出すことが大事だよ。沈黙が一番ダメ。「難しい〜、わからない〜」でも、磯野くんの考え、気持ちを言葉にしてね。

🐤磯野：なるほど。考えを共有することで、ナビゲーターはドライバーの考えを聞き、助力してくれるのですね。

ロール（役割）を交代する

🐤磯野：ロールケーキが食べたいな〜

🐔中島：君は食べ物の話しばかりだな〜(困)

🐔中島：ペアプロでは、ロールを交代すると効果的だと言われているよ。主に以下の3つのスタイルでロールを交代することが多いかな。

  • 時間で交代する
  • ステップで交代する
  • 自由に交代する

🐔中島：冒頭でも説明したけど、新人側がドライバーを務めることが多いので、このへんは相手（ベテラン）と相談しながら決めていくのがよいね。

🐔中島：あと、長い時間ペアプロするときは適時休憩を挟んでね。区切りがいいところで、ふりかえりをしてもいいかもね。

ペアプロをはじめてみよう

🐔中島：ここまで来たら、いよいよペアプロをはじめてみよう！

🐤磯野：まだ不安です…(震)

🐔中島：最初は誰でも不安だよ。でも、勇気を出して一歩踏み出せば世界が広がるはずだよ。さあ、一歩踏み出してペアプロの世界に飛び込もう！！

ペアプロの効果

数日後・・・・・

🐤磯野：中島メンターお久しぶりです〜

🐔中島：お〜、磯野くん元気そうだね〜

🐤磯野：あの日からペアプロの良さを知ってしまい、最近はちょくちょく色々なところでペアプロしてます！

🐔中島：いいね〜、どんな効果があった？

🐤磯野：いろんな効果を感じているので一言ではいい表せないのですが、以下のような効果を感じています！

  • 問題解決

    • デバッグ手法を学べる
    • タスクの洗い出し、切り分け方を学べる

  • コードレビューによるさまざまな効果

    • レビュー内容がリアルタイムにコードへ反映される
    • 読みやすく保守性に優れたコードを学べる
    • ミスが生まれにくい。二人の目と脳とで監視することで抜け漏れを防止できる

  • 思考の整理

    • 今自分が考え、これから行うことは何なのかを常に相手に共有することで、思考の整理ができる。コードを書いてから間違いに気づくのではなく、話している最中に気づけることも多い

  • 知識と学びの共有

    • Git操作、エディタの便利機能など、凄腕プログラマが日常使っている技術を目の当たりにできる
    • 技術力の底上げ、高い教育効果を発揮
    • 結果(コード)だけではなく、過程（プログラミング）を共有することで得れる知識やスキル
    • 暗黙知の共有（経験や勘に基づく知識のこと。言葉で表現が難しいもの）勘所やバグの原因究明など、ドキュメントでは伝えづらい重要なスキルを共有できる

🐤磯野：などなど、さまざまな効果を感じています。そして、何よりペアプロは楽しい！メンターやアドバイザーはもちろん、卒業生や現役生、外部コミュニティでもペアプロを体験したのですが、どれもこれも楽しく学びの多いペアプロでした！

🐔中島：楽しいことは何よりだね。ペアプロは情報伝達効率を最大にすることでプログラミングの質を高めることができる、本当に素晴らしい手法だと思う。これらも色々な壁にぶち当たると思うけど、ペアプロを活用して困難を乗り越えて言ってね！

🐤磯野：はい！ありがとうございます！

おまけ

AIとペアプロ？

🐔中島：RubyWorld Conference 2021のMatzの基調講演は観たかい？

🐤磯野：まだ観ていないですぅ…

🐔中島：MatzがRubyの未来のヴィジョンについて話しているんだけど、近い将来、Rubyを使ったツールで「AIとペアプロ」ができる日がくるかもしれないよ。

🐤磯野：AIとペアプロ！？凄い未来だ〜！

🐔中島：52:25 ぐらいからその話しになるので、興味があったら観てみてね♪

youtu.be

モブプロって何ですか？

🐤磯野：中島メンター、そういえばモブプロなる美味しそうな名前もよく耳にしますがこれはなんですか？

🐔中島：お！さすがお目が高い。モブプロはね、ペアプロを発展させた手法だよ。

🐤磯野：へ〜、なんかこれも面白そう！

🐔中島：モブとは「群衆」のことで、3〜5人を想定したペアプロを発展させたプログラミング手法のことを指すよ......と、今日はこのへんで詳細は次回のブログにまとめたいと思うから、その時のお楽しみに！

  • 輪読会でレインボー
  • 三鷹でわいわいアプリ作成
  • はるぐち先生とじゃんけんプログラム

以上の3テーマを予定しているよ

おわりに

最後までお付き合いいただきありがとうございました。

今までペアプロに何度も救われた身として、この記事を書けたことを嬉しく思います。

ペアプロ未経験の方へ少しでも参考になれば幸いです。

次回予告

さ〜て、明日のアドベントカレンダーは、

の2本です！

それではまた明日もみてくださいね〜！ んぐぁぐぐ！！

チェリー本輪読会　最終週まとめ

輪読会

f:id:shirotamaki:20210619091936p:plain

🍒 はじめに

チェリー本輪読会の第17週目(最終週)のエントリーになります。

輪読会の概要については第1週目にまとめています。

🍒 輪読会 第17週目(最終週)まとめ

第12章12.1.1〜付録(あとがき)まで

期間：2021年9月13日〜2021年9月17日

かれこれ3ヶ月前に終わった輪読会ですが、今更ですが最終週を書きました！

個人的な備忘録（思い出ログ）として書いています。

requireの単位はライブラリ

組み込みライブラリ以外のクラスやモジュールを使う場合は、requireで事前にライブラリを読み込んでおく必要があります。requireしている単位はひとつひとつのクラスやモジュールではなく、ライブラリになります。requireで読み込んでいるライブラリは慣習的に小文字で書くことになっています。gemの命名規則について以下ブログが参考になりました。

推奨される RubyGem の名前の付け方 - yu8mada

Rubyのバージョン管理

Rubyを使用する場合、なるべく最新のものを利用することが推奨されています。

Rubyのバージョン以下のコマンドで確認できます。

❯ ruby -v
ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [x86_64-darwin20]

x.y.z

  • x majorバージョン
    • アーキテクチャやコンセプトの変更、完全な書き換えがあった場合に増加する
  • y minorバージョン
    • クリスマスごとに増加する。大幅な仕様変更や機能追加が行われる。
    • 後方互換性のない仕様変更が入る可能性がある
  • z teenyバージョン
    • 軽微な使用変更、小さな機能追加が行われる。
    • API互換性を維持するセキュリティフィックス（修正のこと）やバグフィックスが行われる

Ruby 2.1.0 以降のセマンティックバージョニングについて

セマンティック バージョニング

Semantic Versioningとは、ソフトウェアのバージョニング方法の一つです。

「1.23.45」といったように.で区切った3つの数字で表されます。

セマンティック バージョニング 2.0.0 | Semantic Versioning

Gemfileでgemのバージョンを指定する記号の意味

バージョンをGemfileに指定して管理ができます。バージョン番号を指定しない場合は、Bundlerにおまかせになります。

  • 1.7.2 特定のバージョンを使いたいときは、カンマ区切りで指定する
  • >=1.7.2 1.7.2以上であれば何でも良い場合は>=を使う
  • ~> 1.7　~> 悲観的バージョン演算子と呼ぶ。マイナーバージョンは上げてもいいが、メジャーバージョンは上げたくない場合に使う
  • ~> 1.7.2 パッチバージョンは上げていいが、マイナーバージョンは上げたくない場合に使う

RubyMineでrbenvが反映されない件

RubyMineでのRubyバージョン切り替えは、rbenv shell コマンドで実行する必要があります。

scrapbox.io

その他バージョン管理の注意点

Rubyのバージョンごとにgemを管理する必要があります。

他のgemとの依存関係があり、gemのバージョン変更を試みる際、互換性の問題でエラーになる場合があるので注意が必要です。

自作gem入門

こちら教えていただいgemの入門記事です。

いつかgem作りにもチャレンジしてみたいと思いました！

qiita.com

あとがきの朗読(本人ver.)

なんと！最後のあとがきを著者の伊藤さんご本人に読んでいただきました！

この感動はなかなか文章では伝えづらいですが、とても貴重な体験でした。著者に見守られる輪読会、そして最後にはあとがきを読んでいただき、労いの言葉までいただく。日本中どこを探しても、このような経験ができる輪読会はなかなかないのではないでしょうか？

めちゃくちゃエモい最終回でした！

謝辞

2021年5月25日にスタートし、9月17日に最終回を迎えた輪読会。

あれから月日が経ちましたが、最後は輪読会でお世話になった方々への感謝の気持ちをまとめ締めくくりたいと思います。

始めた当初は完走できるか不安でしたが、終わってみると本当にあっという間で楽しい毎日でした。

就職が決まったメンバー、フィヨルドブートキャンプのカリキュラムを終えられ卒業されたメンバー、別の輪読会を主催しているメンバーなどなど、その後もみなさん各方面で大活躍されています。

輪読会という共通目的を持った仲間で走りきった17週間。輪読会を通しとても成長できました。

輪読会メンバー、多くのアドバイス、サポートいただいた森塚先輩、アドバイザー、メンター、そして著者の伊藤さん！

関わってくれた全ての皆さんに感謝したいです。

ありがとうございました！

参考書籍

🍒 おまけ

チェリー本の完走ブログ

輪読会メンバーのブログも紹介したいと思います。

参加した経緯や輪読会で学んだことなど、読みながら「うんうん、わかる〜」の連続で、輪読会の雰囲気や熱が伝わってくる素敵なブログです。

いっしーさんのブログにも書かれていますが、同じ目的を持って学ぶ仲間ができたことが私も何よりも嬉しく、とても良い経験、財産となりました。

isshi-hasegawa.hatenablog.com

yana-g.hatenablog.com

チェリー本改訂2版が発売されました

すでにご存知かとは思いますが、2021年12月2日にチェリー本の改訂2版が発売されました！もちろん、私もすでに購入し手元にあります。これから、改訂2版の輪読会も開催されるのですが、とても楽しみです。

これからチェリー本を学習する方は、「さくらんぼが2つ」を目印に、改訂2版を買いましょう。ボーっとして間違えて購入しないように注意です（パーフェクトRubyonRailsも改訂版とそうでない版があるのですが、私は過去にやらかした経験があります…w)

blog.jnito.com

また、こちらのブログはチェリー本の差分がわかりやすくまとまっていてお薦めです。

aim2bpgさん の分析力凄すぎる...！

aim2bpg.com

伊藤さんのお墨付きです！

次のステップとしてのお薦め教材

「チェリー本の次に読むべきRuby本のお薦めはなんですか？」と、メンターさんや卒業生の方に質問したときに、よく名前の上がる本をご紹介します。

「パーフェクトRuby」はRubyをさらに体系的、網羅的に学ぶには最適だそうです。チェリー本で学んだ知識をより深く学んでいくことができます。

メタプログラミングについて学ぶのも良いそうで、その中でもダントツに名前が上がるのが「メタプログラミングRuby」です。メタプログラミングを始めるなら、まずはこちらがお薦めとのことです。

改訂2版 パーフェクトRuby

gihyo.jp

メタプログラミングRuby 第2版

www.oreilly.co.jp

書を持てよ、輪読会へ出よう

主催者のトミーさんの呼びかけにより始まった輪読会。

このチェリー本輪読会をきっかけに、その後多く輪読会が誕生しました。すでに終了した輪読会もありますが、現在もフィヨルドブートキャンプ内では多くの輪読会が開催されています。

私が現在参加中の輪読会の一部ですが、以下のブログも輪読会の雰囲気が感じ取れる素敵な内容なので、もし気になった方はぜひ読んでみてください。

paru871.hatenablog.com

isshi-hasegawa.hatenablog.com

また、「参加したいけど、いま一歩踏み出せないあなた」へはこちらのブログを！コミュニティへ飛び込むまでのお気持ちが丁寧に書かれていてわかりみが深いです。

napple29.hatenablog.com


これにてチェリー本輪読会シリーズは完結です！

最後までお読みいただきありがとうございました！

また、どこかの輪読会でお会いしましょう♪