React でサーバとデータ連携する方法を調査中。 取り急ぎ、前回はサーバから json を取得したので、今度はPOSTで送信してみます。 送信する内容はフォームに入れた文字列とします。 React でフォーム処理する部分はこのドキュメントを参照のこと。

React でサーバとデータ連携する方法を調査中。 取り急ぎ、サーバから json を取得してそれを React でレンダリングするところまでのメモ。 ポイントは、React のFAQ に書いてあります。

サラサナノにのりかえた 的な話から9ヶ月経過、 相変わらずサラサナノを使っています。 ただし、中身はエナージェルインフリーの替芯です。

一方で、実は一ヶ月ほど前に uni-ball ONE（ユニボール ワン）F を入手してテスト的に使いはじめたのです。 中身は 無印の「替芯　ゲルインキボールペン」 です。

そもそもの動機はエナージェルインフリーの書き味が良き！となって、しかし、あの純正軸はほんとに嫌（個人の感想です）なので、 それ用の気に入った軸を購入しようと文具店を散策していたところ、uni-ball ONE F を見つけた次第。

「初めての TensorFlow.js」の８章にニューロン一個を使って一次関数を導く例が出ていた。

任意の一次関数の x,y のセットを機械学習させることで、 y = a*x +b の a（傾き）と b（切片）を機械的に見つけることができる、という話。 そこで、これ相当の機能を自前のコードで実装することを試みた。

テンソルの操作になれるために、TensorFlow.js を使って画像を操作する練習。

Word2Vec ... いまさら感がありますが、Wikipediaダウンロードから手順を書き残します。

使用した環境は Ubuntu 22.04 LTS です。

ポケモン名のリストから最も出現頻度の高いポケモンをみつける というエントリーを書きましたが、その内容を Haskell へ移植しました。

あとで、備忘録として移植手順を書き残すつもりですが、今はまずは結果だけメモします。

決定木のプログラミングをしているときに必要になった関数。 これを備忘録としてメモしておきます。

XMLデータをいい感じに javascript のオブジェクトに変換してくれる・・・という fast-xml-parser。

実際に使ってみた結果躓いた点を書き留めます。

以前にも同じようなことしていた。 Node.js で XML文書をパース

このときは XMLのパースに xmldom を使っていた。 完全に覚えていない。

HashMapを生成して、その中のエントリーの種類に応じて別々の HashMap を生成するためのコード（備忘録）。

取り急ぎベジェを使った円の描画を復習したので書き残す。

Android Studio を使わない ライブラリプロジェクトで Robolectric テストをする一番簡単なプロジェクト例 というエントリーを２年ほど前に書いたのですが、いろいろバージョンアップされて古くなってしまった。このテストプロジェクトをそこそこ最近のAndroid開発環境で動くようにしたので、その備忘録です。 作動確認はしていますが、Robolectric よくわかっていないのでその点はご了承ください。

たとえば、0,1,2 という index を生み出す場合、いくつかの書き方がある。

先日、Windows11 22H2 のアップデートがきた。待っていた systemd 対応がきたので、早速更新。 せっかくなので、Windows の回復を利用して、フルリセットに近い形で Windows11 22H2 を入れた。 始める前は Windowsの再インストールは気が重かったのだが、やってみたら簡単だった。以前はもっと大変だったという印象がある。まだまだ ChromeOS ほどではないにしても。 Windows11 22H2 をセットアップしたあと、通常手順で wsl --install してインストールしたところ、インストールされた Ubuntu は systemd に対応していなかった。 ちなみにインストールされたのは Ubuntu 20.04.4 LTS。 上記 microsoft devblogs を読み直してみると、Windows Insiders Build でないと systemd 対応版の WSL はインストールされないらしい。 でもさらによく読んでみたら、github のWSL リリースページから 0.67.6 を入手して手動でインストールすればよいらしい。 果たしてやってみると、systemd対応になった。 Wnn8 をインストールしたらすんなり自動起動できるようになった。 Windowsを再起動して WSL を起動したら、自動で Wnn8 が起動している。 とりあえずは、systemd 対応でうれしいのは（自分にとっては）これだけだけど。 以前に書いたこの Wnn8インストールのエントリーの後半で、 なんやかんや Wnn8 の起動設定をしている部分がいっさい不要になった。

以前にGroovy / Golang / Node.js, リストを n 個ごとに分割したリストのリスト(サブリスト)をつくりたい というエントリーを書いたのだが、kotlin でそれをつくり出す必要が生じたので備忘録として書き残します。

ここで言うサブリストとは、リストを n 個ごとに分けたい、という場合につくるリストのリストのことです。

まずそもそもの話、 Excel のチェックボックスのチェック状況を特定のセルにリンクして記録する機能(Cell link)があらかじめ備わっているので、それを使うべき。 そうすれば、このエントリーで書いているようなことを行なわなくても普通にPOIとか node.js の xlsx 系ライブラリで難なくその値を読むことができます。

英語レイアウト版 MX Keys Mini がついにリリースされたので入手しました。 7月末、ちょうど amazon.com でUS版を購入しようとしていたそのときに、 日本での発売がアナウンスされてこちらを予約しました。 もう少しで amazon.com で買うところでした。 日本のLogicool版の英語レイアウトキーボードを買っておけば、 今度は、メカニカルキーボードの方も英語レイアウト版も発売してくれるに違いない。

EPS は、 https://xmlgraphics.apache.org/commons/ を使って、 PDF は、 https://pdfbox.apache.org を使って、 それぞれ 画像のタテヨコの大きさを取得します。 使用する言語は kotlin script です。

久しぶりにデバッグ画像をプログラムから生成する必要が生じたので、Java2D による画像生成を復習した。

Kotlin の Sealed クラスを使えば、 代数データ型の直和型を表現できる、という情報を得たので、MaybePokemon クラスをつかって試してみた。

しばらく諸事情により遠ざかっていた Android アプリ開発を再開しようと思っている。 そのウォーミングアップとして Kotlin でスクリプトを書いたりしているのだが、 結構いい感じ。 もちろん普通に JavaVM 上で動く Kotlin で開発しているのだが、 それとは別に Kotlin Native というものがあり たとえば Linux X64 ネイティブ実行できる実行ファイルを生成できるらしい。 かっこいい！と思って調べはじめたのだが、思いのほか難しかった。 とりあえず、テキストファイルを読みとって標準出力するところまでたどり着いたので、 その記録を残す。

前のエントリー MacBook Air M1 に bash と emacs のセットアップ備忘録の補足です。

Kotlin をコマンドラインで使う方法は、 以前のエントリー Kotlin Script が便利 Javaのライブラリも使える でも書いたのですが、 何通りかの方法があるので、整理しました。 Kotlin でライブラリ(jar)をつくり、それを Groovy スクリプトから使うこともできます。

jq をソースからインストールしたので備忘録を残す。

いつまで耐えられるかわからないが、 とりあえずこの MacBook Air M1 には home brew を入れないと決めている。 そして、 jq を使おうとしたら当然コマンドが存在しない。

jq も簡単にソースからビルドできると思ったがそうはいかなかった。

最初に jq 1.6 を試したが、 oniguruma の部分が解決できなかった。 jq 1.5 はビルドできた。

先日の Cloud Vision API を使う Python3 編 に続いて Spring Boot Kotlin での Cloud Vision API の OCR のコード覚え書きです。

Python で既に書いたコードを Kotlin に移植しました。 Spring Boot は今まで使う機会がなかったのですが、 今回使って良いと思ったのは gradlew bootJar するだけで executable な単一の jar ファイルを生成してくれることです。

ただ Python のようにスクリプトファイルひとつで処理できるような小さな処理に Spring Boot を使うのは気が重いですね。

Google の Cloud Vision APIの機能のひとつにOCRがあり これを業務で使う機会がありました。 実際に使ってみると、対象が印刷物をスキャンした画像データだったなど条件がよかったのだとは思いますが ほぼOCR処理として100%に近い形でテキストに変換されました。 とはいえ、100%ではないので、そこは人間が一度はすべて確認する必要がありますし、 そもそもOCRで読みとったテキストをこちらが使用したい単位に整理する処理については 当然OCRの守備範囲外になります。 そのため、その部分のコードを書くのが相当に大変でした。

もし人間が目視＆手作業としてテキスト入力すれば、その整理部分も含めて人間が処理することになる。 それがアウトソーシングとしてページ単価いくらで予算の範囲で収まるのであれば、 どうなんだろう。 自分ががんばって書いたコード部分は結局たいした価値があるのだろうか……という微妙な仕事になってしまった。

そろそろ シリコンマックに移行しないと……と思い立ち先月 MacBook Air M1 を購入した。 それが今年のWWDCの前だったので、それまで待って発表内容を見てから購入すべきか悩んだ。 しかし、刷新された MacBook Air 2022 が出る、という噂があったので、 既存の MacBook Air が廃盤になって購入できなくなると困るという考えがあった。 12inch MacBook のときがそうだったように、入手しようか悩んでいるうちに廃盤になって購入できなくなるのは避けたい。 それに、仮にその新しい MacBook Air 2022 が素晴らしいものだとしても、 ここ最近の円安により相当値段が高くなることが予想されたので、 十分実用的だと感じている MacBook Air M1 が10万円ちょっとで買えるならば、 どのみち、新しい MacBook Air 2022 を買うことはないだろう。 それならもう開催前にオーダーしてしまおう。 最悪のケースでも 2週間以内なら返品できるわけだから、などと悩みつつ購入。

先日、電子書籍「ExtendScript と Node.js による Markdown to InDesign 開発入門」をリリースしました。 Amazon の Kindle Unlimited の会員の方は無料で読めます。ExtendScript に関心がある方は是非ご覧ください。

これは、 以前リリースした「Node.js による InDesign ExtendScript モダン開発入門」の続編です。

書籍中のソースコードはこちらの Github レポジトリにあります。

たとえば、次のようなポケモンオブジェクトのリストがあったとして:

[
  { name: 'Eevee', type: 'normal' },
  { name: 'Pidgeot', type: 'normal' },
  { name: 'Pikachu', type: 'electric' },
  { name: 'Raichu', type: 'electric' },
  { name: 'Jigglypuff', type: 'normal' },
  { name: 'Squirtle', type: 'water' },
  { name: 'Golduck', type: 'water' },
  { name: 'Voltorb', type: 'electric' }
]

これをタイプ別にグループ化したリストのリストをつくる関数を考えます。

こんなエクセルデータの表 pokemon-type-table.xlsx があったとして、それを読み取る。 そして ポケモン名からポケモンタイプを引けるようにする。

macOSまたは Chromebook のLinux において、Emacs で編集しているときに現在のカーソル行にある URL をブラウザで開く方法を調べた。

サラサナノにのりかえた 的な話から3ヶ月経過、 相変わらずサラサナノばかり使っています。

前回のエントリーでは サラサナノ + 0.3mm のリフィルは使い辛いと書いていたのでしたが、すみません、違いました。 それは、使うノートの方の問題で、ノートの種類によっては 0.3mm のリフィルはとても機能します。

この問題を解くHaskell による実装を書いたのだが、 結局のところ、対象となる文字列（画像ファイル名)の等価性をカスタマイズするために、 文字列を丸めてそれを使って等価性の比較を行っているだけ。 Haskell では、 Eq 型クラスを自前で用意した Item 型に実装する形で、 言語にもともと備えられている仕組みを 使っているのでコードとしてはわかりやすいのは確かだけれど。

そこでこの問題を Haskell 発想により近い形で JavaScript で実装しなおしてみる。

前回のエントリー微妙に揺れのある２つの文字列リストに対する積集合(Intersection)と差集合(difference)の計算 の Haskell 編です。

積集合と差集合とか書いて・・・途中で気づいたのですが、２つの集合の差だけを求めれば済む話だった。 Haskell 編では差だけを求めます。

微妙に揺れのある次のような 二つの文字列リスト（画像ファイル名）があるとする。

const listA = ['grape.pdf', 'apple_v1.pdf', 'apple_v2.pdf', 'lemon_v1.pdf', 'peach_v2.pdf'];
const listB = ['grape.png', 'lemon.png', 'strawberry.png'];

listA の画像から listB の画像をPDFからPNG変換して作成した、という状況。 変換し忘れている画像ファイル(PDF)を知りたい。 そんな場合の計算方法について考える。 なお、世の常として listB に listA には存在しない strawberry が間違って混入されている、という例になっている。

Node.js の xlsx モジュールを使って、データの入っている範囲を計算します。 その他、特定の行のデータを取得したり、列データを取得する方法について覚え書き。

このエクセルデータのダウンロード: potate.xlsx

今 ExtendScript を使って markdown テキストを InDeisgn 文書に変換する方法を考えている。 その際に画像の大きさの扱い方で悩んでいたのだが、 pandoc で ICML を経由して markdown を InDesign にする場合は、 markdown で次のようにそれを指定できるらしい。

Windows の WSL みたいに MacOS でも軽快に（VirtualBoxやParallelsほどおおげさでなく）Ubuntuを使いたい。 と思っていたら Multipass を使えばよいだけだった。

以前のエントリー ブラウザテキストエリアで Emacs キーバインド を使いたい で、普通にブラウザで Ctrl + N が使える方法を探していたのだが、 ここしばらくは、 Windows11 で Vivaldi というブラウザを使うことで 回避してきた。

先日 markdown-to-ast を使って markdown をパースするというエントリーを書いたのですが、 markdown-to-ast は commonmark をラップしたライブラリだとの情報を得た。

それならば、markdown-to-ast を使うのではなく、直接 commonmark を使ってみることにする。

文字スタイルをスクリプトでつくって適用する方法を調べた。

それを使って Hello, World! を生成して、段落スタイルと文字スタイルを適用するスクリプトを書いたので 備忘録を残します。

markdown で記述されたテキストをパースしてあれこれしたい場合。 markdown-to-ast が便利そうなので、使ってみた。 これはすごい便利。

2022-04-04 更新: commonmark 編を書きました。

コーヒーメニューの価格改訂リストの作成で書いた再帰関数をリファクタリングします。

コーヒーメニューの価格改訂リストの作成の後編です。 読み取った新旧のコーヒーメニューリストをコーヒー名をキーにマージして旧価格／新価格を一覧にします。 また、エラーが含まれていたらログも書き出します。

新旧二つのコーヒーメニューアイテムリストデータを元に価格改訂データを作成する。 今度は入力データをエクセルデータにして、結果をエクセルデータとして書き出します。

Writer モナドを使ったコーヒーメニューの価格改訂リストの作成 の改善版をつくります。 新旧のアイテムリストから、同じコーヒー名を持つアイテムを組み合わせたタプルをつくる方法を改善します。 →２つのリストの要素を組み合わせたい（リストモナド）

新旧２つのコーヒーメニューアイテムリストがあり、 そこから同じコーヒー名をもつ新旧アイテムの組み合わせをつくりたい、という問題を考える。

ひとつの方法（方法A）は、ユニークなコーヒー名リストを作成し、 それを使って、新旧２つのリストからそのコーヒー名を持つアイテムを取り出し、新旧アイテムをタプルにする。

もうひとつの方法（方法B）は、新旧２つのコーヒーメニューアイテムリストの各要素ごとの 全ての組み合わせを生成しておき、 その中かから、新旧のアイテムでコーヒー名が一致している組み合わせだけを残す。

方法Aは発想としては分かりやすいけれども、もしひとつのリスト内に同じコーヒー名を持つアイテムが含まれていると困る。 その場合を考慮してコードをかけばよいのだろうけれど、ややこしい気がする。

Writer モナドの使用例として その１ / その２ / その３ とエントリーを書いたのだが、気に入らない。 結局 Writer モナドを使う必要のないコードになってしまった。

今回はその１〜３のコードをリファクタリングして、Writer モナドを使うべき理由のあるコードに直します。

たとえば、コーヒーメニューアイテムの名前とその価格があったときに、値段が高い方を取り出したい、とする。 ただし、価格が不明なアイテムもあるので、価格の型は Mayb Int になっている。 それらを上手に取り扱いたい場合を考える。

たとえば Maybe String から String だけを取り出したい場合。 maybe 関数を使えばよい。

前回はエラーのある入力データを用意して、それを処理できるようにしました。 今回は、ようやく本題の Writer モナドを使ってエラーの内容を付加する機能をコードします。

前回は入力データにエラーがない場合を想定したコードでした。 今回はデータにエラーが含まれていた場合について考えます。 エラーが含まれていても作動するようにするだけでなく、どんなエラーなのかの説明（ログ）を同時に追加します。

Writer についてこのエントリーで軽く使い方を調べました。 今回はコーヒーの価格改訂を題材にして Writer モナドを使ってみます。

ここでは次のようなケースについて考えてみます。

以下の３つのコーヒーメニューアイテムがあるとします。

• Caffe Americano / 400yen
• Pike Place Roast / 450yen
• Caffe Misto / 500yen

これらが事情により値上げとなり、以下のようになったとします。

• Caffe Americano / 420yen
• Pike Place Roast / 480yen
• Caffe Misto / 580yen

そこで改訂前と後の価格がアイテムごとに把握できるデータを作成します。

• Caffe Americano / 400yen / 420yen
• Pike Place Roast / 450yen / 480yen
• Caffe Misto / 500yen / 580yen

方針として、まずはデータにエラーが含まれていないケースについて考えます（その１）。 その後データにエラー（不備等）があった場合に対処できるコードを Writer モナドを使って書くことにします（その２）。

今回は xlsx モジュールを使って、エクセルデータを書き出します。 前回 までにエクセルデータの読み取りと Computer 型への変換まで行ったので、 今回はその結果をエクセルデータとして書き出します。

前回 に続いてのパート2 です。

前回作成したエクセルデータを読み込むコードをモジュールにした上で、ボディ行を Computer 型に変換するところまで実装します。

xlsx モジュールを使って、エクセルデータの読み書きを試します。

処理内容は、エクセルデータからコンピュータリストを読み取り、所定の条件にマッチした情報のみをエクセルデータとして書き出すことにする。

フォームデータがPOSTされたときのサーバ側でのフォームデータ取得方法 はわかったのだが、GETのときのURLの後ろに追加されるパラメータはどう取得すればいいのか？

フォームデータがPOSTされたときのサーバ側でのフォームデータ取得の記述方法。

前回 ポケモンのモデル化とその進化を Maybe モナドと bind を使って記述しました。 変換処理を連続で適用するという意味では、前回の段階では、コードが読みやすくなった程度で モナドを使う利点がさほどない状態でした。 今回は、ポケモン進化モデルのルールを追加し、モナドを使ううれしさを探ってみます。

Haskell で練習のため キャタピー進化系のモデル化をやってみます。 Maybe Monad を使ってトレーニングとバトルでゲットしたキャタピーを進化させよう。

Twitter にて この電子書籍のアマゾン Kindle 無料サンプルは文字化けした状態であるとのご指摘がありました。 せっかく無料お試しいただいた方、誠に恐縮です。 現在、原因調査および対処中です。 → 解決しました。2022年 3月 4日 18時現在

data とそのフィールド値の取得 でポケモン型を使いました。

そのとき疑問に思ったのが、 たとえば Pokemon をレコード構文で定義した場合に ポケモン型からその名前を取得するのに name aPokemon のようにすれば ポケモン名が取得できることがわかったのですが、name のような、よくありがちな関数名を使えるようにしたら、困るのでは？ということです。

つまり、次にたとえば 進化石 EvolutionStone 型を定義したとして、 そこにも name があったらバッティングして機能しなくなるよね？ ということです。実際にやってみましょう。

前回 pure と Just の違い を調べていて、filterM の Maybe 限定版、というのを考えたのでそれを実際に試した。

Monad においては pure より return を使った方が普通なのかもしれません。わかりません。 Javaなどに慣れていると return は Java の return のイメージになり混乱するので、pure を使うで統一しています（今のところ）。 pure と return どっちなの？という件については https://wiki.haskell.org/Monad を見てください。

前回 コンピュータリストを bind ( >>= ) を使って連続して条件を適用しました。

しかし、コードをよく見てみると、 Just の部分を pure に変更しても作動するし、その逆に pure の部分を Just に変えても作動する。 今回はその謎を調べます。