Min tekniske arbeidsflyt som webutvikler

25. mars 2017
Asbjørn Ness

I dette innlegget skal jeg ta en gjennomgang av hvordan jeg jobber når jeg utvikler websider. Det vil si i valg av verktøyer, rammeverk, systemer og hvordan jeg tenker. Artikkelen ble sist oppdatert 25. mars 2017.

Illustrasjon: Colourbox

Innfallsvinkel

Jeg anser meg selv som en lettvekter innenfor front end-utvikling, og har ikke en erfaren programmerers innfallsvinkel til verktøy, programmeringsspråk og alle nye metoder. Det er derfor med forbehold om at det finnes mer effektive og oppdaterte metoder at jeg skriver dette innlegget.

Formålet er å inspirere deg til å komme i gang med noe tilsvarende, uten å være profesjonell. Og gi et innblikk i flere deler av prosessen som ikke nødvendigvis nevnes i sammenheng.

Innhold

Videre skal jeg gjennomgå følgende punkter:

  • Valg av publiseringsverktøy / CMS / CMF / teknisk plattform.
  • Valg av rammeverk for CSS/HTML/JavaScript.
  • Oppsett av versjonshåndtering med git.
  • Forholdet mellom lokalt utviklingsmiljø og live produksjonsmiljø.

Publiseringsverktøy

Siden våren 2015 har jeg utelukkende holdt meg til ProcessWire og brukt tiden på å lære meg dets API. Jeg har gradvis blitt flinkere og er i stand til å løse de fleste problemstillingene jeg støter på. Du kan lese mer om dette i En innføring i ProcessWire.

Det finnes mange publiseringsverktøy å velge mellom. Det er fordeler og ulemper med de fleste. Det kan være snakk om smak og behag. Eller hvilket kunnskapsnivå du ønsker å legge deg på. Poenget mitt er at det er en fordel å lære seg et system godt, da du kan løse oppgaver effektivt.

Er du dreven på programmering, går du muligens bort fra CMS-er med sine begrensinger. Du vil gjerne bygge løsninger som kan utføre oppgavene akkurat som du ønsker og på en optimal måte. For mange, meg inkludert, er fremdeles et CMS et nyttig utgangspunkt.

Kort oppsummert, velg et publiseringsverktøy som du tror kan løse dine problemer, og lær det godt.

ProcessWire sett fra innsiden

Rammeverk

Et rammeverk kan være så mangt. I dette innlegget bruker jeg kun begrepet om CSS/HTML/JavaScript-rammeverk. Det finnes uttallige varianter. Det mest kjente er nok Bootstrap.

Det finnes lettvektere med begrenset funksjonalitet som Concise CSS og Simple Grid. Og tyngre, mer funksjonsrike rammeverk som Foundation.

UIkit

Jeg ofte UIKit til mine egne prosjekter. Det har en del funksjonalitet, oversiktlig dokumentasjon, og er lett å tilpasse. Og det tar ikke all verdens plass i antall kB, en fordel om man vil bygge for rask lasting. Det har også flex, noe Bootstrap i skrivende stund ikke har støtte for annet enn i sin alpha-versjon av Bootstrap 4.

Boostrap

Fordelen med Bootstrap er at mange bruker det. Lurer du på noe, finner du sannsynligvis svaret fort på Stack Overflow eller ved et nettsøk.

Orienter deg

Les dokumentasjonen til flere rammeverk. Se om de inneholder elementene du kommer til å bruke. Har du kunnskap nok til å bygge videre selv der funksjonalitet mangler? Om du er en nybegynner, vil jeg anbefale å starte med Bootstrap.

CSS og preprosessorer

Som et tillegg til forrige punkt tar jeg en kjapp tur innom CSS. Den generelle trenden går mot at SCSS leder an i rammeverkverden som preprosessor. Less er et alternativ. Noen bruker også PostCSS, som er relativt nytt.

SCSS og Less er preprosessorer, og de er ganske like. Når SCSS- eller Less-filene kompileres, blir de til CSS. Grunnen til at de brukes, er fordi de lar deg skrive mindre kode. Til det brukes teknikker som variabler og funksjoner.

Selv har jeg brukt både SCSS og Less fordi tilgjengeligheten har vært ulik på tvers av UIkit-versjonene. Jeg sjekket temperaturen da jeg for alvor begynte å se på mulighetene til preprosessorer for under to år siden. Inntrykket mitt var at SCSS tok mer og mer over, og jeg valgte å bruke SCSS i rammeverkene som støttet det den gangen. Siden da kom UIkit 3 som ved lansering av beta-versjonen kun hadde Less-støtte.

Versjonshåndtering

Jeg planlegger å skrive et eget innlegg om git, for å samle trådene jeg selv fant det vanskelig å nøste sammen da jeg startet å skrape i overflaten av versjonshåndtering. Inntil da blir det kun en kort introduksjon:

Med git kan du loggføre endringene dine systematisk. Du kan gå tilbake til tidligere versjoner av en fil. Du kan ha flere versjoner av filer, ved å jobbe i branches. Hoved-branchen din er en master. Om du ønsker å utvikle noe nytt, lager du en ny branch, og jobber i den. Faller det arbeidet i grus, går det ikke utover masteren, og du kan lett slette den nye branchen. Er du fornøyd kan du slå den sammen med masteren. Det er mange flere muligheter, men dette er et greit sted å starte.

Jeg bruker git, og har en konto hos GitHub hvor jeg også lagrer (pusher) endringer til. Å loggeføre og kunne jobbe med mulighet til å hente opp igjen filer ved feil, gir en trygghetsfølelse, og sparer meg fra mye dobbeltarbeid ved eventuelle feil.

Git for Filmdagbok

Automatisering av arbeidsflyt

Når jeg koder er det mange ting jeg gjør opp igjen og opp igjen. Sånn er det også for mange andre, og derfor har det oppstått flere metoder for automatisering av arbeidsflyten.

Følgende punkter er ting jeg gjør hele tiden:

  • Slår sammen SCSS-filer, gjør de om til CSS, forminsker de og legger de i en egnet mappe.
  • Slår sammen noen JavaScript-filer for seg, andre for seg, forminsker de og legger de i en annen mappe.
  • Oppdaterer PHP-filer med nye versjonummer bak CSS- og JavaScript-filene for å slippe trøbbel med nettleserens mellomlagring av filer.
  • Går inn i nettleseren og trykker Oppdater hver gang jeg vil se endringer jeg har kodet.

Tidligere brukte jeg en metode for automatisering som heter grunt. En annen populær metode er gulp. Hva som er best, som i lettest, mest fornuftig å bruke og mest oppdatert, har jeg ingen forutsetning for å avgjøre. På dette område anser jeg meg selv som nybegynner.

Grunt kjøres ved at jeg har en gruntfile.js i en mappe. I denne står det et sett med instruksjoner, som hvilke filer som skal slås sammen, kompileres, flyttes og når nettleseren automatisk skal oppdatere en side. Det siste gjøres i samarbeid med en Chrome-utvidelse som heter LiveReload.

Grunt kjørtes i mitt tilfelle fra Terminal i macOS, ved at jeg skriver grunt for å kjøre hele prosessen, eller grunt watch for å la det stå på og følge med på filer som blir lagret fortløpende.

Med lansering av UIkit 3 begynte jeg å bruke deres metode for automatisering, som bygger på node.js. Grunt og gulp er pakker som installeres på toppen av node.js, så metoden til UIkit 3 er sånn sett en forenkling.

Grunt i Terminal på macOS

Lokalt miljø og produksjonsmiljø

Med unntak av ørsmå feilrettinger når jeg har dårlig tid, så oppdaterer jeg aldri kode rett på websiden som ligger offentlig. Det vil si i produksjonsiljøet. All koding skjer først lokalt, hvor det kan testes. Deretter lastes filene opp.

Det finnes metoder for å bruke git til å automatisere opplasting av filer. Å ha git i produksjonsmiljøet har sine fordeler, da du kan rulle tilbake til en tidligere versjon, dersom oppdateringen var forhastet.

I mine prosjekter er filene som endres begrenset til en til to mapper, som jeg vanligvis laster opp via FTP. Med andre ord manuell flytting av filer.

Jeg jobber lokalt med verktøyet MAMP PRO som et program med grafisk brukergrensesnitt for å sette opp sider på en lokal server, det vil si på min egen datamaskin. Eksempelvis har jeg en lokal side tilsvarende http://www.asbjornness.pw/ hvor jeg utvikler. Der kjører jeg en kopi av ProcessWire som er hentet fra produksjonsmiljøet. I skrivende stund er også dette en manuell jobb med en del overlapping, og har forbedringspotensiale.

Følg med framover for et eget innlegg om hvordan du installerer ProcessWire lokalt ved hjelp av MAMP PRO i macOS.

En oppsummering

Jeg har såvidt skrapet overflaten på noen generelle deler av min webutviklingsprosess. Denne er i stadig endring, hvor jeg gradvis beveger mot mer effektive metoder. Trygghet, testing og en idé om at arbeidet mitt skal kunne overlates til andre ved nødvendighet er andre ting jeg har i tankene.

Jeg gjenbruker mest mulig av det jeg lager, og hva andre tilbyr. Jeg forsøker å holde kodemengden liten, og ta utgangspunkt i at når noe lages så er det en del av en helhet. Et eksempel er farger. Med SCSS og variabler defineres fargepaletten kun et sted, og gjenbrukes.