前回の続き。なるべく一般人向けに書きます。サードパーティCookieとあまり関係のない話も書きます。 http://d.hatena.ne.jp/mala/20111125/1322210819 http://d.hatena.ne.jp/mala/20111130/1322668652 前回までの概要 トラッキング目的のCookieの利用などからサードパーティCookieの利用は問題視されIE6で制限がかけられるもプライバシーポリシーを明示すれば利用できるという迂回手段を用意、しかし今ではP3Pはオワコン化、SafariはサードパーティCookieの受け入れをデフォルトで拒否する設定を採用したが一度受け入れたCookieは問答無用で送信、Mozilla関係者は「殆ど合法的な利用目的はない」と言っていたものの既存Webサイトとの互換性のために変更できず、ブラウザはサードパーティCookie
前回 http://d.hatena.ne.jp/mala/20111125/1322210819 の続きです。 前回のあらすじ ブラウザベンダーはサードパーティCookieをデフォルトでオフにしたかったんだけどお前らがサードパーティCookieに依存したサイト作るし使うからオフに出来なかったんだよ!!!!! といった事情を踏まえた上でWebアプリケーションにおけるサードパーティCookieの利用の歴史について書きます。前提知識の共有が済んだので、ここからはある程度個人的な意見も含まれます。実装面での技術的な内容も含みます。 サードパーティCookieが必要とされてきた歴史 広告のためのトラッキングCookie以外にも、サードパーティCookieに依存したサービスが数多く存在してきた。個人的に把握しているいくつかのサービスについて時系列で述べる。ついでに広告業界の流れについても重要なのを幾
Web開発者のためのサードパーティCookieやらトラッキングやらの問題点について三回ぐらいに分けて書きます。 この文章は個人的に書いていますので、おい、お前のところのサービスがサードパーティCookieに依存してるじゃねーかというツッコミがあるかもしれないが、そういうことを気にしているといつまで経っても公開できないという問題が出てしまうので、そんなことはお構いなしに書く。ちなみに例外なく自社サービスに対してもサードパーティCookieに依存するな死ねと言っている。これはWebプログラマー観点で、自分がサービス開発に関わる上で知っておかねばならないだろう知識として十数年間だらだらとWebを見ていて自然に知っていたものと、あるいは興味を持って率先して調べたものが含まれている。ググッて直ぐに分かる程度の用語の定義的なことは書かない。あくまでWebサイト制作者側からの観点なので、ブラウザ開発関係
今季、何度見たことだろう。両サイドの裏にロングボールを放り込まれて2失点。相馬監督はリーグ最終戦を、「今季の悪いところが出た」と総括した。 相馬フロンターレの1年目は、J1再昇格後ではワーストとなる11位。要因は、はまり切らなかった守備が大きいだろう。 ボールを奪われても、高い位置で囲い込んで奪い返す攻撃的な新システム。序盤こそ好調だったものの、その高いラインの裏は同時に大きな穴となった。リーグ中盤に喫した8連敗中は、20失点8得点。精神的にも守備に追われ、持ち味の攻撃力も影を潜めた。 まさにそんな試合となった、この日の特に前半。FW小林は「長いパスで押し込まれて、攻撃の形をつくる余裕が全然なかった」と振り返った。 わずかに見えた光明は、後半に修正できたことだろうか。スタミナが切れてきた相手のパスの起点を激しいプレスでつぶし、流れを引き寄せた。「後半はこっちのワンサイド。前半からや
第35回全国地域サッカーリーグ決勝大会は3日、大阪・長居第二陸上競技場で決勝ラウンド第2戦2試合を行い、神奈川勢同士の対戦は、YSCC(関東社会人1部)が2―1でSC相模原(同2部)に勝利。YSCCは勝ち点を6に伸ばし、来季の日本フットボールリーグ(JFL)昇格を決めた。 YSCCは、1999年に事実上消滅したJリーグ横浜Fの前身、全日空横浜SCからたもとを分かつ形で誕生し、2002年にNPO法人化。テニスからヨガまで多岐にわたる総合型スポーツクラブとして、地域に密着した活動を続けている。サッカーのトップチームは関東社会人1部リーグを3連覇中。同大会は過去2年決勝ラウンドまで進みながら、JFL昇格を逃していた。 試合は後半、辻、平間のゴールで2点を先行したYSCCがSC相模原の追撃を振り切り、最終戦を残して2位以内が確定した。 最終日の4日は、YSCCは藤枝MYFC(東海)と、SC相
HTML5 Advent Calendarの3日目です。 「HTML5 Advent Calendar」はこんな感じの取り組み。まだ空きがあるので、よかったらどうぞ。 今年は、HTML5もAdvent Calendarやります! 本来のAdvent Calendarとは、12月1日からクリスマスの25日まで、カードに作られた窓を1日に1つずつ開けていくというものです。一方、技術系のAdvent Calendarは、12月1日から25日までの間、毎日違う人が特定のテーマに沿ってブログ記事を書くというものです。もちろん、ここでのテーマは「HTML5」になります。HTML5に関することならなんでもOKです! このイベントに参加した順番が、そのままブログを公開する日付とします。 是非、みなさん一緒にわいわい楽しんでやりましょう! HTML5 Advent Calendar 2011 : ATND
ほかにもやり方はいろいろあるわけですが、カレントディレクトリにCPANモジュール風のディレクトリ構成をもった何かがあるとすると、コマンドラインから > cpanm Mojolicious Pod::Simple (必要なら) > mojo generate lite_app podviewer > perl podviewer daemonとタイプして、http://localhost:3000/perldoc/lib/Hoge のようなURLを見ると、http://mojolicio.us/perldoc 以下で使われているPODビューアを構文ハイライトやらなにやら込みで利用できます。 また、実際には@INCの中をチェックしているので、必要ならpodviewerを起動するときに-Ilibを追加するか、podviewerの中でuse lib "lib";のような行を追加してやると、http
ブラウザーがCSSをパースする際、不明なセレクターに遭遇するとどうなると思いますか? 実はそのセレクターを含むルール全体が無視されます。何を当たり前のことを言っているんだと思われるかもしれませんが、そのルールが複数のセレクターを持っていて、そのうちひとつだけが不明なものだとしてもルール全体が無視されるということはあまり知られていないような気がします。知られていないというよりも意識する必要があまりなかったという方が近いですかね。 つまり以下のようなCSSコードは無意味です。 :-moz-any(article, aside, nav, section) h1, :-webkit-any(article, aside, nav, section) h1, :matches(article, aside, nav, section) h1 { color: red; } CSS4の:matche
体積の単位「ミリリットル」は、記号では mℓ や ml、mL などと書かれる。要はリットルのエルをどう書くかの違いだが、Wikipedia ではこのエルについてこう解説されている。 本来、リットルを表す記号は小文字の l だけである。SIにおいては、人名に由来する単位のみ記号の一文字名を大文字にし、それ以外の単位は全て小文字で書くことになっている。 しかし、多くの英語圏の国では、筆記体のアラビア数字の1を単に垂直の線のみで示すのが一般的となっており、これとラテン文字の小文字の l はまぎらわしい。 1979年、第16回CGPMで、大文字の L をリットルの新たな記号として用いることが採択された。また、将来この2つのうちのどちらか1つのみを正式なものとして選択されるべきであると表明されたが、1990年の会議ではまだその時期ではないとされている。現在では、産業技術総合研究所やアメリカ標準技術局
コンピュータで、「ファイルを開く」という概念がよく理解できません。裏側で何が行われているのでしょうか? 私が理解していること ・コンピュータは0と1しかあつかえない ・ハードディスクは、磁石がのった円盤で、磁力の向きで1,0を表現している ・ファイル読み取りは、これらの1,0の並びを認識すること ・ファイル書き込みは、これらの並びを変更すること では、開く、閉じるは? シェルで、 echo "hello" > hello.txt と実行すると、物理的にはHDDにデータが書き込まれます。 それは理解できます。 しかし、C言語などで FILE *fp; fp = fopen( "test.txt", "r" ); としたとき、fopenの裏側では何が行われているのでしょうか? ファイルポインタ(とかファイルハンドル)とは一体何なんでしょうか? 読み取り、書き込みは、物理メディアに対しての物理的
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く