昨日はtoguriさんのVRを追いかけるゼミやってますでした。 360度動画がFacebookで見れるようになったり、コロプラさんが白猫のVR化や株式会社360Channelを設立したりとホットな技術。PlayStationVRもお披露目されましたし、盛り上がってるんですね〜！明日は@yudpppさんです。

今日の記事では自分が携わっているスマホの同期アバターサービスで
どのようにリリースサイクルを回しているかを紹介したいと思います。

特に

リリースサイクルのボトルネックはどこか
リリースサイクルと強く結びついているテスト
バグなくリリースするために心がけていること
iOS/Android両プラットフォームリリースオペレーション

について触れていきます。

同期サービスが故に行っている、iOS/Android両プラットフォームの同時リリースオペレーションのノウハウは稀かもしれませんが、工夫ポイントでもあるので少し詳しく紹介させてください。

アバターサービスの技術スタック

フロント

9割がCocos2d-xで実装
テキスト入力、ピッカー、アルバム取得などはネイティブ(Java/Objective-C)

サーバー

Node JS, Mongo, Redis

通信は同期系通信(発言、ユーザーの位置情報など)はMQTT、ユーザーのタップドリブンの通信はhttpsで行っており、シリアライズにmsgpackを用いています。
私は職種としてフロントエンドで、C++からUIKitやAndroidSDKにブリッジする部分やネイティブに依存する部分、例えばサードパーティ SDK組み込みやPush通知、課金周りを主に開発してきました。

それもあって、Google PlayStoreやiTunes Connectをよく触っていたためリリースフローに各プラットフォームの仕様などを還元することがありました。

リリースフローについて

まずは、リリースフローについて紹介します。

おおまかなリリースフロー

f:id:matsuokah:20151212045055p:plain

↑はチームで実際に使っているガントチャートに近いもので、以下のことを管理しています

いつどのバージョンのどの機能がテスト可能になるのか
いつどのバージョンを申請するのか
いつどのバージョンをリリースするのか
特筆すべきこと(iOSアプリの64bit対応やATS、IPv6対応のデッドなど外部要因であり無視できないもの)

また、このガントに載る機能の情報は要件定義が終了し、開発が進められる状態のものです。
チーム全体のスケジュールがここに集約されているため開発陣はもちろん、マスタデータの管理者やテストチームに共有されており、共通認識を持つことで円滑にテストまで行けるようになっています。

フローを説明すると

staging環境のアプリを準備（タグ切り）
staging環境にて仕様テスト、強制終了箇所が増えてないかのモンキーテスト
Apple Storeにアプリを申請
Google PlayStoreでβ公開
Apple のレビューを待つ
レビューが通ったら両OSのアプリを同時にリリースする

iOSのレビュー提出日を基準にスケジュールを組み立てる

ネイティブアプリはAppleのレビュー期間がボトルネックになります。言い換えれば、リリースが若干ながらアンコントローラブルということです。
それ故に、コントローラブルであるアプリの申請日を基準に逆算してスケジュールを組んでいます。

前回のリリースからいかに短い期間で申請を出せるかがリリースサイクルを早く回す為の重要なポイントとなります。

リリースサイクルを早めるメリット/デメリット

メリット	デメリット
・新機能を早くみてもらえる・テスト単位を小さくすることができる・バグの修正を早く・ユーザーにアプリを再認識してもらえる	・わずかに離脱するユーザーがいる

圧倒的にメリットの方が大きいです。特に注目したいのが「テスト単位が小さくすることができる」です。テスト単位、コード差分が小さいということは即ちリグレッションリスクを低くできる」ということなのです。

後は、PDCAが早く回せるのでその分アプリの改善をたくさんできるということになります。

また、ホームに埋もれていてもアップデートのバッジによってアプリを見てもらえるので、視覚的な副産物があります。(効果があるのかはわかりませんが笑)

1回のリリースサイクルは約2週間

Appleのレビューにかかるのは約7日、営業日換算で5日です。
更に申請をするまでに組み込む機能の仕様テスト及び、強制終了が増えてないかのモンキーテストを5日とっています。
(現状ではリグレッションテストが行えていないので今後の課題となっています。)

従って1回のリリースサイクルにかかる時間は最短で２週間になります。

定期的に申請までこぎつけるのはかなり骨が折れるので、Facebookが2週間に1度に必ず行っているiOSアプリの定期リリースは心から尊敬しています。

大きい機能をこのフローにのせるには

当たり前ですが、2週間単位のリリースサイクルとはいえ開発する機能によっては2週間の中に収まらない大きな機能が出てきます。

この場合は、トップダウン的に約1~3ヶ月にマイルストーンをざっくりとおいて、大枠が見えたところで2週間のスキームに落としこむという方法をとっています。大枠はボトムアップ的に見えて来ますが、大体トップダウンのスケジュールに着地します。

また、このような機能は仕様が膨大である場合が多いです。つまり5日間のテストにも収まりません。

そこでdevelopment環境の仕様テストを行っています。

stagingと何が違うかというと、ガンガン開発中・仕様が盛り切っていないfeatureブランチのアプリだったり、ひとまず開発者が仕様を盛り込み終わったdevelopブランチのアプリだったりします。サーバーにもテストすべき機能が盛り込まれたアプリをデプロイしてもらっています。

また、テストやデプロイするアプリの管理やテスト依頼などの細かいイテレーションはその機能の担当者がやっています。

development環境でテストすることで、仕様の定義漏れに気づくというメリットがありました。

開発者は意地悪なテストをしません。どうしても自分に都合の良いテストしかできません。なぜなら、その機能をどう使えばいいか知っているからです。

しかし、テスターさんはとりあえず同時タップしたり、SDを抜いたり、サスペンド&レジュームしたり、3G回線エミュレートしたり、電池が少ない状態にしたり、画像が数千枚ある端末でテストしたりします。そうすると、仕様が不明確な部分や、実装が漏れているエラー処理を浮き彫りにさせたり、ストレスがある状況での挙動がおかしい現象を見つけることで潜在バグの先手見つけたりすることができます。それをstagingに前に済ませることで、差し戻しが激減され、結果的にstagingでの5日間のテストで収まるようになっています。

リリース

同期サービスならではである部分を含め、リリースについて紹介していきます。

まず特殊かもしれないポイントですが、AppStoreとPlayStoreでのリリース日を合わせる形にしています。上位互換の無い機能がリリース、致命的なバグフィクスや運用上の都合で強制アップデートが必要になる場合、同時の方が都合がいいからです。

特に新機能はリリースと同時にキャンペーンやプロモーションを行うことが多いので、AppStoreとPlayStoreのリリースのラグを減らすことは運用上で必須事項となっています。

また、フロントのコードはCocos2d-xで実装されており、Android/iOS共にほぼ同じソースである以上、片方だけが不具合になるケースは稀なので同時リリースがリリースサイクルの観点からも最短であります。

強制アップデートの基準

致命的なバグフィックス
上位互換のない機能
プロモーションで必要になる機能の導入やアライアンスなど、運用上の理由

以上の観点で１つでも引っかかれば強制アップデートをするようにしています。それ以外では絶対に行いません。なぜなら、せっかくアプリを遊びに来ているのにアップデートをしないと遊べないのです。

ユーザーは今、この時、アプリを使いたいのです

Androidのアプリのβ公開

社内ではHockey Appを使っており、productionのアプリはダウンロード可能となっています。また、PlayStoreにアップロードするアプリと使っているKeyStoreが同じならば課金も同様にできます。

従って、わざわざβ公開をしなくても動作確認は可能です。

では、なぜβ公開をするのか。公開ボタンを押してからPlayStoreに反映される時間のラグを防ぎ、不具合が起きるリスクを少なくするためです。

直接製品版に公開	ベータ版から製品版にプロモート
1時間〜2時間	3分~15分

実測した結果、上記のようになりました。

ちなみにiOSは公開をポチってから5分~30分です。この取り組みのおかげでAndroidとiOSのアプリ公開の時間差は30分以内に収まっています。

特に新機能はリリースと同時にキャンペーンやプロモーションを行うことが多いので、AppStoreとPlayStoreのリリースのラグを減らすことは運用上で必須事項となっています。

と、先程にも触れたように概ね、iOSとAndroid同時リリースをする上でこのβ公開は欠かせません。

リリースオペレーション

具体的なオペレーションは審査が通った後からになります。ざっくりとまとめると

レビュー通過のメールが届く
営業時間が残り４，５時間あれば当日、少なければ、翌営業日にまわす(障害対応可能時間を増やすため)
iTunes Connectで公開をポチる
Google PlayStoreでβアプリを製品版にプロモートする
AppStore公開される
Google PlayStoreに公開される
必要であれば強制アップデート
アプリ内お知らせやキャンペーン、ツイッターでの告知などのプロモーションを公開する

という、フローで行っています。

特に5,6は今まで述べてきたように分単位で気をつけています。そのための仕組として、リリースを検知してHipChatに通知をするにしています。

手で確認するのも面倒ですし、アプリで確認するとキャッシュが聞いていたり、Androidのβ版のテスターアカウントに関してはすでに公開されているので、製品版の公開タイミングはわかりません。

リリース検知の手法としてはGoogle PlayStore, AppStoreの公開日をスクレイピングして、前回と差分があればリリースと見なしています。(DOMが変わったらメンテが必要)

github.com

AppStoreの例となるスクリプトを載せておくので適当に御覧ください。

リリース祝いも兼ねて通知は少しだけ、待ち遠しくなるようにしています。最近はマンネリしてるかもですが。

PlayStore

f:id:matsuokah:20151212124521p:plain

ペリーキターーーーっ！

AppStore

f:id:matsuokah:20151212124525j:plain

波キターーーーっ！

f:id:matsuokah:20151212125003p:plain

この日は13:00に公開ボタンをポチってから Google PlayStoreが10分、AppStoreが26分だったようです。従ってこの日は16分の時間差で済みました。こんな感じで、少しテンションを上げてリリースしてます↑age↑(´∀｀∩)↑age↑

まとめ

以上、弊社のとある同期系アバタースマホアプリのリリースサイクルについて触れてみました。

他人のお山である以上、リリースサイクルは完全にフレキシブルにはならないものの、コントローラブルなポイントを見つけて、リリースサイクルに落としこむという事が肝になると個人的に考えています。

文字ばかりにはなってしまいましたが、最後までお読みいただきありがとうございました。

2015-11-23

iPhone4からのiOSユーザーがメイン機をAndroidへの乗り換えた話

f:id:matsuokah:20151123163232j:plain

筆者はsimフリー機(iPhone6)をMVNOで運用していたが、docomoのXpria Z5を契約したという話。
乗り換えにあたって「契約まで」と「メイン機の移行」でしたことをまとめてみた。

乗り換えた理由

まず、乗り換えた理由から。理由は5つ

ハードウェア的にでできることが似通ってきた（カメラの高画質化、指紋認証など）
両OSで使えるアプリが増えてきた
Appleの垂直統合的な環境からAndroidへの乗り換えやすさがサポートされてきた
Felica(モバイルSuica, Edy, 会社の入退室カードキー統合)
防水/防塵

iPhone4の頃Androidは便利なアプリはほとんどiOSにしかなく、
Androidは2.3でウェブページのピンチすら重くてブラウジングがままならず、ルートをとってオーバークロックが流行っていたが
今やハードウェアの高性能化とOSやアプリの改善により差がないといえる。

今では両OSでできることがほぼ同じだが、iPhoneにはないのが電子マネーや防水/防塵。
国内で生活する上で電子マネーヘビーユーザーの自分にとって決定的となった。

そして、家のメディア周りがSONYなのでXperiaを選んだ。(BRAVIA, PS4, nasne)
Xperiaはオクタコア(コア数が8)となっており、処理重視4コア・省電力重視4コアという内訳。
処理重視と省電力重視のコアを組み合わせるのはハイスペックモデルのAndroid機ではスタンダードになっている。

契約

f:id:matsuokah:20151123192739j:plain

2015-2016冬モデルのXperia Z5(ドコモ)をヨドバシにて契約。
一括購入によるポイント付加や下取りの査定がゆるかったため、今後は契約はヨドバシですることにした。

家に眠っていたiPhone5(32G)を出した所、傷はそれなりにあったものの下取りは満額の22680円だったので。
また、ソフトバンクショップでは「MNPでの転出元simと使っている端末が一致しなければ引き取れない」と言われたので、ヨドバシではダメ元だったが引き取ってもらえた。

元々、Nexus 5をもっていたが、開発機として購入したため初期化したりOS Versionを上げたり下げたりするためメインとしては使えなかった。

乗り換えてはじめにした設定

ランチャ

f:id:matsuokah:20151123173435p:plain

初期設定ではDocomo標準の使いにくいランチャが設定されているので、まずはここから改善していく。

Nova Launcher Prime - Google Play のアプリ Nova Launcher Prime - Google Play のアプリ

Nova Launcherは売れてるランチャだけあって、あると便利な設定が揃っていて、安定している。

細かなアイコンのレイアウト(グリッド/余白)
デスクトップでジェスチャの
設定のバックアップ/インポート

Nexus5でいろいろ試していて、落ちるアプリがよくあったが、一番Nova Launcherが安定していた。

アイコンバッジ

f:id:matsuokah:20151123184148j:plain

iOSだとOSレベルでサポートされているアプリアイコンへのバッジはAndroidではサポートされていない。
これはランチャに依存している模様。従って対応のランチャをインストールするなり、その設定をする必要がある。

Nova Launcherの場合、デフォルトでバッジをつける設定ができる。
バッジ設定をOnにして、バッジプロバイダアプリを設定すればバッジが表示される。
デフォルトではNova Launcherの開発者が提供するプロバイダがあるが、Missed it!がNova Launcherではおすすめされている。
Missed it!は通知のサマリをウィジット化できるアプリで、デザインや表示フォーマット、サマリに加えるアプリなどをカスタマイズすることができる。

デスクトップ

f:id:matsuokah:20151123183456j:plain

Androidの場合デスクトップが起動時の画面でウィジットをおいたり、
アプリのショートカットを置いたりとカスタムできるところであり、Androidの醍醐味となる所。

※iOSのホームがAndroidの場合、アプリドロワー(即ち、アプリ一覧)に近い。

ウィジット

時計
Calendar
天気
Missed it!
Edy残高
Suica残高
Trello Add Card shortcut

アプリショートカット

連絡/SNS (LINE, Gmail, Slack, 電話, Facebook, Messenger, Twitter, Instagram)
ニュース(はてぶ, Feedly, 日経電子版)
カメラ
タスク管理(Trello)

プリインストールアプリの無効化

３大キャリアあるある。不要なアプリのプリインストールの多さ。

これらを無効化しないと通知も鬱陶しいし、電池持ちが悪くなる気がしている。
そこでルート化なしで可能な範囲で一番最初にポチポチ無効化していった。

AR effect
エリアメール
災害キット
ドコモクラウド
ドコモメール
Enchanted forest
File Commander
FMラジオ
文字編集
NOTTV
ドコモアドレス帳
音声レコーダ
テレビ(ワンセグ)
ドコモ音声入力
ドコモバックアップ
コンシェルジュ

他にもdマーケットなどオフにしたいものがあったが、オフの設定ができないようになっていた。
アンイストールできないアプリもあって非常に憤りを覚える^^;

移行したアプリ


1Password	Comico	DropBox	Facebook	Facebook Messenger
Gmail	Google Analytics	GoogleMap	Googleフォト	HipChat
IFTTT	Instagram	Kindle	NewsPicks	Pocket
PushBullet	Skype	Slack	SmartNews	SoundCloud
Trello	Twitter	WEAR	Yahoo!乗換案内	Yahoo!天気
はてなブログ	クックパッド	スリープサイクル	ヨドバシゴールドポイントカード	日経電子版 \| 食べログ

よく使うもの棚卸しして移行したアプリたち。本当に使いたいアプリは両OSにリリースされてるものが多く、iOSにロックインされることはなくなったな〜、と痛感。

iPhoneに溜まってた写真はすべてGoolgeフォトでバックアップ
1PasswordはiCloud同期からDropBox同期に
他のアプリはそれぞれのアカウントでログインすればいいためほとんど手間なく移行完了。
特にGoogleアカウントログインのアプリはOSレベルでログインがサポートされてるので全く手間がない。

これで移行はできたと思われる。Androidもぬるさくになったし、インテントも便利。
iOSで惜しいのはポップアップの辞書くらい。

おまけ

f:id:matsuokah:20151123195254j:plain

「初期設定してください」という通知をタップしたらこの画面に飛んだ。
バックキーも聞かないし、インストールしか選択肢がない。キャリアまじこわい・・・

2015-11-13

kindleでライトに読めるソフトウェア開発のためのタスク管理・マネジメント本まとめ

読書メモ

本の選び方

タスク管理本は管理の対象がどのくらいの規模なのかを自分に問いかけてから選ぶと失敗しないと思います。

つまり、管理の対象は1人(自分)のをするのか、1,20人未満小規模のチームなのか。規模の大きさによってフレームワークや起こりうる問題などが違ってくるため、自分が何を求めているのかを分析したうえで選ぶ必要があります。

読んでよかったkindle本を、規模や対象に分けてメモ。

自分のタスク管理

図解ミスが少ない人は必ずやっている［書類・手帳・ノート］の整理術

仕事を円滑にすすめる上での情報の整理術のTIPSたちが詰まっている本。一見、デスクワークしてる人向けっぽいような表紙ですが、仕事をしている人なら誰でも使える技を紹介してくれています。

タスク管理入門本としておすすめです。

スマホ時代のタスク管理「超」入門

肌身離さずはいられないスマホの活用を前提としてフレームワークがしっかりと書かれています。リマインダーやカレンダーなどのツールを使い始めた頃に読むと目からうろこが落ちる本。具体性があるので、すぐ使えるノウハウが詰まっています。

ひとつ上のGTD ストレスフリーの整理術実践編――仕事というゲームと人生というビジネスに勝利する方法

kindle本ではないですが、更にタスク管理を徹底したいと思った時、部長クラスの上司におすすめされて読んだら役立った本なので紹介します。GTD(Getting Things Done)と呼ばれるフレームワークに準拠して書かれていて、小さいTipsではなく、1週間から1ヶ月単位の長期的な習慣づくりをしたい人におすすめ。タスク管理という概念や人が怠惰になる原因など、本質的な内容が載っています。

チームのタスク管理

SCRUM BOOT CAMP THE BOOK

スクラムの入門本でちょうどセール中。２，３時間で読めるにしては内容が濃いです。ケースバイケースな問題に直面した時にどう切り抜けていくか？というストーリーが含まれていて、文章で淡々と解説されるよりも説得力を感じました。

スクラム初心者から中級者にかけて、まずは読みたい1冊です。

カンバン:　ソフトウェア開発の変革

最近最高純利を更新したトヨタのカンバン方式をソフトウェア開発に還元した本。どうしてもスクラムではカバーしきれない柔軟性や組織的な仕組みづくりの補強として読みました。

ボトルネックの見える化→解消するための基本的な考え方から、実践例が載っていてます。

エッセンシャルスクラム

辞書的存在なエッセンシャルスクラム。スクラムをやっていると言語化しにくいが違和感を感じるポイントやジレンマがでてきます。それらの根本はどこにあるって、なぜ違和感やジレンマを感じるのかという概念的な解説が書かれています。フレームワークでカバーできないところを判断する一つの視点として役立つ本でした

部下のコーチング・行動科学

３分間コーチ　ひとりでも部下のいる人のための世界一シンプルなマネジメント術

マネジメントは、心理学的側面からアプローチするとすんなりと物事な進むことがあると感じた1冊。どうしてもフレームワークや仕組みでもカバーしきれないところが出てきますが、それを話し方・対応の雰囲気などで改善していくためのノウハウが書かれた本。一人でも部下がいるならおすすめです。

短期間で組織が変わる　行動科学マネジメント

4章、5章がおすすめ。人のやる気に関わるところを論理的に解説されていて、自分にも当てはまるところがちらほら。コーチングでより結果を出すためには？というところがフレームワークと合わせて紹介されている本です。

まとめ

結局自分のメモ代わり的に書いてしまい、ライトに読める本ばかりではなくなってしまいましたがぜひ読んでみてください。

2015-11-13

Webセキュリティの読み物

読書メモ

徳丸浩のWebセキュリティ教室

徳丸本がkindleで、出てたのでメモ。単行本は10月にでてます。

ポイント

３章構成(概要→攻撃手法→事例)となっており、読み物として要所とトレンドを抑えた内容となっている
特に３章では具体例を14も列挙されています。列挙されている例で言うと、「脆弱性の責任訴訟問題」、「パスワードの定期更新の有効性の検証」など

また、(徳丸さんのブログ)http://blog.tokumaru.org/2015/10/web1022.htmlでは

本書は書きおろしではなく、日経コンピュータ誌に連載したエッセイを、ほぼそのまま並べ直した形となっています。前著「安全なWebアプリケーションの作り方」のようながっつりした技術書ではなく、もう少し気楽な読み物として、技術者以外の方々にも読んでいただける内容になっている…と思います。

と、紹介されています。

セキュリティをガッツリ学びたいなら...?

徳丸さんといえば体系的に学ぶ安全なWebアプリケーションの作り方が有名。

この本は

脆弱性とは何か
なにが脆弱性になりやすいか
どのように対処すべきか
どのようにテストすべきか

と、セキュリティに関する勘所が実践形式かつ段階的に紹介されていて、１回流せばいやでも勘所がつきます。対策のノウハウをつけることもさながら、観点を持っておくだけで実装の視野が広がる一冊となっているのでおすすめです。

体系的に学ぶ安全なWebアプリケーションの作り方

2015-11-12

IFTTT経由の柔軟な定期リマインダーをつくる

軽いライフハック

作ったのは翌日がなんのゴミの日か？を前日の23時頃に通知するシステム。

ここ２ヶ月位前にIFTTTを知ってポピュラーなレシピだけじゃ限界あるし自分の生活にとって最適なレシピを作りたいと思ってやってみた。 JSもExcelも初心者だけど、それほど手間をかけたわけでもないのに自分が求めてるものを作れるなと実感したのでメモ。

構成

Spreadsheet, Google App Script, IFTTT, slack

f:id:matsuokah:20151027000656p:plain

手順としては以下の通り

Spreadsheetにゴミの日情報を記載
Spreadsheetからゴミの日情報をGoogleAppScriptで抽出してメールでIFTTTのトリガーをフック
IFTTTの連携先にブロードキャスト
今回はslackにメールの題名と本文を通知

IFTTTを挟むことによって連携先が柔軟になるので、あとから他のサービスに連携したくなった時もポチポチしていくだけでいい。IFTTT便利。

マスタ管理はSpreadsheet

日付計算、文字の使い回しなどは関数が揃っているSpreadsheetがおすすめ。

自分が会社で所属しているプロジェクトでもゲームのマスタ管理をSpreadsheetで行い、GoogleAppScript(以下、GAS)で整形してJSON化するといったことをしている。マスタ管理をSpreadsheetでする最大のメリットは勝手に編集履歴を作ってくれることとGoogleAppsとの連携が強力であること。Spreadsheetにマスタ情報を定義しておけばあとは取り出すだけ。ライトなデータベース的に使えるので今回の様な場合にも無料でデータベースとして使える。

実際に定義したのは...

マスタ(ゴミの種別、何週目の何曜日が収集日か、メール送信先、メール題名、メール本文)
条件マッチ用の正規表現
日付計算情報(明日は何週目の何曜日か？)

https://docs.google.com/spreadsheets/d/1e-PkwcZmZg8qZj4TB95woJv_GRjd2VwePTNSHL8UOOs/edit?usp=sharing

今後は引っ越してもここの収集日をメンテするだけで通知が飛んでくれる。何週目マッチ && 曜日マッチがメールのカラム。メール送信条件が満たされていればtrueになる。つまり、true行のメールを送るというロジックをGASで組めばいいことになる。

フックするGASはIFTTTと連携させているGmailのアカウントで

IFTTTを連携しているメールの場合のみリアルタイムなメールトリガーが使える。

これがまた便利。

  GmailApp.sendEmail('trigger@recipe.ifttt.com', sub, body);

とメールするだけで題名と本文を連携先に流すことができる。メールの送り主はGmailのアカウントになる。

また、GASの最大のメリットは定期実行が可能なところ!!!cronが不要でとてもよろしい。

f:id:matsuokah:20151027003839p:plain

メイン関数を毎日１回23時から24時の間に実行するという設定の例。

下記がスクリプト.

function getMainSheet() {
  var url = "https://docs.google.com/spreadsheets/d/1e-PkwcZmZg8qZj4TB95woJv_GRjd2VwePTNSHL8UOOs/edit#gid=0";
  var spreadsheet = SpreadsheetApp.openByUrl(url);
  var sheets = spreadsheet.getSheets();
  for ( var i in sheets ){
    if ( sheets[i].getSheetName() != "settings" ) {
      continue;
    }
    
    return sheets[i];
  }
}

function getColumnMap(data) {
  var header = data[0];
  var info = {};
  for (var j = 0; j < header.length; j++) {
    var cell = header[j];
    switch (cell) {
      case 'mail':
        info.mail = j;
        break;
      case 'to':
        info.to = j;
        break;
      case 'sub':
        info.sub = j;
        break;
      case 'body':
        info.body = j;
        break;
      default:
        break;
    }
  }
  return info;
}

function getMailTo(data, columnMap) {
  var toArray = [];
  for (var row = 0; row < data.length; row++) {
    if (row && data[row][columnMap.to]) {
      toArray.push(data[row][columnMap.to]);
    }
  }
  return toArray.join(',');
} 

function getSendMailInfo(data) {
  var columnMap = getColumnMap(data);
  var sendIndex = 0;
  for (var row = 0; row < data.length; row++) {
    var mail = data[row][columnMap.mail];
    if (mail && row != 0) {
      sendIndex = row;
      break;
    }
  }
  
  if (!sendIndex) {
    return sendIndex;
  }
  
  var info = {
    to: getMailTo(data, columnMap),
    sub: data[sendIndex][columnMap.sub],
    body: data[sendIndex][columnMap.body]
  };
  
  return info;
}

function main(){
  var sheet = getMainSheet();
  var data = sheet.getDataRange().getValues();
  
  var info = getSendMailInfo(data);
  if (!info) {
    return;
  }

  GmailApp.sendEmail(info.to, info.sub, info.body);
}

IFTTTを挟む

IFTTTの挟む最大の利点はメールを抽象化してタイトルと本文という概念にできること。

つまりハブとして流せるのがいい。さらにメールに対してはほぼリアルタイムにトリガーが起動するということ。なぜならメールの受信がトリガーだから。なので、連携しているメールアドレスからtrigger@recipe.ifttt.comにメールが送られれば最大15分のタイムラグをなくせる。

(GASの定期実行がpm11~pm12とアバウトなので意味ないけど。)

slackにポストする

ここまで来たら後はIFTTTの設定画面でポチポチするだけ。

明日がゴミの日となればslackに通知が飛ぶ。ここで家族slackを提案したい。

slackは数名程度なら無料で使えるので家族でチャンネルをシェアすることができる。したがって、同居人に同じチャンネルを見れるようにしておけば、「明日は燃えないゴミの日」と二人に伝えることができる。ああ、なんて便利なんだ。

IFTTTはTrelloとも連携できるのでTrelloのカードを作ってもいい。Trelloの更新を検知してslackに通知をすることもできる。家族trelloもよい。(筆者は買い物リストやデートに行くところなどTODOをTrelloで共有している)

まとめ

筆者は引っ越したてで、ゴミの出し方が変わったためこういうものを作れて少し幸福度が上がっている。

今回のようにマスタ・送信ロジック・通知連携・通知サービスとマイクロサービス化っぽくしていれば、マスタの内容を書き換えるだけで他の通知もできるだろうし、土台となりうる。送信ロジックをもう少しインテリジェンスにしてもいい。

ちょっと手をくわえただけで無料で自動化できるDocsのアプリ群、IFTTT、それと連携しているサービス様たちは偉大だ。ほぼ、JSの経験、Excelの経験がない自分でもそれなりに便利なものができた。

2015-10-16

Gitでコミット履歴を整理したい時に覚えておきたいコマンド(編集中)

シーン: featureブランチから更に作業ブランチを作ってた場合

f:id:matsuokah:20151016013044p:plain

上記のようにfeature/Aから枝分かれして並列で開発している時に、BのマージコミットをしたあとにC...C''のリベースをしようとするとなかなか大変だなーと思う時がありました。そこで

feature/AB'''とfeature/AC''B'''を比較してCのコミットハッシュを取得する
feature/ADを作り、1で取得したコミットをcherry-pickしてリベース
feature/AD'をfeature/AB'''にマージする

とすればわりと履歴が編集しやすくなるとと思いました。

1. まず差分のハッシュリストを取得する

$ git --no-pager log --no-merges --pretty=oneline ...`git rev-parse feature/AB'''`

330a340d25477683baf0767e471b8ed28fea41a9 Fixed hoge
f8ca306bb8e94a7ef899c42bc3097ba8d569e18c Fixed fuga
7f8d6461240e2b618982d39371d77dae89a206c9 Fixed barr

2. `feature/AD`に`cherry-pick`

$ git checkout feature/A
$ git checkout -b feature/AD
$ git cherry-pick 330a340d25477683baf0767e471b8ed28fea41a9
$ git cherry-pick f8ca306bb8e94a7ef899c42bc3097ba8d569e18c
$ git cherry-pick 7f8d6461240e2b618982d39371d77dae89a206c9
$ git rebase -i HEAD~3

3. `feature/AB'''`にmerge

$ git checkout feature/A
$ git pull
$git merege feature/AD'

これでなんとかリベースできそう。本当はgit-nowとかtigを使いこなせればいいんだろうけど、まだまだ初心者であります...!

2015-10-07

Anti Adblock機能を使っているサイトでコンテンツを読む方法。Anti Anti Adblock

Anti Adblockとは？

その名の通り、Adblockしているブラウザに対してコンテンツを表示しないという策を講じる機能です。あくまでブラウザです。

ご存知のかたが多数と思いますが、サードパーティ製の広告ブロック機能がiOS9から使える様になりました。そのアプリはストアで１位を取るなど、無視できない機能となっています。

2010年からこの機能自体はあったようなんですが、iPhoneユーザーをターゲットにしてるブロガーが多いらしく、Anti Adblockの導入に火がつきました。

↓ブロックされている例

f:id:matsuokah:20151007235624p:plain

これはどうやってブロックされているかというと、丁寧にリンクが付いているので仕組みを見ることができます。

Antiblock.org - Script-Download

リンク先ではソースが公開されており、自由に使えるようになっています。

コピペでらくらく配置と設定ができる

f:id:matsuokah:20151007230113p:plain ブログなどに導入する広告用のjsが読み込めない場合にAnti Adblock機能を発動させるように出来てるようでASP(広告の配信元)のURLが設定可能になっています。デフォルトでは３つのASPが読み込めない時に発動するようです。

ちゃんと設定している人はそのブログやサイトで使っているASPのリンクをすべて設定していることでしょう。

ただ、こんなにも頭いいAnti Adblockですが実はこれらは簡単に対処することができます。

MacでAnti Anti Adblock

サファリで読む

リーダー機能を使いましょう f:id:matsuokah:20151007231645p:plain

Chromeで読む

リーダー機能のExtensionを入れましょう

chrome.google.com

f:id:matsuokah:20151007233132p:plain

iReaderとかもあったんですが、ダメでした。Readabilityはこの記事を書いてる現時点で本文抽出出来ました。

iPhoneでAnti Anti Adblock

サファリで読む

サファリでリーダー機能を使えばいいだけです。

f:id:matsuokah:20151007233651p:plain f:id:matsuokah:20151007233652p:plain

RSSリーダーで読む

FeedlyでRSSを登録
気になる記事をPocketに
Pocketのリーダーで読む

まとめ

今回は各アプリのリーダー機能を使うというところで手を打ちました。結構頭が良くてありがたい。ただ、イタチごっこなのでリーダーでも見れない日が来るかもしれません。

しかしながら、本文(コンテンツ)自体が広告の場合はどうにもならないので、そこは見極めるしかないようです。ステマに躍らされるのはいつだってそれらしい本文を信じてしまうからですｗ

俺氏について

アバターサービスの技術スタック

フロント

サーバー

リリースフローについて

おおまかなリリースフロー

iOSのレビュー提出日を基準にスケジュールを組み立てる

リリースサイクルを早めるメリット/デメリット

1回のリリースサイクルは約2週間

大きい機能をこのフローにのせるには

リリース

強制アップデートの基準

Androidのアプリのβ公開

リリースオペレーション

PlayStore

AppStore

まとめ

乗り換えた理由

契約

乗り換えてはじめにした設定

ランチャ

アイコンバッジ

デスクトップ

ウィジット

アプリショートカット

プリインストールアプリの無効化

移行したアプリ

おまけ

本の選び方

自分のタスク管理

チームのタスク管理

部下のコーチング・行動科学

まとめ

ポイント

セキュリティをガッツリ学びたいなら...?

軽いライフハック

構成

Spreadsheet, Google App Script, IFTTT, slack

マスタ管理はSpreadsheet

実際に定義したのは...

フックするGASはIFTTTと連携させているGmailのアカウントで

IFTTTを挟む

slackにポストする

まとめ

シーン: featureブランチから更に作業ブランチを作ってた場合

1. まず差分のハッシュリストを取得する

2. feature/ADにcherry-pick

3. feature/AB'''にmerge

Anti Adblockとは？

↓ブロックされている例

コピペでらくらく配置と設定ができる

MacでAnti Anti Adblock

サファリで読む

Chromeで読む

iPhoneでAnti Anti Adblock

サファリで読む

RSSリーダーで読む

まとめ

2. `feature/AD`に`cherry-pick`

3. `feature/AB'''`にmerge