UnityとRiderで作業しているときに、両方見ながら書けると楽だし、1画面のときにアプリをCmd+Tabで切り替えたときの待ち時間が気になってました。
ディスプレイが一枚余ったのを期に上下二段ディスプレイにしてみました。
これは・・・捗る！
フィヨルドブートキャンプで、「Rails入門と実戦の間にギャップがある問題」の解決策の１つとしてフィヨルドブートキャンプのEラーニングシステム自身の開発を（簡略化した）スクラムでやってみることをはじめました。
ソースコードもカンバンもアジェンダ／議事録もpublicな中で、計画ミーティングと振り返りミーティングを毎週水曜日14:00-15:00で行うことにしました。
カリキュラムの中に、「Pull Requestを5回送って採用される」というのがあるので、それの解消のために参加する形です。
アジャイルな開発手法には独特の用語が多く、カリキュラムとして学んでも実際にやってみないとピンとこないと思うので、「スクールとしてのフィヨルドブートキャンプに通っている方」、「僕ら」、「企業の研修で来られている方」が混ざってやっています。
常にメンバーの出入りがあるので、チームとしてのベロシティは出していないですが、2012年から続いているこのリポジトリを入れ代わり立ち代わり開発を続けていければ面白いかなと思っています。
これが拾えないのってみんなどうしてるんだろう？
class PostsTest < ApplicationSystemTestCase
test "GET /posts/xxxx" do
assert_raises(ActiveRecord::RecordNotFound) do
visit "/posts/xxxx"
end
end
end
例えば、「非公開のpostは見れないことをテストしたい」とかの時。begin...endでも拾えないようで困った。
unityのc#でLinqExtraのShuffleで大ハマリしました。
同じListをforeachしてるのに毎回並びが違うというものです。
@monryさんが書いてくれた検証コードがコレ。
コード：
IEnumerable<int> list = new List<int> {1, 2, 3};
Debug.Log("--A--");
list.ToList().ForEach(x => Debug.Log(x));
list = list.Shuffle();
Debug.Log("--B--");
list.ToList().ForEach(x => Debug.Log(x));
Debug.Log("--C--");
list.ToList().ForEach(x => Debug.Log(x));
Debug.Log("--D--");
list.ToList().ForEach(x => Debug.Log(x));
結果：
--A--
1
2
3
--B--
3
2
1
--C--
2
3
1
--D--
2
1
3
なんでB, C, Dが違うわけ？
@monryさんに聞いてソースを見たところ原因は結果、
「Shuffleという拡張メソッドはShuffleIteratorという別のIteratorを返すから」
というものでした。
list = list.Shuffle();
のところでIteratorが変わっちゃってるんですね。
データとイテレータは分かれているのだと仕組みとしては知っていても、あまり活用したり意識したりすることがなかったので盲点でした。
list = list.Shuffle().ToList();
こうやって上品な抽象的なところから汚くて臭い具象に落としてやればOK。
合同会社フィヨルド御中
ご担当者様はじめまして、○○と申します。
御社のArticlesを拝見しまして、（以下略）
ごめん、内容入ってこないわ。
仕事でフィヨルドブートキャンプというRailsエンジニアになるためのスクールをやっています。
「どのレベルになったら就職できるの？」
という点がイメージできないと、就職したい人にとってわかりづらいなと思ったので明確にしておきたい。
戦力として計算できるRailsエンジニアとは
僕の考える、Railsエンジニアとして就職できる最低レベルは、
「少しでもプラスの戦力として計算できる」
というものです。
「Issueを一人でこなせる」
といっても良いかもしれません。
「は？みんな10の戦力持ってるところに1とかじゃ困るんだけど？」
と思うかもしれませんが、Railsプロジェクトにとってほとんどの人類は1の戦力も無くて、マイナスです。
Railsチュートリアルを終わったばっかりで実務レベルの開発したことないぐらいの人もマイナス戦力です。
「教えるのに大量のパワーが割かれて、居ない方がプロジェクトが進む」
という状態がマイナス戦力です。
Railsプロジェクトのリーダー的な役割をした人なら感覚的にわかると思います。
「Rails経験無くてJava経験だけの人が2人送られてきても困るなぁ・・・」
これがマイナス戦力です。
「多少の教育コストはかかるけど、レビューをしっかりやればトータルで見れば助かる」
このレベルがプラス戦力です。
「Railsのコードは書かせられないけどテスト仕様書を書いててもらおう」
こんな工夫が必要な場合、マイナス戦力です 😅
プラス戦力になるための工夫
このイメージが固まってからカリキュラム終盤の内容も変わりました。
- 弊社プロダクト（怖話など）へPRを送って5回採用される。
- Railsプログラムのアルバイトの斡旋
- DB設計のカリキュラム追加
- RESTful Webアプリ設計のカリキュラム追加
- メンターとペアプロするカリキュラム追加。
Railsの機能を一通り覚えただけじゃ駄目で、実際のプロジェクトに入るには必須の知識がかなりあります。
弊社としては一般的なプログラマー新人研修もやっているのでその中でこの辺ももっと固めていきたい所存です。
- 早さ
- 機能
- 安定性（バグの少なさ）
これらはトレードオフ。そして、
実装力 = 早さ x 機能 x 安定性
しかし、レベルアップすることで、早さそのままで多くの機能を実装できたり、早さそのままでバグが少なく作れるようになったりするんだよね。
割り振れるスキルポイントが増えるみたいな感じで。
Railsのおかげでちょっと早く作れるようになったからっつって、
「俺、作り込むよりプロトタイプ作るのが得意なんだよね。早さと完成度ってトレードオフじゃないですかぁ？」
とか言ってないで、同じ早さのままもっと作り込んだもの作れるようになれ！バグ減らせ！ ＞ 俺
RailsGirls Tokyo 9thにコーチとして参加させていただきました。
また、スポンサーにもなったのでスポンサーLTでフィヨルドブートキャンプの紹介もさせてもらいました。
スポンサーLTや一般LTはRailsGirlsから興味をもってプログラマーを目指してる人、または既にプログラマーになった人が、
「すごい面白いからお前らもやろうぜ」
という内容が多くて、既にプログラマーである僕でも、
「へぇ〜、プログラマーって良さそうねぇ」
と思ってしまいました。
また、@a_matsuda さんの文字通りのすばらしい話もあり、全体がしまりましたね 😁
プログラミングに興味を持ってもらう方法
コーチとして参加して、もっとわかりやすく教えるにはどうしたらいいか、という点も気になりましたが、RailsGirlsはプログラミングを単に教えるというより、プログラミングの楽しさを知ってもらって興味を持ってもらうのが目的だと思います。
何をやってもらったら一番、「プログラミングって面白い」って思ってもらえるんだろう？
ひいては「プログラミングの面白さって何？」というところが気になりました。
いろんなプログラマーの皆さんに聞いてみたいですね。
参加者・参加目的
参加されてる方は下記のような人が多かったです。
- プログラマーの求人をしてる会社の人事の人がプログラマーをよく知るために。
- 今の会社が退屈過ぎてプログラマーに転職したい。
- プログラミングで困ってるWebデザイナー。
- 会社でプログラマーになれと言われたけど聞く人がいない。
- リモートワークなど、プログラマーの自由な働き方が気になってる。
会場がSpeeeさんで、オシャクソラウンジだったので良さ出てましたね。
改善したい点
Railsアプリをいきなり作るので当然なんですが、
「全然わからないことに対するストレスがある」
という感想を聞いたので、「Rails Moreで聞けるよ」だけでなく、
「あなたがわからないのはどこですか？皆さん疑問に思われる点はだいたい下記の5点です。それぞれはこれを読むことでわかるようになりますよ」
ぐらいの道筋を示せるとその編のストレスが軽減されるのかなと思ったので、今後参加するならばその辺りの資料を作ったりしたいなと思います。
今までずっとWebプログラマー（主にrails）で、スマホアプリちょろっとぐらいでしたが、今回初めてUnityでのスマホゲームのお仕事をさせていただきました。
お仕事
ECC が社会体験アプリ「ごっこランド」に新規パビリオンを出店！〜 ECC のえいごのせんせいごっこ〜 | 株式会社キッズスター|KidsStar Inc.
謝辞
「Unityを仕事でやりたい！」という意気込みだけの僕を辛抱強く教えてくださった株式会社Kidsstarエンジニアの @monryさん、@fakestarbabyさん、@hanageman69さん、@lycoris102さんありがとうございます。
お仕事で開発するまで
去年の11月末ぐらいに、
komagata「Unityやりたい」
Kidsstarさん「やろう」
ってなって、まずは勉強のお題として「もぐらたたきを作ってみよう」ということになりました。
（もぐらたたきの要件の図）
その辺りの途中経過はブログにも書いています。
基本的なことを理解してない俺に対して@monryさんが丁寧に辛抱強くおしえてくれて非常に感謝しております。
基本リモートなので、現在の進捗や理解をブログとしてアウトプットするのは良かったなと思います。
ブログにすると自分の中で質問できる程度にまとまります。
フィヨルドブートキャンプで最近Railsを教えているので教える側として思うのですが、初心者のブログを見てると回答や教え方が自然に頭に浮かんじゃいます。それを吐き出すのは比較的ラクなんじゃないでしょうか。
昼間Rails仕事をし、夜中に気力が無くてもなるべく公式サイトのチュートリアル動画をみたりして勉強しました。
2週間ぐらいの感じで…と言われていたのですが結局年内一杯（4週間ぐらい）かかっちゃって後半必死こいてました。
Kidsstarのゲーム開発の流れ
ゲーム開発がはじめてなのでとにかく一回やってみないとリリースまでの開発の流れがわかりません。今回一通り体験できてとっても勉強になりました。
Kidsstarさんでのゲーム開発の流れは下記のような形でした。（外部の開発者としての視点オンリーです）
- お客さんとの間で仕様が決まる。（esa or Googleスプレッドシートで詳細な仕様書が作られる）
- ゲームで使う素材が作られる。（ボイスを録ったり、イラストを作成したり）
- オーサリングの得意なデザイナーさん（神）がほとんどの素材をUnityに配置し、アニメーションもTimelineなどで作る。（GameObjectについてる付箋にプログラマーへの指示が書いてある）
- コードが必要な部分（ゲーム本体や入力に反応して動くところなど）にプログラマーがコードを入れていく。
- お子さん向けテスト（実際に遊んでもらってフィードバックをもらう）
- 多端末検証（Androidの部分を外部の会社さんに依頼してテストしてもらう）
- ごっこランド本体とつなぎこみをし、リリース。（個別のゲームはそれ単体でBuildできるようになっている）
真っ先に思ったのが、
「圧倒的に大変なのデザイナーさんじゃね？」
ということです。
多分デザイナーさんには3つの役割があって、
- 元になるキャラクターなどのイラストを書く。
- 上記を元にゲームで実際に使う素材を作る。
- 素材をUnityに配置する。アニメーションを作る。
3人ぐらいデザイナーさんが関わってると思います。
また、Kidsstarの開発で驚いた点は、
「仕様書が超書いてある」
点です。
僕は最近、コンセプトのパワポだけを元に全て話しながら作ってく感じのWeb開発の仕事が多かったので、かっちり仕様が決まってるのは1プログラマーとして入るのはとても楽でした。
今回のゲームでできなかったこと
ほとんどの実装方法も聞きながらやったようなものですが、
「あ、この画面は自分で書けるかも？」
という状態にβ版リリース一週間ぐらい前にやっとなりました。1ヶ月前にその状態になっとけよなぁ〜頼むよぉ〜😢
音声の録音やビルド周りなど、難しい部分はほとんど@monryさんや@fakestarbabyさんにやっていただき、ランダムで生徒のキャラクターが生成されるアバター部分も@hanageman69さんにやっていただいて、簡単な部分を僕が書くといった程度だったので、次のアプリからはそういった部分も一人でできるように勉強していく所存です。
AssetBundleとか全然理解できていないですしね。
やる前の自分に教えておきたいこと
オーサリングツールは習うより慣れろ
UnityはC#から呼べるランタイムとオーサリングツールで成り立っています。実際はかなりの時間オーサリングツールを弄り回すことになるので概念理解もいいですが、どこに何があるのか、どこの機能を使えばどうなるのか、とにかく慣れです。
Photoshopの使い方をマスターすることを想像するとわかりやすいと思います。
UnityはあくまでHierarchy本位
プログラマー的には「C#で書けることをGUIからでも書けるだけでしょ？」と思いがちですが、Unityはそんなコード本位な思想ではなく、オーサリングツール上のGameObjectにHierarchyがメインで、C#コードはあくまで、
「GameObjectにつけることができる1コンポーネント」
という位置付け。そういった流儀だと理解しないと色々と分かりづらくなってしまいます。
Rider最高
JetBrains社製のC#のIDEであるRiderはUnityに最適。基本的な作法を指摘してくれるので特に勉強中の人間にとっては最高。すぐ買え。
静的型付けコンパイル言語の流儀に従え
言語入門経験が少ないと陥りがちですが、入門時に別言語のスタイルを無理矢理持ち込むのは理解の妨げになる。新しい言語を学ぶ時は郷に入っては郷に従え。
- 暗黙的より明示的
- 型をつけろstringにするな
- クラスが増えることを恐れるな
- コーディングはなるべくIDEに任せろ
rubyをvimで書いているときは頭の中で思い浮かべたコードをすばやくタイプしまくる感じですが、C# + Riderのときは自分の書いた原型をIDEにたびたび投げてコントロールを渡しつつすばやく補完し、指摘点の自動修正をしてもらって仕上げていく感じ。
感想
既に次のゲームの開発が始まっているのでゆっくりしてられませんが、Unityに入門してやってみてとっても良かったです。
やはり新しいことを学んでできることが増えるのは楽しいです。僕の場合、webでは新しい言語を覚えたといってもそれほどできることに違いはありませんが、webとゲームだと全く違うので感動もひとしおです。
まだ2Dゲームだけで3Dはさっぱりなのですが、個人的にも3Dのゲームを作ってみたいです。
弊社（フィヨルド社）が5月18日に行われるRailsGirls Tokyo 9回目のスポンサーになりました。
途中でスポンサートークさせていただけることになりそうです。
RailsGirlsでプログラミングって面白いなと思った方へ、
「さらにガチで学んでプログラマーになりたい人はフィヨルドブートキャンプへ」
という流れは良いかなと思ったためです。
僕自身もコーチとして応募していますが、受かるかどうかはまだわからないです。
今回のオーガナイザーの@usamimiemiさんとスタッフの@naotyomeさんが両方ともフィヨルドブートキャンプ生なので、
「みんな関わってるのにまさか@komagataさんコーチに応募しないわけないよね？」
という無言の圧力を感じています。