2018年2月13日火曜日

DroidKaigi 2018のWebサイトとか振り返り

DroidKaigi 2018が終わりました。今年もWebサイト関係やってました。

当日の担当は公式Twitter警備がメインでした。 ちょっと体調が完全じゃなかったので無理せず控室でもくもくとやってようと思ってたんですが、流石にその他諸々な雑用とかもしてましました。

以下、主にWebサイトについての振り返り。

Webサイトについて

去年の7月くらいだったか。サイト班のwm3さんとpsideさんたちとハングアウトで会話して、今年のサイトの方針についていろいろ決めました。

この2人がかなり動いてくれて、更にその他のスタッフもサイト更新を手伝ってくれたお陰で今年はかなり楽でした。 むしろ2人がかなりやってくれて、俺いらなかったんじゃないかレベル。 ありがてぇありがてぇ🙇🏼

droidkaigi.jpへドメインを変更

2017まではGitHub Pagesを使っていて、ドメインもgithub.ioでした。 今年からはdroidkaigi.jpというドメインに変えています。 実のところGitHub Pagesでホスティングしてるのは変わらないんですが、カスタムドメインにすることで将来的に何かしらバックエンドのシステムを持つ場合に差し替えやすいようにする目論見です。

ドメインはCloudflareを使ってSSL対応してます。

サイトジェネレーターとしてGatsbyを採用

GatsbyはReactを使ったサイトジェネレーターです。 2017まではGitHub Pagesの機能を使っていましたが、色々辛かったので全く異なる形に変えました。 流れは大体こんな感じだった。

🍏「Liquid辛いいいい」
pside「nokogiri辛いい」
wm3「もうReactでいいのでは」

※Liquid（HTMLテンプレートエンジン）もnokogiri（HTMLパーサー）もGitHub PagesのRubygemが依存してる。

サイトのアーキテクチャ構築もwm3さんがやってくれました。 その後の改修などはもちろん俺もやってましたが、React童貞だったのでおっかなびっくり触ってました。

個人的にはLiquidの仕様上の制約により辛かったタイムテーブルページの実装をなんとかできたのが大きいです。

NetlifyやCircleCIを使ったContinuous Deliveryっぽいの

最終的なホスティング先はGitHub Pagesなんですが、 別途Netlifyも使っていました。

PRを作るとその内容でビルドしたサイトがNetlifyにデプロイされて皆ですぐ確認できる形になります。 Google App Engineみたいに複数のバージョンをデプロイできるので、PR別(ブランチ別)に バージョンをデプロイする感じです。

PRをNetlify上で動作確認してmasterにマージするとdroidkaigi.jpをホストしているGitHub Pages用リポジトリにCircleCIでpushする流れです。

スポンサー一覧

サイト上のスポンサー一覧は、ベースをサイト班で作った後はスポンサー班が直接PR出してどんどんマージしていく運用でした。 途中ちょっとサイズ感の調整のためにデータ構造を変えた以外は、スポンサー班がサイトへのスポンサー様ロゴ掲載をやってくれました。 去年までは俺がIllustratorいじくりまわして頑張ってたなぁ。

Sessionizeとの連携

今回は応募トーク管理にSessionize.comを使用することにしました。 KotlinConfでも使われていて、トークの募集・レビュー・採択・タイムテーブル作成まで行える優れものです。

API経由でjsonデータも取り出せます。 当初Webサイトでは応募トーク一覧や採択トーク一覧を直接このAPIを叩いて書き出していました。 しかし、流石に大量に頻繁にアクセスされることを想定したものではなかったようで、アプリから参照されたりすることも考えるとパフォーマンスに不安がありました。 最終的に、一旦jsonを落としてきてから静的にデータを持っておく形になりました。 データはCircleCIのcron機能で日次で更新していました。

他方、基本的にSessionizeをマスターデータにしたいものの、サイト側やアプリ側の表示制御のために独自に追加したい項目もあったりしました。 そのために、サイト上に置いているjson(タイムテーブルの描画にも使ってる)はビルド時に加工したファイルになっています。

次回のDroidKaigiに向けて

色々改善できたり新たな試みを試した結果、欲や改善点も出てきました。

  • もっとCMS化したいかも
    • 他のスタッフも作業しやすいほうがいいよね
    • 公式Twitterやアプリとの連携も
  • 日英だけじゃなく両方の言語というセッションがあった…
    • これは急遽言語区分を追加して対応した。来年は最初から考慮しよう。
  • スポンサー情報のマスター化
    • アプリ側との連携を考えずにスポンサーページを作ったので、あとから無理やりスクレイピングしてスポンサー情報jsonを作るという辛み溢れる状態になっている。
    • 来年は最初からマスターデータの形を考えておこう。
  • Sessionizeとの連携をもっと楽にやりたい
    • 一旦jsonを持ってくるとかちょっとアレ
    • 間にFastlyか何か挟むとか
    • Fastly使ってみたいだけとも言う

その他

最近裏方業ばっかりなので、今年は登壇とか増やしたいななぁ。

とか思ってたら、まだ動画やスライドの公開作業あったよオイ。

投稿者 mstssk 0 コメント ラベル: , ,

2018年2月1日木曜日

Safariでposition:stickyが動かないとき

投稿者 mstssk 0 コメント ラベル: , , ,

2018年1月21日日曜日

AngularでFailed to execute 'send' on 'XMLHttpRequest'とか出た時にやること

Angularで開発していて、ビルド時やテスト時にFailed to execute 'send' on 'XMLHttpRequest' というエラーが出てわけわからん場合がある。
ng test --sourcemaps falseのように--sourcemapsオプションを切って実行してやると、詳細なエラー情報が出てくれる。

参考

投稿者 mstssk 0 コメント

2017年12月4日月曜日

🍺について

この記事はBeer Advent Calendar 2017の12月4日です。 ビールについてならなんでもOKらしいので、🍺について話します。

この記事を読んでいる皆さんは「🍺」がどう見えているでしょうか？

  1. ジョッキに注がれたビールに見える
    • あなたはモダンブラウザでこの記事を読んでいますね
  2. ビールに見えるが白黒
    • まだAndroid 4.3使ってるんですか
  3. 「�」に見える
    • 文字化けとるやん

2と3の方は今すぐ使っているPCかスマホを更新しましょう。

さて、1の方は具体的にどんなふうに見えているでしょうか？ そして、あなたが見ている🍺は他の人も同じ🍺に本当に見えているでしょうか。

PCやスマホで表示される絵文字は結局はただの書体の一つに過ぎないので、環境によって表示が異なります。 次のURLにはいろんなメーカーやアプリでの🍺の表示リストが載っています。 https://emojipedia.org/beer-mug/

いろんな絵がありますが、いずれも「ジョッキに入ったビール」として認識できると思います。 この絵文字はUnicodeで「beer mug」として定義されており、 その指針に従ってどのプラットフォームも 表示を実装している からです。

また「🍻」という絵文字もありますね。 こちらは「clinking beer mugs」です。

しかし、絵に過ぎないので、度々不幸なミスも発生 します。

Android 8.0での🍺の絵文字は泡とビールの間に謎の空間が出来てしまっています。 この不具合はAndroid 8.1で修正されています。

他の 絵文字にはさまざまな問題が起きていますが、幸いながら🍺については上記のちょっとした表示ミス程度しか問題が起きていません。 皆さん、安心して🍺を使っていきましょう。飲んでいきましょう。

投稿者 mstssk 0 コメント

2017年8月30日水曜日

ページ右下に熱盛を出すだけのUser Styleを書いた

ものすごく邪魔。

@mazamachiさんの「たまに熱盛が出てしまうextension」が面白そうだったので作った。

中身はコレ。

StylishといったUser Styleを設定できる拡張機能を利用したりして使う。

transitionやらanimationやら設定して忘れた頃に「熱盛！」ってドンと出る実装はできそうだけど、ここまでやって満足してしまった。

問題があって、Stylishでやるとiframeの中にまで熱盛するので、Twitterのタイムライン中の埋め込み動画やBloggerの画像アップロードダイアログの中にも熱盛が出てしまい、笑いをこらえながらこの記事を書いています。

投稿者 mstssk 0 コメント ラベル:

2017年8月29日火曜日

cron.yamlのdescriptionに日本語を書いてはいけない

TL;DR

Google App Engineのcron.yamlのdescriptionに日本語を書くと、アップロード処理がInternal Server Errorになることがある。
なので、基本的に英語で書いておくのが無難。

確認したのはGo言語のStandard Environment。

なにが起きたか

既存のプロジェクトでcron.yamlに記述している6つの設定のdescriptionを全て日本語に書き換えた。
CIで自動デプロイしているのだが、何故かcron.yamlのアップロードだけInternal Server Errorのため失敗しているログが出ていた。
デプロイスクリプトのexit statusがnon-zeroにならないという別の問題も発生しており、気付かないうちにcron.yamlのアップロードに失敗したり成功したりを繰り返している謎の挙動になっていた。
失敗したり成功したりはサーバー側で発生しており、デプロイを行うのがgcloudコマンドでもappcfgでも同じ状況。

どうやら次の繰り返しになっていた。

  1. cron設定が無い状態
  2. cron.yamlをアップロード → これは成功し6つすべて反映される
  3. 別のCIでcron.yamlをアップロード → Internal Server Errorが発生し、6つのcron設定のうち3つだけが何故か残っている状態に
  4. 更に別のCIでcron.yamlをアップロード → Internal Server Errorが発生し、残り3つも消えて、cron設定がない状態に
  5. 0に戻る

cron設定が3つ以下の場合は、上の挙動の3番目が抜けるだけで成功と失敗を繰り返しすのは一緒。

今回の現象が起きる前から6つのcron設定を 同じCIで常にデプロイしていたが、失敗はしていなかった。
1つ日本語のdescriptionも混ざっていたが アップロード出来ていた。
おそらく6つすべて日本語に書き換えたため発生した。

推測と対応

cron.yamlを書き換えつつ gcloud app deploy cron.yaml --project foobar を何度か実行した結果から、次のような現象だと推測している。

  • cron.yamlのアップロード処理は既存の設定を一旦全てクリアするため、3つずつ削除している
  • そこに日本語のdescriptionが含まれていると失敗しInternal Server Errorになる
  • 消し損ねたものは 次にcron.yamlをアップロードする時に削除される
  • そのためcron設定が4〜6つある場合は、2回アップロードに失敗して（3つずつ削除して）全て消しこんでからでないとアップロードに成功しない
  • 既存の設定のdescriptionに日本語が含まれている時に発生するので、一旦すべて削除したから英語のdescriptionだけのcron.yamlをアップロードすると成功するし、その後も英語のdescriptionであれば問題ない

というわけで、一旦空のcron.yamlを 2回アップロードして（2回Internal Server Errorにして）から英語だけのdescriptionのcron.yamlを 何度かアップロードしているが、今のところエラーは発生せず反映されている。
また、コメントに日本語入っているのは問題ない様子。

TODO issue登録

投稿者 mstssk 0 コメント ラベル:

2017年8月5日土曜日

えいえんのケチャガールへの道＆C92宣伝 #Splatoon2

Splatoon2のはじめてのフェスでしたね！
今回はマヨネーズvsケチャップで、ケチャップ側につきました。

2017/08/05のお昼頃からはじめて休憩はさみつつ2時間半弱で、フェス称号のカンストである「えいえん」まで行きました。
ちょうど30戦やって勝ったのは18戦でした。勝率60％でしたが、正直もっとうまく立ち回らないとガチマッチで上にいけないなー、という気持ちになりました。

戦績をメモっていたので簡単に振り返ってみます。

最初N-ZAPを使っていて何度か黒が付いたので、遠目から着実に立ち回ろうとジェットスイーパーに切り替えましたが、むしろ近づかれて倒されるシーンが増えてしまいました。
あとで確認したら、N-ZAPでは7割弱だった勝率が、ジェットスイーパーでは６割に落ちていました。
もう少し近距離にも対応できるようデュアルスイーパーに切り替えましたが、そこから連敗してもっとひどい状態に。
そろそろデュアルスイーパーに慣れて勝ち星が付き始めたところで、「えいえん」に到達しました。

ブキ別勝率 N-ZAP ジェットスイーパー デュアルスイーパー
勝率 69.23% 60.00% 42.86%
回数 13 10 7

ステージ別の勝率を見ると、母数が違うので一概には言えませんが、海女美術大学が一番勝てています。
海女美術大学は侵攻ルートが限られていて守りやすいので堅実に立ち回っていれば巻き返せるステージです。

一方でバッテラストリートの勝率は芳しくありません。
押し込みまくっって勝つか、その逆をやられて大敗するか５分５分な感じでした。味方の状態を見てもっと堅実に立ち回って前線を確保できていれば勝率は改善できそうだと思います。

ステージ別勝率 コンブ ミステリー タチウオ 海女美術大学 バッテラ
勝率 0.00% 66.67% 66.67% 71.43% 50.00%
勝ち星/回数 0/1 6/9 2/3 5/7 5/10

30戦全体の戦績は次のとおりです。

勝敗ステージ称号のタイミング備考
1loseコンブふつう12:30開始, N-ZAP
2winミステリー
3winミステリーまこと
4winタチウオ
5winミステリー
6winタチウオスーパー
7loseタチウオ
8win海女美術大学13:00ステージ変更
9lose海女美術大学
10winミステリー
11winバッテラ
12winバッテラ
13loseバッテラ
14winミステリーカリスマジェットスイーパーに変更
15loseバッテラ
16loseバッテラ
17winバッテラ
18winミステリー
19win海女美術大学
20win海女美術大学
21win海女美術大学
22loseバッテラ
23loseミステリー
24loseバッテラデュアルスイーパーに変更
25lose海女美術大学
26loseミステリー
27win海女美術大学身内戦
28winバッテラ
29winバッテラ
30loseミステリーえいえん14:48えいえん到達

おまけ(宣伝)

今夏もコミケ(C92)に行くんですが、一緒に出展するvvakameさんが「負けたくない！Splatoon2」という出すそうです。
レビューで読ませてもらいましたが、チームプレイの心構えといったところから書かれていて、Splatoon2を知らなくてもある程度楽しめる内容になっています。この本自体の入稿体験記も載っています。

俺も「Edge of Android 8」という本に「ツは通知のツ」というタイトルでAndroid 8 Oで大きく変わるNotification関係について書いてます。

投稿者 mstssk 0 コメント ラベル: , ,

2017年6月18日日曜日

ng-japan 2017に行ってきた

ng-japan 2017に行ってきました。
ツイートとスライドをまとめただけの記事です。

Keynote: How to Think About Angular



RxJSを活用したアプリケーション開発

CQRSを学ぶために「.NETのエンタープライズアプリケーションアーキテクチャ第2版　.NETを例にしたアプリケーション設計原則」という本を使っているそう。

You need to know SSR

 

Angularアプリのテストについて

Web Payments + Credential Management API

これはAngularのトークではなく、ブラウザでの支払いフォームなどの改善や新機能の紹介。
※スライドのURLを見つけられなかった。

Apple Pay JSをPayment Request APIと同じように使えるwrapper
https://github.com/GoogleChrome/appr-wrapper

Angular, Firebase, Cloud Functions for Firebase

スライド


関数型はモテる。

Advanced Component styling with Angular (v4+)



Best practices for modules in Angular



Angular Animations

スライド

What's New in Angular Material

Autocomplete や Datepickerふえたよー。今後も対応部品増やしていくよー。というトーク。



投稿者 mstssk 0 コメント ラベル: , , ,

2017年5月17日水曜日

Google I/O 2017 初渡航KPT（非技術記事）

初渡航だよ。

2017/05/15に入国、16日までの時点での気付きを、雑だけどKPTにまとめてみた。 最終日までにアップデートはあるとおもう（記事を更新するとは言っていない）。

登壇予定の Google I/O 2017 フィードバックセミナー もよろしく。

Keep

  • 成田の出国ゲートの職員さんが可愛かった
  • 自動化ゲートの登録をしておくと、入出国の手続きがスムーズになる
  • 無印良品のネッククッション
    • 飛行機の中で寝る時に色んな形で使える。首に巻いてネックピローにしてもいいし、抱きまくらにもなる。座席で同じ体勢で寝続けるのが辛いので色んな形になるこの商品がちょうどよかった。
  • 耳栓
    • 機内は大型のトラックや重機のエンジンのそばにいるような騒音が鳴り続けてます。それが高速道路を車で走ってる時くらいにはなる。
  • 1日余裕を持って現地入りする
    • 到着したその日は時差ボケで眠すぎてほぼ何も出来ない

Problem

  • 時差ボケ
    • ホテルにチェックイン直後に寝入ってしまった(日本時間で深夜だった)
    • 2日目も同じ時間帯(日本時間では深夜)に眠くなってしまった。
  • SIMのアクティベートのミス
    • ZIP SIMというのを購入した。SIMを入れた直後に滞在地のZIPコードをSMSで送ると、そこの地域の電話番号が割り当てられる。
    • ZIPコードを送らないと、ランダムな電話番号が割り当てられる。カリフォルニアに居るのに東海岸エリアの番号になってしまった。
    • ※参考: https://www.amazon.co.jp/dp/B01ESSHHSM の商品説明
  • SIMの電話番号重複
    • 以前別の人が使っていた番号らしく、知らない電話がかかってきたり…
    • Uberも↑のせいで登録できずサポート問い合わせ中
    • Lyftは同じ番号を使っていた別人のアカウントを引き継ぐかとか聞かれてしまった
  • 旅行用に買った安い財布のジッパーが開けづらかった
  • 耳栓のサイズ
    • サイレンシアのMだと少し大きかった
  • アイマスク使わなかった。
    • 狭い機内で荷物の出し入れが大変だったので、横着して席に元々あったブランケット被って凌いでいた。
    • 帰りはちゃんとアイマスク使ってみよう。
  • 喉の乾燥防止用のマスク
    • 同上
  • 衣類をTシャツと下着とセットで圧縮袋にいれておいたが、探しづらい。
    • 一方で、Tシャツだけ下着だけの圧縮袋に分けると、1度目に着替えを取り出す時に全部解凍することになる…

Try

  • 財布はもっと使いやすさを考えて買おう
  • プリペイドSIMでUberやLyftなど電話番号が必要なサービスを登録した場合
    • 後で電話番号の登録を消したりアカウントを消したりしておく
  • 衣類は小さめの圧縮袋に種類ごとにまとめて入れておく
    • 種類ごとにすることで探しやすくする
    • 小さめのもので小分けにしておくことで、ちょっとずつ解凍できるようにする
投稿者 mstssk 0 コメント

2016年10月25日火曜日

golang.tokyo #1 行ってきたメモ

2016/10/25にメルカリで行われたgolang.tokyo #1に行ってきたメモ
http://golangtokyo.connpass.com/event/39965/

Twitterのハッシュタグは #golangtokyo

知らない名前がたくさん出てきて半分以上聞き漏らした

メンバーのGo教育

  • レビューでGoっぽくない書き方を指摘するときは、blogとか外部の資料を参照して指摘する（レビュワー個人の意見ではなく一般的な点だと伝える）

IDEやデバッグ

  • vim, InteliJ, Atom, emacs
    • だいたい何かしらプラグインがある
  • 会場内でデバッガ使ってる人はあまりいなかった
  • Bleveっていうのがあるらしい

コーディング規約は？ レビューの指針は？ golintに従ってます？

  • 変数名は簡潔にする（Goの文化）
    • でも事業ドメインなコードを書く場合どうしても説明的になっちゃうのは仕方ない
  • 正規表現のMustCompileの使い方
  • golintは対応しておこう
    • ただし辛い場合はベストエフォートで。
    • golint使っとくと、いけないコードをパートナーに指摘するときに言いやすい。

Webフレームワーク・テンプレートエンジン・ORM

エラー処理どうしてますか？

  • pkg/errors
    • 外部ライブラリがまともなエラーを返さない場合にいい感じにwrapしよう
  • errgroup
  • 必須なものがないとかいう場合は積極的にpanic使おう

goのお手本になりそうなもの

ロガー

パッケージ分け

責務で分けたい？機能で分けたい？

  • ドメイン単位で切る
    • ニュース、ユーザーとかのドメインで分けてその中でデザインパターン
  • internalパッケージはライブラリを作るのでなければ使わない方がいい

テスト周り

  • GAE向けのアプリ使う場合でも、出来るだけgo本体だけで完結するようなロジックにして疎にしておく
  • テスティングフレームワーク使わない(testingのみ)
    • テストのためだけのミニ言語を覚えるとかめんどいし、後からのメンバーの受け入れコストもある
  • 出来るだけDBのテストは書かない
    • データはすべてinterfaceを定義しておけばモックできる
  • できるだけDB立ててテストするべきだよ派も

デプロイまでのフローとか工夫してる点、CI

  • goは基本ビルドが早い
    • 循環インポートとか周りから依存されまくってるパッケージが変わるとキャッシュが使われずフルビルド走っちゃう。ビルドが遅い場合は設計が悪いかも。
    • kaneshin「そういう事があって、ペアーズのビルドは遅くなっちゃってる。別に一人で書いてるやつは早いけどね！」
  • 本番ビルドはChatOpsで3回コマンド叩かないといけない、とか
    • 3回の中で他メンバーのチェックを入れるようにしたり

pprof使ってる？本番のモニタリングとかチューニングとか

  • pprofでなくdd
  • stringを+で繋ぐな、とか地味なやつ

リファクタしたいところ／Goのイマイチな点

  • テンプレートエンジン…
  • timeのフォーマット…

メモ

パッケージの分け方について

投稿者 mstssk 0 コメント ラベル: ,

2016年3月10日木曜日

El CapitanでBlockdiagのインストールに失敗した

事前に入れておくべきソフトウェアを入れてなかったので、遠回りしたよ。という話。

ちゃんとドキュメント読まなかった自分への自戒のために記す。

環境

  • Mac OS X 10.11.3 El Capitan

現象

これで行けるらしいがeasy_installでエラーになった

brew install freetype
sudo easy_install blockdiag

試したこと

  • easy_installのアップデートしてからインストールしなおし 
    sudo easy_install -U setuptools
  • こんどはPillowがねーよって言われたので入れる 
    sudo easy_install pip
    sudo pip install Pillow
  • funcparserlib「フハハハ、Pillowを倒しても俺が」
    sudo pip install funcparserlib

これで動くようになった

投稿者 mstssk 0 コメント

2015年11月15日日曜日

Android StudioとGradle wrapperが違うdebug.keystoreを使う問題

TL;DR

関連issue

Issue 162179 - android - Android Studio and Gradle wrapper use different default keystore - Android Open Source Project - Issue Tracker - Google Project Hosting
https://code.google.com/p/android/issues/detail?id=162179

嘆き

色々試した↓結果

それっぽいissueを見つける

真理に至る

投稿者 mstssk 0 コメント

2015年6月2日火曜日

Wii Uを買って面倒くさい繋ぎ方をした

イカのアレがやりたくなったので、Wii Uを買いました。

しかし、テレビを持ってないので、PC用のディスプレイに繋げてます。 しかもHDMIじゃない。
音声は別出力にしてスピーカーに繋げたりで、ちょっと面倒くさい感じになりました。

構成

基本的にまとめwikiの通り。
Display側がDVI-Dでも問題なく繋がって、1080pで映像出力出来てます。

.   Display           スピーカー
    (DVI-D)               |
       |       ステレオ-ミニプラグ変換ケーブル
       |                  |
HDMI-DVI-Dケーブル      AVケーブル----コンポジット映像※使わない
       |                  |
     (HDMI)          (AVマルチ出力)
    Wii U本体 -------------+
  • Display: Dell U2311H
  • スピーカー: Dell AX510PA TFTモニタ用スピーカ
  • HDMI-DVI-Dケーブル: だいぶ前に買ったやつ
  • AVケーブル: Wii U専用AVケーブル
  • ステレオ-ミニプラグ変換: CN-2010A, AP-119A
    <追記 2015/06/06> 変換ケーブルとコネクタの多段はさすがに邪魔だったので、 35SF-R2V を秋葉原ラジオセンターで買ってきた。なんでもあるねあそこ。

繋ぎ方・設定の仕方は、任天堂の説明ページ「 接続例：アクティブスピーカーを使用する場合 」を参照。
設定には、Wii Uの本体のシステムバージョンが4.0.0J以上にアップデート済みである必要があります。

参考

投稿者 mstssk 0 コメント ラベル:

2015年5月30日土曜日

Nexus9にAndroid M Previewを焼く

Android MのDeveloper Previewが公開され、システムイメージも公開されました。
焼く手順は Flashing Instructions に書いてありますが、実際やったら躓いたのでメモ。

環境

  • Mac OS X 10.9.5
  • Android SDKなどはセットアップ済み
  • Nexus9はまだOEMロックしたままだった

手順

  1. Nexus9の開発者オプションで「OEMロック解除」の許可にチェックを入れる。
    ※Androidのバージョンによっては表記が違うかも。
  2. 下記URLからNexus9用のシステムイメージ(volantis-MPZ44Q-preview-d15ad483.tgz)をダウンロードし、解凍する。
    http://developer.android.com/preview/download.html#images
  3. Nexus9をUSB接続する(ADB接続できるようにしておく)。
    adb devicesとか叩いてADBが繋がること。
  4. adb reboot bootloaderを実行する。
    Nexus9にHBOOT(Nexus9のブートローダー)の画面が表示される。
  5. fastboot oem unlockを実行する。
  6. Nexus9の画面が切り替わり、OEMアンロックするかどうか確認される。
    Volume UpキーでYesを選択する。
    データがクリアされた後、ブートローダーの画面が表示される。
  7. ダウンロードしたシステムイメージに同梱されてるflash-all.shを実行する。
  8. なんかエラー出た。
    target reported max download size of 518205818 bytes
    archive does not contain 'boot.sig'
    archive does not contain 'recovery.sig'
    fastboot(13207,0xa14a01a8) malloc: *** mach_vm_map(size=2132963328) failed (error code=3)
    *** error: can't allocate region
    *** set a breakpoint in malloc_error_break to debug
    failed to allocate 2130828644 bytes
    error: update package missing system.img
    image-volantis-MPZ44Q.zipの中身の焼きこみに失敗してるらしい。
  9. image-volantis-MPZ44Q.zipを解凍して、中身の各imgファイルを書き込むコマンドを実行する。
    下記をすべて実行する。
    fastboot flash boot boot.img
    fastboot flash recovery recovery.img
    fastboot flash system system.img
    fastboot flash cache cache.img
    fastboot flash vendor vendor.img
  10. 終わったらリブートする(ブートローダー画面でREBOOTを選択)。
    Android M Previewが起動する。
    ※必要ならOEMロックする。ロックするときもデータはクリアされる。

参考

投稿者 mstssk 0 コメント ラベル: , ,

2015年5月29日金曜日

Google I/O 2015 Keynote

Google I/O 2015 Extended Tokyoで観たKeynoteのメモ

  • date : 2015-05-29
  • place : 六本木TOHOシネマズ

Keynote

全周囲スクリーンでピンポンやってた

Android M Developer Preview

  • 品質改善を目指す
  • バグ修正
  • プラットフォームの抜本的な要素の見直し

カスタマイズ重点

  • App Permissions
    • AppOpsがちゃんとリリース
    • 機能の使用時にユーザーが許可/不許可を選べる
      • もちろん、本体設定で後で(または先に)変更できる
    • 8つのパーミッション？
  • Web Experience
    • Chrome Custom Tabs
    • タブをプリフェッチ？
  • App Links
    • Intent起動を賢く出来る？
    • ユーザの選択を奪うだけに見えた
  • Mobile Payment
    • Android Pay
    • 決済サービス
    • 実店舗でもアプリ内でも
  • 指紋認証(Fingerprint Support)
    • Password Credentialとして使える
    • デバイスアンロックとか
    • Play Storeで購入時の認証にも
  • Power & Charging
    • Doze というプロジェクト？
    • Nexus6にM乗せたら、2倍電池が持つようになったよ！
    • USB type-Cで高速な充電
    • Android端末自体をモバイルチャージャーにできたり
  • 細かい所の使い勝手改善
    • コピペのUIとか
    • 音量設定UI
      シークバーの所に着信音・メディア音量・アラームの3つのシークバーが並ぶ。
  • その他いろんなfeatures
    • 「最も洗練されたバージョンです」
      ↑いつも言ってない？

Android Wear

  • 機種が増えてるよ！
  • ウォッチフェイス大事！
  • always on
    常にウォッチフェイスを表示できるようになった
    白黒のLow-powerモード
  • 手首をひねる動作で操作できる
  • 手書きでEmojiを入力できる(手書きしたものを認識して対応する絵文字を探す)

Brillo

  • Internet of Thingsのためのもの
  • Androidからの派生
  • IoT的な機能を最小限のfootprintで実現できるように
  • Weaveというスキーマ?
    JSON
    クラウド,電話,Brilloデバイスを繋ぐAPI

BrilloのDeveloper Previewは第3四半期
Weaveのは第4四半期を予定

検索の改善

  • 画像認識の進化
    ニューラルネットワークによるDeepラーニング
  • コンテキストを含めた検索

Google Now

  • 3つの柱
    • Context
    • Answers
    • Actions

Now on Tap

  • Android Mの新機能
  • より深くコンテキストを理解して検索する
  • しかも音声認識で自然言語検索
  • アプリ側の変更は不要
  • デモ
    • 音楽を再生中に「彼の本名は？」と音声認識で聞くと、そのアーティストの本名が出てくる
    • 「○○という映画を見に行こう」というメールで使えば、映画の情報を出してくれる
    • レストランで読み方がわからないメニューがあった時、画像検索してみる
      適当にそれっぽく読んでも、メニューを見ているというコンテキストを理解して検索してくれる.

Google Photos

  • (アイコンは見覚えあるけど) 新しいサービス
  • 写真・ビデオをうまいこと整理・管理してくれるサービス
  • 人・モノ・場所によって自動で分類
  • 写真の内容を画像解析済みなので「トロントの大雪」で検索すれば、 ちゃんとその時の写真が出てくる。
  • 複数選択の賢いUI
    1つ長押しして選択状態に -> そのままドラッグして範囲選択！
  • 一覧で年月日の細かさをピンチイン/アウトで切り替わり
  • 相手がアカウントを持っているかとかログイン済みかとか気にしないで共有できる
  • 無制限・無償なバックアップストレージ
    どんな高解像度・巨大なファイルサイズでもよい
    今日からすぐ使える！
    (※なにそれこわい)

次の10億人へ向けて

　いろんな取り組みの紹介

  • Google Translatesのビデオ
  • 次の2年で12億のスマートフォンが増える
  • Android oneデバイスが新興国でどんどん増えてる
  • Chromebookも普及してきてる
  • しかしネットワークはまだ遅い。なので最適化をしている。
  • ChromeのOffline Support
  • Google MapのOffline Maps対応を目指している
    オフラインでも周辺の施設を検索したり
    そのまま音声案内ナビゲーションを開始したり

開発者へ

Develop

  • Android Studio 1.3
    • C/C++ サポート
    • Gradle早くなる？
  • Polymer 1.0
    • Polymer Elements
  • Cocoapods
  • Cloud Test Lab
    • apkをアップロードすると、世界のトップ20の機種でのテストをしてくれる！
  • Firebase

Engage

  • App Indexing
    • めっちゃAppLinkがある
    • iOSでも実験中
  • Cloud Messaging
    • iOSサポート
    • Android, iOS, Chrome の3つのプラットフォームで
  • Chrome
    • Push Notification
    • Add to Home screen
  • App Install Ads
    • iOSサポート
  • Google Play
    • デベコンでもっといろんな情報を見れるように
    • Analytics
    • Play Store Listing Experiments
    • Developer Pages
      • 開発者が自分の他のアプリを紹介したり出来るページをPlay上で
  • AdMob
    • Analyticsしてるよ
    • メディエーション増えてる。直近だと中国のTencent

Google Play上でのアプリの検索

  • 10億人ものユーザがいる
  • どうやってアプリにリーチさせるか
  • 検索結果のカテゴライズ
    • 例えば「ショッピング」で検索すると、 検索結果はファッションやクーポンなどといったカテゴリに分かれている
  • Family Star
    • 家族向けコンテンツ

Cardboard

  • Google Play上にいろんなアプリがすでにある
  • CardboardのSDK改善
  • 改善した新しいCardboardを配るよ！
    磁石スイッチとか

Expeditions

  • Cardboard遠足
  • 複数のCardboardに同じコンテンツを表示させる
  • 世界のいろんな場所をCardboardで観られる
    万里の長城でもベルサイユ宮殿でも

Jump

  • Cardboardコンテンツを作るためのもの？
  • 360度撮影とコンテンツ作成までのフレームワーク的な？
  • Camera Geometory, Assembler, Player
  • Camera Geometory: 360度を16台のカメラで撮影
  • Assemblerでそれをゴニョる
    • 撮影した写真から奥行きや、モノの配置などを認識する。
      元はただの写真だが、各カメラの撮影した部分の被った部分で頑張るみたい
  • Player: YouTubeっていうのがあってね

最後

自動運転や、気球による通信基地局提供プロジェクトなど進めてるよ！ また来年！

投稿者 mstssk 0 コメント ラベル: , ,

2015年5月27日水曜日

shibuya.apk の雑なメモ

shibya.apk 行ってきました！

※当日の内容は網羅してません。気になったトコだけメモしてたものにちょっと毛を生やした記事です。

日付： 2015-05-22
場所： DeNA

発表1. それwebでよくない？

Webアプリを普通のアプリと同じように動かす仕組みが出来てきている。
なので、Webでよくない？という話。APKじゃねぇ

  • Web App Manifest
    • locationバー非表示にする設定とかできる
    • Chromeで「ホーム画面に追加」したアイコンから起動すると、Overview screen(Recent Apps)でアプリかのように表示される
      ※ Chromeの「タブとアプリの統合」をOFFにしていても、別のアプリのように振る舞う
  • Service Worker
    • WebアプリとNativeアプリとの差を埋めるためのもの
    • オフラインでもキャッシュを返したりとか
    • サービスワーカーでfrontに返すデータをinteruptしたり、キャッシュしたり
  • WebPush
    • Chrome 42からWebでも通知出したりできる
  • Web App Install Banner
    • Web標準仕様ではない
    • Web App Manifestが条件に合致すると、Chromeがホームへの追加をサジェストする

発表2. Meets Jack and Jill

「全部qiitaに書いておいたからメモ取らなくていいよ！」

Android - Meets Jack and Jill - Qiita
http://qiita.com/calciolife/items/faf6affc0f8cf70c4af9

  • 最適化しつつコンパイルするよ！
  • ARTにとって良くなるようにバイトコードを最適化とか

発表3. fabricの話

wasabeefさんに代わり、Flockで来日していた@romainhuetさんが発表することに。

https://get.fabric.io/

  • FlockでiOS向けに話した内容をAndroidに向けに変えて話してくれた
  • fabricは、Twitter社が提供するアプリを作るための色々なサービスを含むブランド？みたいなものらしい
  • ClashlyticsとかMoPubとか
  • Digitsがちょっと気になった
    • SMSによるユーザ認証の仕組みを提供するものっぽい
    • SMSの送信数に制限無く、現状無料で使えるらしい。まじで！？

懇親会

LTしたらTwitterのTシャツ貰えました！（ジャンケン大会で配られたものと同じ）
でも、飯食いそこねました！

アプリの通知をLollipop対応しよう / shibuya.apk 2015-05-22 LT // Speaker Deck
https://speakerdeck.com/mstssk/shibuya-dot-apk-2015-05-22-lt

LTの内容は、C87で甘味アンドロイドパークに書いたのをまとめたもの。
テクブ本のお求めはBOOTHやCOMIC ZINで。
関係者を倒してもドロップはしません。

投稿者 mstssk 0 コメント ラベル: , , ,

2015年5月11日月曜日

DroidKaigi私書録

去る2015年4月25日、DroidKaigiを開催しました。ご来場頂いた方々ありがとうございました。

私は運営メンバーとして参加し、主にWebサイトの管理・構築をしていました。
勿論、当日はスタッフも！

色々思い出しつつつらつら振り返ってみます。

DroidKaigiのWebサイト

りんご、Webサイトつくってよ ──── mhidaka

そんな感じでカジュアルに誘われ、ほいほい付いて行ったのが第2回のDroidKaigi事前ミーティングでした。
そのMTGが1月27日。
そこから1週間後の2月3日には、CFPのためWebサイト公開までこじつける事になろうとは、思いもよりませんでした*1。

WebサイトはGitHub Pagesを使ってます。 独自ドメインの取得も考えましたが、今回は手弁当でやる方針が決まっていた事もあり droidkaigi.github.io で公開しました。

CFP開始予定まで時間がなかったので、最初はBootstrapでえいやと一人で手っ取り早く作成。 公開前にデザイナーさんにアドバイスを頂いて細かい部分を手直ししたりしました。 公開後も、ところどころの修正を他メンバーからガシガシPR貰って直したり。 なかなかGoogleで検索結果上位に来ず、sitemap.xmlを導入しようとしたら、間違ってサイトが30分ほどすっとんでたのはいい思い出です。

CFPは別にGitHubのissue上で揉まれて作成された文面を載せてます。 CFP担当のメンバーもギリギリなスケジュールの中頑張ってました。

採択したセッションの公開のタイミングで、@yulily100さんにデザインして頂き、 Jekyllを弄ったりなどの技術面を私がやる体制に。 ゆりりーさんは「デザイナーがXMLを書くことでできる改善しやすいアプリ開発」というセッションで登壇もされています。

実は、DroidKaigiアプリ のためにセッション情報を取得するAPIなんてのも作っていました。 Jekyllでjsonを書き出してるだけですけどね。アプリ開発のスケジュール都合上使いませんでしたけど。

Webサイトを作った際の知見については、 「DroidKaigiのWebサイトの作り方」 という記事でまとめています。内容被ってますが、こちらもどうぞ。

アイロンプリントしてました

背中からアイロン台がはえるよ ──── mhidaka

DroidKaigi当日、早朝の渋谷マークシティにアイロン台を背負い現れる、我らがDroidKaigi実行委員会代表の言葉です。

ご来場頂いた皆さんは、運営メンバーが公式Tシャツに「圧倒的当事者意識」とか、何やら色々と貼り付けていたのをご存知だと思います。 私はアレを前日に都内某所で印刷してました。
そしてあの当日、サイバーエージェント社セミナールームの衝立に遮られた向こう側、スタッフの控えブースにはアイロン台が鎮座していたのです。

ちなみに、私は自分のアイコンを背中に貼り付けてました。
個人的には「ｱﾝﾄﾞﾛｲﾄﾞﾁｮｯﾄﾃﾞｷﾙ」を貼り忘れたのが心残りです。

圧倒的当事者意識

上でも触れましたが、DroidKaigiの運営メンバーの中で、何故か圧倒的当事者意識という言葉が流行っていました。 コミュニケーションで主に使っていたSlackでは絵文字にする始末*2。

Slackの絵文字を追加するのは簡単です。 設定ページにアクセスして、 絵文字名を ati と入力して、 画像を選択し、 「Save New Emoji」をクリックするだけ。

この言葉は某社の標語から来ていますが、DroidKaigi運営内の使い方はどうやら本家とは違ってたらしいです。
本家某社内では「ATIを見せてくれ」って感じで何かをお願いする際に使うのが主だそうですが*3、 DroidKaigiの運営内では「すごいATIだ」という具合にthumb up的に使われる場合のほうが多かったです。

当日

当日の朝、集合時間が迫る渋谷駅を見事に乗り過ごした所から一日がスタートしました。
当日の担当は基本的に受付係。あとは雑用があれば手伝って、という具合でした。

私は基本的に部屋Bの方にいたので、Aのセッションが聞けていません… orz
Twitterのログやらスライドやら見てたら、「デブは電車に乗るな」とか謎ワードが目に飛び込んできましたよ！？

運営に参加して

こういったイベントの運営に関わるのはかなり久々のことでした。 おそらく、大学祭の実行委員やってた以来です。

私が参加してから4月25日当日までの数ヶ月間、大変でしたが苦ではありませんでした。
きっと、あんまり仕事しなかった圧倒的当事者意識を持った優秀なメンバーと一緒に携わることが出来たからです。

DroidKaigiの運営メンバーは、呼びかけで集まった有志のエンジニアです。
所属する会社はバラバラで、ミーティングの際には各社の社内用語が飛び交って、意思疎通に軽く難が出るという一風変わった出来事もありました。
それでも、issue tracker(GitHub)とチャットツール(Slack)があれば上手く行くあたり、流石はエンジニアの集まりという感じでした。

今回の盛況ぶりで、こういったイベントがAndroidのエンジニアに需要があるということが明確になりましたが、問題点も多々ありました。 特に、ご来場いただけなかった方々には申し訳なく思います。 DroidKaigi自体は終わりましたが、まだ反省会やらなんやら内々でやることは残ってます。 羊さんがクロージングトークで何やら話してましたしね。

何はともあれ、登壇して頂いた皆さん、ご来場頂いた皆さん、運営メンバーの皆さん、ありがとうございました。

  1. でも、てくぶのC87特設サイトも1週間くらいで作ってたから、毎度のことかと考えなおしつつある。
  2. なんとかりんごって奴がやった。
  3. 又聞きなので違ってたらすみません。

投稿者 mstssk 0 コメント ラベル: , ,

2015年4月30日木曜日

DroidKaigiのWebサイトの作り方

DroidKaigiに来ていただいたみなさん。ありがとうございました！

私は運営メンバーに参加して、Webサイトの構築・管理とかしてました。

CFP開始当初は時間がなかったので、私がえいやとBootstrapで作成。
ただし、公開前にデザイナーさんにアドバイスを頂いて細かい部分を手直ししたり、公開後も他のメンバーからガシガシPRを貰って手を入れていきました。
採択セッションの公開時のあたりで、デザインをゆりりーさんにお願いし、私が技術面を担当する体制に。

サイトはGitHub Pagesを使ってます。 今まではペライチのHTML置くくらいにしか使ってませんでしたが、DroidKaigiのサイトではも少しちゃんと機能を使ってます。

本記事ではその辺をまとめてみます。

※ Androidの話は全くしません。

リポジトリ

  • GitHub PagesのOrganization siteとしてリポジトリ作成
  • organizationname.github.ioという名前でリポジトリを作ると、masterブランチの内容が同名のURLで公開されます。
    • Organizationじゃなく、個人ユーザーの場合も同じ。
    • gh-pagesブランチを使うのはProject siteの場合です。
  • リポジトリはPrivateのままでもGitHub Pagesは公開できます。

CMS（Jekyll+Liquid）

  • GitHub PagesではJekyllが使えます。
    • ただし素のJekyllが使えるわけではなく、あくまでGitHub Pagesのgemを使う形になります。
  • 色々制約があるので、Using Jekyll with Pagesを要参照。
    • 例えば、_config.ymlのsource:〜設定は無視されるので、常にリポジトリのトップレベルにソースを置く必要があります。
      これに気付かずpushしたら、30分ほどサイトがすっとんだ事がありました。
  • Jekyllのプラグインも決まったものしか使えません。
  • テンプレートエンジンはLiquid
  • アクセス時にページを書き出すのではなく、Jekyllの起動時（GitHub Pagesではpush時）に書き出しキャッシュするだけ。
    • なので、インタラクティブなWeb APIっぽいものを作る事は出来ません。
    • 実はセッションリストをjsonで取得できるようにしてあるんですが、それもLiquidで書き出してるだけです。
  • _data/の下にYAMLで任意のデータを置くとテンプレートから参照できます。
    • それでセッションリストのデータを持っています。
    • YAML書き換えるとページとjsonも勝手に書き換わります。
    • Jekyllでは普通_posts/2015-04-24-DroidKaigi.mdって感じのパスで記事を書いて行くようなんですが、 DroidKaigiのサイトではそれは使っていません。
  • Jeykyllで処理するファイルの先頭にはFront Matterを書きます。

テスト

  • YAML使ったり、json書き出したりとかしだしたので、CIでテストもするようにしました。
  • Travis CIで回してます。
  • テスト内容
    • ビルド
    • HTMLの構文チェック HTML::Proofer
    • favicon
    • リンク切れ
    • imgのalt属性のチェックはわざと無視。代替文字が必要なデザインじゃないので。
    • YAML,jsonの構文チェック（パースしてみてるだけ）

テストはとりあえずでいいやとインラインで書いちゃってるけど、どういう書き方がベターなんだろ。

Webフォント

英字はRoboto。日本語はNoto Sans。

その他

ちゃんとSEOとか知ってる人には常識だろうけど

  • 一度設定したOpenGraph用の画像を消す時は注意
    • サイトのmetaタグの画像パスなどを書き換えても、すぐにはFbは反映してくれない様です。
    • デザイン刷新時に古い画像を消したら、一時的にFbのシェア時に画像が出なくなってしまいました。
  • はてブとかツイートボタンとか、ソーシャルボタンはURLが明示的に指定できるならした方がいい
    • 指定がなければ勝手に現在のURLになる
    • http/httpsの違いや、ハッシュの有無で別のページとして扱われちゃう
    • canonical URLも書くべき <link rel="canonical" href="http://droidkaigi.github.io/"/>
  • ページランク
    • サイト公開直後はDroidKaigiで検索しても全然検索結果の上位に来なかった。5ページ目以降とか。
    • てくぶのコミケ用ページをGitHub Pagesで作った時もそうだったんですが、一月くらいは上がらない感じ。
    • 後からsitemap.xmlを用意したりとかしたけど、結局Googleがいつクロールしてくれるかはわからないので…

一緒に書いたけど、ソーシャルリンクについてはどちらかと言うとテクブのサイト作ってた時の知見。
あと、PRのブランチへにpushしたら、どっかにデプロイしてすぐ他の人がプレビュー出来るようにすればよかったなー、と気付いた。 レビューが捗る。

感想記事的なものは別に書きます。

投稿者 mstssk 0 コメント ラベル: , , ,

2015年4月8日水曜日

GitHubのContributionsをIngressのResistance色にするUser Styleを書いた(二番煎じ)

こんにちは。アイコンは緑だけどResistanceの青りんごです。

下記の記事を見て「cssでも出来んじゃね？」って思って書いてみました。

GitHub の Contributions を Ingress の Resistance 色にする Chrome 拡張を作った - I'm kubosho_ http://blog.kubosho.com/entry/change-ingress-registance-color-of-github-contributions

resistance-contributions.css

cssの中身。legendの元の色指定がインラインスタイルだったので、上書きするには!important書かざるを得ないのが悔しい。

StylishといったUser Styleを設定できる拡張機能を利用したりして使う。

before:

after:

あんまりGitHub使えてないなぁ…

投稿者 mstssk 0 コメント ラベル: , ,

2015年3月8日日曜日

Unicodeの絵文字の肌の色ゴタゴタについて思ったこと

※Twitterに書きなぐった事をまとめるだけの記事です。

Unicodeの絵文字の話について、考えてた時にふと思ったこと。

元々は↓の流れ。

投稿者 mstssk 0 コメント ラベル: ,
登録: 投稿 (Atom)