Den siste mila
Innspurten i prosjekter er ofte en av de mest
slitsomme delene av et prosjekt. Å gjøre alt i et
prosjekt gjør det absolutt ikke noe enklere, og det
er en god erfaring å gjøre seg - har du sjangsen til
å ta et prosjekt fra A til Å på hobbybasis så er det
absolutt berikende!
Her er noen erfaringer/tanker jeg har gjort meg i innspurten:
For å holde koken oppe er det greit å ha oversikt over hva som står igjen og hva som mangler. Jeg er én utvikler og trenger et særdeles lettvekts opplegg. Jeg har i prosjetker benyttet alt fra excel til JIRA (sistnevnte liker jeg veldig godt), men for en person er det som å skyte spurv med kanoner.
Jeg har ramlet ned på å benytte FreeMind tankekart som er helt perfekt til denne oppgaven. Her kan jeg skrive ned tanker om design kombinert med TODO lister, enkelt sette prioriteringsmerkinger på oppgavene og flagge dem som ferdig etterhvert som jeg gjør ting. Utrolig flott verktøy - enkelt og kun det man trenger, spesielt når det holder at jeg kan nå det på en maskin av gangen. Kombinert med dropbox så kan jeg bruke samme filene enten det er fra laptoppen i stua eller arbeidsboksen.
Design er ikke min sterke side. Jeg ser hva som ser dårlig ut og jeg ser hva som ser OK ut. Heldigvis er det mange i verden som vil profilere seg med sitt design og de har laget maler som ligger tilgjenglig på nettet. For Fritt Regnskap så fant jeg en mal via nettstedet http://www.oswd.org/.
Tekstforfatting er heller ikke min sterke side. Jeg er ikke spesielt god på det, men jeg får da i det minste skrevet ned det jeg vil formidle. Her kreves det en god del viljestyrke, for det sitter langti inne å skulle levere noe som er bra her
Det viser seg også i tekstene som
blir produsert som gjerne trenger et par
gjennomlesninger før de bør se dagens lys. Og
selv etter det så trenger de en runde gjennom
noen andre også.
Det er for kunder helt greit å benytte tid på utrulling i kommersielle prosjekter. I prosjekter som jeg har utført som konsulent så har kunden bortimot aldri vært interessert i å ha slike punkter på arbeidslisten. De bekymrer seg relativt lite om det koster mye å legge ut løsningen - det er ofte på et annet budsjett enn utviklingsbudsjettet og med en utrulling i halvåret, med kanskje en patch hver måned, så ser de ikke behovet. Nå i utviklingsperioden så kan jeg finne på å rulle ut flere ganger daglig når jeg programmerer til stagingmiljøet mitt, og når ting er oppe å kjører for fullt, så vil jeg sikkert rulle ut til hovedmiljøet så snart jeg har noe som jeg er trygg på at virker.
Jeg har laget et opplegg hvor utrulling til staging er et script som jeg kjører lokalt på min maskin (kopi av server-phpkode og klientfiler (html+javascript) ut til Domeneshop. Der leggert det seg i en staging katalog og de regnskapssystemene som er flagget med å gå mot staging vil da være klare å teste det nye. Denne kopieringen tar 2-3 minutter.
For å flytte dem til staging til hovedløpet har jeg så laget en egen admin side hvor jeg kan sperre for aktivitet i løsningene med redigering av html melding til brukerne. Systemet blir lukket når en gitt fil ligger på filsystemet så stenging virker øyeblikkelig. Når systemet er sperret blir distribusjonsknapp aktiv; denne funksjonen kjører et script som ligger på serveren som kopierer filene fra staging til hovedløpet. Dette tar et minutt eller tre å kjøre, avhengig av hvor opptatt maskinene til domeneshop er. En utrulling fra min maskin og ut til alle vil da kunne gjøres på en ti minutters tid.
Regnskapssystemene har jeg fordelt i to databaser som jeg har tilgjengelig. På basis av adressen til systemet så hasher jeg dem inn i de 2 basene, og ett regnskapssystem har omtrent 20 tabeller med sin egen prefix. Slik kan jeg fordeler jeg altså flere regnskapssystemer i samme MySQL database. Denne teknikken fungerer glimrende, og dette vil i teorien la seg skalere lineært om jeg skulle ha behov for det.
I utgangspunktet regner jeg med å kjøre omtrendt 100 systemer per base, men først så vil jeg holde meg til 100 totalt for å unngå å nå maksgrensen for SQL trafikk som domeneshop har satt opp på sine systemer. Skulle det bli fryktelig populært kan jeg heller øke den grensen og se hva systemet kan tåle, og blir det enda mer populært enn det så får jeg tenke enda en gang til på hvordan dette kan ordens opp i
I og med at det rask blir svært mange tabeller betyr det at det å gjøre en oppgradering i databasen raskt blir et mareritt når antall databaser øker. For å være litt i forkant har jeg laget meg admin verktøy for å kunne kjøre sql i N tabeller. Dette er en veldig kraftig funksjon, men også en potensielt veldig skummel greie, så jeg har lagt inn et ekstra verifikasjonsledd som sender epost til en mailkonto med engangslink som må aktiveres for å verifisere at jeg ønsker å kjøre SQLen. Slik blir det i det minste noe mer usannsynlig at noen kan klare å lage bøll om de skulle få tak i passordene mine.
Her har jeg også laget admin funksjonen slik at jeg kan kjøre SQLene i staging tabellene mine først og se at ting blir slik jeg vil ha det. Deretter kan jeg utføre samme SQL kommando i resten av løsningene, så skulle noe gå skeis så har jeg kun rotet det til for meg selv.
Utrulling og backoffice funksjonalitet er elementer jeg strengt tatt ikke må ha for å få løsningen til å gå rundt. De har tatt en del tid å skrive, men til slutt er det tid jeg kommer til å spare på sikt. Her er det også viktig at løsningen vil hjelpe meg mot å gjøre feil i systemet som kan lage mye støy som igjen vil ta tid å rydde opp i. Jeg kunne benyttet den tiden til å lage enda mer funksjonalitet. i hovedsystemet, men det får heller komme senere. For eksempel når jeg får flere brukere enn én kunde
Ironien i det hele er at den totale tiden jeg har benyttet for å først splitte ett regnskapssystem i X systemer + backoffice system er på ingen måte noe som har tatt meg forferdelig mye tid. Jeg vil tippe at det hele oppsumerer seg til noe over et ukeverk når jeg er ferdig utviklet med det hele. I konsulenttid er det ikke direkte billig, men jeg vil tro at det er noe som kunne ha blitt sparet inn for de fleste prosjektene jeg har vært i. Klart, nå er utrullig av en PHP/web løsning ekstremt enkelt, men selv i de andre prosjektene som jeg har vært i så vil ikke utrulling være spesielt mye mer avansert enn det. (Et par ear filer som skal ut og noen databasescripts som skal kjøres)
Dette er definitivt en erfaring jeg skal ta med meg videre, og skal jeg tilbake til konsulentverden så vil jeg planlegge for utrulling og oppgradering fra starten av prosjektet. (Samt insistere på at dette er en veldig god idé...)
Her er noen erfaringer/tanker jeg har gjort meg i innspurten:
For å holde koken oppe er det greit å ha oversikt over hva som står igjen og hva som mangler. Jeg er én utvikler og trenger et særdeles lettvekts opplegg. Jeg har i prosjetker benyttet alt fra excel til JIRA (sistnevnte liker jeg veldig godt), men for en person er det som å skyte spurv med kanoner.
Jeg har ramlet ned på å benytte FreeMind tankekart som er helt perfekt til denne oppgaven. Her kan jeg skrive ned tanker om design kombinert med TODO lister, enkelt sette prioriteringsmerkinger på oppgavene og flagge dem som ferdig etterhvert som jeg gjør ting. Utrolig flott verktøy - enkelt og kun det man trenger, spesielt når det holder at jeg kan nå det på en maskin av gangen. Kombinert med dropbox så kan jeg bruke samme filene enten det er fra laptoppen i stua eller arbeidsboksen.
Design er ikke min sterke side. Jeg ser hva som ser dårlig ut og jeg ser hva som ser OK ut. Heldigvis er det mange i verden som vil profilere seg med sitt design og de har laget maler som ligger tilgjenglig på nettet. For Fritt Regnskap så fant jeg en mal via nettstedet http://www.oswd.org/.
Tekstforfatting er heller ikke min sterke side. Jeg er ikke spesielt god på det, men jeg får da i det minste skrevet ned det jeg vil formidle. Her kreves det en god del viljestyrke, for det sitter langti inne å skulle levere noe som er bra her
Det viser seg også i tekstene som
blir produsert som gjerne trenger et par
gjennomlesninger før de bør se dagens lys. Og
selv etter det så trenger de en runde gjennom
noen andre også.
Det er for kunder helt greit å benytte tid på utrulling i kommersielle prosjekter. I prosjekter som jeg har utført som konsulent så har kunden bortimot aldri vært interessert i å ha slike punkter på arbeidslisten. De bekymrer seg relativt lite om det koster mye å legge ut løsningen - det er ofte på et annet budsjett enn utviklingsbudsjettet og med en utrulling i halvåret, med kanskje en patch hver måned, så ser de ikke behovet. Nå i utviklingsperioden så kan jeg finne på å rulle ut flere ganger daglig når jeg programmerer til stagingmiljøet mitt, og når ting er oppe å kjører for fullt, så vil jeg sikkert rulle ut til hovedmiljøet så snart jeg har noe som jeg er trygg på at virker.
Jeg har laget et opplegg hvor utrulling til staging er et script som jeg kjører lokalt på min maskin (kopi av server-phpkode og klientfiler (html+javascript) ut til Domeneshop. Der leggert det seg i en staging katalog og de regnskapssystemene som er flagget med å gå mot staging vil da være klare å teste det nye. Denne kopieringen tar 2-3 minutter.
For å flytte dem til staging til hovedløpet har jeg så laget en egen admin side hvor jeg kan sperre for aktivitet i løsningene med redigering av html melding til brukerne. Systemet blir lukket når en gitt fil ligger på filsystemet så stenging virker øyeblikkelig. Når systemet er sperret blir distribusjonsknapp aktiv; denne funksjonen kjører et script som ligger på serveren som kopierer filene fra staging til hovedløpet. Dette tar et minutt eller tre å kjøre, avhengig av hvor opptatt maskinene til domeneshop er. En utrulling fra min maskin og ut til alle vil da kunne gjøres på en ti minutters tid.
Regnskapssystemene har jeg fordelt i to databaser som jeg har tilgjengelig. På basis av adressen til systemet så hasher jeg dem inn i de 2 basene, og ett regnskapssystem har omtrent 20 tabeller med sin egen prefix. Slik kan jeg fordeler jeg altså flere regnskapssystemer i samme MySQL database. Denne teknikken fungerer glimrende, og dette vil i teorien la seg skalere lineært om jeg skulle ha behov for det.
I utgangspunktet regner jeg med å kjøre omtrendt 100 systemer per base, men først så vil jeg holde meg til 100 totalt for å unngå å nå maksgrensen for SQL trafikk som domeneshop har satt opp på sine systemer. Skulle det bli fryktelig populært kan jeg heller øke den grensen og se hva systemet kan tåle, og blir det enda mer populært enn det så får jeg tenke enda en gang til på hvordan dette kan ordens opp i
I og med at det rask blir svært mange tabeller betyr det at det å gjøre en oppgradering i databasen raskt blir et mareritt når antall databaser øker. For å være litt i forkant har jeg laget meg admin verktøy for å kunne kjøre sql i N tabeller. Dette er en veldig kraftig funksjon, men også en potensielt veldig skummel greie, så jeg har lagt inn et ekstra verifikasjonsledd som sender epost til en mailkonto med engangslink som må aktiveres for å verifisere at jeg ønsker å kjøre SQLen. Slik blir det i det minste noe mer usannsynlig at noen kan klare å lage bøll om de skulle få tak i passordene mine.
Her har jeg også laget admin funksjonen slik at jeg kan kjøre SQLene i staging tabellene mine først og se at ting blir slik jeg vil ha det. Deretter kan jeg utføre samme SQL kommando i resten av løsningene, så skulle noe gå skeis så har jeg kun rotet det til for meg selv.
Utrulling og backoffice funksjonalitet er elementer jeg strengt tatt ikke må ha for å få løsningen til å gå rundt. De har tatt en del tid å skrive, men til slutt er det tid jeg kommer til å spare på sikt. Her er det også viktig at løsningen vil hjelpe meg mot å gjøre feil i systemet som kan lage mye støy som igjen vil ta tid å rydde opp i. Jeg kunne benyttet den tiden til å lage enda mer funksjonalitet. i hovedsystemet, men det får heller komme senere. For eksempel når jeg får flere brukere enn én kunde
Ironien i det hele er at den totale tiden jeg har benyttet for å først splitte ett regnskapssystem i X systemer + backoffice system er på ingen måte noe som har tatt meg forferdelig mye tid. Jeg vil tippe at det hele oppsumerer seg til noe over et ukeverk når jeg er ferdig utviklet med det hele. I konsulenttid er det ikke direkte billig, men jeg vil tro at det er noe som kunne ha blitt sparet inn for de fleste prosjektene jeg har vært i. Klart, nå er utrullig av en PHP/web løsning ekstremt enkelt, men selv i de andre prosjektene som jeg har vært i så vil ikke utrulling være spesielt mye mer avansert enn det. (Et par ear filer som skal ut og noen databasescripts som skal kjøres)
Dette er definitivt en erfaring jeg skal ta med meg videre, og skal jeg tilbake til konsulentverden så vil jeg planlegge for utrulling og oppgradering fra starten av prosjektet. (Samt insistere på at dette er en veldig god idé...)
|