読者です 読者をやめる 読者になる 読者になる

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

JavaEEを主にシステム開発をしながら思うところをツラツラを綴る

セミナー資料のまとめ

勉強会

自分向けのメモ

Java Day Tokyo

Java Day Tokyo 2016

Java Day Tokyo 2015

Java Day Tokyo 2014

online20130514-javaday

JJUG CCC

GitHub - jjug-ccc/slides-articles-2016fall: JJUG CCC 2016 Fallの発表資料およびブログ記事まとめ

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

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

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

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

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

JJUG CCC 2013 Spring の発表資料について | 寺田 佳央 - Yoshio Terada

AWS Summit Tokyo

AWS Summit Tokyo 2016 セッション資料・動画一覧 | AWS

AWS Summit Tokyo 2015 開催レポート動画・資料一覧 | AWS

AWS Summit Tokyo 2014 開催レポート動画・資料一覧 | AWS

AWS Summit Tokyo 2013 レポート セッション動画・資料一覧 | AWS

  • 行ったことは無い。面白そうな資料がありそう。

勉強会の情報

勉強会 随時更新

自分が参加したことがある勉強会・カンファレンス・セミナーの情報です。
私が参加しているものは無料のものばかりです。ちなみに、私はヘタレなので複数人によるワークショップではなく、セミナー型の聴講タイプのものにしか参加していません(意図せず、ワークショップになることもありましたが)。
ハンズオンや参加人数が少ないものも基本的に参加していません。私は「その他大勢の一人」でいたいので(ヘタレです)。逆に言えば、私のようなタイプの人でも参加できそうなものを紹介しているともいえます。良い意味で敷居が低いと思いますので 興味を持たれたら まず参加してみてはいかがでしょうか?

UMTP

UMTP Japan - セミナー・イベント情報

  • 今はアジャイルのワークショップもやっているみたいですね(未参加)。モデリングだけでなく、DDDやスクラムなどモダンと言われる開発手法全般に守備範囲を広げているとは思っていませんでした。
    UMLの勉強会の内容は書籍だけで黙々とやるのとは違って人の話として聞くのは刺激も含めて参加して良かったと記憶してます。オブジェクト指向UML(DDDも?)に興味があって有識者の話を聞いてみようと思うのでしたら、是非参加されることをお勧めしたいです。講師の方は皆さん質問のしやすそうな方ばかりだったと記憶しています。

  • モデリングについては基本的に固定の内容で実施しているようなので、レベル毎のものを一度参加されれば良いと思います。

OSS-DB

イベント・セミナー|DBスペシャリストを認定する資格 OSS-DB技術者認定試験

  • PostgreSQLの勉強会です。基本的なSQLの書き方というのも多少はありますが、メインはDBの仕組みなどの技術的な話です。私はそちらの方が聞けたので非常に良かったです。ログの話などバックアップ&リカバリーに関係する話もありました。たしか、こちらは勉強会の後、質問させていただいた記憶があります。丁寧に答えていただけたと思います。PostgreSQLは使わないから、という理由だけで聞かないのは勿体ないと個人的には思います。DBも広い意味ではファイルシステム(オンメモリ―でも)だということを理解できましたし、それは多分、本質的には他のDBでも類似だと思います。

  • 基本的に固定の内容で実施しているようなので、レベル毎のものを一度参加されれば良いと思います。

JJUG

日本Javaユーザーグループ

  • Java全般の事を学べる場所です。JavaSE、JavaEEJVM言語、DDDなどの設計関連など多岐にわたります。個人的には一番知りたい情報を収集できる場です。
    ナイトセミナー(月1回)は情報公開当日にほぼキャンセル待ちになるくらい人気。
    JJUG CCC(年2回)で技術動向が分かったり、他の開発現場の話を聞けたり、書籍を執筆者やアクセス数の多いブログの中の人に出会える場でもあります。私は懇親会に参加したことはありませんが、参加すれば より面白いかもしれませんね(人によっては)。

  • 内容はイベント毎に異なります。

JSUG

日本Springユーザ会 | Doorkeeper

  • Springは使っていませんがJavaEEとの違いや技術動向を知っておきたいという意図で参加しました。JavaEEは技術標準として、SpringはOSSの代表という感じと個人的には思っています。どちらが良いというのではなく、どちらも大切だと思います。一応、なんでもかんでも参加はしていませんが、私のようなアプローチはキャンセル待ちになってしまった人からすれば迷惑かもしれませんね。。とはいえ、JavaEEから離れるとしたらOSSとしてのスタンダードだと思われるSpringは選択肢になるので情報取集はしておきたいんですよね。
    (でも正直、JavaEEって そんなに悪くないと思うんだけどなぁ。)

  • 内容はイベント毎に異なります。

Java Day Tokyo

  • 個人的にはJJUGの延長的な位置づけです。Oralceが主催をしているということもあると思いますが、Java標準(JSR的な)の情報を知ることが出来ます。今後のJavaSEやJavaEEのリリース情報なども、このカンファレンスならではなのかもしれません。

Google Atmosphere Tokyo

  • Googleの情報収集。便利な機能や技術動向を収集するために参加しています。年に1回なので定期イベントというと語弊があるかもしれませんね。 Googleを採用しなくとも、類似のクラウドプラットフォームはあります(マイクロソフトとか)。情報システム部の方であれば技術要素よりも仕事改善の手法という意味で、聞くだけでも価値はあるのではないでしょうか。
    また、すでにGoogleAppsを導入している方であれば、より便利な活用方法の情報を入手できる機会になるのでお勧めです。

Developers Summit

  • デブサミ2017から参加しました。技術者の集いという感じでしょうか。ただ紹介される技術範囲が広いので逆に薄いという印象にも。普段自分が関わってこなかった情報を入手できるという意味では良かったと思います。

POStudy

POStudy ~アジャイル・プロダクトマネジメント研究会~ | Doorkeeper

  • 言語を固定しない、アジャイル開発のプロセスに関する勉強会です。私が参加したものは「その他大勢の一人」でいられたものでしたが、基本的にスクラムなどの実践やワークショップというのが多いみたいです。コミュニティの目的を考えるとそちらが正しいと思います*1

あとがき

基礎技術としてUMTPOSS-DBはお勧めです。私が技術的に聞きたいことをバランスよく聞かせてもらっていると思うのはJJUGです。
とりあえず、どんなことをしているのかな?というのは全てではないですが過去の資料が公開されているので、それらを読むところから始めても良いかと思います。

*1:ですが、いかんせん私はワークショップ系は得意ではないので。。。

JavaEEのメモ

JavaEE

自分向け

未分類

JSFでエラーのある項目の背景色を変える - じゃばらの手記

  • 自分でも似たようなことをしているけど、全く違うやり方。
    いつか、ブログにまとめたい

認証

Java アプリケーションコンテナに依存しないユーザー認証 : まだプログラマーですが何か?

  • JavaEEとはちょっと違うけどメモ。

未分類メモ

随時更新

自分向け

Java関連のスライド

Minazou67, Software developer | SlideShare

仮想化

VagrantとDockerについて名前しか知らなかったので試した - Qiita

データベースのメモ

DB 随時更新

自分向け

基本

「理論から学ぶデータベース実践入門」読んだ - $shibayu36->blog;

  • 多分、この資料の勉強会(?)は、直接聴講したと思う。

ロック

JavaでRDBデッドロック検出 - Qiita

データベース - Webアプリケーションのデータ更新で楽観ロックを使う理由について(5504)|teratail

i am BEST : 楽観的ロックに必要な悲観的コーディング(2)

排他制御のあれこれ - Qiita

他の人にも勧められる書籍

テストのメモ

随時更新 Test

自分向け

考え方

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

アサーション

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

標準出力のテスト

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

検証

JUnit4 で List の assertThat を簡潔に書きたい

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

リファクタリングのメモ

Java 随時更新

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

継承か委譲か

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

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

継承を使ったらコード量は減るけど、機能追加をするときに継承元のクラスの実装とかフィールドを見ないといけない。見ること自体はどっちにしても見るべきとは思うけど、数日経ってから「なんだっけ、この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にすること。そうしないとサブクラスが作成できないから。

参考

Javaのstaticファクトリーメソッドについて ‹ 技術の犬小屋

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

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

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

命名

クラス名

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

オブジェクト指向

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

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