Jaga ja valitse – SharePoint ja sõbrad

See tuleb nüüd selline kokkuvõtte jutt kuumadest teemadest consumerization ja governance, peamiselt SP võtmes, aga ka muidu. Terminite tõlkimisega on muidugi probleeme:

  • Consumerization on tarbimine või tarbimiskultuur ehk siis IT vaates on kasutajad praegu pigem tarbijad, kellel on valikuvõimalus ja kes ootavad kvaliteetset teenust
  • Governance on umbes nagu haldus, aga laiem, alustades strateegilisest tasandist ja lõpetades administreerimisega.

Teemad on omavahel üsna tihedalt seotud, vähemalt minu peas – mida rohkem käitub kasutaja kui tarbija, seda suuremad on tema ootused, seda rohkem vajame me korrektset haldust. Minu jaoks olid need (eriti haldus) kokkuvõttes ühed olulisemad teemad, mis mitmetest ettekannetest läbi jooksid. Proovin oma mõtted ja argumendid ritta ajada, mis pole aga üldse nii lihtne,  sest nagu Dan Holme ütleb: “It’s complex, but not necessarily difficult”.

Peamiselt refereerin siin OSP233, Managing the SharePoint Disruption with End-to-End SharePoint Governance (Dan Holme), aga ka OSP01-LNC, 36 Terabytes: How Microsoft IT Manages SharePoint in the Enterprise (Jim Adams ja Nate Bruneau) ja FDN03, Enable Consumerization of IT (Ward Ralston), lisaks keynotes jms

Aga proovime pihta hakata.

Infoühiskonna probleemid on ammu teada:

  • Infot on palju
  • Info on killustatud/mitmes kohas/mitu erinevat versiooni
  • Erinevad inimesed võivad näha ainult teatud infot
  • Erinevad inimesed tahavad näha ainult teatud infot
  • Inimesed tahavad näha seda infot igal pool, igal ajal, iga seadmega

Selge pilt, mängu tuuakse tuleb SP, mis kõike seda võimaldab. Aga just võimaldab, mitte ei tee. Tihti arvatakse, et SP (või jumala eest mingi muu tehnoloogia) on just see hõbekuul, mis kõik probleemid lahendab. Kahjuks mitte, vajadus seda hallata jääb siiski alles, kuid eriti SP puhul tuleb puuduliku halduse puhul löök varem või hiljem. Ja see saab olema valus. SharePoint kasutab filigraanselt ära entroopia iseeneslikku suurenemist – kui selle (st SP farmide jms) eest hoolt ei kanta, siis lähevad asjad metsa:

  • kellelgi pole aimu, mis SP sees toimub – palju on seal saite ja mis info seal, kellele see info kättesaadav on (turvalisus!)
  • ei kasutata mitte SharePointi, vaid mingeid muid, mittetoetatuid vahendeid (turvalisus!), sest ei teata/osata
  • SP kasutatakse valedel eesmärkidel ja asjadeks, milleks see mõeldud pole – tulemuseks aeglane ja/või mittetoimiv süsteem
  • lõppkokkuvõttes nagu midagi oleks, aga äril sellest olulist kasu pole

See ongi see koht, kus meil peaks olema korralik haldus(strateegia).  Halduse eesmärk on nüüd ja tulevikus pakkuda kasutajatele võimalikult valutult parimat teenust. Haldus peaks sisaldama:

  • ootuste juhtimist, eesmärkide seadmist (ka pikemas perspektiiviks)
  • muutustega kohanemist
  • eeskirjade ja reeglite väljatöötamist
  • riskide ja tulude (võimaluste) tuvastamist
  • rollide ja vastutuse määramist
  • tulemuste (sh kõige eelnimetatu) kontrollimist

Soojenduseks tuleb aru saada, et ilma halduseta lähevad asjad valesti ja nagu eelnevalt mainitud, eriti SP puhul. Kui see arusaamine on olemas, saab hakata nuputama, kuidas asju kuidagi rööpasse ajada ning seal ka hoida. Kõige olulisem on mõista, et SP on strateegiline otsus ja strateegiline platvormi valik:

  • jah, me armastame Microsofti
  • jah, me hakkame SP kasutama
  • jah, me hoolitseme selle eest

Juhuslik SP on ikaldus (ma nagu oleks seda kuskil juba öelnud?). SP käib kokku kõigi muude MS toodete-tehnoloogiatega, alates Windows Serverist, MSSQList, AD’st ja IISist ning lõpetades Exchange, Office ja Lynciga. Ilma nendeta on SP kasutegur väga küsitav. Samuti ei ole investeering – nii rahaline kui ka inimestesse ja aega (teadmised!) – ainult ühe projekti puhul eriti mõistlik. SP on ühe projekti jaoks kallis ja keeruline, tõenäoliselt on ühe spetsiifilise eesmärgi täitmiseks ka odavamaid, lihtsamaid ja paremaid asju, aga SP võib olla hiilgav ja väga võimas ning suhteliselt odav platvorm – kui sellega korralikult ümber käia. Kui sellega ei käida korralikult ümber, siis on ta ka mitme projekti jaoks kallis ja ebaefektiivne. Arvestada tuleb nii ROId (Return on Investment), aga võib-olla hoopis rohkem ROId (Risk of Inaction), mis tähendab jälle seda, et kõik läheb metsa, kui me õigesti ei tee ja ka kasust on sel juhul asi kaugel.

(Mulle tuleb sellega seoses alati meelde üks tšuktšianekdoot:

Tšuktšile kingitakse mootorsaag Družba, kusjuures uueks päevanormiks on 5 ruumi puid. Tsuktsile oli see enne käkidegu. Alustab lõikust. Lõikab ja lõikab, kuid päevanormi täis ei saa. Ka järgmistel päevadel ei tule üle 3,5 ruumi. Ülemused mõtlevad, et milles on asi. Lähevad asja uurima. Üks komisjonist näitab, kuidas tema Družbaga saeb. Tsuktsi vaatab ja imestab:
“Kui mina saagisin, siis ta küll ei põrisenud!”

Kõiki asju on võimalik valesti kasutada, eksole)

Et SP on pikema-ajaline strateegiline ja poliitiline otsus, tuleb ka poliitikast aru saada – kes ja miks SharePointi tahab, keda see mõjutab (kes on kasutajad) ning kuidas selle kõige vahel ellu jääda ja normaalseid tulemusi saada.

Kui meil on strateegilises plaanis olemas arusaamine, et SP on meie platvorm ja nüüd teeme sinna peale mingi projekti, siis noh, see on nagu tarkvaraprojekt ikka, aga omade konksudega. Alustuseks äripoole vajadused:

  • Mida me tahame ehk tulemused
  • Miks me tahame ehk äriline vajadus
  • Kellele seda vaja on ehk poliitika
  • Kuidas me seda hindame ehk mõõdupuud (metrics)

Seejärel tuleb projekt ellu viia – sh lahenduse arhitektuur, realisatsioon, paigaldused jms, mis on üleüldse omaette teema. Kõige olulisem on aga nagu iga tarkvaraprojekti puhul, et kõik sõltub eesmärkidest (=äri vajadustest), skoopi tuleb suuta hoida ning otseteid ei tohi võtta – maksavad hiljem kätte (tuleb tuttav ette?).

SharePointi mõttes on kriitiline koht arhitektuuri paikapanemine, sest siia alla läheb lisaks füüsilisele ja loogilisele arhitektuurile ka infoarhitektuur koos kõigi oma reeglite ja standarditega. Just selles kohas tuleb tihtipeale välja organisatsiooni nõrkus – suurem osa süsteeme ei laseb asju teha ka suvaliselt, nt võrguketas ei küsi sinult nt lepingute salvestamisel ette, kaua sa seda alles hoida tahad, kes seda nägema peaks (nt erinõuded salajastele või isikuandmetele), mis tema metaandmed on jne. SharePoint küsib, sest need on olulised küsimused ja reeglina tagavad kogu organisatsiooni parema toimimise. Siinkohas peab siis analüütik (või kesiganes sellega tegeleb) äripoolelt need vastused välja pressima – kuidas ikkagi tegelikult olema peaks? Kui äripoolel ei ole vastuseid, siis tuleb need ise välja mõelda, aga kindlasti peab äripool need heaks kiitma. Konks on muidugi selles, et absoluutselt kõik on omavahel seotud – äri vajadused, infohalduse strateegia ning loogiline ja füüsiline arhitektuur. Aga noh, see kõik on tarkvaraprojektipuhul tavapärane. Ebatavaline on SP otseste rangete nõuete puudumine, selle asemel on vajadused, strateegiad ja arhitektuur, mis on kõik läbiräägitavad (või -röögitavad, sõltuvalt temperamendist). Loomulikult mingis faasis tekivad nõuded, aga alguses on vajadused ja variandid, kuidas SP neid rahuldada saab, seega harjumatult suur osakaal on konsultandil/analüütikul/lahenduse arhitektil. Nii mõnegi projekti puhul ei ole vaja koodi võibolla üldse kirjutadagi, aga seda rohkem on vaja seadistust ning ettekirjutust, kuidas seda lahendust õigesti kasutama peaks.

Ütleme nüüd, et traditsioonilises mõttes on meil projekt “valmis”, st mingi osa läheb live’i. Nüüd on vaja seda ka käigus hoida ja vastavalt vajadusele parandada. Vajadus kindlasti tuleb, sest tarkvaral on rumal komme muuta maailma ja seega ka äripoole vajadusi, millest kõik alguse saabki. SP puhul tuleb uuenduste stsenaariumid samuti hoolega läbi mõelda, sest

  1. uuendada tuleb SharePoint ennast, vastavat lahendust (kohandusi) ja sisu
  2. lahenduse ja sisu piir on üsna õrn, näiteks CSS, mida hoitakse laaditeegis (jah, nii on Style Library eesti keeles), ning mida saab muuta seega otse live’is, rääkimata õigustest jpm

Ehk siis liiklus ei käi mitte traditsioonilisel suunal test->live vaid teatud juhtudel ka vastupidi, suunal live->test.

Kasutajate kaasamine on iga projekti võtmeküsimus. SP on suur ja kipub inimesed ära hirmutama, seetõttu tuleb seda teha ettevaatlikult:

  • müüa SP maha ehk näidata kuidas konkreetsete kasutajate mure saab kiiresti elegantse lahenduse
  • koolitada väheseid vajalikke asju ja muus osas pakkuda materjale – kogu SP ei õpi keegi ära, see ajab ainult segadusse. Jällegi – kiired ja lihtsad lahendused, mida SP konkreetsete kasutajate muredele pakub
  • teha SP omaseks ja isiklikuks – branding ja muu turundusteema

See võib hardcore nohikule tunduda selline ümmargune pehme möla, aga kahjuks on see oluline. Meil võib olla maailma parima funktsionaalsusega tarkvara, aga kui seda ei kasutata, siis pole sellest suurt kasu…

Niisiis, meil on live’is projekt, kasutajad kasutavad ja kõik on hästi. Võib vist asjad kokku pakkida? Ilmselgelt vale vastus. SP tuleb jälgida. Hooldada ja teha vajalikke seadistusi või muudatusi, sealjuures need dokumenteerida (miks ehk äri vajadus; mis ehk muudatus; kuidas ehk tegevus või protseduur) ning tungivalt soovitatavalt ka automatiseerida – tuleb pikas perspektiivis odavam (tagab järjepidevuse, kvaliteedi ja korratavuse). Muidu on meil olukord – “jah, oli küll ükskord varem midagi taolist, ma midagi vist tegin ja nagu hakkas tööle, aga ma enam ei mäleta, mis see oli”. Jälgida tuleb nii ühte projekti kui kogu SP keskkonda tervikuna ning ka ärivajaduste kontekstis:

  • kas kõik  vastab algsetele vajadusetele?
  • kas vajadused on muutunud?
  • kuhu läheme edasi?

Ja siis tuleb edasi minna ning teha kõike seda uuesti. SP pole ühekordne projekt. SP on strateegiline valik, lõputu teekond ja areng (isiklik kasv ja muu new age). Tuleb meeles pidada, et SP vajab tegelemist, peavad olema paigas strateegiad ja protseduurid ning tuleb teada, mida tuleb teada;), edasi on juba lihtne.  “It is complex, but it’s not difficult“.

TL, DR: SharePoint on suur ja väga võimas, aga vale kasutuse korral on verd, higi ja pisaraid väga palju, seetõttu tuleb kogu üritust algusest saadik hoolega rööbastel hoida, asju õigesti teha ning seejärel kogu aeg silma peal hoida. Et SharePointi on mõttekas kasutada mitmeks projektiks, tähendab üks kord halvasti tegemist mitu korda selle kirumist.

Ja nüüd ma jõuan oma ivani. Eesti on väike ja ainult vähesed ettevõtted on tegelik SP sihtgrupp, mis kasutab kõiki võimalusi (vt SP kui strateegiline valik). Tihtipeale ostetakse endale SP koos mingi lahendusega, endale täpselt asjast aru andmata, millega tegemist on. Siinkohal peab tarnija (peamiselt projektijuhi isikus) ilmutama lausa üliinimlikke võimeid ja kõik selle ülalpoolkirjutatu selgeks tegema nii oma ülemustele kui ka tellija poole juhtisikutele:

  • SP tuleb läbi mõelda
  • SP tuleb monitoorida
  • SP saab ja tuleb muuta vastavalt uutele vajadustele
  • kasutajaid tuleb koolitada ja koolitada ja siis veel koolitada
  • SP ei ole tavaline tarkvaraprojekt

Kui nende asjadega ei arvestata, siis üldiselt on tulemuseks ühel (tellija pole rahul) või teisel (kahjumis) viisil halb projekt. Mõlemal juhul saab vastu pead tarnija (peamiselt projektijuhi isikus), kuigi objektiivselt võivad puudujäägid olla hoopis tellija organisatsioonis. Ehk siin on nüüd suur karvane küsi- ja hüüumärk, kuidas neid riske kõigile osapooltele tutvustada ja mitte isegi pähe, vaid juba selgroo sisse tampida.

Kogu see teema oli minul juba enne TechEd sügaval olemas, aga ma ei osanud seda kuidagi sõnastada, lihtsalt oli selline näriv tunne, et kuskil on midagi väga olulist… Nii et kui OSP233 sel teemal alustas, siis ma oleks nagu valgustatud saanud:) Loodetavasti suutsin midagi edasi ka anda.

Lingid:


Agiilne arutelu agiilse arenduse teemadel

Nagu eelnevalt mainitud, olen mina üks vähekogenenud Scrum Master, aga proovin saada paremaks ja käisin TechEd Europe 2012 raames kahel üritusel –  AAP309 juba kirjutasin, aga lisaks ka BOF07, An Agile Talk on Agile, Peter Provost ja Klaus Even Enevoldsen. Et selle kohta slaide/salvestust pole, panen peast;)

Formaat oli iseenesest geniaalne. Põhimõtteliselt toimus arutelu nagu Scrum:

  • tekitati teemade (küsimuste) backlog
  • hinnati prioriteedid. Igal inimesel oli kaks häält.
  • võeti küsimused sprindis (10 min) ette
  • Sprindi lõpus:
    • Hääletati, kas küsimus on vastatud. Kui vastatud, siis oli tehtud, kui ei, läks tagasi backlogi
    • Lisati uusi teemasi backlogi ja hääletati prioriteedid ümber

Teemad oli ka muidugi huvitavad:

  • Kuidas kaasata tiimi liikmeid (eriti neid, kes vastu punnivad)? Selgitada, õpetada ja harida, kui see ei aita, siis võib-olla polegi vastavat liiget vaja? St üks tõrvatilk rikub poti mee ja korralikult toimiv tiim kaalub üles ühe (või paar superstaari). Jah, alguses on ilmselt raske, aga pikas perspektiivis on sellest rohkem kasu.
  • Mis on agiilse tarkvaraarenduse tulevik? Sama, mis kogu tarkvaraarendusel – continuous delivery ehk pidev tarne. Järjepidev koostöö ja tagasiside, arenduse ja nö hoolduse piiride hägustumine.
  • Kui palju on vaja ette analüüsida? Nii palju, kui on vaja? St kasutuslugudele, mis kunagi töösse võib-olla ei jõuagi, pole väga mõtet aega kulutada, samas peab arendustiimidel olema alati tööd võtta, samuti nõuab täpsemate hinnangute andmine mingil tasemel analüüsi. Ehk siis mida kõrgemal mingi lugu backlogis on, seda detailsem analüüs peab olema tehtud. Kui ülesanne liigub sprinti, peab olema arendajale vajalikul tasemel analüüs tehtud.

Kõrvamärkus: vahel juhtub, et tehakse mingi asjaga tööd, aga sprindi lõpus otsustakse, et ikka ei ole valmis ning prioriteetide ümbervaatamisel selgub, et võib-olla me ikka ei taha seda. Ja see on täiesti normaalne.

Edasi sai aeg kahjuks otsa, aga sellegipoolest oli väga äge ja formaat, nagu öeldud, geniaalne. Hiljem küsisin veel Peterilt eraldi, et kas ja kuidas on võimalik teha agiilset arendus fikseeritud aja, raha ja nõuete korral. Vastus:

  • sisemiselt saab Scrumi teha, kuigi kliendivaates pole sellel väga mõtet (sest kõik tuleb kindlaks ajaks ära teha)
  • hinnangute andmisel anna hinnanguid ja korruta need 3. Või 5. Või 7. Kui sa aga tõepoolest projekti tahad, siis suured ninad keelduvad asju läbi korrutamast, mis ei muuda aga töö suurust. Seega reeglina võidab sellised pakkumised see, kes pakub ebareaalset hinda/tähtaega. Kui sina võidad, siis tõenäoliselt saad rahaliselt vastu pükse.
  • üldiselt – need on halb variant, aga teinekord võib kliendi sissesöömiseks neid kasutada.

Agiilsed ajahinnangud

Juhtumisi olen mina meie tiimi Scrum Master (võrdlemisi vähekogenud) ning ühtlasi aegajalt puutun kokku ajahinnangute muu sellisega. Seega sai käidud kahel Scrumi/agiilse arenduse loengul/arutelul, soojenduseks võtame esimese ehk AAP309, Making Agile Estimation Work,  Stephen Forte ja Joel Semeniuk.

  • Ajahinnangud
    • Aegade algusest on tarkvaraarenduses olnud ajahinnangud probleemsed – tavaliselt valed, liiga optimistilikud.
    • Ajahinnang on hinnang (=ebatäpne, vastavalt hetke parimatele teadmistele, mis on ), mitte lubadus.
    • Anna ulatus, mitte üks number.
    • Ära anna hinnangut õhust, küsi täpsustavaid küsimusi – hinnang läheb täpsemaks.
    • Määramatuskoonus – alguses on sinu hinnang ebatäpne ~4x (nii üles kui alla, st hinnanguliselt 1 aastane projekt võib võtta 3 kuud-4 aastat), aga läheb järjest täpsemaks. Ajahinnang on täpne siis, kui projekt on lõpetatud.
    • Tuleb endale tunnistada (ja teistele selgeks teha), et ajahinnangud on subjektiivsed ja muutuvad.
    • Algne hinnang ongi ebatäpne ja peab muutuma (tuleb ümber hinnata), kuid läheb täpsemaks vastavalt sellele, kui hästi me probleeme tunneme.
  • User stories ja story points
    • Väärtus kasutajale. As a <role> I would like to <action> in order to <the goal or business value>. Peaksid sisaldama ka vastuvõtukriteeriume – millal on valmis. Ei tohiks olla liiga pikk (üks lõik). Hiljem lüüakse väiksemateks (arendus)ülesanneteks. Liiga väiksed tükid hinnangu andmisel suurendavad ebatäpsust.
    • Inimestel on raske hinnata mingi asja suurust, aga lihtne võrrelda. Seega on meil baaslugu, millel on kindel arv punkte. Kõik tulevased kasutuslood hinnatakse võrdluses sellega – 2x suurem, 2x väiksem, sama jne. Eelis võrreldes tundidega on nt see, et erinevate inimeste hinnangud võivad sisaldada erinevaid asju – puhas arendus vs arendus koos testimise, projektijuhtimise, paigalduste, koolituste jms. Võrdlus on kõigil aga sama. Alles kunagi hiljem tõlgitakse punktid ümber tundideks.
    • Punktide andmine – planning poker, siis ei mõjuta teiste hinnangud. Tuleb leida konsensus, ühine arusaamine. Kui hinnangud on väga erinevad, saadakse asjadest erinevalt aru ja tuleb see läbi arutada.
  • Backlog
    • Backlogis võib olla maksimaalselt 3 (või midagi taolist) kõrge prioriteediga tööd, 5 keskmist ja ülejäänud madalat
    • Prioriteet ja hinnangud on seotud, seega võiks eelnevalt hinnata ja siis prioritiseerida
    • Iga sprindi lõpus uued kasutuslood, bugid, hinnangud ja prioriteedid, seega muutub ka backlog ja seega järgmise sprindi sisu!
  • Velocity
    • Palju story pointe suudab tiim sprindi läbida. Muutuv suurus, aga samuti muutub täpsemalt sprintide käigus.
    • See on see koht, kus story points tõlgitakse ümber tundideks!
  • Re-estimate
    • Mõõdame tulemusi ja muudame vastavalt sellele hinnanguid.
    • Siin selgub, kas me oleme graafikus projekti lõpetamise mõttes. Lõpetamiseks minev aeg=(Backlog (punktides)/sprindi velocity (punktides))xsprindi pikkus. Alguses on hinnang jätkuvalt ebatäpne! Arvestada ka parandusteks kuluvat aega.
    • Kui ei ole graafikus, tuleb midagi muuta (traditsiooniline aeg/kvaliteet/funktsionaalsus kolmnurk)

TL,DR – agiilne arendus tähendabki pidevat muutumist: muutub backlog, hinnangud, ajakava, kasutuslood. Hinnangud ongi defintsiooni järgi alguses ~4x valed, aga lähevad projekti edenedes paremaks, mida paremini me tunneme ülesandeid, tiimi jms.

Lugemisvara:

  • User Stories Applied – Mike Cohn
  • Agile Estimating and Planning – Mike Cohn
  • Agile Retrospectives –  Esther Derby, Diana Larsen
  • slideshare🙂 – Stephen Forte, Joel Semeniuk

Muidu – väga huvitav ja mõnus huumor, mitmeid “ma tean, mida te tunnete”-hetki. Nii tore, et ma pole ainus.

 


SharePoint 2010, ADFS ja claims

Ehk siis mida tarka ma õppisin TechEd Europe 2012 eelseminarilt PRC01  Building Federated External Access for Microsoft SharePoint 2010 (John Craddock):

  • Claims ja Federation – mingi Identity Provider (IP) annab meie rakendusele info kasutaja kohta, autentimine toimub tema juures, vastu saame Security Tokeni (ST). Usaldus on kahepoolne, st STS usaldab rakendust, rakendus usaldab STSi (kaks sertifikaati). STSina saab kasutada ka näiteks Facebooki, LiveID, Google jms.

Claims ja Federation suhtlus (John Craddock, http://blog.xtseminars.co.uk/what-is-federated-identity-and-authorization)

  • Autoriseerimine toimub rakenduses vastavalt saadud claimile. Kõik  Security Token Providerid (STS) saavad ise claime ümber kirjutada vastavalt vajadustele (nt lisada teatud IP (mitte segi ajada IPga) kaudu autenditud kasutajatele kindel roll). Seal saab kasutada ka muid andmeallikaid (Attribute Stores), milleks võib olla AD, LDAP, SQL või muu taoline andmebaas. Kui me lisame SPle Custom Claims Provideri, toimib ka tema nagu STS.
  • ADFS – konfigureerimine läbi PowerShelli (PS).  SPTrustedIdentityTokenIssuer tuleb luua, et saaks vastavat STSi valida. Ühel Web Applicationil võib olla mitu STSi ja üks STS võib olla mitmel Web Applicationil.
  • Claimide lugemine: tegelikult on Claim objekt, millel on tüüp, väärtuse tüüp, väljaandja ja väärtus. SP konverteerib need stringideks:

John Craddock, XTSeminars

Home Realm Discovery (kaks valikut)

  • SP teeb kasutajatel vahet sõltuvalt sellest, mis STS kaudu nad ennast autendivad (nt sama kasutaja otse AD või AD läbi ADFS autentides on erineva kasutaja). Võib põhjustada segadusi, seega on targem jätta ainult üks variant.
  • Küpsised! ADFS küpsised (4 erinevat http://blogs.technet.com/b/geoffrey_carlisle_on_idm__security/archive/2010/10/13/common-adfs-cookies.aspx) ja SP Web Application küpsised (FedAuth). SP küpsised peavad olema persistent (st mitte-sessioonipõhised), kui tahetakse kasutada Office’it. Ühtlasi peab olema sait ka brauseri arvates trusted. Vaikimisi  on FedAuth kestus (TokenLifeTime) 60 min (kuigi kirjas on 0). Ühesõnaga, erinevad küpsised vaatavad, kas kasutaja on autentitud SP mõttes ja STS mõttes. Seadistus sõltub olukorrast ja turvakaalutlustest. Võimalus on ka sliding sessions.

Küpsised, John Craddock, XTSeminars.co.uk

  • Väljalogimine – millest me välja logime, ainult SP või ka STS? Mõistlik on välja logida ka STSist. OOTB SharePoint seda ei tee, vaja kirjutada koodi (tekitada eraldi leht). Omaette teema on ADFSist välja logimine – tuleb välja logida ka kõigist WA või muudest asjadest.
  • Claims Augmentation (claimide ümberkirjutamine, suurendamine, transformeerimine?) – kõige mõistlikum on claime hallata AD FSis: grupeerimine, metaclaims ja claims store
  • User Identity Store – kust me saame infot kasutajate kohta (nt SP profiili jaoks)? Kasutaja info import, andmete võtmine claimist (aga seal ei pruugi just palju olla), eraldi andmete kogumine (nö registreerumine)
  • UAG? http://www.microsoft.com/en-us/server-cloud/forefront/unified-access-gateway.aspx
  • ADFS deploy – kui me ei luba enam Windowsi autentimist on ainus viis, kuidas rakendustele ligi saada = kriitiline komponent. Alati farm, saab laiendada, dubleerida jne. Proxyd, tulemüürid…
  • Üldiselt hakkabki elu nii käima, vaja on väga mitme osapoole koostööd – arendajad, IT, konsultandid jpt

TL,DR – jah, SharePoint, claims ja ADFS töötavad ka OOTB, aga vähegi viisakama kasutuskogemuse jaoks on vaja arendajatel ka tööd teha.

Lingid:

Kes rohkem kuulda tahab, mis seminaril näidati või räägiti, võib minuga ühendust võtta.

Muidu – oli väga hariv ja silmi avav päev. Nii mõnigi “ahhaa-koht” tuli ette ja ütleme nii, et oleks kõike seda sügisel teadnud, oleks hulka aega ja närve ilmselt kokku hoidnud. Aga parem nüüd kui mittekunagi. Igal juhul suur tänu John Craddockile meeldejääva päeva eest ja mõni teine kord jälle.


TechEd Europe 2012

Esimene kord sellist üritust külastada ja väga tore oli. Asjasse mittepühendatutele teadmiseks, et tegu on Microsofti korraldatava suure konverentsiga, kus on 5000-10000 osavõtjat, igas ajaaknas paralleelselt 10-20 sessiooni (loengut), lisaks TechExpo (nö messiala) ja HOL (hands-on labs, käed-külge labor?), kus saab arvuti taga erinevaid stsenaariume läbi mängida. Põhiosa kestis teisipäevast reedeni, esmaspäeval oli eelkonverents (Pre-Con).

Konverents oli tore, Amsterdam oli tore ja mulle hullult meeldis. Targemaks sain ka, vähemalt enda arvates. Kuulamas käisin järgmisi asju (sessiooni kood on link Channel9 materjalidele):

  • PRC01 Building Federated External Access for Microsoft SharePoint 2010, John Craddock. Minu kokkuvõte
  • KEY001, TechEd Europe Keynote with Brad Anderson and Jason Zander
  • KEY002, TechEd Europe Keynote with Antoine Leblond
  • FDN03, Enable Consumerization of IT, Ward Ralston.
  • BOF07, An Agile Talk on Agile, Peter Provost ja Klaus Even Enevoldsen. Minu kokkuvõte
  • BOF15, Surviving Public Speaking, Alex de Jong
  • OSP01-LNC, 36 Terabytes: How Microsoft IT Manages SharePoint in the Enterprise, Jim Adams and Nate Bruneau (Channel 9 Põhja-Ameerika sama asja video).
  • ECR06, Exam Cram Session on Exams 667 and 668: Microsoft SharePoint Server 2010, Radi Atanassov
  • OSP231, Developing and Managing SharePoint Solutions with Microsoft Visual Studio, Jay Schmelzer
  • AAP309, Making Agile Estimation Work,  Stephen Forte ja Joel Semeniuk. Minu kokkuvõte
  • OSP233, Managing the SharePoint Disruption with End-to-End SharePoint Governance, Dan Holme. Minu kokkuvõte koos üldise jutuga
  • DBI207, BI Power Hour, Adam Wilson, Matthew Roche and Jen Stirrup
  • OSP333, Best Practices for Building Your Website for Scale with Microsoft SharePoint 2010, Spencer Harbar
  • OSP337, Branding and Customizing My Sites with SharePoint 2010,  John Ross and Randy Drisgill
  • DEV307, JavaScript: The Language, Andrew Miadowicz
  • WSV316, Clouds and Your Organization: A (Former) Professional Economist’s View for IT Pros, Mark Minasi
  • OSP433, Deep Dive on SharePoint Ribbon Development and Extensibility, Israel Vega and Richard diZerega

Nagu juuresolevalt pildil näha võib, siis keskendusin peamiselt SharePointile, aga mujal oli ka huvitavaid asju. Käin neid jupikaupa ka läbi ja huvitavamatest teen eraldi kokkuvõtted.

Lisaks loengutele veetsin piisavalt aega ka HOL  sektsioonis, jätkuvalt siis SP ja natuke ka BI teemadel. Lisaks loomulikult TechExpo aladel uudistamine ja muu seltskondlik tegevus. Päevad venisid lõppkokkuvõttes üsna pikaks…

Muuseas oleks Amsterdam RAI keskus täiesti hiilgav koht sise-o läbiviimiseks, ma hakkasin umbes teise päeva lõunaks aru saama, kust kuhu saab.

Veelkord – väga äge oli.