Gå til innhold

Profesjonell webutvikling i 2013


Anbefalte innlegg

Vet du hva som ble slettet?

Absolutt ingenting er slettet. Annet enn ditt eget innlegg som kun inneholdt en smiley.

 

Men nok off topic nå. Setter strek for off topic her:

------------------------------------------------------------------------------------- <- strek

Endret av L4r5
  • Liker 1
Lenke til kommentar
Videoannonse
Annonse

Idag så går det det mykje i Fabric og Putty hos oss. Men eg synes /bin/sh pluss SSH er godt nok. Eg orker rett og slett ikkje å måtte lære meg noko nytt som eigentleg ikkje er betre heller. Og alle unix systemar har /bin/sh, det er ikkje alle som har Ruby eller Python.

Lenke til kommentar

Nå synes jeg ikke VG eller Stackoverflow er veldig representativt for løsningene en jobber med. Ihvertfall jeg har fortsatt til gode å publisere et forum, eller en nyhetstjeneste i profesjonell sammenheng. Selv om det er en løsning med mye trafikk synes jeg ikke det er akkurat det å ha en løsning med mye trafikk som er vanskelig. En må gjøre kompromisser for å sikre oppetid, eller være mer konservativ med endringer, men ihvertfall for meg som backendutvikler så ligger utfordringene i forretningslogikken.

Hverken du eller jeg kan mene noe om noe vi vet lite om. Hva som foregår av backend-tilpasninger og integreringer på nevnte eksempler er ikke så lett synlig for oss. Det er slik det skal være for velfungerende nettsteder.

Spesielt kundenes evige behov for merkelige detaljer og rapporter, og uvilje til å bruke publiseringstjenester for å lansere eller oppdatere innhold (vi vil bytte navnet på et abonnoment: bug report) og begrensninger i tredjepartsverktøy, eller tilogmed egne verktøy, som sniker inn cowboy-logikk som er legacy så fort det kommer ut i produksjon.

 

[...]

 

Min erfaring er at trafikk i seg selv er ikke et problem, eller det er i det minste lett å skalere seg etter. Utfordringen er å kunne legge ut en løsning som fungerer riktig i alle bruksscenarioer, og som er enkel å vedlikeholde i ettertid. Det er faktisk det som er jobben. Det finnes ikke perfekte utviklingsverktøy, eller rammeverkt og tjenester uten merkeligheter eller begrensninger. Det å takle dette på en fornuftig måte og samtidig ikke banne over en lav sko er et aspekt som jeg synes er i stor grad oversett.

 

Alt det du skriver kan vel de fleste kjenne seg igjen i i forskjellig grad. Poenget mitt var nok nærmere at vi kan trekke lærdom fra sites som har opplevd "/." eller "digg" effekten, eller eventuelt DOS angrep. Dersom de som har stått bak sidene ikke hadde lært seg å tenke skalering underveis ville noen av konkurrentene overtatt tronen. Det er ingen plass for andre plass. Ytelse er ett hensyn som må tas hensyn til fra backend til frontend. Men det er flere hensyn man må forholde seg til, som du påpeker.

Lenke til kommentar

Idag så går det det mykje i Fabric og Putty hos oss. Men eg synes /bin/sh pluss SSH er godt nok. Eg orker rett og slett ikkje å måtte lære meg noko nytt som eigentleg ikkje er betre heller. Og alle unix systemar har /bin/sh, det er ikkje alle som har Ruby eller Python.

Det er veldig lett å kjøre oppdateringer på flere servere i parallell med Fabric. Og du behøver bare å installere Fabric på serveren du trigger skriptet fra. Det er ikke helt det samme som ett sh skript.

Lenke til kommentar

Har brukt Octopus endel i en tidligere jobb. Likte det ganske bra, men det ble endel kluss når man brukte det sammen med SlowCheetah for dev-time configfletting... (Octopus tok tak i fler filer en den skulle)

 

Men mesteparten av koden jeg jobber med just nu deployer med 7zip og en bat-fil :p

Lenke til kommentar

Det er veldig lett å kjøre oppdateringer på flere servere i parallell med Fabric. Og du behøver bare å installere Fabric på serveren du trigger skriptet fra. Det er ikke helt det samme som ett sh skript.

Det kan du enkelt gjere med eit shell script og! Inkluderert parallelle oppgåver!

 

Når eg trengje Python, så er det som regel ein god del meir avanserte oppgåver som skal løyast. Og då vil eg trengje tilgang til avanserte tredjeparts verktøy. Men framleis så blir dette Python skriptet som blir eksekvert igjennom eit shell script.

Lenke til kommentar

Hva brukes egentlig av deployverktøy? Her omrking har vi utviklet et eget som vi bruker for selve deployen, men det hadde vært fint om vi fikk gjort det litt enklere.

Siste tiden har jeg jobbet primært med nettskyen og Windows Azure. Der foregår deployment direkte fra utviklerverktøyet, som pakker ned filene i en slags .zip fil som lastes opp og deployes til en ny virtuell maskin. Man kan også laste opp manuelt om det er ønskelig.

 

Jeg vet at IIS har noe som heter Web Deploy, men har aldri fått det til å fungere riktig. For eldre løsninger, brukes ofte FTP eller rett og slett RDP.

Lenke til kommentar

Med forbehold om at jeg bare har skumlest denne tråden: Glem PHP. Det er utbredt, men et dårlig språk, fremtida ligger ikke der. Go, node.js etc. er muligens up-and-coming, men ennå ikke godt etablert for webutvikling. Java og .NET er fortsatt mye brukt, men ikke spesielt spennende, spør du meg.

 

Hvis du vil lære deg profesjonell webutvikling anno 2013 er det to veier å gå:

- Ruby og Rails

eller

- Python og Django

 

Ruby og Python er programmeringsspråk, Rails og Django er webrammeverkene. Begynn med å lære deg et av språkene, gå så over til rammeverkene. Fins mange gode tutorials. Språkene er ganske like, selv foretrekker jeg Ruby, selv om jeg liker begge. Rails har etter min mening litt bedre struktur enn Django, og gjør også mer automatisk for utvikleren.

Lenke til kommentar

Bruk w3c for alt det er verdt, og den enkleste måten å få bra designede sider, "språkmessig", er via avanserte teksteditorer. For windows er Notepad++ gull, for Linux er det svært mange alternativer, personlig liker jeg Kdevelop/Kate.

 

WYSIWYG-editorer er mindre WYSIWYG enn en teksteditor når det kommer til stykket :p

Lenke til kommentar

Det er en ganske drøy påstand og hevde at man må skrive alt fra bånn. Man øker produktiviteten dramatisk ved å bruke verktøy som Dreamweaver CS6 eller CC.

 

Det var spørsmål om profesjonell webutvikling. Ingen bruker wysiwyg-verktøy i profesjonell sammenheng.

 

Fra min egen erfaring. Som det står - satt på spissen. Folk gjør så mye rart. Men i hovedsak er Dreamweaver et verktøy for grafiske designere som primært jobber i Photoshop og vil ta designet sitt interaktivt ut på web. Det er ikke noe profesjonelle webutviklere bruker, de har lite å tjene på et slikt verktøy, det funker bedre for de som ikke har html/css i fingertuppa, men de kan ikke kalle seg profesjonelle webutviklere.

 

Adobe produkter for noobs.

 

Jeg anbefaler

http://notepad-plus-plus.org/

 

Mange som uttaler seg om Dreamweaver og klarer å framstå som all mouth no knowledge i den sammenhengen.

 

Jeg bruker selv Notepad Plus Plus i mange sammenhenger, også til koding. Helst kun dersom koden er kortere enn en skjermside. Dreamweaver er derimot en svært god kode-editor med suveren server-håndtering. Vi koder objektorientert PHP, hovedsaklig fra bunn av men også sammen med rammeverk, og Dreamweaver har masse god støtte uten at noen av oss har sett WYSIWYG-grensesnittet på ti år. Å bruke Notepad Plus Plus er som å gå tilbake til skrivemaskin fordi det er kulere å være forfatter på skrivemaskin. Du erklærer at du er dust, men en stolt dust som står for din egen kode. Jaja, fint for deg, vi ansetter nok ikke deg først.

 

Vi ønsker å ikke bruke Dreamweaver på sikt, spesielt etter Cloud-greia kom og gjør Adobe-programvaren dyrere i forhold til vår spesifikke total cost of ownership. Men Eclipse og de andre tingene vi har testa ut har rett og slett ikke vært gode nok. Dreamweaver har riktignok en WYSIWYG-del. Men alle som tror at det er "greia" med Dreamweaver, er helt på jordet. Det er tre standardmodus i Dreamweaver, og hvis man koder så er det naturlig å vurdere Dreamweaver for dets "code"-modus, ikke "design". Der står Dreamweaver godt på egne bein. Og håndteringa med testserver, utviklingsserver, liveserver og code repository er riktignok ganske dårlig, men likevel tusenogfemti prosent bedre enn noe annet vi har vært borti. Å gå tilbake til egen klient for å laste opp filer hit og dit er helt utenkelig, så lite effektiv er det ikke lov å være.

 

Så til trådstarter:

 

Det er mange jobber hvis du behersker LAMP (Linux/Apache/MySQL/Php) og kan dokumentere dette på ett eller annet vis.

Endret av tommyb
Lenke til kommentar

Min favoritt for tiden er å bruke http://nodejs.org/ sammen med http://expressjs.com/ så kan du skrive både backend og frontend i javascript. Favoritt teksteditor er http://www.sublimetext.com/.

+1. Bruker også for express for de fleste web backends for tiden. På klientsiden går det i angular eller backbone og for deployment bruker jeg enkle bash-script som puller kode fra GitHub. Herlig å kunne skrive det meste av koden i JavaScript. Hvis jeg må lage noe CMS-lignende greier kan det dog hende jeg bruker Ruby On Rails, da det imho løser denne typen oppgaver meget godt, og har mange gjenbrukbare gems.

 

Gode gamle Make er i tillegg uvurderlig for å oppgaver som å bygge css- og js-filer, og alle andre automatiserte oppgaver for den saks skyld.

Endret av Alex Moran
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...