忍者ブログ
プログラマ、ララ・ベル子さんのゆるふわ奮闘記。

[PR]

×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

ベル子の弟子

どうも、
見た目はゆめかわ、頭脳はゆるふわ、心はヤンデレ
名探偵ベル子です。

最近、技術ブログだからと言って技術的なことばかり書いていたので
「大丈夫かな、この人。仕事しかしてないんじゃないの。
友達とかいないんじゃないかなー」
と思われてそうです。
ひどいですね。そんなことあります。

ということで今回は、ベル子の弟子について日記的なものを書いてみます。
まずは弟子のスペックから。

・小学4年生の男の子
・ゲーマー。好きなゲームはマリオ。
・趣味は弟子オリジナルのねこカード作り
・特技はピアノ(今度、発表会で『千本桜」を連弾で弾くとか。どんだけオタクなんだか)

まず、なぜ弟子がベル子に弟子入りすることになったかといういきさつから。

弟子が小学2年の夏休み、私にこんなことを言ってきたのである。

弟子「暇すぎてYouTubeばっかりみちゃうよ。なんか面白いことないかなー?」
師匠「そんなに時間があるなら勉強とかしなよ」
弟子「勉強はしたくないんだよねー。いつでもできるし」
師匠「(確かに丸つけとか教えるのとか、こっちもつまらない)
   あ、これ面白そうだよ」

そこで見つけたのはプログラミンというゲーム感覚でプログラミングの学習ができる
子供向けのビジュアルプログラミングWebサービス。

これならゲーム感覚で面白そうと私は思った。

弟子はすっかりこのプログラミンが気に入って一日中作品を作って遊んだのである。

そして、その作品を夏休みの自由研究に出すと言いだした。
言っておくが、私は止めた。
本人のセンスというより親のセンスと思われたら大変だと思ったのである。

しかも、なぜかパソコンでレポートを描こうと言い始めた。
パソコンで絵が描けるのは知ってたらしい。

当時の弟子はまだタイピングもできなかったので、
横でつきっきりで教えてあげなくちゃならず、
周囲の人間には
「手書きでよくね?
てか小2の自由研究でプログラミングっておかしくね?
貯金箱にしなよ」
と散々言われたのだが、弟子は言い出したら聞かない体質なので
最後まで付き合うことになった。
やれやれ、オタクはこれだから嫌だ(自分含め)。

レポートは無事に書き終わった。
学校でも特に問題にはならなかったようなので、一安心。

そして弟子は
「プログラミンって面白いんだけど、
もうちょっとこうなればいいなぁってのが多いんだよねー。ほかにいいのないかな?」
と上から目線で偉そうに言い出した。

次にScratchというビジュアルプログラミング言語を発見し、2人でやってみた。
当時はちゃんと日本語化されていない&UIが分かりづらく
「なんかこれ、面白くないね」
と言ってやめてしまったのである。

あれから2年ほどの間に、弟子は「プログラミングをやってみたい」と何回か言ってきた。
というより具体的には「ゲームをつくりたい」ということなのだが。

プログラミングやるなら、まずはブラインドタッチからだ!と
タイピングのソフトを地味にやらせてみた。
でも地味な作業は子供は好きじゃない。
まあ、なんとかゆっくり打てるくらいになったので、許してやることにした。

そして先日、とうとう弟子がこう言ってきた。
「オレっち、プログラミングをやってみたいんだよね。真面目にやるから教えてよ。」

ならばということで、再度 Scratchをやってみることに。
今度はちゃんと本を買ってみた。

子供がやるやつなんだから適当にできるだろうという
私にありがちな驕り高ぶりを捨てることにしたのである。
ああ、本って偉大。

今のバージョンはUIもすごく分かりやすくて使いやすい。
弟子も「面白いね!」とのこと。

ということで、今回、弟子がベル子に弟子入りすることになりました。
弟子は理系なので、すごく理解が早くて、フラグ使いまくりです。
理系というよりゲーマーだからか。
自称「ガチオタのゲーマー」らしいので。

また時間があるときに弟子の近況を報告しようと思います。
弟子が私の仕事をしてくれる日は近.......くはないな。
先は長いっす。

拍手[2回]

PR

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

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

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

ベル子とイケメンが[ベル子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特集をコーディングした時に言っていたのを、
うっすら覚えていた。
あれからすでに5年も経ってるから、もうスタンダードになってるよね?と思ったし
Laracastsでもテイラーが「最近、Websocketでつなげること多くなってきたよねー?」と言っていたので、当然がっつりスタンダードなんだろうねと思ったけど、いろいろ調べた結果、少し微妙な点もありそう。

そしてWebsocketがいいのではないかと思ったのには、もっと現実的な理由があって
Laravel5.1以降には、Websocketを使ってリアルタイム通信をする機構が
最初から備わっているのだ!よ!
デフォルトではPusherという外部サービスが、ブロードキャストドライバーに設定されてるんだけど
RedisとSocket.ioを使って自前で実装する方法も選択できる。さすがLaravel。
だから、Laravelに限定して言うと「実装が簡単」そう。
私にもできそう。一人でもできそう。かわいい女の子だってできちゃいそう。

ドキュメント
https://laravel.com/docs/master/events#broadcasting-events

イベントブロードキャストとは、サーバー側で発火したイベントをクライアント側に配信する機構で、
そのドライバーとしてPusher、Redis、Log(開発用)の3種から選択できる。
お好みのもの選べるのって嬉しいよねー。
女子はブッフェ好きだしねー。

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

お疲れ様でした!!

拍手[0回]

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

こんばんは。ベル子です。 

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

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

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

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

フロントエンドをモダンにするための用語まとめ(1) 
フロントエンドをモダンにするための用語まとめ(2) 
フロントエンドをモダンにするための用語まとめ(3)

【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ってまさにこういうときに使うべき。

では、また来月会おう。

拍手[1回]

Laravel 4.2から5.0の変更点

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

この前、

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での変更点
ーーーーーーーーーーーーーーーーーーーー
▼リリースノート
http://readouble.com/laravel/5/1/ja/releases.html#laravel-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のすべてを1つに統合する統一されたエレガントな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コマンドで、全ての設定を1つのファイルにキャッシュできるようになった。

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


▼アップグレードガイド
http://readouble.com/laravel/5/1/ja/upgrade.html#upgrade-5.0

・環境設定
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シンタックスを使用しなければならない場合は、以下の場所に以下の3文を追記のこと。
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 !!

拍手[0回]

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

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

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
する必要もあまりなくなる気がする。

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

拍手[0回]