Мы працягваем расказваць пра праекты вясновага хакатона DevDays, у якім удзельнічалі студэнты магістарскай праграмы. .
Дарэчы, жадаем запрасіць чытачоў далучыцца да . У ёй мы будзем публікаваць самыя апошнія навіны пра набор і вучобу. Відэазапіс з дня адчыненых дзвярэй таксама можна будзе знайсці ў групе. Нагадваем: мерапрыемства пройдзе 29 красавіка, падрабязнасці .
Telegram Desktop Voice Message Parser
Аўтар ідэі
Хорошев Арцём
Склад каманды
Хорошев Арцём - менеджэр праекта / распрацоўшчык / QA
Елісееў Антон - бізнес-аналітык / спецыяліст па маркетынгу
Кукліна Марыя - UI дызайнер / распрацоўшчык
Бахвалаў Павел – UI дызайнер/распрацоўшчык/QA
З нашага пункта гледжання, Telegram з'яўляецца сучасным і зручным месэнджэрам, а яго версія для ПК адрозніваецца папулярнасцю і адчыненым зыходным кодам, з прычыны чаго маецца магчымасць яго мадыфікаваць. Кліент прапануе дастаткова багатую функцыянальнасць. Апроч стандартных тэкставых паведамленняў, у ім прысутнічаюць галасавыя званкі, відэапаведамленні, галасавыя паведамленні. І менавіта апошнія часам прыносяць нязручнасць свайму атрымальніку. Часцяком няма магчымасці праслухаць галасавое паведамленне, знаходзячыся за кампутарам ці наўтбукам. Можа перашкаджаць навакольны шум, адсутнасць навушнікаў, ці вы не хочаце, каб змесціва паведамлення хто-небудзь пачуў. Такіх праблем амаль не ўзнікае, калі вы выкарыстоўваеце тэлеграм на смартфоне, бо яго можна проста паднесці да вуха, у адрозненне ад наўтбука ці ПК. Мы паспрабавалі вырашыць дадзеную праблему.
Задачай нашага праекту на DevDays было дадаць у настольны кліент Telegram (далей Telegram Desktop) магчымасць трансляваць атрыманыя галасавыя паведамленні ў тэкст.
Усе аналагі цяпер – гэта робаты, якім можна пераслаць гукавое паведамленне, а ў адказ атрымаць тэкст. Нас гэта не вельмі задавальняе: перасылаць паведамленне робату не вельмі зручна, хацелася б мець натыўную функцыянальнасць. Да таго ж любы бот – гэта трэці бок, якая выступае пасярэднікам паміж API па распазнанні прамовы і карыстачом, а гэта, прынамсі, небяспечна.
Як было адзначана раней, telegram-desktop валодае двума вагавымі перавагамі: лёгкасцю і хуткасцю працы. І гэта не выпадкова, бо ён поўнасцю напісаны на C++. А бо мы вырашылі дадаваць новую функцыянальнасць прама ў кліент, то і распрацоўваць прыйшлося на C++.
У нашай камандзе было 4 чалавекі. Першапачаткова, двое займаліся пошукам прыдатнай бібліятэкі для распазнання прамовы, адзін чалавек вывучаў зыходны код Telegram-desktop, яшчэ адзін разгортваў build праекту . Пазней усё займаліся фіксамі UI і адладкай.
Здавалася, што рэалізацыя задуманай функцыянальнасці не складзе працы, але, як заўсёды і бывае, узніклі цяжкасці.
Рашэнне задачы складалася з двух незалежных падзадач: выбару падыходнага сродку для распазнання прамовы і рэалізацыі UI для новай функцыянальнасці.
Пры выбары бібліятэкі для распазнання голасу нам адразу прыйшлося адмовіцца ад усіх offline API, таму што моўныя мадэлі займаюць шмат месца. А гаворка ж ідзе толькі пра адну мову. Стала зразумела, што давядзецца выкарыстоўваць online API. Пазней высветлілася, што сэрвісы па распазнанні прамовы такіх гігантаў як Google, Yandex і Microsoft зусім не бясплатныя, і нам прыйдзецца здавольвацца выпрабавальным перыядам. У выніку быў абраны Google Speech-To-Text, бо ён дазваляе атрымаць токен для карыстання сэрвісам, якога хопіць на цэлы год.
Другая праблема, з якой мы сутыкнуліся, звязана з некаторымі недахопамі C++ - заапаркам розных бібліятэк пры адсутнасці цэнтралізаванага рэпазітара. Так атрымалася, што Telegram Desktop залежыць ад мноства іншых бібліятэк канкрэтных версій. У афіцыйным рэпазітары ёсць па зборцы праекта. А таксама вялікая колькасць адкрытых issues аб праблемах зборкі, напрыклад и . Усе праблемы аказаліся звязаныя з тым, што build script напісаны для Ubuntu 14.04/18.04, і для таго каб паспяхова сабраць telegram пад Ubuntu XNUMX/XNUMX, прыйшлося ўносіць змены.
Сам па сабе Telegram Desktop збіраецца досыць доўга: на наўтбуку з Intel Core i5-7200U поўная зборка (сцяг -j 4) са ўсімі залежнасцямі займае каля трох гадзін. З іх парадку 30 хвілін займае лінкоўка самога кліента (пазней высветлілася, што ў Debug-канфігурацыі лінкоўка займае каля 10 хвілін), хоць этап лінкоўкі даводзіцца паўтараць кожны раз пасля ўнясення змен.
Нягледзячы на праблемы, нам удалося рэалізаваць задуманую ідэю, а таксама абнавіць для Ubuntu 18.04/XNUMX. Дэманстрацыю працы можна ўбачыць па . Таксама прыкладаем некалькі анімацый. Каля ўсіх галасавых паведамленняў з'явілася кнопка, якая дазваляе трансляваць паведамленне ў тэкст. Пры націску правай кнопкай мышы можна дадаткова ўказаць мову, якая будзе выкарыстана для трансляцыі. Па даступны кліент для загрузкі.
Па нашым меркаванні, атрымаўся добры Proof of Concept функцыянальнасці, якая была бы зручная шматлікім карыстачам. Спадзяемся ўбачыць яе ў будучых рэлізах Telegram Desktop.
Пашыраная падтрымка натуральнай мовы ў IntelliJ IDEA
Аўтар ідэі
Танкаў Уладзіслаў
Склад каманды
Танкаў Уладзіслаў (цімлід, праца з LanguageTool і IntelliJ IDEA)
Сакалоў Мікіта (праца з LanguageTool і стварэнне UI)
Хвароў Аляксандр (праца з LanguageTool і аптымізацыя прадукцыйнасці)
Садоўнікаў Аляксандр (падтрымка парсінгу моў разметкі і кода)
Мы распрацавалі плягін для IntelliJ IDEA, які правярае розныя тэксты (каментары і дакументацыю, літаральныя радкі ў кодзе, тэкст аформлены ў Markdown або XML-разметцы) на граматычную, арфаграфічную і стылістычную вернасць (у англійскай гэта называецца proofreading).
Ідэяй праекту было пашырыць стандартны spellcheck IntelliJ IDEA да маштабаў Grammarly, зрабіць свайго роду Grammarly inside IDE.
Паглядзець на тое, што атрымалася, можна .
Ну а ніжэй мы падрабязней раскажам пра магчымасці плагіна, а таксама пра цяжкасці, якія ўзніклі пры яго стварэнні.
Матывацыя
Існуе мноства прадуктаў, створаных для напісання тэкстаў на натуральных мовах, але дакументацыя і каментары да кода пішуцца часцей за ўсё ў асяроддзях распрацоўкі. У той жа час IDE выдатна спраўляюцца з пошукам памылак у напісанні кода, але дрэнна прыстасаваны для тэкстаў на натуральных мовах. З-за гэтага вельмі лёгка дапусціць памылкі ў граматыцы, пунктуацыі ці стылі, а асяроддзе распрацоўкі не пакажа на іх. Найбольш крытычна дапусціць памылку ў напісанні карыстацкага інтэрфейсу, бо ад гэтага пацерпіць не толькі зразумеласць кода, але і самі карыстачы распрацаванага прыкладання.
Адной з самых папулярных і развітых асяроддзяў распрацоўкі з'яўляецца IntelliJ IDEA, а таксама IDE, заснаваныя на IntelliJ Platform. У IntelliJ Platform ужо ёсць убудаваны spellchecker, аднак ён не пазбаўляе нават ад найпростых граматычных памылак. Мы вырашылі інтэграваць адну з папулярных сістэм аналізу натуральнай мовы ў IntelliJ IDEA.
Рэалізацыя
Мы не ставілі перад сабой задачы стварыць сваю сістэму верыфікацыі тэкстаў, таму скарысталі існуючае рашэнне. Найбольш прыдатным варыянтам аказаўся . Ліцэнзія дазваляла бесперашкодна выкарыстоўваць яго для нашых мэт: ён бясплатны, напісаны на Java і выкладзены ў open-source. Акрамя таго, ён падтрымлівае 25 моў і развіваецца ўжо больш за пятнаццаць гадоў. Нягледзячы на адкрытасць, LanguageTool з'яўляецца сур'ёзным канкурэнтам платных рашэнняў верыфікацыі тэкстаў, а тое, што ен здольны працаваць лакальна, літаральна з'яўляецца яго killer feature.
Код плагіна ляжыць у . Увесь праект пісаўся на Kotlin з невялікім даданнем Java для UI. За час хакатона ўдалося рэалізаваць падтрымку Markdown, JavaDoc, HTML і Plain Text. Пасля хакатона ў вялікім абнаўленні былі дададзены падтрымка XML, радковых літаралаў у Java, Kotlin і Python, а таксама праверка арфаграфіі.
Цяжкасці
Даволі хутка мы зразумелі, што калі кожны раз будзем скормліваць увесь тэкст на праверку LanguageTool, то інтэрфейс IDEA будзе падвісаць на любых хоць трохі сур'ёзных тэкстах, бо інспекцыя сама па сабе блакуе струмень UI. Праблема вырашалася праз праверку `ProgressManager.checkCancelled` - гэтая функцыя выкідвае выключэнне калі IDEA лічыць, што інспекцыі пара б перапыніцца.
Гэта цалкам пазбавіла ад завісанняў, але карыстацца гэтым немагчыма: вельмі ўжо доўга апрацоўваецца тэкст. Пры гэтым у нашым выпадку часцей за ўсё мяняецца вельмі невялікая частка тэксту і хочацца неяк закэшаваць вынікі. Менавіта гэта мы і зрабілі. Каб не правяраць кожны раз усё, мы дэтэрмінавана разбівалі тэкст на кавалкі і правяралі толькі тыя, якія змяніліся. Бо тэксты могуць быць вялікімі і нагружаць кэш не жадалася, мы захоўвалі не самі тэксты, а іх хешы. Гэта дазволіла дамагчыся плыўнай працы плагіна нават на вялікіх файлах.
LanguageTool падтрымлівае больш за 25 моў, але ці наўрад аднаму карыстачу патрэбныя яны ўсё. Хацелася даць магчымасць спампоўваць бібліятэкі для канкрэтнай мовы па запыце (калі адзначылі яе галачкай у UI). Мы нават рэалізавалі гэта, але атрымалася надта складана і ненадзейна. У прыватнасці, нам даводзілася асобным classloader-ам падгружаць LanguageTool з новым наборам моў, пасля чаго акуратна яго ініцыялізаваць. Пры гэтым усе бібліятэкі ляжалі ў карыстацкім .m2-рэпазітары, і пры кожным старце нам даводзілася правяраць іх цэласнасць. У выніку мы вырашылі, што калі ў карыстачоў будуць праблемы з памерам убудовы, то мы будзем пастаўляць асобную ўбудову для некалькіх найболей папулярных моў.
Пасля хакатона
Хакатон скончыўся, але праца над убудовай працягнулася ўжо вузейшым складам. Жадалася падтрымаць радкі, каментары і нават канструкцыі мовы, такія як назовы зменных і класаў. Цяпер гэта падтрымліваецца толькі для Java, Kotlin і Python, але мы спадзяемся, што гэты спіс будзе расці. Мы выправілі мноства невялікіх памылак і сталі больш сумяшчальнымі з убудаваным спелчэкерам Idea. Акрамя гэтага з'явілася падтрымка XML і праверка арфаграфіі. Усё гэта можна знайсці ў другой версіі, якую мы апублікавалі нядаўна.
Што далей?
Такая ўбудова можа быць карысны не толькі распрацоўнікам, але і тэхнічным пісьменнікам (часта якія працуюць, да прыкладу, з XML у IDE). Ім кожны дзень даводзіцца працаваць менавіта з натуральнай мовай, пры гэтым не маючы памагатага ў выглядзе падказак рэдактара аб магчымых памылках. Наш убудова дае такія падказкі і робіць гэта з высокай ступенню дакладнасці.
Мы плануем развіваць убудову як дадаючы новыя мовы, так і даследуючы агульны падыход да арганізацыі праверкі тэксту. У бліжэйшых планах рэалізацыя профіляў стылістыкі (набораў правіл вызначальных стайлгайд для тэксту, да прыкладу "не пісаць eg, а пісаць поўную форму"), пашырэнні слоўніка і паляпшэнне карыстацкага інтэрфейсу (у прыватнасці, мы жадаем даць карыстачу магчымасць не проста ігнараваць слова, а дадаваць яго ў слоўнік, паказваючы частку гаворкі).
Крыніца: habr.com