ページ

2015年11月29日

JJUG CCC 2015 Fallに参加してきました

Javaのコミュニティカンファレンスに参加してきたのでメモを投稿。ちゃんとまとめるつもりはあまりないけど、あとで公開されたスライドへのリンクも追加する。

JJUG CCC 2015 Fall
http://www.java-users.jp/?page_id=2056

keynote-1 基調講演1 : Javaは守りに入らない、これが今のJavaだ

by 谷本 心(日本Javaユーザーグループ)
10:00-11:00
#ccc_keynote1

Kids are Future.
Javaを子供向けに教える。教育に利用する。

そろそろ他の言語に行こうと思っていたが、やっぱりJavaから離れられなかった。
Spring Boot

keynote-2 基調講演2:Java EE 8 – Work in Progress

by David Delabassee(Oracle Corporation)
11:00-12:00
#ccc_keynote2

進捗がいいもの
WEB層の拡張 (HTML5 Support/ Web Tier Enhancements)
JSON Binding (JSONB)
JSON Processing (JSON-P) enhancements
Server-sent events (SSE)
Action-based MVC
HTTP/2 support

Survey: https://blogs.oracle.com/ldemichiel/entry/results_from_the_java_ee

JSON-P 1.1
JsonPointer…JSONの要素へのポインタオブジェクト
immutableになってる

SSE
JAX-RSを活用していく
ストリームを使う例
@Produces("text/event-stream")

MVC
Java EE 8ではAction-based MVCを提供する (Struts2やSpringのようなアプリケーションでコントローラを実装するMVC)
今まで通りJSFのようなComponent-based MVCも提供し続ける
Model層、View層は既存の資産を利用すれば良いが、Controller層については議論された。結局JAX-RSを使うことになり、それがいい方法であった。

Controller用の新しいアノテーション
@Controller…メソッドに付与してコントローラであることをフレームワークに知らせる

HTTP/2サポート
Servlet 4.0による
ほとんどの開発者にとっては今まで通りの使い方でHTTP/2対応ができる

感想
早くJava EE 8出てほしい。

AB-1 「jOOQ と Flyway で立ち向かう、自社サービスの保守運用」

by 池田 裕介(株式会社サイバーエージェント)
13:00-13:50
#ccc_ab1

DBスキーマのバージョン管理
チーム開発実践入門にも書かれてる

Flyway…DBマイグレーションツール
mavenやgradleでビルドできるようにするといい

ファイル名のバージョンは連番ではなくタイムスタンプにすると良い
マージしたときに衝突しない
outOfOrderオプションを使うことで過去のバージョンも適用できる

JOOQ
すでに存在するDBを重視
ドキュメントやチュートリアル、サンプルコードが充実している
fetch()から結果をCSV, XML, HTML, FormatedText フォーマットで出力が可能

感想
JOOQ便利そうだし可読性もすごくいいけど、JPAにあるようなentity cacheやprepared statement cacheの機能があるのかどうか。
またJPAでも、Criteria APIの可読性が低いと思ったらJPQLを使えば良いのでは。要調査。

回答を発表者から頂けた。


EF-2 How to speed up your application using JCache[通訳有]

by gregrluck
14:00-14:50
#ccc_ef2

データを2回以上参照するなら、キャッシュを使う
データベースアクセスだけでなく、データの生成など

アムダールの法則 (amdahl's law)

Cache効率(キャッシュのヒット率)

何をキャッシュにつめるか
参照データ(郵便番号など)
長期間存在するデータ
よく使われるデータ
よく変化するデータについては考慮する

メソッド
get, put, putAndGet

JSR107 annotations

感想
JCacheのセッションすごく面白かった。キャッシュのイントロダクションが長かったかも。通訳しながらなので仕方ないけど、JCacheの設計方針や実装についてもっと詳しく話を聞きたかった。

GH-3 マイクロサービスアーキテクチャ – アーキテクチャ設計の歴史を背景に

by 鈴木 雄介
15:00-15:50
#ccc_gh3

時代の変化
メインフレーム→クラサバ→ウェブ

クラウドの時代(過渡期)
サーバーの処理能力が超巨大化
巨大なサービスをどのように変化させていくか

カナリアリリース(ブルー・グリーンデプロイ)
新バージョンをリリースして稼働させたサーバー群に、全体のアクセスのうち少量だけ流すことで、システム全体を停止することなくリリース時の不具合を検知することが出来る

ダークカナリアリリース (test-in-prod)
LBから新バージョンにアクセスできるのは開発者のみ
モチベーション:ステージングではなく本番でテストしたい
→連携するシステムとの整合性が取れているかは本番環境でなければわからない

Chaos Monkey
Netflixの事例

巨大なサービスをいかに管理するか
→マイクロサービスアーキテクチャ (MSA) に分割

広義には、粒度ではなく関係性に注目を
重要なのはサービス相互の関係性のあり方
- 複雑なものを、いかに管理するのか

巨大なサービスはトップダウンに管理できない
技術面:分散配置と統合
組織面:持続性と分権
ボトムアップでもうまくいかない
あるルールのもとで多様性を保証する
→プラットフォームを利用する

サービスの分割
モジュール分割の基本は「時間軸の中で変化するスピードの違いの境目」で切る

プラットフォームとは
巨大なサービスを管理するための基盤

GH-4 GS CollectionsからEclipse Collectionsへ - 機能豊富なオープンソースJavaコレクションフレームワーク

by 伊藤 博志(ゴールドマン・サックス)
16:00-16:50
#ccc_gh4

スライド:http://www.goldmansachs.com/gs-collections/documents/2015-11-28_JJUG_CCC.pdf

JavaOne 2014で発表して以降、人気急上昇中

開発者としてはかなり自信があり、Java標準のコレクションに採用されても遜色がないと考えている

ファクトリーメソッドが用意されてる mutable/immutable
より簡潔に書ける
より多くのケースでメソッド参照を活用できる
より高い可読性で記述できる
再利用が可能
メモリ効率が良い

SortedBag
キーに対して、キーのaddされた回数を保持する

shuffleThis
リストの要素の順番をランダムに入れ替える

zip
リストとリストを組み合わせてペアのリストにする

chunk
コレクションの分割処理

集合演算
intersect, union, difference, symmetricDifference (XOR)

CharAdapter
文字列のコレクションから、数字のみ抽出して別の文字列コレクション

GS Collections Kata
https://github.com/goldmansachs/gs-collections-kata
ユニットテストをひとつずつパスしていくTDD型トレーニングマテリアル

感想
GuavaやApache Commonsのコレクションで良くない?って思ってたけど、Eclipse Collection使おうと思えた。すごい。

EF-5 これからのコンピューティングの変化とJava

by きしだなおき
17:00-17:50
#ccc_ef5

処理を早くするには
並列度を上げる
より近いところにデータを置く(キャッシュ)

データ・セントリック・システム
データの近くで処理(Hadoop等)

ノイマン型アーキテクチャ
CPU…OSが実行できる
GPU

非ノイマン型アーキテクチャ
ノイマン型じゃない
FPGA, ニューラルネット型コンピュータ、量子コンピュータ
2,3つ目は今のところプログラム可能ではない

FPGA
命令をメモリから読み込む必要がない
データを流すだけで回路が処理をしてくれる

JavaでCPU
Streamで並列処理

JavaでGPU
Aparapi…JavaコードをOpenCLに変換・楽だがGPUの性能を出しにくい
OpenCL…JOCLとかある・ちょっと面倒だけどGPUの性能を出せる
Project Sumatra…Stream処理を自動的にGPUで行う(今年5月で開発終了)

ディープラーニングで処理が速くなる

JavaでFPGA
Synthesijer…FPGA用のコードを自動生成してくれる

今のままのJavaで足りるのか
オブジェクトのメモリ効率が悪い
さまざまなアーキテクチャに対応した値が扱えない
- 256bit整数型、floatx4型(SIMD命令用)
高機能データ構造がメモリにやさしくない
- Genericsが基本型を扱えない
配列がハードウェアにやさしくない

ハードウェアに近付く (Close to the Metal)
sun.misc.Unsafe
並列化プリミティブとかシリアライズとかメモリ管理とかJVMとのやりとりができる
Cassandra, Ehcache, HBase, Hadoop, Hibernate, JRuby, Netty等の製品が使ってる
Java9でメンテナンス停止(仕様凍結)
Java $N-1で完全置き換え、Deprecate
Java $Nで廃止
Unsafeの代替は仕様策定中

Project Valhalla
ユーザー定義基本型
ValueType…nullを持たず、参照ではなくデータを格納する
ハードウェアに近いコードが書けるようになっていく

コンピュータは変わる
Javaも変わる
あなたは?

ふと思ったこと

2014年8月18日

Mac OS X 10.9の初期セットアップ覚え書き

バージョン

  • Mac OS X 10.9.4

システム環境設定

  • トラックパッド・ジェスチャの設定
    • システム環境設定 --> トラックパッド
  • Spotlightのキーボードショートカットを [⌘+Space] に変更
    • システム環境設定 --> キーボード --> ショートカット --> Spotlight
  • スリープ開始5秒後にパスワードを要求
    • システム環境設定 --> セキュリティとプライバシー --> 一般

基本的にインストールするもの

  • FIrefox
  • Google Chrome
  • Evernote (App Store)

開発用にインストールするもの

  • XCode (App Store)
  • iTerm2
  • CotEditor
  • Emacs for Mac OS X
  • Eclipse
  • Intellij IDEA 13
  • SourceTree (Git)
  • MySQL Workbench
  • Sequel Pro (MySQLクライアント)

フォント


2014年4月23日

[Jenkins] 選択肢からGitのブランチを選んでJenkinsビルドできるようにする方法

ビルドする度に毎回、Jenkinsの設定でビルド対象のブランチを変更するのがめんどくさい。


こんな感じで、ビルドボタンを押したあと、ブランチ一覧が出てきて、それを選択して指定できたら便利だなあ…。
ブランチ一覧も、Gitリポジトリから自動的に生成できたらいいなあ…。

ということでJenkinsの環境を整えた。

以下、Gitで管理されたプロジェクトをJenkinsでビルドするとき、リモートリポジトリ(中央リポジトリ)から動的にブランチ一覧を生成し、一覧からブランチを指定してビルドする方法です。

やりたいこと

  • ビルドボタンを押したあと、どのブランチでビルドするか選びたい
  • ブランチ一覧はGitリポジトリから自動的に生成したい

前提

  • Git pluginを使って、Gitプロジェクトのビルドができる

使ったプラグイン

似た名前のプラグインで、Extensible Choice Parameter pluginというものがあるので注意。こちらも便利だけど、本題から外れるので紹介しない。

1-1. ブランチ一覧ファイルのフォーマット

以下のようなフォーマットでブランチ一覧ファイルを生成することで、ビルド時に選択肢として使用することができる。

フォーマットは次のようになっている:
  • 一行は次のように構成される
    • キー名 = [カンマ区切りで要素を羅列]
  • 右辺の要素が選択肢を構成する
  • 左辺のキー名は、選択肢を呼び出すときに使用する

1-2. ブランチ一覧ファイルの生成

肝心のブランチ一覧ファイルは `git ls-remote` コマンドを使用してブランチ一覧を取得し、 `sed` と `tr` で加工して生成する。

本題から外れるので、各コマンドの説明は省略する。

このコマンドをJenkinsのジョブで「定期的に実行」させておく。別に定期的に実行でなくてもいいけど、定期的に実行することで、意識せずにブランチ一覧を最新状態に保てる。

自分のチームの場合、スケジュールは `H/15 10-21 * * 1-5` としている。(月-金曜日の10-21時台で、15分ごとに実行)

2-1. ビルド時に選択肢を提供する

ブランチ一覧ファイルが生成できたら、これをExtended Choice Parameter Plug-Inで利用する。
  1. ビルドのパラメータ化にチェックを入れる
  2. パラメータの追加からExtended Choice Parameterを選択
  3. Name, Property File, Property Keyを適切に入力する
    このとき、Nameはビルド時に環境変数として利用できる

  • Property Fileは、ブランチ一覧ファイルのパスを指定する
  • Property Keyは、ブランチ一覧ファイルの中のキー名を指定する
    ここでどの選択肢を使用するか指定できる
  • Nameは何でもいい

2-2. 選択肢に応じてビルドするブランチを変える

続いてGit Pluginの方を設定する。

GitのBranches to buildの項目に、Extended Choice Parameterで指定したNameを入力する。例えば `${target_branch}` のように入力する。

これで全ての設定は完了。

ビルドすると次のように選択肢が現れ、どのブランチをビルドするか選べるようになる。



補足

`hotfix/~` とか `feature/~` を表示したくないって場合は、ブランチ一覧ファイルを生成する段階で、適当に `grep -v` したりして除外してください。

うちのプロジェクトでは、リモート上の不要なブランチは随時削除しているので全て表示しても問題ない感じです。

2014年1月23日

自分のためのrbenvまとめ

rbenvの使い方の覚え書き

1. Homebrewを使ったrbenvのインストール

Homebrewを使ってインストールする。 .bash_profileに以下を追記する。

2. rbenvを使ったrubyのインストール

インストール可能なrubyバージョンを調べる rubyをインストールする

3. rbenvの操作

インストール済みのrubyを表示(*が付いてるやつが今適用されてるversion) 使用するrubyのバージョンを変更する 現在のディレクトリだけrubyのバージョンを変える gemの操作 bundlerの操作

参考

2013年12月12日

新規開発するときに整えたい開発体制


新規じゃなくてもいいけど、こうだったらいいなという願望。
  • バージョン管理を徹底する
  • masterブランチはいつでもリリース可能に
  • バッチはJenkinsに集約
  • テスト駆動開発(単にテストを書くということではなく、テストが開発を駆動していること)
  • 感覚ではなく事実を信じる(計測する)
  • 全てのビュー改修・文言修正にはA/Bテストを
  • 短期的な利益を捨てても長期的な利益を取りにいく
  • 管理ツールも使いやすく(運用コストを減らし、運用ミスの発生確率を下げる)

2013年12月8日

アジャイルサムライベースキャンプに参加して

Agile Samurai Base Campっていうイベントに参加してきました。

http://www.agilesamuraibasecamp.org/

角谷氏の基調講演から始まって、インセプションデッキとテスト駆動開発の2グループに分かれてセッションが行われました。

講演者の一人である和田卓人氏は、以前ペアプロをしてもらったこともあり、もう一度お話を聞きたかったので、今回のイベントに参加しました。というわけで自分自身はテスト駆動開発のセッションに参加しました。

和田さんのお話

冒頭は、まず目標を考え、それを示すテストを書き、red --> green --> refactoringのサイクルを回しましょう(黄金の回転)という、いつものお話から始まりました。

印象に残ったのは
  • 「複数を相手にしない。一人ずつ対処する。」(五輪書)
  • いきなり全てのテストを書いてRedだらけにしない
  • TODOリストから一つのタスクを引っ張ってきて、テストを書く
    • 一つずつテストをひっぱってきて、黄金の回転ですばやく倒す
という話でした。この話をする前に、大きなタスクは小さく分解して、「一つずつ少しずつ段を小さく」というお話をされていたけど、具体的に言われると、やりがちなので注意しようと思いました。

テストを書くのは不安を取り除くためというのは、ペアプロをしてくださったときに何度も言われていたけど、今回も強調していっていたのでやはり重要なのだなあと再確認できました。実際にテストを書いて進めてたときは、気持ちが楽だったし。

また、あるリリース済みの機能の仕様変更が来た場合、テストコードの変更が大量に発生してしまう場合はどうしたらいいですか?という質問をしました。

当たり前のことだけど、仕様変更が大きければテストコードの変更が多くなるのは当然のことで、その変更をできるだけ少なくするためにはテストフレームワークをカスタマイズする等して対応すると良いとのことでした。

ただ、テストフレームワークのカスタマイズって、どのレイヤーの話だ?もうちょっと掘り下げて質問すれば良かったけど、自分の技量ではまだ理解できないと思ったのでやめといた。

テスト駆動開発の事例の話

ここで印象に残ったのは、レガシーコードのTDDの話。これは、自分の環境にも近いものがあり、参考になりました。

また、TDDしてるプロジェクトのソースコードレビューの観点を質問したが、テストコードをよく見るとのことでした。
  • テストが小さな粒度に分解されているか
  • 一つのテストケースで複数のアサーションが入っていないか
テストコード以外の部分は、普通のレビューと同じらしいです。

まとめ

朝9:30からのイベントだったので、結構疲れた。

多くの講演者の方々が、一人でも始められるとおっしゃっていたので、がんばってみようと思う。和田さんにも久しぶりにお会いできて、やる気でました。

明日からまた塹壕に帰ります。がんばるぞー!

2013年11月12日

Mac OS X 10.8の初期セットアップ覚え書き

バージョン

  • Mac OS X 10.8.5

システム設定

  • Spotlightのキーボードショートカットを [⌘+Space] に変更
    • システム環境設定 --> キーボード --> キーボードショートカット --> Spotlight
  • スリープ開始5秒後にパスワードを要求
    • システム環境設定 --> セキュリティとプライバシー --> 一般

基本的にインストールするもの

  • FIrefox
  • Google Chrome
  • Thunderbird
  • Skype
  • Evernote (App Store)
  • XtraFinder

開発用にインストールするもの

  • XCode (App Store)
  • iTerm2
  • CotEditor
  • Emacs for Mac OS X
  • Eclipse
  • Git
  • MySQL

フォント

Related Posts Plugin for WordPress, Blogger...