雑な感想とメモ[WEBエンジニア勉強会 #01(東京都,新橋)]@20170602

WEBエンジニア勉強会 #01(東京都,新橋)に参加してきたので感想とメモを雑に共有する。 僕もLT枠として発表した。 togetterでもまとめられている。

感想

※お前の感想じゃなくてまとめだけ見たいという方はこちら

エンジニアの世代間の違いが現れていて面白かった

この勉強会ではまず、ある程度ベテランのエンジニアさんがたが20~30分の発表をされ、そのあと若手エンジニア勢（自分も含め？）のLTがあった。
ベテラン勢の方はWeb系エンジニアとして働く上で役に立ちそうな知識を話されていて、
若手はエンジニアとして仕事し始めて感じた悩みや楽しいことなどを話していた。
多くの勉強会と違い、新橋で開催されていることや、特定の技術にフォーカスを当てている勉強会ではなかったこともあって、普段とは少し違った雰囲気だったように思う。

ベテラン勢の発表が軒並み刺さりまくった

Web技術の歴史、OAuth2.0、開発環境についてという3つのベテラン勢の発表は忙しい昨今自分だけでは振り返ったり勉強できたりしない分野をしっかりまとめてくださっていて、
自分が気になった時に参照できるようなものになっていて、単体で見ても非常に良いものだった。

発表者 + 数人で打ち上げをした

主催のOSCAさんの声掛けで打ち上げの飲み会を会場の横のビルで行った。
ベテランの方々のSIerでの苦労話などが聞けて面白かったし、
僕がやっているpodcastをOSCAさんが聞いてくださっていて、そのFBなどが得られてよかった。
SIとか受託をしていたほうが技術的には幅が広く多くの経験をつめるという意味で良いのかなぁという気が最近してきている…どうなんだろう。
もっとキャリアの長い人、いろんなキャリアを歩んできた人のエンジニア観を聞きたい。
そういう意味ではこの勉強会はちょうどいい題材を扱っているとも言える。

以下、本編

勉強会の目的

  • Web技術の共有と学習
  • 普段の取り組みの発表
  • Webエンジニアの友達や仲間を作る

近年のWEBの歴史と現状について (@engineer_osca)

自己紹介

趣味

  • 夜景写真家
  • 舞浜在住（ディズニーの三歩が趣味）

主催の目的

  • エンジニアで現役
  • 友達づくり、知識を共有したい
  • 老害トークはしたくない

どこまでがWEB？を話したい

主催として過去ではなく、未来の話をする勉強会にしたいが、今回は歴史の話をする。

Web

ブラウザとサーバがHttpでやり取り

WEB GUI / インターフェース

→ FlashやSilverlightが駆逐されHTMLの時代に

HTML 5.1の話

  • pictureタグ
    • sourceタグを子に持ちmedia属性によって表示の制御が可能
    • スマートフォン対応やレスポンシブ対応がやりやすくなる
  • input type
    • datetime-local
    • week
    • month
      • 日付の入力を受け付けやすくする
      • input typeがHTML5で増えたがまだあまり使われていない？
      • 今後、どのように使えるのか、watchがひつよう

Webブラウザ

  • InternetExplorer
  • Mozilla Firefox
  • Apple Safari
  • Google Chrome
  • Edge
    • ブラウザの凌ぎ合いによる肥大化(誰が使うのかわからないような機能が追加される)
    • ブラウザに本当に必要な機能はなんなのか？
    • Electron
      • Webの知識でデスクトップアプリ
      • ブラウザの仕組みが裏で動いている
      • ブラウザ肥大化の象徴？
    • ブラウザでやるべきこととネイティブでやるべきことの線引をすることがこれからのエンジニアに求められる

クライアントサイド・スクリプト

通信(HTTP、HTTPS)

HTTP/2

  • 通信の高速化
    • ヘッダの圧縮
    • PUSH通信(サーバ側から送るものをスケジューリングできる)
    • HTTPバイプライン
    • Head of Line(HoL)ブロッキング問題の解消
  • HTTPS通信が前提
    • Let’s Encrypt
    • サーバ上で証明書の発行要求を行う
    • 取得できるのはDV証明書
    • 有効期限は3ヶ月だが、コマンドラインで要求可能なのでcronなどで自動更新が可能
    • 流れとしては、GoogleがHTTPSを優遇するということを公表していたり、通信の傍受を防ぐ目的でメジャーになっている
  • 各種サーバーのサポート()

サーバー環境の変化

その他の話題

次回以降の発表候補

OAuth 2.0 をかみくだく (@garbagetown)

認証と認可

  • 認証
    • Authentifcation(AuthN)
    • 誰であるかの証明(運転免許証やパスポートなど)
      • ID/Password
  • 認可
    • Authorization(AuthZ)
    • 何ができるか(鍵や切符など)
      • AccessToken

OAuth2.0が必要となった背景

サービス増加に伴う認証の課題

  • IDなどの文字数の制限がサービスによって違う
  • アカウント争奪戦
  • 文字種の強制 など

サービス連携に伴う認可の課題

ログインの共有、パスワード変更などの問題が有る 近年Finteh界隈ではパスワードをサービスに預けるということをゴリ押ししているため、 金融庁の指摘が入っているなどで話題

それぞれの課題と解決策

  • OAuth 2.0 2012年10月にRFC 6749 こちらでOAuth1.0が正式に廃止

  • 用語がわかりづらい

    • OpenIDなどで使われる用語との差異
    • 世間一般で使われる用語との差異
    • 混乱を招くので注意が必要
    • 現実で起こりうる問題
  • 仕様で定められていない処理が多い
    • クライアントを登録する方法
    • リソースオーナーを認証する方法
    • アクセストークンの内容と検証方法
  • 処理フローが複雑
    • HTTPリダイレクトの連続(OAuth Dance)
    • セキュリティの考慮事項が多い

身近な例Connpass(勉強会サービス)とTwitter(マイクロブログサービス)

  • リソースオーナー
    • エンドユーザー
  • リソースサーバー
  • クライアント
    • 勉強会サービス
  • 認可サーバー

事前準備

クライアント登録手順、リソースオーナーの認証手順は仕様の範囲外こちらはRFC6749を考える前に必要

  • Protocol Flow
    • クライアントクレデンシャル
      • クライアントIDとシークレットで認証
      • クライアントアクセス情報の取得
      • フォロワー情報取得などは可能
    • リソースオーナーパスワードクレデンシャル
      • リソースオーナーの認証情報(パスワード)を渡す
      • クライアントに悪意がある場合、リソースオーナーになりすまして任意の操作を行えてしまう
      • アカウントの乗っ取りが可能なのでサービスが信用出来ないと、エンドユーザーはこのフローを踏んではいけない
    • インプリシット
      • リダイレクト祭り
      • アクセストークンのやり取りの末、勉強会サービスがアクセストークンを入手する
      • アクセストークンがローカルに保存されてしまうため、端末共有時などは要注意
    • 認可コード
      • Webアプリケーションで使われている、一般的にOAuth2.0と呼ばれているもの
      • アクセストークンをローカルに保存されないため、勉強会サービスが攻撃に合わない限り大丈夫

OAuth 認証と OpenID Connect

まとめ

  • 認証と認可をちゃんと理解しよう
  • サービスの増加と連携に伴う認証、認可の課題
  • OAuth2.0は認可のためのものでOAuth認証を使われている

Appendixが資料に挙げられているので参考にする

webエンジニアがスタートダッシュをキメるためのローカル開発環境の勘所 (@nabedge)

ビズリーチの人(リンク)

新橋はいい街

  • 「魚金」(が多い)
  • 「なんくるないさ」（ガード下に有るらしい・ゴーヤチャンプル）
  • 「宇和島」（高いけど珍味が良い・板前さんがいかつい）
  • 「PUBこだま」がおもしろいらしい(アド街ック天国で紹介、90歳のママさん)
  • 「Footers」など

ローカル開発環境を素早く準備する（スタートダッシュは大切）

  • 目的にフォーカスする
  • 炎上した時に助っ人にすぐに仕事に入ってもらえる

Webサービスのコードをどこで、どうやって書くのか？

  • 【レベル0】データセンター建物内にて本番サーバにアクセスしてコードを書く？
    • 古き良き思い出
    • データセンターで寝泊まり
  • 【レベル1】エディタとSCPクライアントによって本番サーバにアップロード
  • 【レベル2】ローカルなサーバXAMP、MAMPで書いて、SCPクライアントで本番サーバにアップロード
  • 【レベル3】検証サーバを立てて、動いたら本番サーバにアップロード
  • 【レベル4】MySQL,Redis,…チーム開発、VCS、CI、で検証サーバと本番サーバを運用

レベル4のローカル開発環境の話

  • ローカル開発環境の要件

    • コードをサクサク書ける
    • 書いたコードが動くことを自分のPCで確認できる
      • コードが動くための バックエンドサーバが必要

  • ミドルウェア群

長大な「ローカル開発環境構築手順書」

  • 長い
    • 抜け漏れ、手順書書き直すの忘れ
    • 他のWebサービスの開発環境とバッティングしてインストールできない(バージョン違いなど)

NOT 手順書、そして仮想OS

OracleVirtualBox or VMWare、Vagrant, Docker

  • ホスト型(ハイパーバイザ型)
    • IPをずらして複数の開発環境の共存によるバッティングを起こさないようにできる
  • コンテナ型
    • 起動速度が軽い

組み合わせでやるのが良い

ローカル開発環境4原則

  • サルでもできるくらいの自動化
  • 誰でも環境を変更して配布可能に
  • 他の開発環境と干渉しない
  • 金の弾丸（富豪的開発）

エンジニアになって2ヶ月経って思うこと (@ak6mcz2)

自分の前の発表だったのでまとめきれなかったorz

大企業でWeb開発はできるか (@renjikari)

  • 通信業界のエンジニア(サーバ寄り)
  • 新卒2年目
  • MSPのベンチャーでアルバイトしてました
  • 好きなこと
    • Infrastructure as Code
    • ISUCON

Web開発の話

  • 業務向けのシステム
    • SIに近い
  • クラウド利用のための契約とかprovisioningとかをポチポチできるようにする

  • 社内の人がクラウドを触る助けをする

  • 内製開発

  • Python + Django

pros , cons

pros

  • スピード感
    • ある意味丸投げ
    • 2月
  • エンジニア間
    • 大企業でもコードが書ける
    • ツールとか言語はなんでも基本OK
    • Gitlab+Jenkins+Slack+Trello

cons

  • POがいない(責任を取りたくない?)
  • Testを書かない
  • レビュー
  • 継続的デプロイができない
    • 商用環境が神聖

ロードマップ（これからしたいこと）

  • フィードバックを貰ってUI改善
  • マルチクラウドも契約から疎通まで
  • テストを書いてほしい

まとめ

  • どうも大企業でもWeb開発はできる