2015年4月27日

2015年4月26日

【備忘録】CakePHPトランザクション処理の仕方

 CakePHPでトランザクション処理のトランザクション処理の書き方をわかりやすくするためのコンポーネントとかを書いたのに別のプロジェクトをやった時に中途半端にロジックを書いてちゃんと動かなかったので忘れないようにするために記録しておきます。

 共通部品化できているの使いまわせると思います。

 まず、アプリケーションを作る時どこでトランザクションを管理すべきかですが、やっぱりコントローラで管理するのが正しいと思っています。
 CakePHPの場合、DataSourceに対してトランザクションをかけるのですが、DataSourceはモデルが持っているので、イマイチなコーディングになっていまします。
 テーブルが1つの場合は、良いですが、複数のテーブルになった途端見た目がおかしなことになってしまいます。

テーブル1つの場合
トランザクションをかけたいテーブルが1つに明確なのでbeginの意味はわかりやすいです。
    $this->Table1->begin();

    $this->Table1->save($data);

    $this->Table1->commit();

テーブル2つの場合
Table1のbegin()を実行した時点でデータソースに対してトランザクションがかかるので、Table2もトランザクション対象になります。
でも、見た目、Table2はトランザクション対象にならない感じがします。
    $this->Table1->begin();

    $this->Table1->save($data1);
    $this->Table2->save($data2);  // ←トランザクション対象外に見える

    $this->Table1->commit();


じゃぁ、どうするか!

複数のテーブルにトランザクションをかける場合、明示的に使用するモデルを指定する方式をとります。
トランザクション用のコンポーネントとモデルにトランザクション用のメソッドの追加をします。

TransactionComponent.php
class TransactionComponent extends Component {
  /**
   * トランザクション開始
   *
   * @param array $models トランザクション処理するモデルを全て指定する
   */
  public function begin($models) {
    $this->models = $models;
    foreach ($models as $model) {
      $model->begin();
    }
  }

  /**
   * ロールバック
   */
  public function rollback() {

    foreach ($this->models as $model) {
      $model->rollback();
    }
  }

  /**
   * コミット
   */
  public function commit() {

    foreach ($this->models as $model) {
      $model->commit();
    }

  }
}
AppModel.php
モデルに対して、トランザクションの開始、commit、rollbackのメソッドを追加する。
class AppModel extends Component {
App::uses('Model', 'Model');
class AppModel extends Model {

  /**
  * トランザクション開始
  */
  public function begin() {
   $db = $this->getDataSource($this->useDbConfig);
    $db->begin();
  }

  /*
  * トランザクションコミット
  */
  public function commit() {
    $db = $this->getDataSource($this->useDbConfig);
    $db->commit();
  }

  /*
  * トランザクションロールバック
  */
  public function rollback() {
    $db = $this->getDataSource($this->useDbConfig);
    $db->rollback();
  }

}
HogeController.php
使うモデルを明示的に指定するので、わかりやすくなる
App::uses('Model', 'Model');
class HogeController extends AppController {

  public $uses = array("Table1", "Table2");
  public $components = array("Transaction");

  private function register($data) {

    try {
      $this->Transaction->begin(array("Table1", "Table2"));

      if(!$this->Table1->save($data)) {
        $this->rollback();
        return false;
      )

      if(!$this->Table2->save($data)) {
        $this->rollback();
        return false;
      )

      $this->commit();

      return true;

    }catch(Exception $e) {
      $this->rollback();
      return false;
    }

  }

}
これは、CakePHPを使い始めてDBのトランザクションはどうやって扱ったら良いかというのを調査していたらあるサイト(今もあると思いますが忘れました)で一つの解として紹介されていたもものです。  実際の所、ルールなので、複数テーブルにトランザクション処理をするときは、代表のテーブルに対してbegin、commit、rollbackをするということにすればいちいちこんなめんどくさいことをしなくても良いのですけどね。

2015年4月23日

新システムがリリースされました

 1年以上前から手がけていたシステムが本日プレリリースを迎えました。
と言っても社内システムなので世の中の人には関係ないのですけどね。

 本当は、去年の10月にリリースする目標でやっていたのですが、いろんな問題が紛失して今になってしまっています。

 で、何かとういうと、システム移行の過渡期なので旧システムと新システムが同時に運用されます。
 新しい伝票データは新システムで登録して、既に作成されているデータは旧システムで運用していきます。
 システムを使う現場の人はとても大変だと思いますが頑張って新しい方を使って頂きたいです。


 実は、システムを作った側も大変になります。

  • 課題が沢山残っているので随時対応
  • ステージング環境、プロダクション環境と開発環境の3環境を面倒見る必要がある。
  • ステージング、本番環境のリリースを間違わないようする。
    プログラムだけだったらいいんですが、データベースもあるのでいろいろと難儀

 開発環境以外は、AWSなのでこれを機械に開発環境もAWSに作ってしまおうかとちょっと考えてもいます。
 でも、お金が掛かるのがちょっと気になるんですが…。


 これをしながら別のシステム開発もしていくので頭の切り替えが大変です。
新システムのリリース後は何かと問い合わせがあると思いますが頑張っていこうかと。


 でも、これを期にリリースのためのツールや手順のパターン化などが整理できていくはずと思って、勉強期間としても捉えています。
 動けばOKではないのです。いろんなことがスムーズになって属人性の排除ができればよりグッドです。

2015年4月22日

Google+のイベントのタイムゾーン

 Google+のイベントをよく使うのですが、そのデフォルトのタイムゾーンが「日本の東京」ではなく、「東ティモール」になっているのがとても気になる。

 時間的には「+9:00」なので何の問題もないのですが気持ち悪いので毎回変更しています。

きっとどこかの設定が「東ティモール」になっているんでしょうね。

赤丸をしたところが問題のところ

AWSのコンソールが日本語化された

 AWS(Amazon Web Services)のコンソールが日本語化されました。
これで、これってなんだろう?ってのが短時間で解消されそうです。

でも、英語版を見慣れていたせいかなんかスッキリしない感じがします。


【AWS発表】AWS マネージメントコンソールの日本語対応

2015年4月18日

Gitを使う前にgit svnで練習がよいのかな?

 近い将来プログラムソースのバージョン管理をGitに切り替えていこうかと思っています。
 現在は、Subversionでやってます。
 いきなりGitってのも良いのですが、Gitを使ってSubversionのリポジトリを使うためのgit svnというのがあるというのを知りました。
 Subversionを捨てて、Gitに移行してもよいのですが慣れていないツールを使って振り回されて本来やりたいことができなくなると困るのでね。
 新しいプロジェクトが始まったら、Gitを本格的に使っていくことにしました。

で、git svnは。
やっていることは、以下の以下のとおりです。
準備

  1. Subversionのtrunkをコミット毎にローカルのgitリポジトリに取り込む。
    完了すると、ローカルのgitでバージョン管理ができるようになる。
運用
  1. プログラムソースを修正する。
  2. 修正したソースをステージングへ追加する。
  3. gitのリポジトリにコミットする。
    ↑ここまでが通常のGitの操作
  4. git svnでsubversion用のコミットをする
    git svn dcommitコマンドでSubversionのリポジトリにコミットする。
かるく動かしてみたらできたので行けそうです。

 これの何がいいかというと、Subversionの場合、リポジトリが見えてないとコミットできないので直したものがどんどんたまって、ポイント毎に戻りにくくなってしまいます。
 ですが、Gitであれば、ローカルのGitリポジトリに対してコミットをできるのでポイント毎に戻ることができるようになります。
 Subversionのリポジトリが見える環境では、Subversionを使って、つながってない時はgit svnを使ってローカルにコミットをためる。で、Subversionが見えるタイミングになったら、dcommitをしてSubversionにコミットです。

 これで、どこでもソース管理ができるという寸法です。いかがですか?

本当はGitを直接使うのが良いので早くGitに移りたいです。
OSも関係なく、コマンドラインでもさくさくと作業ができればプロっぽいですよね(笑)

Git svnの使い方サイトとか

データフォーマットって大事だよという話

 残念なことは続くよねー。
 移行データを作って送ってもらったのはいいのですが、フォーマットが違うため使うことができないです。
 初めて送ってきたんだったら何かの間違いと思って何も思わずに、直してくださいと言うんですが、それが何回も続くと大丈夫かこの人?ってなってしまいます。
 前回も違っていてそれを指摘すると、自分の責任ではなく業者の問題とかって言って、逆に叱られたんですよね。でも、そんなのには負けずに言い返しますけどね。

 本当の期限が迫っているので、それまで送られてくればいいんですが…。

もう、リリースを何回も伸ばしてるんだからこれが最後だろうな。


2015年4月10日

テキストエディタを変える宣言をしたにもかかわらず

 テキストエディタをSublimeTextからatomに変更すると宣言したにもかかわらず、未だに移行できず。
 理由は、画面分割をした時にマウスでサイズ変更ができないようなんです。
キーボードでできるようにするプラグインがあるようですが、キーボードで操作する為の練習をしないとならないということでなかなか次の一歩が踏み出せません…。

 でも、いつか必ずや!

 

2015年4月8日

やっぱり自分の開発環境は最高

 出向先から舞い戻ってきて(*1)自分の事務所で開発作業をしてるのですが、やっぱり日頃使い慣れている環境での作業は快適だし、捗りますよね。

 いくらCPUが早いPCだったとしても画面解像度が低いと効率の良い開発はできなです。
自分のディスプレイの解像度が高過ぎる(2,560X1,440)のだと思いますが、ノートPCでメインの開発はやっぱり無理があります。
 あと、キーボードが手に馴染んでいるかもとても大事です。
 ワープロやってるだけだったらいいけど。


*1
 出向先に居てもプロパーの人が他の作業につきっきりでなにも進まないのでここに居なくてもいいですよねと言い続けて作業することになりました。
 まぁ、やるべきこともいまいちあやふやですが目指すところはだいたい理解できたので自分の理解のなかで進めることになっています。
 で、週1で見せて整える作戦です。



うまくいくかどうかわかりませんが挑戦中です。
出向先の人(会社)も新しいことに挑戦の年だということで了承してくれたのだと思いますが…。

2015年4月2日

Vagrant使って開発してみます

 Vagrantというオープンソースのソフトウェアがあります。
仮想環境をソフトウェアで簡単にコントロールすることができるツールです。

予め作っておいたOSのイメージをとっておくことで簡単環境を再構築をしたりすることができます。

 自分は、Windowsがメインの環境なので、Linux上で動くWebのアプリケーションとかは、Windows環境で開発、単体テストをしてから、Linux上デプロイして再度テストをするということをしていました。
 Linuxのディレクトリにファイルを置くのは、むずかしいというか一手間必要だったりするのでちょっと面倒だと思っていました。
 ですが、Vagrantを使うと仮想環境のLinux上のディレクトリをクライアントPC(Windows)フォルダのマッピングを簡単にやってくれるのでそのフォルダ上で開発をすることで直ぐのデプロイしたことになるのでちょー便利です。



 で今回はこんな環境で開発をします。

作るアプリの運用環境
(※本当の運用環境は、aws上ですけどね)
  • OS:CentOS
  • Webサーバ:Apache
  • 開発言語:PHP
  • DB:MySQL

開発で使うツール達
  • OS:Windows7
  • DBツール:A5:SQL Mk-2
  • テキストエディタ:Atom
  • 仮想環境:VirtualBox
  • 仮想環境構築ツール:Vagrant

当分、この環境でシステム開発したいなーって思いますわ。