GreenWallでGitHubの活動グラフを画像のように設計する

GitHubのカレンダーを小さな描画面に変える発想

GreenWallは、GitHubプロフィールに表示されるコントリビューションのグラフへパターンを描くためのデスクトップアプリです。リポジトリの説明は機能を短く示していますが、READMEは画像を入力にして活動ヒートマップを作り、カレンダー上の位置を決めたうえでリモートリポジトリへ送る流れを具体的に説明しています。単なる画像変換器ではなく、入力、プレビュー、配置、GitHubへの反映を一つの画面で扱う設計です。

描画面の大きさには明確な限界があります。選べる行数は1から7、列数は1から52で、縦長の画像を無理に押し込むと形がつぶれます。READMEがTarget rowsを使って縦方向の比率を保つよう案内しているのは、この制約を操作の中心に置いているからです。細部の再現性を期待するより、限られたマスへ文字や輪郭を落とし込む用途として理解したほうが、結果とのずれを予測しやすいでしょう。

AutoとBinaryを素材の性質で使い分ける

変換モードはAutoとBinaryの二つです。Autoは一般的な写真やグレースケール画像を対象にし、Binaryは白地の黒文字や線画のように明暗を分けたい入力を想定しています。写真を二値化すれば情報量が失われ、文字をAutoに任せれば輪郭がぼやける可能性があります。モード名だけで決めず、元画像の目的が階調なのか輪郭なのかで選ぶのが実用的です。

調整項目には明るさの反転、しきい値、拡大縮小時のフィルター、ストローク回復、ストローク拡張があります。READMEの例では、黒文字ならBinaryと反転、Nearest、低いしきい値、線が細い場合は回復と拡張を組み合わせます。低コントラストの写真はAutoとBilinear、明るすぎる画像はしきい値の調整が候補です。どの設定が常に正解かを決める機能ではなく、入力ごとにプレビューを見てマスの残り方を確かめる道具です。

細い線とノイズをマス目の単位で整える

GitHubのヒートマップは、元画像のピクセルをそのまま保存する場所ではありません。細い線が一つのマスに吸収されると消え、暗い背景のノイズは意図しない緑の点になります。Binary stroke recoveryは弱くなった線を戻す方向の調整で、Stroke dilationは線を太らせる調整です。二つを上げれば視認性が増す一方、文字の隙間や図形の細部が埋まるため、値を大きくすれば改善するとは限りません。

Nearestは輪郭を保ちたい文字や線画に向き、Bilinearは写真の階調を穏やかにまとめる選択です。READMEは、露出過多、低コントラスト、騒がしい背景を失敗例として挙げています。ここから読み取れる判断は、変換前のトリミングや背景整理も結果に影響するということです。アプリ内のパラメーターだけで元画像の問題が消えるわけではないので、まず不要な余白を切り、目的の輪郭が見える素材を用意するほうが効率的です。

配置操作とコピー機能が作業を短くする

GitHubの個人アクセストークンでログインすると、画面左上にアバターと名前が表示されます。その後、カレンダー上をドラッグしてパターンを配置します。右クリックはブラシと消しゴムの切り替えに使え、ブラシ強度を変えることで緑の濃淡も選べます。マウス操作で一マスずつ直す場面を残しているため、変換結果を確認してから局所的に削る、濃くするという仕上げができます。

同じ図形を複数置きたいときはCopy Modeを使います。範囲をドラッグしてCtrl+Cを押すと選択部分をコピーし、左クリックまたはCtrl+Vで別の位置へ貼り付けます。貼り付け前には選択パターンがマウスに追従するプレビューが出て、右クリックで取り消せます。最後にコピーした図形をCtrl+Vで戻せるという説明もあります。コピー機能は画像編集ソフトのレイヤー操作ではなく、カレンダー上のマスのまとまりを再利用するための機能です。

PAT、リポジトリ公開範囲、表示遅延を先に確認する

完成したデザインはCreate Remote Repoからリポジトリ名と説明を設定し、公開または非公開を選んでGenerate & Pushを実行します。アプリがリポジトリを作成してプッシュするため、GitHubアカウントへの権限とPATの扱いが利用条件になります。READMEはPATの取得方法を別文書へ案内していますが、トークンをどこへ保存するか、必要な権限が何か、既存リポジトリを上書きするのかまでは、このREADMEだけでは判断できません。使う前にそこを確認すべきです。

プッシュ直後にプロフィールのグラフが変わらなくても、処理失敗とは限りません。READMEはGitHub側の表示に5分から2日かかる場合があると記しています。非公開リポジトリを使う場合は、プロフィール設定のInclude private contributionsを有効にする方法も示されています。これは表示条件の案内であり、どのコミットが確実に数えられるかをGreenWallが保証する説明ではありません。初回は非公開の検証用リポジトリで、権限、表示範囲、アカウント設定を切り分けるのが安全です。

OS別の起動条件と署名なしmacOSアプリの扱い

WindowsとLinuxについて、READMEはダウンロードしたアプリを直接実行すると説明しています。macOSでは未署名のため、初回起動時にセキュリティ制限が出る可能性があります。案内されているのは、アプリのあるディレクトリへ移動してからxattrで属性を変更する手順です。sudo xattr -cr ./green-wall.app、続いてsudo xattr -r -d com.apple.quarantine ./green-wall.appを上から試し、解決した時点で止めます。

この操作はアプリを起動するコマンドではありません。READMEも、属性変更の後に手動でダブルクリックする必要があると注意しています。コードはローカルのファイル属性を変えるため、配布元とファイル名を自分で確認してから実行するべきです。なお、説明中のディレクトリ例とアプリ名は利用者が実際の配置に合わせて置き換える必要があります。署名や配布検証の詳細はREADMEに書かれていないため、macOSでの導入を無条件に簡単とは言えません。

Wailsの開発環境から見えるプロジェクトの境界

ソースから試す場合、開発ガイドはGo 1.24以上、Node.js v22以上、Gitを前提にしています。Wails v2.10.2をgo installで導入し、リポジトリをクローンした後にfrontendディレクトリでnpm installを実行します。開発中はwails dev、ビルドはwails buildで行い、生成物はbuild/bin/に出ます。公開バイナリを使う利用者と、ソースを触る開発者で必要な準備が分かれている点は把握しやすい構成です。

リポジトリのメタデータ上の主言語はTypeScriptですが、READMEのビルド手順はGoとWebフロントエンドをWailsでまとめる構成を示しています。内部のデータモデル、認証情報の保管、画像処理ライブラリ、テスト方法については、記載された範囲からは断定できません。READMEには推薦実績やGitHub Weekly、HelloGitHubへの掲載も記録されていますが、それらは機能の正確さや安全性を検証する資料ではありません。GreenWallは教育、デモ、研究目的と説明され、応募書類の実績を偽るような誤用は利用者の責任だと明記されています。MITライセンスであることも、GitHub側の集計仕様やアカウント設定まで保証するものではありません。

編集部の結論

GreenWallは、GitHubのカレンダーを小さなドット絵のキャンバスとして使いたい人に向きます。写真や文字をそのまま再現する道具ではなく、7行52列の制約とコントリビューション表示の遅延を受け入れ、公開範囲とPATの扱いを自分で確認できる人向けです。採用実績などを装う目的には使わず、まず非公開リポジトリで変換結果、権限、表示条件を試すのが妥当です。

公式情報源

1. Official README
2. Project repository
3. Release notes