Seguimos falando dos proxectos do hackathon primaveral DevDays, no que participaron alumnos do máster .
Por certo, queremos invitar aos lectores a unirse . Nela publicaremos as últimas novidades sobre contratación e estudo. No grupo tamén se pode atopar un vídeo da xornada de portas abertas. Lembrámosvos: o evento terá lugar o 29 de abril, detalles .
Analizador de mensaxes de voz de escritorio de Telegram
Autor da idea
Khoroshev Artyom
Estrutura de mando
Khoroshev Artem – xefe de proxecto/desenvolvedor/QA
Eliseev Anton - analista de negocios/especialista en mercadotecnia
Maria Kuklina - Deseñadora/desenvolvedora de IU
Bakhvalov Pavel - Deseñador/desenvolvedor/QA de IU
Desde o noso punto de vista, Telegram é un mensaxeiro moderno e cómodo, e a súa versión para PC é popular e de código aberto, o que permite modificalo. O cliente ofrece unha funcionalidade bastante rica. Ademais das mensaxes de texto estándar, contén chamadas de voz, mensaxes de vídeo e mensaxes de voz. E son estes últimos os que ás veces supoñen molestias ao seu destinatario. Moitas veces non é posible escoitar unha mensaxe de voz mentres estás nun ordenador ou portátil. Pode haber ruído ambiental, falta de auriculares ou non queres que ninguén escoite o contido da mensaxe. Estes problemas case nunca xorden se usas Telegram nun teléfono intelixente, porque simplemente podes achegalo ao teu oído, a diferenza dun portátil ou dun PC. Tentamos resolver este problema.
O obxectivo do noso proxecto en DevDays era engadir a posibilidade de traducir as mensaxes de voz recibidas en texto ao cliente de escritorio de Telegram (en diante, Telegram Desktop).
Todos os análogos neste momento son bots aos que pode enviar unha mensaxe de audio e recibir un texto de resposta. Non estamos moi contentos con isto: reenviar unha mensaxe a un bot non é moi cómodo; gustaríanos ter unha funcionalidade nativa. Ademais, calquera bot é un terceiro que actúa como intermediario entre a API de recoñecemento de voz e o usuario, e isto é, como mínimo, inseguro.
Como se indicou anteriormente, telegram-desktop ten dúas vantaxes significativas: facilidade e velocidade de operación. E isto non é casual, porque está escrito enteiramente en C++. E como decidimos engadir novas funcionalidades directamente ao cliente, tivemos que desenvolvela en C++.
Había 4 persoas no noso equipo. Inicialmente, dúas persoas buscaban unha biblioteca adecuada para o recoñecemento de voz, unha estudaba o código fonte de Telegram-desktop, outra estaba a implementar o proxecto de compilación. . Máis tarde, todos estaban ocupados arranxando a IU e depurando.
Parecía que implementar a funcionalidade prevista non sería difícil, pero, como sempre sucede, xurdiron dificultades.
A solución ao problema consistiu en dúas subtarefas independentes: escoller unha ferramenta de recoñecemento de voz adecuada e implementar unha IU para novas funcionalidades.
Ao elixir unha biblioteca para o recoñecemento de voz, inmediatamente tivemos que abandonar todas as API sen conexión, porque os modelos de linguaxe ocupan moito espazo. Pero estamos a falar só dunha lingua. Quedou claro que teriamos que usar a API en liña. Máis tarde descubriuse que os servizos de recoñecemento de voz de xigantes como Google, Yandex e Microsoft non son para nada gratuítos, e teremos que conformarnos cun período de proba. Como resultado, escolleuse Google Speech-To-Text porque che permite obter un token para usar o servizo, que durará un ano enteiro.
O segundo problema que atopamos está relacionado con algunhas das deficiencias de C++: un zoolóxico de varias bibliotecas en ausencia dun repositorio centralizado. Acontece que Telegram Desktop depende de moitas outras bibliotecas específicas da versión. O repositorio oficial ten para a montaxe do proxecto. E tamén un gran número de cuestións abertas sobre problemas de construción, por exemplo и . Todos os problemas resultaron estar relacionados co feito de que o script de compilación foi escrito para Ubuntu 14.04 e, para construír con éxito telegrama baixo Ubuntu 18.04, houbo que facer cambios.
O propio Telegram Desktop tarda bastante en montar: nun portátil cun Intel Core i5-7200U, a montaxe completa (marca -j 4) con todas as dependencias leva unhas tres horas. Destes, uns 30 minutos lévanse vinculando o propio cliente (máis tarde resultou que na configuración de Depuración, a ligazón leva uns 10 minutos), pero a fase de ligazón ten que repetirse cada vez despois de facer cambios.
A pesar dos problemas, conseguimos implementar a idea ideada, así como actualizar para Ubuntu 18.04. Pódese ver unha demostración do traballo en . Tamén incluímos varias animacións. Apareceu un botón xunto a todas as mensaxes de voz, que che permite traducir a mensaxe a texto. Facendo clic co botón dereito, tamén pode especificar o idioma que se utilizará para a emisión. Por cliente dispoñible para descargar.
Na nosa opinión, resultou ser unha boa proba de concepto de funcionalidade que sería conveniente para moitos usuarios. Esperamos velo en futuras versións de Telegram Desktop.
Soporte mellorado da linguaxe natural en IntelliJ IDEA
Autor da idea
Tankov Vladislav
Estrutura de mando
Tankov Vladislav (líder do equipo, traballando con LanguageTool e IntelliJ IDEA)
Nikita Sokolov (traballando con LanguageTool e creando IU)
Khvorov Alexander (traballando con LanguageTool e optimizando o rendemento)
Sadovnikov Alexander (soporte para analizar linguaxes de marcado e código)
Desenvolvemos un complemento para IntelliJ IDEA que verifica varios textos (comentarios e documentación, liñas literais en código, texto con formato Markdown ou marcado XML) para a precisión gramatical, ortográfica e estilística (en inglés chámase corrección de probas).
A idea do proxecto era expandir o corrector ortográfico estándar IntelliJ IDEA á escala de Grammarly, para facer unha especie de Grammarly dentro do IDE.
Podes ver o que pasou .
Pois ben, a continuación falaremos con máis detalle das capacidades do complemento, así como das dificultades que xurdiron durante a súa creación.
Motivación
Existen moitos produtos deseñados para escribir texto en linguaxes naturais, pero a documentación e os comentarios de código adóitanse escribir en contornos de desenvolvemento. Ao mesmo tempo, os IDE fan un excelente traballo para atopar erros no código, pero son pouco axeitados para textos en linguaxes naturais. Isto fai que sexa moi doado cometer erros na gramática, a puntuación ou o estilo sen que o ambiente de desenvolvemento os indique. O máis importante é cometer un erro ao escribir a interface de usuario, xa que isto afectará non só á comprensión do código, senón tamén aos propios usuarios da aplicación desenvolvida.
Un dos entornos de desenvolvemento máis populares e desenvolvidos é IntelliJ IDEA, así como os IDE baseados na plataforma IntelliJ. A plataforma IntelliJ xa ten un corrector ortográfico incorporado, pero non elimina nin os erros gramaticais máis sinxelos. Decidimos integrar un dos populares sistemas de análise da linguaxe natural en IntelliJ IDEA.
Implantación
Non nos propuxemos a tarefa de crear o noso propio sistema de verificación de texto, polo que utilizamos unha solución existente. A opción máis axeitada resultou ser . A licenza permitiunos usalo libremente para os nosos propósitos: é gratuíto, está escrito en Java e de código aberto. Ademais, admite 25 idiomas e leva máis de quince anos en desenvolvemento. A pesar da súa apertura, LanguageTool é un serio competidor das solucións de verificación de texto de pago, e o feito de que poida funcionar localmente é literalmente a súa característica principal.
O código do complemento está en . Todo o proxecto foi escrito en Kotlin cunha pequena adición de Java para a IU. Durante o hackathon, conseguimos implementar soporte para Markdown, JavaDoc, HTML e Plain Text. Despois do hackathon, unha actualización importante engadiu compatibilidade con XML, literais de cadea en Java, Kotlin e Python e a corrección ortográfica.
Dificultades
Moi rápido decatámonos de que se alimentamos todo o texto a LanguageTool para inspeccionar cada vez, entón a interface IDEA conxelarase en calquera texto máis ou menos serio, xa que a propia inspección bloquea o fluxo da IU. O problema resolveuse mediante a comprobación `ProgressManager.checkCancelled`: esta función xera unha excepción se IDEA considera que é hora de abortar a inspección.
Isto eliminou completamente as conxelacións, pero é imposible de usar: o texto tarda moito en procesarse. Ademais, no noso caso, a maioría das veces unha parte moi pequena do texto cambia e queremos almacenar en caché os resultados dalgún xeito. Iso é exactamente o que fixemos. Para non comprobar todo cada vez, dividimos o texto de forma determinista en anacos e comprobamos só os que cambiaran. Dado que os textos poden ser grandes e non queriamos cargar a caché, almacenamos non os propios textos, senón os seus hash. Isto permitiu que o complemento funcionara sen problemas mesmo en ficheiros grandes.
LanguageTool admite máis de 25 idiomas, pero é improbable que un usuario os necesite todos. Quería dar a oportunidade de descargar bibliotecas para un idioma específico previa solicitude (se o marcas na IU). Incluso implementamos isto, pero resultou demasiado complicado e pouco fiable. En particular, tivemos que cargar LanguageTool cun novo conxunto de idiomas usando un cargador de clases separado e, a continuación, inicializalo coidadosamente. Ao mesmo tempo, todas as bibliotecas estaban nun repositorio .m2 de usuario, e en cada inicio había que comprobar a súa integridade. Ao final, decidimos que se os usuarios tiñan problemas co tamaño do complemento, proporcionaríamos un complemento separado para varios dos idiomas máis populares.
Despois do hackathon
O hackathon rematou, pero o traballo no complemento continuou cun equipo máis reducido. Quería admitir cadeas, comentarios e mesmo construcións lingüísticas como os nomes de variables e clases. Actualmente só se admite para Java, Kotlin e Python, pero esperamos que esta lista aumente. Arranxamos moitos pequenos erros e somos máis compatibles co corrector ortográfico integrado de Idea. Ademais, apareceron soporte XML e corrección ortográfica. Todo isto pódese atopar na segunda versión, que publicamos recentemente.
Cal é o próximo?
Este complemento pode ser útil non só para desenvolvedores, senón tamén para escritores técnicos (a miúdo traballan, por exemplo, con XML nun IDE). Todos os días teñen que traballar con linguaxe natural, sen ter un asistente en forma de consellos de editor sobre posibles erros. O noso complemento ofrece tales suxestións e faino cun alto grao de precisión.
Planeamos desenvolver o complemento, tanto engadindo novos idiomas como explorando un enfoque xeral para organizar a comprobación de texto. Os nosos plans inmediatos inclúen a implementación de perfís estilísticos (conxuntos de regras que definen unha guía de estilo para o texto, por exemplo, "non escriba, por exemplo, pero escriba o formulario completo"), ampliar o dicionario e mellorar a interface de usuario (en particular, queremos darlle ao usuario a oportunidade non só de ignorar unha palabra, senón de engadila ao dicionario, indicando a parte do discurso).
Fonte: www.habr.com