Projects on Rindrics Mumbles

義元左文字

Thu, 04 Dec 2025 00:00:00 +0900

概要

frasyrを利用したStrangler Figアプローチで、資源評価事業全体のwebアプリケーション化を試みるプロジェクト。

開発経緯

本プロジェクトの前身となった三日月宗近では、パラメータ最適化など、科学計算部のパフォーマンスが問題となった。そこで、frasyrをモノリスアプリケーションとして動かしたうえで、その周囲に関心領域の分かれたマイクロサービスを追加していくアプローチを検証する。

現在の状態

進行中

村正

Thu, 01 Jan 2026 00:00:00 +0900

概要

Excel/CSVのシートから、空行で区切られた複数の表を検出し、それぞれをタイトル行、ヘッダー行、データ行に分けて読み取るJavaSrcipt用ツール。

印刷物の表のようなレイアウトでデータが配置されたシートでは、1枚に複数の表が並び、表の上にタイトルが書かれていることが多い（いわゆるネ申エクセル）。村正は次のルールで、こうしたシートを機械が扱える矩形のデータとして読み込む:

空行で区切られた行のまとまりを、表の候補（ブロック）とみなす
ブロックの先頭行が、ブロック内の最大列数より少なければタイトル行とみなす
タイトルの次の行をヘッダー行とみなす。正規表現でヘッダー行を指定することも、ヘッダーなしと指定することもできる

開発経緯

資源評価事業をドメインモデリングに基づいてアプリケーション化する三日月宗近プロジェクトで、査読者用のデータアップロード機能が必要だった。このような外部との連絡部分では、自アプリのモデルを外部のデータ型式から守るためのいわゆる「腐敗防止層」が必要となる。腐敗防止層のうち、Excelファイルからデータを取り出す部分を、汎用パッケージとして切り出した。

現在の状態

npmで公開中（“muramasa” ではまずいのでさすがにまともな名前をつけた）: @rindrics/tblparse

基本的にはnpmパッケージだが、GUIから使えるデモサイトを下記でホストしている:

tblparse Demo | tblparse.rindrics.com

https://tblparse.rindrics.com/

recurring-backlog-item-creator

Sun, 09 Nov 2025 00:00:00 +0900

概要

設定ファイルに基づいて、GitHub Projectsのバックログアイテム（issue）を定期的に自動作成するGitHub Actions。作成周期（毎月、四半期、年1回など）の異なる定期issueは、種類ごとにGitHub Action workflowが必要なため嵩張る。これを設定ファイル一つで管理できるようにした。

設定できる項目:

issueごとの作成月
タイトルの接頭辞・接尾辞（{{YearMonth}} などのテンプレート変数を使える）
Projectのカスタムフィールド

目的

振る舞いをコードではなく、データとしての設定ファイルで表現する感覚をつかむこと。

設定をデータとして扱うと、「今月どのissueを作るか」は、設定と月からissueの一覧を求める変換として書ける。そこで、CLIとActionとに分けて設計した:

CLI: 設定ファイルと月を受け取り、作るべきissueをJSONで返す
- Goを使うことで楽に書けた
- 副作用のない関数を中心に実装した。フィールドの検証やIDの解決でGitHubを読む部分はインターフェースで抽象化し、テスト時にモックに差し替え可能にした
Action: GitHubへの外部副作用（issueの作成、Projectへの追加、フィールドの設定）を担当

現在の状態

GitHub Marketplaceで公開中: rindrics/recurring-backlog-item-creator

ppap-cli

Sat, 01 Jun 2024 00:00:00 +0900

概要

PPAP（Password付きZIPファイルを送ります / Passwordを送ります / Angoka Protocol）を使った添付ファイル送信を助けるCLI。

目的

ブラックジョークのソフトウェア表現の模索。

現在の状態

リポジトリで公開している。

数珠丸

Mon, 01 Jan 2024 00:00:00 +0900

概要

独自ドメインのメールをSlackをクライアントとして送受信するツール。

受信: SESで受けたメールをS3に保存し、Lambdaで解析してSlackに投稿する。本文がSlack Block Kitの文字数制限を超える場合は、ファイルとしてスレッドに添付する
送信: botにテンプレートを出させ、記入して投稿したメッセージのURLをbotに渡すと、プレビューが表示される。確認して送信ボタンを押すとSESから送る。同じメッセージからの二重送信は防いでいる

目的

独自ドメインのメール送受信環境を作ること
- 商用サービスほどの可用性は必要ないので作ってみた。
- 常時稼働のサーバーがないので運用コストが低い。受信したメールはまずS3に保存するので、Slackへの投稿に失敗してもメール自体は失われない
「インフラがインターフェイスを実装する」という考え方が、クラスレベルだけでなくパッケージやデプロイレベルでも成り立つことを実感すること
- メールの解析や送信の判断はcoreパッケージにまとめ、ストレージやメールサーバーとのやり取りはリポジトリのインターフェースとして抽象化したので、一応クラウドプロバイダの種類にも依存しない設計になっている

現在の状態

coreパッケージはnpmで公開中（さすがにまともな名前をつけた）: @rindrics/slackmail

独自ドメイン宛てのメールは、すべて本ツールで受信している。

三日月宗近

Wed, 01 Jan 2025 00:00:00 +0900

概要

資源評価のプロセス全体をwebアプリケーション化する試み。計算部だけでなく、業務プロセスの進行: 評価ステータスの遷移などもドメインモデリングされている。

デモとドキュメントは下記から利用できる:

資源評価Web | mikazuki-munechika.rindrics.com

https://mikazuki-munechika.rindrics.com

資源評価Web 📖 | docs.mikazuki-munechika.rindrics.com

https://docs.mikazuki-munechika.rindrics.com

開発経緯

下記はプロジェクト開始時のモチベーション文:

資源評価事業をwebアプリケーション化する実験をしている。資源計算だけでなく、計算・執筆・提案・議論・合意形成の流れからなる資源評価「事業」全体の話だ。

この事業の難しさは、科学的・政治的要求にもとづく課題を解決する数値計算方法を開発するところにあるのはもちろんだが、そもそもコミュニケーションの難しさのほうがより重要なのではないか: 立場や知識背景がまったく異なるステークホルダーが、資源評価という関心領域（ドメイン）の下に集まって、漁獲可能量という一つの数値について議論し・意思決定しないといけない。

ソフトウェア設計者たちは、これと同じ問題が（広義の）ビジネスがある場所には必ず潜んでいることに気づいており、その解決のために「ドメイン駆動設計（Domain-Driven Development. DDD）」を2000年代前半に確立した。ドメイン駆動設計では、開発過程における思考資源の投資先を、プログラミングのような技術的詳細ではなく、ビジネスの営みを抽出した「ドメインモデル」をつくることに集中する。ドメインモデルは一度作って終わりではなく、ステークホルダー間で認識の齟齬が見つかるたびに、その新たな知識はモデルに反映される。このようにして磨き上げたドメインモデルを中心としてアプリケーションを開発するこの手法は、資源評価事業においてもヒントになると考えている。

現在の状態

開発停止（検証完了）

資源評価プロセスを型で表現し、コード補完などやコンパイル時チェックで開発を支援できることを確かめられた。

計算のフローチャートを実際のコードから生成できることがわかった
日本語を使うことで、細かいニュアンスの違いも吟味しながらドメインモデリングできることがわかった
- 参考: ドメインモデリングに日本語を使う

検証の過程でわかったこと

Node.jsではパラメータ最適化部分で速度が出ず、科学計算に適した言語を呼び出す必要がある
- frasyrを入れたRを呼び出すのが自然
  - frasyrモノリスを使ったStrangler Figアプローチの後継プロジェクト義元左文字で検証する
  - 三日月宗近と義元左文字は背反ではなく、必要であれば両者をつなぐこともできる
ドキュメントとしてエクスポートする型は、ドメインエキスパートに見せるものに絞るのがよさそう
- あまり考えず生成したらこうなったが、これを見たドメインエキスパートを圧倒してしまうと思う
評価のステータスを型で表すこと自体はいいが、状態をオブジェクトに持たせる旨味はなかった
- ユースケースを考慮しても、状態はイベントから導出するほうがよいだろう