Hackathon DevDays'19 (パート 2): IntelliJ IDEA での Telegram 用のオーディオ メッセージ パーサーと文法チェック

修士課程の学生が参加した春のハッカソンDevDaysのプロジェクトについて引き続き話します。 「ソフトウェア開発・ソフトウェアエンジニアリング」.

ところで、読者の皆様もぜひご参加ください VK修士課程学生グループ。 採用や勉強に関する最新ニュースを掲載していきます。 公開日のビデオもグループ内でご覧いただけます。 イベントは 29 月 XNUMX 日に開催されますので、詳細をお知らせします。 オンライン.

Telegram デスクトップ ボイス メッセージ パーサー

アイデアの作者
ホロシェフ・アルチョム

チーム構成

Khoroshev Artem – プロジェクト マネージャー/開発者/QA
Eliseev Anton – ビジネス アナリスト/マーケティング スペシャリスト
Maria Kuklina – UI デザイナー/開発者
Bakhvalov Pavel – UI デザイナー/開発者/QA

私たちの観点からすると、Telegram は現代的で便利なメッセンジャーであり、その PC バージョンは人気があり、オープンソースであるため、変更することが可能です。 クライアントは非常に豊富な機能を提供します。 標準のテキスト メッセージに加えて、音声通話、ビデオ メッセージ、音声メッセージが含まれます。 そして、受信者に不便をもたらすのは後者です。 コンピュータまたはラップトップを使用している間は、音声メッセージを聞くことができないことがよくあります。 周囲の騒音があったり、ヘッドフォンがなかったり、メッセージの内容を誰にも聞かれたくない場合があります。 スマートフォンで Telegram を使用すると、ラップトップや PC とは異なり、耳に当てるだけで済むため、このような問題はほとんど発生しません。 私たちはこの問題を解決しようとしました。

DevDays でのプロジェクトの目標は、受信した音声メッセージをテキストに翻訳する機能を Telegram デスクトップ クライアント (以下、Telegram デスクトップと呼びます) に追加することでした。

現時点での類似物はすべてボットであり、音声メッセージを送信し、応答としてテキストを受信できます。 私たちはこれにあまり満足していません: メッセージをボットに転送するのはあまり便利ではないため、ネイティブ機能が欲しいと思っています。 さらに、ボットは音声認識 API とユーザーの間の仲介者として機能するサードパーティであり、少なくとも安全ではありません。

前述したように、テレグラムデスクトップには、操作の容易さと速度という XNUMX つの大きな利点があります。 すべて C++ で書かれているので、これは偶然ではありません。 また、新しい機能をクライアントに直接追加することにしたため、C++ で開発する必要がありました。

私たちのチームには4人がいました。 当初、XNUMX 人が音声認識に適したライブラリを検索し、XNUMX 人が Telegram デスクトップのソース コードを研究し、もう XNUMX 人がビルド プロジェクトをデプロイしていました。 電卓デスクトップ。 その後、全員が UI の修正とデバッグに忙しくなりました。

意図した機能の実装は難しくないと思われましたが、いつものように困難が発生しました。

この問題の解決策は、適切な音声認識ツールの選択と、新しい機能のための UI の実装という XNUMX つの独立したサブタスクで構成されていました。

音声認識用のライブラリを選択するときは、言語モデルが多くのスペースを占有するため、すべてのオフライン API をすぐに放棄する必要がありました。 しかし、私たちが話しているのは XNUMX つの言語だけです。 オンライン API を使用する必要があることが明らかになりました。 その後、Google、Yandex、Microsoft などの巨人の音声認識サービスはまったく無料ではないことが判明し、試用期間で満足する必要があります。 その結果、サービスを使用するためのトークンを取得できる Google Speech-To-Text が選択されました。トークンは XNUMX 年間有効です。

私たちが遭遇した XNUMX 番目の問題は、C++ のいくつかの欠点に関連しています。つまり、集中リポジトリが存在しないため、さまざまなライブラリが大量に存在するということです。 たまたま、Telegram Desktop は他の多くのバージョン固有のライブラリに依存しています。 公式リポジトリには、 命令 プロジェクトを組み立てるために。 また、ビルドの問題に関する多数の未解決の問題もあります。たとえば、 時間 и два。 すべての問題は、ビルド スクリプトが Ubuntu 14.04 用に記述されているという事実に関連していることが判明しました。Ubuntu 18.04 でテレグラムを正常にビルドするには、変更を加える必要がありました。

Telegram Desktop 自体の組み立てにはかなりの時間がかかります。Intel Core i5-7200U を搭載したラップトップでは、すべての依存関係を含む完全な組み立て (フラグ -j 4) に約 30 時間かかります。 このうち、クライアント自体のリンクには約 10 分かかります (後で、デバッグ構成ではリンクに約 XNUMX 分かかることが判明しました) が、変更を加えるたびにリンク段階を繰り返す必要があります。

問題はあったものの、思いついたアイデアをなんとか実装し、アップデートすることができました。 ビルドスクリプト Ubuntu 18.04の場合。 作業のデモンストレーションは次の場所で見ることができます。 リンク。 いくつかのアニメーションも含まれています。 すべての音声メッセージの横にボタンが表示され、メッセージをテキストに翻訳できます。 右クリックすると、ブロードキャストに使用する言語を追加で指定できます。 による リンク クライアントをダウンロードできます。

リポジトリ。

私たちの意見では、これは多くのユーザーにとって便利な機能の優れた概念実証であることが判明しました。 Telegram Desktop の将来のリリースでこの機能が登場することを期待しています。

IntelliJ IDEA での拡張された自然言語サポート

アイデアの作者

タンコフ・ウラジスラフ

チーム構成

Tankov Vladislav (チームリーダー、LanguageTool と IntelliJ IDEA を使用)
Nikita Sokolov (LanguageTool の使用と UI の作成)
Khvorov Alexander (LanguageTool の使用とパフォーマンスの最適化)
Sadovnikov Alexander (マークアップ言語とコードの解析のサポート)

私たちは、さまざまなテキスト (コメントやドキュメント、コード内のリテラル行、Markdown または XML マークアップでフォーマットされたテキスト) の文法的、スペルおよび文体の正確さをチェックする (英語ではこれを校正と呼びます) IntelliJ IDEA 用のプラグインを開発しました。

プロジェクトのアイデアは、標準のスペルチェック IntelliJ IDEA を Grammarly の規模まで拡張し、IDE 内に Grammarly のようなものを作成することでした。

何が起こったかわかります リンク.

さて、以下では、プラグインの機能と、その作成中に発生した困難について詳しく説明します。

動機

自然言語でテキストを書くように設計された製品は数多くありますが、ドキュメントやコード コメントは開発環境で書かれることがほとんどです。 同時に、IDE はコード内のエラーを見つけるのには優れていますが、自然言語のテキストにはあまり適していません。 そのため、開発環境から指摘されることなく、文法、句読点、またはスタイルの間違いを非常に簡単に犯してしまいます。 ユーザー インターフェイスの作成時に間違いを犯すことが最も重要です。これは、コードの理解しやすさだけでなく、開発されたアプリケーションのユーザー自体にも影響を与えるからです。

最も人気があり開発されている開発環境の XNUMX つは、IntelliJ IDEA と IntelliJ プラットフォームに基づく IDE です。 IntelliJ プラットフォームにはすでにスペルチェッカーが組み込まれていますが、最も単純な文法エラーさえも取り除くことはできません。 私たちは、人気のある自然言語分析システムの XNUMX つを IntelliJ IDEA に統合することにしました。

具現化

私たちは独自のテキスト検証システムを作成するという目標を設定しなかったため、既存のソリューションを使用しました。 最も適切なオプションは次のとおりであることが判明しました LanguageTool。 このライセンスにより、私たちは目的のために自由に使用することができました。これは無料で、Java で書かれており、オープンソースです。 さらに、25 の言語をサポートしており、XNUMX 年以上開発されています。 LanguageTool はオープンであるにもかかわらず、有料のテキスト検証ソリューションに対する深刻な競合相手であり、ローカルで動作できるという事実が文字通りそのキラー機能です。

プラグインコードは次のとおりです GitHub 上のリポジトリ。 プロジェクト全体は Kotlin で書かれており、UI 用に Java が少し追加されています。 ハカソン中に、私たちは Markdown、JavaDoc、HTML、およびプレーン テキストのサポートを実装することができました。 ハカソンの後、メジャー アップデートで XML、Java、Kotlin、Python の文字列リテラル、およびスペル チェックのサポートが追加されました。

難しさ

毎回検査のためにすべてのテキストを LanguageTool にフィードすると、検査自体が UI フローをブロックするため、IDEA インターフェイスが多かれ少なかれ重大なテキストでフリーズすることにすぐに気づきました。 この問題は「ProgressManager.checkCancelled」チェックによって解決されました。IDEA が検査を中止する時期だと判断した場合、この関数は例外をスローします。

これによりフリーズは完全に解消されましたが、テキストの処理に非常に時間がかかるため、使用することはできません。 さらに、私たちの場合、ほとんどの場合、テキストのごく一部が変更されるため、何らかの方法で結果をキャッシュしたいと考えています。 まさにそれが私たちがやったことです。 毎回すべてをチェックしないように、テキストを決定的に分割し、変更された部分のみをチェックしました。 テキストは大きくなる可能性があり、キャッシュをロードしたくないため、テキスト自体ではなく、そのハッシュを保存しました。 これにより、プラグインは大きなファイルでもスムーズに動作できるようになりました。

LanguageTool は 25 を超える言語をサポートしていますが、2 人のユーザーがすべての言語を必要とすることは考えられません。 リクエストに応じて (UI でチェックを入れた場合) 特定の言語のライブラリをダウンロードする機会を与えたかったのです。 私たちもこれを実装しましたが、あまりにも複雑で信頼性が低いことが判明しました。 特に、別のクラスローダーを使用して、LanguageTool に新しい言語セットをロードし、慎重に初期化する必要がありました。 同時に、すべてのライブラリはユーザーの .mXNUMX リポジトリにあり、起動するたびにそれらの整合性をチェックする必要がありました。 最終的に、ユーザーがプラグインのサイズに問題を抱えている場合は、最も人気のあるいくつかの言語に対して別のプラグインを提供することにしました。

ハッカソン終了後

ハッカソンは終了しましたが、プラグインの作業は少数のチームで継続されました。 文字列、コメント、さらには変数名やクラス名などの言語構成要素もサポートしたいと考えていました。 現在、これは Java、Kotlin、Python でのみサポートされていますが、このリストが増えることを期待しています。 多くの小さなバグを修正し、Idea の組み込みスペルチェッカーとの互換性が向上しました。 さらに、XML サポートとスペルチェックが登場しました。 これらすべては、最近公開された第 XNUMX バージョンに記載されています。

次は何ですか？

このようなプラグインは、開発者だけでなく、テクニカル ライター (IDE で XML を扱うことが多い) にとっても役立ちます。 毎日、彼らは自然言語を使用して作業しなければなりません。アシスタントは、エラーの可能性について編集者のアドバイスを提供してくれるわけではありません。 私たちのプラグインはそのようなヒントを提供し、高い精度でそれを実行します。
新しい言語を追加することと、テキスト チェックを組織するための一般的なアプローチを検討することの両方によって、プラグインを開発する予定です。 私たちの当面の計画には、文体プロファイル (テキストのスタイル ガイドを定義するルールのセット、たとえば「例を書かず、完全な形式を書く」) の実装、辞書の拡張、ユーザー インターフェイスの改善 (特に、ユーザーに単語を無視するだけでなく、品詞を示して辞書に追加する機会を提供したいと考えています)。

出典: www.habr.com