八発白中

技術ブログ、改め雑記

Mackerelで家族のヘルスチェックをする

5月に入院して1ヶ月くらい療養していました。

健康にも気をつけないとな、と今更ながら反省しつつ、どうすれば健康管理ってできるのかなと考えてみています。

Fitbitログから学ぶ

一年半前からFitbit Charge 2で心拍数と睡眠時間を記録しています。運動量ではなく、主に睡眠時間を計測するためにつけています。

普段は計測するだけして結果を見ることはほとんどないのですが、「今日は頭が働かないな」というときにふとFitbitのダッシュボードを見ると「なんだ睡眠不足か」とかわかるので便利です。

人によって必要な睡眠時間は異なります。僕は週の平均睡眠時間が7時間を切ると体調が悪くなるようです。

入院中に思い立って過去のFitbitのデータをさかのぼって見返してみると面白いことが見つかりました。安静時心拍数が見事に入院まで右肩上がりで推移しています。

単純な心拍数だけだと歩くだけでも上がりますが、これは安静時心拍数。なにもしていないときの平均値です。

もともと自分は安静時心拍数68〜74を推移していたのですが、入院前に88まで跳ね上がっていました。

安静時心拍数が高すぎる場合は頻脈と呼ばれるようです。

頻脈で疑う鑑別疾患は血液疾患(貧血)、精神疾患(緊張、ストレス、不隠、不安)、代謝疾患(甲状腺機能亢進症、脱水)、発熱、呼吸器疾患(低酸素状態)、心疾患(頻脈性不整脈群、心不全、心筋炎:徐脈もあり)等々様々な状態で見られうる。

心拍数 - Wikipedia

要因はおそらく「貧血」か「ストレス」か「発熱」でしょう。

安静時心拍数は異常がなくても上下するのですが、一日の中で出社している時間は高く、家に帰ってくると下がります。

仕事中でも特に上がっている時間帯は会議中だったりして、会議中にストレスかかってるのだな、とか分析できます。

けれど、入院してから頻脈だったことがわかったところで遅すぎます。悪くなる前にこれを知れたらいいのに。

Fitbitの機能として心拍数のアラート通知はありません。

アラートといえばMackerelさん

そこでアラートといえば、と考えに上ったのがMackerelでした。

サーバー監視サービスのMackerelはメトリクスのグラフ化だけでなく閾値での警告通知をしてくれるはずです。そこにデータ投げればいいんじゃない?と思ってやってみました。

Fitbit Web APIを叩いてMackerelに流すだけの簡単なスクリプトを書いて、さくらVPSに設置してcrontabで5分おきにFitbit→Mackerelに心拍数などのデータを流す。

やってみた

↓僕 (Eitaro) の心拍数(左)と睡眠時間(右)

f:id:nitro_idiot:20180531224913p:plain

これは薬の副作用であまり寝られていないときのグラフです。

睡眠時間の折れ線が複数あるのは睡眠レベル別の時間です。Fitbitでは浅い睡眠、レム睡眠、深い睡眠、睡眠中の覚醒時間を計測できます。

f:id:nitro_idiot:20180802105949p:plain:w360

↓これは実際に来ているアラート画面。

f:id:nitro_idiot:20180531224914p:plain

meymao(妻)の睡眠時間アラートも来ています。妻もFitbit Alta HRをつけているので睡眠時間と心拍数を計測しています。

夫婦で普段からSlackを使っているので、MackerelのSlack IntegrationをつけるとSlackにも流れます。

これは5時間程度しか寝られなかったときの通知。

f:id:nitro_idiot:20180802105219p:plain:w360

睡眠レベルを使って熟睡できていないときもアラートが来るようにしています。

さすがに心拍数をSlackに流すとうるさいのでそちらはメールでアラートを飛ばしています。

まとめ

Mackerelのアラートは単純なしきい値だけでなく、過去10個の計測値の平均でアラートできたりします。ので、心拍数のスパイクで無駄にアラートが飛ぶのも抑制できます。

未解決のアラートが続いているときに再アラートする機能も便利です。

たとえば睡眠時間アラートで12時間後に再通知に設定すると夜9時ごろに再度睡眠時間のアラートがSlackに飛ぶので、「今日は早く寝なきゃ」というリマインドとして使えます。

Mackerelの難点は、高いってことでしょうか。プランが「無料」か「月額1800円」しかないです。

無料プランだと24時間しかデータが記録できないので1日1回の睡眠計測では1個しかデータ登録できず、グラフ化ができません。

かといって1800円を個人ユースでは高いな、と思うので間のプランが欲しいところです。

なぜShibuya.lispは成功し続けているのか

この10月の3連休を利用して、大阪で開催された関西Lispユーザ会にお邪魔しました。

kansai-lisp-useres.connpass.com

一枠空きがあったので20分程度の発表もさせていただきました。いまいち余計だったかもしれません。

すべての発表が終わったあとにイベント終了まで少し空き時間がありました。その時間を利用して運営の一人の油谷さんから関西Lispについての運営指針の話がありました。内容は「Shibuya.lispは作ったプロダクトの発表の場になっていて発表のハードルが高い。関西Lispは気軽に発表してもらい、アットホームなコミュニティにしたい」というものでした。

僕は東京に住んでいることもあり普段はShibuya.lispコミュニティに参加しています。運営者とも話す機会が多いので運営指針もそれなりに聞いています。そういう立場で話を聞いていると「ほう、外からはそのように見えるのか」と非常に興味深く思いました。

Shibuya.lispの運営指針

実際のところShibuya.lispのイベントでの発表に具体的な制約はありません *1。発表したいと思った人が好きなテーマで好きな時間を使って発表できます。

「ライブラリを作りました」とか「ISLisp処理系を作りました」というような技術的に高度なものが目立つし事実かなり多い、というのは言われてみるとそうだな、という程度であまり意識したことはありませんでした。結果的にハードルが高くなって発表しづらくなっている、といえばそうなのかもしれませんが、かと言って逆に高度な発表を禁止するというのも違うでしょう。

そんな高度な発表も多くありながら毎月のイベント開催を5年弱もの期間継続しており、毎回20人前後の参加者を集めているというのがShibuya.lispの歴史とコミュニティの成熟による成果なのだとすると素晴らしいことだと僕は思います。

なぜShibuya.lispは成功しているのか

このようなShibuya.lispの成功は、東京という地の利はあったにせよ、運営陣の努力なく達成されているものではありません。

この辺りのポイントはκeenさんの以下のエントリーにまとめられています。

4年間続いたShibuya.lispのLispMeetUp | κeenのHappy Hacκing Blog

特に僕が重要だと思う点は「運営の負荷を減らした」ということです。

安定的に毎月のLisp Meetupの行うにはどうすればいいか。属人的な努力には依存しないことです。誰かの大きな努力に依存すればその人が忙しくなったタイミングで開催が途絶えます。

たとえば毎月安定して使える会場を用意することで、会場を手配するコストを減らしたり、毎月の開催テーマをローテーションすることで、何をやるかという運営の決断コストをなくすなどの工夫がなされています。

「発表者が集まらない問題」の解決策

加えて、関西Lisp油谷さんが問題としていた点は「だんだん発表者が集まらなくなっている」ことでした。

発表者を、関東陣の僕を除いて、4人も集められているのだから全く問題に感じる必要ないのでは、と思いはするのですが、イベント運営者としてはありがちな不安なので理解はできます。

Shibuya.lispの初期の運営のTech Talkも同じ問題を抱えていました。Tech Talkを定期開催しようとしても発表者が集まらず、運営が伝手で発表してもらえそうな方にお願いしており、それが運営陣の負担となっていました。そしてそれが「どうせ開催しても発表者集まらないしな」というネガティブな空気にも繋がり、運営が途絶える要因となります。

Shibuya.lispの運営が第2期メンバーに引き継がれたときに上記の問題に対する重要な決断は「発表者がいようがいまいが開催する」ということでした。

「そもそもShibuya.lispが何を目的として存在するのかを考えなくちゃいけないんじゃないですか」

単にイベントを開催するにしても、なぜ、というのが明確でなければいずれまた目的を見失う。Shibuya.lispは何かの手段であって、目的ではないんじゃないか、と。

僕のその言葉に一同黙り込んだ。さあ、Shibuya.lispをやる目的とは何だろうか──。

そのとき前運営の立場として参加していた佐野さんが言ったことは、図らずも新しい運営方針を決定付けたものかもしれない。

──「理由はそのコミュニティに集まった人々で作ればいいことで、我々はただその箱を用意すればいいんじゃないかな。だとすれば、『続ける』ということも十分目的になるよ」

Common Lispのコミュニティ事情 - 八発白中

発表者がいなければいないでいいのです。集まったメンバーで自己紹介をしてだらだら話をするでもよし、その場でライブコーディングを始めるもよし、早めに切り上げて飲みに行くでもよし。何にせよ場を作り続ける、ということを目的としたことは振り返っても成功の要因だった気がします。少なくとも「発表者が集まらない…」と運営陣が嘆くような心理的コストも減り、イベントの安定開催に一役買っています。

そういったShibuya.lispでの経験から言えば、油谷さんの不安は理解はできるけれども、あんまり心配しても仕方ないのでは、と思うわけです。

*1:Lispに関係すること、というのが唯一の条件だったと記憶。

Day 25: Utopian

メリークリスプマス!

これは fukamachi products advent calendar 2016 の25日目の記事です。

今日はUtopianについて話します。

アドベントカレンダー最終日

このアドベントカレンダーも今日が最後ですが、テーマになっているプロダクトのリリース日がだいたい時系列になっていることに気づいていましたか。

CL-TEST-MOREから始まってClack、Cavemanなどのフレームワークがあり、途中にIntegralやWooなどもありました。

そして最後が今日のUtopianです。これはまだ開発中であり、そういう意味では未来の話とも言えるかもしれません。

未来はどこにあるか

2011年10月、Shibuya.lispのLTで「深町英太郎はどこへ向かっているのか」というトークをしました。

タイトルはネタっぽいですが5年前から向かうべき場所としてのUtopianが出てきています。

Utopianとは何か

アリエルで松山さんと働いていたときにClackとCavemanを作りましたが、それでもCommon LispでWebアプリケーションを作るには足りないものが多すぎました。DB周りはほとんど整備されてないし、テンプレートエンジンも心もとありません。Webサーバーも実績不足でどこまで実用に耐えうるのか疑問でした。

最終的にはRailsのようなフルスタックなWebフレームワークも欲しい。それはClackよりもCavemanよりも高い抽象度になるだろう。名前はどうする。薄いフレームワークが原始人だったから、厚いのは未来人? いや、そういう年代の違いではないだろう。もっと夢のような。じゃあ桃源郷? Utopianか?

そうして夢の話をしてるうちにその名がプロジェクト名としてしっかりとした重みを持ち始め、向かうべき象徴となりました。

そして、Utopianは長くGitHubの空のリポジトリとして放置されていましたが、ついに今年の2月にMitoを基幹としてUtopianの開発が始まりました。

「いつ完成するんですか」という質問をたまにされます。わかりません。まだまだ遠いような気もします。

おわりに

UtopianはGitHubで開発中です。

では皆さん、良いお年を。

Day 24: Mito

これは fukamachi products advent calendar 2016 の24日目の記事です。

今日はMitoについて話します。

Integralの失敗

11日目のIntegralの「抽象化の失敗」のところで取り上げましたが、Common LispのORMとして作られたIntegralはPostgreSQLのサポートに失敗し、サポートするには根幹部分から再設計が必要となりました。

その後dataflyを作ったりして、ORMよりももっと軽量なライブラリを好んで使っていました。けれどそれも、サムライトでIntegralを採用してから話が変わってきました。

いよいよ真面目にメンテナンスしないといけなさそうだけれども、Integralに手を入れ続けるのは限界がありそうです。そこで自信を持って使ってもらえるORMは必要だなと思って一から書き直したのが「Mito」でした。

Mito

Integralの経験を活かしてMitoでは慎重に抽象化を行いました。具体的にはdefclassCREATE TABLE文と紐付けるメタクラス層と、そのメタクラスをData Access Objectとして扱えるようにするメタクラス層で分離しました。

また、Integralではdefclass:typeRDBMSのカラム型に変換できる機能もあったのですが、Mitoではそこまでの高度な抽象化はしませんでした。そのため少し保守的な設計になっていますが、何よりちゃんと動くことが大事です。

最近は僕もいくつかのプロジェクトでMitoを使っており、マイグレーションも含めて問題なく動いています。

名前の由来

どうでもいいことなんですが、「なんでMitoって名前なんですか」とサムライトの社内ミーティングで訊かれました。

Mitoというのは京都市動物園にいるアジアゾウの「美都」からつけました。

これは猛暑真っ只中の写真で、飼育員さんに水浴びしてもらっているところです *1

f:id:nitro_idiot:20130817131454j:plain

飼育員さんがプールに入らせようと好物のりんごをプールに放ったのですが、プールが嫌いな美都は鼻を伸ばしてりんごだけ取っています。水こわいけどりんごは食べたい。

なぜアジアゾウの名前をつけたかというと。

昔、ElephantというCommon Lispのオブジェクトストアがありました。このAPIはよくできており、CLOSオブジェクトを永続化させるという高度な抽象化を行っていました。このElephantには問題も多かったのですが、目指した夢としての印象は僕にとっては強烈で、僕のORMにもその心意気は込めたいと思ったからです。あと愛着が湧くからです。美都かわいい。

まったく技術的な話ではありませんでした。

おわりに

MitoはGitHubで公開されており、現在Starは35ついています。

明日のアドベントカレンダーは最終日25日目のUtopianについてです。お楽しみに。

*1:写真は2013年当時のゾウ舎。今はゾウ舎が移築されて広くなっており、ゾウも4頭増えています。しばらく美都は奥のゾウ舎から出てこなくてまったく会えなかったのですが最近は見られるのでしょうか。

Day 23: Psychiq

これは fukamachi products advent calendar 2016 の23日目の記事です。

今日はPsychiqについて話します。

はてなでの経験

僕の経歴の中ではてなで働いていた時期はあまりOSS活動もせず、Common Lispを書いていませんでした。仕事がPerlということも理由の一つでしょう。

けれど直接的ではないにせよはてなでの経験は少なからず僕の活動には影響を与えています。Webアプリケーションのサーバーサイドからフロントエンドまで担当でき、どのようにWebアプリケーションを構成し運用するかを学ぶことができました。どこがボトルネックになりやすいのか、長期的に運用する上でどういう面が問題になるのかなどの生きた知見が得られました。

はてなではWebフレームワークから作ることもそう珍しいことではなく、その経験はCaveman2の開発にも活かせたり。

その過程でCommon Lispに足りないものもありました。それがメッセージキューでした。

メッセージキュー

メッセージキューはアプリケーションで実行に時間がかかりそうだが同期的にやらなくてもいいものを他のプロセスやスレッドに投げて非同期で実行できるミドルウェアです。

はてなではTheSchwartzを使っていました。サムネイル画像を作ったり動画の変換、通知やその他バッチ処理を走らせたりするのに使われていました。

最近だとAmazon SQSとか使ってるところが多いんでしょうか。

必ずしもすべてのアプリケーションで必要なわけではないですが、必要になったときにCommon Lispになければ導入が困難になるかもしれません。

Lesque

そこで2014年の1月に作ったのが「Lesque」です。

これはRubyのResqueを元に作ったメッセージキューでした。作ったタイミングとしてははてなを退職する少し前くらいで、それから新しいWebサービスを作るのに必要だと見越しての開発でした。

blog.8arrow.org

Psychiq

さて、Lesqueを使ったはいいものの当初の予定とはかなり違って、使う機会のないまま日は経ちました。

そして2年後、とうとうLesqueを使えるかもな、というタイミングで見てみると、そのコードは古いですしCommon Lispの環境にもついていけておらず継続して開発するのもためらわれるものでした。この2年でRoswellがスタンダードになったにも関わらずRoswellスクリプトが提供されていなかったり、Travis CIでのテストが行われていなかったり。

メッセージキューの世界でも世代交代がありました。Sidekiqという新しいプレイヤーが現れました。Resqueのプリフォークスタイルではなく、スレッドを使うため高速に動作し、シンプルなアーキテクチャであるということが売りのようです。

そこで新たにSidekiqをCommon Lispに移植することにしました。それが「Psychiq」でした。

blog.8arrow.org

落語Bot

とはいえPsychiqもそれからしばらく使うことはなかったんですけど、先日とうとう使う機会がありました。

11月の末にLINE Botの「落語Bot」をリリースしました。これは落語の定席や落語家のスケジュール検索ができるLINE Botです。現在、その落語会情報のクローリング部分にPsychiqを使っています。

Psychiqを使ってみてJonathanのバグを見つけたりCL-DBIの問題を見つけたりとかありましたが今のところ順調に動いています。

おわりに

PsychiqはGitHubで公開されており、現在のStar数は16です。

明日のアドベントカレンダーは24日目のMitoについてです。お楽しみに。