SyntaxHighlighter

2012年12月31日月曜日

2012年の振り返り


2012年の振り返り。

今年は、いくつか新しいことに取り組む機会があり、特に技術的にはいろいろ得られた年でした。
自分が中心となって開発したものが、一気に採用されてかなり忙しい一年でしたが、よい一年だったと思います。


技術的なものは、以下のウェイトが多かったと思います。

  • Jenkins
  • WebDriver
  • Spring + Thymeleaf

・Jenkins

個人的にはちょこちょこ触ってみてはいましたが、今年、2012年に初めて実プロジェクトの運営で使いましたが、自分の関連プロジェクトはだいたい使うようになりました。

リーダポジションの人で、ある程度アプリケーションの全体像や品質を考えなくてはならない立場の人には結構、受けがいいですが、まだ経験が浅いような若手だとまだあまりメリットを感じれていない人もいます。
(まぁ、Jenkinsがあった開発となかった開発を両方経験しないと、ないときの不便さがわからないというのもありますが。)

具体的に何がいいの?とたまに言われるのですが、自分としては以下の点が気に入っています。

・変更に対するしきいが飛躍的に下がった
Jenkinsで、コミット時に自動的にテストが実行されることにより、気軽に変更したり試したりできることを実感しました。

これには当然、ユニットテストを書く必要があるのですが、Jenkinsではいままでの履歴も保持しており、テスト自体の成長の記録もわかるので、テストを書こうという気にさせてくれます。

過去のプロジェクトの多くでは、ユニットテストを書いてるけどだんだんメンテナンスされていかなくなる、というのを幾度か経験しましたが、Jenkinsでは、自動実行される事により、プロダクションコードと、テストコードが乖離すると、すぐにテストがエラーになるので、修正しなければ先に進めなくなる点も(強制な面はありつつも)気に入っています。

体感的な効果はテストをないがしろにしがちな人も多少、意識が変わってきているという認識です。
いままではテストの話など全然しなかった人が、これはどういう風にテストするといいと思いますか?など言ってくれたりしてくれるようになりました。


・メトリクス関連のツールと組み合わせての品質の予防
checkstyle、findbugsのような静的解析、cobetruaのようなカバレッジツールと組み合わせてある一点で品質を観測するのではなく、連続的にいつでも最新のコードの品質を確認できるようになりました。

自動でメトリクスを取得するので、ある程度システムが出来上がってくると、checkstyleなどをさぼっていると警告数がどんどん増えて行きます。

自分で取得するのではなく、Jenkinsが取得するので手間ではなく、かつ見たときに、あ、細かい部分をさぼってるな、対応しなきゃ、という気にさせてくれます。

もちろん、メトリクスが取る事が目的ではないので、場当たり的な対応やテストコードにならないように注意する必要があり、その部分はまだ浸透はしきれていない部分はあるというのはまだまだ実感しています。


Jenkinsは(というかCIツールになりますが)、自分の中では、なくてはならないものというか、すでにあって当然というスタンスでいます。


・WebDriver

Webアプリの場合、ブラウザ操作を自動化したり、画面の処理結果などを検証したいという場合が数多くあります。

WebDriverはコードでブラウザ操作を行うライブラリで、ブラウザ操作の自動化や、検証についてこれをかなり使っています。

他の候補として、firefoxプラグインとして自分で操作したものを記録し、テストコードを出力してくれるSelenium IDEなども検討してみましたが、なんだかTDDじゃないなぁと思ったり、生成されるコード中にURLや入力値がハードコードされてしまうので、見送りました。

ただし、WebDriverはそのまま使うのではなく、多少ラップして、Excelに手続き的に書いたシナリオをJUnitから自動実行するようにしています。

その他、テスト前のデータ初期化やREST APIの呼び出しなどもテストシナリオに記載できるようにしています。

Excelはプログラマには結構嫌われてしまう面が強いのですが、それなりの規模のプロジェクトではJUnitテストコードをまともにかける人ばかりではないので、Excelで、テストシナリオを書くとWebDriverのテストがかけるというのは結構便利なんじゃないかなと思っています。Excelなら「なんとなく」なら使える人も多いですし。

またJenkins + maven cargo + coberturaと組み合わせて自動テスト時に、ブラウザ操作をしつつ、カバレッジも取るという事もしています。(もちろんこのテストはスローテストになるので、コミット単位ではなく、定期的に実行しています)

webアプリでテストコードだけでカバレッジを取るというのは難しいので、これも助かっています。


・Spring + Thymeleaf

Springは今年ではなく、ここ数年は継続的に扱っています。

Spring関連は組み合わせや自由度が高く、どれを使っていいのか迷う面もありますが、いろんな逃げ道があったり、後発のフレームワークと組み合わせたりできるってのはアーキテクチャを決める側としてはうれしいものがあります。

また、後方互換性にもかなり気を使っているので、バージョンアップの際にも安心感があります。(反面、内部のコードはキレイと言いがたい部分も結構あったりするのですが。)

後方互換性に気をつかいつつ、新しい仕様への対応も継続的に続けているプロダクトはそうそうなないんじゃないかなと思います。

Springは一部、拡張してSeasarやSlim3のように開発モードとしてhotRelaodingライクなことをできるようにしており、Spring MVCでもサクサク開発ができて便利です。(Spring3.1 -> 3.2 のServlet3.0対応周りでちょっとハマりましたが)
 
最近は、spring-loadedというプロジェクトというもの出てきてるようで、Grailsでフォーカスされているようですが、もしかしたら本家側でもhotReloadingのようなものも対応してくれたりするとうれしいですね。(有償?でJRebelというのもあるようですが、これもどんな感じか気になります)

  https://github.com/SpringSource/spring-loaded

ビューは、Spring MVCと組み合わせで、ThymeleafというHTMLベースのテンプレートエンジンと組み合わせて使っています。

  http://www.thymeleaf.org/

TeedaやFaceletesのような同じHTMLベースのビューフレームワークを探していたのですが、印象はよいです。
HTMLベースがよかったのは、お客様向けのモックを見せる段階で作成したHTMLをなるべく活かしたいなと思っていたのが大きな理由です。

TeedaはS2前提なのと、Faceletesは、内部的にはJSFだったので見送ったのですが、ThymeleafはSpringと組み合わせることも考慮されており、使いやすいと思っています。

Thymeleaf1.xのころから使い始めていたので、そのころはマイナーだったようですが、最近は日本のブログでもみかけたり、Springのカンファレンスでもセッションがあったようで、今後、広まってくれるとうれしいなぁという気持ちです。




その他、プロジェクト運営の観点からも、今年はわりと自分の中でもいいターニングポイントになったかと思います。

世の中は、キレイなアーキテクチャや運営などできているところもあると思いますが、
今年は多くのプロジェクトを見る機会があったせいか、まだまだ整備されていない形の開発や運営があるのを実感しました。

社内外をみていて強く感じたのは、プロジェクト初期の判断ミスによって運用、保守フェーズへのしわ寄せがいったり、残される人への負担を増やす対応とか、自分が最後まで面倒見ないからといって、後続に負債をもたせるようPM、PLとか、。。。ですねぇ。
(そしてその運用が当たり前と思うような保守も)

理想と現実と、組織の制約のバランスをとって現実解を探していくのもおもしろいかと思います。

アプリ単体ではなく、運用・保守までトータルしたクオリティを向上させ、疲弊しない開発やプロジェクト運営というレールをしけるようになっていきたいです。
今後はそこのニーズが合うかどうかもどう仕事して行くかの基準になるかと思います。

2012年4月9日月曜日

JavaOne Tokyo 2012 2日目

JavaOne Tokyo 2012 2日目の話。

2日目に参加したものは以下の通りです。


  • [JK2-01] Technology Keynote
  • [JS2-01] #jt12_s201 The Java EE 6 Programming Model Explained
  • [JS2-13] #jt12_s213 Java EE 6時代のJ2EEパターン再考
  • [JS2-21] #jt12_s221 How to Write Low Latency Java Applications
  • [JS2-31] #jt12_s231 ForgeとArquillianを利用したJava EEアプリケーションの迅速な開発
  • [JS2-41] #jt12_s241 Java Persistence API on the Grid
  • [JS2-51] #jt12_s251 The Future of JavaScript in the JDK
  • [JK2-01] Technology Keynote


[JK2-01] Technology Keynote


2日目のキーノートは、Coin, Lambda, Jigsaw, JDK7,8,9の方針、JavaFX, Java EE7(Cloud周り) 、いろんなデバイスにJava載るよ、 Java ME、M2M、という話の概要レベルがキレイにまとまっててキーノートとして非常にわかりやすかったです。

CoinやLambdaは、1日目のセッションで重複しているものが多かったので、さらっと聞けました。
Lambdaは1日目に見たものを早速書き方が異なっていて、どっちが最新だよ、というツッコミが。

キーノートでは、「Math#max」という表記で、1日目のセッションだと、「Math::max」のように「::」を用いて示しているところが微妙に違ってました。

JavaFXは、初日のStrategy Keynoteでキネクトっぽく、スピーカーの方の動きと、JavaFX上のDukeの動きがシンクロするという面白いデモ + GUIエディタを見せてもらってから急に興味がわいて来ました。
今回のJavaOneではJavaFXのセッションもかなり多かったので、Oracleとしても力は入ってるのでしょう。
どれか一つくらい、JavaFXのセッション聞いておけばよかったかなとちょっと後悔。

Java EE7では、再度、クラウドの話がありましたが、このあたりはやはりクラウドベンダーとの協調がどうなされていくかが重要かなと思っています。

組み込みJava関連はあまりお仕事では関わったこともなく、詳しい話はスルーしました。


[JS2-01] #jt12_s201 The Java EE 6 Programming Model Explained


Java EE6でのプログラミングモデルの話。
1日目のセッションのいくつかで聞いた情報が重複していました。
web-fragment.xmlはここでも出てきていたので、意外と有名なんだなと。

EE6は、なぜかweb.xmlが嫌いみたいでweb.xmlなしでも起動できるようにアノテーションやら、ServletContainerInitializerで初期化処理がコードベースでできるようになっています。

が、個人的にはweb.xmlはあってもいいんじゃないかなと思います。
定型的なものは、web-fragment.xmlで流用できるようにしておけばいいし、web.xmlがあるほうがエントリポイントが見つけやすくていいと思っています。

strutsや2.5系以前のspringのように、画面や機能が増えるごとにXMLも増えていくのはもちろん避けるべきだと思いますが、数が増えない(であろう)コアの部分やアプリケーション全体のコンフィグレーションを示す外部ファイルはあってもいいと思う。

CDI周りは、Qualifierアノテーションを使えば、独自のDIの目印用のアノテーションを作れるのは知りませんでした。
Qualifierの仕組みは、Springでも使えるようで、試してみたところ、Spring3.1でもQualifierアノテーションを活用したDIができるので、これは便利で早速取り入れています。


[JS2-13] #jt12_s213 Java EE 6時代のJ2EEパターン再考


ちょっと選択を失敗したセッション(笑)
いや、内容は悪くはなかったのですが、EJB2からやってきてる人向けのセッション内容でした。
EJB2は概要レベルは知っていますが、基本的にEJB3以降の世代なので、あまりバッドノウハウを知らない状態で聞いても、いまさら感が結構ありました。

EJB2はやっぱりいろいろ苦労されてるのですね。。。


[JS2-21] #jt12_s221 How to Write Low Latency Java Applications


JVMのメモリ管理の話。
最初は、基本的なメモリ管理の話かーと思って、油断してたら後半はちょっと難しかった。
このときは、結構疲労してたので話しとTLをウォッチ中心にしてしまいました。



[JS2-31] #jt12_s231 ForgeとArquillianを利用したJava EEアプリケーションの迅速な開発

レッドハットさんによる、CDI周りとForgeの話。
Arquillianという方の話は時間の関係か、結局詳細は聞けず。
(別のセッションで詳しくされてたみたい)

CDIでは、CDIのExtension部分の汎用的な部分を提供するDeltaSpikeというプロジェクトがあるようです。
JBossではなくて、Apacheとしてプロジェクトが立ち上がってるみたい。


Forgeは、Spring Rooのようなコマンドラインベースでコードを自動生成するツールです。
最初みたとき、めっちゃ似てると思いました(笑)

ただし、Forgeのほうは、Spring Rooとは違って純粋なjavaコードを出力していたように見えました。

Rooのようにajファイルを出力して黒魔術的にやるよりは明示的にjavaコードを出力してくれるほうがわかりやすい気もしなくもないですが、変更が入ったりラウンドトリップな感じで進めて生きたい場合はどうするんでしょうか?

Rooは、javaコード部分のほうは、変更されること前提で設計されているので、変更を検知してくれるけど、Forgeも変更に強かったりするのかな?であればかなり便利そうな印象。
出力されたものをスケルトンとして継承して利用するようにするのが基本なのかな。

また、Rooでscaffoldすると、View部分がJSPの独自タグ満載(tagx)で作られるので違和感があるのですが、Forgeのほうは、JavaEEということでJSF(facelets)で出力するようです。
こちらの方がすんなり入れそうという印象。





[JS2-41] #jt12_s241 Java Persistence API on the Grid


タイトルにはないけど、ほぼCoherenceの話。
JPAのキャッシュ機構は微妙だけど、それを補うのにCoherence使ってねみたいな印象を受けました。
(いいすぎ?)
TLみる限りでは、JPAのキャッシュはあまり使ってる人いないみたい。
memcachedと組み合わせたりするほうがいいですかね。


[JS2-51] #jt12_s251 The Future of JavaScript in the JDK


Node.jsでJavaのクラスが使える!
このセッションで一番盛り上がった瞬間。

Java6ではRhinoだったけど、Nashornという名前で後継プロジェクトができてるよう。
JavaとJavascript間をよりシームレスに利用できるようになるみたい、JavaBeansやCollectionのやりとりが簡単になったり、デバッグもできるようになる。

Nashornでは、Javascript上から、java, javaxパッケージのクラスが使えるようになる。

デモでは、Node.jsがNashorn上で再現され、さらにNode.js(Javascript)コードからJavaのSimpleDateFormatを使って日付をフォーマットしてコンソールやブラウザに出力するデモ。

前半は、まったりとした説明で会場の空気もまったりしていたのですが、Node.jsのデモから体感的に一気にまわりの食いつきが変わってた。

javaxパッケージが使えるということで、Node.jsからJDBCが使えることになればまた面白そう。

今のところ使う場所は想像できないけど、プロジェクト的にはかなり面白い取り組みだなと思います。


まとめ・感想


JavaOneは初参加でしたが、非常に有意義でした。

今後のJavaの進み方、現在の取り組みがかなり整理された状態で聞くことができたのが、やはり大きい。

どういった方向性に進んでいるかをちゃんと提示してもらえると開発者としてもどういう風に進んでいこうかということが考えていけるので非常によいと思います。
(方向性が合わない場合はJavaから離れてもよいわけですし)


Oracleさんの会場運営もよかったです。
全セッション(?)に通訳レシーバがちゃんとありましたし、たまたま前方の席のほうに座って気づいたのですが、手話用の通訳もあり、こういった細部にも配慮されているんだなぁと感心しました。

ただ、セッション間の移動は、会場が同じであっても総入れ替え制でそこの混雑が段取りがいまいちだったなぁと思います。
同じ会場でセッションが続く場合は、デブサミのように、会場前方で受け付けれるようにしてあれば、分散されてもう少し混雑が緩和されていたのではないかと思います。

とはいえ、非常に有意義な時間を過ごさせていただいたのは間違いありません。
スタッフの皆様、お疲れ様でした&ありがとうございました。

JavaOne Tokyo 2012 1日目

JavaOne Tokyo 2012に参加してきました。
7年ぶりとのことらしいですが、自分は7年前は社会人なりたてくらいだったので存在をあまり知りませんでした。

大きめのカンファレンスはいくつか参加したことありますが、ここまでJava + 技術ネタのセッションばかりのものは初めてで非常に楽しめました。

参加人数の1000人オーバーということで、普段回りに少ない(あれ?)Javaのエンジニアの方々がたくさんいたり、Twitterでつぶやいてると、同じ会場で聴講している方がコメントくれたりして楽しんで聞けました。

自分が1日目に参加したものは以下の通りです。

  • [JS1-02] #jt12_s102 Java EE Web Container in the Cloud -What's New in Servlet 3.1
  • [JS1-11] #jt12_s111 The Heads and Tails of Project Coin
  • [JS1-21] #jt12_s121 Pragmatic Cloud and PaaS with Java EE 7 (and GlassFish)
  • [JS1-31] #jt12_s131 Project Lambda: To Multicore and Beyond
  • [JS1-42] #jt12_s142 JAX-RS 2.0: What's in JSR 339?
  • [JS1-51] #jt12_s151 HotRockit: What to Expect from Oracle's Converged JVM

[JS1-02] #jt12_s102 Java EE Web Container in the Cloud -What's New in Servlet 3.1


Servlet3.1まわりの話。
一通り知ってるつもりでしたが、web-fragment.xmlは知りませんでした。
web-fragment.xmlを使えば、web.xmlの一部を定義しておいて、jarに同梱できるようです。
フレームワークなどを作っている場合は、servletやfilterが必要になることが多いので、フレームワークで利用するfilterを定義しておいて、jarに同梱しておけばすぐに使えるという感じ、これは便利そう。

後で調べてみたところ、複数のweb-fragment.xmlがあり、かつfilterが適用される順番などを気にする必要がある場合は、web.xmlに、<absolute-ordering>タグを記載すれば明示的に順番を指定できるよう。


少しだけ、WebSocket対応というキーワードがありましたが、詳細なし。


Java EE7の話。
EE7ではクラウド対応というキーワードしか知らなかったのですが、かなりいろいろなものが入りそう。
アプリケーションレイヤーとしては、multi-tenancy対応が気になりました。
アプリケーションで複数の顧客をサポートするような場合の対応です。(Salesforceのように)

JPAレベルでもいろいろサポートするようで、@Multitenantのようなアノテーションでマルチテナントを明示化したりするようです。

テナントIDといった顧客を識別するIDをwhereに自動的に組み込み、データをうまいこと扱うような感じです。

テナントIDの引き渡し方といったことなどはまだまだ仕様策定中らしく詳細はまだ不明。

とはいえ、最近は案件としても、リソースの有効活用という観点からもマルチテナントなアプリケーションを求めれられることがあるので、こういった機能があると確かに便利だなと思います。

また、バーチャルサーバというテナントごとに独立したイメージのサーバを立てることができるようになるみたいでこちらもおもしろそう。


[JS1-11] #jt12_s111 The Heads and Tails of Project Coin


Coinの話。
CoinはJava7から入っている小さい変更です。
小さいといっても、Javaの世界において影響度は小さくなく、そういった変更に対する影響の話やコンパイラでどう解釈されるかなどの話があって、Coinの仕様自体の話よりもそちらの話がおもしろかった。

Coinは6つのフィーチャーだけど、その小さなことが他の機能に影響しており、全体の1/3程度に影響がしているらしく、樹形図のようなものを見せてもらいました。それらに対してどう影響を考慮していくかといった、開発プロセスの考え方の話がおもしろい、これはスライドあげてほしいなぁ。

Coin自体については一度サンプルコードを書いてみたことがあったのでおおむね知ってる話でした。

ちなみにサンプルコードはgithub上に上げています。



[JS1-21] #jt12_s121 Pragmatic Cloud and PaaS with Java EE 7 (and GlassFish)


1つめのセッションに続いて、Cloud関連の話。
このセッションでは特にPaaS関連が中心でした。

PaaSではMulti-Services, Elasticity, Isolationを意識する必要があるよう。

Multi-Serviceは、
Elasticityは、リソースの増減を柔軟にすること、
Isolationは、独立性を確保すること、マルチテナントになった場合でも他のテナント(顧客)のものは見えないようにしないといけない。

IMS(IaaS Management Service)と呼ばれるアーキテクチャで、PaaSのリソースの上げ下げをコマンドラインインタフェースやAPIでできるようにするという感じのスライドがあったけど、あまりよくわからなかったです。

IMSは、ユーザには、あくまでレイヤーしか見せないようにラップして、実際のサーバをelasticに増減するのはPluginで頑張る感じなのかなという印象を受けましたが、理解があってるかはいまいち不明。

AWS Pluginとか、Azure PluginとかIaaSにサービスに応じたPluginが出てきたりするのでしょうか。

なんにせよ、クラウドのポータビリティを意識しているんだなところはいい印象です。
ただ、SpringSourceのクラウド間のポータビリティへの取り組みである、Cloud Foundryとかも少なくとも日本ではあまり聞かないのでここらへん、うまく仕組みを作っただけでは普及しないのではないかと思っています。

たぶん、クラウドベンダーと如何に連携ととって推し進めれれるかがキーポイントとなりそう。


デモでは、Glassfish4によるelasticなサーバの上げ下げのデモがありました。
サーバにメモリ負荷をかけると自動的に別のサーバが起動してAutoScaleするデモでした。

AutoScaleするトリガーはいくつか選べるようで、今回はメモリが一定値以上なら自動的にスケールする設定のよう。

デモでは、全部同じマシン上で別ポートとしてサーバをあげていましたが、実際には別の仮想サーバであげたりすると思うので、そのあたりの連携とかどうなんだろう。

ノードマネージャ的な機能が入るんでしょうけど、どうAWSとかと連携していくのかまだイメージがわかない。


[JS1-31] #jt12_s131 Project Lambda: To Multicore and Beyond


Lambdaの話。
セッション名を読み上げる司会の方がランバダとかいってちょっと吹いた。(まぁそう読めちゃうやんね。。)

Lambdaは、構文がかなり大幅に書き換わるからか、まだまだ変わる可能性があることが強調されていました。

例えばソートするときには、以下のようにかけるみたい。
「people.sort(comparing(Person::getLastName));」
今までだと、無名クラスでComparatorを自前で書いてたりしたけど、かなりすっきりする印象。

セッション後の周りで、「これウチの人間はたぶん使えない」とかいう声も聞こえてきましたが、個人的にはすっきりするのでうれしい。

新しくJavaやる人にとっても最初からこういう構文だということで入ってくればよりすっきりわかりやすいのではないかなと。

これは早く欲しいフィーチャーです。


Interfaceのdefault methodの話。

インターフェースに直接、デフォルトの実装を定義できるようになるらしい。
スライドの例では、デフォルトでUnsupportedOperationExceptionをスローするとか。

2つのインタフェースに同名のデフォルトメソッドが実装されていたりしても、どちらを利用するか明示できるみたい。
implements Hoge, Fooとして、両方ともに、getValue()みたいなデフォルトメソッドがあってどちらを使うかというようなときなど。

この機能はインタフェースデザインをうまくできないとハマる原因となりそうなので、ちょっと注意したいところ。


[JS1-42] #jt12_s142 JAX-RS 2.0: What's in JSR 339?


JAX-RS2.0の話。
JAX-RSは全然使ったことないけど、アノテーションスタイルでかなりすっきりかけるようで好印象。

が、Spring MVC使ってるとちょっとしたJSONやXMLは普通に@ResponseBodyで返せるので、Spring使ってるとあまり出番はないかなと思った。

ただし、JAX-RS2.0ではいろいろ機能を拡充していくみたいで、Bean Validation対応や、独自Interceptor、PreMatchRequestFilter、RequestFilter、ResponseFilterといった拡張ポイントがいろいろ用意されているようなので、このあたりの仕様をもうちょっとウォッチしてみたいところ。

なんかSpring使ってると、だいたいそれあるよ的な感じになってしまうのですが、RESTスタイルのJava標準としてキレイに整備されていくと、Spring側にもフィードバックされそうでいいなぁという感じです。


[JS1-51] #jt12_s151 HotRockit: What to Expect from Oracle's Converged JVM


JVMの話。
会場アンケートで、どのJVM使ってる?という質問で

IBM J9 ->1人
JRocket->そこそこ
HotSpot->多い

という結果に。
自分もIBM Java6は使ったことがあるのですが、J9=Java7のことかと思って手をあげませんでした。(ゴメンなさい、唯一あげた一人の方。。。)

セッションの中心は、JRockit Flight Recorder(今後は、Java Flight Recorderに名前が変わるみたい)でした。
ボトルネックや、メモリリークの検知デモがあったりいくつかのデモがあって非常にわかりやすかったです。

WebLogicな案件でもあまり使ったことなかったけど、かなり興味わきました。
あまりクリティカルなメモリリークにぶち当たったことがないので使いこなせていませんが、WebLogic案件で試してみよう。


スペシャルセッション

LTラッシュ。
Dukeの顔を模したおにぎり弁当+飲み物(ビール、ノンアルコール)が配布されてうきうき。

大体爆笑していたので、全然メモってません(笑
ドラ娘さんのやりとりや、ろくろやバルスなど楽しませていただきました。


という感じで1日目終わりです。

2012年3月20日火曜日

STS(eclipse)でSeversからサーバ起動時、maven管理のjarファイルをクラスパスに通す方法

今まではMaven2 Additionalプラグインを使って、WEB-INF/lib以下にjarをコピーしていたのですが、自身で開発をしているjarでsnapshot版に変更が頻繁にあると、コピーが少し手間に思っていました。


ということで少し、eclipseの設定を見てみたところ、プロジェクト直下の.classpathファイルにある、mavenのclasspathentryを直接編集すればうまく動きそうです。
mavenのclasspathentryに対して、org.eclipse.jst.component.dependencyに関連づけることにより、サーバ起動時にクラスパスが自動的に通っているよう。

 
  
   
  
 

これで、mavenでjarなどを変更しても、いちいちWEB-INF/lib以下にコピーしなくてもよくなった。

2012年3月4日日曜日

JAWS Summit 2日目

JAWS Summit 2日目に行ってきました。(1日目は参加せず)


<資料>
サイト
まとめリンク
発表資料(slideshare)

・サイト
JAWS Summit 2012

・facebook
JAWS Summit 2012ファンページ
クラウドデザインパターン (cdp)

・slideshare
クラウドデザインパターン デザインパターン概要編
クラウドデザインパターン コンテンツ配信編(Movable Type on AWS)
クラウドデザインパターン Eコマース編(EC-CUBE on AWS)
クラウドデザインパターン キャンペーンサイト編(WordPress on AWS)

# ベストプラクティス Force.comとAWS連携は、3/4時点では公開されておらず

・Toggetter
2012/03/03 JAWS Summit 2012 PROGRAM Day2 クラウドデザインパターン


<感想>
それぞれのセッションの内容は、詳しく記載されているのでそちらを参照。(最近はホント、資料もアップされる勉強会が多くて親切ですね、感謝。)

注)以下でのクラウドは、基本的にPaaS、IaaSを想定しています。

AWSも認知度が上がってきてるかと思えば、まだまだそうではないみたい。
知ってる人は増えてきてるけど、使いこなしてる人はまだまだ少ない。

AWSクラウドをより伝わりやすくしたい。
ということで考え出されたのが、クラウドデザインパターン(CDP)。
クラウドをつかうときの典型的な問題の解決するパターンとのこと。

デブサミでもチラッと聞いたけど、物事を認知させるのには、名前が重要。
アジャイルのように名前と意味が別解釈されたり一人歩きする危険性はあるものの、名前がないと認知しようがない、確かにそうだ。

facebookのクラウドデザインパターンのファンページをいいねすれば、CDPのパターンを記載したwikiが見れる。
(が、一説によるとgoogle検索してもクロールされてるかも、facebookのアカウントを持ってない人はググればでてくるかも)

最近は、こういう勉強会などのfacebookのファンページも多くなってきてるのかな。

CDPは、3/3時点で45パターンあるらしくて、もうすこしで48とか。
ちらっと見てみると、図でイメージがちゃんと示されてるのが多くて、パターン適用時の注意点も書いたりしているものもあって、育っていくとすごく便利だと感じた。
(AWS忍者や、JAWSUGの方々が書いてると思うので、実体験によるものも多く載ってると思います。)


ただし、パターンだけあっても、じゃあそれを自分たちのシステムを作る際にどう適用さればいいの?ということになるが、それをシナリオとして一緒に伝えていくためのものが、今回のセッションの中心だった。
コンテンツ配信、Eコマース、キャンペーンサイトなど。
こういったシステムでどういうスモールスタートをして、どうスケールしていくかが順々に説明されてわかりやすい。


世界を見ると、世界ではクラウドを使いこなしている企業が多く成功している。
日本ではまだまだ弱いという印象(らしい)。
AWSとしてはクラウドを使いこなせるデベロッパーを増やしたい、とのこと。


デザインパターンのプレゼンを見ていて、やっぱりクローズドな環境と、パブリッククラウドはスケールのしやすさが桁違いだなぁと。
QAでもあったけど、スモールスタートから、順々に規模を大きくしていくこともできるし、逆に規模を縮小していくこともできる。
ホント、柔軟(elastic)だなぁと。

コストとしても、個人的にはどんどん(AWSだけでなく)パブリッククラウド自体が流行って、クローズドな環境とのコスト差をどんどん広げていってほしいと思う。

今でも相当あると思うけど、より差がついていくことによって、クローズドオンリーな環境でも検討の機会が出てくると思うので。

もちろん、セキュリティリスクや、既存運用の取り回しなどいろいろな乗り越えるべきハードルがあると思うけど、トップダウンで判断されやすいコストで大きく水を空けられると検討せざるを得なくなる。
(まぁ、世の中にはどうしても外に繋げないシステムもあると思うけど、それはそれで寡占ビジネスなんだろうなぁ)

官公庁や金融機関などの事例はまだ少ないという認識だけど、時間の問題で先に着手できたところがアドバンテージを得れるんじゃないかなと思う。
官公庁や金融機関を扱ってるSIerもアドバンテージを得るためにも提案してほしいなぁ。(SIerとしての旨みは少ないのかもしれないが)

たぶん、いずれはクラウドが来るな、しなきゃなと思っているところはいかに早く手を出していけるかが大事。
クラウドの流れはもう規定路線になってる。
AWSでないにしろ、検討をしてノウハウを溜めていかないとどんどんコスト差がついていく。

後はベンダー(クラウド)ロックインを避けるためにももう少し、クラウドポータビリティが充実してくるといいなぁ。
SQLみたいな共通言語としてAPIが共通化されればいいのに。
(SpringSourceがクラウドポータビリティを目指していたと思うけど、どうなったんでしょう。。)
仮想サーバなどのインフラはある程度共通化できたとしても、運用ノウハウはクラウド固有だから難しいかな。

個人ユースでは去年はEC2、RDS、S3などを利用していたけど、APIももう少し深堀して行きたい。
全部のサービスを使うには手広くなりすぎてると思うので、自分に必要なサービスから入っていて、必要になったら徐々に見ていく感じがいいと思う。

2012年2月19日日曜日

デブサミ 2012 2日目

デブサミ 2012 2日目に行ってきました。

1日目に続き、自分用のメモとして。

<自分が聞いたセッション>
・若手~中堅まで幅広く
 ・【17-B-5】アジャイルマニフェスト ディケイド

・チームリーダ以上向け
 ・【17-C-2】仕事のバトン、渡っていますか? - プロジェクト管理におけるコミュニケーション基盤作り
 ・【17-A-4】Scrumで組織改革

・その他
 ・【17-B-7】ソーシャルコーディングの世界
 ・【17-B-6】Building scalable web apps
 ・【17-A-3】スマートフォンにおけるHTML5実装の最先端


<セッションについて>
2日目は、GREEさんではなく、DeNAさんが多かった。
そのほかは、1日目よりは雑多(ノンジャンル)な感じが多かった気がする。


<感想>
・【17-C-2】仕事のバトン、渡っていますか? - プロジェクト管理におけるコミュニケーション基盤作り
少し遅刻して聴講。
プロジェクト管理というより、JIRAの話と絡めて、課題管理ツールの話だった気がする。
 
顧客と一緒にJIRAなどのツールを使えるのはいいなぁ。
もちろん顧客からの要望とかQAとかは社内でも管理しているところが多いと思うけど、消しこみとか管理とか正直二度手間なときもあるし。
プロジェクトを開始するときにそういう風土をもてるならより顧客と一体になってできそう。

セッションの中で、時間管理重要というのがあった。
課題管理ツールで、時間管理をするというのではなくて、別のツール(WBSやExcel)などで時間管理をして、その枠内(タイムボックス)で課題管理ツールを使うことのがよいらしい。
このあたりはその通りだと思う。

僕はTracを良く使うんだけれども、基本的にはWBSとは関連させてない。
スケジュール管理はMS-ProjectとかExcelで割り切って使っている。というか1:1になることが少ない、粒度が合わない。
スケジュール管理というか、バグや修正など、決まった1つの事象についてのトラッキングにやっぱり向いてるんだと思う。
リリースのときのタギングとか関連付けにも使えるので、課題管理ツールはやっぱりそういうものに使うのがいい。


起票ルールについて、「気遣い(言葉遣いを丁寧に)」が重要というのはすごくすっと入った。
バグにぶちあたってイライラすることもあるときに、(個人を)非難するような書き方になったり、気分を害す書き方になっていることもあって、
そういうときは(仕事とはいえ)コミュニケーションがうまくいかず、非協力的な態度をとったり、とられたりするということもあったなぁと。
そういうのに時間をとられるのはやっぱりもったいない。


浸透をいかにさせるか、というのはすごく共感できて、Tracを使うようにしたときも最初はなかなか使ってくれなかった。
使い方に手間取ったりすると嫌がられる。
なので、一緒に操作したり説明したり、という地味な対応が待っている。

導入する自分と、導入しなければいけないその人にとって、メリットや知識や思いに乖離があって、そうなる。
課題管理ツールって、ともすれば別の運用で何とかなる場合というものも多いので、そうなる。
そこで以下に一緒に動いて障壁を取り除けるかってのは大事。

昨日のデブサミの自分戦略の部分で、アウトプットを広げるというフレーズがあったけど、
自分のいいと思っているものを相手に浸透させていくというのもアウトプットを広げるという一つなのかも。
浸透させられないというのは、そこへの取り組みが足りてないってことか。


・【17-B-5】アジャイルマニフェスト ディケイド
角谷さんのプレゼンは初めて拝聴させてもらったけど、なにこれおもしろい。
ご自身でも言ってるとおり直接は役に立たないんだろうけど、一緒に考えさせられる講演だった。

アジャイル(本来は形容詞)やパターンなどの呼び方が先行していて、手法や名前に囚われてはいけないとのこと。
プランニングポーカーやってる、朝会やってる=アジャイルではない。

広めたりするときは名前がついてるほうがいいけど、それが実際に自分たちの状況において適用するときにあうかどうかはわからない。

クラウドとか、ビッグデータとかアジャイルとか、確かに世の中に認知させるためには名前が必要だけど、それが自分のコンテキストの中で有効かどうかは自分自身にしかわからない。
あるところでは有効であった手法でも自分にとっては、前提や制約条件が違ってそのままハマるわけではない。

世の中の色々なプロジェクトから類似の問題は抽出できて、パターン化することはできる。
自分が解決したいものがそのパターンに当てはまったとしても、同じ手法が通じるとは限らない。

たぶん、自分(たち)自身の問題として真剣に解決するためにどうすればいいか、価値を提供できるにはどうすればいいか、というのを考え続けていかなければいけないんだと思う。


プレゼン資料みただけではわけわからないので、話と一緒になって聞くというライブ感は大事だなぁ。
頭の中で組み立てられているストーリーとスライドが一体になって展開されたときの爆発感は見ててわくわくする。

あと、講演終わってから、たまたま生matzを近くで見かけて、こっそり、おー!ってなってた。(笑)


・【17-B-6】Building scalable web apps
herokuの中の人が来日してのお話。

全編英語でお送りされました。
(自分のリスニング力の低さに)泣きそう。

スライドにちらっとある図と部分部分で聞き取れる単語でフル推測の時間。

herokuが、自分たちのアプリ開発以外の部分(インフラ、デプロイなど)を全部面倒見てくれるってのだけなんとなくわかった。
デモは、gitでherokuのリポジトリにpushするだけでheroku上でアプリが動くデモだった。
gitのpush時にhookして、ごにょごにょしてる感じ。

configがAPIでできるようなことがちらっと聞こえた気がするけど、AWSみたいな感じなのかな。

正直、herokuうんぬんよりも自分のリスニング力の低さに絶望した。
世界に通じるエンジニアになるためにも英語は避けれないなと実感。


・【17-B-7】ソーシャルコーディングの世界
まとまりのないようなスライドだったけど、それでもどこかまとまってるような良くわからない感じ。
でも、githubでのソーシャルコーディングの楽しさやすごさはすごく伝わってきて楽しく聞けた。

ソーシャルコーディングを活用できるとすごく世界が広がるんだろうなぁ。
でもコードを書くのもソーシャルだと、コミュニケーション力が低い人がますます淘汰されるのか。

企業が求めるコミュニケーション力というものとは別だと思うけど、仕事をするのにコミュニケーション力ってのはやっぱり必要なんだなと実感。


2日間参加して、自分の進んできた道や足りないところなどを見つめなおす機会になりました。
こういったところで刺激をもらったり考えたりするのってやっぱ大事。

デブサミ10周年おめでとうございます、そしてありがとうございました。

2012年2月17日金曜日

デブサミ 2012 1日目

デブサミ 2012 1日目に行ってきました。

内容というよりは、考えを自分用のメモとしてとくにまとまりもなく書き出した。
書き出すことによって聞いていただけでは出なかった考え方ができるかもしれない。

大まかな内容・流れはまとめリンクからtogetterを見ればいいし、資料も大半が公開されると思う。
(有志のみなさんの素早い配慮がすばらしいです、感謝)


結論は、やっぱり行ってよかった。

<ref>
サイト
まとめリンク
発表資料(slideshare)
# まだ当日なのであがってないけど、そのうちちらほらアップされると思われる。

<自分が聞いたセッション>
以下のような人がみるといいじゃないかなと思う。

・若手~中堅まで幅広く
 ・【16-A-7】あの人の自分戦略を聞きたい!

・チームリーダ以上向け
 ・【16-B-1】極上のSI戦略
 ・【16-B-3】教科書と現場のあいだ

・インフラ向け
 ・【16-A-2】大ヒットソーシャルアプリ「ドラゴンコレクション」の裏側

・UX(ユーザーエクスペリエンス)
 ・【16-A-4】Effective Smartphone UX at GREE
 ・【16-E-5】デザインの最前線
 ・【16-A-6】いまどきのi18nのはなし
 # i18nはここに入れていいか微妙だけど

<セッションについて>
セッション全体的な印象としては、(スポンサーの関係もあるが)GREEさんが多い。
=いわゆるソーシャル系・スマートフォン開発物が多い。

クラウドは(エンジニアとしてはとっくに当たり前になっているので)バズワードを抜けたのか、クラウドクラウドしてるものは少ない。
後はWeb寄り(HTML5やJavascript)、スピーカーの経験談や考え方などのセッションなどなど。


<感想>
・全体
今回の僕の方針としては、あまり(エントリーレベルものの)技術紹介的なものは避けて聞くようにした。
スピーカーの考え方や、いままでやってきたことなどを聞いて、自分のなかでも考えたかった。
他人と同じ仕事のスタイルをするという意味ではないけど、登壇されるほどの方々の話は拝聴させていただくとやっぱり参考になる部分が多々あったり、この視点は足りなかったと思ったり、自分も同じ考えで方向性などの再確認ができたりするので刺激になる。

・SI寄りの話
・【16-B-1】極上のSI戦略
SI寄りの話が2セッション(これと16-B-3)ほどあったけど、どちらもSIerはおもしろい、やりがいがあるという感覚のよう。

自分の思いとしては、ここ数年は、SIer->Web系への転職がさかんだったり、SIerが落ち目(斜陽産業)とdisられることはあるけど、Web系とSIerは使ってる技術・ソフトウェアなどは似てる部分は多々あるものの、もともとの目指してるものが違うのだから別にdisらなくてもなぁという感覚。

Web系の方々の運用ノウハウとかみてるとやっぱすごいので、素直に知識を吸収すればいいと思ってる。敵じゃない。
技術的には確かにWeb系の方が面白い(試せる可能性としては高そう)という印象。

一口にSIといってもいろいろあるので全体論をしても建設的な結論がでないのでもったいない。
自分の取り巻く範囲でどう活用できるかを考えていきたい。

今までのような受託が少なくなるというのも同意だけれども、業務系でも今までクローズドな部分だったのが、インターネット寄りのサービスと組み合わせたりまだまだアイデアはあるんだと思う。(16-A-7でも少し話が出ていた)
ホントにパッケージソフトウェアだけで済んじゃうところもあるし、もっともっと泥臭いところもある。
そういったところがパッケージソフトだけで済むとは到底思えないし、そこをSIというか一緒にデザインしていくのはきっと楽しい。


自分が技術やコンシューマーユーザと接していきたいか、SIerとして社会や企業に接して行きたいかというので決めればいいのかなと思う。
(給料的なものは別として)


大手になればなるほど、(本来やる必要のない)根回しがいたり、様々なしがらみがあったりしてそれはそれで面倒だけれども、企業のお客さんと直接やりとりして業務をデザインできるポジションというのはなかなかない。
そこそこ大きな企業にしてそういうところにタッチできるチャンスがある人は当たりを引いてると思う。なかなかまわってくるわけじゃない。


SI寄りのセッションでもたぶん元請を念頭に置いた話をしていると思われるので、元請でない場合はやらないほうがいいと思う。元請でないとSIのやりがいがある部分などは少ない。

SIという単語ではあるけど話をしているのは人月で大量に作業している1要員の話でなくでもっと案件全体を担当してるような人の話だと思う。
なのでエクセルと向き合うのが仕事です、みたいな立場の人ではピンと来ない部分もあったりするのかなと。(なので少数精鋭がいいんだろうけども)

話を聞いてみると、なんでもできるスーパーマンみたいな人材ばっかりな印象があるけど実際はどうなんだろう。
全部内製というわけでもなく、パートナーの話とかもでてきてるから、コアの作業以外は外に出してるんだろうと思う。

技術も顧客折衝も営業もできたらそれは確かに年収1000万オーバしてもおかしくはない。
2~3分野に得意な人をうまくオーバーラップ、クロスするように組み合わせてチームにしてやっているんなら納得。


生産性のところでLOCが出てきたのはどうしようかと思った。(自動生成系なら必然的に増えそうだからなんともいえない)


全体としてSIの中で目指しているものは自分と似ている部分が結構あるなと思った。(似ているというのもおこがましいが)
講演なので、うまくくるんでる部分もあるんだろうけど、実際の話をもう少し聞いてみたい。


・【16-B-3】教科書と現場のあいだ
こういったところで講演される方でも、仕事のほうはトラディショナル(昔ながらの開発)な割合が多いみたい。
トランザクションスクリプト(手続き的)、オフショア活用など。

スクラムやDDDとかはプライベートのほうで学ぶことが多いらしい。

アジャイルをやんわりとdisってた印象。
たしかに、プランニングポーカーとかいろんな道具を使ってレクリエーションっぽいやり方でチームと話そうと思っても、
(自分もでやる場合もそうかもしれないが)勉強会とかにくるような意欲のない人たちに受け入れられるのは難しい。

自分でも社内向けに勉強会のメモや内容を展開してもリプライはなかなかないという経験は結構ある。
ただ他のセッションとかの話をいろいろ聞いていると、それはリーチしている人が少ない(アウトプットを広める努力を僕がしていない)という問題もありそう。


少し印象的な話としては、スクラムマスターの研修かなにかで、
朝会をしているが、深刻な問題として、各自が自分のタスクをやっているだけなので作業状況を共有する意味がない、という意見が。

これは自分も少し思い当たることがある。(というかチームには属してるんだけれども、いろんなところに借り出される珍しいポジションなので)

本来はその状態はよくないので作業をひとつのキューににれてチームで取り組む。というのがスクラムの考え方の一つとしてあるみたい。
これを聞いて素直にいいなぁと思ってスクラムをちょっと勉強したくなった。
そのメンバーが業務上、私事上でなにがあるかわからないのでリスクをヘッジすると言う意味でも。


原則(プリンシプル)、実践(プラクティス)という言葉があったけど、スクラムの重要な考え方っぽい。
アジャイルとかなんやらとかいろいろ手法や方法論があるけども、型通りにやる背後には、原則(プリンシプル)がある。それを理解して実践(プラクティス)することに意味がある。

原則をを理解すれば実践に幅がうまれる。そうすればコンテキストに載せられる。
コンテキストにのせれば組織の中で会話するための言葉が手に入る。

たぶんリーダとかマネジメントをしないといけない人は、いかに組織・チームが共有できるコンテキストを正しく構築できるかが鍵になるんだろうと思う。
共有できれば余計なバッファも減るし、誤った方向に進まないようにもできる。

講演自体はすごく面白く聞けたけど、ちょっと横文字が多すぎるので、スクラムとかアジャイルとかの本を読み漁ってない自分のような人にはコンテキストを間違って捉えられてしまうかなと思ったり。
(でもスクラムはホントに知りたいなと思った)


・UX・デザインの話
・【16-A-4】Effective Smartphone UX at GREE
・【16-E-5】デザインの最前線
どちらもデザインを作り上げていく際の考え方として考えさせながら聞けた。

GREEさんの方では、スマートフォンについての話だったけど、スワイプの指の使い方一つ一つにもちゃんと考えてたり、
ユーザが何か操作したときいかにアプリがストレスを感じさせることなく動くかというところが考えられている。

また、スマートフォンの利用シーンをきちんと考えていて、例えば歩きながらだと誤操作したりすることも考えてたり、
ユーザが(アプリとして)こういう挙動をしてほしいというものを今はまだできてない部分も多々ある上でちゃんと研究されているようでさすがだなと。


デザインの最前線では、ソフトウェアだけなくハードウェアも深く関わる分野でも関わったりすることがあるそう。
プロトタイプの話が出てきていて、抽象的なものから具体的におとしていくのは今の複雑さものごとには難しいのではないか。といような表現にはすっと頭の中に入った。

頭の中の創造や、ラフスケッチでの話を進めることもできるけど、みんながみんな想像力たくましいわけではない。
百聞は一見に如かずということわざがあるように、プロトタイプのような具体化にして、抽象と具体を時には行ったりきたりしてよりよいものができていくんだろうなと。

またプロトタイプを作るだけではダメで、ユーザにそれをどうやって理解してもらうかのストーリーを作るのも重要。
ただモノをつくるだけではなく、アウトプットをいかに相手に伝えられるかというのは大事。


・【16-A-7】あの人の自分戦略を聞きたい!
いろんな人が自分語りをするというとても楽しく聞けたセッション。
それ話していいの?みたいなネタもあったりする。

登壇された方々には及ばない部分も多々あるとは思うけど、活躍されている方々と考え方が似ている部分が多かったりすると自信にもなる。

全員が立場もやってることも大きく違うので、自分自身に置き換えたときにそのままマッチするかといえばそうではないけども、端々で考えさせられながら聞けた。

また、それぞれ別の人が話してるのに登壇者全員に以下のような共通したものが根底にあるような気がした。

 ・セルフブランディング(自分が得意な部分を以下に価値として相手に伝えるか)
 ・楽しむ
 ・学び続ける姿勢
 ・アウトプットをする+アウトプットを広げる
 ・自重しない
 ・自分からアクションする

もちろん細部はみんな違うんだろうけど、ベースの姿勢は共通してるんだと思った。


考え方が近いなと感じたのは、ソニックガーデンの倉貫さんで、会社にも提案していくっていうのは似ているなと思った。
自分は会社の中での立ち位置は結構レアな感じでいろんなことにタッチできる機会が増えてきている。

でもそれは待ってたわけじゃなくて、アピール(了承が得れるように説得したり、結果もそれなりに残せたり)し続けているから、そういった機会が増えている。
たぶん遠回りもたくさんしているんだろうけど、そういった周りがやってないことについては不足してる部分もありながらでもチャレンジできてるんだと思う。


明日も楽しみです。