ソフトウェア工学

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 非同期のノンブロッキングイベント駆動プログラミングが大流行しているようです。これが何を意味するのか、基本的な概念を理解しています。しかし、私が確信していないのは、コードが非同期であることのメリットとなるタイミングと場所、またはブロッキングIOを非ブロッキングにする方法です。ライブラリを使用してこれを行うことができると確信していますが、より深い概念と、それを自分で実装するさまざまな方法にもっと興味があります。 このテーマに関する包括的な/決定的な書籍、または他のリソース（デザインパターンのGoF、CのK＆R、bashなどのtldpなど）はありますか？ （注：イベント駆動プログラミングの学習に関する私の質問と実際に機能的に同じ質問であるかどうかはわかりません）

21 design-patterns  learning  books  architectural-patterns  asynchronous-programming 

私のほとんどのプロジェクトでHibernateを約8年間使用した後、私はその使用を思いとどまらせ、ストアドプロシージャを介してのみDBと対話するアプリケーションを求めている会社に行きました。 数週間これを行った後、私が構築し始めているアプリケーションのリッチドメインモデルを作成することができず、アプリケーションは（恐ろしい）トランザクションスクリプトのように見えます。 私が発見した問題のいくつかは次のとおりです。 ストアドプロシージャは最小量のデータを読み込むだけなので、オブジェクトグラフをナビゲートすることはできません。つまり、フィールドが異なる類似したオブジェクトがある場合があります。たとえば、顧客からすべてのデータを取得するストアドプロシージャと、顧客からアカウント情報といくつかのフィールドを取得するストアドプロシージャがあります。 多くのロジックは最終的にヘルパークラスになるため、コードはより構造化されます（エンティティは古いC構造体として使用されます）。 ストアドプロシージャから結果セットを抽出し、エンティティに配置するフレームワークがないため、より退屈な足場コード。 私の質問は： 誰もが同様の状況にあり、ストアプロシージャアプローチに同意しませんでしたか？あなたは何をした？ ストアドプロシージャを使用する実際の利点はありますか？「誰もドロップテーブルを発行できない」という愚かな点は別として。 ストアドプロシージャを使用してリッチドメインを作成する方法はありますか？オブジェクトグラフをナビゲートできるように、AOPを使用してエンティティにDAO /リポジトリを挿入する可能性があることを知っています。ブードゥー教に非常に近いので、このオプションは好きではありません。 結論 まず、答えてくれてありがとう。私が到着した結論は、ORMは（一部の人が述べたように）リッチドメインモデルの作成を有効にしないが、（多くの場合繰り返し）作業の量を単純化するということです。以下は結論のより詳細な説明ですが、ハードデータに基づいていません。 ほとんどのアプリケーションは、情報を要求して他のシステムに送信します。これを行うには、モデル用語で抽象化（ビジネスイベントなど）を作成し、ドメインモデルがイベントを送受信します。通常、イベントにはモデルからの情報の小さなサブセットが必要ですが、モデル全体ではありません。たとえば、オンラインショップでは、支払いゲートウェイはユーザーに請求するためにユーザー情報と合計を要求しますが、購入履歴、利用可能な製品、およびすべての顧客ベースは必要としません。そのため、イベントには小規模で特定のデータセットがあります。 アプリケーションのデータベースを外部システムとして使用する場合は、ドメインモデルエンティティをデータベースにマッピングできる抽象化を作成する必要があります（NimChimpskyが言及したように、データマッパーを使用）。明らかな違いは、各モデルエンティティのデータベース（レガシースキーマまたはストアドプロシージャ）へのマッピングを手作業で作成する必要があることです。2つは同期していないため、1つのドメインエンティティが部分的にマッピングされる可能性がありますデータベースエンティティ（たとえば、ユーザー名とパスワードのみを含むUserCredentialsクラスが他の列を持つUsersテーブルにマップされる）、または1つのドメインモデルエンティティが複数のデータベースエンティティにマップされる場合があります（たとえば、1対1の場合テーブルに1つのマッピングがありますが、1つのクラスにすべてのデータが必要です）。 エンティティが少数のアプリケーションでは、エンティティを横断する必要がない場合、追加の作業量は少ないかもしれませんが、エンティティを横断する条件付きの必要がある場合は増加します（したがって、ある種の「怠lazな」読み込み」）。アプリケーションが成長してより多くのエンティティを持つようになると、この作業は増加するだけです（そして、非線形に増加すると感じています）。ここでの私の仮定は、ORMを再発明しようとしないことです。 DBを外部システムとして扱うことの利点の1つは、アプリケーションの2つの異なるバージョンを実行し、各アプリケーションのマッピングが異なる状況を回避できることです。これは、本番環境への継続的な配信のシナリオでより興味深いものになります...しかし、これは、ORMでもそれほどではないかもしれません。 開発者は、データベースにアクセスできなくても、悪意のあるコードを挿入するだけで、システムに格納されている情報のほとんどではなくてもほとんどを取得できることに基づいて、セキュリティの側面を無視します。親愛なる主よ、顧客のクレジットカードの詳細を記録する行を削除するのを忘れたとは信じられません！）。 小さな更新（6/6/2012） ストアドプロシージャ（少なくともOracleの場合）では、テーブルの構造を変更するとプロシージャとトリガーが無効になるため、ダウンタイムがゼロの連続配信のようなことはできません。したがって、DBが更新されている間、アプリケーションもダウンします。Oracleは、このためのEdition-Based Redefinitionと呼ばれるソリューションを提供しますが、この機能について私が尋ねた少数のDBAは、実装が不十分であり、運用DBに配置しないと述べました。

21 java  design  orm  stored-procedures  domain-driven-design 

データベースに情報を保持するための複数の構成を見てきました。一般的に、私の世界では3つのタイプのデザインが一般的です。 コントローラーが永続性を管理します モデルは永続性を管理します サードパーティのライブラリが永続性を管理します。通常、モデルに何らかの種類の注釈が​​必要です。 概念的に、MVCアーキテクチャと最も互換性があり、互換性のある構成はどれか（もしあれば）疑問に思っていますか？ （リストにない場合は、回答の一部として簡単な概要/概要を教えてください）

21 mvc 

壊れたウィンドウを参照して、将来のアクティビティのためにリファクタリングを残すのが最適な場合はありますか？ たとえば、既存の内部システムにいくつかの新機能を追加するプロジェクトが、これまでシステムで動作していなかったチームに割り当てられ、動作するための短いタイムラインが与えられた場合、それを正当化することができますか？このシナリオで期限を設定するために、主要なリファクタリングを既存のコードに延期しますか？

21 project-management  refactoring  maintenance 

例外に関する Eric Lippertの記事を読むことは、プロデューサーとしてもコンシューマとしても、例外にどのように取り組むべきかについて、間違いなく目を見張るものでした。ただし、厄介な例外のスローを回避する方法に関するガイドラインを定義するのにまだ苦労しています。 具体的には： a）他の誰かがあなたの前にレコードを変更したか、b）作成しようとしている値が既に存在するため、失敗する可能性のあるSaveメソッドがあるとします。これらの条件は例外ではなく予期されるものであるため、例外をスローする代わりに、メソッドのTryバージョン、TrySaveを作成することにします。TrySaveは、保存が成功したかどうかを示すブール値を返します。しかし、それが失敗した場合、消費者はどのように問題があったのかを知ることができますか？または、結果を示す列挙型、Ok / RecordAlreadyModified / ValueAlreadyExistsなどを返すのが最善でしょうか？integer.TryParseでは、メソッドが失敗する理由は1つしかないため、この問題は存在しません。 前の例は本当に厄介な状況ですか？または、この場合に例外をスローするのが好ましい方法でしょうか？Entityフレームワークを含むほとんどのライブラリとフレームワークでそれがどのように行われるかを知っています。 メソッドのTryバージョンを作成するタイミングと、メソッドが機能するかどうかを事前にテストする方法を提供するタイミングをどのように決定しますか？私は現在これらのガイドラインに従っています： 競合状態の可能性がある場合は、Tryバージョンを作成します。これにより、消費者が外因性の例外をキャッチする必要がなくなります。たとえば、前に説明したSaveメソッド。 条件をテストするメソッドが元のメソッドが行うことをほぼすべて実行する場合は、Tryバージョンを作成します。たとえば、integer.TryParse（）。 それ以外の場合は、条件をテストするメソッドを作成します。

21 exceptions 

だから私は比較的単純なシステムを持っています。モバイルクライアントは、私が（他のモバイルクライアントと共有されている）は、リモートSQLサーバーに同期しているしたいとSQLiteのデータベースのレコードを作成します。そのため、電話のsqliteテーブルに新しいレコードを作成するとき、その変更をRESTful APIを介してリモートサービスにプッシュします。私が抱えている問題は、データの衝突がないようにプライマリキーをどのように注文するかです（つまり、電話のレコードはサーバー上の完全に異なるレコードと同じプライマリキーを持っています）。クライアント上のレコードを参照し、サーバー上の同じレコードを参照するための通常の「ベストプラクティスは何ですか？」

21 sql  web-services 

現在、かなり複雑な会社向けに新しいアプリケーションをコーディングしています。期限に間に合うように、機能はかなり打ち上げられており、起動する準備ができています。 私は今月末までにバージョン1を立ち上げて実行するタスクを与えられました。私は開発のほぼ半分であり、終わりが見えてくるようになりました。 昨日、要件の1つに対する非常に優れた簡単なソリューションを思いつくのに時間を費やし、その結果を非常に誇りに思っています。今朝、バージョン2のドキュメントが送信されました。そこには、昨日書いたコードを破壊するか、大幅に変更する必要があるという要件があります。そのままにしておくと、将来多くの作業が必要になります。現在のソリューションをより堅牢にするためにもう1日かかるため、v2機能をはるかに少ない労力で追加できますが、必要な追加のコーディングには少し遅れが出ます。 v2を実行するかどうかはわかりません。私の場合もあれば、同僚の場合もあれば、インターンの場合もあります。 あなたが私の靴を履いていたら、将来それをより簡単にするために今時間を費やしますか、それともあなたのソリューションを残して、時間が来たときにそれを処理しますか？

21 code-quality  future-proof 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 私の履歴書には、「Cでの7年間の実践的なプログラミング経験がある」と記載されています。 明確にするために、私は独学で学んだCプログラマーであり、いくつかの大学のコースが混在しています。私はいくつかの小さな個人プロジェクトに取り組んできましたが、実際の実世界での経験のないコンピューターサイエンスの卒業生よりも有能だと思いますが、決して専門家に近いわけではありません。 問題はこれです...私は求人サイトで私の履歴書を見る採用担当者から電話やメールを受け取り続け、シニア開発者のポジションや契約などに興味があることを尋ねました。私の履歴書には3年の仕事経験しかありません（これはすべてITのものです）ので、彼らがCでの私の以前の経験について尋ねるとき、私はそれが専門的な仕事ではなく個人的な仕事であることを明確にしなければなりません。 私は開発者としての仕事が本当に欲しいのですが、自分が処理できないものに雇われたくはありませんし、自分の強みを誇示しようとしている間、自分を偽りたくありません。私は意図的に「実践的」という表現を選んだのは、それが専門的ではないことを暗示しているからです。履歴書をより明確にするために、履歴書でCの経験をどのように表現すればよいですか？

21 experience  resume 

私は次の技術環境でプロジェクトを開始しています：.Net 4.0、Entity Framework 4.0、WVM with MVVM Architecture 私はネット上で多くの例を見て、この環境に関する本をいくつか見ました。いくつかの例では、著者はこのアイデアを持っていました： Viemodelには、Modelクラスのインスタンス（Entity Framework Entity、Personなど）があります WPFビューコントロールをModelのプロパティにバインドします 一部の著者はそうしましたが： Viemodelは、モデルのすべてのプロパティを公開します。 モデルに直接ではなく、ViewModelのプロパティにWPFビューコントロールをバインドします。 それでは、viewmodelが独自のモデルを公開するのではなく、モデルからプロパティをバインドできるようにすることをお勧めしますか？またはどちらがより好ましいですか？

21 .net  entity-framework  mvvm 

でアンドリュー・ヘイにより、ブログ記事、以下の公理を仮定しました。 プロジェクトの最後に同じバグを修正するよりも、プロジェクトの最後にバグを修正する方が大幅にコストがかかります。 しかし、特にLess Wrongのブログ投稿を読んだ後、これは確実ではないようで、私がそれをバックアップするのを見たデータは非常に古いです。 これは今日でも公理は正確ですか？

21 project-management  debugging  estimation 

そのコードベースを維持する契約を結ぶ前に、実質的なレガシーコードベースのように見えるものを評価するように頼まれました。 このような状況になったのはこれが初めてではありません。現在の例では、コードは適度に知名度が高く、かなり高負荷のマルチプレイヤーゲームサイト用であり、一度に少なくとも数千人のプレイヤーをオンラインでサポートします。そのようなサイトの多くはそうであるように、これはフロントエンドとバックエンドのテクノロジーが混在しています。 内側から見たサイト構造は混乱しています。「_OLD」と「_DELETE」という接尾辞が付いたフォルダがいたるところにあります。フォルダの多くは、目的を果たさないか、非常にわかりにくい名前を持っているようです。正規のフォルダ内にさえ、いくつもの古い未使用のスクリプトが存在する可能性があります。それだけでなく、それ以外の場合は操作可能なスクリプトであっても、間違いなく多くの無効なコードセクションがあります（はるかに差し迫った懸念）。 これは、現在のメンテナーからサイトの元の開発者/メンテナーへの引き渡しです。これらの種類のシナリオでは当然のことですが、現職者は、契約上および法律上、新たに選出されたメンテナーにそれをプッシュするために必要なもの以外、ハンドオーバーとは何の関係もありません。したがって、既存のサイト構造に関する情報を現職から抽出することは、単に問題外です。 コードベースに入るために頭に浮かぶ唯一のアプローチは、サイトのルートから始めて、リンクされたスクリプトをゆっくりと、しかし確実にナビゲートすることです...そしておそらく何百もの使用があり、そうでないものは何百もあります。特に古いFlashアプリケーションでは、他のスクリプトへのリンクがテキストファイル（.AS / ActionScript）ではなくバイナリ（.FLA）に埋め込まれている可能性があるため、サイトの大部分がFlashにあることを考えると、これはさらに簡単ではありません。 だから、保守性のために全体としてコードベースを評価する方法について誰かがより良い提案を持っているのだろうかと思っています。WebサーバーのOS（アクセスできる）上のファイルへのアクセス頻度のグラフを表示する方法があれば素晴らしいと思います。一度も使用されないファイルがあるため、一度も使用されていないファイルを削除できます。

21 freelancing  tools  websites  source-code  flash 

私は停止する問題の別の説明を読んでいたところ、例として挙げられているすべての問題が無限のシーケンスに関係していると考えるようになりました。しかし、プログラムで無限シーケンスを使用することはありません。時間がかかりすぎます。すべての実世界のアプリケーションには下限と上限があります。実数でさえ真の実数ではありません-32/64ビットなどとして保存された近似値です。 問題は、プログラムが停止した場合に判断できるサブセットがあるかどうかです。ほとんどのプログラムで十分ですか？プログラムの「停止可能性」を判別できる言語構成体のセットを作成できますか。私はこれがどこかで以前に研究されたと確信しているので、どんなポインタでも評価されるでしょう。言語は完全なチューリングではありませんが、チューリングがほぼ完了しているようなものがありますか？ 当然のことながら、このような構成体は再帰と無制限のwhileループを除外する必要がありますが、これらを使用しないプログラムは簡単に作成できます。 例として標準入力からの読み取りは制限されなければなりませんが、それは十分に簡単です-問題のドメインに応じて、入力を10,000,000文字などに制限します。 ティア [更新] コメントと回答を読んだ後、おそらく質問を書き直すべきです。 すべての入力が制限されている特定のプログラムについて、プログラムが停止するかどうかを判断できます。その場合、言語の制約は何であり、入力セットの制限は何ですか。これらの構成体の最大セットは、停止するかしないかを推測できる言語を決定します。これについて行われた研究はありますか？ [更新2] これが答えです、はい、1967年にhttp://www.isp.uni-luebeck.de/kps07/files/papers/kirner.pdfから遡ります 有限状態システムの停止問題は少なくとも理論的に解決できることは、1967年にミンスキーによって既に議論されています[4]：「...有限状態のマシンは、完全に放置されると、最終的に完全に周期的になり繰り返しパターン。この繰り返しパターンの期間は、マシンの内部状態の数を超えることはできません...」 （したがって、有限チューリングマシンに固執する場合は、オラクルを構築できます）

21 algorithms  computer-science 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 暗号化ソフトウェアに関する米国の輸出規制を満たさなければならないソフトウェアを設計および公開するとき、どの側面を考慮する必要がありますか？ ウィキペディアでは、暗号化ソフトウェアに割り当てることができるさまざまなカテゴリがあると述べています。また、輸出先（中国、ロシアなど）も大きな役割を果たしています。しかし、私はこれらの制限と私の仕事への影響を本当に理解していませんでした。 誰も私にそれを説明できますか？ アプリケーションを公開しようとすると（たとえば、AppleのApp StoreやAndroidのマーケットで）、アプリケーションが米国の輸出規制を満たしていることを確認する必要があるからです。また、パスワードなどの安全な情報ストレージを提供する多くのアプリケーションがあります。 彼ら全員が政府に通知し、レビューを求めましたか？もちろん、彼らがそうしたかどうかはわかりません。しかし、彼らはこれを行う必要がありますか？

21 security  encryption  cryptography 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 プログラマはなぜオープンソースのアイデアを好むのでしょうか？私はそれらのプロジェクトの作成者について話しているのではなく、もちろん名声を得ていますが、業界全般について話しているのですが、なぜ業界に多くの悪影響をもたらすのにオープンソースのコンセプトが好きなのでしょうか？ まず、wordpressや他のCMSのようなプロジェクトは、クライアントがブログやシンプルなウェブサイトを望む多くのフリーランスの仕事を奪います。第二に、Railsや他のライブラリやAPIなどのプロジェクトは、多くのプログラマーを仕事から解放し、プログラマーの需要を減らします。これらのオープンソースAPIにより、1人のプログラマーが10人のプログラマーがかつて行ったことを行えるようになりました。最後に、Notepad ++などのオープンソースソフトウェアでは、ソフトウェアを購入するように頼むと、人々はおかしくなります。 だから、問題は、なぜ私たちを貧しくするのであれば、なぜオープンソースがまだ好きなのでしょうか？おそらく、プログラマーとしての私の人生はより困難になるでしょうが、少なくとも私はそれで生計を立てることができます。しかし、今では、人間に取って代わる機械に似ています。面白いのは、私たちが自分自身に取って代わる「機械」を作成しているということです。 たとえば、ツールを発明した場合、それを共有する必要はありません。それはあなたとあなたの会社を助けます。これらのオープンソースツールがなくても、他のプログラマーはまだお金を稼ぐ仕事をしているので生きています。

21 open-source 

私は現在のシステム以来、本格的なORMよりも職場での実装が簡単である可能性があるため、Dapperや（.NET 4.0に依存しているためそれほどではありませんが）いわゆるいわゆる「マイクロORM」を検討しています。ストアドプロシージャに大きく依存しているため、NHibernateやEFなどのORMを使用するには、大幅なリファクタリングが必要になります。フル機能のORMよりもこれらの1つを使用する利点は何ですか？データベース接続を取り巻く薄いレイヤーのように見えますが、それでも未加工のSQLを記述する必要があります-多分間違っているでしょうが、そもそもORMの理由は、SQLを記述する必要がないということです。自動的に生成できます。特に、複数テーブルの結合およびテーブル間のマッピング関係は、純粋なSQLでは困難ですがORMでは簡単です。 たとえば、Dapperの例を見てみましょう。 var connection = new SqlConnection(); // setup here... var person = connection.Query<Person>("select * from people where PersonId = @personId", new { PersonId = 42 }); コマンドを記述したり、パラメータを設定したり、Builderを使用してエンティティをマップし直したりする必要がないことを除いて、ハンドロールADO.NETデータレイヤーの使用とはどのように違いますか。ストアドプロシージャコールをSQL文字列として使用することもできるようです。 Micro ORMを使用する意味がある場合、ここで見逃している他の具体的な利点はありますか？おそらく数行のコードを除いて、ADO.NETを使用する「古い」方法で何かを保存する方法を実際には見ていません-実行する必要があるSQLを把握するために書く必要があります。テーブル（IMHO ORMが最も役立つ部分）間の関係をマッピングする必要があります。

21 .net  orm