Har du styr på dine ord?

Ellers lad mig skrive din pressemeddelelse, din jobannonce eller teksten på din hjemmeside.

Er det et nyhedsbrev, et salgsbrev eller produktinfo du har brug for, så er det det jeg hjælper dig med.

Måske har du allerede selv skrevet teksten og har bare brug for et par andre øjne på den, lidt sparring eller en tur igennem korrektur-vridemaskinen.

Er det hjælp til opdatering af din hjemmeside du har brug for, eller ideer til hvordan du får mere ud af din tilstedeværelse på nettet, er det også mig du ringer til.

Lad mig sætte ord på dine tanker og ideer, og hjælpe dig med at få den opmærksomhed du fortjener.

Hvis du har en opgave du vil tale med mig om, eller du vil høre mere om hvad jeg kan hjælpe dig med og hvad det koster, så kontakt mig på 3117 2724 eller line.bornemann@gmail.com

xoxo Line Bornemann – Communicationista

Når ideerne bare kommer væltende…

Ja, det kan skam være både inspirerende og overvældende. Mest det første, lidt det sidste. Det der ofte sker, når man kommer i gang – rigtig i gang – er jo at der kommer fart på udviklingen, og ideerne og inspirationen kommer rullende ind over én, og man må holde tungen lige i munden for at sortere og strukturere, så man ikke pludselig prøver at løbe i alle retninger, fordi det hele bare er uh, så fedt. Det er det jo, men det skal det også blive ved med at være, og derfor må tankerne og ideerne systematiseres.

Åh, hvor lyder det bare boring – og ikke særlig kreativt! Men nu er jeg jo heller ikke kunstner. Jo, jeg elsker det jeg laver, men det er jo ikke kun for sjov – ikke kun fordi jeg bare må ud med det, der er i høj grad et kommercielt sigte, og derfor må der være en vis struktur. Heldigt for mig, at jeg er god til at sortere og strukturere, for hold da op, der sker noget oven i knolden på mig for tiden!

Den seneste ide jeg har fået, startede faktisk med en hyggelig aften hos en veninde jeg ikke havde set i alt for lang tid. Hun havde i mellemtiden fået nyt job, og i løbet af snakken om hendes job og mine planer, foreslog hun mig at tage et kig på et online kvindemagasin, som er tilknyttet det firma hun arbejder i. Som sagt, så gjort – dagen efter var jeg inde og kigge, og kunne med det samme se, at det er et super interessant og lækkert medie, men også at der mangler et redaktionelt område, som jeg vil kunne skabe og drive, og vigtigst af alt : som brugerne vil komme til at elske. Overordnet: sports & health – derunder en masse stofområder, der skal grupperes og sættes i system. Jeg prøvede lige hurtigt ideen af på en veninde, og hun synes bare at jeg skulle se at komme i gang. Så nu er planen at jeg går i gang med et oplæg, og får samlet mig et testpanel af kvinder jeg kan prøve mine ideer af på, inden jeg pitcher det til chefredaktøren.

Jeg er sikker på at der er plads i magasinet til det jeg kan bidrage med – og ikke mindst en interesseret målgruppe, jeg skal bare have det gennemarbejdet, og den her slags projekter har jeg aldrig arbejdet på før, så det bliver en spændende opgave.

Man kan vel sige at min key sentence i øjeblikket er : strukturer din kreativitet – jo du kan!

It-girl – creatingIt

Frikvarter

Så er der fri leg! – ja. Pauser er nødvendige, hvis vi skal tænke store tanker. Pauser er nødvendige, hvis vi skal være produktive eller kreative. Pauser er nødvendige, hvis vi skal yde vores bedste – uanset hvad vi laver.

Min pause er nu, og jeg vil bruge den til at fortælle om et helt fantastisk sted i mit liv : nu.

I næsten halvanden måned har jeg gået i skole, skrevet her på siden og på http://eeze.dk/category/sports-addict-life-love/ – jeg har trænet, gået ture, bagt boller, lavet en smule freelance tekst, elsket mit liv og fokuseret på mig. Jeg har taget en pause – en hårdt tiltrængt en – til at finde ud af hvilken vej jeg ville og hvorfor jeg ville, om jeg var på vej i den ønskede retning, og lykkeligvis er jeg blevet bekræftet i mit valg.

Jeg ved nu – uden en skygge af tvivl – at jeg skal skrive. Ja, det har jeg for så vidt vidst i et stykke tid, og jeg er stadig meget målrettet i min søgning efter jobs, der hedder noget med webkommunikation, men jeg er blevet mere end sikker på at det er vejen frem, og på at jeg kan gøre det – jeg kommer i mål. Jeg er allerede nået et stykke af vejen – det går rigtig godt i skolen, jeg er ikke på nørd-niveau, men mere og mere giver det mening hvad vi laver, og på mine skriverier får jeg rigtig meget feedback, af den konstruktive slags, af den positive slags, og af den vilde slags – du ved, der hvor feedbacken er : “du inspirerer mig helt vildt” – “jeg bliver så motiveret af at læse det du skriver” – “jeg er kommet i gang med…” – “tak for sparket, jeg er i gang igen”. DET motiverer mig – DET inspirerer mig – DET sætter to streger under at jeg er gået i den rigtige retning, og at det valg jeg tog for halvanden måned siden, var det rigtige.

Men alt det er ikke kommet af sig selv – og det var slet ikke kommet nu, hvis ikke jeg havde taget den pause.

Pauser er vigtige – husker du at tage dine?

It-girl – livingIt

Artefakter – i it-projekter? Ja da!

Ja, måske er det bare mig, men var artefakter ellers ikke noget man hørte om i arkæologiske sammenhænge – mest i hvert fald? Godt, det er det ikke! Artefakter forekommer nemlig i høj grad i det vi her beskæftiger os med; softwareudvikling. Vi skal se lidt nærmere på dem i dag, og hvordan de hænger sammen med vores krav. En enkelt artefakt vil jeg med det samme fremhæve, nemlig Use Case Model, som er en meget central, og praktisk taget uundværlig del af processen – vær opmærksom på den.

Alle de artefakter jeg fortæller om her, er en del af inceptions fasen – den forberedende fase, men fordi vi arbejder i iterationer, vil flere artefakter forekomme flere steder i processen og undervejs vil nogle af dem måske ændres eller udbygges.

Vi begynder med visionen, som jo beskriver de overordnede mål med projektet – hvad er det vi vil og hvorfor vil vi det? Den her del er det meget vigtigt at skrive ned! Selvom man har siddet sammen og talt om visionen, er det ikke en garanti for at alle parter har samme opfattelse af hvor de skal hen, hvad der skal lægges vægt på undervejs og hvorfor. Derfor er det vigtigt at kunne tage visionen frem i tvivlsspørgsmål, for de vil komme i de forskellige iterationer.

Det næste er vores Use Case, som er hvad vi kan kalde et brugs scenarie, og som har til formål at beskrive de funktionelle krav – hvilke handlinger skal man kunne udføre i systemet? Til at begynde med laver vi en liste over de fleste af vores Use Cases, men analyserer og beskriver kun ca. 10% af dem – hvorfor? Fordi resten kommer i de senere iterationer. Der er her vi begynder med de krav, der er størst risiko for vi ikke kan lykkes med. Vi analyserer og beskriver i detaljer de handlinger vi anser for de sværeste. En Use Case består af to elementer : en tekst og et UML (Unified Modeling Language) diagram, der viser det samme som teksten med ord forklarer. Giver det mening? Teksten fortæller en historie om hvad det er vi gerne vil kunne gøre i systemet, som hvis en butik skulle have et nyt kassesystem og vi skulle forklare at det skal kunne registrere salg, tage varer retur, opdatere lagerbeholdning, omregne til anden valuta, tage imod checks og betalingskort osv.  Og hvordan det rent praktisk foregår. Til at illustrere det, tegner vi et UML diagram, med kasser, pile og få forklarende/beskrivende ord, der viser hvordan processen ser ud.  Det er en stor fordel at bruge UML diagrammer, i særdeleshed hvis man bruger udenlandske programmører, der måske ikke er helt fortrolige med nuancerne i det sprog Use Case teksten er skrevet på. Dertil kommer, at teksten er skrevet i slutbrugerens sprog, og ikke med en masse tekniske forklaringer, som en programmør typisk selv ville bruge. Senere vil jeg komme meget mere ind på UML, og alle de fortræffeligheder, der er forbundet hermed.

En supplerende specifikation kan ofte være en fordel, til at definere de ikke-funktionelle krav, der kan være til et system. Der kan være lovgivningsmæssige hensyn, skattetekniske finurligheder, krav om at brugeren skal kunne vælge mellem flere sprog og en række andre ting, der skal tages højde for. Det bruger man denne supplerende specifikation til at få på plads.

En ordliste viser sig ofte at være en af de meget nyttige artefakter, der ikke kun bruges til oversættelse til andet sprog, men i højere grad som redskab til at forklare begreber, ord og terminologier.

Risko-liste og, i mangel af bedre ord, Risk Management Plan er to super vigtige elementer. Hvad kan gå galt, og hvad gør vi ved det, når/hvis det går galt? Hvad kan der opstå af tekniske forhindringer, tidsmæssige forhindringer, resourceproblemer osv. Og hvad er planen, hvis vi render ind i de problemer? Jeg behøver vel næppe forklare hvorfor det er så super vigtigt at bruge lidt tid her? Nej? Det tænkte jeg nok!

Prototype og proof of concept – dem kommer vi heller ikke udenom. De er i sagens natur ikke det aller første vi tager hul på, men de kommer meget tidligt i processen, og har det formål at sikre, at det nu også er umagen værd at gå videre med projektet, for hvis vi ikke kan præsentere noget der viser at det kan komme til at virke – den lille bid software vi udvikler efter den mest risikofyldte use case for eksempel, hvis den ikke virker efter hensigten, er det så umagen værd at gå videre? Eller har vi valgt den rigtige udviklingsteknologi? Skal vi ændre noget der? Eller er der krav, der skal ændres? Du kan godt se hvorfor det her skal foregå tidligt i processen, ikke? Og mange gange i processen faktisk – vi tester jo løbende, husk på det.

En iterations plan – ja, det er skam nødvendigt. Den beskriver jo hvad der skal ske i de første iterationer og hvor lang tid de hver især tager. En tidsplan er vigtig, og igen er det ikke tiden vi rykker noget ved, men indholdet i de enkelte iterationer, hvis vi ikke når det planlagte. En iteration bliver aldrig længere end den er planlagt til – aldrig.

En plan for elaborationsfasen som helhed – jo, den behøver vi også. Det er her vi giver et bud på hvor lang tid den fase må vare. Og her vi beskriver hvad vi skal bruge af værktøjer, uddannelse, folk og andre resourcer.

Development Case – udviklings scenariet. Hvordan har vi tilrettet vores UP efter projektet? Hvilke skridt tager vi hvornår, hvilke artefakter arbejder vi med og hvordan? Det er altid UP’en der customizes, eller tilrettes til projektet – altid. Spørgsmålet er ikke om vi gør det, men hvordan vi gør det, og det er det vi definerer og beskriver her.

Var det ligeså spændende for dig, som for mig? Eller var det bare en masse sludder og vrøvl? Lad mig høre hvad du synes – og lad mig høre hvis du har spørgsmål! Eller hvis der er et emne du gerne vil have mig til at tage op – jeg tager imod ideer med stor glæde.

It-girl – enjoyingIt

Requirements = krav – så langt, så godt!

Den amerikanske journalist Don Marquis sagde engang at; Ours is a world where people don’t know what they want, and are willing to go through hell to get it. Korrekt – på flere niveauer, men lad os se det i relation til det vi gav os i kast med sidst – it-udviklingsprojekter. For er der et sted hvor det kan siges at være en sandhed, så er det her! Men hvad så med UP? Spørger den opmærksomme læser. Ja, UP – det er derfor vi er så glade for UP, når vi holder fokus, og holder os til den måde at arbejde på. Det gør alle så ikke, og fred være med dem – bogstaveligt talt, for hvis de vælger at arbejde efter vandfalds-modellen, kan det godt ende med at blive en smertefuld proces.

Af uransagelige årsager, forekommer vandfalds-projekter stadig i utrolig mange virksomheder, og man kan med rette undre sig over det, når der findes så åbenlyse og hensigtsmæssige alternativer. Og det gør jeg så – undrer mig.

Men lad mig lægge ud med kort at skitsere et vandfalds-projekt. I sådan et projekt tager man  en fase ad gangen, og først når hver fase er afsluttet, begynder man på næste. Således defineres alle krav først, i det vi kalder en kravspecifikation, så designer vi, programmerer, implementerer, tester, integrerer og afleverer. En fase ad gangen. Det betyder, at fordi alle krav skal med fra starten, så kommer der meget ofte for mange og forkerte krav med, og risikoen for at ende ud med et stykke software, der ikke er spot on i forhold til det kunden i virkeligheden har brug for, er ret stor. Der tages ikke undervejs højde for, om det var de rigtige krav man havde listet, og derfor arbejder man videre i blinde, og giver ikke sig selv og kunden muligheden for at rette ind og omdefinere opgaven, så den ender med at passe til præcis det, der er behov for. En anden fare er, at der udvikles software, der aldrig, eller sjældent bliver brugt – og det sker meget ofte i den slags projekter – spild af tid og penge. Flere undersøgelser viser, at op imod 45% af det der udvikles efter vandfaldsmodellen, aldrig bliver brugt, 19% bruges sjældent, 16% nogle gange, 13% ofte og kun 7% bruges altid. En ret stor fejlprocent hvis du spørger mig – og sikkert også hvis du spørger dem der sidder på pengekassen. Så… no more waterfalls – right?!

Altså, krav er ikke bare krav. Og en hvilken som helst metode til at definere sine krav, dur ikke. Ikke hvis man har lidt fokus på effektivitet, omkostningsstyring og på at få det rigtige produkt. Til at hjælpe os med den del af processen har vi FURPS+ modellen, som er et vigtigt værktøj, for enhver, der arbejder med UP. Det er måden vi kategoriserer vores krav på. F – Functional – hvad vil kunden have, herunder også sikkerhedsrelaterede krav. U – Usability – krav til effektivitet og anvendelse i forhold til brugeren, præcis og fyldestgørende dokumentation. R – Reliability – krav til acceptable nedetider, hvor stor er nøjagtigheden i resultaterne og kan vi demonstrere det, herunder fejl og forudsigelighed heraf. P – Performance – krav til responstider, throughput, hukommelse, tilgængelighed og hvor mange resourcer systemet må bruge for at køre optimalt. S – Supportability – krav til overvågning, vedligeholdelse, test, installation, internationalisering, konfigurering og tilpasning. Under +’erne kommer krav der handler om interface, hardware, indpakning, lovgivning, implementering. FURPS+ er en meget anvendelig checkliste, der kan hjælpe os med at sikre, at vi tager stilling til alle de vigtige spørgsmål undervejs – vi gør det jo i hver iteration, og hver gang er det vigtigt at stille de rigtige spørgsmål i forhold til hvor i processen vi er. Her kan en checkliste som FURPS+ hjælpe os.

Giver det mening? Lidt? Næste gang fortsætter vi lidt med de der krav – og udbygger med UP Artifacts, Use Cases og vigtigheden af at skrive den fælles vision ned. Glæd dig, det bliver vildt spændende!

It-girl – embracing

Unified Process, Iterative Development, Risk-driven – huh??

Jo, den er god nok – det hedder det, og ja – det lyder meget svært. Og det er det også – eller er det?

Lad os tage det fra en ende af, og se om ikke det bliver lidt mindre svært efterhånden.

Unified Process (UP), som er måden at drive og gennemføre et udviklingsprojekt på, er en iterativ proces. Iterativ betyder ‘gentaget’, og UP er altså en måde at drive et projekt gennem gentagelser. Overordnet er UP opdelt i 4 faser: Inception (forberedelse), Elaboration (Etablering), Construction (Konstruktion) og Transition (overdragelse). Og undervejs er hver fase inddelt i iterationer.   Hver iteration er ganske kort – vi taler få uger – det er meget vigtigt, og det gør noget godt for overskueligheden, og for kundetilfredsheden, for den kunde vi udvikler softwaren til, får løbende noget at evaluere på, og en større sandsynlighed for i sidste ende at stå med et stykke software, der lever op til det de har brug for – hverken mere eller mindre. Altså, vi starter med nogle krav, laver noget design, noget funktionalitet, vi analyserer, vi tester, vi implementerer og vi integrerer – vi finder formentlig nogle fejl. Så fortsætter vi med næste iteration, med flere krav, mere design, mere funktionalitet, mere analyse og fejlretning, test, implementering og integration – og nye ting der skal korrigeres. Og så videre til næste iteration med… I de sidste iterationer vil der typisk være mere fokus på de sidste faser, men ellers er princippet det samme. Korrektionerne vil blive mindre omfattende, og til sidst er vi i mål. Hver iteration ender ud med et lille stykke software, som kunden kan prøve, og bruge til at vurdere hvad der skal med i næste iteration – hvad skal rettes? Hvilke nye krav skal med? Lidt større stykke software for hver iteration. Kan du se ideen?

Når først vi har fået forklaret, at Iterative Development (ID) på er det samme som iterativ udvikling, og handler om gentagelser, så virker det måske lidt mere tilgængeligt – ja? Så går vi videre med det. Det kunne hurtigt komme til at lyde som en gentagelse, så jeg vil ikke rode mig ud i længere forklaringer, men med det samme slå fast, at hvor UP repræsenterer strukturen i udviklingsprocessen, så er ID selve det praktiske arbejde: krav, design, analyse, programmering,  test, integration og implementering. Og til sidst, overdragelsen. Det er vigtigt at tidsfristerne på hver iteration overholdes. Hvis der er sat 3 uger af, så vær færdig efter 3 uger, og tag det I ikke nåede med i næste iteration. Det er vigtigt med en stram styring af tiden, for at bevare overskueligheden og sikre at det ikke kommer til at flyde, og i sidste ende blive alt for dyrt.

Netop det at styre omkostningerne, og sikre at det overhovedet kan betale sig at udvikle det her stykke software, er UP rigtig godt til.  UP – og for den sags skyld mange nyere metoder – lægger op til en kombination af Risk-driven (risiko-drevet) og Client-driven (kunde-drevet) planlægning, der indebærer at man først identificerer mulige showstoppere, dvs. de elementer, der har størst risiko for ikke at kunne lade sig gøre – eller vil blive for dyre at udvikle – og gå i gang med dem. Hvis der er succes, vil der være fornuft i at fortsætte projektet – hvis ikke… nej. På den måde kan man nå at stoppe et projekt på et tidligt stadie og undgå en lang dyr proces, der i sidste ende måske alligevel ender med at være spildt, eller i hvert fald en utilfredsstillende og mangelfuld løsning.

Er det spændende – ja? Svært – ja? Eller måske? De overordnede principper og begreber er da til at forstå, når man først har fået dem forklaret. At bruge dem i praksis, er naturligvis en anden historie – og min udlægning af det, er under alle omstændigheder en meget simplificeret version. Men jeg tror på simplicitet som en effektiv indgang til et stort og komplekst område – for det er det virkelig, det er ikke for sjov. Og hvis du har det som jeg, så nøjes du heller ikke med at læse med her, så går du selv ud og finder mere litteratur om det, og så får du fyldt en masse mere på. Jeg har, som du nok ved, valgt at gå i skole og lære det her – det er ikke sikkert du vil det, måske har du andre behov og interesser – måske læser du med her, ikke for at lære om UML, UP, ID og hvad ved jeg, men for at følge min rejse rundt i den eventyrlige verden vi kalder it. Til det her, mit første fag, læser vi en bog, der er stor og tung, og som i første omgang virkede lidt utilnærmelig – eller i hvert fald ikke for hvem som helst. Og tag ikke fejl – den er heller ikke for hvem som helst, man skal have den specielle tankegang, der gør én i stand til at tilegne sig netop den type stof, tage det ind og forstå det. Men efter sidste lektion, har den – og hele det store komplekse område – åbnet sig en smule mere, for vi har en meget dygtig lærer, som forstår at vise og forklare og stille de gode spørgsmål – og han forstår at forenkle og gøre tilgængeligt. Noget af det håber jeg at have givet videre til dig. Ikke mindst lysten til at følge med igen, her på siden.

It-girl – ready to embrace

DET er kærlighed!

Sååådaan – SÅ kom vi i gang! I onsdags blev der taget hul på det vi er der for. (Hvis du er ny her på siden, så er det skolen jeg taler om). Vi kom lige så stille i gang med at bruge Visual Studio, et Microsoft IDE (Integrated Development Environment), hvor vi lavede en knap, gav den et navn, og en tekstboks, og en tekstboks mere, kiggede på koderne og hvordan man får det rigtige svar i boks 2, på spørgsmålet i boks 1, ved at klikke på knappen. Helt basic, men en start – og en virkelig skøn start. Der er meget lidt, der kan måle sig med den følelse man får, når noget man først ikke forstod  pokkers meget af, pludselig virker tilgængeligt, og så småt begynder at give mening. Når float, double og loop pludselig ikke er helt uigennemskuelige begreber længere, men de første genkendelige og forståelige ord i et nyt sprog.

Meget af timen – timerne – gik for mit vedkommende med at få installeret Visual Studio på min nye computer, og det var ikke nemt, skulle jeg hilse og sige! Vi forsøgte alt muligt. Afinstallerede programmer, der kunne forstyrre installationen, deaktiverede min firewall og antivirus, og forsøgte igen og igen…. Jeg kæmpede, fik hjælp fra klassekammerater og vores lærer og ingenting hjalp. Men jeg er blandt ligesindede, så da det IGEN gik galt og det hele stoppede midt i processen, og et lille “NEJ, ikke igen!” undslap mig, og jeg genert undskyldte mit udbrud, var det i følge vores lærer “helt okay  at lægge følelser i det” – thank you! For hvor er det befriende at være i et miljø, hvor ens følelser er genkendt og accepteret – hvor man er for at lære og udvikle sig, og hvor vi deler den samme passion. De specifikke mål er måske ikke de samme, og heller ikke forudsætningerne, men det overordnede – at lære (mere) om softwarekonstruktion, er det samme.

DET er kærlighed!

Og i sidste ende fik jeg det installeret – efter at have genstartet Windows….

It-girl – LovingIt

Let the games begin!

Nu er det alvor, nu er vi i gang. I den her uge begyndte undervisningen – og lektierne. Ja, undervisning er måske så meget sagt, det var selvfølgelig mere en introduktion af faget, bøgerne, semesterplanen, klassen og underviseren. Men det var starten på det jeg har glædet mig så meget til, at jeg kunne smage det når jeg vågnede om morgenen – og jeg er ikke blevet skuffet. Det er spændende, det er svært og det her efterår bliver helt sikkert en af de største faglige udfordringer for mig, i flere år.

Så den her weekend er lektie-weekend – som så mange andre af efterårets og vinterens weekender vil blive det. Jeg sidder og læser om C# og forstår indtil videre kun en lille smule af det her sprog, som er ganske nyt for mig, men det gør ikke noget – jeg skal nok få lært hvad pseudokoder, compound assignment operators, implicit type conversions og explicit casting er og hvad de gør. Og når jeg har forstået det, skal jeg nok huske at fortælle dig om det.

UML bogen, som jeg havde læst en smule i inden første time, skal vi først bruge i lektion 3 og jeg er så spændt på det. Vores underviser introducerede bogen som den mest komplekse af de 2 vi skal læse, men forsikrede os om, at i kombination med undervisningen, skulle vi nok få fat i det. Hvilket på mit sprog betyder, at jeg virkelig skal holde fokus og være aktiv i timerne, for den der bog, den er ikke ‘for sjov’, og hvis jeg ikke er med fra starten, så kommer jeg nok ikke i mål. Så nu er det næsen i bøgerne, fokus og fuld koncentration og en masse sjove og spændende timer med undervisning, opgaver, læsning og med at lære mine nye klassekammerater at kende. DET bliver mit efterår!

Vi er en meget blandet klasse – 15-18 personer med vidt forskellig baggrund. Nogle arbejder med at designe hjemmesider, nogle kommer ‘bare’ med en stor interesse for it, og så er der lidt af hvert der imellem – fælles for os er at vi er der fordi vi vil være der, vi har hver især taget et positivt tilvalg og en beslutning om at blive dygtige it’ere – eller dygtigere.

I fredags havde jeg en super aften med en rigtig god ven, der ud over at være netop det, også er en stor inspirationskilde for mig. Han har altid nogle nye vinkler, hvis jeg går og tumler med noget, og han er god til at stille de spørgsmål, der får mig til at tænke på en anden måde og komme videre med ideerne. Han foreslog blandt andet, at når det nu er webkommunikation jeg så gerne vil arbejde med, så skulle jeg da finde nogle firmaer, der var interesseret i at få kigget på deres hjemmeside, og få et forslag til hvordan den kan optimeres. På den måde kommer jeg i gang, på free lance basis og kan gøre det ved siden af skole og job, og får undervejs lært en masse jeg kan bruge den dag ‘jobbet’ er der. Da min styrke jo ligger på tekstsiden, vil det fornuftige uden tvivl være at gøre det i samarbejde med en der er grafisk stærk, så vi i samarbejde kan få lavet nogle rigtig lækre hjemmesider – kender du sådan én?

It-girl – unfolding

Wok og UML

To små ‘ord’, der hver især dækker over noget basalt og essentielt. Wok – mad jeg kan lide, og som stiller min sult på et basalt, fysisk plan. Fylder hullet i min mave.

UML står for noget, der stiller en anden sult. UML er short for Unified Modeling Language, og det er en vigtig del af mit pensum på første fag: Softwarekonstruktion. Første fag på den uddannelse, der kommer til at fylde et andet tomrum i mig – et mere luftigt et af slagsen. Det stiller min sult efter lærdom, efter viden, og fylder hullet i mig, der kommer når jeg længes efter at lære. For når jeg lærer er jeg hel.

Ja ja, nu kan man jo lære mange ting og på mange måder, tænker du nok – og hvorfor skal der en uddannelse til for at stille mig tilfreds? Kunne jeg ikke bare lære noget mere om det jeg arbejder med i forvejen? Eller lære at blive bedre til at tale fransk? Eller lære at svømme andet end almindelig brystsvømning (med hovedet HELT over vandet)? Nej – for jeg er god til mit job, og kunne jeg blive bedre? Ja, det kunne jeg vel nok. Jeg kan lidt fransk, og kunne det være fedt at tale det flydende? Ja, det kunne det da. Og ville det ikke også være en god ide at blive rigtig god til at svømme? Absolut! Men hvad så – hvorfor er det ikke ‘nok’?

Det tænder mig ikke (nok) – it’s that simple! Men det gør it – web – kommunikation – det gør dét. Så når jeg åbner min første skolebog, og ser at det her bliver svært – meget svært, fordi forfatteren skriver at visse forudsætninger kræves – forudsætninger jeg ikke har – så gibber det lidt i mig, og jeg når lige at tænke ’shit’! Og så mærker jeg igen forventningen, og glæden og suget i maven – og hvordan det føles virkelig at trække vejret.

Når jeg er lidt ‘in over my head’ og ved at det her skal jeg godt nok kæmpe for, så får jeg det der rush, som jeg også får af en løbetur, en spinningtime og andet sport. Det hedder adrenalin. Og det er en del af det der driver mig, det indrømmer jeg – men det er også en livsbetingelse for mig. Ikke adrenalin, men at lære, fordybe mig, tilegne mig ny viden og forstå – og følelsen når det hele hænger sammen og giver mening. Need I say more?

Ikke? Så vil jeg gå ud og lave min wok – jeg har en meget fysisk sult, og den må jeg jo også tage mig af.

It-girl – ready to unfold

So close…

I den her uge kom velkomstbrevet fra skolen – det brev jeg har ventet på med længsel. Nu har jeg fået det, og der var bogliste, informationsfolder og mit eget login til Fronter, hvor jeg kan holde styr på kalenderen, se beskeder vedr. undervisningen og sikkert en masse andre spændende ting, efterhånden som semestret skrider frem.  I brevet var der desværre også en besked om at første undervisningsdag er rykket fra d. 2. september til d. 9.

Ja, det er jo næsten ikke til at holde ud, når man er en utålmodig sjæl, og bare gerne vil i gang med det samme. Men jeg har bestilt bøgerne, og den ene burde komme i løbet af nogle få dage – så det er ikke tiden til fortvivlelse, men til at glæde sig – og det gør jeg så!  Så selvom jeg troede at første skoledag var tættere på, holder jeg humøret oppe og næsen i skærmen, og tæller ned til 9. september kl. 17:15.

Siden sidst har jeg kastet mig over OpenSocial – et sted, der samler alle vores sociale netværk – tror jeg da, for jeg har kun lige signet up, og har 1 kontakt og ikke fået leget så meget med det endnu, men hvis det er så smart som jeg tror det er, vil det gøre hele vores adfærd, færden, gøren og laden i vores sociale online-netværk meget mere fleksibel og overskuelig, så jeg leger videre. Er der nogen der har erfaringer med det allerede, og kan fortælle mig om det er godt eller skidt – eller bare endnu et netværk?

It-girl