【7週目】未経験からTECH::EXPERTでプログラミングやってみた

非同期メッセージ機能完成

先週に引き続きメッセージ機能の実装です。

先週ツイートした時は高速Ctrl+Rで非同期に見せるという高度な技を使用していたので、今週は非同期通信を中心に実装しました。

そういえばちゃんと非同期で実装しました！画像も選択した時点で自動的に送られるようにしてます。これで高速Ctrl+Rとはお別れ😢

チームメンバーがヘッダーその他諸々を作ってくれたのでだいぶ形になってきた🔥 pic.twitter.com/sxycLUTTQ2

— 金子幸三郎@未経験エンジニア (@Kosaburo_Kaneko) 2018年6月14日

メンバーがヘッダー、サイドバー、フッターを作ってくれていたので、renderでメッセージ画面を表示するようにしてます。見た目的にはほぼ完成したと言ってもいいんじゃないですかね。

勘違い

メッセージ機能自体を非同期化するのはカリキュラムでもやったことがあったのですんなりいったんですが、マッチしたユーザーの一覧の最新のメッセージを非同期更新するところでハマりました。

ハマったというか、勘違いしていてフロントのフレームワーク等がないと実装できないと思ってました。

ビューファイルはざっくりこういう構造になってました。マッチしたユーザーの一覧とメッセージエリアは部分テンプレートで切り出していた格好です。

それで非同期でメッセージを更新しようとすると以下のようになります。

ここまではOKです。

ここから_matched_usersの最新メッセージを更新しようとする場合、何を思ったか以下のように一度コントローラーを通さないとできないと思ってました。

そもそも_message_areaで更新された最新メッセージの値を逆流させてコントローラーまで届くのか…？ というところでつまずき、半分諦めてプルリク出そうかと思ってました。

と思ってたんですが、電車乗ってる時に勘違いに気付きました。上記のように考えてた原因はjQueryがそれぞれのビューに紐づいていると考えてたからなんですね。例えば、あるjQueryが記載されたファイルは_message_areaしか操作できない、といったように制限されてるとなぜか勘違いしてました。多分疲れてました。

実際は以下のように更新できました。

いやーなんで勘違いしてたんだろう…部分テンプレートだからアクセスできないっていう風に考えてたっぽいんだけど…

無事実装完了したのでプルリク出してメンターさんからLGTMをもらったのでmasterブランチにマージしました。

ポイント機能

次はポイント機能を実装します。

どういう機能かというと、お金をポイントに交換することができてそのポイントで「いいね」を買ったり、メッセージ付き「いいね」を送れたりします。

その根幹となるポイント機能ですが、実際の決済機能は実装しません。ダミーのカード番号や有効期限が入力されていればポイントが購入できるようにします。

pairs_point from Kosaburo Kaneko on Vimeo.

今週はとりあえずビューだけを完成させました。ここのビューではモーダルが使われていてそこに結構時間使っちゃったんですが、それは別の記事にしようと思ってます。

ポイントを購入したらDBが更新されるバックエンドの動きを実装できれば完成…ですが毎回そんなすんなり行くことはないので、油断しないようにします。

終わり

いやほんとビュー作るのって時間がかかるんですよね…

時間かかるし、いくら時間かけても終わりがないし、いくら時間かけても機能自体は実装されないんですよね。フロントに注力しすぎて時間と労力かけた割には全然進んでないみたいな状況に陥る気持ちはわかるような気がします。

なのでフロントをある程度実装したらまず機能を作ることを先にやるように意識してます。それで全体の枠ができてそれでもフロントを修整したかったらするようにすればまあ進まないってことはないかなと思います。

【6週目】未経験からTECH::EXPERTでプログラミングやってみた

最終週（最初のプロジェクトの）

仕上げ

現在同時進行で二つのプロジェクトが進んでいて、そのうちの一つは今週いっぱいで終了でした。アジャイルチーム開発を初めてやった案件なので、なんか思い入れがあります。

今週は軽微な修正とテストとデプロイがメインでした。軽微と言っても使う側から見ると軽微でも開発側から見るとけっこう手間かかったりするんですよね…。

• AjaxでのレスポンスとHTMLでのレスポンスでコメント表示の見た目が違う
• 各ポストにはタグ付けができ、作成されたタグの一覧を（きれいに）表示する
• Newest / Popular機能
• ポスト投稿時にアップロードする画像をプレビュー表示させる
• アップロードした画像をポスト編集時に表示させる

このような点を今週は修正していきました。

ユーザーからすると当たり前に感じる機能ですが、いざ実装しようとすると「あれ？どうやってやるんだっけ？」ってなったりしました。一回実装したのに他でバグが出て泣く泣く削った機能もありましたが、なんとか最終形に持っていくことができてよかったです。

テスト

テストコードを書くのは自分が担当しました。正直あまり得意じゃないので、チャレンジしようと思って自分から名乗り出ました。やめとけばよかった。

• 投稿機能
• ポストへのコメント機能
• ポストへのタグ付け機能
• ポストへのLike機能

それぞれ「投稿ができる」「削除ができる」「編集ができる」ことをテストコードで保証しなければなりません。

カリキュラムで習った通りrspecでテストコード書き始めました。投稿と編集については問題はなかったんですが、どうしても削除のテストがうまくいきませんでした。

削除はログインしていないとできないようにしているので、deviseというgemを使ってログインをしてから削除をするという行動をテストで再現します。

そこの絡みかFactoryGirlなのかわかりませんが、email has been already takenというエラーをずっと回避できないままタイムアップでした。database_cleanerをインストールすればいいみたいな話もあったんですが、解決までには至らず…めっちゃ悔しいです。

テストってものを作り上げていくわけではないので、同じコードを書くにしても機能を実装してる時とかなり意識が違うなと感じます。好き嫌いが分かれると思いますが、個人的にはテストが通った時の気持ち良さはけっこう癖になる気がしてます。気がしてるだけですが。

Pairsクローン

メッセージ機能実装

Pairsを使ったことがあって相手からちゃんと返事が返ってくる人ならわかると思いますが、Pairsには素晴らしいメッセージ機能が備わってます。この機能を僕が担当することになりました。

実際開発者目線で見ると新たな発見がいろいろあります。今パッと思い返すだけで以下のような機能があります。

• 自分と相手のメッセージで見た目を切り替える
• 同じ日付のメッセージには重複して日付を表示させない
• それぞれの相手との最新のメッセージをサイドバーに表示
• 一通目以外は画像投稿ができる

などなど。

正直言って、めっっっっっっちゃ苦戦しました。

• それぞれの相手との最新のメッセージをサイドバーに表示

これ！こいつ！これをRailsだけでどうやったらできるのか、かなり悩みました。ここはビューをどういう構造にするのかにも関わるので、影響が及ぶ範囲が大きくて大変でした。

いやーーー丸三日間作っちゃ壊してを繰り返してやっっっっっとこの機能できた！最新のメッセージをユーザーごとに表示するとこなんだけど、検索してもハマるやり方がなかったからフルRailsで自力で作った！！！素晴らしい！！！！！自分で自分を褒めるスタイル！！！！！！！！！！！ pic.twitter.com/FpFTFZJPSu

— 金子幸三郎@未経験エンジニア (@Kosaburo_Kaneko) 2018年6月7日

夜ガチャガチャいじってて突然閃いた勢いでツイートしちゃいました。あと日付もeach_with_indexとか使ってごにょごにょやるとできるということに気づけました。ググっても出てこないんすよここら辺。そのうち記事にしようかなと思います。

難易度が上がれば上がるほどピンポイントでの解決法はGoogle先生も知らないことが増えるので、蓄えた知識と経験を応用させて解決しなきゃいけません。これができたことがすごく嬉しかったです。あーエンジニア面白いなーって改めて思いました。

スプリントレビュー

毎週月曜から土曜までを1スプリントとして区切っていて、土曜はメンターさんのレビューが入ります。Pairsでは初めてのスプリントレビューでした。

僕が作ったメッセージ機能をメンターさんに見せたところ、

メ「Ajaxですか？」 

僕「違います」

メ「Ajaxにしましょう」 

〜終了〜

…

裏側の苦労とかは別によくて、必要なのは機能なんですよ（泣）

基本的な機能は実装できてたから突っ込むところは特になかったのでこんな感じであっさり終わったんだろうという超ポジティブ思考でいきます。

工数見積もり

見積もり失敗

第一スプリントが終了したのでチームで振り返りをしました。

結果的に僕が担当したメッセージ機能も完成はできず、各機能も部分的にしか実装することはできませんでした。それ自体はまあ、それはそれで仕方ないのですが、問題はこれが当初の見積もりと大幅な差があったことです。

先週各機能の見積もりをやったという話をしましたが、その時には第一スプリントで各自が担当した機能は全て完璧に実装完了して、プラスAWSにもデプロイした状態でスプリントレビューを迎えられるだろうという見積もりでした。

実は一度見積もりをみんなで出してみた後に「う〜ん、これって余裕がありすぎない？」という雰囲気になって開発する機能を追加したという経緯がありました。

なぜここまで見積もりと現実が乖離したかというと、各機能に必要な要素を把握しきれてなかったからだと思ってます。

僕が担当したメッセージ機能を例にとると、僕自身過去にメッセージ機能を開発した経験があったので、見積もり段階ですでに具体的な開発手段のイメージがついてました。

ですが、実際に開発を始めると

• 同じ日付のメッセージには重複して日付を表示させない
• それぞれの相手との最新のメッセージをサイドバーに表示

これらのような、「あ、これも実装しなきゃいけないじゃん。しかも実装した経験ないわ。」というものがポロポロ出てきました。なので結果的に当初の見積もりよりも実際の工数の方が多くなってしまったんですね。

対策

以下の二つの対策案にたどり着きました。

• 見積もり精度を上げる
• バッファーを見積もりに入れる

まずそもそも初回の見積もり時に把握できてなさすぎたことがあると思います。なんとなくメッセージ機能ってこうだよね、ぐらいの感覚で見積もってたのかなーと。見積もりにはもう少し時間をかけてチームとコミュニケーションをとりながら機能の全容を把握していってもいいと思いました。

ですがそれでも完璧に見積もるというのは不可能だと思います。

前職が機械メーカーだったので、納期を見積もってお客さんに出すのは日常茶飯事でしたが、最低でもプラス一週間は多めに出していました。だいたい海上輸送で機械を日本に持ってくるので、まず製造自体が遅れるリスクもあるし、海上輸送がどこかでストップしたり税関で止められるリスクもあるからです。

つまり予期しないことが発生することを見込んで、最悪そうなった場合でも支障なくプロジェクトを進められるように見積もりをしていました。まあ実際支障は出ますけど、最低限に抑えられるようにバッファーをかませていました。

なのでそのやり方をこっちにも持ち込もうと思います。

終わり

もう何百回も言ってる気がしますが、スクールに通う醍醐味はこのチーム開発だとつくづく思います。なんかもう得るものが大きいです。一人じゃ絶対に得られないものを得られます。

実際に転職する前に体験しておけばかなりスムーズに業務に移れるんじゃないかと思います。

書いてて思い出したことで、なぜ見積もりポーカーするときの数字がフィボナッチ数なのかという疑問があったんですが、いい記事をみつけたので貼っときます。

tango-ruby.hatenablog.com

絶対にPairs完成させたいと思います。

【5週目】未経験からTECH::EXPERTでプログラミングやってみた

チーム開発に次ぐチーム開発です。どんなスーパーエンジニアでもチームで動くわけなので絶対に押さえなければいけないポイントではあります。

一人で開発するのとはまたいろいろ違ってたくさん発見があるのが本当に面白いです。ここに関してはハードスキルよりもソフトスキルが試されます。技術力を高めることはもちろんなんですが、ソフトスキルも高めてエンジニアとしてもビジネスパーソンとしても成長したいですね。 

チーム開発継続中

先週から開発してるアプリは引き続きチームで作ってます。

毎週土曜日は他のチームと一緒に一週間の進捗を発表する時間があります。実際にアプリのデモを行いながら振り返るので、前もってherokuにデプロイしておく必要があります。

なので金曜日にデプロイ作業を30分程度で行うように見積もっていたんですが、甘かったです。鬼のエラー地獄が待ってました。結局1時間以上はデプロイ作業やってたと思います。

gitでherokuにプッシュする時にエラーが出ました。ネットで調べてもほとんど情報がなく苦労したんですが、結局railsのバージョンを上げたら完治しました。デプロイするときにいろんなgem等のバージョン周りでデプロイ先とうまくいかないことがよくあるような気がしてます。

でも次もう一回エラー出てもどこから手をつけるか難しいな…エラー文にバージョンのことは明示されてないから、そもそもバージョンが問題なのかどうかもわからないしバージョンだったとしてもある特定のgemが悪さすることもあるらしいので、gemなのかrailsなのか…余計にややこしいです。

初めての面接

今週TECH::EXPERTに入ってから初めて面接を受けました。聞かれた質問はこんな感じですね。

• どういうことをスクールで学んでるか
• どういう開発チームを好むか
• なぜエンジニアになりたいか

なんかやっぱり面接を受けて人と話すことでふわっとしてたとこが固まってくるみたいなことありますね。もちろん話す内容は準備してましたが、いろいろ考えることがありました。

どういうエンジニアになりたいのかとか、そもそもなんでエンジニアになろうと思ったのかとか、スクールに入って実際にコード書き始めるとあまり意識しなくなっていたので、意識づけして最短ルートで進んでいきたいと思います。

プロジェクト追加

今のチームとは別のチームにもアサインされ、既存サービスの完コピを作るプロジェクトを開始することになりました。通常最初のチーム開発を終わらせてからこの完コピを開始するんですが、僕の場合ちょっと早めにカリキュラムを終わらせたので前倒しにしてもらいました。

で、チームで話し合って「Pairs」のクローンを作ることにしました。今回もアジャイルで開発していきます。

まずプロダクトバックログに機能を書き出して、見積もりポーカー（各機能がどれくらいの工数を要するかチームで決める方法）を行うとこまでやりました。これだけで9時間ぐらいかかりました。

それぞれの機能の難易度感をチーム内ですり合わせるのに時間がかかるんですよね…でもこれをやらなかったら見積もりがバラけてかなり精度が落ちるので必要なもんだと思ってますが、実際現場はどうなんだろう。もっと上手なやり方がある気がするな。 

読書

Twitterで紹介されていた技術書を買ってみました！多分人生で購入した初の技術書です。

Progate交流会でもオブジェクト指向の話出たから、買ってきた！@neer_chan さんのツイートが無ければまだ出会ってなかったであろう…感謝🙏 pic.twitter.com/zEFk0wHyXQ

— 金子幸三郎@未経験エンジニア (@Kosaburo_Kaneko) 2018年6月1日

一瞬で読み進めてしまったんですが、めっちゃ面白いですねこれ。オブジェクト指向と言えばなんか人間クラスがあって歩くとか喋るとかいうメソッドがあるぐらいのぼやっとした比喩でしか認識してなかったけど、そもそもなぜオブジェクト指向が必要とされたのかその経緯から教えてくれるのでスッと入ってきます。いやーまだまだ勉強できることがたくさんあって嬉しいです。

終わり

このチーム開発が終わるとカリキュラムは全部終了なんですよね。卒業まで一ヶ月切った今、入る前よりかなりスキルアップしていると感じてます。むしろここからどういう方向に進むかしっかり考えないと…というフェーズに来てる気がします。

今週はスケジュール的にカリキュラムとカリキュラムの谷間みたいなタイミングだったのであまり書くことはなかったんですが、実際のチーム開発作業は月曜から始まるのでなんとか三週間で完成できるように頑張ります！

<Rails> user_signed_in?って本当に必要なの？

素朴な疑問かもしれませんが、Railsでツイッターのようなアプリのコードを眺めていた時にこの疑問にぶち当たりました。 

ツイートの一覧を表示するビューの中で、もし表示されているツイートと現在ログインしているユーザーが同じであればツイートの編集リンクと削除リンクを表示させる、というロジックですね。

以下のコードです。

<% if user_signed_in? && current_user.id == tweet.user_id %>
  <li>
    <%= link_to '編集', "/tweets/#{tweet.id}/edit", method: :get %>
  </li>
  <li>
    <%= link_to '削除', "/tweets/#{tweet.id}", method: :delete %>
  </li>
<% end %>

deviseを使っているのでuser_signed_in?とcurrent_userメソッドが使えます。

あと@tweetsがcollectionでコントローラーから渡されてます。

なぜuser_signed_in?が不必要ではないかと疑問を持ったかというと、current_userメソッドはユーザーがログインしているからcurrent_user.idでそのユーザーのIDを取ってこれるわけで、であればログインしているかどうか条件分岐してくれるuser_signed_in?メソッドはいらないのではないかと、そう思ったわけです。

つまり以下のようなコードでいいんじゃないかと考えました。

<% if current_user.id == tweet.user_id %>
  <li>
    <%= link_to '編集', "/tweets/#{tweet.id}/edit", method: :get %>
  </li>
  <li>
    <%= link_to '削除', "/tweets/#{tweet.id}", method: :delete %>
  </li>
<% end %>

ですがこれだとうまくいきません。

ユーザーがログインしていない場合、このコードだとcurrent_userがnilになり、current_user.idを取りに行けないのでエラーでアプリが止まります。ユーザーにいつも我々が見てるあの紅のエラー画面を見せることになります。

あれ？でもuser_signed_in?も同じような挙動じゃないの？と思ったんですが、user_signed_in?の場合はユーザーがログインしてなかったらこのif文自体全部スキップさせるようです。なのでcurrent_user.idを参照することなく、end以降にジャンプします。なのでユーザーがログインしてなくてもあのエラー画面には遷移しないようです。

というわけで、ユーザーがログインしていて、かつそのユーザーが投稿している場合、といったロジックはuser_signed_in?とcurrent_user.id == hoge.idの組み合わせが必要です。

終わり

僕が疑問に思ったかのように書いてますが、スクールの友人がペアプログラミング中に言ってくれたんですけどね。

いやーペアプログラミング面白いっすね。めちゃくちゃ勉強になります。  

【4週目】未経験からTECH::EXPERTでプログラミングやってみた

ついに入学から一ヶ月経ったかー！としみじみ感じています。好きなことやってると時間って過ぎるの早いですね。

ずっと座りっぱなしなのでジムに通い始めたんですが、スクールとジムだけでほとんど1日の予定埋まるので充足感ありますね。QOL急上昇中です。

基礎的なカリキュラムはもう終えてしまったので、ここからは応用編的なところを進めていきます。

React公式チュートリアル

カリキュラムではインフラからHTML&CSS、Railsを学ぶんですが、モダンなフロントエンドは入っていません。ですがエンジニアになる上で避けて通れないとこだと思うので、自分でReactを勉強することにしました。

こちらの記事で公式のチュートリアルがいいと紹介されていたので、とりあえずそれをやってみることにしました。

student-engineer.net

作ったのはこんな感じの○×ゲームです。

Reactは状態をフロント側で保持しておくことができるってことなのかな？サーバーサイドがなくてもそういったことはできるんですね。あとjQueryよりもメンテナンス性が高いんだろうなと感じました。

でも深く仕組みを理解できてないからか、使いどころがまだわかってません。ある程度フロントが複雑になったら初めてReactを導入すべきなのか、jQueryを使うのであればもう絶対最初っから組み込んだ方がいいのか…

Stack Overflowでよっぽど古い会社じゃない限りjQueryはもう使ってないみたいな意見も目にしたので、気になります。

ポートフォリオサイト

実際にReactを使って他にも何か作ってみたいなと思い、いろいろ考えました。自分が転職目的でスクールに入ったので、せっかくならそれに役立つものを作ろうと思い、ポートフォリオを作成することにしました。

portfolio-a8cd0.firebaseapp.com

Reactの練習目的だったんですが、使った時間は

• React: 10%
• Deploy: 20%
• CSS: 70%

こんな感じになりました…^^;

でもキャリアアドバイザーさんにすごくいいと褒められたので、よしとします。

react-routerで振り分けてコンポーネントごとにコードを書いているので、見通しはすごくいいな、という印象です。確かにこれやってみるとサーバーサイドからJSONでデータ渡してあげるだけで結構スムーズにフロント側でいじくり倒せそうだなと思いました。

これ自体はある動画を参考にして制作したので、また違うデザインで作ってみたいなーと思ってます。

チーム開発

スクールの醍醐味の一つであるチーム開発がスタートしました。

4~5人構成のチームに分かれて、チームでアプリを一つ作り上げます。アプリはログイン機能、投稿機能があって、その投稿にコメントとタグ付けができるといったものです。

チーム開発はアジャイルという手法を実践しながら開発していきます。

企画、要件定義、設計、実装、テストといった流れを上流から下流に水が流れていくように開発していくモデルをウォーターフォール型と呼びます。

一方アジャイルは設計、実装、テストを小刻みに何回も繰り返しながら開発していく手法です。なのでバグがあってもバグ発生前までに戻る手数が少ないですし、仕様変更があったときなんかに対応しやすくなるといったメリットがあります。

実際に現場で取り入れられている開発手法をチームで実践しながらできるのはTECH::EXPERTの良いところだと思います。

チーム開発は全ての開発期間においてペアプログラミングでやっていきます。

これが一番大きな特徴かもしれません。1台のコンピュータを2~3人で使いまわして開発していきます。僕たちのチームでは30分ごとにキーボードを打つ人を交代するようにしてます。

キーボードを触らない人も見ているだけじゃなくて、「こうした方がいいんじゃないか」とか「なぜそこのコードはそうなってんの？」とかを話しながら進めていきます。

スクールに入った理由の中の一つがチーム開発だったのですが、その考えは大当たりでした。

まず他の人のコードを読みながら開発できるってのは他の人の頭の中を見れるような感じなので、「ああ、こういう風に考えながらコード書いてるのか」というのがわかります。

また自分の頭の中も丸裸なので、いかに自分が無思考で書いてるかがわかります。なぜここのコードはこうなのかをきちんと言語化できるようになりますし、それができなければわかるまで調べて説明しなきゃいけないのでめちゃくちゃ理解が深まります。感覚としては個人開発の6時間とペアプログラミングの1時間が同等ぐらいの密度があると思いました。

それだけじゃなく、チーム開発をどう進めていくかをチーム内で議論する機会があるので一人で開発している時には得られない経験がたくさんあります。

・commitはこれぐらいの粒度で区切った方がいいんじゃないか

・プルリクのレビューの作法を事前に決めよう

・ペア内で今何を考えて書いているのかを把握するためにコードを書く人は喋りながら書いてみよう

こういう個人開発だとなかなか意識しないところを考えるので、普段とは違う脳の領域が活性化してすごくいいです。

終わり

今週はこんな感じでした。

1ヶ月が過ぎて若干のベテラン感が出始めてきて、もはや渋谷のランチは行き尽くしました。多分。そのうち渋谷のおススメのランチでも紹介したいなと思います。

また来週頑張ります👨‍💻

<Rails> partialをrenderするときのcollectionとは？こっちの方が速いみたい。

Railsを使ってて部分テンプレートをrenderするときにローカル変数を渡すことがあると思います。いくつか渡し方があるんですが、それぞれどう違うのか、パフォーマンスの変化についてもまとめました。

前提としてtweetモデルとtweetコントローラーが存在していて、以下のようにコントローラーでインスタンス変数にtweetを代入している状況とします。

tweets_controller

def index

  @tweets = Tweet.all

end

 

each文を使う場合

eachでlocalを渡す時のビュー

<% @tweets.each do |tweet| %>

　<%= render partial: "tweet", locals: { tweet: tweet } %>

<% end %>

@tweetsというインスタンス変数に入ってるtweetの個数分だけ部分テンプレートを表示するというロジックをeach分で実装しています。実際にtweetを表示するパーシャルは下です。

_tweet.html.erb

これは単純にコントローラーから渡された@tweetsに入ってる各tweetの値を表示するようにしているだけです。

<div class="content_post" style="background-image: url(<%= tweet.image %>);">

    <div class="more">

      <span><%= image_tag 'arrow_top.png' %></span>

      <ul class="more_list">

        <li>

          <%= link_to '詳細', "/tweets/#{tweet.id}", method: :get %>

        </li>

        <% if user_signed_in? && current_user.id == tweet.user_id %>

          <li>

            <%= link_to '編集', "/tweets/#{tweet.id}/edit", method: :get %>

          </li>

          <li>

            <%= link_to '削除', "/tweets/#{tweet.id}", method: :delete %>

          </li>

        <% end %>

      </ul>

    </div>

    <%= simple_format(tweet.text) %>

  <span class="name">

    <a href="/users/<%= tweet.user_id %>">

      <span>投稿者</span><%= tweet.user.nickname %>

    </a>

  </span>

</div>

さてこれで速さを測ってみました。

パフォーマンス

Rendered tweets/_tweet.html.erb (1.8ms)
Rendered tweets/_tweet.html.erb (0.7ms)
Rendered tweets/_tweet.html.erb (0.7ms)
Rendered tweets/_tweet.html.erb (0.6ms)

データベースにtweetを4つ保存していたので、@tweetsにtweetが4つ入っていました。なので4回パーシャルが呼び出されています。これは予想通りの動きです。

each文を使わないとき

collectionでローカル変数を渡す時のビュー

<%= render partial: "tweet", collection: @tweets %>

eachで囲まない分、こっちの方が見た目的にもすっきりしてますね。collection: @tweetsという形で渡してあげると、パーシャルでtweet.user_idといった感じでインスタンスの属性にアクセスできます。

こっちでも速度を測定してみました。

パフォーマンス

Rendered tweets/_tweet.html.erb (2.7ms)

collectionで渡すとそもそもパーシャルが一度しか呼ばれないんですね。

先ほどのeach文を使用した時は合計 (3.8ms) かかっていたので、こっちの方がパフォーマンスも良いです。

これで頭の中がすっきりしました。今後eachで回したいようなパーシャルがある時はcollectionを使います。

【3週目】未経験からTECH::EXPERTでプログラミングやってみた

だいぶスクールにも慣れてきて、そろそろ近くのランチは行き尽くした感が出てきました。なんか思ったより道玄坂周辺ってランチないですよね。前の職場は神田だったので安くて美味いランチがいっぱいあったんですが、渋谷は高いっす…。

また今週やったことを記録しようと思います。

テスト

ソフトウェアを作る上でコードを書く以上に重要なのがテストです。もちろんTECH::EXPERTのカリキュラムにしっかり組み込まれています。

なぜテストが必要なのかというと、一つは仕様漏れを減らせるからです。テストを書くとなると一つ一つ丁寧に機能を確認していくことが必要になります。その分開発時間は長くなりますが、エンジニアに抜けや漏れは許されません。

前職が産業機械メーカーだったので機械エンジニアと接する機会が多かったんですが（というか僕自身もエンジニアだったんですが）、もし彼らが仕様とは違うネジ一本でもつけてしまったら大惨事です。数千万の損害賠償が簡単に発生します。

ただソフトウェアのいいところは一回作動させてエラーが出たら修正すればいいってとこですね。機械を一回動かしてみて壊れました、はさすがに怒られますからね。ソフトウェアはむしろエラーばんばん出しながら開発していけるのでいいですよね。

もう一つのメリットはリファクタリングや機能追加がやりやすくなるという点です。テストをパスすればOKという明確な指標があるので、それさえ守れば何してもいいというのは気が楽です。

機能追加してどこにどう影響が出るかというのを全て把握することは実質無理なので、テストで完全に機能するということを担保すべきですね。

さて、カリキュラムではRSpecとFactoryGirlを使ってテストを書いていきます。

RSpecはRailsでテストができるようになるgemで、FactoryGirlはユーザーログインテストなんかを簡単にできるようにしてくれます。

テストコードの書き方自体はより自然言語に近い感じなので理解しやすいですが、機能ごとに細かく書いて行ったりそもそもテスト全体を設計していくのはなかなか骨が折れる仕事ですね…テストエンジニアという職があるのもうなずけます。

チャットアプリの機能追加

非同期化

jQueryを使ったメッセージ送信のAjax化とインクリメンタルサーチを実装しました。

どちらも基本的にはclickやkeyupなどで発火したら入力データをバックエンド側に渡して、バックエンドからJSON形式でデータをもらって表示させるという流れです。

こういう書き方をしたら非同期になるのはわかったけど、本質的になぜ非同期になるのかは正直あまり理解できてないです。要勉強ですね。

あとわからないのはRailsでパーシャルをrenderすれば部分更新になると思うんですけど、これって非同期って呼ぶんですかね？あとReact routerも同じような感じで部分更新すると思うんですけど、これも非同期なのかな？

非同期と部分更新がどういう関係なのか把握せねば。

自動更新機能

これは別のブラウザーを開いていても同じチャットルームにいれば自動的に更新されて、他の人が送ったチャットが勝手に受け取れる機能です。

最初聞いた時はどんなロジックで実装するのかわからなくて、多分人知を越えたすごい実装方法なんだろうな…と思ってたらsetIntervalで一定間隔で関数実行していくだけでした。これがスタンダードなんだろうか…？LINEとかも同じロジックで更新させてるのかな？

とか言いつつ実装はかなり手こずりました。turbolinksがくせ者すぎる…こいつのせいで半日無駄にした。これが作動してると最初の訪問でjQueryが効いてくれないことがあるみたいなんですよね。リロードしたら効くんだけど。確か$(document).ready()で全体囲めば解決できた…気がする。

サーバーの基本知識

IPアドレスやSSH、Linuxコマンドに関する基本的なところを学びました。

ここに関しては多少本で勉強してたので、スムーズに理解できました。でもエンジニアです！って胸はって言えるほどには理解できてないかな…。「ポートとソケットがわかればインターネットがわかる」って本を読んだんだけど、途中から結構苦しかったのでもう一回読み直そうと思う。

ポートとソケットがわかればインターネットがわかる――TCP/IP・ネットワーク技術を学びたいあなたのために (Software Design plus)

あと秘密鍵と公開鍵のセキュリティシステムについても少し記述があったけど、これもたまたま前に本で読んでた内容だった。なるべく読書する習慣つけててよかった…。

暗号解読〈上〉 (新潮文庫)

これ確かホリエモンがオススメしてたんですよねー。単純に読み物として面白いのでオススメです。

AWS

完全に初めて触りました！今まで作ったものをデプロイすることはHeroku以外にはなかったので、なかなかチャレンジングな内容でした。と言うかほぼブラックボックスです。デプロイはできたけど何も見ずにもう一回同じことはできないだろうな…。

アカウント作成から、EC2インスタンス作成、Linuxサーバー構築、MySQLの設定、nginxとUnicornをインストールして、Capistranoでデプロイを自動化しました。

作ったチャットアプリにはcarrierwaveで画像アップロード機能をつけたので、この環境でも動くようにアップロードされた画像ファイルはS3に置くようにして連携させました。

なんか昔個人ホームページをロリポップにアップロードしたのを思い出した。何もわかってなかったから手探りでググりながらやったもんなー。DNSとか全く理解してなかったからお名前.comで買ったドメインに何も表示されなくて焦ったな。

久しぶりにロリポップの公式サイト見たら超オシャレになってて笑った。林家ペーパーぐらいピンクだったのに。

終わり

そんなこんなで自分で作ったチャットアプリのデプロイが終わり、基本的には個人作業はここで終わりです。これからはチームでWebサービスを作る期間に移ります。

ただ時間的にちょっと余裕があるので、個人的な開発もやっていこうと思ってます。せっかくいろいろ聞ける優しいメンターさんがいるので、チャレンジしていこうと思ってます。何作るかはまだ考え中…