Seasar Conference 2015に行ってきました。

Seasar Conference 2015に行ってきました。


Seasar Conference 2015 公式サイト
compass

自分が聞いたセッション

• 【S405】基調講演（当日急遽テーマ変更）
• 【S401】SIの終焉3
• 【S405】俺は守りに入らない、これが今の俺だ（当日急遽時間変更）
• 【S405】Seasarからクラウドへ、振り返って知る技術的に重要だった観点のある個人的観測について
• 【S405】SmartNewsとBacklogの作り方
• 【S405】SIは本当に終わったのか?

なお、今回は、聞いたセッションの資料は公開されてないよう。
（半分はパネルディスカッション形式だったから。他の方のは公開されているセッションもある。）

全体の話

ひがさんのセッションで、いきなりのテーマ変更としてSeasar2関連の裏話へ。

Seasar2は、1年後（2016/09/26）へサポート打ち切りへ。
運営側や、他の発表者も知らない感じが見受けられ、本当にサプライズだったのかも。

実際のメンテナやMLでのサポートでずっと貢献されていた、小林さんへの感謝の拍手があったのが感慨深い。

今後については、ひがさんのブログで発表されている通りですが、

• GitHub自体は残すのか（ソースは公開されたままなのか）
• mavenリポジトリはどうなるのか？（mavenのセントラルリポジトリにはない）
• 公式サイト自体（レファレンスは日本語が多いので伝えやすい）

といったあたりが気になるところです。

Seasar2から卒業しよう
続Seasar2から卒業しよう

また、セッションまたいだ印象としては、今回は選んだセッションの都合なのかそうでないのか、Seasar Conferenceと銘打っているのに、Seasar2のコードは一つもみなかった。（その他関係がないプログラムコードは、1セッションでしか結局見なかった）

発表者の現在の仕事の立ち位置、ロールなどもあるのでしょうが、
個々のプログラムやFWを紹介というよりも、プロダクトやビジネスをどう推進していくかのような立ち位置、内容の印象を多く受けました。

個々のセッションの話

【S405】基調講演（当日急遽テーマ変更）

事前公開とはテーマが変わって、ひがさんのSeasar2裏話

Not 同窓会 But 卒業式。

• Seasar2は、1年後（2016/09/26）へサポート打ち切りへ
• Seasar2をずっとやってると新しい技術（分野？）を追えない
• 環境に慣れた、満足感が出てきたら次のフェーズに向かったほうがいい

ひがさんの仕事の関連もあるので、一部オフレコの話もあったり、裏話は聞けてよかった。

他、公開可能なものは、ほぼブログで話されているようなので、割愛。

聞いてて考えたことは、Seasar2しかり、某FWなり、10年以上企業（がバックにあるプロダクト）がちゃんとサポートしてくれるFWってのはないと思っていかないとなと感じた。
ただ、もう機能追加がないので、自分なり、自社のメンバーがある程度ソースを理解して、拡張できるレベルのメンバーがいれば自分たちのプロダクトの開発においては問題ないかなと思います。
セキュリティ面で何か合った場合は、自分たちでパッチをあてるなどはしていかなければなりませんが。

そういった意味では、Springは今でも活発に開発が続けられているので、すばらしいなと思います。

【S401】SIの終焉3

栗原さんの仕事の軌跡を振り返りつつ、SIの話。

後でSIの終焉、SIの終焉2の記事を見ると、おおむね一緒のことを話されていたのかなと思います。

後半、時間切れで本題にあまり入れなかったようで、もうちょっと聞きたかったな思いました。
最近、プラットフォームを押さえにいくのがトレンドなのか、Uber、Airbnbといったものだけでなく、アメリカで過ごした身近なところでのインフラの寡占化の例を照会してもらったのは興味深かったです。

SIの終焉
SIの終焉2

SIの終焉という記事を記載したとき

• Google Appsをセールスしていたのでクラウド推しの背景もあった
• （クラウド推しについては）今振り返ってみても、時代が進んでもあまり変わっていない
• 当時は、金融の案件がストップ、違約金もらってまで止まったケースがある -> SIをやってると翌月からいきなり仕事があるわけではない
• 変遷
• 2010 -> フルスクラッチ
• 2011 - 2013 -> SIレス（パッケージ）
• 2014 - マネージドサービスにアウトソーシング（Google Apps etc）
• SIは、SES、SaaSにわかれて移行してきている

SIの終焉2のとき

• 1をふりかえって、予想はあたったけど、うまくできなかったことがある
• Google Apps -> 低収益性でもうからない
• ドルで仕入れて、円で売る。為替、当時80円、今は120円でお客さんのコストもアップしてしまう
• クラウドリセールするのは軒のみあまりいいことはない。ちまいSIしかなかった（ライセンスをうるためのオプションのようなもの）
• 人のものを売っていてももうからない -> 自分たちのものを作ったほうがいい
• Google Appsのまわりのアドオンのようなものを売っていた
• SIは期間がぶれる可能性がある
• サービスだと、前払い（年額）なので収益予測がしやすい、雇用に対する計画がしやすい
• SoftBank、Googleと組んでiPhone + Google Appsで寡占的な法人市場を形成できてたが、具体的にアプリが何もなかった
• アプリを作る話を提案したら、Glabioという会社を作ることになった。

SIの終焉3（本題）

• アメリカ 地獄編
• シリコンバレーの紹介
• 舞浜の先に埼玉が来た感じ、田舎。
• それなのに家賃が超高い。年収は日本円に直すと、新卒1000万。もらってる人は5000万？
• 各家庭共働きが当たり前
• インフラの画一化
• 民間企業がゴミを回収している、サービスを選べない
• 犯罪、車上荒らしにあったが、警察は現場に来ない、日常茶飯事なので、emailを聞かれ、被害届サイトがあって自分で入力し、それをもって保険請求などをする
• これらは民間企業がやっている、被害届けはCoplogicという会社（SaaS）

• アメリカでは、インフラを徹底的に効率化している
• インターネット化
• クレジットで払うのは当たり前で、日本と逆に現金で払えないお店がある
• それらの民間企業はどういったビジネスをしているのか
• Coplogic -> へぼい（見た目の話）CSSなんてないようなもの
• UBER（配車サービス）、日本はタクシー免許持ってる人？だが、普通の車とおじさんが来る
• Airbnb（ワードが出ただけ）
• 日本になく、アメリカにあるもの
• 積極さ
• なんとかなりそうなものが出たら爆走。下手したら一塁に出てないのに、二塁に行こうとするくらいの勢い

企業内の構造について

• 世の中の会社、役員は、社員を使い、評価、教育を行う
• トップでなく、リーダーでないとダメ、信頼してもらわないとダメ
• 活かすコミュニケーションとは、自分はやりたがらないこと、できないこと、思いつかないことを担当する（やりたがらないことをやって信頼を獲得する）

このあたりでセッションの時間切れ。

（LTに持ち越したようですが、都合によりLTは参加しなかったので聞けず）

【S405】俺は守りに入らない、これが今の俺だ

ガチDJになるようです。

次のセッションにも関連しますが、おかしいくらい熱中という意味では、冗談ではなく真剣なんだろうなと思います。

個人としては、Seasar2全盛期のように、プログラマー、エンジニア全体を活性化するような活動をしてもらえると励みになりますが、今は目指す方向が変わったということかな。

• ひがさん学校に通ってて、ガチのDJになろうとしている
• sxsw（サウスバイサウスウェスト）に向けて動いている
• プログラミングをやめるつもりはない。どちらかというと得意な方と思っている
• 今は、プロジェクトにとって一番いい関わり形でやっていきたい。（のでプログラミングは関わっていない）
• 今日は映像などはないが、自分にとって完成した思ったら公開はする、2ヶ月以内
• （その他専門的な話 & オフレコ寄りの話）

【S405】Seasarからクラウドへ、振り返って知る技術的に重要だった観点のある個人的観測について

DIxAOPというSeasar2に関係のある話しをうまく、クラウドのプロダクトに絡めて、興味深く聞けた。

特に、Fault Injection Testingの考え方は非常に面白いなと思ったし、考え方+ライブラリレベルで実現しようとしている企業もあるということで、参考になった。

前段

• 今は某A社のプリセールスのアーキテクト
• （Seasar2と関連して話しているのか）DIxAOP考え方の重要性は増している
• Webの受け口はシンプルにしてクライアント側の事情と切り離す、これらに関連している

前の会社からの転職について

• 2011 -> クラウドの世界へ踏み出す
• なぜ入ったか -> 必要なのは非連続的な成長と考えた
• 前の会社では、ある程度自由にできる部分はあったが、階段でしか上がれない会社であった
• 今の会社では、いろいろな会社、システムがみれた
• スタートアップ、メディア、アダルトといった多岐に渡る、お客さんを見ている
• 帯域、ストレージの使い方
• 小売からみたITと、ITのそもそもの考え方の違い、そういったものを学びたかった
• 全体を滞りなくまわすやりかた。そういったものが知れる会社

クラウドについて

• 扱っている粒度が変わってきた -> FW、ライブラリからサービスへ
• クラウドで重要な点
• 大事なのは、IaaSより、Programmable Infrastructureかどうか
• ダイナミックなインフラ
• コンピュートとストレージの明確な分離
• インフラのコモディティ化
• 使える技術要素がよりスケールに主眼
• 非同期、ノンブロッキング、スケールアウト、リアクティブプログラミング、一貫性の考慮
• クラウド -> ユートピアは来ない。全然違うプラットフォームとして考えたほうがいい。
• 運用面 -> 落ちても即座に復旧するシステム
• 一元的に集中管理、絶えず、改善、デプロイメントからロールバックまで
• システムが桁違いに大規模、細かいところはアプリ側で工夫したほうがよい
• 全体最適が中心、個別最適ではない

DIxAOP

• 大きなサービスを作る場合は重要
• 疎結合にしないとスケールしない
• クラウド、モダンソフトウェアにみる、DIxAOPの例
• Presto
• Facebookが開発している、Hadoop上でSQLを利用するエンジン
• s3mper
• Netflixが開発している、AWS S3上のデータ整合性ライブラリ
• Fault Injection Testing
• 障害を意図的に混入させテストする手法
• クラウドのリソースはクラウドにあるので、テストがしにくい
• 外部から状況をエミュレートしたり再現できたりする余地があることがシステムとっては大事
• こういった箇所でもDIの考え方が利用されている

マイクロサービス

• マイクロサービスは、サービスをパイプでつなぐみたいなもの
• 依存関係をアーキテクチャのレベルでできるだけ解決
• うまくやるには難しい、DevOps的な運用スタイルじゃないとそもそも無理
• 考慮すべきこと
• 認証と認可
• スロットリング
• サーキットブレイカー（まずいときに遮断）

最後のオンプレミス

• クラウドは、新しいプラットフォームであり、最後のオンプレミス
• 仮想化ベース -> EC2
• コンテナベース -> Docker,ECS
• イベントベース -> Lambda
• The No Stack Startup

これからのクラウドに向けての考察

• ダイナミックでプログラミング可能なインフラを使うには？
• クラウドネイティブな開発手法・設計手法、徹底的に活用するものがない
• クラウドネイティブアプリケーション
• クラウドを活用するための言語・開発ツール
• ローカルで開発じゃなくなりそうでは？
• 運用方法、もっと手がぬけないのか
• 自動化も作り込むまでが大変、全員ハンドメイド感

【S405】SmartNewsとBacklogの作り方

SmartNewsの浜本さん、ヌーラボの橋本さん、ひがさんのパネルディスカッション。
注釈がない限りは各プロダクトの方が話されていた内容。

浜本さんと橋本さんのアプローチの仕方が違っていているのに、根本にある考え方は意外と似通っていて、おもしろいなと思った。
バイアス（思い込み）、確かによくハマるので、自分の感覚だけを信じすぎるのではなく、客観的なもので判断というのは重要。

SmartNewsのパーソナライズの話し、パーソナライズをやめてみんなが興味があるものシフトしたのはなぜか？（浜本さん）

• パーソナライズをやめたわけ
• 当初は、TwitterのAPIを使っていて、ソーシャルグラフを取得して解析、個人の好みにあうものが表示される、というのをやっていた
• パーソナライズの段階を0 - 10で判断できるようにしていたが、0でも以外と面白いものがあることに気付いた
• パラメータチューニングするのが好き
• 初期では、インテリジェントなものができないのでいろいろパラメータを試していた
• 完全にオンにしていたものをオフにするということはなかなかやっていなかった
• パーソナライズにやろうとしていろいろためしていたが、逆にパーソナライズしないほうが面白いこともあるとわかった
• UIをわかりやすくするというのがあるが、余分な機能というのはどうやって削ぎ落としたか
• 当時は朝刊、昼刊、夕刊などを選べるようにしていた
• ユーザテストをやったときに、ユーザにみせると昼刊が夕方に表示されていて、なんで？と言われた
• ユーザからみると、昼から、夕方に差し掛かるときにひるのニュースみても仕方がない
• プッシュ通知としては残したが、ユーザから目に見える機能としては消した

Backlogについて（橋本さん）

プロダクトがうまれた背景

• 東京の仕事を受注して、やりとりするさいに、メールでやりとりするのが大変だったので作った
• 当時も他のツールはあったが、業務用すぎたので自分たちで明るいものを作ろうということになった
• 自分たちにとっていい感じのものを作った

Backlogの転換点

• 自社サービスとして出したのは大きな転換点
• 業務チックでないものに整えてだした
• そのころはクラウドというのもなく、小さい会社だったので、スラッシュドット？から叩かれた
• 浜本さん：SmartNewsもリリース時に叩かれた
• 浜本さん：ITメディアの人がジョインして、メディアの人とコミュニケーションを取ってくれてうまいこと鎮静化され
• Backlogの炎上は、放置した
• 結果的に（いいプロダクトだからか）ユーザは増えていった
• ものが当たるときは賛成、反対派がぽんとわかれるのかなと思っている
• ASP型ですぐにつかえるのがいいと評価されたものもある
• ひがさん：ユーザテストについては？
• あまりやってない、社内でけっこう使って実績があった
• 機能などは社内にものをいう人が多い
• 見た目はデザイナさんが、開発に参加してくれた
• ひがさん：ISIDでもBacklogを使っている
• ひがさん：Iデザイナーで開発者でない人ばかりのプロジェクトでも使ったりしていたが、そういうときに気軽に使えるのはよい

Backlogのコンセプト

• とにかくすぐに始められることというのが、当時はアイデアを練ってかんがえてたのはあった
• なので、ダウンロードはありえないよねというのはあったと思う
• ひがさん：そういったプロダクトのコンセプトとしては当初からあったのか。
• そう。プロダクトの作りにも関わってくる。
• （マルチテナントな構成で提供できる作りになっているかということだと思われる）
• ひがさん：方向性を変えるときでも、根本的な部分は変えてないというのはSmartNews、Backlogともに変わってないのかなと思った

SmartNewsのコンセプト

• SmartNewsは、Smartモードというオフラインでも読めるNewsを提供している
• 今は、Facebook、Appleなども提供している
• ひがさん：機能を削るという話はでなかったのか
• そこは削らなかった、当時は、地下鉄は電波が入らなかった
• そういう環境でも快適にニュースを提供したいという信念を持っていて、そこは譲らなかった

SmartNewsのユーザテスト

• 日本でも英会話カフェで外国人捕まえてやった
• アメリカでもクレイグスリストで募集をかけるとユーザが集まってくれる

Backlogのユーザテスト

• 最初にソフトウェアファーストでやったので厳密に狙ってたわけではない
• 少しは目論見があったので、英語版も出していた
• シンガポール、ニューヨーク、など現地スタッフがいる
• ひがさん：細かいチューニングとかはやってるのか？
• スタッフとして採用はしているので、そこでフィードバックはもらっているのはあるかもしれないが、やってますよとまでは言えない
• 狙ってやってるかというわけではない

起業、新しいサービスをするためのアドバイス

浜本さん

• 作ってる側の目と何の思い入れのないひとが見る目が全然違っていて、後から自分はなんでこんな思い込みをしているのかということがあった、今でもある
• 確実にバイアスがかかっていて、それを解かないといけない
• ユーザテスト、他のプロダクトとの比較などやっている
• 街にいる人のスマホとかの使い方の観察など、なるべく自分の感覚でないものを取り入れる目を持つというのを心がけるのがいいと思う
• SmartNewsとしてはプロダクト思考をめざしている
• ユーザに届ける部分の届き方が少し違うだけで、大きく変わるが、そこをきちんと伝えられるエンジニアは貴重

（プロダクト = 触ることができるもの（自分たちで意思決定、開発者している部分？）という意味か）

橋本さん

• おかしいくらいに夢中になっていること
• 浜本さんのように、いきなりアプリを直接見せて感想を聞かせてもらうように熱中しているような人
• 冷静な分析
• すばやい判断

【S405】SIは本当に終わったのか?

こちらもパネルディスカッションで、某A社の大谷さんと、ヌーラボの橋本さん、ひがさんの話し。

失敗パターンは特に参考になりました、確かに思い当たる点がいくつかある。。

SI vs スタートアップは、どちらがいいという結論は（当然）出ず。

SIの前提が、今のSIの延長線上でどういう体制、進め方で開発していくかという感じで、SIがどう変化していくかという話しではなかったのは、話し手のロールゆえになのかなというのが気になった。

栗原さんのSIの終焉3でもSIの向かう先が少し提示されていたけど、見るレイヤーが違う感じで、あちらは、SIはSES 、SaaSに分かれていく話で、SIのビジネスのやり方自体の話しをされていたが、こちらはもう少し狭いスコープの話しだった。

プロダクトの失敗パターン

• ひがさん：誰かからアイデアを持ちかけられたもの（他人事になりやすい）
• 人から言われたことをいかにうまくいくようにするかに考えちゃうから
• サービスが世の中に受け入れられるかどうかをスキップしているから
• 他人事になっちゃいけない
• 橋本さん：受託もそう、お客さんから言われた仕様をそのままうけると失敗する
• 大谷さん：オーナーシップを持てないもの
• スタートアップでも同じ、自分でオーナーシップを持てるかどうか
• ひがさん：焼き直し（ガラケー->スマホ等）
• 橋本さん：オリジナリティがないもの（社内用Twitter）
• ひがさん：広めるための施策がないもの（ユーザの増やし方）

企画だけで当たるかどうかは絶対にわからない。
なので、ユーザテストなどで検証が必要。

SI or スタートアップ

• ひがさん：大谷さんは、SI or スタートアップ？
• 大谷さん：スタートアップとSIの違いは、技術というよりは、スパンが違う
• 技術はコロコロ変えるものではないし、負債もそれなりに抱えてる
• サイクル的に変えるチャンスはあるかもしれない
• スタートアップでも古い技術ちょこちょこ置き換えながらやっているところもある
• 橋本さん：受託は、おもしろかったものもある
• ひがさん：受託やっていいなと思ったのは、ユーザのニーズが理解できるというのはよかったなと思う
• 金融機関のローンシステムの裏など（どういう審査がされているかとかがわかる）
• 橋本さん：受託のときは仕様書が降りてくるようなものは受けてなく、こっちが気持ちを持って作れるかというのがあった
• ワガママなお客さんも好きでなく、お互いが会話できる関係性でないと断っていた
• 大谷さん：（前の会社のとき）主体的に動ける人と一緒にできるかというのは大事だった
• 保険のシステムのときも保険のおばちゃんと発注している人の意識差が違ったりしてた
• ひがさん：SIとスタートアップの違い、結構違うというわけではなく、エンドユーザがどう使っているか、どう思っているかを見ながら開発できるのかというのが大事
• 橋本さん：全体を見るのが大事
• エンジニアとして注目してみると、受託だと事業計画を見せてもらわないエンジニアもいる
• それをお互いでブラッシュアップしてから仕事をうけるというのもあった
• お客さんもシステムをしょっちゅう作るわけではない、素人なので
• が、受託では踏み込ませてくれないときもある
• スタートアップだと事業計画はみやすいかも？
• 大谷さん：スタートアップというわけでもなく、企業の企画の方も該当しそう
• ITの中だけに閉じたとしても、できることが少ない
• AWSに行って、外の人といろいろ話すようになったかなり変わったと思う
• ひがさん：言われたものを言われたまま作るってのはうまくいかない
• 顧客といい関係を築きながら進めるのがいいけど、それが難しい
• 大谷さん：スタートアップだからというのはない
• チーム、企業の規模が大きいほど、難しい
• ユーザとダイレクトにインタラクションを持ちにくくなる
• 実際に使う人と企画する人が分離しないように、チームの作り方を工夫するのが大事かなと思った
• ダイレクトに使う人でない人が関わったら難しい
• スタートアップでは小さい人数で回しているのがあるから、ダイレクトに接しやすいかなというのがある
• 橋本さん：SEは、あまり仕事を頑張らないほうがいいと思う
• 頑張っちゃってるせいで、体調を崩している人が多いように見受けられる
• ハートフルな自分がでてくる
• （お客さんの背景なども考慮するようになってくる？）
• 橋本さん：スタートアップは広告戦略もあるので、それをそのまま信じるのは危険かなというものある
• 失敗したときのスタートアップは影響がでかい
• 受託は（契約によっては）受託金額という限度がある
• ひがさん：どっちもいいところ、悪いところがある

2014年の振り返り

2014年の振り返り。

今年は、gitを使った開発フローをいろいろ模索しながら進めるのが多かった一年でした。
Atlassianのstashを使ったgitの開発を本格的に初め、機能ブランチやプルリクエストを活用して機能開発、レビューの効率化などをしてました。

stashいいよ、いい。
stashで気に入ってるのは、以下の点です。

• レビュー機能
• パーミッション

・レビュー機能

レビューをする機会もかなり多いので、パッと差分が見れたり指摘できる環境があると便利です。
stashでは、プルリクエストを出す前に、ブラウザ上でブランチ間のdiffがすぐに表示されて、余計なコミットやソースが紛れ込んでいないかをセルフチェックできますし、プルリクエストした後では、コードの行やdiffにコメントをつけて、指摘や会話をすることができます。

これをうまく活かせるようになるべく機能追加はfeatureブランチで、バグ対応は、基本的にすべてブランチ上で対応、プルリクエストで処理するように変わりました。

・パーミッション

stashでは、ブランチごとにパーミッションが設定できるのですが、これはすごくいいと感じました。
それなりに人数がいる開発だと、gitの操作に習熟してない人もいてしまうので、誤ったpushをされてしまうケースがよくありました。
（実際に、メインブランチをforce pushしようとするような人もいました）

手順やルールだけだと、仕組み上できてしまうので、不慣れな人の操作を防げないこともあると思いますが、パーミッション設定でブロックしておいてよかったというのがありました。

個人的にもgitでこういったプロセスをまわして、プルリクベースで開発するのは楽しいしリズムがよい。




反面、うまく取り組めなかったものは、以下の点です。

• chefやansibleといったサーバ自動化周り

-> 実際に構築する（自分たちで手がだせる範囲での）サーバの数がそこまでないということで見送った

•  勉強会の参加

-> 大きめの勉強会はいくつか捻出できたが、コミュニティ系の小規模なものはあまりいける余力がなかった

勉強会、もう少しいけるようにしないとなぁと思います。
フロントエンド周りが少しウォッチできてない感があり、angularjsなどで多少触ってはいるものの、Web Componentsとかも勉強していきたい。

・来年（2015年）

ここ数年取り組んできた、FWや、自動化（ソース、テスト）関連の取り組みが一応、内部では評価されてるようで、それを広めるためにもう少しリソースを割いてもらえそうなので、うまくコントロールして多くのプロジェクトにレールをしけるようにしたいと思ってます。
加えて、git(stash)を使った開発フローもこなれてきたと思うので、こういった開発プロセスも整えて、より手間なく開発ができるようにしていきたいです。

デブサミ 2014 1日目

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

すでにまとめができてるようで関連資料などはそこで公開されそう。

デブサミ2014、講演関連資料まとめ

自分が聞いたセッション（リンクはTogetter）

• 【13-B-1】サーバプロビジョニングのこれまでとこれから
• 【13-B-2】グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～
• 【13-B-3】社内システムの構造と設計、実装のはなし
• 【13-A-4】新卒エンジニア研修ですべきことできること
• 【13-A-5】成功と失敗の狭間に横たわる2つのマネジメント
• 【13-A-6】Mobageを支えるテストエンジニアリング
• 【13-B-7】何故クックパッドのサービス開発は日々進化しているのか

全体の話

全体の傾向として、インフラ、テスト自動化、開発を通してのプロセスに関わる話が多い印象を受けました。

数年前はフレームワークや最新技術などのセッションが多く、少し前はクラウドの話が多く、これら前の技術・仕組みが当たり前となっている前提で、次のステップへ進んで行く話なのかなと感じました。

クラウドやCIは当たり前で、それをどう組み合わせて自分たちの開発プロセスをスムーズにしていくのかという点が中心な印象。

個々のセッションの話

セッション資料はいまのところすべて公開されているようなので、自分が感じた点を中心に記載しています。

【13-B-1】サーバプロビジョニングのこれまでとこれから

講演資料（speakerdeck）

serverspecなり、Chefなり、dockerなり今インフラレイヤーでトレンド周りを押さえたセッションで一発目としては興味深く聞けました。

会場アンケートで、Puppet、Chefを使用したことがあるかのアンケートだと、

• Puppet -> 数人
• Chef -> 3〜4割手を挙げた

という感じ。

Chefはホントにもう流行ってるようで、まだきちんと取り組めてない自分はちょっと焦る。

ただし、話の中でImmutable（Disposable）なインフラ、作って破棄できる環境というのが出てきてこちらのほうが自分は興味深く聞けた。

既存の動いているサーバに変更を加えるのではなく、全く新しいサーバを構築して、サービスの切替はロードバランサーなどで切り替える。

成功したら元のサーバは破棄（Dispose）、失敗したら元のサーバに向き先を戻す。

-> Blue-Green Deploymentという考え。（AWS EC2などによって容易になってきている）

Chefはかなり気になっているけど、環境を作った後に、差分でどんどんアップデートして行ける（メンテできる）ものかなという懸念があった。

学習コストが高いと聞くし、あまり難しいことまでこだわりすぎるとハマると思っていたので、シンプルに使える構成に持って行くのはたしかになるほどなぁと。

サーバにImmutableであることの制約をいれることによって、同じツールで常に同じ状態を維持するという敷居が下がるのかなという期待が持てる気がした。

後半に出てきた、Dockerは直近で試してみたいものだったので、デブサミという場でも出てきてちゃんと広まってるんだなと思って試してみたい意欲が上がった。

【13-B-2】グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～

講演資料（speakerdeck）

引き続きChefに関連するセッション。

こちらでも会場アンケート

• Chef触ったことある -> 4割くらい
• Chef使ってる -> 1割くらい

という感じ。

こちらでもMutable、Immutableの話が出てきていて、こちらだと、ChefはMutableだと相性がいいとのこと。

複雑で大変そうと思ったら、グリーではChef Soloをベースにラップしたツールを内製して使ってるよう。（Chef ServerはSPOFなり、Erlang人材不足などによりで採用しないことになったとのこと）

セッション聞いてると、Chefでなんでもかんでもやるのは厳しいかなとなんとなく思った。
ある程度、したいこと、やることを限定してやらないと収集つかないような印象を受けた。（それを乗り越えれば幸せになれるのかもしれないが、そこに至るまでが相当ハードル高そう）

前述のImmutable前提のように割り切ることができて、新規からのべき等性を確保するという割り切りができるならよさそう。

【13-B-3】社内システムの構造と設計、実装のはなし

講演資料（slideshare）


社内システムほど、他システム連携を考えようというのがすごくいいなと思った。
連携するのはやっぱりJSONが便利。

社内システムは長期運用が前提になりがち。
欠点や問題点があっても、長い間ほっとかれるものもある。
ドキュメントは、風化していくので、データ自体が人に見やすい形になってるのはとても大事。
たしかによっぽどカリカリなパフォーマンスを求められない限り、わかりやすいもののほうがいい。
触る敷居が低いというのはシステム連携を考えるにあたって無視できない要素だなというのを再認識した。

JSONなどのAPIを提供する際には、view側にも仕組みを持たせすぎるよりも自身のviewからもそのAPIを叩くようにした方が修正が少なくてよい。（クライアントjsでそのAPIを叩く方式等。）

「社内システムほど試しやすい場はない」
まさに。

【13-A-4】新卒エンジニア研修ですべきことできること

講演資料（speakerdeck）

個人的には本日一番、ためになった（ある意味耳が痛い）セッション

「自走できるエンジニア」

これができるエンジニアを育てることはやっぱ難しいと再認識。
出来る人は勝手にできるようになるけど、そうじゃない人を引き上げるというのは、やはりかなり根気や覚悟がいるということ。

理想を先に刷り込むという表現があったけど、いいケースをちゃんと知っておくというのはとても大事だと思った。

実際の現場だと、多くのことがバッドノウハウなどで回避できるけど、それって本来は良くないことなんだという意識をちゃんと持てるか（それが当たり前だと思わないか）というのは成長に必要な要素だなと感じた。

物事に疑問を持てるエンジニアになれるかというのはエンジニアとしてやってくには大事な要素だ。

考えとして、

• 基本的な技術向上、マインド向上
• 問題を問題と感じれるか
• 応用力を身につける

というのは考え自体は自分もなんとなく思ってたけど、それを体現されるまでにもっていったのは素直にすごいと思う。

【13-A-5】成功と失敗の狭間に横たわる2つのマネジメント

講演資料（slideshare）

マネジメント関連のセッション。
マネジメントといっても、よくいうQCDに関わるマネジメントではなくて、マインドのマネジメントのお話だった。

全体的にふむふむと一緒に考えながら聞けた。

期待マネジメント
ここまでやってくれる「はず」が実は自分とチームや、上司が思っていることが違うことが往々にあるので、お互いに表明してすり合わせていかないといけない。

なんとなく周囲に期待されているものはわかるけどはっきりする機会というのはそうそうないのかもしれない。
自分の場合は、これやりたいとか、これやりますと言い切ってから取り組んでるので、そういう意味だと自分の表明はできているかもしれないけど、反対に周りの期待することをちゃんと聞けてないのかなと感じた。

また期待は変わっていくものなので、定期的に確認する必要がある。

モチベーションは何気ない一言で乱高下する。
また人によって鍵穴（きっかけ）は全然違うし、他人がその鍵を持っているわけではないので、周りは手助けはできるが、やるのは自分自身。

良いプレイヤーは不調な時が短い、調子を上げれることも重要。
へこんだときに立ち直れるスイッチを自分で知っておくのは大事。

これは確かにそうだと思う、常にいい状態で入れる人はいないと思うけど、できる人はなんらか自分のリフレッシュ方法やゾーンに入りやすくする方法などを経験的にも持っている気がする。

【13-A-6】Mobageを支えるテストエンジニアリング

講演資料（slideshare）

テストに関する、チーム組織が中心なセッション。

DeNAではSWETと呼ばれる特殊チームがいるようだ。
名前は違えど、Google(SET)やMS(SETD)にも同種のカテゴリはあるらしい。

テストのパターンところで、ブラックボックス、ホワイトボックス、グレーボックスと三種類出てきて、グレーボックスってあまり聞いたことない単語だなと思ってたら、DBやキャッシュなどアプリデータを直接いじってテストするということだった。

条件付きの結合テストに近いのかなと。
前提を置いてデータを積んでテストするということであまり特別な感じは受けなかった。

テストでCalabash(Cucumber)を使ってたみたいで、やっぱりいまいち受けはよくないみたい。
自分はあまりCucumberは肌に合わない（無理矢理感が強くて中途半端になりそう）と思っていて触ったことはないけど、Cucumberを絶賛している資料とかはあまりみたことがない。

Appiumというのがあるそうで、こちらはWebDriverを使っているっぽい。
やっぱりWebDriverベースのツールがいいようだ。
自分もWebDriverはよく使ってます。（よくInternetExploreDriverに泣かされるけど）

【13-B-7】何故クックパッドのサービス開発は日々進化しているのか

講演資料（speakerdeck）

クックパッドの開発フローのセッション。

java-jaの方だったけど、最近はその界隈の人たちはあまりきてないのだろうか。
java-jaのセッションは昔は冷やかしとか爆笑とか結構あったような気がするけど、今回のセッションの雰囲気はそんな感じではなかった。（くすくす笑いはあったけど、昔のような内輪ノリはなかった）

全体を聞いた印象は、クックパッドすごい。
クックパッドは、ほぼすべてでGitHubを活用していて、デザイナーさんだけでなく、サポートデスクの方もGitHubのIssueなどを直接扱っているよう。

GitHubという土台があるからこそだと思うけど、サポートの方までGitHubを活用するというのは目から鱗な感じ。

ここらへんをある程度個人の裁量で決めれる組織風土というのもあるんだろうけど、そういったより良くしていこうというのがいいサイクルで回ってるんだなというのがみてとれた。

少し前は、タスク管理と言えばRedmineやTracなどが活用されていたけど、GitHubベースになると下手に連携とかしないでIssueを活用する流れの方がいいのかな。

2013年の振り返り

2013年の振り返り。

今年は、去年（2012年）に培ったものを別のプロジェクトに適用していくなど、改善にフォーカスした一年でした。
まったくの新規技術といったものには触れてはいませんが、去年本格的に導入しだしたもの（Jenkins、WebDriver、Gradle）を引き続き導入・深く掘り下げてることが多く、裏方寄りのお仕事が中心になってる状態です。

そういった意味では去年の振り返りの後半に書いた方向に、少しは舵取りできてるのかもしれません。（アプリ単体ではなく、運用・保守までトータルしたクオリティを向上させ、疲弊しない開発やプロジェクト運営というレールをしけるようになっていきたい）


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

• Jenkins x WebDriver
• ソース自動生成

・Jenkins x WebDriver

社内的には、自動テストが受けがいいようで、WebDriverの方が受けがいいのですが（苦笑）、個人的にはJenkinsさんにいろいろ頼るのが好きです。
去年は、初めて導入という感じでしたが、だいぶ回し方も慣れてきたようで、新しいプロジェクトではどうJenkinsを活用してビルド＆デプロイ、テストをうまくこなしていくかを考えれるようになりました。（導入するのが当たり前になった）

Jenkinsはある程度テンプレ的に構築できるのですが、WebDriverをうまく活用していくのはアプリの特性やくせもあるので、まだ一概にすっと導入できるかというと、まだ難しい部分もあります。
対して、あらかじめWebDriverなどブラウザ自動テストを行う前提で設計をしておけば、バッドノウハウも少しずつ溜まってきているので、ハマりどころが少なく抑えれるかなと思います。

・ソース自動生成

僕自身も、諸手を挙げて賛成というわけではありませんが、きちんと適用範囲を決めて導入するのはアリだと思っています。

基本スタンスとしては、すべてを自動生成とか、設計書と同期とりますとか、GUIでノンプログラミング、というのはよほど簡単なシステムでないと難しいと思っています。

しかしながら、数百画面レベルの規模だと、さすがに一画面ずつ一からというのは非効率なため、ある程度パターン化して、可能な範囲で雛形を生成していくのは一定規模だと必要かなと思っています。

このあたりをソース自動生成用のフレームワークをベースにして、アプリに特化した対応をすることによってうまく適用していくというのが今のところの現実解かなと考えています。

とはいえ、やりすぎると自動化ハイ（自動化が目的になる）となるので、

• 可能な範囲の見極め（頑張り過ぎない）
• 書き換え可能（その後は各自でエンハンス可能、ツールによっては編集禁止とかもあるので。。）
• テストも合わせて雛形生成（デグレ検知＋テスト自身の作成も負荷になる場合もあるので）

というくらいのカジュアルな方針でいいと思っています。

実際、これくらいの方針でもちゃんと母数が多いと効果はでるので、アリかなと。

また、自動生成されるコードは、キレイなコード（可読性を意識＋あらかじめユーティリティや抽象クラスを活用する設計）を心がけているため、コピペコードの防止という面も合わせてあります。（プロジェクトの都合でどうしても、きちんとしたコードを書ける要員が集めれないという場合は助かります）

・来年（2014年）

ひとつ楽しみとしては、gitを社内で利用できるようにしました。

2013年後半から徐々に準備しており、年明けごろからはgitベースで開発できるようにしたので、来年はそちらの方面で楽しく開発できそうです。

subversionでもいいじゃんという話もありますが、結構リリースが複雑になりそうなプロジェクトがあるので、ブランチ、マージがより柔軟なgitでチャレンジすることにしました。

もう一つは、出遅れ感はややありますが、chefなどのサーバ管理ツールをなんとかねじ込みたいですね。数はそんなにないとは言え、似たようなサーバを構築することはそこそこあるのでこのあたりのフローも省力化していきたいです。

来年も、基本路線としてはやはり、疲弊しない開発やプロジェクト運営を行えるようにしていきたいというのは継続していきたいと思います。

# あとはもう少し、勉強会の参加を増やしていきたいところです。
# 下手すると来年はデブサミが勉強会始めとなるかもしれません。

Web✕Java - HTML5で進化したWeb標準を、Java技術でどう扱うのか？ に行ってきました

・サイト
  http://atnd.org/events/42782

　公開可能資料は後ほど、html5jえんぷら部で公開されるとのこと
　http://www.html5biz.org/

・アジェンダ
  ・今のWeb標準とStruts/Javaの問題(仮)
  　出遅れて受付待ちで拝聴できず。

  ・Java EE の概要と HTML 5 の取り組み
  　# 資料は9/10午前時点で未公開
  　twitterのTLによると近いのは以下らしい。
  　http://www.slideshare.net/mobile/OracleMiddleJP/java-ee-7-detail
  　http://www.slideshare.net/OracleMiddleJP/java-ee7-html5

  ・Strutsから移行する人のためのJSF基礎
  　http://www.slideshare.net/SatoshiKubo1/strutsjsf

  ・JavaプログラマのためのScalaプログラミング
  　# 資料は9/10午前時点で未公開

  ・JavaからScalaへ　~ScalaでWeb開発はこう変わる~
  　http://www.slideshare.net/takezoe/javascala


・全体的な感想
タイトル詐欺（笑）
html5の話がほぼなかったのは残念。

半分くらいは、Scalaだった気がする。

Scalaは業務では使えていないけど、FWとかはウオッチしているので、実体験としてのplay2、Scalatraの話が聞けてよかった。
竹添さんが言っていたけど、「エンジニアとしては新しいものが出てくる環境のほうがよい」というのは同意です。
Javaは、まだまだアクティブだと思うけど、Seasar2のコミュニティがアクティブだったころよりは熱気というのは冷めている気がする。
（とはいえ、Springは継続的にSpring4まで来ていて十分活用していますが）

ただ、熱気という観点だと、ここ数年はJava/Scalaといった言語面というよりも、CI/DepOpsといった開発サイクル全体への取り組みへと分散して行っているという感触がある。
今まではプログラム中心でアクティブだったけど（ある程度成熟してきたのもあって）、CIやリリースサイクルの高速化、運用の向上といった点がフォーカスされてきているのかなと。

また、Oracleの寺田さんのJavaの話でいつももったいないなと思うのが、過去のアーキテクチャ（Struts/Spring/Hibernate）をよくdisること。
それと比較するよりは、EE7ではこう楽なんですよとアピールして行く方が建設的なのかなと思いました。

今、Springをそれなりに使っている人は、部分活用するにしても、わざわざ全面的にJavaEEに戻ったりはしないと思うので、新規参入者に向けて標準技術がいかに楽できるんですよと言って行く方がいいのかなと思う。
EE7でできることは、すでにSpringでできるか、Springと統合しやすいようなライブラリがあったりするので。

# tomcatと比較するのは、サーバ製品を売っているベンダーということで、理解はできます

同じjava内のStruts、Springと張り合うより、nodejs、ruby、.netなど別の言語からのパイを奪うほうがjava全体にとってはいいはず。


・メモ
・Java EE の概要と HTML 5 の取り組み
  ・Struts1.xはEOL、使い続けるなら自分たちで脆弱性の対応をしなければならない
    ・# ベンダー製品もバージョンのサポート期限やバージョンアップによる検証コストもあるのでそんなに変わるかなという気もしなくもない
    ・# strutsに限っては、枯れている、大手SIerがサポートし続けるだろうというのもあって別枠として捉える方がいいと思う

  ・相変わらず（？）のStruts/Spring/Hibernate dis
    ・# そろそろ未来の話を聞きたいところ
  ・EE7
    ・Oracle寺田さんのブログ内アンケートでは、WebSocket/JAX-RSなどが人気上位
    ・従来型(JSF)、次世代型(WebSocket, JSON, JAX-RS)どちらにも対応している
    ・JMSが改善されているらしい。
      ・# が、Springだと特にJMS用のクラスとか作らないでいいので気にしたことない
    ・EE7は、本番にいきなりはおすすめできない。まずはEE6から試してほしい。
　　・GlassFish4.0ではEE7の機能はお披露目的な感じで、本番環境ではまだあやしい部分があるとのこと
    ・http://yoshio3.com/2013/06/11/glassfish-v4-0-released-0611/
    ・# APIや仕様的に気になるのが多いけど、はっきりと本番で使える品質ですって言われてないと、標準を採用基準として考える人は（標準なのに）採用しづらいのでは


・Strutsから移行する人のためのJSF基礎
  ・JSFの拡張ライブラリ、Prime Faces、Rich Facesがある
  　・Prime Faces より Rich Faces のほうが、海外の認知度は高い？
  ・モダンブラウザしか対応されていないケースが多い（業務システムには少し敷居が高い）
  ・JSF1は、メモリを大量に積んで下さい（Struts時代の2倍から10倍ぐらい）
  ・# struts->JSFは需要あるのか。自分はthymeleafに流れてしまった。


・JavaプログラマのためのScalaプログラミング
  ・Java/Scalaでの記述比較中心
    ・# が、文字が小さくてスライドがあまり見えなかったのが残念。。
    ・# 資料公開されたらゆっくり見てみたい
    ・# groovy/gradleで文法が似てる部分もあって、慣れればすんなり読めそう
  ・traitは、mixin（別のオブジェクトの実装を持てる）できる機能。（という理解でいいのかな）
    ・java8ならインターフェースのデフォルトメソッドが近い気もする


・JavaからScalaへ　~ScalaでWeb開発はこう変わる~
  ・play2、Scalatraの話
  ・Javaの（これ以上の生産性向上の）限界を感じた、らしい。
    ・Seasar2 + Click + S2JDBC からScalaにポーティング ->コード量40〜50%減。
    ・play2、ノンブロッキングIOで大量アクセスをさばきやすい
      ・が、IOがノンブロッキングでも、ボトルネックはやはりDB待ちのケースが多い
      ・viewテンプレートもタイプセーフなので、実行前にエラーがわかる
      ・# これはけっこう惹かれる
    ・play2のwarプラグインは茨の道（はまりやすい）
    ・play2 -> BtoC（大量リクエストをさばくもの）
    ・Scalatra -> 業務アプリ向き（Javaからポーティングしやすい）
      ・# javaから行くなら、play2よりScalatraのほうが親和性がありそう

JJUG CCC 2013 Spring

・サイト
  http://www.java-users.jp/?page_id=330

・まとめサイト
  http://togetter.com/li/500961

・参加したもの
  ・H-1JavaEE6からJavaEE7に向かって
    http://www.slideshare.net/OracleMiddleJP/java-ee-6-to-java-ee-7

  ・H-2ProjectLambdaEssential

  ・H-4失敗から学ぶAPI設計
    http://www.slideshare.net/yusukey/api-ccch4-jjug-jjugccc-jjug-ccc-2013-spring

  ・R2-5[BOF]Groovy2.Xの新機能
    http://www.slideshare.net/uehaj/jjug-ccc-groovy2x20130511

・全体的な感想
Lambdaの話と、Twitter4jのAPI設計の話が特にためになった。
Lambdaは、遅れてもいいからJava8に入って欲しい。

Lambda、Groovy（というか主にGradle）でクロージャ周りを使えるようになってきたけど、やっぱり書きやすさが全然違う。
全容を把握できてる訳ではないけど、うまくJavaのタイプセーフさとも組み合わさればJava8は広まりそう。
ネタでコーディングルールで、Lambda禁止とかあるけど、導入されるなら積極的に使って行きたい。

インターフェイスのdefaultmethod、implmentsした順で実装が優先されるとかいう理解をしてしまっていたけど、Twitterで指摘をいただいて試したところ理解が間違っていた。
別のdefaultmethod同士だと、やっぱりどちらの実装を選択するかを明示しないといけないよう。

https://gist.github.com/hiroisojp/5560120

Twitter4jのAPI設計の話、ライブラリとフレームワークという側面でAPI設計は結構変わると思うけど、
主にライブラリとして作って行く場合の設計意図の話が直接聞けてためになった。

  ・拡張ポイントはなるべく少なく
  ・クラス継承はさせない
  ・デザインパターンを活用しすぎない（初心者は詳しくない）

というところから、ライブラリとしてのスコープ（どの部分までを扱うか、どう提供するか）をブレないように設計するという観点が必要と感じた。

その他、細やかな点として、
  ・IDEの補完を活かせるようにする
    ・同一パッケージにして、検索性を上げる

  ・IDEの補完が効きすぎないようにする
    ・利用して欲しくないクラスを意図的に検索性を下げる
ex)z_T4JInternal***として、z（補完候補の最後の方にでる）、Internal（内部で利用しているクラス）というように意図を示す

といったのも参考になった。

・メモ
・H-1JavaEE6からJavaEE7に向かって
  ・JavaEE6の振り返り
  ・JAX-RPC、EJBEntityBeanは、EE6で廃止予定で、EE7からは「仕様上なくなる」。実際になくすか（下位互換を保つか）はベンダーに次第

  ・EJBコンテナをJUnitであげれる->サンプルコードはルックアップしてるがDI形式にできないのかな？（その方がスマートだと思う）

  ・JavaEE7のテーマは、「シンプル化」、「HTML5対応」
  ・EL3.0で実はLambda式がもう使える（SE7環境下で動作する）
  ・EL3.0でやり過ぎると、昔のJSPのロジック埋め込みに逆戻りな気がするので、ビューとロジックを分離して欲しい気がする

・H-2ProjectLambdaEssential
  ・Lambdaは、クロージャ周りが注目されがちだけど、（出自としては）クロージャのためではなくパラレルコンピューティングを導入するため。
  ・Lambda<<API（のほうが重要）
  ・functionalinterfaceでインターフェイスを定義すれば、Lambdaで書ける。
  ・@FunctionalInterfaceは、実装が問題ないかコンパイル時にチェックするためのもの（後で確認した）
  ・StreamAPIは、Groovyのコレクション処理に似てる気がした
  ・map、filter（戻り値がStreamになってるようなもの）は遅延される。->最適化されて速い

・H-4失敗から学ぶAPI設計
  ・「NoGGRKS」（親切に対応）

  ・シンプルにYAGNI。将来必要になるかもとか拡張性とかを考えすぎない。
  ・クラス数は極力増やさない。インターフェースは（なるべく）使わない。
  ・拡張ポイントはなるべく少なく。何でもかんでもやると逆に初心者に難しくなる。
  ・クラス継承はさせない。finalじゃないと意図しない挙動になることがある。
  ・一部finalでないものはモック用が主で、コメントで理由をつけている。

  ・ライブラリ自体を簡単に書くよりは、ユーザが簡単に利用できるようにしている。
  ・普通のユーザが戸惑うような作りにはしない。
  ・デザインパターンを適用しない。（やりすぎない）->知らない人が多い。

  ・IDEの補完を活かせるようにする。
  ・一般的すぎるクラス名にしない。
  ・IDEの補完がいきすぎないようにする。使うべきでないクラス名を異様にする。（z_T4JInternal*****）

  ・至上命題
    ・互換性の維持
      ・クラス名を変えない。
      ・挙動を変えない。
      ・Twitter側の挙動が変わった場合は判断が迷う、Twitter4jが吸収すべきかどうか。
      ・直列化形式（シリアライズ）の互換性の維持
        ・復元ができないケースがたまにある。対応する情報がなくなったとか
        ・フィールドは残してgetterなど省くなどで対応。
      ・難しい。が、気をつけるだけでテストはしてない。（ホントはしないといけないけど、コストがかかる）
    ・互換性情報は、ドキュメントで通知
    ・非互換はコンパイラに検出させる。どうしても保てない場合など。

・失敗例
  ・パッケージ構成
  ・やりすぎるとクラスが見つけられない。blogのコード例をコピペしても見つからない。
  ・（ただし、通常のプロダクトでは機能別にパッケージわけしたほうがいい）
  ・ソースディレクトリをわけるのがいいかもしれない。

・R2-5[BOF]Groovy2.Xの新機能
  ・スピーカー、プログラミングGroovyという書籍の中の人だった。
  ・Groovyは、動的が中心だったが、動的かつ、静的言語になってきてる
  ・Gradleは、Androidの公式ビルドシステム

  ・2.0から、@TypeChecked、@CompileStaticなどの静的チェックを行えるアノテーションが導入されている
  ・静的Groovyでどう変わる？
  ・引数は省略できなくなる、動的機能は対応不可。（そのかわり性能向上、IDE補完、型安全、ランタイムではなくコンパイル時に検知。Javaっぽい）
  ・静的Groovy、大規模なものをあとから書き直すというのはちょっとつらいように感じられる。

  ・indy対応(invokedynamic)、Groovyのindyはあまり性能がよくないようにみえるよう。

  ・Groovy2.0
    ・静的への回帰
    ・BettarJava
    ・今使えるJava8(Lambda,TypeAnnotation)

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とか、。。。ですねぇ。
（そしてその運用が当たり前と思うような保守も）

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

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