Node.jsではてなの自分の記事一覧を取得する

はてなの自分の記事一覧をサクッと取得できるようにしたかったのですが、意外と

• Node.jsで書かれている
• 結果をJSONにする

ものが見当たらなかったので結局自分で作ることにしました！

ツールの流れ

はてなから自分の記事一覧を取得する流れは下のようになります。

1. はてなのAtomPubを使う（認証はこの記事ではBasic認証を使います）
2. エンドポイントをGETすると最新の記事が10件とれる
3. 結果はXMLなのでJSONに変換する
4. 2のレスポンスに次の10件のURLが記載されているので、全部取得終わるまで2, 3を繰り返す

はてなのAtomPub

はてなのAtomPubの仕様については以下Hatena Developer Centerに記載されています。

developer.hatena.ne.jp

認証のところに書かれていますが、取得時に使える認証は

• OAuth認証
• WSSE認証
• Basic認証

の3種類です。個人的にしか使わないし、簡単な方法でとりたいので今回はBasic認証を使うことにしました！

Basic認証に必要なユーザー名ははてなIDで、パスワードはAPIキーを使用します。

APIキーははてなブログの管理画面から設定＞詳細設定に行った場所にあります！

設定＞詳細設定

下の方を見るとAtomPubの項目があり、そこにAPIキーがあるのでメモっておきましょう！

APIキー

ブラウザからGETしてみる

それでは、試しに記事一覧をブラウザから取得してみます。

ドキュメントにも記載がありますが、以下のURLで取得できます。

GET https://blog.hatena.ne.jp/{はてなID}/{ブログID}/atom/entry

僕の場合はてなID=kenevでブログID=kenfdev.hateblo.jpなので、以下になります。

https://blog.hatena.ne.jp/kenev/kenfdev.hateblo.jp/atom/entry

これをブラウザに入れると、下のようにBasic認証が聞かれるはずです。

ここにユーザー名とAPIキーを入力すると、下のようなXMLが表示されます。

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:app="http://www.w3.org/2007/app">
  <link rel="first" href="https://blog.hatena.ne.jp/{はてなID}}/{ブログID}/atom/entry" />
  <link rel="next" href="https://blog.hatena.ne.jp/{はてなID}/{ブログID}/atom/entry?page=1377584217" />
  <title>ブログタイトル</title>
  <link rel="alternate" href="http://{ブログID}/"/>
  <updated>2013-08-27T15:17:06+09:00</updated>
  <author>
    <name>{はてなID}</name>
  </author>
  <generator uri="http://blog.hatena.ne.jp/" version="100000000">Hatena::Blog</generator>
  <id>hatenablog://blog/2000000000000</id>
  
  <entry>
    <id>tag:blog.hatena.ne.jp,2013:blog-{はてなID}-20000000000000-3000000000000000</id>
    <link rel="edit" href="https://blog.hatena.ne.jp/{はてなID}/
    ブログID}/atom/edit/2500000000"/>
    <link rel="alternate" type="text/html" href="http://{ブログID}/entry/2013/09/02/112823"/>
    <author><name>{はてなID}</name></author>
    <title>記事タイトル</title>
    <updated>2013-09-02T11:28:23+09:00</updated>
    <published>2013-09-02T11:28:23+09:00</published>
    <app:edited>2013-09-02T11:28:23+09:00</app:edited>
    <summary type="text"> 記事本文 リスト1 リスト2 内容 </summary>
    <content type="text/x-hatena-syntax">
      ** 記事本文
      - リスト1
      - リスト2
      内容
    </content>
    <hatena:formatted-content type="text/html" xmlns:hatena="http://www.hatena.ne.jp/info/xmlns#">
      &lt;div class=&quot;section&quot;&gt;
      &lt;h4&gt;記事本文&lt;/h4&gt;
      &lt;ul&gt;
      &lt;li&gt;リスト1&lt;/li&gt;
      &lt;li&gt;リスト2&lt;/li&gt;
      &lt;/ul&gt;&lt;p&gt;内容&lt;/p&gt;
      &lt;/div&gt;
    </hatena:formatted-content>
    <app:control>
      <app:draft>no</app:draft>
    </app:control>
  </entry>
  <entry>
  ...
  </entry>  
  ...
</feed>

XMLが取得できそうだとわかったところで、Node.jsで実装してみます！

Node.jsで取得する

まずはソースを載せちゃってからポイントを解説します。

const axios = require('axios');
const parseString = require('xml2js').parseString;

const hatenaAPIUser = '<USER_ID>';
const hatenaAPIPassword = '<API_KEY>';
const entryUrl = `https://blog.hatena.ne.jp/<USER_ID>/<BLOG_ID>/atom/entry`;

const creds = `${hatenaAPIUser}:${hatenaAPIPassword}`;
const encoded = Buffer.from(creds).toString('base64');
const authorizationHeader = `Basic ${encoded}`;

/**
 * Promise based timeout
 * @param {number} msec wait milliseconds
 */
function wait(msec) {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve();
    }, msec);
  });
}

/**
 * Promise based XML->JSON Parser
 * @param {object} data XML Data
 */
function parseStringPromise(data) {
  return new Promise((resolve, reject) => {
    parseString(data, (err, result) => {
      if (err) {
        reject(err);
        return;
      }
      resolve(result);
    });
  });
}

/**
 * Get all Hatena entries recursively
 * @param {string} url Entry URL
 */
async function getAllEntries(url) {
  console.log('fetching:', url);
  const entries = await axios.get(url, {
    headers: {
      Authorization: authorizationHeader,
    },
  });

  const {
    feed: { entry, link },
  } = await parseStringPromise(entries.data);

  const next = link.find(l => l.$.rel === 'next');

  const parsedEntries = entry
    .filter(e => {
      const {
        'app:control': [
          {
            'app:draft': [isDraft],
          },
        ],
      } = e;
      return !(isDraft === 'yes');
    })
    .map(e => {
      const categories = e.category ? e.category : [];

      return {
        id: e.id[0],
        title: e.title[0],
        url: e.link[1].$.href,
        published: e.published[0],
        publishedAt: new Date(e.published[0]).getTime(),
        updated: e.updated[0],
        updatedAt: new Date(e.updated[0]).getTime(),
        summary: e.summary[0]._,
        categories: categories.map(c => c.$.term),
      };
    });

  if (next) {
    // recursively fetch if 'next' exists
    const nextHref = next.$.href;
    await wait(500);
    const nextEntries = await getAllEntries(nextHref);
    return [...parsedEntries, ...nextEntries];
  } else {
    return parsedEntries;
  }
}

getAllEntries(entryUrl).then(console.log);

ポイントとしては

• 外部リクエストにはaxiosを使い、BASIC認証用のHTTPヘッダーを作成している
• XMLからJSONにはxml2jsというライブラリを使っている
• 無限ループで負荷かけちゃうの怖いのでリクエスト間に500ミリ秒待つ
• 最終的なJSONの形は自分で決める

となります。順番に説明します！

外部リクエストにはaxiosを使い、BASIC認証用のHTTPヘッダーを作成している

最近axiosを使う機会が多かったので、なんとなく外部リクエストのライブラリはaxiosにしました。 ライブラリは割とどうでもいいのですが、ポイントはBASIC認証のHTTPヘッダーを作っている部分です。

const creds = `${hatenaAPIUser}:${hatenaAPIPassword}`;
const encoded = Buffer.from(creds).toString('base64');
const authorizationHeader = `Basic ${encoded}`;

...

  const entries = await axios.get(url, {
    headers: {
      Authorization: authorizationHeader,
    },
  });

...

BASIC認証を実現するためにはHTTPヘッダーに Authorization というものを作って、中身はBasic <ユーザー名:パスワードをbase64エンコードした値>となります。

XMLからJSONにはxml2jsというライブラリを使っている

XMLからJSONにするために下のライブラリを使っています。

github.com

axiosで取得したXMLの中身をこのライブラリに通すことで、JSONを取得することができます。

const parseString = require('xml2js').parseString;

/**
 * Promise based XML->JSON Parser
 * @param {object} data XML Data
 */
function parseStringPromise(data) {
  return new Promise((resolve, reject) => {
    parseString(data, (err, result) => {
      if (err) {
        reject(err);
        return;
      }
      resolve(result);
    });
  });
}

...

  const {
    feed: { entry, link },
  } = await parseStringPromise(entries.data);

...

個人的にCallbackがあまり好きじゃないので、Promiseにわざわざ変換したfunction書いてますけど、これは別に必要ないです。Promiseにしてawaitしたかっただけです。

無限ループで負荷かけちゃうの怖いのでリクエスト間に500ミリ秒待つ

コードがバグっていてはてなさんのサーバーに変な攻撃を起こしてしまうのが怖いので、リクエスト間に待ちを発生させるようにしてます。

/**
 * Promise based timeout
 * @param {number} msec wait milliseconds
 */
function wait(msec) {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve();
    }, msec);
  });
}

...

  if (next) {
    // recursively fetch if 'next' exists
    const nextHref = next.$.href;
    await wait(500);
    const nextEntries = await getAllEntries(nextHref);
    return [...parsedEntries, ...nextEntries];
  } else {
    return parsedEntries;
  }

...

先程と同じく、setTimeoutをPromiseにしてawait使いたかったのでわざわざfunction作っています。あとは再帰呼び出しをする直前にawait wait(500)と書いて500ミリ秒待つようにしています。

最終的なJSONの形は自分で決める

XMLからJSONに変換したものは、そのままではものすごく使いづらいので、適宜興味のある項目だけ抜き取って最終的な形に整形します。

...
      const categories = e.category ? e.category : [];

      return {
        id: e.id[0],
        title: e.title[0],
        url: e.link[1].$.href,
        published: e.published[0],
        publishedAt: new Date(e.published[0]).getTime(),
        updated: e.updated[0],
        updatedAt: new Date(e.updated[0]).getTime(),
        summary: e.summary[0]._,
        categories: categories.map(c => c.$.term),
      };
...

こうすると、下のようなJSONになります。

{
  "id": "xxxxxxxxxxxxxxxxxxx",
  "title": "AWS SAA再認定のために5日間頑張ったこと",
  "url": "https://kenfdev.hateblo.jp/entry/saa-recertification",
  "published": "2019-03-08T20:42:58+09:00",
  "publishedAt": 1552045378000,
  "updated": "2019-03-08T20:42:58+09:00",
  "updatedAt": 1552045378000,
  "summary": "昨日AWSソリューションアーキテクト・アソシエイト（以下SAA）に再認定されました。3月中に取得しないといけないというミッションがあったので慌てて先週申し込みました。試験会場の関係で試験日まで5日しか無かったのですが、合格できたので備忘録を残しておきます。 TL;DR（まとめ） …",
  "categories": ["AWS"]
}

まとめ

以上ではてなの記事一覧の取得ができます！最後はfsを使ったりしてファイルにJSONを保存すれば何か他の用途に使うことができるかと思います。

以下リポジトリにコードを格納していますので、興味がある方は使ってみてください！

github.com

「k3sとラズパイでフロントエンド開発に挑戦した話」を発表しました

今週は2つのイベントでLTをさせていただきました！ほぼ同じ内容で登壇したので、2日連続で参加された方には申し訳なかったのですが、少し内容を変える努力はしました。。。

rancherjp.connpass.com

cnjp.connpass.com

発表資料

ストーリー

フロントエンジニアでラズパイ持っててkubernetesに興味があったら、とりあえずラズパイ上にNuxt.js乗せたくなりますよね！？

ということで、今回はNuxt.jsをラズパイに入れたk3s上にデプロイすることに挑戦したときの話をしました！ポイントとしては下のとおり！

• arm32v7/nodeの alpine だと npm install でコケる
• なのでARMのイメージで alpine はあきらめる
• docker create manifest でマルチアーキイメージを作れる（ARMとx86_64で同じイメージ名！）
• Dockerfileの FROM に ARG を使うとイメージレイヤのキャッシュが効かない疑惑がある

ヘルプをもらえました！

node のイメージを素で使ってましたけど、 node-slim にしては？ というアドバイスがいただけました！

build-argsとキャッシュ問題はこれじゃないかというアドバイスをいただきました！https://t.co/yUkdVBH7YV #cnjp

— Ken Fukuyama (@kenfdev) June 7, 2019

879mb→310mb

半分以下には落とせました！けれど2桁までは落としたい気持ちがあります。。。

ARG 使うとキャッシュは効かない！？ についてのアドバイスもいただけました！

arm32v7/nodeの `slim` を使えばいいのではというアドバイスも！試します！

#cnjp pic.twitter.com/oA57vHNqfH

— Ken Fukuyama (@kenfdev) June 7, 2019

上の公式ドキュメント読みましたけど、毎回同じ値にしてるのにキャッシュ効かないんですよねー。これは引き続き調査 or Dockerfileを分ければいいのかなと思ったり。

おまけ

こういうコメントがもらえてうれしいです！アプリ寄りな話を増やしたい気持ちはあるんですよね。

@kenfdevさんの、k3s on ラズパイに作ったフロントを乗っけて、フロント開発したという話。フロントもやりたい、kubeも学びたい人に良さそうである（＾ω＾）#cnjp

— おかもん@子育てしながら系エンジニア（・ω・） (@mojogeek666) June 7, 2019

なかなか時間を作るのにも苦労していますが、今後もフロントエンドとコンテナをからめていきたいです！

カックさん（@kakakakakku）さんのメンタリングを卒業しました

3月から5月の3ヶ月間に渡るカックさん（@kakakakakku）のブログメンタリングを卒業しました！

ここに卒業記事を残し、今後についても書き残しておきたいと思います。

メンタリングをなぜ受けたのか

僕はアウトプットすること自体は好きで、ブログを書いたりイベントに登壇したりは不定期にしていました。自分でも認識していた問題はアウトプットの習慣化がまるでできていなかった点です。その点を改善すべく、メンタリングを受ける決意をしました。

アウトプットの習慣化がなぜできないのか

「なぜアウトプットの習慣化ができないのですか？」と聞かれたら多くの人が「忙しくて時間が無い」と答えるかと思います。

今、「うんうん」と頷いた方、ぜひぜひ下の記事を読んでいただきたいです。これだけでもマインドセットが変わると思います！

kakakakakku.hatenablog.com

kakakakakku.hatenablog.com

僕も「時間が無い」と思っていた中の一人ですが、「時間が無い」と定義していたのは自分です。誰かに強制的に自分の時間を奪われていたわけではありません（そういう人もいるかもしれませんが…）。時間の使い方をコントロールできていなかったのが大きな原因だと気づくことができました。

3ヶ月の実績

3ヶ月の実績は下のとおりです。

PV

項目	3月初	5月末
Twitter Follower	393	410
はてブ	0	12
読者数	0	31

メンタリングが始まって結構すぐにCloud Native Kansaiという大きめなイベントでLT登壇することができたので、PVがすごく上がっています。

そのときの記事がこちら。

kenfdev.hateblo.jp

けれど、この波に乗ることができずにいっきに低迷！そこからOPAネタを書いていきながら、最後は書評に挑戦して徐々にPVを上げていくことができたかなと思っています（まだまだですが）。

驚くような結果にはならなかったので反省していますが、今後も継続して精進していきます！

課題

卒業とともにカックさんに最後のフィードバックをもらいました。中でも特に僕が今後も改善していきたい点については「満足できるクオリティに達するまでの距離を遠くに置きがち」なところです。週1のアウトプットを出していくことはできるようになったのですが、1アウトプットするまでに要している時間が多すぎると感じています。

いつもどうしても

• まとまりが悪い
• ストーリー性が見えにくい
• もっと違う観点を取り入れたほうがいいのでは
• などなどetc.

と考えてしまって、書いては消して、書いては消してを続けてしまいます。「小さく考える力」が圧倒的に足りていないのを痛感しています。 カックさんにも薦められた「小さな習慣」を読み、「常にアジャイルに、小さく考えられるように」改善し続けたいと思っています！

小さな習慣

メンター、カックさんについて

カックさんは本当にすごい方です。そのすごさは他のメンティの卒業エントリを見てもわかると思います。今後もエントリは増えていくと思うので、下のようにググったりTwitter検索した内容を確認すると勉強になります。

www.google.com

twitter.com

すごい点は数え切れないほどあるのですが、僕からも1点共有しておきたいです。

それは「やってみせる・やらせてみる・フィードバックする」のサイクルが本当にうまく回っていると感じた点です。

この記事を書いている最中にもカックさんからこんなツイートが流れています。

普通に envsubst のことを知らなかったから書いたんだけど，Linux コマンド1個で記事が書けるんだよ！というネタ粒度の観点をブログメンティに伝える目的もあったのだ😀 / Shell で「テンプレートエンジン」のような仕組みを実現できる envsubst コマンド - kakakakakku blog https://t.co/LuKL3Vriz1

— カック@ブロガー / k9u (@kakakakakku) 2019年6月3日

カックさん自身、かなり多忙なはずなのですが、毎週必ずアウトプットをしています。メンターであるカックさんがやってみせてから、メンティにもやらせてみる。そして、やらせてみた後は必ずフィードバックがもらえます。フィードバックは「よかった」「悪かった」なんてシンプルなフィードバックじゃなくて、かなり濃厚で、親身なフィードバックがいただけます。すごいのは、それらのフィードバックや他の通常な会話も合わせて、メンティの僕が精神的に負荷を感じることが無い点です。「がんばろう」という気持ちに素直になりますし、「しんどい」ときにはどう乗り越えていくことができるか相談に乗ってくれます。メンターの鏡です！自分自身で最高のメンターによるメンタリングを経験することができたので、僕もこうなれるように、この点についても日々精進していきたいです。

今後について

このメンタリングを通して毎週最低1記事を書くということが習慣化できたので、自分は成長したと感じています。メンタリング中に初挑戦した書評ともちょうどフィットするのですが、メンタリングを受けたことで、セルフマネジメントのレベルが上がって、ブログを書くことの習慣化が可能になったのかなと思います。

今後3ヶ月の目標としては

• 週1アウトプットを続ける
• ホッテントリな記事を書く
• 英語の記事も書く（https://medium.com/@kenfdev）

としたいです。

習慣化したのを継続すること（当たり前ですが！）、質の高い記事が書けるようになること。そして、英語のアウトプットも増やしていけたらと思います！（世界は広い！）

またちょっと長い目な記事になってしまいましたが、以上で卒業報告とさせていただきます！

カックさん（@kakakakakku）、本当にありがとうございました！！！

Unit Test好きにはたまらない！Conftestで設定ファイルのテストをしてみた

KubeConでOpen Policy Agent関連の発表を追っていたところ、面白そうなプレゼンを発見しました！

Unit Testing Your Kubernetes Configuration with Open Policy Agent

僕はUnit Test大好き人間なのでUnit Testと聞くだけで興奮するのですが、それにさらにOpen Policy Agentが関わっているときたら放っておけません！

もしOpen Policy Agentについて初めて聞いたという方は以下の記事でも紹介しているので興味があればぜひ！

kenfdev.hateblo.jp

Conftest

ConftestはYAMLあるいはJSONで定義された設定ファイルに対してテストを書けるというツールです。

面白いのは、テストに使うのがOpen Policy AgentのRegoというポリシー用の言語だという点です。上に紹介した記事にも書いていますが、さらに気になる人は公式サイトでもRegoについて詳しく書かれているのでぜひ読んでみてください。

www.openpolicyagent.org

インストール

Macにインストール。僕はbrewを使いましたが、様々な方法でインストールできますので、READMEをチェックしましょう！

brew tap instrumenta/instrumenta
brew install conftest

インストールはこれで完了です！

テストを書く

ではテストを書いてみましょう！KubernetesのYAMLがテストできるってところがハイライトされがちですけどYAML, JSONならなんでもOKです！

ということでせっかくなのでチュートリアルには無いCircleCIのYAMLを対象にしました！

テストを書くにあたって重要なのはRegoという言語を使うということです。

Regoはポリシーに特化した言語で、ちょっとトリッキーなところもありますが、宣言的で読みやすい言語だと思います。

例えばCircleCIの以下のようなconfigがあったとします。

version: 2.0
jobs:
  build:
    docker:
      - image: circleci/buildpack-deps
    steps:
      - checkout
  test:
    docker:
      - image: kenfdev/golang:1.12
    steps:
      - checkout
workflows:
  version: 2
  build_and_test:
    jobs:
      - build
      - test

これを.circleci/config.ymlに置きます。

conftest を導入すると何ができるかというと、このYAMLの記述内容に対してポリシーを書くことができます。

具体的にはこんなポリシーを割り当てることができます

• version: 2.1 以上しか使っちゃいけない
• CircleCI純正のイメージしか使っちゃいけない
• コンテナのイメージにlatestを使っちゃいけない

などなどです。

実際にこのポリシーを適用したテストを順番に書いてみます。

conftestはデフォルトでpolicyディレクトリ配下の.regoファイルを見てくれる様なので、circleci.regoというファイルを作ります。

touch policy/circleci.rego

この中にルールを書いていきます。

packageを指定

Regoのpackageはデフォルトでmainが使われます。これは--namespaceオプションで変更可能とのこと。

なので、packageはmainにしましょう。

package main

version: 2.1 以上しか使っちゃいけない

「CircleCIのOrbs機能を使いたいから、Versionを必ず2.1以上にしたい」というポリシーがあるかもしれません。その場合に書けるポリシーは以下のとおり。

deny[msg] {
 input.version < 2.1
 msg = "Use version 2.1 or higher"
}

denyになる条件を探すので、「どうなっているとルール違反か？」というマインドが必要です。inputというのはRegoで特別な変数で、conftestの場合ここにテスト対象のYAMLあるいはJSONが入っています。なのでinput.versionでversionにアクセスできます。

conftestを実行してみます！

$ conftest test config.yml
config.yml
   Use version 2.1 or higher

2.0をconfig.ymlに指定しているので怒られてますね！

CircleCI純正のイメージしか使っちゃいけない

こんなユースケースがあるかどうかはさておき、使うコンテナのimageにポリシーを設けたい場合の例になります。

必ずimageがcircleci/から始まっているかどうかをチェックしてみます！

deny[msg] {
  docker_images := input.jobs[_].docker[_].image
  not startswith(docker_images, "circleci/")
  msg = "Only use official CircleCI images"
}

Regoのちょっとトリッキーな書き方をさっそく取り入れてみました。

docker_images := input.jobs[_].docker[_].image

これを言語化すると「jobsの中に含まれる複数のキー（build, test）の中にあるdockerという配列の中のimageキーの値」になります。

こうやって書くことでOPAがよしなに順番に拾ってくれます。そして、それらがcircleci/で始まってなかったらアウトにします。

not startswith(docker_images, "circleci/")

ここで使っているstartswithはRegoに予め組み込まれているビルトイン関数です。OPAのドキュメントにも載っているので、どういうものがあるかチェックしておくといざとなったら使えて便利です！

www.openpolicyagent.org

「circleci/で始まっていないもの」を探すので、先頭にnotをつけている点もお忘れなく！

実行してみます！

$ conftest test config.yml
config.yml
   Only use official CircleCI images
   Use version 2.1 or higher

kenfdev/golang:1.12 を使っているので怒られていますね！

コンテナのイメージにlatestを使っちゃいけない

またまたimageに関連するポリシーです。安定したCIを回すためにimageに必ずタグを指定するというポリシーが必要になるかもしれません。latestを使っていたらルール違反にしましょう。

deny[msg] {
  docker_images := input.jobs[_].docker[_].image
  tag_is_latest(split(docker_images, ":"))
  msg = "Do not use `latest` container image tags"
}

# helpers
tag_is_latest(images) {
  count(images) < 2
}

tag_is_latest([_, tag]) {
  tag == "latest"
}

docker_imagesはさっきと同じですが、2行目がまたちょっとトリッキーです。latestを検知する方法は以下の2つの観点にしています。

• :で分割した場合に要素が2個より小さい
• :で分割して末端側（tag側）の値がlatestになっている

いずれかにヒットしたらルール違反にします！ここでポイントなのは、「いずれか」ということ。つまりOR条件になります。Regoのルール内の行は全てANDになり、同じルール名のルール（この場合tag_is_latest）を並べるとORになるという特性があります。これはIncremental Definitionsと言って公式ドキュメントでも説明があるので要チェックです。

www.openpolicyagent.org

また、僕が以前書いた記事にもANDとOR、そしてルール内から別のルールを呼び出すことについて触れていますので興味があればぜひ参考にしてみてください！

kenfdev.hateblo.jp

上のやり方ではtag_is_latestというルールを別途2つ作って、それぞれの判定条件を書きました。

:で分割した場合に要素が2個より小さい

tag_is_latest(images) {
  count(images) < 2
}

imagesにはsplit(docker_images, ":")で分割された値が入ってきます。今回の例であれば下のようになります。

["circleci/buildpack-deps"] # 要素数は1つ
["kenfdev/golang", "1.12"] # 要素数は2つ

タグが無い場合のデフォルトがlatestになるので、分割された要素の数が2より小さいかどうかをチェックします。

:で分割して末端側（tag側）の値がlatestになっている

tag_is_latest([_, tag]) {
  tag == "latest"
}

また新たな記法が引数の場所（[_, tag]）に登場しました。これは、いい感じに配列の値を分割代入させる書き方です。

例えば下のように書くとイメージしやすいと思います。

[name, tag] = ["circleci/buildpack-deps", "latest"]

nameにはcircleci/buildpack-depsが対応し、tagにはlatestが対応して代入されるようなイメージです。でも、nameには今回は特に興味がないので、上の例では[_, tag]と書いています。そして、ルール内ではtag == "latest"というように評価することで、tagがlatestかどうかチェックすることができます。

それでは、テストを実行してみましょう！

$ conftest test config.yml
config.yml
   Only use official CircleCI images
   Do not use `latest` container image tags
   Use version 2.1 or higher

image: circleci/buildpack-depsがタグを指定していないので、ちゃんと怒られていますね！ちなみにimage: circleci/buildpack-deps:latestとしてもちゃんと怒られます。

conftestでテストができました！念の為ポリシーの全体像も載せておきます。

# .circleci/policy/circleci.rego
package main

deny[msg] {
 input.version < 2.1
 msg = "Use version 2.1 or higher"
}

deny[msg] {
  docker_images := input.jobs[_].docker[_].image
  not startswith(docker_images, "circleci/")
  msg = "Only use official CircleCI images"
}

deny[msg] {
  docker_images := input.jobs[_].docker[_].image
  tag_is_latest(split(docker_images, ":"))
  msg = "Do not use `latest` container image tags"
}

# helpers
tag_is_latest(images) {
  count(images) < 2
}

tag_is_latest([_, tag]) {
  tag == "latest"
}

config.ymlの修正

怒られっぱなしなのもちょっと悲しいので、config.ymlを直しましょう！

全てのポリシーを満たすために下のように修正しました。

version: 2.1 # 2.1に変更
jobs:
  build:
    docker:
      - image: circleci/buildpack-deps:jessie # latest使うのやめた
    steps:
      - checkout
  test:
    docker:
      - image: circleci/golang:1.12 # circleciのイメージに変更した
    steps:
      - checkout
workflows:
  version: 2
  build_and_test:
    jobs:
      - build
      - test

それではテスト実行です！

$ conftest test config.yml
config.yml

ちょっとわかりづらいんですけど、何も怒られなくなりましたね！

いい感じにconftestで設定ファイルに対してテストが書けることがわかりました。Regoへの慣れは必要ですが、今後Open Policy Agentも様々な場所で使われていくことになりそうなので、Regoは学んでおいて損は無いんじゃないかなと思っています。

今回のコードは以下のリポジトリに置いてます。

github.com

まとめ

• YAML, JSONの設定ファイルに対してテストが書けるconftestを試した
• conftestは宣言的にOpen Policy AgentのRegoを使ってテストを書ける
• どこがルール違反になっているか、場所も教えてくれるとさらにうれしい
• 全部ポリシーをパスしてたらもうちょっとうれしい出力がほしい（笑）
• 今後に期待したい！！！

参考

Conftestを使ったテストの例 github.com

Open Policy Agentのチュートリアル www.openpolicyagent.org

セルフマネジメントについて考える / 『管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう』を読んで②

「管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう」という本を読み終えました！

管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう

この本の中でも特に「生産的に働く」ことについては以下の記事で書評を書いたので、興味がある方はぜひ！

kenfdev.hateblo.jp

この記事では、第2部で紹介されている「セルフマネジメントのレベル」と「師匠が背中を見せる」ことについて注目した書評を書きます。

目次

• はじめに
• 第1部　生産的に働く　～楽に成果をあげるために“見直す”
  • やり方を見直す　～「ふりかえり」で抜本的に生産性を改善する
  • 生産性を見直す　～「時間対効果」の高い仕事をする
  • タスクを見直す　～「タスクばらし」で小口化する
  • やる気を見直す　～無理に上げない、なくさない状況をつくる
  • 信頼関係を見直す　～「心理的安全性」を生み出す環境
  • 会議を見直す　～口を動かすだけでなく、いっしょに手を動かす
  • 雑談を見直す　～ホウレンソウから「ザッソウ」へ
  • 社内業務を見直す　～人手に頼らない「業務ハック」で改善を続ける
  • 価値を見直す　～受託脳よりも提案脳で考える
• 第2部　自律的に働く　～人を支配しているものを“なくす”
  • 管理をなくす　～セルフマネジメントで働くチームをつくる
  • 階層をなくす　～「ホラクラシー」組織を実現する仕組み
  • 評価をなくす　～個人の成長と会社の貢献の「すりあわせ」をする
  • 数字をなくす　～組織のビジョンよりも自分のためならがんばれる
  • 組織の壁をなくす　～信頼しあえる企業文化の育て方
  • 急募をなくす　～仕事があっても、いい人がいなければ採用しない
  • 教育をなくす　～自分の頭で考える社員の育て方
  • 制度をなくす　～本質ありきで考える「そもそも思考」
  • 通勤をなくす　～働く場所に縛られない「リモートチーム」
• 第3部　独創的に働く　～常識や慣習に従うことを“やめる”
  • 既存のビジネスモデルに従うのをやめる　～納品のない受託開発
  • 顧客を説得する営業をやめる　～対等な関係を作るマーケティング
  • 新規事業の指示命令をやめる　～部活から生まれるイノベーション
  • 規模を追求することをやめる　～組織の大きさもコントロールしない
  • 会社らしくすることをやめる　～文化をつないでいくコミュニティ
• おわりに

セルフマネジメントの3つのレベル

本書では「管理をなくす」にあたって、セルフマネジメントについて紹介されています。「仕事」、「組織」、「自分」という3つの観点で、それぞれレベルを3つに分けて定義しています。

観点	Lv1	Lv2	Lv3
仕事	タスクを管理する	リソースを管理する	価値を生み出す
組織	周囲に伝える	周囲と協調する	周囲を活かす
自分	休憩をとる	安定して働く	将来を考える

何ができていると、どこのレベルにいるかというのが述べられています。「自分はそれぞれの観点でどこのレベルにいるのか？」というのを確認できて面白いですし、何ができればレベルが上がるのかというのも参考にすることができます。

「休憩をとる」ということ

セルフマネジメントのレベルの中でも注目したいのは「自分」の観点の中のLv1に入っている「休憩をとる」ことです。

休憩が習慣化していない人にとっては「いつ休憩をとるのか？」というのが難しいと感じそうですが、僕はポモドーロ・テクニックがここにフィットすると感じました。

何度か僕のブログで紹介していますが、ポモドーロ・テクニックについては僕のブログメンターでもあるカックさん( @kakakakakku )の以下の記事がおすすめです！

kakakakakku.hatenablog.com

ポモドーロ・テクニックを使って「25分間は超絶に集中し、その後は5分間休憩をとる」というサイクルを繰り返していくと休憩も1つのタスクのように感じられるようになり、自然と習慣化もしていきます。

だれかが管理しないと休めないようでは、マネジメントする側の負担は大きいままです。

と、本書でも述べられています。休憩を自らとれるかとれないかは、自分だけの問題ではないということに気づく必要があります。休憩の習慣化は小さく見えてセルフマネジメントにおいては大きな一歩だと感じました。

師匠が背中を見せる

本書には「教育をなくす」という章があり、「教育する」のではなく「仕事の中で育てる」方法について紹介しています。

これには以下3つのポイントが述べられています。

• やってみせる
• やらせてみる
• フィードバックする

本書では育てる側を「師匠」、育てられる側を「弟子」と呼んでいて、1点目の「やってみせる」というのは「師匠が弟子に背中を見せる」ということです。ポイントとなるのは、いかにして師匠は弟子に自分の技術を盗ませるかです。そのためにまずは「やってみせる」ことが大事だと述べられています。個人的にふりかえってみても、物理的に離れていた新人に仕事をやってみてもらったときよりも、隣に座って一緒に仕事をしていた新人の方が圧倒的に成長のスピードが早かったのが記憶に残っています。これは、自然と自分の仕事を「やってみせる」ことができていたのではないかと思います。

気になった点としては、最初から物理的に離れている者同士（リモート）の場合、「やってみせる」にはどうしたら良いかということです。フルリモートをしている身としては今後の課題として追求していきたいです。

まとめ

• 『管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう』を読んだ
• セルフマネジメントに悩んでいるor興味がある人にオススメできる
• セルフマネジメントできる人を増やしたい人にもオススメできる
• フルリモートにおける師弟関係について追求していきたい

管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう

生産的に働くことについて考える / 『管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう』を読んで①

ふとFacebookのタイムラインから流れてきた「管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう」という本。今まで技術書ばかり読んできていて組織や人に関する本には手をつけていなかったのですが、最近は積極的に読むようにしています。この本を読みながら改めて気付かされる点が非常に多かったため、自分のためにも書評を書きます！

管理ゼロで成果はあがる ~「見直す・なくす・やめる」で組織を変えよう

目次

以下が目次となっていて、この記事では太文字の「第1部　生産的に働く　～楽に成果をあげるために“見直す”」に注目します。

• はじめに
• 第1部　生産的に働く　～楽に成果をあげるために“見直す”
  • やり方を見直す　～「ふりかえり」で抜本的に生産性を改善する
  • 生産性を見直す　～「時間対効果」の高い仕事をする
  • タスクを見直す　～「タスクばらし」で小口化する
  • やる気を見直す　～無理に上げない、なくさない状況をつくる
  • 信頼関係を見直す　～「心理的安全性」を生み出す環境
  • 会議を見直す　～口を動かすだけでなく、いっしょに手を動かす
  • 雑談を見直す　～ホウレンソウから「ザッソウ」へ
  • 社内業務を見直す　～人手に頼らない「業務ハック」で改善を続ける
  • 価値を見直す　～受託脳よりも提案脳で考える
• 第2部　自律的に働く　～人を支配しているものを“なくす”
  • 管理をなくす　～セルフマネジメントで働くチームをつくる
  • 階層をなくす　～「ホラクラシー」組織を実現する仕組み
  • 評価をなくす　～個人の成長と会社の貢献の「すりあわせ」をする
  • 数字をなくす　～組織のビジョンよりも自分のためならがんばれる
  • 組織の壁をなくす　～信頼しあえる企業文化の育て方
  • 急募をなくす　～仕事があっても、いい人がいなければ採用しない
  • 教育をなくす　～自分の頭で考える社員の育て方
  • 制度をなくす　～本質ありきで考える「そもそも思考」
  • 通勤をなくす　～働く場所に縛られない「リモートチーム」
• 第3部　独創的に働く　～常識や慣習に従うことを“やめる”
  • 既存のビジネスモデルに従うのをやめる　～納品のない受託開発
  • 顧客を説得する営業をやめる　～対等な関係を作るマーケティング
  • 新規事業の指示命令をやめる　～部活から生まれるイノベーション
  • 規模を追求することをやめる　～組織の大きさもコントロールしない
  • 会社らしくすることをやめる　～文化をつないでいくコミュニティ
• おわりに

「精神論」でふりかえりをしてはいけない

「やり方を見直す」方法として「ふりかえり」の大切さが述べられています。

ふりかえりの4つのポイント

1. KPT（Keep・Problem・Try）でふりかえりをする
2. とにかく全員で出し切ることを優先する
3. 精神論ではなく、具体的なアクションに落とし込む
4. 週に一度、1時間のふりかえりから始める

特に3番目は多くの人が陥る問題だと思います。何か問題（Problem）があって、それを改善するための試み（Try）を考えた場合、どうしても「次はこうならないように気をつける」と精神論を言ってしまいがちです。

そういった精神論ではなく、以下のように具体的なアクションに落とし込むことが大事だと述べられています。

Problem「2日連続で寝坊してしまった」
↓
【NG】Try「早起きするように気をつける」
【OK】Try「目覚まし時計を買う」

僕もついつい「がんばる」や「気をつける」と言ってしまいがちですが、常にこの点は意識していきたいです。

100%の品質と完成度は目指さない

80%の完成度には2割の時間でよくて、残り20%を高めるためには8割の時間がかかる

というパレートの法則の引用を用いて、完璧を目指してはいけないという点が紹介されています。

ja.wikipedia.org

完璧を目指そうとすると考え込むことが多くなり、ひたすら時間だけが過ぎていくことが多くなります。また、そもそも完璧の定義自体が自分で決めたものなので、完璧かどうかなんてわかりません。

80%であってもリリースをしてみて、「もっとこうしてほしい」点や「これは必要ない」点について早い段階で見つけて改善していくことが大事だと述べられています。

最後にFacebook創業者のマーク・ザッカーバーグの引用も紹介されています。

Done is better than perfect.

この考え方は最近読んだ「エンジニアの心を整える技術」でも紹介されていて、非常に大事だと感じています。

booth.pm

作業じゃなくて仕事をまかせる

本書では「仕事」と「作業」は違うものだと述べられています。

• 作業
  • 事前に定められた手続きに従っておこなう活動
  • 手を動かすことに価値がある
  • わかりやすい結果や指標がある
  • 進め方に創意工夫の余地がない
• 仕事
  • だれかに価値を届けるための活動
  • 「価値とは何か」をそもそも考えなければいけない
  • わかりやすい結果や指標がない
  • 進め方に創意工夫の余地がある

作業の進め方に「創意工夫の余地がない」かどうかは議論の余地がありそうですが、僕自身も作業を依頼していることが今まで多かったかなと感じます。

作業には事前に定められた手続きが必要になるので、依頼する側の負担が大きいです。さらに、「依頼」をされると、された側は自分の仕事として考えるのが難しいと本書では述べられています。

仕事には「わかりやすい結果や指標がない」かわりに「進め方に創意工夫の余地がある」ことで、仕事をする側は 主体性をもって取り組む ことができます。

主体性をもつ→自律的に成長する→モチベーションが上がる→生産性も上がる

というような好循環が生まれる。上の表現だけでは単純に見えますが実際には「仕事の全体像や目的の伝え方」、「コミュニケーションの方法」、「フィードバック」について気をつけるべき点があり、本書では別途詳しく紹介されています。

社会人になって2、3年もすれば後輩ができたり、チームメンバーの入れ替えなどがあってコラボレーションを主体的に行っていく必要性が増していきます。そのときには作業ではなく、仕事をまかせることが大事なんだと改めて考えさせられました。

「ホウ・レン・ソウ」から「ザッ・ソウ」

本書ではホウ（報告）・レン（連絡）・ソウ（相談）の大切さについて述べられつつも、より大事なのはザッ（雑談）・ソウ（相談）だと述べられています。「雑談が大事」なのは既に知っている人も多いと思いますが、問題はどうやったら雑談を増やせるか？という点です。雑談は「よし、雑談をしよう！」と言ってなかなかできるものでは無いですし、信頼関係など前提条件が揃っている必要があります。

そこで本書では「雑談をうまくするポイント」が3つ紹介されています。

1. 雑談と仕事の場所をツールで分けない
2. 社内で起きている雑談の様子を見える化する
3. 定期的に雑談する機会をつくる

雑談と仕事の場所をツールで分けない

この点についてはハッとさせられました。確かに、例えばSlackのチャンネルに「#雑談」というチャンネルがあったとしたら、そのチャンネルに投稿するということは「よし、今から雑談するぞ！」という気持ちが先に発生する人が多いと思います。もちろん人によってこれは変わるのでしょうけど、雑談をする前に「雑談 or NOT 雑談？」というオーバーヘッドが生まれるのがあまり良くないというのには納得させれました。流れるように自然に雑談ができる環境がベストですよね。

社内で起きている雑談の様子を見える化する

この点については前提として社内全体の高い信頼関係が必要だとは感じます。それが無い状態ではどうしても前節にも述べられているように、発言の前に「こんな内容（雑談）を投稿していいだろうか？」というマインドが発生してしまうからです。

また、もう一つ注意する点については、（これは雑談に限った話ではないですが）公開される情報が多くなるということはSlackのようなツールの場合にそれだけ「通知」も多くなります。これによって気になることが多くなり、生産性が落ちてしまう可能性も含まれていると思います。

気になる通知

そこで僕が追加で紹介したいのはポモドーロ・テクニックです。

「25分間はとにかく決めたタスクに集中し、5分間休憩を挟む」ということを1セットとして繰り返すテクニックのことです。この25分間の間、通知が来たとしても無視します。無視するというのは、Slackであれば「離席中」にして通知が来ないようにするレベルです。

この記事では詳しくは述べませんが、以下の記事がとてもよくまとまっているのでポモドーロ・テクニックに馴染みの無い人はぜひ読むことをお薦めします！

kakakakakku.hatenablog.com

話が少し逸れましたが、「雑談の見える化」は見ようと思えば誰でも見えるような状態にしておくことが一つのポイントなのかなと僕は解釈しています。これもSlackの例えになりますが、可能な限りチャンネルはすべてPublicにしておくことがその手法の一つかと考えています。「他のチームの様子はどんな感じだろ？」となったときに「チラッ」と覗けたり、チャンネルにJoinできたりする環境が大事だと思います。

この点についてはSlackのJulia Graceさんによる「Building Engineering Teams Under Pressure（英語）」という公演でも述べられていて、合わせて視聴することをお薦めします。

www.youtube.com

まとめ

「管理ゼロで成果はあがる〜「見直す・なくす・やめる」で組織を変えよう」の「第1部　生産的に働く　～楽に成果をあげるために“見直す”」を読みました！個人的には「ふりかえり」することと「雑談」することが2つの大きなポイントだと感じました。「生産的に働くこと」については常に意識しつつ今後も仕事に取り組んでいきたいと思います！

また、セルフマネジメントについては、以下の記事で書きました！

kenfdev.hateblo.jp

おまけ

生産的に働くこととDeveloper Happinessも強く関連していると思います。この点については以前書いた下の記事で「Developer HappinessとEmployee Retention」というトピックでも紹介していますので興味があればぜひ読んでみてください！

kenfdev.hateblo.jp

Algolia Searchの速さに鳥肌が立った話

algolia.connpass.com

「Algolia Community Party in 京都 - 2019年5月10日」に参加し、LTしてきました！

発表資料

ストーリー

業務でAlgoliaのスパイクをうつ機会があったので、そのときに経験した 圧倒的な爆速っぷり について完全なる自己満でそのときの気持ちを伝えました！

SPA（Single Page Application）の入門チュートリアルで「検索バーでフィルタリング」する簡単なアプリを作った記憶は無いでしょうか？

下のCodePenのような簡単なフィルタリングアプリです。

https://codepen.io/tiana-p/full/XGJgPo

ここで検索バーに文字を入力すると、リアルタイムにフィルタリングが適用されます。 とても速いのですが、Amazon、楽天市場、価格.comで使うような「大量のデータから検索」する機能で同じようなUXを実現しようとすると かなり難しい です。

なぜなら、上のフィルタリングアプリは 最初から ブラウザがインメモリに持っている情報に対してフィルタリングしているのに対して、「大量のデータから検索」する場合には外部のAPIにリクエストして、さらにそのAPIが外部のデータベース内のデータを取得しにいったりするからです。これをどうにか高速化するにはインデックスを頑張ったり、キャッシュを頑張ったりと、涙ぐましい努力が必要になります。そしてその努力をしたとしても、上のフィルタリングアプリのようなスピードを実現するのはかなり難しいと思います。

なので、大量のデータから検索するときに、 ちょっと時間がかかる っていうのは「ある程度は仕方ないかな」と妥協することが多いはずです。

ただし！ 外部にデータがあったとしても爆速で検索できてしまうのがAlgoliaなんです！

下のデモサイトで体験ができるのでぜひ体感してみてください。

community.algolia.com

今まで様々な技術スパイクをうってきましたが、隣の同僚にまで「これ、やばいっすよ」って感動を伝えたのはAlgoliaが初めてです。

13万件のサンプルデータを入れてみて、多少パフォーマンスが変わるかと思いきや検索には 3ms しかかかりませんでした！（ただし、ネットワークの時間を含めると20~40ms）

イベントレポート

下のイベントレポートが両者とも非常にわかりやすくまとまっています！

Algoliaの @shinodogg さんのイベントレポート

shinodogg.com

@silver_birder さん のイベントレポート

silverbirder180.hatenablog.com

まとめ

まだAlgoliaのさわりの部分しか使えていないので

• Query Rules（「cheap camera」って検索したら「cheap」が「< 10,000」に変換できて、10,000円以内のカメラに絞れたりする）
• Personalization（検索で行った行動などから、ユーザー毎にサジェストをパーソナライズできたりする）
• Internationalization（多言語に対する検索インデックスの管理方法）
• Multi-tenancy（マルチテナントなデータの管理方法）

あたりのトピックを今後は深掘りしていきたいです！

幸運な巡り合わせのおかげで突如3日前に参加＆LTが決まったイベントでしたが、Algoliaの中のEiji Shinohara( @shinodogg )さんやフランスからかけつけて下さったMichaël Sokol( @_ms123 )さんともお話できて本当によかったです！