Továbbra is szót ejtünk a tavaszi DevDays hackathon projektjeiről, amelyekben a mesterképzés hallgatói vettek részt .
Ezúton szeretnénk felkérni az olvasókat, hogy csatlakozzanak . Ebben közöljük a legfrissebb híreket a toborzásról és a tanulásról. A nyílt napról készült videó is megtalálható a csoportban. Emlékeztetünk: az esemény április 29-én lesz, részletek .
Telegram asztali hangüzenet-elemző
Az ötlet szerzője
Horosev Artyom
Felsorakozni
Khoroshev Artem – projektmenedzser/fejlesztő/QA
Eliseev Anton – üzleti elemző/marketing specialista
Maria Kuklina – UI tervező/fejlesztő
Bakhvalov Pavel – UI tervező/fejlesztő/QA
A mi szempontunkból a Telegram egy modern és kényelmes messenger, PC-s változata népszerű és nyílt forráskódú, ami lehetővé teszi a módosítását. Az ügyfél meglehetősen gazdag funkcionalitást kínál. A normál szöveges üzeneteken kívül hanghívásokat, videoüzeneteket és hangüzeneteket is tartalmaz. És ez utóbbiak néha kellemetlenséget okoznak a címzettnek. Gyakran nem lehet meghallgatni egy hangüzenetet számítógépen vagy laptopon. Előfordulhat környezeti zaj, fejhallgató hiánya, vagy nem szeretné, hogy bárki meghallja az üzenet tartalmát. Ilyen problémák szinte soha nem merülnek fel, ha a Telegramot okostelefonon használja, mert egyszerűen a füléhez viheti, ellentétben a laptopokkal vagy a számítógépekkel. Megpróbáltuk megoldani ezt a problémát.
A DevDays projektünk célja az volt, hogy a beérkezett hangüzeneteket szöveggé lefordítsuk a Telegram asztali kliensbe (a továbbiakban Telegram Desktop).
Jelenleg minden analóg bot, amelyre hangüzenetet küldhet, és válaszként szöveget kaphat. Ezzel nem nagyon vagyunk elégedettek: az üzenet botnak való továbbítása nem túl kényelmes, natív funkciókat szeretnénk. Ezenkívül minden bot egy harmadik fél, amely közvetítőként működik a beszédfelismerő API és a felhasználó között, és ez legalább nem biztonságos.
Mint korábban említettük, a telegram-desktopnak két jelentős előnye van: a könnyű és gyors működés. És ez nem véletlen, mert teljes egészében C++ nyelven van megírva. És mivel úgy döntöttünk, hogy új funkciókat adunk közvetlenül az ügyfélhez, ezt C++-ban kellett fejlesztenünk.
A csapatunkban 4 fő volt. Kezdetben ketten kerestek megfelelő könyvtárat a beszédfelismeréshez, egy személy a Telegram-desktop forráskódját tanulmányozta, egy másik pedig a build projektet telepítette. . Később mindenki a felhasználói felület javításával és a hibakereséssel volt elfoglalva.
Úgy tűnt, hogy a tervezett funkcionalitás megvalósítása nem lesz nehéz, de mint mindig, most is felmerültek nehézségek.
A probléma megoldása két független részfeladatból állt: egy megfelelő beszédfelismerő eszköz kiválasztásából és egy felhasználói felület megvalósításából az új funkciókhoz.
A hangfelismerő könyvtár kiválasztásakor azonnal le kellett mondanunk minden offline API-ról, mert a nyelvi modellek sok helyet foglalnak el. De csak egy nyelvről beszélünk. Világossá vált, hogy az online API-t kell használnunk. Később kiderült, hogy az olyan óriáscégek beszédfelismerő szolgáltatásai, mint a Google, a Yandex és a Microsoft egyáltalán nem ingyenesek, és meg kell elégednünk a próbaidőszakkal. Ennek eredményeként a Google Speech-To-Textre esett a választás, mert ezzel egy teljes évig érvényes tokent kaphat a szolgáltatás használatához.
A második probléma, amellyel találkoztunk, a C++ néhány hiányosságával kapcsolatos – a különféle könyvtárak állatkertje központi tárhely hiányában. Előfordul, hogy a Telegram Desktop sok más verzióspecifikus könyvtártól függ. A hivatalos adattár rendelkezik a projekt összeállításához. És számos nyitott probléma például az összeállítási problémákkal kapcsolatban и . Kiderült, hogy minden probléma azzal kapcsolatos, hogy a build szkript Ubuntu 14.04-re íródott, és ahhoz, hogy a telegram sikeres legyen Ubuntu 18.04 alatt, változtatásokat kellett végrehajtani.
Maga a Telegram Desktop összeszerelése meglehetősen hosszú időt vesz igénybe: egy Intel Core i5-7200U laptopon a teljes összeszerelés (-j 4 jelző) minden függőséggel körülbelül három órát vesz igénybe. Ebből körülbelül 30 percet vesz igénybe magának a kliensnek a linkelése (később kiderült, hogy a Debug konfigurációban a linkelés kb. 10 percet vesz igénybe), de a linkelési szakaszt minden változtatás után meg kell ismételni.
A problémák ellenére sikerült megvalósítani a megfogant ötletet, valamint frissíteni Ubuntu 18.04-hez. A munka bemutatója megtekinthető a . Számos animációt is mellékelünk. Az összes hangüzenet mellett megjelenik egy gomb, amely lehetővé teszi az üzenet szöveggé fordítását. A jobb gombbal kattintva ezenkívül megadhatja a sugárzáshoz használt nyelvet. Által kliens letölthető.
Véleményünk szerint ez egy jó Proof of Concept funkcionalitásnak bizonyult, amely sok felhasználó számára kényelmes lenne. Reméljük, hogy a Telegram Desktop jövőbeni kiadásaiban is láthatjuk.
Továbbfejlesztett természetes nyelvi támogatás az IntelliJ IDEA-ban
Az ötlet szerzője
Tankov Vladislav
Felsorakozni
Tankov Vladislav (csapatvezető, a LanguageTool-lal és az IntelliJ IDEA-val dolgozik)
Nikita Szokolov (a LanguageTool-lal dolgozik és UI-t készít)
Khvorov Alexander (a LanguageTool-lal dolgozik és a teljesítményt optimalizálja)
Sadovnikov Alexander (a jelölőnyelvek és kódok elemzésének támogatása)
Kifejlesztettünk egy bővítményt az IntelliJ IDEA-hoz, amely ellenőrzi a különböző szövegek (megjegyzések és dokumentációk, szó szerinti sorok a kódban, Markdown-ban vagy XML-jelölésben formázott szöveg) nyelvtani, helyesírási és stilisztikai pontosságát (angolul ezt lektorálásnak hívják).
A projekt ötlete az volt, hogy az IntelliJ IDEA szabványos helyesírás-ellenőrzőjét a Grammarly méretére bővítsék, hogy egyfajta Grammarly-t készítsenek az IDE-n belül.
Láthatod, mi történt .
Nos, az alábbiakban részletesebben beszélünk a bővítmény képességeiről, valamint a létrehozása során felmerülő nehézségekről.
motiváció
Számos termék létezik természetes nyelvű szövegírásra, de a dokumentációt és a kód megjegyzéseit leggyakrabban fejlesztői környezetekben írják. Ugyanakkor az IDE-k kiváló munkát végeznek a kódhibák megtalálásában, de nem alkalmasak természetes nyelvű szövegekhez. Ez nagyon megkönnyíti a nyelvtani, írásjelek vagy stílusbeli hibák elkövetését anélkül, hogy a fejlesztői környezet rámutatna rájuk. A legkritikusabb a hibás felhasználói felület írása, mivel ez nemcsak a kód érthetőségét, hanem magukat a fejlesztett alkalmazás felhasználóit is befolyásolja.
Az egyik legnépszerűbb és legfejlettebb fejlesztőkörnyezet az IntelliJ IDEA, valamint az IntelliJ Platformon alapuló IDE-k. Az IntelliJ Platform már rendelkezik beépített helyesírás-ellenőrzővel, de a legegyszerűbb nyelvtani hibáktól sem szabadul meg. Úgy döntöttünk, hogy az egyik népszerű természetes nyelvelemző rendszert integráljuk az IntelliJ IDEA-ba.
Реализация
Nem tűztük ki magunk elé saját szövegellenőrző rendszer létrehozását, ezért egy meglévő megoldást alkalmaztunk. A legmegfelelőbb lehetőségnek bizonyult . A licenc lehetővé tette számunkra, hogy céljainkra szabadon felhasználhassuk: ingyenes, Java nyelven íródott és nyílt forráskódú. Ezenkívül 25 nyelvet támogat, és több mint tizenöt éve folyik a fejlesztés. Nyitottsága ellenére a LanguageTool komoly vetélytársa a fizetős szövegellenőrző megoldásoknak, és az a tény, hogy helyben is tud működni, a szó szoros értelmében gyilkos tulajdonsága.
A beépülő modul kódja benne van . Az egész projektet Kotlin nyelven írták, egy kis Java kiegészítéssel a felhasználói felülethez. A hackathon során sikerült megvalósítanunk Markdown, JavaDoc, HTML és Plain Text támogatását. A hackathon után egy jelentős frissítés támogatta az XML-t, a Java, Kotlin és Python nyelvű karakterláncokat, valamint a helyesírás-ellenőrzést.
Nehézségek
Elég hamar rájöttünk, hogy ha minden alkalommal betápláljuk az összes szöveget a LanguageTool-ba ellenőrzésre, akkor az IDEA felülete lefagy minden többé-kevésbé komoly szövegnél, mivel maga az ellenőrzés blokkolja a felhasználói felület áramlását. A probléma a `ProgressManager.checkCancelled` ellenőrzéssel megoldódott – ez a függvény kivételt dob, ha az IDEA úgy véli, hogy ideje megszakítani az ellenőrzést.
Ezzel teljesen megszűntek a lefagyások, de nem használható: a szöveg feldolgozása nagyon sokáig tart. Sőt, esetünkben a szövegnek leggyakrabban nagyon kis része változik, és az eredményeket valahogyan gyorsítótárba szeretnénk helyezni. Pontosan ezt tettük. Annak érdekében, hogy ne minden alkalommal ellenőrizzünk mindent, determinisztikusan darabokra bontottuk a szöveget, és csak azokat ellenőriztük, amelyek megváltoztak. Mivel a szövegek nagyok lehetnek, és nem akartuk betölteni a gyorsítótárat, ezért nem magukat a szövegeket tároltuk, hanem azok hash-ét. Ez lehetővé tette a plugin zökkenőmentes működését még nagy fájlokon is.
A LanguageTool több mint 25 nyelvet támogat, de nem valószínű, hogy egy felhasználónak mindegyikre szüksége van. Lehetőséget akartam adni arra, hogy kérésre letölthessünk egy adott nyelvhez tartozó könyvtárakat (ha bejelölöd a felhasználói felületen). Ezt meg is valósítottuk, de túl bonyolultnak és megbízhatatlannak bizonyult. Különösen a LanguageTool-t kellett betöltenünk egy új nyelvkészlettel egy külön osztálybetöltő segítségével, majd óvatosan inicializálnunk kellett. Ugyanakkor az összes könyvtár egy felhasználói .m2 tárolóban volt, és minden induláskor ellenőriznünk kellett az integritásukat. Végül úgy döntöttünk, hogy ha a felhasználóknak problémái vannak a bővítmény méretével, akkor több legnépszerűbb nyelvhez külön bővítményt biztosítunk.
A hackathon után
A hackathon véget ért, de a bővítményen végzett munka egy szűkebb csapattal folytatódott. Támogatni akartam a karakterláncokat, megjegyzéseket és még nyelvi konstrukciókat is, például változó- és osztályneveket. Jelenleg ez csak Java, Kotlin és Python esetén támogatott, de reméljük, hogy ez a lista bővülni fog. Sok apró hibát kijavítottunk, és jobban kompatibilisek lettünk az Idea beépített helyesírás-ellenőrzőjével. Emellett megjelent az XML támogatás és a helyesírás-ellenőrzés. Mindez megtalálható a második verzióban, amelyet nemrég publikáltunk.
Mi a következő lépés?
Egy ilyen beépülő modul nem csak a fejlesztők számára lehet hasznos, hanem a műszaki írók számára is (gyakran például XML-lel dolgoznak egy IDE-ben). Minden nap természetes nyelven kell dolgozniuk, anélkül, hogy asszisztensük lenne szerkesztői tippek formájában az esetleges hibákról. Bővítményünk ilyen tippeket ad, és ezt nagy pontossággal teszi.
Tervezzük a bővítmény fejlesztését, mind új nyelvek hozzáadásával, mind a szövegellenőrzés megszervezésének általános megközelítésének feltárásával. Közelebbi terveink között szerepel a stilisztikai profilok (szöveghez stílus útmutatót meghatározó szabályrendszerek, pl. „ne pl., hanem írd a teljes formát”) megvalósítása, a szótár bővítése és a felhasználói felület fejlesztése (különösen, lehetőséget akarunk adni a felhasználónak, hogy ne csak figyelmen kívül hagyjon egy szót, hanem felvegye a szótárba, jelezve a szófajt).
Forrás: www.habr.com