Vi fortsätter att prata om projekten från vårens hackathon DevDays, där studenter på masterprogrammet deltog .
Vi vill förresten bjuda in läsare att vara med . I den kommer vi att publicera de senaste nyheterna om rekrytering och studier. En video från den öppna dagen finns också i gruppen. Vi påminner dig: evenemanget kommer att äga rum den 29 april, detaljer .
Telegram Desktop Voice Message Parser
Idéns författare
Khoroshev Artyom
Lagkomposition
Khoroshev Artem – projektledare/utvecklare/QA
Eliseev Anton – affärsanalytiker/marknadsspecialist
Maria Kuklina – UI designer/utvecklare
Bakhvalov Pavel – UI-designer/utvecklare/QA
Ur vår synvinkel är Telegram en modern och bekväm budbärare, och dess PC-version är populär och öppen källkod, vilket gör det möjligt att ändra den. Klienten erbjuder ganska rik funktionalitet. Förutom vanliga textmeddelanden innehåller den röstsamtal, videomeddelanden och röstmeddelanden. Och det är de sistnämnda som ibland medför olägenheter för sin mottagare. Det är ofta inte möjligt att lyssna på ett röstmeddelande när du sitter vid en dator eller bärbar dator. Det kan finnas omgivningsljud, brist på hörlurar eller så vill du inte att någon ska höra innehållet i meddelandet. Sådana problem uppstår nästan aldrig om du använder Telegram på en smartphone, eftersom du helt enkelt kan ta den till örat, till skillnad från en bärbar dator eller PC. Vi försökte lösa detta problem.
Målet med vårt projekt på DevDays var att lägga till möjligheten att översätta mottagna röstmeddelanden till text till Telegram-skrivbordsklienten (nedan kallad Telegram Desktop).
Alla analoger för tillfället är bots som du kan skicka ett ljudmeddelande till och få ett textmeddelande till som svar. Vi är inte särskilt nöjda med detta: att vidarebefordra ett meddelande till en bot är inte särskilt bekvämt, vi skulle vilja ha inbyggd funktionalitet. Dessutom är varje bot en tredje part som fungerar som en mellanhand mellan taligenkännings-API:t och användaren, och detta är åtminstone osäkert.
Som nämnts tidigare har telegram-desktop två betydande fördelar: enkel och snabb drift. Och detta är ingen slump, eftersom det är skrivet helt i C++. Och eftersom vi bestämde oss för att lägga till ny funktionalitet direkt till klienten var vi tvungna att utveckla den i C++.
Det var 4 personer i vårt team. Inledningsvis letade två personer efter ett lämpligt bibliotek för taligenkänning, en person studerade källkoden för Telegram-desktop, en annan implementerade byggprojektet . Senare var alla upptagna med att fixa användargränssnittet och felsöka.
Det verkade som att det inte skulle vara svårt att implementera den avsedda funktionen, men som alltid uppstod svårigheter.
Lösningen på problemet bestod av två oberoende deluppgifter: att välja ett lämpligt taligenkänningsverktyg och att implementera ett användargränssnitt för ny funktionalitet.
När vi valde ett bibliotek för röstigenkänning var vi omedelbart tvungna att överge alla offline-API:er, eftersom språkmodeller tar upp mycket utrymme. Men vi pratar bara om ett språk. Det blev klart att vi skulle behöva använda online-API:et. Senare visade det sig att taligenkänningstjänsterna från sådana jättar som Google, Yandex och Microsoft inte alls är gratis, och vi måste nöja oss med en provperiod. Som ett resultat valdes Google Speech-To-Text eftersom det låter dig få en token för att använda tjänsten, som kommer att pågå i ett helt år.
Det andra problemet vi stötte på är relaterat till några av bristerna i C++ - en djurpark med olika bibliotek i frånvaro av ett centraliserat arkiv. Det råkar vara så att Telegram Desktop är beroende av många andra versionsspecifika bibliotek. Det officiella arkivet har för att montera projektet. Och även ett stort antal öppna frågor om byggproblem, till exempel и . Alla problem visade sig vara relaterade till det faktum att byggskriptet skrevs för Ubuntu 14.04, och för att framgångsrikt bygga telegram under Ubuntu 18.04 var det nödvändigt att göra ändringar.
Själva Telegram Desktop tar ganska lång tid att montera: på en bärbar dator med en Intel Core i5-7200U tar en komplett montering (flagga -j 4) med alla beroenden cirka tre timmar. Av dessa tar cirka 30 minuter genom att länka själva klienten (senare visade det sig att i Debug-konfigurationen tar länkningen cirka 10 minuter), och ändå måste länkningssteget upprepas varje gång efter ändringar.
Trots problemen lyckades vi implementera den tänkta idén, samt uppdatera för Ubuntu 18.04. En demonstration av arbetet kan ses på . Vi inkluderar även flera animationer. En knapp har dykt upp bredvid alla röstmeddelanden, så att du kan översätta meddelandet till text. Genom att högerklicka kan du dessutom ange vilket språk som ska användas för sändning. Förbi klient tillgänglig för nedladdning.
Enligt vår åsikt visade det sig vara ett bra Proof of Concept av funktionalitet som skulle vara bekvämt för många användare. Vi hoppas få se det i framtida versioner av Telegram Desktop.
Förbättrat stöd för naturligt språk i IntelliJ IDEA
Idéns författare
Tankov Vladislav
Lagkomposition
Tankov Vladislav (teamledare, arbetar med LanguageTool och IntelliJ IDEA)
Nikita Sokolov (arbetar med LanguageTool och skapar användargränssnitt)
Khvorov Alexander (arbetar med LanguageTool och optimerar prestanda)
Sadovnikov Alexander (stöd för att analysera märkningsspråk och kod)
Vi har utvecklat ett plugin för IntelliJ IDEA som kontrollerar olika texter (kommentarer och dokumentation, bokstavliga rader i kod, text formaterad i Markdown eller XML-uppmärkning) för grammatisk, stavning och stilistisk noggrannhet (på engelska kallas detta korrekturläsning).
Tanken med projektet var att utöka standardstavningskontrollen IntelliJ IDEA till grammatikens skala, för att göra en sorts grammatik inuti IDE.
Du kan se vad som hände .
Tja, nedan kommer vi att prata mer i detalj om pluginens funktioner, såväl som de svårigheter som uppstod under dess skapelse.
Motivation
Det finns många produkter designade för att skriva text på naturliga språk, men dokumentation och kodkommentarer skrivs oftast i utvecklingsmiljöer. Samtidigt gör IDE ett utmärkt jobb med att hitta fel i kod, men lämpar sig dåligt för texter på naturliga språk. Detta gör det mycket lätt att göra misstag i grammatik, skiljetecken eller stil utan att utvecklingsmiljön påpekar dem. Det är mycket viktigt att göra ett misstag när du skriver användargränssnittet, eftersom detta kommer att påverka inte bara förståelsen av koden, utan också användarna av den utvecklade applikationen själva.
En av de mest populära och utvecklade utvecklingsmiljöerna är IntelliJ IDEA, samt IDE baserade på IntelliJ-plattformen. IntelliJ Platform har redan en inbyggd stavningskontroll, men den blir inte av med ens de enklaste grammatiska felen. Vi bestämde oss för att integrera ett av de populära analyssystemen för naturligt språk i IntelliJ IDEA.
genomförande
Vi satte inte oss som uppgift att skapa vårt eget textverifieringssystem, så vi använde en befintlig lösning. Det mest lämpliga alternativet visade sig vara . Licensen tillät oss att fritt använda den för våra syften: den är gratis, skriven i Java och öppen källkod. Dessutom stöder den 25 språk och har varit under utveckling i mer än femton år. Trots sin öppenhet är LanguageTool en seriös konkurrent till betalda textverifieringslösningar, och det faktum att det kan fungera lokalt är bokstavligen dess mördande funktion.
Pluginkoden finns i . Hela projektet skrevs i Kotlin med ett litet tillägg av Java för UI. Under hackathonet lyckades vi implementera stöd för Markdown, JavaDoc, HTML och Plain Text. Efter hackathonet lade en stor uppdatering till stöd för XML, bokstavssträngar i Java, Kotlin och Python och stavningskontroll.
Svårigheter
Ganska snabbt insåg vi att om vi matar all text till LanguageTool för granskning varje gång, så kommer IDEA-gränssnittet att frysa på all mer eller mindre allvarlig text, eftersom själva inspektionen blockerar UI-flödet. Problemet löstes genom kontrollen `ProgressManager.checkCancelled` - den här funktionen ger ett undantag om IDEA anser att det är dags att avbryta inspektionen.
Detta eliminerade helt frysningarna, men det är omöjligt att använda: texten tar väldigt lång tid att bearbeta. I vårt fall ändras dessutom oftast en mycket liten del av texten och vi vill cachelagra resultaten på något sätt. Det var precis vad vi gjorde. För att inte kontrollera allt varje gång delade vi deterministiskt upp texten i bitar och kontrollerade bara de som hade ändrats. Eftersom texterna kan vara stora och vi inte ville ladda cachen, lagrade vi inte själva texterna utan deras hash. Detta gjorde att plugin-programmet fungerade smidigt även på stora filer.
LanguageTool stöder mer än 25 språk, men det är osannolikt att någon användare behöver dem alla. Jag ville ge möjlighet att ladda ner bibliotek för ett specifikt språk på begäran (om du kryssar för det i UI). Vi implementerade till och med detta, men det visade sig vara för komplicerat och opålitligt. I synnerhet var vi tvungna att ladda LanguageTool med en ny uppsättning språk med en separat klassladdare och sedan försiktigt initiera den. Samtidigt fanns alla bibliotek i ett användar-.m2-förråd, och vid varje start var vi tvungna att kontrollera deras integritet. Till slut bestämde vi oss för att om användarna hade problem med storleken på pluginet så skulle vi tillhandahålla en separat plugin för flera av de mest populära språken.
Efter hackathon
Hackathonet avslutades, men arbetet med plugin fortsatte med ett smalare team. Jag ville stödja strängar, kommentarer och till och med språkkonstruktioner som variabel- och klassnamn. För närvarande stöds detta endast för Java, Kotlin och Python, men vi hoppas att den här listan kommer att växa. Vi har fixat många små buggar och blivit mer kompatibla med Ideas inbyggda stavningskontroll. Dessutom har XML-stöd och stavningskontroll dykt upp. Allt detta finns i den andra versionen, som vi publicerade nyligen.
Vad händer nu?
En sådan plugin kan vara användbar inte bara för utvecklare, utan också för tekniska skribenter (som ofta arbetar till exempel med XML i en IDE). Varje dag får de jobba med naturligt språk, utan att ha en assistent i form av redaktörstips om eventuella fel. Vårt plugin ger sådana tips och gör det med en hög grad av noggrannhet.
Vi planerar att utveckla plugin, både genom att lägga till nya språk och genom att utforska ett allmänt tillvägagångssätt för att organisera textkontroll. Våra omedelbara planer inkluderar implementering av stilistiska profiler (uppsättningar av regler som definierar en stilguide för text, till exempel "skriv inte t.ex. utan skriv hela formuläret"), utöka ordboken och förbättra användargränssnittet (i synnerhet, vi vill ge användaren möjligheten att inte bara ignorera ett ord, utan att lägga till det i ordboken, vilket indikerar orddelen).
Källa: www.habr.com