我们继续聊一下硕士生参加的春季黑客马拉松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。 后来发现，谷歌、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