Anbefalinger og overslag

0. Indholdsfortegnelse

Nr.		Beskrivelse
1		Markdown som det mest oplagte format at sikre Notes-dokumenter i
2		Forskellige måder at lagre og vise markdown-dokumenterne på
3		Statiske side generatorer (SSG) er velegnede til at servere arkiv-databaser
4		Udbudet af statiske-side-generatorer (SSG)
5		Open source og feltet af SSG´er
6		Begrundelse for valget af Hugo og Icarus-temaet
7		Konverteringen
	A	Hardware/software
	B	Programmering/manuel gennemgang
	C	Økonomi
8		Den efterfølgende drift af et system af statiske websteder
	A	Hardware/software
	B	Programmering/mandskab
	C	Økonomi

---

1. Markdown

Markdown - med filendelsen .md - har de senere år gået sin sejrsgang verden over som det grundformat, man gemmer dokumenter i. Der er endda kommet et plugin, som gør det muligt at åbne og gemme markdown-dokumenter fra Word.

Et markdown-dokument består udelukkende af de tegn, som findes på ethvert computer-tastatur. Desuden er det umiddelbart læseligt i Notepad!

Selv om grundprincippet således er enkelt ud over alle grænser, så formår formatet at vise tekster med alt det pynt og design, som vi alle forventer af et Word-dokument eller en webside. Formateringen skabes af en række koder, der flettes ind i den rå tekst. Herefter kan den formaterede tekst vises direkte, når man åbner teksten. Eller markdown-dokumentet kan konverteres til HTML, hvorefter den vises som en webside.

De små koder, der gør hele forskellen, er beskrevet nærmere i dette markdown cheat sheet, og de kan afprøves direkte i en af de utallige markdown editorer på nettet. F.eks. kan denne tekstet copy-pastes direkte ind i en online markdown konverter, hvorefter formateringen med overskrifter, lister, tabeller, check-bokse, links etc. vises. Der er også mulighed for at få vist billeder og få adgang til vedhæftede filer fra et markdown-dokument.

Samtidig indebærer markdown-formatet mulighed for at gemme meta-data på en struktureret måde i toppen af hvert enkelt dokument. Disse data er ikke til visning for brugeren direkte - men til brug for optælling og generering af navigation. Metoden minder til forveksling om de informationer, som placeres i toppen (head) på alle web-dokumenter, og om de skjulte felter, der typisk er lagt foroven i Notes-dokumenter.

I markdown kaldes denne «dokument-top» for front matter, og her gemmes dataene i formatet YAML. YAML minder meget om JSON, og data i de to formater kan uden videre konverteres til hinanden. Fælles for dem er, at de giver mulighed for at gemme relationelle data (reelt tabeller) i dokumenter.

Her kommer et udtræk af et test-dokument som illustration af, hvordan et Notes-dokument bliver forvandlet til et markdown-dokument med YAML i front matter. Denne tekst kan også klistres ind i Dillingers online markdown-converter.

---
title: Vejledning om udetillæg
description: Her står en beskrivelse
notesURL: 4D856C31E089EBB7C1257DE10041CE52.html
lang: da
site: test
decision:
- Afvist
author:
- Peter Jensen
categories:
- Lov om udetillæg
- §16
tags:
- Peter Jensen
- Afvist
- Lov om udetillæg §16
excerpt: Her står et resumé til brug for oversigter
date: 2014-07-10 00:00:00
updated: 2014-07-10 00:00:00

---

# Overskrift

### Mellemrubrik

Tekst

### Ny mellemrubrik

Mere tekst

Dataene i Lotus Notes er lagret som dokumenter (med meta-data i toppen), og det er derfor både naturligt og nærliggende at bevare dokument-strukturen ved en data-eksport. Der bliver tale om en slags 1-1 konvertering, som gør mange ting både lettere og billigere.

Eneste reelle alternativ er at flytte indholdet af Notes-dokumenterne over i en relationel database (SQL), hvor alle informationer i princippet fordeles i tabel-celler. Dette giver mindst tre helt overordnede udfordringer: - Notes-felter med flere værdier (f.eks. fra en check-boks) må flyttes helt ud i undertabeller, fordi en tabelcelle i en relationel database kun kan rumme én værdi. - Store dokumenter/dokumenter med stort indhold af formatering, billeder og filer risikerer at overskride den plads, der er sat af til de forskellige elementer i SQL-databasen. Dette løses ofte ved at placere den formaterede tekst uden for SQL-databasens tabelstruktur, hvorved vi i princippet alligevel ender med at have et dokument, som skal håndteres. - Visse Notes-databaser rummer Notes-links (såkaldte doc-links), som går til andre dokumenter i samme database eller andre Notes-databaser. Disse links består af en særlig dokument-ID, som er særdeles svær at trække ud og bevare funktionaliteten af i andre systemer. Ved at «genbruge» dokument id´et i filnavnet på de konverterede markdown-dokumenter får vi mulighed for at forhindre i hvert fald en del af doc-linksene i at «dø».

2. Database-typer og markdown

Som det fremgår af punkt 1, er markdown-formatet svært at komme uden om, når der skal trækkes data ud fra et dokument-system som Lotus Notes. Så det vil jeg under alle omstændigheder anbefale, at man gør.

Men markdown-dokumenterne behøver i princippet ikke blive liggende som dokumenter i et fil-system på en harddisk. Den formaterede tekst, som vi ofter kalder Rich Text i Notes, bliver rent faktisk til ren tekst (plain text), når den er konverteret til markdown. Dermed bliver den også mere «spiselig» for en SQL-database. Hermed åbnes der mulighed for, at formateringen fra et tekst-felt i en Notes-database kan bevares ved at putte markdown ind i et tekst-felt i SQL. Der skal være god plads, men selve formateringen holdes inden i tabellen så at sige. Det er kun billeder og andre filer, som herefter er nødt til at ligge uden for tabel-strukturen. Samtidig kan meta-data fra andre Notes-felter gemmes i andre kolonner på dokumentets række i SQL-tabellen.

Markdown i SQL er altså praktisk muligt. Men hvor let denne kombinations-løsning lader sig integrere med eksisterende web-kode - f.eks. i Microsoft ASP.NET, kan ikke besvares uden et nærmere studie af den aktuelle opsætning.

Uanset dette anbefales det at gøre markdown med tilhørende filer i filsystemet til den grundliggende opbevaring af dataene fra Notes-dokumenterne. I denne form skal dataene nemlig aldrig mere «trækkes ud» fra noget. De er trukket ud en gang for alle i et format, som ikke ejes af nogen. Det betyder farvel til vedligeholdelse, opgradering og licenser. Desuden kan ingen (leverandør eller producent) længere stille sig mellem data og bruger/dataejer.

Foruden den nævnte import i SQL kan markdown-filerne konverteres til brug i andre sammenhænge:

1. Generering af pdf-filer. Der findes masser af markdown-to-pdf konvertere. Også som open source. Man kan få en lille fornemmelse af den korte afstand fra markdown til pdf ved at klistre dette dokument eller noget andet markdown ind i online konverteren fra før, hvor et markdown dokument konverteres til pdf (eller html) med et par museklik. Og skulle bogstaverne være for store eller lign., ændres dette med en css. Stylesheets er i stand til at lave fin-formatering af både pdf´er og html-sider, som genereres på basis af markdown.
2. Generering af web-steder som vi kender det i dag i HTML5 med responsivt design. Dette kan gøres ved hjælp af statiske side generatorer (engelsk: Static Site Generators), som der findes hundredvis af open source versioner af rundt om i verden
3. Genering af web-steder, som de bliver i fremtiden. Baseret på HTML 6, HTML 7, CSS 4, CSS 5 etc.
4. Visning af dokumenter på måder, som vi slet ikke har fantasi til at forestille os i dag.

Markdown giver med andre ord mulighed for write-once, publish anywhere.

I det følgende skal der dog fokuseres på punkt 2 (generering af web-steder), som er nødvendigt i et eller andet omfang, hvis Notes skal kunne lukkes ned, uden at vigtige data går tabt for brugerne.

3. Egenskaber ved SSG´er

I det aktuelle tilfælde er der tale om at gøre data tilgængelige som arkiv. Det vil sige, at dokumenterne skal være tro mod originalerne. Ændringer og rettelser vil være sjældne. Denne anvendelse gør statiske-side-generatorer til et oplagt valg: 1. Et website, som gemmer data i en database, skal generere hver enkelt dokument «forfra», hver gang en bruger klikker sig hen til det. Denne fremgangsmåde koster både tid og serverkraft, og den egner sig derfor først og fremmest til visning af indhold, der redigeres og udvides ofte. Statiske side skal kun bruge denne tid og kraft én gang for hvert dokument - nemlig ved genereringen. 2. Statiske side generatorer (SSG) er derfor særdeles hurtige vil at vise deres indhold. Det er jo lavet på forhånd - så at sige. 3. SSG´er er utroligt stabile til at afvikle websider. Det skyldes især, at de jo ret beset ikke bestiller andet end at flytte bits og bytes i den daglige drift. 4. De er umuligt at hacke, fordi der ikke er nogen bagvedliggende database at sende ondsindede koder ind i.

Efter at en database er lagt i drift med en statisk side generator, kan dens sider dog fortsat redigeres, hvis der skulle opstå behov for det. Det sker lettest og enklet ved at lave de ønskede rettelser i de bagvedliggende markdown-dokumenter og køre en ny generering af det websted, som dokumenterne indgår i. Denne generering tager fra få minutter til måske en times tid - afhængig af webstedets størrelse og den tilgængelige serverkraft.

Men det er ikke nødvendigt at have direkte adgang til filerne på serveren for at lave rettelser. Lige præcis Hexo har - som en af meget få - faktisk et admin-plugin som giver adgang til at rette i sine markdown-dokumenter fra web.

4. Udbudet af SSG´er

Hvis valget falder på at sætte strøm til de gamle Notes-databaser med statiske side generatorer, er vi så langt fra «fastlåsning til leverandør», som vi næsten kan komme.

1. Der findes hundredvis af SSG´er, og der kommer hele tiden nye til.
2. SSG´erne bliver udviklet på alle tænkelige platforme. Fra PHP og java over .NET til Go og Python. Men javascript dominerer billedet med sine Node.js og ruby-baserede løsninger.
3. Statiske side generatorer er så udpræget et open source fænomen, at det er svært at komme i tanker om SSG´er, som man betaler for. Det foregår så vidt vides kun, hvis generatoren udbydes som en cloud-service.
4. Skulle man af en eller anden grund fortryde et valg af SSG, så står det enhver frit for at skifte til en anden. Eller at bruge flere forskellige samtidig.
5. Et skifte i fremtiden kræver naturligvis installation og opsætning af den nye generator. Men dokumenterne skal ikke konverteres. Den nye generator importerer blot filerne på en ny måde og med et nyt resultat.

5. Open source og og feltet af SSG´er

I forrige version af dette dokument indeholdt dette kapitel en gennemgang af fordelene ved at bruge javascript og Node.js frem for proprietære formater og systemer, som indebærer en risiko for at blive fastlåst til producenter og leverandører.

Argumentationen var lagt ind af hensyn til den statiske side generator Hexo, som kræver installation af Node.js for at fungere.

Dette er dog ikke længere aktuelt, idet alternativet Hugo, som anbefales i næste kapitel, ikke kræver Node.js for at fungere.

Hugo er dog 100 pct. open source lige som Hexo. Dette kan der også fremhæves en lang række fordele ved, som rækker langt ud over, at anskaffelsesprisen er kr. 0. Det dog vil føre for vidt at gå længere ind i dette her. Dog kan det nævnes, at myndighederne i flere og flere lande har kraftige overvejelser om at gå den vej. Det gælder f.eks. i Rusland og i Bulgarien.

Som nævnt i kapitel 4 findes der flere hundrede statiske-side-generatorer. Den nok mest udbredte spiller på banen, Jekyll, bør efter min opfattelse undgåes. Dels fordi den er langsom til at generere dokumenter. Dels fordi den bygger på Ruby on rails, som er et underliggende javascript-framework, der kræver opsyn og vedligeholdelse.

Desuden er Ruby on rails tilsyneladende på vej ud i mørket - formentlig godt hjulpet på vej af Node.js. Det sidste viser sig bl.a. ved et faldende antal søgninger på Google og næsten nul-vækst i downloads af program-pakker fra RubyGems.org. Til sammenligning viser de samme grafer, at Google-søgningen på Node.js er kraftigt stigende, lige som downloadet af Node.js-pakker via NPM det seneste år er steget rundt regnet lige så meget som alle de øvrige frameworks (java, .net, php, ruby etc.) - tilsammen!

Herefter står Hugo og Hexo som de mest oplagte bud.

De er begge:

• Meget udbredte

De to systemer benyttes af tusindvis af websteder verden over.

• Populære

Hugo og Hexo har i skrivende stund omkring 15.000 stjerner (=fans) på GitHub, som er verdens ubetinget største smeltedigel for open source projekter. Dermed indtager de to biblioteker henholdsvis anden- og tredjepladsen for biblioteker inden for statiske-side-generatorer, og de har samtidig i længere tid været de to biblioteker, som har haft den største fremgang i popularitet på deres felt.

• Bakkes op af mange udviklere

De to frameworks har et solidt korps af folk til at sikre den fortsatte udvikling. Ifølge GitHub har over forskellige personer bidraget til den aktuelle version. Det er næsten 5 gange så mange som Hexo, der i forvejen har rigtig mange bidragydere.

• Hjælpen er lige ved hånden

Både Hugo og Hexo vedligeholdes og videreudvikles af modne og særdeles levende communities. Jeg har aldrig oplevet at skulle afvente svar på spørgsmål i mere end 24 timer nogen af stederne. Selv velvoksne support-aftaler med mange nuller i får svært ved at være med her.

• Fungerer på flere operativsystemer

Begge platforme kan køre fra både Windows, Linux og MacOS. Dette er tilfældet for Hexo, fordi det underliggende Node.js kan afvikles fra de pågældende platforme. Hugo kræver ikke Node.js (mere herom i næste kapitel). I stedet kan den downloades i versioner til både Windows, Linux og OS X.

• Lego-klodser - på samme måde som WordPress

Hugo og Hexo ligger helt i top, når det gælder udbudet af tilpasninger og udvidelser, som ofte er lige til at «klikke på». Der er således d.d. officielt 105 temaer og 197 plugins at vælge imellem til Hexo. Oversigten med Hugo-temaer tæller p.t. godt 150. Men der findes mange flere temaer og plugins, som ikke er nået ind på listen. Jeg har selv brugt og testet flere af dem.

• Responsivt design

Det er nærmest en selvfølge, at temaer til statiske-side-generatorer ser godt ud på både store skærme, tablets og mobiltelefoner. Jeg er i hvert fald aldrig stødt på et tema, som ikke er «født» responsive.

6. Hugo og Rapid eller Icarus

Pilen kommer dog i den sidste ende til at pege på Hugo. Især af følgende grund:

• Kan generere meget store websteder

Den indledende test af Hexo gik glimrende. Lige indtil databaserne nåede op over 1200 dokumenter. Her gik Hexo i sort, og ingen i communityet kunne komme op med en brugbar løsning på problemet. Hugo, derimod, var i stand til at generere 2995 test-dokumenter fra i første hug - og uden at kny. En efterfølgende test-kørsel af Hugo med 11.980 dokumenter gav samme positive resultat. Det må siges at være udslagsgivende, idet nogle Notes-databaser kan indeholde et fem-cifret antal dokumenter.

Desuden taler følgende til gunst for Hugo i forhold til Hexo:

• Ikke blot hurtig - men rasende hurtig

Ifølge mine tests tager det Hexo over en time at generere ca. 1000 dokumenter. Til sammenligning behøver Hugo kun under 5 minutter. Men det er vel at mærke til 11.980 dokumenter. 2995 klares på godt halvandet minut.

• Helt uafhængig

Hugo har ingen afhængigheder - eller dependencies, som det hedder. Den kræver ikke installation af Node.js eller nogetsomhelst andet software - med hvad deraf følger af risici for fejl og problemer ved opdateringer. Hugo kræver således ikke en gang, at Node.js findes på den pågældende server.

• Behersker taksoonomier

Flere statiske-side-generatorer er i stand til ud-af-boksen at omsætte nøgleord og emneord i markdown-dokumenterne til auto-genererede oversigter og tilhørende navigation. Hugo er den eneste statiske side generator, jeg kender til, som er i stand til at tage det næste skridt. Den håndterer også de såkaldte taksonomier, som er yderligere nøgleord, der kan sættes op individuelt for hver database. Eksempler kan være årstal, år og måned, berørt afdeling, forfatter, type af dokument, type af indhold etc.

Vi kender noget lignende fra netop Notes, som typisk indeholder en række oversigter/views lavet på basis af lignende taksonomier. Hugo giver med andre ord mulighed for at trække alle disse oversigter, der jo reelt er forskellige søgeindgange, med over på web. Dette gælder, uanset hvor mange og uanset hvilke nøgleord, den pågældende Notes-database er bygget op omkring.

Blandt de over 150 temaer til Hugo anbefales Icarus eller Rapid, som i øvrigt også begge findes til Hexo, til en wiki.

Icarus:

• Beskrivelse

• Demo af Hugo-Icarus.

Rapid (som i øvrigt bygger på WordPress temaet Hueman):

• Beskrivelse

• Demo - Er ikke helt færdigudviklet i den form, som det findes i på nettet.

De to temaer anbefales først og fremmest på grund af deres tre-kolonne design.

Rigtig mange Notes-databaser kan i virkeligheden kaldes wikier, som er websteder med dokumentation, vejledninger, beskrivelser, statistikker etc. Fælles for dem er, at hver enkelt database typisk indeholder en lang række nøgleord og emneord, som bruges i oversigter til at give overblik over materialet. Hvis disse oversigter skal gøres let tilgængelige på web, er det oplagt at gøre dem til en del af navigationen. Enten som links fra navigationen til de fulde oversigter. Eller som kategorier, der linker videre til udsnit af oversigter (f.eks. alle dokumenter skrevet af en bestemt person.

Disse links (i hvert fald de mest relevante af dem) skal helst være ved lige ved hånden hele tiden. Det kalder på god plads til navigationen.

Nogle temaer samler al navigation i en top-menu. Andre har et to-kolonne design, hvor den ene kolonne viser det aktuelle dokument, mens den anden rummer navigation. Kolonnen med navigation pakkes typisk ned i bunden ved visning på mobiler. Endelig kan man få et tre-kolonne design, hvor indholdsdelen er omkranset af navigationsspalter. Dette anbefales her, idet vi jo skal have plads til en masse navigation.

Tilfældigvis er Icarus det eneste tre-kolonne design, som jeg endnu er stødt på til Hugo. Selv på mobil er der adgang til den tredje kolonne med Icarus, i og med at den kan kaldes frem ved klik på en trekant. Icarus tilbyder med andre ord en masse funktioner, som passer vældig godt til en wiki.

7. Konvertering

Erfaringerne fra pilotprojektet med 2995 dokumenter peger i retning af to forskellige arbejdsgange i forbindelse med konvertering af en Notes-database til markdown og efterfølgende opsætning i en statisk side generator. Den længste arbejdsgang bliver aktuel ved konvertering af databaser med formateret indhold (Rich Text), mens den korte er tilstrækkeligt, hvis databaserne udelukkende indeholder data uden formatering.

De to arbejdsgange er illustreret nedenfor.

7.A. Hardware/software

Konverteringen af den enkelte Notes-database kan foregå på en hvilkensomhelst pc. På følgende måde: - Onsite eller via VPN. - Den pågældende pc skal have Lotus Notes og Hugo installeret. - For ikke at forstyrre driften arbejdes der på en kopi af den pågældende Notes-database.

7.B. Programmering/manuel gennemgang

Hvor ville det være dejligt, hvis hele konverteringen var gjort med blot at «skovle» dataene fra Notes over i et andet system - og tænde for stikkontakten. Men nu er det jo en gang Notes, og endda en række indbyrdes vidt forskellige databaser, vi har med at gøre. Så vi står nærmere i den stik modsatte situation…

Det er bl.a. helt afgørende at finde ud af, hvor meget formateret tekst (Rich Text) inkl. bl.a. tabeller, doc-links, billeder og vedhæftninger, der «gemmer sig» i hver enkelt database. For at undgå, at denne analyse beror på en manuel gennemgang, har jeg udviklet en Rich Text-agent i Lotus Notes script, som kan afvikles på alle databaser. Forinden skal al Rich Text konverteres til MIME-format, hvilket sker med et par andre agenter. Men derefter kan Rich Text-agenten registrere alle «ubehageligheder», som derefter vises i et view, der giver et fuldstændig overblik over databasens indhold.

Derudover skal det besluttes, hvilke dokumenter der er behov for at trække ud, og hvordan de skal se ud. Hvis den pågældende database i forvejen er tilgængelig på web, er det oplagt at tage udgangspunkt i de eksisterende webformularerer ved beslutning om det fremtidige design. Har den pågældende database aldrig været «webificeret», forestår der en lidt større opgave med at lave et webdesign fra grunden til brug for den statiske side generator.

Fremgangsmåde for en database med formateret tekst: - Udtræk sker ved hjælp af Lotus Notes-værktøjet AgeCom, som ifølge mine tests skiller sig klart ud fra konkurrenterne. Den er således i stand til at konvertere hvert enkelt dokument til et HTML-dokument. Dette sker med udgangspunkt i et formular-design, som findes i databasen. Desuden har værktøjet en lang række indstillings-muligheder, som bl.a. gør det muligt at slippe af med det meste af den gamle HMTL (med font-tags, faste skriftstørrelser, faste bredder på tabelceller etc.), som Notes genererer. AgeCom er bl.a. i stand til at trække indlejrede og vedhæftede elementer ud og placere dem i filsystemet - enten i en undermappe med dokumentets nye filnavn, eller i en fælles mappe for hele databasen. Samtidig ændres dokumentets links, så de fortsat passer til de udtrykne elementer. Dermed får selv «meget rige» tekster lov at «beholde deres rigdom». - AgeCom aflererer en HTML, som er forholdsvis ren. Den er i hvert fald så renset, at det er muligt at køre batch-konvertering til markdown. Til dette findes der en række værktøjer på markedet, men jeg anbefaler frameworket to-markdown som er open source og baseret på Node.js. Når dette framework kaldes fra et batch-program, som jeg selv har lavet i javascript, er det muligt at auto-konvertere langt hovedparten/næsten alle HTML-dokumenter til markdown. - Vi slipper selvfølgelig ikke for at lave stikprøve-kontrol. Men indtil videre er jeg kun stødt på et behov for manuel tilretning af et dokument, hvis det indeholder tabeller. Hvor mange dokumenter, dette er tilfældet for, har kørslen med Rich Text-agenten allerede givet svar på. Man kan derfor nøjes med at gå manuelt ind i disse dokumenter og lave en pæn markdown-tabel. - Et alternativ mht. til tabellerne kan være at lade al tabel-HTML forblive inden i markdown-teksterne. Det er muligt at få vist indlejret HTML fra markdown direkte i de færdig-genererede HTML-dokumenter. Ulempen er dog, at hele tabel-formateringen følger med. Dermed opstår der stor risiko for, at tabellerne bliver grimme og/eller kører langt ud over kanten i det responsive design.

Der var ingen Rich Text af betydning i den testede Notes-database. Så den er et godt eksempel på, hvordan konverteringen af rene tekst-databaser bliver noget nemmere end ovenfor beskrevet.

Fremgangsmåde for en database uden formateret tekst: - Her trækkes indholdet af databasen ud med en Lotus Script-agent, som jeg har lavet. Den tilpasses til at overføre indholdet i det design, som ønskes, og med de nøgleord i front matter, som kan danne grundlag for den senere navigation på web. - Lotus Script-agenten batch-konverterer Notes-dokumenterne direkte til markdown-dokumenter 1-1. - Efter konvertering er stikprøve-kontrol naturligvis fortsat nødvendig. Men den vil typisk udelukkende afsløre mærkværdigheder i datamaterialet, eftersom agenten giver fuldstændig kontrol over dannelsen af hvert enkelt markdown-dokument.

7.C. Økonomi

• Timeforbruget til konvertering af hver enkelt database afhænger fuldstændig af, hvor meget formatering og hvor mange filer den gemmer på. Herunder ikke mindst om der er mange tabeller, som kalder på en menneskelig hånd.
• Et overslag skal derfor tages med alle mulige forbehold. Men det kan lyde på 10-20 timer til at konvertere en database uden Rich Text - 20-40 timer til at konvertere en database med Rich Text. Dertil kommer evt. yderligere tid til tilretning af tabeller og fejl i de indtastede data. Dette kan dog overlades til andre efter en kort instruktion.
• Antallet af timer bør dog blive noget lavere pr. database, hvis der er tale om at konvertere flere databaser med nogenlunde samme design og type af indhold.
• Hvis ellers markdown-filerne er, som de skal være, kan opsætning og generering af det endelige websted formentlig udføres p et par timer pr. database.

8. Drift

Driften af statiske websider er langt mindre krævende mht. hardware, vedligeholdelse og overvågning end database-baserede websider. Dette vil skinne tydeligt igennem rent økonomisk.

Desuden er statiske websider både stabile og sikre. Eftersom der i bund og grund (blot) er tale om at servere et utroligt stort antal HTML-filer for brugerne, kan bør adgangen kunne kontrolleres gennem rettighederne til de forskellige mapper, som filerne ligger i. De statiske websider er og bliver filer. Dermed er de også styret af den sikkerhed, som i forvejen ligger i filsystemet.

Hugo kan dirigere de genererede html-dokumenter for hver enkelt database hen til hvilkenhelst mappe. Det giver mulighed for at gruppere databaser (som jo nu er blevet til mapper med html-filer), hvorefter de kan linke til hinanden inden for hver gruppe.

Efter genereringen startes Hugos server, hvorefter siderne kan browses fra localhost:1313 (kan ændres). Dette gælder ikke blot siderne fra en enkelt generering. En enkelt instans af Hugo server er i stand til at køre multi-sites - dvs. servere sider fra x antal websteder/databaser, som er genereret hver for sig og på forskellige tidspunkter. Hugo kan også i én og samme kørsel generere dokumenter til x antal sites - også kaldet multi-tenancy.

Et alternativ kan være at benytte kundens eksisterende proxy til serveringen, så det hele foregår under én hat. Det kan også tænkes, at kunden foretrækker at bruge andre værktøjer til at løse opgaven med. HTML-filer er heldigvis utroligt lette at have med at gøre, når de først er genereret. De skal blot skovles ud i nogle browsere, som requester dem. Dette kan gøres på utallige måder.

Hvis der er ønske om at få oversat localhost-et-eller-andet eller 192.168.0.XX-webadresserne til noget pænere, findes der også værktøjer til dette, og kunden bruger sikkert nogle af dem allerede. Selv har jeg gode erfaringer med proxy-serveren Nginx på både Node.js og på Linux. Den serverer hver dag en to-cifret procentdel af de websider, der bliver læst på verdensplan. Nginx findes i en open source-version, der ser ud til at rumme de fleste af de funktioner, som man kan få brug for.

8.A. Hardware/software

Som nævnt er en enkelt fysisk server fint i stand til at afvikle x antal Hugo-sites - med endnu flere underliggende websteder (fordi nogle af dem er grupperet). Hvor grænsen går, må komme an på en prøve. Jeg er dog overbevist om, at den samme fysiske server vil være i stand til at servere lange flere statiske web-steder end servere, der bygger på databaser, og som derfor kræver et opslag og generering af HTML-kode, hver gang en bruger klikker med musen.

8.B. Programmering/mandskab

Hugo, Nginx og Node.js er alle open source. Så omkostningen til driften af disse begrænser sig til den ressource, der medgår til overvågning og vedligeholdelse af systemet.

8.C. Økonomi

Det anbefales i første omgang at afsætte en fysisk - eller virtuel - server til driften af de første statiske websteder. Om der senere vil blive behov for flere servere, afhænger dels af antallet af konverterede databaser, dels af hvor aktivt de bliver brugt.

Hugo er i stand til at deploye - dvs. overføre HTML-filer - direkte til en Git-server. Så hvis der i forvejen er planer om at lave udvikling i Git, vil det være oplagt at samtænke dette med driften at statiske websider.

Til sidst skal det lige med, at Node.js også er en en velegnet platform til drift af mindre statiske websteder end dem, det drejer sig om her. Dvs. websteder, der kræver hyppig opdatering fra x antal brugere. Her taler vi om CMS-systemer, der gemmer i databaser. Dette foregår typisk ikke i (My)SQL - men i dokument-databaser/NoSQL-databaser, hvor MongoDB er den langt mest udbredte. Af gode kandidater til at løse en sådan opgave uden licens-udgift og binding til et bestemt styresystem kan her nævnes Keystone og PencilBlue, hvor én installation af sidstnævnte endda kan håndtere x antal websteder - ligesom i det ovenfor skitserede forslag.