Takazudo hamalog

programming notes. mainly about JavaScript / jQuery. [@Takazudo] [takazudo@gmail.com] Hint: alt + /

cool guy

スラッシュアックスが素敵

2013/12/01 permalink

このエントリーはモンハン モンハン Advent Calendar 2013、2日目のエントリーです。スラッシュアックスについて解説します。

私とモンハン

とりあえず自分は、よくいる、何百時間をモンハンをしてきたような人です。モンハン4は色々忙しくて、買ったものの、村クエが終わるか終わらんかぐらいのところで止まっているわけなんですが、前作まではかなりやってました。そしてPSPの時はPCに映像を出力し、プレイ動画を撮りながらタイムアタックみたいなのを一人でモクモクとやってたというような感じです。

そんな私が好きな武器は、スラッシュアックス。そんなスラッシュアックスが素敵だという点を少しでもお伝えするべく、本記事を書きます。それではレッツラゴー

スラッシュアックスの特徴

とりあえず、スラッシュアックスの基本的な特徴について触れておきます。スラッシュアックスは以下の様な特徴を持ってます。

  • ガードできません
  • 武器を出している時、横回避がステップになります
  • 斧モードと剣モードを切り替えながら戦います
  • 斧モードで戦ってるとスラッシュゲージが増えます
  • 剣モードで攻撃するとスラッシュゲージが減ります
  • 剣モードの時、攻撃ははじかれません
  • ゲージ一杯使うと属性解放攻撃みたいのができます

属性解放攻撃みたいなのは、モンスターがピヨってたりとかのスキがものすごーいあるときでないと使うタイミングあありません。しかし、剣モードで縦斬りを繰り返してるほうが強かったりしたりとかどうとかで、まぁカッコイイだけで存在感は大してない感じと考えて問題ないかなと。

スラッシュアックスで一番強い攻撃というのは、今書いたとおり、剣モードで縦斬りを繰り返す - です。縦斬りは、同じ場所で動かず、連続して延々と繰り返すことができます。そして、攻撃力が高い攻撃なのです。同じ場所でザクザクザクザクと敵を切りつける…!斧モードはえーと、まぁ後でいいや。とりあえず剣モードでいっぱい切るのが良い!

…というわけで、あれ…なんか斧モードとか剣モードとか属性解放とか色々ある割には、結構地味です。おまけにガードできません。ハンマーみたいにインパクトのある行為力な攻撃があるというわけでもなく、まぁなんかちょっと強げな攻撃を繰り返せるっていう感じの武器なんですね。そして弾かれない。

ざっくり印象を言ってしまうと、複雑な割にはけっこう地味!
そしてガードもできない。
だから初めてばかりの人にはちょっとどうだろう…

しかし!

回避性能

そんなスラッシュアックスに最高の相性のスキル…それは「回避性能」です。自分は、スラッシュアックスが好きというよりかは、この、「スラッシュアックス+回避性能」という組み合わせに惹かれ、ずっとスラッシュアックスを使ってきました。

ではその、回避性能とは何か。このスキルは、回避中の無敵時間を延ばすスキルです。そんなにモンハンをやっていない人にとっては、

「あーあの横転するときのがちょっと伸びるのね、へーー、たまによけられたりするやつ?」

と思うかもしれません。が、このスキルは、モンハンというゲームを、より高次元のシビアなアクションゲームへと昇華させます。とりあえず、どんな感じか知りたい人は、私がPSPのPortable 3rdの時に撮った動画でも見てみてください。そんな超うまいというわけではないですが…。

イビルジョーの攻撃を回避でちょこちょこ避けているのが分かるかと思います。

戦いの基本

まず、回避がどうのと語る前に、モンスターとの戦いがどのように行われるかを考えてみることにします。大きいタイプのモンスターと戦う場合、基本的には以下の様な動きになると考えられるのではないでしょうか。(ここでは、1vs1でモンスターと対峙するときのことを考えます)

攻撃 -> 振り向き -> 攻撃 -> 振り向き -> 攻撃 -> …

モンスターは、攻撃してきて、その後プレイヤーの方に向き直り、また攻撃し…という流れを繰り返すのが普通です。モンスターが攻撃してくる時に、モンスターの真正面にいてはやられてしまいます。

このモンスターを倒すにはどうするかといえば、もちろん、攻撃を当てにいかねばなりません。しかし、モンスターはこちらの攻撃を待ってくれず、延々襲ってきます。

では、どのように攻撃を当てればよいか、というのを考えねばなりません。その攻撃のタイミングとして一番のチャンスなのは、モンスターの攻撃後〜振り向き〜次の攻撃の間です。真正面から向かっていけば、当然、モンスターはこちらに攻撃してきます。なので、モンスターの攻撃が当たらない位置に移動 - 例えば横に回り込み、攻撃を当て、次の攻撃が来る前には、モンスターの正面に自分が位置していなければ良いのです。モンスターは、攻撃が終わったタイミングで、プレイヤーのいる方向に向き直りますので、この方向転換の間に、モンスターの後ろなどに回りこんだりします。

ざっくりですが、これがモンスターにダメージを与える基本的な考えです。

つまるところ、モンスターの攻撃の当たらない場所まで避難して、そこでちょっとだけモンスターを殴り、また攻撃が終わったらまた避難し…というのを繰り返すのが、基本的な攻撃のパターンになります。

モンスターによって攻撃の種類は様々であり、その攻撃範囲や時間も違います。モンスターがゆっくり振り向くか、早く振り向くか、それにより次の行動は何が来るか… その間にどのくらいの攻撃を当てられるか…。このように考えながらモンスターにちょっとずつダメージを与えていきます。そこには経験や技術が関わってきて、だんだんとわかってきてうまくなっていく…というのが、モンハンの楽しさであると言って、ひとつよいのではないかと私は考えます。

モンハンって、パーティーゲーム的な面もありますが、そういうストイックなゲーム性が強くあって、そういうところが好きなんですよね。えーと話がそれました。

回避性能があるとどうなるか

で、その戦いに回避性能が加わると、この戦いはもう一段階面白くなります。回避性能が無い状態では、次の攻撃をしてくる時までに、必ず、避難していなければなりませんでした。しかし、回避性能がある場合、この避難は、次のモンスターの攻撃にかぶせることができます。

モンスターの次の攻撃を受けるのと同時に回避することで、より長い間、ダメージを当て続けることが可能になります。はやくモンスターを倒すためには、当然、武器の攻撃力が重要です。しかし、それよりも、いかに沢山の攻撃を当てられるかも、非常に重要です。回避性能を付けることで、攻撃の機会を増やし、素早くモンスターを倒すことが可能になります。

例えば、以下は、イビルジョーの尻尾振り回しを回避で避け、その後すぐに縦斬りを行っているところです。

回避して避け…

すぐに縦斬り

この攻撃は、もし食らわないようにするのであれば、ガードをするか、敵からかなりの距離をとらなければなりませんでした。

以下は、イビルジョーのブレスを避けながら近寄っているところです。

このブレスは、ガード不能です。ブレスを食らわないようにするには、遠くまではなれるか、後ろに回り込む必要がありますが、回避で避けられればなんのことはありません。相手との距離を逆に縮めています。

ほか、回避性能は、振動によるふらつきや、咆哮も避けることができます。ただしこれは、必ず全てにおいて可能なわけではありません。咆哮にも、モンスターによって、その咆哮にかかる時間は異なっています。例えば、イビルジョーは0.1秒だがリオレイアは0.2秒、フルフルは0.3秒…といった具合に。(値は適当)回避性能で避けることの出来る時間がこれを上回り、あとはタイミングが合えば、これを避けることが可能です。上記動画の中でも、咆哮や地揺れを回避しているタイミングがあります。これもまたひとつ、回避の楽しいところです。

スラッシュアックスと回避性能

上記が回避性能の解説でしたが、スラッシュアックスは、この回避性能と、様々な面で相性の良い武器です。どのへんの相性が良いのかを見ていきます。

ステップ

まずは、スラッシュアックスの横回避は、ステップという、ちょっとだけ位置をずらすモーションになります。このステップ、ちょっとそこまで嬉しいとも言えないモーションです。なぜなら、ステップをしても、ちょっとだけしか移動しません。その結果、次の攻撃を食らってしまう事があるためです。攻撃の後はさっさと避難したいわけですから、ちょっとだけしか移動しないステップを見て、「スラッシュアックスは使いづらい」と感じてしまうのも無理は無いかもしれません。

しかし、回避性能が付いている時は、このステップがむしろ気持ちよく避けることの出来るモーションになります。ステップにも回避性能の無敵時間延長は適用されるため、敵の攻撃をちょっと避けて、すぐに次の攻撃に繋げられるからです。ステップ前と後で、向いている方向は変わりませんから、ちょっと敵の攻撃を避け、次の攻撃につなげることができます。

しかし、それでもステップの距離が短いことには変わりありません。そんな時は、回避距離UPも合わせて付けてみます。するとこれまた素敵に回避生活をおくることができます。(しかし、短いほうが色々と調節しやすいというケースも多いので一概に良いともいえません)

斧モード

斧モードの時の動きは、なにかもっさりして鈍い感じと形容されそうな動きです。攻撃の範囲が広かったり、踏み込み攻撃があったりするのですが、ひとつひとつの攻撃に要する時間が若干長く、攻撃後に、回避に移行できる時間も若干長めになっています。

この、回避に移行できる時間が長いという点は、回避性能がない場合、大して意味のない特徴です。なぜなら、その時間がいくら用意されていようが、さっさと移動しなければ、次の敵の攻撃をうけてしまうからです。しかし、回避性能がある場合、この特徴が大いに意味のあるものとなります。

回避性能のスキルを付けて回避をしたところで、そんなにびっくりするほど回避時間が上がるわけではありません。0コンマ何秒というぐらいの時間、伸びるだけです。しかし、その0コンマ何秒の時間を有効に利用すべく、敵の攻撃の時間とタイミングを見切り、回避を行うのです。

さて、敵の攻撃が終わり、こちらに振り向いてきて、振り向き終わり、次の攻撃をしてくる - という状況を想像してみます。その間、なるべく多くの攻撃を当て、最後の敵の攻撃のタイミングで回避 - としたいわけですが、実質、そんなにピッタリ、敵の攻撃、振り向きの時間と、こちらの攻撃の時間を合わせるのは、なかなかに難しいことです。回避は、敵が攻撃してきた、そのタイミングで行わないと意味がありません。このタイミングに合わせるために、攻撃後の回避移行待機時間を利用します。攻撃してちょっと時間をあけ、回避に繋げるのです。(以下の図は、上が敵、下が自分の動きを想定)

やってみると分かりますが、このような立ち回りは、他の武器では行いづらいことです。スラッシュアックスでは、攻撃後の回避移行待機時間を利用し、モンスターの攻撃に、テンポを合わせるような独特の立ち回りを行うことができます。これができると、なんだかリズムにのって的と戦っているような感覚を覚えます。これがなかなか楽しいです。

剣モード

剣モードは、そんなに特徴が色々とあるわけではなく、かなり単純な動きです。そして、今挙げた、回避移行待機時間も多くありません。しかし、そのぶん、攻撃力が高く、攻撃時間が短く、弾かれないという特徴があります。この弾かれないという特徴は、攻撃の頻度を上げるのに、大いに役立つ特徴です。敵の部位を考慮して攻撃を行わない - ということを考えなくてよくなります。

剣モードにおいては、避ける感覚が、斧モードとは異なります。剣モードの攻撃は、何回もヒットさせるという点に集中し、キリの良い所で引き上げる必要があります。

プレイスタイルにもよりますが、結局のところ、剣モードで切っている方がダメージが大きいので、剣モードで切りつつ、ゲージが減ったら斧モードに切り替え、またゲージが溜まったら剣モードに…というのを繰り返すのが、スラッシュアックスの戦い方の基本になります。

ほか、連続攻撃の途中にモードの切り替えボタンを押すと、攻撃をつなげたまま斧モードへと切り替えられるので、なにやら、「オレ、無駄のない動きしちゃってるよ」感があり、テクニカルな感じもして一人で盛り上がります。

剣モードの攻撃の当たり判定

剣モード時の攻撃は単純ではありますが、実は、当たり判定に独特な部分があります。例えば、縦斬りを行った場合、縦斬りが終わった際の、キャラクターの左後ろ側 - 剣を振りきった当たり - にも当たり判定があります。これを利用すると、右を向いたまま、ちょっと先まで移動して、このギリギリのところをモンスターに当て、そのまま前方へ回避…とすると、長い回避と攻撃を両立させることができます。横に回避するよりも、前に回避するほうが距離が出るのです。

逆に、横攻撃は、切った後、キャラクターの右後ろまで当たり判定があります。これは、縦斬りとは逆で、左を向き、横切りをして後ろギリギリをモンスターに当て、まっすぐ回避すれば、横方向に長い回避をすると同時に、攻撃を当てるということが可能になります。

このさきっちょ攻撃を当てるタイミングというのは、モンスターの振り向きに合わせて - というパターンが多いです。そういったケースを考えると、この攻撃をモンスターの頭に当て、華麗に回避 - ということが可能だったりします。

最後に

以上で、スラッシュアックスの解説を終わります。スラッシュアックスは、ガードが行えないため、かなりモンスターの行動を理解した上で使うべきかもしれません。なので、はじめてモンハンをプレイする人には、個人的にはおすすめしづらい武器です。

しかしながら、モンスターの行動を深く理解し、回避することに喜びを見いだせたならば、モンハンを、よりシビアなアクションゲームとして楽しむことが出来るに違いないでしょう。モンハンやりこみの一つとして、回避性能+スラッシュアックスを、是非試してみてほしいと思います。

自分が他にあげていた動画は、ナルガクルガと戦ってたやつで、もう一個ありました。しかし動画汚い…。

Advent caledar、明日は Eri Sawada さんがなにか書くようです…!

Androidに対する愚痴

2013/08/02 permalink

Androidはまじでクソだ。具体的には標準ブラウザがクソだ。iPhoneにも最初は苦労させられたものだけれども、その比じゃない。仕事では自分はそういうAndroidのクソさに付き合うのが嫌で嫌で蕁麻疹がでそうなので、Androidはクソすぎるんでそういうリッチぽいのはやめたほうがいいですよ、無駄にコストがかかるだけですよと言い続け、その上でそこまで攻めてない感じのデザインにしたところで、しかしなおそのクソさを発揮しやがる。どういうことなんだ?

クライアントに相談を受け、オレは真摯に考えを述べる。「Androidがクソなんでそんなのはやめましょう」と。もちろんこれが正しい決断だという自分の考えには、一点のくもりもない。しかし、その結果、仕事の話自体が無くなるという、この無駄なサイクルにかけるコストをAndroidはどう保証してくれようというのか?弊社およびクライアントがお前に期待し、色々と妄想し、打ち合わせをしたその時間は、ブラックホールへと飲み込まれ、あらゆる次元から消え去った。まずAndroidがクソであるのは、その存在のクソさゆえに、このように、利益につながらないとろで、無駄な時間を我々に費やさせるという点である。検証した結果、できませんでしたと言ったようなものもこれに含まれる。

Androidが我ら開発者 - といってしまうが、そのやる気を削ぐ大きな理由の一つは、そのデバッグのしづらさだ。Androidエミュレータっていうもの。このクソみたいに重い、ゴミみたいなエミュレーターは何なんだ?全く使いものにならない。GPUを使うとどうのとかいう記事を見つけてやってみたものの、オレのMacbook Airではやったとたんにフリーズ。ふざけんな。この愛情を全く注ぐ気にならないAndroidというデバイスに対して、仕方なく費やしたおれの人生時間の一部。しかしそれは何の利益ももたらさなかった。この無駄さ。まったくもって虚しい。諸行無常の響きあり。iOSを見習え。Androidがいかにクソであっても、この「デバッグのしやすさ」すら達成されていたら、そこまでストレスを感じなかったかもしれない。しかしながら、Androidはそのような面でももちろんクソである。スタートラインでコケている。

Androidは、CSSの対応にも微妙さを発揮している。特に2.X代のものがひどい。我々は、長い間、IEうんたらというものに苦しめられてきた。しかし、スマートフォンが流行り、今まで封印されていた、新しいCSSのプロパティが使えることに胸を躍らされたものである。具体的には、border-radius, display:table, gradientなどなど。普段コーディングするときには、使いたくとも使えなかったそれらのプロパティを、喜んで使いだした。しかしここでまたAndroidが邪魔をする。なぜ表示されない?そのガビガビの多角形は角丸を表してるつもりなのか?そういう、対応しているくせに中途半端。さらに端末ごとに起こったり起こらなかったりとか、そういう事象から引き起こされる頭痛から逃れるためには、より基本的なプロパティを使っていくしか無い。つまり、Androidはクソ、そういうこと。

Androidに特にがっかりさせられるのは、HTML5系の新しい機能を使う時だ。Modernizrによれば、Androidでも、この機能は使えるという。しかし実際はどうだ。それで使えるとはよく言えたものだ。自分が出会ったのは、history API、pushStateの挙動だ。pushStateでコロコロURLを変えていっても、一部のクソAndroidでは、locationオブジェクトがバグっていて、location.realod()すると、最初に開いたページに戻ってしまう。これがやっかいなのは「一部の機種」で起こるということだ。そういう機種と出会う度に、このように発見が難しい、クソみたいなバグを追求をしないとならない。その機種が、すごいシェアがあるのであればよい。(その世界代表が昔のIEである)しかし実際はそうではない、星の数ほどあるクソAndroidのごく一部に対応したに過ぎず、髪の毛を一本拾ってゴミ箱に入れ、「この部屋にはチリの一つもない」といっているのと等しい。そのように星の数ほどあるクソ端末が人を馬鹿にしたふざけた挙動をするのに対し、「このクソブラウザは、どんなヘマをやらかしたんだ?」と、これを探求することのどこに喜びがあるというのだ。さらにこれを何回繰り返せばいいっていうんだ?そして、これを解決することで、我々が作ったライブラリは、無駄に肥大化していく。お前のために費やした時間を、より有意義に使うべきであったと後悔する。さらにお前はAndroid4ではないか。2ならまだ笑えたものを、4でそれとはいったいどういうことなんだ?

つまりだ、やりたいこと(x)がリッチであればあるほど、それにかかる工数(y)は二次関数のグラフみたいにでかくなっていくわけだ。ワイイコールエックスノジジョウだ。ではわれわれはどうするべきか。そう、それは、リッチなコンテンツを作らないことだ。それしかない。一部の端末で動く、限定的なサイトならよい。しかし、広く一般に使われるサイトを作る時、そういうわけにはいかない。我々は、新しいクールな技術を使い、クールなサイトを開発したいと常々思っている。しかし、限られたコストの中で完成を約束するために、我々は選択しなければならない。このクソみたいに無駄に種類があるクソみたいなAndroidに足並みをそろえることを。

jQuery Mobileという偉大なフレームワークがある。これが偉大なのは、クソみたいなAndroidにもちゃんと対応していることだ。jQuery Mobileのドキュメントやissueを見ていると、Androidをはじめとしたスマートフォンがいかにクソかということがわかる。涙が出てくる。このjQuery Mobileというものは、そのようなクソデバイスにも対応しきった素晴らしいライブラリであり、汗と涙の結晶であるといえる。なにかをやろうとしたら、issueやソースコードをチェックし、jQuery Mobileがそれを試みて諦めたかどうかをチェックした方がいい。jQuery Mobileを作っているのは、なんかどっか海外の会社だ。その会社は戦略的に、モバイルに広く対応するフレームワークを作ることで、名を上げたりとかどうとか、そういう面で成功しているのだろう。しかし、それができるのは、そこに突っ込んでコミットし、その見返りを狙ってというのがあるが故だ。普通にちょっとサイトを作る時に、そこまでコミットはできない。

あなたはどうかしらない、しかし私はこう思ってる。Androidという癌みたいな端末がいるから、スマートフォン向けにリッチなことなんて、金と時間、なによりあなたの人生を無駄に使うことだからやめとけってこと。リッチなことをしたかったら、その上限はjQuery Mobileができること - だ。それ以上のことをしたかったら、世界中のAndroidが爆発して粉々になる必要がある。

そういえば最近、AndroidのWeb広告で、こういうリッチなのをやりたいという相談をうけたことがある。スマン、そんなのは100%無理だ。なぜかって言えば、Androidがクソだからなんだ。君は技術について無知だったかもしれないが悪くない。オレにも何もできることはない。Androidがクソなんだよ。そして結果的に、僕達がその企画に費やした時間は無駄になったんだ。ごめんよ。

つまりおれが言いたいのは、Androidはクソ。そういうこと。

===

以下、コメントなりはてブなり読んだ感想を追記。

# AndroidじゃなくてAndroid標準ブラウザの話だよね

まーたしかにそうでした。しかしブラウザは根幹の機能でしょうから関係有りますね。

# ネイティブがどうのこうの

* ネイティブアプリはネイティブ故に高速に動作する点が利点として大きい
* その反面マルチな環境に対応するにはコストがかかる
* HTMLはワンソースでマルチな環境に対応できる点が利点して大きい
* Androidのような存在はその利点を大きくそぎ、Web自体の進化を遅らせる(←)

これが残念だとおれが思っているポイント。
ネイティブで作ったほうが思ったの作れるのは当たり前でしょ。

Web周辺の技術は標準化が進み、未来が明るいように思えるが、環境についてはそんなのはまだまだ理想でしかなく、その理想を実現するためのprogressive enhancementなりどうのこうのを頑張った所で(!)なんともいかない点があるAndroidの存在が残念だってのがポイントですよ。UAにandroidが含まれてたらこの機能全部オフにする、その残念さが分かりますか?そういうやり方はオレだってやりたくないんですよ。

「HTMLはワンソースでマルチな環境に対応できる点が利点して大きい」

これ。これをつぶすAndroid。これがクソってこと。
儲けられる儲けられないの話じゃないの。

あと、そういう状況なら別の提案をしないとダメだろっていう人は、フツーにそういう人を知りたいので、是非弊社に営業しに来てください。そういうのは山ほどありますが、うちはWebを専門にやってる会社なんです。チャンスですよ。だけどまー、Web作りたいですっていうのがそのまま「いやアプリで」って言うふうにはなんないんですよねー。例えばニュースを伝えたいとかさー。しかしながら、たしかにWebアプリっていうのはそういう面で言えば今のところうまいやり方ではない気がしますね、モバイルだと。

# Appleがどうのこうの

iOSは1個しか無いからマシってだけの話である。別に好きでもない。ただスマートフォンの中では最もブラウザの実装がマシってだけ。そしてエミュレーターも高速に動くってだけ。ていうかAndroidエミュレーターがバカみたいにCPU食うだけだから。

# エミュレーターはもっと速いマシンではしらせろとかどうの
# もっと試せよ
# 実機でやるべきだろボケ

標準的な技術を使って作られたコンテンツを、特定のプラットフォームに対応させるために多くのコストをかける必要があるってことだよね。それを当たり前と思っちゃってるほうがやばいんじゃないの。会社には6台以上Androidの検証端末があるけど、えーっとWeb標準ってなんだっけ?

# 仮想マシンVMだと早いよ

知らなかった試してみますありがとう。

# jQuery Mobile

補足しておくけど、jQuery Mobileが手放しで素晴らしいと褒め称えたいわけではない。一応言っておくと、jQuery Mobileはかなり厚いフレームワークとして存在し、その内容は、多くのモバイル環境のための差異潰しが含まれている。よって、そこそこのJavaScriptに関する経験と知識がないと、自由に使うことは難しいというのが自分の感想。

そして、自分が「残念だーーー」と思うのは、そのjQuery Mobileを開発するために費やされた時間というのは、未来には何の役にも立たない、端末のバグを補完するために使われたという点。まーそういうのって何にでもあるんだけど、この状況を作り出している現状ってどうなんかなーって話ですよ。そのために費やされた開発者は報われるのか?いや、報われるように良くなっていってくださいよブラウザのほうも進化して。

まー、すげー人ってのは、そういうのも理解した上で、戦略的にこれが有効だからチョチョっとやっちゃうもんなんでしょうけど。

# リッチって言う物自体がアレ

そりゃー私が一番思ってますよ。でもねー、リッチリッチって、一緒くたに言えないんですわ。3Dとかcanvasとかがリッチっていうことなんですかねー?まー確かに自分もリッチという言葉を前提なしに使ってたな。まーしかしそれが言葉ってもんだから仕方ない。あー話がそれた。

まーリッチが良い悪いという問題と、ブラウザがそれを実現できるできないという問題は、全く別である。そして、皆が使うブラウザで同じ技術が使えるようになれば、そこでできることは増える。これはどう考えたって良いことでしょう。その環境があった上で、リッチを選ばないなら、それはそれでいい。個人的には例に出したpushStateみたいな地味な機能がリッチなんだが。まーそんなのはおれの好みだからどうでもいいか。そういうのず~~っと使えないのってだめじゃない?HTML5ってなんだっけ?

# ガラケーよりまし

たしかにそうですね。だがもっと良い未来を望まないのでしょうか。

# 三流だとかお前には頼まないとかそういうの

一応助言しておくと、はいはい出来ますって言う奴には気をつけろってこと。何も言わない奴はそもそも何も知らないってこと。

# お前は向いてないとかそういう話

Webをもう何年も何年もやってきたけど、自分が何も知らなくて業界に入ってきて、Androidの面倒みさせられてたら絶対やめてるっていうぐらいに思ったから書いた。実際にスマートフォンであれこれやりたい系の話は断りまくってる。やるべきじゃないからだ。Senchaも夢をいだいて試したがやはりAndroidがクソだったので客には提案できない。

# コメントとか読んだ感想

「HTMLはワンソースでマルチな環境に対応できる点が利点である」というのはやっぱまだ全然理想でしかないんだなーってなんか思った。そして、フフ、それが現実だよとagreeしてしまうのがまた残念なところだよ。

しかし、全体的に言えば、Webの技術ってのは、何年前からかは確実によくはなっているとは思う。コメントなりはてブみてると、まーなんかWebの進化のダイナミックさを感じますね。Androidという存在自体も。だから思うことをコメントでもしとけばいいんじゃないでしょうか。

2chにこのエントリが貼られてて、こういう意見が書かれてました

「これ読む限りAndroidがWebの進化を停滞させてるよね」

そう、それだよそれ。そんなに売るならもうちっとはマシに作れって話ですよ。クソなものはクソだって広めてやったほうがAndroidのためってもんですよ。

===

追記その2

その後思ったのだけれども、自分の「リッチ」という言葉の使い方が明確でなかった。で、自分で整理した、自分が言う「リッチ」というのは、3Dが使えるだとかアニメーションができるだとかそういうことではなく、使いやすいUIのことである - と自分のなかで定義付けた。それを実現するためにブラウザが備えている機能を使って開発するのが我々で、そういった機能のうち、新しいものであれば、それは3D Transformsだったり、canvasだったり、pushStateが、例えばある。そういった、時には「派手な」機能が、無駄に使われてしまうゆえに「リッチなのなぞいらん」と言われてしまうんだろう。

で、繰り返しになってしまうが、そういった機能を使いつつ、それらをサポートしないブラウザのために、progressive enhancementだのgraceful degradationのような方法を使うわけだけども、そもそもAndroid端末においてはそのようにチェックして、「機能が使える」らしいことがわかった所で、その、使えると判別された機能がバグっててダメなんだから、使わないことを選ぶしかなくなってしまうというのが、自分がすごくイヤって思ってるところであると、改めて思った。そうすると、例えば、position:fixedですら使うのが困難になる。

RWDでマルチスクリーンに対応〜などという考えで作ったとしても、やはりそれは、media queryを使い、あとは極力基本的なプロパティで設計する必要があったりとか、そういう風になってしまう。なんかそういう状態になってしまうんだよなーってのが微妙すぎるって思う次第。

jQuery.ImgLoaderにprogressイベントを追加

2012/12/01 permalink

Takazudo/jQuery.ImgLoader - GitHub

に、XHR2が利用可能な場合、画像のプリロードをXHR2で行い、進行経過をより細かくとれるようにした。

デモ

新しめのブラウザで見ると、ファイルが読み終わるまでにいくつもprogressが取れてるのが分かります。これでかなり細かくロード状況を画面に出すことができそう。

ほかちゃん本 - ノンプログラマのためのJavaScriptはじめの一歩

2012/11/11 permalink

弊社ピクセルグリッドの、ほかちゃんが、ノンプログラマのための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が使えるか否かの判別

2012/10/25 permalink

古い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については以下も参考に。

Fixed Positioning in Mobile Browsers | Brad Frost Web

ChromeでSassがコンパイルした結果のCSSから元のSCSSの場所を見つける

2012/10/24 permalink

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を普通に読み込むと

http://d.pr/i/fMZ5

あれ、これは・・・

http://d.pr/i/qjE2

オーマイガッド ジスイズクーール!

しかしこのためにCSSに元の部分がどれとか書きだされちゃうんで、ビルドツールつかって、デプロイ時には—debug-infoナシでコンパイルする必要はありんす。

Safari6でwindow.scrollTo後、変更された値が即座に反映されない

2012/10/22 permalink

よく確認してないけど、

window.scrollTo(0, 100);

とかやったあとにスクロール位置とると、100が戻ってくるのが普通のブラウザ(だと思ってる)なんだけど、Safari6.* ではこれが即座に反映されないっぽい。なので、

setTimeout(function() { … }, 0);

とかやると、ちゃんと取れるっぽかったので、そうした。

が、この時、何か別に処理が走ってて、0 setTimout後にスクロール位置をとってみても、まだscrollToの結果が表示に反映されていなかった場合、まだスクロール位置が変更されてないことになってるっぽい。なので、スクロール後の座標を再度取るときは、ちょっと間を開けてやらんといかんっぽい。要するにwindow.scrollToの結果が反映されるのは同期から非同期になったってこと?

これはSafari6のバグなのかなんなのか謎。ということを、jQuery.tinyscrollerをいじってる時に見つけた。ので直した。

CoffeeScriptでの存在確認演算子のコンパイル結果が2パターンある話

2012/10/09 permalink

if age? ってやつ。これのコンパイル結果が

if (typeof age !== “undefined” && age !== null)

になる場合と

if (age != null)

になる場合がある。

!= null版

typeof版

なんでやねんと話していたら、どうやら「コンパイルするスクリプトにておいて、その変数が使われていたら != 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で説明されてた

existential operator doesn’t check undefined for function argument · Issue #993 · jashkenas/coffee-script

typeofのチェックは、!=よりまじでslowだって言ってる。このissueにあるベンチを見てみたけど、Chromeだと全然差が無かった。しかし、IE6でみてみたところ、確かに圧倒的にtypeofのほうがslowだった。最近のブラウザは進化してそのような差が気にならないぐらい、どちらも爆速になったってことか、たぶん。

バファリンの半分はやさしさでできているが如くセミナーの半分以上は善意でできている

2012/09/07 permalink

何やらイラついたことがあったので書いておきます。

Web業界界隈で働いしている人には、有料無料問わず、セミナーに参加されたことがある人が多いと思うのですが、このようなセミナー、特に無料だったりするものは、そもそも直接の利益を出すことが殆んど無理なのです。多くの場合は、スポンサーにお金を出してもらい、開催されたりする形になるでしょう。有料でもそれは同じ。でかいホールを借りるのには一日でも数十万はかかるし、登壇する人が食っていけるだけのフィーを出すのは、参加費だけで計上するのは殆んど無理に近いのです。

では、そのうようなセミナーをなぜやるのかというのは、その殆どが善意です。こんな技術があるので紹介したいとか、みんなに伝えたいことがあるとか、オーガナイザーも登壇者も、そういう気持ちで臨んでる人が殆どを占めているはずです。少なくとも、私が会ってきた人達のほぼ全ては、そのような人らだった。そして、そのようなセミナーを開催される人、登壇する人らには敬意を払わざるをえないです。

しかしながら、そのように善意だけでメシが食っていけないのも事実。ではどうするかというのは、各人のビジネスプランですが、例えば結構いい値段のする少人数向けレクチャーを宣伝したり、自著を宣伝したり、受託案件の受注を狙ったりなどなどです。まぁ、そんなこんなで「セミナーの半分以上は善意でできている」と僕は思ってます。

数ヶ月前、アメリカにjQuery conference, node conferenceを聞きに行きましたが、そのような場でもそれは同様です。いや、僕の感覚では、登壇者がそれ自身を楽しみ、コミュニケーションするという側面は、日本で開催されているセミナーらよりも、もっと強かったと感じられ、非常に印象的でした。(そのレポートはCodeGridに書いたので興味があればーと微妙に宣伝)

誰しもそうだと思うんですが、Webにおいて、開発者らを支えているのはオープンな技術と、それを共有してくれる偉大な先人らだったりするわけですよね。

だから、うちはなんちゃらの元祖だから他のやつらがうちらのことを真似るのは我慢ならないなどとくだらないことを言い、他のセミナーや同業種の他者にケチをつけ、方方に迷惑をかけたりしているのを見かけたら、少なくとも僕はそのような人らを信頼することは無いでしょう。

jQuery conferenceで聞いてきたこの超すごいMVCの考え方を日本で広めたのはオレなんで、それを真似してセミナーを開催しようなど我慢ならない - などと僕が言ったとして、それがどれだけ滑稽か、分かるでしょう? Webの技術において、そのようなクローズドな考えは、これからもずっと適すことはないでしょう。

jQuery.tinyscroller

2012/04/06 permalink

スムーズスクロールするやつ作りなおした。
APIコール時、コールバックを受け取るのをやめてdeferredを返すようにしたかったのでそのようにし、ごちゃごちゃになってたのを整理した。

デモ

deferredでやりとりすると、コールバック設定しまくらないといけないのが防げて便利

jQuery.LazyJaxDavisで静的サイトを手軽にダイナミックにする

2012/04/03 permalink

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は自分にとっては有益だった

2012/04/02 permalink

CoffeeScriptは是か否かという話は、CoffeeScriptを調べていれば否応なしに引っかかる話題で、自分もそれについてはかなり考えさせられた。何回かこのブログでも書いたとおり、CoffeeScriptいいなーと思ってはいて、ここ1,2ヶ月はずっと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で書いたライブラリがある。

で、このライブラリを作って、それを別の仕事で使おうとコピってくるんだけれども、そうしていると、当然、バグだったり、機能追加したいことが出てくる。そんな時、つくったライブラリをいじるのが非常にめんどくさい。

なぜなら、読み込んでいるのは、コンパイルされた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みたいなやつ

2012/03/27 permalink

AjaxかIframeかなんかしらのコンテンツを擬似ダイアログに出すやつを書いた。

なんの素っ気も無いダイアログなんだけれども、なんの素っ気も無いダイアログが欲しかったので書いた。ダイアログのスクリプトはそりゃー山のように世の中には存在するんだけれども、実際に仕事で使う時には、素敵な見た目とか全然いらないことが多いし、そんでもってAPIも柔軟に用意されてないと困るんだよなーと思うことが多かったので、そんな時に便利かもしれない。

今までそういう時は、自分は、DOM window っていうライブラリをよく使っていたんだけれども、このライブラリを使う場合でも、このライブラリのラッパーみたいのを書いてどうのこうのしていた事が多かったので。

目玉な機能?は以下みたいなものか

  • 素敵な見栄えとか無いんで、1からHTMLとCSS書く場合に向いてると思う
  • a要素にdata属性ぽこぽこ足せばそれだけでとりあえず使える
  • ダイアログ単独で開いたり閉じたりするAPIを持ってる
  • 開く前、開いた後、閉じる前、閉じた後…という具合に、柔軟にイベントを設定可能
  • 基本は真ん中にダイアログを表示するけど、ページ内に収まらない場合でもちゃんと見えるように、ちょっと気の利いた表示にしてくれたりする
  • jQuery UI dialogっぽいステートフルな使い方もできるようにした
  • ダイアログ表示までの遅延処理を自分で置き換えることができる(画像一式プリロードしてから開けとかそういうのが可能)
  • ローディングスピナーにSpin.jsを使うことを選べる
  • IE6のselect要素がダイアログの前に来ちゃうんですよー問題に対応可

とりあえず自分は今後も使っていく予定

Github Flavored Markdownをローカルでプレビューする for Mac

2012/03/27 permalink

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

2012/03/24 permalink

最近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.

ってサイトに書いてあるから、たぶん同じ様な事考えて、そんなに機能いらんからーってんで作られたものだと思うけど。

とりあえずちょろっと試したら難なくできたっぽい(SCSS / CSS)ので、これでいいかと思っているところ。

ここgruntでのビルド例を置いておきます。