Andris Reinman

Ütlen kohe algatuseks ära, et kuigi mõlemad on head ja tänuväärsed litsentsi tüübid, siis mina soosin kindlalt BSD stiilis litsentse (BSD, MIT jne).

Kui GPL rõhub tarkvara vabadusele - GPL litsentsiga tarkvara peab olema vaba nüüd ja igavesti ning selle tarkvara kasutajad peavad sellega arvestama. Siis BSD paneb rõhu kasutaja vabadusele. Kasutajal on vabadus teha BSD litsentsiga tarkvaraga mida iganes, sealhulgas võib seda ka müüa.

Minu meelest hind, mis BSD litsentsiga kaasneb (tarkvara omandanud kasutaja võib selle muuta kinniseks), on tunduvalt väiksem kui tulu (kasutaja vabadus).

Kuid loomulikult on mõlemal variandil omad nišid. Näiteks teekide puhul on BSD imho vaieldamatult parim litsents - vastasel korral võib juhtuda et seda teeki eriti ei kasutatagi, aga see pole teegi looja jaoks üldse hea. Ja seda seetõttu, et niikaua kui teeki arendavad edasi originaalsed (või teised sama ideed kandvad) autorid, ei anna BSD litsentsiga saadud teegi puhul selle suletuks muutmine mitte midagi. Näiteks kui tegu aga on nn. ühekordse tootega, mis pole pidevas arengus, näiteks foto või raamat, tagab GPL õiglase seose autori ja teose vahel.

Ühe projektina aines Avatud Lähtekoodil põhinev Arendusmudel tuli valmistada Wesnothi kampaania. Mina isiklikult polnud sellest mängust varem suurt midagi kuulnud, aga nüüd semestri jooksul olen vahel ka lihtsalt oma lõbuks mõnda suvalist selle mängu kampaaniat proovinud. Kuigi tegelikult ma suurem asi mängumees pole, ainult vahel toksin ajaviiteks mõningaid ‘90-ndate mänge ehk neid, mis olid parasjagu popid kui tegin esimest tutvust arvutitega.

Larry ning Space Quest stiilis mängud olid ühed lemmikud näiteks. Ma suurem asi autosõidu või action mängude sõber pole kunagi olnud, rohkem on tõmmanud need “multika” tüüpi asjad. Mäletan kuidas ahmisin Juhan Habichti “Selles mängus ei hüpata” raamatut. Need kohad mis mängimise osa ei puudutanud jätsin kiirelt vahele, aga mängu kirjeldusi (raamatus oli juttu Larry esimesest osast ning Space Quest teisest osast) lugesin jälle ja jälle kümneid kordi.

Tollal kui see raamat tuli, mul suuremat asja arvutite juurde polnud - neid polnud lihtsalt kuskilt võtta, seega tuli asjasse suhtuda pigem “teoreetilisel” tasemel. Igatahes mõni aasta hiljem kui ma ise nendele mängudele käed külge sain, õnnestus mul tänu mainitud raamatule Space Quest II nii läbi mängida, et ei pidanud kuskilt vihjeid otsima hakkama, kogu mäng oli juba peas.

Kui nüüd Wesnothi kampaania juurde tagasi tulla, siis mina vaatasin Rohelise meeskonna mängu. Mängisin kõik kolm tabelit läbi ja tuleb tunnistada, et kuigi võrreldes näiteks Punase meeskonnaga läks neil mängu tegemisega päris pikalt aega - meie saime esimese mängitava versiooni valmis juba suhteliselt kursuse alguses - on tegu muljetavaldava tulemusega. Väga head tööd on tehtud graafikaga ning ka stoori kannab. Ma pole küll suurem asi mängus esitatud maailmavaate hindaja või õigemini hindan küll, aga väga kehvaks ja suure miinusmärgiga, kuid see ei ole momendil oluline.

Tehniline teostus (skripti poolelt) on jäänud väga lihtsaks, kasutatud pole ühtegi lisavõimalust. Kõik mängu kolm osa on täpselt ühesugused - kaardil on kaks kindlust, mängija vastase oma; mängu algul ütlevad mõlemad pooled oma sõnavõtud ning mängitakse kuni vastaspealik on surnud. Samas on olemasolev tehtud väga kvaliteetselt, seega virisemiseks selle koha peal tegelikult põhjust ei ole.

Minu hinded oleksid seega järgnevad:

• Graafika 5
• Tehniline teostus 4 (veidi liiga lihtne)
• Stoori 4-
• Kokku 4+

Lugesin läbi artiklid Anarchism Triumphant, The Cathedral and the Bazaar ja Kuidas saada häkkeriks ning tegin neist järgnevad järeldused.

Anarhismi triumf

Artikkel räägibprobleemidest autorikaitse ning tarkvara vallas. Sisuliselt on iga autorikaitse subjekt digitaalsel kujul lihtsalt numbrite järjestus. Kas seega on ikka täiesti korrektne, et numbrite järjestust on võimalik “patenteerida”. Kuigi sellisel viisil numbritele rõhumine nagu artikli alguses ei ole minu arust väga korrektne ja veidi demagoogiline, kuna sama hästi võiks küsida, kas on õige patenteerida sõnade järjestust (sest seda ju seletav tekst lõpuks on). Numbrilise vormi puhul on tegu andmekandja nagu iga teisegagi. Oluline pole lõppude lõpuks ju mitte vorm, vaid sisu.

Aga üldiselt - väga väärt lugemine. Olen täiesti nõus et praegused autorikaitse mehhanismid lonkavad kolme jalga ning on AUTORI-kaitsest - selle originaalses mõttes - üsna kaugel.

The Cathedral and the Bazaar

Autor jagab vaba tarkvara arenduse kahe mudeli vahel:

1. katedraalimudel, kus töö on rangelt koordineeritud, igaüks tegeleb oma kindla asjaga ning kui kõik on enda osaga lõplikult valmis saanud, pannakse osad kokku ja saadakse lõplik toode. Tekib omamoodi revolutsioon - uus versioon on eelmisest väga palju erinev ja vanu põhimõtteid kummutav. Mina tooksin siinkohal näitena MS Windowsi, kus versioonilt XP versioonile Vista üleminek toimus(b) üle väga pika aja ning Vistasse oli üritatud kokku panna kõik , mis nende aastate jooksul operatsioonisüsteemide jaoks välja oli mõeldud. Tulemuseks oli midagi ‘17 aasta revolutsiooni sarnast, teoorias ilus aga praktikas kole verine.

2. turumudel, kus igaüks tegeleb parasjagu selle osaga, mis meeldib. Koordinatsioon praktiliselt puudub või on väga nõrk ning kohe kui keegi saab mingi osaga valmis, antakse välja järjekordne versioon tootest. Toimub evolutsioon. Kui eelmist näidet laiendada, siis kasutades mitte avatud, vaid suletud tarkvara näidet oleks siinkohal hea võrdlus Mac OSX-iga. Uus Mac OSX on tulnud välja suhteliselt ühtslases tempos, umbes iga pooleteise aasta järel. Uus versioon on parandanud alati mingi hulga vanu vigu ja tutvustanud mõningase hulga uusi featuure. Juhul kui need feeatuurid on vigased või pole elujõulised, siis need vaadatakse suhteliselt kiirelt järgmise versiooniga üle.

Autor toob loo jooksul välja 19 puntki, mida peaks arvestama tarkvara arendusel või mis on eelduseks hea toote loomisel (näiteks punkt 1., mis sätestab, et hea toode tuleb ainult suurest vajadusest tegija enda poolt).

Kuidas saada häkkeriks

Mulle meeldib esitatud kontseptsioon, mis seob häkkerluse lahti puhtalt arvutitega seonduvast ja laiendab mõistet igasugusele nupukal viisil probleemide lahendamiseni. Ja kui täpsemalt vaadata, siis algselt mõiste seda kujutaski, lihtsalt vahepeal on häkkerite ja arvutitega tegelemise vahele miskipärast võrdusmärk tõmmatud.

Tean omast käest kuidas pool-tuttavad võtavad ühendust ja ütlevad “sa oled ju Tallinnas arvutite peal, oled ju häkker, järelikult peaksid oskama küll kodulehte teha.” Ja selles ühes lauses on juba päris palju vigu.

Mis veel artiklisse puutub, siis seal on punkt, mis veenab häkkeriks soovijaid programmeerima õppima ning nimetab viis programmeerimiskeelt, mis tuleks kindlasti ära õppida. Mina isiklikult lisaks sinna nimekirja ka kuuenda, nimelt JavaScripti. Leian, et autor on JavaScriptile ühes oma teises artiklis HTML Hell kõvasti liiga teinud. See kui suurem osa inimesi on valinud selle keele langevate lumehelbekeste valmistamiseks ning hiirele ASCII animatsiooniga “saba” tekitamiseks, mis hirmsasti lehe vaatamist segavad, ei tee keelt veel iseenesest halvaks. JavaScripti “kapoti all” on tegelikult imeline keel, olles sisuliselt ainus prototüübipõhise orienteeritusega intuitiivne objektorienteeritud keel (kõik teised sarnased keeled on liiga marginaalsed, et neid isegi mainida), samal ajal kui kõik muud on klassipõhised.

Pealegi on JavaScript “tõeline” avatud lähtekoodi keel, kuna seda praktiliselt ei ole võimalik kompileerida ning tuleb vähemalt brauseris edastada kasutajale originaalsel avatud kujul.

Prototype ning jQuery on kaks suurepärast JavaScripti raamistikku. Kuigi suuresti laiendatavad (Prototype jaoks on Script.aculo.us ning jQuery jaoks leidub meeletult erinevad pluginad), on mõlema näol tegu pemiselt “madala taseme” raamistikega, mis erinevate valmiskomponentide pakkumise asemel tegelevad peamiselt brauseritevahese ühildamise ning keele laiendamisega.

Raamistikud võimaldavad näiteks kasutada meetodeid, mis keeles peaksid olema (ja tuleviku versioonides ongi), aga mida hetkel pole veel implementeeritud või on seda ainult osaliselt (sündmuste haldus, JSON, loendamine jms).

Taustast

Prototype kasutab MIT stiilis litsentsi (eemaldatud on vaid keskmine punkt, mis nõuab tarkvara levitamisel pakketi panema ka info selle litsentsi kohta).

jQuery võimaldab litsentsi valida nii MIT kui GPLv2 vahel - kasutad seda, kumba sobivamaks pead.

Prototype pärineb Ruby on Rails projektist, olles selle spin-off. Raamistiku loojaks ja peamiseks arendajaks on Sam Stephenson.

jQuery loojaks ja vedajaks on John Resig Mozilla korporatsioonist.

Prototype arendus

Prototype lähtekoodi hoitakse github.com koodihoidlas (avatud lähtekoodiga projektidele on seal majutus tasuta) ning nagu domeeninimest juba aru saada, on versioonihalduse tarkvarana kasutusel Git. Veahaldussüsteemina on kasutusel Lighthouse, kuhu projektiga seotud inimesed (ehk kõik need, kes on endale konto registreerinud) saavad saata kõikvõimalikke arendusega seotud materjale (veapiletid, vigade parandused jne).

Kõik soovijad saavad Prototype raamistiku arendamisel kaasa lüüa, otsides näiteks vigu ja esitades vearaporteid. Arendajatevaheline suhtlus toimub meililisti ning IRC abil, võimaldades siis kokku leppida, et kes mida teeb jms. Kui on soovi midagi ka ise muuta, saab seda teha tõmmates endale Prototype lähtefailid. Kui vajalikud muudatused on tehtud, sisaldab pakett tervet hulka erinevaid teste, mis tuleb koos uue koodiga läbi viia. Kui kõik testid annavad rohelist, võib oma muudatused ära saata.

Muudatuste saatmiseks tuleb luua diff fail ning laadida see uue piletina üles Lighthouse teenusesse. Teine võimalus on githubi kasutajatel, kes saavad enda versiooni github.com teenusesse läbi Git versioonihalduse üles laadida. Muudatused ei lähe automaatselt kõigile nähtavale, esiteks tuleb saata projekti vedajale Sam Stephensonile teade uuendustest, mida ta peaks aktsepteerima. Kui projekti juht leiab, et kõik on okei, lähevad muutused nähtavale.

jQuery arendus

jQuery lähtekoodi hoitakse Google Code hoidlas, mis kasutab veahaldussüsteemi Subversion.Veahalduseks kasutatakse laialt levinud vastavasisulist tarkvara TRAC. Arenduses kaasalöömiseks piisab täiesti jQuery veahaldussüsteemis endale konto lomisest. Peale seda on võimalik hakata vigu haldama ja vearaporteid koostama.

jQuery kasutab sarnaselt Prototype raamistiku arendajatega samuti Google Groups meililisti ning oma IRC kanalit. Muudatusi saab teha läbi Subversioni. Kui lähtefailid on alla tõmmatud ning muudatused tehtud, tuleb esitada muudatusettepanekud mõnele projekti tuumikliikmele. Arendustiimiga liitumiseks tuleb liituda Google Code süsteemis jQuery grupiga (juhul kui võetakse liikmeks), peale mida võib saada vastavad õigused ka ise asju üles laadida.

Kokkuvõtteks

Mõlemad projektid on suhteliselt sarnased, nii oma sisu kui ka arendusmudeli järgi. Võibolla ainult et jQuery arenduses saab tegelikult lüüa kaasa rohkem inimesi, kuna üheks projekti osaks on erinevad pluginad, mida igaüks vajadusel juurde võib teha. Prototype juures säärast integreeritud pluginate süsteemi ei ole. Iseasi kas neid pluginaid ongi vaja - madalatasemelise raamistiku juures, mida nii jQuery kui Prototype on, ei olegi alati erinevad lisavõimalused vajalikud ega oodatud.