hayajoさんとの思い出

hayajoさんがはてなに入社されたそうです！

http://hayajo.hatenablog.jp/entry/2017/11/05/055756

ところで、hayajo さんというエンジニアと新潟で出会ったのは、ぼくが新潟に引っ越してすぐだった。2011年のことだ。そのときの記録は http://d.hatena.ne.jp/nkgt_chkonk/20110804/1312460118 に書いてある。この記事はエモくてちょっと面映いんだけど、まあ、当時の素直な気持ちがよく出ている文章だな、と改めて他人事のように思ったりする。

新潟にいる間、Niigata.pmを通じて @civic さんの主催するNDSという開発者コミュニティに非常にお世話になった。東京に比べるとやっぱりプログラマ人口がそもそも少なすぎる新潟で、ぼくがプログラマとして腐らず、発信し続けられたのはNDSのひとたちがぼくにたくさん刺激を与えてくれていたからだ。

その中でも、 @hayajo さんはひときわぼくに刺激を与えてくれたエンジニアだ。

なんといっても、決して環境に恵まれていたわけではない中で（そりゃ東京のスターエンジニアたちが集まるところと比べたら、新潟で随一環境がいいところであったとしても「環境に恵まれている」とはいえない）、ストイックに自分が興味のあること、自分のやるべきことについて深く学んでいく姿勢がとにかくかっこよかった。そして、それらの成果を対外的に発表するときにも、決して必要以上に自分を大きく見せようとはせず、淡々と、でもその内側にすごい熱量をもって発表していく姿は、自分にとっては「憧れ」のひとことだ。

そういえば、もうひとつ。hayajoさんは決して「若いエンジニア」ではない。年齢的にはむしろこの界隈としてはかなり高めの層だと言えると思う。けど、hayajoさんはそんなこと関係なく、貪欲に学び、そして挑戦していく。そういう姿を見ていると「エンジニア35歳定年説とは……」という気持ちになれるし、学ぶ気持ちや挑戦する気持ちがあるかぎり人間はいくらでも大きな舞台に立てるんだ、年齢のことなんて言い訳にならない、ということを考えさせられる。ほんとうに尊敬すべき姿勢だし、心からかっこいいと思う。ありていな言葉で言えば、「web系エンジニアとして年を重ねる」ということについて、hayajoさんがぼくにとってはひとつのロールモデルになっている、といえる。

はてな入社おめでとうございます。今後さらに大きな舞台でぼくの目標でありつづけてください。

ScalaMatsuri2018のトークに応募した

Building native apps with Scala.jsというタイトルでScalaMatsturi2018に応募しました。

2018.scalamatsuri.org

ここのところ、GUIアプリケーションをScalaで記述したいという素朴なScala愛を大切にしたいという思いから、Scala.jsとJSプラットフォームを利用してGUIアプリケーションを書くという試みをしてきました。「Scala.jsでGUI」とパッときいたときの「えっまじで？冗談じゃなくて？」という印象に反し、それらは一定の成果を挙げているという実感があります。

このトークでは、それらの経験からJSプラットフォームのツールキットを利用してScala.jsでGUIアプリケーションを記述する勘所について共有したいと思っています。採択には、SNSなどでのシェア数が考慮されるとのことなので、応援してもいいよって方や聴きたいと思ってくれる方はがんがんシェアをおねがいします！！！！

2018.scalamatsuri.org

2018.scalamatsuri.org

2018.scalamatsuri.org

2018.scalamatsuri.org

ReactNative + Scala.jsファーストインプレッション

ちょっと訳あって仕事の一貫としてReactNative + Scala.js の技術検証している。あたまには「全部C#」のライフベアさんの事例がある。弊社、最近メンバー増えてきたけどまだこの規模だと「あのひとはあれができるけどあのひとはこれができなくて」がボトルネックになりうるので、 筋の良い 共通の基盤技術を持つという選択肢のひとつとして検証したいというのがモチベーションとしてある。というわけで、

• Reduxは使ってない。「Scalaを基盤技術にしてどこまでできるのか」が検証の目的だから。
• Vue.js + Scala.jsでElectronアプリ作ったときと同じ感じで、MVWhateverのVとWhateverの部分は素直にJSで書いている。分厚いMをScalaで書き、UIだけReactNativeで記述する。

以下ファーストインプレッション

• pros
  • Vue.js + Scala.jsでいろいろやったときと同程度にはドメイン層はきれいにScalaで書けている。よいと思う
  • 「Viewの定義の書き方がHTMLじゃくて各プラットフォームのUIコンポーネントの抽象」ってのは、HTMLでGUIアプリ作ろうとする筋の悪さと比べたら圧倒的に筋が良いという印象
  • 注意深く設計することで、少なくともモデル層以下はScalaのコードをAndroidとiOSで共有できそうな実感がある
  • Scalaでビジネスロジック書くマンとRNでネイティブよりの部分書くマンの分業はかなり現実的にできるなという印象
    • それってファウラー先生が言ってたPDSのメリットのひとつだよね
• cons
  • ReactNativeは比較的簡単にネイティブに降りられるんだなということはわかった。が、普通にJSで書いていても、インフラストラクチャ層では「JS -> ネイティブのバインディングを自分で書く」という必要がある（コレ自体には納得感があり、筋の良さすら感じる）上に、それをScala.jsから利用するために「Scala -> JSのfacadeも自分で書く」あるいは「RNで使われるライブラリへのfacadeも自分で書く」というのは結構発生する雰囲気で、そこは正直だるさ感じるのがある
  • そもそもswiftとかKotlinで書けばよくね？
  • ていうかScala.jsもReactNativeも「枯れた技術」から遠すぎるよね
  • prosと鏡合わせだけど、HTMLの知識役に立たん。むしろネイティブの知識が役立つ

という感じです。

わたしは「クライアントサイドのアプリケーションの寿命はサーバーサイドのアプリケーションの寿命より短い」ということを信じているので、クライアントサイドでは「枯れた技術」にこだわる必要ないのではないかという立場（異論反論あろうとは思います）なんだけど、そういう立場であってもプロダクション投入に対してはかなり慎重にならざるを得ないなこれ（頑張ればなんとかなるけどその頑張りはペイするか…？）って感じです。とはいえ、夢はあると思います、Scala.js + ReactNative。様々なプラットフォームに、少ない人間で対応していくという目的に対して、Redux + JSによるマルチプラットフォームを基盤技術にするよりずっと筋がいいという感じがしているのもたしかです（動的型付け言語で複雑な状態管理をするとか正気か！？）。一方、「たとえ合理的だったとして、そんなニッチな技術選択して誰が採用できると言うのだ……」という問題はある。

こちらからは以上です。

ブラウザアプリケーション以外のプラットフォームでのReduxはtoo muchか？

@Nkznとかが最近よく言ってるReactNativeではReduxじゃなくていいんじゃない？って話。Electronでも同じような議論が可能だと思うので、さらに一般化して「ブラウザアプリケーション以外のプラットフォームでJSで動くGUIアプリケーションでReduxは必要なのか？」という話をします。

結論から先に言うと、わたしも「ブラウザで動くわけじゃないなら、Reduxである強みってそんなになくなるよね」という立場です。

まず、前提として、Fluxは「状態管理パターン」で、Reduxは数あるそのパターンの実装のひとつである。ということを確認しておきましょう。

その上でReduxの特殊性は

• Stateがピュアなオブジェクトで表されている
• Stateの更新はイベントを契機に常に同期的に行われる
• 以上2点により
  • いつでも状態のスナップショットをシリアライズ/デシリアライズ可能な形で取得できる
  • イベントを積み重ねれば常にそのスナップショットを再現できる

という利点を持ちますね。その結果として非同期なオペレーションと同期的なオペレーションでコードが全然異なってきてしまうというデメリットも同時に引き受けているわけだけれど、今回はそこについては詳細には触れません。

ところで、状態のスナップショットがシリアライズ/デシリアライズ可能であるという利点は「サーバー側で最初に状態作って、HTMLレンダリングして、シリアライズされた状態もクライアント側に渡したい」みたいなときにめっちゃ効いてくるので、SSRやるならReduxに乗っとくってのはかなりいい戦略になると思います。

しかし逆の見方をすると、Stateがシリアライズ/デシリアライズ可能であるという点がうまく効いてこないような場合にはReduxである必要は本当にあるのだろうか？　という疑問が湧いてくるわけです。そして、SSRが必要ない、ブラウザアプリケーション以外のプラットフォームでは、あまりこのStateがシリアライズ可能であるという特性は活きてこないんじゃないか？というのが、わたしの考えです。

となると、今度は「Reduxならみんな書けるでしょ（ほんとか？メンテナブルなReduxアプリケーションをほんとにみんなが書けるのか？破滅してる現場結構あるっぽいぞ？）」を取るのか、「別のやりかたをイチから検討しましょう」のコスト支払ってRedux以外のやり方探すのかっていう話になってくるかなと思います。

というわけで、掲題の「ブラウザアプリケーション以外のプラットフォームでのReduxはtoo muchか？」については、わたしの立場としては「Reduxはtoo muchかどうかはともかくブラウザアプリケーションを取り巻く環境に対して too adaptive である。とは言えFluxパターンの実装として枯れてるしよく使われてるし、そういう"長いものにMackerel"的な良さはあるんじゃないですかね。」というあたりに落ち着くのでありました。

わたし個人的には「SSRみたいな特殊な事情がないなら、古き良きレイヤードアーキテクチャのようなやり方のほうが見通しがいい気がするねえ」くらいの立ち位置ですが、それぞれメリット・デメリットあると思うので、このあたりを出発点にチーム内で議論できるといいですねと思います。

Living in Peaceの「チャンスメーカー奨学金」の支援者になった

どこで知ったんだったか忘れたけれど、Living in PeaceというNPOがある。

www.kodomo.living-in-peace.org

詳しくはサイトを見てもらうのがいちばんいいと思うんだけど、ひとことで言うと、子どもの貧困対策をやってるところだ。そのうち寄付で支援できるのは「チャンスメーカー」ってやつと「チャンスメーカー奨学金」ってやつで、どちらも子どもの貧困対策であることは同じなんだけど、それぞれ性格がちょっと違うみたい。「チャンスメーカー」のほうは「児童福祉施設にいる間のための支援」、奨学金のほうは「施設出たあとの教育機会の格差を支援」というような性格になっているようだ。

ところで、話は変わって、わたしは、自分の今いる環境や仕事、それに使っている能力を得るために、ちゃんとそれなりのコストを自分でかけてきたという気持ちはある。大学に入ったあと、高校の友人が「しんぺいくんが受験勉強始めたあとめちゃめちゃ努力してるの見て"すごいな"って思ったよ」って言ってくれたりしたのは「あー、見てくれるひとは見てくれるんだな」って思ったし、プログラマになってからも様々なことを自覚的に、自律的に学習してきたつもりだ。その学習がなければ、いまの環境や仕事、能力は自分にはなかったと思う。

けど、一歩引いてみれば、「どうして自分がそのコストを学習にかけることができたのか」ということが見えてくる。わたしの親はわたしの教育にとてもお金と時間と手間をかけてくれて、そのおかげで、わたしは22歳で大学を卒業するまで、他の雑事にあまり気を取られることなく集中して勉強することができた。そのときの経験から「あ、学習すればわかる、できるようになるんだな」という実感も身につけることができた。

前回の記事で書いた「家庭の所得格差がそのまま学習機会の格差になってる」ってのはそういうことも含めた上でのことで、さまざまなめぐり合わせの上でたくさんの「学習の機会」を、偶然に、運良くもらった自分には、学習の機会の格差を少しでも再配分する義務があると思っている（この思いは、プログラマコミュニティから学んだ様々なことを別の形でプログラマコミュニティに還元しようとしている自分の気持ちともつながっている）。

ざっくり言うとそういう気持ちから、「チャンスメーカー奨学金」の支援をすることにした。月々1,000円から支援できるそうです（少額で継続的にできるのも良いっすよね）。「俺が（私が）学習に集中できたのはそういう環境があったからだよな」みたいなことを思うひとは（そうじゃない環境だったひともいるでしょうし、そこから努力で学習の機会を勝ち取ってきたひとのことは尊敬してます。でも、「だから誰だってできる！！」ってのは生存バイアスですので、できたらそういうことを言わないでほしいな……）、検討してみてもいいんじゃないでしょうか。

ところで、こういう話をパブリックでするのは正直なところ損しかなくて、インターネットではなにを書いても怒られが発生するし、「偽善者乙」みたいに言われてとにかく嫌な気持ちになって最悪なんだけど、「こういうのあるらしいよ」って伝えたいから書いた。けどどうせ怒られるんだろうな、知ってる。

N予備校にめちゃめちゃ感動したって話

今日N予備校の体験授業やってみたんだけど、普通に内容めちゃめちゃよくて、あれが月額1000円安すぎる。予備校の価格破壊だって思った。

わたしは「医療」と「栄養がきちんと取れるレベルの食事」と「教育」については、格差の再生産が是正され、富の再配分が積極的になされるべきである、という立場を取っている。でも、現状を見てみると、正直言って家庭の所得格差がそのまま学習機会の格差になってると思う。それを考えると、N予備校めちゃめちゃ素晴らしいと思う。ほんとうにめちゃめちゃ素晴らしい。

ただ、強制力のあるサービスではないから、結局学習習慣のある子じゃないとメリット享受しにくいのはあると思ってて、そのあたりには家庭の「余力」ってめっちゃ効いてくるので、あれで全て解決にはならないと思うけど、それでもクッソ高い予備校以外の選択肢ができたのほんとすごい。

実はわたしは高3のとき東進衛生予備校（有名講師の授業がビデオで受けれるやつ）に通って「地方でもこんなレベルの授業受けられるのまじ革命的だな」って思ったけど、東進クッソ高いんですよね。あのお金を親が出してくれたの、親になったいま考えるとまじですごいと思う。とはいえ内容が良いならきちんとそれを提供しているひとたちには高い収入を得てほしいというのもあって、今のアクセスしやすい価格を維持したままN予備校の講師陣や仕組みを作っているひとたちが5000兆円得てくれるといいなってほんとに思う。

そのためにはもっとN予備校知られてほしい、まずは世の中のお父さんお母さん、体験授業受けてみませんか。わたしはまだ子供幼稚園に通ってるけど、「これがこのまま発展してくれるなら子供の教育費に関する悩みがひとつ解決するな」って思ったよ。いま真剣に自分が月額1000円払って授業受けたいなって思ってる。

追記

ちなみに体験授業受けたのプログラミングコースじゃなくて数学です

ToKyoto.jsでScala.jsについてLTしてきました。

自分の発表について

speakerdeck.com

もう3日前のことになりますが、ToKyoto.jsでLTしてきました。Scala.jsの話です。スライドにあるし、このブログでも何度か取り上げていますが Scala.js 普通に実用性あります。とはいえ「実用性がある」と「使うべき」の間には高い壁がそびえているわけですが……。

ちょっと補足的な話をしておくと、ReduxやVuexが提供する状態管理パターンのよさはいくつかあって、

• Single source of truth が守られる
• 参照系と更新系が強制的に分離させられる
• 以上の二点により、プレゼンテーション上でのデータの分割構造とロジック上のデータの分割構造が分離される
  • ヘッダーで使う情報とメインコンテンツで使う情報が互いに関連するみたいなやつが、おなじデータソース見るの簡単とかそういうこと
• 自分でデータの変更をobserveしなくていい
• 状態がピュアなJS objectで表されている

というのがわたしの認識するメリットです。そのうち、最後のメリットに関しては「SSRするからInitialStateをサーバーサイドでバーっとjsonに吐き出したい」とかそういうときにとくに効いてくるもの（参考: You Might Not Need Redux – Dan Abramov – Medium ）という感じがある。

逆に言うと、そういう制約がないのであれば、「ふつうのLayered Architecture」をやりながら、Single source of truthを守り、コマンドとクエリを分離してやれば、ReduxやVuexが提供してくれるメリットをある程度教授しつつも、他のGUIプラットフォームで得たGUIアプリケーション設計の知見を活かすことができると考えています（データ変更監視するのはがんばるしかない）。

実際、Scala.jsに移植されたNekogataDrumSequencerとBackLoggerはRepositoryがSingle source of truthになっていて（というかモデル層以下で状態を持つものはすべてRepositoryに寄せて、他を全てImmutableで書いている）、これはそれなりにワークしているなあという実感があります。

逆に言うと、ReduxやVuex的な「状態のスナップショットがJSONで取れちゃう」みたいなことがしたいときにはもう少し工夫する必要がありそうですね。

で、こういう「Layered Architectureでがんばる」みたいなやつはJSだとちょっとむずかしくて、いや、むずかしいっていうか、むずかしくはないんだけど、Scalaみたいないろんな言語サポートが欲しくなるな〜みたいなのがあって、そこで「Scala.jsありかもよ」っていう文脈ですね。

ほかのひとの発表について

@amagitakayosi さんのやつがとくにおもしろかったです。とくにMIDI信号をがんばってGPUに送るときの工夫の話が「うおー、おもしれ〜〜〜」って感じで、NekogataDrumSequencerもMIDIコン対応したくなりました（GPUには送る必要ないけど）。

その他

仕事ではJS書きまくってるんですけど、コミュニティ的にはいままであまりJS界隈に顔を出したことがなくて、JSコミュニティはアウェイな感じだったんですけど、twitterやブログで一方的に知ってて「話してみたいな〜」って思ってたひとと話してみたら先方もわたしのこと知っててくれて、その上で有意義なお話をたくさんさせてもらえてめっちゃよかったです。次はScalaっていうアウェイなコミュニティに顔を出してみたいなと思うのでScalaMatsuri応募するぞ！