問題タブ [robustness]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
selenium - Seleniumスクリプトの堅牢性を高めるにはどうすればよいですか?
約30個のスクリプト化されたテストケース(各テストケースはスクリプトです)を連続して実行していますが、指定された要素を識別できない、要素が存在しないなどの失敗が頻繁に発生します。
要素が表示されるのを待つために、すでに多くの異なるメソッドを追加しました。時々それが明らかにそこにあるとき、私はセレンが要素のIDを見つけるのに苦労していると思いますか?
私はいくつかを含めました
と
と
何かをする前に、要素が存在するかどうかを常にチェックします。これはおそらくパフォーマンスに大きな影響を与えますが、今のところ、スクリプトをエラーなしで完全に堅牢に実行したいだけです。私はこのコードを持っています:
これでもエラーになります!!! そして、それはselenium.stopに到達し、成功を「偽造」するために失敗することはありません。スクリプトの堅牢性を強化するために何ができますか?どんな助けでもいただければ幸いです。
IE8でSelenium2.20.0を使用しています。
android - プロバイダー クラッシュ時の Android コンテンツ プロバイダーの堅牢性
Android プラットフォーム (ICS で確認済み) では、クライアントがクエリの途中である (つまり、開いているカーソルがある) 間にコンテンツ プロバイダーが停止した場合、フレームワークは、開いているカーソルを保持しているクライアント プロセスを強制終了することを決定します。
これは、クエリを実行した後にスリープするダウンロード マネージャー クエリでこれを試したときの logcat 出力です。「スリープ」は問題を再現することでした。プロバイダーが正しい/間違ったタイミングで停止した場合、通常のユース ケースで発生することが想像できます。そして、com.android.media (downloadProvider をホストする) を kill します。
「プロバイダー com.android.providers.downloads.DownloadProvider が死にかけているプロセス android.process.media であるため、com.example (pid 12234) を強制終了します」
ActivityManagerService::removeDyingProviderLocked でこのコードを追跡しました
これはポリシーの決定ですか、それともプロバイダーが終了した後のカーソル アクセスは安全ではありませんか?
クライアント カーソルが、CP によって設定された ashmem の場所の fd を保持しているようです。これが、サーバー (プロバイダー) が停止したときに Binders のような例外をスローするのではなく、クライアントが強制終了される理由ですか?
shell - コンパイルされた実行可能ファイルからのCLIシェルスクリプトコード生成?
質問、議論のトピック
私は、より堅牢性を促進し、パフォーマンスが高く、プラットフォームに依存しないコンパイル言語(OCamlなど)で記述されたコードからコマンドラインシェルスクリプトのソースコードを生成することに非常に興味があります。基本的には、コンパイルされた言語でプログラミングして、必要なOSとの対話を実行し(提案します:より複雑な対話またはプラットフォームに依存しない方法で実行するのが容易ではない対話)、最後にコンパイルしますネイティブのバイナリ実行可能ファイル(できれば)に変換します。これにより、コンパイルされた言語でプログラムした内容をシェルで実行するシェルスクリプトが生成されます。[追加]:「効果」とは、環境変数とシェルオプションを設定し、特定の非標準コマンドを実行することを意味します(標準スクリプト「glue」はコンパイルされた実行可能ファイルによって処理され、生成されたシェルスクリプトから除外されます)。そのような。
私は今のところそのような解決策を見つけていません。OCamlをJavaScriptにコンパイルするなど、今日の他の可能性と比較して、実現するのは比較的簡単*のようです。
- 私が説明していることの(公開されている)実装はすでにありますか?
- 私が説明しているものと(非常に)類似している他の可能性は何ですか、そしてそれらはそれとどのように異なりますか?(言語から言語へのコンパイル(コンパイルからshへ)が思い浮かびますが、それは不必要に実現するのが難しいようです。)
私が意味しないこと
- 代替シェル(Scshなど)。管理するシステムでは、ユーザーや1人の管理者がシェルを選択できるとは限りません。また、他の人(顧客、同僚など)だけでなく、期待できない人のためのシステム管理ソリューションになることを願っています。別のシェルを受け入れます。
- 非対話型シェルスクリプト(ocamlscriptなど)が通常機能するための代替インタープリター。個人的には、この目的でシェルスクリプトを回避することに問題はありません。私がそうするのは、シェルスクリプトは一般に保守が難しく(たとえば、特定の文字や「コマンド」などの変更可能なものの操作に敏感)、一般的な汎用プログラミング言語が提供できるのと同じレベルの機能を作成するのが難しいためです(たとえば、この点でBashとPythonを比較してください)。ただし、ネイティブシェルスクリプトが必要な場合があります。たとえば、起動時にシェルから供給されるシェルプロファイルファイルなどです。
バックグラウンド
実用的なアプリケーション
私が説明することの実用的な有用性を疑う人もいるかもしれません。これの実用的なアプリケーションの1つは、さまざまな条件に基づいてシェルプロファイルを定義することです(たとえば、プロファイルのソースとなるシステムプラットフォーム/ OS、セキュリティポリシーに続くもの、具体的なシェル、ログイン/非ログインタイプシェル、インタラクティブ/非インタラクティブタイプのシェル)。シェルスクリプトとしての(巧妙に作成された)汎用シェルプロファイルに対する利点は、パフォーマンス(人間が作成したスクリプト解釈の代わりに、圧縮/最適化されたソースコードを生成する可能性のあるネイティブマシンコード)、堅牢性(型チェック、例外処理)の向上です。 、機能のコンパイル時検証、結果のバイナリ実行可能ファイルの暗号化署名)、機能(ユーザーランドCLIツールへの依存度が低いかまったくない、
実装の詳細、副次的な問題
- プログラマーは、生成されたシェルスクリプトの一般性の程度を制御できる必要があります。たとえば、バイナリ実行可能ファイルが毎回実行され、適切なシェルプロファイルコードが出力される場合もあれば、1回の実行の状況に合わせて調整された固定シェルスクリプトファイルを生成する場合もあります。後者の場合、リストされている利点、特に堅牢性(例外処理やユーザーランドツールへの依存など)の利点ははるかに制限されています。[追加した]
- 結果として得られるシェルスクリプトが何らかの形のユニバーサルシェルスクリプト(GNU autoconfが生成するような)であるか、特定のシェルに(動的にまたはそうでない)適応されたシェルネイティブスクリプトであるかは、私にとって主要な問題ではありません。
- 簡単*:これは、基本的に基本的なシェルビルトインのライブラリで使用可能な関数を使用することで実現できるように思われます。このような関数は、それ自体と渡された引数を、意味的に適切で構文的に正しいシェルスクリプトステートメント(文字列として)に変換するだけです。
さらに考えていただき、特に具体的な提案をありがとうございます。
xml-rpc - XML-RPC プラグインの堅牢性
クライアント側 JavaScript から XML-RPC サーバーとの通信を他の方法よりもはるかに簡単にする jQuery プラグインを作成しました。rtorrent クライアントと正常に通信する独自のアプリケーションで使用しました。スタンドアロン プラグインとして公開しました: jquery-xmlrpc
ユーザーはプラグインに対して 2 つの問題 ( #1と#2 ) をログに記録し、無効な XML-RPC の解析に失敗したと述べています。問題の無効な XML-RPC は空の<value>
ノードです。ユーザーは、無効な XML-RPC ドキュメントを送信している XML-RPC サーバーを処理しています。<nil>
、空の文字列、および不正な空の<value>
ノードを含む、次の XML-RPC ドキュメントについて考えてみましょう。
最初は、誤って空の<value>
ノードを処理し、それらを<nil/>
/null 要素として扱ってよかったです。これは奇妙な特殊なケースのように見えましたが、扱いやすく、ロバストネス プリンシパルの精神に沿ったものでした。
「受け入れるものはリベラルに、
発信するものは保守的に」
しかしその後、問題が更新され<value>
、次のように、動作の悪いサーバーもノードで生の文字列を送信したことがわかりました。
この時点で、リモート サーバーはまったく正しくありません。これは有効な XML-RPC ではありません。しかし、ロバストネスの原則は、私が何を受け入れるかについて自由であるべきだと述べています。
ロバストネスプリンシパルはどこまで取るべきですか? 生の文字列を受け入れる必要がありますか? 他のユーザーに、動作の悪い XML-RPC サーバーに対してバグを記録するように伝えて、拒否する必要がありますか? 不適切な入力の受け入れが度を越してしまうのはどの時点ですか?
c - 「ファイル データ」と「ファイル サイズ」は一緒にディスクにコミットされますか、それとも別々にディスクにコミットされますか
次の例を検討してください。
fputs() の実行中に電源が失われるとどうなりますか?
その後、サイズがゼロではなく、最初のバイトが「h」ではない「my_file」を見つけることができますか? はいの場合、ゼロであることが保証されていますか、それとも任意の値を含むことができますか?
もちろん、誰も私たちのファイルに触れていないと仮定してください。
編集: また、ターゲット ディスク ドライブ/デバイスが、内部にバッファリングされたすべてのデータを書き込むのに十分な時間電力を維持できるタイプであると仮定します。
POSIXはこれについて何か言いたいことがありますか? Linuxは?Windows はありますか?
編集: STDIO ストリーム API の実装方法の詳細に焦点を当てるつもりはありませんでした。POSIXを仮定すると、これが私が本当に意味することです:
編集: POSIX はサイズをファイルのメタ データと見なすため、質問はおそらく次のように言い換えることができます: 上記のコードの結果として、ファイル データとそのファイルのメタ データを別々の段階でディスクにコミットすることはできますか?
編集: http://www.sqlite.org/atomiccommit.htmlでこれを見つけました:
7.5 安全な追加セマンティクスを持つファイルシステム
SQLite バージョン 3.5.0 で導入された別の最適化では、基になるディスクの「安全な追加」動作を利用します。SQLite は、データがファイル (具体的にはロールバック ジャーナル) に追加されると、最初にファイルのサイズが増加し、次にコンテンツが書き込まれると想定していることを思い出してください。そのため、ファイル サイズが大きくなった後、コンテンツが書き込まれる前に電源が失われた場合、ファイルには無効な「ガベージ」データが含まれたままになります。ただし、VFS の xDeviceCharacteristics メソッドは、ファイルシステムが「安全な追加」セマンティクスを実装していることを示している場合があります。これは、ファイル サイズが大きくなる前にコンテンツが書き込まれることを意味し、停電やシステム クラッシュによってロールバック ジャーナルにゴミが入り込むことはありません。
これは、少なくとも部分的な答えを提供するようです。
database-design - 重要で複雑な計算であっても、計算された属性を常に削除する必要がありますか?
データベース設計の「第 3 正規形」では、機能の依存関係を取り除く必要があります。他のフィールドから計算できる属性 (フィールド) をテーブルから削除して、冗長性を排除しようとします。たとえば、別のエンティティを参照する場合、そのキーのみを保存します。これらの参照されたエンティティから属性のレプリカを保存しません。これは、参照されたエンティティを変更するたびにそれらを更新する必要があることを意味するためです。
もう 1 つの状況は、高さなどの属性です。人の身長を知りたいのですが、アプリケーションでは、メートル、フィート、天文単位など、さまざまな単位で知りたい場合があります。ただし、これらの値のすべてを保存するわけではありません。計算フィールドを削除する必要があるため、そのうちの 1 つ (もちろんメートル) のみを残し、必要なときに変換された値を「その場で」計算します。
また、年齢なども保存せず、生年月日から計算します。この場合、時間とともに年齢が変化するという事実も役割を果たします。これを行わないと、常に更新し続けない限り、データはすぐに不正確になります。
ここで、各ユーザーの星座を表示するソーシャル ネットワークがあるとします。各ユーザーについて、生年月日と時間、およびユーザーが選択した占星術の伝統 (西洋または中国など) から計算されたサインを表示します。誰かの星座を計算することは、かなり専門的で複雑な計算ですが、占星術のライブラリから呼び出して計算するだけです。このデータベースをどのように設計しますか、機能的に依存するこの属性を削除しますか、それともユーザーのサインを 1 回計算しますか、それとも生年月日を更新するたびに計算し、それをデータベースに保存してサインインの計算の可能性を忘れますか?システムの残りの部分、または「3NF」を強制しますか 鉄拳で支配?また、アルゴリズムが計算しているサインとは異なるサインをユーザーが主張する場合、ユーザーのサインを微調整できることの潜在的な利点をどのように見ますか?
ここで、新しいアプリケーションを考えてみましょう。あなたは、新しい徴集兵の可能な職業を選択する陸軍用のシステムを構築しています。システムの一部は、ORNL で開発された巨大なパターン認識マシンであり、データベースから得られる大量のデータに基づいて、徴集兵に許可される職業を教えてくれます。このパターン認識方法は、各人の身長、生年月日、医療記録、学校の成績証明書を調べ、その人が 2 つのアンケートのうちの 1 つに回答した長いリストも調べます。また、上位の将校が記入した評価アンケートも考慮に入れ、行われる分析では、各年のすべての徴集兵を同時に調べて、フィードフォワードなどの一連のパラメーターを考え出します。神経網。このニューラル ネットワークは、パターン認識システム全体よりも単純ですが、それでも温度単位の変換だけでなく、かなり複雑な計算です。それにもかかわらず、あなたはそれを「ブラックボックス」として見ることができ、データベースから記録を引き出すと、各徴集兵の運命を知ることができます.
陸軍のカレンダーの特定の日に分析が行われ、ANN パラメーターが検出されます。次に、ブラック ボックスを実行して、各徴集兵に次の 1 年または 2 年に何をするかを伝えることができます。それはかなり重要なことです。あなたは人々の職業を決定し、キッチンでオーブンを操作する人や、タンクを運転する人を派遣します。全員が陸軍のネットワークにログインして自分の職業をチェックし、個人のウェブページで結果を確認します。
これで小さなブラック ボックスが表示され、データベースから取得した属性に基づいてこの重要な値が出力されます。属性とパラメーターはおそらく決して変更されず、徴集兵の運命の計算はおそらく常に正しく、初日から常に同じ値になります。しかし、「計算された属性を削除する」というルールに従うためだけに、それをデータベースの外に残しますか?
これは、年齢、星座、または温度変換の単なる計算ではありません。パターン認識システムは、まさに属性を計算するためのパスです。しかし、この非常に重要なことを何度も何度も再計算して、それをシステム内に永久に保持したいですか? それとも、すべてを一度計算して、この魔法のブラック ボックスの存在を忘れたほうがよいと思いますか? つまり、このクレイジーなパターン認識コードをすべて1 日1 回実行し、結果を選択してデータベースに記録するだけです。誰かがログインして分析の出力を確認するときは、クエリが単なる退屈なデータ取得手順になるようにし、すべてのパターン認識の「興奮」は別の機会にします。
もう 1 つの明白な状況: あなたは Amazon のようなウェブ ストアを運営しています。DB 内のユーザーのレコードから供給される本を人々に推奨するためのパターン認識メソッドがあります。現在の推奨事項が必要なときは常に実行し続けますか?それとも、パターン認識ボックスをシステムの残りの部分とは別のものとして扱い、その結果を他のプログラムが読み取れるデータベースにフィードするだけですか? たとえば、気まずい瞬間に推奨事項を切り替えていないことを確認するためのコントロールがあればいいと思いませんか?... 計算負荷についてあまり心配する必要はありません。優れたメモリと計算リソースを想定してください。
TL;DR -- 計算された属性を削除する規則は決して破られるべきではないと思いますか?それとも、非常に複雑で繊細なパターン認識方法によって計算された非常に重要な属性の結果をデータベースに格納しても問題ないと思いますか? 実際には「オンデマンド」で計算を実行できないふりをして、これらの結果を記録したままにしておく必要がある状況はありませんか? とにかく更新されませんか?
c++ - C ++例外を無効にして(VS2010)メモリ不足の堅牢性を確保するにはどうすればよいですか?
パフォーマンスが重要なダイナミックリンクライブラリ(DLL)に取り組んでいますが、これも比較的小さいバイナリサイズである必要があります。明示的に例外をスローしないので、例外サポートを完全に無効にしたいと思います。ただし、例外が1つあります(意図しないしゃれ)。メモリが不足すると(OOM)、アプリケーションにエラーコードを報告して、適切に処理できるようにする必要があります。コードベースが大きすぎるため、すべての割り当てを個別にチェックしてエラーを伝播できず、触れてはいけない外部コードが含まれています。そこで、DLLのエクスポートされた関数でOOM例外をキャッチしたいと思います。
簡単なテストでは、Visual C ++2010でC++例外を無効にした場合(つまり、/ EHa、/ EHsc、または/ EHsフラグがない場合)、割り当てが多すぎると、catch(std :: bad_alloc&)ブロックにジャンプすることが示されています。
したがって、希望どおりに機能するようです。ただし、次のレベル1の警告が表示されます:「C4530:C ++例外ハンドラーが使用されていますが、アンワインドセマンティクスが有効になっていません。/EHscを指定してください」。MSDNによると、「スローを実行する関数とスローをキャッチする関数の間のフレームに自動ストレージがあるオブジェクトは破棄されません」。
正確に私はここで何を失うでしょうか?ライブラリを介して作成されたものを削除でき、アプリケーションを最初からやり直すことができる限り、未定義の状態のままにしておくことは問題ありません(必要に応じて)。回復できないメモリリークの大きなリスクはありますか?
DLLは別のメモリプールを使用しますか?もしそうなら、アプリケーションにDLLをアンロードせずにパージできますか?アプリケーションが再初期化を実行するまで、ライブラリにそれ以上の(エクスポートされた)関数呼び出しを簡単に無視させることができます。
アドバイスありがとうございます。
c++ - C++ でランタイム警告をスローする
数週間前に例外の使用を開始しましたが、警告をスローする方法があるかどうか疑問に思っています。キャッチされない場合、この警告によってアプリケーションが強制的に終了されることはありません。どのような状況でそれを使用したいかの例を挙げます。
プロパティを一意の ID に追加するシステムがあります。まだ存在しないIDにプロパティを追加しようとすると、システムはそのIDを内部で作成し、後でプロパティを追加して結果を返す必要があります。もちろん、これは静かに行うことはできません。しかし、アプリケーションは実行し続けることができるので、例外をスローしたくありません。
何かが正しくないことを通知するにはどうすればよいですか? システムは実行されていますか?
python - Python、「.txt」ファイルに整数を書き込む
pickle 関数を使用することは、整数をテキスト ファイルに書き込むための最も高速で堅牢な方法でしょうか?
これまでの構文は次のとおりです。
より堅牢な代替手段がある場合は、お気軽に教えてください。
私のユースケースは、ユーザー入力を書くことです:
- はい、人間がそれを読んで編集する必要があります
- ファイルには10個の数字があります
- Python は後でそれを読み戻す必要があるかもしれません。