masutaka

こんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。

本日、週次の社内勉強会 <a href="https://developer.feedforce.jp/archive/category/FFTT">FFTT</a> で『引っ越ししたら家賃が3分の1になったかも』というタイトルで、実際は Amazon CloudFront + Heroku で動いていた<a href="https://masutaka.net/">自分のブログ</a>を GCP の <a href="https://cloud.google.com/run">Cloud Run</a> に移行した話をしました。

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vTucSlV9z4czouHd-hIOiDBwaeh1a7CMbEm2mmx5kGDTijuRKJF4ID3blnnKz1nhG6rvMfMBLyTSFMM/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="410" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


モチベーションはスライドにつらつら書きつつも、実際はこの FFTT の発表当番だったからではあります。結果的に満足行く結果にはなったので、これからコード管理などもう少し作り込んでいきます。<s>今後ネタに困ったらまた引っ越せばよいし。</s>

Cloud Run もそうですが、<a href="https://domains.google/intl/ja_jp/">Google Domains</a> や <a href="https://cloud.google.com/monitoring">Cloud Monitoring</a> の外形監視（稼働時間チェック）など、便利でライトに使える GCP を知ることが出来たことも収穫でした。

それでは良い週末を！(^^)/

こんにちは id:masutaka26 です。本日、週次の社内勉強会 FFTT で『引っ越ししたら家賃が3分の1になったかも』というタイトルで、実際は Amazon CloudFront + Heroku で動いていた自分のブログを GCP の Cloud Run に移行した話をしました。モチベーションはスライドにつらつら書きつつも、実際はこの FFTT の発表当番だったからではあります。結果的に満足行く結果にはなったので、これからコード管理などもう少し作り込んでいきます。今後ネタに困ったらまた引っ越せばよいし。Cloud Run もそうですが、Google Domains や Cloud Monitoring の外形監視（稼働時間チェック）など、便利でライトに使える GCP を知ることが出来たことも収穫でした。それでは良い週末を！(^^)/

自分のブログを CloudFront + Heroku から Cloud Run に移行した話をした

こんにちは。自称 Looker エバンジェリストの id:masutaka26 です。今日は Spectacles というツールを導入して、Looker インスタンスの健全性を高められた話を紹介します。Spectacles とは4 種類のテスト基本的な振る舞いどのテストを採用し、どのような課題を解決したのかSQL validationAssert validationContent validationLookML validationどのような GitHub Actions にしたのかCI workflowSchedule workflow落ち穂拾い作業ブランチのゴミが残ることがあるマシンユーザーを作るか作らないかまとめSpectacles とはSpectacles は Looker のサードパーティ CI ツールです。継続的に各種テストを実行し、Looker インスタンスを健全に保つことが出来ます。クラウド版と OSS 版があり、それぞれ過去にクラスメソッドや、Zenn の記事で紹介されたことがあります。SpectaclesでLooker（LookML）のテストをやってみた | DevelopersIOLookerのCIツールであるSpectaclesを導入した話今回は OSS 版を使いました。github.com4 種類のテスト2022 年 9 月時点で 4 種類のテストが実装されています。SQL validation全ての Dimension の sql パラメーターについて、実際にクエリを実行し、その有効性を検証するdata warehouse のリソースを過剰に使わないよう工夫されている。例えば BigQuery の料金は発生しない1Assert validationLookML IDE 上でも実行できる LookML data tests を実行するContent validation開発メニューの Content Validator 相当の検証を行い、エラーのある Dashboard や Look を特定するLookML validationLookML IDE 上でも実行できる LookML validation を実行する基本的な振る舞いSpectacles は Looker API を使用し、指定した Looker インスタンス上で、LookML data tests や validation などを実行します。Spectacles -(Looker API)-> Your Looker Instanceいわゆるユニットテストでは、テスト環境でソースコードを checkout し、そこでテストを実行しますが、Spectacles はその点は全く違います。つまり GitHub Actions 等の CI で動かす場合、LookML コードの checkout は不要ということです。どのテストを採用し、どのような課題を解決したのかSQL validationいきなりですが、こちらは今回採用出来ませんでした。我々の環境で全ての Explore をテスト対象にすると、かなりの数のテストが失敗します。hidden: yes な Dimension がおそらく全てです。想定内です。$ spectacles sql --project my_project_name --profile -vそれならばと、--ignore-hidden オプションを付けると、今度はこんなエラーが発生します。どうやら 1 つも Dimension が表示されない Explore があるようです。こちらも想定内です。Explore object is missing dimensions, meaning this query won't have fields and will error. Often this happens because you didn't include dimensions when you built the project.--explore オプションでエラーが発生しない Explore を指定すればよいのですが、Explore が 150 個以上ある関係で、切り分けができていません。sql パラメーターは壊れていても、実際に Explore で当該 Dimension が使われないとエラーにならないのと、そのエラーが報告されるとも限らないので、いずれは再挑戦したいです。Assert validation我々の Looker インスタンスでは、BigQuery の外部テーブルに Google スプレッドシートを指定したテーブルを数多く参照しています。つまり人間が編集するデータです。このようなデータはオペミスにより壊れることがあり、primary_key も芋づる式に壊れることがあります。primary_key はほぼ全てテストを書いています2が、約 250 個と数が多いです。一方で LookML IDE 上での data tests は同時実行数が 1 に制限されているようで、テストに 10 分以上かかります。commit 前のテストを必須にできない状態でした。そのため、時々テストを手動実行しないと、壊れたことに気づけない課題がありました。以上の課題を解決するために、定期的に LookML data tests を実行し、手動実行せずに気付けるようになりました。Content validation今までは私の注意力で Dashboard 約 140 個と Look 約 30 個のエラー数ゼロを継続できていましたが、まさに属人的でした。これも定期的に実行し、Content Validator を手動実行することなく気付けるようになりました。LookML validation時々 LookML IDE を介さず、ローカル環境で git commit してデプロイすることがあります。そのケースで大きな変更をすることはないものの、validation が通らない LookML がデプロイされる確率はゼロではありません。こちらは git push のタイミングで実行することで、健全性を高めることが出来ました。どのような GitHub Actions にしたのかgit push のタイミングで実行する CI workflow と、定期的に実行する Schedule workflow を作りました。CI workflowgit push のたびに、当該 commit のブランチに対して、LookML validation のテストをしています3。name: CIon:  push:    branches-ignore: # ①      - 'dev-**'            # LookML IDE の個人用開発ブランチ      - 'tmp_spectacles_**' # spectacles の --commit-ref オプションが作るブランチjobs:  validate_lookml:    name: Validate LookML files    runs-on: ubuntu-latest    timeout-minutes: 5 # デフォルトは 360 分。料金のスパイクを防ぐ    concurrency: # ② spectacles が複数同時に実行しないようにする      spectacles_should_be_run_in_series    steps:    - uses: actions/setup-python@v4      with:        python-version: '3.x'    - name: Install Spectacles      run: pip install spectacles    - name: Run LookML Validator      env:        LOOKER_BASE_URL: "https://my_instance_name.looker.com"        LOOKER_CLIENT_ID: ${{ secrets.SPECTACLES_LOOKER_CLIENT_ID }} # ③        LOOKER_CLIENT_SECRET: ${{ secrets.SPECTACLES_LOOKER_CLIENT_SECRET }} # ③      run: spectacles lookml --project my_project_name --commit-ref "$GITHUB_SHA" -v①で特定のブランチを除外しています。特に今回のケースでは、tmp_spectacles_** を設定しないと validate_lookml ジョブが無限に起動し続けるため、絶対に必要です。②も結構重要で、CI workflow と次に示す Schedule workflow から起動される spectacles プロセスの同時実行数を 1 に制限しています。Spectacles は③と紐づく Looker ユーザーが実際に開発モードで tmp_spectacles_** というブランチを作り、切り替えます。Looker では 1 人のユーザーが同時に利用できるブランチは 1 つだけです。Spectacles の複数起動は問題が発生するため、今回の制限を設定しました。公式ドキュメントでも言及されています。Schedule workflow早朝と夕方に master（デフォルト）ブランチ上で、Content validation と LookML data tests を実行しています。name: Scheduleon:  schedule:    - cron: "00 21 * * 0-4" # 平日の  6:00 JST    - cron: "30  7 * * 1-5" # 平日の 16:30 JSTjobs:  schedule:    name: Scheduled job    runs-on: ubuntu-latest    timeout-minutes: 30 # デフォルトは 360 分。料金のスパイクを防ぐ    concurrency: # ① spectacles が複数同時に実行しないようにする      spectacles_should_be_run_in_series    env:      LOOKER_BASE_URL: "https://my_instance_name.looker.com"      LOOKER_CLIENT_ID: ${{ secrets.SPECTACLES_LOOKER_CLIENT_ID }}      LOOKER_CLIENT_SECRET: ${{ secrets.SPECTACLES_LOOKER_CLIENT_SECRET }}    steps:    - uses: actions/setup-python@v4      with:        python-version: '3.x'    - name: Install Spectacles      run: pip install spectacles    - name: Run Content Validator      run: spectacles content --project my_project_name -v    - name: Run LookML data tests      run: spectacles assert --project my_project_name -vブランチの時や、master ブランチへのマージ直後ではまだ Dashboard や Look がエラーになることがあるため、Content validation はこのタイミングにしています。LookML data tests も 10 分以上かかることと、git push の粒度でやらないと不安というわけではないため、このタイミングにしています。BigQuery の料金もかかりますからね。落ち穂拾い作業ブランチのゴミが残ることがあるSpectacles が途中で異常終了すると、LookML IDE と GitHub に tmp_spectacles_b016c8a4dd といった、Spectacles が作る作業ブランチが残ることがあります。気づいたら削除してあげましょう。正常終了の場合は残りません。マシンユーザーを作るか作らないかLooker はユーザー課金モデルであるため、Spectacles のためにユーザーを作ることに躊躇するかもしれません。私もそうでした。おまけに Developer 相当の権限が必要なため、そこそこの料金です。Create a Looker API Key | Spectacles DocsWe strongly recommend creating a dedicated Spectacles user in Looker to ensure a human user doesn't accidentally change the Git branch or turn off development mode in the middle of a validation.ですが、公式ドキュメントで強く奨励されているとおり、Spectacles 専用のユーザーを作って下さい。人間のユーザーは権限が大きすぎますし、前述のとおり Spectacles は実際に開発モードでブランチを作って切り替えるため、人間の作業とコンフリクトします。まとめSpectacles というツールを導入して、Looker インスタンスの健全性を高められた話をしました。導入したのは先月ですが、導入の翌日にタイミング良く Schedule workflow のテストが落ち、primary_key が壊れたことに気づけたことにはニッコリしました。私のようなボッチ LookML 開発者は、いかに作業を機械に任せるかが重要だと思います。心の平穏も大事です。また、あとから CI を導入するのは結構大変なので、始めから開発計画に組み込むことをオススメします。それでは良い Looker ライフを！(^^)/Limiting Resource Consumption | Spectacles Docs↩Looker で Join 先の view の primary_key をいい感じにテストする方法をようやく見つけた - Feedforce Developer Blog↩実際には他のジョブや、失敗時の Slack 通知ジョブもありますが、分かりやすくするために省略しています。↩

OSS 版 Spectacles を使って、LookML の data tests や validation などを GitHub Actions で継続的に実行させてみた

こんばんは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。

本日、<a href="https://looker-japan-user-group.connpass.com/event/253923/">Looker User Meetup Online #8</a> で『BigQuery経由で使うGoogleスプレッドシートのスキーマ管理』の話をしてきました。Looker User Meetup は 5 回目の参加、発表は初めてです。

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vTlQkD3R2OS415gr51ieTs1pyy3cK0ck8By1PYJ8SZtrFDjWyLP1eD_s7Q4UDH_yvmTDNdHFpZQf0IU/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="410" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


いくつかネタはあったのですが、今回のテーマは「Lookerまでのデータデリバリー、みんなどうしてる？」ということもあり、この 2 年で確立した方法を紹介することとなりました。

bq CLI ではなく、terraform で管理している方もいらっしゃいました。terraform の更新に追随するのはそれなりに大変だと思いますが、これならスキーマ定義と、実際のスキーマの差異検知は出来そうですね。

「dbt seed」を使っている方もいらっしゃるようでした。今回 2 つの発表があった dbt ですが、全く触ったことがありません。😇

あと、P24 で「BigQueryは一番左のシートしか参照できない」と書きましたが、誤りでした。範囲にでシート名も指定すれば出来ることを確認しました。P10 で華麗に「シート範囲」を無視してますね。💦

<a href="https://gist.github.com/masutaka/142ca20b802401d12012fe952f2ea1f3">P18 の Gist</a> との差分は以下になります。

<pre class="code lang-diff" data-lang="diff" data-unlink>diff --git a/define.json b/define.json
index 9429e16..11d391c 100644
--- a/define.json
+++ b/define.json
@@ -1,7 +1,8 @@
 {
 &quot;autodetect&quot;: false,
 &quot;googleSheetsOptions&quot;: {
- &quot;skipLeadingRows&quot;: 1
+ &quot;skipLeadingRows&quot;: 1,
+ &quot;range&quot;: &quot;マスターデータ!A:E&quot;
 },
 &quot;ignoreUnknownValues&quot;: false,
 &quot;maxBadRecords&quot;: 0,
</pre>


一人開発の弊害ではありますが、こうやってアウトプットすることでこそ得られるフィードバックとも言えます。ある意味期待通りです。😄

次回以降も需要があれば発表したいと思います。

こんばんは id:masutaka26 です。本日、Looker User Meetup Online #8 で『BigQuery経由で使うGoogleスプレッドシートのスキーマ管理』の話をしてきました。Looker User Meetup は 5 回目の参加、発表は初めてです。いくつかネタはあったのですが、今回のテーマは「Lookerまでのデータデリバリー、みんなどうしてる？」ということもあり、この 2 年で確立した方法を紹介することとなりました。bq CLI ではなく、terraform で管理している方もいらっしゃいました。terraform の更新に追随するのはそれなりに大変だと思いますが、これならスキーマ定義と、実際のスキーマの差異検知は出来そうですね。「dbt seed」を使っている方もいらっしゃるようでした。今回 2 つの発表があった dbt ですが、全く触ったことがありません。😇あと、P24 で「BigQueryは一番左のシートしか参照できない」と書きましたが、誤りでした。範囲にでシート名も指定すれば出来ることを確認しました。P10 で華麗に「シート範囲」を無視してますね。💦P18 の Gist との差分は以下になります。diff --git a/define.json b/define.jsonindex 9429e16..11d391c 100644--- a/define.json+++ b/define.json@@ -1,7 +1,8 @@ {   "autodetect": false,   "googleSheetsOptions": {-    "skipLeadingRows": 1+    "skipLeadingRows": 1,+    "range": "マスターデータ!A:E"   },   "ignoreUnknownValues": false,   "maxBadRecords": 0,一人開発の弊害ではありますが、こうやってアウトプットすることでこそ得られるフィードバックとも言えます。ある意味期待通りです。😄次回以降も需要があれば発表したいと思います。

Looker User Meetup Online #8 で『BigQuery経由で使うGoogleスプレッドシートのスキーマ管理』の話をした

こんにちは、<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。<a href="https://developer.feedforce.jp/entry/2022/06/17/110000">先週</a>に引き続いてのブログ更新です。

Ruby や JavaScript などのプログラミング言語では、依存関係を管理することでコードの再利用性を高めるとともに、バグの少ないコードを書くことが出来ます。ただ、<a href="https://docs.looker.com/ja/data-modeling/learning-lookml/what-is-lookml">LookML</a> はプログラミング言語ではないため、同じ方法が使えません。

今回は LAMS という LookML Linter を導入することで、LookML の再利用性を高める糸口を見つけました。LAMS を紹介しつつ、その知見を共有します。

<ul class="table-of-contents">
 <li><a href="#LAMS-とは">LAMS とは</a></li>
 <li><a href="#導入方法">導入方法</a></li>
 <li><a href="#ルールの免除">ルールの免除</a></li>
 <li><a href="#LookML-の再利用性を高められた-F1-ルール">LookML の再利用性を高められた F1 ルール</a></li>
 <li><a href="#注意事項">注意事項</a></li>
 <li><a href="#まとめ">まとめ</a></li>
</ul>

<h2 id="LAMS-とは">LAMS とは</h2>

LAMS (Look At Me Sideways) は LookML のスタイルガイドと Linter がセットになったツールです。準公式のツールなのかな？

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Flooker-open-source%2Flook-at-me-sideways" title="GitHub - looker-open-source/look-at-me-sideways: A style guide and linter for Looker&#39;s LookML data modeling language" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/looker-open-source/look-at-me-sideways">github.com</a></cite>

LookML IDE に付属する LookML validator が文法的な誤りを検出するのに対して、LAMS はメンテナンス性の高い、もう一歩進んだ LookML を提案します。

2022-06-21 現在、4 グループ、32 個のルールが定義されています。

🔗 <a href="https://looker-open-source.github.io/look-at-me-sideways/rules.html">LAMS Style Guide</a>

<ul>
<li>Key Dimensions (K1 ~ K6)</li>
<li>Other Fields (F1 ~ F6)</li>
<li>Derived Tables (T1 ~ T15)</li>
<li>Explores (E1 ~ E5)</li>
</ul>


<h2 id="導入方法">導入方法</h2>

Linter を後から導入するのは辛いので、可能ならリポジトリを作るタイミングで導入するのが良いと思います。

<a href="https://github.com/looker-open-source/look-at-me-sideways#deployment-examples">README の Deployment Examples</a> には、ローカルマシンで実行する方法や、GitHub Actions や CircleCI などで CI する方法がまとまっています。

今回は GitHub Actions を採用しました。git push するたびに LAMS が実行され、結果を Pull request 上で確認出来ます。参考までにコードを貼っておきます。

.github/workflows/ci.yml

<pre class="code lang-yaml" data-lang="yaml" data-unlink>name: CI

on: push

jobs:
 lams:
 name: LAMS LookML Linter
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 - uses: actions/setup-node@v3
 with:
 node-version: '16' # Use LTS https://nodejs.org/en/
 - name: Install LAMS
 run: npm install -g @looker/look-at-me-sideways@2
 - name: Run LAMS
 env:
 LOOKER_LICENSE_KEY: ${{ secrets.LOOKER_LICENSE_KEY }}
 run: make lams
</pre>


Makefile <a href="#fn:1" rel="footnote">1</a>

<pre class="code makefile" data-lang="makefile" data-unlink>LAMS := lams
LOOKER_LICENSE_KEY := ${LOOKER_LICENSE_KEY}
REPORT_USER := feedmatic_report@example.com
SOURCE := **/{*.model,*.explore,*.view,*.layer,manifest}.lkml

.PHONY: lams
lams:
 @$(LAMS) --reporting=yes --report-license-key=$(LOOKER_LICENSE_KEY) --report-user=$(REPORT_USER) --source=&#39;$(SOURCE)&#39;</pre>


<h2 id="ルールの免除">ルールの免除</h2>

manifest.lkml にこのように書くと、プロジェクト全体で任意のルールを免除することが出来ます。

<pre class="code" data-lang="" data-unlink># LAMS
# rule_exemptions: {
# F2: &#34;Any explanatory message you would like&#34;
# F3: &#34;Another explanatory message for a different rule&#34;
# }</pre>


dimension, measure, derived_table 単位でも免除することが出来ます。基本はこちらで免除し、無理そうなら manifest.lkml で免除すると良いでしょう。

初めから全てのルールをパスすることは少ないと思うので、必要に応じて免除すると良いでしょう。また、LAMS はあくまでスタイルガイドなので、必ずしも全てのルールに対応する必要はありません。

<h2 id="LookML-の再利用性を高められた-F1-ルール">LookML の再利用性を高められた F1 ルール</h2>

32 個のルールのうち、今回は個人的に一番意義というか、感心した <a href="https://looker-open-source.github.io/look-at-me-sideways/rules.html#f1">F1</a> ルールを紹介します。

例えば orders.view から users.view の <code>count</code> measure を参照する、以下のような LookML があったとします。

LookML 書き始めの頃はこのように書きがちかと思いますが、F1 ルールでは NG です。orders.view が users.view に依存してしまうことで、orders.view の再利用がし辛くなるからです。そもそもこのケースでは LookML validation もエラーになるはずです。<a href="#fn:2" rel="footnote">2</a>

<pre class="code" data-lang="" data-unlink>view: users {...}

view: orders {
 ...
 measure: orders_per_user {
 sql: ${count} / NULLIF(${users.count},0)
 }
}

explore: orders {} # Errors :(

explore: users {
 join: orders {...}
}</pre>


解決方法がこちらです。まず、依存フィールドだけを抽出した users_orders.view を作ります。この view では sql_table_name や derived_table を設定しません。

<pre class="code" data-lang="" data-unlink>view: users {...}
view: orders {...}

view: users_orders {
 # No need for a sql_table_name or derived_table
 measure: orders_per_user {
 sql: ${orders.count} / NULLIF(${users.count},0)
 }
}</pre>


こうすることで少なくとも orders.explore は users.view に依存しないクリーンな LookML になりました。

<pre class="code" data-lang="" data-unlink>explore: orders {} # Doesn&#39;t break like before!</pre>


次に users.explore で魔法を使います。users.view と users_orders.view の Join で通常指定するはずの <code>sql_on ... ;;</code> の代わりに、空の SQL <code>sql: ;;</code> を指定します。

<pre class="code" data-lang="" data-unlink>explore: users {
 join: orders {...}
 join: users_orders {
 sql: ;;
 # Use `sql` instead of `sql_on` and put some whitespace in it
 relationship: one_to_one
 view_label: &#34;Orders&#34; # For cleaner explore UI
 }
}</pre>


え？と思うかもしれませんが、これは妥当な LookML です。

Users explore が生成する SQL を確認すると分かりますが、<code>orders_per_user</code> measure を選択しても Join 句は増えません。しかしこの measure が参照するテーブルは既存の users と orders だけなので、構文エラーになりません。

初見での理解は難しくなりますが、orders.view の再利用性が高まるのは大きなメリットです。

<h2 id="注意事項">注意事項</h2>

<a href="https://looker-open-source.github.io/look-at-me-sideways/rules.html#k1">K1</a> と <a href="https://looker-open-source.github.io/look-at-me-sideways/rules.html#k2">K2</a> のように、一部のルールには依存関係があり、一方を免除するためには両方免除する必要があります。

あと、まだ <a href="https://docs.looker.com/reference/view-params/extension-for-view">Extension</a> と <a href="https://docs.looker.com/ja/data-modeling/learning-lookml/refinements">Refinements</a> に対応していません。Issue <a href="https://github.com/looker-open-source/look-at-me-sideways/issues/46">#46</a> によると、<a href="https://github.com/fabio-looker/node-lookml-parser">パーサー</a>側は対応したそうで、あとは LAMS 本体を対応するだけだそうです。割と致命的な課題...。

<h2 id="まとめ">まとめ</h2>

LookML の Linter である LAMS を紹介しました。うまく使うことで、再利用性やメンテナンス性の高い LookML を書くことが出来るかもしれません。

それでは良い Looker ライフを！(^^)/
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
Makefile を作ったのは、ローカルで実行しやすくするためです。<a href="#fnref:1" rev="footnote">&#8617;</a></li>
<li id="fn:2">
<a href="https://help.looker.com/hc/en-us/articles/360023586293-Error-Unknown-or-Inaccessible-Field">F1 ルールに従わずにエラーを回避する方法はあります。</a><a href="#fnref:2" rev="footnote">&#8617;</a></li>
</ol>
</div>

こんにちは、id:masutaka26 です。先週に引き続いてのブログ更新です。Ruby や JavaScript などのプログラミング言語では、依存関係を管理することでコードの再利用性を高めるとともに、バグの少ないコードを書くことが出来ます。ただ、LookML はプログラミング言語ではないため、同じ方法が使えません。今回は LAMS という LookML Linter を導入することで、LookML の再利用性を高める糸口を見つけました。LAMS を紹介しつつ、その知見を共有します。LAMS とは導入方法ルールの免除LookML の再利用性を高められた F1 ルール注意事項まとめLAMS とはLAMS (Look At Me Sideways) は LookML のスタイルガイドと Linter がセットになったツールです。準公式のツールなのかな？github.comLookML IDE に付属する LookML validator が文法的な誤りを検出するのに対して、LAMS はメンテナンス性の高い、もう一歩進んだ LookML を提案します。2022-06-21 現在、4 グループ、32 個のルールが定義されています。🔗 LAMS Style GuideKey Dimensions (K1 ~ K6)Other Fields (F1 ~ F6)Derived Tables (T1 ~ T15)Explores (E1 ~ E5)導入方法Linter を後から導入するのは辛いので、可能ならリポジトリを作るタイミングで導入するのが良いと思います。README の Deployment Examples には、ローカルマシンで実行する方法や、GitHub Actions や CircleCI などで CI する方法がまとまっています。今回は GitHub Actions を採用しました。git push するたびに LAMS が実行され、結果を Pull request 上で確認出来ます。参考までにコードを貼っておきます。.github/workflows/ci.ymlname: CIon: pushjobs:  lams:    name: LAMS LookML Linter    runs-on: ubuntu-latest    steps:    - uses: actions/checkout@v3    - uses: actions/setup-node@v3      with:        node-version: '16' # Use LTS https://nodejs.org/en/    - name: Install LAMS      run: npm install -g @looker/look-at-me-sideways@2    - name: Run LAMS      env:        LOOKER_LICENSE_KEY: ${{ secrets.LOOKER_LICENSE_KEY }}      run: make lamsMakefile 1LAMS := lamsLOOKER_LICENSE_KEY := ${LOOKER_LICENSE_KEY}REPORT_USER := feedmatic_report@example.comSOURCE := **/{*.model,*.explore,*.view,*.layer,manifest}.lkml.PHONY: lamslams:    @$(LAMS) --reporting=yes --report-license-key=$(LOOKER_LICENSE_KEY) --report-user=$(REPORT_USER) --source='$(SOURCE)'ルールの免除manifest.lkml にこのように書くと、プロジェクト全体で任意のルールを免除することが出来ます。# LAMS# rule_exemptions: {#  F2: "Any explanatory message you would like"#  F3: "Another explanatory message for a different rule"# }dimension, measure, derived_table 単位でも免除することが出来ます。基本はこちらで免除し、無理そうなら manifest.lkml で免除すると良いでしょう。初めから全てのルールをパスすることは少ないと思うので、必要に応じて免除すると良いでしょう。また、LAMS はあくまでスタイルガイドなので、必ずしも全てのルールに対応する必要はありません。LookML の再利用性を高められた F1 ルール32 個のルールのうち、今回は個人的に一番意義というか、感心した F1 ルールを紹介します。例えば orders.view から users.view の count measure を参照する、以下のような LookML があったとします。LookML 書き始めの頃はこのように書きがちかと思いますが、F1 ルールでは NG です。orders.view が users.view に依存してしまうことで、orders.view の再利用がし辛くなるからです。そもそもこのケースでは LookML validation もエラーになるはずです。2view: users {...}view: orders {  ...  measure: orders_per_user {    sql: ${count} / NULLIF(${users.count},0)  }}explore: orders {} # Errors :(explore: users {  join: orders {...}}解決方法がこちらです。まず、依存フィールドだけを抽出した users_orders.view を作ります。この view では sql_table_name や derived_table を設定しません。view: users {...}view: orders {...}view: users_orders {  # No need for a sql_table_name or derived_table  measure: orders_per_user {    sql: ${orders.count} / NULLIF(${users.count},0)  }}こうすることで少なくとも orders.explore は users.view に依存しないクリーンな LookML になりました。explore: orders {} # Doesn't break like before!次に users.explore で魔法を使います。users.view と users_orders.view の Join で通常指定するはずの sql_on ... ;; の代わりに、空の SQL sql: ;; を指定します。explore: users {  join: orders {...}  join: users_orders {    sql: ;;    # Use `sql` instead of `sql_on` and put some whitespace in it    relationship: one_to_one    view_label: "Orders" # For cleaner explore UI  }}え？と思うかもしれませんが、これは妥当な LookML です。Users explore が生成する SQL を確認すると分かりますが、orders_per_user measure を選択しても Join 句は増えません。しかしこの measure が参照するテーブルは既存の users と orders だけなので、構文エラーになりません。初見での理解は難しくなりますが、orders.view の再利用性が高まるのは大きなメリットです。注意事項K1 と K2 のように、一部のルールには依存関係があり、一方を免除するためには両方免除する必要があります。あと、まだ Extension と Refinements に対応していません。Issue #46 によると、パーサー側は対応したそうで、あとは LAMS 本体を対応するだけだそうです。割と致命的な課題...。まとめLookML の Linter である LAMS を紹介しました。うまく使うことで、再利用性やメンテナンス性の高い LookML を書くことが出来るかもしれません。それでは良い Looker ライフを！(^^)/Makefile を作ったのは、ローカルで実行しやすくするためです。↩F1 ルールに従わずにエラーを回避する方法はあります。↩

LAMS を導入して、LookML の再利用性を高められた

こんにちは、<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。

今回は少し前に社内に共有した記事を、このブログでも共有します。Looker は Ruby や Python 等のプログラミング言語よりはユーザーが少ないはずで、質問相手がいないと本当に困ります。この記事がその一助になれば幸いです。

<ul class="table-of-contents">
 <li><a href="#ググる">ググる</a></li>
 <li><a href="#チャット">チャット</a></li>
 <li><a href="#問い合わせフォーム">問い合わせフォーム</a></li>
 <li><a href="#Looker-Community-en">Looker Community (en)</a></li>
 <li><a href="#Looker-Community-ja">Looker Community (ja)</a></li>
 <li><a href="#Slack-Looker-User-Group---Japan">Slack Looker User Group - Japan</a></li>
 <li><a href="#番外編-製品についてのアイディアがありますか">番外編: 製品についてのアイディアがありますか？</a></li>
 <li><a href="#まとめ">まとめ</a></li>
</ul>

<h2 id="ググる">ググる</h2>

さすがにこれは基本ですね。💦

<a href="https://docs.looker.com/ja">公式ドキュメント</a> に誘導されることもしばしばです。これが結構よく出来ています。<code>looker table calculation</code> などと英語でググると、解決にたどり着きやすいかもしれません。

マニアックなテクニックとして、ググった URL の後ろに <code>&amp;gl=us&amp;hl=en&amp;gws_rd=cr</code> を付け、検索対象を英語にして、日本語のノイズを減らす方法もあります。

<a href="https://www.google.com/search?q=looker+table+calculation&oq=looker+table+calculation&aqs=chrome..69i57.26j0j7&sourceid=chrome&ie=UTF-8">https://www.google.com/search?q=looker+table+calculation&oq=looker+table+calculation&aqs=chrome..69i57.26j0j7&sourceid=chrome&ie=UTF-8</a>

↓

<a href="https://www.google.com/search?q=looker+table+calculation&oq=looker+table+calculation&aqs=chrome..69i57.26j0j7&sourceid=chrome&ie=UTF-8&gl=us&hl=en&gws_rd=cr">https://www.google.com/search?q=looker+table+calculation&oq=looker+table+calculation&aqs=chrome..69i57.26j0j7&sourceid=chrome&ie=UTF-8&gl=us&hl=en&gws_rd=cr</a>

私はこんなブックマークレットを使っています。ちなみに名前は <code>en</code> です。

<pre class="code" data-lang="" data-unlink>javascript:location.href=location.href+&#39;&amp;gl=us&amp;hl=en&amp;gws_rd=cr&#39;</pre>


<h2 id="チャット">チャット</h2>

Admin 権限を持ったユーザーだけが使用できます。

日本語可ですが、日々混んでいるので急ぎでなければ次の「問い合わせフォーム」が良いと思います。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20220616/20220616165108.png" width="313" height="400" loading="lazy" title="" class="hatena-fotolife" itemprop="image">

<h2 id="問い合わせフォーム">問い合わせフォーム</h2>

<a href="https://help.looker.com/hc/en-us/requests">https://help.looker.com/hc/en-us/requests</a> から <code>Create a New Request</code> をクリックします。Looker ユーザーなら誰でも利用可能なのかな？日本語可です。

このフォームは割と最近知ったのですが、問い合わせてみたら翌日返信が来て、速やかに解決できました。急がない時はチャットより良いと思います。サポートの方も時間に追われなくて良さそうです。

今までのチャット履歴もここで確認出来ます。これは知らなかった。

<h2 id="Looker-Community-en">Looker Community (en)</h2>

誰でも利用可能です。日本語不可。頻繁に投稿があります。

<a href="https://community.looker.com/">https://community.looker.com/</a>

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20220616/20220616173918.png" width="1200" height="489" loading="lazy" title="" class="hatena-fotolife" itemprop="image">

<h2 id="Looker-Community-ja">Looker Community (ja)</h2>

誰でも利用可能な日本語コミュニティです。稀に投稿があります。

<a href="https://community.looker.com/%E3%83%98%E3%83%AB%E3%83%97%E3%81%A8%E3%82%B5%E3%83%9D%E3%83%BC%E3%83%88-101">コミュニティフォーラム (Japanese) > ヘルプとサポート</a>

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20220616/20220616174114.png" width="1200" height="458" loading="lazy" title="" class="hatena-fotolife" itemprop="image">

⚠️ <a href="https://community.looker.com/%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A9%E3%83%A0-japanese-161">コミュニティフォーラム (Japanese) のトップ</a> で <code>Ask question / Create topic</code> ボタンをクリックすると en のほうにトピックが作られてしまいます。注意です。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20220616/20220616174411.png" width="1116" height="774" loading="lazy" title="" class="hatena-fotolife" itemprop="image">

このフォームが正解です。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20220616/20220616174446.png" width="1200" height="690" loading="lazy" title="" class="hatena-fotolife" itemprop="image">

<h2 id="Slack-Looker-User-Group---Japan">Slack Looker User Group - Japan</h2>

日本語の Slack コミュニティもあります。<a href="https://community.looker.com/%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9%E3%81%A8%E5%91%8A%E7%9F%A5-100/looker%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E4%BC%9Aslack%E3%81%AE%E3%81%94%E6%A1%88%E5%86%85-28903">今年の初め (2022-01-14) に作られました</a>。

<a href="https://join.slack.com/t/lookerusergroup-japan/shared_invite/zt-1auagto9i-cT2lV~cejC7MgxMrzvveow">この招待リンク</a>から参加出来ます。

<h2 id="番外編-製品についてのアイディアがありますか">番外編: 製品についてのアイディアがありますか？</h2>

新しい機能のアイディアを POST 出来る場所です。Admin 権限を持ったユーザーだけが使用できます。日本語不可です。

不具合も報告されることがあり、たまに 前述の「問い合わせフォーム」に誘導されています。それで知りました。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20220616/20220616175411.png" width="391" height="500" loading="lazy" title="" class="hatena-fotolife" itemprop="image">

<h2 id="まとめ">まとめ</h2>

私が知る限りの「Looker で困った時の解決手段」をまとめました。

以前紹介した情報収集も日々継続すれば、Looker のスキルはかなり高まる実感があります。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2021%2F08%2F16%2F150000" title="私が１年かけて辿り着いた Looker の情報収集方法を紹介する - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe>

それでは良い Looker ライフを！(^^)/

こんにちは、id:masutaka26 です。今回は少し前に社内に共有した記事を、このブログでも共有します。Looker は Ruby や Python 等のプログラミング言語よりはユーザーが少ないはずで、質問相手がいないと本当に困ります。この記事がその一助になれば幸いです。ググるチャット問い合わせフォームLooker Community (en)Looker Community (ja)Slack Looker User Group - Japan番外編: 製品についてのアイディアがありますか？まとめググるさすがにこれは基本ですね。💦公式ドキュメント に誘導されることもしばしばです。これが結構よく出来ています。looker table calculation などと英語でググると、解決にたどり着きやすいかもしれません。マニアックなテクニックとして、ググった URL の後ろに &gl=us&hl=en&gws_rd=cr を付け、検索対象を英語にして、日本語のノイズを減らす方法もあります。https://www.google.com/search?q=looker+table+calculation&oq=looker+table+calculation&aqs=chrome..69i57.26j0j7&sourceid=chrome&ie=UTF-8↓https://www.google.com/search?q=looker+table+calculation&oq=looker+table+calculation&aqs=chrome..69i57.26j0j7&sourceid=chrome&ie=UTF-8&gl=us&hl=en&gws_rd=cr私はこんなブックマークレットを使っています。ちなみに名前は en です。javascript:location.href=location.href+'&gl=us&hl=en&gws_rd=cr'チャットAdmin 権限を持ったユーザーだけが使用できます。日本語可ですが、日々混んでいるので急ぎでなければ次の「問い合わせフォーム」が良いと思います。問い合わせフォームhttps://help.looker.com/hc/en-us/requests から Create a New Request をクリックします。Looker ユーザーなら誰でも利用可能なのかな？日本語可です。このフォームは割と最近知ったのですが、問い合わせてみたら翌日返信が来て、速やかに解決できました。急がない時はチャットより良いと思います。サポートの方も時間に追われなくて良さそうです。今までのチャット履歴もここで確認出来ます。これは知らなかった。Looker Community (en)誰でも利用可能です。日本語不可。頻繁に投稿があります。https://community.looker.com/Looker Community (ja)誰でも利用可能な日本語コミュニティです。稀に投稿があります。コミュニティフォーラム (Japanese) > ヘルプとサポート⚠️ コミュニティフォーラム (Japanese) のトップ で Ask question / Create topic ボタンをクリックすると en のほうにトピックが作られてしまいます。注意です。このフォームが正解です。Slack Looker User Group - Japan日本語の Slack コミュニティもあります。今年の初め (2022-01-14) に作られました。この招待リンクから参加出来ます。番外編: 製品についてのアイディアがありますか？新しい機能のアイディアを POST 出来る場所です。Admin 権限を持ったユーザーだけが使用できます。日本語不可です。不具合も報告されることがあり、たまに 前述の「問い合わせフォーム」に誘導されています。それで知りました。まとめ私が知る限りの「Looker で困った時の解決手段」をまとめました。以前紹介した情報収集も日々継続すれば、Looker のスキルはかなり高まる実感があります。それでは良い Looker ライフを！(^^)/

Looker で困った時の解決手段まとめ

こんにちは、<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。

<a href="https://www.looker.com/">Looker</a> を使い始めて 3 年目に突入しました。変わらず <a href="https://feedmatic.net/">Feedmatic</a> という広告運用コンサルティングのデータ整備をする毎日です。

今回はここ 1 年の懸案だった LookML Validation の堪え難い遅さを改善出来たので、共有します。

<ul class="table-of-contents">
 <li><a href="#2-年間でコード量が肥大化した">2 年間でコード量が肥大化した</a></li>
 <li><a href="#LookML-Validation-が堪え難いほど遅くなった">LookML Validation が堪え難いほど遅くなった</a></li>
 <li><a href="#My-LookML-Validator-is-slow">My LookML Validator is slow!</a><ul>
 <li><a href="#TLDR">TL;DR</a></li>
 <li><a href="#Quick-wins">Quick wins</a></li>
 <li><a href="#Long-answer">Long answer</a></li>
 <li><a href="#Bonus-note">Bonus note</a></li>
 </ul>
 </li>
 <li><a href="#include-を最適化したら半分弱の時間になった">include を最適化したら半分弱の時間になった</a></li>
 <li><a href="#まとめ">まとめ</a></li>
 <li><a href="#余談">余談</a></li>
 <li><a href="#追記-LAMS-を使って-wildcard-include-を禁止する">追記: LAMS を使って wildcard include を禁止する</a></li>
</ul>

<h2 id="2-年間でコード量が肥大化した">2 年間でコード量が肥大化した</h2>

2 年前と比べて Feedmatic プロジェクトの <code>.lkml</code> ファイルがものすごく増え、440 個、23,217 行<a href="#fn:1" rel="footnote">1</a>にもなりました。Explore は 62 個、<a href="/entry/2021/08/30/150000">テスト用</a>も含めると 150 個もあります。相変わらず<a href="/entry/2022/02/04/180000">ボッチ LookML 開発者</a>ではあるのですが。💦

さて、<a href="/entry/2020/10/23/190000">Looker の JumpStart</a> で教えて頂いた「モデル編成のベストプラクティス」のうちの 1 つにこちらがありました。

<blockquote>ユーザーが必要とする答えに簡単にアクセスできる、可能な限り少ない数の explore を使用する。</blockquote>

しかし、広告運用の文脈だと、クライアントごとに独自実装が必要なケースが多く、このコード量になってしまいました。💦

<h2 id="LookML-Validation-が堪え難いほど遅くなった">LookML Validation が堪え難いほど遅くなった</h2>

そんな LookML 開発に使用する Looker IDE には LookML Validator が付属しており、git commit 前に強制する設定をしています。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.looker.com%2Fja%2Fdata-modeling%2Fgetting-started%2Flookml-validation%23validating_your_lookml" title="Editing and validating LookML" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://docs.looker.com/ja/data-modeling/getting-started/lookml-validation#validating_your_lookml">docs.looker.com</a></cite>

以前は一瞬で完了していましたが、最近は 20 秒以上かかります。ちょっとコメントを書き換えただけでこれだけ待たされるのは、なかなかの苦行です。

試作した別プロジェクト（41 ファイル、1999 行）はそんなにかからないため、単純にコード量に比例していると思いました。

念のため Looker のサポートに質問したところ、やはりコード量（プロジェクトのサイズ）が影響しているそう。そして Looker インスタンスの CPU やメモリ使用量に問題はないとのこと。

さらに、こちらの記事を紹介して頂きました。🙏

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcommunity.looker.com%2Ftechnical-tips-tricks-1021%2Fmy-lookml-validator-is-slow-23592" title="My LookML Validator is slow! | Looker Community" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://community.looker.com/technical-tips-tricks-1021/my-lookml-validator-is-slow-23592">community.looker.com</a></cite>

<h2 id="My-LookML-Validator-is-slow">My LookML Validator is slow!</h2>

長い記事ではないので、ざっと翻訳します。

<h3 id="TLDR">TL;DR</h3>

プロジェクトが大きければ大きいほど、検証には時間がかかります。

<h3 id="Quick-wins">Quick wins</h3>

<ol>
<li>戦略的に "includes" する

<ol>
<li>常に他のすべてのビューをインクルードすることは開発上簡単かもしれないが、命名規則を使って必要なファイルだけを戦略的にインクルードすることで、パフォーマンスを向上させることができる</li>
</ol>
</li>
<li>使用しない explore（および join、field など）をコメントアウトまたは削除する</li>
<li>プロジェクトを複数のプロジェクトに分割することを検討する</li>
</ol>


LookML のベストプラクティスについては、<a href="https://community.looker.com/lookml-5/lookml-best-practices-1636">こちらの記事</a>をご覧ください。

<h3 id="Long-answer">Long answer</h3>

LookML のプロジェクトサイズ（総行数）と不要な <code>include</code> の両方が LookML Validator の性能に影響を及ぼします。

Validation は 2 段階のプロセスで行われます。

1) 1 回目の検証では、プロジェクト内のすべてのファイルを読み込み、どこにも参照されていないファイルも含めて、メモリに読み込み、ソースコードを 1 モデルずつ完全に翻訳して、「コンパイル」エラーを探します。

2) 2 回目の検証は、各モデルで開始し、そのモデルから参照されるファイルのみを解析します。そして、そのモデルに基づいてクエリーを構築し、クエリーエラーや「実行時」エラーを探します。また、これらのパスは、すべての検証で行われることも重要です。

結論として、1 回目の検証は LookML プロジェクトのサイズに、2 回目の検証は不要な <code>include</code> 文に影響されます。したがって、LookML プロジェクトのサイズを適切に保つと同時に、より選択的かつ戦略的な <code>include</code> を推奨するのが良いでしょう。

<h3 id="Bonus-note">Bonus note</h3>

Explore ごとのフィールド数は、検証時間という点で非常に重要です。これはしばしばモデルのパースよりも時間がかかります。

<h2 id="include-を最適化したら半分弱の時間になった">include を最適化したら半分弱の時間になった</h2>

今回は「戦略的に "includes" する」をやってみました。

具体的には 56 個の <code>.explore.lkml</code> ファイルを以下のように変更しました。ワイルドカード付きの <code>include</code> を出来るだけ減らしました。

<pre class="code" data-lang="" data-unlink># 変更前
include: &#34;/views/**/*.view&#34;

↓

# 変更後
include: &#34;/views/view1.view&#34;
include: &#34;/views/view2.view&#34;
include: &#34;/views/view3.view&#34;
include: &#34;/views/view4.view&#34;
include: &#34;/views/view5.view&#34;</pre>


結果がこちら。たったこれだけで、20 秒かかっていた LookML validation が 12 秒弱にまで縮まりました。期待以上です！👏😂🎉

<table>
<thead>
<tr>
<th style="text-align:right;"> </th>
<th style="text-align:right;"> 変更前（秒） </th>
<th style="text-align:right;"> 変更後（秒） </th>
</tr>
</thead>
<tbody>
<tr>
<td style="text-align:right;"> 1 </td>
<td style="text-align:right;"> 20.46 </td>
<td style="text-align:right;"> 12.39 </td>
</tr>
<tr>
<td style="text-align:right;"> 2 </td>
<td style="text-align:right;"> 20.44 </td>
<td style="text-align:right;"> 11.89 </td>
</tr>
<tr>
<td style="text-align:right;"> 3 </td>
<td style="text-align:right;"> 20.05 </td>
<td style="text-align:right;"> 11.69 </td>
</tr>
<tr>
<td style="text-align:right;"> 3 </td>
<td style="text-align:right;"> 20.61 </td>
<td style="text-align:right;"> 11.65 </td>
</tr>
<tr>
<td style="text-align:right;"> 5 </td>
<td style="text-align:right;"> 20.48 </td>
<td style="text-align:right;"> 11.95 </td>
</tr>
<tr>
<td style="text-align:right;"> 平均 </td>
<td style="text-align:right;"> 20.41 </td>
<td style="text-align:right;"> 11.91 </td>
</tr>
</tbody>
</table>


ついでに、事情があって隠している Explore 10 個<a href="#fn:2" rel="footnote">2</a>の削除を確認してみたら、さらに速くなり、9 秒程度まで縮まりました。なるほど。

<h2 id="まとめ">まとめ</h2>

ここ 1 年の懸案だった LookML Validation のパフォーマンスを改善しました。

include を最適化するだけで、ここまで速くなるとは驚きでした。おまけに LookML Validation のプロセスも理解することもできました。

💭 コンパイラ側で良しなにするのは難しいのかな、<a href="https://github.com/looker-open-source/look-at-me-sideways">LAMS</a> で警告してくれれば良いのかな。

引き続き、LookML 開発を妨げる課題があれば、解決していきます。💪

<h2 id="余談">余談</h2>

<code>Validate LookML</code> をクリックすると、すぐ <code>Validate LookML</code> に戻ることがあるのですが、なんででしょう...？ファイル保存直後だとほぼ発生します。

<img src="https://user-images.githubusercontent.com/170014/170627597-55819ca6-7394-4900-9e33-9ed0c1ce2492.gif" alt="looker" />

Validation が終わる時間くらいまで待つと 2 回クリックしなくて良いみたいです。🙄

<img src="https://user-images.githubusercontent.com/170014/170627672-f1bf212b-ab73-48f3-9feb-4e8f751984b6.gif" alt="looker2" />

<h2 id="追記-LAMS-を使って-wildcard-include-を禁止する">追記: LAMS を使って wildcard include を禁止する</h2>

LookML の Linter として LAMS というものがあります。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2022%2F06%2F21%2F130000" title="LAMS を導入して、LookML の再利用性を高められた - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2022/06/21/130000">developer.feedforce.jp</a></cite>

このカスタムルールを定義することで、今回のようなワイルドカード付きの <code>include</code> を禁止することが出来ます。

manifest.lkml にこのように書くだけです。

<pre class="code" data-lang="" data-unlink># LAMS
# rule: NO_WINC {
# description: &#34;Prohibit wildcard include to avoid increasing LookML verification time&#34;
# match: &#34;$.files.*.include.*&#34;
# expr_rule: ($let file_path ($get ::project files ::path:2 $file_path))
# ($if ($match &#34;\\*&#34; ::match)
# ($concat &#34;Found wildcard include &#39;&#34; ::match &#34;&#39; in &#34; ::file_path &#34;&#34;)
# true) ;;
# }</pre>


<a href="https://looker-open-source.github.io/look-at-me-sideways/customizing-lams">Customizing LAMS</a> にさらりと書いてありますが、指摘されたファイル名を出す方法が分からなかったので、Issue <a href="https://github.com/looker-open-source/look-at-me-sideways/issues/95">#95</a> で質問したら分かりました。これは分からない。💦
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
コメントと空行を除く<a href="#fnref:1" rev="footnote">&#8617;</a></li>
<li id="fn:2">
<code>.explore.lkml</code> 10 個、<code>.view.lkml</code> 10 個、<code>.layer.lkml</code> 31 個<a href="#fnref:2" rev="footnote">&#8617;</a></li>
</ol>
</div>

こんにちは、id:masutaka26 です。Looker を使い始めて 3 年目に突入しました。変わらず Feedmatic という広告運用コンサルティングのデータ整備をする毎日です。今回はここ 1 年の懸案だった LookML Validation の堪え難い遅さを改善出来たので、共有します。2 年間でコード量が肥大化したLookML Validation が堪え難いほど遅くなったMy LookML Validator is slow!TL;DRQuick winsLong answerBonus noteinclude を最適化したら半分弱の時間になったまとめ余談追記: LAMS を使って wildcard include を禁止する2 年間でコード量が肥大化した2 年前と比べて Feedmatic プロジェクトの .lkml ファイルがものすごく増え、440 個、23,217 行1にもなりました。Explore は 62 個、テスト用も含めると 150 個もあります。相変わらずボッチ LookML 開発者ではあるのですが。💦さて、Looker の JumpStart で教えて頂いた「モデル編成のベストプラクティス」のうちの 1 つにこちらがありました。ユーザーが必要とする答えに簡単にアクセスできる、可能な限り少ない数の explore を使用する。しかし、広告運用の文脈だと、クライアントごとに独自実装が必要なケースが多く、このコード量になってしまいました。💦LookML Validation が堪え難いほど遅くなったそんな LookML 開発に使用する Looker IDE には LookML Validator が付属しており、git commit 前に強制する設定をしています。docs.looker.com以前は一瞬で完了していましたが、最近は 20 秒以上かかります。ちょっとコメントを書き換えただけでこれだけ待たされるのは、なかなかの苦行です。試作した別プロジェクト（41 ファイル、1999 行）はそんなにかからないため、単純にコード量に比例していると思いました。念のため Looker のサポートに質問したところ、やはりコード量（プロジェクトのサイズ）が影響しているそう。そして Looker インスタンスの CPU やメモリ使用量に問題はないとのこと。さらに、こちらの記事を紹介して頂きました。🙏community.looker.comMy LookML Validator is slow!長い記事ではないので、ざっと翻訳します。TL;DRプロジェクトが大きければ大きいほど、検証には時間がかかります。Quick wins戦略的に "includes" する常に他のすべてのビューをインクルードすることは開発上簡単かもしれないが、命名規則を使って必要なファイルだけを戦略的にインクルードすることで、パフォーマンスを向上させることができる使用しない explore（および join、field など）をコメントアウトまたは削除するプロジェクトを複数のプロジェクトに分割することを検討するLookML のベストプラクティスについては、こちらの記事をご覧ください。Long answerLookML のプロジェクトサイズ（総行数）と不要な include の両方が LookML Validator の性能に影響を及ぼします。Validation は 2 段階のプロセスで行われます。1) 1 回目の検証では、プロジェクト内のすべてのファイルを読み込み、どこにも参照されていないファイルも含めて、メモリに読み込み、ソースコードを 1 モデルずつ完全に翻訳して、「コンパイル」エラーを探します。2) 2 回目の検証は、各モデルで開始し、そのモデルから参照されるファイルのみを解析します。そして、そのモデルに基づいてクエリーを構築し、クエリーエラーや「実行時」エラーを探します。また、これらのパスは、すべての検証で行われることも重要です。結論として、1 回目の検証は LookML プロジェクトのサイズに、2 回目の検証は不要な include 文に影響されます。したがって、LookML プロジェクトのサイズを適切に保つと同時に、より選択的かつ戦略的な include を推奨するのが良いでしょう。Bonus noteExplore ごとのフィールド数は、検証時間という点で非常に重要です。これはしばしばモデルのパースよりも時間がかかります。include を最適化したら半分弱の時間になった今回は「戦略的に "includes" する」をやってみました。具体的には 56 個の .explore.lkml ファイルを以下のように変更しました。ワイルドカード付きの include を出来るだけ減らしました。# 変更前include: "/views/**/*.view"↓# 変更後include: "/views/view1.view"include: "/views/view2.view"include: "/views/view3.view"include: "/views/view4.view"include: "/views/view5.view"結果がこちら。たったこれだけで、20 秒かかっていた LookML validation が 12 秒弱にまで縮まりました。期待以上です！👏😂🎉  変更前（秒）  変更後（秒）  1  20.46  12.39  2  20.44  11.89  3  20.05  11.69  3  20.61  11.65  5  20.48  11.95  平均  20.41  11.91 ついでに、事情があって隠している Explore 10 個2の削除を確認してみたら、さらに速くなり、9 秒程度まで縮まりました。なるほど。まとめここ 1 年の懸案だった LookML Validation のパフォーマンスを改善しました。include を最適化するだけで、ここまで速くなるとは驚きでした。おまけに LookML Validation のプロセスも理解することもできました。💭 コンパイラ側で良しなにするのは難しいのかな、LAMS で警告してくれれば良いのかな。引き続き、LookML 開発を妨げる課題があれば、解決していきます。💪余談Validate LookML をクリックすると、すぐ Validate LookML に戻ることがあるのですが、なんででしょう...？ファイル保存直後だとほぼ発生します。Validation が終わる時間くらいまで待つと 2 回クリックしなくて良いみたいです。🙄追記: LAMS を使って wildcard include を禁止するLookML の Linter として LAMS というものがあります。developer.feedforce.jpこのカスタムルールを定義することで、今回のようなワイルドカード付きの include を禁止することが出来ます。manifest.lkml にこのように書くだけです。# LAMS# rule: NO_WINC {#  description: "Prohibit wildcard include to avoid increasing LookML verification time"#  match: "$.files.*.include.*"#  expr_rule: ($let file_path ($get ::project files ::path:2 $file_path))#             ($if ($match "\\*" ::match)#                 ($concat "Found wildcard include '" ::match "' in " ::file_path "")#               true) ;;# }Customizing LAMS にさらりと書いてありますが、指摘されたファイル名を出す方法が分からなかったので、Issue #95 で質問したら分かりました。これは分からない。💦コメントと空行を除く↩.explore.lkml 10 個、.view.lkml 10 個、.layer.lkml 31 個↩

LookML Validation を 20 秒から 11 秒に高速化出来た

私が所属しているフィードフォースでは、毎月 FFLT という LT 大会があります。
最近久しぶりに参加していて、昨日は本当に久しぶりに LT をしました。久しぶりすぎて LT が 5 分であることを気にかけなかったという&hellip;。いや、もちろん覚えてはいたのですが（汗）。
お題は [2022-03-06-1] や [2022-03-30-1] でそれとなく書いていた「Kindle 本を聴く」方法です。
すべてのケースに合うわけでも、ベストな方法でもありませんが、集中力が必要で眠くなりがちな本を読むという作業を省エネ化出来たことは、自分にとって価値あるものでした。
まだまだ最適化が必要なので、やっていきます。

私が所属しているフィードフォースでは、毎月 FFLT という LT 大会があります。最近久しぶりに参加していて、昨日は本当に久しぶりに LT をしました。久しぶりすぎて LT が 5 分であることを気にかけなかったという…。いや、もちろん覚えてはいたのですが（汗）。お題は [2022-03-06-1] や [2022-03-30-1] でそれとなく書いていた「Kindle 本を聴く」方法です。すべてのケースに合うわけでも、ベストな方法でもありませんが、集中力が必要で眠くなりがちな本を読むという作業を省エネ化出来たことは、自分にとって価値あるものでした。まだまだ最適化が必要なので、やっていきます。

『本を聴く毎日を送っています』という LT をした

こんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。

本日、週次の社内勉強会 <a href="https://developer.feedforce.jp/archive/category/FFTT">FFTT</a> で『ボッチLookML開発者兼データ整備人を連れてきたよ！』というひどいタイトルの発表をしました。

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vTv911SmUBM9fAk-IKQM9139Q29fU7INnUHwbFeOBxolqyybPdlcFHW2dAHBTgr3P9J_kL0Xdhbe38L/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="410" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


2020 年 4 月から Looker に関わって得たことをまとめた内容であるとともに、1 年半近く前からのアップデートになります。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2020%2F10%2F23%2F190000" title="『4月から取り組んできたLookerの導入から実装までのお話（Redashとも比較）』という発表をした - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2020/10/23/190000">developer.feedforce.jp</a></cite>

世に出ている Looker の情報はキラキラしているものが多く、ツラい話をそれほど目にしません。<s>絶対にあるはずなのに！😭</s>

それならば！とツラい話や解決が困難な話を散りばめさせてもらいました。課題が共有されて初めて知見が役に立つと思いますからね。解決した課題もあるよ（小声）。

それでは良い週末を！(^^)/

こんにちは id:masutaka26 です。本日、週次の社内勉強会 FFTT で『ボッチLookML開発者兼データ整備人を連れてきたよ！』というひどいタイトルの発表をしました。2020 年 4 月から Looker に関わって得たことをまとめた内容であるとともに、1 年半近く前からのアップデートになります。developer.feedforce.jp世に出ている Looker の情報はキラキラしているものが多く、ツラい話をそれほど目にしません。絶対にあるはずなのに！😭それならば！とツラい話や解決が困難な話を散りばめさせてもらいました。課題が共有されて初めて知見が役に立つと思いますからね。解決した課題もあるよ（小声）。それでは良い週末を！(^^)/

『ボッチLookML開発者兼データ整備人を連れてきたよ！』という発表をした

こんにちは、<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。

この記事は Looker Advent Calendar 2021 の 13 日目の記事です。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Fadvent-calendar%2F2021%2Flooker" title="Calendar for Looker | Advent Calendar 2021 - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://qiita.com/advent-calendar/2021/looker">qiita.com</a></cite>

昨日は Yappli 阿部さんの「<a href="https://tech.yappli.io/entry/2021/12/12/Sexy_Tech_for_You_9">Lookerの目標値やストップワードを、Googleスプレッドシート連携でお手軽管理【Sexy Tech for You #9】</a>」でした。Looker を使うとこのような LookML を書くだけで、ビジネスユーザーが SQL を書くことなく、本業に集中できるのはとても良いですよね。

個人的には、SQL ベースの派生テーブルの中で join するよりも、explore で join したほうが Looker らしく、メンテナンス性が良い気がしました。<a href="https://help.looker.com/hc/en-us/articles/360023722974">symmetric 集計</a>が働くため、ファンアウトも避けられます。wikipedia テーブルに関しては、永続的な派生テーブル（PDT）を使って BigQuery のスキャンサイズを抑えるのも良さそうです。

、、、( ﾟдﾟ)ハッ！ついマジレスをしてしまいました。💦

今回は dimension が null の measure を（0 ではなく）ø にする少しマニアックな記事を書く予定でしたが、先日の <a href="https://looker-japan-user-group.connpass.com/event/233775/">Looker User Meetup Online #7</a> で、LookML のディレクトリ構造を知りたいというチャットをお見かけしたので、今回はその話を書くことにしました。

<ul class="table-of-contents">
 <li><a href="#今回のプロジェクトの規模感">今回のプロジェクトの規模感</a></li>
 <li><a href="#デフォルトのディレクトリ構造">デフォルトのディレクトリ構造？</a></li>
 <li><a href="#特別なファイル形式を知る">特別なファイル形式を知る</a></li>
 <li><a href="#最近使っているディレクトリ構造">最近使っているディレクトリ構造</a><ul>
 <li><a href="#bigquery">bigquery/</a></li>
 <li><a href="#model1modellkml">model1.model.lkml</a></li>
 <li><a href="#explores">explores/</a></li>
 <li><a href="#views">views/</a></li>
 <li><a href="#tests">tests/</a></li>
 <li><a href="#manifestlkml">manifest.lkml</a></li>
 </ul>
 </li>
 <li><a href="#まとめ">まとめ</a></li>
 <li><a href="#2021-12-29-追記">2021-12-29 追記</a></li>
</ul>

<h2 id="今回のプロジェクトの規模感">今回のプロジェクトの規模感</h2>

プロジェクトの規模感によってディレクトリ構造は変わると思うので、先に書いておきます。

<ul>
<li>Looker インスタンスに 1 つだけ LookML プロジェクトが存在する</li>
<li>BigQuery Dataset 76 個</li>
<li><code>.lkml</code> ファイル 277 個

<ul>
<li><code>.model.lkml</code> ファイル 1 個</li>
<li><code>.explore.lkml</code> ファイル 56 個</li>
<li><code>.view.lkml</code> ファイル 139 個</li>
<li><code>.test.lkml</code> ファイル 78 個</li>
</ul>
</li>
<li>LookML 開発者 1 名</li>
</ul>


<h2 id="デフォルトのディレクトリ構造">デフォルトのディレクトリ構造？</h2>

この記事を書くまで誤解をしていたのですが、デフォルトのディレクトリ構造というものはなかったのですね。この記事を書くために改めて Blank Project を作ったら、ファイルもディレクトリも何もないプロジェクトが作られました。

モデルファイルを作るとこのようなコードが展開されるので、<code>.view.lkml</code> に関しては <code>/views/</code> 以下に作る方が多いと思います。私もそうでした。

<pre class="code" data-lang="" data-unlink>include: &#34;/views/*.view.lkml&#34; # include all views in the views/ folder in this project
# include: &#34;/**/*.view.lkml&#34; # include all views in this project
# include: &#34;my_dashboard.dashboard.lookml&#34; # include a lookml dashboard called my_dashboard</pre>


例えばこのようになります。

<pre class="code" data-lang="" data-unlink>feedmatic.model.lkml
views
├── all_media.view.lkml
└── ga.view.lkml</pre>


開発初期は <code>feedmatic.model.lkml</code> に view 以外の、explore や datagroup などをズラズラと書いていました。

<h2 id="特別なファイル形式を知る">特別なファイル形式を知る</h2>

ご存知の通り、LookML のファイル形式は <code>.lkml</code> です。

LookML 開発が続くと <code>.model.lkml</code> や <code>.view.lkml</code> などが増えていきますが、この中で唯一意味を持つのが <code>.model.lkml</code> です<a href="#fn:1" rel="footnote">1</a>。その他のファイル形式は整理のために自由に作ることが出来ます。

例えば <code>feedmatic.model.lkml</code> を作ると、<code>feedmatic</code> というモデルが定義されます。<code>https://{{your looker domain}}/projects</code> で確認できます。<code>all_media.view.lkml</code> を作っても、何かが作られるわけではありません。

以上の知識を持った上で、公式ドキュメントを読むと理解が深まるかもしれません。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.looker.com%2Fja%2Fdata-modeling%2Flearning-lookml%2Flookml-terms-and-concepts" title="LookMLの用語と概念" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe>

<h2 id="最近使っているディレクトリ構造">最近使っているディレクトリ構造</h2>

こんな感じです。それぞれ解説していきます。

<pre class="code" data-lang="" data-unlink>bigquery
├── spreadsheet1
│   ├── define.json
│   └── schema.json
└── spreadsheet2
 ├── define.json
 └── schema.json
model1.model.lkml
explores
├── corp
│   ├── base.explore.lkml
│   ├── name1.explore.lkml
│   └── name2.explore.lkml
├── explore1.explore.lkml
└── explore2.explore.lkml
views
├── corp
│   ├── base.view.lkml
│   ├── name1.view.lkml
│   └── name2.view.lkml
├── view1.view.lkml
└── view2.view.lkml
tests
└── model1
 ├── corp
 │   ├── name1.test.lkml
 │   └── name2.test.lkml
 ├── explore1.test.lkml
 └── explore2.test.lkml
manifest.lkml</pre>


<h3 id="bigquery">bigquery/</h3>

いきなり LookML 関係ありません。💦

BigQuery はデータソースに Google スプレッドシートを指定でき、そのスキーマ定義はコード化することが出来ます。

コード化することで変更履歴を Git で管理できますし、BigQuery CLI を使って簡単に Dataset や Table を作ったり、削除したりが出来ます。

<pre class="code" data-lang="" data-unlink>$ bq mk spreadsheet1
$ bq mk --external_table_definition=./define.json spreadsheet1.gsheet
$ bq rm -r spreadsheet1</pre>


破壊的な変更をする時は、バージョン名を付けた Dataset を新規作成し、LookML から参照先を変えます。こうすることで、本番環境に影響を与えずに開発することが出来ます。

<pre class="code" data-lang="" data-unlink>$ bq mk spreadsheet1_v2
$ bq mk --external_table_definition=./define.json spreadsheet1_v2.gsheet</pre>


スキーマ定義は公式ドキュメントをご覧下さい。需要があればそんな記事を書きます。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcloud.google.com%2Fconfig-connector%2Fdocs%2Freference%2Fresource-docs%2Fbigquery%2Fbigquerytable%3Fhl%3Dja" title="BigQueryTable  |  Config Connector Documentation  |  Google Cloud" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe>

他の Dataset は ETL ツール<a href="#fn:2" rel="footnote">2</a>が作るためコード化はしていません。

<h3 id="model1modellkml">model1.model.lkml</h3>

中心となるこのファイルは軽いです。本当にこの程度しか書いていません。

<pre class="code" data-lang="" data-unlink>connection: &#34;docs_bigquery_db&#34;

include: &#34;/explores/**/*.explore&#34;
include: &#34;/tests/model1/**/*.test&#34;

named_value_format: jpy_0 {
 value_format: &#34;\¥#,##0&#34;
}

named_value_format: jpy_1 {
 value_format: &#34;\¥#,##0.0&#34;
}

# for test
access_grant: can_view_explores_for_tests {
 user_attribute: view_explores_for_tests
 allowed_values: [&#34;yes&#34;]
}</pre>


必要な定義は <code>connection</code> と <code>include</code> だけです。

include 対象を全ての <code>.explore.lkml</code> と、このモデルに関連するテスト（<code>tests/feedmatic/</code> 以下全ての <code>.test.lkml</code>）だけにしていることがポイントです。つまり <code>.model.lkml</code> は <code>.explore.lkml</code> と自分の <code>.test.lkml</code> しか知りません。

あとは蛇足で、<code>named_value_format</code> と、<a href="/entry/2021/08/30/150000">前回紹介したテスト</a>に必要な <code>access_grant</code> だけです。

<h3 id="explores">explores/</h3>

1 つの explore を 1 つのファイルに定義しています。

<code>explores/explore1.explore.lkml</code> はこのように書いています。<code>.explore.lkml</code> は <code>.view.lkml</code> しか知りません。

<pre class="code" data-lang="" data-unlink>include: &#34;/views/**/*.view&#34;

explore: explore1 {
 # ...
}</pre>


紆余曲折あり、<code>explores/corp/name1.explore.lkml</code> のような取引先ごとの explore もあります。

基本となる <code>explores/corp/base.explore.lkml</code> はこのような定義です。ファイル名と explore 名を変えていることがポイントです。Ruby の慣習を参考にしました。

<pre class="code" data-lang="" data-unlink>explore: corp_base {
 extension: required
 # ...
}</pre>


<code>corp_base</code> explore を継承する、各取引先の explore はこのような定義です。

<pre class="code" data-lang="" data-unlink>include: &#34;./base.explore&#34;
include: &#34;/views/**/*.view&#34;

explore: corp_name1 {
 extends: [corp_base]
 # ...
}</pre>


<h3 id="views">views/</h3>

view も explore と同様に、1 view 1 ファイルに定義しています。

<code>views/view1.view.lkml</code> です。<code>.view.lkml</code> は <code>.model.lkml</code>, <code>.explore.lkml</code>, <code>.test.lkml</code> の誰も知りません。

<pre class="code" data-lang="" data-unlink>view: view1 {
 # ...
}</pre>


取引先ごとの view も同じです。<code>views/corp/base.view.lkml</code> はこんな感じで、

<pre class="code" data-lang="" data-unlink>view: corp_base {
 extension: required
 # ...
}</pre>


継承先の <code>views/corp/name1.view.lkml</code> はこんな感じです。

<pre class="code" data-lang="" data-unlink>include: &#34;./base.view&#34;

view: corp_name1 {
 extends: [corp_base]
 # ...
}</pre>


<h3 id="tests">tests/</h3>

テストはかなり書いており、2021-12-13 現在、184 もあります。

ほぼ explore 単位でファイル分割しています。分割することで、ファイル単位のテストが可能になっています。

こちらのベストプラクティスに従っています。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcommunity.looker.com%2Flookml-5%2Flookml-data-tests-recommendations-and-best-practices-20815" title="LookML Data Tests: Recommendations and Best Practices | Looker Community" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe>

テスト対象はこんな感じです。

<ul>
<li>(1) LookML で特別な実装をしていて、壊れても気づくのが難しそうな実装</li>
<li>(2) <code>primary_key</code> が重複していないか？ null になっていないか？を全ての view に対して</li>
</ul>


(2) は前回詳しく書きました。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2021%2F08%2F30%2F150000" title="Looker で Join 先の view の primary_key をいい感じにテストする方法をようやく見つけた - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe>

実行に時間がかかることが悩みで以前こんな Topic を作りましたが、反応ゼロでした。みなさん課題ではないのかしら？💦

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcommunity.looker.com%2Flookml-5%2Fis-it-possible-to-run-tests-in-parallel-28222" title="Is it possible to run tests in parallel? | Looker Community" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe>

<code>primary_key</code> は壊れた時に気づくのが難しく、LookML 開発者が私だけということもあるため、機械的に全ての <code>primary_key</code> をテスト出来るようにしています。ただ、全テストは結構時間がかかるので、日に 1 回くらいの頻度で手動実行しています。CI したい...。

<h3 id="manifestlkml">manifest.lkml</h3>

ディレクトリ構造とは関係ありませんが、manifest.lkml についても触れておきましょう。

<code>bigquery/</code> の項で書いたとおり、テーブル定義に破壊的な変更を加える時は <code>dataset_v2</code> のように Dataset 名にゆるふわバージョンを付けています。つまり割とカジュアルに Dataset 名が変わります。

そのため、このように manifest.lkml で全ての Dataset 名を定義しています<a href="#fn:3" rel="footnote">3</a>。Dataset 名は複数箇所で使われ得るためです。

<pre class="code" data-lang="" data-unlink>constant: table_name1 { value: &#34;`table1_v2.gsheet`&#34; }
constant: table_name2 { value: &#34;`table2.view`&#34; }</pre>


利用例です。

<pre class="code" data-lang="" data-unlink>sql_table_name: @{table_name1} ;;</pre>


<h2 id="まとめ">まとめ</h2>

現在 LookML 開発で使っているディレクトリ構造を紹介しました。中規模くらいまでの LookML プロジェクトには使える実感があります。

ただ、最近はファイル数が多くなってきて、<code>.view.lkml</code> を追加した時に変更する <code>.explore.lkml</code> と <code>.test.lkml</code> の距離が遠く、実装しづらい課題があります。

Refinements を使えば解決できるのだろうか、もっと再利用性のあるコードにしたいなど、悩みは尽きないです。

こちらの記事は読んで手も動かしたのですが、巨大なファイルを分割する、Blocks のようなライブラリをカスタマイズする（？）、以外の使い方を見いだせていません。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcommunity.looker.com%2F%25E3%2582%25B3%25E3%2583%25A9%25E3%2583%25A0-103%2Frefinements%25E3%2582%2592%25E4%25BD%25BF%25E3%2581%25A3%25E3%2581%25A6lookml%25E3%2581%25AE%25E3%2582%25B3%25E3%2583%25BC%25E3%2583%2589%25E3%2582%2592%25E6%2595%25B4%25E7%2590%2586%25E3%2581%2599%25E3%2582%258B-18809" title="Refinementsを使ってLookMLのコードを整理する | Looker Community" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe>

皆さんのディレクトリ構造も是非教えて下さい！

<h2 id="2021-12-29-追記">2021-12-29 追記</h2>

<a href="https://community.looker.com/lookml-5/what-is-the-looker-recommended-folder-structure-for-lookml-development-28826">What is the looker recommended folder structure for LookML development ? | Looker Community</a>

Looker Community にもお悩みの方がいらっしゃいました。返信している Dawid さんはよくお見かけする方で、かなりの熟練者だと思います。

そんな彼も、今回私が書いた記事のような物理的な構造が良いのか、論理的な構造が良いのか、未だに試行錯誤しているようです。

始めは物理的なディレクトリ構造から始めて、徐々に変化しながら論理的な構造に近づくのかもしれません。その頃にはステージに応じたベストプラクティスが出ていると良いですね。
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
正確に書くと <code>manifest.lkml</code> や <code>.strings.json</code> などもありますが、一旦考えなくて良いと思います。<a href="#fnref:1" rev="footnote">&#8617;</a></li>
<li id="fn:2">
<a href="https://funnel.io/">Funnel.io</a> を使っています。<a href="#fnref:2" rev="footnote">&#8617;</a></li>
<li id="fn:3">
1 行で書いているのはソートしやすくするためです。<a href="#fnref:3" rev="footnote">&#8617;</a></li>
</ol>
</div>

こんにちは、id:masutaka26 です。この記事は Looker Advent Calendar 2021 の 13 日目の記事です。qiita.com昨日は Yappli 阿部さんの「Lookerの目標値やストップワードを、Googleスプレッドシート連携でお手軽管理【Sexy Tech for You #9】」でした。Looker を使うとこのような LookML を書くだけで、ビジネスユーザーが SQL を書くことなく、本業に集中できるのはとても良いですよね。個人的には、SQL ベースの派生テーブルの中で join するよりも、explore で join したほうが Looker らしく、メンテナンス性が良い気がしました。symmetric 集計が働くため、ファンアウトも避けられます。wikipedia テーブルに関しては、永続的な派生テーブル（PDT）を使って BigQuery のスキャンサイズを抑えるのも良さそうです。、、、( ﾟдﾟ)ハッ！ついマジレスをしてしまいました。💦今回は dimension が null の measure を（0 ではなく）ø にする少しマニアックな記事を書く予定でしたが、先日の Looker User Meetup Online #7 で、LookML のディレクトリ構造を知りたいというチャットをお見かけしたので、今回はその話を書くことにしました。今回のプロジェクトの規模感デフォルトのディレクトリ構造？特別なファイル形式を知る最近使っているディレクトリ構造bigquery/model1.model.lkmlexplores/views/tests/manifest.lkmlまとめ2021-12-29 追記今回のプロジェクトの規模感プロジェクトの規模感によってディレクトリ構造は変わると思うので、先に書いておきます。Looker インスタンスに 1 つだけ LookML プロジェクトが存在するBigQuery Dataset 76 個.lkml ファイル 277 個.model.lkml ファイル 1 個.explore.lkml ファイル 56 個.view.lkml ファイル 139 個.test.lkml ファイル 78 個LookML 開発者 1 名デフォルトのディレクトリ構造？この記事を書くまで誤解をしていたのですが、デフォルトのディレクトリ構造というものはなかったのですね。この記事を書くために改めて Blank Project を作ったら、ファイルもディレクトリも何もないプロジェクトが作られました。モデルファイルを作るとこのようなコードが展開されるので、.view.lkml に関しては /views/ 以下に作る方が多いと思います。私もそうでした。include: "/views/*.view.lkml"                # include all views in the views/ folder in this project# include: "/**/*.view.lkml"                 # include all views in this project# include: "my_dashboard.dashboard.lookml"   # include a lookml dashboard called my_dashboard例えばこのようになります。feedmatic.model.lkmlviews├── all_media.view.lkml└── ga.view.lkml開発初期は feedmatic.model.lkml に view 以外の、explore や datagroup などをズラズラと書いていました。特別なファイル形式を知るご存知の通り、LookML のファイル形式は .lkml です。LookML 開発が続くと .model.lkml や .view.lkml などが増えていきますが、この中で唯一意味を持つのが .model.lkml です1。その他のファイル形式は整理のために自由に作ることが出来ます。例えば feedmatic.model.lkml を作ると、feedmatic というモデルが定義されます。https://{{your looker domain}}/projects で確認できます。all_media.view.lkml を作っても、何かが作られるわけではありません。以上の知識を持った上で、公式ドキュメントを読むと理解が深まるかもしれません。最近使っているディレクトリ構造こんな感じです。それぞれ解説していきます。bigquery├── spreadsheet1│   ├── define.json│   └── schema.json└── spreadsheet2    ├── define.json    └── schema.jsonmodel1.model.lkmlexplores├── corp│   ├── base.explore.lkml│   ├── name1.explore.lkml│   └── name2.explore.lkml├── explore1.explore.lkml└── explore2.explore.lkmlviews├── corp│   ├── base.view.lkml│   ├── name1.view.lkml│   └── name2.view.lkml├── view1.view.lkml└── view2.view.lkmltests└── model1    ├── corp    │   ├── name1.test.lkml    │   └── name2.test.lkml    ├── explore1.test.lkml    └── explore2.test.lkmlmanifest.lkmlbigquery/いきなり LookML 関係ありません。💦BigQuery はデータソースに Google スプレッドシートを指定でき、そのスキーマ定義はコード化することが出来ます。コード化することで変更履歴を Git で管理できますし、BigQuery CLI を使って簡単に Dataset や Table を作ったり、削除したりが出来ます。$ bq mk spreadsheet1$ bq mk --external_table_definition=./define.json spreadsheet1.gsheet$ bq rm -r spreadsheet1破壊的な変更をする時は、バージョン名を付けた Dataset を新規作成し、LookML から参照先を変えます。こうすることで、本番環境に影響を与えずに開発することが出来ます。$ bq mk spreadsheet1_v2$ bq mk --external_table_definition=./define.json spreadsheet1_v2.gsheetスキーマ定義は公式ドキュメントをご覧下さい。需要があればそんな記事を書きます。他の Dataset は ETL ツール2が作るためコード化はしていません。model1.model.lkml中心となるこのファイルは軽いです。本当にこの程度しか書いていません。connection: "docs_bigquery_db"include: "/explores/**/*.explore"include: "/tests/model1/**/*.test"named_value_format: jpy_0 {  value_format: "\¥#,##0"}named_value_format: jpy_1 {  value_format: "\¥#,##0.0"}# for testaccess_grant: can_view_explores_for_tests {  user_attribute: view_explores_for_tests  allowed_values: ["yes"]}必要な定義は connection と include だけです。include 対象を全ての .explore.lkml と、このモデルに関連するテスト（tests/feedmatic/ 以下全ての .test.lkml）だけにしていることがポイントです。つまり .model.lkml は .explore.lkml と自分の .test.lkml しか知りません。あとは蛇足で、named_value_format と、前回紹介したテストに必要な access_grant だけです。explores/1 つの explore を 1 つのファイルに定義しています。explores/explore1.explore.lkml はこのように書いています。.explore.lkml は .view.lkml しか知りません。include: "/views/**/*.view"explore: explore1 {  # ...}紆余曲折あり、explores/corp/name1.explore.lkml のような取引先ごとの explore もあります。基本となる explores/corp/base.explore.lkml はこのような定義です。ファイル名と explore 名を変えていることがポイントです。Ruby の慣習を参考にしました。explore: corp_base {  extension: required  # ...}corp_base explore を継承する、各取引先の explore はこのような定義です。include: "./base.explore"include: "/views/**/*.view"explore: corp_name1 {  extends: [corp_base]  # ...}views/view も explore と同様に、1 view 1 ファイルに定義しています。views/view1.view.lkml です。.view.lkml は .model.lkml, .explore.lkml, .test.lkml の誰も知りません。view: view1 {  # ...}取引先ごとの view も同じです。views/corp/base.view.lkml はこんな感じで、view: corp_base {  extension: required  # ...}継承先の views/corp/name1.view.lkml はこんな感じです。include: "./base.view"view: corp_name1 {  extends: [corp_base]  # ...}tests/テストはかなり書いており、2021-12-13 現在、184 もあります。ほぼ explore 単位でファイル分割しています。分割することで、ファイル単位のテストが可能になっています。こちらのベストプラクティスに従っています。テスト対象はこんな感じです。(1) LookML で特別な実装をしていて、壊れても気づくのが難しそうな実装(2) primary_key が重複していないか？ null になっていないか？を全ての view に対して(2) は前回詳しく書きました。実行に時間がかかることが悩みで以前こんな Topic を作りましたが、反応ゼロでした。みなさん課題ではないのかしら？💦primary_key は壊れた時に気づくのが難しく、LookML 開発者が私だけということもあるため、機械的に全ての primary_key をテスト出来るようにしています。ただ、全テストは結構時間がかかるので、日に 1 回くらいの頻度で手動実行しています。CI したい...。manifest.lkmlディレクトリ構造とは関係ありませんが、manifest.lkml についても触れておきましょう。bigquery/ の項で書いたとおり、テーブル定義に破壊的な変更を加える時は dataset_v2 のように Dataset 名にゆるふわバージョンを付けています。つまり割とカジュアルに Dataset 名が変わります。そのため、このように manifest.lkml で全ての Dataset 名を定義しています3。Dataset 名は複数箇所で使われ得るためです。constant: table_name1  { value: "`table1_v2.gsheet`" }constant: table_name2  { value: "`table2.view`" }利用例です。sql_table_name: @{table_name1} ;;まとめ現在 LookML 開発で使っているディレクトリ構造を紹介しました。中規模くらいまでの LookML プロジェクトには使える実感があります。ただ、最近はファイル数が多くなってきて、.view.lkml を追加した時に変更する .explore.lkml と .test.lkml の距離が遠く、実装しづらい課題があります。Refinements を使えば解決できるのだろうか、もっと再利用性のあるコードにしたいなど、悩みは尽きないです。こちらの記事は読んで手も動かしたのですが、巨大なファイルを分割する、Blocks のようなライブラリをカスタマイズする（？）、以外の使い方を見いだせていません。皆さんのディレクトリ構造も是非教えて下さい！2021-12-29 追記What is the looker recommended folder structure for LookML development ? | Looker CommunityLooker Community にもお悩みの方がいらっしゃいました。返信している Dawid さんはよくお見かけする方で、かなりの熟練者だと思います。そんな彼も、今回私が書いた記事のような物理的な構造が良いのか、論理的な構造が良いのか、未だに試行錯誤しているようです。始めは物理的なディレクトリ構造から始めて、徐々に変化しながら論理的な構造に近づくのかもしれません。その頃にはステージに応じたベストプラクティスが出ていると良いですね。正確に書くと manifest.lkml や .strings.json などもありますが、一旦考えなくて良いと思います。↩Funnel.io を使っています。↩1 行で書いているのはソートしやすくするためです。↩

LookML 開発で使っているディレクトリ構造を紹介する

こんにちは、<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。
先週はまるっと夏休みにしてました。今日からまた <a href="https://ja.looker.com/">Looker</a> と戯れる日々が始まります。

丸１年 Looker と戯れてきて最近ようやく、Join 先の view でも primary_key が壊れてないことを保証するテストの書き方が分かったので、今回紹介します。

<ul class="table-of-contents">
 <li><a href="#Looker-における-primary_key-の役割">Looker における primary_key の役割</a></li>
 <li><a href="#primary_key-の実装例">primary_key の実装例</a></li>
 <li><a href="#LookML-開発におけるテスト">LookML 開発におけるテスト</a></li>
 <li><a href="#Join-先の-view-は-primary_key-をテスト出来ないことがある">Join 先の view は primary_key をテスト出来ないことがある</a></li>
 <li><a href="#Join-先の-view-の-primary_key-をいい感じにテストする">Join 先の view の primary_key をいい感じにテストする</a></li>
 <li><a href="#まとめと所感">まとめと所感</a></li>
 <li><a href="#おまけ">おまけ</a></li>
</ul>

<h2 id="Looker-における-primary_key-の役割">Looker における primary_key の役割</h2>

Looker には <a href="https://help.looker.com/hc/en-us/articles/360023722974">Symmetric Aggregates</a> という、合計を重複させない素晴らしい仕組みがあります。以前このブログでも紹介しました。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2020%2F10%2F23%2F190000" title="『4月から取り組んできたLookerの導入から実装までのお話（Redashとも比較）』という発表をした - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe>

その Symmetric Aggregates では <a href="https://docs.looker.com/reference/field-params/primary_key">primary_key</a> が重要な役割を果たします。適切に設定されていないと、以下のような問題が発生します。

<ul>
<li>primary_key が重複すると fanout エラーが発生することがある</li>
<li>primary_key が null だと Measure が 0 になることがある</li>
</ul>


このような問題は大概、ふわっと質問が来て発覚します。今のタスクを保留にして調査することは精神的になかなか辛いものがあり、それなりに時間も費やすことになるため、可能な限り事前に避けたいところです。

<h2 id="primary_key-の実装例">primary_key の実装例</h2>

私が所属する <a href="https://feedmatic.net/">Feedmatic</a> では、ウェブ広告や Google Analytics のデータを扱っています。正規化されたきれいなデータは少なく、Rails の id のようなユニークなカラムは存在しないことが多いです。

そのため、このようにいくつかの Dimension を組み合わせて primary_key を定義します。

<pre class="code" data-lang="" data-unlink>dimension: id {
 primary_key: yes
 type: string
 sql: CONCAT(${dimension1}, ${dimension2}, IFNULL(${dimension3}, &#39;&#39;)) ;;
 hidden: yes
}</pre>


※ <a href="https://ja.wikipedia.org/wiki/%E3%83%87%E3%83%BC%E3%82%BF%E3%82%A6%E3%82%A7%E3%82%A2%E3%83%8F%E3%82%A6%E3%82%B9">DWH</a> は BigQuery を使っています。

これで済めばよいのですが、上の例だとある日突然 dimension2 が null になり始めたり、全ての string 型の Dimension を使っても重複し始めることがあります。データの性格は理解していたつもりでしたが、実際どちらもありました。😭

<h2 id="LookML-開発におけるテスト">LookML 開発におけるテスト</h2>

以上の課題を解決するために、<a href="https://docs.looker.com/reference/model-params/test">test</a> パラメータが使えます。

例えばこのような <code>parent</code> explore があったとします。Join がないのでシンプルです。

<pre class="code" data-lang="" data-unlink>explore: parent {
 ...
}

view: parent {
 dimension: id {
 primary_key: yes
 ...
 }

 measure: count {
 type: count
 }
}</pre>


私はこのようなテストを書いて、全ての <code>parent.id</code> が null でないことと、重複しないことを保証させています。

<pre class="code" data-lang="" data-unlink>test: parent_id_is_not_null {
 explore_source: parent {
 column: id {}
 sorts: [parent.id: asc]
 limit: 1
 }
 assert: id_is_not_null {
 expression: NOT is_null(${parent.id}) ;;
 }
}

test: parent_id_is_unique {
 explore_source: parent {
 column: id {}
 column: count {}
 sorts: [parent.count: desc]
 limit: 1
 }
 assert: id_is_unique {
 expression: ${parent.count} = 1 ;;
 }
}</pre>


👉 ソート時に null が先頭と末尾のどちらに来るかは、DWH の実装によります。

<h2 id="Join-先の-view-は-primary_key-をテスト出来ないことがある">Join 先の view は primary_key をテスト出来ないことがある</h2>

さて、<code>child</code> view を Join する必要が出てきました。

<pre class="code" data-lang="" data-unlink>explore: parent {
 join: child {
 type: left_outer
 relationship: one_to_many
 sql_on: ... ;;
 }
}

view: parent {
 dimension: id {
 primary_key: yes
 ...
 }

 measure: count {
 type: count
 }
}

view: child {
 dimension: id {
 primary_key: yes
 ...
 }

 measure: count {
 type: count
 hidden: yes
 }
}</pre>


同じように <code>child.id</code> のテストを書きましたが、うまくいきません。<code>is_not_null</code> はまだしも、<code>is_unique</code> がダメです。

<pre class="code" data-lang="" data-unlink># これは OK
test: parent_child_id_is_not_null {
 explore_source: parent {
 column: id { field: child.id }
 sorts: [child.id: asc]
 limit: 1
 }
 assert: child_id_is_not_null {
 expression: NOT is_null(${child.id}) ;;
 }
}

# parent の count になり、テストが通らない。
test: parent_child_id_is_unique {
 explore_source: parent {
 column: id { field: child.id }
 column: count { field: child.count }
 sorts: [parent.count: desc]
 limit: 1
 }
 assert: child_id_is_unique {
 expression: ${child.count} = 1 ;;
 }
}</pre>


よく考えれば当たり前の話で、Join した状態でテストを書いているからです。そもそも <code>child</code> view の primary_key のテストをしたいだけなのに、Join は邪魔です。

<h2 id="Join-先の-view-の-primary_key-をいい感じにテストする">Join 先の view の primary_key をいい感じにテストする</h2>

<code>child</code> view と同じファイルに、こっそり <code>child</code> explore を定義します。<a href="https://docs.looker.com/ja/reference/explore-params/hidden-for-explore">hidden</a> にして存在を消しています。さらに <a href="https://docs.looker.com/reference/explore-params/required_access_grants-for-explore">required_access_grants</a> で、開発者以外の URL 直打ちによるアクセスも防いでいます。

<pre class="code" data-lang="" data-unlink>view: child {
 dimension: id {
 primary_key: yes
 ...
 }

 measure: count {
 type: count
 hidden: yes
 }
}

# Define for test
explore: child {
 hidden: yes
 required_access_grants: [can_view_explores_for_tests]
}</pre>


<a href="https://docs.looker.com/reference/model-params/access_grant">access_grant</a> である <code>can_view_explores_for_tests</code> はこのような定義です。

<pre class="code" data-lang="" data-unlink># For tests
access_grant: can_view_explores_for_tests {
 user_attribute: view_explores_for_tests
 allowed_values: [&#34;yes&#34;]
}</pre>


<a href="https://docs.looker.com/admin-options/settings/user-attributes">User attribute</a> である <code>view_explores_for_tests</code> は、今回のような「Join 先の view をテストすること」全般に使います。User Access は <code>None</code>、Default Value も <code>no</code> です。開発者用の Group を作り、その Group value を <code>yes</code> にしました。

ここまでやらずとも全員アクセス不可でも良いのですが、テストが落ちた時に「クエリの探索」からの調査ができなくなるので、開発者にはアクセス権を与えるポリシーにしています。

あとは <code>parent</code> explore と同じようにテストを書くだけです。

<pre class="code" data-lang="" data-unlink>test: child_id_is_not_null {
 explore_source: child {
 column: id {}
 sorts: [child.id: asc]
 limit: 1
 }
 assert: id_is_not_null {
 expression: NOT is_null(${child.id}) ;;
 }
}

test: child_id_is_unique {
 explore_source: child {
 column: id {}
 column: count {}
 sorts: [child.count: desc]
 limit: 1
 }
 assert: id_is_unique {
 expression: ${child.count} = 1 ;;
 }
}</pre>


テストは通っても、LookML validation error が発生するかもしれません。その時は <a href="https://docs.looker.com/ja/reference/explore-params/fields-for-explore">fields</a> パラメータを使って、露出する field を限定すると良いでしょう。

<pre class="code" data-lang="" data-unlink># Define for test
explore: child {
 hidden: yes
 required_access_grants: [can_view_explores_for_tests]
 fields: [child.id, child.count] # Avoid LookML validation error
}</pre>


このテクニックは <a href="https://help.looker.com/hc/en-us/articles/360023586293-Error-Unknown-or-Inaccessible-Field">Error: Unknown or Inaccessible Field – Looker Help Center</a> でも紹介されています。

<h2 id="まとめと所感">まとめと所感</h2>

LookML 開発者で、且つテストを書いていて、且つ Join 先の view の primary_key に課題を抱えている、大変ニッチな層向けに記事を書きました。どこかの誰かに参考になれば幸いです。

もっと良い方法や、今回のやり方はここがマズイとかあれば <a href="https://twitter.com/masutaka">@masutaka</a> にお知らせ頂けると大変うれしいです。🙏

Feedmatic では今回のような view は数十もあり、primary_key のテストはまだ書き始めたばかりです。

Looker ではテストは直列でしか実行されないようで、書けば書くほど全テストが遅くなるのはモヤモヤしています。さすがに要望しようと思ってますが。

それに関連して、最近ディレクトリやファイル構成を再検討しました。次回はその記事を書く予定です。

<h2 id="おまけ">おまけ</h2>

今回の記事を書く過程で、中の人が書いたベストプラクティスを見つけました。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fcommunity.looker.com%2Flookml-5%2Flookml-data-tests-recommendations-and-best-practices-20815" title="LookML Data Tests: Recommendations and Best Practices | Looker Community" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe>

今回の記事ほど細かいテクニックは書かれていませんが、全体を網羅した良記事なので要チェックです。

こんにちは、id:masutaka26 です。先週はまるっと夏休みにしてました。今日からまた Looker と戯れる日々が始まります。丸１年 Looker と戯れてきて最近ようやく、Join 先の view でも primary_key が壊れてないことを保証するテストの書き方が分かったので、今回紹介します。Looker における primary_key の役割primary_key の実装例LookML 開発におけるテストJoin 先の view は primary_key をテスト出来ないことがあるJoin 先の view の primary_key をいい感じにテストするまとめと所感おまけLooker における primary_key の役割Looker には Symmetric Aggregates という、合計を重複させない素晴らしい仕組みがあります。以前このブログでも紹介しました。その Symmetric Aggregates では primary_key が重要な役割を果たします。適切に設定されていないと、以下のような問題が発生します。primary_key が重複すると fanout エラーが発生することがあるprimary_key が null だと Measure が 0 になることがあるこのような問題は大概、ふわっと質問が来て発覚します。今のタスクを保留にして調査することは精神的になかなか辛いものがあり、それなりに時間も費やすことになるため、可能な限り事前に避けたいところです。primary_key の実装例私が所属する Feedmatic では、ウェブ広告や Google Analytics のデータを扱っています。正規化されたきれいなデータは少なく、Rails の id のようなユニークなカラムは存在しないことが多いです。そのため、このようにいくつかの Dimension を組み合わせて primary_key を定義します。dimension: id {  primary_key: yes  type: string  sql: CONCAT(${dimension1}, ${dimension2}, IFNULL(${dimension3}, '')) ;;  hidden: yes}※ DWH は BigQuery を使っています。これで済めばよいのですが、上の例だとある日突然 dimension2 が null になり始めたり、全ての string 型の Dimension を使っても重複し始めることがあります。データの性格は理解していたつもりでしたが、実際どちらもありました。😭LookML 開発におけるテスト以上の課題を解決するために、test パラメータが使えます。例えばこのような parent explore があったとします。Join がないのでシンプルです。explore: parent {  ...}view: parent {  dimension: id {    primary_key: yes    ...  }  measure: count {    type: count  }}私はこのようなテストを書いて、全ての parent.id が null でないことと、重複しないことを保証させています。test: parent_id_is_not_null {  explore_source: parent {    column: id {}    sorts: [parent.id: asc]    limit: 1  }  assert: id_is_not_null {    expression: NOT is_null(${parent.id}) ;;  }}test: parent_id_is_unique {  explore_source: parent {    column: id {}    column: count {}    sorts: [parent.count: desc]    limit: 1  }  assert: id_is_unique {    expression: ${parent.count} = 1 ;;  }}👉 ソート時に null が先頭と末尾のどちらに来るかは、DWH の実装によります。Join 先の view は primary_key をテスト出来ないことがあるさて、child view を Join する必要が出てきました。explore: parent {  join: child {    type: left_outer    relationship: one_to_many    sql_on: ... ;;  }}view: parent {  dimension: id {    primary_key: yes    ...  }  measure: count {    type: count  }}view: child {  dimension: id {    primary_key: yes    ...  }  measure: count {    type: count    hidden: yes  }}同じように child.id のテストを書きましたが、うまくいきません。is_not_null はまだしも、is_unique がダメです。# これは OKtest: parent_child_id_is_not_null {  explore_source: parent {    column: id { field: child.id }    sorts: [child.id: asc]    limit: 1  }  assert: child_id_is_not_null {    expression: NOT is_null(${child.id}) ;;  }}# parent の count になり、テストが通らない。test: parent_child_id_is_unique {  explore_source: parent {    column: id { field: child.id }    column: count { field: child.count }    sorts: [parent.count: desc]    limit: 1  }  assert: child_id_is_unique {    expression: ${child.count} = 1 ;;  }}よく考えれば当たり前の話で、Join した状態でテストを書いているからです。そもそも child view の primary_key のテストをしたいだけなのに、Join は邪魔です。Join 先の view の primary_key をいい感じにテストするchild view と同じファイルに、こっそり child explore を定義します。hidden にして存在を消しています。さらに required_access_grants で、開発者以外の URL 直打ちによるアクセスも防いでいます。view: child {  dimension: id {    primary_key: yes    ...  }  measure: count {    type: count    hidden: yes  }}# Define for testexplore: child {  hidden: yes  required_access_grants: [can_view_explores_for_tests]}access_grant である can_view_explores_for_tests はこのような定義です。# For testsaccess_grant: can_view_explores_for_tests {  user_attribute: view_explores_for_tests  allowed_values: ["yes"]}User attribute である view_explores_for_tests は、今回のような「Join 先の view をテストすること」全般に使います。User Access は None、Default Value も no です。開発者用の Group を作り、その Group value を yes にしました。ここまでやらずとも全員アクセス不可でも良いのですが、テストが落ちた時に「クエリの探索」からの調査ができなくなるので、開発者にはアクセス権を与えるポリシーにしています。あとは parent explore と同じようにテストを書くだけです。test: child_id_is_not_null {  explore_source: child {    column: id {}    sorts: [child.id: asc]    limit: 1  }  assert: id_is_not_null {    expression: NOT is_null(${child.id}) ;;  }}test: child_id_is_unique {  explore_source: child {    column: id {}    column: count {}    sorts: [child.count: desc]    limit: 1  }  assert: id_is_unique {    expression: ${child.count} = 1 ;;  }}テストは通っても、LookML validation error が発生するかもしれません。その時は fields パラメータを使って、露出する field を限定すると良いでしょう。# Define for testexplore: child {  hidden: yes  required_access_grants: [can_view_explores_for_tests]  fields: [child.id, child.count] # Avoid LookML validation error}このテクニックは Error: Unknown or Inaccessible Field – Looker Help Center でも紹介されています。まとめと所感LookML 開発者で、且つテストを書いていて、且つ Join 先の view の primary_key に課題を抱えている、大変ニッチな層向けに記事を書きました。どこかの誰かに参考になれば幸いです。もっと良い方法や、今回のやり方はここがマズイとかあれば @masutaka にお知らせ頂けると大変うれしいです。🙏Feedmatic では今回のような view は数十もあり、primary_key のテストはまだ書き始めたばかりです。Looker ではテストは直列でしか実行されないようで、書けば書くほど全テストが遅くなるのはモヤモヤしています。さすがに要望しようと思ってますが。それに関連して、最近ディレクトリやファイル構成を再検討しました。次回はその記事を書く予定です。おまけ今回の記事を書く過程で、中の人が書いたベストプラクティスを見つけました。今回の記事ほど細かいテクニックは書かれていませんが、全体を網羅した良記事なので要チェックです。

Looker で Join 先の view の primary_key をいい感じにテストする方法をようやく見つけた

こんばんは、<del>徳川家ｙ</del> <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。

以前紹介したように、去年から <a href="https://ja.looker.com/">Looker</a> を使ったウェブ広告数値の可視化や BI <a href="#f-25b67c2a" name="fn-25b67c2a" title="Business Intelligence">*1</a> に取り組んでいます。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2020%2F10%2F23%2F190000" title="『4月から取り組んできたLookerの導入から実装までのお話（Redashとも比較）』という発表をした - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe>

LookML 開発者として LookML を書き始めて困ったのが、Looker の情報が少ないように見えたことです。

LookML を含む Looker のドキュメントは充実しているのですが、それらを組み合わせた応用的なフロー情報が少なく感じました。ビジネスユーザー向けの情報も同様です。

現在は網羅的、かつ集約した情報を取得できているので、その方法をご紹介します。

<ul class="table-of-contents">
 <li><a href="#情報源をリストアップする">「情報源」をリストアップする</a></li>
 <li><a href="#少し脱線">少し脱線...</a></li>
 <li><a href="#情報源の取得方法への課題">「情報源」の取得方法への課題</a></li>
 <li><a href="#今はどうなったか">今はどうなったか？</a></li>
 <li><a href="#Looker-Communityのフィードが存在した件">「Looker Community」のフィードが存在した件</a></li>
 <li><a href="#Looker-の記事一覧--DevelopersIOのフィードを作った件">「Looker の記事一覧 | DevelopersIO」のフィードを作った件</a></li>
 <li><a href="#まとめ">まとめ</a></li>
 <li><a href="#追記">追記</a></li>
</ul>

<h2 id="情報源をリストアップする">「情報源」をリストアップする</h2>

初めはこれらをたまに見に行ったり、Slack の <code>/feed subscribe</code> <a href="#f-e46aea89" name="fn-e46aea89" title="Slack に RSS フィードを追加する | Slack">*2</a> で購読したりしてました。

<ul>
<li><a href="https://community.looker.com/">Looker Community</a>

<ul>
<li>公式フォーラム。英語で Question や Conversation が出来る</li>
</ul>
</li>
<li><a href="https://community.looker.com/%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A9%E3%83%A0-japanese-161">Looker 日本語コミュニティフォーラム</a>

<ul>
<li>「Looker Community」の日本語版。<a href="https://docs.looker.com/relnotes/intro">Release Notes</a> の日本語訳には本当に感謝 🙏</li>
<li>「ニュースと告知」「ヘルプとサポート」「コラム」はそれぞれ Subscribe 出来る。メールで通知される

 <figure class="figure-image figure-image-fotolife" title="Looker 日本語コミュニティフォーラム"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20210815/20210815145002.png" alt="f:id:masutaka26:20210815145002p:plain" width="1200" height="382" loading="lazy" title="" class="hatena-fotolife" itemprop="image"><figcaption>Looker 日本語コミュニティフォーラム</figcaption></figure></li>
</ul>
</li>
<li><a href="https://www.facebook.com/groups/721814241538725">Looker APAC Forum | Facebook</a>

<ul>
<li>リリース案内や事例紹介など</li>
</ul>
</li>
<li><a href="https://dev.classmethod.jp/tags/looker/">Looker の記事一覧 | DevelopersIO</a>

<ul>
<li>ご存知クラスメソッドさんのブログ。国内最多の記事量と投稿頻度</li>
</ul>
</li>
<li><a href="https://zenn.dev/topics/looker">Lookerの記事一覧 | Zenn</a>

<ul>
<li>Zenn にもそれなりの頻度で投稿される</li>
</ul>
</li>
<li><a href="https://qiita.com/tags/looker">Looker - Qiita</a>

<ul>
<li>Qiita はもう少し頻度は落ちるかな</li>
</ul>
</li>
<li><a href="https://twitter.com/search?q=%23looker%20lang%3Aja&amp;f=live&amp;vertical=default">#looker lang:ja - Twitter 検索</a>

<ul>
<li>以上の情報をふわっと取得できる。<code>looker lang:ja</code> や <code>#looker</code> だとノイズが多いのでこれに落ち着いた</li>
</ul>
</li>
</ul>


<h2 id="少し脱線">少し脱線...</h2>

Looker Community には過去一度だけ質問しました。

<a href="https://community.looker.com/lookml-5/how-do-i-dynamically-switch-view-name-in-sql-parameter-of-dimension-27831">How do I dynamically switch view name in sql parameter of dimension? | Looker Community</a>

私は日本語サポートに頼ることが多い傾向です。最近はだいぶ減らせています。

扱う情報を外に出せないので、外に出せるところまで昇華するのは難しいですね。🌀

Looker の水野さんが日本語訳して下さっている、Looker のリリースノート <a href="#f-c898f381" name="fn-c898f381" title="例: Looker 21.12 リリースノート | Looker Community">*3</a> は、去年の 12 月から社内向けにこんな記事を書いて、Looker に徹底的に向き合うようにしています。

<figure class="figure-image figure-image-fotolife" title="Looker 21.12 のリリースノートを眺めてみた"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20210815/20210815160438.png" alt="f:id:masutaka26:20210815160438p:plain" width="1200" height="849" loading="lazy" title="" class="hatena-fotolife" itemprop="image"><figcaption>Looker 21.12 のリリースノートを眺めてみた</figcaption></figure>

今まで書いた記事です。

<figure class="figure-image figure-image-fotolife" title="Looker のリリースノートを眺めてみたシリーズ"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20210815/20210815160356.png" alt="f:id:masutaka26:20210815160356p:plain" width="1200" height="887" loading="lazy" title="" class="hatena-fotolife" itemprop="image"><figcaption>Looker のリリースノートを眺めてみたシリーズ</figcaption></figure>

<h2 id="情報源の取得方法への課題">「情報源」の取得方法への課題</h2>

RSS/Atom（フィード）を配信していないサイトがほとんどで、見に行くのがかなり面倒でした。

そのものズバリなフィードは Zenn と Qiita だけです。クラスメソッドさんは Looker タグのフィードが存在せず、当時は Twitter で捕捉してました。

<h2 id="今はどうなったか">今はどうなったか？</h2>

ほぼすべてを社内の Slack channel <code>#news-looker</code> に集約させることが出来ました。

以下が実際に購読しているフィードです。

<ul>
<li><a href="https://community.looker.com/feed/buzzcapture">https://community.looker.com/feed/buzzcapture</a>

<ul>
<li>「Looker Community」のフィード。後述する</li>
</ul>
</li>
<li><a href="https://feed43.com/developersio-looker.xml">https://feed43.com/developersio-looker.xml</a>

<ul>
<li>「Looker の記事一覧 | DevelopersIO」のフィード。後述する</li>
</ul>
</li>
<li><a href="https://zenn.dev/topics/looker/feed">https://zenn.dev/topics/looker/feed</a>

<ul>
<li>「Lookerの記事一覧 | Zenn」のフィード</li>
</ul>
</li>
<li><a href="https://qiita.com/tags/looker/feed">https://qiita.com/tags/looker/feed</a>

<ul>
<li>「Looker - Qiita」のフィード</li>
</ul>
</li>
</ul>


Twitter は <a href="https://ifttt.com/">IFTTT</a> を使って、同 channel に POST しています。

<ul>
<li><code>If</code> New tweet from search <code>#looker OR LookML lang:ja -rt</code></li>
<li><code>Then</code> Post to channel

<ul>
<li>Channel: <code>#news-looker</code></li>
<li>Message: <code>@{{UserName}} : {{Text}} (via Twitter {{LinkToTweet}})</code></li>
</ul>
</li>
</ul>


「Looker APAC Forum | Facebook」は集約できませんでしたが、Twitter にも流れることがあるので、一旦考えないことにしました。

<h2 id="Looker-Communityのフィードが存在した件">「Looker Community」のフィードが存在した件</h2>

<a href="https://community.looker.com/%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9%E3%81%A8%E5%91%8A%E7%9F%A5-100/%E3%82%AB%E3%83%86%E3%82%B4%E3%83%AA-the-kitchen-table-%E3%81%8C%E5%85%AC%E9%96%8B%E3%81%95%E3%82%8C%E3%81%BE%E3%81%97%E3%81%9F-24032?postid=45126#post45126">Looker の水野さんに聞いたら、調べて教えて下さいました。</a>🙏

<ul>
<li>(1) 新しいトピックの投稿

<ul>
<li><a href="https://community.looker.com/feed/topics">https://community.looker.com/feed/topics</a></li>
</ul>
</li>
<li>(2) 全ての新しい投稿（最初の投稿（タイトル＋ボディ）+ 全てのリプライ）

<ul>
<li><a href="https://community.looker.com/feed/buzzcapture">https://community.looker.com/feed/buzzcapture</a></li>
</ul>
</li>
</ul>


アナウンス記事です。
<a href="https://community.looker.com/%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9%E3%81%A8%E5%91%8A%E7%9F%A5-100/looker%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%83%86%E3%82%A3%E3%81%AErss%E3%83%95%E3%82%A3%E3%83%BC%E3%83%89-25553?postid=46404#post46404">LookerコミュニティのRSSフィード | Looker Community</a>

(1) と (2) は両方とも「Looker 日本語コミュニティフォーラム」の情報も流れてきます。

今は (2) を購読しており、トラフィックはそれなりにあります。もちろんほぼ全て英語です。辛かったら (1) にすると良いと思います。

<a href="https://community.looker.com/">https://community.looker.com/</a> の HTML には RSS/Atom 情報がないので、これらのフィードに気づける人は少ないと思います。Looker さんには是非お願いしたいところです。

<h2 id="Looker-の記事一覧--DevelopersIOのフィードを作った件">「Looker の記事一覧 | DevelopersIO」のフィードを作った件</h2>

ないものは仕方がないので、<a href="https://feed43.com/">Feed43</a> というサービスで作りました。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmasutaka.net%2Fchalow%2F2021-03-14-1.html" title="フィード（RSS/Atom）を配信していないサイトのフィードを Feed43 で作成する" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe>

出来たのが <a href="https://feed43.com/developersio-looker.xml">https://feed43.com/developersio-looker.xml</a> です。どなたでも購読可能です。よろしければどうぞ。

HTML をパースしているだけなので、HTML 構造が変わったら壊れることはあると思います。気づけたら直します。

本当は <a href="https://dev.classmethod.jp/tags/looker/">https://dev.classmethod.jp/tags/looker/</a> のフィードがあれば良いのですけどね。今後に期待です。

[Update] そのものズバリ <a href="https://dev.classmethod.jp/feed/?tag=looker">https://dev.classmethod.jp/feed/?tag=looker</a> を <a href="https://twitter.com/sh19910711/status/1427429573117964306">Twitterで教えて</a>頂きました。ありがとうございます！

<h2 id="まとめ">まとめ</h2>

私が１年かけて辿り着いた、Looker の情報取得方法をご紹介しました。

これで Looker の情報は大量にインプット出来たので、今後はコミュニティにアウトプットしていきます。🔥
※ ネタは少しあるけど、時間がない。(^^;

皆さんにも参考になれば幸いです。他にもあれば <a href="https://twitter.com/masutaka">@masutaka</a> に教えて下さい！

<h2 id="追記">追記</h2>

<blockquote>他にもあれば <a href="https://twitter.com/masutaka">@masutaka</a> に教えて下さい！</blockquote>

記事にも登場して頂いた Looker の水野さん <a href="https://twitter.com/tomoya_cs">@tomoya_cs</a> をフォローするとさらに捗ると思います。

<blockquote data-conversation="none" class="twitter-tweet" data-lang="ja">Lookerの情報収集本当に至難と思いますが、まとめていただきありがとうございます😭 あとは私をフォローいただけると最新情報が入手しやすくなるかと（アウトプットがんばります🙇‍♂️） <a href="https://t.co/eDQz8A5VCC">https://t.co/eDQz8A5VCC</a>&mdash; tomoya | Looker CS (@tomoya_cs) <a href="https://twitter.com/tomoya_cs/status/1428194155943972872?ref_src=twsrc%5Etfw">2021年8月19日</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> 
<div class="footnote">
<a href="#fn-25b67c2a" name="f-25b67c2a" class="footnote-number">*1</a>:<a href="https://ja.wikipedia.org/wiki/%E3%83%93%E3%82%B8%E3%83%8D%E3%82%B9%E3%82%A4%E3%83%B3%E3%83%86%E3%83%AA%E3%82%B8%E3%82%A7%E3%83%B3%E3%82%B9">Business Intelligence</a>
<a href="#fn-e46aea89" name="f-e46aea89" class="footnote-number">*2</a>:<a href="https://slack.com/intl/ja-jp/help/articles/218688467-Slack-%E3%81%AB-RSS-%E3%83%95%E3%82%A3%E3%83%BC%E3%83%89%E3%82%92%E8%BF%BD%E5%8A%A0%E3%81%99%E3%82%8B">Slack に RSS フィードを追加する | Slack</a>
<a href="#fn-c898f381" name="f-c898f381" class="footnote-number">*3</a>:例: <a href="https://community.looker.com/%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9%E3%81%A8%E5%91%8A%E7%9F%A5-100/looker-21-12-%E3%83%AA%E3%83%AA%E3%83%BC%E3%82%B9%E3%83%8E%E3%83%BC%E3%83%88-27799">Looker 21.12 リリースノート | Looker Community</a>
</div>

こんばんは、徳川家ｙ id:masutaka26 です。以前紹介したように、去年から Looker を使ったウェブ広告数値の可視化や BI *1 に取り組んでいます。LookML 開発者として LookML を書き始めて困ったのが、Looker の情報が少ないように見えたことです。LookML を含む Looker のドキュメントは充実しているのですが、それらを組み合わせた応用的なフロー情報が少なく感じました。ビジネスユーザー向けの情報も同様です。現在は網羅的、かつ集約した情報を取得できているので、その方法をご紹介します。「情報源」をリストアップする少し脱線...「情報源」の取得方法への課題今はどうなったか？「Looker Community」のフィードが存在した件「Looker の記事一覧 | DevelopersIO」のフィードを作った件まとめ追記「情報源」をリストアップする初めはこれらをたまに見に行ったり、Slack の /feed subscribe *2 で購読したりしてました。Looker Community公式フォーラム。英語で Question や Conversation が出来るLooker 日本語コミュニティフォーラム「Looker Community」の日本語版。Release Notes の日本語訳には本当に感謝 🙏「ニュースと告知」「ヘルプとサポート」「コラム」はそれぞれ Subscribe 出来る。メールで通知される  Looker 日本語コミュニティフォーラムLooker APAC Forum | Facebookリリース案内や事例紹介などLooker の記事一覧 | DevelopersIOご存知クラスメソッドさんのブログ。国内最多の記事量と投稿頻度Lookerの記事一覧 | ZennZenn にもそれなりの頻度で投稿されるLooker - QiitaQiita はもう少し頻度は落ちるかな#looker lang:ja - Twitter 検索以上の情報をふわっと取得できる。looker lang:ja や #looker だとノイズが多いのでこれに落ち着いた少し脱線...Looker Community には過去一度だけ質問しました。How do I dynamically switch view name in sql parameter of dimension? | Looker Community私は日本語サポートに頼ることが多い傾向です。最近はだいぶ減らせています。扱う情報を外に出せないので、外に出せるところまで昇華するのは難しいですね。🌀Looker の水野さんが日本語訳して下さっている、Looker のリリースノート *3 は、去年の 12 月から社内向けにこんな記事を書いて、Looker に徹底的に向き合うようにしています。Looker 21.12 のリリースノートを眺めてみた今まで書いた記事です。Looker のリリースノートを眺めてみたシリーズ「情報源」の取得方法への課題RSS/Atom（フィード）を配信していないサイトがほとんどで、見に行くのがかなり面倒でした。そのものズバリなフィードは Zenn と Qiita だけです。クラスメソッドさんは Looker タグのフィードが存在せず、当時は Twitter で捕捉してました。今はどうなったか？ほぼすべてを社内の Slack channel #news-looker に集約させることが出来ました。以下が実際に購読しているフィードです。https://community.looker.com/feed/buzzcapture「Looker Community」のフィード。後述するhttps://feed43.com/developersio-looker.xml「Looker の記事一覧 | DevelopersIO」のフィード。後述するhttps://zenn.dev/topics/looker/feed「Lookerの記事一覧 | Zenn」のフィードhttps://qiita.com/tags/looker/feed「Looker - Qiita」のフィードTwitter は IFTTT を使って、同 channel に POST しています。If New tweet from search #looker OR LookML lang:ja -rtThen Post to channelChannel: #news-lookerMessage: @{{UserName}} : {{Text}} (via Twitter {{LinkToTweet}})「Looker APAC Forum | Facebook」は集約できませんでしたが、Twitter にも流れることがあるので、一旦考えないことにしました。「Looker Community」のフィードが存在した件Looker の水野さんに聞いたら、調べて教えて下さいました。🙏(1) 新しいトピックの投稿https://community.looker.com/feed/topics(2) 全ての新しい投稿（最初の投稿（タイトル＋ボディ）+ 全てのリプライ）https://community.looker.com/feed/buzzcaptureアナウンス記事です。LookerコミュニティのRSSフィード | Looker Community(1) と (2) は両方とも「Looker 日本語コミュニティフォーラム」の情報も流れてきます。今は (2) を購読しており、トラフィックはそれなりにあります。もちろんほぼ全て英語です。辛かったら (1) にすると良いと思います。https://community.looker.com/ の HTML には RSS/Atom 情報がないので、これらのフィードに気づける人は少ないと思います。Looker さんには是非お願いしたいところです。「Looker の記事一覧 | DevelopersIO」のフィードを作った件ないものは仕方がないので、Feed43 というサービスで作りました。出来たのが https://feed43.com/developersio-looker.xml です。どなたでも購読可能です。よろしければどうぞ。HTML をパースしているだけなので、HTML 構造が変わったら壊れることはあると思います。気づけたら直します。本当は https://dev.classmethod.jp/tags/looker/ のフィードがあれば良いのですけどね。今後に期待です。[Update] そのものズバリ https://dev.classmethod.jp/feed/?tag=looker を Twitterで教えて頂きました。ありがとうございます！まとめ私が１年かけて辿り着いた、Looker の情報取得方法をご紹介しました。これで Looker の情報は大量にインプット出来たので、今後はコミュニティにアウトプットしていきます。🔥※ ネタは少しあるけど、時間がない。(^^;皆さんにも参考になれば幸いです。他にもあれば @masutaka に教えて下さい！追記他にもあれば @masutaka に教えて下さい！記事にも登場して頂いた Looker の水野さん @tomoya_cs をフォローするとさらに捗ると思います。Lookerの情報収集本当に至難と思いますが、まとめていただきありがとうございます😭あとは私をフォローいただけると最新情報が入手しやすくなるかと（アウトプットがんばります🙇‍♂️） https://t.co/eDQz8A5VCC— tomoya | Looker CS (@tomoya_cs) 2021年8月19日  *1:Business Intelligence*2:Slack に RSS フィードを追加する | Slack*3:例: Looker 21.12 リリースノート | Looker Community

私が１年かけて辿り着いた Looker の情報収集方法を紹介する

こんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。いよいよ明後日は <a href="https://jp.rizinff.com/_ct/17440570">RIZIN.28</a> ですね！東京ドームで MMA（総合格闘技）のイベントが行われるのは、約 17 年半ぶりだそうです（Wikipedia 調べ）。ドキが胸胸します。

本日、週次の社内勉強会 <a href="https://developer.feedforce.jp/archive/category/FFTT">FFTT</a> で『ここがつらいよ普段使いのLinux』という発表をしました。タイトルは違いますが、気にしないで下さい。

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vTBXZg9pczERJABgT3Uuu922Ktcc91HHl00QOtySt7fFtxrL4NZOcco1BtkK_pDuFkO0Uo-JuAwBkoC/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="400" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


Mac が重い時に IME 切り替えが一瞬遅れて、例えば「feedforce」とタイプする時に「ふぇえ...」になる現象に悩まされていました。

そこで約 10 年ぶりに Windows PC を購入して、同じく約 10 年ぶりに Linux を普段使いし始めました。

数々の諸問題が発生しましたが、無事全部解決（？）したお話です。

<ul>
<li>キーボードショートカットがつらい</li>
<li>タッチパッドがつらい</li>
<li>指紋認証出来なくてつらい</li>
<li>たまにスリープから復帰しなくてつらい（一番つらい）</li>
<li>ちょっとした画像編集に GIMP を使うのはつらい</li>
</ul>


みんなも Mac を捨てて Linux を使うといいと思うよ！

それでは！

<div class="hatena-asin-detail"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4871908240/hatena-blog-22/" class="hatena-asin-detail-image-link" target="_blank" rel="noopener"><img src="https://m.media-amazon.com/images/I/51NEN46FW9L._SL500_.jpg" class="hatena-asin-detail-image" alt="だれでもできるLinuxセットアップ―無料(ただ)なのに頼れるOSリヌクス" title="だれでもできるLinuxセットアップ―無料(ただ)なのに頼れるOSリヌクス"></a><div class="hatena-asin-detail-info"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4871908240/hatena-blog-22/" target="_blank" rel="noopener">だれでもできるLinuxセットアップ―無料(ただ)なのに頼れるOSリヌクス</a><ul class="hatena-asin-detail-meta"><li>作者:<a href="http://d.hatena.ne.jp/keyword/%CE%EB%CC%DA%20%C5%AF%BA%C8" class="keyword">鈴木 哲哉</a></li><li>オーエス出版</li></ul><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4871908240/hatena-blog-22/" class="asin-detail-buy" target="_blank" rel="noopener">Amazon</a></div></div>

こんにちは id:masutaka26 です。いよいよ明後日は RIZIN.28 ですね！東京ドームで MMA（総合格闘技）のイベントが行われるのは、約 17 年半ぶりだそうです（Wikipedia 調べ）。ドキが胸胸します。本日、週次の社内勉強会 FFTT で『ここがつらいよ普段使いのLinux』という発表をしました。タイトルは違いますが、気にしないで下さい。Mac が重い時に IME 切り替えが一瞬遅れて、例えば「feedforce」とタイプする時に「ふぇえ...」になる現象に悩まされていました。そこで約 10 年ぶりに Windows PC を購入して、同じく約 10 年ぶりに Linux を普段使いし始めました。数々の諸問題が発生しましたが、無事全部解決（？）したお話です。キーボードショートカットがつらいタッチパッドがつらい指紋認証出来なくてつらいたまにスリープから復帰しなくてつらい（一番つらい）ちょっとした画像編集に GIMP を使うのはつらいみんなも Mac を捨てて Linux を使うといいと思うよ！それでは！だれでもできるLinuxセットアップ―無料(ただ)なのに頼れるOSリヌクス作者:鈴木 哲哉オーエス出版Amazon

『ここがつらいよ普段使いのLinux』という発表をした

こんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。最近好きな YouTuber はシバターです。シバターかわいいよ...。シバター...

フィードフォースでは先日紹介したとおり、ドキュメント共有ツールに <a href="https://esa.io/">esa</a> を使っています。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2021%2F02%2F03%2F110000" title="変化に耐え得る esa のカテゴリ設計を徹底的に考えてみた - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe>

メンバー数は 90、デイリーアクティブメンバーは 69 くらいです。2/10 の新着記事数は 106 でした。情報共有が活発な会社で、体感でもとても多いです。

全ての新着記事と記事へのコメントは Slack の <code>#esa-notify</code> に通知されます。そこを全部読めば追えはしますが、いかんせんこの数です。

真面目に全部読むと、私の場合はかける時間に見合わないなと感じたので、最近は esa の検索を利用した方法を使っています。

<ul class="table-of-contents">
 <li><a href="#使っている方法">使っている方法</a><ul>
 <li><a href="#フォローした人の新着記事を読む">フォローした人の新着記事を読む</a></li>
 <li><a href="#エゴサーチする">エゴサーチする</a></li>
 <li><a href="#気になるキーワードに言及した新着記事を読む">気になるキーワードに言及した新着記事を読む</a></li>
 <li><a href="#日報以外の最近更新された記事を読む">日報以外の最近更新された記事を読む</a></li>
 <li><a href="#直近の記事を読む">直近の記事を読む</a></li>
 </ul>
 </li>
 <li><a href="#公式ドキュメント">公式ドキュメント</a></li>
 <li><a href="#ちょっとした悩み">ちょっとした悩み</a></li>
 <li><a href="#所感">所感</a></li>
 <li><a href="#おまけ-ボツにした方法">おまけ: ボツにした方法</a></li>
</ul>

<h2 id="使っている方法">使っている方法</h2>

<h3 id="フォローした人の新着記事を読む">フォローした人の新着記事を読む</h3>

検索クエリの例:

<pre><code>@alice OR @bob OR @sapp sort:created-desc
</code></pre>

🔖 ブラウザのブックマーク: <a href="https://feedforce.esa.io/posts?q=%40alice+OR+%40bob+OR+%40sapp+sort%3Acreated-desc">Follow</a>

上の例では alice, bob, sapp をフォローしているイメージです。

社長やプロダクトオーナーをフォローして、最近の会社の状況を把握するようにしています。他、自分が関心がある人もフォローしています。

メンバーは固定ではなくたまに入れ替えます。現在 16 人をフォローしています。

<h3 id="エゴサーチする">エゴサーチする</h3>

検索クエリの例:

<pre><code>マスタカ -@me OR ますたか -@me OR masutaka -@me OR 増田 -@me sort:created-desc
</code></pre>

🔖 ブラウザのブックマーク: <a href="https://feedforce.esa.io/posts?q=%E3%83%9E%E3%82%B9%E3%82%BF%E3%82%AB+-%40me+OR+%E3%81%BE%E3%81%99%E3%81%9F%E3%81%8B+-%40me+OR+masutaka+-%40me+OR+%E5%A2%97%E7%94%B0+-%40me+sort%3Acreated-desc">Egosearch</a>

「マスタカ」「ますたか」「masutaka」「増田」が含まれ、且つ自分の記事を除いた新着記事を全部読んでいます。

空メンション <code>masutaka</code> やアイコン絵文字 <code>:@masutaka:</code>、<code>&lt;!-- Boku ha masutaka nari. --&gt;</code> のような HTML コメントも捕捉出来ます。👁

<h3 id="気になるキーワードに言及した新着記事を読む">気になるキーワードに言及した新着記事を読む</h3>

検索クエリの例:

<pre><code>looker -@me sort:created-desc
</code></pre>

🔖 ブラウザのブックマーク: <a href="https://feedforce.esa.io/posts?q=looker+-%40me+sort%3Acreated-desc">Search Looker</a>

「looker」が含まれ、且つ自分の記事を除いた新着記事を全部読んでいます。

<h3 id="日報以外の最近更新された記事を読む">日報以外の最近更新された記事を読む</h3>

検索クエリの例:

<pre><code>-category:日報 sort:updated-desc
</code></pre>

🔖 ブラウザのブックマーク: <a href="https://feedforce.esa.io/posts?q=-category%3A%E6%97%A5%E5%A0%B1+sort%3Aupdated-desc">日報以外</a>

<code>日報/</code> カテゴリ以外で、最近更新された記事をたまに読んでいます。新着記事でないことがポイントです。良さそうな WIP 記事を先取りできることがあります。🤗

<h3 id="直近の記事を読む">直近の記事を読む</h3>

退勤後とかは、新着記事一覧 <code>/posts</code> も見ます。

<h2 id="公式ドキュメント">公式ドキュメント</h2>

ここまで使った検索クエリは、公式ドキュメント「<a href="https://docs.esa.io/posts/104">help/記事の検索方法</a>」に書かれています。

OR 検索よりも AND 検索のほうが優先度が高いとは書かれていないので、行間を読む必要があります。括弧は使えないので、前述の「エゴサーチする」は自分にとって難易度が高かったです。

esa の皆様、その節はサポートありがとうございました。🙏

<h2 id="ちょっとした悩み">ちょっとした悩み</h2>

スマホだと「フォローした人の新着記事を読む」が検索対象のメンバーアイコンで埋まるので、結構スクロールしないと記事にたどり着けません。メンバーアイコンと記事の境界も曖昧で、スクロールしすぎることがあります。

<figure class="figure-image figure-image-fotolife" title="スマホだと数スクロールがメンバーアイコンで埋まる"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20210211/20210211183124.png" alt="f:id:masutaka26:20210211183124p:plain" width="200" height="400" loading="lazy" title="" class="hatena-fotolife" itemprop="image"><figcaption>スマホだと数スクロールがメンバーアイコンで埋まる</figcaption></figure>

もう少しメンバーアイコンのサイズが小さいと良いと思います。ﾁﾗｯﾁﾗｯ

<h2 id="所感">所感</h2>

全ての新着記事を読む代わりに、テーマを決めた複数の方法で esa 記事を読み、かける時間を減らしました。２ヶ月ほど使っており、なかなか満足しています。

ただ、関心外のことが入って来づらくなることは、特にこのフルリモートワーク下では怖さを感じます。

カッチリやらずに、たまに <code>#esa-notify</code> を覗けばよいのですけどね。記事へのコメントだけを通知する Slack チャンネルでも作れば良いのかしら？

<h2 id="おまけ-ボツにした方法">おまけ: ボツにした方法</h2>

コメントもエゴサーチしようとしましたが、なんか期待通りの振る舞いではなかったです。

<pre><code>comment:マスタカ OR comment:ますたか OR comment:masutaka OR comment:増田 sort:created-desc
</code></pre>

コメント本文はきちんと検索出来ているようですが、検索結果はあくまで（コメント単位ではなく）記事単位なので、すでに読んだ記事のことが多いからかな？

他の方法で網羅できているようなので、まあいいかあと思いました。

こんにちは id:masutaka26 です。最近好きな YouTuber はシバターです。シバターかわいいよ...。シバター...フィードフォースでは先日紹介したとおり、ドキュメント共有ツールに esa を使っています。メンバー数は 90、デイリーアクティブメンバーは 69 くらいです。2/10 の新着記事数は 106 でした。情報共有が活発な会社で、体感でもとても多いです。全ての新着記事と記事へのコメントは Slack の #esa-notify に通知されます。そこを全部読めば追えはしますが、いかんせんこの数です。真面目に全部読むと、私の場合はかける時間に見合わないなと感じたので、最近は esa の検索を利用した方法を使っています。使っている方法フォローした人の新着記事を読むエゴサーチする気になるキーワードに言及した新着記事を読む日報以外の最近更新された記事を読む直近の記事を読む公式ドキュメントちょっとした悩み所感おまけ: ボツにした方法使っている方法フォローした人の新着記事を読む検索クエリの例:@alice OR @bob OR @sapp sort:created-desc🔖 ブラウザのブックマーク: Follow上の例では alice, bob, sapp をフォローしているイメージです。社長やプロダクトオーナーをフォローして、最近の会社の状況を把握するようにしています。他、自分が関心がある人もフォローしています。メンバーは固定ではなくたまに入れ替えます。現在 16 人をフォローしています。エゴサーチする検索クエリの例:マスタカ -@me OR ますたか -@me OR masutaka -@me OR 増田 -@me sort:created-desc🔖 ブラウザのブックマーク: Egosearch「マスタカ」「ますたか」「masutaka」「増田」が含まれ、且つ自分の記事を除いた新着記事を全部読んでいます。空メンション masutaka やアイコン絵文字 :@masutaka:、 のような HTML コメントも捕捉出来ます。👁気になるキーワードに言及した新着記事を読む検索クエリの例:looker -@me sort:created-desc🔖 ブラウザのブックマーク: Search Looker「looker」が含まれ、且つ自分の記事を除いた新着記事を全部読んでいます。日報以外の最近更新された記事を読む検索クエリの例:-category:日報 sort:updated-desc🔖 ブラウザのブックマーク: 日報以外日報/ カテゴリ以外で、最近更新された記事をたまに読んでいます。新着記事でないことがポイントです。良さそうな WIP 記事を先取りできることがあります。🤗直近の記事を読む退勤後とかは、新着記事一覧 /posts も見ます。公式ドキュメントここまで使った検索クエリは、公式ドキュメント「help/記事の検索方法」に書かれています。OR 検索よりも AND 検索のほうが優先度が高いとは書かれていないので、行間を読む必要があります。括弧は使えないので、前述の「エゴサーチする」は自分にとって難易度が高かったです。esa の皆様、その節はサポートありがとうございました。🙏ちょっとした悩みスマホだと「フォローした人の新着記事を読む」が検索対象のメンバーアイコンで埋まるので、結構スクロールしないと記事にたどり着けません。メンバーアイコンと記事の境界も曖昧で、スクロールしすぎることがあります。スマホだと数スクロールがメンバーアイコンで埋まるもう少しメンバーアイコンのサイズが小さいと良いと思います。ﾁﾗｯﾁﾗｯ所感全ての新着記事を読む代わりに、テーマを決めた複数の方法で esa 記事を読み、かける時間を減らしました。２ヶ月ほど使っており、なかなか満足しています。ただ、関心外のことが入って来づらくなることは、特にこのフルリモートワーク下では怖さを感じます。カッチリやらずに、たまに #esa-notify を覗けばよいのですけどね。記事へのコメントだけを通知する Slack チャンネルでも作れば良いのかしら？おまけ: ボツにした方法コメントもエゴサーチしようとしましたが、なんか期待通りの振る舞いではなかったです。comment:マスタカ OR comment:ますたか OR comment:masutaka OR comment:増田 sort:created-descコメント本文はきちんと検索出来ているようですが、検索結果はあくまで（コメント単位ではなく）記事単位なので、すでに読んだ記事のことが多いからかな？他の方法で網羅できているようなので、まあいいかあと思いました。

全ての esa 新着記事を読みきれないので、最近はこの方法を使ってる

こんにちは id:masutaka26 です。夜の散歩（意味深）に勤しむ毎日です。フィードフォースではドキュメント共有ツールには esa と Google ドキュメント1を、コミュニケーションツールには Slack を採用しています。情報共有はかなり活発で、2021/2/1 現在の esa 記事数は 81,324 です2。現在のカテゴリ構成と課題チームのスピードを上げるための大原則チームのスピードを上げるための情報整理1. Flow 型と Stock 型の記事を理解する2. 基本は Flow 型の記事にする3. 議事録カテゴリは出来るだけ作らない4. Slack に流れていく情報も Flow 型の記事にする5. 使い続けられる情報を Stock 記事として引き上げる6. 整理を頑張らないことで整理の難易度が低くなった7. esa を全ての情報の起点にするそれをチームでやるのは難しすぎない？esa は難しいesa の本当の正体esa への要望まとめesa 公式アカウントからのアドバイスコラム記事のカテゴリ整理を頑張らない理由Flow カテゴリをどこまで許容するか現在のカテゴリ構成と課題トップカテゴリは厳密にルール化されていて、これらの種類以外のカテゴリが増えることはありません。日報/2021/02/01 (月)/masutaka といった記事が置かれる曜日がないなど、型から外れた日報は小人さんによって速やかに修正される。Bot 並に早いwプロダクト1/実際には Feedmatic などのプロダクト名が入る︙プロダクトN/プロジェクト/期間が決まっている系のプロジェクトカテゴリが並ぶチーム/人事や情報セキュリティなどのチーム系カテゴリが並ぶコミュニティ/技術系や読書会などのコミュニティ系カテゴリが並ぶノウハウ/各種ツールのノウハウ系カテゴリが並ぶFeedforce Inc./会社全体に関係する記事が置かれるUsers/Templates/Archived/例えば「プロダクト1」の下は、議事録系を除き基本的に Stock 型の記事になっており、「マニュアル」カテゴリの下にはさらに 15 の子カテゴリが生えているとします。プロダクト1/議事録/開発/コンサルティング/マーケティング/インシデント/ナレッジ/マニュアル/子カテゴリ数は 15︙その他/※ 複数のプロダクトから作った架空カテゴリです。ここまでならよく整理されているように見えますが、実際は古くてメンテナンスされていない記事が多く、言ってしまえばノイズが多い状況です。情報共有されればされるほど、ノイズが増えてしまう悪循環です。Slack に目を向けると、こちらもオープンではありますが、時にブログ記事並みのメッセージが投稿されることがあります。未読メッセージを読み進めると手が止まり、読み切るのが難しいと想像されます。ブログ記事並みのメッセージ例。これで半分です。細切れの情報も多く川の流れのようで、断片化した情報をつなぎ合わせるのは難しいと思います。世の中には情報共有が足りないことに悩む組織は多いと思いますが、活発になったとしても、適切に整理されていなければその量に溺れてしまいます。一方で、最近のコロナ禍もあって 10 年前と今とでは変化のスピードは上がっています。変化に強いチーム設計、つまりは変化に強い情報整理設計が重要です。これをやらなければ、チームのスピードは徐々に下がっていくでしょう。チームのスピードを上げるための大原則私が社内で様々なプロダクトを渡り歩いた経験上、チームのスピードを上げるためには以下の 2 点が重要だと感じています。ノイズを減らす情報を一ヶ所に集めるマネージャーはこれらの阻害要因を減らす仕掛けを作る必要があります。ただ、そういったことが得意な方ばかりではありません。むしろ情報量が一番多く、一番困っているのは彼らかもしれません。マネージャーに余裕がなければ、それがボトルネックとなりチームのスピードが下がります。これからその対策を考察していきます。チームのスピードを上げるための情報整理はじめに書いておくと、出来るだけ整理を頑張らないことが重要です。1. Flow 型と Stock 型の記事を理解するまずは公式ドキュメント「記事のストック・フローの分類と検索」を読んで、Flow 型と Stock 型の記事の存在を知り、理解します。2. 基本は Flow 型の記事にする全て Flow 型にするくらいの気持ちで記事を作ります。記事が多くなっても視界に入りづらいし、整理する必要もないためです。Flow 型記事の例書き捨ての記事であれば プロダクト1/2021/02/01/タイトル、今月中は更新する記事であれば プロダクト1/2021/02/タイトル で良いと思います。ただ、さすがに今年中更新する記事は Stock 型の記事にしたほうが良いと思います。3. 議事録カテゴリは出来るだけ作らないプロダクト1/議事録/ のような議事録カテゴリはできるだけ作らず、プロダクト1/2021/02/01/〇〇会議 議事録 のようなカテゴリとタイトルにします。議事録のような使い続けない記事を視界に入れるのは、どちらかと言えばノイズだからです。社内で以下のような階層をよく見かけますが3、一回限りの会議の置き場所に悩んでしまいます。プロダクト1/議事録/〇〇会議/YYYY/MM/DD/〇〇会議プランニング/YYYY/MM/DD/プランニングプロダクト1/議事録/20210201 〇×会議 議事録 のような自由なパターンも現れたりして、さらに悩ましくなります。過去の議事録をたどる目的でカテゴリを分けたいのであれば、記事の最初に「議事録一覧はこちら」みたいな検索リンクがあれば十分でしょう。「議事録一覧はこちら」の一例それでも作りたい場合は プロダクト1/議事録/〇〇会議/2021/02/01/〇〇会議 議事録 のような記事名にして、後から プロダクト1/2021/02/01/〇〇会議 議事録 に一括変換して視界から消せるように、設計するのが良いと思います。一括変換の仕方は公式ドキュメント「記事のカテゴリを一括変更」が分かりやすいです。4. Slack に流れていく情報も Flow 型の記事にするSlack にはブログ記事並みのメッセージが投稿されることがあります。そうなりそうになったら迷わず プロダクト1/2021/02/01/○○のお願い といった Flow 型の記事を作り、その URL を Slack で共有します。他の場面で引用したい時は意外とあるものですし、内容をあとで更新したいこともあります。Slack だと特にあとからの更新には不向きです。何より当該記事をブラウザで開き、残りの Slack 未読メッセージをスイスイと読むことが出来ます。Slack に投稿されてしまうと、その長いメッセージを読みながら、他の channel に移動するのは億劫です。5. 使い続けられる情報を Stock 記事として引き上げる結局のところ、ほとんどの情報は使い続けることはありません。具体的すぎるからです。そのような具体的な情報は寝かすことで、抽象度の高い情報、例えばカテゴリ名を炙り出せることがあります。良いカテゴリ名が思いつかない時は、まだ抽象度が高くないと思うので、引き上げないほうが良いでしょう。いくつかの Flow 記事をしばらく寝かしたら、あとから汎用的な抽象度の高い Stock 記事のアイディアが湧くこともあります。6. 整理を頑張らないことで整理の難易度が低くなったここまででほとんどの記事は Flow 型の記事のはずです。冒頭に述べたノイズになるような記事は少なく、情報に溺れる確率は低いと思います。使い回しが効かない具体的な情報を Flow 型の記事に追いやることで、整理の難易度を低くすることが出来ました。7. esa を全ての情報の起点にするでは、Google ドキュメントも同じようにしましょう！とは思っていません。esa を全ての情報の起点にする勢いで、適宜 Google ドキュメントにリンクを張ると良いでしょう。Google ドキュメントのフォルダ整理は出来るだけやらないほうが良いです。時間がいくらあっても足りません。Google Drive はただの情報プールです。Google Drive 内検索も優秀です。それをチームでやるのは難しすぎない？そう思った方、正しい感覚です。「チームのスピードを上げるための情報整理」は「私が考える esa 原理主義」に振り切って書きました。情報整理のスキルに関して少数精鋭チームでないと、運用するのは難しいと思います。現在私は開発者 1 人、ビジネスメンバー 2 人のチームに所属しています。私主導でカテゴリを決めているので、これまで書いた方法で整理し、うまくいっている実感があります。Flow 型の記事に対して、Stock 型の記事を少なく保てている。そういえば初期は Flow 型の記事しか作りませんでした。esa は難しいフィードフォースでは 1 年半ほど前まで Qiita:Team を使っていました。Qiita:Team はほぼ Flow 型の記事しか書けないため、これまで話した問題は出てきませんでした。いや「表面化しなかった」が正確でしょう。esa は Stock 型の記事も書けます。ブログと wiki が合体したようなツールなので、難しくないわけがありません。wiki を書くためには抽象的思考が必要です。私の観測範囲では、半分以上の方は具体的思考に寄り過ぎているため、得意ではないという実感です。意識したことがないかもしれません。esa の本当の正体正直言って現在の esa は「情報整理のスキルに関して少数精鋭チーム」でないと、乗りこなすのは難しいと思います。これに気づいた時、Ruby という言語に似ていると思いました。Ruby は esa で採用されているプログラミング言語です。初心者はにこやかに迎えてくれますが、本番環境で使い続けるためには、コードで表現されていない振る舞いを読み解く必要があるなど、実は少数精鋭チーム向けの言語です。esa LLC は少数精鋭チームのようなので、良くも悪くも「コンウェイの法則」が働いて、そのようなサービスになったのだと勝手に想像します。esa への要望社員数 100 人オーバーが見えてくると、型（制約）の必要性を感じます。新規作成時にデフォルトカテゴリが Flow 型になるような、型を設定できると良い？例: プロダクト1/ 以下での新規作成は、デフォルトカテゴリが プロダクト1/YYYY/MM/DD/ になるフレームワーク的に、何らかのパターン以外のカテゴリを作れないようにする？第一階層カテゴリ以下で、そのようなパターンを数種類から選べるようにする？どれも難しい話ですかね...？現在社内で抱えている課題として「記事整理にハードルがある」は間違いなくあると思います。たくさんの記事を移動すると、/posts がその情報で埋まる4移動しただけなのに、記事に自分の小さなアイコンが付くそもそも記事を 1 つ 1 つ移動するのが大変タイトルに入れてしまった日付をカテゴリにして...とかまですると、API を使わざるを得ない出来れば Windows のエクスプローラのようなカジュアルさで、且つ履歴が残るとうれしいです。あと、要望したことはありますが、現在の「カテゴリ以下の記事全て」に加えて、「カテゴリ直下の記事」「アーカイブした記事」を切り替えるような機能が欲しいです。イメージとしては、GitHub の UI に「カテゴリ直下の記事」を加えたものです。In, On, Archived を切り替えられるイメージ「カテゴリ直下の記事」は on:カテゴリ で検索できますが、知っているユーザーはごく僅かです。アーカイブの認知も怪しくて、古い記事が残る要因かもしれません。一部カテゴリではこんな工夫をしています。アーカイブという手段を認知させている例難しいと思いますが、情報整理のスキルがそれほど高くなくても使える UI 設計をお願いしたいところです。🙏もし、もっと詳しく私にヒアリングしたいなどあれば、masutaka@feedforce.jp または @masutaka の DM までお知らせ下さい。まとめ私から見える、フィードフォースで抱えている情報整理の課題をまとめ、チームのスピードを上げるための整理方法を提案しました。ただ、それは「私が考える esa 原理主義」に振り切っているため、チームで採用するのは難しいと思います。カテゴリがデフォルト Flow 型になるなど、情報整理を頑張らず済む使い勝手になると、とてもうれしいです。esa 公式アカウントからのアドバイス新規作成時にデフォルトカテゴリが Flow 型になるような、型を設定できると良い？こちらのアドバイスを頂いたので早速試しました。良さそうです！あるカテゴリ配下で "Create a new post" ボタンで記事を新規作成するときに、カテゴリが一致するFlowのテンプレートがあれば、そのテンプレートが自動的にプリセットされるという機能があります。（続く→）— esa_io (@esa_io) 2021年2月3日  例えば以下のテンプレートがあったとして- Templates/カテゴリ1/YYYY/MM/DD/テンプレートA- Templates/カテゴリ1/サブカテゴリ1/YYYY/MM/DD/テンプレートB「カテゴリ1」配下で記事作成→ テンプレートA 「カテゴリ1/サブカテゴリ2」配下で記事作成 →テンプレートB がそれぞれ自動適用されます— esa_io (@esa_io) 2021年2月3日  後日アンサー記事も頂きました！「所感」にこの記事の感想が書いてあります。ProTip/2021/02/03/特定のカテゴリ配下の記事作成時に、テンプレートを適用する - docs.esa.ioコラム自分の思いを書ききれないので、コラムに逃しました。(^^;記事のカテゴリ整理を頑張らない理由こんな理由からです。歴史が証明しているesa の検索がそこそこ優秀今では信じられないかもしれませんが、1990 年代の Yahoo! JAPAN は、人間のスタッフがウェブサイトの情報を収集してカテゴリ分類して登録する、ディレクトリ型検索サービスでした5。今はロボット型検索が使われているのは周知のとおりです。そのため Stock 型の記事だけを作り続けるといずれ破綻することは、1 歴史が証明していると言えます（やや大げさ）。2 については、公式ドキュメント「記事の検索方法」にある検索クエリで、それなりに検索できます（諸説あり）。「キーワード検索しやすい記事にするコツ」も参考にすると良いでしょう。Flow カテゴリをどこまで許容するかFlow カテゴリをどこまで許容するかは、悩ましいところです。(a) 制約をつけずに自由に作ることを許容するか。プロダクト1セールス...YYYYMMDD開発○○機能YYYYMMDDYYYYMMDDYYYYMMDD(b) 原理主義っぽく、１つの Flow カテゴリしか許容しないか。プロダクト1セールス...開発...YYYYMMDD(a) は職種横断的な情報共有を重視しないチームに合うと思います。中規模以上のチームです。(b) は職種横断的な情報共有を重視するチームに合うと思います。小さなチームです。はじめは (b) で作ってみて、やりづらくなってきたら (a) にすると良いでしょう。ただし、(a) の プロダクト1/開発/○○機能/YYYY/MM/DD/ まで細かく Flow カテゴリを作るのは、把握が難しくなりそうですので、オススメはしません。Google Workspace（旧称 G Suite）を契約しています。↩現在のメンバー数は 90、最古の記事は 2014/4/3 です。↩過去に推奨したことあります。ｽﾏﾇｽﾏﾇ…。↩Archived/ 以下への移動は更新日時が変わらず /posts に現れないので、カテゴリ一括変更と組み合わせれば、一応回避はできます。↩今回の件で調べたところ、その「Yahoo!カテゴリ」は2018年3月29日まで動いていたことを知りびっくりしました↩

変化に耐え得る esa のカテゴリ設計を徹底的に考えてみた

この記事は Feedforce Advent Calendar 2020 の 3 日目の記事です。
昨日は kysnrm の「さよなら湯島 」でした。私も今のところに住んで来年で 6 年になるので、8 回目の引っ越しを少し考えてますが、まだ状況が流動的なので悩ましい&hellip;。
（ここから歌詞）
優先度を付けると、高高高高高高とかになることあるよね。みんな優先度が高い。
でも人間は一度に複数のタスクを処理することは出来ないよ。
それに実際終わってみたら、終わった順番が付いているはずだよ。
じゃあ 1, 2, 3&hellip; とタスクに順番を付けてみようか。つまりは優先順位ね。
優先度より優先順位のほうが偉い。ダンダン
優先度は優先順位を決める１つの要素でしかないよ。区別しようか。
例えば他にもこんなのを考慮する必要があるよ。
・期日
・かかる時間
・かかるお金
・サービスへのインパクト（顧客増加、顧客満足度など）
・他のタスクがどれだけ効率化するか？
優先度より優先順位のほうが偉い。ダンダンダン
先の例だと、優先度はだいたい「期日」と「サービスへのインパクト」でふんわり決まっていることが多いと思うよ。
作業者は他の要素も考慮して「優先順位」を決めると良いよ。
とは言え、考えすぎても難しいから、最初は「優先度」「かかる時間」「期日」から「優先順位」を決めると良いよ。
タスクAのほうが優先度が高いけど、タスクBはすぐ終わりそうだし、タスクAの期日までまだ余裕があるから、タスクBを先にやろう的な。
優先度より優先順位のほうが偉い。ダンダンダ、ダン
つまりは優先度よりも優先順位は上位のレイヤー、優先度より優先順位のほうが偉いということよ！
優先度より優先順位のほうが偉い。ダンダンダ、ダダン（号泣してみんな立ち上がる）
（歌詞終わり）
次回（？）は、私が使っている優先順位を決めるための具体的なテクニックをご紹介します。
明日の Feedforce Advent Calendar 2020 は、八百くんがよく日報に書いていた AI Quest の話をしてくれるみたいです。お楽しみに。

この記事は Feedforce Advent Calendar 2020 の 3 日目の記事です。昨日は kysnrm の「さよなら湯島 」でした。私も今のところに住んで来年で 6 年になるので、8 回目の引っ越しを少し考えてますが、まだ状況が流動的なので悩ましい…。（ここから歌詞）優先度を付けると、高高高高高高とかになることあるよね。みんな優先度が高い。でも人間は一度に複数のタスクを処理することは出来ないよ。それに実際終わってみたら、終わった順番が付いているはずだよ。じゃあ 1, 2, 3… とタスクに順番を付けてみようか。つまりは優先順位ね。優先度より優先順位のほうが偉い。ダンダン優先度は優先順位を決める１つの要素でしかないよ。区別しようか。例えば他にもこんなのを考慮する必要があるよ。・期日・かかる時間・かかるお金・サービスへのインパクト（顧客増加、顧客満足度など）・他のタスクがどれだけ効率化するか？優先度より優先順位のほうが偉い。ダンダンダン先の例だと、優先度はだいたい「期日」と「サービスへのインパクト」でふんわり決まっていることが多いと思うよ。作業者は他の要素も考慮して「優先順位」を決めると良いよ。とは言え、考えすぎても難しいから、最初は「優先度」「かかる時間」「期日」から「優先順位」を決めると良いよ。タスクAのほうが優先度が高いけど、タスクBはすぐ終わりそうだし、タスクAの期日までまだ余裕があるから、タスクBを先にやろう的な。優先度より優先順位のほうが偉い。ダンダンダ、ダンつまりは優先度よりも優先順位は上位のレイヤー、優先度より優先順位のほうが偉いということよ！優先度より優先順位のほうが偉い。ダンダンダ、ダダン（号泣してみんな立ち上がる）（歌詞終わり）次回（？）は、私が使っている優先順位を決めるための具体的なテクニックをご紹介します。明日の Feedforce Advent Calendar 2020 は、八百くんがよく日報に書いていた AI Quest の話をしてくれるみたいです。お楽しみに。

優先度より優先順位のほうが偉い

こんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。最近の趣味はリハビリと YouTube 鑑賞です。

本日、週次の社内勉強会 <a href="https://developer.feedforce.jp/archive/category/FFTT">FFTT</a> で『4月から取り組んできたLookerの導入から実装までのお話（Redashとも比較）』という発表をしました。

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vQWgD1o2eZC69Mt9F9ln3xQL6Wx82W782cHe1YJEIPHWAdqp6tLEH_I29CyrMBbA9Ag0jmkMoQZ0QQp/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="400" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


4 月から <a href="https://jp.feedmatic.net/">Feedmatic</a> という弊社フィードフォースの広告運用サービスに BI ツールである <a href="https://ja.looker.com/">Looker</a> を導入すべく、検討と実装をしてきました。

関わっているエンジニアは私一人で、社内の他のエンジニアからは何やってきたか分からないと思っていたので、今までのまとめ的な発表をしました。

ネット上を探しても導入時の具体的な話は見つけられなかったので、誰かの参考になることも期待して、外向けも意識しています。

Looker ユーザ向けには P30 から「Symmetric 集計」を頑張って解説しています。説明が雑なのは認めます。🙏

Looker は学習コストは高いですが、かなりパワフルなツールなので、個人的には非常にやる気を出して燃えています。🔥

それでは！

こんにちは id:masutaka26 です。最近の趣味はリハビリと YouTube 鑑賞です。本日、週次の社内勉強会 FFTT で『4月から取り組んできたLookerの導入から実装までのお話（Redashとも比較）』という発表をしました。4 月から Feedmatic という弊社フィードフォースの広告運用サービスに BI ツールである Looker を導入すべく、検討と実装をしてきました。関わっているエンジニアは私一人で、社内の他のエンジニアからは何やってきたか分からないと思っていたので、今までのまとめ的な発表をしました。ネット上を探しても導入時の具体的な話は見つけられなかったので、誰かの参考になることも期待して、外向けも意識しています。Looker ユーザ向けには P30 から「Symmetric 集計」を頑張って解説しています。説明が雑なのは認めます。🙏Looker は学習コストは高いですが、かなりパワフルなツールなので、個人的には非常にやる気を出して燃えています。🔥それでは！

『4月から取り組んできたLookerの導入から実装までのお話（Redashとも比較）』という発表をした

こんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。足底筋膜炎は誤診のようでした。リハビリに勤しむ日々です。

今回は社内向けに書いた esa 記事が好評でしたので、少し改変してお届けします。

フィードフォースでは Slack を使っており、リモートワークにおけるコミュニケーションの手段も Slack がメインです。

Slack はチャットツールであるため、ある程度のリアルタイム性を求められますが、ただそれに従っていると振り回されてしまいます。

今回は私が実践しているいくつかの工夫を紹介します。他に良い方法があれば、是非教えてください。

<ul class="table-of-contents">
 <li><a href="#今すぐできないことあとでやるあとで確認するは自分にリマインドする">今すぐできないこと（あとでやる＆あとで確認する）は自分にリマインドする</a></li>
 <li><a href="#自分が他の人に依頼した時もリマインドを設定する">自分が他の人に依頼した時もリマインドを設定する</a></li>
 <li><a href="#チャンネルは優先度を付ける">チャンネルは優先度を付ける</a></li>
 <li><a href="#見なくなったチャンネルからはこまめに抜ける">見なくなったチャンネルからはこまめに抜ける</a></li>
 <li><a href="#未読チャンネルはショートカットキーで移動する">未読チャンネルはショートカットキーで移動する</a></li>
</ul>

<h2 id="今すぐできないことあとでやるあとで確認するは自分にリマインドする">今すぐできないこと（あとでやる＆あとで確認する）は自分にリマインドする</h2>

自分にリマインドすることで忘れることが出来る。同期的コミュニケーションを非同期に逃がす感じ。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20200627/20200627014903.png" alt="f:id:masutaka26:20200627014903p:plain" title="f:id:masutaka26:20200627014903p:plain" class="hatena-fotolife" itemprop="image">

👇 <code>slackbot</code> からの DM で通知される。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20200627/20200627013415.jpg" alt="f:id:masutaka26:20200627013415j:plain" title="f:id:masutaka26:20200627013415j:plain" class="hatena-fotolife" itemprop="image">

すぐ出来なくてさらに先延ばししたければ、Snooze する。出来ない時はゆるふわで良いので Snooze することが大事。放置しないようにしている。

👇 たまに <code>slackbot</code> の DM とかで <code>/remind list</code> して確認している。Snooze し忘れたりして、過去のリマインドが残っているとこんな感じになる。→ <code>Past and Incomplete</code>

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20200627/20200627013716.png" alt="f:id:masutaka26:20200627013716p:plain" title="f:id:masutaka26:20200627013716p:plain" class="hatena-fotolife" itemprop="image">

🌀 本当は Gmail の Inbox（受信トレイ）でリマインド管理したい。Snooze が使いやすいし。

<h2 id="自分が他の人に依頼した時もリマインドを設定する">自分が他の人に依頼した時もリマインドを設定する</h2>

相手が忘れても大丈夫になる。これも同期コミュニケーションから非同期への変換。

<h2 id="チャンネルは優先度を付ける">チャンネルは優先度を付ける</h2>

私の場合は <code>Starred</code> > <code>Low Priority</code> > <code>Channels</code> という優先度にしてます。
（優先度が分からなくなるので、<a href="https://slack.com/intl/ja-jp/help/articles/226410907-%E5%85%A8%E3%81%A6%E3%81%AE%E6%9C%AA%E8%AA%AD%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E3%82%92%E7%A2%BA%E8%AA%8D%E3%81%99%E3%82%8B">全未読機能</a>は使っていません）

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20200627/20200627014706.png" alt="f:id:masutaka26:20200627014706p:plain" title="f:id:masutaka26:20200627014706p:plain" class="hatena-fotolife" itemprop="image">

<code>Starred</code> と <code>Channels</code> は最初からあるグルーピングです。<code>Low Priority</code> は自分で作りました。

公式ヘルプ: <a href="https://slack.com/intl/ja-jp/help/articles/201331016-%E3%83%81%E3%83%A3%E3%83%B3%E3%83%8D%E3%83%AB%E3%82%84%E3%83%80%E3%82%A4%E3%83%AC%E3%82%AF%E3%83%88%E3%83%A1%E3%83%83%E3%82%BB%E3%83%BC%E3%82%B8%E3%81%AB%E3%82%B9%E3%82%BF%E3%83%BC%E3%82%92%E4%BB%98%E3%81%91%E3%82%8B">チャンネルやダイレクトメッセージにスターを付ける | Slack</a>

💡 <code>Channels</code> の中には mute しているチャンネルもあります。

<h2 id="見なくなったチャンネルからはこまめに抜ける">見なくなったチャンネルからはこまめに抜ける</h2>

抜けたいチャンネルで <code>/leave</code> と発言すると、一瞬で抜けられるよ。

<h2 id="未読チャンネルはショートカットキーで移動する">未読チャンネルはショートカットキーで移動する</h2>

<ul>
<li>Windows

<ul>
<li>前の未読チャンネルや DM に移動: <code>Alt</code> <code>Shift</code> <code>↑</code></li>
<li>次の未読チャンネルや DM に移動: <code>Alt</code> <code>Shift</code> <code>↓</code></li>
</ul>
</li>
<li>Mac

<ul>
<li>前の未読チャンネルや DM に移動: <code>Option</code> <code>Shift</code> <code>↑</code></li>
<li>次の未読チャンネルや DM に移動: <code>Option</code> <code>Shift</code> <code>↓</code></li>
</ul>
</li>
</ul>


公式ヘルプ: <a href="https://slack.com/intl/ja-jp/help/articles/201374536-Slack-%E3%81%AE%E3%82%AD%E3%83%BC%E3%83%9C%E3%83%BC%E3%83%89%E3%82%B7%E3%83%A7%E3%83%BC%E3%83%88%E3%82%AB%E3%83%83%E3%83%88">Slack のキーボードショートカット | Slack</a>

こんにちは id:masutaka26 です。足底筋膜炎は誤診のようでした。リハビリに勤しむ日々です。今回は社内向けに書いた esa 記事が好評でしたので、少し改変してお届けします。フィードフォースでは Slack を使っており、リモートワークにおけるコミュニケーションの手段も Slack がメインです。Slack はチャットツールであるため、ある程度のリアルタイム性を求められますが、ただそれに従っていると振り回されてしまいます。今回は私が実践しているいくつかの工夫を紹介します。他に良い方法があれば、是非教えてください。今すぐできないこと（あとでやる＆あとで確認する）は自分にリマインドする自分が他の人に依頼した時もリマインドを設定するチャンネルは優先度を付ける見なくなったチャンネルからはこまめに抜ける未読チャンネルはショートカットキーで移動する今すぐできないこと（あとでやる＆あとで確認する）は自分にリマインドする自分にリマインドすることで忘れることが出来る。同期的コミュニケーションを非同期に逃がす感じ。👇 slackbot からの DM で通知される。すぐ出来なくてさらに先延ばししたければ、Snooze する。出来ない時はゆるふわで良いので Snooze することが大事。放置しないようにしている。👇 たまに slackbot の DM とかで /remind list して確認している。Snooze し忘れたりして、過去のリマインドが残っているとこんな感じになる。→ Past and Incomplete🌀 本当は Gmail の Inbox（受信トレイ）でリマインド管理したい。Snooze が使いやすいし。自分が他の人に依頼した時もリマインドを設定する相手が忘れても大丈夫になる。これも同期コミュニケーションから非同期への変換。チャンネルは優先度を付ける私の場合は Starred > Low Priority > Channels という優先度にしてます。（優先度が分からなくなるので、全未読機能は使っていません）Starred と Channels は最初からあるグルーピングです。Low Priority は自分で作りました。公式ヘルプ: チャンネルやダイレクトメッセージにスターを付ける | Slack💡 Channels の中には mute しているチャンネルもあります。見なくなったチャンネルからはこまめに抜ける抜けたいチャンネルで /leave と発言すると、一瞬で抜けられるよ。未読チャンネルはショートカットキーで移動するWindows前の未読チャンネルや DM に移動: Alt Shift ↑次の未読チャンネルや DM に移動: Alt Shift ↓Mac前の未読チャンネルや DM に移動: Option Shift ↑次の未読チャンネルや DM に移動: Option Shift ↓公式ヘルプ: Slack のキーボードショートカット | Slack

個人的に実践している、Slack に振り回されない方法

こんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。最近はドラクエウォークと足底筋膜炎との両立に悩んでいます。

先週の金曜日、週次の社内勉強会 <a href="https://developer.feedforce.jp/archive/category/FFTT">FFTT</a> で『HerokuでSidekiqを監視する方法を確立した』という発表をしました。

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vTZAByBIEhPjehZJ8Jb3atZBJSpu1R371Z3qQZcolE99poCpdYHWfWl5tlH2pQxwBedoCBPYK8rTwoI/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="400" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


Heroku で Sidekiq を監視する知見を見つけられなかったのが、このお題を選んだ経緯です。どなたかが参考になるとうれしいです。

今回は自宅からのリモート発表でした。物理発表と違って、話した内容よりもリアクションの分からなさによる戸惑いが気になってしまいました。（オイ

※ リアクションはしてくれてたみたいです。🙏

複数モニター必須とか、いろいろ知見がありそうなので、今後蓄積出来ると良さそうです。

こんにちは id:masutaka26 です。最近はドラクエウォークと足底筋膜炎との両立に悩んでいます。先週の金曜日、週次の社内勉強会 FFTT で『HerokuでSidekiqを監視する方法を確立した』という発表をしました。Heroku で Sidekiq を監視する知見を見つけられなかったのが、このお題を選んだ経緯です。どなたかが参考になるとうれしいです。今回は自宅からのリモート発表でした。物理発表と違って、話した内容よりもリアクションの分からなさによる戸惑いが気になってしまいました。（オイ※ リアクションはしてくれてたみたいです。🙏複数モニター必須とか、いろいろ知見がありそうなので、今後蓄積出来ると良さそうです。

『HerokuでSidekiqを監視する方法を確立した』という発表をした

こんにちは。<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。

半年くらい前から <a href="https://devcenter.heroku.com/articles/language-runtime-metrics-ruby">Heroku の Ruby Language Metrics</a> (Public Beta) を使い始めました。その時、どのようにメトリクスを収集しているか調べたので、この記事にまとめます。（なぜこのタイミング...）

有効にする方法は前述の公式ドキュメントをどうぞ。<a href="http://blog.hatena.ne.jp/sho7650/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/sho7650/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:sho7650</a> の記事も併せて読むと分かりやすいと思います。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Fsho7650%2Fitems%2F7315e78fa3e6aa75b85b" title="[Ruby] より細かくMetricsを取得したい [Heroku] - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://qiita.com/sho7650/items/7315e78fa3e6aa75b85b">qiita.com</a></cite>

ところで、いつから Public Beta だったのですかね？ GA はいつになるのかな...？

<h2>概要</h2>

今回は Rails 前提で説明します。このような仕組みでメトリクスの収集と送信が行われます。

<ol>
<li><a href="https://github.com/heroku/heroku-buildpack-metrics/">heroku/metrics buildpack</a> により、Dyno 起動時に <a href="https://github.com/heroku/agentmon">agentmon</a> がインストールされ、常駐する</li>
<li>Rails が起動すると、<a href="https://github.com/heroku/barnes">barnes</a> gem がメトリクスを収集し始め、定期的に localhost の agentmon に送信する</li>
<li>agentmon は <code>https://app.metrics.heroku.com/&lt;dyno id&gt;</code> にメトリクスを送信する</li>
<li>エンジニアは Heroku Dashboard から Ruby のメトリクスを閲覧できる</li>
</ol>


<h2>agentmon のインストールと起動</h2>

<a href="https://github.com/heroku/heroku-buildpack-metrics/">heroku/metrics buildpack</a> によって、agentmon というデーモンがインストールされます。

<a class="embedly-card" href="https://github.com/heroku/agentmon">heroku/agentmon</a>

agentmon は後述する barnes gem から受け取ったメトリクスを <code>https://app.metrics.heroku.com/&lt;dyno id&gt;</code> に送信します。

この URL は環境変数 <code>HEROKU_METRICS_URL</code> の値で、Heroku Dashboard から Enhanced Language Metrics を有効にすると、各 Dyno で定義されます。

面白いのは、Slug 生成時には <a href="https://github.com/heroku/heroku-buildpack-metrics/blob/053529d2488d1108d8fd777c2ef6575d899dcf20/bin/compile#L15-L17">/app/.profile.d/heroku-metrics-daemon.sh がインストールされる</a>だけで、Dyno 起動時にこのスクリプトが実行され、<a href="https://github.com/heroku/heroku-buildpack-metrics/blob/053529d2488d1108d8fd777c2ef6575d899dcf20/.profile.d/heroku-metrics-daemon.sh">agentmon のインストールと起動が行われる</a>ことです。

Dyno では通常 Puma などのプロセスしか起動されませんが、このような方法を使えばデーモンも起動できることを初めて知りました。

ちなみに <a href="https://devcenter.heroku.com/articles/buildpack-api#profile-d-scripts">Dyno が起動する時 /etc/profile によって <code>/app/.profile.d/*.sh</code> がすべて実行されます</a>。

<h2>barnes gem によるメトリクス収集と送信</h2>

<a class="embedly-card" href="https://github.com/heroku/barnes">heroku/barnes</a>

Rails が起動すると、<a href="https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes.rb#L40-L64">Barnes.start</a> から呼ばれる <a href="https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/periodic.rb#L31-L67">Barnes::Periodic.new</a> で Ruby のスレッドが作られます。

<code>Barnes.start</code> はすぐに終了しますが、作られたスレッドは非同期で実行されます。無限ループのスレッドなので、Rails が起動している間、起動し続けます。

この無限ループでは 10 秒に 1 回、後述するメトリクスを収集し、localhost の agentmon に送信します。

送信するのはスレッド中のインスタンス変数 <code>@reporter</code> です。これは <a href="https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/reporter.rb">Barnes::Reporter</a> のインスタンスで、<code>statsd_client</code> を介して agentmon に送信します。

<code>statsd_client</code> は <code>Barnes::Reporter.new</code> 時に渡されます。
<a href="https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes.rb#L51">https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes.rb#L51</a>

<h2>収集されるメトリクス</h2>

<code>Barnes::ResourceUsage</code> では収集されるメトリクスを一望できます。
<a href="https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/resource_usage.rb#L28-L63">https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/resource_usage.rb#L28-L63</a>

収集されるメトリクスと、収集方法です。

<ul>
<li>Puma のメトリクス（ <code>Barnes::Instruments::PumaInstrument</code> ）

<ul>
<li><a href="https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/instruments/puma_instrument.rb#L33-L48">https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/instruments/puma_instrument.rb#L33-L48</a></li>
</ul>
</li>
<li>CPU 実行時間等のメトリクス（ <code>Barnes::Instruments::Stopwatch</code> ）

<ul>
<li><a href="https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/instruments/stopwatch.rb#L36-L58">https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/instruments/stopwatch.rb#L36-L58</a></li>
</ul>
</li>
<li><a href="https://docs.ruby-lang.org/ja/2.7.0/class/ObjectSpace.html#M_COUNT_OBJECTS">ObjectSpace.count_objects</a> の結果（ <code>Barnes::Instruments::ObjectSpaceCounter</code> ）

<ul>
<li><a href="https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/instruments/object_space_counter.rb#L27-L30">https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/instruments/object_space_counter.rb#L27-L30</a></li>
</ul>
</li>
<li><a href="https://docs.ruby-lang.org/ja/2.7.0/method/GC/s/stat.html">GC.stat</a> の結果（ <code>Barnes::Instruments::RubyGC</code> ）

<ul>
<li><a href="https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/instruments/ruby_gc.rb#L62-L84">https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/instruments/ruby_gc.rb#L62-L84</a></li>
</ul>
</li>
</ul>


<h2>まとめ</h2>

Heroku Ruby Language Metrics のメトリクス収集の仕組みを調べました。

ただ有効にするだけだと、他のエンジニアに説明することができなかったことが、今回調べた動機です。

今回に限りませんが、Heroku は完全なブラックボックスではなく、調べると実装が透けて見えるのがとても良いと思います。

<script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script>

こんにちは。id:masutaka26 です。半年くらい前から Heroku の Ruby Language Metrics (Public Beta) を使い始めました。その時、どのようにメトリクスを収集しているか調べたので、この記事にまとめます。（なぜこのタイミング...）有効にする方法は前述の公式ドキュメントをどうぞ。id:sho7650 の記事も併せて読むと分かりやすいと思います。qiita.comところで、いつから Public Beta だったのですかね？ GA はいつになるのかな...？概要今回は Rails 前提で説明します。このような仕組みでメトリクスの収集と送信が行われます。heroku/metrics buildpack により、Dyno 起動時に agentmon がインストールされ、常駐するRails が起動すると、barnes gem がメトリクスを収集し始め、定期的に localhost の agentmon に送信するagentmon は https://app.metrics.heroku.com/<dyno id> にメトリクスを送信するエンジニアは Heroku Dashboard から Ruby のメトリクスを閲覧できるagentmon のインストールと起動heroku/metrics buildpack によって、agentmon というデーモンがインストールされます。heroku/agentmonagentmon は後述する barnes gem から受け取ったメトリクスを https://app.metrics.heroku.com/<dyno id> に送信します。この URL は環境変数 HEROKU_METRICS_URL の値で、Heroku Dashboard から Enhanced Language Metrics を有効にすると、各 Dyno で定義されます。面白いのは、Slug 生成時には /app/.profile.d/heroku-metrics-daemon.sh がインストールされるだけで、Dyno 起動時にこのスクリプトが実行され、agentmon のインストールと起動が行われることです。Dyno では通常 Puma などのプロセスしか起動されませんが、このような方法を使えばデーモンも起動できることを初めて知りました。ちなみに Dyno が起動する時 /etc/profile によって /app/.profile.d/*.sh がすべて実行されます。barnes gem によるメトリクス収集と送信heroku/barnesRails が起動すると、Barnes.start から呼ばれる Barnes::Periodic.new で Ruby のスレッドが作られます。Barnes.start はすぐに終了しますが、作られたスレッドは非同期で実行されます。無限ループのスレッドなので、Rails が起動している間、起動し続けます。この無限ループでは 10 秒に 1 回、後述するメトリクスを収集し、localhost の agentmon に送信します。送信するのはスレッド中のインスタンス変数 @reporter です。これは Barnes::Reporter のインスタンスで、statsd_client を介して agentmon に送信します。statsd_client は Barnes::Reporter.new 時に渡されます。https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes.rb#L51収集されるメトリクスBarnes::ResourceUsage では収集されるメトリクスを一望できます。https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/resource_usage.rb#L28-L63収集されるメトリクスと、収集方法です。Puma のメトリクス（ Barnes::Instruments::PumaInstrument ）https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/instruments/puma_instrument.rb#L33-L48CPU 実行時間等のメトリクス（ Barnes::Instruments::Stopwatch ）https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/instruments/stopwatch.rb#L36-L58ObjectSpace.count_objects の結果（ Barnes::Instruments::ObjectSpaceCounter ）https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/instruments/object_space_counter.rb#L27-L30GC.stat の結果（ Barnes::Instruments::RubyGC ）https://github.com/heroku/barnes/blob/v0.0.8/lib/barnes/instruments/ruby_gc.rb#L62-L84まとめHeroku Ruby Language Metrics のメトリクス収集の仕組みを調べました。ただ有効にするだけだと、他のエンジニアに説明することができなかったことが、今回調べた動機です。今回に限りませんが、Heroku は完全なブラックボックスではなく、調べると実装が透けて見えるのがとても良いと思います。

Heroku Ruby Language Metrics のメトリクス収集の仕組みを調べた

土曜日にこんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。

この記事は Heroku Advent Calendar 2019 の 14 日目の記事です。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Fadvent-calendar%2F2019%2Fheroku" title="Heroku Advent Calendar 2019 - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://qiita.com/advent-calendar/2019/heroku">qiita.com</a></cite>

昨日は <a href="https://qiita.com/takahito0508">@takahito0508</a> さんの『<a href="https://qiita.com/takahito0508/items/0f30e441dd5fba673560">Salesforce の Org Development 用の Buildpack を作った話</a>』でした。Heroku の Buildpack は割と簡単な仕組みなので、ハードルが低いですよね。

さて、同じ日（2019/12/13）に開催された <a href="https://herokujp.doorkeeper.jp/events/99972">Heroku Meetup #27 "Heroku Vitamin!"</a> で『デプロイで止まらないバッチ処理を求めて』というお題で発表してきました。

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vRVD7Gx345OvUDpoGaRxv5sYQB9uCpvFORJvhgKWySCxNd3WqQQEM4Gfpx0OJYoOyf2sY8GVUKD3spA/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="400" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


Heroku meetup は<a href="https://herokujp.doorkeeper.jp/events/93092">前々回 #25</a> 以来の参加と登壇です。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2019%2F07%2F29%2F140000" title="Heroku Meetup #25 &quot;Heroku Ghost&quot; で 2 回話してきた #herokujp - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2019/07/29/140000">developer.feedforce.jp</a></cite>

<h2>所感</h2>

世の中では割と多くのバッチ処理が動いていると思います。ですが、Heroku 上でのバッチ処理はあまり情報がないので、今回紹介させて頂きました。技術スタックとしては、Rails の Active Job と Sidekiq です。

今回もニッチな発表ができてとても満足しています。会場にいる一人に刺されば大成功くらいの気持ちで発表していました。

中の人曰く、こんな One-Off Dyno の使い方をする人は初めて見たとのこと。(^^;

使い方としては問題ないそうですが、<a href="https://devcenter.heroku.com/articles/dyno-runtime#private-spaces-runtime">Private Spaces</a> では Dyno の起動が遅いそうなので、そこはやや注意とのこと。

※ <a href="https://ecbooster.jp/">EC Booster</a> では一般向けの <a href="https://devcenter.heroku.com/articles/dyno-runtime#common-runtime">Common Runtime</a> を使っています。

とは言え、<a href="https://devcenter.heroku.com/articles/platform-api-reference#dyno-create">Dyno Create API</a> は Dyno の起動完了を待たずに即座に終了するため、Private Spaces でも大丈夫みたいです。

<blockquote class="twitter-tweet" data-lang="ja">.<a href="https://twitter.com/masutaka?ref_src=twsrc%5Etfw">@masutaka</a> さんのお話 <a href="https://twitter.com/hashtag/herokujp?src=hash&amp;ref_src=twsrc%5Etfw">#herokujp</a> <a href="https://t.co/RZnLFWq9qn">pic.twitter.com/RZnLFWq9qn</a>&mdash; Satoshi Nagano (@thisisnagano) <a href="https://twitter.com/thisisnagano/status/1205437869453500416?ref_src=twsrc%5Etfw">2019年12月13日</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

明日は <a href="https://qiita.com/seijikohara">@seijikohara</a> さんです。お楽しみに。

土曜日にこんにちは id:masutaka26 です。この記事は Heroku Advent Calendar 2019 の 14 日目の記事です。qiita.com昨日は @takahito0508 さんの『Salesforce の Org Development 用の Buildpack を作った話』でした。Heroku の Buildpack は割と簡単な仕組みなので、ハードルが低いですよね。さて、同じ日（2019/12/13）に開催された Heroku Meetup #27 "Heroku Vitamin!" で『デプロイで止まらないバッチ処理を求めて』というお題で発表してきました。Heroku meetup は前々回 #25 以来の参加と登壇です。developer.feedforce.jp所感世の中では割と多くのバッチ処理が動いていると思います。ですが、Heroku 上でのバッチ処理はあまり情報がないので、今回紹介させて頂きました。技術スタックとしては、Rails の Active Job と Sidekiq です。今回もニッチな発表ができてとても満足しています。会場にいる一人に刺されば大成功くらいの気持ちで発表していました。中の人曰く、こんな One-Off Dyno の使い方をする人は初めて見たとのこと。(^^;使い方としては問題ないそうですが、Private Spaces では Dyno の起動が遅いそうなので、そこはやや注意とのこと。※ EC Booster では一般向けの Common Runtime を使っています。とは言え、Dyno Create API は Dyno の起動完了を待たずに即座に終了するため、Private Spaces でも大丈夫みたいです。.@masutaka さんのお話 #herokujp pic.twitter.com/RZnLFWq9qn— Satoshi Nagano (@thisisnagano) 2019年12月13日明日は @seijikohara さんです。お楽しみに。

Heroku Meetup #27 で『デプロイで止まらないバッチ処理を求めて』という話をしてきた #herokujp

こんにちは。<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。

去年の 6/30 からジムに通い始めて、なんとか週に 2~3 のペースで続いています。サプリメントも半信半疑ながら毎日飲んでいますが、ドラッグストアや Amazon で買うと割と高いと思います。

個人的には <a href="https://jp.iherb.com/">iHerb</a> がだいぶオススメです。以前 3.6kg のプロテインを買ったらなぜかキャンペーンが適用されて、30% オフの 6,517 円になりました。

さらにこの<a href="https://www.youtube.com/watch?v=ue0EFA_SxZc">案件動画</a>を見て、プレワークアウトサプリ（C4 SPORT）にも手を出してしまいました。BCAA も飲んでいます。

Twitter とかで検索すると、初回 10% OFF の紹介コードが見つかると思います。さらにお得です。

何の記事でしたっけ...？そうだ、この記事は <a href="https://adventar.org/calendars/4169">Feedforce Advent Calendar 2019</a> の 5 日目の記事です！

昨日は <a href="http://blog.hatena.ne.jp/kano-e/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/kano-e/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:kano-e</a> の「2019 年に会社ボドゲ棚から自宅に持ち帰ったボドゲたち」でした。変わらぬボドゲ愛・・・！

<iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fff-boardgame.hatenablog.com%2Fentry%2F2019%2F12%2F04%2F000000" title="2019 年に会社ボドゲ棚から自宅に持ち帰ったボドゲたち - フィードフォース ボドゲ部" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://ff-boardgame.hatenablog.com/entry/2019/12/04/000000">ff-boardgame.hatenablog.com</a></cite>

<h2>sidekiq-cron で月末を指定する</h2>

脈絡ありませんが、<a href="https://github.com/ondrejbartas/sidekiq-cron">sidekiq-cron</a> では <code>last</code> で月末を指定することが出来ます。

例えば <code>0 12 last * * Asia/Tokyo</code> の次回実行は <code>2019/12/31 12:00 JST</code> です。<code>2019/11/30 12:00 JST</code> は無事動きました。

このような設定になります。

<pre class="code lang-yaml" data-lang="yaml" data-unlink>sample_job:
 active_job: true
 cron: &quot;0 12 last * * Asia/Tokyo&quot;
 class: &quot;SampleJob&quot;
 queue: default
</pre>


この cron 書式は sidekiq-cron が依存する <a href="https://github.com/floraison/fugit">fugit</a> による実装です。

確認はしていませんが、<code>last</code> の他にも <code>-1</code> や <code>L</code> などが使えるようです。

🔗 <a href="https://github.com/floraison/fugit/blob/v1.3.3/spec/cron_spec.rb#L734-L747">https://github.com/floraison/fugit/blob/v1.3.3/spec/cron_spec.rb#L734-L747</a>

<pre class="code lang-ruby" data-lang="ruby" data-unlink>context 'negative monthdays' do

 [
 [ '* * -1 * *', '* * -1 * *' ],
 [ '* * -7--1 * *', '* * -7,-6,-5,-4,-3,-2,-1 * *' ],
 [ '* * -1--27 * *', '* * -31,-30,-29,-28,-27,-1 * *' ],
 [ '* * -7--1/2 * *', '* * -7,-5,-3,-1 * *' ],
 [ '* * L * *', '* * -1 * *' ],
 [ '* * -7-L * *', '* * -7,-6,-5,-4,-3,-2,-1 * *' ],
 [ '* * last * *', '* * -1 * *' ],
 ].each { |c, e|
 it(&quot;parses #{c}&quot;) { expect(Fugit::Cron.parse(c).to_cron_s).to eq(e) }
 }
end
</pre>


<code>negative monthdays</code> って表現は面白い。

<h2>healthchecks.io で月末のバッチを監視する</h2>

バッチが本当に起動したかを監視するのは難しいと思います。月末の監視はさらに難しいと思います。

過度な依存は禁物ですが、<a href="https://healthchecks.io/">healthchecks.io</a> は選択肢に入れても良いかもしれません。以下の記事をどうぞ。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2018%2F10%2F09%2F140000" title="terraform-provider-healthchecksio に足りない機能を実装したらコラボレータになれた - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2018/10/09/140000">developer.feedforce.jp</a></cite>

前述の cron 設定だと <code>0 12 l * *</code> で監視することが出来ます。<code>l</code> は小文字のエルです。

terraform-provider-healthchecksio の設定例です。

<pre class="code lang-tf" data-lang="tf" data-unlink>resource &quot;healthchecksio_check&quot; &quot;sample_job&quot; {
 name = &quot;SampleJob&quot;
 tags = [&quot;production&quot;]
 grace = &quot;60&quot;
 schedule = &quot;0 12 l * *&quot;
 timezone = &quot;Asia/Tokyo&quot;
 channels = [data.healthchecksio_channel.slack.id]
}

data &quot;healthchecksio_channel&quot; &quot;slack&quot; {
 kind = &quot;slack&quot;
}
</pre>


こちらの cron 書式は <a href="https://github.com/healthchecks/healthchecks">healthchecks</a> が依存する <a href="https://github.com/taichino/croniter">croniter</a> による実装です。

<code>l</code> 以外の指定は見当たりませんでした。

🔗 <a href="https://github.com/taichino/croniter/blob/0.3.29/src/croniter/tests/test_croniter.py#L209-L223">https://github.com/taichino/croniter/blob/0.3.29/src/croniter/tests/test_croniter.py#L209-L223</a>

<pre class="code lang-python" data-lang="python" data-unlink>def testLastDayOfMonth(self):
 base = datetime(2015, 9, 4)
 itr = croniter('0 0 l * *', base)
 n1 = itr.get_next(datetime)
 self.assertEqual(n1.month, 9)
 self.assertEqual(n1.day, 30)
 n2 = itr.get_next(datetime)
 self.assertEqual(n2.month, 10)
 self.assertEqual(n2.day, 31)
 n3 = itr.get_next(datetime)
 self.assertEqual(n3.month, 11)
 self.assertEqual(n3.day, 30)
 n4 = itr.get_next(datetime)
 self.assertEqual(n4.month, 12)
 self.assertEqual(n4.day, 31)
</pre>


2019 年もそろそろ終わりです。年末にだけ動くバッチを設定＆監視するのも良いかもしれません。

明日は、こばりゅうの記事です。ひこうきかっけー！？お楽しみに。

こんにちは。id:masutaka26 です。去年の 6/30 からジムに通い始めて、なんとか週に 2~3 のペースで続いています。サプリメントも半信半疑ながら毎日飲んでいますが、ドラッグストアや Amazon で買うと割と高いと思います。個人的には iHerb がだいぶオススメです。以前 3.6kg のプロテインを買ったらなぜかキャンペーンが適用されて、30% オフの 6,517 円になりました。さらにこの案件動画を見て、プレワークアウトサプリ（C4 SPORT）にも手を出してしまいました。BCAA も飲んでいます。Twitter とかで検索すると、初回 10% OFF の紹介コードが見つかると思います。さらにお得です。何の記事でしたっけ...？そうだ、この記事は Feedforce Advent Calendar 2019 の 5 日目の記事です！昨日は id:kano-e の「2019 年に会社ボドゲ棚から自宅に持ち帰ったボドゲたち」でした。変わらぬボドゲ愛・・・！ff-boardgame.hatenablog.comsidekiq-cron で月末を指定する脈絡ありませんが、sidekiq-cron では last で月末を指定することが出来ます。例えば 0 12 last * * Asia/Tokyo の次回実行は 2019/12/31 12:00 JST です。2019/11/30 12:00 JST は無事動きました。このような設定になります。sample_job:  active_job: true  cron: "0 12 last * * Asia/Tokyo"  class: "SampleJob"  queue: defaultこの cron 書式は sidekiq-cron が依存する fugit による実装です。確認はしていませんが、last の他にも -1 や L などが使えるようです。🔗 https://github.com/floraison/fugit/blob/v1.3.3/spec/cron_spec.rb#L734-L747context 'negative monthdays' do  [    [ '* * -1 * *', '* * -1 * *' ],    [ '* * -7--1 * *', '* * -7,-6,-5,-4,-3,-2,-1 * *' ],    [ '* * -1--27 * *', '* * -31,-30,-29,-28,-27,-1 * *' ],    [ '* * -7--1/2 * *', '* * -7,-5,-3,-1 * *' ],    [ '* * L * *', '* * -1 * *' ],    [ '* * -7-L * *', '* * -7,-6,-5,-4,-3,-2,-1 * *' ],    [ '* * last * *', '* * -1 * *' ],  ].each { |c, e|    it("parses #{c}") { expect(Fugit::Cron.parse(c).to_cron_s).to eq(e) }  }endnegative monthdays って表現は面白い。healthchecks.io で月末のバッチを監視するバッチが本当に起動したかを監視するのは難しいと思います。月末の監視はさらに難しいと思います。過度な依存は禁物ですが、healthchecks.io は選択肢に入れても良いかもしれません。以下の記事をどうぞ。developer.feedforce.jp前述の cron 設定だと 0 12 l * * で監視することが出来ます。l は小文字のエルです。terraform-provider-healthchecksio の設定例です。resource "healthchecksio_check" "sample_job" {  name     = "SampleJob"  tags     = ["production"]  grace    = "60"  schedule = "0 12 l * *"  timezone = "Asia/Tokyo"  channels = [data.healthchecksio_channel.slack.id]}data "healthchecksio_channel" "slack" {  kind = "slack"}こちらの cron 書式は healthchecks が依存する croniter による実装です。l 以外の指定は見当たりませんでした。🔗 https://github.com/taichino/croniter/blob/0.3.29/src/croniter/tests/test_croniter.py#L209-L223def testLastDayOfMonth(self):    base = datetime(2015, 9, 4)    itr = croniter('0 0 l * *', base)    n1 = itr.get_next(datetime)    self.assertEqual(n1.month, 9)    self.assertEqual(n1.day, 30)    n2 = itr.get_next(datetime)    self.assertEqual(n2.month, 10)    self.assertEqual(n2.day, 31)    n3 = itr.get_next(datetime)    self.assertEqual(n3.month, 11)    self.assertEqual(n3.day, 30)    n4 = itr.get_next(datetime)    self.assertEqual(n4.month, 12)    self.assertEqual(n4.day, 31)2019 年もそろそろ終わりです。年末にだけ動くバッチを設定＆監視するのも良いかもしれません。明日は、こばりゅうの記事です。ひこうきかっけー！？お楽しみに。

月末に起動したいバッチを sidekiq-cron で指定し、healthchecks.io で監視する

こんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。

先週金曜日（2019/7/26）に開催された <a href="https://herokujp.doorkeeper.jp/events/93092">Heroku Meetup #25 "Heroku Ghost"</a> で『デプロイ元をCircleCIからHerokuに乗り換えた』というお題で発表してきました。

<iframe src="https://docs.google.com/presentation/d/e/2PACX-1vRy7z2A77VE4UNCp7EhpFgeQr7fl8XqHolYwsaokN76rGCvoeo1SKh1hkNg3ew2D4pSLoQAz-iefLnR/embed?start=false&loop=false&delayms=3000" frameborder="0" width="960" height="400" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true"></iframe>


つい先日、現在関わっている <a href="https://app.ecbooster.jp/">EC Booster</a> のデプロイフローを改善し、それなりに知見を得られたためです。

Heroku Meetup の参加は<a href="https://herokujp.doorkeeper.jp/events/91348">前回 #24</a> に引き続き、セッションでの発表は<a href="https://herokujp.doorkeeper.jp/events/82754">前々回 #23</a> 以来です。

前々回 #23 については自分のブログにも書きました。

<a href="https://masutaka.net/chalow/2018-11-28-1.html">Heroku Meetup #23 "Heroku Dynamite!!" で話してきた #herokujp / マスタカの ChangeLog メモ</a>

<h2>LT でも話した</h2>

LT でも飛び込みで話しました。内容は <a href="https://github.com/heroku/heroku-buildpack-google-chrome">heroku-buildpack-google-chrome</a> と <a href="https://github.com/heroku/heroku-buildpack-chromedriver">heroku-buildpack-chromedriver</a> の細かすぎる話です。動かない Chrome や chromedriver のバイナリが本番環境にデプロイされることを防ぐ方法や、それに関して PR を出した話など。スライドの 41~43 ページ目が相当します。

無駄に元気な 1 日でした。

<blockquote class="twitter-tweet" data-lang="ja">今日は会社で LT 1 本やって、Heroku meetup で通常セッション 1 本、その後に飛び込み（？）で LT 1 本やった。さすがにもうこの数をやることないかな？ <a href="https://twitter.com/hashtag/herokujp?src=hash&amp;ref_src=twsrc%5Etfw">#herokujp</a>&mdash; Takashi MASUDA (@masutaka) <a href="https://twitter.com/masutaka/status/1154719579374936065?ref_src=twsrc%5Etfw">2019年7月26日</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

※ 44~45 ページ目は、尺の関係で削ったブランチ戦略のメモです。ベストな戦略ではないので改善予定。

<h2>雑感</h2>

初心者向けの知見に比べて、一歩進んだ Heroku 知見はあまり Web 上に存在しない印象です。

ここ 1 年近く、それなりに Heroku を学習してきて「かなりの規模まで Heroku で十分では？」「デプロイや Dyno の再起動で中断されるため苦手とされがちなバッチ処理も、簡単に克服できるのでは？」などと、考えが変わってきています。

これからもブログや登壇などで、コミュニティに還元していきます。

<blockquote class="twitter-tweet" data-lang="ja">本日の頂き物。キャップはスピーカー特典 <a href="https://twitter.com/hashtag/herokujp?src=hash&amp;ref_src=twsrc%5Etfw">#herokujp</a> <a href="https://t.co/Whc3UVJrbg">pic.twitter.com/Whc3UVJrbg</a>&mdash; Takashi MASUDA (@masutaka) <a href="https://twitter.com/masutaka/status/1154746086814150658?ref_src=twsrc%5Etfw">2019年7月26日</a></blockquote><script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

こんにちは id:masutaka26 です。先週金曜日（2019/7/26）に開催された Heroku Meetup #25 "Heroku Ghost" で『デプロイ元をCircleCIからHerokuに乗り換えた』というお題で発表してきました。つい先日、現在関わっている EC Booster のデプロイフローを改善し、それなりに知見を得られたためです。Heroku Meetup の参加は前回 #24 に引き続き、セッションでの発表は前々回 #23 以来です。前々回 #23 については自分のブログにも書きました。Heroku Meetup #23 "Heroku Dynamite!!" で話してきた #herokujp / マスタカの ChangeLog メモLT でも話したLT でも飛び込みで話しました。内容は heroku-buildpack-google-chrome と heroku-buildpack-chromedriver の細かすぎる話です。動かない Chrome や chromedriver のバイナリが本番環境にデプロイされることを防ぐ方法や、それに関して PR を出した話など。スライドの 41~43 ページ目が相当します。無駄に元気な 1 日でした。今日は会社で LT 1 本やって、Heroku meetup で通常セッション 1 本、その後に飛び込み（？）で LT 1 本やった。さすがにもうこの数をやることないかな？ #herokujp— Takashi MASUDA (@masutaka) 2019年7月26日※ 44~45 ページ目は、尺の関係で削ったブランチ戦略のメモです。ベストな戦略ではないので改善予定。雑感初心者向けの知見に比べて、一歩進んだ Heroku 知見はあまり Web 上に存在しない印象です。ここ 1 年近く、それなりに Heroku を学習してきて「かなりの規模まで Heroku で十分では？」「デプロイや Dyno の再起動で中断されるため苦手とされがちなバッチ処理も、簡単に克服できるのでは？」などと、考えが変わってきています。これからもブログや登壇などで、コミュニティに還元していきます。本日の頂き物。キャップはスピーカー特典 #herokujp pic.twitter.com/Whc3UVJrbg— Takashi MASUDA (@masutaka) 2019年7月26日

Heroku Meetup #25 "Heroku Ghost" で 2 回話してきた #herokujp

こんにちは。増田（<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a>）です。今回はネタ探しに特に苦労しました。

週次の社内勉強会 <a href="https://developer.feedforce.jp/archive/category/FFTT">FFTT</a> で『esaを支えたい技術』という発表をしました。

<a href="https://esa.io/">esa</a> をネタに Emacs Lisp と <a href="https://elm-lang.org/">Elm</a> を無理やり繋げた内容です。ちょっと強引だった。

<h2>発表の内容</h2>

<script async class="speakerdeck-embed" data-id="61df048e1aec4413bd797af156bc5f21" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>


流れとしては、↓ こんな感じです。

<ul>
<li>先月 <a href="https://github.com/masutaka/emacs-helm-esa">emacs-helm-esa</a> というツールを作ったよ</li>
<li>Elm を学んだら、Emacs Lisp と Syntax が似ていたよ</li>
<li><a href="https://github.com/masutaka/sandbox-elm-esa">esa の検索をするだけの簡単なツール</a>を作ったよ</li>
</ul>


<h2>発表の感想</h2>

付箋紙に感想を書いてくれました。 は私からのコメントです。

<ul>
<li>関数型言語について学んでみたいと思っていたので、おすすめの順序を提示してくださり、参考になりました！

<ul>
<li> 良かったです。Elm はだいぶ学びやすかったです</li>
</ul>
</li>
<li>Elm、こうして見てみると Haskell にめっちゃ似てますね！

<ul>
<li> そうなんですね</li>
</ul>
</li>
<li>発表の流れで Elm の話になると思わなかった

<ul>
<li> 強引でしたね (^^;</li>
</ul>
</li>
<li>Elm ならふだんバックエンドのコード書いている人でもモダンなフロントエンド書けるって聞いたので勉強がんばる（決意）

<ul>
<li> 刺激になってよかったです</li>
</ul>
</li>
<li>良かったです！規模が大きくなってきても同じノリで書けるのも Elm は良い

<ul>
<li> そういう感じなんですね。コンパイルが通ればだいたい動くのが楽でした</li>
</ul>
</li>
<li>Elm の HTML を作るのがすごいですね！

<ul>
<li> ですよね。<a href="https://github.com/masutaka/sandbox-elm-esa/blob/b46bb8d405030a96ab3049a8aac1450decf0adf9/src/Main.elm#L93">この辺りの div や i</a> は全部関数ですからね</li>
</ul>
</li>
<li>ネタバレに慎重になりすぎでは！？

<ul>
<li> 自分でも全く理解できません</li>
</ul>
</li>
<li>来週にはこれが Chrome 拡張になっているんですかね？

<ul>
<li> はい、次回以降の当番の方が必ず・・・！</li>
</ul>
</li>
<li>Elm おもしろそう 🏃‍♀️🚶‍♂️ emacs ってすごいんですね

<ul>
<li> とは言え、今の時代は emacs の他に優先順位の高いものがたくさんありますね 💦</li>
</ul>
</li>
<li>まさかの Elm とは！？

<ul>
<li> 考えに考えた末の Elm です...</li>
</ul>
</li>
<li>これで EC Booster Front 開発できますね

<ul>
<li> 見ててくださいよ！これからのマスタカを！！１</li>
</ul>
</li>
</ul>


<h2>所感</h2>

正直、外したかな？と思いながら発表してましたが、感想を読むと良い刺激を与えられたようで良かったです。

一方で新しい言語の説明は難しいうえ、皆さんに馴染みがない Emacs Lisp との比較をしたので、余計に分かりづらかったという...。

こうするとあまり盛り上がらないという学びを得たことと、個人的には大変満足のいく内容だったので、結果的には良かったです。

さて、次回の勉強会のネタはどうするかな...。

<div class="hatena-asin-detail"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4863542224/hatena-blog-22/"><img src="https://m.media-amazon.com/images/I/51G32HC7rSL.jpg" class="hatena-asin-detail-image" alt="基礎からわかる Elm" title="基礎からわかる Elm"></a><div class="hatena-asin-detail-info"><a href="https://www.amazon.co.jp/exec/obidos/ASIN/4863542224/hatena-blog-22/">基礎からわかる Elm</a><ul><li>作者:<a href="http://d.hatena.ne.jp/keyword/%C4%BB%B5%EF%20%CD%DB%B2%F0" class="keyword">鳥居 陽介</a></li><li>発売日: 2019/02/27</li><li>メディア: 単行本（ソフトカバー）</li></ul></div><div class="hatena-asin-detail-foot"></div></div>

こんにちは。増田（id:masutaka26）です。今回はネタ探しに特に苦労しました。週次の社内勉強会 FFTT で『esaを支えたい技術』という発表をしました。esa をネタに Emacs Lisp と Elm を無理やり繋げた内容です。ちょっと強引だった。発表の内容流れとしては、↓ こんな感じです。先月 emacs-helm-esa というツールを作ったよElm を学んだら、Emacs Lisp と Syntax が似ていたよesa の検索をするだけの簡単なツールを作ったよ発表の感想付箋紙に感想を書いてくれました。 は私からのコメントです。関数型言語について学んでみたいと思っていたので、おすすめの順序を提示してくださり、参考になりました！ 良かったです。Elm はだいぶ学びやすかったですElm、こうして見てみると Haskell にめっちゃ似てますね！ そうなんですね発表の流れで Elm の話になると思わなかった 強引でしたね (^^;Elm ならふだんバックエンドのコード書いている人でもモダンなフロントエンド書けるって聞いたので勉強がんばる（決意） 刺激になってよかったです良かったです！規模が大きくなってきても同じノリで書けるのも Elm は良い そういう感じなんですね。コンパイルが通ればだいたい動くのが楽でしたElm の HTML を作るのがすごいですね！ ですよね。この辺りの div や i は全部関数ですからねネタバレに慎重になりすぎでは！？ 自分でも全く理解できません来週にはこれが Chrome 拡張になっているんですかね？ はい、次回以降の当番の方が必ず・・・！Elm おもしろそう 🏃‍♀️🚶‍♂️ emacs ってすごいんですね とは言え、今の時代は emacs の他に優先順位の高いものがたくさんありますね 💦まさかの Elm とは！？ 考えに考えた末の Elm です...これで EC Booster Front 開発できますね 見ててくださいよ！これからのマスタカを！！１所感正直、外したかな？と思いながら発表してましたが、感想を読むと良い刺激を与えられたようで良かったです。一方で新しい言語の説明は難しいうえ、皆さんに馴染みがない Emacs Lisp との比較をしたので、余計に分かりづらかったという...。こうするとあまり盛り上がらないという学びを得たことと、個人的には大変満足のいく内容だったので、結果的には良かったです。さて、次回の勉強会のネタはどうするかな...。基礎からわかる Elm作者:鳥居 陽介発売日: 2019/02/27メディア: 単行本（ソフトカバー）

esa をネタに Emacs Lisp と Elm を無理やり繋げた発表をした

こんにちは <a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> です。

少し前に、Heroku の worker Dyno 上で動く、Chrome のクローラで IP アドレスを固定化出来ないか調査しました。

実装は見送られましたが、想定よりも難しく調査に時間がかかったので、この記事に残しておきます。

方法だけ知りたい方は、下の方にある「手順」をご覧ください。

<ul class="table-of-contents">
 <li><a href="#Heroku-Add-on-を比較する">Heroku Add-on を比較する</a><ul>
 <li><a href="#開発組織">開発組織</a></li>
 <li><a href="#実装">実装</a></li>
 <li><a href="#プラン">プラン</a></li>
 <li><a href="#CLI-のインストール">CLI のインストール</a></li>
 <li><a href="#Heroku-Buildpack">Heroku Buildpack</a></li>
 </ul>
 </li>
 <li><a href="#コラム-固定-IP-アドレスへの私見">[コラム] 固定 IP アドレスへの私見</a></li>
 <li><a href="#Chrome-のクローラで-IP-アドレスを固定化する">Chrome のクローラで IP アドレスを固定化する</a><ul>
 <li><a href="#試行錯誤の日々">試行錯誤の日々</a></li>
 <li><a href="#ついに成功">ついに成功</a></li>
 <li><a href="#手順">手順</a></li>
 </ul>
 </li>
 <li><a href="#QuotaGuard-Static-の注意事項">QuotaGuard Static の注意事項</a></li>
 <li><a href="#まとめ">まとめ</a></li>
</ul>

<h2 id="Heroku-Add-on-を比較する">Heroku Add-on を比較する</h2>

今回は <a href="https://elements.heroku.com/addons/proximo">Proximo</a> と <a href="https://elements.heroku.com/addons/quotaguardstatic">QuotaGuard Static</a> を検討し、最終的に QuotaGuard Static を採用しました。

💡 他に <a href="https://elements.heroku.com/addons/fixie">Fixie</a>, <a href="https://elements.heroku.com/addons/fixie-socks">Fixie Socks</a>, <a href="https://elements.heroku.com/addons/guru301">Guru301</a> などがあるようです。

以下、その理由です。

<h3 id="開発組織">開発組織</h3>

Proximo は <a href="https://github.com/pirateradio">https://github.com/pirateradio</a> を見た感じ <a href="https://github.com/ddollar">@ddollar</a> の個人開発のようです。この方は <a href="https://github.com/ddollar/foreman">foreman</a> などを作っており、多分すごい人です。

QuotaGuard Static は <a href="https://www.quotaguard.com/">https://www.quotaguard.com/</a> によると <a href="https://www.alpineshark.com/">Alpine Shark, LLC</a> のようです。会社のほうがちょっとだけ安心できます。

<h3 id="実装">実装</h3>

Proximo は 1 つのようですが、QuotaGuard Static は 2 つの Proxy サーバで冗長化されているようです。Proxy サーバが落ちる確率は低いかもしれませんが、冗長化されているに越したことはありません。

🔗 <a href="https://devcenter.heroku.com/articles/proximo#provisioning-the-proximo-add-on">https://devcenter.heroku.com/articles/proximo#provisioning-the-proximo-add-on</a>

<pre class="code" data-lang="" data-unlink>$ heroku addons:create proximo:development
Adding proximo to sharp-mountain-4005... done, v18 ($5/mo)
Your static IP address is 10.9.8.7</pre>


🔗 <a href="https://devcenter.heroku.com/articles/quotaguardstatic#provisioning-the-add-on">https://devcenter.heroku.com/articles/quotaguardstatic#provisioning-the-add-on</a>

<pre class="code" data-lang="" data-unlink>$ heroku addons:create quotaguardstatic:starter
-----&gt; Adding quotaguardstatic:starter to sharp-mountain-4005... done, v18 (free)
-----&gt; Your static IPs are [10.11.12.13, 14.15.16.17]</pre>


<h3 id="プラン">プラン</h3>

QuotaGuard Static は無料プランがあるので始めやすいです。Proximo のプランは <code>$5/mo</code> からです。

ちなみにどちらも <code>PROXIMO_MASK</code> や <code>QUOTAGUARDSTATIC_MASK</code> という環境変数を設定すると、一部のレンジの送信だけこれらのサービス経由にすることができ、料金を節約できます。

💡 正確に書くと <code>QUOTAGUARDSTATIC_MASK</code> は後述する qgsocksify 用の環境変数です。

<h3 id="CLI-のインストール">CLI のインストール</h3>

どちらも CLI が提供されており、必要に応じてインストールします。

Proximo はインストール元が http なのがイマイチでした。https に変えてもアクセス不可です。

<pre class="code" data-lang="" data-unlink>$ curl http://downloads.proximo.io/proximo-stacklet.tgz | tar xz</pre>


QuotaGuard Static は普通に https でインストール出来ます。

<pre class="code" data-lang="" data-unlink>$ curl https://s3.amazonaws.com/quotaguard/qgtunnel-latest.tar.gz | tar xz
$ curl https://s3.amazonaws.com/quotaguard/quotaguard-socksify-latest.tar.gz | tar xz</pre>


<h3 id="Heroku-Buildpack">Heroku Buildpack</h3>

今回の調査の過程で Heroku Buildpack を作りました。バイナリファイルをリポジトリに commit せずに済みます。よかったらどうぞ。

<ul>
<li><a href="https://github.com/masutaka/heroku-buildpack-proximo">https://github.com/masutaka/heroku-buildpack-proximo</a></li>
<li><a href="https://github.com/masutaka/heroku-buildpack-qgtunnel">https://github.com/masutaka/heroku-buildpack-qgtunnel</a></li>
<li><a href="https://github.com/masutaka/heroku-buildpack-qgsocksify">https://github.com/masutaka/heroku-buildpack-qgsocksify</a></li>
</ul>


<h2 id="コラム-固定-IP-アドレスへの私見">[コラム] 固定 IP アドレスへの私見</h2>

IP アドレスを固定化したいのは、どんなケースでしょうか。

多くはセキュリティ要件だと思いますが、私はあまり賛同できないです。

そもそも当該 IP アドレスは認証されておらず、所有者が変わることがあります。仕組み上それに気づくことは難しいため、逆にセキュリティリスクを増やすことになります。そういう意味では電話番号とよく似ています。

サービスのスケールの観点からもデメリットがあります。例えば Heroku から AWS に引っ越す時、固定 IP アドレスは変わってしまうでしょう。顧客との調整が必要ですし、間に開発会社が入っていると、より時間がかかります。

<h2 id="Chrome-のクローラで-IP-アドレスを固定化する">Chrome のクローラで IP アドレスを固定化する</h2>

今回のケースでは Heroku の worker Dyno 上に <a href="https://rubygems.org/gems/sidekiq">sidekiq</a> が起動しており、<a href="https://rubygems.org/gems/selenium-webdriver">selenium-webdriver</a> 経由で Chrome が子プロセスとして起動し、クロールします。

<pre><code>sidekiq
└ Chrome
 ↓
 クロール先
</code></pre>

<h3 id="試行錯誤の日々">試行錯誤の日々</h3>

当初は sidekiq 自体に qgtunnel や qgsocksify をラップしましたが、うまくいきませんでした。よく考えたら納得です。

Chrome に <code>--proxy-server=http://&lt;USERNAME&gt;:&lt;PASSWORD&gt;@&lt;HOSTNAME&gt;:&lt;PORT&gt;</code> や <code>--proxy-auth=&lt;USERNAME&gt;:&lt;PASSWORD&gt;</code> を指定してもダメ。

どうやら少なくとも Chrome 73 ではセキュリティ上の理由から、コマンドラインオプションから認証情報を設定できないようです。認証なしプロクシなら大丈夫ですが、QuotaGuard Static は商用サービスなので認証は必須です。

<h3 id="ついに成功">ついに成功</h3>

ダメ元で QuotaGuard Static のサポートに聞いたら、方法を知っており、無事クロール先にアクセスすることが出来ました。

👇 Dyno とクロール先を SOCKS5 トンネルで繋ぎ、それ経由でアクセスします。

<pre><code>sidekiq
└ Chrome (4443 port)
 ↓ (SOCKS5 tunnel)
 QuotaGuard Static
 ↓ (SOCKS5 tunnel)
 クロール先 (443 port)
</code></pre>

TCP アクセスならなんでも IP アドレスを固定化出来そうです。

<h3 id="手順">手順</h3>

(1) 当該 Heroku App に QuotaGuard Static Add-on をインストールします。

(2) qgtunnel CLI もインストールします。前述の heroku-buildpack-qgtunnel を使うとお手軽です。

<pre class="code" data-lang="" data-unlink>$ curl https://s3.amazonaws.com/quotaguard/qgtunnel-latest.tar.gz | tar xz</pre>


(3) Heroku のダッシュボードから、QuotaGuard Static のダッシュボードに進み、<code>Settings</code> → <code>Setup</code> とクリックします。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20190425/20190425193848.png" alt="f:id:masutaka26:20190425193848p:plain" title="" class="hatena-fotolife" itemprop="image">

(4) さらに <code>Tunnel</code> → <code>Create Tunnel</code> とクリックします。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20190425/20190425192905.png" alt="f:id:masutaka26:20190425192905p:plain" title="" class="hatena-fotolife" itemprop="image">

(5) <code>Remote Destination</code> にクロール先を、<code>Local Port</code> は 4443、<code>Transparent</code> は true に設定します。<code>Encrypted</code> は設定しません。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20190425/20190425193342.png" alt="f:id:masutaka26:20190425193342p:plain" title="" class="hatena-fotolife" itemprop="image">

(6) トンネルが出来ました。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20190425/20190425193614.png" alt="f:id:masutaka26:20190425193614p:plain" title="" class="hatena-fotolife" itemprop="image">

<ul>
<li>127.0.0.1:4443 へのアクセスは destination.example.com:443 へのトンネルになります</li>
<li><code>Transparent</code> を有効したことにより、destination.example.com の DNS が 127.0.0.1 に上書きされました。destination.example.com:4443 へのアクセスは destination.example.com:443 と等価になります</li>
<li>すでに HTTPS を使っているため、<code>Encrypted</code> は必要ありません</li>
</ul>


(7) selenium-webdriver に与える Chrome のバイナリを qgtunnel でラッピングします。今回は以下のようなシェルスクリプト bin/google-chrome-qgtunnel を作り、selenium-webdriver に指定しました。

<pre class="code lang-sh" data-lang="sh" data-unlink>#!/bin/sh -eu

exec bin/qgtunnel &quot;$GOOGLE_CHROME_SHIM&quot; &quot;$@&quot;
</pre>


💡 <a href="https://github.com/heroku/heroku-buildpack-google-chrome">heroku-buildpack-google-chrome</a> と <a href="https://github.com/heroku/heroku-buildpack-chromedriver.git">heroku-buildpack-chromedriver</a> を使っています。環境変数 <code>GOOGLE_CHROME_SHIM</code> は <code>/app/.apt/usr/bin/google-chrome</code> です。

(8) 左側の <code>Outbound</code> をクリックし、SOCKS5 url を Heroku の環境変数 <code>QUOTAGUARDSTATIC_URL</code> に上書きします。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20190425/20190425191501.png" alt="f:id:masutaka26:20190425191501p:plain" title="" class="hatena-fotolife" itemprop="image">

(9) 左側の <code>Tunnel</code> から <code>Download Configuration</code> をクリックし、<code>.qgtunnel</code> ファイルをリポジトリに commit します。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20190425/20190425203447.png" alt="f:id:masutaka26:20190425203447p:plain" title="" class="hatena-fotolife" itemprop="image">

(10) 以上の設定により、destination.example.com:4443 へのアクセスが destination.example.com:443 に変換され、且つ IP アドレスも固定されます。

なにかトラブルがあったら Heroku の環境変数 <code>QGTUNNEL_DEBUG</code> に true をセットして、ログを確認すると良いと思います。

<h2 id="QuotaGuard-Static-の注意事項">QuotaGuard Static の注意事項</h2>

app.json の addons に <code>quotaguardstatic</code> を追加して、Review App を作ると Micro plan <code>$19/mo</code> で作られてしまいます。<code>quotaguardstatic:starter</code> とかにしても同じです。

QuotaGuard Static のサポートに聞いたところ、Heroku のアカウント単位で設定を変える必要があるそう。問い合わせが必要です。

<h2 id="まとめ">まとめ</h2>

Heroku の worker Dyno 上で動く、Chrome のクローラで IP アドレスを固定化しました。

固定 IP アドレス対応は出来るだけ避けたほうが良いと思いますが、どうしても必要な時にこの記事が参考になれば幸いです。

こんにちは id:masutaka26 です。少し前に、Heroku の worker Dyno 上で動く、Chrome のクローラで IP アドレスを固定化出来ないか調査しました。実装は見送られましたが、想定よりも難しく調査に時間がかかったので、この記事に残しておきます。方法だけ知りたい方は、下の方にある「手順」をご覧ください。Heroku Add-on を比較する開発組織実装プランCLI のインストールHeroku Buildpack[コラム] 固定 IP アドレスへの私見Chrome のクローラで IP アドレスを固定化する試行錯誤の日々ついに成功手順QuotaGuard Static の注意事項まとめHeroku Add-on を比較する今回は Proximo と QuotaGuard Static を検討し、最終的に QuotaGuard Static を採用しました。💡 他に Fixie, Fixie Socks, Guru301 などがあるようです。以下、その理由です。開発組織Proximo は https://github.com/pirateradio を見た感じ @ddollar の個人開発のようです。この方は foreman などを作っており、多分すごい人です。QuotaGuard Static は https://www.quotaguard.com/ によると Alpine Shark, LLC のようです。会社のほうがちょっとだけ安心できます。実装Proximo は 1 つのようですが、QuotaGuard Static は 2 つの Proxy サーバで冗長化されているようです。Proxy サーバが落ちる確率は低いかもしれませんが、冗長化されているに越したことはありません。🔗 https://devcenter.heroku.com/articles/proximo#provisioning-the-proximo-add-on$ heroku addons:create proximo:developmentAdding proximo to sharp-mountain-4005... done, v18 ($5/mo)Your static IP address is 10.9.8.7🔗 https://devcenter.heroku.com/articles/quotaguardstatic#provisioning-the-add-on$ heroku addons:create quotaguardstatic:starter-----> Adding quotaguardstatic:starter to sharp-mountain-4005... done, v18 (free)-----> Your static IPs are [10.11.12.13, 14.15.16.17]プランQuotaGuard Static は無料プランがあるので始めやすいです。Proximo のプランは $5/mo からです。ちなみにどちらも PROXIMO_MASK や QUOTAGUARDSTATIC_MASK という環境変数を設定すると、一部のレンジの送信だけこれらのサービス経由にすることができ、料金を節約できます。💡 正確に書くと QUOTAGUARDSTATIC_MASK は後述する qgsocksify 用の環境変数です。CLI のインストールどちらも CLI が提供されており、必要に応じてインストールします。Proximo はインストール元が http なのがイマイチでした。https に変えてもアクセス不可です。$ curl http://downloads.proximo.io/proximo-stacklet.tgz | tar xzQuotaGuard Static は普通に https でインストール出来ます。$ curl https://s3.amazonaws.com/quotaguard/qgtunnel-latest.tar.gz | tar xz$ curl https://s3.amazonaws.com/quotaguard/quotaguard-socksify-latest.tar.gz | tar xzHeroku Buildpack今回の調査の過程で Heroku Buildpack を作りました。バイナリファイルをリポジトリに commit せずに済みます。よかったらどうぞ。https://github.com/masutaka/heroku-buildpack-proximohttps://github.com/masutaka/heroku-buildpack-qgtunnelhttps://github.com/masutaka/heroku-buildpack-qgsocksify[コラム] 固定 IP アドレスへの私見IP アドレスを固定化したいのは、どんなケースでしょうか。多くはセキュリティ要件だと思いますが、私はあまり賛同できないです。そもそも当該 IP アドレスは認証されておらず、所有者が変わることがあります。仕組み上それに気づくことは難しいため、逆にセキュリティリスクを増やすことになります。そういう意味では電話番号とよく似ています。サービスのスケールの観点からもデメリットがあります。例えば Heroku から AWS に引っ越す時、固定 IP アドレスは変わってしまうでしょう。顧客との調整が必要ですし、間に開発会社が入っていると、より時間がかかります。Chrome のクローラで IP アドレスを固定化する今回のケースでは Heroku の worker Dyno 上に sidekiq が起動しており、selenium-webdriver 経由で Chrome が子プロセスとして起動し、クロールします。sidekiq└ Chrome ↓ クロール先試行錯誤の日々当初は sidekiq 自体に qgtunnel や qgsocksify をラップしましたが、うまくいきませんでした。よく考えたら納得です。Chrome に --proxy-server=http://<USERNAME>:<PASSWORD>@<HOSTNAME>:<PORT> や --proxy-auth=<USERNAME>:<PASSWORD> を指定してもダメ。どうやら少なくとも Chrome 73 ではセキュリティ上の理由から、コマンドラインオプションから認証情報を設定できないようです。認証なしプロクシなら大丈夫ですが、QuotaGuard Static は商用サービスなので認証は必須です。ついに成功ダメ元で QuotaGuard Static のサポートに聞いたら、方法を知っており、無事クロール先にアクセスすることが出来ました。👇 Dyno とクロール先を SOCKS5 トンネルで繋ぎ、それ経由でアクセスします。sidekiq└ Chrome (4443 port) ↓ (SOCKS5 tunnel) QuotaGuard Static ↓ (SOCKS5 tunnel) クロール先 (443 port)TCP アクセスならなんでも IP アドレスを固定化出来そうです。手順(1) 当該 Heroku App に QuotaGuard Static Add-on をインストールします。(2) qgtunnel CLI もインストールします。前述の heroku-buildpack-qgtunnel を使うとお手軽です。$ curl https://s3.amazonaws.com/quotaguard/qgtunnel-latest.tar.gz | tar xz(3) Heroku のダッシュボードから、QuotaGuard Static のダッシュボードに進み、Settings → Setup とクリックします。(4) さらに Tunnel → Create Tunnel とクリックします。(5) Remote Destination にクロール先を、Local Port は 4443、Transparent は true に設定します。Encrypted は設定しません。(6) トンネルが出来ました。127.0.0.1:4443 へのアクセスは destination.example.com:443 へのトンネルになりますTransparent を有効したことにより、destination.example.com の DNS が 127.0.0.1 に上書きされました。destination.example.com:4443 へのアクセスは destination.example.com:443 と等価になりますすでに HTTPS を使っているため、Encrypted は必要ありません(7) selenium-webdriver に与える Chrome のバイナリを qgtunnel でラッピングします。今回は以下のようなシェルスクリプト bin/google-chrome-qgtunnel を作り、selenium-webdriver に指定しました。#!/bin/sh -euexec bin/qgtunnel "$GOOGLE_CHROME_SHIM" "$@"💡 heroku-buildpack-google-chrome と heroku-buildpack-chromedriver を使っています。環境変数 GOOGLE_CHROME_SHIM は /app/.apt/usr/bin/google-chrome です。(8) 左側の Outbound をクリックし、SOCKS5 url を Heroku の環境変数 QUOTAGUARDSTATIC_URL に上書きします。(9) 左側の Tunnel から Download Configuration をクリックし、.qgtunnel ファイルをリポジトリに commit します。(10) 以上の設定により、destination.example.com:4443 へのアクセスが destination.example.com:443 に変換され、且つ IP アドレスも固定されます。なにかトラブルがあったら Heroku の環境変数 QGTUNNEL_DEBUG に true をセットして、ログを確認すると良いと思います。QuotaGuard Static の注意事項app.json の addons に quotaguardstatic を追加して、Review App を作ると Micro plan $19/mo で作られてしまいます。quotaguardstatic:starter とかにしても同じです。QuotaGuard Static のサポートに聞いたところ、Heroku のアカウント単位で設定を変える必要があるそう。問い合わせが必要です。まとめHeroku の worker Dyno 上で動く、Chrome のクローラで IP アドレスを固定化しました。固定 IP アドレス対応は出来るだけ避けたほうが良いと思いますが、どうしても必要な時にこの記事が参考になれば幸いです。

Heroku で Chrome を使ったクローラの IP アドレスを固定する

こんにちは id:masutaka26 です。この記事は Heroku Advent Calendar 2018 の 12 日目の記事です。qiita.com昨日は @takuchalle さんの『Heroku で wkhtmltoimage を使う方法』でした。似たツールの webkit2png は使ったことがあります。webkit2png が動作するのは macOS だけですが、wkhtmltoimage は Windows と Linux でも動作するのですね。へぇー。先月、Heroku の Preboot 機能を調べる機会がありました。Web 上の日本語記事は Preboot が GA になった 2014 年頃の情報が多く、若干情報が古かったため、2018 年時点の最新の情報をまとめます。Preboot 機能とは何かどのように有効にするのか使用する Procfileデプロイによる heroku ps の変化デプロイ時の挙動デプロイ時のログ再起動時の挙動再起動時のログWeb dyno 1 台目Web dyno 2 台目注意事項まとめPreboot 機能とは何かProduction Check > Dyno redundancy に書いてあるとおり、Heroku では冗長性確保のため、本番環境の Web Dyno は 2 台以上が奨励されています。Running at least 2 web dynos for any mission-critical app increases the probability that the app will remain available during a catastrophic event. Multiple dynos are also more likely to run on different physical infrastructure (for example, separate AWS Availability Zones), further increasing redundancy.ただし、それだけだとデプロイや 1 日 1 回の自動再起動で、処理の遅延（H27 - Client Request Interrupted）や H28 - Client Connection Idle が発生することがあります。以下のグラフは Dyno Restart のタイミングで H27 と H28 Error が発生している様子です。このグラフはダッシュボードの Metrics から確認できます。これを回避できるのが Preboot 機能です。どのように有効にするのかHeroku CLI で有効にできます。$ heroku features:enable preboot -a YOUR_APP_NAME有効になりました。簡単ですね。$ heroku features:info preboot -a YOUR_APP_NAME=== prebootDescription: Provide seamless web dyno deploys [general]Docs:        https://devcenter.heroku.com/articles/prebootEnabled:     true使用する Procfile今回はこの Procfile を使います。release: bin/rails db:migrate db:seed# Web appweb: bin/rails s -p $PORT -e $RAILS_ENVworker: PROCESS_TYPE=worker bundle exec sidekiq -C config/sidekiq.yml# Ad appad_worker: PROCESS_TYPE=ad_worker bundle exec sidekiq -C config/sidekiq.ymlweb, worker, ad_worker という 3 つの process type を定義しています。今回注目する process type は web だけです。1 行目で release も定義しているため、デプロイ時には One-Off Dyno1 で release 処理をしたあと、生成した Slug が Dyno に展開されていきます。デプロイによる heroku ps の変化それでは $ watch 'heroku ps -a YOUR_APP_NAME' しつつ、デプロイの様子を観察していきましょう。macOS では watch コマンドは $ brew install watch 等でインストール出来ます。Web Dyno 1 台の場合、release Dyno の実行が終わると、web.1 Dyno のステータスが up → starting → up と変化します。starting 中にリクエストがあると、クライアントは待たされ、前述の H27 や H28 Error が発生します。Web Dyno 1 台でデプロイした様子Web Dyno 2 台かつ Preboot 無効でも、基本的に同じです。2 台同時に up → starting → up と変化します。Web Dyno 2 台かつ Preboot 無効でデプロイした様子Web Dyno 2 台かつ Preboot を有効にすると、期待した通り、1 台ずつ up → starting → up になりませんでした・・・！あれ？Web Dyno 2 台かつ Preboot 有効でデプロイした様子Logs will show new dynos starting soon after the slug compile is finished. The output of heroku ps will immediately show the state (for example, starting or up) of the new dynos. Old dynos are still running but won’t appear in heroku ps.Preboot のドキュメントによると、heroku ps では確認できないようです。ただしログでは確認できるそう。デプロイ時の挙動Approximately 3 minutes after the deploy completes (or 2 minutes after your app’s boot timeout limit, which defaults to 1 minute), HTTP requests will start routing to the new dynos and simultaneously stop routing to the old dynos.遅くともデプロイ完了から約 3 分後、もしくはアプリケーションの起動タイムアウトリミット 2 分（デフォルトは 1 分）後、HTTP リクエストは新 Dyno に Routing されるそうです。Shortly after the new dynos are fully live and serving user requests, the old dynos will be shut down. You’ll see them shut down in the logs as usual.新 Dyno が完全に起動し、ユーザリクエストを処理するとすぐに、旧 Dyno はシャットダウンされるようです。これもログで確認可能とのこと。では実際にログを見てみましょう。デプロイ時のログgit push 後まもなく、Web dyno の状態が up から starting に変わりました。Nov 28 14:58:51 heroku[web] notice RestartingNov 28 14:58:51 heroku[web] notice State changed from up to startingNov 28 14:58:51 heroku[web] notice RestartingNov 28 14:58:51 heroku[web] notice State changed from up to starting新 Web dyno 2 台で Puma (Web server) がそれぞれ起動を開始しました。Nov 28 14:59:17 heroku[web] notice Starting process with command `bin/rails s -p 24256 -e production`Nov 28 14:59:19 heroku[web] notice Starting process with command `bin/rails s -p 15417 -e production`Nov 28 14:59:21 app[web] info [heroku-exec] StartingNov 28 14:59:22 app[web] info [heroku-exec] StartingNov 28 14:59:31 app[web] info => Booting PumaNov 28 14:59:31 app[web] info => Rails 5.2.1 application starting in productionNov 28 14:59:31 app[web] info => Run `rails server -h` for more startup optionsNov 28 14:59:32 app[web] info => Booting PumaNov 28 14:59:32 app[web] info => Rails 5.2.1 application starting in productionNov 28 14:59:32 app[web] info => Run `rails server -h` for more startup optionsWeb dyno の状態が starting から up に変わりました。まだ Puma は起動しきっていません。Nov 28 14:59:33 heroku[web] notice State changed from starting to upNov 28 14:59:34 heroku[web] notice State changed from starting to up新 Web dyno 1 台で Puma が起動しきりました。問題はありませんが、手元で起動するよりずいぶん遅い気がします。Nov 28 15:02:03 app[web] info Puma starting in single mode...Nov 28 15:02:03 app[web] info * Version 3.12.0 (ruby 2.5.3-p105), codename: Llamas in PajamasNov 28 15:02:03 app[web] info * Min threads: 11, max threads: 11Nov 28 15:02:03 app[web] info * Environment: productionNov 28 15:02:03 app[web] info * Listening on tcp://0.0.0.0:24256Nov 28 15:02:03 app[web] info Use Ctrl-C to stop旧 Web dyno 1 台で Puma が終了しました。前述の意訳では約 3 分とあるため合っています。Nov 28 15:02:19 heroku[web] notice Stopping all processes with SIGTERMNov 28 15:02:19 app[web] info Gracefully stopping, waiting for requests to finishNov 28 15:02:19 app[web] info === puma shutdown: 2018-11-28 06:02:19 +0000 ===Nov 28 15:02:19 app[web] info Goodbye!Nov 28 15:02:19 app[web] info ExitingNov 28 15:02:19 heroku[web] notice Process exited with status 143もうひとつの旧 Web dyno 1 台で Puma が終了しました。これも意訳のとおりです。Nov 28 15:03:25 heroku[web] notice Stopping all processes with SIGTERMNov 28 15:03:25 app[web] info Gracefully stopping, waiting for requests to finishNov 28 15:03:25 app[web] info === puma shutdown: 2018-11-28 06:03:25 +0000 ===Nov 28 15:03:25 app[web] info Goodbye!Nov 28 15:03:25 app[web] info ExitingNov 28 15:03:25 heroku[web] notice Process exited with status 143もうひとつの新 Web dyno 1 台で Puma が起動しきりました。Booting Puma からずいぶんと時間がかかりました。Nov 28 15:05:08 app[web] info Puma starting in single mode...Nov 28 15:05:08 app[web] info * Version 3.12.0 (ruby 2.5.3-p105), codename: Llamas in PajamasNov 28 15:05:08 app[web] info * Min threads: 11, max threads: 11Nov 28 15:05:08 app[web] info * Environment: productionNov 28 15:05:08 app[web] info * Listening on tcp://0.0.0.0:15417Nov 28 15:05:08 app[web] info Use Ctrl-C to stopPuma の起動に時間がかかるのは謎ですが、Preboot のドキュメントと相違ないと理解しました。再起動時の挙動再起動時の挙動も確認します。Heroku ではアプリケーションの健全性を維持するため、Dyno は 1 日に 1 回、自動的に再起動します。Dyno は差し替えられるため、ローカルファイルシステムの変更はすべて破棄されます。The new dynos will start receiving requests as soon as it binds to its assigned port. At this point, both the old and new dynos are receiving requests.新 Dyno は割り当てられたポートにバインドされると、すぐにリクエストを受信し始めます。この時点で、新旧の Dyno がリクエストを受信するそう。Approximately 4 to 6 minutes after the restart is invoked, the old dynos will be shut down. You’ll see them shut down in the logs as usual.再起動が行われてから、約 4~6 分後に旧 Dyno がシャットダウンされるようです。これもログで確認可能とのこと。Preboot が GA になった 2014 年頃は、まだ 1 日 1 回の再起動には対応していないようでした。現在は対応しているようです。再起動時のログ結論から書くと、1 台目が再起動し終えてから 2 台目が再起動していました。再起動においても、ドキュメントの通りに Preboot が機能しているようです。Web dyno 1 台目Web dyno 1 台の状態が up から starting に変わりました。Nov 30 11:41:22 heroku[web] notice CyclingNov 30 11:41:22 heroku[web] notice State changed from up to starting新 Web dyno 1 台で Puma が起動を開始しました。Nov 30 11:41:42 heroku[web] notice Starting process with command `bin/rails s -p 32434 -e production`Nov 30 11:41:44 app[web] info [heroku-exec] StartingNov 30 11:41:50 app[web] info => Booting PumaNov 30 11:41:50 app[web] info => Rails 5.2.1.1 application starting in productionNov 30 11:41:50 app[web] info => Run `rails server -h` for more startup optionsWeb dyno 1 台の状態が starting から up に変わりました。まだ Puma は起動しきっていません。Nov 30 11:41:51 heroku[web] notice State changed from starting to up新 Web dyno 1 台で Puma が起動しきりました。相変わらず時間がかかります。Nov 30 11:45:45 app[web] info Puma starting in single mode...Nov 30 11:45:45 app[web] info * Version 3.12.0 (ruby 2.5.3-p105), codename: Llamas in PajamasNov 30 11:45:45 app[web] info * Min threads: 11, max threads: 11Nov 30 11:45:45 app[web] info * Environment: productionNov 30 11:45:45 app[web] info * Listening on tcp://0.0.0.0:32434Nov 30 11:45:45 app[web] info Use Ctrl-C to stop旧 Web dyno 1 台で Puma が終了しました。前述の意訳では約 4~6 分後とありましたが、間を置かずに終了しました。Nov 30 11:45:55 heroku[web] notice Stopping all processes with SIGTERMNov 30 11:45:56 app[web] info Gracefully stopping, waiting for requests to finishNov 30 11:45:56 app[web] info === puma shutdown: 2018-11-30 02:45:55 +0000 ===Nov 30 11:45:56 app[web] info Goodbye!Nov 30 11:45:56 app[web] info ExitingNov 30 11:45:56 heroku[web] notice Process exited with status 143Web dyno 2 台目もうひとつの Web dyno 1 台の状態が up から starting に変わりました。14 分くらい差があります。最大 216 分のランダムな差があるようなので、記載通りです。Nov 30 12:00:41 heroku[web] notice CyclingNov 30 12:00:41 heroku[web] notice State changed from up to starting新 Web dyno 1 台で Puma が起動を開始しました。Nov 30 12:00:59 heroku[web] notice Starting process with command `bin/rails s -p 16965 -e production`Nov 30 12:01:01 app[web] info [heroku-exec] StartingNov 30 12:01:08 app[web] info => Booting PumaNov 30 12:01:08 app[web] info => Rails 5.2.1.1 application starting in productionNov 30 12:01:08 app[web] info => Run `rails server -h` for more startup optionsWeb dyno 1 台の状態が starting から up に変わりました。まだ Puma は起動しきっていません。Nov 30 12:01:10 heroku[web] notice State changed from starting to up新 Web dyno 1 台で Puma が起動しきりました。今回は時間がかかりませんでした。Nov 30 12:01:15 app[web] info Puma starting in single mode...Nov 30 12:01:15 app[web] info * Version 3.12.0 (ruby 2.5.3-p105), codename: Llamas in PajamasNov 30 12:01:15 app[web] info * Min threads: 11, max threads: 11Nov 30 12:01:15 app[web] info * Environment: productionNov 30 12:01:15 app[web] info * Listening on tcp://0.0.0.0:16965Nov 30 12:01:15 app[web] info Use Ctrl-C to stop旧 Web dyno 1 台で Puma が終了しました。今度は時間がかかりました。前述の意訳では約 4~6 分後とあるため合っています。Nov 30 12:05:14 heroku[web] notice Stopping all processes with SIGTERMNov 30 12:05:14 app[web] info Gracefully stopping, waiting for requests to finishNov 30 12:05:14 app[web] info === puma shutdown: 2018-11-30 03:05:14 +0000 ===Nov 30 12:05:14 app[web] info Goodbye!Nov 30 12:05:14 app[web] info ExitingNov 30 12:05:14 heroku[web] notice Process exited with status 143注意事項Preboot を有効にしてデプロイすると、無効時よりも時間をかけて Dyno が差し替わります。全ての Dyno に反映されるまで数分かかることもあるようです。この点はチームで把握しておく必要があります。最大 3 分間、新旧の Dyno が重複するため、Add-on の同時接続数の制限に達する可能性があります。Heroku Postgres の場合は pgbouncer buildpack を使うことが奨励されています。新旧の Dyno が混在することにより、一度のデプロイで DB schema とアプリケーションコードを変更すると、不具合が発生する可能性があります。Preboot 機能を一旦無効にすることを勧めています。でも、Procfile に release process type を定義していれば同じなので、個人的には気にならないですね。Preboot 機能を使うためには、Dyno type が Standard-1X 以上である必要があります。Dyno type が Free と Hobby では Preboot を有効に出来ません。Preboot が適用されるのは Web Dyno だけです。自分で定義した worker Dyno 等は対象外です。まとめHeroku の Preboot 機能を深掘りし、有効にする必要性を理解しました。Web Dyno を 2 台以上にしたら Preboot を有効にすると良さそう前述の「注意事項」には留意したほうが良いしかし、こんなに長い記事になるとは...。明日の heroku Advent Calendar 2018 はまたまた id:masutaka26 です。Bitbar の便利な Heroku plugin を紹介してくれるみたいです。お楽しみに。このような使い捨ての Dyno を One-Off Dyno と呼びます。heroku run で使われる Dyno もそうです。↩

Heroku の Preboot 機能を深掘りした

ｺﾞﾎｺﾞﾎ&hellip;この記事は feedforce Advent Calendar 2018 の 7 日目の記事です。健康的な記事を書くつもりが、月曜日から水曜日まで寝込んでいました（白目）。
6 日目はふねさんの『リモート勤務が出来るようになったので煮込みがはかどる話 』でした。
煮込み料理( ・∀・)ｲｲ!!ですね。無職時代に、カレーを作りながら採用面接向けの課題をやっていたことを思い出しました。(ToT)
そんな私の記事は [2016-12-14-1] と [2017-12-19-1] に引き続き、またまた健康・生活に関する記事です。40 を超えると、健康の話しかしませんよね？
さっそく中間報告 トレーナー曰く「今のところ順調に筋肉量が増え、体脂肪率が減っている」とのこと。さすがに CM みたいに極端には結果は出ないですね。初期の体脂肪率が 31.4% とかはおかしいので機械の故障でしょう&hellip;。
※ ジムで InBody を使っての計測
自宅では 2014 年から Withings の体重計で毎朝測っています。
※ Withings Smart Body Analyzer での計測
③の傾斜角が今回の成果になります。2kg 程度ですが、私の身長は 161cm ほどなので、これでも体つきに変化が出ています。筋肉量を増やしつつ、体重が減っていますからね。
①は朝食を MCT オイル＆バター＆コーヒーにしていた頃です。筋トレはしていません。
②は一週間でこの変化です。一週間熱が出続けて寝込んだらこうなりました。出社したら痩せたと言われました。
どちらも見事にリバウンドしていますね&hellip;。
なぜまたジムに通い始めたか 週に 2〜3 回、晩酌する習慣がついてしまい、人生最大の体重と体脂肪率になったからです。
実は 2 年前まで近所のジムに通っていました。あまり合わずに 3 ヶ月ほどで辞めた後、近所のエニタイムフィットネス に行こうと思い 2 年が経ってしまいました。
これ以上延ばすのはまずいと思い、申し込んだのが [2018-06-30-1] というわけです。
ジムに行く頻度と内容 週 3 回目標で、最低週 2 回で続けています。もう 6 ヶ月目です。雨の日も風の日も台風の日も通います。何も考えずに通うことが重要です。「一度決めたことを忠実に繰り返してしまう」という私の性格に大変助かっています。

ｺﾞﾎｺﾞﾎ…この記事は feedforce Advent Calendar 2018 の 7 日目の記事です。健康的な記事を書くつもりが、月曜日から水曜日まで寝込んでいました（白目）。6 日目はふねさんの『リモート勤務が出来るようになったので煮込みがはかどる話 』でした。煮込み料理( ・∀・)ｲｲ!!ですね。無職時代に、カレーを作りながら採用面接向けの課題をやっていたことを思い出しました。(ToT)そんな私の記事は [2016-12-14-1] と [2017-12-19-1] に引き続き、またまた健康・生活に関する記事です。40 を超えると、健康の話しかしませんよね？さっそく中間報告 トレーナー曰く「今のところ順調に筋肉量が増え、体脂肪率が減っている」とのこと。さすがに CM みたいに極端には結果は出ないですね。初期の体脂肪率が 31.4% とかはおかしいので機械の故障でしょう…。※ ジムで InBody を使っての計測自宅では 2014 年から Withings の体重計で毎朝測っています。※ Withings Smart Body Analyzer での計測③の傾斜角が今回の成果になります。2kg 程度ですが、私の身長は 161cm ほどなので、これでも体つきに変化が出ています。筋肉量を増やしつつ、体重が減っていますからね。①は朝食を MCT オイル＆バター＆コーヒーにしていた頃です。筋トレはしていません。②は一週間でこの変化です。一週間熱が出続けて寝込んだらこうなりました。出社したら痩せたと言われました。どちらも見事にリバウンドしていますね…。なぜまたジムに通い始めたか 週に 2〜3 回、晩酌する習慣がついてしまい、人生最大の体重と体脂肪率になったからです。実は 2 年前まで近所のジムに通っていました。あまり合わずに 3 ヶ月ほどで辞めた後、近所のエニタイムフィットネス に行こうと思い 2 年が経ってしまいました。これ以上延ばすのはまずいと思い、申し込んだのが [2018-06-30-1] というわけです。ジムに行く頻度と内容 週 3 回目標で、最低週 2 回で続けています。もう 6 ヶ月目です。雨の日も風の日も台風の日も通います。何も考えずに通うことが重要です。「一度決めたことを忠実に繰り返してしまう」という私の性格に大変助かっています。

ジム通いと食生活改善を５ヶ月続けたので中間報告をする

こんにちは。増田（<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a>）です。以前住んだ街を訪れるのが趣味です。

週次の社内勉強会 <a href="https://developer.feedforce.jp/archive/category/FFTT">FFTT</a> で『Heroku と EC Booster と私』と『Heroku ちょこっと Deep Dive』という発表をしました。

まさかのダブルタイトル・・・！ スライドを作っていたら別々の話のような気がして、こうなりました。

<h2>発表の内容</h2>

<script async class="speakerdeck-embed" data-id="868618a13fbb4e8d8baf8f00c1f2e962" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>


『Heroku と EC Booster と私』は主に社内向けの話です。最近の EC Booster のインフラを紹介する機会がなかったので、今回の発表の場を借りました。

『Heroku ちょこっと Deep Dive』では Heroku の Slug について、ちょこっと調べました。

Heroku では <a href="https://jp.heroku.com/dynos">Dyno</a> という軽量コンテナ上で、アプリケーションが動作します。アプリケーションは <a href="https://devcenter.heroku.com/articles/slug-compiler">Slug というパッケージに固められて</a>います。Slug にはアプリケーションコードの他に Buildpack や、Ruby なら bundle install されたライブラリ等が含められています。

最近 Heroku を Terraform で管理し始めた時に、<a href="https://www.terraform.io/docs/providers/heroku/r/slug.html">heroku_slug</a> というリソースを見つけました。使いはしなかったのですが、自分で Slug を変更できる感覚がよく分からなくて調べたことが始まりでした。

まさか Scratch から作れるとは思いませんでしたし、Slug の中身やサイズの増減を把握する方法が分かったことは大きな収穫でした。

発表では話し忘れたのですが、Heroku は Stack に日々セキュリティパッチが当たって、24 時間以内に適用されることは大きなメリットです。小さなチームで当てるべきパッチの把握や適用をするのは、相当しんどいですからね。

それでは、発表後に書いてくれた付箋への返信です。

<h2>発表の感想</h2>

付箋紙に感想を書いてくれました。 は私からのコメントです。

<ul>
<li><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20181112/20181112233219.jpg" alt="Heroku by yousuke?" title="f:id:masutaka26:20181112233219j:plain" class="hatena-fotolife" itemprop="image">

<ul>
<li> いつもありがとうございます</li>
</ul>
</li>
<li>ふだん Heroku Review App しか使ってなかったんですが、興味を持ちました

<ul>
<li> Rails アプリの公開にも、小さなスクリプトの定期実行にも使えるので便利ですよ</li>
</ul>
</li>
<li>マッスル マスタカ！💪

<ul>
<li> マッスル マッスル！💪</li>
</ul>
</li>
<li>Heroku 未だに HTTP 1.1 なんですよね

<ul>
<li> そうなんですよねー 💦 さすがにそろそろ...</li>
</ul>
</li>
<li>早く AWS + CloudFront 使いたい

<ul>
<li> assets は CDN に逃したいですねー</li>
</ul>
</li>
<li>(dfplus.)io はいまだにフロントは Heroku 使ってマスタカ

<ul>
<li> そうでありマスタカ</li>
</ul>
</li>
<li>Push された tar ball に build された file が入るんですか

<ul>
<li> そんな感じですー</li>
</ul>
</li>
<li>EC Booster のリリース時に Heroku を徹底的につかいたおすことを目標にしていたので、この発表もマスタカさんのふだんの仕事もとても感謝しています

<ul>
<li> もったいないお言葉、ありがとうございます！</li>
</ul>
</li>
<li>「Heroku は良いサービス」めっちゃわかる

<ul>
<li> だよねー</li>
</ul>
</li>
<li>Heroku は良しなにやってくれるけど、その「良しなに」部分もちゃんとオープンになっているのすばらしい

<ul>
<li> ですねー。ずっと謎だった Slug の正体が分かってよかったです</li>
</ul>
</li>
<li>プロダクション環境での Heroku 運用、勉強になりました

<ul>
<li> まだまだ小さなサービスですからね。これから大きくなると、問題がたくさん出てきそうです</li>
</ul>
</li>
<li>なんか push したら動かしてくれる Heroku が裏で何やってるか知れてよかったです！ 最近便利な機能知って Heroku いいなーってなってます！

<ul>
<li> ありがとうございます。他にも <a href="https://www.heroku.com/continuous-integration">Heroku CI</a> や <a href="https://devcenter.heroku.com/articles/pipelines#promoting">Promoting</a> など、まだ試せていない機能がありますねー</li>
</ul>
</li>
<li>資料が分かりやすいです

<ul>
<li> 安心安全な資料作りを心がけて参ります</li>
</ul>
</li>
<li>資料の文字数がちょうど良くてとても見やすいと思いました

<ul>
<li> 本当はもっと減らしたいのですが、あとから読める資料としても作ったので、今回の長さになりました</li>
</ul>
</li>
<li>ボトルネックがないようなら Heroku 便利そう

<ul>
<li> とは言え、パフォーマンスを突き詰めると厳しいと感じています。現在は割とバックグラウンド＆バッチ処理にフォーカスしています</li>
</ul>
</li>
<li>さすが弊社で Heroku に一番詳しい男！！

<ul>
<li> 引き続きニッチな領域を攻めていきます</li>
</ul>
</li>
<li>マスタカさんは説明が上手だなと思いました（こなみ）

<ul>
<li> ありがとうございます！</li>
</ul>
</li>
<li>Heroku..... なんだかんだ、難しいイメージがあります...

<ul>
<li> 私も最初はそうでしたねー</li>
</ul>
</li>
<li>身近に仕事で Heroku 使ってる人だー

<ul>
<li> いえす！</li>
</ul>
</li>
<li>初心者でも使えるけど奥が深い Heroku

<ul>
<li> ですねー</li>
</ul>
</li>
</ul>


<h2>発表の感想の感想</h2>

Heroku はバックエンドエンジニアには概ね好評ですが、フロントエンドエンジニアには割と不評な印象を受けました。

HTTP/3 という話が出てきた今、未だに HTTP/1.1 なのはだいぶ遅れてますし、パフォーマンスを突き詰めると、どうしてもレイテンシー問題に直面してしまいます。逆に言えば、この辺どうにかなれば最強だと思うのですが。🌀

Heroku の先を見据えてやっていきます。💪

こんにちは。増田（id:masutaka26）です。以前住んだ街を訪れるのが趣味です。週次の社内勉強会 FFTT で『Heroku と EC Booster と私』と『Heroku ちょこっと Deep Dive』という発表をしました。まさかのダブルタイトル・・・！ スライドを作っていたら別々の話のような気がして、こうなりました。発表の内容『Heroku と EC Booster と私』は主に社内向けの話です。最近の EC Booster のインフラを紹介する機会がなかったので、今回の発表の場を借りました。『Heroku ちょこっと Deep Dive』では Heroku の Slug について、ちょこっと調べました。Heroku では Dyno という軽量コンテナ上で、アプリケーションが動作します。アプリケーションは Slug というパッケージに固められています。Slug にはアプリケーションコードの他に Buildpack や、Ruby なら bundle install されたライブラリ等が含められています。最近 Heroku を Terraform で管理し始めた時に、heroku_slug というリソースを見つけました。使いはしなかったのですが、自分で Slug を変更できる感覚がよく分からなくて調べたことが始まりでした。まさか Scratch から作れるとは思いませんでしたし、Slug の中身やサイズの増減を把握する方法が分かったことは大きな収穫でした。発表では話し忘れたのですが、Heroku は Stack に日々セキュリティパッチが当たって、24 時間以内に適用されることは大きなメリットです。小さなチームで当てるべきパッチの把握や適用をするのは、相当しんどいですからね。それでは、発表後に書いてくれた付箋への返信です。発表の感想付箋紙に感想を書いてくれました。 は私からのコメントです。 いつもありがとうございますふだん Heroku Review App しか使ってなかったんですが、興味を持ちました Rails アプリの公開にも、小さなスクリプトの定期実行にも使えるので便利ですよマッスル マスタカ！💪 マッスル マッスル！💪Heroku 未だに HTTP 1.1 なんですよね そうなんですよねー 💦 さすがにそろそろ...早く AWS + CloudFront 使いたい assets は CDN に逃したいですねー(dfplus.)io はいまだにフロントは Heroku 使ってマスタカ そうでありマスタカPush された tar ball に build された file が入るんですか そんな感じですーEC Booster のリリース時に Heroku を徹底的につかいたおすことを目標にしていたので、この発表もマスタカさんのふだんの仕事もとても感謝しています もったいないお言葉、ありがとうございます！「Heroku は良いサービス」めっちゃわかる だよねーHeroku は良しなにやってくれるけど、その「良しなに」部分もちゃんとオープンになっているのすばらしい ですねー。ずっと謎だった Slug の正体が分かってよかったですプロダクション環境での Heroku 運用、勉強になりました まだまだ小さなサービスですからね。これから大きくなると、問題がたくさん出てきそうですなんか push したら動かしてくれる Heroku が裏で何やってるか知れてよかったです！ 最近便利な機能知って Heroku いいなーってなってます！ ありがとうございます。他にも Heroku CI や Promoting など、まだ試せていない機能がありますねー資料が分かりやすいです 安心安全な資料作りを心がけて参ります資料の文字数がちょうど良くてとても見やすいと思いました 本当はもっと減らしたいのですが、あとから読める資料としても作ったので、今回の長さになりましたボトルネックがないようなら Heroku 便利そう とは言え、パフォーマンスを突き詰めると厳しいと感じています。現在は割とバックグラウンド＆バッチ処理にフォーカスしていますさすが弊社で Heroku に一番詳しい男！！ 引き続きニッチな領域を攻めていきますマスタカさんは説明が上手だなと思いました（こなみ） ありがとうございます！Heroku..... なんだかんだ、難しいイメージがあります... 私も最初はそうでしたねー身近に仕事で Heroku 使ってる人だー いえす！初心者でも使えるけど奥が深い Heroku ですねー発表の感想の感想Heroku はバックエンドエンジニアには概ね好評ですが、フロントエンドエンジニアには割と不評な印象を受けました。HTTP/3 という話が出てきた今、未だに HTTP/1.1 なのはだいぶ遅れてますし、パフォーマンスを突き詰めると、どうしてもレイテンシー問題に直面してしまいます。逆に言えば、この辺どうにかなれば最強だと思うのですが。🌀Heroku の先を見据えてやっていきます。💪

『Heroku と EC Booster と私』と『Heroku ちょこっと Deep Dive』という発表をした

こんにちは、増田（<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a>）です。秋は体が急に冷え、一年で一番体調を崩しやすいので、意識して風呂に浸かっています。元気です。

<a href="http://blog.hatena.ne.jp/critical_alert/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/critical_alert/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:critical_alert</a> から <a href="https://healthchecks.io/">https://healthchecks.io/</a> を教えてもらいました。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20181007/20181007221520.png" alt="f:id:masutaka26:20181007221520p:plain" title="f:id:masutaka26:20181007221520p:plain" class="hatena-fotolife" itemprop="image">

cron 系の定期実行ジョブが本当に実行されたかを監視してくれるサービスです。

以前、<a href="https://github.com/ondrejbartas/sidekiq-cron">sidekiq-cron</a> のバグで定期実行ジョブが実行されないことがあったので、なんらかの方法でお手軽に監視したいモチベーションがありました。

<h2>terraform-provider-healthchecksio を発見</h2>

コード化したいなーと思って調べたら、非公式の Terraform provider を発見。

<a class="embedly-card" href="https://github.com/kristofferahl/terraform-provider-healthchecksio">kristofferahl/terraform-provider-healthchecksio</a>

<script async src="//cdn.embedly.com/widgets/platform.js" charset="UTF-8"></script>


こういった設定は属人化しやすいため、Terraform でコード化できるのは助かります。

ただ、この時点では schedule や timezone などに対応していなかったため、採用は断念しました。

healthchecks.io 上でポチポチと監視用のエンドポイントを作成し、ビジネスロジックにも ping するコードを埋め込み、いい感じに動作していました。

<h2>実装開始</h2>

悶々とした日を送り続けたある日、調べてみたら意外と簡単に機能が実装できそうなことが分かりました。

👇 それで送ったのがこの PR。可能な限りのパラメータを使えるようになりました。

<ul>
<li><a href="https://github.com/kristofferahl/terraform-provider-healthchecksio/pull/1">Add parameters by masutaka · Pull Request #1</a></li>
</ul>


terraform import もしたいなーと調べたら、たったの 3 行で対応出来ることが判明。👇 2 つ目の PR を出して無事マージされました。

<ul>
<li><a href="https://github.com/kristofferahl/terraform-provider-healthchecksio/pull/2">Introduce terraform import by masutaka · Pull Request #2</a></li>
</ul>


ついでにしれっとコラボレータに招待してくれて、commit 権を頂けました。やったぜ！

👇 先ほど 3 つ目の PR を出しました。非公式の Terraform provider なので、自分でバイナリを設置する必要があるのですよね。参考になりそうな Makefile を作りました。

<ul>
<li><a href="https://github.com/kristofferahl/terraform-provider-healthchecksio/pull/3">Add examples/Makefile by masutaka · Pull Request #3</a></li>
</ul>


<h2>今後の予定</h2>

<blockquote>The database failover process is manual, and the ops team consists of a single person, so multi-hour or even multi-day outages are possible!

While we can only guarantee a best effort availability, in practice the availability has exceeded 99.9% since the service publicly launched in July 2015.

<a href="https://healthchecks.io/about/">https://healthchecks.io/about/</a></blockquote>

healthchecks.io は安定稼働しており、2015 年 7 月のサービス開始以来、稼働率は 99.9% を超えているそうです。ただあくまでベストエフォート型の可用性しか保証していないので、過信は禁物です。いわゆる 1 人開発プロジェクトでもあります。

今後は Datadog で同じ監視が出来るか調査して、healthchecks.io と併用したいなーと思っています。<a href="https://cronitor.io/">Cronitor</a> も頭の片隅にあるけど、少しオーバースペック感があります。

<h2>おまけ</h2>

healthchecks.io は OSS でもあり、GitHub 上にコードが公開されています。Django で実装されています。

<a class="embedly-card" href="https://github.com/healthchecks/healthchecks">healthchecks/healthchecks</a>

こんにちは、増田（id:masutaka26）です。秋は体が急に冷え、一年で一番体調を崩しやすいので、意識して風呂に浸かっています。元気です。id:critical_alert から https://healthchecks.io/ を教えてもらいました。cron 系の定期実行ジョブが本当に実行されたかを監視してくれるサービスです。以前、sidekiq-cron のバグで定期実行ジョブが実行されないことがあったので、なんらかの方法でお手軽に監視したいモチベーションがありました。terraform-provider-healthchecksio を発見コード化したいなーと思って調べたら、非公式の Terraform provider を発見。kristofferahl/terraform-provider-healthchecksioこういった設定は属人化しやすいため、Terraform でコード化できるのは助かります。ただ、この時点では schedule や timezone などに対応していなかったため、採用は断念しました。healthchecks.io 上でポチポチと監視用のエンドポイントを作成し、ビジネスロジックにも ping するコードを埋め込み、いい感じに動作していました。実装開始悶々とした日を送り続けたある日、調べてみたら意外と簡単に機能が実装できそうなことが分かりました。👇 それで送ったのがこの PR。可能な限りのパラメータを使えるようになりました。Add parameters by masutaka · Pull Request #1terraform import もしたいなーと調べたら、たったの 3 行で対応出来ることが判明。👇 2 つ目の PR を出して無事マージされました。Introduce terraform import by masutaka · Pull Request #2ついでにしれっとコラボレータに招待してくれて、commit 権を頂けました。やったぜ！👇 先ほど 3 つ目の PR を出しました。非公式の Terraform provider なので、自分でバイナリを設置する必要があるのですよね。参考になりそうな Makefile を作りました。Add examples/Makefile by masutaka · Pull Request #3今後の予定The database failover process is manual, and the ops team consists of a single person, so multi-hour or even multi-day outages are possible!While we can only guarantee a best effort availability, in practice the availability has exceeded 99.9% since the service publicly launched in July 2015.https://healthchecks.io/about/healthchecks.io は安定稼働しており、2015 年 7 月のサービス開始以来、稼働率は 99.9% を超えているそうです。ただあくまでベストエフォート型の可用性しか保証していないので、過信は禁物です。いわゆる 1 人開発プロジェクトでもあります。今後は Datadog で同じ監視が出来るか調査して、healthchecks.io と併用したいなーと思っています。Cronitor も頭の片隅にあるけど、少しオーバースペック感があります。おまけhealthchecks.io は OSS でもあり、GitHub 上にコードが公開されています。Django で実装されています。healthchecks/healthchecks

terraform-provider-healthchecksio に足りない機能を実装したらコラボレータになれた

お元気にしてますか。増田（<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a>）です。

先週の金曜日にフィードフォースにおける 2017 年度（2017年6月 〜 2018年5月）の納会が行われ、その中で初の MVP を受賞することができました。🎉

<figure class="figure-image figure-image-fotolife" title="喜びのコメントを表明中のしがないますたか"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20180608/20180608194920.jpg" alt="f:id:masutaka26:20180608194920j:plain" title="f:id:masutaka26:20180608194920j:plain" class="hatena-fotolife" itemprop="image"><figcaption>喜びのコメントを表明中のしがないますたか</figcaption></figure>

<figure class="figure-image figure-image-fotolife" title="チーム賞ももらったヨ"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20180614/20180614005507.jpg" alt="f:id:masutaka26:20180614005507j:plain" title="f:id:masutaka26:20180614005507j:plain" class="hatena-fotolife" itemprop="image"><figcaption>チーム賞ももらったヨ</figcaption></figure>

会社で賞を頂いたのは 4 年前のルーキー賞以来です。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmasutaka.net%2Fchalow%2F2014-06-13-1.html" title="会社でルーキー賞に選ばれた" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://masutaka.net/chalow/2014-06-13-1.html">masutaka.net</a></cite>

<del>四年寝太郎としては、取るべくして取った賞だと思いました（ｷﾘｯ</del>

正直なところ、頑張ったで賞くらいはもらえたりして？とボンヤリ思っていましたが<a href="#f-3841f537" name="fn-3841f537" title="そのような賞はありません">*1</a>、まさか MVP とは思いもよらず、発表の瞬間は素で驚きました。

2017 年度は以下のチームに所属していました。

<ul>
<li>2017 年 6 月 〜 2018 年 3 月

<ul>
<li><a href="https://dfplus.feedforce.jp/">DF PLUS</a>（社内では DF Maker と呼ばれる）</li>
</ul>
</li>
<li>2018 年 4 月 〜 2018 年 5 月

<ul>
<li><a href="https://ecbooster.jp/">EC Booster</a></li>
</ul>
</li>
</ul>


DF Maker ではサービスの信頼性向上にひたすら努める毎日でした。ECS でとんでもない量のエラーが発生して、３連休の間は暇を見つけてエラーログを確認してたなー（遠い目）。

EC Booster ではチームビルディングから始めました。👇️以下の記事にまとまっています。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2018%2F05%2F21%2F150000" title="『開発基盤チームとして課題を探したらマネジメントをしていた』という発表をした - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://developer.feedforce.jp/entry/2018/05/21/150000">developer.feedforce.jp</a></cite>

どちらにも共通することが、2 年目の優秀な若者と仕事ができたことです。私が若者を引っ張っていくぜーという感じではなくむしろ逆で、すでにサービスを知り尽くした若者から学ぶ日々でした（今もそうです）。

その中で、「こうすればチーム開発がドライブするだろう」や「こうすればサービスの質を高められるだろう」というアイディアを出し、実践し、小さな改善と失敗を繰り返したことが、結果としてチームの状況を良くしたりサービスの質を高めることが出来たのだと思います（現在進行系）。

もちろん、一緒に働くことができたチームの皆さんの協力があっての賞です。ありがとうございます。🙏

それではまた 4 年後にお会いしましょう💤
<div class="footnote">
<a href="#fn-3841f537" name="f-3841f537" class="footnote-number">*1</a>:そのような賞はありません
</div>

お元気にしてますか。増田（id:masutaka26）です。先週の金曜日にフィードフォースにおける 2017 年度（2017年6月 〜 2018年5月）の納会が行われ、その中で初の MVP を受賞することができました。🎉喜びのコメントを表明中のしがないますたかチーム賞ももらったヨ会社で賞を頂いたのは 4 年前のルーキー賞以来です。masutaka.net四年寝太郎としては、取るべくして取った賞だと思いました（ｷﾘｯ正直なところ、頑張ったで賞くらいはもらえたりして？とボンヤリ思っていましたが*1、まさか MVP とは思いもよらず、発表の瞬間は素で驚きました。2017 年度は以下のチームに所属していました。2017 年 6 月 〜 2018 年 3 月DF PLUS（社内では DF Maker と呼ばれる）2018 年 4 月 〜 2018 年 5 月EC BoosterDF Maker ではサービスの信頼性向上にひたすら努める毎日でした。ECS でとんでもない量のエラーが発生して、３連休の間は暇を見つけてエラーログを確認してたなー（遠い目）。EC Booster ではチームビルディングから始めました。👇️以下の記事にまとまっています。developer.feedforce.jpどちらにも共通することが、2 年目の優秀な若者と仕事ができたことです。私が若者を引っ張っていくぜーという感じではなくむしろ逆で、すでにサービスを知り尽くした若者から学ぶ日々でした（今もそうです）。その中で、「こうすればチーム開発がドライブするだろう」や「こうすればサービスの質を高められるだろう」というアイディアを出し、実践し、小さな改善と失敗を繰り返したことが、結果としてチームの状況を良くしたりサービスの質を高めることが出来たのだと思います（現在進行系）。もちろん、一緒に働くことができたチームの皆さんの協力があっての賞です。ありがとうございます。🙏それではまた 4 年後にお会いしましょう💤*1:そのような賞はありません

先期の MVP に選ばれた

こんにちは。増田（<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a>）です。発表が無事終わり、何かゲームでも買おうかなと思ってます。

さて、フィードフォースでは毎週金曜日 16:00 から、社内技術勉強会を開催しています。当番制の持ち回りで技術に関連したことを発表します。

先週金曜日は私の当番で『開発基盤チームとして課題を探したらマネジメントをしていた』という発表をしました。

技術チーム以外の方もたくさん聞きに来てくれて、ありがたかったです。🙏

<h2>発表の内容</h2>

<script async class="speakerdeck-embed" data-id="978c7016bb7b473693f547116e8e704f" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>


<a href="http://developer.feedforce.jp/entry/2017/10/16/150000">前回</a>含めて、これまでの発表は全てコードが登場していました。今回のようなコードが登場しないマネジメントの話は、内容が拡散しがちで難しかったです。結局まとまりませんでした...。

今回は敢えて後から読めるプレゼン資料にしました。なのでプレゼン資料としては冗長な書き方になっています。

まとめるとこんな内容です。

<ul>
<li>コミュニケーションの不確実性を解消することが、マネジメント（やチームビルディング）に必要なはず</li>
<li>そのため自ら場に飛び込んで、情報の非対称性を解消していった</li>
<li>これからもソフトウェアを書くこと以外に課題解決の手段があればやっていく</li>
<li>そして徐々にマネジメントにかける時間を減らし、コードを書く時間を増やしていく</li>
</ul>


今思えば、話し忘れたことがポロポロと出てきます。

<ul>
<li>そもそもチームメンバーは自走できる方々で、ホワイトボード整理の時も方針だけ話したら勝手に整理されていった

<ul>
<li>私は方向性を決めただけ</li>
</ul>
</li>
<li>チームに入りたてのときは少々オーバーリアクションを心がけ、徐々に普通に戻していく。

<ul>
<li>何考えている人か分かってもらうことで、その後のコミュニケーションをスムーズにする</li>
</ul>
</li>
</ul>


完璧な発表などありませんね。

<h2>発表の感想</h2>

付箋紙に感想を書いてくれました。 は私からのコメントです。

<ul>
<li>ジョハリの窓の紹介ありがとうございます。勉強になります！

<ul>
<li> 私も『<a href="https://www.amazon.co.jp/dp/B079TLW41L/">エンジニアリング組織論への招待</a>』で初めて知りました。数年前にプロダクトオーナーの学習をした以来ですから...</li>
</ul>
</li>
<li>自分はまだマネジメントからは程遠い存在なのですが、話しかけやすいオーラを出すことや、くだらないと思うことも質問することなどは、今すぐにでも実行出来るし、目指すことだと思いました。ありがとうございました！

<ul>
<li> はい、個々が意識することが自走するチームや、個々のリーダーシップに繋がると思います</li>
</ul>
</li>
<li>共感できる良い話でした

<ul>
<li> あざす！</li>
</ul>
</li>
<li>初公開の画像が見られて良かったです

<ul>
<li> お粗末さまでした...</li>
</ul>
</li>
<li>早くインフラ朝会にもどって来てください

<ul>
<li> 今回の件が落ち着いたらインフラ朝会にもどりますよ。待っていてくださいね！</li>
</ul>
</li>
<li>必要な情報とそうでもない情報の整理はものすごい HP/MP を消費しそう

<ul>
<li> そうですね...</li>
</ul>
</li>
<li>マネジメントの成果はすぐには結果に現れないかも？どの位の頻度で振り返るべきなのか？

<ul>
<li> イテレーションごとの振り返りで、チームを観察すれば良いです。マネジメントの成果かどうかは重要ではないと思います</li>
</ul>
</li>
<li>◯◯を支える技術

<ul>
<li> 次回はコードの話をしよう...</li>
</ul>
</li>
<li>知識科学やり直さなきゃ・・・

<ul>
<li> 私は今回で終了ですw</li>
</ul>
</li>
<li>チームの問題点を発見して、それを解決する手段を選ばないスタンスがすごい

<ul>
<li> もう必死ですよ（笑）</li>
</ul>
</li>
<li>「内心ではなく行動に注目する」は、認知行動療法などでも使われていますね（最近のトレンド？）

<ul>
<li> へぇ〜</li>
</ul>
</li>
<li>なかなかボリュームある資料でしたが、作るのにどれくらいかかったのか気になります

<ul>
<li> 先週土曜日の夜に草稿を作り「これでいけそう」という感触を得て、今週は平日の夜２日くらいで整理をしました。話す内容については一ヶ月くらい前から頭の中で考えたり、『<a href="https://www.amazon.co.jp/dp/B079TLW41L/">エンジニアリング組織論への招待</a>』を全部読んだりしてました</li>
</ul>
</li>
<li>最近疲弊してそうで心配でしたが、今日の発表で色々アウトプットしてもらって安心しました

<ul>
<li> 気にかけて頂いてありがとうございます。これからも安心安全のマスタカをお届けして参ります</li>
</ul>
</li>
<li>うなずきすぎて首もげる

<ul>
<li> ありがとうございます。参考になったことが各チームに還元されるとうれしいです</li>
</ul>
</li>
<li>マスタカさん自体はマネジメントよりコード書く方が好きなんでしょうか？

<ul>
<li> そうですね。引き篭もってコードを書きたいです</li>
</ul>
</li>
<li>ますたかさんのおかげでチームがちゃんと回りはじめた気がします

<ul>
<li> そう言って頂けるとうれしいです。今がスタート地点だと捉え、精進してまいります</li>
</ul>
</li>
<li>増田さんが参加されてから何かがスムーズになった実感があります（情報や知識だけでなく）

<ul>
<li> うれしいですね。マネジメントは空気のような存在が良いと考えています</li>
</ul>
</li>
<li>マネジメントってどうやるか？のテクニックの面もあるけど、誰がやるか？の面も大きい気がしてます

<ul>
<li> そうですね。例えば入ったばかりの職場だと、信頼関係を築くことから始まると思います。今回は同じ会社ということと、過去に一緒に働いたメンバーがいたことに助けられました</li>
</ul>
</li>
<li>EC Booster のこれからに期待しています！

<ul>
<li> 💪</li>
</ul>
</li>
<li>「場に飛び込む」「正しく伝わったと思わない」肝に銘じます！

<ul>
<li> よろしくお願いします！</li>
</ul>
</li>
<li>「エンジニアが発見した課題の解決フロー」読みたいです

<ul>
<li> Slack で書いたとおり、割と普通のフローです。発表で話したエンジニア以外の方からの依頼と整合性を合わせてこうしました。まだ始めて間もなく 1 イテレーションも回してない状態ですがね...

<ol>
<li> Issue を作ると EC Booster waffle.io の Planning カラムに入る</li>
<li> 次の開発ミーティングで Planning カラムを空にする</li>
<li> スプリントでは Sprint Backlog に集中する</li>
</ol>
</li>
</ul>
</li>
<li>feedforce だとマネジメントオンリーじゃなくて、開発+マネジメントが最強という話を昨日クリストフとした

<ul>
<li> 最強かは分かりませんが、コードも分かったほうが捗ると思います</li>
</ul>
</li>
<li>仕事でもプライベートでも、コミュニティ内でオープンな発信をする人が多いと、円滑に物事が進みやすいなと考えられました。その逆もまた然りだったので...。かつ、人に伝えるときは具体的にするというのも大切かと思いました

<ul>
<li> 他人は自分でないので、分かりやすく具体的なコミュニケーションが大事ですね</li>
</ul>
</li>
<li><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20180519/20180519155210.jpg" alt="masutaka by yousuke" title="f:id:masutaka26:20180519155210j:plain" class="hatena-fotolife" itemprop="image">

<ul>
<li> え、誰？（困惑）</li>
</ul>
</li>
</ul>


<h2>最後に</h2>

<div class="hatena-asin-detail"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4774196053/hatena-blog-22/"><img src="https://images-fe.ssl-images-amazon.com/images/I/51zMvVL4MeL._SL160_.jpg" class="hatena-asin-detail-image" alt="エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング" title="エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング"></a><div class="hatena-asin-detail-info"><a href="http://www.amazon.co.jp/exec/obidos/ASIN/4774196053/hatena-blog-22/">エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング</a><ul><li>作者: 広木大地</li><li>出版社/メーカー: 技術評論社</li><li>発売日: 2018/02/22</li><li>メディア: 単行本（ソフトカバー）</li><li><a href="http://d.hatena.ne.jp/asin/4774196053/hatena-blog-22" target="_blank">この商品を含むブログ (2件) を見る</a></li></ul></div><div class="hatena-asin-detail-foot"></div></div>

良かったぞ。「エンジニア組織論」ではないことに注目。プロダクトオーナーやエンジニア以外の職種の方にも是非読んでもらいたいです。

こんにちは。増田（id:masutaka26）です。発表が無事終わり、何かゲームでも買おうかなと思ってます。さて、フィードフォースでは毎週金曜日 16:00 から、社内技術勉強会を開催しています。当番制の持ち回りで技術に関連したことを発表します。先週金曜日は私の当番で『開発基盤チームとして課題を探したらマネジメントをしていた』という発表をしました。技術チーム以外の方もたくさん聞きに来てくれて、ありがたかったです。🙏発表の内容前回含めて、これまでの発表は全てコードが登場していました。今回のようなコードが登場しないマネジメントの話は、内容が拡散しがちで難しかったです。結局まとまりませんでした...。今回は敢えて後から読めるプレゼン資料にしました。なのでプレゼン資料としては冗長な書き方になっています。まとめるとこんな内容です。コミュニケーションの不確実性を解消することが、マネジメント（やチームビルディング）に必要なはずそのため自ら場に飛び込んで、情報の非対称性を解消していったこれからもソフトウェアを書くこと以外に課題解決の手段があればやっていくそして徐々にマネジメントにかける時間を減らし、コードを書く時間を増やしていく今思えば、話し忘れたことがポロポロと出てきます。そもそもチームメンバーは自走できる方々で、ホワイトボード整理の時も方針だけ話したら勝手に整理されていった私は方向性を決めただけチームに入りたてのときは少々オーバーリアクションを心がけ、徐々に普通に戻していく。何考えている人か分かってもらうことで、その後のコミュニケーションをスムーズにする完璧な発表などありませんね。発表の感想付箋紙に感想を書いてくれました。 は私からのコメントです。ジョハリの窓の紹介ありがとうございます。勉強になります！ 私も『エンジニアリング組織論への招待』で初めて知りました。数年前にプロダクトオーナーの学習をした以来ですから...自分はまだマネジメントからは程遠い存在なのですが、話しかけやすいオーラを出すことや、くだらないと思うことも質問することなどは、今すぐにでも実行出来るし、目指すことだと思いました。ありがとうございました！ はい、個々が意識することが自走するチームや、個々のリーダーシップに繋がると思います共感できる良い話でした あざす！初公開の画像が見られて良かったです お粗末さまでした...早くインフラ朝会にもどって来てください 今回の件が落ち着いたらインフラ朝会にもどりますよ。待っていてくださいね！必要な情報とそうでもない情報の整理はものすごい HP/MP を消費しそう そうですね...マネジメントの成果はすぐには結果に現れないかも？どの位の頻度で振り返るべきなのか？ イテレーションごとの振り返りで、チームを観察すれば良いです。マネジメントの成果かどうかは重要ではないと思います◯◯を支える技術 次回はコードの話をしよう...知識科学やり直さなきゃ・・・ 私は今回で終了ですwチームの問題点を発見して、それを解決する手段を選ばないスタンスがすごい もう必死ですよ（笑）「内心ではなく行動に注目する」は、認知行動療法などでも使われていますね（最近のトレンド？） へぇ〜なかなかボリュームある資料でしたが、作るのにどれくらいかかったのか気になります 先週土曜日の夜に草稿を作り「これでいけそう」という感触を得て、今週は平日の夜２日くらいで整理をしました。話す内容については一ヶ月くらい前から頭の中で考えたり、『エンジニアリング組織論への招待』を全部読んだりしてました最近疲弊してそうで心配でしたが、今日の発表で色々アウトプットしてもらって安心しました 気にかけて頂いてありがとうございます。これからも安心安全のマスタカをお届けして参りますうなずきすぎて首もげる ありがとうございます。参考になったことが各チームに還元されるとうれしいですマスタカさん自体はマネジメントよりコード書く方が好きなんでしょうか？ そうですね。引き篭もってコードを書きたいですますたかさんのおかげでチームがちゃんと回りはじめた気がします そう言って頂けるとうれしいです。今がスタート地点だと捉え、精進してまいります増田さんが参加されてから何かがスムーズになった実感があります（情報や知識だけでなく） うれしいですね。マネジメントは空気のような存在が良いと考えていますマネジメントってどうやるか？のテクニックの面もあるけど、誰がやるか？の面も大きい気がしてます そうですね。例えば入ったばかりの職場だと、信頼関係を築くことから始まると思います。今回は同じ会社ということと、過去に一緒に働いたメンバーがいたことに助けられましたEC Booster のこれからに期待しています！ 💪「場に飛び込む」「正しく伝わったと思わない」肝に銘じます！ よろしくお願いします！「エンジニアが発見した課題の解決フロー」読みたいです Slack で書いたとおり、割と普通のフローです。発表で話したエンジニア以外の方からの依頼と整合性を合わせてこうしました。まだ始めて間もなく 1 イテレーションも回してない状態ですがね... Issue を作ると EC Booster waffle.io の Planning カラムに入る 次の開発ミーティングで Planning カラムを空にする スプリントでは Sprint Backlog に集中するfeedforce だとマネジメントオンリーじゃなくて、開発+マネジメントが最強という話を昨日クリストフとした 最強かは分かりませんが、コードも分かったほうが捗ると思います仕事でもプライベートでも、コミュニティ内でオープンな発信をする人が多いと、円滑に物事が進みやすいなと考えられました。その逆もまた然りだったので...。かつ、人に伝えるときは具体的にするというのも大切かと思いました 他人は自分でないので、分かりやすく具体的なコミュニケーションが大事ですね え、誰？（困惑）最後にエンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング作者: 広木大地出版社/メーカー: 技術評論社発売日: 2018/02/22メディア: 単行本（ソフトカバー）この商品を含むブログ (2件) を見る良かったぞ。「エンジニア組織論」ではないことに注目。プロダクトオーナーやエンジニア以外の職種の方にも是非読んでもらいたいです。

『開発基盤チームとして課題を探したらマネジメントをしていた』という発表をした

この記事は feedforce Advent Calendar 2017 の 19 日目の記事です。
18 日目はなべはるさんの『ITベンチャー企業の人事が使っている SaaS
10選！ 』でした。なべはるさんは一日に食べるアイスと同じくらい SaaS
を活用していてすごいと思います！
昨年 [2016-12-14-1] に引き続き、今年も生活に関する記事です。ダイエッ
トは皆さん興味があると思うので、とても有用な情報かと思います。
実際試して、結果的に全部失敗しています。この記事をアンチパターンと
して試せば、成功するのではないでしょうか？（えぇ..）
1. ヘルシア緑茶を 3 ヶ月間飲み続ける 川崎の平間に住んでいた頃なので、2004 年秋頃だと思います。
経緯は忘れましたが、ヘルシア緑茶を毎日 1 本、3 ヶ月間飲み続けまし
た。毎日バラで買うのは大変なので、近所の酒屋での箱買いです。
「ヘルシア緑茶飲んでいるからへーきへーき」と食事制限はしませんでした。
★結果: 何も変わらず。むしろ増えた記憶が。ヘルシア緑茶のようにほろ
苦い思い出です。
2. ジムに毎日通う 時は流れ、2010 年 9 月。それまで全く運動をしていなかったのに、急に
近所のジムに通い始めました。今は無きクイックシェイプというジムです。
最初の何ヶ月かは本当に毎日通っていて、行かないのはジムが休みの金曜
日と、たまの飲み会の日くらいでした。
これらの記事に意識高くまとまっています。
[2011-03-05-1] [2011-03-05-2] [2011-03-05-3] 今でもなぜあそこまでやる気があったのか分かりません。
★結果: 意識が高くなりすぎて、新卒から 11 年在籍した会社を退職
[2011-04-22-1] 。スタートアップで社員第一号として働き始める。
ダイエットには失敗。
西明石に引っ越した 2011 年 4 月末まで、7 ヶ月間通いました。
3. 野々池貯水池でウォーキング 一階のダイニングキッチンがオフィス、二階の各部屋に若者と住んでいた
この家の近所には、ジムなんて便利なものはありません。あるのは田んぼ
くらいでした。
自転車でいけるくらいの距離に野々池貯水池があり、老若男女がジョギン
グやウォーキング、犬の散歩などをしていました。

この記事は feedforce Advent Calendar 2017 の 19 日目の記事です。18 日目はなべはるさんの『ITベンチャー企業の人事が使っている SaaS10選！ 』でした。なべはるさんは一日に食べるアイスと同じくらい SaaSを活用していてすごいと思います！昨年 [2016-12-14-1] に引き続き、今年も生活に関する記事です。ダイエットは皆さん興味があると思うので、とても有用な情報かと思います。実際試して、結果的に全部失敗しています。この記事をアンチパターンとして試せば、成功するのではないでしょうか？（えぇ..）1. ヘルシア緑茶を 3 ヶ月間飲み続ける 川崎の平間に住んでいた頃なので、2004 年秋頃だと思います。経緯は忘れましたが、ヘルシア緑茶を毎日 1 本、3 ヶ月間飲み続けました。毎日バラで買うのは大変なので、近所の酒屋での箱買いです。「ヘルシア緑茶飲んでいるからへーきへーき」と食事制限はしませんでした。★結果: 何も変わらず。むしろ増えた記憶が。ヘルシア緑茶のようにほろ苦い思い出です。2. ジムに毎日通う 時は流れ、2010 年 9 月。それまで全く運動をしていなかったのに、急に近所のジムに通い始めました。今は無きクイックシェイプというジムです。最初の何ヶ月かは本当に毎日通っていて、行かないのはジムが休みの金曜日と、たまの飲み会の日くらいでした。これらの記事に意識高くまとまっています。[2011-03-05-1] [2011-03-05-2] [2011-03-05-3] 今でもなぜあそこまでやる気があったのか分かりません。★結果: 意識が高くなりすぎて、新卒から 11 年在籍した会社を退職[2011-04-22-1] 。スタートアップで社員第一号として働き始める。ダイエットには失敗。西明石に引っ越した 2011 年 4 月末まで、7 ヶ月間通いました。3. 野々池貯水池でウォーキング 一階のダイニングキッチンがオフィス、二階の各部屋に若者と住んでいたこの家の近所には、ジムなんて便利なものはありません。あるのは田んぼくらいでした。自転車でいけるくらいの距離に野々池貯水池があり、老若男女がジョギングやウォーキング、犬の散歩などをしていました。

これまで試したダイエット７つを紹介する（※全部失敗）

こんにちは。増田（<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn1.www.st-hatena.com/users/ma/masutaka26/profile.gif" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a>）です。社内勉強会の順番が来ると、２ヶ月前くらいからソワソワしてきます。

そんなわけで今回は『日報を golang で支える技術』というお題で発表しました。

<h2>発表の内容</h2>

<script async class="speakerdeck-embed" data-id="b96e99d03504492f85e58bff0c8d1171" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>


以下、スライドからの抜粋です。

<ul>
<li>背景など

<ul>
<li><a href="https://masutaka.net/chalow/2016-04-09-1.html">以前の社内勉強会で github-nippou という gem を紹介した</a></li>
<li>ひとつの ruby スクリプトからそこそこ作り込み、毎日便利に使っている</li>
<li>先日も同僚の <a href="https://github.com/ryz310">@ryz310</a> から pull request をもらって、さらに便利になった</li>
<li>からの、golang への書き換えをした。その場でライブリリース</li>
</ul>
</li>
<li>モチベーション

<ul>
<li>以前 <a href="https://github.com/github/hub/releases/tag/v2.2.0">hub コマンドが ruby から golang に移行した</a>のを見て、一度やってみたかった</li>
<li>rubygems の CLI を Dockerize してポータビリティを高めるのは何かが違うという気持ち</li>
<li><a href="https://github.com/ryz310">@ryz310</a> からもらった元気</li>
</ul>
</li>
<li>当たり前だけど、全て代わりの方法を調べて実装しなければいけなかった

<ul>
<li>octokit → go-github, thor → cobra など。Assets の取り扱いも変わる</li>
</ul>
</li>
<li>良かったこと

<ul>
<li>１バイナリになったのでインストールやアップデートが容易になった</li>
<li>パフォーマンスも予想外に上がった（当社比約２倍）

<ul>
<li>以前調べた時は GitHub への API アクセスがボトルネックだったので、そこまで変わらないと思っていた</li>
</ul>
</li>
<li>結果的にいろんなライブラリを使えて、良い素振りになった</li>
</ul>
</li>
<li>困ったこと

<ul>
<li>とにかく関数が長くなりがち</li>
<li>getXXX() 多くなりすぎ</li>
<li>ファイル分割の意味</li>
<li>書けば書くほど golang っぽい書き方が分からなくなる</li>
<li>OOP ではないことへの戸惑い</li>
<li>ruby が柔軟すぎて移植は難しかった。オススメはしない</li>
</ul>
</li>
<li>疑問など

<ul>
<li>class設計で便利だった、private method の代わり

<ul>
<li>設計し直すべきか</li>
<li>classを 使わなかった頃の JS の知見を知りたい</li>
</ul>
</li>
<li>ビジネスロジックのパッケージ名はどうすれば

<ul>
<li>今回は lib にした</li>
</ul>
</li>
</ul>
</li>
<li>感想

<ul>
<li>今後、rubygems で CLI ツールを作ることはないと思う。継続利用を考えると勧めづらい</li>
<li>golang は単一ファイルでの実装と実行に一番ハードルが低い気がしている

<ul>
<li>もっと楽な言語あったら教えて</li>
</ul>
</li>
</ul>
</li>
<li>今後の予定

<ul>
<li>golang っぽい書き方にする</li>
<li>もっとテストを書く</li>
<li>golang on Lambda や API サーバも学習する</li>
<li>『<a href="https://www.amazon.co.jp/dp/B01FH3KRTI">スターティングGo言語</a>』を読み切る</li>
</ul>
</li>
</ul>


<h2>結果</h2>

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20171014/20171014163806.png" alt="f:id:masutaka26:20171014163806p:plain" title="f:id:masutaka26:20171014163806p:plain" class="hatena-fotolife" itemprop="image">

↓

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20171014/20171014163802.png" alt="f:id:masutaka26:20171014163802p:plain" title="f:id:masutaka26:20171014163802p:plain" class="hatena-fotolife" itemprop="image">

<a href="https://github.com/masutaka/github-nippou">https://github.com/masutaka/github-nippou</a>

<h2>発表の感想</h2>

付箋紙に感想を書いてくれました。 は私からのコメントです。

<ul>
<li>クラス設計周りの話は自分も悩んでいます

<ul>
<li> ライブラリとか読んで学習します！</li>
</ul>
</li>
<li>GraphQL 対応の PR 出すぞ

<ul>
<li> お待ちしております！</li>
</ul>
</li>
<li>Go の GraphQL のクライアント側はまだなさそう

<ul>
<li> <a href="https://github.com/graphql-go/graphql">github.com/graphql-go/graphql</a> を見つけました。API リクエストを 1 回に出来るのかな？</li>
</ul>
</li>
<li>CLI は ruby &lt; golang わかる。mruby も良いかも

<ul>
<li> mruby はエコシステムが大変そうで...</li>
</ul>
</li>
<li>Makefile 参考にします

<ul>
<li> あざす！</li>
</ul>
</li>
<li>Makefile 全く分からない... 勉強しないと！！

<ul>
<li> 基本だったら１日くらいで分かりますよ。make はビルドを必要な時だけに抑えられるので良いです</li>
</ul>
</li>
<li>流石ますたかさん とても面白く熱量ある発表でした

<ul>
<li> ありがとうございます。熱量は大事にしてます</li>
</ul>
</li>
<li>神回ですね

<ul>
<li> もっと技術レベル上げていきます！</li>
</ul>
</li>
<li>刺激を受けるいい話だった

<ul>
<li> 刺激を与えるのがエンジニアとして使命のひとつだと思っています</li>
</ul>
</li>
<li>スピード up は nice 発見

<ul>
<li> ですね</li>
</ul>
</li>
<li>やっぱりはやくなるものなんだなー

 <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20171014/20171014160652.jpg" alt="f:id:masutaka26:20171014160652j:plain" title="f:id:masutaka26:20171014160652j:plain" class="hatena-fotolife" itemprop="image">

<ul>
<li> 速いだけでテンションが上がります</li>
</ul>
</li>
<li>golang 熱の高まり・・・！！

<ul>
<li> やりましょう！</li>
</ul>
</li>
<li>go モチベーションの高さの理由が分かりました！！

<ul>
<li> もう必死ですよ</li>
</ul>
</li>
<li>ずっと Go 書いてたのはこれだったのかー（棒）

<ul>
<li> そうなんですよー（棒）</li>
</ul>
</li>
<li>Go 書きたい

<ul>
<li> 今書きましょう！</li>
</ul>
</li>
<li>ゴー書いてく！！

 <img src="https://cdn-ak.f.st-hatena.com/images/fotolife/m/masutaka26/20171014/20171014160710.jpg" alt="f:id:masutaka26:20171014160710j:plain" title="f:id:masutaka26:20171014160710j:plain" class="hatena-fotolife" itemprop="image">

<ul>
<li> ｱ､ﾊｲ</li>
</ul>
</li>
<li>ざんねん！！わたし（@ryz310）の PR はここでおわってしまった！！

<ul>
<li> またお待ちしております！（笑）</li>
</ul>
</li>
<li>バイナリ配布うれしい！

<ul>
<li> ユーザの皆様のことを第一に考えております</li>
</ul>
</li>
<li>CLI は golang <del>Web やる気にはなら…</del>

<ul>
<li> 配布を考えるとそうですねー。今は GitHub でリリースしておけば、Homebrew や zplug など配布手段はいろいろありますし</li>
</ul>
</li>
<li>ディストリビューション大変だなー

<ul>
<li> gox で簡単に並列ビルドできるので、それほど大変ではなかったですね</li>
</ul>
</li>
<li>知見 ライブデプロイ is つらい

<ul>
<li> もうハラハラドキドキですよ</li>
</ul>
</li>
<li>ライブデプロイメント

<ul>
<li> やはり初回の CI は絶対失敗しますね...</li>
</ul>
</li>
<li>（社内 Slack の）#golang を今後ともよろしくお願いします

<ul>
<li> こちらこそ！</li>
</ul>
</li>
</ul>


<h2>最後に</h2>

とにかく設計が目下の悩みです。良い情報があれば教えてください！

こんにちは。増田（id:masutaka26）です。社内勉強会の順番が来ると、２ヶ月前くらいからソワソワしてきます。そんなわけで今回は『日報を golang で支える技術』というお題で発表しました。発表の内容以下、スライドからの抜粋です。背景など以前の社内勉強会で github-nippou という gem を紹介したひとつの ruby スクリプトからそこそこ作り込み、毎日便利に使っている先日も同僚の @ryz310 から pull request をもらって、さらに便利になったからの、golang への書き換えをした。その場でライブリリースモチベーション以前 hub コマンドが ruby から golang に移行したのを見て、一度やってみたかったrubygems の CLI を Dockerize してポータビリティを高めるのは何かが違うという気持ち@ryz310 からもらった元気当たり前だけど、全て代わりの方法を調べて実装しなければいけなかったoctokit → go-github, thor → cobra など。Assets の取り扱いも変わる良かったこと１バイナリになったのでインストールやアップデートが容易になったパフォーマンスも予想外に上がった（当社比約２倍）以前調べた時は GitHub への API アクセスがボトルネックだったので、そこまで変わらないと思っていた結果的にいろんなライブラリを使えて、良い素振りになった困ったこととにかく関数が長くなりがちgetXXX() 多くなりすぎファイル分割の意味書けば書くほど golang っぽい書き方が分からなくなるOOP ではないことへの戸惑いruby が柔軟すぎて移植は難しかった。オススメはしない疑問などclass設計で便利だった、private method の代わり設計し直すべきかclassを 使わなかった頃の JS の知見を知りたいビジネスロジックのパッケージ名はどうすれば今回は lib にした感想今後、rubygems で CLI ツールを作ることはないと思う。継続利用を考えると勧めづらいgolang は単一ファイルでの実装と実行に一番ハードルが低い気がしているもっと楽な言語あったら教えて今後の予定golang っぽい書き方にするもっとテストを書くgolang on Lambda や API サーバも学習する『スターティングGo言語』を読み切る結果↓https://github.com/masutaka/github-nippou発表の感想付箋紙に感想を書いてくれました。 は私からのコメントです。クラス設計周りの話は自分も悩んでいます ライブラリとか読んで学習します！GraphQL 対応の PR 出すぞ お待ちしております！Go の GraphQL のクライアント側はまだなさそう github.com/graphql-go/graphql を見つけました。API リクエストを 1 回に出来るのかな？CLI は ruby < golang わかる。mruby も良いかも mruby はエコシステムが大変そうで...Makefile 参考にします あざす！Makefile 全く分からない... 勉強しないと！！ 基本だったら１日くらいで分かりますよ。make はビルドを必要な時だけに抑えられるので良いです流石ますたかさん とても面白く熱量ある発表でした ありがとうございます。熱量は大事にしてます神回ですね もっと技術レベル上げていきます！刺激を受けるいい話だった 刺激を与えるのがエンジニアとして使命のひとつだと思っていますスピード up は nice 発見 ですねやっぱりはやくなるものなんだなー 速いだけでテンションが上がりますgolang 熱の高まり・・・！！ やりましょう！go モチベーションの高さの理由が分かりました！！ もう必死ですよずっと Go 書いてたのはこれだったのかー（棒） そうなんですよー（棒）Go 書きたい 今書きましょう！ゴー書いてく！！ ｱ､ﾊｲざんねん！！わたし（@ryz310）の PR はここでおわってしまった！！ またお待ちしております！（笑）バイナリ配布うれしい！ ユーザの皆様のことを第一に考えておりますCLI は golang Web やる気にはなら… 配布を考えるとそうですねー。今は GitHub でリリースしておけば、Homebrew や zplug など配布手段はいろいろありますしディストリビューション大変だなー gox で簡単に並列ビルドできるので、それほど大変ではなかったですね知見 ライブデプロイ is つらい もうハラハラドキドキですよライブデプロイメント やはり初回の CI は絶対失敗しますね...（社内 Slack の）#golang を今後ともよろしくお願いします こちらこそ！最後にとにかく設計が目下の悩みです。良い情報があれば教えてください！

github-nippou という gem を golang で書き直したという発表をした

この記事は feedforce Advent Calendar 2016 の 14 日目の記事です。
13 日目はハッシーの『フィードフォースでの映像制作について 』でした。
彼らがつい二週間前にリリース(?)したシンゴジラのパロディムービーは、
密かに今までで一番のお気に入りです。社内限定で今までのムービー見ら
れないかなー。
さて、私も表題の年齢になり、季節の変わり目はひどい肩こりや頭痛に悩
まされる日が出てきました。普段は気になりませんが、この時だけはたま
らず整体に行きます。あまりにひどいと寝込んでしまうことも。
とは言え、昔から体だけは丈夫で、体調が悪くなることはそうそうありま
せん。寝込むのは年に一度くらい。あと二日酔い。二日酔いツライ。
ただ、体が冷えるとあっさり風邪を引くことが分かってきたので、会社で
は毛布モドキを被り、家では着ぐるみモドキ を履き、だいぶ気を付けてい
ます。
10 月のあの日もそうでした。急に気温が下がり、肩がこり、こりゃ風邪
引くかなーと思っていたところ、何の気なしに湯船にお湯を張り風呂に入
りました。１年前に引っ越してから初めての風呂です（汚くはない）。
そしたらびっくり。肩こりがすーっと消え、体もポカポカです。その日を
境に、週に何度か風呂に入る日が始まりました。
どのようにして風呂に入るか 詳しく説明させて頂きます。
何はなくともまずは掃除です。今の部屋に引っ越してから、CaSy に月一
で来てもらっている [2015-12-27-1] ので、基本的にはきれいです。でも
入る前の掃除はもちろんします。
掃除が終わったらお湯を溜めます。10 月だと 44 度、今だったら 45 度
くらいを 10 分ですね。私は昔から熱い風呂は好きではないのですが、風
呂の蓋は買ってないので設定温度は熱めです。
未だにお湯張りタイマーの使い方が分かりません。一度、90 リットルの
つもりが、90 度のお湯を溜めてしまい、泣きながら水で薄め続けました。
お湯が溜まったら速やかに風呂に入ります。iPhone をドアの外に置き、
静かな音楽をかけます。給水用のお茶や水も置きます。間違ってもついで
の洗濯は止めましょう。静かな音楽が台無しです。
軽くお湯で体を流し、湯船にゆっくりと浸かります。歯磨きをするのも良
いでしょう。
適度に暖まったら体を洗います。朝の忙しい時間ではないので、ゆっくり
出来るのが良いですね。洗い終わったらまた湯船に浸かります。この辺で
給水するのも良いでしょう。
次は頭を洗います。最近は意識高いので、３日に一度はこちらで皮脂をズ
ビっと落としています。リンスやコンディショナー必須。
それ以外はこちらを使っています。逆に皮脂を落としすぎないシャンプー
です。リンスやコンディショナー不要です。前々職の先輩に教えてもらい
ました。
どちらも安くないですが、一日あたりに換算すると大したことないので、
ここ数年使っています。
顔を洗いつつ髭を剃ったら、最後の湯船です。風呂で髭を剃る人って、ど
のくらいいるのですかね？
出る時に潔くお湯を捨てます。以前は洗濯に使っていましたが、水道代が

この記事は feedforce Advent Calendar 2016 の 14 日目の記事です。13 日目はハッシーの『フィードフォースでの映像制作について 』でした。彼らがつい二週間前にリリース(?)したシンゴジラのパロディムービーは、密かに今までで一番のお気に入りです。社内限定で今までのムービー見られないかなー。さて、私も表題の年齢になり、季節の変わり目はひどい肩こりや頭痛に悩まされる日が出てきました。普段は気になりませんが、この時だけはたまらず整体に行きます。あまりにひどいと寝込んでしまうことも。とは言え、昔から体だけは丈夫で、体調が悪くなることはそうそうありません。寝込むのは年に一度くらい。あと二日酔い。二日酔いツライ。ただ、体が冷えるとあっさり風邪を引くことが分かってきたので、会社では毛布モドキを被り、家では着ぐるみモドキ を履き、だいぶ気を付けています。10 月のあの日もそうでした。急に気温が下がり、肩がこり、こりゃ風邪引くかなーと思っていたところ、何の気なしに湯船にお湯を張り風呂に入りました。１年前に引っ越してから初めての風呂です（汚くはない）。そしたらびっくり。肩こりがすーっと消え、体もポカポカです。その日を境に、週に何度か風呂に入る日が始まりました。どのようにして風呂に入るか 詳しく説明させて頂きます。何はなくともまずは掃除です。今の部屋に引っ越してから、CaSy に月一で来てもらっている [2015-12-27-1] ので、基本的にはきれいです。でも入る前の掃除はもちろんします。掃除が終わったらお湯を溜めます。10 月だと 44 度、今だったら 45 度くらいを 10 分ですね。私は昔から熱い風呂は好きではないのですが、風呂の蓋は買ってないので設定温度は熱めです。未だにお湯張りタイマーの使い方が分かりません。一度、90 リットルのつもりが、90 度のお湯を溜めてしまい、泣きながら水で薄め続けました。お湯が溜まったら速やかに風呂に入ります。iPhone をドアの外に置き、静かな音楽をかけます。給水用のお茶や水も置きます。間違ってもついでの洗濯は止めましょう。静かな音楽が台無しです。軽くお湯で体を流し、湯船にゆっくりと浸かります。歯磨きをするのも良いでしょう。適度に暖まったら体を洗います。朝の忙しい時間ではないので、ゆっくり出来るのが良いですね。洗い終わったらまた湯船に浸かります。この辺で給水するのも良いでしょう。次は頭を洗います。最近は意識高いので、３日に一度はこちらで皮脂をズビっと落としています。リンスやコンディショナー必須。それ以外はこちらを使っています。逆に皮脂を落としすぎないシャンプーです。リンスやコンディショナー不要です。前々職の先輩に教えてもらいました。どちらも安くないですが、一日あたりに換算すると大したことないので、ここ数年使っています。顔を洗いつつ髭を剃ったら、最後の湯船です。風呂で髭を剃る人って、どのくらいいるのですかね？出る時に潔くお湯を捨てます。以前は洗濯に使っていましたが、水道代が

不惑の年に風呂の良さを知った

赤枠がソーシャルPLUS のコメントウィジェット。全然違和感がない。
今までその下にある Zenback の Facebook コメントフォームを有効にし
てましたが、使われませんし飽きてきました。ちなみにその前は DISQUS で[2010-05-03-1] 、その前はくっつきBBS でした[2008-09-29-1] 。
まだ Twitter ログインにしか対応していませんが、これから各種ソーシャ
ルログインに対応していくかも？
本当はメイン機能であるログインと繋ぎ込みをしたり、他のウィジェット
（アクションボタン、シェアウィジェット、プロバイダーボタンバー、ア
クティビティウィジェット等）もフルで使いたかったのですが、このブロ
グが静的サイトということもあり面倒になって止めました。

赤枠がソーシャルPLUS のコメントウィジェット。全然違和感がない。今までその下にある Zenback の Facebook コメントフォームを有効にしてましたが、使われませんし飽きてきました。ちなみにその前は DISQUS で[2010-05-03-1] 、その前はくっつきBBS でした[2008-09-29-1] 。まだ Twitter ログインにしか対応していませんが、これから各種ソーシャルログインに対応していくかも？本当はメイン機能であるログインと繋ぎ込みをしたり、他のウィジェット（アクションボタン、シェアウィジェット、プロバイダーボタンバー、アクティビティウィジェット等）もフルで使いたかったのですが、このブログが静的サイトということもあり面倒になって止めました。

ドッグフーディングを始めてみた

[2014-10-20-1] に引き続き、会社の技術ブログを書きました。
Vagrantで簡単に作れる！！RubyやKyotoTycoonのrpmたち｜feedforce Engineers&rsquo; blog CentOSを本番環境で使っている方は、Rubyのバージョンアップはどうして
いるんですかね？
rbenvを使っているところもあるのかな。記事にも書いたけど、それだと
サーバのCIは使いものにならないけど。
最近はサーバのCIやDockerのおかげか、低レイヤーな技術が見直されてい
る気がします。前者は今回のrpm、後者はシェルスクリプト。
個人的には地味な技術は好きなのでちょっとうれしい。

[2014-10-20-1] に引き続き、会社の技術ブログを書きました。Vagrantで簡単に作れる！！RubyやKyotoTycoonのrpmたち｜feedforce Engineers’ blog CentOSを本番環境で使っている方は、Rubyのバージョンアップはどうしているんですかね？rbenvを使っているところもあるのかな。記事にも書いたけど、それだとサーバのCIは使いものにならないけど。最近はサーバのCIやDockerのおかげか、低レイヤーな技術が見直されている気がします。前者は今回のrpm、後者はシェルスクリプト。個人的には地味な技術は好きなのでちょっとうれしい。

会社の技術ブログを書きました(3回目)

[2014-08-09-1] に引き続き、会社の技術ブログを書きました。
JenkinsでサーバのCIを始めました｜feedforce Engineers&rsquo; blog ネタ的には新しくはないのですが、フィードフォースのエンジニアが今今
どんなことをしているかを伝えたくて書きました。
こういう記事を投稿し続けていけば、興味あるエンジニアの目に止まるん
じゃないかと。
弊社は最近採用に力を入れています。
結構気軽に会いにいけるので、興味ある方はどうぞ☆
フィードフォースは「会いにいける！」ベンチャーです！(社長指名可) - 株式会社フィードフォースの求人 - Wantedly Rubyで開発したいエンジニアをウォンテッド！（土日面談／スカイプ面談可） - 株式会社フィードフォースの求人 - Wantedly 【株式会社フィードフォースの求人】 【自社サービス開発／新規事業立ち上げ／残業10H以内／土日面談可】Webエンジニア - Forkwell Jobs 

[2014-08-09-1] に引き続き、会社の技術ブログを書きました。JenkinsでサーバのCIを始めました｜feedforce Engineers’ blog ネタ的には新しくはないのですが、フィードフォースのエンジニアが今今どんなことをしているかを伝えたくて書きました。こういう記事を投稿し続けていけば、興味あるエンジニアの目に止まるんじゃないかと。弊社は最近採用に力を入れています。結構気軽に会いにいけるので、興味ある方はどうぞ☆フィードフォースは「会いにいける！」ベンチャーです！(社長指名可) - 株式会社フィードフォースの求人 - Wantedly Rubyで開発したいエンジニアをウォンテッド！（土日面談／スカイプ面談可） - 株式会社フィードフォースの求人 - Wantedly 【株式会社フィードフォースの求人】 【自社サービス開発／新規事業立ち上げ／残業10H以内／土日面談可】Webエンジニア - Forkwell Jobs

会社の技術ブログを書きました(2回目)

アジャイル開発で便利だったホワイトボードなどまとめ｜feedforce Engineers&rsquo; blog 先週の話ですが。
3月に入社して早5ヶ月。
何度か書く書く詐欺してましたが、ようやく書きました。
特に奇をてらったわけではなく、自分が興味あることをまとめただけ。
このブログも同じです。
良い記事が書けると、何度も読み返したくなりますね。
自分が一番の読者です。
次回は技術の話を書く。

アジャイル開発で便利だったホワイトボードなどまとめ｜feedforce Engineers’ blog 先週の話ですが。3月に入社して早5ヶ月。何度か書く書く詐欺してましたが、ようやく書きました。特に奇をてらったわけではなく、自分が興味あることをまとめただけ。このブログも同じです。良い記事が書けると、何度も読み返したくなりますね。自分が一番の読者です。次回は技術の話を書く。

初めて会社の技術ブログを書きました

3月に入社し[2014-03-09-1] 、先月が弊社フィードフォース の期の終わりで
した。そして今日が納会(※)。運良く、ルーキー賞(の1人)に選ばれました。
※ 納会が年末以外にもあることにビックリ。
何度かお話しましたが、私の能力が云々という話では全くなくて、単純に
タイミングが良かっただけだと感じています。
納会を企画したイベントチーム、ならびに私を選んで頂いた方、業務でお
世話になった方、その他もろもろありがとうございました。
組み込み業界から前職ラングリッチ に飛び込んだ時[2011-04-22-1] 、意外
にも今までの経験がちょいちょい役に立ちました。
今のフィードフォースでは、あの時以上にタイミングよく、皆さんのお役
に立てたようで嬉しいです。自分の成長と会社の成長が、いい感じに重なっ
たというか。
役に立ったと思われるのは以下のとおり。
・アジャイル開発の経験
・チームビルディング
・GitHub的ななにか
・Rails&amp;Rspec全般
・Chef&amp;Serverspec全般
・ELF的な知識
地固めが出来たので、これからはより技術的なことに挑戦していきます。
ぶっちゃけ、そちらに関しては他の開発者の方のほうが詳しいので、その
辺は教えを請いつつ学びつつ、チームの力を伸ばしていくことに集中します。
私個人も成長しますが、チーム力を高めたほうがなにかと早いので。
今後ともよろしくお願いします。

3月に入社し[2014-03-09-1] 、先月が弊社フィードフォース の期の終わりでした。そして今日が納会(※)。運良く、ルーキー賞(の1人)に選ばれました。※ 納会が年末以外にもあることにビックリ。何度かお話しましたが、私の能力が云々という話では全くなくて、単純にタイミングが良かっただけだと感じています。納会を企画したイベントチーム、ならびに私を選んで頂いた方、業務でお世話になった方、その他もろもろありがとうございました。組み込み業界から前職ラングリッチ に飛び込んだ時[2011-04-22-1] 、意外にも今までの経験がちょいちょい役に立ちました。今のフィードフォースでは、あの時以上にタイミングよく、皆さんのお役に立てたようで嬉しいです。自分の成長と会社の成長が、いい感じに重なったというか。役に立ったと思われるのは以下のとおり。・アジャイル開発の経験・チームビルディング・GitHub的ななにか・Rails&Rspec全般・Chef&Serverspec全般・ELF的な知識地固めが出来たので、これからはより技術的なことに挑戦していきます。ぶっちゃけ、そちらに関しては他の開発者の方のほうが詳しいので、その辺は教えを請いつつ学びつつ、チームの力を伸ばしていくことに集中します。私個人も成長しますが、チーム力を高めたほうがなにかと早いので。今後ともよろしくお願いします。

会社でルーキー賞に選ばれた

【学生無料！】【Railsセミナー】Why choose Ruby on Rails ? : ATND 弊社フィードフォースの応援要員として、メンバーズ様主催のRailsセミナーに行ってきました。メモ程度ですが軽く記録しときます。
◆第1部 名刺管理アプリ「Eight」を育てるチームと技術
Sansan株式会社 宍倉功一さん
法人向けのSanSanは.NETだが、個人向けのEightはRailsを採用。
spider for MySQL使うとテーブル単位でDB分割できて便利。
SLASHで効果測定。新人研修は徳島の一軒家で2週間。
高負荷サービスの話聞けてよかった。
◆第2部 Railsとアジャイルで変える受託開発
株式会社メンバーズ 木村壮介さん
CircleCIでfeature branchをHerokuに継続deploy - Masatomo Nakano Blog みたいなdeapというツール良かった。受託の関係でHerokuではなく、自社サーバを使うんだっけかな？
◆第3部 変化を産み出すための組織文化作り
株式会社フィードフォース 鈴木龍さん
他の発表より生々しい感じで存在感を出せてた感。途中の「お金は大事だよー」の画像とか、HipChatの実際のチャットとか追加されてて、数日前の素振りよりもすごく良くなってた。
◆第4部 国内最大級のクラウドソーシングサービス「クラウドワークス」のつくりかた
株式会社クラウドワークス 大場光一郎さん
CIはJenkinsツライのでSEMAPHORE を採用。
Amazon Redshift(分散RDBS)を使用。
分析用のプラットホームに向いてる Hadoopに似てる FlydataでRedShiftに転送
なぜCircleCIじゃなくてSEMAPHOREを採用したのでしょう？と質問したら、無料期間中に最後までテスト出来たのがSEMAPHOREだけだったからとのこと。CircleCI含めた他のサービスはは15分以上かかるテストkillされてしまったらしい。 ◆懇親会
何人かの方とお話出来た。弊社のメンバー多めだったけど。。
大場さんと話すのがちょっとした目的だったので、ホント来た甲斐がありました。
loading...
loading...
ちなみに私が大場さんを認識したのは[2007-10-04-1] でした。しかもここ、メンバーズさんのサイトでした。いろいろ繋がります。ちょっと見ると、ソニックガーデン興す前の倉貫さんもいらっしゃる。

【学生無料！】【Railsセミナー】Why choose Ruby on Rails ? : ATND 弊社フィードフォースの応援要員として、メンバーズ様主催のRailsセミナーに行ってきました。メモ程度ですが軽く記録しときます。◆第1部 名刺管理アプリ「Eight」を育てるチームと技術Sansan株式会社 宍倉功一さん法人向けのSanSanは.NETだが、個人向けのEightはRailsを採用。spider for MySQL使うとテーブル単位でDB分割できて便利。SLASHで効果測定。新人研修は徳島の一軒家で2週間。高負荷サービスの話聞けてよかった。◆第2部 Railsとアジャイルで変える受託開発株式会社メンバーズ 木村壮介さんCircleCIでfeature branchをHerokuに継続deploy - Masatomo Nakano Blog みたいなdeapというツール良かった。受託の関係でHerokuではなく、自社サーバを使うんだっけかな？◆第3部 変化を産み出すための組織文化作り株式会社フィードフォース 鈴木龍さん他の発表より生々しい感じで存在感を出せてた感。途中の「お金は大事だよー」の画像とか、HipChatの実際のチャットとか追加されてて、数日前の素振りよりもすごく良くなってた。◆第4部 国内最大級のクラウドソーシングサービス「クラウドワークス」のつくりかた株式会社クラウドワークス 大場光一郎さんCIはJenkinsツライのでSEMAPHORE を採用。Amazon Redshift(分散RDBS)を使用。分析用のプラットホームに向いてる Hadoopに似てる FlydataでRedShiftに転送なぜCircleCIじゃなくてSEMAPHOREを採用したのでしょう？と質問したら、無料期間中に最後までテスト出来たのがSEMAPHOREだけだったからとのこと。CircleCI含めた他のサービスはは15分以上かかるテストkillされてしまったらしい。 ◆懇親会何人かの方とお話出来た。弊社のメンバー多めだったけど。。大場さんと話すのがちょっとした目的だったので、ホント来た甲斐がありました。loading...loading...ちなみに私が大場さんを認識したのは[2007-10-04-1] でした。しかもここ、メンバーズさんのサイトでした。いろいろ繋がります。ちょっと見ると、ソニックガーデン興す前の倉貫さんもいらっしゃる。

Railsセミナーに行ってきた #railssemi

去年の11月14日にラングリッチ を退職しました。
退職は人生２回目で[2011-04-22-1] のメタテクノ以来です。
組み込み業界出身でWebの知識があまりない私を受け入れてくれたラングリッ
チには、本当に感謝しております。
今回の退職と転職活動では、多くの方にご心配とご迷惑をお掛けしました。
この場を借りてお礼とお詫びを申し上げます。
ラングリッチを振り返る 当時のラングリッチは会社設立からちょうど1年、サービスがローンチされ
てから9ヶ月経ったあたりでした。
社員はまだいなかったので、社員番号一桁 どころか社員第一号でした。
社員番号などない的な。
当時起きたことをまとめてみました。
2010年7月17日 ラングリッチ誕生
2010年8月5日 ラングリッチのプロモアカウントに捕捉される。 多分このツイート をした
から。
2010年8月25日 ラングリッチのレッスンを初受講。 滝のような汗は出たが、かなり面白かっ
たのでレッスンを毎日受け続けることに！(元々私、ラングリッチの生徒だっ
たんです。こんな記事も[2010-12-19-1] )
2011年1月1日 ラングリッチのtomoyaさんにTwitterのダイレクトメッセージでコンタクト
をとり、後日Skypeのチャットでいろいろお話。
2011年3月2日 メタテクノ最終出社日
2011年3月3日 有給消化期間を満喫し始める。
2011年3月11日 14:46に東日本大震災発生。15:00からラングリッチのレッスンが始まって
しまった(キャンセルはレッスン開始1時間前までw)。停電のためiPhoneの
Skypeを使って、プライ先生に実況中継。
2011年3月15日 地震の混乱が収まらない中、関西空港でtomoyaさんと落ち合いフィリピン
はセブ島にGO!!
2011年4月1日 サービスの裏側やフィリピンを体験して帰国。この辺からラングリッチの
カスタマーサポートのお手伝い開始。開発にも着手し始める。
2011年4月21日 メタテクノ退職日
2011年4月27日 川崎から引っ越し。西明石行きの夜行バスに乗る。
2011年4月28日 荷物が来るまでCEOの家に居候。
2011年5月2日 荷物が来て、オフィス兼住居への引越し完了。
ラングリッチでは本当に色々なことを学びました。スタートアップの黎明
期からの成長っぷりを体験できたことはもちろんですし、東京に進出して
からは、アジャイル開発、TDD、まともなWebアプリケーションの作り方等、
これらは今も自分の資産となっております。
最後の大きなプロジェクトはラングリッチへの恩返しのつもりで、全てを
出し尽くしました。しかしこれが本当に大変で、期日までに終わるのかと
いう不安があり昼夜問わず開発していたため、2ヶ月間の総コミット数は
637にもなりました。
※表示が変ですが、2013年8月31日から2013年11月1日の総コミット数です。
もちろんこれは開発者の皆さんだけでなく、関係者全員のご協力のおかげ
です。そもそもPull Request見てくれる人がいないと成立しないですし。
開発内で言うと、セキュリティチェック、サーバ構築、フロントエンド、
要件整理等、自然に役割分担されていきました。あ、オレこれやるわ的な。
私はアプリ側を実装したため、コミット数が膨れ上がったというわけです。
退職後 前回と違って、退職後は悠々自適の生活&hellip;とはいかず、転職活動をしてい

去年の11月14日にラングリッチ を退職しました。退職は人生２回目で[2011-04-22-1] のメタテクノ以来です。組み込み業界出身でWebの知識があまりない私を受け入れてくれたラングリッチには、本当に感謝しております。今回の退職と転職活動では、多くの方にご心配とご迷惑をお掛けしました。この場を借りてお礼とお詫びを申し上げます。ラングリッチを振り返る 当時のラングリッチは会社設立からちょうど1年、サービスがローンチされてから9ヶ月経ったあたりでした。社員はまだいなかったので、社員番号一桁 どころか社員第一号でした。社員番号などない的な。当時起きたことをまとめてみました。2010年7月17日 ラングリッチ誕生2010年8月5日 ラングリッチのプロモアカウントに捕捉される。 多分このツイート をしたから。2010年8月25日 ラングリッチのレッスンを初受講。 滝のような汗は出たが、かなり面白かったのでレッスンを毎日受け続けることに！(元々私、ラングリッチの生徒だったんです。こんな記事も[2010-12-19-1] )2011年1月1日 ラングリッチのtomoyaさんにTwitterのダイレクトメッセージでコンタクトをとり、後日Skypeのチャットでいろいろお話。2011年3月2日 メタテクノ最終出社日2011年3月3日 有給消化期間を満喫し始める。2011年3月11日 14:46に東日本大震災発生。15:00からラングリッチのレッスンが始まってしまった(キャンセルはレッスン開始1時間前までw)。停電のためiPhoneのSkypeを使って、プライ先生に実況中継。2011年3月15日 地震の混乱が収まらない中、関西空港でtomoyaさんと落ち合いフィリピンはセブ島にGO!!2011年4月1日 サービスの裏側やフィリピンを体験して帰国。この辺からラングリッチのカスタマーサポートのお手伝い開始。開発にも着手し始める。2011年4月21日 メタテクノ退職日2011年4月27日 川崎から引っ越し。西明石行きの夜行バスに乗る。2011年4月28日 荷物が来るまでCEOの家に居候。2011年5月2日 荷物が来て、オフィス兼住居への引越し完了。ラングリッチでは本当に色々なことを学びました。スタートアップの黎明期からの成長っぷりを体験できたことはもちろんですし、東京に進出してからは、アジャイル開発、TDD、まともなWebアプリケーションの作り方等、これらは今も自分の資産となっております。最後の大きなプロジェクトはラングリッチへの恩返しのつもりで、全てを出し尽くしました。しかしこれが本当に大変で、期日までに終わるのかという不安があり昼夜問わず開発していたため、2ヶ月間の総コミット数は637にもなりました。※表示が変ですが、2013年8月31日から2013年11月1日の総コミット数です。もちろんこれは開発者の皆さんだけでなく、関係者全員のご協力のおかげです。そもそもPull Request見てくれる人がいないと成立しないですし。開発内で言うと、セキュリティチェック、サーバ構築、フロントエンド、要件整理等、自然に役割分担されていきました。あ、オレこれやるわ的な。私はアプリ側を実装したため、コミット数が膨れ上がったというわけです。退職後 前回と違って、退職後は悠々自適の生活…とはいかず、転職活動をしてい