Internett er under stadig forandring, noko som fører til at du som utviklar også stadig må fornye deg, og tilegne deg ny informasjon.
Kva for slags teknologier blir viktige å kunne i 2010?
Meldingskøer
Eit godt eksempel på dette er registreringsprosessen som dei fleste nettsider har. Scenarioet er vanlegvis som følgjer:
1. Bruker fyller ut eit registreringsskjema, skriv inn brukernamn, passord og epost-adresse
2. Brukeren blir sendt til ei ny side med informasjon om at kontoen blir oppretta, og at ein aktiveringsepost snart er å finne i brukerens innboks
For dei fleste små sider går det vanlegvis fint å integrere heile logikken med oppretting av konto, utsending av aktiveringsepost osb. direkte i applikasjonen. Men kva om sida di havner på Digg, Reddit, Slashdot eller liknande sider, og tusenvis av brukarar byrjer å registrere seg?
Sannsynlegvis byrjer databasen din å kjenne trykket. Så får SMTP-serveren din ein stor baklogg. Konsekvensen av dette er at brukaren kjem til å oppleve sida di som forferdelig treig.
Ved å avlaste registrerings- og verifiseringsprosessen til eit eksternt ledd, får serveren din moglegheita til å bearbeide informasjonen i eit tempo som er passande for den. Og brukaren får inntrykket av at tjenesta di er kjapp og påliteleg.
Dei to mest kjende meldingskøserverane er antaglegvis Apache ActiveMQ og RabbitMQ, som inneheld det meste av funksjoner ein måtte trenge – for applikasjoner av alle størrelser. Du har óg meldingskøer som er litt lettare i vekt, som Resque, Gearman og Beanstalk, så du finn heilt sikkert noko som passer din applikasjon og dine ressurser.
Eit serverside-rammeverk
Veldig få applikasjoner blir i dag bygd opp frå bunnen med blanke ark i Java/PHP/Ruby/Python/ditt-språk-her. Dei aller fleste er avhengig av eit rammeverk som forenkler prosesser som er aktuelle i sammenheng med nettet (enten det måtte være databaseabstraksjon, REST-mønstre, serialisering av objekter osb…). Kvart språk har eit rammeverk som er meir populært enn konkurransen. Python har Django, PHP har Symfony, Java har Spring, og så vidare.
memcached
Hjørnesteinen i einkvar kjapp applikasjon har dei siste åra vore memcached. Utvikla hos LiveJournal for å støtte den eksplosive veksten dei i si tid hadde på ganske begrensa ressurser. memcached er ei enkel, distribuert og minnebasert nøkkel-verdi-database som er lynrask. Berre spør Facebook, som har over 800 servere og 72 TB minne dedikert til memcached.
Ein bruker ofte memcached til lagring av ferdiggenererte HTML-snutter som er komponert av statisk og dynamisk data, for å sleppe at logikklaget må komponere dette på nytt for kvar sidevisning. Eit anna bruksområde som ein ofte finn (blant anna hos Twitter) er «Rate limiting«, for f.eks. å begrense antall ganger du kan oppdatere Twitter-profilen din pr. time.
Ikkje-relasjonelle databaser
Ei bølge av interessante databaser har dukka opp dei siste åra. Dei mest kjende er Cassandra, CouchDB, MongoDB og redis. Hovudforskjellen mellom tradisjonelle databaser, som MySQL, og dei ikkje-relasjonelle databasene som nevnt ovanfor, er at ein går lengre og lengre vekk i frå å beskrive datarelasjoner i databasen, og heller lar applikasjonslaget ta seg av denne prosessen. Store sider som Twitter og Digg har fram til heilt nylig brukt MySQL for å lagre alt av data, for å så laste mesteparten av dette i minne via memcached. Etter kvart innsåg dei at MySQL ikkje gav dei nokon form for fordel ovanfor ikkje-relasjonelle databaser, sidan informasjonen deira allereie var normalisert til eit punkt kor JOINs ikkje var aktuelt (eller fordelaktig ressursmessig).
Begge desse har no gått over på den kraftigaste av dei tidligare nevnte ikkje-relasjonelle databasene, nemleg Cassandra.
(for min eigen del er MongoDB svært interessant: JavaScript-basert, innebygd MapReduce, innebygd 2D-matching, automatisk sharding av data, og JSON som datautvekslingsformat)
jQuery
Ja, eg skreiv jQuery i staden for “eit JavaScript-rammeverk”, då jQuery har posisjonert seg ovenfor konkurransen. Ingen andre JavaScript-rammeverk er meir brukt enn jQuery, og sannsynet er stort for at din noverande eller neste arbeidsgivar bruker det over f.eks. Prototype.js eller MooTools. jQuery har blitt like de facto for JavaScript som WordPress er for PHP (berre med bedre kodebase, he he), og skal ha mykje av æra for å bringe JavaScript til den kvardagslege nettutviklaren.
Basisforståing for HTML5
I natt publiserte W3C ein ny versjon av dokumentet som spesifiserer kva som er nytt i HTML5, så denne er ganske enkel. Dette dokumentet forklarer fint kva for slags omstillinger du må gjere for å oppdatere koden din til den femte revisjonen av HTML.
Har vi gløymd noko?
Er det noko du savner frå denne lista? Fyll opp!
Er noe som er glemt her =)
Cloud Computing – Det er viktig å ha forståelse for hva Cloud Computing er for noe, hvilke muligheter som finnes og kanskje lære seg ett eller flere av de tilgjengelige miljøene for Platform-as-a-Service.
Annet områder som blir mer viktig fremover er «Internet Service Bus», hvor man eksponerer tjenester via eksterne leverandører og dermed muliggjør kommunikasjon på tvers av lukkede nettverk uten å åpne opp brannmurer.
Claims-based sikkerhetsmekanismer er et annet område man bør ha litt forståelse på, integrasjon på tvers av løsninger og organisasjoner blir mer og mer aktuelt og etterspurt.
Man bør selvsagt se på Adobe Flash og Microsoft Silverlight, som er de to største alternativene for rike web-applikasjoner. Disse rammeverkene blir i stor grad også brukt til desktop-applikasjoner, se f.eks. WiMP, TweetDeck, Facebook-klienter, Boks (http://www.intheboks.com), m.m..
Sånn helt på tampen, burde SIKKERHET vært et eget kapittel her. Det er i dag altfor liten fokus på sikkerhet, vi som jobber i denne industrien har et enormt ansvar for å sikre at vi selv har nok kompetanse på hvordan gjøre at løsningene blir sikre. Flere hundre tusen av datamaskiner er til enhver tid under kontroll av individer med negative hensikter, viktig at vi tar det veldig seriøst.
Tror fremtidens nettjenester blir rike og interaktive og vil få egne identiteter på grensesnittet. I dag har de fleste websider samme mønster for oppbyggingen, men med Adobe AIR, Silverlight og HTML 5 vil vi få helt nye og egne opplevelser.
Kanskje langt meir grunnleggande og opplagt enn dine punkt, men eg møter og til stadigheit folk som ikkje har høyrd om dei ulike HTTP-headerane og ikkje veit kva dei innebærer. Om eg skulle lagt til noko i lista di må det bli det: Grunnleggande kunnskap om HTTP-protokollen. Det er tross alt den som får alt til å henge saman.
Ein annan ting er bruk av klientside utviklarverktøy som Firebug (eller Dragonfly eller IE sine Dev tools om du er sær) ser eg òg mange som ikkje brukar aktivt.
Et par tanker om hva jeg mener nettutviklere bør kunne, minst:
1) HTTP-Protokollen
2) Cacheløsninger a-la Squid/Varnish, kan man ikke #1 kan man glemme dette dog. Rett konfiguert kan man fjerne 90%++ av trafikken mot webserveren bak.
3) SQL – Dumt å lære seg bare rene rammeverk den dagen man faktisk må skrive en real spørring…
4) Utviklerverktøy, som nevnt er Firebug herrlig 🙂
5) Sunn fornuft(!) Er mye rart der ute av løsninger i dag.
6) Grunnleggende Linux, mye av tjenester hostes i dag på Linux løsninger. Det er da greit å vite når applikasjonen bruker for mye minne, og dermed slugger ned hele løsningen.
..En liten start 🙂
Tja. Jeg tror vel nesten man har tatt med for mye av det som ikke er så viktig før du lager noe svært. Hvis du kan lage gode applikasjoner i f.eks. Rails eller Django kommer man veldig langt, kan du bittelitt databaseoptimisering og en dæsj caching i begge ender så kommer du enda lenger. Hoster du appen din på noe som ikke er gammalt ræl, for eksempel en virtuell kontainer hos Joyent eller MediaTemple, skal det veldig mye til før man trenger å tenkte på queuing (som man ikke akkurat trenger å gjøre mer komplisert enn å splitte appen sin i to biter) eller bli med i NoSQL-bevegelsen.
Jeg tror det viktigste for moderne nettutviklere er å kunne det som gagner brukerne: Kunne prosjektstyring, også når man er alene, grensesnitt, lage brukerhistorier, ha en spesifikasjon som er testbar, og så videre. Se litt om en prosess her: martinaspeli.net/articles/distributed-agile/
Så lenge mer minne og større server er billigere enn din egen tid skal det veldig mye til før man trenger å kaste seg inn i heftig vertikal skalering. Og hvis man trenger det, er nettet stappfullt av muligheter, sånn som her: djangoadvent.com/1.2/scaling-django/
Tja, der jeg jobber er fokusteknologiene i 2010 fortsatt Spring, JSP, Hibernate og Oracle, akkurat som de var i 2009, og 2008, og 2007, og etc. jQuery begynner omsider å bli stuerent når de stakkars utviklerne av og til er nødt til å ta i noe som ikke er Java (selv om de drømmer om å kunne bruke GWT istedenfor og omgås alt det der vanskelige Javascript-tullet), men utover det ser det ikke akkurat ut som om det blir en teknologisk revolusjon med det første. Ellers på jobbmarkedet virker det som om det ser omtrent likedan ut – man kan bytte ut Java med .NET og Oracle med MSSQL, men det er bare nyanseforskjeller.
Så det jeg lurer på er hvor jobbmarkedet finnes for denne moderne webutvikleren? Eller er det bare utopisk å tro at ny teknologi blir relevant før om ti års tid når de som legger føringene for dagens enterprise-utvikling har dødd ut?
Hilsen desillusjonert moderne webutvikler 😛
Enig med Arve Systad, en god forståelse av HTTP-protokollen er viktig. Kunnskap om de viktigste verbene GET, POST, PUT og DELETE, og hvordan man skal bruke disse, ulike headere, samt et og annet om URI-design bør også være et krav nå som REST-APIer og web services er i vinden som aldri før. Ellers en flott artikkel Henrik!
Varnish med ESI er definitivt en av de store tingene for året som kommer – og det kan utnyttes på langt flere måter enn det de fleste gjør i dag.
Jeg tror også vi kommer til å se et enda større fokus på søk og operasjoner rundt søk, og programvare slik som Solr og Sphinx – du bør vite hvordan dokumentsøk fungerer (dette henger seg fint sammen med NoSQL-applikasjoner som Cassandra og lignende).
Sondre: Haha, takk for påminninga om Cloud-computing – i NRKbeta har vi drabba borti det i eit par år, så den klarte eg å hoppe rett over.
“Claims based authentication” var heilt nytt for meg fram til no, men det kan sjå ut for å vere MS sitt svar på oAuth, stemmer det? Og “Internet Service Bus” blir da utveksling av informasjon mellom to parter via ein tredjepart, som f.eks. ved XMPP?
Arve: Definitivt, god forståelse for HTTP-protokollen er eit must, men det ser eg på som ganske obligatorisk om du skal jobbe mykje med nettet. Du har likevel heilt rett!
Tor Henning: Enig i alt. 🙂
Christoffer: Til private prosjekter: Sjølvsagt, heilt enig. Eg meiner likevel at det er viktig å holde seg oppdatert på “det nye”, då ein plutseleg kan komme over eit prosjekt der det kan være fordelaktig. Som eit eksempel held vi no på med å migrere ganske enorme mengder statistikk frå BitTorrent-prosjektet vårt over til MongoDB. Vi har ingen nytte av datarelasjoner direkte i SQL-databasen likevel, så når eit kjappare alternativ med enkel støtte for å generere aggregert data via MapReduce er på tilgjengelig, ser vi på det som ganske fordelaktig for oss.
Internet Service Bus handler om at man aktivt åpner en (TCP-)kanal ut fra det interne nettverket opp til en ekstern leverandør (f.eks. Microsoft), som en «relaying-party» mellom deg og en eventuell partner. BizTalk Server som har en kanal bygget på Windows Communication Foundation, støtter ISP på Windows Azure out-of-the-box. Trengs kun en liten konfigurasjon, og vips har man en tjeneste eksponert på nettet med sikkerhet og alt mulig.
Mer detaljert informasjon: msdn.microsoft.com/en-us/architecture/bb906065.aspx
Burde vel egentlig sagt Claims Based Identity & Access. Er ikke noe som er revolusjonerende nytt, men det begynner å bli aktuelt for mange å bruke: infoq.com/news/2009/10/Guide-Claim-Based-Identity. Active Directory Federation Services 2.0 tillatter at to organisasjoner kan etablere «trust» mellom sine Active Directory uten at man trenger å synkronisere kontoer mellom hverandre, og deretter gjøre ressurser tilgjengelig for eksterne. Samme teknologi kan benyttes i egne webløsninger for rask og enkel integrasjon mellom en web-applikasjon og en ekstern STS (Secure Token Service) – f.eks. en OpenID leverandør eller Windows Live ID. Claims Based Identity & Access vil redusere sikkerhetsproblemer med passord-lekasjer, da man «outsourcer» autentifiseringen.
Forståelse for HTTP er viktig, men det er også slik at man kommer veldig langt uten. Det kommer stadig nye abstraksjoner som fjerner detaljene fra protokollene og gjør det mindre viktig å kunne standardene. Det er mulig å gjøre XML-RPC i dag uten å engang vite hva XML er. Hva med WSDL, XML Schema, AJAX, WS-* m.m. som gjøres av utviklere i dag uten at man trenger å forstå detaljene.
Som Bodil nevner, det er Java og .NET som er regjerende mestere i markedet for utviklere av alle former, også på web. Er flere mer «eksotiske» alternativer for web som brukes i utstrakt grad, men i større prosjekter er det ofte vanskelig å få aksept for mindre etablerte plattformer og teknologier.
Henrik: Jeg mente absolutt ikke bare til private prosjekter, men jeg ser hva du mener. Hva du trenger har nok til slutt også mer med datamengde enn trafikkmengde å gjøre.
Produkter og rammeverk kommer og går, så for meg blir den grunnleggende kunnskapen om være seg HTTP, CSS, HTML, Javascript, SQL, modellering, arkitektur, cacheing, drifts/serverkunnskap etc det viktigste.
Utviklere som klarer å lage enkle løsninger, som unngår kompliserende ledd inntil det trengs, som kjenner både fordeler og ulemper ved rammeverk, programmeringsspråk og teknologiene, tror jeg er de som er best rustet for fremtiden.
Interessant blogpost, Henrik!
Du skriver om HTML5 på slutten av posten, men jeg savnet noen ord om grunnleggende HTML og CSS. Min erfaring er at det ikke er noen selvfølge at en utvikler kan HTML og CSS. Men da er de kanskje ikke nettutviklere?
Andre nevner heldigvis HTML og CSS i sin kommentar 😉
Christoffer: Det er også eit interessant skilje. I (veldig) mange sammenhenger er det datamengda som dikterer ressurskravene, men du har óg eksempel som det eg nevnte i posten rundt meldingssystemer (kva om registreringsskjemaet ditt blir truffen av Digg osv).
memcached er óg eit tilfelle kor det går meir på trafikkmengde enn datamengde.
Men i vårt tilfelle, som har med lagring av statistisk data å gjere, er det sjølvsagt datamengda som gjer at vi må sjå oss rundt etter alternativer.
Andre: Det siste avsnittet ditt er gull verdt, ingen tvil om. 🙂
Ang. det første avsnittet, så er det supert å kunne teorien rundt teknologiane som vi bader i, men det er vel så viktig å kunne utvikle eit produkt basert på denne teknologien. Og det er vel meir det denne posten handler om, produkta som bygger på den basiskunnskapen vi allereie har.
Martin: Heilt enig, beklager, eg burde nok utbrodert litt meir om generell forståing for HTML og CSS.
Det viktigste en webutvikler bør tenke på, er å bruke kode fra open source-biblioteker om mulig. I dag finnes det så mye ferdiglaget der ute, som ofte er gjennomtestet for bugs.
Man kan starte med å ALDRI skrive ut XML via print-setninger. Bruk et bibliotek. Det er faktisk vanskeligere enn man tror å skrive gyldig XML, om man ikke har fullstendig kontroll over dataene (og selv da er det mange feller man kan gå i)
Fix: «Symphony» til «Symfony» i teksten.
Takk, Anton. 🙂
@Bodil «Tja, der jeg jobber er fokusteknologiene i 2010 fortsatt Spring, JSP, Hibernate og Oracle»
Men dette er APPLIKASJONs-rammeverk og -teknologier, hvor Spring og JSP bare gir web-grensesnitt ned til den egentlige forretningslogikken.
Jeg mener det går an å lage web-applikasjoner med mye enklere verktøy enn du må bruke.
Jeg stusser over at du fremholder rammeverk fremfor de underliggende teknologiene. Jeg henger meg spesielt opp i at du oppfordrer utviklere til å lære seg jQuery fremfor å oppfordre folk til å lære seg JavaScript.
En «moderne» webutvikler bør beherske sine teknologier godt nok til at han ikke har noe problem med å til enhver tid vurdere hvorvidt det i det hele tatt bør brukes et rammeverk, og i så fall hvilket. En god JavaScript-programmerer vil ikke ha noen problemer med å sette seg inn i et gitt rammeverk, selv ikke ett med et så lite konsistent API som jQuerys, dersom det skulle være nødvendig. En god «jQuery-utvikler» vil ha problemer med å gå andre veien. Samme gjelder andre tilsvarende situasjoner.
Å bruke en teknologi fordi mange bruker det syns jeg også er skummelt. WordPress er et godt eksempel – her sier du jo selv at koden er langt fra imponerende. Det samme vil du nok oppdage at gjelder mange deler av de store JavaScript-rammeverkene om du setter deg ned og leser litt.
Hvis man går for å lære seg et rammeverk heller enn de underliggende teknologiene, hvordan skal man da løse problemene som før eller siden dukker opp? Melde bug og vente til noen andre fikser det?
Enig med Christian.
Det aller, aller viktigste en nettutvikler bør kunne, er å utvikle. Kjennskap til rammeverk o.l. kommer i andre rekke.
Jeg vil kanskje si at også underliggende plattformer kommer i andre rekke. Dvs. at det ikke bare er feil å legge vekt på jQuery, men i en viss grad også feil å legge vekt på kjennskap til akkurat JavaScript. Det er viktigere å skjønne de generelle programmeringsteknikkene som ligger til grunn, men det har jeg inntrykk av at mange ikke gjør.
Om det er noe problem med nettuvikling i dag, er det kanskje at for mange utviklere ikke først og fremst er utviklere, men rammeverkkjennere. Det hjelper lite å ha en fet og kul plattform om koden din er på trynet.
Både enig og uenig. Enig, fordi gode programmeringskunnskaper selvsagt er viktig basis. Uenig fordi det å programmere JavaScript på klienten er en egen disiplin som du ikke nøvdvendigvis er god i selv om du ellers er en god programmerer. Her var jeg litt upresis; jeg burde nok heller sakket om «browserscripting», ettersom det er det som er det store poenget: Å kode for en web der hvem som helst kan besøke siten din med hva som helst av browsere osv krever innsikt i hvordan browserne er forskjellige, hvordan man kan håndtere forskjeller, og hvordan man på best mulig måte kan utnytte mulighetene som er tilstede.
Å lære seg et «cross browser JavaScript library» ala jQuery er ingen unnskyldning for ikke å kunne noe om disse tingene, ettersom rammeverkene også har sine egne problemer.
Gjævt å sjå slike artiklar på NRK Beta. Men eg lurer på om han er skrivi av ein som elles nyttar bokmål. «Einkvar» (eigl. «einkvan») betyr «ein og annan,» ikkje «enhver.» «Sidevisning» tyder at sida skrumpar, ikkje at ho visast fram (vising). «Sannsynet» er ein smule arkaisk og dei fleste vil nok seia «sjansen.» «Byrjer» skal vera «byrjar,» «teknologier» bli «teknologiar» og så vidare. Ein del av ordlegginga er typisk bokmål: «Eit godt eksempel på dette er registreringsprosessen som dei fleste nettsider har. Scenarioet er vanlegvis som følgjer:»; som bør vera: «Eit godt døme på dette er registreringsprosessen (ev. registreringa) hos dei fleste nettstader. Det som ofte skjer er:»
Ikkje for å vera ein drittsekk. Web 2.0-hackarar har betre ting å gjera enn å bale med språk. Med mindre det er dataspråk. (Go Perl!)
«Visest» (som det vel heter i presens?) for «vert/blir vist fram» er vel også ganske bokmålsk?
Annet som er glemt her: computer science.