いっても、これが一体何の役に立つのだろうと思いませんか。助けられたケースを書いていきたいと思います。上でのテストがエラーになってしまいました。)実行時に10分間何の出力もないためエラーになったようです。追加したテスト単体で実行すると成功、そのテストを含むディレクトリをまるごと実行しても成功、しかしテストスイート全体を実行すると同じエラーで止まる。してみることにしました。反応が返ってこない事がわかりました。コネクションが張られ続けること、などが分かりました。接続したまま、それが閉じられていないことが原因と推測し、各テストコードでテストが終わったら接続を切るようにしたところ問題が解決しました。終わらぬバッチ処理いつもは数時間で終わる日次で実行しているバッチ処理があるのですが、それが数日経っても終わっていないということがありました。コマンドを実行してみました。かけることが可能です。pollしている(イベントを待っている)が、それがタイムアウトしているようでした。ファイルディスクリプタを指定します。接続の結果が返ってきていないということが分かりました。これに関してはプログラム中で、該当するAPIとのhttp通信時に適切なタイムアウトを設定していないことが原因だったため、タイムアウトを設定することで解決しました。まとめなにか問題が起きているが、実際何が起きているのかよく分からない。役に立つ可能性があります。頭の片隅に入れておくといいかも。12:11もっと読むコメントを書く2021-08-02uniqueByから始める低計算量アルゴリズムのすゝめReactNativeこんにちは、アプリ開発担当のエモトです。先日、弊社アプリが大型アップデートされました。我々アプリチーム含め社内メンバーと取り組んで、ダークモードなど新しい機能を追加してリリースすることができました。新しくなったアプリをご利用くださいませ。話は変わり、ある配列に対して、その配列の要素が重複しない配列に気軽に変換にしたい。なり、非常に大きい計算負荷になってしまいます。安易に実装するぐらいなら、サードライブラリを利用するのが良いと思います。ネイティブ実装と比べると計算量はより気になる要因の1つです。ループが2つ重なるパターンがあり、良い計算量の設計ではないと気づきました。計算量は考慮されているが、重複確認は単純比較のみなので、必ずしも代わりになるわけではないとわかりました。これは何かしないといけない。利用するのが簡単ですが、要素の順番が保証されないケースがほとんどです。利用するしかありません。型の場合、比較が困難になります。そのため、特定要素を比較する場合も作成しました。万個の要素を持つ配列を用意して、計測しました。倍以上の計算時間でした。変換するという処理だから?かもしれませんが、詳しくは分かりませんでした。uniqueBy検証結果から以下のようなコードを作成しました。方が早そうだが、実際は遅かった。対象データは先ほどと同様な100万個要素の配列を用意しました。13210回ほど検証したところ、多くの場合で、自作の方が早かったです(うれしい)。まとめuniqueBy(重複なし配列への変換)を含め、安易なアルゴリズムでコーディングすると計算量が高くなる処理があります。これらは自作せずに、サードパーティを利用した方が良いと思っています。それぞれの設計思想や目的があり、自分が使いたいシーンで必ず良い結果や計算量が与えられるとは限らない問題もあります。うまく処理できたことが重なって、自作の採用にメリットがあり挑戦できました。最適なアルゴリズムを考える時間は、とても楽しい開発でした。最後に、オトバンクではエンジニアを募集中です。Kotlinのネイティブコードも書いてます)にご興味があれば、是非どうぞ。採用・求人お待ちしております。10引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。