Patuloy naming pinag-uusapan ang mga proyekto ng spring hackathon DevDays, kung saan lumahok ang mga mag-aaral ng programa ng master. .
Sa pamamagitan ng paraan, nais naming mag-imbita ng mga mambabasa na sumali . Dito ay ilalathala namin ang pinakabagong mga balita tungkol sa recruitment at pag-aaral. Ang isang video mula sa bukas na araw ay matatagpuan din sa grupo. Ipinaaalala namin sa iyo: magaganap ang kaganapan sa Abril 29, mga detalye .
Telegram Desktop Voice Message Parser
Ang may-akda ng ideya
Khoroshev Artyom
Komposisyon ng Koponan
Khoroshev Artem β project manager/developer/QA
Eliseev Anton β business analyst/marketing specialist
Maria Kuklina β UI designer/developer
Bakhvalov Pavel β UI designer/developer/QA
Mula sa aming pananaw, ang Telegram ay isang moderno at maginhawang messenger, at ang bersyon ng PC nito ay sikat at open source, na ginagawang posible na baguhin ito. Nag-aalok ang kliyente ng medyo mayamang pag-andar. Bilang karagdagan sa mga karaniwang text message, naglalaman ito ng mga voice call, video message, at voice message. At ito ang huli na kung minsan ay nagdudulot ng abala sa kanilang tatanggap. Kadalasan hindi posible na makinig sa isang voice message habang nasa isang computer o laptop. Maaaring may ingay sa paligid, kakulangan ng headphone, o ayaw mong marinig ng sinuman ang mga nilalaman ng mensahe. Ang ganitong mga problema ay halos hindi kailanman lumitaw kung gumagamit ka ng Telegram sa isang smartphone, dahil maaari mo lamang itong dalhin sa iyong tainga, hindi tulad ng isang laptop o PC. Sinubukan naming lutasin ang problemang ito.
Ang layunin ng aming proyekto sa DevDays ay magdagdag ng kakayahang magsalin ng mga natanggap na voice message sa text sa Telegram desktop client (mula rito ay tinutukoy bilang Telegram Desktop).
Ang lahat ng mga analogue sa ngayon ay mga bot kung saan maaari kang magpadala ng isang audio message at makatanggap ng isang text bilang tugon. Hindi kami masyadong nasisiyahan dito: hindi masyadong maginhawa ang pagpapasa ng mensahe sa isang bot; gusto naming magkaroon ng native na functionality. Bilang karagdagan, ang anumang bot ay isang third party na nagsisilbing tagapamagitan sa pagitan ng speech recognition API at ng user, at ito ay, sa pinakamababa, hindi ligtas.
Tulad ng nabanggit kanina, ang telegram-desktop ay may dalawang makabuluhang pakinabang: kadalian at bilis ng operasyon. At ito ay hindi nagkataon, dahil ito ay ganap na nakasulat sa C++. At dahil nagpasya kaming magdagdag ng bagong functionality nang direkta sa kliyente, kailangan naming bumuo nito sa C++.
Mayroong 4 na tao sa aming koponan. Sa una, dalawang tao ang naghahanap ng angkop na library para sa speech recognition, isang tao ang nag-aaral ng source code ng Telegram-desktop, ang isa ay nagde-deploy ng build project . Nang maglaon, abala ang lahat sa pag-aayos ng UI at pag-debug.
Tila na ang pagpapatupad ng nilalayon na pag-andar ay hindi magiging mahirap, ngunit, gaya ng palaging nangyayari, ang mga paghihirap ay lumitaw.
Ang solusyon sa problema ay binubuo ng dalawang independiyenteng subtask: pagpili ng angkop na tool sa pagkilala sa pagsasalita at pagpapatupad ng UI para sa bagong functionality.
Kapag pumipili ng library para sa voice recognition, kailangan naming agad na iwanan ang lahat ng offline na API, dahil ang mga modelo ng wika ay kumukuha ng maraming espasyo. Ngunit isang wika lang ang pinag-uusapan natin. Naging malinaw na kailangan naming gamitin ang online na API. Nang maglaon, lumabas na ang mga serbisyo sa pagkilala sa pagsasalita ng mga higante tulad ng Google, Yandex at Microsoft ay hindi lahat libre, at kailangan nating maging kontento sa isang panahon ng pagsubok. Bilang resulta, napili ang Google Speech-To-Text dahil pinapayagan ka nitong makakuha ng token para sa paggamit ng serbisyo, na tatagal ng isang buong taon.
Ang pangalawang problemang nakatagpo namin ay nauugnay sa ilan sa mga pagkukulang ng C++ - isang zoo ng iba't ibang mga aklatan sa kawalan ng isang sentralisadong imbakan. Nagkataon na ang Telegram Desktop ay nakasalalay sa maraming iba pang mga library na partikular sa bersyon. Ang opisyal na imbakan ay may para sa pag-assemble ng proyekto. At din ang isang malaking bilang ng mga bukas na isyu tungkol sa mga problema sa pagbuo, halimbawa ΠΈ . Ang lahat ng mga problema ay naging nauugnay sa katotohanan na ang build script ay isinulat para sa Ubuntu 14.04, at upang matagumpay na makabuo ng telegrama sa ilalim ng Ubuntu 18.04, ang mga pagbabago ay kailangang gawin.
Ang Telegram Desktop mismo ay tumatagal ng medyo mahabang oras upang mag-assemble: sa isang laptop na may Intel Core i5-7200U, ang kumpletong pagpupulong (flag -j 4) na may lahat ng dependencies ay tumatagal ng halos tatlong oras. Sa mga ito, humigit-kumulang 30 minuto ang ginugugol sa pamamagitan ng pag-link sa mismong kliyente (sa paglaon ay lumabas na sa pagsasaayos ng Debug, ang pagli-link ay tumatagal ng humigit-kumulang 10 minuto), ngunit ang yugto ng pagli-link ay kailangang ulitin sa bawat oras pagkatapos gumawa ng mga pagbabago.
Sa kabila ng mga problema, nagawa naming ipatupad ang naisip na ideya, pati na rin ang pag-update para sa Ubuntu 18.04. Ang isang pagpapakita ng gawain ay makikita sa . Kasama rin namin ang ilang mga animation. May lumabas na button sa tabi ng lahat ng voice message, na nagbibigay-daan sa iyong isalin ang mensahe sa text. Sa pamamagitan ng pag-right-click, maaari mo ring tukuyin ang wikang gagamitin para sa pagsasahimpapawid. Sa pamamagitan ng magagamit ang kliyente para ma-download.
Sa aming opinyon, ito ay naging isang mahusay na Patunay ng Konsepto ng pag-andar na magiging maginhawa para sa maraming mga gumagamit. Inaasahan naming makita ito sa hinaharap na paglabas ng Telegram Desktop.
Pinahusay na Suporta sa Likas na Wika sa IntelliJ IDEA
Ang may-akda ng ideya
Tankov Vladislav
Komposisyon ng Koponan
Tankov Vladislav (team lead, nagtatrabaho sa LanguageTool at IntelliJ IDEA)
Nikita Sokolov (nagtatrabaho sa LanguageTool at gumagawa ng UI)
Khvorov Alexander (nagtatrabaho sa LanguageTool at nag-optimize ng pagganap)
Sadovnikov Alexander (suporta para sa pag-parse ng mga markup na wika at code)
Gumawa kami ng plugin para sa IntelliJ IDEA na sumusuri sa iba't ibang mga teksto (mga komento at dokumentasyon, literal na linya sa code, text na naka-format sa Markdown o XML markup) para sa katumpakan ng gramatika, pagbabaybay at istilo (sa Ingles ito ay tinatawag na proofreading).
Ang ideya ng proyekto ay upang palawakin ang karaniwang spellcheck IntelliJ IDEA sa sukat ng Grammarly, upang makagawa ng isang uri ng Grammarly sa loob ng IDE.
Makikita mo kung ano ang nangyari .
Well, sa ibaba ay pag-uusapan natin nang mas detalyado ang tungkol sa mga kakayahan ng plugin, pati na rin ang mga paghihirap na lumitaw sa panahon ng paglikha nito.
Pagganyak
Mayroong maraming mga produkto na idinisenyo para sa pagsulat ng teksto sa mga natural na wika, ngunit ang dokumentasyon at mga komento sa code ay kadalasang isinusulat sa mga development environment. Kasabay nito, ang mga IDE ay gumagawa ng isang mahusay na trabaho sa paghahanap ng mga error sa code, ngunit hindi angkop para sa mga teksto sa natural na mga wika. Ginagawa nitong napakadaling magkamali sa grammar, bantas, o istilo nang hindi itinuturo ang mga ito sa kapaligiran ng pag-unlad. Pinaka-kritikal na magkamali sa pagsulat ng user interface, dahil makakaapekto ito hindi lamang sa pagiging madaling maunawaan ng code, kundi pati na rin sa mga user ng binuong application mismo.
Ang isa sa pinakasikat at binuo na mga kapaligiran sa pag-unlad ay ang IntelliJ IDEA, pati na rin ang mga IDE batay sa IntelliJ Platform. Ang IntelliJ Platform ay mayroon nang built-in na spellchecker, ngunit hindi nito inaalis kahit ang pinakasimpleng grammatical error. Nagpasya kaming isama ang isa sa mga sikat na sistema ng pagsusuri ng natural na wika sa IntelliJ IDEA.
Pagpapatupad
Hindi namin itinakda sa aming sarili ang gawain ng paglikha ng aming sariling sistema ng pag-verify ng teksto, kaya gumamit kami ng isang umiiral na solusyon. Ang pinaka-angkop na pagpipilian ay naging . Ang lisensya ay nagpapahintulot sa amin na malayang gamitin ito para sa aming mga layunin: ito ay libre, nakasulat sa Java at open-source. Bilang karagdagan, sinusuportahan nito ang 25 na mga wika at na-develop nang higit sa labinlimang taon. Sa kabila ng pagiging bukas nito, ang LanguageTool ay isang seryosong kakumpitensya sa mga bayad na solusyon sa pag-verify ng teksto, at ang katotohanan na maaari itong gumana nang lokal ay literal na nakamamatay na tampok nito.
Ang plugin code ay nasa . Ang buong proyekto ay isinulat sa Kotlin na may maliit na karagdagan ng Java para sa UI. Sa panahon ng hackathon, nagawa naming ipatupad ang suporta para sa Markdown, JavaDoc, HTML at Plain Text. Pagkatapos ng hackathon, isang malaking update ang nagdagdag ng suporta para sa XML, string literal sa Java, Kotlin at Python, at spell checking.
Mga kahirapan
Mabilis naming napagtanto na kung ipapakain namin ang lahat ng teksto sa LanguageTool para sa inspeksyon sa bawat oras, ang interface ng IDEA ay mag-freeze sa anumang mas o mas seryosong teksto, dahil ang inspeksyon mismo ay humaharang sa daloy ng UI. Ang problema ay nalutas sa pamamagitan ng `ProgressManager.checkCancelled` check - ang function na ito ay nagtatapon ng exception kung naniniwala ang IDEA na oras na para i-abort ang inspeksyon.
Ito ay ganap na inalis ang mga pag-freeze, ngunit ito ay imposibleng gamitin: ang teksto ay tumatagal ng napakatagal na oras upang maproseso. Bukod dito, sa aming kaso, kadalasan ang isang napakaliit na bahagi ng teksto ay nagbabago at gusto naming i-cache ang mga resulta kahit papaano. Ganyan talaga ang ginawa namin. Upang hindi masuri ang lahat sa bawat oras, tiyak na hinati namin ang teksto sa mga piraso at sinuri lamang ang mga nagbago. Dahil maaaring malaki ang mga text at ayaw naming i-load ang cache, hindi namin inimbak ang mga text mismo, kundi ang mga hash nito. Pinayagan nito ang plugin na gumana nang maayos kahit sa malalaking file.
Sinusuportahan ng LanguageTool ang higit sa 25 wika, ngunit malamang na hindi kailangan ng sinumang user ang lahat ng ito. Nais kong bigyan ng pagkakataong mag-download ng mga aklatan para sa isang partikular na wika kapag hiniling (kung lagyan mo ito ng tsek sa UI). Ipinatupad pa nga namin ito, ngunit ito ay naging masyadong kumplikado at hindi mapagkakatiwalaan. Sa partikular, kinailangan naming i-load ang LanguageTool ng isang bagong hanay ng mga wika gamit ang isang hiwalay na classloader, at pagkatapos ay maingat na simulan ito. Kasabay nito, ang lahat ng mga aklatan ay nasa isang user .m2 repository, at sa bawat simula kailangan naming suriin ang kanilang integridad. Sa huli, napagpasyahan namin na kung may mga problema ang mga user sa laki ng plugin, magbibigay kami ng hiwalay na plugin para sa ilan sa mga pinakasikat na wika.
Pagkatapos ng hackathon
Natapos ang hackathon, ngunit nagpatuloy ang trabaho sa plugin sa isang mas makitid na koponan. Nais kong suportahan ang mga string, komento, at maging ang mga konstruksyon ng wika tulad ng variable at mga pangalan ng klase. Sa kasalukuyan ito ay sinusuportahan lamang para sa Java, Kotlin at Python, ngunit umaasa kaming lalago ang listahang ito. Nag-ayos kami ng maraming maliliit na bug at naging mas tugma sa built-in na spellchecker ng Idea. Bilang karagdagan, lumitaw ang suporta sa XML at spell checking. Ang lahat ng ito ay matatagpuan sa pangalawang bersyon, na nai-publish namin kamakailan.
Ano ang susunod?
Ang ganitong plugin ay maaaring maging kapaki-pakinabang hindi lamang para sa mga developer, kundi pati na rin para sa mga teknikal na manunulat (madalas na gumagana, halimbawa, sa XML sa isang IDE). Araw-araw kailangan nilang magtrabaho sa natural na wika, nang walang katulong sa anyo ng mga tip sa editor tungkol sa mga posibleng pagkakamali. Nagbibigay ang aming plugin ng gayong mga pahiwatig at ginagawa ito nang may mataas na antas ng katumpakan.
Plano naming bumuo ng plugin, kapwa sa pamamagitan ng pagdaragdag ng mga bagong wika at sa pamamagitan ng paggalugad ng pangkalahatang diskarte sa pag-aayos ng pagsuri ng teksto. Kasama sa aming mga agarang plano ang pagpapatupad ng mga pang-istilong profile (mga hanay ng mga panuntunan na tumutukoy sa isang gabay sa istilo para sa teksto, halimbawa, "huwag sumulat hal, ngunit isulat ang buong form"), pagpapalawak ng diksyunaryo at pagpapabuti ng user interface (sa partikular, gusto naming bigyan ang gumagamit ng pagkakataon hindi lamang na huwag pansinin ang isang salita, ngunit upang idagdag ito sa diksyunaryo, na nagpapahiwatig ng bahagi ng pananalita).
Pinagmulan: www.habr.com