ここギコ！: 位置ゲーの歴史をまとめてみた
Posted by nene2001 at 11:07 / Tag(Edit): 位置ゲー 歴史 / 0 Comments: Post / View / 0 TrackBack / Google Maps Wikipediaに位置ゲーの項目ができていたので、私の知っていることを補完していってるのですが、いろいろ調べていくうち、面白いことが判ってきました。 せっかくなので図にまとめてみました。 （なお、判らないままにまとめたところも多々あります。正確な情報を持っている方は、教えていただければ修正します。） ▲ 位置ゲーの歴史年表 ▲ 図の見方としては、矢印の始まりと終わりで、サービスの開始時期と終了時期を表し、色で対応しているキャリアを表しています。 黒色の矢印はマルチキャリア（対応キャリア数は問わない）を表しています。 複数のサービスの矢印が同じ高さに、時期をずらして
ここギコ！: tokuhiromの書き方、頭悪りい
Posted by nene2001 at 22:56 / Tag(Edit): tokuhirom brain 100% pure geek / 73 Comments: Post / View / 2 TrackBack / Google Maps 1/3冒頭追記：今回のトリガになった記事につきまして、特に悪意がなかった件は、tokuhirom氏の追記により了解しました。 が、とりあえず書いてしまったモノは書いてしまったモノとして、そのまま残しておきます。理由はコメント欄参照。 DISられるほど俺のコードの品質が悪いしメモリ効率もよくないのは認めるが、それでもこの書き方はないだろう、ハゲ。脳みそ100%天然ギーク。 HTTP::MobileAgent::Locator を Location::Area::iArea に依存しなくした - TokuLog 改め だまってコ
ここギコ！: はてな・MixiにOpenID対応汁！の声が高まっております
はてな・MixiにOpenID対応汁！の声が高まっております。 Authentication/Identity for Mashups -blog.bulknews.net- はてなとMixiがOpenIDに対応してくれればなあ 独自アカウントから解放されるということ -眠る開発屋blog- なんでもオープンとか言うなら、ぜひともユーザー認証もオープンに -浅倉卓司＠blog風味？- 各投稿の温度差無視して都合のいい部分だけで一からげにしたというそしりもありましょうが。 各サービスがOpenIDでのサーバ・クライアント双方に対応してくれ、そして各サービス独自のIDとOpenIDとが紐付けられれば（=各サービス間のIDが相互運用可能になる）、それだけでも各サービス間の機能の疎通が一意なOpenID経由で可能になって、SNSはオープンにしないといけないよという以前のエントリに対する一つの解にな
ここギコ！: FreeStyle WikiでOpenIDログインプラグインを作ってみた
FreeStyle WikiでOpenIDログインプラグインを作ってみた。 ほとんど骨格はまかまかさんのTypeKeyログインプラグインと一緒。 後は認証ロジックをMovableType OpenID CommentプラグインやCatalyst OpenID プラグインに真似させてもらって。 動作例はyadis.jpで公開中。 しかし何故かあまりうまく連携できない。 というか、Videntity.orgの公開直後はうまく連携できていたはずの、公開サービスであるLiveJournal、TypeKey、Videntity.orgの３者が、ここ最近何故かうまく連携しなくなっているみたいで、何をリファレンスにテストすればいいのかわからない状況で...。 とりあえず公開サービス間の連携では、唯一LiveJournalをOpenIDサーバ、Videntity.orgをコンシューマにした組み合
ここギコ！: OpenIDで個人サイト同士が繋がるSNS - Social_Networking_Unlimited
2005年10月14日 OpenIDで個人サイト同士が繋がるSNS - Social_Networking_Unlimited OpenIDのメーリングリストで、OpenIDでのアカウントをベースに、自分のBlogサイト等メインURLをベースに繋がれるSNS実装ができた事を知った。 Videntity.orgという、OpenIDの認証サーバサービスが始めたサービスなのだが、すごい面白い。 まず、OpenIDがよく知られてないと思うので簡単に説明すると、自分を特定するURLとパスワードをIDのベースとして、OpenIDに対応したサイトならどこでもその組み合わせでログインできるようになるシステム。 例えば、Videntity.orgでkokogikoというアカウントを作ると、http://kokogiko.videntity.org/という個人ページが作られ、このURL（kokogikoだ
ここギコ！: いわゆる「地図サイト」の座標系って？
Google Maps Remixというのが流行っているらしい - Nakamura-KU ADDICT ここまでは簡単だったのですが、僕の目的であるGoogle Maps上の任意の位置の緯度・経度情報を取得はちょっと厄介っぽい。 調べたところGoogle Mapsの投影法はメルカトル図法のようですが、中心点・スケールなどの引数は緯度経度単位系で呼び出しているおり、画面の表示単位系（多分メルカトル）と管理の単位系（WGS84 緯度経度)が異なってます。 そのため画面のクリック位置から緯度経度の算出は面倒な気が... これ見て長年来の疑問が湧き上がってきたのですが、MapionだのMapFanだのちず丸だの、あの辺の普通のWeb地図サイトの投影法って、どういうアレなんでしょうか？ 昔携帯版ここギコを作るために、MapFan・ちず丸あたりで、経緯度何度変われば何ピクセル移動するか、その逆、
ここギコ！: HTTP::MobileAgent：サブクラス検知でいきなりつまづく
Posted by nene2001 at 15:28 / Tag(Edit): / 2 Comments: Post / View / 2 TrackBack / Google Maps 先に書いたHTTP::MobileAgentアーキテクチャ改修提案ですが、まだ本家には連絡していません。 とりあえず何か形がないと言っても流されるかもしれないので...。 とはいえ、今ある機能を全部再現してから提案、となると、元々一人メンテナ無理でしょ、というアタリから出てるのに本末転倒なのでアレですが、とりあえず最低限のアイデアの実現の目処は立ててから提案するかなと。 で、サブクラス・プラグインの自由な別開発、新規開発を可能にするための自動検知機構ですが、いきなりつまづきました。 こんな感じの実装を考えていたのですが（これはサブクラスの例ですが、プラグインも同じ）、 HTTP:
ここギコ！: OpenIDやその周辺の認証、FOAF承認の議論場所
Posted by nene2001 at 05:45 / Tag(Edit): / 0 Comments: Post / View / 0 TrackBack / Google Maps すみません、その後考察も実装も進んでませんが、今この辺でいろいろやってるサイトの紹介をば。 どんぞこ日誌 FOAFとTypeKeyでWiki承認など、FOAF周りの実装で実績のあるまかまかさんのサイト。気付かなかったOpenIDの危険性等、いろいろ勉強させられます。 びーこん OpenID仕様日本語訳の作成者。OpenIDのMLでも仕様の提案等をされており、日本でのOpenIDサーバの立ち上げを考えておられる一人者。 ひらっちblog FOAF承認と同様、オープンなSNSの基盤となりうるAffelioプロジェクトでも、積極的に提言・活動されている方。 というあたりでしょうか。 一応個
ここギコ！: ステルスFOAF
FOAFベースの承認ですが、自分から直接の知り合いに関しては、FOAF上の深度1のノードを走査すれば、承認可能です。 しかしながら、友達深度2、3と降りていくと、自前のFOAFだけでは承認できないため、seeAlso要素を辿って適合するFOAFファイルを探していくわけですけども、これが承認の要求が来るたびに行っていたのでは、時間がかかってあまりに効率が悪い。 特に友達100人できるかなな人のFOAFでは、事実上不可能に近い。 というわけで、コンテンツの承認範囲にFOAFの深度で制限をかけるならば、かけた方の責任で、事前に規定の深度までFOAFを走査しておいてキャッシュしておいてよ、という話になるわけだけど。 でもそれなら、FOAFをキャッシュして、承認要求時にmbox_sha1sumからURL逆引きするための何らかの常駐システムがサーバに必要と言うわけだし、それなら別に深度1の友人だ
ここギコ！: FOAFだけで友人認証する方法
Posted by nene2001 at 06:41 / Tag(Edit): / 3 Comments: Post / View / 3 TrackBack / Google Maps 先のエントリで書いた一番いいのは認証側・被認証側のFOAF、認証側・被認証側のサーバ、被認証側のブラウザ、この５者だけで完結して認証できればベストの方法を思いつきました。 というか、英語が苦手なせいでOpenIDプロジェクトのほうを精査できてないので、はげしく同じ発想かもしれないという気がしてならない...というか、サイトだけ見ると違うっぽいなと思うんだけど、ML斜め読みしてると同じかもという気がしてくる...のですが、まあ同じだったなら同じで、自分で紹介記事を書いたプロジェクトと同じものをわざわざ晒す馬鹿者もいるという事で、まあ笑ってみてやってください。 違うなら違うで新しいアイデア
ここギコ！: FOAF（に限らず）での記事公開範囲認証とか、httpdで対応してもよいのでは
2005年05月18日 FOAF（に限らず）での記事公開範囲認証とか、httpdで対応してもよいのでは FOAFで訪問者の自分との近しさを判定して、記事の公開範囲を変更する場合、例えば既存のBlogなんかでそれをやろうとすると、PHPなんかで認証結果を受け取り、それに応じて動的に公開範囲に応じたページを生成するしかなかったわけです。 MovableTypeのように、スタティックなページを出力するタイプのCMSの場合、訪問相手の認証状況に合わせてページを変えるというのは不可能だったわけですが（もちろん最近のMTはPHP出力にも対応してるからそれを使えばよいという説もあるが）、 よく考えれば、FOAFで認証された公開レベルより低い公開レベルのデータしか提供しない、同じURLでも認証レベルによって異なるデータを出力するといったあたりを、Apacheのモジュールとして実装してやれば、静的コンテ
ここギコ！: セマンティックWEBは成功する…かも
Folksonomyが熱い昨今ですが、 タグ付けって精度の粗さはあるとは言え、明らかにメタデータ付与行為ですよね。 でも皆喜々としてタグ付けしているのを見ると、セマンティックWEB懐疑派の言う「メタデータなんて誰も付ける訳ないやんけ」という前提は、実は間違っていたんじゃないかと思いました。 今までは、少なくとも私の知るところでは、セマンティックWEB肯定派からの反論ですらこの前提は受け入れて、「（ブログでRSSが隆盛したように）人がメタ情報を付けなくても、ツールが支援して付けてくれるようになるんだ」といった類のものでした。 ですが、実はそもそもそんな前提自体根拠がなくて、先にある程度の実装があって、（データ付与という）苦労をしてもそれに見合うリターンがあるような状況では、人は苦労を惜しまないのでは、という気がしてきました。 考えてみると、今のWEBのHTMLタグ付けだって、もう当たり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ここギコ！: ステルスFOAFに近似な仕様があった
ここギコ！: FOAF承認における認証バックエンドは、なんでもいいんじゃないか