Jeg byggede et fuglehus

Bogstaveligt talt! Et som fugle kan lægge æg og få unger i. Det kan være godt for et webprojekt at tage kapgeringssaven frem og save noget sibirsk lærk.

Jeg har længe arbejdet på at større projekt, hvor et ret omfattende website skal snakke sammen med nogle eksterne systemer, som arbejder med ASP og en Microsoft-database.
Som mange udviklere ved, så er det normalt ret nemt at tæmme data så længe de er indenfor ens eget system, følger reglerne for formatering, tegnsæt, databaseopbygning osv. Og så hjælper det selvfølgelig også at de er lavet af en selv, og følger de skrevne og uskrevne regler, der er for hvordan ting opbygges.

Vi har i Vertikal f.eks. i mange år arbejdet med UTF8- og UTF32-tegnsæt, fulgt anbefalede navngivnings- og kodestandarder og konsekvent lavet alt på engelsk. Vi bruger engelske navne til alle funktioner, variable, inline-dokumentation, docblocks osv. – og vi bruger ikke camelCase, men kun små bogstaver og underscores – med mindre, der er en standard, der foreskriver noget andet.

Sådan er det ikke ude i den store verden. Jeg skulle bl.a. arbejde med en MSSQL-database, der brugte et ikke nærmere specificeret Windows-tegnsæt, blandede HTML-entities og de ”rigtige” tegn – altså både æ, ø, og å og æ, å og ø i den samme streng – brugte danske bogstaver i tabel- og feltnavne og ingen form for systematik havde i navnene eller deres bogstavering.
I database-schemaet kunne f.eks. være tabeller eller felter, der hed: personID, persongrænse, MedlemForeningsPersonNøgle, kæde… kæde? Hvem kalder en tabel i en database for kæde? Well, nogen gør. Og nogen bruger ingen former for systematik i navngivningen, hvorved al selvforklaring udelukkes. Det er en af årsagerne til at jeg nærer en slet skjult afsky for at arbejde med andre folks data og kode.
 

Nå, men nok om det, for opgaven var givet: der skulle laves en spejling af databasen i vores Drupal-baserede system, som kunne udveksle data gennem web-services med det eksterne system.
Det skulle vise sig at være mere besværligt end det lyder, bl.a. af ovennævnte årsager. Jeg fik først databasen som en MSSQL-backup. Sådan en er en massiv fil, som er pakket efter en-eller-anden Microsoft-standard, og kun kan pakkes ud ved at man reetablerer den på en MSSQL-server.
Sådan en havde jeg ikke på min lokale maskine, så det skulle der gøres noget ved.

Microsoft har heldigvis en gratis udgave af deres database-miljø, som man kan installere, og det kastede jeg mig over. Utallige filer blev downloadet og navne som Active Directory Authentication Library for SQL Server, Microsoft ODBC Driver 13 for SQL Server og Microsoft SQL Server Data-Tier Application Framework samt en snes andre ligeså langnavnede programmer dukkede op i listen over installerede programmer på min maskine samtidig med at yderligere en gigabyte diskplads forsvandt.
Jeg har før bitchet over kompleksitet, og denne proces fik mig ikke til at tage mine ord i mig. Tværtimod! For at genskabe databasen, skulle jeg installere talrige MS-programmer og -komponenter, for derefter at kunne kaste mig over SQL-serverens komplekse visuelle interface.

Lang historie kort: Til trods for at jeg har arbejdet med MSSQL før, så lykkedes det mig ikke at få data ind i nogen læsbar form. Jeg sad med en klods data på næsten 1,2 GB, og skulle blot bruge nogle få tabeller hver på nogle hundrede KB, men intet gjorde som det skulle.

Jeg brugte en stor del af to arbejdsdage på det, fik hjælp af vores server-haj Martin, kæmpede og sloges, og lige fedt hjalp det. Jeg fik nogle data ud, men kunne ikke finde alle de relativt få data jeg skulle bruge.
Når data skal ud fra den MySQL-database, jeg normalt arbejder med, så ”dumper” man dem til en tekstfil. I denne fil står alle SQL-kommandoerne og alle data i klartekst, og man kan åbne filen i en editor, læse hvad der står og sågar klippe det ud man skal bruge hvis man ønsker det. Filen pakkes typisk ned med en standard ZIP- eller GZ-algoritme, som kan pakkes ud på stort set alle platforme.

Filen kan reetableres på stort set enhver MySQL-server gennem et web-interface (som f.eks. PHPMyAdmin) eller med en kommando i stil med mysql -u user -p database_name < dump.sql
For nogen virker det indviklet, men det er i mine øjne noget nemmere end at skulle parkere den halve Microsoft-vognpark i sin lille garage for blot at konstatere at intet kører alligevel.

Det var her jeg byggede et fuglehus!

Det var her jeg byggede et fuglehus!
Bogstaveligt talt. Jeg byggede et fuglehus. Sådan et som fugle kan lægge æg, ruge og opfostre deres unger i.
Som mange ved, så arbejder jeg i et kontor i mit hjem, en ting hvis glæder jeg har besunget før. Det betyder bl.a. at når der går knuder i en proces, så behøver jeg ikke gå ud til kaffemaskinen på kontorgangen og hænge uproduktivt ud for at få luft, men jeg kan åbne min terrassedør og gå ud i haven. De forgangne uger har vi bygget et drivhus her på matriklen, og der var en del sibirsk lærk tilovers fra det projekt. De kunne passende blive til fuglehuse til havens mange småfugle, som lige nu er på jagt efter et sted at stifte familie.

Så jeg pakkede værktøjet ud, og denne gang de fysiske: kapgeringssaven, skruemaskine og bits (men ikke bytes), boremaskine og bor, vinkler, file, sandpapir og alt det hejs. På nettet finder man nemt anvisninger på dimensioner: størrelser på flyvehul, dybde osv., som gerne skal laves til de fuglearter man har i haven. Fugle er ikke ligeglade: blåmejser vil gerne have 28mm huller, musvitter 32mm. Gråspurve kan bedre lide 34mm mens skovspurve ligesom musvitter er mere til 32mm. Jo, de er skam kræsne på millimeteren de små fjerede!
Med en grov skitse optegnet på et ark A4 kastede jeg mig over lærken (træet altså) og savede 90- og 30-graders vinkler så det stod efter. Efter en kort stund havde jeg de 6 stykker som udgør en fuglekasse, og kunne skrue dem sammen med de tiloversblevne skruer fra vores ligeledes nyligt overståede terrasseprojekt.

Alt i alt et meget tilfredsstillende resultat, og noget som ville kunne løfte humøret hos næsten enhver kontorslave. Mens jeg arbejdede med duften af harpiks i næsen, afskærmet fra verden af beskyttelsesbriller og høreværn, tænke jeg ikke meget på tegnsæt og feltnavne, men fik lige præcis den luft og energi, der skulle til for at kunne komme videre.

Løsningen på databaseproblemet viste sig at være enkel.

Med lidt hiv og lidt sving og lidt human ingeneering – læs: telefonsamtaler – fik jeg tilsendt simple, små, kommaseparerede dumps af de få databasetabeller jeg skulle bruge. Alt i alt ca. 2 MB data, hvilet står i skærende kontrast til de 1,2 GB jeg fik i backuppen.
I CSV-filerne stod feltnavne og data i klartekst, og ved hjælp at det database-schema, jeg også havde fået, var der ikke de store ben i at få kørt data ind i MySQL og gøre dem tilgængelige for Drupal.

Så nu er data i hus, og der kan opbygges formularer hvor brugerne kan redigere dem. Så skal der blot opsættes web-services, således at data kan komme tilbage i den oprindelige MSSQL-database, hvor de skal bruges af nogle eksterne ASP-baserede systemer. Jeg håber ikke at den medarbejder, der skal arbejde med min webservices, bliver lige så forbandet over mine data, som jeg var over deres.
Jeg leverer data tilbage med de oprindelige feltnavne og tegnsæt, således at modtageren forhåbentlig ikke behøver hænge ud ved kaffemaskinen i frustration for at komme igennem processen.

Hvis det er tilfældet kan jeg anbefale i stedet at få lidt luft ved at bygge et fuglehus!
 

Vi sælger skamløst viden og assistance vedrørende