Node学園祭2016に行った話 2
前回の続き。
なんとか1か月経つ前に書きました。セーフセーフ。
Building Interactive npm Command Line Modules
https://lrlna.github.io/nodefest-2016
コマンドラインオプションを覚えるのは大変なのでインタラクティブに使えるようにして使いやすくしましょうという話。
yargs自体はこの話を聞く前から使っていたのですが、その他のpromptやchalk, inquirerといったライブラリは知らなかったので聞いてよかったです。 色変更や選択肢からのカーソルキーでの選択なんていう面倒なもの、みんなどうやって実装しているんだと思っていましたから。
本題と全く関係ないですけど$PS1
に絵文字を使うのがいい感じだったので取り入れてみたいところです。
Famicom programming with JavaScript
http://fritzvd.com/talks/tokyo-famicom
タイトルの通りファミコンプログラミングをJSで、という話。
デモこそうまく動いていなかったようなのですがJSはどこまで行くんだ...というのを感じられました。 ちょいちょいファミコンの話に脱線するのが面白かったです。8bit制約楽しい。
(エミュレータで動かす以上当然ですが)ROMにコンパイルされるとのことなので、実機でも動かせるのだろうなと思うとやってみたくなります。
GraphQL for the RESTful crowd
GraphQLなるWeb APIの形式(?)の話。
REST API自体を作ることも触ることもほとんどないので、そもそもGraphQLがなんなのかあまりわかってなかったのですが、題材がポケモンだったこともありすんなり話に入っていけました。 当面触ることもないのですが、ある程度は調べておいた方がよさそうに感じました。
Keynote
Seif Projectの話。Web(と言うよりHTTPS?)を置き換えるのだそうです。
公開鍵暗号での通信をNodeが担当してUIをQtで作るのだそうで、アーキテクチャのきれいさは理解できるのですけど、Seif Protocolで通信するWebブラウザが出てくるだけで終わるんじゃないかなあという気がすごくします。 Qtで使うC++って結局のところQt用の言語になってしまっていてアプリ毎に開発するのはコストが高いと思うのですよね。 各プラットフォームごとに実装するよりはもちろん楽なのでしょうけど。
質疑応答の中で言ってましたが、現状では接続先の特定には「すごくひどいURLのようなもの」を使うしかないとのことで、将来的にはDNSのようなものも必要なのだろうかとか考えていました。
どうにも最終形が今一つイメージがしづらく、そのうち具体的なアプリケーション例が出てきてほしいなあと思いました。
Why to Standardize your READMEs
READMEのフォーマットを標準化してみんなで使おうという話。
実際READMEを書くのって思う以上に大変だったりします。 「何書けばいいんだっけ?」「あれも書いておかなきゃ」と毎回悩む羽目になったあげく結局何か抜けていたりとかするので、機械的にチェックできる仕組みがあると助かりますね。
Vue.js 2.0 サーバサイドレンダリング
https://speakerdeck.com/kazupon/vue-dot-js-2-dot-0-server-side-rendering
そもそもVue.jsを知らなかったので理解がイマイチだったのですが、React以外の選択肢として知っておくと良さそうかなと思いました(なおAngularは挫折)。
React + Reduxを使った大規模商用サービスの開発
https://speakerdeck.com/yoshidan/nodefest2016
Mattermost Desktopは素のReactのみで作っていて(サーバー側はRedux化しようと言っているところ)、いずれReact-RouterやReduxを入れていかないとしんどいかなあと思っていたところだったので、Reduxの具体的な事例を見れたのが良かったです。
消費者向けというところもあるのでしょうけど、商用サービスというのは大変なのですねえ。
boarding the tiny framework train
https://github.com/yoshuawuyts/choo
フレームワークを作る話なんですが、発表者のYoshua氏の、世界中を旅しながらプログラミングをしてるといった生き方や途中のライブコーディングの速さに圧倒されたという感想が第一に来ます。 多分、他人のコーディングを見てかっこいいと思ったのは初めてかもしれません(そもそもあまり機会がない)
冒頭に出てきた"BUILDING THINGS IS FUN"というのは大事ですよね。 忘れないようにしたいです。
The Evolution of Electron
https://speakerdeck.com/zcbenz/evolution-of-electron-nodefest-2016
1日目の記事でも書きましたが、これを聞きに行ったといっても過言ではないのでした。
AtomのためにElectronを作るに至った経緯から始まり、オープンソースの成長にはコントリビューターの存在が大事で、そのために気を付けることを話していました。
- 開発のしやすさ(セットアップスクリプトの用意や、可読性の良いコード)
- IssueやPull Requestへの反応の早さ
さて自分はどうかと振り返ってみると、反応の早さは本業がある以上どうにもならない時もあるとして、とりわけ前者の可読性の部分は耳の痛い話でした。 勢いのまま進めてしまいがちなので気を付けたい部分です。 何が良いか、というのはその時々で変わる面もあると思うのですが、フレームワークのやり方に乗っかってしまうのは一つのやり方だとは思います(そんな簡単な話じゃない)。
JavaScript による並列処理:共有メモリとロック
https://speakerdeck.com/chikoski/20161113-nodefest
タイトルの通り、JSでマルチスレッドをするときのメモリ管理に共有メモリとロックが必要ですよね、という話。
JSというか実質Cの話で、内容的にも「そりゃそうでしょうよ」というものなわけですが、ある意味今回1,2を争う面白さだったかもしれません。 JavaScriptって全然イケてないなー(棒)
Lightning Talks
LTからは特に興味のあったものを。
WebAssemblyに欠けている大事なもの
https://docs.google.com/presentation/d/116KcjqmqlO9SnHt-G5cemWgWgepqLEvZJ1vSoptEjI4/edit
C/C++のパッケージマネージャとかライブラリ依存の話がひたすら首を縦に振ってうなずくしかなかった。 最近はC/C++を全く書いていないので、そろそろCMakeLists.txtをスラスラ書けない気がする... ローカルフォルダで完結するパッケージマネージャが欲しい...
自分でパッケージマネージャを作るところまでは考えが及ばなかったので自分は普通だなと思いました。
From Library to Tool - power-assert as a General Purpose Assertion Enhancement Tool
アサーションツールへの依存性をゼロにすることでテストコードをより長生きさせましょうという話。
chaiを初めて見たときにその書き方に感動して使っていたんですが、テスト失敗時に何が悪いのかイマイチわかりにくく最近ではイマイチだと感じていました。 いっそGoのようにアサート無しでベタにif文書いていた方がマシという...
そんなところにこの発表だったので、次からはpower-assertを使いたいなと思いました。
RuntimeJS Playground
https://github.com/groundwater/runtime-playground
JSでハードウェアレイヤを触る話。実にプリミティブにディスプレイデバイスをメモリ番地で参照して、それが実際にQEMU上で動いているという、マイコンを触る側からすると実に親しみやすい最高のプレゼンテーションでした。
(やれるかどうかはともかく)実機で動かしてみたいものです。
Closing & Party
普段こういう場ではコミュ障を発揮してあまり話をできない性質なのですが、せっかく来たのでZhao氏に話しかけるところから始まり、普段よりは少しマシに人と話をできたと思います。
でもやっぱりしんどいものはしんどい。
参加人数もさることながら、通訳までこなしていて、運営は非常に大変だったのではないかと思います。 1セッション30分で次から次へと進んでいくので、かなり密度の高い1日になりましたが、とても楽しかったです。
来年も参加するかというと、東京なので腰が重くならざるを得ないのですが、参加できるといいなあと思います。