Vi fortsetter å snakke om prosjektene til vårens hackathon DevDays, der studenter ved masterprogrammet deltok .
Vi vil forresten invitere lesere til å være med . I den vil vi publisere siste nytt om rekruttering og studier. En video fra åpen dag finner du også i gruppa. Vi minner deg om: arrangementet finner sted 29. april, detaljer .
Telegram Desktop Voice Message Parser
Ideforfatter
Khoroshev Artyom
Kommandostruktur
Khoroshev Artem – prosjektleder/utvikler/QA
Eliseev Anton – forretningsanalytiker/markedsføringsspesialist
Maria Kuklina – UI designer/utvikler
Bakhvalov Pavel – UI designer/utvikler/QA
Fra vårt synspunkt er Telegram en moderne og praktisk messenger, og PC-versjonen er populær og åpen kildekode, noe som gjør det mulig å endre den. Klienten tilbyr ganske rik funksjonalitet. I tillegg til standard tekstmeldinger, inneholder den taleanrop, videomeldinger og talemeldinger. Og det er sistnevnte som noen ganger bringer ulemper for mottakeren. Det er ofte ikke mulig å lytte til en talemelding mens du er på en datamaskin eller bærbar datamaskin. Det kan være omgivelsesstøy, mangel på hodetelefoner, eller du vil ikke at noen skal høre innholdet i meldingen. Slike problemer oppstår nesten aldri hvis du bruker Telegram på en smarttelefon, fordi du ganske enkelt kan ta den til øret, i motsetning til en bærbar PC eller PC. Vi prøvde å løse dette problemet.
Målet med prosjektet vårt på DevDays var å legge til muligheten til å oversette mottatte talemeldinger til tekst til Telegram-skrivebordsklienten (heretter referert til som Telegram Desktop).
Alle analoger for øyeblikket er roboter som du kan sende en lydmelding til og motta en tekst som svar. Vi er ikke veldig fornøyd med dette: å videresende en melding til en bot er ikke veldig praktisk; vi vil gjerne ha innebygd funksjonalitet. I tillegg er enhver bot en tredjepart som fungerer som en mellommann mellom talegjenkjennings-API og brukeren, og dette er i det minste utrygt.
Som nevnt tidligere, har telegram-desktop to betydelige fordeler: enkelhet og hastighet. Og dette er ingen tilfeldighet, for det er skrevet helt i C++. Og siden vi bestemte oss for å legge til ny funksjonalitet direkte til klienten, måtte vi utvikle den i C++.
Det var 4 personer i teamet vårt. Opprinnelig søkte to personer etter et passende bibliotek for talegjenkjenning, en person studerte kildekoden til Telegram-desktop, en annen implementerte byggeprosjektet . Senere var alle opptatt med å fikse brukergrensesnittet og feilsøke.
Det så ut til at det ikke ville være vanskelig å implementere den tiltenkte funksjonaliteten, men som alltid oppsto vanskeligheter.
Løsningen på problemet besto av to uavhengige deloppgaver: å velge et passende talegjenkjenningsverktøy og implementere et brukergrensesnitt for ny funksjonalitet.
Da vi valgte et bibliotek for stemmegjenkjenning, måtte vi umiddelbart forlate alle offline APIer, fordi språkmodeller tar opp mye plass. Men vi snakker kun om ett språk. Det ble klart at vi måtte bruke online API. Senere viste det seg at talegjenkjenningstjenestene til slike giganter som Google, Yandex og Microsoft slett ikke er gratis, og vi må nøye oss med en prøveperiode. Som et resultat ble Google Speech-To-Text valgt fordi det lar deg få et token for bruk av tjenesten, som vil vare i et helt år.
Det andre problemet vi møtte er relatert til noen av manglene til C++ - en dyrehage med forskjellige biblioteker i fravær av et sentralisert depot. Det har seg slik at Telegram Desktop er avhengig av mange andre versjonsspesifikke biblioteker. Det offisielle depotet har for å sette sammen prosjektet. Og også en lang rekke åpne saker om byggeproblemer, for eksempel и . Alle problemene viste seg å være relatert til det faktum at byggeskriptet ble skrevet for Ubuntu 14.04, og for å kunne bygge telegram under Ubuntu 18.04, måtte endringer gjøres.
Selve Telegram Desktop tar ganske lang tid å montere: på en bærbar PC med en Intel Core i5-7200U tar komplett montering (flagg -j 4) med alle avhengigheter omtrent tre timer. Av disse tar ca. 30 minutter ved å lenke selve klienten (senere viste det seg at i Debug-konfigurasjonen tar koblingen ca. 10 minutter), men koblingsstadiet må gjentas hver gang etter endringer.
Til tross for problemene klarte vi å implementere den unnfangede ideen, samt oppdatere for Ubuntu 18.04. En demonstrasjon av arbeidet kan sees på . Vi inkluderer også flere animasjoner. En knapp har dukket opp ved siden av alle talemeldinger, slik at du kan oversette meldingen til tekst. Ved å høyreklikke kan du i tillegg spesifisere språket som skal brukes til kringkasting. Av klient tilgjengelig for nedlasting.
Etter vår mening viste det seg å være et godt Proof of Concept av funksjonalitet som ville være praktisk for mange brukere. Vi håper å se det i fremtidige utgivelser av Telegram Desktop.
Forbedret støtte for naturlig språk i IntelliJ IDEA
Ideforfatter
Tankov Vladislav
Kommandostruktur
Tankov Vladislav (teamleder, jobber med LanguageTool og IntelliJ IDEA)
Nikita Sokolov (jobber med LanguageTool og lager brukergrensesnitt)
Khvorov Alexander (jobber med LanguageTool og optimaliserer ytelsen)
Sadovnikov Alexander (støtte for parsing av markeringsspråk og kode)
Vi har utviklet en plugin for IntelliJ IDEA som sjekker ulike tekster (kommentarer og dokumentasjon, bokstavelige linjer i kode, tekst formatert i Markdown eller XML-oppmerking) for grammatisk, staving og stilistisk nøyaktighet (på engelsk kalles dette korrekturlesing).
Ideen med prosjektet var å utvide standard stavekontrollen IntelliJ IDEA til skalaen til Grammarly, for å lage en slags Grammarly inne i IDE.
Du kan se hva som skjedde .
Vel, nedenfor vil vi snakke mer detaljert om funksjonene til pluginet, samt vanskelighetene som oppsto under opprettelsen.
Motivasjon
Det finnes mange produkter designet for å skrive tekst på naturlige språk, men dokumentasjon og kodekommentarer skrives oftest i utviklingsmiljøer. Samtidig gjør IDEer en utmerket jobb med å finne feil i kode, men egner seg dårlig for tekster på naturlige språk. Dette gjør det veldig enkelt å gjøre feil i grammatikk, tegnsetting eller stil uten at utviklingsmiljøet påpeker dem. Det er mest kritisk å gjøre en feil når du skriver brukergrensesnittet, siden dette vil påvirke ikke bare forståeligheten av koden, men også brukerne av den utviklede applikasjonen selv.
Et av de mest populære og utviklede utviklingsmiljøene er IntelliJ IDEA, samt IDE-er basert på IntelliJ-plattformen. IntelliJ Platform har allerede en innebygd stavekontroll, men den kvitter seg ikke med selv de enkleste grammatiske feilene. Vi bestemte oss for å integrere et av de populære analysesystemene for naturlig språk i IntelliJ IDEA.
implementering
Vi satte oss ikke som oppgave å lage vårt eget tekstverifiseringssystem, så vi brukte en eksisterende løsning. Det mest passende alternativet viste seg å være . Lisensen tillot oss å fritt bruke den til våre formål: den er gratis, skrevet i Java og åpen kildekode. I tillegg støtter den 25 språk og har vært under utvikling i mer enn femten år. Til tross for sin åpenhet, er LanguageTool en seriøs konkurrent til betalte tekstverifiseringsløsninger, og det faktum at det kan fungere lokalt er bokstavelig talt dens morderfunksjon.
Plugin-koden er inne . Hele prosjektet ble skrevet i Kotlin med et lite tillegg av Java for brukergrensesnittet. Under hackathonet klarte vi å implementere støtte for Markdown, JavaDoc, HTML og Plain Text. Etter hackathonet la en stor oppdatering til støtte for XML, strenge bokstaver i Java, Kotlin og Python, og stavekontroll.
vanskeligheter
Ganske raskt innså vi at hvis vi mater all teksten til LanguageTool for inspeksjon hver gang, så vil IDEA-grensesnittet fryse på mer eller mindre seriøs tekst, siden inspeksjonen i seg selv blokkerer UI-flyten. Problemet ble løst gjennom `ProgressManager.checkCancelled`-sjekken - denne funksjonen gir et unntak hvis IDEA mener at det er på tide å avbryte inspeksjonen.
Dette eliminerte fullstendig frysingene, men det er umulig å bruke: teksten tar veldig lang tid å behandle. Dessuten, i vårt tilfelle, endres oftest en veldig liten del av teksten, og vi ønsker å cache resultatene på en eller annen måte. Det var akkurat det vi gjorde. For ikke å sjekke alt hver gang, delte vi deterministisk opp teksten i biter og sjekket kun de som var endret. Siden tekstene kan være store og vi ikke ønsket å laste cachen, lagret vi ikke selve tekstene, men hashen. Dette gjorde at plugin-en kunne fungere jevnt selv på store filer.
LanguageTool støtter mer enn 25 språk, men det er usannsynlig at noen bruker trenger dem alle. Jeg ønsket å gi muligheten til å laste ned biblioteker for et spesifikt språk på forespørsel (hvis du krysser av i brukergrensesnittet). Vi implementerte til og med dette, men det viste seg å være for komplisert og upålitelig. Spesielt måtte vi laste LanguageTool med et nytt sett med språk ved å bruke en separat klasselaster, og deretter initialisere den forsiktig. Samtidig var alle bibliotekene i et bruker-.m2-depot, og ved hver start måtte vi sjekke integriteten deres. Til slutt bestemte vi oss for at hvis brukere hadde problemer med størrelsen på pluginet, så ville vi tilby en egen plugin for flere av de mest populære språkene.
Etter hackathonet
Hackathonet ble avsluttet, men arbeidet med plugin fortsatte med et smalere team. Jeg ønsket å støtte strenger, kommentarer og til og med språkkonstruksjoner som variabel- og klassenavn. Foreløpig støttes dette kun for Java, Kotlin og Python, men vi håper denne listen vil vokse. Vi har fikset mange små feil og blitt mer kompatible med Ideas innebygde stavekontroll. I tillegg har XML-støtte og stavekontroll dukket opp. Alt dette finner du i den andre versjonen, som vi nylig publiserte.
Hva blir det neste?
En slik plugin kan være nyttig ikke bare for utviklere, men også for tekniske forfattere (som ofte jobber for eksempel med XML i en IDE). Hver dag må de jobbe med naturlig språk, uten å ha en assistent i form av redaktørtips om mulige feil. Vår plugin gir slike hint og gjør det med høy grad av nøyaktighet.
Vi planlegger å utvikle plugin, både ved å legge til nye språk og ved å utforske en generell tilnærming til organisering av tekstsjekking. Våre umiddelbare planer inkluderer implementering av stilistiske profiler (sett med regler som definerer en stilguide for tekst, for eksempel "ikke skriv f.eks, men skriv hele skjemaet"), utvide ordboken og forbedre brukergrensesnittet (spesielt, vi ønsker å gi brukeren muligheten til ikke bare å ignorere et ord, men å legge det til i ordboken, som indikerer orddelen).
Kilde: www.habr.com