「W3C」を含む日記 RSS

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

2020-06-22

anond:20200622223511

横。

「」問題傍点が打てないから仕方なくやってる人が多いと思う。

統一表記問題ではなくW3CWhatWG問題

2020-01-23

anond:20200123131608

それこそ、W3C辺りでグローバルな仕様を決めないと、無理じゃねぇかな

2019-09-14

anond:20190914232227

HTML5なんてものはない。HTML Living Standardということだね。

HTML標準仕様策定についてW3CWHATWG合意発表。今後はWHATWGリビングスタンダードが唯一のHTML標準仕様

https://www.publickey1.jp/blog/19/htmlw3cwhatwgwhatwghtml.html


HTML5なんてのは、WHATWG仕様まとめブログが意訳したものに過ぎない。今後はリビングスタンダードが唯一の標準

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プロトコル採用するのはアリなのよ。 Permalink | 記事への反応(3) | 20:57

2019-05-14

anond:20190514114143

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

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

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

2019-03-12

anond:20190223223730

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

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

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;
ログイン ユーザー登録
ようこそ ゲスト さん