Category Archives: Web技術

JJUG ナイト・セミナー 「ビール片手にLT&納涼会」でLTしてきました。

動画:

こちらが自分で

こちらが共同発表をしてくれた@smilelx_xl さんです。

去年の11月にCCCで発表させて頂いて以来、公の場で発表するのは二度目でした。共同発表をしてくれた、 @smilelx_xl さんは初めての発表だったようですが、手書き風スライドが好評でした。
一方僕の発表はビデオで見ると早口過ぎて聞き取れない、スライドは文字が小さすぎて読めないという相当ダメな内容で、改善の余地があることが分かりました。自分の発表をビデオで見るということは非常に勉強になり、撮影・youtubeアップいただいた、@yusuke さんには大変感謝致します。

今回の発表で伝えたかったことは、デザイナーさん視点の声でした。僕の発表は、@smilelx_xl さんがスムーズに発表できるための前置き的位置づけだと考えれば十分目的を達成できたのではないかと思います。
スライドで書いたように、2009年からMayaaを使い始め、この発表で扱われていることは、2010年から2012年頃の話です。その頃は自分の所属する会社も小さく従業員は一桁でした。プログラマーといえば、社員は僕ともう一人、Webデザイナーさんは@smilelx_xl さん一人でした。サービスを成長させる過程は面白いものですが、このテンプレートエンジンのこと一つとっても、世の中にシェアしたいと常々思っていました。ただ、多分僕一人出て行ってもインパクトがないので、@smilelx_xl さんに発表させたいと周囲に話したりしていました。もし、Seasar Conferenceが2011年以降も行われていたら、もっと早く応募して発表が実現していたかもしれません。JJUGはちょっと固いイメージがあったので発表するには敷居が高く感じていました。そんなJJUGも最近世代交代が行われたため、急に近寄りやすくなったと感じています。お陰で今回の発表を応募することができたと思います。

Twitterで「デザイナーは名前空間なんて言わないだろ」という的確なつっこみを頂きましたが、ごもっともです。実は今回の発表は、僕が事前に原稿案を作成し、@smilelx_xlさんに渡していました。@smilelx_xlさんはそのまま書かれたのですね。まったくもって「一般人に分かりやすい」用語を使っていない一例です。
今回はデザイナーとプログラマーの話でしたが、今回の話の概要は、実は、別の組み合わせでも成り立つと思います。違う職種同士共同作業をする上で大切なことは同じだと思います。一人で全部できてしまうスーパーエンジニアなら、もっと効率がよいかもしれませんし、実際にそういうスキルがある人も知っていますが、普通はなかなかいないでしょう。それに、やはり、違うバックグラウンドをもった人同士が共同作業をすることは楽しい。

そういうわけで「Aを利用してプログラマーとBが共同作業をする上で大切なこと」シリーズをやったらどうかと思いましたが、毎回僕が社内の別部署の女子を連れて発表したらさすがに殺されると思うので、うちのチームの誰かやってくれないかなーと思っていない(笑)

これでこの件の発表はおしまいと思ったのですが、尊敬する@skrbさんに、JJUG CCC 2013 Fall の Call for Paperに応募しないかとはっぱをかけられてしまったので、今回の発表をもっと詳細化したバージョンをまた@smilelx_xlさんと共同で計画しています。もし、採用されたら今度は早口にならずに丁寧に話したいと思います。

JVM用のJavaScriptエンジンをまとめてみる

JVM上で動くJavaScriptについて調べたので、メモしておきます。

これまでの状況

まずは、Rhinoが有名です。「ライノ」と呼びます。RingoJSMayaaなど、すでに広く使われています。Java6から標準でJDKにバンドルされています。(ただし、バンドルされたものは若干バージョンが古いです。)
Rhinoの他には Apache Aptana Jaxerというサーバサイドでscriptタグを解釈するフレームワークがあります。こちらは、C言語で書かれたSpider Monkeyを利用しています(JNIでしょうか?)。
Spider MonkeyとRhinoはともに、Mozilla傘下で開発がされている姉妹関係にあります。Firefoxで使用されているのはSpider Monkeyの方で、現在のFirefoxでは、TraceMonkey, JagerMonkeyのようにパフォーマンス改善が施されています。

サーバサイドJSといえば、Node.jsが有名ですが、JVM上では、RingoJSというフレームワークがあります。これはRhinoをベースにしています。

その他、Java上でChromeOSで使われているV8エンジンを使おうという試みもあります。
http://rbackhouse.blogspot.com/2011/03/using-google-v8-javascript-engine-in.html

これからの動き?

Java7から、invokeDynamic機能が搭載されました。これによって状況が変わりました。なぜかというと、invokeDynamicを使用すると、JVM上で動くスクリプト言語のパフォーマンスを向上できるからです。Rhinoはパフォーマンスのために、ソースコードが職人芸になってしまい、読みづらいと言われています。
OracleはJava8で、新しいJVM上でのJavaScript実装 Nashorn をRhinoの置き換えとしてリリースするとアナウンスしました。Nashornとは、ドイツ語で「サイ」を意味する(中性)名詞です。「ナズホーン」と呼びます。ちなみにRhinoは英語で「サイ」という意味です。ソースが公開されるのかについての言及はないので、商用製品としてリリースされる可能性があります。
他にDyn.jsというプロジェクトがApache2.0ライセンスで開発が進められています。これは、Dynalinkantlr3という、同じApache2.0ライセンスのライブラリをうまく利用して、ソースを読んで見ましたが非常に綺麗な印象を受けました。
Rhinoも開発が続けられていて、invokeDynamic対応が進められています。

今後どうなるのか?

2011年12月3日時点zipでダウンロード出来るバージョンのDyn.jsをダウンロードして実行したところ、次のコードが誤って実行されていました。

(funcion(x){print(x)})(1)

x

これはバグです。Rhinoで同じコードを書くと

1

と出力されます。最新版ソースからビルドしたものを使えば直っているかもしれませんが、やはりまだまだ開発途中という印象があります。ドキュメントが充実していないので、例えば、Javaオブジェクトとの連携方法がよくわかりません。RhinoではPackages.パッケージ.クラス名でアクセスできますが、この記法で統一されるのでしょうか?

Java8のリリースは2013年と言われているのでまだ時間があります。Rhino自体はパフォーマンスに問題がないため、今後も使われていくでしょう。NashornはOracleの力で、もしかしたら今後普及するかもしれません。Dyn.jsはソースが非常に美しいので、頑張って欲しいと思います。

HTML5ブラウザを内包するアプリケーションをJavaで作る場合は、V8エンジン+JNIを検討するのも選択肢として良いかもしれません。

Javaやが知るべき5つのJSエンジン

という釣りタイトルで以下のエンジンを列記した際は当エントリへ、今時流行らないトラックバックでもくださいw

  • Rhino
  • SpiderMonkey
  • V8
  • Nashorn
  • Dyn.js

5人揃ったので

赤ライノ、青スパイダー、緑ブイ、ピンクナズホン、イエローディーン、5人揃ってJSエンジャー

追記

2011/12/03 22:33 Aptana JaxerをApacheと記入してしまっていたので修正しました。やや言い回しやレイアウトなど修正しました。

この記事は以前多くのブックマーク・コメントを頂きました。

これからブックマークされる方はこちら↓

HTMLとCSSの棲み分けについて

前のエントリで、HTML5とCSS3の現代的な棲み分けとして、

div#container > div:nth-of-type(3) > div > aside p {
...
}

のような複雑なCSSセレクタを組み立てて、HTML側のマークアップは必要最小限のclassとdivを使った 美しいものとするという方針には「疑問がある」と述べましたので、そのことについての詳細と、ハンズオンの発表者:一條 美和子さんに伺ったことを書かせていただきます。

プログラムの世界では、連携には「密結合」と「疎結合」という用語が存在します。このブログは大半がプログラマーに読まれているはずなので、ぴんとくる人がほとんどと思いますが、「疎結合」ということは、交換可能とほぼ同じ意味です。

今までの、HTML+CSSの書き方では、HTML側にclass属性やid属性を多様していました。

<div id="main">
hello, world <span class="number">2011</span>
</div>

こんな感じですね。このような形だと、HTMLがCSSに依存していると言えます。CSSから見たら、IDやclassという独自ルールの中で完結しているので、HTMLページとは疎結合です。HTMLから見ると、CSSにIDやclassを制約されてしまいますが、classは文字列に過ぎないので、ゆるい密結合です。この形なら、一つのHTMLに対し複数のCSSを、逆に一つのCSSに対し複数のHTMLを割り当てることができます。

そのかわり、

ページのタイトルは必ずtitleクラスをつけること

などの制約をHTML側にかけることになります。この方法は、一種のテンプレートエンジンを作っていることになります。IDとclassを一定のルールに当てはめれば統一的なデザインフレームワークに落とし込めるという考えです。

もし、これとは反対に、HTML側にはclass属性やdiv、spanタグは可能なかぎり書かず、CSSがセレクタでデザインを頑張ったとすると、そのCSSは、対象のHTMLに強く依存してしまいます。CSSから見たHTMLは密結合です。そのかわりHTMLはCSSに対してほぼ自由です。

このことのメリットは、HTMLが自由だということ。より、文章構造に特化することができ、CSSはデザインというふうに役割分担が徹底できます。デメリットはCSSに対するHTMLの交換ができないということです。極端に言えばページ一つ一つにひとつのCSSを書かなくてはなりません。

確かに、HTMLの本来の意味には正しいかもしれません。しかし、エンジニアリングの観点からすると、CSSファイルが複雑化し、CSSセレクタのトラブルも発生しがちですし(ページ書き換えたら崩れたなど)、複雑なCSSセレクタは処理が遅く、開発スピードも落ちるのではないかと危惧します。

いちじょうさんに聞いてみた

この件について、ハンズオン発表者のいちじょうさんに、懇親会で突撃して質問させていただきました。自分もお酒が入っていて完全に覚えていないので、間違っていたらごめんなさい。しかし、とにかく何か 信念を持たれていて、よろしくないマークアップは極力排除しようと熱い想いを持たれていました。

私「そもそもマークアップをHTML5で厳格にやるという発想に驚きました。そう言うのは本来XML(XHTML)の仕事ではないでしょうか?」

HTML5ではなく、XHTML2.0が出来ていたなら、さらにルールが厳格化されたでしょう。しかし、受け入れられたのは緩やかさが必要です。理想を求めるのではなく、実社会では現時点でベターな一時的な存在が必要なのです。

「テンプレートエンジンなどを作っていると、IDやclassが一定のルールで制限されますがそれは望ましくないのでしょうか?」

実は仕事上そのようなテンプレートエンジンを扱うことが多いです。あまり望ましくはないですが、しぶしぶ使います。それでもなるべく不要なIDやclassは避けるようにします。class='red'などは、色が赤じゃなくなったらどうするのか?と言って部下には書かせないように徹底しています。

「HTMLからデザインを排除する目的はなんですか?」

HTMLは見た目ではなく、URLに対応する「リソース」だと思います。例えば、デザイナが文字に色をつけたとして、それは「色を付けただけ」なのでしょうか?必ずそこには「強調したい」などの意味が含まれています。

考察

いちじょうさんに伺ってわかったことは、現段階も理想型ではないということです。Webで提供されるのは紙ではなくデータです。したがって扱うのは見た目ではなく情報なのです。データを情報として扱うのに最適なフォーマットを使い、見た目の部分を外出しすることがURL=リソースを中心としたWebという世界のあり方なのですが、しかし現実はそこまで追いついておらず、各種ハックを使いながら、理想を目指して歩んでいるのだと思います。

自分もCSSが不慣れなだけで、慣れればこの書き方は良いのかもしれません。CSSはimportもでき、mediaクエリや、いろいろな道具を使い分けることで、かえって共通化を徹底できるかもしれません。マークアップ側もよりルール化された記述をすることで、統一性のあるページ群をつくることが 出来るのかもしれません。

言えることは、今あるものも理想型などではなく、理想に向かっての一時的な状態であるということです。理想に向かって現実を一歩一歩踏みしめることで、未来のWebがより一層便利なものになると思います。

だれも何が答えかなんてわかりません。