最年少 DataSpider 技術者の誕生！ IoTとセンサーとAPIのごった煮ハッカソン参加レポート（前編）
皆さん、はじめまして。東海・関西地区担当の築山と申します。営業マンのクセにでしゃばってエンジニアブログに進出してきました。
10月29,30日に Mashup Awards 名古屋ハッカソン「IoTとセンサーとAPIのごった煮ハッカソン」にサポート企業として参加してきました。客観的なレポートは事務局の方にお任せするとして、私からは主観たっぷりのレポートをお送りします。
Mashup Awards とは
Mashup Awards は賞金総額「500万円」と日本最大級のハッカソンイベントでして、アプレッソは昨年よりスポンサーをさせていただいております。
各地区の予選やWebでの審査を経て 12月17日に決勝を目指します。今回の名古屋ハッカソンはその一次予選も兼ねたハッカソンイベントとなります。
では、早速レポートに移ります。
開会～チームビルディングまで
オープニング
今回は事前申し込み24名の参加者に加えて、API、デバイス、ソフトウェアなどを提供するサポート企業が7社と大盛況。
サポート企業の机の上には様々なデバイスが並んでいるのですが・・・・
ん！？ これは・・・何故ラケット？？
ラケットのことが気になりつつも、いつもの通り伴野さん、まなみんの仕切りで始まります。
「Mashup」とは元々「複数の音楽を組み合わせる音楽の手法」で、Mashup Awards も様々な API やサービスを組み合わせることにより多くの賞を狙うことができるイベントとなっています。
様々なデータを連携することが得意な DataSpider とは非常に相性に良いイベントです。
インプットタイム
続いてインプットタイムです。各企業が参加者の方に自社のサービスを紹介します。 ここで魅力的だと感じて貰えた企業はたくさんのチームでハッカソンに採用してもらえるので、大事なアピールタイムとなります。
↑トップバッターはサイボウズの北川さん。kintone の紹介です。
↑ヤフーの清土さんからは myThings と myThings Developers
↑気になっていたラケットは SONY さんの持ち物でした。
デバイスをセットすることで、スイング速度、角度などの情報が得られます。
これを使ってどんな作品が出来上がるのか楽しみですね。
私からも DataSpider + Thunderbus の紹介をさせていただいたのですが、
エンタープライズの用途で使われていることをお話しても伝わりづらいので、
過去のハッカソンの制作事例を中心に紹介させていただきました。
↑大垣ハッカソンの最優秀賞作品 Bar Sota です。
アイデアソン＆チームビルディング
各社のサービスを頭に入れた状態でアイデアソンに移ります。
このようなアイデアシートを用いて、頭のなかにあるものを発散させていきます。
その後、アイデアを絵に変えていき、様々な人と会話してチームを作っていきます。
↑「通称：ナンパタイム」の風景
ランチタイム
アイデアソンを終え、チームができたところでお昼休憩です。
今回のハッカソン会場は名古屋工業大学をお借りしているのですが、お昼は学食にお邪魔します。
安い！
ハッキングタイム
お腹いっぱいになったところでお待ちかねのハッキングタイムです。我々サポート企業はアイデアソンの内容を聞いて、自社のサービスを使っていただけそうなチームのお手伝いに行きます。
最年少 DataSpider 技術者の誕生
ハッキングタイムが始まって早々に私に声をかけてくれたのが、なんと中学1年生の子。お父さんと一緒に参加しているのですが、「DataSpider を使ってみたい！」と言うことでお手伝いさせていただくこととなりました。
DataSpider で「スクリプト」と呼ばれる処理を作っていくのですが、どうやら API などの言葉もあまり知っていなかったようなので・・・
その場にあったホワイトボードを借りて授業が始まります。
やりたいことを聞きながら整理すると、マイクで拾った情報を元に mbed というデバイスがデータの送信元になります。DataSpider では mbed から送られてくるデータを受け取って、kintone へのレコード登録、雑談対話 API へのデータ送受信、Twitter 書き込みを DataSpider で実装する必要がありそうです。
随分とやることが盛り沢山で、この時点での私の気持ちは「完成しなくても DataSpider を使って楽しんで貰えればいいかな」という気持ちでした。
どうやら、ソフトウェアのインストールも初めてだったようなので、まずは DataSpider のインストールから一緒に進めていきます。（続く）
他チームの様子
ふと、周りに目を向けてみると・・・サポート企業に相談しながら皆様黙々と作業されています。
今回のテーマは IoT ですので、こんな作業も当然あります。
え！？えーと・・・それは「鍬（クワ）」ですよね？？これは完成が楽しみです。
長くなってしまったので、後半に続きます。
APIStudy#1が開催されました
こんにちは。そしてはじめまして、アプレッソ技術部の對馬です。
いつもはDataSpider Technical Networkでブログを書いているのですが、今回はブログ内容の関係でエンジニアブログにお邪魔することになりました。 もしかしたらこれからもたまにお邪魔して、ちょろっと書いていくこともあるかもしれません。 よろしくお願いします。
さて、エンジニアブログにお邪魔して何を書くかと言いますと！ この間、とある勉強会のお手伝いをさせていただきましたので、その勉強会の様子をご紹介しようと思います。
その勉強会とは…ずばり…「APIStudy」！！
APIStudyでは「APIのベストプラクティスを考えていく」ことを目的とし、APIを利用する人や提供する人に参加していただき、お互いにとって最適なAPI設計につながることを目指す勉強会です。
そして記念すべき第1回目が、10月13日(木)にサイボウズ株式会社 東京オフィスにて開催されました。 初回ということで「発散」のテーマのもと、まずは参加者が日ごろ感じているAPIへの熱い思いをぶつけ合って、APIのどこが好きか、どこを改善したいか、どこについて話し合いたいかなど、それぞれの思いを明確にしました。
オープニング＆インプット
まずはアプレッソ 脇野からAPIStudyの概要説明ののち、3名からAPIに関するLTがありました。
サイボウズ 後迫さんから「経験から学ぶkintone API」
kintone APIの歴史や、どのような目的で提供しているのか。kintone APIの貴重なお話でした！
ケンブリッジ・テクノロジー・パートナーズ 市川さんから、「オープンデータのAPI利用と開発について」
オープンデータを使うときにあるあるな悩みについて…、利用・開発する側のご意見を話していただきました！
Misoca 松本さんから「MISOCA API V3の開発するにあたって」
名古屋から来てくださいましたー！
MISOCA API V3になるまでの奮闘したことのご紹介や、APIについて気になる点を提示していただきました。
余談
ちなみに私はAPIについて全くと言っていいほど知識がないです。
なのでLTで一番熱くなったのは、市川さんのLT内で「ラブライブ！サンシャイン‼」という単語が出てきたときでした。
※ラブライブ！サンシャイン‼は静岡県沼津市が舞台となっているスクールアイドルの青春アニメです。※
そんな私ですが、3名のLTから APIに対する熱い思いが伝わってきて、「APIって実は相当面白いことなんじゃないか！？この勉強会は楽しくなるんじゃないか！？」とワクワクしだしました。
ブレインストーミング＆チームビルディング
LTが終わると勉強会の本題、「発散タイム」です。
まずは参加者の皆さんに「API」で思いつくキーワードを挙げてもらいます。
▲キーワードを書き出します
APIへの思いを出し切った後は、参加者全員分のキーワードをカテゴリ分けしていきます。
「エラーについて」「ドキュメントについて」の困った体験のカテゴリや、勉強についてのカテゴリ、セキュリティについて語りたい！というものなど、たくさんの人がいる分、キーワードもカテゴリも多様です。
そして自分が興味のあるカテゴリについて深堀するため、カテゴリ別にチームを作ります。
テーマの深堀＆発表
チームができたら、そのカテゴリについてチーム内で語ります。
こういう困ったことあるよね、皆さんはどうしていますか？など、今まで溜まりに溜まっていたAPIへの思いを吐き出します。
真剣にディスカッションをしながら「あるあるネタ」で笑いあうなど、皆さんがとても楽しそうで、勉強会が始まってすぐの「ワクワク」は当たっていたんだなぁと、何だか嬉しくなりました。
そして最後は、チーム内で話し合ったことを全体と共有します。
Documentチーム
作るの大変！化石化しちゃう！など様々なAPIのドキュメントについての問題の解決策を話し合っていました。
設計・Versionチーム
いけてるWebAPIとは何か！？について話し合っていました。
あるある話
kintoneについて物申したかったけど、もはやkintoneAPIだけではおさまらなかった全体的な「APIのあるある」について発表していました。
おわり
参加者の皆さんの反応が気になりすぎた初回でしたが、皆さん楽しんでいただけたようで何よりでした。 APIについて、こんなに注目した勉強会というのも、なかなかないのでは…。 そしてアウトプットをメインとした内容だったので、そういった意味でも充実感があった、という意見もいただきました。
皆さん、ご参加ありがとうございました！！！
そしてそして！！！
なんと既にAPIStudy #2が開催決定しております！！ ありがとうございます！
少しでも気になった方は、上記ページからお気軽にお申込みください！
是非一緒にAPIのベストプラクティスを考え、盛り上げていきましょう！
アジャイル開発になったらQA担当者はどうなるの？ 〜「実践アジャイルテスト」で学んだこと〜 その4
こんにちは、品質マネジメント部の磯です！
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその4になります。
前回は「テスト自動化の阻害要因」について書きました。
今回は「アジャイルテストの自動化戦略」について学んだことをいくつかピックアップしてきます。
テスト自動化のピラミッド
(P274 14.1.2 「テスト自動化のピラミッド」より)
上記の図はテスト自動化における範囲や容易性などを示した図になります。
下に行くほど容易かつ広範囲をカバーすることができます。下から順に説明していきます。
単体テスト/コンポーネントテスト
- チームを支援する技術面のテスト（第1象限）
- 一般にxUnit系のツールを用いて、対象システムと同言語で記述される
- 高速で安価に記述できる(高ROI)
受入テスト（APIレイヤー）
- チームを支援するビジネス面のテスト（第2象限）
- 「正しいものを作ったか？」を確かめる為、機能テストやストーリテストなどが含まれる
- 単体テストに比べて大規模な機能の集合をカバーする
GUIテスト
- 頻繁に変更が入る可能性が高い
- 実行に時間がかかる
- 低いROI
手動テスト
- ビジネス面について批評するテスト（第3象限）
- 人間の手と目によって実施されるべき
- ユーザビリティテストなど
テスト自動化を検討するにあたってはこのピラミッドに当てはめて考えるとよいとしています。 テスターがまず取り掛かりそうなGUIテストの自動化は実のところ投資対効果があまり高くありません。 それは頻繁な仕様変更や実行そのものにかかる時間などからです。
また、ビジネス面について批評するテストは人間の手と目によって実施されるべきものです。自動化ではその価値が計れません。
何を自動化できるのか, 何を自動化するべきでないのか
（P277 14.2 「何を自動化できるか？」, P283 14.3 「何を自動化するべきでないか？」より）
上記の通り、開発工程の中で自動化できそうなものがあげられています。ここでは機能的な側面のテスト以外にも、定型的な繰り返し作業、たとえばテストの結果レポートをメールするといった作業についても自動化 候補として検討することが推奨されています。こういった周辺作業についても自動化を進めることによって、本来注力すべき作業の生産性もあがりそうです。
また、候補外とされているものについては、人間による批評が必要なもの、ROIが著しく低いと思われるものが含まれています。失敗する可能性がほぼないテスト（「絶対に失敗しないテスト」とありますが、「絶対」はありえません。念のため！）や1回限りのテストについて自動化することは、大きな無駄となってしまいます。
自動化の戦略を立てる---どこから始めるべきか？
（P287 14.5 「自動化の戦略を立てる---どこから始めるべきか？」より）
戦略を立てるにあたっては、冒頭の「テスト自動化のピラミッド」を参考にします。ピラミッドは下層にいくほどROIが高くなります。一方でビジネス面のテストを考えると上層にいく顧客が求める機能が実装されているか、状況が理解しやすくなります。
最下層のテストを充実させつつ、いくつかのテストケースにおいては手動で確認するようにするなど、目的に合わせて優先順位をつけていくことが重要と考えます。
テスト自動化にアジャイルの原則を適用する
（P297 14.6 「テスト自動化にアジャイルの原則を適用する」より）
テストの自動化においてもアジャイルの原則を適用して、その価値を利用していくことができます。テストの設計やスコープをシンプルに保つことが必要になります。これは様々な変化に対してテストが追従していくうえで重要な思想と考えます。また反復的なフィードバックも大きな効果をもたらします。よりよい自動化の方法やテストシナリオを検討してフィードバックしていくことが大切です。しかしここで忘れたくないのはROIを意識することです。全てをやり直すとなっては、今までかけた時間が無駄になってしまう可能性があります。顧客へ価値を届ける為に何が優先されるべきかをしっかり考えることが必要と思います。
また、チーム全体のアプローチはテスト自動化においても重要な考え方としています。テスタビリティが十分に考慮された実装となるように、プログラマやテスター、その他のチームメンバーが協力することで、複数の観点やスキルセットが得られます。チーム全体で助け合うことによって前進する勇気や自信が高まります。（いいですね！）
まとめ
今回は「アジャイルテストの自動化戦略」について学んだことをアウトプットしました。 まとめると...
- 「テスト自動化のピラミッド」を利用して、注力すべきポイントを検討する
- 開発にあたって自動化可能なもの（プロジェクト進行における定型業務含む）、自動化すべきでないもの（人間による批評が必要なもの、ROIが著しく低いもの）を考える
- 自動化に対してもアジャイルの原則を適用する
となります。またそれぞれROIをしっかり意識して検討/実施していくことが重要ですね！
次回予告
次回はすこし飛んで第18章「コーディングとテスト」についてアウトプットしていきたいと思います。
ではまた！
アジャイル開発になったらQA担当者はどうなるの？ 〜「実践アジャイルテスト」で学んだこと〜 その3
こんにちは、品質マネジメント部の磯です！
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその3になります。
前回は「アジャイルテストの4象限」について書きました。
今回は「テスト自動化の阻害要因」についてです。 自動化というとQA/テストエンジニアとって、実現すればあらゆる苦行から救ってくれる魔法のように思えてしまいますが、果たして実際のところはどうでしょうか。 どういった効能があり、どういった阻害要因があるのかについて、学んだことをアウトプットしていきます。
では、そもそもなぜ自動化する必要があるのか？という点から始めたいと思います。
なぜ自動化するのか？
本節にでは自動化する理由が8つ挙げられています。
- 手動のテストは時間がかかりすぎる。
- 手作業は間違いを起こしやすい。
- 自動化は人々を自由にし最高の仕事を行えるようにする。
- 自動化されたリグレッションテストはセーフティネットを提供する。
- 自動化されたテストはより早く頻繁にフィードバックを与えることができる。
- コーディングをこれまで以上にできるようにするためのテストと例。
- テストが文書化を提供してくれる。
- 自動化は投資上の十分な見返りがある。
（P256 13.1 「なぜ自動化するのか？」より）
ふむふむ、自動化を試みようとするエンジニアは大半が上記のようなことが「できたらいいな！」と思うのではないでしょうか。（しかしながら、いささか多くを求めすぎでは・・という危惧も抱きます。）
気になったものについてピックアップしてみます。
- テストが文書化を提供してくれる。
静的な文書を最新の状態に保つことは難しいことです。しかし、もしシステムが変更された際に、自動化されたテストを更新しなければ、テストは失敗します。私たちは、ビルドプロセスを「グリーン」に保つために、それらを更新しなければなりません。自動化されたテスト>は常に、私たちのコードがどのように動作するかを正確に書いたものであるということを意味します。
（P262 13.1.7 「テストは偉大な文書化である」より）
これはテストケース自体が仕様書になるといっているのだと思いますが、この考えは絵に描いた餅になりがち・・・。新鮮な状態に保ち続けるのはなかなか難しいと思います。 テスト対象の規模や歴史が積みあがってくるごとに増していく自動テストケース。重複するコードを共通化してシンプルにするも、新たな機能に対応していくうちにどんどんとメンテが困難になってしまう、なんてことは自動化あるあるではないでしょうか。
さて、自動化するにあたっていろいろな心配事が湧き上がってくると思います。これらは「自動化を妨げる障害」として著者の経験が纏められています。
自動化を妨げる障害
- プログラマの姿勢
- 痛みのこぶ
- 初期投資
- 常に変化するコード
- レガシーシステム
- 恐れ
- 古い習慣
（P263 13.2.2 「私たちのリスト」より）
これらについては一つずつ見ていきたいと思います。
プログラマの姿勢
ここではプログラマの姿勢について論じられています。
従来的なチーム編成ではDEVチームQAチームといった具合に別個の組織として存在しており、DEVチームは機能テストの自動化についてまったく考えたことがないでしょうと言っています。 アジャイルな体制においてはDEV, QAといった役割を超え、一体的な体制で開発していくことが良しとされているため、そのような意識では困りますよ！ということです。
また、自動化用のコードを実装する場合にはDEVよりの経験が必要となるため、プログラマにもQAレイヤーでのテストに対して積極的な姿勢が必要です。
痛みのこぶ
（特にテスト自動化に限ったことではありませんが）初期段階においては多くの時間がかかります。 これを時間に対する作業量のグラフとしたとき、ポコッとこぶがあるような見た目になります。
この状態を乗り越えるには適切な指導やマネジメント層の支援も必要となってきます。適切な指導/支援が受けられる環境であれば、組織としてテスト自動化への積極的な取り組みが行われているように思えますね。こぶも小さなものとなりそうです。
初期投資
自動化を始めるに当たってはどのような技術を使って実現するのか、十分な検討が必要となります。
自前で作ったものをフレームワークを使用するのか、すでにあるものを使うのかどうか。 高価なソフトウェアを導入しても、実現したいことに対してはオーバースペックである可能性もあります。
十分に評価できる時間（つまりはお金ですね！）を事前に投資できるとよりよい成果をうみだせるのではないでしょうか。
常に変化するコード
GUIに対しての自動化は困難を伴うと予測されます。なぜなら頻繁な変更がおこなわれ、その都度追従していくのは多くの手間がかかってしまうからです。
このような状況を改善していくにはプログラマとテスターの協調関係をより強めることが必要といっています。頻繁に変更が行われたとしても、機能としての意図は大きく変わらないはずなので、そこに着目してテストを編成していくのがよいとしています。
たとえば何らかの計算をする機能であれば、適合するテストデータをあらかじめ用意しておき、それを流し込むテストコードを変更に強い設計にしておく、といったことなのかと思います。
レガシーシステム
過去に実装されたコードにはテスタブルな状態にないものも存在します。これらはリファクタリングするなどしてテスト可能な状態に持っていくことが重要ですが、新規開発も行いながら過去のコードも触っていくというのはなかなか困難な作業となります。
実現にあたってどのような戦略を持てばよいのか、次の章で紹介されていますので次回のエントリでアウトプットしていきたいと思います。
恐れ
この項は著者の思いがかなりでているところなので、原文を引用します
プログラミングを行わないテスターはアジャイル世界において提供するものが何もないと、しばしば言われてきました。私たちはそうではないと信じています。どのように自動化すべきかをテスター個々人が心配する必要はないのです。これはチームの問題です。
（P268 13.2.8 「恐れ」より）
それぞれの知識を持ち寄って、協調していくことにより、恐れをはねのけていきたいですね！
古い習慣
困難にさいなまれたとき、ついつい居心地のよい古い習慣に戻ってしまうことがあります。インクリメンタルな自動化を行っていくべきところで、毎回手動でのテストを実施するようになってしまう、といったことです。これでは変化への柔軟性に大きく影響が出てしまう恐れがあります。後々大きなバグが生み出され、ビジネスにも影響してしまう可能性があります。
まとめ
今回の章は「テスト自動化」についてのものでした。記述内容からどのレイヤーなのかがちょっとわかりづらいところもありましたが・・、ざっくりとまとめると・・。
- 自動化によって開発工程におけるセーフティネットが築ける
- ネガティブな阻害要因は必ずでてくるが、恐れずチーム全体で解決していく
と理解しました。
次回は・・・
テスト自動化にあたっての戦略について、アウトプットしてきたいと思います！
ではまた次回。
アプレッソ品質マネジメント部に9月（去年）からJOINしました
どうも初めまして、こんにちは。9月にJOINしました、金森と申します。 9月といっても、去年の9月、つまり一年越しの自己紹介となってしまいました。 物凄く遅くなってしまい今更感がありますが、この場を借りて簡単な自己紹介をさせていただきたいと思います。 ネット上でこうやって自己紹介することは初めてなので、結構緊張しています 笑
職歴について
アプレッソ入社前までは中小のSIerにてテストや開発を行っていました。 最初はアパレル関係のシステムのテストに一年ほど従事していました。 その後、物流会社のシステムに携わり、そこでDataSpiderに出会いました。 DataSpiderを使っていた、またテスターとしてもっと頑張りたいと思いアプレッソ品質マネジメント部にJOINしました。
DataSpiderを使ってみて
実際にDataSpiderを使って一番良かったと感じたことは、比較的経験の少ない人でも使え、使い方を覚えれば容易に開発できることであると思いました。 所属していたプロジェクトは私含め経験の浅い人が多かったのですが、開発がスムーズに進みました。 使い方もそれほど複雑ではなく、どんな人でも開発ができることは最大の長所であると感じました。
アプレッソにJOINして・・・
アプレッソに入社して約1年、テスト実施に携わっていました。 そこで感じたことですが、まずQAチームという立場からテストができることが良いことであると感じました。 前職で比較的小規模なプロジェクトに携わっていたのですが、そこでは自分で作成したプログラムを自分でテストしていました。 そのため、どうしても見落としてしまうことがありました。 なので、開発だけでは見つからない不具合を別の視点から発見できることがいいことであると思いました。 また、前職で携わっていたプロジェクトで、開発とテスターの力関係が開発 > テスターという力関係のプロジェクトがありました。 そのような風潮がないことも良いことであると感じました。
これから
現在開発全体でスクラム体制を取り入れ、アプレッソQAチームはその中でQAがどう関わっていくかを常に考えています。 私もテスト実施者としてどのように表現するかを常に考え、日々精進あるのみです。 自分の知らないことをやることは大変ではありますが、それと同時に楽しいことでもあります。 以上、簡単ではありますが、自己紹介とさせていただきます。 今後ともよろしくお願い致します。
追伸
10月からジョブローテーションで2か月ほどサポートチームに移ります。 気持ちを一新し、頑張っていきます。
趣味とか
ゲーム（ポケモンとかが好きです） 野球観戦（横浜DeNAベイスターズのファンです、久しぶりのAクラスで嬉しいです）
JavaOne 2016 3日目 & 4日目 - Message in the (Panama) Canal
こんにちは、開発部の野口です。
案の定 3日目のレポートは飛ばしてしまいましたが……巻き返していきます。 例によって、特に印象に残ったものをピックアップしてお伝えします！
Connecting Oceans with Project Panama: A Journey into Native
JNI の置き換えや Vector API の追加を目指す Project Panama についてのセッション。
Project Panama という名前は（ご想像の通り）北アメリカと南アメリカの境にあるパナマ運河からきていて、”connecting the gap” をコンセプトとするプロジェクトです。つなぐのは、Java と Native との間の gap、ですね。
Project Panama は JDK 9 には入りません。
JDK 10 以降でのリリースを目指して、鋭意研究開発中です。
野心的な機能が色々と含まれますが、すべてを実装し尽くしてから出すというよりは、部分的に使えるようにして、早くリリースすることを目指しているそうです。
Java と Native とをつなぐ、安全で、簡単に使える、高速なインタフェースを構築することが大きな目標です。
Java がネイティブコードと連携するための方法としては JNI があり、また JNA をはじめとする、JNI の使用を容易にするためのライブラリも広く使われています。
Project Panama は、それらを「安全性、使用の容易さ、速さ」の 3 つの面で超えることを目指します。
よくばりですね！
簡単なデモもありました。
jextract というツールで C のヘッダを読み込んで自動生成されたクラス群を使って、OpenGL のライブラリを呼び出します。
▲ネイティブっぽい雰囲気の Java コード
実際のコードを見ると、想像以上にネイティブコードっぽい Java コード、つまりネイティブとの一対一対応に近いラッパーを Java のクライアントコードから触ることができていて、これらのクラス／インタフェース群がすべてコマンド一発で生成されるのだとしたら、かなりナイスです。
安全性についても色々と考慮されており、さらにこれでパフォーマンスも JNI を上回るとしたら……。
AutoCloseable や 関数型インタフェースといった近年 Java に入った機能も大いに活用して設計されており、たしかにこれならやれるのかも、と期待が持てます。
ただし、あくまで研究開発段階ということで、今後仕様や設計が変わる可能性は大いにあるとのことです。
実際、セッション終わりの質問タイムも紛糾しました。
まだまだ課題は山積みのようですが、業務上 JNI のつらさを味わうことがちょいちょいあるので、期待したいところです。
Thinking in Parallel
Stuart Marks と Brian Goetz というグルーヴィーな登壇者による、並列処理についてのセッション。
今後入る予定の新機能についての議論があるかなとも思っていましたが、案外そういうのはなくて、基礎的な内容でした。
にも関わらずここに書いているのは、とても面白かったから！
大まかに言って、前半は Stuart が Stream API の価値について説き、後半は Brian が並列処理についての議論をするという段取りでした。
ごく簡潔にまとめてしまうと、Stuart の主張は、従来の for ループを使うよりも、Stream API を使用するほうが常によい。
理由は、新しいから、カッコいいから、関数型だから……ではなく、「抽象性のレベルが（for ループよりも）上だから」。
ごもっともです。
たとえば C を使わずに Java を使うのと（細部にこそ違いはあれ）同じなのかなと思います。一方で、「それでも Java でなく C を使うケース」というのもあることを考えると、完全な論理ではないとも思いますが、少なくとも、（C 言語を使うのに十分な正当性が必要であるように）for ループを使うのには十分な正当性、たとえばパフォーマンスのボトルネックであることが特定されているとか、が必要と言えそうです。
一見 Stream で処理するのが難しそうな「値のリストをチャンクに分割する処理」も、「インデックスのストリーム」という考え方を導入することで Stream で処理できるよ、という例には目を開かされました。*1
それから、後半の Brian の主張はというと、こちらは「並列化するほうが常によい」……ではもちろんなく、必要なときにだけすべし、でした。
理由は、「並列化は最適化だから」。はい。
並列化はたいてい、メモリ空間と効率（省エネ）を犠牲にして、スループットを向上させるために行います。よって、その費用対効果が十分だと判断できる場合以外には、すべきではありません。
Stream API は並列処理をサポートしています。
ここで、Stream API で並列処理によってスループットが上がる可能性があるための条件として、
- データの数が多く、一件あたりの処理コストも高いこと
- データの（メモリ上での）局所性が高いこと
- 処理の分割コストが低いこと
- 最終的な処理結果の統合コストが低いこと
- 順序に依存しないこと
が挙げられていました。
美しいリストです……。
もちろん、これらの要素を感覚で判断して決めてしまうのではなく、実データ（少なくとも、それに近いデータ）による実測が必要です。（最適化ですから最適になっていることを確認しないと！）
なお、上の議論は値の計算処理を前提としていて、I/O が絡む場合は少し変わってきます。
Let’s Get Lazy: Explore the Real Power of Streams
『アジャイルプラクティス』や『Java による関数型プログラミング』などの著書を持ち、JavaOneでも例年数多くのセッションを担当している Venkat Subramaniam による遅延処理についてのセッション。
去年は縁がなく、今年初めて彼のセッションを取ったのですが、さすが期待通りの内容でした。
まず Haskell の動作や Scala の lazy キーワードによる遅延評価を紹介したのち、Javaでは Supplier のラムダ式で同じようなことができるよね……、といった具合に、一歩一歩下地を作ります。
個人的には、評価した値を再利用するパターンも何か紹介してくれるかなと期待していた（結局なかった）ので、そこにはやや不満もありましたが、全体としての構成と運びが見事すぎて、帳消しになりました。
後半は、Stream API がいかに lazy であるかの紹介。
Stream は終端処理が呼ばれるまではあくまでパイプラインを組むにすぎず、各種の条件（filter）や変換（map）は終端処理を呼んだ時点でまとめて処理されます。
そのため、個々の処理が行われる回数は、従来の for ループで効率的にロジックを組んだ場合とまったく変わらない。ということを、実際の動くコードで、デバッグプリントも使いながら巧みに説明します。
▲なんかペンみたいなやつでパイプラインを示す
▲デバッグプリントでどのロジックが何度呼ばれたかを示す
どれも既に知っていることなのですが、よく整理された説得力のある説明で、知識が更新され、定着していきます。
終盤には無限ストリームを説明し、またリストを返すメソッドをストリームを返すメソッドにリファクタリングすることで、行われる処理の量（実行時間）を大きく削減するというデモも行いました。
この辺のコンセプトは彼の著書である『Java による関数型プログラミング』でも説明されている（されていた……はず）のですが、こうして説明を受けることで本当に明日から使える知識になります。
こういうところ（すぐれた教師の教えを直接受けられること）にも、JavaOne のような技術カンファレンスの価値はあります。
Ask the JDK Architects
去年も色々な面白トークを聴くことができたこのセッション。
今年は Mark Reinhold、John Rose、Brian Goetz の 3 名が登壇して、参加者からの数多くの質問に答えました。
▲The JDK Architects
今年のキーノートでまさに Brian が発表していたローカル変数の型推論について、去年も話題に上がっていた（気がする）「Java で一番後悔していること」、果ては彼らが好きな IDE まで……。
いくつかピックアップして紹介したいのですが、いまいち聞き取れなかったところの補完をするのに手持ちの iPhone *2 だけでは心許ないので、日本に帰ってから補足します！！
Oracle Appreciation Event
そして……会社から JavaOne 行かせてもらってる組として役得としか言いようのないこのイベント……！
▲今年は AT&T パークで行われました
Sting のステージ開始から 2 曲目で早々に Gwen Stefani が（再）登場し、一緒に「Message in a Bottle」を歌うなどしていました。
別々のスターが同時に二人ステージ上にいる状況に混乱して、少し泣きそうになりました。
▲Sting & Gwen Stefani!!
JavaOne 2016 も残すところあと一日。
最後（蟹 One）まで気を抜かず、励みます。
JavaOne 2016 2日目 （その2）
こんにちは、開発部の陳です。
同行している野口とは選んでいるセッション構成が少し違うので、 そのうちに印象の深いものを、2日目レポートの裏番組でお送りします。
Pick Diamonds from Garbage
セッション名の通り、ゴミ（GC ログ）からダイアモンド（有益な情報）をあさる方法を紹介するチュートリアルでした。
構成は順に、 KPI の説明、GC ログの読み方、ツールの紹介、Q&A になっています。
GC の KPI を説明するのに、 バカンスでサンフランシスコからハワイに行くのに、 戦闘機と旅客機どっちが適切かという面白い比較をしました。
- Latency = 一人の乗客を運ぶのにかかる時間 / GC pause time
- Throughput = すべての影響を考慮した上で、24時間で運べる乗客数 / useful works
- Footprint = 一人の乗客を運ぶのにかかるコスト / CPU, memory
この例えは一見奇抜ですが、GC を広い意味でオブジェクトの移動として捉えれば、納得できます。
そのあと GC ログの読み方を紹介したが、
- Java の実装ベンダー
- JVM バージョン
- GC アルゴリズム
- 起動時引数
によって、形式だけでなく含まれている情報もかなり違うという無情な現実を突きつけられました。
さらにその現実の残酷さを実感するため、ここでこの曲を流しました…
最後に現実との戦いに生き残るため、いいツールを紹介してくれました。
GC ログをアップロードすると、人が読みやすい形式テーブルやチャートに変換してくれるほか、 さらに統計情報や、GC の動きを分析して、可能な問題点を洗い出すという便利なツールです。 REST API も提供しているので、パフォーマンステストを含む CI に組み込むと幸せになるかもしれません。
Functional Data Structures With Java 8
Zeroturnaround の Oleg Šelajev さんが、Java 8 ベースの「関数型データ構造」を紹介するセッションでした。
コレクションを関数型の手法で実装するという素敵な試みで、 個人的（主に情報学的な観点）にはとても面白い内容だと思いますが、 普通の Java 開発者が普段の仕事でプロダクションコードで使う場面はあまりないでしょう…
セッションのスライドはこちらで公開されています。
Disciplined Locking: No More Concurrency Errors
Checker Framework の中の人、Werner Dietl 先生と Michael Ernst 先生によるセッションで、
主に @GuardedByアノテーションの使い方とコード検証にまつわる話でした。
@GuardedByは 2006 年に Java Concurrency in Practice の作者、Brian Goetz さんが提案したもので、
データ競合を防ぐためのロックを文書化するためのアノテーションで、いまやデファクトスタンダードになっています。
しかし、このアノテーションには正式な定義がないため、解釈によって意図した使い方と異なる実装になる可能性があるので、
このセッションで、@GuardedBy の定義を厳密化したうえで、Checker Framework によるソースコード検証方法を説明しました。
ちなみに、このセッションの元ネタとなる論文はこちらです。興味のある方はぜひご一読を。
裏番組も（たぶん）つづきます
初日の会場の寒さに負けて、風邪気味になってきましたが、体力がある限り更新続けて多くの情報をお届けしたいと思います。 もし体力が尽きてダウンになったという事態になったら…まあ、その時にまた考えます。
