nginxとGoでつくるメルカリのプッシュ通知システム | メルカリエンジニアリング
原稿の締め切りを越えた先にあるもの、それは校正です。「俺達の戦いはこれからだ！」的な展開に胸が熱く・・・いえ、ちょっと胃のあたりがチクチクする@cubicdaiyaです。 今回はメルカリのプッシュ通知システムとその変遷について紹介します。 メルカリとプッシュ通知 メルカリではアプリ内でのさまざまなイベントの発生時に対象ユーザに対してプッシュ通知を行うようになっています。アプリ内で発生するイベントというのは例えば、 商品の購入 購入した商品の発送 商品に対するいいね！、コメント といったものです。通常アプリ内でイベントが発生した際はAPIサーバにHTTPSリクエストを発行し、MySQLデータベースへの参照・更新が行われた後ユーザにレスポンスを返します。そして必要であればプッシュ通知を行います。 メルカリのプッシュ通知システムの課題と変遷 メルカリのプッシュ通知システムはこの1年間で2度刷新さ
Silent Push / Background Fetch 時の fetchCompletionHandler に渡す引数ごとの挙動の違いを調べてみた
Silent Push / Background Fetch 時の fetchCompletionHandler に渡す引数ごとの挙動の違いを調べてみた 2014/09/10追記: 追加調査によって判明した事項を追記しています。 iOS 7から追加されたPush通知によるバックグラウンド処理機能 (Silent Push) および定期的なバックグラウンドフェッチ機能 (Background Fetch) ですが、これらの機能はバックグラウンド処理が完了したタイミングでいずれもfetchCompletionHandlerにUIBackgroundFetchResult型の値を渡すような設計になっています。 ちょっと調べれば、大体どこの解説サイトにも以下のように説明があります。 UIBackgroundFetchResultNewData 新しいコンテンツの取得に成功し、新しいデータが存在した
Parse.comのREST APIを使ったPush通知 - 株式会社CFlatの明後日スタイルのブログ
複数のアプリに対してParse.comを介してPush通知を送りたい場合、Webインターフェースでポチポチやるのは効率が悪く、とても辛い作業になってしまいます。Parse.comのサイトはレスポンスが少し遅いなと感じる程度である上に、1回1回が退屈な作業を何度も繰り返すことになるのでミスも入り込み易いのです。当然ですが、自動化・半自動化をするのが望ましいでしょう。 複数種類のiPhoneアプリを同時開発するときのTips - 株式会社CFlatの明後日スタイルのブログ REST API用のKEY REST APIを使うためには、アプリケーションIDとREST API用のアプリケーションキーが必要です。これらのキーを自動化スクリプトなり、専用のファイルなり、どこかに転載しておきます。 なお、iOS用のアプリケーションキーとREST API用のアプリケーションキーは異なります。 Rubyクライ
Developer:リジェクトされないために App Storeレビューガイドラインの和訳 2015年最新版 | siro:chro
Developer:リジェクトされないために App Storeレビューガイドラインの和訳 2015年最新版 2015 12/23 App Storeでアプリリリース時の審査基準となるレビューガイドライン。 初めての iOS アプリ開発において、英文であることを理由に熟読しないまま理解したつもりで開発を始めてしまい、何度もリジェクトを経験しました。 このときのリジェクトによる苦い経験から、少しでも日本の開発者の役に立てればと思い、App Store Review Guidelines を和訳（一部意訳）しました。 あえて訳さない方が適切と思われる名称やセンテンスについては、原文のままの表現を用いています。（本コンテンツに対してのご意見・不備・間違い等ありましたらこちらからご連絡いただければ幸いです） 開発者のスキル・レベルに関係なく、一読すればきっとリリースまでの道のりが短くなります。ご活
#isucon 2013で優勝しました - すぎゃーんメモ
第三回 ISUCONの本選に、参加しました。予選から引き続き、@kazeburoさん、@tagomorisさんとの「LINE選抜チーム」。 #isucon 2013予選に参加した - すぎゃーんメモ 第三回 #isucon 本選リアルタイムフォトレポート【更新終了】 : ISUCON公式Blog 結果はなんと、優勝！！ おや、優勝2回目だ。→第1回のとき タイムライン 予選のとき同様に、自分の手元にある記録と記憶を辿ってどんな雰囲気だったか書き残してみます。間違っていたらゴメンナサイ。 使用言語はPerlです。 〜10:00 出社…じゃなくて会場入り。ちゃんと前日に早寝したので寝坊せずに済みました。 〜11:00 開会待ち。早くきすぎた、でも他の参加者さんたちも早くからしっかり集まってる。 ルール説明。ストーリー仕立てで緊張感が走る。画像系サービスか〜。 11:00〜 開始。用意されたのは
Redmine, git, Jenkinsの状態を横断的かつリアルタイムに表示する『Dashbozu』をリリースしました。 - みずぴー日記
Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ『Dashbozu』を作りました。 これを使えば、一つの画面でプロジェクトの”今”の状態を把握できます。 WebSocketを用いているので、ただ開いているだけで、次々と情報を得ることができます。 iPadで開きっぱなしにして、机の上に置いておくような使い方を想定しています。 なぜこれを作ったか 一般的なソフトウェア開発現場では Redmineでチケットを作成する gitでコミットを繰り返し、中央レポジトリにpushする JenkinsによるCIが実行される 結果を確認し、Redmineのチケットを閉じる という流れで作業が進んでいきます。 これらの作業の中で、開発者は「適切な」タイミングでチェックとフィードバックをすることを求められます。 例えば、チェックのタイミング
git pullの詳細な挙動を追ってみる - hokaccha memo
git push/pullは何気なく使ってるけど実はよくわかってなかった。ことのきっかけはこういう質問。 hogeというリモートブランチをローカルのhogeブランチにもってきたい hogeをローカルのmasterにはマージしたくない pullでなんかこんな感じでいけそう？ $ git pull origin hoge:hogeでもこれは間違えで、なぜか今いるブランチ（master）にhogeがmergeされるし、期待してる動作じゃない。正解はこう。 $ git branch hoge origin/hogeもしくはチェックアウトも同時にするなら $ git checkout -b hoge origin/hogeこう。自分は普段後者のやり方でやってたけど、なんで上のはダメで下のが正解なのか説明できなかったのでちゃんと調べてみた。 入門Gitと実用Git、あとhelpを参考にした。 ブランチ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
