Jatkamme keskustelua kevään hackathon DevDays projekteista, joihin maisteriohjelman opiskelijat osallistuivat .
Muuten, haluaisimme kutsua lukijoita liittymään . Siinä julkaisemme viimeisimmät rekrytointi- ja opiskeluuutiset. Ryhmästä löytyy myös video avoimien ovien päivästä. Muistutamme: tapahtuma järjestetään 29. huhtikuuta, tiedot .
Telegram Desktop Voice Message Parser
Idean kirjoittaja
Khorošev Artjom
Joukkueen kokoonpano
Khoroshev Artem – projektipäällikkö/kehittäjä/QA
Eliseev Anton – yritysanalyytikko/markkinointiasiantuntija
Maria Kuklina – käyttöliittymäsuunnittelija/kehittäjä
Bakhvalov Pavel – käyttöliittymäsuunnittelija/kehittäjä/QA
Meidän näkökulmastamme Telegram on moderni ja kätevä messenger, jonka PC-versio on suosittu ja avoimen lähdekoodin, mikä mahdollistaa sen muokkaamisen. Asiakas tarjoaa melko runsaasti toimintoja. Tavallisten tekstiviestien lisäksi se sisältää äänipuhelut, videoviestit ja ääniviestit. Ja juuri viimeksi mainitut aiheuttavat joskus hankaluuksia vastaanottajalleen. Ääniviestiä ei useinkaan ole mahdollista kuunnella tietokoneella tai kannettavalla tietokoneella. Ympäristössä voi olla melua, kuulokkeiden puute tai et halua kenenkään kuulevan viestin sisältöä. Tällaisia ongelmia ei juuri koskaan esiinny, jos käytät Telegramia älypuhelimessa, koska voit yksinkertaisesti tuoda sen korvallesi, toisin kuin kannettava tietokone tai tietokone. Yritimme ratkaista tämän ongelman.
DevDays-projektimme tavoitteena oli lisätä kyky kääntää vastaanotetut puheviestit tekstiksi Telegramin työpöytäasiakkaalle (jäljempänä Telegram Desktop).
Kaikki analogit ovat tällä hetkellä botteja, joihin voit lähettää ääniviestin ja vastaanottaa tekstin vastauksena. Emme ole kovin tyytyväisiä tähän: viestin välittäminen botille ei ole kovin kätevää, haluaisimme natiivitoiminnon. Lisäksi mikä tahansa robotti on kolmas osapuoli, joka toimii välittäjänä puheentunnistuksen API:n ja käyttäjän välillä, ja tämä ei ole vähintään turvallista.
Kuten aiemmin todettiin, telegram-desktopilla on kaksi merkittävää etua: käytön helppous ja nopeus. Eikä tämä ole sattumaa, koska se on kirjoitettu kokonaan C++:lla. Ja koska päätimme lisätä uusia toimintoja suoraan asiakkaaseen, meidän oli kehitettävä se C++:ssa.
Joukkueessamme oli 4 henkilöä. Aluksi kaksi henkilöä etsi sopivaa kirjastoa puheentunnistukseen, yksi tutkii Telegram-desktopin lähdekoodia, toinen otti käyttöön rakennusprojektia. . Myöhemmin kaikki olivat kiireisiä käyttöliittymän korjaamisessa ja virheenkorjauksessa.
Näytti siltä, että suunnitellun toiminnallisuuden toteuttaminen ei olisi vaikeaa, mutta kuten aina tapahtuu, vaikeuksia ilmeni.
Ongelman ratkaisu koostui kahdesta itsenäisestä osatehtävästä: sopivan puheentunnistustyökalun valinnasta ja uuden toiminnallisuuden käyttöliittymän toteuttamisesta.
Valittaessa kirjastoa äänentunnistukseen jouduimme heti luopumaan kaikista offline-sovellusliittymistä, koska kielimallit vievät paljon tilaa. Mutta puhumme vain yhdestä kielestä. Kävi selväksi, että meidän on käytettävä online-sovellusliittymää. Myöhemmin kävi ilmi, että Googlen, Yandexin ja Microsoftin kaltaisten jättiläisten puheentunnistuspalvelut eivät ole ollenkaan ilmaisia, ja meidän on tyytyttävä kokeilujaksoon. Tämän seurauksena Google Speech-To-Text valittiin, koska sen avulla saat palvelun käytöstä tokenin, joka kestää koko vuoden.
Toinen kohtaamamme ongelma liittyy joihinkin C++:n puutteisiin - erilaisten kirjastojen eläintarhaan keskitetyn arkiston puuttuessa. Sattuu niin, että Telegram Desktop riippuu monista muista versiokohtaisista kirjastoista. Virallisella arkistolla on projektin kokoamista varten. Ja myös suuri joukko avoimia kysymyksiä esimerkiksi rakennusongelmista и . Kaikki ongelmat liittyivät siihen, että koontiskripti oli kirjoitettu Ubuntu 14.04:lle, ja jotta sähke voitaisiin rakentaa onnistuneesti Ubuntu 18.04:lle, jouduttiin tekemään muutoksia.
Itse Telegram Desktopin kokoaminen kestää melko kauan: kannettavalla tietokoneella, jossa on Intel Core i5-7200U, täydellinen kokoonpano (lippu -j 4) kaikilla riippuvuuksineen kestää noin kolme tuntia. Näistä noin 30 minuuttia menee itse asiakkaan linkittämiseen (myöhemmin kävi ilmi, että Debug-kokoonpanossa linkitys kestää noin 10 minuuttia), mutta linkitysvaihe on toistettava joka kerta muutosten jälkeen.
Ongelmista huolimatta onnistuimme toteuttamaan syntyneen idean sekä päivittämään Ubuntu 18.04. Esittely työstä on nähtävissä osoitteessa . Mukana on myös useita animaatioita. Kaikkien ääniviestien viereen on ilmestynyt painike, jonka avulla voit kääntää viestin tekstiksi. Napsauta hiiren kakkospainikkeella, voit lisäksi määrittää lähetyksissä käytettävän kielen. Tekijä: asiakas ladattavissa.
Mielestämme se osoittautui hyväksi todisteeksi toimivuudesta, joka olisi kätevä monille käyttäjille. Toivomme näkevämme sen tulevissa Telegram Desktopin julkaisuissa.
Parannettu luonnollisen kielen tuki IntelliJ IDEAssa
Idean kirjoittaja
Tankov Vladislav
Joukkueen kokoonpano
Tankov Vladislav (tiimin johtaja, työskentelee LanguageToolin ja IntelliJ IDEA:n kanssa)
Nikita Sokolov (työskentely LanguageToolin kanssa ja käyttöliittymän luominen)
Khvorov Alexander (työskentely LanguageToolin kanssa ja suorituskyvyn optimointi)
Sadovnikov Alexander (tuki merkintäkielten ja koodin jäsentämiseen)
Olemme kehittäneet IntelliJ IDEA:lle laajennuksen, joka tarkistaa eri tekstien (kommentit ja dokumentaatiot, koodin kirjaimelliset rivit, Markdown- tai XML-merkinnöillä muotoiltu teksti) kieliopin, oikeinkirjoituksen ja tyylin tarkkuuden (englanniksi tätä kutsutaan oikolukuksi).
Projektin ideana oli laajentaa IntelliJ IDEA:n standardioikoluku Grammarlyn mittakaavaksi, jotta IDE:n sisällä voitaisiin tehdä eräänlainen Grammarly.
Näet mitä tapahtui .
No, alla puhumme yksityiskohtaisemmin laajennuksen ominaisuuksista sekä sen luomisen aikana ilmenneistä vaikeuksista.
Motivaatio
Tekstin kirjoittamiseen luonnollisilla kielillä on suunniteltu monia tuotteita, mutta dokumentaatio ja koodikommentit kirjoitetaan useimmiten kehitysympäristöissä. Samaan aikaan IDE:t tekevät erinomaista työtä löytääkseen virheitä koodista, mutta ne sopivat huonosti luonnollisilla kielillä oleviin teksteihin. Tämän ansiosta on erittäin helppoa tehdä virheitä kielioppi-, välimerkki- tai tyylivirheissä ilman, että kehitysympäristö huomauttaa niistä. On kriittisintä tehdä virhe käyttöliittymän kirjoittamisessa, sillä se vaikuttaa koodin ymmärrettävyyden lisäksi myös itse kehitetyn sovelluksen käyttäjiin.
Yksi suosituimmista ja kehittyneimmistä kehitysympäristöistä on IntelliJ IDEA sekä IntelliJ Platformiin perustuvat IDE:t. IntelliJ Platformissa on jo sisäänrakennettu oikoluku, mutta se ei poista yksinkertaisimmistakaan kielioppivirheistä. Päätimme integroida yhden suosituista luonnollisen kielen analyysijärjestelmistä IntelliJ IDEA:han.
Реализация
Emme asettaneet itsellemme tehtäväksi oman tekstinvarmennusjärjestelmän luomista, joten käytimme olemassa olevaa ratkaisua. Sopivin vaihtoehto osoittautui . Lisenssi antoi meille mahdollisuuden käyttää sitä vapaasti tarkoituksiinmme: se on ilmainen, kirjoitettu Java-kielellä ja avoimen lähdekoodin. Lisäksi se tukee 25 kieltä, ja sitä on kehitetty yli viisitoista vuotta. Avoimuudestaan huolimatta LanguageTool on vakava kilpailija maksullisille tekstintarkistusratkaisuille, ja se, että se voi toimia paikallisesti, on kirjaimellisesti sen tappava ominaisuus.
Plugin koodi on sisään . Koko projekti kirjoitettiin Kotlinilla, ja käyttöliittymään oli lisätty vähän Javaa. Hackathonin aikana onnistuimme ottamaan käyttöön tuen Markdownille, JavaDocille, HTML:lle ja Plain Textille. Hackathonin jälkeen merkittävä päivitys lisäsi tuen XML:lle, Javan, Kotlinin ja Pythonin merkkijonokirjaimille sekä oikeinkirjoituksen tarkistukseen.
vaikeudet
Melko nopeasti ymmärsimme, että jos syötämme joka kerta kaiken tekstin LanguageToolille tarkastettavaksi, niin IDEA-rajapinta jäätyy kaikkiin enemmän tai vähemmän vakavaan tekstiin, koska tarkastus itse estää käyttöliittymän kulkua. Ongelma ratkesi `ProgressManager.checkCancelled` -tarkistuksella - tämä toiminto tekee poikkeuksen, jos IDEA uskoo, että on aika keskeyttää tarkastus.
Tämä eliminoi jäädytykset kokonaan, mutta sitä ei voi käyttää: tekstin käsittely kestää hyvin kauan. Lisäksi meidän tapauksessamme useimmiten hyvin pieni osa tekstistä muuttuu ja haluamme tallentaa tulokset jotenkin välimuistiin. Juuri niin me teimme. Jotta emme tarkistaisi kaikkea joka kerta, jaoimme tekstin deterministisesti osiin ja tarkistimme vain ne, jotka olivat muuttuneet. Koska tekstit voivat olla suuria, emmekä halunneet ladata välimuistia, emme tallentaneet itse tekstejä, vaan niiden tiivisteet. Tämän ansiosta laajennus toimi sujuvasti jopa suurilla tiedostoilla.
LanguageTool tukee yli 25 kieltä, mutta on epätodennäköistä, että kukaan käyttäjä tarvitsee niitä kaikkia. Halusin antaa mahdollisuuden ladata kirjastoja tietylle kielelle pyynnöstä (jos valitset sen käyttöliittymässä). Otimme tämän jopa käyttöön, mutta se osoittautui liian monimutkaiseksi ja epäluotettavaksi. Erityisesti meidän piti ladata LanguageTool uudella kielijoukolla erillisellä luokanlataajalla ja alustaa se sitten huolellisesti. Samaan aikaan kaikki kirjastot olivat käyttäjän .m2 arkistossa ja jokaisen käynnistyksen yhteydessä piti tarkistaa niiden eheys. Lopulta päätimme, että jos käyttäjillä on ongelmia laajennuksen koon kanssa, tarjoamme erillisen laajennuksen useille suosituimmille kielille.
Hackathonin jälkeen
Hackathon päättyi, mutta työ laajennuksen parissa jatkui kapeamman tiimin kanssa. Halusin tukea merkkijonoja, kommentteja ja jopa kielirakenteita, kuten muuttujien ja luokkien nimiä. Tällä hetkellä tätä tuetaan vain Javalle, Kotlinille ja Pythonille, mutta toivomme, että tämä luettelo kasvaa. Olemme korjanneet paljon pieniä virheitä ja parantuneet yhteensopivaksi Idean sisäänrakennetun oikeinkirjoituksen tarkistuksen kanssa. Lisäksi XML-tuki ja oikeinkirjoituksen tarkistus ovat ilmestyneet. Kaikki tämä löytyy toisesta versiosta, jonka julkaisimme äskettäin.
Mitä seuraavaksi?
Tällainen liitännäinen voi olla hyödyllinen paitsi kehittäjille, myös teknisille kirjoittajille (usein esimerkiksi XML:n kanssa IDE:ssä). Joka päivä heidän on työskenneltävä luonnollisella kielellä ilman, että heillä on avustaja, joka antaa editorivinkkejä mahdollisista virheistä. Plugin tarjoaa tällaisia vihjeitä ja tekee sen erittäin tarkasti.
Aiomme kehittää laajennusta sekä lisäämällä uusia kieliä että tutkimalla yleistä lähestymistapaa tekstintarkistuksen järjestämiseen. Lähisuunnitelmiimme kuuluu tyyliprofiilien käyttöönotto (sääntösarjat, jotka määrittelevät tekstin tyylioppaan, esim. ”älä kirjoita esim., vaan kirjoita koko lomake”), sanakirjan laajentaminen ja käyttöliittymän parantaminen (erityisesti Haluamme antaa käyttäjälle mahdollisuuden paitsi jättää sana huomioimatta, myös lisätä se sanakirjaan osoittaen puheen osan).
Lähde: www.habr.com