Atlassian Summit 2012, osa 3

Eelmise hommiku feilist tehti järeldusi ning viimasel hommikul ei saanud hommikusöök ka lõunaks otsa. Ilmselt mängis siin rolli eelmise õhtu pidu, sest rahvast oli saalis märksa hõredamalt.

Teist keynote‘i andis edasi Scott Farquhar, teine Atlassiani asutajaliige. Põhiliselt oli juttu JIRAst ja kuidas nad keskenduvad peamiselt kolme asja parandamisele:

1. Usability:

  • Quicksearch & JQL
  • Quick-create multiple issues
  • In-line edit in JIRA 5.1
  • Satisfaction for keyboard-junkies

2. Extensibility:

  • Remote issue links
  • Activity streams
  • REST APIs

3. Performance:

  • JIRA 5.1 is 40% faster than JIRA 4.4 with 200k issues
  • 5.1 handles 500k issues as good as 4.1 handled 200k.

Sõna anti ka New Relic esindajale, kes väitis, et 79% nende klientidest kogeb suurenenud arenduskiirust pärast nende Monitoring as a Service teenuse kasutusele võtmist. Ka Scott ise kiitis mehi ja vandus, et Atlassiani on nad samuti tohutult aidanud.

Teine külalisesineja oli Bob Kerner New York Stock Exchange-ist. Ta rääkis veidi agiilsusest ja oma tiimide juhtimisest, mõned huvitavamad mõtteterad:

  • Kellel pole midagi varajata, on agiilsusega päri, teised mitte nii väga.
  • Time to market jms on bogus, keskendu kvaliteedile ja replitseeritavusele ning kõik on korras.
  • Teamile pisikesed motivaatorid, nt kui issue’sid suletakse, käib vali kell või kui Bamboo build’id ei lähe katki, saab kogu meeskond õlut.

 

Bryan Rollins jätkas JIRA teemal. Jõudluse osas olevat lisaks eeltoodule veel paranenud garbage collector’is veedetud aeg (ca 2-3% vähem) ja committed heap size olevat samuti 20-30% väiksem (200k issuega). Ta tõi ka välja asjad, mis on seotud jõudlusega:

Mõjutavad:

  • Paraalleelsed kasutajad
  • Issue‘d
  • Custom field‘id
  • Õigused (permissions)

Ei mõjuta:

  • Registreeritud kasutajate arv
  • Projektid
  • Issue tüübid
  • Workflow‘d

 

Tehnilise poole pealt on nad muutnud oma load-testide platformi (JMeter -> Grinder), tõid välja JIRA Data Generator plugina mugavaks testandmete loomiseks ning toetuvad paljuski New Relic-u monitooringu andmetele, et jõudlust veelgi parandada. Enterprise kasutajatele on loodud ka know-how‘d sisaldav leht http://atlss.in/wegobig

 

Lahenduseks klasterdamisvõimaluse puudumisele on nad võtnud suunaks federation‘i – JIRAde eraldamine projektipõhiselt ja siis nende omavaheline ühendamise REST teenuste abil (ühendatud otsing, mugav issue‘de linkimine, kloonimine/liigutamine jne). Geograafilise hajutamise probleemi see kuigi hästi ei lahenda, aga nad tegelevad sellega, et JIRA toetaks Content Delivery Network‘imist ja staatilist sisu saaks serveerida Akamai sarnaste teenuste abil.

 

Avati ka  veidi kaarte, kuhu nad JIRA 5.2ga tüürivad – tulemas on issue‘de arhiveerimine ja tõsised muudatused IssueNavigator-is (instant results, in-place editing).

 

Edasi kuulasin Jay Rogersit rääkimas agiilsetest mustritest, tema mõtteterad:

  • Kõik ei saagi olla lõplik (this is the latest final design).
  • UI disainimisel proovi kasutada paberist välja lõigatud elemente (paper prototyping).
  • UX law – know the rules, break the rules (it’s all about listening).
  • User validation – nt igal neljapäeval kogu inimestelt tagasisidet oma toote kohta.
  • Kui ise ei jõua kõike teha, kasuta tasulist usability testimise teenust.

 

Atlassiani uute arendajate onboard’imise programmist sai ka natuke teada:

  • uued peavad endale ise selged eesmärgid seadma
  • neil on tavaks panna kõik newbie’d ühte füüsilisse asukohta
  • kogemust antakse nii erinevate toodete kui rollide lõikes
  • õppimine on tähtsam, kui millegi valmis saamine
  • väljakoolitamise aja- ja ressursimahukust ei tasu alahinnata
  • meetrikad programmi efektiivsuse mõõtmiseks: tagasiside ja code review’d

 

Claudio Ombrella Autodeskist rääkis JIRAst pärast 300k issue’t, kuid meie tiimi jaoks millegi väga üllatavaga ta välja ei suutnud tulla. Siiski mõned nopped:

  • Kliendi poolelt tuleks brauseri cache’i kaust jätta välja antiviiruse skännimisest.
  • Rakenduse poolelt tasub suurendada GreenHopper-i issue cache’i (tema puhul olevat 200k hea väärtus olnud).
  • Andmebaas võiks olla samas masinas JIRAga.
  • Võimalusel mitte kasutada SSLi.

Summit lõppes taas kord ilma igasuguse kära ja pidulikkuseta, lihtsalt pärast viimast ettekannet olid kõik toidunurgad tühjad ning inimesed voorisid vaikselt uksest välja. Pärast kiiret kõrvalepõiget Golden Gate Bridge-i juurde suundusin partnerite lõpupeole. Toimus veel viimne vennastumine, vannuti, et ollakse üksteisega ühenduses ning lasti huvitavatel roogadel ning värsketel veinidel hea maitsta. Mõnus punkt väga huvitavale üritusele.

Atlassian on teinud hämmastavat tööd, et nii lühikese ajaga on oma toodete ümber suudetud luua niivõrd laiapõhjaline ökosüsteem ja juba üle 1000 entusiasti otsustas sel aastal kokku saada. Järgmisel aastal kindlasti uuesti!

2 thoughts on “Atlassian Summit 2012, osa 3”

  1. Mis selle täpne mõte on?

    Kliendi poolelt tuleks brauseri cache’i kaust jätta välja antiviiruse skännimisest.

    Skännnitakse ju live trafficut, mitte salvestatud kausta?

  2. Antiviiruse softi põhimõte on ju skännida faile, et leida neist nakatumise mustreid. Faile leidub paraku ka brauseri cache’i kaustas ning kui keelata antiviirusel neid skännida, kaasneb sellega ilmselt väike võit kiiruses, sest neid saab kettale kirjutada ja sealt lugeda ilma lisa-tööta.

Leave a Reply

Your email address will not be published. Required fields are marked *