コード日進月歩

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

『次世代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でラップしてしまう。

言語の選択

  • 各種ミドルのクライアントライブラリがしっかりしていないとつらいので、そういう意味だとAWSやGCPが対応している言語がよかったりする。その流れだと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が追加されている
  • 普通の使い方であればRFC6749とRFC6750を抑えておけばいい
  • もっとセキュアな使い方をしたければ他の部分を読んで実装すればいい
  • 普通の使い方も、厳格な使い方もできる。

認証と認可

  • 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

全体を通しての感想

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