Web: 2009年2月アーカイブ
symfonyを入り口近辺でちょろちょろ試してはいたものの、ある程度まとまった知識が欲しいと感じ始めていたので、以前から取り組んではすぐ挫折していたaskeetに再びやることにしました。最低限、24日目まで通してやることが目標。
ちなみにsymfonyバージョンは1.0.19。今から始めるなら1.2系がスジなんでしょうが、askeetチュートリアルもDefinitive Guideも日本語訳が揃っている1.0系に有難く頼らせて頂きたいということで・・・。
1日目
環境構築やプロジェクト、アプリケーションの作成など。
Subversion周りの作業など関係無いところはスキップして、とりあえずさくっと終了。
2日目
DB周りの作業をざーっと行う。
$ symfony propel-generate-crud frontend question Question
上記コマンドでCRUDジェネレータを実行するところで、「Questionモジュールが無い」とエラーになりました。そういえばmodule作成する箇所が無かったような・・・。
というわけで、questionモジュールも先に作成しておきます。
$ symfony init-module frontend question
3日目
レイアウトやテンプレートの変更、ルーティング調整、バッチファイルからのテストデータ取り込みなど。
以下、感じたこと。
- ORMの恩恵受けられるようなDB設計を考慮することが大事。
- ジェネレータでベース作って、不要なアクション・テンプレートをクリーンアップしていくという流れがやっぱり基本？
- css落としてきたけど、なんだかレイアウトずれてるんですが・・・。とりあえず無視。
ひとまず今日はここまで。
ORMは便利だろうけど、パフォーマンスが気になるとかSQLが全部目に見える状態で作りたいとかいう話もあったりして、直接PDO経由でDB操作をしたい場合にどうすれば良いのか試してみました。
DSN情報を設定ファイルに記述。
apps/appname/config/app.yml
all:
db:
dsn: mysql:host=localhost;dbname=test
user: root
pass: pass
DB接続クラスを作成。
lib/dbConnection.class.php
<?phpclass dbConnection
{
static private $PDOInstance; protected function __construct()
{
$dsn = sfConfig::get('app_db_dsn');
$user = sfConfig::get('app_db_user');
$pass = sfConfig::get('app_db_pass');
self::$PDOInstance = new PDO($dsn, $user, $pass);
}
public static function getConnection()
{
if(!self::$PDOInstance)
{
new self();
}
return self::$PDOInstance;
}
}
actionなどからコネクション取得。
$conn = dbConnection::getConnection();
で、あとはこのコネクション使っていろいろと、ていう感じで動かしてみていたのですが、おいおい調べていたら自作せずともデフォルトのDB設定でPDO接続を指定できてしまうことを知りました・・・。
config/databases.yml
all:
pdocon:
class: sfPDODatabase
param:
dsn: mysql:host=localhost;dbname=test
dbtype: mysql
database: test
username: root
password: pass
actionからコネクション取得。
$conn = $this->getContext()->getDatabaseConnection('pdocon');
action以外から取得。
$conn = sfContext::getInstance()->getDatabaseConnection('pdocon');
なるほど、こっちの方が簡単。
動的にDB接続先を切り替えたりといったこともやってみたかったりするので、それぞれの使い勝手も含めて引き続き調べてみたいと思います。
まだ動かして間もないですが、少しずつsymfonyに慣れてきた気がします。
検索エンジン3社、正しいサイトURLを認識させるcanonical属性を導入（URLの正規化） :: SEM R
正しいURLを定義したり、同一内容の複数ページのインデックス登録の指定ができるcanonical属性がGoogle、Yahoo!、Live Searchの3検索エンジンで採用されたとのこと。
ちょうど今関わっているEC系の案件で、複数カテゴリーに属する同一商品のメインページをどう処理するかといった議論が挙がったりしていたので、その優先付けを認識させる手段として早速使えそう。
試しに当サイトにもタグを追加してみました。こんな感じです。
<link rel="canonical" href="http://blog.knockoutmarch.com/" />
ブログ上のブックレビューを閲覧できるサイト「読んでる？」がGoogleインデックスから削除されてしまいました。
アクセス数も見事な曲線をたどっています（笑）
Google Analytics
そもそも実験サイトではあったのですが、ここ数ヶ月アサマシ力が予想以上に高まり貴重な存在になっていた矢先だったので、痛い出来事でした。
原因を推測するに、不適切なページにadsenseが貼られていると警告がきたこと（修正済み）や、sitemap.xml内のページ数がガイドラインの50,000個以上になったことがあった（修正済み）など、気になることはありましたが、一番可能性として高そうなのはインデックス欲しさにsitemapのリストを増やし過ぎたことかなぁ・・・と考えています。
動的ページなのでやろうと思えば幾らでも生成できますが、そこは常識的にアクセスがあったページだけをリストに生成するようにしていたのですが、普通のサイトでは考えにくい単位で数が増えていただろうことは否めません。
取り急ぎ、sitemap周りを調整してGoogleに再審査をリクエストしてみましたが、さてどうなることやら。
http://mail.google.com/mail/help/intl/ja/about_whatsnew.html
Gmailが機能追加しましたね。
とりあえず、ラベルが複数同時にON/OFF切り替えられるようになったのと色付けできるようになったのが、個人的には使い勝手かなりUPでいい感じ。
カード決済履歴を見たら記憶に無いお金が落とされていたので、いろいろ調べていたらovertureからのものと判明。
まあよくよく調べると、確かにこんな説明が管理画面に書いてあった。
ご注意: アカウント残高が、平均クリック料金の3日分から7日分（目安）を下回った場合に、残高不足になります。
気楽に手を出したので自動引き落とし設定になっているのも良く把握してないで使っていたし（取り急ぎ、アカウントの支払い方法設定を「なし」に変更しました）、残高等のメンテナンスも放置状態だったのでこれは反省点。
ただ、今回気になったのはこの請求に関する通知メール。アカウントの言語設定が日本語になっているにもかかわらず、英語でメールが来ていました（それで気付くのがだいぶ遅れた）。
アカウント登録時やニュースレターなんかはいつも日本語で送られてくるのに、なんでより大事なメールは英語なの？
これに気が付かなかったら、今後も残高が減る度に引き落とされ続けてたわけで。
こんな不親切な仕様だと何かこすい思惑を感じざるを得ないのですが・・・。
