RubyKaigi 2023 に初参加してきました
2023年5月11日〜13日にかけて、RubyKaigiに現地参加してきました。会場は長野県松本市のまつもと市民芸術館でした。 RubyKaigi自体初の参加でしたが、結論から言うととてもいい経験になりました。これはその記録です。
whoami
Hikaruです。プログラミングスクールのフィヨルドブートキャンプ(以下FBC)でWebアプリケーション開発を勉強をしています。
事前にやったこと
RubyKaigiの前にこちらのイベントに参加しました。 「Shibuya.rb RubyKaigi 2023 前夜祭」はオフラインイベントで、フィヨブーハウス(後述)の住人と事前に顔合わせできたのがよかったです。 「RubyKaigi 2023 を楽しむ予習会」ではRubyKaigiチーフオーガナイザーの松田さんがRubyKaigiの見どころを説明してくださってイメージが膨らみました。
フィヨブーハウス
今回のRubyKaigiでは、FBCが宿泊場所としてゲストハウスを丸ごと借り上げて受講生に無料で提供してくれました。ありがとうございます。神すぎる…
RubyKaigiの会場からも程近かったので、休憩や作業の拠点として非常に便利でした。
他の受講生とPCを並べてコードについて話すのが最高に楽しかったです。
セッション
Day1の最初にMatzがキーノートでJoy can create Benefitsみたいなことを言っていて、これにガーンとやられました。コアにあるのは楽しさを突き詰めるということであって、役に立ちそうとかお金になりそうみたいなことではないんだなあと感じました。
Rubyは世界中のビジネスサービスで使われているにも関わらず、あくまでJoyを追い求めているのがとても新鮮で、ああ自分はRubyコミュニティに来たんだなあと思いました。
まあ肝心のセッションの内容については、ほとんど何を言っているかわからなかったんですけど…それでもスピーカーの皆さんがそれぞれ「こんなことしました！」とJoyを持って語る姿に心を動かされました。熱って伝播するんですねえ。
去年のRubyKaigiに参加していたFBCの先輩方が「去年よりわかることが増えた」と皆言っていてすごい。来年は幾分かわかるようになっていると願いたい…
イベント
Day1の夜のオフィシャルパーティーに参加しました。ホテルの大きなパーティー会場を貸し切って行われた立食パーティーでFBCの関係者の方々とたくさん話せて良かったです。一人ぼっちで参加していたら心細かったろうと思います。あと以前からお話を聞いてみたかったエンジニアの方にもご挨拶できて大満足のDay1でした。
他にも最終日のRubyMusicMixin 2023に参加しました。FBC卒業生の方がDJをやっていてカッコよかったです。疲れと酔いも相まって非日常感がすごかった。
申し込みが遅れてしまって参加できなかったイベントがあったので来年は募集状況や締め切りをこまめに確認したい。
松本
松本は最高の街でした。僕はRubyKaigi最終日の翌日に帰る予定だったのですが、出発まで時間があったので少し街を見て回りました。お城のイメージしかなかったんですけど、街も綺麗だし、おしゃれなカフェがたくさんあって松本は洒落者の街でした。住みやすそう。
そして酒とご飯が美味い！しばらく家で茹でたそばは食べられません！
そして来年に向けて…
実は今回のRubyKaigiに行くかどうか迷っていることをFBCの日報に書いたらメンターの方に背中を押してもらって、えいや！でチケットを買ったんですよね。来て本当に良かったです。ありがとうございました。
来年2024年の会場は沖縄だそうです。事前の予想(願望？)が的中しました。 来年の今頃は何をしているでしょうか。ちゃんとFBCを卒業できているといいな。
それでは。
2023年の抱負
明けましておめでとうございます。
昨年はお世話になりました。
今年もよろしくお願いいたします。
ということで今年の抱負です。
フィヨルドブートキャンプを卒業する
2022年が始まるころは「さすがに今年中には卒業してるだろ〜」と高を括っていましたが、まあ結果は言うまでもないですね。
特に卒業を急いでいたわけでもないのですが、なんだかんだでプラクティスも残すところあと2つです。
現実的に卒業を見据えられるところまでいよいよやってきました。
最終プラクティスの自作サービス制作で良いものを作って無事に卒業したいですね。
就職する
まだ何も手をつけていないのでキャリアの棚卸しや情報収集をぼちぼち始めないとなあと思ってます。
良い会社とご縁がありますように...
一人暮らしを始める
一人暮らししたいですね〜。
やっぱり他人に邪魔されない生活が欲しい...。そして自立して初めて自分になることができる感があるので。
場所はあんまり考えてないけど、転職先へのアクセスが良いところがいいな〜。仕事に集中できる環境がいいよな〜。
自分にまつわる家事は今でも自分でやっているので全く不安はない。むしろ物件選びの方が不安。結構押しに弱いんですよね...。急かされてうっかり決めちゃいそう。後悔しないようにしたいですけど、まあそれも経験か。
自己開示をする
人の目を気にせず気軽に自分の気持ちを表明してみたい。
というのも僕は自分の意見を溜め込みがちで苦しい思いをしてきたんですよね。あと人目を気にして頑張っちゃったり弱音や本音を隠しちゃったり。
とにかく「しっかりしなきゃ」みたいな思いが強かったんですけど、2022年は自分を見つめ直してそういった苦しみを手放せた年でした。
2023年は弱さを見せられる強さを受け入れたい。
ギターセッションの勉強をする
ずっと言ってる気がするけど、ジャズギターでセッションができるようになりたいですね。指板の音と度数が覚わらん。
痩せられるように習慣を変える（ジム通い・食事）
『小さな習慣』を読んで習慣を変えることでしかダイエットは成功し得ないということがわかったので、一人暮らしを開始するタイミングでジムを契約して生活リズムに組み込みたい。
ダイエットには食事も大事だけど、これも一人暮らしを始めるのでどうにでもなるな〜。でも料理が好きで片付けも苦にならないタイプ（そして食べるのも好き）だったりして、気を抜くとすぐチキン南蛮とか高Fatなものを作っちゃうので気をつけねば。
ITについて
毎日GitHubの草を生やす
Write Code Every Day。まあ毎日意味のあるコードを書くのは難しいので、勉強したことや写経をGitHubに1コミット以上していきたいですね〜。
毎日手を動かしてコードを書く、という継続のためにやってみたい。
基本情報技術者を取る
就職してしばらくはその仕事に必要なことを急いで身につけなきゃいけないだろうけど、長期的なことを考えると、IT分野の基礎的な知識やコンピューターサイエンスの知識を身につける必要があるかな〜と思っています。
ITパスポートと情報セキュリティマネジメントは持っているので次は基本情報（FE）かな、と。
英語について
2022年は結構英語力が伸びたのでとても良かった！
輪読会に参加して文章と参加者のレベルの高さにやばい！となって勉強したのが良かった。出来なさすぎて変な汗流しながら笑って誤魔化してた自分お疲れ！ 笑
中でも一億人の英文法やキク英文法を読んで文法をおさえられたのが大きかった（新たに学んだというよりかは大学受験の時に勉強して以来忘れていたことを思い出したという感覚の方が強いかも）。
あとは自分の英語の発音は悪くないかも？と思ったので良い感じにスピーキングも伸ばしていきたいですね〜。
最終的な目標は英語でスムーズにコミュニケーションが取れるようになること。
オンライン英会話を始める
輪読会でReadingや発音をある程度実践できた反面、Listeningや自分の考えを述べるといったことはできなかったのでオンライン英会話で英語を話す機会を得たい。
英語のハノン
毎日ちょっとずつやる。そのための時間を確保します。
算数・数学に再入門する
自分は"いわゆる"ド文系で、今まで何度も数学に挑戦しては挫折するということを繰り返していました。
その中で数学がよくできる人の発言をよく観察すると、どうやら自分は数の概念みたいなものに対する理解が弱いということに気がつきました。
今年は、その数の概念みたいなものに触れるところから始めて見たいと思います。
ゆくゆくはアルゴリズム力や数学的思考力を身につけて仕事に活かせるようになればいいなと思っています。
読書
時間を決めて読書をする。これも英語のハノンと同じで、そのための時間を設けることで積読を解消だ！みたいな。
アウトプット
技術ブログを24本書きます。ブログはなんだかんだで2022年やり残してしまったことなのでやっていかねば。
さいごに
ひとまずは2023年のToDoという形で色々列挙してみました！
他にも登録者数11人（うち1人は自分の別垢...）という底辺YouTubeチャンネルをやってて、それを伸ばしたいとか色々あったりするんですけど、それはまあいいや。
2023年が皆さんにとっても素晴らしい実りある年になりますように！
今年もみなさんよろしくお願いします！
オブジェクト指向設計実践ガイド（POODR） 感想 & 第1章 まとめ
はじめに
はじめまして、Hikaruと申します。
私はいまプログラミングスクール フィヨルドブートキャンプ（以下FBC）でWeb開発を学んでいます。
そんな中FBCのカリキュラムとは別に、Practical Object-Oriented Design, An Agile Primer Using Ruby （POODR、オブジェクト指向設計実践ガイド原著の第2版）の輪読会を2022年1月から10月までおよそ10ヶ月かけて敢行しました。
そして原著に加えて初版の邦訳版『オブジェクト指向設計実践ガイド』も読んでみました！この記事ではその感想と第1章のまとめを紹介していきたいと思います。
残りの章は今後何回かに分けて投稿していこうと思っています（本当は全部まとめて投稿するつもりでしたが、体調不良で寝込んでいたため予定変更です...）。
後述しますが日本語版と英語版では内容に大きな差はないので、英語版に限らずこれから日本語版を読もうとしている方でも参考にできると考えています！
この記事は...
これは「フィヨルドブートキャンプ Part 1 Advent Calendar 2022」の12日目の記事です。
Part2はFBCのメンターのcafedomancerさんが担当してくださってます！
ちなみにcafedomancerさんは前述のPOODR輪読会メンバーでもありました。その節はお世話になりました...ありがとうございました🙇♂️
昨日はHiromi Sugieさんの「Ruby初心者がAtCoderの過去問から多くの学びを得るために工夫していること」でした。
Part2はhirano-vm4（けだま）さんの「FBCと仕事の両立とふりかえり&卒業後は？」でした。
感想
POODRは一足飛びに完成形を示して「これが正解」とするのではなく、初心者がやりがちな失敗などを経ながら徐々ににコードを発展させていくので、理解が置いてけぼりにならずに済みました。
なぜこの設計がいけないのか、この設計に足りない視点はなにか、を踏まえつつ次に進むことでオブジェクト指向設計が達成しようとしていることに対する理解が自然に深まっていったように思います。
また、静的型付け言語と動的型付け言語を比較して説明を展開するパートもあったのですが、その部分は静的型付け言語の経験や知識がないとわかりづらかったように思います。
僕は静的型付け言語での開発経験はありませんが、『良いコード／悪いコードで学ぶ設計入門 保守しやすい成長し続けるコードの書き方』（通称ミノ駆動本）を同時並行で読んでいて、こちらは静的型付け言語であるJavaをサンプルとして使いながら設計について解説しているので、この二冊を読み合わせることで静的型付け言語と動的型付け言語の違いやそれぞれの良さをある程度理解することができたかなと感じています。
POODRを読んで良かったと思う点として、読み終わった後も「あ、これはPOODRに出てきたあのパターンだ！」とか「たしかこれについてPOODRで説明されていたな」と思い出しながら勉強することができたことがあります。
この本には本当に役立つ実践的な知識が詰まっていて、他の本やコードと知識がリンクするんですよね。
某ゼミじゃないですが、POODRを読む前と読んだ後ではプログラミング学習の楽しさが変わったような、そんな実感があります。
英語のレベルは？
僕の英語レベルは普通くらいだと思っていますが、べらぼうに難しかったです笑
特に単語のレベルが半端ではなく、英検準1級・1級レベルの単語が当然のように出てくるので、スラスラ読めるという感じではなかったですね。
英文自体もしっかりしていて、一文一文が日本語で言うところの重複文になっているので、これを読み終えた時は英文読解力が爆上がりしました笑
POODR輪読会を完走できたことが自信になり、現在はもっと英語ができるようになりたいと思えているのでその意味では頑張ってよかったなと思います。
明らかにひとりでは読み切ることができなかったので、一緒に輪読会をしてくれた英語に堪能なメンバーに感謝したいです。
日本語版（初版）との違いは？
オブジェクト指向設計に関わる部分では違いはありませんでした（気付いてないだけかも？）。初版で取り上げたRubyの機能のうち、第2版までにアップデートがあればそこを差し替えた、くらいの印象でした。
著者のSandi Metzさんも公式サイトで、「（新しい）Rubyの機能を使うようにいくつかの推奨事項をアップデートしていますが、細かい変更になるので単に初版を現代化しただけだと思っていただいて大丈夫です。すでに初版を読んでいるなら新たに購入していただく必要はありません」（抜粋、意訳）としているので内容的に大きな改訂はないということで大丈夫そうです。
余裕があれば（気づくことができたら）各章のまとめで初版と第2版の違いについても紹介したいなと思います。
読むと自転車に詳しくなれるって本当？
本当です。が、初見では少々イメージしづらいところがあったので、自転車のギアがどんな部品から成り立っているのかくらいは知っておくと楽に読めると思います。
オブジェクト指向設計実践ガイド 第1章 まとめ
1章は本の内容全体に対する導入のような位置づけでした。
1.1 設計の賞賛（In Praise of Design）
1.1.1 設計が解決する問題（The Problem Design Solves）
アプリケーションの仕様や要件は常に変化する。これは避けることができない。
なのでアプリケーションが変更しやすいようになっているとエンジニアにとってはハッピー。設計はそのために必要なもの。
1.1.2 変更が困難な理由（Why Change Is Hard）
そもそも変更がなぜ大変かというと、アプリケーションがうまく設計されていないと変更の影響が他の箇所へ延々と波及していってしまうからだ。
オブジェクト指向アプリケーションは、オブジェクトというパーツがそれぞれメッセージを送り合うことによって成り立っている。正しい相手に正しくメッセージを送るためには相手のことを知っていなければならないが、これが依存という形でアプリケーションの変更を難しくしてしまう。
オブジェクト指向設計はこの依存関係をうまく扱うためのもの、つまりオブジェクトが変更に耐えられるように依存関係を調整するコーディングのテクニックである。
1.1.3 設計の実用的な定義（A Practical Definition of Design）
設計は画一的な解決法が存在するようなものではなく、匠の技（an art：技術、芸術）のようなところがある。
数多ある手法の中からニーズとコスト/利益のバランスを勘案して、現在と将来の両方においてコスパの良いコードの配置（アプリケーションの構造）を考えなければならない。
設計の目的は設計を後からでもできるように対処法を残しておくことであり、その目標は変更のコストを小さくすることにある。
1.2 設計の道具（The Tools of Design）
1.2.1 設計原則（Design Principles）
オブジェクト指向設計者は原則とパターンという二つの道具を使って設計をしていくらしい。
原則については、5つのソフトウェア開発の原則の頭文字を取ったSOLIDというものがある。
- 単一責任（Single Responsibility）
- オープンクローズド（Open-Closed）
- リスコフの置換（Liskov Substitution）
- インターフェース分離（Interface Segregation）
- 依存性逆転（Dependency Inversion）
その他に、DRY（Don't Repeat Yourself）やデメテルの法則（LoD：Law of Demeter）がある。 この先々で説明するよ！
1.2.2 設計（デザイン）パターン（Design Patterns）
パターンというのはいわゆるGang of Four（GoF）のデザインパターンのこと。GoFはオブジェクト指向アプリケーションに見られる共通の問題に名前をつけて、共通の手法で解決できると示したところがすごい！
デザインパターンは乱用したり誤用したりせずに正しく使うことが大事。
1.3 設計の行為（The Act of Design）
設計のための良い道具を揃えていても、それを使いこなして良いアプリケーションを作ることができるかは結局プログラマーの経験によるところが大きい。
1.3.1 設計が失敗する原因（How Design Fails）
Rubyのような扱いやすい言語には、設計をせずともある程度のものは作れてしまうという問題がある。そのような（ちゃんと設計されていない）アプリケーションは、機能追加しようとするとバグが発生したり思わぬ箇所が壊れたりするようになっていく。
設計について多少の知識があると、今度は逆に設計を作り込みすぎてしまうという過ちを犯してしまうことがある。緻密に作り込みすぎているので後から機能追加できないという状況に陥ってしまう。
設計フェーズと実装フェーズが離れすぎていても失敗する。設計は実装からのフィードバックを受けて改善していくイテレーティブなプロセスなので、設計がフィードバックを受けられないとニーズとかけ離れたものが出来上がる危険性がある。
1.3.2 設計をいつ行うか（When to Design）
オブジェクト指向設計ではアジャイルに開発を進める。設計もイテレーティブに行う。
アジャイル開発では「はっきりしたことは作ってみないとわからない」ということを前提としているので、あらかじめ詳細設計をするやり方には意味がないというのがその立場！
詳細設計書は最初こそアプリケーション開発のために作られるが、最終的には誰の責任で限られた期間に何をどこまでやるのかという顧客と開発者の対立の道具にしかならない。
アジャイル開発ではそのようなことはなく、顧客と協業して小さくソフトウェアを作っていく。
1.3.3 設計を判断する（Judging Design）
オブジェクト指向設計にどれだけ沿っているかを計測するソフトウェアやライブラリがある。これらのメトリクスはバイアスなしに現在のコードの状態についてのヒントを出してくれるという点で有用。
だが、メトリクスがどんなに良くてもそのアプリケーションの変更が容易になっているとは限らない。なぜなら事前に想定していない変更のコストは依然として高いままだからだ。
逆に将来的なコストがかかったとしても今すぐに実装するべき機能もある。これは技術的負債として将来のコストを前借りしているということだ。
ある機能をすぐに実装するか否かは、スキルとタイムフレームによって決めると良い。
1.4 オブジェクト指向プログラミングのかんたんな導入（A Brief Introduction to Object-Oriented Programming）
1.4.1 手続き型言語（Procedural Languages）
あらかじめ組み込まれたデータ型とそれに対する操作を利用してプログラミングする。そして振る舞い（メソッド）とデータの間に断絶がある。データは振る舞いに渡されて処理されるだけで、データと振る舞いは完全に別のものとして存在する。
1.4.2 オブジェクト指向言語（Object-Oriented Languages）
オブジェクト指向言語はオブジェクトの中に振る舞いとデータを持たせている。
オブジェクトは他のオブジェクトとメッセージを送ったり受け取ったりすることで振る舞いを呼び出したり実行したりしている。そしてオブジェクトは自分のデータをカプセル化していて、データに向けて外部から何がどれくらいアクセス可能かを決めている。
Rubyのようなクラスベースのオブジェクト指向言語は、クラスというオブジェクトの構造の設計書を定義できる。クラスの中にはメソッド（振る舞い）と属性（データ）を定義できる。
一度クラスを定義すればインスタンスを繰り返し作ることができる。あるクラスから作られたそれぞれのインスタンスは同じメソッドを持っているので同じように振る舞う。メソッドと同様にインスタンスは同じ名前の属性を持っているが、その中身はそれぞれのインスタンスのデータになっている。違うデータを持っているのでそのインスタンスは異なるものを表現している。手続き型言語と同じように、オブジェクトの型によってどのような振る舞いをするかがわかる。
オブジェクト指向言語はそれ自身がオブジェクトでできており、どんなクラスもClassクラスのインスタンスである。なのでプログラマーが新しい型を自分で定義できる。オブジェクト指向言語はこのようにして使われる領域に特化した独自の言語になっていく。
まとめ
いかがでしたか？設計とはアプリケーションの変更のコストを最小化するために、将来の変更容易性を確保することなんですね〜。
要約するにあたって大幅に内容を削ったり統合したりしたため原文のニュアンスとは異なる表現になってしまっている部分があるかもしれません。何かお気づきの方はご指摘くださいますと幸いです。
明日はガラムマサラさんが何か書いてくれるみたいです！楽しみですね〜
ちなみにPart2はsasaboさんです！こちらも楽しみ！
アドベントカレンダーとしてはここでバトンをお渡ししますが、このブログでは今後もオブジェクト指向設計実践ガイドのまとめを投稿していく予定です。気になる方は是非チェックしてくださいね。
さて、2022年も残すところあと僅かとなりました。今年はどんな一年だったでしょうか？来年はどんな年にしたいですか？
皆さまにとって2023年が実りある素敵な年になりますように！
ここまで読んでいただきありがとうございます。Hikaruでした。
Merry Christmas！
