Hvilke teknologier ligger bak avanserte nettsteder?

[Digitalsitron]

@Wonko

Hva jeg vil få ut av prosjektet:

Jeg er en entrepenør av hjerte og vil forsøke å realisere mine egne ideer etter hvert. Samtidig ønsker jeg å ha noe jeg kan vise til en potensiell arbeidsgiver om jeg skulle legge entreprenørskap på hylla og søke jobb.

 

Målet for prosjektet:

Få kunnskap til å kunne utvikle et webprosjekt fra start til slutt og på (optimalt) alle nivåer.

 

Mitt nåværende nivå:

Data interessert siden bareneskolen, programmert siden ungdomskolen (C++). Fikk A i OO-programmering. Kan sette opp f.eks en LAMP stack, men har lite erfaring med programmering mot web.

 

 

@Knaill Takker for bra side. Ser at KS kjøprer nginx, tar en ekstra titt på det.

 

@Terrasque @Bolson Jeg er helt enig, For meg som er "helt blank" på si side leter jeg etter en teknologi å starte med for å kunne bruke konseptene. Jeg håper å kunne starte med en teknologi som er.

1) Framtidsrettet

2) Attraktiv for arbeidslivet (Helst økende etterspørsel)

3) Effektiv

For hver av de ulike konseptene/nivåene som dukker opp innen webutvikling.

 

@Ice Konge første avsnitt! Printa det ut og hang det på tavla.

Synes du Node.js/mongoDB/nginx ville være en bra stack å lære om du hadde startet på nytt?

 

 

EDIT: Bra kurs om Node.js?

Endret 4. oktober 2012 av Digitalsitron

[siDDis]

Til dei som anbefaler NoSQL, har dykk tenkt over kvifor disse databasane er så mykje kjappare enn ein standard relasjons database.

 

Det er ikkje fordi dei har enklare modell, men fordi dei skriver til disk når det passer for dei. Har du eit straumbrot, og vips så har du mista data for dei siste 5-15 minutta....

 

I 2010 så var PostgreSQL kjappare enn Redis for rein key-value lagring.

 

For å besvare trådstarter sitt spørsmål om skalering. så er det ikkje bare valet av teknologi, men og valet av arkitektur som bestemmer skaleringa. Faktisk vil eg påstå av valet av arkitektur er mykje viktigare enn teknologi.

[Millmax]

Det kan være fristende å se til hva store internasjonale nettsteder benytter for super-skalerbare applikasjoner. Det aller meste blir litt irrelevant for de fleste programvareutviklere i Norge. Jeg jobber som utvikler i et konsulentselskap med et par hundre ansatte, utviklerne våre er grovt delt i to: .NET og Java. I tillegg har vi noen innen mobile enheter og bittelitt innen andre teknologier. Om du lurer på hva som gjelder innen de mest avanserte _norske_ nettstedene kan du for eksempel ta en titt på arkitekturen bak Altinn / Altinn2: Der er det .NET, Sharepoint, Episerver og InfoPath som er de mest dominerende produktene. I tillegg kommer OpenSSO, F5 og SQL Server

 

Se spesielt sliden for produkter i løsningen, side 22:

http://opentheweb.org/L1_Arkitektur%20-%20Wilfred%20Oestgulen.pdf

 

Andre slides:

http://www.brreg.no/kurs/altinndag11/B1_Arkitektur,_funksjonalitet_og_kommende_godbiter.pdf

http://www.brreg.no/kurs/altinndag09/L1_Loesningsarkitektur_Oestgulen.pdf

http://www.nettavisen.no/multimedia/na/archive/00986/altinn_sluttrapport_986204a.pdf

 

Så tilbake til hverdagen som programvareutvikler: svært mange av våre prosjekter kjøres nå på .NET, spesielt de nye prosjektene som vi vinner. Lærer du deg .NET grundig, gjerne kombinert med WCF, kanskje med EpiServer og / elller SharePoint har du kompetanse som gjør at hodejegerne ringer deg flere ganger _hver dag_. Selv om .NET ikke er veldig kult i hipsternes verden, er det der jobbene ligger, både i dag og i morgen.

[torbjørn marø]

Til dei som anbefaler NoSQL, har dykk tenkt over kvifor disse databasane er så mykje kjappare enn ein standard relasjons database.

 

Det er ikkje fordi dei har enklare modell, men fordi dei skriver til disk når det passer for dei. Har du eit straumbrot, og vips så har du mista data for dei siste 5-15 minutta....

 

NoSQL er en bestegnelse brukt om en hel rekke alterantiver til å bare benytte klassiske relasjonsdatabaser. Du kan ikke skjære alle over én kam i forhold til noe som helst - de har alle ting de er ulike på. Bruker selv MongoDB, og skriver data direkte til disk.

[GeirGrusom]

Til dei som anbefaler NoSQL, har dykk tenkt over kvifor disse databasane er så mykje kjappare enn ein standard relasjons database.

 

Det er ikkje fordi dei har enklare modell, men fordi dei skriver til disk når det passer for dei. Har du eit straumbrot, og vips så har du mista data for dei siste 5-15 minutta....

 

I 2010 så var PostgreSQL kjappare enn Redis for rein key-value lagring.

Det kommer vel fullstendig an på implementasjonen. Du må alltid tilpasse databasevalg til kravet ditt, og ikke bruke hverken objektdatabaser eller relasjonsdatabaser ukritisk. For meg virker det som sistnevnte er svært vanlig.

[siDDis]

Altinn er basert på å kaste tusenvis av millioner med kroner for å få det til å skalere. Valet av løysninger er basert på produkter som kostar altfor mykje i forhald til det dei leverer.

 

London Stock Exchange gjekk på den smellen også, men har nå i ettertid bytta Microsoft og produkt ditt og datt til sitt eige system + Oracle.

 

Skal du skalere, så må du også kjenne operativsystemet. For du må tilpasse den biten også, enten ved å lage nye moduler eller skrive om eksisterande moduler. Og på det området er Microsoft løysninger svært svake.

 

Så har du planer om å lage noko gigantisk, så ikkje velg Microsoft og ein haug med andre propritære produkter. For du har troleg rett og slett ikkje budsjett til å få det til å skalere på same måte som du får med eit nix basert system.

 

Derimot skal du ha deg ein jobb, så er det nok med C#/.Net stillingar for dei som er usikker på kva dei skal velja. Og det er garantert eit betre val enn å jobbe hos nokon som brukar PHP.

[siDDis]

NoSQL er en bestegnelse brukt om en hel rekke alterantiver til å bare benytte klassiske relasjonsdatabaser. Du kan ikke skjære alle over én kam i forhold til noe som helst - de har alle ting de er ulike på. Bruker selv MongoDB, og skriver data direkte til disk.

 

Jo! Hovedproblem nummer 1 er løgn og fanteri for å vise til tåpelege benchmarks.

 

Kvifor velje du MongoDB istadenfor ein RDBMS? Fordi det er nytt, fancy og blir lovprisa av mange andre? Amatørene som prøver MongoDB lovpriser det fordi det er så enkelt og har ein så rå ytelse, men dei gidder ikkje å sjekke at default innstillingane er COMMIT TO DISK WHEN MONGODB FEEL FOR IT.

Tar du på safe mode så går ytelsen så mykje ned at ja, SQLite er eit raskare alternativ.

 

MongoDB er såpass nytt, utvikla av nokon som prøver å finne opp hjulet på nytt(fordi dei kan) og stinker BETA database i lange baner, akkurat som resten av NOSQL løysningane som Cassandra, Redis osv. Foursquare droppa MongoDB og gjekk over til RDBMS til slutt, rett og slett fordi hypen ikkje holdt mål.

 

Når det gjelder valet av key-value databaser, så er det noko eg har brukt mykje tid på å analysere i det siste. Sannheita er, utruleg nok...verken BerkelyDB, JDBM3, Tokyo Cabinet, Redi, Cassandra er gode nok alternativer når ein trenger både moglegheiter til replikering og konsistent data. Faktisk så er PostgreSQL den beste ikkje propritære løysninga for rein key value database, ijallefall den eg har funne til nå.

[tomsi42]

Derimot skal du ha deg ein jobb, så er det nok med C#/.Net stillingar for dei som er usikker på kva dei skal velja. Og det er garantert eit betre val enn å jobbe hos nokon som brukar PHP.

 

Det vel C#/.Net og Java EE som er det tryggeste å velge for tiden. Men er det det den morsomste teknologien å jobbe med?

[GeirGrusom]

Det vel C#/.Net og Java EE som er det tryggeste å velge for tiden. Men er det det den morsomste teknologien å jobbe med?

 

C# er da et ganske artig språk ihvertfall, men det er ikke plattformen det kommer an på, men hva du jobber med. Personlig synes jeg web generelt er triste greier. Jeg liker lett å holde meg i bakgrunnen så jeg slipper å røre borti det makkverket der.

[siDDis]

Veldig einig med GeirGrusom, web med C#/.Net er triste greier, ellers synes eg det er ganske greit verktøy å lage ting. Enkle skrivebordsapplikasjoner er superproduktivt med Visual Studio også er det veldig trivielt å benytte seg av windows apiet.

[Gjest Slettet-Pqy3rC]

Vi gjør alt det vesentlige i C++.

 

Datatravel;

UI makkverk <-> Services (C++) <-> Datastores (SQL's).

 

Web sidene (eller anne UI) når aldri databasen(e) direkte. Så JQuery og denslags blir aldri brukt, det går via XML utveksling (WebServices etc). Sånn sett er en relativt skjermet for alle UI teknoligiene som popper opp som paddehatter, all "business logic" blir gjort av tjenesten(e) i midten.

[Terrasque]

Siden man er i gang med den vanlige teknologi "diskusjonen", og folk diskuterer SQL og NoSQL så fjæra fyk..

 

 

Edit:

Web sidene (eller anne UI) når aldri databasen(e) direkte. Så JQuery og denslags blir aldri brukt

 

Skal ærlig inrømme at jeg ikke helt ser den koblingen....

 

Edit2: Chart hentet herfra

Endret 5. oktober 2012 av Terrasque

[siDDis]

Den tegningen er jo bare tull. Feks Redis er ein av dei verste når det kjem til Consistency, men ytelsen er enorm. Og PostgreSQL kan fint benytte seg av P'en for å distribuere data i små shards http://instagram-eng...ds-at-instagram

[Gjest Slettet-Pqy3rC]

Edit:

Web sidene (eller anne UI) når aldri databasen(e) direkte. Så JQuery og denslags blir aldri brukt

Skal ærlig inrømme at jeg ikke helt ser den koblingen....

Ikke jeg heller (!?). Jeg mente å skrive et-eller-annet om bindinger mellom data og brukergrensnitt, men husker ikke lenger hva poenget var.

[asicman]

Hvilke teknologier ligger bak avanserte nettsteder i dag?

 

Jeg studerer informasjonsteknologi på andre året og leker med tanken om å starte ett litt mer utfordreren prosjekt som tar i bruk teknologien bak morgendagens avanserte nettsteder. Fra før kan jeg programmere i Python, Java, C++.

 

 

Hvis foremålet er å lære om mer avanserte teknologier så ville jeg sett på Weblocks. Online spillet Thanandar er skrevet i Weblocks.

 

 

Jeg ser mange her argumenterer for eller i mot NoSQL/RDBMS. I weblocks og Common Lisp så jobber man med objekter akkurat som objektene i språket. Hvordan objektene blir persistente kan man velge. Om man ønsker å migrere til en annen back-end senere så kan man gjøre det med ingen eller minimale kode endringer.

 

 

Man definerer bare et object på samme måte som man gjør i Common Lisp.

 

Hvis jeg skal lage et object som inneholder URL'er så spesiefiserer jeg det på samme måte som jeg definerer klasser i Common Lisp, men i stedet for defclass så bruker jeg defpclass («p» for persistent):

 

(defpclass url ()
 ((acctime  :accessor acctime	:initarg :acctime  :initform (get-universal-time))
  (refcount :accessor refcount   :initarg :refcount :initform 0)
  (name	 :accessor name	   :initarg :name)
  (url	  :accessor url		:initarg :url)))

 

Et annet sted så spesifiserer jeg hvordan dataene skal lages, f.eks. med Elephant som igjen kan ligge over en Berkeley DB:

 

(defstore *url-store* :elephant
 :spec (list :bdb *home-database-pathname*))

 

Eller jeg kan bruke PostgreSQL til å lagre de samme objektene:

 

(defstore *url-store* :clsql '("server" "db" "user" "pass")
  :database-type :postgresql)

 

Det er mange forskjellige back-end metoder, cl-prevalence, CLSQL (som igjen kan bruke Oracle, PostgreSQL, MySQL, SQLite, ODBC, osv.) PostgreSQL, (er usikker på om noen har brukt AllegroCache fra Franz), osv. Skal man bare ha performance og har nok memory kan man t.o.m. bruke:

 

(defstore *scratch-store* :memory)

 

Måten man skriver koden som bruker objektene på er den samme. Skal man vise dataene som en tabell som skal sorteres, redigeres osv. definerer man et view over dataene:

 

(defview url-table-view (:type table :inherit-from '(:scaffold url))
 (view-database :hidep t)
 (id :hidep t))

 

Dersom man ønsker spesiell rendring av objektene kan man definere widgets som beskriver hvordan disse skal tegnes:

 

(defwidget url-list (widget)
 ((data-class :accessor url-list-data-class
		   :initform 'url
		   :initarg :data-class
		   :documentation "The class name of the objects rendered
	   by this url-list. It's assumed to have the slots url and name")))

 

Videre kan man beskrive hvordan bestemte typer i klassene skal vises eller hvordan input skal sjekkes/parses.

 

Siden det er skrevet i Common Lisp kan man ha server programmet kjørende og så koble seg på processen og kompilere inn nye funksjoner (med f.eks. SLIME) og definere nye klasser osv. uten å stoppe programmet. Man kan inspisiere og debugge med data lagt igjen av web brukere osv.

 

Dette er etter min mening et utrolig fleksibelt og bra rammeverk, men ulempen er at det ikke er mye brukt og at dokumentasjonen er ikke av de mest utfyllende.

[wonko]

Håper det går greit jeg ignorerer hovedspørsmålet ditt (om teknologi) og heller prøver å gi litt generelle råd. Hvis det ikke er interessant må du bare si fra

Målet ditt ("Få kunnskap til å kunne utvikle et webprosjekt fra start til slutt og på (optimalt) alle nivåer.") er ganske ambisiøst - kanskje mer enn du tror, og det kan være lurt å ta et skritt tilbake og se hva som inngår i dette.

 

Sånn jeg ser det er dette hoveddelene av et webprosjekt (i tilfeldig rekkefølge):

1) Serverdrift/arkitektur - installasjon og drift av teknologistacken, skalering (proxy, caching osv.).

2) Design - idéutvikling, problemanalyse, planlegging og brukeropplevelse/UX

3) Implementasjon - programmere backend og frontend, persistering (database) osv.

 

Man synes ofte ikke alle delene er like morsomme, og var jeg deg ville jeg fokusert på det jeg syns var morsomst for å holde motivasjonen oppe. Kanskje du kan få noen til å hjelpe deg med de delene du ikke er så interessert i, så har du muligheten til å lære litt om samarbeid og prosjektstyring i samme slengen

 

Du ser ut til å ha begynt med del 1, men som mange nå har nevnt er kanskje delen jeg har kalt "design" et mer naturlig sted å begynne. Når det gjelder valg av teknologistack er det sikkert både moro og nyttig å lære litt om hva som blir brukt av de store, men når du kommer til del 3 - implementasjonen - tror jeg ikke nødvendigvis det mest framtidsrettede er å sette igang med de nyeste, hotteste rammeverkene. Jeg ville heller, som sagt, begynt med noe som gir så lite hjelp/magi som mulig for å lære grunn-konseptene (nettverksteknologi, server-klient-modellen, http, webservere og front-end teknologi (javascript))

 

Jeg ser node.js er nevnt - dette har jeg aldri brukt selv, men jeg har skjønt det er et veldig enkelt rammeverk for å lage serverprogrammer i javascript, og er jo veldig i vinden for tida. Dette høres igrunnen ut som et veldig bra startsted - du lærer deg javascript samtidig som du kan begynne helt på bunnen med å lage en enkel http-server og slukke tørsten din for hipster-teknologi +1 for node!

[Terrasque]

node.js er mer som server delen i en asynkron (event basert) klient/server løsning. Vil si det er litt spesiell i forhold til tradisjonell web programmering.

 

Veldig enkelt eksempel node.js program:

 

var http = require('http');
http.createServer(function (req, res) {
 res.writeHead(200, {'Content-Type': 'text/plain'});
 res.end('Hello World\n');
}).listen(1337, "127.0.0.1");
console.log('Server running at http://127.0.0.1:1337/');

 

Forøvrig er JavaScript et ... interessant språk.

[asicman]

Forøvrig er JavaScript et ... interessant språk.

 

Er det closures du mener er spesielt interessant siden du linker til den siden?

[Terrasque]

Blant annet. Syns det viser mye om JS på en god måte. Man kan få til det meste, men ting gjøres gjerne litt annerledes enn i andre språk.

[asicman]

Men i så måte er ikke Javascript så forskjellig fra gamle travere som Lisp/Scheme.