
ブラウザには、ログイン画面などのフォームで入力した内容を保存して、次回の入力時に自動で候補リストとして表示してくれる「オートコンプリート」という機能があります。とても便利な機能なのですが、一度間違って入力してしまった場合でも候補リストに残ってしまうのが、ちょっと困りものです。

Firefox では、次のキーを押すことでオートコンプリートの候補リストから削除することができます。

- MacOS の場合： `Shift` + `Delete`キー
- Windows の場合： `Delete` キー

下記のサポートページに詳しい方法が載っているのでご参照ください。すべての入力履歴を消す方法や、オートコンプリートの機能を無効にする方法も紹介されています。

参考：
[フォームの自動補完 \| Firefox ヘルプ](https://support.mozilla.org/ja/kb/control-firefox-automatically-fills-in-forms)


Firefoxでオートコンプリートの候補リストから削除する方法


スタイルシートで`a`要素のリンクのデザインをする際に、次のように 4 つの擬似クラスを用いることが多いと思います。

```css
a:link {
  color: blue;
}
a:visited {
  color: purple;
}
a:hover {
  color: red;
}
a:active {
  color: yellow;
}
```

実はこの 4 つの擬似クラスの記述順序には注意が必要で、

1. link
2. visited
3. hover
4. active

の順番で記述しないと意図した結果にならなかったりします。この順序についてちょっと調べてみたので、まとめてみたいと思います。

## なぜこの順番じゃなければダメなのか？

[実践 Web Standards Design](http://amzn.to/2CIVkds) には、次のように書かれています。

> **:hover 擬似クラスと:active 擬似クラスは一連の動作であるので**、スタイルシート内でもこの順番で記述しないと有効にならない点に注意してください。
>
> --「3 章 3.3/CSS 管理のコツ」より

> 擬似クラスの記述順序には注意が必要です。（略）**常に最後の指定で上書きされるということに注意し**、link、visited、hover、active の順番で記述しておくと問題ないでしょう。逆に、すでに訪問済みのリンクは背景画像を変えたくないということであれば、visited を最後に記述するとよいでしょう。
>
> -- 「7 章 16/背景画像を利用して訪問済みリンクを一工夫する」より

擬似クラスの記述順序にルールがあるというのを知ったのは、実はこの本がきっかけでした。それまでは「hover が効かない！」とか「訪問済みのリンクの色が変わらない！」とかいった問題に出くわしてハマッた経験が何度かあったので、書く順番が原因だったことがわかったときは思わず「そうだったのか！」とひざを打ってしまいました。

で、勢いづいてもう少し調べてみると、CSS の権威である Eric Meyer 氏のサイトでも同じ内容に関する解説を見つけました。

🔗 [Link Specificity – meyerweb.com](http://meyerweb.com/eric/css/link-specificity.html)

カンタンにまとめてみると、

- セレクタの固有性（specificity）は 4 つとも同じ。
- なので、最後に書かれたものから優先的に適用される。
- 例えば、link、active、hover、visited の順番で記述しているとすると・・・
- 未訪問リンクの場合は、active を hover が打ち消すので active は無効になる。
- 従って、active は hover の後ろに記述しなければならない。
- 訪問済みリンクの場合は、active も hover も一番最後の visited が打ち消してしまって無効になる。
- 従って、visited は hover や active の前に記述しなければならない。
- つまり、link、visited、hover、active の順番で書くべし。
- ちなみに、link と visited は打ち消しあうことがないので順番はどっちでも OK。
- link はあくまで「未訪問（unvisited）」のリンクのみに適用される擬似クラスで、「リンク全般」に適用されるものじゃないので要注意。
- link じゃなくて unvisited にすればいいのにね。

## 順番の覚え方

海外では、この記述順序ルールを link-visited-hover-active の頭文字をとって「**LVHA**」と言うようです。ちょっと覚えづらいなぁと思っていたのですが、たまたま見かけた海外のブログにうまい覚え方が紹介されていました。

🔗 [How To Remember The Order of Selectors: LOVE and HATE – CSS Tricks](http://css-tricks.com/remember-selectors-with-love-and-hate/)

> Just think 'LOVE' (LV) and 'HATE' (HA)....

**LOVE and HATE** かぁ。ちょっと意味深だし覚えやすいですね。


:link、:visited、:hover、:active の記述順序とその覚え方


cron が crontab で設定した時間どおりに実行されないという現象に出くわして困ったのですが、何とか解決できたのでその方法を紹介しておきます。

まず、以下のような設定（1 分ごとに実行）をしてみると、期待したとおりに動いている様子。

```bash
* * * * * date >> /path/to/cron_check.txt
```

次に、以下のような設定（14 時台で 1 分毎に実行）をしてみると、14 時台にも関わらず実行されません。

```bash
* 14 * * * date >> /path/to/cron_check.txt
```

もしかしてタイムゾーンがズレているのかも、と思い、次のように仕込んでみました。

```bash
* 0 * * * echo '0' >> /path/to/cron_check.txt
* 1 * * * echo '1' >> /path/to/cron_check.txt
* 2 * * * echo '2' >> /path/to/cron_check.txt
* 3 * * * echo '3' >> /path/to/cron_check.txt
　　：
* 22 * * * echo '22' >> /path/to/cron_check.txt
* 23 * * * echo '23' >> /path/to/cron_check.txt
```

すると 14 時台なのに、`cron_check.txt` に出力されたのは「0」。やはりタイムゾーンが狂ってるっぽいです。

[NetBSD で cron の動作時間がずれる \- CORY's twilight zone](http://www.cory.jp/98/netbsd_cron.html) を参考にして、crontab の先頭に

```bash
TZ="Japan"
```

を追記してから

```bash
$ sudo /sbin/service crond restart
```

で cron のサービスを再起動したところ、無事、時間通りに実行されるようになったのでした。（`TZ="Japan"` の代わりに `CRON_TZ="Japan"` としてもうまくいきました。）

もし、同じような問題に出会った方は試してみてください。


cronが設定した時間どおりに実行されない場合の対処法


`element.innerHTML` を使うと、その要素内の HTML を取得することができます。Mozilla Developer Network (MDN) には次のように書いてあります。

> innerHTML は、与えられた要素に含まれる全てのマークアップ と内容を設定または取得します。
>
> -- [element\.innerHTML – MDC Doc Center](https://developer.mozilla.org/ja/DOM/element.innerHTML) より

また、jQuery.html() も、innerHTML と同様、HTML を取得することができます。

> Get the HTML contents of the first element in the set of matched elements.
>
> -- [\.html – jQuery API](http://api.jquery.com/html/#html1) より

でも、これらのメソッドを使っても、HTML のソースをそのまま取得できるわけではないことをご存知でしたか？私は知らずにハマってしまいました。ということで、以下、調べてみた結果です。

## 例 1

```html
<div id="main">
  <ul>
    <li>coffee</li>
    <li>coke</li>
    <li>red bull</li>
  </ul>
</div>

<script>
  var html = document.getElementById('main').innerHTML;
  console.log(html);
</script>
```

この例では、次のような期待通りの HTML が返ってきます。

```html
<ul>
  <li>coffee</li>
  <li>coke</li>
  <li>red bull</li>
</ul>
```

## 例 2

しかし、次の場合はどうでしょうか？

```html
<div id="main">
  <p><div>foo</div></p>
</div>

<script>
  var html = document.getElementById('main').innerHTML;
  console.log(html);
</script>
```

コンソールに出力されるのは

```html
<p><div>foo</div></p>
```

だと期待するかもしれませんが、実際は

```html
<p></p>
<div>foo</div>
<p></p>
```

という文字列が返ってきます。jQuery.html() の場合も同じ結果になります。

なぜこのようなことが起こるのでしょうか？不思議に思い、[Quora](http://www.quora.com/Why-does-innerHTML-or-jQuery-html-return-a-different-value-for-different-browsers-when-used-with-this-markup) で質問を投げてみました。すると、すぐにどなたかが答えてくれました。（Quora すげー！）また、Twitter でも同様の質問を投げてみたところ、[@hogenishi1122](http://twitter.com/#!/hogenishi1122/status/43640487340556288) さんが答えてくれました。（感謝！）

innerHTML や jQuery.html() は HTML のソースをそのまま返すわけではなく、ブラウザが一度 DOM ツリーに変換したものを返すとのこと。従って、invalid な HTML コードだと、ブラウザが解釈した DOM ツリーが返ってくるというわけでした。

invalid な HTML を書かなければ、さほど問題にはならないかもしれませんが、必ずしも世の中がすべて valid だとは限りません。記憶の片隅に留めておけば、無用な苦労をすることもないかと思います。


innerHTML や jQuery.html() は HTMLをそのまま取得できるわけではない


これは [CSS Preprocessor Advent Calendar 2012](http://www.adventar.org/calendars/1) の 5 日目の記事です。

今日はあまり知られていない Sass の **if 関数**について紹介したいと思います。

Sass には、条件分岐のための制御構文として @if ディレクティブ（いわゆる if 文）が用意されています。

```scss
$type: ocean;

p {
  @if $type == ocean {
    color: blue;
  } @else {
    color: black;
  }
}
```

Sass の紹介記事の中では必ずと言っていいほど出てきますし、皆さんも一度は使ったことがあるのではないでしょうか。

実はこの @if ディレクティブ以外に、Sass には [if 関数](http://sass-lang.com/documentation/Sass/Script/Functions.html#if-instance_method)が標準で用意されています。

上のコードを if 関数を使って書き直すと、次のようになります。

```scss
$type: ocean;

p {
  color: if($type == ocean, blue, black);
}
```

1 行で非常に簡潔に書くことができました。🙂

@if ディレクティブとの一番の違いは、値でしか利用できない点です。例えば、次のようにプロパティごと返そうとしてもエラーになります。

```scss
$type: ocean;

p {
  if($type == ocean, color: blue, color: black);
}
```

複数の条件分岐があるケースはこのようになります。ただし、コードの可読性が落ちるので、素直に @else if を使ったほうがよいように思います。

```scss
$type: monster;

p {
  color: if($type == ocean, blue, if($type == matador, red, black));
}
```

このように、使い道は @if ディレクティブよりも限定されますが、うまく使うと、スマートにコードを書くことができます。例えば、以下は [Compass](http://compass-style.org/) の中で実際に使われている事例です。

```scss
@mixin transform-origin(
  $origin-x: $default-origin-x,
  $origin-y: $default-origin-y,
  $origin-z: false,
  $only3d: if($origin-z, true, false)
) {
  $origin: unquote('');
  @if $origin-x or $origin-y or $origin-z {
    @if $origin-x {
      $origin: $origin-x;
    } @else {
      $origin: 50%;
    }
    @if $origin-y {
      $origin: $origin $origin-y;
    } @else {
      @if $origin-z {
        $origin: $origin 50%;
      }
    }
    @if $origin-z {
      $origin: $origin $origin-z;
    }
    @include apply-origin($origin, $only3d);
  }
}
```

第 4 引数 `$only3d` の初期値は、第 3 引数 `$origin-z` の値によって `true` か `false` がセットされるようになっていますが、if 関数を使うことで非常にわかりやすいコードになっているのが見てわかるかと思います。

というわけで、if 関数の紹介でした。


Sass の if 関数

Angular 2: Component のスタイル実装と CSS のカプセル化

webpack で moment.js の無駄なロケールファイルを除去する

CI のビルド時に patch を適用する際の注意点

Vanilla JS や TypeScript で Custom Elements を書く際の注意点

WebdriverIO + ヘッドレス Chromeでローカルブラウザテスト

[lit-html が v0.9.0 で ShadyCSS をサポートするようになった](https://github.com/Polymer/lit-html/blob/ea3e8bfc321d30e132afa49d9452d7e48c3d5b13/CHANGELOG.md#090---2018-02-01)ということなので、いろいろと調べてみた。

## TL;DR

- 現時点では、Shadow DOM のスタイルカプセル化に対応するには ShadyCSS を使う必要がある。
- lit-html 経由で ShadyCSS を使うと便利。

## Shadow DOM の Polyfill

2018 年 2 月現在、各ブラウザの Shadow DOM v1 のサポート状況は次のようになっている。

- Chrome と Opera は済み 🙆‍
- Safari と iOS Safari は一部バグあり 🤔
- Firefox と Edge はまだ 🙅‍

（参考：[https://caniuse.com/#feat=shadowdomv1](https://caniuse.com/#feat=shadowdomv1) ）

したがって、幅広いブラウザに対応するには、 現段階では [Web Components の Polyfill](https://github.com/webcomponents/webcomponentsjs) (`webcomponents.js`) の利用が前提となる。

Polyfill には `webcomponents-lite.js` や `webcomponents-sd-ce.js` などターゲットブラウザとサポートしたい仕様に応じていくつかのファイルが公開されているが、これらのうち「Shady DOM/CSS をサポート」となっているものには、実は「[**Shadow DOM のスタイルがカプセル化されない**](https://github.com/webcomponents/webcomponentsjs#shadowdom-css-is-not-encapsulated-out-of-the-box-)」という問題がある。（Shady CSS をサポートって書いてあるのに！！）

## Shadow DOM のスタイルカプセル化とは

例えば `<my-avatar>` という次のような Custom Element があったとする。

```javascript
import { html, render } from 'lit-html';

class MyAvatar extends HTMLElement {
  //...
  _render() {
    const template = html`
      <style>
        img {
          border-radius: 50%;
          border: 1px solid #ccc;
        }
      </style>
      <img src="${this.src}" width="160" height="160" />
    `;
    render(template, this.attachShadow({ mode: 'open' }));
  }
}
```

`element.attachShadow()` で Shadow DOM を生成しているので、ここで定義した `<img>` のスタイルは Shadow DOM 内にのみ適用される = カプセル化されているというのが期待する挙動だ。

それを確認するために、次のような HTML を用意してみる。

```html
<img src="https://randomuser.me/api/portraits/lego/7.jpg" width="160" />
<my-avatar src="https://randomuser.me/api/portraits/lego/7.jpg"></my-avatar>
```

Chrome 64 と Firefox 58 でそれぞれ確認した結果がこれ。

<figure>
  <img src="/images/posts/2018-02-15-result-in-chrome.png" alt="Chromeでの結果（左：<img>　右：<my-avatar>）" width="346" height="169" />
  <figcaption>Chrome 64 での結果（左：<code>&lt;img&gt;</code>　右：<code>&lt;my-avatar&gt;</code>）</figcaption>
</figure>

<figure>
  <img src="/images/posts/2018-02-15-result-in-firefox.png" alt="Firefox 58 での結果（左：<img>　右：<my-avatar>）" width="346" height="169" />
  <figcaption>Firefox 58 での結果（左：<code>&lt;img&gt;</code>　右：<code>&lt;my-avatar&gt;</code>）</figcaption>
</figure>

Chrome では、期待どおり `<my-avatar>` にだけスタイルが適用されているのがわかる。

しかし、Firefox の場合、`<my-avatar>` で定義したスタイルが通常の `<img>` にも適用されてしまっている。Shadow DOM 内のスタイルが外に漏れ出しているのだ。逆に Shadow DOM の外で定義されたスタイルも Shadow DOM 内を汚染することになる。

## ShadyCSS とは

この問題を解決するためのライブラリ（Polyfill）が ShadyCSS だ。「スタイルのカプセル化」をサポートしたい場合、`webcomponents.js` の Polyfill に加えて、ShadyCSS も使う必要がある。

[https://github.com/webcomponents/shadycss](https://github.com/webcomponents/shadycss)

ShadyCSS の処理を通すと、Firefox などのブラウザでは、上記の `<my-avatar>` のコードが次のように擬似的な Scoped Style に変換される。

```html
<head>
  <style scope="my-avatar">
    img.kz-avatar {
      border-radius: 50%;
      border: 1px solid #ccc;
    }
  </style>
</head>
<body>
  <kz-avatar src="https://randomuser.me/api/portraits/lego/7.jpg">
    <img class="style-scope kz-avatar" src="https://randomuser.me/api/portraits/lego/7.jpg" height="160" width="160" />
  </kz-avatar>
</body>
```

ただ、[Usage](https://github.com/webcomponents/shadycss#usage) にあるように素で使おうとすると結構めんどくさいコードを書く必要がある。

でも、lit-html 経由で ShadyCSS を利用するととても簡単に書くことができる。

## lit-html で ShadyCSS を使う

というわけで、ようやく本題。

lit-html で ShadyCSS を利用するには、 `lit-html` の `render()` の代わりに `lit-html/lib/shady-render.js` の `render()` を使う。

```javascript
import { html, render } from 'lit-html/lib/shady-render.js';

class MyAvatar extends HTMLElement {
  static get is() {
    return 'my-avatar';
  }
  //...
  _render() {
    const template = html`
      <style>
        img {
          border-radius: 50%;
          border: 1px solid #ccc;
        }
      </style>
      <img src="${this.src}" width="160" height="160" />
    `;
    render(template, this.attachShadow({ mode: 'open' }), MyAvatar.is);
  }
}
window.customElements.define(MyAvatar.is, MyAvatar);
```

`lit-html` の `render()` との違いは、第三パラメータにスコープ名を渡す必要がある点。ここで渡した値が `<style>` の scope 属性にセットされる。これは、タグ名と一致している必要がある。いずれにせよ、最小限のコードで ShadyCSS が使えるのはうれしい。

ただし、制約もあって、例えば、

```javascript
const template = html`
  <style>
    img {
      width: ${this.size}px;
    }
  </style>
  <img src="${this.src}" width="160" height="160" />
`;
```

というように、 `<style>` の中で変数を展開しようとすると、

```html
<style scope="my-avatar">
  img.kz-avatar {
    width: <!-- {
      lit-8364277839110217
    }
  }
</style>
```

というように変換されてしまってうまくいかない。こういうユースケースに対応したいならば、おとなしく Polymer などのライブラリを利用するほうがよいだろう。

## まとめ

というわけで、Firefox と Edge が Shadow DOM をサポートするまでは、**lit-html + ShadyCSS** の組み合わせが有力な選択肢になりそう。

lit-html と ShadyCSS


_この記事は「Nuxt.js で Markdown ベースのブログを構築する」シリーズの一部です。_

- [_Nuxt.js で Markdown ベースのブログを構築する（Markdown 編）_](/posts/2018-01-17/build-a-blog-with-nuxtjs-and-markdown-1)
- [_Nuxt.js で Markdown ベースのブログを構築する（Nuxt.js 編）_](/posts/2018-01-18/build-a-blog-with-nuxtjs-and-markdown-2)
- _Nuxt.js で Markdown ベースのブログを構築する（サイトパフォーマンス編）_ ← ここ

---

今回はサイトのパフォーマンスをあげるためにやったことをまとめる。

## サイト構築初期の状態

サイトを構築したばかりの頃の Lighthouse のスコアは次のような感じだった。

<figure>
  <img src="/images/posts/2018-01-24-lighthouse-report-1.png" alt="サイト構築初期のLighthouseのスコア" width="1336" height="240" />
  <figcaption>サイト構築初期の Lighthouse のスコア</figcaption>
</figure>

「Progressive Web App」のスコアが低いのは、Service Worker を使っていなかったのが要因で、「Accessibility」と「SEO」のスコアが低いのは、単に自分が書いたマークアップの品質が低かったため。

注目すべきは「Performance」と「Best Practices」の 2 つだ。特別なことはそれほどしていないにも関わらず、はじめから非常に高いスコアが出ていた。**Nuxt.js** と **Netlify** を使ったおかげと言える。

### Nuxt.js の恩恵

Nuxt.js は、特に設定しなくても、

- コード分割（Code splitting）
- CSS の HTML へのインライン展開
- Resource Hints によるリソースの事前取得の設定

といった、Web フロントエンドの最新のベストプラクティスを自動でやってくれる。この点は、Web フロントエンド界隈から生まれたフレームワークの強みで、以前からある Jekyll や Hugo といった静的サイトジェネレーターとの決定的な差だと思う。

### Netlify の恩恵

Netlify は、

- HTTP2
- SSL

といった、サイトパフォーマンスには欠かせない機能を無料で提供してくれるのがありがたい。しかも設定がとても簡単で、SSL なんかはボタンを 1 クリックするだけで作業が完了して感動した。

## 追加でやったこと

というわけで、あとは細かい点をチューニングするだけだった。主にやったことはこんな感じ。

### バンドルファイルの最適化

- `nuxt build --analyze`（または [build プロパティの analyze オプション](https://ja.nuxtjs.org/api/configuration-build#analyze)）を使って、バンドルファイルの中身を分析
  - Qiita API のレスポンスをまるごと含まれた巨大な JSON ファイルがバンドルされていたのを発見。最小限のフィールドのみを保存するようにした。

### PWA 化（Service Worker の導入）

- [Nuxt.js の PWA モジュール](https://github.com/nuxt-community/pwa-module/) を利用した。

### アクセシビリティ対応

- SVG のアクセシビリティ対応
- テキスト色のコントラストを調整した。
  - [Chrome 64 から使える DevTools の新機能](https://developers.google.com/web/updates/2018/01/devtools#contrast)が便利だった。
- アクセシビリティについては、まだまだ勉強不足。。。

### HTTP/2 Server Push

- [HTTP/2 Server Push on Netlify \| Netlify](https://www.netlify.com/blog/2017/07/18/http/2-server-push-on-netlify/) を参照。
- [自前の Nuxt.js モジュール](https://gist.github.com/jmblog/8f75d0c941ec823e4d641d08189d3d43)を書いてやってみた。
- けど、ほとんどパフォーマンス上の変化はなかった。

## 結果

ほぼ 100 点になった 🎉 （Performance は計測するごとに多少のばらつきがあるが 90 点以上は出てる。）

<figure>
  <img src="/images/posts/2018-01-24-lighthouse-report-2.png" alt="チューニング後のLighthouseのスコア" width="1336" height="241" />
  <figcaption>チューニング後の Lighthouse のスコア</figcaption>
</figure>

## まとめ

シンプルなサイトだということもあるが、Nuxt.js と Netlify のおかげで、わりと簡単にパフォーマンスの高いサイトを構築することができた。とはいえ、時間の経過とともに、問題も出てくるだろうから、定期的にチェックしていきたい。

ちなみに、サイトパフォーマンスの改善方法については、[超速! Web ページ速度改善ガイド](http://amzn.to/2F7Cf1N)がとても参考になる。基本的な知識から最新の Web 技術まで体系的に学べる良書でおすすめです。


Nuxt.js で Markdown ベースのブログを構築する（サイトパフォーマンス編）


_この記事は「Nuxt.js で Markdown ベースのブログを構築する」シリーズの一部です。_

- [_Nuxt.js で Markdown ベースのブログを構築する（Markdown 編）_](/posts/2018-01-17/build-a-blog-with-nuxtjs-and-markdown-1/)
- _Nuxt.js で Markdown ベースのブログを構築する（Nuxt.js 編）_ ← ここ
- [_Nuxt.js で Markdown ベースのブログを構築する（サイトパフォーマンス編）_](/posts/2018-01-24/build-a-blog-with-nuxtjs-and-markdown-3/)

---

今回は Nuxt.js 側の実装について紹介する。

## 記事ページの実装

本ブログでは、記事ページの URL を `/posts/YYYY-MM-DD/xxx-yyy-zzz/` というルールにしている。このような動的なルーティングを Nuxt.js で実装するには、

```bash
pages
└── posts/
    └── _date/
       └── _slug/
            └── index.vue
```

というディレクトリ構造にするだけで済む。`_` で始まるディレクトリ名はパラメータとして扱われる。つまり、 `_date` と `_slug` がそれぞれ `YYYY-MM-DD` と `xxx-yyy-zzz` に該当する。

`pages/posts/_date/_slug/index.vue` の中身を見てみよう。

```html
<template>
  <div>
    <h1>{{ title }}</h1>
    <div class="post-meta"><time>{{ params.date }}</time></div>
    <div v-html="bodyHtml"></div>
  </div>
</template>

<script>
  import { sourceFileArray } from '../../../../content/posts/json/summary.json';

  export default {
    validate({ params }) {
      return sourceFileArray.includes(`content/posts/${params.date}-${params.slug}.md`);
    },
    asyncData({ params }) {
      return Object.assign({}, require(`~/content/posts/json/${params.date}-${params.slug}.json`), { params });
    },
    head() {
      const title = `${this.title} - jmblog.jp`;
      const url = `https://jmblog.jp/posts/${this.params.date}/${this.params.slug}/`;
      return {
        title: title,
        meta: [
          { hid: 'og:url', property: 'og:url', content: url },
          { hid: 'og:title', property: 'og:title', content: title },
        ],
        link: [{ rel: 'canonical', href: url }],
      };
    },
  };
</script>

<style>
  @import 'assets/tomorrow-night-bright.css';
</style>

<style lang="scss" scoped>
  .post-meta {
    font-size: 0.8em;
    color: #888;
    margin-top: -1rem;
    margin-bottom: 2.4rem;
    text-align: right;
  }
</style>
```

Vue.js の[単一ファイルコンポーネント](https://jp.vuejs.org/v2/guide/single-file-components.html)になっていて `<template>`、`<script>`、`<style>` の 3 つで構成されている。

### `<template>`

`<template>` の中はすごくシンプル。後述する `<script>` の asyncData メソッドで用意したデータ（タイトルと投稿日と Markdown から変換した HTML）を流し込んでいるだけ。

### `<script>`

`<script>` がこのファイルのメインとなる。

まず [validate メソッド](https://ja.nuxtjs.org/api/pages-validate)で、アクセスされたページが実際に存在しているかをチェックしている。ここでは、[前回の記事](/posts/2018-01-17/build-a-blog-with-nuxtjs-and-markdown-1)で紹介した `summary.json` の `sourceFileArray`フィールドに、対象の Markdown ファイルのパスが含まれているかどうかで、ページの存在を判定している。

ちなみに `params` という引数が渡ってきているが、ここには先ほど説明した `pages/` 以下の `_` で始まるディレクトリ名とその値がセットされている。

つまり、`/pages/2018-01-01/new-post/` という URL にアクセスした場合、`params` の中身は

```js
params = {
  date: '2018-01-01',
  slug: 'new-post',
};
```

のようになる。

[asyncData メソッド](https://ja.nuxtjs.org/api/)では、該当する記事ページの JSON ファイル（Markdown ファイルから変換したもの）を読み込んでいる。JSON オブジェクトだし、Markdown で書いた本文も HTML に変換済みなので、そのまま return して `<template>` に渡すだけで済む。

最後に [head メソッド](https://ja.nuxtjs.org/api/pages-head)では、`<head>` の中身（title とか description）をセットしている。

### `<style>`

`<style>` で import しているのは highlight.js 用のテーマ CSS。ちなみに、[以前私が作って、本家のリポジトリに取り込まれた](https://github.com/isagalaev/highlight.js/commit/7dfa2563c398101e823812887c0c03b2db99328d#diff-65609631df92589b6b2aef575aa6c85c)ファイルだったりする。

## 静的ファイルの書き出し

Nuxt.js では `nuxt generate` コマンドで HTML ファイルが生成することができるが、動的なルーティングは無視されるため、そのままだと各記事ページは生成されない。これらの HTML ファイルも生成するには `nuxt.config.js` の generate オプションを使う必要がある。ここでも `summary.json` が活躍する。

```js
const { sourceFileArray } = require('../content/posts/json/summary.json');
const sourceFileNameToUrl = require('./sourceFileNameToUrl');

const generateDynamicRoutes = (callback) => {
  const routes = sourceFileArray.map((sourceFileName) => {
    return sourceFileNameToUrl(sourceFileName);
  });
  callback(null, routes);
};

module.exports = {
  //...
  generate: {
    routes: generateDynamicRoutes,
  },
  //...
};
```

これで `dist` ディレクトリには `posts/2018-01-01/new-blog/index.html` といったファイルが生成されるようになる。

## sitemap.xml の生成

`sitemap.xml` は [@nuxtjs/sitemap](https://github.com/nuxt-community/sitemap-module) を使えば簡単に生成できる。

npm か yarn でインストールしたあと、`nuxt.config.js` に追加する。

```js
module.exports = {
  //...
  modules: ['@nuxtjs/sitemap'],
  sitemap: {
    path: '/sitemap.xml',
    hostname: 'https://jmblog.jp',
    generate: true,
    exclude: ['/404'],
    routes: generateDynamicRoutes,
  },
};
```

動的ルーティングはやはりデフォルトでは無視されるため、`routes` オプションに、上で説明した `generate` と同じものを渡す必要がある。

## まとめ

というわけで、かなりお手軽に Nuxt.js で Markdown ベースのブログシステムを構築することができた。

Nuxt.js は[公式ドキュメント](https://ja.nuxtjs.org/)が充実していてほとんど迷うことがなかったし、Vue.js の[単一ファイルコンポーネント](https://jp.vuejs.org/v2/guide/single-file-components.html)もかなり書き心地がよかった。（もう少し複雑な Web アプリケーションになると違ってくるかと思うが。）

Nuxt.js といえば、サーバーサイドレンダリングのためのフレームワークだという印象だったのだが、静的ファイルジェネレーターとしてもかなり使いみちが広いんじゃないかと今回感じた。機会があればまた使ってみたいと思う。

[サイトパフォーマンス編](/posts/2018-01-24/build-a-blog-with-nuxtjs-and-markdown-3) に続く。


Nuxt.js で Markdown ベースのブログを構築する（Nuxt.js 編）


_この記事は「Nuxt.js で Markdown ベースのブログを構築する」シリーズの一部です。_

- _Nuxt.js で Markdown ベースのブログを構築する（Markdown 編）_ ← ここ
- [_Nuxt.js で Markdown ベースのブログを構築する（Nuxt.js 編）_](/posts/2018-01-18/build-a-blog-with-nuxtjs-and-markdown-2)
- [_Nuxt.js で Markdown ベースのブログを構築する（サイトパフォーマンス編）_](/posts/2018-01-24/build-a-blog-with-nuxtjs-and-markdown-3)

---

本ブログは、

- Markdown で記事を書き、
- Nuxt.js の[静的ファイル生成機能](https://ja.nuxtjs.org/guide#%E9%9D%99%E7%9A%84%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AE%E7%94%9F%E6%88%90)を使って静的ファイルを書き出し、
- Netlify を使ってホスティングする

というシステム構成になっている。具体的にどのようにしているか簡単に紹介する。

## processmd を使った Markdown ファイルの変換処理

それぞれのブログ記事は `YYYY-MM-DD-xxxxx.md` という Markdown ファイルに書いている。ファイルの先頭に YAML front matter でメタ情報を記述するという、ブログ記事によく見られるフォーマットになっている。

````text
---
title: 記事のタイトル
created_at: 2018-01-01
---

## 見出し 2

本文です。

```javascript
const f = () => {};
```
````

この Markdown ファイルは、Nuxt.js の中で変換処理を行うと複雑になるので、あらかじめ Nuxt.js（というか JS）で扱いやすいように、JSON ファイルに変換している。

この処理に使っているのが [processmd](https://www.npmjs.com/package/processmd) という CLI ツールで、これがとても便利だった。

例えば、上にあげたような Markdown ファイルを `processmd` コマンドに渡すと

````json
{
  "title": "記事のタイトル",
  "created_at": "2018-01-01T00:00:00.000Z",
  "bodyContent": "## 見出し 2\n\n本文です。\n\n```javascript\nconst f = () => {};\n```",
  "bodyHtml": "<h2>見出し 2</h2>\n<p>本文です。</p>\n<pre><code class=\"hljs\"><span class=\"hljs-keyword\">const</span> f = <span class=\"hljs-function\"><span class=\"hljs-params\">()</span> =&gt;</span> {};</code></pre>",
  "dir": "content/posts",
  "base": "2018-01-01-test.json",
  "ext": ".json",
  "sourceBase": "2018-01-01-test.md",
  "sourceExt": ".md"
}
````

といった JSON ファイルに変換してくれる。Front matter で書いたメタ情報はそれぞれフィールドとなり、`bodyContent` には元の Markdown が、 `bodyHTML` にはそれを [markdown-it](https://github.com/markdown-it/markdown-it) で HTML に変換した値が含まれる。

よく見てもらえばわかるように、コードブロックは [highlight.js](https://highlightjs.org/) が適用された状態の HTML で書き出されるので、あとは highlight.js 用のテーマ CSS を読み込むだけで、簡単にシンタックスハイライトが導入できる。

また、`--stdout` というオプションをつけると、同時にサマリーファイルも書き出すことができる。

```bash
$ processmd content/posts/**/*.md --stdout --outputDir content/posts/json > summary.json
```

summary.json はこんな感じ。

```json
{
  "fileMap": {
    "content/posts/json/2007-09-25-link-visited-hover-active.json": {
      "title": ":link、:visited、:hover、:active の記述順序とその覚え方",
      "created_at": "2007-09-27T00:00:00.000Z",
      "dir": "content/posts/json",
      "base": "2007-09-25-link-visited-hover-active.json",
      "ext": ".json",
      "sourceBase": "2007-09-25-link-visited-hover-active.md",
      "sourceExt": ".md"
    },
    "content/posts/json/2012-12-05-sass-if-function.json": {
      "title": "Sass の if 関数",
      "created_at": "2012-12-05T00:00:00.000Z",
      "dir": "content/posts/json",
      "base": "2012-12-05-sass-if-function.json",
      "ext": ".json",
      "sourceBase": "2012-12-05-sass-if-function.md",
      "sourceExt": ".md"
    },
    "content/posts/json/2011-03-21-innerHTML-returns-serialized-html.json": {
      "title": "innerHTML や jQuery.html() は HTMLをそのまま取得できるわけではない",
      "created_at": "2011-03-21T00:00:00.000Z",
      "dir": "content/posts/json",
      "base": "2011-03-21-innerHTML-returns-serialized-html.json",
      "ext": ".json",
      "sourceBase": "2011-03-21-innerHTML-returns-serialized-html.md",
      "sourceExt": ".md"
    }
  },
  "sourceFileArray": [
    "content/posts/2007-09-25-link-visited-hover-active.md",
    "content/posts/2011-03-21-innerHTML-returns-serialized-html.md",
    "content/posts/2012-12-05-sass-if-function.md"
  ]
}
```

Markdown ファイル名に日付（YYYY-MM-DD）を使っておくと `sourceFileArray` は日付順に並ぶので、記事一覧リストの実装にそのまま利用することができた。

また、本ブログでは使っていないが `--preview` オプションを使うと、指定した文字分だけコンテンツの先頭をテキストで書き出してくれる。「記事一覧リストに本文の概要を載せたい」といった場合に便利だと思う。

````json
{
  "title": "記事のタイトル",
  "created_at": "2018-01-01T00:00:00.000Z",
  "bodyContent": "## 見出し 2\n\n新しいブログ記事です。\n\n```javascript\nconst f = () => {};\n```",
  "bodyHtml": "<h2>見出し 2</h2>\n<p>新しいブログ記事です。</p>\n<pre><code class=\"hljs\"><span class=\"hljs-keyword\">const</span> f = <span class=\"hljs-function\"><span class=\"hljs-params\">()</span> =&gt;</span> {};</code></pre>",
  "preview": "見出し 2\n\n新しいブログ記事です。\n\nconst f = () = {};\n`"
}
````

[Nuxt.js 編](/posts/2018-01-18/build-a-blog-with-nuxtjs-and-markdown-2) に続く。


Nuxt.js で Markdown ベースのブログを構築する（Markdown 編）


2013 年から長らく放置していたブログを新しくした。

以前のブログは WordPress を使っており、時折 WordPress 自体のアップデートはしていたものの、ほとんどの記事は古くて役に立たなくなっていたし、HTTPS 化もしていなかったし、スパムコメントも届いていたしで、インターネットを汚しているなぁという罪悪感がずっとあった。昨年末の休みに、ようやく重い腰を上げて作り直した。

今回は WordPress をやめて Nuxt.js を採用した。詳しくは別途投稿しようと思う。

古い記事については、アクセスがあって、内容もまだ賞味期限が切れていなさそうなものだけピックアップして移行した。また、最近は Qiita へもいくつか投稿していたため、API で取得して記事一覧に追加した。

ホスティングは Netlify を使っている。いいサービスだと聞いていたが、実際に使ってみると UI もわかりやすく、デプロイも驚くほど簡単で感動した。HTTPS 化もあっけなく完了。

長年の懸念をようやく払拭できて、すっきりした。2018 年もがんばっていこう。


Nuxt.js を使ってブログを新しくした


2019 年を振り返ってみる。

# 仕事

約 6 年間勤めた Kaizen Platform を退職して、Ubie 株式会社に転職した。（人生 3 度目の転職）

1 月末が Kaizen Platform の最終出社で、有給休暇を消化しながら、2 月から Ubie で働き出した。2 月の 1 ヶ月間は、東京に滞在してオンボーディング。普段会えない友人たちともひさびさに会うこともできた。

最初に担当したのは、[AI 問診 Ubie](https://introduction.dr-ubie.com/) のタブレット問診機能のフロントエンド開発。当初は Rails の上に React の SPA が乗っかっていたので、脱 Webpacker をし、 Rails への依存をなくした。また、JavaScript と TypeScript が混在している状態だったので、こちらも TypeScript へ完全移行した。

コードベースの整備はうまく進められたが、プロダクトの機能開発は、チームとしてあまりうまく進めることができずにいた。しかし、スクラム開発を導入し、チーム構成とプロジェクトの進め方を見直したことで、状況は劇的に改善された。（詳しくは、
[こちらの資料](https://speakerdeck.com/shikichee/three-challenges-of-medical-startup?slide=50)を参照。）ちゃんとしたスクラム開発ははじめてだったが、こうも変わるものかとちょっと感動した。

6 月から 9 月までは、品質をあげつつ、高齢者向けの UI 改善施策を多く行った。その内容は [FRONTEND CONFERENCE 2019 で発表](https://jmblog.jp/posts/2019-11-03/frontend-conrefence-2019/)することができた。

9 月からは Vue.js（Nuxt.js）を使った別プロダクトを担当している。「AI 問診 Ubie」が拡大フェーズに入ってきた一方、こちらのプロダクトはまだまだ検証を進めているフェーズなので、より緊張感を持ちながらも毎日楽しみながら過ごしている。Vue.js はほぼ初めて触るが、正直、まだ手に馴染んでこない。Composition API も試験的に導入してみたので、もう少し様子を見てみたい。また、Firebase もがっつり触ることができてよかった。

会社自体は、自分が入社したときには 20 名くらいだったが、12 月には 2 倍近くに増えた。東京オフィスに行くたびに知らない顔が増えていて、勢いを感じる。人が増え、プロダクトが拡大していくなか、当然問題もいろいろ出てくるが、それらをすばやく解決しながらさらに前に進んでいくという体験は、スタートアップならではの面白さだと思う。

2020 年も大いに楽しみたい。

# プライベート

3 月に福岡へ旅行に行った。

夏休みには青森へ旅行に行った。

キャンプは 3 回行った。

ガンバ大阪の試合はホーム最終戦だけスタジアムで観戦した。

頻繁に腰を痛めるようになってきた。

2020 年は体を鍛えたい。


2019年振り返り


11/3 にグランフロント大阪で開催された FRONTEND CONFERENCE 2019 で「高齢者でも使えるプロダクト UI の挑戦」というタイトルで発表しました。

[高齢者でも使えるプロダクト UI の挑戦 / Designing User Interfaces for the Elderly \- Speaker Deck](https://speakerdeck.com/jmblog/designing-user-interfaces-for-the-elderly)

高齢者にも使ってもらえるプロダクトにするために、これまで地道に改善を続けてきたことを事例として共有するという内容でしたが、ありがたいことに、発表後たくさんの質問をいただきました。その場でうまく回答できなかった部分もあったので、あらためてこの場で回答をさせてもらいたいと思います。

### 「色覚障害の見え方をチェックするためのおすすめのツールは？」

スライドの中でも紹介した [NoCoffee](https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbnhckmgdhmgdckeigabjfbddl) という Chrome 機能拡張以外に、Mac アプリでは [Sim Daltonism](https://apps.apple.com/jp/app/sim-daltonism/id693112260) が使いやすくおすすめです。

### 「50px ってどうやって決めた？」

このスライドにある「50px」という数字はどのように決めたのかという質問でした。

<img src="/images/posts/2019-11-03-slide-41.png" alt="Slide No.41" width="1922" height="1082" />

その場では「えいやで決めました」と回答してしまったのですが、過去のチケットを探ってみたら、ちゃんと経緯が書いてありました。

Apple の Human Interface Guidelines では、コントロール要素のタップ領域を 44pt 以上の大きさにするよう定められています（[参考](https://developer.apple.com/jp/design/tips/)）。この数字をベースに、指の揺れ幅を加味した結果「50px」にしたとのことでした。（ちなみに、この数字をあまり大きくしてしまうと、今度はスクロールがうまく効かなくなってしまうので注意が必要です。）

### 「高齢者のユーザービリティをあげると、他の年代の人にとって使いにくものにはならないか？」

高齢者にとって使いやすいものが必ずしも他の年代の人にとって使いやすいものにはならないかもしれないが、どのように考慮しているか、という質問でした。

例えば、パソコンやスマホを日常的に利用している人にとっては、「あいうえお配列のキーボード」で入力するよりも、普通にテキスト入力をするほうが使いやすいというのは間違いないと思います。ただ、そういったユーザーでも「あいうえお配列キーボード」が使えないということはないはずです。今のフェーズでは、あらゆる年代の方が自分の症状をタブレットで正確に伝えきるというタスクを遂行してもらうことが最も重要であり、若年層は多少回りくどい操作であっても使いこなせてしまうので、現時点では「使いやすさ」を追求するよりは、高齢者でも「使える」レベルにプロダクトを引き上げることに注力しています。このレベルをクリアできるようになったら、「使いやすさ」や「使って心地よい体験」というさらに上のレベルを目指していければと思います。

### 「左右の入れ替えで左利きのひとの考慮は？」

レイアウトを左右に入れ替えたというこのスライドについて、左利きの人だと問題が解決しないのではというご指摘でした。

<img src="/images/posts/2019-11-03-slide-56.png" alt="Slide No.56" width="1922" height="1082" />

まさに仰るとおりで、利き手に関係なく使えるようなレイアウトにするべきですし、そもそもこの画面は、他と比べて行うべきタスクが多く、ユーザーが最も難しさを感じる箇所でもあるので、まだまだこの画面には課題が多くあるとチームでも認識しています。引き続き改善をしていきたいと思います。

### 「チームがうまく機能しているように感じるのだが、どういう工夫をしているのか？」

その場では簡単に「スクラムがうまく機能しているおかげ」と回答しましたが、他の社員が別のイベントで発表した資料に、チームづくりの話が詳しく出てきますので、ぜひご覧ください。（前半は、今回の私の発表と重複した内容になっています。）

[高齢者 UI への取り組みと自発的改善チームの作り方 / Elderly UI and Scrum Team \- Speaker Deck](https://speakerdeck.com/shikichee/elderly-ui-and-scrum-team)

### 最後に

自分の発表を聞きに来てくださった方々、ありがとうございました。何か一つでも普段の業務に生かせるヒントとなれば幸いです。

FRONTEND CONFERENCE には毎年参加しているのですが、エンジニアリングとデザインの話がバランス良く聞けて、いつも刺激をもらえます。今年も多くの素晴らしい発表がありました。運営スタッフの皆さん、ありがとうございました。来年も参加できることを楽しみにしています！


FRONTEND CONFERENCE 2019 に登壇しました


2020 年を振り返ってみる。

## ポルトガル旅行の中止

長女も中学生となり、家族で海外旅行ができるのも今年がラストチャンスになりそうだと思い、年初からポルトガル旅行の計画を立てていた。フライトを予約し、宿泊先を Airbnb で確保し、あとは行くだけと楽しみにしていたが、2 月半ばから新型コロナウイルスの影響で雲行きが怪しくなってくる。3 月頭にはヨーロッパでも感染が広がり、フライトもキャンセルとなってしまった。次はいつ行けるのか...

## 小中学校の休校

3 月 2 日から臨時休校となり、6 月になってようやく再開となった。長女が通っている塾ではしばらくしてオンライン授業がはじまったが、公立の小中学校では 3 ヶ月間自宅学習のみ。対応力の差を如実に感じた。子どもたちにとっては、早起きしなくていいし、わからないところは親に聞いたり YouTube の映像授業で調べれば済むしで、そんなに困ることもなかったっぽいが、親にとっては非常事態でいろいろ気を揉むことが多かった。

## 体づくり

去年の振り返りで「2020 年は体を鍛えたい。」と書いたが、今年は家にいる時間が長かったので、継続的に体づくりができた。2 月には家族全員で「1 ヶ月プランクチャレンジ」をやりきったし、その後も YouTube でお気に入りのパーソナルトレーナーのチャンネルを見ながら定期的に体を動かせた。その結果、ずっと悩まされていたぎっくり腰も今年は 1 回もかからずに過ごすことができた。

## 仕事

ヘルステック（医療 x テクノロジー）のスタートアップである Ubie にとって、新型コロナの影響は非常に大きかった。現在開発を担当している生活者（toC）向けサービス「[AI 受診相談ユビー](https://ubie.app)」は、感染拡大をうけて、当初の計画を大幅に前倒して 4 月 28 日に緊急リリースした。その後も、いくつかのニュース番組で取り上げられて喜んでいたらアクセスが集中して冷や汗をかいたり、リリースしたものの思うように数字が伸びず苦しんだり、4Q は逆に施策がはまって数字がどんどん伸びたりと、プロダクトづくりの面白さを実感する 1 年だった。

会社自体も、社員数が 3 倍になり、さまざまな組織づくりも進められ、アウトプットの多い 1 年となった。

[2020 年、20 億円の資金調達からグローバル進出まで。Ubie の 1 年間ふりかえり。｜ Ubie $ユビー$｜ note](https://note.com/ubie/n/nf72394281a31)

## 来年にむけて

おかげさまで仕事は順調だし、まだまだやることがたくさんある。この勢いのまま、来年も突き進みたい。

日常生活では、人に会う機会は激減してしまったし、常に新型コロナにおびえながら生活するのはなかなかしんどい。正月の帰省も諦めた。来年の今ごろはどんなふうになっているのか想像できないが、1 日でも早く安心してみんなで集まって騒げる日が戻ってくることを願ってる。

<img src="/images/posts/2020-12-30-looking-back-2020.jpg" alt="コロナぼくめつ！" width="1920" height="1440" />


2020年振り返り

地方で暮らしながら都内のスタートアップでのびのびと働くソフトウェアエンジニアの話


2021年を振り返る。

## プライベート

休日は引きこもってばかりの1年だった。新型コロナの影響も当然あるし、長女が高校受験の年なので、家族で出かける機会がほとんどなくなってしまったのも大きい。新型コロナウイルスのワクチン接種を行ってからは、気分的にだいぶ落ち着けたが、それでもあちこち出かけることはなく、気づいたら一年が終わってたという印象。

唯一、11月に会社のメンバーとキャンプに行けたのがいい思い出。自分以外は全員東京からの参加だったので、中間地点ということで静岡県浜松市のキャンプサイトに集まったのだが、ひさびさの長距離運転も楽しかったし、みんなで焚き火を囲んでまったりできたのはよかった。

<img src="/images/posts/2021-12-30-campfire.jpg" alt="" width="4032" height="3024" />

あと、今年は原因不明の体調不良に悩まされて、何度も病院に通った。医療費も時間もかかったうえに、結局原因ははっきりせず、もやもやだけが残った。（これが年を取るということなのかもしれない。）ただ、患者としての体験もでき、また医師への理解も深まったので、仕事をする上ではいい経験となった。初めての検査も多く、特にCT検査は宇宙船の冬眠装置みたいで興奮したし、造影剤を体内に入れた瞬間、体内が一気に熱くなって「ち、力が解放される...」という感じがしてちょっと楽しかった。（ちなみに検査結果はまったく異常なしだった。）

## 仕事

5月末に、それまで所属していた[ユビーAI受診相談](https://ubie.app)の開発チームから離れた。1年8ヶ月という長い間、いろいろな施策を試行錯誤する日々だったが、自分が抜けた途端、ユーザー数が一気に増えて、いまや会社の中心となるサービスにまで一気に成長した。（ちょっとだけ複雑な気分。うそ。とても喜ばしい。）

6月からは新規事業にゼロから携わり、0→1の難しさと楽しさを体感することができた。この経験から得た知見を[「0→1」フェーズにおける技術的負債との向き合い方](/posts/2021-09-15/how-to-deal-with-technical-debt-in-start-up-companies)という記事にまとめた。

10月からはグローバルチームに異動して、[グローバル向けのBtoCサービス](https://ubiehealth.com/)の開発に携わっている。メンバーの半数はシンガポール、残りは日本とインドというメンバー構成。コミュニケーションのほとんどが突然英語になって大丈夫かなと思ったが、今のところなんとかなっている（と思いたい）。DeepL と Grammarly と Google Meet の自動字幕というテクノロジーに助けられている面もかなりあるが、それより「ちゃんとした英語を話さなければ！」という思いがなくなり、「文法が間違っていてもいいから、とにかく伝えたいことを伝えるのだ！」とメンタル的に図々しくなったのが大きいように思う。（これも年を取るということなのかもしれない。）とにかく異なる文化を持つ同僚たちと一緒に仕事をするのがとても楽しい。

## 2022年にむけて

プライベートでは単調な一年だったので、状況が許す限り、たくさんの人と会い、様々な土地を訪れて、いろいろなものを見て、食べて、飲んで、楽しめるといいなと思う。（シンガポール出張したいなぁ。）あと、努力しないと体がどんどん老けていくのを年々実感するので、健康維持のために投資することを惜しまないようにしたい。

仕事では、放っておいても刺激的なことが日々起こる会社なので、今年同様、変化の渦を楽しもうと思う。

2022年もいい年になりますように。


2021年振り返り


[2018年に Nuxt.js を使ってブログを新しくした](/posts/2018-01-10/new-blog-with-nuxtjs)が、最近は仕事でも React しか触っていないので、Next.js に移行した。

作業ログ：[https://zenn.dev/jimbo/scraps/4226bd96c51c75](https://zenn.dev/jimbo/scraps/4226bd96c51c75)

1日足らずで移行作業がほぼ終わり「余裕余裕」と思ってたけど、Netlify の不具合を踏んで sitemap.xml と atom.xml の生成がうまくいかないことがわかり、そこから数日ハマってしまった。

時間はかかったが、おかげで [remark](https://remark.js.org/) を使った Markdown の処理に少し詳しくなれたのでよかった。

パフォーマンスも上々。

<img src="/images/posts/2021-09-26-lighthouse-report.png" alt="Lighthouseの結果" width="2038" height="1222" />


ブログを Nuxt.js から Next.js に移行した


以前から<strong>「スタートアップのなかで『技術的負債』というものをどう扱うべきなのか」</strong>というテーマに対して関心が高かったのだが、今年の6月から「0→1」の新規事業に関わるようになって、自分の中でなんとなく考えがまとまりそうなので、雑に吐き出してみる。最近、社内でも「技術的負債」が話題にあがることが多く、その中で同僚のエンジニアからあがった意見も参考にしている。

## そもそも技術的負債とは

[@t_wada](https://twitter.com/t_wada) さんの次の記事に答えが書いてある。

[【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 \- t\-wada のブログ](https://t-wada.hatenablog.jp/entry/ward-explains-debt-metaphor)

個人的には次のように解釈した。

- 「手を抜いた雑なコード」は技術的負債とは呼ばない。それはただの低品質なコードである
- 仮説検証や経験からさまざまな学びを得ることは正義
- そこで得た「学び」と「現状のソフトウェア」とのギャップを「技術的負債」と呼ぶ

このような<strong>「学びから生まれる技術的負債」</strong>に加えて、仮説検証を最速で行うために（あとで返済する前提で）わざと作り出す<strong>「計画的な技術的負債」</strong>と呼ぶべき類の負債もあるように思う。

いずれの負債も基本的にはポジティブに捉えてよいと考えている。<strong>「学びから生まれる技術的負債」</strong>はそれだけ多くの学びを得ているということだし、<strong>「計画的な技術的負債」</strong>もそれによって仮説検証を加速させることができるからだ。

難しいのは、そのようにして生まれた技術的負債を「いつ」「どのように」返済していくかということだ。

<small>これらの技術的負債のほかに、特定の顧客からの要望やビジネス上のやんごとなき事情によりプロダクトに組み込まれた<strong>「大人の事情による負債」</strong>というのもありそうだが、こちらはあまりポジティブに捉えるべきではないように思う。それらの対処法にも興味はあるが、「0→1」フェーズでは発生することは考えにくいため、この記事ではスコープ外とした。</small>

## 「0→1」フェーズにおける技術的負債

「0→1」フェーズでは必然的に「技術的負債」が大量に生まれやすい構造になっている。

まず「0→1」フェーズについて整理しておく。現在所属している [Ubie株式会社](https://ubie.life/)では、事業フェーズを次のように定義している。

<p><small>（ちなみにUbieは、担当するフェーズごとに「Ubie Discovery」と「Ubie Customer Science」という2つの組織に分かれている。私は 「0→10」を担う「Ubie Discovery」に所属している。）</small></p>

<img src="/images/posts/2021-09-15-ubie-discovery.png" alt="課題探索からPMFまで同時多発的に行うUbie Discovery" width="1370" height="470" />

「0→1」フェーズでは、<strong>PSF（Problem/Solution Fit）</strong>を目指す。PSFとは、ユーザーが抱える課題（= Problem）を発見し、それらを解決する「MVP（Minimum Viable Product）」（= Solution）が特定できている状態である。

言い換えると、「仮説はある。だが実際はどうなのか、何もわからん」状態から、<strong>仮説検証を何度も繰り返し、そこから学びを得て</strong>ユーザーの課題やプロダクトのあるべき姿を探っていくフェーズである。

「新たな学びを得ること」こそが「0→1」でやるべきことなので、多くの<strong>「学びから生まれる技術的負債」</strong>が発生するのは当然であり、健全に検証サイクルが回っている証とも言える。また、いかにすばやく仮説検証が繰り返せるかが重要になってくるため、<strong>「計画的な技術的負債」</strong>も効果的に利用していきたいところである。

とはいえ、技術的負債は必ず<strong>「返済」</strong>する必要がある。「学びを得ることは正義」とはいえ、なんでもかんでも負債として抱えると、のちのち返済に苦しむ未来は容易に想像できる。また、積み上がった技術的負債によって、仮説検証のスピードが落ちてしまっては本末転倒である。

したがって、生み出される<strong>負債の量をうまくコントロール</strong>する必要がある。

## どのように技術的負債を取り扱うか

### 「学びから生まれる技術的負債」の場合

「学び、学び」と書いているが、プロダクト開発をしていると様々な種類の学びが得られる。

- 新たに獲得したドメイン知識
- ユーザー調査などから発見した解決すべき課題
- その課題を解決するための新たなソリューション
- アーキテクチャに関するベストプラクティス
- ライブラリやフレームワークのAPIや機能に関する知見
- コードレビュー、勉強会、SNSなど様々な経路を通じて知った「もっといいコードの書き方」
- シャワーを浴びながらひらめいた実装アイディア

もっとたくさんあると思うが、次の2つに大きく分けられそうである。

1. <strong>仮説検証による学び</strong>
2. <strong>エンジニアリングに関する学び</strong>

前者の<strong>「仮説検証による学び」</strong>は多ければ多いほどよい、というのは自明だろう。

後者の<strong>「エンジニアリングに関する学び」</strong>は、エンジニアとしての成長を意味するのでよいことではあるのだが、「0→1」フェーズにおいては、<strong>そこから生まれる技術的負債が、仮説検証を妨げる要因になりがち</strong>ではないかと感じる。

ソースコードの品質が低すぎると、バグフィックスに追われてそもそも検証が進まないというのは想像しやすい。

例えば、安易な例だが「使ったことはないけど、このフレームワークは流行ってるし今回の要件に向いてそうなので採用！」というような意思決定は、仮説検証による学びよりも、新しい技術を使うことによる学び（とそこから生まれる技術的負債）に多くの気を取られてしまうためリスクが高い。すでに利用実績があって、知見が溜まっているものを選択したほうがよいだろう。

<p><small>（では「手に馴染んだ枯れたフレームワーク」を採用すればよいかというと、「0→1」に成功してその先のフェーズに進んだときに「時代遅れのフレームワーク」になっていて、世の中に広まっている新たなベストプラクティスを採用しづらい状況になっている、というようなこともありうるので難しい。）</small></p>

また、「0→1」フェーズでは細かな単位で「作っては捨て、作っては捨て」を繰り返す。未熟なアーキテクチャや全体設計になっていると、一回一回の変更に時間がかかってしまう。経験を積むことでよりよい設計が見えてくることも当然あるが、最初から仮説検証のスピードを維持するためには「ある程度の安定性はありつつ変更も加えやすいようなアーキテクチャ」といったものを初期の段階からしっかりと組めるに越したことはない。

<p><small>（が、初期構築に時間をかけすぎると、そもそも仮説検証をスタートできないので、こだわりすぎるのもよくない。難しい。）</small></p>

「技術力が高くなければ『0→1』の開発はするべきではない」と言うつもりは毛頭ないし（そんなことを言えば自分にブーメランが返ってくるだけだ）、たとえ何かを妨げる結果になったとしても、何かしらの学びを得ることはそれ自体尊いことだと思う。

しかし、特に「0→1」フェーズに限って言えば<strong>「エンジニアリングに関する学び（とそこから生まれる技術的負債）」は、極力小さくなるようにコントロールするべき</strong>ではないだろうか。（別の言い方をすれば、エンジニアリングに関する不確実性は、できるだけ小さくしておくほうがよい。）

### 「計画的な技術的負債」の場合

<strong>「計画的な技術的負債」</strong>というのは、例えば「将来的には自前のバックエンドが必要になりそうだけど、今はひとまず SaaS で検証を進める」とか、「このコンポーネントは共通化できそうな気がするけど、そもそも検証したら要らなくなるかもしれないし、いったんコピペで対応する」といったものをイメージしている。

<strong>「計画的な技術的負債」</strong>に関しては、仮説検証を加速させるブースターのような役割があるので、積極的に利用したほうがよさそうだ。

ただし負債としてたまり続けると、腐臭を漂わせることになるので、返済することは絶対に忘れるべきではない。

「計画的な技術的負債」の場合は<strong>「学びから生まれる技術的負債」</strong>とは違い、それを積んだ背景やコンテキストが明確で、<strong>返済すべき条件やタイミング</strong>があらかじめ想定できているはずだ。したがって、[ADR](https://zenn.dev/souppower/articles/bfdf79069ae9a7)や`TODO`ファイル、コメントアウトなど（フォーマットは何でもよいが）記録を残し、いつでも確認できるようにしておくことが大切だろう。

また、<strong>「返済のしやすさ」</strong>もある程度考慮したうえで負債を積むこともできるはずである。

例えば「自前のバックエンドにデータを移しやすいような SaaS を選定する」とか、「フロントエンドのインフラストラクチャ層でデータアクセスを抽象化しておいてバックエンドのリプレイスの影響を受けにくいようにしておく」とか、「共通化しそうなコンポーネントは名前のプレフィックスを合わせる」とか、やれることはたくさんある。

## さいごに

あくまで個人的な経験から得た「学び」をまとめたものである点はご了承ください。みなさんの意見も聞かせてもらえると嬉しいです。


「0→1」フェーズにおける技術的負債との向き合い方

private な npm パッケージを Dockerfile でインストールして GitHub Actions でビルドする


2022年を振り返る。

## プライベート

去年は引きこもってばかりだったが、今年はその反動で少しずつ気持ちが外に向かっていった1年だった。長女の高校受験が無事終わり、ようやく一段落したことも大きかった。

7月に家族で北海道旅行に行ったが、それ以外では家族でいっしょに出かけるという機会はあまりなかった。長女も次女も少しずつ親から離れて自分たちの世界を構築しだしていて、子育てが終わりに近づいているんだなぁと実感する。これからは自分自身のために使える時間が増えると思うが、と同時に残りの人生が徐々に目減りしていってるのも感じる。やりたいことは今やらないとという気持ちがこの1年で強くなったように思う。

あと、去年の振り返りで

> 努力しないと体がどんどん老けていくのを年々実感するので、健康維持のために投資することを惜しまないようにしたい。

と書いたが、8月からジムに通いだした。今のところ週2回、継続的に通えているので、2023年も続けたい。

## 仕事

去年の10月から所属していたグローバルチームを4月に離れ、日本のプロダクト開発チームに戻った。グローバルチームでの経験は得難いものだったが、今のチームも会社の事業を支えるチームなので、とてもやりがいがある。会社自体もますます進化している。まだまだ走り続けるぞ。

## 2023年にむけて

2023年のテーマは「好奇心は高く、フットワークは軽く」。

やりたいことはやる。行きたいところには行く。会いたい人には会う。

いろいろあると思うけど、楽しい年になりますように。


2022年振り返り

SSGとしてのAstroとNext.jsを比較してみた

症状検索エンジン「ユビー」のUXライティングを改善している話

デザイントークンを自動補完するVS Code拡張機能を開発しました


[@masuP9](https://twitter.com/masuP9)のブログ記事「[BudouXを使ってフレーズ単位で改行する](https://masup.net/2022/01/budoux)」にインスパイアされて、本ブログのOGP画像に[BudouX](https://github.com/google/budoux/tree/main/javascript/)を適用してみた。

## 結果

**適用前**

<img src="/images/posts/2022-01-16-open-graph-image-before-applying-budoux.png" alt="BudouX適用前のOGP画像例" width="1200" height="630" class="with-border" />

**適用後**

<img src="/images/posts/2022-01-16-open-graph-image-after-applying-budoux.png" alt="BudouX適用後のOGP画像例" width="1200" height="630" />

よさそう。

## 実装

まず、ローカルにテンプレートファイルを用意する。パフォーマンスを考慮する必要がないので、Tailwind CSSの[Play CDN](https://tailwindcss.com/docs/installation/play-cdn)を使っている。

```html
<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <script src="https://cdn.tailwindcss.com"></script>
  </head>
  <body class="antialiased tracking-widest">
    <div class="relative w-[1200px] h-[630px] flex items-center px-36">
      <h1 id="title" class="mb-8 font-bold text-6xl leading-relaxed text-gray-900">Hello!こんにちは！</h1>
      <img class="absolute bottom-16 right-20" src="../../../public/icon.svg" width="82" height="82" />
    </div>
  </body>
</html>
```

メインとなるスクリプトでは、

1. テンプレートファイルをPuppeteerで開く
2. `h1`要素の`innerHTML`をBudouXを適用したタイトルで置き換える
3. スクリーンショットを撮る

というステップでOGP画像を生成している。

```ts
import fs from 'fs';
import { join } from 'path';
import matter from 'gray-matter';
import puppeteer from 'puppeteer';
import { loadDefaultJapaneseParser } from 'budoux';

const postsDirectory = join(process.cwd(), 'src/_posts');

function getPostTitle(filename: string): string {
  const fileContents = fs.readFileSync(join(postsDirectory, `${filename}`), 'utf8');
  const { data } = matter(fileContents);
  return data.title;
}

async function main() {
  const postFiles = fs.readdirSync(postsDirectory);
  const parser = loadDefaultJapaneseParser();

  for (const mdFilename of postFiles) {
    const title = getPostTitle(mdFilename);
    const browser = await puppeteer.launch();
    const page = await browser.newPage();
    // テンプレートファイルを開く
    await page.goto('file:///' + join(process.cwd(), 'src/scripts/generateOGImage/template.html'));
    // BudouXを適用したタイトルを取得する
    const parsedTitle = parser.translateHTMLString(title);
    // h1要素のinnerHTMLを置き換える
    await page.$eval(
      'h1',
      (el, parsedTitle) => {
        el.innerHTML = parsedTitle as string;
      },
      parsedTitle,
    );
    // スクリーンショットを撮る
    await page.screenshot({
      path: `public/og-images/${mdFilename.replace('.md', '')}.png`,
      clip: { x: 0, y: 0, width: 1200, height: 630 },
    });
    await browser.close();
  }
}

main();
```

次は、元記事と同じように、記事タイトルにもBudouXを使ってみようかな。

<ins datetime="2022-01-16T08:02:44.740Z">追記：記事タイトルにもBudouXを適用した。こちらもよさそう。</ins>


2022

2021

2020

2019

2018

2017

2016

2015

2012

2011

2010

2007

2006