ソフトウェア工学

FP言語では、同じパラメーターを使用して関数を何度も呼び出すと、同じ結果が繰り返し返されます（つまり、参照透過性）。 しかし、このような関数（疑似コード）： function f(a, b) { return a + b + currentDateTime.seconds; } 同じパラメータに対して同じ結果を返すことはありません。 これらのケースはFPでどのように処理されますか？ 参照の透明性はどのように適用されますか？それともそうではなく、プログラマが自分で行動するかどうかに依存しますか？

8 programming-languages  functional-programming  side-effect 

私たちは、プロジェクトに最適なスプリントの長さを見つけようとしていました。3週間ベースで作業した後、スプリントを2週間に削減すると、速度が向上すると考えました。 利点は明らかでした-短いフィードバックループ、小さなストーリー（ユーザー価値あり）など。一方で、セレモニー（企画、回顧）など、私たちが制作しておらず、より頻繁に発生するデメリットもたくさんあります。 新しいチームのために、最適なスプリントの長さをどのように決定できるのかと思っていました。

8 agile  scrum  sprint  feedback 

入力をポートでリッスンするJavaプログラムがあります。入力に基づいて、Webサービスを呼び出し、成功/失敗をクライアントプログラムに返します。 クライアント接続ごとにスレッドをフォークします。プログラムに接続するクライアントへの応答は迅速でなければなりません。 これらは私が検討している選択肢です 通常のスレッドを使用する と使用ExecutorServiceするnewFixedThreadPool と使用ExecutorServiceするnewCachedThreadPool 私がプールを検討している理由は、私のスレッドが短命であるためです-スレッドはWebサービスを呼び出し、クライアントに結果を返し、接続を閉じます。 newFixedThreadPool接続がキューでスレッドを取得するために待機しているため、私は正しいことだとは思いません。 newCachedThreadPoolスレッドが1分後に死ぬということを除いて、完璧でした。私の場合、接続のバーストが発生します。つまり、複数の接続があり、その後数分間停滞する可能性があり、その後再びバーストします。CachedThreadPool内のスレッドは停止し、再度作成する必要があると思います。この場合、場合によっては＃1のように動作する可能性があります。 理想的には、私はnewCachedThreadPool最小限にしたいと思っていました-つまり、スレッド数が決して20を下回らないという設定です。したがって、アイドル状態のスレッドは強制終了されますが、最小しきい値を下回ることは決してありません。 このようなものはありますか？または、より良い代替案はありますか？

8 java  multithreading 

一部のエンティティを値オブジェクトに変換しようとすると、値オブジェクトが集約内で一意でなければならない場合に行き詰まります。 集約のルートを作成するMovieエンティティがあるとします。このMovieエンティティは、特定のタイムスタンプで広告を表示する役割を持ついくつかのAdvertisementEventオブジェクトのセットに関連付けられています。 AdvertisementEventはいくつかへのリンクが含まバナーが表示されている必要があり、座標といくつかの効果フィルタを。 以来AdvertisementEventだけで設定パラメータのコレクションを、私はそのアイデンティティを気にしてばかり大きな値オブジェクトのように扱う必要がある場合、私はわかりません。ただし、映画内では、特定のタイムスタンプで、おそらくタイムスタンプの前後でも、AdvertisementEventが1つだけであることを気にします。 私は疑問を複数の独立した質問に分割するのが難しいので、そこに行きます： ない設定パラメータのコレクションは、値オブジェクトのように聞こえますか？ 映画内のAdvertisementEventの一意性の概念とトランザクション整合性ルールを混在させていますか？ ない任意の時点での選択肢（2）のがあることを意味AdvertisementEventがで作られた集合体のメンバーでなければなりません作品？ 私のあるAdvertisementEventのオブジェクトは、エンティティ、値オブジェクトやイベントオブジェクト？（私の混乱を強調するために、名前にイベントサフィックスを使用しました） このような大きな値のオブジェクトはデザインのにおいですか？ 私はそれだけで何かではないので、私はDDDの意味でのイベントはお取り扱い致しておりませんことを推測起こります。実際のDDDイベントは、AdvertisementEventReachedのようなものでなければなりません。

8 domain-driven-design  entity  value-object 

私はこの記事を読んでいました：Designing Flags Enumerations @ msdnそしてそれは言う フラグ列挙値の組み合わせは中間スキルであり、一般的なシナリオを実装する開発者には必要ありません。 フラグの列挙は素晴らしいと思います-Cでの経験の中で学んだことです。 なぜこの記事は、私が有用な（そして複雑ではない）スキルであると考えるものから離れて開発者に警告しているように見えるのですか？

8 .net  enum 

私が持っているabstract class A抽象メソッドを宣言しているがdoStuff。現在、を継承しAて実装するクラスが多数ありますdoStuff。 クラスのインスタンスはAFactory、ユーザー入力に基づいて実行時に初期化されます。元々、すべてのクラスには同じ単一のパラメーター（ユーザー入力）がありました。しかし今、私はAニーズを継承する新しいクラスだけである追加のパラメーターを持っています。 だから私はそれを次のロジックで分解します： ユーザー入力（AFactoryもちろん使用）に基づいてインスタンスを生成するインタープリタークラスは、この追加のパラメーターを認識していませんでした。 それをクラスインタープリタクラスにプッシュしようとすると、本当に厄介なことになります。それは、いつファクトリーに渡すかを知らなければならず、そもそもファクトリーを持つという全体の目的に反するためです。 それを何かに使うかもしれないと期待して盲目的にファクトリーに送ることも、かなり醜いようです。 私の現在の解決策：一方、にリファクタリングA.doStuff(Param param)することにしましたA.doStuff(AParams params)。 AParams必要なパラメータをすべて保持doStuffでき、興味がない場合は無視できます。これは私にとっても少し厄介なようで、WIN32APIで構造体を送信することを抑制します。この構造体は、醜く役に立たない多くのパラメーターを保持する可能性があり、私はそれが好きではありません。 この問題に取り組むよりエレガントな方法はありますか？それとも私が見落とし、これを解決したいくつかのデザインパターン？ 注： Java 1.7を使用しています クラスの名前は、理論上の設計上の問題を強調するためにばかげていますが、実際には、わかりやすく意味のある名前が付けられています。 私はかなり多くのことを検索しましたが、（このコードをXスローしている理由とは対照的に）特定の抽象的な理論的な問題をWebで検索するのは非常に難しいことがわかったExceptionので、とにかく尋ねることにしたので、これが複製。 編集1： 明確化：サブクラス固有の引数をdoStuffメソッドに渡す必要があります。 編集2： 私はKilian Fothの意図を完全には理解していなかったので、問題をよりよく説明し、解決策を理解するのに役立つJava疑似コードをいくつか書きました。そう： これは私の問題の骨組みです。 これは私のソリューションの骨組みです。 これは キリアンフォスの解決策かもしれないと思いますが、よくわかりません。

8 java  design  design-patterns  abstraction  abstract-class 

受け入れ基準に関するこのブログの投稿で、著者は適切な受け入れ基準は次のようでなければならないことを説明しています。 解決策ではなく意図を述べる（たとえば、「ユーザーはドロップダウンからアカウントを選択できる」ではなく「ユーザーはアカウントを選択できる」） 実装に依存しない（理想的には、この機能/ストーリーがWeb、モバイル、音声起動システムなどに実装されるかどうかにかかわらず、フレージングは​​同じです） 比較的高いレベルである（すべての詳細が書面である必要はない） 次のような詳細： 列見出しは「バランス」です ローリングバランスの形式は99,999,999,999.9 D / CRです。 チェックボックスではなくドロップダウンを使用する必要があります チームの内部ドキュメントまたは自動受け入れテストのいずれかに移動する必要があります ただし、GUIテストを実行するためにCucumberまたは同様のフレームワークを使用することについて眉をひそめる人々をよく耳にします。さらに、内部ドキュメントを使用すると、ドキュメントを定期的に更新できないために多くの問題が発生する可能性があります。 私はまだ、お客様との会話中にそのような詳細をキャプチャする効果的な方法を見つけるのに苦労しています。

8 agile  development-process  scrum  requirements  user-story 

ハードウェア仮想化における「ハイパーバイザー」について読みました。VMは私の領域ではないため、用語の由来がよくわかりません。 Wikipediaの記事の「複数のオペレーティングシステムが別の仮想マシンのコンテキストで同時に実行することができ、ハードウェアの監視プログラム状態も同様に仮想化された、」方法について協議 これは、スーパーバイザープロセスが仮想化されたことを意味します。これは本当ですか？

8 terminology  history  virtual-machine  virtualization 

私は最近この例に出くわしました： 1,000回のうち999回の例外がスローされない場合、例外は1回だけ生成されます。一方、条件文は不必要に999回呼び出されているため、この場合は例外が優先されます。 このインスタンスではC＃ですが、一般的に言ってこれは本当ですか？以前は、try / catchステートメントには、条件の処理に費やされる時間と同じ独自のオーバーヘッドがあると想定していました。 確かに、通常は条件付きの場所にtry / catchブロックを投げるだけでコードを書くのはひどい方法ですが、リソースの観点からこのステートメントは成り立ちますか？

8 design  object-oriented 

私たちの製品は私たちのサービスに新しいプレーヤーを登録し、それをAzure（私たちは.NETを使用しています）でホストすることを選択しました。 これは私が書いている最初のREST WSであるため、それが確実な解決策であるかどうかについてフィードバックを得たいと思いました。 アプリについて知っておくべきいくつかの仮定： ユーザーは、ユーザーのパスワードを要求せずに、匿名でサービスにログインします 水平スケーリングを可能にするには、WSは完全にステートレスである必要があります サードパーティのスヌーピングを防ぐためにHTTPS（SSL）を使用して接続しています 編集： ネイティブiOS / Androidデバイスを対象としています 私たちの主な懸念は、改ざんされていないクライアントのみがリクエストを送信できるようにすることです そして抽象的な認証プロセス： クライアントは単純なハッシュ（UDID：Timestamp）を作成し、タイムスタンプを使用して基本的なアルゴリズムで暗号化します（たとえば、秘密鍵はハッシュの2番目の文字ごとです） クライアントはサーバーにUDID、タイムスタンプ、ハッシュを送信します サーバーはハッシュを再構築し、ユーザーから送信された暗号化されたハッシュを復号化します 2つが等しい場合-実際にクライアントから送信されたことがわかります（悪意のある送信者からではないことを願っています） すべての入力/提案は素晴らしいでしょう-明らかに私がこの問題を処理しているのは初めてなので、私はそれを間違って設計したかもしれません。 ありがとう！ 2回目の更新： OAuthのセキュリティ仕様を読むと、クライアントとサーバーは秘密鍵を知っている必要があり、クライアントはユーザーのモバイルデバイス（ウェブアプリではなく）にローカルに保存されているため、私の質問に対する実際の回答はないようです。 OAuthセキュリティガイド（http://hueniverse.com/oauth/guide/security/）から： OAuthを実装する場合、対称または非対称の共有シークレットの制限を理解することが重要です。クライアントシークレット（またはプライベートキー）は、サーバーがクライアントの身元を確認するために使用されます。WebサーバーなどのWebベースのクライアントの場合、クライアントの秘密（または秘密鍵）の機密を保持することは比較的簡単です。 ただし、クライアントがデスクトップアプリケーション、モバイルアプリケーション、またはブラウザーアプレット（Flash、Java、Silverlight）やスクリプト（JavaScript）などの他のクライアント側ソフトウェアである場合、クライアントの資格情報をアプリケーションの各コピーに含める必要があります。 。これは、クライアントシークレット（またはプライベートキー）がアプリケーションと共に配布される必要があることを意味し、継承によってセキュリティが侵害されます。 これは、そのようなアプリケーション内でのOAuthの使用を妨げませんが、サーバーがそのようなパブリックシークレットで持つことができる信頼の量を制限します。シークレットは信頼できないため、サーバーはそのようなアプリケーションを不明なエンティティとして扱い、アプリケーションに関する統計の収集など、信頼のレベルを必要としないアクティビティに対してのみクライアントIDを使用する必要があります。一部のサーバーは、このようなアプリケーションを禁止したり、さまざまなプロトコルや拡張機能を提供したりすることがあります。ただし、現時点では、この制限に対する既知の解決策はありません。

8 security  web-services  rest  scalability  authentication 

私は同僚に、深いレベルの制御フローがコードの可読性に有害であると主張しました。 関連するスタックオーバーフローの質問/software/52685/if-you-need-more-than-3-levels-of-indentation-youre-screwedからの例： for(int i=0; i<10; ++i){ Object val = repeat(i, someVar); if(val.value > 3){ switch(val.item){ case DOG: if(mProcess){ outputToUser(val); doMoreThings(val, mMoreThingDoer); if(mRepurpose){ addExample(val); } // and so on, and so on... ほとんどの場合と同様に、このトピックに関する意見を見つけるのは簡単です。 しかし、誰かがそれ以上に貢献できるかどうか疑問に思っています。 たとえば、問題に関連する実際の調査が行われたことがありますか？ それとも、「Xのほうが好き」を超えた他の議論をすることはできますか？

8 coding-style 

多くの人が知っているように、最近のモバイル開発は急増しており、私がコーディングしているものに影響を与えていると思います。具体的には、モバイルアプリケーション向けのWebサービスの開発に興味があります。 RPCとRESTの2つのアーキテクチャが考えられます。私はRESTサービスとRPCサービスの両方を開発しましたが、RPCサービスは、特にPHPなどの言語でコーディングする方がはるかに簡単であることがわかりました。それに関する問題はスケーラビリティにあるようです-多くの手順が存在する場合、サーバー側は簡単に混乱する可能性があります。 一方、RESTははるかに構造化されているように見え、サーバー側での保守が比較的容易になりますが、データを複数のリソースに分割する可能性があり、モバイルアプリケーションには（複数の理由で）悪影響を及ぼします。 私が経験したことから、ほとんどの場合RPCは少し良いようです： クライアント側とサーバー側の両方が、使用可能な手順と実行される呼び出しの数を最小限に抑えることを懸念しています。 アーキテクチャのルールに従うことは、そうでなければ可能である最適化で対抗しません。 RESTやRPCについて誰かに説明してもらうことはあまり期待していません。Webはそれでいっぱいです。モバイルアプリの開発経験のある人に、サーバーサイドでこれら2つのアーキテクチャを使用することについての意見を表明してほしい。ヒントも歓迎します（だれがヒントを好きではないですか？）。

8 rest  mobile  server-side  rpc 

私たちが知っているように、SRPはすべてのクラスが単一の責任を持つべきであり、その責任はクラスによって完全にカプセル化されなければならないことを述べています。 しかし、セッターとゲッターは別の責任を果たします -それらは抽象クラスのプロパティ（データ）アクセスを行います。 場合セッターとゲッターは、抽象クラスのプロパティへのアクセスを行う、その後、彼らは別の責任を果たす行います。 だから私がこのようなものを持っているなら、 class Config { private location; public function write(array $data) { .... } public function read($key) { ... } public function exists($key) { ... } public function delete($key) { ... } // Below comes property abstraction // Here I doubt - I CANNOT USE this class …

8 solid  single-responsibility 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 6年前休業。 常にClojureを支持して行われる議論はそれです。 構文はより単純で、複雑なルールなしでコードを表現する方法は1つだけです。 ただし、Scalaには、Clojureと比較して、さまざまなタイプの構文と構成体がロードされています。 しかし、Clojureを学ぼうとしている過去1週間から、組み込みマクロのリストが無限であることに気づきました。同じ括弧構文でそれらを書いたとしても、それぞれがどのように機能するかを学ぶ必要があります。 では、どのような意味でClojureの構文は単純なのでしょうか。LISPerにとってはそうかもしれませんが、Scalaでさまざまな構成を学習するさまざまなバックグラウンドを持つ人々にとっては、より簡単に思えます。 中立的な観点から、どの構文がよりシンプルで読みやすいですか？

8 scala  clojure 

ソートされたデータがあれば、検索ソリューションは明白です。並べ替えられていないデータが与えられた場合、適切なオプションは、並べ替えてから検索するか、単なる線形検索です。 この質問は、データがある程度ソートされているが、再編成できない場合の対処方法です（書き込み操作にはセクターの消去が必要であり、セクターがRAMに収まりません）。 詳細： データレコードは、タイムスタンプとともに順次ログに記録されます。ただし、タイムスタンプクロックは、同期される前にしばらくの間エポックにリセットされるか、夏時間調整などにより単純に調整されます。 検索結果は、指定された時刻に最も近いタイムスタンプを持つログレコードである必要があります。特定のタイムスタンプでレコードのバイナリ検索を実行しているときに、不連続なログデータのパッチに到達し、間違った方向にピボットする可能性があります。 ブルート線形法以外に、ここで利用できるヒューリスティックはありますか？例：ローカルミニマの影響を受けないシンプレックス検索？ 更新： レコードの約95％がソートされた順序であると想定できます。約5％（ログ全体に分散）は、汚いしゃっくりです。タイムスタンプが時間的に逆戻りし、ログの先頭よりも前のスタンプがある場合、しゃっくりの始まりを識別できます。

8 algorithms  search  heuristics