銀行員からのRailsエンジニア

銀行員からのRailsエンジニア

銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。

当ブログではアフィリエイト広告を利用しています

メソッドの呼び出しエラーで学ぶRubyのインスタンスメソッド・クラスメソッド

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

業務で僕がハマったRubyのメソッドの呼び出しエラーについて丁寧に解説していきます。

この記事を読めばRubyのクラスメソッド・インスタンスメソッドについてざっくり理解できるようになると思います。

↓の例題をご覧になって、答えと理由を即答できなかった方は是非読んでみてください!

f:id:ysk_pro:20181028085539p:plain

1. 例題

こちらのコードの出力はどうなるでしょうか?

class A
  def self.b
    c
  end

  private

  def c
    p 'Yeah!'
  end 
end

A.b

① Yeah!
② エラーとなる

Twitterでアンケートをとってみた結果がコチラです。


 

2. 例題の答え

② エラーになる が正解です!

いかがでしたか?

Twitterアンケートでは正解者は半数以下となりました...!

3. 解説

この問題を理解するために、順を追って解説していきます。

3-1. メソッドのレシーバとは?

通常、メソッドは以下のように呼び出すと思います。

オブジェクト.メソッド名(引数1, ・・・)

このときの、オブジェクトをレシーバと呼びます。

メソッドを実行することをオブジェクトにメッセージを送る、という考え方をするので、メッセージを受け取るという意味からレシーバと呼ばれています。

3-2. インスタンスメソッド・クラスメソッドとは?

インスタンスをレシーバとするメソッドをインスタンスメソッドと呼びます。そのままですね。

同様に、クラスをレシーバとするメソッドをクラスメソッドと呼びます。

例えば、インスタンスを作るときによく使う

User.new

の .new はクラス(User)をレシーバとしているのでクラスメソッドです。

直接インスタンスを操作するわけではないけれども、そのクラスに関連する操作を行いたい場合に、よくクラスメソッドが用いられます。

3-3. インスタンスメソッド・クラスメソッドの定義の仕方

こちら↓のx がインスタンスメソッドです。よく見る形ですね。

class A
  def x
    c
  end
end

そしてこちら↓の y がインスタンスメソッドです。self. をつけるとクラスメソッドになります。

class A
  def self.y
    c
  end
end

クラスメソッドは↓の z のように定義することもでき、以下のように定義したメソッドは特異メソッドと呼ばれます。

class A
  class << self
    def z
      c
    end
  end
end

 

3-4. メソッド内で別のメソッドの呼び出す方法

メソッドの中では、そのメソッドのレシーバ自身を参照するのに self を用います

さらに、メソッドの中ではレシーバを省略してメソッドを呼び出す出すことができます

レシーバを省略してメソッドを呼び出すと、暗黙的に self がレシーバとなります

すなわち、インスタンスメソッドの中でレシーバを省略してメソッドを呼び出すと、呼び出されるのはインスタンスメソッドとなり、クラスメソッドの中でレシーバを省略してメソッドを呼び出すと、呼び出されるのはクラスメソッドとなります。

<プラス知識>
private というのは、メソッドをレシーバを指定して呼び出せないようにしています。
つまり、レシーバを省略した形式でしか呼び出せないために、インスタンスの外側から利用できなくなっているのです。

3-5. ここで問題を再度見てみると...

class A
  def self.b
    c
  end

  private

  def c
    p 'Yeah!'
  end 
end

A.b

① Yeah!
② エラーとなる

b メソッドはクラスメソッドだということがまず分かります。

よって、その b メソッドの中で呼び出している c メソッドのレシーバはAクラスとなるため、c という名前のクラスメソッドを探しにいきます

しかし、c という名前のクラスメソッドは存在しないため(存在するのはc という名前のインスタンスメソッドのみ)エラーとなるのです。


cメソッドをクラスメソッドにした、↓のコードであれば、出力は Yeah! となります。

class A
  def self.b
    c
  end

  def self.c
    p 'Yeah!'
  end 
  private_class_method :c
end

クラスメソッドをprivateにする方法は↑のコードの通りです。

4. おわりに

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

僕は業務でクラスメソッドからインスタンスメソッドが呼べずに1時間程ハマるまで、クラスメソッドとインスタンスメソッドの区分が曖昧になっていました。

この記事で皆さまの理解が少しでも深まると嬉しいです。

ちなみに、僕がこの件でハマった際は、↓の本の解説で解決することができました。
解説がとても丁寧で分かりやすいので、Rubyについて深く知りたい方にオススメです!

たのしいRuby 第5版

たのしいRuby 第5版

改めて読んで見ても、「ああ、そういうことだったのか」という気づきが多くて面白いですよー!

Enjoy Ruby!

【技術書まとめ12】達人プログラマー 〜毎週アウトプットチャレンジ〜

毎週1冊技術書を読んでブログでアウトプットすることを目標にしており、今回は第12弾です。

今回は、 達人プログラマー を読んでまとめました。

より良いプログラマーになるための実践的なアドバイスが多く含まれている名著なので、ご存知の方も多いと思います。

400ページ弱と割とボリュームはありますが、やはり名著であり学ぶことが多かったので定期的に読み返そうと思える技術書でした。

できる限りエッセンスはまとめたつもりなので、本書の内容にご興味ある方はこの記事を読めば概要は掴めると思います。

新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

 

f:id:ysk_pro:20181021135714p:plain

まえがき

  • 達人プログラマーになるためには、日々の意思決定、あるいは各開発における全ての意思決定に対して継続的かつ批判的な評価をする必要がある。絶え間なく考え続け、リアルタイムで自らの作業を批判的に見るべき
 

第1章 達人の哲学

  • 「壊れた窓」(つまり悪い設計、間違った意思決定、質の悪いコード)をそのままにしてはいけない。発見と同時に全てを修復するべきである。もし正しく修復するだけの十分な時間がないのであれば、その旨をわかりやすいところに明記しておく。チームやプロジェクトのコードが清潔で美しいものである場合、それを汚さないよう細心の注意を払うはずであり、それを維持することが重要
  • 毎年少なくとも一つの言語を学習する。言語が異なると、同じ問題でも違った解決方法が採用される。つまり、いくつかの異なったアプローチを学習することにより、幅広い思考が可能になる
  • 仕事における伝達のうちで最も難しいことは、自分の言いたいことを明確にすること。何が言いたのかを練り、次に概略を書く。そして、自分自身に対して「これで言いたいことの意味が伝わるだろうか?」と問いかける。その後、満足するまで磨きをかけていく
 

第2章 達人のアプローチ

  • 直交性とは、2つ以上のものの独立性、分離性を表している。片方を変更しても他方に影響を与えない場合、それらは直交しているという。コンポーネント互いに独立していると、他の部分を気にせずに変更することができる
  • 見積もりを尋ねられた場合、まずそれがどういった文脈における見積もりなのかを知る必要がある。正確な答えが必要なのか、もしくは大雑把な答えで構わないのかを理解する
 

第3章 基本的なツール

  • シェルに慣れ親しむことによって、生産性は向上する
  • バグについて、最初に与えられた情報よりも多くの情報を集めるには、バグを報告してきたユーザーにインタビューするのが早い場合もある
  • 問題の原因を探し出すための非常に簡単で効果的なテクニックとして、「誰かに説明する」という手法がある。他人に問題を説明するには、まずコードを精読し、その中に存在する暗黙の仮定を明確にしていかなければならない。いくつかの仮定を言葉で表していくことで、問題に対する新たな見識が突如としてひらめくことがある
 

第4章 妄想の達人

  • 達人プログラマーは自分自身も含めて信頼しない。自分も含めた誰もが完璧なコーディングを行うことができないという事実を知ることで、達人プログラマーのコードは彼ら自身の過ちに対しても防衛的になる
  • トラッシュ(メチャクチャ)にするのではなく、クラッシュ(停止)させる。通常の場合、障害を抱えて中途半端に動いているプログラムよりも死んだ(停止した)プログラムの方がダメージは少ない
 

第5章 柳に雪折れ無し

  • コードに柳の枝のような柔軟性を持たせることができれば、雪の重みという外界の変化に負けないようになる。柔軟性を保つ良い方法はコード量を減らすこと
  • 機能に対するデメテルの法則の目的は、任意のプログラムにおけるモジュール間の結合度を最小化しようというもの。これを実現するためには、直接関係のないメソッドへのアクセスを出来るだけ避けるようにすれば良い。エラー発生率はメソッドから直接起動されている機能の数に比例するという結果もある
  • データベースのスキーマ設計では、パフォーマンス向上のため、スキーマの非正規化、つまり処理速度を上げるために正規化ルールを破ることが一般的に行われており、モジュールを密接に関連付けていればパフォーマンスが向上する場合もある。このようなモジュール結合が適切であると判断できる場合は設計上の問題はないものの、コードは脆弱で柔軟性のないものとなってしまう
  • モデルからビューを分離すると、同じデータモデルを使って複数のビューをサポートできるようになり、柔軟性の高い設計となる
 

第6章 コーディング段階

  • 常に何をやっているのかを意識する
  • 完全に理解していないアプリケーションを作成しようとしたり、なじみのない技法を使おうとしない
  • 信頼の置けるものだけを前提とする。偶然や仮定に依存してはいけない
  • 仮定をドキュメント化する
  • 過去のしがらみにとらわれない。既存のコードによって未来のコードが影響されないようにする。陳腐化したコードがあれば、それが全部であっても書き換える
  • 理由の分からないものが動いているように見える場合、それが単なる偶然なのかどうかを確認する
  • リファクタリングを始める前に、しっかりしたテストが用意されていることを確認する。そして出来る限り頻繁にテストを行う
 

第7章 プロジェクトを始める前に

  • 要求ドキュメントを生成する際に最も注意しなければいけないことは、過度の記述をしてしまわないようにすること。良いドキュメントは、ビジネスにおける必要性を正確に反映していて、かつ簡素な記述である
  • 多くのプロジェクトの失敗原因として、スコープの増大がある。増加していく要求を管理するための鍵は、プロジェクトのスポンサーに対して、各新機能がスケジュールに与える影響を指摘していくこと
  • プロジェクトの用語集、つまりプロジェクト内で使用するすべての特殊な用語と語彙を1箇所にまとめて定義したものを作って、それを管理すべき。プロジェクトの参加者は、エンドユーザーからサポートスタッフに至るまで全て、この用語集を使うことによって整合性を保証できる
  • 問題が思っていたよりも難解であることに気がついた場合は、以下を自問する
    • もっと簡単な手段は存在するのか? 
    • 本当の問題を解決しようとしているのか、それとも末端の問題にとらわれているのか?
    • なぜそれが問題なのか?
    • 解決を難しくしている真の原因は何なのか?
    • この手段でやり遂げなければならないのか?
    • そもそも解決しなければならない問題なのか?
 

第8章 達人のプロジェクト

  • ブランドを確立するという手法でチームを一体化させることもできる。プロジェクトの立ち上げ時に、皆でそのプロジェクトに対して突飛な名前を付ける。これによってチームにアイデンティティーを与えるとともに、一丸となって仕事を行うための世界観も醸成できる。
  • 優れたプロジェクトでは成果物のコードよりも多くのテストコードが存在する。長期的な観点に立った場合、テストコードの生成に時間をかけたとしても、最終的にコストは低く抑えられるうえ、欠陥がほとんどない製品を生み出せる可能性も上がる
  • プロジェクトのテストは、何をテストするか、どのようにテストするか、いつテストするかという3つの観点で実施方法を考える必要がある
  • 一般的にソースコード中のコメントは「なぜ」それを行うかという目的やゴールを記述すべき既にコードが「どのように」それを行うかを表しているため、コメントでそれを記述するのは無駄なことであり、DRY原則に違反する行為となる
  • ソースコードへのコメントは、技術上のトレードオフ、意思決定の理由、却下された代替案といったような、プロジェクト資料のどこにも記述されない難解なポイントを記述するためのものである
  • 変数名には、意味のある名前をつけなければならない。コードを書くのは数回で済むが、コードを読むのは何百回にもなるためである
  • プロジェクトの成功というものは、ユーザーの期待にどの程度答えたかによって現実的に判断される。ユーザーの期待を下回ったプロジェクトは、どんなに素晴らしい成果物を構築したとしても失敗したと見なされる
  • ユーザーが言葉で表現しきれていない期待を、ユーザーと共に作業することによって、開発プロセスや最終成果物に関する理解として共有する必要がある

 

おわりに

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

「毎年少なくとも1つの言語を学習する」というアドバイスはとても有名ですよね。

さらに僕は、勤めている会社で面白いプロジェクト名をつけている理由が分かりました 笑

以前読んでまとめた、「プリンシプル オブ プログラミング」 にも、より良いプログラマーになるための示唆が多く含まれていたので、↓の記事も合わせて読むのがオススメです。

ysk-pro.hatenablog.com

新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

 

次は、UNIXという考え方 を読む予定です。

こちらもかなり有名な技術書なので読むのが楽しみです。

来週も頑張ります!

【技術書まとめ11】Webを支える技術 〜毎週アウトプットチャレンジ〜

毎週1冊技術書を読んでブログでアウトプットすることを目標にしており、今回は第11弾です。(↓ 歴史)

1. 「プリンシプル オブ プログラミング」を読んで思ったこと、実践していくこと
2. 【技術書メモ】パーフェクトRuby on Rails 〜毎週アウトプットチャレンジ①〜
3. 【技術書メモ】Everyday Rails - RSpecによるRailsテスト入門 〜毎週アウトプットチャレンジ②〜
4. 【技術書メモ】安全なウェブサイトの作り方・安全なSQLの呼び出し方 〜毎週アウトプットチャレンジ③〜
5. 【技術書メモ】体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 〜毎週アウトプットチャレンジ④〜
6. 【技術書メモ】なるほどUnixプロセス Rubyで学ぶUnixの基礎 〜毎週アウトプットチャレンジ⑤〜
7. 【技術書メモ】オブジェクト指向設計実践ガイド 〜毎週アウトプットチャレンジ⑥〜
8. 【技術書メモ】SQL 第2版 ゼロからはじめるデータベース操作 〜毎週アウトプットチャレンジ⑦〜
9. 【技術書メモ】現場で使えるMySQL 〜毎週アウトプットチャレンジ⑧〜
10. 【技術書】実践ハイパフォーマンスMySQL 第3版 〜毎週アウトプットチャレンジ⑨〜 

今回は、Webを支える技術 を読んでまとめました。

HTTPURIHTMLRESTなどのWebの基礎となる技術を解説している有名な本です。

エンジニアとして働くにあたってWebの基礎知識は必須であり、この本は勉強になることが多いので、通算4周読んでいます。 

Webの基礎知識の概要を掴みたい方この本に興味がある方の参考になれば嬉しいです。

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

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

 

f:id:ysk_pro:20181014084659p:plain

第1部 Web概論

第1章 Webとは何か

  • Webを支える最も基本的な技術は、HTTP(Hypertext Transfer Protocol)とURI(Uniform Resource Identifier)、HTML(Hypertext Markup Language)である
    • URIを使えば、世界中のあらゆる情報を指し示すことができる
    • HTMLはそれらの情報を表現する文書フォーマットである
    • HTTPというプロトコルを使って、それらの情報を取得したり発注したりできる
 

第3章 REST Webのアーキテクチャスタイル

  • RESTの重要な概念の一つにリソースがある
    • リソースとは、Web上に存在する情報である
    • リソースはURIで一意の名前を持つ
    • URIを用いることで、プログラムはリソースが表現する情報にアクセスできる
  • RESTとは次の6つを組み合わせたアーキテクチャスタイルである
    • クライアント/サーバユーザインタフェースと処理を分離する
    • ステートレスサーバ:サーバ側でアプリケーション状態を持たない
    • キャッシュ:クライアントとサーバの通信回数と量を減らす
    • 統一インターフェース:インターフェースを固定する
    • 階層化システム:システムを階層に分離する
    • コードオンデマンド:プログラムをクライアントにダウンロードして実行する
  • 個別のWebサービスやWebAPIがRESTfulになると、Webは全体としてより良くなる
 

第2部 URI

第4章 URIの仕様

  • URI(Uniform Resource Identifier)とは、リソースを統一的に識別するIDである
 

第5章 URIの設計

  • 変わらないURI(シンプルなURI)が最も良いURIである
 

第3部 HTTP

第6章 HTTPの基本

  • HTTPはRESTの重要な特徴である統一インターフェース、ステートレスサーバ、キャッシュなどを実現しているWebの基盤となるプロトコルである
  • HTTPはTCP/IPをベースにしている。TCP(Transmission Control Protcol)とIP(Internet Protocol)は、インターネットの基盤を構成する重要なネットワークプロトコルである
  • クライアントでは、1つのリクエストを送信してレスポンスを受信する際に次のことを行っている
    • リクエストメッセージの構築
    • リクエストメッセージの送信
    • (レスポンスが返るまで待機)
    • レスポンスメッセージの受信
    • レスポンスメッセージの解析
    • クライアントの目的を達成するために必要な処理
  • クライアントからリクエストを受けたサーバは次のことを行っている
    • (リクエストの待機)
    • リクエストメッセージの受信
    • リクエストメッセージの解析
    • 適切なアプリケーションプログラムへの処理の委譲
    • アプリケーションプログラムから結果を取得
    • レスポンスメッセージの構築
    • レスポンスメッセージの送信
 

第7章 HTTPメソッド

  • HTTPメソッドには、クライアントが行いたい処理をサーバに伝えるという役割があるが、メソッドは8つしか存在していない(内2つは利用頻度が高くないので割愛)
    • GET:指定したURIの情報を取得する、最も仕様頻度の高いメソッド
    • POST:GETに次いで利用頻度の高いメソッドで3つの役割がある
      • 子リソースの作成
      • 既存リソースへのデータの追加
      • 他のメソッドでは対応できない処理
    • PUT:リソースの内容の更新と、リソースの作成という機能がある
    • DELETE:リソースを削除する
    • HEAD:リソースのヘッダを取得する。GETはリソースを取得するが、HEADはリソースのヘッダだけを取得するという違いがある
    • OPTION:そのリソースがサポートしているHTTPメソッドの一覧を返す
  • リソースの作成についてのPOSTとPUTの使い分け
    • POST:クライアントはリソースのURIを指定できず、URIの決定権はサーバ側にある。よって、URIをサーバ側で決定するWebサービスの場合は、POSTを使うのが一般的である
    • PUT:リソースのURIはクライアントが決定する。よって、クライアントが決めたタイトルがそこままURIになるWebサービスの場合は、PUTを使うことが適切である
  • POSTでPUT/DELETEを代用することができる
 

第8章 ステータスコード

  • ステータスコード3桁の数字であり、先頭の数字によって次の5つに分類される
    • 1xx:処理中
    • 2xx:成功
    • 3xx:リダイレクト...レスポンスメッセージのLocationヘッダを見て新しいリソースへ接続する
    • 4xx:クライアントエラー...エラーの原因がクライアントのリクエストにある
    • 5xx:サーバエラー...エラーの原因がサーバ側にある
 

第9章 HTTPヘッダ

  • HTTP認証方式には、Basic認証とDigest認証がある
    • Basic認証:ユーザ名とパスワードによる認証方式。ユーザ名とパスワードをAuthorizationヘッダでリクエストごとに送信する。ユーザ名とパスワードが平文でネットワーク上を流れるため、HTTPS通信などの検討が必要となる
    • Digest認証Basic認証よりもセキュアな認証方式。Digestとはメッセージダイジェストの略で、あるメッセージに対してハッシュ関数を適用したハッシュ値のこと。クライアントはまず認証情報なしでリクエストを送信して、そのレスポンスの情報・ユーザ名・パスワードを使ってダイジェストを生成して、それをリクエストとして送信して送信する。サーバ上にハッシュ値のみを保管しておけば良いというメリットはあるが、毎回はじめに認証情報なしでリクエストを送信して、レスポンスを得なければいけないというデメリットもある
  • リソースがキャッシュ可能かどうか、その有効期限がいつまでなのかは、Pragma、Expires、Cache-Controlヘッダを用いてサーバが指定する
 

第4部 ハイパーメディアフォーマット

第10章 HTML

  • HTMLはハイパーメディアのため、テキストだけでなく画像や映像なども埋め込むことができる。歴史的経緯により、一般的に画像の埋め込みには<img>要素を、それ以外のオブジェクトの埋め込みには<object>要素を利用する
  • フォームはターゲットとなるURIを持ち、結果はそのURIに送られる。その時に用いるメソッドは<form>要素のmethod属性で指定し、GETまたはPOSTになる。GETの場合はターゲットURIとフォームへの入力結果からリンク先のURIを生成する。POSTの場合は、リクエストメッセージのボディにフォームの内容が入る
 

第11章 microformats

  • HTMLの中でさらに意味のあるデータを表現するための技術がmicroformatsである。microformatsを用いると、リンクの細かい意味やイベント情報などを表現できる
  • microformatsを用いると、既存のWebページをそのままWebAPIとして提供できる。必要最低限のコストでWebサービスをWebAPI化できるのがmicroformatsの最大の特徴である
 

第12章 Atom

  • Atomはブログなどの更新情報を配信するためのフィードとして知られているが、実際には幅広い分野で応用が可能な汎用XMLフォーマットである。様々なWebサービスのWebAPIとして利用することができる
 

第13章 Atom Publishing Protocol

  • AtomAtom Publishing Protocol(AtomPub)と組み合わせることで、リソースの表現だけでなくHTTPを活用した操作もできるようになる
 

第5部 Webサービスの設計

第15章 読み取り専用のWebサービスの設計

  • リソース設計とは、クライアントとサーバの間のインタフェースの設計、つまりWebサービスやWebAPIの外部設計である。どのようにリソースを分割し、URIで名前をつけ、相互にリンクを持たせるかが設計の勘所になる
  • リソース設計の指針として唯一存在しているのは、リソース指向アーキテクチャの設計アプローチで、次のステップからなる
    • Webサービスで提供するデータを特定する
    • ② データをリソースに分ける
    • (以下、各リソースに対して)
    • ③ リソースにURIで名前をつける
    • ④ クライアントに提供するリソースの表現を設計する
    • ⑤ リンクとフォームを利用してリソース同士を結びつける
    • ⑥ イベントの標準的なコースを検討する
    • ⑦ エラーについて検討する

 

おわりに

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

HTTP、URI、HTML、RESTなどについてまだ理解できてないなと思われる方は、この本を読んでみることをオススメします!

僕もエンジニアの先輩の方々に、よくこの本をオススメされていました。

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

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

 

次は、達人プログラマー を読む予定です。

こちらもよく話題になる本なので読むのが楽しみです。

来週も頑張ります!

 

【技術書】実践ハイパフォーマンスMySQL 第3版 〜毎週アウトプットチャレンジ⑨〜

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

今回は、実践ハイパフォーマンスMySQL 第3版 を読んでまとめました。

MySQLの詳細を解説している技術書で800ページありました...!

少し長いですが、今後実務でMySQLを使った時に、「あ!あの本に書いてあったことだ」とこの本に戻れるように、出来るだけ多くのキーワードに触れるように書いています。

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

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

 

f:id:ysk_pro:20181008083734j:plain

1章 MySQLアーキテクチャと歴史

  • MySQLアーキテクチャ3つのレイヤに分かれている
    • 1つ目のレイヤには、MySQL特有ではないものが含まれている。接続の処理、認証、セキュリティなど、ネットワークベースのほとんどのクライアント/サーバーツールで必要となるものである
    • 2つ目のレイヤはMySQLの中枢部とも言える部分であり、クエリ解析、分析、最適化、キャッシュ、および全ての組み込み関数(日付、時間、算術演算、暗号化など)のコードが含まれている。ストアドプロシージャ、トリガ、ビューなど、ストレージエンジン全体で提供される機能は全て、このレベルに属している
    • 3つ目のレイヤには、ストレージエンジンが含まれている。それらはMySQLの中に格納される全てのデータの保存と取得を受け持つ
  • MySQLはクエリを解析して内部構造(解析ツリー)を作成した後、様々な最適化を適用している。これには、クエリの書き換え、テーブルを読み取る順序の決定、使用するインデックスの選択などが含まれる。最適化の様々な側面についてサーバーに説明を求めることもできる。これにより、サーバーがどのような決断を下すのかが明らかとなり、クエリ、スキーマ、設定を見直すことができる
  • あるクライアントがデータを変更している間、別のクライアントがそのデータを読み取らないようにしなければならないので、ロックが絶え間なく発生する。MySQLのストレージエンジンは、独自のロックポリシーと粒度を実装できる
    • テーブルロック:最も基本的で最もオーバーヘッドが低い
    • 行ロック:並行性が最も高く、オーバーヘッドが最も高い
  • MySQLのトランザクショナルストレージエンジンのほとんどは、単純な行ロックメカニズムを使用しない。代わりに、行レベルのロックとMVCC(MultiVersion Concurrency Control)と呼ばれる並行性を高める手法を組み合わせて使用する
 

2章 MySQLベンチマーク

  • ベンチマークとは、システムにストレスをかけるように設計された作業のこと
  • ベンチマークは、負荷がかかっている時のシステムの振る舞いを観察し、システムのキャパシティを特定し、どの変更が重要であるかを学習し、様々なデータを使ってアプリケーションの性能を調べるのに役立つ
  • ベンチマークを開始する前に、「新しいインデックスは現在のものよりも上手く動作するか」のような質問を目標として設定する
  • ベンチマークシステムは既存システムを利用すべきで、独自に作成するべきではない
 

3章 サーバーのパフォーマンスのプロファイリング

  • パフォーマンスは応答時間で定義するのが最も効果的
  • 最適化する際は、応答時間に多くの時間が費やされている場所を計測することに90%以上の時間を割くべき
  • 計測はデータベースではなく、アプリケーションから開始するべき
  • 詳細な計測によって分析しきれないほど大量のデータが生成されるため、プロファイルが必要。プロファイルは、重要な情報を浮き彫りにし、どこから手を付ければよいかを判断するためのツールである
  • プロファイリングは、タスクと所要時間を計測する作業と、結果を集約してタスクを重要なものから並べていく作業の2つの手順に分かれている
  • New Relicは優れたプロファイリングツールである。Webブラウザからアプリケーションコード、データベース、その他の外部呼び出しまで、様々なユーザーエクスペリエンスを、実際の稼働環境でも診断することができる
  • スロークエリログは、クエリの実行時間を計測するための、最もオーバーヘッドが少なく、最も信頼できる方法である
  • スロークエリログからプロファイルを生成するのは、ログ分析ツールが必要である
  • 未知の問題が発生した場合は、大きく分けて2種類の原因がある。サーバーが処理に追われていてCPUサイクルを大量に消費している、もしくはリソースが解放されるのを待機していることが考えられる
 

4章 スキーマとデータ型の最適化

  • インデックスをつける列にはNULL値を格納できないようにするのがベター
  • TIMESTAMPとDATETIMEは似ているが、TIMESTAMPはDATETIMEよりもストレージ効率がよいため、TIMESTAMPを使用すべき
  • 正規化はよいことであるが、(ほとんどの場合はデータが重複する)非正規化が実際には必要で、役立つこともある
 

5章 インデックスによるパフォーマンスの向上

  • インデックスの最適化は、クエリのパフォーマンスを改善するための最も効果的な方法
  • ほとんどの場合、MySQLではB木インデックスを使用することになる。その他のインデックスは特殊な目的に適している
  • インデックスの利点
    • サーバーが調べなければならないデータの量が少なくなる
    • サーバー上でのソートや一時テーブルが不要になる
    • ランダムI/OがシーケンシャルI/Oに変わる
  • 値全体ではなく最初の数文字にインデックスを付けると、記憶域を節約し、パフォーマンスを改善できることがある
 

6章 クエリのパフォーマンスの最適化

  • クエリのパフォーマンスが不十分であるとしたら、最も基本的な理由は、クエリが操作するデータが多すぎることである。効率の悪いクエリのほとんどはアクセスするデータが少なくするように変更できる。以下手順で分析する
    • アプリケーションが必要以上に多くのデータを取得していないかどうかを確認する
    • MySQLサーバーが必要以上に多くの行を解析していないかどうか調べる
  • MySQLがクエリを実行するためのプロセス
    • クライアントがSQLステートメントをサーバーに送信する
    • サーバーがクエリキャッシュをチェックする。ヒットした場合は、キャッシュに格納されている結果を返す。ヒットしなかった場合は、SQLステートメントを次のステップに渡す
    • サーバーがSQLステートメントを解析し、前処理を行い、最適化して、クエリ実行プランを作成する
    • クエリ実行エンジンがストレージエンジンAPIを呼び出し、クエリ実行プランを実行する
    • サーバーが結果をクライアントに送信する
 

7章 MySQLの高度な機能

  • パーティションテーブルとは、複数の物理サブテーブルを1つの論理テーブルとして組み合わせたもの
  • ビューはデータを一切格納しない仮想テーブルであり、テーブル内のデータはビューへのアクセス時に実行されるSQLクエリによって生成される
  • トリガ、ストアドプロシージャ、ストアドファンクションという3つの形式でコードをサーバーに格納できる
  • クエリキャッシュは、完了したクエリからクライアントに返された正確なデータを保持する。クエリキャッシュでヒットした場合、サーバーはクエリキャッシュに格納されている結果をそのまま返せばよく、解析、最適化、実行の3つのステップを省略できる
 

8章 サーバー設定の最適化

  • サーバー設定ファイルを出発点として、サーバーとワークロードに合わせて基本オプションを設定し、安全性オプションと健全性オプションを適切に追加し、必要に応じてInnoDBプラグインを設定する
  • 何かがうまく行かなくなった場合、サーバーのプロファイリングに現れる
 

9章 オペレーティングシステムとハードウェアの最適化

  • MySQLサーバーのパフォーマンスは、システムの最も弱い部分によって決まってしまう。MySQLサーバーを実行するオペレーティングシステムとハードウェアがその制限因子となることが多い
  • MySQLには、CPU、メモリ、ディスク、ネットワークリソースの4つの基本リソースが必要である。ネットワークが深刻なボトルネックとなって表れることはまずないが、CPU、メモリ、ディスクがボトルネックになることはある
 

10章 レプリケーション

  • レプリケーションは、あるサーバーのデータを別のサーバーのデータと同期させることである。複数のレプリカが1つのマスターに接続し、マスターと同期することもできる。そして、レプリカがマスターの役割を兼ねることもできる
  • マスターのバイナリログに変更を記録し、そのログをレプリカで再生するという仕組みで動作するようになっており、非同期である
  • 一般に、レプリケーションはマスターのオーバーヘッドをそれほど増加させない
  • レプリケーションは、読み込みクエリを複数のサーバーに分散させるのに役立ち、読み取り主体のアプリケーションにうってつけであり、負荷分散できる
 

11章 MySQLのスケーリング

  • スケーラビリティとは、負荷の増加に対処するためにリソースを追加した時に、システムがその投資に見合うだけの価値をもたらす能力のこと
  • キャパシティとは、一定時間内に処理できる作業量を表す
  • スケーラビリティは、リソースを追加することによりキャパシティを増やす能力と言い換えることもできる
  • より高性能なサーバーを導入することは垂直スケーリング、またはスケールアップと呼ばれ、複数のコンピュータにわたって作業を分割することは水平スケーリング、またはスケールアウトと呼ばれる
  • データシャーディングは現在、非常に大きなMySQLをスケーリングするための最も一般的で優れた手法であり、データを小さく分割して、それらを別々のノードに格納する
  • 急速な成長が見込まれる一般的なアプリケーションのスケーラビリティ戦略は次のようになる。1台のサーバーから読み取りレプリカを使用するスケールアウトアーキテクチャにへ移行し、さらにシャーディングや機能分割を行う
 

12章 高可用性

  • 高可用性とはダウンタイムが少ないこと
  • 高可用性は2つの手法によって実現される
    • ダウンタイムの原因を回避すること。ダウンタイムの原因の多くは、適切な設定、監視、人為的エラーを防ぐためのポリシーや予防措置といった手段を通じて簡単に回避できる
    • ダウンタイムが発生したら、直ちにリカバリできるようにする。通常は、冗長性やフェイルオーバー機能をシステムに組み込むという方法がとられる
  • 高可用性のこれら2つの側面は、平均故障期間(MTBF)と平均修復時間(MTTR)の2つの数値として計測できる
 

13章 クラウドでのMySQL

  • クラウドでのMySQLの分類
    • IaaS(Infrastructure as a Service):クラウドで仮想サーバーリソースを購入し、そこにMySQLインスタンスをインストールして実行できる。MySQLとオペレーションシステムは自由に設定できるが、実際のハードウェアにはアクセスできず、それについて知ることはできない
    • DBasS(Database as a Service):MySQL自体がクラウドで管理されるリソースとなりわMySQLにアクセスするための資格情報がユーザーに提供される。MySQLの一部の設定は指定できるが、実際のオペレーティングシステムや仮想サーバーインスタンスにはアクセスできず、それについて知ることはできない
  • クラウドのメリットは、柔軟性や事前コストの削減、製品化までの工期短縮などがある
 

14章 アプリケーションレベルの最適化

  • 負荷の高いアプリケーションにとって、キャッシュはきわめて重要である。一般的なWebアプリケーションは、キャッシュするコストよりも生成するコストの方がはるかに高いコンテンツを大量に提供するため、通常はキャッシュを通じてパフォーマンスを桁違いに向上させることができる
  • キャッシュは、パッシブキャッシュとアクティブキャッシュの2つに分けられる。
    • パッシブキャッシュは何かをリクエストすると結果が返されるか、それは存在しないというメッセージが返される。memcachedはパッシブキャッシュの一例
    • アクティブキャッシュはリクエストをアプリケーションの他の部分に渡して、リクエストされた結果を生成し、その結果を格納してリクエスト元に返す
 

15章 バックアップとリカバリ

  • 論理バックアップには2種類がある
    • SQLダンプ:ダンプファイルには、テーブル構造とデータの両方が含まれており、全てが有効なSQLコマンドとして書き出される
    • 区切りファイル:区切りファイルは、SQLダンプファイルよりも小さく、バックアップと復元が速い
  • リカバリの方法はデータをバックアップした方法によって決まり、以下の手順の一部または全てを実行する必要がある
    • MySQLサーバーを停止する
    • サーバーの設定とファイルのパーミッションを書き留める
    • データをバックアップからMySQLのデータディレクトリへ移動する
    • 設定を変更する
    • ファイルのパーミッションを変更する
    • アクセスが制限された状態でサーバーをリブートし、完全に起動するまで待機する
    • 論理バックアップファイルを戻す
    • バイナリログを調べて再生する
    • 復元したものを検証する
    • 完全にアクセスできる状態でサーバーを再起動する

 

おわりに

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

MySQL、奥が深すぎますね、、! 

MySQLで困ったことがあった時は、この本を参照すれば間違いないと思います。

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

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

 

次は、Webを支える技術を読む予定です。

来週も頑張ります!

【転職後の振り返り】銀行からの転職を決意して1年経ったので、1年前と今を比べてみました

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

早いもので、銀行からの転職を決意してから1年が経ちました。

(2017/10に転職したい旨を上司に伝え、実際に退職したのは2018/1です。)

1年前は不安が大きかったのですが、振り返ってみるとこの1年で毎日がより楽しく、充実したものになっていたので、具体的に何が変わったのかを振り返る意味でブログにまとめてみます。

(こちらは誕生日に軽く振り返ったツイートです)

エンジニアへの転職を考えている方などの参考になれば嬉しいです。

f:id:ysk_pro:20181008080803j:plain

1. 時間

一言で言うと、自分・家族のために使える時間がめちゃくちゃ増えました。

転職して勤務時間は短くなり、不毛な飲み会がなくなり、勤務地近くに引越ししたことで、通勤時間が50分→15分となり、自由な時間が驚くほど増えました。

その時間は、スキルアップのために自分がしたい勉強や、健康のための筋トレ妻とゆっくり過ごす時間になっています。

 

2. 仕事のやりがい

Webサービスを作るという自分の好きなことを仕事にできたこと、仕事自体が自分のスキルアップに直結していることから、仕事へのやりがいがとても上がりました。

 

3. 働きやすさ

今の職場が、怒られない否定されないノルマはない、という銀行では考えられなかったような(笑)働きやすい環境に恵まれて、伸び伸びやらせていただいているため、とても働きやすいです。

 

4. 年収

金額自体は微減です。しかし、銀行時代に頻繁にあった不毛で高額(1回5~6千円...)な飲み会が無くなったことで使える金額自体はむしろ増えているのではないかと思います。

年収も銀行のような横並びの形態ではなく、実力に応じて決まってくるため、自分次第で大きく上昇する可能性もありモチベーションが高まりました。 

 

おわりに

いいことばかり書いてしまったので、悪いことも考えたのですが、一つも思いつきませんでした(笑)

自分の思っている以上にこの世の中にはたくさんの仕事・職場があり、転職自体も経験してみると意外と大したことはない、というのが転職してみて分かったので、あまり無責任なことは言えませんが、1年前の僕のように転職を悩んでいる方は一歩踏み出すことで世界は変わるんじゃないかなーと思っています。

僕が銀行を辞めて、ITエンジニアになった理由や、実際の転職活動については、詳細をこちらの2つのnoteにまとめていますので、ご興味あればご覧ください。

note.mu

note.mu

ここからの1年も、より楽しくワクワクできるように毎日チャレンジしていきます!

DIVE INTO CODEのDEMODAY(オリジナルwebサービスを発表するイベント)5thを見に行ってきました!

今年の4月に登壇者として参加したDEMODAYに、今回は見る側として参加してきました。

前回は登壇者目線でブログを書いたので、今回は観戦者目線で思ったことや、発表されたサービスについて書きました。

DIVE INTO CODEのDEMODAYってどんなイベント?という方や、DIVE INTO CODEに通った方は実際にどんなwebアプリケーションを作れるようになったの?という方の参考になれば嬉しいです。

f:id:ysk_pro:20181007192052j:plain

こちらはサービスプレゼン中の写真です。

熱気がすごい!

1. DEMODAYとは?

DEMODAYとは、僕が通っていたプログラミングスクール「DIVE INTO CODE」が主催する、スクール受講生が起業家、CTO、一般の方々の前で自分の作ったwebサービスをプレゼンし、その場で実際に使ってもらうイベントです。

第5回となる今回は、80名の方が来場し、渋谷ヒカリエのレバテックのおしゃれなオフィスで開催されました。

diveintocode.doorkeeper.jp

(こちら公式のイベント概要ページです)

 

2. 発表していただいた5つのサービスの紹介

僭越ながら、発表いただいたサービス5つ全てを紹介させていただきます。

2-1. Asuraku

https://asuraku.herokuapp.com/

f:id:ysk_pro:20181007194802p:plain

オンラインで運動の基礎が学べるサービスで、「筋トレ版Progate」と紹介していました。

f:id:ysk_pro:20181007195456p:plain

このように教材もしっかり作り込まれており、コンテンツが充実したら是非使ってみたいな、と思えるサービスでした。

このサービスのキモはコンテンツの質だと思ったので、どのように質を担保するのかを質問したところ、実際にトレーナーの方が作ることによって質を担保しているとのことでした。

〇〇版Progateのようなオンライン教材は、とても素晴らしい着眼点だと思いました。

 

2-2. KDN家電を買い叩け

https://buy-a-receipt.herokuapp.com/

f:id:ysk_pro:20181007194817p:plain

家電を買い叩くのが苦手な方のために、他の人が実際に買い物したレシートを共有して、それを使って家電を買い叩こうというサービスです。

JavaScriptを使って、画像アップロード時に隠したい情報を黒塗りすることができるなど、難しい技術も使って実装しており、会場からは技術的な質問も多かったです。

技術的にもう一歩踏み込んで文字認識機能があったら、とっても便利なサービスになりそうだな、と思いました。

 

2-3. Beaper

https://stormy-everglades-19869.herokuapp.com/

f:id:ysk_pro:20181007194834p:plain

助けを必要としている人と助けたい人を繋げるマッチングサービスです。

自身が怪我をしていた時の体験談からプレゼンが始まり、とても引き込まれました。

原体験から生み出されたサービスいいですよね。

高齢者がビーコン端末を押すと、近くのユーザーにLINE通知される、というシステムを実装していました。

イデアも素晴らしく、それを実際に形にされていて本当にすごいと思いました。

ビーコン端末の値段と高齢者にどのように普及させるかを質問したところ、端末は2,000円程度で、ボランティア団体を巻き込んで普及させていきたいとのことでした。

是非普及させて優しい世界を作っていって欲しいです。

こちらのサービスが審査員賞1つ最優秀賞を受賞しました。

 

2-4. にほんごきょうしのほしいもの。

https://nihongokyooshinohoshiimono.herokuapp.com/

f:id:ysk_pro:20181007194848p:plain

日本語教師教材用のリアルな日本語を集められたり日本語教育について相談できるサービスです。

作られた方が外国の方に日本語を教えている方で、自分が欲しいものを形にされていてすごいです。

既存で使いやすいサービスが無いという課題を当事者として持っており、実際に普及しそうだと思いました。

フォントも可愛くて素敵です。

こちらのサービスが審査員賞を2つ受賞しました。

 

2-5. ICHIOSHI

https://murmuring-gorge-36052.herokuapp.com/

f:id:ysk_pro:20181007194901p:plain

買って良かったものを投稿する実名制のレビューサイトです。

本当に良いものを人からのおすすめで見つけるというコンセプトに共感しました。

商品検索機能はあえて付けずに、商品との偶然の出会いも大切にしているという考え方も面白かったです。

f:id:ysk_pro:20181007201727p:plain

実際に使われているサービス顔負けのUIですよね。すごいです。

こちらのサービスが審査員賞を1つ受賞しました。

 

3. 観戦者として参加して思ったこと

サービス開発へのモチベーションアップ

自分の作ったサービスの素晴らしさ、世界観を真剣にプレゼンしている姿を見て、めちゃくちゃサービスが開発したくなりました

多分みんなそう感じてると思います。 

 

すごくいい機会・いいイベントだと思った

前回登壇した時も思いましたが、改めていいイベントだな、と思いました。

自分が作ったサービスを80人の前でプレゼンする機会なんてなかなか無いですよね。 

半年毎に開催されているので次回はおそらく来年の4月なのですが、次回是非また参加したいです、、!

 

4. おわりに

とってもいい成長機会になるので、DIVE INTO CODE受講生、卒業生の方は是非、チャレンジしてみてください!!

参考として、前回僕が登壇した時の記事はこちらです。

ysk-pro.hatenablog.com

DIVE INTO CODEを卒業した時に書いた記事がこちらなので、ご興味ある方はご覧ください。

ysk-pro.hatenablog.com

サービス開発楽しみましょう!!

 

 

 

エンジニアとして最近買ってよかったもの5選【2018年10月版】

個人的にこういうライフハックを読むのが好きで、いつか自分もやってみたいと思っていたので、ゆるく書いてみました!(短いのですぐ読めます)
エンジニアになって最近買ったものを5つ紹介しています。

f:id:ysk_pro:20181020082322p:plain

1. Amazon Echo Plus + Hueランプ(電球)

f:id:ysk_pro:20180930170431j:plain

ベッドの中からの「アレクサ、おやすみ」→ 消灯・就寝

というのは、小さなことですが一度経験してしまうと戻れなくなるくらい快適です。

音楽やニュースを聞くのにも使っており、手軽でいい感じです。

アレクサのスキルも開発できるらしいので、エンジニアとしていつかやってみたい、、!

 

2. ドラム式洗濯乾燥機

f:id:ysk_pro:20180930170519j:plain

これを買うまでは、洗濯物を干すこと天気予報を見ていつ干すか考えること急な雨で干してるものを心配することがストレスでしたが、買ってからはその全てから解放されました。

家を出る前にボタンを1つ押しておくだけで、帰ったら洗濯物がふわふわに仕上がっています。最高です。

時短は正義。

 

3. アーロンチェア(いい椅子)

f:id:ysk_pro:20180930173341j:plain

エンジニアはデスクワークなので、腰痛を未然に防ぐためにいい椅子は必須だと思っています。

新宿の大塚家具で色々な椅子の座り比べをしたのですが、アーロンチェアが圧倒的でした(値段も圧倒的でしたが...)。

背中の部分が位置にによって張りの強さを変えていることによって座りごごちが抜群で、前傾にもできてタイピングが楽で、12年保証が付いており品質も安心です。

座面がメッシュなのもお尻が蒸れなくて嬉しい、、!

【楽天】アーロンチェア リマスタード Bサイズ ポスチャーフィットSLグラファイト ハーマンミラー 送料無料

 

4. 電動昇降デスク

f:id:ysk_pro:20180930173401j:plain

全体像はアーロンチェアの項目の写真をご覧ください。

こちらの写真は高さを変えるボタンです。

職場が電動昇降デスクなのですが、立って仕事するのめっちゃいいです。

特に眠い時!笑

眠くない時もたまに立つことでメリハリがつき、運動不足解消にもなって気に入ったので家でも買っちゃいました 笑

電動なので高さを変えるのも楽々です。

【楽天】電動昇降デスク 送料無料 スタンディングデスク 幅120

 

5. 分離キーボード + Magic Trackpad

f:id:ysk_pro:20180930173731j:plain

こちらは僕の会社での開発環境です!

普通のキーボードをタイピングする姿勢って窮屈じゃないですか?

(手を中央に寄せるって結構不自然だと思う...)

分離式キーボードなら自然に両手を机に置いた姿勢でタイピングできて楽だなー、と思って買いました。

実際にすごく楽で、正しいタイピングも身につきました 笑

分離キーボードにはAppleのMagick Trackpadが相性抜群で、写真のようにキーボードの間に置いて使っています。 

Apple Magic Trackpad 2 MJ2R2J/A

Apple Magic Trackpad 2 MJ2R2J/A

 

 

おわりに

それなりに高いものってやっぱり価値ありますよねー。

ここに買いたものは買ってよかったし、もっと早く買っておけば良かった、、と思うものばかりです。

もっと生活を楽に・良くしたいので、是非みなさんの「買ってよかったものリスト」教えてください〜!

Enjoy Shopping!!