mieki256's diary



2003/04/17(木) [n年前の日記]

#1 hns導入で未だ四苦八苦

hns導入で四苦八苦してるので巡回もできず。思ったとおりの動作状態も実現できず未だ日記公開も出来ず。

#2 [pc] 気温25℃での自宅サーバ電源ファン音

気温25℃近辺。階下に降りたら自宅サーバの電源ファン音量が大→小→大を繰り返していて驚いた。Y氏から戴いたこの電源って静音電源だったのか。だとしたらめっちゃ嬉しい。ありがとう!>Y氏。でも…もしも静音電源じゃなかったらどうしよう。その場合、どうして電源ファン音が変化してるのか、考えることすら怖い…

電源ファン音以外が騒音の原因 :

自宅サーバはかなりの騒音を出しているのだけど、電源が静音電源だったとすると、騒音の原因は電源ファン以外にあるということになる。一応、CPUクーラーは、ヒートシンク大きめ、FAN回転数若干少な目のモノに交換したはずなので、CPUファン音が騒音の原因であるとはちょっと考え難い。とするとHDD駆動音が原因ということになるが、しかしサーバ機の前面、HDDが置かれているはずの前部分に覆いを被せてもそれほど騒音は減少しない感じもする。すると一体、どこが騒音の原因になっているのだろう。

ファンレスPC :

騒音が気になり始めると、なんだかファンレスPCが欲しくなってくる。しかしファンレスPCはまだ結構高いし。中古ノートPCをサーバ機にしてしまうほうがコスト面では現実的かもしれない。もっとも中古ノートPCは大容量のHDD増設が難しい。それともSCSI増設等導入すれば手軽に増設できるのだろうか。それはそれでコストがかさみそう。

この記事へのツッコミ

Re: 気温25℃での自宅サーバ電源ファン音 by Y(笑)    2003/04/18 23:21
多分静穏電源では無いのでは・・・(汗)
なにぶん貰い物のケースに付いてたモノで一度も動かした
事が無いシロモノで電源のスペックは不明なんす(笑)
型番とかで調べればわかるのかなぁ・・・
自宅に転がってる350WのP4対応電源よりも2倍位重かった
のでそんなに悪いモノでは無いとは思いますけど。

変なの送りつけちゃいましたですね(汗)
Re: 気温25℃での自宅サーバ電源ファン音 by mieki256    2003/04/19 00:36
( ̄□ ̄;)!! な、な、なんですとー!?

…いや、しかし…
つい先ほども、HDDへのアクセスが激しくなった後に電源FAN音が大きくなって
「おお、内部の温度が上がったから風量を増やしたのか。賢いヤツじゃのう」
と感心してたのですが…すると一体これはどういうこと…ミステリーだ…

もしかすると、特に「静音」ってわけではない電源も、
最近の電源であれば温度によってFANの回転数が変わるのが当たり前…
なんてオチがついたりはしないものでしょうか。
電源云々は全然詳しくないのでそのへん全く把握してないんですよ>自分

なにはともあれ、そのうち折をみて、ケース開けて型番を確認してみます。
FAN回転数の調整機能がついてくれてたなら嬉しいが、はたして…
Re: 気温25℃での自宅サーバ電源ファン音 by Y    2003/04/19 21:52
http://terasan.okiraku-pc.net/dengen/no02/

型番を調べてみると↑のモデルのようでした。
Re: 気温25℃での自宅サーバ電源ファン音 by Y    2003/04/19 22:06
http://www10.tok2.com/home/ko1/okiraku/mypc/pclife09.htm

やっぱり可変FANのようですね。
Re: 気温25℃での自宅サーバ電源ファン音 by mieki256    2003/04/20 19:03
おお。そちらで型番を把握してたのですね。
助かります。ケースを開けずに済みました。
お手を煩わせてしまってスミマセン。

なるほど、やはり可変ファンでしたか。安心しました。やはり賢い電源だ…
こんな良さゲな品を送って戴いて嬉しいです。ヒデキ感激<ヒデキって誰よ?

件のページには「音がうるさい」と書かれていたので、ちょっと驚きました。
さすがに無音ではないものの、以前使ってた電源に比べると遥かに静かなので。
前の電源はよほど酷い電源だったと言う事なんだろうか。
しかしこれで「うるさい」という評価なら、
最近の静音電源ってとんでもなく静かなのだろうな。むぅ。
Re: 気温25℃での自宅サーバ電源ファン音 by Y    2003/04/22 21:55
FANの回転数が高くなると音が大きくなるみたいですね。
そゆ意味では低消費電力PCだと静かなのですないでしょうか。
Re: 気温25℃での自宅サーバ電源ファン音 by mieki256    2003/04/24 09:43
なるほど、電源単体では駆動音の大小については評価できず、
システム全体が絡んでくると…
そういう意味では、余りモノパーツでサーバ機を用意した事が
功をそうしているのかも、ですかね。
ウチのヘボサーバ機に対する評価がちょっと変わったかも(爆)

#3 [hns] hns+mod_rewrite

mod_rewriteについて色々記述を変えてみたところ自分の環境では以下のように .htaccess に記述する事で yyyymmdd.html の形でアクセスができるようになった。本来は yyyy/mm/dd.html の形でできるといいのかもしれないけど、hns関連ファイルに対して相対アドレスでのリンク指定ができるように改悪してしまった関係上、動作させてるとフォルダ階層がどんどん深くなってしまう。なので yyyymmdd.html でお茶濁し。もちろん .pmや.phの各修正部分も %year/&month%day.html を %year%month%day.html といった形で変更。
RewriteEngine on
RewriteBase /~username/diary
RewriteRule ^([0-9][0-9][0-9][0-9])([0-9][0-9])([0-9][0-9])([0-9]+)\.html /~username/diary/index.cgi?$1$2$3S$4 [NE,T=application/x-httpd-cgi,L]
RewriteRule ^([0-9]+)([[abc])\.html /~username/diary/index.cgi?$1$2 [NE,T=application/x-httpd-cgi,L]
RewriteRule ^([0-9]+)\.html /~username/diary/index.cgi?$1 [NE,T=application/x-httpd-cgi,L]
動いてはいるものの、自分はタコ初心者なので誤った mod_rewrite 指定をしてる可能性大。

tDiaryでも同様 :

検索してたら、 _tDiaryは既にこの手の対策を打っていた ことを知る。headline部を横に表示する為のCSS指定 *1 の件といい、tDiaryは随分進んでる。日単位ではなくて記事毎 *2 にコメントがつけられるなら絶対にtDiaryを導入するところなのだけど。

*1: もちろん、CSS指定では無い、従来のtable利用によるレイアウトは、CSSにまともに対応していないブラウザ上でも問題が起きにくいというメリットがあるわけで。その代わりtableの内容が確定するまで本文が表示されないというデメリットもあるけど。
*2: hnfで言えばNEW毎。

#4 [hns] そろそろ一段落。ひとまず日記として公開できるかな

yyyymmdd.html 形式でのアクセスもできるようになったし、これでひとまず日記ページとして本サイトからリンクできそう。まだ一部の過去ログについてはリンクが未修正の部分もあるけれど。

他のコンテンツ :

結局、他のコンテンツについては今まで通りgeocitesに置く事になりそう。自宅サーバにページを置くと転送速度が遅いから表示されるまでに時間がかかるし。conf/rlink.txt に本サイトのURLを記述して RLINK でリンクしておけば後から修正するのも容易だろうし。

リンクがまだ変 :

あー、LNEW指定のURLが404に。修正が必要みたい。まだダメか。

#5 [hns] このページが読みづらい

なんか本当にページが読みづらいなぁ…何がマズいのだろう。試しに左のHeadline部分の背景色を濃くしたり、各記事のタイトル部分を少し薄くしてみたり。でもなんか違う。

#6 [hns] カテゴリ分けについて

カテゴリ分けで悩む。重なってるのがあるから。例えば本来、「hns」は「pc」とも重なるし「web」とも重なる。細かくカテゴリ分けの単語を用意するのも考えものかも。

分類分けの手法 :

こういった分類分けは、人間が手作業でやっていくしかないのもツライ。YahooとGoogleの違いとでもいうか。hnsで言えば、カテゴリ分けはYahooだし、Namazu for hns は Google かな。

山田さんと木下さんが :

_山田さんの偏平足悪化理由や木下さんの宝くじに当たった理由 は知る由もないけれど *1 、自分の場合、hns導入によって打ちこむ文章量が増えたみたい。キータイプ量増加は、自分の場合、主にカテゴリ分け機能の存在によるところが大きい。今までは「記録を残すなら別ページ・別コンテンツにしないと、そもそも記録に辿りつけない」と思考が働きブレーキになっていた。それが、「後からカテゴリ別にタイトルを出して容易に目的の情報を見つけられるから、ひとまずダーッと打ちこんでおこう」といった感じになって歯止めが利かなくなりつつある。

カテゴリ別表示 :

となれば、カテゴリ別に本文を列挙して表示する機能があると更に利便性は向上するかもしれないけど、その場合の各日付を表す数値自体は何ら関連性を持たないわけで、はたして関連性の無い日付数値の羅列を元にした本文列挙は現状のhnsでどの程度実現性があるのだろうと。もっとも自分の場合Sleipnirを使ってるので、カテゴリ別タイトルを表示→全選択→「選択部分のリンクを開く」で一応の目的は果たされる。そう考えると、hnsにそれら関連機能を盛り込む必要性はさほどないのかもしれない。

*1: 一晩中作業した後の明け方に件のページを眺めていたら、思わずニヤニヤしてしまった。どうやら脳が疲れて末期的状態に陥ってるらしい。そろそろ休憩をとらないと。

#7 [hns][web] 欲しい機能

やはりいくつか機能が欲しい。

本文の折り畳み :

やはり最新の日記ページ表示時には本文の折り畳みがあると嬉しい。一応左側のheadline部分にカーソルを合わせると同様の内容がポップアップはされるけど、たぶん気づかない人が大半だろうし、そもそも逐一カーソルを合わせていくなんてうっとおしい。headline.cgiの改変で同種の処理ができそうな気もするので余裕があったら試してみたい。

<a herf="〜" taregt="_blank"> :

LNEW,LINK指定で、target属性も指定できないか。現在は強制的に、全てのリンクを、<a href="" target="_blank"> としてしまったけど。本当は、「自分の日記ページに対するリンクは現在開いているウインドウ内に表示」して、 *1 「URLが 'http://' から始まるもの、つまり自分のサイトではないページへのリンクは別のウインドウを開いて表示」されるようにしたい。 *2 おそらく target="xxxx" も指定しながらリンク指定ができるコマンドを別途作ってしまうほうが楽に対応できそう。

リンク先ページをどう開くか :

Webページを読む場合、リンクに target指定が無いと、
  1. ページの中にリンクが出てくる。
  2. リンクをクリック。
  3. リンク先ページを表示。元のページは消える。
  4. 読む。(この時点では内容は大まかにしか頭に入ってない。)
  5. 元ページへ戻る。リンク先ページは消える。
  6. 読み進む。
  7. 読んでるうちに先ほど開いたページの内容を確認したくなる。(確認しなければ現在読んでるページの文意が理解できない為。)
  8. ページをスクロールさせてリンク箇所を探す。
  9. リンクをクリック。
  10. リンク先ページを表示。元のページは消える。
  11. 内容を確認すべき個所をスクロールして探す。
  12. 読む。
  13. 元ページへ戻る。
  14. さきほどまで読んでた箇所をスクロールして探す。
  15. 読み進む。
  16. 7へ戻る。
といった感じで実はかなり面倒臭い。
それに対して、リンク先を新しいウインドウで開けば、上記の流れのうち「スクロール」云々の作業が激減するし、クリック一つで二つのページの表示を切り替えられる事で、ページを行き来しつつ内容を読み進める事がさほど苦ではなくなる。
つまり、リンク先を新しいウインドウで開くかどうかの指定が出来ると、著者側の働きかけで閲覧側のストレスを軽減する事が可能になる。故に、target指定が出来ると良いのではないか、と思うのだけど。

もっとも、自分の場合はタブブラウザを利用している為に、ウインドウを新たに発生させる事に抵抗を感じていないという側面もある。これがもし、IEなどの非タブブラウザを使ってる人間であれば、ウインドウが新たに開くというだけでストレスを感じる可能性が高い。

だが、そもそも上記のように、その閲覧行為の流れをはっきりと意識すれば、とにもかくにも一つのウインドウ内でページ表示が切り替わっていくことが、実はかなり不便で非合理的な使い方であることも理解してもらえるのではないか。何より、タブブラウザに人気がある現状が、上記のような面倒臭い閲覧手順が既に過去のものであることを実証している。

と思ったけど、リンク先を新しいウインドウで開くかどうかは本来ユーザが自由に選択すべき事項のような気もする。IEの場合、単にShiftキーを押しながらリンクをクリックすれば新しいウインドウで開くのだし、タブブラウザであれば大抵はマウスボタンのどこかに「新しいウインドウで開く」を割り当てる事が出来る。

…やっぱりtarget指定は無くそう。新しいウインドウで開きたい人は各々自分で開いてくれ、という事で。

*1: つまり、<a href="〜"> という指定。target属性指定が含まれない。
*2: つまり、<a href="〜" target="_blank"> という指定。

#8 [web][xyzzy] xyzzyのtipsサイトが閉鎖していた

.xyzzy の hnf 用設定を修正しようと、普段参考にしてるtipsサイトにアクセスしたらサイトが閉鎖してた。

今まで為になる情報を公開してくれていた事には大変感謝しつつも、なぜ「最近更新してないから」などという理由になってない理由で閉鎖するのかと若干怒りにも似た感情すら覚える。古かろうが更新されなかろうがそこに情報が置いてあるだけで充分価値のある事だし、閲覧者達に取っては役に立っている。なのにどうして「価値のないサイト」と自分一人で誤った評価を下し情報を無頓着に消去してしまうのか。閉鎖するぐらいなら放置してほしい。放置する姿勢が恥ずかしいというならコンテンツをzipで固めるなりして「古い情報です」と明記して置いておくなりすればとりあえずの体裁を保てるのではないか。せめて閉鎖するまでの猶予期間ぐらいは設けてほしいものだが。

閲覧者達にも問題があるのか :

もしかすると閲覧側にそもそも問題があるのかもしれない。「更新してない」状態をさほど深く考えることなく「悪である」と評価を下しているのは、やもすると閲覧側に多かったりはしないか。もしそのような評価を下しているなら悔い改めるべきだろう。「Webは更新されるもの」などという無意味な思い込みを他者に強制することで、価値あるサイトを次々と閉鎖に追い込んでいるなら、そういった閲覧者こそWebから真っ先に去るべき存在ではないか。 *1

情報の価値 :

そもそも情報に優劣などないと自分は考える。
更新されている情報は価値があり、更新されていない情報は価値が無いのか。それでは「源氏物語」は存在する価値の無い情報だろうか。けして更新される事の無い印刷物に掲載された各種文章は須らく価値の無い情報なのだろうか。
自分にとって有益ではない情報は全ての人間にとって価値が無いのか。文学を専攻する人間にとって数学書はおそらく価値のない情報だが、だからといって数学書は世界から消去すべき存在であると言えるのだろうか。

その情報が、いつ、どこで、誰の役に立つか、それは誰にもわからない。故に、情報に対して誰もが絶対的な優劣などつけられないはずもない。であれば極力それら情報は残しておくべきだろう。失った後でやはり必要だったと悔いても遅い。

なのに何故「更新してないから」の一言で情報を消去できるのか。どうして「更新してない」だけで「サイトを閉鎖すべき」と主張ができるのか。「更新してない」事や、「情報として古い」事が、情報の価値自体を貶めると考えているなら、それはまるで、 _人類の貴重な文化遺産を爆破して回った連中 と同じ思考だろう。そんな思考や主張をする事で一体何の得があるのか。

情報の優劣は評価できないが、情報の有無に対しては誰しもが評価を下せる。0か1か、nilかtか、falseかtrueか、有るか無いかは、絶対的な事実だ。そして、無いよりは有った方がいい。たとえそれが誤った情報、古い情報であったとしても、無いよりは有る方がいい。有りさえすればそこから次の情報が産まれる可能性が出てくるからだ。それら情報に対し誤りを見つけた人間が、新たにサイトを立てるなり掲示板等で情報交換するなりして、新しい情報としてWebに提供していけばいいだけの話。全ての情報をtipsサイトの管理人が追い続け更新する義務などどこにもない。

皆、もっと無責任にサイトを放置すべきだ。無責任に放置する行為こそが、情報を公開した者にとって、真に責任ある行為だ。サイトを閉鎖し情報を消去する事はけして責任ある行為ではない。勘違いしてはならない。1だったものを0にする行為のどこが責任ある行為か。情報を消去する事こそが本当に無責任な行為であることを、情報を公開する者であれば強く認識しておくべきではないだろうか。

要するに :

まあ要するに、これはと思った情報を見つけたらとにかくローカルに保存するしかないね、って話でしかないのですが。GetHTMLWで件のサイトを丸ごと保存しておけば良かった。大失敗。

ていうかWiki導入すれば :

問題解決じゃないかと思った。導入作業はちと大変かもしれないけど、運用が始まってしまえば「最近更新していないから」なんて閉鎖理由は過去のものになる。なぜなら閲覧者が「これは有用」と思ったtipsをどんどん追加してくれるから。管理人は何もしなくていいし、更新してない云々で責められることもないし、いいことづくめじゃないか。

*1: 「更新してほしいな」と望む発言と、「更新してないなら閉鎖すべき」と発言する事は全然違いますので念の為。

#9 [hns][xyzzy] xyzzy用なんちゃってhnf-mode

嘆いていてもアレなので、件のサイト管理者への若干の抗議の意味も込めつつ、xyzzy用のなんちゃってhnf-mode(hnf-mode.l)を公開してみたり。といっても、どれもこれもxyzzyのtips関連サイトからコピペしてきて少し弄っただけ。為になる情報を数多く公開してくれてる先輩方に大感謝。 _hnf-mode20030417.zip

機能 :

機能は以下の通り。
  1. 当日(あるいは、x日前、x日後)のhnfファイルを開く。新規作成時はテンプレートファイルの内容が自動で挿入される。
  2. 現在開いてるhnfファイルを基準に、C-PageUp,C-PageDownで、昨日 or 明日のhnfファイルを開く。
  3. hnfコマンドに対して色付け表示をする。
  4. 特定フォルダ以下でファイル新規作成をした際、必ずeuc,lfにする。
これだけ。ショボ。
自分の場合、ファンクションキーに「当日のファイルを開く」関数を割り当ててる。ファンクションキーを叩く→Enterを2回叩く、で当日のファイルが開いてちょっとだけ快適。

emacs用のhnf-mode.el :

を触ってみればhnf-modeにどんな機能が必要なのか理解できるかもしれないけど、hnf-mode.elをすぐさま動かせる環境を持ってないので今一つわからず。どんな機能があると便利なのだろう。

ftpupdate.lは便利 :

_ftpupdate.l を導入してファンクションキーあたりに割り当てると、hnfを記述→C-x C-sで保存→ファンクションキーを叩く、で即座に該当ファイルをサーバに転送できてhns更新作業終了、なので楽ちん。ftpupdate.lの作者様に大感謝。ただし、ftpupdate.l はバイナリモードで転送するようなので、hnfファイルをあらかじめeuc,lfで作成しておく必要がある。ので、特定フォルダ以下でファイルを新規作成するとeuc,lfにしてしまう関数もhnf-mode.lにコピペしてあったり。もしかすると環境によっては機能がダブってしまうかもしれないので注意。

色付け表示はいい加減 :

hnfコマンドに対して正規表現で色付け表示してるけど、自分が頻繁に利用するコマンドにしか対応してなかったり。本当は、パラメータ数が違っていたら赤で表示、とかしてみたかったのだけど、いざそういった修正を加えようと、頼りにしていたxyzzyのtipsサイトにアクセスして参考文献を見ようとしたら閉鎖していてガックリのシオシオでショックがデカかったわけで。登ってる最中に梯子を外されてしまった。

こういう状況に度々遭遇している自分としては、
「貴方が思っている以上に、貴方のサイトはただ公開してるだけでも、たとえ放置してるだけだとしても、充分に価値があるんです。その場の気まぐれやマイナスにしかならない思い込みで閉鎖しないでほしいのです」
と強く言いたいわけで。タコ初心者の自分にはどんな情報もありがたい。貴方がゴミ箱に放り込んだそのファイルも私にとっては喉から手が出るほどの宝物に見える。頼むから閉鎖しないでください。お願い。

以上、1 日分です。

過去ログ表示

Prev - 2003/04 - Next
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

カテゴリで表示

検索機能は Namazu for hns で提供されています。(詳細指定/ヘルプ


注意: 現在使用の日記自動生成システムは Version 2.19.6 です。
公開されている日記自動生成システムは Version 2.19.5 です。

Powered by hns-2.19.6, HyperNikkiSystem Project