 
|
はてなキーワード: DOMとは
先日「Flashエンジニアが今後10年食べていくには？」というテーマを元に
Flash に精通した Web 技術者達のディスカッションが行われる催し物があった。
http://www.publickey1.jp/blog/11/flash10.html
この記事だけでは内容が省略しすぎているため
時間があれば是非録画の模様もみていただきたい。前半初頭は音量が小さいので注意。
こういった催し物は面白いなと、私はとても楽しく見させていただいた。
http://www.ustream.tv/recorded/19073524
http://www.ustream.tv/recorded/19074357
ディスカッションでは Flash だけではなく HTML5 についても触れている。
ディスカッションの感想をディレクションや営業を行なっている知人に聞いたり、
ネット上の反応を見てみたところ以下のような意見がいくつかあった。
「『Flash が好きな人』だけではなく HTML5 派の人との対談もあればよかった」
「Flash 派の人の話だから HTML5 が使えないという話はいまいち参考にならない」
『Flash 派』『HTML5 派』という くくりで考えてしまう人は
まだまだ多いと実感する。
パネリスト達は
過去から現在までに様々なプログラミング言語を利用し、あらゆる技術に精通している。
Flash という表示媒体/環境開発がベター(時にはベスト)だと考え、
Flash をよく扱っている、という旨を話している。
最後の締めとして
Flash よりも優れたものが登場するのであればそちらに移行するでしょう、
とも言っている。
これだけの説明があったのに
ディスカッション内で触れた HTML5 に対する否定的な話は、
『Flash 派』とやらのポジショントークだと目に写ってしまったのだ。
Java やら C やら objective-c やら perl やら php やら
サーバサイドからスマホ用ネイティブ言語を用いてのアプリ制作まで
色んな事やってます、と言っても
現在世の中には HTML5 を推し、合わせて Flash を否定する記事が結構出回っている。
技術者が話す専門的な用語の飛び交う話よりも
HTML5 vs Flash 的な読みやすい記事に耳を傾けてしまう人はいる。
Apple 製品を好む人は「ジョブズがそう選択したのだから」と
なおさらこういった記事に目を向けてしまう。
「Flash vs HTML5 の話にのせられてしまうのは、よくわかっていない人だ。」
ディスカッション内では、
ネット上の煽り記事を読み不安に思ったクライアントから連絡を受け
きちんと状況をゼロから説明するハメになってしまった、という内容があった。
似たような状況になっている人もいるのではないだろうか。
当方周辺では、
「Flash は駄目だ」「Flash でなくても HTML5 ならできるはずだ」
「HTML5 は Flash の代わりになるものだと言われている」と
クライアント、あるいは仕事先の関係会社から耳にする機会が増えてきた。
技術者の及ばないところで
ベターではない技術が選択、あるいは勧められてしまう やっかい性。
その記事は世間の目には届かない。
TV CM でバンバン流れている iPhone や iPad では Flash を見ることができない
という状況に乗じた
勘違いを正すためには、今までよりもより一層
あるいはメッセージを発信するよう心がけていかねばならないと感じる。
パネリスト達のような
Flash を扱う事が可能な技術力を持ち合わせている人にとって
Flash が終わろうが、代わりの技術が HTML5 やらその他何になろうが
大した影響はない。
『プログラミング』についての話をしてみる事にする。
「世にあらゆるプログラミング言語があるが
「何か一つ言語を習得し
『Flash の事は全く知らないがプログラミングプロフェッショナルの人』
が近くにいるならば是非上記について伺ってみてほしい。
その通りだと答えてくれるはずだ。
他の言語で作ったものを Flash のプログラミング言語に移植することも容易いのだ。
ここで上記三行の「他の言語」を「JavaScript」に置き換えてみてほしい。
HTML の DOM 操作に必要な言語は JavaScript である。
言語は、Flash ならば ActionScript、HTML5 ならば JavaScript を用いる。
画面描画は
あるいは用意されている描画用 API を ActionScript で呼び出し、
あるいは用意されている描画用 API を JavaScript で呼び出す。
Flash と似たような技術として Java Applet や Shockwave があるが、
これらも一緒で
言語を変え、その技術に合わせた描画を行う処理を記述するだけだ。
Web 技術者が何かに属していて、何かには属していないかのような区別の仕方は
的がはずれている事を なんとなく感じていただけただろうか。
仕事に対し、あるいは表現したい事に対し、ベターな選択を行うだけの事なのである。
環境や表示内容に合わせ両方を採る選択もあるだろう。
パネリストの中に ActionScript が好きだ、という人がいた。
これは別に
Flash が好き(製品のファン)だから ActionScript が好き、と言っているのではない。
ActionScript が優れたプログラミング言語だと判断しての発言なのだ。
HTML5 を選択するだけの事であり、
その別の技術を選択し、
Flash より優れた技術が登場しなければ Flash を使い続ける、
ただそれだけの事なのである。
もう少し突っ込んだ話をすると
Flash のプログラミング言語である ActionScript(ActionScript 1.0)と
HTML 表示制御を行う言語 JavaScript は 実は同じ言語仕様である。
『ECMAScript』という単語で調べてみてほしい。
「Flash と HTML5 は対立するもの」と考えていた人、
あるいは ActionScript や JavaScript を触れたことがない人にとって
「え？そうなの？」と思う人もいる事だろう。
JavaScript は大規模開発に向いていない、という話は聞いたことがないだろうか。
同様の言語仕様である ActionScript 1.0 はこの問題を解決するため
ActionScript 2.0 から ActionScript 3.0 へと進化していった。
Flash は開発がし易い、という話がよく挙げられるが
その理由の一つがこれである。
現行の JavaScript と ActionScript 1.0 は ECMAScript 3 準拠に対し、
ActionScript 3.0 は ECMAScript 4 準拠である。
言語として進化しているものを Flash は採用しているので
開発は抜群にし易い。
ECMAScript 4 準拠の JavaScript も登場する日もあったかもしれなかったのだが、
ECMAScript 4 標準化が白紙、
ECMAScript 4 は無かったことになってしまったのだ。
ActionScript 3.0 で作成したプログラムが
ちなみに JavaScript は大規模開発に向いていない、という事に対し、
最近では Google が新言語 Dart というものを開発している。
位置づけとしては ActionScript 2.0 に近いと比喩した人もいる。
ActionScript 2.0 はコンパイル時 ActionScript 1.0 に変換されて出力される。
Dart も同じく JavaScript 変換機能を持つ。
先の事は誰にもわからない。
HTML5 が成長するとは必ずしも言えない。
技術者は身を持って知っている。
表示と動作の差異、技術者はずっと苦しめられてきている。
めんどくさい。コストがかかる。
HTML5 も同じ道を辿るのでは、と言われてしまうのも仕方がない。
実際に HTML5 の各ブラウザの実装具合はバラバラである。
Flash はといえば、
今でも 10年以上前のスクリプト言語 (ActionScript 1.0 よりも前の言語)で
Flash が動作するブラウザがいつまで携帯に搭載され続けるのか、
まだ誰にもわからない。
今後も当面携帯向け Flash を作り続ける事になるのかもしれない。
携帯向け Flash は一つの容量が小さいというのが救いである。
IE6 対応 HTML サイト制作にせよ、携帯向け Flash 制作にせよ
状況に応じて何を選択するかを判断できるほどの技術力を身につける事
選択する技術に何ができて何ができないのか、
どの技術を組み合わせるとよいのか、
自ら判断できるようになった時、一人前の Web 技術者になったと言えるだろう。
一つ何かをモノにしてしまえば前述の通り移行は容易い。
それを極めるくらいまでとことん勉強してほしい。
続けていくと見えてくるはずだ。自信という名の悟りの道が。
気になった点をいくつか。
現状の HTML5 の実装具合のバラバラさに対し、
「(HTML5の)表示の差分を埋めてくれる何かが登場するかもしれない」
と言う発言があった。
言った当人も会場にいる人達も、きっとこう思っただろう。
「それってなんて Flash Player？」と。
「あれはやめたほうがいい」という発言があった。
勝手に注釈するのであればこの発言は
「Flash で作られた重たい Web を HTML5 でまた再現するつもりなの？」
という皮肉であろう。
【お知らせ】2011/09/07
http://d.hatena.ne.jp/uniqueweb/20110906/1315285545
プログラムは全く得意じゃないけれど最近よく見かけるようになったエロ動画検索を自分でも作ってみたくて頑張ってみました。
近年、インターネットの普及によりエロ動画が自宅で簡単に見れるという素晴らしい時代になりました。
自分が若い頃はインターネットなんてものはなくエロビデオが主流でドキドキしながらレンタルビデオ屋に行き、可愛い女の子がレジにいない隙を見計らってお兄さんにパッケージを伏せて空箱を渡しビデオを借りたものでした。
お兄さんにビデオの空箱を渡そうとした時に可愛い子がレジに戻ってきて焦って渡すのをやめてものすごく変な動きをしながらエロビコーナーに引き返していくなんてことも多々ありましたｗ
僕のお気に入りといえば「白石ひとみ」や「あいだもも」といった女優でよく借りてました。エロビを借りるということがものすごく恥ずかしい時代？年頃？でカモフラージュに普通のビデオと一緒に借りるということもしていました。それはそれは大変な思いでオナニーしてたんです！
しかも、ビデオデッキ自体が貴重な時代でリビングに一台しかないのが当たり前でした。
深夜家族が寝静まってからヘッドフォンとビデオを抱えリビングに行き暗がりの中でヘッドフォンをテレビに差し込んでビデオの再生ボタンを期待に胸をふくらませながら押したものです。いいシーンを何回も見るためにビデオを巻き戻すんですが、ビデオを巻き戻すガチャンガチャンという機械音で家族が起きてこないか？とかそれはそれはドキドキしながら見てました。一仕事終えたあとヘッドフォンを外したらジャックが外れていて大音量で喘ぎ声が響き渡っていたなんてこともありました。誰も起きてこなかったのは優しさなんでしょうか？ｗ
さて、大分前置きが長くなりましたがエロというものはものすごい技術発展させるものだと思います。エロのおかげで日本でビデオは普及しエロのおかげで日本でインターネットはものすごく普及したと言っていいと思います。自分もエロを通して技術の発展に貢献し自分自身のスキルアップになれば。という高い志を持ってこのサイトを制作しました。決して自らのオナニーライフの充実と性癖を充たすため作ったわけではありません・・・ｗ
※2011.08.07 利用中のサーバーに障害が発生しているようで現在サーバーに接続できない状態となっています・・・
サイト名の由来は抜きネタからきています。抜きネーター、ヌキネーターという感じですｗ
エロサイトの制作工程を日記にしてみたんで良かったら読んで下さい。そしてこのサイトを使って夜いろいろと励んでくれたら嬉しいです。
まず前提条件としてお金をほとんどかけたくない。アダルトサイトであるということから
月の予算は5000円以内で考えていたのでけっこう探すのが大変でした。
日本でアダルトサイトを許可している所はかなり限られていてさらにやりたいことができるのは
専用サーバーかVPSしかないのでそうなると専用サーバーは予算オーバーなので
VPSで探すことになり検索しまくってはじめに見つけたVPSはKAGOYAのVPSだったのですがβ版で募集を締め切っていて泣く泣く諦めました。
KAGOYAはかなり評判がいいみたいなので使ってみたかった。
次に見つけたのが○○○VPS。海外サーバーで日本語サポートがあり転送量の制限なしディスク容量100G
月1300円程度で借りれるということで初期設定費用に5000円程度かかりましたが借りてみました。
結果、ここは最悪でした。
あまりの酷さに1ヶ月で解約。
よく調べてみたら評判がものすごく悪い某VPSの再販らしいです。
もう失敗したくないと思い今度は比較的有名な海外サーバーLINODE。
iptablesの設定でどうしてもうまくいかなくて拙い英語でメールしてみたら
10分しないうちに返信がきました！
メールに書かれているとおりにコマンドを入力したらあっさり解決。
担当のブライアンはなぜか分からないけどとてもフレンドリーで親切に感じましたｗ
LINODEは複数のディストリビューションから好きなものを選択できるので
とりあえず、64bit版を選択。
一番面倒だけど重要だということで
Tripwire
ほんとに面倒でした。
はじめはmysqlにストレージエンジンgroongaを使おうと思ったのですが
初めに借りた最悪なVPSはOSが32bit版だったのでgroongaがのソースが見つからずなぜかと思っていたら
どこかで見つけた記事で32bit版ではgroongaの性能を発揮しきれないということで32bit版の提供をやめてしまったらしいと書いてたので
じゃあ、sennaにするかということで最悪VPSでsennaをインストール。
その後LINODEに変更したのでOSに64bit版を選択し念願のgroongaをインストール。
しかし、調べてみると
プログラムもそれに合わせてその都度書き換えたので2度手間どころか3度手間4度手間でした・・・
まず
そして下記の順番でインストール
rpm -ivh mecab-0.98-tritonn.1.0.12a.x86_64.rpm
rpm -ivh mecab-ipadic-2.7.0.20070801-tritonn.1.0.12a.x86_64.rpm
rpm -ivh senna-1.1.4-tritonn.1.0.12a.x86_64.rpm
rpm -ivh MySQL-shared-5.0.87-tritonn.1.0.12a.x86_64.rpm
rpm -ivh MySQL-client-5.0.87-tritonn.1.0.12a.x86_64.rpm
rpm -ivh MySQL-server-5.0.87-tritonn.1.0.12a.x86_64.rpm
rpm -ivh MySQL-devel-5.0.87-tritonn.1.0.12a.x86_64.rpm
my.cnfの設定をして終了
で肝心の全文検索ですがデータ件数が5万件程度で少ないせいなのか、あいまい検索と比べてそれほど速さを実感できなかったです・・・
でもきっとすごく速くなったはず！
ちなみに「麻美ゆま おっぱい」で検索した場合、0.01 secで結果が返ってきました。
さて、動画データの作成ですがいくつかのエロサイト等制作記事でもあるようにスクレイピングということをします。
スクレイピングとはWEBサイトから特定の情報だけを取得することでネット上にあるサイトをクロールして必要なデータだけを拾ってデータを作るといった感じでしょうか。
スクレイピングのプログラム自体は以前にTidy関数を使って為替データを10分おきに取得するような物を作ったことがあったのでそれほど時間はかからないかなと思ったのですがけっこう時間かかりました。
スクレイピングにはTidyとhtmlSQL、それにPHP Simple HTML DOM Parserを使いました。
SQL みたいな文法で HTML を抽出する PHP のライブラリ
htmlSQLよりアツい!?jQueryみたいにセレクタでHTMLをparse(解析)する「PHP Simple HTML DOM Parser」
３つの中で抜群に使えるのはPHP Simple HTML DOM Parserだったんですが
ループ処理させるとメモリがすごいことになって今回のようなスクレイピングに向いてないみたいで
結局、htmlSQLとTidyの両方を使ってスクレイピングしました。
両方ともPHP Simple HTML DOM Parserに比べるとうまくデータの取得ができないことが多く残念な感じなんですが他に選択肢がないので・・・
使える順に並べると
といった感じかもしれません。
おおまかにデータを取得して正規表現で特定データを抜き出しました。
http://affiliate.dmm.com/link.html
利用可能な物はパッケージ画像、サンプル画像（縮小）と書かれていたのでそれに従い画像を利用。
注記に※ユーザーレビューは引用いただけません。とだけ書かれているのでそれ以外は引用ありと判断して説明文とタイトルなどを利用
女優データとジャンルデータ、DVDデータ、を紐付けたデータベースを作成し検索ワードに応じて検索結果に関連する商品を表示させるようにしました。
現状、売り上げ0で意味があるのか分かりませんけどｗ
エロサイトということで多少はチューニングとか設定とかしないとまずいかもと思い色々調べて設定しました。
やったこと
KeepAlive On MaxKeepAliveRequests 60 KeepAliveTimeout 3 <IfModule prefork.c> StartServers 7 MinSpareServers 5 MaxSpareServers 10 ServerLimit 30 MaxClients 30 MaxRequestsPerChild 4000 </IfModule>
様子見ということで2日間で設定してみました。
query_cache_limit=1M
query_cache_min_res_unit=4k
query_cache_size=16M
query_cache_type=1
とりあえずこんなところを設定してみましたが、爆発的なアクセスがあるわけでもないので有効なのか今のところ分かりません(-_-;)
Apache Benchでテストはしてみましたけど問題はない感じですが実際にチューニングができているか分かりません。
プログラマーとして有名なゆうすけさんのサイトとgoogleを参考にしました。
シンプルで使いやすいようにしようと思いこのデザインにしました。
クロスブラウザはIE7、firefox3、chromeで行いました。
可変ものって作ったことなかったんですがけっこう面倒なんですね。
ブックマーク機能とメニューの折りたたみ機能、検索結果の表示方法切替を作りました。
まず、ブックマーク機能ですがログインなしで気に入った動画をブックマークできるようにしました。
ブックマークに追加した動画はブックマークページで確認できるようにしました。
cookie機能を利用したらいけると思い色々調べてjquery.cookie.jsを利用。
保存したクッキー情報を呼び出してphpに渡して処理し指定要素にブックマーク一覧をloadメソッドで表示させるという感じです。
$(function(){ $("#youso").load("xxx.php"); });
メニューの折りたたみ機能は人気AV女優やAV女優別、人気タグなどをそのまま表示させるとずらっと長くなって邪魔だったのでつけました。
これには同じくjquery.cookie.jsを利用しました。
参考サイト：http://blog.caraldo.net/2009/03/newjqqookiemenu.php
検索結果の表示方法切替にはZoomer Galleryを利用しました。
参考URL：http://phpjavascriptroom.com/?t=ajax&p=jquery_plugin_zoom#a_zoomergallery
検索結果ページで表示される
[ここの画像]
××× の検索結果
44件中 1～10件目を表示
ここの画像の部分をクリックするとgoogleイメージ検索みたいに一覧でイメージ表示できるようにしてみました。
基本的に動画の埋め込みを許可しているサイトのみプレイヤー表示をしそれ以外は画像を表示し動画データへリンクするようにしました。
埋め込み部分はあらかじめそれぞれのサイトに対応したプレーヤー部分のコードを記述しVIDEOIDの部分に置き換えるような形にしました。
XVIDEOSを例にすると
XVIDEOSの場合かならず動画のurlがhttp://www.xvideos.com/videoXXXXXX/のようになりますのでXXXXXXの部分を
VIDEOID部分に置き換えるようにプログラムを組みました、
埋め込み部のソース
>||<object width="510" height="400" classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" ><param name="quality" value="high" /><param name="bgcolor" value="#000000" /><param name="allowScriptAccess" value="always" /><param name="movie" value="http://static.xvideos.com/swf/flv_player_site_v4.swf" /><param name="allowFullScreen" value="true" /><param name="flashvars" value="id_video=VIDEOID" /><embed src="http://static.xvideos.com/swf/flv_player_site_v4.swf" allowscriptaccess="always" width="510" height="400" menu="false" quality="high" bgcolor="#000000" allowfullscreen="true" flashvars="id_video=VIDEOID" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" /></object>
||<
その他の動画サイトもURLの一部分のデータを使っているので同様の処理をしました。
実際の作業は２、３週間ですが色々調べる時間が多くて制作に2ヶ月くらいかかりました。
自分でエロ動画検索を作ってみて有名プログラマーさん達がいかに優秀なのか思い知らされました。
全くWEBの知識がない人で４、５ヶ月ですごいの作っちゃう人とかもいるみたいですし世の中広いな～と思います。
大分、色んな知識を得ることができました。
これからプラグラムを勉強しようと思う人はぜひエロサイトから入ってみて下さい。
そんなこんなで？頑張って作ってみたエロ動画検索、良かったら使ってみて下さい。
これで少しは技術の発展に役立てたでしょうか？ｗ
P.S エロサイトを作っていてはじめは楽しくて興奮しながら作ってたのですが最後の方はエロい物を見ても全く反応しなくなりましたｗ
不能ではないんですけど・・・今現在も性欲が著しく減退しております・・・
そしてスーパーpre記法がうまういかないのはなぜ？はてな匿名ダイアリー初投稿で全然分からない・・・
そしてそしてプログラマーさんとかデザイナーさんとかエロい人とかお気軽にお声をおかけ下さい。
【お知らせ】2011/09/07
最近マークアップエンジニア志望の若者と話す機会が多いのだけれど、そこで気づかされるのは、彼らの中に過去のHTML（特に90年代以前の仕様）を読んだことのあるという人が、驚くほど少ないことだ。
例えば「マーク・アンドリーセンをどう思う？」と聞くと、「アンドリーセンって誰ですか？」という答えが返ってくる。「ヨスケの独自要素で何が一番好き？」と聞くと、「見たことがありません」と言われてしまう。「ではきみは、昔のHTMLを見たことがあるの？」と聞くと、たいていが「とほほでやっていたものくらいなら……」という答えしか返ってこない。
今の若い人の間では、HTMLを体系的にとらえようという人は少ないようだ。見るのは専ら近年の話題仕様ばかりで、歴史を辿ってみたり、系譜をひもといて標準化団体ごと理解しようとする人はほとんどいない。
これは、ちょっと由々しき問題だと思わされた。HTMLは、もう長いこと（90年代の早い時期から）インターネットの王者としてあらゆるWeb関連技術の上に君臨してきた。だから、Webを作ることを仕事にしたいなら、何をするにせよ避けて通ることはできない。
HTMLは、表・画像・フォーム・音楽・デザイン・フレーム・動画など、さまざまな分野においてその時代々々に達成された最新の成果を持ち寄るようにして作られてきたところがある。だから、HTMLを読まずして現代のインターネットは語れないと言ってもいいくらいだ。
もし何かクリエイティブなことをしたいのなら、HTMLを読むことは欠かせない。また、単に読むだけではなく、それを包括的・体系的にとらえることも必要だ。なぜなら、HTMLを包括的・体系的にとらえることによって、現代のインターネットそのものを、包括的・体系的にとらえられるようになるからだ。そしてそうなれば、Webを作ることの道理や筋道が理解でき、何かクリエイティブなことをする上で、大きな助けとなるからである。
そこでここでは、昔のHTMLをほとんど見たことがないという人や、あるいはHTMLそのものもあまり見ないという人のために、これを見ればHTMLを体系的に理解でき、現代インターネットの成り立ちや実相までをも包括的にとらえることができるようになる、7本の仕様を紹介する。
ここで紹介するHTMLは、いずれも後のWeb業界に決定的な影響を与えたものばかりだ。これらが、HTMLという標準のありようや方向性を決定づけた。この7本を見れば、HTMLというのはどのようなきっかけで生まれ、どのような変遷を辿って、どのような足跡を残してきたかというのが、体系的に理解できるようになる。そしてそれが、世界のインターネット利用シーンにどのような影響を及ぼしてきたかということも、知ることができるようになるのだ。
まず最初は、ちょっと強引かも知れないけれど、第一次ブラウザ戦争前のHTMLをひとまとめにするところから始める。
80年代末にティム・バナーズ＝リーの発明したHTMLというメディアは、その後『HTML 1.0』（1993年）『HTML+』（1994年）『HTML 2.0』（1995年）などの仕様で次第にそのスタイルを確立していき、マーク・アンドリーセンが一大産業として発展させた後、『HTML 3.0』に行き着く。そして幸運なことに、ここに集大成されるのだ。
ブラウザ戦争前のHTMLは、これ1本だけ読めば良い。このHTMLに、戦前のHTMLの全ての要素（属性）が詰まっている。このHTMLを見れば、HTMLのインターネットの王者としての風格、スターという存在の大きさ、作者以上にブラウザが重視される「産業」としての側面、お尻Pから終了タグ省略可へ・文字情報から画像付きへと移り変わった技術革新の変遷など、戦前のHTML史やWeb業界のありようが全て分かるのだ。
このHTMLの魅力は、説明し始めるといくら紙幅があっても足りないので、ここではその一端を紹介するにとどめておく……といっても、気の利いたことを言えるわけではない。『HTML 3.0』の魅力を知るには、まずは読んでもらうこと――これに尽きるからだ。そして、もし一度でも読めば、その魅力はたちどころに理解できるだろう。
『HTML 3.0』を見て驚かされるのは、現在のHTMLと比べても全く遜色ないところである。破棄されてから14年の時が経過しているが、現代人の読解にも当たり前のように堪えうるのだ。それは、逆にいえばHTMLというものは、今から14年前、つまりこの『HTML 3.0』が作られた時点で、様式として一つの完成を見たということでもある。
『HTML 3.0』は、HTMLという標準が到達しようとした一つの極みである。それゆえ、HTML史というものは、『HTML 3.0』以前と以降とで分けられるようになった。これ以降に作られたHTMLで、『HTML 3.0』の影響を免れたものはないからである。
iモードが世界のHTML史に与えた影響というのは、一般に理解されているよりもはるかに小さなものである。日本人というのは、「日本の技術が世界に影響を与えた」というと、なぜか鼻高々と聞いてしまうところがある。「日本はガラパゴス」という言葉は聞いたことがあっても、「それって日本人が過小評価しているだけじゃないの？」と、眉に唾をしてとらえるところがある。
しかしiモードは、真に日本のHTML史を塗り替えたサービスの一つである。特に、このサービスの後世に与えた影響には、本当に計り知れない大きさがある。
iモードは、ドコモのメインストリームだったポケットベルが、それまでの栄華の反動で深刻な低迷期に陥っていたPHS流行後すぐの時期、そんなポケットベルに取って代わって、日本で最も輝いていた携帯サービスであった。それゆえ、広末に見蕩れた世界のHTMLファンたちは、iモードのWebサイトを見ることによって、失われかけていたWeb制作の魅力を再発見することにもなったのである。
iモードは、没落したHDMLに変わってモバイルWebの命脈をつなぎ止めた、言うならば救世主のような存在であった。海外のモバイル陣営が営々と築きあげてきたそれまでの栄光を切り捨て、日本の後代へと引き継いだ重要なリレー第一走者としての役割を、HTML史において担ったのである。
そして、そのバトンを受け取った日本の若きWebデザイナーたちが、2000年代に入って雨後の竹の子のように現れたことで、モバイルWebは鮮やかな発展を遂げる。だから、もしiモードが存在しなければ、HTMLの様相は今とは違ったものになっていたかもしれないのだ。
そんなiモードHTMLのバージョンはいくつもあるのだが、中でも特に多くのHTMLファンを――取り分け日本の若きWebデザイナーたちを魅了したのが、この『Compact HTML』である。この仕様の一番の魅力は、なんといってもその大胆に構築されたW3C Noteであろう。HTML史において、これほど拡張多く適当なディテールで構成されたNoteは他にない。そのためこのNoteは、これ以降無数に手本とされ、真似され、拡張されることとなるのである。
正字正仮名の影響を受けた日本の若き日記書きたち――言うなれば「CSSコミュニティ」――が頭角を現す直前のW3Cで、HTML史に乾坤一擲の巨大な爪痕を残した1本の仕様が誕生する。
この時期、情報技術の進歩によって、HTMLにもさまざまな新しいテクノロジーがもらたされていたのだが、それらを十全に取り入れたばかりではなく、縦横に駆使することによって、これまでとは全く違った国際化、全く違ったアクセシビリティ体験を生み出すことに成功したのが、この仕様『HTML 4.0』を勧告したWorld Wide Web Consortiumである。
『HTML 4.0』は、HTML史において最も革新的な仕様の一つとなった。この仕様に初めて触れた当時のWebデザイナーたちは、そのあまりの目新しさに度肝を抜かれた。そこでは、これまで全く見たことのないマークアップがくり広げられていた。そのため、これまで想像さえしたことのなかった全く新しいHTML体験を、そこで味わうことになったからである。
W3Cの果たした一番の功績は、テクノロジーとHTMLを見事な調和をもって融合させたことだろう。例えばそこでは、「スタイルシート」という新しい技術のデザインと、それでレイアウトされたページが閲覧者に与える独特の感覚というものを、双方ともに熟知していた。だから、それらを効果的に融合させることによって、全く新しいHTML体験を生み出すことができたのである。
この仕様『HTML 4.0』には、そうしたテクノロジーとHTMLとの融合が、至るところに散見できる。その数の多さとクオリティの高さによって、HTMLはここに、新しい時代の幕開けを迎えるに至ったのである。
先に述べた「CSSコミュニティ」がWeb日記業界に論争をもたらすのは、2000年代に入ってからのことである。そして、そのきっかけとなったできごとの一つが、1947年生まれの非政府組織で、IECとも協力した生粋の工業標準化団体であった国際標準化機構が、この仕様『ISO/IEC 15445:2000 (ISO-HTML)』によって成功を収めたことである。
このHTMLは、単にJIS的に標準化しただけではなく、文化的な意味においても、フラットでリニアな構造の力を広く世界に知らしめることとなった。この仕様の成功によって、世界の人々は、レベル付けされた見出しの魅力の大きさを知る。そしてそれが、やがて見出しのレベル分けが世界のスタンダードとなり、誰もが当たり前のように使う状況を育んでいくのである。
またこの仕様は、CSSコミュニティそのものにも大きな影響を与えた。この仕様の成功に刺激を受けた才能ある若きコミュニティ住人たちが、その後立て続けに台頭し、いくつもの名サイトを生み出していくからである。
それらが相まって、やがてCSSコミュニティは空前の黄金時代を迎えることになる。その端緒となり、道筋を切り開いたのが、他ならぬこの『ISO-HTML』なのだ。
『HTML 4.0』で繁栄の足がかりを築いたW3Cは、この仕様『XHTML 1.0』によって、ついにその栄華の頂点に達する。そして、それを成し遂げたメタ言語も、W3C勧告のの一つであり、また『HTML 4.0』を作ったSGMLの改良でもあった、Extensible Markup Languageであった。
この勧告は、史上最も商業的に成功した仕様となる。そのためこれ以降、この勧告にならって商業的バズワードを盛り込んだ仕様が数多く作られるようになり、しかもそれらが、実際に大きな商業的話題を集めていくのだ。すると、そこで生み出された多くの意見は、やがて再びW3Cに還元され、さらなる発展をもたらすことにもつながった。
そんなふうに、この仕様がきっかけとなってW3Cにもたらされた意見は、HTMLという言語を変革させていくことになるのだが、それに伴って、HTMLそのものにも大きな革新をもたらすことになる。
その変革も、他ならぬW3Cの手によってなされた。ここで『XHTML 1.0』の成功によって手にしたメンバーをもとに創設した文書マークアップの開発集団「HTML Working Group」が、より魅力的な拡張性を追求していく中で、やがてM12n（モジュール化）という技術の開発に至るのである。するとそれが、これまでのHTMLを一変させたのだ。
M12nは、HTMLに魅力的かつ効果的な特殊語彙を、DTDでしかも複雑怪奇にもたらすことに成功した。おかげでそれは、あっという間に世界から見捨てられていった。そのため今では、M12nの使われているHTMLを探す方が難しくなったくらいだ。それくらい、この『XHTML 1.0』がWeb業界にもたらした変革には、大きなものがあったのである。
2000年代以降、繁栄を謳歌したW3Cは、しかしその栄華の大きさゆえ、00年代中盤に入るとそれを存続させることに力をそがれてしまい、革新的な仕様はなかなか生まれてこなくなった。
しかし、そんな時代が5年は続いた00年代の後半になって、今度はその栄華のただ中で育った新しい世代のHTML WGメンバーたちが台頭してくることにより、再び変革の時を迎えることとなる。
その新しい世代のHTML WGメンバーとは、マイクロソフトやモジラ・ファンデーション、オペラらに代表される「ブラウザベンダ」と、無関係な編集者たちであった。
彼らに共通するのは、文書構造に不必要なものなら全て――とるに足らないガジェット的なものまで含めて――残らず切り離そうとする「オタク的な性質」を持っていたことだ。
彼らは、それまで見過ごされがちだったHTMLの些末な要素にスポットを当て、それを別仕様に押し出すことで、従前とは一風変わった、新たな魅力を持った草案を生み出していった。そして、その真打ち的な存在として00年代の後半に登場したのが、XHTML2 Working Groupだ。
XHTML2 WGは、特に99年に最後の草案が作られたこの仕様『XHTML 2.0』によって、オタク的なHTMLの楽しみ方が、一部のマニアだけにとどまり、それ以外の多くの人たちには受け入れられないことを証明してみせた。この失敗が、デ・ファクト的な新生HTML WGにさらなる脚光を浴びせることになったのはもちろん、それに影響を受けたWeb WorkersやDOM Level 3 Eventsといった、次世代のWeb標準たちの誕生にもつながっていったのである。
最後は、第二次ブラウザ戦争の集大成ともいえるこの仕様である。
『HTML5』は、HTML史においては『HTML 3.0』と同じような意味を持つ。つまり、それまでのHTMLの要素が全て詰まっているのだ。この仕様を見れば、それ以前のHTMLの歴史というものが全部分かる。
『HTML5』には、HTMLのあらゆる要素が詰まっている。ここには、『HTML 3.0』のような歴史的な仕様としての「総合性」があり、『Compact HTML』のような「実装の実在さ」がある。『HTML 4.0』のような「マルチメディアとアクセシビリティの融合」があり、『ISO-HTML』のように「セクション構造の魅力を全世界に知らしめ」た。また、『XHTML 1.0』のように「バズワード的に成功」したのはもちろん、『XHTML 2.0』が別仕様に押し出した「オタク的ガジェット」にも満ちている。
全て詰まっているのだ。なんでもあるのである。つまりこのHTMLは、『HTML 3.0』と全く同じ意味合いを持っているのだ。HTML史というものは、『HTML5』以前と以降とで分けられる。これ以降に作られるHTMLで、『HTML5』の影響を免れるものはないであろうからである。
以上、これさえ読めばHTMLを包括的・体系的にとらえることができる7本の仕様を、制作された年代順に紹介した。
こうして見ると面白いのは、歴史的に重要な仕様は、必ずしも定期的に現れるのではなく、あるところでは連続しているし、あるところでは長らくなかったりすることだ。それはまるで「素数の分布」のようだ。一見規則性はないように見えるものの、何かしらの法則が隠されているようでもあり、興味深い。
それから、ここに挙げた仕様は、いずれも「読むことによって他の仕様にも興味が移行する」ということを念頭に選んだ。
例えば、『HTML 3.0』を読んだならば、ブラウザ戦争前夜の独自HTML拡張に自然と興味がいくだろうし、『Compact HTML』を読んだなら、iモードのそれ以外のバージョンのHTMLも見たくなるだろう。CSSコミュニティについてもそれは言えるし、『ISO-HTML』を読んだなら、このHTMLを流行らす土壌ともなった「フラットでリニアな構造」というムーブメントにも自然と興味がわくはずだ。さらには、『XHTML 1.0』はXMLオタクになるきっかけになるだろうし、『XHTML 2.0』はその他の「オタク的なXML EventsやXForms」の仕様も見たくなるという効果を持っている。
ただし、最後に選んだ『HTML5』だけは、こうした例とは別に考えなければならないかも知れない。なぜならこのHTMLは、完成度があまりにも高いために、これを見た後に他のHTMLを読むと、どうしても物足りなく感じてしまうからだ。
しかしいずれにしろ、これらの仕様を読むことによって、HTMLをさらに愛さずにいられなくなるのは疑いない。そしてまた、これらの仕様を読むことによって、HTMLを包括的・体系的に見る目を養ってもらえれば、その後のクリエィティブな活動にも、大きな助けとなるはずだ。
上に挙げた仕様への理解は、以下に紹介する著作を読むことによって、さらに深まる。これらを読むことによって、ぼくは「HTMLを体系的に見るとはどういうことか」を学んできた。
高校時代に読んだこのサイトによって、「リソースとは何か」ということを、ぼくはを知った。
「HTMLはSGMLの応用だ」ということが、このサイトを読むことでよく分かる。何気なく見ていた省略記法でも、その裏には、実にさまざまな技術や、それを開発してきた歴史というものが隠されていた。
世界がCSSコミュニティの何に驚かされたかといえば、それはやっぱり精緻に書き込まれた正字正仮名にだ。ノジタンの日記には、HTMLの本質が詰まっている。だからこそ、あれだけ多くの日記で多くのコミュニティ住人に、言及されたり模倣されたりしたのだ。
ここでは取りあげられなかったのだが、とほほ氏がHTMLというジャンルに及ぼした影響にも、本当に大きなものがある。そして、ぼくが上に挙げた感想のいくつかは、このサイトに書かれていたばけらさんとの「スタイルシート論争」を参考にしたものなのだ。
これらのサイトを読めば、どんなHTMLが素晴らしく、どんなHTMLがそうではないというのが、よく分かる。その判定基準を知ることができ、審美眼を養うことができるのだ。なにしろ、あのCSSコミュニティ住人の言うことなのだ。これにまさる教科書は、他にはない。
【元ネタ】
たしかにjavascriptをきっちりマスターすれば、それは強みになるかもしれない。
しかし、いかんせんアクが強すぎる。王道になり得ない。
まず、javascriptだけで完結しない。どうしてもサーバサイドが絡む。
いや、javascriptで完結できるよ、と思うかもしれないが、それは特殊だ。ニッチだ。
何を言っても今のところ、javascriptは組込み言語の域を出ていない。
実行環境が特殊過ぎる。
ファイルシステムがあってプロセスがあってネットワークがあるOSに透過な環境で動かない。
DOMがあってHTTPでデータが運ばれてシングルタスク的な環境になってる。
そして、クラス/インスタンスモデルではなく、プロトタイプチェーンモデルだ。
サーバソフトウェアから使い捨てプログラムまで書くような言語ではない。
プログラミングの体験には良いかもしれない。オブジェクトを体験するには良いかもしれない。
しかし、程々にして他の言語に移った方が良い気がする。
javascriptを極める前にマルチリンガルを目指せ。
……。
当たり前か。
一つの言語で満足できるわけない。
セクショニング・コンテンツ要素やセクショニング・ルート要素のアウトラインは、一つ以上の潜在的にネストしたセクションから構成されます。セクションとは、本来の DOM ツリーのいくつかのノードに相当するコンテナのことです。略（アウトラインの中のセクションとは、section 要素に相当するものもあるかもしれませんが、section 要素のことではありません。これらは、ただ単に概念上のセクションでしかありません。）
http://www.html5.jp/tag/elements/headings-and-sections.html#outline
セクショニング・コンテンツ
アウトライン - 一つ以上のセクションから構成される
セクション - セクショニング・コンテンツでもよい
セクション - セクショニング・コンテンツでなくてもよい
http://takahashifumiki.com/others/480/
まぁまぁまともな生活ができる楽園なんだからさー。
アンタのような頑張り屋さんで能力が高い人が
わんさか来ちゃうと、居場所なくなってしまうでしょ。
しーえすえすないと見ればわかるでしょ？
俺らがスイーツ(笑)だって。
これを知らなきゃ始まらない。
当然一度くらい仕様書読んでるよね？
「・・・」
クソプログラマがわけわかんねぇ実装するから
俺たちはこんな苦労してんだ。
あー忙しい忙しい。
うんそうだね。でもあと5年もすれば
そんな知識ほとんど必要なくなるけど
ほかに何ができんの？
「・・・」
見てみろよこのきらきら感。
同じようなレイアウトで違いがわからないんだけど？
「いろいろサイト見て参考にしてるんで・・・」
まぁ0->1を生み出せる人間なんてほとんどいないわけだから
君たちは1を1.1にしてくれればいいよ。
「・・・」
・・・じゃあなんでこの位置にこのボタン置いたの？
「・・・なんとなく」
wwwwww
なんとなくって何だよwww
クリエーターが自分の作ったもの説明できなくてどうすんだよwww
見た目だけパクってんじゃねーよ。
結構絵を描いてきてるんだよね？勉強してるんだよね？
この画像パース狂ってるし光源がわけわからなくて気持ち悪いけど？
「・・・」
アナログできねーやつが
色についてちゃんと勉強したの？
「イキル。なんかクールじゃないですか？？」
色の本は1冊くらい読もうよ。
うんうん重要だね。
「・・・」
多くの人に見てもらいたいんすよ。
うんうん。そうだね。
で、ガイドラインは当然読んでるんだよね？
「・・・」
おぉさすがクリエーター。センスあるね。
ところでさっき言ってたユーザビリティ、
アクセシビリティとか考えているんだよね？
「・・・あぁまぁ一応」
で、どこクリックすればいいの？
「・・・」
半端な知識で設計されても後々困るからやんなくていいよ。
無茶な要求しやがって。こういうわけわかんねぇ
「・・・？」
別に.confには触れなくていいから、
.htaccessくらいは設定できるようになろうよ。
興味ないの？死ぬの？
「イキル。でも興味はありません。」
内容が同じファイルUPしたのに動かない・・・
パーミッションが違うよ。
どういう意味か調べないの？興味ないの？死ぬの？
「イキル。でも興味はありません。」
フォームなんていろいろあるから
適当に選んでUPするだけでだろ。簡単簡単。
え？確認画面がほしい？
「無理です。」
別にアプリケーション作れとは言わないけどさ
単なる問い合わせメールフォームくらいつくれない？
簡単なカスタマイズもできないようじゃ
顧客の要求にこたえられないだろ。
やっぱ今はAjaxだよね。スクロールしてもサイドバーがついてくるんだぜ！！
ライブラリ読み込んでるだけじゃね？
しかもDOMってるだけだよ。
アプリケーション作れなんて言わないから
君らクリエーターならこのナビゲーション
俺ならこうするって思うことないの？
「・・・ライブラリで充分です。」
またバカなクライアントから修正きたよ。
まぁ俺がサービス名間違ってたんだけど。
確認しないの？
ふーん。ちなみにIE6でレイアウト崩れてるけど？
「・・・」
で、なんでその誤字の修正に3時間もかかってんの？
「だって100ファイルもあるんですよ？俺じゃなきゃ1日あっても終わらねっす。」
君らが大好きなDreamweaverで多少正規表現使えなかったっけ？
1分で終わるよ。自分使うツールの機能に興味ないの？
忙しい忙しいって無能なだけでしょ？
「興味ないです。CSSをダイアログで設定する機能くらいしか使わないです。」
これまでのようにやっぱり自分が満足できる
うんうん自分が納得できるものを作るのは大事なことだね。
サイト見てるユーザが全然満足してないんじゃない？オナニーなの？
「・・・でもクライアントはきっと満足してますよ。俺のオナニーすごいし。」
売れるサイトが欲しいんだよ。
なんとか売るのがてめぇらの仕事だろが。
一流プログラマ様が作ってくださった物をまったく理解しようともしないで
いじくってるバックボーンなきスイーツ(笑)なんだからさレベル高い奴はくんな。
こんな程度のスキルで4、500万は稼げちゃって
やっすいキャバでもオークションのやり方教えてとかブログのやり方教えて、
とか言われてお家行ってにゃんにゃんできちゃうわけだから出たくねーよこんな楽園。
しかもこんな能力じゃ楽園でたらどこも行くとこないよ。
努力しないでそこそこの金がもらえて
おしゃれって思われる仕事を用意するのが政治だろって訴えますよマジで。
残らないだろうけどなwww
オワタwww
.
本記事末尾のローカルなkey mappingを実現するコードを改良してプラグインにしました。
↓
Vimperatorでローカルなkey mappingを実現するプラグイン local_mappings.js を書いた。
http://anond.hatelabo.jp/20080826124641
2008-07-14 - やぬすさんとこの日記
http://d.hatena.ne.jp/janus_wel/20080714
→n秒後/前に移動するkey mappingも忘れずに！
Re: autocmd が分からない - hogehoge
http://d.hatena.ne.jp/teramako/20080731/p1
のコードをいじった。
" --- autocmd --- " nicovideo " cでコメント入力、Cでコマンド入力、sでシーク、lでボリューム調整、 " pで停止/再生、mでミュートのon/off、vでコメの表示トグル、zでズーム。 javascript <<EOM liberator.plugins.nicomap = function(){ // no args var list=[ ["p","nicopause"], ["m","nicomute"], ["v","nicomementvisible"], ["z","nicosize"], ["s","nicoseek"], ]; // has args var list2=[ ["c","nicomment"], ["C","nicommand"], ["l","nicovolume"], ["s","nicoseek"], ]; if(buffer.URL.indexOf("http://www.nicovideo.jp/watch") == 0){ for (var j=0; j<list.length; j++){ let i = j; liberator.mappings.addUserMap([1],[list[i][0]],list[i][1], function(){ liberator.execute(list[i][1]); },{ rhs:":"+list[i][1]+"<CR>" } ); } for (var j=0; j<list2.length; j++){ let i = j; liberator.mappings.addUserMap([1],[list2[i][0]],list2[i][1], function(){ liberator.execute('normal :'+list2[i][1]+'<Space>'); },{ rhs:":"+list2[i][1]+"<Space>" } ); } } else { for (var i=0; i<list.length; i++){ liberator.mappings.remove(1,list[i][0]); } for (var i=0; i<list2.length; i++){ liberator.mappings.remove(1,list2[i][0]); } } }; liberator.autocommands.add('LocationChange','.*','js liberator.plugins.nicomap()'); EOM
http://d.hatena.ne.jp/nokturnalmortum/20080802#1217633913
.
現在のマウスカーソル位置でクリックイベント発生するkey mappingを設定できればより快適なんだが・・・。
(「コメントする」ボタンのDOMノードが取得できれば、dispatchEventでいけそうだけど)
" ************* local key mappings **************** javascript <<EOM (function(){ function setlocalmap(obj){ var list = obj.list; var list2 = obj.list2; var exp = obj.exp; if(list.constructor != Array || list2.constructor != Array){ echr("invalid argument: array argument required");return; } if(exp.constructor != RegExp){ echr("invalid argument: regex argument required");return; } if(exp.test(liberator.buffer.URL)){ for (var j=0; j<list.length; j++){ let i = j; liberator.mappings.addUserMap([1],[list[i][0]],list[i][1], function(){ liberator.execute(list[i][1]); },{ rhs:":"+list[i][1]+"<CR>" } ); } for (var j=0; j<list2.length; j++){ let i = j; liberator.mappings.addUserMap([1],[list2[i][0]],list2[i][1], function(){ liberator.execute('normal :'+list2[i][1]+'<Space>'); },{ rhs:":"+list2[i][1]+"<Space>" } ); } } else { for (var i=0; i<list.length; i++){ liberator.mappings.remove(1,list[i][0]); } for (var i=0; i<list2.length; i++){ liberator.mappings.remove(1,list2[i][0]); } } } /** * Add Key Mappings to Specific Web Pages * @param obj : has following properties * list : commands that take no args * list2 : commands that take args * exp : target page's URL (regex) * @see Re: autocmd が分からない - hogehoge * http://d.hatena.ne.jp/teramako/20080731/p1 */ liberator.plugins.addLocalUserMap = function(obj){ liberator.plugins[obj.name + "MapSetter"] = function(){ setlocalmap(obj); } liberator.autocommands.add( 'LocationChange', '.*', 'js liberator.plugins.' + obj.name + 'MapSetter()' ); }; // nicovideo // cでコメント入力、Cでコマンド入力、sでシーク、lでボリューム調整、 // pで停止/再生、mでミュートのon/off、vでコメの表示トグル、zでズーム。 var nicovideo = { name : 'nico', exp : /^http:\/\/www.nicovideo.jp\/watch/, list : [ ["p","nicopause"], ["m","nicomute"], ["v","nicomementvisible"], ["z","nicosize"], ["s","nicoseek"], ], list2 : [ ["c","nicomment"], ["C","nicommand"], ["l","nicovolume"], ["s","nicoseek"], ], }; liberator.plugins.addLocalUserMap(nicovideo); })(); EOM
まあ、どのくらいの数の脆弱性オタがそういう彼女をゲットできるかは別にして、
「オタではまったくないんだが、しかし自分のオタ趣味を肯定的に黙認してくれて、
その上で全く知らない脆弱性の世界とはなんなのか、ちょっとだけ好奇心持ってる」
ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、Webアプリ脆弱性のことを紹介するために
（要は「脱オタクファッションガイド」の正反対版だな。彼女に脆弱性を布教するのではなく
相互のコミュニケーションの入口として）
あくまで「入口」なので、時間的に過大な負担を伴うような図解などは避けたい。
できれば、秋葉原とか筑波とかから突っ込みがはいるような微妙な奴も避けたいのだけれど、つい選んでしまうかもしれない。
あと、いくら脆弱性的に基礎といっても古びを感じすぎるものは避けたい。
プログラム言語オタがCOBOLは外せないと言っても(いましたね)、それはちょっとさすがになあ、と思う。
そういう感じ。
彼女の設定は
セキュリティは専門でもなんでもないが、クロスサイトなんちゃらとか、SQLなんとかくらいは聞いたことがある。
サブカル度も低いが、頭はけっこう良い
という条件で。
まあ、なんで一番がSQLインジェクションじゃないんだよとも思うけれど、たいていのWebアプリに必ずあるという普遍性(日本語変か?)とか、文字コードネタのバリエーションとか、DOMが絡んでわくわくするとか、Same Origin Polic何じゃそりゃという点では外せないんだよなあ。長さも3文字だし。
ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。
この情報過多な脆弱性について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報を彼女に
伝えられるかということは、オタ側の「真のコミュニケーション能力」の試験としてはいいタスクだろうと思う。
アレって典型的な「オタクが考える一般人に受け入れられそうな脆弱性（そうオタクが思い込んでいるだけ。実際は全然受け入れられない）」そのもの
という意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには
一番よさそうな素材なんじゃないのかな。
「Webアプリの専門家からいえば、この二つはアプリネタじゃないと思うんだけど、率直に言ってどう？」って。
侵入先のファイルが見えてしまうというハッカー的なものへの憧憬と、これによる逮捕者がいるという法的な考証へのこだわりを
彼女に紹介するという意味ではいいなと思うのと、それに加えていかにもマニアックな
「よく眼にするけどあまり実害の思いつかない」/etc/passwd
「滅多に見られないけど、見つけたらゾクゾクする」/etc/shadow
の2ファイルをはじめてとして、オタ好きのするファイルを世界に公開(流出?うわ、日本語間違いが怖い)しているのが、紹介してみたい理由。
たぶん秋のDK収穫祭を見た彼女は「これCSRFだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。
そして、われらがアイドルはまちちゃんの紹介のおかげで、この脆弱性が日本で大人気になったこと、
「やっぱりWebアプリの脆弱性は個人情報DBなんかがあるサイトのものだよね」という話になったときに、そこで選ぶのは「SSIインジェクション」
でもいいのだけれど、そこでこっちを選んだのは、この脆弱性がふつーのホームページなどでも本当によく見つかるくせに、意外に問題視されていないレアっぽさが好きだから。
断腸の思いでJavaMailのAPIがTo欄やFrom欄に改行チェックいれているのに、なぜかSubject欄だけチェックがされてなくて脆弱性の原因になるかもって中途半端さが、どうしても俺の心をつかんでしまうのは、
その「チェックする」ということへの躊躇がいかにもオタ的だなあと思えてしまうから。
ほかのメールAPIでもチェックが不十分なものはあるし、そもそもsendmail呼び出すときはチェックはアプリ側でやるしかないとは思うけれど、一方でこれが
Microsoftだったら意外にきっちりセキュアに仕上げてしまうだろうとも思う。
なのに、安全なAPIを使わずに(知らずに?)脆弱性を混入してしまうというあたり、どうしても
「自分の過去から知っている書き方でないと書けないプログラマ」としては、たとえ脆弱性混入した奴がそういうキャラでなかったとしても、
親近感を禁じ得ない。脆弱性の高危険度と合わせて、そんなことを彼女に話してみたい。
今の若年層でディレクトリリスティングによる個人情報漏洩事件をリアルタイムで見聞きしている人はそんなにいないと思うのだけれど、だから紹介してみたい。
SQLインジェクションよりも前の段階で、個人情報の漏洩規模とかはこの脆弱性で頂点に達していたとも言えて、
こういう危険の高さが経産省あたりの個人情報保護ガイドラインにのっていたり、というのは、
別に俺自身がなんらそこに貢献してなくとも、なんとなく脆弱性好きとしては不思議に誇らしいし、
いわゆるインジェクション系でしか脆弱性を知らない彼女には見せてあげたいなと思う。
UNIXシェルの「セミコロン」あるいは「バッククォート」をオタとして教えたい、というお節介焼きから見せる、ということではなくて。
「ホワイトリストで対策すると安全なんだけど敢えてエスケープを究めたいマニア」的な感覚がオタには共通してあるのかなということを感じていて、
だからこそ佐名木版『セキュアWebプログラミングTips集』は20ページ以上もかけてOSコマンドインジェクション対策の説明しているのは、エスケープ手法以外ではあり得なかったとも思う。
「侵入先のコンピュータでコードが動いてこそなんぼ」というクラッカーの感覚が今日さらに強まっているとするなら、その「クラッカーの気分」の
源はOSコマンドインジェクションにあったんじゃないか、という、そんな理屈はかけらも口にせずに、
単純に楽しんでもらえるかどうかを見てみたい。
これは地雷だよなあ。昔だったら筑波方面、今だったら秋葉原方面から火のような「hiddenは危険脳」ブクマがつくか否か、そこのスリルを味わってみたいなあ。
こういう昔のIPA風味の解説をこういうかたちでブログ化して、それが非オタに受け入れられるか
突っ込みを誘発するか、というのを見てみたい。
9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にSQLインジェクションを選んだ。
XSSから始まってSQLインジェクションで終わるのもそれなりに収まりはいいだろうし、カカクコム以降のWebアプリ脆弱性時代の原動力と
なった脆弱性でもあるし、紹介する価値はあるのだろうけど、もっと他にいい脆弱性パターンがありそうな気もする。
というわけで、俺のこういう意図にそって、もっといい10パターン目はこんなのどうよ、というのがあったら
教えてください。
「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。
Inspired by アニオタが非オタの彼女にアニメ世界を軽く紹介するための10本
動作未確認。すんげー冗談半分。
// Hatena Monge Star user script // 2008-07-07 // by masda. (http://anond.hatelabo.jp/20080707043247) // ==UserScript== // @name Hatena Monge Star // @namespace http://anond.hatelabo.jp/20080707043247 // @description Hatena Monge Star // @include http://b.hatena.ne.jp/entry/* // @version 0.3.1 // ==/UserScript== // deriving from [http://d.hatena.ne.jp/Hamachiya2/20080707/HatenaBlackStar2] ver Firefox // [http://f.hatena.ne.jp/hatenacinnamon/20070109001332] // Thx! and CUTE! location.href = 'javascript:(' + function() { (function (w) { if (typeof(w.Ten) == 'undefined') { return; } HatenaBookmarkMongeStar = new Ten.Class({ initialize: function(li, entryTitle) { var comment = ''; var tags = ''; var commentSpans = Ten.DOM.getElementsByTagAndClassName('span', 'comment', li); if (commentSpans.length > 0) { comment = Ten.DOM.scrapeText(commentSpans[0]); } var tagsSpans = Ten.DOM.getElementsByTagAndClassName('span', 'user-tag', li); if (tagsSpans.length > 0) { $A(tagsSpans[0].getElementsByTagName('a')).each(function(a) { tags += '[' + Ten.DOM.scrapeText(a)+ ']'; }); } var title = tags + comment; if (title.length == 0) { var name = Ten.DOM.scrapeText(li.getElementsByTagName('a')[1]); title = name + 'のブックマーク'; } // this.uri = 'http://b.hatena.ne.jp/keyword/' + li.getElementsByTagName('a')[1].href; var u = li.getElementsByTagName('a')[1].href; if (u.indexOf('#') == -1) { this.uri = u + '#_HatenaMongeStar'; } else { this.uri = u + '_HatenaMongeStar'; } this.title = title + ' - ' + entryTitle; this.comment_container = Hatena.Star.EntryLoader.createCommentContainer(); var target = commentSpans[0] || li; target.appendChild(this.comment_container); this.star_container = Hatena.Star.EntryLoader.createStarContainer(); this.star_container.className = 'hatena-star-star-container MongeStarContainer'; target.appendChild(this.star_container); } }); var tryCount = 0; var tryMax = 300; function waitForHatenaStar() { // if (Hatena.Star.EntryLoader.loaded) { // Hatena.Star.EntryLoader.loaded = false; var s = document.getElementsByClassName('hatena-star-add-button'); if (s.length) { Hatena.Star.EntryLoader.loaded = false; Hatena.Star.EntryLoader.loadEntries = function() { var entries = []; var title = Ten.DOM.scrapeText(Ten.DOM.getElementsByTagAndClassName('span', 'title', document.body)[0]); var ul = document.getElementById('bookmarked_user'); if (ul) { $A(ul.getElementsByTagName('li')).each(function(li) { if (li.className != 'more') { entries.push(new HatenaBookmarkMongeStar(li, title)); } }); } return entries; } new Hatena.Star.EntryLoader(); } else { if (++tryCount > tryMax) { setTimeout(waitForHatenaStar, 400); } } } setTimeout(waitForHatenaStar, 500); })(window); }.toString() + ')()'; GM_addStyle(<><![CDATA[ .MongeStarContainer { margin-left: 4px; } .MongeStarContainer .hatena-star-add-button { background-color: #fc6 ! important; } .MongeStarContainer a { text-decoration: none ! important; color: #f80 ! important; font-size: 10px; position: relative; } .MongeStarContainer a:before { content: '毛'; font-size:small; } .MongeStarContainer a .hatena-star-star { filter: alpha(opacity=00); -moz-opacity:0.00; opacity:0.00; position: absolute; top: 0; left: 0; } .MongeStarContainer .hatena-star-inner-count { color: #f90 ! important; } ]]></>);
動いたらいいな-
> 正直PHPよりJavaScriptの方が使いやすいだろ
使いやすいのはDOMが使えるから。DOMが良いのは、それがブラウザの構成要素でもあって、ブラウザを制御できるから。
結局HTMLにしてHTTPを通さなきゃいけないサーバサイドでは威力半減、コスト増大で旨味が少ない。
PHPとかRoRみたいなフレームワークを使うのとかjavaとか、そんなのと大差がなくなる。
唯一の旨味はクライアントサイドと同じjavascriptとDOMである、ということだけ。
しかし、それは一見であって、逆に紛らわしいとか、結局データベースとかC/S間でやりとりされるデータを理解してないと、とか、PHPで良くいわれる敷居が低くて初心者が、というのと同じ構図になるとか、結局大差ないんじゃないか？
……あ、javascriptが叩かれるようになってPHPが目立たなくなって死ぬ、ってことか。
JavaScriptはサイトの見え方を変えることができる。ニコニコ動画からほとんど広告を消すこともできる。オペラだったらこんな感じ。
// ==UserScript== // @name test // @include http://www.nicovideo.jp/watch/* // @author test // @version 0.0.1 // ==/UserScript== (function(){ //DOM？の取得 var elemAuthorsComment = document.getElementById("WATCHHEADER").getElementsByTagName("p")[2]; var tableTagList = document.getElementsByTagName("table"); var elemTag = tableTagList[7]; var elemCommentAndMyList = tableTagList[8] //削除 myDeleteById("PAGEHEADER"); myDeleteById("WATCHHEADER"); myDeleteById("WATCHFOOTER"); myDeleteById("PAGEFOOTER"); //作者コメントやタグなどの追加 document.body.appendChild(elemAuthorsComment); document.body.appendChild(elemTag); document.body.appendChild(elemCommentAndMyList); //関数 function myDeleteElement(elem){ elem.parentNode.removeChild(elem); } function myDeleteById(id){ var elem = document.getElementById(id); myDeleteElement(elem); } })();
まぁ、一箇所残ってるけど。こんな風に簡単に広告を消すことができる。GmailについてもFirefoxのGreasemonkeyに広告を消す拡張がある。JavaScriptを使えばこんな風に広告を消すことができるのだけど、これは企業側にとっては脅威だ。ネットサービスを提供する企業は主に広告収入によって、収入を得ている。しかしJavaScriptによってそれがなくなってしまうと広告収入が減る。現段階ではまだJavScriptを使うのは敷居が高いし、そもそもGreasemonkeyのようなブラウザ向けのユーザースクリプトがあること自体知られてないだろう。だから今はまだいい。しかし今後ブラウザ向けのユーザースクリプトが認知され、だれかが書いたJavaScriptを簡単に使えるようになったらどうなるのだろうか？IEを主に使うような普通の人でも特定のサイトで広告がうざいからそれを消すためのユーザースクリプトを探すようになるかもしれない。そうなったらJavaScriptはニコニコ動画を含めたウェブサービス企業を殺すのだろうか？
なのでJavaSciptの勉強がてら、メタブックマークを見えなくするユーザースクリプトを作った。DOMがよくわからないので変なところがあるかも。スコープやノードリストなんかもよくわかってないので、無駄なところもあるかも。
以下ソース。
Opera用 // ==UserScript== // @name Metabu Eraser // @include http://b.hatena.ne.jp/entrylist* // @author Hatena Anonymous User MASUDA // @version 0.0.1 // ==/UserScript== (function(){ document.onload = main; function main(){ var entryList = filterByTagAndClass("div", "entry"); checkAndErase(entryList); } function filterByTagAndClass(tag, name){ var list = document.getElementsByTagName(tag); var newList = []; for(var i = 0; i < list.length; i++){ if(list[i].className == name){ newList.push(list[i]); } } return newList; } function checkAndErase(nodeList){ for(var i=0; i < nodeList.length; i++){ var elem = nodeList[i].getElementsByTagName("a")[0]; if(elem.href.substring(0,50) == "http://b.hatena.ne.jp/entry/http://b.hatena.ne.jp/"){ nodeList[i].parentNode.removeChild(nodeList[i]); } } } })();
Firefox(Greasemonkey) // ==UserScript== // @name Metabu Eraser // @include http://b.hatena.ne.jp/entrylist* // @description version:0.0.1 // ==/UserScript== main(); function main(){ var entryList = filterByTagAndClass("div", "entry"); checkAndErase(entryList); } function filterByTagAndClass(tag, name){ var list = document.getElementsByTagName(tag); var newList = []; for(var i = 0; i < list.length; i++){ if(list[i].className == name){ newList.push(list[i]); } } return newList; } function checkAndErase(nodeList){ for(var i=0; i < nodeList.length; i++){ var elem = nodeList[i].getElementsByTagName("a")[0]; if(elem.href.substring(0,50) == "http://b.hatena.ne.jp/entry/http://b.hatena.ne.jp/"){ nodeList[i].parentNode.removeChild(nodeList[i]); } } }
なのでJavaSciptの勉強がてら、ニコニコ動画関連のブックマークを見えなくするユーザースクリプトを作った。DOMがよくわからないので変なところがあるかも。スコープやノードリストなんかもよくわかってないので、無駄なところもあるかも。
以下ソース。
// ==UserScript== // @name NicoNico Eraser // @include http://b.hatena.ne.jp/entrylist* // @author Hatena Anonymous User MASUDA // @version 0.0.1 // ==/UserScript== (function(){ document.onload = main; function main(){ var entryList = filterByTagAndClass("div", "entry"); checkAndErase(entryList); } function filterByTagAndClass(tag, name){ var list = document.getElementsByTagName(tag); var newList = []; for(var i = 0; i < list.length; i++){ if(list[i].className == name){ newList.push(list[i]); } } return newList; } function checkAndErase(nodeList){ for(var i=0; i < nodeList.length; i++){ var elem = nodeList[i].getElementsByTagName("a")[0]; if(elem.href.substring(0,30) == "http://www.nicovideo.jp/watch/"){ nodeList[i].parentNode.removeChild(nodeList[i]); } } } })();
// ==UserScript== // @name NicoNico Eraser // @include http://b.hatena.ne.jp/entrylist* // @description version:0.0.1 // ==/UserScript== main(); function main(){ var entryList = filterByTagAndClass("div", "entry"); checkAndErase(entryList); } function filterByTagAndClass(tag, name){ var list = document.getElementsByTagName(tag); var newList = []; for(var i = 0; i < list.length; i++){ if(list[i].className == name){ newList.push(list[i]); } } return newList; } function checkAndErase(nodeList){ for(var i=0; i < nodeList.length; i++){ var elem = nodeList[i].getElementsByTagName("a")[0]; if(elem.href.substring(0,30) == "http://www.nicovideo.jp/watch/"){ nodeList[i].parentNode.removeChild(nodeList[i]); } } }
まぁ、これだと初音ミクやアイドルマスター以外の動画も見えなくなるんだけどね。
つーかJavaScriptだとPythonみたいなfor文使えないの？
AJAXだと動的に要素を作ったり消したりしていくことになるけれど、そのときに、どういう要素を作るのかをjavascriptにハードコーディングしたくないんだ。具体的に言えばDOMで要素を作っては加えるとか、innerHTMLにHTMLを突っ込むとか、そういう事をあまりしたくない。スクリプトにはなるべくコントロールを担当してほしいのだ。
そこで、もともとのHTMLに雛形、つまりテンプレートを（たとえばid属性をつけて）書いておくと、初回にそれを読んで記憶し（そして一旦消すかもしれない）、以降はそれを元に要素を作ることが出来るようなのがほしい。もちろん、要素の属性値やテキストは、必要なところが指定できる感じで。
って書きながら、どう作ればよいか分かった気がした。指定IDのinnerHTML読んで、それをテンプレートにして、たとえば%…%を置き換えるとかすればよいのか。難しく考え過ぎていた。後はループとか挿入位置とかの指定か。
ってか、そういうのはもうあったりしないのか？
はてブの人気エントリに「今回のmixiのリニューアルについて - 専門家に聞く」ってのがあるんだけど、そのページのにある寺田さんの発言がステキすぎて目が離せません。
文章構造、悪くないと思うけどね…。
とりたてて良くもないけど、そこそこいい感じじゃないすか？具体的にどう悲惨なんだろね。
今までの化石みたいなTableレイアウトのソースに比べれば、死ぬほどマトモでしょ。
個人的にはHTML要素のid・class指定にLowerCamelCaseを使うのは好きじゃないとか、onmouseover・onmouseoutみたいなDOMイベントをHTMLソース上に書かなくてもいいじゃんとかはあるけど。
但し、せっかくCSSにしたんだからHTMLソースを短くする努力をした方が良かった気がする。
PVが半端ないから、HTMLソースの量でも結構大きく響いてくるはず。
本当にそうですね…！やっぱり時代はPHPですよね（笑
今回のリニューアルは「テンプレートのリニューアル」であり、「システムも含めた全面的なリニューアル」ないんでそりゃ変わらないでしょ。
数千台のサーバで運営されており、実績のある現在のPerlベースのシステムを、PHPベースに変更することで何のメリットがあるんですかね？
「PHPだと、Perlと違い実行時にプロセスが立ち上がらないので高速です」とか言いそうな予感がプンプンしますが…。
「Javaベースにして、Oracleにしましょう」といった話であれば、はいはいSIer乙って気分になるんだけど、PHPが出てくるところがなんとも微笑ましいです。
どう考えても創業以来からの身内で開発をしているとしか思えません。技術や知識が古く、独自の思考をもった温室エンジニアたちが、権限ばかり与えられて新しく入ったデザイナーやコーダーと上手に連携できていない様子が目に浮かぶようです。
んー、1000万IDあるサイトを、運用する技術とかだけでも結構なもんだと思うけどね。
サイトのスケールアウトの難しさとか… 知ってるのかな？
どこまでいっても「なぜ上場したのか・・・」という問題に尽きます。
なんかあんまり触れられてないけど、今回のmixiのデザインリニューアルで一番強く思ったのは「mixiが持っていたキャッチーさが薄くなってしまった」ということ。
同時期に開始したGreeと、mixiの二つのSNSの内、mixiだけが圧倒的な勢いでユーザ数をのばしていった理由。
他のウェブサービスでは見ない原色系の色遣い。パッと見て親しみやすい感じ。オタクっぽくない感じ。
そこがmixiのアイデンティティだと思っていたので、普通になっちゃったことにビックリした。
初期のデザインコンセプトが「人と人をつなげる楽しいウェブサイト」だったとすると、
今回のリニューアルのデザインコンセプトは「ソーシャルプラットフォーム」みたいな感じで独自色を薄くした感じなのかねぇ…。
あと、非常に分かりづらいメニュー構成（操作メニューが2つあって、その意味づけがはっきりしていない）は、変わらないのが相変わらず駄目だと思った。
上二つはガジェット自体の構造について。要はXMLを書けばよいらしい。
で3つ目が本題で、内容javascriptでRSSやJSONでデータを取得して表示する方法。表示はこれを参考にすればよいと思う。後は、読んだ後、リストからはずす処理をどういったUIでやるかだよね。Javaやったんならオブジェクトの扱いは大体わかると思うから、後はDOMを理解すればOKだと思う。
がんばれ。
<html><head><title>Hello JavaScript World!</title><style type="text/css"> <!-- .select { margin-left: 30px; padding: 0 2px; width: 6em; border: dotted 1px; } .select p { margin: 2px; } --> </style></head><body><script type="text/javascript"> <!-- // step 1 : output text document.write("Hello world!"); // step 2 : output html document.write("<br/><b>Hello javascript world!</b>"); // step 3 : manipulate DOM var p1 = document.createElement("p"); p1.appendChild(document.createTextNode("Hello DOM world!")); document.body.appendChild(p1); // step 3 : interactive, using function, event handler function solid() { this.style.borderStyle="solid"; } var p2 = document.createElement("p"); p2.appendChild(document.createTextNode("Hello interactive world!")); document.body.appendChild(p2); p2.addEventListener("click", solid, false); // not solid() // step 4 : using object, prototype, closure function P(str) { this.str = str; } P.prototype.regist = function(parent){ this.elem = document.createElement("p"); this.elem.appendChild(document.createTextNode(this.str)); parent.appendChild(this.elem); var self = this; this.elem.addEventListener("click", function(){self.act()}, false); // otherwise // this.elem.helloworld = this; // this.elem.addEventListener("click", function(){this.helloworld.act()}, false); // bad way // this.elem.addEventListener("click", this.act, false); // this.elem.addEventListener("click", function(){this.act()}, false); }; P.prototype.act = function(){}; var p3 = new P("Hello prototype world!"); p3.act = function(){ if (this.elem.style.borderStyle == ""){ this.elem.style.borderStyle = "solid"; } else { this.elem.style.borderStyle = ""; } }; p3.regist(document.body); // step 5 : inheritance function SELECT(parent, str) { this.str = str; this.regist(parent); } SELECT.prototype = new P(); SELECT.prototype.act = function(){ p4.elem.style.borderStyle = this.str; p4.div.style.display = "none"; } var p4 = new P("Hello world!"); p4.div = document.createElement("div"); p4.div.className = "select"; p4.div.style.display = "none"; p4.select = [ new SELECT(p4.div, "none"), new SELECT(p4.div, "dotted"), new SELECT(p4.div, "solid") ]; p4.act = function(){ p4.div.style.display = "block"; }; p4.regist(document.body); document.body.appendChild(p4.div); //--> </script></body></html>