Emacsからlemに移行した
ずっとEmacsをメインエディタとしていましたが、先月lemに移行しました。
lemはCommon Lispで書かれたエディタです。
「なんでLem使わないの？」って訊かれたから、試してうまく動かなかったところを具体的にリストアップしたら凄い勢いで改善されててだんだん使わない理由がなくなってきてる。外堀埋められてる感ある
— fukamachi (@nitro_idiot) 2018年7月9日
そもそも自分はCommon Lisperだしlem使うほうが資産がCL界に降りてきて良いよな、という考えもあり使いたい気持ちはありました。
vi-modeさえまともに動けばまあ他の不便は我慢できるか、という状態だったので、vi-modeのバグを上げて修正と機能追加をしつつ使い始めてみました。
結果、なんとか使い続けられています。
lem使い始めて1ヶ月経ったらしい。 https://t.co/hVtGxpfi9l
— fukamachi (@nitro_idiot) 2018年8月11日
この1ヶ月でEmacsを使ったのはSwift書くのに数日だけでした。さすがにシンタックスハイライトもないのはつらい。
活発な開発
lemには毎日コミットがあり「Common Lispプロジェクトでもっとも活発なのでは…？」と思うほど。
この1ヶ月でコミットは200を超えており、今日めでたくv1.4がリリースされました。
- vi-modeの改善 by fukamachi & gos-k他
- css-modeの追加 by myao
- auto-save-modeに自動保存機能追加 by snmsts
- ファイルエンコーディングエラーの対応 by snmsts
- js-modeのオートインデント機能 by fukamachi
- paredit-modeの部分実装 by gos-k & fukamachi
さらにリリース直後にrust-modeが追加されたりと勢いが衰えていない様子。
lemの良いところ
lemの良いところは起動が速いところです。
拡張も含めてダンプコアを吐くので起動が素のVim並に速いです。
起動が速いのでシェルと行ったり来たりできるため、必要ならシェルとの連携もできます。
たとえばQlotを使うには qlot exec lem とかやればlemのREPLがプロジェクトローカルなquicklispを参照します。
Common Lispで書かれているので拡張もContributeも楽です。
lemを使ってみませんか
特にCommon Lisperの方々、lemを使ってみませんか。
インストールはRoswellでできます。
ros install cxxxr/lem
インストールすると lem で起動できます。SLIMEは M-x slime で起動できます。
設定は ~/.lem/init.lisp に書きます。たとえばvi-modeを有効にするには、
(lem-vi-mode:vi-mode)
と書いておけば自動で有効になります。
僕の .lem はGitHubで公開しているので参考にどうぞ。
https://github.com/fukamachi/.lem
lemのバージョン更新もRoswellでできます。
ros update lem
普段使い以外にも、 git config —global core.editor lem とかしておくとコミットメッセージをlemで書けるのでおすすめです。
Mackerelで家族のヘルスチェックをする
5月に入院して1ヶ月くらい療養していました。
健康にも気をつけないとな、と今更ながら反省しつつ、どうすれば健康管理ってできるのかなと考えてみています。
Fitbitログから学ぶ
一年半前からFitbit Charge 2で心拍数と睡眠時間を記録しています。運動量ではなく、主に睡眠時間を計測するためにつけています。
普段は計測するだけして結果を見ることはほとんどないのですが、「今日は頭が働かないな」というときにふとFitbitのダッシュボードを見ると「なんだ睡眠不足か」とかわかるので便利です。
人によって必要な睡眠時間は異なります。僕は週の平均睡眠時間が7時間を切ると体調が悪くなるようです。
入院中に思い立って過去のFitbitのデータをさかのぼって見返してみると面白いことが見つかりました。安静時心拍数が見事に入院まで右肩上がりで推移しています。
fitbitのログを見返していると安静時心拍数が跳ね上がって入院とともに下がっていることがわかる。
— fukamachi (@nitro_idiot) 2018年5月20日
せっかく心拍数をトラッキングしているから、それをストレスレベルとしてアラートが来るようにできないかと設定を探してみたけど見つけられず。 pic.twitter.com/pQVHQJZeZ7
単純な心拍数だけだと歩くだけでも上がりますが、これは安静時心拍数。なにもしていないときの平均値です。
もともと自分は安静時心拍数68〜74を推移していたのですが、入院前に88まで跳ね上がっていました。
安静時心拍数が高すぎる場合は頻脈と呼ばれるようです。
頻脈で疑う鑑別疾患は血液疾患（貧血）、精神疾患（緊張、ストレス、不隠、不安）、代謝疾患（甲状腺機能亢進症、脱水）、発熱、呼吸器疾患（低酸素状態）、心疾患（頻脈性不整脈群、心不全、心筋炎：徐脈もあり）等々様々な状態で見られうる。
要因はおそらく「貧血」か「ストレス」か「発熱」でしょう。
安静時心拍数は異常がなくても上下するのですが、一日の中で出社している時間は高く、家に帰ってくると下がります。
仕事中でも特に上がっている時間帯は会議中だったりして、会議中にストレスかかってるのだな、とか分析できます。
けれど、入院してから頻脈だったことがわかったところで遅すぎます。悪くなる前にこれを知れたらいいのに。
Fitbitの機能として心拍数のアラート通知はありません。
アラートといえばMackerelさん
そこでアラートといえば、と考えに上ったのがMackerelでした。
サーバー監視サービスのMackerelはメトリクスのグラフ化だけでなく閾値での警告通知をしてくれるはずです。そこにデータ投げればいいんじゃない？と思ってやってみました。
Fitbit Web APIを叩いてMackerelに流すだけの簡単なスクリプトを書いて、さくらVPSに設置してcrontabで5分おきにFitbit→Mackerelに心拍数などのデータを流す。
やってみた
↓僕 (Eitaro) の心拍数(左)と睡眠時間(右)
これは薬の副作用であまり寝られていないときのグラフです。
睡眠時間の折れ線が複数あるのは睡眠レベル別の時間です。Fitbitでは浅い睡眠、レム睡眠、深い睡眠、睡眠中の覚醒時間を計測できます。
↓これは実際に来ているアラート画面。
meymao(妻)の睡眠時間アラートも来ています。妻もFitbit Alta HRをつけているので睡眠時間と心拍数を計測しています。
夫婦で普段からSlackを使っているので、MackerelのSlack IntegrationをつけるとSlackにも流れます。
これは5時間程度しか寝られなかったときの通知。
睡眠レベルを使って熟睡できていないときもアラートが来るようにしています。
さすがに心拍数を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での経験から言えば、油谷さんの不安は理解はできるけれども、あんまり心配しても仕方ないのでは、と思うわけです。
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では慎重に抽象化を行いました。具体的にはdefclassをCREATE TABLE文と紐付けるメタクラス層と、そのメタクラスをData Access Objectとして扱えるようにするメタクラス層で分離しました。
また、Integralではdefclassの:typeをRDBMSのカラム型に変換できる機能もあったのですが、Mitoではそこまでの高度な抽象化はしませんでした。そのため少し保守的な設計になっていますが、何よりちゃんと動くことが大事です。
最近は僕もいくつかのプロジェクトでMitoを使っており、マイグレーションも含めて問題なく動いています。
名前の由来
どうでもいいことなんですが、「なんでMitoって名前なんですか」とサムライトの社内ミーティングで訊かれました。
Mitoというのは京都市動物園にいるアジアゾウの「美都」からつけました。
これは猛暑真っ只中の写真で、飼育員さんに水浴びしてもらっているところです *1。
飼育員さんがプールに入らせようと好物のりんごをプールに放ったのですが、プールが嫌いな美都は鼻を伸ばしてりんごだけ取っています。水こわいけどりんごは食べたい。
なぜアジアゾウの名前をつけたかというと。
昔、ElephantというCommon Lispのオブジェクトストアがありました。このAPIはよくできており、CLOSオブジェクトを永続化させるという高度な抽象化を行っていました。このElephantには問題も多かったのですが、目指した夢としての印象は僕にとっては強烈で、僕のORMにもその心意気は込めたいと思ったからです。あと愛着が湧くからです。美都かわいい。
まったく技術的な話ではありませんでした。
おわりに
MitoはGitHubで公開されており、現在Starは35ついています。
明日のアドベントカレンダーは最終日25日目のUtopianについてです。お楽しみに。
*1:写真は2013年当時のゾウ舎。今はゾウ舎が移築されて広くなっており、ゾウも4頭増えています。しばらく美都は奥のゾウ舎から出てこなくてまったく会えなかったのですが最近は見られるのでしょうか。
