Ons gaan voort om te praat oor die projekte van die lente hackathon DevDays, waaraan studente van die meestersgraadprogram deelgeneem het .
Terloops, ons wil graag lesers nooi om aan te sluit . Daarin sal ons die jongste nuus oor werwing en studie publiseer. ’n Video van die opedag kan ook in die groep gevind word. Ons herinner jou: die geleentheid sal op 29 April plaasvind, besonderhede .
Telegram Desktop Voice Message Parser
Skrywer van die idee
Khoroshev Artyom
Span samestelling
Khoroshev Artem – projekbestuurder/ontwikkelaar/QA
Eliseev Anton – besigheidsontleder/bemarkingspesialis
Maria Kuklina – UI-ontwerper/ontwikkelaar
Bakhvalov Pavel – UI-ontwerper/ontwikkelaar/QA
Vanuit ons oogpunt is Telegram 'n moderne en gerieflike boodskapper, en sy rekenaarweergawe is gewild en oopbron, wat dit moontlik maak om dit te verander. Die kliënt bied redelik ryk funksionaliteit. Benewens standaard teksboodskappe, bevat dit stemoproepe, videoboodskappe en stemboodskappe. En dit is laasgenoemde wat soms vir hul ontvanger ongerief meebring. Dit is dikwels nie moontlik om na 'n stemboodskap te luister terwyl jy by 'n rekenaar of skootrekenaar is nie. Daar is dalk omringende geraas, 'n gebrek aan oorfone, of jy wil nie hê dat iemand die inhoud van die boodskap moet hoor nie. Sulke probleme ontstaan amper nooit as jy Telegram op 'n slimfoon gebruik nie, want jy kan dit eenvoudig na jou oor bring, anders as 'n skootrekenaar of rekenaar. Ons het probeer om hierdie probleem op te los.
Die doel van ons projek by DevDays was om die vermoë by te voeg om ontvangen stemboodskappe in teks te vertaal na die Telegram-rekenaarkliënt (hierna na verwys as Telegram Desktop).
Alle analoë op die oomblik is bots waarna jy 'n oudioboodskap kan stuur en 'n teks in reaksie kan ontvang. Ons is nie baie gelukkig hiermee nie: om 'n boodskap na 'n bot aan te stuur is nie baie gerieflik nie; ons wil graag inheemse funksionaliteit hê. Daarbenewens is enige bot 'n derde party wat optree as 'n tussenganger tussen die spraakherkennings-API en die gebruiker, en dit is ten minste onveilig.
Soos vroeër genoem, het telegram-lessenaar twee belangrike voordele: gemak en spoed van werking. En dit is nie toevallig nie, want dit is geheel en al in C++ geskryf. En aangesien ons besluit het om nuwe funksionaliteit direk by die kliënt te voeg, moes ons dit in C++ ontwikkel.
Daar was 4 mense in ons span. Aanvanklik was twee mense op soek na 'n geskikte biblioteek vir spraakherkenning, een persoon het die bronkode van Telegram-desktop bestudeer, 'n ander het die bouprojek ontplooi . Later was almal besig om die UI reg te maak en te ontfout.
Dit het gelyk asof die implementering van die beoogde funksionaliteit nie moeilik sou wees nie, maar, soos altyd gebeur, het probleme ontstaan.
Die oplossing vir die probleem het bestaan uit twee onafhanklike subtake: die keuse van 'n geskikte spraakherkenningsinstrument en die implementering van 'n UI vir nuwe funksionaliteit.
Toe ons 'n biblioteek vir stemherkenning gekies het, moes ons dadelik alle vanlyn API's laat vaar, want taalmodelle neem baie spasie op. Maar ons praat net van een taal. Dit het duidelik geword dat ons die aanlyn API sal moet gebruik. Later het dit geblyk dat die spraakherkenningsdienste van sulke reuse soos Google, Yandex en Microsoft glad nie gratis is nie, en ons sal tevrede moet wees met 'n proeftydperk. As gevolg hiervan is Google Speech-To-Text gekies omdat dit jou toelaat om 'n teken te kry vir die gebruik van die diens, wat vir 'n hele jaar sal duur.
Die tweede probleem wat ons teëgekom het, hou verband met sommige van die tekortkominge van C++ - 'n dieretuin van verskeie biblioteke in die afwesigheid van 'n gesentraliseerde bewaarplek. Dit gebeur so dat Telegram Desktop afhanklik is van baie ander weergawe-spesifieke biblioteke. Die amptelike bewaarplek het vir die samestelling van die projek. En ook 'n groot aantal oop kwessies oor bouprobleme, byvoorbeeld и . Al die probleme het geblyk te hou verband met die feit dat die bouskrif vir Ubuntu 14.04 geskryf is, en om telegram suksesvol onder Ubuntu 18.04 te bou, moes veranderinge aangebring word.
Telegram Desktop self neem nogal lank om te monteer: op 'n skootrekenaar met 'n Intel Core i5-7200U neem die volledige samestelling (vlag -j 4) met alle afhanklikhede ongeveer drie uur. Hiervan word ongeveer 30 minute geneem deur die kliënt self te koppel (dit het later geblyk dat in die Debug-konfigurasie, koppeling ongeveer 10 minute neem), en tog moet die koppelingstadium elke keer herhaal word nadat veranderinge gemaak is.
Ten spyte van die probleme, het ons daarin geslaag om die konsep idee te implementeer, sowel as by te werk vir Ubuntu 18.04. 'n Demonstrasie van die werk kan gesien word by . Ons sluit ook verskeie animasies in. 'n Knoppie het langs alle stemboodskappe verskyn, wat jou toelaat om die boodskap in teks te vertaal. Deur regs te klik, kan jy ook die taal spesifiseer wat vir uitsaai gebruik sal word. Deur kliënt beskikbaar vir aflaai.
Na ons mening het dit geblyk 'n goeie Bewys van Konsep van funksionaliteit te wees wat vir baie gebruikers gerieflik sou wees. Ons hoop om dit in toekomstige uitgawes van Telegram Desktop te sien.
Verbeterde natuurlike taalondersteuning in IntelliJ IDEA
Skrywer van die idee
Tankov Vladislav
Span samestelling
Tankov Vladislav (spanleier, werk saam met LanguageTool en IntelliJ IDEA)
Nikita Sokolov (werk met LanguageTool en skep UI)
Khvorov Alexander (werk met LanguageTool en optimaliseer prestasie)
Sadovnikov Alexander (ondersteuning vir die ontleding van opmaaktale en kode)
Ons het 'n inprop vir IntelliJ IDEA ontwikkel wat verskeie tekste (opmerkings en dokumentasie, letterlike reëls in kode, teks geformateer in Markdown of XML-opmerk) nagaan vir grammatikale, spelling en stilistiese akkuraatheid (in Engels word dit proeflees genoem).
Die idee van die projek was om die standaard speltoets IntelliJ IDEA uit te brei na die skaal van Grammarly, om 'n soort Grammarly binne IDE te maak.
Jy kan sien wat gebeur het .
Wel, hieronder sal ons in meer besonderhede praat oor die vermoëns van die inprop, sowel as die probleme wat tydens die skepping daarvan ontstaan het.
Motivering
Daar is baie produkte wat ontwerp is om teks in natuurlike tale te skryf, maar dokumentasie en kodekommentaar word meestal in ontwikkelingsomgewings geskryf. Terselfdertyd doen IDE's 'n uitstekende werk om foute in kode te vind, maar is swak geskik vir tekste in natuurlike tale. Dit maak dit baie maklik om foute in grammatika, leestekens of styl te maak sonder dat die ontwikkelingsomgewing dit uitwys. Dit is uiters belangrik om 'n fout te maak met die skryf van die gebruikerskoppelvlak, aangesien dit nie net die verstaanbaarheid van die kode sal beïnvloed nie, maar ook die gebruikers van die ontwikkelde toepassing self.
Een van die gewildste en mees ontwikkelde ontwikkelingsomgewings is IntelliJ IDEA, sowel as IDE's gebaseer op die IntelliJ-platform. IntelliJ Platform het reeds 'n ingeboude speltoetser, maar dit raak nie eers van die eenvoudigste grammatikale foute ontslae nie. Ons het besluit om een van die gewilde natuurlike taalanalise-stelsels in IntelliJ IDEA te integreer.
Implementering
Ons het nie vir onsself die taak gestel om ons eie teksverifikasiestelsel te skep nie, daarom het ons 'n bestaande oplossing gebruik. Die mees geskikte opsie blyk te wees . Die lisensie het ons toegelaat om dit vryelik vir ons doeleindes te gebruik: dit is gratis, geskryf in Java en oopbron. Daarbenewens ondersteun dit 25 tale en is dit al meer as vyftien jaar in ontwikkeling. Ondanks sy openheid, is LanguageTool 'n ernstige mededinger vir betaalde teksverifikasie-oplossings, en die feit dat dit plaaslik kan werk, is letterlik sy moordende kenmerk.
Die inpropkode is in . Die hele projek is in Kotlin geskryf met 'n klein toevoeging van Java vir die UI. Tydens die hackathon het ons daarin geslaag om ondersteuning vir Markdown, JavaDoc, HTML en gewone teks te implementeer. Na die hackathon het 'n groot opdatering ondersteuning vir XML, stringletters in Java, Kotlin en Python bygevoeg, en speltoetsing.
probleme
Ons het redelik vinnig besef dat as ons elke keer al die teks na LanguageTool toevoer vir inspeksie, dan sal die IDEA-koppelvlak op enige min of meer ernstige teks vries, aangesien die inspeksie self die UI-vloei blokkeer. Die probleem is opgelos deur die `ProgressManager.checkCancelled`-tjek - hierdie funksie skep 'n uitsondering as IDEA glo dat dit tyd is om die inspeksie te staak.
Dit het die bevriesing heeltemal uitgeskakel, maar dit is onmoontlik om te gebruik: die teks neem baie lank om te verwerk. Boonop verander in ons geval meestal 'n baie klein deel van die teks en ons wil die resultate op een of ander manier kas. Dit is presies wat ons gedoen het. Om nie elke keer alles na te gaan nie, het ons die teks deterministies in stukke opgedeel en net dié wat verander het, nagegaan. Aangesien die tekste groot kan wees en ons nie die kas wou laai nie, het ons nie die tekste self gestoor nie, maar hul hashes. Dit het die inprop toegelaat om selfs op groot lêers glad te werk.
LanguageTool ondersteun meer as 25 tale, maar dit is onwaarskynlik dat enige gebruiker hulle almal nodig het. Ek wou op versoek die geleentheid gee om biblioteke vir 'n spesifieke taal af te laai (as jy dit in die UI afmerk). Ons het dit selfs geïmplementeer, maar dit blyk te ingewikkeld en onbetroubaar te wees. Ons moes veral LanguageTool met 'n nuwe stel tale laai met 'n aparte klaslaaier, en dit dan versigtig inisialiseer. Terselfdertyd was al die biblioteke in 'n gebruiker .m2-bewaarplek, en met elke begin moes ons hul integriteit nagaan. Uiteindelik het ons besluit dat as gebruikers probleme het met die grootte van die inprop, ons 'n aparte inprop vir verskeie van die gewildste tale sal verskaf.
Na die hackathon
Die hackathon het geëindig, maar werk aan die inprop het voortgegaan met 'n nouer span. Ek wou snare, opmerkings en selfs taalkonstrukte soos veranderlike en klasname ondersteun. Tans word dit net vir Java, Kotlin en Python ondersteun, maar ons hoop dat hierdie lys sal groei. Ons het baie klein foutjies reggemaak en meer versoenbaar geword met Idea se ingeboude speltoetser. Boonop het XML-ondersteuning en speltoetsing verskyn. Dit alles kan gevind word in die tweede weergawe, wat ons onlangs gepubliseer het.
Wat is volgende?
So 'n inprop kan nuttig wees nie net vir ontwikkelaars nie, maar ook vir tegniese skrywers (wat dikwels werk, byvoorbeeld, met XML in 'n IDE). Hulle moet elke dag met natuurlike taal werk, sonder om 'n assistent te hê in die vorm van redakteurwenke oor moontlike foute. Ons inprop verskaf sulke wenke en doen dit met 'n hoë mate van akkuraatheid.
Ons beplan om die inprop te ontwikkel, beide deur nuwe tale by te voeg en deur 'n algemene benadering tot die organisering van tekskontrolering te ondersoek. Ons onmiddellike planne sluit in die implementering van stilistiese profiele (stelle reëls wat 'n stylgids vir teks definieer, byvoorbeeld, "nie skryf nie, maar skryf die volledige vorm"), die uitbreiding van die woordeboek en die verbetering van die gebruikerskoppelvlak (veral, ons wil die gebruiker die geleentheid gee om nie net 'n woord te ignoreer nie, maar om dit in die woordeboek by te voeg, wat die woordsoort aandui).
Bron: www.habr.com