51

新しいテクノロジーが安定し、試され、テストされるまでは、新しいテクノロジーを急いで採用するべきではないと言う人をよく耳にします。うまくいくのに 3 つのバージョンが必要だというジョークさえあります。これは実際の経験からの声かもしれませんが、少なくとも時々、そのような姿勢は自己満足、変化への抵抗、新しいスキルを習得するために必要な努力の結果です.

しかし、私の意見では、ソフトウェア業界で成功を収めるには、イノベーションのペースを維持することが重要です。大企業には R&D に専念する部門全体がありますが、中小企業では、開発チームが追いつく必要があります。正式に発表される前であっても、新しいテクノロジーに着手してください。これにより、有利なスタートを切ることができ、残りの部分についていくのに役立ちます。

可能な限り従おうとする戦略は次のとおりです。

  • 新しい技術を積極的に取り入れる
  • 実験には初期ベータ版を、開発にはプロトタイプと RC を使用する
  • 早期に採用したテクノロジーが正式にリリースされたときに、製品に対する最終的な変更に対処します。
  • アクティビティがまったくない、あいまいなオープン ソース プロジェクトに依存しないでください。
  • 必ず勉強してください。ただし、正式な製品ロードマップを考慮してください。

これまでのところ、熱心すぎて新しいテクノロジーの列車に飛び乗れないという代償を払ったことはありませんが、それでも利益を享受しています. これは単なる偶然なのだろうか、それともアーリーアダプターであることは結局それほど危険ではないのだろうか?

早期採用に関する議論に招待するよりも、このような問題は確かに議論の余地があり主観的なものであるため、新しいテクノロジーを早期に採用することが重大な間違いであることが判明し、悲惨な代償を払わなければならなかった実際の経験を聞きたいと思います。支払った。

4

42 に答える 42

25

私はかなり良い Java アプレットを書くことができます。すべてのテクノロジーは最終的には衰退しますが、これは非常に急激な上昇と下降がありました。

于 2009-07-23T15:07:10.680 に答える
24

私は現在、Microsoft Office Word 2007 の CustomXML サポートに悩まされています。

CustomXML を使用すると、ビジネス データなどをモデル化できるカスタム定義要素をドキュメントに含めることができます。たとえば、カスタム要素で XSD を定義し、それを docx ファイルに関連付けてから、プレースホルダーを CustomXML タグとして生成し、次を使用してドキュメントをナビゲート/変更できます。 C# (またはその他の .NET 言語) およびOpenXML SDK . OpenXML の利点は、自動化のために Office をサーバー マシンにインストールする必要がなくなり、サード パーティのライブラリを購入する代わりになることです。

要するに、Word 2007 でカスタム定義の XML を使用してドキュメントを開く機能に関して訴訟がありました。この記事から：

8月11日、同社はOffice Wordの販売差し止め命令を受け…

「この差し止め命令は、2010 年 1 月 11 日の差し止め命令日以降に米国で販売された Microsoft Word 2007 および Microsoft Office 2007 のコピーにのみ適用されます。この日付より前に販売されたこれらの製品のコピーは影響を受けません。」

Microsoft の対応は、Word の将来のバージョンから CustomXML のサポートを削除することであり、この機能を完全に削除するパッチをリリースしています。公式アップデートへのリンクはこちらです。この Microsoft OEM パートナー センター サイトによると:

米国では、次のパッチが必要です。この更新プログラムは、Office 2007 のすべての言語で機能します。

この更新プログラムをインストールすると、Word は DOCX、DOCM、または XML ファイルに含まれるカスタム XML 要素を読み取れなくなります。これらのファイルは引き続き開きますが、カスタム XML 要素はすべて削除されます。カスタム XML マークアップを処理する機能は、通常、Word ドキュメントの自動化されたサーバー ベースの処理に関連して使用されます。通常、カスタム XML は、Word のほとんどのエンド ユーザーによって使用されません。

エンドユーザーと開発者のごく一部がそれを利用していると思いますので、最後の文は正確であると考えています. 問題は、このテクノロジーを実際に利用したプロジェクトをどのように進めるかについて、現時点では何の言葉もありません (しゃれは意図されていません)。CustomXML は、私が現在取り組んでいる大規模なプロジェクトの土台です。この決定の影響は肯定的ではなく、CustomXML が提供する構造を維持する同等の代替アプローチがないため、実質的に前方互換性が妨げられます。

私の同僚の何人かと私は、このトピックについて豊富な知識を持っています...私たちが計画していたようにブログ記事を書くことができなかったのは良いことだと思います:) 私たちはこれでいくつかのかなり印象的な偉業を達成しましたVSTO ですが、このニュースは残念です。

このトピックに興味がある人は、次の記事をチェックしてください。

ZDNet の記事:

BNet の記事:

ソフトペディアの記事:

編集：公式アップデートへのリンクを追加しました。

于 2010-01-07T06:26:53.030 に答える
21

数年前、私たちは Notification Services と呼ばれる SQL Server 2005 の新機能を多用しました。残念なことに、これは SQL Server 2008 で廃止されました。これは重大な問題であり、ソフトウェア アーキテクトはすべての新しい Microsoft テクノロジに疑問を抱くようになりました。

ここにいくつかの詳細といくつかの詳細があります

Microsoft の Entity Frameworkにも問題がありました。

于 2009-05-24T17:53:25.770 に答える
9

スカラ。

紙の上では見栄えがするので、Scala のバージョンを最新の状態に保ちながらプロジェクトを書きました。バージョン番号 (2.7.x) とその開発年数により、比較的安全に作業を行うことができました。

さて、私は間違いを犯しました。問題？ドキュメンテーションとコード サンプルの深刻な不足、および絶えず変化するクラス ライブラリ (私の仕事中に 2 回、以前に動作していたコードに「非推奨」の警告が表示され始めました...そして、数か月にわたって同様のバージョンについて話しています。数字）。

多くを失ったとは言えませんが (これは私的なプロジェクトでした)、近い将来 Scala には触れません。とはいえ、それでも非常に素晴らしく、有望な言語だと思います。

于 2010-01-05T10:51:36.750 に答える
8

はい、あります！JSF 1.0で！Sun はそれをリリースする前に十分にレビューしなかったようです。

私たちは物事を機能させようとしてきましたが、しばらくして、エラーの原因が JSF のバグであることが判明し、回避策を使用する必要がありました。JSF 1.1 と myfaces-tomahawk 実装の使用が開始されてから、プロジェクトはある程度のスピードを持ち始めました。

于 2009-05-24T17:29:58.990 に答える
8

私がいたとき10、父は私のために真新しい新年の歌を演奏しようとしましたElektronika BK-0010-01。

言うまでもなく、シンセサイザーはテープからのロードに失敗し、隣人がギターを持って来るまで歌はありませんでした。

于 2009-05-24T17:37:34.500 に答える
6

最悪の場合は、新製品を使用してプロジェクトを 80% 達成したときに致命的なバグに遭遇した場合です。

80 年代半ばに、私の上司は、KnowledgeMan と呼ばれる新しい dBase の代替手段を試してみることを提案しました。私が自分のものだと思っていたいくつかの重大なバグが実際には彼らのものであることに気付いたのは、ずっと後のことでした。すべてを最初からやり直す必要がありました。それは私の仕事を犠牲にしました。

于 2010-01-08T18:45:52.073 に答える
6

はい。私は Lisp プログラマーです。私にはすべてが新しく未熟に見えます。:-)

于 2010-01-08T18:54:36.843 に答える
6

Delphi.NET。それを聞くと、まだチックがあります！

于 2010-01-04T15:49:31.777 に答える
6

QBASIC が実際に離陸したことはありません。私もそれを学ぶのに何年も費やしました。

OK、公平を期すために、それは私の最初の言語であり、学ぶための良い方法でした. その後、Visual Basic、そして VB.NET に置き換えられました。だから、それは私の時間の完全な無駄ではありませんでした。;)

ほとんどの場合、言語が正確に「離陸」しなくても、それは他の何かに適用できる良い学習体験です。

于 2009-07-23T15:05:15.940 に答える
5

残念ながら、それは両方の道を切ります。Windows用の大規模なWebベースのアプリの開発を最初に開始したとき、.NETはベータ版でリリースされていました。.NET1.0の最終リリースは間もなくリリースされました。

しかし、それは新しく、何が起こるのか、どれほど人気が​​あるのか​​、そしてMSが6か月後にそれを削除するのかどうかはわかりませんでした。そのため、私たちは実証済みのVB6を使い続けました。

そのVB6レガシーを維持する必要があり、しばらくの間制限されていました。どこにもリストされていませんが、特定のバージョンのWindowsでVBランタイムのサポートが廃止されるという妄想があります。

とは言うものの、.NETルートを使用することには、それ自体の問題があった可能性があります。1.0、1.1、および2.0は、それぞれが以前のバージョンと（いくつかの）非互換性を持って、次々とかなり早く出てきました。したがって、.NETプラットフォームを移行する必要があると、別のリスクが発生します。少ないですか多いですか？それを経験していない人には答えられません:-)

結局、あなたがそうするならあなたは堕落し、そうでなければあなたは堕落することができます。誰かが内臓を読んで、特定のテクノロジーがいつでも成功するかどうかを判断できる場合、彼らはソフトウェアで仕事をするべきではなく、おそらく代わりにヘッジファンド管理に入り、多額の現金を稼ぎ、早期に引退する必要があります： -）

于 2010-01-08T16:50:23.507 に答える
5

AzMan (Microsoft 認証マネージャー)

シングル サインオンの夢と、「既存のインフラストラクチャを活用する」ことができるという主張、または現在のマーケティングの発言に魅了されて、公開 Web サイト/Web アプリでこれを使用し始めました。システム管理者がツールを開発したりコードを書いたりすることなく管理できる ASP.NET のドロップイン ソリューション。ウィンウィンでしたよね？

この決定の結果、私たちはいくつかのことを学びましたが、いずれも学びたくありませんでした。

  • Active Directory 自体は、パブリック Web サイトにサービスを提供する認証メカニズムにはあまり適していません。能力がないわけではありません。かなり能力がありますが、博士号を取得して「Hello World」アプリを作成するようなものです。それは過度に修飾されており、そのようなコンテキストで必要とされる以上のことを行います。単純な古い SQL テーブルよりも操作がはるかに難しく、より多くのメンテナンスが必要です。

  • アズマンは遅い。非常に遅い。ロール プロバイダーはキャッシュを維持する必要があります。これにより、どのような種類のパフォーマンスについて話しているかがわかります。なぜこんなに遅いのか完全には理解できませんでしたが、ホーネットのネストした COM とそれが依存するネットワーク プロトコルに関係があるのではないかと思います。

  • キャッシュ (上記を参照) は、ほとんどまたはまったく制御できない場合、非常に危険なものになる可能性があります。新しいユーザーを手動で (つまり、サイト自体ではなく管理アプリケーションを介して) 追加した場合、これらのユーザーは、キャッシュの有効期限が切れてログアウトするまで、「承認されていません」画面が表示されます。これは、オンラインで自己登録したユーザーにも発生することがあります。理由はわかりませんでした。

  • ツールは恐ろしいものでした。信じられない場合は AzMan コンソールをざっと見てください。本当に頭が痛い場合は、いくつかのドキュメントを読んでください。なんでそんなに複雑なの？

  • それは薄片でした。多くの場合、プロバイダーは動作を停止し、不可解な COM エラー (毎回異なるエラー) を吐き出し、IIS または Web サーバー全体を再起動して、再び連携させる必要がありました。また、ドメイン信頼もセットアップしました。これは明らかに、社内の企業ドメインに 50,000 のパブリック ユーザー アカウントが必要なかったからです。唯一の問題は、管理者がロールを管理するためにセカンダリ ドメインの管理者アカウントにログインする必要があることでした。これは、コンソールに障害が発生するためです。プライマリから使用しようとすると、不可解な方法で (セカンダリ ドメインでドメイン管理者権限を持つエンタープライズ管理者としても)。

  • サポートは事実上存在しませんでした。基本的な SQL Server ロール プロバイダーを使用する場合 (使用していませんが、例としてだけです)、1,000 万のチュートリアルがあり、Google でエラー メッセージを検索したり、フォーラムで質問したりできます。AzMan で何か問題が発生したり、何か新しいことをしたいときはいつでも、良い情報を見つけるのに苦労しました。

  • コードの統合は厄介でした。たくさんの乱雑な COM レイヤーを通過する必要があり、インターフェイスはひどいものでした。私の記憶が正しければ、単純な承認チェックを行う方法はありませんでした。アプリ/ロール レジストリ全体をダウンロードする必要がありました。かなり前の話なので記憶が曖昧かもしれませんが。

最終的に、私たちはこれ以上我慢することができず、いくつかの SQL Server テーブルに基づいて自家製のシステムを構築するためにシステム全体を切り離すことにしました。移行は苦痛でしたが (上記の 2 つのポイントを参照)、完了し、振り返ることはありませんでした。

于 2010-01-07T15:15:10.277 に答える
4

Java

私は1996年に作業を開始することに非常に熱心で、いくつかのプロジェクトに使用しました。しかし、Web開発では、私は常にPerlと最近のPHPを好みました。GUI開発私は主に.NETを使用することになりました。スクリプトで処理できないいくつかのコマンドラインプログラムでは、Perl、Python、さらにはそのPHPを使用することを好みます。

私が書いたJavaプログラムのいくつかは長期間使用されていましたが、Java以前のアプリケーションのいくつかはまだ使用されています。

これの主な理由は、Javaで何かを開発するのに、別のプログラミング言語を使用するよりも常に時間がかかったためだと思います。そのため、結果として得られるアプリケーションには含まれる機能が少なく、置き換えが簡単でした。

通常、開発の速度は私の顧客にとって問題であるため、Javaは最終的に2番目の選択肢になる傾向があります。

于 2010-01-07T10:34:51.207 に答える
4

Mozilla XULRunner.

AIRの前はAdobe AIRでした。私たちはそれを使って人事管理システムを書きました。当時、XULrunner は FireFox の基盤となるエンジンとして「ちょうど」リリースされようとしていました。

プロジェクトを開始して 2 年が経ち、デプロイの直前に新しい XULrunner が出てきて、すべてのコードが完全に壊れてしまい、Firefox のデプロイはどこにもありませんでした。専用のデスクトップ インストーラーを使用して古いバージョンを展開することになり、それ以来、セキュリティやパフォーマンスの更新の恩恵を受けずにそれを使用してきました。それにもかかわらず、それは私たちの顧客との非常に成功したプロジェクトでした.

現在、Ext で実行するようにアプリを書き直しています。これは私たちにとって新しいホットなことですが、より多くのコミュニティ サポートがあり、何かに行き詰まった場合は商用サポートを提供しているようです。

于 2010-01-06T17:53:24.517 に答える
4

もちろん

私は現在、Fortran 2003 のアーリー アダプターであることの苦痛を感じています :-)

マーク

于 2010-01-04T16:14:04.677 に答える
3

ここで傾向に気づいた人はいますか？ここにあるテクノロジの大部分は、マイクロソフトによって作成され、キャンセルまたは変更されました...

私はまた、エンティティ フレームワークに加えられた変更により、Microsoft にやられました。

于 2010-02-01T17:29:40.417 に答える
3

Mac OS X での 64 ビット Carbon API: 私は個人的にこれに熱中することはありませんでしたが、大きなソフトウェア会社で働いている友人がいて、1 年かけてほぼすべてのコードを 64 ビット Carbon API を使用するように変換し、 WWDC で、これらの API が利用できなくなることが発表されました。

于 2010-01-08T21:01:56.963 に答える
3

市場でのプレゼンスが不足している場合:

  • グーグルズゴー
    • ツールチェーンが貧弱で、一般的なコンパイラや C との統合が欠けています。
  • Python3000
    • 必須の機能がない: イテレータ、クリーンアップされた内部、およびより整頓されたインターフェイスは、私たちハードコア ユーザーにとっては便利ですが、大多数はパフォーマンスを求めており、これは提供されていません。
  • C++0x
  • C99
    • 12 年が経過しましたが、これを完全に実装している主流のコンパイラはありません。人気のあるプロジェクトとニッチなアーキテクチャは安全のために C89 のままです。

低品質の場合:

  • Windows ビスタ
    • '言っ途切れる。
  • パーフォース
  • C++

アップストリームに遅れをとっている場合:

  • Windows 上の PyGTK
  • MSVC C サポート

私がこれらのテクノロジーをリストしたからといって、それらが良くないことを示唆しているわけではないことに注意してください。私はこれらすべての大ファンです (質の悪いものを除く)。これらのテクノロジーにやられているという私の意見は直接的なものです (通常、私は既存のテクノロジーの代替としてそれらをプッシュしようとしているか、または多額の投資が既に行われた後に単に障壁にぶつかっています.

于 2010-01-08T02:31:44.180 に答える
2

しかし、私の意見では、ソフトウェア業界で成功を収めるには、イノベーションのペースを維持することが重要です。

これはあなたの特定の質問に答えるものではありませんが、Crossing the Chasmという本に興味があるかもしれません。

于 2009-05-24T17:38:09.477 に答える
2

プログラミングではありませんが、まだ新しいテクノロジーの失敗です - 私は最初のミニ ATX ビルドでニップルを失いそうになりました。

于 2010-01-08T07:34:48.253 に答える
2

私はかつてwitangoの使用を余儀なくされましたが、それを乗り越えています。

于 2009-07-23T15:07:59.807 に答える
2

私にとっては、Delphi の IntraWeb がそれでした。

于 2009-07-23T15:04:58.267 に答える
1

黒い鳥。

MSNのインタラクティブコンテンツを作成するための素晴らしい開発環境。

于 2009-07-23T15:09:35.450 に答える
1

VBA - 製品への統合に多くの時間を費やしました。新しいリリースのたびに多くの時間を費やして、何かを壊さないようにしています。VB6 と VBA も COM ベースであるため、標準ユーザーとして実行し、レジストリへの書き込みアクセス権を持たない場合は問題になります。

于 2010-01-10T06:25:25.123 に答える
1

トゥルーベーシック

1980 年代半ば、私たちは、さまざまな DOS 実装で動作し、C 言語のように「ちょこちょこいじる」言語ではない開発プラットフォームを探していました。

私たちは、1964 年に BASIC の最初の作成者によって作成されたと宣伝されている True Basic を見つけました。これは、p コードに「コンパイル」された言語でした。DOS マシンで動作するだけでなく、GEM (Atari-ST) および Amiga ボックスでも動作しました。

これには、私たちが使用していた VAX/VMS マシンの開発環境で使用していたのと同じようなアドオンが含まれていました。Forms パッケージ、「ISAM」アドオン (PC で呼び出し可能なデータベースが登場する前) など。

残念ながら、マルチプラットフォーム機能は言語を十分に売り込みませんでした。ウィキペディアによると、Mac OS バージョンがあります (ただし、OS X や Snow Leopard はありません)。このメモを書いているときに、「現在の」TrueBasic ページも見つけました。

最終的に Visual Basic 1.0 が登場し、私のような BASIC プログラマーは全員、Microsoft の名前が付いていたのでチェックしました。もちろん、10 バージョンを経て、TrueBasic が V5.5 のまま .Net プラットフォームに移行しました。

于 2010-01-07T12:45:50.683 に答える
1

数えきれないほどありました。考えてみるとまだ痛いのは、WLPI (古い BEA ワークフロー製品) です。うまくいかず、ベンダーはそれを放棄しました。はぁ ...

とにかく、私は最新の状態に追いつくこと (そこに何があるかを知り、それを考慮に入れること) は非常に価値があると思いますが、次の場合にのみ最先端に住んでいます:

  1. あなたは切り傷を負って出血する準備ができています（お金/時間/リソース）
  2. それは重要な戦略的優位性/競争力を提供します。

これの良い例は AJAX です。今では十分に成熟しており、やむを得ない理由がない限り、すべての新しい Web サイトがそれを行う必要がありますが、最初にそれが可能になったとき、その上に構築された Web サイトは、従来の代替手段と比較して非常に高価でした.

一部の Web サイトでは、競争力を維持するために最新のルック アンド フィールが必要であり、サイト自体の機能が二次的なものであり、AJAX アーリー アダプターである必要がある場合でも同様です。他の人はしません。あなたが誰であるかを知り、それに応じて行動してください。

于 2009-05-24T17:48:56.290 に答える
1

Windows Azure の .NET サービス... 彼らはそれをキャンセルしました。

于 2010-01-09T05:42:07.063 に答える
1

Windows オープン サービス アーキテクチャ (WOSA): http://en.wikipedia.org/wiki/Windows_Open_Services_Architecture

ODBC、MAPI、TAPI などの基盤。

于 2010-01-08T03:18:03.120 に答える
0

Web プッシュ、J2EE CMP

于 2010-01-08T18:16:22.660 に答える
0

C++ ですが、採用したのは私ではありませんでした: 80 年代後半から 1990 年代初頭にかけて、C++ 開発者がほとんどいなかった頃、私はプロジェクトのフロント エンドを行う仕事に就きました。プロジェクトを担当するマネージャーは、バックエンドを行う契約プログラマーとして彼女の仲間を連れてきました。当時、私は一般的に C++ や OOP について何も知りませんでした。私たちが使用した UI パッケージは C++ を実行できませんでしたが、彼はそれを使用することを主張しました。その後、プログラマーとマネージャーの両方が長い間いなくなったときに、いくつかのバグが見つかりました。私は自分のコードでそれらを簡単に修正しましたが、多くのことはできませんでしたが、他の人の C++ コードのバグに肩をすくめました。当時の経営陣は私を訓練する代わりに、私にドアを見せてくれました。

于 2010-02-01T17:50:38.957 に答える
0

私は火傷しました：

  • こぶを乗り越える前はgcc、その後はMSVC++
  • 独自の Sun C++ コンパイラ
  • マイクロソフト開発者ネットワーク
于 2010-01-10T11:06:14.683 に答える
0

TurboGears Web フレームワーク

作成する Web アプリがあり、これに飛びつきました (友人から聞いたことがあります)。私は代替案を本当に知らず、MVC を適切に知らず、さまざまな「標準」コンポーネント (SQLObject の代わりに SQLAlchemy など) の代替案を認識していませんでした。プロジェクトのドキュメントと全体的な状態は、手を汚したときよりもはるかに優れていますが、最終的には、いくつかの魔法の機能をバイパスする「トリック」に依存し、ドキュメント化されていない機能が多数含まれる巨大なアプリケーションになりました。締め切りに間に合わせるために。それはメンテナンスの悪夢になりました。要件が変更された場合の書き換えの計画を立てて、時間をかけてより単純なものを構築することに時間を割いておけばよかったと心から思います。

これは 1.x シリーズでしたが、現在 Pylons ベースの 2.x シリーズでは廃止されています。ご想像のとおり、コア チーム自体が調査を決定しましたが、私は維持しなければならないレガシー アプリケーションに行き詰まっていました。

于 2010-01-07T18:38:13.827 に答える
0

さらに悪いのは、自分で開発した新しい/未熟なソフトウェアを会社に採用させる場合です。最初、私が唯一の開発者だったとき、私の気の利いた HTML GUI フレームワークは、RIA の構築に問題なく機能しました。しかし、開発者が増えると、強力なコミュニティが背後にある実証済みのプラットフォームを使用しない場合、開発者の生産性がどれほど低下するかがわかりました。このことと、HTML 4 が RIA にいかに不適切であるかを最終的に認識したという事実により、Adobe Flex 3 に切り替えました。この移行には非常に満足しています。

于 2010-01-09T20:09:30.720 に答える
0

iBatis。

私たちは、Hibernate がすでに行っている多くのことを実装することになります。本質的に、iBatis を使用して非標準の独自の内部 JPA プロバイダーを開発しました。テクノロジーはすでに選択されているため、できることはあまりありませんでした。

打撃を軽減するために、作業の重複を避けるためにコードをリファクタリングしました。

于 2010-01-08T18:30:37.640 に答える
0

私はモデル駆動型開発に非常に興味を持っていたので、学問的研究のために、無料でダウンロードできる Leonardi ソフトウェアを使用したことがあります。

このソフトウェアにしばらく取り組んだ後、ドキュメンテーションが不足していることに気付きました。また、まったくサポートされていません (無料のものはありません)。

非常に安価な作品を提供して、Leonardi でアプリを完成させなければなりませんでした。

ですから、十分な品質のドキュメントとサポートを手に入れることができると確信していない限り、新しいテクノロジを使用しないでください。

于 2010-01-07T12:14:26.383 に答える
0

WinDev .

これで手を火傷しなかったことは幸運でしたが、この製品はフランス（原産国）でかなり人気があり、他の人が手（および財布）を火傷しないように、ここで回答する価値があると思いますこの災害で。

  • デフォルトでフランス語の独自の言語「W-Language」がありますが、英語と中国語のバージョンも利用できます...わからない、プログラミング言語の複数のバージョンを持つことは良いようには見えませんアイデア、とにかく私に。

  • ほぼ毎年、IDE と言語の両方にバグ修正を加えた新しいバージョンの IDE をリリースしています。もちろん、これは有料のアップグレードですが、常にバグ修正を新機能として宣伝しているため、「919 個の新機能」を追加できます。彼らの広告。

  • 非常に貧弱なドキュメンテーション - 私は彼らのソフトウェアを購入していないので、付属のマニュアルを持っていない可能性があります - しかし、(好奇心のために) Web を検索してみましたが、チュートリアルはもちろん、多くのコード サンプルが見つかりませんでした。英語のドキュメントを見つけるのはさらに難しいと思います。

  • 彼らの広告とマーケティングは奇妙で性差別的です...自分の目で確かめてください（完全にNSFWではありませんが、誰かがあなたの画面を見た場合、あなた自身の責任でクリックしてください.

  • 彼らの製品について話しているフォーラム スレッドがあるかどうか (特に彼らが購入すべきかどうか) にかかわらず、突然、数人の「20 年の経験を持つプログラマー」が到着し、その製品が彼らの生活をどのように変え、彼らをより多くの人にしたかという長いメッセージを投稿します。生産性など...興味深いことに、これらの「プログラマー」は誰もフォーラムに参加したことはありません...ご想像のとおり、同社の広告/マーケティングチームはフォーラムにスパムを送信しています。

  • 彼ら自身のフォーラムに関しては、彼らはすべての否定的なレビュー/意見を検閲します.

  • また、Webdev と呼ばれる姉妹製品もあり、同じ W-Language を使用して Web サイトと Web アプリケーションを作成できます。これを使用して作成されたサイトの例を次に示します。ページのソースを見ると目が充血します。もちろん、上記のすべてがこの製品にも当てはまります。

于 2014-12-13T16:25:11.927 に答える
0

モンゴDB。私はそれを新製品の中核で使用しましたが、ディスクへの書き込みごとに同期しないことがわかりました。そのため、たとえばサーバーの電源が失われた場合、データが破損する可能性があります。

于 2010-01-08T19:02:56.187 に答える
0

これは、質問よりも議論に対処します。新しい技術を採用することによる費用対効果は当然だと考えていると思います。非常に大規模な企業の場合、テクノロジの変更には数億ドルの費用がかかる可能性があります。費用対効果がなければ、数億ドルを節約できます。ほとんどの企業は、テクノロジーを使用して何か他のものを作成しており、新しいテクノロジーが存在するという理由だけでそれを消費する余裕はありません。コストメリットがある場合は、そうすることは理にかなっています。

于 2010-01-04T22:35:48.023 に答える
-1

はい、チームの「テスト済みライブラリ」の他のプログラマーです。「それはあなたが必要とすることを正確に行います！」。そして、コードではなく実際のライブラリがクラッシュしているようです。そして、それは月に一度かそこらで起こります。

私たちのチームではTDDのスターターなので、それは普通かもしれませんが、とにかくたくさん燃えます:)

于 2010-01-07T11:56:26.327 に答える