SlideShare a Scribd company logo
Seasar2で作った俺たちのサービスの今
阪田 浩一 (さかた こういち)
@jyukutyo じゅくちょー
フリュー株式会社
元塾講師アルバイト
関西Javaエンジニアの会(関ジャバ) 会長!?
2009年秋 発足
2014年11月 JUG入り
SI(客先常駐) 9年 / 自社サービス 5年目
blog : Fight the Future http://jyukutyo.hatenablog.com
昨年(2015年)のJJUG CCC 2015 Springでも話しました
http://www.slideshare.net/jyukutyo/jjug-ccc-2015ab4
2016/9/26にSeasar2は
サポートを終了する!
DBFlute DBFlute.NET Doma
Emecha Mayaa S2Container.NE
T
S2Dao.NET
以下を除いた全プロダクトが
EOLとなります!
つまりJavaでの
Seasar2関連は
ほとんどが対象
このセッションは、
それを受けて
プロジェクトで
移行を始めた
事例の紹介です
今日のゴール
対象 S2で開発/運用している人
提供したい
こと
対象の人たちがS2から
移行する際の参考事例
注意事項
“ベスト”プラクティスでは
ないこと
まずは結論から
結果:Springに移行
2016年2月にリリース
移行前 移行後
プレゼンテー
ション層 Cubby 2.0
Spring MVC
2.4.3
永続化層 S2Dao 1.0.51 Doma 2.6.0
コンポーネント
フレームワーク S2 2.4.43 Spring 2.4.3
ただし、2月に
リリースしたのは
あくまで1機能のみ
リリース内容は
同一機能の
リプレース
その後
さらにいくつか
リプレースした
2016年5月現在
3機能がSpringで
動作している
そんな状況です
今日
お話しすること
結果に至るまでのこと
“なぜ”Spring/Domaなのか?
“どのようにして”移行したのか?
“何に”詰まった/困ったのか?
なぜSpring/Doma
なのか?
WebSocketやSSEを(楽に)使いたい
Java 8に移行したので、
それに対応するFWにしたい
長期間、同じ運用開発をしているので、
メンバーの飽きを防ぎたい
ただし移行の緊急性は高くない
(ように思う)
そもそもS2から移行する
必要があるのか?
こうした理由に至った
僕らの背景を
簡単にご紹介します
(あくまで理解の
補助として)
対象アプリケーション
サービス名 ピクトリンク
サービス
イン
2011年
(前身サービスはもっと以前から)
利用者数
1,000万人
女子高生の70%は会員
(有料会員数は秘密)
主な機能
プリントシール機で撮影した画像を
取得できる
提供
Webサイト
iOSアプリ/Androidアプリ
課金
携帯電話キャリア課金 / 楽天ID決済
iOS課金 / Android課金
PageView 月間約1億PV
備考:プリントシール機とは
ゲームセンターや
ショッピングモールにある
写真を撮影をする機械。
女性の利用が多い。
開発チーム構成
サイトチーム 6名
• 私がリーダを担当
アプリチーム 7名
• iOS
• Android
• Web API
インフラチーム 5名
• サーバ
• ネットワーク
• Ansible
• Elasticsearch/Ki
bana
• Oracle RAC
ログチーム 3名
• Tableau
• BigQuery
HTML/CSS 2名
• デザインをHTML
に
合計23名
私はサービスインの
半年後に
参画しました
23名という人数と
開発開始から
5年以上経過している、
そういう状況
10年くらい標準だったよう
S2、S2Struts、Cubby、S2Daoなど
ただし、ここ5年ほど私の部署以外では
新規プロジェクトでScalaを採用
全社的に標準が
S2ファミリーだった
言語はJavaとする
運用開発チームの特性上、FWだけでなく
言語も変わると、メンバーが対応できない
日々の工数すべてを移行に避けない
機能改善/追加と並行に作業する
アプリケーションを作り直さない
テスト手順が煩雑なキャリア課金がメインのため
移行先FWの前提条件
All or Nothingの移行は
やっぱり
リスクが高すぎる!
(ように思う)
まずは移行先となる
フレームワーク(FW)
を調査する
移行先FWで調査した候補
Spring
Spring MVC
Spring Boot
Java EE
JSF
JAX-RS
Jersey MVC
Play Framework
Spark Framework
Jodd
Ninja
Doma
JOOQ
JDBI
Bootiful SQL Template
A simple SQL template
engine for Spring Boot
考えたこと:
もうトレードオフで
判断するしかない
S2、Cubby、S2Daoとそれほど
考え方が離れていないFWとする
学習にかけられる期間、工数を最小限に
今あるサービスクラスを
(少なくとも多少コードを書けば)
利用できるFWとする
トレードオフで重視したこと
Servletで動作するFWとする
既存のWebアプリと同一のWARファイルに
監視会社へ監視依頼する数が増えない
コストが増えない
同一のアプリケーションとなりシンプル
アプリケーション間で連携するのは複雑そう
トレードオフで重視したこと
みなさんの
プロジェクトでは、
どんな前提条件や
どんなことを
重視しますか?
そして、
僕らの判断理由は
決定:Spring MVC + Doma!
プレゼンテー
ション層
Spring MVC
2.4.3
Cubbyのアノテーションの
使い方と似てる感じ。
WebSocketに対応。
永続化層
Doma
2.6.0
S2Daoと同じく2-Way SQL。
Java 8に対応。
新規DaoはDomaで、既存
Daoは少しずつ置き換え。
コンポーネント
フレームワーク
Spring
2.4.3
S2Daoを含んだ既存資産は
DIコンテナがある方が
利用しやすいと判断。
ちょっと詳細
Cubby ->
Spring MVC
CubbyとSpring MVC似てる?
Cubby
@Accept(RequestMethod.GET)
@Path("index")
public ActionResult index() {
return new Forward("/index.vm");
}
Spring MVC
@RequestMapping(path = "/index",
method = RequestMethod.GET)
public String index() {
return "/index.vm";
}
Cubbyから移る
前提なら、
読めば内容が
理解できる近さ
S2Dao ->
Doma 2
S2DaoとDomaのDaoクラス
S2Dao
@S2Dao(bean = Employee.class)
public interface EmployeeDao {
@SqlFile
@Arguments({ ”employeeId” })
Employee findById(Integer employeeId);
}
S2DaoとDomaのDaoクラス
Doma
@Dao
@AnnotateWith(annotations = {
// 生成されたDAO実装クラスに@Componentを付与する
@Annotation(target = AnnotationTarget.CLASS,
type = Component.class),
// 生成されたDAO実装クラスのコンストラクタに
// @Autowiredを付与する
@Annotation(target = AnnotationTarget.CONSTRUCTOR,
type = Autowired.class)})
public interface EmployeeDao {
@Select
Employee selectById(Integer employeeId);
}
S2DaoとDomaの
SQLテンプレート
S2Dao
select
*
from
employee
where
/*IF employeeId != null */
employee_id = /*employeeId*/9999
-- ELSE department_id is null
/*end*/
S2DaoとDomaの
SQLテンプレート
Doma
select
*
from
employee
where
/*%if employeeId != null */
employee_id = /* employeeId */9999
/*%else*/
department_id is null
/*%end*/
差異は少ない
Domaの
公式ドキュメントに
DIコンテナとの
連携方法も
書いてある
どのようにして
移行したのか?
まず
2014〜15年で
Javaを 6 -> 8
Tomcatを 6 -> 8
へ移行しておいた
基盤のバージョンアップは
すでにクリアしている
ただし、Java 8の機能を
駆使したコードは
まだなかった
同時に当時から
少しずつ時間を取り、
メンバーに
Java 8の機能をレクチャー
新FWの学習だけを
進めればよい状態
としていた
さて、
移行後
アプリケーションは
こういう構造に
Application (WAR)
S2Servlet DispatcherServlet
DIコンテナ DIコンテナ
Cubby Action
Service / Logic
S2Dao DAO
Interceptor
MVC Controller
Service / Logic
S2Dao DAO
Interceptor
Doma2 DAO
同一のJS/CSS/テンプレートファイル
1つのアプリケーション
2つのDIコンテナ
DIコンテナそれぞれで
重複して
オブジェクトを
管理することになる
なお、サーバ起動時間、
ヒープ使用量に
大きな差は出ていない
(だいたい
シングルトンなので)
新旧FWの振り分け
Servlet Mapping / Filter
/*
/2/* 左記以外
Cubby ActionMVC Controller
web.xmlで設定
続いて
既存資産の利用
S2Daoを利用している
Service / Logicを
既存資産として
Springでも利用する
つまり、S2Daoの
Daoオブジェクトを
SpringのBeanとして
管理できればよい!
SpringでS2Daoを使う -その1-
n-ichimuraの日記
2006年!
http://d.hatena.ne.jp/n-ichimura/20061119/1163944881
過去にSpring + S2Daoを
検証した方が!
そのコードを参考に
現在の状況に合わせて
実装した
これで無事
SpringでS2Daoが
利用できた!
続いて
Spring MVCでの
課題
Cubby Actionから
Spring MVC Controller
へ書き換えるのは
いいとして
リクエストパラメータ
のバリデーションは
どうしよう?
Cubby標準のバリデーションから
Spring MVCでBean Validation利用へ
JSR-349 Bean Validation 1.1
Method Validationを使う
コントローラのメソッドを対象に
リクエストパラメータの
バリデーション
なぜ
Method Validation
を選んだのか?
Cubbyからの移行なので、
リクエストパラメータ
をModelに入れる
方式に慣れていない
(メンバーが多い)
サービスの性質上、
複雑なバリデーション
はない
メソッドの引数に
アノテーションを
つけるだけの
Method Validation
でよさそう
という判断です
Cubbyでのバリデーション
アクションクラス
@RequestParameter(name = ”hoge”)
public String hoge;
protected ValidationRules rule =
new DefaultValidationRules() {
@Override
protected void initialize() {
add(”hoge”, new RequiredValidator());
}
};
@Validation(rules = ”rule”,
errorPage = ”/error.vm”)
public ActionResult index() {
リクエストパラメータ
を1つずつ
インスタンス変数で
受け取っていた
メソッドバリデーション
コントローラクラス
@Controller
@Validated
public class HogeController {
@RequestMapping(path = “validate",
method = RequestMethod.POST)
public ModelAndView validate(@NotEmpty String s) {
..
}
Spring MVCでは
リクエストパラメータを
コントローラメソッドの
引数で受け取れる
この引数に対して
アノテーションで
バリデーションを
設定する
メソッドバリデーション
コントローラクラス
@Controller
@Validated
public class HogeController {
@RequestMapping(path = “validate",
method = RequestMethod.POST)
public ModelAndView validate(@NotEmpty String s) {
..
}
Bean Validation仕様と
その実装Hibernate
Validator独自の
バリデーションの
アノテーションは
そこそこ用意されている
バリデーション用
アノテーション
@AssertFalse/True
@DecimalMax/Min
@Digits
@Future/Past
@Max/Min
@Null/NotNull
@Pattern
@Size
@CreditCardNumber
@Email
@NotBlank
@NotEmpty
@Range
@URL
@ScriptAssert
etc.
独自のアノテーションも
もちろん作れる
で、
バリデーションエラーに
なったときは?
例外
javax.validation.
ConstraintViolationException
が発生する
この例外を
Springの
ExceptionHandlerで
処理することにする
ExceptionHandler
@ExceptionHandler(value=ConstraintViolationException.class)
public ModelAndView handleValidationFailure(
ConstraintViolationException e) {
Set<ConstraintViolation<?>> v = e.getConstraintViolations();
...
// Cubbyにおけるバリデーション失敗時のJSON構造と合わせる.
// バリデーション対象の変数名をキー、メッセージのリストを値としたMapに
Map<String, List<String>> f = v.stream()
.collect(
toMap(
c ->
((PathImpl)c.getPropertyPath()).getLeafNode().asString(),
c -> {
List<String> l = new ArrayList<>(1);
l.add(c.getMessage());
return l;
}
これでほぼOKなんだけど
困ったことが…
最初SpringでMethod Validationが
動作せずちょっとハマった
Bean Validationはメッセージリソース
を利用できるが、”{0}は必須です”の
{数字}の置換が使えない
困ったこと
SpringでMethod
Validationを使う時は
MethodValidationPostProcessor
をBean登録する、
のだけど…
MethodValidationPostProcessor
インスタンスの生成時に
LocalValidatorFactoryBean
インスタンスをvalidatorとして
セットしましょう
公式リファレンスには
はっきりそうと書いていない感じ
SpringでMethod Validation
が動作せずちょっとハマった
MethodValidationの
Bean設定
@Bean public LocalValidatorFactoryBean l() {
LocalValidatorFactoryBean l = new LocalValidatorFactoryBe...
ReloadableResourceBundleMessageSource r =
new ReloadableResourceBundleMessageSource ();
r.setBasename("classpath:/messages");
l.setValidationMessageSource(r);
return l;
}
@Bean public MethodValidationPostProcessor
m(LocalValidatorFactoryBean l) {
MethodValidationPostProcessor m =
new MethodValidationPostProcessor();
m.setValidator(l);
return m;
}
Bean Validatorでメッセージに
リソースバンドルの値は設定できる
@NotEmpty(message=“{valid.required}”)
Validationのアノテーションの属性値
はリソースバンドルから読める
@Size(min = 2, message = ”{size.min}”)
size.min={min}桁未満は入力できません
Bean Validationでの
リソースバンドルの利用
今使っているこういうのができなさそう
required={0}は必須です
password=パスワード
name=名前
組み合わせて...
“パスワードは必須です”、“名前は必須です”
Bean Validationでの
リソースバンドルの利用
org.hibernate.validator.messageinterpolation.
ResourceBundleMessageInterpolator
を継承して実装した
length={0}は{1}文字以下です
password=パスワード
five=5
@Size(message = ”{length}{0:password}{1:five}”)
出力:パスワードは5文字以下です
組み合わせられる実装を
作った
難点:プロパティのキーを
複数使ったり、キー文字列
が長いと読みづらい
message = "{valid.maxLength}
{0:hoge.fuga.example.title}{1:max}"
よりよい方法があれば
ぜひ教えてください〜
メッセージリソースは
そのままSpring MVCでも
使えるようになった
ここでまったく
別の観点で課題が
既存のユニットテスト
が動かない!
全クラスにユニットテストがある
S2TigerTestCaseクラスを継承
EasyMock + djUnit + JUnit3
ユニットテスト
ラムダ式を書いたら
djUnitの部分で
エラーが発生!
java.lang.Error: djUnit class load error
(Class : com.example.ExampleClass)
at jp.co.dgic.testing.common.DJUnitClassLoader.findClass
(ClassLoader.java:424)
at jp.co.dgic.testing.common.DJUnitClassLoader.loadClass
(DJUnitClassLoader.java:45)
at java.lang.ClassLoader.loadClass
(ClassLoader.java:357)
at com.example.ExampleClassTest.setUp
(ExampleClassTest.java:79)
djUnitでエラーが発生
djUnitはもう
更新がないため、
Java 8に対応していない
内部で利用している
ASM/BCELの
メジャーバージョンアップ
に対応していない
逆に言うと、
djUnitを使っていない
ユニットテストなら
動作する
新規/変更したクラスのユニットテスト
は、クラス単位ですべて書き換えた
JMockit + JUnit4
ユニットテストの書き換え
モックライブラリ
機能が豊富
APIの呼び出し方が少し変わっている
JMockitとは
JMockit or Mockito + PowerMockで検討
JMockitの方が、djUnitを使ったテストコー
ドを単純に書き換えやすそうに感じた
JMockitにした理由
JMockitへの書き換え
S2TigerTestCase + EasyMock + djUnit
public class ExampleActionTest
extends S2TigerTestCase {
private ExampleAction tester;
@EasyMock(register = true)
private ExampleService service;
public void setUp() { ... }
public void recordIndex() {
...
EasyMock.expect(service.something())
.andReturn(serviceResult);
}
public void testIndex() throws Exception {
Forward actual = tester.index();
assertEquals("/hoge/fuga.vm”, ...);
}
JMockitへの書き換え
JMockit
public class ExampleControllerTest {
@Tested
private ExampleController tester;
@Injectable
private ExampleService service;
@Test
public void testIndex() throws Exception {
...
new Expectations(tester) {
{
service.something();
result = serviceResult;
}
};
String actual = tester.index();
assertThat(actual, is("/hoge/fuga.vm"));
}
JMockitでの書き方が
見慣れない感じですね
しかし
チームへの導入で
とくに抵抗はなく、
みな書き換えができた
ちなみに、
移行した機能の
いわゆる結合テストは
すべて手で再実施…
後の方で
発覚したこと
「あ、S2Velocityの
機能も移行しないと
いけないのか」
S2Velocityを使い、Veloctityツールの
インスタンスをS2Containerで
管理していた
Velocityツールとは
テンプレートファイルで利用する
ユーティリティクラス
Velocityの利用
同一のテンプレートファイルを
Springのときでも動作させるためには
同様の仕組みが必要となる
ToolboxManager/VelocityToolboxView
を実装
SpringのコンテナからVelocityContextに
Velocityツールのインスタンスを渡す仕組み
を実装した
Velocityの利用
これで既存の
テンプレートファイルを
そのままSpring MVCから
利用できるようになった
Tipsを2点
Tips(1)
既存クラス
@Component(name = ”example”,
instance = InstanceType.REQUEST)
public class ExampleClass {
スコープの設定
@Componentアノテーションを読み取って
スコープ設定をするSpringのResolverを
作成
Tips(2)
既存クラス
@Component(name = ”example”,
instance = InstanceType.REQUEST)
public class ExampleClass {
Bean名の設定
@Componentアノテーションを
読み取ってBean名を生成する
SpringのBeanNameGeneratorを作成
その他
2時間のミーティング
主に以前との差分、新しい書き方や
意味を説明
ほぼ抵抗なく習得へ進んだ
メンバーへのレクチャー
Springで動作させる機能を増やす
2016年5月現在で3機能なので
機能単位での独立したサービスにする
マイクロサービス化?
企画要件へ利用できるようになった
技術を適用する
WebSocketを使うとユーザにどんな体験を
提供できるか
今後の展望
S2からの移行、
怖くないよ!
ご清聴
ありがとうございました!
Q&A

More Related Content

PPTX
JJUG CCC 2017 Spring Seasar2からSpringへ移行した俺たちのアプリケーションがマイクロサービスアーキテクチャへ歩み始めた
PDF
人生がときめくAPIテスト自動化 with Karate
PDF
DevOps with Database on AWS
PDF
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
PDF
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
PDF
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
PDF
Dockerからcontainerdへの移行
PDF
GitLabのAutoDevOpsを試してみた
JJUG CCC 2017 Spring Seasar2からSpringへ移行した俺たちのアプリケーションがマイクロサービスアーキテクチャへ歩み始めた
人生がときめくAPIテスト自動化 with Karate
DevOps with Database on AWS
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
Dockerからcontainerdへの移行
GitLabのAutoDevOpsを試してみた

What's hot (20)

PDF
劇的改善 Ci4時間から5分へ〜私がやった10のこと〜
PDF
ドメイン駆動設計 ( DDD ) をやってみよう
PPTX
CloudFront経由でのCORS利用
PDF
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
PDF
こんなに使える!今どきのAPIドキュメンテーションツール
PDF
フロー効率性とリソース効率性について #xpjug
PDF
こわくない Git
PPTX
GraalVMを3つの主機能から眺めてみよう(Oracle Groundbreakers APAC Virtual Tour 2020 講演資料)
PDF
がんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とは
PDF
MySQLレプリケーションあれやこれや
PDF
TDD のこころ
PDF
Amazon Cognito使って認証したい?それならSpring Security使いましょう!
PDF
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
PDF
PostgreSQLアンチパターン
PDF
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
PDF
Form認証で学ぶSpring Security入門
PDF
これからのJDK 何を選ぶ?どう選ぶ? (v1.2) in 熊本
PDF
テスト文字列に「うんこ」と入れるな
PDF
コンテナ環境でJavaイメージを小さくする方法!
PDF
Confluence と SharePoint 何が違う?
劇的改善 Ci4時間から5分へ〜私がやった10のこと〜
ドメイン駆動設計 ( DDD ) をやってみよう
CloudFront経由でのCORS利用
速習!論理レプリケーション ~基礎から最新動向まで~(PostgreSQL Conference Japan 2022 発表資料)
こんなに使える!今どきのAPIドキュメンテーションツール
フロー効率性とリソース効率性について #xpjug
こわくない Git
GraalVMを3つの主機能から眺めてみよう(Oracle Groundbreakers APAC Virtual Tour 2020 講演資料)
がんばらなくても C# で Single Page Web アプリケーションが書けてしまう「Blazor」とは
MySQLレプリケーションあれやこれや
TDD のこころ
Amazon Cognito使って認証したい?それならSpring Security使いましょう!
【BS4】時は来たれり。今こそ .NET 6 へ移行する時。
PostgreSQLアンチパターン
AWSとオンプレミスを繋ぐときに知っておきたいルーティングの基礎知識(CCSI監修!)
Form認証で学ぶSpring Security入門
これからのJDK 何を選ぶ?どう選ぶ? (v1.2) in 熊本
テスト文字列に「うんこ」と入れるな
コンテナ環境でJavaイメージを小さくする方法!
Confluence と SharePoint 何が違う?
Ad

Viewers also liked (8)

PDF
Introduction to Cloud Foundry #JJUG
PDF
Spring Bootで変わる Javaアプリ開発! #jsug
PPTX
OpenJDKは使い物になるか?OpenJDKの実際と今後 (NTTデータ オープンソースDAY 2015 Autumn 講演資料)
PDF
Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」 #jjug_ccc #ccc_f3
PPTX
将来 自分で サービスを持ちたいエンジニアの葛藤
PPTX
高速なソートアルゴリズムを書こう!!
PDF
Java9を迎えた今こそ!Java本格(再)入門
PPTX
Dockerで始める Java EE アプリケーション開発 for JJUG CCC 2017
Introduction to Cloud Foundry #JJUG
Spring Bootで変わる Javaアプリ開発! #jsug
OpenJDKは使い物になるか?OpenJDKの実際と今後 (NTTデータ オープンソースDAY 2015 Autumn 講演資料)
Javaエンジニアに知ってほしい、Springの教科書「TERASOLUNA」 #jjug_ccc #ccc_f3
将来 自分で サービスを持ちたいエンジニアの葛藤
高速なソートアルゴリズムを書こう!!
Java9を迎えた今こそ!Java本格(再)入門
Dockerで始める Java EE アプリケーション開発 for JJUG CCC 2017
Ad

Similar to Seasar2で作った俺たちのサービスの今 (20)

ODP
Spring2概論@第1回JSUG勉強会
PPT
試験にでるSpring
PDF
Spring Framework ふりかえりと4.3新機能
PPTX
Spring Fest 2017 「エンタープライズで利用するSpring Boot」#jsug #sf_h1
PPT
Cubby 2006-08-23
PDF
SpringOne 2GX 2014 参加報告 & Spring 4.1について #jsug
PDF
Spring Frameworkの今 (2013年版) #jjug_ccc #ccc_r17 #springframework
PPT
Spring mvc
PPT
SAStruts Seminar In Tripodworks
PPTX
Java EE8 Report
PDF
Jsug2015 summer spring適用におけるバッドノウハウとベタープラクティス
PDF
Java/Androidセキュアコーディング
PDF
Seasarプロジェクト徹底攻略
PDF
Rodから聞いたことを全部話すぜ
PDF
Spring.project
PPTX
Java8移行から始めた技術的負債との戦い(jjug ccc 2015 fall)
PPT
S2dao Seminar in tripodworks
PPT
T2 - 関ジャバ1月27日
PDF
Jjug springセッション
PDF
Spring3.1概要x di
Spring2概論@第1回JSUG勉強会
試験にでるSpring
Spring Framework ふりかえりと4.3新機能
Spring Fest 2017 「エンタープライズで利用するSpring Boot」#jsug #sf_h1
Cubby 2006-08-23
SpringOne 2GX 2014 参加報告 & Spring 4.1について #jsug
Spring Frameworkの今 (2013年版) #jjug_ccc #ccc_r17 #springframework
Spring mvc
SAStruts Seminar In Tripodworks
Java EE8 Report
Jsug2015 summer spring適用におけるバッドノウハウとベタープラクティス
Java/Androidセキュアコーディング
Seasarプロジェクト徹底攻略
Rodから聞いたことを全部話すぜ
Spring.project
Java8移行から始めた技術的負債との戦い(jjug ccc 2015 fall)
S2dao Seminar in tripodworks
T2 - 関ジャバ1月27日
Jjug springセッション
Spring3.1概要x di

More from Koichi Sakata (20)

PPTX
Introduction to JIT Compiler in JVM
PPTX
Guide to GraalVM (Oracle Groundbreakers APAC 2019 Tour in Tokyo)
PPTX
Guide to GraalVM (JJUG CCC 2019 Fall)
PPTX
Introduction to GraalVM and Native Image
PPTX
Introduction to GraalVM
PPTX
GraalVMで使われている、他言語をJVM上に実装する仕組みを学ぼう
PPTX
Bytecode Manipulation with a Java Agent and Byte Buddy
PPTX
Great Ideas in GraalVM
PPTX
Graal in GraalVM - A New JIT Compiler
PPTX
Kanjava 201804 Java News
PPTX
KanJava 201804 Career 思い込みから逃れた先には、可能性がある
PPTX
from Java EE to Jakarta EE
PPTX
Java release cadence has been changed and about Project Amber
PPTX
JJUG CCC 2017 Fall オレオレJVM言語を作ってみる
PPTX
KANJAVA PARTY 2017 前説
PPTX
“Purikura” culture in Japan and our web application architecture
PPTX
デブサミ2017 Javaコミュニティ作ったら人生変わった
PPTX
JJUG CCC 2016 fall バイトコードが君のトモダチになりたがっている
PPTX
日本からJavaOneに行こう!
PDF
How Scala code is expressed in the JVM
Introduction to JIT Compiler in JVM
Guide to GraalVM (Oracle Groundbreakers APAC 2019 Tour in Tokyo)
Guide to GraalVM (JJUG CCC 2019 Fall)
Introduction to GraalVM and Native Image
Introduction to GraalVM
GraalVMで使われている、他言語をJVM上に実装する仕組みを学ぼう
Bytecode Manipulation with a Java Agent and Byte Buddy
Great Ideas in GraalVM
Graal in GraalVM - A New JIT Compiler
Kanjava 201804 Java News
KanJava 201804 Career 思い込みから逃れた先には、可能性がある
from Java EE to Jakarta EE
Java release cadence has been changed and about Project Amber
JJUG CCC 2017 Fall オレオレJVM言語を作ってみる
KANJAVA PARTY 2017 前説
“Purikura” culture in Japan and our web application architecture
デブサミ2017 Javaコミュニティ作ったら人生変わった
JJUG CCC 2016 fall バイトコードが君のトモダチになりたがっている
日本からJavaOneに行こう!
How Scala code is expressed in the JVM

Seasar2で作った俺たちのサービスの今