kanonji's tumblelog

漫画家の漫画が当たるでしょ。僕のせんせがそうだった。

馬鹿当たりして、家まで買う事になる。
人気爆発の先生だと、編集者が家まで探して、ローン組むの。
家買わせると、ロ－ン払わなくちゃいけなくて、言う事を
より、聞くようになるから、都合がいいんだ。
サルまんにも同じような話があったけど。

でも、漫画家が、編集者より良い生活をしだすと、
やっぱり人間だから面白くないんですね。
中卒に、一流大学出が、生活水準で負けると面白くない。
こんどは、「なんかヘマやったら、野郎、面白いめにあわせてやる」とか
考え始めるんじゃないですか。

人気作が終了し、次回作に失敗すると、
「できるだけ悲惨な放り出し方をしてやる」とか思うみたい。

どうするかというと、簡単な話で、
甘い言葉で「次回作に期待してます。新しい作品、出来たら持ってきてください」
と言う。で、何を書いても、没にする。

「ウチじゃ、もう駄目だから、よそにいけ」なんて、絶対言わないですよ。
タチの悪いのは。
それらしい事言って「次に期待してます」の連打をする。何度も何度も。
「よそにいけ」なんつうと、まだ成功作のネームバリューで
漫画家に商品価値があるから、その時点で他所に取られると損するの。

だから、「いい感じですが、もうひとつ」の繰り返しで、
馬鹿な漫画家に期待させつつ、駄目だしを永遠に繰り返す。
漫画家はローンかかえて、ますます必死。駄目駄目駄目・・・・。

そのうち、必ず、その漫画家はぶち壊れます。

何描いたらいいのか、わかんなくなる。
そうしたら、放り出す。
担当も異動。ある日突然。

「もう、僕、ファッション誌だから」

漫画家は完全に壊れます。精神も家庭も、肉体的にも。
仕事場は、とっくに解散されてますが。

編集部は
「まあ、時代と合わなくなったからしょうがないよな」で終了なんでしょう。

そういうことを散々やって、笑い話のように話してた編集を
知ってます。

漫画家にも、編集者にもドロドロの怨念があるんですよ。
世間知らずの中卒、高卒と、
一流大学出たインテリの、埋められない溝も深いし。

「漫画家なんて、檻のなかの羊。おれたちは羊飼い。
家畜なんだよ、お前は。わかってんの？」
な～んて、あかるく話す正社員もいますから。

「漫画が好きで、漫画家目指してきて、ここまできて、そんなこと言われるなんて。
ちょっと言い過ぎでしょう！」
「そんなの芸能界と同じだろ。何処が悪い。当然じゃねえか。
ガタガタ言わずに当ててみな。」

そういう世界ですね。
理屈とか、あんまり通じない。

普通のビジネスの世界も、こんな感じなんでしょうか。
会社員やったことないから、よくわかんないです。
個人事業主とか、取引先とか・・・。
そんな世界じゃ、全然ないですよ。僕が馬鹿なだけかも。

441 名前： せんたくやくん(東北地方)[sage] 投稿日：2008/06/09(月) 12:40:27.16 ID:H3iAMUgn0
硫化硫黄で自殺すれば、入浴剤を規制し
ネットで情報が流れれば、ネットを規制し
サバイバルナイフで殺せば、ナイフを規制し

原因とはとことん向き合わないんだなこの国は。

趣味でやっている人のことは、まあ、いいとして（踏み台にされる可能性はあるけど）、仕事でPHPを使うときの注意を書いておこう。

コーディング規約を守る。組織にコーディング規約がないなら、Zend Framework PHP標準コーディング規約 [zend.com]を使う。オレ流コーディングスタイルは禁止。
内部コードにはEUC-JPかUTF-8を使う。入出力もできるだけShift JISを避ける。Shift JISを使う場合には2byte目に0x5Cを含む文字の動作を忘れずに確認する。
開発環境の警告レベルをE_STRICTにする。本番環境ではdisplay_errorsをオフにする。
register_globals、magic_quotesはオフにする。
type hintingを積極的に使う。
スコープの長い配列をクラスでラップする。
プレゼンテーションとロジックを分割すること。プレゼンテーションには変数または関数の出力とループ以外のロジックを残さないこと。ロジックの中で直接出力をしないこと。ロジックはSimpleTestを使って単体テストすること。
SQL文に変数を埋め込むときにはプレースホルダを使う（PDOのprepareとbindParams）。
リクエストから取得したパラメータを出力するときはhtmlspecialcharsを使う。
関数が長くなったら分割する（composite methodパターンを使おう）。
グローバル変数を使うのは避ける。
変数を定数として使わない。定数はdefineで定義するか、const宣言する。
常に最新バージョンでテストできる環境を作り、サービスイン後もバージョンアップに対応するための予算をとっておく（サービスイン後にお金をかけたくないなら、PHPは避けるべき）。
継承を使うなら、クラス図くらいは書いておく（単にコードを再利用したいだけなら、移譲を検討すること）。
各URLにおけるパラメータとその閾値を文書化すること。パラメータの閾値の境界線についてソースレビューし、テストすること。
既存のフレームワークを学習することに投資すること（学習コストを嫌って自己流のフレームワークを作ることは、バグを作りこむことになるのでかえってコスト高になる）。
PHPしか使えない作業者の成果物はこまめにレビューすること。
設計を重視すること。
コピー＆ペーストプログラミングの匂いを発見したら、そのコードを書いた人にプログラミングの基礎を教えること。
リファクタリングの時間をスケジュールに入れること。
require/includeを条件文や関数宣言の中に記述しないこと。
PHPに限らない話も多いけどね。PHPを採用するときって「期間」「人材」が理由になることが多いけれど、それらの問題を解決できるほどPHPは素晴らしいものではない、ということは知っておいてもいいんじゃないかと。百戦錬磨の腕利きたちがいるとき、期間を短くするためにPHPを使うのはいいでしょう。人材不足でPHPができる人しか揃わないときは、PHPしかないですよね。でもね、両方の場合はプロジェクトを断念する方が間違いないです。未熟なプログラマーでも素早くWebアプリケーションを十分な品質で作れる方法なんかないですから。