Ni daŭre parolas pri la projektoj de la printempa hackathon DevDays, en kiu partoprenis studentoj de la majstra programo. .
Cetere, ni ŝatus inviti legantojn aliĝi . En ĝi ni publikigos la lastajn novaĵojn pri varbado kaj studado. Vidbendo de la malferma tago ankaŭ troviĝas en la grupo. Ni memorigas vin: la evento okazos la 29-an de aprilo, detaloj .
Analizilo de Voĉa Mesaĝo de Telegramo
Aŭtoro de la ideo
Ĥoroŝev Artjom
Komando-strukturo
Khoroŝev Artem - projektestro/programisto/QA
Eliseev Anton - komerca analizisto/merkatiga specialisto
Maria Kuklina - UI-projektisto/programisto
Bakhvalov Pavel - UI-dezajnisto/programisto/QA
De nia vidpunkto, Telegramo estas moderna kaj oportuna mesaĝisto, kaj ĝia komputila versio estas populara kaj malfermita fonto, kio ebligas modifi ĝin. La kliento ofertas sufiĉe riĉan funkciecon. Krom normaj tekstmesaĝoj, ĝi enhavas voĉvokojn, videomesaĝojn kaj voĉmesaĝojn. Kaj estas ĉi tiuj lastaj, kiuj foje alportas ĝenon al sia ricevanto. Ofte ne eblas aŭskulti voĉmesaĝon ĉe komputilo aŭ tekokomputilo. Eble estas ĉirkaŭa bruo, manko de aŭdiloj, aŭ vi ne volas, ke iu ajn aŭdu la enhavon de la mesaĝo. Tiaj problemoj preskaŭ neniam aperas se vi uzas Telegramon sur inteligenta telefono, ĉar vi povas simple alporti ĝin al via orelo, male al tekkomputilo aŭ komputilo. Ni provis solvi ĉi tiun problemon.
La celo de nia projekto ĉe DevDays estis aldoni la kapablon traduki ricevitajn voĉmesaĝojn en tekston al la Telegram-tabla kliento (ĉi-poste nomata Telegram Desktop).
Ĉiuj analogoj nuntempe estas robotoj, al kiuj vi povas sendi sonmesaĝon kaj ricevi tekston responde. Ni ne tre ĝojas pri tio: plusendi mesaĝon al bot ne estas tre oportuna; ni ŝatus havi denaskan funkcion. Krome, ajna bot estas tria partio, kiu agas kiel peranto inter la API de rekono de parolado kaj la uzanto, kaj ĉi tio estas, minimume, nesekura.
Kiel notite antaŭe, telegramo-skribotablo havas du signifajn avantaĝojn: facileco kaj rapideco de operacio. Kaj ĉi tio ne estas hazardo, ĉar ĝi estas skribita tute en C++. Kaj ĉar ni decidis aldoni novajn funkciojn rekte al la kliento, ni devis disvolvi ĝin en C++.
Estis 4 homoj en nia teamo. Komence, du homoj serĉis taŭgan bibliotekon por parolrekono, unu persono studis la fontkodon de Telegram-skribotablo, alia deplojis la konstruprojekton. . Poste, ĉiuj estis okupataj ripari la UI kaj sencimigi.
Ŝajnis, ke efektivigi la celitan funkciecon ne estus malfacila, sed, kiel ĉiam okazas, malfacilaĵoj aperis.
La solvo al la problemo konsistis el du sendependaj subtaskoj: elekti taŭgan parolrekonan ilon kaj efektivigi UI por nova funkcieco.
Elektinte bibliotekon por voĉa rekono, ni tuj devis forlasi ĉiujn eksterretajn API-ojn, ĉar lingvaj modeloj okupas multe da spaco. Sed ni parolas pri nur unu lingvo. Evidentiĝis, ke ni devos uzi la interretan API. Poste montriĝis, ke la parolrekonoservoj de tiaj gigantoj kiel Google, Yandex kaj Microsoft tute ne estas senpagaj, kaj ni devos kontentiĝi pri provperiodo. Kiel rezulto, Google Speech-To-Text estis elektita ĉar ĝi permesas vin akiri ĵetonon por uzi la servon, kiu daŭros dum tuta jaro.
La dua problemo, kiun ni renkontis, rilatas al kelkaj mankoj de C++ - zoo de diversaj bibliotekoj en foresto de centralizita deponejo. Okazas, ke Telegram Desktop dependas de multaj aliaj versio-specifaj bibliotekoj. La oficiala deponejo havas por kunmeti la projekton. Kaj ankaŭ granda nombro da malfermitaj temoj pri konstruproblemoj, ekzemple и . Ĉiuj problemoj montriĝis rilataj al la fakto, ke la konstruskripto estis skribita por Ubuntu 14.04, kaj por sukcese konstrui telegramon sub Ubuntu 18.04, ŝanĝoj devis esti faritaj.
Telegram Desktop mem bezonas sufiĉe longan tempon por kunmeti: sur tekkomputilo kun Intel Core i5-7200U, kompleta muntado (flag -j 4) kun ĉiuj dependecoj daŭras ĉirkaŭ tri horojn. El ĉi tiuj, proksimume 30 minutoj estas prenitaj per ligado de la kliento mem (poste montriĝis, ke en la Sencimiga agordo, ligado daŭras ĉirkaŭ 10 minutojn), sed la ligo-etapo devas esti ripetita ĉiufoje post fari ŝanĝojn.
Malgraŭ la problemoj, ni sukcesis efektivigi la elpensitan ideon, kaj ankaŭ ĝisdatigi por Ubuntu 18.04. Demonstro de la laboro videblas ĉe . Ni ankaŭ inkluzivas plurajn kuraĝigojn. Apud ĉiuj voĉmesaĝoj aperis butono, kiu ebligas traduki la mesaĝon en tekston. Per dekstra klako, vi povas aldone specifi la lingvon, kiu estos uzata por elsendo. De kliento disponebla por elŝuto.
Laŭ nia opinio, ĝi montriĝis bona Pruvo de Koncepto de funkcieco, kiu konvenus por multaj uzantoj. Ni esperas vidi ĝin en estontaj eldonoj de Telegram Desktop.
Plibonigita Natura Lingva Subteno en IntelliJ IDEA
Aŭtoro de la ideo
Tankov Vladislav
Komando-strukturo
Tankov Vladislav (teamgvidanto, laborante kun LanguageTool kaj IntelliJ IDEA)
Nikita Sokolov (laborante kun LanguageTool kaj kreante UI)
Khvorov Alexander (laborante kun LanguageTool kaj optimumigante rendimenton)
Sadovnikov Alexander (subteno por analizado de marklingvoj kaj kodo)
Ni ellaboris kromprogramon por IntelliJ IDEA, kiu kontrolas diversajn tekstojn (komentoj kaj dokumentaro, laŭvortaj linioj en kodo, teksto formatita en Markdown aŭ XML-marko) por gramatika, ortografio kaj stila precizeco (en la angla tio nomiĝas provlegado).
La ideo de la projekto estis vastigi la norman literumkontrolon IntelliJ IDEA al la skalo de Grammarly, por fari specon de Grammarly ene de IDE.
Vi povas vidi kio okazis .
Nu, ĉi-sube ni parolos pli detale pri la kapabloj de la kromaĵo, kaj ankaŭ pri la malfacilaĵoj, kiuj estiĝis dum ĝia kreado.
Motivacio
Estas multaj produktoj destinitaj por verki tekston en naturaj lingvoj, sed dokumentado kaj kodokomentoj plej ofte estas skribitaj en evolumedioj. Samtempe, IDEoj faras bonegan laboron por trovi erarojn en kodo, sed estas malbone taŭgaj por tekstoj en naturaj lingvoj. Ĉi tio tre facilas fari erarojn pri gramatiko, interpunkcio aŭ stilo sen la evolumedio atentigi ilin. Plej grave estas erari skribante la uzantinterfacon, ĉar ĉi tio influos ne nur la kompreneblecon de la kodo, sed ankaŭ la uzantojn de la evoluinta aplikaĵo mem.
Unu el la plej popularaj kaj evoluintaj evolumedioj estas IntelliJ IDEA, same kiel IDEoj bazitaj sur la IntelliJ Platformo. IntelliJ Platform jam havas enkonstruitan literumkontrolilon, sed ĝi ne forigas eĉ la plej simplajn gramatikajn erarojn. Ni decidis integri unu el la popularaj naturlingvaj analizsistemoj en IntelliJ IDEA.
Реализация
Ni ne metis al ni mem la taskon krei nian propran tekstan konfirmsistemon, do ni uzis ekzistantan solvon. La plej taŭga opcio montriĝis . La permesilo permesis al ni libere uzi ĝin por niaj celoj: ĝi estas senpaga, skribita en Java kaj malfermfonte. Krome, ĝi subtenas 25 lingvojn kaj disvolviĝas dum pli ol dek kvin jaroj. Malgraŭ ĝia malfermiteco, LanguageTool estas serioza konkuranto al pagitaj tekstaj konfirmsolvoj, kaj la fakto ke ĝi povas funkcii loke estas laŭvorte ĝia mortiga trajto.
La kromprogramo estas en . La tuta projekto estis skribita en Kotlin kun malgranda aldono de Java por la UI. Dum la hakatono, ni sukcesis efektivigi subtenon por Markdown, JavaDoc, HTML kaj Plain Text. Post la hakatono, grava ĝisdatigo aldonis subtenon por XML, kordliteraĵoj en Java, Kotlin kaj Python, kaj literumkontrolo.
Malfacilaĵoj
Sufiĉe rapide ni rimarkis, ke se ni ĉiufoje nutras la tekston al LanguageTool por inspektado, tiam la interfaco de IDEA frostos sur iu ajn pli aŭ malpli serioza teksto, ĉar la inspektado mem blokas la UI-fluon. La problemo estis solvita per la kontrolo `ProgressManager.checkCancelled` - ĉi tiu funkcio ĵetas escepton se IDEA opinias, ke estas tempo ĉesigi la inspektadon.
Ĉi tio tute forigis la frostiĝojn, sed estas neeble uzi: la teksto bezonas tre longan tempon por procesi. Cetere, en nia kazo, plej ofte tre malgranda parto de la teksto ŝanĝiĝas kaj ni volas kaŝmemori la rezultojn iel. Ĝuste tion ni faris. Por ne ĉiufoje kontroli ĉion, ni determinisme dividis la tekston en pecojn kaj kontrolis nur tiujn, kiuj ŝanĝiĝis. Ĉar la tekstoj povas esti grandaj kaj ni ne volis ŝargi la kaŝmemoron, ni konservis ne la tekstojn mem, sed iliajn haŝojn. Ĉi tio permesis al la kromaĵo funkcii glate eĉ sur grandaj dosieroj.
LanguageTool subtenas pli ol 25 lingvojn, sed estas neverŝajne ke iu ajn uzanto bezonas ilin ĉiujn. Mi volis doni la ŝancon elŝuti bibliotekojn por specifa lingvo laŭpeto (se vi marku ĝin en la UI). Ni eĉ efektivigis ĉi tion, sed ĝi montriĝis tro komplika kaj nefidinda. Precipe, ni devis ŝargi LanguageTool per nova aro da lingvoj uzante apartan klasŝargilon, kaj poste zorge pravalorigi ĝin. Samtempe, ĉiuj bibliotekoj estis en uzanta .m2-deponejo, kaj ĉe ĉiu komenco ni devis kontroli ilian integrecon. Fine ni decidis, ke se uzantoj havus problemojn pri la grandeco de la kromaĵo, tiam ni disponigus apartan kromprogramon por pluraj el la plej popularaj lingvoj.
Post la hakatono
La hakatono finiĝis, sed laboro pri la kromaĵo daŭris kun pli mallarĝa teamo. Mi volis subteni ŝnurojn, komentojn, kaj eĉ lingvokonstruaĵojn kiel ekzemple variablo- kaj klasnomoj. Nuntempe ĉi tio estas nur subtenata por Java, Kotlin kaj Python, sed ni esperas, ke ĉi tiu listo kreskos. Ni riparis multajn malgrandajn erarojn kaj fariĝis pli kongruaj kun la enkonstruita literumkontrolilo de Idea. Krome aperis XML-subteno kaj literuma kontrolo. Ĉio ĉi troveblas en la dua versio, kiun ni eldonis lastatempe.
Kio sekvas?
Tia kromaĵo povas esti utila ne nur por programistoj, sed ankaŭ por teknikaj verkistoj (ofte laborante, ekzemple, kun XML en IDE). Ĉiutage ili devas labori per natura lingvo, sen havi asistanton en formo de redaktokonsiloj pri eblaj eraroj. Nia kromaĵo provizas tiajn sugestojn kaj faras ĝin kun alta grado de precizeco.
Ni planas evoluigi la kromprogramon, kaj aldonante novajn lingvojn kaj esplorante ĝeneralan aliron por organizi tekstokontroladon. Niaj tujaj planoj inkluzivas la efektivigon de stilaj profiloj (aroj de reguloj, kiuj difinas stilgvidilon por teksto, ekzemple, "ne skribu ekz., sed skribu la plenan formon"), vastigi la vortaron kaj plibonigante la uzantinterfacon (precipe, ni volas doni al la uzanto la ŝancon ne nur ignori vorton, sed aldoni ĝin en la vortaron, indikante la vortparton).
Fonto: www.habr.com