Hotfix release available: 2025-05-14b "Librarian".
upgrade now! [56.2] (what's this?)
Hotfix release available: 2025-05-14a "Librarian".
upgrade now! [56.1] (what's this?)
New release available: 2025-05-14 "Librarian".
upgrade now! [56] (what's this?)
ajutine
Table of Contents
Tiimikas 25.10.2011
- Osalesid: Rain, Taavi, Raul, Rene, Reet, Ain, Anu, Urve, Annika, Juri (teises osas)
Soojendus
- Raulil on küsimus, et kas nutikodu saab olema eraldi serverite peal?
- Küsimus on õhus, et nutikodu eest vastutavad Mati ja Priit, kes pole sellest ringist, kes dokumenteerimise kokkuleppeid teeb…
Raul & dokumenteerimine:
- Taavi - tutvustas tiimile, aga olulist arutelu ei tekkinud. Peab enne proovima, et tekiks arvamus. Taavi üritab pakkumiste lahendust wikisse dokumenteerida, kuid kuna seal uusi liideseid ei ole, siis on see keeruline/küsitav.
- Anu - liidesed on olemas, aga teenuseid nagu kirjeldama ei peakski. Kus on siis kirjas teenused (just PL/SQL)?
- Raul - wikis ongi rohkem tehnoloogia põhine info…
- kuskil dokumendis peaks see info olemas olema ja wikis siis viide sellele.
- teenuste nimekiri on wikis olemas, kuid pole sisendeid väljundeid ega seda, kes mingit teenust kasutab
- Anu - Anettes/Antos näiteks on teenuseid päris palju, kuid lootusetu nende kirjeldamine muidugi ei ole…
- üks näide on töödejuhtimine, kus ühtegi liidest juurde ei tule, kuid teenuseid uusi tuleb väga palju. Praeguse loogika järgi nagu ei tulekski töödejuhtimise kohta dokumentatsiooni midagi kirjutada
- eesmärk ei ole mitte ainult uut asja dokumenteerida vaid tekitada suur pilt, kus “kõik” info olemas
- ideaalis peaks olema nii, et kui keegi tahab hakata mingit uut teenust kasutama, siis ta küsib vastava lahenduse arhitekti käest luba ning arhitekt paneb wikisse uue kasutaja kirja. See peaks kindlasti olema 1 inimene, kes ideaalis on süsteemiarhitekt, kuid selline roll meil enamasti puudub (v.a. Argos, kus selleks on Juri). Praeguses seisus on see siiski pigem lahenduse arhitekt, mitte aga analüütik.
- Ain - pangas oli üks suur Rose'i skeem, kus kõigi süsteemide vahelised liidestused kirjas. Selle haldamiseks oli eraldi inimene. Meil on aga arhitektuuripildid rakenduse põhised.
- selle miinuseks on, et kõigil osapooltel pole vahendit (EA)
- kui teha väljatrükk, siis ei saa sealt otsida (täisteksti otsinguna)
- Otsus on, et hakkame koguma/kirjeldama detailselt ka teenuste infot
- alustame uutest teenustest
- hetkel parim koht tundub olevat ikkagi wiki
- Raul uurib, kas ja kuidas saada logidest infot milliseid teenuseid kes kasutab
- Raul mõtleb veel läbi kuidas teenuseid kirjeldada
- liides on kirjeldatud selle rakenduse passis, kes liidest pakub ning seal on kirjas ka sisendid ja väljundid ning mis suunas andmed saavad liikuda
- iga liidese iga kasutaja (rakenduse) dokumentatsioonis on kirjas, et tema seda kasutab ja mis suunas sel konkreetsel juhul info liigub
- oleks vaja teha üks hea näidis kuidas liideseid ja teenuseid kirjeldada
- Ain mõtleb, et mis asi PoC'ks võtta.
- kas ja kuidas teha wiki mingi osa partneritele kättesaadavaks? Hetkel wiki vaikimis avalik ja teatud lehed privaatsed. Esialgu peaks info kommunikeerimine käima läbi analüütiku.
- Raul räägib sellest Hannes Piirsaluga.
- ettepanek, et tabelite kirjeldusi ei hakka wikisse kirjtuama
- Ain pakub, et võiks olla EA mudel, millele wikist viidatakse
- mis asi on “viide arenduse dokumentidele”? V: eelkõige viide LiveLink'i kataloogile, kus iga arenduse dokumendid kirjas
- probleem sellest, et LiveLinkis on tellimuse/arenduse/projekti, mitte rakenduse põhiselt dokumendid
- suuremate projektide puhul on dokumendid LL's, aga väiksemate arendusete puhul on info lihtsalt Mantise kannetena või hoopis Argose “doku” kannetena.
- Rain - olulisem on hoida suurt pilti up-to-date. Arenduse dokumendid on väga spetsiifilised ning tegelikult muutuvad järgmise arendusega juba mitte ajakohaseks.
- JÄRGMINE NÄDAL JÄTKAME (01.11.2011)!
- Kuna Taavit ei ole (puhkus), siis ta leiab endale asendaja.
Argose arendusprotsess ja versioonikontoll
- sandboxis on live struktuur ilma kliendi arvete jms infoga
- arendaja peab testandmed ise tegema, mis enne iga unit testi käima laskmist vastava skriptiga baasi laetakse
- pakkumised jms teuleb skiniga otse sandboxi livest. Uus skin genereeitakse, kui live's tehakse mõni muudatus.
- siin tehakse vaid unit teste. UI testid on mujal (taram'is)
- kuidas käib UI's tehtud häälestuste kandmine versioonihaldusesse?
- tulemuseks peab olema skript ning seega tuleb see:
- A) muudatuse teinud inimesel käsitsi teha
- B) tekib Argose konfi liidesesse mingi nupp, mis muudatuse faili genereerib
- probleem tekib, kui mitu inimest muudavad sama pakkumist. Ehk tegelikult andmeid baasis (mitte struktuuri).
- tegu on tegelikult töökorraldusliku probleemiga, mis vajab kokkulepet, et ühte pakumist muudab vaid üks inimene
- küsimus on ka see, et miks üldse otse live's peaks konfi muutma?
- Rain vastutab, et Ain otsustaks, et kuidas selle teemaga edasi liigume (kas väiksemas ringis saavad osad inimesed kokku või kaasame hoopis veel rohkem mujalt osapooli jne.)
ajutine.txt · Last modified: 2019/09/20 15:52 by 127.0.0.1