しばらく前に英語圏で好評だった、Nick Lewisの The Road to Drupal Hellの一部邦訳。面白いし、結構役に立つので。
ついでに、こんな感じでDrupalの失敗談なんかもコメント欄で共有しましょう。うまく行かなかったプロジェクトから学べる事は多いので。
===========
地獄に、Drupal開発者専用の新たな層が誕生
(PRWeb) -- 先週Drupalコンテンツマネージメントシステムは、オープンソースCMSとしては、独自の地獄の層を持つ最初のCMSになりました。多くのプロプライエタリのCMS、特にVignettは、独占的な地獄を持つ事で知られていましたが、今回の出来事はオープンソースのCMSとしては初めてです。
アクマベンチャーズのスポークスマン、ヴィンセント・ペンドラグーン氏によると、この層の対象者は「全般に経験が浅く無精だったり、自分を過信している、APIなどに興味を払わない開発者」とのこと。地獄がオープンソースに新たな重要性をもたらすか、という質問に対するペントラグーン氏の答えは、「地獄は単に、オープンソースが与え得る不幸を受け止めているだけです」。
ヘルズ・グローバルマーケティングおよびサポートチームは、Drupalのみが提供する特別な層を「訪れたい」と願う開発者のためのFAQを作成しています。
FAQ
Q:Drupal開発地獄とは何ですか？
A:Drupal開発地獄とは、地獄の他の階層とは異なるものです。地獄のほとんどは炎や氷、毒蛇や毒グモ、鎖や鋭利なカギ針などで構成されています。Drupal開発地獄とは、特定の設定およびコードの組み合わせの結果もたらされる精神状態を指します。
Q:コスト（代償）はどのくらいですか？
A:あなたの永遠の魂です。
Q:Drupal開発地獄に堕ちるためには、PHP, MySQLやCSSを知る必要がありますか？
A:もちろんそんなものは不要です！地獄の全ての部分、年齢、性別、人種、国籍、知識を問わずは全ての人に開放されています。ただ、我々の調査データが示すところによると、Drupal開発地獄のほとんどを占めるのは、開発者、デザイナー、プロジェクトマネージャー、クライアントです。
Q:いいですね。どうやったら地獄に行けますか？
A:そんな質問が来るとは思いませんでした。魂は雪の結晶のようなもので、二つとして同じものはなく、堕ち方も千差万別です。我々のマーケティングチームが、開発者、デザイナー、プロジェクトマネージャー、クライアント向けに案内書をご用意しましたのでご覧下さい。
Drupal地獄への行き方
開発者がDrupalプロジェクトを地獄へ送る方法トップ１０
1.自由にDrupalコアや寄贈モジュールをハックする。Drupalのテーマレイヤーは絶対に活用しない。最高の成果を得たいのであれば、データベースおよび整然と並ぶincludeファイル、モジュール、テーマ等がどのように機能するかについて理解するのを避けること。
2. 絶対にapi.drupal.orgで関数を検索しないこと - 数あるAPIの中に、ひとつたりとも有用な関数なんて無いことは、懸命な人であれば誰でも知ってること。
検証済みかつ完璧に統合された関数の数々を上級プログラマーが提供していたって、自分自身で複雑かつ一回限りの関数さえ書ければ問題ない。それよりも、最高の結果を得るには、関数なんて使わない事。そして、それらをモジュールになんて入れるのは絶対にダメ。
3. Drupalまたは寄贈モジュールのチェックアウト時に、絶対にDRUPAL-[x]タグ（xは最新stableバージョン）を使わない。だってCVSには新しい機能が取り揃えられているからね！
4. tpl.phpファイルに、多くのスクリプト、 SQLクエリー、JavaScriptを詰め込む努力をする。もちろんこれらをモジュールやtemplate.phpに入れる方が簡単だけど、プロは絶対に簡単な方法なんて採用しちゃいけない。
5. Drupalのコードがあなたに歯向かうとき、絶対にコードを理解しようなんてしないこと。コードが歯向かうときは、あなたはそれを全力でねじ伏せなければいけない。できれば、理性に欠ける回避法や、他のモジュールから一部のコードまとめて消すのなんかが好ましい。
6. 自分に挑戦する - 関数名、変数名、CSSのidやclassにテキトーな名前を付ける。ここでの秘訣は、異なるidや変数に同じ単語を使いつつも、アンダースコア、ハイフン、大文字、時勢、複数形の使い方に変化を加えること。例えば、ノード内に"node-page"というクラスを作り、それを"node-page"というidで囲み、さらに切り替え式のbody idに"node_Pages"という名前をつける、など。
7. ブロックには直接PHPコードを埋め込めるのだから、モジュール内にブロックを作成する必要なんてない。っつうか、誰がテキストエディターなんか使って開発なんかするかよ。
8. hookシステムの仕組みを学ぶことを拒む
9. template.phpの仕組みを学ぶことを拒む
10. forms_apiの仕組みを学ぶことを拒む
11. ボーナス：サポート対象から外れたバージョンのDrupalを使う
（続きはそのうち訳すかも。いや、誰か訳して！）
Comments
教訓：development snapshot（開発途上）およびベータの寄贈モジュールはプロダクションサイトで使わない。
もう２年以上前になるけど、僕はとある小さいプロジェクトで、Simplefeedというモジュールの拡張をした。
Simplefeedはいわゆるアグリゲーターモジュール。Simplepieという構文解析ライブラリを介して、RSSフィードをノードとして保存するモジュールで、当時どのアグリゲーターモジュールでも処理できないタグを処理するべく奮闘してた。
Simplefeedは自分で書いた構文解析エンジンを使うことができて、これを手がかりに開発を進めて行った。そして開発がほぼ終わりかけたとき、それまでベータだったSimplefeedが正式リリースされた。僕は早速アップデートして挙動を確認。。。動かない。あれ？なんで？しかも見た事も無いエラーメッセージが出る。
数時間かかって検証した結果、正式リリースされたSimplefeedは、独自開発のエンジンをサポートしないよう変更されていた。Simplefeedのプロジェクトページには「独自の構文解析エンジンを使いたかったらFeed APIに乗り換えてください」と書いてあった。はあ。
ということで、このサイトは無事、脆弱性の心配のある古いモジュールを懐に秘めてローンチしたのでした。ちゃんとクライアントには説明しましたよ。
===================
development snapshotを使う上で気をつけたい理由の一つは、仮に深刻なセキュリティホールが発見されたとしても、Drupalセキュリティチームはこれに関してSecurity Announcementを出さないということ。これは、開発途上なんだからそもそもプロダクションサイトで使うべきでない、というのが理由。
必要だからと、ついつい使ってしまう'6.x-1.x-dev'とかいうバージョンのモジュール、できればセキュリティレビューをしてから使ってください。（そして脆弱性を発見したら、開発途上だからといって公開せずにmaintainerに報告してください）
Nick Lewis
Nick Lewis is so funny. His insights into Drupal and Drupal development are always refreshing (although this one dates a bit, like you said)