Java on yusuiked's blog

Java で引数の null チェックで迷った話

yusuiked@gmail.com (yusuiked) — Tue, 15 Dec 2015 17:00:00 +0900

これは Java Advent Calendar 2015 の 15 日目の記事です。

昨日は @opengl_8080 さんの Byteman 使い方メモ＋α でした。明日は @irof さんです。

前置き

ついこないだチームでちょっとだけ話題に上って、みんなある程度指針は持っているものの、割と悩みつつ明確に答えを出せなかったので、もっと良い意見があればと思って晒してみます。まぁよくある話だし、Java 8 で Optional が使えるようになって null について語られるケースが増えたと思うので、再考するちょうどよい機会になればいいなーと思います。初心者向けです。

どう処す？処す？

こんな状況の時にあなたならどうしますか？

// Generics なのは例です。String でもなんでもいいです
public T doSomething(T input) {
    // input が null の時にどう処す？処す？
}

もちろん、呼び出し側のコンテキストとか、ライブラリを何使うかとか、Java 8 or それ以前とか、そういった前提によっていろいろ対処は変わってくるとは思うのですが、いくつか選択肢があると思います。良い悪いを置いといて、よく見るのは、

null を返す
何らかのデフォルト値を返す
java.lang.IllegalArgumentException などの例外を投げる

辺りかなぁと思います。null を返すパターンの時は、もし返り値が Collection や配列なのに、null 返しちゃうようなのを見かけたら、Effective Java をそっと差し出してあげてください。

おぬし気が効いてるのう

個人的に、以下のような実装を見たら、おお、おぬしホスピタリティを心得ておるのぅ、って思います。

Null Object パターンで何もしないオブジェクトを返す
- これも一種のデフォルト値を返すパターンと言える

public interface Command {
    void execute();
}
public class ABCCommand implements Command {
    public void execute() {
        System.out.println("ABC");
    }
}
// こいつが Null Object
public class NullCommand implements Command {
    public void execute() {
        // do nothing
    }
}
public class Main {
    public static void main(String... args) {
        Command missing = createCommand(null); // 普通こんなことやらないけど
        missing.execute();  // createCommand の戻り値が null だったら〜という null チェックが要らない
    }
    public static Command createCommand(String name) {
        if ("abc".equals(name)) {
            return new ABCCommand();
        } else {
            return new NullCommand();
        }
    }
}

ガード節を表現する実装をする

Spring in Summer ~ 夏なのにSpring で発表してきました #jsug_sis

yusuiked@gmail.com (yusuiked) — Mon, 31 Aug 2015 18:00:00 +0900

こういう大きいイベントでセッション発表するのは初めてだったのでかなり緊張しましたが、無事発表を終えることができました。やればできるもんですねｗ*1

Report to Spring Developer from CyberAgent from Yusuke Ikeda

www.slideshare.net

時間が多少オーバーしてしまい、質疑応答の時間が取れなかったのは申し訳なかったです。ただセッション終了後には数人の方に質問しにきていただいたりもして、多少なりとも興味持って聞いていただけたのかなぁと勝手ながら思っています。

発表の機会を下さった @making さんはじめ、 JSUG スタッフの方々、その他関係者の方々、本当にありがとうございました。

補遺

私と同僚の山田の2人でのセッションで、前半が私のレガシーシステムへの導入事例、後半が山田の Spring Boot を使った運用 Tips といった構成でした。最初は私も技術的なことを掘り下げたセッションにしようかとも思っていたのですが、メリハリがないと聞く側も疲れてしまうだろうという気持ちもあってこのような構成にしました。結果的にはバランスが取れて良かったかなと思っています。

私のパートはセッション中にも何度か言いましたが、BtoC でよく話題に上がるような以下の様な問題

高トラフィック
低レイテンシ
大量データ

はあつかわず、どちらかというとどこにでもありそうな話題をテーマにしました。目新しい話題を期待されていた方には申し訳なかったです。

Spring のカンファレンスで私たちのような事業者が冠に付いたセッションに対して期待されるのは、どちらかというと上記のようなテーマではないかと思ったりもしました。ただ、私自身が Spring に絡めた話でその文脈を語れるほど経験がなかったことと、私が Spring（特に Boot）に対して魅力に感じていたのは、今回のセッションで話したような生産性の高さと柔軟性、そして簡単さだった*2ので、そこをお話したかったということが大きいです。

そういう意味でも、もし導入を検討されている方や悩まれている方がいるなら、背中を押してあげたい気持ちですｗ*3

質問されたこと

犠牲的アーキテクチャの話で、今あるものを捨ててしまうのが価値、とは？

この辺りの話はちょっと前提をすっ飛ばしすぎて、普段 Web 上の議論を追っていない方にとってはなんのこっちゃという話でした。すみません。

大元は、マーティン・ファウラーが書いたこのエントリが発端の話です。（日本語訳はこちら）

端的に言うと、今作っているものも数年後には捨てざるを得ないくらい、世の中が変わったり技術が進んだりして、要件が実態と合わなくなることがあるかもしれない。ビジネスが成長して、システムのスケーラビリティが追いつかないこともあるかもしれない。それならば、作る時に最初から捨てることを意識してアーキテクチャを選ぼう、という考え方です。ただし、捨てるからといって、それまで作ってきたものに価値はない、ということではなく、

比較的短時間で捨ててしまうソフトウェアだって多くの価値を生み出しうると認めること

ともある通り、それはそれで開発チームが得てきた問題領域に対する経験や知識が無駄になるわけではないし、また品質を置いてけぼりにしていいわけではなく、極力モジュール性を高めておくことで新しいアーキテクチャにも交換できるようにしておくことが重要だとも言っています。この辺は、今流行りの Microservices Architecture にも通じる話かなと。

兎にも角にも、これをそもそもやるべきかどうか、いつやるべきか、というのに答えがあるわけでもなく、

多くの場合、これは技術というより事業の決断なのだ。

ということなんだと思います。

この話題に関しては、犠牲的アーキテクチャという言葉ともに、神宮式年遷宮に絡めて語られたり、式年遷宮アーキテクチャなどと言われて一時議論されていました。以下に、Web 上の有用な議論のリンクを示しておきますので、興味ある方はどうぞ。特に、Rebuild.fm の Aftershow 67 を聞いてみるといいと思います。

その他参考になるリンク

チーム状況として1人と言っていたが、障害時のオペレーションはどうしているのか？

基本的に自分が対処できる状況にあればするが、休みやいない場合はもちろんローテーションするようにしている
一次対応は他メンバーでもできるようになっている
手順は Wiki にまとめるなど、明確化している

開発が1人だったということだが、インフラのキッティングやらネットワークやらまで1人でやったのか？

インフラはオンプレミスの仮想環境に乗る形なので、アプリケーションエンジニアは基本的にはミドルウェアまで見られればとりあえず回る

蛇足

1人でやってることに関して、「私も1人でやってるんで、どういう風に上手くやってるのか教えて欲しいですー」みたいな話をちらほら聞きました。意外と世の中ソロプレイを強いられている方々多いのでは…？ｗ

渋谷 JVM に行ってきた #渋谷JVM

yusuiked@gmail.com (yusuiked) — Sun, 19 Apr 2015 23:25:02 +0900

d-cube.connpass.com

JVM そのものではなく、JVM の上で動く言語についての会でした。申し込み人数が100人超えしていたけど、最終的には90人くらいに落ち着いてた。

連休に入るとサーバが故障するとか、ヘソ曲げてるとしか思えない

— Yusuke Ikeda (@yukung) 2015, 4月 18

出かける直前にサーバのアラートが来ちゃって*1、なんだかんだバタバタしてしまい10分くらい遅れて到着したけど、セッション自体はまだ始まってなかったのでセーフ。

まとめはこの辺

togetter.com

とか、

とか。shigemk2 さんの記事は素晴らしくまとまっているので、詳細な内容はそちらでどうぞ。 

Scala セッション（@takezoen さん）

竹添さんの言語遍歴と Scala に出会ってからのお話。Java 以外にも Lisp、Haskell、Clojure といろいろ変遷があって、人に歴史ありだなーと勝手に思ってました。会社入って早い段階でポール・グレアムの本を読んでいたとか、当時の自分は存在も知らなかったしすごいなーと思いつつ。2011年〜2012年辺りの Java の停滞感と、当時の Scala の Java にはなかった熱気が、竹添さんを Scala に誘ったといった辺りも、なるほどなぁと思いながら聞いてました。途中、Java の停滞期の話をしている途中で竹添さんの PC から Java アップデートのお知らせが来てスライドが中断するという奇跡が起こって会場が盛り上がってたｗ

たけぞえさんへの Java からの悲痛な叫びｗｗ #渋谷JVM

— Yusuke Ikeda (@yukung) 2015, 4月 18

JJUG CCC 2015 Spring に行ってきた #jjug_ccc

yusuiked@gmail.com (yusuiked) — Wed, 15 Apr 2015 08:00:00 +0900

少し時間が経ってしまいましたが。

前回までの会場とは違い、西新宿駅から近くなったのでより行きやすくなってた。この辺りは以前通っていた職場にも近くて、歩いて通ったことも何度もあったので、懐かしさを感じつつ会場入り。もうやんカレー昔よく行きました。

タイムテーブルはこちら。

参加したセッション

感想とか思ったこととか

参加レポートは他の方にお任せして、個人的に感じたことや思ったことなどを。セッション資料も JJUG のサイトにリンクされてますし、以下のブログでも素晴らしくまとまっているのでそちらをどうぞ。

JJUG CCC 2015 Spring ( #jjug_ccc ) - セッション資料の一覧 - 地平線に行く - 地平線に行く

基調講演1 Java 20年史

JJUG 副会長の河村さんによる Java 昔話。なんだか大学の講義を聞いているようで懐かしさを覚えつつ、前半は聞いたことが無い単語や技術要素もあったりして逆に新鮮だったのと、全体を通して Java がどう変化してきたのかを俯瞰で見ることができていい機会だった。

私は Java 触り始めたのが大学3年の頃なので 2003 年くらい。ちょうど Struts が出始めの頃で、卒業論文で分散オブジェクト技術について書いてたので、 RMI/IIOP とか EJB とかについて調べていた記憶が話を聞いていて蘇った。それから新人研修がちょうど Java5 が出たての頃で、研修の補助図書として Java5 の本を渡された記憶とかも。懐かしい。

全体として、Java はインターネットの普及とともに進化してきたのだと改めて感じた。ブラウザの覇権の歴史とか、JavaScript の復興とか、これまでのインターネットの歴史について振り返るような授業が大学にあるとすれば、必ず出てきそうな話だと思うし、それとともに Applet やら Servlet やら EJB やらが出てきて何が問題だったのか、みたいなことが教科書に乗ってると思う。そういう意味で、むしろ最近入社した新卒〜3年目くらいの人に聞いて欲しいと思った。その時どんな問題があってそういった技術が出てきて、その技術がどんな課題があって消えていったのか、といったことは、技術がどんなに進歩しても普遍的な話だと思うし。

Java エンジニア養成読本読み終わった

yusuiked@gmail.com (yusuiked) — Sun, 04 Jan 2015 19:49:37 +0900

年末年始積ん読消化第1弾。

ざっくりとしたレビューは booklog の方に書きました。

こっちは雑感を少し。

きしださんの巻頭記事は、Java 屋な人が飲み屋で展開したいネタがギュッと詰まってて大変面白かったです。こういう話題を飲み屋でできるチームは良いチームな気がしたｗ歴史とかも、自分が大学時代語られていたような話から最近の話題まで網羅されてて、読み物として純粋に楽しめました。

特集1の Java 入門と、特集4のチーム開発入門は、新人研修が終わって次何読ませるかってなった段で一旦これをかますのがいいかなーと思いました。もちろん最初はわからないことが多く出て消化不良になるリスクもあるんだけど、避けては通れない道でもあると思うので、早いところまず到達して欲しいポイントを見せて到達点を明示しておくのも大事なのではないかなーと思ったり。

ブクログの方にも書いたけど、Java 入門の方は読んでて、あ、これ Effective Java とパーフェクト Java に書いてあったなーとか思い出したりしたので、両方のエッセンスが上手く詰まっている気がするし、例外のお話や標準ライブラリのところは、この本が想定している読者層であろうエンプラな現場では、大事なくせに先輩方が教えてくれない（教えられない？…おや誰か来たようだ）現場の方が多かったりする。さらにチーム開発入門はこのままWebDBPressのチーム開発実践入門へ繋げる流れがいいかなーなどと感じた。そういう意味でもこういう読みやすい媒体で触れさせるのに最適だと思う。

Effective Java 第2版 (The Java Series)

作者: Joshua Bloch,柴田芳樹
出版社/メーカー: ピアソンエデュケーション
発売日: 2008/11/27
メディア: 単行本（ソフトカバー）
購入: 77人クリック: 936回
この商品を含むブログ (267件) を見る

改訂2版パーフェクトJava

作者: 井上誠一郎,永井雅人
出版社/メーカー: 技術評論社
発売日: 2014/11/01
メディア: 大型本
この商品を含むブログ (3件) を見る

はじめての Spring Boot 読み終わった #hajiboot

yusuiked@gmail.com (yusuiked) — Sat, 27 Dec 2014 08:45:47 +0900

一足先に仕事が納まっていたので、今日通しで読み終えた。

はじめてのSpring Boot―「Spring Framework」で簡単Java (I/O BOOKS)

作者: 槙俊明
出版社/メーカー: 工学社
発売日: 2014/11
メディア: 単行本
この商品を含むブログ (3件) を見る

感想

それほど分量が多い本ではないし、ステップ・バイ・ステップで記述されているので最低限の Java の知識さえあればサラッと読める。サンプルソースコードや正誤表も GitHub で管理されているので、常に最新状況が反映されていて安心感がある。またサンプルも動かなかったりしたらソース落としてきて手元でビルドして確認できる点は、初心者が写経して typo で動かなくてやる気なくす、みたいなことを減らすことができそうだし素晴らしいなぁと思いました。よく、技術書でサンプルコードを zip で落とすパターンもあるけど、もう一律 GitHub でいいんじゃないかなぁ。

内容

Hello World から始まって、Spring Boot というよりは Spring Framework の基本、おそらく最も使う機会が多いと思われる要素（DI、Spring JDBC、Spring JPA）を一巡り、その後 Spring Boot で REST API と Thymeleaf を使った画面のある WebApp を実装し、Flyway や Spring Security にもさっと触れます。そして作ったアプリを heroku にデプロイ、最後に RestTemplate を使ったテスト方法と、Spring Boot でアプリ開発をするにあたって一通りの要素が網羅されていて、Spring Boot の取っ掛かりにはとてもコストパフォーマンスの良い*1書籍だと思います。

第九回 #渋谷java で LT してきた

yusuiked@gmail.com (yusuiked) — Sat, 13 Dec 2014 21:37:27 +0900

前回に引き続き参加させていただいて、今回は喋ってきました。

jooq-to-send-to-sql-faction from Yusuke Ikeda

今回は割と早めに LT 登録させてもらっていたのですが、それから怒涛のように仕事が忙しくなってスライド作る時間が作れず、当日なんとか間に合わせた感じ。デモで使ったサンプルは結構前に検証も兼ねて書いたものを使いまわしてなんとか事なきを得ました。

デモプロジェクトはこちら。

yukung/jooq-sample · GitHub

次回はもっと余裕を持って行動したい（小並感）

感想

LT 内で Java の O/R マッパーのお勧め聞いたらやっぱり Doma って返ってきました。

今回はマサカリもバンバン飛んでていつもより緊張感あった気がしますｗでも、終わった後その場でソースコードレビューしてたりして、楽しかったです。

あと、@making さんからサインもらいました。Spring Boot 使い始めの時はとてもお世話になりました。ありがとうございました。

-—-

第八回 #渋谷java に行ってきた

yusuiked@gmail.com (yusuiked) — Sun, 21 Sep 2014 21:53:18 +0900

http://shibuya-java.connpass.com/event/8212/

前回の参加が第4回だったので、大分お久しぶりです、という感じでした。相変わらずオサレな会場に加え、なんとオフィス内にビーチまで出来ていました。オサレ感がレベルアップしている…!!

オフィス内ビーチ！ #渋谷java pic.twitter.com/KFxZyJkFRJ

— Yusuke Ikeda (@yukung) 2014, 9月 20

資料とTogetter

感想

以下、それぞれのセッションの個人的な感想をば。思ったままに書くので読みづらいかもしれません。

QueryDSLとSpring DataでとりあえずCRUD @nabedge さん

Qyerydsl という SQL っぽい DSL でタイプセーフにRDBアクセスするフレームワークの紹介でした。資料はなく、サンプルコードを交えたコードの解説。詳しくは @nabedge さんの GitHub を見ていただければ。

Querydsl
- http://querydsl.com/
サンプルコード
- https://github.com/nabedge/querydsl-sample

リポジトリを見てもらえればわかりますが、中身は DDL + 初期データのSQL と、Spring Framework と連携する Java configuration のコードだけです。DBアクセスするためのコードは Querydsl が SQL を元に自動生成するため Maven で install 実行すると生成されます。*1

実際の使い方はテストコードを見れば大体わかります。基本的には、テーブルにアクセスするための自動生成されたオブジェクトと、クエリを文字列ではなく DSL としてメソッド呼び出しで表現*2して、タイプセーフにクエリが発行できる、という感じのものでした。更新系のクエリはコールバックを更新用のメソッドに渡すようなスタイルなため、Java8 のラムダ式で書くとシンプルに書けます。@nabedge さんもこれを調べて初めてラムダ式を書いたと言っていましたｗ

見た感じ、S2JDBC に非常に似ている印象を受けました。公式サイトを見る限り、サブクエリや検索結果オブジェクトへの射影なども表現できるようで、簡単なクエリをバシバシ投げながらコードを書く際は気持ちが良さそうだなぁと感じました。

また、私がちょうど今お守りをしている Java のプロジェクトは O/R マッパーとして MyBatis を使っていますが、アノテーションに SQL を書きまくっていて、文字列ということもあるし、気軽に SQL をペタペタ貼り付けて実行、とかをやりづらく、実際に動かしたら SQL エラー、とかになって非常につらたん(´・ω・｀)、という状況だったので、IDE の補完を駆使してタイプセーフにクエリを発行できるところに魅力を感じました。ちょっと興味が湧いたので触ってみようかと思います。

Seasar2再学習めも

yusuiked@gmail.com (yusuiked) — Sat, 18 Sep 2010 02:31:07 +0900

久しぶりに時間が取れたので，

Seasar 2 徹底入門 SAStruts/S2JDBC 対応

作者: 竹添直樹
出版社/メーカー: 翔泳社
発売日: 2010/04/20
メディア: 大型本
購入: 10人クリック: 270回
この商品を含むブログ (33件) を見る

を読んでSeasar2を再学習したのでそのメモ。

S2Containerの初期化

SingletonS2ContainerFactory#init()
app.diconの内容でコンテナを初期化する

コンポーネントの取得

S2Container#getComponent()で取得
できるだけ型を指定して取得するほうが吉

DIの設定

自動バインディングをうまく利用することでdiconファイルの記述量を減らすことができる
インタフェースを実装していないコンポーネントをDIする場合や，同じインタフェースを実装した複数のコンポーネントが登録されている場合は，diconファイルで明示的にDIの設定を記述する。

ライフサイクルの選び方

singleton,application,sessionなどライフサイクルが長い場合はスレッドセーフであることを十分に留意する必要がある。request,session,applicationはWebアプリケーション環境下のみで指定可能。利用する場合はweb.xmlにてS2ContainerFilterの設定が必要。

初期化と破棄のタイミング

singletonのコンポーネントはコンテナの初期化(S2Container#init())と同時にインスタンスが生成され，初期化される。singleton以外のコンポーネントはコンポーネントのインスタンスが取得されるタイミングで初期化される。
初期化時と破棄時の処理を行うためにdiconファイルでinitMethodタグとdestroyMethodタグで設定する。destroyMethodタグはsingletonのコンポーネントのみ有効。

DIできないライフサイクル

application,session,requestというライフサイクルについては，自分よりも短いライフサイクルのコンポーネントはDIできない。ただし，より長いスコープを持つコンポーネントに対して，prototypeのコンポーネントをDIすることは可能。
- スレッドセーフでないユーティリティ，ステートフルなコンポーネントなど，複数のコンポーネント間で共有したくないものをDIするケース

outerコンポーネントの使い方

S2Container外でインスタンスを生成して，S2Container#injectDependency()を呼び出すことでDIを行う
Seasar2以外のフレームワークや，既存のアプリケーションの一部にSeasar2を組み込んで使うような場合に使う

インジェクションの種類

コンストラクタインジェクション
- componentタグの配下にargタグを用いてコンストラクタの引数を指定する
セッターインジェクション／フィールドインジェクション
- componentタグの配下にpropertyタグを記述する
メソッドインジェクション
- componentタグの配下にinitMethodタグを用いて呼び出すメソッドを指定する

自動バインディング

autoBinding属性内容 auto コンストラクタとプロパティに対して自動バインディングを行う。autoBinding属性を省略した場合はauto semiauto アノテーションなどで明示的に指定したプロパティに対して自動バインディングを行う constructor コンストラクタに対して自動バインディングを行う property プロパティに対して自動バインディングを行う none 自動バインディングを行わない

今さらながらStruts+Tomcatの環境周りまとめ

yusuiked@gmail.com (yusuiked) — Sat, 13 Feb 2010 20:50:03 +0900

研修の講師をやることになり、サンプルアプリを作ることになったので、Struts+Tomcatでアプリを作ろうとしたら、開発環境構築で大分躓いてしまいました。久しぶりでほとんど覚えてなかったのでメモっておきます。

使用したStrutsのバージョンは1.2.9、Tomcatのバージョンは5.5です。*1

Tomcatと各JavaEE仕様のバージョンの対応

JavaEE Servlet JSP EJB JSF 備考 Tomcat4.x 1.3 2.3 1.2 2.0 Tomcat5.x 1.4 2.4 2.0 2.1 Tomcat6.x 5.0 2.5 2.1 3.0 1.2 JAX-WS2.0、JAXB2.0、JPA1.0、JSFとJSTLの共存が可能 Tomcat7.x 6.0 3.0 2.2/EL2.2 3.1 2.0 JAX-RS、CDIなどが追加、JAX-WS2.2、JAXB2.2、JPA2.0

JSTL/EL式とTomcatとの関係

JSTL EL式備考 Tomcat4.x 1.0 △ ※EL式使うときはJSTL1.0が必須 Tomcat5.X 1.1 ○ ※JSTLなくてもEL式は使用可能（JSP2.0の標準仕様、Tomcatがcommons-el.jarを含んでいる） Tomcat6.x 1.1 ○ 1.2も使おうと思えば使える Tomcat7.x 1.2 ○ JSTL 1.2 には JSP 2.1 コンテナーが必要なこと、またJSTL 1.2 以降では JSTL が Java EE の一部を構成することに注意*2

JSTL1.2 のライブラリは公式のMavenリポジトリにはない？？（未確認）java.net の GrassFish のリポジトリから取得するよう

バージョン対応表など詳しくは

JavaEE6