GLOXINIA Blog

神子ロス (Kamiko Loss) によるブログ

全記事一覧

Unity 6 が感度1000倍になった理由を探る (Semantic Versioning)

schedule2024-03-20 23:15
update2024-03-21 01:42
編集部注（2023 年 12 月 1 日）：11 月の Unite 2023 で、Unity エディターとランタイムの新しい名前が公開されました。Unity 2023 サイクルの 3 つ目の TECH ストリームは、Unity 6 Preview と命名されます。また、Unity 2023 LTS は Unity 6 と呼ばれることになります。Unity 6 および Unity 6 Preview で提供される内容については、Unite 2023 基調講演 ならびに製品ロードマップのセッション（まもなく YouTube で公開予定）をご覧ください。
Unity は "Unity 2023" のように年度をバージョンにしていたが、次のバージョンを "Unity 6" にすることを発表した。もともと Unity 5 の次を Unity 2017 にするという流れがあったので、元の形式に戻る形となる。そして先日 Unity 6 が実際にリリースされたのだが、そのバージョンが 6000 となぜかバカでかい数字なのが巷で話題になっている。
表示上は Unity 6 とあるが、実際のバージョンは 6000.0.0b11 と1000倍になっている！対魔忍！？一瞬びっくりしたが、すぐに Sematinc Versioning のことが思い当たった。巷はただザワザワしており、このことについて言及しているのをあまり見ない気がする。
Sematinc Versioning (SemVer) とはソフトウェア バージョンをどういう規則でつけるかを決めたものだ。必ずしも従う義務はないが、みんながなるべく同じ認識でやっていくために基準はあった方がいい。GitHub の共同設立者である Thomas Preston-Werner が作ったらしい。
8. メジャーバージョン X （X.y.z | X > 0）は、パブリックAPIに対して後方互換性を持たない変更が取り込まれた場合、上げなければなりません（MUST）。その際にマイナーおよびパッチレベルの変更も含めてもよいです（MAY）。メジャーバージョンを上げた際には、パッチおよびマイナーバージョンを0にリセットしなければなりません（MUST）。
SemVer に従う場合、メジャーバージョンは前のバージョンより上げなければならないのだ！よって Unity 2023 の次を Unity 6 にする場合、表示名はなんでもいいが、バージョンは 2023 より大きくて 6 っぽい整数にしなければならない……ということでしょうがなく 6000 にしたのだろう。
せっかくなので SemVer の仕様を一通り読み返してみたのだが、以下のルールも気になった。
9. プレリリースバージョンは、パッチバージョンの直後にハイフンとドットで区切られた識別子を追加することで表現してもよいです（MAY）。識別子は必ずASCII英数字とハイフン [0-9A-Za-z-] でなければなりません（MUST）。識別子は空であってはなりません（MUST NOT）。数値の識別子はゼロから始めてはなりません（MUST NOT）。プレリリースバージョンは関連する通常のバージョンよりも低い優先度です。プレリリースバージョンは、不安定であり、関連する通常のバージョンが示す要件と互換性を満たさない可能性があります。例：1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92。
この文章、微妙に分かりづらくて原語の英語版も読みにいったんだけど、英語版でも同じ表現で分かりづらかった。パッチバージョンのあとに "ハイフンとドットと ASCII 英数字" が使い放題のように見える。だとすると 6000.0.0b11 でも問題なさそうだが、実際にはパッチバージョンのあとに繋げられるのはハイフンだけで、そのあとに "ハイフンと ASCII 英数字" で書かれた識別子を "ドット" で区切って繋げていってもいいよと言っているのだ。
……分かりづらくない？例を見たら分かるんだけど、例を見ないと分からない時点で微妙だし、なんならハイフンを含んだ識別子の例がないのが気になる。 1.0.0-alpha-1 もアリなはずだが。
そういうわけで 6000.0.0b11 というバージョンは SemVer のプレリリースバージョンの仕様に厳密には従っていない。まあ Unity は昔からずっとこうなので、そこは伝統を重視しているのだろう。SemVer に厳密に従った場合は 6000.0.0-b.11 もしくは 6000.0.0-b11 のようになると思われる。

Scrablog を開発するモチベーション

schedule2024-02-17 05:41
update2024-02-26 00:38
101回目のブログオープン では自分がブログの開設と閉鎖を繰り返す理由について顧みた。その中で Scrablog を開発した理由として以下のように述べた。
もともと Scrapbox という自分が愛用している Wiki ツールがあり、データ取得に関してそれなりに柔軟な API があり、かつ WYSIWYG な (文字を記述する部分に修飾が反映される) テキストエディターを有しているため Headless CMS として活用できるのでは！？といった思いつき一点張りで開発をはじめた。
思いつきファーストなところから始まったのは本当だが、まだ書いてない理由、というか背景があるので書いてみる。といっても主に "公開 Scrapbox プロジェクトではダメなのか？" という観点でしかないので、けっこう些細なものになる。Scrapbox のことを知らない人ならなおさらだ。
Scrapbox はもう5年以上も愛用している Wiki サービスだが、どこまでいっても Wiki でありブログではない。ブログとしての運用も可能だが、どうしても使いづらい点が出てくる。
一番大きいのはスタイル (見た目) の差だ。Scrapbox は記事がカード形式で表示される。Scrapbox では UserCSS というカスタマイズ機能を提供しており、見た目を自由にカスタマイズできるため、これをオールドスクールなブログの見た目に変えるのは理論上不可能ではないが、どうしてもかなりの無理が生じてしまう。
かなりの無理というか、おそらく自分が求めている "ブログにアクセスすると記事の全文が並んでいる" をやろうとすると無理なんじゃないだろうか？だらだらスクロールするだけで文字を読み進める行為がすぐに始まるのが好きなんだよな。
序文だけが書かれた記事の一覧が出るようなブログもあるけど、最初にどの記事を読むかのクリックの必要が発生するのでちょっとダルく感じてしまう。情報のインデックス性という意味では正しいんだけど。
カード形式の他にも、テロメア機能をはじめとして Scrapbox のデフォルトの見た目をいちいち無効にしていく必要があり、ブログのような見た目に近づける作業があることも考慮すると、自分でゼロベースでデータにスタイルを適用していった方が早いような気がしてそうしてしまった。
ただし、検索機能などあらかじめ用意されている便利な機能もわざわざ実装しなおさないといけない (現時点ではまだない) ため、自分でやるという選択はコストとの兼ね合いを考慮する必要がある。
特に検索機能に関しては大変なので Scrapbox の API を叩いて動的にコンテンツを表示するシステムにすることも考えたことがあった。API 経由のデータ取得にすると認証が切れた時点で表示できなくなるのが痛い。Helpfeel 社、API Key 認証機能つけてくれ〜！
そのほかに、表示順を選択できる機能も、Wiki として使用するときは便利になることもあるが、ブログとして公開したいときにはあまりいらない機能に思える。いや、あったら便利かもしれない……でもなるべくシンプルにしたいし……
とかなんとか考えるのが面白いんだよな、結局。コストの考慮がどうこうとか言ってたけど全部嘘です。
最近はサイドバー機能をつけた (左 Scarblog / 右 Scrapbox)。サイドバーにソーシャルリンクを設定できる機能があったらいいなと思ってたんだけど、記事を表示する機能を流用して特定のページ (profile) を表示すればいいんじゃね？と思ってそう実装したらガッチリはまってうれしい。これからの機能にも応用が効くし。こういうのが面白すぎる。

101回目のブログオープン

schedule2024-02-05 22:31
update2024-02-26 00:38
もはや何回目になるのか分からないが、この度ブログを開設する。ブログを何回も開設したことがある、ということは何回も閉鎖したことがあるということだ。なかなか長続きしない。月別アーカイブの地層が何十年分にも積み重なっている長寿ブログを見るたびに尊敬の念を禁じ得ない。
なぜこうも長続きしないのだろうか。胸に手をあててしばらく考えてみたところ、大別して2つの原因がある気がしてきた。 (飽き性なのは大前提なのでカウントしないこととする)
まずひとつめに、昔の文章を見返しているうちに気恥ずかしくなってしまう説だ。説というか、実際にそのように感じているので、ほぼ事実である。自分の声を録音して聴くとなんだか変な気がしてウワーッってなる現象があるが、それの文章バージョンが発生する。とはいえもういいトシなので、いい加減に自分に対して慣れたい気持ちがある。
そしてふたつめに、実は自分はブログを書くことに積極的な興味があるのではなく、ブログ周辺の環境を整える技術的な過程にしか興味がないのではないか説。この説を思いついたときのしっくりきた感といったらなかったので、これもまたほぼ事実であろう。
思えば今まで開設してきた数々のブログに関しても技術的な思い出ばかりがある。古くはシコシコ書いた HTML を Yahoo! ジオシティーズで公開したことにはじまり、ガラケーでホームページと日記を管理したこと、Tumblr で既存のテーマを改造したこと、WordPress で PHP を弄ったことなどなど……
直近では Contentful なる Headless CMS + Vue の構成でブログを作成していて、ここまでくると Contentful を触ってみたかっただけなのでは？感がすごいので説得力に拍車がかかる。
さらに言えば、今回ブログを開設するきっかけとなったのも Scrablog というブログ公開用のツールを開発したからである。もともと Scrapbox という自分が愛用している Wiki ツールがあり、データ取得に関してそれなりに柔軟な API があり、かつ WYSIWYG な (文字を記述する部分に修飾が反映される) テキストエディターを有しているため Headless CMS として活用できるのでは！？といった思いつき一点張りで開発をはじめた。
Scrablog はざっくりとこのような仕組みで動いている。Scrapbox が想定している本来の使い方では全然なさそうだし、かなり Helpfeel 社にフリーライドしておりあまり行儀がいいものではないが、まあ怒られたら引っ込めるか～ぐらいの気持ちで運用をはじめる。
ソースコードは こちら で公開している。まだ最低限の機能しかないが、気が向いたら (使っていて気になるところがあったら) 機能追加や不具合修正を続けていく予定だ。なんならこの記事を公開した直後にさっそく不具合がいくつか見つかった。ドッグフーディング大事。
ちなみに、コミットログを見てもらうとわかるのだが数か月何もしてない時期があったりして、仕事のストレスが堆積したときにそれを解消する (1人だけでコードを書くのはかなり気持ちがいい) 目的で作られたところが大きい。
また、サンプルおよび使い方の説明は こちら で公開している。元となる Scrapbox プロジェクト も公開しているため、どんな感じで使えるかの参考になると思われる。使い方の説明については、書いていて普段あまりにも当然のように行っていることを手順書のように順序立てて書いていたら大変すぎて疲れたので、まあまあ雑だ。気が向いたら強化するかもしれないが、こちらはあまりやる気が出ない。
そんな感じで、結論づけると仕事のストレス解消に書いたコードついでにはじめたブログだが、ぼちぼち続けていければいいなあ。

プロフィール

神子ロス (Kamiko Loss)
ゲーム制作, Web 制作, 写真, 作字 をやります。家系ラーメンが好き。