WEB関係っぽいことの最近のブログ記事
会社でやっているECサイトのサーバを新しくして、OSもPHPもDBもバージョンも上げた。
サーバが古すぎて、システムをカスタマイズしたくても、何もできないところまできていたから、エイヤっと刷新してみた。
折角だから64bit OSにしたからメモリ積みまくり。
ついでにサーバを増やしてロードバランサにして、Webサーバも多重化してみたよ・・・!
(人に頼んだだけで自分でやったわけじゃないけど)
・・・まあ、一気にやるもんじゃないですねw
一気にやらざるを得ない状況なんだけどね。
もう全然まともに動かん・・・。
PHP4→5の移行もそうだけど、多重化したWebサーバ同士の同期とか色々と大変すぎる。
多重化したらゲートウェイになっているロードバランサが色々と悪さをする。
キャッシュやらSSLやら変な動きをしまくってる。
ただ、ロードバランサが原因なのか特定できないし、決め付けるとハマりそうだしなあ・・・
僕はエンジニアじゃないし、経験も知識もないから、こういう時に凄く困る。
Google先生や親切な人に助けられながら、勘で何とかこなしてるけど、今回はヤバいかも。
それにしても、一番ヤバいのはSSL。
今まで平気だったのに、サーバ刷新したらページ内で使われている画像やCSSのロードが抜群に遅くなった。
一回読み込んじゃえばキャッシュされるのか(?)急に普通に動くようになるんだけど、数分ロードしっぱなしになってしまう。
それがまたJavascriptで処理してるページが最悪に酷くて、ロードが終るまでブラウザからの操作を受付なくなるページとかが大量発生してる。死ねる。
ちまちまJavascriptの方を直そうかと思ったけど、上手くいかず。
まだ原因は特定できていないけど、さっき見つけた下記のサイトに書いてあることが近いので参考にしてみようかしら。
スベログ/D: Apache + mod_sslとIEの関係
Apache + mod_sslでSSLを有効にしてIEでアクセスするとやたらと遅い。
具体的にはページ内で使われている画像やスタイルシートのダウンロードにやたらと時間がかかってる。
ちなみに通常のHTTP接続だと全然大丈夫だったりする。SSLのせーでCPUやメモリが食われているのかな?
と思い、チェックしてみたけど余裕はあるっぽい。うーんと悩んでて試しにFirefoxやOperaでアクセスすると・・・あれっ大丈夫じゃん。(^^;A
何でだろ?とググりまくってたらhttpd-ssl.confにデフォルトで組み込まれている↓以下の設定が原因っぽい。
色々と試してみよう。。。
あんまり更新してなかったらアクセスが減ったので少し寂しいフジイです。
まあ、個人ブログなんだし、ユルユルと書くよ。
ぼくが2月に書いた「論点ちがうよ、web屋さんたちぃ~!!
今はそのセミナーの帰り。
電車でエントリを書いています。
多分Web担当者フォーラムに載ると思うし、めんどうだから、細かい内容は書かないけど、「発注するときはRFP(提案依頼書)書きましょう」っていう富士通の人の話と、「同じRFPでも見積もりが大きくブレる理由」をロフトワークの人が話すという2つが主な内容でした。
特にロフトワークの人の話は非常に面白かった。
ぼくはWeb製作の発注って、知識がないと難しいと思う反面、Web屋さんの言う「正しい発注方法」は製作経験がないと難しいような事が平気で語られることが多くて胡散臭いと思ってたんだけど、今回のセミナーで語られたのは、同じ要件なのに80万~800万の見積もりが出た時の選択方法やリスクを評価する方法、コンペを行う時の注意点など、製作スキルとは違う、発注の際に必要な実践的な内容ばかりで、とても面白かった。
これなら製作の知識がない人でも適切な発注ができると思うので、Web担当者が知るべき発注技法というべきもので、すごく良いセミナーでした。
多分、企業のWeb担当者は参加者の半分か6割くらいだと思うんだけど、色々と得るものは大きかったんじゃないかなあ。
あ、それと個人的にはパネルディスカッションの時間が面白かった。
Web担当者が「社長に好みで横槍を入れられるのを避ける方法はないですか」って質問をしていたのが超ツボw
それと、富士通のWebマスター人がサイトの横幅を設計する時の話で「世の中のスタンダードが何かを調べるのではなく、ウチのサイトに来ている人はどうなのかというアクセス解析をすることです」と言っていたのが印象的だったなあ。
うわー、こないだフォームの送信先はクロールしないよって書いた矢先だったのに。。。
Google様がフォームの送信先もクロール対象にするそうです。
【追記】・・・と、思ったら「Only a small number of particularly useful sites receive this treatment.」ってことで、あくまで実験だから一般サイトには及ばないっぽいっすね。すんません。
秋元@サイボウズラボ・プログラマー・ブログ
張られているリンクをより多く見つける目的で、GooglebotにHTML Formを送信させて出てきたページもクロールさせる、という発表があった。
(中略)
クロールされるフォームは以下のようなものに限定されるようだ。
- GETメソッドであること
- robot.txtなどで除外指定されていないこと
- passwordフィールドを持たないこと
- user, id, accountなどのフィールドを持たないこと
POSTはダメなのか・・・
これって id とか user っていうGETのパラメータをもってるとダメってことかな。
フォーム送信されていない、普通のリンク(href)の場合は &id=xxxx があってもインデックスされているから、これはフォーム送信されるときだけのルールなんだろうね。多分。
ところでスパイダートラップにならないのかなあ・・・
SEO塾のブログより。
チカッパ・ロリポップの404は302? - 永遠にインデックスされ続ける削除ファイル
へぇーへぇー。このブログはチカッパで設置してて、しかもrobot.txt設置していないからヘッダ見てみよう。
(一部省略してます)
http://fujii-yuji.net/robot.txt
GET /robot.txt HTTP/1.1
Host: fujii-yuji.net
HTTP/1.x 302 Found
Date: Sun, 06 Apr 2008 04:31:22 GMT
Location: http://err.chicappa.jp/404.html
----------------------------------------------------------
http://err.chicappa.jp/404.html
GET /404.html HTTP/1.1
Host: err.chicappa.jp
HTTP/1.x 404 Not Found
Content-Type: text/html
ほ、ほんとうに302でリダイレクトしてから404を返してる・・・!
追記:もう一個やってるサイトだとhtaccessで404ページを設定しているんだけど、こっちだと302にならないです。チカッパのデフォルト404だとリダイレクトが走るってことですね。
ま、商用サイトでもないし、別に困らないけど(笑)
ちなみに、クローラーがサイトにアクセスする時、ページより先にrobot.txtにアクセスするから、robot.txtを設置してない人は302→404になってクローラーが巡回できないんじゃないって問題については杞憂ですな。
普通にrobot.txtがないサイトと同じようにクロールしてるみたいです、はい。
チカッパ・ロリポップの404は302? - 永遠にインデックスされ続ける削除ファイル
paperboy&co.が運営しているチカッパやロリポップのサーバでは、存在しないファイルにアクセスした場合に、HTTPヘッダが本来の404を返さずに302でリダイレクトしているのではという疑惑があるというのである。
へぇーへぇー。このブログはチカッパで設置してて、しかもrobot.txt設置していないからヘッダ見てみよう。
(一部省略してます)
http://fujii-yuji.net/robot.txt
GET /robot.txt HTTP/1.1
Host: fujii-yuji.net
HTTP/1.x 302 Found
Date: Sun, 06 Apr 2008 04:31:22 GMT
Location: http://err.chicappa.jp/404.html
----------------------------------------------------------
http://err.chicappa.jp/404.html
GET /404.html HTTP/1.1
Host: err.chicappa.jp
HTTP/1.x 404 Not Found
Content-Type: text/html
ほ、ほんとうに302でリダイレクトしてから404を返してる・・・!
追記:もう一個やってるサイトだとhtaccessで404ページを設定しているんだけど、こっちだと302にならないです。チカッパのデフォルト404だとリダイレクトが走るってことですね。
ま、商用サイトでもないし、別に困らないけど(笑)
ちなみに、クローラーがサイトにアクセスする時、ページより先にrobot.txtにアクセスするから、robot.txtを設置してない人は302→404になってクローラーが巡回できないんじゃないって問題については杞憂ですな。
普通にrobot.txtがないサイトと同じようにクロールしてるみたいです、はい。
システム発注をする際、担当SEさんにSEO的な要件を入れたRFPを渡すと「なるほど~はじめて知りましたー」と言われることも多い気がするので、システム設計に関わる方に見ていただくSEOの基本説明資料を作ろうと思っています。
※基本中の基本なので、わかってる人は読まなくていいくらいの基礎だけです。
Web担に書こうかと思ったけど、荒削りなので、ここにエントリ。
追記していって、まとまったら、 Web担に書こうかな。
■SEOの基本
Google・Yahoo・MSNなどの検索エンジンの仕組みは、クローラー(ロボット/スパイダー)が、色々なWebページを拾ってDBに情報を収めるというものです。ページのデータがDBに格納されている状態を「インデックスされる」と呼んでいます。
インデックスされたWebページは、各検索エンジン独自の考え方と技術によって(=アルゴリズムによって)重要度が付けられ、検索結果として表示されます。
SEO専業とかになると、もっと深いところまで考える必要があるのですが、普通にWebシステムを作るのであれば、下記のように検索結果が作られていると考えてください(実際とは少し違いますけど、基礎としては下記の認識があれば十分だと思います)
(1)クローラーがくる
↓
(2)インデックスされる
↓
(3)アルゴリズムによって表示順位などが決定される
このエントリではSEOの深い技術ではなく、「適切にクローラーが巡回してきて、インデックスをしてもらえるシステムを構築する」という基礎だけを考えることにします。
■クローラーが巡回できるページを設計する
独自ドメインをとって、HTMLでスタティックなページを作って、検索エンジンに登録さえすれば時間はかかりますし例外もありますが、普通はクローラーが訪問してきますが、Webサイトによってはクローラーが到達しづらいページや、クローラーに嫌われるページがあります。
逆に言えばクローラーが巡回してくれるページを設計するというよりは、巡回しづらいシステムを作らなければ良いというだけで、Webシステム設計者の方は、この部分だけ押さえておけば、とりあえずは問題のないものが作れると思います。多分。
■JSにはNOSCRIPTを。
最近のクローラーはJavascriptを理解しているものもある気もするのですが、Javascriptを理解しないクローラーでも巡回できるようにしておくのが基本です。
ただし、JSのON/OFFでリンク先やページの意味が大きく変化するようなNOSCRIPTを仕込むのはスパム行為になるので控えてください。
■FORMは使ってくれません。
これ、意外と知らない人が多くてビックリなのですが、例えばECサイトを作る時に商品カテゴリなどをフォームからのPOST/GET(またはJSなど)で取るようにしてあると、そこから先にクローラーは来てくれません。
クローラーはフォームデータを送信しません(←これ重要)
デザインの時点でクローラーも巡回できるよう設計にしておくのが大事なのです。
(他の方法もあるのですが、スパムにならない方法を説明するのがダルいので省略しますw)
■URLを一意にする
フォワード/インクルードを連発するJAVA屋さんがハマりやすい罠なのですが、クローラーはURLを一意の基準としてページを巡回しています。
クローラーはURLを変えずに遷移させるページを上手く巡回できないので、ちゃんとURL変えてください。
※フレームワークの仕様で変えられないとか言わないでね、本気で困るから(笑)
逆にURLに、PHPSESSID=******を含む場合や、input type="image"の際に送信されてしまうクリック座標データを含むURLなども問題です。
Googleは「同じページにURLが複数ある状態」について下記のように教えてくれています。
ウェブマスター向けガイドライン -Google
セッション ID やサイト内のパスを追跡する引数がなくても、検索ロボットがサイトをクロールできるようにする。 これらの技術は個々のユーザーの行動を追跡する場合には便利ですが、ロボットがアクセスするパターンとはまったく異なります。 これらの技術を使用すると、実際は同じページにリンクしている、異なる URL をロボットが排除できず、そのサイトのインデックスが不完全なものになる可能性があります。
「同じページにURLが複数ある状態」のと「違うページだけどURLは同じ状態」は、どちらもダメって覚えてください。(←これ重要)
上記のGoogleガイドラインにも書いてありますが、ほぼ同一のコンテンツでURLに含むパラメーター少しだけ違う動的ページが大量にある(=ページが大量にある)ような場合、クローラーは(そのサイトへの負荷なども考えて)大量にインデックスすることをしないようにしています。
つまり、インデックスされない可能性や、アルゴリズムによる評価が低くなる可能性があるということです。
もちろん、それだけではなくセッション・クッキーやリファラーによって表示を変えるページもクローラーを惑わせるので、上手に設計する必要があります。(変なことするとスパムになることもあるから注意)
以前と違い、最近の検索エンジンは動的なページもインデックスしてくれますが、それは上記のように「URLを一意にする」を守っている場合です。GETで引き回すシステムを作る時に、同じ検索結果なのに様々なURLがあるシステムを作ってしまうことがあります。例えば下記のような場合です。
「メーカー名→カテゴリ→素材」と遷移してきた場合と「カテゴリ→素材→メーカー名」と遷移した場合で、同じ検索結果を返していてもURLは違う・・・なんてことはありませんか?これらは同じURLを返すように設計すべきです。
または、下記のようにメインの検索ルートは動的なURLを使用せず、フリーワードや絞込みの際にフォワードやフォームを使ったページを返すというのが、一般的な手法だと思います。

また、URLにGETのパラメーターを表示している、いないに関わらず気をつけなくてはならないのがスパイダートラップです。
生ログを見ればわかると思いますが、大手検索エンジンが放つクローラーは非常に行儀がよろしいので、できる限り巡回先のサーバーに負荷をかけないように考えて動いています。
ですが、サイトの設計によっては、クローラーがURLに含むパラメーター違いなだけの似たページを巡回しているうちに無限ループさせられることがあります(最近のクローラーは賢いから気づくっぽいけど)
当然、そういったサイトは検索エンジンから好かれることはありませんので、クローラーのループが発生しないような設計が必要です。
・・・なんてものを書いていたら、SEOmoz 動的サイトにおけるSEOの施策という素晴らしい記事が公開されているじゃないですか。ぼくのエントリより、これ読む方がいいかも。とほほ。
つ、疲れた・・・今日はこれ以上書く気力が起きないので、気が向いたら続編を書きます。。。
仕事で製造メーカーの方と話をしていて感じたことがある。
会社や業界にもよるのかもしれないけど、製造メーカーのクオリティってホントに凄い。
折りたたみ式のケータイみたいな形状の製品って、何回開閉をしたら手ごたえが柔らかくなるか調べてるんですよ!
メーカーによるんだろうし、知っている人からすれば当然のことかもしれないけど、ぼくは初めて知ったので、凄くビックリしました。常識なのかな。。。
バイト雇うのか品質管理の人が手作業するのかしらないけど、ワイヤー状の部品とかと違って試験機かけられない形状のものをテストするの大変だろうなあ・・・
試験機使う場合だって、試験機で振動を与えて何百時間で壊れるかを確認したり。
こんなクオリティで消費者と向き合わないといけないなんて、製造メーカーって、本当に凄い。
昨年はメーカーによるお詫びやら呼びかけのCMがテレビに流れまくったらしいけど(今さら、こんな話題ですんません)何十年前に作ったものでも、消費者の使い方が間違っていても、製造メーカーは何らかの責任を問われるんだよね。
製造メーカー以外の業種の方、もしも、製造メーカーレベルのクオリティで業務を進めろって言われたらギブアップしちゃいそうだと思いませんか?ぼくは思いました。
それでいてコストダウンやアフターサービス、CSも高いレベルで求められるんだもんなあ。脱帽。感服。
参考にならないくらいレベルが高すぎるって思ってしまいそうだけど、クオリティに対する心構えくらいは参考にしたいと感じた春の日なのでした。
いや、ひとことじゃ済まないからタイトルは釣りだと思ってほしい。
ECについては色々と思うところのあるフジイですよ。こんにちは。
売れないオンラインショップの条件という記事が、はてなブックマークで話題っぽいので、ちょっと釣られてエントリを書いてみようと思う。
売れないオンラインショップの条件 -japan.internet.com
年商3億円近くも稼ぎ出しているそのオンラインショップ(中略)
その Web サイトを見て愕然とした。
ページが1ページしかないのである。しかも、果てしない縦のスクロールが続き、デザインを無視した巨大な商品写真と巨大フォントで書かれたキャッチコピーの嵐、段組みも行わない。
まず、この記事に対して、「商材が良いからだ」とか「デザインをよくすれば、もっと売れる」と言っている人は自分で商売をしたことがないか、少なくとも物を売るという行為が苦手な人だろうなあと思う。
ダサいスーパーのチラシが主婦層に訴求力があるのと同じなんだから、そういう層がいることは認めなくちゃいけない。
また、この記事に対して、「全てのネットショップがそうなっていく」とか「デザイナー不要」と言っている人は3億どころでは売上を上げているネットショップ、例えばAMAZONや大手のECサイト(モールではないところ)を見てくるといいと思ったよ。
デザイナ不要と思った人も、良いデザインにすれば売れると思った人も、どっちも元記事を誤解している。
商売を、そういう「型」にハメちゃうのが「売れない」を作る原因なんだよなあ。。。
正直、実店舗の運営にも関わったことがあり、ECにも関わる僕としては、今頃になってこんなことが話題になるを見て驚いたわけだが、実店舗の小売業では当然のことが行われているだけなんだよね。
今は小売業はどこも苦戦しているけど、そこは軽く目をつぶって最盛期のことと思って考えてほしい。
ドンキホーテが、どこに何が置いてあるかわかりにくい圧縮陳列をして、勢いをつけた時代がある。
例えばドンキホーテが、見やすく探しやすいユーザビリティに優れた陳列では、大して売れなかっただろう。
レクサスがドンキホーテみたいな雰囲気だったら、高級車は売れるだろうか?
スーパーや家電量販店のチラシは、激しくダサいが訴求力があるし、高級家具を扱う店のカタログは高級感がある。
おっと、精髄反射で「ネットと実店舗は違う!」って言わないでよw
その考えは危険だ。孔明の罠だ。
僕が言いたいのは、「オンラインショップ」をひとくくりするなってことです。
普通に考えて、商材も違うし、会社規模も、狙っている顧客層だって違うんだから、オンラインショップってひとくくりで語れるわけない。
デザイン必須派も、3億円ECサイトの手法を否定せず、「売り方のひとつ」として認めるべきだよ。
かつ、「全てのECサイトにあてはまるわけではない」ってこともよく考えるべき。
(そもそも、年商3億って別に「売れてる」って言うほどの金額じゃあないしねw)
その手法があてはまる条件(商材・会社・ターゲット)であれば、楽天的ショップみたな作りをすればいいんだし、あっていなければ合う手法を考えればいいだけ。
元記事も、そういうことを書いてるっぽいんだけどデザイナー不要論とか持ち出して煽ってるから、誤解している人が増えちゃったんじゃないかと思うです。
ラブライブ見逃した・・・
※ラブライブはWebライブ番組を作り方のノウハウ番組
仕方ないのでアーカイブ見てます。生で見たかったなー
月曜だからスピリッツは買ったんだけど、ラブライブのことを忘れるとは・・・とほほ・・・
それにしても、この感覚って凄く新鮮。
テレビの生放送は録画で見ても内容がかわるわけじゃないけど、Webライブ番組の場合は参加型だから放送時間に見た方が100倍おもしろいんだよね。
視聴者に生で見られなかったのが悔しいと思わせたら製作側の勝ちなんだと思うんだけど、正に!今!ぼくが悔しいと思っております!ちくしょー、来週は絶対に生で見てやるー!
見逃したお陰で、Webライブ番組を視聴する面白さに気づきましたよ。
(と、書いて自分をなぐさめる)
もっともっと、みんなWebライブ番組みればいいのに。
とはいえ、音楽かけてるだけのFMの延長みたいな番組(?)が多いから面白い番組を探すのが大変なんだよね。
ぼくが面白い番組を探して紹介しようかと思ったんだけど、テレビと違って曜日とか放送時間を固定化している番組って少ないから紹介しにくいんだよね。
それにしてもラブライブで河野さんが放送曜日・時間の固定化を推奨している理由が改めてわかりました。
著作権問題的にアレなんだけど、最近見たので面白かったのは24時間ぶっ通しで20年以上前のファミコンのゲームをやり続ける番組。
レトロゲームという題材も面白いんだけど、なんといってもチャット参加している視聴者との対話が凄く上手くて、そこが面白いツボだった。
やっぱWebライブ番組は視聴者との掛け合いが面白いんだなあ。。。
#あ、アーカイブ見ながらエントリ書いてて気づいたけど、再生の途中で止まる・・・ぼくの環境のせいかなあ・・・とりあえずラブライブのブログにコメントしておこう・・・
##(追記)あれれ、今見たら、止まらず見れた。ぼくの環境のせいだったのかも。ごめんなさい。
やっと、はてなのトップページから消えた模様。
ふぅーーー。
好意的な方が大半でしたし、ご指摘・ご意見をくださった方も凄く勉強なる鋭いご意見を頂いたので納得ですし、貴重な体験をさせていただいたとは思うけど、何か疲れたなあw
っていうか、そんなに多くの人が興味を持つような良いエントリじゃなかったと思うんだけど、、、不思議なものですね。
smashmediaの河野さんが、はてブがわからないというエントリで
ブックマーク数というものに対してどう評価すればいいのか悩みます。と書かれていたのを思い出して読み返してしまうくらい、不思議な気持ちになりました。
ぼくみたいなのがネットの片隅で書いたことを色々な人が読んでくださったのは、すごくすごく嬉しいことです。
それと同時に何というか上手く説明できない不思議な気持ちがあるんですよね。
なんだろ、これ。
うまく言葉にできたら書こうと思うので、忘れないように、不思議な気持ちになったってことをエントリにして残しておきます。
(わけわかんないエントリで、すんませんですwww)
はてブのコメントやトラバでコミュニケーションが生まれていくのは楽しかったです。
まだこのブログはじめて3ヶ月だけど、ブログって面白いなあ。
#どーでもいいけど、ぼくのブログはブログレーダーにはひっかからないらしい。
レーダーにひっかからないって、どんなステルスw
うお。なんじゃ、こりゃ。
昨日の晩に書いた論点ちがうよ、web屋さんたちぃ~!!が、はてなブックマークの人気エントリー(ホッテントリ)になったみたいで凄い勢いでアクセスが増えてる。
なんだ、このアクセス数。
あー、びっくりした。
頭痛が酷くて推敲せずにアップしたから、超gdgdなのが超気がかり。
ああ、あんな読みづらいの読んでくださってありがとうございます。
割とWeb屋さんが好意的な反応で嬉しいっす。
ホッテントリ入りしたのに気づいたときは、
「ああ、もうダメだ。ハカーの人に自宅さらされたり、渋谷歩いてるときに黒い頭巾を被った12人のWeb屋さんに囲まれてボコボコにされたりするに違いない」
と、妄想にかられたのですが、そんなことないみたい。
Web屋さんって、理想に燃えてる人が多いですね。
そこがステキです。
ちょっとだけフォロー。
ぼくが見積もり依頼するときの要求がアバウトなのは間違いないっす。
精度を上げるのに努力してます。迷惑かけた方、サーセンwww
実際のところ、ちゃんとはできていませんです。
はじめて発注する人に発注のコツを教えてあげたげてください。
好意的に思ってくださるWeb屋さん、ありがとう。
是非、中小企業のWeb担に会う時には、発注のコツを教えてあげてください。お願いします。
ぼくが始めて発注をした時は、そりゃあもうお互いに辛い思いをしましたので。
Web屋さんにとっても良い結果に繋がると思いますので、Web担を育てるつもりで、ここはひとつ。
Websig24/7の参加者の方、ダシに使ってごめんなさい。
煽りに使うつもりじゃなくて、Web屋さんがクライアントの悪口言うのを聞いちゃったことがあるってのを表現したかっただけなんだけど、読み間違うとWebsig24/7の参加者の質が悪いみたいに見えちゃうから追記しました。
Websigのおかげで、発注方法を色々と工夫したりできています。感謝してます。変な書き方して本当にすんません。
まあ、こんなにアクセス増えるのも数日の間だけだろうけど(普段のエントリは面白くないだろうからね)、自分の書いたものに物凄い勢いでレスポンスがあるのは、ちょっと面白い体験だったな。
はてブって面白いとはじめて思ったよ。
