E-ITSPEA

  Täna kirjutan nutikelladest, mida toodab üks lõuna korea firma väga lihtsa nimetusega Dot. Huvitav on see, et need nutikellad on mõeldud nägemispuudega inimestele ja kasutavad Braille kirja. Ekraanil on neli Braille dünaamilist sümbolit. Kasutaja saab seadistada kiirust, millega sümbolid muutuvad. Kellad on sünkroniseeritud nutitelefoniga bluetooth-i kaudu nagu tavalised nutikellad. Süsteem tõlgib informatsiooni rakendustest telefonis Braille kirja, mis hiljem ilmub kelladel. Niimoodi kellade kasutaja saab lugeda sõnumeid, otsida infot brauserist või õiget suunda navigaatorist ja muud. Kasutades nuppe, mis asuvad kellade külgedel, kasutaja saab saata telefonile lihtsad sõnumeid. Dot-il on avatud API, mis annab võimaluse arendada ja modifitseerida kellade funktsionaalsust. Kuidas ütlevad Dot, nende põhieesmärk oli lahendada kõige suurema probleemi, mis praegu on nägemispuudega inimeste seadmetel ja rakendustel: kõik nad "suhtlevad" kasutajaga helisõnumitega. See on tavalisel

Täna soovin rääkida kasutatavusest ehk kasutusväärtusest, kui mugav ja efektiivne on seade, programmi kasutamine ja kui kiiresti inimene saab sellega hakkama, ja minu elukogemuses on väga hea näide sellest. Enne karantiini olen töötanud ma hotellis teenindajana. Kui COVID tuli ja külaliste arv langes, ülemus tegi otsuse hotelli kinni panna remondile. Nii jäin ma ilma tööd ja pidin uut töökohta otsima. Kuu jooksul leidsin endale uue töökoha, kus olid peaaegu ainult plussid, võrreldes eelmisega, suurem palk, vähem tööd, väiksem ja sõbralikum kollektiiv. Miinused olid ka, ja üks nendes oli ja on siiamaani - kassasüsteem. Kui hotellis oli väga mugav, lihtne, arusaadav süsteem, millega inimene saab intuitiivselt töötada, siis baaris, kuhu ma tulin tööle, oli vastupidav olukord. Miks? Võin seletada. Alustan suurema kasutatavusega süsteemist, mis oli hotellis. Esimeseks see oli puututundliku ekraaniga, mis on mugavam kui hiir ja klaviatuur, sest see võtab vähem ruumi. Teiseks, oli süsteemsus,

Iterative Model ei vaja alguseks väga täpseid nõudmisi. Selle vastu kõik algab funktsionaali osaliselt realiseerimisega. Peale eelmise etappi testimist ja hindamist tulevad järgmised sihid ja nõuded ja protsess kordub. Vaheversioonid võivad olla mitteideaalsed aga töövõimelised. Kui me teame, mis on meie lõppsaadus, me liigume, arendame oma projekti ja teeme nii, et iga samm oleks produktiivne ja iga versioon töövõimeline. Miks ja kus on mõistlik sellist arendus mudelit kasutada? Esimeseks, kui meil on juba olemas täpsed ja arusaadavad nõuded lõppversioonile. Teiseks, kui projekt on suur. Põhieesmärk on olemas, aga realiseerimis detailid võivad muutuda ajajooksul.  Iteratiivse mudeli näiteks on speech recognition  või kõnetuvastus. Esimene kõnetuvastus masin oli AUDREY mida projekteeriti 1952. aastal Bell Labs. See oli analoogmasin, mis tuvastas sõnesid ja numbreid vahepausidega. See ei saanud populaarseks, sest oli väga keeruline, aga oli väga progressiivne idee. Täna kõnetuvastus pro

 Olen läbi lugenud ameerika tarkvara arendaja Eric S. Raymondi artikli "How To Become A Hacker" ("Kuidas saada hakkeriks"). Arvan, et see pealkiri, saab huvitada Interneti kasutajat, ja mõned, võib olla,  juba otsivad Google-st seda lootusega teada saada, kuidas Pentagoni häkkida või enda pangakontole paar nulle juurde kirjutada. Aga enne kui hakkate seda veebist otsima, informeerin teid, millest tõesti see dokument on, ja miks ma soovitan seda lugeda. Alustan sellest, et kui te arvate, et häkkerid just need inimesed, kes istuvad 24/7 oma korterites ja teenivad raha pangasüsteemide häkkimisega, ja just see teid huvitab, siis see artikkel on teie jaoks lugemiseks kohustuslik. Kui aga juba alguses autor räägib, kes üldse on häkker, millega ta tegeleb ja kuidas eristada häkkerit "kräkkeritest". Nüüd saime teda, kes on kes, ja liigume edasi.  Teine punkt räägib häkkerliku suhtumisest. Seletab, et meie maailm on täis probleeme, mis ootavad oma lahendusi, ja mik