【技術書メモ】Everyday Rails - RSpecによるRailsテスト入門 〜毎週アウトプットチャレンジ②〜

会社のマネージャー技術力高くてすごく尊敬してるのだけど、年に50冊技術書読むらしい、、、！
毎週１冊ペースや…！

早速、毎週 技術書１冊をブログでアウトプットするチャレンジ始めてみます！！！
モチベーション高くて時間もある今なら出来るはず…！

誰か一緒にやりませんか？笑

— ゆうすけ@Railsエンジニア (@ysk_pro) July 13, 2018

毎週 １冊技術書を読んでブログでアウトプットするチャレンジの第二弾です〜！

技術書の読み方はこちらの記事に書きました。

【保存版】技術書の読み方について - 銀行員からのRailsエンジニア

「何が書いてあったか」「抽象的な考え方」を中心にアウトプットしていきます。

第二弾で読んだ本はこちらです。

leanpub.com

RSpecについての有名な電子書籍です。

RSpecのセットアップ

・RSpec gemをインストールすると作成されるファイルは以下の４つ

　- .rspec：設定ファイル

　- spec：スペックファイルを格納するディレクトリ

　- spec/spec_helper.rb・spec/rails_helper.rb：RSpecの動きをカスタマイズするヘルパーファイル

 

・.rspec ファイル内に一文追加することで、RSpecの出力を読みやすいドキュメント形式にすることができる

 

・binstub をインストールすると、アプリケーションの起動時間を素早くするSpringの恩恵が受けられる

 

・rails g コマンドを使った際にスペックファイルを同時に作成するための設定方法について

 

モデルスペック

・モデルはアプリケーションのコアであり、モデルが十分にテストされていると信頼性の高いコードを構築できる

 

・モデルスペックには次のテストを含める

　- 有効な値が入力された場合は、モデルの状態が有効（valid）になっていること

　- バリデーションを失敗させるデータであれば、モデルの状態が有効になっていないこと

　- クラスメソッドとインスタンスメソッドが期待通りに動作すること

 

・境界値のテストをするべき

 

・describeとcontextは互換可能であるものの、基本的な使い分け方は以下の通り

　- describe：クラスやシステムの機能に関するアウトラインを記述

　- context：特定の状況に関するアウトラインを記述

 

・before はdescribeまたはcontextブロック内の各テストの前に実行される

 

・可読性を優先してDRY原則に違反するのは問題ない。テストはDRYであることよりも読みやすいことの方が重要

 

テストデータの作成

・テストシナリオが複雑になった際にFactory Bot gemを使うとテストデータのセットアップをシンプルにすることができる

 

・ファクトリを使えば、FactoryBot.create(:user)と書くだけで、簡単に新しいユーザーを作成でき、スペック全体で使うことができる

 

・FactoryBot.build では新しいテストオブジェクトをメモリ内に保存し、FactoryBot.create ではアプリケーション用のデータベースにオブジェクトを永続化する

 

・ファクトリはシーケンスを使うことでそれぞれにユニークな値を設定できる

 

・ファクトリは数行のコードを書くだけで、必要なデータを作ってくれてセットアップ用のコードも短くなりテストコードが読みやすくなる。しかし、ファクトリを使うとテスト中に予期しないデータが作成されたり、無駄にテストが遅くなったりする原因にもなる可能性がある。できる限りFactoryBot.createではなく、FactoryBot.buildを使うことでデータベースに追加する回数が減り、パフォーマンスの低下が軽減できる。

 

コントローラスペック

・前提として、RailsチームとRSpecチームの双方が、コントローラのテストを削除するか、モデルのテストやより高いレベルのフィーチャスペックと置き換えることを推奨している

 

・コントローラスペックは、基本的にブラウザに返すレスポンスコードをテストする

 

・Deviseのヘルパーを用いて、認証が必要な処理もテストすることができる

 

フィーチャスペックでUIをテストする

・Capybara gemを使うとリンクをクリックしたり、Webフォームを入力したり、画面の表示を検証したりすることができる

 

・コントローラスペックではユーザーインターフェースを無視して、パラメータを直接コントローラのメソッドに送信するのに対して、フィーチャスペックではユーザーが使うものと全く同じユーザーインターフェースを使ってテストをする

 

・フィーチャスペックでは１つのexample、もしくは１つのシナリオで複数のエクスペクテーションを書くのは問題ない

 

・save_and_open_page、Launchy gemを使うことで、save_and_open_pageをスペック内で呼び出した時にHTMLを自動で開き、デバッグすることができる

 

・シナリオ文の後に、js: trueというオプションを渡すことで、JavaScriptを用いたテストを行うことができる

 

リクエストスペックでAPIをテストする

・API関連のテストは spec/requests ディレクトリに配置する

 

・リクエストスペックではCapybaraは使わない（Capybaraはブラウザの操作をシミュレートするだけであり、プログラム上のやりとりは特にシミュレートしないため）

  

・コントローラスペックをリクエストスペックで置き換えることは可能

 

スペックをDRYに保つ

・重複するコードはサポートモジュールに切り出すことが可能であり、フィーチャスペックでよく使われる

 

・letメソッドは遅延読み込みされるため、使う必要のないデータを作成してテストが遅くなるといったことが起きにくい

 

・shared_contextを使うと、複数のテストファイルで必要なセットアップを行うことができる

 

・自分で独自のカスタムマッチャを作成することが可能

 

・aggregate_failures を使うとその中では１つのエクスペクテーションが失敗しても、次のエクスペクテーションが実行される。これにより、同じコードを何度も実行して遅くなったり、複雑なセットアップを複数のテストで共有したりせずにテストが失敗した複数のポイントを把握することができる

 

速くテストを書き、速いテストを書く

・Soulda Matchers を使えば、モデルの簡単なテストを1行で書くことができる

 

・モックは本物のオブジェクトのふりをするオブジェクトで、テストのために使われる。テストダブルと呼ばれることもある

（メリット）

　- モックはデータベースにアクセスしないため、テストにかかる時間が短くなる

　- 時間のかかるネットワーク呼び出しを実行する必要があったり、レートリミットを持つ外部APIとやりとりする必要があったりする場合、モック化はそうしたコストを最小化してくれる

 

・スタブはオブジェクトのメソッドをオーバーライドし、事前に決められた値を返す。つまり、呼び出されるとテスト用に本物の結果を返すダミーメソッド

 

・テストがとても遅くなったり、再現の難しいデータ（外部APIなど）をテストするのでなければ、無理にモックやスタブを使う必要はない

 

・タグ機能を使えば、ファイル内の特定のテストだけを実行して、それ以外はスキップするようにできる。新機能追加の時などに使うとテストの実行が早くなる

 

・ParallelTests gemを使ってテストを並列に実行すると格段にスピードアップする可能性がある

 

その他のテスト

・ファイルアップロード機能のテストについて

 

・Active Jobを使ったバックグラウンドジョブのテストについて

 

・メール送信のテストについて

 

テスト駆動開発

・テスト駆動開発（TDD）は、以下の手順で行うとスムーズに進む

1.  必要なステップをテストコードにコメントとして記載する
2.  コメントをテストコードに置き換える
3.  テストを実行し、テストが失敗したエラーメッセージを見て、そのエラーを発生させたないための実装をする
4.  テストが成功するまで 3. を繰り返す
5.  リファクタリングを行う

 

・新機能を実装する際にテストを書くことで、リファクタリングが楽になり将来的に時間をかなり節約することができる

 

テストを書く順序

・テストを書く順序は、フィーチャスペックを書いてからモデルスペックを書く。その際はエンドユーザがタスクを完了させる手順を考えて書く。これは外から中へと呼ばれるテストを書く際の一般的なアプローチ

 

RSpecを書いてみた感想

今までRSpec(テストコード)書くのめんどくさいな〜、
て思ってたけどちゃんと書いてみたらリファクタリング(コードをキレイにすること)がめちゃくちゃはかどる！

当たり前だけど、いちいちローカルで動くかどうかをポチポチ確認しなくていいのが快適！

RSpec書くの楽しくなってきた〜！

— ゆうすけ@Railsエンジニア (@ysk_pro) July 18, 2018

↑テストコード書くのが楽しくなってきました！笑

・RSpec自体は思っていたよりも難しくなく、直感的に書くことができました

・テストコードを実装前に考えることで、実装方法を考える時間が増え、実装がスムーズになったような気がします

おわりに

来週も頑張ります！（来週末引越しなので次は再来週になってしまうかもしれませんが…）

この記事で紹介した本を順番にアウトプットしていく予定ですー！

ysk-pro.hatenablog.com

【技術書メモ】パーフェクトRuby on Rails 〜毎週アウトプットチャレンジ①〜

はじめに 

会社のマネージャー技術力高くてすごく尊敬してるのだけど、年に50冊技術書読むらしい、、、！
毎週１冊ペースや…！

早速、毎週 技術書１冊をブログでアウトプットするチャレンジ始めてみます！！！
モチベーション高くて時間もある今なら出来るはず…！

誰か一緒にやりませんか？笑

— ゆうすけ@Railsエンジニア (@ysk_pro) 2018年7月13日

 ということで、毎週 １冊技術書を読んでブログでアウトプットするチャレンジを始めました！

この記事はその第一弾です。 

毎週読むにあたって心がける読み方のポイントはこちらです。

・何が書いてあったかを覚えるだけでいい → 辞書のように使う

・具体的なことよりも抽象的な考え方を身につける → 抽象的なことの方が汎用的

・できるだけたくさんの本を読んだ方がいい → 引き出しを増やす

・アウトプットをする → 考えながら読むようになる 

詳細はこちらのブログに書いています。

ysk-pro.hatenablog.com

「何が書いてあったか」「抽象的な考え方」を中心にアウトプットしていきます。

第一弾として読んだ本はこちらです。 

パーフェクトRuby on Rails

Ruby on Railsの超有名な本です。 

 

１章 Ruby on Railsの概要

＜Railsの思想＞

・CoC（Convention over Configuration）（設定より規約）

（メリット）

　- 規約に従うことで設定ファイルを書く必要がなくなる

　- 開発者毎の設定の差異が無くなり、他のエンジニアと共通のルールでコミュニケーションが取れる

 

・DRY（Don’t Repeat Yourself）

　- 1つのことは1箇所だけに書く

 

・REST（Representational State Transfer）

　- Webアプリケーションの設計概念の1つ

　- 全てのリソースに一意となる識別子(URI)がある

　- URIを通じてリソースを操作する手段を提供する

（メリット）

　- リソースを中心に考えることで、機能追加のしやすい自然な設計になる

 

・自動テスト

　- Railsでは自動テストを行う文化を重要視している

 

２章 Ruby on RailsとMVC

＜MVCアーキテクチャ＞

・Model：データベースとの接続とデータに対する操作、およびビジネスロジックを書く

・View：Modelの内容を参照し視覚表現を行う

・Controller：Modelのロジック呼び出し、必要なViewの選択など、ModelとViewをつなぐ

 

＜モデル＞

・ActiveRecordによるモデルには、大きく分けて2つの側面がある

　- データベースと接続し、データベースのレコードのレコードとエンティティを結びつける役割

　- ビジネスロジックの実装的な振る舞いに関するところ、すなわちバリデーションや、様々なコールバック（特定の処理に引っ掛けて別の処理を呼ぶこと）などを実行する役割で、ActiveRecordの内部で利用されているActiveModelというモジュールが担っている

 

・モデルにはScopeを定義できる

　- Scopeとは、よく利用する検索結果に名前をつけてひとまとめにしたもの

（メリット）

　- 繰り返し利用するクエリの再利用性が上がる

　- クエリに名前をつけることで可読性が向上する

 

・ActiveRecord enumsは、プログラム上では定数のように扱えるが実態は数値で表されるもの

（メリット）

　- 直接文字列として保存するより数値として保存した方がデータベース上の空間効率が良くなる

 

・アプリケーションの主要なロジックはなるべくモデルに書くべき

（メリット）　

　- コードが整理され、テストがしやすくなる

 

＜コントローラ＞

・コントローラが継承しているApplicationControllerは、アプリケーションのすべてのコントローラで共通するヘルパーや属性、挙動などを定義する場所

 

・Railsアプリケーションにおいては、基本的にコントローラが例外処理を担当する

 

＜ビュー＞

・variantsという機構で、接続してきた端末によって別々のテンプレートを表示させることができる（スマホ用のテンプレートなど）

 

・HTMLタグの付与などビューに特有の加工をする場合は、モデルに変換処理を書くより、ヘルパーを利用するやり方が一般的

 

・Railsのビュー処理を通すと、テンプレートエンジン内でRubyのStringのオブジェクトを描画しようとした場合に自動でHTMLタグに対してエスケープ処理が施され、単純なXSSを防ぐことができる

 

・HTTP APIのサーバの場合、必要な情報はHTMLではなく別のフォーマットで渡す場合がほとんど。JSON APIであれば、ビューの担当する仕事はJSONを生成することとなる

 

３章 アセット

・Railsではデフォルトでいくつかのアセットパスが用意されている

　- アプリケーションのメイン機能に関わるもの：app/assets

　- 共通で利用するライブラリに関わるもの：lib/assets

　- オープンソースのJavaScriptライブラリなどの外部から取得して利用するもの：vendor/assets

 

・アセッツプリコンパイルについての説明

 

・CoffeeScript、Sassについての説明

 

・Turbolinksは、JavaScriptやCSSに変化が無いのであればタイトルとbodyだけ差し替えることでJavaScriptやCSSの読み込みを省略することができ高速化できる、という思想のもとに成り立つ

（注意点）

　- ページ遷移時のイベント発行を前提にしていたり、グローバルな変数にデータをを保持しているJavaScriptは、意図した通りに動作しなくなる場合があるので注意が必要

 

４章 Railsのロードバスとレイヤーの定義方法

・MVCに当てはまらないようなモジュールの主要な管理方法

　 - モデルとして扱う

　 - libディレクトリで管理する

　 - 新しいレイヤーを定義する

 

・Railsは命名規則に沿ったファイル名とクラス名を採用していると自動でファイルをrequireしてくれる、オートローディングという機能が備わっている

 

・Sidekiqは、バックグラウンドで継続する非同期処理を行う

　- SidekiqはRailsとは別にプロセスを立ち上げ、そのプロセスがRailsからのメッセージを受け取りワーカークラスを引き渡して実行することで非同期処理を実現している

　- Sidekiqを使用するためにはRedisが必要になる

 

５章 開発を効率化するgem

・Pry：ステップ実行を行うことができる

 

・Hirb：コンソール上でモデルを表形式で出力できる

 

・Better errors：JavaScriptでの非同期処理などのエラー画面が表示されないようなケースで例外が発生した場合、「/_better_errors」 にアクセスすることで最後に発生した例外のBetter errorsのエラー画面を参照できる

 

・rails-erd：モデル情報からER図のPDFを出力できる

 

６章 Railsアプリケーション開発

・Twitterログインの実装

 

・ログイン状態を管理するヘルパーメソッド

 

・イベントのCRUD機能実装

 

・i18nの設定

 

・よく使うgem（kaminari、ransack、carrierwave）の使い方

 

７章 Railsアプリケーションのテスト

・テストを書く理由

　 - 仕様と設計を考える機会が増えることで、仕様の抜け漏れを減らし、きれいな設計になりやすい

 　- 手作業によるテストを減らせる

 　- ちゃんと動くかどうかの不安を減らせる

 　- リファクタリングや仕様変更に対応しやすい

 

・モデル、コントローラ、ビューのテスト、エンドツーエンドのテストの書き方

 

・TDDについて

（メリット）

　- それぞれの段階で、設計すること、実装すること、リファクタリングすることだけに専念できるため、一度にきれいで動くコードを書こうとするのに比べて考えなければいけないことを減らすことができる

 

８章 Railsのインフラと運用

・サーバにデプロイするにあたって必要なミドルウェア

 　- ウェブサーバ：ブラウザからのリクエストを一番最初に受け取るサーバ（Nginx、Apache2）

 　- アプリケーションサーバ：Railsのアプリケーション自体をホストするサーバ（Unicorn：Railsのプロセスを別途立ち上げる形のアプリケーションサーバ、Passenger）

 　- データベース

 

・Capistranoについて

 

９章 より実践的なモデルの使い方

・コールバックやバリデーションを別クラスに分離するメリット

 　- テストのための事前条件を満たすための負荷が減り、テストが容易になる

 

・ActiveModelモジュールを活用することで、自分で定義したプレーンなRubyクラスに対してActiveRecordに備わっている機能を組み込むことができる

 

・モデルとコントローラにデフォルトで存在するconcernディレクトリは、横断的関心事（複数のモデルや機能に跨って影響するもの）を実装する際に利用する

 

・サービスクラスはコントローラとモデルの中間のイメージで、処理そのものをカプセル化し責務を分離したもの

 

10章 Railsを拡張する

・gemを作ることができる方法としての、Rack Middlewareについての説明

 

おわりに

一週間で読むと決めると集中して読めるし、アウトプットすることで頭に残るのでいい感じです。

毎週頑張っていきますよー！

一緒にチャレンジしてくれる方募集中です〜（笑）

パーフェクトRuby on Rails

【保存版】技術書の読み方について

こんにちは。ゆうすけです。

Railsエンジニアになって1週間経ちました。

元気に働いています。

Railsエンジニアになって1週間経ちました！
〈環境〉
・Tシャツ勤務最高！
・デュアルディスプレイ × 昇降式デスク(立って作業もできる) 快適！

〈やっていること〉
研修用のRailsアプリを作りながら、Rails・周辺ツールを学んでいますー！楽しい！

早く自社サービスの改善、機能追加やりたい〜！

— ゆうすけ@Railsエンジニア (@ysk_pro) 2018年7月6日

「技術書の読み方」について会社のマネージャーにとても参考になることを教えていただいたのでブログに残しておこうと思います。

ポイントは

・何が書いてあったかを覚えるだけでいい → 辞書のように使う

・具体的なことよりも抽象的な考え方を身につける → 抽象的なことの方が汎用的

・できるだけたくさんの本を読んだ方がいい → 引き出しを増やす

・アウトプットをする → 考えながら読むようになる

です。

何が書いてあったかを覚えるだけでいい

まず、全てを覚える必要はありません。不可能です。

技術書は辞書のように使えればいいと割り切って、どんなこと書いてあったかを覚えるようにします。

実際にその技術が必要になった際に、すぐに参照できるようにしておきます。

具体的なことよりも抽象的な考え方を身につける

webエンジニアは技術の移り変わりが早いので、具体的なことは比較的早く変わっていきます。

しかし、抽象的なこと、つまり根本の考え方のようなものは普遍的で変わらないことが多いのでそれを身に付けるようにします。

できるだけたくさんの本を読んだ方がいい

同じ本を繰り返し読むことも当然大切です。

しかし、これと同じくらい、たくさんの本に触れることも大切です。

技術書を辞書的に使うと先ほど書きましたが、自分が持っている引き出しは多いに越したことはありません。

アウトプットをする

アウトプットをすると決めておけば、何をアウトプットしよう、と自ずと考えながら読むようになります。

僕はこれから読んだ技術書は基本的に全てブログにアウトプットしていこうと思っています。

目標は毎週１冊！

おわりに

いかがだったでしょうか。

技術書の読み方を教わったので、ここから更にガツガツ読んでいこうと思います。

ご意見・ご感想や、みなさんの技術書の読み方についても教えていただけると嬉しいです！

先月1ヶ月で読んだ13冊の技術書についてはこちらの記事にまとめているので、是非参考にしてみてください。

ysk-pro.hatenablog.com

【保存版】Railsエンジニアとして内定後、実務で必要とされる知識をつけるために1ヶ月で必死で読んだ13冊

はじめに

こんにちは。ゆうすけです。

僕はRailsエンジニアとして内定後、勤務が始まるまでの１ヶ月で技術書１３冊（金額にして3.4万円(汗)）を読んできました。

内定先のマネージャーにおすすめされた本も多く、Railsエンジニアに転職を検討されている方、実務レベルの知識を習得したいという方の参考になればと思い、１ヶ月で読んできた本を紹介します。

無料でPDFが公開されているものもあるので、是非参考にしてみてください。

当然ですが１ヶ月で全てを理解出来た訳ではなく、今後繰り返し読んでいこうと思っているので、自分の現状の備忘も含めて書きました。

読んだ本

基礎知識

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

kindle版無し / ３周(何周読んだか) / 理解度：高 / ボリューム：中

タイトルにもあるように、HTTP、URL、HTML、RESTなど曖昧な理解だったものが分かりやすく解説してあり、僕に欠落していたWebの知識を一気に入れることができ、とても良い本でした。

 ３周読みましたが、定期的に読み返して完全に知識を定着させる予定です。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

プログラミング一般

プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則

kindle版有り / １周 / 理解度：高 / ボリューム：中

この本は今の自分に刺さることが多く書いてあり、実践していきたいことがたくさんあったので、別のブログ記事にまとめました。

ysk-pro.hatenablog.com

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

 オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

kindle版有り / １周 / 理解度：低 / ボリューム：大

オブジェクト指向設計実践ガイド　?Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方

Ruby

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで

 kindle版有り / １周 / 理解度：高 / ボリューム：大

Rubyについての新しい学びが多く、定期的に読み返そうと思っている本です。

「プロを目指す人のためのRuby入門」読了

どこで誰に聞いても聞いてもオススメされるから間違いないと思ってたけど、
新しい学びがたくさんあってめっちゃ良かった！！

一部理解しきれない箇所もあったから、何回も読んで基礎を固めていいコードでいいサービス作るぞ〜！https://t.co/yEHcFFX4j5 pic.twitter.com/xCHG1BPIWK

— ゆうすけ@Railsエンジニア (@ysk_pro) 2018年5月27日

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで Software Design plus

なるほどUnixプロセス ― Rubyで学ぶUnixの基礎

 電子書籍のみ(kindleでは無い) / １周 / 理解度：低 / ボリューム：大

tatsu-zine.com

Rails関連

パーフェクト Ruby on Rails

kindle版有り / １周 / 理解度：中 / ボリューム：大

パーフェクトRuby on Rails

Everyday Rails - RSpecによるRailsテスト入門

電子書籍のみ(kindleでは無い) / １周 / 理解度：中 / ボリューム：中

内定先で使われているRSpecについて、実例が多く使われていたので、基本的なところはしっかり理解できました。

leanpub.com

データベース

 SQL 第2版 ゼロからはじめるデータベース操作

kindle版有り / １周 / 理解度：高 / ボリューム：小

「SQL 第2版 ゼロからはじめるデータベース操作」読了！

Railsから入るとDB・SQLの学習は後回しになるけど、大規模なDBを扱う実務ではDBの知識はめちゃくちゃ重要。マスト。
（内定先の受け売りです 笑）

めちゃ分かりやすかったからオススメです！
今月DBの本あと2冊読む！https://t.co/bFQjOyv0bX pic.twitter.com/fp573qOPqn

— ゆうすけ@Railsエンジニア (@ysk_pro) 2018年6月20日

SQL 第2版 ゼロからはじめるデータベース操作

 現場で使える MySQL

kindle版無し / １周 / 理解度：低 / ボリューム：中 

現場で使える MySQL (DB Magazine SELECTION)

 実践ハイパフォーマンスMySQL 第3版

kindle版無し / １周 / 理解度：低 / ボリューム：特大

内定先のマネージャー曰く、この本が理解できれば10年間は食べていける高度で実用的な内容、とのことです。頑張ります。

実践ハイパフォーマンスMySQL 第3版

webセキュリティ

安全なウェブサイトの作り方

PDF無料 / ３周 / 理解度：高 / ボリューム：小

こちらと、もう一つ下の安全なSQLの呼び出し方は、IPA（独立行政法人 情報処理推進機構）が発行しているもので、以下のURLからPDFが無料でダウンロードできます。

かなり分かりやすくシンプルに説明してありました。

https://www.ipa.go.jp/files/000017316.pdf

安全なSQLの呼び出し方

PDF無料 / ２周 / 理解度：中 / ボリューム：小

https://www.ipa.go.jp/files/000017320.pdf

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版　脆弱性が生まれる原理と対策の実践

kindle版有り / １周 / 理解度：高  / ボリューム：大

「安全なWebアプリケーションの作り方」読了！

セキュリティの勉強は後回しにしがちだけど、大量の顧客情報を扱う実務では超重要。
（内定先からの受け売り② 笑）

かなり噛み砕いて対策方法まで解説してあり、分かりやすかったのでオススメですー！
僕は繰り返し読みます。https://t.co/tDeWB11FKs pic.twitter.com/0sRxfw7ZJr

— ゆうすけ@Railsエンジニア (@ysk_pro) 2018年6月27日

 

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版　脆弱性が生まれる原理と対策の実践

おわりに

いかがでしたでしょうか。

皆さんが読んだことがある本もあったのではないでしょうか。

なんとか１ヶ月で１３冊読みましたが、理解度は本によって様々でこれから時間をかけて繰り返し読んでいこうと思っています。

少なくとも身銭を切って大量の情報に触れたことで、知識の大幅な底上げになったと感じています。

プログラミング初学者の方には、「理解度：高」となっている書籍は僕でも理解することができてとても為になった本なのでオススメです！

個人的には、すぐには理解できなくても背伸びしてレベルの高い技術書にトライしていくことも大事だと思っています。

知識豊富で頼られるエンジニアに早くなれるように一緒に頑張りましょう！！

それぞれの技術書については、技術書タグをつけて適宜アウトプットしているのでこちらから是非ご覧ください！

ysk-pro.hatenablog.com

デザイン素人の僕が、Webサービスを最低限のデザインにするためにやったこと

こんにちは。ゆうすけです。

僕はプログラミングを始めて、初めて作ったwebサービスを使ってRailsの自社サービス開発エンジニアに転職することができたのですが、そのサービスのデザインを褒めていただけることが多く、どのようにデザインをしたのかをよく聞かれるのでまとめてみました。

人は見た目が9割と言うように、webサービスもぱっと見の見た目がとても重要なので、これから初めてwebサービスを作る方・今作っている方の参考になれば嬉しいです。

まず、僕が作ったサービスはこちらです。

www.jobmiru.com

サービスの詳細についてはこちらのブログ記事に書きましたので、ご興味ある方はご覧ください。

ysk-pro.hatenablog.com

以下、僕がやったことを書いていきます。

デザインテンプレートを使用した

当然ですが、ユーザーがアクセスして一番初めに見るトップページのデザインが最も重要です。

テンプレートを使えば、なんと一瞬でおしゃれなトップページに仕上がります。

僕がお世話になったのはこちらのサイトです。

Start Bootstrap - Free Bootstrap Themes and Templates

おしゃれなテンプレートを無料で使うことができます、、、スゴい。

こちらのサイトの「Agency」というデザインを使用しました。

以下実例です。

＜僕のサイト＞

＜使ったテンプレート＞

ほぼそのまんまじゃねえか、と突っ込んでいただけたと思います。

でもそれでいいんです。

テンプレートを使ったかどうかなんて、余程のテンプレートマニアでない限り分かりません（多分）。

実際にほぼそのまま使っている僕のデザインでも多くの方に褒めていただくことができました。

テンプレートの導入はとても簡単で、上記サイトからcssファイルをダウンロードできるので、そのcssファイルを自分のコードへコピペするだけです。

慣れれば10分くらいでできるはずです。

驚くべきコスパです！

フィードバックを出来る限り多くもらった

機能に関してもですが、デザインに関しても未完成の状態からフィードバックを可能な限り多くもらうことを重視しました。

一例ですが、デザインテンプレートを導入した当初のモバイル表示は以下の通りでした。

ここから複数の方に以下フィードバックをいただきました。

①背景の色が薄いので文字が見づらい。

②ボタン(2箇所)の黄色が強すぎる。

③ロゴ、メッセージのフォントが細い。

④画像の周りの隙間はいらない。

最終的にはこのようになりました。

 かなり良くなっていませんか…？

この他にも自分では気づけていない点に多く気づかせていただきとっても有意義でした。

僕の場合、Twitterでフィードバックをいただける方を呼びかけたところ20人近くの優しい方が応じてくださってフィードバックをいただくことができ、デザインを大幅に改善することができました。

Bootstrapのボタンを変えた

デザイン素人の味方 Bootstrapを使っている方も多いと思います。

もちろん僕も使っています。

僕の個人的な意見なのですが、Bootstrapはとっても便利でほんとに素晴らしいんですけど、ボタンのデザインがいまいちなんですよね、、、

先ほど添付したモバイル版の変更前のボタンがBootstrapなのですが、これを変えるだけでかなり印象が変わったと思います。

「ボタン css」と検索すると素晴らしいボタンデザインのcssがたくさんに出てくるので、そこから自分が気に入ったものを代わりに使うとデザインのレベルがグッと上がると思います。

アイコンを多く使った

アイコンというのはこのページでいう「🔍」「✔️」「🖤」「★」「💬」のことです。

アイコンがあるだけでそれっぽくならないですかね、、、？

「Font Awesome」を使えば簡単に導入できます。

おわりに

まとめると、僕が考えるwebサービスを最低限のデザインにするための最短ルートは以下の通りです。

デザインテンプレートを使って最低限のデザインを作る

→ 多くの方にフィードバックをもらって修正する

→ ボタンやアイコンなど細かい点を修正していく

僕はこの方法で作ったサービス（Jobmiru）を使って、プログラミング歴6ヶ月ながら自社サービスのRailsエンジニアになることができました。

その時の転職活動についてはこちらに書いています。

note.mu

冒頭にも書いた通り、デザインがある程度整っていれば、初めて作ったサービスでも「おおっ」と思わせることができるはずです。

もしフィードバックが必要な方は僕で良ければいつでも協力させていただきますのでお気軽に声をかけてください！皆さんの作ったサービスが見たいです！

デザインを恐れず、サービス作りを楽しみましょう！！

Ruby on Railsで雨が降る日の朝にメッセージで教えてくれるLINE bot「今日雨降るよちゃん」を作りました

こんにちは。ゆうすけです。

自分が欲しいな〜と思ったLINE botを作ったところ、半日でLINE API 無料枠上限のお友達50人と予想外の反響をいただいたので作った理由や人に使ってもらえるサービスとは何かについて考えたことなどを書いてみます。

（↑無料素材のアイコンですが、なかなかいい感じではないですか？笑） 

今日雨降るよちゃんとは？

機能としてはとってもシンプルで、東京で雨が降りそうな日の朝7時にLINEでメッセージが届く、というものです。

もう少し具体的に言うと、東京の時間別（6時〜12時、12時〜18時、18時〜24時）の降水確率が一つでも30%を超えていたら、友達追加した「今日雨降るよちゃん」から雨が降ることととその日の時間別の降水確率をメッセージで送ってくれます。

降水確率がいずれも30％未満の場合、メッセージは来ません。

メッセージはこんな感じで届きます。

（リリース翌日の今日実際に届いたメッセージです）

癒されるメッセージを26歳男性が一人で頑張って考えたのですが、癒されます、、かね、、、

メッセージは数パターン用意していて、更におまけ機能として「明日」や「かわいい」などのいくつかのキーワードに反応して返信してくれます。

ネーミングは、、、どうでしょうか、、、笑

画像は無料素材からお天気お姉さんにジャストフィットしたものがあったので利用させていただきました。

なぜ作ったか

毎朝傘を持っていくかどうか、天気のアプリをチェックするの面倒じゃないですか？

僕はとっても面倒でした。

特にTVを売ってからは、天気予報は自分で情報を取りにいくものに変わったので、TVの天気予報みたいに受動的に情報が得られたらいいのになー、と思っていました。

というのと今月初めにLINE botを初めて使ってサービスを作っており、LINE bot面白い！となっていたのでLINE botにお天気情報を通知してもらったらええやん！となり、作りました。

ちなみに今月初めに作ったサービスはこちらです。

ideatweet.herokuapp.com

アイデアツイートという、アイデアが湧いてくる２つのランダムなキーワードを返してくれるサービスです。 

最初の構想（思いつき）では、前日から気温が急激に変化した日（最低or最高気温が±5度）にもメッセージを送ることを考えていたのですが、シンプルな方がいいし気温情報は実際そんな必要ないかなーと思い直し、一旦は削ることにしました。

（お友達追加してくださった方で実際に使ってみて気温情報欲しい、など改善して欲しい点があればTwitterのリプライ、DM等で是非教えてください！）

作成期間

6/19に思いついて、6/20から作り始めて6/22にリリースしたので、3日くらいです。

上記アイデアツイート作成の経験からLINE bot作成のノウハウはあったので、天気情報をどうやって持ってくるかと、LINEのプッシュメッセージ（LINEから能動的にメッセージを送ること）のやり方を調べるだけだったので簡単にできました。

サービスをいくつか作っていくと、あのサービスのあの機能と、こっちのサービスのあの機能を組み合わせればいけるなー、という感じで作るスピードは加速度的に上がっていくと感じています。

技術面

LINE APIについて

LINE botを作る際は、LINEのMessagingAPIを利用します。

MessagingAPIにも2種類あり、利用者が送信したメッセージに反応してbotがメッセージを返すのが「Reply API」、利用者のアクション無しでbotが能動的にメッセージを送ることができるのが「Push API」があります。

今回のLINE botは毎朝7時に能動的にメッセージを発信する必要があったので、Push APIを利用しています。

（厳密には、返信機能も実装しているのでReply APIも利用しています）

Push APIを利用する必要があったので、料金プランは「Developer Trial」を利用しており、友達追加可能な人数制限が50人となってしまいました。。。

Push APIを利用して友達50人超にしようとすると「プロ(API)」プランにせざるを得ず、その場合月額32,400円となっています、、、高い、高すぎるよ。。。

逆に、Push APIを利用せずに、Reply APIの身を使う場合は、フリープランで友達追加の人数制限無しで利用することができます。

（アイデアツイートはReply APIのみの利用なのでフリープランにしています）

毎朝7時の実行について

今回サーバーはHerokuを利用しており、毎朝7時に実行する機能は、Herokuのアドオンである「Heroku Scheduler」を使用しています。

これを使えば、毎朝7時に実行、みたいなことが簡単に実現できます。

その他については、チュートリアルを書く予定なのでそちらに詳しく書こうと思います！

人に使ってもらえるサービスとは？

これまで4つサービスをリリースしてきましたが、リリースして半日で50人以上のユーザーがつくサービスは初めてでした。

当然と言えば当然なのですが、どれだけサービスを作り込んだかよりも、小さなことであってもユーザーの課題を解決することが一番大事なんだなー、ということが実感できたのでこのサービスを作ってよかったです。

おわりに

ここまで読んでくださりありがとうございました。

お友達数が制限の50人になってからも、お友達登録したかった、、、と言ってくれる方もいたので、イケメンの今日雨降るぜ君を作ることも考えたのですが、同じ機能のサービスを作っても面白くないので、誰でも「今日雨降るよちゃん」を作れるようなチュートリアルを書こうと思います。

少しのRailsの知識さえあればとっても簡単に作ることができると思うで、是非楽しみにしていてください^^

今日雨降るよちゃんではありませんが、今月初めに作った「アイデアツイート」のチュートリアルが本日書き終わったので、RailsでのLINE botの作り方を知りたい、もしくはRailsで簡単なサービスを作ってみたい、という方は是非こちらも読んでみてください。

note.mu

簡単に作ったサービスでしたが、思った以上の反響がありとても嬉しかったのでサービス作りモチベーションが上がってます！

使っていただいている皆さまありがとうございます。

まだまだ面白いサービス作ります！！

これからもよろしくお願いしますー！！

「プリンシプル オブ プログラミング」を読んで思ったこと、実践していくこと

1. はじめに

こんにちは。ゆうすけです。

実はRailsエンジニアとして7月から働くことが決まり（やったー！）、ブログのタイトルもちゃっかりRailsエンジニアに変えてます。

 

Railsエンジニアへの転職活動についてはこちらのnoteに詳細書きました。

note.mu

 

現在は1ヶ月の休職期間(!)を満喫するとともに、7月から働く会社のエンジニア兼マネージャーの方からいただいたおすすめの本リストに従って絶賛読書中です。

 

ただ読んだだけでは忘れてしまうので、ブログに「思ったこと、実践していくこと」としてアウトプットしていこうと思います。

 

アウトプットの仕方については何がベストか分からないので試行錯誤していきます。

 

第一弾は、「プリンシプル オブ プログラミング 3年目までに身につけたい一生役立つ101の原理原則」という本です。

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

タイトルからして、これからエンジニアになる今の僕にめっちゃ必要そうな本ですね〜。

 

2. 本の概要

プログラミングの原理原則という名前の通り、質の高いプログラミングをするための先人たちの経験・知恵を具体例を用いて分かりやすく解説してあります。

3. 思ったこと・実践していくこと

各項目についてまず自分が思ったこと、実践していくことを書き、四角の枠内に本からの引用を記載しています。

コードを書くときは「コードの読みやすさ」を最重要視する

SIerで働いていた時、既存コードの解読にめちゃくちゃ時間がかかっていました。

（とてもとても分かりにくくてストレスだった、、、）

 

今後コードを読む人たちの時間・ストレスを考慮すると、コードを書くのに多少時間がかかったとしても読みやすいコードを書くべき、という考え方はとても共感できるので早く身に付けます。

プログラミングにおける1つ1つの判断は、「そのコードが変更される」という前提で行うようにしましょう。つまり、「変更に強いコードを書く」ということです。 そして、そのためには「コードが読みやすい」ということが、もっとも大切です。結局コードというものは、書いている時間より、読んでいる時間の方が、はるかに長くなります。変更されるという前提に立つと、書くのにどれだけ時間がかかっても、読む時間を短縮できるなら、十分に元を取ることが可能です。

 

コードは必要最低限のものだけ書く

「あの機能追加するかもなー、一応このコード書いておこう」とコードを書いて結局使われずに放置、、、というのは僕も心当たりがあるので気をつけます。

コードは「たぶん必要になるだろう」「必要になるかもしれない」で書いてはいけません。本当に必要になった時、必要なものだけを書く、という方針で臨みます。 ソフトウェアの変化を完全に予測して、先回りしたコードを書くのは不可能です。そこは割り切って、今必要なコードだけを書くようにします。

 

変数やメソッド名の命名のチェック法

分かりやすい変数名・メソッド名はコードの分かりやすさに大きく影響します。

変数名・メソッド名を見ただけで何のための変数・メソッドか分かったらすごく楽ですよね。

今までは何となく分かりやすいかなー、くらいの感覚で命名していて、チェックはしていませんでしたが、今後はこの方法でチェックします。

命名について、「名前可逆性」という考え方があります。これは、「名前は、その元となった内容の説明文を復元できなければならない」という命名指針のことです。 この条件を満たすために、「ループバックチェック」を行います。内容の説明文から名前を考えたら、今度は逆に名前から推測できる説明文を考えるようにするのです。説明→名前→説明の順で、1周回って元に戻る（ループバックする）ように説明が一致すればよい名前で、一致しなければ要注意となります。

 

技術はきちんと理解してから使う

当然と言えば当然ですよね。

きちんと理解していないと仕事で聞かれた時に答えられませんもんね。

 

ググって一番上に出てきたやつをコードだけ見てコピペで動いたからとりあえずOKはやめます。。。

技術を学ぶ時は、動作原理や進化の過程、設計の背景にあるものも同時に知るようにします。これで照準が合い、目的が達成されやすくなります。 よいプログラマは、時間がかかっても、言語・ツール・技術・問題領域など、分野を問わず、きちんと理解してから作業に取りかかる傾向があります。特に、プログラミングにおいては、「よくわからないけど、動いたから、これでよし」「よくわからないけど、直ったから、これでよし」とすると、後から必ず品質的な問題が発生します。きちんと理由を説明できるまで、粘り強く理解してから、コードを確定するようにしましょう。

 

コード内のコメントは「そのコードを書いた理由」を書く

今までは何となく分かりにくいかな、と思ったところにコメントを書いていましたが、コードだけでは表現できない、このコードを書いた理由を書くようにします。

 

何をしているかについては、きちんとコード書いていればコードを読めば分かるので極力コメントには書きません。

コメントがなくても読めるような、わかりやすいコードを書くのが理想です。 ただし、コードはどこまで行っても「What」と「How」、つまり「何をしているか」「どのようにやっているか」までしか表現できません。「Why」、つまり「なぜそれをしているか」を表現するには、コメントを使用する必要があります。 コードという文書は、読む人とのコミュニケーションに使用するものです。コミュニケーションを円滑にするのに役立つなら、Whyだけにとどまらず、進んでコメントを手段として使用するべきです。コメントで説明しなくてもよい、わかりやすいコードを目指しつつ、それでも表現できない部分にはコメントを書く、というバランスを持ったコードを書くようにしましょう。

 

技術的負債も借金の利子のように雪だるま式に増えていってしまう

技術的負債の話は利子の例えがすごい分かりやすかったです。

（元銀行員だからですかね 笑）

 

利子が雪だるま式に増えていくように技術的負債も開発を続けると雪だるま式にどんどん増えてしまいます。

返済不能になる前に、お金も技術的負債も極力早く借金は返すべきです。

実務経験がない中で技術的負債は正直ピンとは来ませんがしっかり覚えておきます。

すぐに返済できなかった場合、「利子」が発生します。汚いコードがソフトウェアに残り続けると、問題が大きくなるのです。負債コードを読むには時間がかかります。そこに修正を加えるとなると、さらに汚いコードになり、ソフトウェアの動作も不安定になってきます。利子は複利となり、指数関数的に膨らんでいくのです。 そして、利子が膨らみすぎたり、多数の負債を許容することによって、負債を抱えすぎてしまった場合、返済不能に陥ります。つまり、「機能追加」も「保守」もできない、不安定でアンタッチャブルなコードと化してしまうのです。

 

人に優しく、コードに厳しく

自分が言われる時のために覚えておきます。

7月から入社して自分のコードをズタボロに言われるだろうけど、これはイケてないコードを恨んで言っているのであって、自分に言われてる訳ではない、はず…

「人に優しく、コードに厳しく」して、人ではなくコードを批評します。

 

人に聞く前にまずアヒルに説明してみる

わからないことを教えてもらうために、わからない点を説明してる時に「あ！ちょっと待って…！こうかも…なんか分かっちゃっいました、すみません」てのはよくあります。

 

人に聞く前にアヒルに説明してみることを習慣にしよう。

「説明する」というデバッグ 「ラバーダッキング」は、ある種のデバッグ手法です。 プログラミングにおいて、発生している問題や、問題を抱えているコードを「誰か」に説明します。すると、問題の原因に自ずから気付き、自己解決できることがあります。 この場合の「誰か」は、バスタブに置いたゴムのアヒル（ラバーダック）のように、話を聞きながら定期的にうなずくだけでよいのです。何かを言う必要はありません。 実際にやってみると、効果はてきめんです。場合によっては、説明し始めた途端に気付いて「あ、もういいや、変なところがわかったよ。ごめん、ごめん」ということになり、照れくさい思いをすることもあります。 「簡単で」「安い」のに、効果の高いデバッグ方法です。

 

解決が停滞した場合、「誰か」にそれを説明しましょう。 話しかける「誰か」は、それこそ「ゴムのアヒル」のように、無機物でも構いません。「説明する」という行為が重要です。 例えば、ある大学の情報系の学部では、ヘルプデスクのそばに「テディベアのぬいぐるみ」が常備されています。そして、不思議な障害に悩む学生は、人間のスタッフに相談する前に、ぬいぐるみに向かって説明しなければならないルールにして、一定の効果を上げています。

 

4. 余談（読書法について）

本についてのブログ一発目なので、僕の読書法についても紹介します。

 

僕は技術書、それ以外の書籍かに関わらず、「レバレッジリーディング」という方法で読書しています。

レバレッジ・リーディング

 この本は僕のバイブルです。

 

レバレッジリーディングとはこの本で紹介されている読書法で、

 

本の中で重要なこと（自分が覚えておくべきこと）はその本の中の一部であり、その一部をメモ（レバレッジメモ）に取り、そのメモを繰り返し読むことで本の内容を自分の中に落とし込むことができる

 

という読書法です。

 

大学生の頃はレバレッジメモを作るために、読書しながらメモをする箇所のページのかどを折り、該当箇所に線を引いて、読み終わった後にその箇所を全てワードへ入力していました。（結構面倒で大変でした）

 

しかし、kindleを購入してからそのプロセスがめちゃくちゃ楽になりました。

kindleでは本文を長押しすると好きな箇所に「マーカー」することができるのですが、そのマーカーした部分をwebサイトで見ることができるのです。

 

つまり、本を読んで、画面を長押ししてマーカーを引いていくだけでレバレッジメモが出来てしまうのです、、、！神！

 

しかも本体は驚くほど軽くてたくさんの本が入る！kindleすげー！

Kindle Paperwhite、電子書籍リーダー、Wi-Fi 、ブラック

kindleのおすすめ記事みたいになってしまいましたが、個人的にはkindleは神ツールだと思っているので、まだお持ちでない方は是非購入を検討すべきだと思っています。

 

5. おわりに

後半は話がそれてしまいましたが、初めて書いた本の感想記事をお読みいただきありがとうございました。

 

「プリンシプル オブ プログラミング」はプログラミングの原理原則を網羅的に学ぶことができ、自分の状況によって刺さる原理原則は違うと思うので、定期的に読み返そうと思っています。

読み返した時にこの記事を見て成長を実感できたら嬉しいな〜。

 

この記事では今の僕に刺さった箇所のみの、本のほんの一部を紹介しているに過ぎないので、他の原理原則も知りたいという方は是非読んでみてください！

 

1章1章は長くなくて飽きないので、僕は2日でサクッと読み終えることができました。

プログラミングの原理原則について網羅的に学びたいという方におすすめです。

プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則

読んだ本についてのブログが今回だけで終わってしまわないように頑張ります！

ご意見・ご感想等いただけるととても嬉しいです。

 

皆さんプログラミング学習頑張りましょう！！