ハロウィンかぼちゃを育てる

ご近所さんにハロウィン用のかぼちゃを育てている人がいて、毎年ハロウィンになると家の前にかぼちゃで作ったジャック・オー・ランタンを並べている。真似してみた。

ポイント

育てる難易度はあまり高くない。食用かぼちゃと違ってハロウィン用の観賞用かぼちゃは味を気にする必要がない。見た目もきれいな形になるにこしたことはないけれど、いびつだとしてもそれがジャック・オー ・ランタンの味になるので気にすることはない。

難しいのは単純にかぼちゃが大きすぎて扱いづらいということ。できれば協力者が欲しい。

収穫時期はコントロールするのが難しいが、できるだけ遅いほうが良い。ハロウィンかぼちゃは水分が多く腐りやすいので、早すぎるとハロウィンまでに持たずに腐ってしまう。保存方法で工夫の余地はあるとはいえ、収穫して2ヶ月以上持たせるのは難しいようだ。

種購入と苗作り

種はデカかぼちゃとしてはメジャーな品種と思われるアトランティックジャイアントを購入した。ゴールデンウイーク直後に種を植えて発芽を待った。

種まきの時期は地域によっても違うが本来は4月くらいだろうか。私が住んでいるのは仙台で、やや涼しめの気候なので少し遅らせた。

育苗ポットに種をまいてから1週間から2週間程度で発芽した。ちなみにアトランティックジャイアントは食用かぼちゃに比べてこの時点ですでにでかい。

定植

6月、苗に本葉が出てきたところで畑への定植をした。これもやり方は食用かぼちゃと変わらない。

念のため、食用かぼちゃやスイカなど、ウリ科の交配してしまいそうな作物の隣ではない場所を選んだ。

水やりと追肥

その後水やりは適度にしたが、ほぼ放置状態で育てた。

花が咲いたタイミングで祖父が授粉作業をしたりしていたが、授粉していない花にも実が出来たりしたので必須ではなさそう。

実が出来たら形が良くなるように起こしてあげたりした。ただ無理にやるとつるが折れてしまうので無理にはやらないほうが良い。実を大きくするためにはどんどん追肥した方が良いが、あれよあれよという間に大きくなっていくかぼちゃを見て、大きすぎても困るのでしなかった。

収穫

実が十分に育つとやがて実につながる茎が白く変色してひび割れてくる。時期にもよるが、これ以上は腐ってしまいそうだと感じたら収穫する。

保存

保存が一番難しい。

ハロウィンかぼちゃは水分が多く、かぼちゃというよりは「瓜」という感じの実だ。それをハロウィンまで腐らせずに保管するには色々と工夫がいる。

まず、傷をつけないこと。それからよく乾かすこと。特にヘタの部分は水っぽいので収穫直後にドライヤーなどで乾かすこと。木工用ボンドで固める人もいるらしい。その後日陰で風通しの良いところに置いて保存する。

いろいろ策を講じても、ご近所さん曰わくだいたい2ヶ月以上保存するのは難しいようだ。保存に力を入れるよりは実ができる時期を調整したいところだが、天候に左右されるところもあると思うし良い方法を知らない。

夏ごろに出来たかぼちゃは腐らせてしまった。運良くハロウィン直前まで収穫を遅らせることができたかぼちゃもありランタン作りにはそれを使った。

このカボチャは腐ってしまった

運搬

ノリで始めたデカかぼちゃ作りだが、実際に現物が出来てしまうと運搬の問題に直面した。重さもあるが球体なので1人で抱えるのには難があり大きいものは複数人で運ぶしかない。運ぶときにはブルーシートなどに載せてシートの四隅を持って運んだりすると楽だった。

ランタン作り

ランタン作りは思っていたより簡単だった。食用かぼちゃと違ってさほど硬くないし、内部の空洞をそのまま利用するので、筋力に自信が無くても大丈夫。ただしかぼちゃが大きくて時間もかかるので多少は疲れる。

まずかぼちゃの底に直系20cmくらいの穴を開けて、そこからわたを掻き出す。次に顔を作ってあげる。ライトアップはご自由に。

飾る

できたランタンは家の前に置いた。日持ちは天気か良ければ一週間くらいはしそうだ。

夜になるとなめくじが来ることがあってそれはちょっと困っている。対策が必要そう。

まとめ

散歩してる人や子どもたちが面白がってくれているようだし、かぼちゃ作りも適度な難易度があって楽しい。来年もやろうと思う。ランタン作りの際に種もとっておいた。

ScalaMatsuri 2022でCats Effect 3の話をしました

speakerdeck.com

純粋関数型スタイルのプログラミングは私はあまりやって来なかったんですが、たまには違ったことをやってみようかなと思って発表してみました。年末年始にTypelevelの技術スタックをいろいろ見ててhttp4sとかさわってみてたりしたんですが、その過程でCats Effect 3が気になった感じです。

やはり純粋関数型スタイル自体にはそんなに興味ないんですが、Cats Effectのランタイムは面白くて、それに乗っかるためのフレームワークとして純粋関数型スタイルが要求されるというのはそんなに悪くないなと思いました。あと資料作成や準備の過程でCats Effectの作者の方(Danielさん)のトークを何本かYouTubeで見たんてすが面白すぎる。全部面白い。

Scalaは人気のピーク(ピークと言うほどでもない)を越えてしまって少しコミュニティの熱量は下がってるのかなって気がしますね。とは言え個人的には他に乗り換えたい言語もなく、今やるならRustなんだろうけどRustでWebアプリとか作る気にはならないしなあ、みたいな微妙な気持ちです。まあしばらくはplayframeworkのほうをやっていきます。あとPHPとかですかね?(冗談じゃなくて今本業PHPなんです)

Play Frameworkの開発チームに入れてもらいました

Play FrameworkがLightbendの手から離れる という発表が昨年の10月にあったんですが、それをきっかけにやりとりして Play FrameworkのGitHub Team に入れてもらいました。 しばらく待ちの状態だったんですが、先週くらいから動き初めたところです。とりあえず当面はTravis CIからGitHub Actionsへの移行やScala3対応になるのかなと思います。

PlayはLightbendから離れる決定をしたあとからOpenCollectiveで寄付を募っています。 寄付してくれてる方々を見ると日本の方も多いですね。ありがとうございます。 mkurzさんからも感謝のメッセージをいただいてます。引き続きご支援お願いします 🙏

// mkurzさんは私が何か働きかけたように思ってそうだが何もしていない
Also, a high proportion of the current Play backers on Open Collective are Japanese,
so it seems you reached out to the Japanese community already? If so, 
and if you have a mailing list or similar set up, 
would you mind to say thank you to them from me and the other contributors ;)

最近のタグジャンプ事情を調べた

テキストエディタのタグジャンプ機能、最近はどんな感じなのかなあと思って調べていました。 結論としては10年前とあまり変わっていないみたい。というか新しいツールが出てきていなくて、進化が止まっている印象。

ctags

exuberant-ctagsは2009年のリリース以降開発が止まっていて、代わりにuniversal-ctagsというもののメンテナンスが続いていました。 exuberant-ctagsはMacではパッチ当てないとビルドできなかったし、もうかなり厳しそう。でもまだ使っている人多そう。

GNU Global

GNU Globalはそんなにアクティブじゃないけどメンテナンスはされていて、新しいバージョンもぽつぽつと出てました。 Macで最新リリースをビルドして見たらconfigureが通らなかったんだけど、リポジトリの方を見たらそのためのパッチは取り込まれていました。 まだ使えそうではある。

その他

さすがにもっと改良されたやつとか出てきてるだろうと思って調べたけど全然ない。タグファイル作ってタグジャンプする時代は終わったんですね。 最近だとLSPみたいなIDE機能を使うかag/ripgrepとかを使いこなすというのが主流っぽい印象を受けました。

コード書く上ではLSPやIDEが強いけど、コードを読むだけだったらタグジャンプの方が手軽で便利に感じる時もあるので、もうちょっとあってもいい気がするんですけどね。なんかいいのあったら教えてください!

Emacs + Metals + lsp-mode でScalaを書く

最近重たい処理走らせてる時とかにIntelliJが遅くてつらかったのでEmacsでもある程度コード読んだり書けたり出来るようにしました。 最近はLSPが人気あるようでEmacsでもlsp-modeというのが結構使われているみたい。Scalaの場合はLSPとしてMetalsを使うことになります。

設定

  • lsp-modeが入っていればとりあえずOK
  • flycheckを入れてコンパイルエラーの表示が出来るようにしましょう
  • lsp-uiを入れてなんかUIからポチポチ出来るようにしましょう
  • companyをコード補完機能に使いましょう
(use-package flycheck
  :init (global-flycheck-mode))

(use-package lsp-mode
  :hook
  (lsp-mode . lsp-lens-mode)
  (scala-mode . lsp)
  :config
  (setq lsp-prefer-flymake nil))

(use-package lsp-ui)

(use-package company
  :hook
  (scala-mode . company-mode)
  :config
  (setq lsp-completion-provider :capf)
  (setq company-minimum-prefix-length 1))

そんなにガリガリ設定書かなくても割といい感じになるのがすごい。

使い方

  • インストールはMetalsのドキュメントでどうぞ。
  • M-., M-, で定義元にジャンプしたり戻ったりできる。
  • キーバインドの一覧は https://emacs-lsp.github.io/lsp-mode/page/keybindings/
  • 一覧に乗ってないけど s-l g e でエラー一覧表示ができた。ドキュメント更新のpull req送った方良いのかな?

f:id:tototoshi:20210406224447j:plain
コード補完

f:id:tototoshi:20210406224357p:plain
エラーの一覧表示

f:id:tototoshi:20210406224517p:plain
コンパイルエラーの表示と選択できるアクション一覧

トラブルシューティング

デバッグはとりあえず *lsp-log* バッファを見てみると何か分かる。Metalsの場合は .metals/metals.log でも良し。

必殺再起動は M-x lsp-restart-workspace

ハマったとこ

補完がうまく行かないなあ、Any型と判定されるなあとか思ってたんだけど、monorepo的なリポジトリでworkspaceのルートが誤判定されてちゃんとプロジェクトが読み込まれていないのが原因でした。M-x lsp-workspace-folder-add で設定したら補完ができるようになりました。

あと大きなプロジェクトで遅くなるけどファイルをウォッチするか?遅くなるけど?と聞かれた時に読み込まないようにしたら補完が効きませんでした。ウォッチしないとダメなのかな。とりあえずウォッチすることにして、遅くなってから考えることにしました。

制限

今のところ機能的にここが限界だろうなあというのが2つ。

  • 高度なリファクタリング機能
    • さすがにIntelliJには勝てない。なんかすごいことやろうと思ったらIntelliJを起動しよう。
  • Javaのコードを追えない
    • Metals = scalameta + LSP なのでそりゃそうかという感じ。

感想

コード読んだり、調査だったり、ちょっとした修正には十分な機能なので嬉しい。まあガッツリコード書くときはIntelliJだけどそれ以外を軽い環境でカバー出来るのは良いですね。

EmacsをTerminalとして使う

emacs-libvterm っていうのを見つけたのだけどこれがすごく良いので紹介します。

emacs-libvterm

https://github.com/akermu/emacs-libvterm

EmacsにはTerminal系の機能としてterm-modeやeshellなどがあるんですが、遅かったり、クセが強かったりで使えてませんでした。一時期それでも使おうとしてたんですがちょっと無理でした。

それがemacs-libvtermはTerminal.appと遜色ないくらいに速く動いてくれます。しかもtmuxもちゃんと動く。 ちなみにneovim/libvterm というやつを元にしてるみたいなのでvim様には頭が上がらないですね。

f:id:tototoshi:20210401211017p:plain

試し始めはたまになんかもっさりしたり、tigみたいなncurses系のアプリで表示が崩れたりしたんだけどそれは使っている日本語フォントに起因する問題だったようで、 Cicaというフォントにしたら見事に解消しました。

https://github.com/miiton/Cica

Emacs in Emacsしてしまうのを封じる

さて、Emacsの中でシェル使えるようにしてもEmacsの中のシェルでさらにEmacsを開くとわけがわからなくなるのでそれを防止しましょう。emacs の代わりに emacsclient を使って、新たにEmacsを起動するのではなく今起動しているEmacsに新しいバッファを開くようにします。

Emacs側ではサーバーを起動して置いて

;; .emacs.d/init.el
(server-start)

さらに次のスクリプトを ~/bin/emacs として置いておきます。

#!/bin/bash

if [[ "$1" == "" ]]
then
    /path/to/emacsclient -n .
else
    /path/to/emacsclient -n "$@"
fi

逆にEmacsからterminal側に移るにも適宜keybindを設定してterminalとEmacsの行き来を便利にすると良いでしょう。

まとめ

emacs-libvtermを使うことでTerminalの中でEmacsを使うのではなくEmacsの中でTerminalが使えます。このブログはエイプリルフールではなくて真面目に書いたつもりです。

f:id:tototoshi:20210401211035p:plain

TypeScriptでgRPCしたいがいろいろあってよくわからない

用語

  • grpc/grpc-node: Node.js向けの公式プロジェクト
  • grpc-tools: grpc/grpc-node が提供しているパッケージ
  • grpc_tools_node_protoc: grpc-toolsに含まれるコマンド
  • agreatfool/grpc_tools_node_protoc_ts: grpc_tools_node_protocで吐いたコードに .d.ts を付けるサードパーティのコマンド
  • improbable-eng/ts-protoc-gen: TypeScript向けのサードパーティprotocプラグイン

Node or ブラウザ

gRPCのサーバー側はどのツールもNodeを想定しているので特に問題ない。 gRPCのクライアント側はNodeで使うことを想定しているのものとブラウザで動かすことを想定しているものがあるので注意が必要

  • ブラウザ上で動作することとを想定しているもの
    • grpc/grpc-web
  • Node用のもの
    • grpc/grpc-node (grpc-toolsのgrpc_tools_node_protoc)
  • 両方に対応しているもの
    • improbable-eng/grpc-web
      • Transportを切り替えることで両方で使えるっぽい

JavaScript での gRPC

次の2パターンがある。

  • .protoをそのまま読み込む
  • .protoからコード生成したコードを読み込む

TypeScriptから使う場合は型定義を付けたいので後者のコード生成するやり方を選ぶのが良さそうだよね。

grpc or @grpc/grpc-js

  • grpcは開発終了間近
  • 今後は @grpc/grpc-js を使うのが良さそう
  • 両方ほとんど同じだけど @grpc/grpc-js を使う場合、protobufを生成する時に --grpc_out=grpc_js:... みたいなオプションが各ツールによって提供されているので適宜ドキュメントをチェックすべし

TypeScriptサポート

できるだけ公式か公式に近いものが良いなら以下の2つが良さそう。2つあるけど動作環境を考慮すると実質一択なのかな。

  • grpc/grpc-webのTypeScriptサポート(experimental)
  • agreatfool/grpc_tools_node_protoc_tsで公式のgrpc/grpc-node (grpc-tools) に対して .d.ts を付ける

まとめ

  • grpc-webやりたいならgrpc/grpc-web
  • そうでなければgrpc-tools+grpc_tools_node_protoc_tsが一番無難そう
  • 両対応したいならimprobable-eng/ts-protoc-genも選択肢に上がってきそう

おまけ