[PR]
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
[2回]
こんばんわー。
ベル子だよー。眠くて瞼がくっついちゃいそうだよー。
頑張って調べすぎたよー。いつものことだけどねー。
何かを調べだすと時間を忘れてしまう病だと思うんだ、私。
とにかく今は、鬼かわいいパンケーキが食べたいってことしか考えられない。
では、まずリアルタイムな通知って何かというと
ベル子とイケメンが[ベル子SNS]というSNSを使っています。
ベル子がコメントをうpすると、イケメンのほうのブラウザ画面に
「セクシー美女からのコメントが1件あります」のような通知が
ページリロードなしで表示される。
というもの。
要するにTwitterのあれ。
まず、リアルタイムな通知を可能にする方法には、以下のものがある。
古典的な方法で、一定時間ごとにサーバに更新を問い合わせる手法。
ページ全体を取得すると高負荷となるため、Ajax通信でリクエストし変更部分を更新するのが最近では主流。
リアルタイム性に欠ける。
サーバー負荷が高い。
無駄なリクエストが発生する。
といった問題点がある。
Pollingではリアルタイム性に欠けるため、考えだされた手法。
クライアントから送信されたリクエストをサーバがいったん保留し、
サーバ側でイベントが発生した際に任意のタイミングでレスポンスを返す手法。
リアルタイム性は高い。
無駄な問い合わせは発生しないが、長時間HTTPコネクションを占有してしまう。
一度クライアントにPushしたら、またクライアントからのリクエストを待たないといけない。
タイミングによってはタイムラグが発生する。
Long pollingの発展版で、HTML5で標準化されている手法。
サーバーはイベントが発生したら、クライアントに断片データを返す。
レスポンスの一部を送信することによりクライアントとの通信が切れず
Long pollingと違い再度リクエストする必要がない。
新規格なのでブラウザがSSEに対応している必要があるが、IEは全滅。
Edgeも検討中でまだ対応はしていない。
polyfillで対応可能。
HTTPを拡張したリアルタイム通信を前提として双方向にデータが送受信できる通信プロトコルのこと。
小さなデータサイズで情報を送受信できるためHTTPに比べるとかなり通信コストが低い。
TCPコネクションを張りっぱなしにするため、ノンブロッキングI/Oサーバ（Node.js）が必要。
HTML5のAPIとして語られることが多く、現在はW3Cで勧告候補（Candidate Recommendation）となっているが、
最新の仕様はWHATWGのLiving Standard（後述）に記載されている。
IE10以降対応。
リアルタイムと聞いて、まず最初に思いつくのはWebsocket。
イケてる人たちが「これからはWebsocketでリアルタイムだぜ」と
2011年に私が某◯SNのHTML5特集をコーディングした時に言っていたのを、
うっすら覚えていた。
あれからすでに５年も経ってるから、もうスタンダードになってるよね？と思ったし
Laracastsでもテイラーが「最近、Websocketでつなげること多くなってきたよねー？」と言っていたので、当然がっつりスタンダードなんだろうねと思ったけど、いろいろ調べた結果、少し微妙な点もありそう。
そしてWebsocketがいいのではないかと思ったのには、もっと現実的な理由があって
Laravel5.1以降には、Websocketを使ってリアルタイム通信をする機構が
最初から備わっているのだ！よ！
デフォルトではPusherという外部サービスが、ブロードキャストドライバーに設定されてるんだけど
RedisとSocket.ioを使って自前で実装する方法も選択できる。さすがLaravel。
だから、Laravelに限定して言うと「実装が簡単」そう。
私にもできそう。一人でもできそう。かわいい女の子だってできちゃいそう。
ドキュメント
https://laravel.com/docs/master/events#broadcasting-events
イベントブロードキャストとは、サーバー側で発火したイベントをクライアント側に配信する機構で、
そのドライバーとしてPusher、Redis、Log(開発用)の３種から選択できる。
お好みのもの選べるのって嬉しいよねー。
女子はブッフェ好きだしねー。
Pusherを使えば、リアルタイム通信の部分は外部サービスにお任せできるので
サーバー負荷などの心配もしなくていいんだけど、もちろんお値段がかかります。
「実装も楽々で、サーバの負荷も気にしなくていいなんて、すごいわ〜。
でも、それってお高いんでしょう？」
って思うよね。
以下が価格表です。
会社で見たときは画面が小さくてフリープランが見えてなかったんだけど、
家で確認したら一番下にフリープランが書いてあった。
あと、コネクションという単位がよく分からず、これが1回の接続と仮定すると
「すごい高いな.....」と思ったんだけど、ポップアップの注意書きに『同時接続ユーザー数のこと』と書いてあった。だよねーだよねーじゃなきゃべらぼうに高いよねー。
そうだとするとログインユーザーが同時に1万人以下であれば
月々5万円以下で運用できそう。割と妥当なお値段でした。
「やだやだーお安いーー」とまでは言えないけど。
| フリープラン | スタートアップ | プロ | ビジネス | プレミアム | エンタープライズ | |
|---|---|---|---|---|---|---|
| 価格 | 無料 | 49$(約5,000円) | 99$(約1万円) | 299$(約3万円) | 499$(約5万円) | 要問い合わせ |
| 同時接続ユーザー数 | 最大100 | 最大500 | 最大2,000 | 最大5,000 | 最大10,000 | 10,000以上 |
| 送受信メッセージ数 | 20万／日 | 100万／日 | 400万／日 | 1,000万／日 | 2,000万／日 | 2,000万以上／日 |
RedisとSocket.ioを使う方法は、タダでできるしいいかなーと思ったのですが、
サーバーの負荷がどのくらいかかるのか、正直よく分からない。
Socket.ioはWebsocketで繋げられない場合はLong pollingで繋げるらしいので、
ブラウザーサポート的には心配なさそう。
Websocketのほうがいろいろと負荷的にメリットが多いと書いてある場合が多いけど
比較的に新しい技術のため、やや心配性のベル子さんは実地検査データが欲しくて更に調べてみました。
http://blog.flect.co.jp/labo/2014/04/websocket-8124.html
ロードバランシングに工夫が必要とか、サーバを冗長化とか、SSL接続じゃないとダメとか
ファイアーウォールに注意とかいろいろ書いてあって、
インフラ強くないと怖そう。。。だ。。な。。
ただ、この人たちは絶対にゲームとか作ってる人たちだから、そこまで通知って通信量多くないよね？って気もする。
https://gist.github.com/nulltask/89e6f36e194c951697a0
http://uorat.hatenablog.com/entry/2015/08/30/190613
あったぞ、テストしてる記事！
Cometのネットワークリソースの消費量はWebsocketの2~3倍。
Cometの場合はクライアント数によって遅延が増える。
このためかどうか分からないけど、結構Cometについてはあまりいいこと書いてある記事がなかった。
OSリソース面でもWebsocketは優位そう。
でもWebsocketと比べちゃえば、当然って気もする。
http://builder.japan.zdnet.com/sp_oracle/weblogic/35044482/2/
しかし、問題はRedis。
RedisとはNoSQLに分類されるインメモリKVS（キー・バリュー・ストア）で
「驚くほどレスポンスが速い」という噂。
インメモリとはデータをハードディスクなどには書き込まずメモリ上で管理するしくみのことで、RDB などに比べ非常に高速にデータを出し入れできるという特徴があります。
実は、2年くらい前にドットインストールをみながら試してみたことがあるんだけど、
当時は「使い方は分かったけど、何に使ったらいいものなのか分かりません（ドヤ顔）」というのが感想だった。
サーバのメモリを圧迫したりしないのかな？
たぶんするよね？
でも、Pub/Subのセッション共有だけでしか使わないようだし、そんなに気にしなくていいのかな？
あと、Node.jsが接続を無制限に受け付けると、その分リソースを食うのでは？
WebsocketはHTTPみたいに同時接続制限がないと書いてあった。
よく分からないけど、Redis使ってるから、Socket.io専用サーバを立てればいいのか？
WebSocketサーバーを冗長化した際に各々のサーバーでsubscribeしておき、連携したいデータをpublishすればサーバー間連系はこの中継サーバーに委ねられます。
なるほど、難しい用語がいっぱいだね！
じゃあ、次は代表的なサービスたちがどんな手法でリアルタイム通知をやってるか調べてみるぞ。
TwitterのStreaming APIはServer-Sent Eventsの規格ができる前からあるやつだから
独自のフォーマットらしいけど、一応種類的にはServer-Sent Eventsらしい。
http://qiita.com/mpyw/items/664390c945af6c035547
ここで、一応、標準規格のServer-Sent Eventsについて調べてみる。
ブラウザ実装状況は以下のとおり。
Server-Sent Eventsのブラウザ実装状況
http://caniuse.com/#search=Server-sent%20events
MS Edgeは実装検討中のようだけど、IEは全滅。
Can I UseだとだとW3CではなくWHATWGのLiving Standardにリンクが貼られてたけど
W3Cのドキュメントを検索したところ、現在は勧告（Recomendation）になってる。
WHATWGのLiving Standardというのは、最新の仕様を断続的にアップデートしているHTMLの標準仕様書で、
ブラウザの中の人は、だいたいこちらの仕様を参照しているらしい。
W3Cの仕様更新は遅く、Living Standardから切り出されているということが、その要因のよう。
http://www.publickey1.jp/blog/15/html5whatwgw3c_tpac_2015.html
話がそれたけど、気にしない。気にしない。
サーバサイドpush技術としてのWebsocketとServer-sent eventsの特徴比較
http://qiita.com/suin/items/e33af700ceb678d40a67
だけど、そもそも論でごめん、Laravelでどうやって実装すればいいのかよく分からない。
実装例があったわよー、奥さん。
http://zrashwani.com/server-sent-events-example-laravel/#.VwqYwxOLRE4
次はfaceboook。
めっちゃ明らかなLong polling！
Long Pollingは、普通のPollingより負荷が高いことが、さっき読んだ記事で分かったけど、
これももしかしたら、一種のServer-sent events（独自）なのかも？
Server-sent eventsはLong Pollingの発展版と書いてあったし。
じゃあ最後にyammer。
これもLong pollingっぽい。
pollingのajax自体は3秒ごとに投げて、サーバー側で最大60秒保留しておいて返す。
みたいなことなのかもしれない。
なるほど、ゲームなどのリアルタイム性を要求される場合はwebsocketマストだけど、
通知くらいならLong polling(独自Server-sent Events)でいいのかもね。
あとはサーバにどれだけ負荷がかかってくるかってことか。。。
参考にしてる人たちはサーバ富豪そうだしな。。。
結論：
いやーいっぱい調べたけど、とりあえずAjaxで更新をチェックさせておけば、あとからLong pollingにはできそうだから、とりあえずそうするよ。
いろいろやって、あとでサーバのほうの設定でてこずっちゃうと困るし。
どうでもいいけど、テイラースウィフトのスタイルとユーモアセンスが羨ましすぎる。
http://www.gizmodo.jp/2016/04/taylor_swift.html
お疲れ様でした！！
[5回]
(Model View ViewModel)
モデル、ビュー、ビューモデルからなるMVCの派生デザインパターンのこと。MVVMの特徴は、ビューとビューモデルの双方向データバインディング。
双方向データバインディングとはビューのデータとビューモデルのデータを結びつけて、どちらかが変更されたら、もう一方も更新するという仕組みのこと。
(Model View Whatever)
モデル、ビュー、その他の何かしらの構造を持つアプリケーションデザインパターンのこと。
Angularの開発者がMV*というフレームワークが世の中に溢れ、議論が絶えないことから、Angularはビューとモデルと何かしらで成り立つMVWフレームワークだと宣言したことに由来。
余談だが、アメリカ人は「どうでもいい」と言いたいときに"Whatever"と独特のリズムをつけて言う。長々と彼氏の自慢をされたときに「つーか、どーでもいいんだけど」というニュアンスで使う。もちろんケンカを売る言葉だが、非常によく使われる。
JavaScriptユーティリティライブラリ。JavaScriptでコーディングする際に、あったら便利な関数を拡張するライブラリ。jQueryと被っているメソッドも。
またunderscore.jsを使うことによりJavaScriptで関数型プログラミング的なコードを書くことができるらしい。
JavaScript MV*フレームワーク。JSフレームワークの先駆けにして愛用者多数。
underscore.jsに依存。部分的にjQueryに依存。
標準では双方向データバインディングがない。
Backbone.jsのViewまわりの機能を拡張するプラグイン。
Backbone.jsのデータバインディング機能を強化するプラグイン。
これを使うことで双方向データバインディングができるようになる。
先発のJavaScript MVVMフレームワーク。宣言型双方向データバインディングが特徴。
シンプルで学習コスト低め。レガシーブラウザーをサポート。
Googleが開発しているJavaScript MVWフレームワーク。
JavaScriptフレームワークと言えばAngularのことを指すと言っても過言ではない最も有名なフレームワーク。フルスタックで機能は豊富だが、学習コストが高いことで知られる。レガシーブラウザーにも対応している。1.x系と全く互換性のない2系がリリース予定という衝撃展開。
facebook社製で、UIに特化したJavaScriptライブラリ。MVCのViewに特化したライブラリで一方向データバインディングが特徴。コンポーネント指向。
仮想DOMの採用で、差分のみをレンダリングするため、高速な処理が可能と言われている。大規模アプリケーションのVeiw部分に使用されることを想定して作られている。
React自体はシンプルで学習コスト低めだが、Flux実装しようとすると学習コストが高くなる。ViewだけのフレームワークなのにAngularと同等のファイルサイズがある。
当初はBackboneなどのMV*フレームワークと組み合わせて使われることが多かったが、最近ではオレオレFlux実装かFluxフレームワークと組み合わせて使うのが一般的になってきた。
仮想DOMを採用しているため、DOMを直接触りに行くjQueryとの共存には、コツが要る、というよりやめたほうがいい気がする。
Reactが採用したことで話題になった。仮想的なDOMをJSオブジェクトで構築し、そのツリーの差分を検出することで、実際のDOMでは差分のみを書き換える。こうすることによりDOMの更新や書き換える際のコストが大幅に減る。仮想DOMのみの専用ライブラリも存在する。また、レンダリング速度の問題だけでなく、素のJSでDOMを構築するためサーバーサイドでも利用できる。
Angular2では仮想DOMが採用される予定らしい。
XMLに似ているJavaScriptの文法拡張。Reactはテンプレート部分にこのシンタックスを使うことを推奨している。HTMLに似ているため、分かりやすい。JSXで書いた場合はJSXTransformer.jsを読み込ませるか、プリコンパイルする必要がある。JSXTransformer.jsを読み込ませるほうは変換にコストがかかるためプロダクション環境では推奨されていない。
MVCと比較されるfacebookの人が提唱しはじめたwebアプリケーションのアーキテクチャ概念のこと。
アプリケーションの処理フローが一方向のみに流れるデザインパターンにカッコいい名前をつけてみたということ。いわゆるObserverパターン！！
名前がカッコいいので、みんな言ってみたくなったしやってみたくなった。たぶんそんな感じで、いろんなフレームワークやオレオレ実装が氾濫した。
後発のFluxフレームワーク。乱立するFluxフレームワークの中で後から登場し、人気を得た。現在、Fluxフレームワークの中で一番スタンダード。だが、触ってみた人のレビューを読むと、「これってFluxなのかな？」という疑問が書かれている。公式ドキュメントにも「Fluxかと聞かれたら、YesでもありNoでもある」とある。
後発のJavaScript MVVMフレームワーク。分かりやすくシンプルなAPIと双方向データバインディングが特徴。後発フレームワークのため、先発フレームワークのいいとこどり感がある。AngularJSに影響を受けている。
IE9以上のモダンブラウザを対象としているため、ライブラリ自体も軽量。
AngularJSのようなフルスタックJSフレームワークに比べて機能は少なめだが、シンプルで学習コストが低い。他のフレームワークとの連携が考慮されている。
他に有名なMVVMフレームワークとしてKnockout.jsがある。
後発のため、日本語での解説記事は多くないが、ドキュメントが充実していてボランティアにより翻訳されている。だが個人的には、この翻訳がほぼ直訳なので、原文ドキュメントも同時に参照することをオススメする。
Fluxにインスパイアされて作られたVue.js用のアプリケーションアーキテクチャ。Vuexの他に、Vue.jsで中〜大規模アプリを開発する場合、Reduxと合わせるという選択肢もドキュメントでは、提示されている。
シングルページアプリケーションのこと。長すぎるのでイケてる人のブログ記事などでは、ほとんどこの表記。
シングルページアプリケーションとはユーザーがWebアプリケーションを使っている間、ページ全体のロードが発生せず、単一のページで完結するアプリケーションのこと。ネイティヴアプリのような優れたレスポンスとユーザーエクスペリエンスが提供できるとして、近年、注目を集めている。
しかしSPA特有の問題として、初期ロードが遅くなる、クローラにうまくインデックスしてもらえないなどの問題がある。
サーバーサイドレンダリングのこと。
シングルページアプリケーションでは、初期ロード時にブラウザがJSを評価した後で、サーバからデータを取得し、それからレンダリングを開始するため、初回のロードがどうしても遅くなる。
さらにクローラはJavaScriptをブラウザと同等に解釈できないため、空のWebページとしてインデックスされてしまうというSEO上の問題もあった。
昨年の10月に、Googleが公式にAjaxクロールのための推奨構成の廃止を宣言したことにより、Google、または一般的なサーチエンジンのクローラはSPAをブラウザ並みに解釈すると伝えられたが、SPAの性質上、コンテンツの100%がクロールされるのかは実際のところ分からない。
これらの理由から初回ロード時のみ、サーバーサイド(node.js)でHTMLを構築してレンダリングさせるという解決策があり、これをサーバーサイドレンダリングと呼ぶ。
サーバーサイドレンダリングに対応しているフレームワークは、現状で、ReactやEmberなど限定されている。
読み方はアイソモーフィック。「同形の」という意味の形容詞。フロントエンドとバックエンドでコードを共有するという設計思想を表現する際に使われるキーワード。
最近では同じ意味で、UniversalなJSと表現されることもある。どんな環境でも使えるという意味合いから。
例）Isomorphicなフレームワーク。
isomorphic化。
isomorphicでpluggableなFlux実装。
3番目を分かりやすく言い換えると、「フロントエンドとバックエンドでコードが共有できて、さらに着脱が可能な、処理フローが一方向のみに流れるアーキテクチャを採用したアプリケーション実装」ということ。
3番目はFluxibleというyahooが開発したFluxフレームワークの説明において見られる表現。
HTML5で拡張されたブラウザの履歴情報を操作するAPI。
シングルページアプリケーションや非同期によるページ更新を行う場合、同一ページ内でコンテンツが更新されるためURLが変わらない。そのため、ユーザーが直接URLを叩いてコンテンツを読みに行ったり、ブラウザの前後ボタンを使用しての前後ページへのアクセスができなくなってしまう。それを解決するためHistory APIを使用してスクリプト上からURLを変更する。
オブジェクト指向プログラミング、関数型プログラミングなどと同様のプログラミングパラダイムの一つ。
パラダイムとは、ある時代に、「これがオレの考える◯◯」的なことを言い出した人に、多くの人が賛同して捲き起こる特定分野においての潮流のこと。
リンク先からの引用だが、「データフローの宣言によって、片方の変化を他方に自動で伝播させる」というのがリアクティブプログラミングの基本的な考え方で、MVVMに見られるデータバインディングの仕組みがこれに当たる。
また、リアクティブプログラミングの新たなアプローチとして近年注目されているものに関数型リアクティブプログラミング(FRP)というものがあり、リアクティブプログラミングに関数型プログラミングの思想を加えたものということのようだ。
単にリアクティブプログラミングと言った場合、こちらの関数型リアクティブプログラミングのほうを指すことが多い。
そもそも関数型プログラミング自体がよくわかっていないため、関数型リアクティブプログラミングが何なのかは、難しくてよく分からなかった。だから、知りたい人はリンク先を参照してほしい。
たぶん、非同期処理が多いとコールバック地獄に陥るし何かと面倒くさいから、そうならないためにイベントを配列のようなストリームという箱に入れて、それを使って何やかんやするよ！みたいなことだと思う。
https://html5experts.jp/ahomu/13333/
http://qiita.com/hirokidaichi/items/9c1d862099c2e12f5b0f
関数型リアクティブプログラミングのこと。長いので、イケてる人のブログではだいたいこの表記。
関数型リアクティブプログラミング言語。純粋関数型プログラミング言語Haskellをベースに作られた静的型付けされた言語。
Elmで書かれたコードはhtml/CSS/JavaScriptにコンパイルされる。
.NETのReactive ExtensionsというライブラリのJS版。関数型リアクティブプログラミングJSライブラリ。JSライブラリなのでコンパイルの必要がなく読み込むだけでいい。監視可能なコレクションや配列を使って、非同期なイベントベースのプログラムを作成できるライブラリ。
http://liginc.co.jp/web/js/151272
RxJSにインスパイアされて作られた後発のFRPライブラリ。
RxJSに依存する一方向にデータが流れるFRPフレームワーク。仮想DOM、サーバーサイドレンダリングをサポート。一方向のデータフローということで、概念的にはFluxにも近いのかな？でもFRPなんですよね？ということで、最も私にとって何がなんだか分からないフレームワーク。
開発者はFlux Challengeという、あるお題のFlux実装を募集し検証するということをやっている。Flux実装は複数の非同期処理をエレガントに行えるのかということに疑問を持っており、それを検証しようとしている模様。
facebook社製、不変データコレクションを扱うためのライブラリ。
コンソールから実行できるWebKitベースのヘッドレスブラウザ。ヘッドレスブラウザとはGUIのないブラウザのこと。
JSの自動テストで使用する人が多い。
PhantomJSのラッパーライブラリ。テストコードがより簡潔に記述できる。v2になり内部ブラウザがPhantomJSからElectronベースとなり視覚的にテストしている様子が確認できるようになった。
Githubが開発しているHTML/CSS/JavaScriptを使ってクロスプラットフォームのデスクトップアプリケーションが作成できるフレームワーク。Atomエディタのネイティヴ部分をSDKとして公開したのが始まり。オープンソースのWebブラウザであるChromiumを内蔵しているため、ランタイムのいらない独立したアプリとして動作する。
SlackのWindows版でも使われている。
ブラウザを内蔵しているためファイルサイズが大きくなる。
Angularチームが開発したNode.jsで動作するJSテストランナー。JasmineやMochaなどのテストフレームワークを使用してテストを行う。
Angular標準のJSテスティングフレームワーク。BDDを採用しておりRSpecと似た記法で記述する。
JavaScriptテストフレームワーク。Nodeモジュールをインストールしてコマンドラインでテスト実行する方法と、htmlで読み込ませてブラウザで実行する方法がある。TDDとBDDどちらの記法でも書ける。アサーションライブラリはバンドルされてないのでお好みのライブラリを選択する必要がある。アサーションライブラリと言うのがイマイチよく分からないけど、it.should.have.('hogehoge')みたいなテストコードで出てくる表現を記述できるようにするためのライブラリっぽい。有名なのはChai、shouldなど。
ES6対応のJavaScript構文チェックツール。拡張性が高く、柔軟性のあるルール設定が可能。gulpのタスクに組み込んで使える。JSHintから乗り換える人が出てきている後発のリントツール。
http://qiita.com/inuscript/items/dcf48f56d8f484c0a1a8
HTML5のCanvasを使ったアニメーションが作れるフレームワーク。
何かと紛らわしい名前のため、まとめに入れてみた。
ということで数回にわたりお送りしたフロントエンド用語まとめ、いかがだったでしょうか。途中で私のココロの声がダダ漏れしてしまうハプニングもありましたが、概ね冷静な解説ができたかと思います。
思っていたよりたくさんありましたねー。
こうやって見ているとRubyがWeb業界に与えた影響は非常に大きいですね。
あと、フロントエンドにもサーバーサイドの文化が流入してきていて、逆にサーバーサイドにもフロントエンドの文化が流入してきていて、お互いに影響を与え合っているという感じでしょうか。
昔は住む世界が違うと思ってた大嫌いなアイツ。だけど、最近はなんだかいつも気になって仕方ない。これって、もしかして恋？？ううん、絶対ちがう。でも…。
うん、一番いい時期だな。
こういうおニューな技術の動向について、少し流し読みしておくと、イケてる人に話しかけられたときに
「ああ、Electronですね！知ってますよー。マカロンよりもっちりしてて美味しいですよねー」という定番のギャグを飛ばさなくて済むし、「ヘイ、シリー」を連呼しなくていいので安心です。
(先日、飲み会で酔っぱらってSiriさんに何度も絡んだら、Siriがガチギレして、再起動するまで何の質問にも答えてくれなくなったのはここだけの秘密）
でも専門用語とか横文字とかいっぱい言うと、オタク感（本来の姿）が出てしまいやや気持ち悪いので、「えーそれなんですかぁ？ ◯◯さんて、すごく物知りでイケメンですよねぇ」って部活の後輩風に答えたほうが、ポイント高いかもしれないです。
特に女子は、優秀だけどオタクという印象を相手に与えても何もいいことないです。マニアしか釣れないです。
冗談はさておき、コードの分離に関心が集まっていたかと思うと、むしろコードを共有しようという流れがあったりと、人はいろんなことを考えるものですね。Node.jsの人気の高まりにつれ、Webアプリケーションの世界では、フロントエンドとサーバーサイドの境界はあいまいになっているのかもしれません。
ページ遷移なしに状態を保持しながら複雑な更新を行うということは、これからはフロントエンド側のコードもきちんとした設計思想に則ってオーガナイズする必要がありそうです！
フレームワークなしでやってると、どうしてもJSが「きゃー今散らかってるから、絶対見ないでぇー」な雰囲気になってきてしまいます。
そういった意味で、ハイレベルなフロントエンド開発がこれからのWebアプリケーション構築では必須になっていきそうです。
Sass、Lessもそうですが、後発が流行ったと思ったら先発が巻き返したりもしますし、Web業界の移り変わりはホントに目まぐるしいですね。
でも目まぐるしいから面白いとも言えるし、どんどん便利になっていくとも言えます。
新しいだけじゃなくて、すごいだけじゃなくて、クライアントにもエンジニアにもうれしい、そんなフロントエンド構成を選択していきたいものですね！！あと未来の自分と同僚のためにも！！
（それが弊社の社是だし）
TL;DRってまさにこういうときに使うべき。
では、また来月会おう。
[1回]
[0回]
[0回]