Continuem parlant dels projectes del hackathon de primavera DevDays, en el qual van participar alumnes del programa de màster .
Per cert, ens agradaria convidar els lectors a unir-se . En ella publicarem les últimes notícies sobre la contractació i els estudis. També podeu trobar un vídeo de la jornada de portes obertes al grup. Us recordem: l'acte tindrà lloc el 29 d'abril, detalls .
Analitzador de missatges de veu de Telegram Desktop
Autor de la idea
Khoroxev Artyom
Alineació
Khoroshev Artem – director de projecte/desenvolupador/QA
Eliseev Anton: analista de negocis/especialista en màrqueting
Maria Kuklina: dissenyadora/desenvolupadora d'IU
Bakhvalov Pavel: dissenyador/desenvolupador/QA d'interfície d'usuari
Des del nostre punt de vista, Telegram és un missatger modern i còmode, i la seva versió per a PC és popular i de codi obert, fet que permet modificar-lo. El client ofereix una funcionalitat força rica. A més dels missatges de text estàndard, conté trucades de veu, missatges de vídeo i missatges de veu. I són aquests darrers els que de vegades suposen molèsties al seu destinatari. Sovint no és possible escoltar un missatge de veu en un ordinador o portàtil. Pot haver-hi soroll ambiental, manca d'auriculars o no voleu que ningú escolti el contingut del missatge. Aquests problemes gairebé mai sorgeixen si utilitzeu Telegram en un telèfon intel·ligent, perquè simplement podeu portar-lo a l'orella, a diferència d'un ordinador portàtil o un ordinador. Hem intentat resoldre aquest problema.
L'objectiu del nostre projecte a DevDays era afegir la possibilitat de traduir els missatges de veu rebuts a text al client d'escriptori de Telegram (d'ara endavant anomenat Telegram Desktop).
Tots els anàlegs de moment són robots als quals podeu enviar un missatge d'àudio i rebre un text com a resposta. No estem molt contents amb això: reenviar un missatge a un bot no és molt convenient; ens agradaria tenir una funcionalitat nativa. A més, qualsevol bot és un tercer que actua com a intermediari entre l'API de reconeixement de veu i l'usuari, i això és, com a mínim, insegur.
Com s'ha indicat anteriorment, telegram-desktop té dos avantatges importants: facilitat i rapidesa d'operació. I això no és casualitat, perquè està escrit completament en C++. I com que vam decidir afegir noves funcionalitats directament al client, vam haver de desenvolupar-la en C++.
Hi havia 4 persones al nostre equip. Inicialment, dues persones estaven buscant una biblioteca adequada per al reconeixement de veu, una persona estava estudiant el codi font de Telegram-desktop, una altra estava desplegant el projecte de creació. . Més tard, tothom estava ocupat arreglant la interfície d'usuari i depurant.
Semblava que implementar la funcionalitat prevista no seria difícil, però, com sempre passa, van sorgir dificultats.
La solució al problema consistia en dues subtasques independents: triar una eina de reconeixement de veu adequada i implementar una interfície d'usuari per a noves funcionalitats.
Quan vam triar una biblioteca per al reconeixement de veu, vam haver d'abandonar immediatament totes les API fora de línia, perquè els models d'idioma ocupen molt d'espai. Però només estem parlant d'una llengua. Va quedar clar que hauríem d'utilitzar l'API en línia. Més tard, va resultar que els serveis de reconeixement de veu de gegants com Google, Yandex i Microsoft no són gens gratuïts i ens haurem d'acontentar amb un període de prova. Com a resultat, es va triar Google Speech-To-Text perquè us permet obtenir un testimoni per utilitzar el servei, que durarà un any sencer.
El segon problema que hem trobat està relacionat amb algunes de les mancances de C++: un zoo de diverses biblioteques en absència d'un dipòsit centralitzat. Succeeix que Telegram Desktop depèn de moltes altres biblioteques específiques de la versió. El repositori oficial té per muntar el projecte. I també un gran nombre de qüestions obertes sobre problemes de construcció, per exemple и . Tots els problemes van resultar estar relacionats amb el fet que l'script de compilació es va escriure per a Ubuntu 14.04 i, per tal de construir telegrama amb èxit amb Ubuntu 18.04, s'havien de fer canvis.
Telegram Desktop triga força a muntar-se: en un ordinador portàtil amb un Intel Core i5-7200U, el muntatge complet (marca -j 4) amb totes les dependències triga unes tres hores. D'aquests, uns 30 minuts es triguen enllaçant el propi client (més tard va resultar que a la configuració de Depuració, l'enllaç triga uns 10 minuts), però l'etapa d'enllaç s'ha de repetir cada vegada després de fer canvis.
Malgrat els problemes, hem aconseguit implementar la idea ideada, així com actualitzar-la per a Ubuntu 18.04. Es pot veure una demostració de l'obra a . També incloem diverses animacions. Al costat de tots els missatges de veu ha aparegut un botó que us permet traduir el missatge a text. Fent clic amb el botó dret, també podeu especificar l'idioma que s'utilitzarà per a la transmissió. Per client disponible per descarregar.
Segons la nostra opinió, va resultar ser una bona prova de concepte de funcionalitat que seria convenient per a molts usuaris. Esperem veure-ho en futures versions de Telegram Desktop.
Suport millorat del llenguatge natural a IntelliJ IDEA
Autor de la idea
Tankov Vladislav
Alineació
Tankov Vladislav (cap d'equip, treballant amb LanguageTool i IntelliJ IDEA)
Nikita Sokolov (treballant amb LanguageTool i creant la interfície d'usuari)
Khvorov Alexander (treballant amb LanguageTool i optimitzant el rendiment)
Sadovnikov Alexander (suport per analitzar llenguatges de marcatge i codi)
Hem desenvolupat un connector per a IntelliJ IDEA que verifica diversos textos (comentaris i documentació, línies literals en codi, text amb format en Markdown o marcatge XML) per a la precisió gramatical, ortogràfica i estilística (en anglès això s'anomena correcció de proves).
La idea del projecte era ampliar la correcció ortogràfica estàndard IntelliJ IDEA a l'escala de Grammarly, per fer una mena de Grammarly dins de l'IDE.
Podeu veure què va passar .
Doncs bé, a continuació parlarem amb més detall de les capacitats del complement, així com de les dificultats que van sorgir durant la seva creació.
RњRѕS, ReRІR ° C † ReSЏ
Hi ha molts productes dissenyats per escriure text en llenguatges naturals, però la documentació i els comentaris de codi s'escriuen més sovint en entorns de desenvolupament. Al mateix temps, els IDE fan un treball excel·lent per trobar errors en el codi, però són poc adequats per a textos en llenguatges naturals. Això fa que sigui molt fàcil cometre errors de gramàtica, puntuació o estil sense que l'entorn de desenvolupament els indiqui. El més important és cometre un error en escriure la interfície d'usuari, ja que això afectarà no només la comprensió del codi, sinó també els usuaris de l'aplicació desenvolupada.
Un dels entorns de desenvolupament més populars i desenvolupats és IntelliJ IDEA, així com els IDE basats en la plataforma IntelliJ. La plataforma IntelliJ ja té un corrector ortogràfic integrat, però no elimina ni els errors gramaticals més senzills. Vam decidir integrar un dels sistemes populars d'anàlisi del llenguatge natural a IntelliJ IDEA.
Implementació
No ens vam proposar la tasca de crear el nostre propi sistema de verificació de text, així que vam utilitzar una solució existent. L'opció més adequada va resultar ser . La llicència ens va permetre utilitzar-la lliurement per als nostres propòsits: és gratuïta, està escrita en Java i de codi obert. A més, admet 25 idiomes i fa més de quinze anys que està en desenvolupament. Malgrat la seva obertura, LanguageTool és un seriós competidor de les solucions de verificació de text de pagament, i el fet que pugui funcionar localment és literalment la seva característica principal.
El codi del connector està en . Tot el projecte va ser escrit en Kotlin amb una petita addició de Java per a la interfície d'usuari. Durant el hackathon, vam aconseguir implementar suport per a Markdown, JavaDoc, HTML i Plain Text. Després del hackathon, una actualització important va afegir suport per a XML, literals de cadena en Java, Kotlin i Python i la correcció ortogràfica.
Dificultats
Molt ràpidament ens vam adonar que si fem arribar tot el text a LanguageTool per inspeccionar-lo cada cop, aleshores la interfície IDEA es congelarà en qualsevol text més o menys seriós, ja que la inspecció mateixa bloqueja el flux de la IU. El problema s'ha resolt mitjançant la comprovació `ProgressManager.checkCancelled': aquesta funció genera una excepció si IDEA creu que és hora d'avortar la inspecció.
Això va eliminar completament les congelacions, però és impossible d'utilitzar: el text triga molt a processar-se. A més, en el nostre cas, la majoria de vegades una part molt petita del text canvia i volem guardar els resultats a la memòria cau d'alguna manera. Això és exactament el que vam fer. Per no comprovar-ho tot cada cop, vam dividir el text de manera determinista en trossos i vam comprovar només els que havien canviat. Com que els textos poden ser grans i no volíem carregar la memòria cau, no hem emmagatzemat els textos en si, sinó els seus hash. Això va permetre que el connector funcionés sense problemes fins i tot en fitxers grans.
LanguageTool admet més de 25 idiomes, però és poc probable que un usuari els necessiti tots. Volia donar l'oportunitat de descarregar biblioteques per a un idioma específic a petició (si el marqueu a la IU). Fins i tot ho vam implementar, però va resultar massa complicat i poc fiable. En particular, vam haver de carregar LanguageTool amb un nou conjunt d'idiomes mitjançant un carregador de classes independent i, a continuació, inicialitzar-lo amb cura. Al mateix temps, totes les biblioteques estaven en un repositori .m2 d'usuari, i a cada inici n'havíem de comprovar la integritat. Al final, vam decidir que si els usuaris tenien problemes amb la mida del connector, proporcionaríem un connector independent per a diversos dels idiomes més populars.
Després del hackathon
El hackathon va acabar, però el treball en el connector va continuar amb un equip més reduït. Volia admetre cadenes, comentaris i fins i tot construccions de llenguatge com ara noms de variables i classes. Actualment només és compatible amb Java, Kotlin i Python, però esperem que aquesta llista creixi. Hem corregit molts errors petits i hem tornat més compatibles amb el corrector ortogràfic integrat d'Idea. A més, ha aparegut el suport XML i la correcció ortogràfica. Tot això es pot trobar a la segona versió, que hem publicat recentment.
Què serà el següent?
Aquest complement pot ser útil no només per als desenvolupadors, sinó també per als escriptors tècnics (sovint treballant, per exemple, amb XML en un IDE). Cada dia han de treballar amb llenguatge natural, sense tenir un assistent en forma de consells de l'editor sobre possibles errors. El nostre connector proporciona aquests consells i ho fa amb un alt grau de precisió.
Tenim previst desenvolupar el connector, tant afegint nous idiomes com explorant un enfocament general per organitzar la comprovació de text. Els nostres plans immediats inclouen la implementació de perfils estilístics (conjunts de regles que defineixen una guia d'estil per al text, per exemple, "no escriviu, per exemple, però escriviu la forma completa"), l'ampliació del diccionari i la millora de la interfície d'usuari (en particular, volem donar a l'usuari l'oportunitat no només d'ignorar una paraula, sinó d'afegir-la al diccionari, indicant la part del discurs).
Font: www.habr.com