別にしんどくないブログ

技術のことや読書メモを書いています

【資料公開】FRONTEND CONFERENCE 2019でXSSやセキュリティについて話します #frontkansai

2019-11-02 グランフロント大阪で行われるフロントエンドカンファレンス2019に『フロントエンドエンジニアのためのセキュリティ対策~XSS編~』というタイトルで発表します。
資料は公開しています。100ページ超えているので読むのが大変だと思います。(作るのも大変だったが・・・)
当日までに変更はあるかもしれませんが、大きくは変わらないと思います。マサカリ待ってます。

speakerdeck.com

スタッフとしても携わっているので当日はスタッフ兼登壇者ということであまり懇親会などには顔を出せないかも知れませんが、もし見かけたら気兼ねなく話しかけてください!質問やマサカリも待っています!!
発表をぜひ聞きに来てください!

2019.kfug.jp

そもそもこの話をするきっかけになったのは、Webは脆弱性と常に隣り合わせだなと日々感じることが多く、Webに関係するセキュリティ関係を調べていたところCSPやTrusted Typesなどブラウザのセキュリティ対策の機能に興味を持ち調べたためです。
CSP Lv.3はW3CのWorking Draftが出ていてTrusted TypesはChromeshipされようとしています

もし、お読み頂いている方でWebのセキュリティに興味がある方は仲良くなってください!色々教えてほしいです!

では当日お会いしましょう!お読みいただきありがとうございました。

関西Node学園 8時限目を開催しました。 #kng8

nodejs.connpass.com

サイボウズ(株)大阪オフィスにて開催しました。 Node.js v12がLTSになり、v13がリリースされたタイミングに合わせて開催しました。

当日の様子です。

togetter.com

登壇内容

Node.js v12のES Modules / @shimataro999

t.co

Node.js v12でES Modulesを使う方法や、CommonJSとES Modulesでの相互運用の話、importするファイルの拡張子の補完などについて話をしていただきました。

Node.jsではES Modulesを実験的にサポートしています。従来Node.jsはCommonJSというモジュールシステムを採用してきましたが、ここ数年Node.jsはWebの仕様に合わせていこうとしています。従来のCommonJSでのモジュール解決を破壊してしまうとnpmパッケージの多くが使えなくなる可能性があります。そのためNode.jsとしてもなかなかES ModulesをNode.jsでサポートするのに時間がかかっています。

資料中にも出てきましたが、以下の記事がNode.jsのES Modulesについて詳しく書かれています。

medium.com

Node.js v13の気になる変更点 / @shisama_

speakerdeck.com

10/22にリリースされたNode.js v13について話をしました。
内容は以下のブログに書いた内容と重複するので割愛します。

shisama.hatenablog.com

AmazonAPIGatewayのLambdaAuthorizerでJWTを検証するLambdaをServerlessFrameworkでデプロイする / @is_ryo

docs.google.com

API Gateway Authorizersで使えるLambda AuthorizerでのJWT(JSON Web Token)の検証を行う話をしていただきました。
JWKやjsonwebtokenを使ったJWTの検証、ServerlessFrameworkを使ったLambdaにAuthorizerをデプロイする方法について紹介してくれました。

serverless.com

私個人としてはこの辺はかなり弱いので、「そんなものがあるのか」と初めて知ることばかりでした。

今回紹介していただいた内容を踏まえたサンプルも用意していてもらっています。

github.com

Cloud Storage for Firebaseとセキュリティルール / @mochiya98

docs.google.com

FirebaseのCloud Storageにファイルを保存するときにメタデータに紐付かないファイルはアップロードを制限する方法について話をしていただきました。
Cloud Storageにはメタデータを付与してアップロードすることができます。しかし、クライアントが任意にメタデータを付与できてしまいます。任意ではなく、決まったメタデータ(例えば有効期限やパスワード)を必ず付与したい場合直接のファイルアップロードを禁止にします。ファイルのメタデータはFirestoreに保存しておき、アップロードはCloud FunctionsでAdminSDKから書き込みを行うことでファイルとメタデータの紐付けを担保するという方法を紹介していただきました。

Trying State Manegemant without Redux(updated) / @nkgrnkgr

speakerdeck.com

Reduxを使わずにReact HooksとContextで状態管理を行う話をしていただきました。
Reduxはコードが冗長になり、教育コストが高めということでReduxを使わずにReactだけでやってみようとしたとのことです。 ContextとuseStateを使うことでグローバルな状態管理を行うことができます。Contextを使いたいときはuseContextでContextを取り出すことができます。
また、useReducerを使うことでReduxと同じようにactionが発行するtypeによって処理を分岐させるreducer関数を書くことはできます。しかし、この場合はReduxの冗長さは解決できません。
また、Reduxはredux-thunkやredux-sagaなどのミドルウェアが便利なので使っているという方は多いのではないでしょうか。しかし、Reduxを使わないことでJSのファイルのサイズを抑えることができたり、冗長さを回避するように書くことができるメリットはあります。

asyncQuerySelector / @salamander_jp

docs.google.com

MutationObserverを使ったライブラリでターゲットのDOMが標示されるまで待つことができます。

デモページを用意してもらっています。

https://codepen.io/04/pen/ZEEKVyz?editors=1010

また、同様のことが可能なライブラリがあります。asyncQuerySelectorはこのライブラリを参考に作ったとのことです。

github.com

最後に

今回はNode.jsの発表もあり、LambdaやCloud Functions、フロントエンドの話など多彩な内容だったのが良かったと思います。
私も知らないことが多かったので勉強になりました。

今回、参加者(登壇者含む)が35名だったのに対してキャンセルが30名も発生してしまいました。プレミアムフライデーということもあってタイミングが良くなかったのかも知れません。
また、当日キャンセルせずに来られなかった方が6名ほどいました。

他の勉強会の主催者からも金曜日は避けた方がいいというアドバイスをいただいているのもあり、当日参加していただいた方々に何曜日が都合悪いかアンケートを取ってみました。 その結果、火曜と水曜がほぼ手が上がらなかったので、火曜と水曜に開催してみようかなと思いました。

関西Node学園では開場提供をしていただける方やJavaScriptやNode.jsに関わる発表をしていただける方を通年募集しています。
もし、興味がございましたらTwitterやshisama07@gmail.com宛にメールをしていただけると幸いです。

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

【資料公開】関西Node学園でNode.js v13について話します

nodejs.connpass.com

10/25に行う関西Node学園 8時限目でNode.js v13の変更点について話します。
昨日のブログで紹介した内容を発表します。

shisama.hatenablog.com

資料は公開済です。質問や不備がありましたらお手数おかけしますが、Twitterブコメ等で教えていただけると助かります。

speakerdeck.com

Node.js v13の主な変更点

Node.jsのv12がLTSになり、v13がcurrentとしてリリースされました。 ダウンロードは公式ページから行えます。

nodejs.org

今回はNode.js v13の主な変更点を紹介したいと思います。
以下リリースノートにあるNotable Changesからいくつかピックアップします。

nodejs.org

assert (PR: #28263)

assert.throws()またはassert.reject()でthrowされたエラーの検証にコンストラクターが使われた場合、throwされたエラーの代わりにAssertionErrorがスローされます。

コードで見た方がいいかもしれません。

gist.github.com

build (PR: #29887)

full-icuでビルドされるようになり、i18n系の機能ですべての言語をサポートしました。

Node.jsはこれまでビルド後のバイナリサイズの増加への懸念により、--with-intl=small-icuオプションを付けてビルドしていたバイナリを配布していました。
しかし、v13からは--with-intl=full-icuでビルドしたバイナリを配布するようになりました。
懸念されていたバイナリのサイズですが、macOSだと35MBから49MBになります。

オプションによる言語サポートの違いは以下の表のとおりです。こちらからも確認できます。

https://nodejs.org/api/intl.html#intl_options_for_building_node_js

挙動の違いに関するサンプルコードは以下のとおりです。

gist.github.com

v12以下(small-icuでビルドされたバージョン)はM01と出力しますが、v13以降(full-icuでビルドされたバージョン)はeneroと出力します。

console (PR: #29251)

console.timeEnd()console.timeLog()の結果がミリ秒ではなく時分秒の単位で出力するようになりました。

単位はh(時)、min(分)、s(秒)があります。

サンプルコードは以下の通りです。

gist.github.com

v12では3001.732msと出力されていましたが、v13からは3.001sと出力されます。

deps (PR: #29694)

JavaScriptエンジンのV8のバージョンが7.8になりました。

これによりObjectの分割代入のパフォーマンス、メモリ使用量、WASMの起動時間が改善されます。
詳しくはV8のブログを読んでください。

v8.dev

http (PR: #29589)

古いHTTPパーサーが削除されました。

v12からすでにデフォルトではllhttpが使われています。

github.com

しかし、--http-parser=legacyとオプションをつけてnodeを起動すると古いパーサーを使うことも可能でした。
v13からはEnd-of-Lifeとなりました。オプション自体が削除されました。

llhttpはTypeScriptで書かれたhttpパーサーです。

github.com

古いHTTPパーサーは保守が難しく、またアーキテクチャ上パフォーマンスに問題がありました。
llhttpは保守性向上のためにTypeScriptで書かれています。それをCのコードやビットコードに変換しています。
古いHTTPパーサーに比べてパフォーマンスはかなり向上しています。

Image from Gyazo

http, http2 (PR: #27558)

デフォルトのサーバータイムアウト時間が変わりました。

これまでサーバーのタイムアウトの時間はデフォルト2分でした
リクエストが完了するまでに2分以上かかる場合、ソケットは閉じられ空のレスポンスを返していました。
そのため、画像の変換やサイズが大きいファイルのアップロードなど処理に時間がかかる場合、処理の途中でリクエストが閉じられることがありました。
これまでも--http-server-default-timeout=millisecondsオプションを使うことでユーザー側でもこの時間を変更することは可能でした。0に設定することでサーバータイムアウトを無効にすることもできました。

v13からはデフォルトで0が設定されるようになりました。つまりサーバータイムアウトが無効になりました。

ES Modules (PR: #29866)

まだWIPでリリースされていませんが、ES Modulesもv13からフラグなしで使える予定になっています。
Node.js v12にもマイナーバージョンの更新(12月か3月ごろ?)でバックポートする議論もされています。

New Release Plan · Issue #400 · nodejs/modules · GitHub

最後に

今回紹介したのは一部の機能になります。自分が気になった変更をまとめただけですので、他にもすごい変更点はあるかもしれません。

Node.js v13は2020年6月でEnd-of-Lifeになる予定です。
次のNode.js v14は例年通りだと2020年4月にリリースされ10月末にLTSになる予定です。今回紹介したv13の機能も含まれます。

https://raw.githubusercontent.com/nodejs/Release/master/schedule.svg?sanitize=true

最後までお読みいただきありがとうございました。質問や不備はTwitterブコメなどでお願いいたします。

【資料公開】#v_kansai 11でVue.jsのパフォーマンスについて話します。

vuekansai.connpass.com

京都Devかふぇ#7〜Vue.jsLondon2019参加報告会(非公式)〜【v-kansai共催】 - connpass と共同開催みたいで、こちらの参加枠はまだ空いているのでお時間あればぜひ。

表題のとおり、v-kansaiでVue.jsに関するパフォーマンスTipsについて話をします。本当はWorkerDOMの話も盛り込みたかったが時間が足らなかったのでまたどこかで...。
言い訳がましい感じになりますが、転職してからVue.jsを触っていないので、もっと良い方法はあるかもしれません。マサカリ待っています。

speakerdeck.com

参考にした記事

今週末のVue Fesは参加しないですが、台風は来ないであげてほしい。参加数1400名の大規模カンファレンスということもあり、運営さんは気が気じゃない想いだと思います。

ウェブリオを退職しました。「いい話」から5年経ったいま

この記事は念の為元上司に査読していただきました。

2019年8月末でウェブリオ株式会社を退職します。
ウェブリオはオンライン辞書サービスを運営する会社です。

インターネット上にウェブリオの中の人の声や退職エントリは少なく、ウェブリオに入社しようと考えている人にとって情報が少ないと思いこの記事を書くことにしました。ウェブリオへの入社を検討されている方に参考になれば幸いです。

「いい話」

とても多くの人に読まれたウェブリオの退職エントリがあります。
以下の記事ははてなブックマーク数1000を超え、「ウェブリオ 退職」で検索すると検索上位に出てきます。
そのため、ウェブリオに入社を考えている人は一度は読んだことあるかと思います。
便宜上、本記事では「いい話」と呼ばせていただきます。

takeda25.hatenablog.jp

しかし、5年前の記事で情報が古くなっています。

その後W社の社風や開発者の扱いに変化があったかどうか等についてご自身で最新の情報を得ていただければと思います。

と「いい話」の冒頭にもありますように、本記事ではウェブリオの現在についてお伝えできればと考えています。
これから書くことはあくまで2019年時点の情報です。もし数年してこの記事を読んでいる人がいれば参考になさらずご自身で最新の情報を探していただければと思います。

「いい話」から5年経ったウェブリオのいま

この節では「いい話」を読まないとわからない内容が含まれています。

「いい話」が投稿されたのが2014年4月で、僕が退職したのが2019年8月なので5年が経過しています。
そのため、会社の中は変わっています。
もちろん「いい話」に対して批判を書くつもりはございません。 というのもこの方とは在籍期間が重なっておらず、全く面識がありません。また、在籍していたオフィスも違います。
そのため「いい話」に関しては真実かどうかも判断できません。 ちなみに僕は「いい話」の流動性には共感する部分があります。

実質上司について

まず、「いい話」に出てくる実質上司はすでに退職しています。
僕が入社した2016年8月時点ですでに退職されていました。
「いい話」に登場するエンジニアの方々はすでに全員退職されています。
現在在籍するエンジニアの中には「いい話」に出てくるような性格の方はいないかと思います。

OSSについて

MIT ライセンスの JavaScript 外部ライブラリを使おうとすると、「使っても問題ないか調査してください」と言われ、またできれば外部のものは使わずに実装してほしいと言われた。

OSSのライブラリについてはむしろ使っていきましょうという雰囲気です。
ウェブリオ自身もGitHubにMITライセンスでソースコードを公開しています。

github.com

役員との関わりについて

偉い人レベルでの、従業員は使い捨て可能・交換可能な部品であるという見方。

これについては私は結構大切にしていただいていた方だと感じています。
意見を尊重してくれましたし、最終出勤日に営業部の幹部の方から労いの電話をいただいきました。
人によっては合う合わないありますが、幹部の方と従業員の距離は非常に近いです。
また、意見をする人を尊重・評価する傾向があり会社に意見はしやすかったです。

良かったところ

ここから先は「いい話」とは関係なく、私がウェブリオに感じたことを書いていきたいと思います。
私自身の体験や感じたことに基づくので、違った意見や考えもあるかもしれませんがそれは他の社員の方が書いてくれることを期待しています。

働く環境について

働きやすさ・風通しの良さを求めている人にはウェブリオはおすすめです。 「いい話」にも出てきましたが、残業は本当に少ないです。有給休暇も1時間単位で取れました。申請こそありましたが、却下されることはありませんでした。これが個人的には一番最高でした。
10:00〜16:00コアタイムのフレックスだったので、僕はたまに朝1時間の有給をとって11:00に出社していました。朝起きて「11時に出勤します」とメールするだけなので、有給のとりやすさは抜群に良いかと思います。
非常に働きやすい環境かと思います。子育て、コミュニティ活動、OSS活動を並行して行えたのはこの働きやすさがあったからだと感じています。

学習支援について

技術書やビジネス書などの書籍は申請なしで購入することができました。各々がAmazonでポチるだけです。申請はいりませんでした。
備品も正当な理由があれば購入してもらえます。
勉強会やカンファレンス参加も業務として行くことができ、参加費用や旅費を出してくれる制度もあります。
地方に住んでいるエンジニアとしては東京で行われるカンファレンスに参加しやすかったです。
そういった学習支援を重視している人にとっても良い会社だと思います。

良くないと思うところ

評価について

マネジメントよりコードを書き続けたいタイプの人にはおすすめしません。コード書いてるよりマネジメントしてる方が評価される傾向があるように感じました。成果を出し続けている技術力ある人よりマネジメントしている人の方が評価されていました。私の推測ですが、幹部にエンジニア上がりの人やCTOのような技術のわかる人がいないのが原因なのかなと思いました。これは幹部の人も対応しようと考えていてリーダークラスのエンジニアの意見を評価の参考にするなど技術に対して評価できるように試行錯誤しているようにも見えました。

給料について

給料は低いです。私は給与テーブル上の平社員ではそこそこ上のほうにいたと思いますが、年収450万円弱でした。そのため、ほとんどの社員が400万円台なのではないかと推測できます。私自身転職ドラフトの指名額などを参考に市場価値に合った給料をいただけていないことを把握していました。
これはウェブリオに限った話ではないですが、市場価値に合わせた待遇にしなければ良い人は採用できませんし社員は辞めていくと思います。
ウェブリオもこれについては人事を中心に考えていると思います。一気に給料UPはなかなか難しいと思いますが、少しずつでも改善されると期待しています。

ちょっと話がそれますが、報酬の総定額を採用プロセスの早い段階で言ってしまった方がいいんじゃないかなと思います。内定出してから報酬を伝えることが多いですが、その時点で大きくズレが生じていて辞退することになることは珍しくありません。双方にとって面接などにかけた時間とかもったいないと思うんですよね。その点、最初から金額がわかっている転職ドラフトは良かったです。転職ドラフトに限らず、今回オファーいただいた企業は最初に参考値を提示してくれました。大変助かりました。

退職理由

転職前に昇進の話をいただいてて給料も上がるし評価もいただいてたので、上記の理由が直接的な退職のきっかけになったわけではありません。優秀な方々が徐々に辞めていったことが大きかったです。他の人の退職に関しては様々な理由があるのですが、ここでは控えさせていただきます。
優秀な人が退職していきだんだんと楽しさを失ってたときに、ある企業からお誘いいただいたのが直接的な退職のきっかけになりました。
もちろん給料も前述の通り市場価値に沿った金額をいただきたいと考えていました。

最後に

「いい話」が書かれてから5年経ってウェブリオ内部の変わったところや私が感じたことを書きました。
色々書きましたが私はウェブリオに入社して良かったと考えています。子をもつ身としては働きやすかったですし、自由に色々させていただき成長につながったと思います。
もし興味があれば、応募してみてください。

www.weblio-inc.jp

次はサイボウズ株式会社のフロントエンドエキスパートチームで働きます。こちらも興味があればご応募お待ちしております!

cybozu.co.jp

退職のタイミングでなくてもいいのですが、会社のことを社外に発信することで採用のミスマッチを防ぐことができるかもしれません。どんどん発信していくべきだと思います。
この記事がウェブリオに入社しようか考えている人にとって参考になることを願っております。

最後までお読みいただきありがとうございました。質問などはTwitter宛やコメントなどでお願いいたします。

『たいていのことは20時間で習得できる』を読んだ / 効果的学習のための10のルール

この本は超速でスキル獲得するためのTipsが書かれた本である。
要約すると、習得したいスキルをできるだけ細かくサブスキルに分解し、少しのリサーチ時間と最も重要なサブスキルに20時間を費やすというものです。
最も重要なサブスキルに集中して習得することで、その後の学習効率が大きく変わるということ。
もし、重要なサブスキルを身に着けて満足であればそこでやめてしまってもいいのだ。

本は理論編と実践編で構成されており、実践編はヨガやプログラミングと具体的なスキルの習得について書かれている。
そのため、実践編は習得したいスキルのところだけ読めばいいだろう。この本自体は理論編が70ページほどで実践編も、例えばプログラミングだと、80ページほどしかない。そのため、読むのには時間がかからないだろう。

理論編では「超速スキル獲得方の10のルール」と「効果的学習のための10のルール」の2つのチェックリストについて紹介されている。
特に「効果的学習のための10のルール」のほうが気になったので今回は「効果的学習のための10のルール」の方を重点的にメモを残しておきたいと思う。
「超速スキル獲得方の10のルール」に関してはルールだけ記載しておく。

超速スキル獲得方の10のルール

  1. 魅力的なプロジェクトを選ぶ
  2. 一時に一つのスキルにエネルギーを集中する
  3. 目標とするパフォーマンスレベルを明確にする
  4. スキルをサブスキルに分解する
  5. 重要なツールを手に入れる
  6. 練習の障害を取り除く
  7. 練習時間を確保する
  8. すぐにフィードバックが返ってくる仕組みをつくる
  9. 時計のそばで一気に練習する
  10. 量と速さを重視する

効果的学習のための10のルール

  1. スキルとそれに関連したトピックについて調べる
  2. わからなくてもやってみる
  3. 心的モデルと心的フックを知る
  4. 望んでいることの「逆」を想像する
  5. 実際にやっている人の話を聞いて予想を立てる
  6. 環境から気が散る要素を取り除く
  7. 覚えるために間隔をあけて反復と強化をする
  8. チェックリストとルーティーンを設ける
  9. 予測を立て、検証する
  10. 自分の生物学的欲求を大切にする

1. スキルとそれに関連したトピックについて調べる

20分かけて習得しようとしているスキルと関連がありそうな本やDVDなど資料を少なくとも3点見つけること。ここでの目的は、最も重要なサブスキル、重要な構成要素、必要なツールを知ることである。スキルについての広範な知識をてっとり早く集め、全体像をつかむこと。

2. わからなくてもやってみる

初期リサーチの段階では理解できないことが多いが、経験を積むと同じ情報が理解可能になる。また、混乱を認識すること自体が、理解の一形態である。具体的に「何に」混乱しているのかはっきりさせ、それを解決するために次に調べること、するべきことを理解することにつながる。練習をすればわかるようになると自ら言い聞かせることで、混乱から理解へと最速で進むことができる。

3. 心的モデルと心的フックを知る

心的モデルとは、繰り返し登場する概念や技術であり最も基本的な学習単位である。存在するモノ、あるいは関係性を理解し、分類する手段である。
心的フックとは、新しいことを覚えるときにすでに知っていることと類似性や比喩を用いて理解することである。
初期リサーチで心的モデルや心的フックをたくさん集めておけば、特定の行動をしたとき次に何が起きるか予測しやすくなる。

4. 望んでいることの「逆」を想像する

「反転」という問題解決の手法で、物事の本質を理解するのに役立つ。望んでいることの逆を調べることで、一見気づかない重要な要素を特定できる。
行動するときに、何もかも失敗したら何が起きるかを頭の中でシミュレーションしておくことで必要なモノや行動がはっきりわかる。

5. 実際にやっている人の話を聞いて予想を立てる

目標とするスキルを既に身につけいている人に話を聞き、上達にともなってどのような変化が期待できるか、予め知っておくことができる。そうすることで練習中に興味を失わず、モチベーション喪失を防ぐことができる

6. 環境から気が散る要素を取り除く

気が散る原因は、電子的なものと生物学的なものに分類できる。電話、インターネットなどの電子的なものは電源を切る。悪気のない家族、同僚などの生物学的なものは事前に知らせて邪魔をしないようにお願いをする

7. 覚えるために間隔をあけて反復と強化をする

忘却曲線を理解し、間隔を置いて反復と強化をすることは、重要な概念や情報を定期的かつ体系的に学習するのに役立つ。このテクニックは情報をすばやく思い出すのが大切なスキルに有効である。

8. チェックリストとルーティーンを設ける

たいていのスキルには何らかの決まった手順がある。練習のたびにしなければならないことを確認するにはチェックリストを使う。これはプロセスを体系化し、もっとも重要なことに注意を集中できるようにする。
ルーティンは、スキルの練習に毎日同じ方法で取り組めるようにする構造だ。
チェックリストやルーティンをつくることで、効率よく練習できるようになる。

9. 予測を立て、検証する

予測をたて検証する習慣をつけること。そのために予測や試行錯誤の結果はノートなどに記録しておく。

10. 自分の生物学的欲求を大切にする

最適な学習サイクルは約90分、それより長くなると頭も身体も自然と休憩を求める。無理をせずに休憩をとるほうが生産的である。練習を始めるまえにタイマーを設定することで忘れずに休憩を取るようにする。必要であれば練習時間を細かく区切って20分練習して10分休憩といった具合でもいい。

最後に

すべてのスキル獲得のために10のルールが必要ではないかもしれないが、10のルールをチェックリストとして使うことで効果的な学習に役立つと思う。