問題タブ [enterprise]

私の仕事では、約3,000の個別のテストケースで構成されるテストのグループを実行しています。以前は、このテストスイート全体を1台のマシンで実行していましたが、テスト実行全体を完了するのに約24〜72時間かかりました。テストをグループ化して約3台の別々のマシンに分散する独自のシステムを作成しました。テストは優先順位が付けられ、コアテストが最初に実行されてより迅速な結果が得られ、追加のテストが使用可能なマシンがある場合に実行されます。

誰かがテストを複数のマシンに分散して、完全な実行の合計テスト時間を短縮するための良い方法と、それを達成するために使用されたツールを見つけたのではないかと思います。私はいくつかの調査を行い、TestNGはこの方向に進んでいるように見えますが、まだかなり開発中であるようです。

テストを書き直す予定はありませんが、新しいテストを追加したり、新しい製品やアドオンをテストしたりするときに、非常に多くのテストを処理しているという事実に対処できるようにしたいと思います。一方、3.x非常に基本的な方法でもJunitテストを配布するのに役立つツールを見つけることができれば、それを行うために独自のツールを維持する必要がないので、それは役に立ちます。

私が行う作業のほとんどは、エンタープライズWebアプリケーションと見なすことができるものを使用することです。これらのプロジェクトには、大きな予算、より長いタイムライン（3〜12か月）、および大幅なカスタマイズがあります。開発者として、次のデスクトップOSとしてのWebのアイデアを宣伝してきたため、顧客は、この「新しいOS」で実行されるソフトウェアがデスクトップと同じように反応することを期待するようになりました。これには、自動アップグレードの管理が簡単なことも含まれます。つまり、「アップデートが利用可能です。アップグレードしますか？」これも現実的な期待ですか？この機能を実装しようとした経験から誰かが話すことができますか？

Lisp は学術界で非常に早い段階で一連の興味深い言語機能を開発しましたが、それらのほとんどは本番環境で普及することはありませんでした。

JavaScript などの一部の言語は、ガベージ コレクションやレキシカル クロージャーなどの基本的な機能を採用しましたが、強力なマクロ、データとしてのコード、カスタム制御構造など、大規模なプログラムの作成方法を実際に変更する可能性のあるすべてのものは、他の関数型言語内に広まっているようですが、重要なプロジェクトに使用するのに実用的な言語はありません。

関数型プログラミング コミュニティは、参照透過性、一般化されたケース式 (つまり、パターン マッチング、C/C# スイッチのように不自由ではない)、カリー化された関数など、(関数型プログラミング自体とは別に) 他にも多くの興味深いアイデアを思いつきました。通常のプログラミングでは明らかに有用であり、既存のプログラミングの実践と簡単に統合できるように思われますが、何らかの理由で、学問の世界で永遠に立ち往生しているようです.

なぜこれらの機能が採用されるのにこれほど苦労するのでしょうか? 「ファーストクラス関数」を中途半端にコピーするのではなく、Lisp から実際に学ぶ現代的で実用的な言語はありますか?それとも、これを不可能にする固有の競合があるのでしょうか?

バージョン 1.0 からの C# 開発者として、F# は過去数週間の自由時間を確保してきました。現在、コンピュータは 2 コア、4 コアで販売されており、マルチスレッド化を実現するのは必ずしも簡単ではありません。

現時点では、F# は複雑なワークロードや重いワークロードに対して大きな可能性を秘めていることがわかります。F# は (RTM になったら) エンタープライズ ソフトウェア市場で重要なプレーヤーになると思いますか?

エンタープライズ Web ベース システム (J2EE でプログラムされていますが、これはより一般的な質問です) の保守を支援していますが、エンタープライズ システムの「健全性」を測定するための優れたツールはありますか? たとえば、サーバーのメモリ容量をチェックしたり、バッチ実行のステータスをチェックしたり、一定時間内に処理されたレコード数をチェックしたりするツールはありますか?

これを回答ごとに 1 つのツールに限定したくはありませんが、回答ごとに複数のツールを使用しても問題ありません。

私たちは、エンタープライズ e コマース Web アプリケーション (Java/サーブレット ベース) のモバイル ブラウザー サポートへの道をたどり始めています。もちろん、決定すべきことはたくさんありますが、モバイル ブラウザーを確実に検出し、それに応じて返されるコンテンツを決定できるようにすることが、基礎となるように思えます。httpリクエストに基づいて（迅速に）この決定を行う標準的な方法はありますか、理想的には、リクエストを行っている特定のブラウザとデバイスに関する詳細情報（画面サイズ、html機能など）を収集しますか？

また、既存の大規模なエンタープライズ Web アプリケーションを利用して、開発側からモバイル ブラウザー サポートを設計するというこの道をたどった人からの補足情報もあれば幸いです。

[編集] 私は確かにリクエスト ヘッダーを理解しており、標準ユーザー エージェントのデータベースに関する情報は非常に役立ちます。「その他の」リクエストヘッダープロパティについて話している場合は、同様の標準化された名前/値のリソースを含めることができれば、大きな助けになります。

[編集] 何人かのユーザーが、検出を行う Web サービスへの回線経由の呼び出しを含む解決策を提案しています。これでうまくいくと確信していますが、次の 2 つの理由から、企業の e コマース サイトには適していません。1) 速度。サード パーティへのすべてのページ リクエストに対する回線経由の呼び出しは、パフォーマンスに大きな影響を与えます。2) 依存関係/法律。ウェブサイトの応答時間と主要な機能をサービスに結び付けますが、これは法的およびリスク上の理由から恐ろしいことです.

db4o を使った最初のテストに非常に感銘を受けました。しかし、db4o を搭載したエンタープライズ クラスの Web サイトがいくつあるのだろうかと思っています。メインの Web サイトには何も表示されていません。

db4o を使用しない理由がわかりません。たとえば、トランザクションや同時実行性を処理する方法には十分なサポートがあるようです。

私が見ることができるウェブサイトのリストを持っている人はいますか？

大規模または中規模のプロジェクトで、オープン ソースの .NET 実装である Mono を使用した人はいますか? 実世界の本番環境での準備が整っているかどうか疑問に思っています。安定していて、高速で、互換性があり、使用するのに十分ですか? プロジェクトを Mono ランタイムに移植するには多大な労力が必要ですか、それとも Microsoft のランタイム用に既に記述されたコードを取得して実行するだけの十分な互換性がありますか?

ここでは個人のパスワード管理について説明しましたが、会社全体のレベルでパスワードをどのように管理していますか？

見習い期間中、私はいくつかの小規模なプロジェクトにNHibernateを使用しましたが、そのほとんどは自分でコーディングおよび設計しました。さて、より大きなプロジェクトを開始する前に、データ アクセスを設計する方法と ORM レイヤーを使用するかどうかについての議論が起こりました。私はまだ見習い期間にあり、エンタープライズ プログラミングの初心者であると考えているため、オブジェクト リレーショナル マッパーをデータベースに使用すると開発が大幅に容易になるという私の意見を押し付けようとはしませんでした。開発チームの他のコーダーは私よりずっと経験が豊富なので、彼らの言うことに従うだけだと思います。:-)

ただし、NHibernate または同様のプロジェクトを使用しない主な理由のうちの 2 つを完全には理解していません。

1. SQL クエリを使用して独自のデータ アクセス オブジェクトを作成し、それらのクエリを Microsoft SQL Server Management Studio からコピーするだけです。
2. ORM のデバッグは難しい場合があります。

したがって、もちろん、多くの s などを使用してデータ アクセス レイヤーを構築することもできますSELECTが、ここでは、自動結合、プロキシ クラスの遅延読み込み、およびテーブルが新しい列を取得したり、列が改名。(多数のSELECT、INSERTおよびUPDATEクエリの更新と、マッピング構成の更新、および場合によってはビジネス クラスと DTO のリファクタリング。)

また、NHibernate を使用すると、フレームワークをよく理解していないと、予期しない問題が発生する可能性があります。たとえば、文字列の長さを自動的に検証するように設定した Table.hbm.xml を信頼することができます。ただし、「単純な」SqlConnection クエリ ベースのデータ アクセス レイヤーにも同様のバグがあると想像できます。

最後に、上記の議論は、重要なデータベース ベースのエンタープライズ アプリケーションに ORM を使用しない正当な理由になるのでしょうか? 彼ら/私が見逃したかもしれない他の議論はおそらくありますか?

(おそらく、これはチームワークを必要とする最初の「大規模な」.NET/C# ベースのアプリケーションのようなものだと思うことを付け加えておく必要があります。単体テストや継続的インテグレーションなど、スタック オーバーフローではごく普通のことと見なされているグッド プラクティスではありません。 -現在までここに存在します。)