システム開発で思うところ

Javaで主にシステム開発をしながら思うところをツラツラを綴る。主に自分向けのメモ。EE関連の情報が少なく自分自身がそういう情報があったら良いなぁということで他の人の参考になれば幸い

テストのメモ

考え方

- JUnit 実践講座

http://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TM_Version2012.J03.pdf

これだけは覚えたい、ユニットテストを書くための4つのデザイン - Qiita

実践テスト駆動開発(GOOS)読んだ - Qiita

ユースケースからテストケースへの追跡可能性

【初心者向け】テストコードの方針を考える(何をテストすべきか?どんなテストを書くべきか?) - Qiita

speakerdeck.com

speakerdeck.com

www.slideshare.net

アサーション

JUnitの新しいアサーション assertThat - A Memorandum

標準出力のテスト

標準出力に結果を出すプログラムをJUnit 4.1でテストする方法 - 結城浩のはてなブログ

検証

http://tomoyamkung.net/2013/08/26/java-junit-list-assert/

JUnitでの例外テストの書き方 - Qiita

JUnit のテストメソッドを複数スレッドで実行する - 日々常々

テスト管理ツール

www.slideshare.net

www.slideshare.net

JUnit

JUnit5で変わるテストの書き方 - きしだのHatena

Spock

www.slideshare.net

Spockのドキュメントを読んだよ - Mitsuyuki.Shiiba

JavaのユニットテストにSpockを適用する - Qiita

Spockでデータベースが絡むテストを書くためにやるべきこと その1 - Qiita

Spockの知られざる機能 - うさぎ組

Spock1.1の新機能紹介 - うさぎ組

mike、mikeなるままに…: Spockで例外のテスト

その他

Ansibleのテストで使いたい8つのServerspec | DevelopersIO

Commits · bufferings/tdd · GitHub

www.slideshare.net

リファクタリングのメモ

自分向け。
過去に作ったものは、この考えに則っていないものは多々あるが、あくまで「今」の考え。多分今後も変わり続けると思う。

継承か委譲か

継承にするか、委譲にするか迷った時の判断基準

継承しているクラスのメソッドを拡張していないんだったら委譲にする

継承を使ったらコード量は減るけど、機能追加をするときに継承元のクラスの実装とかフィールドを見ないといけない。見ること自体はどっちにしても見るべきとは思うけど、数日経ってから「なんだっけ、このthis.hogeって?、となったりする。
もっとちゃんとした理由は調べれば色々あったりするけれど、こんな理由もあるというメモ。

委譲とインターフェースで余計な操作は公開しない

実装もありつつ統一操作も持たせたい時には委譲したクラスの操作で共有したい操作のみインターフェースで定義する。 それって抽象クラスと同じで、単に委譲実装をするから手間は増えるだけに感じるけど似て非なる実装。 なお、委譲の実装はIDEの機能を使えば そこまで大変ではない。

抽象クラスを使用しないことにムキになっているなっているわけではなくて、抽象クラスは基本的にテンプレートパターンのような「拡張」を前提とするものに限定しておいた方が良いのではないかな、というのが現時点の整理。

インフラやシステム環境のAPIにはラッパーを準備する

インフラやシステム環境は、後々、横断的な対応をしたくなることはよくある。テストの時にもモック化しやすい。過去の経験では日付や時間は操作できるようにしておく方が良い。少なくとも営業経過日のテストや日替わりの時刻変更をしなくて良かったケースは皆無だった。

継承を疑う条件

methane.hatenablog.jp

継承したクラスが継承元にはないpublicなメソッドを持っている時点で、一回疑うべきである。

カプセル化

カプセルは多少緩くても良い気がする

カプセル化としてフィールドやメソッドをprivateにする作法がある。むやみに拡張をさせたくないときに、そのようにしましょう、という作法という理解。意識せず機械的に作法的にそうしているケースもある。
ただ最近、多少緩くても良い気がするように段々となってきた。勝手に使用したり、拡張されてほしくないケースもあると思うが、それを開発時にすべて想定するのは難しく、だからカプセルに閉じ込める、というのは利便性が下がるように思い始めているから。 ということで、最近のメソッドにはprivateではなくdefault(無印)を使うようにしている。一応、フィールドは更新をされると想定外の挙動になる可能性があるのでfinalで更新不可にはしている。 おそらく正しい作法としてはインターフェースと実装をペアにしてコンポジションなりを出来るようにしておけば、それが一番良いのだろうとは思う。でも、ちょっと全部にそれをするのはシンドイ。。
内部実装が漏れるのは良くない、というのは分かるけど、特にフレームワークなど基底層の場合「デバッグなどで必要としている情報をクラスが保持しているのは分かったけど、アクセッサが無くて参照できない」ということに何度か遭遇すると「更新はしないから参照はさせて・・」と言いたくなることが多々あった経験から。当然だけれど、そういう操作については、ドメイン層のクラスから直接参照するのはNGだと思うので何かしらのラッパークラスを設けて必要最低限の操作のみを開放するという作法は実施する。
インフラ層(フレームワーク含む)をドメイン層から直接使用しないようにするのは、実装による使用不可にするというよりも、動的・静的解析によって使用禁止喚起することをプロジェクト毎の基準を持って実施するのが良い塩梅では無いかな、と思う。
実際の現場はカオスなので、少しでも開放すると既得権益となってしまって済し崩しで設計思想が破壊されてしまう可能性が十分あるので、なかなかそうもいかないというのは分かるけど、とりあえず自分の開発では多少緩くするのが現在の指針。

不変の作法

フィールドの不変の作法

  • プリミティブ系:final
  • List系:Collections.unmodifiableList()
  • Map系:Collections.unmodifiableMap()

インスタンス構築

newよりもstatic factory

構築するインスタンスの確定を遅れさせることが出来るので、newよりもstatic factory。緩いカプセル化と同じく、どういう要件で拡張をしたくなるのか未来は分からない。未来に対しては寛容でいた方が、後々幸せな事が多い気がする。
実装時の注意としてはコンストラクタはprotectedにすること。そうしないとサブクラスが作成できないから。

参考

いぬごやねっと

補足として、決して new が嫌いという訳ではない。作成するインスタンスを確定させておきたい強い意志がある場合は、newの方が良いと思っている。例えば独自の実行時例外。

パラメータ、必須はstatic factory、任意はbuilder

newよりもstatic factoryにする延長で、static factoryは必須項目、builderで任意項目という整理をしておくと使用時に分かりやすい気がする。
ただし、builderパターンは、パラメータの相反については表現しづらいので、任意項目だけれどstatic factoryが全くない訳ではない。static factoryであれば、相反は表現できる。

Builderパターン

2017/8/27追記

Effective Java の Builderパターンとその拡張 - がくぞーのメモ

私の認識が間違っていたかも。

命名

パッケージ名

パッケージ名は、単数形?複数形? - Qiita

クラス名

うまくクラス名を付けるための参考情報 - Qiita

オブジェクト指向

おすすめオブジェクト指向練習方法 | サイバーエージェント 公式エンジニアブログ

リーンなコードを書こう:実践的なオブジェクト指向設計

コーディング

Null

2017/8/18 追記

  • 戻り値がNullかもしれない場合にはOptional

Java 8 "Optional" ~ これからのnullとの付き合い方 ~ - Qiita

セキュアなコーディング

www.slideshare.net

例外

段階的に理解する Java 例外処理 - Qiita

その他

DBリファクタリングの勘所と所感 - そーだいなるらくがき帳

パッケージの循環依存の対処

一般的にプログラムにおいて循環依存は良くないことと言われています*1

とはいえ、Javaは循環依存をしていてもコンパイルエラーになることはありません。
なので気が付かない間に循環依存をしてしまっているケースはあるように思います。

とりあえず、パッケージの循環依存については、チェックするやり方がありますので、それを活用するのが良いと思います。 (本記事はmavenjdepend-maven-pluginの使用例でもあります。)

blog.guildworks.jp

ところで、私もチェックを実施したところ、ちょこちょこと循環依存をしてました。

これからも同じように気がつけば循環依存をしてしまっているケースが発生すると思います。反省も含めて、どういう循環依存の実装をしてしまって、それをどういう風に対処したのか、というのを記しておきたいと思います。

コマンドパターンのような実装をしたい

デザインパターンのコマンドパターンのようなことをしたいと思って実装したら循環依存エラーになりました。

やりたかったこと

  • HogeController:共通の呼出窓口となるクラス。
  • FugaCommandHandler:Commandを実行するクラス。
  • FugaCommandManager:Commandを管理するクラス。
  • Piyo1CommandPiyo2Command:Commandクラス。

FugaCommandManagerで、Commandクラス(Piyo1CommandPiyo2Command)を登録して、 各CommandクラスはCommandInterfaceを実装して統一的な操作が出来るようにします。
また各Commandは個別機能ということでパッケージにまとめておきます。

機能としては、HogeControllerから呼び出したFugaCommandHandlerFugaCommandManagerに登録した各Commandを実行します。

この例ではクラスが少ないので同一パッケージにしても良いかもしれないのですが、各Commandについては複数のクラスを使用しているので、個別のパッケージを設けることにしました。

循環参照あり

GitHub

GitHub - vermeer-blog-circular-reference/sample1-error: 循環参照サンプル1(循環参照エラー)

パス構成

org
└─vermeer1977
   └─sample
       └─circular_reference
           │  CommandInterface.java
           │  EnvironmentItem.java
           │  FugaCommandHandler.java
           │  FugaCommandManager.java
           │  HogeController.java
           │  Main.java
           │  
           └─command
               ├─piyo1
               │      Piyo1Command.java
               │      
               └─piyo2
                       Piyo2Command.java

ぱっと見た感じだと問題なさそうな構成に思っていましたが循環依存が発生しました。

循環依存になったと思われる理由

HogeControllerにて取得した実行環境情報EnvironmentItemを各Commandで使用するのですが、それが原因だと思われます。

対処例

FugaCommandManagerを独立したパッケージに分割しました。 こうすることで、HogeControllerのパッケージとPiyo1Commandのパッケージが直接依存する関係が、仲介するパッケージを経由する状態になり循環依存のエラーがなくなりました。
発想としては、UMLの関連クラスを緩衝材として実装するイメージ、もしくはDTOを仲介させることで直接参照をしないようにするイメージです。

GitHub

GitHub - vermeer-blog-circular-reference/sample1-ok: 循環参照サンプル1(循環参照エラーの解消)

パス構成

org
└─vermeer1977
    └─sample
        └─circular_reference
            │  CommandInterface.java
            │  EnvironmentItem.java
            │  FugaCommandHandler.java
            │  HogeController.java
            │  Main.java
            │  
            └─command
                │  FugaCommandManager.java
                │  
                ├─piyo1
                │      Piyo1Command.java
                │      
                └─piyo2
                        Piyo2Command.java

副産物

分割したことで、今後、Commandクラスを増やした時に改修するクラスがパッケージレベルで整理されているので見通しも良くなった気がします。

呼出元のクラスを引数にしたい

やりたかったこと

呼出元の情報を元に呼出先で編集処理をしたい。

循環参照あり

GitHub

GitHub - vermeer-blog-circular-reference/sample2-error: 循環参照サンプル2(循環参照エラー)

パス構成

org
└─vermeer1977
    └─sample
        └─circular_reference
            │  Main.java
            │  
            ├─callee
            │      Callee.java
            │      
            └─caller
                    Caller.java

循環参照になった理由

説明の余地のないくらい、しっかりした循環依存です。

対処例

呼出先のクラスCalleeで実際に操作したい機能を満たすインターフェースを作成して、引数の型を変更しました。

修正前は呼出元クラスCallerインスタンスを呼出先クラスCalleeで参照したため循環依存になります。
修正後は呼出先クラスCalleeで必要となる振舞いを定義したインターフェースを呼出元クラスCallerに実装することで循環依存が解消されます。
参照する向きを変更したイメージです。
(ちょっと今回の例だと、何のどの概念をインターフェースとしたのか分かりにくいのが難点ですが・・)

GitHub

GitHub - vermeer-blog-circular-reference/sample2-ok: 循環参照サンプル2(循環参照エラーの解消)

パス構成

org
└─vermeer1977
    └─sample
        └─circular_reference
            │  Main.java
            │  
            ├─callee
            │      Callee.java
            │      CalleeInterface.java
            │      
            └─caller
                    Caller.java

実装の抜粋

  • Callee

calleeパッケージにCalleeクラスのメソッドの仮引数の型をCallerクラスからCalleeInterfaceに変更する

<修正前>

    public Callee(Caller caller) {
        this.caller = caller;
    }

<修正後>

    public Callee(CalleeInterface caller) {
        this.caller = caller;
    }
  • Caller

CallerCalleeInterfaceimplementsする

public class Caller implements CalleeInterface {

・・・

}

副産物

インターフェースを介することで、どのようなメソッド(振舞い)が呼出先として必要であるのか見通しが良くなりました。クラスのままだと、どのメソッドが使われているのか使用箇所の調査をしないと判別できません。

とはいえ、呼出元が呼出先の抽象概念の一部である、というのは少々宜しくないような気もします。基本的には素直に循環依存を解消するのであれば1つ目の例のように仲介するクラスを設けて、呼出元で中継するクラスを作成して呼出先に渡す、というのが良さそうに思います。可読性が落ちない程度で、仲介パッケージを作らなくても問題ないくらいの複雑度であれば、こういうやり方もありそうだ、という例にはなるように思います。

さいごに

正直なところ、始めは自分の作成した自分だけが想定される開発者なので循環参照の対応は無理しなくても良いかなと思っていました。ですが、実際、改修することで、見通しが良くなったように思います。

むかーしの話ですが、大規模SIer案件ではコードにインターフェースが使用されているものは、ほとんど*2ありませんでした。そういうこともあって「フレームワークなど抽象度の高い機能を実装しないのであればインターフェースを使うことはないだろうな」と思っていましたが、実際に自分で手を動かしてみると、そんなことは無いな、と思うようになりました。本記事もその一例のように思います。

*1:言語によってはコンパイルエラーになったりするみたいです。

*2:というか全く

新人エンジニアが読んでおいた方が良いと思う本の紹介

春もそろそろ近づいてきています。新人さんの季節ですね。

新人さんに限らずですが「こういう本を読んでおくと良いと思いますよ」と薦めている本がありますので、それを紹介したいと思います。

実際のところは「若いうちに読んでおけば良かった」という自戒の意味が強かったりします。
ここから書籍の紹介までは、おじさんの昔話なので、適当に読み飛ばしていただければと思います。

私は元々COBOLで金融系の開発をしていて、その後、PL経験を積んだ人間です。一応、物事を整理する能力は人並みにはあったということで最低限の仕事はしていたとは思います*1。とはいえ、OJTという名の下に仕事は現場で覚えるものと言い訳をして、物を作る基礎力の無い残念なエンジニアの典型でもありました。Javaでの実装経験が無くても、オブジェクト指向が分からなくても、設計書のレビューもしますし、プロジェクト管理もしますし、さらにはデバッグやプログラム改修もします。なんだか無茶苦茶ですね。でも、それが実態でした。プログラムの良いところは結果が出てくれるというところです。やり方はともかくとしても要件・仕様は把握しているので、そこを満たせば目の前の問題に限っては対処できます。また、幸いにもプログラミングについては、より詳しい技術者もいましたので、そういった方々と協力したチームを作ることで多くの問題も解決できました。PLやPMとして求められたのは、私の技術向上よりも、チームをまとめて大きい金額の仕事をしていくことなので、その意味では問題はありませんし、それも正解の1つだと思います。
ただ、私自身は大きな売り上げを出す人よりも、自分の力で1から物を作ることが出来る人に憧れがありました。だったら自分で行動すれば良かったわけですが、日々の仕事を言い訳に行動をしないままでした。そんな時、色々とあって大きなプロジェクトの開発プロセスに携わるチームに実質一人で参画できます*2。そのことが私にとって非常に良い転機になります。これまでやってきていた、お客様のシステム要件を理解することももちろん大切なのですが、システムを作ることそのもの(開発手法、プログラミング手法、方式検討など)をじっくり考えることが出来る時間が出来ましたし、情報収集・分析の一環としてVBAでツールを作ったりして、自分の手を動かして1から物を作る機会も得ることが出来ました。

そして、この頃から、ようやくシステムに関する本を少しずつですが読み始めます。そして思います「あぁ、こんなにサクッと読める本もあるのに、なんで私はもっと早く読んでいなかったんだろう。。あの時、知っていたら、もっと良い結果に導けたかもしれないなぁ」と。

とまぁ、そんな経緯もあって、私が読んだ本の中で、達人プログラマーになるというよりも、浅く・広く・難しすぎない・目を通すだけでも見ておくと後々良いと思う、という本を周囲に薦めるようになります。そして今回紹介している本はそういう経緯で選定した本です。

では、おじさんの昔話はこのあたりにして新人さんが読んでおいた方が良いと思う本を紹介していきたいと思います。

Javaアソシエイツ

SUN教科書 Java アソシエイツ (SJC-A)

SUN教科書 Java アソシエイツ (SJC-A)

Sunテキスト Javaアソシエイツ EXAM 【310-019】 (SKILL-UP TEXT)

Sunテキスト Javaアソシエイツ EXAM 【310-019】 (SKILL-UP TEXT)

何から勉強したら良いのかなぁ、と思っていらっしゃる方であれば、まずこれらの本を薦めています。どちらの本でも良いですし他にもあります*3。ページ数が多いから前者、通勤電車で読むからコンパクトな方が良いというのであれば後者、など立ち読みして好みの方を選んでください。知っておいてほしい知識はどちらでも学べます。

言い過ぎかもしれませんが、この資格そのものに実際のところ何の価値もありません。なので合格を目的としなくて良いです*4

では、なぜ私がこの本を進めるかというと「教科書」的な位置づけの本だからです。SIerで勉強というと、まず出てくるのが基本情報処理試験だと思います。こちらも悪いわけではないです。ただ情報分野への理解には良いですが、システムやプログラミングへの理解という意味だと良くはないです*5。良し悪しではなく目的が違います。

教材にすることでJavaで開発をする人にとって一通り知っておいてほしい知識が身に付きます*6。AWTとかSwingとか「今、それ使う開発はあるの?」という情報もありますが、知識として知っておいて損はありません。メンテナンス対象となっているシステムが使用しているケースもあり得ます。また、Javaは関係ないから、という人もいると思いますが、もしSIerで仕事をする方であれば、UML*7や継承など、オブジェクト指向での開発に必要となる知識は必要です。言語特有の知識はありますが、自分の開発言語に置き換えながら読むなどして、いろんな言語があるんだな、という学習の仕方もあると思います。

「この程度の事をわざわざ勉強しなくても」という方もいらっしゃるかと思いますが、むしろ「この程度の事」だからこそ、きちんと勉強をしておくことが大切だと私は思います。

もし理解を深めたいというのであれば問題集もあります。私は資格取得までしたので問題集まで読みましたが、私がまず知っておいてほしい知識と思っている内容は参考書で十分です*8

徹底攻略 Javaアソシエイツ問題集[310-019]対応 (ITプロ/ITエンジニアのための徹底攻略)

徹底攻略 Javaアソシエイツ問題集[310-019]対応 (ITプロ/ITエンジニアのための徹底攻略)

開発現場の掟

開発現場の掟 (プロの鉄則) エンジニアが現場で生き残るための極意 (開発の現場セレクション)

開発現場の掟 (プロの鉄則) エンジニアが現場で生き残るための極意 (開発の現場セレクション)

実際の開発現場での経験を踏まえた知恵が書かれた本です。経験豊かなエンジニアからすれば当たり前であったり、平凡なことばかりかもしれません。でも、これから経験を積む入り口に立っている新人の方には有用な情報が多いと思います。

当たり前のように思うかもしれませんが、この当たり前が実際は難しいものです。

例えば、新人の方でも、自学してスクラムとかアジャイルとか、そういった開発手法を導入しよう、なぜ導入しないんだ、あぁだからSIerは・・・と思うことがあるかもしれません。確かにそういう一面もあるかと思いますが、それを取り入れない理由もあります。おじさんになると、そのあたりも勘案するようになったりしますが、若さゆえの衝突もあると思います。ひょっとしたら、正しい、間違っているは別にして「アジャイルの劇薬の鉄則」あたりが現場の経験としてあったためかもしれませんよ。

他にも仕事の進め方や、開発時に「始めからやっておけば良かった」ということなど、まぁそういう引き出しが色々と書かれている本なので、読んでおいて損はないと思います。

楽々ERDレッスン

楽々ERDレッスン (CodeZine BOOKS)

楽々ERDレッスン (CodeZine BOOKS)

データベースはシステムにおいてほぼ必須です。データベースを使わなくてもモデリングは必須です。

データベースの設計は、設計時の初期にシステムをモデリングする際に検討することが多いため、新人はなかなか経験できません。そして経験年数を重ねて設計工程に参画することになって、いきなりやれと言われます。そこから改めて過去の自分の携わったシステムを正解として自分なりに試行錯誤をすることになりがちです。でも、まだ「やれ」と言われて経験が出来るのであれば幸せかもしれません。

設計はセンスではなく技術なので、そうやって経験を積む中でより良い設計が出来るようになるわけですが、モデリングおよびデータベース設計は、やり直しのリスクが大きいため、始めから出来るだけ品質の良いものにしておきたいところです。そうすると案件的に「経験者優先」となってなかなか経験そのものを積むこと自体が難しいことの方が多いです。

では、本当に、その既存の設計や経験者の設計は妥当なのでしょうか?自分が設計したデータベースがただのデータの入れ物になってはいないでしょうか?

経験を補完するためには知識と疑似トレーニングが有効だと思うわけですが、紹介している本は、その2つを満たしていると思います。SQLについても基本的なところだけでなく、難解なものも事例として書かれています。この本は、モデリングだけ、SQLだけ、ではなくて、自分がモデリングしたものを実際にSQLで検索してみると、、という実践の流れまでを一通り押さえてくれているところが良いと思っています。

ひょっとしたら、本書を薦めつつ、新人さんがいきなりデータベース設計をすることは無いだろうということで、矛盾しているように思われるかもしれません。確かに設計そのものをすることは無いかもしれません。ですが、知識の習得や疑似トレーニングをしておくことで、目にするテーブル設計の意図を通じて仕様をより深く理解できるようになるのではないでしょうか。興味を持つと仕事が面白くなります。ER図を自分なりに紐解いていく中で、システムのイメージを掴めるようになります(それはモデリング追体験かもしれません)。無機質に思えたテーブル定義が、システムを抽象的に表現していると感じるようになったら楽しいと思いませんか?少なくとも、私は、そういうことを楽しいと思うエンジニアさんと一緒に仕事をしたいです。

現場で役立つシステム設計の原則

2019/4/19 追記

オブジェクト指向の何が嬉しいの?
じゃあ実際にコードで表現するのは どうしたら良いの?
そのためには どういう設計をしたら良いの?
に対して、理解を助けてくれます。

ただし「これこそが答えである」とはしない方が良いです。
著者の増田さん(増田 亨. (@masuda220) | Twitter)も その時の自分の考えであって、今後も変わっていくと仰っています。

とはいえ、ここまで現場でたたき上げた経験の結果を記した書籍は ほとんど無いのではないかと思います。

私の書評

vermeer.hatenablog.jp

著者も参加されていた勉強会のメモ

vermeer.hatenablog.jp

Javaルールブック

Javaルールブック ?読みやすく効率的なコードの原則

Javaルールブック ?読みやすく効率的なコードの原則

最後に紹介する本は、ぐっとプログラミングよりの本になります。Java5までのコーディング規約です。今はJava8なので情報としては古いのですが、紹介している理由は新しい古いとは別の事なので問題はありません。

こちらの書籍を薦めている理由は、プログラミングでの「良い例」「悪い例」と比較してくれているところです。プログラムをする中で大切な要素に、レビューをしてもらう、という工程があります。その延長で「他人のコードを読んで勉強しましょう」と良く言われます。でも良いレビュアーに出会えないかもしれません。また、コードを読めと言われても闇雲に読むのも難しいですし、目の前にあるコードが読むに値するものか判断するためには、やはりそれなりに経験が必要です。でも、その経験そのものが無い状態では・・・というループになってしまいます。

その第一歩として、この本を薦めています。

その上で、より良いコードを書く技術の本はたくさんありますし、その中には平易なものもいくつもありますので、そちらの本を読むようにしていけば良いと思います。

最後に

紹介した書籍は「絶対に正しい事」とは限りませんし、私自身も紹介した書籍の全てが正しいというつもりもありません。プログラミングも設計も開発手法も、色々な「正しさ」を持っている人がたくさんいますし、好みの問題もあります。とはいえ、まずは土台となる基礎が無いと、そういった判断をすることも難しいと思います。
また、上述で紹介した本の後に読んだ方が良いと思う、割合と平易な本もいくつかありますが、それを言い始めるとラインナップを見ただけで、お腹が一杯になってしまうことになるような気がしましたので、私なりに厳選をしたつもりです。

これからエンジニアになろうとしている方にとって、紹介した本が一助になれば幸いです。

*1:おそらくですが、そういうSIerシステムエンジニアと呼ばれる人は多いのではないでしょうか

*2:その時の上司に拾っていただいたというのが本当のところです

*3:私が読んだのは、この2冊です。

*4:試験料は馬鹿になりません、結構高いです

*5:無駄ではないです。というか無駄な勉強は無いです。

*6:お恥ずかしい話ですが、私はこの教科書的な知識すらありませんでした。

*7:クラス図だけだけど

*8:資格を受けるのなら黒本問題集は必ずやった方が良いです。参考書だけでは演習量が足りないです。

NetBeansのメモ

自分向けのメモ

基本設定

netbeans.conf

環境設定メモ。アップデートや再インストールしたときにはチェックする。

netbeans_default_options="-J-client -J-Xss2m -J-Xms32m -J-Xmx2048m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true -J-Dsun.java2d.dpiaware=true -J-Dsun.zip.disableMemoryMapping=true"

引用元は忘れたけど、これもつけておいた方が良いみたい。

export JAVA_TOOL_OPTIONS='-Dfile.encoding=UTF-8'

日本語化

NetBeans 8.2 のIME使用時のスクロール問題 | junichi11.com

NetBeans 8.2で日本語を使えるようにする - しんさんの出張所 はてな編

プラグイン

NetBeans Backlog Plugin | junichi11.com

Web上で直接編集してしまうことも多々あるけど、NetBeans上でも確認できたりコミットするときに連携できたりするので便利。Bitbucketにタイミングで課題管理をBacklogに。一人開発だからGoogleスプレッドシートでも問題ないけれど、IDEでの操作するかどうかは別にして、できるのであればそれに越したことは無いかなと思ったのと、有償のJIRAは過剰かなというところでBacklogに落ち着く。
GitHubにも同様のプラグインがあるので、GitHubで課題管理をするときには、そちらも選択肢。ただ課題管理が色々あるのも面倒なので基本的にはBacklogで一元管理をしていこうと思う。

使い方

NetBeans でコード内の TODO を一覧表示させる – わーどぷれすっ!

NetBeansでJavaソースコードのステップ数も測定できるメトリクスプラグイン「SourceCodeMetrics plugin」 - yappynoppyの日記

Mavenメモ

自分向けのメモ

基本

Maven | TECHSCORE(テックスコア)

pom.xmlの各要素デフォルト値と変数置換について - Qiita

Mavenでビルドする際にpomによく書くことメモ - Qiita

Mavenでビルドする際の10のTips - cynipeと読む

GitHub - IBM/japan-technology: IBM Related Japanese technical documents - Code Patterns, Learning Path, Tutorials, etc.

パス

Mavenを使ってリソースファイルをJARの外部に配置する方法 - Qiita

Maven3で環境ごとのresourceを差分で管理する方法 - Qiita

実行時制御

Maven管理下のリソースファイルの値を実行時にプロパティの値で置換する (Resource Filtering) - 理系学生日記

JavaTechnology Slot Online | Cara Daftar bermain Slot Online

Exec Maven Plugin

http://tomoyamkung.net/2015/09/09/2015-09-09-maven_exec_plugin/

2011-01-06

http://www.sssg.org/blogs/hiro345/archives/14570.html

Maven pom.xml のバージョン番号を Java プログラムから取得する / 桃缶食べたい。

No hack, No chance: Jar の META-INF/MANIFEST.MF に書いた Class-Path が効かない件

モジュール管理

Mavenプロジェクトをモジュール化する | Java好き

java - Maven / FatJarのビルドについて - スタック・オーバーフロー

3. Maven 入門 (7) | TECHSCORE(テックスコア)

2010-11-27

Mavenでの依存ライブラリの最新バージョンを表示、更新したりできるVersions Maven Plugin - CLOVER🍀

Apache Maven Javadoc Plugin – Grouping Packages

Mavenプラグインで外部ライブラリをrepackageする方法 - Kengo's blog

Maven Assembly Pluginで実行可能jarをつくる - 理系学生日記

Maven Assembly Plugin をマルチモジュールプロジェクトで使う - A Memorandum

Maven Assembly Plugin でできるファイル名がクソダサかった話 - 理系学生日記

Maven で依存 JAR ライブラリを target/dependency にコピー - kymmt

Mavenから開発しやすいEclipseのTomcatプロジェクトを生成する - TIM Labs

JavaDoc

みかん箱

mvn siteのtips三連発 | nagaseyasuhito Daily works.

GitでMavenリポジトリ

Github上に私設Mavenリポジトリをつくる - M12i.

GitHub の Pages を maven リポジトリとして使用するときのアカウント情報をセキュアにする(OAuth2Token) | KK.Kon の徒然メモ書き

http://synergian.github.io/wagon-git/usage.html

Github を Maven リポジトリとして使う -

PMD

Maven使いのためのPMD入門(2012年夏) - Kengo's blog

PMD rulesetの一覧(java) | Monotalk

PMD 標準的な ruleset とは何かを調べてみる | Monotalk

プラグイン

http://boatrip.co.jp/blog/2016/06/26/011/

警告は出るけど、とりあえず出力はされている自分のpom.xml抜粋

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.7.7.201606060606</version>
    <executions>
        <execution>
            <id>prepare-agent</id>
            <phase>test-compile</phase>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
        <execution>
            <id>report</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>report</goal>
            </goals>
        </execution>
    </executions>
</plugin>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.19.1</version>
    <configuration>
        <skipTests>false</skipTests>
    </configuration>
</plugin>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-report-plugin</artifactId>
    <version>2.19.1</version>
</plugin>

出力される警告
file.encoding cannot be set as system property, use <argLine>-Dfile.encoding=...</argLine> instead

ということでmaven-surefire-plugin<argLine>を追記するけれどカバレージレポートが出なくなる。
現状は警告を放置してレポートが出力される方を優先することにしている。

循環参照チェック

https://blog.guildworks.jp/2014/09/25/find-cyclic-dependencies/

テストクラスは、とりあえず、言われるままに実装。
今のところ循環は無いみたい。

pom.xmlの関連個所のみ

    <dependency>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>jdepend-maven-plugin</artifactId>
        <version>2.0</version>
        <scope>test</scope>
        <type>jar</type>
    </dependency>


<reporting>
    <plugins>
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>jdepend-maven-plugin</artifactId>
            <version>2.0</version>
        </plugin>
    </plugins>
</reporting>

依存管理

Mavenでプロジェクトの依存関係を解析する - CLOVER🍀

http://blog.soebes.de/blog/2014/01/02/version-information-into-your-appas-with-maven/

環境情報の切り替え

maven-war-pluginで環境ごとの設定ファイルを管理してみた - Challenge Engineer Life !

SpotBugs

nablarch-style-guide/Maven-settings.md at master · nablarch-development-standards/nablarch-style-guide · GitHub

JavaSEのメモ

ブックマーク的なメモ

全般

Oracle JDK 8にあってOpenJDKにない機能 - Qiita

http://www012.upp.so-net.ne.jp/eshibata/pdfs/Tiger20131025_FontEmbedded.pdf

IT Pro Java技術最前線全目次集 - Code Discipline

Java Generics Hell Advent Calendar 2017 - Adventar

effective java 3rdまとめ - Qiita

パス関係

Javaで絶対パスを取得するgetAbsolutePath()の罠と解決方法 - Qiita

【Java Tips】ディレクトリ配下の全ファイルを処理する

指定パッケージ内のクラス一覧を取得するサンプル - うなの日記

ResourceBundleでクラスパス上にない外部ファイルを指定する - Challenge Engineer Life !

Javaでプログラム実行後にJARファイルをクラスパスに追加したい - torutkのブログ

Jarファイルメモ(Hishidama's java-archive Memo)

あるプログラマーのワークスペース: getResourceAsStream()でリソースが読み込めない

クラスローダー

参照可能なクラスのリストを取得したい - argius note

URL to load resources from the classpath in Java - Stack Overflow

Javaクラスローダーを自作する - Qiita

java - How to get classpath from classloader? - Stack Overflow

任意のjarファイルから条件に合ったクラスをロードする - Qiita

実行時にクラスパスを追加する - CLOVER🍀

java - How to get classpath from classloader? - Stack Overflow

プロパティ

【Java】システムプロパティの扱い方について(System.getProperty) - TASK NOTES

型検証

異型のオブジェクト比較 - プログラマーの脳みそ

JavaオレオレFrameworkに欠かせないリフレクションでの総称型解析 - Qiita

Java 8 &quot;Optional&quot; ~ これからのnullとの付き合い方 ~ - Qiita

あの、isAssignableFrom ってよくわからなくなるんですケド - A Memorandum

JavaCompiler

Javaコンパイラークラスメモ(Hishidama's JavaCompiler Memo)

「Java SE 6完全攻略」第89回 プログラムからコンパイル - Compiler API その1(4ページ目) | 日経 xTECH(クロステック)

Java Code Examples javax.tools.JavaCompiler.CompilationTask.setProcessors

Java Compiler API - Compile and Load in Memory Dynamic Code

リフレクション

JavaでPropertyDescriptorを使ってBeanのプロパティに簡単にアクセスする - No Programming, No Life

ProxyパターンとProxyクラスと黒魔術 - プログラマーの脳みそ

java.lang.reflect.Proxyの使い方(2) - Qiita

リフレクションで遊ぼう

JavaでScript(Nashornも)

[Java8] Java上でJavaScriptを動かす - Qiita

JavaスクリプトAPI

http://samuraism.jp/diary/2015/07/10/1436497303628.html

パフォーマンス

StringBuilderの初期化方法パフォーマンス比較 | Pimp my Code. @wataru420

  • StringBuilder.setLenght(0)

セキュリティ

Java Security Manager でセキュアなサービスを構築しよう - Cybozu Inside Out | サイボウズエンジニアのブログ

Java Authentication Guide with Apache Shiroをテキトーに訳した - kagamihogeの日記

依存解析

クラスやメソッドの依存関係を調べる (jdeps, cfa) | まくまくJavaノート

Lambda

Java8

www.slideshare.net

Oracle JDK 8にあってOpenJDKにない機能 - Qiita

もしもラムダの中で例外が発生したら(後編) - Taste of Tech Topics

Java9

www.slideshare.net

www.slideshare.net

www.slideshare.net

www.slideshare.net

Jigsaw 勉強メモ - Qiita

Java11

JEP 320の悪夢 – JDK 11は史上最悪のJDKかもしれない – My Note

GraalVM

www.slideshare.net

speakerdeck.com

speakerdeck.com

その他

Javaのリスク考察 2018年版 - プログラマーの脳みそ

speakerdeck.com

www.slideshare.net

www.slideshare.net

www.slideshare.net