vim-lspでElm用のVim環境を構築する

ElmCast/elm-vimをやめてvim-lspとasyncompleteを使ってelm-language-serverに対応したVim環境を整えたのでメモ。

github.com

プラグイン導入

vim-plugでvim-lspとasyncomplete系のプラグインを一気に導入する。すでに導入していれば不要。

Plug 'prabirshrestha/async.vim'
Plug 'prabirshrestha/asyncomplete.vim'
Plug 'prabirshrestha/asyncomplete-lsp.vim'
Plug 'prabirshrestha/vim-lsp'
Plug 'https://github.com/IzumiSy/vim-lsp-settings'

最後のvim-lsp-settingsは正しくはmattnさん作のプラグインで、vim-lsp用の設定を自動で適用してくれかつ各言語用のサーバーがなければインストールを実行してくれる超便利なプラグイン。これは絶対あったほうがいい。

しかし、この記事を書いた時点ではelm-language-server用の設定にバグがあり正しくサーバーが起動されなかったため、一旦自分で修正してフォークしたものを使っている。

PRは出しているので、VimでElmの環境を整えたい人は以下のPRがマージされるまでは自分のやつを使ってもらうか、自分でvim-lsp用のelm-language-serverの設定を手で書くのがいいだろう。

github.com

なお、Vimは8.2 patch 929からビルトインでElmのシンタクスハイライト設定を内蔵しているため、もはやElmをVimで書くのにシンタクス用プラグインも導入しなくてよい。

github.com

設定

自分は基本的に各プロジェクトのdevDependenciesにElm関連のバイナリをインストールするのでelm-language-serverの設定としてバイナリのパス設定を追加する。

let g:lsp_settings = {
\   'elm-language-server': {
\     'initialization_options': {
\       'elmPath': './node_modules/.bin/elm',
\       'elmFormatPath': './node_modules/.bin/elm-format',
\       'elmTestPath': './node_modules/.bin/elm-test'
\     }
\   }
\ }

ファイル保存時のフォーマッター実行も追加。

au BufWritePre *.elm :LspDocumentFormat

あとカーソルがある部分の関数やレコード定義を左右分割か別タブで表示する設定も入れている。

nnoremap <leader>df :vert LspDefinition<CR>
nnoremap <leader>tt :tab LspDefinition<CR>

以上、これだけでVimでも補完を効かせてElmが書ける。定義元へも飛べる。

vim-lspの設定はかなり面倒だと思い込んでいたが、実際にはvim-lsp-settingsを入れておけば勝手に言語サーバーのインストールから設定までやってくれるので、ほとんどIDEと体験は変わらなかった。

あとはElmファイルをVimで開くと「elm-language-serverをインストールするか」というような旨のメッセージが出るので、それに従ってインストールさせればよい。elm-language-serverがグローバルインストールされている場合にはそちらが優先されるのかも知れないが、自分は試していない。

2020年6月のクラウドバンク

izumisy.work

今年もふと思い出したので書いてみる。以下が先月時点での収益レポート。

2020年6月の収益レポート

ちょうど新型コロナウイルスが盛り上がってきたのが多分3-4月頃で、その直後しばらく新規の投資案件が出てこなくて非常に心配になった。だが今は新しくスター・マイカとの共同ファンドを出したりするなど、アメリカンファンディングのようにサービス自体が完全停止するということはなさそうである。

投資額も増えてきたからか、税引後収益も1万超えに突入してきた。コロナウイルス真っ只中で6%超えの利回りが出る原理はよくわからないが、おそらく太陽光系案件がコロナウイルスとは関係なく安定して高利回りを生んでいるのではないかと推測している。CEO金田さんもクラウドバンクのセミナーにてFITの権利を入手するルートをクラウドバンクは持っており引き続き高利回りの太陽光案件を出していくと言っていたので、若干期待が持てる。

東京でまたコロナウイルス感染者が増え始めている現状の影響がどの程度出てくるのかわからないが、余剰資金がある限りは少しづつ突っ込んでいきたい。

開発チームの振り返りタイミングのパターン

考えることがあったので雑にメモ。

1. 毎週末（木曜日or金曜日）

• 最も一般的なパターン。木曜日ないし金曜日にその1週間を振り返る。
  • 1スプリントを1weekと置いていれば毎週何らかの成果物があるはずなので、それに対する振り返りがこの時間にあたる。
• 毎週30分-1時間近くの時間を毎週ブロックすることになる。
• 振り返りで出てきたトライを翌日からすぐに始められない（土日に入ってしまう）ため、トライ実施のモチベーションに懸念が残る。
  • 週明けにトライの内容を再確認するなどの工夫で解決できる可能性がある。

2. 毎週明け（月曜日or火曜日）

• 1の問題点であったトライ実施のモチベーションが改善され、翌日からモチベーション高くトライを意識できる。
• 一方で、振り返る内容は先週のものになるためメンバの振り返りに対するモチベーションが低くなる懸念がある。
  • 振り返りに対するモチベーションの低下すごく致命的で、これが起きてしまうとそもそも振り返りの時間そのものが遊んでしまう。
  • 開発過程での課題を記録しておいてもらうなどの方法も考えられるが、基本的に人間は「忘れずになにかをやる」というのは不可能であると考えたほうがよいため、あまりまともなアイデアではない。

3. 開発アイテム終了後

• 定期での振り返りを実施しないかわりに、開発アイテム単位で振り返りを実施する。これによって毎週1時間を必ずブロックされることがなくなる。
• 少なくとも毎週定期で振り返りをするよりも凝縮されたものにはなるが、一方で開発期間が長いアイテムの場合には開発中に発生した課題を誰かが記録していないとすぐに情報が失われてしまうため、振り返りのタイミングで「なにも覚えてない」の状態になる懸念がある。
• 「振り返りをするアイテム」と「振り返りをしないアイテム」の定義も必要になる。
  • 開発メンバ全員、開発メンバ個々人、リーダー／マネージャで見えている風景が異なるため、振り返りのモチベーションに対する合意をとるコストが発生する場合もある。この意思決定をナアナアにしたり無視したりすると今度は振り返りに対するモチベーションに影響がでる。

4. 振り返りを不定期実施にする

• 朝会のタイミングで問題定期をしてもらうなど、不定期的になんらかの問題が起きたタイミングで開発プロセスに対する改善を加える。
• 一方で、集団で話しながら振り返りをするということがなくなり視点が個々人に閉じるため、振り返りの対象が近視眼的なものになる懸念がある。
• メンバーのモチベーションにもよるが「場がなければ行動を起こせない」という性質のチームであると基本的に自主的な改善は発生しない。

振り返りのROI

「振り返り」はチームの中で気づいた改善点や強みを共有しあうことで改善のサイクルを回し、より効率のよい開発を行えるようにするための重要なプロセスのひとつである。

一方で我々の時間は有限であり、週あたりの労働時間において「振り返り」が占める時間と、その「振り返り」から生まれる結果に対して、振り返りを実施する人間は気を配る必要がある。振り返りをしたからと言って必ずしもチームのアウトプットの質が改善されるわけではなし、振り返りをしなくても自律的に改善が行われるチームもある。振り返りをしなくても自動的にチームが良くなるような高ROIなチームなら、敢えて時間をとる必要もない。

そのようなチームはいわゆる自己組織化されたチームと呼ばれるものであるが、そのようなチームにおいてはルール化／フレームワーク化された仕組みはただ単に形骸化するどころか逆にチームのパフォーマンスの足かせにもなるため、注意が必要だと言える。

アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き

shelm: 脱法Elmパッケージマネージャー

elm/core などのカーネルモジュールにバグがあるとき、公式のバグ修正を待っていられないことがある。物によってはアプリケーションの動作に大きな影響があったりして早急な修正が必要になる場合もある。

そのような場合にはshelmを使うことで、自分たちで野良フィックスを取り込んだカスタムの elm/core が使えるようになる。

github.com

原理としてはelm-git-installと近い。

Elmアプリケーションのビルド時に使用されるelm-stuff配下のデータを先に作ってしまい、キャッシュされていることにしてpackage.elm-lang.orgからダウンロードできるものと置き換えている。

使い方

例えば、カーネルモジュールであるelm/timeを自分たちでカスタムしたもので置き換えたい場合には、次のようにlocationsフィールドをelm.jsonの中に新しく作り、オーバーライドする手段を指定する。

"dependencies": {
    "direct": {
        ...
        "elm/time": "1.0.0"
    },
    "locations": {
        "elm/time": {
            "method": "github",
            "name": "IzumiSy/elm-time"
        }
    }
}

methodのセクションにはgithubだけではなくfileも指定できる。

    ...
    "locations": {
        "elm/time": {
            "method": "file",
            "name": "../my-pkg/time"
        }
    }

あとはshelmでfetchを叩くことでelm-stuff配下にローカルパッケージのキャッシュデータを作らせることができる。

$ ./shelm fetch

あとはいつもどおりelm makeすればよい。

ほかにもいくつか機能があるが、それに関してはREADMEを読むか実際のコードを読むことで理解できると思う。shelm自体は1ファイルのシンプルなシェルスクリプトであるため、とくに複雑なものでもない。

余談: shelmはなぜ脱法か

このshelmの存在は、ElmlangのSlackワークスペースで「カーネルパッケージにあるバグを一時的に治したい場合にはどうすればよいか」という質問への回答として得られたものであるが、基本的にはElmのコミュニティにおいては脱法である。

shelmのREADMEにも"Note: Best not talk about this on the offical Elm channels unless you're trolling."（Elmの公式チャンネルでshelmについて話さないこと）と書かれていることからもそれが分かる。

Elmのカーネルモジュールにはポートを使わずにJSとのデータをやりとりできる基盤が存在しているため、容易に実行時例外を発生させるコードを書くことができてしまう。しかし公式はElmのことを「実行時エラーの存在しないAltJSである」と謳っていることから、カーネルモジュールに対する機能追加には非常に慎重である。また、Elmを使う人達の体験を損なわないためにも、shelmのようなElmの概念を揺るがす存在には厳しく目を光らせている。

いずれにせよ、実行時エラーのない言語としてElmを使うのであれば、自己責任のうえでshelmの利用は如何ともし難いカーネルモジュールのバグ修正程度に留めるべきだ。

Fitbit Charge 4でSpotifyアプリ連携がインストールできない場合の対処法

Fitbit Charge 4を買った

Fitbit Charge4 GPS搭載フィットネストラッカー Black/Black L/Sサイズ [日本正規品] FB417BKBK-FRCJK

Spotify連携が利用できない

Charge 4には、Bluetoothで接続している端末と連携してSpotifyをコントロールできる機能がある。

しかし、買った直後その機能が有効にできないトラブルに遭遇した。

有効にしようとFitbitアプリからSpotifyアプリを選択しても、デバイスのバージョンが古いなどと言われSpotify連携がインストールできない。

インストールできない

解決策: アップデートを待つ

身も蓋もない解決策だが、大体24時間ほど待つと唐突に新しいアップデートが利用できるようになり、これをインストールするとSpotify連携が有効になる。

新しいアップデート

上記のファームウェアアップデートのインストールが完了すると、以下のようにめでたくSpotify連携が利用できるようになる

Spotify連携が利用できる旨が表示される

自分はCharge 4のセットアップ時に、すでにデバイスのアップデートを1度実行している。

しかし、どうやら初回時点のデバイスアップデートとは別のアップデートを受け取らないとSpotify連携を有効にすることができないらしい。

nvmやrbenvを遅延ロードさせる

nodeとかrubyとか特定のコマンドを使うときまでバージョンマネージャのローディングが遅延できたらなー思って調べてみたら、alias/unaliasを用いて遅延ロードっぽいことをやるテクニックを知った。

例えばnvmは以下のようにnodeやnpmなどのようなコマンドが呼び出されたときに初めてロードさせられる。

export NVM_DIR="$HOME/.nvm"
if [ -e "$NVM_DIR/nvm.sh" ]; then
  alias nvm='unalias nvm node npm && . "$NVM_DIR"/nvm.sh && nvm'
  alias node='unalias nvm node npm && . "$NVM_DIR"/nvm.sh && node'
  alias npm='unalias nvm node npm && . "$NVM_DIR"/nvm.sh && npm'
fi

やっていることはシンプルで、nvmが必要なコマンドにaliasを貼っておき、コマンドが必要になったときにはじめてnvmが初期化されるようになっている。

一度呼び出されたらunaliasするので、次回以降はnvmの初期化は行われない。

同じくrbenvもやれる

export PATH="$HOME/.rbenv/bin:$PATH"
if [ -e "$HOME/.rbenv" ]; then
  alias ruby='unalias ruby bundle gem && eval "$(rbenv init -)" && ruby'
  alias bundle='unalias ruby bundle gem && eval "$(rbenv init -)" && bundle'
  alias gem='unalias ruby bundle gem && eval "$(rbenv init -)" && gem'
fi

なお、元ネタは以下のツイートの記事。

Love this technique to achieve lazy loading of nvm and rbenv! They are too slow to run at terminal startup😂 https://t.co/OOBRtFF0ep

— IzumiSy™ (@sy_izumi) 2020年5月23日

Intellij IDEAのVMオプションとVSCodeの設定をイジってフリーズを減らす

去年末にお金をケチって買ったiMac 2019(Core i3 3.6 GHz, 8GB)でIntellij IDEAとVSCodeを起動していると、文字の入力もできないくらいレインボークルクルが頻発して仕事どころじゃないことがここの所よくあった。

数年前に買ったThinkCentreで動かしているUbuntuのほうがまだ快適という謎もあり「さすがにコレはどうにかしたい」という強い意思からいろいろ調べてみた。

結果、どうやらアプリケーションが使うメモリサイズが大きすぎて、GCによるストップ・ザ・ワールドが頻繁に起こっているっぽいということが分かってきた。CPUをケチったせいでGCを捌ききれず、結局8GBもメモリを積んでいても無駄になるとは悲しい...

Intellij IDEAの設定

ということで、最大メモリサイズを1Gまで減らしみると、見違えるほどフリーズ時間が減った。

あとから気がついたが、実はUbuntuで動かしていたIntellijは元から最大メモリサイズが少なめの設定になっていた。こりゃどうりでサクサクなわけだよ。

-Xms128M
-Xmx986M
-XX:+UseConcMarkSweepGC
...

なお、G1GCみたいなメモリがたくさん使えること前提のGCアルゴリズムを選択するのもたぶん良くないだろうとということで、とりあえずConcurrent Mark Sweep GCを代わりに指定しておくことにした。

VSCodeの設定

また、VSCodeもそこそこ大きいGoアプリケーションを開くとレインボークルクルの頻発につながっていて非常に鬱陶しかったので、ファイルで使う最大メモリをデフォルト4GBとなってたところ1GBまで落とした。

加えてwatcherExcludeに.gitディレクトリ配下を追加してみた。

{
    "files.maxMemoryForLargeFilesMB": 1024,

    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/node_modules/**": true
    }
}

これだけでめちゃくちゃいい感じになった。今までのストレスはなんだったのか。

メモリがたくさんあるからといって全部使えるとは限らない好例だったと思う。たくさんメモリを使うには、性能のいいCPUも必要ということが分かる。作業マシンへの投資をケチってはいけない。

ガベージコレクション

gcloudコマンドでGAEアプリケーションデプロイ時に指定できるバージョン名には使える文字種に制限がある。

gcloud app deploy コマンドを使ってGAEアプリケーションをデプロイする際には--versionというオプションを使うことでバージョン名を自分で指定できるので、ブランチ名とかIDとかをバージョンとして出したくなる。

しかし、試しにブランチ名を含めてバージョンに指定してみたら以下のエラーが出た。

May only contain lowercase letters, digits, and hyphens. 
Must begin and end with a letter or digit. Must not exceed 63 characters.

つまり、バージョン名には小文字、数字、ハイフンしか含められないとのこと。

なので、もしブランチ名をバージョンに含めようとすると fix_123 みたいなブランチ名のアプリケーションだけデプロイできないことになる。 あと、ブランチ名が長いのもNGだし、大文字が入っている場合もNG。

なので、結局コミットIDだけ含めることにした。正直もうちょっと使える文字種の制限を緩めて欲しい...