コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

クライアントとサーバに分かれていたアプリケーションの経緯とIsomorphicの話がわかるスライド『Isomorphic Survival Guide』

スライド回顧録です。

speakerdeck.com

「DevLOVE201 越境ジャーニー」 のときに紹介されていたスライド。サーバーとクライアントで同じプログラミングコードを書いて一定化させる「Isomprphic」の話のスライドです。

このスライドはIsomorphicの話としてもわかりやすいのですが、そこの経緯を示したクラサバモデルの歴史がわかりやすく時系列順に書かれているのでインターネット勃興以前のシステムが垣間見えるのがこの資料のよいところです。

この前の多層アーキテクチャが生まれた利点を考える - コード日進月歩 を書く際に多層アーキテクチャのことを調べたのですが、資料としてインターネットがあることが前提なのかそうではないのかが分かりづらく、抽象的な話が多かったので把握がしにくかったのですが、この資料の存在がわかりやすく時系列に出してくれていたので他の資料の内容がすっと理解できました。

付録Cもそうですが、時系列で説明してくれるものはこういう技術に注目がいった経緯がわかるので、過去を知らないものとしては何故出来たのかをスムーズに知る手立てになるのでとてもありがたいです。

Isomorphicという言葉と概念は最近耳にしなくなりましたが、node.jsでコードを統一する、C#やKotlinでアプリとサーバのコードを揃えるという概念は今もそこかしこにあるので、ある意味一般化して強調しなくてもいい話になったのかな、とも思います。

関連リンク

rspec内でcontrollerを定義して、concernのメソッドをテストする

俗に言うAnonymousControllerという手法です。

環境

$ bundle exec rspec --version
RSpec 3.8
  - rspec-core 3.8.0
  - rspec-expectations 3.8.2
  - rspec-mocks 3.8.0
  - rspec-rails 3.8.1
  - rspec-support 3.8.0

書き方

下記のようなconcernがあったとする

module Targetable
  extend ActiveSupport::Concern

  def public_na_method
    true
  end
end

publicメソッドを試したい場合は下記のように書く(helperは環境に応じて適宜書き足してください)

RSpec.describe "Targetable", type: :controller do
  controller ApplicationController do
    include Targetable
  end
  
  describe "#public_na_method" do
    it "動くこと" do
      expect(controller.public_na_method).to eq(true)
    end
  end
end

参考

『次世代Webカンファレンス』のAdのセッションが面白かったのでまとめたメモ

昨日の録画が上がってて、作業しながら聞いてたら面白かったので昨日の記事に追従する形おまとめした。

発表のまとめ

Ad

www.youtube.com

トークメモ

ラッキング

  • 広告主としては電話番号や住所のような個人情報は欲しくないが、もっと匿名性のある情報はほしい。
  • GDPRの考え方により、個人情報の範囲が拡張されて、閲覧履歴すらも個人情報とみなされると日本でもその時流が来る可能性がある。
  • デジタルマーケティングなので、ユーザに合わせたよりよいものを出すためのものだが、どんどん規制が厳しくなっている

セキュリティ

  • ユーザが任意で広告トラッキングをさせないためのITP (Intelligent Tracking Prevention) を回避するような業者も出てきているが、あまりよろしいことではない。
  • 広告側のエンジニアがちゃんとモラルをもってやっていかないと、ビジネス側はどうしても利益を推し進めてしまう。
  • ITPを回避するEverCookieやSuperCookieという技術がよくないのが、ユーザが任意で消せない。
  • ユーザの同意を得ながら明示的に止めたい場合は止めるというクリーンな運用が必要

事業者、クライアントの多様性

  • 事業者が多すぎて、業界の基準に従っているところ従っていないところと別れている。
  • 現在は手付きの悪い業者は広告クライアント側が拒絶する流れができているので悪い業者は弾かれている
  • 悪い業者が出している広告、というのはユーザーとしてはわかっていない。そのため業界全体がクリーンにならないと駄目なのではないか

IDFAと業界全体のプロトコルの不揃い

  • IDFAという仕組みがある。Appleのアプリに組み込まれる、広告用のID。アプリをまたいで固定され、ユーザが明示的に使わないってことができる。
  • Webにも同じ考えがあれば嬉しいが、サイトAとサイトBで同じIDが特定できるとプライバシーポリシーの同意とかの考え方が難しくなるので、整理としては難しそう
  • ads.txtや進んでいるが、業界として足並み揃えて進めるみたいのはあまり進んでいない。
  • OpenRTB(Real Time Bitting)も2.0から3.0に移行しようとしているが、全体的に進んでいるってわけではない
  • 事業者間で誰からやりはじめる?みたいな読み合いな状態になってしまっている。

広告不正(アドフラウド)

  • 不正に広告を挿入、広告主を騙して不正に取得するのがアドフラウド
  • クリックやPVに対してお金を支払うというのが根底にあり、そのカウントを水増しをしてくる。表示されている10%は不正広告という話もある。
  • 話題になった漫画村ではiframeを不正に使って大量の広告を表示していた
  • SimilarWebの上位100位以上は見たことないドメインが出てくるのはおそらくそういう不正な広告アクセス
  • OpenRTB3.0では不正への仕様が入っているが、まだ業界が取り組めていない
  • アプリなどはネイティブのプラグインとして提供しているから不正が起こりがちの現状がある
  • ads.txtやads.certという考え方で不正を防ぐというのも考えている
  • ただ業界としては正して行こうという流れ

BetterAds

  • ブラウザ側が広告の形を規定して、それに沿わないものは表示しないという取り組み
  • Chromeのシェアを考えると、従わざるをえない状況になるはず
  • これが真剣に取り組まれていくと扱われる広告がクリーンになるので、そこからまた室の悪いものが出てきても特定しやすくなりそう
  • 技術的にもそういうものが検知しやすいような仕様が入ってきている

デジタルマーケティング市場の今、そしてこの先

  • デジタルマーケティングのエンジニアって少なくなっている
  • デジタルマーケティングの市場は伸び続けている、また広告のデジタル化が進んでいるので当面市場としてダウントレンドになることは考えにくい。またデータマーケティングという観点もある
  • テレビや新聞がオンラインにならないというシナリオは考えづらく、オンラインになればそれらの業種の人がデジタルシフトするので悲観的なシナリオは考えづらい
  • 広告配信システムって、どこに何を出すかのシステム。今後配信するメデイアも増えてくるし、配信する面(タクシー、屋外広告、ARなど)も増えるはず。
  • 人間のアテンションがある限り、広告の費用は投下される

オペレーション作業

  • 本当のはじめは1つのサイトに出せばよかったという時代だったが、だんだんプレイヤーが増えていく中で出せる面としてのサイトやサービスが増えた。そこのコントロールの労力はどんどん増えていった。が、それをコントロールするのはマンパワーになっていた。
  • 広告業界は業界の歴史的にマンパワーでどうにかする文化が強い。マンパワーで解決できないものはできない、という形にすらなっている。テクノロジーで解決するというレイヤーでの取り組みが行われていない。
  • 運用を簡単にするという意味では3rd Party Ad Servingという考え方もあったが、GoogleFacebookに馴染むような形ではなかったのでそこまで浸透しなかった。
  • 広告は配信技術にはテクノロジーを投入してきているが、オペレーションのテクノロジーに投資すれば良くなるのではないか、そろそろ人間が管理するのは大変な領域になってきた。

AdBlock

  • AdBlockも「広告邪魔じゃん、悪いことしてるじゃん」というエンドユーザの信頼を失っている部分から来ている話
  • 広告ってユーザーとのコミュニケーション接点なのに、それを拒否されてしまう事態にまで至ってしまったという事実を重く受け止めるべき。
  • ポジショントークにはなるが「商品の広告を出すことで認知してもらい、みんなが商品を買うことで利益が出て、また新たな商品を売ることができる」というようなエコシステムがあるのに、それができなくなってしまう。
  • ユーザが広告から身を守れる以上、広告業者全体でどうやって信頼してもらうかを考える必要がありそう

広告とWebサイトの機能

  • AMPで出したい要望もあるので、AMPAdという形で対応はしている。
  • PWAも作り方を考えないと遅くなってしまうので向き合う必要がある
  • メディア側がちゃんと広告を使いやすくようにしていかないと行けない
  • document.write は結構事故があったりするので扱いにくいが、利用されているところもあるので使わざるを得ない問題がある
  • ブラウザ側にはユーザを守るための機能は実装されている
  • 広告事業者的にもブラウザ側に欲しい機能という観点で意見が出た

事業者との付き合い方

  • ちゃんと長期的な視点で取り組んでいる事業者を選んでいく
  • 悪い事業者は弾かれていく
  • 単一の事業者だけよくなってもしょうがないので、利用側からは業界全体が良くなることを要望してほしい。

感想

  • 現在の広告に対しての最新動向としてどうにかしていきたいという気持ちがひしひしと伝わる話だった。
  • Better Adsの話は知っておいてよかったなというのと、これで室の悪いものは淘汰されていってほしい。
  • オペレーションへのアプローチが全然されていないというのがびっくり。確かにそこは一種のブルーオーシャンなのかも?

関連リンク

『次世代Webカンファレンス』に行ってきたよメモ

次世代 Web カンファレンス 2019に行ってきました。

各発表の感想

全部パネルディスカッションなので自分が見てきたセッションのメモでお送りします。あとで録画が出るのでちゃんと見たいかたはそちらを御覧ください。また登壇者はconnpassなどをご参照のこと。


SRE

www.youtube.com

twitter.com

トークまとめ

お三方個別に意見を喋られてましたが、まとめたダイジェスト風になります。

行う業務の比率に関して

  • リアクティブとプロアクティブという形でタスクを分ける手法をとっていて、それらが50%ずつになる運用をしている
    • リアクティブとは差し込みやアラート対応などの業務
    • プロアクティブとはモニタリングの改善などもともと計画的にやろうとしてた業務
    • SRE本のトイル(toil)とリアクティブは同じ意味だが、言葉が強すぎる
  • ロードマップを敷いて、それ以外の差し込みタスクという形で定義しているケースもある

リアクティブなタスクの取り組み方

  • マネージャーに頑張る、みたいな側面もあるが取り扱う人を変えたりすることで調整しているという側面もある
  • リアクティブ/プロアクティブ運用においてはリアクティブに50%分を設けるので、それを使っていくし、リアクティブがなさそうならリアクティブなタスクに使う
  • ロードマップを作ってスクラムを行うという考え方だと、それ以外のタスクは差し込みタスクなのでベロシティが下がるのでわかる。それを次回移行のスプリント設計に生かしていく。

オンコール/インシデント/ポストモーテムへの取り組み方

  • すべての日においてシフトを組む、週末だけシフトを組んで平日はみんなで、SREチームだけだったり、マイクロサービス時はアプリ開発チームが受け持ったりとチームの有り様によって様々
  • ポストモーテムはSlackで行ったりするケースが紹介されていた。
  • 過去2年分の障害を洗い出して、放置されているけどやらなければならないものは新規のロードマップで取り込んでやるなどを行っていったというケースもあった。

SLI(Service Level Indicator)/SLO(Service Level Objective)

  • SLIとSLOをサービス開始前に決めるようにし、SLOはアプリケーションを作った開発者が決めているが、本来はPOやCTOが妥当性を検討するという世界観がよい、という意見があった。
  • ビジネスサイドとしては限りなく100%に近づけたくなるが、本当にそうであるべきかを問うべき。99.99を99.999にするのにどれだけコストがかかるのか、どういうことをする必要があるのかをしっかりと示して行くべき。このタスクを取り組むとタスクできなくなりますよ、という話。

監視の取り組み方

  • DataDogでモニタリングし、WarningはSlack、クリティカルなものはPagerDutyで通知し、開発者にもアカウントを付与してオンコールする仕組みを敷いているという話があった
  • オオカミ少年アラートが多いので、開発者とアラートの設定をレビューする、「朝3時に起こされるかもしれないが、それでも良いアラートか?」というような観点。
  • PrometheusとAlertManagerで構築し、テキストベースにすることでPR確認という運用を敷いている。

インフラのセルフサービス化をどう考えているか

  • マイクロサービスに取り組んでいるのでマネージドのサービス(AWSとかGCPの意)を使ってチーム内で完結させることでチームでいろいろ管理ができるようになる。プラットフォームチームはその下にあるkubaneticsやterraformの実実行などをカバーする

SREはどうなっていくか

  • 開発者全体に溶け込むということもあるのではないか
  • 上記の話とは別観点として、99.99の可用性を実現するのは開発者だけでも行ける時代になってきたが、99.999の可用性を実現するなど、より突き詰めていくとSRE側のエンジニアがいるのではないか。
  • 考え方としては運用というよりはソフトウェアエンジニアリングに変わってきた。計測できるものがすべて。
  • マネージドサービスの進化によって関わり方も変わってくる
  • SREはシステムを理解したソフトウェアエンジニアがやっていくといいのかもしれない。

感想

  • SREの考え方の登場によりスクラムとかの理論をより適用できるようになったので、枯れた知識の水平思考ができそうな分野だという感じ。
  • 緊急対応のポイントの積み方とかは逆にアプリケーション開発としても取り組める考えかただと思った。たぶんマネジメント+開発とかやっている人はプロアクティブやトイルがマネジメントリソースとかでも考えられそうだし。
  • deeeetさんがマイクロサービスに適用したときの考えかたなので、チームにどのようにインフラ的なものを移譲しているかという良い事例が聞けた感じ。
  • SRE本の知識あり前提の話だったが、後から十分補完できた。

関連リンク


Security

www.youtube.com

twitter.com

トークメモ

最近のWebの脆弱性事例

  • CDNのキャッシュ事故とか設定の認識ミスで起きた事故
  • 多いという観点だとどうしても利用者や初級者が使うという観点でWordPressやECQubeが上がってしまう。WordPressなどはプラグインを完全に信用するモデルなので、それがWordPressの評判を下げている。
  • npmの変なコードが交じる事例、あれに関してはバージョン固定をすることで回避できることだった。
  • 物によっては最新にアップデートすることでセキュアなものがある一方、npmの事例などは固定にしておいたほうがセキュアという結構難しい。

CVE

  • CVEは気になったものは読むようになどしている、ただ全部見るのは無理なので、コードの任意実行(code execute)あたりでひっかけて見るようにしている。とはいえ普通の開発者はそこまでしなくていい。
  • セキュリティ系のメーリングリストのほうが説明がちゃんとあるのでそっちを読むと良いかもしれない

Webの脆弱性との向き合い方

  • ブラウザの固有の仕様やそこに構えることに関してはいろいろな意見が出たが、そこまで考えて開発者が考慮するのは大変だし、最新の機能に関してはブラウザ側がちゃんと更新してくれるはず
  • Flashや微妙に放置されている仕様をついた脆弱性に対策するをするために変な実装方法が出回る。

HeaderやCookie

  • 脆弱性のためのヘッダが増えており(5個ぐらい)、脆弱性診断などではつけないと怒られるケースもある。
  • ヘッダに関しては利用ケースによっては必須なものとそうではないものがあるが、おまじない的につけてしまうケースが多かった、ただそこで外さなければいけない場面において必要なものを外してしまったりすることで事故が起きる。

  • CookieにはサードパーティCookieを利用して他人にすり替えるなどもできる。

  • Cookieには __SERCURE__HOST という接頭辞をつけることでセキュアにできる ( 参考 )
  • Double Submmit Cookie とかは微妙な事例(参考:IEのクッキーモンスターバグはWindows 10で解消されていた | 徳丸浩の日記

CSP(Content Security Policy)

プライバシー

  • GDPRなどあるが、目に見える形で同意を求める世界観はどうなのだろうか。
  • 個人情報のCookieと匿名性のあるCookieが等しく扱われることになり、意図しない形なのでは
  • マシンリーダブルなものがほしいがまだそのようなものはない、このままだとJSの利用まで同意を求められる時代が来る可能性もある

アドテクとセキュリティ

  • フィンガープリンティングの手法などは広告に使うべきではなく、不正対策目的などで使われたほうがいい(違う端末からログインされました、みたいなもの)
  • アドテクノロジー側はそこまでセキュリティの関心がない、カンファレンスとかでもセクションなどがない。
  • ターゲティングとJSONPによる広告配信などは問題がある実装になっていた。(広告文面が第三者が取れる情報になっていたので不動産系のターゲティングをみると居住地が特定されてしかう可能性があった)
  • これらの問題は被害者に500円与えるとか、そういうことではない回復不可能な問題なのでちゃんと向き合う必要がある

セキュリティはどうしていくべきなのか

  • いままではMan in the Middle(中間者、間に入って通信を見るという意だと思われる)などで安全なアプリからセキュリティの専門家はチェックできたが、Andoroidなどはそうではなくなってきている
  • 難読化も突き詰めていくとあんまり意味がない部分でもあるので、解読しにくくする方にアプローチするのではなく見せやすくしたほうがいいのではないか。(セキュアなコードはフロントに置くべきではないし、圧縮ならほかの手法で充分)

Web開発者への気持ち

  • コピペ問題、効率のためにコピペするのはいいが「権利の問題」「脆弱性の問題」を考えてちゃんとやってほしい。ググって1つ目のリンク先が脆弱性のあるコードだったりすることもあるので…
  • セキュリティやプライバシーは当事者意識を持つことが大事で、おかしい気がする、からセキュリティの専門家にエスカレーションするだけでも防げるものはある。ただし相談は無料ではないよ。

感想

  • まとめながら自分も用語を補完しながらやった、Man in the Middle ってなんだろうと思ってたけど中間者ってことですね…
  • HeaderやCookieの話は学びが多かった、というかCSPとか知らない仕組みでした…
  • 割と意訳なところもあるので気になるひとは動画を見たほうがよいかもです。

関連リンク


Microservice

www.youtube.com

twitter.com

トークメモ

分散トレーシングと問題発生箇所特定

  • マイクロサービスに関しては問題発生箇所の特定がわかりにくいというのがあるがどうしているかという話
  • AWS X-Rayを使ってやっているが、あくまでもパフォーマンスチューニング観点だったり、実際にそれをやりはじめるとログが膨大になる。送るときも普段はサンプリングして、明確なエラーはちゃんと送る。
  • 分散トレーシングはパフォーマンス確認には使えるが、事故時の確認には使いにくい。
  • 問題特定は入り口のAPIでユニークIDのトークンを発行してそれを各所でロギングするしかないよね、という感じ。

障害対応のシュミレート/障害対応をどうするか

  • サービス出す前にそのコンポーネントが落として動くかをチェックする。エンドユーザに失敗認定されないようなリトライをクライアント側でしているか、みたいなところも見る
  • 一方でリトライしたことによりサービスの息の根を止めるみたいなところがあるのでちゃんと考えたい
  • カオスエンジニアリングはサービス特性的に一部落ちていても問題のないならできるが、BtoBだとそれが許されないこともあるので、そこらへんの話がちゃんとできていればできる
  • カナリーデプロイは仕組みがあればできるが、台数少ないとかだとあんまり意味がない。
  • 識者は当たり前だけど、その当たり前ができてなかったりする。例えば反射的に障害検知としての心構えみたいの(リリース後のモニタリングや変化のチェックなど)

サービスメッシュとどう向き合うか

  • サービスメッシュを入れるとリトライ、タイムアウト、サーキットブレイカーなどや死んだ時のハンドリングできるので良い、ただいつ入れるべきか
  • Envoyとかも基盤さえ整っていれば別にサービスが少ない時点でも入れてもいいのでは?という感想
  • 開発者が考えて使わなければいけないのはつらいので基盤部門とかにお願いしたい。

バックエンドはどこまで作り込む?

  • Firebaseとかあるが、あれはあくまでもサーバーエンジニアが考えていたようなことがクライアントエンジニアに移っただけ
  • AWSなどのマネージドサービスができたらインフラエンジニアが消える、みたいな話に似ていて、結局対応者が変わるみたいな感じ

データのプロトコル

  • 言語がバラバラになるとSchemaなしにはできない。JSONはそのためにあるが、ProtocolBufferもSchema固定できるのでそういうSchemaが共有できるものが必要。
  • JSONでもいいか、と思ったものでも量が増えてくると辛くなってくるのでProtocolBufferという流れになってきた。
  • Kafkaとかだとクライアントが優秀だからそのままのプロトコルを使わなくてもOK。ただしPerlはクライアントの作りが微妙なのでJavaでラップしてしまう。

言語の選択

  • 各種ミドルのクライアントライブラリがしっかりしていないとつらいので、そういう意味だとAWSGCPが対応している言語がよかったりする。その流れだとJavaがよく、KotlinやScalaという選択肢でもJVMレイヤーで考えればJavaのライブラリは互換がある。
  • 規模が大きいと、開発の継続性、他の国でも開発者が確保できるかも論点になる
  • Goを採用している話が出たが、クライアントライブラリや監視で問題にはあまりなってない
  • パフォーマンスなどの話になるとRubyなどは辛くなってくる側面もある
  • 枯れた言語がいいという側面もあるが、枯れすぎるとライブラリなどが辛くなる

人数が増えるとマイクロサービスは必然?チームはどう考える?

  • 1つのリポジトリをたくさんの人数で管理するのは管理もコミュニケーションも大変。自然と別れてくるはず。
  • Amazonのピザ2枚ルールがあたりが妥当なのかもしれない、S3は200以上のマイクロサービスに分かれているという話もある
  • コンポーネントが大きいと必然的にピザ2枚ルールで分割し、開発が別れてマイクロサービス化する。人が多いとレビューとかも意見が別れたりするので大変になる。
  • ピザが2枚食べられるって、結構あいまいな人数設定で、お腹いっぱいになるかそれなりに食べられるかで変わる。
  • コンポーネントに割り当てる人数も考えかた次第で変わる、1人でもまかなえそうなものでも属人性や技術継承の観点から多人数つけたりする。
  • チームをロケーションが異なるところで分割すると会話の難易度があがる、ただしロケーションが違うと監視や採用の面では旨味があるので考え方次第

Webのサーバサイドに思うこと

  • マネージドサービスがいろいろできるので1人ができることは広がっているので、なんでもやることが大事かも
  • チームによっては1つのことに集中できるようになるので、そこで専門的なことができるという側面もある

感想

  • 分散トレーシング運用事例とかは参考になった、というかAmazonはマネージドであるんですね…
  • サービスメッシュを本番投入している事例とかは心強いし、しかも初期からいれるべきかもみたいな見解が聞けたのは良かった。
  • チームの分け方はなるほどな、という感じ。そして今日の話だけ聞くとJavaつよいって感じですが、やっぱりプロダクトファーストだと立ち上がりのときはRailsとかで大量トラフィックと向き合うときにJavaとかの選択肢になるんじゃないかなという気持ち。
  • カオスとケイオスの読み方の違いはクーロンとクローンの違いみたいな感じがする。

関連リンク


AuthN/Z

www.youtube.com

twitter.com

トークメモ

パスワードと最近の認証

  • IDの認証としてのパスワードは5〜10年にで設定したものはどっかでバレている可能性が高い
  • パスワードは駄目な部分がある
    • WebサービスごとにIDとパスワードを設定しているが、サービスによっては守りが手薄で漏れることがある
    • ユーザーはパスワードを覚えるために同じものを使い回す、そのため漏れると他のサービスのパスワードも漏れたのと同然
  • パスワードが漏れた際にリスト型攻撃のようなことをされるが、前は全然関係ない地域からドカッとアクセスが来ていたが、最近はゆっくり試行されるためにわかりづらくなっている
  • OAuthがひとつのブレイクスルー、ユーザがパスワードなどのcredentialをアプリに渡さなくても済むようになった。
  • Yahoo!JapanはFIDOに取り組んでおり、パスワード脱却をしようとしている。
  • パスワードレスはいいこともあるが、アカウントリカバリーの難易度があがるなどの話もある
  • ただ秘密の質問などのいけてないものもあるのでそこらへんはまだユーザ規模的に完全になくすことはできてない (参考: Yahoo!ジャパンの「秘密の質問と答え」に関する注意喚起 | 徳丸浩の日記

Web Authentication

  • ブラウザの仕様として登場してきているWeb Authentication
  • Authenticatorというものを使って、パスワードの代わりを実現する、それの認証の一つとしてスマートフォン+指紋で実現するのがFIDO。FIDO=生体認証ではない。
  • 考え方として多要素認証と多段階認証がある。多要素は要素の異なるもの(文字列と生体など)で多段階は異なるタイミングでパスワードを聞くなどである。
  • 認証がローカルで完結するので、Webサービスなどと違い一度もパスワードがネットワークの外に出ないのが利点。加えて、機器側で対象のWebアプリを限定などもできるのでフィッシング詐欺のようなものを防げる
  • ただ端末そのものが本人を示す役割をしているので紛失や盗難のリカバリーが大変。普段使っている異なる端末からOTP(OneTimePassword)使って認証かけるなどしかできない。

本人確認

  • オンラインのWebサービスは手軽さを売りにしている以上、認証は手軽にならざるを得ない、本当は免許証の提出をすれば確実なものができあがるが、そうはいかない。
  • KYC(Know Your Customer)などの考えかたがあるが、オンボーディングだけではなくContinus(継続的に)確認してく必要がある
  • オンラインのIdentityは種類あると思っており、「気軽に始めたい」というものと「お金が絡むもの」のように使い分けたい。
  • PhotoID(写真付き証明書)は確かに本人確認としては強いが、保険証をうまくつかって異なる人物が免許証をつくるなどの抜け穴は存在する。そういう巧妙な偽造を組み合わせるとオンラインで口座開設などはいろいろ危険を孕む。
  • SIMなどは電話番号が本人を証明するものとして使っているので、そういう偽造された本人証明はいろいろとつらい
  • マイナンバーカードやIC入りの免許証はもっと使いようがあるはず

OAuth2.0

  • OAuthに関わるRFCはたくさんある。標準化されていることはとてもいいことだが、多すぎて追うのが大変
  • OAuthの基本的な部分は実装しやすいようになっており、セキュリティ対策を後追いでRFCが追加されている
  • 普通の使い方であればRFC6749RFC6750を抑えておけばいい
  • もっとセキュアな使い方をしたければ他の部分を読んで実装すればいい
  • 普通の使い方も、厳格な使い方もできる。

認証と認可

  • AutnN/ZというのはAuthenticationとAuthorizationのこと。
  • OAuthは認可の仕様、OAuthから派生したOpenIDも認可、OpenIDに認証の仕組みがついたのがOpenID Connect。
  • その中の仕組みとしてあるのがJWT(JsonWebToken)。JWTのSpecも重厚。

IDProvider、ユーザ体験との向き合い方

  • Web Authenticationも仕様としては公開されるが、セキュリティにパワーをかけられないところは無理に実装せず、GoogleやYahooJapanなどのIDProvicerなどのサードパーティに任せる。
  • ACR(Authentication Context class Reference)やAMR(Authentication Methods References)など認可に関する情報をOAuth2.0では提供しているのでそれを正しく使うべき
  • 使い分けのフローは仕様として存在するが、それが自身のサービスのどこに当てはまるかは脳みそを使うところなのであまり考えられていない
  • 認証のユーザー体験はあまり重きを置かれない部分で、どちらかというと「作らなければならない機能」のような立ち位置
  • IDProviderは信頼性が大事である。ユーザが信じてくれないとアカウントを作ってくれないので、不信を抱くような作りは良くない

ブロックチェーンとID

  • ブロックチェーンの技術はIdentityManagementという観点で非常に有用なのではないかという。
  • 考え方次第ではWeb上のAuthenticatorとして使えるのではないか
  • ブロックチェーンを使うと、そこにセッション情報が載せられるので、一律ログアウトということもできるのでは、という夢が広がる

感想

  • FIDOはこのまえのBuildersConで話を聞いて知っていたけど、それ以前にOAuthとどう向き合うみたいなところはためになった
  • 本人確認とどう向き合うかは業界的にも考えなければいけない問題だとは思う。
  • OAuthも知らない仕様がたくさんある、コンテキストとして向き合うときは向き合わないといけないのかもしれない
  • パスワードのない時代、あと10年以内に来るのだろうか

関連リンク


FrontEnd

www.youtube.com

twitter.com

トークメモ

2年前から変わってないことと現状

  • SPAの考え方が定着してきた、どのフレームワークもそれらへのアプローチは大体できている
  • どちらかというとDX(Developer eXperience)向上の方向や低スペックマシンや不安定環境をカバーするアプローチにフィーチャーしている
  • 状態管理なども前は「やるべきか」という議論だったが、今は「どうやるか」にシフトしている
  • ブラウザがどんどん新しい機能を提供しているので、それに対してフレームワークはどう追従していくかという感じ。

「型」の浸透

  • 型の考え方がだいぶ浸透し、切っては切り離せないものになってきた
  • React流行でFlowTypeが流行り、TypeScriptとバトった結果、型の存在が認識されるようになり、浸透した。いまはTypeScriptが生き残り、Angularなども含め、みんなTS化している。
  • 型の概念が初心者の理解を阻害するかというのは意見がわかれるのでなんとも言えないところ

Lintについて

  • TSLintで厳しくするよりかはコンパイラでカバーするという考えだと必要性は薄れる
  • だんだんESLintにシフトできるのではないか、そのためESLintとしての重要性は減っていきそう

テスト

  • フロントエンドのテストはレイヤーが上がっていて、スナップショットやE2Eの精度も上がってきているし、StoryBookでやるなどもある。
  • コンポーネント志向の高まりで、コンポーネントは入出力があってればOKという形でテストができる

コンポーネント

  • コンポーネントの考える単位が変わってきた、昔は考えの拠り所がAtomicDesignぐらいだったが今はReact.lazyの登場などによりLazyLoadの単位で考えるということもできる。
  • デザイナーとどうやって歩調をあわせるかも難しくなってくる。デザイナーとプログラマではコンポーネントを考える粒度が違う。figmaでデザイナーが組み立てる場合もあるし、そこまで考えずにデザインしてもらいプログラマがバラすパターンもある。

StoryBook

  • StoryBookがコンポーネントの作り方のガイドラインのようになってくれている
  • カタログとしても機能するし、マネジメントなどの人にも見せやすい
  • 敷いて言うのであれば壊れやすいのがどうにかなってほしい

コンポーネントがリッチになる

  • コンポーネントがリッチになる時代が来そう
  • ただし行ったり来たりのようなもので、ある程度詰め込みすぎるとまたそうでない時代が来そうではある

非同期処理とObserbable

  • asyncやPromissなどの考え方はだんだん浸透してきてる
  • ObserbableもWeb標準としては動いていないものの、実装としてはDOMなどの考え方で使われてきており、浸透している気がする。

ServiceWorkerとPWA

  • PWA化するとまでは行かないが、オフライン動作用のためにあるみたいな立ち位置ぐらい。
  • PWA化以外の用途ではあまり使われなく、そこまで浸透していないなぁという印象
  • そのまま自力実装ではなく、何かしらラッピング実装をつかう感じ(WorkBoxJSやAngularServiceWorker)
  • 2018年のChromeDevSummitではどう作るかみたいなフェーズに来ていて、考え方的には定着しているが、あまり日本の事例はない。
  • どうしても日本の場合はiOSがあるので、別ドメイン認証ができない、ハードウェアバックキーがないゆえに戻るボタンをどこに置くか問題など、ユーザー体験の設計のしにくさから強く進めにくい部分がある。

WebComponents

  • Edgeの方針変更により、だいたいのブラウザでは実装されそう。
  • 一時期よりは過大な期待はされていないし、やっと環境として整ったのでこれからという感じ
  • CustomElementでアプリケーションを作るのは無理、というのはPolymerが一定証明してくれた。
  • Reactで作られたものをAngulerと組み合わせる、みたいな立ち位置として外界との協会としてCustomElementを使う感じになるのではないか
  • 現在iframeで実装しているものの代替としても活躍してれるのではないか

ESModule

  • 異なるフレームワークのものが乗っかるとBundlerが大きくなるという懸念もあるがそこらへんはキャッシュ周りが解決してくれる、という期待
  • WebPackでやるプロセスそのものは未来も変わらなそうだが、どんどん最適化はされていきそう
  • チャンクの分割とかはもっと最適化するとか体系的に組み立てるとかしてくれそう

LayerAPI

  • 初心者にはだいぶ考えることがおおく、使うのが難しい。
  • 使い所が難しく、また作れるもののイメージも付きづらいのでそこまで活用されなそう

Off The Main Thread

  • 一部の重い処理を逃してくとかはある、ただメインの処理をメインスレッド外にもたせるみたいのはまだイメージできない。
  • ReducerやWebFontを持ってくるところなどは適任ではないか
  • JSにマルチスレッドいるか?みたいな意見もありそうだが、やりすぎと言われたことが当たり前になっているので、これも当たり前になりそう

感想

  • React、Angular、Vue、Polymerに携わる人たちそれぞれの意見が聞けて面白いセッションだった
  • みんなStoryBook使ってるんだなーという印象、そこまで凝ったことをやるリソースがないけどやってみたくなる
  • TypeScriptもデファクトスタンダードになりつつあるのかなと思わせてくれた。
  • WorkBoxJSでなにかServiceWorker的なことをしてみたくなる。
  • PWAは来るのか?と思ったけど、結構iOSにおける阻害要因って多いんだなというのを知ることができたのも発見

関連リンク

Ad

当日見てなかったけど、ビデオ見てまとめた

shinkufencer.hateblo.jp

全体を通しての感想

  • 全部パネルディスカッションだったから結構聞くのにパワー使いましたがそれなりに学びもありました。
  • バックエンド寄りの話は結構監視や、考える関心みたいなところは似てきているなという印象でした。というよりサーバーサイドアプリケーションエンジニアは結構多くの領域を見る人と尖って見る人の二極化になっていきそうなという印象でした。
  • セキュリティや認証のセッションは学びが多く、考え方を改めないとなみたいな部分もありました。
  • フロントエンドは知識の再整理って側面が強かったですが、話し手が全員使っているフレームワーク違ったので、一つのフレームワークに偏ってなくてすごいよかったです。
  • 録画が出たら他のセッションもみたい…

Rubyなど ; で区切るワンライナーを作る時はブラウザのURL欄を使うと楽

何を言っているんだというタイトルだが今日は生活の知恵ぐらいの話です。

やりたいこと

例えばこんなコードがあるとする

a = 10
x_list = [1,3,5,7,11]
x_list.each { |x| p "#{a * x} is number" }

これをファイルを作らず実行したい。

やりかた

セミコロンをつける

まずは行が終わるための区切り文字である ; を付与する。改行に置換するなどすると早い。

a = 10;
x_list = [1,3,5,7,11];
x_list.each { |x| p "#{a * x} is number" };

ChromeのURL欄に貼る。

何をいっているかわからないと思うがやる

f:id:shinkufencer:20190113131810g:plain
こんな感じに改行が取り除かれる

ChromeのURL欄をコピーして、任意のテキストエディタに貼り付ける

そうすると下記のようになる。

a = 10; x_list = [1,3,5,7,11]; x_list.each  { |x| p "#{a * x} is number" };

ruby -e で実行できるように '' で囲む

ruby -e 'a = 10; x_list = [1,3,5,7,11]; x_list.each  { |x| p "#{a * x} is number" };'

完成。

利点

  • エディタで改行取り除けばいいのでは…?と思うが、トライアンドエラーで書いているときに大変じゃないですかとか向け
  • 満足な置換機能がないエディタが手元にないときでもできる

注意点

  • 簡易なものなら今の所問題ないが、長くなってくるとわからない
  • URL的にエスケープしちゃうような文字列だと期待値とずれることもありそう(今の所遭遇していない)
  • シングルコーテーションを意図的に外せないものは考慮外

『App Client Melting Pot #1』に行ってきたよメモ

App Client Melting Pot #1「設計」 に行ってきました。そして年始の誓いに沿って登壇をと思い、今回は懇親会LTにいれた、のでしたが…!

各発表の感想

FiNCのクライアントアーキテクチャを揃える試み

感想

  • iOSAndroidを並走させることにおいての知見の塊
  • Viewはバインディングできる素養が揃っているからMVVMで、ObservableをRxで実現するのは理にかなっている。
  • Rxのオペレーターって揃ってないんだっていうのは学び
  • ジェネリクスでResourceを作るのとても良いと思ったが、InProgressの進捗度は認識併せないと変な使い方しそうな気配がすごいした
  • ドキュメントでルール敷くよりもサンプルプロジェクトで敷くっていい考え方だなと思ったので、いろんな場面で使っていけそう

関連リンク


実践、BFF ~ BFFはFiNCのアプリで何を解決したのか ~

感想

  • 実は過去に見ている が改めて聞いて発見があった
  • 結構ネットワーク遅延(レイテンシ)を下げるために割と一個のAPIに盛り盛りにしがちだが、それで返って遅くなるケースってあるよねとか思った
  • ユーザ体験のトライアンドエラーをやるなら、Webにそれを寄せようという考え方は大切だなと思った。(おそらく今は面影なきMERYJSONでパーツを表現してそれをクライアントで組み立てるみたいな手法を紹介していた気がする ※情報ソースが藻屑になって消えたのでぼんやり)
  • BFFとのコミュニケーションコスト高いので、そこを自力解決は改めてやりたいけどできない決断なのですげーなという気持ち

関連リンク


2つの同期 4つの状態

感想

  • 同期の種類、頭では理解していたけどこうやって体系づけされていたのかという学び
  • ステートの種類も確かにコレぐらいに分類できるなという学び、ただPresentationが結構わかりにくさあるなと感じた。
  • 後半はStateを題材にしながらもGUIアーキテクチャの事例カタログ集みたいになってて読み返したくなるスライドでした。
  • あとラグランパンチ(だと思われるフォント)使うとメリハリついてよいなーと思った。

関連リンク


設計の話をする前にすり合わせしたい言葉

登壇した感想

  • まさかの繰り上げ通常枠での発表、直前打診されてびっくり。
  • 「みんな割と手堅い内容で来るはずだし、懇親会用だしあっさりしたものにしよう」とか思ってたので設計を語り合うまえに…みたいな感じに仕上げました。
  • JSONの話はウケてよかった。

関連リンク


パネルディスカッション

トークメモ

ロジックをサーバ、クライアント、どっちに置く?

  • 表示に関わることだからPresentationであるクライアントに起きたい…というのはあるがアプリはアップデートの兼ね合いがあるので難しい
  • 面白くない答えにはなってしまうがケースバイケース
  • エラーメッセージとか概念的にはViewだがサーバに持たせるかというところは悩みどころ
  • iOS/Androidはプラットフォームごとに表現のレギュレーションが違ったりするので、そういうロジックはクライアントが持つ、という考えもある

設計はどう決めたか

  • チームの練度や技量によって異なってくる
  • 設計は機能によって変わってくるので、機能を考えてアーキテクチャパターンを考える
  • 設計はレールである、盤石なレールは山手線のようなもので遠回りしてでも確実につくることができる。山手線の真ん中を通り抜けてショートカットするような中央線のようなものをつくりたい場合はそのショートカットした仕様を保つことができるのであればやればいいし、保つことができないのならやめたほうがいい。
  • やりたい事業に併せてつくっていくので、事業会社としては事業を成長させる設計が正解、という考えもある

設計のレベルアップをどうやっているか

  • 新しい設計パターンが出たらサンプルコードをやる
  • アーキテクチャができた経緯や真意を調べる、そこから自分の知ってる方法との差異や、どういう問題に対して生み出されたものかがわかる。ちゃんと調べたければ論文などにあたるとよい
  • 小さく始めて、大きくしたときに鞍替えできるかみたいな観点でやっておくとよい
  • パターンは問題解決のためのもの、パターンを覚えていき、いろいろ使うことで設計力をあげていく。

感想

  • 急遽行われたパネルディスカッション。自分の発表の後だったのでメモが結構半端だったのでちょっとぼんやりめ。
  • レールを使うのがいいのか悪いのかで山手線と中央線の例が出て、レールになぞらえて面白い話だった。東京在住の人なら使えるたとえ。
  • 知識の原点は論文やホワイトペーパーをあたるという行動はすごい大事だなと思っているので、そこらへんのリサーチ力あげたいなと思った。

関連リンク


全体を通しての感想

  • iOSAndroidの垣根を超えた勉強会って感じでしたが、自分みたいなエンジニアの人もいたので結構面白かったです。クライアントという観点でいけばJS的なところもいてもよさそう
  • しんぺいさんの話は聞けなかったのは残念でしたが、それが転じて自分としてはいい機会を与えていただきありがとうございます。という感じ
  • 懇親会も結構いろいろ喋れて、他の会社の作り方とかしれてよかった。次もあればひっそりと参加したい会でした。

他の方の感想とか関連リンク

『設計の話をする前にすり合わせしたい言葉』という内容で登壇してきました。

App Client Melting Pot #1「設計」で話してきたメモです。

発表したスライド

speakerdeck.com

設計する前にみんなで認識合わせよう、というスライド

伝えたかったこと

  • 言葉の認識ズレが、チームの認識ズレになるので、言葉の統一は図るべきという話(ドメイン駆動設計のユビキタス言語の整理と同じ)
  • 言葉の内容を理解していたとしても、実践したときにそれが体現できているかは別なので、分かる人がそれらの補正をしていくといいなという気持ちを込めた

登壇後記

  • 懇親会中のLT枠のつもりで気軽に書いたら、普通の枠と同じテンションでやることになったがそこそこ笑いがもらえてよかった…
  • ドメインとモデルの発祥を探したが、全然見つからない。モデルに関しては本当に言い始めた人が日本語情報だけだとよくわからなくて、最終的な落とし所がWikipedia
  • レイヤードアーキテクチャの事例は実体験をぼかしたものだけど、笑いが起きたのであるある的なことなんだな…という謎知見を得た
  • モデルに関しては色々ご意見出て参考になった。

qiita.com

関連リンク