我們繼續聊一下碩士生參加的春季黑客馬拉松DevDays的項目 .
順便說一句，我們想邀請讀者加入 。 我們將在其中發布有關招聘和學習的最新消息。 群組還可以找到開放日的影片。 提醒您：活動將於29月XNUMX日舉行，詳情 .
Telegram 桌上語音訊息解析器
創意作者
霍羅舍夫·阿爾喬姆
團隊組成
Khoroshev Artem – 專案經理/開發人員/品質保證
Eliseev Anton – 業務分析師/行銷專家
Maria Kuklina – UI 設計師/開發人員
Bakhvalov Pavel – UI 設計師/開發人員/QA
從我們的角度來看，Telegram 是一種現代且方便的通訊工具，其 PC 版本很流行且開源，這使得對其進行修改成為可能。 客戶端提供了相當豐富的功能。 除標準簡訊外，還包含語音通話、視訊訊息、語音訊息。 而後者有時會給收件人帶來不便。 在電腦或筆記型電腦前通常無法收聽語音訊息。 可能有環境噪音、沒有耳機，或是您不希望任何人聽到訊息的內容。 如果您在智慧型手機上使用 Telegram，此類問題幾乎不會出現，因為與筆記型電腦或 PC 不同，您只需將其放在耳邊即可。 我們試圖解決這個問題。
我們在 DevDays 專案的目標是為 Telegram 桌面用戶端（以下簡稱 Telegram Desktop）新增將收到的語音訊息翻譯為文字的功能。
目前所有的類似物都是機器人，您可以向其發送音訊訊息並接收文字回應。 我們對此不太滿意：將訊息轉發給機器人不太方便；我們希望擁有本機功能。 此外，任何機器人都是充當語音辨識 API 和使用者之間中介的第三方，這至少是不安全的。
如前所述，telegram-desktop 有兩個顯著的優點：操作簡單和速度快。 這並非巧合，因為它完全是用 C++ 寫的。 由於我們決定直接在客戶端新增功能，因此我們必須使用 C++ 進行開發。
我們團隊有4個人。 最初，兩個人在尋找合適的語音識別庫，一個人在研究 Telegram-desktop 的源代碼，另一個人在部署構建項目 。 後來大家就忙著修復UI、調試。
看起來實現預期的功能並不困難，但是，就像往常一樣，困難出現了。
這個問題的解決方案包括兩個獨立的子任務：選擇合適的語音辨識工具和實現新功能的 UI。
當選擇用於語音辨識的函式庫時，我們立即不得不放棄所有離線API，因為語言模型佔用了大量空間。 但我們只談論一種語言。 很明顯，我們必須使用線上 API。 後來發現，Google、Yandex、微軟等巨頭的語音辨識服務根本不是免費的，我們只能滿足於試用期。 因此，我們選擇了 Google Speech-To-Text，因為它允許您獲得使用該服務的令牌，該令牌將持續一整年。
我們遇到的第二個問題與 C++ 的一些缺點有關——在缺乏集中儲存庫的情況下，各種庫的動物園。 碰巧 Telegram Desktop 依賴許多其他特定於版本的函式庫。 官方倉庫有 用於組裝項目。 還有大量關於建置問題的未決問題，例如 и 。 所有問題都與建置腳本是為 Ubuntu 14.04 編寫的事實有關，為了在 Ubuntu 18.04 下成功建置 telegram，必須進行更改。
Telegram Desktop 本身需要相當長的時間來組裝：在配備 Intel Core i5-7200U 的筆記型電腦上，包含所有依賴項的完整組裝（標誌 -j 4）大約需要三個小時。 其中，連結客戶端本身大約需要30分鐘（後來發現在Debug配置中，連結大約需要10分鐘），但每次更改後都必須重複連結階段。
儘管存在問題，我們還是設法實現了設想的想法並進行了更新 適用於 Ubuntu 18.04。 作品的演示可見於 。 我們還包括一些動畫。 所有語音訊息旁邊都會出現一個按鈕，讓您可以將訊息翻譯成文字。 透過右鍵單擊，您還可以指定用於廣播的語言。 經過 客戶端可供下載。
我們認為，它是一個很好的功能概念證明，對許多用戶來說很方便。 我們希望在 Telegram Desktop 的未來版本中看到它。
IntelliJ IDEA 中增強的自然語言支持
創意作者
坦科夫·弗拉迪斯拉夫
團隊組成
Tankov Vladislav（團隊負責人，使用 LanguageTool 和 IntelliJ IDEA）
Nikita Sokolov（使用 LanguageTool 並建立 UI）
Khvorov Alexander（使用 LanguageTool 並優化效能）
Sadovnikov Alexander（支援解析標記語言和程式碼）
我們為IntelliJ IDEA 開發了一個插件，用於檢查各種文字（註解和文件、程式碼中的文字行、Markdown 或XML 標記格式的文字）的語法、拼字和風格準確性（英文中這稱為校對） 。
這個專案的想法是將標準拼字檢查 IntelliJ IDEA 擴展到 Grammarly 的規模，在 IDE 中製作一種 Grammarly。
你可以看到發生了什麼 .
那麼，下面我們將更詳細地討論該插件的功能，以及在創建過程中遇到的困難。
動機
有許多產品專為用自然語言編寫文字而設計，但文件和程式碼註釋最常在開發環境中編寫。 同時，IDE 在查找程式碼中的錯誤方面做得非常出色，但不太適合自然語言的文字。 這使得很容易在語法、標點符號或風格上犯錯，而開發環境卻沒有指出這些錯誤。 在編寫使用者介面時犯錯是最關鍵的，因為這不僅會影響程式碼的可理解性，還會影響所開發應用程式的使用者本身。
最受歡迎和開發的開發環境之一是 IntelliJ IDEA 以及基於 IntelliJ 平台的 IDE。 IntelliJ Platform 已經有一個內建的拼字檢查器，但它甚至無法消除最簡單的語法錯誤。 我們決定將一種流行的自然語言分析系統整合到 IntelliJ IDEA 中。
履行
我們沒有為自己設定創建自己的文字驗證系統的任務，因此我們使用了現有的解決方案。 最適合的選擇是 。 該許可證允許我們自由地將其用於我們的目的：它是免費的，用 Java 編寫且開源。 此外，它支援25種語言，並且已經開發了超過十五年。 儘管具有開放性，LanguageTool 仍然是付費文字驗證解決方案的有力競爭對手，而且它可以在本地工作這一事實實際上是它的殺手鐧。
插件程式碼位於 。 整個專案是用 Kotlin 編寫的，並為 UI 添加了少量 Java。 在黑客馬拉松期間，我們成功實現了對 Markdown、JavaDoc、HTML 和純文字的支援。 黑客馬拉松之後，一項重大更新添加了對 XML、Java、Kotlin 和 Python 中的字串文字以及拼字檢查的支援。
困難
很快我們就意識到，如果我們每次都將所有文本提供給 LanguageTool 進行檢查，那麼 IDEA 介面將凍結任何或多或少嚴重的文本，因為檢查本身會阻塞 UI 流程。 該問題是透過「ProgressManager.checkCancelled」檢查解決的 - 如果 IDEA 認為是時候中止檢查，則該函數會拋出異常。
這完全消除了凍結，但無法使用：文字需要很長時間來處理。 此外，在我們的例子中，通常只有一小部分文字發生變化，我們希望以某種方式快取結果。 這正是我們所做的。 為了避免每次都檢查所有內容，我們確定性地將文字分成幾部分，並僅檢查那些已更改的內容。 由於文字可能很大且我們不想加載緩存，因此我們不儲存文字本身，而是儲存它們的雜湊值。 這使得插件即使在大檔案上也能順利運作。
LanguageTool 支援超過 25 種語言，但任何使用者不太可能需要所有語言。 我想提供根據請求下載特定語言的庫的機會（如果您在用戶界面中勾選它）。 我們甚至實現了這個，但事實證明它太複雜且不可靠。 特別是，我們必須使用單獨的類別載入器來載入一組新語言的 LanguageTool，然後小心地初始化它。 同時，所有庫都位於使用者 .m2 儲存庫中，每次啟動時我們都必須檢查它們的完整性。 最後，我們決定，如果用戶對插件的大小有疑問，那麼我們將為幾種最受歡迎的語言提供單獨的插件。
黑客松結束後
黑客馬拉松結束了，但插件的開發工作仍在一個較小的團隊中繼續進行。 我想支援字串、註釋，甚至語言結構，例如變數和類別名稱。 目前僅支援 Java、Kotlin 和 Python，但我們希望這個清單會持續成長。 我們修復了許多小錯誤，並與 Idea 的內建拼字檢查器更相容。 此外，還出現了 XML 支援和拼字檢查。 所有這些都可以在我們最近發布的第二版本中找到。
接下來是什麼？
這樣的插件不僅對開發人員有用，而且對技術編寫人員也很有用（例如，通常在 IDE 中使用 XML）。 他們每天都必須使用自然語言進行工作，而沒有助理以編輯提示的形式提示可能出現的錯誤。 我們的插件提供了這樣的提示，並且非常準確。
我們計劃透過添加新語言和探索組織文本檢查的通用方法來開發該外掛程式。 我們近期的計畫包括實施風格設定檔（定義文字風格指南的規則集，例如「不要寫eg，而是寫完整形式」）、擴展字典和改進使用者介面（特別是，我們希望讓使用者不僅有機會忽略某個單詞，也可以將其加到字典中（指示詞性）。
資料來源：www.habr.com