昨年に引き続き、YAPC::Asiaへお邪魔しました。 YAPCは今年で最後とのことで個人スポンサーでの参加です。
なお、午前のセッションを聴き始めたら会社から割と緊急なコールで途中退場→その場で障害対応ってなわけで午後からのセッションからの参加です。
例によって、場所確保のためにずっと同じ席で聴講です。(たまたま聴きたいセッションが集中していたということもありますが)
フロントエンドエンジニアというポジションが成立するようになった今日に至るまで、 Javascriptを中心としたフロントエンド周辺は様々な変遷を経てより高度にあるいは複雑になってきています。
そんなフロントエンド周りの技術要素をnon Javascript時代から現在まで駆け抜け、メインはSPA周りの技術要素についての解説というプレゼンでした。
個人的には一応最近までのトレンドはだいたい押さえてるつもりでしたが、 言葉だけ聞いたことあるレベルのものやその技術要素の背景などはよくわかってなかったものなども多く、 一つ一つはあまり深堀りされませんでしたが、様々なキーワードが出てきてものすごく為になる内容でした。
どれがいい・悪いではなくこういったものが注目・採用されてきた、という客観的な解説がとてもよかったです。
以下、気になったキーワードです。
- Isomorphic(Universal Javascript):Javascriptはもはやクライアント専用言語ではなくなっており、であればライブラリはサーバ/クライアントともに同じものを同じように使いたいという考え。これは他の言語にはないトピックと言えます。
- Babel:Ecmascript6の機能や記述を現在未実装のブラウザでも使うためのライブラリというかコード変換プログラム。シンタックスシュガー的なものであれば実用ですが「どう考えてもブラウザ実装がないと実現できなそう」なものは避けた方がよさそうです。
- flux:MVCをさらに細分化し、データの流れを1方向にすることでよりシンプルにする(=複雑化を避ける)アーキテクチャ。シンプルなパーツを組み合わせて作ろう、という流れUNIX philosophyに通じるものがある、とのことです。
Javascript周りは、構成の概念(トレンド)や主要なライブラリ、そして言語仕様そのものが頻繁に変わります。 盤石な概念と思われたMVCですらより細分化されています。 この分野に身を置く人にとっては、これを楽しめるか「つらい」問題として捉えるかが一つの分水嶺ですね。
あと、Gruntって開発止まってるんですね。 私がフロントエンド周りに手を出し始めた頃にはgulpが流行っていたので実はGruntは使ったことないです。
タイトル読み直して「あっ」と思ったのですが、WebAudioというより信号処理でしたね。 「WebAudioの裾野を広げる」のがセッションの狙いのようです。
WebAudioといえばブラウザ上でソフトウェアシンセを動かすデモが有名です。
WebAudioはブラウザがあればJavascriptで簡単に音を出せるんだぜ、というものですが、実際にはある程度信号処理の知識は必要ですね。 私は10代の頃シンセ小僧だったこともあり、このセッションの内容はだいたい理解できたのですがそうじゃない方は要復習ですね。
JavascriptのAPIはとにかくちょいちょい変わっていくので、主要な関数ですらいつの間にかdeprecated(非推奨)になってしまっており、WebAudioも例外ではないようです。
このセッションでは「Audio＝音楽」ではなく「光(ディスプレイ出力)ではない新たな出力」という切り口でWebAudioをこう使う！というネタなんだがガチなんだか判断に難しいWebAudioの使い方の紹介がありました。
デモや事例紹介では、WebAudioを使ったモデム・モールス信号通信・LEDを光らせるといった常軌を逸した使われ方が多かったですがIoTへの応用についてはなるほどと思いました。
モデムとモールス信号の実演はしびれました。音がとにかく素敵。
PerlとPerl製パッケージとDIYで保温調理するぜ、という内容。 Chef的な話だと勝手に勘違いしていましたが、ガチで料理でした。
大行列・早々に入場制限とどうやら大人気セッションのようでしたが、私自身はこのノリには正直ついていけてなかったです。
http://yappo.github.io/talks/20150821-yapcasia2015-microservices/
ここ数年バズってるmicroservices。なんのことはない、サービスが拡大していきアプリケーションが正しくコンポーネント化されていれば自然とそうなるものだ、というセッション(勝手に意訳)。 ここ数年携わってるとある基幹システムは最近数えていないけど数十のサブシステムで成り立っていて、誰もそうは呼んでいないけどmicroservicesに近い存在。あるある的な話については何かと参考になる部分が多かったです。
参考になるポイントをピックアップしました。
- 小さいサービスではモノシリックなコードで運用すべき
- 分離するタイミング：他のサービスでも使いたい、社外でも使って欲しい
- メンテナンスに手間がかかるモジュールを利用するコンポーネントなどは独立すると捗る。
- デプロイの簡単さが重要
- URLはどうするか：1つにしてバックエンドを切り替える、とすると便利。大規模化してくるとスケール(LB負荷など)の観点からサブドメインがいい
- 後方互換性はとにかくがんばる。
- 正しいコンポーネント化が重要
- サービスの規模が大きくなると、日本語ではなく英語オンリーなメンバーが増えてくるのでAPIドキュメントは最初から英語のほうが。
というわけで明日も参加します。(寝なきゃ)
