ソフトウェア工学

システム開発ライフサイクル内で働く専門家、学者、学生向けのQ&A

3
symfonyで外部RESTful APIを利用する方法は?
私たちはプロジェクトのマイクロサービスアーキテクチャを構築しており、主にフロントエンドのSymfonyアプリケーションがバックエンドのRESTful APIと対話しています。 問題は、このアプローチがデータベースを持つDoctrineに大きく依存しているSymfonyエンティティ管理を壊していることです。Symfonyは通常、Doctrineでエンティティを処理し、ほとんどの作業を自動化しますが、APIから外部データにアクセスする必要がある場合、これは簡単に再現できません。 たとえば、クライアントエンティティの場合: Doctrineを使用すると、Clientクラスを定義するだけで、クライアントを簡単に作成、更新、取得できます REST APIアプローチを使用すると、APIを介してクライアントにアクセスできますが、クライアントの作成(POST)、更新(PUT)、取得(GET)などを定義するために多くの作業が必要です。 クライアントは、フロントエンドアプリだけでなく、専用のAPIだけでなく、いくつかのアプリケーションでも使用されています。 API呼び出しの複雑さを隠すエンティティのようなメソッドを使用してクラスを作成し、すべてのAPIデータをローカルにインポートして、Doctrineを通じて、または他の方法でそれらにアクセスする必要がありますか?

1
Swiftにウィットネステーブルが必要なのはなぜですか?
Swiftの実装の詳細を読み込もうとしていますが、特定できないのは、その「ウィットネステーブル」です。構造体に使用される別個のvtableポインターのようです。 しかし、なぜそれが必要なのでしょうか。構造体は値によってコピーされるため、コンパイル時にそれらの型がわかっています。では、どのメソッドを呼び出してそれを実行するかをハードコーディングするだけではないでしょうか?これらのメソッドで仮想ディスパッチを実行する理由

2
カバレッジ-アルゴリズムの欠陥-その使用を取り除く方法は?
前書き メインラインのベクターグラフィックスレンダリングエンジンの多くには、アルゴリズム上の欠陥があります。これらは、各シェイプを個別にレンダリングし、ピクセルカバレッジを計算してアンチエイリアスを作成してから、それらを重ね合わせます。はい、それは簡単ですが、正しい解決策はさらに簡単です。 これは、透明度によってカバレッジを膨らませるので、融合の問題につながります。アルファブレンディングは、状況を正確に表さないルールに従います。たとえば、50%カバーされているピクセルが、50%補完カバーされているピクセルに隣接している場合、100%のカバレッジではなく、75%のカバレッジになります。 。これがどのように見えるかは、アルゴリズムの調整方法やその他の詳細によって異なりますが、本質的にはこれは既知のエラーです。誰かが、さまざまなエンジンエラーを文書化し、それをどのように改善できるかを示す論文を書くという困難を乗り越えました。 画像1:完全に代表的ではないサンプル。上の行に拡大されたエラーを示す三角形でできた形状をレンダリングしたサンプル。SVGソース この問題には、単純な単純な解*があり、カバレッジ計算を行わずにスーパーサンプルを使用して、画像をフィルターで絞り込みます。おまけとして、ボックスフィルタリングよりも優れた画像再構成アルゴリズムを使用できます(「ピクセルは正方形ではありません3」を参照)。現在のソリューションと同等の速度を持つソリューションもあり、これらのソリューションはハードウェアラスタライゼーションパイプラインで実行する方がはるかに簡単です(この問題を回避するために構築されているため、GPUでこのエラーが表示されることはほとんどありません)。 これもコストがかからない問題ではありません。グラフィックデザインに携わっている多くの人が、この問題を手動で回避するために重要な時間を費やして、ここでオーバーラップがあり、オーバーラップがないことを確認して、コンピューターがそれらの問題を修正するようにします。そして多くの場合見事に失敗します。しかし、クライアントはなぜエラーがそこにあるのか気にせず、修正する必要があります。 質問 エラーはどのように伝播しますか?それらはすべて同じエラーを実行しているため、アルゴリズムに同じソースを使用していると結論付けることができます。デザイナーがこのアルゴリズムを選択した原因は何でしょうか?3Dプログラマーだけがこのエラーを認識し、2Dプログラマーが認識しなかったのに、APIと教育でその部分を成文化したのはなぜですか? このエラーがそれ以上伝播しないようにする方法を教えてください。 補遺(これについては質問していません) *どうやら、スーパーサンプリングは問題なく機能するという私の主張は並外れており、並外れた証明が必要です。スーパーサンプリングが機能するための鍵は、スーパーサンプリングがカバレッジ処理を行わないことです。本質的に、スーパーサンプラーは各サンプルをポイントサンプルとして扱います。ポイントサンプルは、基になる領域を想定していないため、アルファ比較が発生しない場所では発生しません。 答えの1つで説明されているように、それが一貫して機能するために。一貫性を保つために、サンプルを整数サンプリングで処理する必要があります。これにより、一度スクリーンスペースに変換された各ポイントが、等しい座標に対してまったく同じソリューションを取得し、サンプルがピクセル境界によって2回シェーディングされないことが保証されます。これを行うには、サンプルが左下のサンプルである場合、サンプルがピクセルをトリガーしない可能性があります(したがって、正確なエッジは> vs <=で処理されるというルールを作成します)。1つを除くすべてのコンソールグラフィックカードは、このように機能します。これにより、余分なデータをキャッシュしたり、近くで追加のテストを行ったりする必要がなくなります。このソリューションは、カバレッジベースのソリューションよりも安定しており、より一般的で一貫しています。 アルゴリズムは元のコードとまったく同じで、コードが少し少なく、サンプルが少し多くなっています。したがって、カバレッジベースのアルゴリズムと同じかそれ以上ではありません。これは、グラフィックスカードだけでなく、他のほぼすべての信号処理分野で古くからこのような方法を使用してきたためです。 この方法には欠点がありますか?まあ、単純な仮定をすると、少し遅くなります。理論的には、カバレッジラスタライザよりも速い漸近的な振る舞いをします。レイトレーサーのように、典型的なシーンではまだ同等です。また、畳み込みベースのエフェクトの使用を実装するのがより困難になる可能性があります。

4
ステップごとに別々のテスト方法を用意するのは良い考えですか?
REST APIをテストしています。JSON構造を返すとしましょう。サーバーをテストするための最良のアプローチは何ですか?各テストステップは、前のすべてが成功した場合にのみ成功します。 構造A:すべてを一度にテストする - Test method 1: - make server request - assert http response code was 200 - assert returned file is not empty - assert returned file has valid JSON syntax - assert returned JSON contains key X これが最善の解決策のようです。 利点: 1つのサーバー要求のみ 「サーバーはキーXのJSONを返しますか?」という動作全体をテストしています。 構造B:各テストにアサートを徐々に追加します - Test method 1: - …

2
誰がウェブ開発でデータベースを設計していますか?[閉まっている]
休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか?この投稿を編集して、事実と引用で回答できるように質問を更新してください。 3年前休業。 Web開発のコンテキストで、誰がデータベースを設計しますか?バックエンドのWeb開発者をサーバー側の処理、データモデリングなどに関連付ける情報のホスト全体にもかかわらず、方程式のデータベース設計の側面は神秘的に存在しないようです。 誰が物理データベースをセットアップするかについては言及していません。データベースの論理モデルを設計し、ユーザーストーリーのインタビューを実施して、必要なフィールド、フィールド仕様などについての情報を入手する人について言及しています。 。 データベースの(PROPER)設計は簡単な作業ではなく(私はこの 672ページャーを読んでいます)、簡単に職業全体になる可能性があることに気付きました。ただし、インターネットを上下に検索しても、Web開発のコンテキストで誰がこのタスクを処理することが予想されるかについては、驚くほど少ない結果しか得られていません。

5
小さなオブジェクトの作成を最小限に抑える必要がありますか?
多数の(1000を超える)小さなオブジェクトを頻繁に作成するものを作成する場合、パフォーマンスのためにそれを最小化する必要がありますか?特に、ローエンドからハイエンドのデスクトップ、さらにはモバイルまで、どのシステムで実行されるかわからない場合。モバイルの場合、多くのオブジェクトを作成するとパフォーマンスが少し低下すると聞きましたが、それがどれほど本当かはわかりません。 この考えをよく示す例があります。グラフィックプログラムでは、理想的にはと呼ばれるすべての描画に使用されるメソッドがあるとしましょうdrawPixel(Point)。1秒間に60回以上呼び出される可能性のあるゲームのように、作成されるポイントは1000になり、頻繁に繰り返される場合があります。または、drawPixel(int x, int y)多くのポイントオブジェクトの作成を最小限に抑えるために使用できます。 オブジェクト指向の設計では、Pointを使用することをお勧めします。ただし、プリミティブ型を使用するとパフォーマンスが向上する場合があります。ほとんどの場合、パフォーマンスの向上はごくわずかですが、モバイルマシンや古いマシンなどについてはよくわかりません。このようなことを行うことによるパフォーマンスの向上は何ですか?それは考慮に入れられるべきものですか?

5
類似した機能に異なるパターンを使用する
私はプロジェクトの唯一の開発者です。これは、他のソフトウェアプロジェクトと同様に、将来誰かに奪われる可能性があります。 機能Aを実装するためにパターンXを使用したとしましょう。機能を開発して完成させた後、今学んだパターンYを使用して同じ機能を実装できることに気付きました。しかし、機能Aはうまく機能しており、XからYへのリファクタリングは時間がかかり、ほとんどメリットがありません。 次に、機能Bを実装します。これはAに似ていますが、今回はこの機会にパターンYで遊んでみたいと思います。機能Aを実行するときよりも、最終結果に満足しています。ただし、コードでは2つ使用していますXとYの異なるパターン。 ただし、機能AIを構築するときに機能Bと同じパターンを使用するのに十分なスキルがなかったという事実を除いて、異なるパターンを使用する実際の理由はありません。 この質問は、特定の問題に適切なパターンを選択することに関するものではないことに注意してください。同様の問題を解決するためにコードベースに共存する約2つのパターンは、リファクタリングするのに十分な時間を与えると1つに減らすことができます。 そのコードは臭いですか? このようにソースコードを保持することの欠点は何ですか? 1つのパターンのみを使用する必要がありますか?つまり、Bを記述するときに、AをリファクタリングしてYを使用するか、Xを使用し続けるか。 ソースで、類似した機能に2つの異なるパターンがある理由は本質的に理由がないことをどのように伝えることができますか? 次の開発者が私のコードをどう思うかについてあまり心配していませんか?

1
数百万のレコードでの部分的な名前の一致
私たちは、名前を照合するためのWebベースのアプリケーションを開発しました。名前をパーツに分割することで動作し、各パーツのSoundex値はデータベースに格納されます。レーベンシュタイン距離メトリックは、与えられた名前に対するパーセンテージ音のマッチングだけでなく、スペルを適用するために使用されます。 実行時に、すべてのレコードをメモリに読み込み、すべてのSoundex値とすべての名前のすべての部分のスペルにレーベンシュタイン距離を適用します。 最大で2万の名前があったため、これは最初は問題なく機能していましたが、現在、当社のクライアントの1つに3,000万の名前があります。リクエストごとにこの巨大なリストをメモリにロードし、このタイプのマッチングを適用することは、大量のメモリと実行時間を使用する悲惨なアプローチです。 サウンドとスペリングのパーセンテージマッチングを使用して、近い将来に3000万件以上のレコードのデータベースを検索するための提案を探しています。 コア機能 エンドユーザーは、照合する名前と最小パーセンテージを入力します。名前の任意の部分が指定された名前の指定されたパーセンテージまでの任意の部分と一致するすべての名前をデータベースに表示することになっています。完全な名前を一致させる必要はありません。割合までの一致が成功した場合は、どの部分でも成功します。例えば。 Given Name: Helen Hunt Name in DB: Holly Hunter 両方の名前の両方の部分は正確には一致していませんが、ある程度までは一致します。80%と想定します。したがって、ユーザーが80%と入力した場合、DB内の名前は一致する名前として表示される必要があります。

3
フックが適切なデザインの選択になるのはいつですか?
私はActiveRecordコールバックの使用が横行し、悲惨な大規模なRailsアプリに取り組んできました。多くの場合、レコードを保存すると予期しない副作用が発生し、システムについて推論することが困難でした。 同時に、継承の一部として有効に使用されるフック(たとえば、サブクラスが親の内部について知る必要なく特別な動作を追加できるようにするテンプレートメソッドを使用する親クラス)とプラグインを使用するフックを見てきました(例えば、emacsモードがアクティブになるとフックを実行し、ユーザーがそのモードの周りにカスタム動作を追加できるようにします)。 RailsアプリとLispインタープリターは非常に異なるシステムであることは理解していますが、直面している問題に対してフックが適切な設計の選択肢であるかどうかを決定するときに、よく知られている基準があるかどうか知りたいです。 私に飛びつくテーマは予測可能性です。フックの誤用は、遠くで不気味な行動や意外な振る舞いにつながるようですが、適切に使用すると、緊密な結合がなくても予測可能なフレームワークにつながる可能性があります。 私はまだプログラミングのキャリアを始めて数年しか経っていないので、私は多くの点で自分自身を初心者だと考えており、人々はこのトピックにかなりの量の考えを入れていると思われます。この決定を導くことができるいくつかのガイドラインは何ですか?
10 hooks 

2
MonoプロジェクトはどのようにしてMITの下でLGPLされたライブラリを再ライセンスできましたか?
Monoプロジェクトは、かつてLGPL化されたライブラリーを持っていました。実際mbundle、それを実行するとまだ言います LGPL Monoランタイムを静的にリンクすることには、動的にリンクすることよりも多くのライセンス制限があることに注意してください。参照http://www.mono-project.com/Licensingのライセンスの詳細については。 2016年3月の時点で、彼らはMITの下でそれらを再ライセンスしました。プロジェクトが何年も前のものであり、おそらく多くの外部の貢献者からの貢献があり、それらの貢献はLGPLによる貢献としてのみ提供された場合、どのようにしてライセンスを変更できましたか?彼らは過去12年間、すべての寄稿者から許可を得なければならなかったのではないでしょうか。たぶんそれらの寄稿者は何らかの合意に署名しなければならなかったのでしょうか?

3
クラスコンストラクターにデータ(対動作)を挿入するとはどういう意味ですか、なぜそれが悪い習慣と見なされているのですか?
私はレモヤンセンの「Learning TypeScript」という本を読んでいます。1つのセクションで、作成者は、Modelクラスの作成方法を含む非常に単純な概念実証MVCフレームワークの作成方法を説明し、次のように述べています。 モデルには、使用するWebサービスのURLを指定する必要があります。ModelSettingsという名前のクラスデコレータを使用して、使用するサービスのURLを設定します。コンストラクターを介してサービスURLを注入することもできますが、クラスコンストラクターを介して(動作ではなく)データを注入することは悪い習慣と見なされています。 私はその最後の文を理解していません。特に、「データを挿入する」とはどういう意味かわかりません。過度に単純化された例を使用したJavaScriptクラスのほとんどすべての導入では、データがパラメーターを介してコンストラクターに導入(「注入」)されているようです。例えば: class Person { constructor(name) { this.name = name; } } 私は確かにname行動ではなくデータと考えています。この種の例には、コンストラクタパラメータとして普遍的に含まれており、これが悪い習慣であるという言及は決してありません。したがって、上記の引用にある「データ」または「注入」などの意味を誤解していると思います。 JavaScript / TypeScriptでデコレーターをいつ、どこで、どのように使用するかについての説明を含めることができます。私は、コンセプトが私が求める理解に密接に関連していると強く信じています。ただし、さらに重要なこととして、クラスコンストラクターを介してデータを挿入することの意味と、それがなぜ悪いのかをより一般的に理解したいと思います。 上記の引用をより詳しく説明すると、これは状況です。Modelこの例では、NASDAQ用とNYSE用の証券取引モデルを作成するために使用されるクラスが作成されます。各モデルには、生データを提供するWebサービスまたは静的データファイルのパスが必要です。この本は、コンストラクター・パラメーターではなく、デコレーターをこの情報に使用する必要があると述べており、次のようになります。 @ModelSettings("./data/nasdaq.json") class NasdaqModel extends Model implements IModel { constructor(metiator : IMediator) { super(metiator); } ... } 単にコンストラクタのパラメータとしてではなく、デコレータを介してサービスURLを追加する必要がある理由を理解していません。たとえば、 constructor(metiator : IMediator, serviceUrl : string) {...

2
暗黙的に別のクラスに変換することのみを目的とするクラスを作成するのは悪いことですか?
Circleオブジェクトを作成できるライブラリを使用していて、円の半径と中心を指定してオブジェクトを定義できる状況を想像してみてください。ただし、何らかの理由で、必要なflavourパラメーターも受け取ります。ここCircleで、自分のアプリで本当に使用する必要があるとしましょう。ただし、アプリの目的で、フレーバーをFlavours.Cardboard毎回に設定できます。 この「解決」をするために、私は自分の作成Circleのみとり異なる名前空間でクラスをradiusし、centerパラメータとしてではなく、外部ライブラリのへの暗黙のコンバータがあるCircleだけで作成したクラスCircle(this.radius, this.center, Flavours.Cardboard)のオブジェクトを。したがって、他のタイプのが必要なすべての場所でCircle、自動変換を実行します。 そのようなクラスを作成するとどうなりますか?より良い解決策はありますか?私のアプリケーションが、この外部ライブラリの上に構築されたAPIであり、他のプログラマーが使用することを目的としていた場合、何か違いはありますか?

3
会議時間と開発時間の節約の間には関係要素がありますか?
私はプロジェクトに取り組んでおり、定期的(通常は毎週)の非公式の会議を開いて、プロジェクトのステータスとGUIについて話し合っています。 私はそこにいる唯一の開発者です。他の4〜5人はIT以外の経歴を持っています。 この会議にはいつもより長い時間がかかりましたが、ある時点で、私の同僚の1人がプログラムのいくつかのフィールドと、それらがどのように満たされるかについて質問しました。私は答えて、私が気付いたディスカッションで、私のプロセスは完全に間違っていると思いました。 しかし、それについて事前に話し合ってエラーを見つけたので、かなり迅速に変更できます。 このことを考えながら、開発時間を節約することに関して、会議時間の間に要因があるかどうかを自問しました。 たとえば、会議時間を1分にすると、開発時間をX分節約できます。 もしそうなら、これは私たちの会議がどれくらいの頻度でどれくらいの長さであるべきかを定義するのに役立ちます。 (明確にするために:会議の長さを大まかに決定することさえできても、より良い会議をしたくありません。会議時間と開発時間の間に関係がある場合、私は主に興味があります!質問の理由:好奇心! )

3
「make」の増分ビルドでハッシュアルゴリズムが使用されないのはなぜですか?
私はの初心者でmakeあり、いつ使用するか迷っていますmake clean。 ある同僚は、増分ビルドmakeはファイルのタイムスタンプに基づいていると私に言った。そのため、VCSで古いバージョンのファイルをチェックアウトすると、「古い」タイムスタンプが付けられ、「このファイルを再コンパイルする必要がない」とマークされます。その後、そのファイルは次のビルドに含まれません。 同じ同僚によると、それを使用する理由になりますmake clean。 とにかく、私make cleanは他のStackExchangeの質問から「いつ使用するか」という質問への答えを大まかに得ましたが、私のもう1つの質問は次のとおりです。 makeたとえば、SHA-1ではなくファイルのタイムスタンプに依存してインクリメンタルビルドを行うのはなぜですか?たとえば、Gitは、SHA-1を使用してファイルが変更されたかどうかを正常に判断できることを示しています。 速度の問題ですか?
10 builds  make 

2
ビジネスロジックをサービスレイヤーに移動せずに、ドメインオブジェクト属性の一意の制約を確認するための洗練された方法はありますか?
私はドメイン駆動設計を約8年間適応してきましたが、これらすべての年が経過した後でも、まだ1つ問題があります。それは、ドメインオブジェクトに対してデータストレージ内の一意のレコードをチェックしています。 2013年9月、Martin Fowlerは、可能であればすべてのドメインオブジェクトに適用する必要があるTellDon'tAsk原則について言及し、操作がどのように行われたかをメッセージで返します(オブジェクト指向の設計では、これはほとんど例外によって行われます)。操作は失敗しました)。 私のプロジェクトは通常多くの部分に分かれており、そのうちの2つはドメイン(ビジネスルールのみを含み、ドメインは完全に永続性を無視する)とサービスです。データをCRUDするために使用されるリポジトリレイヤーを認識するサービス。 オブジェクトに属している属性の一意性はドメイン/ビジネスルールであるため、ドメインモジュールにとっては長くなければならないため、ルールは本来あるべき場所にあります。 レコードの一意性を確認できるようにするには、現在のデータセット(通常はデータベース)にクエリを実行して、別のレコードNameが存在するかどうかを確認する必要があります。 ドメインレイヤーは永続性を無視しており、データを取得する方法がわからないだけでなく、データを操作する方法しか考慮していないため、リポジトリ自体に直接触れることはできません。 私が適応させたデザインは次のようになります。 class ProductRepository { // throws Repository.RecordNotFoundException public Product GetBySKU(string sku); } class ProductCrudService { private ProductRepository pr; public ProductCrudService(ProductRepository repository) { pr = repository; } public void SaveProduct(Domain.Product product) { try { pr.GetBySKU(product.SKU); throw Service.ProductWithSKUAlreadyExistsException("msg"); } catch (Repository.RecordNotFoundException e) { // suppress/log …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.