qsonaのブログ

プログラマーです。

キッズバースデー休暇という神制度

明日は息子の6歳の誕生日ということでまーたポエムを書きたくなってしまうのだが、たまには自分が所属している株式会社FiNCについて書いてみよう。

明日は会社を休む。普通の有給休暇ではなく、キッズバースデー休暇という制度を使わせてもらう。

company.finc.com

これはかなり本質を突いた福利厚生制度だと思う。子供1人につき有給1個追加、っていう制度の方が理論的には有利なんだけど、そういうことではなくて、子供の誕生日は子供と一緒の時間を過ごしましょう、子供を大事にしましょう、という会社からのメッセージングなわけだ。

子育てしながら働く人にとって、いや一般化せずに自分の話にしよう、子供が2人いて、働いている自分にとって、子育てへの理解がある環境かどうかというのは、生産性にモロに直結する。

とある昔話を書こう。とある会社に勤めていたときは、裁量労働制だが基本19時まで働いていた。保育園は19:15までなので間に合わないので、基本的に迎えは妻が行っていたが、とある日、妻が迎えに行けない事情があって、その日は18:45に退社させてほしいとチームリーダーに言ったんだ。そしたら「半休になるけど大丈夫?」って聞かれたのね。えっ?て思った。

あはい、分かりました、っていってその場は引き下がったけど、とはいえ黙って半休にするほどお人好しではないので、人事に問い合わせたら、「その場合、形式上は半休を申請してほしいが、裁量労働制なのでそもそも半休という概念は存在せず、したがって半休によって有給休暇が減ることはない」という回答を頂いた。いろいろツッコミどころはありつつ、それから僕は半休の鬼(?)になった。・・・まあ自分のその行動もいま考えたらどうかと思うけど、いずれにしてもそのチームにいたときは、お互いに信頼関係を築けずに地獄のような日々を過ごしていた。

幸い大きな会社だったので異動が可能で、ずっと異動願を出し続けてたら、ある時全く違うチームに異動させてもらった。そこの新しい上司が2人の子供の親だった。働き方についてもすごく理解してくれたし、子供がよく熱だす時期とかもあったけど本当に気負わなくなって、無駄に悩むことが全然なくなって、その分チームに貢献しようっていう気持ちが強くなって、前とくらべれば生産性は雲泥の差になった。はっきりいって天国みたいなチームだった。

その時は、そのチームは、上司の他にも家庭を持ってる人が何人もいたりしたので、理解してくれやすいのかな、って思ってた。なので、今の会社(FiNC)に転職するときは、最初理解してもらえるかちょっと心配だった。子育てをしているエンジニアはたしか一人もいなかったから。けれど、はっきり言ってその心配は無用だった。いつも尊重してくれて、理解しようとしてくれて、気遣ってくれた。だから、子供の何かで会社に遅れたり家にいなきゃいけなくなった時も、変に申し訳無さとかを感じずにすむし、だから逆にその分頑張りたいとか貢献したいとか、そういうプラスな気持ちになることができる。わりと定常的に保育園の迎えに行っていて、帰って子供が寝てから仕事する、みたいなサイクルが確立してる。まあ今日はこんなポエムを書いているんだけど。

そんなことで、いまの会社の同僚達には本当に感謝している。こんなので伝わるかどうかわからないけど、日付が変わってしまいそうなのでここで一旦投稿する。

Rails Developers Meetup 2018 に参加/発表/進行協力してきた

railsdm.github.io

発表

資料

speakerdeck.com

引用

前段

事業会社におけるマイクロサービス化について - arclamp

MaturityModel (Martin Fowler)

Lv.1

レールの伸ばし方 // Speaker Deck willnetさん

Lv.2

The Secret to Amazons Success Internal APIs

ぎんざRuby会議01にて、「マイクロサービス指向 Rails API 開発ガイド」という発表をしました

RESTful Web API 開発をささえる Garage - クックパッド開発者ブログ

わかる!ドメイン駆動設計 ~もちこちゃんの大冒険~【C91新刊】 - TechBooster - BOOTH

Lv.3

RubyKaigi 2017 でどんな発表をしたか - onk.ninja

マイクロサービスにおける 非同期アーキテクチャ ota42yさん

クローズドソースから始めるオープンソース onkさん

ApplicationTemplateのススメ onkさん

準備

テーマ設定を広げすぎていつも後悔するんだけど、今回も例によってそうしてしまったので、話がまとまらなくてつらかった。 4日前のGinza.rbに参加して、主催の平野さん ( 干し肉 (@yoshi_hirano) | Twitter ) に「聞きたい内容とかありますか」っていう雑な質問をしてしまったのだけど、 それに対してかなり細かく返していただいて、おかげさまでこれを念頭に起きながらだいぶ組み立てることができた。

上の質問と回答は、ama というアプリケーション上で行われている。このイベントのために平野さん自身が作られたとのことで、強いとしかいいようがない。上記のアプリケーションをホストしているサイトが残るかわからないとのことなのでそちらのリンクは避けておく。

ずっとアイディアは書き留めていたが実際に資料の構成を作り始めたのは2日前。とりあえずマークダウンで書いていって後からKeynoteに移そうと考えていた。が、かなり枚数が多くなって、手でいちいち移行するのキツイな・・・と思っていたところに神ライブラリを見つけた。

GitHub - k0kubun/md2key: Convert markdown to keynote

k0kubun.hatenablog.com

k0kubunさんのライブラリで、マークダウンをkeynoteに移行できるものだが、直接生成するのではなくて、Keynoteアプリを開いた状態で実行するとGUI上でどんどん変化しながら移行されていく。(そうしている理由は記事にある。)この様子が余りにすごくて、実行したときはオフィスで声(大声に近い)が出てしまった。

一旦未完成の状態だったが、これを試してみてほぼ完全にマークダウンからKeynoteに移行できることが分かったので、ギリギリまで構成つくるのに専念できることになった。感謝しかない。

それで木・金で資料作成して9割方できて、当日朝は進行協力して、13時から1hくらいで完成させて、そこからKeynoteに移行して、画像はってレイアウト調整して、直前はぶつぶつ唱えながら練習して、それで17時から発表した。30分目一杯使って、伝えたかったことは伝えられたように思う。

マイクロサービス一般みたいな話をするのはこれが最後でいいかなと思っていて、次登壇できるときは脱却して特定の技術とかを話すようにしていきたい。

そんな感じですが、マイクロサービス始めたいと思ってるけどどうしようとか、マイクロサービス始めたけどうまくいってないとかそういう話あればtwitterとかで気軽に声かけていただければと。

しかし、それにしてもこんなにマイクロサービスの競争率高いとは思わなかったw

発表内容

ハイライトはこれ。

なんとなく分かってはいたけどこの対比には笑ってしまったw。

一応補足すると、自分はレイヤードアーキテクチャRailsに導入するのは辛いとは言ったがw、MicroservicesはDDDをベースにした概念といって差し支えないので、立場が違えど大事にしているものは同じだと思っている。

ちょっと広く話しすぎて刺さるか心配だったけど、色々反応を頂いてありがたかった。

スポンサーLT

speakerdeck.com

同僚の澤井さん nobuhikosawai (@nobuhikosawai) | Twitter のスポンサーLT。聞いていたけど、10分枠を目一杯使った渾身のトーク感あった。

トークの最後にライブでIssueを立てていたのだけど、それをYoutube配信で見ていた方がPRを出すという激熱い展開になっていた。

結果両方クローズされてしまったが、ナイストライでした。

offsetでnewするのは僕らのユースケースでは必要なので、これからもVirtualTimeZoneRailsを使い続けることになるでしょう。モンキーパッチだけど、当て方もいいしメンテが難しくないので大丈夫。

2日間お互いのトークをブラッシュアップしあって、楽しかった。

聴講したセッション

1日目

365日24時間稼働必須サービスの 完全無停止DB移行

大体準備に忙しくてゆっくり聞けなかったけど、kyudenさんの発表だけちゃんときけた。そして最高だった。正直、エンジニアリングのレベルが違いすぎる。あとでもう一度後半の話を読み返してちゃんと理解する。

speakerdeck.com

2日目

Observability, Service Meshes and Microservices

今回のカンファレンスではマイクロサービスの話が乱立していて(はい、すいません)それだけ関心が高いのだなと感じたが、その中でも一歩先を行くcookpadの、taiki45さんの発表。サービスメッシュの話はずっと聞きたいと思っていた & taiki45さんの話はずっと聞きたいと思っていた(本当) ので完全に俺得セッションでした。大変わかりやすかったです。

speakerdeck.com

Qall - Docker で作る Quipper の開発環境

speakerdeck.com

Quipperのmtsmfmさんの発表。Ginza.rbでの同氏の発表をきいて感銘して ( Remove AS::Mb::Unicode::UnicodeDatabase // Speaker Deck )、今回も楽しみにしていて、実際非常に今の自分にとってためになる話だった。開発環境Docker化はRailsと合わせるとめんどくさいところが多そうだったからそもそもチャレンジしていなかったんだけど、今日の話をきいてやっていきたいな。あとサービス全部入りDockerは、弊社でもやろうとしてて実際進めてたんだけど、サービス増えすぎてローカルじゃ起動できない感じ(メモリ足りない)になってきて諦めたという経緯があったように記憶してる。その辺の話を懇親会できいてみたかったけど声かけそびれた。

「社内ツール作成サークル」活動記録

ドリコムのonkさんの発表。まだ資料あがってなさそうだった。待ち。

社内ツールを内製するのって正直大変だと思うのだけど、社内ツールを実際のプロダクト開発のようにユーザー(社内の人たち)に提供してフィードバックもらって改善して・・・という話。なんていうか、聞いていて最初の方は、そうはいってもつらいこともありそうだとか、実際どれくらい時間とれるんだろうかとか考えてたけど、聞いてるうちに、ものづくりって素敵だよな、エンジニアって素敵な仕事だよな、とか、いろいろ考えてたらなんだか桃源郷みたいに思えてきて、最初の方に思ってたこととか全部野暮だった気がしてきて、そんな話をonkさんが12年もの間働いてきた多分最後の発表で、会場はそのドリコム社で、こんな最高の話をしているっていう状況に勝手に感情移入して泣きそうになっていた。

その他

ほかにも見たんだけどちょっとまとめる気力がいまないので一旦ここまで。amaすごいっていう話も書きたいんだけど一旦。懇親会と二次会も最高だったんだけどそれも一旦。

平野さんをはじめとする運営の方々、本当にありがとうございました。 またお手伝いできることがあったらなんなりとお声がけくださいませ。

Innocent Walls (SP Another) のフルコン攻略

前提

1P右利き 正規譜面

要求: 縦連打がそこそこ得意、地力は十段取れないとさすがに厳しいかと

参考: 筆者がフルコンボ達成時のスペックは十段(いまでいう中伝)、お菓子ハードくらい。2回繋いでてベストは空POOR1。スコアはベストでもAAAに乗ってないくらい。

上記くらいのスペックの人が現実的な回数(100回くらい?)で白壁フルコン狙うには、ある程度回数が必要だと思うので、癖が付かないようにするとか、普通のところもなるべく安定させるいう観点も大事。

譜面はtextage様から http://textage.cc/score/

攻略

個別攻略の前に一言

  • クラッチ+連打のところは、鍵盤片手でやる。
    • クラッチと鍵盤を両方左手で連打するのは(フルコン目指すことを考えると)安定しないので。
  • 重要な難所は押し方を覚える。
  • 癖付かないように毎度ある程度スコアを狙っていったほうがよい。あんみつはおすすめしない。

1-5小節

つなぐだけなら簡単なんだけど、連奏中に疲れないようにリズム崩して叩いてると変な癖着くので、ちゃんとスコア狙うのがいいと思う

6-13小節

さすがにここらへんは出来る前提で。十段くらいは欲しい理由はそれ

14-21小節

例えば14小節の2-3拍目のように 66466 ってあるやつ、右手だけでも出来るのだが、ここの 真ん中の4を左手で取る ようにすると圧倒的に安定する。

22-29小節

4拍目-次小節の1拍目にかけて右手5連打になるところ。以下を注意する

  • 4566|7 ってなってるところは 最初の4を左手で取れば4連打に減らせる
  • 5677|6 ってなってるところは、7が小指だとキツイので、僕は薬指と小指をくっつけて補強してる

28小節の4拍-29小節の 4566|67 は、4を左手でとっても 566|67 の5連打になる。こればっかりはどうしようもないので、逆に前半の切りどころはここだけなので 気合で乗り切る

30-37小節

簡単なんだけどやはり連奏してるとこういうのでも癖が着くので、ちゃんとリズムを理解してスコアを狙うようにする

34小節みたいなのは7を小指で叩いてるとつかれるので小指と薬指くっつけてる。

34, 35, 36小節あたりは、間にはいる4を左手でとって、なるべく右手をいじめないようにする

38-45小節

これも簡単なのだけど、自分はなぜか変な癖がついたので、good出るようになったりしたら譜面見直すなりで正しく覚える

46-53小節

基本ずっと3鍵は右手。たまに来る単発の6565とか5656ってところに5を左手回せる人は回してもいいと思う。僕はやってない。

同じく6の2連打は中指なんで押しやすいが、7は小指だと辛くなってくるので薬指をくっつける。

52小節の4拍目から53小節が、この曲最初の難所。ここは 2+6 => 1+7連打を全て右手で取る のが最も安定する。

(運指は、人+薬=>親+子の連打)

2+6を右手でとって入る、というのを覚えるのが重要。

連打抜け後の3+5=>S+1+7、は、右手親中で3+5 => 右手小指で7 (S+1は左手) としている。

54-61小節

だんだん難しくなってきて、とはいえ地力があればそこそこの確率でつながるんだけど微妙に安定しないゾーン。

序盤と同じく、 664 と来たらこの4を左手で取る。 これでだいぶ安定する。

60-61小節がこの曲2番目の難所。1ブロック前の箇所と形は似ているが、2+6=>1+7連打の前に休みがないので、2+6を右手で取るのは不可能。 したがってここは 2+6は左人+右中で取って、次の1+7は右親+子で連打 する。つまり、 2の左人の下に右手をくぐらせる。

62-65小節

65小節の 77577577|577 ってとこがやっぱり難しくて (3番目の難所) 、多分開幕の方にあれば割と楽なんだけど、後半にあるからそこそこ疲れていて腕がもつれやすい。

が、実はここの譜面、他がスカスカなので、 5番に左手を回す とメッチャ簡単になる。ぜひ試して欲しい。

繋いだときは全部右手(5親,7子)でやってて、ここで1切りを何度かやらかしてるので、もっと早く気づいてたら早く繋がってた。

66-69小節

68小節の地味にあるS+1+6の連打は、1+6を右手で取る。

69小節は言うまでもなく最大の難所。もちろん鍵盤片手だが、指の配置を確認すると、
1+3+5+7が 親+人+中+子 になる。

あとは入るタイミング。リズム的にいうと(DがS+1+7で)

D|DD-DD-DD|-DDDDDDD

なのだが、僕レベルの縦連打力では全ピカグレは無理なので、

  • 間で休みすぎない (途中で少しでも遅れたら、ほぼ繋ぐのは無理)
  • 特に最後の2-7 のところの間は、休みというよりも「そこは連打ではない」くらいな微妙な間隔の開け方
  • つまり、 最後の7連打は気持ち早めに入る (黄グレくらい)

逆に言うと、もっと筋力強くて連打できる人は、あんまり意識しないでリズム通り叩いたらいいと思います。

最後に、皿。普通に押しから入ったら 最後引きで終わる ので、それだけ覚えておく。

最後引いた後にその手でそのまま2鍵を取るところに注意する。
(こういうのは最後思いっきり引くモーションを付けると安定しやすいんだけど、あまり勢い良く引くと次の2鍵を左手でとるのがスカりやすいのが若干いやらしい)

(繋いだ時で、ここ単体での繋がる率は50-70%くらいだった。)

70-77小節

十段とれるくらいなら出来るはず。自分は皿が絡む箇所では3鍵を全部右親で取ってる。

最後に

drummania だと(ランダムとかないので) 単曲で攻略するという姿勢が割と普通だったのだけど、iidxだとあんまりこういうやり方してる人周りで見なかったので。

息子が「ふしぎな国のアリス」の絵本を読んでいたので、あらすじを聞いてみた

4歳8ヶ月の息子が、実家にあった「ふしぎな国のアリス」を読んでいたので、読み終わった後に試しにどんな話だったか聞いてみた。本をペラペラめくりながら話してくれた。それを記録として残す。(息子は、文字や文を読むことに相当興味が寄ってるので、年齢にしてはかなり読める方だと思う)

本はこれ。 https://www.amazon.co.jp/dp/4591021645 ひらがなで3000字くらい、結構長い。見開きで、150字程度ごとに絵がある。


まず穴に落ちて、そして、入り口がせまかったからえんえん泣いて、そしたら池になっちゃった。池に浮かんで、アリスはまたそとに出て、おうちにかえったら手袋がなくて、ジュースを飲んだら大きくなって、きのこを食べたら首が長くなっちゃった。そしてね、ねこに言われて、そして、おうちはどこ?ってきかれておうち行けたから早く行きなさいって言われたからお茶もジュースもないわってアリスがいって、お茶を飲もうとしてもコップはからでした。しばらく帰ってなんか行って、しばらく行くとトランプの職人が白いばらの花を赤いペンキで塗っていました。「女王様が白いバラが嫌いです」っていったから、ここ通って見つかって、ににん(二人)の首をきって、アリスは切ってないけど、この塗ったやつの首が切れた。女王様はまけて、女王がもってる棒を渡して、フラミンゴを渡して、フラミンゴをだーんだーんってやって、女王様は負けたのね。アリスが勝ったんだけど女王様は大喜びだったのね。アリスが勝ったら死刑になっていたでしょう。地上に帰る道をわからなかったから教えて、グリムフォンにたずねなさいって言ったからグリムフォンにきくと、にせうみがめにたずねなさいって言って、にせうめがみに聞くとそれはえびにたずねなさいって言って、えびにきくとそれは裁判官に尋ねなさいっていって、そうすると検事が帰ってきた。アリスは王様のランドにいって、ハートのジャックが女王のパイを盗んだ罪で裁判がおこなってたんだって。帽子屋と3月うさぎが立って、私たちがパンを食べていました、女王は判決を言ってハートのジャックは死刑にして、アリスはあきれて大声で「そんな簡単な理由で人を死刑にするなんて許せないわ」というと突然アリスの大きくなりました。命令すると、トランプの人がね、やりを構えたんだって。そしてアリスにおそいかかったら、アリスをよけなさいっていって、落ち葉をはらってねごとを言ってるけど、どんな夢をみてるのってお姉さんに言われるとやっと目をさましたんだって。


明らかな誤読は、実際にはトランプの職人の首は切れてない(「アリスが隠して、刀に赤いペンキを塗って、女王をだました」のくだりが多分理解できなかったっぽい)ことと、アリスと女王様の勝ち負けが逆転してることの2点。適度に飛ばしながらスラスラ喋るので、ある程度頭に内容が入っているのだろうと思う。

子供が話すことをテキストで残すのは、成長の記録としていいかもしれない。

第65回 HTML5とか勉強会 ー React最新情報 に参加したメモ

リンク

公式

eventdots.jp

安定のりぃさんログ

lealog.hateblo.jp

togetter

togetter.com

もう十分まとまってた。

感想

自分の立ち位置としては、フロントエンジニアではないけどJavaScript自体には詳しい方で、社内でReact/Reduxで動いてるPJがあるのもあって興味はある(いずれ書けるようになる必要がある)。Reactやfluxが何なのか的なのは理解するよう努力している。最新情報を普段から追うのは難しい。CSSは書いたことない。という感じでしたが、どのトピックも非常にストレートに自分のためになりました。

各セッション

React現状確認 by @koba04

speakerdeck.com

Reactの最新情報盛りだくさん。今後非推奨になる項目は特にチェックしておかなければです。

具体的なところだとPropTypesが非推奨っぽくなる話が特に気になった。flowやTypeScript使う、あるいはPropTypesは別パッケージへ。

なぜReduxを使うのか by @kuy

speakerdeck.com

Storeの役割を分割して名前をつけた、というのには納得。

Reduxの役割は状態管理に特化していて、外れるところがmiddlewareに切り出されエコシステムになっているというのは良い面でありつつ、・・・

スライド中にも入っている以下の議論。

togetter.com

このあたりについて、懇親会でkuyさんと古川会長と話すことができた。

フロントエンドの役割をもつサーバを挟み(BFF: Backends for Frontends などと呼ばれる) middlewareでやっているような処理はそこで持たせる、というようなことを話されていた。ちょうど、フロントサーバを導入したときにそういうフロントのための処理をどの程度やるべきなのか、ということを社内でも話していたところ。

Relay by @hokaccha

speakerdeck.com

GraphQL を中心として、サーバ・フロントまで含めたフルスタックなフレームワークとして期待される。データの取得を宣言的に書ける、というメリットは確かに納得。

下の記事のように、自分はちょうど社内でフロントエンドサーバーを絶賛検討中で、GraphQLも検討中。フルスクラッチでは書けないのでRelayを導入するのは辛そうですが、考え方等は勉強になりました。

qiita.com

How to style React components by @Quramy

How to style React components

CSSは今までに10行くらいしか書いたことがなく、ちょうどCSSの構造化の話に興味があったところだったので、有難すぎる話でした。

経験なさすぎて大した感想を述べられないのが残念ですが、CSS in modulesが良さそう(小並感

今回BEMは触れられませんでしたが、こういうのもありますよね。

GitHub - axross/bemmer: BEM-like simple classname builder.

まだ標準がないだけに色々な苦労がありそう(小並感

Atomic Design powered by React @ AbemaTV by @ygoto3_

www.slideshare.net

Atomic Designについては初めて知った。実例では、思った以上に本当に細かい粒度に分けていたのが印象的。

Stateless Componentでかつ粒度が小さく、ロジックがほぼ含まれないものであれば、デザイナーにとってもjsxを書く敷居が低くなる。確かに。

こちらの記事も参考になる。

ygoto3.com

その他

Reactの勉強会でしたが、AngularJSで有名な金井さんが受付のお手伝いをされていた。実は3年前くらいに本当に右も左も分からなかった時代、初めて行った勉強会はなぜかAngularJSのもので、金井さんがお話しされてたのでとてもよく覚えています、という話を金井さんにしたら、烏龍茶2Lを頂きました。

ygoto3さんは僕の前職であるサイバーエージェントの方で、チームの方々といらっしゃっていた。そのうちの1人は同期で、久しぶりに会った。技術的にもチームメンバーにも恵まれて、楽しそうで良かったなと思いました。

まちがってもいいんだよ、の言葉が返ってきた話

夜中だけど不思議な気分で寝られなくなったので、そのことについてポエムを書く。

息子(3歳9ヶ月)、結構ミスを気にする慎重派で、
親の前ではやるけど他の人の前ではやらないことが多かったり、
何回か「違うよ、こうやるんだよ」的な指摘をすると、その後気にしてやらなくなったりすることが多い。

少なくとも2歳になった頃にはそういう性格が見えてきてたと思う。それで息子にはことあるごとに、
「まちがってもいいんだよ」 「失敗してもいいんだよ」 と言い続けてきた。

そのうち、本人は「まちがってもいい」という言葉を気に入ったらしく、いろんな場面で使うようになった。

たまに拡大解釈して、わざと間違ったり、いわゆる悪いことをした後に「まちがってもいいんだよ」とか言い出すけど、
そんな時も極力、「間違ってもいい」こと自体は否定せずに、違う方面で理屈をつけて(間違ってもいいけどわざと間違えるのは違うとか)話すようにしてきた。




今日、僕が息子と遊んでたら、僕の力加減のせいで息子が顔をぶつけて、怪我するほどではなかったものの、
よほどショックだったのか大泣きしてしまった。
だいぶ時間が経ってなんとかその場はおさまった。

夜、息子と一緒に風呂に入った時に、ぶつけさせちゃってごめんね、痛かったよねと謝った。

息子は最初はなんのことか忘れていたような素振りだったけど、少し経ってから思い出したようで、
「いいよ」と言った。

「おとうさん、まちがっちゃったんでしょ? まちがってもいいんだよ」




子育てはすごくやりがいのあることだけれど、少なくとも乳幼児期はフィードバックが少ないから、自分がやっていることが正しいのか間違ってるのかわからないのが難しいなと思う。
例えば僕は以前塾講師を長くやっていて、その時の経験は確実に子育てにも活きているけれど、それと確実に違うと言えるのは、あの時は模試や小テストという、自分の仕事の良し悪しを調べるわかりやすい指標があったのが、今はないということだ。

そして、子育てには上司やメンターのような、自分の子供に対する接し方を見てそれに対するアドバイスをくれる人もいない。だからどうしても自己流にしかならない。

だからだと思う、思いがけず自分の言葉が逆に子供から返ってきたということに、いたく心が動かされて、そして何かすごく不思議な気分に浸っている。

Node.jsだけで2年半生きてきた自分が、そろそろRuby on Railsをやってみようと思う話

Node.jsをやってきて良かったこと

職業プログラマとして2年半、Node.jsだけをやってきた。Node.jsで特に良かったと思えるのは以下の2つかなと思っている。

OSSへの貢献

大層なことではないが、この1年で、lodash, neo-async, xto6, などいくつかOSSへの貢献ができたこと。

2年目に新規開発チームに異動し、自分がチームで最もNode.js経験が長いという状態になった。弊社はGitHubEnterpriseを利用していて、このプロジェクトではメンバ全員がForkして基本はPull Request駆動(ガチガチではないが)という、基本OSSにそのまま応用できる形でやっていて、ここでgitのコマンドもきちんと使えるようになった(2年目にして初めてgit rebaseやgit cherry-pickを使った)。

ちょうど、我々の開発中にlodash3系が出そうということで、npmではなくGitHubの最新に向けておいた。おかげでいくつかバグを踏んだりもして、issueやPRを送るのはほぼ必然だった。ユーティリティ系のライブラリだから決してハードルは高くないが、それでも大御所に貢献できるのは嬉しかったし、自身の成長を感じることもできた。それ以外にも、いろんなライブラリのソースコードを読むのは日常的だった。

趣味レベルからOSS貢献に繋げられる人はすごいなと素直に思う。でも、業務のレベルでしっかり使うと、それだけ色々な課題も見えやすいし、OSS貢献のハードルは下がると思う。OSS貢献は一つの分かりやすい技術レベル指標だと思うので、それが出来やすい環境にいたのは良かった。

プログラミングの力がついた

Railsはプログラミングじゃないみたいな記事が最近あった。それはともかくとして、Node.jsはそれ自体microだしフレームワークもその大体が薄いから、自分で考えて実装する量が多いと思う。ブラウザゲームのサーバサイドは定形処理みたいなのが少ないし、フルスタックな言語やフレームワークを生かせないという判断で、Node.jsを使ってきていたのだろうと思う。いずれにしても、課題に対して実際にコードを書いて解決するのは自分にとっても性にあっていたし、いい経験になったと思う。

あとは、非同期処理が当たり前、というのもよかった。

そろそろRailsをやりたいという話

今なら先人のフルスタックな知恵を十分理解できるんじゃないか、と思ったということ。もうだいぶ前から、サーバサイド開発といえば筆頭に上がる存在だし、今だってそうだ。それほど価値を認められているものを、このまま知らずにいるのはもったいないんじゃないかと思った。今ここでRailsを十分知ることは、Web技術者としての視野を拡げることに繋がると思っている。

これからも仕事はNode.jsだけど、一旦趣味レベルでRuby on Railsをはじめてみよう。

みちすじ

やるやる詐欺にならないように。一旦、勉強しながら、簡単なゲームをRailsで実装してみようかと。ついでに最近流行りのマイクロサービスっぽく、フロントサーバとバックエンドサーバを分離してみよう。

作るもの

7 hand pokerという、昔MSN Messengerにあったゲーム。ユニークなルールですごい好きだったんだけどMSN Messengerつかわなくなってゲーム自体もやってないから、自分が遊びたいというモチベーションがある。あと、一度対戦ゲーム(トランプとかボードゲーム的な)をちゃんと実装したいと思ってた。

構成

ブラウザ(js) <=> Node.js(リアルタイム, ルーム機能とか) => Rails(7 hand pokerのロジック+REST? API) => MySQL

作らないけど、例えばチャットからやりたかったら chat client <=> bot server => Rails => MySQL みたいな感じに、Railsからは完全にそのまま流用できるイメージ。作らないけど。

いつもいつも(プログラミングに限らず)企画だけ立派にやって完成せずに終わるので、ここに書いておけば、出来なかったらちょっとは恥ずかしい、だからがんばる、という狙い。rubyも書いたことないしrailsも起動しかしたことないので、まずは手を動かしてみる。