LibreOffice’i arendaja intervjuu: Kohei Yoshida

Kohei Yoshida on LibreOffice’i projektis teada-tuntud inimene. Paljudele on ta üheks tuumarendajate grupi liikmeks, kes on pühendunud stabiilsele arenemisele ja projekti koodi parandamisele. Samuti on tema õlgadele asetatud ühena liidritest Calc’i arendamine. Kohei leidis oma tihedast graafikust meie intervjuu jaoks aega ning nii on meil võimalus selle mehega ja tema suhtest LibreOffice’iga lähemalt tutvuda.

LibreOffice eksisteerib ainult tänu sellega töötavatele inimestele; seega palun räägi endast natuke lähemalt.

Minu nimi on Kohei Yoshida, jaapanlane kes praegu elab Põhja-Carolina’s Raleigh’is. Töötasin kunagi keskkonnateaduse valdkonnas, kuid vahetasin selle eluala oma tõelise kire ja kinnismõtete vastu tarkvara-arenduse valdkonnas. Olen selle vahetuse üle väga õnnelik, sest nüüd on mul võimalik oma sundmõtteid õigustada ja saada selle eest ka tasustatud.

Milliste teiste tarkvaraprojektidega Sa veel seotud oled?

Peale LibreOffice’i? Ega tegelikult eriti ei olegi. Mõistagi, vanadel aegadel olin seotud OpenOffice.org projektiga, aga see on ka kõik.

Kunagi töötasin umbes aasta aega SlickEdit’i arendajate meeskonnas, veel enne kui ühinesin Novell’iga OpenOffice’iga täistööajaga tööks.

Kus sa elad (ja/või õpid)?

Raleigh, Põhja-Carolina.

Millega vabal ajal tegeled?

Kilde siit-sealt erinevatest tegevustest, nagu näiteks oma poja Taekwondo trenni saatmine, TV-st peamiselt uudiste ja dokumentaalide vaatamine maailma värskete arengutega kursis olemiseks, trenn hea vormi hoidmiseks… ja muid selliseid asju.

Millal sa LibreOffice’iga tavaliselt töötad?

Väga lihtne. Tegemist on täistöökohaga, täpselt nagu kõik inimesed käivad tööl. Samas panustan ma ka päris palju omaenda aega, tavaliselt mõne väiksema projekti edendamiseks, mis ei kuulu otseselt minu kui töötaja töökohustuste hulka.

Millist tekstitöötlejat sa eelistad ja miks?

Erinevalt teistest paljudest arendajatest, kes kasutavad emacs’i või vim’i, eelistan mina SlickEdit’i. See on täiesti korralik kommertsrakendus, kus on sisse-ehitatud sümbolite andmebaas LibreOffice’i laadse projektiga sobivas mahus. Samuti leiab sealt kõikvõimalikke kasulikke funktsioone, mis hoiavad mu aega ja mugavust kõvasti kokku. Fakt, et ma ka ise antud tarkvara arendamisega kokku puutusin, ilmselt andis esimese tõuke ja siin ma sellega olen.

Kuidas sa LibreOffice’ist kuulsid?

Noh, on raske olla sellest mitte kuulnud, kuna olen projektiga olnud seotud alates selle sünnist.

Miks sa projektiga ühinesid?

Sattusin siia tänu mu tööandjale, SUSE’ile.

Milline oli sinu esmane koostöö kogemus LibreOffice’iga?

Veelkord, sedalaadi küsimustele ei saa ma päris üheselt vastata, sest olen projektis kaasa löönud esimest päevast. Aga ma pean märkimist väärivaks seda, et meie uus git-il põhinev repositoorium on minu tööd 100 korda kergemaks teinud kui vana süsteemiga, mis polnud tegelikkuses muud kui vaid käsitsi meisterdatud pakettide haldus-süsteem, mis oli cvs/subversion/mercurial repode ümber mähitud. Kui sulle on tuttavlik Go-oo projekt, siis täpselt sellest ma räägingi.

Nüüd, kui ma vaatan Go-oo projekti süsteemile tagasi, oli tegemist kohutavalt ebaefektiivse ja mitte just parima loovust toetava keskkonnaga. Tol ajal ma küll nii otseselt ei mõelnud, aga nüüd küll. Meil oli ka alustava LibreOffice’i projekti süsteemi juures mitmeid tahumata nurki. Hea uudis, mis mind rõõmsaks teeb, on muidugi see, et oleme saanud vahepeal süsteemi edasi arendada ja suurem osa veidrustest on nüüd parandatud.

Mida sa selle aja jooksul teinud oled?

Olen alates projekti algusest teinud mitmeid asju. Sõltuvalt oma töö iseloomust, tegelen ma mitmete Calc’i arendustega ja minu jaoks on raske koostada individuaalset saavutuste nimekirja. Üldiselt, asjad mida olen teinud saab kategoriseerida järgmiselt:

  1. koodipuhastus
  2. uued funktsioonid ja täiustused
  3. tuuma restruktureerimine parema hoolduse/suutlikkuse/mälujälje parandamiseks

Viimasel ajal fokuseerin oma tegevust peamiselt jõudluse täiustamisele ja tuuma restruktureerimisele, et muuta koodi lahtisemaks, paremini hooldatavaks ja üldiselt paremini toimivaks. Need muutused ei jõua kasutajani küll visuaalselt, kuid on minu arvates sama olulised kui nähtavad funktsioonid.

Olen töötanud ka koodi väljaviimisega välistesse projektidesse, mida hallatakse väljaspool LibreOffice’it. Mdds ja orcus projektid on selliste pingutuste headeks näideteks.

Millist omapoolset panust LibreOffice’ile siiani sa ise kõige tähtsamaks pead?

Edasiarendused Pivot-tabeli mootorisse, mis on nüüd 3.6 versioonis väga heas vormis, ja loendamatult palju üksuste testimise koodi alates projekti käivitamisest.

Kuidas see kasutajaid mõjutab?

Loodetavasti peavad kasutajad Pivot-tabeleid kasutades vähem erinevate asjade taga ootama. Lisaks, meie üksus-testide raamistiku suutlikkus aina suuremat osa koodist automaatselt testida tähendab väiksemat võimalust tagasilangusteks. Kahjuks pole meie testide raamistiku poolt kaetav ala piisav ja me peaksime endiselt usinalt testide koodi kirjutama erinevate pisivigade ennetamiseks. Aga asjad arenevad ja loodetavasti kasvab üksus-testide arv ja ulatus koos uute versioonide ja koodimuutustega.

Milline on sinu tulevikuvisioon ja/või mida sa sooviksid paremaks teha?

Minu visiooniks projektis on muuta kood rohkem modulaarsemaks – viies rohkem koodi mdds’i, orcus’i vms vähendamaks koodi hooldust. Lisaks tuleb tõsta üksus-testide ulatust väljalasete koodi kvaliteedi tõstmiseks. Ja loomulikult, ma ei saa unustada ka Calc’i kiiruse tõstmist kõigis valdkondades. Aga selle saavutamiseks tuleb meil teha väga mitmeid muutusi paljudes erinevates kohtades.

Samuti sooviksin ühel päeval korralikult jännata ja aru saada joonistuskihi koodist. Praegu tean ma väga vähe, minimaalselt, et hakkama saada. Jätkates Calc’i joonistuskihi koodi, mis põhineb suures osas ühisele joonistuskihi koodile kõikide rakenduste vahel, suuremahulise restruktureerimise ja arhitektuuri taasehistamisega ei ole ühel päeval selline teadmiste tase enam piisav. Ühel hetkel võiks seda olukorda muuta.

Tabeli kood veel üks elajas, mille kohta meil korralik teadmine puudub. Mitmeid meist, kaasa arvatud mina, oleme seda koodi uurinud, aga see tundub ikkagi kuidagi “võõras”. Oleks tore seda muuta.

Lisaks, me peame tõsiselt ette võtma ods ja xlsx impordi kehva jõudluse. See on lahendamiseks keeruline ülesanne, ja kuigi mul on mõned ideed laadimise kiirendamiseks, on tegemist pigem ikkagi pika-ajalise muudatusega kui homme juhtuva asjaga. Mul on mõned prototüüpmõtted orcus’es, aga väljakutse seisneb nende ideede materjaliseerimises, et need LibreOffice’is korralikult toimiksid. See ei saa kerge olema, ent ükspäev peab selle asjaga tegelema.

Viimaks, ma tõesti sooviksin restruktureerida Calc’i tuumakesta hoidlat, et saada kasu uuematest CPU vektoriaalsest toest, kasutada ära GPU-d või isegi lubada mõne superarvuti klastri lisamist arvutusfunktsioonide massiivseks kiiruse tõstmiseks. Selle saavutamine saab peamiseks arhitektuurseks väljakutseks, aga see saab ka väga huvitav olema.

Millist nõu sa annaksid uutele LibreOffice’i arendajatele, kes teevad oma esimesi parandusi/täiendusi?

Tee omale täpselt selgeks, mida sa soovid selle projektiga saavutada ja, kui võimalik, proovi püsida ühel kindlal alal ning anna minna.

Kas sa tegeled veel millegi põnevaga peale häkkimise?

Tegelikult mitte eriti. Üldiselt kipun ma kulutama palju aega uusimate puhta energiaga arenduse uurimusega. Kahju, et mul ei ole võimalik selles vallas ise midagi eriti teha ja ma saan ainult õppida, milliseid hämmastavaid asju on teised inimesed selles valdkonnas teinud. Usun, et meil on globaalse suurusega energiakriis, ja ma tõesti olen selle väga raske küsimusega tegelejatele tänulik. Samal ajal tegelen ma ka ise rakenduste efektiivsuse suurendamisega – rakendus täidab ülesandeid kiiremini, kulutades vähem CPU võimsust ja hoides sellega kokku nii elektrienergiat kui ka üleliigse soojuse teket.

Suur tänu aja ja vastuste eest! Ootame põnevusega uusi koodiridu meie lemmikkusse kontoritarkvara paketti!