株式会社ドワンゴを退職します(5年2ヶ月ぶり1回目)


2019年8月末で、株式会社ドワンゴを退職します。これは主に社内の友人に向けた文章ですが、一応自己紹介は書いておきます。

私はkinoppydという名前で、2014年にドワンゴへ入社し、Scala/Rubyエンジニアをやっていました。最初に配属されたプロジェクトはニコニコ生放送のScala化プロジェクトで、ニコ生のScala化、ニコ生のHTML5化のお手伝い、公式生放送の老朽化した機能のマイクロサービス化などを行いました。その後はチームを異動し、ニコナレのバックエンド開発に従事しました。

他にも、社内でSlack芸人やBot芸人をやっており、なんか記事にされたりしたこともありました。

【bot、暴走中!】「Slackは福利厚生」と言い切る、ドワンゴ流・Slackの超活用術とは

絵文字コミュニケーション術、サーバーワークスとドワンゴが明かす

趣味はRubyのコードを書くことで、OSS活動としてSinatraライクな書き味のBotフレームワーク Mobb の開発などをやっていたり、技術書典でSinatraのコードリーディング本やメタプログラミングRubyの副読本などを書いていたりしました。次の技術書典では「ActiveRecord完全に理解した」という本を出します。

退職の理由

大まかに言うと、ライフスタイルが変わったためです。具体的に言うと、結婚をしました。

人生にはお金が必要です。ドワンゴからもらっていた給与は、私一人で生きていく分には十分なものでした。しかし、私自身の人生と将来生まれてくる子供の人生の2つを支えるには不十分でした。また、昇給のペースなどを考えても今後私が求める水準に達するにはかなりの努力と時間がかかると思い、転職して給与を上げる決断をしました。

私はとても夜型の人間です。そしてドワンゴには、真の裁量労働が存在しています。成果を出しチームの中で合意があれば、何時に出社しても何時に帰っても何も問題はなく、なんなら一日8時間働く必要すらありませんでした。私は在籍中、月に160時間働いてない月がそこそこあるくらいです。そのため、私は概ね昼の12時から14時の間に出社し、夜の20時から0時の間に帰る、という生活を続けていました。しかし、妻は9時に家を出て20時に帰ってくるという生活を送っており、夫婦間で生活時間の不一致が問題となりました。私は真の裁量労働の権利を持っているので、その時間に合わせて生活すればいいとは思いましたが、努力しても夜型の生活を改善できませんでした。そのため、定時が存在する会社に勤め強制的に妻と同じ時間を生きることを決めました。

また、ドワンゴは2019年2月の経営陣交代以降、事業の集中と選択を進めており、私の所属するチームが持っていたニコナレもクローズの運命からは逃れられませんでした。ニコナレの使っている仕組みの一部をScala化するなどをしていたため、この仕事を離れるとなるとそれなりの引き継ぎが必要でした。しかしサービスのクローズにより、私の持ち物は何もなくなってしまいました。結果としてとても身軽になったことも決断の大きな後押しになりました。

他にもいろいろな理由はありますが、まあこの3つに比べると些細なものです。

思い出

会社では、とても友人に恵まれました。まさか社会人になってからこんなにたくさん友達ができると思っていなかったので、驚きと感動があります。ドワンゴに入ってからの新しい友人に影響された結果様々な趣味に目覚め、今までの人生の中で考えられないほど自分の変化があった5年間でした。ポーカーやロードバイク、創作活動を始めたのもそうですし、そもそも今のメイン言語であるRubyを書き始めたのもドワンゴに入ってからです。ドワンゴは、非常に多種多様な人たちが在籍しており、積極的に関わっていくとプラスだったりマイナスだったりの影響をガンガン受けていきます。

仕事で関わる人達にも恵まれ、多くは良き友人で尊敬できる仲間でした。特に、生放送チームで一緒に働いた先輩と後輩、そしてニコナレチームの上長とチームメイトは、一緒に働けたことが光栄に思えるほどでした。私は本当に幸運で、働いている間に人間関係で困ったことにほぼ出くわすことがありませんでした。後述する理由でドワンゴには大変気難しい人も多い中で、このことは本当に運が良かったとしか言いようがありません。

ドワンゴは、自分の中の感覚で一言で表せば、良くも悪くも十数年前のインターネット・アトモスフィアをだいたい東銀座に再現した会社です。人々はネットでコミュニケーションをとり、その雰囲気は独特で、世間にさらけ出すと微妙な顔をされそうな世界観と価値観がありました。社内コミュニケーションツールのSlackにはその影響が特に色濃く出ており、私にとっては心地よかったけどこの空気に馴染めない人は本当に馴染めないだろうなぁという感じです。他人の認識はアイコンとハンドルで、実際に顔を合わせてもその人の名前すらわからないことも多々あります。Slackで雑談するのが大好きで、古のインターネットのコンテキストをずっと積み重ね続けたような会話が繰り返され、さながら歩くインターネット老人会のようでした。00年代や10年代にネットで流行った出来事をみんな知っているのが半ば当然のような、生まれたときからネットしてたんじゃないかみたいな人たちがたくさん住み着いていました。繰り返しますが、自分はそんな雰囲気が大好きでした。しかしその弊害として、やはりネットの中で繋がることが好きな人が多く、実際の対人関係では頻繁に衝突を起こす人も多かったです(ネットの上で衝突している人もいましたが)。これが私がドワンゴに気難しい人が多いと思う理由で、人と話すときにはその人のコンテキストをきちんと把握する努力が必要だと感じるところです。

挨拶

ドワンゴのインターネッツを去ることは、とても寂しいことです。すっかり自分の中に染み付いてしまった感覚を忘れることは、恐らく一生無理でしょう。同僚としても友人としても仲良く接してくれた人達にはいくら感謝を伝えても足りません。また、何度も退職の決意を鈍らせるくらい、一緒に働き続けたいと思えた上長にも、会えて本当に良かったです。いま、ドワンゴが大変な時期に離れてしまうことをとても心苦しく思いますが、ニコニコという文化をこれからも守り続けてくれると、一人のユーザーとしてこれほど嬉しいことはありません。

これから

9月からは、SmartHRという会社でRubyエンジニアをやっていく予定です。今後もよろしくお願いします。


カテゴリー: 未分類 | コメント / トラックバック: 0個

技術書典6で、メタプログラミングRuby本を出します


技術書典6に参加します

今回も技術書典にサークル参加します。ブースは「か54」です。

今回の本は、メタプログラミングRuby第2版の内容を追いかけつつ、現実のプログラミングという世界ではどのようにメタプログラミングが利用されているのかを解説する本です。具体的には、Sinatraのコードのなかからメタプログラミングが用いられている箇所をピックアップして、それを教本に従って解説します。

メタプログラミングRuby第2版は、本の中でいくつか現実のコードを出して解説をしている箇所がありますが、いずれも断片的で複数の巨大なコードベースにまたがったものなので、追跡が難しいです。そこで、Sinatraというミニマルなコードベースの中から、強力なメタプログラミングを使っている箇所を取り出し、それがプロダクトに対してどのような意味を持っているのかを考えていきます。

本を書いた環境

こっちが本題です。

前回の技術書典5では、StackEdit+GitBookという環境で執筆を行いました。これはいくつかの要件があったけれど、最終的になんかいろいろうまく行かなくてこうなってしまった、という環境の成れの果てです。詳細は前回のブログを見てください。

今回の環境

いくつかの選択肢がありましたが、今回は最初からRe:VIEWを使って本を書くことに決めました。理由としては、次にあげるいくつかの前回の反省があります。

  • GitBookの成果物は、印刷するのにやや難がある
  • Markdownから望むRe:VIEWの形式に変換するのには、現実的に無理がある
  • というよりも、そもそも文章フォーマットの相互変換に無理がある

Markdownで執筆したものを、望むような形で印刷可能なPDFに変換することは、もはや無理だと悟ったというのが最も大きな理由です。PandocやSphinxも、変換は行ってくれますが結局の所は出力の形式が望んだものになるかどうかは確かではありません。そうなった場合、PandocやSphinxの気持ちを感じながらMarkdownを修正していくということはもはや不可能です。ならば最初から余計な相互変換を持たないRe:VIEWを使うべきだという結論になりました。複数の入力を受けつけ、複数の出力をしてくれるソフトは確かに便利ですが、アンコントローラブルになる箇所が多く、執筆時間が限られているときには選択が難しかったのです。

幸い、Re:VIEWのフォーマットは比較的わかりやすく、リストなどにやや不満はありつつも十分に1日で書けるようになるものでした。そのため、今回は最初からRe:VIEW形式で執筆を行おうと考えました。しかしその一方で、いくつか諦める必要のあるものもありました。

  • ライブプレビュー
  • クラウドエディタ

この二点です。

ライブプレビューに関しては、まあそれはそうという感じしか無く、都度ビルドして確認することしかできません。

クラウドエディタに関しては、まあクラウドエディタでRe:VIEWファイルを書けば良いので特に諦める必要はなかったのですが、EditStackに不満を持っていた私はあれからもっと良いクラウドエディタに出会っていませんでした。良いエディタという意味で言えば、esa.ioはかなり気に入っています。しかし、これはMarkdownに特化しているため、使えませんでした。

しかし、原稿をクラウドエディタで書くことを諦められなかった私は、考えました。結果、Re:VEIWフォーマットとMarkdownはなんとなく似てないこともなかったので、今回はまず概要と草稿をesa.io上で執筆し、そのMarkdownデータを手でRe:VEIWに変換した上で、本を作るための細かな命令などを手元のエディタで行いました。おそらく、技術書を書く上で一番つらいのは、最初の草稿をあげるまでで、そこから先は多少の原稿の修正と、印刷用のマークアップ作業です。なので、その辛い箇所をクラウドエディタでなんとかして、機械的にちかい作業はローカルのエディタで行うように分担したのです。

最終的に、Re:VIEWのファイルはGitで管理してGitHubにプッシュしていたので、GitHub上からクラウドエディタのようなこともできなくはなかったですが、それはやらなかったです。

用意した環境

最終的に用意した環境は次のとおりです

  • esa.ioで草稿執筆
  • vimでRe:VIEWファイルへ書き換え
  • 文章の管理はGitHub
  • Dockerコンテナでビルド

CI等は使っていません。複数人で執筆なら必要だったと思いますが、一人の場合は手元でガンガンビルドするので、特に恩恵はないと思ったからです。

Dockerのイメージには、[vvakame/docker-review: Re:VIEW build container by docker](https://github.com/vvakame/docker-review) を使わせてもらいました。

問題点

草稿までをMarkdown+クラウドエディタで書き、仕上げをRe:VEIWとGitで行うというのはなかなかいい選択肢でした。ただ、問題も一つありました。Re:VIEWは、TeXを中間表現として使っているという点です。

印刷用にマークアップを施し、Re:VEIWで実際にPDFを出力してみて、何か調整したいと思ったときに求められるのは、TeXの知識なのです。残念なことに、私は情報系にしては珍しく大学でTeXを学ぶことがなく、またその後も学ぶつもりがなかったので、TeXのことが全くわかりませんでした。

今回の原稿で具体的に困ったのは、引用したソースコードが行番号付きリストの横幅に収まらなかったケースです。何かしらの方法で改行が必要でしたが、そのために必要だったのはTeXの知識でした。

[【Re:VIEW】表のセル内でURLを折り返しする方法 – himajin315の記録](http://d.hatena.ne.jp/himajin315/20150312/1426146268)

[Re:VIEWで長い文字列を折り返すためにやったこと – patorashのブログ](https://patorash.hatenablog.com/entry/2018/12/12/160511)

これらのページに行き着いても、TeXのことが書いてあって、雰囲気ではわかっても何かエラーが発生したときにそれがどういう原因で出て、どうやって治すのかの当たりをつけるのに困難を極めました。私がうまく行かなかった理由は、設定を記述する順番が間違っていたというものでしたが、そんなもんわかるかという感じです。

とはいえ、Re:VIEWの良い点は、日本語のドキュメントが充実している点と、Twitterで泣き言を言っていると作者の方が拾ってくれたりするところです。

これは本当に助かりました……

次回の執筆環境

今回、Re:VIEWはとてもいいソリューションだと思いました。Markdown2Re:VIEWは諦めて、最初からRe:VIEWで書くことをおすすめします。細かい表現とか、変換時に失われますし。

クラウドエディタに関しては、いくらか思うところがあるので、次回までにはまたいろいろと選定したいと思っています。


カテゴリー: 未分類 | コメント / トラックバック: 0個

Mobb 0.5 and Repp 0.4 out now


このエントリは Mobb/Repp Advent Calendar の二十五日目です

Mobb 0.5.0 out now

🎉

クリスマスなので、超急ぎでリリースしました。Ruby 2.6.0 も出たし。

Mobb 0.5.0では、Advent Calendar で予告していたいくつかの機能がリリースされます。

Mobbのメソッド呼び出しをチェーンする、 chain/trigger シンタックス

BotはBotと会話するべきかどうか?

Mobbの正規表現解釈と、MatchDataの行方

Mobb製のBotになにか処理をさせたが、何も反応を返したくないときはどうするのか

Mobbにおけるマッチのパッシング

これらの機能の新規実装により、 chain/trigger, react_to_bot/include_myself, matched, say_nothing/silent, pass キーワードが新たにMobbに追加されました。

また、次の機能は予告していましたが0.5.0には入りませんでした。

MobbのLogger

Mobbのcronを秒単位で動かす

Mobbのマッチングにどれもヒットしなかった場合のフック

理由としては、実装そのものは概ね出来ているのですが、大きな機能追加が入りきちんとリリース前の検証が出来なかったからです。この機能は、検証が終わり次第リリースします。

Happy Mobb

25日間なんとかACを完走できました、これからもMobbをよろしくおねがいします。

 


カテゴリー: 未分類 | コメント / トラックバック: 0個

Mobb/Repp Advent Calendar のネタが尽きたので、開発してて面倒な話をします


このエントリは、 Mobb/Repp Advent Calendar の二十四日目です

Mobb開発とRepp開発で困る依存性

Mobbの開発には、大きく分けて2つのケースがあります。Mobb単体の機能追加や修正で済む場合と、Repp側にも機能追加や修正が必要な場合です。

Mobb単体で終わる場合にはなにも困ることは無いのですが、Repp側との連携をしなくてはいけない場合は面倒なことが発生します。Repp側の機能追加や修正を、開発中のMobbにどうやって適用するかです。場合によっては、ReppとMobbのコードを行ったり来たりしながら修正を行う場合もあります。

いまのところ、そういったケースではMobb側のGemfileにローカルのReppへの依存を書きます。

一応これでローカルで修正したReppと連携した開発ができるのですが、このGemfileはgitの管理下にあるので、下手になにか追加していると、ブランチのスイッチやリベース時になんか面倒なことになったり、場合によっては間違えてコミットしてしまったりして事故が発生する可能性があります。

Gemfileをgitの管理から外すのが最も良い気がするのですが、こいつはbundlerでgemコマンドを叩いたときに勝手にできるやつだし、なんかどうも消すのに妙な抵抗感があります。

こういう、他のコードと並行して変更する必要がある開発の場合、どうやるのが一番いいんでしょうか?


カテゴリー: 未分類 | コメント / トラックバック: 0個

Mobb/Repp Advent Calendar のネタが尽きたので、対応したいハンドラとか書いときます


このエントリは Mobb/Repp Advent Calendar の二十三日目です。

ネタが切れたので対応したいハンドラとか書いておきます

本当に作るかどうかはわかりませんが

  • Discord
  • LINE
  • IRC
  • ChatWork
  • 他にも何かあれば教えてください

カテゴリー: 未分類 | コメント / トラックバック: 0個