2015-06-26

ActiveMQのTransactionに関して検証してみた

ActiveMQのTransactionに関して検証してみた。

通知とトランザクションに関して

JMSでは「通知」と「トランザクション」の二つの方法がある。

通知

プロデューサー（送信者）　→　JMSサーバー　へ送られた時、
JMSサーバー　→　プロデューサー（送信者）へと受け取った通知を渡して完了する。

JMSサーバー　→　コンシューマー（受信者）へ送られた時、
コンシューマー（受信者）→　JMSサーバー　へと受け取った通知を渡して完了する。

ActiveMQにはこれらに関して３つのモードがある。

autoモード

メッセージの配信の通知をJMSサーバーが自動的に処理してくれます。一回だけの配信を保証します。
createSession(false,Session.AUTO_ACKNOWLEDGE)で設定します。

clientモード

確認応答をJMSサーバーではなくJMSクライアントが行うモードです。
createSession(false,Session.CLIENT_ACKNOWLEDGE)で設定します。

duplicates okeyモード

自動的に確認応答を行ってくれます。数通受け取った場合通知を行うため、autoモードと違い同じメッセージが何通も配信されることがあります。必ず一回だけを保証するautoモードと比べるとその点を保証しない分処理量が少ないというメリットがあります。
createSession(false,Session.DUPS_OK_ACKNOWLEDGE)で設定します。

トランザクション

処理を確定するコミット、処理を復元するロールバックなどを行うことが出来る。
トランザクションモードではコンシューマ／プロデューサーがコミットを行えば、
JMSサーバに対してメッセージ配信が完了したことを通知する。

コンシューマがロールバックを行えば受信されたことをキャンセルし、
再配信を要求することになる。

プロデューサーがロールバックを行えばメッセージ送信をキャンセルする。
ActiveMQでは、

createSession(true,-1)で設定します。

※第二引数は使用しないので、trueにした時点で通知は関係なくなる。

ということで、

トランザクションを検証してみた

コードを全部書くと長いのでわかりそうなレベルで省略しています。
送受信の購読するキューは１つで。
設定は　createSession(true,-1)

検証１：トランザクションとコミットが効く

sender.send("test1");

↓

コミット前は読めない

message = (TextMessage) receiver.receive(1000);
assertNull(message);

↓

コミット後は読める

sender.commit();
message = (TextMessage) qmForRecieve.receive(1000);
assertThat(message.getText(), is("test1"));

↓

受信側がコミットしないと消えない

message = (TextMessage) receiver.receive(1000);
assertThat(message.getText(), is("test1")); 未だ読める

receiver.commit();
message = (TextMessage) receiver.receive(1000);
assertNull(message);　消える

検証２：トランザクションとロールバックが効く

sender.send("test1");

↓

ロールバック前は読めない

message = (TextMessage) receiver.receive(1000);
assertNull(message);

↓

ロールバックすると読めない

qm.rollback();

message = (TextMessage) receiver.receive(1000);
assertNull(message);

検証３：他の受信者が使ってるメッセージは読めない

sender.send("test1");

sender.commit();

↓

ある受信者が読んでいる間は
message = (TextMessage) receiver01.receive(1000);
assertThat(message.getText(), is("test1"));

↓

別の受信者は読めない
message = (TextMessage) receiver02.receive(1000);
assertNull(message);

↓

でもある受信者がロールバックして終了すると

receiver01.rollback();

↓

別の受信者が読める
message = (TextMessage) receiver02.receive(1000);message = null;
assertThat(message.getText(), is("test1"));
receiver02.commit();

検証４：別のメッセージでも読めない

sender.send("test1");

sender.send("test2");

sender.commit();

↓

ある受信者が読んでいる間は
message = (TextMessage) receiver01.receive(1000);
assertThat(message.getText(), is("test1"));

↓

別の受信者は別のメッセージでも読めない
message = (TextMessage) receiver02.receive(1000);
assertNull(message);

↓

でもある受信者が終了すると

receiver01.commit();

↓

別の受信者が読める
message = (TextMessage) receiver02.receive(1000);
assertThat(message.getText(), is("test2"));
receiver02.commit();

検証５：別のメッセージは書ける

sender01.send("test1");

sender02.send("test2");

↓

sender02のみコミットする

sender02.commit()

↓

Sender01のコミットを待たずに読める
message = (TextMessage) receiver.receive(1000);
assertThat(message.getText(), is("test2"));

receiver.commit();

↓

sender01をコミットする

sender01.commit();

↓

Sender01のコミットも読める（02のコミットは先ほど消費した）
message = (TextMessage) receiver.receive(1000);

assertThat(message.getText(), is("test1"));

receiver.commit();

結論

Transactionがちゃんと効く！！！

送信側にも受信側にもトランザクションがあるっておもしろいなー。

でも、送信は別のトランザクション待たずに送信するけど、

受信は別のトランザクション待たないと受信できないんだなーと。

UT間違えたかな((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

2015-06-01

マーチン・ファウラーのリファクタリングを読んで（第１〜４章）

マーチン・ファウラーのリファクタリング、
とりあえず第１章から第４章のリファクタリングの始め方的なのを読んだので、
一旦まとめてみる。

まだ実際のリファクタリングの方法より、なぜするのかとか、どう始めるのかの辺りですが。

なぜリファクタリングをするのか

リファクタリングすると何がいいの？動いてるからいいじゃん。

ってよく言われますが、

コードを理解しやすくなる
→　バグを見つけやすくなる
→　より早くプログラミングできる様になる。
→　スケジュールがスムーズに進む

というところで、結局みんながHappyになれる！

「スケジュールを気にする管理者は、
スピーディな方法を望むが、どうやってやるかは知らない。」

結局はこれなので、もし管理者を説得するなら、

この流れで説得するのがいいのかも。

リファクタリングは設計を保管する

確かに。

最近コードを書くときは、設計はざっくりで、

まず書いてリファクタリングして設計に戻るほうが穴がない。

結局、ウォーターフォール的に先にがっちり設計するよりも、

書いたコードは想定以上のことを見つけられる。

「最初の設計は穴だらけなはず」
まさにこの通り。

変更しにくいコードから離れられる

「読みにくい」
「ロジックが重複」
「既存の修正が多い」
「条件分岐が複雑」

こういうコードは変更しづらい、

だから、リファクタリングによって変更を容易にする。

それによって開発効率は上がる。バグは減る。

リファクタリングって、

エンジニアのこだわりとかじゃないんです！

いつリファクタリングをするべきか

機能追加の時
バグフィックスの時
コードレビューの時

この中で書いてあったのが、

「リファクタリングをリファクタリングだけの時間で切り出さない」

というところかな。結局行う時間が確保できずに借金になりがちだし。

リファクタリングをしてはいけない場合

変更するより書きなおしたほうが早い
期間が迫っている場合

ちょっとこれは本に書いてあるけど、あまり納得できないかな。

このパターンでリファクタリングできないことが多いんじゃないかと。

まぁ、僕は書き直しますが苦笑。

ただ、

「未着手のリファクタリングは借金」
とはいえ、今はしないけど借金ですよというのも書いてあった。

これ、測れるとリファクタリングをちゃんとできる様になりそうだな。

どうやって測るかな。。。

リファクタリングをする時に最初にすること

テストを書く！

ってまぁあたりまえというか、これをしないと安心してリファクタリングできないですね。

PHPだとFixtureとかPHPUnitで、JavaだとJUnitとかですね。

そのテストを書く時に注意するべき点は２つ

実行されない完全なテストより、実行される不完全なテストの方が良い
例外のテストを忘れない

無駄にpublicなメソッドのテスト全部書いても、リファクタリングには無意味ですね。

でも、最近思うのは、先にテスト書いておかないと、テストしにくいメソッド構成とかになってて、結局テスト前にリファクタリングが発生したり。。。

テスト大事！

リファクタリングを始める（まずやってみること）

まずは長いメソッドがあったらそこはリファクタリング対象のはず！

でも、ここで何行以上とか決めちゃうと無駄にメソッドが分割されて結局読みにくくなりそうなので、そういうのはやめておいた方がいいんじゃないかなと。

そのメソッド内でしか使われないローカル変数はメソッドへの問い合わせによって書き換えられる。

確かに無駄に一時変数が多いと読みにくいしバグになりやすい。

変数を無駄に増やさない！

ローカル変数を問い合わせによる取得にすれば、その部分だけテストできるし。

メソッドの移動

使用するデータを持つオブジェクトにメソッドは定義されるべき。

ポリモーフィズムを取り入れるのもいいかと。
「そのメソッドが呼び出されたとき、どう振る舞えば良いかはそのオブジェクトが知っている」

例：Switchは自分自身に対して行うべき

この時、わかりやすい様に、メソッド名とか変数名の変更を躊躇しないのも大事。

ここはまだ導入部分だけど、これだけでもリファクタリングの概念はつかめるかな。

早く先が読みたい(*´Д`)ﾊｧﾊｧ

ここまでのまとめ

リファクタリングを行う必要性をこの辺りまではかなり説明してくれていて、

もし、「リファクタリングしたいけど管理者を説得できないし・・・」とか

思っている人がいれば、まずここを読んでみるのはいいかと。

さて、やっと実際のリファクタリングの方法論に入っていけるヽ(=´▽`=)ﾉ

<a href="http://www.amazon.co.jp/%E6%96%B0%E8%A3%85%E7%89%88-%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E2%80%95%E6%97%A2%E5%AD%98%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E5%AE%89%E5%85%A8%E3%81%AB%E6%94%B9%E5%96%84%E3%81%99%E3%82%8B%E2%80%95-OBJECT-TECHNOLOGY-SERIES/dp/427405019X" data-mce-href="http://www.amazon.co.jp/%E6%96%B0%E8%A3%85%E7%89%88-%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0%E2%80%95%E6%97%A2%E5%AD%98%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E5%AE%89%E5%85%A8%E3%81%AB%E6%94%B9%E5%96%84%E3%81%99%E3%82%8B%E2%80%95-OBJECT-TECHNOLOGY-SERIES/dp/427405019X">Amazon.co.jp：新装版リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES): Martin Fowler, 児玉公信, 友野晶夫, 平澤章, 梅澤真史: 本</a>www.amazon.co.jp

2015-05-26

Software in 30 days

「Software in 30 days」を読んだ感想を徒然と。

おもしろかった所

予測型プロセスの駄目な所

計画には時間がかかり、うまくできない
デスマーチが士気を低下させる

確かに計画なんて上手くいくはずがない。

それなのに長期的な計画を立ててやろうとするなんて。。。

スクラムチームが上手くいくために必要なこと

個人の尊重
開発チームに大きな裁量

エンジニアに裁量がある時が一番良いものが作れる！

詳細まで考えられていて「こういう風に作って！」

って言われたものはだいたいもっと簡単にできたり、

実際に作った後に「違う」って言われたりするなぁ。

スクラムチームの作り方

召集兵より志願兵であること
チームメンバーを惹きつけるメッセージを作る

メンバーの入れ替えとか自発性とかを重視している本だなぁ。

チームメンバーを惹きつけるメッセージとか、

スクラムを導入しているチームに採用する時に使えるし、

考えてみようかな。

ロール毎の役割

プロダクトオーナー

バックログを明確に表現できる

作業の価値を保証できる

優先順位をつけれる

開発者

肩書はない

自己組織化されている

チーム全体で責任を持つ

スクラムマスター

効果的なプロダクトバックログの管理方法を探す

プロダクトバックログを明確に説明できる

長期のプロダクト計画を理解している

おー。なかなかスクラムマスターとしてやっている！

良かったｗ

ちょろっと時間ができた時とかに

よくホワイトボードのタスクとか貼り直してみたり、

プロダクトバックログをどういう風にスクラムチーム用にするかとか、

しょっちゅうやってるなーと。

まだまだできてないことも多いしがんばろう！

プロジェクトの中止

損失を限定し、機会を浪費しない価値もある。

ほんとこれがわかっていないプロジェクトが多い気がする。

ダメだってわかったらその時点で一旦破棄するべきだろう。

モチベーション

上がる時：仕事を自ら管理できている時

下がる時：もっと働けというプレッシャーがある時

結局、裁量が多ければそれだけモチベーションは上がるかなー。

まとめ

ウォーターフォールが駄目、スクラムがいいっていうだけの、

よくあるスクラム本と違って、

モチベーションのこと、チームづくり、スクラムの組織への導入について

とかがおもしろかったな。

「文化に合わせてスクラムを変えるのではなく、上手くやるために文化を変える」

とか、すごく大変そうだけど、必要なことだなと。

１時間で読めたし、オススメです！

<a href="http://www.amazon.co.jp/dp/4048912364">Amazon.co.jp： Software in 30 Days スクラムによるアジャイルな組織変革"成功"ガイド: Ken Schwaber, Jeff Sutherland, 角征典, 吉羽龍太郎, 原田騎郎, 川口恭伸: 本</a>www.amazon.co.jp

2014-12-02

AWS Road Showまとめ

全体を通して

なんか入った時からスーツの人ばっかりだなーと思ってたけど、
どちらかと言うと既存企業向けの導入の話が多かったかな。
エンジニア的な話は少なくてちょっとがっかり。でも、

ワークショップ
Chat Worksの話
AWS re:Invent速報
企業ブース

は楽しかった！

基調講演

固定費、変動費、大企業への導入の話ばっかりだった。
正直おもしろくなかった。。。

ワークショップ

EC2上にAMIインスタンスを作って、
ELBでバランシングするとこまでできた！
普段だったら3000円ぐらいの１レッスンをタダで受けれた。
これでスケールアウトしやすいWebサービスを簡単に作れる。
...でも、他にもいっぱいAWSの機能あるし、
もっといろいろ勉強しないとなと思った。

Chat Worksの話

最初は社内ベンチャーで、
一人で開発したってすごいなと思った。

初期：レンタルサーバー
立ち上げ期：AWSへの移行
成長期：AWSでもスケールアウトしやすい構成に変更

という順当な感じで進化したのだな。
企業が成長するにつれてAWSの機能の意味がわかってくるらしい。
AWSで始めることで、将来まで安心できる感じいいなー。
いろいろと参考になった。

大きくなるとAWSの地雷を踏むから注意

ELBは暖気申請しないと落ちる
これぐらいの負荷がくるから準備してねってやつらしい。
RDSはProvisionedIOPSは必須
IO保証してもらわないとたまに遅くなるらしい。

S3へのユーザーからのダイレクトアップロード、ダウンロード機能

この機能があるとWebサーバー通さなくていいからいいなー。

現在のインフラの構成

User->ELB->AutoScalingEC2->ElasticCache(Session),DynamoDB->S3(Log)  
         ->RDS->ColudSearch  
         ->SQS->EC2(Back End)  
      S3->Glacier(Backup)　直接Upload,Download

AWS関係ないけど、groongaは1億レコードで潰れるらしい。。。やばいなそれは。

AWS re:Invent速報

玉川さんのAWS関連の本買いたいなー。

増えてるサーバー数

8000億円規模の企業時代のサーバー数と
同じ数のサーバーを毎日増やしてるとかやばい！
４５回も値下げできたのは、
規模の経済が起きてるからなのか。

新機能

Amazon WorkSpaces

仮想デスクトップ

Amazon Zocalo

ファイル共有

AWS Directory Service

共有ディレクトリ

Amazon RedShift

数PBまで使えるデータウェアハウス
すかいらーくで実績があるらしい。

Amazon Kinesis

データを２４時間だけ保持するサービス
スシローはリアルタイムで１５分後の売上を解析しているらしい。
すぐに捨てるデータにはもってこいだな。

Amazon RDS for Aurora

現状のRDBは複数のレイヤ(SQL,Transaction,Caching,Logging)
が一枚岩になってしまっているのでDBはスケールしずらいけど、
こいつだと簡単にできるらしい。
こんな感じらしい。

  パフォーマンス : MySQL5.6の5倍の性能
  ストレージ自動拡張 : 最大64TBまで  
  S3へ自動バックアップ
  データ暗号化

EC2 Container Service

Dockerコンテナ管理サービス。
今までEC2上に自分でDockerとかはよくある話だったけど、
それをサービスとして提供するらしい。
コンテナそのままデプロイいいなー。

Deployまわり

Cloud Formation : プロビジョン
Cloud Watch : モニター
Code Commit : プライベートGitリポジトリ
Code Pipeline : ビルド、テスト、デプロイの自動化
Code Deploy : デプロイツール,Gitとかからでも使える
Service Catalog : 複数サーバーのシステムをテンプレートの管理をして構成できる

この辺に関しては、Gitとか、Jenkinsとか、
今までAmazon以外に他の技術を使ってやらないといけなかったことが
全部On Amazonでできるようになるって感じ。
おもしろい方向性だな。

AWS Lambda

AWS上のイベントをトリガーに独自のコードを実行させられる。簡単な処理なら、もうサーバーなんていらないじゃんって考えらしい。
Lambda function(Java Script)をデプロイするだけで動作する。

企業ブース

そんなビジネスもあるんだーっていろいろと参考になった。
おもしろかったブースはこれかな

Splunk

Splunkのロゴの入ったキットカットもらった！
ステッカーもいっぱいもらった。
無料でダウンロードしてAWSのログ収集して、
サポートだけ有料っていうのがいいなー。

cloudpack

今までAWSって、小さい会社のサイト作るときとかは変動費だからって
結構導入しぶったりされることが多かったけど、
このサービスはAWS上のサーバーを定額提供するらしい。
他のVPSでも別にいいんだけど、
裏のサーバーがAWSっていうのが安心できる。

総括

まぁ、総括すると、これでタダとは、楽しかったなー。次はもっとエンジニア的なカンファレンスとかに行きたいな。がんばろうっと！
あ、ノベルティーいっぱいもらった。
f:id:kensanty:20141202170612j:plain

2014-11-22

認定プロダクトオーナー研修を受けてきた

認定プロダクトオーナー研修を受けてきた。

Minimize build and First release, Maximize outcome and impact.

のためにどうやって

ストーリー作りをしていくのか
アイデアを出すのか
アイデアを形にするのか

といったことが学べた。

印象に残っていること

プロダクトオーナーは、プロダクトチーム側のスクラムマスター

プロダクトオーナーは

Product Manager : 価値
Dev lead : 実現性
Design lead : ユーザビリティ

そういった人たちをチームとしてまとめ、

ストーリー、バックログを作成していくというのを

あくまで手助けしていくロールで、

決してプロダクトオーナーだけでストーリーを作るのではない、

というところは、Ah ha!（なるほど）と思った。

スクラムマスターもスクラムチームをとりまとめはするけど、

別になにかを決めるってわけじゃなくそれらをサポートするのが仕事

だから、似てるなと。

User Story Mapping

プロダクトバックログを作っていくにあたっては、

MVP : Minimize Vaiable Product(最低限生存可能なプロダクト)

を見極めるのが大事で、

それをチームで考える為に”ユーザーストーリーマッピング”という

手法を学んだ。

これらの考えと手法を生かしていくためにアピールがんばらないとな。

がんばろー。

2014-11-08

XL1200Xフォーティエイトマフラー交換

フォーティエイトのマフラーをバンスアンドハインズの、ショートショットに交換。パワービジョン(ECM書き換え)はとどいていますが、まだエアクリーナーは届いてないのでとりあえず、ノーマルで。

交換前

f:id:kensanty:20141108114147j:plain

外しました

f:id:kensanty:20141108114426j:plain 外す際手順としては - エキゾーストのカバーを剥がす - マフラーとエンジンをつないでいる部分を外す - マフラー下部、サイドのボディと固定している部分を外す - マフラーのステーが残るのでプライマリーカバーを外す ※この時デカイ六角が必要でなくて焦ってたら友達が突然ヘルプに来てくれました（笑） - ステーを外して、バンス用のステーに交換あとは逆の手順で付けていくだけです！

交換後

f:id:kensanty:20141108114446j:plain

レビューとしてはカナリ爆音。。。もはや爆発音。で、インジェクションはチューンしてなくてもまぁふつうに、ギクシャクせずには走れます、(燃料濃い。。。)。吹け上がりが良くなって気持ちよく加速します。バイクは楽しい！

2014-11-03

Mac上にVirtualBoxでLAMP環境構築

ふとWordpressで遊んでみたいなと思いMac上にUbuntuのLAMP環境構築

今回の目的はずばり

[ Macローカル上にて編集したものをすぐに見れる環境構築 ]

下準備

Virtual Box

https://www.virtualbox.org/

公式サイトからインストールして言われるがままにインストール

Vagrant

おなじみ、仮想環境管理用の最強ツールです。

https://www.vagrantup.com/

これもダウンロードして言われるがままにインストール

Berkshelf

Chefのcookbookの面倒な依存関係を解消してダウンロードするのに使います。

下記コマンドでインストール

sudo gem install berkshelf

時間がかかるけど待ちます。

これにて下準備完了。さてさてさっさとやりますか。

調理

作業用のディレクトリをworkspaceとします。

まずはChefのcookbookを手に入れましょう

workspace/Berksfile

を作成し、下記を記述

site :opscode

cookbook 'mysql'
cookbook 'php'
cookbook 'apache2'

cookbookをopscodeから取得しちゃいましょう！

workspaceにて下記コマンドを実行

berks vendor cookbooks

これでworkspace/cookbooksに必要なcookbookが揃ったはずです。

今回PHPなのでローカルで編集したものをすぐに見たいので、

apacheの設定だけVirtualBoxとの共有ディレクトリに変更しておきます。

ローカルに workspace/webapp ディレクトリを作成。

確認用index.phpの作成

echo '<?php echo "Hello LAMP";?>' > webapp/index.php

さて、お次はVagrantの設定

vagrant init ubuntu/trusty64

Vagrantfileができあがります。

僕の場合は下記設定だけにしました。

# -*- mode: ruby -*-
# vi: set ft=ruby :

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "ubuntu/trusty64"
  config.vm.network "private_network", ip: "192.168.33.10"
  config.vm.provider "virtualbox" do |vb|
      vb.customize ["modifyvm", :id, "--memory", "2048"]
  end  
  config.vm.provision "chef_solo" do |chef|
    chef.cookbooks_path = "./cookbooks"
    chef.add_recipe "php"
    chef.add_recipe "php::module_mysql"
    chef.add_recipe "apache2"
    chef.add_recipe "apache2::mod_php5"
    chef.add_recipe "mysql::server"
    chef.add_recipe "mysql::client"
    chef.json = {
          apache: {
                      docroot_dir:  "/vagrant/webapp",
                      default_site_name: "default",
                      default_site_enabled: true
                  }
          }
  end
end

起動！

vagrant up

さてさてあとはカプメンでも食べながら待ちますか。

。。。

完了したらローカルからアクセスできる様にファイヤーウォールを切ってしまって

vagrant ssh
sudo ufw disable

http://192.168.33.10/index.php

にアクセス。

LAMP環境完成！

ディレクトリは下記の様になってるはずです。

workspace/cookbooks　：　Chefのクックブックたち

workspace/webapp/　：　Document root

workspace/Vagrantfile　：　Vagrantの設定ファイル

workspace/Berksfile　：　Berkshelfの設定ファイル

あとはwebapp上でアプリをいじいじしていくだけですなー。

作業自体は１０分ぐらいかな。

(2014/12/11 指摘があったchefのattributeの件修正しました！)