SyntaxHighlighter

2015年12月31日木曜日

2015年の振り返り

2015年の振り返り。

今年は、ここ数年取り組んできたFWや、自動化(ソース、テスト)関連の取り組みの整備、発展、またstash(bitbucket)を使った開発フローを導入、普及するということが多かった一年でした。
反面、新しい技術に取り組む機会が少なかったのが残念ではあり、導入検証レベルでdockerにトライしている程度。

そういった意味では、よい効果が出たものを各方面に普及しつつ、また自身は新しいものを吸収していくということはやり方に工夫がいるなということを感じた一年でした。
ただ、チャレンジの年、普及の年と1、2年ごとに入れ替えがあるのはいいことかもしれません。(毎年チャレンジだけしてそれを普及しないというのも仕事としてはどうかなと思うので)

また、今年はそこそこの規模での案件の平行開発が活発で、gitのブランチ運用がかなりノウハウがたまった気がします。
それにともない、CIのジョブもうまくそれぞれの環境でテストできるように工夫が必要だったりで、難しい反面、ひとたび構築出来ると安定感が増すので、このあたりは文書化して残しておくのは重要かなと思いました。

反面、忙しさが増してしまい、勉強会の参加はうまく取り組めなかったと思います。

去年にも引き続き、大きめの勉強会は時間を確保したが、コミュニティ系の小規模なものはあまりいける余力がなかった。
また、大きめのものはブログに感想を書くようにしているが、小さめのものはtwitterでつぶやいて終わりという、振り返りがきちんとできていないものがいくつあった。

勉強会、行ってブログにまとめるまでが勉強会ということもあり、アウトプットをまとめることをしていかないといけないなと思います。


来年(2016年)

来年は、環境がいろいろ変わりそうなので、また少しチャレンジをしようと思っています。
今までやってきたものを下地にして、自分の地力が試されそうなので、一歩ずつ取り組んでいこうと思います。

2015年11月17日火曜日

JavaOne 2015 報告会に行ってきました。

JavaOne 2015 報告会に行ってきました。


JavaOne 2015 報告会 @ 東京
togetter JavaOne 2015 報告会 @ 東京 #j1jp

自分が聞いたセッション(リンクは公開された資料)

全体の話

JavaOne 2015に行った方々のJavaOneの雰囲気 + Javaの最新動向の話し。
最近の大きめのカンファレンスは、あまりコードの部分に触れることも少なくなり、少し寂しかったのですが、今回は、Javaの未来の話しということもあり、新しい機能と共にコード例がたくさんあり、わかりやすいものも多く、非常によかった。

報告会では来年JavaOne行ってみたい人アンケートがちょっと出て、手をあげなかったけど、後日、この報告会の話しを知り合いに話したら来年一緒に行ってもいいかもと言われてたので、気になるイベントに。
(もし行けても、個人で行くことになりそうなので、もう少しチケットがお手頃ならいいのになぁ。)

個々のセッションの話

Impressions of JavaOne & Java trends


JavaOne全体の雰囲気を伝えるセッション

気になったキーワードあたりは下記

  • 今回のJavaOneは大きなアップデートなし
    • ORACLEは予定通りに作業を進める会社
    • 成熟し、大人になったものと思えば良い
  • OracleはJavaとJavaコミュニティを重視している
    • EE8はコミュニティの声をきいて、どれを入れるかを決めている
    • (ベンダー主導でない)
  • JJUG CCC 2015が、11/28(土)にあるので来てね


技術トレンド

  • DevOps & Microservices
    • Javaそのものは重要視ではない(Javaは基盤)
  • そもそも「ソフトウェア開発」が重要ではない
    • プログラミングができるのが重要だった時代から、サービスを提供する時代になってきている
  • ITサービス運用が重要
  • カナリアリリース
    • ブルーグリーンデプロイメント
    • ルーター側で古いバージョン、新しいバージョンを平行稼働して新しい方に振り分けていく
    • 問題があったら古い方に戻す
  • ダークカナリアリリース
    • 開発者にしかみえないリリースを本番環境でテスト
    • マイクロサービスにすると、周辺サービスに依存するものが多くなるので、本番環境でやったほうがテストが効率的
    • (クックパッドも本番環境でユーザには見えない機能が使えるとかあったかも)
  • Chaos Monkey
    • ランダムサーバを落とすOSS
  • サービス品質の確保
    • 全体的なサービス品質を確保するために、部分的な品質劣化を許容
    • 不運なユーザは存在しうるが、サービスがダウンするような事態にはならない
    • エンタープライズ発想とは逆
    • Netfilixがいうレベルのダウンタイムなら許容できるエンタープライズもあるのではないか
このあたりは、鈴木さんのブログをみたほうがよいかも。

エンタープライズにおけるDevOpsとマイクロサービス - JavaOne2015レポート

(感想)
SeasarCon2015でもFault Injection Testingの話しがあったように、Netflixは障害が起こるのは当たり前の前提での設計、テストをしているのだと感じた。

また、ソフトウェアデザインについて、重要なポイントが変化してきているというのは確かに思っていたことではある。

  • 内部品質 -> デザインパターンとかで綺麗に作るか
  • 外部品質 -> JUnitなどの単体テストしやすさで作るか(DIなども)
  • 利用時品質 -> サービス継続を確保するためにどう作るか

という感じでデザイン(プログラムの設計)の仕方が変わってきている。
というか、あまりプログラムの細部が語られなくなってきたように思う。

語られない = 必要でないというのは違うと思っていて、

  • それを必要とする人間とそうでない人間・会社の棲み分けがより広がってるのではないか
  • スピーカーが大人になった(一部分をみるのではなく、全体を見る立場の人が多くなった)

のではないかと思っている。

Java SE Update


  • JDK9は、2016/09/22、来年のJavaOneに合わせてリリース予定
  • JDK9 = Project Jigsaw + それ以外


それ以外

  • jshell -> コンソール上でコードをかけるようになる
  • Java.Doc.Next -> javadoc周りのがいろいろ便利に
  • Cross compiling and the javac -release -> source,targetオプションを集約したもの
  • Milling Project Coin -> "_"の命名禁止(既存でかいてると影響がある)、内部的な変更
  • Deprecation and imports
  • Re-engineering javac -> ダイアモンドネストが多いとコンパイル時間が増えてたのが改善
  • 非互換がいくつかあるので注意(詳しくはスライド参照)


JAR Hellの課題

  • 紛失したライブラリはどれか
  • コンフリクトはどこで発生したか
  • 内部APIを安全に変更できるか

-> JARの抽象化機構が必要 -> Moduleが必要

Module

  • モジュールの依存関係を定義する仕組み
  • 公開したくないパッケージをexports指定で公開しないようにできる
  • publicの範囲も指定可能に
  • API開発をしている人にはメリットがある
    • 意図しない内部的なクラスを使われなくなる

jlink

  • jlinkでオリジナルjavaイメージを作れる感じ
  • (java_20151113、java_new、java_bakとかできそうな。。)


(感想)
Moduleの公開したくないパッケージを指定できるというのは、FWなりAPIを作っている人からすると、嬉しいと思う。

Moduleはいろいろ記述が柔軟になりそうな反面、複雑なものが出てきそうで、JAR HellからModule Hellとかならないのだろうかとは懸念する。

また、今は実質、GradleやMavenなどのビルドツールを使っていると思うが、それらを置き換えてまで使いたいかというのを仕組みを理解している人に聞いてみたい気もする。

Gradleなどが、Module形式でかけたり、Moduleが定義されていると、そこらへんを読み取って依存を追加してくれたりするなど、Moduleとうまく共存できれば広がるんだろうけど、そのあたりはどうなんだろうか。

Java SE 講演から


Eclipse Collectionsの話し。

  • GS Collectionsから、Eclipse Collectionsへの移行途中
  • Spring ReactorにもGS Collectionsの依存が入っている
  • GS Collectionsでは社内的な事情でGitHubに公開していたものの、PRは受け取れなかった
    • コミュニティのコントリビュートを受けれるようにしたかった
  • Eclipse Collectionsへ。(パッケージもcom.gs -> org.eclipseへ変わる)

その後は、GS Collectionsでもあったようなお話。

(感想)
今回はまだスライド公開されていないようですが、下記あたりのものがJavaOne用にブラッシュアップされた感じ。

GS Collections and Java 8 Lambdas
GS CollectionsとJava 8 実用的で流暢なAPIで楽しい開発を!

Eclipse Collectionsになったはいいけど、GitHubでプルリクとか受ける形になるのかな?
(聞き逃したので不明ですが、Eclipse Foundation傘下なので、GitHubでやるのではないっぽい?)

GS Collectionsは、Java Day Tokyoで知っていたけど、追加の情報もあって勉強になった。

特に、throwingというラッパーメソッドのようなものを利用することで、lambda内のtry-catchがすっきり書けるのはとてもいいと思った。

Java ME & IoT


  • SE embedded -> なくなった(セッションがひとつもなかった)
    • Open JDKにモバイル相当のプロジェクトができた。(さくらばさん情報)
  • jigsawでやってくれということか変更点がほとんどない

他にJavaOneのマイナー?な点にスポットをあてたネタがいろいろなセッション。

Java EE Update(前半)


Servlet4.0
  • HTTP/2対応
  • HTTP/2 サーバプッシュ
    • htmlの要求がきたら、関連するjs,png,cssなどをプッシュする
    • 1リクエスト、1レスポンスの原則が崩れる
    • PushBuilderというものが検討されている
JAX-RS2.1

  • 非同期クライアントAPIの改善
    • Jerseyには既に実装がある
    • RxJava、Java8のCompletableFuture対応
      • 今は書き方が複雑
      • FinalResult、PartialResultアノテーションで順序制御(提案中)
  • ノンブロッキングI/O
    • 本当に必要かも含めて、まだまだ検討中
JMS2.1

  • JMS2.0の微妙な部分の改善
  • MessageListenerの実装が不要に
    • Messageインターフェースのキャスト不要(TextMessageなど)
  • キュー指定がJNDIで指定可能に


JPA2.2

  • Java SE8対応
  • Date and Time API
  • Repeatableアノテーション
  • スクロール機能の標準化。(hibernateであったもの)


WildFly Swarm

  • Spring Boot風のJavaEE(まだ実験的)
  • Spring Bootとの背景の違い
    • Spring Boot -> Springを利用するときにpom.xmlが複雑化していたのを整理
    • WildFly Swarm -> Java EEをフルセットで使うのではなく、利用する機能だけ一式jarにまとめて軽量化
  • ・・・とあるが、WildFly Swarmで実行可能なjarができるが、今はちょっとした依存の組み合わせでも、100MB近いjarになる
    • 不要な依存がまだ入っているのではないか
  • 機能の追加はpom.xmlに追加したい機能を依存に追加する(Spring Bootと同じような感じ)
  • デフォルト設定(Spring BootだとAuto Configuration)もある
    • 何が設定できるかは xxxFraction.javaのソースを読む(しかない?)

SwarmによるJava EEの分解を見て
  • Java EEもマイナーアップデートが欲しい
  • Springは着実に進化、JavaEEは標準化に時間がかかる
  • 仕様確定後、実装サーバが1年越しにようやく出てくる


(感想)
JAX-RSの非同期部分はあまり知らなかったので、コード実例がありながらだったので、とても参考になった。

最後にも言われていたが、EE全体は、どうしてもSpringに比べてスピード感が遅い印象で、洗練された新しい機能を早く使いたい場合は、(対応されていれば)Springの方がいいと思う。

とはいえ、標準化がされないと独自仕様が乱立するだけなので、Java EEとSpringでいい仕様をフィードバックしあって成長していって欲しい。(Springで実質デファクトとなったものを整備してEE側にも取り込まれて、Spring側がそれらの標準仕様に対応していくという流れはいくつもあるので)

Java EE Update(後半)


MVC1.0

  • JSF(component)ではなく、なぜMVC(action)か
    • 見通しのよさ、簡便さ
    • RESTとの親和性
  • フロントエンドの流行廃り
    • WONTA(Write Once, Never Touch Again)
    • どうせそのうち書き直すのだから、保守性は考慮にいれないの意味
    • 定着したサーバサイド技術として、MVCへのニーズ
  • ValidationはBeanValidationベース
  • ビュー(JSPなど)は仕様レベルではJSP、Facelet
    • 参照実装(Ozark)にはextensionとしていくつかある
    • (自分がよく使っているThymeleafもあるよう)
  • スコープ
    • デフォルトスコープは、request
    • リダイレクトスコープ(RedirectScoped)も可能
  • FWでなく、API
  • 「ポストStruts」ではない
  • Validationとそれに関連する画面遷移の周りのをもうちょっと使い込まないと実用にはつらい

(他に紹介されてた、JSON-P 1.1、JSON-Bはあまり使うことはなさそうなので省略)

JavaOneの感想

  • すでに日本のブログや勉強会で紹介されてたネタもちょくちょくあった
  • 世界とレベル差はあんまりない


(感想)
MVC1.0はSpring MVCっぽいものがEEとして出るというような感じで、Spring MVC自体はかなり気に入っているので、そういったものが標準として出てくるのはよいと思った。
また、(参照実装ではあるが)Thymeleafも対応されそうな気配があるので、ウオッチしたいなと思う。

JSONは、Jascksonがデファクトなような気がするので、今更感が強いような。
(加えて、JSON以外のデータフォーマットが数年後に出るかもしれないのに、低レベルAPI部分に凝り過ぎなような気もする)

Speaker Panel: How to be a speaker at JavaOne?

パネルセッション

スピーカ

  • 谷本さん(アクロクエストテクノロジー)
  • 伊藤さん(ゴールドマン・サックス)
  • てらださん(Microsoft)


Q1. JavaOneで講演してどう?

  • 谷本さん
    • スピーカーで言っても飛行機代出ない
    • コミュニティに貢献できるのはうれしい
    • うかるテーマで出したので、話したいものではないのでモチベーションが上げにくかった
    • 他の人がやらないようなもの、事例系がうかりやすい
  • 伊藤さん
    • JavaOne初めて行ったので、テンションあがった
    • Call for Paper(CfP)と別経路で話すことになったので、講演が決まったのは9月入ってからで急だった
    • Eclipse Foundationで話す枠があったので、提供してもらった
  • てらださん
    • Oracleをやめたけど、JavaOneに行きたかった
    • 自腹でいこうと思っていたが、JavaOneのチケットは15万くらいする
    • Oracle時代に世界中のコミュニティの人と知り合いだったので、受かった人にお願いした
    • 人のセッションに乗っかって、話させてもらった(2、3人スピーカー登録できるので)
    • 当初は、話すまでは予定になかったが、発表の10分前に話すことに決まった
    • 日本用の動画の画面、文字でプレゼンで、英語でしゃべって説明した
    • 意外と日本語の画面でもわかってくれる人もいた
    • (今回でなく)1回目の発表はめちゃくちゃ緊張した
      • JavaOneはセッションがおもしろくないと人がどんどん抜けていくのを知ってたから
    • 今年は、10分前に決まったものもあって、気楽にやれた
    • 日本でイベントでしゃべってるような感じできた
  • 谷本さん
    • (今回でなく)1回目、自分の英語が伝わってるか不安だった
    • 多少、文法が間違ってても準備してたら話しをきいてくれる
    • 今回は準備不足で結構、途中退席されてしまった
  • てらださん
    • 日本とちょっとプレゼンの仕方が違う
    • 日本では最初つまらなくても、後半でおもしろかったら印象に残る
    • アメリカはおもしろくなかったら退席されるので、最初にこういうポイントは聞いてほしいということを伝えておくのがよいと思う


Q2. 今後、どんな人にJavaOneで講演してもらいたいか

  • 谷本さん
    • JJUGなどで話している人がいい
    • GC、JVMなどのコアな部分ではそうではないが、それ以外だと日本人の発表が勝っている人もいる
    • 世界で活躍すると、コミュニティも盛り上がる
    • コミュニティに参加しているような人は積極的に参加してほしい
    • 子供がプレゼンというのもおもしろい(子供がやってみた系)
    • (話あいまい)子供でもプレゼンの訓練をしている私立とかあって、そこの子供はとてもうまいそう
  • てらださん
    • 今日ここにきている人は、JJUGでまず発表してみることをチャレンジしてほしい
    • うかりやすいのは、事例系
  • 伊藤さん
    • ツイート数は日本が一番多かったように思う
    • JJUGのコミュニティを紹介する系もよいかもしれない


Q3. JavaOneのスピーカーになるための極意

  • 谷本さん
    • 会社としてでる
    • 事例公開、lambda、jigsawといった単品のものは本家本元がいるので、ノウハウ、パフォーマンスチューニングとかのほうが通りやすいのではないかと思う
  • 伊藤さん
    • 英語については、テクノロジー系だと、用語が英語から来てるので、会話よりはプレゼンのほうが楽(準備もできるので)
  • てらださん
    • JavaOneは文化としてセッション中でも質問くるので、そこは大変
  • 谷本さん
    • プレゼンである程度書いていたら、乗り切れるかも
    • 質問はtwitterでと書いておいて。手を挙げても見ないふりをしたこともあった
  • 伊藤さん
    • チャンスがあったら手が伸ばせる人
    • 臆せず、やってみる人
  • 谷本さん
    • 今自分がやっている仕事が頑張ってれば、おもしろければ、それを話せば良い
    • 事例で、実際に使った痛みがないと相手に伝わらない
    • 大きい会社の事例と、小さい会社の事例だとちょっと違うので、表現の仕方は考える。なんかの箔をつけないといけない、大企業のお客様の事例として話すなど
  • てらださん
    • コンテンツを選んでる側は、コミュニティ参加、講演経験なども考慮されている
  • さくらばさん(場外から)
    • CfPは、締め切りから審査されるわけではなく、随時審査されるので締め切り間際に出すと、落ちる確率が高くなるかも
  • 谷本さん
    • アブストラクトは英語、過去資料、発表動画とかは日本語で出してもOKだった
    • 動画は発表している雰囲気を見ているのではないか
  • てらださん
    • CfPはいくつも出せる、(サムライズムの)ゆうすけさんは4本出していた


Q4. スピーカーになるとこんなメリットがあるか?

  • 伊藤さん
    • スピーカータグをもらえる
  • 谷本さん
    • チケットがタダ
    • 転職しやすくなるかも(会社の顔になるのでなかなか辞めれないが)
  • てらださん
    • スピーカー用の部屋が使える


Q5. 来年JavaOneのスピーカーになりたいと思っている人へ

  • 谷本さん
    • 日本の人はすごい人がいる
    • コミュニティを盛り上げていくことが重要
    • 自分がやることをきっちりやっていれば、世界という舞台もレベルも、実はそんなに遠くない
    • 仕事頑張れ、エンジニアが一番成長するのは普段の仕事であり、その延長線上でアウトプットすることでよりよい形になっていくと思う
    • 周りのも発展させていくし、自分も成長するのでよいと思う
    • Javaも若い人がまた入ってきて平均年齢さがってきてるので、また盛り上げていきたい


(感想)
それぞれ思い思いに話されていたが、3人とも共通するのは、伊藤さんがいっていた、チャンスがあったら手が伸ばせる人、臆せず、やってみる人というスタンスの人だなと思った。
手を伸ばさないと、変わらない、けど今やってる自分の仕事、自分がやることをきっちりやっているという積み重ねも大事。

その行動力、(結果を伴う)信頼性で周りの人ともフィードバックループをつなげていくということかな、自分も少しでも見習っていこう。


2015年9月30日水曜日

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年12月31日水曜日

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年2月14日金曜日

デブサミ 2014 1日目

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

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

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

自分が聞いたセッション(リンクはTogetter)


全体の話

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

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

クラウドや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年12月30日月曜日

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などのサーバ管理ツールをなんとかねじ込みたいですね。数はそんなにないとは言え、似たようなサーバを構築することはそこそこあるのでこのあたりのフローも省力化していきたいです。

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

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

2013年9月10日火曜日

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のほうが親和性がありそう