我们继续谈论春季黑客马拉松DevDays的项目，硕士课程
“软件工程/软件工程”的学生参加了这些活动。
顺便说一句，我们想邀请读者加入
裁判法院的
VK小组 。 在其中，我们将发布有关招聘和学习的最新消息。 开放日的视频也可以在该小组中找到。 我们提醒您：该活动将于4月29日举行，详细信息
在网站上 。
电报桌面语音消息解析器
这个想法的作者霍罗舍夫·阿约姆
团队组成Khoroshev Artem-项目经理/开发人员/质量检查
Eliseev Anton-业务分析师/市场营销专员
Kuklina Maria-UI设计师/开发人员
Bakhvalov Pavel-UI设计师/开发人员/质量检查
从我们的角度来看，Telegram是一个现代且方便的Messenger，其PC版本非常流行且开源，因此可以对其进行修改。 客户端提供了相当丰富的功能。 除标准文本消息外，它还包含语音呼叫，视频消息，语音消息。 后者有时会给接收者带来不便。 通常，在计算机或笔记本电脑上无法收听语音消息。 环境噪音，缺少耳机可能会造成干扰，或者您不希望任何人听到消息的内容。 如果您在智能手机上使用电报，则几乎不会发生此类问题，因为与笔记本电脑或PC不同，您可以将其带到耳边。 我们试图解决这个问题。
我们在DevDays的项目的目标是增加在Telegram桌面客户端（以下称为Telegram桌面）中将接收到的语音消息转换为文本的功能。
目前，所有类似物都是机器人，您可以向它们发送音频消息，然后接收文本。 这对我们来说不是很方便：将消息转发到机器人不是很方便，我想具有本机功能。 此外，任何漫游器都是充当语音识别API与用户之间的中介的第三方，这至少是不安全的。
如前所述，电报桌面具有两个重量优势：轻便和速度快。 这绝非偶然，因为它完全是用C ++编写的。 并且由于我们决定直接向客户端添加新功能，因此我们不得不使用C ++开发它。
我们的团队中有4个人。 最初，两个人在寻找合适的语音识别库，一个人研究了Telegram-desktop的源代码，另一个人正在部署
Telegram Desktop项目的构建。 后来，每个人都忙于UI修复和调试。
似乎实现预期功能并不困难，但与往常一样，出现了困难。
该问题的解决方案包括两个独立的子任务：选择用于语音识别的适当方法以及为新功能实现UI。
在选择用于语音识别的库时，我们立即不得不放弃所有离线API，因为语言模型会占用大量空间。 但这只是一种语言。 很明显，您将必须使用在线API。 后来发现，诸如Google，Yandex和Microsoft之类的巨头的语音识别服务根本不是免费的，我们必须对试用期感到满意。 结果，选择了Google Speech-To-Text，因为它可以让您获得使用该服务的令牌，该令牌将持续一年。
我们遇到的第二个问题与C ++的某些缺点有关-在没有集中式存储库的情况下，各种库的动物园。 碰巧Telegram Desktop依赖于其他许多特定版本的库。 官方资料库中有建立项目的说明。 还有大量关于构建问题的未解决问题，例如
一次和
两次 。 事实证明，所有问题都与为Ubuntu 14.04编写构建脚本有关，为了成功在Ubuntu 18.04下构建电报，我不得不进行更改。
Telegram Desktop本身将花费相当长的时间：在具有Intel Core i5-7200U的笔记本电脑上，带有所有依赖项的完整程序集（-j 4标志）大约需要三个小时。 其中，链接客户端本身大约需要30分钟（后来证明在Debug配置中，链接大约需要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在发现编写代码中的错误方面做得很好，但是不适用于自然语言的文本。 因此，很容易在语法，标点或样式上犯错误，并且开发环境不会指出这些错误。 在编写用户界面时犯错误是最关键的，因为这不仅会影响代码的可理解性，还会影响所开发应用程序本身的用户。
最受欢迎的开发环境之一是IntelliJ IDEA，以及基于IntelliJ Platform的IDE。 IntelliJ平台已经具有内置的拼写检查器，但是它甚至不保存最简单的语法错误。 我们决定将一种流行的自然语言分析系统集成到IntelliJ IDEA中。
实作
我们没有为自己设定创建自己的文本验证系统的任务，因此我们利用了现有的解决方案。 最合适的选项是
LanguageTool 。 该许可证允许我们自由地将其用于我们的目的：它是免费的，用Java编写并以开放源代码布局。 此外，它支持25种语言，并且已经发展了15多年。 尽管它是开放的，但LanguageTool还是付费文本验证解决方案的重要竞争对手，而它能够在本地工作的事实实际上是其杀手级功能。
插件代码位于
GitHub上的
存储库中 。 整个项目是用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）。 他们每天都必须使用自然语言，而不必借助助手来获得有关可能的错误的编辑提示。 我们的插件提供了这样的提示，并且这样做的准确性很高。
我们计划通过添加新语言并探索组织文本验证的通用方法来开发插件。 在不久的将来，将实现样式配置文件（定义文本样式指南的规则集，例如，“不要编写例如，但要写完整的表单”），扩展字典并改善用户界面（特别是，我们希望使用户不仅能够忽略单词，还可以添加单词）他进入字典，表示词性）。