循環注水冷却

トラブル続きで大変だね。世間は、東電の管理の甘さを非難する声が大きいようだけど、20日時点で、あと１週間で溢れると言われていたのだから、多少の不具合には目を瞑っても稼動させるべきなんでしょ。
まあ、いろいろ文句は言われるのを承知の上の判断なのではないのかなぁ。

あちこち直すのは、とりあえず１万トンくらい処理してからでいい。それまでは、のらりくらり言い訳してやりすごすのが、懸命なやり方だと思う。

Ajax と cookie

某所でのこと。

phpで作っていて、ログインもセッションも管理していて、安全に作ってあるはずのシステムが、AJAX関連の呼び出しが無頓着なせいで、そこからデータが筒抜けという状態が露呈。

たぶん、ajaxで呼び出すときに cookie をキチンと渡していないのだろう。デフォルトでは勝手に渡してくれるのだっけ？

まあ、他山の石です。

静的なページ (その2)

以前作っていたこちらのページも、ページの生成を、べたのphpから、symfonyベースのものに変更。
ORM(Object Relatinal Model)に合わせて、データベースの構成を少しばかり修正する。

こちらのサイトは、試作的なこともあってデータベース操作を生のSQLで操作していたのだけれど、doctrineのadmin generatorを使うと、通常の管理程度ならこれだけでほぼ間に合いそうだ。
(もちろん、痒いところには手が届かないけれど、定義したrelationを反映した画面を自動で生成してくれるのは、なかなかすごい。)

データへのアクセス方法を考えると、もう少し索引を作成した方が効率がよさそうなのだけれど、スキーマ定義に反映させる方法がまだよくわからない。
まあ、静的なページに変換してしまった後はデータベースの効率は関係なくなってしまうわけだけれども。

ホームページを直さなくちゃ。 (その4)

結局、drupal はやめて、symfonyで全部書き直し。
(細かい部分を除けば)デザインは、drupalの時のを継承しつつ、中身は symfonyに移した。

たいして複雑なことをしているサイトでもないので、コンタクトフォームとブログを置き換えるくらいの手間ですんだ。ま、symfonyの手習いを兼ねてといったところ。

ファイルの転送をするときに、rsyncが使えないのは、ちょっとつらいかも。

drupal ( その12 )

結局、node_access 表が、壊れていたようで、
insert into node_access values ( 0,0,'all', 1, 0,0 );
で、アクセス関連の不具合も解消した(ようだ)。

なぜ、このデータが欠損したのかははっきりしない。
プロバイダのサーバーがバージョンアップしたのと時期が一致するので、データベースの内容を移すときにプロバイダが移し損ねた疑いが強いのだけれど、もう時間が経ちすぎているので検証しようがない。

drupal ( その11 )

drupalの不調の原因が少しわかった。

一つは、キャッシュの問題。これは、キャッシュをクリアすれば改善する。
もう一つは、PRIMARYキーの auto increment属性の問題。これは、どうも、dump/restoreの過程で落とされてしまったらしい。

で、この二つの対応をしたところ、鬱陶しい警告メッセージはほとんどでなくなって一見よさそうに見えるようになったのだけれど、まだアクセス権限関連が少し変なまま。
アクセス権限関連の不具合は、上のauto incrementが原因で設定ファイルを更新できていなかったのだけれども、それは今は直っているはず。でも、まだおかしい。

drupal ( その10 )

drupalもそうなのだけれど、結局 CMS に対する不満というのは、デザインが固定化してしまうということと、データの使いまわしが難しいということなのだろう。

統一されたレイアウトでサイト全体の統一感が得られるというのは CMSの利点のうちの大きなものなのだけれど、それが逆に欠点にもなってくる。drupalの場合はすべてのページが node という概念で統一されているので、それ以外の部分は、blockにしろ何にしろ、表示するかしないかくらいの選択肢しかない。
それ以上のことを望めば、残りをすべて非表示にして、その中でカスタマイズするしかない。

デザインの制約は結局、どのサイトも似たような印象になってしまう結果になる。(勿論、フルカスタマイズする気ならいくらでも見た目を変えることは可能だけれども、それはCMSの方向とは違う方を向いているように思う。)

データの使いまわしについていえば、単なる blog であれば、大抵の blog間で import/export ができるのが普通なのだけれど、なまじすべてのデータが node 扱いなので、データを exportしようと思うと、まず blogに対応するnodeを選択するところから始めなくてはいけない。データベースを直接操作することになる。
あまりカスタマイズしていない状態なら、大した手間ではないとはいえ、汎用の処理ではないので、変換処理のバグ取りなどをしないわけにはいかない。クリック一つでexportできるといった簡便さからはほど遠い。

まあ、出来合いのものを使うのと、自分で全部作るのとの、作業量の兼ね合いなんだけどね...