世界有数のAPI利用企業で考える標準仕様範囲外の仕様とユーザー体験の関係性

こんにちは、最近ブルグミュラー15曲目(原曲No.20)が終わった内波です。
「じゃあ小学校3年生くらいだね」と言われて少しだけしょんぼりした瞬間もありましたが楽しくやっています。

このブログではだいぶご無沙汰していましたが、最近、我々の会社の立場がかなり稀有なもので、そこで得られている情報をもっと多くの人に広く共有していくべきだな、と感じるようになったので、久々に筆をとりました。
何がそんなに珍しい立場かというと、他社が提供するAPI、その中でも特に、単純な「機能」としてのAPIではない、ユーザーの認可を受けてその代理人として利用するAPIを、これほど多く扱っている企業はなかなかないんじゃないかな、というものです。

 

はじめに

この記事で取り扱うAPI

API(アプリケーション・プログラミング・インターフェース)という単語は非常に広い意味で利用されるものですが、この記事でフォーカスするものを一言で述べると「第三者向けユーザー認可型」のWeb APIになります。

続きを読む

Kubernetesクラスタ上で動かすSidekiqに対してヘルスチェックを導入した話

こんにちは。
マネーフォワード クラウドのアカウント基盤のプラットフォームをプロダクトオーナー兼バックエンドエンジニアとして開発しているkamillleです。
普段はRailsやk8s manifest、Terraformなどを書いています。

今回はKubernetesクラスタ上で動かしているSidekiq(※)プロセスに対してヘルスチェックを導入して、より安全にデプロイが行えるようになった話をご紹介しようと思います。

(※) Railsのアプリケーションで非同期処理を行うためのライブラリ

 

ヘルスチェックで満たしたい要件

今回ヘルスチェックで満たしたかったゴールは下記の2つです。

  1. デプロイ時に新しいSidekiq用のPodが起動したが内部でプロセスが立ち上がらなかった場合は既存Podのterminateを行わない(いわゆるゼロダウンタイムデプロイを高いレベルで実現したい)
  2. Sidekiqのプロセスは生きているがなんらかの理由でジョブを捌けなくなったら検知して再起動する

 
ゴール実現のためにそれぞれ以下の状態を検知できるようにすることが必要と考えました。

  1. Sidekiqが起動し、Redisのキューを捌けるようになった
  2. Sidekiqのプロセスは生きているが処理が止まってしまっている

 
これをKubernetesのヘルスチェック(Readiness, Liveness, Startup Probe)に当てはめると下記になると考えました。

  • Startup Probe、もしくはReadiness Probe(※)で 1. Sidekiqが起動し、Redisのキューを捌けるようになったを検知する
  • Liveness Probeで 2. Sidekiqのプロセスは生きているが処理が止まってしまっているを検知する

(※)Startup ProbeとReadiness Probe、どちらを使うべきかは後述します。

続きを読む

Reacji Channelerを使って楽をしようとしたら情弱であることを晒してしまった…の巻

TL;DR

  • Reacji Channelerは便利なので積極的に使いましょう
  • ぼくのような凡ミスをするときちんと理解してないことがバレます、容量用法を守ってお使いください。
  • お役立ち機能を公式が用意してくれているのめちゃくちゃ最高ですね!

 

Reacji Channeler便利そう!わいもやりたい!!!

マネーフォワードには毎月 LGTM賞といってエンジニアの「それ、すごくいいね!」を集めてワイワイするイベントがあります。
LGTM賞にノミネートされるのはエンジニアだけの活動に限らず、経理のかたが素晴らしい熱量でまとめてくれた社内ドキュメントやPOのGoodな行いなどを推薦することもあります。

なお、LGTMとは「Looks Good To Me」……ではなく、「Looks Good Technology driven to Me」の略です。
もしかすると近々「Looks God To Me」に改名されるかもしれません(多分ない)

このLGTM賞は自薦他薦を問わず公募しているのですが、少しでも推薦のハードルを下げるため「LGTM賞へ」という絵文字をつけると勝手にLGTM賞に推薦されるという仕組みがあります。
この絵文字リアクションをつけるだけ、というハードルの低さがめちゃくちゃ個人的に体感がよすぎて真似したくなってみました。
きっとこの記事をみているかたも試したくなったことでしょう、うんうんぼくはしってるんだ!

続きを読む

AndroidアプリにおけるUIの状態保存と復元について調べてみた

こんにちは。
2020年新卒でAndroidエンジニアの宮本です。
マネーフォワード クラウド確定申告アプリの開発を担当しています。

マネーフォワードでは、全社のAndroidエンジニアが集い、月一で社内勉強会を開催しています。
(最近はオンラインにて開催)

この勉強会では、毎回Android開発に関するテーマを1つ決めて深堀り、発表・ディスカッションしています。
本記事では、2021年1月の勉強会で私が発表した『AndroidアプリにおけるUIの状態保存と復元』について紹介します。

 

はじめに

Androidアプリにおいて、ユーザーが端末の戻るボタンを押してActivityを閉じたり、「最近の画面」でスワイプしてアプリを終了するなどしてActivityの破棄が行われると、ユーザーが行った操作などによって変化したUIの状態は初期化され、再度ActivityやFragmentを開いた際は変更前のクリーンな状態から開始されます。

▼ 「最近の画面」のスクリーンショット(公式ドキュメント 最近の画面 より引用)

そのため、多くのアプリでは画面表示に必要なデータをAPIから都度取得したり、データベースに保存できるようにしていることが多いでしょう。

一方で、AndroidのシステムによってActivityが破棄されてUIの状態が初期化されることもあります。
そのため、AndroidフレームワークではUIの状態が保持されることを保証するために、必要なデータを保存・復元するための仕組みが用意されています。

今回はどのようなときにシステムによってUIの状態が初期化されるのか、UIの状態を保持・復元するべきケースやその方法について解説します。

続きを読む