『Rustで作るプログラミング言語』を読んで、かねてから構想していた自作言語を形にした

Rustで作るプログラミング言語という書籍が先日発売されました。簡単なプログラミング言語を作ってバイトコードに変換して実行したりネイティブコードに変換して実行してみよう、という本で、大変面白く読みました。最終的にまあまあ本格的な言語になるので、これを元にするとわりとちゃんとした言語を作れそうです。

この書籍で最終的に作られる言語はこちら:

ちょうど私も、以前から構想していた言語があったので、ちょっと作ってみました。というのも、TypeScriptを設定記述言語としてさまざまなプログラミング言語から使えると便利ではないかとずっと思っていたのです。

この設定言語で複雑なことができる必要はなく、最終的にはJSONに準ずるデータ構造になればよいので、その程度だったらそれほど大掛かりではなくツールとしてメンテできるのではないかと思っています。似た思想のツールとしてはJsonnetがありますが、Jsonnetは構文が独自でまったく新しい言語を覚えなければならないのが不満なのです。かといってJSONは非力すぎますし。

TypeScriptで設定を書くのであれば、ほとんどのプログラマーの共通言語であるJavaScriptとほぼ同じように書けますし、TypeScriptの深い知識は不要です。さらに、Typescriptの厳格なサブセットであればTypeScriptの開発ツールキットをそのまま利用できるので、設定を書いている途中にTypeScriptの強力な静的型チェックや補完機能も使えるというわけです。

この設定言語のプロジェクトはこちら("titys" から "tiscript" にリネームしました):

GitHub - gfx/tiscript: Turing-Incomplete TypeScript Subset as a Configuration Language

こういう感じで設定ファイルを書けます:

// editor_config.ts

const LF = "\u{0A}"; // \xHH はまだサポートしていない

export const EditorConfig = {
    tabSize: 4,
    trimTrailingWhitespace: true,
    endOfLine: LF,
    encoding: "utf-8",
};

このファイルはJSONに変換するとこうなります:

{
  "EditorConfig": {
    "tabSize": 4,
    "trimTrailingWhitespace": true,
    "endOfLine": "\n",
    "encoding": "utf-8"
  }
}

Turing-incompleteなことが重要 なので、TiScript (Turing-Incomplete TypeScript) と名づけました。プロジェクトの進捗としては40%くらいですが(とくに型構文をほとんどサポートしていない!)、世の中にあるeslintなどのJavaScript設定ファイルくらいであればすでにTypeScriptに書き換えたものをJSONに変換可能です。

言語として何一つ新規に発明したところがないというのはポイントです。私が判断したのは、強いていえば「何を実装しないか」くらいです(このへんはREADMEに書いてあります)。

現在のところインターフェイスとしてはコマンドしか用意していないのですが、すでにJSONを受け付けるツールにのためのプリプロセッサとしてはすでにある程度使えるでしょう。とはいえ、さすがに今は機能的にも不足ですし、また、Rust用のAPIなどを整備しないと現実的には使い物にならないので、ある程度使い物になるくらいまではメンテするつもりでいます。

脱線しましたが、『Rustで作るプログラミング言語』はRust学習の 2冊目以降の本 としてはかなりよいのではないかと思います。

Rustで作るプログラミング言語
Rustで作るプログラミング言語

デイリーポータルZの新着記事をBlueskyに投稿するbotを作った

デイリーポータルZの新着記事をBlueskyに投稿するbotを作りました。

github.com

デイリーポータルZは2024年1月1日から独立した会社になるようですが、状況から察するに実態としては消滅まで秒読みと思われます。インターネットからデイリーポータルZが無くなるのは寂しいので、どこかの企業がスポンサーになってくれることを期待しています。

dailyportalz.jp


それはそれとしてBlueskyのボットを作るのは結構楽しいですね!ボットのコードはRustで書きました。GitHub Actionsの定期実行でRSS feedをポーリングして新しいものがあったらポストする、という素朴なプログラムです:

bsky.app

Bluesky APIへのアクセスはsugyan/atriumを使いました:

memo.sugyan.com

投稿の本文をリッチテキストにできたり*1、OGPカードを自分で組み立てたりできるので*2、遊びがいがあって楽しいです。

Enjoy!

*1:逆にいえば、勝手にURLがリンクになったりはせず、自分でリンクなどを貼らないといけない。

*2:逆にいえば、勝手にOGPカードが生成されたりはしないので、自分で組み立てないといけない。

SMBCのOliveカードでオンライン決済が拒否されたら「クレジットモード専用カード番号」を試すとよい

2023年から三井住友銀行にオリーブアカウントなるものができて、これのクレジットカードが「クレジットモード」「デビットモード」「Vポイント払いモード」を切り替えて使えるという触れ込みです。このほか、オリーブ化するとSMBCからの振り込み手数料が無料になります。この振込手数料無料に引かれてオリーブ化したのですが、このオリーブアカウントで発行するオリーブカードがあまりにも出来がわるくて驚いています。

実際に使ってる方はわかると思いますが、実店舗・オンライン決済問わず、Oliveカードでの支払いが拒否されることが頻繁にあります。おかげでオリーブカードと通常のSMBCカードの2枚持ちをする必要があります。なんならオリーブカードは使う必要がないくらいです。

ところで、オンライン決済のときにオリーブカードが弾かれる場合は、「クレジットモード専用カード番号」なるものがあるので、それを試すとうまくいくことが多いようです。どうもデビットカードが使えないサービスではオリーブカード(の番号)は使えないので、その対策のようです。こういう「対策」が必要な時点でクレジットカードとしては設計ミスだとしか思えないのですが、とにかくどうしてもオリーブカードをオンライン決済で使いたければ、クレジットモードの番号を使いましょう。

詳しい方法はFAQもあります。確認方法が、アプリをいじっていてたまたま見つかるような場所じゃないのがまたいやらしいですね…:

qa.smbc-card.com

この方法だと実店舗で拒否されるパターンには対応できません。

よくみると「ご利用上の注意」も非常に長くて、こんなの普通の利用者が覚えられるわけがありません。どうしてこんなプロダクトがリリースされてしまったのか:

www.smbc-card.com

まとめると、オリーブカードを使わないのが一番悩みが少なくなる方法ではないかと思います。

家計口座用の家計簿アプリをマネーフォワードMEからZaimに乗り換えた

追記(2023/11/29): 2023/11/1からまたZaimでアメリカン・エキスプレスとの連携ができなくなりました: (11/2 掲載)アメリカン・エキスプレスの連携不具合について:よくある質問|家計簿アプリ Zaim。マネーフォワードではできているようです。困惑の極み…。とりあえずZaimのプレミアムプランは解約しました。


最近、我が家の家計のための家計簿アプリを、5年ほど使ったマネーフォワードMEからZaimに乗り換えました。今のところ、機能的には満足しており、かつこれまでできていなかった我が家の家計スタイルに合った家計簿の運用がようやくできるようになったので、大変満足しています。


もともとあった課題として、マネーフォワードMEは我が家の家計スタイルを実装していないというものがありました。我が家の家計スタイルは、別に特殊なものではなく、次のゼクシィの記事の「【2】お互いに、毎月定額を共同口座に入れて管理する方法 」にあたります。

共働き夫婦の「家計の管理方法」は全5パターン!ふたりに合うのは?|ゼクシィ

お互いに、毎月定額を共同口座に入れて管理する方法

【2】お互いに、毎月定額を共同口座に入れて管理する方法

例えばお互いに月収の6割を家計に入れよう、などとルールを決め、その中で生活費をやりくりする方法。それ以外は自分で自由に使えるお金として残すことができます。ふたりとも同等の収入を得ている夫婦の多くが採用している方法です。

家計簿アプリでこのスタイルを実装するには、いくつか方法が考えられます。パッと思いつくのは次のような2つでしょうか。

  1. 共有口座のために共有アカウントを作ることにして、アプリでは「アカウントの切り替え」を簡単にできるようにする
    • 利点: ユーザーにとって新しい概念が登場しないため操作が簡単(実装も簡単と思われる)
    • 欠点: 「家族の誰が操作したか」の記録ができない
  2. 共有口座や履歴を、複数のアカウント間で、個々人の家計簿とは異なる名前空間で共有できるようにする
    • 利点: 「複数人で共有口座・出納を管理」という家計スタイルを採用している人にとっては理解しやすい
    • 欠点: 仕様が複雑になる(特にこの家計スタイルを採用していない人にとっては)

重要なのは、「自分の家計簿は自分のアカウントで、家族の家計簿は自分のアカウントとは隔離された名前空間で管理する」ということです。家族といえども個々の独立した人間である以上、個人用の家計簿の全てを共有する必要はないのです。実際、1Passwordのファミリープランはまさにそのように実装されていて、個人パスワードは個人のvault(データを保存する際の名前空間)へ、家族と共有するパスワードは共有vaultで管理できます。

残念なことに、マネーフォワードMEはアカウント切り替えも口座の共有もできないため、我が家の「家計簿」を管理するのには不都合がありました。それでもいつか実装されるはずと思ってここ5年ほど騙し騙し使っていました*1。そしてミートアップや個人的に知り合ったマネーフォワード関係者に希望を伝えたり、フィードバックとして何度か意見を送ったりしてきました。しかし、最近のマネーフォワードMEの機能開発の様子*2をみていると、稼ぎの少ないtoCのサービスに今後大きなリソースは割かない方針ではないかと思わざるをえません。これ以上待っても改善は期待できないと確信してしまった以上、サービスの移行は必然です。

Zaimを選んだ理由は、多少なりとも縁のある会社であること*3、アカウント切り替えを実装済みであること、妻が以前はZaimユーザーだったので慣れていること、我が家で使っている銀行などの金融サービス全てとAmazonに対応していること、などです。

なお、我が家の家計簿はZaimに移行したものの、個人用の家計簿をマネーフォワードMEから移行するかどうかは決めていません。できればZaimに移行したいのですが、これまでの履歴を失うのはちょっとつらいなあと思っています*4

*1:私と妻がそれぞれ家計用の口座を個人のマネーフォワードMEアカウントに登録して「家計」グループをつくり、それぞれが自分のアカウントの中で「家計」グループを見ていました。当然カテゴリの共有はできないので、支出の正確な分類は長らく共有できていなかったのです

*2:具体的にはリリースノートなど

*3:旧Zaim社(現くふうAIスタジオ社)は、昔は一時クックパッドオフィスに間借りしていましたし、今もクックパッドからスピンアウトしたくふうカンパニー系列の会社です

*4:我が家の家計簿についてはこれまでの履歴を諦めましたが…

40代の男性プログラマーが5ヶ月の育休を取った

次子のために5ヶ月の育休をとった記録です*1

家族構成は、外資系*2勤務フルタイムワーカーの私、同じく外資系勤務フルタイムワーカーの妻、長子のmfx氏(2017年9月生まれ)、そして次子のrfx氏(2022年6月生まれ)という四人家族です。

私が育児休業をとったのはrfx氏の育児のためです。妻がはrfxの誕生の1ヶ月前から産休に入り、11月いっぱいまで育休をとりました。私は妻と入れ替わるように11月下旬から翌年の4月下旬まで育休をとったため、約5ヶ月間育児休業を取得することになりました。つまり、rfx氏が保育園に入園して慣らし保育が終わるまでの期間を、私たち夫婦で分担して育休をとり、育児に集中することにしたのです。

長子のmfx氏が生まれたときは、私は育休を取得しませんでした。当時は人数が一桁台のスタートアップ企業に勤めていましたが、育休は取ろうと思えば取れたはずです。しかしなんとなく「今、休むわけにはいかない」と感じて育休は取らなかったのでした。しかし、せめて新生児期の1ヶ月くらいは育休を取得すればよかったと後悔しています。育休をとらなかったことだけが原因ではないものの、このときは妻の産後のダメージがなかなか回復せず、家族として苦しい時間が長引いてしまったという思いがあります。

さて、社会人として長年働いてきた私にとって、こんなにも長い休暇を取得するのは、新婚旅行で3週間休んだとき以来です。この育休期間中、赤子の世話に追われましたが、まだハイハイもできないくらいの段階でした。その中で、育児と家事だけをして過ごす「専業主夫」の経験は貴重ではありました。

育休を取得して良かったと感じる点も多いです。家事もしながら赤子の世話をする日々は思った以上に忙しく、フルタイムで働くときと比べても余暇が余計にあるとは言えませんでした。それでも、このときはmfx氏が鳥に興味を持っていたこともあり、平日昼間に子供達をつれて近場の公園でバードウォッチングに出かけたりと、思い出深い経験を重ねることができました。また、この時期にザッハトルテなどちょっと凝ったお菓子を作ったり*3、mfx氏といっしょに生地をこねるところから始めてピザまんを作ったり、普段だったらなかなかできないことに挑戦したりもしました。

しかし、育休取得にはデメリットもあります。妻が産休に入ってから私の育休が終わるまでの11ヶ月ものあいだ、我が家の収入は激減しました。育休給付金は限度額が月30万円です。この額が私たちの手取りとして入ってきましたが、これは本来の手取りと比べると少ないのです。我が家は私も妻も給与に大きな差がないので、「育休を夫婦で分割して取ったこと」それ自体によるマイナスはほとんどありません。しかし、数ヶ月ものあいだ収入が減るのは、家庭によっては許容できないでしょう。

さらに育休によって昇給しにくくなるというデメリットもあると思います。育休が明けてからも、後述するように仕事に集中しにくい日々が続くので、ことによると丸1-2年分の昇給が消えるかもしれません。これは長い目で見ると育休による直接的な収入の減少よりも大きな影響です。これは突き詰めると「子供を1人持つたびに生涯収入が大きく減る」ということになってしまうのですが…。収入や昇給機会の減少は事前にわかっていたことではありますが、実際に起きると苦しいものです*4

とはいえ、「保育園までのあいだ、育休を取らずになんとか過ごす」という選択肢は、通常は考えにくいでしょう。そうであるならば、妻一人が育休をとってキャリアへの悪影響を負うよりも、そのリスクを妻と夫で分散したほうが、家庭というチームとしてはベターであるはずです。我が家としては、このリスク分散はよい形で働いたと思います。

なお育休後、rfx氏を保育園に預ける日々が始まりましたが、頻繁に風邪をひいては休園せざるを得ない状況が続いています。というより、この9月までのあいだほとんど常に微熱を含むいくつかの風邪の症状があり、何の風邪の症状もない日は月に1-2日くらいしかありません。こういう状況だと赤子を家で看病せざるをえず、仕事に集中はできません。これは今まさに私の自己肯定感の低下を引き起こしています。

こう書くとデメリットが非常に大きいようにも見えるかもしれませんが、それはやはりまだ生まれて1年と少ししか経っていないから、とは言えると思います。mfx氏を育てた経験から考えると、子育てが劇的に楽しくなったのは、3歳くらいからでした。このくらいの時期からできることや語彙が爆発的に増え、認知的にも大きく成長して、一緒に遊ぶのがとても楽しくなったからです。親と異なる趣味嗜好を発揮して、親もそれを楽しむ、ということをしはじめたのも3歳くらいでした*5。rfx氏(現在15ヶ月)はまだ発話もないくらいの赤子なので、はやく成長しないかなあと思っています*6

*1:4ヶ月の育休をとる - Islands in the byte stream 当初は4ヶ月のつもりでしたが、そのあと慣らし保育中も育休をとることにしたので5ヶ月になりました。

*2:Fastly K.K.

*3:もともとスイーツを作るのが趣味なのです。

*4:ところで、我々夫婦は二人とも外資勤務で通常の給与以外に株式報酬(RSU)がありますが、妻が育休の時は株式報酬も止まり、私の育休のときは株式報酬はもらえました。この辺は企業のポリシーによって違うようです。

*5:具体的には恐竜に大ハマりしました。夫婦ともに古生物にそこまで興味はなかったのが、最終的に古生物の本を読んだり福井の恐竜博物館に旅行したりするようになり、このmfx氏の趣味を家族みんなで一緒に楽しみました。

*6:赤ちゃんのときの可愛さはそれはそれで唯一無二ではありますが、「人間的な交流」はできませんから…。

エンジニアHubにHTTP/3の記事を寄稿しました

エンジニアHubに「HTTP/3|Webエンジニアが知るべき新常識 ─ QUICやコネクションマイグレーションなどを学ぶ 」という記事を寄稿しました。CDNとしてHTTP/3を提供しているFastlyで働いているという縁からです*1

eh-career.com

書きたいことはこの記事にすべて書いたので呼んでいただきたいのですが、この記事では「自分でHTTP/3サーバーを管理する」ということはまったく視野に入れていません。HTTP/3は現在のところCDNのための技術といっても差し支えないからです。

一方で、これから数年かけて「非ブラウザのHTTPクライアントにおけるHTTP/3の活用術」といったことが研究され、広まっていくのでしょう。ちょうどHTTP/2が標準化されたあとで、HTTP/2を活用したgRPCが作られたように。これについては個人的には非常に楽しみにしています。非ブラウザのHTTPクライアントがよく使われるのはスマホアプリですし、スマホアプリの動作環境は必然的に通信が不安定であり、HTTP/3が得意とする環境だからです。まあしかし、これはまだ先の話です。

この記事に書いたように、これからしばらくHTTP/3との付き合い方は「CDNでHTTP/3を有効にする」で良いのではないかと思っています。

*1:Fastly に入社しました - Islands in the byte stream -- そういえばFastlyで働き始めてからそろそろ4年になります。

『日経サイエンス』誌を読んだら思いの外よかった

ふと思い立って『日経サイエンス』誌を読んだらけっこうよくて軽く感動しました。

これまではTwitter至上主義だったので情報はTwitterから仕入れればよいと思っていたのですが、最近のTwitterのサードパーティ・マイノリティ排除の様子に辟易してTwitterをやめて以来、情報に飢えていたのでした。そこでたまたま目にした科学雑誌を読んだら満足感が高かったという感じです。

自分の専門分野(ソフトウェアエンジニアリング)ではない専門誌を読むという発想があまりなかったのですが、子供が生物に関心をもったのをきっかけに真面目に理科・科学を学び直すのもよいなあと思ってたのでちょうどよいというのもあります。こと学術系の記事に関しては、有料コンテンツも捨てたものじゃないですね(当たり前)。

https://amzn.to/480Mnry

vscodeが使うTypeScript.tmLanguageに基づいて構文ハイライトを実現する

vscodeはTypeScriptの構文ハイライトのために TypeScript.tmLanguage という定義ファイルをもっています。

この tmLanguage はもともとTextmate用の構文定義言語のようですが、vscodeプロジェクト群はこれを利用する構文ハイライトエンジンも提供しています。

つまりこれらを使うと、vscodeと同じ構文ハイライトを実装できるということ!所用でTypeScriptのカスタム構文ハイライト(モノクロ)が必要なったので、ためしに実装してみました。CSSクラスが多様でまじめに実装するのはけっこう面倒くさいので、今回はCSSクラスの名前ベースで適当にパターンマッチでやっつけました。モノクロとはいうものの、といらえず「薄くする(color: gray)」「濃くする(color: bold)」くらいしかしない想定です。

仕上がりはこんな感じです。

ハイライトの例

コードはここにあります。

github.com

vscodeの設定ファイル .vsocde/*.json をGitHubでJSONCとしてハイライトさせる

.gitattributes に次の1行を足すと、vscodeの設定ファイルがGitHubでJSONC (JSON with Comments) としてsyntax highlightされるようになります。

.vscode/*.json linguist-language=jsonc

GitHubのsyntax highlightは github/linguist で制御されています。これに同梱されている overrides.md というドキュメントに、repoごとのカスタマイズ方法が載っています。

https://github.com/github/linguist/blob/master/docs/overrides.md

syntax highlightだけでなく、GitHub repoの統計(どの言語がN%、みたいなやつ)からの除外、自動生成されたかどうかのフラグ(統計から除外されるのと、PRでdiffがデフォルトで展開されなくなる)、などを制御できます。

syntax highlightのデフォルトおよび利用可能な値は languages.yml に定義されているので、そこを参考にして設定できます。

https://github.com/github/linguist/blob/master/lib/linguist/languages.yml

ハイライトの実例はこんな感じ: https://github.com/msgpack/msgpack-javascript/blob/main/.vscode/launch.json


そもそもGitHubがデフォルトで .vscode/*.json をJSONCとしてもいいんじゃないか?とおもってpull-req github/linguist#6221も提案してみたのですが、これは採用予定なしと。理由は次の通り:

  • basenameだけでなくpathnameをみるというのは破壊的変更で影響範囲が大きすぎる。もし本当にやるなら慎重な検討が必要だが、いまのところ恩恵を受けるのは .gitattributes を指定していないvscode userだけ
  • GitHub 11年の歴史でsyntax highlightの際にpathname全体をみるという要求はvscodeの設定ファイルだけ
  • そもそもvscode*.json ファイルにJSONと非互換なフォーマット(JSONC)を書けるというのは慣習に違反していて無作法では?もしこの件について何かしたいならvscode.vsocde/*.jsonc をサポートするべきではないか

正論すぎますね。個人的には、JSONがコメントと末尾コンマを許容するようになるとこの件のみならずJSON/JSONCにまつわる様々な問題が解決してみんな幸せになれるので、Microsoftvscode teamがそういう提案をしてくれるといいなと思います(いや提案するのは誰でもいいですが)。逆に、そういう未来を想定するならばvscode.vscode/*.jsonc をサポートする必要はないのかなとも思います。現状だといずれにせよ .gitattibutes でカスタマイズできますしね。

ナイフで果物を切っているときに手を滑らせて全治一ヶ月の切り傷を負った

3行で

  • キウィフルーツなどのぬめりのある果物を切ったあとは、別の作業に取り掛かるまえに手を洗うべし
  • リンゴなどの硬めの果物を手の上で切るのはハイリスクなので、可能であればまな板を使うべし
  • 切り傷を負ったとき、5分経っても血が止まらなければ即病院へ(行きつけのクリニックでよい)。ナイフによる切り傷はよくあることなので医者も処置に慣れている

詳細

2022年6月に、果物ナイフで左の人差し指をばっさり切って縫合する羽目になりました。抜糸まで10日、その後キーボードをタイピングできるようになるまで数週間、だいたい全治一ヶ月くらいでした。そこからさらに半年ほど経過した今でも縫合痕は残っていますが、日常的にはまったく問題ないくらい回復しました。怪我の場所に意識を集中すると、違和感が多少残っているかな、という程度です。

これは朝キウィフルーツとリンゴをナイフで剥いているときに起こった事故です。この2種の果物は我が家の定番の組み合わせで、100回以上この組み合わせで皮を剥いてきています。ぼくはいつも「キウィフルーツ→リンゴ」の順で皮をむいていて、これはリンゴを先に剥くことで変色させたくないからです*1。このときまで、キウィとリンゴの間に手を洗うこともなければ、リンゴを切るときにまな板もまったく使っていませんでした。果物ナイフの扱いには自信があったし、頻繁にする作業で十分に慣れていると思っていたし、本質的でない作業をするのは面倒ですからね!

この日は、数日前に第二子誕生からの妻と第二子の退院を迎えたばかりでした。つまり、深夜未明にたびたび発生する新生児の授乳がはじまり、とくにこの日はぼくが夜の授乳を担当した日でした。それによって、朝は徹夜明けのごとくぼーっとしていました。

そしてキウィを切ったあとのヌルヌルの手のまま、リンゴを手のひらの上でナイフで半分に割ろうとしているときに、手を滑らせて件の事故がおきました。かなり力を入れていたので、指先に数ミリの深さの切り傷ができ、一見すると「ナイフで指先を切っただけなのにこんなに!?」と思うくらいの出血がありました。

最初は普通の些細な怪我だと思ってしばらく傷を圧迫して様子をみていたのですが、数分たっても出血が止まりません。しかたなく行きつけのクリニックで診てもらったところ、傷を見るなりお医者さんが「縫いましょう」と宣言。そして10分ほどで縫合完了。10日後に抜糸する旨を聞く。あっという間に治療完了でした。その後は多少腫れたりはしたものの、順調に回復。すぐにクリニックに行って治療したのが功を奏したのかのかもしれません。よかったですね。

教訓としては、寝不足や体調不良などのときはなるべく刃物を扱わない、刃物を扱うときはぬめりに注意する、硬いものを切るときにはまな板を使う、もし怪我をして数分間出血が止まらないときはちゃんと医者に診てもらう、という感じですかね……。第二子誕生直後のバタバタしたタイミングだったからこそのでやらかしですが、結果的に今年二番目くらいにインパクトのある事件となりました(一番は第二子の誕生)。

*1:かといって塩水やレモン水につけるとリンゴ本来の風味が抜けるので嫌なのです。第一、水につけておくのも面倒ですし。