HDD が raw に、そして testdisk で Analyze するもパーティション見つからず、どうしよう…

USB HDD に寿命がきたようだ。

まず、接続時に「電力不足」云々のメッセージが出るようになった。
原因は色々あるのだろうが、USB ケーブルの接続部分に問題があるのだろう。
中の HDD は無事だと信じケースから取り出し、SATA => USB 変換ケーブル（サンワサプライ USB-CVIDE2) にて接続してみると一応認識はされた。ただし、raw として。

こんなときは、testdisk ですね？
しかし、analyze を実行してもパーティションが見つからない。
途方にくれてぼんやりと testdisk の画面を眺めていると、Geometry で Sector Size が 4096 になっているのを発見。あーこれか！

ということで、Sector Size を 512 に変更したところ、パーティションが見えました！
多くのファイルが破損しているようではありましたが、コピーしていみるとコピー先は意外に普通に開けたりしました。

testdisk では Sector Size の変更は「危険」と言われますが、PBR が壊れている場合は値が正しく設定されていないこともありますからよーく確認しましょう。そして、Analyze するだけだったら Sector Size を間違えても何も起こりません！ビビらなくても大丈夫です、write しなければね。
その後当方は PBR の write が残念ながらエラーとなりましたが、testdisk のコピー機能でせっせとファイルを別の HDD にコピーして事なきを得ました。

sftp でのポート指定

sftp コマンドでポート番号を指定してリモートサーバに接続する際のオプションは -oPort=xxxx ですが、CentOS では指定の順序が大事です。

% sftp -oPort=xxxx [Remote Server]

は OK ですが、

% sftp [Remote Server] -oPort=xxxx

は NG!

Google アナリティクスのデータをシステムにインポートする処理を自動化する

いつの間にか正式にリリースされていました。

https://developers.google.com/analytics/devguides/reporting/core/v2/gdataAuthentication?hl=ja#common_oauth


ということで以下は古い情報です。

Google API では OAuth 2.0 で認証を！と Google では推奨しているわけですが、Google Analytics （以下 GA）が Service Account に対応していなかったため、GA のデータをインポートする処理は人が オペレートせざるを得なかったのですが対応したようです。（まだ正式リリースではないようですが。）

Service Applications and Google Analytics API V3: Server-to-server OAuth2 authentication?

ついに！と記事を見ながら作業したのですが、以下のエラーでつまづきました。

PHP Fatal error:  Uncaught exception 'Google_ServiceException' with message 'Error calling GET https://www.googleapis.com/analytics/v3/data/ga?ids=......(403) User does not have sufficient permissions for this profile.' in google-api-php-client-read-only/src/io/Google_REST.php:66

なになに？プロファイルに対する権限がない？
アナリティクスのユーザとして Service Account のメールアドレスを登録する際の権限は「管理者」でなければならないということだそうです。
前述のページの手順ではそのことに触れていません。
↓に小さく情報があるのを見つけました。

Google グループ "Google Analytics Reporting API" の関連記事（一番下のコメント参照）

mysqldump: Got error: 1016: Can't open file: './mydb/mytable.frm' (errno: 24) when using LOCK TABLES

MySQL で夜間バックアップを行うスクリプトを作成して cron で実行。
翌朝確認してみると、次のようなエラーが...

mysqldump: Got error: 1016: Can't open file: './mydb/mytable.frm' (errno: 24) when using LOCK TABLES


情報がありました。
http://www.bigresource.com/Tracker/Track-mysql-L5WFTgJm/


table_cache might be too small.
Try --lock-tables=false on mysqldump.


なるほど、社内システムの夜間バックアップなのでロックは不要。
--lock-tables=fales で解決。

MySQL の geometry 型

座標をＤＢに入れるならこの geometry 型を使ってみよう！と思ってやってみたが、CakePHP だと座標の取得の度に 'fields'=>array('X(lnglat) AS X', 'Y(lnglat) AS Y') を書かなければならず面倒…

面倒くさがり屋の私はやはり lat decimal(9,6), lng decimal(9,6) のほうが扱いがはるかにラクということに気が付いた。

テーブルに geometry と decimal の両方のフィールドを設けて、当面様子をみることにしよう。

CIRCLE とか使って「半径 X km 以内のお店を検索」などのサービスをすることを目論んでいたが、MySQL ではまだ CIRCLE もDISTANCE もない。道は遠そうだな…

MySQL での DELETE WHERE EXISTS

MySQL では DELETE 時の WHERE 区で　EXISTS, NOT EXISTS は指定できないらしい。

DELETE FROM tab_a a

WHERE NOT EXISTS

(SELECT * FROM tab_b b WHERE a.id=b.id)

みたいなのはＳＱＬエラーとなります。

残念...

CakePHP の bake はとても便利

bake は超便利で使いまくりですが、bake が吐き出す view がとっても English なので日本語に変更しなければならずそこんとこが面倒。

bake が view を吐き出すのに使っているテンプレートは /cake/console/libs/templates/views にあるので、それらを直接書き換えてから bake するとかなり幸せ。