Vi fortsætter med at tale om projekterne fra forårets hackathon DevDays, hvor studerende på kandidatuddannelsen deltog .
Vi vil i øvrigt gerne invitere læserne til at være med . I den vil vi offentliggøre de seneste nyheder om rekruttering og studier. En video fra åbent dagen kan også findes i gruppen. Vi minder dig om: begivenheden finder sted den 29. april, detaljer .
Telegram Desktop Voice Message Parser
Idéforfatter
Khoroshev Artyom
Stå på række
Khoroshev Artem – projektleder/udvikler/QA
Eliseev Anton – forretningsanalytiker/marketingspecialist
Maria Kuklina – UI designer/udvikler
Bakhvalov Pavel – UI designer/udvikler/QA
Fra vores synspunkt er Telegram en moderne og bekvem messenger, og dens pc-version er populær og open source, hvilket gør det muligt at ændre den. Klienten tilbyder ret rig funktionalitet. Ud over standardtekstbeskeder indeholder den taleopkald, videobeskeder og talebeskeder. Og det er sidstnævnte, der nogle gange medfører besvær for deres modtager. Det er ofte ikke muligt at lytte til en talebesked, mens du er ved en computer eller bærbar. Der kan være omgivende støj, mangel på høretelefoner, eller du ønsker ikke, at nogen skal høre indholdet af beskeden. Sådanne problemer opstår næsten aldrig, hvis du bruger Telegram på en smartphone, fordi du blot kan bringe det til øret, i modsætning til en bærbar eller pc. Vi forsøgte at løse dette problem.
Målet med vores projekt på DevDays var at tilføje muligheden for at oversætte modtagne talebeskeder til tekst til Telegram desktop-klienten (herefter benævnt Telegram Desktop).
Alle analoger i øjeblikket er bots, som du kan sende en lydbesked til og modtage en tekst som svar på. Vi er ikke særlig tilfredse med dette: videresendelse af en besked til en bot er ikke særlig praktisk; vi vil gerne have indbygget funktionalitet. Derudover er enhver bot en tredjepart, der fungerer som mellemled mellem talegenkendelses-API'en og brugeren, og dette er som minimum usikkert.
Som tidligere nævnt har telegram-desktop to væsentlige fordele: nem og hastighed af betjeningen. Og det er ikke tilfældigt, for det er skrevet helt i C++. Og da vi besluttede at tilføje ny funktionalitet direkte til klienten, var vi nødt til at udvikle den i C++.
Der var 4 personer i vores team. Til at begynde med søgte to personer efter et passende bibliotek til talegenkendelse, en person studerede kildekoden til Telegram-desktop, en anden implementerede byggeprojektet . Senere havde alle travlt med at rette brugergrænsefladen og fejlfinde.
Det så ud til, at implementeringen af den tilsigtede funktionalitet ikke ville være vanskelig, men som det altid sker, opstod der vanskeligheder.
Løsningen på problemet bestod af to uafhængige underopgaver: at vælge et passende talegenkendelsesværktøj og implementere en brugergrænseflade til ny funktionalitet.
Da vi valgte et bibliotek til stemmegenkendelse, måtte vi straks opgive alle offline API'er, fordi sprogmodeller fylder meget. Men vi taler kun om ét sprog. Det blev klart, at vi skulle bruge online API. Senere viste det sig, at talegenkendelsestjenesterne fra sådanne giganter som Google, Yandex og Microsoft slet ikke er gratis, og vi bliver nødt til at nøjes med en prøveperiode. Som et resultat blev Google Speech-To-Text valgt, fordi det giver dig mulighed for at få et token for at bruge tjenesten, som vil vare i et helt år.
Det andet problem, vi stødte på, er relateret til nogle af manglerne ved C++ - en zoologisk have med forskellige biblioteker i mangel af et centraliseret lager. Det sker, at Telegram Desktop afhænger af mange andre versionsspecifikke biblioteker. Det officielle arkiv har til at samle projektet. Og også en lang række åbne spørgsmål om byggeproblemer, f.eks и . Alle problemerne viste sig at være relateret til det faktum, at build-scriptet blev skrevet til Ubuntu 14.04, og for at kunne bygge telegram under Ubuntu 18.04, skulle der foretages ændringer.
Selve Telegram Desktop tager ret lang tid at samle: på en bærbar computer med en Intel Core i5-7200U tager en komplet samling (flag -j 4) med alle afhængigheder omkring tre timer. Af disse tages omkring 30 minutter ved at linke selve klienten (senere viste det sig, at i Debug-konfigurationen tager linking omkring 10 minutter), og alligevel skal linkningsstadiet gentages hver gang efter ændringer.
På trods af problemerne lykkedes det at implementere den udtænkte idé, samt opdatere til Ubuntu 18.04. En demonstration af arbejdet kan ses kl . Vi inkluderer også flere animationer. Der er vist en knap ud for alle talebeskeder, så du kan oversætte beskeden til tekst. Ved at højreklikke kan du desuden angive det sprog, der skal bruges til udsendelse. Ved klient tilgængelig til download.
Efter vores mening viste det sig at være et godt Proof of Concept af funktionalitet, der ville være praktisk for mange brugere. Vi håber at se det i fremtidige udgivelser af Telegram Desktop.
Forbedret understøttelse af naturligt sprog i IntelliJ IDEA
Idéforfatter
Tankov Vladislav
Stå på række
Tankov Vladislav (teamleder, arbejder med LanguageTool og IntelliJ IDEA)
Nikita Sokolov (arbejder med LanguageTool og skaber brugergrænseflade)
Khvorov Alexander (arbejder med LanguageTool og optimerer ydeevnen)
Sadovnikov Alexander (understøttelse af parsing af markup-sprog og kode)
Vi har udviklet et plugin til IntelliJ IDEA, der tjekker forskellige tekster (kommentarer og dokumentation, bogstavelige linjer i kode, tekst formateret i Markdown eller XML-markering) for grammatisk, stavning og stilistisk nøjagtighed (på engelsk kaldes dette korrekturlæsning).
Ideen med projektet var at udvide standard stavekontrollen IntelliJ IDEA til grammatisk skala for at lave en slags grammatik inde i IDE.
Du kan se, hvad der skete .
Nå, nedenfor vil vi tale mere detaljeret om plugin'ets muligheder såvel som de vanskeligheder, der opstod under oprettelsen.
Motivation
Der er mange produkter designet til at skrive tekst på naturlige sprog, men dokumentation og kodekommentarer er oftest skrevet i udviklingsmiljøer. Samtidig gør IDE'er et fremragende stykke arbejde med at finde fejl i kode, men er dårligt egnet til tekster på naturlige sprog. Dette gør det meget nemt at lave fejl i grammatik, tegnsætning eller stil, uden at udviklingsmiljøet påpeger dem. Det er mest kritisk at lave en fejl ved at skrive brugergrænsefladen, da dette ikke kun vil påvirke kodens forståelighed, men også brugerne af den udviklede applikation selv.
Et af de mest populære og udviklede udviklingsmiljøer er IntelliJ IDEA, samt IDE'er baseret på IntelliJ-platformen. IntelliJ Platform har allerede en indbygget stavekontrol, men den slipper ikke for selv de simpleste grammatiske fejl. Vi besluttede at integrere et af de populære naturlige sproganalysesystemer i IntelliJ IDEA.
implementering
Vi har ikke sat os selv til opgave at skabe vores eget tekstbekræftelsessystem, så vi brugte en eksisterende løsning. Den mest passende mulighed viste sig at være . Licensen gav os mulighed for frit at bruge den til vores formål: den er gratis, skrevet i Java og open source. Derudover understøtter den 25 sprog og har været under udvikling i mere end femten år. På trods af sin åbenhed er LanguageTool en seriøs konkurrent til betalte tekstbekræftelsesløsninger, og det faktum, at det kan fungere lokalt, er bogstaveligt talt dets dræberfunktion.
Plugin-koden er inde . Hele projektet blev skrevet i Kotlin med en lille tilføjelse af Java til brugergrænsefladen. Under hackathonet lykkedes det os at implementere understøttelse af Markdown, JavaDoc, HTML og almindelig tekst. Efter hackathonet tilføjede en større opdatering understøttelse af XML, strenge bogstaver i Java, Kotlin og Python og stavekontrol.
vanskeligheder
Ret hurtigt indså vi, at hvis vi sender al teksten til LanguageTool til inspektion hver gang, så vil IDEA-grænsefladen fryse fast på enhver mere eller mindre seriøs tekst, da selve inspektionen blokerer for UI-flowet. Problemet blev løst gennem `ProgressManager.checkCancelled` check - denne funktion kaster en undtagelse, hvis IDEA mener, at det er på tide at afbryde inspektionen.
Dette eliminerede fuldstændigt fryserne, men det er umuligt at bruge: teksten tager meget lang tid at behandle. Desuden ændres i vores tilfælde oftest en meget lille del af teksten, og vi ønsker at cache resultaterne på en eller anden måde. Det var præcis, hvad vi gjorde. For ikke at kontrollere alt hver gang, delte vi deterministisk teksten i stykker og tjekkede kun dem, der var ændret. Da teksterne kan være store, og vi ikke ønskede at indlæse cachen, gemte vi ikke selve teksterne, men deres hashes. Dette gjorde det muligt for plugin'et at fungere problemfrit selv på store filer.
LanguageTool understøtter mere end 25 sprog, men det er usandsynligt, at nogen bruger har brug for dem alle. Jeg ønskede at give mulighed for at downloade biblioteker til et bestemt sprog efter anmodning (hvis du afkrydser det i brugergrænsefladen). Vi implementerede endda dette, men det viste sig at være for kompliceret og upålideligt. Især var vi nødt til at indlæse LanguageTool med et nyt sæt sprog ved hjælp af en separat klasseindlæser og derefter omhyggeligt initialisere det. Samtidig var alle bibliotekerne i et bruger .m2 repository, og ved hver start skulle vi tjekke deres integritet. Til sidst besluttede vi, at hvis brugerne havde problemer med størrelsen af plugin'et, så ville vi levere et separat plugin til flere af de mest populære sprog.
Efter hackathon
Hackathonet sluttede, men arbejdet med plugin'et fortsatte med et smallere hold. Jeg ønskede at understøtte strenge, kommentarer og endda sprogkonstruktioner såsom variabel- og klassenavne. I øjeblikket understøttes dette kun for Java, Kotlin og Python, men vi håber, at denne liste vil vokse. Vi har rettet en masse små fejl og er blevet mere kompatible med Ideas indbyggede stavekontrol. Derudover er XML-understøttelse og stavekontrol dukket op. Alt dette kan findes i den anden version, som vi udgav for nylig.
Hvad er det næste?
Et sådant plugin kan ikke kun være nyttigt for udviklere, men også for tekniske forfattere (ofte arbejder f.eks. med XML i en IDE). Hver dag skal de arbejde med naturligt sprog, uden at have en assistent i form af redaktørtips om mulige fejl. Vores plugin giver sådanne hints og gør det med en høj grad af nøjagtighed.
Vi planlægger at udvikle pluginnet, både ved at tilføje nye sprog og ved at udforske en generel tilgang til organisering af tekstkontrol. Vores umiddelbare planer omfatter implementering af stilistiske profiler (sæt af regler, der definerer en stilvejledning til tekst, f.eks. "skriv ikke f.eks., men skriv den fulde formular"), udvidelse af ordbogen og forbedring af brugergrænsefladen (især, vi ønsker at give brugeren mulighed for ikke bare at ignorere et ord, men at tilføje det i ordbogen, hvilket angiver orddelen).
Kilde: www.habr.com