
この記事は[Visual Studio Code Advent Calendar 2019 - Qiita](https://qiita.com/advent-calendar/2019/vscode)8 日目の記事です。

現在、仕事で使っている VS Code の LiveShare を使ったリモートペアプログラミングについて紹介します。
ちなみに利用している技術スタックは、「React+TypeScript」のフロントエンドチームの事例です。

## 目次

## 背景

なぜ現在この方法を採用しているかというと、次のような理由がありました。

- ジュニアのフロントエンドが参画したため、育成する必要がある
- PullRequest をレビューという従来の形を採用してみたが、育成効果があまりないことにすぐ気づいた
- リモートワークが多い

## なぜ PullRequest をレビューがジュニア育成に機能しなかったのか？

一番の理由は、フロントエンドの UI には文書化しにくい暗黙の仕様(※)のようなものがたくさんあり、これらの内容を PullRequest という 1 点で指摘する場合、どうして**ももぐらたたき**のようになってしまいがちだからです。

> ※ レスポンシブ対応や中のコンテンツの幅を変化させたときにどう振る舞うかなどです。

このような指摘方法では、指摘している自分自身もなんだか楽しくないですし、ジュニアのモチベーションを下げてしまいそうで心配でした。

しばらくして**ももぐらたたき式**のやりかたを改め、自分のやり方を見せながら教える方針に変更しました。つまり**ペアプログラミング**です。

## 自分がやりたいペアプログラミングの形を探る

過去にやってきたペアプログラミングには、個人的にどうしても嫌いな側面があって、自分がペアプログラミングを主導する上でこれら問題を解決する方法を考える必要がありました。

自分がこれまでやってきたペアプログラミングの嫌いな点です。

- 教える側と教えられる側が別れている(今回のシニア・ジュニア間は特にそうなりやすい)
- 片方がナビゲータ側になるので、ナビゲータは画面を見ているだけで非常につまらない
- ナビゲータとドライバーで上下関係が生まれる(相性が悪いと今後の仕事上の関係が悪くなる可能性がある)
- スキルや知識の継承や共有が主目的になりがち

つまり、これまでのペアプログラミングは心理的な負荷が高く、双方にストレスが多いと感じていました。そこで、今回いい機会だと思い自分なりにどうしたいのか真剣に考えてみました。

そこで感じたことは、ペアプログラミング(というかペア作業)の一番の醍醐味は「**お互いに 1 つのものを協力して完成させていく過程を楽しみ、そこで生まれる達成感からお互いの信頼関係が深まることではないか**」と思った次第です。

そのため自分がやりたいペアプログラミングを実現するために、同じ PC の画面上で同時に並行作業でき、ナビゲータとドライバーの垣根をなくせるようなツール(道具)が必要でした。
そこで出会ったのが「**[Live Share](https://visualstudio.microsoft.com/services/live-share/)**」です。

## Live Share とは

前置きが長くなりましたが、Live Share を一言でいうと「**コードの共同編集**」です。
Google Doc の共同編集を体験した方であれが想像がしやすいかと思いますが、複数人で同時に同じコードを編集することができるツールです。

Live Share を使うと、下のように VS Code 上で他の人がどこを編集しているか一目でわかるようになります。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/liveshare-03.png)

> (画像は本家サイトのもの) https://visualstudio.microsoft.com/services/live-share/

Live Share は VS Code の plugin となっているので、こちらからインストールしてください。

- [Live Share \- Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare)

こまかな設定や利用方法については、Web を検索すると様々な情報が見つかるので、そちらを参照してください。

## 実際のリモートペアプログラミングのやり方

リモートペアプログラミングをする上で次のツールを利用しています。

- VS Code + Live Share
- Slack(ビデオチャット用。画面共有できれば他のもので代用可。)

VS Code の他にはリアルタイムで会話するために、ビデオチャットツールを利用しています。
Live Share には**Shared servers**や**Shared terminal**など相手の環境を共有できる強力な機能がありますが、やはり「そっちの画面ちょっとみせて」といったライトなやりとりができた方がいいので、ビデオチャットには画面共有ができた方がいいです。

まず、どちらかのローカル環境に VS Code 経由で接続する(Collaborative Session)ことでリモートペアプログラミングが始まります。

基本的に VS Code を左右 2 ペインにして作業します。
下の例では左がジュニア、右がシニアです。ジュニア側は React の小さな UI コンポーネントを作成し、シニア側はコンポーネントを検証するコードを書きます。こうすることで 2 人同時に並行作業することができます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/liveshare-02.png)

今回は小さな UI コンポーネントを題材にしました。シニアがスタイルガイド([React Styleguidist](https://react-styleguidist.js.org/))に UI コンポーネントの様々なバリエーションを追加していき、これをジュニアが実装していきます。
ジュニアがつまづいたりした場合は、ビデオチャットで教えたり、直接コードを変更しながら実装の手順を順番に見せたりします。

最終的に二人で協力しながら 1 つの UI コンポーネントを完成させることを目指します。

> スタイルガイド([React Styleguidist](https://react-styleguidist.js.org/))とは、UI コンポーネントの見本カタログのようなものです。他には[Storybook](https://storybook.js.org/)が有名です。
> 個人的な経験として、昨今のフロントエンドの品質を上げるためには、**末端の UI コンポーネントを品質を上げることが非常に重要**なことがわかってきました。そのため、このようなスタイルガイドを利用して様々な状態(レスポンシブ・内包するコンテンツなど)に対応する UI コンポーネントを作り込む作業を非常に重要視しています。

二人で作成したコンポーネントは最終的に下のような美しいスタイルガイドになるため、ペアで作業していてスタイルガイドが順番に完成に近いていく様子や、スタイルが崩れるバリエーションの例(文字が長いとか)を、スタイルガイドに追加してジュニアに見せてワイワイさせたり、終始ペア作業をしていて楽しいです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/liveshare-01.png)

また、ネストした構造のコンポーネントをレスポンシブにしていく手順など、これまで教えにくい部分についても、シニアがどのような視点でコンポーネントを完成させていくのか順に見せることで教えやすいように感じています。

> ここでは紹介していませんが、デザインは[Figma](https://www.figma.com/)を使っています。デザイン作業も完全リモートです。

なにより一緒に作業することで、ジュニアのスキルレベルの把握ができ、どのような課題があって次にそのような挑戦をさせたらしいか、考えることができるようになりました。

ジュニアも今まで謎だった、フロントエンド実装の手順について明らかになり、自信がついてきたような気がします。
このようなことは、フロントエンド特有の自由度に起因するのかもしれませんが、ジュニアに結果だけでなく過程も見せることで確実にスキルアップできそうな気がします。

## まとめ

VS Code の LiveShare を使ったリモートペアプログラミングの紹介でした。

きっかけはチームにジュニアが参画したことで、従来の**もぐらたたき式**の PullRequest レビューや、ストレスの多いペアプログラミングを脱却し、本当にチームの中でジュニアがのびのび楽しく成長できる環境を作りたかったことが始まりでした。

まだ、試行錯誤の途中ですが、これからも自分が考える最良の環境を目指して努力していきたいです。


VS CodeのLiveShareを使ったリモートペアプログラミングの紹介


[react-native-router-flux](https://github.com/aksonov/react-native-router-flux)の小ネタです。

前回の話はこちら。

- [react\-native\-router\-flux の onRight をカスタマイズする \| I am mitsuruog](https://blog.mitsuruog.info/2019/03/rnrf-customizable-onright)

前回はアプリの NavBar の右側にあるボタン(以下、RightButton)をクリックした時に、次の画面に props を渡したいようなユースケースを想定していましたが、今回は RightButton を props の条件で出し分けしたいと思います。

次のような手順で実現できそうです。

1. PageComponent 内部で RightButton を出す
2. RightButton をタップした時に、Component 内部のタップハンドラ(private function)を実行する
3. 外部からの props の値で RightButton を出し分けする

コードは全て TypeScript です。

## PageComponent 内部で RightButton を出す

RightButton の追加方法は**いくつかある**のですが、今回は PageComponent に static な`navigationOptions`プロパティを追加して、この中で RightButton 用の Component を定義します。

> この方法というものがいくつかあって、それぞれ期待する動きをしないので辛いです。

```ts
// ...
import { NavigationScreenProps } from "react-navigation";

class Page extends React.Component<State, Props> {
  static navigationOptions = ({ navigation }: NavigationScreenProps) => {
    return {
      // ここにRightButtonのComponentを渡す
      headerRight: <Button title="+1" />,
    };
  };

  render() {
    // ...
  }
}
```

`navigationOptions`で渡されている関数の`navigation`は`react-navigation`の`NavigationScreenProps`の型を使います。これは、`react-native-router-flux`が`react-navigation`をベースとして拡張しているためです。

## RightButton をタップした時に、Component 内部のハンドラを実行する

RightButton をタップした時に、Component 内部のハンドラを実行するには`Button`Component の`onPress`を使えば可能です。しかし、`static`プロパティ内部から PageComponent 内の private function を呼び出すにはひと工夫必要でした。

`static`プロパティ内部から PageComponent の function を実行するには、props の`navigation`を通じて function の参照を渡すことで可能となります。
`componentDidMount`の中で props の`navigation.setParam`を使うことで参照を渡すことができます。

```ts
// ...
import { NavigationScreenProp, NavigationScreenProps } from "react-navigation";

export interface Props {
  navigation: NavigationScreenProp<any, any>;
}

class Page extends React.Component<State, Props> {
  static navigationOptions = ({ navigation }: NavigationScreenProps) => {
    return {
      headerRight: <Button title="+1" />,
    };
  };

  componentDidMount() {
    // ここでハンドラの参照をセットする
    this.props.navigation.setParams({ onRight: this.onRight });
  }

  // ...
}
```

渡されたハンドラの参照を次のように`navigationOptions`で使うことができます。

```diff
// ...

class Page extends React.Component<State, Props> {
  static navigationOptions = ({ navigation }: NavigationScreenProps) => {
    return {
-      headerRight: <Button title="+1" />
+      headerRight: <Button title="+1" onPress={navigation.getParam('onRight')} />
    };
  }

// ...
```

これで RightButton をタップした時に`onRight`が呼び出されるようになります。

## 外部からの props の値で RightButton を出し分けする

外部からの props も上の方法と同様に`navigation.setParam`と`getParam`を使って実現します。

今回は props で`hasButton`が渡されるとします。`componentDidMount`の中で再び`navigation.setParam`を使います。

```diff
// ...

  componentDidMount() {
    // ここでハンドラの参照をセットする
    this.props.navigation.setParams({ onRight: this.onRight });
+   this.props.navigation.setParams({ hasButton: this.props.hasButton });
  }

// ...
```

この値を`navigationOptions`の中で使います。

```diff
// ...

class Page extends React.Component<State, Props> {
  static navigationOptions = ({ navigation }: NavigationScreenProps) => {
    return {
-     headerRight: <Button title="+1" onPress={navigation.getParam('onRight')} />
+     headerRight: navigation.getParam('hasButton') ?
+       <Button title="+1" onPress={navigation.getParam('onRight')} /> :
+       undefined
    };
  }

// ...
```

これで props 経由で RightButton を出し分けすることができるようになりました。

。。。大変。

以上


react-native-router-fluxのonRightをカスタマイズする(part2)


先日、参加した[html5j パフォーマンス部 第五回勉強会 ― 改正民法債権法と非機能要求としての Web パフォーマンス](https://atnd.org/events/106358)の勉強会にて**「Synthetic Monitoring」**なる聞きなれない単語が出てきたので、学習のためこのブロクのパフォーマンスを 1 週間測定してみた話です。

勉強会の内容をみて「Synthetic Monitoring とは？」っと興味を持った方には、読むと雰囲気が伝わるのではと思います。

Synthetic Monitoring については、当日の竹洞さんの資料や動画を確認してください。

- (Slide) <https://www.slideshare.net/takehora/web-150634918>
- (Video) <https://www.youtube.com/watch?v=R44_wzrkVMw>

> 注意)
>
> - この記事の内容は、[Spelldata 代表取締役 竹洞さん](https://spelldata.co.jp/about/representative.html)に測定を協力していただき、いろいろ教授していただい内容を元にしています。しかし、私自身が曲解・誤解している部分もあると思いますので、内容は正確でない可能性があります。ご注意ください。
> - 個人ブログを 1 週間計測しただけのごく限られた条件下の話であるため、この記事の内容を Web パフォーマンス全般について語っているような形で解釈しないでください。また計測値についても鵜呑みにしないでください。ご自身の Web サイトの状態を正確に知るためには、実際に測定して専門家に分析を依頼してください。
> - ブログ書きながら画像のキャプチャを撮っているため、若干計測の時間がずれているものがあります。雰囲気を感じるには十分だと思いそのままにしています。

## 測定条件

測定した条件は次の通りです。

- 測定したページ: <https://blog.mitsuruog.info/2018/03/how-to-learn-css-1>
- 測定期間: 2019/6/21 ~ 2019/6/28
- 測定ネットワーク:
  - 4G
  - 4G エミュレート
  - Desktop
- 測定地点:
  - Tokyo: NTT
  - Tokyo: KDDI
  - OSAKA: NTT
- 測定間隔: 各測定地点 15 分間隔
- 測定方法: Catchpoint を使った Synthetic Monitoring

> 注意)
>
> - 3 タイプの測定ネットワークで測定を行なっていますが、Desktop 以外のネットワークでサイトが遅すぎて測定がタイムアウトしてしまっていたため、以降の測定値はすべて Desktop で測定した内容です。

## このブログの測定結果

### 直近 1 時間分布を見る

まずはじめに直近 1 時間のパフォーマンス推移の散布図を見てみます。メトリクスは次の 3 つです。

- Render Start (ms)
- Document Complete (ms)
- Speed Index

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint1-1.png)

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint1-2.png)

- Render Start (ms): 700ms~2s くらい
- Document Complete (ms): 2s~3s くらい
- Speed Index: 1,000~2,000

### 直近 24 時間分布を見る

直近 1 時間では信頼性に欠けるので、範囲を 24 時間に広げます。

Render Start の中央値が 1,298ms で Document Complete の中央値が 2,786ms なので、
残念ですが遅いサイト確定です。

いくつか**外れ値**(赤丸で括った部分)の存在が確認できます。外れ値は後ほどの Waterfall を見てみます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint1-3.png)

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint1-4.png)

俯瞰して見ると、ブログの速度は次の関係が成立しそうです。

- (速い) OSAKA: NTT > Tokyo: NTT > Tokyo: KDDI (遅い)

## 単一測定点の Waterfall を見る

だいたいの傾向がわかったので、中央値あたりにある測定点の Waterfall を見てみます。

この測定点の測定データでは、Render Start が 1,800ms で Document Complete までが 3,100ms です。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint2-1.png)

どのあたりにボトルネックがあるかというと、下の図から次のリクエストに問題がありそうです。()の中は用途です。

- ws-fe.assoc-amazon.com（Amazon アフィリエイト）
- blog.mitsuruog.info（HTML 配信）
- s3-ap-northeast-1.amazonaws.com（画像配信）
- i.creativecommons.org（画像配信）
- maxcdn.bootstrapcdn.com（FontAwesome CDN）
- rcm-fe.amazon-adsystem.com（Amazon アフィリエイト）
- Render Start から JavaScript の実行時間が 1,500ms くらいある

個別に見ていきます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint2-2.png)

まず HTML 配信から。

このサイトは[Netlify](https://www.netlify.com)(Free プラン)を使っているのですが、ここでの HTML 配信が遅延しているようです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint2-3.png)

> [Netlify Pricing](https://www.netlify.com/pricing/)を確認すると Free プランでも Netlify Edge features の Global CDN deployments が有効になっているので、単純にこの CDN が遅いだけかもしれません。
> （有料化したら別の高速化オプションがあるかもしれませんが。。。）

次に FontAwesome の CDN。遅いですね。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint2-4.png)

続いて画像配信。このサイトの画像は S3 から直接配信しています。

S3 の場合は、画像の最初の 1 バイト目が配信されるまでは速いのですが、ファイルサイズが大きくなると急激にデータの送り出しが遅くなるケースがあるようです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint2-5.png)

続いて、クリエイティブ・コモンズの画像。
（こんな小さな画像の配信でこんなに遅延するとは。。。）

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint2-6.png)

そして、Amazon アフィリエイト。
（Redirect!? 一体こいつは何をしているんだ。。。）

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint2-7.png)

最後に JavaScript の実行時間です。1,500ms くらいあります。

> この時間は Catchpoint では測定できないので、Developer tool のプロファイルで測定・分析する必要があります。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint2-8.png)

今日は、パフォーマンス改善の話はしないので、ボトルネックの把握だけにします。
ここまでで判明した事実として、このブログは次のボトルネックがあるようです。

- HTML 配信が遅い
- S3 からの画像配信が遅い
- FontAwesome の CDN とクリエイティブコモンズの画像配信が遅い
- Amazon のアフィリエイトが遅い
- JavaScript の実行時間が遅い

続いて代表的な外れ値の Waterfall を確認してみます。

### 外れ値(S3 遅延のケース)

まず、Render Start が一番遅延している測定点の Waterfall を確認します。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint3-1.png)

Render Start まで 10s 掛かっています。
ボトルネックを見ると、S3 が遅延していることがわかります。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint3-2.png)

上のボトルネックでも判明している、S3 からの画像の送り出しの部分が非常に遅延していますね。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint3-3.png)

## 外れ値(JavaScript 実行による遅延のケース)

続いて、Document Complete が遅延している測定点を見てみます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint4-1.png)

Render Start から Document Complete まで 5s 掛かっていることがわかります。

ボトルネックを見ると遅延していますが、上の Render Start の中央値 1,298ms と比べると Render Start の 1,397ms というのは、そこまで外れ値でななさそうです。
（つまり、通常通りの遅延であって、ここまで異常値になった原因ではない。）

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint4-2.png)

異常箇所はどこにあるかというと、JavaScript の実行時間にありました。

ここの分析には Developer tool でプロファイルの測定をする必要がありますが、このタイミングを捉えるのは非常に根気がいる作業であることが容易に想像できます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint4-3.png)

## ボトルネック通信の品質の揺らぎを見る

続いて各ボトルネックの品質がどれくらい幅があるか見てみます。これは継続的にデータを収集する Synthetic Monitoring ならではの面白さだと感じます。

ちなみにパフォーマンスにおいて品質とは**「速さ」**です。

### ボトルネック通信をピックアップして分布を見る

まず、測定した通信の中で遅いものをピックアップします。
今回は次の 3 つをピックアップしました。

- `https://blog.mitsuruog.info/2018/03/how-to-learn-css-1`
  - S3 から配信している画像の中でも特別にサイズが大きいもの(サイズは 1M)
- `https://i.creativecommons.org/l/by-sa/4.0/88x31.png`
  - クリエイティブコモンズの画像
- `https://rcm-fe.amazon-adsystem.com/e/cm`
  - Amazon の AD システムの何か？

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint5−1.png)

まず分布をみます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint5−2.png)

このままでは何もわからないので、累積分布関数(Cumulative Distribution Function)をかけます。

累積分布を見ると**どれくらいの確率でどれくらいの速度が出ているか**がわかります。
下のグラフを眺めていると、途中までは速度が速く一定ですが、急に遅くなるポイントがあります。これを**「変曲点」**と呼び、品質を見る上で重要なポイントです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint5−3.png)

個別にみてみます。

### S3 画像配信の品質

まず分布をみます。
中央値は 238ms ですが、分布を見ると速いケースと遅いケースに二極化しているようです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint6−1.png)

次に累積分布をみます。変曲点は 60 パーセンタイルと 99 パーセンタイルの 2 つでした。
つまり「60%の確率で速く、残りの 39%の確率は非常に遅く、1%の確率で信じられないくらい遅い」ということです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint6−2.png)

このグラフのように速度のばらつきも大きいため、大きいサイズの画像を S3 から配信した場合は**品質が悪い**と言えます。

### クリエイティブコモンズと Amazon の AD システムの品質

2 つまとめて分布を見てみます。
分布を見るとクリエイティブコモンズの方が、Amazon の AD システムよりも高速なことが多いことがわかります。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint7−1.png)

次に累積分布をみます。変曲点は共に 99 パーセンタイルでした。
つまり「99%の確率で遅く、1%の確率で信じられないくらい遅い」ということです。

このような累積分布を示す場合は、(遅いけど)**品質が良い**と言えます。
下のグラフを見ると、クリエイティブコモンズは品質が一定ですが、Amazon の AD システムは少し変動の幅があるため、クリエイティブコモンズの方が品質が良いと言えます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint7−2.png)

### Netlify からの HTML 配信の品質

Netlify からの HTML 配信の分布をみてみます。

> 記事を書いている間にとんでもない外れ値が出ていました。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint8−1.png)

次に累積分布をみます。
品質は安定していますが、1 つだけ異常な測定値がありました。これは一体なんなのでしょうか。。。？

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint8−2.png)

異常点の Waterfall を見てみます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint8−3.png)

なんと DNS failure。サイトに到達できてない。

今回の計測では、これの原因の推測まではできません。
しかし、1 ヶ月や 1 年などの長い周期で測定していた場合、何かの傾向(定期的なシステムメンテナンスなど)が読み解けるかもしれませんね。

### S3 から小さな画像を配信してみたらどうか？

S3 から大きい画像を配信した場合は遅延することがわかったのですが、小さな画像の場合はどうでしょうか？
小さな画像の通信をいくつかピックアップして分布を見てみます。

中央値は 25ms なので割と高速ですが、分布にばらつきがみられ品質はあまり良さそうではないです。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint9-1.png)

累積分布を見てみます。
品質が一定ではない(気がする)。
CloudFront などの CDN から配信した場合を直接測定したことがないので、正直なんとも言えませんね。CDN を測定してみると違いがわかると思います。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2019/catchpoint9-2.png)

ちょっと疲れてきたので、このあたりにします。

## まとめ

自分のブログのパフォーマンスを Synthetic Monitoring で 1 週間測定してみて、通信上のボトルネックについてどれくらいの品質なのか分析してみました。

わかったこととしては、このブログは遅いが、HTML 配信や画像配信、JavaScript 実行のプロファイル分析をすることで高速化する可能性があるということです。
また、品質管理の観点では、品質は平均ではなく分散であり、累積分布をみることでどれくらい安定しているか判断できるようになることがわかりました。

継続的に同じ条件で測定を行うことで、別の視点からの比較・分析がやりやすいことがわかりました。

とはいえ、Catchpoint は個人で使うには高すぎるので、別の代替えサービスを探して測定を続けたいと思います。

### 謝辞

個人で Synthetic Monitoring を試してみようと思ったところ、どのサービスも個人で利用するためには敷居が高すぎて頓挫しているところを、「1 週間なら試しに測定してもいいよ」と言ってくれただけでなく、後日、丁寧な解説用の動画を作成してくれた竹洞さんに最大の感謝を送ります。


Catchpointでこのブログのパフォーマンスを1週間Synthetic Monitoringしてみた


JavaScript のテストフレームワーク[Jest](https://jestjs.io/en/)の小ネタです。

最近 react や react-native のプロジェクトでモジュールの参照に alias を使うことが多いのですが、Jest でこれを扱う方法について紹介です。

## alias を使ったモジュール参照

alias を使ったモジュール参照とは、プロジェクト内の特定のディレクトに別名(alias)をつけることで、`import`文の記述を簡単にすることです。

例えば、次のような相対パスでモジュールを import している箇所に alias を使ってみましょう。

```ts
// greet.ts は src/shared/services にあるとする
import { greet } from "../../../greet.ts";
```

alias を使う場合は、まず`src/shared`に`Shared`という alias をつけます。そうすると次のように相対パスを除いて書くことができます。

```ts
// Shared は src/shared を参照している
import { greet } from "Shared/services/greet.ts";
```

alias を使うメリットとしては、`import`文の記述を簡略化することもあるますが、相対パスを使った場合よりリファクタなどの変更に強いことが挙げられます。

## moduleNameMapper を使って alias を扱う

Jest で alias を扱うためには`moduleNameMapper`を使って alias と実際のパスをマッピングします。

- <https://jestjs.io/docs/en/configuration#modulenamemapper-object-string-string>

上の例の場合は次のようになります。

```js
module.exports = {
  moduleNameMapper: {
    "^Shared(.*)$": "<rootDir>/src/shared/$1",
  },
};
```

これで Jest でも、alias を使ったモジュール参照があるプロジェクトをテストすることができました。


Jestでaliasを使ったモジュール参照を扱う

<p>所属会社が CTO 協会主催の<a href="https://eventregist.com/e/gmxATLNsi1KK">Thanks Giving Day 2022</a>にスポンサーとして出展したので、スポンサーとして講演してきました。</p>
<p>久々のオンラインイベントだったことや、基調講演から非常に熱い話が聞けたので、終始熱気に包まれた雰囲気の良いイベントだったと思います。主催の CTO 協会と当日運営されていたメンバーの方々、本当に素晴らしいイベントでした。感謝しています。</p>
<p>今回は、基調講演の小林議員の話が非常に印象的だったので、その辺りの熱気が冷めないうちに記録にのこしておこうと思います。</p>
<h2 id="基調講演の感想">基調講演の感想</h2>
<p>基調講演は藤本理事・小野理事・小林議員の特別対談ということで進められました。</p>
<p>正直なところ、議員が基調講演すること正直あまり期待していなかったんですよね。
しかし、実際の話を聞いてみるとデジタル庁でやっていることや、今後の日本の未来のためのアイデアがビジョンの話など
想像以上に面白く、また、アプローチ自体が非常にプログラマ思考で進められていて感心しました。</p>
<p>話の内容としては、小林議員がデジタル庁でおこなっていることが中心でしたが、どれも非常に興味深い内容でした。</p>
<ul>
<li>日本は公共インフラが老朽化してきて問題となっているが、実は下のインフラ（法律・制度・さまざまな商習慣。以下、ソフトインフラ）が実は老朽化していて、新しい取り組みを行う際に障害になっている。</li>
<li>ソフトインフラのボトルネック箇所をすでに特定し、そこをリファクタする取り組みをしている。</li>
<li>法律のコード化に取り組んでいる。コード化することで、法律を変更した際にどこに影響があるか、それぞれが矛盾しているか検知することが可能。これにより影響についてコンピュータ上でシュミレートができる。また、コード化することで A と B がどちらが良いかなど、実際にものを見て議論ができるようになる。</li>
<li>国として自治体共通のインフラを整備しようとしている。将来的にマーケットプレイスのようなものを設立し、調達のコストや期間、サービスの多様化などを促す。</li>
<li>ソフトインフラに縛られた理不尽な要求がある、その場合、もっと上流に行ってルール（仕様）を書き換える必要がある。</li>
</ul>
<p>最後に、「<strong>みんなで上流に行ってルール（仕様）を書き換えよう</strong>」という強いメッセージをもらいました。話を聞いているうちに、自分の中で何かが熱くなるのを感じました。</p>
<p>久々に日本の未来について希望が持てる話でしたし、デジタル庁がしっかり仕事をしているんだなと認識しました。デジタル庁がんばれ！</p>
<p>そしてこの基調講演はイベントの空気を決定し、イベント全体が非常に熱気があるものとなりました。</p>
<h2 id="これからのエンジニア採用育成のあり方スポンサーセッション">「これからのエンジニア採用・育成のあり方」　スポンサーセッション</h2>
<p><img src="https://blog-mitsuruog.s3.ap-northeast-1.amazonaws.com/images/2022/cto-1.png" alt=""></p>
<p>小賀理事との対談形式でした。「これからのエンジニア採用・育成のあり方」というテーマでいろいろと話をしました。会場は満員でかなり緊張したことを覚えています。また機会があったら挑戦してみたいです。</p>
<p><img src="https://blog-mitsuruog.s3.ap-northeast-1.amazonaws.com/images/2022/cto-2.JPG" alt=""></p>
<p>個人的には、セッションの準備の過程で、自社のプロダクトの理念や強みなどを改めて知る機会になって、非常に良かったです。</p>
<h2 id="最後に">最後に</h2>
<p>CTO 協会主催の Thanks Giving Day 2022。私自身も多くの CTO と直接お話する機会があり、想像以上に収穫が多かったイベントでした。</p>
<p>自身も含め、多くの人がデジタル庁や CTO 協会に貢献したいという気持ちを抱くようになったのではないでしょうか？</p>
<p>日本にはオードリー・タンのような人は現れないのかと巷では嘆かれているが、実はすでに存在してて、それなりに成果も出ているようでした。なぜ日本のメディアはこのことを取り上げないで、ネガティブな情報ばかり発信しているのか不思議に思いましたね。</p>
<p>「<strong>みんなで上流に行ってルール（仕様）を書き換えよう</strong>」</p>
<p>そんな気持ちになるいいイベントでした。</p>

CTO協会主催のThanks Giving Day 2022に行った感想

Recent Posts

VS CodeのLiveShareを使ったリモートペアプログラミングの紹介

react-native-router-fluxのonRightをカスタマイズする(part2)

Catchpointでこのブログのパフォーマンスを1週間Synthetic Monitoringしてみた

Jestでaliasを使ったモジュール参照を扱う

Tags

Archives