アプリ内にデバッグメニューを作るのはやめよう。外から注入しよう。
アプリ開発をしていると、接続するサーバーを切り替えたり、特別なポップアップが毎回出るようにするために、アプリ内にデバッグメニューを作りたくなると思います。しかし、アプリ内デバッグメニューには下記のようなデメリットもあります。 ・フラグ管理を誤ると、一般ユーザにもデバッグメニューが見えてしまう事故が起きる ・App Storeで配布されているアプリでデバッグメニューが使えない ・アプリごとにデバッグメニューの実装が異なり、他チームのエンジニアがヘルプに入った際の学習コストや、エンジニア以外がドッグフーディングする際にコストがかかる ・そもそもデバッグメニューがないアプリにUIから実装するの大変 こういったデメリットを解決するために、アプリ外部からデバッグ用のデータを注入・抽出できる仕組みを実装しました。この仕組みを用いると、App Storeに配布されているアプリにも安全にデバッグ用データを
データベースにRDBを選択するときの注意事項について考える（追記あり） - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2019年6月20日追記： この度は、本ブログにて技術的に誤った記事を掲載したことをお詫び申し上げます。具体的には以下の通りです。 一方的にRDBがスケールしないという技術的根拠が薄い内容となっていました。 RDBとAmazon DynamoDB（以下、DynamoDB）/NoSQLデータベースを要件に応じて適切に選択するという内容になっていませんでした。また、本来考慮すべきアプリケーションの設計やデータアクセスパターンに言及しておらず、RDBのデメリットの部分にのみ焦点を当てる内容となっていました。 DynamoDBの具体的な活用やD
Mackerel における決済プラットフォーム Stripe の利用について - Hatena Developer Blog
Mackerel チームアプリケーションエンジニアの id:astj です。 先日（といっても2ヶ月経ってしまった……）、 Increments さんと Stripe さんの共催による "Qiita x Stripe Meetup" というイベントがあったのですが、そちらで Mackerel での Stripe の利用に関して発表する機会をいただきました。 zine.qiita.com 当日の発表資料はこちらです。 speakerdeck.com イベントレポート内でも要点を掲載していただいていますが、折角なので発表内容を追補した上で以下に記述しておきます。セルフ書き起こしみたいな趣きです。資料中、あるいは以降の文中でも言及していますが、 SaaS であることというのは継続的に新しい価値をデリバリーしてアップデートし続けることであり、また SaaS を利用するというのはそのデリバリーされる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
メルカリ上場1年、多角化失敗で得た教訓 狭まる包囲網、フリマ回帰鮮明に - 日本経済新聞
