タグ付けされた質問 「configuration」

アプリケーションの構成には常にJSONファイルを使用しています。私は多くのJavaをコーディングしたときからそれらを使い始めましたが、現在は主にサーバーサイドとデータサイエンスのPython開発に取り組んでおり、JSONがこれ以上正しい方法であるかどうかはわかりません。 Celeryが実際のPythonファイルを構成に使用するのを見てきました。当初、私はそれについて懐疑的でした。しかし、構成に単純なPythonデータ構造を使用するという考えは、私に成長し始めています。いくつかの長所： データ構造は、通常コーディングしているものと同じです。そのため、心のフレームを変更する必要はありません。 私のIDE（PyCharm）は、構成とコードの関係を理解し​​ています。Ctrl+ Bを使用すると、構成とコードを簡単に切り替えることができます。 IMOの不要な厳密なJSONを使用する必要はありません。二重引用符、末尾のコンマ、コメントはありません。 作業中のアプリケーションでテスト構成を作成し、変換やJSON解析を行わずに簡単に構成ファイルに移植できます。 本当に必要な場合は、構成ファイルで非常に簡単なスクリプトを実行することができます。（これは非常に制限されるべきですが。） だから、私の質問は次のとおりです。切り替えた場合、どのように自分の足を撃ちますか？ 熟練していないエンドユーザーが構成ファイルを使用することはありません。構成ファイルへの変更はすべてGitに現在コミットされており、継続的な展開の一部としてサーバーにロールアウトされています。緊急事態があるか、開発中でない限り、手動で構成を変更することはありません。 （私はYAMLを検討しましたが、それについて何かが私をいらいらさせます。それで、今のところ、それはアメリカのテーブルから外れています。）

72 python  json  configuration  configuration-management  python-3.x 

ユーザーが設定できるアプリケーションを書いたとしましょう。この「構成データ」をデータベースに保存するには、2つのパターンが一般的に使用されます。 単一行のテーブル CompanyName | StartFullScreen | RefreshSeconds | ... ---------------+-------------------+------------------+-------- ACME Inc. | true | 20 | ... 名前と値のペアのテーブル ConfigOption | Value -----------------+------------- CompanyName | ACME Inc. StartFullScreen | true (or 1, or Y, ...) RefreshSeconds | 20 ... | ... 両方のオプションを実際に見てきましたが、どちらにも明らかな利点と欠点があります。 単一行の表は、使用できる構成オプションの数を制限します（通常、行の列の数は制限されているため）。追加の構成オプションごとに、DBスキーマの変更が必要です。 名前と値のペアの表では、すべてが「文字列で入力」されています（ブール値/日付/その他のパラメーターをエンコード/デコードする必要があります）。 （もっとたくさん） どのオプションが望ましいかについて、開発コミュニティ内でコンセンサスがありますか？

64 database-design  data-structures  configuration 

ほとんどのアプリケーションでは、シングルトンまたは静的な「構成」オブジェクトを使用して、ディスクからさまざまな設定を読み取ります。ほぼすべてのクラスがさまざまな目的で使用します。基本的には、名前/値のペアの単なるハッシュテーブルです。それは読み取り専用なので、私はそんなにグローバルな状態を持っているという事実にあまり関心がありません。しかし、ユニットテストを始めた今、問題になり始めています。 1つの問題は、通常、実行するのと同じ構成でテストしたくないということです。これにはいくつかの解決策があります。 configオブジェクトに、テストにのみ使用されるセッターを与えると、異なる設定を渡すことができます。 単一の構成オブジェクトの使用を続けますが、シングルトンから、必要なすべての場所に渡すインスタンスに変更します。その後、アプリケーションで1回、テストで1回、さまざまな設定で構築できます。 しかし、どちらにしても、2番目の問題が残っています。ほとんどすべてのクラスがconfigオブジェクトを使用できます。そのため、テストでは、テストするクラスの構成を設定する必要がありますが、その依存関係もすべて設定する必要があります。これにより、テストコードが見苦しくなります。 この種の設定オブジェクトは悪い考えだという結論に達し始めています。どう思いますか？いくつかの選択肢は何ですか？そして、どこでも設定を使用するアプリケーションのリファクタリングをどのように開始しますか？

43 configuration 

私は最近、Pragmatic Programmerを読んでいます。 詳細は、特に頻繁に変更される場合に、元のコードを台無しにします。ビジネスロジック、法律、またはその日の経営陣の個人的な好みの変化に対応するためにコードを変更する必要があるたびに、新しいバグを導入するというシステムを破壊するリスクがあります。 ハント、アンドリュー; トーマス、デビッド（1999-10-20）。実用的なプログラマー：ジャーニーマンからマスターへ（Kindle Locations 2651-2653）。ピアソン教育（米国）。キンドル版。 私は現在、値のセットからのみ取得できるプロパティを持ついくつかのモデルを持つWebアプリをプログラミングしています（Webアプリのデータは機密ではないため）。 light-> type =球/立方体/円柱 ライトのタイプは上記の3つの値のみにすることができますが、TPPに従って、値を変更して構成ファイルに配置できるように常にコーディングする必要があります。アプリ全体でこれのいくつかの事件があるので、私の質問は次のとおりです。 これらのような値を次の場所に保存する必要があります。 構成ファイル： 'light-types' => array(sphere, cube, cylinder), 'other-type' => value, 'etc' => etc-value データベース内の構成テーブルごとに1行の単一テーブル 各設定項目のテーブルを持つデータベース（例えば表：light_types;カラム：id、name） 他の方法は？ 提供された支援/専門知識に感謝します。

41 design  database  configuration 

Rob Coneryによるこの投稿（スラッグに注意）は、開発環境は仮想マシン内で実行する必要があると述べています。私は彼が言っていることを見て同意する傾向がありますが、それでも少し不安を感じます。仮想化が非常に成熟しているため、VM内で運用システムを実行する場合でも、速度はほとんど問題になりませんが、ここで何か気になる点があります。 開発マシンの仮想化についてどう思いますか？すでにそうしましたか？そうした場合、道路に落とし穴や落とし穴がありますか？

41 productivity  configuration  development-environment  virtualization 

ほとんどの場合、次のように、プロジェクトのルートディレクトリに開発アプリケーションの構成を保存します。 app |-- config.json しかし、この設定はバージョン管理システムに保存され、ユーザー名、パスワード、その他の機密情報が漏洩する可能性があるため、これは最善のアプローチではないようです。 12ファクターアプリガイドでは、構成ファイルをすべて削除し、構成セットアップに環境変数を使用することをお勧めします。 ...環境変数に設定を保存します。Env変数は、コードを変更せずにデプロイ間で簡単に変更できます。構成ファイルとは異なり、誤ってコードリポジトリにチェックインされる可能性はほとんどありません。また、カスタム構成ファイルやJavaシステムプロパティなどの他の構成メカニズムとは異なり、これらは言語およびOSに依存しない標準です。 それは本当にいいように思えますが、ソース変数にチェックインせずに、前述の環境変数をどこに保存しますか？そして、これらの変数をアプリに渡すためにどのツールを使用できますか？多数の設定オプションが存在する可能性があり、アプリを起動するたびに手動で入力するのは好ましくありません。したがって、それらはどこかの種類のファイルに保存する必要があります。したがって、このファイルはソース管理になり、元の場所に戻ります。 構成オプションを処理する一般的に受け入れられている方法はありますか。ソース管理にローカル構成を保存するリスクはありませんか？

38 architecture  configuration  configuration-management 

特定のキーをweb.configに入れるか、Constants.csクラスに入れるか、またはこのようなものに入れるかについて、よく自分と戦います。 たとえば、ケースに関係なくアプリケーション固有のキーを保存する場合、カスタムキーを使用して保存し、Web構成から取得したり、定数クラスの定数を参照して使用したりできます。 いつ設定キーで定数を使用したいですか？ この質問は、私が考えるあらゆる言語に本当に当てはまります。

20 configuration 

多数のサーバーがあるシステムを想像してください。それぞれに多くの設定があります： サーバーに固有のもの 地域固有のいくつか それらすべてに共通するもの このグループのサーバーは読み取り専用であるように、カスタムグループを作成できます 等 私が念頭に置いている現在のプラクティスは、オーバーライド機能を持つ単純なプロパティ構造です。 例の目的でGoogleサーバーを使用してみましょう。それぞれにロードする設定のリストがあります。 たとえば、ロンドンのサーバーには次のものがあります。 rootsettings.properties、europesettings.properties、londonsettings.properties、searchengine.properties、など 各ファイルに一連のプロパティが含まれており、読み込みシーケンスを使用するとプロパティをオーバーライドできます。 たとえば、次のようにrootsettings.properties持っていることがありaccessible=false、デフォルトとして、しかしでオーバーライドされるsearchengine.propertiesとaccessible=true 私がこの構造で抱えている問題は、制御不能になるのが非常に簡単なことです。構造化されていないため、任意のレベルで任意のプロパティを定義でき、多くのアイテムが廃止される可能性があります。 さらに、ネットワークの成長に伴い、非常に多くのサーバーに影響を与えるため、中間レベルの変更は不可能になります。 最後に重要なことですが、個々のインスタンスにはそれぞれ1つの特別なプロパティが必要になる場合があります。つまり、ツリーは最終的に各サーバーの構成になり、最適なソリューションではなくなります。 より良い構成管理アーキテクチャの提案/アイデアがあれば、私は大歓迎です。

15 configuration  configuration-management  properties 

ユーザーが設定する必要のあるいくつかの変数を含むシェルスクリプトを作成しています。おそらく一連の質問をすることで、スクリプトをダウンロードして構成するためのインストーラーがあります。問題のスクリプトは、他の開発者を対象としています。 これは、いくつかの方法で実装できます。 スクリプト自体でプレースホルダーを使用し、sedインストール中にそれらを置き換えるために使用します（/programming/415677/how-to-replace-placeholders-in-a-text-fileのようなもの） 長所：すべての変数定義はスクリプト内に含まれています。スクリプトを手動でダウンロードし、インストーラーよりもエディターを好むユーザー向けに変数を構成するのは簡単です。 短所：インストーラーを使用して変数を設定し直すと、変数を再構成するのは困難です。エラーが発生しやすい、より複雑な正規表現を作成しない限り。 configファイルを使用します。基本的に、割り当てのある別のシェルスクリプトを使用sourceして、それを使用します。（そして、おそらくそれを配置し~/.scriptnameますか？メインスクリプトはにコピーされます/usr/local/bin） 長所：スクリプトの再構成は簡単です。メインスクリプトからそれを行うためのパラメータを追加することもできます（おそらく最初のソリューションでも動作しますが、それ自体からスクリプトを編集することは非常に良い考えのようには聞こえません） 短所：スクリプトは2つのファイルに依存するようになり、ユーザーは構成ファイルを作成するためにインストーラーを実行する必要があります。これは、構成ファイルが存在しない場合に構成ファイルを自動生成することで解決できます。ただし、外部の構成ファイルを見つけることは、スクリプトをダウンロードし、編集し、それを実行したいだけのユーザーにとっては依然として面倒です。 また、インストール後にユーザーが構成を管理する方法に関するいくつかのオプション： $ myscript config server.host example.org $ myscript config server.proxypath / home / johndoe / proxyのようなGit $ myscript config server.httppath / home / johndoe / web Interactive $ myscript config サーバーのホスト名を入力します 。example.orgサーバー上のプロキシへのパスを入力します：/ home / johndoe / proxy サーバー上のhttpディレクトリへのパスを入力します：/ home / johndoe / …

13 configuration  configuration-management  shell  bash 

私が関与したすべてのプロジェクトで、外部コンサルタントからの意見がありました。どのような構成管理を使用しているかについて質問されました。これらのいずれの場合でも、コンサルタントは構成管理を定義できませんでした。それで何ですか？

12 development-process  management  configuration 

私たちは多くのアルゴリズムを実装していますが、それらは通常、多くの共有され、公に知られており、セキュリティ関連のパラメーターを持っています。 現在、すべてのパラメーターと2つの定義済みグローバルオブジェクトを保持するクラスを使用しています。 class PublicParams(object): p = q = 0 def __init__(self, p, q): self.p = p self.q = q # used for tests publicParams_test = PublicParams(15,7) # Some 2048 bit numbers for example publicParams_secure = PublicParams(128378947298374928374,128378947298374928374) その後、アルゴリズムはPublicParamsオブジェクトを引数として受け取り、デフォルトで生産的になりますpublicParams_secure def AlgoOne(n, publicParams = publicParams_secure): # do stuff with publicParams.p # ... AlgoTwo(x, …

11 python  unit-testing  configuration 

そこにあるほとんどすべてのパブリックCMSは、データベース設定などに.php構成ファイルを使用しています。たとえば、WordPressをインストールすると、.php設定ファイルが自動的に作成されます。 なぜ.iniファイルを使用しないのですか？PHPには既にparse_ini_file（）があり、他の言語にも同様の関数があると思います。

10 php  cms  configuration 

プログラムに新しい構成オプションを追加すると、多くの場合、オプションを実行する必要がある場所にオプションを取得するという点で、大量の波及効果が生じる可能性があります。私が認識しているこれに対処する3つの基本的な方法があります。 すべての構成設定を、プリミティブとして明示的に必要とするプログラムの部分に渡します。これは最も明示的な方法であり、物事を最も分離する方法です。欠点は、これが冗長であり、もろいことです。 最も頻繁に使用される構成設定をグローバル/静的にします。これは最も簡単な方法ですが、距離を置いてアクションを導入し、テスト性を妨げ、構成が本当にグローバルであると仮定します（常に1つの構成のみが必要である）。 プログラム全体またはプログラム内の主要な懸念事項のすべての構成オプションを含む構成クラス/構造体を作成し、これを明示的に渡します。これは、（1）より明確ではありませんが、（2）より明確です。1つの関数呼び出しのみの設定を変更する場合は、構成オブジェクトを複製して、この1つの値を変更できます。これは、テストと実際の両方で役立ちます。ただし、必要のない関数に大量の情報を渡す可能性があり、configクラス/構造体の値を変更すると、離れた場所でアクションが発生する可能性があります。 （3）パターンとアンチパターンのどちらを検討しますか？アンチパターンの場合、代わりに何をしますか？

10 design  testing  configuration  object 

プログラムデータを保存する方法はいくつかあります（ゲーム、従業員データベース、プログラム構成などにファイルを保存します）。 プレーンテキスト（考える.iniと.conf） XML データベース（MySQL、SQLite ...） .zip および類似のいくつかのファイルを含む（異なる形式で） バイナリファイル（.docたとえば、シリアル化ツールによって作成されたものなど） 上記のフォーマットのさまざまな使用例は何ですか？それらの長所と短所の対比（速度、柔軟性、ファイルサイズ、使いやすさなどを考えてください）？異なるタスクのためにそれらをどのように決めるのですか？ zip形式について：これは、他のファイルを格納するためだけに使用されます。別の圧縮形式の場合もあります。これにより、イメージファイル、サウンドファイル、テキストファイルなど、いくつかのファイルの構造が可能になります。例として、ファイルを含むメッセージの保存形式があるとします。次のファイルを圧縮ファイル内に含めることができます。 message.txt (containing the message) attachments (folder containing attachments) audio.wav picture.jpg

10 database  xml  data  configuration  storage 

次の2つの例を検討してください。 オブジェクトをコンストラクターに渡す class ExampleA { private $config; public function __construct($config) { $this->config = $config; } } $config = new Config; $exampleA = new ExampleA($config); クラスのインスタンス化 class ExampleB { private $config; public function __construct() { $this->config = new Config; } } $exampleA = new ExampleA(); プロパティとしてのオブジェクトの追加を処理する正しい方法はどれですか？いつどちらを使用すればよいですか？単体テストは私が使用するべきものに影響しますか？

10 object-oriented  unit-testing  configuration