#kansaits 1でTypeScriptのbuilt-in typesについて話します！

6/10に開催されるkansai.ts #1でTypeScriptに組み込まれている便利な型について話をします。 いつも通りスライドを公開しているので、もし興味あれば読んでフィードバックいただけると幸いです！ 不備や質問もTwitter @shisama_までいただけると助かります！

speakerdeck.com

kansaits.connpass.com

GatsbyJSで英語日記を構築した

英語で短めの日記を書くのをやりたくてgatsby-starter-blogでサクッと構築しました。 https://diary.shisama.dev にしましたが、DNSの設定もこの記事を書く直前にしたので浸透していないためにNetlifyドメインにリダイレクトされるかもしれません。

diary.shisama.dev

この日記は継続して英語をアウトプットする習慣を身につけることを目的にしているため、とにかく短くてもいいし内容もどうでもいい日常の内容とかにする予定です。
そのため、見た目とかもほぼデフォルトです。タイトルも日付でいくつもりです。あと自分で構築した静的サイトの場合、技術的に実験する場所にもできます。GatsbyJSの土台の上に乗っているとはいえ思いついたことをやりたいと思います。

この日記を構築するにあたって最初はgatsby-starter-lumenを使う予定でしたが、記事ごとに書くメタ情報(titleやdateなど)がやたらと多く、だるかったのでgatsby-starter-blogにしました。

github.com

ホスティング先はNetlifyで行い、pushすればビルド&デプロイされると思っています。
そして、Gatsby最高だよ。めちゃくちゃ速い。Lighthouseで計測したらPerfomance 94点でした。

続けていく中で躓いたことや解決策が見つかれば英語・日本語ともにアウトプットしていきたいと思います。 日本語のブログ(このブログやQiita)も継続して続けたいと思います。

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

Node.js v12の気になる変更点について話すかも #kng6

登壇予定だった方がやむを得ない事情により、急遽登壇できなくなってしまったのでNode.js v12の変更点を話すかと思い資料を作りました。
まだ、発表枠は空けていますが2日前に登壇枠が空いたので流石に応募する人はいないようで、前日の今時点で応募が無いのでたぶん話す。応募があっても時間の配分によりますが、たぶん話すと思います。

例のごとく発表資料は先に公開します。

speakerdeck.com

もし不備などがありましたら、ブコメか@shisama_にメンション飛ばしていただけると助かります。

チームに必要な「5つの法則」とチェックリスト / 『THE TEAM 5つの法則』を読んだ

GWは実家に帰省していました。同様に帰省していた弟が『THE TEAM 5つの法則』という本を持ってきていました。書店でも見かけたことがある表紙だったのでパラパラと読み始めると面白かったので一気に全部読んでしまいました。

『THE TEAM 5つの法則』
目標設定、人員設定、意思疎通、意思決定、共感創造、の5つの「チームの法則」を体系的に理解できるようになっている。https://t.co/DwIqpZRlMU pic.twitter.com/hobUZyjWfE

— shisama / Masashi Hirano (@shisama_) 2019年5月1日

この本はよく言われる「良いチーム」への誤解を主張するところから始まります。  

例えば「目標を確実に達成するのが良いチームだ」「チームはコミュニケーションが多ければ多い方が良い」「みんなで話し合って決めるのが良いチームだ」といった当たり前のように良いと思われていることに対して、実は時にチームが十分にパフォーマンスを出せない原因になり得ると主張しています。著者は「チームの法則」を用いることで、こういった誰もが持つ誤った認識を解消し、本来あるべきチームの姿をつくることができると主張しています。

その法則は「5つの法則」に分類することができます。

これら本書はこの5つの法則が章ごとに分かれて構成されています。気になる章だけ読んでも完結するようになっています。  

また、各章は「法則」「具体的事例」「チェックリスト」「学術的背景」で構成されており、好きなところから好きなところだけ読んでもいいようになっています。   このエントリでは本書のチェックリストをベースに読書メモを書き残しておきたいと思います。自分が後からチェックするのに使うためにこのブログに残しておきますが、このエントリを読んでくださっている方も読んでて気になるところがあれば気になった章だけでも本書を読むことをおすすめします。

Aim（目標設定）

チェックリスト

• チームの活動の意義が明確になっているか？

• チームの創出すべき成果が明確になっているか？

• チームは推奨している行動が明確になっているか？

• チームではかつどうの意義と創出すべき成果、推奨している行動が適切に接続されているか？

• チームが活動する意義、創出すべき成果、推奨されている行動を日常的に意識できているか？

メモ

チームのパフォーマンスは目標設定によって決まります。適切でない目標が設定されているとすべてが台無しになることもあります。  

目標設定には3つのレベルがあります。

• 行動レベルの目標設定

• 成果レベルの目標設定

• 意義レベルの目標設定

意義レベルの目標設定では最終的に実現したい抽象的な状態や影響を示したものです。意義レベルの目標にはチームのパフォーマンスにブレークスルーを起こす力があります。  

昔は行動レベル、成果レベルの目標が重視されてきましたが、時代とともに意義レベルの目標が重視されるようになってきました。意義レベルの目標設定にはGoogleやメルカリなどが導入しているOKRを使うことができます。

チームが何のために存在し、すべてのメンバーが意義目標を意識し、自発的に行動し成果をあげることが求められるようになってきています。

Boarding（人員選定）

チェックリスト

• チームの活動の特徴を語られるか？

• チームのメンバーには適切な多様性があるか？

• チームには適切な流動性があるか？

• チームに必要なメンバーの特徴を理解しているか？

• チームのメンバー集めやメンバー選びに貢献しているか？

メモ

環境の変化度合いや人材の連携度合いによってチームの特徴は変わります。チームにとって必要な人材を選定する前にチームの特徴を把握することが大切です。  

チームが置かれた状況に応じて多様なメンバーを集めるか均質なメンバーを集めるか変わります。どちらかに偏っている場合は採用基準を見直す必要があるのではないでしょうか。同じく状況に応じては固定のメンバーよりもメンバーに流動性がある方が良いときもあります。ビジネスの環境変化が速い今日では必要なときに必要なメンバーを選定できるようにしている組織であったほうがいいと言えるでしょう。

Communication（意思疎通）

チェックリスト

• チームはルールを明確化できているか？

• チームはメンバー同士がお互いの過去や特徴を理解するような機会を持てているか？

• チームは問題やアイデアメンバーが安心して共有できる雰囲気をつくれているか？

• チームメンバーの過去や特徴を踏まえたコミュニケーションを取れているか？

• チームメンバーに恐れや迷いなく自分が感じる問題やアイデアを発信できているか？

メモ

適切な緻密さを保ったルールを決めることでコミュニケーションコストを少なくすることができます。逆に過度なルールはコミュニケーションコストを増やします。コミュニケーションは多ければ多いほど良いチームであればルールを再設定したほうがよいです。無駄なコミュニケーションを減らして効率化する一方で、「お互いを理解するコミュニケーション」や「安心して意見が言える場づくり」は大切にする必要があります。心理的安全と相互理解に基づくコミュニケーションによってチームメンバー間の連携が取れて相乗効果を発揮することができます。

Decision（意思決定）

チェックリスト

• チームは状況に応じて最適な意思決定方法を選択できているか？

• チームはスピーディーに再現性のある議論ができているか？

• チームは意思決定者が孤独を恐れず決断できているか？

• リーダーの意思決定を自らの手で正解にすべく活動ができているか？

• 決断が必要なタイミングで「強く」「速く」意思決定ができているか？

メモ

まず、どのような方法で意思決定するか意思決定する必要があります。チームの意思決定には「独裁」「多数決」「合議」の3つがあります。状況に応じてスピーディーに意思決定する必要がある場合は全員で決めるより誰かが一人で決めるほうが良い場合もある。合議は時間がかかるのでスピーディーに意思決定するためには選択肢を用意します。まず選択肢を決める基準を決め、選択肢の優先順位を決めます。最後に優先順位に合致する選択肢を選択することで素早く意思決定できます。

「5秒で考えた手」と「30分かけて考えた手」は86％が同じ手なので5秒以内に打った方が良いというファーストチェス理論という考え方があります。これに基づくことでとにかく速く意思決定ができます。ソフトバンクの孫さんが実践しているそうです。

合議による意思決定に時間がかかる場合は独裁も必要です。そとのときに大切なことは意思決定者が反対や孤独を恐れずに決めること、しかしメンバーは意思決定者を孤独にしないことです。

「専門性」「返報性」「魅了性」「厳格性」「一貫性」を有したメンバーを意思決定者にすると意思決定の成功確率が上がります。

Engagement（共感創造）

チェックリスト

• チームでは金銭報酬や地位報酬だけでなく感情報酬がメンバーに提供されているか？

• チームではメンバーに何に共感してもらうかが明確になっているか？

• チームにはメンバーがチームの魅力を感じる仕組みが埋め込まれているか？

• 自分が何を求めてチームに参加しているかを明確にできているか？

• チームがメンバーの共感を生み出すことに貢献できているか？

メモ

すべてのメンバーがモチベーションに左右されるというのはすべてのチームにあてはまることです。モチベーションを高めるために4つのPがある。

• Philosophy（理念・方針）

• Profession（活動・成長）

• People（人材・風土）

• Privilege（待遇・特権）

4つのPすべてを提供することは難しいのでどれかに注力する。例えば、マッキンゼーはProfession、リクルートはあPeople、ディズニーはPhilosophyの魅力で束ねています。社内だけでなく社外にも魅力が伝わることで応募者とのミスマッチ防止にも繋がります。

今回は『THE TEAM 5つの法則』のチェックリストと読書メモを紹介しました。
チームのパフォーマンスに悩んでいる方や他の本で良いとされている方法がうまくいかない方におすすめです。

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

THE TEAM 5つの法則 (NewsPicks Book)

 

v-kansai Vue.js/Nuxt.js meetup #5でamp-scriptについて話します。 #v_kansai

AMP Conf 2019から気になっていたamp-scriptについてVue.jsを交えて話をします。 本番までに修正するかもしれませんが、以下資料です。

speakerdeck.com

もし不備や質問があれば、ブコメやTwitterで教えていただけると幸いです。

参考

• AMP Conf 2019 - amp.dev
• Keynote (AMP Conf '19) - YouTube
• Component: amp-script - amp.dev
• GitHub - ampproject/worker-dom: The same DOM API and Frameworks you know, but in a Web Worker.
• off-the-main-thread with WorkerDOM - Speaker Deck
• The glory of amp-script: Unleashing the kraken (AMP Conf '19) - YouTube
• amp-script: Add Vue.js TodoMVC example by niutech · Pull Request #21701 · ampproject/amphtml · GitHub

Node.js v12で使えるJavaScriptの新機能

Node.js v12が4/23にリリースされました 🚀

Node.jsのCoreにも新しい機能が入りました。 また、APIの追加以外にもTLS1.3のサポートやhttp_parserがllhttpに代わったりしています。 詳しくは以下をご覧ください！

github.com

JavaScriptエンジンであるV8もバージョンアップしています。
Node.js v10のV8のバージョンは6.8でしたが、Node.js v12では7.4に大幅アップデートしています。
V8のバージョンが上がることによりJavaScriptの使える機能や構文が増えます。
今回はMathias氏のツイートをもとにNode.js v12から使えるJavaScript(ECMAScript)の新機能について紹介したいと思います。

New JavaScript features in Node.js v12:

➡️ Array#{flat,flatMap}
➡️ class fields
➡️ globalThis
➡️ Intl.{ListFormat,Locale,RelativeTimeFormat}
➡️ Object.fromEntries
➡️ stable Array#sort
➡️ String#matchAll
➡️ Symbol#description
➡️ well-formed JSON.stringify

— Mathias Bynens (@mathias) 2019年4月23日

一部v11から使える機能もあります。
掲載しているコードはすべてv12.0.0で動作確認済です。

Array#flat

Array.prototype.flat() - JavaScript | MDN

ネストされた配列をフラットにします。以下MDNから引用です。

この機能はv11.14.0でも使えました。

Array#flatMap

Array.prototype.flatMap() - JavaScript | MDN

配列の値をmap関数でマッピングし、結果の配列をフラット化します。以下MDNから引用です。

この機能もv11.14.0で動作しました。

class fields

Classの中でプライベートフィールドが使えるようになります。 class fieldsについては以下の記事が参考になると思います。

developers.google.com

また、#が使われるようになった経緯をJxckさんが詳しく解説してくれています。

blog.jxck.io

動作確認済のコードは以下のとおりです。

コメントアウトしている箇所のようにプライベートフィールドの#countにアクセスするとエラーになります。

globalThis

globalThis - JavaScript | MDN

GitHub - tc39/proposal-global: ECMAScript Proposal, specs, and reference implementation for `global`

globalThisは環境を超えてグローバルオブジェクトにアクセスするためのオブジェクトです。
これまでブラウザではwindow、Node.jsではglobalがグローバルオブジェクトとして使われていました。
もちろんこれらは今まで通り各環境で使えますが、どちらでもアクセス可能なオブジェクトとしてglobalThisが追加されました。
globalThisを使うことで以下のような使い分けをする必要がなくなりました。

以下の記事も参考になるかと思います。

👻globalThis👻と🌏global🌏と🌝this🌝 - Qiita

Intl.ListFormat

Intl.ListFormat - JavaScript | MDN

配列を国ごとに形式を変えて文字列フォーマットしてくれるIntlの新しいAPIです。

Intl.Locale

GitHub - tc39/proposal-intl-locale: `Intl.Locale` specification [draft]

Intl.Locale

第一引数の文字列"pl-u-hc-h12"はUNICODE LOCALE DATA MARKUP LANGUAGEで定義されている形式に沿って記述します。最初のplは言語を表しています。英語であればenです。uはunicodeであること、hcはHour Cycleを表していてhc12は12時間周期であることを表しています。hc12は1〜12、hc23は0〜23といった具合です。例えば23時をフォーマットするときにhh:mm形式を指定すると11:00となり12時間周期にフォーマットされ、HH:mmは23:00と0〜23時の形式にフォーマットされます。hh:mmはhc12、HH:mmはhc23の形式を使っていることになります。

UTS #35: Unicode Locale Data Markup Language

Intl.RelativeTimeFormat

Intl.RelativeTimeFormat - JavaScript | MDN

これは言語によって時間表記を変換してくれる国際化APIです。
以下のコードを見るとわかるかと思いますが、jaを指定してformat関数に2日後を指定すると文字列"明後日"に変換してくれます。

Object.fromEntries

Object.fromEntries() - JavaScript | MDN

key, valueのペアの配列をオブジェクトに変換します。

stable Array#sort

v8.dev

Arrayのsortが安定ソートになりました。

安定ソート - Wikipedia

String#matchAll

String.prototype.matchAll() - JavaScript | MDN

正規表現にマッチするものをすべて取り出して配列にします。キャプチャした値も配列の中に含まれます。

Symbol#description

Symbol.prototype.description - JavaScript | MDN

Symbolの引数に指定した値を参照することができます。descriptionプロパティは読み取り専用です。

well-formed JSON.stringify

GitHub - tc39/proposal-well-formed-stringify: Proposal to prevent JSON.stringify from returning ill-formed strings

不正なサロゲートペアがエスケープされた文字列として出力されるようになります。

以前までは

JSON.stringify("\uD800");
// --> '"�"'

だったのが

JSON.stringify("\uD800");
// --> '"\ud800"'

になります。

最後に

今回はJavaScript(ECMAScript)の新機能を紹介しましたが、冒頭でも触れたようにNode.jsのCoreにも様々な変更が入っています。 v12がLTSになるのは10月末を予定しています。

github.com

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

『徳丸浩のWebセキュリティ教室』を読んだ

徳丸浩のWebセキュリティ教室

セキュリティの専門家として著名な徳丸先生が2015年に出版された本である。
170ページほどで薄めの本ながらWebのセキュリティに関して様々な事例や解説が紹介されている。
いくつか例を挙げると、XSSやSQLインジェクションやCSRFなどの説明やさくらVPSへの不正ログイン事件やGHOSTなどの事例をが書かれている。
本書序盤から度々出てくる「脆弱性はバグという意識を持つ」は開発者全員が意識しなければいけないと感じた。
あと発注者も意識が必要と書かれており、セキュリティ要件の提案と見積をRFPに盛り込んでおくことが勧められていた。
これにより発注側にもセキュリティ対策の責任を持つと開発者との責任のなすりつけ合いや逐一確認するといった無駄も省けて良さそうだと感じた。
またIPAの「安全なウェブサイトの作り方」や「セキュリティ実装チェックリスト」に沿って確認するのも勧められている。

www.ipa.go.jp

また「安全なウェブサイトの作り方」は2015年に改訂され、以下の脆弱性について詳細や対策を解説している。無料で公開されているので、セキュリティへの関心の第一歩として一読するのは良さそうである。

1. SQLインジェクション
2. 0Sコマンドインジェクション
3. パス名パラメータの未チェック/ディレクトリトラバーサル
4. セッション管理の不備
5. XSS(クロスサイトスクリプティング)
6. CSRF(クロスサイトリクエストフォージェリ)
7. HTTPヘッダーインジェクション 8.メールヘッダーインジェクション
8. クリックジャッキング
9. バッファオーバーフロー
10. アクセス制御や認可制御の欠落