D言語でクリエイティブコーディングのためのフレームワークarmosを開発している話
はじめに
この記事はD言語 Advent Calendar 2016とクリエイティブコーディング Advent Calendar 2016の記事です．
1年ほど前からopenFrameworksやprocessingのようなフレームワークをD言語で開発しています．この記事では，ざっくりですがその紹介をしていきたいを思います．なお現在のarmosの仕様は暫定的なもので，これから大きく変更される可能性があります．
armos
armosはクロスプラットフォームのクリエイティブコーディングフレームワークを目指して開発されました．言語は，ネイティブコンパイル言語の処理速度と，軽量言語の書きやすさを兼ね備えたD言語を採用しており，シンプルなプロトタイピングから，複雑でスピードを要求されるようなアプリケーションまで柔軟な記述が可能です．画像や音声等の複数のライブラリを統一的なIFでラップしており，開発者はD言語のコードからそれぞれの機能を簡単に扱うことができます．
現在のarmosについては，動作環境については，Linuxと一部のWindowsで確認しており，Macについては未確認となっています．一部グラボによっては描画が正しく行われない，等の環境依存があるようです．機能については，openGLによる描画処理，Assimpによる3Dモデルの読み込み，openALによる3次元音声処理，GLFWによるウィンドウ管理と各種入力デバイスのサポート等が実装されています．これらは工数の兼ね合いから，ライブラリの全機能のラッピングよりも主要な部分の実装が優先されており，あまり重要ではない機能やユーテリティは後回しとなっています．また，今後は動画やフォント，パスの描画等の機能を実装していく予定です．
機能の追加やバグフィックス等がありましたら是非気軽にContributionお願いします:)
サンプルコード
moduleの数がそれなりに多く網羅的な説明をこの記事で行うのは困難なので，armosの基本的なアプリケーションの記述方法を紹介していきたいと思います．
// armosの機能を使うためのimport文． // コード中のどの部分がarmosの機能なのかを明示するためにstaticをつけている． static import ar = armos; // oFと同様にBaseAppを継承してアプリケーションのclassを記述していく． // 基本的なメンバ関数は以下の3つがある． // setup 実行時の最初に一度だけ呼ばれる // update 毎フレーム呼び出される．メンバの更新処理を記述する // draw 毎フレームupdateの直後に呼び出され，描画処理を記述する class TestApp : ar.app.BaseApp{ override void setup(){ // アルファブレンディングを有効にするため，BlendModeを指定する． ar.graphics.blendMode = ar.graphics.BlendMode.Alpha; // Lenaの画像を扱うImage classのインスタンスを生成し，画像ファイルを読み込む． // 読み込みの処理はFreeImageを使用． _imageLena = (new ar.graphics.Image).load("lena_std.tif"); // 同様にD-man(D言語くん)の画像を読み込む． // また，ここでは拡大した際にぼけないよう，テクスチャのフィルタの設定も行っている． // このように，armosで実装されているほとんどのclassやstructはメソッドチェーンで処理を書いていくことができる． _imageDman = (new ar.graphics.Image).load("d-man.png") .minMagFilter(ar.graphics.TextureMinFilter.Nearest, ar.graphics.TextureMagFilter.Nearest); } override void draw(){ // Lenaの画像の一部分を表示． // 第一引数と第二引数は表示位置，それ以降の引数で切り抜く範囲のピクセル座標を指定する． _imageLena.drawCropped(512, 512, 256, 256, 512, 512); // Lenaの画像を0,0の位置に表示． _imageLena.draw(0, 0); // oFやp5にある同名の関数と同様，Model行列を保存(stackにpush)する． ar.graphics.pushMatrix; // Model行列のx, y座標を10倍に拡大する． ar.graphics.scale(10, 10, 1); // 今のModel行列が適応されるので10倍のサイズのD言語くんが表示される． _imageDman.draw(14, 5); // 保存しておいたModel行列を再び読み出す(stackからpop)． ar.graphics.popMatrix; } private{ // 画像を読み込み，表示するためのImage． ar.graphics.Image _imageLena; ar.graphics.Image _imageDman; } } // D言語の標準のエントリーポイント． void main(){ // 上で実装したアプリケーションを実行する． ar.app.run(new TestApp); }
このコードを実行することで，以下のような表示を行うアプリケーションが動作します．
armosには各機能の動作を紹介するサンプルプロジェクトが同梱されているので，詳細はそちらを参照してください．
armos/examples at dev · tanitta/armos · GitHub
特徴
いくつか紹介したいと思います．
oFライクなイベント
armosを用いたアプリケーションを開発する際に継承するクラスarmos.app.BaseAppは，openFrameworksのofBaseAppと同様なメソッドを用意しています．キーボード入力は，現在のキーの状態をすぐに確認できるhasPressedKey, hasHeldKey, hasReleasedKeyが実装されています． https://github.com/tanitta/armos/blob/dev/source/armos/app/baseapp.d
Vector
ベクトルを表すstructです．要素の型と次元をtemplate引数として指定します．各種オペレータのオーバーロードが実装されており簡単にベクトルの計算ができます．
auto v = Vector!(float, 3);
また，Vector Swizzleが実装されており，GLSLのvector.xzのような記法でのプロパティへのアクセスが可能です．
auto vec = Vector3f(2.0,4.0,6.0); vec.yx = Vector2f(0.0,1.0); assert (vec == Vector3f(1.0,0.0,6.0));
他にもVectorを元にしたMatrixやQuaternion等が実装されています．
Shader
openGLのShaderを扱うclassです．基本的なインターフェースはoFと似たものとなっていますが，Shaderのプログラムのattributeやuniformにデータを渡す関数は，D言語の強力なコンパイル時メタプログラミング機能により，データの要素の型や要素数を意識することなく扱うことが可能です．
int d = 1; shader.uniform("distance", d); shader.uniform("position", ar.math.Vector2f(1.0,2.0));
Material
ポリゴンの材質を表す，Shaderとプロパティをまとめたinterfaceで，複数の材質の切り替えやパラメータの管理等を容易に行えます．また，このinterfaceを元にオリジナルのMaterialを作成することができます．
AutoLoadMaterial
上のMaterial interfaceを元にしたMaterialで，読み込んでいるShaderのソースファイルが更新された際に自動的に変更を検知し，再読み込み，コンパイルを行います．これにより，GLSLを用いたライブコーディングが可能となっております．
2Dデータ
2DのデータはImage, Bitmap, Textureの3種類があります．簡単に画像を扱うためのImage classは，ファイルの読み込みから画面への描画をサポートします．画像の読み込みはFreeImageにより行うため，様々な形式の画像ファイルに対応しています．Bitmap structは画像を表す単純なデータ構造で，サイズ分のピクセル情報を持ちます．拡張機能として，ndsliceへの変換が可能なため，複雑な画像処理でも高速で行うことができます．Texture classは，openGL側で画像を扱うためのもので，Bitmapからの変換が可能です．
3Dデータ
armosでの3Dのデータは階層構造になっています．
- 形状を表すMesh class
- Meshと材質を表すMaterialを束ねたEntity class
- 複数のEntityを束ねたModel class
なおModelはファイル名を指定することで外部ファイルからデータを読み込む機能も実装されています（Assimpを使用）．また，MeshとEntityはGPU側で高速に扱うためのBufferMesh，BufferEntityが存在します．これらは，openGLのVBOを用いてデータを管理しており，元のMeshやEntityから簡単に変換することができます（CinderのBatchのような感じ）．
Filter機能
Fbo classのメンバ関数FilteredByを使うことで，表示結果にフィルタをかけていくことができます．引数にはMaterialを指定します．
fbo.filteredBy(invert) .filteredBy(offRegistrationFilter);
D言語でクリエイティブコーディングをするときの便利なパッケージ
D言語で色々やっていくために書きました．
easing
よくあるeasing関数がまとめられたパッケージです．関数を直接扱う際は定義域，値域共に(0,1)ですが，付属のmap関数を用いることで，それらを自由に変更することができます．実装されているeasing関数はパッケージのREADME.mdを参照してください．
import easing; auto output = input.linear; // | // easing function -+ auto output = input.map!linear(0.0, 10.0, 0.0, 1.0); // | | | | | // easing function -----+ | | | | // min of input ---------------+ | | | // max of input --------------------+ | | // min of output -------------------------+ | // max of output ------------------------------+
osc-d
おなじみOpen Sound Control(OSC)プロトコルのD言語実装です．外部のシーケンサ等からarmosのアプリケーションを操作することができるようになります．
実際のところD言語でクリエイティブコーディングってどうなの
D言語の仕様については問題なく快適にコードが書けます．ビルド速度も高速で，試行錯誤のサイクルをガンガン回すことができ，テンプレートをゴリゴリ使ってもそれほど遅くなりません．hppとcppでコードを分ける必要も無く，module機能が実装されているのでincludeの依存関係で悩む必要も無いため，ソースコードの取り回しが非常に楽です，また，昔のD言語はアップデートが派手だったらしいのですが，最近のD言語はそのような破壊的な変更も無く安定しています．言語仕様が洗練されているため学習コストも低く，特にC++erなら非常に楽に学べると思います．
エコシステムに関しては，モダンな言語でよくあるパッケージマネージャとしてdubがあり，プロジェクトと要求パッケージのバージョン依存を管理をしてくれます．ライブラリ周りについては，品揃えはそこそこ充実してきたのですが，どうしてもクリエイティブコーディングのような用途で要求されるような特殊なものは不足してしまうところがあります．また，D言語はCで書かれたコードについては互換性がありますが，一方でC++はそのへんが難しいらしく，そのため，openCVやKinectのようなライブラリがC++で記述されたものについては，一度Cでラッパを書いてそこから呼び出す，等の方法をとる必要があるようです．（なお，openCVについては，同様の画像処理ライブラリとして現在dcvが開発されており，今後が非常に楽しみです）
このように，ライブラリついては若干不安がありますが，言語自体は非常に優秀です．足りないライブラリはガンガン実装してコミュニティに貢献していきましょう！
My First Game Jam: Summer Editionに参加した
久しぶりにゲームジャムやりたいなと思ってIndie Game Jamsを眺めていたら，My First Game Jamっていう初心者向けのゆるそうなイベントを見つけたので参加してきた．
自分は以前にGlobal Game Jamに参加したこと（参照）があるので"My First Game Jam"ってわけじゃないんだけど，今回使ったprocessingでゲームを作るのは始めてだったのでまあ初心者ってことで．
My First Game Jamとは
- 初心者向けのゲームジャム
- ルールはかなりゆるい
- 期間は2週間
- 一人で開発してもよし，チームを組んでもよし
- 普通のゲームジャムと同様，開催直後に発表されるテーマに沿って開発する．
開催までの色々
一人で作るのも寂しかったので，普段から素晴らしい楽曲を書いているOtObOx先生をサウンド回り担当として誘った．「やる？」「やる」的な二つ返事でコトが進んだ記憶がある．フットワークが軽くて素敵だと思う．というわけで，自分がプログラミングとグラフィック担当，OtObOx先生がサウンド担当って感じでチームが決まった．
開催後前半
どんなゲームを作っていくか，SlackとTeamSpeak3で作戦を練った．今回発表されたテーマは"a spin on a popular story/myth"．スピンオンってなんだ．ググりまくった記憶がある．とりあえず日本の昔話系をリストアップした．自分はゲーム作りやすそうだったので因幡の白うさぎをゴリ押しした気がする．サメから落ちたらゲームオーバーみたいな．最終的に竹取物語ベースのシューティングを作ることになった．この時はまだ，月からの使者を迎撃する普通のインベーダ的なゲームを想定していたのであった...
開催後後半
1週間が経過した．「そろそろつくろっか．まあ1週間もあれば余裕っしょ．ハンデハンデ笑」という気持ちで開発が始まった．とりあえず2日間ぽちぽちドットを打ち，もくもくコードを書いて叩き台が完成．設計や実装の美しさを無視した，とりあえず動けばいいコードを乱暴に書き上げていく作業は，背徳感とスピード感があってとても気持ちが良かった．あとは楽曲や効果音を組み込みつつ，難易度を下げる方向に調整していった．
最終日は，時間ギリギリまでテストプレイのフィードバックでクオリティを上げていく作業をした．朝ごはんとして温めた角煮肉まんを電子レンジから取り出す暇が無いほどエクストリームだった．（テスターのみなさんありがとうございました！）13時の提出直前は，バージョンを一つ戻すかどうかで決断を迫られる体験ができた．git rebaseのコマンドをド忘れして激焦った．提出も，イベントのページと別でアカウントが管理されている都合，無事にアップロードできてるのか分からなくて激ヤバだった．
最後は，すっかり冷えきった角煮肉まんをもう一度レンチンしなおして笑顔でおいしく頂けたのでよかった．
できあがったもの
月から地球にやってくる使者のウサギから，かぐや姫を守るシューティングゲーム．前半1週間でOtObOx先生が「弓飛ばそう弓」と言ってた気がするが，実際に実装されたのは，タケヤリにロケットブースタをポン付けした星間ミサイルと，それに作用する重力場であった．射出後に加速するタケヤリミサイルを地球の軌道に上手く乗せて，飛来するウサギを迎撃していく．真上に打ち上げるだけだと，重力が作用してすぐに落下してしまうため慣れが必要．また，タケヤリの残弾数は地上のタケを刈り取ることで回復できる．WindowsとLinux対応．（Macは適当にprocessingでビルドして動かして下さい．）なお，開発途中で名前が"taketori war"から"taketori wars"に変わったため，表記ゆれが非常に激しい．あとdision氏のスコアがオーバーフローしたプレイ動画乗せておきます．
得られた知見
- 相手の作業風景を直接見れないのでリモート難しい．くだらない内容でも良いので連絡をこまめにとると，お互いの開発状況がなんとなくわかって安心．
- 少ないメンバーで迅速な意思決定ができたのでよかった．多くても3人とかがよさ気？
- 実際に作業する人手が不足している．自分がプログラミングとグラフィック両方やるのはちょっと厳しい．どちらかできる人がもう一人いれば...．
- ゲームの難易度は，開発者自身が実装の過程で慣れてしまうため，調整が難しい．自分が思っている以上に下げる，あるいはコアメンバ以外の人にテストプレイをしてもらう必要がある．
- 爆発エフェクトは白黒の点滅を入れると視覚的に威力が上がる．
- 適当なバネモデルで画面を揺らすと激しい肌触りになる．
- 早めの提出
ある日の環境構築
まとめ
linuxで，Radeon(HD5850)+xf86-video-atiでKMSが有効な状態でstartxを実行すると画面が真っ暗になって落ちる，そういうときは，カーネルパラメータにradeon.dpm=0を指定すると解決する場合がある．
ポエム
ある日のこと，メインの開発機のArchでyaourt -Syuでアップデートを行った後，dlangで書いている自前のプロジェクトのビルドを終え，実行したところ以下のエラーが出た．
X Error of failed request: BadMatch (invalid parameter attributes)
— tanitta (@trit_techne) 2016年7月2日
Major opcode of failed request: 42 (X_SetInputFocus)
GLまわりのエラーのようなので，とりあえず可能性として以下の原因が思い浮かんだ．
- グラフィックドライバまわりのエラー
- glfwのライブラリのリンクまわりの不具合
出力の前半にDRIまわりの警告があったため，まず，グラフィックドライバについて調べた．この環境では，プロプライエタリのcatalyst-testをドライバとして使用している．導入の際，要求される他のパッケージやデーモンの設定等で苦労した記憶があるため，このあたりが怪しいと判断した．そこで，オープンソースドライバであるxf86-video-atiによるcatalyst-testの置き換えを試みたが，パッケージの依存性の解決が難しそうだったため，予備として用意していた，グラフィックドライバやxorgを導入する前まで設定を済ませておいた別のパーティションのArchlinuxで，オープンソースドライバのxf86-video-atiを用いた新しい環境を立ち上げることにした．
ところで，今回問題が発生したメインの環境でcatalyst-testを使用していたのは，最初の環境構築の際に，他のドライバの，catalyst，xf86-video-atiでは上手くRadeon HD5850が動作しなかったためであり，また，今のcatalyst-testの導入後に何度か他のドライバでの動作を試みたが全て失敗していた．そのため，今回の試みも正直ダメな予感がしていた．
さて，さっそく新しい環境を整える．まずは，arch wikiにある通り，カーネルパラメータにnomodesetを設定してKMSを無効化，xf86-video-atiを入れる．ここまでは順調だが，その後，KMSを有効にした状態でstartxによりXWindowを立ち上げると，スクリーンに何も表示されなくなる（情弱感）．また，キーボードのcaps lockのランプも，普段は切り替えを行うと点滅するのだが，その反応もなくなってしまう．これまで何度か試みた際もこの挙動が原因でドライバの導入を諦めており，フォーラムを覗いても同様の症状のスレッドはxorg.cfgまわりに原因があるものばかりで，XWindowまわりが怪しいんだろうなーと予想していた．ところが，生成されたXorg.0.logを眺めていると，どうやらnomodesetでKMSが無効になった状態で起動を試みていることを示すメッセージを見つけた．これはnomodesetが指定されていた時に誤ってstartxを実行してしまった時のログであり，タイムスタンプを確認すると，KMSが有効な状態での起動に失敗する以前のものだった．つまり，それが上書きされずに残っている，ということは，startxのログが生成される以前で何らかの障害が発生している，あるいは，startxの処理の中でエラーログが生成されないような派手な落ち方をしている，この2つに原因を絞り込むことができる．そもそも，linuxではシステムがいきなり停止するような場合，ハードウェアに原因があることが多く，また，上で書いたcaps lockのランプが反応しなくなるのも，システムがコケていることを示し，startx後に画面に何も表示されなくなった際にハードに近い部分が不具合を引き起こしている説を補強する．
そこで，カーネルパラメータまわりについてフォーラムを検索したところ，radeon.dpmについて設定すると上手く起動する，とのポストを見つけた．このオプションは，"Dynamic Power Management"と呼ばれるGPUの使用率にあわせて動的に周波数と電圧を変更する機能についてのもので，radeon.dpm=0を設定するとあっさり動いた．最初にxf86-video-atiの導入を試してから2年近くが経過していており，正直なんともいえない気持ちになった．あと，余談だが最新のcatalystでcatalyst-testを置き換えるのも依存が大変なことになったが成功した．ただ，プロプラなので更新が遅く，さらに最近のオープンソースドライバも熟成してきたので，個人的にはxf86-video-atiの方に分があると思う．
無事に念願のドライバが導入できたところで，そもそもの今回の環境構築のきっかけを思い出したい．それは，自前のプロジェクトが実行時にグラフィック回りの警告とエラーが出た，というものであった．この新しい環境でコンパイラや依存ライブラリを整え，実行すると，警告は消えたが同じエラーが表示された．どうやら，グラフィックドライバとは別の，もうひとつの可能性であるglfwまわりについても考えねばならないらしい．ところが，こちらはドライバの問題よりずっとスムーズに解決したので，事の顛末は以下のツイートをもって代えさせていただきたい．
PKGBUILDを書き換え: glfwのsourceを以下のforkに指定して解決https://t.co/qKXoQJaLdq
— tanitta (@trit_techne) 2016年7月2日
これと同様の対応を元々の環境で行ったが，エラーは表示されず上手く動いた．早急にこのPRがmergeされることを祈る．
結局のところ，問題を解決するために新規に開発環境を立ち上げる必要は無かった，という話です．
Global Game Jam Sapporo 2016に参加した
夜にはレッドブルおねーさんが徘徊する会場で，初めて会う人達とチームを組んで，48時間以内にゲームをつくる，そんな素敵なイベントのGlobal Game Jamに，2ヶ月前，参加してきた．
きっかけ
GGJは去年あたりにツイッターで見かけて興味を持った．本当はその年のGGJ2015に参加するつもりだったが，自分のスキルセットが中途半端で見送り．それから一年が経過して，ある程度簡単な言語やライブラリ等を要求されても1周間くらいの学習期間が確保できればそこそこ使える感じになってきたので今回は参加することにした．
できたもの
GGJのサイトはこっち
ゲームとしてはローグライクっぽい方向を目指した．カーソルキーでロボットを操作して，バッテリーを取りながら右下のゴールに到達するとゲームクリア．デザインは，移動や敵との接触でバッテリーが減少するリスクと，マップに散らばるバッテリーを集めることで残量が増加するメリットとのジレンマが生じるデザインにした．
チームの決定
GGJ Sapporoでは，申し込みをする際，手元の開発環境と主なスキルセットをアンケートに入力して提出し，それを元に運営の方がチームを決定する．自分は普段Arch Linuxを使用しているため，共同で開発するとなるとクロスプラットフォームな何かに縛られてしまうのが不安であった．神頼みでアンケートを記入して提出，チームの発表日を待った．
チーム分けが発表されると，自分は「UNIX☆Webチーム」に配属された．キャプションには"OSS好きやオールラウンダーが織り成すUnix衆、ここに結成！ その可能性、外部からは予測不能！"と記されていた．
開発
今回はgithubを軸に開発を行った．全員が既にアカウントを所有し普段から使用していたためぴったり．自分は，作業のルートとなる，ゲームとしてギリギリ遊べるレベルの叩き台をマッハででっち上げる作業をした．プロトタイプを開発するのが昔から好きなので，この作業は本当に楽しかった．その後は，新機能の実装，バグ潰し，ドット絵をぽちぽち打つなどをしていた．他のメンバーについては，ちゃんとスタートからゴールまでたどり着ける迷路生成とゲーム機能，細かいバグのfixなどはyassu氏やnasa9084氏が，レベルデザインといくつかの効果音はhomomaid氏，ランキング等の処理を行うsinatraのバックエンドはmktakuya氏とtosiemon18氏，GGJ終了後も耳に残っていた印象的なBGMと効果音はmanzyun氏が制作．全員に良い具合にタスクが割り当たり，チームとしてガンガン進捗を叩き出せたのでスピーディーで楽しかった．
ドット絵は最近界隈でアツいらしいasepriteというエディタを使用．普通のペイントソフトには無いような，ドット打つのに特化した機能が沢山実装されている．購入に際して，Windows/Mac版で提供されるバイナリは有料だが，よく調べたら自前でgithubからcloneしてビルドする分には無料．正直購入する気満々だったのでdonateしたい．そのくらいオススメ．
会場の様子
自分のチームは部屋がひとつそのまま割り振られた（部屋によっては2チームで共用のところも）．部屋には電源タップが大量に用意されており，タップ持って行こうか迷っていたので安心．ネットワーク環境はそこそこ速かったので良かった．ciscoの機材が転がっており，運営のエンジニアの方曰く，チューンを煮詰めればまだ速度を上げられるらしい．
なお，毎晩レッドブルガールが出現し，缶を開封した状態のレッドブルがもらえる．そのため，背中に羽が生えた状態での作業を余儀なくされ，開発が大変捗った．ちなみに余談だが，それでも会場の自販機のレッドブルは売り切れになっていた．
まとめ
チームが最高で楽しかった．ぜひ来年も参加してみたい．
Linuxの自宅鯖に時報機能をつけてQoLのブチ上げを試みた
生活にリズム感が欲しかったので，自宅サーバのsystemdサービスとして動く，指定の時間にアラームが鳴るアプリをつくった．（ポモドーロの既存のタイマーアプリでも良かったんだけど，いつのまにかアプリのプロセスを消してしまったり，そもそもPC，スマートフォンをいちいち操作して立ち上げるのがめんどくさかったりで，イマイチうまく使いこなせていなかった）今のところ10時から22時までの間，0分と45分にアラームが鳴るのでそれを目安にして45分間作業を，15分休憩って感じで活用している．
とりあえず動いたので記事を書く．
中身
めんどくさいのでrubyで書くことにした．スケジュールを読み込み，mpg321を叩いてアラーム音を鳴らす．
指定の時間にコードを実行するため，systemdのタイマー機能を用いる．このへんの設定はsystemd/タイマー - ArchWikiを参考にして.serviceと.timerを書いた．
なお，リアルタイムタイマーの.timerでのn分毎に実行する設定は
OnCalendar=*:0/n
でできる．
cf. systemd timer every 15 minutes - Unix & Linux Stack Exchange
アラーム音
Windows立ち上げてDAW開いて色々するのがめんどくさかったのでブラウザで動くaudiotoolで3OSCのアナログシンセをいじって適当に作った．騒々しい音だと疲れるので，ゆるめに仕上げた．（audiotoolいろいろ遊べるので暇つぶしにオススメ） www.audiotool.com
future
- スケジュールとコード本体との分離
- googleカレンダーと連動させたい
memo
- 休憩を忘れて無駄に消耗してしまいがちなので，これで改善されてもっと進捗できればうれしい．
- 実生活をHackしていく系，QoLも上がるので良い．
- あと久しぶりに記事書いた．
オープンソースカンファレンス2015 Hokkaidoにちょっとだけ行ってきた
滞在時間20分
この後も予定があったので急いでいたため，適当に地図を見てたら道を間違えて迷子になった．ちなみに帰りも迷子になった．汗をかいて完全に濡れオタク． 展示ブースでは，どこかで見たことのあるかのんくん(@HOMOMAID)にハグされそうになった．ローカルさんの売り子？してたっぽい．元気そうでなにより．あとsapporo.cppなるコミュニティの方とお話した．つよそうだった．最後に，帰ろうとしたらえむけーくん(@mktakuya)から電話で呼び出しをくらってポメくん(@pome_11)とふっくん(@fk2763owl)とお話した．めちゃ楽しそうだった．
感想
OSCに参加するのは初めてだったけど，こんなにたくさんコミュニティがあるとは思わなかった．熱かったです．今後もし機会があったらまた参加したいかも．
まだSlackのサイドバーで消耗してるの？
Slackのサイドバーが邪魔だったしウィンドウを狭くしたら文字がはみ出てたので，そのへんを改善するChrome拡張を作った．
機能
Slackを開いてCtrl+Yでサイドバーを出し入れできる． ウィンドウ幅を狭くしてもテキストが自動改行される．
経緯
Slackのサイドバーが，どこからどうみても消せる機能を搭載してる雰囲気だったので，調べたら以下のページが出てきた．
Slack「Nope, not at the moment at least. Maybe in the future!」
実装まで待つのもだるいので作った．githubで公開した後，サイドバーまわりの挙動を修正するプルリクを@lempiji氏からいただいて，とても快適になった．感謝！久しぶりにgithubした気がする．
