6月ですよ！今年も梅酒を漬けましたので記録をしておきます。 今年の材料は以下の通り: 梅: ヤオコー和光丸山台店で売っていた南高梅1袋。多分1kgくらい。 砂糖: 日新製糖の中ザラ糖1kg。中ザラ糖でつけるのは2020年以来ですね。 酒: 美峰酒類製造、酔仙酒造販売のホワイトリカー「果実の泉」1.8L 今年はカインズでPET製の果実酒瓶 が売っていたので、そちらを使用しました。丸いガラス瓶は「ぽい」んですけど、割れそうで気を遣うし、床面効率も良くないんですよね。 最後にテプラでレシピを記録。これまで買っていたガラス瓶はだいたい説明書にメモを書いておく欄があって、それを切って使っていたのですが、今回はなかったのでテプラでメモをすることにしました。 昨年の梅酒 はこんな感じになっていました: 昨年はホワイトリカーに氷砂糖という、かなり標準的なレシピで作りましたので、ザ・梅酒という感じのスッキリとした味でした。 また来年お会いしましょう！

これまで、emacs上で行ごとの変更状況を表示するのに、git-gutter.el を使用してきました。約4年前 から使用しており、今現在でも問題なく動いているため特に不満はなかったのですが、emacs-jpでdiff-hl の話を聞き、見た目が良いな、と思ったのでdiff-hlに移行しました。 git-gutterの見た目: diff-hlの見た目: fringeを使用するようになったことでフレームが少しスッキリしました。 問題が一点だけあって、私は普段macOS上でemacs-mac を使用しているのですが、frameを複数に分割したとき、一番左のwindowでは問題なく表示されたのですが、右側のwindowでは縦フチが表示されませんでした。 emacsを起動した後に手動で(fringe-mode '(9 . 8))などとしてfringeの幅を広げると上手く表示される一方、default-frame-alistに広げた幅を入れても何故か上手く表示がされない状態で起動してきたため、diff-hl-modeを有効化した後に幅を広げないと上手く調整がきかないのか、と思ったので、次のようにdiff-hl-modeを呼び出してset-frame-parameterする形で解消しました: 1 2 3 4 5 6 7 8 9 10 11 12 ;; show git diff parameter on fringe (use-package diff-hl :ensure t :diminish :hook (magit-post-refresh . diff-hl-magit-post-refresh) :init (global-diff-hl-mode) ;; somehow the left line is not drawn well without setting left-fringe ;; parameter after diff-hl-mode is enabled (diff-hl-mode) (set-frame-parameter nil 'left-fringe 9) (diff-hl-flydiff-mode)) 正直イマイチ感がすごいので、良い解決方法をご存じの方がいたら教えてください。 ...

かれこれ半月ほど経ってしまったのですが。 昨年末にCloud Native Computing Foundationの日本チャプターとしてCloud Native Community Japanが発足しまして、そのサブチャプターとしてKubernetes Upstream Training Japanが立ち上がり、第一回のイベントとしてKubernetes Upstream Training Japn 2024-03 を実施しました。 資料などはGitHubのリポジトリ に上がっているので見ていただくと良いのですが、要するにKubernetes にコントリビュートをしてみたいけど何から始めれば良いのかわからない・・・という人向けに、Kubernetesコミュニティではどのように普段コミュニケーションをとっていて、どういう手順でコントリビュートをすれば良いのか、という解説をしたり、実際にコントリビュート体験をしてもらったりするイベントでした。 なにせKubernetesというのは世界中で使われている大きなソフトウェアで、英語がさらっと読める人は良いのですが、日本人としてはやはり英語が苦手だという人も多いですし、まして技術力が求められ(そうに見え)るところに飛び込んでいくというのはなかなか勇気が要るモノです。そんな人の背中を押して、日本のKubernetesコミュニティをもっと盛り上げていこう、というのがこのイベントの目的であるわけです。 次回開催はいつになるか不明ではありますが、Kubernetes(特にkubernetes/website )にコントリビュートしたい！という人は積極的にサポートしていく所存でありますのでお気軽にご連絡ください。

大学時代の恩師であるところの工藤峰一教授が退官なさるということで、最終講義と祝賀会に行ってきました。 4月からは新しい方が着任なさるという話ですが、研究室の名前も変わるかも知れませんし、PRMLくんももう見られなくなるかもしれないですね

このブログは現在、Hugo という静的サイトジェネレータを使用してページを生成しているのですが、このHugoには多くの便利機能があり、そのうちの一つがImage processing です。 テンプレートの中で、ほんの数行のコードを書くだけで、画像のサイズを調整したり、切り抜いたり、あるいはぼかしたりすることもできます。これまでのところ、このブログでは画像のサイズは結構適当で、場合によっては表示の幅が変わってしまって見栄えが良くないということが(たまに)ありました。 そこで今回、HugoのImage processing機能のうち、Resizeを使用して、実際にサイトが表示されるときの画像を良い感じにしようと思ったのですが、サイト全体の画像描画部分にhookをかけたところ、エラーが出てビルドができなくなってしまいました。エラーメッセージの大半はファイルパスで、今回は本筋ではない上に長いので端折るとして、重要そうなところを抜き出すと次の様な感じ: 1 2 execute of template failed at <$image.Resize>: error calling Resize: : resize : png: invalid format: invalid checksum 要するに、Resizeしようとしたときに、checksumが合わないので対象のpng画像ファイルがおかしい、ということらしいんですよね。しかしこれまでこのブログを更新してきて、(パスとかが間違っていない場合に)画像が表示されなくて困ったこともないし、そもそもpngファイルにchecksumがあるなんてことも知らないし・・・ golang/go#43382 での会話を見たところによるとどうやら、pngファイルには「チャンク」と呼ばれるモノが存在して、これが無視できることも多い(特に実際に表示する時には不要なモノが多い)けれど、Goのimage/pngは今のところはそれらを無視せず、エラーを吐くことになっている、ということらしい。 エラーの対象となったファイルを、issueの説明に書かれているようにpngcheckにかけてみると次のようにCRCエラーがあることが分かりました: 1 2 3 4 5 6 7 $ pngcheck -v arch-1.png File: arch-1.png (272304 bytes) chunk IHDR at offset 0x0000c, length 13 1082 x 778 image, 32-bit RGB+alpha, non-interlaced chunk zTXt at offset 0x00025, length 188903, keyword: mxGraphModel CRC error in chunk zTXt (computed c3f0b5f1, expected 1ce878d9) ERRORS DETECTED in arch-1.png なるほど、zTXtというチャンクがあって、そこのCRCが間違っている、ということらしいですね。キーワードはmxGraphModelということで、分からないけど多分グラフに関連したモノが入っているのでしょう。確かにこのファイルはdraw.ioで書き出したもので、書き出しの時に編集情報のようなものを埋め込むオプションを有効にした気がするので、それがどこかのタイミングで壊れ、今回のエラーにつながった、という流れの様です。 ...

近年、テキストエディタ/IDEの機能はますます複雑となり、プログラミング言語の数は増え、その組み合わせは膨大なものとなっています。元来テキストエディタはそれぞれがそれぞれの実装でそれらの組み合わせを実現してきましたが、自動補完、定義ジャンプ、ドキュメントの表示など、概ねその基本的な機能は同じであるにもかかわらず、すべてのエディタ開発者はそれぞれが車輪の再発明を行う必要があったのです。その問題を解決するために設計開発されたのがLanguage Server Protocol(LSP)であり、ここ数年で多くのテキストエディタが採用したことにより名前くらいは知っているという人も多いのではないでしょうか。 Tree-sitter はある意味でLSPあるいはLanguage Serverと呼ばれるものに似ています。Tree-sitterは、プログラミング言語の文法から構文解析器を自動生成するパーサージェネレーターツールであり、またそれを使用した構文解析ライブラリです。 Tree-sitterは任意の言語を解析できる汎用的なツールで、動作が速く、依存が少ないツールです。2018年にGitHubからリリースされ、emacs 29.1ではbuilt-inの機能として使えるようになりました。 Emacs x Tree-sitterの仕組みと導入 emacsでTree-sitterを使うには、2つの条件があります: 使用したい言語のパーサーが実装されている Tree-sitterに対応したmajor modeが実装されている 使用したい言語のパーサーが実装されている 当然のことながら、Tree-sitter用に文法が定義されている必要があります。使用したい言語のパーサーが既に誰かによって実装されているかは、available-parsers のリストを参照すると良いでしょう。概ね、メジャーどころの言語は実装されておりほとんどの場合困ることはないと思います。各言語の文法定義(grammar)はJavaScriptで定義し、tree-sitter CLIを使用してC言語のソースコードに変換し、最終的にはそれをコンパイルして使用します。 emacsの場合、~/.emacs.d/tree-sitter/ディレクトリにコンパイルされたダイナミックリンクライブラリを置くことで読み込むことができます。予めコンパイルされたものを置く、でも良いのですが、treesit-install-language-grammarを使用すると文法をダウンロードしてきて配置してくれるため簡単です。treesit-install-language-grammarを使用するには、まずtreesit-language-source-alistに言語とgitリポジトリのペアを定義します。その後treesit-install-language-grammarに言語を渡すことでgit cloneからコンパイル、配置まで行ってくれます。 例えば、YAML用の文法を導入するには次の様に定義します: 1 2 (setq treesit-language-source-alist '((yaml "https://github.com/ikatyang/tree-sitter-yaml"))) そして、(treesit-install-language-grammar yaml)(もちろんM-xでやっても良いと思います)とするとYAML用の文法がインストールされます。私はこの手のものはemacsの起動時に自動で導入されてほしいので、次の様にしました: 1 2 3 4 5 6 7 8 9 (setq treesit-language-source-alist '((yaml "https://github.com/ikatyang/tree-sitter-yaml"))) (dolist (element treesit-language-source-alist) (let* ((lang (car element))) (if (treesit-language-available-p lang) (message "tree-sistter: %s is already installed" lang) (message "tree-sitter: %s is not installed" lang) (treesit-install-language-grammar lang)))) Tree-sitterに対応したmajor modeが実装されている emacsでTree-sitterを使用したい場合、残念ながら、LSPを使用するときのように、単純にパッケージを追加すればすべての言語でよしなに動く・・・という風にはなりません。emacsでは今までのところ、major modeがシンタックスハイライトを提供するためには主に正規表現などが使用されてきました。正規表現を利用したシンタックスハイライトと、Tree-sitterを使用したシンタックスハイライトは大きく違うため、ほとんどのmajor modeではそのままTree-sitterを採用する形にはならず、Tree-sitter専用のmajor modeが提供される形になっています。emacs29ではメジャーどころの言語に対するTree-sitter対応モードが提供されています 。 手動でこれらのモードを拡張子ごとに設定しても良いのですが、major-mode-remap-alistを設定することで、従来のmajor modeをそのままTree-sitter対応のモードに切り替えることができます。 例えば、yaml-modeの代わりにyaml-ts-modeを使用する場合次の様に設定します: 1 2 3 4 5 6 (add-to-list 'major-mode-remap-alist '(yaml-mode . yaml-ts-mode)) ;; or (setq major-mode-remap-alist '((yaml-mode . yaml-ts-mode))) この設定によって、yaml-modeでバッファが開かれる場面ではすべてyaml-ts-modeが使用されるようになります。今のところ、hookなどの設定は移行されないため、これらは個別に設定を移行する必要があります。 ...

2024年最初のテックカンファレンスとして、YAPC::Hiroshima 2024 に参加してきました。 YAPCはPerlのイベントで、“Yet Another Perl Conference"の略です。twitterハッシュタグは前回に引き続き#yapcjapan でした。 広島に来たのは2017年にOSC2017 Hiroshima 以来2度目です。前夜祭、アフターイベントがあるうえ三連休に絡んでいるということで、木曜日の午後に広島入りして、月曜の夜に帰るという4泊5日という計画としました。なお、弊チームではPerlを使用していないため業務ではなく趣味なのですべて自費です。 前夜祭 前夜祭は本編と同じ会場で、2本のトーク(?)と番宣リレーという企画がありました。以下ハイライトです: 妻から連絡が来たが「登壇中です」のみを返す実績を解除しました。 — そーだい@初代ALF (@soudai1025) February 9, 2024 登壇しながら明日のLTの資料作ってる #yapcjapan — そーだい@初代ALF (@soudai1025) February 9, 2024 そーだいさんクラスになると登壇しながら資料を書ける、学びですね(?) 本編 本編は3トラックで開催されました。次のセッションを聞きました: コミュニティと共に生きる - キャリアの螺旋と人生を変えた瞬間 (再演) 関数型プログラミングと型システムのメンタルモデル Blogを作り、育み、慈しむ - Blog Hacks 2024 非同期な開発体制を支えるドキュメント文化 PerlでつくるフルスクラッチWebAuthn/パスキー認証 平成のエンジニアから令和のエンジニアへの遺言〜技術情報を伝達する手段の変遷〜 ライトニングトーク キーノート どのセッションももちろん最高だったんですけど、やはり最高of最高はとほほさんによるキーノートでした。 正直これまでカンファレンスで話を聞いたどのレジェンドよりも「実在の人物だったんだ・・・」感がありました。いやまぁそりゃ、実在の人物でしょうけれども。 個人スポンサーノベルティはこてでした。SmartHRさんもこてを配っていたのでもらいました。右手と左手で、ひっくり返すのに便利かとおもったので。この時はまさかあんなことになるとは思ってもいなかった・・・！ 懇親会 今回はなんと懇親会あり。YAPCとしては実に5年ぶりの懇親会だそうです。永遠に時間が足りないですね。困った。 二次会 各社による半公式二次会があるのも知ってたんですが、なんとなくまぁ申し込みをしないでおいたんですよね。野良二次会やりたくて。なので野良二次会をやりまして、同じ会社の人と実質初めましてですね、Slackではお世話になってます的な話をするなどしました。 YAYAPC::Hiroshima アフターイベントとしてYAYAPC::Hiroshima にも参加しました。なんだかんだ三日間。すごい。 テーマは"What you live"ということで、オフラインだからこそ話せること、ということで、まぁTwitterを見てもらうとわかるのですが、インターネットで共有はできないものの、みんなわかる・・・！という感じで、うめき声みたいなツイートが発生していました。 ぼーっとしている間にLT枠が埋まってしまっていたので、応募すればよかったかな〜などと思っていたのですが、当日、タイムテーブルミスったからLT枠がある、ということで飛び入りで怪しい話をさせていただき、なんと賞まで頂戴いたしまして、結果的に個人スポンサーノベルティのこてが2本と相成りました。いやー、これにはびっくり。大変ありがたいことです。 終わった後は12人ほどで飲みに繰り出しまして(17時頃)、途中人が多少入れ替わりつつ飲み続け、23:30頃に解散しました。 これは死んでる @songmu san #yayapc #yapcjapan pic.twitter.com/vFajihV2vC — nasa9084@某某某某(0x1e) (@nasa9084) February 11, 2024 そして解散した後は深夜だというのに一人でお好み焼きを食べるなどしました。お好み焼き美味しい。 ...

私は普段、railwaycat/emacsmacport を使ってインストールしたemacs-mac を使用しているのですが、何故かmacOSをSonomaにアップグレードしたらタイトルバーが太くなりました。 macOS SonomaにしたらEmacsのタイトルバーが太くなった…！ によると、次の設定を入れるとなおるようです: 1 2 (tool-bar-mode 1) (tool-bar-mode 0) うーん、起動も遅くなったっぽいし、workaround感がすごい。わかんないですけどなんかフレームの初期化に失敗しているとかそういう感じなんでしょうか。 emacs-macの方で修正を入れてくれている様子 なので、リリースされるまではこのworkaroundでしのいでおくくらいしかできなさそうです。

2024年、新NISAが始まりましたので、手数料が高いTHEOを解約して新NISAに移すことにしました。LINE証券 と同様、記録を残しておきます。 2018年9月3日: THEO登録、10,000円/月で積み立て設定 2018年10月15日: 初回入金 2020年2月20日: 20,000円/月に積み立て設定変更 2022年3月28日: 10,000円/月に積み立て設定変更 2023年12月29日: 最後の積み立てが終了 総積立額は880,000円、トータルリターンは330,325円 (+37.54%)でした。 以上です。

あけましておめでとうございます。本年もよろしくお願いいたします。世間では新NISAが話題ですが皆さんいかがお過ごしでしょうか。 扨、LINE証券がサービス終了ということで、LINE証券で積み立てていた投資信託をメインの証券口座に移管して、新NISAに突っ込むべく売却したのでレポートとして記録に残しておきます。 銘柄はeMAXIS Slim米国株式(S&P500)、タイムラインは次の通り: 2022年5月: 積み立て開始、積立額は17,000円/月 2022年12月: 積立額を27,000円/月に増額 2023年11月: 最後の積み立てが終了 保有数は215,920口、積立総額は443,000円、本日(2024年1月31日)時点で概算評価額は561,607円、評価損益は+118,583円、評価損益率は+26.76%でした。 以上です。