人生が二度あれば

山岸による私的な、めも帖

という両者相反する内容の記事がございました。両論もっともな内容であり、また実行速度だけではなく思想も絡んでしまう非常に煩わしい問題であります。

はじめに筆者の立場を明確にしておきます。筆者は日本国内で働くウェブアプリケーション開発者です。主にウェブアプリケーションフレームワークとして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オブジェクトのインスタンスの持つ組み込みメソッドであるpushcoffeeコマンドが通常使用するJavaScript言語処理系であるv8では確かに充分な速度での動作がなされます。ですが、IE 6からIE 8のような古いウェブブラウザーではそこまでの速度は期待できません。安易な回避が可能であるのならば、同様の記述を繰り返すこととなり、まことに恐縮ではありますが、避けておいたほうが無難です。

多くの人が使用しているのではないかと思われるjQueryも仕様としてfunction式がundefinedと返却されることを前提とした記述があります。自身が記述することとなる部分だけではなく、JavaScriptライブラリー (やフレームワーク) のことを全て考えるとなると煩わしさは膨大なものとなります。JavaScriptとRubyが違う言語であると正しく認識した上でCoffeeScriptを使用することが肝要なのではないでしょうか。

筆者自身の個人的な意見を最後に記載しますと、やはりCoffeeScriptを初めとするJavaScriptへと変換されることを前提とした言語を使うのではなく、始めからJavaScriptをそのままに書くことのほうが最良であると強く信じております。

しかしながらJavaScriptというこの言語は、非常に癖の強い言語であり、複数人によって一つのソースコードを記述する場合には、明確なコーディング規約をアプリケーション開発を開始する以前から定めておかなければ、早晩崩壊を迎えることとなります。一方のCoffeeScriptは言語仕様から、そうしたJavaScriptの癖と呼べるようなものを極端に排除しており、また自由な記述ができる余地も減じさせられております。その結果として複数人によるアプリケーション開発に際しても、ある程度の統一性が生まれます。途中参入者も手間が少なく参加できるというのはCoffeeScriptの大きな強みであると言えるのではないでしょうか。

とはいえ、筆者がCoffeeScriptを好きな言語であると言える日が来ることは間違いなくありませんが。

先日まで光の戦士となりエオルゼア各地で発生し、諸国を大いに困らせている蛮神問題の解決を図らんと尽力しておりました。しかしながら蛮神を二柱討伐した後、蛮族イクサル族が信仰する蛮神であるガルーダをいざ討伐せんと意気揚揚としていたところ力量が基準に至っておらず、足止めをされてしまいました。ここで光の戦士としての自身の能力を高めんと自己研鑽に努めるべきなのでありましょうが、峰城大学付属学園の三年生になりました

わたしはPS3でFF14を遊んでいたのですが、PS3版のFF14はPS3の性能面の問題からか、Windows版のFF14とくらべると非常に劣った存在となってしまっています。わたしはゲームをそう頻繁に楽しんでいないのですが、そのようなわたしの目からでは、PS3版のFF14はまともに遊ぶには難しい状況であると言わざるを得ません。

PS3版のFF14は画面上に表示させられる物体の数に極めて厳しい制限があり、プレイヤーが複数人集まるような状況になると、一部表示されない物体というものが出てきます。表示されない物体というものが、自身以外のプレイヤーが操作するキャラクターであったり、そのキャラクターの召喚する味方キャラクターであれば、FF14はプレイヤーが他プレイヤーを攻撃できないようになっているため、自身に対する影響というものはそこまで大きくありません。ですが敵キャラクターが表示されないという事態になってしまいますと、話は別です。

見えない敵から攻撃を受け、行動不能の状態にされてしまう。PS3という七年も前に発売された機器という厳しい制限の中で開発を続けている方には酷な言いかたになってしまうかもしれませんが、バカらしくてやっていられません。

FF14は行動不能状態になった際に受ける不利益はいくつかありますが、進行に大きな影響が出るような大きなものはなく、さして気になるようなものはありません。ですが、得られたはずのものが得られないときに感じる苛立ちはあり、経験値を得て、レベルを上げるというRPGでは当然のように繰り返すこととなる作業に必要以上の時間をかけてしまうことに繋がります。

PS3版のFF14はあくまで体験版と割り切り、それなりの性能を誇るコンピューターを用意し、Windows版のFF14を改めて購入するのが最も良い手立てであるとわたしは考えています。月月の利用料金をすでにある程度支払っており、PS3版のFF14もしばらくした後に再開するつもりではありますが、気持を落ちつけるため少なくとも今月中は、複数回楽しんでおりPS3でも正常に楽しめることをすでに確認しているWHITE ALBUM 2を楽しみます。

先の記事である「誰がオープンソースソフトウェアを酷いものにしてしまうのか」に対する反応について、わたしから言えるのはクソだクソだ外野から汚い言葉を吐き散らすだけで済ましている状況が健全だと言えるわけがない。ただそれだけです。

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ディストリビューションのパッケージシステムで管理されていないと煩わしいと考えているのかもしれませんが、あまりにも甘えが過ぎるのではないかとわたしは考えております。

突然ですがカメラ (とレンズ (とSDカード)) を買いました。

突然ですがカメラ (とレンズ (とSDカード)) を買いました。

Recent Posts

Archive