Kuidas nad seda teevad?

KDE arendusmudeli taga olevateks ideelisteks põhipunktideks on (suht vabas tõlkes):

• Tee seda nüüd ja kohe!
  
• Keskendu!
  
• Kasuta saadaolevaid tööriistu, selle asemel et olemasolevaid uuesti leiutada!
  
• Kui teed ettepaneku, ära ütle "me peaks...", vaid "ma kavatsen..."; grandioossed plaanid on kasutud, kui sul pole tahtmist nende saavutamiseks tööd teha.
  
• Arenda järkjärguliselt.
  
• Tee alguses valmis mõistlik funktsionaalsus ning täiusta seda aja jooksul.
  

Tundub päris sobiv tarkvaraarendusprojekt, mille "häkkerlikkust" lähemalt vaadelda. Projekti edukuses ei pruugi niikuinii kahelda, sest KDE on üks kahest unixiliste maailmas kõige laiemalt levinud töölauakeskkonnast.

Lähemal uurimisel võibki KDE manifestist lugeda:

KDE was founded by GNU/Linux hackers who saw the need for a great graphical desktop environment for the Unix platform. All development is open and is discussed and published on the Internet.

Vaatan natuke lähemalt, mida nad oluliseks peavad ja kuidas arendavad. Oma filosoofia kirjeldamisega ei ole projekti liikmed muide üldse kitsid olnud.

Kõige üldisem ja loosunglikum on ilmselt KDE manifest. Mulle meeldib muide see, et KDE ei aja taga rangelt mitte-kommertslikku joont. Ühtlasi ma ei leia, et häkkerlik mõtteviis välistaks kuidagi rahateenimise ja hästi elamise. Pigem vaatan sellise nurga alt, et lähtekoodi avalikkus võiks hoopis tarkvaraga rahateenimist soodustada (oluliseks saab idee ja tegelik sisu).
Manifest mainib ka veel, et KDE rakendused töötavad ka teiste aknahalduritega peale KDE enda oma. Mulle meeldib selline lähenemine! Mu lemmikterminal on mitmel põhjusel Konsole, aga aknahalduritest meeldib näiteks minimalistlik Fluxbox, mille ma aeg-ajalt kasutusele võtan, kui tahan visuaalset rahu.

Arendajate omavahelisele suhtlusele annab aga üldise raami käitumiskoodeks.
Rahvusvahelise arendusprojekti juures on loomulik, et sallivus ja koostöövalmidus on väga olulised. Samas tundub ka heas mõttes "häkkerlik", et eraldi on rõhutatud, et KDE arendusprojektis ei ole kohta rassismile, seksismile ega muudsorti diskrimineerimisele. Käsikäes sallivuse ja koostöövalmidusega käib aga pragmaatilisus ja töötavate lahenduste eelistamine lõpututele vaidlustele ja võitlusele.

Lõpetuseks vaatan, mis infot jagatakse projekti vastu huvi tundvale arendajale.
Kõik, mida võiks eeldada, on olemas. Kirjeldused eri versioonikontrollitööriistade kasutamise kohta, kompileerimisjuhised ja õpetused arenduskeskkonna ülesseadmiseks. Mulle endale on sellised projektid alati meeldivad, kus arendus- ja testkeskkonnad on süstemaatiliselt ülesehitatud ja hästi dokumenteeritud. Üks "häkkerliku" mõtteviisi ilminguid võikski olla just arusaamine, et arendusvahendid ja -keskkonnad on valitud teadlikult ja et nende ülesehitust annab ja tuleb detailselt kirjeldada, kuna süsteemi ülesehitus on muuhulgas ka nende vahenditega määratud. Jällegi selline pragmaatiline värk.

Aga tegelikult ma ei tea üldse, kui tore see KDE projekt seestpoolt on, sest ma ei ole kellegagi neist kokku puutunud. Samas on ka "häkkerlik" suht hägus väljend ja ei ütle midagi inimestevaheliste suhete kohta.

Google ANALytics ja blokeeritud ITSPEA foorum

This summary is not available. Please click here to view the post.

Fassaad?

Virginia Shea 5. käsk: "Make yourself look good online"


1. Korrektselt kirjutamisest
Mina eristan kirjutamise juures laias laastus kaht olukorda: teadlikult täisteksti kirjutamine ja mõttevoo kirjapanek. Täisteksti kirjutan siis, kui teen sellise otsuse: jälgin lause-ehitust, grammatikat, suur-väiketähti jne. Mis puutub elektroonilisse suhtlusse, siis täistekstina püüan kirjutada e-kirju, blogi sissekandeid ja muid tekste, mis ei ole osa vestlusest, vaid peaksid pädema omaette tervikliku tekstina.
Samas on palju olukordi ja formaate, kus ma eelistan mõttevoogu täistekstile ja siinkohal pole ma üldse nõus, et alati tuleb reegleid järgida. Paralleele võiks tuua vabavormilise luulega. Niimoodi grammatiliselt lõdvemalt ja tihti läbivalt väikeste tähtedega kirjutan näiteks IRC-s ja MSN-is. Siinkohal tuleb muidugi endale aru anda, et grammatika ja sõnavõtu sisu ei tohiks tegelikult üldse kuidagi seotud olla. Ega ma seepärast "irtsus" valeta või hoople või kedagi sõima, et ma vähem komasid kasutan ja spontaansem olen. Peamine mõte oleks siinkohal, et ega online-jutuajamised pole muudmoodi kui päriselu. Ma ei pane end pidulikult riidesse, et kellegagi koridoris paar sõna vahetada. Aga ma räägin sealjuures ikkagi sama juttu, mis alati.

Kui otsida näidet, kus korralik kirjaviis on võrgus hästi mõjunud või vastupidi, siis on kindel valdkond, kus ootan 100% korrektset keelekasutust, firmade või ka eraisikust teenusepakkujate kodulehed. Tahes tahtmata näitab keelekasutus kodulehel mulle firma lohakust vs. pedantsust pisiasjades ja ka lugupidamist kliendi suhtes. Ühtegi URL-i ei hakka siinkohal tooma, kuna ei taha hetkel teha head ega halba reklaami.

Kokkuvõtvalt ütleksin nii, et õigekiri fassaadina ei ole kindlasti mõttekas. See on omakorda muidugi juba kultuuriruumi küsimus, et kuivõrd inimene üldse oma sisemaailma ja ühiskonna vahele fassaadi ehitab.

2. Kas tead ka, mida räägid?
On inimesi, kes jäävad igas olukorras tagasihoidlikuks, ja siis on selliseid, kes alati targutavad. Mõned neist teavad, mida räägivad, mõned räägivad niisama ja enamik meist on ilmselt segu kõigest. Ilmselt pole siin suurt vahet, kas räägid poolvõõra inimesega tööl-koolis-turul või võrgus. Inimesi õpime tundma pikema tutvuse käigus ja eks need hooplemised oma teadmistega peavad siis just niipalju vett, kui neil sisu on. Tegelikult võib-olla on nii, et kui võrk kui suhtluskeskkond muutub meile täiesti harjumuspäraseks, siis ilmselt hakkab kaduma see virtuaalmaailma 'teistsugusus' ja võrgueluks eraldi reeglite koodeksit vaja polegi.

3. Viisakusest
Mina õppisin võrgus suhtlema peamiselt IRC põhjal ja suhteliselt ruttu sain teada, et läbivalt suurte tähtedega kirjutamist tõlgendatakse karjumisena. Rääkimata kellegi isiklikust solvamisest mõnel avalikul kanalil, ongi mulle külge jäänud arusaamine, et kõike saab võrgus rääkida rahulikult. Tegelikult on üleliigse kisamise vältimine mu jaoks vist viisakuse mõiste üks nurgakivisid. Nii et kui kõik muu on elementaarne, siis läbivate suurtähtede suhtes olen ma võrguvestluses päris allergiline.

4. Aga sinu n-ö online profiil?
Viimastel aastatel on saanud aktuaalseks igasugused sotsiaalsed võrgustikud. Asja hea ja halb külg korraga on see, et Google leiab su igalt poolt üles, kui sa kuskil vähegi oma pärisnimega esined. Sotsiaalvõrgustikud muidugi pakuvad päris palju privaatsust, aga Eesti on näiteks päris väike ja ka võrgustike piires võib juhtuda, et 'kellegi tuttav on kellegi tuttav' ja sinu veidramaid sõnavõtte võidakse märgata olukorras, kus see väga kasuks ei tule. Minu kogemuse põhjal on näiteks tööandjad hakanud päris usinalt kandidaate 'googeldama' ja ilmselt läbi tutvuste näevad nad ka paljude kandidaatide kohta rohkem kui Google võimaldab.

Lõpetuseks tõden, et võrk võimendab, aga fassaad on jällegi võlts. Kui nüüd mõelda kõikvõimalike ämbrite peale, kuhu võib võrgus valesti rääkides astuda, siis - kunagi pole nii, et kuidagi ei ole. Saad oma vitsad kätte ja elad edasi. Võrgus või muidu, ega vahet väga polegi.

Jätkusuutlik professionaalsus

Kuna IT on suhteliselt hoomamatult lai valdkond, siis ma kitsendaksin teemat ja lüpsaksin jälle tarkvaraarenduse lehma. Ülaltoodud foto muide illustreerib pilti, mis mulle silme ette tuleb, kui mõtisklen tarkvaraarendajate kui liigi üle. Minu peamine nõue kolleegidele olekski muide see, et ärge oma tervist unarusse jätke. Rüht aga kajastab tervist päris hästi.

Igapäevases tarkvaraarendusega seotud töös võiks tuua välja selliseid olulisi isikuomadusi ja muid vajalikke aspekte:

• suhtlemisoskus ja teistega arvestamine (meeskonnatöö!)
• keskendumisvõime ja täpsus ning kannatlikkus
• algatusvõime ja julgus eksida
  
• oskus oma aega planeerida ning MITTE üle töötada!!!
• isikliku elu tähtsustamine
  
• igapäevane enda arendamine nii erialaselt kui väljaspool eriala, mitte jättes unarusse oma füüsilist vormi
  
• valmisolek töötuks jäämiseks, majanduslangusteks jms keerulisteks rahalisteks olukordadeks
• tervislik toitumine

See sai vist natuke "pehmem" nimekiri kui tüüpilises tööpakkumises ette tulev sarnane loetelu. Aga minu meelest on need punktid omavahel väga tihedalt seotud.


Võib juba arvata, et selles valguses ei ole vinge IT-proff tüüpiline "patsiga poiss", kes elab masina taga, toitub ainult pizzast ja isikliku elu puudumise tõttu end ei pese. Kuigi selliseid on väga palju, ei tea me praegu ilmselt veel väga hästi, kui head nad erialaselt 30 aasta pärast on ja kas nad sealjuures ka terved ja õnnelikud on.

Põhjendan lühidalt iga toodud punkti väljatoomist.


Suhtlemisoskusega on mul selline kogemus, et firmas võivad olla väga head ja kogenud spetsialistid, aga kui nad ei suuda endast rumalamatega suhelda, siis varem või hiljem osutub töö ebaefektiivseks. Kui aga vähekogenud arendaja ei oska suhelda, aetakse ta firmast ilmselt minema. Üks asi on kinnisus, aga ka ülbus või selline irvitav suhtumine ei meeldi mulle. See ei tee elus midagi paremaks. Meeskonnatöö elab vaid terve suhtlusega kollektiivis.

Keskendumine on mõnes mõttes vastand suhtlemisele. Oskuslik ümberlülitumine suhtlemiselt keskendumisele ja vastupidi on kindlasti oluline. Kui veel seoseid otsida, siis kui on piisavalt suheldud, on ka mõnus olla omaette ja nokitseda detailide kallal. Keskendumist ja kannatlikkust võib muidugi teha keerulisemaks asjaolu, et veeb on lahelugemist täis. Ja kõikvõimalikud irtsud ja MSNid muidugi panevad ka omakorda põntsu. Keskendumine ja kannatlikkus on kindlasti töökogemusega õpitavad, nii et soovitan ikkagi neid jooni endas arendada.

Tänu algatusvõimele sünnivad siia ilma kõik suuremad muutused. Algatusvõime aga kannab endas riski eksida, kuna tihti astud tundmatule maale. Abiks omadus on siinkohal julgus eksida - kusjuures tööandja peaks muidugi inimesi ka eksimise osas julgustama. Ma ei usu väga, et kogemus ja kvaliteet tekivad ilma suuremate ämbriteta. Ämbrist ämbrisse parema tarkvara ja mõnusama elukeskkonna suunas!

Igas ööpäevas on 24 tundi. Ümmarguselt 8 neist veedame magades-vedeledes, 8 ringis tööl ja ülejäänu jääb kõige muu jaoks. Aja planeerimine ja terade eraldamine sõkaldest on ilmselt oluline võti oma tervise säilitamisel ja kvaliteetse töö tegemisel ilma, et toodaks ohvriks eraelu. Suhteliselt äraleierdatud teema ka, nii et midagi lisada pole.

Isiklik elu on ju see, mille mõnusamaks muutmiseks me idee poolest tööl käime. Minu meelest tuleb isiklikku elu kindlasti tähtsustada ja kindlasti ei jää aeg-ajalt ka muud üle kui olla selle võrra viletsam või aeglasemalt arenev või lihtsalt rumalam töötaja. Milleks mulle teaduskraad või arhitekti roll, kui see minult kodurahu rööviks? Isiklik elu ja ajaplaneerimine on muidugi tihedasti seotud. Teisalt - hiljuti sai just tööl arutatud, et silmapaistvalt hea programmeerija saab ilmselt olla ainult inimene, kel pole "elu". Nii et kriteeriumina suht mitteuniversaalne asi. Ilmselt annab isikliku elu olemasolu ja seisu mõõta mingi sisemise rahulolutunde põhjal.

Enese harimine hoiab vormis. Selles suhtes olen ma päris rahul, et ülikool omal ajal pooleli jäi ja praegu jälle vaikselt õpin. No kuhu on kiiret, eriti seoses IT arengu ulmelise kiirusega? Leian, et pidev arenemine nii vaimusfääris kui ka ihulises plaanis (mis on tegelikult ju enda tundmaõppimine) teevad elu päris nauditavaks. Samas aga - kui suurt osa peaks enda harimine isiklikust elust enda alla võtma? Lugege perele erialast kirjandust ette ja käige koos metsas jooksmas - kas on väga veider soovitus? Ja veel, igasugused süvalihaskonnaga tegelevad treeningmeetodid on minu meelest igati abiks enda tundmaõppimisel ja ka keskendumise ja vastupidavuse õppimisel. Ei ole nii, et loed ainult raamatuid - varem või hiljem see enam ei tööta.

Tõsine jama on siis lahti, kui oled omast arust vinge proff ja töötuks jääd. Või devalveeritakse kroon ja sissetulek sellega oluliselt väheneb ja midagi hinge taga ka polnud (või jäi see panka kinni). Kuna tarkvaraarenduse vallas on suht suur lootus head palka saada, siis iga endast lugupidav inimene peaks päris tihti ja tõsiselt kaaluma oma majanduslikku seisu ja võimekust ootamatutes raskustes toime tulla. See on muidugi vajalik igal elualal, aga IT puhul rõhutaksin just võimalust säästa ja paigutada ülejäävat raha targalt. Ja siingi tuleb mainida, et ka tervis on investeering - igasugused kulukad tegevused nagu hambaarsti juures käimine võiksid olla regulaarsed.

Eelpoolräägitud jutu taustal ei tule soovitus tervislikult toituda ilmselt üllatusena. Kusjuures mida vastutusrikkamad on tööülesanded, seda kasulikum see ilmselt on. Infarktide ja muude jubeduste vältimiseks näiteks. Rääkimata tarkvaraarendustöö istuvast iseloomust. Kui tahad ikka aastakümneid täiskoormusega ja loovalt tarkvara teha ja mõnusalt elada, siis värske söök ning alkoholi ja muu sarnase kraami vältimine on väga soovitatavad.

Pika jutu lühike moraal: tarkvaraarenduse proff aastal 2009 on selline, kes tervise ja võimete poolest on teoreetiliselt igati vormis ja eluga rahul ka aastal 2039.

Kingsepa lastel pole kingi

Millest saada aru, et tarkvara on halva ergonoomikaga? Võibolla sellest, et ta paneb sind oigama, vanduma, peaga vastu seina taguma. Sellist tarkvara pole kellelegi tarvis.

Üks selline üllatus ilmus tarkvaramaailma umbes aasta tagasi.

TTÜ uus õppeinfosüsteem on justkui loodud eesmärgiga üliõpilase eest infot peita ja suruda talle peale keerulisi otsinguid igas võimalikus kohas. Muidugi juba sisse logides pead pahandama, sest TTÜ ei ole tahtnud endale muretseda tunnustatud sertifikaati ja brauser pakub lahkelt välja võimaluse õppeinfosüsteemi mitte kasutada.





Ütleme lihtsustuse mõttes, et sertidemajandus sai korda. Vaatame natuke ringi.

Avaleht koosneb peamiselt tühjusest:


Käisin ise mõned aastad tagasi TTÜs ja vana OISi puhul häiris mind alati see, et ma ei näinud esilehel kõige olulisemat infot: oma staatust (akadeemilisel või mitte, täis- või osakoormusega, tasuline või tasuta, päeva- või kaugõppes, punkte nii palju ja õppekava esitatud/mitteesitatud).
Kahju, et uus ei erine selles osas vanast.

Ja 'minu andmete' all ka on tühjus!


Pildil on 3 kohas kirjas "Minu andmed", aga mida pole, on minu andmed!
Miks nad infot niimoodi mitmetasemeliste linkide alla peidavad? Kui sul on suur valge leht, siis mõtle välja, mida kasutaja sooviks seal näha - ilma et ta peaks minema tegema otsinguid või liikuma mõnele alamleheküljele.


Rosinaks saia sees on aga teadete postkast. Oleme ju kõik harjunud sellega, et meilitarkvaras kaustade vahel liikudes näeme alati kohe kausta sisu. Kirju!



Vaatame siis vastamata kirjade kausta ja "Voila!"


Ma ei taha otsida, ma tahan kirjade nimekirja!
See ei ole kirjakast, see on otsing, mis on kirjakasti vaatamise erijuht.

Noh ja siis on veel sellised kiiksud, et otsingust tulnud vastuste lahtiklikkimine teise tab-i pole võimalik, sest tegu pole linkidega, vaid mingi skriptimajandusega.

Kas nad tõesti õpetavad tarkvara loomist?

Vim - otsetee mõttest koodini

Tuntud tekstiredaktor nimega Vim on minu igapäevane töövahend. Ta ei ole seda üldse vägisi - ma olen ta valinud endaga kaasas käima. Ei saa just öelda, et valin töökohta selle põhjal, kas saan Vim-iga koodi kirjutada, aga kui võrrelda minu efektiivsust ja head tuju Vim-i ja näiteks Visual Studio redaktoriga töötades, siis viimast peale surudes peab tööandja ilmselt arvestama topelt ajakulu ja minu katkiste närvidega.

Vim ja tema eelkäija Vi on nii vanad redaktorid, et võimaldavad töötada täiesti ilma hiirt kasutamata. Miks mulle hiir ei meeldi? Minu arust soodustab hiire pidev kasutamine lihaskasutuse ebasümmeetriat ja see omakorda toob kaasa lihaspinged. Olgu, tegelikult on enamikku tarkvaravahendeid võimalik nii seadistada, et hiirt pole vaja - määrad kiirklahvid ja toimib. Nii et eriline argument see klaverile suunatus muidugi pole.

Aga kuidas sa mõnes suvalises redaktoris teed seda, mida visual block? Noh et valid ära 10 rida ja sisestad iga rea ette üheainsa liigutusega näiteks paljudes keeltes esineva kommentaarimärgi '#'? Kommentaarimärk on ka võib-olla paha näide, sest programmeerimiseks mõeldud redaktorid pakuvad vist enamasti võimalust koodiplokki sisse ja välja kommenteerida. Aga visual blocki abil saad ju suvalisel positsioonil võtta ette suvalise liigutuse ja seda kogu valitud plokile rakendada. Väga kodune.

Ükskord me aga avastasime kodus (juhtumisi elan ühe omasugusega, kes ka igapäevatöös Vim-i kasutab), et kui oled Vim-i kasutamisel tõeliselt vilunud, võib see tegevus kõrvaltvaatajale paista paraja maagiana. Alam-aknad tekivad ja kaovad, asetuvad üksteise suhtes ümber; koodiplokid tekivad ja kaovad; funktsioonide definitsioonid avanevad ja sulguvad; hüppad koodis markerite abil kuhu iganes ja noh, näiteks ctagsi abil ka funktsiooni väljakutse juurest otse tema definitsiooni algusesse.

Aga ma pole oma argumentatsiooniga ikkagi rahul. Kindlasti võiks täpselt samasugust kiidulaulu kuulda Emacsi ja Eclipse'i ja tõesti ilmselt ka Visual Studio kohta, lihtsalt tuleb otsida vastavat redaktorit väga armastav inimene.
Samas kaldun arvama, et võib-olla on programmeerijatele mõeldud töövahendid lihtsalt kujunenud tarkvaraergonoomika osas väga headeks - vastasel juhul keegi lihtsalt ei kasutaks neid.

Selles mõttes võiks öelda, et iga redaktor, mida kasutab märkimisväärne hulk programmeerijaid oma igapäevatöös, aastaid ja hoolimata töökohtade ja projektide muutumisest, väärib ergonoomika osas esiletõstmist. Kusjuures ilmselt on ka nii, et kui oled ühe omaks võtnud, siis teised tunduvad tüütud, mõttetud, kohmakad, liiga hiirepõhised.

Sõna jõud

Tarkvaralitsentside peale mõeldes ei oska ma tuua ühtki näidet, mille puhul võiks väita, et mingi teise litsentsi kasutamine selle tarkvara populaarsust või kvaliteeti oluliselt oleks muutnud. Tuleb muidugi mainida, et ma ei oska mõelda väljaspool avatud lähtekoodiga tarkvara maailma, st Linuxit kui sellist poleks ilma avatud lähtekoodita kindlasti üldse tekkinud ja samas ei tundu erinevate suletud lähtekoodiga litsentside vahel mingit praktilist erinevust olevat.
Kui suletud lähtekoodiga tarkvara kood avalikuks tehakse, on võimalik selle muutuse tulemusi hinnata, aga avatud või siis suletud lähtekoodiga litsentside ringis ei ole minu arust enam väga hästi võimalik välja tuua, kui hästi või halvasti ühe või teise litsentsi kasutamine projektile mõjub.

Avatud lähtekoodiga tarkvaraga seoses võiks siiski rääkida kolmest projektist, kus litsentsidega seoses on toimunud huvitavaid arenguid.

XFree86 vs. X.Org
XFree86 projekti põhilisi arendajaid Keith Packard oli rahulolematu selle projekti piiratud arendusmudeliga ja otsustas teha oma haruprojekti, mille peale ta XFree86 projektist välja visati. XFree86 projekt omakorda tegi väikese litsentsimuudatuse, mis sundis haruprojektide arendajaid oma lähtekoodi dokumentatsioonis XFree86 organisatsiooni reklaamima.
See pisike liigutus põhjustas lõpuks olukorra, kus Linuxi distributsioonid võtsid järgemööda XFree86 asemel kasutusele X.Org-i, mille arendajate hulgas oli aastaks 2004 ka mainitud Keith Packard. Loo moraal: üks lause litsentsis võib otsustada tarkvaraprojekti hääbumise.


IPFilter
IPFilter oli tulemüüritarkvara, mida kasutati kõigis BSD-des ja Solarises. Selle peamine autor oli Darren Reed. Mingil põhjusel arvasid IPFilteri kasutajad, et see on BSD litsentsi all, kuna see meenutas visuaalselt BSD litsentsi. OpenBSD arendajad aga avastasid hoolikal lugemisel, et kui sa IPFilteri koodis muudatusi teed, ei tohi saadud binaari levitada. Peale mõningasi äpardunud läbirääkimisi otsustasid OpenBSD arendajad nullist uue tulemüüritarkvara kirjutada. PF (Packet Filter) on tänaseks kasutuses ka teistes BSD opsüsteemides ja on oma funktsionaalsuselt IPFilterist kaugelt võimekam.


KHTML / WebKit
KHTML on veebirenderdusmootor, mis loodi KDE projekti raames Konquerori brauseris dokumentatsiooni ja veebi kuvamisel kasutamiseks. Arendust alustati 1996. aastal - kaua enne seda, kui Netscape'i lähtekood avalikustati ja Mozilla projekt tekkis. Aastaks 2003 oli KHTML nii hinnatud, et Apple võttis ta oma Safari brauseri renderdusmootoriks - aga kuna KHTML oli GPL litsentsi all, pidi ka Apple oma arendusharu lähtekoodi avalikuks jätma. Apple nimetas oma arendusharu ümber WebKitiks. Tänaseks on see peale Apple'i Safari kasutuses ka nende populaarses iPhone'is. Tänu GPL litsentsile sai ka Apple'i konkurent Nokia WebKiti kasutusele võtta. Nokia omakorda ostis hiljuti ära Qt teegi loojafirma Trolltechi ja nüüdseks on WebKit Qt osa. Uba on selles, et kuna KHTML arendus on ajast maha läinud, kolib KDE parasjagu oma veebirenderdust üle Qt standardseks osaks olevale WebKitile. Ring on täis.

Intellektuaaltarbija kaitse ja õiglane ootus muutmata sisule

Ma ütlen päris tihti igasugustes olukordades, et "mina olen usklik inimene - ma usun, mida mulle räägitakse". Karta on, et mõni on mind hakanud tõesti ka usu mõttes usklikuks pidama (mis ei puutu asjasse), aga ometi eeldame ju, et iga loetud raamat on algupärane selles mõttes, et autorikaitse huvides ei ole teksti-fotosid-kaarte või muid andmeid rikutud.

Olin just hädas, et mida siis õieti arvata autorikaitsest ja intellektuaalomandist, kui mulle anti viide Amazon.com-i sisurikkumise patendile. Või kuidas sa nimetad sellist tegevust, mille tulemusena on teoses sõnu muudetud:

By replacing one or more selected words in an excerpt with synonyms for the words, illicit copies of the excerpt may be recognized by comparing a copy of the excerpt to the original.


Kusjuures, kujutage ette muusika töötlemist sarnasel meetodil. Ilmselt tuleks tekitada päris korraliku mahuga tarkvaraprojekt, mille raames loodud tarkvara suudaks muusikateostes muuta noote nii, et säiliks soovitud harmoonia/disharmoonia, rütm, atmosfäär ja kõik muu, mis üht muusikapala koos hoiab. Tekstidega on lihtne, need on selles mõttes ühemõõtmelised. Muusika puhul satuksime keerulisse tehisintellektivaldkonda.

Siinkohal peangi tunnistama, et kuna autorikaitsega on mindud suhteliselt ebameeldivate meetmeteni, siis tuleks appi võtta n-ö intellektuaaltarbija kaitse. Umbes nagu tavaline tarbijakaitse. Kahe aasta jooksul on pretensioonide esitamise võimalus. Kui saapal tuleb aas küljest ära, saan minna poodi ja müüjafirma on kohustatud mu saapa korda tegema või ta välja vahetama.
Kui ma nüüd avastan mingit Amazoni-stiilis autorikaitse all olevat teost lugedes, et sisu on muudetud, saaksin samuti minna kaebama, et miks mulle tahetakse panna süüks soovi teost kopeerida. Selline asi ei puutu ju üldse minusse kui heausksesse lugejasse.

Ja veel:

For example, mapmakers may insert deliberately inaccurate or fictitious roads or place names in maps. Enterprises that provide phone directories may insert fictitious listings into the directories. The intent of this falsified content is to be perceivable but not easily recognizable as "false content" to the casual viewer, including those who might want to illicitly copy the material.

Mõtiskleme edasi. Oletame, et meil on mingi keeruline ja kallis kommertstarkvara, mis juhuslikult on võimeline inimesi teise ilma saatma või neid invaliidistama. Siin on kaks aspekti: esiteks - tarkvara käitumise võltsimine tavakasutajale arusaamatul viisil ja teiseks, tarkvara koodi võltsimine heausksele arendajale arusaamatul viisil. Jällegi päris ulmelise keerukusega projekt, kui arvestada, et tarkvara tootjal-võltsijal on risk autorikaitse eesmärgil tehtud muudatustega tõesti inimesi tappa. Ja kui nüüd see muutmine toimuks lähtekoodi tasemel, siis pandaks vaene arendaja väga täbarasse olukorda. Proged, testid, veendud, et nagu toimib ja et ei tohiks midagi hullu juhtuda - ja siis tuleb mängu autorikaitse, kes natuke su koodi muudab... Tegelikult peaks ilmselt sellisel puhul tekkima täitsa uus tarkvaraarenduse metoodika, kus arendataks mitut paralleelset korrektset versiooni, kusjuures fantaseerida võiks ka automaatsete koodimuudatuste üle, mis säilitaksid tarkvara korrektse käitumise.

Peaks siinkohal lõpetama, et jääda mõistlikkuse piiridesse.

Mina ei ole seda usku

Lugesin soomlaste parlamendiraportit infoühiskonnast ja selle võimalikust loovusepõhisest arengustsenaariumist. Soomes ma pole elanud ja soomlaste hingeelu iseärasusi ei tunne, aga pigem arvan, et tegelikult ei ole mu tähelepanekud eesti ühiskonna kohta ka soome kontekstis valed.

Lugedes meenus mulle muuhulgas ühe mu keskkooliõpetaja mure n-ö arengumaade pärast, et ikka tuleks ilmtingimata neile haridust viia. Euroopalikku haridust Aafrikasse? Ma ei usu, et meie arusaamad elust on ainuõiged või kõige paremad.

Lisaks kangastus, et majanduslangusega seoses soovitatakse meil siin, et kui töötuks jääd, hakka ettevõtjaks. Ilmselt on seal mingi põhjus, miks soomlaste raportit lugedes just sellised asjad pähe lõid. Mulle tundub, et autor ei ole just väga hea inimestetundja.

Olgu, juttu oli Maslow väärtuste püramiidist. Joonised muide ei ole selle raporti tugevam külg. Aga kuna ma olen nimetatud püramiidist varem lugenud, siis sain enam-vähem aru. Kuidas aga tagada, et kui suurem osa inimestest ei ole tegelikult loovad ega ettevõtlikud, suudetaks luua just loovusel põhinev majandusareng, mis kõigi ühiskonnaliikmete põhivajadusi rahuldaks? Ausalt, kui käin Laitse poes süüa ostmas, siis 10 inimesest 9 on alkoholivines, tahab edasi juua ning ilmselt väga tööl ei tahaks käia.
Kui suurem osa inimesi ikka ei soovi luua ega areneda, ei soovi tunda ühtsust muu kui viinapudeliga, siis on veider loota, et saab eksisteerida mingi loovusepõhine heaoluühiskond ja loovusel põhinev majanduskasv. Innovatsioonist rääkimisega seoses unustatakse minuarust enamasti ära, et tõeliselt vingeid asju suudavad luua väga vähesed. Ja selle koha pealt rääkis soomlaste raport küll ju õieti, et kui teatud vajadused pole rahuldatud, tekib üleüldine kadedus ja pead tõstab vägivald.

Kurb tõsiasi on, et pole ilmselt olemas ühiskonnakorraldust, kus kõik teeksid igapäevatööna seda, mis neile kõige rohkem meeldib, ja saaksid tarbida kõike, mida ihaldavad, nii et sealjuures loodusväärtused säiliks ja kõik elaksid vanaduseni ilma suuremate haigusteta. Miks siis kirjutatakse kokku dokumente, mille põhiteema on just selline ideaalne ühiskond? Praktikas on olemas palju vajalikke töid, kus loovusega pole kohe mitte midagi peale hakata - töö prügimäel sorteerijana kasvõi.

Tõepoolest on kaasaegse Lääne ühiskonna üheks probleemiks see, et inimene on sunnitud jooksma hammasrattas, mida lükkab tagant üha kiirem areng. Ja probleemiks on muidugi, et üksikisikule on selle arengu motiivid jäämas üha kaugemaks. Lahenduseks loovuse ja ühtekuuluvuse hammasratas?

Minule tundub, et mingite ühiskondlike arenguprogrammidega ega ka riikliku võimlemiskavaga ei ole võimalik tegelikku igapäevast elu väga mõjutada.

Soomlaste raport näitas kahjuks, et ilmselt on mingi osa seltskonnast niivõrd elukauge, et ei märkagi enda kõrval inimest.

Täna ma kirjutan wikist

Uue meedia võimalustega seoses tuleb mainida, et ma suhtun kõikvõimalikesse vaba sisu esinemisvormidesse väga hästi, aga ise ei ole viitsinud väga ajaga kaasas käia. Kui välja arvata tööalased vajadused. Seepärast räägiks wikist seoses tööga ja võrdleks wikit traditsioonilisemate suhtlus- ja dokumenteerimisvahenditega, mida tarkvaraarenduses on kasutatud.








(allikas: 3nexus.com)



Tarkvaraarenduses käib töö lihtsustatult nii :

• Kliendil (välisel või firma mingil üksusel) on mingi soov. Ta oskab seda kuidagi kirjeldada, aga suht lünklikult ja muidugi üldse mitte tehniliselt.
• Firmas on analüütik või siis keegi projektijuhi-analüütiku sulam, kes kliendi ära kuulab ja kirja paneb, mida uuelt tarkvaralt või mingitelt täiendustelt-muudatustelt oodatakse.
• Tarkvaral, olgu ta juba olemas või mitte, on üldiselt nõuded, arhitektuur, komponentide disain ja kood. Ja ilmselt ka testid, kui tegu on hea firmaga. Mingi osa loetletust on kuskil kirjas. Kas kood on ühtlasi ka dokumentatsioon, selle üle vaieldakse. Aga kindlasti ei ole kood ainus kirjasolev asi ja seega lähevad ootused ja tegelikkus kindlasti kuskil sünkroonist välja.
• Tarkvara on vigane (olevikus või tulevikus) ja vead on kuskil kirjas. Paremates firmades on selleks veahoidlad, viletsamates firmades on vead kuskil e-mailides vms. Hea on, kui vead, veaparandused, dokumentatsioon ja tegelikkus kõik kooskõlas on. Kood on elab igas enesest lugupidavas projektis muidugi versioonikontrolli all, aga see ei taga kuskilt otsast koodi ja kõige muu kooskõlasolemist.
• Arendaja on tihti olukorra ees, kus ta hakkab millegi põhjal koodi kirjutama, aga nõuded muutuvad koguaeg ja tulemus peab muidugi olema kooskõlas viimaste nõuetega. Või siis läheb nii, et implementatsioonis on veel kuidagi kolmandatmoodi, sest nõuetele vastavalt ei olnud probleemi võimalik tehniliselt lahendada.
  

Mõelge, kui palju kommunikatsiooni tarkvaraarendus endas hõlmab ja kui palju on sünkroonist väljaminemise võimalusi. Võib isegi öelda, et tarkvara saab loodud muutuvate sisendandmete kiuste.

Wiki kujutab endast igavesti mõnusat vahendit tarkvaraarenduses liikuva info hoidmiseks, muutmiseks ja haldamiseks, kusjuures ärksamaid wikisid annab siduda veahoidlate, versioonikontrolli, RSSi ja muu sarnasega, tänu millele tekib wiki ümber elav protsess.
Jama on ainult siis, kui kasutatakse formaate, mis ei allu teksti diffimisele (kes ei tea, siis diffimine on kahe tekstifaili võrdlemine ja võrdlustulemuse väljastamine tekstikujul, kokkulepitud tähistustega). Näiteks ei allu diffimisele .doc-formaadis nõuded jne.
Kirjeldan nüüd eeltoodud tarkvaraarenduse protsessi osi ja osalejaid wikipõhise lähenemise kontekstis ja mainin iga punkti juures, kuidas varem tehti ja mis on piirangud.

• Head wikid oskavad majandada kasutajaõigustega. Kui meil on toimiv wiki, siis saab klient õiguse teatud wiki lehti külastada ja ka kommenteerida, mida vaja. Lisaks saab wiki kaudu ligi tarkvara väljalasetele (pakkidele, binaaridele vms). Ilma wikita oleks klient arendusfirmast või -osakonnast isoleeritud ja tarkvara versioonid jõuaks temani plaadil, mälupulgal või näiteks mingi FTP saidi kaudu, kus ei oleks jällegi võimalik näiteks viidata uues versioonis parandatud vigadele. Selle punktiga seoses mingeid väga suuri probleeme tekkida ei tohiks.
  
• Analüütik paneb muidugi kõik vajaliku wikisse kirja. Dokumente genereerib vajadusel ka wiki põhjal. Ilma wikita oleks kuskil kataloogid nõuete failidega, ilmselt eri versioonid lihtsalt eri failides, või siis kasutaks firma mõnd dokumendihaldussüsteemi. Siin on muidugi wiki sobiv ainult teatud firmadesse, teatud olukordadesse, sest wiki võib väga lihtsalt käest ära minna. Selleks, et wiki oleks hea analüüsidokude asukoht, peab keegi isiklikult selle eest hea seisma ja firmas peaks valitsema ka õhkkond, mis soosib tekstiformaati ja sellest vajadusel eri väljundite genereerimist.
• Tarkvara dokumentatsiooni hoidmine wikis on umbes samalaadi ülesanne nagu analüüsipoole hoidmine. Vaja on süsteemi, huvilisi ja arusaamist, et wiki on allikas ja kõik muu genereeritakse. Probleeme tekitavad kindlasti väliste vahenditega tekitatud joonised, see probleem on tegelikult ka analüüsidokude juures. Ja vanamoodne lähenemine oleks jällegi sama: failid kuskil kettal, näiteks .doc formaadis, samuti erinevate CASE-vahendite väljundvormaatides failid.
  
• Tark wiki viitab koodi- ja veahoidlale. Vanamoodsate vahenditega võib olla päris raske järge pidada, kus mingi nõue implemenditud või viga parandatud on. Eriti ilus on, kui wiki oskab kuvada mingit alamhulka veahoidlas püstiolevatest probleemidest ning väljavõtet versioonihalduse viimastest commit-idest. Raskused võivad ilmselt tekkida vigade-versioonide ja wikivaheliste ristviitamistega, e. kuidas ma viitan koodist mingile wikis kirjasolevale nõudele jms. Jällegi: vaja on huvilisi, süsteemi ja õiget wikit.
• Muutuvatest nõuetest võiks arendaja saada infot RSSi abil. Eriti on see hea, kui töötajad ei asu füüsiliselt samas hoones. Kui nõuet wikis muudetakse, võiks arendaja saada teada, millega seoses muudatus tehti ja lingi, kus see kirjeldatud. Vanamoodsam alternatiiv oleks, et projektijuht tuleb tuppa ja teatab, et tegelikult tahetakse hoopis naa, mitte nii. Kuna nõuete muutumine on tüütu nii või teisiti, siis wiki peale ülesehitatud protsessis ei satu projektijuht tuppa vähemalt kõige viletsamal hetkel - näiteks kui arendaja on just suutnud keskenduda koodile.
  

Hästi disainitud tooted müüvad end ise

Nii olla ükskord öelnud Digital Equipment Corporationi (DEC) juht Ken Olsen. Veel on ta ajalukku läinud väitega (tõsi küll veidi kontekstist väljarebituga), et pole vähimatki põhjust, miks keegi peaks omale koju arvutit tahtma. Ken oli inseneri taustaga ja tema firma oli oma rikkuse kokku ajanud miniarvutite (PDP, VAX) loomisega, seega turundus ja tollal veel olematu PC turu perspektiivikus ei sobitunud ilmselt kuigi hästi ta maailmapilti. DECil oli mitmeid tooteid, mille kvaliteeti siiani heldimusega meenutatakse (näiteks OpenVMS opsüsteem). Kahjuks viisid juhtimisvead selle suure firma hauda - firma, mis omal ajal oli IBMi järel maailma suuruselt teine infotehnoloogia ettevõte (tippajal 130000 töötajat).

Lähemalt räägin DECi protsessoriperest nimega Alpha. See oli 64-bitine RISC-tüüpi protsessoriarhitektuur, mida tutvustati esmakordselt 1992. aastal. Alpha oli oma aja kohta tehnoloogiliselt väga paljulubav ja sünnist kuni 90ndate lõpuni oli ta oma arengus i386-tüüpi protsessoritest aastaid ees.
Paraku polnud sellest kõigest kasu ja tänapäeval jookseb enaikus desktop- ja serverimasinates ikkagi i386 ja nii Alpha kui ka DEC ise on tänaseks unustusehõlma vajunud.

Lugesin Alpha ebaõnnestumise põhjuste kohta üht pikka ülevaadet ja selgub, et temaga seotud turundusvõtted ja muud otsused saab ainult ühtmoodi kokku võtta: "Nii ei tehta!"

* Suhtumine, et head toodet polegi vaja reklaamida. Maailmas on paraku küllaga näiteid, kus tehniliselt hea ja halva kuid hästi turundatu konkurentsis on peale jäänud viimane.

* Ei haaratud võimaluse avanedes kinni Apple'i koostööpakkumisest ja kaotati seega potentsiaalne tee PC turule. Apple valis oma protsessoriarhitektuuriks seejärel hoopis PowerPC.

* Alpha serverid maksid umbes 2 korda sama palju kui konkurentide samaväärse arvutusvõimsusega riistvara (mis ei olnud ka kaugeltki odav).

* Klientidel soovitati opsüsteemina kasutada Windows NT-d, Digital Unixit või OpenVMSi (just selles järjekorras). Windows NT, mis oli seega antud riistvara soovituslikeim OS, oli paraku 32-bitine ja eeskätt i386 turule mõeldud. Seega oli Windows NT Alphal aeglasem, kui riistvara võimaldanuks, ja enamus rakendusi ei toiminud. Oli küll olemas emulaator, mis suutis i386 binaare NT all jooksutada, kuid seda umbes 40% jõudluskao hinnaga. Olematu oli ka draiverite tugi, kuna ükski riistvaratootja ei olnud huvitatud NT jaoks Alpha draiverite kirjutamisest. Seda veidram on, et kõige vähem soovitas DEC kasutada omaenda OpenVMS-i, mis oli NT-le arhitektuuriliseks eeskujuks ja on siiani misioonikriitilistes süsteemides kasutusel. OpenVMS oli juba 20 aastat tagasi hajusa failisüsteemiga klaster-operatsioonisüsteem, mille klastrite "uptime'id" ulatuvad üle 10 aasta, kusjuures kogu raua võib jupphaaval välja vahetada ilma, et klaster sellest restarti peaks minema.

* OpenVMS ja Digital UNIX olid kallid ja niigi luksusauto hinnaklassis Alpha-põhiste masinatega ei tahetud kumbagi neist paraku tasuta kaasa anda.

* Kuigi NetBSD ja hiljem ka teised BSD perekonna liikmed ja Linux porditi 90ndate keskel ja lõpus Alphale, ei tahtnud DEC neist midagi kuulda. Ükski neist opsüsteemidest poleks olnud jõudluse või raua toe osas NT-st või DECi enda OS-idest halvem ja neist mõne toetamine oleks seega võimaldanud eelmise puntki mõju oluliselt vähendada.

Idealismist üksi ei piisa

"Sellise lutsu ostsidki?!" - küsis kolleeg ja perekonnatuttav mu mehelt, kui talle meie uuest "koduloomast" e. Openmoko projekti loodud Neo Freerunneri nimelisest telefonist rääkisin ja ta selle jutu ajel mehele helistas. Kõnekvaliteet oli olematu ning läbi müra ja ragina kostus mu mehe kauge, katkendlik ja robotlik hääl. Tore oli, et telefon kõnele üldse reageeris ja sleep-olekust välja otsustas tulla.
Tegelikult pidi Freerunnerist saama revolutsiooniline seade, millel suur puutetundlik ekraan, GPS ja multimeedia võimalused ning mis oli täiesti avatud - nii tarkvara lähtekoodi kui riistvara spekkide poolel. Avatud ta tõepoolest oli. Ja ilmselt ei oleks programmeerimisega mitteseotud inimene temaga üldse midagi peale osanud hakata.

Freerunnerist ja kõigist tema omadustest hakati rääkima aasta enne, kui Steve Jobs esimese iPhone-i versiooni tulekust teatas. Kätte saime telefoni aasta pärast iPhone'i turuletulekut.
Miks nii juhtus ja miks see telefon niivõrd ebaõnnestus?

Openmoko projektil oli küll üllas idee kasutada ainult avatud spekkidega riistvara, kuid nad ei osanud ilmselt uneski näha, kui keeruline võib olla riistvaratootjatelt selliseid komponente saada. Binaardraivereid aga polnud projekt nõus kasutama. Ja nii olid neil väga piiratud võimalused riistvarapoole loomisel.
Ja nagu sellest veel vähe oleks - Euroopas ei sobinud Freerunneri riistvara siin kasutuses oleva mobiilside sagedusvahemikuga, mistõttu ilmutas end riistvaradisaini viga ja kõnekvaliteet osutus olematuks. USAs jällegi ei saanud Freerunner hakkama osa sealsete SIM-kaartidega.
Avatud tarkvara aga tähendas seda, et peale telefoni kättesaamist oli vaja parandada hunnik vigu, et kasutajaliides talutavalt töötaks - näiteks et avaneks kontaktiraamat ja et telefon suudaks kõne vastuvõtmiseks üles ärgata.
Kõige toredam viga on siiski riistvaraline: selleks, et telefoni saaks laadida, on vaja kernel buutida, et too saaks kuhugi registrisse paar väärtust kirjutada. Niisiis ei tohi telefoni akut päris tühjaks lasta. Aga kui nii siiski juhtub, on lahendus olemas. Tuleb telefon ikkagi laadima panna ja mõned tunnid oodata. Kuigi aku ei lae, toimub kerge voolulekkimine ja kui hästi läheb, on Freerunner võimeline end nimetatud paari tunni möödudes siiski buutima. Et võimaldada laadimist.

Ja veel. Avatud lähtekoodiga tarkvara pidi tagama Freerunneri arengu. Nimelt lootsid Openmoko projekti loojad, et telefoni ümber tekib arendajate kogukond ja telefon saab seetõttu heaks ja populaarseks. Aga juhtus nii, et tekkis kümmekond eri distributsiooni, mis kõik üritavad Freerunneri tarkvara paremaks teha, aga keegi ei ole tõusnud esile ega saavutanud läbimurret.

Selline luts siis. Oleme kodus talle siiani kaks rakendust leidnud: robootika ja GPS.
Telefoniks ta ei sobinudki.

Pildil on Neo Freerunner rattalenksu küljes, Aegviidu kandis -7 kraadi juures talve nautimas.

IT ajaloo äpardusi (kolmes osas)

Selles ja kahes järgnevas postituses mõtistklen kolme IT ajaloo nähtuse üle, mis ei kuulu just väga edukate sekka.

Teemaga seoses meenusid mulle kõigepealt sellised seadmed nagu peilerid. Kutsuti ka piipariteks. Vähemalt paaril mu klassikaaslasel oli selline omal ajal vöö küljes, aasta võis olla umbes 1998.
Nüüd hakkasin mõtlema, et mis seade see selline oli ja mida ta võimaldas? Ja kuidas teda omal ajal reklaamiti? Ilmselgelt jäi ta hiljem jalgu mobiilside võimalustele ja kõikvõimalikele mobiili ja arvuti vahepeal olevatele seadmetele (PDA-d), võib-olla ka GPS seadmetele ning seda enam sellistele, mis ühendavad telefoni, meilikliendi, GPSi ja multimeedia.

Peiler on selline seade (pildil mingis moodsamas vormis):












Ta on tehniliselt suht piiratud ja ilmselt need, mida mina mäletan, võimaldasid vaid mingisugust ühesuunalist märguande moodi sidet. Hiljem tuli tekstisõnumite tugi, aga kellel seda enam vaja oli?
Tuleb siiski mainida, et kasutuses on peilerid siiamaani, nimelt päästeteenistustes ja kriisiabis üldisemalt. Väidetavalt peab peilerside katastroofiolukorras paremini koormusele vastu kui mobiilside.

Mobiilside, mobiilse interneti ja igasuguste kaasaskantavate seadmete valguses ei ole peiler kindlasti IT ajaloo edukate seas. Vähemalt ei kuule me temast üldse. Google'ist eestikeelseid vastuseid otsides leidsin mitu vana artiklit (jällegi umbes 1998. aastast), mis räägivad võimalusest saada peilerile teade saabunud e-mailist. Teenustasu oli sealjuures päris krõbe.

Võtame näiteks sellise lõigu (Äripäeva artiklist):
E-posti vastvõtmiseks sobivad igat tüüpi peilerid, kõige enam kasutatava kaubamärgi Motorola mudelid võtavad vastu teateid-elektronposti teavitusi järgnevas mahus: üherealine Motorola Express Ultra kuni kuus teadet, neist lukustatavad kolm teadet, kaherealine LX 2 võtab vastu 20 teadet, kümme neist lukustamise võimalusega, neljarealine LX4 20 teadet, lisaks 20 teate mällu salvestamise võimalus.


Meie arusaamad elementaarsetest kommunikatsioonivõimalustest on praegu ilmselt natuke teised.

test

test