Archive for the 'Tehnoloogia' Category

Feb 07 2009

IT järgmise 10 aasta trendid

Published by Targo under Innovatsioon, Tehnoloogia

Kuulsin mõni kuu tagasi Miha Kralj’i loengut sellest, mis IT-s järgmise 10 aasta jooksul juhtuma hakkab. Nüüd sattusid mulle need slaidid jälle näppu ja kuna tegemist oli tõesti huvitava loenguga, võtan teema ka siin arutusele, segamini oma isiklike mõtetega.

Ajaloost

1960. aastatel oli IBM infotehnoloogia A ja O, nad olid võitmatud ja miski ei saanud neid kõigutada. 1964. aastal tootis IBM ligikaudu 70% kõigist maailma arvutitest.

1990. aastate alguses oli firma aga katastroofi äärel, 1992 oli IBM-i kahjum 8,1 miljardit dollarit, mis oli tollal USA ajaloo rekord.

Mis siis juhtus? Asi polnud selles, et IBM-i inimesed oleks olnud rumalad – IBMis töötas mitmeid Nobeli ja Turingi auhinna võitjaid. Ka mitte selles, et IBMil oleks olnud halb tehnoloogia, ka selles osas on IBM pigem kiidusõnu saanud.

Tegelikult juhtus lihtsalt see, et tehnoloogia, millele IBM oli ise aluse pannud, hakkas muutma ühiskondlikke struktuure. Infotehnoloogia demokratiseerus ja peale kasvas uus põlvkond, kellel oli arvutitega hoopis teine suhe, tehnoloogia oli nende elu igapäevaseks osaks, mitte enam miski, mida valges kitlis onud hooldama ja paigaldama pidid. Tehnoloogia upgrade‘i tagajärjel toimus ka inimeste upgrade. IBM ei osanud seda uut demograafilist gruppi enam kuidagi käsitleda ja kaotas oma liidrikoha.
 

Inimestest

Sama protsess kestab tõusulainena edasi. Vaatleme näitena e-maili. 15 aastat tagasi oli see midagi esoteerilist, millega inimesed tegelesid hobi korras, aga see ei mõjutanud nende elu kuigivõrd. Praeguseks on e-mail lahutamatu osa minu elust, ma ei oska tõesti ette kujutada, kuidas ma ilma e-mailita suheldud saaksin. Ainus minu tuttav inimene, kellel e-maili pole, on ehk minu vanaema ja tema on tõesti juba väga vana. Võib-olla on neid inimesi veel, aga ilmselt peaksin ma neid mingiteks veidrikeks.

Samas ei ole mul näiteks rate.ee kontot. Kui ma selle endale teeksin, siis oleks tegemist lihtsalt mingi katsetusega, kindlasti ei viitsiks ma sinna massiliselt mingeid asju uploadida ja seal oma sotsiaalset elu elada. Aga minu 14-aastasel täditütrel on reidikonto loomulikult olemas. Samuti kõigil tema sõpradel ja üldse kõigil, keda ta oluliseks peab. Ja see ei ole tema jaoks kindlasti mingi katsetus, vaid täielikult integreeritud osa tema elust, täpselt nagu e-mail on osa minu elust. Ja mina olen tema jaoks samasugune vanainimene nagu minu vanaema on minu jaoks. Sul pole reidikontot? Aga… kuidas sa niiviisi elatud saad?

Miha Kralj tõi täpselt samasuguse näite. Kui ta saadab oma 15-aastasele lapsehoidjale e-maili, jääb see tihti nädalaks vastuseta. Kui ta aga jätab kommentaari tüdruku MySpace’i lehele, helistatakse 20 minuti jooksul.

Järgneb üks väga oluline tähelepanek: Kogu see rate.ee/MySpace/Facebook asi pole mitte mingi lastehaigus, millest inimesed läbi kasvavad ja seejärel “normaalset elu” elama hakkavad. EI! See generatsioon jääbki taolisi vahendeid kasutama, vahetades ehk keskkonna millegi “professionaalsema” (nt MySpace->LinkedIn) vastu, aga see jääbki osaks nende igapäevasest elust ja tööst.

  • Kümne aasta pärast jõuavad paljud rate.ee põlvkonna liikmed ühiskonnas ja IT-s otsustajate sekka ja ülejäänutel on parem selleks valmis olla, nii oma suhtlemisharjumuste kui ka IT-lahenduste osas.

Mida rohkem suhtlemist toimub virtuaalselt, seda olulisemaks saab inimestele nende virtuaalne identiteet. Internetis avatarina kasutatav pilt saab palju tähtsamaks kui see, millist ülikonda sa kannad. Ja kui me tahame teada, kes hakkab tulevikus näiteks ettevõtteid juhtima, tasub uurida, kes juhivad praegu nt World of Warcrafti klanne. Suure klanni juhtimine pole kaugeltki lihtne ülesanne, paljud sealkasutatavad virtuaalse organiseerimise võimed kanduvad üle virtualiseeruvatesse “päris” asutustesse.

Arvutitest

Töötasin kunagi väikeses firmas, mis pakkus muuhulgas ka interneti sissehelistamisteenust. Riistvara uuendamine käis nii, et osteti eraldi protsessor, mälu, kõvakettad, modemid jne, igaühe puhul parameetreid hoolega vaagides.

Ajad läksid edasi, põlve otsas interneti pakkujad söödi turult välja ja arvutitarnijate hinnakirjadesse ilmusid spetsiaalsed serverarvutid. Kasutajate arvud kasvasid hüppeliselt, varsti polnud ka üksikute serveritega enam midagi teha ja nad organiseeriti algul riiulite ja siis tervete kappide ehk rackidena.

Ja nüüd oleme olukorras, kus suured firmad ostavad korraga terve konteineritäie servereid, see tuuakse kohale raudteevagunil ja ostjal ei ole tegelikult selle konteineri võtit. Kui konteineri jõudlus langeb alla 95%  (ehk näiteks 5% seal sees olevatest CPUdest on otsad andnud!), tuleb kohale tehnik, kes vastavad osad välja vahetab.

Mees ja Koer tüüpi firma muidugi sellist teenust ei tooda ega tarbi ja riistvaratootjate seas on aset leidnud kiire konsolideerumine.

Järgmisel pildil on Miha slaidilt laenatud graafik, mis näitab turul aktiivselt tegutsevaid ja relevantseid riistvaratarnijaid:

  • See trend jätkub nii globaalsel kui lokaalsel tasandil – suure tõenäosusega pole mõne aasta pärast enamikku praegu tegutsevatest väiksematest IT-firmadest enam olemas.

Keskkonnast

Tuleme tagasi selle konteineri juurde: peamine tähelepanuväärne detail pildil on kolm jämedat kaablit, mis serverisse sisenevad: need on elekter, jahutusvesi ja võrguühendus, mis iseloomustavad hästi ka järgmisi trende.

Globaalne soojenemine ja keskkonnakaitse on praegu väga poleemilised teemad. Enamasti süüdistatakse keskkonnahädades transporti jms “vanu” majandusharusid. IT-d peetakse trendikaks ja keskkonnasõbralikuks. Tegelikult kulutab IT aga sama palju energiat kui lennundus!

Arvutustehnika arengu peamiseks piirajaks on praegu elektritarve ja sellega kaasnev jahutusvajadus (mis tarbib omakorda energiat). USAs ehitati data centereid omal ajal Floridasse, Californiasse, New Mexicosse… aga enam mitte. Kuna “kolmas toru” ehk võrguühendus on samuti oluliselt jämedamaks muutunud, pole asukoht enam oluline ja osutub võimalikuks valida lokatsiooni tervest maailmast. Põhja-Ameerikas said populaarseks põhjapoolsemad, jahedamad, aga ohtra hüdroenergia piirkonnad. Kui me aga vaatame tervet maailma, siis kust võime leida odava energia, jaheda kliima ja haritud tööjõu? Islandilt.

Gloobuselt vaadates asub Island kenasti Ameerika ja Euroopa vahel ja sobib seega uueks globaalseks keskuseks. Meie jaoks on jutu moraal aga selles, et

  • Globaliseerunud maailmas liiguvad raha ja lahendused silmagi pilgutamata kõige soodsamasse asukohta.

Seesama blog, mida te praegu loete, asub tegelikult mingis Hong Kongi serveris. Aga võibolla on ta nüüdseks kolitud näiteks Filipiinidele, mul pole õrna aimugi. 10 aasta pärast teavad vähesed IT-inimesed, kus nende rakendused tegelikult jooksevad, ja mis nendega madalamal tasemel toimub, kõik on virtualiseeritud, rakendused ja andmed on võimalik ühe nupuvajutusega hoopis kusagile mujale ümber tõsta. Tarkvara, mis selle vajadusega ei arvesta, ilmselt kasutusele ei võeta.

Siit koorub välja veel üks tähelepanek: kui me teeme sedasama, mis meie naabergi, paneb konsolideerimise trend meid lõunaks nahka ja ei tee teist nägugi. Mõni suurem tegija tuleb ja pakub sama teenust (olgu see siis riistvara, tarkvara, hosting või muu) suuremamastaabilisemalt ja odavamalt ja meie kliendid ongi läinud. Seega tuleb meil vaadata, mida teised ümberringi teevad… ja siis teha midagi muud.

5 responses so far

Nov 24 2008

Tech-Ed’i märkmed III

Panen kirja, mis veel Tech-Ed’ist peas meeles, edasi tuleb juba välismälu kasutama hakata.

Arendusprotsess

Roy Osherove rääkis huvitavalt sellest, kuidas kirjutada hästi (automaat)testitavat koodi.

Miks automaattestimine hea on, seda teavad ehk kõik, aga kordamiseks:

  • Regressioonide vältimine (ehk parandame üht asja ja teine läheb katki)
  • Varajane vigade avastamine (väga oluline tarkvaratootmise põhiteoreemi seisukohalt)
  • Nõuete parem mõistmine
  • API dokumentatsioon (kui keegi peab seda APIt ka kohe kasutama, kasvõi testide otstarbeks, saab dokumentatsioon palju parem)

Koodi testitavust saab hinnata selle alusel, kui lihtne on meil:

  • Tekitada suvalise objekti instantsi (sest tihti on seal sada erinevat sõltuvust).
  •  Saada samale testile alati samu tulemusi
  • Testida ainult üht komponenti korraga, ilma teisi puutumata
  • Kontrollida komponendi sisendeid ja väljundeid
  • Isoleerida komponenti tema sõltuvustest ja liidestest

Mitmesugused isoleerimisvajadused on sageli lahendatavad dependency injectionitega, mille kohta leiab veebist juba põhjalikumat lugemist.

Targo märkus: See kõik ei tähenda muidugi, et kogu kood peab alati automaattestidega kaetud olema ja kõik kohad dependency injectioneid täis. Igal projektil on oma iseärasused, vahel ei anna automaattestiimine mingit võitu, vahel aga on see projekti õnnestumiseks möödapääsmatu.

SharePoint veel kord

Südantsoojendav oli kuulda Ishai Sagi ettekannet SharePointi custom field type’idest. Seda seetõttu, et olen ise ühe päris radikaalse custom field type’i projekti realiseerinud (Business Data field type MOSS 2007-s) ja kui on mingi tehnoloogia, kus ma ilmselt maailma top 100 eksperdi seas olen, siis on selleks SharePointi fieldide customiseerimine :P

Edasi, SharePointiga tegelemiseks üks huvitav gadget on Content Query Web Part:

  • Laseb sooritada päringuid üle mitme listi (mitte küll SQLi stiilis joine)
  • Väga hea jõudlusega, cache’ib asju intelligentselt
  • XSLi põhine customiseerimine

http://blogs.msdn.com/ecm/archive/2006/10/25/configuring-and-customizing-the-content-query-web-part.aspx

http://office.microsoft.com/en-us/sharepointdesigner/HA101741341033.aspx

Abivahendid veel

Tess Fernandez pidas ühe parima debugimise ettekande, mida ma kunagi kuulnud olen, demonstreerides mitmesuguseid vahendeid, nii neid, mida ma juba teadsin, kui ka uusi.

Minu isiklikuks lemmikvahendiks on kindlasti SOS, mis on mitmel korral lasknud mul keerulises olukorras kangelast mängida. Ja samuti on mul iga kord hea meel, et me elame managed koodi ajastul, kus meil on võimalik nt kogu heap mälu läbi käia ja vaadata, mis objekte sealt seest leiab. Yum.

Kellele Tessi mainitud vahendid võõrad on, saab downloadida ka demo, kus üksikasjalikud instruktsioonid sees.

Järgmine TechEd EMEA on juba Berliinis, mis pole novembrikuus ilmselt enam nii hea variant kui Barcelona. Aga samas ka ehk mitte nii hull kui Tartu.

No responses yet

Nov 22 2008

Tech-Ed’i märkmed II

Published by Targo under SharePoint, Tehnoloogia

Jätkan Tech-Edi asjade kirja panekut.

Äri

Ikka ja jälle üleskerkivaiks teemadeks mitmetes ettekannetes olid SOA, Cloud, SaaS, Azure jne.

Põhiideedeks siis, et tulevikus:

  • Me kirjutame rakendusi teenustest, mida me ise ei loonud
  • Paigaldame neid masinatele, mis pole meie omad
  • Liigutame neid “pilves” ühest datacenterist teise, kruvides lihtsalt mingit graafilist mudelit

Jutu moraal tarkvaraarendajatele:

  • Muuta oma tarkvara kasutatavaks (veebi)teenuste kaudu
  • Tarkvara võiks koosneda protsessikesksetest taaskasutatavatest komponentidest
  • Algoritmid opereerivad järjest rohkem ärimudelitel ja DSLil
  • Uurida võimalusi, kuidas klassikalised rakendused saaks ära kasutada “pilve” teenuseid

Azure

Azure’i puudutavatel teemadel oli mitu ettekannet päevas. Põhiideed siinkohal:

  • Virtualiseeritus. Vastavalt oludele ja vajadusele tekitatakse Windows Serveri instantse.
  • Kettaruum (storage). Vastupidav, skaleeruv, kättesaadav ja sisaldab harjumuspäraseid abstraktsioone
  • Hooldus. Teenuseid tekitatakse ja nende elutsüklit majandatakse automaatselt

Iga uus arenduskontseptsioon algab Hello Worldist. Azure’i Hello Worldi saab näha siin. Põhiline müügiargument asja juures muidugi see, et asi töötab täpselt nagu tavaline ASP.Neti arendus. Azure annab aga automaatselt:

  • Keskkonna, kus kood jookseb
  • Riistvara (mingis anonüümses konteineris ja data centeris)
  • Võrguühenduse
  • Paigalduse ja konfigurerimise
  • Isolatsiooni
  • Koormuse balansseerimise

Ja nagu ülalolevalt diagrammilt näha, pole Azure mitte ainult inimeste enda koodi hoidmiseks, vaid seal on muuhulgas võimalik kasutada ka SQLi (sh nii andmete hoidmiseks kui ka klient<->pilv sünkimiseks, pluss tavalised andmekaevanduse, andmepuhastuse ja -transformatsiooni jm ülesanded, pluss mitmesugused “entsüklopeedilised” andmekogud ehk reference data), SharePointi, Dynamicsit jms asju.

Sharepoint veel

Commerce Serveri järgmine väljalase, koodnimega “Mojave” sisaldab muuhulgas olulist SharePointi integratsiooni. Ehk siis näiteks Commerce Serveri shopping cart, arve näitamine, kataloogiotsing jpt asjad on kasutatavad SharePointi web partidena.

Samuti on Commerce Serveri kasutajad integreeritud SharePointi User Profile’idega, saab kasutada sama autentimist (forms authentication) jne.

Mojave peaks kättesaadav olema 2009 kevadest.

SharePointi osas oli veel suur tung üritustele, kus räägiti featurede ja solutionite loomisest. Ilmselt on tegemist asjaga, mis inimestes segadust tekitab, kordan seepärast põhiideed üle:

  • SharePointi customization on see, kui sa muudad mingit konkreetset saiti.
  • SharePointi solution on taaskasutatav põhjade ja komponentide hulk, millega sarnast customizationit mitmes saidis luua. Solution on see, mille sa tavaliselt SP serverisse paigaldad ja solutioneid saab luua Visual Studios.
  • Solution koosneb featuredest. Feature võib sisaldada menüüsid, linke, listipõhju, listiinstantse, event handlereid (ehk siis põhimõtteliselt igasugust SP peale ehitatud koodi) jmt elemente. Saidil on võimalik featuresid sisse ja välja lülitada.

Vt. lähemat infot siit: http://sharepoint.microsoft.com/blogs/mike/Lists/Posts/Post.aspx?ID=7

Ja siin on hulk väga lahedaid inimeste poolt valmis tehtud featuresid, mida oma saidile lisada: http://www.codeplex.com/features

Solutionite ja featurede loomiseks ja paigaldamiseks on mitmesuguseid lahedaid abivahendeid, mainiksin siin:

WSPBuilder (http://www.codeplex.com/wspbuilder) – vahend SharePointi solutionite automaatseks genereerimiseks. SharePointi custom koodi deploy toimub tavaliselt „solutionite“ abil, mis sisaldavad XML faile, kus paigaldatav kraam kirjeldatud on. WSPBuilder automatiseerib nende failide genereerimise.

STSDEV – (http://www.codeplex.com/stsdev) – genereerib Visual Studio solutioneid, mis omakorda sisaldavad põhjasid tüüpiliste SharePointi ülesannete lahendamiseks (nt kuidas lisada ja deployda uut lehekülge).

Andmebaasidest veel

Koolis õppisime klassikalist andmebaaside teooriat, mis on kenasti kolmandal normaalkujul, neil on konkreetne schema, transaktsioonid toimivad, kõik on mustvalge.

Uutes süsteemides on nii palju andmeid ja neid hoitakse laiali nii paljudes arvutites, et andmete kvaliteedi ja tähenduse mõisted muutuvad häguseks.

  • Rangelt defineeritud välisvõtmete ja andmebaasiseoste asemel on sõnmid, documendid, lingid, vormid
  • Konkreetsele schemale vastavate tabelite asemel on laiendatavad, erineva või üldse tundmatu semantikaga andmeallikad
  • Piiritletud andmehoidla asemel on kusagilt streamitavad andmevood
  • Range lukustamise ja transaktsioonide asemel on OK, kui mina muudan andmeid ja sina muudad andmeid ja pärast pannakse asjad korda.
  • Täpsete vastuste asemel on meil pidevalt muutuvad andmed ja selleks ajaks kui arvutus tehtud saab, võib vastus juba vale olla

Ühesõnaga, me ei ela enam ilusa, puhta DDLiga kirjeldatud maailmas.

Tüüpiliseks näiteks on siin Amazoni veebipood, kus klassikalisi transaktsioone eriti ei rakendatagi. Laos võib olla viimane eksemplar mingist raamatust ja sina ja mina ostame mõlemad selle ära. Tekkinud tõrge parandatakse hiljem ja ühele meist saadetakse vabandus. Amazonil on ladusid paljudes erinevates geograafilistest paikades, seal muutuvad seisud pidevalt, samuti tellivad miljonid kasutajad kogu aeg mingeid asju. Kui me tahaks sellele süsteemile rakendada rangeid transaktsioone, siis:

  • Tsentraalse andmebaasi puhul ei piisaks meile ka maailma suurimast ja kiireimast arvutist, et seda süsteemi töös hoida.
  • Hajusandmebaasi puhul võtaks andmete korrektsuse kontrollimine nii palju aega, et kasutaja ei jõuaks seda ära oodata. Samuti võib juhtuda nii palju erinevat sorti tõrkeid, et ta saaks arvestatava tõenäosusega mingi vea, kuigi tegelikult on kõik korras.

Ühesõnaga, süsteemi 100% kättesaadavus on palju olulisem kui andmete 100% korrektsus ja vigu on võimalik hiljem parandada – tees, mis vana aja andmebaasiteoreetikutes ilmselt külmavärinaid tekitab.

Abivahendid

Kui keegi veel ei tea, siis Fiddler (http://www.fiddlertool.com/fiddler/) on veebiprogrammeerija ning eriti AJAXi programmeerija parim sõber. Kogu veebitrafficu jälgimine, filtreerimine, breakpointide seadmine, omatahtsi pakettide modifitseerimine… ‘nuf said.

Jätkub veel…

No responses yet