「W3C」を含む日記 RSS

はてなキーワード: W3Cとは

2019-07-07

anond:20190706190044

真面目に回答したら良いのかな?

おそらくは日本ネット投票がまともに解禁されるようになるには、インターネットで使われる情報技術標準規格を選定するW3Cが定めたSelf-Sovereign Identity(SSI)というポリシーに則ったDecentralized Identifiers(DID/DIDs)が日本でまともに運用されてからだと思われる。

Self-Sovereign Identity(SSI)

Self-Sovereign Identityとは訳すと自己主権アイデンティティで、これは技術の規格というよりも技術を開発・運用するためのポリシーなんだ。

詳しくすると論文が書けてしまうので要約するけどSSIでは以下の10項目が提言されている。

  1. 存在 - 個人独立した存在でなければならない
  2. 制御 - 個人自身アイデンティティ管理しなければならない
  3. 接続 - 個人自身情報接続できなければならない
  4. 透明 - システムアルゴリズムは透明性がなければならない
  5. 持続 - アイデンティティは持続性がなければならない
  6. 可搬 - アイデンティティに関するサービス情報は可搬性がなければならない
  7. 互換 - アイデンティティ可能な限り広い範囲で利用できるべきである
  8. 同意 - 個人自身アイデンティティ使用権限を持てるべき
  9. 請求 - アイデンティティ請求は最小であるべきである
  10. 保護 - 個人権利保護する必要がある

これらの10項目はまだ上手い日本語訳が無くて俺の意訳が含まれていることに注意してもらいたい。

このSSIが何を言いたいかといえば個人情報の公開を第三者ではなく個人自身管理制御できるべきということなんだ。

Decentralized Identifiers(DID/DIDs)

SSIを定めたW3Cはそのポリシーに則って個人情報管理するためのシステム仕様を定めた。

それがDecentralized Identifiers(DID/DIDs)で、これも訳すと中央集権識別ということになる。

何のことだが小難しい漢字語になってしまったので、より現代人へ理解やす平易な言葉へ置き換えると分散デジタルID表現したほうが理解やすいと思う。

現在個人情報(アイデンティティ)というもの中央官庁巨大企業によって中央集権的に管理されてしまっている。

これでは個人情報本来の持ち主である個人自由に利用することが難しいし、そして自身個人情報がどのように扱われているのかというのを把握するのが非常に難しくなってしまっているよね。

更には中央官庁企業としても日本国法で言うところの個人情報保護法の兼ね合いで個人情報管理に関して大きなコストを支払わざる得なくなっており、もし仮に個人情報流出した際に賠償責任などのリスクを負う可能性があるのが現状だ。

そこでW3CはSSIポリシーに則ったDIDという仕様を定め、これまで問題視されてきた個人情報管理問題点を解消しようと近年動き出している。

DDIブロックチェーンにより分散的に個人情報管理しつつ改竄を防ぐ仕様が取られている。

更に特徴的なのは個人個人意思によって個人情報請求に対して公開したい範囲個人情報のみを開示できる仕様になっているんだ。

これはどういうことかと言えば、現在日本ではタバコ酒類を購入することに関して成人であることが条件になっていて、成人認証には運転免許証マイナンバーカードなど公的機関が発行する資格証明証が用いられている。

この問題点タバコ酒類を購入する際に必要個人情報は「成人である」という証明だけのはずなのに、例えば運転免許証であれば氏名や現住所、許諾されている運転車両範囲など余計な個人情報記載されてしまっていることが問題なんだよね。

しかし、DIDを用いるとタバコ酒類購入者が開示する情報は「成人である」ということができるようになる。氏名も生年月日も現住所も許諾されている運転車両範囲も開示する必要がないんだ。

これは中央官庁企業に取っても非常に安心仕様だ。何故ならもし誤って個人情報流出させてしまっても流出するのは誰のものだか判然としない「成人である」という情報のみから

他にも携帯電話通信契約などの場合でも本人確認や法的に契約できる者なのかを確認しなければ契約の締結はできないけれど、DIDを用いると開示する情報は「本人である」というものだけになる。

契約業務をする目の前のスタッフアナタがどこの誰だか全くわからないけれど、アナタが本人であることを知ることができる。こういうことを可能とするのがDIDというシステムなんだ。

ポイントカードクレジットカードDIDと紐付けば何枚も持ち歩く必要なんてなくなる。

そして選挙は本人であることや、投票できる年齢であるかどうかを確認したり、投票秘密を守らなければならない。更に言えば投票の集計もしなければならないよね。

DID中央集権に寄ることなアナタが本人であり投票できる者であることをアナタの許諾を得て承認し、投票秘密を守り、更にはコンピュータから超高速に投票集計もしてくれるんだ。

SSIの透明ポリシーによって投票集計のプログラミングコードアルゴリズムオープンに公開され公正に選挙が行われる。

これが最も先進的な個人情報管理のために提言されている新しい技術だ。

SSIとDID日本でまともに運用開始されるとネット選挙未来はそう遠くなくなるよ。

このエントリでSSIとDIDに注目して貰えたら俺としては何も言うことないぜ!以上!

2019-06-12

増田でわかる分散SNS

1章 アカウント凍結

有子「あっキレイなお花!」

共太「写真を撮ってTwitterシェアしようぜ!」

有子「いい考えね!じゃあさっそく・・・あれ?」

共太「ん?どうしたんだ?」

有子「あっ私のTwitterアカウントが凍結されてる!」

共太「なっなんだってー!」

-----

共太「最近SNSアカウントが巻き込まれ凍結されるって話をよく聞くけどまさか有子のアカウントがなぁ・・・

有子「私なにも悪いことしてないよ!お花や猫の写真シェアしたりしてただけだもん!」

分美「あら?どうしたの?」

共太「あっ分美お姉さん!ちょうど良いところに」

有子「分美お姉さん・・・何も悪いことしてないのに私のTwitterアカウントが凍結されちゃって・・・

分美「あら大変!でも仕方ないわよねぇTwitterシステムの上では巻き込まれ凍結はどうしても防げないわ」

共太・有子「えっそうなの!?

分美「Twitter問題のありそうなアカウント独自アルゴリズム自動で凍結しちゃうのよ。コンピュータプログラムで判定しているからどうしとても間違えてしまうことがあるわ」

有子「プログラム相手じゃ間違えてますよってお話することも難しいよね」

共太「Twitter勝手に始めたことを押し付けてくるなんてヒドイじゃないか!」

有子「私の友達だって悪いことしてないのに何度も凍結されちゃって悲しい思いをしてたんだよ!」

共太「お姉さんなにか良い方法はないの!?

分美「ふふふ・・・あるわ!分散SNSよ!」

共太・有子「分散SNS?」

2章 分散SNSって何?

共太「お姉さん、分散SNSってなに?」

有子「前に少しだけ話題になった気がするけど私よく知らない」

分美「分散SNSはねTwitterFacebookみたいなSNSが動くサーバシステム個人個人自由に設置して、設置されたみんなのサーバ同士が繋がり合ってコミュニティネットワークを作ろうって試みなの」

分美「分散SNS構成するサーバ個人の持ち物だから、持ち主の個人独自ルールを定めることができるのよ」

分美「TwitterFacebookサービスを利用しているとTwitterFacebookが定めたルールに利用しているユーザは従わなきゃならないけど、分散SNSサーバ毎にルールを定められるので凍結される可能性を低くできるわ」

有子「あれ?じゃあもしかして私が分散SNSサーバを設置したら・・・

分美「良い点に気が付いたわね!そう、有子ちゃん分散SNSサーバを設置したら有子ちゃんルールよ!」

共太「すっげぇ!じゃあボクの分散SNSサーバを利用したかったら100円な!」

分美「ふふふ、共太クンの分散SNSサーバからそのルールはもちろん定めて良いわ・・・でも分散SNSを利用するユーザにはルールを選ぶ権利があるのよ?」

有子「なるほどね!もし私の分散SNSサーバの利用が無料だったら共太クンの分散SNSサーバを使おうって思うユーザなんか居なくなるじゃない!」

分美「そうねユーザが困っちゃうようなルールを定めればユーザは利用しないだろうし、更に法律違反するルールを定めて実行しちゃうお巡りさんに捕まってしまリスクも当然あるのよ」

共太「自由ルールを決められても好き勝手にしちゃ駄目なんだ・・・

3章 分散SNSは過疎らない

共太「でもさぁ思ったんだけど新しいSNSってユーザ数が少ないよな」

有子「SNSってやっぱりいっぱいユーザが居たほうが楽しいしね」

分美「実はね、分散SNSっていわゆる『過疎』になる可能性が非常に低いのよ。設置したら既に誰かが居るわ」

共太「えっ!?SNSを設置して直ぐは誰も居ないに決まってるじゃないか!」

有子「そうよね?居たとしてもSNSを設置した管理人さんだけでしょ?」

分美「それが分散SNSメリットの1つなのよ。分散SNSは点在する分散SNSサーバ同士が相互接続することで成り立っているの」

分美「だから例えば分散SNSサーバαが既に設置されている状況であれば、分散SNSサーバβが新たに設置されたとき分散SNSサーバβから既に存在する分散SNSサーバαを利用するユーザが見えてコミュニケーションが取れるのよ」

有子「えぇ!?それってすごいことじゃない!!」

共太「自分分散SNSサーバを利用してくれるユーザ積極的に探さなくても良いわけか」

分美「わざと他のユーザを集めないで管理人がたった1人だけで利用している『お一人様』と呼ばれている分散SNSサーバだってあるわよ。他にも家族だけとか学校友達だけの分散SNSサーバがあったり、お絵かき趣味の人のためや音楽趣味の人のための分散SNSサーバもあるわね」

有子「なるほど学校のお友達なら見知った仲だし凍結なんてほとんどありえないもんね!」

共太「通ってるスポーツクラブ分散SNSサーバ設置したら面白そうだなぁ!」

分美「独自ルールを定められるってことは利用するユーザを好きに選ぶこともできるってわけ!そしてなおかつさっきも言ったとおり他の分散SNSサーバユーザともコミュニケーションが取れるから便利」

分美「そんな便利な分散SNSコミュニティネットワーク形成しているのが『ActivityPubプロトコル』よ!」

4章 ActivityPubプロトコル

共太「アクティティパブ・・・?」

有子「プロトコル・・・?」

分美「早い話が分散SNS同士の会話がちゃんとできるようにする方式規格のことなんだけど、実際に重要なのは利用する分散SNSサーバがActivityPubプロトコル対応しているかどうかってこと」

分美「実は分散SNSってActivityPubプロトコルが登場する以前にも様々なプロトコルが考案運用されてきたの」

分美「例を挙げればOStatusプロトコル、DFRNプロトコル、DiasporaプロトコルZotプロトコルあたりが有名ね」

分美「でも問題プロトコルが違えば相互コミュニケーションが取れないことなの」

有子「あれ?分散SNSサーバは他の分散SNSサーバ相互コミュニケーションが取れるんじゃなかったっけ?」

分美「そう、それを実現したのがインターネットで使われる技術の標準仕様を定める団体であるW3C』が制定したActivityPubプロトコルってわけ!」

共太「そうかActivityPubプロトコル以前は分散SNSでも相互接続できない分散SNSがあったんだな」

分美「W3Cが標準仕様であるActivityPubプロトコルを定めてくれたお陰で、分散SNSほとんどは積極的にActivityPubプロトコル採用するようになり、ほとんどの分散SNSサーバほとんどの分散SNSサーバ相互接続コミュニケーションが完成したわ」

5章 もっと知ろう分散SNS

共太「へぇ!ActivityPubプロトコルって凄いんだなぁ」

有子「お姉さん!分散SNSサーバってどんなものがあるの?」

分美「うん!じゃあ先ず最初に語らなきゃいけないのは『GNU Social』ね!Twitterに触発されたマイクロブログSNSよ」

分美「GNU Socialは分散SNS最初期に登場した分散SNS2007年まで遡るわ」

有子「今から12年も前!?そんな前からあるの!?

分美「12年前はidenti.caっていう名前だったの。GNU Socialという名前に落ち着いたのは2013年よ」

共太「それでも6年も前か。その時から分散SNSを考えていたなんて凄いなぁ」

分美「分散SNSのヒントになっているのは2002年に登場したP2Pファイル交換システムの『Winny』なのよ日本製ね」

有子「2002年17年前!どんどん遡るね!」

分美「WinnyのあとにBitTorrentが登場したり色々日本でも問題になり善悪評価が定まらないけれど革新的システムだったのは確かで、それが現代分散SNSという実装に応用されているわ」

分美「GNU Socialの特徴はなんと言ってもその安定性の高さね。最初期に登場したこともあり機能性に乏しさは感じるしアップデートは驚くほど少ないわ。でも後に登場した分散SNSへ強い影響を与えたの」

共太「アップデートが少なくて済むほど安定してるってことか?」

分美「それもあるし、GNU Socialはプラグインによる機能追加に対応しているのよ。新機能が欲しいなら自分で作れという文化なのGNU Socialは」

分美「次に紹介するのは日本で最も人気のある分散SNSMastodon』ね」

有子「あっ聞いたことある!」

分美「Twitterアカウントの凍結騒ぎで一時期Twitterでも話題にのぼったわね。MastodonGNU Socialに触発されたマイクロブログSNSよ」

分美「GNU Socialを参考としたためGNU Socialと互換性がありつつも、よりもモダンな外観や機能を備え、コミュニティが活発でアップデートも非常に多いのが特徴だわ」

共太「それだけ聞くとMastodonの方が良いように感じるなぁ」

分美「日本国内にMastodonサーバは膨大に存在するし分散SNS選びに迷ったらMastodonって考えるのも悪くはないわ。情報も非常に多いしね」

分美「ただMastodon欠点としてはGNU Socialに比べるとより高性能なサーバマシン必要になることね。とある有名なC++プログラマが『富豪的プログラミングだ』と揶揄したのはMastodonコミュニティでは有名な話よ」

有子「自分Mastodonサーバを設置するときサーバマシンの用意に困るわけね」

分美「まぁとは言っても今の普及価格ノートパソコンくらいで十分に動くわ。利用状況によるけどサーバレンタルするとしても月額2,000円以下かしら」

分美「そんな重いMastodonに触発され動作が軽いことを念頭に置かれ開発されたマイクロブログ分散SNS『Pleroma』も検討に値するわね。Mastodonと一部機能互換性を持っているの。Mastodonクライアントアプリが使えたりするのよ」

有子「GNU Socialを参考にしたMastodonMastodonを参考にしたPleromaか面白いなぁ」

共太「お姉さん!なんかもっとこうドーンッとスゴイやつってないの?」

分美「あるわよ?例えば『Hubzilla』なんかは高機能すぎるくらい高機能よ。SNS機能に加えて、ユーザ単位の公開範囲限定チャットアドレス帳カレンダーオンラインストレージ、簡易Webページ作成RSSフィードリーダーFacebook連携Twitter連携、ActivityPub連携etc...」

共太「スゲェ!なんでもアリかHubzilla!」

分美「もともと『ハブ』になることがコンセプトらしいわね。でも今挙げた機能はHubzillaの最大の特徴じゃないの」

有子「えっこの時点で高機能なのに?」

分美「HubzillaはZotプロトコルによるGridネットワークを特徴としていて、これはサーバ認証ユーザ認証が別個に管理されているのよ」

分美「端的に言うとHubzillaサーバαとHubzillaサーバβで1つのユーザアカウント運用できるのよ。例えば普段使ってるHubzillaサーバαが何らかの障害でダウンしても、ユーザアカウントそのままでHubzillaサーバβで利用できちゃうのよ。普通サーバが変わるとユーザアカウントも変えなくちゃいけないわよね。Hubzillaはユーザアカウントを維持できるの」

共太「えっHubzilla凄すぎない?」

有子「まさに分散SNSだね。サーバ1つ無くなっても他のサーバが使えちゃう

分美「非常に先進的な試みをHubzillaはやってるんたけど、その豊富すぎる機能や細かな設定項目、更には複雑な外観で素人お断り感がスゴイのよ・・・

有子「もっとこう気楽で高機能分散SNSはないの?」

分美「あるわよ?」

共太「ちょっと思ったけど何でもあるんだねw」

分美「筆者の増田もこのエントリ書くため改めて調べてみて驚いてるらしいわ。それでもっと気楽な高機能分散SNSには『Misskey』があるわ。なんと国産よ」

分美「投稿テキストへ太字などが設定できたり、昨今のチャットサービスなどで定番化しつつあるいいね!に変わる様々な反応を送れるリアクション機能ユーザ指定して会話できるグループトーク、様々な情報を表示するウィジェット、更にはリバーシゲームが楽しめたりするわ。他にも機能いっぱい」

有子「エンターテイメントって感じ!結構好きかも!Hubzillaは敷居が高すぎる・・・

共太「エンターテイメントと言えばマイクロブログSNS以外には分散SNSってないの?」

分美「あるわよ。Hubzillaを見たときSNS部分はFacebookっぽいなと感じたと思うのだけれど、よりFacebookっぽい分散SNSに『Friendica』があるわ」

分美「FriendicaはFacebookクローンと言って良いほどFacebook機能酷似していて分散SNSFacebook機能を求めているのであれば一番手っ取り早いかもね」

共太「あるとは思ってたけどやっぱりFacebookっぽい分散SNSもあるのか」

有子「えっじゃあもしかしてInstagramっぽいのも・・・

分美「あるわよwInstagramっぽい分散SNSは『PixelFed』ね。Instagramと同様に投稿する写真エフェクトフィルタがかけられるわ」

有子「あるんだw」

共太「流石にYoutube・・・

分美「あるわよwYoutubeっぽい分散SNSは『PeerTube』というの。PeerTubeの凄さはActivityPubプロトコルへの対応だけじゃなく動画配信自体分散機能を持つこと」

共太「あるんだw」

https://peertube.fr/videos/watch/217eefeb-883d-45be-b7fc-a788ad8507d3

分美「この動画は実際にPeerTubeへ投稿されている動画なのだけれど、複数人が同時に視聴するとPeerTubeはYoutubeにない動画配信挙動をするの」

分美「それは視聴者αに続いて視聴者βが動画の視聴を始めると、視聴者βへはPeerTubeサーバから動画配信されるだけでなく視聴者αから動画配信されるのよ。これはWebTorrentという技術を使って実現しているわ」

分美「理論上の話になるけれど、1GBの動画Youtubeが2人へ配信した場合は当然ながらYoutubeサーバは合計2GB配信することになるけれど、PeerTubeサーバ場合は合計1.5GBで済んでしまうのよ。残り0.5GBは他の視聴者からまかなう

有子「これは本当に凄いじゃない!お姉さん当然100人が同時視聴するとPeerTubeサーバ送信量はYoutubeサーバに比べてもっと下がるんでしょ!?

分美「もちろん理論値だし様々な状況によってPeerTubeサーバ送信量は変わるけど間違いなくYoutubeサーバ100人配信するよりは送信量がかなり少なくなるわ」

分美「ちなみに引用しているPeerTubeサーバはわざとフランスのPeerTubeサーバを選んでいるわ。私1人だと何度も動画が途中で止まったけれど増田に貼った時点でどうなるか楽しみね」

共太「PeerTubeスゲェな!もっと知られていても良さそうなのに」

分美「個人動画配信って自宅サーバでやらない限りはレンタルサーバとかだとかなりお金掛かるのよ。PeerTubeだと送信料が抑えられると言っても積み重なるとかなりの額になるしね」

分美「そして例えばJ:COMとか一部のインターネットプロバイダはWebTorrentなどのP2P通信規制をかけているところもあるわ。そのようなプロバイダ契約しているとPeerTubeの旨味は活かせないわね」

有子「PeerTubeもActivityPubプロトコルリプライしたりできるんてしょ?」

分美「できるわ」

https://peertube.cpy.re/videos/watch/da2b08d4-a242-4170-b32a-4ec8cbdca701

分美「この動画はPeerTubeとMastodonのやりとりのデモ動画よ。Mastodon上でPeerTube動画を視聴してリプライしてるわね。そのリプライはPeerTubeへ反映されているの」

有子「すごい!まったく違うWebサービスなのにやりとり出来ちゃってる!」

共太「さっきのPixelFedもやりとりできるんだろ?いいね!とか。これがActivityPubプロトコル・・・!!」

分美「ActivityPubプロトコルは今後ともどんどん様々なWebサービスに広がっていくわ。現在開発中だけれど電子掲示板Redditに触発されActivityPubプロトコルを組み込んだ電子掲示板『Prismo』は良い例ね。Prismoが正式に稼働するとMastodonから電子掲示板雑談へ参加できるようになるわ」

分美「そして別にActivityPubプロトコル対応するため新しくWebサービスを始める必要もないのよ。例えば過去日本国内で栄華を極めたmixiあたりがActivityPubプロトコルサポートしたら一気にmixiから観測できるアクティユーザが数十万人増えるわ。起死回生の一手として検討に値するわね。はてなハイクもそうよ」

分美「ユーザが居ないこと、ユーザを集めることが問題になるのならば常にアクティユーザが居ることへ期待できるActivityPubプロトコル採用するのはアリなのよ。 このエントリーをはてなブックマークに追加ツイートシェア

2019-05-14

anond:20190514114143

プロ出版関係者印刷屋が業務で使う道具をブラウザと同列に語られてもなあ・・・

W3C勧告と違って、アドビが決めてる仕様なのにバージョンごとに挙動変わるのはどう考えてもアドビが悪いんじゃね?

ともかく、旧バージョン作成したファイルを最新バージョンで出力しても旧バージョンと全く同じ出力になるならグダグダ言う奴は激減すると思うよ。

2019-03-12

anond:20190223223730

HTML仕様って今でもW3C勧告してるっけ?

WHATWGケンカしたままうやむやなことになってない?

2019-02-06

SIMカード見てて思うんだけど

なんでこういうのが必要なの?なんでこういう形なの?

なんていうか

もっとスマートにできるんじゃないの?

例えば、WWWW3C管理してるみたいな感じで

携帯電話とか、あるいはIoT的なものもそういう団体管理して

それを書き換えればいいんじゃないの?

2018-09-21

anond:20180921225430

はてなにはプログラマWeb系の人多いんだから毎日w3cのvalidatorにお世話になってる人も多いやろなぁ

2018-07-03

anond:20180703163232

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="ja">

<head>
	<meta http-equiv="content-type" content="text/html; charset=Shift_JIS">
	<title>


  
  

2018-05-14

それを「見やすい」というのは残念ながら君含めてごく少数(たぶん5人くらい)

吉本コーディング

http://tsudoi.org/guide/detail/7.html

 

大前提として改行あけるよりもインデントの方が視覚的に分かりやすい、ソースを書いた本人だからそう思うだけ、親馬鹿効果

・インデントを前提とした設計がされているエディタをまるで考慮してない

・インデントを無くす代わりに余計なコメントを書いてソースを汚している

・みんなhtmlコーディングの話だと理解した上で言っている、自分が賢いと勘違いしすぎ、整形前のコードは万人に読みやすい支持のあるルール(W3C違反しない範囲)で記述するのは人として当たり前

自分けが分かりやすいと思うやり方にこだわるのは11年目からやめよう、製作必要なのは最適化自分が死んでも問題ない環境づくりの両立であって独りよがりの美しさは誰も求めてない

・インデントが多いと見づらいから勧めていたはずなのに、今はインデントが少ないから使え、という謎の野獣先輩理論、少ないからこそインデント問題ない

 

たぶん彼はある面では良い考えだがインデント排除することが見やすさの向上につながっていない、

もし少しでも記述を減らして早く書きたいのだったらコメントさえ使ってないはずだ。

ある程度の支持も得られたかもしれない。

特に開始タグの前にコメント必要ない、class名を見れば済む話なので必要なら閉じタグに書くべき。

コメント使用こそが薄々内心では分かりづらいと思った彼なりの妥協なのは明白。

 

あとどうしても深い階層になってしま場合スケールに合わせてファイルを分割したり共通かすればいいわけ

今どきhtmlだけしか使わないウェブサイトなんて存在せんだろう…。

 

それからアナティクスを下に書くな!

ちゃんGoogle推奨する位置に入れろ!

気に入らないなら無理に使わんでいい!

 

都合の悪いことは見なかったことにすんな

2016-12-23

俺の主観で書いたインターネット文化流行歴史(2008〜2016)

2006-2007

http://anond.hatelabo.jp/20161223021717

2008年

・この頃にやる夫が出てくる

チャー研ブームNHKに取り上げられる

・「ニコニコ大会議2008」が行われる。

現在行われている超会議とは違い、Apple新製品発表会のような形式だった。

ぼっさん消える

MikuMikuDance公開

秋葉原通り魔事件

iPhone 3Gソフトバンクモバイルにより日本で発売

流行:「あなたとは違うんです」「ローゼン麻生」「ゆっくりしていってね!!!」「毎日変態新聞」「いいえ、ケフィアです。」「●●はわしが育てた」「ビッグウェーブ」

https://www.youtube.com/watch?v=ayPUF-AnoxQ

2009年

・「なんJ虐殺」発生。野球ch住民によりなんJ侵略され、今に至る。

のりピー逮捕

AYA STYLE

長島☆自演乙☆雄一郎K-1初参戦

流行:「お口の中がたかゆきでいっぱいだよお…」「裸で何が悪い」「白いクスリ」「※ただしイケメンに限る」「私女だけど彼氏の財布がマジックテープ式だった 死にたい。。」

2010年

1ch.tv消滅

ぼっさん生存確認

sengoku38事件

韓国から2chへのDoS攻撃が頻発。不幸にもデータセンター米国政府関係サーバが同居しており、CIAキレる

改正著作権法施行違法インターネット配信による音楽映像違法と知りながらダウンロード(複製)することが、私的使用目的でも権利侵害に。

流行:「エルシャダイ」「イカ娘」「本田△」「〜なう」「んでんでんでwww」

http://www.nicovideo.jp/watch/sm12664125

https://www.youtube.com/watch?v=pj2WS_vZJoY

https://www.youtube.com/watch?v=tKhbJNSX3UI

2011年

東日本大震災

バードカフェおせち祭り

トンボ鉛筆震災直後の新卒採用やらかし問題

47氏無罪判決が確定

・「バルス」でTwitter落ちる

地震ネット電気が寸断されたせいか2chニュー速から東北の県名が名前に入ってた人が消える

ジョブズ死去

Twitter日本語ハッシュタグ対応

照英コラ画像

・「ぽぽぽぽ〜ん」「まどマギ」「セシウムさん」「乗らなきゃこのビッグウェーブに」「スーパーで水を発見して喜んだら大五郎だった」「ひなた!膣内(なか)で出すぞ!」

https://www.youtube.com/watch?v=kB1Z-OAxD4g

2012年

アフィブログ軒並み炎上

2chが一部のアフィブログ転載禁止措置

這いよれ!ニャル子さん流行

・この頃から淫夢用語流行りだす

open2ch誕生

ヘイトスピーチ問題化

・完全勝利した淫夢くんUC

遠隔操作事件

虚構新聞記事「橋下市長、市内の小中学生ツイッター義務化」に釣られた人たちが原因で騒動

流行語:「ステマ」「アドセンスクリックお願いします」「嫌儲」「ホモォ」

https://www.youtube.com/watch?v=B66CU71Bf7A

2013年

47氏死去

2ちゃんねる個人情報流出事件」が発生

・この頃から2chの衰退がささやかれるようになる

Twitter犯罪自慢(バカッター)が社会問題化

ニコ動歌い手未成年女子と淫行で逮捕。「やばいと思ったが、性欲を抑えきれなかった」

・元NSA職員エドワード・スノーデンNSA個人情報収集手口を告発

Windows Live メッセンジャーサービス終了

LINE登録者数が1億人を突破

・「今でしょ!」「倍返しだ!」「駆逐してやる」「にゃんぱすー

2014年

2ch転載禁止を明文化する。

・Jimがひろゆきを追い出す

・「2ちゃんねるお家騒動」発生。字幕.in運営する矢野さとるによりopen2ch2chを追い出されたひろゆきにより2ch.scが作られ、以降2ちゃんねるは三つ巴の戦いになる。

・野々村議員の記者会見

HTML5W3Cにより勧告

・「がんばれ♥がんばれ♥」

2015年

海外掲示板reddit日本人利用者が増え始める

例の紐

東京オリンピックエンブレムパクリ疑惑に関連し、「ネット民」という単語TVニュース番組で取り上げられる

・オイルマッチ炎上配信。翌日消火器などの防災用品が飛ぶように売れる

2016年

株式会社はてな上場

はてな匿名ダイアリーが発端で「保育園落ちた日本死ね」が話題

PPAP流行

清原和博さん、オクッスリバファローズ入団

パナマ文書

今上天皇お気持ち表明

・「スズメバチには気をつけよう!」「ウサミンたいそう」流行

ポケモンGOリリース

2016-11-02

HTML5

W3Cは、初期のHTMLからXHTMLまでを仕様勧告したのですが、その作業の遅さなどの諸問題で、この団体に見切りをつけて枝分かれしたのがWHATWGです。

今のHTMLWHATWGが主導しています

WHATWGは、変化していくものとして扱うため、「HTML」と呼称

W3Cは、固定された規格として扱うため、「HTML5」とバージョン化。

WHATWGが作ったHTMLを、W3Cが切りの良いタイミングで複写して、独自の考えを足したのが、「HTML5規格」です。

2015-10-04

http://anond.hatelabo.jp/20151004105028

とりあえずこれと

http://www2u.biglobe.ne.jp/~oz-07ams/2002/ecma262r3/fulltoc.html

DOM-HTML

http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html

それとw3cDOM-Coreを読んでおけば一通りわかるようになる

ecmascriptは最新が5だった気がするがブラウザ実装されていない分がかなりあるのでまた後でいい

2015-06-04

Javascriptが糞ならもっといい言語作ればいいんじゃないの?

なんで文句言いながら使い続けるのか疑問なんだけど

HTMLの不満を解消したのがHTML5ってのなんでしょ?

おなじようにJavascript2もW3Cかいうところで作ればいいじゃん。

2015-05-04

Aaron Swartzかいう人

The Internet's Own Boyという映画を観た。その感想を簡単に書く

https://www.youtube.com/watch?v=vXr-2hwTk58

映画を観るまでAaronについて僕は何もしらなかった。僕はそれなりにインターネットが好きだ。こうしてブログを書いてるのも、僕の考えや感じた事に共感してくれる人がいないかをインターネットという拡声器を使って確かめたいからだ。

Aaron Swartzは14才でW3C委員になった。W3Cミーティングの際に、他のメンバーから「いつ集まれる?」と訊かれ、Aaronは「最近14才になったばかりで、ママの許しがないと集まりに行けない」と言った。そんな14才がW3Cで大人と混じって議論をし、その当時Creative Commonsを創ろうとしていたLawrence Lessigに出会いCreative Commonsにも協力した。

とんでもない人だと思った、彼はその後スタンフォード大を中退してY Combinatorプログラムに参加し、自分プロジェクトRedditと合流させた。しかしRedditが成長し、買収された後で彼は解雇されてしまう。その後はシリコンバレーから離れて政治活動に傾倒していく。彼は当時、インターネット自由を奪う危険があるSOPAという法案を食い止めようとした。結果的SOPAは消滅し、インターネット自由は守られた。

彼はその後もインターネット自由を脅かすものと戦った。時にそれは少々強引なやり方でもあった。そんな彼のやり方は、法に触れたと見なされ有罪判決を受けてしまう。インターネット自由と戦った彼は疲れ、怯えて、絶望し、自殺してしまう。

僕が今こうして使っているインターネット自由保証されているものでは無い。この瞬間にも勇敢なハクティビストが僕らのインターネット自由を守っているのかもしれない。彼らに感謝したい、最高の敬意と感謝を送りたい。

Aaronが守ったインターネットはまだ息を続け、毎日僕らに感動をくれる。

ありがとう、Aaron

2014-10-29

HTML5は、終わった。

HTML5がやっと勧告とか良く分からない言葉になったが、ちゃんと現状を認識しておこう。

そもそも、HTML5目的は、新しいHTMLなんかじゃない。

正確には、新しいHTMLなるための道標だったのだ。(過去形

君たちは、window.alertという関数を知っているだろうか。

この関数HTML5定義された最新の関数だ。

え?と思うかもしれない。でも、これこそがHTML5役割だった。

HTMLは、昔、ドキュメントだった。

ドキュメントにalertなんて在るはるがないのだ。

そうやってHTMLは分断されていた。

HTMLというドキュメント操作するAPIとしてDOM。そして、それ以外のAPI黙殺

XHTML1.xでも、それは繰り返された。

XHTML2.0が失敗したのは当然ともいえる。分断されたままアプリケーション拡張しようとしたのだ。

現状を省みずに、ただ夢を追った。

しかし、カウンター存在した。

HTMLの現状を認識することこそ大事であると。

既にHTMLドキュメントではなくアプリケーションであると。

アプリケーションとして見たHTMLには、windowというオブジェクト存在している。

それは”標準仕様”という名前を持たないだけの標準だと。

彼らは現状を定義した。HTMLを再定義した。

次に進むのに必要なのは新しい夢などではなく、現状の再認識だ。

認識さえすれば必要なモノは勝手についてくる。

そう、それがW3C採用され、君たちの知っているHTML5になった。

HTML5の次のバージョンは何ですか?」

HTMLからバージョンを消すことです。バージョニングなんて考えは古い。HTMLは常に更新されるものです。」

彼らはそう語っていた。

HTML5は新しいモノだと勘違いされたが、そうではない。

それは1つの側面でしかない。

大切なのは定義だ。だから勧告なんて待つ必要も無い。

window.alertがクロスブラウザで使える。それがHTML5だった。

君たちは、気付いてるだろうか。

以前よりもクロスブラウザで悩まされることが減ったことに。

最近はまたカオスになってるけどな!)

それこそがHTML5意味だった。

だが、それでも道を踏み外した。

また夢を盛り込もうとした。アプリケーションならアプリケーションなら。

そして、HTML5は、HTMLの再定義という意味を奪われて

新しいアプリケーションプラットフォームという肥料でまるまると太った豚になった。

豚は、そのままでは動かなかった。

HTML5の次のバージョンは、何ですか?」

HTML5.1です。」

HTML5は、終わった。

2014-05-20

Firefox検索エンジンカジュアル管理したい

ここ数年、ブラウザはずっと Google Chrome を使ってきたのだが、先日とある事情で久しぶりに Firefox を使う機会があった。

Firefox はとにかくゴテゴテしていて重い・起動に時間がかかる・アドオンを入れるたびに再起動、というイメージがあってあまり印象が良くなかったのだが、先日最新版を使ってみたらサクサクでびっくりした。それに比べると最近Chrome は、ウィンドウが立ち上がるのは確かに相変わらず早いのだが各種拡張機能ロードするのに時間がかかり、しばらくの間まともにブラウジングが出来ないという体たらくだったので、そろそろメインブラウザFirefox に切り替えようかと検討し始めている。

タブのデザインChrome っぽくなって違和感なく使える。Tab Mix Plus を入れてカスタマイズすれば、新しいサイトを開く際にいちいち「新しいタブ」を開かなくて良いのでラクチンだ。ブラウザRSSリーダーデフォルトサポートしているのも良い。

ところが。いつも使っているあの辞書サイトやらPHPマニュアルやら機械翻訳やらが使えないのが困った! 「Firefox "検索エンジン編集" "任意URL"」でググってもロクな結果出てこなかったし。FirefoxChrome みたいにカジュアル検索エンジン管理したいのだがどうすればいいんだ。

日英/英日辞書についてはアドオンページで「英辞郎 on the WEB」をインストールして解決したのだが、現在 Chrome に設定してあるその他の検索エンジンについても Firefox でも使えるようになりたい。とりあえず、いま Chrome にセットしてある検索エンジン一覧を挙げてみる。これが全部 Firefox に移行できたら助かるのだが。

Google Drive
https://drive.google.com/#search/%s
Google 翻訳
http://translate.google.co.jp/#auto/auto/%s
Google 翻訳 (英→日)
http://translate.google.co.jp/#en/ja/%s
Google 翻訳 (日→英)
http://translate.google.co.jp/#ja/en/%s
Twitter (すべて)
https://twitter.com/search?f=realtime&q=%s
PHP マニュアル
http://jp.php.net/manual-lookup.php?lang=ja&pattern=%s
Redmine (URL はサンプル)
http://example.jp/redmine/issues/%s
W3C Validator
http://validator.w3.org/check?ss=1&uri=%s
Another HTML Lint Gateway
http://www.htmllint.net/cgi-bin/html-lint/htmllint.cgi?ViewSource=on&URL=%s
ダミー画像 (猫) ※検索ボックスに "200/300" のような文字列入力する
http://placekitten.com/%s
whois
http://whois.domaintools.com/%s

Firefox は、Chrome のタブデザインをパクったりするより前に、Chrome 並にカジュアル検索エンジン自作管理できるような仕組みを早く作って欲しい。

2013-06-18

http://anond.hatelabo.jp/20130618085832

ブラウザでいえば、いちおうW3Cはあるけど別にW3Cブラウザを推進してるわけでも何でもない。

今は時代はフラットデザインに流れているけど、別に誰かがフラットデザイン委員会みたいなものを作ってるわけじゃない。

 

べつに海外のほうがいいということが言いたいわけじゃないけど、ここは注意して欲しいけど

アメリカだと協調はするけど団結はしない

日本だと団結はするけど協調はしない。

 

今の日本必要なのは団結ではなく協調性では?

2013-06-03

SEOが次にどうなっていくか

SEOが次にどうなっていくのかを考えてみた。

社内でSEOについて話しても

あれはスパムだそれはスパムだこれもスパム

リンク作れリンク作れ安くて上がるリンク作れ

順位上がればペナルティきてもいいか

けどペナルティきたら何でそんなスパムやったんだ責任取れよ。

この繰り返しなので話が進まない。

ここ1年の間で大きく話題になったペンギンアップデート

ビックデータを扱う時に行うデータクレンジングを強化してスキーム化したものだと思ってる。

こんなのをいちいち手作業を基本としてやってたらコスト無限大なので

ペンギンかい名前で一括処理。

パンダアップデートはほんとどうても良くてこんなの対処できないウェブマスターとか

中規模以上のシステム担当者チェンジしてもらったほうが世のためになる。

このレベルウェブマスター適当なこと吹き込んで状況を悪化させる

ホワイトハットSEO業者も同列。

で、次にどうなっていくかを考えると

リアルタイムレコメンドの性質が強化されそう。パーソナライズとは関係ない。

いまの検索結果はキーワードに対するレコメンド

これにセマンティック強化の流れがかみ合うと

リアルタイムキーワード意味合いを解釈して

それに対する結果もリアルタイムレコメンドされると思う。

パーソナライズ広告で使われまくってるのを見ていて

それが検索結果にも同じく入ってくるのかと考えると

そんな顧客満足度を下げるような事はしない。

ここから具体的にSEOとして何をして行くのか。

まずGoogle定義した仕様の通りにサイトを作ること。W3CじゃなくてGoogle

Google解釈できるサイトになっている事が基本、

これは仕様を読んで実装できるスキルがある人ならできる。

次にデータクレンジングトレンドリアルタイムに把握すること。

ようするにペンギンにやられないように先手を打つこと。

これにはバックリンク解析が必要になってくる。

10とか20とかじゃ意味がなく、統計で使うので母数に最低1000は欲しい。

この母数となるのは怪しげなSEOをやっているサイト

母数として利用で出来るサイト抽出するのにさら10倍以上のサイト数が必要

これを実現できるのはデータマイニングできるスキルがある人。

技術に理解のない会社データマイニングエクセルでやりたがるけど、無謀。

次にリアルタイムレコメンドに表示されるように仕向けるために

何が必要になってくるのか、ここが分からない。

どんなにサイトホワイトハットで言う所のクリーンな状態にしたって

検索結果の上位には表示されない。

キーワード解釈され方の傾向を掴むのは統計じゃ出来ないのは必然

SEOパイが決まっている中での席取りゲーム

どの状態であればGoogleから好意的に解釈されるかを意思決定するAIの出番なんだろうか?

検索結果は過去の1面を切り抜いたものなので、

先読みして何かする部類のものはないと思ってる。

過去投影される自身をどのように操作するか。

リアルタイムインデックス更新されるようになって

ペンギンパンダ適用されてから

地球教みたいなホワイトハット集団が出始めたり

ツールベンダーが多数出てきたり。

SEOはすごく面白くなった。

2013-04-05

JavaScript Lover

いっせーの!

Webにのって さあ出かけよう
ブラウザとのランデブー
ユーザー大事 実装が大事
JS、マジ大好き

ユーザーの痛み それ言語のせい?
UIの動き UXのつもり
今までのJSポジションを
越えた未来は どうなるの?

ねぇどうせWebKitでしよ ダメ?
ダメ! ECMA標準だけ
油断も隙もない
APIとのボーダー越えたい

そうもっと!

大胆で ちょっと強引?
俺ワールド全開
優しいJSも いじわるなJSひとりじめ

型つけてみて やっぱやめて
ウラハラ alt-js
Java以上C++未満の
JS、マジ最高

V8けが きらめいて
遠い背中も 追いかけたよ

これから最適化
フローグラフの分まで伝えたい
ぎゅってしてPNaClコンパイル ダメ?
ダメ! 不埒です

CSS3に甘えたい
GPUに触れたい
どこまで? APIボーダー教えて

おっとっと!

手強い IEの仇
ムキになったら
古いシステムFlashの将来も
譲れない

実装して やっぱやめて
一方通行プロセス
W3C信じて
プラグイン書いて
No more E4X

動的なの? 静的なの? 型推論好き?
好き!
好きだからわず答えて
Ion Monkey 越えよう

おっとっと!

大胆で ちょっと強引?
prototypeを知ったら
JSでの設計コーディングも変わるの?
答えてよ!

ときめき 走り出す
わくわくコーディング
Self以上 Scheme未満の
JS、超愛してる!!

「Girlish Lover」 PV

2012-08-21

http://anond.hatelabo.jp/20120821105940

お前は何がやりたいんだ?まずそれから話そうか?

やりたいことによって使用するソフトが違うのだよ。わかるかい

DTPをやりたいのにpremiereを紹介してもダメだろう。

えっとwebデザインDTPか...

DTPは、デファクトスタンダードイラストレーターから最終的にそれを生業とするならイラレから逃げられないぞ。

Webデザインは、紙とペンだな。あとW3CHTML5勉強して生産性が悪いかもしれないがテキストエディタでよいんじゃないか

2011-01-12

http://anond.hatelabo.jp/20110112023237

より正確に言えば、li要素がネストしたときCSSでlist-style-typeプロパティに何が与えられているのか

IEchromeで同じ表示だったので、W3Cが標準を定義をしているのかもしれない

2010-05-01

Appleは善良な企業

http://jp.techcrunch.com/archives/20100430joe-hewitt-web-development/

アンチMSは聞くけど、アンチAppleは聞かない

MSは囲い込み戦略を、その決して洗練されていないソフトウェア品質から叩かれることがあるけど、

確かに、独自技術特許で固めることはしていなかったように思う。

現に、Ajaxテクノロジーは、基礎をIEの独自拡張から始め、firefoxなど他のブラウザの実装に発展してきた。

Adobe Flashも同じくユーザーに何一つ強制はしていない。

そして事実上今日の一般的なミドルウェアとして使われている。

そのFlashプラットホームを、Appleは否定しているものの、

では、代替となりえる技術Appleが開発して W3C標準化を求めるかというと

そんなことはしていない(HTML5Appleが推進していたのかどうかは知らないけど)

ただ、ネットをもっとオープンで誰もが自由に使えるものにしようとしている気がした。

Mecabがこれから iPhoneプラットホームで使えなくなる(広義)という話を聞いて

珍しくApple非難が一般デベロッパ・一般ユーザーからも出てきたな、と思ったところではたと気づいた。

iPod移行、Apple には Google よりもクリーンイメージ自分の中にあったのだ、と。

では Appleは善良な企業か、Google のように「悪いことはしない」という企業哲学に基づいた経営なのかというと

それは分からない。

Apple は善良な企業なんだろうか

2010-02-19

新世ウェブスタンダード

第壱話 HTML5、襲来

第弐話 見知らぬ、ブラウザ

第参話 鳴らない、Audio

第四話 WAI-ARIA、逃げ出した後

第伍話 Safari、心の向こうに

第六話 決戦、第3のブラウザOpera

第七話 WWWの造りしもの

第八話 Chrome、来日

第九話 瞬間、Canvas、重ねて

第拾話 セクションダイバー

第拾壱話 静止したACID3の中で

第拾弐話 先行実装の価値

第拾参話 バグ、混入

第拾四話 Firefox、魂の座

第拾伍話 バグとハック

第拾六話 死に至る非標準、そして

第拾七話 四人目のECMAScriptエンジン

第拾八話 DTDの選択を

第拾九話 ベンダーの戰い

第弐拾話 XMLのかたち、SGMLのかたち

第弐拾壱話 WHATWG誕生

第弐拾弐話 せめて、マイクロフォーマットらしく

第弐拾参話 IE

第弐拾四話 最後のCSS

第弐拾伍話 終わるXHTML2

第弐拾六話 世界の中心でセマンティックを叫んだけもの

劇場版 W3C新生

劇場版 WebKit/世界標準を、君に

2010-01-13

http://okajima.air-nifty.com/b/2010/01/post-abc6.html

少し遅れた感があるけど、解いてみた。

出力がテキストでないけど・・・。

仕事の合間を使ってやったものの、昼前に始めたのが5時頃にようやくできる程度。

これを25分とは尋常じゃないな、大口叩くだけあってよっぽど優秀なんだろう。

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"&gt;

<html&gt;

<head&gt;
<meta http-equiv="Content-Type" content="text/html; charset=shift_jis"&gt;
<meta http-equiv="Content-Language" content="ja"&gt;
<meta http-equiv="Content-Script-Type" content="text/javascript"&gt;
<meta http-equiv="Content-Style-Type" content="text/css"&gt;
<style type="text/css"&gt;
<!--

pre {
  font-family: monospace;
}

--&gt;
</style&gt;
<script type="text/javascript"&gt;
<!--

window.onload = function() {

  var q = new Map();
  q.load("maptest.txt");
  q.search();

  var answer = document.getElementsByTagName("pre").item(0);
  var answerText = "\r\n";
  for(var ix = 0; ix < q.route.length; ix++) {
    answerText += q.route[ix].join("") + "\r\n";
  }
  answer.firstChild.data = answerText;

  alert("終了しました。");
};

/** マップオブジェクト
 */
function Map() {
  this.ymap = [];
  this.route = [];
}

//マップの読み込み
Map.prototype.load = function(filePath) {
 //ファイルシステム
  var fileSystem = new ActiveXObject("Scripting.FileSystemObject");

 //ファイル読み込み
  var file = fileSystem.OpenTextFile(filePath);
  while(!file.AtEndOfLine) {
    var fileBuffer = file.ReadLine();
    this.ymap.push(fileBuffer.split(""));
  }
  file.Close();

  fileSystem = null;
};

//マップの探索
Map.prototype.search = function() {

  var that = this;

 //マップコピー
  var ymap = this.ymap.concat();
  for(var y = 0; y < ymap.length; y++) {
    ymap[y] = ymap[y].concat();
    for(var x = 0; x < ymap[y].length; x++) {
      if(ymap[y][x] == "S")
        var start = new MapNode(y, x);
      if(ymap[y][x] == "G")
        var goal = new MapNode(y, x);
    }
  }

  var openList = [];
  var closeList = [];

  start.costf = start.distance(goal);
  openList.push(start);

 //経路探索
  while(openList.length &gt; 0) {
    var node = openList.shift();
   //探索終了
    if(goal.equal(node)) {
      createRoute(node);
      break;
    }
    closeList.push(node);

   //隣接ノードの作成
    var tonari = [];
    if( ymap[node.positionY][node.positionX - 1] == " "
     || ymap[node.positionY][node.positionX - 1] == "G" )
      tonari.push(new MapNode(node.positionY, node.positionX - 1, node));
    if( ymap[node.positionY - 1][node.positionX] == " "
     || ymap[node.positionY - 1][node.positionX] == "G" )
      tonari.push(new MapNode(node.positionY - 1, node.positionX, node));
    if( ymap[node.positionY][node.positionX + 1] == " "
     || ymap[node.positionY][node.positionX + 1] == "G" )
      tonari.push(new MapNode(node.positionY, node.positionX + 1, node));
    if( ymap[node.positionY + 1][node.positionX] == " "
     || ymap[node.positionY + 1][node.positionX] == "G" )
      tonari.push(new MapNode(node.positionY + 1, node.positionX, node));

   //隣接ノード検索
    for(var tx = 0; tx < tonari.length; tx++) {
      var openIn = false;
      var closeIn = false;
      tonari[tx].cost = node.cost + 1;
      var costf = tonari[tx].cost + tonari[tx].distance(goal);
      tonari[tx].costf = costf;

     //オープンリストから検索し入れ替える。
      for(var ox = 0; ox < openList.length; ox++) {
        if(tonari[tx].equal(openList[ox])) {
          openIn = true;
          if(costf < openList[ox].costf) {
            openList.splice(ox, 1);
            push(openList, tonari[tx]);
          }
          break;
        }
      }
     //クローズリストから検索し、オープンリストへ移す。
      for(var cx = 0; cx < closeList.length; cx++) {
        if(tonari[tx].equal(closeList[cx])) {
          closeIn = true;
          if(costf < closeList[cx].costf) {
            closeList.splice(cx, 1);
            push(openList, tonari[tx]);
          }
          break;
        }
      }
     //どちらにもない場合、オープンリストへ追加する。
      if(!openIn &amp;amp;&amp;amp; !closeIn)
        push(openList, tonari[tx]);
    }
  }

 //適切な位置に追加する。
  function push(array, item) {
    for(var ix = 0; ix < array.length; ix++) {
      if(item.costf < array[ix].costf) {
        array.splice(ix, 0, item);
        return;
      }
    }
    array.push(item);
  }

 //ルートマップの作成
  function createRoute(lastNode) {
    var node = lastNode.parent;
    while(node.parent) {
      ymap[node.positionY][node.positionX] = "$";
      node = node.parent;
    }
    that.route = ymap;
  }
};

/** マップノード
 */
function MapNode(y, x, parentNode) {
  this.positionY = y;
  this.positionX = x;
  this.parent = parentNode;
  this.cost = 0;
  this.costf = 0;
}

//同一ノードかチェックする。
MapNode.prototype.equal = function(targetNode) {
  if( this.positionY == targetNode.positionY
   &amp;amp;&amp;amp; this.positionX == targetNode.positionX )
    return true;
  return false;
};

//直線距離を求める。
MapNode.prototype.distance = function(targetNode) {
  sabunY = this.positionY - targetNode.positionY;
  sabunX = this.positionX - targetNode.positionX;
  return sabunY ^ 2 + sabunX ^ 2;
};

// --&gt;
</script&gt;
<title&gt;経路探索:A*</title&gt;
</head&gt;
<body&gt;

<pre&gt;&amp;nbsp;</pre&gt;

</body&gt;
</html&gt;

2009-11-28

HTMLを体系的に理解するための7仕様

はじめに

最近マークアップエンジニア志望の若者と話す機会が多いのだけれど、そこで気づかされるのは、彼らの中に過去HTML(特に90年代以前の仕様)を読んだことのあるという人が、驚くほど少ないことだ。

例えば「マーク・アンドリーセンをどう思う?」と聞くと、「アンドリーセンって誰ですか?」という答えが返ってくる。「ヨスケの独自要素で何が一番好き?」と聞くと、「見たことがありません」と言われてしまう。「ではきみは、昔のHTMLを見たことがあるの?」と聞くと、たいていが「とほほでやっていたものくらいなら……」という答えしか返ってこない。

今の若い人の間では、HTMLを体系的にとらえようという人は少ないようだ。見るのは専ら近年の話題仕様ばかりで、歴史を辿ってみたり、系譜をひもといて標準化団体ごと理解しようとする人はほとんどいない。

これは、ちょっと由々しき問題だと思わされた。HTMLは、もう長いこと(90年代の早い時期から)インターネット王者としてあらゆるWeb関連技術の上に君臨してきた。だから、Webを作ることを仕事にしたいなら、何をするにせよ避けて通ることはできない。

HTMLは、表・画像・フォーム・音楽デザインフレーム動画など、さまざまな分野においてその時代々々に達成された最新の成果を持ち寄るようにして作られてきたところがある。だから、HTMLを読まずして現代のインターネットは語れないと言ってもいいくらいだ。

もし何かクリエイティブなことをしたいのなら、HTMLを読むことは欠かせない。また、単に読むだけではなく、それを包括的・体系的にとらえることも必要だ。なぜなら、HTML包括的・体系的にとらえることによって、現代のインターネットそのものを、包括的・体系的にとらえられるようになるからだ。そしてそうなれば、Webを作ることの道理や筋道が理解でき、何かクリエイティブなことをする上で、大きな助けとなるからである。

そこでここでは、昔のHTMLをほとんど見たことがないという人や、あるいはHTMLそのものもあまり見ないという人のために、これを見ればHTMLを体系的に理解でき、現代インターネットの成り立ちや実相までをも包括的にとらえることができるようになる、7本の仕様を紹介する。

ここで紹介するHTMLは、いずれも後のWeb業界に決定的な影響を与えたものばかりだ。これらが、HTMLという標準のありようや方向性を決定づけた。この7本を見れば、HTMLというのはどのようなきっかけで生まれ、どのような変遷を辿って、どのような足跡を残してきたかというのが、体系的に理解できるようになる。そしてそれが、世界インターネット利用シーンにどのような影響を及ぼしてきたかということも、知ることができるようになるのだ。

HTMLを体系的に理解するための7本の仕様

1本目『HTML 3.0』(1995年

まず最初は、ちょっと強引かも知れないけれど、第一次ブラウザ戦争前の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』の影響を免れたものはないからである。

2本目『Compact HTML』(1998年

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は、これ以降無数に手本とされ、真似され、拡張されることとなるのである。

3本目『HTML 4.0』(1997年

正字仮名の影響を受けた日本の若き日記書きたち――言うなれば「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はここに、新しい時代の幕開けを迎えるに至ったのである。

4本目『ISO/IEC 15445:2000』(2000年

先に述べた「CSSコミュニティ」がWeb日記業界に論争をもたらすのは、2000年代に入ってからのことである。そして、そのきっかけとなったできごとの一つが、1947年生まれの非政府組織で、IECとも協力した生粋工業標準化団体であった国際標準化機構が、この仕様ISO/IEC 15445:2000 (ISO-HTML)』によって成功を収めたことである。

このHTMLは、単にJIS的に標準化しただけではなく、文化的な意味においても、フラットリニア構造の力を広く世界に知らしめることとなった。この仕様の成功によって、世界の人々は、レベル付けされた見出しの魅力の大きさを知る。そしてそれが、やがて見出しレベル分けが世界スタンダードとなり、誰もが当たり前のように使う状況を育んでいくのである。

またこの仕様は、CSSコミュニティそのものにも大きな影響を与えた。この仕様の成功に刺激を受けた才能ある若きコミュニティ住人たちが、その後立て続けに台頭し、いくつもの名サイトを生み出していくからである。

それらが相まって、やがてCSSコミュニティは空前の黄金時代を迎えることになる。その端緒となり、道筋を切り開いたのが、他ならぬこの『ISO-HTML』なのだ。

5本目『XHTML 1.0』(2000年

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業界にもたらした変革には、大きなものがあったのである。

6本目『XHTML 2.0』(2009年

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標準たちの誕生にもつながっていったのである。

7本目『HTML5』(2022年?)

最後は、第二次ブラウザ戦争集大成ともいえるこの仕様である。

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を体系的に見るとはどういうことか」を学んできた。

高校時代に読んだこのサイトによって、「リソースとは何か」ということを、ぼくはを知った。

HTMLSGMLの応用だ」ということが、このサイトを読むことでよく分かる。何気なく見ていた省略記法でも、その裏には、実にさまざまな技術や、それを開発してきた歴史というものが隠されていた。

世界CSSコミュニティの何に驚かされたかといえば、それはやっぱり精緻に書き込まれた正字仮名にだ。ノジタン日記には、HTML本質が詰まっている。だからこそ、あれだけ多くの日記で多くのコミュニティ住人に、言及されたり模倣されたりしたのだ。

ここでは取りあげられなかったのだが、とほほ氏がHTMLというジャンルに及ぼした影響にも、本当に大きなものがある。そして、ぼくが上に挙げた感想のいくつかは、このサイトに書かれていたばけらさんとの「スタイルシート論争」を参考にしたものなのだ。

これらのサイトを読めば、どんなHTMLが素晴らしく、どんなHTMLがそうではないというのが、よく分かる。その判定基準を知ることができ、審美眼を養うことができるのだ。なにしろ、あのCSSコミュニティ住人の言うことなのだ。これにまさる教科書は、他にはない。


元ネタ

2009-06-07

http://anond.hatelabo.jp/20090607123602

よく言えば、バナー制作者が工夫してる。

こればっかりは規制の線引きが難しいから、なくならないんじゃない?

2ちゃん自体もだけど、コピペブログでも普通エロゲとか18禁商品への広告が貼ってあるのは、疑問だわ。

AVでも18禁コーナーってゾーニングがある。借りる時点で18歳未満かどうかは確認できるんだから、

単純に18歳未満には貸し出さないって意味だけなら、ゾーニングは不要なはず。

普通ネットやってても、そういう「誘惑」に出逢うことは多い気がする。

まあ2ちゃんコピペブログ普通かといわれるとなんだが。

W3Cで18歳未満禁止のmetaでも作って、エロ暴力的なコンテンツがある場合はそれを記載義務があるようにして、

そのタグセキュリティソフトが関知してアクセスブロックするとかなっても良いと思う。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん