nanisore oishisou

Webエンジニアあるまさんのゆるふわ奮闘記。

リアルタイムな通知を実装したいから色々調べてみた

リアルタイム通知

こんばんわー。
ベル子だよー。眠くて瞼がくっついちゃいそうだよー。
頑張って調べすぎたよー。いつものことだけどねー。
何かを調べだすと時間を忘れてしまう病だと思うんだ、私。
とにかく今は、鬼かわいいパンケーキが食べたいってことしか考えられない。

では、まずリアルタイムな通知って何かというと

ベル子とイケメンが[ベル子SNS]というSNSを使っています。
ベル子がコメントをうpすると、イケメンのほうのブラウザ画面に
「セクシー美女からのコメントが1件あります」のような通知が
ページリロードなしで表示される。

というもの。
要するにTwitterのあれ。

まず、リアルタイムな通知を可能にする方法には、以下のものがある。

・Polling

古典的な方法で、一定時間ごとにサーバに更新を問い合わせる手法。
ページ全体を取得すると高負荷となるため、Ajax通信でリクエストし変更部分を更新するのが最近では主流。
リアルタイム性に欠ける。
サーバー負荷が高い。
無駄なリクエストが発生する。
といった問題点がある。

・Long polling（Comet）

Pollingではリアルタイム性に欠けるため、考えだされた手法。
クライアントから送信されたリクエストをサーバがいったん保留し、
サーバ側でイベントが発生した際に任意のタイミングでレスポンスを返す手法。
リアルタイム性は高い。
無駄な問い合わせは発生しないが、長時間HTTPコネクションを占有してしまう。
一度クライアントにPushしたら、またクライアントからのリクエストを待たないといけない。
タイミングによってはタイムラグが発生する。

・Server-Sent Events（Streaming）

Long pollingの発展版で、HTML5で標準化されている手法。
サーバーはイベントが発生したら、クライアントに断片データを返す。
レスポンスの一部を送信することによりクライアントとの通信が切れず
Long pollingと違い再度リクエストする必要がない。
新規格なのでブラウザがSSEに対応している必要があるが、IEは全滅。
Edgeも検討中でまだ対応はしていない。
polyfillで対応可能。

・Websocket

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万円以下で運用できそう。割と妥当なお値段でした。
「やだやだーお安いーー」とまでは言えないけど。

https://pusher.com/pricing

フリープランスタートアッププロビジネスプレミアムエンタープライズ
価格 無料 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

お疲れ様でした！！

フロントエンドをモダンにするための用語まとめ（４）大好評だけど、ごめんね最終回なの

フロントエンド
こんばんは。ベル子です。 

フロントエンドをモダンにするための用語まとめシリーズの最新号です。

今回はいつもに増して、長いっす。
そして一番おもしろいパートに来ました。
今までのはまとめは、実はちょっとした前菜だったのです！！

そして、フロントエンドは、さながら群雄割拠の戦国の世だということを改めて思い知りました。
ちなみに私は無双ではガラシャ推しで、三国では大喬使いです。

このシリーズのバックナンバーをご覧になりたい方は、
下のリンクより、よーよーちぇけらっちょしてみて下さい。

フロントエンドをモダンにするための用語まとめ（１） 
フロントエンドをモダンにするための用語まとめ（２） 
フロントエンドをモダンにするための用語まとめ（３）

【MVVM】

(Model View ViewModel)
モデル、ビュー、ビューモデルからなるMVCの派生デザインパターンのこと。MVVMの特徴は、ビューとビューモデルの双方向データバインディング。
双方向データバインディングとはビューのデータとビューモデルのデータを結びつけて、どちらかが変更されたら、もう一方も更新するという仕組みのこと。

【MVW】

(Model View Whatever)
モデル、ビュー、その他の何かしらの構造を持つアプリケーションデザインパターンのこと。
Angularの開発者がMV*というフレームワークが世の中に溢れ、議論が絶えないことから、Angularはビューとモデルと何かしらで成り立つMVWフレームワークだと宣言したことに由来。
余談だが、アメリカ人は「どうでもいい」と言いたいときに"Whatever"と独特のリズムをつけて言う。長々と彼氏の自慢をされたときに「つーか、どーでもいいんだけど」というニュアンスで使う。もちろんケンカを売る言葉だが、非常によく使われる。

【underscore.js】

JavaScriptユーティリティライブラリ。JavaScriptでコーディングする際に、あったら便利な関数を拡張するライブラリ。jQueryと被っているメソッドも。
またunderscore.jsを使うことによりJavaScriptで関数型プログラミング的なコードを書くことができるらしい。

【Backbone.js】

JavaScript MV*フレームワーク。JSフレームワークの先駆けにして愛用者多数。
underscore.jsに依存。部分的にjQueryに依存。
標準では双方向データバインディングがない。

【Marionette.js】

Backbone.jsのViewまわりの機能を拡張するプラグイン。

【Stickit.js】

Backbone.jsのデータバインディング機能を強化するプラグイン。
これを使うことで双方向データバインディングができるようになる。

【Knockout.js】

先発のJavaScript MVVMフレームワーク。宣言型双方向データバインディングが特徴。
シンプルで学習コスト低め。レガシーブラウザーをサポート。

【AngularJS】

Googleが開発しているJavaScript MVWフレームワーク。
JavaScriptフレームワークと言えばAngularのことを指すと言っても過言ではない最も有名なフレームワーク。フルスタックで機能は豊富だが、学習コストが高いことで知られる。レガシーブラウザーにも対応している。1.x系と全く互換性のない2系がリリース予定という衝撃展開。

【React.js】

facebook社製で、UIに特化したJavaScriptライブラリ。MVCのViewに特化したライブラリで一方向データバインディングが特徴。コンポーネント指向。
仮想DOMの採用で、差分のみをレンダリングするため、高速な処理が可能と言われている。大規模アプリケーションのVeiw部分に使用されることを想定して作られている。
React自体はシンプルで学習コスト低めだが、Flux実装しようとすると学習コストが高くなる。ViewだけのフレームワークなのにAngularと同等のファイルサイズがある。
当初はBackboneなどのMV*フレームワークと組み合わせて使われることが多かったが、最近ではオレオレFlux実装かFluxフレームワークと組み合わせて使うのが一般的になってきた。
仮想DOMを採用しているため、DOMを直接触りに行くjQueryとの共存には、コツが要る、というよりやめたほうがいい気がする。

【仮想DOM】

Reactが採用したことで話題になった。仮想的なDOMをJSオブジェクトで構築し、そのツリーの差分を検出することで、実際のDOMでは差分のみを書き換える。こうすることによりDOMの更新や書き換える際のコストが大幅に減る。仮想DOMのみの専用ライブラリも存在する。また、レンダリング速度の問題だけでなく、素のJSでDOMを構築するためサーバーサイドでも利用できる。
Angular2では仮想DOMが採用される予定らしい。

【JSX】

XMLに似ているJavaScriptの文法拡張。Reactはテンプレート部分にこのシンタックスを使うことを推奨している。HTMLに似ているため、分かりやすい。JSXで書いた場合はJSXTransformer.jsを読み込ませるか、プリコンパイルする必要がある。JSXTransformer.jsを読み込ませるほうは変換にコストがかかるためプロダクション環境では推奨されていない。

【Flux】

MVCと比較されるfacebookの人が提唱しはじめたwebアプリケーションのアーキテクチャ概念のこと。
アプリケーションの処理フローが一方向のみに流れるデザインパターンにカッコいい名前をつけてみたということ。いわゆるObserverパターン！！
名前がカッコいいので、みんな言ってみたくなったしやってみたくなった。たぶんそんな感じで、いろんなフレームワークやオレオレ実装が氾濫した。

【Redux】

後発のFluxフレームワーク。乱立するFluxフレームワークの中で後から登場し、人気を得た。現在、Fluxフレームワークの中で一番スタンダード。だが、触ってみた人のレビューを読むと、「これってFluxなのかな？」という疑問が書かれている。公式ドキュメントにも「Fluxかと聞かれたら、YesでもありNoでもある」とある。

【Vue.js】

後発のJavaScript MVVMフレームワーク。分かりやすくシンプルなAPIと双方向データバインディングが特徴。後発フレームワークのため、先発フレームワークのいいとこどり感がある。AngularJSに影響を受けている。
IE9以上のモダンブラウザを対象としているため、ライブラリ自体も軽量。
AngularJSのようなフルスタックJSフレームワークに比べて機能は少なめだが、シンプルで学習コストが低い。他のフレームワークとの連携が考慮されている。
他に有名なMVVMフレームワークとしてKnockout.jsがある。
後発のため、日本語での解説記事は多くないが、ドキュメントが充実していてボランティアにより翻訳されている。だが個人的には、この翻訳がほぼ直訳なので、原文ドキュメントも同時に参照することをオススメする。

【Vuex】

Fluxにインスパイアされて作られたVue.js用のアプリケーションアーキテクチャ。Vuexの他に、Vue.jsで中〜大規模アプリを開発する場合、Reduxと合わせるという選択肢もドキュメントでは、提示されている。

【SPA】

シングルページアプリケーションのこと。長すぎるのでイケてる人のブログ記事などでは、ほとんどこの表記。
シングルページアプリケーションとはユーザーがWebアプリケーションを使っている間、ページ全体のロードが発生せず、単一のページで完結するアプリケーションのこと。ネイティヴアプリのような優れたレスポンスとユーザーエクスペリエンスが提供できるとして、近年、注目を集めている。
しかしSPA特有の問題として、初期ロードが遅くなる、クローラにうまくインデックスしてもらえないなどの問題がある。

【SSR】

サーバーサイドレンダリングのこと。
シングルページアプリケーションでは、初期ロード時にブラウザがJSを評価した後で、サーバからデータを取得し、それからレンダリングを開始するため、初回のロードがどうしても遅くなる。
さらにクローラはJavaScriptをブラウザと同等に解釈できないため、空のWebページとしてインデックスされてしまうというSEO上の問題もあった。
昨年の10月に、Googleが公式にAjaxクロールのための推奨構成の廃止を宣言したことにより、Google、または一般的なサーチエンジンのクローラはSPAをブラウザ並みに解釈すると伝えられたが、SPAの性質上、コンテンツの100%がクロールされるのかは実際のところ分からない。
これらの理由から初回ロード時のみ、サーバーサイド(node.js)でHTMLを構築してレンダリングさせるという解決策があり、これをサーバーサイドレンダリングと呼ぶ。
サーバーサイドレンダリングに対応しているフレームワークは、現状で、ReactやEmberなど限定されている。

【Isomorphic】

読み方はアイソモーフィック。「同形の」という意味の形容詞。フロントエンドとバックエンドでコードを共有するという設計思想を表現する際に使われるキーワード。
最近では同じ意味で、UniversalなJSと表現されることもある。どんな環境でも使えるという意味合いから。

例）Isomorphicなフレームワーク。
isomorphic化。
isomorphicでpluggableなFlux実装。

3番目を分かりやすく言い換えると、「フロントエンドとバックエンドでコードが共有できて、さらに着脱が可能な、処理フローが一方向のみに流れるアーキテクチャを採用したアプリケーション実装」ということ。
3番目はFluxibleというyahooが開発したFluxフレームワークの説明において見られる表現。

【History API】

HTML5で拡張されたブラウザの履歴情報を操作するAPI。
シングルページアプリケーションや非同期によるページ更新を行う場合、同一ページ内でコンテンツが更新されるためURLが変わらない。そのため、ユーザーが直接URLを叩いてコンテンツを読みに行ったり、ブラウザの前後ボタンを使用しての前後ページへのアクセスができなくなってしまう。それを解決するためHistory APIを使用してスクリプト上からURLを変更する。

【Reactive Programming】

オブジェクト指向プログラミング、関数型プログラミングなどと同様のプログラミングパラダイムの一つ。
パラダイムとは、ある時代に、「これがオレの考える◯◯」的なことを言い出した人に、多くの人が賛同して捲き起こる特定分野においての潮流のこと。
リンク先からの引用だが、「データフローの宣言によって、片方の変化を他方に自動で伝播させる」というのがリアクティブプログラミングの基本的な考え方で、MVVMに見られるデータバインディングの仕組みがこれに当たる。
また、リアクティブプログラミングの新たなアプローチとして近年注目されているものに関数型リアクティブプログラミング(FRP)というものがあり、リアクティブプログラミングに関数型プログラミングの思想を加えたものということのようだ。
単にリアクティブプログラミングと言った場合、こちらの関数型リアクティブプログラミングのほうを指すことが多い。
そもそも関数型プログラミング自体がよくわかっていないため、関数型リアクティブプログラミングが何なのかは、難しくてよく分からなかった。だから、知りたい人はリンク先を参照してほしい。
たぶん、非同期処理が多いとコールバック地獄に陥るし何かと面倒くさいから、そうならないためにイベントを配列のようなストリームという箱に入れて、それを使って何やかんやするよ！みたいなことだと思う。
https://html5experts.jp/ahomu/13333/
http://qiita.com/hirokidaichi/items/9c1d862099c2e12f5b0f

【FRP】

関数型リアクティブプログラミングのこと。長いので、イケてる人のブログではだいたいこの表記。

【Elm】

関数型リアクティブプログラミング言語。純粋関数型プログラミング言語Haskellをベースに作られた静的型付けされた言語。
Elmで書かれたコードはhtml/CSS/JavaScriptにコンパイルされる。

【RxJS】

.NETのReactive ExtensionsというライブラリのJS版。関数型リアクティブプログラミングJSライブラリ。JSライブラリなのでコンパイルの必要がなく読み込むだけでいい。監視可能なコレクションや配列を使って、非同期なイベントベースのプログラムを作成できるライブラリ。
http://liginc.co.jp/web/js/151272

【Bacon.js】

RxJSにインスパイアされて作られた後発のFRPライブラリ。

【Cycle.js】

RxJSに依存する一方向にデータが流れるFRPフレームワーク。仮想DOM、サーバーサイドレンダリングをサポート。一方向のデータフローということで、概念的にはFluxにも近いのかな？でもFRPなんですよね？ということで、最も私にとって何がなんだか分からないフレームワーク。
開発者はFlux Challengeという、あるお題のFlux実装を募集し検証するということをやっている。Flux実装は複数の非同期処理をエレガントに行えるのかということに疑問を持っており、それを検証しようとしている模様。

【immutable.js】

facebook社製、不変データコレクションを扱うためのライブラリ。

【PhantomJS】

コンソールから実行できるWebKitベースのヘッドレスブラウザ。ヘッドレスブラウザとはGUIのないブラウザのこと。
JSの自動テストで使用する人が多い。

【Nightmare】

PhantomJSのラッパーライブラリ。テストコードがより簡潔に記述できる。v2になり内部ブラウザがPhantomJSからElectronベースとなり視覚的にテストしている様子が確認できるようになった。

【Electron】

Githubが開発しているHTML/CSS/JavaScriptを使ってクロスプラットフォームのデスクトップアプリケーションが作成できるフレームワーク。Atomエディタのネイティヴ部分をSDKとして公開したのが始まり。オープンソースのWebブラウザであるChromiumを内蔵しているため、ランタイムのいらない独立したアプリとして動作する。
SlackのWindows版でも使われている。
ブラウザを内蔵しているためファイルサイズが大きくなる。

【Karma】

Angularチームが開発したNode.jsで動作するJSテストランナー。JasmineやMochaなどのテストフレームワークを使用してテストを行う。

【Jasmine】

Angular標準のJSテスティングフレームワーク。BDDを採用しておりRSpecと似た記法で記述する。

【Mocha】

JavaScriptテストフレームワーク。Nodeモジュールをインストールしてコマンドラインでテスト実行する方法と、htmlで読み込ませてブラウザで実行する方法がある。TDDとBDDどちらの記法でも書ける。アサーションライブラリはバンドルされてないのでお好みのライブラリを選択する必要がある。アサーションライブラリと言うのがイマイチよく分からないけど、it.should.have.('hogehoge')みたいなテストコードで出てくる表現を記述できるようにするためのライブラリっぽい。有名なのはChai、shouldなど。

【ESLint】

ES6対応のJavaScript構文チェックツール。拡張性が高く、柔軟性のあるルール設定が可能。gulpのタスクに組み込んで使える。JSHintから乗り換える人が出てきている後発のリントツール。
http://qiita.com/inuscript/items/dcf48f56d8f484c0a1a8

【CreateJS】

HTML5のCanvasを使ったアニメーションが作れるフレームワーク。
何かと紛らわしい名前のため、まとめに入れてみた。


ということで数回にわたりお送りしたフロントエンド用語まとめ、いかがだったでしょうか。途中で私のココロの声がダダ漏れしてしまうハプニングもありましたが、概ね冷静な解説ができたかと思います。

思っていたよりたくさんありましたねー。
こうやって見ているとRubyがWeb業界に与えた影響は非常に大きいですね。
あと、フロントエンドにもサーバーサイドの文化が流入してきていて、逆にサーバーサイドにもフロントエンドの文化が流入してきていて、お互いに影響を与え合っているという感じでしょうか。

昔は住む世界が違うと思ってた大嫌いなアイツ。だけど、最近はなんだかいつも気になって仕方ない。これって、もしかして恋？？ううん、絶対ちがう。でも…。

うん、一番いい時期だな。

こういうおニューな技術の動向について、少し流し読みしておくと、イケてる人に話しかけられたときに
「ああ、Electronですね！知ってますよー。マカロンよりもっちりしてて美味しいですよねー」という定番のギャグを飛ばさなくて済むし、「ヘイ、シリー」を連呼しなくていいので安心です。
(先日、飲み会で酔っぱらってSiriさんに何度も絡んだら、Siriがガチギレして、再起動するまで何の質問にも答えてくれなくなったのはここだけの秘密）

でも専門用語とか横文字とかいっぱい言うと、オタク感（本来の姿）が出てしまいやや気持ち悪いので、「えーそれなんですかぁ？ ◯◯さんて、すごく物知りでイケメンですよねぇ」って部活の後輩風に答えたほうが、ポイント高いかもしれないです。
特に女子は、優秀だけどオタクという印象を相手に与えても何もいいことないです。マニアしか釣れないです。

冗談はさておき、コードの分離に関心が集まっていたかと思うと、むしろコードを共有しようという流れがあったりと、人はいろんなことを考えるものですね。Node.jsの人気の高まりにつれ、Webアプリケーションの世界では、フロントエンドとサーバーサイドの境界はあいまいになっているのかもしれません。

ページ遷移なしに状態を保持しながら複雑な更新を行うということは、これからはフロントエンド側のコードもきちんとした設計思想に則ってオーガナイズする必要がありそうです！
フレームワークなしでやってると、どうしてもJSが「きゃー今散らかってるから、絶対見ないでぇー」な雰囲気になってきてしまいます。
そういった意味で、ハイレベルなフロントエンド開発がこれからのWebアプリケーション構築では必須になっていきそうです。

Sass、Lessもそうですが、後発が流行ったと思ったら先発が巻き返したりもしますし、Web業界の移り変わりはホントに目まぐるしいですね。
でも目まぐるしいから面白いとも言えるし、どんどん便利になっていくとも言えます。

新しいだけじゃなくて、すごいだけじゃなくて、クライアントにもエンジニアにもうれしい、そんなフロントエンド構成を選択していきたいものですね！！あと未来の自分と同僚のためにも！！
（それが弊社の社是だし）

TL;DRってまさにこういうときに使うべき。

では、また来月会おう。

Laravel 4.2から5.0の変更点

Laravel
おっす。オラ、ベル子。
みんな元気してたー？

この前、

Laravel 5.0から5.1の変更点

を書いてからだいぶ経ってしまいましたが、予告どおりLaravel 4.2から5.0の変更点まとめ記事をアップするよ。

と、その前に恒例の雑談を少々。

女子が無駄になんでも
「超かわいいー」
「マジかわいいねー」
「ウケるーかわいいー」
って言い合ってるのを誰でも一度は聞いたことがあると思います。

今日、Githubのタコ足の猫のステッカーを会社の人からお裾分けしてもらったんですが、
それが「超かわいいー」「マジかわいいねー」「ウケるーかわいいー」だったんですね。
だけど、そういう時に女の子がいないとどうなるかっていうと
一人かわいいのコールアンドレスポンスになってしまうわけです。

Say かわいい
かわいい！！
Say かわいい
かわいい！！

by 全部俺様

孤独を愛するベル子さんも、今日ばっかりはさすがに寂しかったです。
どんな挙動不審な子でも、リア充爆発しろを連呼してるような子でも、百歩譲って男の娘でもいいので、もう一人だけ女子（っぽい）プログラマーがいるといいなぁと思う今日このごろです。
真面目な話、うちの会社は女子も働きやすい職場だと思うので。
特にそう思う根拠は見つからないのですが、私が言うんだから間違いないです。

さて、では本題のLaravel 4.2から5.0への変更点まとめです。
最初のうちは4.2から5.0に以降する際につまづきやすいところを踏まえてまとめていたのですが、
最後のほうは、よく分からない機能もいっぱい出てくるので、単にドキュメントの翻訳になってしまいました。

そして、Laravelのドキュメントの日本語訳は、みなさんもご存知だと思いますがすでに訳されている方がいらっしゃいまして、その方の翻訳が素晴らしいので

いったい私は何をしたんだろう？(白目)

という気持ちになりましたが、英文を翻訳するという作業は、本当に内容を理解していないとできないことなので、そういう点で調べ物もいろいろすることになって、非常に勉強になるんですね。

ということで翻訳されてる方のページも貼っておきますので、私の翻訳と見比べて心の中で「俺は断然ベル子派だぜ！」と思っていただいても構いません。そちらを見ていただいても大体同じ内容です(´・ω・｀)


★4.2から5.0での変更点
ーーーーーーーーーーーーーーーーーーーー
▼リリースノート

・フォルダ構造
app/modelsディレクトリが削除され、代わりにappフォルダ直下に入れられるようになった。
HTTPトランスポート層に関連するクラスを格納する /Controllers /Middleware /Requests（MiddlewareとRequestsは5.0で登場した新タイプのクラス群） が app/Http 配下に配置された。
app/filters.phpは廃止され、代わりに全てのMiddlewareクラスは個別ファイルに記述できるようになり、app/Http/Middleware 配下に格納するようになった。
app/start配下にあったファイル群はapp/Providersに個別のservice providerファイルとして格納するようになった。
langファイルとviewsファイルはresourcesディレクトリ配下に配置された。
その他に、アプリケーションのロジックと関係ないディレクトリ（/config /database /storage /tests ）がapp配下から移動されルートに配置されるようになった。

・名前空間の採用
5.0から名前空間指定が必須となった。

・契約
Laravelの主要なサービスがilluminate/contracts配下にインターフェースとしてまとめられた。

・ルートキャッシュ
php artisan route:cache
route:cache artisanコマンドを実行すると、app/Http/routes.phpの代わりにキャッシュされたルートが使用されるようになり、アプリケーションルート登録時間を劇的に短くすることができる。
新たにルートを追加した際は再度コマンドを実行する必要があり、キャッシュを削除したい場合は、route:clearコマンドを実行する必要がある。
php artisan route:clear

・ルートミドルウェア
Laravel 4ではフィルターと呼んでいた機能が、5.0ではHTTPミドルウェアになった。認証フィルターとCSRFフィルターはミドルウェアに置き換えられapp/Http/Middlewareに個別のファイルとして格納されている。

・コントローラメソッドインジェクション
Classのオブジェクトをコントローラーのコンストラクタだけじゃなくて、個別のメソッドにタイプヒントで注入できるようになった。
メソッドに他のパラメータが渡されていたとしても、サービスコンテナは自動的に判別して注入してくれる。

・認証スキャフォールド
ユーザー登録、認証、パスワードリセットコントローラーが初めから用意されていて、対応するビューやusersテーブルのmigrationもデフォルトで用意されている。

・イベントオブジェクト
イベントは文字列の代わりにオブジェクトとして定義できるようになった。
イベントハンドラーはデータのリストを受け取る代わりに、イベントオブジェクトを受け取る。

・コマンド／キュー
Laravel4でのキュージョブフォーマットに加え、5ではシンプルなコマンドオブジェクトとしてキュージョブを表現できるようになった。
格納場所はapp/Commandsディレクトリに配置する。

・データベースキュー
データベースキュードライバーが追加された。
データベースソフト以外の追加パッケージを必要としないシンプルなローカルキュードライバーである。

・Laravelスケジューラー
これまでエンジニアは、定期的に実行したいCUIコマンドがある場合、そのたびにCronエントリを作成してきた。
作成したCronエントリはソース上のどこからも見つけられず、追加するにはサーバーにSSH接続する必要まであり、エンジニアたちの悩みの種となっていた。
Laravelのコマンドスケジューラーを使って、コマンドのスケジュール管理をLaravel上でスムーズで分かりやすく定義できるようになった。

・Tinker／Psysh
php artisan tinkerコマンドには、より堅牢なPHP REPLであるJustin HilmanのPsyshを利用することにした。Laravel 4で使っていたBorisを気に入ったのであれば、きっとPsyshも気に入るだろう。より優れていると言っていい。なんとWindowsでも動く！

・DotEnv
分かりづらく深い階層を有したさまざまな環境設定ディレクトリの代わりに、Laravel 5ではVance LucasのDotEnvを利用することにした。
このライブラリは環境設定をスーパーシンプルな方法で管理でき、Laravel5の環境設定をスムーズに行えるようにする。

・Laravel Elixir
Jeffrey Wayが作ったLaravel Elixirは、各種メタ言語のコンパイルや、ファイル結合をするための、スムーズで分かりやすいインターフェースを提供する。
もし、これまでGruntやGulpを学ぶことに怯えていたのなら、もう怖がることはない。Elixirを使えば、Gulpを使用してのLess、Sass、CoffeeScriptのコンパイルを超絶簡単に始められる。さらにテストまで走らせられる！

・Laravel Socialite
Laravel SocialiteはLaravel 5.0+互換パッケージとして、超絶簡単なOAuth認証機構を提供する。
現在、SocialiteはFacebook、Twitter、Google、GitHubをサポート。

・Flysystem統合
パワフルなファイルシステム抽象化ライブラリFlysystemをLaravelに導入。
Flysystemはローカル、Amazon S3、Rackspace cloud storageのすべてを１つに統合する統一されたエレガントなAPIである。
ファイルをAmazon S3に保存するのが、超簡単になった。

・フォームリクエスト
Illuminate\Foundation\Http\FormRequestクラスをextendしたフォームリクエストクラスが追加になった。このリクエストオブジェクトはコントローラーメソッドインジェクションで注入され、定型的なバリデーション用の記述をすることなく、ユーザー入力のバリデーションが行える。
注入されたクラスがフォームリクエストのインスタンスであるとLaravelサービスコンテナに認識されると、リクエストは自動的にバリデーションにかけられる。
コントローラーのアクションが呼び出されると、HTTPリクエストのinputはフォームリクエストクラスで定義されたrulesに従い検証される。そしてリクエストが検証通過しない場合はリダイレクトされ（カスタム可能）、エラーメッセージが次のリクエストの間だけ、セッションに保存される（またはJSONに変換される）。

・シンプルなコントローラリクエストバリデーション
Laravel5のベースコントローラーにValidatesRequests traitが含まれた。
このtraitは入力リクエストを検証するシンプルなvalidateメソッドを提供する。
もしフォームリクエストがアプリケーションに対して大げさだと思う場合は、こちらも利用できる。
バリデーションが通らない場合は、例外が投げられ、自動的に適切なHTTPレスポンスがブラウザーに返される。さらに、バリデーションエラーが次のリクエストの間だけセッションに保存される。もしリクエストがAjaxだった場合、LaravelはJSON記法でバリデーションエラーを返却してくれる。

・新しいジェネレーター
新しいデフォルトアプリケーション構造を補完するため、新たにArtisanジェネレーターコマンドがフレームワークに追加された。
php artisan listを参照してほしい。

・設定のキャッシュ
config:cacheコマンドで、全ての設定を１つのファイルにキャッシュできるようになった。

・Symfony VarDumper
変数のデバッグ情報を出力する人気のヘルパー関数ddが、Symfony VarDumper仕様にアップグレードされた。
出力は色分けされ、配列は折りたためるようになった。


▼アップグレードガイド

・環境設定
app/config/{environmentName}/での設定を.envに変更。.envの値にはenv('key', 'defalt value')でアクセス可能。
.envの書き方については.env.exampleを参照。

・ルート
routes.php → app/Http/routes.php

・コントローラ
app/Http/Controllers ディレクトリへ

・ルートフィルター
app/filters.phpは使用しなくなった。
代わりにauthやcsrfは
 ['before' => 'auth']
ではなく
['middleware' => 'auth']
で参照できる。
しかし、Filtersは5で削除されたわけではないのでbeforeとafterを使いカスタムフィルターを作成することはできる。

・グローバルCSRF
デフォルトで全てのルートに対して、CSRFプロテクションが効いている仕様に変更された。
CSRFプロテクションを切りたいときや、特定のルートのみに効かせたい場合は、App\Http\Karnelを修正する。

・model格納用ディレクトリ
modelファイル格納用ディレクトリはなくなり、app直下に配置するような構造になった。
もしapp/Modelsディレクトリを作ってファイルを格納したい場合は、composer.jsonのclassmapディレクティブにディレクトリを追加するのを忘れないこと。

・Eloquentキャッシュ
Eloquentのクエリーをキャッシュするrememberメソッドが削除された。Cache::remember関数を使って各自でキャッシュすること。

・Laravelキャッシャー
使用するtraitとinterfaceの名称が変更になった。
メソッドの変更はない。

・Artisanコマンド
app/commands → app/Console/Commands
Artisanコマンドのリストは
start/artisan.php → app/Console/Kernel.php のcommand配列の中へ

app/database/migrations → database/migrations

・シード
app/database/seeds → database/seeds

・グローバルIoCバインディング
start/global.php → app/Providers/AppServiceProvider.php のregisterメソッドへ

・ビュー
app/views → resources/views

・Bladeタグの変更
セキュリティの強化のため、Laravel 5.0から{{ }}と{{{ }}}のどちらを使用した際の出力もエスケープ処理されるように変更。
新たに生データを出力するタグとして{!! !!}が追加された。
もし4.2のBladeシンタックスを使用しなければならない場合は、以下の場所に以下の３文を追記のこと。
AppServiceProvider@register
\Blade::setRawTags('{{', '}}');
\Blade::setContentTags('{{{', '}}}');
\Blade::setEscapedContentTags('{{{', '}}}’);
{{-- --}}のコメント用タグも廃止になった。

・言語用ファイル
app/lang → resources/lang

・Publicディレクトリ
4.2からアップデートする際は、index.phpは5.0用を使用すること。

・テスト
app/tests → tests

・各種ファイル
Sass、Less、CoffeeScriptなどのファイルは resources/assets 配下へ格納することを推奨。

・Form&HTMLヘルパー
Form&HTMLヘルパーはデフォルト状態では使用できなくなり、使用したい場合は Laravel Collectiveなどから 自分で追加する必要がある。

・CacheManager
Illuminate\Cache\CacheManager → Illuminate\Contracts\Cache\Repository

・ページネーション
$paginator->links() → $paginator->render()
$paginator->getFrom() → $paginator->firstItem()
$paginator->getTo() → $paginator->lastItem()

getプリフィックスの削除
$paginator->getPerPage() → $paginator->perPage()
$paginator->getCurrentPage() → $paginator->currentPage()
$paginator->getLastPage() → $paginator->lastPage()
$paginator->getTotal() → $paginator->total()

・Beanstalk キュー
"pda/pheanstalk": "~2.1" → "pda/pheanstalk": "~3.0”

・リモート
Remoteコンポーネントは使用不可に。

・ワークベンチ
Workbenchコンポーネントは使用不可に。
ーーーーーーーーーーーーーーーーーーーー

今回も、やたら長かったですね！

最後まで読んでくれたあなたには、きっと幸せが訪れます。

Love ya !!

git diffから除外したいファイルの指定方法

Git
こんにちは。
自分のメモ代わりだから、さらっと書きますよー。

gulpでcssやらjsをコンパイルするとgit diffで余計なものがたくさん引っかかるのが嫌だ。
修正した箇所だけ見たい。
diff見ないでコミットとかしたくない。
そんなときに使えるコマンドが
git diff --diff-filter=M

修正があったファイルだけdiffするコマンドーだそうな。
他にもdiff-filterのオプションにはA （追加）、C （コピー）、D （削除）、R （リネーム）とかもあるらしいです。つ、使えるNE★
詳細はこちらの偉大なページをごらんください。

やったーこれで解決だぜ！と思ったのに、
all.css.map
みたいなmapファイルがまだひっかかる。

こんな大量の意味なし修正コードなんて見たくない(´・ω・｀)
矢印押す指も疲れちゃうし。

そんなときは
プロジェクトのrootディレクトリに.gitattributesというのを作成し、
*.map -diff
みたいに追記してやればいいそうな。

ドキュメントのここを読むと
*.map binary
でもいいっぽいです。

この辺の記事に詳しく説明があった。
Git でバイナリファイルを扱うときの私的設定

こんなページもあった。
Laravelでプロジェクトを作成したらまずやることメモ

↑この人は/public/js/配下とかにはコンパイル前のファイルは絶対入れないことにしてるっぽいけど、私はbrowserifyコンパイルしたのを、さらにマージさせてるからgitignoreとかできない。
cssもコンパイル後にマージしてる。

コンパイル後のマージ用ファイルをresources/assets/配下の別ディレクトリに入れればいんじゃね？
という声が聞こえてきそうだ。
でも、なんとなくそれをやると、「やっぱマージ前のやつ読み込んで作業したい。」とか、ベンダーファイルをマージしないで単体で読み込ませたいとか、そんな融通がきかなくなりそうな気がする。

ということで、私は/public/js/配下はgitignoreせず、手動でつけたりはずしたりできるコンパイル後のファイル群を入れることにする。

*.map binary
/public/build/**/* binary
を設定しちゃえば
git diff --diff-filter=M
する必要もあまりなくなる気がする。

あー今日も超寒い。会社におこたスペース作ってくれないかなぁ。
おこたでぬくぬくしながらコーディングしたいベル子でした。

Laravel 5.0から5.1の変更点

Laravel
あけましておめでとうございます！！

皆さん、「スター・ウォーズ／フォースの覚醒」はもう観ましたか？
私は観ました。
もう誰かにネタバレしたくて仕方ないのですが、そこは私もこんなに大きくなったので毎日グッとこらえています。

字幕を担当されていた翻訳者の林先生の講座に行って少しお話したことがあるんですけど、「俺は十分稼がせてもらったから今は後輩たちに仕事を譲ってやりたいんだけどね」と話していました。
でも、やっぱり大作になるとこういう有名な先生に白羽の矢が立ってしまうというのが世の常です。映画翻訳はホントに狭き門ですね。

ということで突然ですが、
今まで私はララ・ベル子という名にもかかわらず、
Laravel 4.2を普段使いしていて、5.0以上はふざけて使ったことしかなかったので、
そろそろ5.0以上を本気で使うために4.2から5.0の変更点をまとめようと思い立ちました。
（去年からずっと思ってたんだけど後回しにしてました。）

しかし、

リリースノートを見ただけでも4.2->5.0は変更点がめっちゃあるっぽい（ぐはぁっ）。
ということで4.2から5.0はすっ飛ばして、5.0->5.1の変更点をまとめるところから始めようという気持ちになりました。
5.1はLaravel初の長期間サポートバージョンですしね
（今回調べて初めて知ったことだけどね(｀・ω・´)キリッ）。

真面目に話すと、4.2->5.0の場合は概念的なものも入り込んでくるので、じっくり勉強したいということもあり、後回しにしました。
決して面倒くさかったわけじゃないです。
決して！！ホントに！いま私、勉強してるからっ！

ちなみに、今回、参考にしたのはLaravelの公式リリースノートとLaracastsのWhat's New in Laravel 5.1です。

★Laravel 5.0から5.1の変更点
=====================================================
・PHP 5.5.9+
動作条件はPHP 5.5.9以上。

・PSR-2に準拠
PSR-2のコーディングスタイル規約を採用した。

・Bladeへのサービス注入
Classのオブジェクトを直接Bladeに注入できるようになった。
（ただ、これをやると何となく誰かに怒られる気がしてならない。）

・Elixirの向上
　１．自動で２つのless、sass、coffeeファイルを１つにまとめてくれるようになった。
　２．Babelコンパイルに対応した。

・テスト設備の改善
FakerとMockeryが最初からインストールされるようになって結合テストが簡単に書けるようになった。

・モデルファクトリー
データベースにシードする際や開発中にテストする際に、ランダムなダミーデータを簡単な記述方法で作成してくれるモデルファクトリー機構が追加された。クロージャーでFaker Libraryのインスタンスを受け取りランダムデータの作成に利用できる。

・自作artisanコマンドの引数とオプションの書き方の改善
自作artisanコマンドの書き方が変わり、引数とオプションの定義の方法が改善されrouteの記述方式に近くなり、より簡潔に書けるようになった。
protected $signature = 'email:send {user}';

・ディレクトリ構成の変更
app/Commands → app/Jobs
app/Handlers    → app/Listeners
ただし、このディレクトリ変更はコアシステムに影響する変更ではないため5.1にアップデートする際に必須ではない。

・ドキュメントの改善とLTS（Long-term support）
公式ドキュメントの検索がオートコンプリート機能つきリアルタイム検索になり、スピーディに該当ドキュメントを見つけられるようになった。
5.1はLaravel初のLTS(長期間サポート)版で、バグ修正は２年間、セキュリティー修正は３年間対応する。

・ミドルウェアパラメーター
middlewareでカスタムパラメーターを受け取れるようになった。

・ルートグループ名
個別のルートだけでなくルートグループに独自の識別名を付けられるようになった。これにより名前付きルートグループ内では名前をつなげるだけで簡潔にルート名が表現できるようになった（ネスト表記できるようになった）。

Route::group(['as' => 'admin::'], function () {
    Route::get('dashboard', ['as' => 'dashboard', function () {
        // Route named "admin::dashboard"
    }]);
});

・ログイン試行回数制御 (Laravel 5.1.4+)
ログイン試行回数により一定時間ログイン処理を受け付けない制御ができるようになった。

・イベントブロードキャスト機能
クライアントにLaravelイベントをPushするブロードキャスト機能が追加された。
設定ファイル Config/broadcasting.php ではPusher、Redis(Socket.io)、logの３種からブロードキャストドライバーを選択できる。

・ACL（アクセスコントロールリスト）認証 (Laravel 5.1.11+)
Laravel 5.1.11からACL認証ロジックがサポートされリソースへのアクセスを簡潔にコントロールすることができるようになった。
新たに追加されたGateファサードを利用して制限を定義する。
制限はコールバック、または新たに追加されたPolicyクラスを利用して定義することができ、Gateに用意されているメソッドを呼び出し利用することができる。
合わせてビューテンプレートには@can ~ @endcanディレクティブが追加になり、ビュー側でも認証コントロールが簡単にできるようになった。

・暗号化
これまでは暗号化にmcrypt拡張モジュールが使用されていたが5.1からは、より積極的に保守されているopenssl拡張モジュールに変更になった。
=====================================================

どうですか？
今まで5.0を使っていて次は5.1使おうかなって人は参考にしてみてくださいなー。

それでは、また！

来年、勉強しようと思ってること

ひとりごと
今年も残りわずかですねー。
ある日とつぜん、通りすがりの王子様っぽい人に「ベル子さん、ラフマニノフの『パガニーニの主題による狂詩曲』はお好きですか。よろしかったら、この私と一緒に聴きに行きませんか？」と跪いて誘ってもらいたいという夢が、今年も叶わなかったベル子です。
生きてるうちに、そんな日がくることを願いつつ、来年勉強しようと思ってることをまとめたいと思います。

ちなみに、ピアノなら王道すぎますがショパンとリストが好きです。
最も愛するクラシック曲は、ちょっとマニアックなのですが、ブルッフの『ヴィオラと管弦楽のためのロマンス』という曲で、あまりにも美しい旋律に感動しすぎてしまうため、作業用BGMには向いてません！
ヴィオラのくぐもった声色とロマンティックな旋律(´；ω；｀)
涙なしには聴けません。

実は私、小学生の時に吹奏楽部に入っていてユーフォニウム担当だったんです。
聞いたこともない楽器だと思いますがｗ
やたらでかいのに何故かメロディラインを吹いたり、ソロまであったり、なぞの存在感を醸し出す楽器で、超無名なのに実は花形の楽器なんです。
もし皆さんも機会があれば、是非、吹いてみてくださいね。
すごく気持ちがいいんで。

あ、いつもどおり話がどんどん脱線していくYO。

ということで本題に戻ります。


【勉強すること】
・Laravel 5.0と5.1と5.2の変更点をまとめる。
　https://laravel.com/docs/master/upgrade#upgrade-5.0
　https://laracasts.com/series/whats-new-in-laravel-5-1

・Vue.js
　http://jp.vuejs.org/

・PHPのデザインパターン
　http://liginc.co.jp/web/programming/php/136131

・PHP7
　http://www.slideshare.net/hnw/phpcon-kansai20150530

・ES2015(特にPromise周りとか)
　http://www.html5rocks.com/ja/tutorials/es6/promises/

・Advent Calendarの記事をチェックする（Laravel、Vue.js、JavaScriptなど）
　http://jumilla.me/laravel-2015-looking-back

・WebPack
　http://liginc.co.jp/web/js/other-js/148813
（↑先日、このCTOの方とイベントでお会いしました。いろいろなフロントエンドのツールを使用してきて、今はWebPackに落ち着いてるとのことでした。）

・フロントエンドをモダンにするための用語まとめ（４）の執筆


来年の初めはここらへんを勉強していこうと思います！

そして来年は、もうちょっとお出かけしてアクティブに過ごしたいな、と。
あとは、少しわがままボディすぎるので体重をりんご３個分くらいに収めたいと思います。

皆様、今年も一年お世話になりました。
よいお年を〜〜〜。

フロントエンドをモダンにするための用語まとめ（３）

フロントエンド
どうも！

フロントエンドをモダンにするための用語まとめシリーズの最新号です。

フロントエンドをモダンにするための用語まとめ（１）
フロントエンドをモダンにするための用語まとめ（２）


【jekyll】
みんな大好きマークダウン記法で記事を書き、黒い画面で呪文を唱えると、静的なhtmlが大量に出来上がる静的サイトジェネレータ。主にブログ用。
Rubyで書かれているのでRuby使いとの親和性が高い。コンパイル後はただの静的ファイル群のため、扱いが非常に楽。WordPressに疲れた人向けらしい。

【シンタックスシュガー】
日本語で糖衣構文。ある構文を、より簡単に人間が読み書きできるように書き換えた構文のこと。

JavaScriptのシンタックスシュガーと紹介されることが多い。
JavaScriptをRubyライクに記述できるメタ言語。Ruby on Railsで標準サポートされていることから、Ruby使いに愛用されている。
Nodeモジュールでコンパイルができるほか、公式サイトにはオンラインのインタープリタがあるので、ちょっと括弧やセミコロンを書くのが面倒になったら、気軽に使うことができる。
クラスベースオブジェクト指向な書き方ができる（←本来の使い方）。
変数展開ができたり、変数宣言が省略できたりして、JavaScriptで陥りがちなミスを未然に防いでくれるという効能もある。
Laravel ElixirでもCoffeeScriptを標準サポートしている。

【TypeScript】
マイクロソフトが開発しているaltJS。JavaScriptに静的型付けやクラス、継承、インターフェイスのようなオブジェクト指向プログラミング構文拡張を加えた拡張言語。
また構文拡張という点からES6を先取りできるトランスパイラーであるBabelとの比較もされる。2015年3月AngularJS2.0がTypeScriptで開発されることが発表され、注目を浴びた。
また、TypeScriptの外部モジュールシステムはCommonJS形式とAMD形式のどちらにもコンパイルできる。

【Edge】
マイクロソフト社製の最新ブラウザー。マイクロソフトは後方互換性や独自性にこだわったため、ブラウザのモダン化、Web標準化に遅れをとり、モダンブラウザという指針を掲げては失敗してきた。その経験から、IEを切り離した新ブラウザEdgeの開発を決断することとなった。新ブラウザEdgeはIEのHTMLレンダリングエンジンTridentを搭載しない全く新しいブラウザだ。
Tridentは1997年発表のIE4で初めて搭載されたレンダリングエンジンで、20年近くマイクロソフトはこのエンジンに改修を続けてきた。使い古されたこのエンジンと別れを告げること(厳密にはTridentをフォークして大量の古えコードを削除)、そして今後は各OSで最新のブラウザのみをサポートとすることを発表し話題となった。
また、発表時にこれからは周りと足並みを揃えることも誓った。これをマイクロソフトは相互運用性と表現している。現在出てきているベンチマークテストの結果からすると、ようやく他のブラウザと同じ水準になった感がある(もちろん私の個人的な感想)。生まれたてのブラウザとしては悪くないとの評価も見られた（こっちはすごそうな人の意見）。html5テストの結果は他と比べてまだ低いが、驚くべきことに次世代JavaScriptと呼ばれるECMAScript6のサポート率が飛び抜けて高い。Edge13ではBabelのサポート率71%を大きく上回る84%の文法に準拠する。Chromeの65%と比べるとその差は20%に迫る。
このような背景から、ユーザーエージェントにChrome、AppleWebkit、Safariなどの文字が入り乱れ全部盛り状態となっているのも特徴だ。
ES6対応状況：http://kangax.github.io/compat-table/es6/

【Yeoman】
yo、Bower、Gruntの３種のツールで構成される統合ウェブサイトジェネレートワークフローのこと。雛形をつくる→ライブラリを取り込む→タスクランナーを走らせる。このような開発フローを提案する概念的なもの。またはyeoman-generatorのことを指す。

【yo】
Ruby on Railsのscaffoldに影響を受けて作成されたNode製の雛形作成ジェネレータ。対話形式で質問に答えていくとモダンなWebアプリの雛形が出来上がる。
npmで公開されている様々なyeoman-generatorを利用することで、お好みのフロントエンド、サーバーサイドのライブラリ群を取り揃えたWebアプリテンプレートが作成できる。さらに、自分でgeneratorを作り公開することもできるので、自分好みのライブラリを取り揃えた雛形を、黒い画面に呪文を唱えるだけで、いつでもすぐに展開することができる。

【タスクランナー】
面倒な作業を自動化するビルドツール。何の作業を自動化するのか分からない人のために、伝統的な手作業のWeb制作風景をおさらいしよう。

１．HTMLを全部カッコつきで丁寧に書く。
２．リセット用CSSとフレームワーク用CSSと共有CSSと
　　ページユニークCSSと共通コンポーネントCSSを別々のファイルで作成する。
３．共通JSとページユニークJSとコンポーネントJSを別々のファイルで作成する。
４．共通で使う画像を１枚にまとめてCSSを調整。
５．構文チェックにかける。
６．納品用にファイルを加工するため本番用のフォルダを作成する。
７．自作のCSSを１枚にまとめる。
８．自作のJSを１枚にまとめる。
９．自作で作ったCSSとJSを圧縮する。
10．依存関係のあるJSファイルを１つにまとめて圧縮する。

一般ユーザー向けサービスのフロント側では少しでも表示速度を速くしてくれとの要求度が高い。モバイルページやアニメ効果を多様したページでのレンダリングスピード向上のために、このような作業をフロントエンドのエンジニアは行う。
この作業は納品時の工数もバカにならないどころか、メンテナンスの際にミスを誘発し自分を呪いたくさせたり、デザイナーやオペレータがCSSを綺麗に戻せなくなるという人間関係のいざこざまで引き起こし、「ちょっとした修正」を「すごくめんどくさい修正」に変えてしまう、非常にやっかいな作業である。
特にCSSスプライトは画像修正のたびに1pxずれてロールオーバーや表示がおかしくなる現象を引き起こす原因となり、画像修正作業をデザイナーに丸投げできない状態にもさせる。
そういう悪夢のような作業を自動でやってくれるのがタスクランナーだ。
さらにCSSメタ言語やJade、CoffeeScriptなど各種メタ言語のコンパイルも自動化できる。

タスクランナーを走らせるコマンドは、ES6構文、Browserify、CoffeeScript、Sassなど、あらゆるものを一度でコンパイルしプロダクション用に加工してくれる魔法の呪文と化している。

【Grunt】
先発のJavaScriptベースのタスクランナー。さまざまなプラグインを読み込むことにより、いろいろなタスクを自動化できる。JavaScript寄りの記述方法。タスクをJSON形式で記述して追加する。
JSON形式なので分かりやすい反面、タスクが増えてきて複雑な処理になってくると、"読みづらいしコード量が多くなる"との意見が見受けられる。

【Gulp】
後発のタスクランナー。
Gruntに比べてコード量が少なくて済む。
タスク量が増えたときにGruntに比べて何をしているのかが分かりやすい。処理がGruntに比べてやや高速（らしい）。
当初はプラグインが少なかったことからGrunt派が多かったが、現在では遜色ない。Node寄りの記述方法で、Node使い以外の使い手にはとっつきにくい。Laravel ElixirではGulpを採用している。
公式サイト
 
【SourceMap】
圧縮したりコンパイルしたりした後のJavaScriptファイルやCSSファイルが元のファイルの何行目なのかというマッピング情報を記録したファイルのこと。
このSourceMapの呪文がコンパイル後のファイルに埋め込んであると、SourceMapに対応したChromeなどのブラウザでは、コンパイル後の難読化したファイルのままでデバッグができるという優れもの。Laravel Elixirでは標準装備。

【polyfill】
読み方はポリフィル。ポリリズムと似ているが全くの別物。
古いブラウザーにない機能を補完するコード(ライブラリ)のこと。

【Web Components】
Googleが提唱しはじめたHTMLをコンポーネント化する概念、または思想のこと。またはその仕様。
ブラウザ標準仕様となることを目指している。
目指しているけど現状ではChromeとOperaとFirefoxで実装が進んでいるだけ。以下のページでブラウザ対応表的なものが見られる。
だけどChromeでさえabout:flagsで有効化しないと現状では動かない。
でもWeb Componentsのポリフィルライブラリwebcomponents.jsを使えばSafariとIEでも利用できる。

Web Componentsは以下の４つの基本仕様で構成される。
・Custom Elements
・Templates
・HTMLImports
・Shadow DOM
Shadow DOMとTemplatesを使って新たな要素を作成しCustom Elementsを定義する。それらをHTMLImportsでロードすることでカスタムHTMLタグを使用できるようになる。
こんなふうに書くと自分でも何のことやら分からない。
要するに
<lara-beruko></lara-beruko>
と書くと
[かわいいね][セクスィーだね][オシャンティーだね]
の３ボタンができて、クリックするとそれぞれの動きをする、というようなカスタムUIコンポーネントが自作できる。
そんな夢のような仕様のこと。
「あれ、でもそれってどこかで聞いたことがあるような気がするぞ」感がすごい。
Web Componentsの詳細解説→https://html5experts.jp/1000ch/11142/
【Polymer】
Web Componentsにシンタックスシュガーを与えるフレームワーク的要素の強いライブラリ。ブラウザ標準仕様を目指しているはずなのに公式フレームワークが存在するというモニョモニョ感がマジパない。
Polymer の詳細解説→https://html5experts.jp/1000ch/11905/




いかがでしたか。
今回もハンパじゃない文字量でお届けしました。
書いてる私が言うのもなんですが、どんだけー！って言いたくなります。

最後まで読んでくれた真面目で勉強熱心なあなたのために、ちょっとした雑談をしまーす。
今月、というか先月でプログラマになって半年が経ちました！
早いものですねー。

楽しい日もあるし、鬼コーチにしごかれて号泣する日もあったりなかったりもしました。

先日、みんなの先輩こと匠師匠（重複表現すぎｗ）と話していたときのこと。
「俺も３年くらいはすげー勉強してたからね」
そうか、孤高の天才的なオーラを醸しだしていて一見、天才肌的な感じの匠師匠にも、そんな努力家的な一面があったんですね。
まあ、そうだろうと思ってましたけど。

言い換えたら「３年くらいは、しっかり勉強しないとダメだよ」ということでしょうね。

まだまだ足りない部分の多い私ですが、これからも皆様よろしくお願いしますm(_ _)m