Hackathon DevDays'19（パート2）：IntelliJ IDEAの電報および文法チェック用のサウンドメッセージパーサー

私たちは、春のハッカソンDevDaysのプロジェクトについて話し続けます。DevDaysでは、修士プログラム「ソフトウェア開発/ソフトウェアエンジニアリング」の学生が参加しました。



ところで、私たちは、読者をマジストラシーのVKグループに参加させたいと思っています。 その中で、募集と研究に関する最新ニュースを公開します。 Open Dayのビデオもグループにあります。 お知らせします：イベントは4月29日に開催されます 。詳細はサイトをご覧ください。

Telegram Desktop Voice Message Parser

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

チーム構成

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

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

DevDaysでのプロジェクトの目標は、受信した音声メッセージをTelegramデスクトップクライアント（以下、Telegram Desktop）のテキストに変換する機能を追加することでした。

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

前述のように、電報デスクトップには、軽量性と速度という2つの利点があります。 これは偶然ではありません。完全にC ++で書かれているからです。 また、新しい機能をクライアントに直接追加することにしたため、C ++で開発する必要がありました。

私たちのチームには4人がいました。 当初、2人は音声認識に適したライブラリを探していました。1人はTelegramデスクトップのソースコードを調査し、もう1人はTelegram Desktopプロジェクトのビルドを展開していました。 その後、誰もがUIの修正とデバッグに追われました。

意図した機能の実装は難しくないように見えましたが、いつものように、困難が生じました。

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

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

遭遇した2番目の問題は、C ++の欠点のいくつかに関連しています-中央リポジトリがない場合のさまざまなライブラリの動物園です。 Telegram Desktopが特定のバージョンの他の多くのライブラリに依存していることがたまたま起こりました。 公式リポジトリには、プロジェクトをビルドするための指示があります。 また、ビルドの問題に関する未解決の問題も多数あります（たとえば、 1回と2回） 。 すべての問題は、ビルドスクリプトがUbuntu 14.04用に記述されているという事実に関連していることが判明しました。Ubuntu18.04でテレグラムを正常にビルドするには、変更を加える必要がありました。

Telegram Desktop自体はかなり時間がかかります。IntelCore i5-7200Uを搭載したラップトップでは、すべての依存関係を含む完全なアセンブリ（-j 4フラグ）は約3時間かかります。 これらのうち、クライアント自体をリンクするには約30分かかりますが（後で、デバッグ構成ではリンクに約10分かかることが判明しました）、変更を行うたびにリンク手順を繰り返す必要があります。

問題にもかかわらず、Ubuntu 18.04のビルドスクリプトを更新するだけでなく、アイデアを実装することができました。 仕事のデモンストレーションはここで見ることができます 。 また、いくつかのアニメーションを適用します。 すべての音声メッセージの近くにボタンが表示され、メッセージをテキストに翻訳できます。 右クリックすると、オプションで翻訳に使用される言語を指定できます。 クライアントは、リンクからダウンロードできます。

リポジトリ。

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

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

アイデアの著者

戦車ヴラディスラフ

チーム構成

Tanks Vladislav（チームリード、LanguageToolおよびIntelliJ IDEAで作業）
Sokolov Nikita（LanguageToolの使用とUIの作成）
Hvorov Alexander（LanguageToolの使用とパフォーマンスの最適化）
Sadovnikov Alexander（マークアップ言語とコードの解析のサポート）

IntelliJ IDEAのプラグインを開発し、さまざまなテキスト（コメントとドキュメント、コード内のリテラル行、MarkdownまたはXMLマークアップでフォーマットされたテキスト）の文法、スペル、スタイルの忠実度（英語では校正と呼ばれます）をチェックします。

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

リンクをクリックすると、何が起こったかを見ることができます。

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

やる気

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

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

実装

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

プラグインコードはGitHubのリポジトリにあります 。 プロジェクト全体がKotlinで書かれ、UIにJavaが少し追加されました。 ハッカソン中に、マークダウン、JavaDoc、HTML、およびプレーンテキストのサポートを実装することができました。 ハッカソンの後、大きな更新により、XML、Javaの文字列リテラル、Kotlin、Python、およびスペルチェックのサポートが追加されました。

難しさ

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

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

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

ハッカソン後

ハッカソンは終了しましたが、プラグインの作業はより狭い構成で続行されました。 行、コメント、さらには変数名やクラス名などの言語構成要素までサポートしたかったのです。 現在、これはJava、Kotlin、Pythonでのみサポートされていますが、このリストが増えることを願っています。 多くの小さなバグを修正し、Ideaビルトインスペルチェッカーとの互換性を高めました。 さらに、XMLサポートとスペルチェックが登場しました。 これらはすべて、最近公開した2番目のバージョンにあります。

次は？

このようなプラグインは、開発者だけでなく、テクニカルライター（たとえば、IDEでXMLを使用することが多い）にとっても有用です。 毎日、自然言語を使用しなければならず、起こりうるエラーに関する編集者のヒントの形でアシスタントを用意する必要はありません。 プラグインはこのようなヒントを提供し、高度な精度で提供します。
プラグインは、新しい言語を追加し、テキスト検証を整理する一般的なアプローチを検討することで開発する予定です。 近い将来、スタイルプロファイルの実装（テキストのスタイルガイドを定義する一連のルール、たとえば「書かないで、完全なフォームを書く」）、辞書を拡張し、ユーザーインターフェイスを改善します（特に、ユーザーに単語を無視するだけでなく、彼を辞書に入れて、品詞を示します）。