マンダリンケーキのレシピ

RSS1.0Atom0.3

このブログのテーマ:
Linuxをいじる Windowsを飼い慣らす Solarisに悩む Firefoxを使い倒す Thunderbirdを使い倒す
W-ZERO3で仕事する Mindmap(マインドマップ)で仕事する
WRC(世界ラリー選手権)を観る 車を走らせる
日常の非日常を記録する
<< March 2024 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 >>
 
+ GREEN goo +

サイト内ウェブ
この検索は「緑のgoo」を利用してます
現在、本貢献中
+ TWITTER +
+ OTHER WORLD +
あわせて読みたい
+ KEY WORD +
+ RECENT COMMENT +
+ RECENT TRACKBACK +
+ ACCESS ANALYZE +
カウンター 無料
seo 相互リンク 無料YouTube高速バス 予約
+ ADVERTISE +
 
スポンサーサイト

一定期間更新がないため広告を表示しています

- | | - | -
I can "BACK TO THE FUTURE" !
さっき、明日のブラウザ天気予報に追記したところで、ふと思ったこと。

ブログって、過去も未来も書き抜けることができる。

どういうことかというと、過去に書いたモノを修正/訂正することも、削除/抹消することもできるということ。

例えば、明日から自分が書いた競馬の本が売り出されるとして、本の宣伝も兼ねてブログを開設する。
で、見所や、書き足りなかったことなどを書く。
そして、過去の競馬の勝ち負けを、実際には着順予想さえしていないのに過去の日付で予想したように書く。
当然、過去のことなので当たっている。
「予想がいっぱい当たった=書いた競馬の本はよく当たる」と宣伝する。
この例は競馬を株式に置き換えてもヨシ。

例えば、ある技術の動向や、ある大企業の次の戦略について、半年後ぐらい先を予想して書く。
で、予想が外れだしたら、書いたモノをコッソリ書き直す。表示されている日付は当時のまま。
最後に、「予想が当たった!あちきってばグレイト!?」などと大々的にPINGを打つ。
タイミングが揃えば、一躍人気サイトとして注目される。

とまぁ、後出しジャンケン的なことが出来そうだなと。

もちろん、こんなことでメリットがあるようには思えないけど、もっともっと賢い人がもっともっとすごいことを考えるのは世の常で、どこかで既に何か起きているのかもしれない。

ということは、逆に「これは当時書いたままの状態です!」とか「ここの部分だけ訂正しました!」とか、「正式な追記です!」と証明したい人もいるのでは。

さーて、どうしたものか…。


  • 修正していないことを証明したい

  • おそらく書いたテキストはデータベースやファイルとしてサーバに保存されている。このテの入出力は修正の場合でも普通はDELETE(REMOVE)してADD(WRITE)なので、ADD(WRITE)の日時を情報として埋め込めればいい。この日時が最終更新日時だ。
    これはサーバが証明してくれる。

  • 修正箇所を証明したい

  • 実は修正箇所を表示してくれるJavaScriptがある。
    …。どこで見たっけ…。忘れた!
    そのJavaScriptはボタンで修正履歴を表示したり非表示にしたり出来るモノだった。
    この修正履歴は書いた内容にそのまま埋め込まれるので、今のところは何かを証明できるワケではないけど、ブログの機能としてこういうのがあればいいワケで。

  • 追記であることを公表したい
  • Internet Archiveで前後の変化を見るという技もあるかもだけど、高頻度で追記されると、アーカイブがついて行けない。
    じゃあ、署名を使おう。
    最初に文章を書いた時に、「日時」と「文字数」と「適当に抽出したいくつかの文字」を使ってハッシュ化された署名を付ける。
    で、追記したら「日時」と「文字数」と「追記した文字」でハッシュ化された署名を付け足す。
    署名から、どこが追記か証明できる。


ふーむ。いいかも。
この署名方式は、インターネットセキュリティ界隈では使い古された方法だけど、ブログ内容に適用するのはおもしろそうじゃない?

あとで考えれば、署名に埋め込むことが出来るハッシュ値が大きければ、文章を丸ごと証明できるので、上記3点の証明をまかなえる。

ちなみに、ハッシュにしたのは署名の偽造を防ぐためで、ハッシュ化されて表示されてる署名とたった今ハッシュ化した署名を比較して、内容に変化があるか、あるならどんな変化かを判定させるということで。

よろしく!

続きを読む >>

ブログ内に他サイトのRSSを表示
ブログ内のサイドバーに他サイトのRSSを表示できるようにしてみた。

で、ついでにJUGEMカスタマイズ講座の「記事内容」の一部を隠すを参考にして、伸び縮みするようにしてみた。

ま、いいんじゃないかな。
JUGEMだけじゃなく他のブログでも有効なので、汎用性は高い。


表示位置を変更できる部分は自分に必要なかったので、修正してない。
気になりだしたら修正する予定。

ボタンを▼とかじゃなく、画像にしてみようかな。
<button>タグにしてみるのもありかな。

JUGEMをnslookupでいじってみる2(メンテ障害)
今回もすごかったJUGEMのメンテ。

2004/10/03 Sun 02:00〜14:00

20:00

23:00

2004/10/04 Mon 01:00

08:00
と終了時刻アナウンスが延びていった。

いったい何のメンテナンスなんだ!?
終わったことだけはわかるけど、
今回の事態を深く反省し、今後の運営において適切な作業計画の立案と効率的な
作業の進行を心掛け、ユーザーの皆様にご迷惑をお掛けすることが無いよう努め
てまいります。
毎回言ってませんか?(#-_-)

さて、事前アナウンスでは、
【メンテナンス内容】
・データベースハードウェア増強
・データベース処理向上
・プログラム修正
と言っている。

前回の様子から何が変わったかわかるかなーと調査してみることに。


うち(momoch.jugem.jp)を正引きしてみると、
look momoch.jugem.jp ... foundin 200410041200
Name : momoch.jugem.jp (.JP | Japan)
Address : 210.172.160.47
210.172.160.49
210.172.160.46
210.172.160.50
210.172.160.61
1台増えてるー!(笑)
ハードウェア増強って、台数を増やしたってこと?
ちなみに210.172.160.61の逆引きは不可。

まぁ、これぐらいの作業ならあんなに遅延することはないはず…。

さっきのメンテ情報には
・データ保全に最善を尽くし、検証を重ねながら作業を行った
・作業終了時間について事前の検証が不足していた。
・使用予定のハードウェアに一部障害が発生した。
・作業を行う過程で、プログラムの修正作業が発生した。
とあり、210.172.160.61かどうかはわからないけど、新サーバで3項目の障害が起きたと思われる。

眠っていた新しい機器をいざ動かそうとするときによく起こる障害で、ハードウェアベンダのサポートで即交換。
もし既に設定を流し込んでいて、リリース直前に障害が発生した場合、再度流し込んで検証する必要が出てくる。
作業者は冷や汗モンでしたね。お疲れさまです。

前回、間違って確認したrelease.jugem.jpは台数が増えてない。
look release.jugem.jp ... found
Name : release.jugem.jp (.JP | Japan)
Address : 210.172.160.46
210.172.160.49
210.172.160.47
210.172.160.50

なんでだー!?と思ってもう一回momoch.jugem.jpを確認すると…
look momoch.jugem.jp ... found in 200410041400
Name : momoch.jugem.jp (.JP | Japan)
Address : 210.172.160.50
210.172.160.46
210.172.160.47
210.172.160.49
わずか2時間の間にサーバが減った!
返せ!(w

まだ作業中なんだろうなぁ…。


release.jugem.jp
staff.jugem.jp
ともに変化無し。

じゃあ、次はHTTPヘッダね。
210.172.160.61も確認。
210.172.160.46
HTTP/1.1 404 Not Found
Date: Mon, 04 Oct 2004 05:07:41 GMT
Server: Apache/1.3.31 (Unix) PHP/4.3.8
Vary: Host
X-Powered-By: PHP/4.3.8
Last-Modified: Mon, 04 Oct 2004 05:07:34 GMT
Content-Type: text/html
X-Cache: MISS from 210.172.160.46
Connection: close

210.172.160.47
HTTP/1.1 404 Not Found
Date: Mon, 04 Oct 2004 05:08:08 GMT
Server: Apache/1.3.31 (Unix) PHP/4.3.8
Vary: Host
X-Powered-By: PHP/4.3.8
Last-Modified: Mon, 04 Oct 2004 05:08:02 GMT
Content-Type: text/html
X-Cache: MISS from 210.172.160.47
Connection: close

210.172.160.49
HTTP/1.1 404 Not Found
Date: Mon, 04 Oct 2004 05:08:18 GMT
Server: Apache/1.3.31 (Unix)
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Last-Modified: Sun, 03 Oct 2004 12:07:24 GMT
Accept-Ranges: bytes
Content-Length: 1674
Content-Type: text/html
Connection: close

210.172.160.50
HTTP/1.1 404 Not Found
Date: Mon, 04 Oct 2004 05:08:37 GMT
Server: Apache/1.3.31 (Unix) PHP/4.3.8
Vary: Host
X-Powered-By: PHP/4.3.8
Last-Modified: Mon, 04 Oct 2004 05:08:26 GMT
Content-Type: text/html
X-Cache: MISS from 210.172.160.50
Connection: close

210.172.160.61
HTTP/1.1 403 Forbidden
Date: Mon, 04 Oct 2004 05:09:08 GMT
Server: Apache/1.3.31 (Unix) PHP/4.3.8
Content-Type: text/html; charset=iso-8859-1
Connection: close
と出た。

微妙に違うのが210.172.160.49で、
Server: Apache/1.3.31 (Unix)
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
Content-Length: 1674
はあるけど、
Server: Apache/1.3.31 (Unix) PHP/4.3.8
X-Powered-By: PHP/4.3.8
X-Cache: MISS from 210.172.160.*
はない。

おそらくリバースプロクシサーバかクラスタの親サーバ(負荷分散制御サーバ)ってところじゃないかと。

momoch.jugem.jpのヘッダーは、
HTTP/1.1 200 OK
Date: Mon, 04 Oct 2004 05:47:13 GMT
Server: Apache/1.3.31 (Unix)
Pragma: no-cache
Last-Modified: Mon, 04 Oct 2004 01:31:11 GMT
Accept-Ranges: bytes
Content-Length: 51258
Content-Type: text/html
Connection: close

前回と比べると、
HTTP/1.1 200 OK
Date: Wed, 15 Sep 2004 02:16:57 GMT
Server: Apache/1.3.31 (Unix) PHP/4.3.8
Pragma: no-cache
Last-Modified: Wed, 15 Sep 2004 00:55:33 GMT
Accept-Ranges: bytes
Content-Length: 44825
Content-Type: text/html
Connection: close

Content-Lengthは無視するとしても、PHP/4.3.8の表記がない。
これって、並列だったはずのシステム構成が変わったってこと!?

うーん…。

レスポンス速度を上げるために、素のApacheを親サーバにしたのはわかる。
でもPHPが入っていないとなると、子サーバに情報を引き継ぐ一時的なサーバとなる。
であれば、負荷がかかるはずのusersサーバを増やすべきでは?

も、もしかして…。
いや、一瞬ではあったけど、正引き結果に210.172.160.61が見えてたことからすると…。
まさか…。

このシステム、負荷によって動的に構成台数が変化する??
普通、ブレードサーバとか使うはずだけど、ieiriブログ情報では、ラック内に1Uサーバが縦に並んでた。同じ構成の1Uサーバを増やしてソフト的に分散させてるのかな…。


とーとつにName Scanした。

2004/09/15 Wed2004/10/04 Mon
210.172.160.33 : search.jugem.jp
210.172.160.34 : mysql0.jugem.jp
210.172.160.35 : jugem.jp
210.172.160.36 : cocan.jugem.jp
210.172.160.37 : mail0.jugem.jp
210.172.160.38 : users0.jugem.jp
210.172.160.39 : balancer0.jugem.jp
210.172.160.40 : manage.jugem.jp
210.172.160.41 : users1.jugem.jp
210.172.160.42 : users2.jugem.jp
210.172.160.43 : mysql2.jugem.jp
210.172.160.44 : aclog.jugem.jp
210.172.160.45 : kaela.jugem.jp
210.172.160.46 : users3.jugem.jp
210.172.160.47 : users4.jugem.jp
210.172.160.48 : mysql3.jugem.jp
210.172.160.49 : mysql4.jugem.jp
210.172.160.50 : users5.jugem.jp
210.172.160.51 : not resolved
210.172.160.52 : not resolved
210.172.160.53 : lolipop0.jugem.jp
210.172.160.54 : lolipopsql0.jugem.jp
210.172.160.55 : lolipop1.jugem.jp
210.172.160.56 : lolipopsql1.jugem.jp
210.172.160.57 : staging.jugem.jp
210.172.160.58 : dispatch.jugem.jp












→dns0.jugem.jp
(変化なし)
(変化なし)
(変化なし)
(変化なし)
→images0.jugem.jp
→mysql1.jugem.jp
(変化なし)
→zeus0.jugem.jp
→admin0.jugem.jp
→not resolved
(変化なし)
(変化なし)
→users0.jugem.jp
→users1.jugem.jp
→images1.jugem.jp
→users2.jugem.jp
→users3.jugem.jp
→images_db0.jugem.jp
→not resolved
→lolipop0.jugem.ne.jp
→lolipopsql0.jugem.ne.jp
→dispatch2.jugem.jp
→mysql2.jugem.jp
(変化なし)
→dispatch0.jugem.jp
210.172.160.59 : admin1.jugem.jp
210.172.160.60 : nfs0.jugem.jp
210.172.160.61 : not resolved
210.172.160.62 : dispatch1.jugem.jp
210.172.160.63 : db.diary.ne.jp
210.172.160.64 : cnt.diary.ne.jp
210.172.160.65 : ping.diary.ne.jp
210.172.160.66 : backup.diary.ne.jp
210.172.160.67 : img.diary.ne.jp
210.172.160.68 : www.diary.ne.jp
210.172.160.69 : www2.diary.ne.jp
210.172.160.70 : www3.diary.ne.jp

ぎゃーー!!
いっぱい変わってる…。無茶しすぎじゃないですか?
あのアナウンス時間でこなそうと思ったらタイムアタックになりそう…。
んじゃ、ひとつひとつ見ていってみる。

210.172.160.33 : search.jugem.jp→dns0.jugem.jp
たぶんこのsearchって、昔あったjugem.jpドメイン内サーチサーバでしょ。
ブログ内サーチしかなくなった今、無駄になったサーバを再利用してDNSサーバにした様子。
Whoisには
[Name Server] dns0.jugem.jp
[Name Server] dns1.jugem.jp
とあり、dns1はjugem.jp(210.172.160.35)の別名。

210.172.160.38 : users0.jugem.jp→images0.jugem.jp
users0は使ってなかったから、画像用のサーバに生まれ変わった。画像用のサーバってmysqlnじゃなかった?
いずれimagesnに統一するんでしょ。

210.172.160.39 : balancer0.jugem.jp→mysql1.jugem.jp
欠番だったmysql1が登録。やっぱりロードバランサ(負荷分散制御)は無くなった模様。もともと機能してなかった(うまく動かせなかった)。

ここから下は結構変わってるので一気。
210.172.160.41 : users1.jugem.jp→zeus0.jugem.jp
210.172.160.42 : users2.jugem.jp→admin0.jugem.jp
210.172.160.43 : mysql2.jugem.jp→not resolved
210.172.160.44 : aclog.jugem.jp
210.172.160.45 : kaela.jugem.jp
210.172.160.46 : users3.jugem.jp→users0.jugem.jp
210.172.160.47 : users4.jugem.jp→users1.jugem.jp
210.172.160.48 : mysql3.jugem.jp→images1.jugem.jp
210.172.160.49 : mysql4.jugem.jp→users2.jugem.jp
210.172.160.50 : users5.jugem.jp→users3.jugem.jp
210.172.160.51 : not resolved→images_db0.jugem.jp
210.172.160.52 : not resolved
210.172.160.53 : lolipop0.jugem.ne.jp
210.172.160.54 : lolipopsql0.jugem.ne.jp
210.172.160.55 : lolipop1→dispatch2.jugem.jp
210.172.160.56 : lolipopsql1→mysql2.jugem.jp
210.172.160.57 : staging.jugem.jp
210.172.160.58 : dispatch→dispatch0.jugem.jp
ふわ〜。
なんだzeus0って!!!
あと、images_db0ができてる。

images0やimages1がimages_db0から画像を呼び出す仕組みと思われる。増強するときはimages_db1とか増やして参照させればいいと。分散DBサーバだったら増強は簡単のはず。
利用者が使う46、47、49、50はそれぞれusers0〜3に。管理しやすくなったのでは。
lolipopn.jugem.ne.jpって何だろう。
今回、2台がjugem.jpドメインへ変更された。使ってないサーバだったのかな。
210.172.160.62 : dispatch1.jugem.jp
を含めて、dispatchサーバが3台に。ポートを長時間占有するアップロードに耐えられるようになったのかな。

こういう増強は、増強後の予想が難しい。増強後に問題が解消したかどうか。


まとめ
・ハードウェア故障は不可抗力。ただし、元からあるサーバを他の用途に転用したものは新サーバと呼ぶべからず。
・DNSサーバを建て増したのは評価アップ。
・工数の見積もりに無理がある。余裕をもってやるべし。長時間の停止よりも、時間が読めない停止の方が不評。できれば平日の深夜から始めるべし。休日は利用するよ。憎まれるより応援されるようになるべし。


あ、昨晩、勢いに任せて2chに書いたモノを残しておこうっと。加筆して誤字も訂正して。
355 :Trackback(774) :04/10/03 23:36:13 ID:NAFjVreI
1.テスト機で検証(チェックリスト作成/工数見積もり)
2.本番作業日の調整・アナウンス
3.本番機サービス停止
4.本番機作業前フルバックアップ
5.本番機作業開始(チェックリスト使用)
6.本番機テストユーザのみサービス開始(検証)
7.本番機作業後フルバックアップ
8.本番機サービス解放

※5や6で問題(作業遅延/障害など)あれば作業中断して4をリストア。PLが判断。
※作業後はDNS強制配信をかける。

〜初歩的なありがち事項〜
・時間が読めなくて延びてしまいがちなのは4と7。
 →一時待避領域やバックアップメディアの確保を忘れないように。
 →データ量から算出した予想時間は当てにしない。実際に計測すること。
・ついつい5で業者作業とSE作業をいっぺんにやってしまい、障害時に切り分けがつかない。
 →作業は別の日にやること。
 →ハードウェア補強とセキュリティアップデートは、利用者の空気を読んで優先順を決めること。
今回、ソフトウェアのアップデートがあったかどうかわからない。MySQLはアップデートされたかもしれない。ApacheとPHPはそのままのようだ。


最後に、もういちどmomoch.jugem.jpを正引き。
look momoch.jugem.jp ... found in 200410041600
Name : momoch.jugem.jp (.JP | Japan)
Address : 210.172.160.46
210.172.160.49
210.172.160.47
210.172.160.61
210.172.160.50
増えたーーー!!(w
もうわけわかんない。

続きを読む >>

JUGEMをnslookupでいじってみる
最近、JUGEMブログが重い。
突然のメンテ、朝6時頃のバックアップ象さん。どーゆー運用してればこうなりますか?

ちなみにうち(momoch.jugem.jp)を正引きしてみると、
look momoch.jugem.jp ... found
Name : momoch.jugem.jp (.JP | Japan)
Address : 210.172.160.47
210.172.160.46
210.172.160.49
210.172.160.50
何度も正引きすると、46と49と50の出てくる順番が変わる。ふーん…。

情報リリース(release.jugem.jp)を正引きすると、
look release.jugem.jp ... found
Name : release.jugem.jp (.JP | Japan)
Address : 210.172.160.50
210.172.160.46
210.172.160.49
210.172.160.47
一緒じゃん!(#-_-)
ということは、「重いなー、どうしたのかなー」と思って見ようとしても、同じサーバなので見ることができない。
なんじゃそら。

あ!

情報リリースはrelease.jugem.ccだったっけ。
look release.jugem.cc ... found
Name : release.jugem.cc (.CC | Cocos (Keeling) Islands)
Address : 202.222.28.197
うんうん、これなら別サーバだから見ることはできそう。
ちなみに、IPアドレスが違う=別サーバと考えてみてます。

JUGEM開発日誌(staff.jugem.cc)も、情報リリースと同じサーバ。
look staff.jugem.cc ... found
Name : staff.jugem.cc (.CC | Cocos (Keeling) Islands)
Address : 202.222.28.197
よしよし。

じゃあ、さっきの自分を正引きしたときのIPアドレスは何だろう。
逆引きしてみた。
210.172.160.46 : users3.jugem.jp (.JP | Japan)
210.172.160.47 : users4.jugem.jp (.JP | Japan)
210.172.160.49 : mysql4.jugem.jp (.JP | Japan)
210.172.160.50 : users5.jugem.jp (.JP | Japan)
usernってのはみんながブログを共通して使ってるサーバなんだろうなぁ。たぶんVirtual Hostか。
mysql4ってのが混じってるなぁ。
ま、いいや。

それぞれのサーバのHTTPヘッダを見てみると、
HTTP/1.1 403 Forbidden
Date: Wed, 15 Sep 2004 02:12:30 GMT
Server: Apache/1.3.31 (Unix) PHP/4.3.8
Content-Type: text/html; charset=iso-8859-1
Connection: close
どれも全部同じ。

ただし、momoch.jugem.jpのHTTPヘッダは
HTTP/1.1 200 OK
Date: Wed, 15 Sep 2004 02:16:57 GMT
Server: Apache/1.3.31 (Unix) PHP/4.3.8
Pragma: no-cache
Last-Modified: Wed, 15 Sep 2004 00:55:33 GMT
Accept-Ranges: bytes
Content-Length: 44825
Content-Type: text/html
Connection: close
ApacheのVirtual Hostデーモンが返してきたモノかな。
Last-Modifiedが最近変わってる…。まだ調整は続いているのね。

ところで、地獄変00さんの地獄変00〜一億円めざすぞにある「JUGEMのレスポンスヘッダーを見てみる」の記載。
まず、旧JUGEMのシステムを使っているJUGEM開発日誌レスポンスヘッダーをば。

Apache/2.0.49 (Unix) PHP/4.3.3

ふむふむ。Apache/2.0系。

次に正式サービスでのレスポンスヘッダー

Zeus/4_3

おおお、Zeusという神々しい名前に!……って、キヌガサ同じWebサーバですね。移行前のアナウンスにあったβテストから正式に変わると驚くほど快適になりますというアナウンスはWebサーバソフトの変更をさしていたんでしょう。

まあ、今回の騒動は移行プログラムのバグということなのでZeus云々は関係ないだろうけど。今つながらないのはDNSの問題だし。

ただ、データ消失は気になるなぁ。完全復旧ができないようなデータの壊れ方って、何なんだろう?データベースのバックアップとかもないのかな?
まず、ZeusってのはApacheと互換性があり、しかもレスポンスがいいらしいWebサーバソフト。Apacheと違い有償。

キヌガサは確かにZeus。
でも、今、JUGEMはApache。

Webサーバソフトの載せ替えに失敗した!?
しかも、その作業の過程で他のユーザのログが消えてしまったのであれば、かなりお粗末。

他のサーバもあるだろうと思って、適当にIPアドレスを見繕って逆引きしてみた。
210.172.160.33 : search.jugem.jp (.JP | Japan)
210.172.160.34 : mysql0.jugem.jp (.JP | Japan)
210.172.160.35 : jugem.jp (.JP | Japan)
210.172.160.36 : cocan.jugem.jp (.JP | Japan)
210.172.160.37 : mail0.jugem.jp (.JP | Japan)
210.172.160.38 : users0.jugem.jp (.JP | Japan)
210.172.160.39 : balancer0.jugem.jp (.JP | Japan)
210.172.160.40 : manage.jugem.jp (.JP | Japan)
210.172.160.41 : users1.jugem.jp (.JP | Japan)
210.172.160.42 : users2.jugem.jp (.JP | Japan)
210.172.160.43 : mysql2.jugem.jp (.JP | Japan)
210.172.160.44 : aclog.jugem.jp (.JP | Japan)
210.172.160.45 : kaela.jugem.jp (.JP | Japan)
210.172.160.46 : users3.jugem.jp (.JP | Japan)
210.172.160.47 : users4.jugem.jp (.JP | Japan)
210.172.160.48 : mysql3.jugem.jp (.JP | Japan)
210.172.160.49 : mysql4.jugem.jp (.JP | Japan)
210.172.160.50 : users5.jugem.jp (.JP | Japan)
210.172.160.51 : not resolved
210.172.160.52 : not resolved
210.172.160.53 : lolipop0.jugem.jp (.JP | Japan)
210.172.160.54 : lolipopsql0.jugem.jp (.JP | Japan)
210.172.160.55 : lolipop1.jugem.jp (.JP | Japan)
210.172.160.56 : lolipopsql1.jugem.jp (.JP | Japan)
210.172.160.57 : staging.jugem.jp (.JP | Japan)
210.172.160.58 : dispatch.jugem.jp (.JP | Japan)
なんだかいっぱい引けた。
manageとかstagingとか、内部用じゃないの?
balancer0がロードバランサだとしても、名前を付けて公開しなくてもいいのでは。うーん、さすが無料サービス!
数万のユーザを抱え、それ以上のアクセスに耐えるバランサが1つしかない!
まさか、ね。

jpユーザは210.172.160.46、210.172.160.47、210.172.160.49、210.172.160.50を使うらしい。
momoch.jugem.ccで正引きしても同じ。
昔から使ってるccユーザのIPアドレスを知りたいところ。
情報求む!!

kaelaはKaela★Blogらしい。誘致してブログを書いてもらっている有名人らしい。
てことは、もしかして他のユーザと環境が違うのでは…。
調べてみた。HTTPヘッダだけど。
HTTP/1.1 200 OK
Date: Wed, 15 Sep 2004 02:34:19 GMT
Server: Apache/2.0.49 (Unix) PHP/4.3.3
X-Powered-By: PHP/4.3.3
Content-Type: text/html; charset=EUC-JP
Connection: close
…。
PHPのバージョンが4.3.3で古い。2003/08/25リリース。4.3.8に至るまで、結構バグフィックスされてますよ?
Apacheは2.0.49か。
大丈夫?
いいの?
とはいえ、1.3.31も危ないですが。

続きを読む >>

ブログ内RSSリーダ
サイドバーにインラインフレームを埋め込んだ。
登録してあるニュースサイトや、RSSがランダムに出るようにしてみてる。

  • サイト登録はあんまり多くても困る。

  • 一定時間で表示を切り替えたい

  • Googleニュースを出したい。


  • ココを参考にしてます。

    JUGEMで働いてみませんか?
    JUGEMでアルバイトを募集しているらしい。

    うーん、おもしろそうだなぁ。。

    家賃が払えていけるんだったら、今のところを辞めてそっちに行くのもいいのかも。

    忘れた頃に募集してみよう。

    続きを読む >>

    指令:オススメ商品紹介の強調表示を撃破せよ
    オススメ商品紹介機能(RECOMMENDとか表示されているところ)は、JUGEM側管理の別のCSSファイルとかで設定してあるようで、リンクがデフォルトで<strong>強調されている。

    かなり読みにくい。

    フォントサイズを10pxから11pxへ変更した上で、CSSの実際のところを参考にしつつ、
    .linktext .amazon_text strong {
    font-weight:normal;
    }
    を追加。

    (自己満足的に)JTに公開してみたいけど、うちはAmazonとbk1のアフィリエイト用リンクを強制的に張っているので無理かなぁ…(x_x

    CSS講座 テンプレートを作ってみようvol.02
    カスタマイズの肝、CSSのちょっとした講座「テンプレートを作ってみようvol.02」。
    早速取り入れようとしてみるが…、講座、間違ってる!?

    とりあえず、写真の枠ってのは実際のポジっぽくていいかなと思い、取り入れてみよう。

    講座の例文

    .entry_des img{
    background: #fff;
    border-top: 1px solid #ccc;
    border-left: 1px solid #ccc;
    border-bottom: 1px solid #666;
    border-right: 1px solid #666;
    float: left;
    margin: 0px 10px 5px 0px;
    padding: 5px;
    }


    少なくともうちには.entry_desなんてクラスJUGEM独自タグは使ってないので、.entry_bodyとは別にimgタグ専用に
    .entry_body img{
    background: #fff;
    border-top: 1px solid #ccc;
    border-left: 1px solid #ccc;
    border-bottom: 1px solid #666;
    border-right: 1px solid #666;
    margin: 0px 10px 5px 0px;
    padding: 5px;
    }

    としてみる。

    うん、よしよし。

    細かな設定はこちら参照。
  • HTNLクイックリファレンス

  • とほほのスタイルシート入門
  • 続きを読む >>

    テンプレート
    ここ何日か、記事も書かずにスタイルシートと格闘した。
    うーむ。まだ納得はいかないけど、とりあえずストップ。

    納得いかない点、お困りの点:

    ・tDiaryやはてなのテンプレートを参考にできたらなぁ…。tDiaryからの移植は今度挑戦。必要な要素を事前に抜き出しておくこと。

    ・オススメ商品紹介のリンクは<strong>が仕込んであって太い!ヤダ! コレはテンプレートをいじっても無理。開発日記のコメントに書いたらちょっとは考えてくれるだろうか。


    今日はお盆明けまで来ないと思われたペリカン便(amazonで買ったCD)の不在通知が入っていたこともあり、トレンドマイクロのふざけた発表に対応するためのバージョンアップ作業完了を火曜に延ばせたこと(だいたいさぁ、8/10に8/16にサポート終了&一部はパターン960までで更新しなくなるなーんて、もうちょっと早く言うべきと思うよ?)などによりちょびっと早く帰ってきた。


    …。
    日通のWeb再配達申し込みに「遅い時間に持ってきて」って書いたけど、19時〜22時の指定で19時30分に持ってきて不在票を入れたあげく、20時に電話したら「もう集配センターに戻ってしまいました。また明日。」って…。やる気出していこうよー、日通さーん。

    Copyright (C) 2004 paperboy&co. All Rights Reserved.

    Powered by "JUGEM"