バージョン管理のエコシステムとしては GitHub がデファクトスタンダードではありますが、プロジェクトによっては少々無理が生じることがあります。

今回の私の場合では、ゲーム開発のプロジェクトで大量のバイナリファイルを扱う見込みですが、 GitHub では 容量制限 があり、（執筆時点では）ストレージが無料枠で 1 GB のストレージ, 追加購入プランでも 50GiB かつ帯域幅（例えば、ダウンロードで使う通信量を含む）も 50GiB/月までとなっており、そこそこの規模のゲームであれば容易に使い果たしてしまう可能性があります。

一応代替策として LFS を別のサービス(AWS S3 など)にホスティング したり、 LFS だけローカルでホスティングする という荒業も可能ですが、AWS を利用するのであれば正しい知識を持ってプロダクションレベルで管理しないと構成がめちゃくちゃになる可能性がありますし（経験あり）、個人レベルではわずかながらコストがかかるのも気になります。

そんなわけで色々考えるのもめんどくさくなり、バックアップ策という意味ではクラウド必須ではないし、 PC が分かれてればいいでしょ…ということで、自宅で少々持て余していた Mac Mini (M2Pro) に GitLab をホスティングすることにしました。

ただし GitHub を捨てるということは草が生えないという点が残念ですが、対策のために労力を費やすモチベーションもそんなにないので、まぁいいかなという感じです。

構成

構成を下記に一覧しますが、基本的には Docker で GitLab をホスティングするというだけです。

ただ注意点としては、ハードウェアに関してはそれなりのスペックが必要です。最近の Mac (Mini) であれば十分そうですが、当初 Docker ホスティング機能のある NAS(QNAP, メモリ 8GB ぐらい)を利用しようとしたところ、スペックが足りず断念しました。参考：GitLab の動作要件

• ハードウェア: Mac Mini (M2Pro)
• 仮想化バックエンド: OrbStack (Docker Desktop の代替)
• GitLab イメージ: gitlab/gitlab-ce:latest
  • EE(Enterprise Edition) ではなく CE(Community Edition) を利用

導入手順

導入手順としてはシンプルで、GitLab のコンテナを起動するだけです。GitLab のイメージは単一で完全なインフラストラクチャ(DB など)を構成してくれるので、コンテナを起動するだけで動作します。

docker-compose.yml を作成

公式のガイド が参考になります。ここの docker-compose.yml をコピーして、適宜編集しています。

Mac 特有の注意点として、例えば 共有 volume はホームディレクトリ以下に配置するなどしないと、書き込み不可能な領域に volume を割り当てようとしてデータが書き込めない(永続化されない)ことがあります。~/GitLab/docker-compose.yml などに配置するといいでしょう。

yaml
services:
  gitlab:
    container_name: gitlab
    image: 'gitlab/gitlab-ce:latest'
    restart: always
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http://YOUR_PC_HOST.local:8929'
        gitlab_rails['gitlab_shell_ssh_port'] = 2224
        nginx['listen_port'] = 80
    ports:
      - '8929:80'
      - '2224:22'
    volumes:
      - './volumes/config:/etc/gitlab'
      - './volumes/logs:/var/log/gitlab'
      - './volumes/data:/var/opt/gitlab'

Gist にも公開しています。

起動・root のログイン

なにはともあれ、docker-compose up で立ち上げます。-d オプションをつけて立ち上げる場合もありますが、私はエラーなどが出ていないかログを確認することを推奨する委員会なので軽く確認してほしいです。

他の端末からアクセスする場合はhttp://YOUR_HOST_NAME_OR_IP:8929/ にアクセスして、ローカルネットワークで疎通できていることを確認します。

問題なければ root ユーザでログインします。初期パスワードはコンテナ内で自動生成されている（有効期限つき）ため、例えばこちらの方法で確認します： GitLab 初期パスワード

ログインしたら、パスワードを変更してください。

データが永続化されていることを確認する

万が一プロジェクトのデータ（issue やレビュー機能を活用してるかもしれませんね）を失うと号泣するしかないので、万全を期してデータが永続化されていることを確認します。

docker-compose down でコンテナを停止（滅する）し、docker-compose up で再度立ち上げます。root で更新後のパスワードでログインして、データが残っていることを確認します。

また、 ls -al ./volumes/data などを実行して、何らかのデータが残っていることを確認します。

所感など

Mac (Mini) を使うと iOS アプリのビルドもできますし、そのような場合に CI/CD が比較的簡単に設定できそうです。ゲーム開発向けのビルド・デプロイサーバーとしての Mac (Mini) の選択肢は結構いいんじゃないかなぁと思いました。

更新履歴

• 2024-08-04: 初稿

最近 Rhai という Rust で動作するスクリプトエンジンを見つけました。

ゲーム開発向けにライブラリの作成を検討していて、当初は目的のライブラリそのものを Cython(Python)で作成しようと考えていたものの、モバイル向けにポーティングするには numpy などのパッケージ導入のハードルが高いことがわかり、断念していました。

最終的に Rust を使うことに決めたのですが、スクリプトエンジンがあるとは知らなかったので嬉しい誤算です。

また、Rhai は AST(abstract syntax tree) というコードをパースした結果を Rust で取得することができます。これを再利用することでパースの時間を省略し、高速にスクリプトを実行できるという利点があります。

そこで、当然ながらどれほどの速度差があるのか気になりましたので、ベンチマークを取ってみました。

結果

テストコードおよび結果はこちらのリポジトリにあります。
Benchmark Rust Rhai

フィボナッチ数列を n 回計算するという単純な処理を行い、その時間を計測しました。主要な部分の抜粋は以下。

rust
    let engine = Engine::new();
    let script = "
        fn fibonacci(n) {
            if n <= 1 { return n; }
            else { return fibonacci(n-1) + fibonacci(n-2); }
        }
        fibonacci(n)
    ";
    let mut rust_times = Vec::new();
    let mut direct_times = Vec::new();
    let mut ast_times = Vec::new();
    let mut ns = Vec::new();
    for n in 1i64..=10i64 {
        ns.push(n);
        let mut scope = Scope::new();
        scope.push("n", n);
        // Rust (vanilla)
        let start = Instant::now();
        let _rust_result = fibonacci(n as i64);
        let rust_duration = start.elapsed().as_secs_f64();
        rust_times.push(rust_duration);
        // Rhai (direct)
        let start = Instant::now();
        let _direct_result: i64 = engine.eval_with_scope(&mut scope, script)?;
        let direct_duration = start.elapsed().as_secs_f64();
        direct_times.push(direct_duration);
        // Rhai (AST)
        let ast = engine.compile_with_scope(&mut scope, script)?;
        let start = Instant::now();
        let _ast_result: i64 = engine.eval_ast_with_scope(&mut scope, &ast)?;
        let ast_duration = start.elapsed().as_secs_f64();
        ast_times.push(ast_duration);
    }

私が docker-compose で走らせた結果は以下の通りでした。

n=10

n=30

考察

前提として、当然ながら PC のスペックによって処理時間は変わるため、Rust(=Vanilla)をベースに相対的な速度を比較して評価します。結果としては以下のことが考察できます。

• 無論、Rust が最速である
• Rhai(Direct)の初回の実行が遅い
  • これはスクリプトエンジンの初回の evaluate に時間がかかるためと思われる（面倒なので未検証）
• Rhai(AST) は Rhai(direct)より早い。スクリプトが複雑になるほど恩恵があると予想できる
• イテレーションが進むにつれて、Rust と Rhai(Direct, AST) の差が指数関数的に広がっていく
  • ごく一般的な話ではあるが、スクリプトで行う処理は短いほうが良い。特に反復的な処理。
• イテレーション 30 で Rhai(Direct, AST) が 830ms 程度に対して、Rust が約 1.5ms （出力した HTML だとポイントごとのデータが見れる）だった。
  • 1/500 程度の差がある(=Rust が 500 倍速い)ということになる。アプリケーションで Rhai がボトルネックになっていると特定できた場合、500 倍の速度向上が見込めると予想できる。

所感

スクリプトエンジンを搭載する利点は JS, Python よろしくランタイムでプログラミングできることです。

Rhai ではこの柔軟性を持ちながら、もしボトルネックになるような処理があれば Rust で書き直すことで高速化が見込めるという利点があります。

今まででも、例えば Python と Cython, C++の組み合わせにより同等のことは可能ではありますが、スムーズさや移植性の点で Rust と Rhai の組み合わせは魅力的だと感じました。

また、AST を取得することでスクリプトのパース時間を省略できる機能もなるほどという感じです。これはスクリプトが複雑になるほど恩恵があると予想されるため、ぜひ活用したいと思いました。

まだまだ研究中ですが、開発全般のワークフローを効率化できる余地がありそうです。何かと機会があれば実際のアプリ開発に取り入れてみたいと思っています。

更新履歴

• 2024-07-06: 初稿

favicon が localhost を参照してしまう、という問題だった。(アプリのコンフィグの問題)ブラウザのデバッガで特定できる。

EEXIST エラー でこける (file already exists)

[urara] error EEXIST: file already exists, mkdir 'src/routes/blog'

このようなエラーでコケる場合は、fs.mkdir で recursive オプションを指定する。 mkdir -p と同じ動きとなるため。

js
// fs.mkdir(path)
fs.mkdir(path, { recursive: true })

参考: Node.js create folder or use existing

GitHub Pages (gh-pages ブランチ) のデプロイを抑止する

GitHub Pages (Actions) の設定で main に push すると gh-pages ブランチに勝手にマージされてしまうことにより Vercel もデプロイしてしまう。というのが原因だったのでそれを抑止する。

対策例: https://github.com/Nagitch/mujina-prod-site/pull/14/files

Sharp Missing In Production エラー

モジュールがインストールされていない・古いだけだった。（エラーログのメモを忘れた…が、すぐにピンとくるはず）

更新履歴

• 2024-07-04: 不足していた説明を追加・校正
• 2023-10-01: 初稿

技術スタック

最終的には次のような構成を選択しました。

• Urara テンプレート
  本サイトのデザインテンプレートです。
  概ね以下の技術で構成されており、このテンプレートをベースにカスタマイズを加えています。
  （元々ブログ専用だったけど魔改造してポートフォリオサイト＋ブログにした）
  • SvelteKit
    • Static Adapter (=Static Site Generator として使用)
  • Tailwind CSS
    • DaisyUI -> Tailwind ベースのデザインフレームワーク
  • Vite
• Vercel によるホスティング

この選定の背景について、以下に書いていきます。

コンセプト・要件

一番の目的は個人事業にも使えるポートフォリオサイトであり、個人制作の成果物も僅かながら仕事に関係することを考慮する必要がありました。
またブログとしても使いたかったのは、見栄えが統一できること（無論外部のブログプラットフォームにはできない）と、ブログ記事からホームへの流入を期待できるためです。
※SEO 的にもサイト内にブログを含めた方が良いかなーというのもあり

ただ、Qiita, Zenn などのブログプラットフォームのほうが類似する記事からの流入が期待できるメリットなどがあるので、ここらへんは一長一短かと思います。

また本業がプログラマーなので、WordPress や適当な CMS を使うのではなく、フロントエンドの技術を使って作りたい気持ちがありました。

SvelteKit / SvelteJS

はじめは GatsbyJS(Next SSG) がいいところかなーと思ったのですが、どうせなら新出の SvelteKit を使ってみようと思いました。
またちょうど最近 SvelteKit 1.0.0 がリリース されたので、これを機に使ってみようという発想です。
使用感としては、ステートフルな思想は変わらず純粋に React(Next) / Vue(Nuxt) の問題を解決した代替という印象で、React/Vue の知識はそのまま活かせますし、個人的には使えるところで積極的に使いたいと思ってます。

Svelte について気になる方は、ぜひチェックしてみてください。

デザイン

個人制作していたり、ゲーム・エンタメ系の仕事に関わってるのもあり「とりあえず作ってみました感」が出てしまうのだけは最低限避けたいと思いました。
またレスポンシブ対応はフロントエンドプログラマーの矜持としてマスト。

なのでめちゃめちゃ凝りたい気持ちはあったのですが、おそらく数年かけてもプロのセンスにはどうしても敵いません。（個人的には純然たる事実として受け入れています）
というわけでテンプレートを探して使うことにしました。
この発想は、業務系 Web でよくデザインフレームワーク(古くは BootStrap とか) を使っていたのですぐにピンときた感じです。

Urara テンプレート, Tailwind CSS

ブログの仕組みが入ってれば単純なページ（ポートフォリオなど）は簡単に実現できるので、とりあえずブログのデザインテンプレートから探すことにしました。あとできればブログは Markdown -> HTML の変換で作りたかった（GatsbyJS でよくあるやつ）のでそこらへんも観点の一つです。

良さげなものが見つからなければどうしようもなかったのですが、SvelteKit, GatsbyJS あたりのテンプレートを探していたところ、幸い好みに近い Urara テンプレート にたどり着きました。

ざっくり以下のカスタマイズをしています。

• ルーティングの変更。ブログは /blog 以下に移動。 / や他コンテンツは自由な Web ページへのルーティングに。
• 基本のカラーバリエーションの変更
• ほか、いろいろ・・（覚えてない）

ホームや他コンテンツのページは Tailwind / DaisyUI を使っています。初めて使いましたがいわゆるユーティリティクラスを使ってデザインするスタイルはかなり合理的でいいなーと思いました。

プログラマーがデザインもする場合や、ちゃんと融通の利くデザイナーと一緒に仕事をする場合は積極的に使っていきたい気持ちです。

Vite

Urara テンプレートが Vite を使っていたので自動的に使ってるだけですが、ブログの Markdown -> HTML 変換をかませていたりしてもホットリロードが即座に反映されるので、快適に作業できました。
ちなみに作業環境としては WSL2 Ubuntu + VSCode (Remote Development) です。 (Docker は使ってない)

Vercel

最初はどこでもよくて、S3 あたりにホスティングすればいいかなーと思っていたのですが、Urara テンプレートが Vercel をサポートしてた(Vercel が SvelteKit に対応してるというが背景にありそう)ので、試しに使ってみたらめちゃめちゃ良かったです。
あと無料枠が無いと思ってたんですが、ありました。（純粋にこれはありがたい・・）
Vercel の料金体系

登録から GitHub と連携、デプロイまで直感的にできました。(ほぼ Urara テンプレートが対応してたおかげですが)
また Vercel のサブドメインを払いだしてくれるので、独自ドメインを持ってなくてもとりあえず公開できます。（知らなくて避けてた）

あと個人的には、CDN への浸透も早いなと感じました。

Web アプリのプロトタイピングなんかをする場合は今後も使ってみたい気持ちです。

問題点

ブログにコメント機能がつけられない

あくまで静的サイト（Static Site）なので当然ですが。

少し考えましたがここは潔く切り捨てました。
ブログの内容としては主に技術系（ある程度普遍的な内容）なので、会話の場として積極的に使うイメージがないのと、
コメントがつくことはほとんどない（と思っている）ので、Twitter(X)などで引用されるのをエゴサしてニッコリしたり、ソーシャルのリンクはホームにあるのでコンタクトが必要ならそっちから連絡してもらえればいいかな～という感じです。
※記事ごとのソーシャルリンクはそのうちつけたい

以上です。同様のお悩みを抱えてる方の参考になれば幸いです。
また度々トラブルシューティングが必要になったので、そちらに関しては別途記事を書く予定です。

更新履歴

• 2023-09-19: 初稿
• 2023-09-20: 細かな修正（誤字脱字・文章校正）

ブログでは多様で有益な情報をお届けしたいと考えています。

生暖かかく活動を見守っていただけば幸いです。よろしくお願いいたします。