Eclipseの日本語化プラグインを導入しようとしてディレクトリをD&Dして上書きするとEclipseが起動しないという状態で結構ハマっていたら、Macだと中身をマージしてくれずにディレクトリ単位で上書きされるのね・・・。
マージされて当然だと思っていただけに中々気が付かず設定ファイルばかり見ていたという。設定でマージするように変更したりできるのだろうか。
こういった思い込みや慣例によって考え方が狭くなったり画一的な考え方しか出来なくなっていたんだな、と認識出来る体験談。環境や人が違えば「当然」も違うという当たり前の事を再度心に留めておかないと。
MacBookの新モデルが発表されたので予てから欲しかったという事もあり2日後にMacBook(ブラック)を購入。
メインマシンを今まで使っていた爆熱Prime Note(windows/ubuntu)からMacBookに切り替えるべくここ何日かで色々模索設定していた。
MacBook使ってみた感想
『(Windows+Linux)*UIを洗練』という感じて非常に使いやすい。CtrlとCmdキーの使い分けに若干悩む時があるもののキータッチも好みで、一通り使ってみたところ買って良かったと言える。
Windowsで使っていたソフトと同じものや似たようなものを入れたので操作も今の所は特に困ってはいないかな。
ターミナルのホスト名変更
[システム環境設定] – [共有] – [コンピューター名の変更] を変更してターミナルで表示される “xx-no-macbook:~” の表示が変更出来る。
入れたソフトとか
- Quickilver
- fenrir(windows)の代用、標準搭載のSpotlightとショートカットが被るので要ショートカット変更。
- KeyRemap4MacBook
- Ctrl+FBNPカーソル移動を行うために。
- Firefox
- +AutoPagerizeとか色々。
- iTerm
- 標準のターミナルだと256色表示出来ないらしいので。
- Eclipse(PDT)
- +Subversive
これから長らくメインマシンになりそうなので大切に使っていこう。
LivedoorBlogからはてなダイアリーへ移行しました。
大きな違いはここら辺か。思った時にすぐ書けるのが大切だと感じたのではてな記法で。
RailsやCakePHPなどのフレームワークではお馴染みのfindBy系メソッドをZendFrameworkで実装したいということで。
Zend_Db_Tableクラスを継承したMyZend_Db_Tableクラス内のマジックメソッドで実装し、ModelはMyZend_Db_Tableを継承する。
<?php
class MyZend_Db_Table extends Zend_Db_Table {
/**
* 論理削除カラム名
* @var string
*/
private $_deleteCol = 'delete_time';
/**
* findAllBy[ColName]($value [, $flag])でデータアクセス
*
* $flag = true で論理削除された行は除外して取得
*
* @param string $method
* @param array $args
* @return Zend_Db_Table_Row_Abstract
*/
public function __call($method, $args) {
if (preg_match('/^findAllBy(\w+)?$/', $method, $matches)) {
$field = strtolower(preg_replace('/([a-z])([A-Z])/', '$1_$2', $matches[1]));
$where = array();
$where["`$field` = ?"] = $args[0];
if (isset($args[1]) && $args[1] === true
&& in_array($this->_deleteCol, $this->_cols)) {
$where[] = "`{$this->_deleteCol}` IS NULL";
}
return $this->fetchAll($where);
}
throw new Zend_Db_Table_Exception("Call undefine method $method()");
}
}
これで$model->findAllByName(’Design’);のようにアクセスすれば`name` = ‘Design’という条件でのデータアクセスが可能になる。
データは論理削除する事が多いのでfindAllByName(’Design’, true)の形の呼び出しで
`name` = ‘Design’ AND `delete_time` IS NULL
有効な行のみ返すようにしている。
まぁそんな感じで移植実装がおこなわれていくわけです。
MySQLではインデックスを使用しても30%以上のレコードにアクセスしなければならない時インデックスは使用されない。が、LIMIT句があればインデックスを使用する。
MySQL では利用可能な場合でもインデックスが使用されない場合があることに注意してください。この一例として、インデックスの使用によって、MySQL がテーブルの 30% を超えるレコードにアクセスする必要が生じる場合が挙げられます(この場合は、必要なシークが大幅に減少するため、テーブルスキャンのほうが高速になる可能性が高くなります)。 ただしこのクエリに、レコードの一部のみを取り出す LIMITが使用されている場合、結果で返される少数のレコードを迅速に検索できるため、MySQL はインデックスを使用します。
6.4.5. MySQLにおけるインデックスの使用
例えば’2007-01-01 < register_date < 2007-12-31′な数百万件データがありregister_dateにインデックスを張っているものとして、以下のSQLの条件の日付を進めていくと急にインデックスが効かなくなる。
SELECT * FROM `foo` WHERE `register_date` < '2007-01-01'
知っていればどうという事はないものの何も考えず実装してしまうとデータ量が増えると予想外の時間が掛ってしまう時があるかもしれない。データ量を増やしたテストとexplainは重要。
データ量が増えるなら差分のみを対象に出来る設計にした方が良いと思う。