radioc@?

レディオキャットハテナ

【勉強会メモ】心理的安全性ゲームを体験してみる

devlove-kansai.doorkeeper.jp

いつもお世話になっているDevLove関西で心理的安全性ゲームを体験する勉強会が開催されました。SFO2019 開催前日で私も登壇準備でそわそわしていましたが、考案者のやっとむさんを招いて開催されるとのことだったので参加してきました。

心理的安全性ゲームとは?

チームでまずい状況が起きた時のメンバーの反応をシュミレーションするカードゲームです。

心理的安全性ゲーム」では、マズい状況に対する様々な反応を体験して、チームにおける心理的安全性の意味と作り方の理解を深めます。

ゲームの進め方

スライドが公開されていますので詳細はそちらを確認。

docs.google.com

実際にやってみた流れをざっとまとめておきます。

チームを作る

4,5人のチームを作ります。仕事上のチームと仮定して仕事のテーマを決めます。

f:id:radiocat:20190222005719p:plain

カードの準備

2種類のカードがあります。どちらも事前にシャッフルしておきます。発言カードの中にはさらに発言とOptionの2種類のカードがありますが混ぜてシャッフルします。

  • 発言カード
    • 1人にチームの人数分のカードを配る(4人のチームであれば1人4枚)
    • 余ったカードは山を作ってテーブルに置く
  • 状況カード
    • 山を作ってテーブルに置く

まずい状況を発生させる

  • 「平和を乱す役」の担当を決めて状況カードを1枚引く
  • 引いたカードをその状況の人になりきって読み上げる

まずい状況に反応する

  • 残りのメンバーが自分の手持ちの発言カードの中から1枚のカードを選んで反応する
  • 手持ちのカードの中にOptionカードがある場合は発言と一緒に出すことができる
    • Optionには態度が書いてあり、発言に合わせた態度をとりながら反応する
  • Optionカードを使った場合は残っている発言カードの山から1枚取って手持ちに追加する

未来のチームのすがたを想像する

  • 「平和を乱す役」の人は全員の反応を聞いたうえで自分がどう感じたかを共有する
  • 「平和を乱す役」の人は自分が感じた「未来のチームのすがた」の該当する場所に石を置く(該当するものすべてに石を置いて良い)

隣の人に担当を交代して繰り返す

  • 「平和を乱す役」の担当を隣の人に交代して同じことを行う
  • 時計回りで1周するまで続ける

やってみた

私は「大事なアポをすっ飛ばしちゃった!」という状況カードを引きました。なかなかひどい反応を頂きました。。

f:id:radiocat:20190222010444p:plain

交代して進めていくと徐々に気の利いた反応が返せるようになりました。しかし、手持ちの発言カードは限られているのでいつでも良い反応が返せるわけでもありませんでした。一見、良さそうな発言カードを持っていても起きた状況によっては出しにくい場合もあります。

f:id:radiocat:20190222010704p:plain

アレンジしてやってみた

2回目はチームのメンバーそれぞれにキャラ設定をしてその人になりきってやってみました。「やり手の営業マン」とか「豪腕社長」とか何でもOKです。私は「陽気なおかあさん」キャラをやってみました。また、発言カードも意図的に気の利いた良さそうな発言ばかりを配ってみました。

おかあさんキャラだと意外とどんな発言カードでもなんとなく優しさを感じて発言だけでなくキャラによっても反応は変わってくることがわかりました。

一方、気の利いた良さそうな発言でも、キャラや状況によってはあまり良い反応にはならないこともわかりました。

f:id:radiocat:20190222011538p:plain

最後にふりかえり

最後にこのゲームを通しての心理的安全性についての学びを会場の全員で共有し合って終わりました。思いついたすべてを付箋に書いて壁に貼り、最後にその中から一番印象に残ったものを1つ選びました。私が選んだのは「母強し」です。

f:id:radiocat:20190222012741p:plain

補足:サイレントソーティング

最後に全員分の付箋を壁に貼った時に、類似のものはグルーピングして並び替えを行いました。この時に使った手法が「サイレントソーティング」と言うらしく、黙って一人ずつ交代で、1枚だけ付箋を選んで移動させていきました。みんなで同時にやると議論になって収集がつかなくなるのを避けるやりかたなのだと思います。わりとスムーズに並び替えが終わって、どこかで使えそうな手法だと感じました。

f:id:radiocat:20190222000945p:plain

【勉強会メモ】Mobile Act OSAKA #8

mobileact.connpass.com

  • 日時:2019/02/15(金) 18:40 〜 21:30
  • 場所:Osaka Innovation Hub (大阪イノベーションハブ)

いつもお世話になっているフェンリルさんのMobile Actです。懇親会でのビールのこだわりが最高です。

How I develop Sketch Native Plugin

griffin_stewie さん

speakerdeck.com

遅刻して聞けなかったので資料のみです。

ReactorKitでテストしやすくする

usami-k さん

speakerdeck.com

github.com

Testabilityに注目

  • Viewの責務
    • UI操作→ActionとしてReactorに渡す
  • Reactorの責務
    • Action→処理を行いStateを生成する
  • Viewの責務
    • State→UIに表示する

View

Reactorの処理

mutate()

  • Actionを受け取ってMutationを返す
  • 具体的な処理を行うObservableを生成
  • 実際に処理を行うかどうかの判断などはReactor
  • Viewがシンプルになる

reduce()

  • Mutaitonと前のStateを受け取ってStateを返す
  • View側では前の状態を考慮しなくて良い

Viewの単体テストを考える

「オブジェクトの責務を果たしているか」をテスト

  • UI操作⇒Action
  • State⇒UI表示

Actionのテスト

  • コードでUI操作を発生
  • ReactorにActionオブジェクトを渡されたことを確認
  • Reactorのスタブを用意
    • ReactorKitで用意されている

Stateのテスト

  • やはりReactorのスタブ

Viewのテストまとめ

  • Viewが責務を果たしている
  • Viewの実装としてはバインディングがちゃんとできている
  • Testability向上でシンプルになった結果単純すぎてテスト不要ではというレベル

Reactorの単体テスト

  • そのオブジェクトの責務を果たしているか
  • コードでActionを発生させてStateをテスト
  • Reactorの中でWebAPI実行
  • データベースアクセスなどがあると単体テストしにくい
  • Serviceとして外に切り出してスタブ化

まとめ

  • ReactorKitでViewとReactorの責務を分離
  • ViewやReactorのテストが可能

学生スタートアップがマイクロビューコントローラーを導入してみた話

nade さん

speakerdeck.com

背景

  • iOS開発2名、デザイナ1名
  • とにかくスピード感がほしい
  • 非同期作業
  • スクラップ&ビルド

数日後⇒大規模なリファクタリング

  • UIを追加しづらくなる
  • 勉強&教育コスト

Fat View Contorllerの闇に落ちていく

→巨人の方の上に乗る

MicroViewController

github.com

UIパーツそれぞれをViewControllerで作ってしまう

ViewControllerに3つのプロトコル

ContainerViewで実装

  • ライフサイクル・画面遷移コードが分割
  • レイアウト時間が短縮
  • クロスアーキテクチャで実装可能

恩恵

  • 開発速度:体感3倍
  • 1ViewControllerのコード:500くらいまで
  • パフォーマンス向上

iOS/Androidでドキュメントスキャナーを作ってみた

itok さん

speakerdeck.com

PDFカメラ

  • カメラで書類を撮影
  • 撮影した写真から切り抜く範囲を調整
  • 必要があれば回転
  • 1〜3ページ分繰り返して最後に画質を指定してPDFとして書き出す

技術要素

  • 矩形認識
  • 矩形切り抜き
  • PDF書き出し

矩形認識

  • カメラプレビュー表示
  • リアルタイムで認識された矩形を重ねて表示
  • 検出された矩形の中で一番大きなものを採用
  • 撮影ボタン→画像

Android

iOS

  • AVKit framework
  • Vision framework

矩形切り抜き

  • ユーザー操作で切り抜き部分を調整
  • 切り抜き+台形補正

Android

iOS

  • CoreImage framework

PDF書き出し

  • 指定された画質で書き出す
  • A4orレターサイズに収まる感じのサイズに調整
    • 北米はレターサイズ
    • それ以外はA4

Android

  • Apache PDFBox
  • 標準のPDF APIは画像の圧縮が効かなかった

iOS

  • UIGraphicsBeginPDFContextToFile
  • UIGraphicsBeginPDFPageWi

雑感

  • 矩形認識はiOSVisionが圧倒的に楽で早い
  • カメラの向き変換が相変わらず面倒
  • カメラプレビュー、撮影画像、UI間の座標変換も相変わらず面倒

Material Themingを使ってみよう

Kazuki Watanabe さん

speakerdeck.com

Material Designとは

Material Theming

  • Material Designをカスタマイズしてアプリの個性や世界観を出す
  • 属性(Color,Shape,Typography)を決めることでプロジェクトのテーマが作れる

Color

Shape

  • 角を切ったり丸めたりした形

Typography

  • H1,H2,H3,H4...

Material Design

Color Themingの適用

  • <color>

Shape Themingの適用

  • Small Components
  • Medium COmponents
  • Large Components

Typography Themingの適用

  • フォントの適用

最後に

  • 表現できる幅が広がった
  • AndroidだけでなくiOS、Flutter、Webでも利用できる
  • たくさんのUI Componentsが利用できる

Managed App Configuration について 〜MDMiOSアプリ設定の配信〜

oishi さん

  • Managed App Configuration
  • MDM(Mobile Device Management)

クラウド型サービス

  • 設定を流せる
  • アプリを消しても入れ直す
  • アプリの中の設定は配信できなかった

App Storeのアプリやインハウスアプリを登録

暗号化されないのでパスワードなどは設定しないように

イテレーションとRustで見るSwiftの所有権

hokuron さん

speakerdeck.com

Ownership Manifest

  • 所有権に関する提案や考察
  • 実装の優先順位
  • 今後仕様が変わることもある

イテレーションにおける所有権

  1. 不変イテレーション
  2. 可変イテレーション
  3. 消費イテレーション

不変イテレーション

  • イテレーションの中で要素を変更しない
  • 要素の取り出しにコピーが発生しない
  • Arrayなど内部にストレージを持つ型はイテレーションの中でArrayそのものを変更できない

可変イテレーション

  • イテレーションの中で要素を変更可能
  • 要素の取り出しにコピー不要
  • Arrayの場合排他アクセスが発生
  • Arrayにアクセスができない
  • NSArrayなどの参照型Arrayには適用されない

Rustにおける共有参照・可変参照

  • 共有参照
    • 共有参照としての借用が終わるまで可変操作(借用)ができない
    • 参照中にもとの値が変更されないことを保証
    • 安全
  • 可変参照
    • 可変参照としての借用が終わるまで別の借用ができない
    • 変更中の値が使われないことの保証
    • 安全

消費イテレーション

  • for in →いつものイテレーション
  • non-copyable型から要素の所有権を得る
  • Sequence protocol
    • 破壊的な消費をしながらのイテレーション
    • 1度目とそれ以降が同じになるとは限らない

Rustにおける消費イテレーション

まとめ

不変イテレーション

  • 変数を shared で宣言
  • nonmutaiting な操作
  • 可変操作ができない
  • Rustは安全

可変イテレーション

  • inout で宣言
  • ループ中でコレクションにアクセスできない
  • Rustは安全

消費イテレーション

  • 変数をownedで宣言
  • Rustは安全

まとめ

  • Rustは安全

【勉強会メモ】スクラム道関西 第117回オープン・ジャム

scrumdo-kansai.connpass.com

  • 日時: 2019/02/12(火) 19:00 〜 21:00
  • 場所:株式会社ラクス 大阪オフィス

いつもお世話になっているスクラム道関西のオープンジャムを弊社にお招きすることになりました。昨年秋にオフィスが移転してイベントができるスペースができて、駅からの近くなったのでいつかこのようなイベントに使ってもらえるといいなと思っていましたが、こんなに早く実現できるとは思いませんでした。 今後もタイミングが合えば利用して頂けると嬉しいです。

今回のテーマはこちら。

f:id:radiocat:20190213015201p:plain

品質管理

  • 品質検査、カバレッジエビデンス取得など社内ルールが厳しい会社がある
    • 社内基準を満たすためにはやることが多くスプリントの枠組みで終わらせるのは難しい
  • スプリントでまとめて作ってまとめてテストしてしまうとミニウォーターフォールになってしまう
  • 出荷前に社内基準に合わせた作業を行うリリーススプリントというやり方もある
  • 出荷可能な状態を維持することを考えるとスプリントごとに社内ルールに合わせるしかない

メンバー増やす時の注意点

  • 同時に増える場合も少しずつ増える場合も9人以上は厳しい
  • 増員が頻繁にある会社でも一度に2人までにして、3ヶ月は間隔をおくようにしている
  • 増えたメンバーの立ち上げが大変
    • 1ヶ月ぐらいはリグレッションテストをやってもらう
      • 直近に参画したメンバー同士でテストのやりかたを教え合う
    • 1ヶ月ぐらいはキャパシティには含めず必ず既存メンバーとペアプロしてもらう

リファインメントで毎回同じことを話してしまう

  • 定期開催しているリファインメントで既に開発T内で合意済みのことを再度議論してしまうことがある
  • 定期的な開催をやめて日々少しずつリファインメントしてみたら良いかもしれない
  • POが議論に絡めているか?
  • 何度も議論になるなら誰かが合意事項に納得できていないのかもしれない

レビューが通らない

  • チームの熟練者から必ずレビューの差し戻しを受ける
  • 何度か差し戻されたらペアプロ、モブプロに切り替える
  • 品質に影響がない内容ならいったんレビューは通して後日モブプロでリファクタリングする
  • 熟練者の知識・知見を共有することが大事
  • 答えを教えると身につかない、何度も教えることになる
  • 自分で気づいて学ぶまで時間を与える教育法もあるが時間がかかる
    • 時間を与えても学べるとは限らない
    • 時間を与えた結果意図しない方向に学習が進むかもしれない
  • 時間を与えるよりも、何度も教えるほうが結果的には早く学習するのではないか

ドキュメントの残し方

  • 社内ルールが厳しく残さないといけないドキュメントがたくさんある
    • 監査のために必要で作らないわけにはいかない
    • 会社によってまちまちで、なるべく作らない会社もある
  • 特にルールは決めていないが知識の共有のために最低限必要なものはドキュメントを作る
  • 新しいメンバーなど、引き継ぎのためにドキュメントは必要
    • 新しいメンバーが必要なのがドキュメントなのか?知りたいことが分かればドキュメントでなくても良いかも

スクラムでやる場合の予算をどうやって見積もるか?

  • 見積もるときはウォーターフォールと同じで、開発工程をスクラムで進める
  • 準委任契約で進める
  • 過去の類似実績から見積もる
  • 見積もり内で開発が終わるように顧客と話をしてスコープを調整して収束させる

【勉強会】Scrum Masterの現場

devlove-kansai.doorkeeper.jp

  • 日時:2019-02-08(金)19:30 - 21:30
  • 場所:MonotaRO 梅田オフィス (ハービス大阪6F)

スクラムマスターをテーマにした勉強会というのは今まではあまりないテーマの気がします。アジャイルスクラムが世の中に浸透してきて関心が高まっているのを感じました。

2つのセッションとも、スクラムをやりたいという想いはあるものの、実際にやってみると様々な課題に直面し、チームをうまく巻き込みながらより良いやり方を模索してきたことが非常によく伝わってきました。また、結局はスクラムの原則にある目的を理解して正しく実践していくことが大事であることを学びとしていると感じました。

ちなみに、スクラムクイズは私たちのチームも実践していますがスクラムに取り組むチームの成熟度を上げていくには良いプラクティスだと思います。

tech-blog.rakus.co.jp

スクラムマスターとは

@yohhatu さん

導入として以下のような書籍やサイトが紹介

0から始めた!スクラム導入から今日まで~初心者スクラムマスター奮闘記~

@superSatoshiKun さん

www.slideshare.net

スクラム導入

どんな想いで広めますか?

1度目

  • 憧れ

→思いが弱く、広め方もわからず、メンバーの入れ替わりで自然消滅

2度目のきっかけ

  • 現プロセスの課題⇒ユーザーに寄り添った開発
  • ビジネス感覚を持ったソフトエンジニアを目指す⇒PDCAのCAを強化
  • 同じチームでも知らないことが多い⇒チームで成長
  • 憧れ

情熱と目的を持って広めていく⇒エバンジェリスト

どうやって詳しくなるか?

  • 本を読んでも今の自分にぴったりな答えは書かれていない
  • 経験がないと課題にも気づけない

経験豊富な方々の意見を聞きにいく⇒社外コミュニテイ

  • 同じように頑張っている人と話せることで勇気をもらえる

どんな方法で広めるか?

勉強会の開催

  • 月1開催を半年間
  • 対話しやすいように少人数
  • 内容
  • ポイント
    • 自分ごととして考えられるように
    • 参加者もアウトプットする場
    • 忙しい時間を割いていただくので感謝を忘れずに

まとめ

  • エバンジェリストとして
  • 広めるためにはフオロワーが重要
    • 社外にも目を向ける
  • 勉強して終わりにしない
    • 対話の時間を設ける
  • やろう!とはならない
  • 実験しよう→やらないとわからないことも多い

スクラム実践

  • 可能な限り忠実に
  • スモールスタート
    • ソフトウェア開発部門だけで
  • スプリントは1週間
  • GitHubのprojectで

スプリント

  • 月曜:プランニング
  • 金曜:デイリースクラム
    • スプリントレビュー
    • レトロスペクティブ
  • デイリースクラム後にリファインメント
  • スクラム以前からの定例ミーティングはなるべくそのまま

目的を理解する

スクラムクイズ

例題

  • デイリースクラムの目的は?
  • プロダクトオーナーは何に責任を持つ?
  • スクラムの3本柱は?

忘れる頃に質問することで記憶に定着⇒目的を再認識する場

  • スプリントレビューの目的は?
  • 答える
  • あれ?できていないね?どうしたらできる?

効果が出た点

  • 透明性が高まって自己組織化が進んだ
    • プランニングで作業漏れを予防
    • プランニングで認識のズレを修正
    • 負荷の偏りの把握
  • 成果物の価値について意識が高まる
  • 定量的なデータが取れる
    • ベロシティでこなせる量が把握できる

スクラムマスターの力不足だった点

  • スクラムガイドから外れた部分は問題になる
    • レビューは既存MTGで代用し正しく行われず、PDCAのCAの強化の効果はなかった
  • スクラムマスターと開発者の兼務は厳しい
  • スプリントゴールが達成できない
    • 割り込み、スケジュール遅れ、見積もりズレ

実感したこと

  • スクラム自体は何も解決しない
  • 支援は難しい
    • 色々な経験がないと支援は難しい

スクラムガイドは忠実に

  • 今のプロセスに合わないからといって一部でも変えるとそこは失敗する
  • 目的が大事

今後

  • 開発全体を巻き込んだスクラムにしたい
  • そのためにも今を徐々に良くしていく

3年間の失敗から学んで、やっとスクラムに向き合う準備ができた話

遠藤 良さん

speakerdeck.com

スクラムと出会い、「うまくいかない」を繰り返して 価値観やマインドはどう変化した?

経歴

こんな価値観

  • 計画主義
    • 計画通り終わらせる
  • リソース効率
    • 人月工数
    • 費用対効果
  • 指示に従う

Ep.1 プラクティスに出会う

  • 新しい環境への期待
  • いままでの価値観
  • はじめてのWeb業界

上長から

  • チームをまとめてみようか
  • プロジェクト計画
  • 取締役会で説明しよう
  • ふりかえりやってみたら?
  • 看板作ったら?
  • 計画は更新すればいいから

不安

  • 新しいプラクティス
  • 中途のプレッシャー
  • 新しい環境への期待

中途のプレッシャー

今までの価値観→増

  • 過去のやり方を踏襲
  • MTGの時間は増加
  • パフォーマンス低下

(うまくいかないぞ…)

銀の弾丸はなかった!

アジャイルの本にあるプラクティスをやっただけじゃダメ

(価値観を変えていかないと失敗する)

Ep.2 POもSMもいないチーム

運用チームリーダー

  • 大量の残タスク
  • 着手中タスクだらけ
  • 常に割り込み発生

上長から

  • 1週間スプリントでリズム作るといいよ
  • バックログ運用してみたら?
  • スプリントレビューは参加するよ

⇒今度こそスクラムだ!

  • PBI…SpreadSheet、Jira
  • スクラムイベント…ふりかえりを定期的に実施して改善
  • プロセス改善…現実をみた上で改善

現実

  • これ、最終誰が決めるの?
  • お客さんに言われたのでやってください
  • これはxxさんタスク

(これがアジャイル?チーム開発?)

Ep.3 学びを捨てたスクラムチーム

上長から

スクラムマスターがんばるぞ!)

  • リリースは10ヶ月先
  • POはスクラム初心者
  • 毎回スプリント完了しない

ドン勝!

  • スプリントを完了できるチームに
  • スクラム理解も深まる
  • 順調にアルファ版リリース

実際

  • POがスコープ削ってくれるでしょ?
  • やってみないとわからないけど一旦オッケー(プランニング)
  • ベータ版リリースを乗り越えよう

(まあスプリントは完了しているし…)

  • POとの対立
  • リリース直前トラブル
  • 燃え尽きるチームとPBI

現実

  • エンジニアのSMを0.5借りられない?
  • 社外コミッターの皆さんに協力してもらおう
  • 今週の土曜だけがんばりゃリカバリできそう

結果

  • 便利な人
  • SMがハンドリング
  • 毎週土曜出勤

何がまずかった?

  • リスクの先送り
  • 進捗を出すためにチームがわかっていることから着手していた
  • SMにタスクアサイ
  • リソースが足りないとSMがレビューや進捗管理
  • 納期&スコープほぼ固定

スクラムマスターがスクラムマスターの仕事をしていなかった

気づいたら開発メンバーの仕事をしていた

「チームは何を学んでいるの?」

  • 不確実性に向き合ってる?
  • 何を学んだ?
  • チームの認識あってるのかな?
  • チームはどうありたいの?

エピローグ

こんな価値観に変わった

  • 実験してみよう
    • 行動からチームが学ぶことが大切
  • ユーザー価値
    • チームの中だけに目を向けない
  • あるべき姿
    • どうありたいか?の最初の問いかけ

試してみることに失敗はない

  • デイリースクラムに集まらない⇒怒ってみる

いまやるべきことに集中するための場をつくる

チームが変わるきっかけを一緒に探す

  • 2チームに分かれてふりかえりして発表
  • 心理的安全性ゲーム

【勉強会メモ】関西Node学園 5時限目

nodejs.connpass.com

  • 日時:2019/02/01(金) 18:40 〜 21:00
  • 場所:サイボウズ株式会社 大阪オフィス

いつの間にか5時限目のNode学園。関西も回を追うごとに盛り上がっているように感じます。最近あまりこの領域の技術に関われていないので付いていくのがやっとというか、なんとか食らいついていますが、ハッシュタグ #kng5 を追いかけるだけでも、とても勉強になります。

Design Mistakes in Node & Deno

@shisama_ さん

speakerdeck.com

Node.jsの設計ミスを設計者自身が改善しようとしている

※参考

yosuke-furukawa.hatenablog.com

Deno

github.com

TypesScriptをV8で実行

  • トランスパイルする必要ない
  • TSファイルを直接実行できる
    • 実行時にDenoがビルド

ES Modulesによるモジュール解決

  • CJSではなくSDMを使ったmoduleローディング
  • package.jspn不要
  • importでインターネット上のリソースを読み込める

Secureな実行環境

  • 安全でない環境では実行できない
  • 実行オプションをつける
  • 許可しなかった場合はパーミッションエラー

Node.jsからの改善

  • Node.jsはCallbackベース
  • DenoはPromiseベース

Deno Core

  • Privilgedな領域とUnprivilegedな領域がある

3つのレイヤー

Deno for Users

  • curlでインストール
  • ライブラリも既にたくさん(deno-redis,deno-xml-parser,expressiveなど)

まだ試行段階

TypeScriptとVue

@Daikids2 さん

speakerdeck.com

  • vue-cli はdeprecatedになった→ @vue/cli を使う
  • TypeScriptとscssを選べる

TypeScriptのサポート

jp.vuejs.org

Class-Style ComponentでTypeScriptそのものの型が使える

Callbackを撲滅した後に ~ Promise化だけでは終わらない

@Ajido さん

speakerdeck.com

techblog.yahoo.co.jp

↑Promiseを撲滅した後に残った課題の話

CallbackとPromiseのインターフェースを両立させる

  • Callbackを省略した時にPromiseが返る→オススメ
    • 段階的なPromise化が可能
    • 将来的なCallbackの廃止
  • Promise型のモジュールを返す
    • ライブラリを一気にPromise化する必要がある(段階的にできない)
  • メソッドチェーンからPromiseを返す
    • .promise()
  • Suffix月の関数からPromiseを返す
    • 実装が楽
    • 互換性への対処が難しい

性能

  • パフォーマンスを計測→現時点ではCallbackが最速
  • async/awaitはPromiseよりも速くなる
    • V8 7.2以上ではawaitの仕様変更に伴う最適化
    • Node-v12に入るかも

現代的なフロー制御は高速なのか?

  • async/awaitはNodeのバージョンアップに伴い速度が向上
    • 速度はCallbackに迫りつつある
  • Promiseよりもasync/waitを
  • async/awaitを使うならメジャーバージョンアップは積極的に

ストリーム対応

Streamをフロー制御にどう組み込む?

  • Streamとフロー制御は相性が悪い
  • Streamのエラーハンドリングは独特
  • EventEmitterのエラーハンドリングは独特、ハンドリング漏れはクラッシュにつながる

AsyncIteratorを使ったStreamのフロー制御

  • ES2018の新機能
  • 統一的なエラーハンドリング

エラー処理

非同期処理のスタックトレースはどう見える?

  • 課題1
    • 呼び出し元エラーの発生箇所が特定できない
  • 課題2
    • awaitで中断した関数はマイクロスタックキューから処理

課題への対処

ブラウザで使えるnpmライブラリ

@mochiya98 さん

drive.google.com

m98.be

Asynchronous Modle Definition

  • CommonJS
    • サーバ向け
    • nodeでお馴染み
  • ES Modules
  • 従来型
    • <script>

UMD

  • 全部のせ
  • 1つのファイルでAMD、CJS、従来型として使える
  • ESMは構文だから古い環境への互換性を失う

UMD+ESMなpackage.jsonの書き方

  • 基本的にmain
  • ESMを活用するツールはmodelを見てくれる
    • mainにUMD、moduleにESMを指定
{
  "main": "hoge.umd.js",
  "module": "hoge.esm.js"
}

Managing multi-package repositories

@kamiyam さん

www.slideshare.net

Lernaについて

lernajs.io

gitとnpmを使ってマルチパッケージリポジトリを管理するワークフローを最適化するツール

※参考

qiita.com

モノレポ化

  • メリット
    • 依存関係がある複数レポジトリ管理
    • モノレポ内で共通モジュールを作成
    • packages以下の各プロジェクトをそれぞれ独立してnpm publishすることも可能
  • デメリット
    • コマンドが若干煩雑
    • ファイル構成が大きくなる
    • デプロイ(公開モジュールが複数あるなど)

始め方

$ npm install
$ lerna init

package以下にプロジェクト配置

  • packagesフォルダの下に各プロジェクト
  • その下にpackege.json

管理モード

  • 固定モード
  • 独立モード

モードの違い→packages以下の管理バージョンを固定/独立選べる

$ lerna add xxxx →基本 npm installは使わない

--scope で対象プロジェクトを絞る

各プロジェクト間の依存モジュール

$ lerna add @others --scope xxx

モジュール全体

$ lerna run xxxx

各モジュールの依存関係を解決

lerna bootstrap

たまにモジュールのロードがおかしくなる

$ lerna clean
$ lerna bootstrap
  • 導入は難しくない
  • 大規模開発環境を細かくbuild/publish

分散データの基本

@leichtgewicht さん

分散ファイルシステム - Wikipedia

Node.jsで分散ストレージ

同じデータ?

  • ハッシュする
  • 正しいファイルであることと誰が開発したかがわかる
  • Buffer.compare()

繋がりがなくなったら?

  • IDをつけたほうが良い
  • crypto.randomBytes(32)

分散する

  • bitfield
  • ブロック単位でどれを持っているかわかる
  • bitfield は3種類、メモリの使い方などが違う

すべてのブロックが揃っているかをどうやって確認する?

  • ハッシュをつける
    • 順番が確認できない
    • 前後のブロクのハッシュからハッシュを作る
    • さらにそのハッシュと次のハッシュでハッシュ→回帰的に
  • 正しい順番かどうかを確認できる
  • merkle-tree-stream

誰が情報を更新したか?

  • publickKey, privateKey
  • signatureを作る

hypercoreというモジュールがある

  • これらすべてのことができる

www.npmjs.com

※参考

datprotocol.github.io