YAPC::Asia Tokyo 2015 1日目 #yapcasia

エンジニアの越川です。
本日は、マネーフォワードのエンジニア数名でYAPC::Asia Tokyo 2015の1日目に参加してきました。

参加したプログラムのうちいくつかのメモをシェアさせて頂きます。

今フロントエンドで何が起こっているのか

メモ

Ajax以降の世界の話 Google MapなどそのころES5(2009)5.1は2011 “use strict”;などのサポートCoffeeScript(2010) JavaScript good partsが発売された頃ALT JSの登場CoffeeScriptが普及したのは、Rails3.1で採用されたのが大きいjQuery(2006) ブラウザの差異を吸収するのに有用だったjQuery Pluginのエコシステム$.ajaxでpromiseを意識するキッカケとなったBackbone.js(2010) Frontend MVCコードも小さくて分かりやすいViewがModelの変更監視、DOMの変更をModelに反映Node.js(2009) platform build on V8Grunt.js(2012) javascript task runnerYeoman, AssembleはGruntの派生2014で開発止まっているnpmのpackage.jsonにscriptをかけるようになったので、あまりGruntである必要性が減ったChrome(2008) V8が乗っているのポイントJITSPATypeScript(2012) Microsoft型IDE supportAST Abstract Syntax TreeJSの構文解析Esprema Espree Acorn babylonLinter ESLintAnalyzer istanbul, platoTest power-assertTranspiler browserify, babelProblems of SPA twitterがやめたときのあれSEOこまるねgoogleはJavaScript実行してくれるけど、、、Performance微妙じゃねメモリリークフロントとサーバとのロジック重複問題Isomorphic servser side node.jsで書けばよいのでは？という思想最初のレスポンスでserver sideでレンダリングするMeteorRendr(backbone.jsを元に)SPAに必要なもの JSONをDOMにどうやってバインディングする？history APIどうするかなどAngular.js(2009、1.0: 2012〜) HTMLを拡張するアプローチ2way Data binding jsのmodelかえたらDOM変わる、その逆もFull stack2.xが開発中とのことSPAってJavaScriptの結合順序とかつらいビルドもつらいgulp(2014) Stream baseのbuild システムconfigarableじゃなくてprogrammableに設定を書くnode.jsらしいbuildシステムpipeでtaskつないでいうかんじbrowserify(2013) substackモジュール化の仕組み node.jsのcommonJSのブラウザ版node.jsと同じライブラリが使えるのがいいよね！複数のjsファイルからbundle.jsが作られる感じStateless Composable Streamにしようステート持たないコンポーネントにしようStreamでやろうぜECMAScript 2015(元ES6のこと) まだブラウザ対応は思わしくない（ALT JSでやろうぜ）Babel(2014) ブラウザが未だサポートしてないES6を使えるようにするJS transpilerStage option(default: stage2) TC39(ECMAの委員会)のstageのこと(stage2: Draft)githubみると、どれがいまどのstageにいるか分かってよさ気EnviromentsService Workers プロセスがずっと残り続けるワーカーOffline / CacheBackground SyncPush NotificationNativeアプリじゃないと出来なかったことがイロイロできるようになるchrome::/serviceworker-internals で状況が見えるExtensible Web https://extensiblewebmanifesto.orgwebをもっと開発者が拡張可能にしようという宣言ブラウザは低レベルの層をサポート、ライブラリで拡張可能とするイメージ例えば、WebComponentをラップするpolymarReact.js(2014) Stateless Component宣言的なプログラミング(サーバーサイドぽい)VIRTUAL DOMでそれを実現一番上のコンポーネントだけが持っているイベントは基本一番上まで上げてく Flux facebookの提唱するフレームワーク1方向のデータの流れを作るFunctional Reactive Programming 非同期なイベントをストリーミングとして扱うこの入力が来たらこうなる、という宣言で書いていくRedux ↑ぽいことを実装FluxやElmに影響を受けてるReducerはただの副作用のない関数single source(データのソースはひとつだけ！ undo/redoやりやすい)React.jsと一緒に使われるけどに依存しているわけではない

感想

流れの早いフロントエンドの世界の今！をざっくり把握する事が出来て良かったです。近年、.rb系の勉強会でもフロントエンドの話題が多いのでRubyistとしてもこの流れをある程度は把握しておきたいですね。

「とりあえず今どきのJavaScriptを書くときはgulp + broweserify + bableでES6書く。フレームワークはRedux+React.js書けばヨサソウ。」という流れがあるなという印象です。

HTTP/2時代のウェブサイト設計

メモ

プロトコルはバイナリだよ h2iってコマンドあるから気軽に試せるらしいよHTTPSだよ 11/16に無料で証明書もらえるところができるよヘッダー圧縮してるよ同じヘッダーのリクエストだと以前のを参照したりするから、めっちゃ小さいよ気にすべきところはデータサイズだよ以下に小さくするかが設計で大事だよasset pipelineみたいな仕組みはリクエストを減らす目的だけど、リクエストの多重化やレスポンスプライオリティのウェイトとかがあるので、必要なものを小さく送る方がいいっぽい特定のページで使わないJSの実装とかデータサイズが大きくなるだけだからやらないほうがヨサソウつまり、sprocket捨てたい人向け（違う

Perlの上にも三年〜ずっとイケてるサービスを作り続ける技術〜

メモ

はてなブログの人イケてるとは開発継続迷わず書ける一貫した指針社内フレームワーク RailsライクなRidge+MoCoコード全部読まないと使えない過剰な抽象化を避けるためにはDRYにするためには3回コピペしたら 3人同時にコピペしたら、、、つまりCommon::にまとめたらゴミ置き場になりそうなのでServiceにしたオブジェクト指向入門がよい(特に11章)継承なるべくやめる（むずいから）状態をなるべく持つのを止めようオブジェクト指向を学んでからシンプル化をすべき長年やっているとより良い方法を見つけるので、見つけた時に、過去の遺産を直すのが大事ドメイン駆動設計 + 実装ドメイン駆動設計状態を持つのがエンティティ、持たないのが値オブジェクトサービスは状態を持たないように独立させるゴミ置き場で始まったものがドメイン駆動設計のサービスだったｗ読書会はgithubで章ごとにissueを立てると捗るよユビキタス言語チームで同じ言葉を話そうプロジェクト名も大事用語集を用意する(gitに突っ込んでっこでおく)エンジニア以外にもコード見せろ普段の会話で使う（つまり別のwikiなどではなくコード内に書く）さわりやすさインターン生が3週刊で成果出せるようなやりかた今年のインターン生は一昨日配属されて、もう新機能だいたい動いててリリースできそう

感想

オブジェクト指向入門とドメイン駆動設計はヨサソウだと思いました。

Electron: Building desktop apps with web technologies

メモ

Atom Webテクノロジーで作られているJavaScript, HTML and CSSAtom は Electronの上に成り立っているElectron io.jsChromiumElectron-based RobotsElectron-based Chat ClientElectron-based Emoji Searcher ウィンドウなしの例Electron-based Curve App https://github.com/benogle/curve-app