keebkaigi2023でPRK_FirmwareにMIDIを実装する話をしました #keebkaigi

松本から帰宅して、しばらく療養生活をしていたため、ブログに書くのが遅くなりましたが、5/11～5/13に松本で開催されたRubyKaigi 2023の前日イベントとして開催されたkeebkaigiにLTスピーカーとして話してきました。

keebkaigi.org

2018年にキーボード会議を開催して以来、最近のRubyKaigiでは何故かキーボード勢として参加している気がしなくもないのですが、これまでゲリラ開催だった突発的キーボードミートアップが、オーガナイザーの手により、一イベントとして独立するようになったことに嬉しさを感じ、日常の多忙さ（仕事・家庭・etc）に二の足を踏みつつも、無謀にLTを申し込んだのでした。

資料もアップしようかと思いましたが、当日はYouTubeチャンネルで中継があり、YouTubeにもしっかり発表記録が残っているため、そのまま流用させてもらいます。
www.youtube.com

発表の意図など

発表内容はLTとは関係なく以前からやろうと思って考えていたもので、選考があるとは聞いていたものの、内容的にACCEPTされる可能性は高いと考えており、LT申込をした時点から実装を開始しました。

当初から目指していた実装目標として、以下のようなものを考えていました。

実際、ギリギリではありましたが、すべての実装が発表に間に合い、無事LTに持っていくことができました。
その分発表資料を練る時間には回せなかったので、そこはまずまず…でしたが、発表自体もあんまり練習もなく一発勝負で臨んだ割には、ほぼ5分ぴったりにLTが収まったのは良かったなと思います。

個人的反省としては、実装したものや背景を紹介するのに必死すぎて、いまいち内容が伝わってなかったんではないかと思いました。
ネタバレを防ぐつもりで、デモを展示の場に出していなかったのも敗因ですね。

次の日以降RubyKaigiには、デモ機（iPad）とキーボードの最小構成デモを持ち歩いて、作ったものをプレゼンし歩いてました。

開発の裏側

MIDI自体は非常にシンプルなパケット（2～3バイトの組み合わせ）なので、Ruby<->C言語のブリッジを書いてしまえば、後はRuby側でパケットを作って配列を渡すだけで良く、さほど苦労もなかったのですが、一番苦戦したところは、MIDIデバイスとしてPRK Firmwareを認識させる、というところだったりします。

PRK Firmwareは複合デバイスとして作られており、キーボード以外にも（マウス・ジョイコン等の）HIDデバイス・シリアル通信・ストレージデバイス（PRK Drive）などとしても振舞うため、複数種類のデバイスクラスを持っており、ここにさらにMIDIデバイスクラスを追加する、という改修を入れました。MIDIデバイスクラスのサンプルを参考に実装したのですが、当初は全くUSBデバイスが反応しなくなり、そのたびにpicoprobe（デバッグモニタ）とキーボードを繋いで、gdbでデバッグをしてました。

Windowsで開発していたのでUsbTreeView.exeも役に立ちましたね。おかげでUSBディスクリプタがバイナリのままでもある程度読めるようになりました。
infinitegra.co.jp

USBディスクリプタが正しく動くようになったとしても、その後ブートしてRubyVMが立ち上がり、そのうえでRubyのバイトコードが動くようになるまでデバイスとして表示されることはないため、暗中模索で本当にこれで大丈夫なんかいな…と不安でした。gitのコミット日付によるとMIDIの実装を完了したのが4/16で、実際動作して、ドレミファソラシドが叩けるようになったのは4/30らしいです。ギリギリすぎますね。

MIDIデバイスとして動作するようになってからは、シリアルコンソールが動作するようになったため、デバッグが大幅に楽になり、残りの実装をGW中に終わらせました。
ほぼすべての休日をこれに充てていたので、家族には感謝です。

当日の話

　当日はLTが終わるまでは多少の緊張はあったものの、デモも事故なく終えることができました。他の方の発表もみんな色んな着眼点を持っていて聞いていて楽しかったです。
　好きなものにかける情熱の話は聞いていて楽しいですね。そこに人が集い、新たなコミュニティが生まれるというのはとても心地よく感じました。

　私もMIDI方面で、これまでお話したことがなかった方たちとお話しする機会を沢山いただき、RubyKaigi中を含め、楽しい時間を過ごすことができました。
　オーガナイザーの皆様、お疲れさまでした＆ありがとうございました。

After Keebkaigiの話

　東京に戻ってきて、いくつかやり残したことがあり、土日で片付けてました。
　Keebkaigi前にこの発表で使用したコードを事前にDraft PRを出していたのですが、これをちゃんと本PRにしようかどうか悩んでました。

github.com

　取り込んでもらいたいのは山々なのですが、既存のキーボードクラスにがっつりと食い込むうえに、リソースを食うので、やるにしても環境変数をつけてビルドするオプショナルなやり方かなぁ…と。QMK Firmwareもコンパイル時にMIDI使用のオプションで振り分けるやり方ですし。
　最近SQLiteの取り込みがPICORUBY_SQLITE環境変数を使ったオプショナルになったっぽいので、それに倣おうかと考えてます。

　このPRを提出した際に、case whenのwhenを大量に書くと落ちる、という問題があり、それを解消する必要があったのですが、prk_firmware作者のhasumikinさんとお話しして、Debug print有効化のオプションがあることを教えてもらい、この土日でオプションを有効化して調査したところ、parserのstackがオーバーフローしている問題に関連していることが分かり、現在サイズの拡張を提案中です。

Syntax Error at case / when statement · Issue #145 · picoruby/picoruby · GitHub

　ただ、このスタックサイズの拡張で問題は解決したのですが、PRK Firmwareに持っていったときに、またしてもRubyVMが立ち上がる前にファームウェアが死ぬという問題に当たってしまい、まだ原因の特定に至っていないのですが、安易なスタックサイズの拡張でいいんだろうか、という迷いもあります。この話に決着をつけたら、ようやく自分のKeebkaigiが終わりそうです。

　次は発表の内容にも書いていたように、次は手元のMIDIキーボードをPRK Firmware化するのにチャレンジしようかなと思います。

おまけの話

あと、もう一つ電子楽器周辺の話をもうちょっとしたかったなと思っていて、自分のトークでは語りきれなかったのですが、もし興味持った方のため、自分の推しのYouTubeチャンネルを紹介しておきます。

Jay Hosking氏、プロのミュージシャンですが、ライブ演奏を動画で公開してくれてて、見てると一日時間が解けます
www.youtube.com

Geoffroy AULAGNER氏。まだチャンネル登録者数は少ないですが、最近YouTubeで定期的にプレイ動画を上げてくれてます。
使ってる機器は自分とほぼ同じなのですが、ぐっと引き付けるメロディラインがいいですね。こういうの聞くとセンスの世界だなと思います。
www.youtube.com

近況と今年買ったものとか。

　この記事は、Rubyis近況(1) Advent Calendar 2021の10日目です。

転職し（て）た

　もう2年前のことになりますが、2019年の9月に株式会社メドレーという会社に転職してました。
　やっている仕事は、医療関係プロダクト開発なのですが、入社時からやっている長期のプロジェクトに関わってます。まあ、それはまた別の機会にでも。

　こっそりここにも出てます。

www.ruby.or.jp

表参道.rbをオンライン開催にして1年が経った

omotesandorb.connpass.com


　表参道.rbという毎月第1木曜日にRubyistが集まってワイワイするコミュニティの運営をやっていました。転職して職場は表参道ではなくなったのですが、表参道.rbには毎回出てました。
　ところがコロナ禍になり、集まって開催という形式が難しくなり、一旦休止していたのですが、コロナ禍が長引きそうなのと、再開しなければコミュニティとして再び立ち上げるのが難しくなるのではないかと思い、2020年11月からZoomでのオンライン開催に移行しました。

　人数はオフライン時に比べて少なくなりましたが、毎回、参加してくださるメンバーにも恵まれ、無事に一年間継続することができました。参加してくださる皆さんには本当に感謝しています。また、オフラインで開催できる日を望みつつ、それまではオンラインでコミュニティを維持していきたいと思いますので、引き続きよろしくお願いします。

家を買った

　元々コロナ禍前から探していたのですが、あまり決め手がなく、コロナ禍の状況になりいよいよそろそろ決めねば、と思い、家探しを本格的にやりました。「土地＋注文住宅」「新築建売」「中古戸建」「新築マンション」「中古マンション」全部のパターンを見に行ったりしてました。
　購入に至るまでの決定プロセス（メリット・デメリットや、購入から返済完了までに関係してくる金銭関係の細かいパラメータなど）は知見なので、どこかにまとめたらちょっと話題になるぐらいの記事を書けるような気がするのですが、まあそれはまた人生に余裕がある時に…。


　結局ライフスタイルや出口戦略を考えた結果、自分に合っているのは新築マンション、という結論になり、駅近の新築マンションを買いました。
　井の頭線 → 中央線ユーザになりましたので、最近Rubyistが多く生息していると思われる三鷹近辺の人はよろしくお願いします。（近所です）

音楽を始めた

　元々写真やキャンプを趣味としていたのですが、コロナの状況ですっかり外に出かける機会が少なくなり、キャンプは家族キャンプメインで継続しているものの、写真を撮る機会がすっかり少なくなってしまいました。

　その代わりの趣味として、音楽を始めました。
　元々子供のころにエレクトーンをやっていた関係で、多少譜面が読める、コードが分かる、手が動くぐらいのレベル感だったのですが、本格的に再開しようと思って、物置に眠っていたシンセサイザーを引っ張り出してきて、練習再開することにしました。

　いつもなら、しばらくすると飽きて、再び物置に戻るところなのですが、今回は珍しく1年半以上続いていて、その要因の一つがSimply PianoというiPhone / iPad用のアプリです。（Android版もあります）
　これは譜面が読めない初心者からバイエル修了程度までの練習コースが用意されていて、iPhoneとキーボードをMIDIケーブルで繋ぐと、譜面と押した鍵盤が連動して、音楽の練習ができるというソフトです。1年間7000円程度のサブスクリプションですが、直接習いに行くのに比べて時間の制約がないのと、ゲーム感覚で練習が進められるので効果は大分実感していて、今は2年目の課金をしてます。もうすぐすべてのコースの履修が終わるので、そしたら、改めてピアノを習いに行くのもいいかなと思ってます。

　そして、引っ越しに合わせてシンセサイザーを新調しました。

　前の職場の同期と月一でオンラインで集まって、セッションやったり、これもコロナ禍での精神安定に大分貢献しているなぁと思います。

今年買ったものとか

　家関係で家具・家電を一新したので、それを含めると遠い目になるのですが、一旦そこは脇に置いて、今年買ったガジェットなど。

SONOS Amp

　引っ越しに合わせて、アンプを新調しようとしてました。
　以前使っていたのはONKYOのCR-N755というインターネットラジオに対応した小型アンプで、買ってから8年間一度の故障もなく動き続けてくれた名機なのですが、新しい環境では奥行き的に厳しいこともあり、新しい小型アンプを探しました。BOSE 125というスピーカーを繋げており、こちらは10年使ってますがまだまだ元気なので、このスピーカーを十分に鳴らせるだけの出力も必要です。

　結局YAMAHAのWXA-50と悩んだのですが、世代的にもWXA-50より新しく、WXA-50を使った人が次に乗り換えるのがSONOS ampの人も多そうなので、こちらを選択しました。
　SONOS oneとかSONOS moveとかつけてサラウンド環境とかも作ってみたいのですが、サラウンド対応のコンテンツがあまりない上に、どちらも割といい値段するので、しばらくはステレオで我慢しますｗ

Orbi mini + NVR510

　マンションの回線業者をこちらで決めることができないので、あまり期待していなかったのですが、各部屋に独立した光回線が来ているということで、測定してみると上下600Mbps出ていて、嬉しい誤算。IPoEにするともっと早くなるんじゃないかと思い、それまで使ってたNVR500はMAP-E非対応だったため、NVR510にしてみました。

　一応速くはなったのですが、まあ微々たる差でしたね…。（遠い目）

　また、引っ越しに合わせて部屋のWifiをWifi6のメッシュネットワークにしました。
　比較がないので効果が分からないのですが、今のところ誰もWifi切れたと言わないので、きっと効果はあったと思う。

iPad Pro 11inch

　なんかヤマダ電機で最新のM1搭載のiPadが安かったので、前々から欲しかったのもあり、そのまま勢いで買いました。
　使用用途はほぼ、先述のSimply Pianoの譜面台とあと実家とのテレビ電話用途ですね。（Center Stage便利）


　結局この後Magic Keyboardも買いました。

NIKKOR Z 24-200z/f4-6.3

　いつまでもNikon Z7にFTZつけてFマウント使うのもなぁ…と思っていて、そうはいってもFマウントで大体の画角カバーしているし、Zレンズに載せ替えるモチベーションが沸かない…ということで、用途の被ってない便利ズームを初のZマウント用のレンズとしてお迎えすることにしました。

　便利ズームなので、凄い写真が撮れた、とかそういう感動はあまりないのですが、しっかり仕事をしてくれる良いやつです。

LUMI keys

　買ったのは2020年のブラックフライデーだったので、正確には去年なんですけど。
　Seaboardとか作っているROLIという音楽メーカーが光るMIDIキーボードを作ったということで、Seaboard Blockとも連結可能ということで、購入しました。

　この後、ROLIの経営母体は倒産しちゃうわけなんですが、LUMIは新しい会社に引き継がれる模様。なんか予感めいたものを感じて去年Seaboard Blockを買ったんだけど、予感的中しましたわ…。

Home pod mini

　元々リビングの天井から2個吊るしてステレオスピーカーみたいにしようと思っていたのですが、新居のテレビに購入したBravia XRが十分なレベルのスピーカーを持っていたので、お試しで先行して買ってた1個が完全に浮きました。今は風呂場脇のコンセントにくっつけられて、出かけるときに時間と天気を聞くぐらいにしか使われていない、もったいない使われ方をしています。

iPhone12 mini

　それまでiPhoneXSを使っていて、miniサイズは欲しかったけどあと1，2年は使うぞ、と思ってたところに、iPhone12 miniの売れ行きが悪いから、iPhone13 miniはでないかも、みたいなことを言われて、慌ててiPhoneXSを下取り交換に出してiPhone12 miniを買ってしまった。

　結局iPhone13 mini出てるじゃん。

NOVATION Circuit mono station

　Omnisphere2のハードウェアインテグレーションを試してみたくて、お試しに買った。
　MIDIコントローラとしての使用がメインなのですが、スタンドアロンのシンセサイザーとしても使えるので、そっちでも使いこなしてみたいのですが、中々難しい。

Ableton Live 11とか

　ブラックフライデーの割引に合わせて購入。去年Ableton live 10 introを買ったけど、クロスグレードもできるみたいなので、Standard版にクロスグレードした。MPE（先ほどのROLIに代表される楽器、詳しい解説はこちらのページを見てください。）対応が目的の機能だったのだが、それならまたIntro購入でも良かったのではないかと思うこともあり…。まあいいや。

　最近、フィンガードラムもやりたいなと思って、ドラム音源のAddictive Drums2もブラックフライデーで合わせて購入。
　入力デバイスは現在選定中です。

まとめ

　そんな感じで元気でやってます。
　またみんなで集まれる日が来るといいですね。

　次の、Rubyis近況(1) Advent Calendar 2021はHolyGrailさんです。

分割キーボードについてのお話

この記事は、OIT Advent Calendar 2018の10日目の記事です。

自己紹介

　Kirika_K2という名前でTwitterやってます。2000年入学・2006年卒のOBです。

　あと最近2年に1回、OIT大学院で教鞭を取ってます。
　もはやこのブログは、年1でOIT Advent Calendarを書くだけのブログになってしまった。

kirika.hateblo.jp
kirika.hateblo.jp

　最近は株式会社ビジネスバンクグループという会社でCTOをやっています。もしRuby・Rails・Docker・Kubernetes・TypeScript・Angular等の技術領域に興味がありましたら、声かけてください。エンジニア募集中です。
qiita.com

自作キーボードという沼の話を書きます

　2018年は自作キーボード、分割キーボードという話が賑わった一年でしたね。
　私も例外に漏れず、Ergo42とHelixというキーボードに手を出しました。（ちなみにHelixはまだ未完成）

自作キーボードとは

　メーカー品を買わず、基盤・キースイッチ・キーキャップ・マイコンを調達し、半田ごてを片手に自分でキーボードを自作することを指します。2,3年前ぐらいから海外では話題に上がっていて、私もチャレンジしたいと思っていたのですが、半田ごてに苦手意識があったのと、海外から輸入してまでやりたいというモチベーションがなかったので、羨ましく眺めているだけでした。

　昨年の年末ぐらいから、日本でも自分で基盤を設計してキーボードキットを販売される方が増えてきまして、日本でもメジャーなジャンルとなってきました。私もそれを機に、キーボード基盤を入手し、自作キーボードにチャレンジしました。

f:id:Kirika:20181209234824p:plain
こういうやつです。（写真はErgo42）

自作キーボードが普通のキーボードと違うところ

　自作キーボードは普通のキーボードと違って以下のような特徴があります。

  • （一部の例外を除いて）少ないキーで構成されている

　通常のキーボードは、テンキーを除いて100個程度のキーで構成されますが、自作キーボードは60％キーボード、40％キーボードと呼ばれたりしますが、通常の60％、40％でキーが構成されています。そのため、すべての文字を打つには1文字1キーでは足りないため、モディファイアキー（Fnキー）との同時押しでキー数を補完します。

　市販のキーボードはモディファイアキーは通常用意されたものしか使用することが出来ませんが、自作キーボードは理屈上すべてのキーにモディファイアキーを設定することが出来ます。例えばLet's Splitは左右24キーずつで合計48キーしかありませんが、理論上24（モディファイアキー）×24キーで最大576通りの入力パターンを生成することが出来ます。
　もちろん生成できたところで使いこなせるわけがないので、モディファイアキーの同時入力は覚えられるだけにします。私は5個（記号入力・数字入力・ファンクションキー・Fnキー・マウス入力）にしています。

  • （多くの場合は）分割されている

　自作キーボード＝分割キーボードというわけではないのですが、大抵の自作キーボードは左右に分割されています。分割していると打鍵する時に肩が開くため、肩こりしなくて良いなどと言われることがありますが、自分はあまりキーボードを打っていて肩こりになったことがないのでよく分かりません。ただ、分割しているキーボードを使いこなす姿はかっこいいと思います。（小並感）
　また、分割されているとキーボードの間にトラックボールマウスや、Magic Trackpadを置くことができるので、ノートPCと同じような操作感を得ることが出来ます。

  • 普通のキーボードでは考えられないキー配列を作ることができる

　LinuxやMacでもキーバインドを変更するツールはありますが、自作キーボードではファームウェアレベルで振る舞いを規定することが出来ます。そのため、普通のキーボードでは考えられないような配列を作ることが出来ます。
　元々普通のキーボードでは、qwerty配列という配列が一般的ですが、これはタイプライター時代にまだ上に直接印字していた時代に、キー同士が絡みにくいように作られた配列で、わざと打ちにくく出来ています。
　他にもDvorak配列など、打ちやすさに特化した配列が過去にも提唱されている他、自作キーボード界隈でも新たにいくつか新配列が提唱されています。（打ちやすいかどうかは個人の感想による）

  • キー軸・キーキャップや基板設計、ケースデザイン等、カスタマイズが無限

　キー軸はCherryMXや互換品、果ては市販のキーボードから剥がして来るなど、沢山の選択肢があります。
　キーキャップもCherryMXタイプのキーキャップなら大抵刺さるので、無限の選択肢があります。

　また、LEDを取り付けることでバックライト加工（キースイッチの裏側にLEDを仕込む加工）やアンダーグロー加工（キーボードの裏側にLEDを貼り付ける加工）ができるため、ここにも無限の選択肢があります。

　ケースも3Dプリンタなどで独自のキーボードケースを設計したり、アクリル加工で作ったり、黒壇などの高級木を使ったキーボードなど、こだわり始めるとキリがありません。
　行き着く最終地点は、CADを使って自分の考えた基盤を設計することです。
　
　元々HHKB Pro2を使っていたので、そこそこ良いキーボードを使っていて、今でも不満はないのですが、10年近く同じキーボードを使ってきたので、そろそろ飽きてきたというのはあるような気がします。また、自作キーボードという最終的に自分が求めるキーボードを追い求めるというところに、ゲームのやりこみに似たようなものを感じています。

デメリット

　PCの自作と同じで、キーボードの値段としては割と高く付きます。
　私が今使っているErgo42と呼ばれるキーボードで、大体2万円といったところでしょうか。
　あと、これもPCの自作と同じなのですが、1個作ると大抵部品がちょっと余るので、その余った部品で2台目が爆誕します。完全に沼の入り口です。

やってみたい？

　これをみて、興味あると感じた方は今年の自作キーボードアドベントカレンダーを読んでみましょう。

adventar.org

　私も積んであるHelixを早く完成させようと思います。
　それではまた来年。

大学院卒業して社会人11年半やって来た総括とこれからの話

この記事は、OIT Advent Calendar 2017の10日目の記事です。

自己紹介

　Kirika_K2という名前でTwitterをやってます。
　2000年入学～2006年卒業、社会人12年目で、今でも大学に年3回は行っている東京在住のOBです。
　次に行くのは恐らく2/10に行われるであろうF研の卒研発表会です。

　ちなみに今日(12/9)は関東OIT忘年会があり、23時半ぐらいまで30人弱の人数で銀座で飲んでました。日が変わったころに家に帰ってきて、その勢いでこの記事を書いてます。現時点で東京にいる人、もしくは来年以降東京に来る人は声かけてくれたら、参加方法回しますので遠慮なくどうぞ。

このエントリは何か？

　奇遇にも、今日はhayatedayon、fox_twittingに続き3連続でHxSのOBがAdvent Calendarを書くことになって、二人とも技術ネタで攻めた記事を書いてくれてるのですが、自分の記事にはタイトル通り、昔話とエモい話しかないです。今年は別のAdvent Calendarにも参加していて、そっちで技術ネタは吐き出しているので、技術ネタが好きならそっちを見てください。

qiita.com

新卒で入った会社に11年半いた

　調べようと思うと一発で分かりますが、大手のSIerに11年半ぐらいいました。
　SIerというのは一般的にはあまりよくないイメージが出回っていますが、自分のいた部署は研究開発部署だったこともあり、俗世のSIerとは大分ずれた感覚で仕事をしていました。具体的には今後流行る技術をいち早く身に着けて、その数年後に現場から必要だと言われたタイミングで無双するようなイメージ。その時には、もう次の新しい技術の探求をしているわけなので、今更この技術か…という場面もなくはないのですが、そこそこの社交性が功を奏したのか、現場・お客さん・上司からも信頼してもらえて、とても居心地が良かったです。

　入社直後からどんなことをやっていたかを、振り返ってみたいと思います。

入社直後

　入社直後に一番初めに配属された部署は、世の中の市場に出回っているベンダーの製品を評価する部隊でした。自分はそこでJavaも買収した某O社のデータベースの新機能や新製品を2年ぐらい評価してました。これはこれで楽しかったのですが、これについては自分のやりたかったことではなく、単に入社前にO社のデータベースの資格を持っていたことが原因だと思っている。ちなみに授業で資格試験を安く受けるための割引チケットを貰ったから、受けたら受かったというレベルで別にO社のデータベースが好きというわけではない。
　が、なんだかんだでO社のデータベースの資格はGoldまで会社の金で取らせてもらった。とても感謝。（大体50万ぐらいかかる）

社会人3年目

　入社3年目から自分が本来やりたかった部署に配属されて、そこでは現場を回って、技術力の怪しいプロジェクトを重点的に助ける仕事をしていました。基本的に自分の部署は専門領域を持った人がそれぞれの守備範囲を守っている感じなのですが、たまに誰にも取れないような質問とかがあったりして、比較的時間に余裕のある自分が拾って、調査して対応したりしてました。入社前からも色々やっていたこともありますが、OS・ミドルウェアのレイヤーからWeb・フロントエンドまで一通り戦える知識を身に着けたのはこの頃で、それは今でも自分の強みだと思ってます。

社会人4年目～9年目ぐらい

　そんなことをしていたら、当時の部長がRubyをやる新しい部署を立ち上げるから、参画して欲しいと言われて、参画することになりました。
　当時2007年ぐらいにRuby on Railsが流行り始めたばっかりのころで、その時自分はRuby on Railsで、当時対抗のような扱いだったPerlのCatalystという技術を触っていたのですが、Perl書けるならRubyも書けるだろ？というノリでRubyをやることになりました。ちなみにその時のRubyの経験は、学生時代にmod_rubyを動かして、tDiaryを動かした程度の知識。
　殆どゼロからのスタートでしたが、Perl書けるならRuby書けるだろ？という見立ての通り、半年もすればRubyで楽しくお仕事をできるようになりました。
　この部署はとても思い入れの深い部署で、部長がある日突然Nintendo DSを持ってきて、「これで何か面白いものを作れ」と言われたり、某自動車工場に連れていかれて、当時はまだ珍しかったNoSQLを使って技術的にかなり攻めたシステムを作ったり、公官庁の大規模システムをRubyで書いたり、Javaでは作れないと白旗を上げたシステムをRubyで作り直すという火消しを1年ぐらいさせられたり、現場経験値をかなり積ませてもらいました。

　役割的にはシステムのアーキテクチャを考えるという仕事で、開発メンバーの技術力などを見極めながら、どこまでフレームワークやライブラリ側で担保するかという線引きをするのが面白く、仕事時間以外でもずっと仕事のことを考えているようなとてもやりがいのある仕事でした。
　他にも社外へのアウトプットやコミュニティとの交流など、この頃頑張ったことが人脈面でも知識面でも大分貯金になっていて、今楽に仕事ができているような気がします。
　この部署で5年ぐらい仕事をしていたのですが、当時の部長が某社に引き抜かれて部署ごと解体され、自分はかつての古巣に戻ることになります。

～現在

　で、現在はなにをやっているかというと2013年ごろに炎上プロジェクトの火消しを1年ぐらいやってた時に、DevOpsというキーワードが流行り始めていて、これは将来的にはSIerの分野にもやってくるな、と思って2015年ぐらいから準備していたのが今現在の仕事になってます。

　これは元々自分が会社の中で最後の仕事にする予定だったもので、今の仕事自体はまだ先の未来図があるのですが、自分が実現しようと思っていたことは、大体実現したので思い切って退職することにしました。

総括とか

　
　元々同僚・後輩含めて、5年で辞めるだろうとか色々な言われようで、実際退職することになっても「思ったより遅かったですね」という反応でだれも驚かない始末なのですが、上に書いた通り、仕事はとても充実していて、色々なものを吸収できました。元々大学時代はベンチャーに行きたいベンチャー志向でしたが、就職課の某さんに「一度は大手に行ってみてもいいんじゃない？」と言われ、ちょっと大手を覗くだけのつもりでしたが、色々人との関係が深くなりすぎて、結果的に11年半いることになりました。
（後悔はないが、このアドバイスに関していえば、完全に就職課のポジショントークなんじゃないかと思っている。）

大手企業に行くことのメリット

　ここを学生に伝えたくて、事細かに書こうと思ったが、あまりにも下世話すぎるので消しました。ごめん。
　オブラートに包んで言うと安定面、収入面、ネームバリューではメリットがありますが、その代わりに自由さが失われます。どういう自由が失われるのかは、入ってみればわかる。
　あと体力面が強いのはでかいと思っていて、ベンチャーだと数社分吹き飛びそうな赤字が出ても、他が利益を出してくれてるから耐えることができたり、自分は該当しなかったけど、仕事が嫌になっても、部署を変えれば解決するので、会社を辞める必要がないというのは強みだと思う。あと、新卒の会社同期というのは高校・大学に続いて最後にできる同級生の友達に近いものになると思う。
　詳しく聞きたければ、TwitterでDMを飛ばしてくれれば答えます。

これからの話について

　12/31で現在の会社を退職し、来年1月からは経営コンサルティングの会社が立ち上げたWebサービスの事業に参画し、そこでCTOという職種で働くことになります。そこで上場を目指して頑張ることになります。

　きっと大手企業とは違った別の苦労はあると思うのですが、頑張って乗り越えていきたいと思います。
　ここについてはもし何かの機会があれば続きを書きます。

最後に

　なんかもっといろいろ書く予定でしたが、実際文章に起こしてみると過激すぎて書けないことも多く含まれていたことに気づいたので、ブログに書くのはここまでにします。もっとローカルに話を聞いてくれれば、いくらでも答えるので、気になる人はコンタクト取ってください。

嫁を作る技術

この記事は、 OIT Advent Calendar 2016の10日目の記事です。

　3年ぶりにブログを書きます。しかもAdvent Calendar。OITでAdvent Calendarをやろうという文化ができるのは本当にいいことだと思う。

Who are you?

　Kirika_K2という名前でTwitterをやってます。
　一応OIT Advent Calendarなので、OITとの関係を記しておくと2000年入学、2006年修士卒、HxSコンピューターサークル5代目代表です。現在はとあるSIerで研究職のような仕事をしています。（あと学祭の時に大量にハンバーガーを買い込むという意味の分からない伝統を始めた張本人でもある。本当に申し訳ない。学祭でサークルのブースに立ち寄った時は、資金援助させてもらうので、それで許してほしい。）

　今年はOITで大学院の講義を１つ受け持った関係もあって、odan君と繋がりができたので、Advent Calendarに書くことができました。今でも年3回は大学に行き、大学とはつながりを持っている身ですが、現役生に声をかけてもらえるのはとても嬉しいです。東京に来たときは声をかけてくれれば、ご飯ぐらいは奢ってあげたいと思う。（ただし現役生に限る）

　あと、こういうのを作ったこともある。今は誰でも編集可能なので、追加したい人は追加してくれると嬉しい。（もう5年前か。これ。）
togetter.com

今日は何の日？

　今日は何の日かというと、Advent Calendarにも宣言した通り、私の結婚記念日である。今年で5周年。
　正確には結婚式をやった日なのだけれども、当日はハッシュタグを作って、参列者がツイートしたりして楽しかったなぁ、と思う。
　ほとんどの人は一生に一回のことだと思うし、譲るところは譲りつつもお互いが納得できる結婚式をみんな挙げればいいと思う。

twitter.com

嫁を作る技術

　さて、本題なんだけど、「嫁を作る技術」といいつつも、本当はボケようと思っていて、Oculus Rift持ってきて、「未来に生きる日本人の嫁の作り方とはこうじゃー！！！」というのをやりたかったんだけれども、さすがに10日ちょっとでそこまでに至りつくには仕事も子育てもFF15も忙しく、結局着手することができなかった。来年に向けての反省としたい。そのため、ガチで、嫁を作る技術を語るしかなくなってしまった。

　ちなみに彼女を作る技術ではなく、嫁を作る技術である。そして技術と言いつつもただの振り返りである。
　そのため、ここには自分の結婚生活における振り返りの駄文が連なっているだけで、他の人に役立つ情報は一切ないかもしれない。

　これはちょっと自慢なんだけど、自分は付き合った期間も含めてここ8年、嫁と喧嘩をしたことが一度もない。結婚してからここ5年の嫁との生活を振り返って、何が良かったのか考えてみたいと思う。

出会いとか

　中高一貫で男子校で、そのままOITに入った自分は基本的に女性と話すという機会が殆どなかった。
　大学に入っても、それは同じで結局まともに話した女性は数えるほどしかいない。中学・高校の友達、大学の友達に関しては、むしろ自分が一番結婚が早かったぐらいで、社会人になったときに、会社の同期に紹介してもらったのが今の嫁である。

　重要なこととして、自分みたいに殆ど女性と繋がりがなかった人間が、女性と知り合うためには、友達の友達、職場で知り合った人、街コンなどの不特定多数のイベントのどれかを活用して出会うしかない。「親方！空から女の子が！」みたいな話や、どこかの田舎の女子高生と体が入れ替わって、お互いのことを深く知ることになるようなアニメのような展開は、まず訪れないので、諦めて積極的に動くべきである。

　当然、最低限の身だしなみとか清潔感のある服装、とかは遵守した上で…である。よく分からなければ、2万ぐらい握りしめて、どこかのセレクトショップに突撃して、話しやすそうな店員に上から下まで選んでもらえばいい。何回かやってると自分に似合う服、似合わない服が何となく分かるようになる。着古したTシャツとかは、首回りがヨレヨレになるので、部屋着として使うならともかく、そういう場で着る服としてはお勧めしない。

　そうすると、次の課題は何かというと、そういう機会があったとして、初対面の女性と何を話したらよいかという問題に直面する。
　ここで一番よくないのは無難にやり過ごすか、何もしゃべらずに終わることである。経験値をあげるために、無難な話題でも無難じゃない話題でもいいから、何か話そう。どうせ、そこで相手がドン引きするのであれば、どのみち長続きはしない。無難な話題としては、出身、相手の趣味等、無難じゃない話題で、いきなりガルパンや競プロの話をしても別に構わないんだけれども、相手に興味を持ってもらえなさそうなら、無理にする話題でもない。共通点を探すのでもいいし、興味津々で聞くもよし。
　会話はあくまでキャッチボールであることをお忘れなく。相手の取れない球を投げ続けても、うまくいかないです。

　そういう意味では、最近はアニメやゲームとかの話題も昔よりは振りやすくなってていいよね。
　あと、同じ趣味同士の接点で付き合うのは、個人的経験だと結構疲れる。
　ただ、共通の趣味があるというのはいいことなので、お互いが一緒に始められる新しい趣味を探すといいと思う。

付き合ってるときとか

　そんな感じで、数か月デートとか一緒に遊びに行ったりして、半年ぐらい遊んでから、交際申し込んで付き合うことになりました。
　経験則的には、出会ってから付き合うまでの時間が短いと、別れるまでの時間も早いような気がする。
　お互い社会人で、相手は休みが不定期だったので、土曜日は夕方から会う、相手の土日が休みの時は旅行に行く。相手が平日に連休があるときは、自分も時々平日に休んで、一緒に旅行に行く、みたいな感じの付き合いで3年ぐらいやってました。

　あと、嫁は元々ゲームが好きだったので、よく一緒にゲームしたかな。モンハンP2Gとか。
　一緒に始めた趣味とかもあります。スノボとか、山登りとか。（山登りは結婚後にヤマノススメ見て、大学の同期と急に始めただけだけど）

一緒に住み始めたときとか

　3年も付き合えば、そろそろ結婚をみたいな感じにもなるんだけれども（自分も相手も年齢的には30手前だった）
　結局付き合う→結婚になるためには何らかのタイミングやきっかけが必要になって、自分はそれが引っ越しのタイミングだった。（社員寮を出るタイミング）
　どうせ引っ越すなら二人で住めるところに、だとしたら両家の挨拶、今までどのタイミングで結婚に踏み切るか、というのを考えるのが馬鹿らしくなるほどあっという間に決まってしまった。ちなみに、結婚に当たっては、二人の意志とかより、親族を含めた調整の方が面倒だったと、補足しておく。

結婚生活とか

　結婚生活においては、お金の管理をしっかりと決めよう、とか家事の分担を決めようとか、まあ色々なサイトでアドバイスがあるんだけれども、自分の場合は共稼ぎで、双方に収入があるので、そこはシンプルで、

・お金は家に決められた額を入れておく。貯金は各自でやっておく。（入れるお金は収入に応じる）
・家事は分担を決めない。その代わり気づいたらやる。お金で自動化できるものはなるべく自動化する（食洗機とか）

　あとは、家族用のクレジットカードを作って、生活用品はそれで買うように。明細の管理は毎月自分がチェックしてます。
　基本的な性格の一致不一致については、結婚前から見ているので、そこが揉めたことはあまりないです。

　あとはお互いの仕事の状況を見ながら、年に数回は旅行に行ったり、お互いがストレスたまらないようにうまくやっているつもり。

今後のこととか

　そんな感じで5年ほどやってきたんだけれども。結婚5年目にしてついに子供が産まれました。
　新しい家族が増えて、子供中心の生活になりつつも、これまで通り夫婦としてうまくやっていきたいと思ってます。

　そんな感じで、結婚記念日おめでとう。俺。これからもよろしく。嫁。

　質問とかあったらコメントで適当に答えます。

大規模開発でも使えるRailsテクニック（１）　変更に強いメソッドを組む

　久々にブログを書きます。

　普段は大手SIerでRuby開発をしているKirikaです。私の会社では4年ほど前からRubyをシステム開発に活用していくように取り組んでいます。当初はお客様、自社の人間を含めてRubyに向けられる視線は非常に懐疑的でありましたが、少しずつ実績を重ね、最近になって、ようやく大規模プロジェクトにも適用出来るという評価が得られるようになってきたと実感しております。

　私は現在Railsフレームワークを拡張して、独自の業務フレームワークを載せる仕事をしておりますが、私が2年間関わってきた大規模と呼べるプロジェクトの中で、Ruby / Railsのこういうところは大規模開発にも使えるよね、と思った点を更新していこうと思います。このブログを参照する方の中には、当たり前のようなことしか書かれていないと思われる方もいらっしゃいますでしょうが、ご容赦ください。

変更に強いメソッドを組む

　フレームワークの仕事でまず重要なのは、開発者にどのようなメソッドを提供するかを決定するところです。ここが決まれば、仮に実装がまだ出来ていなくて空の状態でも開発を進めることができます。開発者がどのように呼び出せば開発がしやすいかを考えるところが重要なのですが、私は呼び出しの箇所をとりあえず以下のように定義しておきます。

def convert(target, options = {}, &block)
  ...
end

　この書き方はRailsの中ではよく見かける書き方なので、知っている人にはあまり目新しい話ではないと思いますが、target引数には処理対象、optionsにはHashを定義して、パラメータの数を自由に増減できるように定義します。私の経験上、メソッドの呼び出しで必須パラメータとなるのは多くても３個程度で、それ以上になると呼び出し側でも煩雑になり、コードの可読性が落ちます。なるべく必須パラメータを減らしましょう。

　どこの開発でもありがちだとは思いますが、大抵最初に取り決めた要件では仕様を満たすことができなくなって、メソッドを拡張していくことになりますが、この形を取っていればoptionsにパラメータを１つ追加するだけで良いので、外部のインターフェースを変更する必要がなく、メソッドの実装をコピペして、別のメソッドを定義する必要がなくなりますｗ（自分の身内でそんなことをする人がいたら鉄拳制裁ですが…。）

　&blockは必ずしも必須というわけではありませんが、引数に開発者が独自にロジックを定義したいというケースはよくあります。Rubyにはlambdaがあるので、optionsの引数の一つとしてlambda式を指定する、という書き方でも良いのですが、可読性を考えるとブロックに指定したほうが見栄えは良いです。ただし１個しか使えないので、大切に使う必要があります。

　&blockを渡すメソッドを書くときは内部でblock.call、もしくはblock.yieldで呼び出します。callはブロック引数の個数をチェックする呼び出し、yieldはブロック引数の個数をチェックしない呼び出しです。開発者がブロックを定義する際にブロック引数の定義を固定したいのであればcall、そうでなければyieldを使うのが良いです。

def convert(target, options = {}, &block)
  ...
  block.call if block_given? # &もしくはblock.yield
end

　他にlambdaを使ったテクニックとしては、パラメータの一要素の型で処理を切り替える、というものがあります。

　例えば、optionsに:messageという引数が使えたとして、当初は静的な文字列を出力するだけで良かったのに、開発が進んでくるとパラメータの値によって動的に値を返さなければならない、というようなケースはよくあると思います。

　例としてconvertメソッドというものがあって、messageオプションには処理が完了した時に出力するメッセージを定義できる、という仕様だったとして、開発者は既に以下のように呼び出している場合を考えてみましょう。

convert :title, :message => "converted!"

　この時、ある機能の呼び出しでは、動的に変更前、変更後のメッセージを動的に埋め込まなければならない、という事が決まった（もしくは発覚した）ということがあった場合のケースを考えてみます。Javaならオーバーロードが使えるので、同じメソッドを定義して解決すると思います。（そして、オーバーロードしたメソッドは大抵実装元がコピペされています。）

　Rubyはオーバーロードがありませんが、メソッドの中で引数の型を判定することで、オーバーロードと同じようなことができます。実装例としては以下のようなものです。

def convert(target, options = {}, &block)
  original = self.__send__(target)
  converted_string = ... # 例えばここで変換処理

  case options[:message].class
  when String, Symbol
    p options[:message]
  when Proc
    p options[:message].yield(original, converted_string)
  end
end

　こうすることで、以下のようにどちらの書き方でも、メソッドは処理してくれるようになります。

convert :title, :message => "converted!"
convert :title, :message => lambda{|before, after|
　"#{before} convert to #{after}" }

　この辺りの書き方もRailsのソースを読んでいたらよく出てくる書き方なので、知っている人は多いかもしれませんね。

　このような実装をするときは、既存のソースコードをどんどん書き換えて行くので、RSpec等を使ってテストドリブンにした方が効率がいいです。

移転しました。

「Kirikaの非人間的生活」を閉鎖し、はてなブログに移転しました。

前の日記は全部インポートしましたので記事はそのまま見られると思います。

 

アンテナについてどうするかは検討中ですが、一時的に取り外しました。

しばらくは利用されたい方はhttp://a.hatena.ne.jp/Kirika/を利用してください。