JJUG ナイトセミナ 「Javaのプログラムはどうやって動いているの?」に参加してきました

  • 講師
    • 櫻庭祐一さん
    • @skrb
    • Java in the Boxの方
    • Javaチャンピオン
    • ITpro Hava技術最前線の著者

JVM 編

JVM

Virtual Machine

Java Virtual Machine

Classファイル

コンパイル

javap

mainを実行するまで

java Test を実行したら

  1. JVM起動
    • JNI_CreateJavaVM()
  2. クラスロード
    • Classファイルの読み込み
    • 使用するクラスを芋づる式にロード
    • java -verbose:class Test
  3. リンク
    • Classファイルが正しいかチェック
      • 改ざん・悪意のあるコードがないか
    • staticフィールドの初期化
      • ただしJavaのコードは実行しない
      • finalでもnullが入る
    • クラス間の関係を解決
      • 継承やら型やら
  4. 初期化
    • staticフィールドの初期化
      • Javaコードも実行
    • staticイニシャライザの実行
  5. main実行

バイトコードの実行

逆ポーランド記法

  • 1 + 2 → 1 2 +
  • (2 + 3) x 5 + (4 - 2) → 2 3 + 5 x 4 2 - +
  • Stack Machineと相性が良い

メモリの状態

  • スレッド毎にStackがある
    • 他にはHeapとMetaspaceがある
    • スタックオーバーフローはStackが溢れた状態

Conclusion

  • Java → Classファイル（バイトコード）
  • JVM起動 → クラスロード → リンク → 初期化 → main実行
  • JVM: Stack Machine

　

GC 編

Why to Use GC

GC (Garbage Collection)

  • メモリの自動管理
  • 不要になったメモリを自動的に回収

Before GC

  • 自前でメモリ管理
  • Cだとmalloc(), calloc(), realloc(), free()

問題点

  • メモリ解放忘れ
  • 二重解放
  • 無効な参照
    • メモリ周りのBUGは修正が難しい

最初のGC

  • 1959: John McCarthy
  • 一般的に使用されだしたのは90年代
    • CPU、Memory性能向上

Mark & Sweep GC

  • 使用中のオブジェクトをマーク
  • マークのないオブジェクトを解放

どうやってマークするか

  • rootから参照を辿る
  • 参照先から参照を辿る

  • 未使用オブジェクトをFree Listへ

    • 次にオブジェクトを配置するときはFree Listから探す

  • compactionでぶつ切れのFree Listを並べる

adv. & dis.

  • adv.
    • 実装がシンプル
    • 参照の書き換えがないため安全 (if not Compaction)
  • Dis.
    • Stop-the-Worldの時間が長い
    • ヒープの断片化がおきやすい (if not Compaction)
    • CompactionをするとStop-the-Worldの時間が長くなる

Copy GC

  • ヒープを二分割
  • 使用する領域は一方のみ
  • 片方から一方へオブジェクトをコピー
  • スイープではなくコピーする

adv. & dis.

  • adv.
  • Dis.
    • ヒープの使用効率が悪い
    • 参照の書き換えがある

世代別GC

Javaで主に使われている

  • 仮説：若いオブジェクトは早く死ぬ
  • 世代別にヒープ管理を行う
    • Young世代：高速なGC → Copy
    • Old世代：安定したGC → Mark & Sweep
  • オブジェクトの年齢：GCを生き延びた回数

特徴

  • M&SとCopyのいいとこどり
  • 領域サイズはチューニングが必要
    • Old世代のGCをなるべく減らす
  • CMS, G1GCなどの派生GCあり

Conclusion

  • M&S、Copy、世代別
    • 60年代から全然変わらない
  • 原理を知って、チューニングに活かす
  • GCと仲良く
  • GCに関しては以下の書籍が詳しい www.amazon.co.jp

『コンピュータシステムの理論と実装』読んでコンピュータ作った

概要

O'reillyから出ている書籍です。 www.amazon.co.jp

「NANDからテトリスへ」という帯タイトルがまさになのですが、NANDゲートが与えられた状態からスタートし、ゲームが動くコンピュータを作り上げます。

割り切って言ってしまうと、本書はその説明書となります。

NANDゲートからAND・ORゲートなどをHDLで記述していき、ALU、CPUを作り、アセンブラ、VM、コンパイラ、OSを書き、最終的にはコンピュータシステムが出来上がります。

もともとは大学の授業として作られたテキストのようで、Webページには資料や必要なソフトウェアが公開されています。

実際にコンピュータシステムを作る

本書はコンピュータシステムの理論が書かれているだけではなく、実際に手を動かして実装できるようエミュレータやテストツールが付属されています。

前半でハードウェアを、後半でソフトウェアを作成します。

ハードウェアは実際に作るわけではなく、HDLで記述していきます。 NANDからマルチプレクサやALU(算術論理演算器)、フリップフロップからメモリやプログラムカウンタを作成し、それらからCPUを、そして最終的にコンピュータのハードウェアを作り上げます。

前半でバイナリコードを処理するコンピュータが完成するので、後半でそのコンピュータ向けバイナリコードを生成するような、アセンブラ・VM・コンパイラ・OSを作成します。

アセンブラ、VM、コンパイラ作成では自分の好きなプログラミング言語を使用し、テストツールがあるので、それをパスするように実装していきます。

本書ではJackという比較的単純な言語を使用しており、Jack用のアセンブラ・VM・コンパイラを作成します。OSはJackで書きます。

作業量

Courseraにこの書籍の前半部分の授業が公開されており、1週間5〜10時間の勉強を7週間という作業量で書かれています。

単純に計算すると、倍の70〜140時間かかることになると思います。（ただし、後半のほうが難しいので、単純計算はできないかもしれません）

他の人がやったものがGitHubに上がっているのですが、VM・コンパイラはそれぞれPythonで数百〜千行くらい書かれてるので、それぐらいの実装が必要かもしれません。

自分は丸12日くらいかかりました。（コンパイラの実装が凄く大変でした…）

雑感

実装がかなり大変ですが、普段気にしていなかった「CPUは分岐をどう処理するか」「スコープの異なる変数をメモリはどう扱うか」などが分かり、勉強になりました。

やって役に立つのか？というとよく分かりませんが、別の書籍の『アンダースタンディングコンピューテーション』のまえがきで、まつもとゆきひろさんが以下のように書かれています。

この「根源」に関する知識がなくてもほとんどの場合、プログラムは書けます。しかし、「計算」とはなんであるかという知識は、プログラミングの本質を理解するのに役立つでしょう。そして、それは心の奥底に沈み込んで、いつかきっと日常を超えたプログラミングを現実化する時の知識となってくれるに違いありません。仮にそんな日が来なくても、教養というものは人生を豊かにしてくれるものでしょう。

日常で使用しているコンピュータをゼロから構築するという体験は、それだけで刺激的であり、また先人の知恵の偉大さを感じさせてくれるものでした。

「JJUG ナイト・セミナー 機械学習・自然言語処理特集！」に参加してきました

Java でカジュアルにはじめる機械学習

スマートニュース株式会社の小宮篤史さんによる発表。

Javaから使える機械学習ライブラリ

とりあえず機械学習をやってみるときのデータセット

　

Spark/MLlibではじめるスケーラブルな機械学習

株式会社エヌ・ティ・ティ・データの猿田浩輔さんによる発表。

　

Luceneと日本語の検索

Elasticsearch社の大谷純さんによる発表。

  • Luceneとは

    • 高速な検索ライブラリ
    • Javaベース

  • 主な機能

    • 転置インデックスの作成と検索
    • 検索結果のスコアリング
    • 豊富なクエリ（近傍、フレーズ、範囲など）
    • フィールド指定による検索

「システムテスト自動化カンファレンス2014 #stac2014」に参加してきました

本カンファレンスは、テスト自動化の技術領域を定義し、啓蒙・普及活動を行っているテスト自動化研究会 STARが主催しているカンファレンスです。

システムテスト自動化は普及のキャズムを超えたので、テスト自動化のアーキテクチャやパターンを考えていこうという趣旨のもと、最前線で活躍される方々が発表されておりました。

どの発表も非常に熱がこもっており、自動化の潮流を強く感じられました。 また、会場の雰囲気も非常によく、ヤフー株式会社様の充実した設備もあり、大変聴きやすいカンファレンスでした。

以下、資料です。

1時間で分かるSTA

鈴木一裕さん @kz_suzuki による発表。 本発表の効果もあり、会場内で販売されていた『システムテスト自動化 標準ガイド』は即完売となっておりました。

　

テスト自動化のパターンと実践 / .reviewrc

テスト自動化のパターンと実践

前川博志さん @Posaune による発表。

　

皮を剥く

石川達也さん @StoneGuitar777 による発表。

　

自動家（オートメーター）をつくる！

三浦一仁さん @kazuhito_m による発表。

　

STA 第2部 : GUI自動テストの保守性を高めるには

伊藤望さん @ito_nozomi による発表。

　

STA 第2部：状態遷移テストにおけるテスト設計と実行の自動化

きょんさん @kyon_mm による発表。

　

STA 第2部 : ビルドプロセスとCI

長谷川孝二さん @nowsprinting による発表。

　

社内スマホアプリのビルド配信ツールによる自動化事例

赤根稔朗さんによる発表。

　

Test Automation Patterns 2014 冬コレ！

松木晋祐 @snsk さんによる発表。

「【メルカリ×奇兵隊×ジェネストリーム登壇】第1回AndroidTips共有会」に参加してきました

登壇者の発表前に事前交流会があり、非常に和気あいあいとした勉強会でした。

ログ管理でウキウキAndroid Life

メルカリの今井さん @tomoaki_imai による発表。

ウキウキするエラー系ログ管理のお話

  • ユーザの声にならない叫び

    • クラッシュが大量に起こっても声を上げるユーザは少ない
    • エラーログを見てバグを駆逐していきましょう

  • エラー監視ツール

    • Google Developer Console
    • Crashlytics
    • 自前エラーレポート

  • Google Developer Console

    • apkをGoogle playに挙げるときのあれ
    • Crashlyticsで見られないものも見られる
    • しかし氷山の一角

  • Crashlytics

    • 導入が超簡単
    • アカウント登録は待ち状態
    • 1行コードを足すだけで使える
    • メルカリではdev、stg、productでパッケージ名を分けそれぞれでログ管理し、テスト・QA

  • 自前エラーレポート

    1. 予期せずエラーが起きてもレポートを飛ばす
      • Applicationクラス内でThread.UncaughtExceptionHandlerを実装
    2. 既知のバグの発生条件を調査できる仕組み
      • すでにErrorが発生すると判明している部分で、catch内で調査に必要な情報を送る
    3. レポートを貯めて送る仕組み
      • レポートをプリファレンスに保存し、レポート送信前にクラッシュしたり通信できなくても、次回起動時に送信できるようにする

ウキウキする分析ログ管理のお話

  • What is 分析ログ

    • インストール率、DAUなどを分析するためのツール

  • 分析ログの問題点

    • それぞれの分析サービスのAPIに標準性がない
    • 似たようなトラッキングコードをかかされる

  • Segment

    • 複数の分析サービスを統合できる
    • シンプルなAPI
    • ユーザーはコンソールから分析サービスを選ぶだけ

  • SegmentについてQiitaにまとめた

  • 注意

    • 成長中のサービスなので開発が盛ん
    • Documentの記述が食い違ってる場合もある
    • SDKもオープンソースなのでプルリク出したらいい

　

ぬるぬる動くAndroid Tips

奇兵隊の小西さん @konifar による発表。

  • 画面をぬるぬるにする

  • 役に立った知識

    1. 現状のパフォーマンスを確認する方法
    2. 修正Tips

現状のパフォーマンスを確認する方法

  • 便利なDeveloperモード
    1. Strictモード
      • 開発者向けオプションの厳格モードをチェック
      • パフォーマンスを低下させるものを見る
    2. GPUレンダリング分析
      • GPUの使用状況をリアルタイムで表示
      • Viewの構築にかかった時間、2Dレンダリングにかかった時間などが分かる
    3. GPUオーバードロー
      • 何回描画されてるかを色で可視化

修正Tips

  • 修正の流れ

    • 遅いところを探して直す
    • Googleの言ってる基本原則
      1. 必要ない処理をしない
      2. 不必要なメモリ割り当てを行わない
    • ボトルネックをちゃんと調べるのが近道

  • 便利ツール

  • Method Tracking

    • どのメソッドに時間がかかってるか1クリックでトラッキングできる
    • ボタンを押して画面を動かして、もう一度押せばプロファイルが見られる
    • 遅いメソッドを見つけて直す

  • Hierarchy View

    • ビューの階層構造が一目でわかる

  • Viewの最適化

    • narrowよりsharrowなView構造
      • LiniearLayoutを使うとネストが深くなりがち
      • RelativeLayoutで作ったほうがいい
      • Listなどはよく効いてくる -ViewのbackdroundをやめてThemeのwindowBackgroundを使う

  • 詳しくは公式のPerformans Tipsを参照

  • まとめ

    1. 提供されているツールを使うと便利
    2. Android Studio使うともっと便利
    3. すぐに試せるのでやってみるといいかも
    4. レイアウトやコードの実装に気を遣おう

　

Reactive Android

ジェネストリームの釘宮さん @shin_kugi による発表。

  • Reactive Programming的な考え方とは？

  • ストリームという概念で物事を捉える

    • ストリームとは、時間順に並んだ進行中のイベントの列

  • Anroidで使えるの？

    • RxAndroidを導入することで簡単に実装できる
      • RxAndroidとはRxJavaのAndroid Module
      • RxJavaはJavaでReactive Programmingを行うためのライブラリ
      • Gradleファイルに1行書くだけ導入できる

  • どういうところに使えるか

    • ModelとControllerの繋ぎ（Obserberパターンに）
    • Http通信のリクエスト&レスポンス

  • まとめ

    • Reactive Programingってなんぞやを理解しないと自分がなにしてるか良く分からない
    • 結局ポイントは何をストリームとするか

　

ちょっとGoogle Analyticsの話しようぜ

岡野さん @operandoOS による発表。

　

その他

開場を提供して頂いたHDEさんにはDr Pepperを無料で飲める世界に一台の自動販売機がありました。

f:id:shzero5:20141120211546j:plain

「Heroku社エバンジェリスト相澤氏が語るDay2「How it works ?」 #APC勉強会 ＃7」に参加してきました

Heroku社エバンジェリストの相澤さん直々の説明で、非常に勉強になりました。

また、AP Communications社の皆さまによる非常に丁寧な運営にも感謝致します。

前回のおさらい

Herokuとは

  • 開発者のためにつくられたクラウドプラットフォーム
  • サーバサイドなどプロダクトの価値創造に関係ないところに労力を注力する必要がなくなる

Herokuの特徴

  • インフラでなくアプリケーションに注力できる
  • 使い慣れたツールでデプロイ
  • 数百万のユーザをささえるスケーラビリティ

Herokuの内部構造

herokuを構成するコンポーネント

  • Dyno
    • アプリケーションコンテナ
    • HerokuApplicationの中核
    • コンテナで構築されるのでオーバーヘッドが少ない
  • Dyno Manager
    • Dynoの状態を監視、制御するコンポーネント
    • どういう種類のプロセスを動かすかという指令を受け取り、必要な数のDynoを起動する
  • Router
    • HTTPリクエストを受ける窓口
    • AWSのELBみたいなものだが、これはサーバ単位ではなくコンテナ単位で振り分ける
    • Erlangで書かれているHermesというプロダクト
  • Platform API
  • Dashboard
    • Platform APIを叩くWebインターフェース
    • 全てのAPIが叩けるわけじゃない
    • 慣れた人はCLIからAPIを叩く
  • Git
    • コードリポジトリ
    • Git PushをフックしてSlug Compilerが動作する
    • ユーザはリモートリポジトリにプッシュするだけでHerokuで動作する
  • Slug Compiler
    • アプリケーションを実行可能な形式にコンパイルする
    • Gemfileなど見て必要なライブラリをインストールし、Dyno Managerに渡る
  • Logplex
    • ログの一元管理コンポーネント
    • ログの集約はするがストレージとビューはもっていない
    • これがあるのでFluentdのようなログ収集の仕組みを組み込む必要はない
  • Addons
    • Herokuに各種機能を追加する
    • AddonsがLogplexのログを取得することもできる

Dynoとは

  • 1つのアプリケーションに対して複数のコンテナが配備される
Dyno Size
  • 3つのサイズが有りメモリとCPU特性が異なる
    • 1X、2X、PX
  • 1DynoHour単位でお金がかかる
    • 1X Dynoが1時間で1DynoHour
    • 2Xだと1時間で2DynoHour、PXだと1時間で16DynoHour
  • PXはマルチテナントではなくサーバを占有する
    • 他のアプリケーションにリソースを食われることがない
  • $0.05/DynoHour
    • ただし、1Applicationにつき750DynoHoursまでは無料（約1ヶ月無料）
    • 1X Dyno 2台を1ヶ月稼働で約4,000円
Dynoのロール
  • Regular Dyno
    • Web Dyno
    • Worker Dyno
  • One off Dyno
    • Scheduler
    • Heroku run

Procfile

  • Applicationの構成を定義したファイル
  • 独自のプロセスを複数定義できる
    • crawlerなど

Buildpack

  • Slug Compilerによって使用されるビルドモジュール
    • Buildした結果はSlugと呼ばれるtarballにまとめられる
    • それがS3にまとめられ、Dyno ManagerがそれをみてDynoに配備する
  • Buildpackだけすり替えることもできる
  • git pushされたファイル構成から使用するbuildpackが決定される
    • GemfileがあればRuby、など

Dynoと再起動

  • WebDyno、WorkerDynoは約24時間に1回再起動する
    • 24時間以上かかるバッチ処理を行っているときは注意が必要
  • 以下の場合もDynoが再起動する
  • デプロイするとダウンタイムが発生する
  • Prebootを使えばブルーグリーン・デプロイができる
    • ダウンタイムがない
    • しかし、新旧のバージョンが同時に動くリスクがある
    • バージョンアップでデータの不整合を起こしうる場合はPrebootするべきではない

Herokuのアーキテクチャ概要

コンテナによる環境の分離とは

  • ハイバーバイザ（仮想化基盤）による環境の分離
    • OSレベルで分離
  • コンテナによる環境の分離
    • ユーザプロセスレベルで分離
    • カーネスプロセスは共有している

コンテナを実現するミドルウェア

  • OpenVZ
  • LXC
  • Docker
  • Warden

コンテナを利用するメリットとデメリット

  • メリット
    • 高密度化が可能（ひとつの物理サーバ上で配備可能な数が多い）
    • オーバーヘッドが少ない（だからスケールが早い、プロセスを立ち上げるだけ）
    • 軽量で素早い起動/終了ができる
  • デメリット
    • 同一のサーバーに異なるOSに依存するアプリを配備できない
    • 同一サーバ上の別コンテナの影響を受ける場合がある
    • ファイルシステムに永続化した情報は揮発する
    • スティッキーセッションが使えない（場合がある）

コンテナの配備

  • 一つのアプリに対して複数のコンテナが配備される
  • サーバがダウンしてもアプリ全体は停止しない
  • 欠けたコンテナはすぐに別のサーバ上に配備される
    • この辺のことをやっているのがDyno Manager

PaaSの利点

  • アプリケーションを分散かつ高密度に配備することにより、より多くのサービスを稼働させながら、安全性と対障害性を高めている
  • 必要なタイミングで素早くスケールイン/アウトをおこなうことができる
  • 上記のような特性を備えた環境を初期投資なしで利用できる

コンテナ型アーキテクチャで稼働するアプリの設計

設計上の考慮

ストレージの揮発性

  • コンテナの外側に保存する
  • メモリキャッシュ
    • MemCachierアドオンを追加
  • 画像など
    • Cloudinaryアドオンを追加
  • ログ情報
    • ogplexがやってくれる
    • アドオンを導入することでバックアップやビッグデータ連携ができる

スティッキーセッション

  • セッション識別子をロードバランサーなどで検知して同じセッションを同じアプリインスタンスにディスパッチする機能
    • JBoss、WebSphereなどはスティッキーセッションを前提に作られているが、PaaSによる効率的なルーティングがアプリ要因で阻害されることになるため、良い設計とは言えない

タイムアウト

  • 時間応答がないリクエストをタイムアウトで強制終了することがある
    • Herokuの場合は30秒
  • WebSocketの中に何も流れていなければ切られる
  • 対応策
    • 長い時間がかかる処理はキューに登録し、バックグラウンド処理で実行するようにする

PaaSに適した設計

  • アプリケーションがプロセス単位で分散配置され、
  • 個別のプロセスはいつでも不安定になり得る
  • という前提のもと、シェアードナッシングに設計する

得られる利益

  • PaaSが提供する安全で拡張性のある実行環境を初期投資なしで利用可能
  • スモールスタートで運用開始し必要な時にスケールアウトさせることが可能

  • アプリケーションの可搬性が高くなり、ベンダーロックインにならない

  • HerokuはPaaSのパイオニア

    • Herokuで動くシェアードナッシングなアプリケーションは他のベンダーでも動く

さらに生産性の高い開発/運用のために

  • The Twelve Factor Application
    • 現代的なアプリケーションを設計、構築、運用するための12の方法論
    • Heroku創業者がプラットフォームサービス上で数百のアプリの特性から得た知見をまとめたもの
    • 『プロフェッショナルのための実践Heroku入門』には日本語訳が書かれている

その他

f:id:shzero5:20141106002433j:plain

著書の『プロフェッショナルのための実践Heroku入門』にサインを頂きました。

「第1回オーシャンビューAndroid/iOS勉強会inBizreach #オーシャンビュー勉強会」に参加してきました

Bizreachさんが毎週もくもく会としてスペースを公開していたそうで、今回は勉強会としての開催でした。

Google I/O 2014 アプリに学ぶ Material Design の実装

Gunosyの@hydrakecatさんによる発表。オライリー本の翻訳なども行っているそうです。 以前にGunosyでMaterial Designの勉強会を行い、今回はその復習とのこと。

Material Designとは

  • ユーザにとって一番馴染みのある紙をメタファーに使ったデザイン
  • AndroidでMaterial Design
    • Material Design ≠ Android L
      • 4.4や2.xでもMaterial Designはできる
    • Lolipopの機能を使うと簡単にできる

Google I/O 2014アプリ

Material Designに関するLolipopの新規機能

  1. マテリアル・テーマ（Material Theme）
  2. リストとカード（Lists and Cards）
  3. 影とクリップ（Shadows and Clipping Views）
  4. 画像（Drawables）
  5. アニメーション（Animations）

  6. 互換性（Compatibility）

  7. 詳細はCreating Apps with Material Design参照

1. マテリアル・テーマ

  • マテリアルテーマを使うとタッチフィードバックなどデフォルトのデザインを利用できる
    • カラーパレットの各色を指定することで、簡単にテーマをカスタマイズできる
  • ベース・テーマは3種類
  • ステータスバー、ナビゲーションバーの色も指定可能

2. リストとカード

  • I/Oアプリでは使っていなかったので省略

3. 影とクリップ

  • z軸方向の位置を指定できる
  • I/0アプリにおける影の使い方
    • スクロール量に応じて影の長さが変わる
  • Viewの外形とクリップ
    • 影の形およびタッチフィードバックの領域を決める外形を指定できる
    • 外形し指定した形にViewをクリップすることも可能（setClipToOutlineメソッド）

4. 画像

  • 画像の着色
    • android:tintプロパティで画像の着色ができる
    • I/Oアプリではスケジュール追加ボタンに使用している
    • 普通はテーマカラーを変えたら全ての画像を作り直す必要があるが、これを用いればコードから画像の色を変えられる

5. アニメーション

  1. タッチ・フィードバック（Touch Feedback）
  2. 出現エフェクト（Reveal Effect）
  3. アクティビティの遷移（Activity Transition）
  4. ビューの状態遷移（Animating View State Changes）
  5. 画像の着色（Drawable Tinting）
a. タッチ・フィードバック
  • ボタンにはデフォルトで当たっている
    • 電卓などタップすると波紋状にエフェクトがかかる
  • ripple要素を使えば同様のタッチフィードバックを持ったdrawableが作れる
b. 出現エフェクト
  • 円形状のアニメーションでViewを出現させることができる
    • 現在は円形のみ
c. アクティビティの遷移
  • 以下のそれぞれにアニメーションを設定できる
    • Enter: Activityに入るときのシーン
    • Exit: Activityから出るときのシーン
    • Shared elements: Activity間で共有されているView
d. ビューの状態遷移
  • 状態が変わった時の見た目だけでなく、そのときのアニメーションも指定可能
    • Viewのプロパティをどれくらいの時間でどう変化させるか

6. 互換性

  • Lolipop以前の端末でも同様のUIを提供している
  • どうやっているか
    1. ソースコードの切り替え
      • gradleのflavorを使って切り替えている
    2. リソースファイルの切り替え

Tips

  • Google Play Serviesが最新ではないと怒られる
    • build.gradleの設定で5+から5.0.+に変更

　

Android 4.4で追加されたステップカウンターを実装した話

@uturistさんによる発表。最近のプロダクトSmanpoで取り入れたステップカウンターのお話。

ステップカウンターとは

  • Android 4.4 KitKatからプラットフォームでサポートされたセンサ
    • Step Detector（徒歩検出）
    • Step Counter（歩数カウンタ）
  • 処理をハードウェアで行っているのでバッテリー消費を抑えられる
  • 端末サポート状況
    • 287 / 7471
    • 最近の端末の多くはサポートしている（Nexsus、Xperia、Galaxyなど）

実装について

カウンタの挙動について

  • 端末起動後リスナ設定中の累積歩数
    • リスナ登録がonResume〜onPause
      • Activityが画面に表示されている間
    • リスナ登録がonCreate〜onDestroy
      • プロセスが生きている限りカウント
    • ただし、他のアプリがリスナ設定していれば、Activityが画面に表示されていなくてもアプリが生きていなくてもカウントされる

Smanpoに使ってみて

  • バッテリの減りは気にならない
  • 実装は簡単
    • 加速度センサでやろうとすると大変
  • マニフェストファイルの記載を忘れずに
  • ステップカウンターが普及すれば世の中がより健康的になる

　

Android開発でのデバッグ環境どうしてますか

@yoshimaaさんによる発表。

  • 標準エミュレータ
    • 標準なので安心感がある
    • 遅い
  • 実機デバッグ
    • とにかく早い、設定が楽
    • 端末依存のテストが不可

でも実機でやりたい

  • deploygate
    • mixiが提供しているサービス
    • USBケーブルからの解放
    • Android端末上のアプリで管理
    • 公開前のベータ版アプリを簡単に配布
    • リアルタイムにログ収集、アップデート
  • Sumatium

　

自作アプリをiOS 8対応した話 〜FastCheckin編〜

@koogawaさんによる発表。

FastCheckin

位置情報取得方法の変更

  • iOS 8から位置情報周りが変わった
  • プライバシー設定が細かくなった
    • 許可しない（Never）
    • 使用中のみ許可（WhenInUse）
    • 常に許可（Always）
  • UsageDescriptionが必須に
    • どのような目的で位置情報を使用するのかを表示する必要がある
      • 表示しないと位置情報が取得できない
      • 以前からあったが、書かなくても使用できた
    • NSLocationWhenInUseUsageDescription項目
    • ダイアログに表示される
  • 認証リクエストAPI追加
    • 認証リクエストを呼び出すためのメソッドが用意された
      • requestAlwaysAuthorization
      • requestWhenInUseAuthorization
    • 何回でも呼べる
      • ダイアログが出るのは未認証のときだけ
    • iOS 7で使うとクラッシュする
      • バージョン分けが必要

ウィジェット対応

  • ウィジェットとは
    • iOS 8から使用可能になったApp Extensionの一つ
    • 通知センターにウィジェットを置ける
    • 正式名称はToday Extension
  • 作り方
  • 注意点
    • キーボードは使えない
    • アラートビューなども使えない
    • 高さには制限がある
    • 使用メモリ量に注意（16MB以内？）
      • 16MB以上なので重いよ、という感じのメッセージがでた

　

10分でTwitterクライアントを作ってみますん

@mofmofnekoさんによる発表

10分でつくるのは無理なので、それに向けたライブラリの紹介

Genymotion

  • 軽量なAndroidシミュレータ
  • 標準シミュレータはMacだと不具合がでることがある

Android-Bootstrap

  • 簡単にいい感じのデザインを実装できる
  • Font Awesome
  • Circle Thumbnail
    • 流行り？の円形アイコンの実装

PICASSO

  • 画像のダウンロード、表示、キャッシュを良しなにやってくれるライブラリ

JsonPullParser

  • Jsonデータを扱うライブラリ

Volley

  • 通信処理を簡素化してくれるライブラリ

OrmLite

Butter Knife

Jenkins

その他

非常に面白いスペースで、ハロウィン限定で赤い海が打ち寄せてました

f:id:shzero5:20141025155527j:plain