| @Mac/iPhone

Touch Bar

リモートワーク中心の世の中なので Slack の Status で離席していることやミーティング中であることが分かると便利なはず。というわけで自分はなるべく Slack の Status を更新するようにしているが、 Slack アプリ内での Status の更新は面倒くさい。メニューを押して絵文字選んでひと言アップデートを入力とか毎度やってられない。ボタン一発で Status を更新したい。

MacBook Pro の Touch Bar は評判が悪い。自分もあまり便利だと思わないのだけど、一つだけ便利な使い方があって、それがこの Slack の Status アップデートボタンを配置するというもの。 Touch Bar に配置されたボタンを押すだけで食事中であることや退勤済であることを Slack の Status として表示できるようになる。めっちゃ便利。

なお、オリジナルのアイディアとソースコードは 9m さんのものです。

https://blog.kksg.net/posts/slack-status-emoji/

https://blog.kksg.net/posts/slack-status-emoji/

blog.kksg.net

必要なもの

準備

1. Slack の API Token を発行する

その仕事、Slack で。

その仕事、Slack で。

Slack のことを学べるようサポートします。役立つ記事やビデオのコレクションを参照して、質問の答えをすばやく見つけましょう。

slack.com

2. 9m さんの gist を clone し、手元で動かせるようにする

$ ghq clone https://gist.github.com/af5894ced5cc1ac38bfd2687cad7c780.git slack_status
$ cd clack_status
$ bundle install
$ echo "SLACK_TOKEN=XXXX" > .env
$ bundle exec app.rb "🍺" "退勤しました"

ちゃんと設定できてれば以下のようになる。

コマンドラインから Slack Status をアップデートしている様子

3. Automator を開き、クイックアクションを設定

新規作成で「クイックアクション」を選ぶ。

Automator を開き「クイックアクション」を新規作成

アクションの中からシェルスクリプトを選ぶ。

シェルスクリプトを選ぶ

実行したい処理をシェルスクリプトで書く。

実行したい処理をシェルスクリプトとして記載

自分は以下のようにしている。

export PATH="~/.rbenv/shims:$PATH"
export LC_ALL=ja_JP.UTF-8
export LANG=ja_JP.UTF-8
cd /Users/morygonzalez/src/gist.github.com/slack_status
bundle exec ruby app.rb "🚽" "放尿 or 脱糞中です"

なお、赤枠で囲った「ワークフローが受け取る項目」は「入力なし」にしておかないとちゃんと動かないので注意。

入力なしを選択

設定完了したら名前を付けて保存する。自分の場合は Slack トイレ などのような名前にしている。この作業を追加したいコマンドの数だけ繰り返す。

4. キーボードショートカットの割り当て

システム環境設定 -> キーボード -> ショートカット -> サービス の順に進む。正しく Automator でアクションを設定できていれば「サービス」の一覧に表示されるので、割り当てたいショートカットキーを割り当てる。

ショートカットの設定

5. BetterTouchTool で Touch Bar をカスタマイズする

タッチバーに表示されるボタンのアイコンとラベル文字を選び、タップしたときにショートカットキーが実行されるようにする。

BetterTouchTool で Touch Bar をカスタマイズ

こうすることで Touch Bar から Automator のクイックアクションが実行され、めでたく Slack の Status がアップデートされるようになる。

ちなみに自分の Touch Bar はこんな感じ。

Touch Bar の様子

ほこりをかぶってる Touch Bar を是非有効活用してあげてください。

Touch Bar がないパソコンを使っている人向けの情報

Touch Bar のない Mac を使っている人はこのやり方を使えないので Slack の Google Calendar 連携機能を使うと良いと思う。設定に Status Sync という項目があるのでこいつを On にすると、 Google Calendar で予定が入っている時間になると Slack の Status を自動で更新してくれる。

Google Calender の Status Sync

会議中であることくらいしか共有できないので Touch Bar にいろんなボタンを配置するのに比べたら不便だけど、カレンダーに予定を入れておくだけで Slack の Status を更新できるようになるのは便利。

今後の課題

良くありがちなのが「仕事中」の Status のまま退勤してしまうというやつ。夜中や週末も仕事している異常な人になってしまう。スマートフォンからも同様にめっちゃ手軽に Slack の Status をアップデートしたいけどまだソリューションを見つけられていない。情報お持ちの方いたら教えてください。

| @技術/プログラミング

前書いてた記事の続き。

🏭 Docker を Production 投入するメリットを考える

🏭 Docker を Production 投入するメリットを考える

仕事で開発中のシステムで、 master ブランチに Pull Request が Merge されると自動的に AWS ECS に構築した社内向けの確認環境にデプロイが行われるような仕組みを導...

portalshit.net

Kaizen Platform 時代は Naoya Ito さんの以下の記事にあるような感じで deploy してた。 Slack 上で hubot に話しかけると deploy 用の Pull Request が作られていい感じに deploy フローが始まる。

GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー

GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー

少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分…

d.hatena.ne.jp

これがめっちゃ良くて、現職場でも導入したいと思ってたので今週ちょっとやってみたところ deploy できるようになった。

実際のデプロイフロー

まず Slack で hubot （ 山の会社なので tengu という名前にしてる）に話しかける。すると hubot で GitHub の API を叩いて deploy 対象の Pull Request を取得し、それぞれの Pull Request ごとに commit をグルーピングして、 deploy 対象の Pull Request の Author にメンションするかたちで master ブランチから deployment/production ブランチへの Pull Request が作成される。

tengu deploy 1

最近 Slack の GitHub Integration がアップデートされて、 Webhook の通知がいい感じに飛んでくるようになったので Slack 上でどんな内容が deploy されるのかが一目瞭然となる。

実際に作成される Pull Request は以下のような感じ。この Pull Request を Merge することで CircleCI 上で deploy 用のビルドが走る。その辺は Naoya さんの記事で書いてあるのと同じ。

tengu deploy 2

いま作ってるやつは AWS ECS で運用しようとしてるので、 cap deploy ではなく手製のシェルスクリプトで以下のことをやっている。

  1. deploy 用のコンテナイメージをビルド
  2. AWS ECR にコンテナイメージをプッシュ
  3. プッシュしたイメージを利用する Task Definition を追加し、 ECS のサービスを更新 ecs-deploy というシェルスクリプトでやる

以前の記事にも書いたが「 CircleCI が落ちてたら deploy できないじゃん？」というツッコミが入ったため CircleCI が落ちていても deploy できるようにシェルスクリプト化してあるので、手元からおもむろに bin/deploy production とかやっても deploy できる。

ちなみにこのフローを実現する .circleci/config.yml は以下のような感じ。

jobs:
  deploy:
    docker:
      - image: docker:17.05.0-ce-git
    steps:
      - checkout
      - setup_remote_docker:
          docker_layer_caching: true
      - run:
          name: Install dependencies
          command: |
            apk add --no-cache py-pip=9.0.0-r1 jq curl curl-dev bash
            pip install docker-compose==1.18.0 awscli==1.14.38
            curl -s https://raw.githubusercontent.com/silinternational/ecs-deploy/ac2b53cb358814ff2cdf753365cc0ea383d7b77c/ecs-deploy | tee -a /usr/bin/ecs-deploy && chmod +x /usr/bin/ecs-deploy
      - run:
          name: Execute deployment (Docker image build, push to ECR, create new Task and replace container)
          command: |
            case ${CIRCLE_BRANCH} in
              "deployment/dev" | "master" )
                DEPLOY_ENV="dev" ;;
              "deployment/production" )
                DEPLOY_ENV="production" ;;
            esac
            bin/deploy ${DEPLOY_ENV}

workflows:
  version: 2
  production-deploy:
    jobs:
      - deploy:
          filters:
            branches:
              only:
                - deployment/production

Chat deploy のよさ

deploy フロー・ deploy 状況が可視化され、民主化されることがよい。昔ながらのローカルからの capistrano による deploy の問題点は deploy の特権化を招いてしまうことだと思う。 ○×さんしか deploy 用の踏み台サーバーに ssh できないので一々○×さんに deploy をお願いしないといけない、というような状況はよく分からない遠慮や序列を招きがち。 deploy フローが自動化されていることでチームに入ったばかりの人でもさくっと deploy が行えるというメリットもある。

deploy の履歴が Slack 上と CircleCI 上、また GitHub 上に Pull Request として残るのもよい。ひとくちに deploy といっても schema 変更が伴う場合は作業ログの共有やコミュニケーションをどこかで行う必要があり、その場所として GitHub の Pull Request が使えるのがとてもよい。 YAMAP で作った deploy スクリプトではそこまでやってないが、 Kaizen Platform の deploy スクリプトには deploy 用の Pull Request 本文に動作確認用のチェックボックスを作って、チェックボックスにチェックが入れられるまで cronbot が二時間おきに deploy 対象の commit author に Slack 上で動作確認を促す、というような仕組みまであった。

今後 YAMAP でもどんどん deploy フローを改善していって Merge ボタンを押したあと寿司を食ってれば良いような状態1にしていきたい。

ちなみに上記の chat deploy を実現するためには GitHub App を作っていろいろやる必要があって、その辺は Kaizen Platform で同僚だった t32k さんの以下の記事が参考になった。

チャットデプロイしたい2018 - MOL

チャットデプロイしたい2018 - MOL

タイトルの通り、チャットデプロイしたい。

t32k.me

書いてあるフローはほとんど Kaizen Platform のやつと同じでちょっとウケた。いやでもそのくらい完成されてる仕組みだと思う。この割とイケてる deploy フローを体験してみたい人は僕が勤めてる YAMAP の Wantedly をご覧下さい。資金調達しており割と積極的に採用中です。

  1. Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した - Glide Note http://blog.glidenote.com/blog/2015/02/18/terraform-github-circleci-atlas-aws/ ↩

| @技術/プログラミング

ExceptionNotification::Slacky

Rails とかで例外が発生したときに Slack に通知するやつ作った。 exception_notification という便利 gem のプラグインとして動く。

GitHub - morygonzalez/exception_notification-slacky: Notify exception to slack channel

GitHub - morygonzalez/exception_notification-slacky: Notify exception to slack channel

Notify exception to slack channel. Contribute to morygonzalez/exception_notification-slacky development by creating an account on GitHub.

github.com

実は ExceptionNotification 本体に SlackNotifier あるんだけど、通知内容があっさりしてて自分たちのユースケースには合わなかった。 IRC 使ってた頃は同僚のスーパープログラマー @udzura さんが作った exception_notification-ikachan を使ってて、それと同程度のエラー通知が来るのを Slack で実現したかった。

世の中には Airbrake のような便利なサービスあって、エラーの統計情報とか取ってまとめて通知してくれたりするものもあるけど、甘えてはいけない。エラーが即 Slack に通知されることで、バグを放っておくと Slack のチャンネルがてんやわんや状態になって業務に支障が出るのでバグを直すインセンティブが生まれ、ソフトウェアの品質が向上していくのである。

| @労働

rebuild.fm でたびたび HipChat とか IRC の話がある。最近は Slack というサービスが流行っているらしい（Rebuild: 54: Email Will Never Die (naan, N)）。ウェブ開発者じゃない人の間にも広まってる感じなのかな。自分はいまの会社に入って初めて IRC に触れて便利だなぁと感動したし、もう IRC のようなチャットシステムがない会社で働くのは無理だなぁという感じがする。

これまで働いてきた会社の情報共有手段を振り返ってみる。

最初に就職して三日で辞めた会社

数人しかいない会社。なんかよくわからない P2P のメッセンジャーだった。一対一でしか情報やりとりできない。 URL の共有とかファイル共有に使ってた。口頭での情報共有がメイン。

二番目に勤めた地元のホームページ制作会社

10人くらいしかいない会社。 Yahoo! メッセンジャーだった。グループチャットとかできたのかもしれないけど一対一でしか使ってなかった。使い方は同じように URL とファイル共有だった。口頭での情報共有がメイン。

三番目に勤めた福岡のウェブ制作会社

社員数は70人くらいで東京やベトナムの社員とも協働することが多かった。基本的に ML でやりとりして、チャットは MS の Communicator とかいうやつだった。 Active Directory なやつ。グループチャットとかあったけど基本的に一対一で情報やりとりしてた。この会社くらいの規模から口頭での情報共有が厳しくなってくる。

現在の職場

社員数300人くらいで、 IRC でやりとりしてる。チームによっては Skype 使ってるところもあるけど、基本的には IRC 。 IRC の良いところは、話しかけることで会話が始まるのではなく、チャンネルがあってそこに人が入っていく感じ。たまり場感ある。大学生の頃サークルやってなかったからちょっと違うかもしれないけど、サークルのたまり場に似てるんじゃないかという感じがする。 IRC に接続すると誰かいてなんか返事が返ってくる感じがいい。

あと ZNC などの IRC バウンサー使うと自分が接続していなかった間のログも読めて良い。 Skype のチャットにもこういう機能あるけど、 Skype はグループを作ったりとか人との会話とかで、人と人のチャットに主眼が置かれる。 IRC はトピックごとに場所がある感じ。

社員全体へのお知らせとか #all チャンネルとか #fukuoka チャンネルに書かれるけど非同期に読めるのが良い。 MS の Communicator とかはその場ですぐ来たメッセージ読んで返事しないとちっこんちっこんアイコンが光ったりしてうざい。というか一対一の会話ツールは非同期コミュニケーションしづらい。 IRC だと手が空いたときにまとめて読んだりできるので良い。

あと IRC は Ikachan とか Hubot とか bot にいろいろやらせられるのがよい。 Jenkins のビルドが走ったら IRC に通知する、デプロイが始まったら IRC に通知する、 Hubot にデプロイをやらせる、 GitHub の Issue にコメントがあったら IRC に通知するなどなど。

三番目の会社は各人が情報にアクセスできるレベルが Active Direcotry で管理されてて必要な情報を必要な時に得ることが難しかった。 IRC でも選ばれたメンバーしか入れないチャンネルとか作ることもできるけど基本的に本人がこの情報欲しいと思ったときにそのチャンネルに入って情報を得ることができて効率が良いと感じた。

もっと多くの人が IRC とかチャット使って仕事して欲しい

IRC はずっと前からある技術だけどいまでも便利な情報共有手段だし何でもっと多くの会社で使われないんだろうという感じがある。小さな会社じゃ自前で IRC サーバーたてるのとかしんどい感じあるしある程度技術者がいて運用スキルがある会社じゃないと使えないのかも知れない。いまは HipChat とか Slack とかあって IRC サーバーたてなくても良いし ZNC とかの使い方がわからなくても過去ログ追えたりするわけだし、ウェブ開発者がうようよいるような会社じゃなくても便利なチャット使えるのだからもっといろんな会社に広がるといいと思う。自分がいまの会社に入ったときに感じた情報源の広がり感をもっと多くの人に味わってもらえると日本社会もっと良くなる気がする。