サイトアイコン Embarcadero RAD Studio, Delphi, & C++Builder Blogs

世界随一のショウジョウバエ研究エンジンはDelphiで構築

Embarcadero Japan Support
smartmockups ldeokn81

小さいショウジョウバエが、生命の秘密を究明しようという研究者に人気があることをご存じでしょうか。この記事では、Delphi開発者のDavid Schwartz氏が、ローコードアプリケーション開発プラットフォームとして、Delphiが最高の選択肢であると確信している理由を語ってくれます。そして、そのDelphiプログラミング スキルを活用して開発した、「ショウジョウバエ研究のための Google™」と呼ばれるプロジェクトのエピソードを紹介します。

ソフトウェア開発のバックグラウンド

1979年6月、アリゾナ州立大学で数学・コンピュータサイエンスの学士号を取得してから、私は、ほぼすべてのキャリアにわたってソフトウェア開発に従事してきました。

80年代中頃には、「オブジェクト指向プログラミング（OOP）」と呼ばれる新しいプログラミング技術が登場し、「C++」というC言語をベースとした新しい言語によって、OOPがサポートされました。好奇心が強い私は、OOPとC++の学習を開始し、その両方について、かなり習熟することができました。実際、私は全国の多くのクラスで教鞭をとっていたのです。

90年代には、自身のコンサルティングファームを立ち上げました。主に、ソフトウェアによって夢を現実にしたいと考えていた人たちと仕事をすることが多く、彼らの頭の中のアイデアを「現実の世界」で実現するために働いていました。

依存するものを構築することを夢見ていて、そのアイデアを頭から追い出し、「現実の世界」で実現するために私を雇った人々と仕事をしました。とても楽しい日々でした。主な仕事は、車、テレビ、電子レンジなどを制御するコンピューターといった、いわゆる「組み込みシステム」の開発でした。

この間、マイクロソフトは、Windowsという手の込んだ「グラフィカル ユーザー インターフェイス（GUI）」プラットフォームを導入しましたが、そのプログラミングは壊滅的に複雑でした。多くの同僚が仕事を畳むのを目撃してきましたが、それは、マイクロソフトのツールが多くのコストと時間を消費するわりに、最小限の収益しか得られないことに起因していました。大企業ではうまくいったかもしれませんが、個人事業主はそうはいきません。そのため、私は厄介なWindowsプログラミングを回避することにしたのです。

アプリケーション開発に RAD Studio / Delphi を選択した理由

1995年2月、私はカリフォルニア州モントレーで開催された「Software Developer’s Conference」というイベントに参加しました。その週の2月14 日はバレンタインデーでしたが、同日、Borland Internationalは、「Delphi」というWindows向けソフトウェアアプリケーション開発するためのまったく新しいアプローチを発表したのです。聴衆のひとりだった私は、完全に圧倒されました。そのとき印象的だったのは、以下の4点です。

  1. 「Windowsイベントループ」と呼ばれるしくみをDelphiがいかに完全に隠蔽したか。Windows向けのコードを記述する際に、最悪と思える部分のひとつが、このイベントループです。もうそれは悪夢でしかなく、開発者達からは軽蔑されていました。それをDelphiは魔法のように完全に消し去ったのです。すごっ！
  2. DelphiのGUIベースのフォームデザイナを使用すれば、実行時とほぼ同じ外観のグラフィカルフォームを簡単に作成することができます。これは、「WYSIWYG（What You See Is What You Get）」設計アプローチと呼ばれていました。それまでも、近いツールはありましたが、Windows用ではありませんでした。また、とても高価だったので、大企業でない限り手の届くツールではありませんでした。
  3. このWYSIWYGマジックを実現していたのは、コンポーネントパレットから選択してフォーム上にドロップできる一連の「コンポーネント」でした。配置したコンポーネントは、「Property Inspector」を使ってその設定を微調整し、コードを1行も書くことなく、文字通り便利な（単純ではあるものの）Windows プログラムを作成できたのです。
  4. おそらく最も素晴らしい点は、これらの「コンポーネント」自体を、Delphiによって記述できることです。VBやその他のほぼ同様のプラットフォームで要求されるように、機能拡張のためにまったく異なる言語や環境を使う必要がまったくないのです。Delphiは、それ自体を拡張するために使用できるのです。

そして、すばらしかったのは、参加者全員に無料で試せるフリー版を提供してくれたことです。このイベントが、私のプロとしてのキャリアの方向性を変えたと言っても過言ではないでしょう。なぜなら、数年のうちに、私の仕事のほぼすべてがDelphiプログラミングから生まれていたからです。以来、Delphiが私のプロとしての活動の中心的存在となったのです。

1995年当時、これらの機能は非常に驚くべきものでしたが、それ以降作成されたすべてのプログラミングプラットフォームでも、こうした機能が期待されていたのです。マイクロソフトは、 Turbo Pascalの作者であり、Delphiチーフ アーキテクトを務めていたAnders Hejlsbergをスカウトし、その後のすべてのプログラミング言語に関する作業を指揮させるほど畏敬の念を抱いていたと言えます。Andersは、新しい言語（C#）と開発プラットフォーム（Visual Studio）の設計を支援しています。今日でも、DelphiとVisual Studioは非常によく似たIDEです。一方をマスターしていれば、もう一方の使用も問題ないでしょう。

最近の開発プロジェクト

それから、Delphiベースのさまざまなプロジェクトに取り組んできました。ほとんどは、Delphiを使用して作成された大規模なエンタープライズアプリケーションの保守が主な仕事でした。2023年の現在でも、大量のレガシーアプリケーションが存在し、多くの企業が数十億ドルとまではいかないものの、数百万ドルの利益を上げています。どうしてなのかと疑問に思う人もいるかもしれません。

私の考えでは、これには2つの理由があると思います。(1) それらのほとんどは堅牢なアプリケーションであり、メンテナンスの必要がほぼないということです。(2) もうひとつは、結局のところリプレースを行うにはコストがかかりすぎるということです。あるシステムの開発チームが、私はいくつかの非常に大規模なDelphiベースのアプリケーションを別のプラットフォームに置き換える作業を進めている間に、私はそのDelphiアプリケーションのメンテナンスを行う業務を請け負いました。ところが、そうしたリプレースプロジェクトが無事完了したことを、私は見たことがありません。実際、予算とスケジュールは、大幅に超過してしまっていたのです。

私はしばしば、Delphiベースのアプリケーションから何百万ドル～何億ドルといった利益を生み出すビジネスを運営している企業幹部から、Delphiがほとんど尊敬されていないことに疑問を持ち、頭を悩ませてきました。それどころか、（完全にデバッグされ安定して動作する）既存のDelphiコードの恩恵をまったく受けることのない、完全に異なる言語とプラットフォームで記述されたものに置き換えることに執心しているのです。私が従事したいくつかの企業では、バグ修正のためにコード修正を行うことすら望まないくらい、既存コードに手を加えることを快く思わない経営陣がいたほどです。

他の開発ソリューションではなく、RAD Studio / Delphiを選び続ける理由

この一連の記事の目的は、現在においても、Delphiが次に実施するプロジェクトにとって優れたプラットフォームである理由を示すことだと考えます。他のソリューションではなく、Delphiを検討するべき理由は何でしょうか？Delphiが他の選択肢と比較して優れている5つの分野について、私の考えを述べましょう。

RAD Studio / Delphiを推奨する最初の理由

まず、DelphiがPascal言語をベースとしている点です。Pascalはもともと、プログラミングを学ぶ学生向けの教育用言語として開発されました。シンプルかつ論理的で、可読性にすぐれ記述も容易です。最も重要なことは、その習得が簡単であることです。DelphiはOOPに対応するように拡張されており、それはObject Pascalと呼ばれています。この言語のセマンティクスは、C++のセマンティクスとほぼ完全に重複していますが、最も注目すべき相違点は、Object Pascalが多重継承をサポートしていないことです。

C++とDelphiのもう1つの小さいながらも重要な相違は、 Delphi のすべての「オブジェクト（クラスのインスタンスなど）」が、暗黙的に参照渡しされることです。つまり、いずれの場合でも（明示的な型キャストでクラス型の制約を破壊する）Pointer型を使用する必要は、ほぼないということです。

昔、嫌いな言語というと、誰でも「C」、そして「C++」を挙げました。なぜでしょうか？おそらく「簡潔すぎるから」と言うのではないでしょうか。90年代はそうだったかもしれませんが、現在ではちょっと状況が違います。私は長い間 C++を使っていませんでしたが、最近C++20のいくつかのコードをぱっと見たところ、どれだけの粗雑さが加えられているかを目の当たりにし、ちょっと悲しくなりました。現在のC++からすれば、DelphiのObject Pascalははるかに単純で、冗長ではなく見えるのです。ただ、どちらも「簡潔」というわけではありませんが w。

RAD Studio / Delphiを推奨する2つ目の理由

第二に、人々が気付いていないことなのですが、多くの人が信じているように、Delphiの Object Pascalはまったく時代遅れではないという点です。Delphiは、手続き型プログラミングと関数型プログラミングの両方をサポートしています。実際、Delphi のオブジェクトはすべて、これらのユースケースの両方でファーストオブジェクトと見なされます。ファーストクラスオブジェクトは、以下をサポートします。

Delphi で関数型プログラミング式を記述するための構文は少し冗長ですが、ファーストクラスオブジェクトをサポートする他の関数型プログラミング言語で実行できることはすべて、Delphiでも実行できます。ジェネリクスもサポートしており、優れたジェネリクスライブラリがいくつか存在します。

RAD Studio / Delphiを推奨する3つ目の理由

3つ目のポイントは、ボーランド、そしてその後のエンバカデロが何年にもわたってこだわり続けていた点で、Delphiの新バージョンでは、常にそれ以前のバージョンとの下位互換性を維持すること保証するという暗黙の要件があることです。初期のリリースでコンパイルされた古いDelphiアプリケーションを、ほとんど労力をかけずに新バージョンで実行することができるのです。

時間の経過とともに、この取り組みには2つの顕著な問題が生じてきました。一般的に、古いプロジェクトをアップグレードする妨げとなる最大の障害は、Delphi 2009で発生したUnicode文字列への切り替えに起因します。もうひとつは、実行時型情報（RTTI）のサポート強化、コンポーネントにより柔軟性を持たせるための変更、ジェネリクスのサポートなどのための内部的な変更に起因するものです。その結果、一部の汎用コンポーネントライブラリのアップグレードが困難になったり、コストがかかりすぎるという事態も発生しました。

RAD Studio / Delphiを推奨する4つ目の理由

4つ目のポイントは、ほとんどの開発者が意識していないことです。それは、Delphiを使用すれば、今日市場に出回っているほぼすべてのランタイムプラットフォーム用のネイティブアプリケーションを作成できるという点です。

つまり、すべての開発ニーズに対して、1つの言語と1つの開発プラットフォームを使用できるのです。現在、こうした開発ニーズに対するには、最大で6つの異なる開発スキルとツールセットの組み合わせを扱うため、複数の開発者を雇わなければならないのですが、Delphiならそれだけで済むのです。

サードパーティコンポーネントの使用

こうしたマルチプラットフォームサポート機能のほとんどは、ここ10年間で（Delphi XE2以降）Delphiの内部で着実な進化を遂げてきました。その一方で、サードパーティベンダーであるTMS Softwareでは、Web Coreと呼ばれる拡張機能の開発に注力してきました。Web Coreは、Delphi IDE内でアプリケーションを作成、コンパイルすることで、最新のWebブラウザで実行可能なアプリケーションを構築できます。さらに、デバッグすることも可能です。これは実際に見ると、素晴らしい機能です。Windowsアプリケーションを作成するのとまったく同じようにDelphiコードを記述すると、そのコードはJavaScriptにトランスパイルされ、単純なHTML ファイル内に埋め込む方法でパッケージ化されます。DelphiコードがWebアプリケーションの非同期性を簡単に処理できるように、トランスパイラをわずかに強化しています。まさに天才的です。

TMS WEB Coreのを使い始めるのに、私はかなり単純だけれどもそう簡単ではないようなアプリを、約1時間かけて作成してみました。数か月後、さらに1時間かけて、いくつかの機能追加を行いました。そのアプリは、こちらで確認できます。

https://bestkeywordmixer.com

TMSはさらに、FNC Components Libraryと呼ばれる完全にクロスプラットフォームの単一コンポーネントライブラリを進化させてきました。これにより、Delphiがサポートするすべてのプラットフォーム（WEB Coreを含む）で、同等あるいは極めて類似したフォームで、同じコンポーネントを使用できるようになりました。従来は、プラットフォームごとに異なるコンポーネントライブラリを使用する必要があったのです。

FNCコンポーネントを使用したDelphiアプリの一例

こちらは、私が最近開発したDelphiアプリのスナップショットです。これは、Text-to-Speechリクエストを処理するAPIを提供するサードパーティーサイトにアクセスするアプリです。はじめに、RESTリクエストを発行し、音声リストをロードします。ここでは、英語音声の全リストをロードしています。これらをダブルクリックすることで、選択した音声オプションとともに短文がホストサーバーに送信され、MP3ファイルが返されます。このファイルは、オーディオプレーヤーに読み込まれ、その声を聴くことができます。アプリのアイデアは、好きな声を選ぶことができるというものです。オーディオプレーヤーコンポーネントとその右側のトラックバーは、いずれもFNCコンポーネントライブラリのものです。実際、これは Win32アプリですが、オーディオプレーヤーコンポーネントは、内部で一連のJavaScriptを使用して実装されています。これをWEB Coreアプリに変換した場合でも、これらのコンポーネントはまったく同じように機能するのです。

RAD Studio / Delphiを推奨する5つ目の理由「開発スピード」

5番目の理由は、おそらく最も重要なメリットになるのですが、Delphiが、プロトタイピングとコード開発の両方において、現在入手可能な最速かつ最も簡単な開発プラットフォームであると考えられることです。

まずはじめに触れておきたいのは、アプリの構築以外にも、ワイヤーフレーム設計や単純なプロトタイプ作成の両方をDelphiで行うほか、POCや機能プロトタイプの両方をDelphiで行っているという点です。実際、Delphiの価格とほぼ同じである、かなり洗練されたワイヤーフレームモデリングツールを見たことがありますが、正直なところ、それは実際には機能しないモデルを構築することしかできません。Delphiの価格について不満を漏らしている人がいますが、ワイヤーフレームだけでなく、プロトタイプやPOC、そして実際のアプリを構築できるDelphiは、同じ箱に複数のツールが入っているようなものだと考えるべきでしょう。

アプリケーション構築において、Delphiがいかに生産性向上に寄与したかについては、いくつかのストーリーがあります。しかし、そのほとんどは、請負元との機密保持契約のため、ここでは紹介することができません。ただ、FlyBaseの誕生に関するストーリーは、私も気に入っており、皆さんにもお話しできる内容です。

ショウジョウバエの胚研究のグローバルデータベースでDelphiが活躍

私は、2000年から2004年までの間、ASUのバイオデザイン研究所で、MEGA [4] と呼ばれるアプリケーションのサポートに従事していました。MEGAは、当時、遺伝学およびゲノミクスの教授であったSudhir Kumar博士 [3] によって開発されました。私は、彼の研究室で遺伝学と比較ゲノミクスの博士号取得に取り組んでいる多くの大学院生と一緒に働いていました。彼はDelphiを使用してMEGAを作成し、その保守と拡張をサポートするべく、私を招いてくれたのです。

（実際、私はこの分野についてはまったくの門外漢だったので、彼に「なぜ私を雇ったのですか?」と尋ねたところ、「まあ、私の経験では、生物学者にプログラミングを教えるよりも、プログラマーに遺伝学を教える方がはるかに簡単なんですよ。」と言われました。確かにそこで働いている間、私は遺伝学とゲノミクスについて多くのことを学んだのですが、退職後にはそのほとんどをすぐに忘れてしまいました。）

2002年秋に、Kumar博士は「かなり複雑な作業」を簡素化するためのツールの作成を私に依頼しました。彼はプロセスの全体像を教えてくれました。

Kumar博士は、世界中の遺伝学とゲノミクスの研究者が一般的に使用するデータを保存するデータベースの構築というアイデアを思いついたのです。彼はそれを「Drosophila Image Acquisition Utility（ショウジョウバエ画像取得ユーティリティ）」と命名（下図参照）し、研究者が一般的なショウジョウバエに関する遺伝子研究の詳細をできるだけ多く一箇所に集約できるようにすることを目的としたのです（ショウジョウバエは、生物学者や遺伝学の研究者によって、数世代にわたる進化の遺伝的傾向を研究するために何十年も使用されてきました。ショウジョウバエは、約48時間以内のサイクルで誕生、生存、繁殖、死を迎えるため、数週間で多くの世代を研究することができるのです）。

ショウジョウバエ画像取得ユーティリティの詳細

実際のアプリケーションの詳細機能については、あまり覚えていないので詳しくは説明しません。そのかわりに、与えられた一般的な要件についてリストしましょう。この記事を読まれている方の多くは、その要件から同じような選択肢を想起できることと思います。そして、Kumar博士が段階的なアプローチでプロジェクトを立ち上げ、プロジェクト資金を獲得することができたという点も分かるでしょう。その成果は、いまなお役立っており、世界中の研究者によって定期的に利用されています。

私が関わった最初のステップは、Delphiを用いって行われたものです。Delphiの驚異的な生産性、そして私が作成した最初のアプリの生産性も、Kumar博士の予想を上回るものでした。

Kumar博士のビジョンは、世界中の研究者が使用できる巨大なデータベースを構築し、ショウジョウバエの胚研究に関連するあらゆる種類の詳細情報を、可能な限り遡って相互参照できるようにすることでした。このデータベースにアクセスできないと、研究者は、自分の研究に関連する詳細情報を見つけるのに、膨大な時間と労力がかかる上に、包括的な結果を得ることができません。Google™は、この種のタスクがあまり得意ではないのです。そこで、「ショウジョウバエ研究のための Google™」になることがゴールになったのです。😃

このエンタープライズアプリ作成に使用した設計プロセス

Kumar博士は、ショウジョウバエに言及している過去10年間に発表された10,000の論文リストを特定しました。それらには、胚の画像と、それらの画像と関連する研究で発見されたさまざまな識別機能が含まれていました（これらの画像は通常、さまざまな詳細情報を引き出すために、いくつもの波長の光のもとで染色されています）。

以下は、自動化を依頼された手動プロセス (「要件仕様」) です。

この一連のプロセスを手動で実行する場合、各ステップでは、その処理に異なるプログラムを使用しなければなりませんでした。Kumar博士は、このタスクの概要（上記リスト） を手渡して、それぞれの手順を説明し、私に言いました。「この手順を自動化するのにDelphiで何ができるか確認してください。2週間あげましょう。」

難しい作業のようだったが…

個人的には、こういったチャレンジは大好きです。私は、すべてを自動化するのためにどうすればよいかを無我夢中で考え、その作業に没頭しました。ある画面から次の画面に移動する「ウィザード」のような構造のアプリを構築し、各画面でそれぞれのステップを実行できるようにしました。ユーザーは、ステップ間でプログラムを離れる必要がなくなりました。さらに、1つの論文で1つないしは2つのステップを実行してから、次の論文に進むように構成しました。不完全な論文に戻ったときでも、必要とする次のウィザードステップに進むことができます。オプションフラグを設定することも可能にしました。例えば、「ステップ3の処理で必要な書類のみを受け取る」などといった設定です。これにより、コンテキストを切り替えることなく、同じ処理を繰り返しすことができるようになりました。これらの機能は、すべてのアカウントで非常にうまく機能しました。

手始めに、10,000件の論文とそのURLの全リストをデータベースに登録する作業から始めました。ボタンをクリックして開始すると、DBのリストから論文が取得され、作業の開始となります。論文の登録は、一度に1人が1件ずつ取り掛かりました。

まず、論文がAdob​​e Acrobatに表示されるので、ざっと目を通すことができます。次に、見つけた画像をマウスで選択し、ボタンをクリックしてキャプチャします。画面が変わり、画像の他の詳細キャプチャを完了させます。

例えば、ウィザードの次ページでは、画像の正規化、反転、回転、トリミングを行い、特定箇所を強調できます。必要に応じて、すべてをオーバーライドすることもできます。次に、他の研究者が検索して保存するかもしれない研究に関連する論文で指摘された特徴をポイントします。その後、元に戻って、論文内の別の画像を処理します。そして、いつでもリスト内の別の論文に進むことができます。

使用したいくつかの外部プログラムについては、そのソースコードを入手して、（直接またはDLLとして）アプリに組み込むことができました。それ以外の場合は、DOSコマンドシェルからチャイルドタスクとして単純に実行させました。

RAD Studioで使用したデータベース技術

各画像のすべてのデータは、親レコードとして検出される論文に関連付けられた子レコードとしてMySQLデータベースに保存されます。この結果、研究者達は、グローバル研究カタログ全体を、画像の特徴、研究者、日付などといった情報をもとに検索することができるようになりました。彼らは、それが非常に便利だとすぐに気付いたのです。

Kumar博士は、どのような要素を用いて見積りを作成したかのかは教えてくれませんでしたが、彼は6人のインターンを雇って6週間ほど0.5時間働いてもらい、期間内に10,000冊の論文すべてをカタログ化できるように、タスクの自動化を進めてほしいと期待していたと思います。私が彼らの仕事をどれだけ簡単にしたかは、計り知れません。

成功したプロジェクト

端的に言えば、私のDelphiアプリのおかげで、彼らはわずか2週間で10,000冊の論文すべてをカタログ化できました。作業を開始してから3週目に入った月曜日、私が研究室にいたときに、インターン全員が昼食後にやってきました。Kumar博士が入ってきても、彼らはただそこに突っ立っていました。「さあ、仕事に取り掛かろう」そうKumar博士が声をかけたところ、ひとりのインターンが「博士、私たちの仕事は全部終わってしまいましたよ」と言ったのです。ほかのインターンもうなずいていました。「え？10,000冊の論文すべて？」と尋ねるKumar博士に、インターンはうなずきます。「どれ、見てみましょう」。博士は、オフィスのコンピューターの前に座り、データベースクエリーを実行し始めました。確かに、彼らの仕事は完了していたのです。

インターンは、雇用期間である6週間のうち2週間しか給料をもらえなかったので、かなり不満だったと思います。そして、それはKumar博士にとっても問題を引き起こしたのではないでしょうか。というのは、研究助成金として必要な金額を過大評価してしまい、使い切らないというのは、資金提供機関が好まないからです。ちょっとやりすぎてしまったようです w。

要するに、Kumar博士は、研究助成金の提案をまとめるのに役立つ使い捨てツールになるはずのプログラムで、誰かがこれほど多くの仕事を驚くほど迅速に成し遂げられるとは想像だにしていなかったのだと思います。2週間の作業で達成できたことに、私自身も驚きました。その「成功」の一部は、私自身のアーキテクチャスキルとプログラミングスキルに関係するものではありましたが、そのほとんどは、Delphiがいかに使いやすく、生産性が高いかに起因するものだったのです。

RAD Studio / Delphiによるアプリ構築は高い生産性を実現

Delphiの「高い生産性」という側面が、他の状況でも問題を引き起こしたことは注目に値します。私は、クライアント用のプロトタイプ作成で、「ほとんど完成した」と錯覚するほと「リアル」な外観と動作を伴うプロトタイプアプリを作成したことがあります。クライアントが見たのは、ハリウッドが映画のセットに使用するものに似ていました。壁の裏やボンネットの下には何もありません。彼らをだまそうとしていたのなら、成功だったでしょう。しかし、実際には、より多くの開発時間をかける必要があり、そのためのクライアントとの交渉がむしろ困難になってしまったのです。私は自分のプロトタイプを「本物」とはかけ離れたものにしなければならないこと、そして時にはうまく動かない結果 (「偽のバグ」) を返すようにしておき、もっと作業が必要であると理解してもらうべきであるということを学びました。

時間の経過とともにこの状況は変わったか

さて、これらのエピソードについて、あなたは「それは20年前の、はるか昔のバージョンのDelphiのことですよね」と言うかもしれません。はい、その通りなのですが、最新バージョンのDelphiを用いれば、さらに30%～50%作業時間を短縮できるでしょう。その理由は、今日のコンピュータがはるかに高速になっていること、そして、フォームにドロップしてプロパティを設定するだけで利用できる大​​量のロジックが組み込まれたDelphi向けコンポーネント／ライブラリが、より多くあるからです。

そして現在では、 TMS WEB Coreテクノロジーを利用して、Web上で動作し、世界中の誰もがすぐにアクセスできるアプリを構築することも可能なのです。

私が言えることは、彼らがそのデータを投入したデータベースが、Kumar博士の同僚の何人かが使用するようになり、彼らもそれが非常に役立つものだと認識したということだけです。このバージョンは少し進化したもので、FlyBase [5] と呼ばれていたと思います。彼はこれらの結果を使用して、MySQLの代わりにOracle DB を使用するFlyExpress [6] と呼ばれるはるかに大規模なデータベースを作成する、より大規模な助成金事業提案書を、NIHに提出することができたのです。私が作成したFlyBaseアプリはより多くの研究者に幅広く配布され、多くの既存の研究出版物が日々投入されています。今日、両者とも健在で、世界のゲノミクス研究コミュニティで、極めて効果的な貢献を果たしているようです。

私が従事したMEGA [4] アプリは現在も使用されており、世界中の遺伝学およびゲノミクス研究者が使用する最も広く引用されているツールの1つになっています（まだ Delphiで記述されているかどうかは不明ですが、Windows、macOS、Linuxでサポートされており、いくつかのWebコンポーネントも含まれていることを発見しています）。

Kumar博士 [3] は現在、ペンシルベニア州フィラデルフィアのテンプル大学で自分の研究室を率いており、比較ゲノミクスの分野で教鞭をとり、その研究をリードし続けています。

一方の私は、現在セミリタイアして、自身のWebアプリ開発に取り組んでいます。Delphi、WEB Core、そして、その他のTMSテクノロジを使用していろいろ構築しており、世界的な成功を収めることも目論んでいるところです。☺️

参考文献

  1. Anders Hejlsberg (Delphi’s original architect): https://en.wikipedia.org/wiki/Anders_Hejlsberg
  2. Best Keyword Mixer (example WEB Core app I built in Delphi in less than an hour): https://bestkeywordmixer.com
  3. Dr. Sudhir Kumar: https://kumarlab.net/home
  4. MEGA: https://www.megasoftware.net/
  5. FlyBase: http://flybase.org/
  6. FlyExpress: http://www.flyexpress.net/
  7. TMS Software: https://www.tmssoftware.com/site/default.asp?s=home
  8. TMS WEB Core: https://www.tmssoftware.com/site/tmswebcoreintro.asp
  9. TMS FNC Components Library: https://www.tmssoftware.com/site/fnc-products.asp

この記事は、Enterprise Article Showcaseへ投稿されたものです。RAD Studio、Delphi、C++Builderと関連技術を用いて構築した開発プロジェクトの成功事例をお持ちの方は、ぜひご連絡ください。詳細はこちらをご覧ください。

モバイルバージョンを終了