Practicing Railsの良さを広めたい
はじめに
ちょっとずつ読んでいたPracticing Railsという本を読み終えたので、簡単な書評でも書いてみようかと思います。 日本語になっていないけど、本当にためになるよい本なのでみんな読んでほしい。
久々にこの電子書籍を読んでみたけど、どのページもすごくいいこと書いてあるなー。時間があったら翻訳したい。（時間があれば）
— Junichi Ito (伊藤淳一) (@jnchito) 2021年5月17日
Practicing Rails: Learn Rails Without Getting Overwhelmed - Justin Weiss https://t.co/cX1hX18t8M
伊藤淳一 (id:JunichiIto)さん(この本の存在を教えてくれたのも伊藤さん)がいつか翻訳してくれるかもですが、その日が来るまでは英語で読んでもいいかも…👀
もくじ
Practicing Railsについて
どんな本？
Rails初学者が「楽しくRailsの学習を続ける」ためのTipsを集めた本です。 公式Docsを読め、ソースコードを読め、エラーログを読め、みたいな言説はもちろん正論なんですが、正しさだけじゃ人は学び続けられないのだ…！
誰が書いた？
Justin Weissというシアトル在住のエンジニアの方だそうです。
Ruby/Railsのカンファレンスでも多数登壇されているみたい。 詳しくはご本人のWebサイトを参考にされるとよさそうです。
どんな人におすすめ？
- Rails始めたての人(FBCで言うとSinatraでメモアプリを作ったくらいの人)
rails newしたあと膨大にファイルができるのがなんか怖いと思っている人- 英語でなんか技術書を読んでみたいと思っている人
- プログラミング学習のモチベーションをあげたい人
私が実際に読むのにかかった期間
1日30分くらい読んだり読まなかったりって感じで、1ヶ月くらい読んでいました。
複雑な話もなくて分量もそこまで多くないので、真面目に時間をさけば1-3日で読み切れると思います。
Practicing Railsの魅力
1. 英語が怖くない
Tests allow you to safely defer design decisions. As your design skills improve you will begin to write applications that are sprinkled with places where you know the design needs something but you don’t yet have enough information to know exactly what. These are the places where you are awaiting additional information, valiantly resisting the forces that compel you to commit to a specific design.
Sandi, Metz. Practical Object-Oriented Design (p.195). Pearson Education
↑の文章読んでみてどう思われますか？ 私はめちゃくちゃこゎぃ🥺って思います。知らない単語ばかりだし文法も難しいし…
この本aka POODRは輪読会で読んでいてとてもいい本なんですが、設計についての抽象的な話が難しいということもありますが、比喩や装飾的な言い回しが多く、英語が第二言語の人にとっては認知負荷の高い本なのではないかと感じます。
その点Practicing Railsの英語はこんな感じ。↓
Testing doesn’t have to be intimidating. It turns out that with a few tips about how to write and organize your tests, testing your code isn’t so much different than writing your code. So as you build up your coding skills, you can improve your testing skills at the same time.
Justin Weiss Practicing Rails (p.118)
ワ〜簡潔で分かりやすい！終始これくらいの英語なので、ほとんどストレスを感じずに読むことができます。
著者の方が非英語圏の読者向けに書いたのかどうかは分からないのですが、少しでも読者の「怖い」「とっつきづらい」という気持ちを軽減するために平易な文章で書かれているのかなと推測しています。
余談ですが、「読みやすい英語と読みにくい英語」について面白い記事を見つけたので貼っておきます。 私は人文系出身で、言語芸術に馴染みがあるためわかりやすい言葉が全ての場面で正義だとは全く思わないですが、誰でもアクセスしやすい言葉とそうではない言葉の違いについて分析されていて面白いです。
2. 無駄に写経させない
ハンズオンでアプリを作りながら学ぶ系の本ではないので、コードは文章の説明程度にしか出てきません。 ただ全く手を動かさないで一方的に教わる本というわけではなく、要件を簡潔な文章にし、そこからUIを描き出したり、そのUIから必要なモデルやコントローラーを見つけていくというエクササイズに1章が割かれています。 現実をコードに落とし込む1歩手前のモデリングの作業について、具体例を使って詳しく教えてくれている印象です。
自分の経験に当てはめて考えると、何を書いているのかもよくわかっていない時点でコードをひたすら写経してアプリを作るのは「これは単にうつしてるだけで勉強になっているのか？」という気持ちになりがちだったので、こういう段階を挟んでくれるのはありがたいと思いました。
あと写経が必須の技術書は、PCが手元にない環境で読むのがだるくなりがち(=読むハードルが上がる)なので、その点この本は寝ながらとか外出中とかにも気軽に読めるのがいいなと思いました。
3. 新しいことを学ぶこと全般について学べる
Railsを学ぶということは、Railsだけを学ぶわけではなく膨大な数の付随知識を求められることになります。
Railsに限らずプログラミングを学習していると、Aを知りたいと思っただけなのにBに関する知識を求められて、Bについて調べたら全然聞いたこともないCについて調べることになって、もともとのAになかなか辿り着けない…みたいなことってよくあると思います。
私は分からないという状態にはだいぶ慣れたとは思いますが、それでも自分の無知にがっかりしたり、学ぶべきことの膨大さに疲弊してしまうことはまだよくあります。
この本で紹介されているTipsをひとことで表すと「難しいタスクは細かく分解しろ」なのですが、新しい分野を学ぶときの心構えとしてもこのTipは応用されています。 例えばRailsが分からない！と一言で言っても、ActiveRecordがわからないのか、Rubyが分からないのか、JSが分からないのかetc...によって取るべき対処は変わってきます。そして学ぶ優先順位も変わってきます。 漠然とした「Rails分からなくてつらい」も、細かく分解すればひとつひとつは乗り越えられなくはない難易度のタスクだと分かってきます。著者は本当に何でも見事なタスク分解を繰り返し例示してくれるので、「難しくてつらい」と思ったら何でもタスク分解してみようという気持ちになってきます。
また、個人的にとても好きなのが、「何かをやるということは、それ以外の別の何かをやらないことでもある。不安かもしれないけど、やらない何かはあくまで今はやらないことであって、一生やらないわけじゃないから、一旦忘れておいて今やるべきことに集中しよう」という考え方です。
今すぐにできることには限りがある一方で今進んでいる道が正解か分からないため、あれもこれも勉強しなきゃと焦ってしまいがちなので心に留めておきたいなと思っています。
4. Tipsがとにかく具体的
最近アジャイル開発の本を複数読んでいるのですが、TDDでコードを書いていない自分をダメ人間のように感じてつらいんです…。 でもTDDで書こうと思っても設計の経験が乏しすぎて手が止まってしまい、何も書き始められないことにもどかしさを感じます。
この本は初学者の気持ちに寄り添ってくれるので、最初からTDDに取り組むことは勧めていません。一方でTDDはやらなくていいとも言っていません。
TDDだって難しいタスクのひとつなのだから分割すればいい、例えば以下のような段階を踏めば少しずつ慣れることができるのでは？と提案しています。
- テストなしでアプリケーションのコードを書く
- アプリケーションのコードを読んで、コードが壊れる可能性を列挙する
- すでに存在するアプリケーションのコードへのテストを書いてみる
- TDDで一部のコードを書いてみる
1に慣れていないうちに4を目指すのは無謀なので、少しずつコンフォートゾーンを広げていき段階的に出来ることを増やしていこうとのことです。
この本はとにかく提案される解決策が現実的で具体的なので、自分でもできそうなことに今日から挑戦してみようって気持ちになれます。
Practicing Railsの不満点
1. お高い🥲
$49なので、現在の日本円だと7000円強…？
日本の技術書も本としてそこそこ高い部類だと思いますが、それでも4000円を超えることはなかなかないので、$1が100円だとしても$49はちょっとひるんじゃう価格だなと思ってしまいました。加えて言うまでもなく円安でもあるのでとってもとっても高い(つらい)。
私は著者のメルマガも定期購読しているのですが、メルマガをしばらく読んで良さそうだなと思ったら買うのもいいかもです。
2. 若干typoがある(許容範囲内)
インスタンス変数が普通の変数になっている箇所を何箇所か見かけました。
まあコードを写経して動かす本ではないのでほとんど気にならないです。
#fjordbootcamp で『アジャイルサムライ』の読書会をやっているというのでフラっと遊びにいったら10年越しに残っているtypo(原文のtypo)を発見してしまった…
— Kakutani Shintaro (@kakutani) 2022年9月15日
こういうこともあるんですね👀
3. 完全なRails初心者のときの自分が読んでどう思ったかは分からない
曲がりなりにもRailsで一度自分のサービスを作った現在だからこそ、「タメになる」「役に立つ」と思えている点は否めないかもとは思いました。
UIから設計を開始するみたいな考え方は、今思うと所属していたプログラミングスクールのフィヨルドブートキャンプのRailsのプラクティスでも推奨されていました。しかしRailsが提供する7つのアクションについてあまり理解できていなかった当時の私は、scaffoldで出来るような1番ベーシックなUIを想像することすらとても難しく感じました。
そのため、完全なRails初心者の方が読んだら、特に最初のころの章は難しいと感じるかもしれません。
それでも「難しいタスクを細かく分割する」や「学習ルーティーンを作る」、「新しい技術情報をどうやって・どこまで追いかけるか」など、どの学習段階の方が読んでも役に立つTipsが紹介されているので気になる章だけでも読んでほしいです。
おまけ(私の読んでる時のメモ)
英語の文章はどこに何を書いてあったのかを後から探すのが大変なので、紙のノートにいいなと思ったことを書き留めながら読みました。 まあ紙である必然性は特にないので、好きなような方法でメモしながら記憶のトリガーを作っていくのがいいのかな〜と思います。
おわりに
1冊英語の技術書を読み切れたって経験があると、わりとなんでも手を出せるようになる気がするので、そういう用途でもこの本はかなりおすすめです。
私の場合はFBCの輪読会で『リーダブルコード』の原著を読んだのが英語で技術書を読む自信を持てるきっかけになったので、この本も興味のある方は有志を募って読書会をやってみるのもいいんじゃないかと思います。
教えてくださった伊藤さん、著者のJustin Weissさんに感謝です！
YouTubeを使ってシャドーイングを行い学習記録を作るアプリをリリースしました
はじめに
こんにちは。所属するフィヨルドブートキャンプ(以下FBC)の最終課題である自作サービスにて、Shadone(しゃどーん)というWebアプリを作成しリリースしました。 このアプリについて紹介させていただくとともに、作る過程で学んだこと、苦労したことなどを共有できればと思います。
目次
自己紹介
2020年10月からFBCで学習を続けてきたトミーと申します。
趣味は語学の勉強で、DuolingoのStreakは1205(2022年9月12日時点)です。
英語をもっと流暢に喋れるようになりたいと思っているので、語学学習のモチベーションを保ち続けるために自分が欲しいと思っていたシャドーイングのためのWebアプリを作成しました。
サービス概要
YouTubeの動画を使ってシャドーイング学習を行うためのアプリです。 フォームからURL、ループ開始・終了時間、ループ回数、再生速度を指定して動画を再生させ、その間シャドーイング学習を行うことができます。 学習が完了(=設定したループが終了)すると学習記録が作られ、学習に使ったYouTubeのURLと学習時間を集計し記録することができます。
サービス名の「Shadone」は「Shadowing」と「Done」を掛け合わせたものです。シャドーイング学習後にDONEのスタンプがカレンダーに付くというアプリの特徴を表しています。 サービスの名前が思いつかずFBCのDiscord上で募集した際、友人のudaさんが「しゃどーん」という名前を考えてくれて、最初はダサすぎて絶対イヤだと思っていたのですが、どうしてもキャッチーさが耳から離れずいつの間にか採用していました。
使い方デモ動画
野菜についている「私が作りましたマーク」的な動画です。 がんばって英語でサービスの使い方を説明しているので、良かったら見てみてください！(日本語字幕もあります)
使用技術
- Ruby 3.0.3
- Ruby on Rails 6.1.5.1
- Vue.js 2.6.14
- TailwindCSS
- RSpec
Vue.jsの2系を選択した理由は、使いたいと思っていたvue-youtubeというライブラリが2系にしか対応していなかったためです。 近い将来、Vue3系へのアップデートは必須で行わなければいけなくなってしまったので、2→3へのアップデートの練習素材としてこれからもメンテしていこうと思っています。
サービスを作った理由
私は毎日シャドーイングの学習を30分行っているのですが、やり方はわりと特殊なんじゃないかと思っています。
- 1分弱の音声教材を用意
- その音声教材を30回ループ
- 実際にかかった学習時間と学習したコンテンツを記録
この際ネックになるのが、まず「1分弱の音声教材」がなかなか見つからないことです。以前は知人に作ってもらったMP-3の音声教材を使っていたのですが、毎日学習しているためストックはすぐに切れてしまいました。 この問題はYouTubeを使うということで解決しました。
YouTubeのABループが行えるChrome拡張機能を入れて学習していたものの、モチベーションはどんどん下がってしまい、学習しない日が増えてしまいました。 理由を考えてみると、以下が思いつきました。
- 一旦YouTubeを開くと別の動画に気を取られて学習に集中できない
- 学習記録を作るアナログな作業に億劫さを感じ、やりっぱなしになってしまう
思えば私は収集癖があるためか、DuolingoのStreak、GitHubの草、FBCの学習カレンダーなど、過去に作った記録を見返すことで「こんなにがんばったんだな」とモチベーションを保てていると思い当たりました。
そのため、シャドーイング学習のモチベーションを保つことに特化したアプリケーションを自分のために作りたいと考え、YouTubeでシャドーイングを行なって、そのまま学習記録が勝手に作られるという機能を持つShadoneを作成しました。
こんな人に使ってほしい
- 語学学習のモチベーションを維持したい方
- 自分のレベルに合ったシャドーイング用教材を探している方
- 英語以外の言語を勉強している方
私はYouTubeのループは外国語学習にしか使う予定はなかったのですが、機能を説明すると楽器やダンスを練習している方に「使ってみたい」と言ってもらえることがあったのは意外でした。あともっと意外だったのは「落語の練習にもよさそう」と言ってくれた方がいたことです。落語もシャドーイングして練習するものなんでしょうか？
なのでYouTubeの一部を繰り返して技術を習得したいと思っている人全てに使ってもらえたら嬉しいです！
技術面で苦労したこと
Vue.jsが難しい
Vue.jsにもJavaScriptにも苦手意識があったのに、アプリの大部分をVueで書く必要があったのは大変でした。 チーム開発のプラクティスでは、Rails側のデータをjbuilderを介してVue側で受け取り使用するというコードは何度も見かけましたが、自分のアプリではVue側で作成したデータをRails側のDBに送るという逆の操作を行う必要があり、データの受け渡し処理の流れを理解できていなかったためコードを修正するたびにリクエストを送り、ネットワークタブでステータスコードやペイロードを確認しながら理解を進めていきました。
またVueのコンポーネント間のデータの受け渡しが必要で、以前チーム開発で使ったVuex(Pinia)を使って非・親子間のデータ受け渡しを行うつもりでしたが、Piniaのドキュメントを読み進めたところ「同一ページ内での処理の場合は使うべきではない」と記載されていたため、コンポーネントの設計を考え直す必要があったのも大変でした。 ブートキャンプのチーム開発だと、すでに大部分ができているところに機能を追加するため技術的にある程度の制約があり、その分考えなくていい面もあるのかなと思います。一方いちからアプリを作るとなると、全てが自由である分、設計からよりよいものを考え選択する必要があるという難しさがあることも学びました。結局クラシックなVueのコンポーネント間データ受け渡し手法である親子間でのバケツリレーを選択しました。
Vue.jsにはとにかく苦しめられましたが、その分力もついたかなと自負しています。機能の実装が完了し、デザインを入れるタイミングで学習記録の編集画面は消し、編集フォームを付与したSPAにしたいと思った時、その場でさほど苦労せずに編集フォームのコンポーネントを作れている自分がいて、ちょっとびっくりしました。
timezoneが難しい
コードレビューを受けている途中で、Railsでtimezoneの設定を行なっていなかったためアプリ内の時間がUTCになっており、日本時間午前0時〜8時59分(8月時点)の間に学習記録を作ると前日の日付で学習記録が作られてしまうというバグを発見しました。
このサービスは日本に限らずいろんな国の方に使ってもらえたら嬉しいな〜と思って開発したので、ユーザーに合わせてtimezoneを変更する必要があると判断したのですが、Railsアプリのtimezoneを動的に変更する方法に関する資料がなかなか見つからず苦労しました。
結局、アプリ内のtimezoneはUTCに統一し、学習記録のレコードが作成されるタイミングでブラウザから受け取ったユーザー固有のtimezoneを反映させることで解決しました。
timezoneに関しては実装についてもテストについても知らないことばかりだったので、近いうちに自分が調べたことを別記事でまとめたいと思っています。
開発を続けるために役に立ったもの
人と比べたり将来が不安で落ち込むことは多かったんですが、その度に具体的なアクションに結びつけることは気をつけていました。 私がやっていた珍しい取り組みとしては、フィードバックのためのペアプロを週1ペースでお願いしていたのと、ポイント付け会とYouTubeでの進捗報告くらいでしょうか。
週1のペアプロ
メインとなるYouTubeのループ機能が完成したあと、バグっている部分がどうしても解決できずペアプロで見てもらった際、自分では壊れていると思っていなかったRailsの基礎的な部分がガタガタで壊れているという事実を指摘され、とても自信を失い落ち込みました。
というのも、私はチーム開発のプラクティスでは色んな方にペアプロしてもらってIssueをこなしたため、その分自作サービスでは自分で調べ勉強しながら作っていきたいと思い、(そのときのペアプロまで)ほぼ人に頼らずに好きなように書いて、動くものを自分で作れるのはなんて楽しいんだろ〜！と思っていたためです。
このペアプロのあとは、頭が真っ白になってしばらく呆然としてしまうくらいには落ち込んだのですが、でも冷静になると全て言われた通りでした。とりあえず私に分かっていたのは、現時点の自分はRailsにもVueにも知識の穴がたくさんあること、卒業までになんとか目につく穴は埋める必要があること、そのために今の自分にできることをするしかないということでした。
落ち込んでいる中で思いついたのが、とにかくフィードバックループを早く回し、傷の浅いうちに修正していくという方法でした。そのため、メンターさんのご厚意に甘え、少しでもコードが書けたらペアプロをお願いしていました。6月末からほぼ週1ペースでペアプロしてもらったので、少なくとも5〜6回はしてもらったと思います。
プロのエンジニアの問題解決の姿勢を学べたので、本当にペアプロしてもらってよかったと思っています。1行ずつコードやドキュメントを読み、HTTPリクエストの中身を確認し、適宜byebugやdebuggerを使ってデバッグし、変数の名前ひとつ取っても磨き抜かれた最適な言葉を選ぶ、みたいな基本の作業を何度も根気強く教えていただき、教えていただいたことはひとりでコードを書くときも気をつけるようにしているので、まあ当社比ではあるものの少しはすごいエンジニアの定石・哲学・思想に近づけたんじゃないかな〜と思っています。
進捗YouTube
後半になるにつれあまりアップロードしなくなってしまったのですが、YouTubeでの進捗報告も続けていました。 珍しい試みだったので、メンターさんや受講生の方がたまに見て感想をくれるのがとても嬉しかったです。
少しずつアプリが作られていく様子に興味がある方は、↓の再生リストからぜひ動画を見てみてください〜！音が小さいらしいので大きめにしてもらえるといいかもです。
ポイント付け会
同じ時期に自作サービスに取り組んでいたFBC受講生4人で、週1回各々のGitHubのかんばんを使って今週取り組むIssueについて説明し、自分以外の3人にポイントをつけてもらうという会を行っていました。
これは以下の点でとてもよい取り組みだったと自負しています。
- 情報交換の場になる
- 自分のIssueについて他人に説明するため、やるべきことがよりクリアになる
- 励まし合える
- 他の人のよいやり方を学ぶことができる
自作サービスのプラクティスではどうしても孤独に陥りやすいという話をFBCを卒業した先輩方から聞いていましたが、私はこの会があったためか、孤独を感じることはほとんどなかったです。
「何もわからないし何もやりたくない」みたいなただの愚痴を聞いてもらったり、同じ技術を使った経験のある方からアドバイスをいただけるような面でありがたかったのはもちろん、自分の無知に直面し自信を失っていたとき、(すでに乗り越えた課題について)自分の経験をシェアしたことで他の方の役に立つことができ自信を取り戻すことができたのが何よりも心の支えとなりました。
『アジャイルサムライ』輪読会
開発を始めた途中で開催された輪読会に参加していたのですが、自分がちょうど個人開発を行っているタイミングで読んだため、机上の空論としてではなくより具体的な「今日から使えるTips集」として読むことができたと感じています。
私のサービスは開発当初想定していたよりも1ヶ月完成が伸びてしまい、最初の締切を過ぎた時点でもやるべきことが山のようにあり、途方にくれていました。
このままどんどん後ろ倒しになって、いつまでも卒業できないのかもしれないと絶望していたのですが、ちょうど輪読会で8章(「アジャイルな計画づくり: 現実と向きあう」)を読み、計画が予定通りにいかないのは当たり前で、ままならない現実のなかでいかにやるべきことを成すかがアジャイル開発だと学びました。
そうじゃなくて、抱えている悩みが、とにかく早く成果をあげることなんだとしたら、今のプロジェクト計画を捨てよう。そして新しい計画を、信じることのできる計画を立て直すんだ。あたかもゼロからアジャイルな計画を立てるかのように進めよう。マスターストーリーリストを作って、リストの規模を見極め、そこに載せているフィーチャに優先順位をつける。そうしたら、最小限の機能でいいから、とにかくお客さんのところへフィーチャを届けよう。全体から見れば一部であってもいい。とにかく仕事を完了させるんだ。
Jonathan Rasmusson『アジャイルサムライ――達人開発者への道』西村直人・角谷信太郎 監訳／近藤修平・角掛拓未 訳、オーム社、2011年、170頁
↑を読んで、自作アプリの完成に必要なのは能力や予算ではなくて「締切」そのものだったのか、締切をいつまでも伸ばしていいものだと心のどこかで思ってるから優先順位もつけられないし完成しないんだ…！と目から鱗が落ちた気持ちになりました。
それからは再設定した締切は動かせないものとみなして、タスクの優先順位を見直したり、不安のある分野は積極的に質問するように意識を変えたことで、締切までにサービスをレビュー依頼できる状態まで作り込むことができました。
このように週1回のこの輪読会は、自分の行っている開発プロセスや開発者としての姿勢を、本の文章や輪読会での会話を通じて反省し、改善していくためのまたとない機会だったなと思います。
本に書いてあることの一部については「こんなこと自分が出来るようになるとは思えない」という気持ちになることもありましたが、頻繁なペアプロでフィードバックループを素早く回す、他人にIssueのポイントをつけてもらうみたいなアイディアは、この本を通じて得た知見を自分の開発に取り入れる過程で生まれたものだと思っています。
余談: Discord Botを作った経験
自分が使いたいからという理由で1年前にDiscord Botを作ってリリースした経験には、作った当時には予想もできなかった形で勇気づけられたなと思います。
Railsアプリを0から作るのは今回が初めてだったので、取り組み始めた時点で全体像は想像できなかったし、作る中でも自分の知識・能力に大いに疑問が湧きましたが、「でも1年前はあんなに何も分かってなかったのに、いろんな人の助けを借りながらDiscord APIやdiscordrbのドキュメントを読んでデプロイまでできたんだから何とかなる」と思えたので完成まで至れたのだと思っています。
だから今回作ったShadoneも、ごく小さなサービスではありますが、これから先困難な問題を前にして暗中模索状態になったとしても、「あのときもなんとか作れたんだから大丈夫」と思える北極星のような存在になるんじゃないかなと期待しています。
さいごに
こうやって振り返ってみると、自作サービスのプラクティスは、チーム開発のときに初めて触れたアジャイル開発の手法を学び直し、自分なりの解釈で実践してみた期間だったという印象が強いです。 コードを書いて動くものを作ることはもちろん面白かったのですが、それ以上に自分で自分のモチベーションや生産性を上げるための具体的な工夫をすることがとても楽しく、やりがいを感じました。
FBCで2年近く学習する中で、ずーーっと「私はエンジニアに向いているんだろうか？」という疑問を持ち続けてきたのですが、チーム開発を終えても自作サービスを作り終えても、自分がエンジニアに向いてるのかはぜ〜んぜん分かりませんでした笑。
むしろ自作サービスを作る中で、自分が何も分かっていなかったということを思い知ったり、すごいエンジニアの人の考え方を目の当たりにし、自分が向いてない理由は100個くらい思いつくようになってしまいました。Web開発は楽しいけど厳しい世界だ！
でも仮に私がエンジニアに向いてないというのが客観的事実だとしたら、そんな人でも0からWebアプリを作り切れるような開発の方法論があるということはすごいことだと思います。
なので例え私がエンジニアにならなくても、どんな職種でどんな働き方をしても、アジャイル開発手法を含めエンジニアリングについて学んだことは無駄にならないと思っています。 むしろ就活を含む、この先の人生の問題解決の場で最善の選択をするための道具を手に入れることができたので、これから先どうなるか全然分からないしめちゃくちゃ怖いけど、持ち前の蛮勇で自分にとってより良いと思える道を進んでいこうと思っています！
最後に、コードレビューを担当してくださり日報や質問タイムでたくさん疑問に答えてくださった駒形さん、アイディア出しの時点からたくさん励ましてくださりデザインについては何時間もペアプロしてくださった町田さん、根気強く毎週のペアプロに付き合ってくださった梅本さん、なぜか私の作ったTシャツを買ってくださった赤塚さん、ポイント付け会でお世話になったParuさん、ガラムマサラさん、Sakiさん、『アジャイルサムライ』輪読会を主催してくださったいっしーさん、サービス名を考えてくださったudaさん、その他長い間私や私のサービス開発に関わってくれたフィヨルドブートキャンプの皆さんに感謝です！
ShadoneTシャツ良かったら買ってねッ
プログラミング初学者向け 英語のおすすめコンテンツ
はじめに
最近少し時間に余裕ができて、英語の勉強をしています。
プログラミング始めたてのころ、プログラミングの学習も英語でしようと思ってたんですが、あまりにリソースの数が膨大でどれが現在の自分に適しているのか分からなくて挫折した記憶があります。
今は2年くらいプログラミング学習を続けて、自分に必要な情報が何なのかが分かってきたので英語学習用のプログラミングに関係するリソースを探すのもうまくなってきました。個人的に面白い、おすすめ！と思ってるコンテンツをPodcast、YouTube、本、その他のジャンル別にいくつか紹介してみようかと思います〜。
もくじ
対象読者になりそうな人
- Web開発に興味がある人
- FizzBuzzくらいのコードは書いたことがある人
- 英語学習に興味がある人(高校レベルくらいの英語が分かるとよさそう)
おすすめコンテンツ
Podcast
The Bike Shed
FactoryBotで有名なthoughtbot社のエンジニア(コンサルタント？かも)の方がやってる番組。トピックは技術の話と開発文化の話が半々くらい(後者の割合が高め)。 Railsでの開発やペアプロ、勉強会の話など自分の興味に近い話をされているため面白いです。英語は難しいのでスクリプトを読みながら聴いてます。
Command Line Heros
Linuxのディストリビューションで有名なRedHat社のPodcast。Code NewbieのSaron Yitbarekがホスト。この方は声がクリアで英語も聞き取りやすいので、彼女がホストする他のPodcastもおすすめです。 Web開発やプログラミングの歴史を当事者インタビューを交えながら知ることができるので、新しい言語を学習するときとかに「これCommand Line Herosでやったやつだ〜！」という体験ができて楽しいです。
YouTube
The Net Ninja
FBCの友人のあんすとさんが激推ししていて知ったYouTubeチャンネルで、FBCのVue.jsのプラクティスではさんざんお世話になりました。 説明がすごく分かりやすい。英語はイギリス英語なのかな、ちょっと私は聞き取りが難しいと思うこともありますが字幕をつければ問題ないです。
Colt Steele
UdemyのJSの講座で有名な講師の人のYouTubeチャンネル。アメリカ英語に耳馴染みのある方には、この方の話す英語はすごく聞き取りやすいと思います。飼われている猫が出てくるのでUdemyの講座の方もおすすめです。
本
The Art Of Readable Code
以前輪読会で読んだのですが、今読み返してみても英語も内容も癖がなくてすごく読みやすい良い本だな〜と思います。
この本に登場する難しい単語、全てプログラミング関連文書に固有のものだったりするので、この本をざっと読んで知らなかった単語をインプットしたらかなり不自由なく技術文書が読めるようになるんじゃないかな〜と思います。
Practicing Rails
チェリー本の著者でFBCメンターの伊藤淳一さんにおすすめいただいた本(チェリー本の巻末のおすすめ本としても紹介されてます)で、最近読み始めました。 Rails初学者でも今日から使えるTipsがたくさん載っていてためになるし、英語もかなり読みやすいです。リーダブルコードより読みやすいかも。
thoughtbotの出してる本
まだちゃんと読んだことはないんですけど、The Bike Shedを聴いていてthoughtbotが出してる本は全てオンライン上で無料でpdfが公開されていることを知りました。
個人的にはこの2冊が気になっています。Testing RailsはRSpec初心者にもとっつきやすそう。
その他
Ruby on Rails Guides
日本語翻訳のRailsガイドは、内容が難しいときは目が滑ることががあり、オリジナルの方が頭に入るような気がします。 英語は癖がなくてとても読みやすいと思います！Railsに馴染みがある方は英語が苦手でも読めると思います。
Upcase
またthoughtbotのコンテンツです(The Bike Shed経由でthoughtbotのことが大好きになってしまったので、ブログとかYouTubeもチェックしています…)。 プログラミングブートキャンプを卒業したレベルの人がレベルアップするための、Q&Aフォーラムや動画教材を中心にした学習リソースみたいです。 昨日見つけたサービスなので隅々まで確認したわけではないのですが、私自身がこのサービスが想定するユーザーに近そうなので、就職に向けた学習にちょうどよさそうって思っています。
プログラミングに関するクイズがフラッシュカードでできるのが面白い。 動画は英語の字幕やスクリプトが見つからないので少しだけハードル高めかもしれません。
さいごに
英語のプログラミング関係のコンテンツは山のようにあるので、ちょっとでも難しい・自分に合わないと思ったら別のものを探すのがいいんじゃないかな〜と思います。 私もPodcastはいくつも聴いてみたけど、結局毎回聴いているのはThe Bike Shedだけかもしれない…。
あと英語かプログラミングの前提知識の量の違いによって、面白いと思ったり理解できるコンテンツは全然違うと感じています。
↑のリストはどちらかというと、英語の知識が多めでプログラミングの知識が少ない人間によるチョイスなので、逆の立場の方だと全然違うんだろうな〜。
フィヨルドブートキャンプのチーム開発の(ほぼ)全Issueをペアプロ・モブプロでやった話
はじめに
こんにちは。1ヶ月前くらいに、所属するフィヨルドブートキャンプ(以下FBC)にてチーム開発のプラクティスが完了しました。
私は取り組んだ計13個のIssueのうち11個をペアプロ・モブプロをして取り組んだので、そのときの思い出について書いてみようかと思います。
もくじ
チーム開発とは
フィヨルドブートキャンプでは基礎学習プラクティスを終えた後、実際に学習のプラットフォームとなっているWebアプリを(受講生がIssueを担当しPRを)作るというカリキュラムがあります。 FBCはOSSなので皆さんのお手元でも立ち上げられますし、なんならPRを送ることもできます。
これまで学んできたRails・Vue.jsなどなどの知識を使って、自分たちが実際に使っているWebアプリの開発に携わりながら、GitHubを使ってチームで開発を行う流れや作法を学ぶというプラクティスになっています。
難易度別のポイントが付けられたIssueを割り振られ、20ポイント分のIssueがマージされたらプラクティス完了という流れになります。
チーム開発までのプラクティスは目指すべき成果物が決まっているので、実際に動いているアプリの新機能やバグ修正を行うという明確なゴールのない作業(実際の仕事と近い)を初めて行うことになり、難易度はグッと上がる気がします。
何でペアプロ・モブプロでやったか
元々チーム開発に至るまでのRails、オブジェクト指向、JavaScript、Vue.jsのプラクティスが私にはどれもめちゃくちゃ難しくて、メンターの方やアドバイザーの方、卒業生や同じ課題をやっている受講生などなど、色んな人にペアプロをしてもらって進めていました。特にVue.jsなど最後の方の課題は難しくてひとりでは行き詰まってしまったので、半分くらいの出来で「ここまで出来たので、ここから先をペアプロで一緒に作業してほしいです」とペアプロ前提で提出してメンターの方と一緒に提出物を作っていきました。
あと私は人と喋るのがそもそも好きなので、プログラミングの課題だけでなく、イベントのスライド作りなんかも画面共有しておしゃべりしながら進めていくこともしていました。ひとりだと先延ばししてしまうけど、人と一緒にやるとやる気が出るし、目標が達成できるし、なによりめっちゃ楽しいなと感じていました。
チーム開発のミーティングに初参加すると、メンターの町田さんから「チーム開発のプラクティスはほとんど仕事と同じだから、これを楽しめるかどうかでプログラマーとしての仕事が自分にとって幸せかどうか考える材料にしてほしい」といった旨のことを言われます。
私は輪読会もそうですが、自分が楽しいと感じるのはチームでワイワイすることだと思っていたので、自分なりに楽しめる方法を開拓していった結果として知識も身につけられたらいいなと考え、全Issueをペアプロ・モブプロで行ってみることに挑戦してみました。
それってドーピングじゃない？学習効果的に駄目じゃない？周りに迷惑じゃない？的な懸念もなかったわけではないですが、まあそう判断されたら駒形さんなり町田さんなりに注意されるだろうと思って勝手に進めてみることにしました。実際に働き始めたら、なかなか自分の好き勝手なやり方で作業を進められるわけではないだろうから、好きなことをするいい機会かもなという目算もありました。
結果注意されるどころか「すごくいいのでどんどんやって行きましょう」と後押ししていただけたので良かったです。
実際に取り組んだIssue
私がFBCの開発で取り組んだIssueは下記のものになり、★が付いているものは人と一緒にやりました。
上記はブランチを切るところからPRの作成まで誰かと一緒にやってもらったIssueもあれば、不明点を一部のみ一緒に見てもらったIssueもあります。
一緒にやる相手は、メンターさんである場合もあれば同じ時期に開発に入ったメンバーの方だったりと様々です。自分が他の方のIssueを一緒にペアプロ・モブプロしたり、レビューを頼まれたPRをメンターの方と一緒にレビューしてもらったこともあったので、合計するとこれ以上ありそうです。
ペアプロ・モブプロって楽しい！
人と一緒にやった11個のIssueで1番思い出深いのは、チーム開発同期のメンバー3人でgood first issue(最初に割り振られる簡単なIssue)にモブプロで取り組んだことです。
good first issueは表示されているテキストを一部変更するくらいの簡単なIssueではあるものの、ひとりで取り組んだ方の日報を読んでいると、gitの操作やエディタの操作、PRの作り方などに不安を感じて緊張しながら取り組んだという内容が散見されました。これって単なる慣れの問題だろうし、誰かに見ててもらえば絶対起きない問題じゃない？と思ったので、すでにチーム開発に取り組んでいる方にDiscord上で「誰か見に来て助けて〜！」と声をかけてみました。
そしたらチーム開発プラクティス中の受講生や卒業生、メンターの方、まだチーム開発には入っていないけど興味を持ってくれた受講生などが集まって21時から翌朝まで(！)盛り上がってとっても楽しかったし、gitの操作やPRの作り方、descripitionの書き方などチームの作法を直接教えてもらえてその後の開発にスムーズに入ることができたと思っています。
最初に取り組んだモブプロがあまりに楽しかったため、それから毎日のようにいろんな方にペアプロを依頼してIssueを進めました。 始めたばかりの頃はなんて楽しいし効率的なんだ！ペアプロしてくれた方レビューにお願いすれば、レビューの手間も省けるし最高のアイディアだった！と浮かれて、土日や平日の夜など、普段だったら学習を休んでいる時間をすべてペアプロに充てていました。
その頃の自分の取り組みの様子はSaki (id:Saki-Htr)さんのブログに詳しいです。今思い出してもチームでやってる感が感じられて楽しかったな〜！
やりすぎた
簡単なIssueでうまく行ってるときは良かったんです。分からないことが分かって楽しい！私いまレベルアップしてる！という実感があり、休まずにプログラミングのことを考えるのが幸せでした。 でもMarkdownの中で独自記法でメッセージブロックを書けるようにしたいという、私にとってどう取り組んだらいいのか分からないくらい難しいIssueを担当することになり、受講生・メンターの方と何度もペアプロしてもらっている中で心が折れてしまいました。
せっかく時間をさいて懇切丁寧に説明してもらっているのに話に全くついていけず、緊張と自己嫌悪で適切な質問もできず、ペアプロが自分のプログラミングの適性のなさを思い知らされる場に感じるようになってしまいました。 分からないことだらけで辛いし、私は本当にこんなことをやりたいのだろうか…本当はドストエフスキー読みたいのに夜も土日もプログラミングしてるせいで何もできない…とめちゃくちゃ深刻な悩みとして泣きながら人に相談したりしていました。
↑のようなことをDiscord上や日報で呟いていた結果、駒形さん町田さんに週1の開発ミーティングにて「なんか疲れてませんか？ペアプロしすぎじゃないですか？」と心配されてしまいました。
ペアプロ疲れ
ペアプロが一般的に疲れるものだということを私は知らなかった(楽しいだけかと思っていた！)のですが、現役のエンジニアの方何人もから「疲れるからほどほどにした方がいい」と言われました。
人に見られながら作業をしていると集中できるということは、裏を返すと気が休まる時間がないということでもあります。
ペアプロを業務の一環として導入している会社でも、定時になったら(キリが悪くても)やめたり、ペアの人と朝・昼ごはんを一緒に食べて互いの疲れ具合を平等にするような工夫をしているという話も聞きました。
私の場合を考えると、ペアプロしてくれる人の予定に合わせてextraに時間を割いている状態(普段は休んでいる21時以降と土日とか)だったり、複数の相手と同じ日にペアプロしたりしていたので、疲れて当然だったと思います。
また、これは自分だけかもしれませんが、相手が時間をさいてくれているという状況に申し訳なさ？を感じ、面白いことを言わなければ…楽しそうにしなければ…みたいな無駄な気負いがあったことも疲れの一因だったかもしれません。この気負いは本当にただの自己満足なのでやめようと思ってます！
疲れないための工夫
私が今回の経験で得た教訓をまとめると以下になります。
- 休憩時間をちゃんと取ること。ドライバー側は疲れるので申し訳ないと思わずに積極的に休憩を申し出る。
- 自分の休息をちゃんと確保すること。ペアプロして教えてもらう場合、多少は相手の都合に合わせることになるけど、それでも土日や21時以降は休むみたいな休息のルールを決めるのがよさそう。
- 「相手の時間を奪っているのでは」的な余計なことを考えないこと。仮に奪っていたとしても向こうが合意している以上、none of my businessだから気にしないという強い気持ちを持つ。
- あくまで「分からないことを理解するため」にペアプロしてもらってるという意識を忘れないこと。「楽しさ」が副次的についてくれば最高だけど、相手との関係性・取り組んでいる問題のややこしさ・双方の精神状態などによって叶わないことはおおいにあるので。
- 分からないことが分からないままペアプロしてもらうことを恥じないこと。「わざわざ時間を取ってもらっておいて、自分が分かってないことも説明できないなんて情けなくてつらい」と思うときはあるんだけど、分かるまで聞けなかったら一生分からないままじゃん？？？
工夫しないと疲れるのは疲れるんですが、やったこと自体は後悔していないです。周りに頼るよい訓練になったという点だけでもやった価値があったと思います。
今の私が分からないことだらけで前に進めないというのは事実なので、サポートしてもらうことへの抵抗感をできるだけ減らすことで、チームとしてよりよい状態を目指せるし自分自身の成長にも繋がるのかな〜と思っています。
見つかった課題
メンターの梅本さんにペアプロしていただく機会がたくさんありました。梅本さんの察し能力が天才的なため、自分の「ｱｱｱ(意: 何もわからない😵💫)」レベルの発話でもほぼ100%の意図を汲み取ってもらえてしまい、逆に(自分に対して)危機感を覚えるようになりました。
知識が足らなくて分からないことを聞くのは全然いいけど、「今まで何を意図してこのコードを書いたのか・これから何をしたいと思っているのか」を自分で説明できていないのはよくないと反省しました(もちろんきちんと説明できなくてもひとりで抱え込むよりずっとマシだとは思いますが)。
なのでチーム開発が終わった後に取り組んでいる自作アプリ作りでは、自分の進捗を説明するYouTube動画を撮って公開しています。 説明の練習用に撮っているので人に見てもらうことは期待していないのですが、文脈(自分の作りたいと思っているもののアイディア)を共有していない相手に非同期で今の状況を伝えることもできるという点でも役に立つ予定です。
今のところ、目に見えて説明が上達したとは自分では感じないですが、音声通話での質問や進捗報告のときに以前よりリラックスして話せているとは思っています。
終わりに
しかし、我々の言葉を真に受けないでください。まずは調査し、これらのアプローチが合っているかどうかを試してみるのです。注意深く実行するとともに、やり過ぎないようにもしてください。特定の方法論に対して過度に投資すると、代替策が見えなくなる可能性があります。慣れてしまうと、その他の手法が目に入り辛くなり、硬直化してしまえば、他のやり方に迅速に適応できなくなってしまうのです。
David Thomas/Andrew Hunt『達人プログラマー（第2版）熟達に向けたあなたの旅』村上 雅章 訳、オーム社、2020年、350頁
『達人プログラマー』の↑の文章を読んだとき、これってペアプロしまくってたときの私じゃん…と思いました。 ペアプロはいいものだ！と感じた経験に頼り、それが全てを解決する万能の道具のように思い込んでやりすぎてしまったのです。
私はバカなのでやりすぎて痛い目に遭うまで何も学べないのですが、次になにかにのめり込みそうになったらこの文章を思い出せたらいいなとは思います〜！(多分無理)
ちなみに最近(一概に自分の影響ではないと思いますが)、いろんな方がFBC内でペアプロ・モブプロをしている姿はよく見かけるようになりました。
木曜日の午後からはるぐち(id:haruguchi_yuma)さんがAtCoderのAB問題に取り組む「勝手にモブプロ」会や、チーム開発真っ最中のいっしー (id:isshi-hasegawa)さんも自分のIssueに取り組むモブプロのモブを募集されています。私が始めた、チーム開発に入ったばかりの方がgood first issueに取り組む様子を見守るモブプロもほそぼそと続いています。
皆さんもプログラミングを楽しむ方法のひとつとしてペアプロ・モブプロに取り組んでみるのは悪くないかもしれません。ただし用量・使用法にはよく注意ですね！！
