図解即戦力 Google Cloudのしくみと技術がこれ1冊でしっかりわかる教科書［改訂2版］
読みました。
読んでレポートを書く必要があったので読んだ。
1967年の本なのでさすがに古くてちょっと読みにくい。
しかしながら、挙げられている事例は、明治期〜昭和初期のことが主となっていて、興味深いものが多い。現在の日本人の法意識のベースになっているものがこういうところから来ているのか、と考えさせられる。
一方で、現代ではだいぶ失われている慣習も多くなってきており、西洋化が進んでいる部分もあると感じる一方で、まだまだ日本の明治期から続く流れもまだまだあるのかなぁという気はするので面白かった。
などなど。
読んだ。JTCで予算とるにはどうしたらいいかっていう視点で書いてあるのは面白い。
Collecting romkan
Using cached romkan-0.2.1.tar.gz (10 kB)
Preparing metadata (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py egg_info did not run successfully.
│ exit code: 1
╰─> [6 lines of output]
Traceback (most recent call last):
File "<string>", line 2, in <module>
File "<pip-setuptools-caller>", line 34, in <module>
File "/private/var/folders/kg/nqb8t2f1253_kh0r_rl06pcm0000gq/T/pip-install-cmsaoeh6/romkan_3dc774240ae4470fa4013b902bdab42c/setup.py", line 8, in <module>
import os, json, imp
ModuleNotFoundError: No module named 'imp'
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed
× Encountered error while generating package metadata.
╰─> See above for output.
note: This is an issue with the package mentioned above, not pip.
hint: See above for details.
となって悲しい。
https://github.com/soimort/python-romkan/issues/17
https://docs.python.org/3.11/library/imp.html
imp というモジュールが、python 3.12で消えたようだ。
romkan に関して言うと、そんなに大きいライブラリではないのでコピペして使うのが良いかもしれず。。
なんかいろいろ似たようなのはあるんだけど、ncdu がわりと良さそうだった。
brew install ncdu で入る。子ディレクトリのファイル容量多いやつを探してくれる。
https://github.com/tokuhirom/momiji
Pure kotlin な形態素解析機が欲しかったから。なぜ pure kotlin がいいかというと、kotlin multiplatform な環境で形態素解析したかったから。
実践・自然言語処理シリーズ2 形態素解析の理論と実装 が網羅的で、どういうふうに mecab が作られてるかを解説してくれてるので、この通りに実装すればまぁ普通にできる。
形態素解析は、ラティス構築してビタビアルゴリズムで最小コスト経路をたどればできるということは知っていたので、というかまぁ IME 作るのとやってることはほとんど一緒なので、やればできるということは知っていたので、やってみたという感じ。
kotlin multiplatform で動くからもちろん JS でも動くので、デモサイトも作ってみました。 https://tokuhirom.github.io/momiji/
mecab の辞書をパースして、ラティスを構築してビタビアルゴリズムでコスト最小な経路を求めた。
mecab のバイナリ辞書のパースは sys.dic, unk.dic, char.bin, matrix.bin の4つのファイルをパースできれば、ひと通りの事ができる。
バイナリファイルはすべてリトルエンディアン。
sys.dic はシステム辞書で、unk.dic は未定義語のコストが入っている特殊辞書。フォーマットは同じ。
val magic = byteReader.readUInt()
val version = byteReader.readUInt()
val type = byteReader.readUInt()
val lexsize = byteReader.readUInt()
val lsize = byteReader.readUInt()
val rsize = byteReader.readUInt()
val dsize = byteReader.readUInt()
val tsize = byteReader.readUInt()
val fsize = byteReader.readUInt()
val dummy = byteReader.readUInt()
という感じでヘッダ領域がある。magic は 0xef718f77u とファイルサイズの xor で、これにより辞書が壊れていないかを確認できる。
その後に 32 byte の charset 領域がアリ、charset が格納されているはずだが、現実には "yes" という文字列が入っている。./cofigure の結果の charset じゃない文字列とかが入っちゃってるのかなぁと思いつつ、現実的には utf-8 決め打ちするので無視して問題ない。
その後、dsize バイト分の領域に、Darts の double array が格納されている。
そして、tsize 個のトークンが格納されている。Token は以下のようなフォーマット。
data class Token(
val lcAttr: UShort,
val rcAttr: UShort,
val posid: UShort,
val wcost: Short,
val feature: UInt,
val compound: UInt,
) {
companion object {
const val SIZE = 2 * 4 + 4 * 2
}
}
あとは fsize バイトの feature が入っている。
未定義語を判定するための文字種定義。例えばカタカナの連続だったら一つの未定義語とする、みたいな処理をするために使う。
32bit unsigned int で char category の数が格納されている。char category は 32 バイトの固定長文字列で、null terminated である。その後、0xFFFF 個の unsigned int が格納されております。
bit field になってるけど以下のような構造。
data class CharInfo(
val type: Int,
val defaultType: Int,
val length: Int,
val group: Boolean,
val invoke: Boolean,
)
連接コストが入ってる。
ヘッダに unsigned short 2つで lsize と rsize が入っている。ここから、lsize * rsize 個の short が入っている。
連接コストは matrix[leftContextId + lsize * rightContextId] のようにして取得可能。
なんか common prefix search したいわけだが、、 https://blog.64p.org/entry/2024/07/24/010456 先日、KDary という実装を作ってできるようにしたんだけど、mecab のバイナリ辞書には Darts のバイナリが埋まってたので、これをそのまま使ったほうが効率がいいという話に。。
Darts のバイナリを使って common prefix search するだけならこれだけで実装できた。
なんかこういう感じでやったらできた。
ガーッとラティスをたどりながら最小コストを計算していって、最後に逆向きに最小コスト経路をたどっていくだけなので簡単。
形態素解析って大変なのは辞書作るところなので、すでにある辞書を利用する分には簡単に実装できた。コード量としても大した事ない感じ。 あと、工藤さんの本がめっちゃ丁寧なのでかいてある通りに実装すれば普通に動いた。
https://github.com/JetBrains/kotlin-wrappers/commit/90f32c011dd11159f599339e8ff6c4af177c2465
useEffect が suspend fun を受け入れるようになっているので、不要になったようだ。
https://central.sonatype.com/artifact/io.github.tokuhirom.kdary/kdary https://github.com/tokuhirom/kdary
KMP(Kotlin Multiplatform) 環境で Mac アプリを実装していた。その中で雑な文書要約をしたくなり、 TF-IDF を使いたくなった。日本語で TF-IDF を使うには単語を分かち書きする必要があるわけだが、分かち書きするには形態素解析機を使うのが手っ取り早いということになる。しかしながら、KMP 環境では利用できる日本語形態素解析機は存在していない。 ないものは作るしかないので、作るのだが、日本語の形態素解析を効率よくやるためには共通接頭辞検索を行う必要がある。このために使えるライブラリも KMP 環境には存在していない。 そこで、まずは共通接頭辞検索のためのライブラリを、他の言語から移植することとした。
MeCab の実装を参考にすれば、移植元は Darts,Darts-Clone, MARISA あたりがパッと思い浮かぶ。tx,rx, ux とかでも良い。xcdat や crawdad でも良い。
LOUDS でもダブル配列でもいいんだけど、シングルファイルで実装されてて移植が簡単そうな darts-clone をベースとすることとした。Darts よりも darts-clone のほうが生成ファイルが小さくなるという点も魅力である。そこそこの速度がでて、実績あるやつならまじでなんでもよかった。
darts-clone の移植は、chatgpt などの力も借りてやろうと思ったが、思ったよりうまくいかず。c++ のコードでは、メソッド呼び出し時に参照やポインタを渡す事ができ、そこを書き換えることが可能だが、そういう概念を chatgpt がうまく解釈できないようだ。今どき、c/c++ 以外でそういう言語ないしな。。 というわけでほとんど手書きした。テストケースは概ね chatgpt に生成させ、darts-clone の出力と突合し、正解データを darts-clone のものに揃えるように実装を調整しながらデバッグしていった。 本来、darts-clone では配列の添字の範囲が size_t だが、kotlin では配列の添字の範囲が Int なので、Int の範囲になるように調整した。
2024-07-06 に実装開始して、2024-07-16 に maven central にリリースしているので、片手間にやって約10日の実装期間ということになる。
ByteArray を Set に入れようとしてハマった。
val setByteArray =
setOf(
"a".toByteArray(),
"a".toByteArray(),
"b".toByteArray(),
)
println(setByteArray)
のような場合、"a".toByteArray() が重複登録されてしまう。 まぁ、これは JVM から始まった言語だからしょうがないが、罠い。
KMP のライブラリは Maven Central へのリリースが可能だ。
先日の kotlin fest で発表していた atsushieno さんのブログ記事を参考にして試したところうまくいった。昔は Maven Central への登録は担当者との温かみのある JIRA 上でのやりとりが必要となっていて、めんどくさかったが、今は github 認証をすれば、io.github.tokuhirom 以下にスッとアップロードできるようになっていて、圧倒的に簡単になっている。
https://zenn.dev/atsushieno/articles/d066e757c9640f https://speakerdeck.com/atsushieno/building-kotlin-multiplatform-libraries-in-2024-cc23c2ab-bbbd-4e28-bd05-c46985685a23
atsushieno さんに感謝。
https://libs.kmp.icerock.dev に KMP なライブラリはまとまってるんで、ここに登録していく。
Pull request を出せばいいだけなので簡単だ。 https://github.com/icerockdev/libs.kmp.icerock.dev/pull/111
Kotlin fest 2024 に参加してきたんで、そのレポート。 JJUG CCC 2024 Spring から一週間たたずの開催。
https://www.kotlinfest.dev/kotlin-fest-2024
https://speakerdeck.com/n_takehata/kotlin-server-side-programming-practice-2024 https://fortee.jp/kotlin-fest-2024/proposal/9c5d8033-173a-4785-a072-abe61af9a531
竹端 尚人さんの発表。
2021年に発売された Kotlin サーバーサイドプログラミング実践開発 からの状況の変化をおさらいしよう、という内容。
書籍は spring-boot, junit,mybatis みたいな構成だったのを、ktor, Koin, kotest, JOOQ にしたらいいんじゃね、みたいな話。
ほかはともかくとして、mybatis/JOOQ の関係性は3年前と一緒な気がするなァ、とは思いつつ。あと、個人的には SQLDelight とかも気になる。
個人的には、Ktor が DI を実装するということをすでに発表しているので、DI 周りはその動向を注視する必要がありそうというのが気になる。ktor の DI の出来がよかったら、そっちにみんな流れる気がしている。 なので、今 spring boot 使ってる案件とかは、ktor DI が出てから検討した方がよい気がする。いつ出るのか知らんけど。。 https://blog.jetbrains.com/kotlin/2024/03/ktor-2024-roadmap-di-update/
結構、ktor の DI がリリースされると、新規案件では boot よりも ktor を採用するケース増える可能性あるんじゃないかなぁ。どうなるかわからないけれど。
あと、kotest は個人的にはそんなにはまってないです。
この手のテクニカルスタックを選ぶときに、JVM 以外でも動くかということはそろそろ気にしたほうがいい気はしていて、FaaS などで Kotlin/JS, Kotlin/Native を採用するケースも今後出てくると思うので、そうなったときにその環境でも使えるものを選んだ方が楽なんじゃないかなぁという気がしております。
https://fortee.jp/kotlin-fest-2024/proposal/b6a4b643-825d-4068-bb58-c659feeb8fbd
RyuNen344 さんの発表。最近、kotlin native 使ってるのもあり、Okio は最近触ってたのでタイムリーな話題。kotlinx.io が公式みがあるものの、Okio にあって kotlinx.io にないものがめちゃくちゃ多いんで、現実的には kotlin native 使う場合は Okio 一択ぽさありますね。
Atsushi Eno さんの発表。 kotlin multiplatform 用のライブラリを公開するこつ、みたいなセッション。
網羅的に説明されていて良かった。個人的には、maven central は難しすぎるので、何か別のレポジトリを JetBrains がホスティングする未来をお願いしたいところです。
kotlin multiplatform 用のライブラリって今めちゃくちゃ貧弱なので、ライブラリ作ったら案外使われると思うので、チャンスだと思う。Java のライブラリって作っても使われにくいけど、kotlin だと結構いけそうな気がする。
https://x.com/kitakkun_pb/status/1804444762491302176
kitakkun さんの発表。K2 コンパイラのフェーズを細かく日本語で解説してて良かったです。 なんかネタがあったら Compiler Plugin 作ってみたいが、、少なくとも Perl の B tree よりはドキュメント多くていじりやすそうだった。
https://fortee.jp/kotlin-fest-2024/proposal/ff006096-bfbe-4389-8e76-ef2a528a4477 https://speakerdeck.com/yanex/k2nokotlin-idepuraguinnozhong-wosi-itemiyou
Yan Zhulanow さんのセッション。
Kotlin は、IDE と密に連携しながらコンパイラ開発してるっていう話とかもありつつ。 Phase とか整理して並列化されるようになったということで、IDE の安定性も上がるっぽく、楽しみ。
JetBrains のエンジニアは強いマシンスペックのマシンで開発していたが、K2 にしたらメモリ少なくても IDE の開発が可能になったので、メモリ2GBチャレンジが流行った、っていう話がいい話だった。
IDEA の K2 サポート、とはいえまだまだ kotlin native だと挙動不審だったりするので今後に期待。 「IDE のこのエラーは、こういう理由でおきててー」みたいな解説があって面白かった。
Analysis API が公開されるというアナウンスもあり、楽しみ。Compiler Plugin は正直、ネタがパッと思いつかないのだが、、Analysis API は結構興味あり。
Kotlin Fest の内容についてですが、 https://y-anz-m.blogspot.com/2024/06/kotlin-convert-java-file-to-kotlin-file.html Kotlinらしいコードを書こう - Convert Java File to Kotlin File のあとにやること というセッション(登壇者体調不良で飛んだセッション)は、kotlin 初心者には良さそうでした。 最近、Kotlin いきなり書くことになってる人とかにおすすめです(普段から書いてる人には当たり前の話が多そう)。
kotlin-wrappers の 1.0.0-pre.757 から 1.0.0-pre.758 までのバージョンで、もんだいがあった..
println(process.platform)
というコンパイルが以下のようなエラーでコンパイル出来なくなったのだ。
> Task :compileProductionExecutableKotlinJs FAILED
e: java.lang.IllegalStateException: IrTypeParameterPublicSymbolImpl for [ node.stream/StreamOptions.Companion.invoke|invoke(web.abort.AbortSignal?;kotlin.Double?;kotlin.Boolean?;kotlin.Function2<kotlin.Throwable?,kotlin.Function1<kotlin.Throwable?,kotlin.Unit>,kotlin.Unit>;kotlin.Boolean?;kotlin.Function1<kotlin.Function1<kotlin.Throwable?,kotlin.Unit>,kotlin.Unit>;kotlin.Boolean?){0§<node.stream.Stream>}[0] <- Local[<TP>,0|TYPE_PARAMETER name:T index:0 variance: superTypes:[node.stream.Stream] reified:false] ] is already bound: TYPE_PARAMETER name:T index:0 variance: superTypes:[node.stream.Stream] reified:false
at org.jetbrains.kotlin.ir.symbols.impl.IrBindablePublicSymbolBase.bind(IrPublicSymbolBase.kt:69)
at org.jetbrains.kotlin.ir.declarations.impl.IrTypeParameterImpl.<init>(IrTypeParameterImpl.kt:48)
at org.jetbrains.kotlin.ir.declarations.impl.AbstractIrFactoryImpl.createTypeParameter(IrFactoryImpl.kt:380)
at org.jetbrains.kotlin.ir.declarations.impl.IrFactoryImplForJsIC.createTypeParameter(IrFactoryImplForJsIC.kt:361)
at org.jetbrains.kotlin.backend.common.serialization.IrDeclarationDeserializer.deserializeIrTypeParameter$lambda$8(IrDeclarationDeserializer.kt:286)
at org.jetbrains.kotlin.ir.util.SymbolTable.declareScopedTypeParameter(SymbolTable.kt:421)
at org.jetbrains.kotlin.backend.common.serialization.IrDeclarationDeserializer.deserializeIrTypeParameter(IrDeclarationDeserializer.kt:308)
at org.jetbrains.kotlin.backend.common.serialization.IrDeclarationDeserializer.deserializeIrTypeParameter$default(IrDeclarationDeserializer.kt:279)
at org.jetbrains.kotlin.backend.common.serialization.IrDeclarationDeserializer.deserializeTypeParameters(IrDeclarationDeserializer.kt:465)
at org.jetbrains.kotlin.backend.common.serialization.IrDeclarationDeserializer.access$deserializeTypeParameters(IrDeclarationDeserializer.kt:68)
at org.jetbrains.kotlin.backend.common.serialization.IrDeclarationDeserializer.deserializeIrFunction$ir_serialization_common(IrDeclarationDeserializer.kt:1204)
at org.jetbrains.kotlin.backend.common.serialization.IrDeclarationDeserializer.deserializeDeclaration(IrDeclarationDeserializer.kt:821)
at org.jetbrains.kotlin.backend.common.serialization.IrDeclarationDeserializer.deserializeDeclaration$default(IrDeclarationDeserializer.kt:815)
at org.jetbrains.kotlin.backend.common.serialization.IrDeclarationDeserializer.deserializeIrClass(IrDeclarationDeserializer.kt:390)
at org.jetbrains.kotlin.backend.common.serialization.IrDeclarationDeserializer.deserializeDeclaration(IrDeclarationDeserializer.kt:820)
at org.jetbrains.kotlin.backend.common.serialization.IrDeclarationDeserializer.deserializeDeclaration$default(IrDeclarationDeserializer.kt:815)
at org.jetbrains.kotlin.backend.common.serialization.IrFileDeserializer.deserializeDeclaration(IrFileDeserializer.kt:40)
at org.jetbrains.kotlin.backend.common.serialization.FileDeserializationState.deserializeAllFileReachableTopLevel(IrFileDeserializer.kt:127)
https://github.com/JetBrains/kotlin-wrappers/commit/9efe9b6a1aceefb8b86114b02667660cb4009e35
でワークアラウンドがコミットされた。この変更がコミットされた 1.0.0-pre.759 がリリース済み。が、なんかまだ maven repository で見えない。
本質的にはコンパイラのバグなので、YouTrack に登録されている。すでに修正済みなので、次回のリリースで直るだろう。 https://youtrack.jetbrains.com/issue/KT-68943/JsPlainObject-breaks-when-interface-has-type-parameters
2024年の春、昨日開催されたJJUG CCC 2024 Spring に参加してきました！家庭の事情で午後からの参加となりましたが、Javaコミュニティの熱気を肌で感じながら、最新技術の情報や多くの開発者との交流を楽しむことができました。この記事では、キーノート、ブースでの会話、懇親会、そしてアンカンファレンスの様子をレポートします。
最初のキーノートは、「Java First. Java Always.」というタイトルで、OracleのJavaエキスパートたちが登壇しました。Javaの最新機能を紹介しながら、次世代アプリケーション開発の未来を描く内容でした。特に、オンプレミスからクラウドまで対応するJavaの強みが強調されており、開発者として非常に励みになりました。
次に聞いたのは、「FFMでJITコンパイラを作ってみた」というセッション。Java 22で正式に導入されたForeign Function & Memory API（FFM）を使って、JITコンパイラを実現するという興味深い内容でした。ffmasmライブラリを使って、Javaからネイティブコードを動的に生成・呼び出す方法が紹介され、FFMの新たな可能性を感じました。
イベント中にFindy、Samuraism、Azulのブースを訪れ、それぞれの担当者とお話をしました。
懇親会にも参加しました。LT大会が非常に盛り上がっており、参加者同士の活発な交流が見られました。変に食事があるよりも、乾き物しかない開場の方がかえって懇親しやすいと感じました。皆がリラックスして会話を楽しめる雰囲気がとても良かったです。
アンカンファレンスにも参加しました。今回はフレームワークの話とAIの話が中心でした。
Spring Boot 3系への移行が大きなトピックでした。Jakarta EEへの移行が主な変更点であるため、実際のアップデート内容はそこまで大きくないとの意見も。QuarkusやMicroProfileも選択肢として挙がり、開発者たちの関心の高さが伺えました。
AIを用いたコーディングについて話し合いました。特にGitHub Copilotのデモが盛り上がり、ほとんどの参加者が実際に使用していることが印象的でした。寺田さんが別のイベントの動画を流しながら、GitHub Copilotのデモについて詳しく解説してくれました。今後の進歩に大きな期待が寄せられています。
JJUG CCC 2024 Springは、Javaコミュニティの最新情報や技術トレンドを学ぶ絶好の機会でした。キーノートやブースでの交流、懇親会、そしてアンカンファレンスを通じて、多くの刺激を受けました。これからもJavaの進化と共に、開発者として成長していきたいと思います。
参加者の皆さん、そして運営スタッフの皆さん、お疲れ様でした。また次回のイベントでお会いしましょう！
ScreenCaptureKit では display 全体をキャプチャするときに、initWithDisplay:excludingWindows: で excludingWindows に empty list を渡したらなぜか動かない。initWithDisplay:includingApplications:exceptingWindows: に動いている全部のアプリケーションをリストアップしたら動く。
https://federicoterzi.com/blog/screencapturekit-failing-to-capture-the-entire-display/
ドキュメントとかみてもよくわからんけど、事実そう。