今月の技術トピックス 株式会社フォアフロンティア 2013/06　帰社日.

Presentation on theme: "今月の技術トピックス 株式会社フォアフロンティア 2013/06　帰社日."— Presentation transcript:

1 今月の技術トピックス 株式会社フォアフロンティア 2013/06　帰社日

2 1. 今月の技術トピックス 今月のトピックスは以下の通り 先月のおさらい HTTP概要 パスワードについて リリース関連

3 1-1. 先月のおさらい そもそも何故？先月説明した内容を再度おさらいする必要があるのか？

4 1-1. 先月のおさらい そもそも何故？先月説明した内容を再度おさらいする必要があるのか？ →皆さんが伸びる人かを試しています。
伸びる人はチャンスを無駄にしません。 →伸びない人はチャンスに気がつかない →更に自分にチャンスが巡ってきていないと被害者意識（勘違い

5 1-2-1. 目の前のチャンス 例えば以下の様なチャンスがあります 人から指摘されたとき つまらない作業を繰り返しやっている時
人から知らないことを聞いたとき

6 人からの指摘 仕事をしていると間違いを指摘されることがあります。 では、皆さんは間違いを指摘されたときどのように感じますか？

7 1-2-2. 人からの指摘 【成長する人】 指摘箇所を自分なりに理解しようと調べる →自分なりに理解することが重要
→これが無い人はソースコピーマンです！ 何故、指摘を受けたか問題点を検証する →同じ失敗を繰り返さないマインドが重要 →原因を追究しない人は類似ミスを繰り返す（仕事ができない烙印を押されます）

8 1-2-2. 人からの指摘 【成長しない人】 最初に言い訳から始まる 指摘に対してイライラするした顔をする
指摘されたことを言われた通りにする →それぞれ何故悪い？

9 1-2-2. 人からの指摘 【成長しない人】 最初に言い訳から始まる →指摘意図を理解できてない（無駄な自己保身）
→自分の能力がわかっていない証拠 指摘に対してイライラするした顔をする →指摘者から不愉快に思われ相手にされない 指摘されたことを言われた通りにする →自力解決能力が身につかない

10 1-2-3. つまらない作業 毎回、雑用みたいな仕事が回ってくるのは何故だかわかりますか？ ほとんどの人が環境が悪いと勘違い
自分が悪いんですけど知ってましたか？

11 1-2-3. つまらない作業 【成長する人】 何故、自分はこの作業なのかを分析する
→スキルがつきそうな仕事をしている人との差を考え、自分の弱点を改善する やりたい作業をやっている人より優れている点を作り出す →自分の担当分だけでなく、全体を把握して違いを生み出そうとする

12 1-2-3. つまらない作業 【成長しない人】 ただ、言われたことだけを実施する 「あーつまらない」と文句をいって、自分は改善しない
→何故駄目？

13 1-2-3. つまらない作業 【成長しない人】 ただ、言われたことだけを実施する
→しかも、指示以下のことしかできない指示待ち人間（数合わせ） 「あーつまらない」と文句をいって、自分は改善しない →能力をアピールしないで、実力があると息巻いている悲しい人間（口だけ・・・）

14 1-2-4. 知らないことを聞いたとき これは成長スピードに大きく影響します ほとんどの人がこのチャンスを無駄にしている
折角、最新技術をできるチャンスをみすみす逃しているんですけど・・・

15 1-2-4. 知らないことを聞いたとき 【成長する人】 メモを残し、後で自分なりに調べる
→新しいことを聞いて頭で暗記できるわけ無いのでメモは必須。 →その後、すぐに調べないと一生調べない わからない点を執拗に質問してくる →自分で理解しようとしないと聞いているだけ無駄 最終的に自分で知識を得るための方法を探ってくる →指示待ち人間には無い発想 →最終的に自力で調べられない=指示待ち人間

16 1-2-4. 知らないことを聞いたとき 【成長しない人】 聞いただけ・・・（1ヶ月以内に忘れる） →聞いている時間の無駄
→聞いているだけの人は現場でも事前準備の概念が無い →忙しくなってきてから時間が無いからと調べないイタイ人 →このタイプはスケジュールが守れない

17 1-3-1. JBoss では、先月説明した話をしましょう！！ 無料版は名称が変わりましたよね？
→もちろん、Java技術者が気になる無いようですよね →聞いているだけだと出てこないでしょう

18 1-3-2. JBoss 無料版は名称が変わりましたよね？ そうです。「WildFly」です
JavaEE7が実装されているようです。

19 2-1-1. HTTP概要 【概要】 HTTPとはブラウザ等でWebサイトを閲覧する際に送受信に使用している通信プロトコル
通信している中身は以下の通り 状態（「リクエスト／レスポンス行」）、1行目 ヘッダー行 ボディ部 では質問、HTTP（アプリケーション層）で使用しているトランスポート層は何？ →以前の帰社日でやっているので大丈夫！！

20 2-1-2. HTTP概要 そう、「TCP」ですね！ さすがにわかりますよね。わからない人は結構レベル低いので注意が必要・・・
では、「TCP」の他に有名な「UDP」がありますが「TCP」と「UDP」の違いは？

21 2-1-3. HTTP概要 HTTPで通信されるデータはパケット型と呼ばれる通信方式であり、そのパケットが正しく到達する保障がありません。
TCPは正しく到達する保障をする役割を持っています →トレードオフとしてチェックする時間分遅い 逆にUDPは保障が無い変わりに短時間で多くのパケット通信が可能 →ストリーミング配信などに使われる

22 2-1-4. HTTP概要 状態（1行目）について確認していきましょう リクエストでは以下の内容 「メソッド」、「URI」、「プロトコル」
レスポンスでは以下の内容 「プロトコル」「ステータスコード」「メッセージ」 では、ここでいっている「メソッド」とは？ 同じく「プロトコル」って何が指定してある？

23 2-1-5. HTTP概要 以下に例を示します 【リクエスト】 GET /hyuga.html HTTP/1.1 【レスポンス】
HTTP/ OK ではメソッド（例ではGET）をJavaEEで実装するに当たり、HTTPServletクラスではどうする？

24 2-2-1. HTTP概要 もちろん、「doGet」メソッドです 他にも「doPost」、「doHead」など
→メソッド「POST」、「HEAD」などに対応 このことから、HTTPを理解していないとJavaEEが理解できないことがわかりますね！ では、「POST」と「GET」の違いは？ →電文で異なる部分を教えてください

25 2-2-2. HTTP概要 【GET】 GETの場合、入力パラメータが1行目のURIに含まれる 【POST】

26 2-3-1. HTTP概要 GETを使用すると入力したパラメータがURIに含まれるため、以下の問題が発生する
Webサーバログにパラメータが残ってしまう リファラーにパラメータが残ってしまう なぜリファラーにパラメータが残ってしまうと問題なの？ また、リファラーはどうやってWebサーバは取得することができているの？

27 2-3-2. HTTP概要 例えば、サイトAにアクセスした際に重要な情報（パスワードなど）がURIに含まれているとします
次にサイトBへアクセスするとサイトAの重要な情報がリファラーから取得できます →掲示板などでよくあるパターン リファラーはリクエストヘッダ「Referer」から取得できます

28 HTTP概要 では、次に現在主流である「HTTP1.1」だと思いますが「HTTP1.0」との違いは？

29 2-4-2. HTTP概要 では、次に現在主流である「HTTP1.1」だと思いますが「HTTP1.0」との違いは？
一番の違いは「Keep-Alive」です！ Keep-Aliveが使えることにより無駄なコネクションを生成しなくても済むようになりました また、同時接続数という概念もポイントです →サーバにリクエストで同時にデータのやり取りを行える最大接続数

30 HTTP概要 これでHTTP概要については終わりますが、Webシステム開発をやっているのに答えられない人がいたら何故でしょうか？ →いない事を祈ってますが・・・ 【参考】

31 2-5-2. HTTP概要 ソースの意味を理解しないで動くからいいやと思ってしまっている可能性が高い
→HTTPの仕組みが理解できていないとJavaEEは理解できないので そういう感じで仕事を進めて行くと「自力で解決できない残念なお荷物」となってしまいます ではどうすればいいですか？

32 2-5-3. HTTP概要 以下の点に気をつけて仕事をしましょう ソースでわからない箇所があれば理解するまで調べる
ソースコピーをやめよう（時間の無駄） 常にソースに疑問を感じましょう 同じミスをしないようにミスしたら自分のどこに問題があり、どうすればミスしなかったかを常に考えましょう

33 3-1. パスワードについて BtoB向けシステムなどではログイン機能がほとんどついていると思います。
大体は「アカウント」、「パスワード」による認証だと思います ただし、パスワードをプレーン状態でDBへ保持することはありません では、どのように保持していますか？また、どうしてその方法が有効なのでしょうか？

34 3-2. ハッシュコード 一般的に使われているのがパスワードをハッシュ化して保持する方法です。
この方法を用いるとハッシュコードにされる前の情報がわからないため、安全といわれています。 しかし、ただハッシュ化するだけでは脆弱といわれています。何故？

35 3-3. レインボーテーブル 簡単に言うとハッシュ化されたデータを逆引きできる表です。 →ということはハッシュは安全ではない ではどうする？
ちなみにハッシュ方式（MD5等）は関係ない →SHA-256でもレインボーテーブルにかかれば一緒

36 3-4-1. ソルト ハッシュ化する値の前後に特定の値を付与する 【例】hash($password . $solt);
ソルトの条件としては以下の通り ユーザごとに異なるソルト ある一定の長さ（20文字以上）

37 3-4-2. ストレッチング ハッシュ処理を何回も繰り返し行なうことを指します。 通常は1,000回以上らしい
ソルト+ストレッチングでハッシュすると強固 →処理コストがかかるので注意が必要 →逆に負荷をかけるためにDos攻撃に利用される可能性有り

38 3-5. セキュリティ総括 セキュリティ問題は日々進化しています。
つまり、最新情報に目を向けていないと脆弱なソースを作ることになるので注意！！ 昔はOKだったという概念は捨てましょう。

39 4-1-1. Polymer 2013/05/17 に行なわれたGoogle IOで「Polymer」が発表された
→正確に言うと「Polymer.js」 Polymerとは多くのWebComponets技術のポリフィルを提供し、独自の再利用可能なコンポーネントを全ブラウザがそれらをサポートする前に、作ることができるようになる！ HTML5を標準に使用している

40 4-1-2. Web Componets Web ComponetsとはUIをコンポーネント化するための仕組み
Google主導で仕様策定が進められている 現時点ではChromeしか対応していないかな？ これにより工数削減が見込まれている