平成二十六年十月十五日をもちまして、二年強の間勤めておりました会社から退社いたしました。
その会社はウェブアプリケーションの開発を主に行う会社で、業務の大半は受託開発となります。在宅での勤務が可能となっているため、社員各自の自宅が実質的なオフィスとなっています。そのため通勤などで煩わしく感じることがなく、また自己が好ましいと思う環境での仕事がしやすいのではないかと思います。
わたしには合いませんでしたが。
現在、わたしはエオルゼアで調理師をしております。トマトケチャップの生産を繰り返し繰り返し行い、お金をちまちまと貯めております。もらえるものはなんでも欲しいので退職祝いはAmazonのほしいものリストからご遠慮なくどうぞ。
という両者相反する内容の記事がございました。両論もっともな内容であり、また実行速度だけではなく思想も絡んでしまう非常に煩わしい問題であります。
はじめに筆者の立場を明確にしておきます。筆者は日本国内で働くウェブアプリケーション開発者です。主にウェブアプリケーションフレームワークとしてRuby on Railsを使用しており、それによりCoffeeScriptも日常的に使用し、そして記述しております。
筆者にとってのJavaScriptという言語は、プログラミングというものを深く学ばんと思わせる契機となった言語であり、深い愛着ととともにわずかながらも執着のようなものを抱いております。そのためJavaScriptを直接書かないために生まれたとも言える言語であるCoffeeScriptに対しては、いささか好ましかざる念を抱いております。よってこの記事は不平等な視点によって書かれているという点をあらかじめ認識していただきたく思います。
さて、多くの人は既にご存知のことかと思われますが、CoffeeScriptという言語はRubyやPythonといった言語に強い影響を受けた言語であります。このことは言語の記述による見た目からの類推だけではなく、CoffeeScriptの配布ページに出現する「Ruby Style」や「from Python」といった記載から容易に推察できるのではないでしょうか。前述した両記事の主題となっているfunction式内部で最後に評価され得る値を該当function式を実行した際に返す値とするCoffeScriptの仕様も、Rubyのメソッド定義が持つ同様の仕様から影響を受けたのです。
Rubyはメソッド定義に関するこの仕様は言語としての仕様としてあらかじめ用意されているものであるために、使用者はそこまで強い意識をする必要はありません。ですがCoffeeScriptは違います。CoffeeScriptはJavaScriptに変換されることを前提とした言語となってあるため、この仕様はあくまで最後に評価されるのではないかとCoffeeScriptの言語処理系によって判断される値が返されることとなります。このことは通常の使用で問題となることは少ないのですが、稀にではありますが問題となって身に振りかかることとなります。明示的なreturn文の記述を行うべきであるという内容の一つ目の記事もそうした稀な現象の一つになります。
稀な事象を気にかける必要は薄いとはいえ、複数人でのアプリケーション開発に際しては不測の事態となり、開発速度の遅延を招きかねないのではないでしょうか。よって自身一人による制御が困難である場合には明示的な値の返却が行われるようにreturn文を用いるようにしたほうが無難です。
蛇足ではありますがArrayオブジェクトのインスタンスの持つ組み込みメソッドであるpushはcoffeeコマンドが通常使用するJavaScript言語処理系であるv8では確かに充分な速度での動作がなされます。ですが、IE 6からIE 8のような古いウェブブラウザーではそこまでの速度は期待できません。安易な回避が可能であるのならば、同様の記述を繰り返すこととなり、まことに恐縮ではありますが、避けておいたほうが無難です。
多くの人が使用しているのではないかと思われるjQueryも仕様としてfunction式がundefinedと返却されることを前提とした記述があります。自身が記述することとなる部分だけではなく、JavaScriptライブラリー (やフレームワーク) のことを全て考えるとなると煩わしさは膨大なものとなります。JavaScriptとRubyが違う言語であると正しく認識した上でCoffeeScriptを使用することが肝要なのではないでしょうか。
筆者自身の個人的な意見を最後に記載しますと、やはりCoffeeScriptを初めとするJavaScriptへと変換されることを前提とした言語を使うのではなく、始めからJavaScriptをそのままに書くことのほうが最良であると強く信じております。
しかしながらJavaScriptというこの言語は、非常に癖の強い言語であり、複数人によって一つのソースコードを記述する場合には、明確なコーディング規約をアプリケーション開発を開始する以前から定めておかなければ、早晩崩壊を迎えることとなります。一方のCoffeeScriptは言語仕様から、そうしたJavaScriptの癖と呼べるようなものを極端に排除しており、また自由な記述ができる余地も減じさせられております。その結果として複数人によるアプリケーション開発に際しても、ある程度の統一性が生まれます。途中参入者も手間が少なく参加できるというのはCoffeeScriptの大きな強みであると言えるのではないでしょうか。
とはいえ、筆者がCoffeeScriptを好きな言語であると言える日が来ることは間違いなくありませんが。
iBus 1.5がクソすぎるという記事がございました。iBusはGNU/LinuxなどのUnixに似た環境を提供するOSのGUIで専ら使われるインプットメソッド (IM) の一つです。iBusはオープンソースソフトウェア (OSS) として提供されており、Google CodeのProject Hostingを用いた管理がなされており、そちらからダウンロードすることができます。
わたしが実際にiBusを使っていた時期というのは決して長いものではなく、また今回「クソすぎる」と強い言葉で否定されてしまっている1.5はまだ使っておりません。ですのでiBusに関して詳しいことを話すのは避けますが、OSSに対して「クソすぎる」というような表現を用いるのはいかがなものかと思ってしまいます。
OSSに対するcontribute、貢献というものはパッチを送り、そのパッチが適用されることだけではないとわたしは考えています。実際にそのOSSを使うこと。使ったことによって気付いた不具合や、自身が欲しいと思った機能に関して、該当するOSSを開発する個人や団体に対して報告することも、貢献という形には含まれるのです。
メーリングリストやBugzilla、GitHubやGoogle Codeのissue、もしくはTracやRedmineのticketという場合もあるでしょう。それぞれのOSSによって報告する手段は異なってしまうでしょうが、報告する術がないという状況は、全くないとは言えませんが、めったなことでは存在していません。もちろんむやみやたらな報告は迷惑となってしまう可能性が非常に高くなってしまいますが、理路整然と誰しも理解できるような報告であれば、OSSを開発している方 (方方) から歓迎されるでしょう。
iBusに話を戻します。iBusは前述した通りGoogle CodeのProject Hostingを用いて管理がなされており、issueも有効に働いています。iBusの1.5が安定版として提供が開始されたのは2012-12-11、つまり一年近く前のこととなります。OSSはもちろん開発している個人や団体の考え方にもよりますが、機能の変更が行われてから、安定版としての提供が開始されるまでの間には、通常広い期間が設けられます。これは追加された機能に不具合が存在してしまっていないかを確認する機会としてはもちろん、該当する機能が本当に有用であるか、そうしたことを確認するためにも非常に重要な期間です。
そのような期間に何もしなかったのは誰でしょうか。そう、iBusを漫然と使っていた人たちです。実際に安定版という形で提供が始められてから、有名なGNU/Linuxのディストリビューションがメジャーバージョンのアップグレードとともに各種パッケージのメジャーバージョンが上げられたことから、自分が使うもので困り始めてからようやく開発者には届かない場で一人、全く建設的ではない文句を言うのです。このような態度がOSSに対する態度として、あって良いのでしょうか。そのような態度を完全に否定するのは難しいながらも、それでも避けてもらいたいと思うのがわたしの率直な思いです。
また、iBus 1.5よりも以前のもの、iBus 1.4系列のものも1.5と平行して公開され続けています。iBus 1.5に不満がお有りなのでしたら、そちらをお使いになれば良いのではないでしょうか。自身の使うGNU/Linuxディストリビューションのパッケージシステムで管理されていないと煩わしいと考えているのかもしれませんが、あまりにも甘えが過ぎるのではないかとわたしは考えております。
わたしから言えるのはクソだクソだ外野から汚い言葉を吐き散らすだけで済ましている状況が健全だと言えるわけがない。ただそれだけです。
モダンな言語でHTML5を開発しよう! 俯瞰して理解するaltJSの比較 (前編 - TypeScript, CoffeeScript, Hexe) と題する記事があった。この記事は見出し中にある「HTML5を開発しよう」という言葉からして意味が通っていない。だが記事の内容から「HTML 5を始めとし、CSSやJavaScriptといったウェブ関連の技術を用いたアプリケーション作りをしよう」という意図であろうと類推することができる。しかしこの記事で問題なのはそのような重箱の隅を突くが如き枝葉末節な部分ではない。この記事の中で薦められているいわゆるaltJSと称される複数の言語たちではない、JavaScriptという言語はモダンな言語ではない、つまり近代的な言語ではないと断言してしまっていることである。
ここ数年のHTML5やCSS3の劇的な進化に比べて、JavaScriptの言語としての進化は緩やかだったのではないでしょうか。HTML5の登場により、リッチなウェブサイト・コンテンツ・アプリケーションが求められる時代になったのに、それを制御する言語が未だレガシーなものであり、ニーズに追いついていないのが現状です。
先に引用した一文は前述した記事の第一段落に記された内容である。この短い一文の中に、事実誤認から来ているのであろう誤りが複数含まれてしまっている。このような記事は非常に度し難く、そして許すことができない。
現在Selectors Level 3という呼称で勧告されている仕様は、CSS3 module: W3C selectorsという呼称で1999年に最初のワーキングドラフトが公開された。CSS 3は1999年以前よりも策定作業が続けられている仕様となっており、そして各ウェブブラウザーベンダーが長年の時をかけて着実に実装を続けているものである。こうした点から考えて、CSS 3は「ここ数年」と表現されるような短期間で「劇的に進化」を遂げたものであるとは到底言い難い。しかしながら先の記事の本質はCSS 3とは関係ないところに置いてあり、CSSに関しては知識も興味もない人物によって書かれている記事なのであろう。なのでその点は差し引いて考える必要がある。
だかしかし、そうした点を差し引いたとしても、この記事の本質であろうJavaScriptに関する記載においても明確な誤りが存在している。先に引用した一文ではJavaScriptは緩やかな進化しかしておらず、レガシーな言語であると断言されている。「レガシーな言語」と「モダンな言語」という言葉には明確な定義は用意されていない。だが文脈から「レガシーな言語」は否定的な表現、「モダンな言語」は肯定的な表現と対なる形となっていることは明白であろう。JavaScriptを進化が緩やかな言語であると表現するのは明らかな事実誤認であり、そして必要以上の悪意に満ちている。自身が書きたいと考える内容に説得力を持たせるだけがために過剰な言葉をもって書かれたものであると邪推してしまうのもいたしかたないことであろう。
筆者は十数年もの間、ずっとJavaScriptという言語を見続けている。言語仕様から各ウェブブラウザーベンダーの実装、そしてどのように使われているまで見ている。とはいえわたしが見られる範囲でしかなく、全てを見通せているとは到底言えない。だが、その決して広いとは言えない範囲を見ていても、JavaScriptの進化は目覚しいものであると強く断言することができる。JavaScriptの規格名であるECMAScriptの仕様は今も更新がなされている。そして策定されているそれらの仕様は段階的にではあるが着実に各ウェブブラウザーに実装されており、ECMAScript 5であれば安心して使えるようになっている。また現在策定中のECMAScript 6も各ウェブブラウザーに搭載されるJavaScript処理系にもよる上に、あくまで限定的ではあるが実験的に一部実装がなされている。各ウェブブラウザーベンダーによる妥協の産物であり現実的なHTML 5や、十数年の時をかけて着実な進化を遂げているCSS 3と比べると、JavaScriptは格段に劇的な進化が短期間の内になされている。こうした現状を鑑みた上でもJavaScriptはレガシーな言語であると断言するのであれば、JavaScriptという言語を愛していると言っても過言ではない筆者は残念という言葉以外を口に出すことはできない。
筆者自身もHTML 5の仕様についてはW3Cのウェブページにて公開されている範囲内に限られてしまっているが追っている。また各ウェブブラウザーにどのように実装されているかを簡易的にではあるが確認している。なのでHTML 5に関する知識もある程度はそなえられているという自負はある。だがHTML 5はこの記事の執筆時点では策定中の仕様であり、また各ウェブブラウザーベンダーによる実装もまだ中途の段階となっている。あくまでHTML 5という仕様は過渡期であり、未だ黎明期であるとすら言うのには難しい時期である。明日にはその中身が全くの別物へと変化している可能性が十二分にある。そのような状況である現時点でHTML 5エキスパートという呼称を負うことのできる精神性には感服せざるを得ない。
だからこそ、このようにHTML 5とは関係のない事柄であろうとも、JavaScriptのようにHTMLと密接に関係するような技術に関する記事において事実誤認にまみれている内容を書かれてしまっていると、全ての信頼性が失せ果ててしまう。信頼性の薄い人間が推すものが良いものであると思える人間は、そう多くはいないだろう。HTML 5の未来を暗くしてしまうことがないように事実確認を確かにした上で記事を適切に書くように心がけてもらいたいと切に願っている。
はてなブックマークの人気エントリーをながめていたところJavaScriptでアニメーションを書く初歩の初歩のような記事が目にはいりました。初歩であればこそ、この記事で省かれているrequestAnimationFrameの話をするべきではないのかとも思いますが、それよりもわたしは元の記事に掲載されているコードがJavaScriptを用いて十ミリ秒の間隔を開けて複数の処理を何度もウェブブラウザーにさせてしまっていることが気になりました。また、いくつかの処理を完了させてから、setTimeoutを用いて任意の時間が経過するのを待ち、同様の処理を行うというかたちになっていますので、処理に時間がかかってしまえば、なめらかな描写は到底実現されないものとなってしまっています。
昨今ではウェブブラウザーの動作させる少なくない端末が高速な処理をなせるようになってきているとはいえ、依然全てがそうなっているという状況ではありません。加えてここ数年で携帯電話に搭載されているウェブブラウザーの水準も非常に高いものとなっており、その使用者も日に日に増加しております。携帯電話はその用途のため、携帯することが前提として設計されており、小さく、そして長時間稼働させられるようにバッテリーのことを考え、処理能力は比較的に乏しくなっている傾向にあります。当然のように、そちらでの動作も勘案しなければなりません。
ウェブという媒体は多くの人が見ることになるものです。であればこそ、自身が想定しない環境にある対象に対しても一定の配慮は必要なのではないでしょうか。自身の持てる限りの全ての知識を、できる限り全て動員させ、処理の高速化や安定化につとめるべきです。
前記のコードのようにCSSとJavaScriptを組み合わせた記述をした方が通常多くのウェブブラウザーでは安定した動作をしてくれます。classListやCSSのtransitionプロパティーを使用しており、あまりにも古いウェブブラウザーでは動作してくれなくなります。しかしながら、元の記事ではtransitionプロパティーと同様にあまりにも古いウェブブラウザーでは動作することがないDate.now()を使用しており、こちらもあまりにも古いウェブブラウザーでの動作は考慮に入れていないと判断しました。
以前、JavaScriptは決して遅くないという記事を書き、遅いのは適切に書かれていないDOM操作のことであるという主張をいたしました。その考えは今でも変わっておりません。適切な記述さえすれば、遅くなるということはないのです。JavaScriptやDOMだけではなくCSSやそのほかの技術を適切に組み合わせて使うことによってウェブブラウザーはその真価を発揮するのです。多くの技術を楽しんで調べて、知識としてその身に取り込んでいくことが、ウェブブラウザーと仲良くして、ウェブページを作るにあたっては肝要となるのです。