Astro で Markdoc が使えるようになる astro-markdoc-renderer を試した。

---
title: "Astro で Markdoc を使う"
description: "Astro で Markdoc が使えるようになる astro-markdoc-renderer を試した。"
date: 2023-01-08T15:00:00+09:00
tags:
  - "Markdoc"
  - "Astro"
---

[astro-markdoc-renderer](https://www.npmjs.com/package/astro-markdoc-renderer) という、Astro で構築したブログに Markdoc を組み込めるライブラリを見つけたので、Astro + Markdoc の構成でブログを作ってみる。  
Astro を使ったブログサイトの構築には、Astro Blog テンプレートを使う。

## Astro で Markdoc を使いたい

このブログは、[Markdoc](https://markdoc.dev/) を使って Markdoc + Next.js の構成で構築している。  
Markdoc には、次の使いやすさを感じている。

- HTML タグに独自フックを差し込める
- 独自コンポーネントを利用する際、記事に HTML タグを書く必要がなく、可読性が高くなる

[Astro](https://docs.astro.build/) は [2022 JavaScript Rising Stars](https://risingstars.js.org/2022/en) の SSG 部門で 2 位にランクインしていて、2023 年現在注目されている SSG ツールである。  
Astro では、できる限りコンポーネントを静的生成し、レンダリング時には最低限の JavaScript だけが実行される。  
そのためページの読み込みが高速になる。

Astro のメリットを享受しつつ、Markdoc の機能が使いたいと思ったので、astro-markdoc-renderer を試してみる。

## STEP1：Astro プロジェクトの作成

Astro プロジェクトを作成する。

```bash
$ npm create astro@latest -- --template blog

╭─────╮  Houston:
│ ◠ ◡ ◠  Keeping the internet weird since 2021.
╰─────╯

 astro   v1.9.1 Launch sequence initiated.

✔ Where would you like to create your new project? … my-blog
✔ Would you like to install npm dependencies? (recommended) … yes
✔ Would you like to initialize a new git repository? (optional) … yes
✔ How would you like to setup TypeScript? › Strict
```

現時点でのディレクトリ構成は次の通り。

```bash
.
├── README.md
├── astro.config.mjs
├── node_modules
├── package-lock.json
├── package.json
├── public
├── src
│   ├── components
│   │   ├── BaseHead.astro
│   │   ├── Footer.astro
│   │   ├── Header.astro
│   │   └── HeaderLink.astro
│   ├── config.ts
│   ├── env.d.ts
│   ├── layouts
│   │   └── BlogPost.astro
│   ├── pages
│   │   ├── about.md
│   │   ├── blog
│   │   │   ├── first-post.md
│   │   │   ├── markdown-style-guide.md
│   │   │   ├── second-post.md
│   │   │   ├── third-post.md
│   │   │   └── using-mdx.mdx
│   │   ├── blog.astro
│   │   ├── index.astro
│   │   └── rss.xml.js
│   └── styles
└── tsconfig.json
```

## STEP2：必要なパッケージのインストール

必要なパッケージをインストールする。

```bash
$ npm install @markdoc/markdoc astro-markdoc-renderer gray-matter
```

## STEP3：Markdoc の設定ファイルの作成

次の内容で、`src/lib/markdoc/markdoc.config.ts` を作成する。  
Markdoc の独自タグや HTML タグのフックに関する設定は、後の STEP で追記する。

```ts:src/lib/markdoc/markdoc.config.ts
import Markdoc from "@markdoc/markdoc";
import type { Config } from "@markdoc/markdoc";

const { nodes, Tag } = Markdoc;

export const config: Config = {
  tags: {},
  nodes: {},
};
```

## STEP4：astro-markdoc-renderer の利用

コンテンツを表示する際に、astro-markdoc-renderer が適用されるようにする。
Blog テンプレートにおいては、コンテンツ表示に `BlobPost.astro` が使われている。  
そのため、`BlobPost.astro` で `MarkdocRenderer` を利用する。

1. 次の内容で、`src/components/Renderer.astro` を作成する。

    ```astro:src/components/Renderer.astro
    ---
    import { MarkdocRenderer } from "astro-markdoc-renderer";
    import type { Content } from "astro-markdoc-renderer";

    type Props = {
      content: Content;
    };

    const { content } = Astro.props;

    const components = {};
    ---

    <MarkdocRenderer content={content} components={components} />
    ```

1. 次の内容で `src/lib/post.ts` を作成する。  
  Astro では、Markdown のコンテンツは、`<slot />` に展開される。  
  `MarkdocRenderer` の `content` には、Markdoc を通したコンテンツを渡す必要があるため、`readPost()` でその処理を実施する。

    ```ts:src/lib/post.ts
    import fs from "fs/promises";
    import matter from "gray-matter";
    import Markdoc from "@markdoc/markdoc";
    import { config } from "./markdoc/markdoc.config";

    export async function readPost({ filepath }: { filepath: string }) {
      const rawString = await fs.readFile(filepath, "utf8");
      const { content } = matter(rawString);
      const ast = Markdoc.parse(content);
      const errors = Markdoc.validate(ast, config);
      if (errors.length) {
        console.error(errors);
      }
      return {
        content: Markdoc.transform(ast, config),
      };
    }
    ```

1. `src/layouts/BlobPost.astro` を次のように修正する。  
  先ほど作成した `Renderer` に、Markdoc を通したコンテンツを渡す。

    ```diff:src/layouts/BlobPost.astro
    ---
    import BaseHead from '../components/BaseHead.astro';
    import Header from '../components/Header.astro';
    import Footer from '../components/Footer.astro';
    + import Renderer from "../components/Renderer.astro";
    + import { readPost } from '../lib/post';

    export interface Props {
      content: {
        title: string;
        description: string;
        pubDate?: string;
        updatedDate?: string;
        heroImage?: string;
    +    file: string;
      };
    }

    const {
    +  content: { title, description, pubDate, updatedDate, heroImage, file },
    -  content: { title, description, pubDate, updatedDate, heroImage },
    } = Astro.props;
    + const { content } = await readPost({
    +   filepath: file
    + });
    ---
    // 省略

        <main>
          <article>
            {heroImage && <img width={720} height={360} src={heroImage} alt="" />}
            <h1 class="title">{title}</h1>
            {pubDate && <time>{pubDate}</time>}
            {
              updatedDate && (
                <div>
                  Last updated on <time>{updatedDate}</time>
                </div>
              )
            }
            <hr />
    -        <slot />
    +        <Renderer content={content} slot="content" />
          </article>
        </main>

    // 省略
    ```

## STEP5：HTML タグへのフックの追加

Markdoc では、Markdown シンタックスから HTML タグを生成するときに、独自の処理を差し込むことができる。  
参考：[Nodes](https://markdoc.dev/docs/nodes)  
今回は、`href` の値が http 始まりなら別タブで開くような処理を差し込む。

`ts:src/lib/markdoc/markdoc.config.ts` の `nodes` に、HTML タグ生成時に差し込む処理を追加する。

```diff:src/lib/markdoc/markdoc.config.ts
// 省略

export const config: Config = {
  tags: {},
-  nodes: {},
+  nodes: {
+    link: {
+      children: ["inline"],
+      attributes: {
+        href: { type: String },
+        target: { type: String },
+        rel: { type: String },
+      },
+      ...nodes.link,
+      transform(node, config) {
+        const attributes = node.transformAttributes(config);
+        const target = attributes.href.startsWith("http") ? "_blank" : null;
+        const rel = target ? "noopener noreferrer" : null;
+        return new Tag(
+          this.render,
+          { ...attributes, target, rel },
+          node.transformChildren(config)
+        );
+      },
+    },
+  },
};
```

## STEP6：独自タグの追加

Markdoc では、独自タグを実装し、`{% TAG %}` のような記法を Markdown に記述することで、シンタックスでは記述できない複雑な DOM を表現できる。  
参考：[Tags](https://markdoc.dev/docs/tags)  
今回は、背景色のついた注意書きブロックタグを作成する。

1. 次の内容で `src/components/Callout.astro` を追加する。

    ```astro:src/components/Callout.astro
    ---
    type Props = {
      title: string;
    };

    const { title } = Astro.props;
    ---

    <style>
      .callout {
        border-radius: 0.375rem;
        background-color: #ccc;
        padding: 0.5rem 1rem;
      }
      .callout--title {
        font-weight: 800;
      }
      .callout--content {
      }
    </style>
    <div class="callout">
      <div class="callout--title">
        {title}
      </div>
      <div class="callout--content"><slot /></div>
    </div>
    ```

1. `ts:src/lib/markdoc/markdoc.config.ts` を次のように書き換える。

    ```diff:src/lib/markdoc/markdoc.config.ts
    // 省略

    export const config: Config = {
    -  tags: {},
    +  tags: {
    +    callout: {
    +      render: "Callout",
    +      attributes: {
    +        title: { type: String },
    +      },
    +      children: nodes.document.children,
    +    },
    +  },
      nodes: {
      // 省略...
    };
    ```

## STEP7：テストページの追加

次の内容で `pages/blog/markdoc-test.md` を追加する。

{% markdoc-example %}

```markdown:pages/blog/markdoc-test.md
---
layout: "../../layouts/BlogPost.astro"
title: "Markdoc のテスト"
description: "Markdoc のテストです"
pubDate: "July 8 2023"
---

## リンク

[Google](https://google.co.jp) は外部リンクなので、別タブで開きます。  
[Home](/) は内部リンクなので、同じタブで開きます。

## Callout

{% callout title="タイトル" %}

注意書きです。**太字** もできます。

{% /callout %}
```

{% /markdoc-example %}

最終的なディレクトリ構成は次の通り。

```bash
.
├── README.md
├── astro.config.mjs
├── node_modules
├── package-lock.json
├── package.json
├── public
├── src
│   ├── components
│   │   ├── BaseHead.astro
│   │   ├── Callout.astro <== 追加
│   │   ├── Footer.astro
│   │   ├── Header.astro
│   │   ├── HeaderLink.astro
│   │   └── Renderer.astro <== 追加
│   ├── config.ts
│   ├── env.d.ts
│   ├── layouts
│   │   └── BlogPost.astro <== 修正
│   ├── lib
│   │   ├── markdoc
│   │   │   └── markdoc.config.ts <== 追加
│   │   └── post.ts <== 追加
│   ├── pages
│   │   ├── about.md
│   │   ├── blog
│   │   │   ├── first-post.md
│   │   │   ├── markdoc-test.md <== 追加
│   │   │   ├── markdown-style-guide.md
│   │   │   ├── second-post.md
│   │   │   ├── third-post.md
│   │   │   └── using-mdx.mdx
│   │   ├── blog.astro
│   │   ├── index.astro
│   │   └── rss.xml.js
│   └── styles
└── tsconfig.json
```

## STEP8：動作確認

ローカルサーバーを起動して、テストページを確認する。

```bash
$ npm run dev

> @example/blog@0.0.1 dev
> astro dev

  🚀  astro  v1.9.1 started in 600ms

  ┃ Local    http://localhost:3000/
  ┃ Network  use --host to expose

```

`{% callout title="タイトル" %}` を記述した部分が、`Callout.astro` で実装した内容に置き換わっている。  
![スクリーンショット：テストページが表示されている](/astro-meets-markdoc/preview.png)

リンクについては、外部リンクは別タブで開くように `target` が設定されていることも確認できた。

```html
<h2>リンク</h2>
<p>
  <a href="https://google.co.jp" target="_blank" rel="noopener noreferrer">Google</a> は外部リンクなので、別タブで開きます。<br>
  <a href="/">Home</a> は内部リンクなので、同じタブで開きます。
</p>
```

## 所感

astro-markdoc-renderer を使うと、Astro + Markdoc の構成が実現できた。  
現在の Next.js を使った構成から移行する場合も、コンテンツに関してはそのまま使えそう。


Astro で Markdoc を使う

AWS CDK を使って、S3 + CloudFront + CloudFront Functions を使ったリダイレクトを設定する。

---
title: "AWS CDK で CloudFront Function を使ったリダイレクト環境を構築する"
description: "AWS CDK を使って、S3 + CloudFront + CloudFront Functions を使ったリダイレクトを設定する。"
date: 2023-01-03T18:00:00+09:00
tags:
  - "AWS Cloud Development Kit"
  - "AWS S3"
  - "AWS CloudFront"
  - "AWS CloudFront Functions"
---

## 概要 {#introduction}

ときどき、CloudFront Functions を使って HTTP リダイレクト環境を構築することがある。  
今までは AWS Console 上で AWS リソースを作成していたが、設定内容を構成管理できるように AWS Cloud Development Kit（AWS CDK）を使ってみる。

この記事では、AWS CDK を使って次の AWS リソースを作成する。

- S3（CloudFront のオリジンに設定する）
- CloudFront ディストリビューション
- CloudFront Functions

## 動作環境 {#env}

- Node.js vv18.12.0
- AWS CLI v2.9.11
- AWS CDK v2.58.1

## 初回：AWS CDK のセットアップ {#setup}

### AWS CDK のインストール {#setup-install-cdk}

AWS CDK をインストールする。プロジェクト単位でインストールしても良い。

```bash
$ npm install -g aws-cdk

# バージョンの確認
$ cdk --version
2.58.1 (build 3d8df57)
```

### デプロイ⽤の S3 バケットの作成 {#setup-s3-bucket}

はじめて CDK でデプロイするときは、デプロイ⽤の S3 バケットを作成する必要がある。  
この S3 バケットはリージョン単位で作成するため、リソースを作成するリージョンを変更する場合は `cdk bootstrap` を実行する。

```bash
$ cdk bootstrap aws://AWS_ACCOUNT_ID/AWS_REGION --profile PROFILE_NAME

 ⏳  Bootstrapping environment aws://123456789012/ap-northeast-1...
Trusted accounts for deployment: (none)
Trusted accounts for lookup: (none)
Using default execution policy of 'arn:aws:iam::aws:policy/AdministratorAccess'. Pass '--cloudformation-execution-policies' to customize.
CDKToolkit: creating CloudFormation changeset...
 ✅  Environment aws://123456789012/ap-northeast-1 bootstrapped.
```

## STEP1：CDK プロジェクトの作成 {#step-create-project}

`cdk init app` で、CDK プロジェクトを作成できる。  
今回は、TypeScript で記述したいので、`language` オプションで「typescript」を設定する。

```shell
$ mkdir example && cd $_
$ cdk init app --language typescript

Applying project template app for typescript
# Welcome to your CDK TypeScript project

This is a blank project for CDK development with TypeScript.

The `cdk.json` file tells the CDK Toolkit how to execute your app.

## Useful commands

* `npm run build`   compile typescript to js
* `npm run watch`   watch for changes and compile
* `npm run test`    perform the jest unit tests
* `cdk deploy`      deploy this stack to your default AWS account/region
* `cdk diff`        compare deployed stack with current state
* `cdk synth`       emits the synthesized CloudFormation template

Executing npm install...
✅ All done!
```

次のファイル群が生成される。

```bash
.
├── README.md
├── bin
│   └── example.ts # CDK アプリのエントリーポイント。lib/example-stack.ts のインスタンスを生成する。
├── cdk.json # ビルド設定や環境変数を定義する
├── jest.config.js
├── lib
│   └── example-stack.ts # CloudFormation スタックを定義する。
├── node_modules
│   └── ...
├── package-lock.json
├── package.json
├── test
│   └── example.test.ts
└── tsconfig.json
```

## STEP2：スタックテンプレートの修正 {#setp-stack-template}

`lib/example-stack.ts` を次のように修正する。

```typescript:lib/example-stack.ts
import * as cdk from "aws-cdk-lib";
import {
  aws_s3 as s3,
  aws_s3_deployment as s3deploy,
  aws_cloudfront as cf,
  aws_cloudfront_origins as cfo,
  aws_iam as iam,
} from "aws-cdk-lib";

import { Construct } from "constructs";

// アカウント名やリージョンは、AWS プロファイルから設定される
const { CDK_DEFAULT_ACCOUNT, CDK_DEFAULT_REGION } = process.env;
const prefix = `example-${CDK_DEFAULT_REGION}-${CDK_DEFAULT_ACCOUNT}`;

export class ExampleStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // S3 バケットを作成する
    // パブリックアクセスをすべてブロックする
    const bucket = new s3.Bucket(this, "S3Bucket", {
      bucketName: `${prefix}-bucket`,
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
      versioned: false,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });

    // オリジンアクセスアイデンティティを作成する
    const identity = new cf.OriginAccessIdentity(this, "OriginAccessIdentity", {
      comment: `${bucket.bucketName} access identity`,
    });

    // オリジンアクセスアイデンティティに S3 のアクセスを許可する IAM を設定する
    const bucketPolicyStatement = new iam.PolicyStatement({
      actions: ["s3:GetObject"],
      effect: iam.Effect.ALLOW,
      principals: [identity.grantPrincipal],
      resources: [`${bucket.bucketArn}/*`],
    });
    bucket.addToResourcePolicy(bucketPolicyStatement);

    // CloudFront Function で動かす、リダイレクトスクリプトを設定する
    const cfFunction = new cf.Function(this, "CloudFrontFunction", {
      code: cf.FunctionCode.fromFile({
        filePath: "assets/redirect.js",
      }),
    });

    // CloudFront のディストリビューションを作成する
    const distribution = new cf.Distribution(this, "CloudFrontDistribution", {
      comment: "cloudfront distribution",
      defaultRootObject: "index.html",
      defaultBehavior: {
        allowedMethods: cf.AllowedMethods.ALLOW_GET_HEAD,
        cachedMethods: cf.CachedMethods.CACHE_GET_HEAD,
        cachePolicy: cf.CachePolicy.CACHING_OPTIMIZED,
        viewerProtocolPolicy: cf.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
        origin: new cfo.S3Origin(bucket, {
          originAccessIdentity: identity,
        }),
        functionAssociations: [
          {
            function: cfFunction,
            eventType: cf.FunctionEventType.VIEWER_REQUEST,
          },
        ],
      },
      priceClass: cf.PriceClass.PRICE_CLASS_100,
    });

    // S3 バケットに index.html を置く
    new s3deploy.BucketDeployment(this, "BucketDeployment", {
      sources: [
        s3deploy.Source.data(
          "/index.html",
          "<html><body><h1>Hello World</h1></body></html>"
        ),
      ],
      destinationBucket: bucket,
      distribution: distribution,
      distributionPaths: ["/*"],
    });
  }
}
```

## STEP3：リダイレクトスクリプトの作成 {#step-redirect}

プロジェクトのルートに `assets` ディレクトリを作成し、`redirect.js` を作成する。

```bash
$ mkdir assets
$ touch assets/redirect.js
```

`redirect.js` は、次の内容にする。  
CloudFront の URL にアクセスすると、`https://new.example.com` にリダイレクトするスクリプトである。

```js:assets/redirect.js
function handler(event) {
  var newUrl = `https://new.example.com`;

  var response = {
    statusCode: 302,
    statusDescription: "Found",
    headers: { location: { value: newUrl } },
  };

  return response;
}
```

## STEP4：AWS リソースのデプロイ {#step-deploy}

スタップテンプレートに記述した AWS リソースをデプロイするには、`cdk deploy` を実行する。

```bash
$ cdk deploy --profile PROFILE_NAME

ExampleStack: building assets...

...
[100%] success: Published randomvalue:current_account-current_region

...

  Deployment time: ...

Stack ARN:
arn:aws:cloudformation:ap-northeast-1:123456789012:stack/ExampleStack/12345678-1234-1234-1234-123456789012

  Total time: ...
```

## STEP5：動作確認 {#step-confirm}

AWS CLI で CloudFront の URL を確認する。

```bash
aws cloudfront list-distributions --profile PROFILE_NAME | jq '.DistributionList.Items[].DomainName'
"foo.cloudfront.net"
```

CloudFront の URL に GET リクエストを送信する。  
HTTP ステータス 302 で、new.example.com にリダイレクトしていることを確認できた。

```bash
$ curl -I https://foo.cloudfront.net

HTTP/2 302
server: CloudFront
...
content-length: 0
location: https://new.example.com
x-cache: FunctionGeneratedResponse from cloudfront
via: 1.1 example-example.cloudfront.net (CloudFront)
...
```

## おまけ：デプロイした AWS リソースの削除 {#destory-resource}

作成した AWS リソースを削除するには、`cdk destroy スタック名` を実行する。

```bash
$ cdk destroy example --profile PROFILE_NAME
```


AWS CDK で CloudFront Function を使ったリダイレクト環境を構築する

---
title: "音声で Todoist にタスクを追加するショートカット"
date: 2023-01-02T09:00:00+09:00

tags:
  - "ショートカット"
  - "Todoist"

---

## 概要 {#abstract}

この記事では、気軽に音声入力で Todoist にタスクを追加できるショートカットの作り方を説明します。

あとでやろうと思いついたことをメモするのを忘れて、そのままになってしまうことがよくあります。  
特に散歩しているときに思いつくことが多く、立ち止まってタスクを登録するのは面倒に感じています。  
iOS の Todoist の場合、[Siri を使ってタスクを追加する機能](https://todoist.com/ja/help/articles/using-siri-with-todoist) があります。
しかし、この機能を利用する場合には、Siri のウェイクワードが必要です。  

この記事で説明する仕組みでは、Phone の背面を 3 回タップしタスクを音声入力するだけで、タスクを Todoist へ追加できるような仕組みを作ります。  
タスク管理アプリに Todoist を使っていますが、ショートカットでタスクを追加できるアプリであれば、同じような仕組みを実現できます。

## 利用イメージ {#usage}

1. iPhone の背面を 3 回タップします。  
  ショートカットが起動します。
  ![スクリーンショット：音声入力のダイアログが表示されている](/shortcut-add-task-by-voice/usage-wake.png)
1. 音声でタスクを入力します。
  ![スクリーンショット：音声入力でタスク名が入力されている](/shortcut-add-task-by-voice/usage-input-task.png)
  Todoist にタスクが追加されます。
  ![スクリーンショット：Todoistの画面。タスクが追加されている](/shortcut-add-task-by-voice/usage-add-task.png)

## 動作環境

- iOS [ショートカットアプリ](https://apps.apple.com/jp/app/id915249334)
- iOS [Todoist アプリ](https://apps.apple.com/jp/app/id572688855)

## STEP1：ショートカットを作成する

次のようなショートカットを作成します。  
![スクリーンショット：ショートカットの全体が表示されている](/shortcut-add-task-by-voice/setup-shortcut.png)

次のアクションをつなぎ合わせます。

### テキストを音声入力

![スクリーンショット：「テキストを音声入力」のアクションが表示されている](/shortcut-add-task-by-voice/setup-voice.png)

- **言語** - 任意の言語を選択
- **聞き取りを停止** - 一時停止後

### Todoist：タスクを作成する  

![スクリーンショット：「タスクを作成する」のアクションが表示されている](/shortcut-add-task-by-voice/setup-todoist.png)

- **タスク名** - 音声入力されたテキスト
- **プロジェクト** - タスクを追加するプロジェクト

## STEP2：ショートカットの起動方法を設定する

iPhone の背面タップ機能でショートカットを呼び出すように設定します。

1. 「設定」アプリを開きます。
1. 「アクセシビリティ」を選択し、「タッチ」を選択します。
1. 「背面タップ」を選択します。
1. 「トリプルタップ」を選択し、「ショートカット」セクションで先ほど追加したショートカット名を選択します。  
  ![スクリーンショット：追加したショートカットが選択されている](/shortcut-add-task-by-voice/wakeup-shortcut.png)

## 所感

この仕組みによって、思いついたタスクをすぐに登録できるようになりました。  
散歩中でも、iPhone を口元に近づけて入力すれば、人目もそれほど気になりません。  

今回は背面タップで起動するように設定していますが、ウィジェットに作成したショートカットを配置すれば、ウィジェットからも起動できます。


音声で Todoist にタスクを追加するショートカット

CodePipeline を使って、GitHub.com に置いた AWS SAM プロジェクトの自動デプロイを試した

CloudFormation で構築した CodePipeline を使って AWS SAM プロジェクトを自動デプロイする

HUGO v0.109.0 で追加された、HUGO テンプレートから Sass に変数を渡す機能を試した

---
title: "HUGO テンプレートから Sass に変数を渡す方法"
description: "HUGO v0.109.0 で追加された、HUGO テンプレートから Sass に変数を渡す機能を試した"
type: "TIL"
date: "2022-12-30T15:00:00+0900"
tags:
  - "HUGO"
  - "Sass"
---


[HUGO v0.109.0](https://github.com/gohugoio/hugo/releases/tag/v0.109.0) で追加された、HUGO テンプレートから Sass に変数を渡す機能を試した。  
HUGO における Sass の標準ライブラリである LibSass でも利用できるが、if 構文を使いたかったため、この記事では DartSass を使用する。

## 要約 {#summary}

- テンプレート：`toCSS` の `vars` オプションに、変数を定義した map を渡す

  ```go
  {{- $vars := ( dict "color1" "#1fb6ff" "color2" "#7e5bef" ) -}}
  {{- $opts := ( dict "transpiler" "dartsass" "vars" $vars ) -}}
  {{- $style := resources.Get "scss/main.scss" | toCSS $opts | fingerprint -}}
  ```

- SCSS：渡された変数を使う箇所で `@use` して変数にアクセスする

  ```scss
  @use "hugo:vars" as h;

  .main {
    color: h.$color1;
  }
  ```

- 設定ファイルに定義した変数も、SCSS に渡すことができる

## 動作環境 {#environment}

- HUGO+extended v0.109.0
- Dart Sass 1.56.1  
  Homebrew で Dart Sass のインストール方法は、[brew tap Formula で追加するパッケージをインストールする場合](/til/brew-install-specify-version##tap-formula) を参照のこと。

## テンプレートファイルに変数を定義する場合 {#template}

### HUGO テンプレート {#template-template}

v0.109.0 から `toCSS` の `vars` オプションに map（キーと値のペア）を渡せるようになった。  
SCSS 側では、`vars` に渡した map の値にアクセスできる。

```go:layouts/partials/head.html
{{- $vars := ( dict "color1" "#1fb6ff" "color2" "#7e5bef" ) -}}
{{- $opts := ( dict "transpiler" "dartsass" "vars" $vars ) -}}
{{- $style := resources.Get "scss/main.scss" | toCSS $opts | fingerprint -}}
{{ with $style }}<link rel="stylesheet" href="{{ .RelPermalink }}">{{ end -}}
```

### SCSS {#template-scss}

渡された変数を使う箇所で `@use "hugo:vars as 名前空間"` する。  
`@use` では名前空間を区切ることができるので、`as 名前空間` とすると、使うときに `名前空間.変数名` でアクセスできる。

```scss:assets/scss/main.scss
@use "hugo:vars" as h;

.main {
  color: h.$color1;
}
```

### 生成された CSS {#template-built-css}

`hugo` を実行して生成された CSS を確認すると、HUGO テンプレートで渡した変数の値が注入されている。

```css:public/scss/main.css
.main {
  color: #1fb6ff;
}
```

## 設定ファイルに変数を定義する場合 {#config}

設定ファイルで切り替えているサイトごとに一部の色を変えたい場合など、設定ファイルに CSS の変数を定義し、それを利用することもできる。

### HUGO の設定ファイル {#config-config}

設定ファイルの Params に SCSS に渡す変数（ここでは `style`）を定義しているとする。  
`vars` には map で渡す必要があるため、`[params.変数名]` のセクションに SCSS で使用する変数を定義する。

```toml:config.toml
[params.style]
colorTheme = "dark"
# var2 = ...
```

### HUGO テンプレート {#config-template}

設定ファイルで設定した変数は `$.Site.Params.変数名` でアクセスできるので、これを `vars` に渡す。

```go:layouts/partials/head.html
{{- $opts := (dict "transpiler" "dartsass" "vars" $.Site.Params.style ) -}}
{{- $style := resources.Get "scss/main.scss" | toCSS $opts | fingerprint -}}
{{ with $style }}<link rel="stylesheet" href="{{ .RelPermalink }}">{{ end -}}
```

### SCSS {#config-scss}

SCSS の書き方は、テンプレートファイルに変数を定義する場合と変わらない。  
DartSass は `@if` で条件分岐ができるため、HUGO の設定ファイルで条件式のトリガーとなる変数を定義して、SCSS 側で切り替えるような実装もできる。

```scss:assets/main.scss
@use "hugo:vars" as h;

$colorTheme: light !default;
$base-color: #fcfcfc !default;
$primary-text-color: #14171a !default;

@if h.$colorTheme == dark {
  $base-color: #15202b;
  $primary-text-color: #fefffe;
}

// メイン
.main {
  background-color: c.$base-color;
  color: c.$primary-text-color;
}
```

### 生成された CSS {#config-built-css}

生成された CSS を確認すると、HUGO テンプレートで渡した変数の値が注入されている。

```css:public/scss/main.css
.main {
  background-color: #15202b;
  color: #fefffe;
}
```


HUGO テンプレートから Sass に変数を渡す方法

2022年に買ってよかったもののメモです。

---
title: "買ってよかったもの＠2022 年"
description: "2022年に買ってよかったもののメモです。"
date: 2022-12-28T18:00:00+09:00
type: "Lifelog"
---

## AfterShokz Aeropex

{% amazon asin="B07RQLTFJ5" title="AfterShokz Aeropex" /%}

いまさら骨伝導のワイヤレスイヤホンを買った。  
今まではカナル型のイヤホンやノイズキャンセリングのヘッドホンを使っていたが、以下の問題を感じていた。

- 長時間つけていると、頭の外側と耳が痛くなる
- つけた状態で発言すると耳の内圧が上がる（気がする）

Aeropex はこれらの問題を解決できたと思う。今は次の用途に使っている。

- オンラインミーティング
- 散歩

完全に聴く専門で使っていて、内蔵マイクは使ってない。内蔵マイクを使うと声がこもって聞こえるらしい。  
骨伝導なので揺れてかゆくなるという話を聞いていたが、笑い声などの大きな音が流れてこない限りは問題なかった。  
散歩をするときも周囲の環境音がわかるので、車や自転車が近づいているのがわかって良い。  
コンビニのレジで毎回イヤホンを外す手間もなくなった。  
反対に、車通りが激しい場所や電車など周囲の音が大きな場所では、あまり音が聞こえない。  
状況に合わせたイヤホンの使い分けが必要。

## ジェットウォッシャー

{% amazon asin="B09XLYQFNZ" title="Panasonic ジェットウォッシャー EW-DJ55-W" /%}

これまで、歯のクリーニングで歯科衛生士さんに褒められたことがない。  
デンタルフロスで頑張るのは限界を感じていたし、「ジェットウォッシャーいいよ」という評判を聞いていたので、手を出すことにした。  
現在、以下の効果を感じている。買ってよかった。

- 歯磨きでは取り切れない汚れがとれる
- 朝起きたときに口内がすっきりしている
- 歯茎が健康になった（気がする）

追加でノズルを購入できるため、衛生的にも安心だし家族でノズルを使い分けできる。  
誰のものかを見分けるためのカラーリングをノズルにつけることもできる。  

据え置きタイプに比べて、充填できる水が少ないため途中で水を補充しているが、そのことに不便さは感じない。  
今度こそ、歯科衛生士さんに褒められたい。

## マーナ 汚れからめ取りクロス

{% amazon asin="B08MKRY3ZX" title="汚れからめ取りクロス" /%}

お歳暮で色んな人に贈りたいくらい気に入っている。  
主にキッチンで使っていて、この布のおかげで掃除の手間とわずらわしさが軽減された。  
コンロの汚れをお湯でふやかした後にこの布で拭き取れば、取れない汚れはこの世にないと思うくらいキレイになる。  
ただし乾きは悪いので、使った後は水で洗って洗濯機に投入している。

普段は、冷蔵庫に設置した [山崎実業のマグネットキッチンタオルホルダー](https://www.amazon.co.jp/dp/B07N6JT3V9/) に挟んで、いつでも取り出せるようにしている。

## ワドルディのフィギュア

今年発売された [星のカービィ ディスカバリー](https://www.nintendo.co.jp/switch/arzga/index.html) をプレイしたところ、ワドルディにハマった。  
ちょっとまぬけで不憫なところが、とてもかわいい。  
タイミングよくワドルディのフィギュアやガチャガチャがあったので、もちろん入手した。  
いまは仕事のデスクに置いている。

- [ソフビコレクション ワドルディ こまった](https://www.enskyshop.com/products/detail/22287)
- [座る星のカービィ - バンダナワドルディ](https://kitan.jp/products/suwaru_kirby/)

写真は、ガチャガチャでゲットしたワドルディとメタナイト様。  
![写真：ワドルディとメタナイトのフィギュアが映っている](2022-best-buy/wadlle-dee.jpeg)  

見ているだけで HP が復活する。


買ってよかったもの＠2022 年

VRoid Studio を使って作成したアバターで Zoom ミーティングや StreamYard での配信に参加するまでの方法です。

---
title: "自作の美少女アバターで Zoom ミーティングや StreamYard の配信に参加する"
description: "VRoid Studio を使って作成したアバターで Zoom ミーティングや StreamYard での配信に参加するまでの方法です。"
date: 2022-12-22T20:00:00+09:00
tags:
  - VRoid Studio
---

## はじめに

macOS で自作のアバターを操作し、Zoom や StreamYard の配信に参加するまでの方法を紹介します。  
この方法だと、自作アバターに凝らなければ、環境の構築やアプリケーションの設定には 30 分もかかりません。

## この記事で説明しないこと

- VRoid Studio を使って 3D モデルを作成する操作手順  
  作成する手順の詳細は、[VRoid Studio ヘルプサイト](https://vroid.pixiv.help/hc/ja/)やほかの紹介ブログを参照してください。
- アバターの表情や手足の動かし方  
  この記事で紹介しているアプリケーションの無償版では、頭と口の動きだけ Web カメラに映った人間の動きに追従します。  
  より細かく表情を同期させたり手足を動かしたりするには、有償版や LeapMotion の利用が必要です。

## 自作のアバターで Zoom や StreamYard に参加するまでのステップ

自作のアバターで Zoom や StreamYard の配信に参加するまでの、おおまかな流れは次のとおりです。  
ほかの紹介ブログで説明している方法も、利用するアプリケーションに違いがありますが、基本的な流れは同じです。

1. 3D モデルを用意し、VRM ファイルを作成する
1. Web カメラに映った人の動きを 作った3D モデルをアバターとして動かす
1. 動かしている映像を投影した仮想カメラを作る
1. Zoom や SteamYard で仮想カメラを使用し、ミーティングや配信に参加する

この記事では、次の図に示す構成で自作のアバターを動かし、Zoom のミーティングや StreamYard の配信に参加します。  
![図：自作のアバターを動かし、Zoom や StreamYard の配信に参加するまでの流れを示している](/steam-original-avatar/structure.png)

使用したアプリケーションは次のとおりです。

- VRoidStudio：3D モデルを作成し、VRM ファイルをエクスポートする
- 3tene：3D モデルのアバターを動かす
- OBS Studio：アバターが動いている画面を投影し、仮想カメラを作る
- Zoom または StreamYard：仮想カメラを使用して、ミーティングや配信に参加する

## 動作環境

- macOS Monterey v12.6（M1 mac でも動作確認済み）
- VRoid Studio 正式版 v1.17.1
- 3tene Free v3.0.6
- OBS Studio v28.1.2
- Zoom v5.13.0

## STEP1：VRoid Studio を使って、3D モデルを用意し、VRM ファイルを作成する

### 3D モデルの作成

通常、3D モデリングを行なうには、ポリゴンを用意したり動かすための関節（ボーン）を入れたり、モデリングの専門的な知識が必要です。  
私は専門知識が皆無なので、オリジナルの 3D キャラクターを作成できる [VRoid Studio](https://vroid.com/studio) を使って、3D モデルを用意します。

VRoid Studio は、男女のそれぞれのモデルをベースに、目や口、髪型などのパーツや体型をカスタマイズして 3D モデルを作成できるアプリケーションです。  
![スクリーンショット：男女のベースを選択する画面が表示されている](/steam-original-avatar/vroidstudio-base.png)

{% embed src="https://vroid.pixiv.help/hc/ja/articles/440559766338" title="VRoidをはじめよう" /%}

### 配布されているカスタムアイテムの探し方

VRoid Studio で使えるパーツは、目ひとつとってもさまざまなパターンがあり、パーツの位置や角度を自由度高く調整できます。  
よりこだわりたい場合は [Pixiv BOOTH](https://booth.pm/ja/) で配布されているパーツを、カスタムアイテムとしてインポートします。  
Pixiv Booth で「VRoid」というキーワードを検索すると、さまざまなパーツを見つけることができます。

私は次のパーツを BOOTH で入手し、カスタムアイテムとしてインポートしました。

- 髪型
- 髪色（テクスチャ）
- 目の色やハイライト（テクスチャ）
- 服（テクスチャ）

カスタムアイテムのインポートには苦戦したので、別の記事でカスタムアイテムを使い方を書きたいです。

### VRM ファイルのエクスポート

VRoid Studio で、作成したモデルを `.vrm` という拡張子のファイルでエクスポートします。  
このファイルを、アバターを動かすアプリケーション 3tene に読み込みます。

1. 画面右上のエクスポートボタンをクリックします。
1. 「VRMエクスポート」を選択します。  
   ![スクリーンショット：[VRMエクスポート]が表示されている](steam-original-avatar/vroidstudio-export.png)
1. エクスポート情報を削減します。
  エクスポート情報が多いと、PC のスペックによっては動かすときにカクつく可能性があるためです。  
  最適値はわかっていませんが、今回は「ポリゴンの削減」で次の項目を選択しました。
    - 「髪の断面形状を削減する」
    - 「透明メッシュを削除する」
1. [エクスポート]をクリックします。

## STEP2：3tene を使って 3D モデルのアバターを動かす

STEP1 でエクスポートした VRM ファイルを動かすために、3tene を使います。  
[3tene](https://3tene.com/) は Web カメラに映った人の動きをアバターに反映して動かすことができるアプリケーションです。  
この記事では、無償版の 3tene を使用します。

### 3tene のインストール

3tene は、[3tene の Web サイト](https://3tene.com/) からダウンロードできます。  
mac の場合は、ダウンロードした zip を展開し、`3teneFREE_beta.app` を「アプリケーション」に移動します。

### VRM ファイルの読み込み

VRoid Studio からエクスポートした VRM ファイルを読み込みます。

1. 左のメニューバーから、[アバターの選択]をクリックします。
1. [+]をクリックします。
1. エクスポートした VRM ファイルを選択します。  
  画面にインポートした3D モデルのアバターが表示されます。  
  ![スクリーンショット：3D モデルのアバターが表示されている](/steam-original-avatar/3tene-import.png)

### 背景画像の変更

背景画像を合成できるよう、背景色をグリーンバックにします。

1. 左のメニューバーから[背景]をクリックします。
1. 「背景変更」タブを選択します。
1. 「色指定」で緑色を選択します。  
  背景が緑色になります。  

### メニューバーの非表示

OBS では、3tene の画面を投影します。  
メニューバーが表示されているとメニューバーごと投影されてしまうため、使わないときは隠すように設定します。

1. 右のメニューバーから[設定]をクリックします。
1. 「システム」タブを選択します。
1. 「メニューバーを自動的に隠す」を選択します。
1. [設定を保存]をクリックします。

### アバターと Web カメラの動きの同期

アバターを操作する Web カメラを選択し、アバターの操作を開始します。

1. [アバター調整]をクリックします。
1. 「設定」タブを選択します。
1. 「Webカメラ」で使用する Web カメラを選択します。
1. [設定を保存] をクリックします。
1. [トラッキングのオンオフ]をクリックします。
1. 「フェイストラッキング」と「リップシンキング」でそれぞれ[開始]をクリックします。  
  アバターが Web カメラに映った人の動きに合わせて動き出します。  
  ![動画：アバターが人の動きに合わせて動いている](/steam-original-avatar/3tene-tracking.gif)

OBS では 3tene の画面を投影するため、3tene を起動したままにします。

## STEP3：OBS Studio で 3tene の画面を投影した仮想カメラを作る

### OBS Studio のインストール

OBS Studio は、[OBS の Web サイト](https://obsproject.com/ja/download) からダウンロードできます。  
mac の場合は、Homebrew を使ってインストールすることもできます。

```shell
$ brew install obs
```

### 起動と権限設定

OBS Studio を起動して、必要な権限を設定します。

1. アプリケーションから「OBS」を選択します。
1. 初めてを起動する場合は、権限を設定します。  
  今回は「画面収録」に対する許可をします。
1. 「自動構成ウィザード」が表示される場合には、「仮想カメラのみ使用する」を選択して設定を適用します。

### 3tene の画面の投影

1. 「ソース」セクションの[+]をクリックします。
1. 「ウィンドウ投影」を選択します。
1. 「新規作成」を選択して、適当な名前を入力し[OK]をクリックします。
1. 「ウィンドウ」で「[3teneFree_beta]3teneFree_beta」を選択します。
1. [OK]をクリックします。
1. 3tene の画面が投影されていることを確認します。  
  このとき、3tene のウィンドウバーが写り込んでしまうため、プレビュー画面で投影した画像サイズを調整します。  
  アバターの位置を動かしたい場合にも、画像サイズや位置の調整で行ないます。  
  ![スクリーンショット：投影した画像のサイズを調整している](/steam-original-avatar/obs-adjust.png)

### 背景画像の合成

Zoom や SteamYard 側でバーチャル背景を合成する場合、この手順は不要です。

1. 「ウィンドウ投影」を選択し、[フィルタ]をクリックします。
1. 「エフェクトフィルタ」セクションの[+]をクリックします。
1. 「クロマキー」を選択します。
1. [閉じる]をクリックします。
1. 「ソース」セクションの[+]をクリックします。
1. 「画像」を選択します。
1. 「画像ファイル」で合成する画像ファイルを選択します。
1. [OK]をクリックします。
1. 「画像」映像デバイスが一番上になるように、順番を並び替えます。
1. アバターと背景画像が合成されたことを確認します。  
  ![スクリーンショット：アバターと背景が合成されている](/steam-original-avatar/obs-concat.png)

### 映像投影デバイスの追加

SteamYard で OBS の仮想カメラを使用するには、映像投影デバイスを追加します。  
Zoom の場合、この手順は不要です。

1. 「ソース」セクションの[+]をクリックします。
1. 「映像投影デバイス」を選択します。
1. 「デバイス」が未選択の状態で、[OK]をクリックします。
1. 映像デバイスが一番上になるように、「ソース」の順番を並び替えます。

### 仮想カメラの開始

仮想カメラを開始します。  
仮想カメラを開始すると、Zoom や SteamYard のカメラの設定で、OBS の仮想カメラを選択できるようになります。

1. [仮想カメラの開始]横の歯車の形をした設定ボタンをクリックします。
1. 「出力の種類」と「出力の選択」でそれぞれ「シーン」を選択します。
1. [OK]をクリックします。
1. [仮想カメラの開始]をクリックします。

さきほどと同様に、3tene と OBS を起動したままにします。

## STEP4：Zoom や StremYard で OBS の仮想カメラを使用する

### Zoom の場合

1. Zoom の設定を開きます。
1. 「ビデオ」タブを選択します。
1. 「カメラ」で「OBS Virtual Camera」を選択します。  
  ![スクリーンショット：OBS Virtual Camera」が選択されている](/steam-original-avatar/zoom.png)
1. OBS の映像が Zoom に表示されることを確認します。

OBS 側で背景画像を合成している場合は、Zoom のバーチャル背景をオフにします。

### SteamYard の場合

1. SteamYard の配信に参加します。
1. [設定]をクリックします。
1. 「カメラ」タブを選択します。
1. 「カメラ」で「OBS Virtual Camera」を選択します。  
  ![スクリーンショット：OBS Virtual Camera」が選択されている](/steam-original-avatar/streamyard.png)
1. OBS の映像が SteamYard に表示されることを確認します。

## おわりに

手順数は多いものの、特に難しい操作もなく Zoom ミーティングや StreamYard の配信に参加できるようになりました。

また、アバターで美少女になってみたことで次の気付きがありました。

- 普段できない格好や、髪色や髪型ができる。現実では髪色をピンクにできない。
- 自己肯定感がとても上がる。かわいい…！！
- MacBookAir（Intel）だとファンの音がすごい。特に 3tene でカメラを ON にすると、CPU 使用率が上がる。
- ディスプレイモニターが足りない。複数のアプリケーションを起動するため、画面を逼迫する。


自作の美少女アバターで Zoom ミーティングや StreamYard の配信に参加する

プライベートリポジトリにある GitHub Reusable Workflow をほかのリポジトリで使えるようになった。その設定方法や再利用なワークフローの作りかたと使いかたを記載する。

---
title: "プライベートリポジトリにある GitHub Workflow をほかのリポジトリで使う"
description: "プライベートリポジトリにある GitHub Reusable Workflow をほかのリポジトリで使えるようになった。その設定方法や再利用なワークフローの作りかたと使いかたを記載する。"
type: "TIL"
date: "2022-12-16T15:00:00+0900"
tags:
  - "GitHub Actions"
---

この記事では、プライベートリポジトリにおいた Reusable Workflow を、他のリポジトリで参照して使う方法を説明する。

## プライベートリポジトリに置いたワークフローを参照して使えるようになった

処理内容が変わらないワークフローを、複数のリポジトリで実行させたいケースが多くある。  
たとえば JavaScript のプロジェクトの場合は、どのリポジトリでも ESLint を実行したい。  
GitHub Actions でそれを実現するには、それぞれのリポジトリでワークフローファイルを持つ必要があり、それらのファイルをメンテナンスしていくのが手間である。

その解決手段のひとつとして、GitHub の Reusable Workflow がある。  
Reusable Workflow は、ひとつのワークフローを他のリポジトリで共有して使うことができる仕組みである。  
ただし共有するワークフローファイルはパブリックなリポジトリに置く必要があり、公開したくないワークフローファイルに対しての運用ができなかった。

しかし、2022 年 12 月 14 日に、プライベートリポジトリにある Action や Reusable Workflow を、ほかリポジトリから参照して使うことができるようになった。  
[GitHub Actions – Sharing actions and reusable workflows from private repositories is now GA](https://github.blog/changelog/2022-12-14-github-actions-sharing-actions-and-reusable-workflows-from-private-repositories-is-now-ga/)  
具体的には、プライベートリポジトリに置いた Reusable Workflow を参照できる参照できる設定が追加された。  
同じユーザーアカウントや組織内であれば、プライベートリポジトリに置いたワークフローを他のリポジトリと共有できるようになった。

## Reusable Workflow を置くリポジトリのワークフロー

### Reusable Workflow を作る

複数のリポジトリで共有して使うワークフローを定義する。  
例として ESLint を実行するワークフローを作ることにする。

1. GitHub にプライベートリポジトリを作る。  
  このリポジトリを、複数のリポジトリ間で共有するワークフローの置き場所とする。  
  リポジトリ名は「github-actions-shared-workflows」とした。

1. 次の内容で、「.github/workflows」の下に共有するワークフローを作成する。
  ファイル名は `eslint.yml` とした。  
  ワークフローを Reusable Workflow にするには、`on.workflow_call` を指定する。

  ```yml:.github/workflows/eslint.yml
  name: eslint

  on:
    workflow_call:

  jobs:
    lint:
      runs-on: ubuntu-latest
      steps:
        - uses: actions/checkout@v3

        - name: Use Node.js
          uses: actions/setup-node@v3
          with:
            node-version: 16
            cache: 'npm'

        - name: Install dependencies
          run: npm ci

        - name: Run lint
          run: npm run eslint
  ```

### Actions のアクセス許可を有効にする

プライベートリポジトリに置いた Reusable Workflow を共有するには、リポジトリの設定で、Actions のアクセス許可を有効にする。

1. Reusable Workflow を置いたリポジトリの[Settings]を開く。
1. サイドメニューの[Actions]を展開し、[General]を選択する。
1. 「Access」セクションで、「Accessible from repositories owned by the user 'USER_NAME'」を選択する。
1. [Save]をクリックする。

## Reusable Workflow を参照して使うワークフロー

Reusable Workflow を参照して使う側のワークフローを作成する。  
このリポジトリには、すでに ESLint が導入されているとする。そのため、ESLint の設定方法はこの記事に記載しない。

次の内容で、Reusable Workflow を参照するワークフローを「.github/workflows」の下に作成する。  
他のリポジトリにある Reusable Workflow を参照するには、`job.<job_name>.uses` で使うワークフローのパスを指定する。

```yml:.github/workflows/eslint.yml
name: eslint

on:
  pull_request:

jobs:
  lint:
    uses: chick-p/github-actions-shared-workflows/.github/workflows/eslint.yml@main
```

## 動作確認

今回参照する側のワークフローでは、Pull Request を作成したときに実行されるように設定した。  
そのため Pull Request を作って動作を確認する。

![スクリーンショット：ワークフローの実行結果](/til/github-aciton-workflow-reusable-private-repository/result.png)

プライベートリポジトリに置いた Reusable Workflow が呼び出されて実行できている。  
このリポジトリでは ESLint がエラーで落ちるような内容にしているため、CI としては失敗することが期待値である。

## リポジトリごとに個別の値を渡したい

実際の運用では、Reusable Workflow を参照するリポジトリごとに、ワークフローの微妙な違いが発生することがある。  
たとえば、Node.js のパッケージマネージャーが Yarn である場合や、リポジトリごとに少し異なるコマンドを使いたい場合が考えられる。  
Reusable Workflow では、参照して使う側から入力値を渡すことができるため、このようなケースでも対応できる。

### Reusable Workflow を置くリポジトリ側

参照するワークフロー側から入力値を渡すには、`workflow_call.input` に変数名や型を定義する。  
定義した変数は、`${{ inputs.<variable_name` }}` で取り出せる。  
参照：[Using inputs and secrets in a reusable workflow](https://docs.github.com/en/actions/using-workflows/reusing-workflows#using-inputs-and-secrets-in-a-reusable-workflow)

修正後のワークフローでは、次のことを対応することにした。

- パッケージマネージャーを npm か yarn を選べる
- Lint のコマンドを渡せるようにする

```diff:.github/workflows/eslint.yml
name: eslint
on:
  workflow_call:
+    inputs:
+      manager:
+        required: false
+        type: string
+        default: 'npm'
+      command:
+        required: false
+        type: string
+        default: 'npm run eslint'

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Use Node.js
        uses: actions/setup-node@v3
+        with:
+          node-version: 16
+          cache: ${{ inputs.manager }}

-      - name: Install dependencies
+      - name: Install dependencies (npm)
+        if: ${{ inputs.manager == 'npm' }}
        run: npm ci

+      - name: Install dependencies (yarn)
+        if: ${{ inputs.manager == 'yarn' }}
+        run: yarn install

      - name: Run lint
-        run: npm run eslint
+        run: ${{ inputs.command }}
```

### Reusable Workflow を参照して使う側

参照して使う側から入力値を設定するには、`with.<variale_name>` を使う。

```diff:.github/workflows/eslint.yml
name: eslint

on:
  pull_request:

jobs:
  lint:
    uses: chick-p/github-actions-workflow-provider/.github/workflows/eslint.yml@main
+    with:
+      manager: "yarn"
+      command: "yarn lint:eslint"
```

### 動作確認 {#reusable-confirm}

参照して使う側のリポジトリで、パッケージマネージャーを Yarn にして、Pull Request を作成する。

![スクリーンショット：ワークフローの実行結果](/til/github-aciton-workflow-reusable-private-repository/result2.png)

無事、`manager` と `command` に設定した値が使われた。


プライベートリポジトリにある GitHub Workflow をほかのリポジトリで使う

Homebrew で Formula にない任意のバージョンをインストールする方法のメモ

---
title: "Homebrew で Formula にない任意のバージョンのパッケージをインストールする"
description: "Homebrew で Formula にない任意のバージョンをインストールする方法のメモ"
type: "TIL"
date: "2022-12-13T21:00:00+0900"
tags:
  - "Homebrew"
  - "DartSass"
---

Homebrew では、バージョンを指定しなければ、Homebrew Formula の最新バージョンがインストールされる。  
過去バージョンが Homebrew Formula に存在する場合は、`@` 以降にバージョンを指定すると、指定したバージョンでインストールできる。

```shell
# 指定できるバージョンを調べる
# 例は postgresql
$ brew search postgresql@

==> Formulae
postgresql@10       postgresql@12       postgresql@14       postgresql@9.4      qt-postgresql
postgresql@11       postgresql@13       postgresql@15       postgresql@9.5      postgrest
==> Casks
navicat-for-postgresql

# @ 以降にインストールしたいバージョンを指定する
$ brew install postgresql@14
```

Homebrew Formula に過去バージョンが残されていない場合、上記の方法ではインストールできない。  
そのため、インストールするバージョンのスクリプトを指定した Formula をローカルに作成することで、任意のバージョンをインストールする。  
ただし、インストールスクリプトを実行するため、Ruby の実行環境が必要である。

## 動作環境

- Homebrew v3.6.15

## Homebrew 公式で提供されているパッケージをインストールする場合

Homebrew 公式で提供されているパッケージは、[Homebrew/homebrew-core](https://github.com/Homebrew/homebrew-core/) で管理されている。

### 1. ローカルにオリジナルの Formula を作成する

`brew tap-new ユーザー名/Formula 名` で新規の Formula を作成する。  
`Formula 名` は、`brew install` するときに指定するパッケージ名となる。

たとえば、Go v1.18.5 をインストールしたいとする。

```shell
# Go の場合
$ brew tap-new $USER/go

Initialized empty Git repository in /usr/local/Homebrew/Library/Taps/chick-p/homebrew-go/.git/
[main (root-commit) b435276] Create chick-p/go tap
...省略...
==> Created chick-p/go
/usr/local/Homebrew/Library/Taps/chick-p/homebrew-go
...省略...
```

`brew extract --version=インストールするバージョン Formla名` で、過去バージョンのインストールスクリプトを特定する。

```shell
$ brew extract --version=1.18.5 go $USER/go

==> Searching repository history
==> Writing formula for go from revision fad51b0 to:
/usr/local/Homebrew/Library/Taps/chick-p/homebrew-go/Formula/go@1.18.5.rb
```

### 2. オリジナルの Formula を指定してインストールする

`brew install` でインストールするパッケージ名に、オリジナルの Formula を指定する。

```shell
$ brew install $USER/go/go@1.18.5

==> Fetching chick-p/go/go@1.18.5
...省略...
==> Downloading from https://dl.google.com/go/go1.18.5.src.tar.gz
######################################################################## 100.0%
==> Installing go@1.18.5 from chick-p/go
...省略...
```

## brew tap Formula で追加するパッケージをインストールする場合 {#tap-formula}

Homebrew 公式で提供されていないパッケージをインストールする場合 `brew tap` して Formula を追加してからインストールする必要がある。  
こういったパッケージで特定のバージョンをインストールする場合も、公式で提供されているパッケージをインストールする方法と同じである。  
ただし、`brew extract` で指定する Formula 名には、tap に必要だったパスも記載する必要がある。

たとえば、dart-sass-embbed の場合、brew extract で sass/sass/dart-sass-embedded を指定する。

```shell
# dart-sass-embbed v1.56.1 をインストールする例
$ brew tap-new $USER/dart-sass-embedded
$ brew extract --version=1.56.1 sass/sass/dart-sass-embedded $USER/dart-sass-embedded
$ brew install $USER/dart-sass-embedded/dart-sass-embedded@1.56.1
```

インストールできたことを確認する。

```shell
$ dart-sass-embedded --version

{
  "protocolVersion": "1.2.0",
  "compilerVersion": "1.56.1",
  "implementationVersion": "1.56.1",
  "implementationName": "Dart Sass",
  "id": 0
}
```


Homebrew で Formula にない任意のバージョンのパッケージをインストールする

AWS Systems Manager を使ってキーペアなしに EC2 インスタンスにアクセスしてみる

---
title: "AWS Systems Manager を使って EC2 にアクセスする"
description: "AWS Systems Manager を使ってキーペアなしに EC2 インスタンスにアクセスしてみる"
type: "TIL"
date: "2022-10-13T12:15:00+0900"
tags:
  - "AWS Systems Manager"
---

## AWS Systems Manager

[AWS Systems Manager（SSM）](https://aws.amazon.com/jp/systems-manager/) は、AWS 上に構築した EC2 インスタンスなどのリソースを管理、制御できるサービスである。  
この記事では、SSM のセッションマネージャーの機能を使って、キーペアを使わずに EC2 インスタンスへ接続するための設定を記載する。

## セッションマネージャー機能を使うメリット

EC2 インスタンスへの接続にセッションマネージャー機能を使ったときのメリットは次のとおり。

* キーペアを管理する必要がない
* SSH 接続のために 22 番ポートを開ける必要がない
* プライベートなサブネットに EC2 を構築した場合は、インターネットに晒す必要がない

## 前提

* [AWS CLI v1.16.12 以降](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-prerequisites.html) のインストールおよびプロファイルの作成  
  この記事では、AWS CLI v2.1.7 で動作を確認した。

## STEP1：EC2 インスタンスの作成

EC2 インスタンスを作成する。
重要なのは、次の 3 つである。

* [SSM Agent のインストール](#ssm-agent-のインストール)
* [Session Manager の利用権限を付与した IAM ロールのアタッチ](#session-manager-の利用権限を付与した-iam-ロールのアタッチ)
* [プライベートサブネットに作成する場合には、サブネットに次のいずれかを設定](#プライベートサブネットに作成する場合の注意点)
  * NAT Gateway の利用
  * VPC エンドポイントの作成

### SSM Agent のインストール

EC2 の作成ウィザードで、「高度な設定」の「ユーザーデータ」欄にインストールコマンドを記載する。  
インストールコマンドは、[SSM Agent の利用](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/ssm-agent.html)のページで、OS イメージごとに記載されている。  
なお、Amazon Linux 2 を利用する場合には、標準でインストールされているのでインストールする必要がない。  

以下は、RHEL 8.x に SSM Agent をインストールする場合の入力例である。

```bash
#!/bin/bash
sudo yum install -y https://s3.region.amazonaws.com/amazon-ssm-region/latest/linux_arm64/amazon-ssm-agent.rpm
```

![スクリーンショット：「ユーザーデータ」の入力例](/til/aws-system-manager/ssm-user-data.png)

### Session Manager の利用権限を付与した IAM ロールのアタッチ

EC2 の作成ウィザードで、以下のポリシーを付与した IAM ロールをインスタンスにアタッチする必要がある。

* `AmazonSSMManagedInstanceCore`

### プライベートサブネットに作成する場合の注意点

プライベートサブネットに作成する場合には、サブネットに次のいずれかを設定する。

* **方法1**：NAT Gateway の利用
* **方法2**：VPC エンドポイントの作成  
  作成する VPC エンドポイントの詳細は、次のページを参照のこと。  
  [Systems Manager を使用してインターネットアクセスなしでプライベート EC2 インスタンスを管理できるように、VPC エンドポイントを作成するにはどうすればよいですか?](https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-systems-manager-vpc-endpoints/)

### 設定例

この記事では、次の設定内容で EC2 インスタンスを作成した。  
記載していない項目は初期値のままである。

1. 「アプリケーションおよび OS イメージ (Amazon マシンイメージ)」で次の内容を選択する
    * **OS イメージ**：Amazon Linux 2 AMI
    * **アーキテクチャ**：64 ビット（x86）
1. 「インスタンスタイプ」で「t2.micro」を選択する
1. 「ネットワーク設定」の、「任意の場所からの SSH トラフィックを許可する」の選択を外す
1. 「高度な設定」の「IAM インスタンスプロフィール」で、[新しい IAM プロファイルの作成]をクリックする
1. 次のポリシーをアタッチした新しい IAM ロールを作成する
   * `AmazonSSMManagedInstanceCore`
1. 先ほど作成した IAM ロールを選択する
1. [インスタンスを起動]をクリックする
1. 「キーペアなしで続行」を選択し、[キーペアなしで続行]をクリックする
1. [インスタンスを起動]をクリックし、インスタンスを起動する

## STEP2： AWS CLI 用の Session Manager プラグインのインストール

次のコマンドで、SSH 接続する端末に Session Manager プラグインをインストールする。  
参考：[AWS CLI 用の Session Manager プラグインをインストールする](https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html)

```bash
$ curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac/sessionmanager-bundle.zip" -o "sessionmanager-bundle.zip"
$ unzip sessionmanager-bundle.zip
$ sudo ./sessionmanager-bundle/install -i /usr/local/sessionmanagerplugin -b /usr/local/bin/session-manager-plugin
```

インストール後に、次のコマンドを実行する。インストールが成功したことを示すメッセージが表示されれば OK。

```bash
$ session-manager-plugin

The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.
```

## STEP3：セッションマネージャーで EC2 インスタンスに接続する

次のコマンドで EC2 インスタンスに接続する。  
セッションが開始されたことを示すメッセージとプロンプトが表示されれば OK 。

```bash
$ aws ssm start-session --target EC2_INSTANCE_ID --profile PROFILE_NAME

Starting session with SessionId: chickp-0b12c54d8bfe987dd
sh-4.2$
```

`whoami` コマンドを実行すると、SSM 接続用の「ssm-user」というユーザーアカウントで接続されていることがわかる。

```bash
sh-4.2$ whoami
ssm-user
```


AWS Systems Manager を使って EC2 にアクセスする

シェルスクリプトの品質をチェックできる ShellCheck を GitHub 上で動かす

---
title: "GitHub Actions の Problem Matchers で ShellCheck の指摘を表示する"
description: "シェルスクリプトの品質をチェックできる ShellCheck を GitHub 上で動かす"
type: "TIL"
date: "2022-09-13T23:20:00+0900"
tags:
  - "ShellCheck"
  - "Problem Matchers"
---

[ShellCheck](https://www.shellcheck.net/) は、シェルスクリプト用の Lint ツールで、文法上の問題や想定外な実行結果が起こらないようにチェックするツールである。  
シェルスクリプトは雰囲気で書いているので、Linter があるのは嬉しい。

この記事では、ShellCheck の実行方法や、GitHub Actions の Problem Matchers で ShellCheck の指摘を表示する方法を説明する。

## ShellCheck をインストールする

Mac であれば homebrew を使ってインストールできる。

```bash
brew install shellcheck
```

## ShellCheck を実行する

ShellCheck は次のコマンドで実行できる。

```bash
shellcheck *.sh
```

例えば次のような、定義されていない変数を使っているようなスクリプトに対してチェックをしたとする。

```bash
#!/bin/bash

echo "$foo"
```

ShellCheck を実行すると、構文エラーとなる項目が表示される。

```bash
shellcheck -f gcc *.sh

test.sh:3:7: warning: foo is referenced but not assigned. [SC2154]
```

## GitHub Actions で ShellCheck を実行する

GitHub Actions では、ランナーが Linux の場合のみ、ShellCheck がプリインストールされている。  
そのため、他の Lint ツールのように事前にインストールする必要がない。  
Ref. [https://github.com/koalaman/shellcheck#in-your-build-or-test-suites](https://github.com/koalaman/shellcheck#in-your-build-or-test-suites)

ShellCheck を GitHub Actions で動かすためのアクションはいくつか公開されているが、開発元が公開した Actions はなかった。  
今回は、[Problem Matchers](https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md) を使って、指摘内容を GitHub Actions のアノテーションに表示させる。  
ちなみに、[ludeeus/action-shellcheck](https://github.com/ludeeus/action-shellcheck) というアクションでは、Problem Matchers を使ってアノテーション表示できるようだった。

### エラー結果をキャプチャするルールファイルを追加する

[Problem Matchers](https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md) とは、GitHub Action の出力結果を正規表現のパターンとして解析し、アノテーションを表示する機能である。  
出力結果のパターンをどのようにキャプチャするかのルールは、json ファイルで定義する。  
あとで GitHub Actions のワークフロー側で指定するため、ファイル名や位置は何でも良い。  
ただ、GitHub.com の機能なので、`.github` 以下に置くと行儀が良さそう。

`owner` に Problem Matchers の固有の ID を割り振り、`pattern` 以下に正規表現のパターンを定義する。  
今回の ShellChecker は gcc 形式で出力するので、`regexp` は gcc 形式に合わせた正規表現とした。  
また、キャプチャしたグループの順番を、`file`（ファイル名）や `line`（行番号）といったプロパティに指定する。

```json:.github/shellcheck-matcher.json
{
  "problemMatcher": [
    {
      "owner": "shellcheck-matcher",
      "pattern": [
        {
          "regexp": "^(.+):(\\d+):(\\d+):\\s(note|warning|error):\\s(.*)\\s\\[(SC\\d+)\\]$",
          "file": 1,
          "line": 2,
          "column": 3,
          "severity": 4,
          "message": 5,
          "code": 6
        }
      ]
    }
  ]
}
```

### GitHub Actions のワークフローを追加する

ShellChecker を実行する GitHub Actions のワークフローを追加する。  
Problem Matchers を使って実行結果をキャプチャするには、ツールの実行前に `echo "::add-matcher::ルールファイルのパス"` を実行すれば良い。

```yaml:.github/workflows/shellcheck.yml
name: shellcheck

on:
  pull_request:
    paths:
      - "*.sh"

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Enable Problem Matchers
        run: echo "::add-matcher::.github/shellcheck-matcher.json"
      - name: Exec shellcheck
        run: |
          shellcheck -f gcc *.sh
          echo "::remove-matcher owner=shellcheck-matcher::"
```

先ほどの、定義していない変数を使ったシェルスクリプトに対し、このワークフローを実行すると、アノテーションにエラー内容が表示された。

![画面キャプチャ：GitHub Actions のアノテーションに、ShellChecker の指摘が表示されている](/til/shellcheck-problem-matchers/github-action-result.png)


GitHub Actions の Problem Matchers で ShellCheck の指摘を表示する

ローカルと GitHub Actions で Dockle を動かしてみた

---
title: "Dockle で Docker イメージのセキュリティやベストプラクティスをチェックする"
description: "ローカルと GitHub Actions で Dockle を動かしてみた"
type: "TIL"
date: "2022-09-07T21:20:00+0900"
tags:
  - "Docker"
  - "Dockle"
---

[Dockle](ttps://github.com/goodwithtech/dockle) は、Docker コンテナイメージのセキュリティチェックや、Docker ファイルのベストプラクティスをチェックできるツールである。  
以前調べた [hadolint](/blog/docker-hadolint/) や [Trivy](/blog/docker-trivy/) をあわせたような機能をもっている。

{% embed src="https://github.com/goodwithtech/dockle" title="goodwithtech/dockle" /%}

## Dockle をインストールする

Mac であれば homebrew を使ってインストールできる。

```bash
brew install goodwithtech/r/dockle
```

## Dockle を実行する

Dockle は次のコマンドで実行できる。

```bash
dockle IMAGE_NAME
```

Docker daemon を起動する必要はないが、Dockerfile のベストプラクティスをチェックしたい場合には、イメージを作っておく必要がある。  
たとえば次の内容の Docker ファイルを Dockle でチェックするとする。

```docker:Dockerfile
FROM node:latest
```

その場合は、`docker build` で作ったイメージに対してチェックする。

```bash
docker build ./ -t dockle-example
dockle dockle-example
```

Dockle を実行すると、診断結果が表示される。

```bash
WARN  - CIS-DI-0001: Create a user for the container
  * Last user should not be root
WARN  - DKL-DI-0006: Avoid latest tag
  * Avoid 'latest' tag
INFO  - CIS-DI-0005: Enable Content trust for Docker
  * export DOCKER_CONTENT_TRUST=1 before docker pull/build
INFO  - CIS-DI-0006: Add HEALTHCHECK instruction to the container image
  * not found HEALTHCHECK statement
INFO  - CIS-DI-0008: Confirm safety of setuid/setgid files
  * setuid file: urwxr-xr-x bin/su
  * setgid file: grwxr-xr-x sbin/unix_chkpwd
  * setuid file: urwxr-xr-x usr/bin/passwd
  * setgid file: grwxr-xr-x usr/bin/expiry
  * setuid file: urwxr-xr-x bin/mount
  * setgid file: grwxr-xr-x usr/bin/chage
  * setgid file: grwxr-xr-x usr/bin/ssh-agent
  * setuid file: urwxr-xr-x usr/bin/chfn
  * setuid file: urwxr-xr-x usr/bin/gpasswd
  * setuid file: urwxr-xr-x bin/umount
  * setuid file: urwxr-xr-x usr/bin/chsh
  * setuid file: urwxr-xr-x usr/bin/newgrp
  * setgid file: grwxr-xr-x usr/bin/wall
  * setuid file: urwxr-xr-x usr/lib/openssh/ssh-keysign
INFO  - DKL-LI-0003: Only put necessary files
  * Suspicious directory : root/.npm
```

## Dockle のチェック項目と、hadolint や Trivy との違い

チェック項目の詳細は、[Checkpoint](https://github.com/goodwithtech/dockle/blob/master/CHECKPOINT.md) で確認できる。  
たとえば `CIS-DI-0001` は、コンテナ用のユーザーを作るべしというルールである。  
この項目は hadolint ではチェックできないが、Dockle ではチェックできる。

Dockle でチェックできるルールは、次のプラクティスに基づいている。

- `CIS` から始まるルール：[CIS Docker 1.13.0 Benchmark v1.0.0](https://www.cisecurity.org/benchmark/docker/) に沿っているか
- `DKL-DI` から始まるルール：[Docker Best Practice](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) に沿っているか
- `DKL-LI` から始まるルール：[Docker Linux Practice](https://www.cyberciti.biz/tips/linux-security.html) に沿っているか

hadolint では、[Docker Best Practice](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/) に沿っているかをチェックする。  
そのため、hadolint でチェックできる内容は、Dockle でもチェックできる。  
一方で、Trivy と Dockle は、チェックできる脆弱性の対象が異なる。  
Trivy では CVE などの脆弱性データベースに基づいているのに対し、Dockle は、CIS ベンチマークに基づいている。

## GitHub Actions で Dockle を実行する

Dockle を GitHub Actions で動かすためのアクションはいくつか公開されているが、hadolint や Trivy と違って、開発元が公開した Actions はなかった。  
この記事では、一番スター数の多い [erzz/dockle-action](https://github.com/erzz/dockle-action)を使うことにする。  
README のサンプルに沿って、リポジトリ内の Dockerfile をチェックするワークフローファイルを追加する。  

```yaml:dockle.yml
name: dockle

on:
  pull_request:
    paths:
      - "Dockefile"

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build an image from Dockerfile
        run: |
          docker build ./ -t my-image
      - name: Run Dockle
        uses: erzz/dockle-action@v1
        with:
          image: my-image
```

ワークフローを実行すると、項目に違反する内容を検出できた。

![スクリーンショット：GitHub Actions での Dockle の実行結果](/til/docker-dockle/dockle-result-action.png)


Dockle で Docker イメージのセキュリティやベストプラクティスをチェックする

HTML をパーズして OGP のメタ情報を返す API を、Netlify Edge Function で実装する

---
title: " Netlify Edge Functions で Web ページの OGP データを取得する関数を作る"
description: "HTML をパーズして OGP のメタ情報を返す API を、Netlify Edge Function で実装する"
date: "2022-09-04T17:30:00+0900"
tags:
  - "Netlify Edge Functions"
  - "Open Graph Protocol"
---

このブログでは、外部の Web サイトの埋め込みパーツを iFramely を使って実装していた。  
ただ表示されるまでに少し遅延があったり、気軽にスタイルを変更したりしたいので、自分で実装することにする。  
Web ページから直接 HTML を取得すると CORS 制約にかかってしまうので、HTML をパーズして OGP のメタ情報を返す API を、Netlify Edge Function で実装する。

このページでは、`url` というクエリパラメーターに OGP を取得したい Web ページの URL を指定して `https://foo.netlify.app/get-meta` に GET リクエストを送信すると、Web サイトの OGP を JSON 形式で取得する Edge Function を作る。  
この記事で作成する Edge Function は、[chick-p/netlify-edge-function-ogp](https://github.com/chick-p/netlify-edge-function-ogp) に置いている。

## Netlify Edge Functions とは

[Netlify Edge Functions](https://docs.netlify.com/edge-functions/overview/) は、Netlify が提供する、ユーザーのロケーションに近いエッジ環境でサーバーレス環境である。  
ほかの同様のサービスには、AWS の CloudFront Functions や Cloudflare の Cloudflare Workers がある。

Netlify Edge Functions の特徴は、次のとおり。

* Deno Deploy を採用しているため、TypeScript や JavaScript で書くことができる
* メモリは 512MB、CPU 時間は 50ミリ秒以内という制約がある
* Netlify のフリープランの場合、3 分/月まで実行できる

Edge Function は次の 3 ステップで作成できる。

1. `netlify/edge-functions` というディレクトリの中に実行するスクリプトを置く
1. `netlify.toml` に呼び出すスクリプトとルーティングの設定を書く
1. Netlify CLI を使ってデプロイする

いくつか [Edge Function のサンプル](https://github.com/netlify/edge-functions-examples/) が GitHub に公開されているので、書き方がわからない場合にはこれらのサンプルを参考にするとよさそう。

## Web ページの OGP データを取得する Netlify Edge Functions を作る

### 環境

- Netlify CLI v11.5.1

### STEP0：事前準備

プロジェクトのディレクトリに、次の構成でディレクトリとファイルを作成する。  
ファイルはまだ空のままで良い。

```shell
.
├── netlify
│   └── edge-functions
│       └── get-meta.ts
└─── netlify.toml
```

### STEP１：スクリプトを作る

`netlify/edge-functions/get-meta.ts` を開き、次の内容を記載する。  
Netlify Edge Functions では、export default するハンドラーの第一引数でリクエストを受け取り、`Response` オブジェクトを返却する。

```typescript:netlify/edge-functions/get-meta.ts
import { Context } from "https://edge.netlify.com";
import { DOMParser } from "https://deno.land/x/deno_dom/deno-dom-wasm.ts";

type Meta = Record<string, string>;

function extractOgp(metaElements: HTMLMetaElement[]): Meta {
  return metaElements
    .filter((element: HTMLMetaElement) => element.hasAttribute("property"))
    .reduce<Meta>((prev, element) => {
      const property = element.getAttribute("property")?.trim();
      if (!property) return { ...prev };
      const content = element.getAttribute("content") || "";
      return {
        ...prev,
        [property]: content,
      };
    }, {});
}

// eslint-disable-next-line import/no-anonymous-default-export
export default async (
  request: Request,
  context: Context
): Promise<Response> => {
  const url = new URL(request.url).searchParams.get("url"); // url クエリを受け取る
  if (!url) {
    return context.json({ error: "The query parameter of url is required." });
  }
  const resp = await fetch(url);
  const html = await resp.text();
  const document = new DOMParser().parseFromString(html, "text/html");
  const meta = document?.querySelectorAll("meta");
  if (!meta) {
    return context.json({ error: "Meta element are not found." });
  }
  const ogp = extractOgp([...meta]);
  const response = await context.json(ogp);
  // CORS 対策
  response.headers.set("Access-Control-Allow-Origin", "*");
  response.headers.set("Access-Control-Allow-Methods", "GET");
  return response;
};
```

### STEP2：呼び出すスクリプトとルーティングの設定を書く

`netlify.toml` 内の `[[edge_function]]` というセクションで、スクリプトとルーティングの関係を定義する。  
この関数では、クエリパラメーターを渡せるようにしたいので末尾に `*` というワイルドカードをつける。

```toml:netlify.toml
[build]
  command = "echo No build for this site, we are living on the edge"
  publish = "."

[[edge_functions]]
  function = "get-meta"
  path = "/get-meta*"
```

### STEP３：デプロイする

デプロイには、[Netlify CLI](https://docs.netlify.com/cli/get-started/) を使う。  
グローバルインストールすると、`netlify` というコマンドが使えるようになる。

```bash
$ npm install netlify-cli -g
```

まずはローカル環境で動作を確認する。プロジェクトのディレクトリで次のコマンドを実行する。
```bash
$ netlify dev

◈ Netlify Dev ◈
◈ Ignored general context env var: LANG (defined in process)
◈ No app server detected. Using simple static server
◈ Running static server from "netlify-edge-function-ogp"
◈ Setting up local development server

────────────────────────────────────────────────────────────────
  Netlify Build
────────────────────────────────────────────────────────────────

❯ Version
  @netlify/build 27.16.1

❯ Flags
  {}

❯ Current directory
  /Users/chick-p/works/netlify-edge-function-ogp

❯ Config file
  /Users/chick-p/works/netlify-edge-function-ogp/netlify.toml

❯ Context
  dev

────────────────────────────────────────────────────────────────
  1. Run command for local development
────────────────────────────────────────────────────────────────


◈ Static server listening to 3999

(dev.command completed in 8ms)

   ┌─────────────────────────────────────────────────┐
   │                                                 │
   │   ◈ Server now ready on http://localhost:8888   │
   │                                                 │
   └─────────────────────────────────────────────────┘

◈ Loaded edge function get-metas
```

`http://localhost:8888/get-meta?url=https://blog.chick-p.work` にアクセスして、OGP 情報に関する JSON が返ってくれば成功となる。

Netlify にデプロイするには、プロジェクトのディレクトリで次のコマンドを実行する。

```bash
# プレビュー環境の場合
$ netlify deploy --build

# プロダクション環境の場合
$ netlify deploy --build --prod
```

コマンドを実行すると Netlify にログインすることを求められ、アプリを新しく作るかどうかを尋ねられる。
新しくアプリを作ることを選択すると、デプロイが始まる。

```shell
$ netlify deploy --build --prod

Packaging Edge Functions from netlify/edge-functions directory:
 - get-meta

(Edge Functions bundling completed in 2.4s)

────────────────────────────────────────────────────────────────
  Netlify Build Complete
────────────────────────────────────────────────────────────────

(Netlify Build completed in 2.5s)
Deploy path:        /Users/chick-p/works/netlify-edge-function-ogp
Configuration path: /Users/chick-p/works/netlify-edge-function-ogp/netlify.toml
Deploying to main site URL...
✔ Finished hashing 5 files and edge functions
✔ CDN requesting 0 files
✔ Finished uploading 0 assets
✔ Deploy is live!

Logs:              https://app.netlify.com/sites/foo/deploys/63145a19063a093f65a88c86
Unique Deploy URL: https://63145a19063a093f65a88c86--foo.netlify.app
Website URL:       https://foo.netlify.app
```

実行結果の最後の「Website URL」が Edge Function をデプロイしたアプリの URL になる。  
URL の末尾に `/get-meta?url=OGP情報を取得したいURL` を実行して、ローカル環境で確認結果と同様に、OPG 情報の JSON が返ってくれば成功である。


 Netlify Edge Functions で Web ページの OGP データを取得する関数を作る

VSCode で URL が <> で囲まれてしまう挙動を無効化する

---
title: "VSCode で Markdown ファイルを編集したときに URL が <> で囲まれてしまうのを防ぎたい"
description: "VSCode で URL が <> で囲まれてしまう挙動を無効化する"
type: "TIL"
date: "2022-09-04T12:30:00+0900"
tags:
  - "Visual Studio Code"
  - "markdownlint"
---

VSCode で Markdown ファイル内に URL を記載すると、自動で `<>` で囲まれる現象が発生していた。  
地味にストレスだったので、この挙動を無効にしたい。

調べてみると、次の設定が影響していることがわかった。

* [markdownlint の VSCode 拡張](https://marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint) をインストールしているため、markdownlint が実行される
* VSCode で、保存する時に Markdown ファイルに lint の結果を適用している

URL を自動で `<>` で囲むのは markdownlint の [MD034](https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md034---bare-url-used) というルールだった。  

解決方法としては、このルールを VSCode の設定で無効化する。
具体的には、コマンドパレット（Shift + Command + P）で[Open User Settings]を開いて、表示された JSON ファイルの末尾に以下を追記すればよい。

```diff:settings.json
    "[markdown]": {
        "files.trimTrailingWhitespace": false,
        "editor.formatOnSave": true, // ファイルを保存するときに markdownlint が適用される
        "editor.formatOnPaste": false,
    },
+    "markdownlint.config": {
+        "default": true,
+        "MD034": false
+    }
```


VSCode で Markdown ファイルを編集したときに URL が <> で囲まれてしまうのを防ぎたい

ローカルと GitHub Actions で Trivy を動かしてみた

---
title: "Trivy で Docker イメージの脆弱性をチェックする"
description: "ローカルと GitHub Actions で Trivy を動かしてみた"
type: "TIL"
date: "2022-08-30T22:23:00+0900"
tags:
  - "Docker"
  - "Trivy"
---

Trivy は、Docker コンテナイメージなどの脆弱性を診断できるツールで、次の特徴をもっている。

* Docker コンテナイメージの OS のパッケージの脆弱性を検出する
* コンテナ上で動くアプリケーションが依存するライブラリの脆弱性を検知する
* コンテナイメージ以外にも、ファイルシステムや AWS アカウントのセキュリティをチェックする  
  Ref. [TrivyでAWSアカウントのセキュリティスキャンができるようになりました](https://dev.classmethod.jp/articles/aws-security-scan-by-trivy/)

{% embed src="https://github.com/aquasecurity/trivy" title="aquasecurity/trivy" /%}

## Trivy をインストールする

Mac であれば homebrew を使ってインストールできる。

```bash
brew install aquasecurity/trivy/trivy
```

## Trivy を実行する

コンテナイメージの脆弱性をチェックするには、次のコマンドを実行する。  
Docker daemon を起動する必要はない。

```bash
trivy image IMAGE
# trivy image node:16-slim
```

脆弱性の一覧が、テーブル形式で出力される。

```markdown
node:16-slim (debian 10.12)
===========================
Total: 133 (UNKNOWN: 0, LOW: 84, MEDIUM: 10, HIGH: 29, CRITICAL: 10)

┌───────────────┬──────────────────┬──────────┬─────────────────────────┬───────────────┬──────────────────────────────────────────────────────────────┐
│    Library    │  Vulnerability   │ Severity │    Installed Version    │ Fixed Version │                            Title                             │
├───────────────┼──────────────────┼──────────┼─────────────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ apt           │ CVE-2011-3374    │ LOW      │ 1.8.2.3                 │               │ It was found that apt-key in apt, all versions, do not       │
│               │                  │          │                         │               │ correctly...                                                 │
│               │                  │          │                         │               │ https://avd.aquasec.com/nvd/cve-2011-3374                    │
... 略 ...
└───────────────┴──────────────────┴──────────┴─────────────────────────┴───────────────┴──────────────────────────────────────────────────────────────┘
```

イメージ名が引数になるので、Dockerfile を対象にする場合は、あらかじめイメージにビルドする必要がある。

```bash
docker build ./ -t foo
trivy image foo
```

## GitHub Actions で Trivy を実行する

[Trivy を GitHub Actions で動かすためのアクション](https://github.com/aquasecurity/trivy-action)も公開されている。  
README のサンプルに沿って、リポジトリ内の Dockerfile をチェックするワークフローファイルを追加する。

```yml:trivy.yml
name: trivy
on:
  pull_request:
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      - name: Build an image from Dockerfile
        run: |
          docker build ./ -t my-image
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@v0.7.1 # 記事作成時点での最新版
        with:
          image-ref: 'my-image:latest'
          format: 'table'
          exit-code: '1'
          ignore-unfixed: true # 修正されていない脆弱性は無視する
          vuln-type: 'os,library'
          severity: 'CRITICAL,HIGH'
```

ワークフローを実行すると、ちゃんと脆弱性を検出できた。

![スクリーンショット：GitHub Actions での Trivy の実行結果](/til/docker-trivy/trivy-result-action.png)

検出された脆弱性に対しては、Dockerfile 内で `apt-get upgrade` してパッケージを最新にしておく。  
これで修正されている脆弱性には対応できる。

```diff:Dockerfile
FROM node:16-slim
+ RUN apt-get update && apt-get -y upgrade \
+  && apt-get clean \
+  && rm -rf /var/lib/apt/lists/*

# 続く...
```


Trivy で Docker イメージの脆弱性をチェックする

markdoc + Next.js 製のブログに Iframely で外部リンクを埋め込むための独自タグを実装した。

---
title: "markdoc + Next.js 製のブログで Iframely の外部リンクを埋め込むタグを作る"
description: "markdoc + Next.js 製のブログに Iframely で外部リンクを埋め込むための独自タグを実装した。"
date: 2022-08-26T22:00:00+09:00
tags:
  - markdoc
  - Next.js
  - Iframely
---

最近、このブログを Gatsby.js から Stripe が開発している [markdoc](https://markdoc.dev/) と Netx.js 使って書き換えた。  
それに伴って、外部リンクを見栄え良く表示できる [Iframely](https://iframely.com/) を埋め込む仕組みを変更する必要があったため、markdoc の独自タグを作成した。

## markdoc の独自タグ

markdoc では、Markdown ファイル内で `{% TAG %}` のような形式で書くことでMarkdown では表現できない HTML 要素を記述できる。  
これを実現するために、独自タグを実装する。  
Gatsby.js の Component や HUGO のショートコードのようなものである。

{% embed src="https://markdoc.dev/docs/nextjs#tags" title="markdoc | Tags" /%}

この仕組みを使って、Markdown ファイル内に次のように記述すれば、Iframely を使って外部サイトの情報を埋め込みできるタグを実装する。  

{% markdoc-example %}

```markdoc
{% iframely href="URL" id="DATA-ID" /%}
```

{% /markdoc-example %}

なお、記事におけるファイル構成は、[Schema customization](https://markdoc.dev/docs/nextjs#schema-customization) に従うものとする。

## タグの実装

今回は「iframely」という名前のタグを実装する。

### STEP1：タグを定義する

「iframely.markdoc.ts」という名前のファイルを作る。

`render` プロパティにはレンダリングするコンポーネント（後述）を指定し、`attributes` にはそのコンポーネントに渡す引数を定義する。  
Iframely を使って外部リンクに埋め込むときは、次の 2 箇所が可変となるので、これらの値を引数に取るようにする。

* `a` 要素に指定する `href` 属性
* `data-iframely-url` 属性内の「//iframely.net/`この部分`」、

```ts:markdoc/tags/iframely.markdoc.ts
import { Iframely } from "../../components/Iframely";

// eslint-disable-next-line import/no-anonymous-default-export
export default {
  render: Iframely,
  description: "iframely",
  attributes: {
    href: {
      type: String,
      description: "The link url",
    },
    id: {
      type: String,
      description: "The data-framely ID",
    }
  },
};
```

### STEP2：コンポーネントを実装する

「iframely.markdoc.ts」に指定するコンポーネントを実装する。  
レンダリングする HTML は Iframely が生成するタグと同じ構造にして、可変となる `href` と `id` の値をコンポーネントに渡す。  
実際の Iframely が生成するタグには `class` 属性がついているが、自分のブログでは表示が壊れたためそれらの `class` 属性は付与していない。
また、Iframely を表示するためのスクリプトタグは、`<head>` に適用するので削除した。

```tsx:components/Iframely.tsx
export function Iframely({ href, id }) {
  return (
    <>
      <div>
        <a
          href={href}
          data-iframely-url={`//iframely.net/${id}?card=small`}
        ></a>
      </div>
    </>
  );
}
```

実装したタグを tags のルートファイルにエクスポートする。

```ts:markdoc/tags/index.ts
export { default as iframely }  from "./iframely.markdoc";
```

### STEP3：Iframely のスクリプトタグを追加する

記事を表示するコンポーネントに、Iframely のスクリプトタグを入れる。  
今回は [react-helmet](https://github.com/nfl/react-helmet) を使って `<head>` タグ内に差し込む。

```diff:_app.tsx
import React from "react";
+ import Helmet from "react-helmet";
// 省略
export function Home({ options }) {
+  React.useEffect(() => {
+    if (window.iframely) {
+      window.iframely.load();
+    }
+  });
  // 省略
  const { ast, content, config, errors } = useMarkdocCode(code);
  const children = content.children;
  return (
    <>
+      <Helmet>
+        <script async src="https://cdn.iframe.ly/embed.js" />
+      </Helmet>
      
      <div>
        {Markdoc.renderers.react(children, React, {
          components: config.components,
        })}
      </div>
    </>
  ):
}
```

`window` に `iframely` がないと怒られるので、型定義ファイルに宣言を追加する。

```typescript:types/global.d.ts
declare var iframely: any;
```

### STEP4：実装したタグを markdown parser のスキーマに渡す

独自タグを markdoc の schema に渡す。  
parse した markdown がレンダリングされる前にタグを解釈する必要があるので、記事を表示するコンポーネント内で schema を指定する。  
[Create a custom tag](https://markdoc.dev/docs/tags)

次の例は、トップページで Markdown ファイルのコンテンツを表示するコードである。

```diff:pages/_app.tsx
import React from "react";
+ import { getSchema } from '@markdoc/next.js/runtime';
// 省略
+ import * as tags from "../markdoc/tags";
+ const schema = {
+   tags,
+ };
// 省略
export function useMarkdocCode(code) {
  const ast = React.useMemo(() => Markdoc.parse(code), [code]);
  const config = React.useMemo(() => {
+    const { components, ...rest } = getSchema(schema);
    return {
      ...rest,
      variables: {
        markdoc: {
          frontmatter
        },
      },
      components,
    };
  }, [ast]);
}

export function Home({ options }) {
  const { ast, content, config, errors } = useMarkdocCode(code);
  const children = content.children;
  return (
    <>
      <Helmet>
        <script async src="https://cdn.iframe.ly/embed.js" />
      </Helmet>
      <div>
        {Markdoc.renderers.react(children, React, {
          components: config.components,
        })}
      </div>
    </>
  ):
}
```

## 動作確認

1. [Iframely](https://iframely.com/try) にアクセスする。
1. 埋め込みたいページの URL を入力して、タグを生成する。
1. 生成されたタグにある`data-iframely-url` 属性内の「//iframely.net/`この部分`」（ID）を確認する。
1. ブログにMarkdown ファイルを追加し、次のように記載する。

    {% markdoc-example %}

    ```markdoc
    {% iframely href="埋め込む記事のURL" id="ID" /%}
    ```

    {% /markdoc-example %}

1. プレビューして、リンクが埋め込まれて表示されていれば成功となる。
  ![スクリーンショット：記事の埋め込みリンクが表示されている](/markdoc-nextjs-tag-iframely/example.png)

markdoc + Next.js 製のブログで Iframely の外部リンクを埋め込むタグを作る

リポジトリ内の png 画像のファイルに対し、圧縮してファイルサイズを減らすことができるかチェックする、GitHub Actions を作りました。

---
title: "png 画像のファイルサイズを節約できるかをチェックする GitHub Actions を作った"
date: 2022-08-24T09:19:38+09:00
updated: 2022-08-27T09:19:38+09:00
tags:
  - GitHub Actions
  - 画像圧縮
description: "リポジトリ内の png 画像のファイルに対し、圧縮してファイルサイズを減らすことができるかチェックする、GitHub Actions を作りました。"
---

リポジトリ内の png 画像のファイルに対し、圧縮してファイルサイズを減らすことができるかチェックする、GitHub Actions（[action-png-size-lint](https://github.com/chick-p/action-png-size-lint/)）を作りました。

{% embed src="https://github.com/chick-p/action-png-size-lint/" title="chick-p/action-png-size-lint" /%}

このアクションでは、[zopflipng](https://github.com/google/zopfli) を使って png ファイルの圧縮後のサイズを算出し、ファイルサイズを減らせるようであればエラーで CI を落とします。

## モチベーション

GitHub.com では、[ひとつのリポジトリのサイズを 5GB 未満にすることを推奨しています](https://docs.github.com/ja/repositories/working-with-files/managing-large-files/about-large-files-on-github#repository-size-limits)。  
リポジトリのサイズが大きくなると、リポジトリのクローンなどの Git の操作に時間がかかります。  
たとえばブログのようなデータを管理する場合、リポジトリのサイズが大きくなる要因のひとつとして、たくさんの画像ファイルを管理することが考えられます。  
できればコミットするときに圧縮済みの画像ファイルをコミットしたいところですが、つい圧縮作業をするのを忘れてしまいます。  
そのため、Pull Request を作成した段階でファイルサイズを減らすことができるかを確認できるようにしたいと考えました。

## 関連する GitHub Actions

今回のアクションと同じように、画像ファイルを圧縮できる GitHub Actions には、[calibreapp/image-actions](https://github.com/calibreapp/image-actions) があります。  
calibreapp/image-actions は、その名のとおりオープンソースの電子書籍ビューアーである calibre を使っています。  
今回のアクションと calibreapp/image-actions との大きな違いは、次の 2 つです。

* image-actions では png 形式以外の画像ファイルにも対応している
* エラーで CI を落とすのではなく、圧縮した画像ファイルをコミットする

今回作ったアクションでは、圧縮後のファイルをコミットせずにエラーで落とすようにしました。  
なぜなら、コミットを作ってしまうとリポジトリサイズの削減には貢献しないからです。  
圧縮したファイルを含むコミットを作ると、リポジトリには圧縮前と後の 2 つのコミットが存在することになります。  
Squash してコミットをまとめれば良いのですが、CI にそこまでさせるには強力すぎではと考えました。

## Actions の使い方

### ディレクトリの画像パスを `image-paths` に指定する

GitHub Actions のステップに次のアクションを指定します。  
入力には次の 2 つの変数を設定します。

* `image-paths`：チェック対象の画像ファイルのパス
* `limit`：CI を落とす、ファイルのサイズ削減が可能な割合のしきい値  
  たとえば「90」を指定すると、元のファイルサイズの 90% よりもサイズを小さくできそうであればエラーになります。

```yaml
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: chick-p/action-png-size-lint@v0
        with:
          image-paths: |
            fixtures/**/*.png
          limit: 90
```

### 変更した画像だけをチェックする（2022年8月27日追記）

ユースケースとして変更したファイルだけチェックすることが想定されます。  
`image-paths` に指定したパスの png 画像がチェック対象になるため、ワークフロー側でファイルだけに絞り込んで `image-paths` に渡すと、変更したファイルだけをチェックできます。

```yaml:lint.yml
on:
  pull_request:
    paths:
      - "*.png"

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 100

      - name: "Diff files"
        run: |
          {
            echo 'CHANGED_FILES<<EOF'
            git diff ${{ github.event.pull_request.base.sha }} ${{ github.event.pull_request.head.sha }} --diff-filter=AM --name-only
            echo 'EOF'
          } >> "$GITHUB_ENV"

      - uses: chick-p/action-png-size-lint@v0
        with:
          image-paths: ${{ env.CHANGED_FILES }}
          limit: 90
```

## 今後実装したい機能

### 除外対象を指定できるようにする

GitHub Actions の `on.pull_request.paths-ignore` のように除外対象を指定できるようにしたいです。


png 画像のファイルサイズを節約できるかをチェックする GitHub Actions を作った

hadolint を使うと、ベストプラクティスに沿った Dockerfile かどうかをチェックできる

---
title: "hadolint で Dockerfile の構文をチェックする"
description: "hadolint を使うと、ベストプラクティスに沿った Dockerfile かどうかをチェックできる"
type: "TIL"
date: 2022-08-17
tags:
  - "Docker"
  - "hadolint"
---

Dockerfile を使った GitHub Actions の Actions を作成している。  
Dockerfile は見よう見まねで書いているので、ベストプラクティスに沿った書き方をしたい。

そんなときに利用できるのが、[hadolint](https://github.com/hadolint/hadolint) は、Dockerfile の Lint ツールである。

## hadolint をインストールする

Mac であれば homebrew を使ってインストールできる。

```bash
brew install hadolint
```

## hadolint を実行する

Dockerfile をチェックするには、Dockefile があるディレクトリで `hadolint Dockerfile` を実行するだけ。  
hadolint でチェックできる内容は、[Rules](https://github.com/hadolint/hadolint#rules) に記載されている。

たとえば、Docker イメージのバージョンで `latest` を指定した Dockerfile に対して、hadolint を実行したとする。

```docker:Dockerfile
FROM node:latest
```

すると、warning が出力される。  
`latest` を指定すると、Docker イメージがアップデートしたときに勝手にバージョンがあがってしまう。  
バグの温床になりかねないため、バージョンを指定するほうが良いとされている。

```bash
$ hadolint Dockerfile
Dockerfile:1 DL3007 warning: Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag
```

## GitHub Actions で hadolint を実行する

GitHub Actions で自動でチェックしたい場合には、[hadolint-action](https://github.com/hadolint/hadolint-action) を利用できる。  
たとえば、Pull Request で Dockerfile が変更されていたら hadolint を実行したい場合には、次のワークフローを作成する。

```yaml:hadolint.yml
name: hadolint

on:
  pull_request:
    paths:
      - "Dockerfile"

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: hadolint/hadolint-action@v2.0.0
        with:
          dockerfile: Dockerfile
```

先ほどの `latest` を指定した Dockerfile を含む Pull Request の CI は、エラーで落ちるようになる。

![画面キャプチャ：hadolint の GitHub Actions でエラーになっている](/til/docker-hadolint/github-action-result.png)


hadolint で Dockerfile の構文をチェックする

action/github-script を使うと、ワークフローのコンテキスト内で JavaScript を実行できる。

---
title: "action/github-script を使って、ワークフローのコンテキスト内で JavaScript を実行する"
description: "action/github-script を使うと、ワークフローのコンテキスト内で JavaScript を実行できる。"
type: "TIL"
date: 2022-08-16
tags:
  - "GitHub Actions"
---

[action/github-script](https://github.com/actions/github-script) は、GitHub ワークフローのコンテキスト内で GitHub API をかんたんに実行できるアクションである。  
このアクションでは Node.js の実行環境を提供しているので、シェル芸をせずに JavaScript で処理を書くことができる。

```yaml:example.yml
jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v6
        with:
          script: |
            console.log("Hello world!");
```

`actions/github-script` の前のステップで `npm install` をすれば npm パッケージを利用できる。

```yaml:example.yml
jobs:
  use-execa:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v3
        with:
          node-version: 16
      - run: npm ci
      - uses: actions/github-script@v6
        with:
          script: |
            const execa = require("execa");
            const { stdout } = await execa("echo", ["hello", "world"]);
```

リポジトリ内のファイルにアクセスするには、`${{ github.workspace }}` で始まるパスを書く。

```yaml:example.yml
jobs:
  print-stuff:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/github-script@v6
        with:
          script: |
            const json = require("${{ github.workspace }}/assets/data.json");
            console.log(JSON.stringify(json));
```


action/github-script を使って、ワークフローのコンテキスト内で JavaScript を実行する

Mac 以外の環境で png 画像を圧縮する方法を調べた。

---
title: "Mac 以外のローカル環境で png 画像を圧縮したい"
description: "Mac 以外の環境で png 画像を圧縮する方法を調べた。"
type: "TIL"
date: 2022-08-13
tags:
  - "画像圧縮"
---

Mac 上で png 画像を圧縮するときには、Mac アプリの [ImageOptim](https://imageoptim.com/mac) を使っている。  
CLI で扱うための[ImageOptim](https://github.com/JamieMason/ImageOptim-CLI)も公開されている。  
ただし、内部的には前述の `ImageOptim.app` を呼び出しているため、 Windows や Linux 上で画像圧縮するのに利用することはできない。  
ImageOptim には Web API もあるが、会社で利用するには外部サービスへのアップロードは NG なので、これも対象外となる。

調べてみると、Google が開発している [zopfli](https://github.com/google/zopfli) が圧縮率も高くてよさそうだった。  
Ref. [PNG画像のファイルサイズをなるべく小さくしたい](http://takaaki.info/2013/10/15/png-optimization/)  
zopfli は C 言語で書かれていて、自分でコンパイルして利用する。  
Node.js で扱うには、zopfli のバイナリファイルを呼び出す [zopflipng-bin](https://github.com/imagemin/zopflipng-bin) を使うのがよさそう。


Mac 以外のローカル環境で png 画像を圧縮したい

2022 July アップデートで変更になった、このコンフリクトしたときの VSCode マージエディターを前のデザインに戻す方法です。

---
title: "VSCode のマージエディターを前のエディターに戻す"
description: "2022 July アップデートで変更になった、このコンフリクトしたときの VSCode マージエディターを前のデザインに戻す方法です。"
type: "TIL"
date: 2022-08-10
tags:
  - "Visual Studio Code"
---

2022 July アップデートで、VSCode のマージエディターが変更になった。  
コンフリクトしたときに左右のプレビューで確認できて、チェックボックスで適用したい差分を取り込みできる。
前の `>>>>>HEAD` を消していくほうが慣れているので元に戻す。  

[Settings]で「mergeEditor」で検索し、「Open the merge editor for files are currently under conflict.」のチェックボックスを外す。  
または、`settings.json` に以下を追記する。

```json:settings.json
{
  // any settings
  "git.mergeEditor": false
}
```

これで元のマージエディターに戻る。

Ref. [GitHub | microsoft/vscode#156608](https://github.com/microsoft/vscode/issues/156608#issuecomment-1208700989)


VSCode のマージエディターを前のエディターに戻す

Algolia が提供する DocSearch を使うと、自作ブログにかんたんに検索機能をつけることができます。この記事では、Gatby.js 製のブログに DocSearch を導入したときにハマったポイントとその解決方法を説明します。

---
title: "Gatsby.js 製のブログで Algolia DocSearch を導入するときにハマったこと"
description: "Algolia が提供する DocSearch を使うと、自作ブログにかんたんに検索機能をつけることができます。この記事では、Gatby.js 製のブログに DocSearch を導入したときにハマったポイントとその解決方法を説明します。"
date: 2022-08-08T15:00:00+09:00
tags:
  - "Algolia"
  - "Gatsby.js"
---

## 概要

Algolia が提供する [DocSearch](https://docsearch.algolia.com/) を使うと、自作ブログにかんたんに検索機能をつけることができます。  
この記事では、Gatby.js 製のブログに DocSearch を導入したときにハマったポイントとその解決方法を説明します。

## 必要な環境

- Algolia のアカウント
- @docsearch/react v3
- Gastby.js v4

## ハマったこと1：Algolia Crawler が利用可能になるまでに時間がかかりそう

Algolia を使って検索機能を実装する場合、事前に Algolia の検索インデックスにブログのコンテンツを登録する必要があります。  
自前で登録する仕組みを用意する代わりに、[Algolia Crawler](https://www.algolia.com/products/search-and-discovery/crawler/) というサービスを利用すると、定期的にインデックスに登録できます。  
DocSearch を導入する場合、Algolia Crawler も同時に利用できますが、申請が必要であり、[チェックリスト](https://docsearch.algolia.com/docs/who-can-apply)に該当していなければなりません。

技術ブログも申し込みできる対象になっていますが、利用可能になるまでには時間がかかりそうでした。  
そのため、今回は自前で Algolia のインデックスを自前で登録することにしました。

Gatsby.js 製のブログの場合、[gastby-plugin-aloglia](https://www.gatsbyjs.com/plugins/gatsby-plugin-algolia/) を導入すると、登録処理の部分を実装する必要がなさそうだったため、これを使うことにしました。  
`gatsby-config.js` を使うとサイトのビルド時にサイト内の情報を Algolia のインデックスに自動で登録するようになります。

導入はかんたんで、npm でインストールした後に `gatsby-config.js` に設定を追記します。  
Algolia の環境設定は、環境変数から読み込むようにします。  
このブログは Netlify でホスティングしているため、忘れずに Netlify の環境設定にも設定します。

`queries` の部分では、登録対象となる記事のコンテンツを抽出するクエリを指定します。  
また、`transformer` で、抽出したコンテンツを Algolia のインデックスへ登録するプロパティの形式に変換します。  

```js:gatsby-config.js
module.exports = {
  // ...,
  plugins: [
    {
      resolve: `gatsby-plugin-algolia`,
      options: {
        appId: process.env.GATSBY_ALGOLIA_APP_ID,
        apiKey: process.env.ALGOLIA_API_KEY,
        indexName: process.env.GATSBY_ALGOLIA_INDEX_NAME,
        queries: [
          {
            query: `{
              allMdx {
                edges {
                  node {
                    excerpt
                    fields {
                      slug
                    }
                    frontmatter {
                      title
                      date(formatString: "YYYY-MM-DD")
                      tags
                    }
                  }
                }
              }
            }`,
            transformer: ({ data }) =>
              data.allMdx.edges.flatMap(({ node }) => {
                return {
                  id: node.fields.slug,
                  content: node.excerpt,
                  title: node.frontmatter.title,
                  publishedAt: new Date(node.frontmatter.date),
                  tags: node.frontmatter.tags,
                }
              }),
          },
        ],
        chunkSize: 10000,
      },
    },
  ],
  // ...
}
```


あとは[Getting Started](https://docsearch.algolia.com/docs/DocSearch-v3) を参考に、ヘッダーを表示するコンポーネントに DocSearch の検索窓のコンポーネントを設置すれば、検索ボックスが表示されます。

## ハマったこと 2：`“Uncaught (in promise) TypeError: Cannot read property ‘lvl0’ of undefined”` が表示される

サイトをビルドし直して検索してみたところ、開発者ツールのコンソールに次のようなエラーが表示されてしまいました。

```bash
“Uncaught (in promise) TypeError: Cannot read property ‘lvl0’ of undefined”
```

どうやら DocSearch で検索するにはインデックスの属性に `hierarchy` というプロパティが必要で、Algolia Crawler はこのプロパティを自動で登録しているようでした。  
そのため、gastby-plugin-algolia のインデックスへ登録するプロパティの形式に変換する箇所で、`hierarchy` プロパティが登録されるようにします。

`hierarchy` プロパティの属性には、`lvl0` から `lvl6` まで指定できます。  
Ref. [recordProps API Reference](https://docsearch.algolia.com/docs/record-extractor/#recordprops-api-reference)

この数字はドキュメントの階層構造にしたがっているため、今回は `lvl0` と `lvl1` に記事のカテゴリーと記事のタイトルを渡すようにしました。  
このブログのカテゴリは今のところ「Blog」固定なので、`lvl0` は固定値としています。

```diff:gatsby-config.js
            transformer: ({ data }) =>
              data.allMdx.edges.flatMap(({ node }) => {
                return {
                  id: node.fields.slug,
                  // ...
+                  hierarchy: {
+                    lvl0: "Blog",
+                    lvl1: node.frontmatter.title
+                  },
                }
              }),
          },
```

Algolia のインデックスが生成し直した後にもう一度検索し直してみると、「Uncaught 〜」エラーは消えて検索結果が表示されるようになりました。

## ハマったこと 3：検索結果の一覧に「#」だけが表示されてしまう

検索結果は表示されるようになったものの、一覧には「#」だけが表示されています。

![画面キャプチャ：検索結果に「#」だけが表示されている](gatsby-docsearch/invalid-search-result.png)

調べたところ、インデックスに `type` というプロパティでどの値を一覧のタイトル部分表示するかを指定する必要があるようでした。  
そのため、gastby-plugin-algolia のインデックスへ登録するプロパティの形式に変換する箇所で、`type` プロパティが登録されるようにします。  
今回は記事タイトルを表示したいため、記事タイトルである `lvl1` を指定します。

```diff:gatsby-config.js
            transformer: ({ data }) =>
              data.allMdx.edges.flatMap(({ node }) => {
                return {
                  id: node.fields.slug,
                  // ...
                  hierarchy: {
                    lvl0: "Blog",
                    lvl1: node.frontmatter.title
                  },
+                  type: "lvl1",
                }
              }),
          },
```

もう一度サイトをビルドしてインデックスを登録し直すと、ぶじ検索結果の一覧に記事タイトルが表示されるようになりました。

![画面キャプチャ：検索結果に記事タイトルが表示されている](gatsby-docsearch/valid-search-result.png)

## ハマったこと 4：検索結果の一覧をクリックしても、目的のページに遷移しない

検索一覧が表示されるようになったものの、一覧をクリックしても目的のページに遷移しません。  
この原因は、`url` というプロパティがインデックスにないためでした。  
そのため、これまでと同様に gastby-plugin-algolia の設定で `url` プロパティが登録されるようにします。  

```diff:gatsby-config.js
            transformer: ({ data }) =>
              data.allMdx.edges.flatMap(({ node }) => {
                return {
                  id: node.fields.slug,
                  // ...
                  hierarchy: {
                    lvl0: "Blog",
                    lvl1: node.frontmatter.title
                  },
                  type: "lvl1",
+                  url: `${baseUrl}${node.fields.slug}`
                }
              }),
          },
```

これで、検索結果から見たいページに遷移できるようになりました。

## まとめ

格好いい検索機能を自ブログに導入できたぞ！


Gatsby.js 製のブログで Algolia DocSearch を導入するときにハマったこと

Jest のカバレッジレポートを GitHub Job Summary へ表示する方法を説明します。

---
title: "GitHub Actions Job Summaries で Jest のカバレッジレポートを表示する"
description: "Jest のカバレッジレポートを GitHub Job Summary へ表示する方法を説明します。"
date: "2022-05-11"
tags:
  - "GitHub Actions"
  - "Jest"
---

## 概要

2022年5月9日に GitHub Actions Job Summaries がリリースされました。  
GitHub Actions Job Summaries は、GitHub Actions のワークフロー内で `$GITHUB_STEP_SUMMARY` という環境変数に Markdown 形式の文字列を設定すると、ジョブのサマリーとして表示される機能です。  
[Supercharging GitHub Actions with Job Summaries](https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/)

この記事では、Jest のカバレッジレポートを GitHub Job Summary へ表示する方法を説明します。  
![スクリーンショット：ジョブサマリーとしてカバレッジレポートが表示されている](/github-actions-job-summary/job-summary.png)

## 確認した環境

- Yarn
- Jest v28.1.0

## 前提

テスト対象として、Jest の [Getting started](https://archive.jestjs.io/docs/ja/24.x/getting-started) で説明している、`sum.test.js` を使います。

## STEP1：カバレッジを表示するコマンドを追加する

カバレッジレポートを出力するコマンドをnpm-scripts に追加します。

```diff:package.json
    "scripts": {
+     "coverage": "jest --coverage"
    },
```

`yarn coverage` を実行すると、標準出力にカバレッジが出力されます。

```bash
yarn run v1.22.17
$ jest --coverage
 PASS  ./sum.test.js
  ✓ adds 1 + 2 to equal 3 (2 ms)

----------|---------|----------|---------|---------|-------------------
File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s
----------|---------|----------|---------|---------|-------------------
All files |     100 |      100 |     100 |     100 |
 sum.js   |     100 |      100 |     100 |     100 |
----------|---------|----------|---------|---------|-------------------
Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        0.51 s, estimated 1 s
Ran all test suites.
✨  Done in 2.39s.
```

## STEP2：カバレッジレポートをファイルに出力する設定を追加する

カバレッジレポートがファイルに出力されるように、Jest の設定を追加します。  
ここでは例として、`package.json` に設定します。

```diff:package.json
  {
    "name": "practice-jest",
+    "jest": {
+      "coverageReporters": [
+        [
+          "text", { "file": "report.txt" }
+        ]
+      ]
+    },
```

`yarn coverage` を実行すると、`coverage/report.txt` に、次の内容でファイルが出力されます。

```plaintext
----------|---------|----------|---------|---------|-------------------
File      | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
----------|---------|----------|---------|---------|-------------------
All files |     100 |      100 |     100 |     100 |                   
 sum.js   |     100 |      100 |     100 |     100 |                   
----------|---------|----------|---------|---------|-------------------
```

このファイルの内容を`$GITHUB_STEP_SUMMARY` に渡せばよさそうです。  
ただし、GitHub Flavored Markdown では、ファイルの先頭行と末尾行の罫線は不要なので、消す必要があります。


## STEP3：GitHub Actions のワークフローを設定する

`yarn coverage` を実行し、出力されたカバレッジレポートの内容を `$GITHUB_STEP_SUMMARY` に渡すワークフローを作成します。  
ワークフローを実行するタイミングは、master へプッシュしたときと、Pull Request を作成したときとします。

```yml:.github/workflows/test.yml
name: test
on:
  push:
    branches:
      - main
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Use Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '14.x'
        cache: 'yarn'

    - name: coverage
      run: |
        yarn install
        yarn coverage
        echo '# Coverage :rocket:' >> $GITHUB_STEP_SUMMARY
        # sed で先頭行と末尾行の不要な罫線を消す
        cat coverage/report.txt | sed '1d' | sed '$d' >> $GITHUB_STEP_SUMMARY
```

## STEP4：動作を確認する

これまでの内容を GitHub にプッシュして、Pull Request を作成します。  
GitHub Actions でワークフローが実行されます。  
ワークフローのジョブが完了すると、Actions の詳細画面にジョブサマリーが表示されます。

![スクリーンショット：GitHub Actions のジョブサマリーが枠線で強調されている](/github-actions-job-summary/actions-result.png)

## まとめ

GitHub Actions Job Summaries 便利！  
Actions を作るときにも役立ちそうです。


GitHub Actions Job Summaries で Jest のカバレッジレポートを表示する

GitHub Actions で configure-aws-credentials を利用するときに、AWS OIDC プロバイダーを使って認証情報を設定する手順を説明する。

---
title: "AWS OIDC プロバイダーを使って GitHub Actions で AWS CLI を実行する"
description: "GitHub Actions で configure-aws-credentials を利用するときに、AWS OIDC プロバイダーを使って認証情報を設定する手順を説明する。"
date: "2022-04-16"
tags:
  - "AWS OIDC"
  - "GitHub Actions"
---

GitHub Actions で AWS CLI を実行する場合、[configure-aws-credentials](https://github.com/aws-actions/configure-aws-credentials) を使うと、安全に AWS の認証情報をセットアップできる。  
このとき、AWS の認証情報であるアクセスキー ID とシークレットアクセスキーを設定する方法には、次の 2 つがある。

- GitHub の設定で、Secrets の環境変数に設定する
- AWS OIDC プロバイダーを使う

この記事では、後者の AWS OIDC プロバイダーを使う手順を説明する。  
AWS OIDC プロバイダーを使うと、AWS OIDC プロバイダーがワークフローを実行するたびに、必要なシークレットアクセスキーが発行される。  
そのため、GitHub Actions 用の認証情報を管理する手間がなくなる。

## AWS OIDC プロバイダーを使って GitHub Actions で AWS CLI を実行する

AWS OIDC プロバイダーを使って GitHub Actions で AWS CLI を実行する手順を説明する。  
今回は、S3 の一覧を取得するコマンド `aws s3 ls` を実行し、バケット一覧を出力することをゴールとする。

### STEP0：テスト用のリポジトリを作成する

GitHub にテスト用のリポジトリを作る。ひとまず中身は空にする。  
デフォルトのブランチ名は何でも良いが、ここでは `main` にする。

### STEP1：OIDC プロバイダーを作成する

1. AWS IAM を開く
2. 左メニューから[ID プロバイダ]を選択する
3. [ID プロバイダを追加]をクリックする
4. 次の内容を入力する
   - **プロバイダのタイプ** - OpenID Connect
   - **プロバイダの URL** - `https://token.actions.githubusercontent.com`
   - **対象者** - `sts.amazonaws.com`
5. プロバイダの URLの[サムプリントを取得]をクリックする

### STEP3：IAM ロールを作成する

 GitHub Actions で S3 コマンドを実行するための IAM ロールを作成する。

1. 左メニューから[IAM ロール]を選択する
1. 「信頼されたエンティティタイプ」に「カスタム信頼ポリシー」を選択する
1. ロールの信頼関係のポリシーに、次の内容を入力する。

    ```json
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "arn:aws:iam::AWS_ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
          },
          "Action": "sts:AssumeRoleWithWebIdentity",
          "Condition": {
            "StringEquals": {
              "token.actions.githubusercontent.com:sub": "repo:GITHUB_USERNAME/GITHUB_REPOSITORY_NAME:ref:refs/heads/main"
            }
          }
        }
      ]
    }
    ```

    次の変数は、自分の環境に合わせて置き換える。
      - `AWS_ACCOUNT_ID` - AWS のアカウント ID  
        GitHub Secrets でも設定するので、メモに控えておく。  
        ヘッダーの自分のアカウント名横の[▼]をクリックすると、アカウント IDを確認できる。  
        ![スクリーンショット：AWS アカウントID が枠線で強調されている](/github-actions-by-aws-oidc/accountid.png)
      - `GITHUB_USERNAME` - GitHub のユーザー名
      - `GITHUB_REPOSITORY_NAME` - GitHub のテストリポジトリ名

    `token.actions.githubusercontent.com:sub`  に設定した値で、どのリポジトリのどのブランチから呼び出すかを定義している。

1. 「許可ポリシー」に、実行する AWS コマンドに合わせた許可ポリシーを設定する。  
  今回は、`aws s3 ls` を実行するために必要な許可ポリシーにする。

1. 「ロール名」を入力する。  
  このロール名は、GitHub Workflow で使用するので、メモに控えておく。

### STEP4：GitHub Secrets を設定する

GitHub リポジトリの設定で、次の値を Secrets に設定する

- `AWS_ACCOUNT_ID` - AWS のアカウント ID
- `AWS_IAM_ROLE_NAME` - STEP3 で作成した IAM ロール名

### STEP5：テスト用のリポジトリに GitHub Workflow を作成する

1. 次の中身で、GitHub Action ワークフローを作成する。

    ```yml:.github/workflows/test.yml
    name: OIDC TEST
    on: push

    permissions:
      id-token: write
      contents: read

    jobs:
      deploy:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v2
          - uses: aws-actions/configure-aws-credentials@v1
            with:
              role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/${{ secrets.AWS_IAM_ROLE_NAME  }}
              aws-region: ap-northeast-1
          - run: |
              aws s3 ls
    ```

1. GitHub Action ワークフローファイルをコミットする

### STEP6：動作確認

1. STEP5 で作ったコミットをプッシュする
1. GitHub Actions を開き、実行結果を確認する。  
   `aws s3 ls` の実行結果として、S3 のバケット一覧が表示されていれば良い。  
   ![スクリーンショット：GitHub Actions の実行結果。S3 のバケット一覧が表示されている](/github-actions-by-aws-oidc/s3.png)

## 補足：Serverless Framework を使うとき

Serverless Framework を使う場合にも、default プロファイルとして設定されるので、いい感じに AWS の認証情報が設定される。  
なので GitHub Actions では AWS のコマンドの代わりに Serverless Framework のコマンド `sls deploy` を実行すれば良い。  

```yaml
      - run: |
          npm ci
          npx sls deploy
```


AWS OIDC プロバイダーを使って GitHub Actions で AWS CLI を実行する

v0.93.0 で追加された Code Block Render Hooks を使って、コードブロックにファイル名を表示する方法を説明します。

---
title: "HUGO の Code Block Render Hooks を使って、コードブロックにファイル名を表示する"
description: "v0.93.0 で追加された Code Block Render Hooks を使って、コードブロックにファイル名を表示する方法を説明します。"
date: 2022-03-13T20:00:00+09:00
tags:
  - HUGO
---

Markdown のコードブロックに記述したコードを、「foo.js」のようにファイル名をつけて表示できるようにします。  
![スクリーンショット:ファイル名付きで表示したコードブロックの例](/hugo-render-hooks-code/sample.png)

この記事では、v0.93.0 で追加された Code Block Render Hooks を使います。  
Code Block Render Hooks が追加されるまでは、下記のページで紹介されているように、ショートコードを実装する必要がありました。  
[ソースコードをハイライト表示する (highlight)](https://maku77.github.io/hugo/shortcode/highlight.html)

Code Block Render Hooks を使うと、Markdown Syntax のコードブロックのまま、ファイル名を表示できるようになります。  
この場合、ショートコードを使うときとは異なり、JavaScript のコードであれば [eslint-plugin-markdown](https://www.npmjs.com/package/eslint-plugin-markdown) を使って ESLint を適用できます。

## 環境

HUGO v0.93.0

## Code Block Render Hooks とは

コードブロック用の Render Hooks は、`layouts > _default > _markup` の下に、`render-codeblock.html` を作成します。  
参考. [公式ドキュメント](https://gohugo.io/templates/render-hooks/)

```plaintext:ファイルの位置
layouts
└── _default
    └── _markup
        └── render-codeblock.html
        └── render-codeblock-bash.html
```

表示する言語ごとに、Code Block Render Hooks テンプレートを出し分けることもできます。  
`render-codeblock-` のプレフィックスと言語の識別子をファイルの名前につけます。  
言語の識別子とは、````js` のようにバッククォート3つの後に付ける言語名のことです。

HUGO のドキュメントには、[mermaid を使って図を表示する例](https://gohugo.io/content-management/diagrams/)が紹介されています。

## ファイル名を表示する Code Block Render Hooks を実装する

コンテンツのファイルに、次のようにコードブロックを記述することを考えます。  
表示するファイル名は、言語の識別子の後に `{name="ファイル名"}` のように記載します。

````markdown:Markdownの例
```js {name="foo.js"}
(() => {
  'use strict';
  console.log("Hello World!");
})();
```
````

Code Block Render Hooks として、`render-codeblock.html` に次の内容を記載します。

````html:render-codeblock.html
<div>
  {{- $name := .Attributes.name -}}
  {{ with $name }}<div class="codeblock--name">{{ . }}</div>{{ end }}
  <div class="codeblock--content">
    {{- highlight (.Inner | safeHTML) .Type .Options }}
  </div>
</div>
````

`{}` 内で渡したファイル名は、`.Attributes` で受け取ります。  
コードブロック内の内容は `.Inner` で受け取ることができるため、[highlight 関数](https://gohugo.io/functions/highlight/#readout)でハイライト表示します。

HUGO でハイライト表示するときに `{}` 内へ指定できる、行番号の開始数などのオプションは、`.Options` に格納されます。  
highlight 関数の第 3 引数として `.Options` を渡すと、同じように行番号の開始数などを指定できます。  
行番号の開始数などのオプションの詳細は、[Highlighting in Code Fences](https://gohugo.io/content-management/syntax-highlighting/#highlighting-in-code-fences) を参照してください。

例えば、次のように行番号を変更したり、行をハイライト表示するオプションを指定して Markdown を書いたとします。

````markdown:Markdownの例
```js {linenos=table,hl_lines=["2-3"],linenostart=199,name="foo.js"}
(() => {
  'use strict';
  console.log("Hello");
})();
```
````

前述の`render-codeblock.html` では `highlight 関数に `.Options` を渡しているため、指定したオプションが反映されています。

![スクリーンショット:行番号の開始や行のハイライトを指定したときの例](/hugo-render-hooks-code/sample2.png)

ちなみに、今回のファイル名の表示部分には、次のような css を適用しています。

```css
.codeblock--name {
  width: fit-content;
  margin: 1rem 0 0;
  padding: 0.4rem;
  font-size: 0.9rem;
  color: rgb(255, 255, 255);
  background-color: #05acc1;
}

.codeblock--name + .codeblock--content {
  margin-top: 0;
}
```


HUGO の Code Block Render Hooks を使って、コードブロックにファイル名を表示する

ヘッドレス CMS である Contentful で記事を管理する Next.js 製のブログを作り、Vercel でホスティングする方法を説明します。

---
title: "Contentful + Next.js + Vercel でブログを作る"
description: "ヘッドレス CMS である Contentful で記事を管理する Next.js 製のブログを作り、Vercel でホスティングする方法を説明します。"
date: "2022-01-08"
tags:
  - "Contentful"
  - "Next.js"
  - "Vercel"
---


## 概要

[Next.js で Markdown ブログを作る](/next-js-blog/)では、記事を Markdown ファイルで作成したブログを作りました。  
この記事では、ヘッドレス CMS である [Contentful](https://www.contentful.com/) で記事を管理する Next.js 製のブログを作り、Vercel でホスティングする方法を説明します。

## Contentful とは

Contentfulは、ヘッドレス CMS とよばれる API ベースな CMS です。  
ヘッドレス CMS なので、Wordpress などの一般的な CMS のようにフロントエンドの部分がありません。  
そのため、Next.js や Gatsby のようなクライアント側をレンダリングするフレームワークと組み合わせて使います。

Contentful では、データの置き場（サイト）となる Space の中で、記事データ（Entity）を管理します。  
記事データは、Content Model と呼ばれる、タイトル、本文、日付などどんな項目で構成するか？というひな形の定義を元に作られます。

## Contentful + Next.js + Vercel なブログを作る流れ

ブログを構築する流れは次のとおりです。

- Contentful で記事データのひな形を作り、デモデータ用の記事を作る
  - Space を作る
  - API キーを発行する
  - Content Model を定義する
  - 記事を作成する
- Next.js アプリを作る
  - Next.js のひな形を作る
  - Contentful の API を実行するための準備をする
  - トップページ（記事一覧）を作る
  - 個別ページを作る
- GitHub に Next.js アプリをコミットし、 Vercel にデプロイする
- Contentful 側で記事が更新されたときに自動でビルドされるように設定する
  - Vercel で Webhook URL を発行する
  - Contentful に Webhook を追加する
  - 動作を確認する

## Contentful で記事データのひな形を作り、デモデータ用の記事を作る

### Space を作る

Contentful でアカウントを作ったら、Space を作成します。  
アカウントを作成した時点でスペースが作られているので、今回はこれを使用します。  
Space は、使用量に応じた「Medium」「Large」の 2 種類のサイズがありますが、無料枠では、「Medium」なスペースをひとつ利用できます。

Space ID は、[Settings] から [General settings]を選択した後の画面で確認できます。

### API キーを発行する

Next.js アプリから Contentful で管理している記事データを取得するために、API キーを発行します。

1. ヘッダーの「Settings」を選択し、「API Keys」を選択します。
1. [Add API Key]をクリックします。
1. 「Access API token」画面で、発行する API キーに名前（任意）をつけます。  
  ![画面例](/contentful-nextjs-blog/add-api-key.png)
1. [Save]をクリックします。
1. 次の値を控えておきます。
    - Space ID
    - Content Delivery API

### Content Model を定義する

タイトル、本文、日付などどんな項目で構成するか？というデータ構造を決める、Content Model を作ります。  
今回は、タイトル、本文、slug を持つ Content Model を作ります。

1. ヘッダーの「Content Model」を選択します。
1. [Add content type]をクリックします。
1. 「Create new content type」画面で、Content Model の名前を入力します。  
  今回は次のように入力しました。「Api Identifier」は、Next.js アプリで指定する「Content Type ID」に相当する値なので、控えておきます。
    - Name: post
    - Api Identifier: post

    ![画面例](/contentful-nextjs-blog/content-model-name.png)

1. フィールドを追加し、データ構造を定義します。

    | Name | Field ID | Field | 説明 |
    | :-- | :-- | :-- | :-- |
    | title | title | Text(short text)   | タイトル |
    | slug | slug | Text(short text) | URL パス |
    | content | content | Text(Rich text)  | 本文 |

    ![画面例](/contentful-nextjs-blog/content-model-field.png)

1. [Save]をクリックします。

### 記事を作成する

Content Model を作成し、記事のひな形ができたので記事を追加します。

1. ヘッダーの「Content」を選択します。
1. [Add post] をクリックします。Content Type を選ぶ場合は、「post」を選びます。
1. デモデータとしての記事の内容を入力します。
1. [Publish] をクリックし、記事を公開状態にします。

## Next.js アプリを作る

### Next.js のひな形を作る

Contentful で管理している記事を表示するための、Next.js アプリを作ります。
Next.js アプリを作る流れは、以前書いた[Next.js で Markdown ブログを作る](/next-js-blog/)をベースにします。

```bash
# Next.js アプリのひな形を作成する
$ yarn create next-app practice-nextjs-blog-contentful --typescript
$ cd practice-nextjs-blog-contentful

## ソースコードを src に移動する
$ mkdir src
$ mv pages src/ && mv styles src/
```

### Contentful の API を実行するための準備をする

Contentful とやり取りするための [npm パッケージ](https://www.npmjs.com/package/contentful)が公開されているので、インストールします。

```bash
yarn add contentful
```

Contentful の API を実行するためのクライアントを生成する関数と、型定義を `src/lib/contentful.ts` に作ります。  
`contentType.sys.id` には、Content Model を作るときに入力した「Api Identifier」の値（今回は、`post`）を指定します。

```typescript:src/lib/contentful.ts
import { createClient } from "contentful";

import { Entry } from "contentful";
import { Document } from "@contentful/rich-text-types";

export interface IPostFields {
  title: string;
  slug: string;
  content: Document;
}

export interface IPost extends Entry<IPostFields> {
  sys: {
    id: string;
    type: string;
    createdAt: string;
    updatedAt: string;
    locale: string;
    contentType: {
      sys: {
        id: "post";
        linkType: "ContentType";
        type: "Link";
      };
    };
  };
}

export const buildClient = () => {
  const client = createClient({
    space: process.env.CF_SPACE_ID || "",
    accessToken: process.env.CF_ACCESS_TOKEN || "",
  });
  return client;
};
```

環境変数として与える `CF_SPACE_ID` と `CF_ACCESS_TOKEN` を、`.env.local` ファイルに定義します。  
API キーを発行する時に確認したときの Space ID が「CF_SPACE_ID」、Content Delivery API が、「CF_ACCESS_TOKEN」です。

```bash
$ touch .env.local
```

```bash:".env.local"
CF_SPACE_ID=スペースID
CF_ACCESS_TOKEN=APIキー
```

### トップページ（記事一覧）を作る

トップページには、記事の一覧を箇条書きで表示してみましょう。

次の内容で、`src/pages/index.tsx` を追加します。  
12 行目の「content_type」には、「Api Identifier」の値（今回は、`post`）を指定します。

```typescript:src/pages/index.tsx
import type { NextPage, GetStaticProps, InferGetStaticPropsType } from "next";
import Head from "next/head";
import styles from "../styles/Home.module.css";
import { buildClient, IPostFields } from "../lib/contentful";
import Link from "next/link";
import { Entry, EntryCollection } from "contentful";

const client = buildClient();

export const getStaticProps: GetStaticProps = async () => {
  const { items }: EntryCollection<IPostFields> = await client.getEntries({
    content_type: "post",
    order: "-sys.createdAt",
  });
  return {
    props: { posts: items },
  };
};

type Props = InferGetStaticPropsType<typeof getStaticProps>;

const Home: NextPage<Props> = ({ posts }) => {
  return (
    <div className={styles.container}>
      <Head>
        <title>Create Next App</title>
        <meta name="description" content="Generated by create next app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <main className={styles.main}>
        <h1 className={styles.title}>Contentful with Next.js</h1>
        <div>
          <ul>
            {posts &&
              posts.map((post: Entry<IPostFields>) => (
                <li key={post.sys.id}>
                  <Link href={post.fields.slug}>
                    <a>
                      <h2>{post.fields.title}</h2>
                    </a>
                  </Link>
                </li>
              ))}
          </ul>
        </div>
      </main>
    </div>
  );
};

export default Home;
```

`getStaticProps()` でContenful API を実行して `props` にその内容を渡します。
このとき、Contentful API で Entry（記事の実体）を取得しています。  
「content_type」に「Api Identifier」の値（今回は、`post`）を指定します。

ローカルでプレビューして、記事の一覧が表示されることを確認します。

```bash
$ yarn dev
# http://localhost:3000/ にアクセスする
```

![画面例](/contentful-nextjs-blog/preview-top.png)

### 個別ページを作る

記事ごとのページを作ります。
今回は本文に Rich text を使うので、装飾がレンダリングされるように「@contentful/rich-text-react-renderer」をインストールします。

```bash
yarn add @contentful/rich-text-react-renderer
```

次の内容で、`src/pages/[slug].tsx` を追加します。  
14 行目の「content_type」には、「Api Identifier」の値（今回は、`post`）を指定します。

```typescript:src/pages/[slug].tsx
import type { NextPage, InferGetStaticPropsType, GetStaticPaths } from "next";
import Head from "next/head";
import { useRouter } from "next/router";
import ErrorPage from "next/error";
import styles from "../styles/Home.module.css";
import { buildClient, IPostFields } from "../lib/contentful";
import { EntryCollection } from "contentful";
import { documentToReactComponents } from "@contentful/rich-text-react-renderer";

const client = buildClient();

const getPostEntries = async () => {
  const { items }: EntryCollection<IPostFields> = await client.getEntries({
    content_type: "post",
  });
  return items;
};

export const getStaticPaths: GetStaticPaths = async () => {
  const items = await getPostEntries();
  const paths = items.map((item) => {
    return {
      params: { slug: item.fields.slug },
    };
  });
  return {
    paths,
    fallback: false,
  };
};

export const getStaticProps = async () => {
  const items = await getPostEntries();
  return {
    props: {
      posts: items,
    },
  };
};

type Props = InferGetStaticPropsType<typeof getStaticProps>;

const Post: NextPage<Props> = ({ posts }) => {
  const router = useRouter();
  if (!router.isFallback && !posts[0].fields.slug) {
    return <ErrorPage statusCode={404} />;
  }
  const post = posts[0];
  return (
    <div className={styles.container}>
      <Head>
        <title>{post.fields.title}</title>
      </Head>
      <main>
        <h1>{post.fields.title}</h1>
        <div>{documentToReactComponents(post.fields.content)}</div>
      </main>
    </div>
  );
};

export default Post;
```

`getStaticPaths()` で、記事のルーティングパスを生成し、`getStaticProps()` で記事の内容を取得します。
それぞれの関数では、Contenful API で記事を取得している `getPostEntries()` を呼び出しています。

ローカルでプレビューして、記事の内容が表示されることを確認します。

```bash
$ yarn dev
# http://localhost:3000/test/ にアクセスする
```

![画面例](/contentful-nextjs-blog/preview-post.png)

## GitHub に Next.js アプリをコミットし、 Vercel にデプロイする

ここまでの内容を GitHub のリポジトリにコミットしておきます。  
次に、Vercel と GitHub のリポジトリを連携した Project を作成し、Next.js のアプリをホスティングします。

1. Vercel にログインします。
1. 「Import Git Repository」からリポジトリを選択します。  
  ![画面例](/contentful-nextjs-blog/vercel-import.png)
1. 「Configure Project」画面で、プロジェクト名と環境変数（「Enviroment Variables」）を設定します。  
  「Enviroment Variables」には、Contentful の Space ID と API キーを設定します。
    - `CF_SPACE_ID`: Space ID
    - `CF_ACCESS_TOKEN`: Content Delivery API

    ![画面例](/contentful-nextjs-blog/vercel-setting.png)

1. [Deploy] をクリックします。

ビルドとホスティングが開始され、しばらくすると URL が発行されます。  
URL をクリックし、ローカルプレビューしたときと同じようにトップページに記事の一覧が表示されたり、記事の内容ページが表示されたりすることを確認します。

## Contentful 側で記事が更新されたときに自動でビルドされるように設定する

このままでは、Vercel を連携した時点の記事しか表示されません。  
Contentful で記事を追加、編集、削除したタイミングでビルドして、HTML が生成されるようにします。  
Contentful で記事を変更するなどの操作をしたときに、Vercel の Webhook を発火させビルドが実行されるようにします。

### Vercel で Webhook URL を発行する

1. Vercel で、作成した Project を開きます。
1. 「Settings」タブを選択します。
1. 左メニューの「Git」を選択し、「Deploy Hooks」で Webhook URL を作成します。  
  Webhook の名前（任意、ここでは「post」）とブランチ名（ここでは「main」）を入力します。
    ![画面例](/contentful-nextjs-blog/vercel-create-webhook.png)
1. [Create Hook]をクリックします。
1. 発行された Webhook URL を控えておきます。  
    ![画面例](/contentful-nextjs-blog/vercel-webhook-url.png)

### Contentful に Webhook を追加する

1. ヘッダーの「Settings」を選択し、「Webhooks」を選択します。
1. [Add Webhook]をクリックします。
1. 「Webhook: Unnamed」画面で、Webhook の設定をします。
    - URL: 「POST」を選択し、Vercel で発行した URL を入力します。  
      ![画面例](/contentful-nextjs-blog/contentful-webhook-url.png)
    - Trigger: 記事に更新があったときにビルドするようにするため、「Entity」のチェックボックスをすべて選択します。
      ![画面例](/contentful-nextjs-blog/contentful-webhook-trigger.png)
1. [Save] をクリックします。

## 動作を確認する

Contetful でコンテンツを追加し、Vercel でビルドが実行されれば OK です。  
Vercel のビルド状態は、「Deployments」で確認できます。  
![画面例](/contentful-nextjs-blog/vercel-deployments.png)

## まとめ

ヘッドレス CMS を使ってブログを作るときの流れを勉強してみたかったので、Contentful + Next.js + Vercel の構成でブログを作ってみました。  
どんなヘッドレス CMS を使う場合でも、次のような流れになるかと理解しています。
- 記事を生成するときに ヘッドレス CMS の API を実行して、記事の情報を取得する
- 記事を変更したときに、ホスティングしているサービスのビルド用のWebhook を実行する


Contentful + Next.js + Vercel でブログを作る

Next.js + TypeScript で Markdown ブログを作る方法を説明します。

---
title: "Next.js + TypeScript で Markdown ブログを作る"
description: "Next.js + TypeScript で Markdown ブログを作る方法を説明します。"
date: "2021-12-28T10:23:00+0900"
tags:
  - "TypeScript"
  - "Next.js"
---


## 概要

React ベースのフレームワークには、Gatsby.js と Next.js があります。  
このブログは Gatsby.js で実装していますが、Next.js を勉強してみたかったので、Markdown ブログを作ってみることで Next.js を学習することにしました。

この記事では、次のようなファイル構成のブログを作ります。

- `content` ディレクトリ以下に Markdown ファイルを配置する
  ```bash
  content
  ├── hello-world/
  │   └── index.md # 記事ファイル
  ├── hello-nextjs/
  │   └── index.md # 記事ファイル
  ````
- URL を記事のファイル名とする  
  たとえば、上記のファイル構成の場合、`https://example.com/hello-world` が記事の URL です。

## Next.js とは

[Next.js](https://nextjs.org) は、React をベースとしたフロントエンドフレームワークです。
サーバーサイドレンダリング（SSR）と静的サイトジェネレーター（SSG）をサポートしています。

## 環境

- Node.js v16.13.1
- Yarn v1.22.17
- Next,js v12.0.7

## TypeScript でNext.js のひな形を作る

`yarn create next-app` で、Next.js アプリのひな形を作ります。

```bash
$ yarn create next-app practice-nextjs-blog --typescript
$ cd practice-nextjs-blog
$ yarn dev
```
`http://localhost:3000` にアクセスすると、スタートページが表示されます。  
![最初の画面例](/next-js-blog/yarn-dev.png)

この時点でのファイル構成は、次のとおりです。

```bash
$ tree
.
├── README.md
├── next-env.d.ts
├── next.config.js # Next.js の設定ファイル
├── node_modules/
├── package.json
├── pages/ # Nextjs でルーティングされるページのコンポーネントを配置する
│   ├── _app.tsx # ルートのコンポーネント
│   ├── api/
│   │   └── hello.ts
│   └── index.tsx # トップページのコンポーネント
├── public/ # 静的ファイルを配置する
│   ├── favicon.ico
│   └── vercel.svg
├── styles/ # css を配置する
│   ├── Home.module.css
│   └── globals.css
├── tsconfig.json
└── yarn.lock
```


## Prettier を導入する

ESLint はひな形の時点で設定されているので、Prettier を導入します。  
Ref. https://nextjs.org/docs/basic-features/eslint

```bash
$ yarn add -D prettier eslint-config-prettier
```

`.eslintrc.json` を開き、`extends` に `prettier` を追加します。

```diff:.eslintrc.json
{
-  "extends": "next/core-web-vitals"
+  "extends": ["next/core-web-vitals",  "prettier"]
}
```

## src ディレクトリに JS ファイルを移動する

Next.js は `src` ディレクトリに対応しているので、`pages` と `styles` を `src` ディレクトリの下に移動します。

```bash
$ mkdir src
$ mv pages src/
$ mv styles src/
```

## 記事ファイルを作成する

`content` ディレクトリ以下に、記事ファイルを作成します。

```bash
$ mkdir -p content/hello-world
$ touch content/hello-world/index.md
$ touch content/hello-nextjs/index.md
```

それぞれ `index.md` の内容を次のようにします。

```markdown:content/hello-world/index.md
---
title: "Hello World!"
date: "2021/12/27"
---

## 見出し

本文
```


```markdown:content/hello-nextjs/index.md
---
title: "Hello Next.js!"
date: "2021/12/28"
---

## 見出し

本文
```

## Markdown ファイルを解析するパッケージを導入する

[公式が提供しているサンプル](https://github.com/vercel/next.js/tree/canary/examples/blog-starter)を参考に、Markdown ファイルを HTML に変換するためのパッケージを導入します。

```bash
$ yarn add remark remark-html gray-matter
```

「remark」と「remark-html」は、Markdown を解析して HTML に変換するパッケージで、「gray-matter」は Frontmatter の YAML を解析するパッケージです。

## .md ファイルを読み込む

`src/lib/api.ts` に、`content` 以下の Markdown ファイルを読み込むための関数を実装します。

```typescript:src/lib/api.ts
import fs from "fs";
import path from "path";
import matter from "gray-matter";

type Post = {
  slug: string;
  content: string;
  title: string;
  date: string;
};

const postsDirectory = path.join(process.cwd(), "content");

/**
 * postsDirectory 以下のディレクトリ名を取得する
 */
export function getPostSlugs() {
  const allDirents = fs.readdirSync(postsDirectory, { withFileTypes: true });
  return allDirents
    .filter((dirent) => dirent.isDirectory())
    .map(({ name }) => name);
}

/**
 * 指定したフィールド名から、記事のフィールドの値を取得する
 */
export function getPostBySlug(slug: string, fields: string[] = []) {
  const fullPath = path.join(postsDirectory, slug, "index.md");
  const fileContents = fs.readFileSync(fullPath, "utf8");
  const { data, content } = matter(fileContents);

  const items: Post = {
    slug: "",
    content: "",
    title: "",
    date: "",
  };

  fields.forEach((field) => {
    if (field === "slug") {
      items[field] = slug;
    }
    if (field === "content") {
      items[field] = content;
    }
    if (field === "title" || field === "date") {
      items[field] = data[field];
    }
  });
  return items;
}

/**
 * すべての記事について、指定したフィールドの値を取得して返す
 * @param fields 取得するフィールド
 */
export function getAllPosts(fields: string[] = []) {
  const slugs = getPostSlugs();
  const posts = slugs
    .map((slug) => getPostBySlug(slug, fields))
    .sort((a, b) => (a.date > b.date ? -1 : 1));
  return posts;
}

```

## トップページに Markdown ファイルの一覧を表示する

トップページに記事一覧を表示するコンポーネントを作ります。`src/pages/index.tsx` を次のように書き換えます。

```typescript:src/pages/index.tsx
import type { InferGetStaticPropsType, NextPage } from "next";
import Head from "next/head";
import styles from "../styles/Home.module.css";
import { getAllPosts } from "../lib/api";

type Props = InferGetStaticPropsType<typeof getStaticProps>;

export const getStaticProps = async () => {
  const allPosts = getAllPosts(["slug", "title", "date", "tags"]);
  return {
    props: { allPosts },
  };
};

const Home: NextPage<Props> = ({ allPosts }) => {
  return (
    <div className={styles.container}>
      <Head>
        <title>Hello world!</title>
        <meta name="description" content="Generated by create next app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>

      <main className={styles.main}>
        <h1 className={styles.title}>記事一覧</h1>

        <div className={styles.grid}>
          {allPosts.map((post) => (
            <a href={post.slug} className={styles.card} key={post.slug}>
              <h2>{post.title}</h2>
              <p>{post.date}</p>
            </a>
          ))}
        </div>
      </main>
      <footer className={styles.footer}>
        <p>Powered by Next.js.</p>
      </footer>
    </div>
  );
};

export default Home;
```

`http://localhost:3000` にアクセスして、表示を確認します。  
![記事一覧ページの画面例](/next-js-blog/aritcle-list.png)

まだ個別の記事ページを作成していないので、記事をクリックしても 404 が表示されます。
![404の画面例](/next-js-blog/404.png)

## 個別の記事ページを作成する

Markdown ファイルを解析して、HTML に変換する関数を作ります。

```typescript:src/lib/markdownToHtml.ts
import { remark } from "remark";
import html from "remark-html";

/**
 * Markdown を解析して HTML にして返す
 * @param markdown Markdown ファイル名
 * @returns HTML
 */
const markdownToHtml = async (markdown: string) => {
  const result = await remark().use(html).process(markdown);
  return result.toString();
};

export default markdownToHtml;
```

次に個別の記事ファイルを表示するコンポーネントを作ります。  
次の内容で、`src/pages/[slug].tsx` を作ります。

```typescript:src/pages/[slug].tsx
import { NextPage, InferGetStaticPropsType } from "next";
import { useRouter } from "next/router";
import ErrorPage from "next/error";
import Head from "next/head";
import styles from "../styles/Home.module.css";
import { getAllPosts, getPostBySlug } from "../lib/api";
import markdownToHtml from "../lib/markdownToHtml";

type Props = InferGetStaticPropsType<typeof getStaticProps>;

/**
 * 記事のパスを取得する
 */
export const getStaticPaths = async () => {
  const posts = getAllPosts(["slug"]);
  return {
    paths: posts.map((post) => {
      return {
        params: {
          slug: post.slug,
        },
      };
    }),
    fallback: false,
  };
};

/**
 * 記事の内容を取得する
 */
export const getStaticProps = async ({ params }: any) => {
  const post = getPostBySlug(params.slug, ["slug", "title", "date", "content"]);
  // Markdown を HTML に変換する
  const content = await markdownToHtml(post.content);
  // content を詰め直して返す
  return {
    props: {
      post: {
        ...post,
        content,
      },
    },
  };
};

const Post: NextPage<Props> = ({ post }) => {
  const router = useRouter();
  if (!router.isFallback && !post?.slug) {
    return <ErrorPage statusCode={404} />;
  }
  return (
    <div className={styles.container}>
      <Head>
        <title>Hello world!</title>
        <meta name="description" content="Generated by create next app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
      <main className={styles.main}>
        <article>
          <h1 className={styles.title}>{post.title}</h1>
          <div className={styles.grid}>
            <div>
              <p>{post.date}</p>
              <div dangerouslySetInnerHTML={{ __html: post.content }} />
            </div>
          </div>
        </article>
      </main>
      <footer className={styles.footer}>
        <p>Powered by Next.js.</p>
      </footer>
    </div>
  );
};

export default Post;
```

ポイントは 34 行目と 64 行目です。  
`post.content` の内容を HTML に変換し、`dangerouslySetInnerHTML` で HTML を innerHTML してレンダリングします。

`http://localhost:3000/hello-nextjs/` にアクセスして、表示を確認します。
![個別のページの画面例](/next-js-blog/article-page.png)
Markdown ファイルから記事が生成されていることを確認できました。

## 所感

Next.js は、Gatsby.js に比べてビルドや開発サーバの立ち上げが早いなと感じました。  
Gatsby.js では、GraphQL を使ってページの内容を取得しますが、Next.js では JavaScript で実装します。GraphQL に慣れないうちは、Next.js のほうがかんたんかもと思っています。

ただ、Google Analytics の導入やコードのハイライトなど細かいところを実現しようとすると、プラグインシステムが充実している Gatsby.js のほうが楽かもしれません。


Next.js + TypeScript で Markdown ブログを作る

---
title: 散歩中に気になった場所の情報を Slack に投稿するショートカット
date: 2021-12-24T09:00:00+09:00

tags:
  - ショートカット
  - 位置情報
archives:
  - "2021/12"
menu:
  - "blog"
featuredImg: /shortcut-pin-place/thumbnail.png

---

## 概要

街なかを歩いていて気になる店が見つかったとき、手軽に店の名前や場所の情報をメモしたい。  
今のご時世、Face ID で iPhone のロックを外してメモするのは面倒だし、家に帰って思い出そうとしてもそのお店の名前を忘れてしまった。  
そんなことが多発したので、その場でボタンを押すと位置情報付きの Google Map の URL を自分用の Slack に投稿できる仕組みを作りました。  
iOS の「ショートカット」アプリを使って実現します。

## 利用イメージ

1. 気になる店を見つけたら、ショートカットのボタンをクリックします。  
  ![ウィジェット画面](/shortcut-pin-place/press-shortcut.png)
1. 店名をメモして、[**完了**]をクリックします。
  ![入力画面](/shortcut-pin-place/input.png)

  位置情報付きの Google Map の URL とメモした内容が Slack へ投稿されます。  
  ![結果](/shortcut-pin-place/result.png)

ロック画面のウィジェットに表示しておけば、Face ID で iPhone のロックを解除する必要もなく、ショートカットを実行してメモできます。  
![ウィジェット画面](/shortcut-pin-place/widget.png)

## 動作環境

- iOS [ショートカットアプリ](https://apps.apple.com/jp/app/id915249334)
- Slack アカウント

## 事前準備

Slack で [Incoming Webhook](https://slack.com/intl/ja-jp/help/articles/115005265063) を設定し、Webhook URL を発行します。

## STEP1：ショートカットを作成する

次のようなショートカットを作成します。  
![ショートカットの全体の画面](/shortcut-pin-place/shortcut.png)

具体的には、次のアクションをつなぎ合わせます。

### 入力を要求

「お店の名前」で「テキスト」を要求

### 現在の天気を取得

「現在地を取得」でも、住所や緯度経度情報を取得できますが、実行速度が早い「現在の天気を取得」を利用します。

### テキスト

![ウィジェット画面](/shortcut-pin-place/text.png)

```plaintext
住所
https://maps.google.com/maps?q=緯度,経度
📌 お店の名前
```

「住所」「緯度」「経度」は、次の手順で変更します。

1. 「気象情報」を配置する
1. 配置した「気象情報」を長押しする
1. 「種類」を「位置情報」に変更し、それぞれ「完全な住所」「緯度」「経度」を選択する
    ![ウィジェット画面](/shortcut-pin-place/detail.png)

### URL

Slack の Webhook URL

### URL の内容を取得

![ウィジェット画面](/shortcut-pin-place/post-url.png)

- **方法** - POST
- **ヘッダー** - なし
- **本文を要求** - json
  - **text** - テキスト

## STEP2：Slack 投稿の許可を設定する

ショートカットを実行し、Slack に投稿することを常に許可しておきます。
![プライバシーの確認のダイアログ](/shortcut-pin-place/privacy.png)

## 所感

位置情報の取得にやや時間はかかりますが、ショートカットを実行するだけで位置情報をメモできるので良いです。  
位置情報も精度良く取得できていると感じます。  

最初は、お店の情報を入力するための「入力を要求」アクションをつけていませんでした。  
運用するうちに、「後で地図を見返して、何という店の名前だっけを確認する」作業が億劫になったので、ショートカット実行時に店の名前もメモできるようにしました。


散歩中に気になった場所の情報を Slack に投稿するショートカット

---
title: "HUGO v0.90.0 で追加された images.Text でブログカードと OGP 画像を自動生成する"
date: "2021-12-10T14:00:00+0900"
categories:
  - "開発"
tags:
  - "HUGO"
archives:
  - "2021/12"
menu:
  - "blog"
---

## 概要

HUGO の [v0.90.0](https://github.com/gohugoio/hugo/releases/tag/v0.90.0) から `images.Text` を使って、画像と文字を合成した画像を生成できるようになりました。  
`images.Text` を使うと、記事ファイル内のテキスト情報を埋め込んだ画像を自動で生成できそうです。

この記事では、記事ファイルの Frontmatter の情報と `images.Text` を使って、生成したブログカードの画像を一覧に表示したり、OGP 画像として設定することを試してみました。

## 環境

- HUGO v0.90.0

## img.Text の使い方を確認する

[ドキュメントのサンプル](https://gohugo.io/functions/images/#text)を確認すると、`img.Text` は、Image Filters の引数として渡すための関数です。  
`img.Text` で渡されたテキストを生成して、Image Filters でリソースに指定した画像に合成します。

```go
{{ $img := resources.Get "/images/background.png"}}
{{ $img = $img.Filter (images.Text "Hugo rocks!" (dict
    "color" "#ffffff"
    "size" 60
    "linespacing" 2
    "x" 10
    "y" 20
))}}
```

## 実装のイメージ

画像ファイルは、Frontmatter の `image` で指定し、テキストには `title` を指定します。

```markdown:posts/ramen.md
---
title: 福岡の美味しいラーメン
image: ramen.jpg
---

## 福岡といえばとんこつ
```

記事や画像ファイルは、次のように配置しました。

```bash
$ tree content
content
└── post
    ├── _index.md  # 一覧ページ
    ├── gourmet.jpg
    ├── ramen.jpg
    ├── ramen.md  # 記事ページ
    ├── udon.jpg
    └── udon.md  # 記事ページ
```

以降の説明では、`hugo new theme THEME_NAME` で生成した空のテンプレートに実装することを想定しています。

## 一覧ページに記事情報から生成したブログカードを表示する

### リストテンプレートの実装

それぞれの記事から、ブログカードの画像を作成し表示するリストページを作ります。

```go:layouts/_default/list.html
{{- define "main" }}
<h1>{{ .Title }}</h1>
{{ $font := resources.Get "https://github.com/google/fonts/raw/main/ofl/notosansjp/NotoSansJP-Black.otf" }}
{{ range .RegularPages }}
<div>
  {{- $img := .Page.Parent.Resources.GetMatch (.Params.image) }}
  {{- $title := .Title }}
  {{- with $img }}
    {{- $options := images.Text $title (dict "color" "#eee" "size" 30 "y" 120 "font" $font) }}
    {{- $img = $img.Fill "600x315 Center"  | images.Filter $options }}
    <div><img src="{{ $img.RelPermalink }}" alt="ブログカード" ></div>
  {{- end }}
  <div>
    <a href="{{ .Permalink }}">{{ .Date.Format "2006-01-02" }} | {{ .Title }}</a>
  </div>
</div>
{{ end -}}
{{ end -}}
```

  - 6行目： Frontmatter の `image`（`.Params.image`）で指定されたパスから画像を取得する
  - 7, 9行目：テキスト情報には記事のタイトル（`.Title`）を使う
  - 10行目：`images.Text` で生成したテキストを元の画像に合成する

### 動作確認

`http://localhost:1313/posts/` を確認してみます。

![一覧ページの画面例](/hugo-090-image-text/list.png)

それぞれの記事のタイトルを埋め込んだブログカードの画像が一覧に表示されていました。

## 生成した画像を OGP 画像に設定する

### \<head\> 内に表示するテンプレートの実装

同様に、生成した画像のパスを OGP のメタ情報として指定します。  

```go:layouts/partials/head.html
<meta property="og:type" content="article">
<meta property="og:title" content="{{ .Title }}">
<meta property="og:description" content="{{ .Description }}">
<meta property="og:site_name" content="{{ .Site.Title }}">
{{- $font := resources.Get "https://github.com/google/fonts/raw/main/ofl/notosansjp/NotoSansJP-Black.otf" }}
{{- $img := "" }}
{{- if .IsPage }}{{- $img = .Page.Parent.Resources.GetMatch (.Params.image) }}
{{ else if .IsSection }}{{- $img = .Page.Resources.GetMatch (.Params.image) }}
{{ end }}
{{- $title := .Title }}
{{- with $img }}
  {{- $option := images.Text $title (dict "color" "#eee" "size" 30 "y" 120 "font" $font) }}
  {{- $img = $img.Fill "600x315 Center"  | images.Filter $option }}
  <meta property="og:image" content="{{ $img.RelPermalink }}">
{{ end -}}
```

- 7, 8行目：記事ページと一覧ページでは、リソースにアクセスする方法が違います。そのため、それぞれに合った方法で画像を取得します。

### 動作確認

ローカルで OGP 情報を確認できる Chrome 拡張 [Social Share Preview](https://chrome.google.com/webstore/detail/social-share-preview/ggnikicjfklimmffbkhknndafpdlabib/related) を使って、プレビューしてみます。

一覧ページの OGP のプレビュー（`http://localhost:1313/posts/`）  
![一覧ページの OGP のプレビューの画面例](/hugo-090-image-text/ogp-section.png)

記事ページの OGP のプレビュー（`http://localhost:1313/posts/udon/`）  
![記事ページの OGP のプレビューの画面例](/hugo-090-image-text/ogp-single.png)

それぞれ、記事の情報に合わせた OGP 画像を設定できました。

## 気になったこと

今回、実装してみて気になったのは、次の点です。

- テキストが長くても、画像のサイズに合うようにテキストのサイズが自動で縮小してくれない
  - Frontmatter からフォントサイズや位置情報を渡せば解決する？
- フォントファイルを取得するときに、キャッシュが効いているのかどうか



HUGO v0.90.0 で追加された images.Text でブログカードと OGP 画像を自動生成する

---
title: "Java や Python の実行環境で Serverless Framework を利用するときにハマったこと"
description: ""
date: 2021-03-28T00:37:23.976+09:00

tags:
  - Node.js
  - Serverless Framework
archives:
  - "2021/03"
menu:
  - "blog"
---

Serverless Framework でにデプロイするとき、実行環境の言語（Java、Python）ごとにいくつかハマりポイントがあったので、メモしておきます。

## 環境

* Node.js v12.20.1
* Serverless Framework v2.30.2

## Java の場合

### 基本：デプロイするにはパッケージングが必要

実行環境が Node.js の場合は、 `serverless deploy` するだけで、関連モジュールを含めてデプロイされます。
TypeScript の場合も、トランスパイルを含めて行ってくれます。

Java の場合、deplopy する前にローカルで `jar` を作ってデプロイする必要があります。
Maven の場合は以下でパッケージングします。

```bash
$ mvn install
$ mvn package
```

### 外部ライブラリを含めて fat jar にしたい

先に説明したとおり、Java をデプロイするときにはパッケージングします。
外部ライブラリを利用するときは fat jar を作る必要があります。

Maven の場合は、` maven-shade-plugin` を使って fat jar を作ります。

```xml
  <dependencies>
    <dependency>
      <groupId>com.example.chick-p</groupId>
      <artifactId>chick-p-lib</artifactId>
      <version>0.1</version>
      <scope>system</scope>
      <systemPath>${basedir}/lib/chick-p-lib-0.1.jar</systemPath>
    </dependency>
  </dependencies>
```

### ローカルにある jar を fat jar に含めたい

先の設定だけでは、ローカルにある jar が fat jar に含まれまないため、次の設定をします。
なお、外部ライブラリは `lib` 以下に置くとします。

```xml
  <build>
    <resources>
      
      <resource>
        <directory>${project.basedir}</directory>
        <includes>
          <include>lib/*.jar</include>
        </includes>
      </resource>
      
    </resources>
    <plugins>
```

これでローカルにある jar を含めた fat jar を作成できます。

### serverless invoke local すると途中で止まるのを解決したい

#### 問題
Serverless Framework では、Lambda へデプロイする前に次のコマンドでローカル実行できます。

```bash
$ serverless invoke local --function FUNCTION_NAME
```

ただ、Java の場合、次のメッセージが表示されたまま、ローカル実行できませんでした。

```bash
$ mvn package
$ serverless invoke local --function hello
Serverless: Building Java bridge, first invocation might take a bit longer.
```

#### 解決方法

これについては [Issue](https://github.com/serverless/serverless/issues/5030) があがってました。
それよると、初回時に次のコマンドを実行する必要があります。

`${NPM_DIR}` は Serverless Framework がインストールされているディレクトリの**ひとつ上**のディレクトリです。グローバルインストールしている場合は、`npm root -g` で確認したディレクトリのひとつ上のディレクトリを指定します。

```
$ cd ${NPM_DIR}/node_modules/serverless/lib/plugins/aws/invokeLocal/runtimeWrappers/java
$ mvn package
```

この設定をしたあと `serverless invoke local` すると、無事にローカルで実行できます。

```bash
$ mvn package
$ serverless invoke local --function hello
Serverless: In order to get human-readable output, please implement "toString()" method of your "ApiGatewayResponse" object.
2020-03-28 10:05:00  INFO  Handler:18 - received: {}

com.serverless.ApiGatewayResponse@71e9ddb4
```

ただし、ローカルにある jar を含めた fat jar でローカル実行できませんでした。ローカル jar に含まれるクラスに対し、`ClassNotFoundException` という例外が出力されました。この解決方法はわかっていません。

## Python の場合

### 外部モジュールを使いたい

実行環境が Python で外部モジュールを利用する場合、いくつかの設定が必要です。

まず、npm で  [Serverless Python Requirements](https://github.com/UnitedIncome/serverless-python-requirements) をインストールします。

```bash
$ npm init
$ npm install -D serverless-python-requirements
```

動作を確認したバージョンは Serverless Python Requirements v5.1.0 です。

`serverless.yml` にプラグインの設定をします。

```yml
plugins:
  - serverless-python-requirements
```

`requirements.txt` に利用するモジュール名を記載します。この例では `requests` を利用することとします。

```plaintext
requests
```

この設定をしたあと、`serverless deploy` することで、Python でも外部モジュールを利用した Lambda 関数をデプロイできます。

なお、モジュールを利用する Python ファイルに `import requirements` が必要という記事をみましたが、現在は不要のようです。

### Python のバージョンを指定したい

Serverless Framework v2.30.2 で `aws-python3` テンプレートを利用すると、Python 3.8 が必要でした。

Python のバージョンを指定して Serverless Framework を利用するには、[公式ドキュメント](https://www.serverless.com/plugins/serverless-python-requirements#customize-python-executable)に案内されているように、Python のランタイムのパスを指定します。

```
custom:
  pythonRequirements:
    pythonBin: /opt/python3.8/bin/python
```

## 全体

実行環境によりませんが、次のハマりごともありました。

### AWS のプロファイルの設定を読み取ってくれない

#### 問題

AWS のプロファイル設定を `--aws-profile` オプションで渡したとき、認証できないというエラーが出ることがありました。

```
$ serverless delopy --aws-profile PROFILE_NAME
User: arn:aws:iam::111111111111::assumed-role/role-name is not authorized to perform: cloudformation:DescribeStacks on resource: arn:aws:cloudformation:ap-northeast-1:xxxxxxxxxxxx:stack/sample ....
```

このエラーメッセージで検索すると、IAM ロールへアタッチしたポリシーの権限が足りないのでは、というアドバイスが見受けられました。
そこでポリシーを確認してみましたが、十分な権限を渡していました。

- AWSLambdaFullAccess
- IAMFullAccess
- AmazonAPIGatewayAdministrator
- AWSCloudFormationFullAccess

AWS-CLI で cloudformation のスタック一覧を取得してみても、問題なさそうでした（スタックがないので空が返ってきました）。

```bash
$ aws cloudformation describe-stacks --profile PROFILE_NAME
[]
```

#### 解決方法

`AWS_SDK_LOAD_CONFIG` を `true` に設定します。

```bash
$ export AWS_SDK_LOAD_CONFIG=1
```


AWS SDK for JavaScript のドキュメントによるとこの環境変数を設定することで、プロファイルの内容を読み取ってくれるようです。

> https://docs.aws.amazon.com/ja_jp/sdk-for-javascript/v2/developer-guide/setting-region.html#setting-region-config-file
> AWS_SDK_LOAD_CONFIG 環境変数が真の値に設定されている場合、SDK for JavaScript はロード時に config ファイルを自動的に検索します。

エラーが出た AWS アカウントは SSO 管理されたアカウントで、通常の AWS アカウントのときに比べて、プロファイルの設定項目が増えていました。
そのため、この環境変数を設定しないと読み取ってくれない項目があったようです。

Java や Python の実行環境で Serverless Framework を利用するときにハマったこと

Gatsby.js 製のブログに、Amazon リンクを表示する Component を自作する方法を説明します。

---
title: "Gatsby.js で作ったサイトで Amazon リンクを表示する"
date: 2021-01-04T20:00:00+09:00
description: "Gatsby.js 製のブログに、Amazon リンクを表示する Component を自作する方法を説明します。"
tags:
  - "Gatsby.js"
  - "React"
archives:
  - "2020/12"
menu:
  - "blog"
---

このブログは Gatsby.js で作っていますが、リンクを埋め込みカードのように表示させたいことがあります。
普通の URL は [iframely](https://iframely.com/) を使って表示させています。

Amazon の場合はあまりよい感じの表示にならない＆アフィリエイトIDの埋め込みができないので、Amazon リンクを表示する Component を自作しました。

```javascript
<Amazon asin="B01EJ7AK5O" />
```

ASIN コードを指定してコンポーネントを呼び出すと、こんな感じに表示されます。

<Amzn asin="B01EJ7AK5O" />

## 環境

- Gatsby.js v2.28.2

## 利用する API

商品情報の取得には、[Rapid API](https://rapidapi.com/) の Amazon Product/Reviews/Keywords を利用しています。
アカウント登録し、あらかじめヘッダーで `X-RapidAPI-Key` に指定するトークンを取得しておきます。

また、axios を使って API にリクエストを送るのでインストールしておきます。

```bash
yarn add axios
```


## コンポーネントの作成

次の内容で `components/amazon.js` を作成します。
css 情報は別途 `gatsby-browser.js` で読み込んでいる css に記述しています。

```javascript
import React, { useEffect, useState } from "react"
import axios from "axios"
import { useStaticQuery, graphql } from "gatsby"

const Amazon = props => {
  const { asin } = props
  const { site } = useStaticQuery(
    graphql`
      query {
        site {
          siteMetadata {
            amazon {
              id
              token
            }
          }
        }
      }
    `
  )
  const { amazon } = site.siteMetadata
  const [data, setData] = useState([])
  const [loading, setLoading] = useState(true)

  useEffect(() => {
    axios({
      method: "GET",
      url:
        "https://amazon-product-reviews-keywords.p.rapidapi.com/product/details",
      headers: {
        "content-type": "application/octet-stream",
        "x-rapidapi-host": "amazon-product-reviews-keywords.p.rapidapi.com",
        "x-rapidapi-key": amazon.token,
        useQueryString: true,
      },
      params: {
        country: "JP",
        asin: asin,
      },
    }).then(resp => {
      setData(resp.data)
      setLoading(false)
    })
  }, [])
  if (loading) {
    return <div />
  }
  const { title, url, main_image, authors, description } = data?.product
  return (
    <div className="blog-amzn-container">
      <div
        className="blog-amzn-wc"
        style={{ backgroundImage: `url(${main_image})` }}
      ></div>
      <div className="blog-amzn-wt">
        <div>
          <strong>
            <a
              href={`${url}/ref=nosim?tag=${amazon.id}`}
              target="_blank"
              rel="noreferrer"
            >
              {title}
            </a>
          </strong>
        </div>
        {authors && <div>{authors[0].author}</div>}
        <div>{description.replace("Read moreRead less", "")}</div>
      </div>
    </div>
  )
}
export default Amazon
```


クライアントサイドで React のマウント時にのみ API をコールするようにします[^1]（`useEffect` の第2引数に空配列を指定）。

結果が返ってくるまでは（`loading` が `true`）、内容のない `<div>` タグを返しておきます。結果を取得したら `setData` で state に取得結果がセットされるので、取得結果を反映した DOM 要素を返却します。

## コンポーネントの定義をマッピングする

MDX ファイル内でコンポーネントを毎回 import するのは面倒なので、
記事を生成するテンプレート（自分の場合は `blog-post.js`）に `<MDXProvider>` を使ってあらかじめマッピングしておきます。

```javascript
import { MDXProvider } from "@mdx-js/react"
import { MDXRenderer } from "gatsby-plugin-mdx"
...
import Amazon from "../components/amazon";
const components = { Amazon };

<MDXProvider components={components}>
  <MDXRenderer>{post.body}</MDXRenderer>
</MDXProvider>
```

## まとめ

ビルド時点で API をコールしたほうが良いかもしれないので、改造するかもです…。

## 参考資料

- [Querying data client-side with fetch](https://www.gatsbyjs.com/docs/recipes/querying-data/#querying-data-client-side-with-fetch)


Gatsby.js で作ったサイトで Amazon リンクを表示する

鍋での炊飯をサポートする Alexa スキルの内容と、スキルを実装する上で難しかったことを説明します。

---
title: "鍋での炊飯をサポートする Alexa スキルを作った"
description: "鍋での炊飯をサポートする Alexa スキルの内容と、スキルを実装する上で難しかったことを説明します。"
date: 2021-01-04T15:00:00+09:00
tags:
  - "Amazon Alexa"
---

近ごろ、鍋でお米を炊いています。鍋で炊飯すると、炊飯器で炊飯するよりもおいしく感じられる気がします。  
おいしさの印といわれる「かに穴」ができた日はうれしくなります（集合恐怖症ではあるけど）。

ボタンひとつで炊飯できる炊飯器と違い、鍋で炊飯する場合はいくつかのステップが必要です。  
私の場合は次のフローで炊飯しています。

1. お米を 30 分くらい浸水させる
1. 火にかける
1. 沸騰したら弱火にして 5 分待つ
1. 火をやめて 10 分蒸らす

ここで問題になるのが、弱火にするときと蒸らすときのタイマーセッティングです。浸水時間は適当なのでタイマーはセットしていません。  
お米を炊くたびに、タイマーで 5 分、10 分と設定するのは非常に面倒くさいです。  
なので、会話の中でタイマーを設定してくれる Alexa スキル「かまどタイマー」を作りました。

この記事では、作成した Alexa スキルの内容と、スキルを実装する上で難しかったことを記載します。

## 会話フロー

「かまどタイマー」では、次の流れで Alexa と会話します。

![全体のフロー](/alexa-skill-rice-cooker/01.png)

## Alexa の応答の待ち時間は8秒なので、タイムアウトしてしまう

### 問題

Alexa からの質問に対してユーザーが答えるのに待ってくれる時間は、8 秒です。
リプロンプトを入れてもさらに 8 秒ユーザーからの応答がなければ、スキルは自動的に終了し、今までのセッション情報は破棄されます。

かまどタイマーの場合、「沸騰したら次へと言ってくれ」と Alexa が言ってきた場合には 、ユーザーは 8 秒以内に「次へ」といわなければなりません。

![応答時間は最大8秒](/alexa-skill-rice-cooker/02.png)

### 解決策

Alexa Audio Player を使って音楽を流すと、擬似的にセッションが続いているように見せることができます。

![音楽を流す](/alexa-skill-rice-cooker/03.png)

ただし、実際には Alexa Audio Player での音楽再生はスキル外で行われるため、Alexa スキルのセッションは再生開始すると破棄されます。  
そのため、セッションにおける「沸騰を待っている」「弱火の 5 分を待っている」といった情報が消えてしまいます。

ここで登場するのが、Audio Player で音楽を流すときに付与できるトークンです。

この Token に「沸騰を待っている」という情報を付与して音楽を再生します。  
「アレクサ、次へ」と言ったタイミングでは、再生している Audio Player の Token を取得して照合し、「沸騰待ちであるなら弱火のフローに進む」といった処理を行います。

![音楽に付与したトークンで前回のセッションの内容を把握する](/alexa-skill-rice-cooker/04.png)

### コード

#### トークンを付与する方の処理

```typescript
const YesIntentHandler: RequestHandler = {
  canHandle(handlerInput: HandlerInput): boolean {
    return (
      handlerInput.requestEnvelope.request.type === "IntentRequest" &&
      handlerInput.requestEnvelope.request.intent.name === "AMAZON.YesIntent"
    );
  },
  handle(handlerInput: HandlerInput): Response {
    const speechText = "沸騰したら「アレクサ、次へ」と言ってください。";
    return handlerInput.responseBuilder
      .speak(speechText)
      .addAudioPlayerPlayDirective("REPLACE_ALL", MP3_URL, "沸騰待ち", 0) // 第3引数がトークン
      .getResponse();
  },
};
```

#### 判定側の処理

```typescript
const NextIntentHandler: RequestHandler = {
  canHandle(handlerInput: HandlerInput): boolean {
    return (
      handlerInput.requestEnvelope.request.type === "IntentRequest" &&
      handlerInput.requestEnvelope.request.intent.name === "AMAZON.NextIntent"
    );
  },
  async handle(handlerInput: HandlerInput): Promise<Response> {
    if (!handlerInput.requestEnvelope.context.AudioPlayer) {
      return handlerInput.responseBuilder
        .speak("なんかおかしいです")
        .getResponse();
    }
    if (handlerInput.requestEnvelope.context.AudioPlayer.token === "沸騰待ち") {  // ここで判定
      // 沸騰
      try {
        await registerTimer(
          handlerInput,
          5,
          "お知らせです。火を止めてください。火を止めたら「アレクサ、次へ」と言ってください。",
          "弱火タイマー"
        );
      } catch (e) {
        console.log(e);
      } finally {
        const speechText = "弱火タイマー5分をセットしました。";
        return handlerInput.responseBuilder
          .speak(speechText)
          .addAudioPlayerPlayDirective("REPLACE_ALL", MP3_URL, "蒸らし待ち", 0)
          .getResponse();
      }
    }
  // ...
};
```

## 参考

- [Alexa Audio Playerを用いて、セッション終了後もユニークなイベントを発生させる](https://qiita.com/MYamate_jp/items/d770f5f317e0f61b9903)


鍋での炊飯をサポートする Alexa スキルを作った

---
title: "Node.js で Alfred Workflows を作る"
date: "2020-08-23T12:00:00+0900"
categories:
  - "開発"
tags:
  - "Alfred Workflows"
  - "Node.js"
archives:
  - "2020/08"
menu:
  - "blog"
redirect_from:
  - /blog/2020/20200823-nodejs-aflred-workflow/
---

## 概要

[Alfred](https://www.alfredapp.com/) は、Mac の多機能ランチャーアプリケーションです。
この記事では、Alfred の機能のひとつ、Alfred Workflows（以下、ワークフロー）を Node.js で作成する方法を説明します。

「[alfy](ttps://github.com/sindresorhus/alfy)」というライブラリを利用すると、Node.js でワークフローをカンタンに作成できます。

## 環境

- Alfred 4（Powerpack）
- Node.js 10

## ワークフローのしくみ

ワークフロー（要 [Powerpack](https://www.alfredapp.com/powerpack/)）は、Alfred に割り当てたトリガーや検索ボックスのインプットをもとに、情報を加工し出力します。

![](/nodejs-aflred-workflow/01.png)

たとえば筆者が作成した [alfred-kibela-workflow](https://github.com/chick-p/alfred-kibela-workflow) では、次のことを行っています。

1. ユーザーより、「ワークフローのトリガーワード」＋「キーワード」が入力される
1. 入力されたキーワードで、Kibela というサービスのノートを検索するため、API を実行する
1. 検索結果のノート一覧を Alfred 上に表示する
1. ユーザーからノートが選択される、ブラウザでそのノートを表示する

ワークフローは、Alfred の画面から「Trigers」や「Input」「Actions」などのブロックを組み合わせて作ります。

![](/nodejs-aflred-workflow/02.png)

ここで、API を実行したり API から取得したデータを Alfred で表示できるデータに加工するため、簡単なスクリプトを書く必要があります。

## 作成手順

今回は、Qiita の記事をキーワード検索して記事一覧を表示し、ユーザーが一覧から記事を選ぶとその記事をブラウザで開くというワークフローを作成します。

### 1. ダミーワークフローの作成

ダミーワークフローを作って、`info.plist` を作成します。
`info.plist` は、Alfred ワークフローのマニフェストファイルです。

### 2. 新規作成

1. Alfred の設定画面を開き、[Workflows] タブを選択します。
1. 画面下の[+]マークをクリックし、[Blank Workflow]を選択します。ワークフローの作成ダイアログが表示されます。
1. ワークフローを設定します。
    - あとで値は変更できますが、「Name」と「Bundle Id」は必ず入力してください。
1. [Create]ボタンをクリックして作成します。Workflow のリストに作成したワークフローが表示されます。

### 3. ブロックの作成

1. 作成したワークフローを選択します。
1. 右側のブロックエディタ部分で右クリックします。
1. 次のブロックを追加します。
    - [Input] > [Script Filter] を選択し、「Script Filter」ブロック
    - [Actions] > [Open URL]を選択し、「Open URL」ブロック
1. 追加したブロックで、それぞれ次のように設定します。
    - 「Script Filter」ブロック
      ![](/nodejs-aflred-workflow/03.png)

        |項目 |説明
        |:--|:--
        |Keyword |ワークフローのトリガーキーワードを設定します。
        ||-「with space」にチェック
        ||-「Argument Required」を選択
        |Language |「/bin/bash」を選択し、「with input as {query}」を選択します。
        |Script |`./node_modules/.bin/run-node src/index.js "{query}"` と入力します。
        ||あとで作成する Node.js プログラムを実行するコマンドです。
    - 「Open URL」

        |項目 |説明
        |:--|:--
        |Encode input as UTF-8 |チェックを入れる
        |Browser |「Default Browser」を選択
1. ブロックを結合します。
    ![](/nodejs-aflred-workflow/04.png)

### 4. `info.plist` のエクスポート

1. 作成したワークフローを右クリックし、[Open in Finder]を選択します。
1. `info.plist`があるので、別の場所にコピーしておきます。
1. 作成したダミーワークフローを削除します。

### 5. Node.js プログラムの作成

Node.js でスクリプトを作成します。
ここでは、Qiita API を実行して記事を検索し、取得結果を Alfred の一覧に渡すことを考えます。

1. プロジェクトを作成します。

    ```bash
    mkdir alfred-workflow-example && cd $_
    npm init -y
    ```

1. 先ほどコピーした `info.plist` をプロジェクトディレクトリの直下に配置します。

1. alfy をインストールします。

    ```bash
    npm i --save alfy
    ```

1. `package.json` を開き、npm スクリプトを定義します。

    ```json
    "scripts": {
      "postinstall": "alfy-init",
      "preuninstall": "alfy-cleanup"
    },
    ```

1. js ファイルを作成します。

    ```bash
    mkdir src
    touch src/index.js
    ```

1. `src/index.js` を開き、以下を記述します。

    ```javascript
    const alfy = require("alfy");

    const token = process.env.QIITA_ACCESS_TOKEN || "";

    const keyword = alfy.input;
    const resp = await alfy.fetch(
      `https://qiita.com/api/v2/items?query=body:${keyword}`,
      {
        method: "get",
        headers: {
          Authorization: `Bearer ${token}`,
          "Content-Type": "application/json",
        },
      }
    );
    const items = resp.map((el) => {
      return {
        title: el.title,
        subtitle: el.user.name,
        arg: el.url,
      };
    });

    alfy.output(items);
    ```

### コードのポイント

- アクセストークン
  - アクセストークンなどのユーザー固有の値は、設定する環境変数をワークフローごとに定義します。この値は、`process.env.KEY` で受け取ることができます。
- ワークフローに渡される変数
  - ワークフローでトリガーと一緒に引数を渡したい場合、「Filter Script」ブロックを使ってスクリプトに渡します。渡された値は `alfy.input` を使って受け取ります。
- `alfy.fetch()` を使うと、HTTP リクエストを送信できます。
  - [http.request](https://nodejs.org/api/https.html#https_https_request_options_callback) をベースに作られているため、ヘッダーやデータなど渡すオプションは http.request のドキュメントを参照してください。
  - 戻り値は Promise です。
- `alfy` では top-level-await を利用するには、`package.json` に以下を追記します。

    ```json
    "esm": {
      "await": true
    },
    ```

- [Alfred がサポートしている JSON オブジェクト](https://www.alfredapp.com/help/workflows/inputs/script-filter/json/)になるよう、リクエスト結果を加工します。
  - Actions や Outputs のブロックに渡したい値を `arg` に設定します。

### ワークフローのインストール

1. 作成したワークフローをインストールします。プロジェクトディレクトリ直下で、次のコマンドを実行します。

    ```bash
    npx alfy-init
    ```

1. Alfred ワークフローの設定画面を開きます。
1. 一覧より、インストールしたワークフローを選択します。
1. 環境変数を設定します。[x] ボタンをクリックします。
1. 次の環境変数を設定します。

    |Name |Value
    |:--|:--
    |QIITA_ACCESS_TOKEN |Qiita のアクセストークン
    ||[Qiita のアプリケーション設定画面](https://qiita.com/settings/applications)から作成できます。

### 動作確認

![](/nodejs-aflred-workflow/05.gif)

1. Alfred を起動します。
1. 「qiita 検索クエリ」を入力します。
1. しばらくすると、検索結果の一覧が表示されます。
1. 一覧からエンターキーで選択します。ブラウザで該当の記事が表示されます。

### ワークフローの公開

作成したワークフローは、npm intall コマンドでインストールできるような形にすると、他の人に配布できます。
たとえば、GitHub リポジトリに公開したり、さらに npm registory に公開したりするなどです。

公開するときは、`info.plist` の中に環境変数の値がセットされていないことを次の手順で確認してください。含まれていた場合は削除してください。


  1. `info.plist` をテキストエディタで開きます。
  1. エディタ内で、環境変数名を検索します。
    ```xml
      <key>variables</key>
      <dict>
        <key>QIITA_ACCESS_TOKEN</key>
        <string>This_is_a_Qiita_token</string>
      </dict>
    ```
  1. 環境変数の値がセットされていた場合は、値を削除しておきます。
    ```xml
      <key>variables</key>
      <dict>
        <key>QIITA_ACCESS_TOKEN</key>
        <string></string>
      </dict>
    ```


Node.js で Alfred Workflows を作る

---
title: "HUGO v0.74 で追加された JS Bundler を試す"
date: "2020-07-20T20:00:00+0900"
categories:
  - "開発"
tags:
  - "HUGO"
  - "TypeScript"
  - "React"
archives:
  - "2020/07"
menu:
  - "blog"
redirect_from:
  - /blog/2020/20200720_hugo-js-bundle/
---

## 概要

HUGO の v0.74.0 にて、[ESBuild](https://github.com/evanw/esbuild)が組み込まれ、 HUGO 上で JavaScript/JSX や TypeScript/TSX のバンドルが行えるようになりました。  
[Native JS Bundler, Open API Support, Inline Partials](https://gohugo.io/news/0.74.0-relnotes/)

HUGO の公式ドキュメントにはまだ記載されてませんが、[Document JS.Build #1171](https://github.com/gohugoio/hugoDocs/issues/1171)を参考にこの記事では、JS Budler を利用する方法を説明します。

> **2020/07/21 追記**
> この機能についてのドキュメントが公開されました。
> [JavaScript Building](https://gohugo.io/hugo-pipes/js/)

## 環境

- HUGO v0.74.2
- Node.js v12.18.1

## 基本

バンドル対象のリソースは、テーマディレクトリ、またはサイトディレクトリの `assets` の下に置きます。

- サイトディレクトリ内のテンプレート内で利用する場合

    ```bash
    site/
    ├── ...
    ├── assets/
    │   └── js/
    │       └── index.ts
    ├── ...
    ```

- テーマディレクトリ内のテンプレート内で利用する場合

    ```bash
    site
    ├── ...
    ├── themes
    │     └── THEME/
    │           ├── ...
    │           ├── assets
    │           │    └── js
    │           │    └── index.ts
    │           ├── ...
    ├── ...
    ```

## TypeScript のビルド＆バンドル

TypeScript をビルド＆バンドルしたいテンプレートファイルに、次のように記述します。

```go
{{ with resources.Get "js/index.ts" }}
  {{ $js := resources.Get . | js.Build }}
  <script src="{{ $js.Permalink }}"></script>
{{ end }}
```

- `resources.Get` のあとに、対象のファイルを `assets` 以下からパスを指定します。
- ビルドしたファイルのパス（ここでは、`$js.Permalink`）を`<script>`タグで指定します。

HUGO でビルドすると、js ファイルと次のような HTML が生成されます。

```html

<script src="http://localhost:1313/js/index.js"></script>

```

生成されるファイル名は、バンドルする対象のファイル名と同じです。名前を変更するには、`js.Build` に渡すオプションとして `targetPath` を指定します。

```go
{{ with resources.Get "js/index.ts" }}
  {{ $js := resources.Get . | js.Build (dict "targetPath" "js/main.js") }}
  <script src="{{ $js.Permalink }}"></script>
{{ end }}
```

ファイルを Minify するには、`js.Build` で渡すオプションに `"minify" true` を渡すか、`resources.Minify` にパイプで渡します。
参考：[Asset minification](https://gohugo.io/hugo-pipes/minification/)

- `"minify" true` を渡す例（オプションが冗長になってきたので、別変数に切り出し）

    ```go
    {{ with resources.Get "js/index.ts" }}
      {{ $option := dict "targetPath" "js/main.js" "minify" true }}
      {{ $js := resources.Get . | js.Build $option }}
      <script src="{{ $js.Permalink }}"></script>
    {{ end }}
    ```

## React のビルド＆バンドル

node_modules からのインポートをサポートしているので、React アプリケーションもバンドルできます。
今回は、HUGO v0.74.2 で追加された `defines` を利用します。

次のような React アプリケーションをバンドルすることを考えます（参考: [Components and Props](https://en.reactjs.org/docs/components-and-props.html)）。

```jsx
import * as React from "react";
import * as ReactDOM from "react-dom";

function Welcome(props) {
  return <p>Hello, {props.name}</p>;
}

function App() {
  return (
    <>
      <Welcome name="Sara" />
      <Welcome name="Cahal" />
      <Welcome name="Edite" />
    </>
  );
}

ReactDOM.render(
  <App />,
  document.getElementById("react")
);
```

`npm install` で利用するモジュールをインストールします。

> `package.json` および `node_modules` はバンドルするテンプレートディレクトリに配置する必要があります。
> たとえば、テーマディレクトリ内のテンプレートで利用する場合には、テンプレートディレクトリの下に配置します。

```bash
npm init -y
npm install --save react react-dom
```

バンドルしたいテンプレートファイルに、次のように記述します。

```go
{{ with resources.Get "js/App.jsx" }}
  <div id="react"></div>
  {{ $options := dict "targetPath" "js/app.js" "minify" true "defines" (dict "process.env.NODE_ENV" "\"development\"") }}
  {{ $js := resources.Get . | js.Build $options }}
  <script src="{{ $js.Permalink }}"></script>
{{ end }}
```

HUGO でビルドすると、js ファイルと次のような HTML が生成されます。

```html

<div id="react"></div>
<script src="http://localhost:1313/js/app.min.js"></script>

```

React を HUGO でバンドルできると、Algolia の [React InstantSearch](https://github.com/algolia/react-instantsearch) を利用して実装する検索画面も組込みきます。
検索画面のためのソースコードを別リポジトリで管理する必要がなくなるので、便利だなと感じます。

HUGO v0.74 で追加された JS Bundler を試す

---
title: "Slack の Slash Commands で Interactive Messages を利用する"
date: "2020-06-20T22:21:00+0900"
categories:
  - "開発"
tags:
  - "Slack"
  - "Slack Slash Commands"
  - "Slack Interactive Messages"
  - "Serverless Framework"
  - "TypeScript"
archives:
  - "2020/06"
menu:
  - "blog"
redirect_from:
  - /blog/2020/20200620_slack-interactive-message/
---

## 概要
この記事では、Bot がユーザーにボタン付きメッセージを送信し、ユーザーからのボタンの入力に応じてアクションする Slash Commands の作り方を説明します。

Slash Commands は、「/」（スラッシュ）から始まるコマンドを入力すると、特定のアクションを実行する機能です。
Slack 上で、ボタンやメニューなどのインターフェースを付け足メッセージを送信できます。
また、ユーザーからのアクションに応答するには、Slack Interactive Messages という機能を利用します。

Slash Commands や Interactive Messages の処理は、AWS Lambda（TypeScript）+ API Gateway で行います。
Lambda の設定やデプロイは手動が面倒なので、 Serverless Framework を利用します。

## 完成イメージ

Slash Comamnd を入力すると、
![](/slack-interactive-message/01.png)

Bot がボタン付きのメッセージを返します。
![](/slack-interactive-message/02.png)

ユーザーがボタンをクリックすると、
![](/slack-interactive-message/03.png)

Bot のメッセージを書き換えます。

## 環境

- Node.js v12.18.1
- Serverless Framework: v1.73.1
- AWS CLI v2.0.24

## Slack App の作成

Slash Commands を作成します。

### Slack App の作成

1. [https://api.slack.com/apps](https://api.slack.com/apps) を開きます。
1. [Create New App]ボタンをクリックします。
1. モーダルが表示されるので、アプリケーション名と適用するSlack のワークスペースを選択します。
1. [Create App]ボタンをクリックします。Slack App が作成されます。

### OAuth スコープの設定

1. 左サイドの「Features」から「OAuth & Permissions」を選択します。
2. 「Bot Token Scopes」より、[Add an OAuth Scope]ボタンをクリックします。
3. 「chat:write」を選択して追加します。
4. 同様に、「commands」を選択して追加します。
5. ページ上部の[Install App to Workspace]ボタンをクリックして、ワークスペースにこの Slack App をインストールします。
6.  アクセス権限をリクエストするページが表示されます。[許可する]ボタンをクリックします。

### Signing Secret の確認

1. 左サイドの「Features」から「Basic Information」を選択します。

2. 「App Credentials」から「Signing Secret」の値を控えておきます。あとで、Lambda の環境変数の設定で利用します。

## プロジェクト作成

1. Serverless Framework を使って、プロジェクトを作成します。TypeScript で開発したいので、`aws-nodejs-typescript` テンプレートを利用します。

    ```bash
    serverless create -t aws-nodejs-typescript -p slack-interactive-command

    Serverless: Generating boilerplate...
    Serverless: Generating boilerplate in "/Users/chick-p/workspace/slack-interactive-command"
    _______                             __
    |   _   .-----.----.--.--.-----.----|  .-----.-----.-----.
    |   |___|  -__|   _|  |  |  -__|   _|  |  -__|__ --|__ --|
    |____   |_____|__|  \___/|_____|__| |__|_____|_____|_____|
    |   |   |             The Serverless Application Framework
    |       |                           serverless.com, v1.73.1
    -------'

    Serverless: Successfully generated boilerplate for template: "aws-nodejs-typescript"
    ```

2. 生成された`slack-interactive-command` ディレクトリに移動します。

    ```bash
    cd slack-interactive-command
    ```

3. Serverless Framework のデプロイ時に必要なモジュールをインストールしておきます。

    ```bash
    yarn install
    ```

## Block Kit Builder での UI パーツ作成

[Block Kit Builder](https://app.slack.com/block-kit-builder/) を使うと、メッセージに利用できる UI パーツを簡単にデザインできます。

左側のメニューから利用したいパーツをドラッグ&ドロップで中央のイメージ表示部分に配置すると、右側の[Payload]タブに JSON が出力されます。
また右側の JSON を編集すると、中央のイメージ表示部分に反映されます。

![](/slack-interactive-message/04.png)

今回は、「りんご」「バナナ」「オレンジ」というラベルのボタンを配置します。またそれぞれボタンがクリックされたときの値を `value` に設定しておきます。

メッセージを作成したら、[Payload]タブの JSON を控えておきます。

## Slash Commands が実行されたときに呼び出される関数 `command` の実装

Slash Commands が実行されたときに呼び出される関数を作成します。

1. `handler.ts` を開いて、次のコードに書き換えます。`blocks` 変数の値は、「Block Kit Builder での UI パーツ作成」で作成した JSON の `blocks` の値を指定します。

    ```typescript
    import {
      APIGatewayProxyEvent,
      APIGatewayEventRequestContext,
      APIGatewayProxyResult,
    } from "aws-lambda";
    import "source-map-support/register";

    const buildErrorResponse = () => {
      return {
        statusCode: 200,
        body: "Sorry, that didn't work. Please try again.",
      };
    };

    export const command = async (
      event: APIGatewayProxyEvent,
      context_: APIGatewayEventRequestContext
    ): Promise<APIGatewayProxyResult> => {
      // リクエストが作成した App から送信されたものかを判定する
      // 詳細は後述
      if (!isVerifiedRequest(event)) {
        return buildErrorResponse();
      }

      // 「Block Kit Builder での UI パーツ作成」で作成した JSON の `blocks` の値
      const blocks = [
        {
          type: "actions",
          elements: [
            {
              type: "button",
              text: {
                type: "plain_text",
                text: "りんご",
                emoji: true,
              },
              value: "apple",
            },
            {
              type: "button",
              text: {
                type: "plain_text",
                text: "バナナ",
                emoji: true,
              },
              value: "banana",
            },
            {
              type: "button",
              text: {
                type: "plain_text",
                text: "オレンジ",
                emoji: true,
              },
              value: "orange",
            },
          ],
        },
      ];

      // メッセージの本文に Block Kit Builder で作った blocks を返す
      return {
        statusCode: 200,
        body: JSON.stringify({
          response_type: "ephemeral",
          blocks,
        }),
      };
    };
    ```

      - `response_type` に `ephemeral` を指定すると、コマンドを実行したユーザーにのみ応答メッセージが表示されます。

## Slack リクエストの検証

Slack から送られてくるリクエストが正しいかを検証する `isVerifiedRequest()` を実装します。

Slack から送られてくるリクエストは、次の2つを満たすとき正しいリクエストとして判定することを推奨しています。

- リクエストヘッダー `X-Slack-Request-Timestamp` の値は5分以内か
- リクエストヘッダー `X-Slack-Signature` が、リクエストボディの値とリクエストヘッダーのタイムスタンプの値をSigning Secret をキーにしてハッシュ化した値と正しいか

参考: https://api.slack.com/authentication/verifying-requests-from-slack

1. `crypto` と `tsscmp` を追加します。

    ```bash
    yarn add crypto tsscmp
    ```

2. 以下を `handler.ts` に追記します。

    ```typescript
    // ...略
    import "source-map-support/register";
    // 以下を追記
    import * as crypto from "crypto";
    import timingSafeCompare from "tsscmp";

    // ...略

    // 以下を追記
    const isVerifiedRequest = (event): boolean => {
      const signature = event.headers["X-Slack-Signature"];
      const timestamp = event.headers["X-Slack-Request-Timestamp"];

      // timestamp does not differ from local time by more than five minutes
      if (Math.floor(new Date().getTime() / 1000) - timestamp > 60 * 5) {
        return false;
      }

      // compare to equal the signatures
      const hmac = crypto.createHmac("sha256", process.env.SLACK_SIGNING_SECRET);
      const [version, hash] = signature.split("=");
      hmac.update(`${version}:${timestamp}:${event.body}`);
      return timingSafeCompare(hmac.digest("hex"), hash);
    };

    // ...略
    ```

## ユーザーがボタンをクリックしたときに呼び出される関数 `answer` の実装

ユーザーがボタンをクリックしたときに呼び出される関数 `answer` を作成します。

1. `axios` と `qs` を追加します。

    ```bash
    yarn add qs axios
    ```

    - `axios` は、ユーザーからのアクションの応答を送信するために利用します。
    - `qs` は、Slack から送られてくるレスポンスを parse するために利用します。

1. 以下を `handler.ts` に追記します。

    ```typescript
    // ...略
    import timingSafeCompare from "tsscmp";
    // 以下を追記
    import qs from "qs";
    import axios from "axios";

    // ...
    /// 略
    // ...

    // 以下を追記
    export const answer = async (
      event: APIGatewayProxyEvent,
      context_: APIGatewayEventRequestContext
    ): Promise<APIGatewayProxyResult> => {
      // リクエストが作成した App から送信されたものかを判定する
      if (!isVerifiedRequest(event)) {
        return buildErrorResponse();
      }
      const body = qs.parse(event.body);
      const payload = JSON.parse(body["payload"] as string);
      // ボタンクリックのアクションのときだけ返答する
      if (payload.type === "block_actions") {
        await axios.post(
          payload.response_url,
          JSON.stringify({
            text: `${payload.actions[0].value} is selected!`,
          }),
          {
            headers: {
              "Content-Type": "application/json; charset=UTF-8",
            },
          }
        );
      }
      return {
        statusCode: 200,
        body: JSON.stringify({
          response_type: "ephemeral",
        }),
      };
    };
    ```

    - `payload.response_url` で渡される URL にリクエストを送ると、元のメッセージ（ボタンを表示していたメッセージ）を書き換えできます。
      - `response_url` の URLは、30分以内に5回まで有効です。
      - 期限が切れた後にメッセージを書き換えたい場合は、Web API の `chat.update` を使って書き換えます。

## serverless.yml の修正

AWS へデプロイするため、`serverless.yml` を修正します。

### リージョンの設定
この記事では、東京リージョンを指定します。

```yaml
provider:
  name: aws
  runtime: nodejs12.x
  apiGateway:
    minimumCompressionSize: 1024 # Enable gzip compression for responses > 1 KB
  environment:
    AWS_NODEJS_CONNECTION_REUSE_ENABLED: 1
  region: ap-northeast-1 # 追記
```

### 作成した関数を定義

作成した関数 `command` と `answer` をそれぞれ定義します。
Slack からは POST リクエストが送られてくるので、method は `post` にします。

```yaml
functions:
  command:
    handler: handler.command
    events:
      - http:
          method: post
          path: command
  answer:
    handler: handler.answer
    events:
      - http:
          method: post
          path: answer
```

### 環境変数を定義

環境変数（`SLACK_SIGNING_SECRET`）は、デプロイするコマンドで与えるようにします。

```yaml
provider:
  name: aws
  runtime: nodejs12.x
  apiGateway:
    minimumCompressionSize: 1024 # Enable gzip compression for responses > 1 KB
  environment:
    AWS_NODEJS_CONNECTION_REUSE_ENABLED: 1
    SLACK_SIGNING_SECRET: ${env:SLACK_SIGNING_SECRET} # 追記
  region: ap-northeast-1
```

## AWS へのデプロイ

AWS にデプロイします。`secret` の部分は、「Slack App の作成」の「Signing Secret の確認」で確認した Signing Secret に置き換えてください。

```bash
SLACK_SIGNING_SECRET=secret serverless deploy
```

ローカルで ts ファイルが js ファイルにトランスパイルされ、AWS にデプロイされます。

デプロイが完了すると、Lambda のエンドポイント URL が表示されるので、控えておきます。

```bash
...略...
endpoints:
  POST - https://example.execute-api.ap-northeast-1.amazonaws.com/dev/command
  POST - https://example.execute-api.ap-northeast-1.amazonaws.com/dev/answer
...略...
```

## Slack App の設定

### Slash Commands の追加

1. [https://api.slack.com/apps](https://api.slack.com/apps) を開きます。
1. 作成した Slack アプリケーションを開きます。
1. 左サイドの「Features」から「Slash Commands」を選択します。
1. [Create New Command]ボタンをクリックします。
1. 次の内容を入力します。

      |項目 |値
      |:-- |:--
      |Command | コマンド名を入力します。この記事では「/fruits」にしています。
      |Request URL |Lambda のエンドポイント URL（command のほう）を入力します。
      |Short Description |コマンドの説明文を入力します。

1. [Save]ボタンをクリックします。

### Interavtive Messages の設定

1. 左サイドの「Features」から「Interactivity & Shortcuts」を選択します。
1. 「Interactivity」を「On」にします。
1. 「Request URL」に、Lambda のエンドポイント URL answer のほう）を入力します。
1. [Save Changes]ボタンをクリックします。

### 動作確認

1. Slack のワークスペースを開きます。
1. 任意のチャンネルを開きます。
1. メッセージ欄に「/fruits」（「Slash Commands の追加」で追加したコマンド）を入力し、送信します。
  ![](./01.png)
1. ボタン付きのメッセージが表示されます。
  ![](./02.png)
2. いずれかのボタンをクリックします。
3. ボタン付きのメッセージの内容が書き換わります。
  ![](./03.png)

以上で動作確認は終わりです。

## 参考

- [Slack メッセージ・アクション API を使ってディスカバラブルなアプリを作ろう](https://qiita.com/girlie_mac/items/21fedcc6ce07aa44a670)


Slack の Slash Commands で Interactive Messages を利用する

Chrome Extensions（以下、Chrome 拡張）をTypeScript で開発するための webpack の設定やファイル構成について記載しています。

---
title: "Chrome Extensions を TypeScript で開発する"
description: "Chrome Extensions（以下、Chrome 拡張）をTypeScript で開発するための webpack の設定やファイル構成について記載しています。"
date: "2020-04-29T16:21:00+0900"
tags:
  - "Chrome Extensions"
  - "TypeScript"
  - "webpack"
---

## 概要

Chrome Extensions（以下、Chrome 拡張）をTypeScript で開発するための webpack の設定やファイル構成について記載しています。

この記事では、Chrome 拡張の作り方については説明しません。作成に必要なファイルや作成した Chrome 拡張の読み込み方は、[Chrome Extension - Getting Started Tutorial](https://developer.chrome.com/extensions/getstarted) を参照してください。

## 環境

- Node.js v12.14.0
- TypeScript v3.8.3
- webpack v4.42.1
- TypeScript v3.8.3

## プロジェクト作成

1. Chrome 拡張のプロジェクトを作成します。

    ```bash
    mkdir chrome-extension-sample && cd $_
    npm init -y
    ```

2. webpack や webpack のプラグインをインストールします。

    ```bash
    npm install --save-dev webpack webpack-cli copy-webpack-plugin
    ```

3. TypeScript や、TypeScript を webpack で利用するための `ts-loader` をインストールします。

    ```bash
    npm install --save-dev typescript ts-loader
    ```

4. Chrome の型定義をインストールします。

    ```bash
    npm install --save-dev @types/chrome
    ```

## ファイル構成

次のファイル構成となるように、必要なファイルを作成します。

```bash
.
├── node_modules
├── public # Chrome 拡張に必要なファイル
│   ├── image
│   │   └── icon128.png # Chrome 拡張のアイコン
│   └── manifest.json # Chrome 拡張の設定ファイル
├── src # トライスパイル対象のファイル
│   └── background.ts # ブラウザ起動時に読み込まれるファイル
├── package.json
├── package-lock.json
├── tsconfig.json # TypeScript の設定
└── webpack.config.js # webpack の設定
```

### tsconfig.json

```json
{
  "compilerOptions": {
    "target": "es6",
    "module": "commonjs",
    "strict": true,
    "rootDir": "src",
    "esModuleInterop": true,
    "typeRoots": [ "node_modules/@types"]
  },
  "exclude": [
    "node_modules"
  ]
}
```

### webpack.config.js

```javascript
const path = require("path");
const CopyPlugin = require("copy-webpack-plugin");

module.exports = {
  mode: process.env.NODE_ENV || "development",
  entry: {
    background: path.join(__dirname, "src/background.ts"),
  },
  output: {
    path: path.join(__dirname, "dist/js"),
    filename: "[name].js",
  },
  module: {
    rules: [
      {
        test: /\.ts$/,
        use: "ts-loader",
        exclude: /node_modules/,
      },
    ],
  },
  resolve: {
    extensions: [".ts", ".js"],
  },
  plugins: [
    new CopyPlugin([{ from: ".", to: "../" }], { context: "public" })
  ],
};
```

- トランスパイル対象のファイルを `entry` で指定します。
- トランスパイル後の JavaScript ファイルを `dist/js` の下に出力します。
- `CopyPlugin` を使って、「public」ディレクトリに置いたアイコンファイルや `manifest.json` をコピーします。

### background.ts

今回は、選択した文字列を Google 検索するコンテキストメニュー（右クリックしたときに開くメニュー）を実装します。

```typescript
const openTab = (query?: string) => {
  if(query) {
    chrome.tabs.create({ url: `https://www.google.com/search?q=${query}` });
  }
}

chrome.runtime.onInstalled.addListener((): void => {
  chrome.contextMenus.create({
    id: "sample",
    title: "選択した文字列を検索する",
    contexts: ["selection"]
  });
});

chrome.contextMenus.onClicked.addListener((info, tab): void => {
  openTab(info.selectionText);
});
```

### manifest.json

```json
{
  "manifest_version": 2,
  "name": "chrome-extension-sample",
  "description": "A sample Chrome Extension.",
  "version": "0.0.1",
  "icons": { "128": "image/icon128.png" },
  "background": {
    "scripts": ["js/background.js"],
  },
  "permissions": ["contextMenus", "tabs"]
}
```

- `manifest.json` は webpack 実行時に「dist」ディレクトリの下にコピーされるので、各ファイルのパスは、「dist」ディレクトリからの相対パスを指定します。

## ビルド

production モードでビルドします。

```bash
npx webpack --mode production
```

ビルド後のファイル構成は次のようになります。

```bash
.
├── dist
│   ├── image
│   │   └── icon128.png
│   ├── js
│   │   └── background.js
│   └── manifest.json
├── node_modules
├── public
│   └── ... 略 ...
├── src
│   └── ... 略 ...
├── package-lock.json
├── package.json
├── tsconfig.json
└── webpack.config.js
```

### 動作確認

1. [Chrome Extension - Getting Started Tutorial](https://developer.chrome.com/extensions/getstarted) の記載の手順で、Chrome 拡張を読み込みます。
読み込みするディレクトリは「dist」です。

2. 新しくタブを開きます（既存のタブの場合は、リロードしてください）。

3. Web ページの文字を選択し、右クリックします。「選択した文字列を検索する」をクリックします。

4. 選択した文字について Google 検索した結果が新しいタブで表示されます。



Chrome Extensions を TypeScript で開発する

---
title: "Node-RED のノードを TypeScript で開発する"
date: "2020-03-01T13:56:00+0900"
categories:
  - "開発"
tags:
  - "Node-RED"
  - "TypeScript"
archives:
  - "2020/03"
menu:
  - "blog"
redirect_from:
  - /blog/2020/20200301_nodered-typescript/
---

## 概要

[はじめてのノード開発](https://nodered.jp/docs/creating-nodes/first-node)で紹介されている、受け取ったメッセージの文字列をすべて小文字に変換するノードをサンプルに、TypeScript で開発する方法について説明します。

npm に[Node-RED の型定義](https://www.npmjs.com/package/@types/node-red) が公開されているので、これを利用します。

## 環境

- Node.js v12.14.0
- TypeScript v3.8.3
- Node-RED v0.20.5

## プロジェクトの作成

1. Node-RED ノードのプロジェクトを作成します。

    ```bash
    mkdir node-red-contrib-lowercase
    cd node-red-contrib-lowercase
    npm init -y
    ```

2. Node-RED、TypeScript と Node-RED の型定義をインストールします。

    ```bash
    npm install --save-dev node-red
    npm install --save-dev typescript @types/node-red
    ```

## TypeScript 設定ファイルの作成

コンパイル対象のファイルは `src` の下に配置し、コンパイル後のファイルは `dist` に生成されます。<br />
        想定するディレクトリ構成は次のようになります。

```bash
.
├── dist
└── nodes
│   ├── lower-case.html
│   └── lower-case.js
├── node_modules
├── package-lock.json
├── package.json
├── src
└── nodes
│   ├── lower-case.html
│   └── lower-case.ts
└── tsconfig.json
```

1. 次のコマンドを実行し、設定ファイルを作成します。`tsconfig.json` がプロジェクトのルートディレクトリに生成されます。

    ```bash
    npx tsc --init
    ```

2. `tsconfig.json` を次のように編集します。

    ```json
    {
      "compilerOptions": {
        "module": "commonjs",
        "target": "es5",
        "outDir": "./dist",
        "rootDir": "src",
        "lib": ["es5", "dom"],
        "moduleResolution": "node",
        "typeRoots": [
          "node_modules/@types",
          "../../node_modules/@types"
        ],
        "esModuleInterop": true
      },
      "include": ["src/**/*"]
    }
    ```

## ノードの作成

### HTML ファイル

`src/nodes/lower-case.html` に、Node-RED エディタに表示されるノードの表示部分を作成します。

ここは[はじめてのノード開発 - lowercase.html](https://nodered.jp/docs/creating-nodes/first-node#lower-casehtml) と同じです。

```html
<script type="text/javascript">
  RED.nodes.registerType('lower-case',{
    category: 'function',
    color: '#a6bbcf',
    defaults: {
      name: {value: ""}
    },
    inputs: 1,
    outputs: 1,
    icon: "file.png",
    label: function() {
      return this.name || "lower-case";
    }
  });
</script>

<script type="text/html" data-template-name="lower-case">
  <div class="form-row">
    <label for="node-input-name"><i class="icon-tag"></i> Name</label>
    <input type="text" id="node-input-name" placeholder="Name">
  </div>
</script>

<script type="text/html" data-help-name="lower-case">
  <p>A simple node that converts the message payloads into all lower-case characters</p>
</script>
```

- `registerType` でノードを登録します。第1引数で指定する文字列がノード名です。

### TypeScript ファイル

`src/nodes/lower-case.ts` に、ノード実行時の処理部分を作ります。

```typescript
import { Red, Node, NodeProperties } from 'node-red';

module.exports = function(RED: Red) {
  function LowerCaseNode(this: Node, props: NodeProperties) {
    RED.nodes.createNode(this, props);
      const node = this;
      node.on('input', (msg) => {
        msg.payload = msg.payload.toLowerCase();
        node.send(msg);
    });
  }
  RED.nodes.registerType("lower-case", LowerCaseNode);
}
```

- Node-RED オブジェクトと、Node、Propeties（ノードの設定項目）に型をつけます（3-4行目）。
- `RED.nodes.registerType` で、HTML で登録したノード名に対し、実行する関数を登録します。

## package.json の編集

1. コンパイル時に、`dist` の下に Node-RED のノードに必要なファイル群がコピーされるようにします。

    ```json
      "scripts": {
        "build": "npm run copy:html && tsc ",
        "copy:html": "mkdir -p dist/nodes/ && cp -a src/nodes/*.html dist/nodes/"
      },
    ```

2. Node-RED にこのプロジェクトが Node-RED のノードだと認識されるよう、設定を追記します。

    ```bash
      "node-red": {
        "nodes": {
          "lower-case": "dist/nodes/lower-case.js"
        }
      }
    ```

## 動作確認

1. 次のコマンドを実行して ts ファイルを js ファイルに変換します。`dist` の下に必要なファイルが生成されます。

    ```bash
    npm run build
    ```

2. Node-RED をローカルにインストールします。

    ```bash
    npm install -g node-red
    ```

3. グローバルな node_modules にシンボリックリンクを張って、Node-RED にノードを登録します。

    ```bash
    npm link
    ```

4. Node-RED を起動します。

    ```bash
    node-red
    ```

5. `http://127.0.0.1:1880/` にアクセスし、Node-RED の起動を確認します。

6. エディタ上に次のノードを配置して、それぞれノードをつなぎます。

  |項目 |ノード |備考
  |:--|:--|:--
  |入力 |inject|「ペイロード」を「文字列」にして、変換したい文字列を入力します。
  |機能 |lower-case |
  |出力 |debug |

  ![](/nodered-typescript/01.png)

7. 左の実行ボタンをクリックして、inject ノードで指定した文字列が小文字になっていれば OK です。

## 独自プロパティの型定義

`lower-case` ノードの場合、ノードのプロパティはデフォルトの「Name」のみでした。

しかし、実際にノードを開発する場合、ユーザーに設定させるオリジナルのプロパティを追加することもあります。
このときの型定義は、`NodeProperties` を継承したインターフェースを作成して利用します。

例として、先頭の一文字のみ大文字にするか制御するプロパティを追加してみます。

![](/nodered-typescript/02.png)

```html
<script type="text/javascript">
  RED.nodes.registerType('lower-case',{
    category: 'function',
    color: '#a6bbcf',
    defaults: {
      name: {value: ""},
      isCapitalize: {value: false}
    },
    inputs: 1,
    outputs: 1,
    icon: "file.png",
    label: function() {
      return this.name || "lower-case";
    }
  });
</script>

<script type="text/html" data-template-name="lower-case">
  <div class="form-row">
    <label for="node-input-name"><i class="icon-tag"></i> Name</label>
    <input type="text" id="node-input-name" placeholder="Name">
  </div>
  <div class="form-row">
    <label for="node-input-isCapitalize"><i class="icon-font"></i> Capitalize</label>
    <input type="checkbox" id="node-input-isCapitalize">
  </div>
</script>

<script type="text/html" data-help-name="lower-case">
  <p>A simple node that converts the message payloads into all lower-case characters</p>
</script>
```

この状態で、TS ファイル側で `props.isCapitalize` を参照するとコンパイル時に次のエラーが出力されます。

```bash
src/nodes/lower-case.ts:15:19 - error TS2339: Property 'isCapitalize' does not exist on type 'NodeProperties'.

12       if (props.isCapitalize) {
```

### 独自プロパティの型を定義する

1. `src/lib/nodes/interfaces.ts` を作成し、以下を記載します。
    ```typescript
    import { NodeProperties } from 'node-red';

    export interface LowerCaseProps extends NodeProperties {
      isCapitalize: boolean;
    }
    ```

    - `NodeProperties` インターフェースを継承する `LowerCaseProps` インターフェースを定義します。その中で、独自のプロパティを定義します。

2. TS ファイルで `LowerCaseProps` を利用するように変更します。
    ```typescript
    import { Red, Node } from 'node-red';
    import { LowerCaseProps } from './lib/interfaces';

    const capitalize = (str: string) => {
      return str.charAt(0).toUpperCase() + str.slice(1).toLowerCase();
    };

    module.exports = function(RED: Red) {
      function LowerCaseNode(this: Node, props: LowerCaseProps) {
        RED.nodes.createNode(this, props);
          const node = this;
          node.on('input', (msg) => {
            if (props.isCapitalize) {
              msg.payload = capitalize(msg.payload)
            } else {
              msg.payload = msg.payload.toLowerCase();
            }
            node.send(msg);
        });
      }
      RED.nodes.registerType("lower-case", LowerCaseNode);
    }
    ```

これで、さきほどと同様にコンパイルがとおり、無事に js ファイルに変換されます。

### 設定ノードの型定義

Node-RED では、ノード内の設定値を別のノードとして定義しておき、利用するノード内でプロパティとして読み込む[設定ノード](https://nodered.jp/docs/creating-nodes/config-nodes)というしくみがあります。
このときの型定義は `Node` インターフェースを継承します。

- 型定義
  ```typescript
  import { Node, NodeProperties } from 'node-red';
  export interface ExampleProps extends NodeProperties {
    config: string;
  }
  export interface ConfigNode extends Node {
    credentials: {
      username: string;
      password: string;
    };
    url: string;
  }
  ```

  - `RED.nodes.getNode` でノードのIDが渡されるように、プロパティ側の `config` の型を `string` にする。
  - 設定ノードの型は `Node` を継承する。

- TS ファイル
  ```typescript
  import { Red, Node } from 'node-red';
  import { ExampleProps, ConfigNode } from './lib/interfaces';
  ... 略 ...
  export const exampleNode = (RED: Red) => {
    RED.nodes.registerType('example', function(
      this: Node,
      props: ExampleProps
    ) {
      RED.nodes.createNode(this, props);
      const configNode = RED.nodes.getNode(props.config) as ConfigNode;
      const node = this;
  ... 略 ...
  ```

  - `RED.nodes.getNode` で取得したノードの型を `ConfigNode` にキャストする。


Node-RED のノードを TypeScript で開発する

Node-RED の WebSocket ノードを使って、WAN 側から Google Home を喋らせる方法です。

---
title: "Node-RED の WebSocket ノードを使って、WAN 側から Google Home を喋らせる"
date: "2020-02-16T12:30:00+0900"
description: Node-RED の WebSocket ノードを使って、WAN 側から Google Home を喋らせる方法です。
tags:
  - "IoT"
  - "Node-RED"
  - "Google Home"
  - "Heroku"
---

## 概要

Node-Red サーバーで、[node-red-contrib-cast](https://flows.nodered.org/node/node-red-contrib-cast) ノードを使うと、簡単に Google Home で任意のメッセージを喋らせることができます。
ただし、Google Home は LAN 側にいるため Node-RED サーバーはローカルに立てる必要があり、外（WAN 側）から操作できません。

これを解決するのに、Heroku に立てた WebSocket サーバーとローカルに立てた Node-RED サーバーの WebSocket ノードを通信させることにしました。

システムの構成は下図のようになります。
![構成図](/wss-google-home/01.png)

この記事では、次のことを行います。

1. [WebSocket サーバを Heroku 上に立てる](#websocket-server-を-heroku-上に立てる)
2. [Google Home の設定を行う](#google-home-の設定を行う)
3. [Node-RED サーバをローカルに立てる](#node-red-サーバをローカルに立てる)
4. [WebSocket ノードと Cast ノードを追加する](#websocket-ノードと-cast-ノードを追加する)
5. [動作確認する](#動作確認する)

## 環境

- Node-RED v0.20.5
- Node.js v12.14.0
- Heroku / Heroku CLI v7.38.1
- Google Home
- Google Home アプリケーション（iPhone）

## WebSocket Server を Heroku 上に立てる

[Using WebSockets on Heroku with Node.js](https://devcenter.heroku.com/articles/node-websockets) を参考に、Heroku 上に WebSocket Server（とブラウザから入力を受け付けるフォームのための WebServer）を立てます。

1. プロジェクトのルートで npm を初期化します。

    ```bash
    npm init -y
    ```

1. `package.json` に以下を追記します。

    ```json
      "engines": {
        "node": "12.x"
      },
      "scripts": {
        "start": "node server.js"
      }
      ```

1. WebServer を立てるための Express と WebSocket Clinet Server の [ws](https://github.com/websockets/ws)（といくつか modules）を追加します。

    ```bash
    npm install --save express
    npm install --save ws bufferutil utf-8-validate
    ```

1. 次の内容で、`server.js` を作成します。

    ```javascript
    'use strict';

    const express = require('express');
    const { Server } = require('ws');

    const PORT = process.env.PORT || 3000;
    const INDEX = '/index.html';

    // WebServer を作成
    const server = express()
      .use((req, res) => res.sendFile(INDEX, { root: __dirname }))
      .listen(PORT, () => console.log(`Listening on ${PORT}`));

    // WebSocket Sever を作成
    const wss = new Server({ server });

    // message イベントでブラウザから受け取ったメッセージを WebSocket で通信しているクライアントに送信する
    wss.on('connection', (ws) => {
      console.log('Client connected');
      ws.on('message', (message) => {
        sendAll(message);
      });
      ws.on('close', () => console.log('Client disconnected'));
    });

    const sendAll = (message) => {
      wss.clients.forEach((client) => {
        client.send(message);
      });
    }
    ```

1. テキストボックスとボタンを配置した、`index.html` を作成します。

    ```html
    <!DOCTYPE html>
    <html>
      <head>
        <script>
          const HOST = location.origin.replace(/^http/, 'ws')
          const ws = new WebSocket(HOST);
          ws.onmessage = (event) => {
            const el = document.getElementById('server-message');
            el.innerHTML = 'Message: ' + event.data;
          };
        </script>
        <title>WebSocket Server</title>
      </head>
      <body>
        <input type="text" id="text" value="" name="text">
        <input type="submit" id="button" value="送信する">
        <p id="server-message"></p>
      </body>
      <script>
        document.getElementById('button').addEventListener('click', ()=> {
          const text = document.getElementById('text').value;
          ws.send(text);
        })
      </script>
    </html>
    ```

2. ローカルで動作確認します。

    ```bash
    npm start
    ```

    ブラウザで `http://localhost:3000` を開き、入力フォームにメッセージを入れて送信します。

    送信すると、「Message: 入力したメッセージ」が表示されます。また、開発者ツールのネットワークタブで、[WS] でフィルターすると、WebSocket 通信のキャプチャを確認できます。

    ![](/wss-google-home/02.png)

3. Git を初期化し、`node_modules` 以下を `.gitignore` に追加します。

    ```bash
    git init
    echo '*node_modules' >> .gitignore
    ```

4. ディレクトリ次の内容でコミットを作り、Heroku に push します。`APP_NAME` は Heroku のアプリケーション名で、任意の値を設定します。

    ```bash
    git add .
    git commit -am "first commit"
    heroku create APP_NAME
    git push heroku master
    ```

5. Heroku 上にできたアプリケーションで、ローカルでやったのと同様に動作確認をします。

    ```bash
    heroku open
    ```

    このとき、開発者ツールのネットワークタブで、[WS] でフィルターし、キャプチャしている WebSocket 通信の [Name] を右クリック > [Copy] > [Copy link address] で **WebSocket の通信先 URL をコピー**しておきます。

## Google Home の設定を行う

Google Home と接続したスマートフォンの Google Home アプリケーションを開き、設定画面から以下を行います。

- 言語設定を日本語にする
- 設定画面の最下部にある IP アドレスを確認する

## Node-RED サーバーをローカルに立てる

1. Node-RED をローカルにインストールします。

    ```bash
    npm install -g node-red
    ```

1. Node-RED を起動します。

    ```bash
    node-red
    ```

1. `http://127.0.0.1:1880/` にアクセスし、Node-RED の起動を確認します。

## WebSocket ノードと Cast ノードを追加する

1. Node-RED の画面で、右上のハンバーガーメニューから[パレットの管理]をクリックします。
1. [ノードの追加]タブを選択し、「node-red-contrib-cast」を検索してインストールします。
1. 左サイドメニューから、次のノードをエディタ上にドラッグ&ドロップします。

    <dl>
    <dt>入力</dt><dd>WebSocket</dd>
    <dt>機能</dt><dd>キャスト</dd>
    </dl>

1. WebSocket ノードは次のように設定します。

    |項目 |値
    |:--|:--
    |種類 |接続
    |URL |開発者ツールのネットワークタブで確認した、WebSocket の通信先 URL
    |送信/受信 |ペイロードを送信/受信

1. キャストノードは次のように設定します。

    |項目 |値
    |:--|:--
    |IP |Google Home の IP アドレス
    |Port |8009
    |language |ja

1. WebSocket ノードとキャストノードをつなぎます。

  ![](/wss-google-home/03.png)

1. [デプロイ]ボタンでデプロイします。

## 動作確認する

Heroku アプリケーションを開き、テキストボックスに喋らせたい内容を入力します。
[送信する]ボタンでクリックし、Google Home が入力した内容を喋ってくれれば成功です。


Node-RED の WebSocket ノードを使って、WAN 側から Google Home を喋らせる

---
title: "nock を使って HTTP レスポンスをモックする"
date: "2020-01-12T09:48:00+0900"
categories:
  - "開発"
  - "テスト"
tags:
  - "Node.js"
  - "Jest"
archives:
  - "2020/01"
menu:
  - "blog"
redirect_from:
  - /blog/2020/20200112_mock-http-response-nock/
---

## 概要

Node.js で HTTP 通信を含むコードのテストを書きたい場合があります。
[nock](https://www.npmjs.com/package/nock) は、Node.js の `http.request` 関数を書き換えて、モックレスポンスを返すライブラリです。

この記事では、Jest + nock を使って HTTP 通信をテストするコードについて記載します。

## 環境

- Node.js v12.14.0
- jest v24.9.0
- nock v11.7.2
- request v2.88.0

## インストール

```bash
npm install jest --save-dev
npm install nock --save-dev

# request モジュールを使うので request モジュールもインストールする
npm install request --save
```

## テスト対象のコード

テスト対象となるコードを作成します。
GitHub.com の REST API を使って、[自分のリポジトリ一覧を取得する](https://developer.github.com/v3/repos/#list-your-repositories) `fetchRepos` としました。

ファイルは、`src` の下に `github.js` という名前で保存します。

```javascript
'use strict';

const request = require('request');

const token = 'TOKEN';
const baseUrl = 'https://api.github.com';

const fetchRepos = async () => {
  const opts = {
    method: 'GET',
    url: `${baseUrl}/user/repos`,
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `token ${token}`,
      'User-Agent': 'Node-Http-Request'
    }
  };
  return new Promise(function (resolve, reject) {
    request(opts, function (error, res, body) {
      if (!error && res.statusCode === 200) {
        const json = JSON.parse(body);
        resolve(json);
      } else {
        reject(error);
      }
    });
  });
}
module.exports.fetchRepos = fetchRepos;
```

## テストコード

`fetchRepos` をテストするテストコードを書きます。
ファイルは、`src` の下に `github.test.js` という名前で保存します。

```javascript
const nock = require('nock');
const github = require('./github');

const baseUrl = 'https://api.github.com';

describe('Test using nock', () => {
  beforeEach(() => {
    nock(baseUrl)
      .get('/user/repos')
      .persist()
      .reply(200, {
        name: 'chick-p'
      });
  })
  afterEach(() => {
    nock.cleanAll();
  });
  it('should request to github.com', async () => {
    try {
      const repos = await github.fetchRepos();
      expect(repos.name).toEqual('chick-p');
    } catch(e) {
      console.log(e);
    }
  });
});
```

- 8-13行目で、指定したパスに対し、GET したときのモックレスポンスを作っています。
  - レスポンスとして、`{name: 'chick-p'}` が返却されるようにします。
  - `fetchRepos` 内で実行される API のパスおよび HTTP メソッドが同じなので、`fetchRepos` を実行したときにこのモックレスポンスが呼ばれることになります。
  - nock では 1回目の呼び出しのみ 200 が返ってきます。テストコードを通して何度も実行する場合は、`persist()` を設定します。
- 16行目で、指定したモックレスポンスをすべて解除しています。

## テストの実行

テストを実行します。
`fetchRepos` でモックに差し替わっているので、テストが合格します。

```bash
npx jest src

  PASS  src/github.test.js
  Test using nock
    ✓ should request to github.com (54ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        3.633s
Ran all test suites matching /src/i
```


nock を使って HTTP レスポンスをモックする

Jest で書かれたテストコードを Visual Studio Code 上でデバッグする方法について説明します。

---
title: "Jest で書かれたテストコードを Visual Studio Code でデバッグする"
description: "Jest で書かれたテストコードを Visual Studio Code 上でデバッグする方法について説明します。"
date: "2020-01-01T12:26:00+0900"
tags:
  - "Visual Studio Code"
  - "Jest"
---

## 概要

Jest で書かれたテストコードを Visual Studio Code 上でデバッグする方法について説明します。

[Jest のドキュメント](https://jestjs.io/docs/en/troubleshooting.html#debugging-in-vs-code)には `launch.json` に設定を記述するとなっています。
ですが、VSCode の拡張「[Jest Runner](https://marketplace.visualstudio.com/items?itemName=firsttris.vscode-jest-runner)」を入れるだけで、以下ができます。

- シナリオ単位でのテストを実行する
- breakpoint を設定してデバッグする

## 環境

- Visual Studio Code v1.41.0
- Jest Runner v0.4.11

## Jest Runner のインストール

1. Visual Studio Code で拡張機能のメニューを開きます。
2. 検索窓に「Jest Runner」と入力して検索し、Jest Runner をインストールします。

## 動作確認用のコード

次のコードで動作を確認します。

- テスト対象のコード
    ```javascript
    const uppercase = (str) => {
      if (!str || typeof str !== 'string') {
        return '';
      }
      return str.toUpperCase();
    }
    module.exports = uppercase;
    ```
- テストコード
    ```javascript
    const uppercase = require('./uppercase');

    describe('uppercase', () => {
      test('with empty', () => {
        const str = '';
        const result = uppercase(str);
        expect(result).toBe('');
      });
      test('with not empty', () => {
        const str = 'hello';
        expect(uppercase(str)).toBe('HELLO');
      });
      test('with not a string', () => {
        const str = 7;
        expect(uppercase(str)).toBe('');
      });
    });
    ```

## シナリオ単位でのテストを実行する

1. 実行したいテストにカーソルを合わせ、右クリックします。
1. 右クリックメニューから「Run Jest」を選択します。
    ![](/debug-jest-vscode/01.png)
1. カーソルを合わせたテストのみ実行されます。
    ```bash
    cd '/Users/chick-p/playground/debug-jest-sample'; node '/Users/chick-p/playground/debug-jest-sample/node_modules/.bin/jest' '/Users/chick-p/playground/debug-jest-sample/src/uppercase.test.js' -t '^uppercase with empty$'
    PASS  src/uppercase.test.js
      uppercase
        ✓ with empty (4ms)
        ○ skipped with not empty
        ○ skipped with not a string

    Test Suites: 1 passed, 1 total
    Tests:       2 skipped, 1 passed, 3 total
    Snapshots:   0 total
    Time:        3.697s
    Ran all test suites matching /\/Users\/chick-p\/playground\/debug-jest-sample\/src\/uppercase.test.js/i with tests matching "^uppercase with empty$".
    ```

## breakpoint を設定してデバッグする

1. breakpoint を設定します。例では 7 行目に設定しています。
   ![](/debug-jest-vscode/02.png)
1. コード上で右クリックします。
1. 右クリックメニューから「Debug Jest」を選択します。
   ![](/debug-jest-vscode/03.png)
1. 設定した breakpoint でテストが一時停止します。
変数にカーソルを合わせると、内容を確認できます。
    ![](/debug-jest-vscode/04.png)

## まとめ

難しい設定を書かなくても、VSCode の拡張を入れるだけで、シナリオ単位での実行やテストのデバッグができるようになりました。


Jest で書かれたテストコードを Visual Studio Code でデバッグする

---
title: "HUGO と AWS Amplify Console で静的サイトを構築する"
date: "2019-12-21 12:00:00+0900"
categories:
  - "開発"
tags:
  - "HUGO"
  - "AWS Amplify"
archives:
  - "2019/12"
menu:
  - "blog"
redirect_from:
  - /blog/2019/20191221_hugo-on-aws-amplify-console/
---

[AWS Amplify Console](https://aws.amazon.com/jp/amplify/) は、Web アプリケーションや静的サイトをホスティングできる Web サービスです。  
リポジトリの変更をトリガーにして、React や Vue.js などの SPA や、HUGO や Gatsby などの静的サイトジェネレータのビルド・デプロイ・ホスティングができます。

この記事では、次の内容について説明します。

- HUGO で作った静的サイトを AWS Amplify Console を使って、ビルド・デプロイする方法
- ログの確認
- HUGO のバージョン固定
- Pull Request 単位でのプレビュー URL 生成

## 環境

- Git
- Hugo v0.58.2

## AWS Amplify Console でサイトを構築する

### HUGO でサイトを作る

1. ビルドするサイトを作成します。サイト作成の詳細は [HUGO で静的サイトを構築する](/hugo-on-aws-amplify-console/20190930_hugo-quickstart.md) を参照のこと。

    ```bash
    hugo new site amplify-console-sample
    cd amplify-console-sample
    ```

2. テーマは、`git submodule` で追加します。
CodePipeline では submodule は利用できないとありますが、2019年12月21日現在、submodule でのテーマ追加でもビルドできました。

  > Pipeline Error: My GitHub source stage contains Git submodules, but CodePipeline doesn't initialize them
  > Problem: CodePipeline does not support git submodules. CodePipeline relies on the archive link API from GitHub, which does not support submodules.
  > Possible fixes: Consider cloning the GitHub repository directly as part of a separate script. For example, you could include a clone action in a Jenkins script.
  >
  > 参照元: [Pipeline Error: My GitHub source stage contains Git submodules, but CodePipeline doesn't initialize them](https://docs.aws.amazon.com/codepipeline/latest/userguide/troubleshooting.html#troubleshooting-gs1)


  ```bash
  git init
  git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke
  echo 'theme = "ananke"' >> config.toml
  ```

3. 記事を作成します。「contents」の下にファイルが作成されます。

    ```bash
    hugo new posts/my-first-post.md
    ```

4. `contents/posts/my-first-post.md` を開き、`draft` フラグを `false` にします。

    ```markdown
    ---
    title: "My First Post"
    date: 2019-03-26T08:47:11+01:00
    draft: false
    ```

5. GitHub でリポジトリを作成し、GitHub にプッシュします。

    ```bash
    git remote add origin git@github.com:OWNER/REPOSITORY_NAME.git
    git add .
    git commit -m "first commit"
    git push -u origin master
    ```

### AWS Amplify Console の設定

1. [AWS Amplify Console](https://console.aws.amazon.com/amplify/home) にアクセスします。

2. [GET STARTED] を選択します。
  ![](/hugo-on-aws-amplify-console/01.png)

3. 接続するリポジトリを選択します（ここでは GitHub を選択します）。
  ![](/hugo-on-aws-amplify-console/02.png)

4. 接続する GitHub アカウントに対し、AWS Amplify を認可します。
  ![](/hugo-on-aws-amplify-console/03.png)

5. リポジトリとブランチを選択し、[次へ]をクリックします。
  ![](/hugo-on-aws-amplify-console/04.png)

6. ビルド構成の設定画面で、[次へ]をクリックします。
  ![](/hugo-on-aws-amplify-console/05.png)

7. 確認画面で問題なければ、[保存してデプロイ]をクリックします。
  ![](/hugo-on-aws-amplify-console/06.png)

8. デプロイが始まります。
  ![](/hugo-on-aws-amplify-console/06.png)

9. 「検証」ステータスまで成功すると、アクセス用の URL が生成されます。
  ![](/hugo-on-aws-amplify-console/08.png)

10. URL にアクセスすると、サイトが生成されていることを確認できます。

    ```bash
    https://BRANCH_NAME.RANDOM-LETTER.amplifyapp.com/
    ```

## ログの確認

1. 各プロセスのログを確認するには、Amplify Console 画面のブランチ名をクリックします。
  ![](/hugo-on-aws-amplify-console/09-01.png)

2. 確認したいプロセスのタブを選択し、「フロントエンド」でログが表示されます。
  ![](/hugo-on-aws-amplify-console/09-02.png)

## HUGO のバージョンを固定する

AWS Amplify Console でビルドする HUGO のバージョンを固定します。

1. 左サイドバーの「アプリケーションの設定」から「ビルドの設定」を選択します。
  ![](/hugo-on-aws-amplify-console/10-01.png)

2. [Edit]をクリックします。
  ![](/hugo-on-aws-amplify-console/10-02.png)

3. [Add package version override]をクリックし、「Hugo」を選択します。
  ![](/hugo-on-aws-amplify-console/10-03.png)

4. バージョンを入力し、[保存]をクリックします。
  ![](/hugo-on-aws-amplify-console/10-04.png)

5. 次回以降のビルドから、指定したバージョンの HUGO でビルドできます。

## PR 単位で Preview ページを作る

### 設定

Pull Request 単位で確認用の URL を作成します。

1. 左サイドバーの「アプリケーションの設定」から「Previews」を選択します。
  ![](/hugo-on-aws-amplify-console/11-01-01.png)

2. [Enable previews]をクリックします。
  ![](/hugo-on-aws-amplify-console/11-01-02.png)

3. [Install GitHub app]をクリックし、接続している GitHub アカウントに AWS Amplify アプリケーションをインストールします。
  ![](/hugo-on-aws-amplify-console/11-02.png)

4. アカウントを選びます。
  ![](/hugo-on-aws-amplify-console/11-03.png)

5. 「Only selecto reposities」を選択し、インストールするリポジトリを選びます。
  ![](/hugo-on-aws-amplify-console/11-04-01.png)

6. [Install]をクリックします。
  ![](/hugo-on-aws-amplify-console/11-04-02.png)

7. AWS Amplify Console の画面に戻ります。Pull Request を出す対象のブランチを選び、[Manage]をクリックします。
  ![](/hugo-on-aws-amplify-console/11-05.png)

8. 「Enabled」にして、[確認]をクリックします。
  ![](/hugo-on-aws-amplify-console/11-06.png)

9. 「Preview Status」が Enabled になれば完了です。
  ![](/hugo-on-aws-amplify-console/11-07.png)

### 動作確認

1. マスタ ブランチに対して有効にしたので、マスタ ブランチに対する Pull Request を作成します。
  ![](/hugo-on-aws-amplify-console/11-09.png)

2. Pull Request を作成すると、「Previews」にその PR に対するビルドが行われ、ページ URL が生成されます。
  ![](/hugo-on-aws-amplify-console/11-09.png)

3. Pull Request 作成後のコミットについても、自動でビルドが実行されます。



HUGO と AWS Amplify Console で静的サイトを構築する

---
title: "GitHub Actions でFitbit アプリケーションの構文チェックとビルドチェックを行う"
date: "2019-12-15"
tags:
  - "Fitbit"
  - "GitHub Actions"
---

## 概要

[GitHub Actions](https://help.github.com/en/articles/about-github-actions) を使って、Fibit アプリケーションの構文チェック（[ESLint](https://eslint.org/)）とビルドチェックを行います。

## 環境

- ESLint v6.7.2
- @Fitbit/sdk-cli v1.7.1

前提として、ESLint の実行に必要なライブラリのインストール、および設定ファイルは作成済みとします。

## GitHub Actions で動かす npm-script を作成する

`package.json` に次の npm script を追記します。

```json
  ...,
  "scripts": {
    "build": "fitbit-build",
    "lint": "eslint --max-warnings 0 **/*.ts"
  },
  ...
```

warning もエラーとして扱いたいので、オプションで `--max-warnings 0` を指定します。

## GitHub Actions の設定ファイルの作成

「.github/workflows」直下に、次の内容で YAML ファイルを作成します。ここでは「build.yml」としています。

このワークフローは、[actions/setup-node](https://github.com/actions/setup-node) を利用しています。
内容は [actions/starter-workflows](https://github.com/actions/starter-workflows/blob/master/ci/node.js.yml) を参考にし、さきほど定義した npm-script のコマンドを指定します。

```yaml
name: fitbit-app-build
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - name: Set Node.js 12.x
      uses: actions/setup-node@master
      with:
        node-version: 12.x
    - name: npm install, build, and lint
      run: |
        npm ci
        npm run lint
        npm run build
      env:
        CI: true
```

npm-scripts を追記した `package.json` とGitHub Actions の設定ファイルを GitHub に push します。
これで、リモートにファイルを push すると CI が実行されます。

![](/github-actions-fitbit-build/01.png)

## ステータスバッジの表示

[Configuring a workflow](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/configuring-a-workflow) を参考に、GitHub Actions のステータスバッジを表示します。

![](/github-actions-fitbit-build/02.png)

バッジ表示は、ワークフロー名を使う方法とワークフローファイルを指定する方法の2つがあります。
Markdown ファイルに表示する場合、次の内容を追記します。

- ワークフロー名を使う方法

  ```markdown
  ![](https://github.com/<OWNER>/<REPOSITORY>/workflows/<WORKFLOW_NAME>/badge.svg)
  ```

    ワークフロー名は URL エンコードが必要です。

- ワークフローファイルを指定する方法

```markdown
![](https://github.com/<OWNER>/<REPOSITORY>/workflows/.github/workflows/<WORKFLOW_FILE_NAME>.yml/badge.svg)
```


GitHub Actions でFitbit アプリケーションの構文チェックとビルドチェックを行う

Fitbit で動かすアプリケーションを TypeScript で開発する手順を説明します。

---
title: "Fitbit アプリケーションを TypeScript で開発する"
description: "Fitbit で動かすアプリケーションを TypeScript で開発する手順を説明します。"
date: "2019-12-14"
tags:
  - Fitbit
  - TypeScript
---

Fitbit で動かすアプリケーションを TypeScript で開発する手順を説明します。

[fitbit-sdk-types](https://www.npmjs.com/package/fitbit-sdk-types) を使って、JavaScript で開発した既存のアプリケーションを TypeScript に移行します。

## 環境

- Node.js v12.13.1
- @fitbit/sdk v4.0.1
- @fitbit/sdk-cli v1.7.1

## TypeScript への移行

1. Fitbit アプリケーションのプロジェクト直下で、次のコマンドを実行します。

    ```bash
    npx fitbit-sdk-types apply-ts
    ```

    コマンドを実行すると、次のことが行われます。

    - `package.json` の `devDependencies` に「fitbit-sdk-types」が追加される
    - プロジェクト直下に `tsconfig.json` が生成される ※ 生成されない場合は、3. を参照
    - 「app」「companion」「settings」ディレクトリ以下
      - `.js` が `.ts` に変更される
      - `tsconfig.json` が生成される

2. 「app」「companion」「settings」以外にディレクトリを作っていて、`.js` ファイルがある場合は、手動で `.ts` に変更します。

3. プロジェクト直下に `tsconfig.json` が生成されていない場合は、次の内容で `tsconfig.json` を作成します。

    ```json
    {
        "extends": "./node_modules/@fitbit/sdk/sdk-tsconfig.json"
    }
    ```

4. ESLint を導入していたので、次のことも行いました。
    1. `@typescript-eslint/parser` `@typescript-eslint/eslint-plugin` をインストールします。

          ```bash
          $ npm i @typescript-eslint/parser @typescript-eslint/eslint-plugin --save-dev
          ```

    2. 設定ファイル（`.eslintrc.js`）に TypeScript の設定を追加します。

        ```javascript
        ...,
        plugins: ["@typescript-eslint"],
        extends: [
          "plugin:@typescript-eslint/eslint-recommended",
          "plugin:@typescript-eslint/recommended"
        ],
        ...
        ```

## ビルド
Fitbit CLI でビルドします。Fibit CLI の使い方は、[別記事](20190824_fitbit-cli.md)を参照。

```bash
npx fitbit

fitbit$ build
```

もし TypeScript のエラーがあれば build で次のようなエラーが発生します。

```bash
[21:18:58][error][app] app/index.ts:110,13 TS2339: Property 'style' does not exist on type 'Element'.
[21:18:58][error][app] Error: Failed to compile /Users/chick-p/Works/fitbit-project/app/index.ts
```

## 移行でつまずいたところ
### 'style' プロパティがない

* コード

    ```typescript
    const el = document.getElementById("element-id");
    ```

* エラー
    ```bash
    [21:18:58][error][app] app/index.ts:110,13 TS2339: Property 'style' does not exist on type 'Element'.
    [21:18:58][error][app] Error: Failed to compile /Users/chick-p/Works/fitbit-project/app/index.ts
    ```

* 原因
  `document.getElementById("element-id")` の戻り値の型が `Element` だったので、`style` がないと怒られていました。

* 解決策
  `GraphicsElement` にキャストします。

    ```typescript
    const el = document.getElementById("element-id") as GraphicsElement;
    ```

### HeartRateSensor のコンストラクタでエラー
* コード
  ```typescript
  const hrm = new HeartRateSensor()
  ```

* エラー
  ```bash
  [21:49:54][error][app] app/index.ts:70,18 TS2351: This expression is not constructable.
        TS2760: Not all constituents of type 'void | HeartRateSensorConstructor' are constructable.
        TS2761: Type 'void' has no construct signatures.
  [21:49:54][error][app] Error: Failed to compile /Users/chick-p/Works/fitbit-project/app/index.ts
  ```

* 原因
  `HeartRateSensor` はデバイスによっては付いてないことがあるので、存在チェックを必要とします。

* 解決策
  存在チェックをします。

  ```typescript
  if (HeartRateSensor) {
    const hrm = new HeartRateSensor();
    ...
  }
  ```



Fitbit アプリケーションを TypeScript で開発する

---
title: "Netlify Functions を使って CORS 制限を回避する"
date: "2019-11-16 10:23:00+0900"
categories:
  - "開発"
tags:
  - "webpack"
  - "Netlify Functions"
archives:
  - "2019/11"
menu:
  - "blog"
redirect_from:
  - /blog/2019/20191116_netlify-function-proxy/
---


## 概要

[webpack-dev-server](https://webpack.js.org/configuration/dev-server/#devserver) は、webpack を用いた開発用サーバーを立てるためのモジュールです。
[Netlify Functions](https://docs.netlify.com/functions/overview/) は、Netlify の提供するアドオンのひとつで、 AWS Lambda を実行基盤にした FaaS（Function as a Service）です。

webpack-dev-server で立てた開発サーバーから Netlify Functions で立てたサーバーを呼び出すと、port が違うため CORS の同一オリジンポリシーの制約に引っかかります。

![](./01.png)

これを回避するには、webpack-dev-server のプロキシ機能を使います。

![](./02.png)

## 環境

- webpack-dev-server v3.9.0
- netlify-lambda v1.6.3

## webpack の設定

`:webpack.config.js` に次の設定を追記します。

```javascript
module.exports = {
  mode: "development",
  // ... 省略 ...
  devServer: {
    proxy: {
      '/.netlify': {
        target: 'http://localhost:9000',
        pathRewrite: { '^/.netlify/functions': '' }
      }
    }
  }
}:
```

- webpack-dev-server に「/.netlify」へのリクエストが来たとき、Netlify Function のサーバー（`localhost:9000`）へフォワードします。
- `pathRewrite` の設定で、「/.netlify/functions」を取り除いた形でのリクエストをバックエンドに投げます。

## おまけ：Nuxt.js の場合
[Nuxt.js](https://ja.nuxtjs.org/guide/) を使って作ったページで、axios を使って Netlify functions へリクエストを送ることを考えます。
Nuxt.js は v2.8.1 で確認しました。

Nuxt.js の設定ファイル `nuxt.config.js` は次のように設定します。

```javascript
module.exports = {
  modules: [
    '@nuxtjs/axios',
    '@nuxtjs/proxy'
  ],
  generate: {
    dir: 'dist/client'
  },
  axios: { baseURL: '/.netlify/functions' },
  proxy: {
    '/.netlify': {
      target: 'http://localhost:9000',
      pathRewrite: { '^/.netlify/functions': '' }
    }
  }
}
```

Nuxt.js でのページと Netlify Functions はこんな感じに作ります。

- リクエストを送るページ

    ```vue
    <template>
      <main>
        <input v-model="name" placeholder="Name"></input>
        <input v-model="message" maxlength="200" type="textarea"></input>
        <button @click="sendMessage">Send</button>
      </main>
    </template>

    <script>
      export default {
        data() {
          return {
            name: '',
            message: ''
          }
        },
        methods: {
          async sendMessage() {
            const params = {
              name: this.name,
              message: this.message
            };
            try {
              const resp = await this.$axios.post('/message', params);
              this.$router.push('/result');
            } catch(e) {
              const message = e || 'Sorry, an error occurred.'
              window.alert(message);
            }
          }
        }
      }
    </script>
    ```

- 結果を表示するページ

    ```vue
    <template>
      <main>
        <span>Thank you!</span>
      </main>
    </template>

    <script>
      export default {
        data() {
          return {
          }
        }
      }
    </script>
    ```

- Netlify Functions の Lambda 関数

    ```javascript
    'use strict';

    const fetch = require('node-fetch');
    export const header = {
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Credentials': 'true',
      'content-type': 'application/json; charset=utf-8',
    };

    exports.handler = async (event, context, callback) => {
      if (event.httpMethod !== 'POST') {
        callback(null, {
          statusCode: 503,
          headers: header,
          body: JSON.stringify({error: 'Method Not Allowed'})
        });
      }

      try {
        const data = JSON.parse(event.body);
        const options = {
          method: 'post',
          body: { name: data.name, message: data.message},
          headers: {'Content-Type': 'application/json', 'X-EXAMPLE-Authorization': 'XXXXX'}
        };
        const resp = await fetch('https://exmaple.com/api/v1/message', options);
        callback(null, {
          statusCode: 200,
          headers: header,
          body: JSON.stringify(resp)
        });
      } catch(err) {
        callback(null, {
          statusCode: 500,
          headers: header,
          body: JSON.stringify(err)
        });
      }
    };
    ```

## 参考
- [netlify-lambda serve (legacy command): Proxying for local development](https://github.com/netlify/netlify-lambda#netlify-lambda-serve-legacy-command-proxying-for-local-development)


Netlify Functions を使って CORS 制限を回避する

---
title: "HUGO のテンプレートファイルの優先順位を理解する"
date: "2019-10-27T12:06:00+09:00"
series:
  - "HUGO オリジナルテーマを作る"
categories:
  - "開発"
tags:
  - "HUGO"
archives:
  - "2019/10"
menu:
  - "blog"
redirect_from:
  - /blog/2019/20191027_hugo-template-order/s
---

HUGO では、`content` の下にある Markdown ファイルを、**テンプレートファイル**を使用して HTML に変換しています。

レンダリングに利用するテンプレートファイルは、ページの種類（コンテンツファイルのパス）に応じて用いられるファイルが異なります。
この記事では、サイトのコンテンツがどのテンプレートファイルを使用してレンダリングされるかについて説明します。

## 環境

- HUGO v0.58.2/extended

## コンテンツファイルの構成
`content` ディレクトリが、次のようなファイル構成だったとします。

```bash
.
├── ...
├── content
│   ├── _index.md # Home page
│   ├── page-01.md # Single page
|   ├── posts
|   |   ├── _index.md # Section page
|   |   ├── post-01.md # Single page
|   |   └── post-02.md # Single page
|   └── quote
|   |   ├── quote-01.md # Single page
|   |   └── quote-02.md # Single page
├─ ...
```

- Home page
  - `content` 直下にある `_index.md` ファイルは、「Home page」と呼ばれ、サイトのトップページにあたるページになります。
- Section pages
  - contents 次のディレクトリは「Section」と呼ばれ、そのディレクトリ直下の `_index.md` はセクションページと呼ばれます。
- Single page
  - 個々の記事ページにあたるページです。
- List pages
  - コンテンツの一覧を表示することを目的としたページです。
- Taxonomy Terms Pages
  - HUGO では、Taxonomy（タクソノミー）と呼ばれる項目を記事ファイルの Front matter につけて、記事をグルーピングできます。たとえば、「タグ」や「カテゴリ」といった項目が Taxonomy にあたります。また、Taxonomy に割り当てられる具体的な値を Term と呼びます。たとえば、記事に「開発」というタグを付け足場合、「開発」が Term にあたります。
  - Taxonomy Terms Pages は、Taxonomy に割り当てられた Term をもつ記事の一覧ページです。

## テンプレートファイルを参照するディレクトリの優先順位
HUGO は、コンテンツを HTML に変換するとき、あるルールにもとづいてテンプレートファイルを参照しています。

HUGO は、大まかには次の優先度でテンプレートファイルのあるディレクトリを探索します。

1. `layouts/` 以下
2. `themes/{テーマ名}/layouts` 以下

探索しているディレクトリのうち、後述するファイル名の優先順位にもとづいて最初に見つかったファイルがテンプレートとして利用されます。
見つからなければ、次に優先度の高いディレクトリでファイルを探します。
最後まで見つからなければ、そのコンテンツはレンダリングされないので、真っ白なページになります。

このディレクトリの優先順位があります。
テーマファイルを一部修正したいときは `layouts` 以下へ変更したいテンプレートファイルと同名のファイルを置くと、そのページのレイアウトだけを独自に変更できます。

## テンプレートファイルを参照するファイル名の優先順位
### Home page
Home page はホームページテンプレートを使って、HTML へレンダリングされます。

ホームページテンプレートは、次のファイルのうち、最初に見つかったファイルが利用されます（参考：[Layout Lookup for Home Page](https://gohugo.io/templates/lookup-order/#examples-layout-lookup-for-home-page)）。

> - index.html
> - home.html
> - list.html
> - _default/index.html
> - _default/home.html
> - _default/list.html

`list.html` は、List page を生成します。
トップページがランディングページではなく記事一覧のみでよい場合は、`index.html` や `home.html` を作らずに、`list.html` だけを作ります。

### Section page
Section page は、セクションテンプレートを使って、HTML へレンダリングされます。

セクションテンプレートは、次のファイルのうち、最初に見つかったファイルが利用されます（参考：[Layout Lookup for Section Page](https://gohugo.io/templates/lookup-order/#examples-layout-lookup-for-section-pages)）。

> - {セクション名}/{セクション名}.html
> - {セクション名}/section.html
> - {セクション名}/list.html
> - section/{セクション名}.html
> - section/section.html
> - section/list.html
> - _default/{セクション名}.html
> - _default/section.html
> - _default/list.html

Home page と同様に、セクションにランディングページを作りたい場合は、`section.html` を作ります。
`{セクション名}/{セクション名}.html` や `{セクション名}/section.html` のように、セクション名ごとに別々のランディングページを作ることもできます。

### Single page
Single page は、セクションテンプレートを使って、HTML へレンダリングされます。

シングルページテンプレートは、次のファイルのうち、最初に見つかったファイルが利用されます（参考：[Layout Lookup for Single Page](https://gohugo.io/templates/lookup-order/#examples-layout-lookup-for-regular-pages)）。

> - {セクション名}/single.html
> - _default/single.html

## 参考

- [Hugo's Lookup Order](https://gohugo.io/templates/lookup-order/)


HUGO のテンプレートファイルの優先順位を理解する

---
title: "GitHub Actions + reviewdog で textlint を実行する"
date: 2019-10-17T00:10:00+09:00
tags:
  - "GitHub Actions"
  - "reviewdog"
  - "textlint"
---

この記事では、文章校正ツールである [textlint](https://github.com/textlint/textlint) のチェックでエラーになったときの結果を、GitHub の Pull Request へコメントする設定について説明します。
textlint は [GitHub Actions](https://help.github.com/en/articles/about-github-actions) を使って実行し、[reviewdog](https://github.com/reviewdog/reviewdog)を使って Pull Request へコメントします。

reviewdog は GitHub Actions で使える Docker ベースの [Public reviewdog actions](https://github.com/marketplace?type=actions&query=reviewdog) を公開しています。

しかしtextlint 用の actions はないので、この記事ではワークフローの定義ファイルを自作します。


## 環境

* [GitHub Actions](https://help.github.com/en/articles/about-github-actions) β版（YAML Syntax）
* [reviewdog](https://github.com/reviewdog/reviewdog) v0.9.13
* [textlint](https://github.com/textlint/textlint) v11.4.0

## GitHub Actions 設定ファイルの作成

1. GitHub Actions を設定するリポジトリを準備します。

2. GitHub Actions のワークフローの定義ファイルは `.github/workflows` の下に置きます。この記事では、ワークフローの定義ファイルは `reviewdog.yml` としました。

    ```bash
    mkdir -p .github/workflows
    touch .github/workflows/reviewdog.yml
    ```

3. `.github/workflows/reviewdog.yml` のファイルの内容には、以下を記述します。

    ```yaml
    name: 'Run textlint with reviewdog'
    on: [pull_request]
    jobs:
      textlint:
        runs-on: Ubuntu-latest
        container:
          image: node:current-alpine
          env:
            LEVEL: error
            FLAGS: src/
        steps:
          - uses: actions/checkout@v1
          - name: setup-reviewdog
            run: |
              mkdir -p $HOME/bin && wget -O - -q https://raw.githubusercontent.com/reviewdog/reviewdog/master/install.sh \
                | sh -s -- -b /usr/local/bin/ v0.9.13
              apk --update add git && \
                rm -rf /var/lib/apt/lists/*
          - name: installl-textlint
            run: |
              cd "$GITHUB_WORKSPACE"
              if [ ! -f "$(npm bin)/textlint" ]; then
                npm install
              fi
          - name: run-reviewdog
            env:
              REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
            run: |
              $(npm bin)/textlint -f checkstyle "${FLAGS:-'.'}" \
                | reviewdog -f=checkstyle -name="textlint" -diff="git diff ${{ github.event.pull_request.base.ref }}" -reporter=github-pr-review -level="${LEVEL}"
    ```

    * `LEVEL` は reviewdog のエラーレベルを設定します。`info`、`warning`、`error` を指定できます。
    * `FLAGS` は textlint をかけたい Markdown ファイルがあるディレクトリを指定します。
    * `${{ secrets.GITHUB_TOKEN }}` と記述すると、GitHub 側が自動で GitHub トークンを作成します。このトークンは`${{ secrets.GITHUB_TOKEN }}` を使ったステップでのみ参照されます。

## textlint の設定
textlint のルールプリセットは [preset-ja-technical-writing](https://github.com/textlint-ja/textlint-rule-preset-ja-technical-writing) を使っています。

1. 利用する npm パッケージを `package.json` に追加します。

    ```bash
    npm init -y
    npm install -D textlint textlint-rule-preset-ja-technical-writing
    ```

2. `.textlintrc` を作成し、次の内容を追記します。

    ```json
    {
      "plugins": {
        "@textlint/markdown": {
          "extensions": [".md"]
        }
      },
      "rules": {
        "preset-ja-technical-writing": true
      }
    }
    ```

## GitHub への反映

作成したファイル群を定義ファイルをリモートにプッシュします。

```bash
git add .
git commit -m "Added: reviewdog workflow"
git push origin master
```

## 動作確認
わざと lint エラーになるファイルを作成し、別ブランチに push してプルリクを作ってみます。

1. `example` ブランチを作成し、`src/example.md` としてエラーになるファイルを作ります。

    ```bash
    git checkout -b example
    mkdir src
    touch src/example.md
    ```

2. `src/example.md` の内容はこんな感じです。

    ```markdown
    # Example

    これはサンプルです。
    `src` ディレクトリ以下に textlint を実行したい Markdown ファイルを置きます。
    このディレクトリは `.github/workflows/reviewdog.yml` の `FLAGS` で変更することができます。
    ```

3. リモートに push します。

    ```bash
    git add src/example.md
    git commit -m "Added: error sample file"
    git push origin example
    ```

4. GitHub.com の画面を開きます。`master` ブランチに対して、`example` をマージするプルリクを作成します。

5. [Actions]タブを開きます。プルリクを作成すると、Actions の実行ログを確認できます。
    ![](/github-actions-reviewdog-textlint/02.png)

6. lint エラーが発生している場合は、こんな風にプルリクに対してエラー内容がコメントされます。

    ![](/github-actions-reviewdog-textlint/03.png)

## 参考

* [GitHub Actions と 主に reviewdog を使った Automated Code Review](https://docs.google.com/presentation/d/1o_5hlRYgXaKARwAxtrQ_qV11c-7_ztJ1ofLrUJ3_y3U/edit)
* [reviewdog/action-eslint](https://github.com/reviewdog/action-eslint)


GitHub Actions + reviewdog で textlint を実行する

---
title: "HUGO で独自 Shortcode を作る"
date: 2019-10-15T23:07:00+09:00
thumbnail: "../img/0000_hugo-thumbnail.png"
categories:
  - "開発"
tags:
  - HUGO
archives:
  - "2019/10"
menu:
  - "blog"
redirect_from:
  - /blog/2019/20191015_hugo-shortcode/
---

HUGO では、記事ファイルを軽量マークアップ言語である Markdown 形式で作成します。しかし、Markdown の表現力には限りがあるため、HTML に頼りたくなる場合があります。
とはいえ、何度も同じような HTML を記述するのは面倒＆ HTML タグを記述することでファイルの可読性が落ちてしまいます。

この問題を解決するため、HUGO には、**[Shortcode](https://gohugo.io/content-management/shortcodes/)**（以下、ショートコード）という機能があります。
Markdown ファイル内で `{{< ショートコード名 >}}` と記述すると、コンテンツ内にショートコードとして定義したテンプレートファイルの HTML の内容を埋め込ます。

HUGO には、Twitter ツイートや Gist コードの埋め込みなど、[ビルドインのショートコード](https://gohugo.io/content-management/shortcodes/)が用意されています。
一方で独自にショートコードを作成できるので、この記事ではテンプレートファイルの作成方法を説明します。

## リンクを新規タブで開くショートコードを作る
Markdown で `[リンク名](リンクURL)` と記述すると、そのリンクは同一タブに開かれます。
新規タブで開きたい場面もあるので、新規タブで開くようなショートコード `target_blank` を作成します。

### 完成イメージ
このショートコードは、記事ファイルに次のように記述します。

```go
{{< target_blank url="https://blog.chick-p.work" "ひよこまめ" >}}
```

* 引数として、`src` にリンク先の URL、`title` に a タグを設定する文字列を渡します。

次のような HTML を生成します。

**生成される HTML:**
```html
<a href="https://blog.chick-p.work" target="_blank">ひよこまめ</a>
```

### テンプレートファイルの作成
ショートコードは、`layouts/shortcodes` というディレクトリの下にある、ショートコードと同名の HTML ファイルをテンプレートファイルとして認識します。

1. `layouts`の下に、`shortcodes` というディレクトリを作成します。

2. ショートコードと同じ名前の HTML ファイルを作成します。今回のショートコード名は `target_blank` なので、`target_blank.html` を作成します。

    ```bash
    ├── ...
    ├── layouts
    │   ├── shortcodes
    │   │   └── target_blank.html
    ├── ...
    ```

3. `target_blank.html` に次の HTML を記述します。

    ```go
    {{- $url := .Get "url" -}}
    {{- if not $url -}}
      {{ errorf "missing value for param 'url': ％s" .Position }}
    {{- end -}}
    <a href="{{ $url }}" target="_blank">{{ .Get "title" }}</a>
    ```

     * HUGO では、変数や関数を`{{ }}`で囲います（参考：[HUGO のテンプレート記法](https://gohugo.io/templates/introduction/)）。
         * `-` は、前後の空白や改行をトリムします。
     * ショートコードで渡された引数は、`.Get "引数名"`で受け取ることができます。
     * `$変数名 := 値` の形で変数を定義します。変数 `$url` に引数の `url` で渡された値を設定しています。
     * 1〜3行目は、`url` が未指定または値が空なら、エラーとする処理です。
         * IF 文は`{{ if 条件式 }} 条件式が成り立つときの処理 {{ end }}` という形で記述します。
     * `{{ $変数名 }}` で定義した変数の値を呼び出します。

## メッセージブロックを表示するショートコードを作る
[Bootstrap のアラート](https://getbootstrap.com/docs/4.3/components/alerts/)のようなメッセージブロックを表示するショートコード `message_box` を作成します。

**例：**
<div style="padding: 0.75em; margin-bottom: 1rem; color: #fff; background-color: #78c2ad; border: 1px solid transparent; border-radius: 0.25rem;">こんな感じにメッセージを表示するメッセージブロック</div>

### 完成イメージ
このショートコードは、記事ファイルに次のように記述します。

```go
{{< message_box color="success" >}}
表示したいコメント
{{< /message_box >}}
```

* ショートコードの`{{</* message_box */>}}`〜`{{</* /message_box */>}}`で囲まれた内容をブロック内の文字列として出力します。
* 引数 `color` で色を指定します（`success`、`danger`、`warning` を指定可能とする）。

次のような HTML を生成します[^1]。
[^1]: 本来は、CSS 部分はクラスを定義して独自のスタイルシートファイルを読み込んだほうがよいですが、今回は割愛します。

```html
<div style="padding: 0.75em; margin-bottom: 1rem; color: #fff; background-color: #78c2ad; border: 1px solid transparent; border-radius: 0.25rem;">
  表示したいコメント
</div>
```

### テンプレートファイルの作成

1. `layouts/shortcodes` の下に、`message_box.html` を作成します。

    ```bash
    ├── ...
    ├── layouts
    │   ├── shortcodes
    │   │   └── message_box.html
    ├── ...
    ```

2. `message_box.html` に次の HTML を記述します。

    ```go
    {{- $color:= .Get "color" -}}
    {{- if not $color -}}
      {{ errorf "missing value for param 'color': ％s" .Position }}
    {{- end -}}
    {{- $bgcolor := "" -}}
    {{- if eq $color "success" -}}{{ $bgcolor = "#78c2ad" }}
    {{- else if eq $color "danger" -}}{{ $bgcolor = "#ff7851" }}
    {{- else if eq $color "warning" -}}{{ $bgcolor = "#ffce67" }}
    {{- else -}}{{ $bgcolor = "#6cc3d5" }}
    {{- end -}}
    <div style="padding: 0.75em; margin-bottom: 1rem; color: #fff; background-color: {{ $bgcolor }}; border: 1px solid transparent; border-radius: 0.25rem;">
      {{- .Inner -}}
    </div>
    ```

     * `{{ if 条件 }}` で `$color` の値に応じて、`$bgcolor` に値を設定します。
        * `if eq 値1 値2` で「値1と値2が等しければ」となります。
        * 一度定義した変数は `$変数名 = 値` で値を再代入できます。
     * `{{< ショートコード名 >}}`〜`{{< /ショートコード名 */>}}`で囲まれた内容の値は `{{ .Inner }}`で取得します。


HUGO で独自 Shortcode を作る

---
title: "HUGO のディレクトリ構成"
date: 2019-10-04T20:20:09+09:00
categories:
  - "開発"
tags:
  - HUGO
archives:
  - "2019/10"
menu:
  - "blog"
redirect_from:
  - /blog/2019/20191004_hugo-site-directory/
---

HUGO プロジェクトのディレクトリは、次のような構成になっています。
この記事では、HUGO プロジェクトのディレクトリの役割について説明します。

```bash
$ tree
.
├── archetypes
│   └── default.md
├── config.toml
├── content
├── data
├── layouts
├── static
└── themes
```

公式ドキュメントは、[Directory Structure](https://gohugo.io/getting-started/directory-structure/)を参照してください。

## archetypes
`hugo new` コマンドでコンテンツファイルを作ったときの Markdown のフォーマットです。
デフォルトでは、次の内容で作られます。

```markdown
++++
title: ファイル名と同じ
date: new コマンドを実行した日時
draft: true
++++
```

たとえば、タグをつける書式をデフォルトで設定したい場合は、次のように `archetypes/default.md` に追記します。

```markdown
++++
title: "{{ replace .Name "-" " " | title }}"
date: {{ .Date }}
draft: true
tags: [""] # 追記部分
++++
```

セクション名（`content` 次のディレクトリ名）ごとに、テンプレートを複数作ることもできます。

たとえば、`content` が次のような構造のとき、`blog` と `product` の下に配置する記事ファイルで、別々のテンプレートを利用したいというケースです。

```bash
├── ...
├── content
│   ├── news
│   │   └── 20191004_news.md
│   └── product
│       └── service_a.md
├── ...
```

この場合、`archetypes` の下に、セクション名を名前にもつファイル（例：`archetypes\news.md`）を用意します。

```bash
├── ...
├── archetypes
│   ├── news.md
│   └── product.md
├── ...
```

`hugo new news/20191005_news` として記事を作ると、その記事ファイルには`news.md` テンプレートが適用されます。

## assets
`hugo new site` したときには生成されません。
[Hugo Pipes](https://gohugo.io/hugo-pipes/) で処理するファイルを保存するためのディレクトリです。

たとえば scss ファイルを css ファイルにビルドしたい場合、ビルド対象の `.scss` ファイルをこのディレクトリに置きます。

## config.toml
[HUGO の設定ファイル](https://gohugo.io/getting-started/configuration/#all-configuration-settings)です。
TOML・YAML・JSON 形式で指定でき、デフォルトでは TOML 形式です。

## config

`hugo new site` したときには生成されません。
HUGO の設定ファイルが複数必要な場合、この `config` ディレクトリに設定ファイルを置きます。

## content

記事ファイルを置くディレクトリです。
`content` の下にサブディレクトリを作り、ブログのセクションを分けることができます。

```bash
├── ...
├── content
│   │   ├── news
│   │   └── 20191004_news.md
│   ├── product
│   └── blog
├── ...
```

## data
サイトの全ページから参照したいデータを記述したファイルを置くディレクトリです。
HUGO では、設定ファイル（`config.toml`）の `[Params]`に書くと、`{{ .Site.Params.variable }}` で参照できます。

しかし、データベースとしてサイトから参照したい情報を設定ファイルに保持すると、設定ファイルが煩雑化します。

そこで、data の下に TOML・YAML・JSON 形式のファイルを配置することで、[Data Template](https://gohugo.io/templates/data-templates/) として扱うことができます。
呼び出しは `{{ .Site.Data.ファイル名 }}` と記述します。

たとえば、次のような JSON ファイルを`./data/hitsong2019.json` に置いたとします。

```json
{
  "hits": [
    {
      "Title": "Lemon",
      "Artist": "米津玄師"
    },
    {
      "Title": "Flamingo",
      "Artist": "米津玄師"
    },
    {
      "Title": "マリーゴールド",
      "Artist": "あいみょん"
    }
  ]
}
```

テンプレートでは次のように書くと、ファイルの内容を参照できます。

```html
<ul>
  {{ range  .Site.Data.hitsong2019.hits }}
    <li>{{ .Title }} - {{ .Artist }} </li>
  {{ end }}
</ul>
```

## layouts
`themes` においたテーマファイルを一部修正したいときやレイアウトパーツを追加したいときに使います。
修正したいテンプレートファイルと同じ構成・ファイル名で `layouts` の下に配置すると、そのレイアウトファイルだけ独自に変更できます。

たとえば、記事ページ（`single.html`）のレイアウトを変更したい場合は、次のように行います。

まず、テーマでは、`テーマ/layouts/_default/single.html` という構成でファイルが配置されています。
プロジェクト直下でも同じように `./layouts/_default/single.html` に配置することで、記事ページのレイアウトを上書きできます。

```bash
├── ...
├── layouts
│   └── _default
│       └── single.html # 上書きするレイアウトファイル
├── static
└── themes
    └── theme-a
        ├── ...
        ├── layouts
        │   ├── _default
        │   │   ├── baseof.html
        │   │   ├── list.html
        │   │   └── single.html # 上書きしたいレイアウトファイル
        │   ├── partials
        │   ├── 404.html
        │   └── index.html
        ├── ...
```

## static
サイト内の静的ファイル（スタイルシート、JavaScript や画像ファイルなど）を配置するディレクトリです。
記事に画像を貼る場合も、このディレクトリの下に配置します。

`static` ディレクトリに配置したディレクトリ・ファイルは、サーバーを立ち上げたときのルートディレクトリ（`hugo` コマンドでビルドしたときの `public`ディレクトリ）に同じ構成で配置されます。

たとえば、次のような構成で `static` ディレクトリに配置するとします。

```bash
├── ...
├── static
│   ├─── img
│   │   └── image.png
│   └── me.png
├── ...
```

`static` 次のファイルは、それぞれ次のようにアクセスできます。

- https://{your-site-url}/img/image.png
- https://{your-site-url}/me.png


HUGO のディレクトリ構成

---
title: "HUGO で静的サイトを構築する"
date: 2019-09-30T20:49:11+09:00

tags:
  - HUGO
archives:
  - "2019/09"
menu:
  - "blog"
aliases:
  - "20190824_fitbit_cli"
redirect_from:
  - /blog/2019/20190930_hugo-quickstart/
---

[HUGO](https://gohugo.io/) は、静的な Web サイトを構築する静的サイトジェネレータのひとつです。

静的サイトジェネレータは、Markdown などで書かれたファイルと静的なコンテンツのテンプレートをビルドして HTML を生成します。

HUGO は Golang で作られており、他の静的サイトジェネレータに比べて、HTML への変換の早さが特徴です。
このブログも HUGO を使って作成しています。

この記事では、HUGO の [Quick Start](https://gohugo.io/getting-started/quick-start/) をもとに、 HUGOでのWeb サイト構築について説明します。

## 環境

* macOS Mojave 10.14.6
* Homebrew 2.1.11
* Git 2.23.0
* HUGO 0.58.2

## HUGO のインストール
ここでは、macOS へのインストール方法を説明します。
他の OS でのインストールは、[Install Hugo](https://gohugo.io/getting-started/installing/) を確認してください。

HUGO は Homebrew で提供されているため、`brew` コマンドでインストールします。

```bash
brew install hugo
```

バージョンを表示してインストールできたかを確認します。
次のように、バージョン番号が表示されれば成功です。

```bash
$ hugo version
Hugo Static Site Generator v0.58.2/extended darwin/amd64 BuildDate: unknown
```

## サイトの作成
`hugo new site` コマンドで、サイトのプロジェクトを作成します。今回は「hugo-example」という名前のサイトを作成します。

```bash
$ hugo new site hugo-example
Congratulations! Your new Hugo site is created in /Users/chick-p/Workspace/hugo-example.

Just a few more steps and you're ready to go:

1. Download a theme into the same-named folder.
   Choose a theme from https://themes.gohugo.io/ or
   create your own with the "hugo new theme <THEMENAME>" command.
2. Perhaps you want to add some content. You can add single files
   with "hugo new <SECTIONNAME>/<FILENAME>.<FORMAT>".
3. Start the built-in live server via "hugo server".

Visit https://gohugo.io/ for quickstart guide and full documentation.
```

`hugo-example` というディレクトリとその下にファイル群が作成されます。

```bash
$ tree hugo-example
hugo-example # ... HUGO のファイル群
├── archetypes
│   └── default.md
├── config.toml
├── content
├── data
├── layouts
├── static
└── themes
```

## テーマの追加
このままでは静的なコンテンツを生成するためのテンプレートファイルがなく、ビルドできないためテーマを追加します。

テーマファイルは自分で作ることもできますが、ここでは公開されているテーマのひとつ、Ananke theme を使います。
[Hugo Themes](https://themes.gohugo.io/)にさまざまなテーマが公開されています。

テーマは Git の submodule として追加します。

```bash
# HUGO プロジェクトのルートディレクトリに移動
cd hugo-example
# Git の初期化とコミット作成
git init
git add .
git commit -m "first commit"
# themes ディレクトリ以下に テーマファイルを追加
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke

# 確認
$ tree .
.
├── archetypes
│   └── default.md
├── config.toml
├── content
├── data
├── layouts
├── static
└── themes
    └── ananke # ... 追加したテーマ
```

プロジェクトのルートディレクトリ直下の設定ファイル `config.toml` にテーマの設定を追加します。

```bash
# テーマの設定
echo 'theme = "ananke"' >> config.toml
```

`config.toml` の中身です。`theme` にテーマ名を指定することで、ビルドするテーマを指定できます。

```toml
baseURL = "https://example.org/"
languageCode = "en-us"
title = "My New Hugo Site"
theme = "ananke"
```

## コンテンツファイルの追加
記事となるコンテンツファイルを追加します。

`content` ディレクトリの下に記事ファイルを追加します。
また
`hugo new セクション名/ファイル名` コマンドで、content ディレクトリの下にセクションのカテゴリを作り、ファイルを追加します。
`hugo new` コマンドで、`posts` というセクションでファイルを追加します。

```bash
# コンテンツファイルの作成
hugo new posts/my-first-posts.md

# 確認
$ tree .
.
├── ...
├── content
│   └── posts
│       └── my-first-posts.md # 追加したコンテンツファイル
├── ...
```

`content/posts/my-first-posts.md` の中身です。
記事の生成に必要な独自変数がついた形でファイルが生成されています。

```markdown
---
title: "My First posts"
date: 2019-09-30T20:49:11+09:00
draft: true
---
```

|変数名 |値
|:--|:--
|title |記事タイトル
|date |記事の日付
|draft |下書きフラグ

記事の内容は、こんな風に「---」（Front Matter）より下に追記していきます。

```markdown
---
title: "My First postss"
date: 2019-09-30T20:49:11+09:00
draft: true
---

## 概要
ここは概要です。
Markdown 形式で書いていけば、いい感じに記事ができます。
```

## ローカルサーバーでの確認
ローカルに HUGO サーバーを立ち上げ、サイトを確認します。

`-D` オプションを付けると、下書きの記事（`draft` が `true`のファイル）を含めてビルドします。

```bash
# サーバーの立ち上げ
hugo serve -D
```

`http://localhost:1313/` にアクセスし、サイトを確認します。
次のようなページが表示されれば成功です。
  ![](/hugo-quickstart/01.png)

## 静的ファイルの生成

次のコマンドで、`public` ディレクトリ直下に HTML ファイルを生成できます。

```bash
# 静的ファイルを生成
hugo

# 確認
$ tree .
.
├── ...
├── public
│   ├── 404.html
│   ├── categories
│   │   ├── index.html
│   │   └── index.xml
│   ├── dist
│   │   ├── css
│   │   │   └── app.d98f2eb6bcd1eaedb7edf166bd16af26.css
│   │   └── js
│   │       └── app.3fc0f988d21662902933.js
│   ├── images
│   │   └── gohugo-default-sample-hero-image.jpg
│   ├── index.html
│   ├── index.xml
│   ├── sitemap.xml
│   └── tags
│       ├── index.html
│       └── index.xml
├── ...
```

## まとめ
HUGO を使うとMarkdown 形式のファイルで記事を生成でき、かつローカルサーバーで動作確認できます。
生成した静的ファイル一式を S3 などのストレージサービスに配置しホスティングすれば、簡単にサイトを公開できます。


HUGO で静的サイトを構築する

Getting Started with the CLI に沿って、このコマンドラインツールを使ったプロジェクトの作成、既存プロジェクトの移行、ビルド、デプロイを行う方法を説明します。

---
title: "Fitbit アプリケーションをコマンドラインで開発する"
description: "Getting Started with the CLI に沿って、このコマンドラインツールを使ったプロジェクトの作成、既存プロジェクトの移行、ビルド、デプロイを行う方法を説明します。"
date: 2019-08-24T11:32:11+09:00
tags:
  - Fitbit
---

これまで、Fitbit で動くアプリケーションやクロックフェイス（文字盤）の開発は、Web アプリケーションの [Fitbit Studio](https://studio.fitbit.com/)で行っていました。

Web UI 上からしか Fitbit のアプリケーションを開発できないと思っていたのですが、Fitbit のコマンドラインツールがあることを知りました。
今回は、[Getting Started with the CLI](https://dev.fitbit.com/build/guides/command-line-interface/#getting-started-with-the-cli)に沿って、このコマンドラインツールを使ったプロジェクトの作成、既存プロジェクトの移行、ビルド、デプロイを行います。

## 環境

* macOS Mojave 10.14.6
* Node.js v12.1.0（8 系以上が必要）
* npm v6.11.2

## プロジェクトの作成

`npx` で実行するので明示的なパッケージインストールは不要です。

1. 作業ディレクトリに移動します。

    ```bash
    cd workspace
    ```

2. 次のコマンドでプロジェクトを生成します。

    ```bash
    npx create-fitbit-app <プロジェクト名>
    ```

    これを実行すると、プロジェクト名と同名のディレクトリが生成されます。
    また、`node_modules` の下に `@fitbit/sdk` や `@fitbit/sdk-cli` を含めた必要なパッケージがインストールされます。

3. 質問形式で設定を聞かれるので、設定していきます。

    * 開発対象（アプリケーション or クロックフェイス）です。

        ```bash
        ? What type of application should be created? (Use arrow keys)
        ❯ app
          clockface
        ```

    * アプリケーション名です。

        ```bash
        ? What should the name of this application be?
        ```

    * [Companion](https://dev.fitbit.com/build/guides/companion/) コンポーネントの要否です（スマートフォン側の設定画面を作る場合や、外部 API を実行する場合など、Fitbit とスマートフォン間で通信する場合に必要となります）。

        ```bash
        ? Should this application contain a companion component?
        ```

    * [設定画面](https://dev.fitbit.com/build/guides/settings/)コンポーネントの要否です。

        ```bash
        ? Should this application contain a settings component?
        ```

    * アプリケーションを動かす端末（複数選択可）です。

        ```bash
        ? Which platforms should this application be built for? (Press <space> to select, <a> to toggle all, <i> to invert selection)
        ❯ ◉ Fitbit Ionic
          ◉ Fitbit Versa
          ◉ Fitbit Versa Lite
        ```

4. 必要なファイル群が生成されます。

    ```bash
    $ tree
    .
    ├── app
    │   └── index.js
    ├── companion
    │   └── index.js
    ├── node_modules
    ├── package.json
    ├── resources
    │   ├── index.gui
    │   ├── styles.css
    │   └── widgets.gui
    ├── tsconfig.json
    └── yarn.lock
    ```

## 既存のプロジェクトを CLI で開発する

1. Fitbit Studio でプロジェクトを開きます。

2. 上部メニューの[Download]から[Export project]を選択します。zip 圧縮されたプロジェクトがダウンロードできます。

3. 圧縮ファイルを展開します。

4. ディレクトリ直下に移動し、次のコマンドを実行します。

      ```bash
      npm i @fitbit/sdk --save-dev
      npm i @fitbit/sdk-cli --save-dev
      ```

    * `@fitbit/sdk` はもともと含まれていますが、バージョンを最新化します。

## プロジェクトのビルド

1. 次のコマンドを実行します。

    ```bash
    npx fitbit-build
    ```

2. Fitbit の Developer アカウントへの認証を要求されるので、ログインします。

3. `build` ディレクトリとともに生成物（`app.fba`）が作られます。

### 補足

* `npx fitbit` で Fitbit CLI を起動し、`build` コマンドでもビルドできます。
  Fitbit CLI を起動した時点でログインしていなければブラウザが起動し、ログインが求められます。

    ```bash
    $ npx fitbit
    Logged in as chick-p <chick-p@example.com>
    # fitbit シェルが立ち上がる
    fitbit$ build
    ```

* Fitbit シェルを抜けるには `exit` を実行します。

    ```bash
    fitbit$ exit
    ```

* アプリケーション ID の発行は、次のコマンドで行います。

    ```bash
    npx fitbit-build generate-appid
    ```

    または Fitbit シェルを立ち上げ、`build generate-appid` を実行します。

    ```bash
    $ npx fitbit
    fitbit$ build generate-appid
    ```

## シミュレーターへのデプロイ

1. [fitbit OS Simulator](https://dev.fitbit.com/release-notes/fitbit-os-simulator/)を起動しておきます。

2. Fitbit シェルを立ち上げ、`install` を実行します。

    ```bash
    $ npx fitbit
    fitbit$ install

    # No app package specified. Reloading ./build/app.fba.
    # Loaded appID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx buildID:xxxxxxxx
    # App requires a device, connecting...
    # Auto-connecting only known device: Versa Simulator
    # App requires a phone, connecting...
    # Auto-connecting only known phone: Simulator
    # App install complete (full)
    # Companion install complete (full)
    # Launching app
    # アプリの起動ログが続きます....
    ```

    ビルドとインストールを同時に行う場合は、次のコマンドを実行します。

    ```bash
    $ npx fitbit
    fitbit$ bi
    ```

## 端末へのデプロイ

1. Fitbit シェルを起動します。

    ```bash
    npx fitbit
    ```

2. スマートフォンの Fitbit アプリケーションで[開発者メニュー]から、「Developer Brige」を ON にします。

3. Fitbit の「設定」アプリケーションで、「Developer Brige」を「Connecting Server」から「Connetcted Server」状態に変更します。

4. `connect xxx` を実行して、Phone と Versa 本体に接続します。

    ```bash
    fitbit$ connect phone
    Auto-connecting only known phone: chick-p iPhone

    fitbit$ connect device
    Auto-connecting only known phone: chick-p Versa
    ```

5. `install` を実行してデプロイします。

    ```bash
    fitbit$ install

    # No app package specified. Using default ./build/app.fba.
    # Loaded appID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx buildID:xxxxxxxx
    # App requires a device, connecting...
    # Auto-connecting only known device: Versa
    # App install complete (full)
    # Companion install complete (full)
    # Launching app
    # アプリの起動ログが続きます....
    ```

## まとめ
CLI でビルド・デプロイできるようになったので、好きなコードエディタで開発できます。
また、npm パッケージも利用できるので、ESLint での構文チェックもできるようになりました。


Fitbit アプリケーションをコマンドラインで開発する

---
title: Visual Studio Code 拡張 VSNotes でメモをとる
date: 2019-05-28T21:22:21+09:00
tags:
  - Visual Studio Code
redirect_from:
  - /blog/2019/20190528_vsnote-template/
---

Visual Studio Code のメモ帳用拡張機能である [VSNotes](https://marketplace.visualstudio.com/items?itemName=patricklee.vsnotes) が便利です。

## VSNotes を使うと便利になること

* 左メニューに常時「VS Notes」のアイコンが表示され、メモへすぐにアクセスできる。
* タグを打つことができ、タグ検索ができる。
* ファイル名の付け方ルールを設定できる。
* VSCode Snipet を使うと、テンプレートを利用してファイルを作成できる。

## 必要なもの

* Visual Studio Code

## 初期設定
### VSNotes のインストール

1. Visual Studio Code で拡張機能のメニューを開きます。
2. 検索窓に「VSNotes」と検索して、VSNotes をインストールします。

### メモの保存先の設定

1. `Shift` + `Ctr`(`Command`) + `P` でコマンドパレットを開き、「vsnotes run」と入力します。
2. 「VSNotes: Run setup」が補完されるので、Enter キーで確定します。右下にダイアログが表示されます。
3. [start] ボタンをクリックします。ファイルダイアログが表示されます。
4. メモファイルを保存したいルートディレクトリを指定します。Dropbox などのネットワークディレクトリも設定できます。
5. VS Code を再起動します。左メニューに VSNote のアイコンが表示されます。
  ![](/vsnote-template/01.png)
6. アイコンを選択すると VSNotes のエクスプローラが表示されます。
  ![](/vsnote-template/02.png)
  VSNotes を使ってメモを作成すると、先ほど指定したディレクトリにファイルが保存され、VSNotes のエクスプローラにファイルがツリー表示されます。

## VSNotes の使い方

1. `Shift` + `Ctr`(`Command`) + `P` でコマンドパレットを開き、「vsnote create」と入力します。
2. 「VSNotes: Creat a New Note」と補完されるので、Enter キーで確定します。
3. ファイル名の入力を求められるので入力します。ファイル拡張子は不要です。
4. 初期状態では、次の内容でメモファイルが作成されます。ファイル名は `yyyy-MM-dd_HH-mm_3.でつけた名前.md` です。

    ```markdown
    ---
    tags:
      -
    ---

    ```

5. `tag` の部分に `* タグ名` を指定すると、VSNotes のエクスプローラにタグが表示され、同じタグがついたファイルにアクセスできます。反映されないときは更新マークをクリックします。

    ```markdown
    ---
    tags:
      - meeting-notes
    ---

    # レベル1
    ## レベル2
    Markdown 形式で書く
    ```

  ![](/vsnote-template/03.png)

## 設定変更
### デフォルトのファイル名の変更
ファイル名のデフォルトは、`yyyy-MM-dd_HH-mm_パレットで指定した名前.md` です。これを `yyyy-MM-dd パレットで指定した名前.md`に変更します。

#### 手順

1. `Shift` + `Ctr`(`Command`) + `P` でコマンドパレットを開き、「setting」と入力します。「Preferences: Open User Settings」と補完されるので、Enter キーで確定します。
2. 設定右上の「`{}`」マークをクリックし、`setting.json` を開きます。
3. 次の内容を追記して、保存します。
```json
"vsnotes.noteTitleConvertSpaces": " ",
"vsnotes.defaultNoteTitle": "{dt} {title}.{ext}",
"vsnotes.tokens": [
  {
    "type": "datetime",
    "token": "{dt}",
    "format": "YYYY-MM-DD",
    "description": "Insert formatted datetime."
  },
  {
    "type": "title",
    "token": "{title}",
    "description": "Insert note title from input box.",
    "format": "Untitled"
  },
  {
    "type": "extension",
    "token": "{ext}",
    "description": "Insert file extension.",
    "format": "md"
  }
],
```

これで、コマンドパレットから「VSNotes: Creat a New Note」したときに生成されるファイル名が `yyyy-MM-dd パレットで指定した名前.md`になります。

### ファイルのテンプレートの変更
ファイルを生成したときのテンプレートを作成します。
今回、議事録テンプレートとして、次の内容のテンプレートを作成します。

```markdown
---
tags:
  * meeting-notes
---

# yyyy-MM-dd パレットで指定した名前
##
```

#### 手順

1. [Code]> [基本設定] > [ユーザースニペット] を選択します。
2. 検索窓に [Markdown] と入力します。`markdown.json [Markdown]` と補完されるので、Enter キーで確定します。
3. `{ ... }` 内に、次の内容を追記して保存します。
    ```json
    "vsnote_template_mtg": {
      "prefix": "vsnote_template_mtg",
      "body": [
        "---",
        "tags:",
        "\t* meeting-notes",
        "---",
        "\n# $TM_FILENAME_BASE\n",
        "$1",
      ],
      "description": "Meeting Template",
    }
    ```

    * テンプレート名にあたるキーは `vsnote_template_` から始まる必要があります（2019/09/25 追記）

4. `Shift` + `Ctr`(`Command`) + `P` でコマンドパレットを開き、「setting」と入力します。「Preferences: Open User Settings」と補完されるので、Enter キーで確定します。
5. 設定右上の「`{}`」マークをクリックし、`setting.json` を開きます。
6. 次の内容を追記し、保存します。
  ```json
    "vsnotes.templates": [
      "mtg",
    ],
  ```

### 動作確認
コマンドパレットから「VSNotes: Creat a New Note」したとき「mtg」が一覧から選べます。選択して Enter キーで確定します。
あとはファイル名を入力すると、スニペットに指定したテンプレートでファイルが作成されます。
  ![](/vsnote-template/04.png)

## 補足

* `datetime` の `format`の書式は、[Moment.js](https://momentjs.com/) のフォーマットに従います。
* `markdown.json`は VSCode の snippet 機能です。使える変数は[Creating your own snippets * Variables](https://code.visualstudio.com/docs/editor/userdefinedsnippets#_variables) を参照のこと。
* 同じように `markdown.json` にスニペットを定義して `settings.json` の `vsnotes.templates` に指定すれば複数のテンプレート登録が可能です。


Visual Studio Code 拡張 VSNotes でメモをとる

---
title: スマートロックデバイスの SESAME を Fitbit Versa で操作する
date: 2019-05-17T15:00:00+09:00
thumbnail: "../img/20190517_sesame-fitbit-app_01.png"

tags:
  - Fitbit
  - IoT
  - SESAME
archives:
  - "2019/05"
menu:
  - "blog"
aliases:
  - "20190824_fitbit_cli"
redirect_from:
  - /blog/2019/20190517_sesame-fitbit-app/
---

先日、CANDY HOUSE 製スマートロック [SESAME mini（セサミ mini）](https://jp.candyhouse.co)を購入・設置しました。

スマートロックと呼ばれるデバイスは各社からいろいろと発売されていますが、SESAME を選んだのは、Webhook や API を利用できるからです。

この API を利用して、いつも身につけている[Fitbit Versa](https://www.fitbit.com/jp/versa)で、鍵の施錠状態の確認や鍵を開け締めするアプリケーションを作りました。  
[GitHub | sesame-for-fitbit-versa](https://github.com/chick-p/sesame-for-fitbit-versa)

実際の端末で動作確認はしていませんが、 Fitbit Versa Lite でも動くはずです。

> **2019年5月18日追記**
> * 鍵が空いている状態・閉じている状態の色が、公式と逆だったので合わせました。
> * アプリが起動した直後に操作すると、Fitbit とスマートフォン間の通信がうまくいかないことがありました。準備画面を表示して待つようにしました。
> * 鍵の状態取得・鍵の解施錠中は、ボタンを押せないようにしました。

## イメージ

![](/sesame-fitbit-app/01.png)

* 右上のボタン：鍵の状態を取得する
* 左下のボタン：鍵を開ける
* 右下のボタン：鍵を閉める

アプリケーションを起動したときも、鍵の状態を取得するようにしています。

## 使い方
### Step1: API トークンとデバイス ID の取得
[SESAME のドキュメント](https://docs.candyhouse.co/#introduction)にもありますが、API トークンはオーナーアカウントで発行する必要があります。

> Please note that in order to enable API for your Sesame, you must be the owner of Sesame and have it paired with the Wi-Fi Access Point.

1. [CANDY HOUSE Dashboard](https://my.candyhouse.co/) にログインし、左メニューの[API Settings]を選択します。
2. [SEND CODE]ボタンをクリックします。アカウントに紐づけているメールアドレスに Verification Code が届きます。
3. Verification Code をフォームに入力し、[CONFIRM]ボタンをクリックすると、API トークンが発行されます。
4. ターミナルで、次のコマンドを実行します。`YOUR-SESAME-AUTH-TOKEN` は取得した API トークンに置き換えてください。

    ```bash
    curl -H "Authorization: YOUR-SESAME-AUTH-TOKEN" https://api.candyhouse.co/public/sesames
    ```

    こんな感じのJSONが返ってきます。`device_id` の部分がデバイスIDです。

    ```json
    [
      {
        "device_id": "00000000-0000-0000-0000-000000000000",
        "serial": "ABCDEFGHIJK",
        "nickname": "HIRAKE GOMA",
      }
    ]
    ```

### Step2: API トークンの有効化
[このページ](https://docs.candyhouse.co/#before-you-start)の「Before You Start」の 3. にあるように、スマートフォンのアプリケーションで、API を有効化します。

### Step3: Fitbit へのデプロイ

1. [GitHub リポジトリ](https://github.com/chick-p/sesame-for-fitbit-versa)からソースコードを clone または zip でダウンロードします。
2. [Fitbit Studio](https://studio.fitbit.com) にログインし、新規プロジェクトを作成します。名前は適当にどうぞ。
3. プロジェクトの左サイドバーに、1. で取得したソースコードの `src` 次のファイルをドラッグして取り込みます。
4. `companion/sesame/sesame.js` を開いて、以下を置き換えます。
    * `{YOUR-SESAME-AUTH-TOKEN}`: SESAME の API トークン
    * `{YOUR-SESAME-DEVICE-ID}`: SESAME のデバイスID
5. [Build]ボタンをクリックし、ビルドします。
6. Fitbit にデプロイします。以下は簡略的な手順です。Android の手順については[こちら](https://dev.fitbit.com/getting-started/)を確認してください。
    * iPhone
      1. 「Fitbit」アプリケーションを開き、左上のデバイスを選択する。
      2. [開発者メニュー]を選択し、「Developer Brige」を ON にする。
    * Versa
      1. Fitbit Versa の設定を開く。
      2. 「Developer Brige」を「Connecting Server」から「Connetcted Server」状態に変更する。
    * デプロイ
      1. Fitbit Studio の上メニューで、[Select a phone / a device]を選択する。
      2. 一覧に表示される iPhone のデバイス名を選択し、接続する。
      3. 同じく、一覧に表示される Versa を選択し、接続する。
      4. [Run]ボタンをクリックし、デプロイする。
    * 後始末
    iPhone / Versa いずれも「Developer Brige」を OFFにする（Versa の場合は、タップして「Disconnected」にする）。

以上。

## 所感

* 「鍵ちゃんとしめたかな」と不安になって戻らなくて済むので、スマートロックはとてもよいです。
* SESAME は「API があること」が他社製品に比べた強みだと思っています。先日バズっていた[こちらの記事](https://blog.lorentzca.me/monitor-lock-status-with-mackerel/)のように何かの形で可視化してみたいです。
* API/Webhook については、以下が改善されるとより使いやすいと思っています。
  * API を利用できるのはオーナーアカウントのみ。
    * 家族が API を使ってロック解除したときに、オーナーが開けたことになるので正確なログがとれません。人別に家を出入りした時間を記録したいです。
  * Webhook で取得できる情報が少ない。
    * 現状だと、デバイスIDとステータス（鍵の状態）のみなので、「誰が」「何経由で」鍵を操作したかがほしいです。これをトリガーに他のスマート家電を操作できるとよいですね。


スマートロックデバイスの SESAME を Fitbit Versa で操作する

---
title: Node-RED から kintone のレコードを操作するノード（node-red-contrib-kintone）を作った
date: 2019-05-11T22:33:11+09:00

tags:
  - Node-RED
  - kintone
archives:
  - "2019/05"
menu:
  - "blog"
redirect_from:
  - /blog/2019/20190511_node-red-contrib-kintone/
---

[Node-RED](https://nodered.org/) から [kintone](https://kintone.cybozu.com/) のレコードを操作するノード（非公式）を作成しました。

この記事では、[node-red-conrib-kintone](https://flows.nodered.org/node/node-red-contrib-kintone)（以降、kintone ノード）の追加方法と、利用例を説明します。

## kintone ノード

kintone ノードでは、kintone レコードを取得（GET）、登録（POST）または更新（PUT）ができます。

ノードのプロパティで、kintone 環境の情報、操作するメソッドやリクエストパラメータを指定します。下図は、メソッドが GET の場合のプロパティです。
![](/node-red-contrib-kintone/02.png)

内部的には、kintone REST API の `/k/v1/records.json` を呼び出しているため、ノードに指定するプロパティは、次の API 仕様にしたがっています。

* GET: [レコードの一括取得](https://developer.cybozu.io/hc/ja/articles/202331474#step2)
* POST: [レコードの一括登録](https://developer.cybozu.io/hc/ja/articles/202166160#step2)
* PUT: [レコードの一括更新](https://developer.cybozu.io/hc/ja/articles/201941784#step2)

kintone への接続情報（ドメイン、kintone のログイン名、ログインパスワード）は、ノードの鉛筆マークから設定します。
![](/node-red-contrib-kintone/01.png)

## kintone ノードの追加方法

公式の[ノードの追加](https://nodered.jp/docs/getting-started/adding-nodes)にあるとおり、次のいずれかの方法で追加します。

### Node-RED の画面から追加

1. 右上のメニューをクリックし、[パレットの管理]を選択します。
2. [ノードを追加]タブをクリックし、「kintone」と検索します。
3. 「node-red-contrib-kintone」の[ノードを追加]ボタンをクリックします。
![](/node-red-contrib-kintone/03.png)
4. 確認ダイアログが表示されるので、[追加]ボタンをクリックします。

### npm install で追加

Node-RED のユーザーディレクトリ（`~/.node-red`）にインストールします。

```bash
cd ~/.node-red
npm install node-red-contrib-kintone
```

## 利用例（POST）

定期的にセンサから取得した値を kintone へレコード登録するフローを作成します。

### 完成イメージ

フローの大まかな流れは下図のとおりです。

1. Node-RED の http request ノードで、センサの REST API を実行し、センシングデータを取得する。
2. 取得したセンシングデータを kintone のレコード形式に整形する。
3. kintone ノードを使って kintone に POST する。

![](/node-red-contrib-kintone/04.png)

### フローの作成

1. 次のノードをエディタ上に追加します。

    |ノード |概要
    |:--|:--
    |inject（タイムスタンプ） |ノードが発火するタイミングを指定する。今回は定期実行なのでタイムスタンプノードを用いる。
    |http request |センサのデータを取得するため、REST API を実行するノード。
    |function |「http request」で取得したデータを kintone [レコード一括登録 API](https://developer.cybozu.io/hc/ja/articles/202166160#step2) のリクエストパラメータ（records）に整形する。
    |kintone |「function」で整形したデータを kintone に登録する。
    |debug（msg.payload） |kintone からのレスポンス結果をデバッグ出力する。

2. それぞれのノードを次のように設定します。
    * inject（タイムスタンプ）

        |プロパティ |値
        |:--|:--
        |ペイロード |日時
        |繰り返し |指定した時間間隔、日時。時間間隔、曜日、時間は任意。

    * http request

        |プロパティ |値
        |:--|:--
        |メソッド |GET
        |URL |センシングデータを取得する API
        |認証 |API の認証方式に従う
        |出力形式 |JSON オブジェクト

    * function

        |プロパティ |値
        |:--|:--
        |コード |下記参照。

        データが入っているオブジェクトはセンシングデータを取得する APIの仕様によるので API の仕様に合わせること。重要なのは、次の2つです。
        * `msg.payload` が **kintone [レコード一括登録 API](https://developer.cybozu.io/hc/ja/articles/202166160#step2) のリクエストパラメータ（records）の形式になっている**こと
        * **`return msg` で `msg` の内容を次の kintone ノードに渡している**こと。

        ```javascript
        var date = new Date();
        var sensor = msg.payload.<データオブジェクト>;

        msg.payload = [
          {
            "date": { "value": date},
            "temp": { "value": sensor.temp },
            "co2": { "value": sensor.co2 },
            "humid": { "value": sensor.humid },
            "dust": { "value": sensor.dust}
          }
        ];
        return msg;
        ```

    * **kintone**

        ![](/node-red-contrib-kintone/05.png)

        |プロパティ |値
        |:--|:--
        |設定 |ノードの鉛筆マークから、追加したい kintone の環境を設定する
        |メソッド |POST
        |アプリケーション ID |データを登録する kintone のアプリケーションID
        |レコード |空の場合、前のノードの`msg.payload`の値を用いるので、**空白にする**

    * デバッグ

        |プロパティ |値
        |:--|:--
        |対象 |msg.payload
        |出力先 |デバッグウィンドウ

3. ノードを下図のように接続します。
  ![](06.png)
4. 右上の[デプロイ]ボタンをクリックしてデプロイします。

### 動作確認

1. `inject`（タイムスタンプ）ノードの[■]ボタンをクリックして実行します。
2. 実行後、レスポンスがデバッグウィンドウに表示されます。
  ![](07.png)
    kintone にもレコードが登録されています。
  ![](08.png)

以上。


Node-RED から kintone のレコードを操作するノード（node-red-contrib-kintone）を作った

Kibela Web API の Google Apps Script での実行方法を説明します。

---
title: Kibela API を Google Apps Script で実行する
description: "Kibela Web API の Google Apps Script での実行方法を説明します。"
date: 2019-04-23T21:34:58+09:00
tags:
  - Kibela API
  - Google Apps Script
  - clasp
  - GraphQL
---

## 概要

[Kibela Web API のベータ版](https://github.com/kibela/kibela-api-v1-document)が公開されました。
Kibela Web API は GraphQL で提供されています。

この記事では、Kibela Web API の Google Apps Script での実行方法を説明します。なお、Google Apps Script のスクリプトは clasp を利用して作成します。

## 必要なもの

* Kibela アカウント
* Google アカウント（Google Apps Script）
* clasp 実行環境
  * 実行環境の構築方法は「[clasp を使って Google Apps Script のスクリプトを作成する](../img/2019/20190423_clasp/)」を参照のこと。

## Kibela アクセストークンの取得

1. 右上のユーザーアイコンから、[設定] > [個人用アクセストークン]を開きます。
2. [アクセストークンの生成]ボタンをクリックし、タイトルとアクセス権限を設定して[作成]ボタンをクリックします。
3. アクセストークンが表示されます。アクセストークンはこれ以降表示されないので、コピーして控えておいてください。

## クエリについて
リクエストボディで、`query` パラメータに対して取得したいリソースのオブジェクトを指定します。
[API コンソール](https://my.kibe.la/api/console) を開き、右側の[Docs]メニューよりオブジェクトの定義を確認できる。

今回は次のクエリで、ログインユーザー（Kibela アクセストークンの発行ユーザー）の最新記事一覧を1000件取得します。
```graphql
{
  currentUser {
    latestNotes(first: 1000) {
      edges {
        node { title }
      }
    }
  }
}
```

## Google Apps Script の作成

1. clasp でGoogle Apps Script プロジェクトを作成します。詳細は「[clasp を使って Google Apps Script のスクリプトを作成する](../img/2019/20190423_clasp/)」を参照のこと。

2. `index.ts`に、次のコードを貼り付けます。
```typescript
function main(): void {
  const token = PropertiesService.getScriptProperties().getProperty('KIBELA_API_TOKEN') || '';
  const team = PropertiesService.getScriptProperties().getProperty('KIBELA_TEAM') || '';
  const endpoint = `https://${team}.kibe.la/api/v1`;

  const graphql = `
  {
    currentUser {
      latestNotes(first: 1000) {
        edges {
          node { title }
        }
      }
    }
  }`;

  const option: GoogleAppsScript.URL_Fetch.URLFetchRequestOptions = {
    method: 'get',
    contentType: 'application/json',
    headers: {
      Accept: 'application/json',
      Authorization: `bearer ${token}`,
    },
    payload: JSON.stringify({ query: graphql }),
  };

  const res = UrlFetchApp.fetch(endpoint, option);
  const json = JSON.parse(res.getContentText());
  Logger.log(json);
}
```

3. クラウドの GAS プロジェクトを開き、スクリプトのプロパティを設定します。  [ファイル] > [プロジェクトのプロパティ]を開きます。[スクリプトのプロパティ]タブより次のプロパティを追加します。

   * KIBELA_API_TOKEN: 取得したKibela アクセストークン
   * KIBELA_TEAM: Kibela チーム名

4. `clasp push`コマンドでクラウドの GAS プロジェクトへアップロードします。
5. クラウドの GAS プロジェクトを開きます。`main`関数を実行すると、Kibela Web API での取得結果がログに出力されます。ログは、[表示]>[ログ]より確認できます。

以上。


Kibela API を Google Apps Script で実行する

---
title: "clasp を使って Google Apps Script のスクリプトを作成する"
date: 2019-04-23T20:11:40+09:00

tags:
  - Google Apps Script
  - clasp
archives:
  - "2019/04"
menu:
  - "blog"
redirect_from:
  - /blog/2019/20190423_clasp/
---

[clasp](https://github.com/google/clasp) は Google ドライブにある Google Apps Script プロジェクトを操作できる CLI ツールです。

clasp で Google Apps Script（以降、GAS）を扱うメリットは次のとおり。

* ローカルでファイルを作成するので、Git 管理できる。
* TypeScript をサポートしており（v1.5.0 より対応）、ES2015 で書ける。

この記事では、`clasp` を利用して GAS のスクリプトファイルを TypeScript で作成しアップロードする手順を説明します。

## 環境

* Node.js v8.15.1
* clasp v2.1.0

## clasp のインストールとログイン

1. 次のコマンドを実行し、clasp をインストールします。

  ```bash
  $ npm i @google/clasp -g
  Installed @google/clasp@2.1.0
  ```

2. Google アカウントにログインします。次のコマンドを実行すると、ブラウザが立ち上がります。Google アカウントへのログインを要求されるのでログインします。

    ```bash
    $ clasp login
    Logging in globally...
    🔑 Authorize clasp by visiting this url:
    https://accounts.google.com/xxx

    Authorization successful.
    ```

2. Google Apps Script APIを有効化します。
   1. [Google Apps Script のユーザー設定](https://script.google.com/home/usersettings)を開きます。
   2. [Google Apps Script API]をクリックし、オンに設定します。

## プロジェクトの作成

1. `clasp create` コマンドでプロジェクトを作成する。
コマンド実行後、プロジェクトの種類を選択します。今回はスクリプトファイルのみのため、「standalone」を選択します。

```bash
mkdir sample
cd sample

$ clasp create sample
? Clone which script? (Use arrow keys)
❯ standalone
  docs
  sheets
  slides
  forms
  webapp
  api

Created new standalone script: https://script.google.com/d/xxxxx/edit
Cloned 1 file.
└─ appsscript.json
```

`appsscript.json` が作成されます。

2. `npm init` で初期化します。
  基本的に Enter キーでスキップしますが、`entry point`のときだけ、「`index.ts`」と入力しておきます。
  最後に `Is this OK? (yes)` と尋ねられるので、「`yes`」と入力します。

    ```bash
    $ npm init
    Press ^C at any time to quit.
    package name: (sample)
    version: (1.0.0)
    description:
    entry point: (index.js) index.ts
    test command:
    git repository:
    keywords:
    author:
    license: (ISC)
    About to write to /Users/chick-p/workspace/sample/package.json:

    {
      "name": "sample",
      "version": "1.0.0",
      "description": "",
      "main": "index.ts",
      "dependencies": {},
      "devDependencies": {},
      "scripts": {
        "test": "echo \"Error: no test specified\" && exit 1"
      },
      "author": "",
      "license": "ISC"
    }

    Is this OK? (yes) yes
    ```

3. GAS の型定義ファイルをインストールします。

    ```bash
    npm i @types/google-apps-script --save-dev
    ```

4. スクリプトファイルを作成します。

    ```bash
    vim index.ts
    ```

    ```typescript
    // index.ts
    function main() {
      console.log('Hello World');
    }
    ```

5. `clasp push`コマンドで、クラウドの GAS プロジェクトへアップロードします。

    ```bash
    clasp push
    ```

## 確認
クラウドの GAS プロジェクトを確認すると、GAS フォーマットに変換されたファイル（`index.gs`）がアップロードされています。

```javascript
// index.gs
// Compiled using ts2gas 1.6.2 (TypeScript 3.4.4)
var exports = exports || {};
var module = module || { exports: exports };
function main() {
  console.log('Hello World');
}
```

以上。


clasp を使って Google Apps Script のスクリプトを作成する

---
title: macOS で pg gem を利用する
date: 2019-04-18T20:19:38+09:00

tags:
  - Rails
  - PostgreSQL
archives:
  - "2019/04"
menu:
  - "blog"
aliases:
  - "20190418_pg-gem_on_macos"
redirect_from:
  - /blog/2019/20190418_pg-gem-on-macos/
---

macOS で pg gem を bundle すると、「pg_config がない」と失敗します。
この解決策について記述します。

## 環境

* macOS 10.14.3
* Ruby 2.6.2
* Bundler version 2.0.1
* PostgreSQL.app 11

## エラーメッセージ

```bash
Fetching pg 1.1.4
Installing pg 1.1.4 with native extensions
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

    current directory: /Users/chick-p/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/pg-1.1.4/ext
/Users/chick-p/.rbenv/versions/2.6.2/bin/ruby -I /Users/chick-p/.rbenv/versions/2.6.2/lib/ruby/2.6.0 -r
./siteconf20190418-22299-193ha91.rb extconf.rb
checking for pg_config... no
No pg_config... trying anyway. If building fails, please try again with
 --with-pg-config=/path/to/pg_config
checking for libpq-fe.h... no
Can't find the 'libpq-fe.h header
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:

...(略)...

An error occurred while installing pg (1.1.4), and Bundler cannot continue.
Make sure that `gem install pg -v '1.1.4' --source 'https://rubygems.org/'` succeeds before bundling.

In Gemfile:
  pg
```

## 解決策
bundle のビルドオプションを指定します。
なお、PosgreSQL は、[Postgresql.app](https://postgresapp.com/)を Application ディレクトリに入れて利用しています。

```bash
bundle config build.pg --with-pg-config=/Applications/Postgres.app/Contents/Versions/latest/bin/pg_config
bundle
```

## 参考 URL

* [Mac OS X で 'pg' を含む Gemfile を bundle install する方法](https://mallowlabs.hatenablog.com/entry/20120806/mac_pg_gem)


macOS で pg gem を利用する

---
title: "Rails 5.x で Bootswatch 4.x gem を利用する"
date: 2019-03-23T21:38:58+09:00

tags:
  - Rails
  - Bootstrap
  - Bootswatch
archives:
  - "2019/03"
menu:
  - "blog"
aliases:
  - "20190323_rails_bootswatch4-gem"
redirect_from:
  - /blog/2019/20190323_rails-bootswatch4-gem/
---

Rails アプリケーションを作るにあたり、手っ取り早く見た目をよい感じにするため、[Bootstrap](https://getbootstrap.com/) を適用しました。
そのままでは Bootstrap 感があるので、Bootstrap に適用できるテーマ [Bootswatch](https://bootswatch.com/) を利用します。

この記事では、Rails 5.x 系に対して、Bootswatch 4.x gem を適用する方法を記載しています。

## 環境

* Rails 5.2.2.1
* Bootstrap gem 4.3.1
* Bootswatch gem 4.3.1

## 手順

[bootswatch-rails](https://rubygems.org/gems/bootswatch-rails) は、 Bootswatch 3.x 系なので、[bootswatch](https://rubygems.org/gems/bootswatch) を利用します。

1. Gemfile に以下を記述して、`bundle` します。
    ```ruby
    gem 'bootstrap'
    gem 'bootswatch'
    gem 'jquery-rails'
    ```

2. `app/assets/stylesheets` 下の `application.css` をリネームし、 `application.scss` とします。

    ```bash
    mv app/assets/stylesheets/application.css app/assets/stylesheets/application.scss
    ```

3. 先ほどの `application.scss` に以下を追記して、テーマを適用します。

    ```scss
    @import "bootswatch/[theme]/variables";
    @import "bootstrap";
    @import "bootswatch/[theme]/bootswatch";
    ```

    * `[theme]` は利用したいテーマ名。

4. `app/assets/javascripts/` 下の `application.js` に以下を追記して、 JavaScript が動くようにします。

    ```javascript
    //= require jquery
    //= require bootstrap-sprockets
    ```

以上。

あとは、HTML を Bootstrap に合わせれば、Bootswatch のテーマが適用されます。
![](/rails-bootswatch4/01.png)

上図では、[Minty](https://bootswatch.com/minty/) というテーマを適用しています。


Rails 5.x で Bootswatch 4.x gem を利用する

---
title: Visual Studio Code と textlint で文章を校正する
date: 2019-03-01T21:34:40+09:00
images: ["images/cover.jpg"]
tags:
  - textlint
  - Visual Studio Code
---

[textlint](https://github.com/azu/textlint) は、テキストを校正するためのコマンドラインツールです。
textlint では、文章をチェックする「ルール」を導入して、ルールに反した文章をチェックします。

類似のテキスト校正チェックツールに RedPen があります。

サイトを構築してブログを書くにあたり、おかしな日本語は避けたいので、textlint を導入しました。
また、ブログを書くエディタに Visual Studio Code（VS Code）を使っているので、VS Code 上で textlint を動作させる方法を記載しています。

## 環境

* macOS Mojave v10.14.3
* Node.js v10.15.0
* npm v6.4.1
* Visual Studio Code v1.31.1

## textlint
### 導入
チェック対象の Markdown ファイルのあるディレクトリへ、ローカルインストールします。
ここでは、textlint 本体と、Markdown ファイルをチェックするプラグインをインストールしています。

```bash
npm install textlint  --save-dev
npm install @textlint/textlint-plugin-markdown --save-dev
```

### ルールのインストール
文章をチェックのルールをインストールします。textlint のルールは、[Collection of textlint rule
](https://github.com/textlint/textlint/wiki/Collection-of-textlint-rule)
にあるように、たくさんあります。

独自に設定するのはたいへんなため、今回はプリセットルールを使うことにしました。

* [JTFスタイルガイドのルールセット](https://github.com/azu/textlint-rule-preset-JTF-style)
* [技術文書向けの textlint ルールプリセット](https://github.com/textlint-ja/textlint-rule-preset-ja-technical-writing)
* [WEB+DB PRESS用語統一ルール](https://github.com/azu/textlint-rule-web-plus-db)

```bash
npm install textlint-rule-preset-jtf-style --save-dev
npm install textlint-rule-preset-ja-technical-writing --save-dev
npm install textlint-rule-web-plus-db --save-dev
```

### ルールの適用

1. インストールしたルールを適用するため、 ルールファイル（`.textlintrc`）をチェック対象のファイルがあるディレクトリ（または、上位ディレクトリ）に作成します。

    ```bash
    ./node_modules/.bin/textlint --init
    ```

2. ルールファイルのサポート形式は YAML / JSON / JavaScript の3種類で、今回は JSON 形式で作成します。

    ```json
    {
      "plugins": {
        "@textlint/markdown": true
      },

      "rules": {
        "preset-jtf-style": true,
        "web-plus-db": true,
        "preset-ja-technical-writing": true
      }
    }
    ```

### VS Code での実行

1. VS Code を開き、サイドバーの拡張機能、またはコマンドパレット（`Ctrl` + `P`）から textlint をインストールします。

    ```bash
    code .
    ext install vscode-textlint
    ```

2. コマンドパレットを開き、「textlint」と入力します。候補の「textlint: Show Output Channel」を選択すると、画面下部に[出力]パネルが表示されます。

3. チェック対象の文章がおかしい場合、同一パネルの[問題]タブにエラーが表示されます。
  ![](./01.png)

### ルールのチェック対象外の指定
ルールをそのまま適用すると、都合の悪いケースが出てくることがあります。

たとえば、私は英単語の前後に半角スペースを入れています。
ところが textlint では、「`原則として、全角文字と半角文字の間にスペースを入れません。 (jtf-style/3.1.1.全角文字と半角文字の間)`」というエラーメッセージが出力されます。

これはチェックしてほしくないので、ルールファイル（`.textlintrc`）へルール対象外であることを記述します。

今回のエラーメッセージを見ると、`jtf-style` の `3.1.1.全角文字と半角文字の間` に違反しているとわかります。
そのため、`.textlintrc` を次のように書き換えます。

Before

```json
"preset-jtf-style": true,
```

After

```json
"preset-jtf-style": {
  "3.1.1.全角文字と半角文字の間": false
},
```

`false` にすることで、セットの中の一部のルールを対象外にできます。

## 所感
textlint を使うことで、自分では気付きにくい typo や、おかしな日本語などを検出できて便利です。
ただ、ルールによっては論文のようにお堅くなってしまうので、適度にルールを見直す必要があると感じています。


Visual Studio Code と textlint で文章を校正する

---
title: "Redash と Google SpreadSheet を連携する"
description: ""
date: 2019-02-02T21:42:22+09:00

tags:
  - Redash
  - Google SpreadSheet
archives:
  - "2019/02"
menu:
  - "blog"
redirect_from:
  - /blog/2019/20190202_redash-spreadsheet/
---

Google SpreadSheet のデータを Redash で扱うための設定方法の手順です。

## 環境

* Redash v5.0.2

## 手順
Redash と Google SpreadSheet を連携するには、SpreadSheet と Redash それぞれの設定が必要です。
大まかな流れは次のとおり。

1. Google SpreadSheet でアクセスキーの発行と共有設定をする。
2. Redash で、アクセスキーの読み込みを行いデータソースに追加する。
3. 追加したデータソースからクエリを作成し、Google SpreadSheet 内のデータを表示する。

### Google SpreadSheet の設定

#### Cloud Platform の設定

1. グラフ化したい Google SpreadSheet ファイルを開きます。
2. [ツール]メニュー > [スクリプト エディタ]を選択します。
3. スクリプトエディタで、[リソース]メニュー > [Google Platform プロジェクト]を選択します。このとき、プロジェクトの保存を求められるので任意の名前で保存してください。
4. 「project-id-」から始まるリンクを選択します。Google Cloud Platform ダッシュボードが表示されます。
  ![](/redash-spreadsheet/01.png)
5. [プロジェクト情報]セクションの[プロジェクト設定に移動]を選択します。[IAM と管理]が表示されます。
  ![](/redash-spreadsheet/02.png)
6. 左メニューから[サービスアカウント]を選択します。
7. [サービスアカウントを作成]ボタンを押下します。
8. 任意のサービスアカウント名を入力し、[作成]ボタンを押下します。[このサービス アカウントにプロジェクトへのアクセスを許可します]は、[続行]ボタンでスキップしてください。
9. [ユーザーにこのサービス アカウントへのアクセスを許可]項目の[キーの作成（オプション）]で、[キーを作成ボタン]をクリックします。
10. キーのタイプに[JSON]を選択し、[作成]ボタンを押下します。秘密鍵ファイルがダウンロードされます。
11. [完了]ボタンを押下します。新しいサービスアカウントが作成されます。
12. Google Cloud Platform とスクリプトエディタを閉じます。

#### 共有設定

1. Google SpreadSheet で、[ファイル]メニュー > [共有] を選択します。
2. [ユーザー]項目に取得した秘密鍵ファイルの `client_email` に記載されているメールアドレスを入力し、[完了]ボタンを押下します。

  ```json
    {
      "type": "service_account",
      "project_id": "project-id-xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "private_key_id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "private_key": "-----BEGIN PRIVATE KEY-----xxxxxxxxxxxxxxxxxxxxxxxxxxxx\n-----END PRIVATE KEY-----\n",
      "client_email": "xxxxxx@project-id-xxxxxxxxxxxxxxxxxxxxxxxxxxxx.iam.gserviceaccount.com",
      "client_id": "xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
      "auth_uri": "https://accounts.google.com/o/oauth2/auth",
      "token_uri": "https://oauth2.googleapis.com/token",
      "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
      "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/xxxxx/xxxxxxxxxxxxxxxxxxxxxxxxxxxx.iam.gserviceaccount.com"
    }
  ```

これで、Google SpreadSheet の設定は完了です。

### Redash の手順
#### データソースの追加

1. Redash 右上のドロップメニューから、[Data Souces]を選択します。
  ![](/redash-spreadsheet/03.png)
2. [New Data Source]ボタンを押下します。
3. データソースとなるサービスが一覧表示されます。その中から、[Google Spreadsheet]を選びます。
4. [Name]項目に任意の値、[JSON Key File]項目に Google SpreadSheet の設定でダウンロードした秘密鍵ファイルを指定します。
  ![](/redash-spreadsheet/04.png)
5. [Save]ボタンを押下します。Data Source が追加されます。

#### クエリの作成（Google SpreadSheet 内のデータを表示）

1. Redash 上中央の [Create]メニューから、[Query]を選択します。
2. 左ドロップメニューから、先ほど追加したデータソースを選びます。右のテキストフィールドに、`SpreadSheetのID|シート番号`を指定します。
  ![](/redash-spreadsheet/05.png)

3. SpreadSheet の ID は、SpreadSheet の URL で確認できます。
   * `https://docs.google.com/spreadsheets/d/<この部分>/edit#gid=0`
   * シート番号（インデックス番号）は、SpreadSheet ファイルの左から 0,1,2.. と振られている。1枚目のシートなら `0` 。

4. [Execute]ボタンを押下すると、SpreadSheet内のデータを取得します。

これでRedash の設定とクエリ作成が完了です。

## Google SpreadSheet をデータソースとした場合の注意点

* 1行目はヘッダー扱いです。
* SpreadSheet 内の全件を取得します。
* 絞り込みしたいときは、Redash DB に保存されているクエリの実行結果をデータソースとして扱う必要があります。
  * 参考：[Querying Existing Query Results](https://redash.io/help/user-guide/querying/query-results-data-source)
