Programming

気が付いたら2025年が終わってました。今年の抱負とか考える前に仕事が始まったので、今年もいきあたりばったりに行きていければと思います。 最近Rustで細々と格闘しているんですが、ちょっとやってみたいことがあってやってみたらできたので、小ネタとして残しておこうかと思います。 やりたいこと 諸事情で、代数式をstructとして管理することをしています。毎度ですが、なんでそういうことをしようとしているのか？は聞いてはなりません。 // こんなtraitを定義しておく trait Equation { // envは変数のhashmap fn evaluate(&self, env: &HashMap<String, f32>) -> f32; } こんなtraitを実装したものを考えたいです。なお実装は自明なので省きます。で、これを普通に実装すると、ちょっと複雑になっただけで大変なことになります。 // 3.2 + 3.4 let e = ArithmeticEquation::new(Add, ConstantEquation::new(3.2), ConstantEquation::new(3.4)) // 掛け算とかがnestすると大変なことになる これをなんとかある程度楽にしたい、というのがモチベーションです。 方法の検討 Rustだと、大きく3通りのやり方があると思います。 procedural macroを実装する lexer/parserを利用してparseを実装する operator overloadとstructを駆使して頑張る macroとoperator overloadはcompile時に、lexer/parserは動的になる感じです。最終的にはlexer/parserが必要になりそうなんですが、一旦は静的にできれば（テストを書いたりするときに）便利です。となると、macroかoperator overloadが選択肢になる感じですね。 lexer/parser自体を生成するmacroとかはあるようですが、そもそもparseするという行為自体が、compileした後の話になるので。 Operator overloadを検討してみる RustのOperator overloadは大変に強力である意味シンプルなのですが、 Scopingが困難 です。 KotlinとかのOperator overloadでは、interfaceの実装元とかで切り分けられたり、scoped functionを利用することで、DSL/operator overloadの利用範囲をscopingすることがるできます。 object Ops { operator fun invoke(f: Ops.() -> Unit) { f() } infix fun String.test(rhs: String): boolean {...} } // こんな感じで使える Ops { "hoge" test "foo" } // 外だと明示的なimportが必要。 翻ってRustのOperator overloadは、標準にある Add や Sub といったTraitを型に対して実装する・・・という形です。 ...

たまには超小ネタです。 Bevy触ってます ちょいちょい中断しつつですが、bevyというゲームエンジンを触っています。なんというか現代的なゲームエンジンを触るのは実は初めてなんですが、Direct3Dで・・・みたいな時代とは隔世の感がありますね。そもそも古すぎか。 やりたいことのためにWASMで動作するように作っているのですが、 glTF ファイルを読み込ませようとしたら、 .gltf.meta という謎のファイルが要求されてエラーになって困ったことになりました。ちなみにglTFファイルとは、WebGLの標準フォーマットとのことです。 https://knowledge.shade3d.jp/knowledgebase/gltf%E3%81%A8%E3%81%AF 解決 https://github.com/bevyengine/bevy/issues/10157 困ったときは公式のissue、ということで探したらありました。どうもbevy_assetsの機能で、metadataを確認することでより適した処理にできる、とかそういうもののようです。ちなみに生成するためには 一回起動したらいいよ 、とのことですが、WASMの場合そもそも書き込むっつってもどこに？となってしまいます。 app.add_plugins(( DefaultPlugins .set(AssetPlugin { // これを追加する meta_check: AssetMetaCheck::Never, ..default() }), )) issueにあったやり方とは違いますが、meta_checkを無効化するとOKです。私がやりたい範囲ではglTFはほぼ使わないので、これで特に問題なさそうでした。

すっかり初夏の感じになってきました。半年すぎるのが早すぎます。 すっかり間が空いてしまいましたが、今回は最近のお仕事で使ってるものとかを簡単に書いてみようかと思います。 ...

去年のGWに何をやっていたか全く記憶が無いんですが、今年も特に何もないGWになりそうですね。なんだかなぁ、という気分しかありませんが。 そんな状態ですが、最近チマチマと作っているOCamlでのScheme処理系で、Monadic Parserを作ってみたので、その紹介をちょっとできれば。 <!–more–> Monadic parserとは まずMonadic parserとは何か、ですが、あんまり明確な定義は無いというか、名は体を表すというか、そのまんまというか。モナドを利用したparserです。HaskellのParsecが有名ですね。 基本的には、 関数で構成されている モナド則により合成可能である という感じかなー、と。理論的な背景はあんまり理解しきれていないので、あくまで私の理解ではありますが。 OCamlのapplicable let Haskellだと、Monadの記述にとても役立つ、 do記法 というのがあります。OCamlには長らくそういうのがなく、PPXとかで各ライブラリごとに拡張を書いていたり、ppx_letのように汎用的な拡張を利用したり・・・というのが必要でした。 が、OCamlの4.08？くらいで導入された Applicable let というのを利用すると、do記法と同じような記述を、OCamlらしく記述することができます。 module Nanika_monad = ... let ( let* ) v f = Nanika_monad.bind f v let () = let* v = Nanika_monad.return v in ... applicable letと言っても、なんてことのない関数定義です。 let* とかだけではなく、 let+ みたいなものも定義できます(定義の中身は、定義の実装者次第です)。letが定義できるということで、同時に and* のような関数も定義することができます。 これですが、 >>= での結合をほぼそのまま変換することができ、逐次処理のように見せることができます。記号で繋げまくっていくのも楽しいですが、後から見たときに処理が明瞭になるので、最近はMonadとかを利用するときはこれを使ってます。 Applicative ParserではなくMonadic Parserになる理由 Monadic Parserとはよく呼ばれるけど、 Applicative Parser というのが無い理由ですが、これはシンプルで、 Applicableだとパースできないものが沢山ある から、という理由のようです。 具体的な例は、もっとよく説明しているサイトを参考にするのがよいと思います。私の浅い理解だと、 Applicableだと、繰り返しやバックトラックといった挙動を定義することができない 前の値を利用する、というようなことができない ため、そもそもパーサーという目的には機能が足りないのでApplicative Parserというものは事実上作成されない、ということのようです。よりシンプルなパースができればいいのであれば、Applicative Parserとかも作れると思います。 ...

諸事情（主に会社の事情）で、AngularとState管理について評価する必要が出ました。ただ、今までそもそもAngularを触ったことがなかったため、Angular公式のTutorialをやることにしました。このTutorialが結構な分量なので、これにstate管理を追加すると丁度いいんでは？ということでやってみました。 <!–more–> Angular CLIのインストール まずはAngular CLIをインストールします。基本的にglobal installを推奨しているようですが、global installはめんどくさい時もあるので、今回はlocal installでなんとかならんかやってみます。 $ yarn add -D @angular/cli $ yarn ng new angular-tutorial --directory . --force $ yarn ng serve --open 一回CLIだけをaddしてから、無理やり上書きするというパワープレイでいけます。ここからは、Tutorialを普通に進めます。 Tutorialをやる（HTTP以外） Tutorialを進めていきます。集中してやれば、大体2〜3時間で終わるくらいのボリュームです。ただ、今回はstate managementをやるのが目的なので、HTTPが絡むような部分はstubにしておきます。 とりあえずTurorialが完了しただけの状態が以下のリポジトリです。masterブランチがその状態です。 https://github.com/derui/angular-tutorial-ngrx では、これにngrxを追加していってみましょう。 ngrxとは Angularを表す ng と、RxJSを表す rx がくっついているのでだいたい想像がつきますが、RxJSを前面に出したAngular用のstate management libraryです。公式ページでは次のように表現されています。 Store is RxJS powered state management for Angular applications, inspired by Redux. Store is a controlled state container designed to help write performant, consistent applications on top of Angular. ...

ふととあるところで、 関数型に書かれていない みたいな記述を見つけました。このときなんかモヤっとしたんですが、うまく言語化出来なかったので、ちょっと書いてみます。 <!–more–> まず始めに観測する 関数型 とか 手続き型 と言いますが、一体どういう基準で話しているかは、書き手・話し手に依存するようです。ただ、ある程度一貫しているのは 関数型という場合、多くの場合は関数がファーストクラス 手続き型という場合、低レイヤーな言語で書かれているようなものを指しているケースが多い 稀に、関数型言語と手続き型言語という感じでの使い方もされる様子 関数型言語としてはHaskell/Lispなど 手続き型言語としてはC/昔のJavaなど くらいのようです。私の観測範囲が狭すぎるのであれですが・・・。 関数型の書き方とは？ Java7から8になったタイミングでよく言われたのは、 Project Lambda によって導入されたLambda式でした。私もご多分に漏れずよろこんで使っているわけですが。ただ、これはJavaという言語が関数を言語のファーストクラスにした、という意味ではなく、単純にあまりに冗長だった無名インターフェースを簡単に書けるようにした糖衣構文です。 例えばこういうのが Thread thread = new Thread(new Runnable() { @Override public void run() { ... } }); こうなります。 Thread thread = new Thread(() -> {...}); どう見ても後者の方が圧倒的に短いです。ですが、これは単に () -> {} が、 Runnableインターフェースの run メソッドの実装として扱われているだけです。IntelliJとかであれば、RefactorだったかSourceから、糖衣構文にした場合としない場合にそれぞれ変換できますので、やってみるとわかりやすいです。 同じくJava8で入った Stream は、このLambdaを使い倒して貰おうというのが明白なインターフェースをしています。大抵、このStreamとLambdaを組み合わせて書いたものを関数型的というケースが多いようです。 何がモヤッとするのか 一応今までに Haskell や Common Lisp、 OCaml(公式が表示されなかったので日本版) を触っていますし、OCamlは今も継続して使っています。Javaは仕事で大量に書きましたし、JavaScriptも大量に書いています。C/C++も普通に使っていました。それぞれ、関数型言語と言われたりオブジェクト指向言語であったり、手続き型（C++はあれですが）言語と言われていたりします。 そんな中でモヤっとするのは、 見た目だけで関数型かどうかは決まらないのに、スタイルで語るのはなんか違うのでは無いか と最近思ったりするからです。試しにやってみるとわかりますが、Stream + Lambdaで調子に乗ってベタ書きすると、すぐに再利用不可かつ、for文で書くよりも可読性の悪いものが出来上がります。 関数型と手続き型の狭間 では実際に、私の思う手続き型と関数型の違いをコードにしていってみます。ここでは私が一番Loveな言語であるOCamlを使います。 let () = let num = ref 12345 in let buffer = Bytes.make 5 ' ' in for i = 5 downto 1 do let n = !num mod 10 in let v = match n with | 1 -> '1' | 2 -> '2' | 3 -> '3' | 4 -> '4' | 5 -> '5' | _ -> assert false in Bytes.set buffer (pred i) v; num := !num / 10 done ; print_string (Bytes.to_string buffer) 12345 という数字を "12345" という文字列にするのを、ものすごく冗長に、かつrefや副作用バリバリで書いてみました。OCamlにはwhileもありますが、ここではforを使いました。OCamlでforを使ったのは初めてです。 ...

この半年くらい、Tableauをよく触っています。そんな中、今まで国内だけで使っていたTableau Workbookを国外でも利用したい、という話が出てきました。 そんなときにできることをまとめてみます。 <!–more–> 以下のような方に参考になれば。 Tableauのワークブック/シートがそれなりにある 日本語ガッツリだったものを国外でも利用する必要に迫られた Tableauでの多言語化 まず、Tableau自体は多言語化されています。 Measure name/メジャーネームとか 合計とか ですが、 ラベル系については一切サポートがありません。 シート名、ダッシュボード名とかもありません。実際にフォーラムでも同じような質問を見つけましたが、そこでは以下のような解決策が示されていました。 各Labelを計算フィールドにする 言語を表すパラメータを作る 計算フィールドの中で、パラメータの値（＝各言語）毎にラベルを定義する これを全部に対して適用する ・・・シートが1つ2つならまぁいいかなって思わなくもないですが、私がもっているのは30シート/10オーバーのDatasourceだったので、とてもじゃないですが参考にできませんでした。 一括で変換したい フォーラムの中では、それ以外にも案が示されていて、その中で一番有望なのが XMLを直接書き換える という方法でした。 Tableauの .twb 拡張子は、エディタで開いてみると単なるXMLになっています。これを直接書き換えればいいやん、というある意味単純な話です。これしかない！って感じで、この路線で進めてみました。 こぼれ話：TableauのAPIクライアント コミュニティで作られているものですが、tableau_toolsというライブラリがあります。 tableau_toolsのリポジトリ これの中にも、Workbookをよしなに書き換えてくれそうなものがあったので、最初はこれを使ってみました。ただ、私の目的にはそぐわなかったので、利用しませんでした。どちらかというとTableauのAPIを叩くほうが主眼のライブラリだったんで、それも仕方ないかな、と。 Tableau Workbookの構造 XMLをいじるには、まず構造を知る必要があります。実際に翻訳で書き換えていった中で、結構色々と知ることができました・・・。 Tableau Workbookは、大きく以下のような構造になっています。翻訳で利用しなかった部分は省略してます。 <!-- Workbookのrootエレメント --> <workbook ...> ... <datasources> <!-- データソース。パラメータもデータソースです。パラメータは、captionがなくってnameがParametersで固定です。 --> <datasource name="Parameters"> <!-- nameはTableauの計算フィールドとかで利用するときの名前です。captionは、「名前の変更」をしたときに設定されるやつです --> <column caption="foo" name="[parameter 1]"> <!-- 「別名」から設定されるものです。membersもセットになっている・・・かもしれません。 パラメータの場合は少なくとも必要でした。 --> <aliases> <alias key="0" value="foo" /> <alias key="1" value="bar" /> </aliases> <members> <member alias="foo" value="0"/> <member alias="bar" value="1"/> </members> </column> </datasource> <!-- PostgreSQLとかのDatasourceだと、nameはtableauが生成した値で、captionには画面側で利用する値になっています。 --> <datasource caption="foo" name="..."> <column caption="a" name="original"> ... </column> </datasource> </datasources> <worksheets> <!-- 各ワークシートです。nameがWorksheetとIDとほぼイコールなので、変更する場合は結構大変です --> <worksheet name="worksheet1"> <style> <!-- 軸のstyleに関する設定です。element="axis"の中を見ると大体わかります --> <style-rule element="axis"> <format attr="title" value="軸" /> </style-rule> <!-- 凡例のstyleに関する設定です。いくつかある場合は複数になるようです。 valueをいじるだけでいいパターンと、formatted-text/runを追加する必要があるケースがありましたが、 formatted-textも設定しておくのが正のようです。 --> <style-rule element="legend-title-text"> <format ...> <format value="凡例" ...> <formatted-text><run>凡例</run></formatted-text> </format> </format> </style-rule> </style> </worksheet> </worksheets> <dashboards> <!-- ダッシュボードです。worksheetと同じく、nameがIDです --> <dashboard name="dashboard"> <!-- ダッシュボードでの配置を管理しているもののようです。 翻訳では、この中のnameが、変更後のworksheetと同様になる必要があります。 --> <zones> <zone name="worksheet1" ...> </zone> <zone name="worksheet2" ...> </zone> </zones> </dashboard> </dashboards> <windows> <!-- tableauデスクトップとかで下に表示されているものの一覧です --> <!-- class=dashboardはダッシュボード、class=worksheetはワークシートです。 ここのnameは、必ず<worksheet>や<dashboard>と一致させる必要があります。 --> <window class="dashboard" name="dashboard"> <viewpoints> <!-- dashboardの場合だけ（多分）翻訳が必要です。ここのnameは、他の<workspace> 要素と一致している必要があります。 --> <viewpoint name="worksheet1" ...> </viewpoint> </viewpoints> </window> <window class="worksheet" name="worksheet1"> </window> </windows> </workbook> 今回必要だったのは以下の部分でした。 ...