Mari-Liisi ITSPEA blogi

16. detsembril ilmus Postimehes uudis " IT-spetsialistid soovitavad kõigil paroolid ära vahetada "  Antud artikkel tulenes eesti kodanike lekkinud kontodest ning nende paroolides, mis lahti murti. Uudisel on ka link, kus saab igaüks kontrollida, kas tema on sattunud ohvrite hulka või mitte ja ausalt öeldes leidsin ka mina ennast nende ohvrite seast, aga samas - ma vahetasin oma paroolid ära ja väga ei karda seda riski - miks? Põhjuseid on umber täpselt 2: 1) Ma ei kasuta ühte parooli mitmel lehel - jah ma tean, jube rakse on sellest kinni pidada nii, et uuesti gmail.com lehele minnes ei peaks parooli taastama hakkama. 2) Paroolid mida ma kasutan on täiesti jaburad tähtede ja numbrite ning sümbolite jadad - see omakorda veel keerulisem meeles pidada, aga ükski süsteem ei murra neid lahti, või noh tehniliselt on kõik võimalik, aga kui on minule lisaks veel 200 000 inimest, kelle parooli sai kordades lühema ajaga lahti murda, siis ma eeldan, et minu omaga ei vaevuta

"Community Created Content. Law, Business and Policy" on kirjutatud kolme soome advokaadi poolt 2007 aastal.  Raamatu eesmärk on võimalikult selgelt ja lihtsate näidete abil rääkida seadusandlusest, mis käsitleb sotsiaalmeedias käibel olevat õiguspraktikat ning ärimudeleid seal ümber.  Esmalt peatuti raamatus pikemalt autoriõigustel ning seejärel sukelduti just sotsiaalmeedia kogukondades kehtivatele reeglitele ning õigustele intellektuaalse omandi ja vara käsitluse üle. Põhiliselt toetuvadki litsentsid ja sotsiaalmeedia võrgustike seadusandlus suuresti autoriõiguste e raamatu esimese pikema peatüki sisule. Järgmisena selgitati raamatus litsentseerimist kui sellist, enamasti baseerus arutlus "Creative Commons" seadusandlusel ning selgitas selle alustalasid ning kasutusalasid, kuid kirjeldatati lühidalt ka teisi õigusakte. Lähemalt kirjeldatakse CC paindlikusest, mugandamisvõimalustest ning vabavara või tasulise litsentsi võimalustest. Sealjuures tuuakse näi

Meie seas on inimesi, kes peavad rohkem vaeva nägema selleks, et kastada infosüsteeme tulenevalt erilnevatest füüsilistest piirangutest. Ühed minule kõige rohkem huvipakkunud lahendused, millega vaegnägijateni tuua veebi lihtstam kasutamine, on reljeefsed riistvaralised lahendused. Mõte nende lahenduste taga on lihtne - vormil olev info edastatakse kasutajale punktkirjas, tekstuuriga pinna loomisel, helisignaalide või vibratsioonide näol. Kõige põnevam reljeefsetest lahendustest omakorda on minuarust reljeefne ekraan - mis tõsi,  on hetkel veel lapsekingades ning enamikel juhtudest võimaldab ekraanidel kuvada ainult klaviatuurinuppe, kuid vaegnägijatele on tulevikus sellel lahendusel väga palju potensiaali.  Näiteks on Disney Research arenduste tulemusena valminud just selline 3D ekraan, mis võimaldab edsatada erinevaid pilte ning infot vormil reljeefsena.  Siin muidugi on omad piirangud - nätieks ei ole võimalik edastada väga informatiivset suurte sügavustega struktuu

Arendus ja ärimudelid on asjad mis käivad käsikäes, ning mis mõlemas osas peavad olema paindlikud. Sellest annab ka aimdust väljatöötatud metoodikate arvukus.  Nüüd mis puutub reaalsesse töösse, siis tihtipeale ongi nii, et vastavalt sellest milline on sinu klient, milline on suhtlus kliendiga - sellest tuleneb ka metoodika mida arenduses kasutatakse. Sellest omakorda tulenevalt on üsna harv olukord, kus tehakse puhast Scrummi või puhast Waterfalli - enamasti mikstiakse mitut metoodikat kokku. Halb on olukord, kus ollakse kinni nö koolis õpitust - st ülikoolis tehakse selgeks, et Waterfall on sisuliselt see kus analüüs on ette valmis tehtud, nüüd kui töötan riigihangetega ja analüüs on ette tehtud, siis järelikult teeme selles üüratus projektis puhast Waterfalli ning välja tuleb SKAIS 2. SKAIS 2 ei ole muidugi erand, neid natuke keeruliselt lõppenud riigiprojekte on mitmeid, kus tulemus ei ole ühegi osapoole jaoks positiivne. Samas ma leian ka, et rakse on teistsugust tule

See on huvitav, kuidas IT-s tõesti on kirjutamata reeglid, millest kinni pidamine teeb ühe arendaja ARENDAJAKS. Ka meil Eestis on hinnatud pigem oskustega arendajad olenemata nende kraadist. Tihtipeale on arendajad enne kooli lõppu, osadel erandjuhtudel enne ülikooli algust, IT firmadesse ära värvatud. Küll aga oma töökohta silmas pidades, on igapäeva arenduses veel olemas mingid veidrad ootused töötaja suhtumisele, mis juskui kirjeldavad tema professionaalsust, aga mida koolis ei õpi: Probleemilahendus on kunts.  Probleemi lahendusse tuleb läheneda loominguliselt. Probleemidel ei ole õiget ega valet vastust ning teatud olukordades sa ei saagi teada mis oli õige ja mis vale. Enamasti on klient, kes udutab aiast, kui ta probleem on ikkagi selles augus aia sees ning selle parandus on asi, mida ei saa tingimata hinnata 1-5ni. St probleemi lahendus ei ole koolitöö kus on õige ja vale vastus Laiskus on voorus.  Mina omakorda olen arvamusel, et minu koodikirjutamise oskuse edasivi

Millegipärast on käibel endiselt ajast ning arust lähenemine, et IT-s on võimalik karjääri teha järgmiselt:  1) kõigepealt alustad nooremarendajana 2) seejärel liigud arendaja ja sealt edasi vanemarendaja positsioonile 3) siis tihtipeale saavad IT firma aru, et ahah - seda meest/naist ei tohi lasta kusagile minna ja ta on väga kasulik 4) Siit edasi edutatakse arendaja tiimi juhiks või arenduse juhiks või juhtide juhiks - asja iva on selles, et eeldatakse väga pädevast arendajast ka ühtäkki head oskust inimesi ja arendusprotsessi juhtida ning klientidega suhelda.   Nüüd siin lähevad asjad minu arust natuke valesti - ja seda mitmel põhjusel.  Esmalt asutus jääb endale vajaminevast ressursist ilma - hea arendaja, seda enam firma jaoks ei ole.  Teisalt nõuded juhile on kõike muud, kui oskus hästi tarkvara arendada. Seega võetakse oma ala spetsialist ja üritatakse teda pressida täiesti teise valdkonna raamidesse, eeldades head tulemust, sest et endiselt - ta ju oskab hästi