【Rubyによるデザインパターンまとめ1】テンプレートメソッド / Template Method

「コードの品質向上」が現在の僕の課題で、マネージャーから「デザインパターンを勉強してみては」とアドバイスをいただいたので、デザインパターンの勉強を始めることにしました。

具体的には、Rubyでデザインパターンを解説した名著である Rubyによるデザインパターン で紹介されているデザインパターンを1つずつまとめていきます。（目標は毎週1つ）

この本で紹介されているサンプルコードをそのまま使うのは面白くないので、オリジナルのコードで説明していこうと思います。

そもそもデザインパターンとは

 一言で言うと、ソフトウェア設計の一般的な問題とその解決策をまとめたものです。

1995年に出版された「オブジェクト指向における再利用のためのデザインパターン」（4人の著者のことをギャング オブ フォーと呼び、GoF本と呼ばれています）によって、デザインパターンが広まりました。

GoF本では23のパターンに名前を付け、解説がされました。

デザインパターンを理解することで、設計についての車輪の再発明を防ぐとともに、エンジニア同士の共通言語となり、設計についてのディスカッションがスムーズに進めることができるようにもなります。

[デザインパターン①] Template Method パターンとは

基底クラスに骨格となる抽象的な処理を書き、サブクラスに具体的な処理を定義するパターンです。

アルゴリズムに多様性を持たせたい場合に便利なパターンで、不変となる部分は基底クラスに書き、変わる部分はサブクラスのメソッドに定義します。

Javaなどでサポートされている抽象メソッドや抽象クラスはRubyではサポートされていないので、呼び出した時に例外を投げるようにして擬似的に抽象メソッドを実装します。

文章で説明するよりも実際のコードで見た方が分かりやすいと思うので、以下のサンプルコードをご覧ください。

サンプルコード

僕は筋トレが好きなので、筋トレネタで書いてみます。

普通筋トレは、1日に全ての部位のトレーニングを行わず「胸の日」「肩の日」のようにその日鍛える部位を決めて、部位毎に集中してトレーニングを行います。

そこで、それぞれの部位の日に行うトレーニングを出力するプログラムを考えてみます。（便利）

まずは、Template Method パターンを使わずに書いてみます。

class MuscleTraning
  def execute(body_parts)
    case body_parts
    when 'chest'
      puts 'ベンチプレス！'
      puts 'チェストプレス！'
    when 'shoulder'
      puts 'ショルダープレス！'
      puts 'サイドレイズ！'
    else
      raise "#{body_parts}という部位のトレーニングはまだ知らないよ"
    end
    puts 'プロテイン摂取'
  end
end

このように実行できます。

MuscleTraning.new.execute('chest')

MuscleTraning.new.execute('shoulder')

実行結果は、それぞれこのようになります。

ベンチプレス！
チェストプレス！
プロテイン摂取

ショルダープレス！
サイドレイズ！
プロテイン摂取

やっていることがシンプルなので、このコードで分かりやすいのでは？と思ってしまうのですが、ここからさらに「腕の日」や「脚の日」が追加される場合や、腕の日にはプロテイン摂取を行わないという条件が追加された場合を考えてみましょう。

case 文の条件分岐が長くなり、可読性が下がり、修正時に既存のコードが壊れてしまうおそれなどが出てきてしまいます。

次に Template Method パターンを使って書き換えてみるとこのようにできます。

class MuscleTraning
  def execute
    main_training
    drink_protein
  end

  def main_training
    raise '抽象メソッド(main_training)が呼び出されてるよ'
  end

  def drink_protein
    puts 'プロテイン摂取' # デフォルトではプロテインを摂取するので、基底クラスに書いています
  end
end

class ChestTraining < MuscleTraning
  def main_training
    puts 'ベンチプレス！'
    puts 'チェストプレス！'
  end
end

class ShoulderTraining < MuscleTraning
  def main_training
    puts 'ショルダープレス！'
    puts 'サイドレイズ！'
  end
end

このように実行すると、先ほどと同じ実行結果となります。

ChestTraining.new.execute

ShoulderTraining.new.execute

先ほどと同様に、新しい部位が追加された場合や、特定の場合にプロテイン摂取をしないという変更が入った場合を考えてみましょう。

新たにサブクラスを作ったり、サブクラスで drink_protein メソッドを継承することで、既存の実装に影響を与えることなくシンプルに変更に対応できることが分かると思います。

さらに、1つ1つのメソッドが簡潔で可読性も高いと思います。

これが Template Method パターンです。

モジュールの extend を使ったパターン（2020/5追記）

上記の例では、継承を使って Template Method パターンを実現していましたが、モジュールの extend を使っても同じことが実現できると知ったので紹介します。

先ほどと同じ内容を、モジュールの extend を使って書き換えたコードはこちらです。

class MuscleTraning
  def execute
    stretch
    main_training
    protein
  end

  def stretch
    puts '全身のストレッチ'
  end

  def main_training
    raise '抽象メソッド(main_training)が呼び出されてるよ'
  end

  def protein
    puts 'プロテイン摂取'
  end
end

module ChestTraining
  def stretch
    puts '胸のストレッチ'
  end

  def main_training
    puts 'ベンチプレス！'
    puts 'チェストプレス！'
  end
end

module ShoulderTraining
  def main_training
    puts 'ショルダープレス！'
    puts 'サイドレイズ！'
  end
end

次のように実行すると、結果は先ほどと同じになります。

MuscleTraning.new.extend(ChestTraining).execute
MuscleTraning.new.extend(ShoulderTraining).execute

extend メソッド は引数で渡されたモジュールのインスタンスメソッドを、レシーバ（今回の例だと MuscleTraning.new）のメソッドとして追加します。また、戻り値はレシーバを返すので、この例のように execute を繋げて実行することができます。

あとはやっていることは先ほどと同じです。

Ruby は直接継承できるクラスが1つだけなので、複数のモジュールを extend したい場合にこちら方法が特に有効となります。

おわりに

ここまで読んでいただきありがとうございます。

ただの継承では と思われるかもしれませんが、これもデザインパターンの1つなのですね。「デザインパターン」というのはもっと複雑なものをイメージしていましたが、シンプルで非常に分かりやすかったです。

Rubyによるデザインパターン では、レポートをHTML形式やプレーンテキスト形式で出力するという現実的なサンプルコードを用いて説明されており、非常に分かりやすかったので、ご興味ある方は是非合わせてご覧ください。

（ただしこの本は絶版で、定価よりも高い値段で中古本が販売されている状況です...高かった...）

Rubyによるデザインパターン

次回は、ストラテジーパターンをまとめる予定です。

来週も頑張ります！

（追記）
ストラテジーパターンについてまとめました！
使い所はTemplateメソッドパターンと似ており、ストラテジーパターンは継承を用いずに実現しています。
是非合わせてご覧ください。
ysk-pro.hatenablog.com

AWSの資格(SAA-ソリューションアーキテクトアソシエイト)に合格するまでにやったこと・感想

こんにちは。

昨日、AWSの資格（SAA - ソリューションアーキテクト アソシエイト）に合格しました！嬉しい！

よっしゃAWSの資格（SAA - ソリューションアーキテクト アソシエイト）受かったーー！！

1回落ちて心折れかかった（1回1.6万円）けど粘って良かった...

個人的にはかなり難しかったけど、AWSの網羅的な知識がついて為になったなー

この参考書（https://t.co/Z8yE0gIlRc）が分かりやすかったです！

— ゆうすけ@Railsエンジニア (@ysk_pro) 2019年8月17日

2週間前に1度落ちてからの合格と、それなりに苦労したので、合格するまでにやったことや、この資格を勉強した感想などを書いておきます。

AWS SAA（ソリューションアーキテクトアソシエイト）資格とは

認定によって検証される能力

• AWS のテクノロジーを使用して安全で堅牢なアプリケーションを構築およびデプロイするための知識を効果的に証明すること
• 顧客の要件に基づき、アーキテクチャ設計原則に沿ってソリューションを定義できること
• プロジェクトのライフサイクルを通して、ベストプラクティスに基づく実装ガイダンスを組織に提供できること

（AWSの公式ページより抜粋）

AWSの資格は色々とあるのですが、SAAが一番幅広く学べそうな印象でした。

なぜ受けたのか

僕が勤めている会社のサービスでAWSを使っているのですが、仕事をしている中でSREチーム（インフラチーム） の話についていけず、まずいと思ったことがきっかけです...

SREチームの方に勉強方法を聞いたところ、このSAA資格のことを教えていただき、せっかくなので資格を取ることに決めました。

合格するまでにやったこと

参考書2冊

AWS認定資格試験テキスト　AWS認定 ソリューションアーキテクト-アソシエイト

この１冊で合格！　AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集

この2冊を使いました。

この2冊の選定理由としては、最近発売されたこと（AWSのサービスはどんどん変わるので、それに伴って試験問題も変わります）、模擬試験が含まれていること（この試験では過去問などが公開されていないので本番を想定した問題はかなり貴重です）です。

個人的には下の黄色い方がオススメです！（説明が分かりやすく、模試の問題数も多かった） 

Udemy

サービスを理解して使えるようにすることが真の目的だったので、実際に手を動かしながら学べるUdemyもやってみました。

主要なサービスについて、解説があった後に実際に触っていく形式です。

多くのサービスを実際に触るのでかなり時間はかかったものの、使用するイメージがつき、楽しく学べました。

僕が受講したのはこちらのコースです。

これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（初心者向け21時間完全コース）

Udemyで頻繁に行われているセール期間中には2,000円以下になるので、そこが狙い目です。

Amazon Black Belt セミナー資料

Black Belt というのはセミナーの名前で、AWSがネット上で公開している各サービスについての資料です。

これがかなり分かりやすく、AWS公式の説明資料なのでおすすめです。

ご参考として、EC2の資料を埋め込みます。

初心者向けにかなり丁寧に解説していることが分かると思います。

全てのサービスについての資料はこちらから見ることができます。 

上で紹介した黄色い方の参考書（この１冊で合格！　AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集）には、試験におけるサービス毎の重要度が3段階で書かれているのですが、 ☆☆☆のサービスは3回、☆☆のサービスは2回、☆のサービスは1回以上こちらの資料を読むようにしました。

SAA資格は過去問が無く、AWSが公式で出している問題も少ないので、AWSが公式で出しているBlack Beltセミナー資料は必ず目を通しておくべきだと思います。

ちなみに、1度目に資格試験に落ちた際には、こちらの資料に目を通していなかったことも敗因の1つだった気がします...

資格を勉強した感想

かなり苦労しましたが、勉強して良かった！と思っています。

資格取得のきっかけになった、SREチームの方が話していた内容もだいぶ分かるようになり、会社で自分が開発しているサービスの構成も分かるようになり面白いです。

AWSに苦手意識のある方、一度体系立てて勉強したい方にAWS SAAの資格取得はおすすめです。

この１冊で合格！　AWS認定ソリューションアーキテクト - アソシエイト テキスト&問題集

【読書まとめ24】王道SEO対策 実践講座

読書まとめの第24弾です。

今回は、成果を出し続けるための 王道SEO対策 実践講座 を読みました。

SEO対策の基本について解説している本で、会社のSEOに強い方に教えていただき読みました。

会社のサービスをはじめ、自分のサービスやブログにもすぐに実践できる内容だったので、忘れないように要点をまとめます。

すぐに読めると思うので、SEOの対策の基本について興味がある方は是非ご覧ください。

成果を出し続けるための 王道SEO対策 実践講座

SEO対策のポイント

• Webサイトの更新頻度は、SEO対策において重要な要素の一つとなる

• パンくずリストを利用することが、最適なリンク構成を実現するための最も単純で基本的な方法

• ドメインやURLは、一度決定したら対象ページが存在している限り変更しない

• alt属性は画像が表示されない場合にどのような画像を表示したかったかを利用者に伝える手段になるとともに、目の不自由な方が画像の内容を知るための手助けになるので、通常は見えなくても利用者にとって非常に重要な要素となる。適切に利用すればコンテンツの評価を上げる要素となる

• オリジナリティがコンテンツの価値になる。テンプレートや画像を提供するECサイトは、画像や価格が異なる程度で、ほとんど内容が同じページが量産されてしまうことがある。こうしたページが重複コンテンツと判断されたり、テキストの要素が少ない価値の低いコンテンツと判断されたりして、ペナルティを課される可能性もある。そのため、画像を撮影した際のデータや商品の仕様などをできるだけ記載して情報を増やしたり、コメント機能で利用者のコメントを集めたりして、それぞれのページが異なる内容を提供できるようにするべき

• アクションにつながるキーワードを含めるとその後の行動に結びつきやすい。具体的には、「SEO対策 相場」や「デジカメ 激安」などの購入したいという意思や、「デジカメ 修理」や「名刺 即日」などのすぐ必要という緊急性を含んでいるワードである

具体的な指針

• titleについて
• • 全角30文字以内
  • 対象ページで狙うすべてのキーワードを入れる
  • キーワードの重複は避ける
  • 意味区切りは「|」「-」「:」のどれかで区切る

• descriptionについて
• • 全角100文字以内
  • 対象ページで狙うすべてのキーワードを入れる
  • キーワードの重複は避ける
  • すべてのページでdescriptionが同じだとマイナス評価につながる

• キーワードを乱用すると、ペナルティの対象となることがある。具体的な利用の目安は以下の通り
• • 見出し：h1から順に利用し、h1が利用できるのはまとまりにつき1つ

• • strong要素：利用は1ページにつき数回程度で、同じ語句には使わない

• キーワードの出現率の参考値は以下の通り。無料ツールを使って調べることができる
• • 1番目に対策したいキーワード：適正出現率 5〜7%
  • 2番目：4〜5%
  • 3番目：3〜4%

ツール

• Search Consoleは、Googleの検索結果でのWebサイトのパフォーマンスを監視、管理できるサービス。WebサイトがGoogleにどのように認識されているか確認できるので、検索結果でのパフォーマンスを最適化するのに役立つ

• Webサイトの運営開始直後で、なかなかクローラが回って来ず、インデックス化までに時間がかかる場合は、Search ConsoleやBing WebマスターツールからURLを指定してクローラの巡回を催促することができる

• Search ConsoleでXMLサイトマップを登録すると、より早くWebサイトの更新情報を検索エンジンに伝えられるので、クローラが回ってくるまでの時間が短くなるとともに、抜け漏れなく情報を収集してもらえるようになる

• 内部リンクはWebサイト内に置ける相対的重要度の指標として利用されるので、強化したいページにリンクを集中させられていない場合は、設計通りの成果を出しづらい

• Search Consoleの「HTMLの改善」を利用することで、HTMLの不足要素や重複を一度にチェックできる

おわりに

ここまで読んでいただきありがとうございます。

特に、具体的な指針の項目は今日から使えるものばかりだったので、すぐに実践していこうと思います。 

この記事で紹介しきれないくらい、多くのSEOについてのことが解説されていたので、SEO対策について網羅的に理解したい方におすすめです。

成果を出し続けるための 王道SEO対策 実践講座

次はWebの速度改善についての本を読んでみようと思います。

AMP Conf 2019に行ってきました！印象に残ったセッションなどまとめ

4/17(水)、18(木)に、六本木ヒルズで行われたAMP Conf 2019に参加してきました！

参加する前は、AMPについてほとんど何も知らない状態だったのですが、2日間でAMPすげー！となったので、印象に残ったセッションなどについて書いてみます。

AMPについて知らなかった方、最近のAMPについて興味がある方の参考になれば嬉しいです。

AMPとは

AMP（Accelerated Mobile Pages）は、モバイルページを高速で表示させる技術で、2015/10にGoogleとTwitterのオープンソースプロジェクトとしてスタートしました。

スマホでGoogle検索した時に、こちらの画像のようにカミナリマーク（⚡️）がついているのがAMP対応ページで、クリックしてみると爆速で表示されるのが分かります。ほんとにビックリするくらい爆速です。

（こちらは「ラクマ スマブラ」と検索した結果で、1ページ目に表示されていました）

読み込めるJavaScriptや、CSSの容量に制限を設けることで読み込みにかかる時間を減らし、さらにGoogleがコンテンツをキャッシュしていることなどによって、このスピードを実現しています。

こちらのAMP Confのオープニング動画（4分くらい）が分かりやすく、そして面白くAMPについての概要を解説してくれているので是非ご覧ください。

youtu.be

（よくありがちな、会場への道中で色々説明していって、最後に本当に会場に登場するやつです 笑）

AMP Confとは

年に一回開催される、開発者の開発者による開発者のための AMP の技術祭典を、今年は東京で行います。（公式ページより） 

公式ページはこちらです（もちろんAMP対応しています）

2018年はオランダのアムステルダム、2017年はニューヨークで開催されており、懇親会で話を聞くと、このイベントのためにブラジルやカナダから来た人もいるような世界的なイベントです。

印象に残ったセッション

全てのセッションはYouTubeでこちらに公開されています（YouTubeの自動翻訳が使えるので英語が分からなくても安心！）

amp.dev live!

2人のGoogleのエンジニアが、30分でAMPページをライブコーディングするセッションです。

作ったAMPページの画像は以下で、次の機能を備えています。

• 下タブでコンテンツを切り替えられる機能
• 下スクロールでナビゲーションバーが隠れて、上スクロールで表示される機能
• ツイートを15秒ごとに自動で取得する機能
• 無限スクロール機能

AMPページは、用意されているコンポーネントを組み合わせて作ることが多いようです。このライブコーディングを通じて、実装のイメージが湧いたのでとても良かったです。

そしてGoogleのエンジニアかっこいいなぁ。

youtu.be

AMP Stories: The Story so far

AMPでこんな感じのストーリー機能が実装できます。おしゃれ！

また、検索結果にAMPストーリーを表示する専用の箇所を作ることを検討しているようなので、今のうちにAMPストーリーを作っておくといいかも。

 

簡単に綺麗なストーリーが作れるようなので、是非作ってみたい...！

youtu.be

AMP for Email: pushing the boundaries of email with AMP

Emailは基本的に、テキストかシンプルなhtmlで構成されていると思います。

しかし、AMP for Emailを使えばこのようにインタラクティブなコンテンツを提供することができます。

↓これが分かりやすいです（セッション動画を該当箇所から再生するようにしています）

Email上で申し込みや購入までできたりするの、とてもいいですよね。

現在はGmailのみが対応しているそうですが、今後他のメールクライアントでも対応予定だそうです。

このセクションの中では実際の実装方法も詳しく解説されており、通常のAMPページ同様にシンプルに実装できそうだったので、試してみようと思っています。

youtu.be

懇親会

1日目の夜にパーティーがあり、参加者やGoogleの方などとお話しすることができました。

DJがいて、ご飯も美味しくて楽しかったー。

寿司！！ 

おわりに

AMPについてほとんど何も知らない状態で参加しましたが、2日間を通じてAMPのファンになりました。

業務扱いで参加させてもらったので自社プロダクトのAMPページを改修するのはもちろん、個人で作るサービスでも使ってみようと思いました。

最初にも書きましたが、全セッションはYouTubeで公開されているので、気になった方は是非ご覧くださいー！

【技術書まとめ23】リーダブルコード

毎週１冊技術書を読んでブログでアウトプットすることが目標で今回が第23弾です。

今回は、リーダブルコード  を読みました。

もはや説明不要の名著ですが、良いコードを書くための原則を分かりやすく、そして簡潔に解説している本です。

200ページ程度でサクッと読めましたが、気づきがとても多かったです。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

1章 理解しやすいコード

• コードは「他の人が最短時間で理解できるように」書く

 

2章 名前に情報を詰め込む

• tmpなどの汎用的な名前が単なる怠慢で使われていることも多い。いい名前が思いつかなかったらfooのような意味のない名前を使いたくなってしまうが、少しでも時間を使って名前を考える習慣をつけるようになればすぐに命名力は高まる

• 抽象的な名前よりも具体的な名前を使う

• 単位やセキュリティなどの重要な属性を名前に追加するのも有効（例 ミリ秒を表す変数名には、後ろに _ms をつけるなど）

 

3章 誤解されない名前

• 誤解される可能性がある名前をつけない。「他の意味と間違えられることはないだろうか」と自問自答する

• 上下の限界値を決めるときは、max_ や min_ を前につけるとよい

• ブール値に名前をつけるときは、それがブール値だとわかるように is や has などを使う

 

4章 美しさ

• 複数のコードブロックで同じようなことをしていたら、ぱっと見て分かるようにシルエットも同じようなものにする

• コードを縦に揃えて楽に読めるようにする

 

5章 コメントすべきことを知る

• コメントの目的は、書き手の意図を読み手に伝えること

• コードからすぐにわかることをコメントに書かない

• コメントよりも自己文書化された適切な名前（関数名、変数名）をつけるべき

• 優れたコメントは、コードを書いた考え（なぜコードが他のやり方ではなくこうなっているのかなど）を記録するためのもの

• 定数を定義するときに、その定数が何をするのか、なぜその値を持っているかという背景をコメントするとわかりやすくなるケースが多い

• 読み手の立場になって考え、質問されそうなこと、ハマりそうな罠についてコメントする

 

6章 コメントは正確で簡素に

• 複数のものを指す可能性がある「それ」や「これ」などの代名詞を避ける

• 入出力の実例をコメントに書いておくことは千の言葉に等しい

 

7章 制御フローを読みやすくする

• ネストの深いコードは理解しにくい。ネストが深くなると、読み手は「精神的スタック」に条件をプッシュしなければならない

• 「失敗ケース」をできるだけ早めに関数から返すことで、ネストを削除できることが多い

• 比較を書くときには、変化する値を左に、より安定した値を右に配置する

• If/elseのブロックは適切に並び替える。一般的には、肯定系・単純・目立つものを先に処理する

 

8章 巨大な式を分割する

• 人間は一度に3〜4つの「もの」しか考えられないので、コードの式が大きくなれば、それだけ理解が難しくなる

• 大きな式の値を保持する説明変数を導入すれば、巨大な式を分割でき、コードを文書化することができる

 

9章 変数と読みやすさ

• 変数のスコープを縮めると読みやすくなる

• 変数が絶えず変更され続けると現在値の判断が難しくなりコードが理解しにくくなるので、変数は一度だけ書き込むようにするとよい

 

10章 無関係の下位問題を抽出する

• 以下のステップで無関係の下位問題を見つけて抽出する
• • 関数やコードブロックを見て「このコードの高レベルの問題は何か？」を自問する

• • コードの各行に対して「高レベルの目標に直接的に効果があるのか？あるいは、無関係の下位問題を解決しているのか？」を自問する

• • 無関係の下位問題を解決しているコードが相当量あるば、それらを抽出して別の関数にする

• 関数は、小さく独立したものになっていれば、機能追加・エッジケースの処理などが楽にでき、読みやすくなる

• プロジェクト固有のコードから汎用コードを分離する。ほとんどのコードは汎用化できる

 

11章 一度に1つのことを

• 一度に1つのタスクをするためには、まずコードが行なっているタスクを全て列挙し、タスクをできるだけ異なる関数に分割するとよい

• 最も大切なのは、プログラムが行なっていることを正確に説明すること

 

12章 コードに思いを込める

• 誰かに複雑な考えを伝えるときには、細かいことまで話しすぎると相手を混乱させてしまう。自分よりも知識が少ない人が理解できるような「簡単な言葉」で説明する能力が大切。これには、自分の考えを凝縮して、最も大切な概念にすることが必要となる。これは誰かに理解してもらうだけでなく、自分の考えをより明確にすることにもなる

• コードというのは、プログラムの動作を説明する最も大切な手段である。つまり、コードも簡単な言葉で書くべき。問題や設計をうまく説明できないのであれば、何かを見落としているか、詳細が明確になっていないということ。プログラム（あるいは自分の考え）を言葉にすることで明確な形になる

• 以下のステップでコードを明確にすることができる
• • コードの動作を簡単な言葉で同僚にもわかるように説明する

• • その説明の中で使っているキーワードやフレーズに注目する

• • その説明に合わせてコードを書く

 

13章 短いコードを書く

• 自分で書いたコードであれば、全ての行をテストして保守しなければいけない。ライブラリの利用や機能の削除をすることで、時間の節約をしたり、コードを簡潔に維持したりできる

• プロジェクトが成長しても、コードをできるだけ小さく軽量に維持するために、以下のことをすべき
• • 汎用的なユーティリティコードを作って、重複コードを削除する

• • 未使用のコードや無用の機能を削除する

• • プロジェクトをサブプロジェクトに分割する

 

14章 テストと読みやすさ

• 他のプログラマが安心してテストの追加や変更ができるように、テストコードは読みやすくするべき

• 一般的な設計原則として、大切ではない詳細はユーザから隠し、大切な詳細は目立つようにする

• テストの本質は「こういう状況と入力から、こういう振る舞いと出力を期待する」というレベルまで要約できる。そして、これらは1行でまとめられることが多い

• テストの入力値は、コードを完全にテストする最も単純な組み合わせを選択する

おわりに

ここまで読んでいただきありがとうございます。 

本書の中では、イラスト・実際のコードを使って解説しており、とても分かりやすくて読んでいて楽しい本だったのでオススメです。 

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

早いもので、もう4月ですね。

次は何を読もうかなー。

来週も頑張ります！

【技術書まとめ22】Effective Ruby

毎週１冊技術書を読んでブログでアウトプットすることが目標で今回が第22弾です。

今回は、Effective Ruby  を読みました。

Rubyの効果的なコードの書き方について詳細に解説している本です。

知らなかった書き方も多く、明日から即実務で使えるとても有意義な技術書でした。

Effective Ruby

第1章 Rubyに身体を慣らす

• Rubyでは、falseとnilを除くすべての値が真である。多くの言語とは異なり、Rubyでは数値ゼロは真となる

• falseとnilを区別しなければならないときは、nil?メソッドを使うか、falseを左被演算子とする”==”演算子を使う

• すべての変数がnilかもしれないという前提でコードを書くようにする。適切であれば、to_s、to_iなどの変換メソッドを使ってnilオブジェクトを強制的に型変換する

• 定数とは、先頭が大文字になっている識別子のことである。クラスやモジュールの名前も実際には定数である

• 定数は書き換えられないようにfreezeすべき。定数が配列やハッシュなどのコレクションオブジェクトは、コレクションとその要素それぞれをfreezeする

• コンパイル時に生成される警告は重要である。大多数は、Rubyが曖昧な構文を検出し、さまざまな解釈のなかから1つを選んで先に進んだときに生成される。Rubyの将来のバージョンが解釈方法を変え、プログラムの動作が突然変わってしまうことを避けるために、曖昧さは取り除いておくべき

 

第2章 クラス、オブジェクト、モジュール

• クラスは、メソッドと定数の入れ物である。メソッドはインスタンスメソッドと呼ばれ、そのクラスのインスタンスとなっているすべてのオブジェクトの振る舞いを表現する。しかし、クラスはそれ自体もオブジェクトなので、クラス変数という変数の入れ物でもあり、クラスメソッドを持っている

• Rubyは多重継承をサポートしていないが、includeメソッドでクラスにモジュールをミックスインすれば、多重継承と同じような効果が得られる

• Includeメソッドを使ってモジュールをミックスインした時、Rubyは水面下で特異クラスを作ってインクルードしたクラスの上の階層に挿入している。この無名で見えないクラスがモジュールにリンクされ、両者はインスタンスメソッドと定数を共有する

• Rubyは、メソッドを探すときに、最後にインクルードされたモジュールから順にたどっていく。最後の階層まで探しているメソッドが見つからなかったときには、method_missingを探してもう一周サーチを行う

• 継承階層の上位にあるメソッドをオーバーライドするときは、メソッド内でsuperを使ってオーバーライドされるメソッドを呼び出すことができる。引数もかっこも付けずにsuperを呼び出すと、呼び出し元のメソッドに渡されたすべての引数を渡してオーバーライドされるメソッドを呼び出すという意味になる。オーバーライドされるメソッドに引数を渡さずにsuperを使いたい場合は、super()のように空のかっこを使う必要がある

• Rubyは、サブクラスのオブジェクトを作るときに、スーパークラスのinitializeメソッドは自動的に呼び出さない。initializeにも通常のメソッドルックアップの規則が適用され、最初に見つかったバージョンが実行される。スーパークラスのinitializeメソッドを使いたいときはsuperを用いる

• セッターメソッドは、明示的にレシーバを指定しなければ呼び出せない。レシーバがなければ、変数への代入と解釈されてしまう。インスタンスメソッドからセッターメソッドを呼び出すときには、レシーバとしてselfを使う

• 新しいクラスを作るほどでもない構造化データを扱うときには、HashではなくStructを使うようにすべき。Struct::newの戻り値を定数に代入し、その定数をクラスのように扱う

• モジュール内に定義をネストして、名前空間を作れる。名前空間の構造は、ディレクトリ構造と同じにする

• トップレベル定数を修飾なしで使うと曖昧になるときには、”::”を使ってフルに修飾する（例 ::Array）

• equal?メソッドは、厳格にオブジェクトを比較し、両方が同じobject_idを持たない限りtrueを返さない

• 2つのオブジェクトが同じ値を表すかどうかをテストするときには”==“演算子を使う

• case式は、個々のwhen節をテストするために”===“演算子を使っている。左被演算子はwhenに与えられる引数、右被演算子はcaseに与えられる引数である

• オブジェクトの順序は、”<=>”演算子を定義し、Comparableモジュールをインクルードすれば実装できる。”<=>”演算子は、左被演算子が右被演算子と比較できないものはnilを返す。左被演算子の方が小さいときは-1、大きいときは1、等しいときは0を返す

• Rubyがprivateメソッドに加えている制限は1つだけで、privateメソッドは明示的なレシーバを指定して呼び出すことができないことである

• protectedメソッドは、関連するクラスの間でプライベートな情報を共有するために作られる。レシーバを明示してprotectedメソッドを呼び出せるのは、同じクラスのオブジェクトか共通のスーパークラスからprotectedメソッドを継承しているオブジェクトだけである

 

第3章 コレクション

• Rubyのメソッド引数は値渡しではなく参照渡しである。ただし、この規則には、Fixnumオブジェクトという例外がある

• 引数として渡されたコレクション（配列やハッシュ）は、書き換える前にdup、cloneメソッドでコピーをつくるべきである（ほとんどの場合dupの方が良い）。メソッドに引数として渡されたコレクションを書き換えてしまう誤りはよくある

• reduce（inject）は、関数型プログラミングの世界で畳み込みと呼ばれる関数で、あるデータを別のデータ構造に変換する、非常に強力な関数である

• 以下例の動作は、イテレーションのたびに、ブロックは現在のアキュムレータと現在の要素を受け取り、それらを加える。この和はブロックの戻り値になり、次のイテレーションのアキュムレータになる。このプロセスは、ブロックにすべての要素が渡されるまで繰り返され、reduceはアキュムレータの最終的な値を返す

  enum.reduce(0) do |accumulator, element|
    accumurlator + element
  end

• reduceに与えられる引数は、アキュムレータの初期値である。引数（初期値）を省略するとレシーバの先頭の要素をアキュムレータとして扱い、第2要素からイテレーションをスタートさせるが、レシーバが空の時nilを返す挙動となってしまうので、常に初期値は設定すべきである（初期値が設定されておりレシーバが空の時は初期値を返す挙動となる）

• reduceを使えば、よく使われるmap・selectなどを使うよりも効率の良いコードにできることがある。reduceのブロックは、新しいアキュムレータさえ返していれば、与えられたアキュムレータと要素に何でも自由に操作を加えられる

 

第4章 例外

• raiseの第1引数としてクラス名を指定できる。その場合、指定されたクラスの例外オブジェクトを作り、それを使って例外を生成する。クラス名を指定しない場合、RuntimeErrorクラスとなる。第2引数（オプション）はエラーメッセージとして使う文字列を渡すことができ、指定しない場合はクラス名となる

• 修復方法がわかっている特定の例外だけをrescueで捕まえるようにする。例外を捕まえるときは、もっとも限定されたタイプのものを最初に書く

• StandardErrorのような汎用例外クラスをrescue節で捕まえるのは避ける。操作を加えたいときは、ensure節で代用できないかを考える

• rescue節の中で例外を生成するときは、raise(e) のようにして元の例外をraiseする

• 例外が発生するかもしれないときは、確保したリソースを解放するためにensure節を使うとよい。ensure節は正常な条件でも例外条件でも実行される

 

第5章 メタプログラミング

• クラス、モジュール、個々のオブジェクトのふるまいなどをプログラムの実行中に変更できるメタプログラミングは、Rubyのもっとも強力な機能の1つであり、もっとも危険な機能の1つでもある

 

第6章 テスティング

• テストを書くときは、失敗するようなテストを書く。コードの重要な部分をコメントアウトし、その部分のテストが失敗するようにする

• バグの根本原因を探し始める前にそのバグのために失敗するテストを書く。バグフィックスの最初のステップはバグの再現であり、そのバグの専用のテストを用意すれば、フィックス後に再度バグが発生することを避けられる

 

第7章 ツールとライブラリ

• Bundlerは、gemの依存を自動的に管理し、開発中に使っているgemセットとまったく同じものを他のデベロッパーや本番サーバも使うようにしてくれる。必要なgemは、Gemfileで指定する。Bundlerは、指示を受けると必要なすべてのgemとそれらの依存関係をインストールする。また、依存全体を格納するGemfile.lockを作成、更新する

 

第8章 メモリ管理とパフォーマンス

• 実行中のRubyプログラムはオブジェクトから構成される。オブジェクトは無数にあり、たとえば、irbを新しく起動すると、10万個くらいのオブジェクトが作られ、ガベージコレクタが作動すると、アクティブオブジェクトの数は1万2千個くらいに削減される。Rubyにはガベージコレクタがあるので、マニュアルでメモリを管理する必要は無いが、ガベージコレクタが正しい処理をするためには実行中のプログラムを一時停止させなければならないので、パフォーマンスが少し下がってしまう

• パフォーマンスの低いコードを書き換えるときは、まずプロファイリングツールを使って状況を確認するべき

• ループ（eachブロックなど）内で使うオブジェクトが書き換えられないのであれば、オブジェクトリテラルを定数とすることで、メモリ確保の回数が減り、ガベージコレクタが起動するリスクを下げることができる

おわりに

ここまで読んでいただきありがとうございます。 

本書にはコードを用いた具体例が多くてとても分かりやすかったので、気になる方はぜひ本書をご覧ください。 

Effective Ruby

次は、リーダブルコード を読む予定です。

来週も頑張ります！ 

【技術書まとめ21】達人に学ぶ SQL徹底指南書

毎週１冊技術書を読んでブログでアウトプットすることが目標で今回が第21弾です。

今回は、達人に学ぶ SQL徹底指南書 を読みました。

SQLの正しい書き方・考え方について丁寧に解説している本です。

特にSQLのパフォーマンスチューニングのところは、すぐに仕事で実践できる具体的な内容で、それ以外のところも知らなかったことが多くとても勉強になったので、SQLに自信がない方は是非ご覧ください。

このまとめには概要だけを書くことでポイントを覚え、実際に使う際に本書の該当箇所にすぐたどり着けるようにしています。

達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ

第1部 魔法のSQL

CASE式のススメ

• CASE式を活用するとSQLでできることの幅がぐっと広がり、書き方もスマートになる

• CASE式には、単純CASE式と検索CASE式がある。検索CASE式の方ができることが多いので、検索CASE式を用いることが多い

• CASE式を使い、SELECT句で条件分岐させるとスッキリかけることがある

• CASE式は、明示的なELSE句がない場合、デフォルトでELSE NULLと見なすという仕様があるので注意が必要

• DECODE関数などと比べた時にCASE文の大きな利点は、式を評価できる点。つまり、CASE文の中でBETWEEN、LIKE、<、IN、EXISTSなどの便利な述語群を使用できる

• CASE式は実行時に評価されて1つの値に定まるので、列名や定数をかける場所には常に書くことができる

• CASE式を駆使することで複数のSQL文を1つにまとめられ、可読性もパフォーマンスも向上する

必ずわかるウィンドウ関数

• ウィンドウ関数のウィンドウとは、範囲という意味である

• ウィンドウ関数は移動平均を求める場合などによく利用される

• ウィンドウ関数は以下の操作を1つの関数に詰め込んでいる
• • PARTITION BY句によるレコード集合のカット
  • ORDER BY句によるレコードの順位付け
  • フレーム句によるカレントレコードを中心としたサブセットの定義

• SQLの内部動作を知るには、「実行計画(execution plan)」を調べればよい。実行計画とは、DBMSがSQL文を実行する際に、どのようなアクセス経路でデータを取得し、どのような計算を行うことが最も効率的かを判断するために作るものである

自己結合の使い方

• 同一のテーブルを対象に行う結合を自己結合(self join)と呼ぶ

• 自己結合は基本的に非等値結合と組み合わせて使われる

• 自己結合は異なるテーブルを結合していると考えると理解しやすい

3値論理とNULL

• 普通のプログラミング言語の真理値型（BOOLEAN型）とSQLの真理値型の違いは、普通の言語はtrue、falseという2つの値を持つのに対し、SQLはそれに加えてunknownという第三の値を持つことである。2つの真理値だけを持つ通常の論理体系が2値論理と呼ばれるのに対し、SQLの論理体系は3値論理と呼ばれて区別される

• NULLに比較述語（＝や > など）を適用した結果は常にunknownになってしまうのは、NULLが値でも変数でもないためである。NULLは、そこに値がないことを示すただの視覚的マーク、目印に過ぎないのに対し、比較述語を適用できるのは値だけなので、NULLに比較述語を適用してもunknownとなってしまう

• 3つの真理値の間には次のような優先順位があり、強い方が弱い方をのみ込む
• • ANDの場合：false > unknown > true（例：false AND unknown -> false）
  • ORの場合：true > unknown > false

• unknownが論理演算に紛れ込むと、SQLが直感に反する動作をしてしまう。これに対処するには、段階的なステップに分けてSQLの動作を追うことが有効

EXISTS述語の使い方

• EXISTSは、SQLにおいて量化を表現する重要な述語である。述語とは、戻り値が真理値（true、false、unknown）となる関数のこと

• EXISTS以外の述語（=や>など）は1行を入力とするのに対し、EXISTSは行の集合を入力とする

• 「全ての行について〜」という全称量化の表現を、「〜でない行が1つも存在しない」という二重否定分に変換し、NOT EXISTSを使う方法がよく使われる

HAVING句の力

• 現在の標準SQLでは、HAVING句を単独で使うことができる

• WHERE句が集合の要素の性質を調べる道具であるのに対し、HAVING句は集合自身の性質を調べる道具である

• SQLで検索条件を設定するときは、検索対象となる実体が集合なのか集合の要素なのかを見極めることが基本である
• • 実体1つにつき1行が対応している → 要素なのでWHERE句を使う
  • 実体1つにつき複数行が対応している → 集合なのでHAVING句を使う

ウィンドウ関数で行間比較を行う

• ウィンドウ関数を用いれば行間比較（異なる行の間で列同士を比較）することが簡単にできる。相関サブクエリでも同じことはできるが、パフォーマンス面、可読性の面でウィンドウ関数の方が優れている

• ウィンドウ関数は、サブクエリを使っているが、相関サブクエリではない。そのため、サブクエリ単体でも実行できるので、可読性が高く動作を理解しやすい。サブクエリ内部だけで実行することで、デバッグも容易に行うことができる

SQLで集合演算

• 集合演算子は重複排除のために暗黙のソートが発生するので、ALLオプションをつけるとソートが行われなくなりパフォーマンスが向上する。よって、重複を気にしなくていい場合、または重複が発生しないことが確実な場合はにはALLオプションをつけるとよい

• UNIONとINTERSECTは冪等性を持つ

SQLを速くするぞ

• SQLパフォーマンスチューニング
• • 効率の良い検索を利用する
  • • サブクエリを引数に取る場合、INよりもEXISTSや結合を使う

• • ソートを回避する
  • • ソートが発生する代表的な演算は次の通り
    • • GROUP BY句
      • ORDER BY句
      • 集約関数（SUM、COUNT、AVG、MAX、MIN）
      • DISTINCT
      • 集合演算子（UNION、INTERSECT、EXCEPT）
      • ウィンドウ関数（RANK、ROW_NUMBER等）

• • • ソートがメモリ上で行われてる間はまだいいが、それでは足りずにストレージを使ったソートが行われるとパフォーマンスが大きく低下する

• • • 集合演算子のALLオプションをうまく使う：重複を気にしなくてよい場合、重複が発生しないことが明らかな場合は、ソートが発生しないALLオプションをつけて使う

• • • DISTINCTをEXISTSで代用する：2つのテーブルを結合した結果を一意にするためにDISTINCTを使っているケースでは、EXISTSで代用することでソートを回避することができる

• • 極値関数（MAX/MIN）でインデックスを使う

• • WHERE句でかける条件はHAVING句には書かない：GROUP BY句による集約はソートなどを行うので事前に行数を絞り込んだ方がよく、うまくいけばWHERE句でインデックスが利用できるため

• • GROUP BY句とORDER BY句でインデックスを使う

• • インデックスが使われない書き方
  • • 索引列に加工を行なっている
    • インデックス列にNULLが存在する
    • 否定形を使っている
    • ORを使っている
    • 後方一致、または中間一致のLIKE述語を用いている
    • 暗黙の型変換を行なっている

• • 中間テーブルを減らす：中間テーブルの問題点は、データを展開するためにメモリを消費することや、元テーブルに存在したインデックスを使うのが難しくなることである
  • • 中間テーブルを使うのではなく、HAVING句を活用する
    • IN述語で複数のキーを利用する場合は、一箇所にまとめる
    • 集約よりも結合を先に行う

• • レコード数を絞れる条件は早い段階で記述する

• SQLにおいて、最大のボトルネックになるのはストレージへのアクセスである。ソートを減らすのも、インデックスを利用するのも、中間テーブルを省略するのも、すべてストレージへのアクセスを減らすことを目的にしている

• SQLの実行順序は、FROM → WHERE → GROUP BY → HAVING → SELECT （→ ORDER BY）である（ORDER BYは正確にはSQLの一部ではないのでカッコとしている）。複雑なSQLを書くときは、いきなりSELECT句から書くより、実行順序に沿ってFROM句から書いた方が自然にロジックを追える

 

第2部 リレーショナルデータベースの世界

• 2000年代に、RDBの欠点であるパフォーマンスのスケーラビリティや非構造化データの扱いといった問題がクローズアップされるようになり、それに対する解決策としてNoSQLが登場してきた

• NoSQLには明確な定義はなく、RDBとは異なるアーキテクチャやデータモデルに基づくデータベースという程度のゆるい定義である

• NoSQLの一つに、KVS（Key-Value Store）がある。KVSは、キーとそれによって一意に決まる値という非常にシンプルな構造しか持たない。Redisやmemcachedなどの製品がKVSの機能を備えている

• NoSQLには、ドキュメント指向型DBと呼ばれるタイプもある。JSONやXMLのような自由度の高いドキュメントを、RDBのテーブルに変換することなくネイティブに扱う機能を持つ。製品としては、MongoDB、CouchDBなどが該当する

• NULLについては、まず以下のようにデフォルト値を入れられないか検討し、どうしようもない場合のみNULLを許可するのがよい
• • フラグなどのコードの場合、未コード化用のコードを割り振る
  • 名前の場合、名前が不明用の値を決めて用いる
  • 数値の場合、0で代替する
  • 日付の場合、0000-01-01や9999-12-31のように最大値・最小値で代替する

 

おわりに

ここまで読んでいただきありがとうございます。 

具体例が多くとても分かりやすかったので、気になる方は是非本書をご覧ください。

達人に学ぶSQL徹底指南書 第2版 初級者で終わりたくないあなたへ

次は Effective Ruby を読む予定です。

来週も頑張ります！