1/7(日)〜1/13(土)までの振り返り
今後の方針について決めるために、先週の活動内容を振り返ろうと思います。
先週やったこと
Sinatraの勉強（を通じたWebシステム開発の勉強）
Railsの勉強を始めるにあたって、まずはSinatraの勉強からスタートしました。
以前とある勉強会に参加したのですが、その際に指導してくださった方が「Railsの勉強するなら、まずSinatraをやっておくとわかりやすい」と教えてくださったので、Sinatraの勉強からスタートしました。
（ちなみにこの勉強会もいい感じだったので、プログラミング初心者の方にはおすすめです。自分でバリバリやれる人向けではないと思います）
勉強する際に使用した教材は「CodingCast」というサービスです。このサービスは、先述の勉強会を主催された方が作ったもののようです！
「Railsやるのになんで遠回りしなきゃならんのだろ」と、正直半信半疑でしたが、実際Sinatraから入ったことでRailsの理解がより深まったなーという思いがあります！
Railsと共通する部分が多く、それでいてRailsよりも簡単な知識で使えるので、入り口には最適でした（その分Railsよりやれることは少ないと思います）。
また上記の動画では、Sinatraの勉強を通じて、Webシステム開発の大まかな概要についても学べるようになっています。
実際に動画の説明でも「Sinatra編はあくまでも「WEBサービスとはどのようなものか」を体験する為に作成されています」と記載されています。
これもRailsの勉強に活きているという実感がありますね。
その他に、動画の情報の密度やテンポも、個人的にはけっこう合っていました。
動画で勉強するサイトで有名なものはやはりドットインストールでしょうが、個人的にはドットインストールより好みです。
ドットインストールの動画は無駄がなさすぎて、なんとなくとっつきにくいなーという思いが合ったんですよね。3分という枠にこだわっているのか、しゃべりのテンポも速いし。
とまあなんか色々褒めちぎってますが、このサービスにも欠点はあります。
それは「使用ソフトが最新版に追随できていない」という点です。プログラミング講座動画としては大きい欠点です。人によってはそれだけでアウトかもしれません。
ですが最新バージョンでなくとも私は十分に理解できましたし、いまも特に困っていません。
そこら辺が気にならない人には是非おすすめしたいサービスです。
Railsの勉強
引き続き、CodingCastでRails編の動画を見ながら勉強中です。現在は21番目の動画まで見ました。
こちらもRails5には対応できていないのですが、細かい点が異なるだけで、勉強する分には差し支えないと思っています。
これらの動画を一通り見て勉強した後、Railsチュートリアルに入っていきたいと思っています。
しかしRailsは便利ですね……まだ触り始めたばかりだというのに、便利すぎて感動しています。
使いこなせるようになるまでには時間がかかるかもしれませんが、簡単なアプリケーションならばいますぐにでも作れてしまいそうです。
世の中にRailsが大好きな人が多いのも理解できます。
私も今後、便利なアプリケーションが作れるようになりたいですねー。
生活ルーチンの作成
ある意味プログラミング技術以上に大事なことかもしれません。
いままではなんとなく朝起きて、なんとなく仕事行って、なんとなく帰宅して食事して、なんとなく息抜きして、なんとなく勉強して、なんとなく寝て、という感じでした。
ですがちゃんと勉強できてる実感が持てなかったので、家事や生活に必要な行動すべてを含めた生活ルーチンを決めてみました。
いまのところ、これがかなりいい感じです。
時間を決めて行動するようになったおかげで、漫然と勉強することもなくなったし、睡眠時間もしっかりと確保できるようになりました。
無駄にネットサーフィンしてしまうのが悪い癖だったのですが、ルーチンから意識的に外すことでそれも少しずつ減ってきて、時間や体力を必要なことに回すことが出来るようになってきました。
とりあえず平日の勉強時間は2時間と決めてみたのですが、いまのところはちゃんと守りながら勉強できています。
「2時間は集中する」と決めて勉強しているので、終わった後の達成感もちゃんとあるし、集中しながらやっているので成果もちゃんと上がるようになりました。
ルーチンの内容は今後改善が必要かもしれませんが、「ルールを守って生活する」というのは今後も続けていきたいです。
今週やること
今週も引き続きRailsの勉強を進めていきたいと思います。
基本的に飽きっぽいので、Railsに飽きたらHTMLやCSSや実際のアプリ開発に浮気しつつ、またRailsに戻ってきたりという風に進めていくのだろうなーと思います。
先日掲げた目標についてと、rails勉強します宣言
先日掲げた1月の目標について
Webアプリケーションを3本作るのは無理です。
目標を諦めた経緯
一言で言えば、「railsを体系的に勉強する必要がありそうだから」です。
Webアプリケーションを作成するにあたって、アプリケーションを公開できる場所が必要だなと思ったので、herokuにアカウントを作成しました。
herokuはすべて英語のサービスで、どのように使用すればいいのかがよくわからなかったので、ドットインストールのheroku講座で勉強しようとしたところ、railsがインストールされた環境での解説でした。
なのでとりあえずrailsをインストールし、とある教材に従うままサンプルアプリケーションを作って動かしてみたものの、何が何やら、どうなっているのかまったくわからなかったのです。
「Webアプリケーション作成は思った以上に骨だ・・・」と感じたので、少々方針を変える必要に迫られた、というわけです。
次の方針
とりあえず以下の教材を使って勉強を進めようと思っています。
先日立てた目標に挫折したように、やり方は適宜変えていく必要があるかもしれませんが、Webアプリ3つ作るよりは目標のレベルが下がったと思うので、いまはこれの達成を目指して頑張りたいです。
ちなみに作りたいと思っているWebアプリの案
- 先日作ったすごろくゲームをWeb上でプレイできるようにアプリ化
- Noisliのような環境音を流してくれるアプリ
- 通勤通学先の住所を入れると、おすすめの引越し先を教えてくれるアプリ
3番はGoogleマップのAPIなんかも使えるようになってみたいなーという思いもあって考えてみました。
これから勉強していく中で作ってみたいアプリも変わる気がするので、その時その時で面白そうなことにチャレンジしていきたいなと思います。
1月の目標
突然ですが2018年1月の目標
Webアプリケーションを3本作ります。
目標を決めた経緯
ここ数日、ブログ更新の間が空いてしまいました。
書きたいネタも書けるネタもなく、一週間ほどぼーっと過ごしてしまっていた感じでした。
最近はWebアプリの開発に興味が出てきていて、ドットインストールのHTML講座を見たりもしていましたが、それほどいいペースでは進められていませんでした。
端的に言って、あんまりやる気がなかったのです。
すごろくゲームで最初に想定していた程度のものが出来上がったこと。
独学でこれ以上すごろくゲームをブラッシュアップすることに限界を感じ始めたこと。
今週頭の12/25(月)は仕事が休みだったのですが、せっかく平日の休みなのに体調がめちゃくちゃ悪くて、プログラミングどころではなかったこと。
そんな理由やら要因やらが重なって、最近つまらないなーと思いながら過ごしていました。
なんとかしてモチベーション回復したいなーと思っていたのですが、この間までモチベーションが高かったのはなぜなのかに気が付きました。
「頑張れば自分でも達成できそうな目標があったから」です。
すごろくゲームは「ちょっと頑張れば作れそうだなー」と思える、当時の自分にとってちょうどいい目標でした。正直思っていたよりも細かいところで色々な知識を要求されてだいぶ難しかったのですが、それもまたいい勉強になりました。
すごろくゲームは完成した後もちまちまリファクタリングを繰り返していて、下手くそなりに少しずついいソースコードになってきたのではないかと思っているところです。
しかもまだまだ良く出来る余地は残されていると思います。
思うのでぜひ取り組みたいのですが、最近は「なんとなく気持ち悪い」みたいな感覚はあっても、「具体的には何が悪いかわからない」という、現状の自力でできる改善はやりきってしまった感を感じていました。
次に何に手を付ければよいのかわからず途方に暮れているというのが正直なところであり、実際に経験者の人に教えてもらえる形式の勉強会にも行ってみようかなと思っているのですが、それはまた別の話です。
すごろくゲームの改善は教えてもらいながらやるにしても、とにかく自分で手を動かして達成できる程度の目標がなければ、自発的に手を動かすことは難しそうだと気付いたのです。そんなわけで、短期的な目標を立てることにしました。
何を目標にする？
先述しましたが、最近はWebアプリの開発に興味が出てきました。
自分が初めてWebの技術に触れたのは大学一年生の時なので、すでに10年ほど前なのですが、当時のWebは正直そんなに楽しい場所ではなかったです。少なくとも自分にとっては。
ですが最近のWebは、クラウドだとかインタラクティブだとかでやれることも増え、herokuなどで自分のアプリを公開できたり、おしゃれなサイトも簡単に作れるようになってきていて、なんというかものすごく楽しい世界に見えるようになってきました。
「発想次第でいろんなことができそうだ」と思えるようになってきたといいますか。10年前とは違って、面白そうでエキサイティングな世界になった気がしています。
そんなわけで「Webアプリを3本開発する」を1月の目標にしてみます。
3本にしたのは「自分の実力的に微妙に難しそうだから」です。
1本なら、多分Webの知識がそんなにない今の自分でもひと月もあれば達成できるでしょう。
2本もまあ、大変かもしれませんが行けそうな気がします。
3本はちょっと難しそうです。
なので3本にしました。高すぎない程度の負荷をかけたほうが、経験値獲得のスピードと質が上がりそうな気がしたので。
というわけで「1月中にWebアプリ3本作る」を目標に、これから頑張っていこうと思います。まだ年明け前だけどフライングします。
「勉強会行こうと思っている件」だとか、「12月の活動まとめ」だとかは、また後日エントリを上げたいと思います。
ランキング処理の汎用化をしてみました。
これは何のエントリ？
すごろくゲーム内のとある処理を汎用化するために、クラスの継承を利用したことについてのエントリです。
話が長くなったのでそれだけ先に書いておきます。
興味のある方は続きをどうぞ！
処理を汎用化するためにクラスを継承した話
すごろくゲームにはランキングの処理が実装されています。
ランキングメソッドの名前はこんな感じです。
- make_ranking_of_finished_player()：ゴールしたプレイヤーのランキング作成
- make_ranking_of_unfinished_player()：ゴールしていないプレイヤーのランキング作成
この名前の場合、ひとつ問題があります。名前にがっつりすごろく要素が入っているため、他のゲームを作るときに使い回しが効かないのです。ですがこれには事情がありました。
ランキングメソッドの名前が汎用的ではない事情
ランキングのアルゴリズムを調べたとき「なんて面白い計算なんだ！」と感動したので、いろんなゲームに使い回しできるようにしたかったのですが、名前をうまく決められませんでした。
汎用的な名前であれば、例えば「昇順ランキング作成」や「降順ランキング作成」となる気がします。実際最初はそういう名前にしていました。
ですがこの名前だと、すごろく的に何をやっているのかが直感的にわかりにくいのです。
すごろくは「進んだマス目が多いほど順位が高い」ですが、「ゴールした順が早いほど順位が高い」ものでもあります。
つまりゴールしていないプレイヤーは「進んだマス目の多さ」を比較し、ゴールしたプレイヤーは「かかったターンの少なさ」を比較する必要があります。降順と昇順のアルゴリズムを使い分けなければいけないのです。
そういう前提を踏まえた上で、すごろくゲームの中に「昇順ランキング作成」や「降順ランキング作成」といった名前のメソッドが出てきたとき、それぞれが何のための処理なのか、パッと見で理解できるでしょうか。自分は自信がありません。
実際のすごろくなら、誰でも盤面を見ただけで順位がわかります。昇順やら降順やらマス目の数やらターン数やらを意識している人はきっといないでしょう。
そんなときに予想もし得なかった名前のメソッドを突然出されて、混乱せずにソースコードが読めるのでしょうか。
自分は読めないと思ったので、素直に「ゴールしたプレイヤーのランキング作成」、「ゴールしていないプレイヤーのランキング作成」という名前のメソッドを作ったわけです。
ですがやっぱりランキングメソッドは汎用化しておきたい……！ せっかく面白いアルゴリズムなのだから、いろんなところで使えるようにしておきたい……！
うんうんと悩んでいたのですが（というか問いが具体的になったのは答えが見えてからで、それまでは「なんとなく微妙だからどこかを変えたい」という感じだったのですが）、解決策を思いつきました。
汎用的なランキング処理のクラスを、すごろく用のランキング処理のクラスに継承させればよいのです。
実際にやったこと
ランキング処理の内容を簡単に説明します。
ランキングの算出は、全プレイヤー同士を比較して、自分より成績のいい相手一人につき、自分の順位に1を足す（順位を一つ下げる）という処理になっています。
ゴールしたプレイヤーを比較するメソッドでは「finish_turn」というインスタンス変数を比較し、ゴールしていないプレイヤーを比較するメソッドでは、「position」というインスタンス変数を比較しています。
ゴールしていないプレイヤーのランキングを算出するメソッドで見ている「finished_players_size」という変数は、ゴールした人数を表す変数です。
「ゴールしたプレイヤーが二人いる場合、ゴールしていないプレイヤーの最高位は3位からになる」という感じで、ランキングの最高位を決めるために参照しています。
そして下記が変更したクラスになります。
以下の点を変更し、改善しています。
- ランキングメソッドの名前を、汎用的に使えるものに変更。
- ランキングメソッドにはプレイヤーの配列とトップランクを渡すように変更。ランキングが何位からでも始められるようになった。
- ランキングメソッド内で比較するものも「get_point」というメソッドにし、メソッドが返す値なら何でも比較できるように変更。
- すごろくプレイヤークラスに「get_point」メソッドを追加し、ゴールしたプレイヤーは「finish_turn」、ゴールしていないプレイヤーは「position」を返すように変更。
これで今後、すごろくゲーム以外のゲームを作る際にも、ランキングの処理を使いまわすことが出来ます。やったー！！
いっそのことプレイヤーの親クラスも作って「get_point」メソッドを持たせても良かったかもしれませんが、今回はそこまでしていません。ブログ書きながら気付いたので、後日すると思います。
ランキングアルゴリズムは計算の仕組みに感動したので、いつでも使い回せるようになったのはけっこう嬉しいです。
所感
わかってしまえば簡単なもので、汎用化したクラスの継承は、別に特別な技術でも何でもありません。OPPの基本であるとさえいえます。ですが今までの自分には使えませんでした。
「教えられた知識を応用できるかどうか」は、深い理解を必要とする気がします。昨日までの自分は、知識として継承を知っていても、使えるレベルまで理解していなかったと言えるのかもしれません。逆に言えば、継承の知識は今回の件でしっかりと定着してくれたのでしょう。
アウトプットの方が大切だという考えはとりあえず変わっていませんが、インプットもやはり大切ですね。怠ることなく両輪を回していきたいと思います。
次にやってみたいこと
OPPといえば、privateやらprotectedやらpublicやらだとも思うのですが、すごろくゲームはまったく意識しないでコーディングしてしまいました。
今後はそのあたりもやってみようかな。
もっといいクラス分けの方法もまだまだありそうなので、そこももう少し考えていきたいです。
すごろくゲームのクラス設計について
「完成した！」といいつつ、ここ最近はすごろくゲームのリファクタリングをちまちまと繰り返しています。
変数名やメソッド名なんかのわかりやすいところを直しただけでも、ソースコードが読みやすくなった気がして、けっこう楽しいです。
ですがそんな中で、どのように直したらよいかわからないものもあり、悩んでいたりもします。
それが「すごろくゲームのクラス設計」です。
私の作ったすごろくゲームは、4つのクラスで動作しています。
それが「プレイヤークラス」、「サイコロクラス」、「ランキングクラス」、「すごろくクラス」です
それぞれの役割は以下の通りです。
プレイヤークラス
- プレイヤー情報の保持（名前、現在地、ゴールしたかどうか等）
サイコロクラス
- initializeメソッドでサイコロの面数を設定
- サイコロを振ってランダムに数字を出す
ランキングクラス
- ゴールしたプレイヤーのランキング算出
- プレイ中のプレイヤーのランキング算出
- ランキングの表示
すごろくクラス
- サイコロクラスのインスタンス保持（6面ダイス）
- プレイヤー数のカウント
- プレイヤー名の登録
- すごろくのプレイ（サイコロを振って、駒を進める）
- 各プレイヤーがゴールしたかの判定
- ゴールしたプレイヤーとゴールしていないプレイヤーを分ける
- 全員がゴールしたかの判定
このように、すごろくクラスの役割だけ、ものすごく多いです。
これを適切なクラスに分けられないものかと、最近は頭を悩ませております。
名は体を表すと言いますか、すごろくクラスはその名前がアプリ全体を表せるような名前になってしまったがゆえに、必要な処理を全部突っ込んでしまった感があります。
クラスの命名がよくないと、後から見たとき何のクラスかわかりにくいだけでなく、そもそもクラス設計がうまくいかないということなのかなと思います。
作成中はどんな処理が必要なのかを全部見通せていたわけではないので、なんでも突っ込めるクラスを作ってしまったとも言えるかもしれません。
名前が悪いから設計が悪いのか、設計が悪いから名前が悪いのか……どちらにせよ問題ですね。
では改めて、すごろくクラスが持っている処理を整理し、どのように分ければよいかを考えてみようと思います。
すごろくクラスは、以下のように実装されています。
お見せするのも恥ずかしいくらい、色々な処理が乱雑に収められています。
ここから私なりに、このクラスの何が悪いのかを考えてみたところ、以下のような結論が出ました。
- 処理が意味のある単位でまとめられていない。
- プレイヤークラスのインスタンス変数を直接いじってしまっている。
1番目は何度も言ったとおり、 必要な処理をすべて突っ込んでしまったため、何のクラスかよくわからないという点です。
player_countメソッドとentryメソッドは意味的にまとめてしまっても良さそうですが、playメソッドは分けてもいいのではないかなーという気がします。
check_each_players_finishedメソッド、screening_finished_playersメソッド、everybody_finished?メソッドなんかも、終了判定として意味的にまとめられそうですね。
これらの処理を新規のクラスにまとめるか、既存のクラスの何処かに入れ込むのは、ちょっと悩みどころです。
ただすごろく程度の単純なゲームの単純な処理を、あまり細分化しすぎてもそれはそれで読みにくいのかなーとかも思ってしまったりします。
2番目については、何やってるかわからないクラスでプレイヤーのインスタンス変数をいじるのはよろしくないかなーという気がしたので挙げてみました。
プレイヤーのインスタンス変数をプレイヤー以外のクラスでいじるなら、それ専用のクラスがあってもいい気がします。
……などと改善点を挙げてみたものの、基本的に独学なので、有識者にレビューしてもらえないのがつらいところですね。
自分なりに考えながら改善するのは楽しいのですが、正しい改善点に気付けてなさそうなのが気になるところです。
あまりはっきりとした結論が出せてない……。
とにかくすごろくクラスの雑多さは多分あまりいい設計ではなさそうなので、なんとかかんとか良い設計を目指したいものです。
一時停止していたデザインパターンの勉強を再開してもいいかなあ……。
自分にあった勉強法について
この記事の目的は？
自主的なプログラミングの勉強を初めて、2, 3ヶ月ほどが経ちました。
その間に得られた「勉強に関する知見」を自分なりに整理し、まとめることで、今後の自分のスタイルの確立に役立てるためのエントリです。
勉強の方法について
最近までの自分にとって「勉強」とは、「インプット」のことでした。
プログラムができるようになりたければ、プログラムの本を読む。
言語について知りたければ、言語の本を読む。
練習としてサンプルコードを写経することはあっても、それはあくまで補助的な手段で、「知識を貯めること」が勉強の本質だと思っていました。
ですがここ最近まで勉強を続けた実感としては、「技術の勉強」とはむしろ「アウトプット」のことではないかと思うようになりました。
知識が重要なのは間違いないのですが、技術者としてのレベルアップに必要なのは「技術を使う練習」なのではないでしょうか。
そう、「勉強」ではなく「練習」。
スポーツや芸術と同じです。
体を使って覚えなければ、いつまで経っても覚えられないのです。
そんなわけで、何度か前のエントリで「こんな本を読みます！」といくつか挙げましたが、最近はそれらを読むことに耽るよりも、とにかく手を動かすことを重視しています。
インプットを蔑ろにしていいという話ではありません。もちろん知らない知識を吸収することは重要です。ですがそれ以上に「実際に知識を使う時間」が大事という話です。
そしてこれは自分だけかもしれませんが、知識を吸収することを目的とした勉強は、なんというか長続きしません。
「インプットしなければならない」という気持ちでいると、知識を吸収することが目的になってしまい、「何のための知識なのか」という点が置き去りにされてしまう気がしています。
それが置き去りにされてしまうと、知識が定着しにくい気がするのです。
学校でも、数学の授業に対して「三角関数とか微分積分とか将来使わないじゃん」という人がいたと思いますが、そういう人は多分「意味のない（意味を感じられない）知識を覚えるのが苦手な人」だったのではないかと思います。
学生時代の自分はそういうこともなく、使う使わないに関わらず覚えられたほうが優秀だと無条件に信じていたのですが、最近は「そんなわけねーじゃん」と思っています。
意味があると思えない知識を覚えられないのは不思議ではないし、覚えられない人が劣っているわけでもありません。むしろ闇雲に暗記するより、背景を理解してから覚えようとしている分、合理的な気がします。
話が逸れましたが、大事なのはインプットに気を取られることではなく「何をアウトプットしたいのか」だと思います。
そしてここ数ヶ月の実感としては、良質なアウトプットに集中していれば自然と必要最低限のインプットは集まってきます。何かに取り組んでいれば、自力で解決できないものは自ずと浮かび上がってくるし、向上心があれば意識していなくても情報は集められます。
どちらが欠けてもいけないとは思いますが、インプットとアウトプットの比率はアウトプットの方が高くていいんじゃないかなー、というのが今の自分の考えです。
勉強の時間帯について
自分は社会人なので、勉強に充てられる時間は限られています。
平日は仕事からの帰宅後か、通勤中、仕事の休憩中。
休日はその時々で予定が変わるので不定です。
なのでここでは、時間が決まっていて比較的計画が立てやすい平日について考えてみます。
先述したように、今の自分にとってはインプットよりもアウトプットの方が重要です。
ですが平日にプログラミングのアウトプットが出来る時間帯は、仕事からの帰宅後しかありません。プログラミングの練習をするにはパソコンが必要だからです。
スマホでもやれるみたいですが、あの小さい端末ではコーディングしづらすぎて自分には出来ません。
とはいえそれ以外の時間帯……通勤中や仕事の休憩中も有効活用はしたいです。
なので最近は、そういった時間帯に興味のある技術ブログや記事なんかを読むようにしています。 いわば完全インプットの時間帯です。
インプットしている中で使えそうな知識を発見してもすぐに試すことが出来ないのは少々困りものですが、概ねこのパターンで回すようにしてからはインプットとアウトプットのバランスが少しずつよくなってきたかなーと思っています。
やりたいことをやりたいときにやる。
IT業界を楽しく生き抜くための「つまみぐい勉強法」 (技評SE選書)
- 作者: 奥乃美,渋川よしき
- 出版社/メーカー: 技術評論社
- 発売日: 2010/05/07
- メディア: 単行本（ソフトカバー）
- 購入: 15人 クリック: 408回
- この商品を含むブログ (45件) を見る
上の本は実際に読んだわけじゃないのですが、紹介やレビューの内容から、おそらく今の自分の考えに近いことが書かれているのではないかなーと思っています。
それがつまり、「やりたいことをやりたいときにやる」です。
勉強していて強く感じたのが、「興味のあるものはコロコロと入れ替わる」ということでした。
かつての自分ならば、他のものに興味が移ったとしても、いましている勉強を続けようとしていました。一度決めたことはやり通さなければならないという刷り込みもあったと思います。
ですが最近はそれでは続かないことがわかってきたので、面白そうなものがあればさっさとそっちに舵を切るようにしています。
既に興味がなくなったものをつまらないと思いながら勉強するより、楽しいことを楽しんで勉強するほうが、人生的にも健全です。
そして突然舵取りを変えても、いまのところ「自分の腕で食っていく」という目標を逸れてしまったという感じはありません。
プログラミングに関するものであれば、何も考えずに面白そうなものに飛びついていても、きっとそれが血肉になってくれるんだろうなーという気がしています。
IT業界は広範な知識が必要なので、多少の寄り道は無駄にはならないでしょう。
まとめ
スタイルの確立についてまとめるなら、こんな感じでしょうか。
- インプットよりもアウトプット重視
- 通勤中や空き時間はインプット、帰宅後はアウトプットに集中
- やりたいことをやりたいときにやる
少しずつ、自分との向き合い方が見えてきたような気がします。
今後もこの調子で、少しずつエンジニアとしての自分を確立していきたいですね。
すごろくゲームが出来ました！
というわけで、先日からコツコツと作っていたすごろくゲームが完成しました！
完成と言っても最初に想定していた機能を実装しているだけで、いま思い付くだけでもいろいろと不足している部分はあるのですが、とにかく完成です！
上記のgithubで公開していますので、コンソール上でrubyを動かせる方は、ぜひ遊んでみてほしいと思います！
苦労した点
ランキングの実装
このゲームは毎ターンサイコロを振って、一番先に20マス進んだ人が勝ちというゲームです。
で、ターン毎のランキングを表示しようとしていたのですが、どのようにすればランキングのアルゴリズムを実装できるかがわかりませんでした。
「順位付け アルゴリズム」で検索すると、参考になるアルゴリズムは出てくるのですが、今度はそれをどのようにこのゲームに当てはめればいいのかに迷う・・・。
「どのクラスに処理を持てばいいのか？」「どういうメソッドを使えば楽に実装できるのか？」「変数名、メソッド名は？」etc...
アルゴリズムがわからないだけでなく、OPPに慣れていないこともあって、どのように実装すればいいのかにだいぶ悩みました。
OPPでの設計
自分はソフトウェア開発の仕事をしていますが、オブジェクト指向プログラミングの経験はありません。
今回はRubyでの自作プログラム挑戦だったため、OPPにも挑戦しよう！ と思ったのですが、書いてみても普段のプログラミングとあまり変わらない出来のソースに……。
とりあえず作ってみたクラスは、意味的に近い変数をまとめただけのクラスで、メソッドは全部外部に実装して処理……仕事ではC言語での構造体をよく使っていたため、クラスも同じ感じで設計してしまっていたのです。最初は「クラスにメソッドを定義する」という感覚が全然掴めずに、まったくOPPになっていませんでした。というか「クラスにメソッドを定義できていない」ということすらよくわかっていませんでした。
その後、web上のOPPについての解説記事や本を読んで、「メソッドをクラスに定義してないじゃん！ 全然OPPじゃないじゃん！」ということにやっと気付いて、設計の方針を転換。それからもクラスをどういう風に分ければいいのかわからないまま、手探りで進めること数日……やっと完成に至りました。
まとめ
今回苦労したことの原因は、総じてコーディング経験が浅すぎることに起因するような気がします。
アルゴリズムがわからないにしても、検索の仕方が下手で時間がかかったり、参考にするにしてもどのように応用すればいいのかわからなかったり、そもそもOPP自体がよくわかっていなかったりと。
今回のプログラム完成を通じて、得られた経験値は小さくないと思っているのですが、「具体的に何が得られたの？」と聞かれると、うまく言葉に出来ません……アウトプットの練習のために作ったブログなのに、こんなんじゃダメですね。
このプログラムももうちょっといじるかもしれませんが、とりあえずはこれで一区切りついたかなと思っています。
完成した嬉しさのままにはちゃめちゃな文章を書いてしまったので、また改めて「何を得られたのか？」を整理したエントリをアップするかもしれません。
すごろくプログラムが完成しても、勉強はまだまだ続きます。
これからも頑張ります！
