【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サービスを作る期間に移ります。

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

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

早くも2週目が終わりました。

入る前に少しプログラミングを触っていたので余裕かましてましたが、世の中甘くないですね。

 

一つずつどのようなことを1週間で学んだかを紹介します。

 

コーヒーメーカーとWi-Fiの話を書くこと

ランチに困らない

Ruby on Rails

Twitterのようなアプリケーションを教材の指示に従いながら作りました。同じ要領で映画レビューサイトも作りました。

Railsチュートリアルを入学前に一周しててMVCの基本概念が頭に入っていたので、ここはわりとスムーズにいきました。でも周りを見ていると本当に未経験の場合ここが一番つまづくポイントみたいです。ModelとViewとControllerがどう連動しているのかを把握するのが難しいみたいですね…逆に言えば入学前にここを押さえとけばスタートダッシュできるかも。

僕はスクレイピングでちょっとつまづきました。

1ページの情報のみを取得するのは簡単なんですが、同じドメインの複数のページをスクレイピングするのが少し複雑でした。ブログとかで過去全部の記事の写真をスクレイピングしたいときなんかがこれと同じ状況ですね。

次へのボタンから次ページへ辿る動きをwhile分で基本trueで動くようにしておいて、次のページのリンクがなかったら（次へボタンがなかったら）breakさせるというロジックはすんなり理解したんですが、実際コードを書くとちょっと複雑な気がしました。

多分4年前ぐらいに自力でnokogiriというgem使ってスクレイピングしようと思って挫折したのがちょっと苦手意識つけちゃってるんだろうなと思います。

中間テスト

この時点で中間テストを受けました！

Rubyでコンソール上で動く簡単なアプリを作ったり、設計書通りにHTMLとCSSを組んだり、Railsのエラーを解きまくるという試験でした。

これは特に問題なくパスしたので、カリキュラムをもう一周しました。基本的に同じことをもう一回やるのは好きじゃないのですが、最終基礎試験に合格するために仕方なくCodecademyでReact.jsを息抜きにやりながらなんとか乗り越えました。

そしてそのまま最終基礎試験を受けました。この試験に合格すると次のステップへ進めます。合格しないとずっと同じカリキュラムを何回もやらなきゃいけないという恐ろしいことになります。

JavaScript

無事に試験に合格したのでJavaScriptとjQueryに入りました。JavaScriptの基礎から一気に非同期通信まで学びます。このセクションの最後にはあるサイトのお天気情報APIを取得し、フォームに入力があった街の天気を非同期で返すといったアプリを作ります。

JavaScriptに関してはN予備校でNode.jsを使ったタスクアプリ作成をやったことがあったので、すんなりいけました。ただjQueryはなんか書き方がごちゃごちゃして見づらいですね。なんとなくReactと比べて規模が大きくなった時の管理が難しそう…という印象を受けました。

非同期通信もN予備校で（たしか）やったので、特に理解に苦しむことはありませんでした。

なんかこれだけ見ると楽勝に見える…そんなことないのに。

学習環境について

ちなみに、TECH::EXPERTの学習環境はめっちゃいいです。

教室は新しくて綺麗でおしゃれですし、いつも静かで涼しくて、Wi-Fi爆速です（250Mbpsオーバー）。コーヒーメーカーもあるので1杯100円でそこそこのコーヒーが飲めます。椅子も疲れにくいし、文句なしです。

これだけで教室に来るモチベーションになりますね。

プロとしてのプログラミング

エンジニアになるということはよっぽどのことがない限りチームで仕事をすることになります。なのでいいエンジニアとは他人にとっても見やすいコードを書けるエンジニアでもあると思います。

そのためにはできるだけコードを短く、かつ動作は早く、綺麗に書くことが大切です。RubyにはRubyの書き方の規則がありますし、RailsにはRailsの規則があります。変数の命名、改行等少し工夫すればかなり可読性が上がります。

また会社ごとにも少しずつ規則は変わってくるはずなので、他人のコードを読んでどんな規則に則ってコードを書いているのか読み取る力も大事ですね。

TECH::CAMPでは単独作業の段階からメンターさんがどうやったらもっと綺麗なコードを書けるかレビューしてくれます。そのおかげで早い段階から他人の目を意識したコードを書けるようになります。

Git

エンジニアになるためにはコードが書ければいいわけではなく、その周辺ツールも使いこなせる必要があります。Gitは間違いなくエンジニアに必須のツールです。

むちゃくちゃ簡単にいうと、どこまで作業したのか履歴を残すことができます。チームでGitを使えばAさんは検索機能、Bさんは買い物かご機能をバラバラに実装して後でがっちゃんこしてもごちゃごちゃならないようにできます。

本当に良かったなと思うのは、N予備校でNode.jsを勉強した時もRailsチュートリアルやった時もGit使ってたんですよね。誰とも共同作業はやってませんでしたが、リモートリポジトリも作って時々プッシュしてました。なのでGitの基本的な使い方は困ることがなかったので助かりました。

SQL

もちろんしっかりSQLも学びました。データをうまく使いこなして初めてサーバーサイド言語が真価を発揮します。

SELECTやWHEREを使って望んだデータを引っ張ってくることができるようになるまで一通り勉強しました。JOINまではやってません。

正直Rails使ってるとSQLの存在を忘れちゃう感じはありますね。むちゃくちゃ簡単にデータ持ってこれるので、SQLが一番脳に定着しなさそうです。

チャットアプリ実装開始

ここからが本番です。試験を突破した後の目標はこのアプリを完成させることです。

今まで学んで来たことの応用なので、教材のサポートは最小限です！自分の力で実装していかなきゃいけません。わからなければ検索です。それでもダメだったらメンターさんが助けてくれますが…できるだけ自力で解決していきます。

フロント実装

まずはアプリの原型となるフロントの大枠を与えられた設計書通りに実装していきます。

今回はSassを使って書いていきます。CSSを便利にしたやつですね。変数使えるのでDRYな記述ができます。

できるだけBEMに則って書いていきます。BEMはフロントエンドの要素をBlock、Element、Modifierという三つの要素に分けて整理します。特にクラス名の規則が厳格です。クラス名が冗長になりがちな印象を受けましたが、コードの再利用性は高いと思います。

ふむふむ…と思いながら実装開始しましたが、なんでこいつがここに行かねえんだよ！とかおい！あいつちょっと見ないうちにどこ行きやがった！！みたいなことが頻発しました。正直全体を通してここが一番時間かけたとこだと思います。

やんちゃなdiv要素たちをなんとか手懐けてフロントエンドの大枠は固まりました。

2週目終わり

そんなこんなで2周目が終わりました。やることが多かったので苦労しましたが、だんだん慣れてきて実装にスピードが出るようになってきました！

この調子で3週目もスパッとこなしたいと思います。

Sassパーシャルをapplication.scssで@importする順番

Railsでチャットアプリを作っていて、まず手始めにSassで見た目を作っていました。

その時にパーシャルをいろいろ作ってたらハマってものすごい時間を食ったので、こんなしょうもないハマり方を今後一切人類が繰り返さないようにここに記します。

パーシャルとは 

振り返りも兼ねてほんの少しだけ丁寧めに書くので、理解している方は飛ばしてください。

CSSでは下記のようなページを構成するそれぞれのパーツをパーシャルと呼ばれるCSSファイルに分割します。

• ヘッダー
• サイドバー
• メインコンテンツ
• フォッター

理由はメンテナンスしやすいことと、可読性を良くするためです。

一つのCSSファイルになんでも詰め込んでしまうとどうしても長くなってしまいますし、どこがHTML内のどの要素を指しているのかわかりづらくなります。

Sassとは

SassとはCSSをもっと便利にしたものです。主に二つ、大きな特徴があります。

• 変数
• Mixin

変数

変数の概念はRubyと同じく、何か値を入れる箱のようなものですね。例えばRubyだとこんなんです。

name = "Kosaburo"

これと全く同じことがCSSでできるんです！

例えばこういうCSSファイルがあったとします。人間のリスト（human_list）と日本人のリスト（japanese_list）があり、どちらも文字の色（color）にはblueが使われてますね。

.human_list {

 font-size: 20px;

 color: blue;

}



.japanese_list {

 font-size: 20px;

 color: blue;

}

これくらいのサイズならいいんですが、これがamerican_listとかchinese_listとか国ごとに増えていくとすると、毎回同じblueを指定するのは大変です。

それに後から文字色をgreenに変えようと思ったら、全部変更しなきゃいけません。

そこでSassの変数を使い、こんな風に書くと便利です。

$name_color = blue;



.human_list {

 font-size: 20px;

 color: $name_color;

}



.japanese_list {

 font-size: 20px;

 color: $name_color;

}

これであれば色の変更があっても、変数を変更すれば一発で全部適応されますね。

Mixin

これは個人的には変数を進化させたもののような印象があるんですが…どうなんですかね。Mixinを使えば上のコードがなんとこうなります。

@mixin human_style() {

 font-size: 20px;

 color: blue;

}



.human_list {

 @include human_style();

}



.japanese_list {

 @include human_style();

}



.american_list {

 @include human_style();

}

いちいち要素ごとにスタイルを指定する必要はなく、一緒にスタイルであれば全部まとめて最初に定義しちゃいます。それを使い回せばほらスッキリです。

そしてこの変数とMixinをまとめたものを「_variables.scss」というパーシャルに切り出して保存します。

 パーシャルを呼び出す

準備は整ったので、「application.scss」から「_variables.scss」を呼び出しましょう。下記のように「application.scss」に記載します。

@import "./reset";

@import "font-awesome";

@import "main_wrapper";

@import "side_bar";

@import "main_content";

@import "variables";

これで完成！

全然ダメ

全然完成じゃありませんでした。いろんな変数が定義されてないっぽくレイアウトが激崩れを起こしていたのですが、スペルミスもないしなんでダメなのかしばらくハマりました。

そうなんです！原因は「application.scss」で@importする順番だったのです。

変数を定義する「_variables.scss」を他CSSファイルよりも後に読み込んでいたのでうまくいかなかったようです。他CSSは「_variables.scss」の中の変数を使うように設計されているので、先に読み込む必要があります。

変数を使う前に先に定義するぐらいわかってたつもりだったんですが…慣れてないものがいくつか重なるとこういうことが起こりますね。

頑張ります。