jQuery.ImgLoaderにprogressイベントを追加
Takazudo/jQuery.ImgLoader - GitHub
に、XHR2が利用可能な場合、画像のプリロードをXHR2で行い、進行経過をより細かくとれるようにした。
新しめのブラウザで見ると、ファイルが読み終わるまでにいくつもprogressが取れてるのが分かります。これでかなり細かくロード状況を画面に出すことができそう。
ほかちゃん本 - ノンプログラマのためのJavaScriptはじめの一歩
弊社ピクセルグリッドの、ほかちゃんが、ノンプログラマのためのJavaScriptはじめの一歩という本を書いたので、紹介します。
自分もjQueryの本を書いたのですが、
僕の本の方は、jQueryの基礎 → jQueryを使ったサンプルを見ながらJavaScript, jQueryを理解するという流れですが、ほかちゃん本の方は、スライドショーのプログラムを一つ、じっくり解説しながら、JavaScriptの基本文法を解説するという感じです。
この本をおすすめしたい人は、まぁ、タイトルもそうなんですが、JavaScriptをちょっとちゃんと勉強しようかなーと思っている人です。既に他の言語を習得している人であれば、サイ本なりなんなり、JavaScriptを事細かに解説している書籍を手にとっても、読み進めていけるでしょうが、そうでない人にとっては、そのような詳細な解説書を読むのは、結構厳しいと思います。しかし、仕事でjQueryなりなんなりを使う機会は増えてきたし、でもJavaScriptをどうやって勉強したらいいかわからないし・・・と思っている人には、この本がベストマッチだと思います。
個人的に、この本の構成は、かなりナイスだと思います。JavaScriptの文法を学ぶ…と言って、ほんとうに短い、文法を解説したようなサンプルをいくつも読んでいても、いざ書こうとなると、うんどうやるんだっけ？と、具体的にコードに落とせないことは、ままあることだと思います。この本は、スライドショーのプログラムを例にだしつつ、このコードのここでは配列を使っていて、配列とはこういうもんなのです - このコードのここではif分を使っていて、if文とはこういうもんなのです - を続け、最終的に全体が理解できるという構成になっています。
自分で本を書いている時も思ったのですが、このへんの塩梅っていうのは、かなり難しいと感じます。だって、ひとつひとつ順番に文法を解説して言ったら、結果として劣化サイ本のようになってしまいますし、その逆を行けば、ただのサンプルを羅列した、結果としてJavaScriptの理解なんてさっぱりできやしない、ソースコピペ貯蔵庫になります。この本は、文法を一つずつ理解していきつつも、サンプル一つがまるっと理解できた！と思わせる構成になっているので、しっかりJavaScriptの基礎を身に付けたい - けどプログラムのことはさっぱりわからん - という人には、かなり良いのではないかなと思います。
ちなみに僕の本の方は、jQueryの基本機能を紹介〜からのーサンプルを一つずつ紹介ーという流れになっていまして、その中で、ちょこちょこJavaScriptの基礎文法に触れてる感じです。そんなこんなで、ひと通り読めば、まぁだいたいなんとなくJavaScriptの文法もわかった感じになるかな？という構成なのですが、僕は自分の本の中で、ほかちゃん本のような、文法を、系統立てて一つ一つ解説するということは、諦めています。まぁ、jQueryの本なので、その辺はメインではないというのもあるっちゃあるのですが。
また、ほかちゃん本の優れた点は、jQueryを使わない、素のJavaScriptをちゃんと解説しているっていう点です。最近JavaScriptを始めたーという方、特にWebデザインとかマークアップから来てる方は、素のJavaScriptだけで書くという機会は、意図してやらない限り、殆どないんじゃないでしょうか。ですが、jQueryを使わないとどう書くのか、jQueryがどんなことをやってくれているのかを知るのは、JavaScriptをさらに学んでいくために、もちろん必須です。
ということで、JavaScriptをこれから学びたいという方は、ほかちゃん本と僕の本を買うといいでしょう！
Mobileでposition:fixedが使えるか否かの判別
古いiOSとダメな古いAndroidではposition:fixedが使えないんですけど、それを判別するのに Modernizr.positionFixed みたいの無いのかと思って探してたらjQuery mobileの中見つけた。
https://github.com/jquery/jquery-mobile/blob/master/js/widgets/fixedToolbar.js
なんとそれを判別するうまい方法は無いんで、ひたすらUAから判別しているらしい。ひいいい・・・
ということで、ありがたくこのコードを使わせていただくとして、jQuery.ui.domwindowをアップデートした。
モーダルダイアログを出すスクリプトで、position:fixedを使って位置を決めているんだけど、position:fixedが使えないブラウザでは、position:absoluteを使って、頑張って位置を計算しなければならない。デスクトップ環境だとその対応はIE6に対してだけ必要なんだけれども、Mobileでもそのダメな奴らにもそれをする必要があった。
なので、jQuery.ui.domwindowはへぼいAndroidでもたぶん動きます。まぁ、今手元にないんで確認してないんですけど。というかモバイルでモーダルダイアログとか使うのはそもそもかなりNGだと思いますけども。
Android2.Xについては以下も参考に。
ChromeでSassがコンパイルした結果のCSSから元のSCSSの場所を見つける
Chromeのexperimentalな機能で、Sassのコンパイルした結果のCSSから、SCSSファイルを参照できるとかなんとかを試した。元記事はこれ
まずChromeで
chrome://flags
とかやるとなんか出るので、
Enable Developer Tools experiments
をオンにする。すると、webkit inspectorの設定に、Experimentalタブが追加されてる。その中で
Support for SASS
をチェック。
Sassのコンパイル時、
sass —debug-info hoge.scss hoge.css
って具合でデバッグ情報を出力するようにする。そんで、そのCSSを普通に読み込むと
あれ、これは・・・
オーマイガッド ジスイズクーール！
しかしこのためにCSSに元の部分がどれとか書きだされちゃうんで、ビルドツールつかって、デプロイ時には—debug-infoナシでコンパイルする必要はありんす。
Safari6でwindow.scrollTo後、変更された値が即座に反映されない
よく確認してないけど、
window.scrollTo(0, 100);
とかやったあとにスクロール位置とると、100が戻ってくるのが普通のブラウザ（だと思ってる）なんだけど、Safari6.* ではこれが即座に反映されないっぽい。なので、
setTimeout(function() { … }, 0);
とかやると、ちゃんと取れるっぽかったので、そうした。
が、この時、何か別に処理が走ってて、0 setTimout後にスクロール位置をとってみても、まだscrollToの結果が表示に反映されていなかった場合、まだスクロール位置が変更されてないことになってるっぽい。なので、スクロール後の座標を再度取るときは、ちょっと間を開けてやらんといかんっぽい。要するにwindow.scrollToの結果が反映されるのは同期から非同期になったってこと？
これはSafari6のバグなのかなんなのか謎。ということを、jQuery.tinyscrollerをいじってる時に見つけた。ので直した。
CoffeeScriptでの存在確認演算子のコンパイル結果が2パターンある話
if age? ってやつ。これのコンパイル結果が
if (typeof age !== “undefined” && age !== null)
になる場合と
if (age != null)
になる場合がある。
なんでやねんと話していたら、どうやら「コンパイルするスクリプトにておいて、その変数が使われていたら != null版、それ以外はtypeof版」になるっぽい。
まず、 age != null のチェックは、age が undefined か、null の場合にのみ false を返すらしい。要するに何かセットされているかをチェックするうまい書き方らしい。
参考: [JavaScript] typeof arg == ‘undefined’ っていらないんじゃね？ / LiosK-free Blog
で、じゃあなんで typeofうんちゃら っていう長いやつになるかって言うと、その変数がまだ使われていなかった場合、if (age != null) でチェックしちゃうと、age is undefined と、エラーを返されてしまう。ここを typeof age とすれば、変数 age が宣言されていない場合でも、エラーが出ない。
なので、ほんとは全部typeof版でもいいんだけど、既にその変数が使われていたのであれば、それは冗長なので、!= nullにコンパイルしている風。
CoffeeScriptすごい。
追記
ここに色々書いてあった
JavaScript：undefined値の判定 - 泥のように
あと、このissueで説明されてた
typeofのチェックは、!=よりまじでslowだって言ってる。このissueにあるベンチを見てみたけど、Chromeだと全然差が無かった。しかし、IE6でみてみたところ、確かに圧倒的にtypeofのほうがslowだった。最近のブラウザは進化してそのような差が気にならないぐらい、どちらも爆速になったってことか、たぶん。
バファリンの半分はやさしさでできているが如くセミナーの半分以上は善意でできている
何やらイラついたことがあったので書いておきます。
Web業界界隈で働いしている人には、有料無料問わず、セミナーに参加されたことがある人が多いと思うのですが、このようなセミナー、特に無料だったりするものは、そもそも直接の利益を出すことが殆んど無理なのです。多くの場合は、スポンサーにお金を出してもらい、開催されたりする形になるでしょう。有料でもそれは同じ。でかいホールを借りるのには一日でも数十万はかかるし、登壇する人が食っていけるだけのフィーを出すのは、参加費だけで計上するのは殆んど無理に近いのです。
では、そのうようなセミナーをなぜやるのかというのは、その殆どが善意です。こんな技術があるので紹介したいとか、みんなに伝えたいことがあるとか、オーガナイザーも登壇者も、そういう気持ちで臨んでる人が殆どを占めているはずです。少なくとも、私が会ってきた人達のほぼ全ては、そのような人らだった。そして、そのようなセミナーを開催される人、登壇する人らには敬意を払わざるをえないです。
しかしながら、そのように善意だけでメシが食っていけないのも事実。ではどうするかというのは、各人のビジネスプランですが、例えば結構いい値段のする少人数向けレクチャーを宣伝したり、自著を宣伝したり、受託案件の受注を狙ったりなどなどです。まぁ、そんなこんなで「セミナーの半分以上は善意でできている」と僕は思ってます。
数ヶ月前、アメリカにjQuery conference, node conferenceを聞きに行きましたが、そのような場でもそれは同様です。いや、僕の感覚では、登壇者がそれ自身を楽しみ、コミュニケーションするという側面は、日本で開催されているセミナーらよりも、もっと強かったと感じられ、非常に印象的でした。（そのレポートはCodeGridに書いたので興味があればーと微妙に宣伝）
誰しもそうだと思うんですが、Webにおいて、開発者らを支えているのはオープンな技術と、それを共有してくれる偉大な先人らだったりするわけですよね。
だから、うちはなんちゃらの元祖だから他のやつらがうちらのことを真似るのは我慢ならないなどとくだらないことを言い、他のセミナーや同業種の他者にケチをつけ、方方に迷惑をかけたりしているのを見かけたら、少なくとも僕はそのような人らを信頼することは無いでしょう。
jQuery conferenceで聞いてきたこの超すごいMVCの考え方を日本で広めたのはオレなんで、それを真似してセミナーを開催しようなど我慢ならない - などと僕が言ったとして、それがどれだけ滑稽か、分かるでしょう？ Webの技術において、そのようなクローズドな考えは、これからもずっと適すことはないでしょう。
jQuery.tinyscroller
スムーズスクロールするやつ作りなおした。
APIコール時、コールバックを受け取るのをやめてdeferredを返すようにしたかったのでそのようにし、ごちゃごちゃになってたのを整理した。
デモ
deferredでやりとりすると、コールバック設定しまくらないといけないのが防げて便利
jQuery.LazyJaxDavisで静的サイトを手軽にダイナミックにする
jQuery.LazyJaxDavisというライブラリを書いた。このライブラリは、一般的な静的に生成されるようなサイトを、HTML5 history APIの力を使って素敵にダイナミックにします。
このライブラリを使うと、すべてのリンクを、通常遷移の代わりに、Ajaxベースのダイナミックな遷移にします。その際、history.pushStateして、通常の遷移と同じように見せる。言葉にするのは難しいので、実際にサイトを見てもらったほうが分かりやすいと思う。以下のサイトの左ナビをポチポチクリックするなりして。
加えて、結構汎用的なURLルーターの機能も備えてる。詳しくは上記ドキュメント（兼デモ）を見てくださいなのだけれども、このライブラリがやりたいのは、「いつも普段みんなが作ってるようなサイトを、HTML5 history API の力を使って手軽に素敵にしようぜ」です。
HTML5のAPI使いたいという話
まず、HTML5がどうだと言われても、別にマークアップが変わったところでなんかドラスティックに素敵になるというわけでもない（とここでは言ってしまうけれども）し、なんか実務で使うのだと、まーその、新しいAPIは使えないよねーなかなか…っていうのがあった。でもなんかうまいこと使いたい。
そこで見つけたのが Davis.js というライブラリなのだけれども、これは、URLのルーター。Backbone.jsにも同じような機能がある。これらのURLルーターは、URLの切り替わりをhistory APIを使って制御してくれて、対応するURLになったら、はいこれやってねという類のもの。でもまー早い話、Webアプリ用だ。だってhistory API使えないブラウザじゃ何も動かんし。その場合には代わりにhashchangeをするという機能がBackbone.jsにはあるが、それはまたそれで実URLじゃないので微妙すぎでしょうよと。hashchangeによる遷移のサイトは、将来的には撲滅されるべき。Webアプリならまぁ仕方なしと思える点もあるけれども、静的なサイトでそれを使うなんてのは微妙すぎる。
でもなんか使いたいよねーと思って考えてたアイデアが、「pushStateした時に、そのページをAjaxで取ってきて、メインコンテンツ部分だけ置き換えればいいんじゃない？」というもの。そうすれば、history API対応していないブラウザでも普通に見えるよねとういことで。これをちょっと試し、弊社PixelGridが、実務で実装したのが以下。（ほぼ）すべての遷移がAjaxになる。
仕組み的には、メインエリアを示すコメントを各ページに入れ、そこだけ抜き出してきてページに突っ込む。これを、Davis.js を使って実装した。この仕事はまぁそんな感じで無事、運用も続いているけれども、心配していたhistory API周りで何かトラブル - ということはほぼ無く運用できてる。
Webアプリ実装した話
別の仕事でまた、なんだか開発する人のノリがとてもよかったので、今度は、上みたいにガバッと取ってくるのではなく、サーバーは全部JSONを返して、それをフロントで全部制御するという仕事をやった。そしてジセダイでやったように、hisotry APIでやる。IEとかでは通常の遷移で見れるようにする - という風に。サーバーはすべてのURLに対して同一のHTMLを返す。これはかなり、規模の割にはチャレンジングなものだったけども、ここでも Davis.js を使ってやった。この案件は名前は出せないけど。
IEでも見れるように - ということなので、Davis.jsをそのまま使えないから、これをラップするライブラリ作り、URLルーターにしてた。
この2つの仕事で作ったものを改良し、汎用的にしたものがこのjQuery.LazyJaxDavisです。
作りたかった機能
まず、ジセダイで実装した、リンク先のhtmlを取ってきてぶっこ抜く方式を、デフォルトで採用したいと思った。これは、意外にトラブルが無かったし、比較的導入のコストも低いから。なので、この機能が、jQuery.LazyJaxDavisの基本機能になってます。
あとは、Webアプリ向けすぎるURLルーターでは無く、もっと静的サイト向けのURLルーターが欲しかった。当然、そのルーターは、IEでも使えなければならない。history APIが使える場合はそれを考慮した状態で - そうでなければ、URLだけを見て、やらせたいことをやるという感じにしようと。具体的には、/product/ だったら、このコードを実行して、 /company/ だったらこのコードを実行して〜っていうのもの。上記2案件で書いていたURLルーターは、この機能を、Davis.jsの上に被せたものだったから、これをもっと汎用的にしたいと。
これらを、jQuery.LazyJaxDavisがうまいこと助けます。ここで挙げた Davis.jsに、基本的には依存してますが。
機能とかデモとか
まず、ぶっこぬいてきてはめる機能。これの実装はかなり楽。なので、静的サイトやらブログやらなんやらで是非使ってみて欲しいと思ってる。
一応言っておくと、後から追加したDOMに関してはdocumentready時にいつも適用しているようなロールオーバーなりなんなりは適用されないので、その点はjQuery.LazyJaxDavisで色々とイベントを用意しているので、これらを使ってうまいことやってくださいというところ。別にそんなに難しい話じゃあ無いが、実務経験からすると、特にソーシャルボタン周りの実装が地味にめんどい。
次、URLルーティング機能。これはDavis.jsベースで動くが、IEとかでもAjaxして取ってくる関連のイベント意外は問題なく動くようになってる。このURLだったらこうして、こっちのURLだったらこうして〜というのが指定できる。
次、より高度なルーティング機能。これは、例えば、/product/foo.html では、このコードを実行したい… これは上のURLルーティングでやればいいんだけど、/product/* 全体でこれを共通で実行させたいんだよね… っていうのを実現するためのもの。透明ルーティングっていう名前にした。上から被せられる、追加のルーティング。
次、ぶっこぬき部分はやらない機能。この場合、Davis.jsに依存しない。じゃあ何してくれるんだというと、上に書いたURLルーティングの機能だけを提供する。
ここまでの機能は、基本的に、静的なサイトで使うことを考慮して作ったものだけれども、それに加えて、でもWebアプリみたいな状況でも使いたいんだよねーという場合、Davis.jsの機能を直接使える機能。
〜と、これがjQuery.LazyJaxDavisの基本的な機能ら。これらをやるために、実務でちょとハマったことだったりなんなりがやや吸収された状態になってる感じです。
ということで、お試しの上、レッツhistory APIしましょう。
ただ、静的なサイトを、軽くWebアプリに用に設計することになるため、（自己責任で）と、一応付け加えておきたいです。
CoffeeScriptは自分にとっては有益だった
CoffeeScriptは是か否かという話は、CoffeeScriptを調べていれば否応なしに引っかかる話題で、自分もそれについてはかなり考えさせられた。何回かこのブログでも書いたとおり、CoffeeScriptいいなーと思ってはいて、ここ１，２ヶ月はずっとCoffeeScriptでJavaScriptを書いているんだけども、いい点はもちろんあるにせよ、書いているうちに、最初は見えてなかった問題も見えてきたりした感じがするので、その点について少し書きます。
あんたの仕事は何なの
まず、自分は受託制作がメインの会社（PixelGrid）に務めていて、一応、JavaScriptやる会社ですと謳っているのもあって、JavaScriptでUIを組む仕事が結構多い。自分は、マークアップ出身なJavaScriptプログラマーみたいな感じになってる。最近よくあるのが、いままでFlashで作っていたものをJSでーとかだったり、WebアプリをAjaxベースでーとか、そういうのとかをメインにやったりしてる。
そのような状況で、複雑なUIを組むためには、設計方法に悩む。jQueryは素晴らしいけども、入り組んだUIを設計するための手段は提供してくれない。そんな状況で、自分はjQuery UIのベースになっているwidgetというフレームワークを使ってイベントのやりくりをしていたけれども、これはあくまでjQueryプラグインをOOPで書けるようにしたようにしたもので、そこまで豊富な機能があるわけじゃない。
サーバーとの連携を多く行うような場合、最近だと、Backbone.jsを使うようにしたりしているんだけども、それでもちいさなクラス的な働きをするものはconstructorとprototypeをポチポチ自分で書いたりしていた。別にそれが悪いという気はさっぱりしないけれども、とにかく、その「ちいさなクラス的な働きをするもの」が必要だと感じていた。
あと、似たような機能を書くことが多い。自分と同じようなことをしている人は分かるかもしれないけれども、ページ上には沢山のパーツがあり、それを管理するクラスを作り、それらをイベントで連携させる - ということを無数にやるため、そこまで複雑ではないが、無くてはならない - しかし、サイトによってちがうしCSSにも依存する - みたいなものを沢山作る必要がある。
CoffeeScirptが解決したモノ
そんな状況で、CoffeeScriptを使い出したんだけれども、CoffeeScriptは、この欠けていた部分を補完してくれたものと感じている。The Little Book on CoffeeScriptには、こう書いてある。
Classes in JavaScript seem to have the kind of effect that cloves of garlic have to Dracula for some purists; although, let’s be honest, if you’re that way inclined, you’re unlikely to be reading a book on CoffeeScript. However, it turns out that classes are just as damn useful in JavaScript as they are in other languages and CoffeeScript provides a great abstraction.
JavaScriptにおいてクラスは、JavaScript原理主義の人にとっては、ドラキュラにニンニクを与えたように嫌がるものだが、CoffeeScriptはこれを役立つものと考え、抽象化した機能として提供する - みたいな感じ。
Webアプリのように複雑にUIが組み合わさって作られる様な状況では、自分はこの意見に同意する。そして、コレを実現しようとした時、そんなわざわざ新しい言語でラップする必要はないよ、この小さいライブラリを使いなよ - と言われるかもしれないけれども、それでも、その「小さいライブラリ」とやらを使うことで、一枚フレームワークの上に立ってコードを書くということになる。CoffeeScriptを使えば、それが既に存在する状態で始められるので、コードを書くのが非常に楽。
これは特に、Backbone.jsと組み合わせて使った時に、大きな効果を発揮したと思う。Backbone.jsのコンポーネントはクラス的に作られているので、CoffeeScriptと合わせて書くと、本当にサクサク書けた。やってみると実感できるけれども、この相性の良さはかなりすごい。
だとしても、そこでCoffeeScriptをあえて使うのは必須ではないでしょうときっと言われるだろう。それは確かにYESだけれども、僕が言いたいのは、この、CoffeeScript + Backbone.jsの組み合わせでコードを書くことで、実際に実務をこなすためにかかった時間を、かなり短縮できたというのが、一つ、事実としてあったということ。CoffeeScriptを大プッシュする人がいたら、きっと同じようなことを経験したのではないかと思う。
とあるプロジェクトで自分が書いたJavaScriptは、1万行を超えてた。これは別に、同じコードをひたすらコピペしていってそうなったわけじゃない。Backbone.jsのModelだのViewだのjQueryプラグインだのを延々必要なだけ書いて行ったらそうなった。今となっては、まぁその時はもっとCoffeeScriptは下火だったけれども、これをCoffeeScriptで書いていたら、自分の潰れた土日はもっと少なかっただろうと思う。今数えたら、 var self = this; を、おおよそ200回書いていた。
CoffeeScirptはたぶんこんな感じ
CoffeeScriptは、JavaScriptの煩わしい括弧だのfunctionだのを省略できますよーという点が大きなメリットの一つだけれども、それも含め、クラスだったり、argumentsの展開だったり、単純なループだったり、printfみたいな機能などなど、JavaScriptに欠けてパーツをいくつか補ったような存在だと思う。なので、それがピッタリフィットするような状況では、CoffeeScriptは最高だねと思えるだろうし、そんなものは僕の書くコードには元々いらないものだよと思うのであれば、わざわざ言語をラップした言語を作るなんて無駄にもほどがある！と感じるんじゃないんだろーか。
で、自分は、こういう、CoffeeScriptが補ったものは、緻密なライブラリを作ったりするのであれば、細かい調整もいるし、そんなのはいらんと感じるかもしれないけども、そういったライブラリを色々と使い、実プロダクトに近いコードを書くのであればあるほど、あーこれが欲しかったんですよーと感じるものじゃないかなーと思う。
なので、そういうのを普段から書いてる人であれば、使ってみるといーんでないのかとは思う。もし、将来的に使わなくなったとしても、学んで見る価値はあるものかなーと。
自分のCoffeeScriptに対する認識は、「フレームワークが一枚かまされたJavaScript」という感じだ。そういう意味で、あらゆるJavaScriptはCoffeeScriptで書かれるべきだとかは別に思わない。
CoffeeScriptメンドクセーと思うこと
そんなこんなで、CoffeeScriptは使うといいよと思ってる自分だけれども、これはでかい問題だと思うことがあった。CoffeeScript書きだしてから、延々とコードを書いていて、クライアントワークで使ったコードを書きなおしてライブラリ化するのが結構楽しくなってきていて、趣味になってた。以下にその、CoffeeScriptで書いたライブラリがある。
- Takazudo/jQuery.ImgLoader
- Takazudo/jQuery.ui.domwindow
- Takazudo/jQuery.TmplDeck
- Takazudo/jQuery.PresetPreloader
- Takazudo/jQuery.LazyJaxDavis
で、このライブラリを作って、それを別の仕事で使おうとコピってくるんだけれども、そうしていると、当然、バグだったり、機能追加したいことが出てくる。そんな時、つくったライブラリをいじるのが非常にめんどくさい。
なぜなら、読み込んでいるのは、コンパイルされたJavaScriptだ。CoffeeScriptをコンパイルした結果は、かなり読める感じだけれども、それを直接いじったら、オリジナルのCoffeeScriptにも反映しなければならない。もし、そうしないのであれば、バグをオリジナルのスクリプトのレポジトリで直し、またコピってくるか、ライブラリのCoffeeScriptのソースも一緒に、そのプロジェクトのソースとして扱って、一緒にビルドしたりとか、そういうことをしなければならない。まぁ、理想は、オリジナルのレポジトリで直し、コンパイルしたものを再度持ってくる - だろうけど、これは結構めんどい。gitのレポジトリをネストする形にして、ライブラリのレポジトリも、親プロジェクトに含めてしまえばいいんだろうか。ここのところのうまい方法が分からない。誰か知ってたら教えて欲しい。
で、これが他の人が書いたCoffeeScriptだったらどうだろう？自分は、CoffeeScriptのビルドを、gruntというnodeで書かれたビルドツールを使ってやってる。ただ、gruntとターミナルで打てば、設定されたとおりにコンパイルし、簡単なバナー用コメントを追加してくれるものではあるけれども、このライブラリをデバッグするためには、少なくともそのようなステップが必要。ライブラリのレポジトリごとにビルドを設定しているから。
これは、まだ自分が書いたコードだからいい。たぶん、ほかのCoffeeScriptで書かれたようなライブラリも、同じような仕組みを使ってビルドしたりしていると思う。10個のライブラリを使っていて、それぞれにバグがあったとしたら、それらをチョコっと直すのだけでも、相当しんどいんじゃないかと思うんじゃないだろうか？
これは、Ryan Florenceが、以下の記事の中でも言及している。
初めにこの記事を見た時、「フーン、まぁこの人はみんなのコードを見る立場のひとだからねー」と思っていたのだけれども、自分でちょこちょこライブラリを作っているうちに、この問題がとても大きいということがわかってきた。
上の記事のコメント欄をざっと眺めてみるといい。たぶん、どこでも同じような議論がかわされていて、「オレにとってはなんの問題もない」とか「保守的に見れば採用は避けるべき」だとか言われており、この問題の結論はきっと出ないだろう。
Source Map とやらの機能で、この問題がかなり改善されそうな兆しが見えてきているものの、このコンパイル問題は、現時点で、CoffeeScriptが抱えている、かなりでかい問題だと感じてる。
ほか、些細な利点
カンマ忘れてIEでエラーとかでない利点。これは、JSlintかけろよとか言われるだろうが、実際、自分はvimでボタンをポンと押せばJSlintをかけられるようにはしているものの、それでも忘れることはある。これを、全く無くせると言うのは、思ったよりもでかいと感じる。
コードが短くなる利点。これは、特に自分のように、プロダクト用のUIみたいな、同じようなコードを沢山書く人間にとっては、思ったよりも効果がでかいと思った。特に、jQueryのdeferredなりイベントなりなんなりで、やたら括弧が入れ子になる状況を、さっぱり綺麗にできるのは、見やすくなるし、単純に書いていて楽しい。
などなど。これらは、些細ではあるものの、業務効率を大きくアップさせるものであるとは思う。自分は、var self = this; を200回書きたいとは思わない。
自分の中での結論
とりあえず、自分はこれからもCoffeeScriptで書いていくつもり。もしCoffeeScriptが使われなくなったとしても、そんなことはいちいち気にしていない。もし自分の関わっているのが、大きなオープンソースのプロジェクトであれば、確かに、それをCoffeeScriptにするのは、思い切った決断のように思う。だけれども、自分は、具体的なプロダクトのためのコードをガリガリ書くような立場の人間なので、そうではない。そのような状況において、CoffeeScriptの採用は、作業スピードとメンテナンス性をあげるものだと感じている。上記で挙げたような問題はあるにせよ。
もしあなたが、CoffeeScriptに興味があるものの、その将来性を不安視して手を付けないでいるのであれば、さっさと試してみろと言いたい。特に、自分と同じような立場の仕事をしていた場合。
この人とは長く続くだろうか？などと不安ばかり抱えて恋人を作る人などいないだろう。
以下の記事では著名人がインタビューに答えているので、読んでみると面白いと思う。
この記事の中で、「ユニットテストにだけCoffeeScriptを使う人はいるだろうね」という意見がある。ユニットテストのために書いたコードが他の何かで使いまわされることは、ほとんど無いだろう。単にサクッと書けるゆえ、コードを書くのを楽にしてくれるはず。CoffeeScriptとはつまり、そういうものだ。たぶん。今のところは。
学習コストがあるという点については、それほどではないと思ってる。CoffeeScriptの恩恵を感じられる人は、そもそも、プログラムの基本的な設計の考え方が分かっている人であると思うから。
jQuery.ui.domwindow - ThickBoxみたいなやつ
AjaxかIframeかなんかしらのコンテンツを擬似ダイアログに出すやつを書いた。
なんの素っ気も無いダイアログなんだけれども、なんの素っ気も無いダイアログが欲しかったので書いた。ダイアログのスクリプトはそりゃー山のように世の中には存在するんだけれども、実際に仕事で使う時には、素敵な見た目とか全然いらないことが多いし、そんでもってAPIも柔軟に用意されてないと困るんだよなーと思うことが多かったので、そんな時に便利かもしれない。
今までそういう時は、自分は、DOM window っていうライブラリをよく使っていたんだけれども、このライブラリを使う場合でも、このライブラリのラッパーみたいのを書いてどうのこうのしていた事が多かったので。
目玉な機能？は以下みたいなものか
- 素敵な見栄えとか無いんで、1からHTMLとCSS書く場合に向いてると思う
- a要素にdata属性ぽこぽこ足せばそれだけでとりあえず使える
- ダイアログ単独で開いたり閉じたりするAPIを持ってる
- 開く前、開いた後、閉じる前、閉じた後…という具合に、柔軟にイベントを設定可能
- 基本は真ん中にダイアログを表示するけど、ページ内に収まらない場合でもちゃんと見えるように、ちょっと気の利いた表示にしてくれたりする
- jQuery UI dialogっぽいステートフルな使い方もできるようにした
- ダイアログ表示までの遅延処理を自分で置き換えることができる（画像一式プリロードしてから開けとかそういうのが可能）
- ローディングスピナーにSpin.jsを使うことを選べる
- IE6のselect要素がダイアログの前に来ちゃうんですよー問題に対応可
とりあえず自分は今後も使っていく予定
Github Flavored Markdownをローカルでプレビューする for Mac
300円ぐらいでこのアプリを買う
必要なやつらをインストール
$ sudo gem install redcarpet $ sudo gem install pygments.rb $ sudo easy_install pygments
どこぞから拾ってきた以下のスクリプトをローカルのどっかに置く
例えば /hoge/foo/gfm.rb に置いたととして、これを実行可能にする
$ chmod a+x /hoge/foo/gfm.rb
Markedの設定から、Custom Markdown Processorに、 /hoge/foo/gfm.rb を指定する。これでgitHub flavored markdownのプレビューが可能になった。
SassのmixinライブラリBourbon
最近CSSを書くのにCompassを使ってたんだけど、
大してCompassの機能を使ってないので、オーバースペックな気がしてきた。なので、Compassのライブラリから、必要なやつだけ引っこ抜いてきて、オレオレライブラリとして使えばいいやと思ったんだけど、なんだかCompassは独自に関数を定義したりしててそのままだと使えないっぽかった。compactとかいう関数が中で使われてて、これがCompass独自に定義しているやつらしく、こいつは、複数の引数を渡し、ある分だけにまとめてくれるやつらしいんだけども。
めんどくさいから他になんか無いかと探してたけど、Sassのmixinをファイルにまとめましたみたいなやつが見つからんかったので、Bourbonとかいうやつにしようかと思ってるところ。
これは、Compassより遥かに軽量っぽい。インストールしたら
$ bourbon install
とかすると、Bourbonのファイル一式がそのディレクトリに置かれる。
そんで、sassでコンパイルするときに、以下のようにすればいい。
$ sass -r ./bourbon/lib/bourbon.rb hoge.scss hoge.css
なんだーなんか結局変なの読み込むんじゃんーとか思ったんだけど、中身見たら、このBourbonとやらも、compactとかいう関数を作ってた。box-shadowとかに複数の引数を渡すみたいのをやるのに必要らしい。他はほとんどmixinだっけだったから、かなり軽量っぽい。
A simple and lightweight mixin library for Sass.
ってサイトに書いてあるから、たぶん同じ様な事考えて、そんなに機能いらんからーってんで作られたものだと思うけど。
gruntのサンプルら
grunt がバージョン0.3になり、APIが変更になった。ついでによく使うサンプルらをまとめておいたのでちょこちょこ更新するかも。
CoffeeScript、sass、compassとかをwatchしてコンパイルするやつ。
jQuery.fx.offですべてのアニメーションをカット
でも昔書いたのだけども、IE8以下ではopacityに対応していないので、jQueryでアニメーションしようとすると、色々なことが面倒。そこで、ばっさりIE8以下対応をさっさとやるのが以下。どうのこうのでブラウザ判別でもして
if (ieLessThan9){
jQuery.fx.off = true;
}
jQuery.fx.off = true にすれば、すべてのアニメーションが一瞬で終わるようになります。これでfadeした時でも一瞬で変わるから問題なしだぜイェイってねー。
※これはかなりUIに関するJSを書く必要があるケースを想定してます
おいおいおい、おれのクライアントはそんなので納得しないぜ？オイ？
とでもお思いですか？それは状況によりけりですよ。かかるコストとスケジュールと実現したいことで決めればいいんです。
例えば、デザインが透過PNGだらけで、やりたいアニメーションをIE8以下向けに調節するのには相当の時間がかかってしまうことが見込まれる場合、普通に作るのと同じぐらいまでにはならないかもしれないけども、かなりの時間をかけて、ここはIE8以下はアニメーション無しでー、これはIE7以下はアニメーション無しでー…っていうようなコードをたっくさん書かないとダメですよ。そういう時、サービス残業してやるんですか？ IE死ねとかツイートしながら。それは違うんじゃないんですかねー。どのブラウザではこういう特長があるからっていうのを始めに説明して、それに対応するには時間がかなり掛かることが見込まれるので云々って言っておき、工数を見積る材料にするべきですよ。その見積りだとIE8以下はアニメーションカットですねとかね。
あとはスケジュールが全然無いときとか。とりあえずIE8以下はアニメーション全てカットで完成させたらどうです？そこからIE8以下を細かく調節していったらいいんじゃないですかね。CSSが使われだした時、CSSを切ってもちゃんと見れるって、みんな重視してたでは無いですか。アニメーションを切ってもコンテンツは見れますよ。まぁ、広く見られるコンテンツであればサイトのアクセスログからブラウザの割合ぐらいは確認したほうがいいとは思いますけどね。
逆に、アニメーションをカットしたほうが良いこともあるんですよ。というのは、IE8以下は性能的にもかなり低いブラウザなので、色々一気にアニメーションさせちゃうと、そもそもサイトが重いーってんで辛いことも多いんです。そんな状態なら、逆にアニメーションを全部させないほうがサクサク閲覧できたりすることも多いですよ。
ということで、ひとつ、jQuery.fx.offでIE8以下アニメーション全カット - ってのを一つのボーダーラインとして考えてみるのはどうでしょう？ もちろん開発者一人が勝手にそう思ってやりましたとか、後から言ってもダメですけど当然。
