やったこと

Apache ＆ Nginx

年末に宣言していたとおり，ApacheとNginxの本を購入．
さらっと読み流すものの，Nginxの理解はまるでできていません．

AWSのインスタンス立てて，マスタリングNginxの始めのページの方をちょろちょろっといじって，location, serverディレクティブの階層関係はとりあえず理解しました．

なにげに初AWSで，アクセスログ＆セキュリティログみるとおびただしい量のログ流れてて，マジ怖ぇーって体験をした感じです．
うかつにポート開けれなくて，はじめはRabbitMQとか建てようと思ってたんですが，AWSでやるの諦めました
（社内クラウドやVagrantで建てたVMにRabbitMQサーバ建ててます）

Spring 4 & Spring Boot

1月に日本オラクル本社で開催された【東京】JJUG ナイトセミナ 「Spring Framework 特集」 に参加してきました．

最近のSpring関係で話題なのが，Spring 4のリリースで，なんとiBatisとStrutsのサポートを終了するという話を聞いてきました．
社内では Spring + Struts + ibatis というプロジェクトもちらほらあり，Spring 4移行は結構骨が折れそうなイメージを持ちました．

Spring的には「Hibernate使え」とのことなので，そういう流れになるといいなぁ・・・

もうひとつの目玉がSpring Bootで，これは自分的に結構気に入ってます．
というのも，ウェブアプリケーションをスタンドアローンで起動できるというヤバい機能を持っているところに惹かれました．

通常，JavaでWebアプリケーションプロジェクトを開発して動作確認するには，Eclipseを使い（すでにここでイケてない），Tomcatサーバを設定し，プロジェクトとサーバを紐付けて，サーバを起動する，という手順が必要です．
最近では，Intellijもボチボチ普及し始めてきてるのですが，上記のような手順は解消できず，「Intellijで開発」→「Eclipseを立ち上げてサーバ起動して動作確認」という，なんとも頭の悪い方法で開発せざるをえません（実際やった）

ところが，Spring Bootを使うとこの問題が解決されます．エントリーポイントのクラスを用意しておき，mainメソッドを実行するだけでデプロイ済みのTomcatサーバが立ち上がってしまいます！！！

@ComponentScan(basePackages = {"my.springboot.sample"})@EnableAutoConfiguration()public class Application {    public static void main(String[] args) {        SpringApplication.run(Application.class, args);    }}

これは非常に便利で，サーブレットコンテナ自体もバージョン管理システムで共有可能になる（Mavenの依存関係として保持）上，「このmainメソッド実行したらTomcatサーバ立ち上がるしー」とだけ言えばいいので，引き継ぎが楽になるという利点があります．

社内でSpring Boot広めていきたいのですが，残念ながらSpring BootはSpring 4以上にのみ対応しており，上記で述べたとおりiBatisが使われている以上，移行できないという問題に直面しています．
新規Springプロジェクトでは，ぜひともSpring Bootを採用してほしいです（切実）．

余談ですが，社内で数少ないiBatis & Strutsを使っていないプロジェクトをブランチ切ってSpring Bootに適応させてみました．
ロギングプラグイン周りの依存関係やSpringのApplicationContextを読み込ませる辺りでかなり骨が折れましたが，一応動作するようになりました．

AMQP and MQTT, with RabbitMQ

最近のはてダでMQTTの話がボツボツ出始めたので，流行りに乗っかって勉強しました．

まーやっぱアレです．既に実装されたものがあるなら，使って体系的に覚えるほうが理解が進みますね．

今回本当にそう痛感した理由が，MQTTプロトコルでRabbitMQをBroker（メッセージ仲介役．キューとかを持ってる）としてメッセージパッシングやってみたとき，Brokerでどういう挙動をしているか観察したことによります．

デフォルトでAMQPをサポートしているRabbitMQでは，プラグインを利用することでMQTTプロトコルも利用できるようになります．
そのとき，RabbitMQでは，AMQPの仕組みを利用してMQTTプロトコルを処理するように実装されているため，見かけ上はMQTTプロトコルを捌くブローカーですが，内部ではAMPQを処理しています．
プラグインがうまいことやってくれてる感じですね．

そのため，MQTTプロトコルで通信したときの様子をrabbitmqctlコマンドで状態を確認したところ，AMQPの仕組みについて理解が深まりました．
なんとも不思議な順序ですが，AMQPの理解が進んでとても満足しています

半分ぐらいは理解したので，あとは疑問に思ったところを実際動作させて結果を見て仕組みを知る，という流れで理解を深めていきます．

ちなみに，この辺は日本語ドキュメントが非常に少ないので，実際AMQP/MQTTのクライアントのコード追ったほうが早いと思ってます．

来月に向けて

プログラミング言語 Erlangの習得

「RabbitMQでMQTT動作させてるときって内部ではAMQPとして動いてるのかなー」ってつぶやいたら，「RabbitMQのMQTTプラグインに書いてるやろ．読めや」みたいな感じでリプライ飛んできたので（大幅な誇張表現あり），Erlang製のRabbitMQの仕組みの理解を深めるためにも，Erlangの習得は不可欠だと感じました．

飛行機本を本日Amazonで購入したので，明日の月初から触り始めていきます．

プログラミングErlang/オーム社

￥4,620

Amazon.co.jp

目標は．「え？？？今どきLisp？？？ｗｗｗｗｗｗマジウケルｗｗｗｗｗｗ」とLisperの皆さんを煽るレベルにまで使いこなせるようになるところです．

Serverspec & Chef

今月から，サーバの移設タスクがどっと来るので，いい機会なのでServerspecのテスト＆実行環境と，Chefのレシピをゼロから作ります．

Chefは社内でも実績多いですが，Serverspecはまだ1プロジェクト程度なので，これを気にどんどん広めていくつもりです．
NWの制約的に難しくなる可能性もあります（インフラチームのポリシー）が，Jenkinsからserverspecのテストを叩ける状態にまで持っていければ，おそらく万全でしょう．

お疲れ様です．はまじです．  
今年の振り返りをやってみようと思います．

割りと，自分の忘備録的な感じに仕上がってしまったので，記事としては面白くないと思います・・・．

一気に書くと長いので，月次でまとめてみました．

月次まとめ

1月

• 学生最後の年．修論に勤しむ
• おばけキャッチ にハマる．

2月

• 修論提出＆公聴会
• 研究室からの朝帰りで，他に誰もいない家で父がエロいビデオ見てたのを目撃（人生初）
• 修論旅行で九州の別府 → 湯布院 → 福岡をへ．湯布美人の生酒がクソうまかった

3月

• グランツーリスモ5 でイベント戦 鈴鹿1000km を攻略
  • GTカーで1:58台をコンスタントに出せるようになった
• 東京に引っ越し．会社のシェアハウスへ．

4月

• 入社．惰性で続けてしまうと思っていたオンラインゲームをビタッとやめる
  • 正直，自分でも驚いた．
  • 結局 引退はしてなくて続けているんですが（12/30現在）

5月

• 研修で使用していたコードレビューツールをメンテ（主にリファクタリング）
• 企画と開発を両方やるエンジニアになると意気込んでいたが，自分にあわないと気づいたので開発一本で頑張ろうと決心
• このころに研修で書いてたユニットテストについて，後々同期から関心のお言葉をいただく（あれはむしろ煽りだったかも）．

6月

• 配属
  • 社内でも中核で重要なプロジェクト（の管理面）を担当することになった
    • ユニットテストがほぼなく，自分の理想とする状態から結構離れててちょっと失望気味だった
• PlayFramework（Java）とSpring Framekwork3を触り始める
  • 同期で勉強会開始．
• デザインパターンの重要性に気づき，ちょこっとずつ勉強を始める．
• 自分の身につけていた技術と会社で使用されている技術に大きく乖離していることに気づく
  • 所詮，Railsだのherokuだのっていうのは，あくまでスタートアップの話で，100万人単位のユーザにサービスを提供できる技術の情報は，Webで簡単に拾ってこれないと気付かされた．

7月

• インフラ研修．
  • Ciscoのルータとか触れたのが非常にいい経験だった．
  • VMware Workstationがほしくなる

8月

• 自分の担当サービスのリファクタリング案を考えてたりしてた
• 大学の後輩に銀座で寿司を奢る
• Hotspot VM（Java VMの代表的なもののひとつ）について記事集めまくってた
  • 正直なところ，当時勉強していたことは身についてない．要再学習

9月

• 新しく別のプロジェクトを担当することになったが，こちらもテストがほぼなかった．
  • Springの使い方も慣れてきたので，プロジェクト内に始めてユニットテスト作成．
  • 後日，先輩が自分のを参考にしてくれた
• serverspec というサーバの状態のテストを行うテストフレームワークを触り始める
  • 人生初Pull Request ＆ マージ
  • そのときのうれしさは文字に表せない．これを気にOSSへの貢献を続けたいと思った．

10月

• 技術研修

  • とりあえず講師がすごい．スーパーマン
  • ふだんなかなか構築する機会の少ないLDAPやHeartBeat，DRBDの構築を体験することができた

• serverspecにpull requestを送った箇所を，Qiitaに記事投稿しようとして色々調査した結果，自分の修正箇所が微妙なんじゃないかという疑念に駆られる

• いろんなのサーバが混在していると有用なので，台数が多いプロジェクトでは有用なんだけど，当時は変な改良加えてしまったと思い込んで相当凹んでた．
  • ちょうどこの時期にこのタイトルの記事を見つけてしまったので，更に凹む “誰がオープンソースソフトウェアを酷いものにしてしまうのか - 人生が二度あれば  ”
• 一応Qiitaにまとめてはいます．sudoコマンドのメッセージを変える方法 - Qiita [キータ]
• ワンナイト人狼 にハマる
• 鈴鹿でF1を楽しむ

11月

• 同期が必死こいて深夜遅くまで開発作業しているのに対し，自分の担当プロジェクトには案件が余り入ってこなくて（つまり暇で）危機感を覚える
  • いま自分のいる場所が，経験を身につける場所としては不相応な場所だと察知．勉強会に参加しようと決意
• 怖いScala に参加
  • 実はScala触り始めて3日目だったんですが，いい感じで意識改善できた気がする．

12月

• 勉強会2回参加（第8回Jenkins勉強会，渋谷.rb[201312]）
• Sensu というリソース死活監視ソフトウェアを触り始める
  • ついでにSensuで使用されているRabbitMQとRedisについても学んだ
  • とくにRabbitMQは社内でも結構使用されているミドルウェアだったので，Sensuを介してAMQP（Advanced Message Queue Protocol）を勉強できたのは本当によかった．
• 社内のとあるserverspecのプロジェクトで，自分が貢献したコードを利用していることを発見．
  • この改変はあまり公にしていなかったので（もしかしたら開発者のmizzyさんが情報をまとめてくれたのかもしれませんが），まさか社内で使われるとは思ってなかった．
  • 超絶嬉しかったです．自分の実装した機能がユーザに使われるよりも，自分よりも経験と実力のある技術者に認めてもらえたような気がして嬉しかったです．
• 一時的に落ちてたserverspecへの熱意を取り戻して，自分の担当プロジェクトのserverspecを記述開始．
  • Rakefileの使い方もここで勉強

まとめ

学生から社会人へパラダイム・シフトした年なんですが，社会人になってからの方が勉強しましたし，学んだことが多かったです．
採用面接時に即戦力と大口叩きまくってたので，もし過去にタイムスリップできるなら自分をぶん殴りたいです．

また，住居が東京になったことで，話題の勉強会に参加しやすくなりました．
11月以降からそれを有効活用し始めてますが，もっと早く動けばよかったと若干後悔しています．
今後どうなるかわかりませんが，とりあえず東京にいるうちに色んな勉強会に参加して，学ばせていただこうと思います．

来年に向けて

来年はミドルウェアをメインに勉強していくつもりです．
とりあえず上半期はApacheとnginxをはじめとして，軽量なもの（webrick）も含めたWebサーバ全般と，サーブレットコンテナ（＋APサーバ）も触っていこうと思ってます．

そのほか，現在勉強中のRabbitMQや，Nettyを使用して実現された非同期通信を提供する社内ライブラリの勉強といったところでしょうか．
（Nettyの非同期通信ライブラリは使いこなせるようになりたいと思ってます）

DB周りに関しては，いまのところ業務で触る機会がないので，DBメインの案件抱えたときに勉強し始めます．

あと，OSSへの貢献も活発にしていきたいです．

最後に

今年は様々な方にお世話になり，またご迷惑をお掛けしてしまいました．
お世話になった方には心からの感謝を，ご迷惑をお掛けした方には心からの謝罪を申し上げます．

未熟者ではありますが，来年以降も精進してまいりますので，ご指導ご鞭撻の方宜しくお願い致します．来年も宜しくお願い致します．

Strategyパターン

例えば，じゃんけんのプログラムを書きました．
このUserクラスは，ずっとグーを出し続ける戦略を採っています．

enum Hand {    BLOCK,    SCISSORS,    PAPER;}class User {    private String name;    private int wons;    public Hand getHand() {        return Hand.BLOCK;    }}

このクラスのインスタンスだけでじゃんけん大会すると．．．結果は悲惨なことにｗ
なので，別の戦略を持ったユーザクラスを作りたい．．． と思ってはいけません！

※悪い例

class RandomHandUser extends User {    private static Hand[] hands;    static {        hands = new Hand[]{ Hand.BLOCK, Hand.SCISSORS, Hand.PAPER };    }    @Override    public Hand getHand() {        return hands[(int)Math.random() * 3];    }}

さて，これで何が問題なのかJavaに詳しい人は一発でわかるでしょう．
そう，nameとwonsが名前解決できません．
何故なら，Userクラスで定義された上記フィールドはそれぞれprivateなため，子クラスに継承されません．

ならばprotectedにすればいい？いえいえ，それは設計の過ちです．
protectedはabstractクラスなど，ほぼ継承されることがわかっているときに使えばよく，Userクラスのような通常のデータはprivateであるべきです．

ではどうすればいいのでしょうか．

答えは，Userクラスの中に戦略フィールドを用意することです．

どういうことかというと，今まではUser#getHandの中で実装していましたが，これを別のクラスに委譲してやればいいのです．

まずは，「getHand()を呼べば，何かしらのHand型が返ってくるメソッドが必要」であると考えられます．
Userクラスでも同じメソッド名で呼び出しますが，そうではなく「じゃんけんの戦略に対してgetHandする」という考えを持ってみます．

そうすると，必然的に次のインターフェースが思い浮かぶことになります．

interface HandStrategy {    public Hand getHand();}

ではこの戦略を実装した，「グーしか出さない戦略クラス」を作りましょう．

class OnlyBlockHandStrategy implements HandStrategy {    @Override    public Hand getHand() {        return Hand.BLOCK;    }}

という感じで，どんどん戦略クラスを作っていきます．
で，これらの戦略クラスをユーザが個別に持てるようにします．

class User {    private String name;    private int wons;    private HandStrategy handStrategy;    public Hand getHand() {        return handStrategy.getHand();    }}

で，mainのコードはこうなりますね．

public static void main(String[] args) {    User alice = new User();    alice.setHandStrategy(new OnlyBlockHandStrategy());    User bob = new User();    bob.setHandStrategy(new OnlyScissorsHandStrategy());    // …………}

さて，ボブはアリスに全敗を喫し，高級寿司を奢らされる羽目になりました・・・．

という感じで，ひとつのクラスのとある区画（アルゴリズム）をごっそり入れ替えることができる，Strategyパターンについて紹介しました．

ちなみにこれ，こうすると見たことありませんか？

class User {    @Autowired    private HandStrategy handStrategy;    // …………}

そうですね，Spring Frameworkでも使用されているDependency Injectionですね．
どの戦略を入れるかはDIコンテナに依存し，中身をごっそり変えることができます．

もはや無意識のうちに使ってしまうぐらいの超頻出デザインパターンなので，ぜひ理解しましょうー

byobuについて（導入編）

最近サーバ管理でログを確認するために，複数台のサーバに個別でログインしてlessコマンドやgrepコマンド叩いてるわけなんですが，10台超えてくるとさすがに面倒になってきました．

最低でも，複数のサーバの状態をひとつの画面で見たいと思ったので，byobu を導入いたしました．

byobu

こちらは公式ホームページです．

ターミナルにscreenではなくbyobuを使うべき100の理由

ちょっとアレな解説ですが，基本的な使用方法を抑えている簡単なマニュアルです

業務中，複数のサーバに対してアプリのデプロイをすることになったので，デプロイ先のサーバにログインして，ログをtail -fで表示し，確認作業を行う必要がありました．

ただ，それが1台のサーバだけではなく，複数同時にデプロイすることになったので，デプロイ先の数だけターミナルを立ち上げてそれぞれサーバにログインして・・・という面倒な作業をおこなっておりました．

さらに，10個ぐらい同時にターミナルウィンドウが立ち上がってるせいで，Alt+TABでウィンドウ間を移動するのが困難であり，いちいちマウスを使ってウィンドウを選択しなければなりません．  

byobuでは，1つのウィンドウを複数に分割でき，ウィンドウ間をキーボード操作で簡単に移動することができます．
Alt+TABではどこに飛ぶかもわからない状態でしたが，byobuを使うことで上記のウィンドウ選択にマウスを使う煩わしさから解放され，思った場所へすぐに移動することができるようになりました．

byobuですべての分割ウィンドウにコマンドを送る方法

で，確かに便利にはなったのですが，どうせならサーバに一括でコマンド送信したいですよねー！という想いがでてきました．

各サーバで実行する（ログ確認用の）コマンドは全く同じなので，複数のウィンドウに対して一括でコマンドを送信したいわけです．

ということで，色々調べておりました．

byobuはscreenをより使いやすくしたという位置づけですが，スタンドアロンではなくバックエンドにscreen/tmuxが動いておりp，そのフロントにbyobuが動いている，という感じです（合ってる？）．

なので，byobuのバックエンドがtmuxであれば，tmux専用のオプションもbyobuで使用することができます．

ということで，byobuで以下のコマンドが使用出来ます．

byobu set-window-option synchronize-panes on

こうすることで，1つのシェルのなかで分割されたすべてのウィンドウに同じコマンドを送ることができます．

「やったーこれでログ管理楽になるぞー」と思いきや，面倒な事態に．

サーバにログインした後ではbyobuのset-window-optionを実行できないという問題が起きました．

まぁ考えたら当たり前なんですが，ローカルから各分割ウィンドウ（ログインサーバ）に対してコマンドを送る方式になっているので，サーバにログインする前にset-window-optionを実行する必要があります．

で，さきにset-window-optionを実行しちゃうと，ここで弊害が．

ssh -l hamaji-dev myserver01

例えば，サーバが10台あって，それぞれmyserver01～myserver10までホスト名が割り振られていたとすると，set-window-optionを先に実行すると，すべての分割ウィンドウで上記コマンドが実行され，同じサーバにログインしてしまうという問題があります．

byobuで複数ウィンドウから別々のサーバにログインする方法

前置きが超長くなったのですが，シンプルな解決策です．

各分割ウィンドウに対して，同じ変数を用いてログイン先をそれぞれ指定する方法です．

% login_to=myserver01
% # set login_to variables on each divided window


% byobu set-window-option synchronize-panes on
% ssh -l hamaji-dev ${login_to}


$ grep hogehoge /path/to/log

どうでしょうか？初回実行時は「気持ち悪ｗｗｗ」と思いましたが，超便利です．

ちゃんと同じコマンドが送られるように，各ウィンドウの同期（目視）する必要はありますが，1回のコマンドでできるのは超便利です．

とは言うものの，各分割ウィンドウで変数設定しないといけないのが若干面倒ですね・・・．  

今日はJavaのGenerics（ジェネリックス）について，Effective Javaを読みつついろいろ試験コード書きながら紹介していこうと思います．

自分もGenericsについて完全に理解していなかったので，自分の勉強も兼ねてますｗ

そのまえに，前提として以下のような関係のクラスがあると想定しています．

class Card {
}
class Joker extends Card {
}

初級編

Genericsについてあまり知らなくても，こんなコードを頻繁に見かけるのではないかと思います．

List<String> list = new ArrayList<String>();

この list には，String と，String を継承したクラスのみをリストに格納することができます．

これを型安全であると言います．そして，指定した String クラスのことを総称してパラメータと言います．
こうすることで，list には String（とその子クラス）しか入れられない，入っていないことが保証されるため，コンパイラが容易にエラーを検出することができます．

では型安全でないコードとはどういうものかというと，こんなコードです．

List list = new ArrayList();

このコードをコンパイルした時に，警告が出ると思います．

これは型チェックされていないことによる警告で，要素に対して呼び出すことのできるメソッドも限られる上，キャストに失敗して実行時エラーになることもありえます．

さきほどの List<String> をパラメータ化された型と呼ぶのに対して，List を原型と呼びます．

で，さきほどパラメータに指定したクラスと，そのクラスを継承したクラスが許可されれるということをお話ししました．

なので以下のコードは正常動作します．

List<Card> list = new ArrayList<Card>();
list.add( new Joker() );

ちなみに，Java7からインスタンス生成時の型省略が可能（ダイアモンドオペレータ）になりました．
つまり，以下の２行は同義です．

List<Card> list = new ArrayList<>();
List<Card> list = new ArrayList<Card>();

中級編

Genericsを用いてクラス・メソッドを実装する場合，それぞれどのようにすればいいのでしょうか？

Genericクラスを作る

Genericクラスはこんな感じで作れます．

class MyGene<E> {
}

MyGeneクラスでは，内部で使用するためにEという仮のパラメータを宣言しておくことで，内部でひとつの型として使用することができます．

こうすることで，フィールドやメソッドの戻り値・引数として仮のパラメータを使用することができます．

class MyGene<E> {
    private E elem;

    public E getElem() {
        return elem;
    }

    public void setElem(E elem) {
        this.elem = elem;
    }
}

ここで注意しておくべき事項として，Genericクラス内では仮パラメータのインスタンスを生成できないことがあげられます．

また，今回詳しく触れませんが，仮パラメータの配列の生成も禁止されています．

GenericクラスではないクラスでGenericメソッドを作る

さて，Genericクラスではない普通のクラスのなかでも，仮パラメータを使用したメソッドを作ることができます．
ということで，Genericメソッドはこんな感じで作成します．

public <E> void map(List<E> list, E elem) {
    //something
}

メソッドの修飾子（public, private, protected, final, static）後と返り値の間に仮パラメータを宣言すると，そのメソッドの宣言部とメソッド実装内部で仮パラメータを使用することができます．

ちなみに，仮パラメータに対して制限をかけることもできます．

例えば，「Cardクラスとその子クラスだけを許可したい」という場合は，それぞれ下記のようになります．

class MyGene<E extends Card> {
    // can use methods defined in Card class.
}

class NonGene {
    public <E extends Card> E something(E elem) {
        // can use methods defined in Card class.
    }
}

こうすることで，仮パラメータEは，Cardクラスかその子クラスであることが保証され，Cardクラスで宣言されたpublicなメソッドやフィールドを使用することができます．
なお，<E extends Card> のことを，境界型パラメータと呼びます．

上級編

さて，このコードは「正常動作」「実行時エラー（もしくは実行時意図しない結果）」「コンパイルエラー」のどれでしょう？

List<Card> list;
list = Arrays.asList(new Joker[5]);

答えは コンパイルエラー です．

何故か考えていきましょう．

list は List<Card>型のインスタンスです．

それに対して，Arrays#asList は（仮パラメータをTとして） T[]型を引数とし，List<T>型を返します．

つまり，Arrays.asList(new Joker[5]) は List<Joker> を返すわけです．

JokerクラスはCardクラスを継承してはいますが，List<Joker> は List<Card> を継承しているわけではないので代入できない，ということになります．

ArrayList<Card> list = new ArrayList<Joker>(); が通らないのと一緒ですね．

これを回避する方法が次のようになります．

List<? extends Card> list;
list = Arrays.asList(new Joker[5]);

このワイルドカードの使用方法によって，list に代入できるのは List<Card> をはじめ，Cardクラスを継承したクラスをパラメータ型としたジェネリック型（ややこしい！）です．

なお，List<? extends Card> のことを 境界ワイルドカード型 と言います．

ちなみに逆（Collections#toArray() ）はどうでしょうか？

List<Joker> list = new ArrayList<>();
Card[] cards = list.toArray(new Joker[0]);

これは問題なく通ります．

Card[] cards = new Joker[5]; が通るのと同じ原理です．

しかしながら，以下のコードはコンパイルエラーを検出してくれません・・・．

実行時エラー（ArrayStoreException）で落ちます．

List<String> list = new ArrayList<>();
Card[] cards = list.toArray(new Card[0]);

toArray()の内部で（厳密には違いますが ）引数の配列の要素に対して代入をしているわけです．

最後に，ワイルドカードを使用した問題を紹介します．

どうなるでしょうか？

List<? extends Card> list = new List<>();
list.add( new Card() );

答えは コンパイルエラー です．

ワイルドカードのパラメータに対しては，null以外のいかなる要素も代入することができません

(参照：Effective Java P.111)．

これはコンパイラが防いでいるらしいです．

Eclipseのコンテンツアシスト等の補完機能で確認すると，null型しか代入できないような補完内容になると思います．

最後に

アプリ実装程度なら，中級以上のテクニックはあまり使わないとは想いますが，知っておくことで実装の幅が広がるのではないでしょうか？
今回，ブログの記事を書きながらEffective Javaを読みつつ，コードを書いて確かめることによって，とても勉強になりましたし，Generics使ってライブラリ作ってみたくなりました．

おまけ

今回からデザインパターンシリーズということで，各回１つずつ（2つもあるかも）デザインパターンをご紹介していきます．

Chain of Responsibility パターン

Chain of Responsibility パターンは，いわゆる「責任のたらい回し」です．

自分自身の手に負えないものは別のやつに任せよう，という感じです．

普通やってしまいそうな，大元のクラスのメソッドのなかで if文を山のように書くというクソみたいな方法が，このパターンを適応するとすごいシンプルになります．

最近ポーカーの役判定プログラムを書いていましたが，複合役のないポーカーではまさにうってつけのパターンだと言えます．

試しにパターン適応前のコードの例をお見せします．

public int getMatchedPokerHand(Player player) {
    Hand hand = player.getHand();
    if (hand.isRoyalStraightFlash()) {
        return ROYAL_STRAIGHT_FLASH;
    }
    if (hand.isStraightFlash()) {
        return STRAIGHT_FLASH;
    }
    if(hand.isFourCards()) {
        return FOUR_CARDS;
    }
    // continues...
}

普通のポーカーなら役の数が少ないのでまだましですが，これが100個とかになってくると発狂してきます．

麻雀のような複合役のあるものには適応しづらいですが，判定方法が複雑かつ順序が決まっているものに対して効果抜群の効力を発揮出来ます．

設計

こんなかんじです．

役クラスを抽象クラスにしておき，それを継承した子クラスで判定方法実装するという形になっています．

コード

とりあえず重要なところだけを抜粋してお見せします．

PlayerクラスとかHandクラスとか，中身は妄想してください．

あと，AbstractPokerHand#matches の引数がPlayer型なのは，可読性向上のためにわざとやってます．

AbstractPokerHand.java

public abstract class AbstractPokerHand {
    private AbstractPokerHand nextPokerHand;
    private String pokerHandName;

    public AbstractPokerHand(String pokerHandName) {
        this.pokerHandName = pokerHandName;
    }
    public AbstractPokerHand setNext(AbstractPokerHand next) {
        this.nextPokerHand = next;
        return next;
    }
    public final AbstractPokerHand getMatchedPokerHand(Player player) {
        if ( this.matches(player) ) {
            return this;
        } else if (nextPokerHand != null) {
            return nextPokerHand.getMatchedPokerHand(player);
        } else {
            return null;
        }
    }
    protected abstract boolean matches(Player player);

    @Override
    pubilc String toString() {
        return "Your hand is " + this.pokerHandName;
    }
}

RoyalStraightFlash.java

public class RoyalStraightFlash extends AbstractPokerHand {
    public RoyalStraightFlash() {
        super("Royal Straight Flash");
    }

    protected boolean matches(Player player) {
        Hand hand  = player.getHand();
        return hand.isFlash() && 
            hand.containsCardNumberOf(10) &&
            hand.containsCardNumberOf(11) &&
            hand.containsCardNumberOf(12) &&
            hand.containsCardNumberOf(13) &&
            hand.containsCardNumberOf(1);
    }
}

TwoPairs.java

public class TwoPairs extends AbstractPokerHand {
    public TwoPairs() {
        super("Two Pairs");
    }

    protected boolean matches(Player player) {
        Hand hand = player.getHand();
        return hand.getNumberOfPairs() == 2;
    }
}

Poker.java

public class Poker {
    public static AbstractPokerHand getHandRule() {
        AbstractPokerHand royalStraightFlash = new RoyalStraightFlash();
        AbstractPokerHand straightFlash = new StraightFlash();
        AbstractPokerHand fourCards = new FourCards();
        // continues…
        AbstractPokerHand onePair = new OnePair();
        AbstractPokerHand noPairs = new NoPairs();
        royalStraightFlash.setNext(straightFlash).setNext(fourCards)
            .setNext(continues…).setNext(onePair).setNext(noPairs);
        return royalStraightFlash;
    }

    public static void main(String[] args) {
        Player player = new Player();
        AbstractPokerHand handRule = getHandRule();
        player.setHand( Hand.createStraightFlashHand() );
        System.out.println( handRules.getMatchedPokerHand(player) );
        // => Your hand is Straight Flash
    }
}

どうでしょうか？

if文の数も2回で済み，ネストもほとんどなく実装できます．

開発現場でガード節っぽい if文が山のように出てきたときにこのパターンを適応できないか考えてみましょう！！

簡易記法系の言語の風習？として、H1タグやH2タグ直下に下線（hrタグ）が引かれています。
アメブロでもできないかいろいろ試行錯誤してみた結果、フリープラグインで解決することができました。

アメーバのブログ管理画面（投稿画面）の左のメニューから、「プラグイン追加」という項目があります。
そこに飛んだ後、「フリープラグイン」というタブを選択すると、空欄のテキストボックスが出るはずです。
そこに以下のHTMLをコピペしてください。

<style type="text/css">
article h2 {
  border-bottom: 1px solid #999;
}
</style> 

技術研修が始まってもうすぐ1週間ほどたちます．

今はJavaの基礎的な講義を受けつつ，チャレンジ問題を解いています．

解いたチャレンジ問題は，何名かのプログラムがピックアップされて講師とともにコードレビューしています．

そんななか，今日はちょっと反省したいことがあってブログを書きました．

内容に即しましては，matabesuさんのブログ を先にご覧になってからお読みください．

「怖かったよ」

コードレビューすごい好きなんですが，我を忘れてしまうことがあります．

新しくアプリを開発することより，他人のコードを読んで学び，他人のコードをより良くしたい気持ちが強いです．

今日はそれが行き過ぎてしまったせいで，周りから見た自分が威圧的だったというふうに教えてもらいました．

言われた時にはっとしました．

たしかに今日は，熱狂しすぎていて，相手の心のことを考えずにコードの良し悪しについて一方的に持論を述べていたときもありました．

また，昨日は Shibuya.rbというプログラミング言語Rubyのコミュニティイベントに参加していたこともあって，レビューに出られませんでした．
昨日のレビュー中のことに関して，matabesuさんのブログ を教えていただいたので読んだところ，かなりグサグサささりました．

心に留めて，明日以降自分の態度改善に尽力したいと思っています．

やめろ

コードレビューでは，とあるツールを使用しているんですが，このツールにはお遊び機能があります．

ソースの指定行やソース全体にコメントを投稿することができるのですが，隠し機能としてコマンドコメントを使用することができます．

各プロジェクト毎にHP（体力）が設定されており，コマンドコメントで増減できるという，遊び心満載のツールです．

ですが，今日はこの隠し機能が悪用され，レビュー中にも関わらず，コメントが荒れることになりました．

さらにまずいことに，このHPがなくなると画面全体がブルースクリーンになるブラックジョーク的なものが存在し，レビューが妨害される事件が発生しました．

さすがに耐えかねて，名指しでコメントを発しました．

○○○，レビュー止まるからやめろ

指名相手はよく話しているので，向こうも深く受け止めはしなかったと思いますが，同じプロジェクトを見てる全員にこのコメントが見えたせいか，一気にコマンドコメントがなくなりました．

おそらくここで空気が変わり，まじめに取り組むようになった人，コメントをやめて別の趣味に行った人など，様々あったと思います．

別の言い方をすると，場の空気を凍りつかせてしまったとも言えます．

これは自分の言い方の仕方が悪かったせいで，恐怖感を植えつけてしまったのかもしれません．

コマンドコメントがなくなって安堵感が得られた反面，周りの皆に対して空気を壊してしまったという問題がありました．

これは今後気をつけるべき事項であり，1対1でしゃべるのではなく，周りの人達がその会話を見ているという意識を，もう少し持つ必要があると痛感しました．

最後に：自分からのお願い

まず，同じ会社の同期として，他人のコードをレビューするという研修の一環であるというときに，遊び呆けてさらには妨害するという行為を許せません．

僕らはすでに社会人として，会社からお金をもらって研修を受けているのに，その報酬に対して貢献しないことに対して非常に憤りを感じます．

このレビュー会は参加必須ではないので，妨害するなら初めから参加しないでほしいです．

大学時代の頃から，他人のコードを見る機会を非常に大切にしていて，コードレビューには本気で取り組むことができます．

自分にとってソフトウェアエンジニアとして最も成長できる機会がコードレビューだからだと確信しています．

誰だって自分が本気で取り組んでいることに対して邪魔が入るのは嫌で，その人に暴言を吐くことだってあると思います．

つまらないコードレビューをやっていると思うかもしれませんが，なかには全力で取り組んでいる人がいることを忘れず，邪魔をしないように気を配っていただければ，僕にとってこの上ない幸せだと思っています．

曽山さん流 成長の習慣

成長とは

知らない自分に出会うこと

1. 限界に挑戦する


2. 挫折する


3. 挫折を乗り越えた時に成長する

成長の習慣

1. 年上の人に相談


2. 自分の思考を紙に書く


3. 経験者の本を読む

学んだこと

会社の人間の特徴を見抜く人事の部長らしい（上から目線すみません；；）アドバイスをいただきました．

自分の限界に挑戦することおよび他人を参考にするということが重要であると感じました．

小池さん流 成長の習慣

やりたいことを実現させるには？

自分自身のサイズをどんどん大きくし，やりたいことを自分の中に取り込む（イメージ）

成長の習慣

1. 自分サイズをどんどん大きくすることを心がける


2. 成功イメージを追求する


3. よりタフな（難しい）道を選ぶ

学んだこと

非常に簡素にまとめていただいたアドバイスですが，中身としては「やりたいことをできる自分になる」という趣向だと感じました．
今できなくても，それをするために自分をどんどん大きくしていこう，というありがたいアドバイスです．

「野望」を「目標」にするために自分を大きくしたい，そう思いました．

山内さん流 成長の習慣

サバイバルレースが開幕

強力なライバルが多数いるなか，どう生き残っていくかが重要

成長の習慣

1. 新人こそ巧遅拙速であれ（巧くて遅いより，拙くても速くあれ）


2. 大局観と嗅覚を身に付けるべし


3. 学習レバレッジ（小さな努力で大きな学習効果）を最大化せよ


4. 大志に本気になれ


5. 身近に目標を創れ


6. 反骨精神と素直さを共存させる


7. 不可能を可能にする心構え


8. チャンスに慣れるな（本当のチャンスは10年に1度くらいしかこない）


9. 自分自身で答えを必ず持つ（創る）


10. アンダーグラウンド（現場）が一番タフだ


11. とことん1番にこだわれ


12. 隣に座っている仲間の成長に責任を持て

学んだこと

マイクを持たせた自分みたいな感じで（笑），非常に多くのアドバイスをいただきました．
これらひとつひとつに山内さんの想いが篭っていることでしょう．

全てを満たすことは難しいとは思いますが，このなかで特に自分が足りていないもの（特に4番だと自負しています）を磨こうと思いました．

内藤さん流 成長の習慣

「市場」マーケットの本質を見ぬくための習慣

1. マーケット（今）をよく見る


2. 機会を集中する


3. 相対的に考える


4. 競争のルールを理解する


5. 限られた時間から，タスクと目標と優先順位を決める


6. 目標をマネジメント（動的変更）する


7. フローとストックのバランスをとって学習する

学んだこと

これまでとは打って変わり，非常に具体的かつ現実的なアドバイスをいただきました．
「今」に最も注視し，最大限の力を「今」発揮しないことには，成長した未来がないという，内藤さんの暗示だと感じました．

刻々と変化する状況に応じて目標を変更するというアドバイスも，その現れなのではないか，と捉えています．

僕としては，一番しっくりくるアドバイスをいただけて，非常に参考になったと感じております．

与えられた機会を大切にし，注力することを心がけて取り組む所存です．

まとめ

CA8という役員8名のうち，4名からありがたい講演を賜りまして，非常に感謝しております．

後日，残り4名からも講演していただけるということは，またとない機会ですので，取りこぼしの無いよう，しっかりと血肉にしていきたいと考えています．