JJUG CCC 2017 - Spring

Java Libraries You Can’t Afford to Miss

  • Behavior

    • Retrofit
    • Type-safe HTTP client for Android and Java

  • Multi Thread

    • JDeferred

  • Testing

    • JUnitParams
    • WireMock

Better Performance by Kirk Pepperdine

  • JITの監視をするにはJITWatchが有効
  • JITの最適化について話していた
  • jClarity
  • HotSpotの特徴を最大限に活かすには、アルゴリズムの最適化とメソッドをそれぞれ小さくすることなど細かいリファクタリングが必要。

SIプロジェクトでよくあるフレームワークのカスタム開発ってまだ必要なの？ by Hideyuki Fujikawa

  • フレームワークを使うことで、コード量の削減、品質標準化をできる
  • 昔のFWは、単なる家(箱)で、家具(カスタムFW)が必要だった。
  • 最近のFWは、家具付きの家になってきたので、特にカスタムFWは不要になってきたことが増えてきた。ただしどのように使うかはガイドが必要

フレームワークの選定

  • Spring、Java EEが有力
    • Java EEは企業の偉い人に人気、サポートの安心感
    • 開発者に人気、最新技術への対応が早い

どの機能を使うか決める

  • Spring IO Stack
  • Java EE Stack

  • 決めるための質問

    • 利用者は？ 対向システムは？
    • 通信方式、認証方式、リソース種類は？
    • トランザクション戦略は？
    • バッチは？非同期処理は？

  • 実行モジュールも使う機能だけで構成したい

    • Java EE
    • プロファイルの利用
    • アプリケーションサーバー固有のフィーチャー管理機能を利用(Wildfly Swarm、WAS Liberty)
    • Spring
    • Spring BootのAutoconfiguration

何を作るか作らないかを決める

作りすぎないことが重要

  • 昔のFWは機能不足なのでカスタムFWとして機能構築が前提
  • 今のFWは製品提供機能でのみでの実現可否を検討
    • できる場合はガイドやサンプルアプリで提供
    • できない場合は機能構築

まだ作り物が必要になりがちなもの

  • FWが提供する機能

    • アプリケーション実行制御
    • 画面遷移制御
    • 低レベルAPIの隠蔽、抽象化

  • 不足している機能

    • 情報伝播(ユーザー情報、リクエストID)
    • ロギング(操作、監査)
    • 非機能要件

  • どう実装するか

    • アプリを侵略しない、透過的な機能実装
    • FW製品が提供するカスタマイズポイントを利用
    • FW機能を劣化させない
    • 技術変遷をふまえる
    • 同じ轍を踏まない
    • 将来の移植可能性を閉ざさない

技術選定をきちんとすること。 必要だと思ったらきちんと作ること

Java8 コーディングベストプラクティス by きしだなおき

  • 変数への再代入を避ける。 変数は可能な限りfinalで。
    • 再代入がないほが最適化がかかりやすい
  • ImmutableList/Mapを使う。
    • Guavaのライブラリ
    • 並列実行で不具合が起きない
    • ofが便利
  • 論理式を使う
    • ド･モルガンの法則を使う
  • オーバーロードは引数省略のために使う。 処理を集約させる

Java 8

  • forEachのifはfilterにできる
  • forEachでの値変換はmapにできる
  • forEachの入れ子はflatMapにできる
  • Streamで書くメリットとしては、行わえる操作が限定されて読みやすくなること
  • 処理を求められるようなものであれば、Streamを使用しないこと。
  • 例外処理は諦める
    • 例外と関数型プログラミングは相性が悪い
    • あきらめてtry~catchを書く
    • streamを諦めてfor文を使う
  • Optionalは要素1つのStreamだと思えばシンプル。

  • 引数にOptionalを使わない

    • メソッド定義者がnullに対応する
    • フレームワークの入口は除く

  • FunctionalInterfaceを実装したクラスを作らない

  • ラムダでAtomicInteger/Longを使わない。 配列を使う。

Java 7以前

  • LinkedListを使わない。 ほとんどの場合、ArrayListの方が速い。remove、insertの実装がひどい。

オープンソースで会社を起こすには by 川口耕介

ビジネスモデル

  • 一度作れば何度でも売れるが、製品版は作れば勝手に売れるものではない。
  • 売り切り vs 年間サブスクリプション
  • SaaS
    • 運用を請け負う
    • 価値を理解してもらいやすい
    • 顧客の個別事情に対応しなければならないという罠
  • サポート
    • 知識のある技術者が障害や質問に対応。
    • 大企業ほど価値を認めてくれる。
    • 知識のある技術者を雇わないといけない。
  • コミュニティから人を雇う
    • 優秀な雇うべき人を探すのは簡単
    • 働き方も癖も性格も分かっている
    • 開発者の中に葛藤を生むことがある
    • プロジェクトの開発者が目減りする
    • プロジェクトを横取りしようとしていると映る危険性
  • プロジェクトとのやりとり
    • オープンソースコミュニティを知らない人にやりとりをさせない
    • 会社としての意見を事前に統一しておく

開発手法

  • Red Hat流の｢上流参加方式｣がベスト
    • プロジェクトのリポジトリに直接コミット
    • プロジェクトのバグトラッカーでタスク管理
    • プロジェクトと同じレビューマージ方式を採用
  • とは言え、難しい事情もある
    • エンタープライズ版と雪像する部分がある
    • お客さん絡みのコメント

商標、法律関係

  • ブランド･商標･法律関係
    • ｢Xの会社｣と思われるのは大事
  • 商標は誰のもの？
    • 商標の所有権を誰が持っているかを明らかにしておく
  • 使ったり元にしたコードのライセンスを遵守する

なぜそこまでするのか

  • プロプライエタリの方が儲かる。
    • Apple, Facebook, Oracle
  • オープンソースの会社は儲からない。
  • オープンソースは無双。
    • 文句なしに優れた開発手法。
    • ニーズに根ざした開発
    • 柔軟性
    • 品質
    • より多くの組織がオープンソースの価値を理解して取り入れている
    • オープンソースの視野の広さ=より大きな潜在市場

大きな問題を解決したい

  • 多くの人の力を結集して初めてできることができる
    • ex. Linuxのファイルシステム
  • Blue Ocean
    • Jenkins用の新しいUI

プロジェクトの得るもの

  • 開発者以外のスキルセット
    • デザイナー
    • テクニカルライター
    • イベント
  • 企業の参加で初めて得られるリーチがある
    • 他の企業の参加も促せる
    • ex. Linus個人のプロジェクト vs Red Hatのプロジェクト

霞を食って生きていけるのは仙人だけ

  • オープンソース、みんなの時間はとても貴重

Q&A

  • コミュニティからのコントリビュートをどう見逃さないようにするか by Elastic 大谷さん
    • 熱意で支えている。組織としての課題となっている。
    • Elasticは毎週金曜日に確認している。 とりこぼしがないかを見ている。 GitHubのissue機能を確認する
  • Apacheのように各社が支えているものとの違いは何か
    • NPOのような団体のほうが健全な思いはある。
  • 営業の工夫は？
    • Jenkins社に名称変更したいができない。 Webinar等をすることでユーザーに覚えてもらう
    • 川口さんがいる会社としてのアピール