Toliau kalbame apie pavasario hakatono DevDays projektus, kuriuose dalyvavo magistrantūros studentai .
Beje, norime pakviesti ir skaitytojus prisijungti . Jame skelbsime paskutines naujienas apie įdarbinimą ir studijas. Grupėje galima rasti ir vaizdo įrašą iš atvirų durų dienos. Primename: renginys vyks balandžio 29 d., detaliau .
„Telegram“ darbalaukio balso pranešimų analizatorius
Idėjos autorius
Choroševas Artiomas
Rikiuotė
Khoroshev Artem - projekto vadovas / kūrėjas / QA
Elisejevas Antonas – verslo analitikas/rinkodaros specialistas
Maria Kuklina – UI dizainerė / kūrėja
Bakhvalovas Pavelas – vartotojo sąsajos dizaineris / kūrėjas / kokybės užtikrinimas
Mūsų požiūriu, „Telegram“ yra modernus ir patogus pasiuntinys, o jos kompiuterinė versija yra populiari ir atviro kodo, todėl ją galima modifikuoti. Klientas siūlo gana turtingą funkcionalumą. Be standartinių tekstinių pranešimų, jame yra balso skambučių, vaizdo žinučių ir balso pranešimų. Ir būtent pastarieji kartais sukelia nepatogumų jų gavėjui. Prie kompiuterio ar nešiojamojo kompiuterio dažnai neįmanoma klausytis balso pranešimo. Gali girdėti aplinkos triukšmas, trūkti ausinių arba nenorite, kad kas nors išgirstų pranešimo turinį. Tokių problemų beveik niekada nekyla, jei „Telegram“ naudojate išmaniajame telefone, nes galite tiesiog neštis prie ausies, skirtingai nei nešiojamasis ar kompiuteris. Mes bandėme išspręsti šią problemą.
Mūsų projekto „DevDays“ tikslas buvo pridėti galimybę gautus balso pranešimus išversti į tekstą į „Telegram“ darbalaukio klientą (toliau – „Telegram Desktop“).
Visi analogai šiuo metu yra robotai, į kuriuos galite siųsti garso pranešimą ir gauti atsakymą. Mes nesame tuo labai patenkinti: persiųsti pranešimą robotui nėra labai patogu, norėtume turėti vietinę funkciją. Be to, bet kuris robotas yra trečioji šalis, veikianti kaip tarpininkas tarp kalbos atpažinimo API ir vartotojo, ir tai yra bent jau nesaugu.
Kaip minėta anksčiau, „telegram-desktop“ turi du reikšmingus pranašumus: naudojimo paprastumą ir greitį. Ir tai nėra atsitiktinumas, nes jis parašyta C++ kalba. Ir kadangi nusprendėme pridėti naujų funkcijų tiesiai į klientą, turėjome ją sukurti C++.
Mūsų komandoje buvo 4 žmonės. Iš pradžių du žmonės ieškojo tinkamos bibliotekos kalbos atpažinimui, vienas studijavo Telegram-desktop šaltinio kodą, kitas diegė kūrimo projektą. . Vėliau visi užsiėmė vartotojo sąsajos taisymu ir derinimu.
Atrodė, kad įgyvendinti numatytą funkcionalumą nebus sunku, tačiau, kaip visada nutinka, iškilo sunkumų.
Problemos sprendimą sudarė dvi nepriklausomos papildomos užduotys: tinkamo kalbos atpažinimo įrankio parinkimas ir naujos funkcionalumo vartotojo sąsajos įdiegimas.
Renkantis biblioteką balso atpažinimui iš karto teko atsisakyti visų offline API, nes kalbiniai modeliai užima daug vietos. Bet mes kalbame tik apie vieną kalbą. Tapo aišku, kad turėsime naudoti internetinę API. Vėliau paaiškėjo, kad tokių gigantų kaip „Google“, „Yandex“ ir „Microsoft“ kalbos atpažinimo paslaugos visai nėra nemokamos ir teks tenkintis bandomuoju laikotarpiu. Dėl to buvo pasirinktas Google Speech-To-Text, nes jis leidžia gauti naudojimosi paslauga žetoną, kuris galios ištisus metus.
Antroji problema, su kuria susidūrėme, yra susijusi su kai kuriais C++ trūkumais – įvairių bibliotekų zoologijos sodu, kai nėra centralizuotos saugyklos. Taip atsitinka, kad „Telegram Desktop“ priklauso nuo daugelio kitų konkrečių versijų bibliotekų. Oficiali saugykla turi projekto surinkimui. Taip pat daug neišspręstų klausimų, pavyzdžiui, dėl kūrimo problemų и . Visos problemos pasirodė susijusios su tuo, kad kūrimo scenarijus buvo parašytas Ubuntu 14.04, o norint sėkmingai sukurti telegramą pagal Ubuntu 18.04, reikėjo atlikti pakeitimus.
Pačios Telegram Desktop surinkimas užtrunka gana ilgai: nešiojamajame kompiuteryje su Intel Core i5-7200U pilnas surinkimas (vėliava -j 4) su visomis priklausomybėmis užtrunka apie tris valandas. Iš jų apie 30 minučių užtrunka susiejant patį klientą (vėliau paaiškėjo, kad Debug konfigūracijoje susiejimas užtrunka apie 10 minučių), tačiau susiejimo etapą tenka kartoti kaskart atlikus pakeitimus.
Nepaisant problemų, sugalvotą idėją pavyko įgyvendinti, taip pat atnaujinti skirta Ubuntu 18.04. Darbo demonstraciją galima pamatyti adresu . Taip pat įtraukiame keletą animacijų. Prie visų balso pranešimų atsirado mygtukas, leidžiantis išversti pranešimą tekstu. Dešiniuoju pelės mygtuku spustelėję galite papildomai nurodyti kalbą, kuria bus transliuojama. Autorius galima atsisiųsti klientą.
Mūsų nuomone, tai pasirodė geras funkcionalumo įrodymas, kuris būtų patogus daugeliui vartotojų. Tikimės tai pamatyti būsimuose „Telegram Desktop“ leidimuose.
Patobulintas IntelliJ IDEA natūralios kalbos palaikymas
Idėjos autorius
Tankovas Vladislavas
Rikiuotė
Tankovas Vladislavas (komandos vadovas, dirbantis su LanguageTool ir IntelliJ IDEA)
Nikita Sokolovas (dirba su LanguageTool ir kuria vartotojo sąsają)
Chvorovas Aleksandras (dirba su LanguageTool ir optimizuoja našumą)
Aleksandras Sadovnikovas (žymėjimo kalbų ir kodo analizavimo palaikymas)
Sukūrėme IntelliJ IDEA įskiepį, kuris tikrina įvairių tekstų (komentarų ir dokumentacijos, pažodinių eilučių kode, teksto, suformatuoto Markdown arba XML žymėjimu) gramatikos, rašybos ir stilistinio tikslumo (anglų kalba tai vadinama korektūra).
Projekto idėja buvo išplėsti standartinį rašybos tikrinimą IntelliJ IDEA iki Grammarly mastelio, kad IDE viduje būtų sukurta tam tikra gramatika.
Jūs matote, kas atsitiko .
Na, o toliau plačiau pakalbėsime apie įskiepio galimybes, taip pat apie sunkumus, iškilusius jį kuriant.
Motyvacija
Yra daug produktų, skirtų tekstui rašyti natūraliomis kalbomis, tačiau dokumentacija ir kodo komentarai dažniausiai rašomi kūrimo aplinkose. Tuo pačiu metu IDE puikiai atlieka kodo klaidų radimą, tačiau jie prastai tinka tekstams natūraliomis kalbomis. Dėl to labai lengva padaryti gramatikos, skyrybos ar stiliaus klaidų, kūrimo aplinkai jų nenurodant. Svarbiausia padaryti klaidą rašant vartotojo sąsają, nes tai turės įtakos ne tik kodo suprantamumui, bet ir patiems sukurtos programos vartotojams.
Viena iš populiariausių ir išvystytų kūrimo aplinkų yra „IntelliJ IDEA“, taip pat „IntelliJ“ platformos pagrindu sukurtos IDE. „IntelliJ Platform“ jau turi įmontuotą rašybos tikrintuvą, tačiau jis neatsikrato net paprasčiausių gramatikos klaidų. Vieną iš populiarių natūralios kalbos analizės sistemų nusprendėme integruoti į IntelliJ IDEA.
Vykdymas
Mes nekėlėme sau užduoties sukurti savo teksto tikrinimo sistemą, todėl panaudojome esamą sprendimą. Tinkamiausias variantas pasirodė . Licencija leido mums ją laisvai naudoti savo tikslams: ji yra nemokama, parašyta Java ir atvirojo kodo. Be to, jis palaiko 25 kalbas ir buvo kuriamas daugiau nei penkiolika metų. Nepaisant atvirumo, „LanguageTool“ yra rimtas mokamų teksto tikrinimo sprendimų konkurentas, o tai, kad jis gali veikti vietoje, tiesiogine prasme yra jo žudikas.
Įskiepio kodas yra . Visas projektas buvo parašytas Kotlin kalba su nedideliu „Java“ priedu vartotojo sąsajai. Hakatono metu pavyko įdiegti Markdown, JavaDoc, HTML ir Plain Text palaikymą. Po hakatono, pagrindinis atnaujinimas papildė XML palaikymą, „Java“, „Kotlin“ ir „Python“ eilučių raides ir rašybos tikrinimą.
Sunkumai
Gana greitai supratome, kad jei kiekvieną kartą pateiksime visą tekstą į LanguageTool apžiūrai, IDEA sąsaja užšaldys bet kokį daugiau ar mažiau rimtą tekstą, nes pati patikra blokuoja vartotojo sąsajos srautą. Problema buvo išspręsta naudojant `ProgressManager.checkCancelled` patikrą – ši funkcija padaro išimtį, jei IDEA mano, kad laikas nutraukti patikrinimą.
Tai visiškai pašalino sustingimą, tačiau jo naudoti neįmanoma: tekstas apdorojamas labai ilgai. Be to, mūsų atveju dažniausiai pasikeičia labai maža teksto dalis ir norime kažkaip išsaugoti rezultatus. Būtent tai ir padarėme. Kad kaskart visko netikrintume, tekstą deterministiškai suskaidėme į dalis ir tikrinome tik tuos, kurie pasikeitė. Kadangi tekstai gali būti dideli ir nenorėjome krauti talpyklos, saugojome ne pačius tekstus, o jų maišus. Tai leido papildiniui sklandžiai veikti net su dideliais failais.
LanguageTool palaiko daugiau nei 25 kalbas, tačiau vargu ar vienam vartotojui jų visų prireiks. Norėjau suteikti galimybę pagal pageidavimą atsisiųsti bibliotekas konkrečiai kalbai (jei pažymėsite ją vartotojo sąsajoje). Netgi tai įgyvendinome, bet pasirodė pernelyg sudėtinga ir nepatikima. Visų pirma, mes turėjome įkelti LanguageTool su nauju kalbų rinkiniu naudodami atskirą klasės įkėlimo programą, o tada atsargiai jį inicijuoti. Tuo pačiu metu visos bibliotekos buvo vartotojo .m2 saugykloje ir kiekvieną kartą pradėdami turėjome patikrinti jų vientisumą. Galų gale nusprendėme, kad jei vartotojams kiltų problemų dėl papildinio dydžio, pateiksime atskirą įskiepį kelioms populiariausioms kalboms.
Po hakatono
Hakatonas baigėsi, tačiau darbas su įskiepiu tęsėsi su siauresne komanda. Norėjau palaikyti eilutes, komentarus ir net kalbos konstrukcijas, pvz., kintamųjų ir klasių pavadinimus. Šiuo metu tai palaiko tik Java, Kotlin ir Python, bet tikimės, kad šis sąrašas augs. Ištaisėme daug smulkių klaidų ir tapome labiau suderinami su „Idea“ įtaisytuoju rašybos tikrintuvu. Be to, atsirado XML palaikymas ir rašybos tikrinimas. Visa tai galima rasti antrojoje versijoje, kurią neseniai paskelbėme.
Kas toliau?
Toks įskiepis gali būti naudingas ne tik kūrėjams, bet ir techniniams rašytojams (dažnai dirbantiems, pavyzdžiui, su XML IDE). Kiekvieną dieną jie turi dirbti su natūralia kalba, neturėdami padėjėjo redaktoriaus patarimų apie galimas klaidas. Mūsų papildinys teikia tokias užuominas ir atlieka tai labai tiksliai.
Planuojame plėtoti papildinį įtraukdami naujų kalbų ir išnagrinėdami bendrą teksto tikrinimo organizavimo būdą. Artimiausiuose mūsų planuose – stilistinių profilių diegimas (taisyklės, apibrėžiančios teksto stiliaus vadovą, pvz., „nerašykite pvz., o rašykite visą formą“), žodyno išplėtimas ir vartotojo sąsajos tobulinimas (ypač, norime suteikti vartotojui galimybę ne tik ignoruoti žodį, bet ir įtraukti jį į žodyną, nurodant kalbos dalį).
Šaltinis: www.habr.com