ポッドキャストの概要
Yoshiori Shoji
はい、というわけで、タメ口fm、半年ぶり?もうちょっとぶりか。
draftcode
え、半年ぶりなんだ。
Yoshiori Shoji
いや、結構空いてるよね。前回西尾さんゲストに呼んで話して以来、AIで話したぐらい。
draftcode
まあ、毎回ね、最終回って言いながらやってるから。
Yoshiori Shoji
そうそう。ついついね、長くなってしまいますが、これは、俺とDraftcodeがタメ口で、
お題の技術について適当なことを言って、ダブルだけのポッドキャストです。
draftcode
いつも通り。
Yoshiori Shoji
いつも通り。今回のお題が、設定記述言語。設定記述言語って言葉で正しいのか、これ。
draftcode
まあ、でも意味はわかるよね。
Yoshiori Shoji
意味はわかる。アプリケーションの設定とかを書いておくための、要はconfファイルとか言われてるやつだよね。
の言語について今日話そうっていう、だいぶマニアックなネタを持ってきたよね。
draftcode
そうね。まあでもみんな、コンフィグは通る道だもんね。
設定ファイルの歴史
Yoshiori Shoji
そう、通る道だし、1回か2回、なんだよこのクソconfファイル、書きにくいなーって絶対思ってるよね。
draftcode
特にね、その独自言語を使ってるところは、これ、どこにこれ書けばいいんだろうって。
例えばさ、エンジンXのさ、エンジンXconfファイル。
この行って、ここのサーバーの中に書いていいのか、なんかこのHTTPの中に書いていいのか。
こう、これどこに書いていいんだろうなーみたいな感じで。
で、リファレンスいてさ、リファレンスいてもたぶんここなんだろうみたいな感じで、探しにくいもんね。
Yoshiori Shoji
エンジンXの話でだから言うと、たぶんなんかそれで言うと、俺の原体験はやっぱりApache Confだよね。
Apache Confがクソ過ぎてめっちゃ書きにくかった。
draftcode
ここ、たぶんジェネレーションギャップがあって、自分あんまりApache使ったことないっていう。
Yoshiori Shoji
そうだよね、そうそうそう。
draftcode
でもさ、あれだよね、ちょっとカトキみたいな感じでさ、
Apacheがあって、ITTPみたいなのもあったし、
だからたぶんそのPaaSのFastCGIとかああいうところの世代からだんだんこう、
なんかCGIとかFastCGIとかじゃなくて、アプリケーションがネイティブにこう、
プロセスHTTPを放して、その前にリバースプロキシーとして、
なんか浮くよねっていう時代にシフトする過程のところで、
こう、いくつか候補があったけど、今はなんかみんなエンジンXになってしまったねっていう。
そうでもないのか、わかんないけど。
Yoshiori Shoji
そう、でもApacheでもほらJavaの時はさ、そもそもModoJKとかがあってさ、
Javaのサーブレットとそれで通信みたいな感じだったから、
まあまあ、まあなんかこれなんか別の話になってきたな。
ウェブサーバーとアプリケーションサーバーの通信みたいな話になったけど、そう。
まあなんでそのApacheのCONFファイルの設定がめんどくさかったのと、
まああとはあれだよね、よくみんな書いてるだろうがSSHCONFとか、
あとはローカルにあるGitのCONFか、とかまあ、はあるよね。
で、たぶんあれだよね、またいつも通り歴史的な経緯の話をするとさ、
たぶんその独自的な設定ファイルがあって、
その後またされた技術であるXMLの時代が来て、
で、XMLはやっぱり人が書くものではないみたいになって、
YAMLになったりJSONになったりみたいな雑な流れがありつつ、
まああとはDSL的に言語で書くみたいなのもずっと独自で進化してきたみたいなのが、
CONFの歴史かなみたいな気がしてる。
draftcode
そう思うとなんかちょっと、なんか感覚としてXMLの時代とさ、
そのYAMLとかJSONの時代ってなんかちょっとギャップがありそうな気はしなくもないけど、
なんか間にあったっけ?
Yoshiori Shoji
XMLがやっぱ辛くてYAMLが出たんじゃない?って俺の中ではイメージがあるんだよね。
draftcode
なんかそうか。自分の、そうね、そうかもね、確かに。そんな気もする。
YAML、今の人にこう、今の人って誰を指すのか分かんないけど、
今の人にYAMLどうよって聞くと多分YAML、
YAMLかーってなんかちょっと、YAMLってやっぱりなんか一定数このちょっと、
嫌い、嫌い、YAML嫌い勢なんかいない?
Yoshiori Shoji
YAML嫌い勢いるけれども、それが若者なのかどうかは分からない。
若者はもう受け入れてるかもしれない。
draftcode
若者とは限ってないけど、やっぱり。
Yoshiori Shoji
限らないけど、YAML、YAMLうーん勢がいるのは分かるし、
俺も若干設定ファイルYAMLって言われると、
んー、YAML以外考えてみない?って思うから。
draftcode
分かる、分かる。
いや、これさ、分かんない。老化なのか分かんないけどさ、
インデントが見えねえんだよ。
Yoshiori Shoji
見えるだろ。
draftcode
インデント分かんないって、あのね、
いや、Pythonいつも書いてるんだけど、
Pythonはまだいいんだけど、なんか、
YAMLはね、長くなるし、
Yoshiori Shoji
深くなると分かんないよね。
draftcode
そう。こことここ一致してんのかなーみたいなとこはさ、
あとさ、あの、YAMLのインデントさ、なんか、
あの、リストと、その、なんか、
デッキ処理のなんか要素みたいなやつでさ、
ここインデントしてもしなくてもいいんだけど、
はいはいはい。
人によってここインデントしたりしなかったりするみたいな感じの、
JSONとその関連技術
draftcode
なんか統一感の無さみたいなのがね、こうあって。
ま、あと、よくハマりがちなのが、
数字とかの塊だよね。
Yoshiori Shoji
そう、それはね、めちゃめちゃあって、
その、面白いのがさ、前職の時、
その、Cookpadの時に、
その、アプリケーション管理するYAML、
壮大なYAMLファイルみたいなのがあったのよ。
全Cookpadで動いてるWebアプリケーションを管理するみたいな。
で、そこにアプリケーション名も書くんだけども、
俺が、なんかのアプリケーション、
数字だけの名前のアプリケーションを作ったのよ。
42っていう名前のアプリケーションを作って。
で、基本的に文字列だから42でいいんだけれども、
YAMLで書くときって、こうダブルコードでくくんないと、
数字扱いになるじゃん。
だから、毎回そこでキャストエラーが出るみたいなのが、
いろんなプログラムで発生してて、
あの、共通の友達であるEagleに、
いや、よしよしさんの42はもうマジであれっすね。
いろいろなテストになってくれて、
いいですねって、
若干うぜえなこのアプリ名みたいな感じで、
言われたことがあって。
まあ、っていう話があって、
YAML、もうちょっと細かくすると何かっていうと、
YAMLって文字列を別にダブルコードとかで
くくる必要はないんだよね。
で、書けるせいで、
文字列で書くべきところに数字だけ、
例えば今で言うと42とかを書いておくと、
他は文字列で書いてあるのに、
そこだけ42ってなると、
だいたいのパーサーが、
数字だけの文字列はキャストしてくれて、
インテージャーとかに変えようとするので、
そこでプログラム内で型の不正語が出る、
みたいなのが、
よく発生する。
YAMLの罠みたいな感じだよね。
draftcode
あの、あと、
イニシエのYAMLスペックって、
その、イエスとノーみたいなのが、
ツリーとフォルスに乗るみたいなスペックなかったっけ?
そういうね、
使わないといえば使わないけれど、
ちょっとYAMLね。
Yoshiori Shoji
YAMLってあれだよね、
パール界隈のインギー、
インギードットネット、
今名前変えたのかな、インギー。
インギーが確か、
最初作ったんだよね。
ああ、そうなんだ。
draftcode
ちょっとね、YAMLも。
まあでもYAMLね、
どっかしらで触らないといけない言語になってしまったから、
XMLはさ、
もうなんか、今、
Yoshiori Shoji
触らなくていいじゃん。
draftcode
何があっても。
YAMLまだね、触らないといけないんでね。
Yoshiori Shoji
まずだってGitのコンフYAMLだよね、まだ。
draftcode
え、Gitのコンフ?
Yoshiori Shoji
コンフはiniファイルだよ。
あ、iniファイルか。
draftcode
あ、iniファイルといえば
トムルがやっぱり
伸びてるよね。
Yoshiori Shoji
そうだね。
今何がいいって言われたら、
俺は若干トムル押すかなぐらいの感じはする。
俺も。
draftcode
結構タイプによるかな。
トムルもトムルで、
まあそうね。
トムルよりマシかな。
Yoshiori Shoji
YAMLよりベタ、ベタYAMLだよね。
draftcode
そう。YAMLかトムルかって言われたら、
Yoshiori Shoji
まあトムルでいいかなっていう感じは確かにする。
なんか一方でこう、
JSONあるじゃん。
JSONを
設定ファイルに使うみたいなの
一瞬あったよね。
draftcode
まあJSONの
悪いところは、
あのー、
コメントが書けないとか、
血管の問題がいまだにあるとか、
そういうところで。
で、それを解決するために
JSON-CとかJSON-5とかが
定義されたはいいけれども、
まあ割と
コメントぐらいは
割とサポートするから。
Yoshiori Shoji
あれさ、JSON-Cっていうの
言葉で言うと、
俺はずっとJSONICだと思ってた。
draftcode
あ、そうなの?アイ入る?
Yoshiori Shoji
アイ入るんじゃなかったっけ?
draftcode
ずっとJSON-Cだと思ってた。
なんかパーサーとかJSON-Cって書いてあるし。
JSONICってある?
Yoshiori Shoji
JSONIC、そう
JSONICってあるよね。
シンプルJSONX
デコーダー
withinJava
あ、違う。これはJSONICか
Javaのライブラリーか。ごめん、俺勘違いしてたわ。
draftcode
JSONIC
今調べたらJavaScriptの
なんかJSONパーサーも
あるけど、
でもこれ、そうね。
JSONICって違うけどJSON-Cな気がする。
JSON-Cか。
Yoshiori Shoji
JSON with commentって言われるやつね。
draftcode
が、
JSON、ほら、例えばさ、
VS Codeの設定がJSONじゃなかったっけ?
JSON-Cか。
そうだね、そうだね。
まだ人間が書ける。
人間が書けるけど、
物によってはJSON-Cじゃなくて、
生JSONとして
読んでいるので、
あ、こいつコメント書けねえなとか
そういう感じになりますね。
Yoshiori Shoji
そうね。
あれ、あれ何だっけ?
Googleの
一瞬Kubeの設定ファイルとかで
使われそうになったのもJSON-Cだっけ?
draftcode
そんな時代あったの?
Yoshiori Shoji
なんか。
なんかあったんだよ、JSON系のやつ。
へえ。
そうそうそう。
draftcode
一応Google製と言われているのが
JSONnet。
Yoshiori Shoji
あ、JSONnetか。
うん。
draftcode
これだ。
Yoshiori Shoji
あれは
draftcode
そうね、あのー
そうね、JSONnetってやつ。
Yoshiori Shoji
そう、JSONnetだ。
俺今JSONnetと勘違いしてた。
draftcode
あれもちょっと高級なやつだね。
Yoshiori Shoji
高級なやつ。
draftcode
色々できるよね。
Yoshiori Shoji
でもね、実はあれ使ったことないんだよな。
draftcode
あ、そうなんだ。
Yoshiori Shoji
俺は一時期ちょっと使ってたなー
というのも
やっぱりYAMLにやけがさせた時
みんな一時期その
JSONnetに行くっていうのが
ぶっちゃけで言うと
クァットでイーグルがやり始めたので
俺も真似しようと思ってやって
色んな個人アプリをJSONnetで
設定をかけるようにしたんだけど
まあなんか
うーん
つらいね。
JSON設定ファイルにする時って
XMLを設定ファイルにしていた時と
ちょっと似た感覚が
俺の中であって
どういう感覚かっていうと
人間が読めると
人間が書けるはやっぱ別に
考えなきゃいけないなっていう
思いがあって
XMLもJSONも人間余裕で
draftcode
読めるのよ。
Yoshiori Shoji
でも人間に書けって言われた瞬間に
急に大変になるんだよね。
なんかさ
このインデントと
この括弧の整合性が
ちゃんと整ってないとか
フォーマッター通しても
うまくフォーマットされないから
括弧がどっか足んねえんだなどこだどこだ
みたいなの探したりとかさ
そういう意味で
人間が読める
ヒューマンリーダブル
ヒューマンライダブルみたいな話よくするけどさ
読めるけど書きにくいわ
絶対に存在すると思っていて
で、XMLとJSONは
俺の中ではその筆頭なのよ
読めるんだけど書ける
で、YAMLやTOMLに関しては
設定記述言語の課題
Yoshiori Shoji
まあまあ書くのも
そこまで大変じゃないね
っていう感覚
draftcode
なるほどね
まあ
なんで大変になるんだろうって
ちょっと思うんだけども
言われてみると
その
設定
XMLもそうだし
JSONもそうだしYAMLもそうなんだけど
なんか設定言語のスキーマみたいなものを
考えるときに
結構ネストしがちだな
っていう感じの
極力フラットにしてくれればさ
まあちょっとダサいけどさ
あ、そんなに
括弧の対応とかインデントがこのこの
っていう風に思わないんだけどさ
なんか、あ、構造化された
コンフィギュネーションが書けるぞっていう風になると
なんか人間ちょっと色々
構造化してくれるし
ここの部分はこのグループなんだからこういう風に
グループ分けしてあげればいいし
ここはこういうオブジェクトでこういう風に内部で渡したい
こういう風にグループ分けしてほしいし
みたいな感じで
思っちゃってなんかめちゃくちゃこう
ネストしてこう
あ、構造化されてる美しいみたいな感じに
スキーマを設定した段階ではなんか
これすごい綺麗に
届くんやんっていう風に思うんだけれども
実際書いてみるとなんかめちゃくちゃ
インデントしててなんか
書きに行きんだよなーしかもなんかこの
ネストしてるとさ
これも
あれだと思うんだけど
マージしたいみたいな要求があるじゃん
これでその上でこれをマージして
っていう風になった時に
ネストしていくとどんどんどんどん
ここオーバーライドしてくるんだけど
あれじゃんでもあれの中にまたさらに
こう構造体みたいなのがあるから
はいはいはいはい
どうやってマージしろーみたいな感じの
こういう場合によっては
なんかユニークキーみたいなのが
あってみたいな感じで思っちゃって
ちょっとね大変なんでね
Yoshiori Shoji
そうね
構造化で今の話で
なんかネストでインデント化
みたいな話あったけどさ
構造なんだろ
データとしては構造化にされてるんだけれども
書き方としてはフラットになる
プロパティファイル
draftcode
っていうやつがあるじゃん
でもプロパティファイルは
Yoshiori Shoji
あれ一応ドットで繋げてほら
構造化にはなってるじゃん内部的には
draftcode
それ言ったらだってトムリもそうじゃん
Yoshiori Shoji
まあそうだね
draftcode
まあ似たような
感じだけども
プロパティファイルはね
ジャパンの
ジャパン海外の人でも
プロパティファイル使ってないからね
Yoshiori Shoji
今使ってる人いないよね
draftcode
あの形式なんか書くのって
JVMのなんかこう
微妙な設定とかはそういう
書くような気がしたくもないけど
Yoshiori Shoji
まあそんなもんだよね
今話を聞いてて面白いなと思ったの
構造化を表してはいるけれども
Terraformでの設定
Yoshiori Shoji
インデントを使ってない構造化の表し方だなと思ってて
書き方としては
フロットだなと思ってて
draftcode
そうね
やっぱりこれローガン問題で
インデントが見えないとか
書き方が見えないとかさ
プログラムだったらさ
いくらネストしててもさ
4つ5つぐらいかもしんないけどさ
これがなんかどんどんどんどん深くなってて
クバネクティスのデプロイメントの
この定義
スペックの中でテンプレートがあって
どんどんどんどん
ネストしていって
やや感じになるもんね
そうね
たぶんそこら辺がXMLも大変だし
ASOも大変だし
大変
自分はね
リアクトのこの
TSXのあれを書くときでも
なんかこうやって
ここが対応しないなって
どこで対応しないんだろうって思っちゃうもんね
そうそう
そうそう
どこで失敗してんだろうなって
まあ
YAML
JSON
そこからもっと
違う
あんまり使われてるとは言い難い
よく使われてるんだけど
テラフォームのHTL
Yoshiori Shoji
そうね
テラフォームでしか使われてないから
よく使われてるって言っていいのか
draftcode
テラフォームがよく使われてるから
Yoshiori Shoji
使われてるんだよ
そうそうそうそう
これはなんか一気に重厚な気分になるよね
draftcode
まあ
Yoshiori Shoji
そもそもテラフォーム自体がね
draftcode
まあそうだね
そういうイメージがつくっていうのもあるんだけど
あの
テラフォームのさコンフィル書いてるときさ
これもさっきのYAMLの
数字文字列問題と一緒なんだけど
ハイフンアンダースコア
問題っていうかさ
普通のプログラミング言語で書いてると
ハイフンってアイデンティファイリアには絶対なり得ない
その
引き算になっちゃうから
なんだけどテラフォームのコンフィグ世界だけは
なんかハイフンがアイデンティファイアの一部になっていて
こう
書いてて
まず書いてて
これどっちにするんだっけって
いつも迷って
アンダースコアだっけ
ハイフンにするんだっけ
あとテラフォームの
このコンフィグ
なんかループとかあるじゃん
あれがなんか
いいなっていう感じで
Yoshiori Shoji
いつもね
変数を持ってったりとか
継承はしないか
持ってくぐらいか
draftcode
でも継承というか
コンフィグの継承もね
結構したい
Yoshiori Shoji
欲求があるよね
したいこともあるさっきの構造化と
最初にYAMLのところで話した型の問題
とかさ
こうなんか
設定ファイルにいろんなものを持ち込めば
持ち込むほど
おかしくなるじゃん
設定ファイルにロジックを書いてはいけません
みたいなのさ
3週ぐらいしてるじゃん
draftcode
でもね
Yoshiori Shoji
なるんだよ
draftcode
わかるよ
なんかね
まず
環境ごとに変えたいっていうのが
出てくるわけよ普通に
でもさ
最初は環境変数だ
環境変数に
これこれ
ベストプラクティスよみたいな感じで
格好してるんだけど
Yoshiori Shoji
ファクトワークスも
draftcode
言ってるし
これが普通よね
みんなそうやってるよ
ってやるんだけど
そうするとまず
プロダクションとステージングと
デブ環境で
違うからとりあえずMRCみたいなの
入れとくかって言って
変えるじゃん
その時は環境変数だしって言って
環境ごとに変えるだけよって
言ってるんだけどここで実は継承が入ってる
Yoshiori Shoji
そうだね
draftcode
一番ベースのMRCと
MRC
プロダクションみたいなのが入ってる
だんだんそれが増えていって
片付けていいなとか
環境変数
たくさん増えていくと
ドキュメンテーションがないと
コメントをちゃんと書いておきたい
この環境変数は
Trueの時はこういう動きをして
Falseの時はこういう動きをして
入ってないと
こうなりますみたいな感じになったりとか
するんだよね
そういうドキュメンテーション書きたいとか
あとあれだね
引っかかりがちなのが
テストよ
Yoshiori Shoji
テストね
draftcode
環境変数ね
また悪いのが
この環境変数があるって
普通はあるよね
普通はあると思って
テストを書いて
コードを書くんだけど
そのコードを
例えばそのクラスを
呼び出す
別のクラスのテストを
書こうと思った時に
あんに環境変数に依存してるから
そのクラスを使うクラスの
テストでも環境変数を
書かないといけないみたいな感じ
パッチしないといけないみたいな感じになってきて
これ実はグローバル変数では
みたいなことにちょっと気づくんだよね
あとの熱いなんだけど
そんなことをやってるとね
だんだん
いやこれ環境変数
実はもう使わないほうがいいんじゃないかって
JSONとかになっていったり
するみたいな経緯がありますね
Yoshiori Shoji
JSONに書くかMRCに書くかの
環境変数と設定ファイル
Yoshiori Shoji
違いみたいになっちゃうからね結局ね
うん
書くファイルが違うだけじゃんみたいな
draftcode
ただJSONとかだと
例えばその
JSONのファイルを読んで
何かのオブジェクトにして
何か待たすみたいなことも
できるっちゃできるから
そのオブジェクトごとを
テスト時には
足しって入れて
テストするってこともできるっていう意味では
Yoshiori Shoji
多少
draftcode
多少楽と言えば多少楽
だけども
今度JSON
MRCとか
そうだけど
ここの値に依存してこの値は
フォーマットしたいみたいな感じのやつとか
例えばなんだろうな
URLみたいなやつを
これステージング環境だったら
環境名ダッシュ何とか
インターナル何とか何とか
みたいな感じのやつが
サービスの次の
エンドポイントだから
環境のやつが変わったら
そこは全部一発で変わるようにしたい
みたいな
横着具合が出てくると
だんだんロジックが書かれるようになっていって
大変なことになっていくわけですね
Yoshiori Shoji
それで言うと結局やりたいことって
外部で記述したものを
プログラム内で
ディクショナリー的な形式で
キーバリューでアクセスしたいっていうだけなんだよね
結局この設定記述言語で
やりたいことって何かっていうと
プログラム内で扱える文字列を
外から取りたい
っていう話だよね
キーバリューっていうことは
若干
なんていうんだろう
外に書ければいい
っていう話なんだけれども
マーシャルとか
シリアライゼーションとかとも
若干似てるのかなっていう気がしてて
プログラムの外から持ってきた値を読んで
キーバリューみたいな
フェアにしたいみたいな
draftcode
それはそうで
例えば
記述する言語として
JSONCなり
HTMLなり
JUSTなりがあるんだけど
そういうのがリッチな言語で
そのリッチな言語が
コンパイル
設定ファイルをコンパイルすることで
例えば生JSONとして
読めるように
コンパイルされるみたいな
形になると思うんだよね
コンパイルされたものを
今度アプリケーションに
読み込んでもらって
アプリケーションレイヤーの
何なりオブジェクトにするなり
JSONにしなくてもいい
JSONであっても
本当にフラットなキーバリューの
だけだったら
キーは環境変数の名前で
バリューは環境変数の値
という風にして
アプリケーションを起動するようにするみたいな
形でもいいんだけど
シリアライゼーションの形式としてはJSONファイルで
環境変数のキーバリューペアでも
いいんだけど
それをアプリケーションに読み込む
だから例えば
HTMLとかテラフォームの
コンフィグファイルっていう
コンフィグ言語みたいな
最終的にそれをコンパイルして
別物にするであれば
その部分はアプリケーションから
アプリケーション自体が
HTMLのプロセッサーを
持ってなくても別にいいという
Yoshiori Shoji
話ではあって
draftcode
そうね
それ言ったら別にJSONで書いてても
それをHTMLに変換することは
可能ではあるからさ
Yoshiori Shoji
そうそうそう
ってなるんだけども
結局大事なのは標準ライブラリが
対応しているかどうかを
みんな気にするのかな
若干あって
わざわざ追加でライブラリを入れないと
設定ファイルが読めませんわめんどくさいので
さっき言った
JSONで書いたのもHTMLに
コンパイルされますってなるけれども
そのコンパイルするものが
ライブラリ化されててわざわざインストールしなきゃいけない
ってなるとやっぱ手間が1個増えるから
言語標準で
パーサーが入っているもので書きたがる
っていうのは
理解はできる
draftcode
入れたくないもんね
入れたくない
設定記述言語の比較
draftcode
えーマジでこのデペンデンシー入るの
みたいな
プロダクションに入らなければいいかな
っていう気持ちはなくはないけれども
まぁでもちょっとね
極力デフォルトで
できるんだとデフォルトやってほしいよね
Yoshiori Shoji
っていう思いがあり
なんで結構
なんでまぁLL系の言語だと
JSONとYAMLは結構
標準で読めることが多いから
まぁだからいまだに使われることが
多いのかなあとXML昔はね
そうXML一瞬だけ
世界を統一したので
XMLはだいたいどの言語もね読めるようになってたり
とかするから
draftcode
でもさぁXMLのパーサーさぁ
なんだろう
現代基準からするとうっていう風にならない?
Yoshiori Shoji
使う時にさぁ
しかもSAXとかでSAXのパーサーです
draftcode
とか言われると
えーマジで
Yoshiori Shoji
なんかさ
普通の人が
設定ファイルのパーサーで
イメージするのってそこにファイルを渡すと
ハッシュマップ的なのが返ってくるの
こう脳内で想像してるから
SAXのパーサーですって言われると
なんか俺めちゃ
ゴリゴリ書かなきゃいけないんだけどみたいに
なるよね
draftcode
XMLって
あれだけど
それで言うと
PythonってPythonの
公式でなんかいろんな
エコシステムがあるんだよね
Pythonのエコシステム
公式エコシステムみたいなのがあるんだけど
その一つがpyproject.tomlっていうファイルを使って
なんか色々設定を書く
昔はsetup.pyだったのが
今はpyproject.tomlになったんだけど
それを
なぜtomlを使ったかっていう
その経緯を
PythonのPEPっていうのがあるんで
そのPEPで書いていて
検証してるんだけど
yaml
もちろんyamlとかjsonとか色々
検証していて
星取り表があってね
この機能はこの設定ファイル言語には
あるからみたいな感じで
Yoshiori Shoji
その518
draftcode
518
っていうのがあるんだけども
yamlを
採用しなかった理由が
yamlパーサーって結構
思ったよりも大きくて
そのpyamlっていうのが
メジャーライブラリなんだけど
これをさすがに公式でインクルーするのは
厳しいっていう感じの
話になってしまったので
まぁちょっと
yamlではダメ
っていう感じになり
tomlはね基本なんかiniファイルの
拡張みたいな感じのノリなんで
もともとiniパーサーは
configパーサーか
っていうのが
Pythonの標準ライブラリにあったし
厳しいっていう感じになった
Yoshiori Shoji
ぽいね
俺知らなくてさドラフトコードが
この
このミーティングを
このpodcastやるよってメモのとこに書いてくれて
初めて知ったんだけどもさ
面白いのが
yamlとtomlの違いまさにそこなんだよね
yamlって実はめちゃめちゃ
エッチケースが大量にあって
それに対応し始めるとすげーでかくなるから
TOMLの利用と背景
Yoshiori Shoji
だから
そこが大変なんだよねっていう話が
書いてあってその
さっき言った星取り表みたいなとこでさ
yesか空欄
みたいになってるのに
yamlだけクエスチョンクエスチョンクエスチョンみたいなのがあって
何かっていうと
ここは人類が多分把握全部はできていなくて
みたいな
言語によってyamlのパーサーによって
読めるものと読めないものがあったりとか
解釈が違うものがあったりとかする
みたいな
のがあってカオスすぎるみたいなことが書いてあって
tomlはなんか300以下
300以下のラインでパーサーが書けている
しかもpure pythonでみたいな
のが書いてあったので
なるほどなーって思って
シンプルにして
使用シンプルにしてちゃんとHKSまで全部決めてあったっていうのは
まあでかいところなんだろうなっていう気もする
draftcode
そうだね
まああと
早いしね小さいと早いっていうのもあると思うんだけど
Yoshiori Shoji
小さいと早いはめちゃめちゃあると思うし
draftcode
まあ
速さなんてそんなに気にすることないだろうって
思ってたんだけども
個人的に作ってるアプリで
設定ファイルをたくさん書きたいみたいなことがあって
まあその時選んだのが
json5
だったんだけども
json5ってまあjson
っぽいんだけれども
まあコメントも書けるし
まあ月刊版問題もないしっていう感じの
いい感じの言語じゃんっていう風に
思ってたんだけれども
割とあんま実装がこなれてないのか
わかんないけどパーサーがめちゃくちゃ
めちゃくちゃ遅くて
読むのに
コンフィグタイムもちょっとでかいっていうのもあるのかもしれないけども
なんか結構読むのに
時間かかるなっていう感じの感触が
Yoshiori Shoji
あったから
draftcode
両タイムでかかるってこと?
結構まあ読んでいくと
そうだねなんかそれぐらいかかってる
Yoshiori Shoji
それはすごいね
draftcode
やっぱjsonその生json
本当にベースのjsonってすごく
最適化されてるから
すんごい早い実装が世の中にあるんだけども
json5はたぶん
まだ
仕様に対してコレクトであるっていうことを
保証するために
そんなになんか最適化されてる
そのパーサーが
世の中に出てないような感じがするのかな
っていう風な印象を持ってるね
Yoshiori Shoji
確かに
draftcode
そうなんだ
Yoshiori Shoji
たぶん1ファイルのね
draftcode
大きくとかあるけど
ぐらいだったら別にいいんだけども
例えば機械的に測れたデータをjson
書かれてねっていう風になると
ちょっと
小手伝いかもしれないっていう風な印象があるね
FUDなんですけど
Yoshiori Shoji
いやまあでもさ
さっきも言ったけども
人間のhuman readableとhuman writeableは違うみたいな話でさ
その機械が書き出したやつは
人間が読めればいいので
なんか
それは設定記述言語とは別で
考えた方がいいんじゃねえかなっていう気がしてるのよ
その
シリアライゼーションデシリアライゼーション
側で考えた方がいいんじゃないっていう気が
若干していて
draftcode
そうなんだけどね
事情がいろいろあったりするもので
例えばさ
基本human writeableというか
人間が書く
ファイルと思ってるんだけど
たまにこれ機械で
機械的にこう
変えたいみたいな需要があるよね
なんかのデータのマイグレーションしたい
設定ファイルのマイグレーションしたい
CLIとか作っててね
CLIの設定ファイルはこれYAMLです
でも
新しいやつになったんで
CLI新しいバージョン入れたら勝手に
このコンフィギュレーション読み込んで書き換えて
新しい
コンフィギュレーションにしましょう
YAMLなんだけど
キーの名前が変わりますみたいな
そういうのあるじゃん
ってなった時に
コメントとかを維持しながら
書き出すっていう
パーサーって別で書かないといけなかった
Yoshiori Shoji
別で書かないといけないね
draftcode
コメント維持するのは
なので
そういう
やっぱり機械で読み込むだけじゃなくて
機械で書きたいって言った時に
人間が読める
ものを
人間が読める形で書く
またちょっと別のテクノロジーが必要で
これもまたちょっと大変なんですよね
Yoshiori Shoji
確かにデシリアライズとは別だよね
draftcode
講義のデシリアライズ
デシリアライズではあるんだけど
Yoshiori Shoji
でもコメントとかも維持しておかなきゃいけない
とか
draftcode
様々な需要があるんで
様々な
大統一
どうなんだろうね大統一
Yoshiori Shoji
でも例えばちょっと前は
大統一大体YAMLだったと思うのよ
大体の
世界の大体の設定はYAMLだったのが
最近トムルに結構動いてるな
と思っていて
Pythonの俺は知らなかったんだけど
俺が使ってるアラクリティ
ターミナルエミュレーターは
設定ファイルがYAMLからトムルに変わったんだよね
draftcode
変わった変わった
Yoshiori Shoji
だから結構
今世の中的にも
トムル推しになってきているのかな
っていう気がしていて
最初に言ったように
トムル嫌いじゃないし
今ならトムル使うかなぐらいの感覚でいるので
これが標準になってくれて
全ライブラ、全言語が標準で
トムル読めるようになってくれたら
ちょっと幸せにはなるのかな
っていう気がするんだけど
型システムとバリデーションの課題
Yoshiori Shoji
また何か問題が出てくるのかね
draftcode
トムルでもね
そうだね
構造が書き方によっては
Yoshiori Shoji
見にくいっていうのもあるし
draftcode
アンチ構造
構造がしすぎると
読めていいぜって言ってたけど
構造もある程度欲しいっていう
Yoshiori Shoji
わがままの需要が
あとはさ
例えば型つけたいみたいな話も
あったじゃん
型ってさどのぐらい必要なのかな
っていうのもたまに悩んでて
文字列
数字
とあとは多分
ブーリアンだよね
うん
ここまでは必須だとは思うのよ
あとは日付型とか
デュレーションとかを
型として持つかみたいなのは
悩ましいよね
draftcode
でもね
どうだろうな
っていう風に思うのは
その
型が欲しいっていうのは
ある程度その
ドキュメンテーションの意味もあれば
バリデーションをどっかのタイミングでしたい
draftcode
っていう気持ちがあるんだよね
で
バリデーターとしてはさ
その程度の型だと
ちょっと満足できないなっていう
場合もあるじゃん
あとは
ブーリアンだったらいいよ
でもイナムになるじゃん
ここはABCのどれかですみたいな感じの
そうね
ってなると
別にストリングでいいんだけど
バリデーションとしてはなっていう風に
ちょっとお気持ちが出てくるし
でまた
ここの値がセットされたら
こっちの値もセットしないといけないみたいな
パターンあるじゃん
Yoshiori Shoji
そういう
draftcode
型システム
全般で言えば
そういう型システムを作ることができると思うんだけど
一般的に現実的に
作れる型システム
使える型システムというか
みんなが理解できる型システムとしては
ブーリアンとかインテージャーとか
そういうレベルでしかないので
難しいよね
例えばそのバリデーションも
最悪アプリケーションの
スタートアップが失敗してくれれば
ロードアウト
ブロックできるから
オッケーよっていう風な立場もあるし
いやいやいやこれは絶対
もう回し前に
絶対テストでバリエーションしたいよ
みたいな感じの
人もいるけどそういうプロダクトもあると思う
Yoshiori Shoji
場合によって違うよね
draftcode
プロダクトによるよね
型が欲しいというよりかは
Yoshiori Shoji
どっかでバリエーションしたいみたいな
型が欲しいイコール
プログラミック言語でもそうだけど
バリエーションしたいというかテストをしたい
draftcode
みたいな感じだもん
設定でテスト変え始めると
Yoshiori Shoji
泥沼感が
設定変えるのに
まずテスト変えてみたいな話も
出てきたりとかさ
draftcode
いい設定のテストとは何かみたいな
Yoshiori Shoji
感じの話になる
で
っていう感じになってくるとさ
若干プログラミング言語と同じ悩みになってくる
わけじゃん
今日まだ話してなかったんだけど
設定ファイルでDSL派がいる
わけよ
プログラミング言語を
そのまま書いているけども設定ファイル
のように見える
で
有名なとこだとRailsの
confファイルとかもある
と思うんだけども
多分でもみんなが一番使ってるのは
Bashとかの設定ファイルBashrcとか
draftcode
うーん
Yoshiori Shoji
あれもDSL
DSLとその問題
draftcode
そう言われれば
Bashrcは別にBashスクリプトだし
Yoshiori Shoji
そうそうそう
でまあ
俺はVimわかんないけどVimもVimスクリプト書くよね
そうそうだね
あれはconfファイルじゃなくてスクリプトだよね
でまあXはもう完全にあれは
Lispでプログラミングを書いているだけなので
なんで
その
confファイルさっき言ったロジックを持ち込むな
みたいな話をしてたけれども
すごい単極にDSL
的なのは結構あるなと思っていて
で
さっきのテストの問題とか型の問題とかさ
だいたい全部片付くのよ
なぜならもうプログラミングがその機構を持ってるわけじゃん
型のシステムはプログラミングが持ってるしさ
それぞれでできるわけじゃん
みたいなのはあり
draftcode
まあどれくらい
Yoshiori Shoji
読んでなんかわざわざ
別のバリデーションとかテストを書くよりは
まあまあプログラミングをそのまま
プログラミングのテストとして書けるみたいなのは
あったりとかもするし
どうなのよ
って思うんだけどどうなのよって言いながら
まあDSLは嫌だな
draftcode
なので
DSLも
その
やり方はいろいろあると思うんだけど
例えばまあ
別に
アプリケーションの
一端として
あるフレームワークがあって
そのフレームワークのコンフィギュレーションの中のものとして
どういう設定を入れるかみたいな
ものについて
ロジックを書くことは
別に隠し
例えばJavaとかだったら
このDIのこのモジュールを入れる入れないみたいな
別にコンフィギュアなわけだから
そもそもSpringとかってあれ
XMLで書こうかコードで書こうか
できるよねっていう
そういう話ではあるね
で
まあそういう
ネイティブの
他のロジックアプリケーションロジックと
同じ言語で書いて同じように扱えるもの
っていうのは別に設定ではあるけれども
まあ
あまり設定
ぽくないというか
単純に
その
コンスタントなだけだから
いいのかなっていう感じがする
ただそういったもの
そういったコンフィギュアの問題点として
例えばちょっとここだけオーバーライドしたいみたいな感じの
行きが出てきたときに
まず環境変数を読んで
Yoshiori Shoji
環境変数が
draftcode
みたいな感じの
たくさん出てきて別にいいんだけども
結局環境変数になっちゃう
Yoshiori Shoji
同じような
とかDSL内で他の
なんかYAML読んだりJSON読んだり
とかし始めたりとかして
使い始めると
なんか構想構造が
階層構造が増えただけで
ただ単にややこしくなったグローバル変数
っていうのになりかねないので
まあDSLあまり好きじゃないんだけども
draftcode
あとDSL
その設定って
一覧でどういう設定があるんだろう
みたいなのって見えにくくなっちゃうよね
もちろんセントナルにかけてれば
別にいいんだけども
例えばあっちこっちでなんか
ここ環境変数読み込んで
こっちのやつにフォールバックしてるみたいな感じだと
なんか厳しい
感じになる
Yoshiori Shoji
設定一覧を見るためにアプリケーションを
起動してインタラクトして
その中で設定オブジェクトをダンプしてください
みたいなさ
そしたら一覧見えますみたいな
気になっちゃいがちだよね
draftcode
なので
設定のスキーマみたいなのを見たいっていう
さっきの型をつけたいっていうのに近いのは
バリエーションしたいとかそういうのに近い
話でいうと
設定自体のスキーマが欲しいよねっていう
ところがあるんだよね
設定スキーマの必要性
draftcode
また設定のスキーマとかがあると
特にまあ
今のJSONスキーマとかでダンプできるみたいなものがあるんだけども
それを使って
LSPとかがちゃんと整ってるんで
そのJSONスキーマを適当に
このファイルのJSONスキーマはこれですっていう風に
なんか指定してあげると
オートコンプリートとかもしてくれて
便利みたいな感じになるんだよね
JSON加工がやめる加工が
そういうなんか快適
そういう側面もあります
が
DSLもいいなっていう
DSLがいいなっていう
時もあるのは
特にプログラマティカルに
いろいろコンフィグを書きたい時ってあるんで
Yoshiori Shoji
そうね
とかちょっとロジックがやっぱりさ
その
なんだろう
ロジックを書かない方がいいのはめちゃめちゃ分かってんだけども
ロジックを書かない
せいでダーティーハックみたいなの
めちゃめちゃする時あるじゃんコンファイルにさ
しょうがないからここ
ロジックが書けないからしょうがないから
環境変数のこれを持ってこようとかさ
とか環境変数のこの
値に実はこう
なんかを配分なんちゃらってつけておいて
プログラム内で
見て判断しようみたいな
設定にロジックが書けないせいで
他のところでダーティーハックをしてる
みたいなことも発生しちゃうことがあるので
一概にこう
DSL絶対悪いとかは
言いたくない気持ちは分かる
draftcode
気持ちによるよね
しかもさ
ある面ではこれがいいなって思うんだけど
他の
なんか問題とかに
直面してくると
DSLやばかったみたいなさ
Yoshiori Shoji
いやでも
DSLくそ
DSLくそだなって思うことは人生で何度もあったわけじゃん
draftcode
あるある
あるしDSLあってよかったな
みたいな感じのこともあるし
こう
もうそれぞれよね
なんでコンフィグの
この読み込みのところでデータベース読み込み
してんだろうなみたいな
コンフィグ同士のデペンデンシーが
あってさ
このコンフィグはこのコンフィグを読まないといけない
そのコンフィグを使って何かやってるんだけど
みたいな感じのところね
だんだんだんだんこれ何書いてんだっけ
みたいな感じになっていく
Yoshiori Shoji
そう
draftcode
そうだね
正解はない
それぞれで
Yoshiori Shoji
そう正解はないけれども
結構いろんなプログラミング
アプリケーションとかでさ
そのYAMLに独自の
継承概念みたいなの
ぶち込んでたりとかするじゃん
draftcode
クバネですね
Yoshiori Shoji
スプリングもそうなのよ
スプリングの設定を
YAMLで書いたときもそうだし
確かRubyのさ
ほらデータベースYAMLとかもさ
draftcode
そうじゃん
自分はあんまRuby使ってないからあれなんだけど
Yoshiori Shoji
そうなんでしょうねっていう
もうDBの設定を
デフォルトみたいなの定義しといて
ステージングとかプロダクションで
URLとID
パスワードのところだけ上書きするみたいなの
とかあるんだけど
そう
継承すぐしたくなるよね
draftcode
そう継承したくなる
継承したくなる
うん
Yoshiori Shoji
そうだね
継承したくなる理由は分かってさ
さっきのRAISEの
DB YAMLが分かりやすい例なんだけども
このアプリケーションで使う
データベースはPostgresであって
でコネクション実は
このぐらい使うので
このぐらいにしておきたいみたいな
のはデフォルトの設定なんだよね
それはアプリケーションの設定
デフォルトの挙動だから
でもステージングとプロダクションで
接続先とパスワードは違います
っていうのはそれは当たり前だから
そこだけ書き換えたい
だから継承したい
これめちゃめちゃ気持ちは分かるよね
draftcode
これよしみも分かると思うけどさ
継承ってさインターフェース継承とさ
実装継承みたいなのがさ
一般にプログラミングだと
設定ファイルの継承って
常に
Yoshiori Shoji
実装継承なんだよね
draftcode
インターフェースは同じだからさ
データベースストリングって
このデータベースのコネクションとさ
ユーザーにパスワードがあってみたいな
全部実装継承なんだよね
だからドルマ化する
未来しか見えないんだよね
難しいんだから
継承早いんだから人類にはっていう
Yoshiori Shoji
でも今のデータベースの件でいうと
環境によって違う値だから
じゃあさデフォルトだけにして
そこは環境変数から
持ってきましょうみたいにするんだよね
そのURL
データベースURLとパスワードは
環境変数から持ってきましょう
だってこれは環境によって違うだけだよね
環境変数を使うみたいなのが
だいたい行われるパターンなのかな
みたいな気がしていて
そうなってくるとテストのときに
テスト書くときに
じゃあここの環境変数が入ってないから
ここの入れときましょうみたいなので
またテストが壊れ始めみたいな
のが発生して
何に書いたら幸せなのかね
draftcode
環境変数
グローバル変数だからさ
このテストは
このテストを走らせた後だけで通るんだけど
このテストだけを走らせると
落ちるみたいな感じの
バゼルの利用とその課題
draftcode
よくあるよねそういう感じの
Yoshiori Shoji
だいたいプログラムね
プログラム内で
セット演武して
デリテンボし忘れて
他のテストに影響がいくみたいなね
そうですね
draftcode
ちょっとDSLの話にまた戻るんだけども
DSLのいまいちな
ところって
メタ構造が
取れないみたいな
ものがあって
すごくそのまま単純に言うと
テストのリストが取れないみたいな
話だから
バゼルとか頑張ってうまく解決するんだけども
動的にコンフィグみたいな
ものが生成されるから
このビルドターゲットの
その
デペンデンシー一覧みたいなのを取りたいと
実際にそのコンフィグを全部
DSLみたいなのを実行しないと
最終的に
どういったコンフィグになるのか
が取れないみたいな
話になるから常に
何をするにしても
その
実行系が必要になる
っていう話になって
遅いし
ループがかけるとループを書きたくなるし
最終がかけると最終を書きたくなる
なんか
そこが難しい
話ですね
Yoshiori Shoji
バゼルのコンフィグの話してなかったね
draftcode
バゼルのコンフィグはね
あれはPythonもどき
もともとPythonだったのがPythonは強力すぎる
Pythonはやめよう
ってなって
Skylarkという言語になったんですが
単純な使い方してればね
いいんですけど
レールに乗った使い方じゃない
使い方を始める
Yoshiori Shoji
ちょっとだけレールから外れ始めると
急にぶん殴ってくるよね
draftcode
大変だよねバゼル
世の中の人
どうやってバゼル使ってるんだろう
Yoshiori Shoji
今ご存知の通り
うちの会社バゼルでいまだに
やってるからさ
ちょっとしたことやろうすると
急にぶん殴られるからな
draftcode
高級メイクファイルと思ってたら
やばい世界に入る
っていう
Yoshiori Shoji
あれはだから
そもそも
Pythonで書こうとしてた
でSkylarkだった
Skylarkっていう
あれがDSLに近いのかな
あれDSLと言っていいんじゃないかな
draftcode
ドメインスペシック
Skylark自体を単体で
使うことも別にできるけど
使ってるプロジェクトあったような
設定言語の多様性
draftcode
気がするけど
Yoshiori Shoji
あんまり
Skylark自体の
draftcode
インタープリターは
独立して
提供された記憶があるから
多分
どなたかDSLを作りたいという
コンフィグDSLを作りたい
っていう方がいれば
そういった
既存の
コンフィグDSL用の
ストリップトランゲージみたいなものが
あるんだけれども
一応DSLと言っていいんじゃないかな
バゼルこそさ
Yoshiori Shoji
コンフィグファイルがさ
わざとだけどさ
至る所に飛んでいくわけじゃん
その
コンフィグファイルの一覧
そもそもどうやったら求められるのか
分かんないくらい
draftcode
バゼルのビルトターゲット一覧取りたいな
って思ったら
もう
ワークスペースの全部を
ビョーって
ビョーって
Yoshiori Shoji
自力で
取らなきゃいけない
それこそね
ディレクトリー単位に
.バゼルファイルがあったりとかするわけじゃん
だから
あれはあれで
すごい世界だよね
draftcode
力こそパワーみたいな感じで
解決していく
Yoshiori Shoji
そう
あれはまあ
次プロジェクトやる時俺は使わないかな
って思いながらやっている
draftcode
自分で選ぶ
選ぶのさ
ほとんど
どうしても
バゼルでしか解決できない
問題がないと
あまり
使う感じにはならない気がしますね
Yoshiori Shoji
なんかでも
好きよ
バゼルでも好きか嫌いかで言われると
思想は好きなのよ
ビジブルとか
指定してさ
このライブラリはここからしか読んじゃダメですよ
みたいなの設定できるわけじゃん
あの考えは結構好きなのよ
俺は
それこそ
draftcode
あのさ
あまり批判として
捉えてほしくないんだけど
XSLDとか好きじゃなかった?
Yoshiori Shoji
XSLDとか好きじゃなくて
draftcode
若干ね
自分の中でその思想は好きだけども
実際使うとなると
思ってもなるものの一つとして
XSLDみたいなのがあって
わかるわかる
XMLをうまく変更できるようにすればいいじゃん
みたいなのが
思想としてはなるほどね
みたいな感じに思う
例えばさ
太古の昔にさ
XHTMLみたいなのがあってさ
確かにこれ全部XMLとして使用できると思う
ストレート
Yoshiori Shoji
いいなあ
draftcode
思想としてはわかるんだけど
まあ
Yoshiori Shoji
あとあれだよね
言語で言うと前も話したかもしれないけど
検査例外ね
draftcode
検査例外
思想としてはね
すごい大好き
でも実際はね
Yoshiori Shoji
まあまあ
ちょっとずれてきちゃったけど
設定言語いろいろややこしいよね
っていう話で
今後しばらくはトムルに落ち着いていくんじゃないかな
って感じかな
トムルとヤムルの比較
Yoshiori Shoji
ヤムルの時代
ヤムルジェンソンの時代は
若干終わりを迎えている気がするよね
draftcode
そうね
トムルパーサーが
どれくらい標準的に
標準ライブラリとして
使えるようになっているのか
Yoshiori Shoji
だってパイソンには入るんでしょ
パイソンはもう入ってるよ
パイソンはもう入ってるし
パイソンで
300行で書けるってことは
嫌がらないと思うんだよね
draftcode
トムルだと
知らないのが
トムルってどれくらいスペックが
厳しいのか分かんないけど
トムル1.3とトムル1.2で
これくらい違いますみたいな
Yoshiori Shoji
トムルってさ
雑に誰か1人が適当に
トムルってこういうものでして
ブログに書いてあるぐらいのイメージしかなかったんだけど
draftcode
前調べた時
今見たらねバージョン1.0.0っていうのが出てて
その前に
トムル1.0とか0.4とか0.3とか
一応バージョンが出てるね
Yoshiori Shoji
トムル1.0
draftcode
いろいろいろいろあるんじゃない
コーナーケースがいろいろあるんでしょ
Yoshiori Shoji
まあまあ
でも300行で書けるってことは
draftcode
いいよね
Yoshiori Shoji
いい気がする
パーサーで300行で書けるって結構
すごいと思うんだけど
パイソンはそんなに
パイソンでそれぐらいで書けるのか
そうそうそう
draftcode
あと
そうだね
Yoshiori Shoji
パールで300行とか言われるとさ
なんかすげえハックして
300行にしたんじゃねーの
みたいな気がするけどさ
パイソンで300行だと
まあ普通に書いて300行かみたいな
draftcode
ヨシオにはあれでしょ
パイソンでショートコーディングしたことなかった
Yoshiori Shoji
そうね
draftcode
してた
Yoshiori Shoji
インデントとかガン無視したパイソンとか書いてた
それは
おもちゃとして遊んでただけだから
draftcode
まあトムルも全然
ありの選択肢かなっていう感じは
Yoshiori Shoji
するよね
まあだから
でもね
draftcode
トムルもさ
ヤムル批判したけどさ
あんまりフェイバルブなコメント
今一回も言ってないけどさ
別に基本的にそんなに
ヤバい言語じゃないね
Yoshiori Shoji
いやうん
99%ヤムルでいいと思ってるよ
draftcode
設定ファイルは
だから
別に
ヤムル
どうしてもやめてほしいってわけじゃないから
あんまりなんか
ヤムルがされる
未来もあんまり見えないんだよな
っていう風に思ったりはするんだよね
Yoshiori Shoji
いやわかる
前に話した
アラクリティがヤムルからトムルになった時もさ
別にヤムルで困ってないのに
めんどくせえなって若干思ったからね
トムルの方が好きな人間としても
そう
ヤムルがなくなってほしい
draftcode
わけではないけども
どっちって言われた時に
まあ様々な条件が一緒だったら
トムルの方がいいかもねっていう
Yoshiori Shoji
ぐらいの
今から選んで1からなんか設定言語
アプリケーション書きましょうってなって
設定ファイルが必要ですってなったら
じゃあトムルにしとくっていう
今はヤムルでいけるかもしれないけど
将来的にこのアプリがでかくなった時に
どっかで後悔するタイミングが来るかもしれないから
最初からトムルにしとこうかみたいな
ぐらいの感覚だよね
draftcode
かもね
まあ
そうだね
あと対象
例えば会社のさ
会社のインターナルの
コンフィグだったらさ
みんな教育すればいいんだけどさ
一般に配布して使うCLIみたいな
のとかさ
一般にこうユーザーに書いてもらう
設定言語っていった時にさ
ヤムルとトムルどっちが市民権認知度が高いか
っていうとたぶん完全にヤムルだよね
Yoshiori Shoji
ヤムルだよね今ね
draftcode
だからねこれちょっとなんとも
ユーザーの市民権みたいなの
考えるとまたヤムル
もありっちゃり
ありっちゃりっていうかなんかなんか
それを考えたらヤムルの方がいいかもしれないっていう風に
ユーザー受容の観点
draftcode
思ってもしまうな
まあ要は
要はバランス
Yoshiori Shoji
そうまあだからパイソンの
これのおかげでトムルがどんだけ市民権を
得るかだよね
draftcode
でもこれ結構あるとは思うんだよ
Yoshiori Shoji
あそうなんだ
draftcode
パイプロジェクト
だってこれ2016年のやつだよ
そっか
8年前だよ8年前
Yoshiori Shoji
ごめん2016年が8年前
っていうことに今逆に衝撃を受けたわ
draftcode
そろそろ
Yoshiori Shoji
9年前になるからね
そうね
しかもメイだもんね
そういう意味で言うとヤムルは綺麗に市民権を
得たよね
うん
そうね
ヤムルは市民権を得たけれども
ジェイソンは未だになんかみんな
脱法ジェイソンしか書かない
どういうこと
ストリクトに言うと
ジェイソンってコメント書けないとか
ケツカマ許されないみたいなのがあるじゃん
でもなんかその言語のライブラリによっては
読み込めちゃうからコメント書いている
みたいな人とかさ
いるじゃん
脱法ジェイソンを使っている人が結構多いよな
っていう認識があって
draftcode
わかるわかる
これ公式のスペックがそうなってんのかわかんないけど
ノンマスキーキャラクターを
入れるときに
Pythonのデフォルトの
ジェイソンライブラリって
指定しないとエスケープされてんだよね
Yoshiori Shoji
あー文字列として
draftcode
文字列かね
文字列とかが
言うなんとかなんとかみたいな感じの
あれってアスキーにしないといけない
っていう特別な
あれがスペックなのかな
それとも別にスペック上
問題ないのかな
Yoshiori Shoji
そこはわからん
あと
Pythonちょっと前まで
マルチバイトモジュレーターの扱い
draftcode
クソだったからね
ちょっと前
10年以上前だった
Yoshiori Shoji
10年以上だいぶ前だね
3になる前の話ね
draftcode
2.7っていつデフォルトゲームになったんだろう
っていう感じ
Yoshiori Shoji
文字列が
Uをつけるかどうかで
draftcode
U文字列とか
B文字列とか
Yoshiori Shoji
B文字列とかがあった時代の話
だから3になる前の話
draftcode
だいぶ昔だね
だいぶ昔の話
Yoshiori Shoji
どっちかな
どちらかってきたのでこの辺にする
draftcode
もうでもあれだね
新しいコンフィグ言語を独自で作る
人たちが少なくなっていってほしいな
ってやっとわなざわエンジンX
コンフィグはもう作ってほしくないな
っていう気持ちが強いですね
Yoshiori Shoji
じゃあそんな感じで
設定期日言語なんか
30分喋れりゃ十分なんじゃない
ってやる前は言っていたのに
また気がついたら1時間話してたね
draftcode
いいですね
Yoshiori Shoji
じゃあそんな感じで
ここで終わります
お疲れ様でした
