You see this page because there is no Web site at this address.
You see this page because there is no Web site at this address.
livedoor Reader(LDR) Unread Counter
グーグル公式ブログの一つ Official Google Webmaster Central Blog にて A proposal for making AJAX crawlable という記事が公開されました。SEM R 様が訳されたものを、Google、AJAXサイトを検索エンジンに登録する方法を解説にて公開されてます。 ポックンは SEM R 様の記事を公式サイトより先に読んだのですが、末尾に私は開発者ではないので専門用語の使い方がわからず、文章が変ですがご容赦をとの注意書きがありましたので続けて公式サイトも読みました。ところが元の文章も、パッと見ただけではウェブサイト開発者に対してグーグルがどうして欲しいのかちと分かりにくいような感じの内容でしたので、ウェブサイト開発者主観で今回のグーグルからの提案の内容を簡単にご説明したいと思います。 まず今回のグーグルからの提案は、Ajax を
「イベントモデルの概念と用語法が混乱しているので、イライライするんですが」が随分長くなったので、その要点を箇条書きにまとめておきます。 Javaイベントモデルにおけるイベントソースを、DOMイベントモデルではイベントターゲットと呼ぶ。 DOMツリー内をイベントが伝搬する運動過程をイベントフローと呼ぶ。 イベントフローのときに通過するノードの列をチェインと呼ぶ。チェインの両端は、ルートノードとイベントターゲット・ノードである。 イベントフローは、キャプチャリング・フェイズ、ターゲット・フェイズ、バブリング・フェイズの3つの部分に分けられる。 イベントフローのチェインに含まれるノードは、EventTargetインターフェースを実装する必要がある。 「イベントフローの折り返し点=チェインの端点」であるイベントターゲットと、EventTargetインターフェースおよびEventTargetを実装し
なんかしばらく WebKit について書いてみたいと思います。開発するために必要な基本的なこととかより、まぁなんか個人的に話として面白いと思ったことについて。 とりあえず WebKit 内のコンポーネントの構成とかから。 WebKit ってのはまぁライブラリなわけで、かつ Win/Mac/Linux などで動いてるので、「WebKit を使って書いたら portable なコード一個管理したら OK」的な感じなのかなーと思うんですが、その実 WebKit API は環境ごとに少しずつ違う物体だったりします。 例えば Windows だったら COM を使ったり Mac だったら ObjC だったり gtk とか kde もそれぞれのシグナル配送モデルを使って色々やったりとか。 portable なライブラリっていうと portable に書けない部分は最小限のライブラリを環境ごとに実装して
WebKit のコードについて。 Google 社内のコードを見慣れてると、 WebKit のコードはまず、オープンソース的な感じというか、ありていに言うとコメントが圧倒的に少ないように感じます。特に内部についてわかってない人もわかるようなコメントを書く気は基本的に無いらしく、冗長気味なコメントを書くとむしろ削ってちょとレビューされたりします。偉い人死んだらどうするのかなー的な。 あとは関数名とかもイマイチなのが多いように思います。個人的な体験で一番印象的だったのは HTML parser 内にあった parseSpecial という関数でした。この special ってのは textarea, script, style, iframe なんかの中にあるタグが無視されるような種類のものを指していたのですが、 special って命名はアレだなぁ…と。そう思いつつ WebKit の人はみん
WebKit のコードレビューについて。 Google ではこのコンポーネントはあの人が詳しそうだなーという人にコードレビューをお願いするシステムなのですが、 WebKit では WebKit reviewer 全体に review を頼んで、このコードは俺が得意だとか見られると思った reviewer が review するシステムになっています。また、 Google やら Chrome やらではほぼ committer==reviewer と言って良いのですが、 WebKit の場合は committer になってさらにかなりの修行を積んだ人だけが reviewer として認められるシステムになっていて、 reviewer は committer よりかなり人数が少なめになっています。 さてこのシステムだと実際のところどういう感じになるかというと、 reviewer を指定しないので「
テストについて。テストは、 Layout tests と呼ばれるもので行なわれています。 LayoutTests というディレクトリに入っています。これはテストの html を用意しておいて、それに対してどういうふうに rendering する予定であるかをあらわす render tree というものをテキストとして出力させて、それに対してテストを増やす時に置いておいた expectation との diff を取って diff が無ければテスト成功という感じで行なうテストです。 テストは、緑背景に PASS と書いてあるなど、見た目で成功しているか失敗しているかがぱっとわかるテストが好まれるようです。例えばこんな感じ: http://lt.shinh.org/t.html#t=css2.1/t0801-c412-hz-box-00-b-a 元々はその render tree の比較しかな
Cookieよりも大容量のデータをクライアントサイドに保存する仕様。それが HTML5 の Web Storage です。 Web Storage はまだ策定中です。 Firefox3.5+, IE8+, Safari4+, Opera10.50+ など最新のブラウザでは既に利用可能ですが、「何年も待ってられない、今すぐ使いたい」ですよね? そこで、クロスブラウザな Web Storage 相当の機能を uupaa.js に実装してみました。 # sessionStorage は実装していませんよ デモ http://pigs.sourceforge.jp/blog/20100104/20100104_uu.storage.htm Firefox2+, Safari3.1+, IE6+, Google Chrome3+, Opera9.2+ で動作確認してます。 ストレージバックエンド 以
正規表現を超えるの補足として、CSVファイルを例に挙げて考えてみる。 CSVファイルの定義は、RFC4180にある。 file = record *(CRLF record) [CRLF] record = field *(COMMA field) field = (escaped / non-escaped) escaped = DQUOTE *(TEXTDATA / COMMA / CR / LF / 2DQUOTE) DQUOTE non-escaped = *TEXTDATA TEXTDATA = %x20-21 / %x23-2B / %x2D-7E COMMA = %x2C CRLF = CR LF CR = %x0D LF = %x0A DQUOTE = %x22 これを Haskell の Parsec で書くと、ほとんどそのままの形で実装できる。 import Text.
Parsec には以下のようなコンビネーターが存在する。 many p -- p を 0 回以上 many1 p -- p を 1 回以上 count n p -- p を n 回 しかし、正規表現の"{min,max}"のような範囲指定はない。そこで実装してみた。 import ApplicativeParsec range :: Int -> Int -> GenParser tok st a -> GenParser tok st [a] range n m p = (++) <$> count n p <*> upto (m - n) p upto :: Int -> GenParser tok st a -> GenParser tok st [a] upto 0 _ = return [] upto n p = (:) <$> p <*> upto (n - 1) p <|>
iPhoneアプリはすごく便利で良いものですが、あれは正直マズイですよね。あんなに簡単に便利なアプリが買えてしまうと、つい衝動買いしてしまって、気がつくと結構なお金を注ぎ込んでいたりします。今までiPhoneアプリに使った合計金額なんて、怖くて知りたくも無いという人もいるかもしれませんが、ここは一つ無駄遣い防止への戒めと今後のアプリ購入計画のためにも見ておいてはいかがでしょうか。 『App Store Expense Monitor』は、これまでiPhoneアプリにいくら使ったかの合計金額が分かるアプリです。このアプリは、まずiTunesフォルダの中にあるiPhoneアプリをすべて洗い出し、その金額をApp Store から引っ張ってきて、今までにiPhoneアプリに使った金額の合計を算出します。 しかもこのアプリは、システム内にあるすべてのアカウントのiTunesフォルダのiPhoneア
GoogleのMatt Cutts(マット・カッツ)氏によるウェブマスター向けのQ&Aビデオです。 前回の投稿から1ヶ月以上投稿がありませんでしたが、今日紹介するビデオの他にもアップされてるので再開ということでしょうか。 さて、今日取り上げるムービーのタイトルは、”Are links in footers treated differently than paragraph links?” 、『フッターのリンクは、パラグラフのリンクとは異なって取り扱われるのか?』という質問です。 「パラグラフリンク」とは、記事の文章の中から張られたリンクのことです。 メインとなるコンテンツにあるリンクと考えていいでしょう。 Are links in footers treated differently than paragraph links? “もともとのPageRankの仕組みでは、リンクはトップに
”Widgetbait(ウィジェットベイト)”という言葉は、聞いたことがないかもしれません。 ウィジェットベイトとは、”Widget(ウィジェット)”で”Linkbait(リンクベイト)”をすることです。 すると今度は、ウィジェットとは?、リンクベイトとは?という話になってくる読者さんもいるかもしれません。(笑) 簡単に説明を。 ウィジェットは、「ブログパーツ」と読んだほうが馴染みがあるでしょうか。 ブログやWebサイトに貼り付けて使うちょっとした部品で、UNIQLOCKなんかが有名ですね。 リンクベイトは、すごく簡単に言うと、意図的に話題・注目を集めることでリンクを集める手法です(詳しくは、Wikipediaで)。 激しい論争をあえて巻き起こすような意見を述べるのは、リンクベイトの一手段ですね。 一歩間違うと、炎上しますが。 ウィジェットベイトは、(たいていの場合)無料でウィジェットを配
住所や生年月日、クレジットカードなどの個人情報をインターネット経由で伝えることが当たり前のようになり、セキュアな通信はますます重要になってきています。 SSLというのは、”Secure Sockets Layer”の略でインターネット(TCP/IPネットワーク)でやりとりする情報を暗号化して送受信するプロトコル(通信規約)です。 ウェブサーバーとブラウザの通信をSSLの仕組みを使って暗号化するのが、HTTPSです。 SSLは、公開鍵やら秘密鍵やらデジタル証明書やらデジタル署名やらいろいろな技術を使い、理解するのに難易度が高い仕組みです。 といっても、今日の記事はSSLの解説ではありませんので、中身は知らなくてもぜんぜんOKです。w ブログ読者から質問をいただきました。 「HTTPSページをインデックスさせないようにするには、どうすればいいのか?」という質問です。 この方は、eコマースサイト
Googleのインデックス能力は、依然として伸び続けています。 Googleは、ほぼ1年前からFlash(.swf)をインデックスするようになっています。 さらに性能が向上し、FlashのSWFファイルが外部から呼び出すHTMLやXML、別のSWFもインデックスの対象に含めることに成功しました。 Webmaster Central Blogで公式アナウンスされています。 すでに導入が済んでいて、次のようなこともできるようになっています。 ユーザーと対話するために表示されているテキストコンテンツをインデックスできる。人間のようにボタンをクリックしたり、入力を送信できる。 FLASH内のリンクを発見できる。 外部リソースを呼び出し、親ファイルと関連付けできる。 SWFObjectやSWFObject2のようなFLASHに埋め込まれた一般的なJavasrcipt技術を、サポートする。 AS1、A
今日は「ロングテール」キーワードをターゲットにしたSEOについて、考えてみたいと思います。 まず、このエントリで用いる「ロングテール」という用語を定義しておきます。 最近は、ロングテールというと「複合キーワード」、もっと言えば「キーワードの数が多い、長いキーワード」として使われる傾向にあるように思えます。 しかし、もともとの意味は違いますね。 「数が非常に少ない、しかし種類が非常に多い」データの分布を表します。 上のグラフの赤の楕円で囲まれた部分です。 恐竜のシッポに見立てて、長いシッポ、Longtailと表現されます。 グラフがキーワードの種類と検索数だったとすると、月に数件しかないようなニッチなキーワードでの検索が延々と続くことになります。 ロングテールに関しては、梅田望夫さんの『ウェブ進化論』が分かりやすいんじゃないでしょうか。 ここでは、もう一歩踏み込んで、ロングテールキーワードを
検索結果での非表示、被リンクの分散、クローリング効率の低下、最悪の場合ランキングの下落・インデックスからの消滅など、重複コンテンツはさまざまな悪影響を発生させます。 海外では重複コンテンツは、ブログ・フォーラム・カンファレンスなどで頻繁に取り上げられるトピックですが、日本のSEO界では、重複コンテンツはあまり話題に上がらないし、興味を持たれていない気がします。 たぶん理由の1つに、重複コンテンツそのものが理解されておらず、何かややこしいもの、自分には関係のないものとしてとらえられているからではないでしょうか。 それはそれで構わないのですが、重複コンテンツによってトラブルにあっていると判断できる問い合わせを何度も受けたのことがあるので、少なくとも重複コンテンツが抱える問題と、対処方法については、SEOに携わる人間なら概要だけでも押さえておくべきだと思います。 重複コンテンツについて、名前くら
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く