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

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

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

【技術書まとめ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:20180930224148j: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!!

【徳丸本勉強メモ】クッキー出力にまつわる脆弱性

はじめに

最近、会社で徳丸本(体系的に学ぶ 安全なWebアプリケーションの作り方 第2版)の勉強会が始まりました。

毎週持ち回りで発表していく形式で、僕の発表するパート(クッキー出力にまつわる脆弱性)についてまとめたので、ブログにも載せようと思います。

会社での勉強会の雰囲気などはこちらの記事をご覧ください。

www.wantedly.com

ちなみに、徳丸本というのはWebアプリケーションのセキュリティに関するめちゃくちゃ有名な本です。 

f:id:ysk_pro:20180924094455j:plain

サマリー

- Webアプリケーションではクッキーによるセッション管理が広く使われている

- クッキーにまつわる脆弱性

  ① クッキーを利用すべきでない目的でクッキーを使っている
  【対策】クッキーはセッションIDの保管場所として利用すべきで、それ以外のデータをクッキーに保存しない方が良い

  ② クッキーの出力時に脆弱性が発生する(クッキーのセキュア属性不備)
  【対策】HTTPS通信を用いるアプリケーションのクッキーにはセキュア属性を指定する

 

クッキーの不適切な利用について

Webアプリケーションで、ページをまたがる情報を保存する方法としては、セッション管理機構が用いられる。

一般的にセッション管理機構は、セッションIDのみをクッキーに保存して、データ自体はWebサーバーのメモリやファイル、データベースなどに保存している。

クッキーはアプリケーション利用者によって書き換えができるため、クッキーに保存すべきでないデータをクッキーに保存すると、脆弱性が発生する場合がある。

 

クッキーに保存すべきでない情報とは?

ユーザIDや権限情報

これらは書き換えられると困る情報である。

これらの情報をクッキーに保存していると、権限外の操作や情報閲覧ができてしまう場合がある。

クッキーに保存すべきでない情報以外であっても、一般的にクッキーにデータを保存しない方が良い

 

クッキーよりセッション変数を使うべき理由

セッション変数の方が便利で安全に使用できるため、通常はセッション変数を利用すべきである。

ただし、クッキーで実現できてセッション変数で実現できないのは、情報の寿命の制御と、異なるサーバーとの情報共有のみであり、これらが必要な場合はクッキーを利用する。

異なるサーバーでの情報共有のクッキーの使用例としては、ログイン画面の「ログイン画面を保持する」という機能がある。この機能はクッキーによりログイン状態が保持される。この時、クッキーに保存される情報はトークンという乱数で、IDやパスワードをクッキーに保存するわけではない。

クッキーにデータを保存する方法とセッション変数を使う方法の比較は下表の通り。

f:id:ysk_pro:20180924090256p:plain

(徳丸本 p.255 より抜粋)
 

クッキーのセキュア属性不備による脆弱性

クッキーにはSecureという属性があり、これを指定したクッキーはHTTPSの場合のみブラウザからサーバーに送信される

クッキーにはセッションIDなどセキュリティ上重要な情報が格納されている場合が多いので、クッキーが盗聴されると成りすましの被害に直結する

クッキーのセキュア属性不備への対策は、クッキーのセキュア属性を設定することである。

 

脆弱性が生まれる原因(クッキーにセキュア属性をつけない原因)

  • 開発者がセキュア属性について知らないケース
  • セキュア属性をつけるとアプリケーションが動かなくなるケース
  • HTTPとHTTPSが混在するWebアプリケーションの場合、セッションIDを保持するクッキーにセキュア属性を設定することは困難である。セッションIDのクッキーにセキュア属性をつけると、HTTPのページではセッションIDのクッキーが受け取れないため、セッション管理機構が使えなくなってしまう。サイト全体をHTTPSにするのが難しい場合、トークンを用いて対策する方法もある。
 

覚えておくべきこと

  • クッキーはセッションIDの保管場所として利用すべきで、それ以外のデータをクッキーに保存しない方が良い
  • HTTPS通信を用いるアプリケーションのクッキーにはセキュア属性を指定する

 

おわりに

この本は一度通して読んでいるのですが、勉強会で自分が発表するために読み直してまとめると、より理解が深まりました

会社で勉強会を行なっているように、実務ではセキュリティの知識は必須なので、セキュリティに関して自信が無いという方は是非こちら読んでみることをおすすめしますー! 

 

 

【元銀行員の僕が教える】銀行のちょっと面白くて、役に立つこと 〜信用創造・ペイオフ編〜

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

いきなりですが、実は僕、今はエンジニアをしていますが、新卒から4年間は銀行で中小企業から上場企業までを相手に、融資の提案などをしていました。

f:id:ysk_pro:20180915104907j:plain

1. この記事を書いたきっかけ

僕が今勤めている会社では、毎週金曜に、参加自由・発表自由・テーマ自由のゆるーいLT会があります。

みんな色んなテーマのことをLTしてて面白い、、!

 

そこで銀行に勤めていた経験から、「銀行について知ってたら面白いこと、役に立つこと」というテーマでLTしてみたら、みんなが興味示してくれたので、ブログにもしちゃおうかな〜と思いました。

シリーズ化も考えてますーー。

 

2つのことについて書いていきます。

 

2. 信用創造

f:id:ysk_pro:20180915090759p:plain

1つ目は信用創造についてです。

これは社会に対して銀行が担っている、重要な役割の中の1つです。

信用創造を一言で言えば、銀行がお金を貸せば貸すほど、世の中にお金が増えていく仕組み、となります。

ちょっと意味がわかりませんよね(笑)

次の図で解説しています。

f:id:ysk_pro:20180915090820p:plain

<図中の取引の説明>

① 銀行が100万円持っています

② 銀行はその100万円を会社Aに融資します

③ 会社Aはその100万円全額をすぐに使う予定はないので、90万円を銀行に預金します

④ 銀行はその90万円を会社Bに融資します

⑤ 会社Bも会社Aと同様に、全額をすぐに使う予定はないので、80万円を銀行に預金します

 

すると、、、会社A・会社B・銀行が使うことができるお金の合計は270万円(図中の赤字部分)になっています、、、!

銀行がお金を貸しただけで世の中のお金が増えましたよね。

ざっくりとですがこれが信用創造で、銀行が社会に果たしている重要な役割の1つなのです。

 

3. ペイオフ

f:id:ysk_pro:20180915090847p:plain

2つ目は知っておくと役立つことです。

最近、マイナス金利などで銀行の経営が危ないっていうニュース多いですよね〜。

銀行がもし、もし潰れてしまったら、預けている預金はどうなるんでしょうか、、、?

ちょっと心配ではないですか? 

 

f:id:ysk_pro:20180915090856p:plain

実は、銀行が潰れても、1人1銀行につき、元本1,000万円とその利息については、預金保険制度(ペイオフ)によって補償されます

なので、預金が1,000万円以上ある方は、銀行を分けて預金しておくとベターです。

 

 

ちなみに、信用創造の2枚目の図と、ペイオフの2枚目の図は、僕が夜な夜な資料を作っていたら、センスの無さに見かねて妻が綺麗にしてくれました。

めちゃ見やすい、、、すごい。

 

4. おわりに

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

当たり前のことばかりですか??

僕は信用創造を初めて知った時は、おおー、面白い、銀行すごいな〜と思いました。

 

そんな僕が銀行を辞めた理由・ITエンジニアになった理由についてはこちらのnoteに詳細を書き、多くの反響をいただいておりますので、もしよろしければ合わせて読んでみてください!

note.mu

お読みいただきありがとうございました。

次回は何を書こうかな〜〜