Zapier を使って、SlackリアクションでTodolistを作るようにした
これまでのタスクの管理方法
最近、お仕事のRoleが若干変わり、コードを書く量が減った代わりに、「○○の件、確認お願いします」などの色んな方面の依頼や調整タスクを拾う事が増えました。
業務のメインツールは言わずもがなのSlackなので、基本的に仕事はSlackから降ってきます。
色んなチャンネルでPostされる依頼タスクを管理するには脳内メモリではオーバーフローすることもしばしばで、
手元のメモ帳にタスクリストを書いたり、依頼Post のPermalinkを拾って自分宛のDMに転送Postするなどしていました。
改善してみようと思ったきっかけ
少し前に特定のリアクションをトリガーにして動くbotを社内の方が作っていたのを見て、似たような事できると思ってZapierでやってみました。
リアクションされたコメントを自動翻訳するSlack BotをZapierで作った
またZapierについては以下のBlogが詳しいです。
社内でかなり導入されていて、今回の以外にも色々使えて便利。
やること
Zapierで 2 step 組むだけ、以上!
って、書くと味気ないけど、ホントにこれだけで
- New Reaction Added
- Send Private Channel Message
のActionを設定するだけです。それぞれ以下のようなイメージです。
New Reaction Added
Reaction
にはトリガーとなるリアクションの種類を指定する。
User
での絞込もできるので、ここに自分を設定すると同じリアクション使う人がいても、それは拾わなくて済むので今回は設定する方が吉。
Send Private Channel Message
Channel
は Post先のチャンネル名。まんま文字通りでしかない。
Message Text
には Step1で拾った情報から、Message Permalink
を設定する。
ちなみにこのStep2 のアクションは Private Channel である必要はなく、Public ChannelでもDMでも良いと思います。
やってみた結果
元の投稿にリアクションをつけます。
PermalinkがPostされるので、Slackの仕様で自動的に中身が展開されて一目瞭然です。 ここから流れを追いたい時には、Permalinkから元チャンネルにジャンプして確認可能です。
まとめ
1アクションでタスクリストを作れるようになりましたっ!
ex-mixi Advent Calendar 2017/12/01
なかなか珍しい ex-mixi(会社のOB/OG)によるAdvent Calendarの一発目をかます masartz です。
ミクシィは 2ホップ前の会社、現所属はメルカリになります。
どういうスタンスで書けば良いのかわかりませんが、各方面を考えてミクシィ時代から今に至るまで継続してることを述べていきたいと思います。
大規模であるが故の技術的な対策
mixiもメルカリも大規模と言って良いレベルのサービスで、そのための負荷対策はどのエンジニアにも求められるものです。 特にクラウドなインフラ環境が今ほど整っておらず、スケーリングに緻密な設計が求められたミクシィ時代に学んだ分散手法は今も活かされています。
ミクシィエンジニアなら、下記は L1分散作業
と表現すれば、その一言で伝わることでしょう。
こういった手法はサービス初期に用いられることは少ないでしょうし、現在においてはクラウドのオートスケールでカバーできる部分もあり、それは投資フェーズにおけるメリットです。 サービスをグロースさせることに注力するのは非常に魅力的です。その後、サービスが安定し収益性を高める段階において コストパフォーマンスとの兼ね合いでこういったエンジニアリングの活用方法があります。
DB分散以外にも、SQLのクエリチューニングによる速度改善、キャッシュ機構を導入することによる負荷削減などの様々な手法も同様です。 どれも地味に感じるかもしれませんが、webサービスにおいてアプリケーションコードの計算量がボトルネックになることよりDBからのSelectやNW通信による 処理にかかる時間の方が遥かに多いです。アプリケーションコードをいたずらにリファクタしチューニングするよりも、DBへの問い合わせを1つでも減らす方がよっぽど速度改善になるケースは多いと思います。
サービスを運用し続けること
俺はミクシィにもメルカリにも、比較的規模が大きくなってから入社したため、本当の意味でのゼロイチのグロース方法は実はわかりません。 1から10でもなく、10から100くらいのステージにいつも関わっています。
その段階では既にサービスは立ち上がっていて、様々なコードを目にすることになります。先日、ブログエントリを公開したところ、 それに関してあまりにも予想外なほどにありがたいコメントをたくさんいただきました。
私のように後から入った人間が、現状だけを見て「これはおかしい、負債だ」と言うべきではありません
この部分が異常に刺さっているようですが、これはマジで本心からそう思ってます。
ミクシィ時代、後から入社してきた人に「なんでこんなコードになってるんですか」と言われるのがとにかく辛かった。
言いたい気持ちはもちろんわかりつつ、それまでの人もそのような問題は当然認識していたからです。
そのようなコードになるのはやはりサービスの成長を第一に考え、実行してきた結果だと思います。 mixiやメルカリよりキレイなコードで動いているサービスはたくさんあるでしょうが、 それらより大きな規模のサービスはなかなかないからです。
我々の仕事はサービスを提供し、価値を届けるのが目的であり、コードはあくまでその手段です。
ミクシィもメルカリもそうやって先輩エンジニアがサービスを成長させてきたのだと思います。
その上で だから、どうするか
ということを考え実行していくことが、後から入ったメンバーのやることであり、
またこれから来たるべきメンバーに対してできることかなと思います。
逆説的な話ですが、後から入った人が既存のコードをdisれるのは、
- サービスでそのコードが動くことで、価値を提供した
- 価値を提供したことで、売り上げを出した
- 売り上げを出したことで、サービス拡大のためメンバーを増やした
からだと思っています。つまり今の自分は目の前にある既存コードのおかげで雇用されたので、 それをdisることは自分自身の否定になってしまうので、できないという考えです。
俺自身ミクシィを出てから、前職でも今の職場でも既存コードの悪口だけは言ったことがないと思います。 サービスの規模との相関で、人や組織もスケールします。それぞれの組織の状態に適したコードがあります。 そのような振る舞い方を学んだのもミクシィという環境でした。
サービスに対する責任感
多くのお客様に使われるサービスというのは本当に刺激的です。
ミクシィ時代も、正直良い意味でも悪い意味でもたくさんの反響をいただだきました。
そのどれも貴重な体験でしたが、特に1つだけ忘れられない件は、
日本に未曾有の大災害が起こった際、友人・家族などがmixiにログインした活動履歴でお互いの安否を確認できたことをお客様から感謝されたことでした。
メルカリのおいても、日々たくさんのお問い合わせをいただきます。 どれもありがたいものですが、やはり感謝されるというのは特別です。 サービスや施策の状況に応じて様々な声がある中でも、感謝は自分達のやるべきことを再確認させられます。
とはいえ、それほどの機会が日常的に多いわけではありません。
だからこそ最も目指すべきことはお客様がなるべく非日常を意識することなく、 いつも通り使える
サービスにする大前提を達成することなのは昔も今も変わりません。
といったところで宣伝
せっかくなので、それぞれの本家のアドベントカレンダーも紹介しておきます。
このex含めて3つ、どれも楽しみにしてください。
まとめ
エモい話になった初日かもしれませんが、
- 当時やってたこと
- 今やってる技術的なこと
- 技術じゃない思い出や考え
などの色々をちょいちょい書いてみました。2日目以降の人で、「こんなこと書いても良いのかな」と思っていた部分の実績と後押しになれば幸いです。
2日目は KAKKA がこんな流れを大きく変える投稿をしてくれることでしょう。
その後も多種多様なコンテンツが繰り広げられ、時には穴も空く事もあるでしょう。
しかし、最終的には hirokidaichi が全て回収してくれるでしょう。
かつての同郷メンバー方々への信頼は今も変わりありません。
それぞれがどのように活躍しているか楽しみであり、離れていようともお互い刺激しあっていければと思っています。
そのような素晴らしい仲間と出会えたミクシィという場に改めて感謝しています。
WEB+DB Press vol.96 の Perl Hackers Hubに寄稿しました
この度、id:songmu さんにお話をいただいて、WEB+DB Press vol.96 の Perl Hackers Hubに「大規模広告配信でのCPANモジュール活用」と題して寄稿しました。
内容は今勤めている fluct社のSSPサービスfluct の配信サーバー周りについてです。
fluctのPerlは広告配信という、いわゆるMVCのフレームワークでWebサイトを作るのとは違った役割を持っていておもしろい面がありますが、
スマホのクライアントアプリを受けるAPIサーバーとかだと作りが参考になる部分もありそうですし、
広告ならではの設計もあります。案件情報を取得する部分は(Perl要素薄いですが)おもしろくてオススメ読みポイントです。
初めての執筆活動
実は、本を出すことはおろか、寄稿するというのも初体験でした。
こんな貴重な機会をいただいた id:songmu さんには大変感謝しております。
やってみて、どうだったか?
すげー大変でした!
普段とても意識していることに「言うことは3行で、簡潔に」というのがあります。
この原則は前職の上司に求められたことで、とにかく如何に短くするかを考えた上で、結論を先にまとめて言うようにしています。
これは少ない時間で本質から逸れない意思決定をするためにとても大事な事だと思ってます。
しかし、記事というものは「起承転結」と構成・流れ があり、それが基本かつ核になります。
執筆にあたっては、まずアウトラインを決めるのですが、個人的にはこれがその後の本文書くより難しかった、、
アウトラインだけで流れがわかるかどうか、がポイントなのですが校正で指摘してもらってもどうして良いかわからず。。
初っ端からかなり躓きました。
その後においても、初期のコンセプトが緩かったために 何を伝えたいのかわからない
文章になってしまったり、技術評論社の稲尾さん、監修の牧さんには執筆の過程で、多大なご迷惑をおかけしました。
結局、書けたの?
最終的には、しっかりと仕上げました。 そう言えるのは理由があって、実は来年(2017年)の頭に、fluct及びVOYAGE GROUP を辞める事にしました。
というわけで、本エントリは「退職エントリ」ではなく、「退職しそうなエントリ」です。
執筆のお話をいただいた時点で、転職先は決まっていなかったものの気持ちの中では辞める意志は固まってました。
だからこそ、今回の記事はキッチリ書こうと決めていました。
所属していれば、例えその記事の内容が不十分でもあとでblog等で補足できるかもしれません。
あるいは同僚がフォロー・サポートしてくれるかもしれません。
しかし、そこを辞める人間が書いた記事がイケてない内容だったら
外の人には、どうせ辞めるから適当に書いたんだろうと思われるかもしれないですし、
残る中の人からは、適当なこと書きやがってと恨まれるかもしれません。
そう思わせないような記事にしなければと思いながら書きました。
もちろんアーキテクチャは変わっていくと思うので、普遍的に正しい情報ではないですが、2016年末の状態は表せています。
自分としては、約2年携わって、記事を寄稿できるくらいシステムを理解したし、むしろ書ききれなかった事の方が多いです。
それはページ数が理由なだけでなく、fluctの環境の中でPerlが稼働している部分はあくまで一部であるためです。
サービスの中にいくつものドメインがあり、リポジトリと稼働する言語が複数ある、というのは前職と全然違くてやりがいのある環境でしたが、そのほぼ全てになんらか手をつけられて理解することができたのは良かったです。
また、記事の次のページで fluctの求人インタビュー広告が載っています。
このインタビューも、自分も参加する案もあったのですが断っていました。それも辞めると決めていたから。
さすがに求人しておいて、もし仮にそれに惹かれてくれた人がいて縁があった場合、「入社してみたら惹かれた人がいなかった」なんて事になったらそれはヒドいと思うのが理由です。
決して、「オススメできない環境だから求人に協力しなかった」訳ではないので、自分は違う道を選ぶけど、fluct及びVGがマッチする人はきっといるだろうし、いてほしいと思う。
話を戻すと
そんなこんなで、俺の卒業論文かつPublic公開な引き継ぎ資料であるWEB+DB Press vol.96 は16周年号として内容盛りだくさんとなっておりますので、是非ともお手に取っていただければ幸いです。
個人的にはかなり大変でしたが、とても良い経験になりました。
正直辞めるつもりで業務を整理しはじめていたので、執筆に割けるリソースがあったけど、通常の業務をこなしつつ執筆される方々は本当にすごい。
そういう時にどこまでできるかわからないけど、また機会があればぜひチャレンジさせていただきたい!
求人告知
fluct及びVGはPerlを始めとして様々な技術を使った事業開発会社です。
ことPerlに関して言うなら、客観的に見てそこまで使用割合は多くない。
おそらく今回の記事内容相当のPerl製のプロダクトはないと思いますが、全く違うアーキテクチャでおもしろいプロダクトはあります。
興味があれば、「ajito で話聞きたい」とつぶやけば誰かが反応するでしょうし、どうしてもであれば俺に連絡もらえれば、繋ぎますのでお気軽にどうぞ!
Atmoph Windowがやってきた!
kickstarterで申し込んでいた、Atmoph Windowがようやく到着しました!
ようやくと言っても、実は3週間くらい前に届いていたのがこれまで(引っ越しがあったので、新居で && net開通してから)開封できてなかったというのもある
設置手順
とりあえずテーブルと同じ高さで立て掛ける形で配置してみた。
テーブルと併設している引き出しボックスを足場にしていて、その引き出しのポジションの関係で右の一部が宙に浮いてるけど、安定してます。
壁にひっかけるためのフックも東急ハンズで500円くらいで売ってたので買ってきました。開く穴が小さくなるし、3点固定で安定。という触れ込みだったけど、思った以上にピンが太くて、「これ穴わかるだろ、、」ということで、ひとまず使ってません。
代わりに100円ショップで買ってきた耐震用の粘着パーツで足元を強化して、これが割と良い感じです。
セットアップ手順
使用にはWi-FI環境が必要ですが、スマホからのWi-Fi認識させるセットアップ手順もスムーズでした。
本当にスマホを上部におしつけて信号を送ると良さそう(手順の話なので買ってない人はようわからんと思いますが・・)
逆にわかりにくかったのは、MENUの操作方法^^;
スマホ側がレーダー画面になり、スワイプとかクリックとかがAtmoph側に反映されるんですが、Atmoph画面にカーソルでも出れば伝わるのですが、パッと見だとスマホ画面とAtmoph側の画面のポインタ位置がシンクロしてるのがわからなかった。。
感想
使って見ての感想は、4k画質ということで、さすがに綺麗。
おかげでさっきは珍しく自宅でターミナル開いた作業が捗りました!
これ、写真だと伝わらないですが、静止画ではなく動画 なので(窓ですから!)
夜の時間に夜景を見ながらPC作業するのはなかなか雰囲気出て良かったです。
今後は素材が増えたり、ライブストリーミングも追加されるとの事なので非常に期待。
個人的には自分の素材をアップロードできるようになるのが楽しみ。
気になった方はこちらから どうぞ。
新型MacBookProを今から注文しても年内到着しなそうなので、うっかりAtmophをお買い求めいただくのも良いのではないでしょうか。
いくつかのファイルをまとめて tail する簡易スクリプト
やりたいこと
サービスリリース時に、先に局所的なデプロイをして様子を見る際などに使う
(実際に使っている)ユースケース
- 広告配信サーバーが数百台あり、リリース時には手始めに1台にデプロイして動作確認というフェーズがある
- この時、該当1台はバランサーから外している
- 配信サーバーは、以下の3つのプロセスで成り立っている
- 先行1台での動作確認時には以下のあたりを確認したい
で、どうやるか?
簡易的なスクリプトを作ってましたが、ちょっとだけ直して外部に切り出してみました
How To Use
の項目のままなのですが、clone して make すれば動きます
もうちょっと詳しく書くと、
- 実態はperl スクリプト
make setup
で必要なCPAN Module を$REPOS/local
配下にinstall- 正しくはcpanm を拾ってくる所からやるべきですが、手抜きしてリポジトリ内に同封してます
etc/config.yaml
を 編集します- path : (必須)tailしたいログファイルのFull Pathを記入。アクセスログ等はローテートすると思いますが、動的な日付部分は POSIX::strftime() 形式で書けます。File::RotateLogsのやり方をパクりました
- color : (必須)Term::ANSIColor で色付けして出力するための色指定です
- option : (任意) File::Tail で出力する際のオプション指定
- 編集したconfig.yaml のフォーマットが正しいか
make test
で確認できます make run
すれば、動きます。無限ループで動き続けるので、Ctrl + C
で切ってください
画面イメージ
まとめ
Term::ANSIColor や File::Tail など、既存のCPAN Moduleを使えてお手軽に作れました
運用上のログ監視はこんなのとは全然違うしっかりした仕組みがあるので、
あくまでリリース時の開発者作業の一助に過ぎません。そのスコープにおいてはこれで十分かと思います
AJITOの風景で写真の構図を勉強する
前置き
こんにちは、この記事は#ajiting Advent Calendar 2015の5日目です。
VOYAGE GROUPの写真サークルに所属する自分が、AJITOで写真の構図を勉強した模様をお伝えします。
構図とは?
写真にはいわゆるいくつかのお決まりパターンがあり、それに沿って撮ることで(きっと)いい感じの絵になります。
プログラムのデザインパターンと一緒ですね!
実は今までちゃんと勉強したことなかったのですが、今回少しだけ学んでみました。
さっそく実践、まずは日の丸構図
文字通り、被写体を真ん中にどんと持ってくるパターンですね
というわけでAJITOのロゴをどーん
何を伝えたい写真なのか一目瞭然ですね
二分割構図
こちらも文字通り真ん中で分割のパターン
垂直に分割するとこうなります
今回は正確には左右非対称です。
ちなみにAJITOの運営としては昼が白のブラインド、夜がさらにその上に濃いブラインドをかけます。
またシンメトリー構図と言って、左右を完全に対称にするパターンがよくありますね。
神社やお寺などの対象物が大きい時に意識して撮ると良いと思います。
タージマハルのシンメトリー構図の写真が超有名で、いつか自分で撮ってみたい1枚です。
三分割構図
だいたいどれも文字通りなのですが、これもそう。
同じく垂直に分割した場合です。
おそらくかなりベーシックな構図で、きっと無意識にやってる事が多いパターンです。
個人的にもこれが一番「よく撮る絵だなぁ」と思いながら撮ってました。
ちなみに水平に分割すると、こうなります。
天井が一番上のレイヤ、頭までが真ん中のレイヤ、残りが一番下のレイヤ、で別れているかなと。
左の壁がなかったらより深みのある写真にできたかもしれません。
対角線構図
これは情報源によって微妙に内容が違う気がするんですが、
パターンAとして、対角線の端と端に撮影物を置いてみます。
奥行きが出ますね
パターンBは、対角線上に並べて(あるいは繋げて)みる
お酒のてっぺんを線で繋いで対角線を描くのを意識してみました。
こちらは机の角を対角線に見立てて、区切りをつけた感じ。
勉強してみた結果、、、
やはり写真は奥が深くて面白いですね。
正直今回の撮れたものは自分の中でかなり満足度は低く、まだまだ未熟だなという感想です。
結局、最後に勉強は切り上げて、好き勝手に撮った写真を並べます
水平に2分割してみましたが、これも意外と良い
好きに撮ったと言いつつ、これも3分割方かもしれない、、
AJITOっぽい
最後に
AJITOは
- 写真の素材にもなる
- 時にはシックなBarでコーディングが捗る( <- 撮影日は珍しくこのパターンでした)
- 基本は社内の様々な交流イベントが常時開催されている
場所ですので、写真でもお酒でも興味を惹かれた方はお気軽にお越しください。
それでは少々早いですが、メリークリスマス!
明日は急遽無茶ブリで指名されたhahatchが登板します!
sinatra-formkeeperで2つの入力内容が異なることをvalidateする
最近業務で、とあるwebツールを作っており、いわゆる入力画面が必要になった。
今回はRubyのプロジェクトだったので、アプリケーション自体はsinatra、
そのvalidatorとしてlyokatoさんのsinatra-formkeeper を使った。
これが大変便利!
さすがFormvalidator::Simpleを作っただけあって、
必要なものは揃っているし、使い方も上述のblogエントリを読めば、ほぼわかる。
ただ、「 入力値A
と 入力値B
が異なること」ということをしたい場合にこれをvalidateする機構がなかった。
今回はこれがピンポイントで欲しい機能だったのでサクっとPRを投げて、取り込んでもらった。
Validatorとしてのコア機能はformkeeperに切り出されているので、PR自体はそちらに対してのものになっている。
さっそくmergeしてもらい、rubygemsからも拾えるようになった。
使い方はこんな感じ。
テストも合わせて貼っておきます。
実装自体は99%が既存の機能である same
のパクリ。
same
は上述のブログ例に書かれている通り、パスワード確認の時などに用いられるでしょう。
対して今回の diff
は例えば登録しているメールアドレスの更新や、パスワードの定期更新などに用いられる事を想定してます。
(※ パスワードを定期的に更新するセキュリティポリシーとその運用の是非についてはここでは言及しません)
まぁ、今回の業務ではそのどちらでもないケースで必要になったパッチ送ったのですがw
なので、きっと他でも有用なところがある(かもしれない)!
繰り返しになるけど、sinatra-formkeeper 自体がそもそも便利なので、
まとめとしてはそれが便利ということが伝われば良しです。