Pixela をSlackにつないで遊んでみた

小ネタ。
昨日が〜〜〜っとコーディングして、寝て、起きたのでブログです。

土曜日くらいから、たまたまSlackを題材にJSのお勉強!をしていて(それについては別途書く)、おもしれ〜少しわかってきたぞ〜〜となり、「他になにか作ろう〜〜」って気分でいたのですが、Twitterを眺めていたらあまりにもpixelaが盛り上がっていたので勢いで作ってみました。

blog.a-know.me

やったこと

Slack上で

  1. ユーザー登録ができて
  2. グラフの新規作成ができて
  3. グラフのインクリメントができる
  4. グラフ一覧も取得できる

必要最低限、って感じ。機能を絞ってインターフェイスをシンプルにした感じのv0.1。

ユーザー登録

  1. @bot pixela me とダイレクトメンションしたら起動
  2. tokenを自動生成する
  3. POST /v1/users を叩く
  4. SlackのユーザーID、Pixelaのusername,tokenを紐づけてDBに保存しておく
  5. 処理完了後、発話者のみ見える形でusername,tokenをSlack上に通知

この「SlackのユーザーIDと紐づけて格納して、実際のサービス(Pixela)のアカウント情報を隠蔽する」ってやり方が、何ともチャットbotぽいな〜とか思ったり。

イメージ

f:id:o0h:20181016124952p:plain

シーケンス

f:id:o0h:20181016125234p:plain

グラフ登録

  1. @bot pixela new とダイレクトメンションしたら起動
  2. 発話者のSlackユーザーIDをもとに、DBからPixela登録情報を引っ張ってくる
  3. conversationのセッションを開始
    • 対話的に「グラフID」「グラフ名」を入力する
    • グラフの詳細なオプション(色、単位、値の型)は現状だと省略。shibafu/cnt/intに固定
  4. POST /v1/users/<username>/graphsを叩く
  5. 処理完了後、登録された情報をリプライ

イメージ

f:id:o0h:20181016133859p:plain

シーケンス

f:id:o0h:20181016131700p:plain

インクリメント

  1. @bot pixela ${グラフID}++ とダイレクトメンションしたら起動
  2. 発話者のSlackユーザーIDをもとに、DBからPixela登録情報を引っ張ってくる
  3. PUT /v1/users/<username>/graphs/<graphID>/increment を叩く
  4. 処理完了後、操作対象となったグラフのURLをリプライ

イメージ

f:id:o0h:20181016132001p:plain

シーケンス

f:id:o0h:20181016131933p:plain

グラフ一覧

  1. @bot pixela list とダイレクトメンションしたら起動
  2. 発話者のSlackユーザーIDをもとに、DBからPixela登録情報を引っ張ってくる
  3. GET /v1/users/<username>/graphs を叩く
  4. 処理完了後、登録されているグラフの一覧をリプライ

イメージ

f:id:o0h:20181016132231p:plain

シーケンス

f:id:o0h:20181016132338p:plain

やっていないこと

概ね「対応してないエンドポイント」「対応していないパラメータ」も面白く使えるようにしたい・・というのがほとんど。 あとは、SVG to PNGを行うためのサーバーを自前で持つか何かをしたら、インクリメント後とか、サムネイル出せるようになるよな〜絶対にそのほうが楽しいよな〜という気持ち。。

あとは、グラフの登録のところ、ひっさびさにBotkitのconversationを使ってみたけどイマイチ・・・Interactive componentにしてフォームで入れたほうが便利っぽいな。

感想など

何個かSlackのbotを作っていて、「いまいち使う楽しさに欠ける」というのはインターフェイスの問題な事が非常に多いなと思っています。要するに「呼び出し方がわからない」「フォーマットが複雑」など。そこに関して、今回は 「私にPixelaを使わせろ!」という意味の me でアカウント登録、ほとんど"graph"がすべてのサービスにおいて「新しく始めるよ!」という意味の new で新規作成、 ++ でインクリメント・・・と、だいぶシュッとしたコマンドをデザインできたかな?という気持ち。

サービスを触っていて思ったのは、単機能&RESTFulなAPIデザイン素敵すぎる。ほとんどドキュメントは流し読みで、実際に動くところまで行けた!!というのが最高の体験でした・・・

正直、最初に見た時に「草が生えるよ!」というサービスって嬉しいか・・?とピンと来てなかったのだけど。数時間後に開いたTwitterで、たまたま別のツイートが目に入ってきて、「Slackに結びつけたら面白いかも?」と思ってから一気に書きました。
「とりあえず動かしてみたら面白いんじゃねwww」くらいのノリでさくさく〜っとマッシュアップできるサービスとかアイディアっていうのはストレス解消に良いですね・・・👼

今のとこ会社のSlackに置こうとしているだけだけど、もーちょい汎用化できたらOSS化するのはアリだよな〜とか。Storage周りどうしよーっていうとこだけ悩まし。
とりあえず、今やりたいのは「運動習慣をつけたい人たちが、運動をしたら報告するチャンネル」があるので「運動したら草を早そう」を盛り上げたいw

フレームワークとどこまで骨を埋めるか問題 ( #phpgenba を聞いて)

問題〜とか言いつつ何も答えが出てない、どころかissueを見定められてないけど。ただの散文です。

#phpgenba を聞きまして。

php-genba.shin1x1.com

「フレームワークとの付き合い方」というトピックがありました。
これについて。正解もないし、良い視点で主張や議論ができるほどの経験値もないと思っているのだけど、まぁ「今の時点で感じていること」を言語化して残して置くことには面白い点もあると思うので。

「どこまでフレームワークの機能を使うか」「(自身で層を敷いて)線引き、責務分離をした上で付き合った方が辛くなりにくい」という話がありました。
DDD、クリーンアーキテクチャの立場から「実装と詳細の分離」という思想と捉えて良いのかな。

その感想を、今の自分なりに。
なお、ここでは「チームで開発する」とした時の「価値」を「自分だけでなく他人も書きやすい・読みやすい・分かりやすい」こと、と定義して思考します。
それを支える要素としては、

  1. PJ全体を通じてブレがない
  2. 具体的なプラクティスやディスカッションを多く仕入れやすい

というのがあると良いな、と思います。

さて、個人的には フレームワークを使うと決めたら、骨の髄までその流儀に乗っかって、旨みを享受する方が美味しい のでは、という立場。*1

支払った学習コストに対して横展開がきくので、少なくとも短期的にはスピードが出る。新規者において、公のソース*2から得られる情報の大きさゆえの学びやすさからだし、同じ理由で、既存メンバーからの指導のしやすがあるから。
この辺りは分かりやすいから良いにしても、自分なりに疑問なのが「フレームワークにロックインされる」ことがどれくらいリスク足り得るか?について。

podcast中で「新しくバンバンwebサービスが立ち上がって行くフェーズから、数年経ったプロジェクトやコードベースをお世話する場面が増えてきた。その背景があって、DDDやクリーンアーキテクチャといった概念が注目されるようになっめきたのではないか」という観点。これは、なるほどなーと思い、賛成で。

他方で、「ドメインに関しては依存したくない」「こっちはフレームワークの機能を使わないレイヤー、というのを決めて置くとうまくいきやすい」のかな?という部分。*3

さて、自分の場合において、「今書いているコードが5年生き残った場合に、(フレームワークべったりか否かで)どっちが親切で説得力があるか」をどう考えれば良いか。

まず、自分が充分に経験を積んだアーキテクト足りえるか?は大きい気がする。要するに、「辛い体験」の経験不足。これは否定しようがないし、今はその「身の丈」で物事を考えなければいけない。
その上で、「世界中で使われているOSSの設計者やコミュニティのほうが、質の高い"良さ"を持っているはずだ」という公算が高かろうな〜と思うところで。
私が考えたデザインと、フレームワークそのものが、「5年後に生き延びていて、かつ良くメンテナンスされている」ことの期待値はどっちが高い・・?

プログラマーは、概して、その本質として「自分の力より高い次元のことを要求される」ものだよな〜とは時々思う。もちろん出来る範囲のことでしかできないのだけど、もし「もっと出来たら」もっと良いデザインや良いやり方で「正解」を出すだろうなーっていう。
そう考えると、「自分の持つ実力を出せる方法があれば、そうしたい」という欲求が生まれる。巨人の方に乗る方法があれば、そうするのが賢いと思う。

自分の中で「フレームワークにのっかり、しゃぶりつくす」というのはそのための方法論の1つ・・・そして、「他のフレームワークに移るときのコストが」という話についても、(今の自分の考えでは)「そのタイミングというのは、これまでの常識で太刀打ちできない要求の変化が起きた」というトリガーがあると想像する。
奇しくも、短いような短くないような職業プログラマ歴の中で、自分は前職と現職で1度ずつ「フルスクラッチの改修」に関わっている。その時に、既存コードの部品を流用しようとはならなかった*4。なので、「この機能を使っちゃうと後々困るかもね」という懸念で、「フレームワークのフルパワーを引き出しながら日々の業務に取り組む」メリットを殺しに行くかなぁ〜というのが、あまりイメージできないなーと。。。正確に言えば、「ここからは独自に」という線引きをするための知識・経験・センスが足りていない・・・のかな。

と、書きながら、程度問題は絶対にあるなとも思った。
それでもソフトウェア/フレームワーク以上のレイヤーで「よくある」かはまだわからないのだけど、例えばデータベースの移行はつらそうだなぁ。。
「mongoすごい!使おう!!」「スキーマレス最高!!多次元構造最高!!」「スケールしていったらつらみが・・」「乗り換えるか・・・?」とかは、一筋縄ではいかないだろうなぁ。


今の自分の武器に盲目的になることはせず、守備範囲内外へのアンテナを貼りつつ、良いもの・悪いもののどちらも正しく批判しつつ、使う道具にはリスペクトを持つ!!

というスタンスでいたい。

*1:数年後には揺り戻しが来るだろうな〜という予感はする・・あくまで、今においてはというもの。

*2:githubも、slackなどのチャットも、stackoverflowもqiitaも。「ググれば出てくる」こと。

*3:この流れで出てきた、「節度」「治安」というのは良い概念だな〜と思いました

*4:cake2 -> cake3の移行は、「同じフレームワークの移行」とは数えないのが正解な気がする・・概念等は共有されているので、キャッチアップについては下駄を履けるのだけど、コードをそのまま使えるか?は・・

やったこと・書いたもの{2018,9}

会社ブログ

OSS

勉強会・LT

へーしゃとランサーズさんで合同勉強会ランチ的な催しを開いてくれました。その時のやつ。(cake縛りのLT会めったにないから嬉しい

herokuでphp動かすためのDockerイメージを組んだ

「herokuでDocker使えるよ」って言うから試そうとしたらハマった - 大好き!にちようび というものを書いたじゃないですか。 あれ以来、「一旦Container registryでやるの諦めてアプリケーションだけ書いちゃおう・・・」となり放置、さらに他のことに浮気をしたりが重なりアプリケーション自体も書いていなかったのですが。

他のことが消化されたり、というのもあったので「久々に作るかー」となり起動したのでした。

で、結論、できた。

ということで、かなり参考にさせていただきつつphp72のものを組めた。今の所、php:7.2-fpm-alpineをベースとしてnginxを足した感じ。

o0ho0h/heroku-php72-fpm - Docker Hub

これを使って、例えば「PostgreSQLとxDebugを足したものを作りたいな」となったら、次のようなDockerfileを用意すれば立ち上がるしHerokuに載せられる。

FROM o0ho0h/heroku-php72-fpm
RUN apk add --no-cache \
    $PHPIZE_DEPS \
    postgresql-dev \
    && docker-php-ext-install pdo pdo_pgsql \
    && pecl install xdebug \
    && docker-php-ext-enable xdebug

ENV COMPOSER_ALLOW_SUPERUSER=1
COPY ./webapp /var/www/html
WORKDIR /var/www/html
RUN php composer install -o

構成イメージはこんな感じだ。

$ tree -L 2
.
├── Dockerfile
├── docker-compose.yml
└── webapp
    ├── composer
    ├── composer.json
    ├── composer.lock
    ├── index.php
    ├── public
    ├── src
    └── vendor

composerは本体をgitに入れて管理させちゃっても良いか、と思ったので入れてある。デプロイ周りの整え方によっては、composer/composer - Docker Hubを使っても良いかもしれない。

実際のアプリケーションを作ってみながらコチラも整えていこう、という気持ちでいるのでまずは「動くところまで」という着地。最終的には、気になっているところをちゃんと取り除きたい。
いま気持ち悪いのは以下

  • rootのままになっている。 docker-nginx-php-fpm-heroku を見ると ADDUSER はしているのだが、USER nonroot とはしておらず、さて・・?という疑問が。
  • 近い問題で、herokuでの起動時にfpmでの user group` ディレクティブが注意される。「superユーザーで実行しない限り効かないよ」と。無指定にすればlocalでの起動に失敗するので、今の所「書いておく、herokuに怒られているけど仕方ない」みたいな割り切り
  • run.sh に乗せている内容を、どうにかDockerfileに持ってこれないものか。理由としては、ベースイメージのCMDの中で実行される内容が肥大化すると、自分のDockerfileに細やかな処理が書きにくくなりそうじゃない?と思うから。

はぁ、それにしても「同じイメージをそのまま使える」のマジで便利。すごいと思う、革命や・・・ 前回apacheでうまく行かなかった理由は相変わらず謎のまま〜〜

Redash Meetup 3.0.0に参加しました #redashmeetup

もう1週間前のことですが。
たまたま知り合い経由で主催の id:ariarijp さんにお声がけをいただいて、Redash Meetupの第3回でお話をしてまいりました。

会全体的な振り返りは、こちらにまとめてくださっているので。 ariarijp.hatenablog.com

発表しましたですよ

で、わたくしめの話した内容はこちらの「minnaka-redash-wo-qi-chi-tiyokushi-uyarifang-wo-kao-eru-number」でございます。
speaker deckの生成するJP->ENなURL、好き。

speakerdeck.com

もともとは tech.connehito.com の記事を書いた時に「こういう内容、meetupで話してみたらどうですか!」と言われたのがキッカケだったので、エントリーの内容を肉付けしたり削ったりして組んだのが今回の発表内容。
正直なところ、これを以てウチの組織で「めちゃくちゃ上手く行っていて快適、ユートピア!」なんて状態はまだほど遠いのだけれど・・・

↓1番思うところはココでありまして。

f:id:o0h:20180711101342p:plain

当日、お話を聞いてくださった方々ありがとうございました。
人の前で話すの久しぶりすぎて、自分のターン終わって着席後に貧血ぽさ&吐きそうになったのは秘密です。

登壇内容で持ち帰ってきたもの

自分としてはAPI経由の操作やQueryRunner等「Redash自体の拡張」というのに手を出していなかったので、お話をされていた他の3名の内容が結構ビシビシ刺さった。

クエリのバックアップ/差分管理・・・そういうのもあるのか・・・とかビックリしたり。

JQL(mixpanel)のQuery Runnerとか書いてみたいな・・・JQL叩くとかチーム内で自分くらいしか使っていないけど、それにしたって自分が叩くのだから欲しい・・・。あとJS/JQL知識はあるのに!みたいなメンバーはいる状態なので、「pythonでリクエストしたり整形しなければいけない」というのが余計。これを是正すれば活用度合い広がりそうなので。やるかぁ。。

"Redash運用に付きまとう課題とその解決方法"が 「未来の話」ぽくて良かった

それとは別観点で、エウレカ大久保さんの話が、自チームよりはるかに先のステージで戦っている!!感があってとてもおもしろかったんですよ。なるほど、そうやって対処していくのか〜的な。

「課題は組織文化・規模等においてケースバイケースだと思う」というのは自分の発表においても述べたとおりなので、同じやり方をそのまま引っ張ってこれるか?についてはNOだと思うけれど。あと、例えば「命名規則管理」は結局・・・みたいな話も御本人がされていたので、これは「minnaka-redash-wo-qi-chi-tiyokushi-uyarifang-wo-kao-eru-number」のテーマとは確かに真っ向に立場を異としているよね!とか。

その中で、じゃあお前は何が「刺さった」といっているのか?というと、「Redashと周辺ツールの組み合わせ方」みたいなところで。
当然ながら「RedashのQueryをAPI経由でSpreadsheetに食わせられるよね」みたいなところは知っていたのだけども。Redash単体だと「ダッシュボード作成のために、似たようなクエリを複数書く必要がある」とか「簡単な集計をビジュアライズに含めるためにソース側に都度集計列を足す必要があったり」「PivotTable含め、集計結果を加工したものを用いてビジュアライズすることができない」とか。 これらが、「データソースから引っ張ってくる部分」と「ビジュアライズのための集計処理をする部分」と「ビジュアライズをする部分」が分離されるような構成にする事で、とても楽になるなぁ〜・・・・・と。*1
「知見や視点を1箇所にまとめたい」がためにRedashは魅力的なので、運用を考えないとなぁとは思うけれど、それでも「SpreadSheetに投げる」は納得感があり良さそうと感じた

あとは「古いクエリによる誤った情報の引き出し」も、たしかになぁ。。

その他、真似したいなぁ〜と思ったのは「ビジュアライズするときの色の使い方等のルールを定める」とか。「男性を表すのが、ものによって赤だったり青だったりすると混乱する」は確かに・・

懇親会で感じたもの

当然ながら自分が話したのが「運用どうしていくか」というものだったので、立ち話も運用どうですか〜〜みたいな話題も多かったのだけど。どの会社も大変そうだ・・w

  • データ分析専任ぽいファクターがあるところはまだまだ少なそうだけど、情シス的な機能や社内ツール的な機能を持つエンジニアが「データ出し」を代行したり管轄していたりすることが多いのかなぁという印象
  • 「非エンジニアがばりばりSQL書く」みたいなのはやっぱりハードルがありそう、そこに達しているだけでも結構恵まれている感じ
  • 「どのくらいの数のクエリやキィーがあるか」「触っている人数がどのくらいか」で求められているものが全く違いそうだな、と改めて

とかかなぁ

企画と会場提供とてもありがとうございました!

個人的にはずいぶんと久しぶりな勉強会登壇で、本番までずいぶんと気が重かったのですがw
発表してみたら会場の方々が温かい雰囲気で聴いてくださってよかった〜
そして会場がすごくキレイでおしゃれだった・・・アレほしい・・・

ということで、主催の有田さん・会場のエウレカさんありがとうございました!!
何かおもしろ知見溜まったらどっかでまた発信したいなー

*1:とはいえシズル感のあるダッシュボードを組むには、やっぱりTableauやDataStudio、もしくはRedash4.x的な「ダッシュボード作成」のための機能がほしいな〜とは感じつつ・・