Used: C#, JavaScript (React), SQL, HTML, CSS. Visual Studio, SQL Server Management Studio, Microsoft IIS/.NET
Under min andra sommar på ABB i Västerås fick jag ansvaret för utvecklingen av ett nytt intern system. Det fanns ett behov av en smidigare process för samla information om produkter då det aktuella tillvägagångssättet var att skicka runt ett gigantiskt exceldokument mellan 10-20 personer. Dessutom fanns produkter av vitt skilda kategorier och därmed egenskaper – en licens för en programvara har till exempel varken en angiven vikt, färg eller bredd. Så ”vad ska fyllas i för just denna produkt”, ”vad ska just jag fylla i” och ”vad betyder ens den här förkortningen?” kunde vara de problematiska frågorna som de fick ställa sig. Målbilden av projektet var ett webbgränssnitt som skulle innehålla ett väldigt dynamiskt produktformulär. Alla skulle ha tillgång till de senaste uppdateringarna och ha rätt redigeringsbehörighet beroende på roll. Framförallt skulle bara relevanta fält dyka upp i formulären för att hålla det enkelt och översiktligt.
I uppstartsfasen pratade jag mycket med de som önskat sig det nya systemet och skissade för att fastställa någon typ av kravspecifikation. Det var extra viktigt i och med att samma personer snart skulle på semester och att jag snart skulle arbeta väldigt självständigt. Bilden här nedan visar en prototyp som jag gjorde i Proto.io under första veckan:
Och några veckor senare, en start på webbapplikationen i React.js:
För att det hela skulle fungera smidigt behövde jag fundera mycket på systemets backend, speciellt hur jag kunde designa en passande databas. Det vill säga vilka tabeller som skulle finnas och vilka fält de skulle innehålla, vilka nycklar och relationer de skulle ha till varandra och så vidare. Också för att kunna ställa effektiva frågor till databasen (som inte behöver leta igenom så många rader varje gång) och inte innehålla repetetiv data. Inte förrän nu i efterhand insåg jag att det jag skapade var en så kallad Key-value database. Det jag kände till sen innan var relationsdatabaser, där strukturen för varje ”objekt” är fördefinerat. T ex om objeket ( en rad i tabellen ) ska representera en hund så kanske de olika fälten är: ras, namn, ålder, favoritleksak. Jag behövde något mer flexibelt för att inte behöva ha ett femtiotal tomma fält för alla produkter bara för att någon annan produkt behövde den informationen. Bilden nedan visar en tabell ur databasen under utvecklandet. Det är en tabell som definerar alla formulärsfält, och som går att se (om man kollar noga) är att ett varje fält har ett parameter-id som är unikt. Sedan kan en annan tabell som definerar vilka fält som ska ingå för en viss produktklass innehålla kopplingar till dessa parameter-id. Samt för att hålla koll på sparade värden, en tabell med fälten (produkt-id, parameter-id, värde ), till exempel!
Och ännu några veckor senare, ett fungerade gränssnitt! Det skedde en del mer finlir efter den här videosnutten och den visar egentligen inte den mest relevanta funktionaliteten – men det var vad jag hittade.
Se också det här blogginlägget från när jag var i full gång med utvecklandet och här är en powerpoint som jag presenterade i slutet – mer detaljer där!
