
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
リンクをコピー
記事をブックマーク
bicycle1885氏(以下、bicycle1885):飛び入りでの発表なんですが、主催者の佐藤建太といいます。タイトルは「覇権を取るパッケージ作成」ということで、私がやっているパッケージの作り方の戦略について、みなさんに共有しようかなと思います。
まず自己紹介です。
いま大学院生で、博士課程にいます。専門はバイオインフォマティクスといって、バイオロジーの、生物学の研究から出てきたデータを、ソフトウェアで解析するような分野です。東大に所属していて、理研にもちょくちょく行ってるので、そのどっちかにいるということですね。
すごいJuliaマニアでして、(バージョンが)0.1か0.2ぐらいのところからずっと使ってて、もう5年以上になるというマウンティングをしておきます(笑)。たぶんJulia歴は大多数の人より長いと思います。
JuliaConにもいままで3回出ていて、参加しなかった、というか参加できなかった回は最初と今年だけですね。ハイパーパッケージクリエイターを自称していて、Juliaでパッケージをたくさん作ってます。
今日はドタ参で、お昼に1枠空くことがわかったので、急遽話を聞きながらスライドを作ってました。
さて、本日の内容です。
まず、どういうパッケージを作ってるかを紹介して、それをどうやって作ってるのかについて、簡単にお話ししようと思います。そして、どうすればJulia界で覇権を取るというか、みなさんに使ってもらえるようなパッケージを作れるのかという話を、簡単にしていきます。
(スライドを指して)これが、開発しているパッケージです。
私が始めたものでないのも1個あるんですけど。
一番上がBio.jl、バイオジュリアといって、バイオインフォマティクスのためのJuliaパッケージを作るものです。210スターで、私が関わってるものでは一番多い。
まあ、まだ新しい言語ですので、あんまりパッケージにスターがつかないんですけど、こんな感じのものを育てています。いまは、バイオジュリアは1個にするとすごく大きいので、細かく分割してパッケージにしてます。
その下はDocOpt.jlというもので、コマンドライン引数のパーサです。48スターぐらいですね。一番最初に私が公開したパッケージです。ただ、(Julia)1.0に対応できてないです。ごめんなさい。
Automa.jlは、正規表現からJuliaコードへコンパイルするコンパイラみたいなものです。これも40スターぐらいついてて、Stefan Karpinski、Juliaを作ったビッグ3の1人からもスターをもらってるという、友達に自慢できるパッケージです。
あと、EzXML.jlという、XMLフォーマットの処理ライブラリも作ってます。これも32スターぐらいあって、けっこう多いですね。マジ便利です。
TranscodingStreams.jlはデータの変換ライブラリです。これは去年作ったやつで、19スターぐらい集めています。gzip、zstd、xz、lz4、bzip2、base64などを、すべて同じインターフェースで使えます。
他にもいろいろなパッケージを、細かいものもあわせるとたくさん作っていますが、主に上げたものをスター順に並べると、こんな感じになります。
なぜパッケージを作るのか? 登山家じゃないですけど、そこにパッケージがないからです。パッケージがあるから作るんじゃなくて、ないから作ります。
基本的に、自分がほしいものをパッケージとして作っています。ほしいものがないから作ってるわけですね。既存のパッケージがあるにはあるけど、ちょっと自分の用途には向いてないときに、自作するということです。もちろん、自分がほしいパッケージですので、自分で使うことを前提として書いています。
EzXML.jlという、XMLを扱うパッケージについて紹介しようと思います。
EzXML.jlを作る前に、すでにLightXML.jlというパッケージがJulia界にはあったんですね。だけど、いくつか不満がありまして。
そもそも、メモリ管理を自前でやる必要がありました。freeっていう関数があって、それを呼ばないと、メモリがキープされたまま残り続けるという、ちょっとアレな感じのパッケージだった。「これは面倒くさいだろう」と思って、自分で新しいものを作ったんですね。
そもそもどういうものかというと、(これは)XMLを扱うんですけど、XMLを扱うにはlibxml2という標準的なCで書かれたライブラリがあって、それをラップするかたちでこのEzXML.jlもLightXML.jlもできてるんです。なんですが、Cのラップはちょっと難しい部分があるんです。
とくに、XMLは木構造になってるので、非構造のあるノードとあるノードをJuliaでラップしたときに、関係があるのに片方を勝手にGCが回収してしまったりすると、すごくメモリのエラーが起きたりします。
単純に、例えばJuliaのGCをするときに、勝手にCのほうの構造体も一緒に解放するようにすると、まだ使うXMLの木の部分が、勝手にJuliaのGCと一緒に消えちゃったりして、メモリがグチャグチャになってしまったりします。
こういう感じでけっこう難しいんですけど、(EzXML.jlでは)そのへんをがんばって解決しました。このへん、すごく話せるので、興味がある方は後で聞きに来てください。
あと、メモリ管理以外にも、XMLには名前空間という概念があって、(LightXML.jlは)それもサポートしていなかった。XPathもサポートしてなかった。巨大なXMLファイルを読むときに、一気にメモリに読んでしまうからストリーム処理をしたいけど、ストリーム処理もサポートしてなかった。あと、なんかインターフェースが変だった。
もうたくさん不満があって、これを騙し騙し使うよりは、自分で新しいものを作ったほうがいいだろうということで、EzXML.jlというパッケージを作りました。
特徴としては、先ほどいくつか挙げた問題を全部解決するように作っていて、「霊長類のための簡単なXMLとかHTMLを処理するためのパッケージ」というコンセプトになっています。
XMLやHTMLを読み込んだり、トラバース、木構造になってるんで、それを、木構造、あっちこっち、DOMインターフェースでいったり。XPathを使って要素を検索したり、名前空間(namespace)をちゃんと扱ってくれたり、エラーメッセージがそのへんにピョーンと出ないで、うまいことJuliaのI/Oのシステムにいれたり。
あとは、メモリマネジメントを勝手にやってくれる。ここが一番大変でした。他にもドキュメントのバリデーションをしてくれたり、大きなXMLを一気にメモリに読まないで、段階的に読む、ストリーミングパーシングができるようにしています。
インターフェースを簡単に比較してみると(スライドを指して)こんな感じです。
ほぼ同じことをやってるんですが、(EzXML.jl では)using EzXMLをして、ex1.xmlというファイルがあったら、それをreadxmlという関数で読み込みます。これは一気にメモリに読み込む、ドキュメントとして読み込む感じですね。
LightXML.jlだと、parse_fileっていう、何をするのかよくわからない関数名になっていたので「ちょっとこれは……」と思って、readxmlというわかりやすい名前にしています。
(EzXML.jlでは)そのドキュメントを取ってきたら、XMLでルートノードを取ってくるんですけど、そのときに.rootと書けるようにしています。こっち(LightXML.jl)ではrootという関数を使わないといけないので、このrootっていう変数名を使えなくて、xrootとか、適当な名前を付けなきゃいけない。
(EzXML.jlでは)rootの以下にあるノードを上から順に観察するとき、eachnodeっていう関数を使って、ルートノードからイテレータを使って1個ずつ子供のノードを取り出せるようにしています。こっち(LightXML.jl)はchild_nodeとなっていて、なぜかアンダーバーが入ってたりして、インターフェースがちょっとイケてない。
あと、EzXML.jlでは、タイプを取ったり名前を取ったりするとき、Juliaっぽく書けるようになっています。LightXML.jlだと、XMLElementというものにいったん変換しないとXMLの要素が使えないんですが、そういったことがないようになっています。
こういうふうにインターフェースを向上させて、豊富な機能も備えています。
先ほども言いましたけど、自動のメモリ管理、これは本当に重要です。加えて、名前空間、XPath、ストリーミング処理もサポートしています。
これ、どういうところに必要かっていうと、バイオ系のデータファイルで、Gene Ontologyとか、もし知ってる人がいたらわかると思うんですけど、非常に巨大なバイオ系のターム、専門用語を、Ontologyというデータ構造みたいなものでまとめて扱えるというものがあるんです。そのデータファイルが非常に巨大で。
名前空間を使っていて、XPathも必要で、ストリーミング処理も必要でという、すべての機能を使わないとうまくパースできないという事情があったんですが、EzXML.jlでは解決して使えるようになりました。このへんをラップして、別のバイオ系のパッケージを作ってたりします。
もう1つ、TranscodingStreams.jlを紹介します。これもJuliaのパッケージで、そもそも「gzipをいい感じに扱いたかった」というモチベーションでした。
gzipはみなさん、ふだんファイル圧縮形式としてデフォルトで使われてると思います。これ(を扱うパッケージ)はもちろん私が作る前からあって、そのままの名前のGzip.jlというものと、あとは、gzipを扱うときはlibzというライブラリを使うのが標準的なので、それをラップしたLibz.jlというものがありました。
実は私、Libz.jlの開発にも関わってるんですけど、私がデザインしたものではないので、ちょっと不満があったんですね。
Gzip.jlは非常に遅い。Cのライブラリでligzのライブラリを呼んでるんですが、インターフェースのラップの仕方があんまり効率的じゃない。ストリーム処理がうまくできないような構造になっていて、処理が何十倍も遅かったりしたんです。
それを解決するために、別の人がLigz.jlを作ったんですが、これは確かに速いんですけど、デザイン的にちょっと拡張しにくくて、gzip以外には基本的に使いづらいデザインになっています。
そこで、gzip以外にもいろいろな圧縮解凍フォーマットを同じインターフェースで扱えるように新しく作ったのが、このTranscodingStreams.jlです。
例えば、Facebookのzstdという圧縮解凍方式が去年あたりに出てきて、gzipより高速で高圧縮っていう、完全にgzipの上位互換みたいな、すごくいい圧縮解凍形式、ライブラリがあります。
他には、標準的に使われているxz、昔はlzmaとか呼ばれてましたけど、あとはbzip2、これはたぶん最近は使う方もかなり少なくなったと思いますが、こういう他の形式もあるということで、これらを全部一緒くたに使えるようにするのがTranscodingStreams.jlです。
特徴としては、このTranscodingStreams.jlというパッケージのなかに、TranscodingStreamという型が1個だけ定義されています。これがメインの型になっていて、JuliaのIOという抽象型の、継承ではないですけど、下位の型です。
このTranscodingStreamは、2つ、型パラメータを取ります。1つがCで書かれているdata transforming codecで、データを変換するための型です。もう1つが(スライドを指して)ここでSと書かれているラップされる型ですね。
これは何をしてるかというと、Sという、もともとあるIOのオブジェクトを、データ変換をかませて、さらにIOにする。IOをCodecで変換して、またIOにするということをしているような内容になります。
謳い文句としては、オーバーヘッドをできるだけ減らすために、バッファリングとか、いろいろなスペシャライズドなソフトを定義しています。あとは、インターフェースが非常にconsistentで、普通のIOが使える人だったら、これも簡単に使えます。
(スライドに)Genericと書いてあるのは、例えばファイルを扱うとか、インメモリでバッファを扱うとか、パイプを扱うとか、いろいろなIOが全部統一的に扱えるということになってますね。これでパラメータ化されている。
あとはextensibleで、これが重要なんですが、このCodecという部分を取り替えるだけで、例えばgzipだったり、zstd、xz、lzma、bzip2、いろんなデータ変換の方式をここに埋め込むことで、データの変換を行えるようになっています。
このファミリーにはいくつかこれに依存してるパッケージがあって、先ほど言ったように、全部Codec、zlibとか、zstdとかがあります。
全部Codecというプレミックスで始まるパッケージで、このへんを開発しています。例えばbase64とかも扱えますね。
あとは、私が作ったものではないですが、lz4という、圧縮率は劣るけど高速な圧縮解凍形式を、Inveniaというカナダの会社が作ってくれたりしています。同じインターフェースを継承してファミリーに加わってくれたということですね。
こんな感じで、新しい形式のサポートが非常に簡単なので、外部の人でもCodecを1個定義すれば、簡単にそれがIOとして使えるようになると思います。実装すべき型、さっき言ったCodecと、メソッドをいくつか定義するだけなので、非常に簡単です。
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10