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

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

スコープについて

@ConversationScoped

画面操作に関するスコープ

実装イメージ

  • 開始ポイントを必ずindex.xhtmlにする。
  • ファイル名を除くフォルダパスが変更されるタイミングを@ConversationScopedの開始・終了の境界にする。
  • index.xhtmlは省略可能にする。(SAStruts風?)。
  • 同一会話内の画面遷移はxhtml名だけで遷移する。.xhtmlの省略不可。
  • 会話開始前にindex.xhtml以外のパスにアクセスをしようとしたら、同一フォルダのindex.xhtmlフォワードする。
  • 画面遷移はリダイレクトするようにInterseptor?faces-redirect=true";を付与する。同一画面遷移(return null)の場合は、自画面パスを取得して対応する
  • サブフォルダも親フォルダの会話範囲にする*1

考察

@ViewScopedJSF依存)は使わない

  • フォルダパスが変わらない=同一画面ということになるので、会話の開始・終了のタイミングは問題なさそう。
  • クライアントに情報を持たないので通信量が少なくて良さそう。

@FlowScopedJSF依存)は使わない

  • 同一会話を同一フォルダまたは子フォルダで表現すれば求めている要件は満たしている。
  • @FlowScopedと違って遷移フローのためのクラスとかXMLを作成しなくていいので分かりやすくなりそう。
  • jarにして部品化することは出来なくなる可能性大?。部品化する場合、仕組みを含めて全て取り込まないといけないことになるのでサイズが大きくなってしまう?。

@RequestScoped

単純な参照のみの画面の事を考えて@RequestScopedは残す。

実装イメージ(悩み中)

StatelessViewの強制

Stateless Viewの制御を@RequestScopedを使用した場合に強制的に行うようにInterseptorで対応。

閲覧のみのコントローラーですよ、ということが分かるようにする工夫が必要かな。

@ApplicationScoped

ビジネスロジック

パーフェクトJavaEEを見ていると、Serviceなどのビジネスロジックは、このスコープにしておくと良さそう。ビジネスロジックに状態を持ってはいけないという思想としても正しいと思う。

インフラレイヤー

コネクションとかインフラ関係でコンテナに1つあれば十分のインスタンス

ユーティリティクラス(悩み中)

ユーティリティクラスをInject対象にする状態が、すでに良くない気がしている。でもテスト容易性のためにstaticクラスにしないで、ということはあるかもしれないので、一応想定はしておく。

@SessionScoped

ユーザー情報

  • ログイン以降のユーザーの状態。
  • 認証・認可

ゲストユーザー情報

  • ログインする前の状態保持。ショッピングカート的な仕組みだと必要かも。

*1:2017/8/6 追記:スコープが広すぎるので対象外にするべき?

JJUG ナイトセミナー 「Java O/Rマッパー特集」に参加してきました #jjug

まとめ

【東京】JJUG ナイトセミナー 「Java O/Rマッパー特集」 7/26(水)開催 #jjug - Togetterまとめ

スライド

speakerdeck.com

Doma

www.slideshare.net

www.slideshare.net

スライド(関連)

speakerdeck.com

www.slideshare.net

感想

私が使用しているのはJPAで、話を聞いたうえでJPAで良いかな、と思った。

理由

JPQLとかORMらしさに拘っていない

基底となる技術要素がRDBである以上、実行SQLから目を背けることは出来ないということから、私は割と気軽にNativeQueryを使っている。標準SQLに限ればDB製品依存も言うほど気にしなくて良いと思っている*1
ただコード内で直接文字列操作をするのは好きではないというのと、SQLの確認のやり易さということでSQLファイルを読み込む共通部品は作った。今は、フラットに格納しているけれどDomaのようにパッケージに準じたフォルダで格納するというのは良さそうだから、今後、改修しよう。

テーブルにEntityクラスが1対1にも拘らない

@ReadOnlyをつけたEntityDTOとして参照のためだけに作ってDomaみたいにフラットな結果を後からゴニョゴニョしている。

キャッシュをあてにしない

キャッシュというかEntityManagerが原因で困ることが割とあるので、あてにしない仕組みにしておいた方が無難と思う。例えばflushはちゃんとコールするとか、selectはDBから最新のものを取ってくるようにするとか、そういうこと。

標準だから

JavaEE標準の看板は選定理由として大きい。思考停止していると言われたら その通りだと思う。ORMに対してトランザクションとクラスマッピングの基本的な仕組みしか求めていない私には何かしらルールと実装があれば良いので「標準」は訴求力になる。

あえて「好み」をいうと…

S2JDBCは良かった。2 way SQLが便利だった印象があるので。なので 今回、話を聞いてDomaが良さそうと思った*2
ただJPAを止めてまで、aptベースの仕組みを導入するか?というと難しいかなぁ。apt自体は理解をすると決して尻込みをするような技術ではないし、実際に動くコードが見られるので むしろ安心感すらあるんだけれど、分かってもらうためのハードルが高いかも。apt自体がもっと使いやすくなれば良いんですけどね。
ということもあって、今のところDomaを使うよりもJPAを便利に使えるための仕組みの精錬を優先しようかと思った結果『JPAで良いかな』という結論に至った次第。

*1:実際に移植しているわけではないので困った経験はないけれど

*2:以前、aptの教材・参考としてDomaのコードをみたけれど、ORMとしては既にJPAを使っていた&一通り仕組み作りまでしてしまっていたのでスルーしていたので、今回、話を聞けて良かった。

PaaS

PaaSに関するブックマークとメモ

外部サービスなどを考えるのであれば、PaaSが良いと思う。理由は運用コスト。ローカル環境や社内環境だと自分でカスタマイズできる自由度に惹かれるけれど、時間は有限なので何かしらのトレードオフは必要。ということで、外部・内部に関係なく、サービスを検討する場合には、まず「これはPaaS上でも動くものなのかな?」というところをスタート地点にするのが良いと考えた。 *1

なんて言っているが実際には全く手を付けていない。。情報収集をしては、その情報がどこかにいったりして毎回調べ直し。 ということで、無くさない場所に必要になりそうな情報のメモを残す。

コミュニティ

https://paas.connpass.com

Cloud Foundry

PaaSをローカル環境で試せる。ただ、私の環境では貧弱すぎる可能性大。

自宅 Cloud Foundry環境を構築する : まだプログラマーですが何か?

GitHub - Pivotal-Japan/cf-workshop: Cloud Foundry Workshop

Bulemix

Bluemixが良いと思うところは、ベースがCloudFoundryだということ。移植性が高そう。また、小さい規模であれば、ずっと無料枠が使えるみたいなところ。

使い方

IBM Bluemix DevOps Services 概要

Bluemix の基礎: サンプル Java アプリをクラウドにデプロイする

www.slideshare.net

www.slideshare.net

BluemixでJava 8を使う(on Liberty Runtime & DevOps Service) - Qiita

無料枠

クラウドサービスIBM Bluemixを無料で使うノウハウまとめ - Qiita

Google Apps Engine

PaaS当初の感動とは別に、癖が強そうということなどもあり、今のところ選定対象から外すことにした。

その他

今のところ、無料枠がネックになって選定外。

*1:GAEが世に出た時には感動に近いものがあったなぁ。

認証・認可・セキュリティのメモ

HTTPステータス

セキュリティ監査で文句を言われないHTTPステータスコードの使い分け - Qiita

HTTPステータスコード - Wikipedia

【Java】HTTPステータスコード列挙型 Powered by Wikipedia - Qiita

認証・認可

業務システムにおけるロールベースアクセス制御 - Qiita

Spring Security 使い方メモ 基礎・仕組み - Qiita

AzureAD for Java

SpringSecurityでFORM認証 - SIerだけど技術やりたいブログ

SpringSecurity 権限に基づいて認可処理をする - SIerだけど技術やりたいブログ

Google API OAuth2.0のアクセストークン&リフレッシュトークン取得手順メモ - Qiita

第一回 認証基盤のこれからを支えるOpenID Connect | オブジェクトの広場

トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita

デジタルID最新動向(2):図解:OAuth 2.0に潜む「5つの脆弱性」と解決法 (1/4) - @IT

「モバイル、オープンAPIを活用するための認証基盤(標準技術 OpenID Connect、OAuth 適用の考え方)」セミナーを開催しました(10月19日@東京) | 株式会社オージス総研

レルム

たかがレルムされどレルム GlassFish で始める詳細 JDBC レルム | 寺田 佳央 - Yoshio Terada

Jersey MVCでレルム認証する(Jerseyも基本的には方法は同じ!) - Java EE 事始め!

実装例など

Javaの道:Tomcat(13.JDBCレルムによるFORM認証)

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

6.10. 代表的なセキュリティ要件の実装例 — TERASOLUNA Server Framework for Java (5.x) Development Guideline 5.1.0.RELEASE documentation

さいきょうの二重サブミット対策 - Qiita

猶予8時間!脆弱性だらけのサービスを堅牢化する実践型研修 - Speee DEVELOPER BLOG

JavaEEでリクエストのHTTPヘッダに値を付加する - No Programming, No Life

GitHub - making/oauth2-sso-demo: Simple OAuth2 SSO Demo with Spring Boot + Spring Security OAuth2

www.slideshare.net

認証局

SSL/TLS化しているサイトにリクエストを投げたら証明書の検証にしくじっているという時 - その手の平は尻もつかめるさ

設定

SpringBootを使うときに最低限やっておきたいセキュリティ対策 - Qiita

思い付きのストック(WebFW)

自分向けの書き溜め(思いついたときに書き足す)。
いつになるか分からないけど、自分なりのJavaEEに薄いラッパーをつくるにあたって、やっておきたいこと。今のシステムのベースとして既に作り込んでいるものも含めて。既に実装しているものについても拡張性や交換可能性まで考慮は至っていないところばかりなので、その辺の見直しも含めた指針。
また、JavaEEがあると楽に環境が準備出来るけど、現状の私自身はTomcatを使っていることもあり、JavaEEに強依存した仕組みには極力したくないと思っている。

なぜ

JavaEEにしてもSpringにしても、セキュリティとかログとかインターセプターとか、なにかしらラップをするものが必要だと思ったから。また要件によって独自実装をする領域を基盤となるフレームワーク(JaveEEとかSpringBootとか)に挟んでおくことで、柔軟な拡張ポイントを確保することも出来るし、それが出来た方が良いと思う。 やりたいことは、すべてに対応するフレームワークというよりも、どこで何を拡張するのか分かりやすいフレームワーク
場合によっては、作業指針にとどまるケースもあると思っている。例えば、DB周りのツールとしてDomaを使う場合、Domaに依存させるのは、このレイヤーまでに留めて、ドメイン領域には浸食しないようにしましょう、みたいな。
考えているのは「書き換えを前提としているフレームワーク」とか「作法を規定するので中身はご自由に。一応、自分なりに便利だと思うコードは準備しておくけど、好きに書き換えてもらっていいですよ」というユルーイもの。つまり、オレオレフレームワークの雛形みたいなもの。

自分で動機を整理しつつ「こんなもの誰がいるのかな?」という思いはありつつ、自分自身が仕組みを作る中で試行錯誤した経緯を考えるとオープンなもので1つくらいあっても良いかなと改めて思ったので、とりあえず出来るだけやってみたいなと思う。*1

何を

共通部品

認証・認可

独自実装:あり
インターセプトで実装。現状はセッションのユーザー情報で保持している権限と、Controllerで指定した権限とのマッチングで制御している。
できればOAuth2みたいな感じで認証サーバーとの連携するようなサンプルまで出来たら素晴らしいんだろうな。

セキュリティ

独自実装:一部あり
CSRFXSSセッションハイジャック、といったところを仕組みとしてまとめたい。今はクローズドな環境で、更新をするユーザーが ごく限られているので、このあたりは後回しにしているけど、必ずほしい機能。

ログ

独自実装:あり
インタセプターによる自動ログ出力と、Producerによる実装をしてはいる。ただ、ログファイルの制御がいまいちちゃんと出来ていないとか問題が多い。。ログについては使用したいツールがシステムによって異なると思うので、そのあたりの置き換え容易性などを考慮した整理とあわせて、ちゃんと見直しをしたい。

例外

独自実装:あり
アプリケーション独自例外が、ログ出力とかメッセージ出力とかツールチップ制御とか、ごちゃごちゃになってしまっている。もっとスッキリできると思うので、ちゃんと見直しをしたい。もしくは、ドキュメントを整理して利用や改修をやり易いようにしておきたい。

バリデーション

独自実装:あり
メッセージの置き換えや、ツールチップの出力位置の情報共有については、自分なりに一旦は実装できたと思う。ただ、メッセージとバリデーションが密結合になっているので、そのあたりをもっと整理したい。
JSFのメッセージ出力とツールチップ出力と強依存の実装になっているところもある。ダメではないような気もするけど「パーフェクトJavaEEJavaEE」のCDI(2章)を読んだ印象では もうちょっと良い感じな整理が出来そうな気もしている。

国際化対応

独自実装:なし Resourceの汎用読み込みは実装済み。
propertiesを都度参照してメッセージを探すのではなくて、Enumで定数にしてパンチミスなどの発生させないようにしたい。 (propertiesからEnumAnnotationProcessorで生成する仕組みを検討中)

プレゼンテーション関連

メッセージツールチップ

独自実装:あり
例外時に限った実装になっている。例外とは分離させて、ツールチップ単体として完結したものにしたい。例外時には部品としてそれを使用するイメージ。

Ajaxによる更新

独自実装:あり
過去のブログは、現システムのエッセンスを抽出したものに近い。パッケージとして整理さえすれば良いだけかもしれない。

サブ画面制御

独自実装:なし

ダイアログとか子画面とか、そういう感じのもの。個人的には避けたい実装だけれど、実際の要件としては良く挙がっているネタなので。
PrimeFacesとかリッチコンポーネントもあるけれど、ここで試したいのは、サブウィンドウ。
参照サブウィンドウではなく、登録サブウィンドウ。 モーダル制御までするのであれば、それはHTML5とかPrimeFacesとかの出番なので、それは関与しない(ブラウザの挙動ではモーダルを保証できないという過去の経験より)。
この辺は、全くの無知なので、落としどころも含めて考察から必要。

モーダル画面連携

独自実装:なし

「サブウィンドウ」ではなくて、モーダルダイアログへの連携。クライアント側の実装については、各種クライアントフレームワークjQueryでゴリゴリとかやり方はたくさんあるので、そちらにお任せ。あくまで「連携」をするための仕組み、もしくは作法の整理。
この辺は、全くの無知なので、落としどころも含めて考察から必要。

ドメイン関連

カテゴリは設けたけど「POJO」であることがポイントになる気がするので、フレームワークとして設けないといけないことは、今のところ思いつかない。

永続化関連

DB操作

独自実装:あり

外部SQLファイルの参照について、独自に作り込んで「しまった」。このメモを整理している中で調べて見たら方法があったようだ。。

SQL文を外部ファイルに|老いぼれSEの艱難辛苦

ただ独自の実装といっても、指定のクラスパス内の指定クエリー名を読み込むだけのシンプルなもの。結局はNativeQueryで使用する文字列をどうやって渡すのか、というだけの話だから、これはこれで残しておいても良いかな、とも思う。それに上述のリンクは「NamedQuery」の話みたいだから「NativeQuery」でも同じかどうかは検証が必要になると思う。また、外部SQLファイルの検証を考えるとXML定義にしておくよりも平文SQLファイルの方が扱いやすい気がする。

現状の方式は、DBからNetBeansでEntityクラスを生成+基本となるクエリーは自動生成しておき、その他に必要な問い合わせをJPQLや外部SQLで作成をしている。Entityクラスの自動生成は色々な方法があるし、プロジェクトによってはExcelから自動生成をすることもあると思う。個人的にはDBからの取得結果のDTOとして充足していれば、それで良いと思っている。なので、ここでは、自動生成したEntityクラスに手を加えるのではない方式を整理できればと考えている。

少なくとも、今は自動生成したEntityクラスに問い合わせクエリーを記述したり、しなかったりと統一していないので、そこは見直したい。

また、これを言ったらどうしようもないんだけれど、永続化周りについては、DomaMyBatisDBFluteとか仕様としてのJPAすら適用外になることも多そうだし、SQL生成および外部SQLの読み込みそのものについても、採用する技術要素によって大きく変わってくると思う。

検討する指針としては「どのような技術要素でも、永続化においてドメイン領域と明確に分離する整理が出来ていること」「どのパッケージで、どういうことをするのか明確に整理すること」をポイントにしたいと思っている。なので、私が実装した外部SQLファイル読み込みの仕組みに強依存しない方が良いと思っている。

トランザクション制御

独自実装:あり

アプリケーションサーバー(Tomcat)のシステムのため、トランザクションEntityManagerを使って行っている。現状はEntityManagerに基本操作を加えたラップクラスを設けている。それはService層でEntityManagerを直接操作をするのを避けたいという考えから。
正直、トランザクション境界であれば、EEサーバーを使うことで、こんなことをしないでも良いと思う。 どちらかというと、ここで検討しておきたいのは、@Transactionalを直接使用しないことと、トランザクション境界をControllerの操作境界と同じようにログ出力などを同時にするようなインターセプターを実装することを想定している。
たとえば、EEサーバーとアプリケーションサーバーをそれぞれ分けて検討して、EEサーバーの場合、トランザクション境界は@Transactionalを使用することで解決しつつ、処理の前後のログについては独自に実装したインターセプターを作成する、とか。
まずはアプリケーションサーバー(JTAの実装を持っていないサーバー)から実装を作って、EEサーバーだと こんな風に書き換えたら良いと思いますよ、みたいな参照実装が作れたら良いなぁと思っている。

どのように(サンプル)

どんなものを作る?

フレームワークに限らず、道具は実際に自分が使ってみて嬉しいものであることが一番大事。そして、できればサンプルのためのサンプルではない方がさらに良い。
個人的な経験として、システム構築において1から作り込む手順を記すよりも、動く雛形システムがあって それを改造するのが一番楽だと思っている。

ということで「ユーザー登録」あたりが一番いいかなぁと思っている。 出来ればJavaEEでモノリシックなものと、Restなマイクロサービスっぽい感じの2パターンが作れたら良いかなぁ。
なんとなーく、この2つが出来たら、一見モノリシックなJavaEEな実装に見えるけど、フレームワーク部分が頑張る事で裏ではマイクロサービス風な仕組みが動いている、みたいなことが出来そうな気がしている。
一番の課題はトランザクション関連になると思っているし、そこについて問題が解消できるとは正直思っていないんだけど、なんとなーく構想だけはあるので、そこまで出来たら個人的には大満足。

パターンは?

同じユースケースでも、オペレーションは様々あると思っているし、いくつかのバリエーションを設けておくことで有用なサンプルになると思っている。

  • ショッピング風

SAStrutsの登録ユースケースのイメージ。入力→確認→完了、のパターン。
JavaScriptなどの無いシンプルなWebシステムらしい感じのパターン。

  • SPA

1画面でリアルタイム(またはSubmitで)登録するイメージ。問題は通信上の情報改竄を仕組みとしてどうやって回避できるのか、だと思う。「ショッピング風」は実際の登録情報はサーバー側に保持しているもので処理をするので、そのあたりの心配はないけれど、SPAの場合どうなるのか調べるところからになると思っている。
Restにおけるセキュリティと同じような課題になるかなぁと何となく考えているので、ここをちゃんと解消できたら色々と幅広い領域についても安心なものになる気がしている。

  • サブウィンドウ

登録用サブ画面を使うパターン。クラサバだとよく出てくるパターンと思っている。
SPAが出来たとしたら、このパターンも割と安全に実装できそうな気がしている。 あとは、親画面の方に良い感じに情報を連携できるのか?というところが課題になりそう。できるだけJavaScriptでリッチな実装をしないという風にしたい。

  • 一覧処理

新規登録ではなく、既存データの修正をする場合のパターンとして、一覧から直接部分的に修正をする。これもクラサバだとよくある気がする。

  • 大量処理

所謂、ファイルダウンロード&アップロードによる更新処理。個人的にCSV(カンマ区切り)は好きではなく、TSV(タブ区切り)の方を選びたい。ただ、それはそれで多くの人になじみがなさそうなので、見栄えの調整もしやすいExcel形式を考えている。
ここについてもポイントはファイル形式ではなくて、仕組みの方になるようにしたいと思っている。例えば「CSV形式にしたい場合は、ここの部分を変更したら良いんだな」と分かりやすいようなクラス分割をする、みたいな。

今回は会話型で対応しうる大量処理を前提にするに留めて、対応するのは同期・非同期の制御までは出来たら良いかなと思っている。

大量処理というと「バッチ」になると思う。ただそういうのはWebからトリガーするというだけでなく、タイマーとかコマンドで実行するフローになると思うので、今回の構想には入れないつもり。またバッチ処理については、自分の中でコレでいったん整理してみよう、という構想すら持ち合わせていないからという後ろ向きな理由もあったりしますが。。だからといってバッチを甘く見ているわけではなく、元バッチCOBOLerだった私としてはバッチ(分散処理・大量処理)の重要さは経験的に理解しているつもりではいます。むしろ、WebFWと混ぜてはいけないと思っていて、中途半端な整理はしたくないなぁと。まぁ言い訳ですね。

参考になるかな

Spring Boot で Boot した後に作る Web アプリケーション基盤/spring-boot-application-infrastructure // Speaker Deck

#jjug_ccc DDDとMicroservicesについて喋ってきましたー(∩´∀`)∩ - Mitsuyuki.Shiiba

GitHub - jkazama/ddd-java: Spring Boot + Java7 [ DDD Sample ]

Rubyist Magazine - HanamiはRubyの救世主(メシア)となるか、愚かな星と散るのか

*1:思うだけで終わる可能性も十分ありますが

JJUG CCC 2017 Spring に参加してきました

日本Javaユーザーグループ 年次総会

ここから話題ににする必要があるか分かりませんが、会長の鈴木さんの話し方は妙に安心感があるなぁと毎度のことながら感心しきり。

大事な事

  • 申し込みしたけど参加できない場合はちゃんとキャンセルしましょう
  • キャンセル待ちを諦めないで!

ふつうのJavaコーディング

ふつうのJavaコーディング #ccc_e1 // Speaker Deck

印象に残ったところ

  • コードは読み物
  • メソッドは高次元に特化したものに
  • 防御的プログラミングを避ける
  • ギリギリまで文字列に頼らない
  • 型と向き合う(DDD的なことだと思う)

業務アプリにおける実装としては正しいことが多いと思った。ただ基盤的なところの実装については(コアAPIとまではいかないけど)ある程度 汎用的であった方が個人的には分かりやすいと思う。いずれにしても、その汎用的なものは業務アプリに落とし込む過程で「特化した実装」にした方が良いと言うのは賛成。

ちょっと考えたところ

  • 固定値の引数はメソッドを作る
    型がEnumでメソッド名と定数の組み合わせで文章として成立していたら可読性は保たれていると思うんだけどなぁ。どうなんだろ?
    でもコンストラクタのパラメータで属性を分類するのではなくて、それはクラスで実装するから、正しい気もするな。
    ひょっとしたらサンプルのメソッド名がドメインを表現するような命名だったら印象違ったのかな? 基本思想としては賛成だから、賛成で良いかも。

Java Clientで入門するApache Kafka

基本知識が無かったので駆け足で理解できた。話し方も丁寧だった。 過剰にモックを準備することなく、ローカルでテストするためのやり方を具体的に目にすることが出来たのは、とても良かった。 これってController層とService層の間の通信をKafkaで疎結合させたら冗長性を簡単に拡張出来るのかな?と思った。

Selenideを使ってみた ブラウザテスト自動化

ブラウザのテストは現状、手作業でやっているけど、Selenideは機会があったら使ってみようと思った。自動化に頼りすぎないというのも良い知見だと個人的には思う。

Javaで実装して学ぶOAuth 2.0

Javaで実装して学ぶOAuth 2.0! // Speaker Deck

  • 対象とするのは認可(認証じゃない)
  • 登場人物の名称と定義を正確に理解するべし

歯ごたえのある内容だったので大変満足。
誤解しがちなところを強調して下さったので、雰囲気での理解から一歩踏み出せた気がする。 結構、自分で実装しないといけないところがある低レベルフレームワークなんですね、という印象。よく言えば汎用的で幅広いのかな。
触ったことは無いけどApache Shiroみたいな感じのものがあると利用しやすいのかな?

Java x Arduinoで始めるIoT

格安のクライアント環境をテスト的に準備してみようとRaspberry Piを試してみたことはあったけどIoTという感じではなかった。
値段も安いし、ハンダも不要のArduinoは、いろいろと試すのには面白そうに思った。
JJUG的な側面の話は少しだったかもしれないけど、こういう話があるのもJJUGの面白さだと思う。

さいごに

以前、お仕事を一緒にさせていただいた方に会って、懇親会はLT大会そっちのけで、その方と話をしたのが何気に充実した時間だったり(笑)
縁とは不思議なものだと思うのと共に、興味の範疇が似ていることが面白かった。
新しい情報が少ないのでJJUGで取り上げられる機会が少なくなっていますが、JavaEEJSF・Facelets含めて)ってそんなに悪くないと思うんですけどねぇ。。良い感じに復権していただきたいところです。

セミナー資料のまとめ

自分向けのメモ

Java Day Tokyo

Java Day Tokyo 2016

Java Day Tokyo 2015

Java Day Tokyo 2014

online20130514-javaday

JJUG CCC

JJUG CCC 2017 Spring ( #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

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

Java読書会BOF

Java読書会BOF

  • 行ったことは無い。書評的に読んでみると良いかもしれない。