問題タブ [enterprise]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
4 に答える
1010 参照

wcf - 企業内の WCF について、あなたの経験から何かヒントはありますか?

エンタープライズ環境で WCF を使用している人々からの連絡をお待ちしています。

ロールアウトの主なハードルは何でしたか? パフォーマンスの問題?どんなヒントでも大歓迎です!

可能であれば、いくつかの一般的な統計とサーバー構成を提供してください!

0 投票する
14 に答える
4042 参照

python - エンタープライズ Web サイトとイントラネットのフレームワーク/CMS の提案 (社長にしっかりと納得してもらう必要があります!)

スタック オーバーフロー コミュニティの皆様

私が勤務している大企業のいくつかの Web サイトをオーバーホールし、組織内のコンテンツ管理とドキュメント ストレージ用の内部イントラネット サイトを開発するタスクを与えられました。

私の「問題」は次のとおりです。彼らは、「実績のある安定したエンタープライズ対応のテクノロジー」であることを証明できるフレームワーク/言語/テクノロジーのセットを使用することを望んでいます。

仕様の「全体像」はそれほど複雑ではありません。主に製品情報とドキュメントを扱う各部門の Web ページを管理するエンタープライズ クラスの CMS を実装します (つまり、www.linksys.com の単純なバージョン)。

オープンソース プログラマーとして、私は Python を TurboGears で使用してゼロから構築したいと考えていますが、TurboGears が企業での膨大な実績を持っていることを社長に証明する方法を実際に見つけることができません。Zope は多くの企業で使用されているようですが、私には少し肥大化しているように見えます。Django も選択肢の 1 つかもしれませんが、TurboGears ほど柔軟ではないようです。

PHP は使いたくありませんが、Drupal には「適切な」名前 (AOL、Sony、MTV) が記載された非常に優れた履歴書があります。さらに、多くの CMS コンポーネントをゼロから構築する手間を省くことができます。

Rails も別の選択肢かもしれませんが、私はそれにあまり詳しくありません (そして、Python/PHP プログラマーとして、Ruby の構文は私を夢中にさせます)。

SO コミュニティは、このようなプロジェクトに対して何を提案しますか? 多くの方が同じジレンマに直面したことがあると思います。あなたにとって何がうまくいった/うまくいかなかったのですか?前にも言ったように、私の最初の選択肢は Python、2 番目は PHP、3 番目は Rails です。

ありがとう、セス

0 投票する
3 に答える
668 参照

web-services - 拡張可能なクエリ インターフェイスの優れた設計とは?

私たちのアプリケーションは、Web サービスを介してクエリを公開します。クライアントは、追加の基準を指定して返される結果をさらに制限したり、まだ行っていないことを要求したりして、カスタム クエリを必要とすることが多いことがわかりました。公開。

これで、これらの新しいメソッドごとに新しいメソッドを作成するというアプローチを取ることができますが、それはやや不便です。クライアントサイトでのアプリケーションの展開には、通常、数週間の段階的な統合テストが必要です。アプリケーション管理者がパラメーター化された名前でクエリを定義する名前付きクエリ メカニズムと、これらのパラメーターを呼び出すだけの対応する Web サービスを提案しました。ただし、誰かが以前にこの問題を解決したと思わざるを得ないので、可能な設計について SO コミュニティから意見を求めたいと思います。

ありがとう!

アップデート

仕様パターンは良いものですが、私たちのアプリケーションは十分な量のデータを処理するため、クエリ作業の多くを RDBMS にプッシュする必要があります。さらに、私たちは 3 つの RDBMS バックエンドをサポートしているため、最大公約数アプローチの使用に行き詰まっています。つまり、最も機能の少ないデータベースが提供できる機能をできるだけ多く使用します。

0 投票する
4 に答える
1565 参照

architecture - エンタープライズ アプリケーション間のデータ フローをどのように表示/レイアウトしますか?

私の雇用主はスイスの大手通信会社です。パフォーマンス管理、障害管理、構成管理など、さまざまなタスクのデータ転送に使用される多くのシステムがあります。

これらのシステムがどのように相互作用するかを「管理者」(とんがり髪など)に説明するために、データフロー/フォーマット/プロトコルに関する情報を「データベース」(カンマ区切りの説得力)に収集し、Graphviz のコードを生成しました(http: //www.graphviz.org/ ) と Yed ( http://www.yworks.com/en/products_yed_about.html ) を使用して、これらのグラフを視覚化します。

私のDBから生成されたこれらのグラフを表示することは、最初はかなり効果的でした..しかし、新しいシステム/データフローを追加すると、GraphvizとYedの両方がグラフを再レイアウトする原因となります.昨日見たあのグラフを今日のグラフに。

エンタープライズ アプリケーション間のデータ フローをどのように表示/レイアウトしますか?

0 投票する
1 に答える
854 参照

database - データベースを他のシステムに複製する最良の方法

大規模な (6 TB) oracle データベースへの更新ストリームを別の非 DBMS システムにレプリケートする最良の方法は何ですか? Oracle データベースを「一括ロード」する必要はありませんが、すべての更新をほぼリアルタイム (10 秒以下のレイテンシー) で別の自家製システムに流したいだけです。更新は 1 秒あたり 10 メガバイトに相当する 150 行/秒の速度で行われます。

明確にするために、あるデータベースから別のデータベースに複製していないことを強調しておきます。これはアプリケーション統合の問題です。データベースから社内の非データベース アプリケーションにレプリケートする必要があります。エンタープライズ サービス バスを使用することを考えましたが、それは不適切なようです。

0 投票する
1 に答える
2693 参照

enterprise-library - Enterprise Library 4: ログ ブロック フラット ファイル

テキスト ファイルへのログ エントリの作成に問題があります。これが私の ASP.net アプリでのロギング構成です。

ここに私のvb.netコードがあります

db.ExecuteNonQuery(cmd, tr) tr.Commit() result = True Catch ex As Exception Dim entry As New LogEntry() entry.EventId = 11 entry.Message = ex.Message entry.Categories.Add("General") Logger.Write(エントリ)

これまでに見つけたすべてのチュートリアルと例は、古いバージョンの Enterprise Library に基づいています。私は Enterprise Library 4 を使用しています。誰か私が間違っていることを知っていますか? それは私のコードですか、それとも設定ですか?Enterprise Library バージョン 4 の詳細なチュートリアルはどこにありますか。付属のクイック スタートに従おうとしましたが、頭も尻尾もできません。

0 投票する
5 に答える
757 参照

project-management - 将来の機能に優先順位を付ける方法(エンタープライズWeb開発)

あなたが2000人のユーザーと7人の開発者を抱える社内のエンタープライズWebアプリケーションのプロダクトマネージャーであるとします。350の将来の機能のリストがあり、それぞれが5〜150開発者の作業日数の範囲です。

作業する機能をどのように選択し、リリースプロセスをどのように実行しますか?

これが私が考えていることです:(退屈ならスキップしてください)

  • リリースプロセス。一度に複数の機能に取り組み、準備ができたらそれぞれを個別にリリースします。もう1つのオプション(これまで行ってきたこと)は、特定の機能セットを選択し、それらを「リリース」として指定して、一度にすべてリリースすることです(大量の電子メールで発表します)。

    リリースプロセスが短いことの利点は、開発が完了したらすぐに機能をリリースできることです。より大きなプロセスの利点は、整理が容易なことです。

  • 機能の優先順位付け。将来のすべての機能を、機能、説明、コメント、見積もり、メリット、(あなたの)見積もり、(あなたの)メリットの列を含むスプレッドシートに入れます。2人の上級エンジニア、もう1人の上級プロジェクトマネージャーとあなた自身にコピーを渡してください。

    エンジニアはすべての機能を見積もります(どの程度正確に?お互いに相談しますか?)。メリットを判断するために、全員が将来の機能にポイント(合計= 10 * [将来の機能の数])を割り当て(互いに相談せずに?)、スコアと平均(?)を比較します。

    ここでのもう1つの潜在的な戦略は、各機能を絶対的な(たとえば)1〜100のスケールでランク付けすることです。絶対的なランク付けがあると、機能リストの変更に応じて優先順位を付けることができるので便利です(誰かが新しい機能を提案するたびにポイントを再配布する必要はありません)。

あなたの戦略は何ですか?このレベルの詳細で問題を攻撃する本/ウェブサイトはありますか?

0 投票する
3 に答える
784 参照

dependencies - 調査する価値のあるリリース管理ソリューションはどれですか?

無数のアプリケーションを無数の言語で記述し、無数のプラットフォームやデータベースで実行しいる組織では、特に一部のリリースがサードパーティの場合、ビルドやパッチのリリースをどのように管理しているのでしょうか? 「リリース管理」アプリケーションがたくさんあることは知っていますが、人々がどのような経験をしたか知りたいです。

明確にするために、これは構成管理に関する質問ではありませんが、それはその一部かもしれません. 私は、ソフトウェア リリースの管理と、そこから生じる相互依存性と前提条件に関心があります。

0 投票する
21 に答える
14705 参照

php - LAMP スタックは企業での使用に適していますか?

LAMP (Linux、Apache、MySQL、PHP / Ruby / Python) スタックはエンタープライズでの使用に適していますか?

明確にするために、「エンタープライズ」とは、セキュリティ、堅牢性、スキルセットの可用性、総所有コスト (TCO)、スケーラビリティ、およびツールの可用性が重要な考慮事項である大企業または非常に大規模な企業を意味します。別の言い方をすれば、フレームワーク/アーキテクチャの外部採用を求める企業 - この種の環境では、エキゾチック/難解なものよりもユビキタスなものの方が「有効」と見なされます。

私は、Oracle、IBM、および Sun がさまざまな企業向けに LAMP スタックにシステムを実装したユース ケースを見てきました。また、yellowpages.com (Ruby on rails) や Facebook (php) などの Web サイトがその上に構築されている例も見てきました。ただし、これらの例はどれも、まさに私が探しているものではありません。

非常に大きな銀行 (例: Citigroup)、通信会社 (例: AT&T)、または製造業者 (例: Proctor and Gamble) のエンタープライズ標準である例を実際に見つけようとしています。明確にするために、私はそれが限られた意味で使用されている例を探しているのではなく (JP モルガン・チェースのように)、CRM、製造システム、または人事管理などのシステムのコア・プラットフォームであり、内部のおよび外部ウェブサイト。

これまで見てきた認識では、LAMP スタック上に構築されたアプリケーションはパフォーマンスが遅く、柔軟性が低いということです。私が聞いた議論のいくつかは次のとおりです。

  • Linux は、Unix、Solaris、または Windows サーバーほどサポートされていないと見なされています。

  • Apache は、BEA WebLogic や IIS などの Web サーバーよりも構成と保守が困難です。

  • MySQL は愛好家向けの「プライム タイムの準備ができていない」DB であり、SQL Server や Oracle の競合相手ではありません (ただし、PostgreSQL はより堅牢であるという評判があるようです)。

  • PHP / Ruby on rails は、CRUD (作成、読み取り、更新、および削除操作) 用に最適化されています。これは、CRUD を多用する Web アプリケーションを構築する場合の利点ですが、Java/Java EE または C# (どちらも一般的なエンタープライズ標準) よりもパフォーマンスが遅くなります。さらに、多くのアプリケーションやシステム (製造システムなど) には、多くの非 CRUD 機能があり、PHP や Ruby、さらには Python で構築するのが難しい場合があります。

LAMPスタックがエンタープライズに適しているという考えを支持または反論する議論を誰か提供してもらえますか?

ありがとう!

更新: LAMP スタックが企業での使用に適している場合があります: 外部向けブログ

0 投票する
3 に答える
643 参照

architecture - エンタープライズ シナリオで Google Gears を使用したことのある人はいますか?

クライアント コンポーネントとサーバー コンポーネントを持つアプリケーションを作成したいと考えています。クライアントは常にインターネットに接続されているとは限らないため、データをローカルに保存し、インターネット接続が利用可能なときはいつでもサーバーと同期する必要があります。データ同期は、クライアントからサーバーへ、およびサーバーからクライアントへの双方向になります。

最初は、ado.net 用の SQL Server Merge レプリケーション/Microsoft 同期フレームワークを利用し、C# Windows フォームを使用してクライアント アプリケーションを作成することを考えていました。

しかし、Google Gears は JavaScript で動作し、クライアントとサーバーの両方で使用できる asp.net Web アプリケーションを構築するだけでよいため、非常に優れたオプションのように見えます。さらに、Windows モバイル 5 および 6 で利用できるため、モバイル デバイスでも利用できます。

しかし、エンタープライズ シナリオで Google Gears を使用した人はいますか? Google Gears を使用して何か問題に直面した人はいますか?