ソフトウェア工学

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

6
どの機能機能がもたらすメリットについて、OOPを少し混乱させる価値がありますか?
HaskellとF#で関数型プログラミングを学んだ後、OOPパラダイムはクラス、インターフェース、オブジェクトで後戻りしているように見えます。同僚が理解できるFPのどの側面を仕事に持ち込めますか?使用できるようにチームを再訓練することについて、上司と話す価値のあるFPスタイルはありますか? FPの可能な側面: 不変性 部分適用とカレー ファーストクラス関数(関数ポインター/機能オブジェクト/戦略パターン) 遅延評価(およびモナド) 純粋な機能(副作用なし) 式(対ステートメント-コードの各行は、副作用の代わりに、または副作用を引き起こすことに加えて、値を生成します) 再帰 パターンマッチング それは、プログラミング言語がサポートしている限り、その言語がサポートする制限まで何でもできる、すべての人にとって自由なものですか?または、より良いガイドラインがありますか?

4
linqは表面に表示されるよりも効率的ですか?
このようなものを書くと: var things = mythings .Where(x => x.IsSomeValue) .Where(y => y.IsSomeOtherValue) これは次と同じですか: var results1 = new List<Thing>(); foreach(var t in mythings) if(t.IsSomeValue) results1.Add(t); var results2 = new List<Thing>(); foreach(var t in results1) if(t.IsSomeOtherValue) results2.Add(t); または、以下のように機能するいくつかの魔法があります: var results = new List<Thing>(); foreach(var t in mythings) if(t.IsSomeValue && t.IsSomeOtherValue) results.Add(t); それともまったく異なるものですか?
13 c#  linq 

3
適切にキューに入れてシリアル化していますか?
さまざまなサービスを通じてメッセージを処理します(1つのメッセージは、完了する前におそらく9つのサービスに触れ、それぞれが特定のIO関連機能を実行します)。現在、パフォーマンスに関して最悪のケース(XMLデータコントラクトシリアル化)とベストケース(メモリ内MSMQ)の組み合わせがあります。 メッセージの性質は、シリアル化されたデータが約12〜15キロバイトになり、週に約400万のメッセージを処理することを意味します。MSMQの永続メッセージは私たちにとって遅すぎました。データが大きくなるにつれて、MSMQのメモリマップファイルからのプレッシャーを感じています。 サーバーのメモリ使用量は16 GBで、キューイングのためだけに増加しています。 メモリの使用量が多い場合、マシンがスワップを開始するため、パフォーマンスも低下します。既にMSMQの自己クリーンアップ動作を実行しています。 ここで間違っている部分があるように感じます。RavenDBを使用してメッセージを永続化し、識別子をキューに入れようとしましたが、パフォーマンスは非常に遅くなりました(せいぜい毎分1000メッセージ)。それが開発バージョンを使用した結果なのかどうかはわかりませんが、より高いスループットが必要です[1]。コンセプトは理論上は非常にうまく機能しましたが、パフォーマンスはタスクに応じていませんでした。 使用パターンには、すべての読み取りを行うルーターとして機能する1つのサービスがあります。他のサービスは、サードパーティのフックに基づいて情報を添付し、ルーターに送り返します。ほとんどのオブジェクトは9〜12回タッチされますが、約10%は、サードパーティが適切に応答するまで、このシステムでしばらくループすることを強制されます。この理由でメッセージの優先度フィールドを使用するため、サービスは現在これを考慮しており、適切なスリープ動作を持っています。 だから、私の質問は、C#/ Windows環境でディスクリートだがLAN接続されたマシン間でメッセージを渡すための理想的なスタックは何ですか? 通常、XMLシリアル化ではなくBinaryFormatterから始めますが、シリアル化をドキュメントストアにオフロードするのがより良い方法である場合、それはうさぎの穴です。したがって、私の質問。 [1]:私たちのビジネスの性質は、メッセージをより早く処理するほど、より多くのお金を稼ぐことを意味します。週の後半にメッセージを処理すると、そのお金を稼ぐ可能性が低くなることを経験的に証明しています。「1分あたり1000」というパフォーマンスは非常に高速に聞こえますが、実際にはその数が10k /分以上必要です。1週間あたりのメッセージ数を指定しているからといって、それらのメッセージを処理するのに1週間あるというわけではありません。 ===============編集: 追加情報 コメントに基づいて、いくつかの説明を追加します。 シリアル化がボトルネックであるかどうかはわかりません。アプリケーションのベンチマークを行ったところ、シリアル化はヒートグラフに表示されますが、サービスのCPU使用率の2.5〜3%にしか関与していません。 私は、私たちのメッセージの永続性とMSMQの潜在的な誤用についてほとんど心配しています。キューのパフォーマンスを維持できるように、非トランザクション、非永続メッセージを使用していますが、少なくとも永続メッセージが再起動後も存続できるようにしたいです。 RAMを追加することは一時的な対策です。マシンはすでに4GBから16GBのRAMに移行しており、追加を続けるためにマシンを停止することはますます難しくなっています。 アプリケーションのスタールーティングパターンにより、オブジェクトがポップされてからキューにプッシュされる時間の半分は、まったく変化しません。これは、他の場所の何らかのキー値ストアにそれを保存し、メッセージ識別子を単に渡すことに再び役立ちます(IMO)。 スタールーティングパターンはアプリケーションに不可欠であり、変更されません。途中のすべてのピースが非同期に(ポーリング方式で)動作し、再試行動作を1か所に集中させたいため、アプリケーションをムカデにすることはできません。 アプリケーションロジックはC#で記述され、オブジェクトは不変のPOCO、ターゲット展開環境はWindows Server 2012です。特定のソフトウェアがLinuxでのみサポートされている場合、追加のマシンを立ち上げることができます。 私の目標は、現在のスループットを維持しながら、最小限の資本でメモリフットプリントを削減し、フォールトトレランスを向上させることです。

3
非IT管理者は、重要なレガシーソフトウェアの長期的なメンテナンスと開発をどのように保護する必要がありますか?
私たちは、非常に便利で堅牢なソフトウェアのコレクションを備えた、小規模で非常に専門的な福利厚生管理会社です。一部はCOBOLで書かれていますが、ほとんどはBASICです。2人の専任コンサルタントがこのシステムを30年以上にわたって適切に維持および改善してきました。言うまでもなく、彼らはすぐに引退します。(そのうちの1人は数年引退することを切望していましたが、過失に忠実であり、夫がゴルフを優先するべきだと主張しているにもかかわらず、固執しています。) 私たちは、使用している種類のソフトウェアを提供している国内の3社のみのうちの1社によって開発されたシステムへの転換の道を歩み始めました。この会社は理論的には変換プロセスを完了することができますが、タイムリーにそれを行うためのリソースがなく、実行する必要のある種類のサービスを提供できないと信じるようになりました。私たちのビジネス。(自分の優先順位を設定でき、適切と思われるリソースを割り当てる権限を持っていることほど素晴らしいことはありません。) ハードウェアは問題ではありません。最新のサーバーで非常に効果的にエミュレートできます。COBOLとBASICが最新の言語である場合、現在のコンサルタントの代替品が今後見つかる可能性があるというリスクを負うことになります。 このようなレガシープラットフォームに集中し、私たちのようなシステムをサポートするためのプログラミングおよびソフトウェア開発の才能を提供し、適切なプログラミングの才能を見つけるリスクを背部から排除するITサポート会社のビジネスモデルがあるはずです若いプログラマーに生産的でやりがいのあるキャリアを持たせることを納得させる仕事。一部にはBASICのような古くてセクシーではない言語で。 要するに、非IT管理者として、この移行をどのように最適に管理できるでしょうか。
13 legacy 

5
*どんな*プログラムタスクも状態なしで表現できますか?
これは理論的な質問ですが、私が現在理解しているプログラミングの長年の後に、主にC ++を使用する「通常の」命令型テクニックです。 これにより、完全に状態指向のプログラムを、純粋に機能的で状態のない別の実装に技術的に置き換えることができるのではないかと思いました。 それは興味をそそるアイデアであり、関数型プログラミングには明確で優雅なものがあることを認めなければなりません。

6
ファイル名にメタデータ情報を保存するのは悪い習慣ですか?より良いソリューション?
私が働いている場所に気づいたのは、人々がファイル名に情報を保存し、ファイル名を解析することに熱心だということです。 私にとってこれは特に良い習慣ではないようです。スクリプトがファイルをグロッビングし、別のファイルが最初に一致するため間違ったスクリプトを取得するという問題が既に発生していることを確認しました。 それは悪い習慣と見なされますか? ある種のメタデータに基づいてファイルシステムからファイルを取得するために受け入れられている他のソリューションは何ですか?

4
Rails:デメテルの混乱の法則
私はRails AntiPatternsという本を読んでいて、彼らはデメテルの法則を破らないために委任を使うことについて話しています。主な例は次のとおりです。 彼らは、コントローラでこのようなものを呼び出すことは悪いと信じています(そして私は同意します) @street = @invoice.customer.address.street 提案された解決策は、次のことを行うことです。 class Customer has_one :address belongs_to :invoice def street address.street end end class Invoice has_one :customer def customer_street customer.street end end @street = @invoice.customer_street ドットを1つしか使用しないため、ここでデメテルの法則に違反していないと述べています。あなたはまだ顧客を通り抜けて住所を通り、請求書の番地を取得しているので、これは間違っていると思います。私は主に私が読んだブログ投稿からこのアイデアを得ました: http://www.dan-manges.com/blog/37 ブログの投稿では、主な例は class Wallet attr_accessor :cash end class Customer has_one :wallet # attribute delegation def cash @wallet.cash end end …

2
RESTful APIはフォーム全体のデータを提供する必要がありますか?
データ用にRESTful APIを完全に使用するJavaScript Webアプリケーションがあるとします。 このアプリケーションにはデータフォームがあり、/ product / 12345のレコードを編集しているとします。フォームを作成するとき、/ product / 12345にRESTfulリクエストを行い、JSONデータを取得します。 { "id": 12345, "name": "Some Product", "active": true, "sales_user_id": 27 } したがって、私のフォームには、営業担当者を選択するためのドロップダウンリストがあるのは明らかです。このリストを作成する必要があります。 データはどこから取得する必要がありますか?最も一般的なアプローチは何ですか? / product / 12345要求応答の一部にすることは理にかなっていますか? { "id": 12345, "name": "Some Product", "active": true, "sales_user_id": 27, "sales_users": [ {"id": 1, "name": "Anna Graham"}, {"id": 2, "name": "Dick Mussell"}, {"id": …
13 api  rest  forms 

2
Webホストで「git push」更新ファイルを作成する方法は?
私は共有ホスティングの下で​​同じウェブホスティングサービスですべてホストされているいくつかのサイトを持っています。私のWebホストはGitをサポートしており、SSHにアクセスできます。ラップトップでもGitをセットアップできます。 「git push origin master」を実行すると、Webサーバー上のファイルが自動的に更新され、以前のコミットのファイルのバックアップも保存されるため、必要に応じて簡単にロールバックできます。これは可能ですか?
13 git  web 

2
インターネットが最初から最後までどのように機能するかについてのインタビューの質問に対して、より技術的な回答が必要です[非公開]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 過去2週間に5人の個別のインタビューを受けましたが、そのうち5人のうち3人がこの質問をしました。 「Google.com」を押してから画面に表示されるページまでの間に何が起こるかを説明してください。 基本的に、インターネットの仕組み。この質問をもう一度受けたら、3回も準備ができていると思います。 私はいくつかのことを知っていますが、私の答えが十分であると確信していません。基本的に、DNSサーバーは「google.com」をIPアドレスに変換することに言及しています。私はTCP / IPについて少し説明します。次に、ブラウザーが解釈して表示するブラウザーに送り返される要求されたページを文字通り処理するWebサーバーについて説明します。 前にも言ったように、自分の答えが十分に技術的であるとは確信できません。私が省略しているステップは何ですか? 価値があるのは、この3回のうち2回は同じ会社で働いていたので、3回目のインタビューのために電話をかけられるので、爆撃することはできません あまりにも難しいです。

1
なぜ関数型プログラミングより命令型プログラミングが好ましいのですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 背景:私は、一般的なメンタルモデルが不可欠なプログラミングであるVB.NETショップで働く関数型プログラミングを提唱しています。システムの基盤はWinFormsであるため、命令型プログラミングから完全に逃れることはできないと理解できますが、そのメリットを信じているため、可能な限りFP(主にLinq経由)を使用しようとしています。 FPに対する議論と反論 流fluentなLinqは、このスタイルがシーケンスを別のシーケンスまで処理し、それを繰り返すという点で、命令型の対応するものよりも効率が低いことに気付くかもしれません。一般に、シーケンス上の繰り返しパスを避けるために最適化できる命令型アプローチよりも数パス多くかかります。このため、リードは、明らかに「効率が悪い」機能的アプローチを選択する理由を理解できませんでした。 反論:CPUサイクルの観点からは効率が悪い場合がありますが、各行はシーケンスを通過するときに1つのことだけを行うため、人間が理解しやすく、追跡しやすいと感じました。私にとって、これは、自分のステーションの各人がやるべき仕事が1つしかない組立ラインがあるような気がします。効率の無視できるトレードオフは、懸念がきちんと分離されたコードによって補償されると感じています。 私の店で聞くFPに対する次の議論は、デバッグするのが難しいということです-それは本当です。Linqコードをステップオーバーするのは簡単ではありません。そして、すぐに見つけられない問題をよりよく追跡して分析するために、メソッドチェーンを解く必要がある場合があります。 _Counter-argument:ほとんどの場合、機能スタイルは読み方がより宣言的であり、エラーが機能チェーン内でスローされると、私は通常、問題をすぐに見つけることができるため、これには問題はありません。 私の質問 私は店で機能的なスタイルを宣伝しようとしてきましたが、私は前進しているとは感じません。私は両方のスタイルのプログラミングを行ってきましたが、最近Haskellに手を出したばかりです。長年の命令的な経験にもかかわらず、私はJavaScriptでFPを日常的に使用しているので、それは私に成長しました。命令型のスタイルにこだわった場合に行ったことと比較すると、コアの正当性のメモが鳴ります。私は脳を機能的思考、機能的構成に向けて再訓練しました。 私が理解できないのは、FPのメリットを他の人に納得させるのがどれほど難しいかです。 たとえば、私のショップの開発者はLinqを使用していますが、通常はドメインデータを処理するコンテキストで使用しています。私はより一般的な意味でそれを使用し、シーケンス/リストまたは永続的なデータ構造を扱うときはいつでもそれを好みます。チームメイトにLinqの使用を拡大するよう説得することができませんでした。 私が理解しようとしているのは、開発者がFPを好まない原因です。 FPの経験が豊富であるが、命令型を支持することに決めた人からの回答を期待したい。機能を使用するのではなく、命令にとどまるという決定を下した理由は何ですか? 命令型プログラミングと関数型プログラミングの違いを強調する追加の例を次に示します。 SelectedRowsLinqでグリッドのメソッドを次のように書きました。 Public Property SelectedRows() As DataRow() Implements IDataSourceControl.SelectedRows Get Return Me.ugrBase.Selected.Rows. OfType(Of Infragistics.Win.UltraWinGrid.UltraGridRow)(). Select(Function(ugr) ugr.ListObject). OfType(Of DataRowView)(). Select(Function(drv) drv.Row). ToArray End Get ただし、このスタイルのコードは一部の開発者を不快にさせるため、当社のリードはそれをより馴染みのあるものに書き換えました。 Public Property SelectedRows() As DataRow() Implements IDataSourceControl.SelectedRows Get Dim plstRows As …

4
アジャイル方法論におけるスタンドアップの目的とその期間は何ですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 私はかつてウォーターフォールの方法論で働いていましたが、今ではアジャイルの方法論に従っているチームにいます。彼らはそれを間違っているようです。たとえば、1日25分以上続くスタンドアップがあり、これは非常に面倒です。さらに、私は他の何よりも自分の給料を経営陣に正当化しているように感じます。 このように感じるのは間違っていますか?これは通常、スタンドアップが行われている方法ですか?

2
機能要件、運用要件、技術要件の違いは何ですか?
Javaに基づいてタスクを実行しましたが、先輩が私にグローバル化されたバグ追跡ツールを作成するための要件を収集するように割り当てました。 ウィキペディア とmindtoolsのWebサイトから多くのタイプの要件を読みましたが、非常に混乱していました。 機能要件、運用要件、技術要件の正確な違いは何ですか?

5
データベースの使用は、テキストファイルからのデータの解析よりも優先されるべきですか?
codereview.SEの成長を測定するPythonプログラムを作成していました。私のアプローチは、フロントページに表示される「サイトの統計」を取得し、ハードドライブに保存することでした。これは毎日1回行う予定です。これまでに、統計を取得してテキストファイルに追加するのに十分な量を作成しました。Pythonスクリプトはgithubで表示できます。私が使用している形式は次のとおりです 22-08-2013 questions 9073 answers 15326 answered 88 users 26102 visitors/day 7407 22-08-2013 questions 9073 answers 15326 answered 88 users 26102 visitors/day 7407 スクリプトを2回実行して、ファイルで使用する形式を取得しました。最初は自分で保存するので、フォーマットは同じであるため、簡単に解析できますが、よくわかりません。データベースを使用する方が、データを取得する方が簡単であるため、ここではより良いはずです。ただし、データベースを使用したことがなく、SQL、MySQL、またはRDBMSのその他のバリアントについての知識もありません。 だから、これは私に質問をもたらします。データをテキストファイルに保存するよりも、データを保存するのにデータベースを優先すべき場合 データベースが必要なのか、単純なテキストファイルが必要なのかを判断する際に参照できるポインタはありますか? PS:より良いタグを追加できる場合は追加してください。追加できるタグについて疑問がありました。

2
Haskellのように、Scala OptionタイプがMaybeと呼ばれないのはなぜですか?[閉まっている]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 Haskellのように、Scala OptionタイプがMaybeと呼ばれないのはなぜですか? 多分私にはもっと「意味論的」になりますが、Optionには私が知らない別の動作があるかもしれません。 ScalaのOptionがMaybeと呼ばれなかった特別な理由はありますか?

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