自転車で通勤しましょブログ

WordPress: cforms2 & Ktai-style

2009/12/10 17:40 | カテゴリー PHP, WordPress | タグ cforms ktai-style WordPress xrea | コメント

WordPressのプラグインのcforms2とKtai-Styleの併せ技一本を狙う。
お客さんが携帯サイトをやっていて、携帯からのお問い合わせに対応したいと。しかし、携帯からのお問い合わせで送信されてくるメールが文字化けするんで助けてください！と後輩から頼まれたというのが経緯。

WordPressのフォーラムより、
携帯からの場合は文字コード変換処理を入れるとかの対応が必要だと思います (Ktai Style の is_ktai() 関数を使えばいけそう)。
という情報を手に入れたので、cforms2のソースコードに手をいれて、携帯の場合の処理を追加することにした。
ちなみに、cformsのバージョンは11.0です。

/wp-content/plugins/cforms/lib_validate.phpの先頭に追加。

// 携帯のアクセスの場合のみ、検証の前にUTF-8にエンコードしてしまう。
if(function_exists('is_ktai')){
  if(is_ktai()){
    foreach($_REQUEST as $key => $value){
      $_REQUEST[$key] = mb_convert_encoding($value, 'utf-8', 'auto');
    }
  }
}
// 以下略

次に、/wp-content/plugins/cforms/lib_email.phpを編集。
@mailを@wp_mailに全部変更する。
ここは@mailで検索すればいいのでソース省略。

次に、/wp-content/plugins/cforms/cforms.phpの354行目あたりを修正。

### start with form tag
// $content .= $ntt . '<form enctype="multipart/form-data" action="' . $action . '" method="post" class="cform'.( $cformsSettings['form'.$no]['cforms'.$no.'_dontclear']?' cfnoreset':'' ).'" id="cforms'.$no.'form">' . $nl;
// au でメール送信できないため、enctypeを除去
$content .= $ntt . '<form action="' . $action . '" method="post" class="cform'.( $cformsSettings['form'.$no]['cforms'.$no.'_dontclear']?' cfnoreset':'' ).'" id="cforms'.$no.'form">' . $nl;

これで、開発環境のほうは、メールの文字コードがutf-8で送信できるようになり、携帯からのお問い合わせにも文字化けしなくなった。しなくなったのだが、、、。

本番環境(xreaのcoreserver)で文字化けが続いた。
件名が文字化けするのだ。件名に『=?utf-8?B?44C(略)』と表示された。

調査すること3時間。遂に解決！！原因はWP Multibyte Patchの設定だった。
utf-8でエンコーディングされている件名をiso-2022-jpで解釈してるために化けているみたいだった。

/wp-content/plugins/wp-multibyte-patch/wpmp-config.phpを修正。
ない場合は、wpmp-config-sample.phpをコピーしてwpmp-config.phpを作成して修正。

// wp_mailに対してのパッチを外す
$wpmp_conf['patch_wp_mail'] = false;

ちなみに、上記の設定をtrueにしたままパッチプラグインの/ext/ja/config.phpでUTF-8を使うように指定したら、何故かさらに文字化けた。本文までiso-2022-jpで解釈されてしまった。UTF-8って指定したのに！！このあたりはまだよくわかっていない箇所なので、もっといい設定があるのかもしれない。

最後に、cformsのmy-functions.phpを修正する。
携帯でのアクセスの場合のみ、検証処理後に出力に用いられるデータをutf-8にエンコードしておく。

// 値の検証後、出力前にコールされる関数
function my_cforms_filter($POSTdata){
	if(function_exists('is_ktai')){
		if(is_ktai()){
			foreach($POSTdata as $key => $value){
				$POSTdata[$key] = mb_convert_encoding($value, 'utf-8', 'auto');
			}
		}
	}
	return $POSTdata;
}

これで、パソコンと携帯からお問い合わせフォームを利用してみたが、どちらも文字化けせずにメールが届いた！後輩も喜んで一件落着！！

WordPress: 自作プラグインでAjaxする正しい方法

2009/12/09 14:08 | カテゴリー Ajax, JavaScript, PHP, WordPress | タグ prototype.js WordPress | コメント

WordPressの自作プラグインでAjaxする方法で、正しく行う方法がないか探していた。Googleで検索しても、Ajaxを使ってるプラグインの情報がたくさん出てくるばっかりで、作り手に有益な情報を調べるにまでいけなかった。だから、必要なファイルのみを無理矢理require_onceで読み込んでインスタンスを生成してから、やりたい処理を行うという強引な方法を取っていた。しかし、Ajaxしたいところで毎回require_onceをやるのは面倒だし、正しくやる方法があるに違いないと思っていたら、あったよ！やっぱり！

http://wpdocs.sourceforge.jp/AJAX_in_Plugins

上のサイトの例では、javascriptライブラリとしてSACKを使っているが、俺はprototype.js&scriptaculousファンなので、prototype.jsを使ったAjaxで勝負！

まず、プラグイン側でjavascriptファイルを読み込む設定を行う。
プラグインの名前は、hogeとします。

/**
 * /wp-content/plugins/hoge/hoge.php
 * 
 * 管理画面でjavascriptを読み込む
 */
add_action('admin_enqueue_scripts', 'hoge_script_admin');
function hoge_script_admin($hook_suffix){
  // 指定したページのみでjsを読み込むために、条件を設定
  // ここではhogeプラグインのカテゴリー管理ページに焦点と絞ったとする
  if (preg_match('/page_hoge_category_list$/', $hook_suffix)) {
    // hoge_category.jsと、prototype.jsを読み込む
    wp_enqueue_script('hoge_category', plugins_url('hoge/js/hoge_category.js'), array('prototype'), '1.0', false);
  }
}

次に、hoge_category.js側に処理を記述する。
関数 update_category_list が呼ばれると、Ajaxでカテゴリーリストを更新する想定です。

function update_category_list(){
  // ajaxurlはWordPressが定義してくれてる
  var params =[];
  // Ajaxアクションを指定
  params.push('action=hoge_get_category');
  // あとは必要なパラメータを設定
  params.push('abc=xyz');
  new Ajax.Updater(
    'category_list', // 更新される領域のID
    ajaxurl,
    {
      method: 'post',
      parameters: params.join('&')
    }
  });
}

最後に、hoge_category.jsから呼ばれるサーバ側の処理を記述する。

// ajaxで呼ばれるアクションを追加する
add_action('wp_ajax_hoge_get_category', 'hoge_get_category');
// 実際に呼ばれるアクションを定義する
function hoge_get_category(){
  $output = '<ul>' . "\n";
  for($i = 1; $i < 10; $i++){
    $output .= '<li>カテゴリーその'. $i .'</li>' . "\n"
  }
  $output .= '</ul>' . "\n";
  echo $output;
}

これで、カテゴリーリストがAjaxで更新されます。

詳細設計書は詳細すぎないほうがいい

2009/12/01 23:01 | カテゴリーシステム開発 | コメント

アジャイルプラクティス達人プログラマに学ぶ現場開発者の習慣
	木下史彦オーム社 2007-12-22 売り上げランキング : 52268 おすすめ平均まさに教科書ださらばウォーターフォール面白かったのは「コードレビューのパターン」。コード見直し模様。 Amazonで詳しく見る by G-Tools

アジャイルプラクティスを読んでて、腑に落ちた記事があった。

「設計は指針であって、指図ではない」

これは、設計者にも開発者にも、どちらにとってもいい言葉だと感じた。理由としては、設計者は指針を書くことに注力できること。いい意味で時間の短縮ができる。

詳細仕様書でフローチャートを書いていたときに、やりたいことはわかっているのだがフローチャートにして書こうするとすごく時間がかかった。しかも悲しいことに、この時間のかかったフローチャートは、「わかりにくい」と言われてしまった！！

フローチャートではなく、フローを箇条書き形式で書き直して見てもらったら、「これならわかる」と。

『詳細』なので、詳細にしなければならないという気負いがあるが、指図になるまで詳細にすると、仕様に問題がある場合に後戻りするのが難しい。しかも、詳細設計書を書くのに異常に時間がかかるようになる。これでは本末転倒だし、プログラマの仕事とやる気を奪う事になる。
機能仕様書に載っている機能は具体的にどんな処理をするかを設計する事が詳細設計であり、どのように実装するべきかはプログラマに任せたほうがいいと思う。アジャイルプラクティスに書かれているが、

「実際にその場所を通ってみるまでは、そこがどんな様子なのか確かなことはわからない」

のである。実装を詳細設計に書いたところで、実際に実装しようとするとどうしても無理が生じる場合はありうる。以前に、指針を示さずに指図になっていた詳細設計書を受け取ったのだが、フローとSQLが間違っていたことがあった。何がしたいのかがわかっていれば、間違っている場合は報告できるし、実装も可能なのだが、このときは駄目だった。詳細設計書の修正依頼をかけても修正に時間がかかり過ぎて工数がどんどん減っていき、待ちきれずに意図を判断して実装。そして詳細設計書と実装がどんどん乖離していく…という悪循環だった。

ドキュメントは指針。そして実装方法は、『実際にその場所にいる人』に委譲したほうがいいと思う。指針を共有できれば、プログラマから設計者へのフィードバックでまた素晴らしい設計が生まれる場合もある。

Manage It! 現場開発者のための達人式プロジェクトマネジメント
	でびあんぐるオーム社 2008-10-18 売り上げランキング : 79101 おすすめ平均プロジェクトマネージャー必見面白いけど読みにくい ITシステム開発のPMそしてそのスポンサー必読です Amazonで詳しく見る by G-Tools

ドキュメントを書く人でありたい。

2009/12/01 02:57 | カテゴリーシステム開発 | コメント

Joel on Software
	青木靖オーム社 2005-12 売り上げランキング : 89514 おすすめ平均会社のみんなに読ませたいお気に入りの本です本当のソフト開発を本当の意味でわかってもらうのにいい本 Amazonで詳しく見る by G-Tools

ドキュメントを残す人でありたいと考え、それを模索している。Wordでテンプレートを作成してみたりとか。Webアプリの開発に携わっていると、低コストで厳しい工数を要求されるので作り出してから考えるみたいになってしまいがちだ（うちの会社では…）。工数を削減するためにドキュメント作成を省いたり、あまりに簡潔なものにしてしまうのは、逆に工数の増大を招く。

ドキュメントを書かないのか、書けないのか。最初は面倒臭がって書いてくれない！と思っていたのだが、最近になって、実は書けないんじゃないだろうか？と考えるようになった。ドキュメントは書けないけど、ソースコードは書けちゃうから書けるほうに安易に手を出して、修正依頼がきて、ブツブツと文句を言っているというような。自分はそんな人間にはなりたくないので、機能仕様書を作成してコーディングに入る前に確認を取るようにしている。これは当たり前のことのように思えるのだが、できていない人が多いんじゃないか？

機能仕様書、詳細設計書の書き方を学ぼうとネットで検索してみたりもしたが、しっくりとくるテンプレートが未だ見当たらない。機能仕様書に関しては、Joel on Softwareで書かれている方法で学習していて、なかなかいいなぁと思えるので、そちらを改良していこうと思う。問題は詳細設計書で、見ていてもしっくりくるのがない。感じたのは

一見わかりやすそうで、そうでもない
Excelで作られているパターンが多い
（主観的な意見だが）読みたいと思わせてくれない作り

という点。特に最後のが重要で、せっかく作っても読まれていないということが、往々にしてある。
ということで、Wordで作ることにした。
まぁあんまり変わらんやん！って言われる可能性も高いのであるけれど、Wordでやるほうが管理上楽だし、綺麗に作る事が出来る。ドキュメントには美が必要だと思う。ドキュメントの作成にしても、最初はなかなか上達はしないので、工数もかかるだろうが、そこをちゃんと経験しないと仕様をまともに考えることがないので（頭を使わないため）、エンジニアとして実力が向上しないんじゃないだろうか？

今思うと、ドキュメント書くのが下手な人の話って、わけわからんことが多いなぁ〜と思う。何がしたいのか、何が求められているのかがブレてて、言いっぱなしで、自分でドキュメントにして形にするということがないような気がする。ドキュメントを書くプロセスを経ると、まとめるというフィルターを通した上で出来上がるので、要件もまとまるし、情報共有もスムーズになるし、他人の時間を節約することができるので費用対効果は素晴らしいものがあると思う。いいドキュメントを作成すると信頼も得られるし。

ドキュメントを作るのを面倒臭がる人は、あまりに「自分の時間」にフォーカスを当て過ぎではないだろうか？他人の時間を節約するということは、自分の時間を節約することにも繋がるので、目先の時間に捕われず、ドキュメントに時間を「投資」したほうがいいと思う。得られるのはドキュメントだけではなく、「書く力・考える力」も手に入る。そういうことが、結果的にお客さんの期待に応えることに繋がると思う。

どういうふうに書いたら他人に喜んでもらえるドキュメントになるだろうか？
手戻りの発生しにくいプロセスにするにはどうすればいいのか？
このプロジェクトの目的、解決すべき本質は何か？

これを常に考えていきたい。

エンジニアのためのWord再入門講座美しくメンテナンス性の高い開発ドキュメントの作り方
	翔泳社 2008-05-22 売り上げランキング : 7760 おすすめ平均為になったすばらしいＷｏｒｄ入門書数少ない、明確な視点・コンセプトのWORD本 Amazonで詳しく見る by G-Tools

Ruby入門が終わった！あと車検も！

2009/11/30 01:31 | カテゴリー日記 | コメント

作りながら学ぶ Ruby入門
	おすすめ平均 Rubyを初めて勉強する人、あるいはプログラミングを初めて勉強する人向けの書籍。 Amazonで詳しく見る by G-Tools

Ruby入門を終えた！やり終えた感はあるけれど、次に繋がる何かがまだ決められていない。やはり、手段が目的になっているとこうなるんかなぁ。プログラミング言語を習得すること（手段）を目的にしていたから。何でもRubyでやってみるとよいということが本にも書かれていたが、そういう「Rubyでやるとどうすればいいか？」を考えるようにしていきたい。ERBを使った掲示板を作るなどからやってみようかなと思う。

あと、もう2010年も目の前なので、2010年モデルの紹介ページの作成に取りかかった。まだ1ページすらできていないけれど、毎日コツコツとやっていこう。こちらは手作業なので、時間はかかるが…。

車検やってきた。軽自動車で、タイヤの2本交換もあったので10万円くらいかかった。
代車に乗って、最近の車の性能を体感した。
まずキーレスだし！代車は普通車だから加速がよかった。
乗ると、いいなぁ〜と思うけど、車買い替えるような状態じゃないし！

まぁ、車検後のパジェロミニの調子はちょっとよくなってたので、嬉しかった。
買い替えって、エコか？俺はそうは思わないんだが。

月	火	水	木	金	土	日
« 1月
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