人気ブログランキング | 話題のタグを見る

PHP開発日記

tomo板にも書いたけど、何しろこのPHP。何か適当に「こんな感じ!?」って書いてみたら動いちゃうのが素晴らしい。何となくVB6のあの適当ぶりを思い出す。かと思えば、割とOO的なコードも許すし、当然継承もできるわけだから高性能。ちと中途半端さもあるが、充分以上に実用可能だねこれ。

現在、投稿用掲示板に特化したCGI作成中。tomo板はネタスレやる分にはいいけど、投稿板としてはやはり参照がダルい。そこで特化版のCGIに移行しようという寸法。

…というわけで設計と製造を始めてるわけだが…

以下は設計中のメモから拾った留意点。


DBがXREAだと5Mしか使えないらしいので、ログをテーブル保存するわけにはいかない。…ってことを対応しようと思うと結構設計に制約ができてきて面白く無い。結局モデルを六個くらい作れば回せそう…ってことになった。

板の設定情報を保存するconfig用テーブル。<これファイル管理すると面倒なのだ。
SSのジャンルごとに大項目として画面わけたいから、ジャンルメタデータテーブル。
作品・またはスレッドのメタデータテーブル。
ログ一件ごとのメタデータテーブル。
ユーザ管理情報テーブル。<投稿用のスレッドはスレ主以外書き込みできなくする為
その他まぁ処理用テーブルは幾つか作ることになるぽ。SQLはソート下手に自分でロジック組むより速いし。とりあえず必須のテーブルだけちゃんとモデリングした。


知り合いの投稿掲示板で使ってるPHPでは、何かテーブル山のように使ってて、容量既に3MBとかいってた。投稿掲示板としては残り2MBでログを…というのは正直厳しい。スレ四本分しかない計算だもんね。圧縮して保持すると、今度は圧縮解凍の処理コストが重すぎる。だからDBで管理するものは各種画面のメタ的な情報のみとし、ログをテキストで持つ方式に設計することにした。スレッド一つアクセスする為にファイルを沢山オープンすることになるけど、試してみた感じ超高速だったからマトモなPCスペックなら問題なさそうだった。

基本指針として、出力系よりも管理画面の充実を優先することにする。これは他の色んな無料公開CGIに共通して、何か使いづらい&機能足りないと思うことが多いから。もうカナリの部分まで後から弄れるようにしたい。スレッド・ログの削除機能とかは当然つけるし、アクセス解析機能とか参照回数とか、後環境変数から得られる情報は全部分析用に保持していくような仕組みを考える。特にアクセスログを残すのは大事。荒らしから身を守るほうが、荒らすことよりもずっと難しいから。

アクセスログ完備すれば.htaccessを利用したアクセス制限機能(要するに荒らしはホストごとBANしちゃう)も運用し易くなるし、どちらかと言えばdeny from allで全弾きしといて、特定優良ホスト(プロバイダ直か、またはアクセスログ要求したら出してくれるトコ)のみ通すような仕組みが望ましいなぁ。書き込みに認証を儲けるつもりだけど、ユーザ登録に制限はつけたくないので結局地道なホスト収集が掲示板自衛のキモになる。 ・・・と、思う。まぁ、アクセスログ収集しとけば許可すべきホストのリストはすぐに出来上がるだろう。これでほぼ串対策は完璧。

ただし正規プロバイダで、串必須なタイプのものがある。CATVなどの中味がLANなネットワークだ。この串対策は環境変数からとってきた値で判定して、一つでも串に該当するものがあれば書き込みエラーが出るようにすりゃいいかと考えている。CATVユーザの切捨てとなるが、特定ユーザはノーチェックで通すというような設定項目を設けておけば、個別で対応できるはず。例えばユーザIDがtomotanで、パスワードが1234って奴が書き込みしようとした場合は串チェックはスルーする…というロジック。あぁ、管理画面の項目が山のようだ。実際のとこは、こう言う管理コストは削減したいんだが…荒らし対策って難しい。

生IPで荒らす度胸があるならソレはもう仕方無い。敬意を表してログをプロバイダと警察にメールするってことで。

と、言う所まで設計して、設計に飽きた。とりあえずDB共通ルーチンを作成。実際に動かしてみたくて、管理画面を作ってみる。おぉ、快速! プロセス一個一個立ち上がってるperlとは大違いだ。PHPってセション管理持ってるし、実はスレッド動作なんだろうか? よくわからん。

ユーザ管理機能を実装する。
・ユーザ一覧参照
・ユーザ更新
・ユーザ登録
・ユーザ削除
上記の4機能実装してみた。上手く動く! DBアクセスは心配するほどのボトルネックは無く、むしろ予想外なほど軽い。更新系もゴリゴリ動く。最大で同時に10回UPDATE文のコールが発生する作りなんだが(だって一件一件更新とかダルいしな。せめて画面に出た奴は同時に弄れないと…) うーん、軽い。10UPDATEなんか瞬時に終わる。負荷どれくらい耐えるかわからんけど、常識的に考えてもPOSTがそんな無茶苦茶発生するはずがない。2chじゃないんだし。つーかmySQLなめとった。使いやすいRDBじゃん。

管理画面のデザインはCSSでガッチリ作った。脱tableタグと言うことで。本番の掲示板機能も同じように作ろう。
CSSって便利だなぁ。後でどうとでも弄れるもんね。これも編集できるような機能つけよう。
・・・どんどん設計が膨れていくなぁww

と、言う所まで進んだ。次はジャンル管理機能とスレッド管理機能とログ管理機能だな。これらは基本似たよーなもんだから一個型作っちゃえば全部それを継承したクラスと言う形で表現できるはず。違うとこだけオーバライド。うーんOO的! インタフェースが無いのが残念だが、まぁ困るほどのモンでもない。

 つか徹夜しちったよ。寝るぽ!
# by tomo_otonasi | 2005-02-27 07:24 | PHP/CGI関連

死の行進の解決はまだまだ不可能だと思う理由

今をときめくIT業界(最近は実情がバレだしている)で普通にエンジニアやってる私は、今まで大小様々なプロジェクトに関わって仕事してきている。この職種、海外では知らないが日本では作業がほぼ確実に遅延し、そして一人当たりの残業時間をクソ増やして物量的にその遅延を解決するよう志向すると相場が決まっている。この程度が酷いといわゆるデスマーチと呼ばれる状態となる。今の私の現場も、人としてどうかと思う稼動率で吐き気と戦う毎日である。

あるブログで、「楽しんでいるから苦にならない」とか書いてあって心底ゲンナリした。きっとこの人はメイクを担当することが多いのだろう。羨ましいことである。しかしプロジェクトを十メートルの長さの一本の紐に見立てると、コンピュータ技術者の白眉でありエクスタシーなメイク工程なんか1メートルにも満たない。本当のプロフェッショナルがやらないと意味がない超上流工程を除けば、残るのはドキュメントの整備と飽くなき無限のテスト地獄に故障対応の永久ループである。これを楽しめる人はほとんどいない。そこではExcelとWordのリテラシこそ最も大事なスキルとなる。後は業務知識。コアな電脳知識やマニアックなスキルは全く必要ない。むしろ、そう言うのに特化している人は業務に置いては邪魔である。(よりよい設計・仕様は必ずしも顧客要件・システム要件に合致しない。今からそれをやれば工期が遅れる=納期に間に合わない=金にならない。往々にしてスキル自慢はそこを理解せず、愚痴る。とってもウザい。じゃあ最初からやれよ!下流工程に何でもかんでも押し付けやがって!!)

とは言え、このクソ稼動――――日、12時間を普通に越える――――は、何とかしないと健康に関わる。特に精神的な。月間で300時間を越えると脳味噌の中で変な唸り声を上げる虫が住んでるような気がしてくるというのは定説。それでマネジメントの本なんかを読むわけだが、これが何とも机上の空論チックで納得いかない。そもそも社内政治の力学が全ての原因であり、これは理想では解決できないんだから。しっかりとマネジメントを行えば間違いなく出来ない子が恨む。有耶無耶にならないから、出来る奴が酷く不公平に扱われる危険が高い。感情とモチベーションはマネジメントでは解決できないのではないか? 定量的な評価を辞めたところで、出来る新人が出来ない上司の上に立つということに現実性が乏しすぎる。それは人間としての感情を度外視した理論であり、マシーンの言葉だ。日本的で無さ過ぎるので、日本では恐らく根付かないだろう。

だから、専門的にマネジメントを行うことができるコンサルタントは外部の人間でなくてはならないと強く感じる。しかし、外部のコンサルを雇うにはエンジニア三人分くらいの金が掛かる。そんな予算が下りないデスマーチが最初から確定しているようなプロジェクトは一体どうすればいい?

結局エンジニアが身体を張るしかないのだ。大体、絶対的な時間と技術の不足があった場合の解決にならないし。そんな仕事は受けてはいけない、と言うと、会社は潰れるのだから。会社は自然淘汰されまいと足掻くものであり、それを問題視されようとも飯食う為には仕方無い。どんな無茶な顧客でも、デスマーチやれば金になるなら、企業はやるのである。

つまり、デスマーチは現状はどんな学問でも解決できない。その前に発注者・受注者ともに意識改革が必要であり、意識が改革された後で提示されないとマネジメントは意味が無いと思う。そんでもって、発注者の意識改革は後20年は無理っぽい(日常的にマシンに触れる世代がトップでないので、最終的な判子を突くのは常にジジイだ。あいつ等死ぬまでは無理)と言う風に私は諦念を抱く。

根本的な解決策は一つだけだ。業界やめちまおう。これだ!!
# by tomo_otonasi | 2004-11-06 13:59 | 雑記

あぁ・・・ 疲れてる最近マジでマジで

Lighter

第二号発刊。11月号ってことになるな。

でも、俺の一次はのっけれんかった。月中の更新になるぽ。うぬう、いそがしすぎんだよ薄給なのに。。。

今回、丸居氏(中の人はMARたんだ)が参加することになった。彼もまぁ大体二ヶ月前くらいから暖め続けてたネタで攻めてきてるんでさっすが面白いぜ!

どうやらブレイドマインが一番人気。俺の話、反響ゼロw でも、何かリアル友が知らない間に読んでて俺に話振ってきてビビったよ。ここもみられてんのか? 何だかなぁw
# by tomo_otonasi | 2004-11-02 00:15 | 雑記

anyone サイトをおもくそ改装

もう、むしろ新装開店。

 ずっと謎だったスタイルシートって奴を真面目に解析して、ビルダーでやる方法調べて、サイトをめっさ改装しまくりました。つーか、既存作品のHTML以外全作り直し。シンプル伊豆ベスト! な感じの踊り子的サイトに。エリス!エリス!

 最近激しくアクティブ。秋だしね。気温が下がらないとモチベーション上がらないんだよね。

 投稿板が段々にぎわってきた。ぬるぽスレもageとくか。なんつーの、投稿板でありながら2ch的なテンション込みってのがうちの売りだしねぇ。それで引く人はうちのサイトに来てくんなくてもイイヤ。だって、サイト特色みたいなもんだし。
 何か初めから良作が集って来てて、非常にいい感じ。これで客が増えれば最低系と呼ばれるモンも増えてくるんだろうけど、それはそれで構わんしー。売りになるのがあれば別に良いのだ。そんでもって俺は自分のSSに傲慢に自信持ってるしな!!げてげてげて

 このブログも雑記に特化するので、後で改装しよう。


TM板批評スレにて

『エヴァは歴史長すぎネタ枯渇し過ぎで本編準拠って言葉すら形骸化してる』
『その感覚を持ち込んで欲しくないな』

 こんな会話を見つけた。コレおかしくない?
 だって、テキストに置いて大事なのは原作への敬意だの愛だのよりもそもそも「面白いのか、否か」じゃないかと俺は思うのですよ。本編準拠してようがしていまいが、面白ければ有りでしょう。余りにも自分設定満開で原作無視しまくりの1.3次創作は九割方クソという真理はあるにしても、原作準拠していないことが悪だとすればその線引きは一体誰がやるの? そんなの読む奴の嗜好次第で、普遍的な閾値の設定は不可能だと俺は思う。
 なので、面白いの書けば、嗜好が合う人にはどんなもんでもアリだろー。そこの匙加減もまた、二次創作作者の腕の見せ所と言えるのではないかにゃー?
# by tomo_otonasi | 2004-10-03 17:53 | 雑記

打ち上げ

Lighterをようやく立ち上げて、やったぜベイベーってことで創刊準備号面子で集って打ち上げ的なことをやったよ。

会場は俺んち。千年雨はもう何度か来てるからいいんだが、五十六に関しては初だ。いきなり小汚い犬小屋じゃ失礼過ぎということで蝶掃除したサ。フェフェフェ。

とりあえず三人で酒飲んだ。五十六は用事があるってことで途中で帰ったが、すんごいくだらない話しかしなかったねぃ。青木さやかがキモイって話題とか。(<蝶どうでもいいw)何かもうCGIとかCSSとか禁句禁句。打ち上げなんだから何も考えずにテレビのバラエティーにゲタゲタ笑って、どうでもいい話して、いやぁ、まぁなんつーか久々に頭空っぽですたワ。



Lighterに掲示板設置。カウンタ設置。クソダルかった(´Д`) そのままじゃ使えないからそれなりに手を入れるわけで…コレがメンドイ。まぁ自分で全部作るよりマシだけど。
Blogみたいに異常に時間かかるようなことは無かった。何かCGI周りの知識ちょっと溜まってきたから今度自作してみよう。

Blogで手一杯だったので、上記のようなCGI系のものが全く足りてなかったので、設置しまくる。後何が必要かな? もう大抵揃ったと思うがどうか。創刊準備今日でようやく整ったって感じかなぁ。BBS、tomo板みたいな内輪的な感じじゃなくて、もっと広い範囲で使ってもらえるといいんだけど。みんな良かったらなんか書いてね~

初日2000人来てくれてたが、昨日は大体400~500? リピーターが四分の一かー。ありがたいこった。でも、孤島志向なthe one for anyoneやこことは違って、ちょっくら拡大志向で真面目にやる気なので、一次創作LINK系に登録とかその辺もやってみた。かおぱらさんと、HONなびさんに登録。小説大好きさんに更新チェック依頼出した。
どうかなー一杯来てくれるとイイナー(´∀`*)

いやぁ、運営者ってのもなかなか楽しいもんよ?
# by tomo_otonasi | 2004-09-20 05:53 | 雑記