Gå til innhold
Presidentvalget i USA 2024 ×

Hvilke teknologier ligger bak avanserte nettsteder?


Anbefalte innlegg

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++.

 

Jeg håper at noen mer erfarne utviklere kan si noe om hvilke teknologier som vil fortsette å være standard og hvilke nye verktøy som vil bli store i årene framover.

 

F.eks:

Facebook sine teknologier:

 

Linux m/SQL og Apache

PHP

Memcache

Cassandra

 

Med Python, Java og C++ som største programmeringsspråk

 

Er dette en set-up dere ville brukt dag? Hvilke teknologier er verdt å lære?

 

 

Kickstarter.com

En annen side jeg synes har en interessant oppbygning er kickstarter.com. Her har jeg ikke klart å finne hvilke plattformer som ligger bak. Er det noen som kan gjette seg fram til og forklare hvordan en slik side blir bygd?(Gjerne fra grunnen av.)

 

Til slutt håper jeg noen kan fortelle meg sammenhengen mellom programmeringsspråk (f.eks ruby on rails) og selve databehandlingen. Hvordan kobles og programmeres disse mot hverandre?

Lenke til kommentar
Videoannonse
Annonse

@Digitalsitron:

 

Du begynner med feil utgangspunkt, nemlig at skaperene bak morgendagens "avanserte" nettsteder har teknologifokus. Det er feil, hverken Twitter, Facebook, YouTube eller Kickstarter er teknologifokuserte. De var idefokuserte - dvs at det var et produkt/en tjeneste som de hadde utrolig stor tro på. Hvilke programmeringsspråk de startet opp med er nesten tilfeldig, og trolig mer grunnet kompetansen tilgjengelig i starten enn vurdering av hvilken teknologi som er best.

 

Derfor ender disse med utrolig mye spesielle tilpasninger og bruk av en miks av teknologier.

 

 

Du glemte f.eks at Facebook bruker Varnish, samme gjør Twitter.

 

Så i realiteten betyr ikke selve teknologivalget så mye.

 

Denne figuren som beskriver grunnloggikken på et av de mest avanserte Enterprise CMS-er forteller litt om strukturen i en avansert nettløsning.

 

post-26625-0-61603600-1349117324_thumb.png

 

Dog er det her ikke med lastbalansering, cache etc. Om man bruker SQL, NoSQL eller repository teknologi (http://en.wikipedia.org/wiki/Content_repository_API_for_Java) er ikke viktig, men @etse har helt rett i at NoSQL er i utstrakt bruk ved store datamengder hvor man i realiteten bare lagrer dataene pga ytelse.

 

Repository teknologi (finnes også for PHP, https://github.com/phpcr/phpcr#readme). Repository teknologi er egentlig et objektbasert lag over selve lagringen, og man kan egentlig lagre dataene som flatfil, json, SQL, NoSQL etc bak.

  • Liker 4
Lenke til kommentar

@Bolson Jeg er totalt klar over at det er sidens ide, ikke teknologien bak som gjør siden bra eller ikke.

Dette prosjektet er for å lære meg de beste teknikkene og teknologiene slik at jeg kan bruke noe av teorien jeg lærer og kunne bygge en solid side om nå ideen skulle komme. :)

 

Takker for bra input, skal ta en titt på noSQL og har litt PHP kunnskaper jeg skal bygge opp.

 

Som programeringsspråk+rammeverk hva ville dere anbefale? Hva er "industristandaren" om 5år? Har oppfattet mye bra om Ruby on rails, lever det opp til hypen?

 

Ser på filmene nå @Terrasque @nostdal.org, good stuff.

Endret av Digitalsitron
Lenke til kommentar

@Digitalsitron: Ruby on Rails lever etter min mening ikke opp til hypen.

 

Mitt poeng var at når ulike suksesser faktisk bygger på så ulike valg av teknologi, vi har nesten hvert eneste større språk/rammeverk med, så er det i realiteten vanskelig å definere noe som de beste teknologiene og teknikkene. "It depends" som så mange sier. Derfor er det kanskje bedre å får kunnskap på et overordnet nivå.

 

Personlig tror jeg ikke det vil være en spesifikk "industristandard" om 5 år. Jeg var med på det første større webrelaterte prosjektet i 1998 (en relativt stor portal) og har ennå ikke opplevd at noe har blitt reell "industristandard". Men hva som faktisk har endret seg mye er økt objektorientering, nye metoder (som MVC med flere), SCRUM, Agile utvikling, Unit testing osv. Samt større fokus på arkitektur og design, og ikke minst brukerfokus. Kunnskap som gjør at det faktisk ikke spiller så stor rolle hvilket rammeverk/språk man bruker - og som gjør det enklere i mange tilfeller å plukke det mest egna for gitt case.

 

Var faktisk borte i et prosjekt for ca et år siden hvor det er brukt Java, Ruby on Rails, PHP og Python, samt både NoSQL og SQL i samme prosjektet.

  • Liker 1
Lenke til kommentar

@Bolson Da forstår jeg deg bedre. Godt at du sier at kunnskap på et "overordnet" nivå er godt å ha i sekken. Det er nettopp dette jeg føler vi får her på DataTek NTNU.

 

Men gitt et case: Kickstarter.com vil denne siden kunne bli utviklet på en tilfeldig gitt plattform og kunne gi identisk brukeropplevelse? Vil utviklertiden ta like lang tid?

 

Om du selv skulle laget en liknende plattform som digg.com/kickstarter.com/etc.. Hva vil du med din bakgrunn ha lett etter av kunnskaper i en utvikler og hvilke teknologier ville ha blitt brukt?

 

Håper på at prosjektet skal kunne gi meg praktisk erfaring som gjør meg attraktiv hos en framtidig arbeidsgiver samtidig som det er artig og lærerikt. :)

Tenker på å lage en enklere versjon av twitter e.l.

Lenke til kommentar

For min del...

 

Twitter clone..

 

* Live updates

* Lagring av tweets

* Input av data fra brukere

 

Live updates

Her vil man gjerne ha mye javascript på klient siden, og tech på server siden som støtter høy concurrency

 

* JavaScript library er kjekt å bruke her, gjør ting lettere, og mer consistent over forskjellige browsere. Forslag : jQuery / Dojo

* Motta events fra server enten via Comet (f.eks ajax long polling) eller Websocket (fremdeles litt varierende støtte for det i browsere)

* Event based web service (eksempler: node.js / twisted / nginx)

* Message queue system for å sende ut nye events til alle delene av systemet. Eksempler: zeromq / rabbitmq

 

Lagring av tweets

Her hadde jeg kanskje gått for en nosql løsning, fordi jeg ikke trenger ACID nivå på ting og streng struktur så mye. Pluss caching for avlasting av cpu og database

* DB engine : Trolig mongodb eller couchdb

* Cache engine : memcache

 

En fordel med å bruke SQL her ville ha vært at det ville vært mye enklere å bytte database senere, da SQL variantene er ganske like hverandre, og en tynn layer imellom kan lett oversette ting. nosql databasene er mye mer forskjellig i struktur, og man binder seg mye mer til en løsning der.

 

Data input

Her hadde jeg sannsynligvis gått for en RESTful API basert løsning, som også web klienter hadde brukt via JavaScript :)

Den løsningen, sammen med en del fancy client cache triks, så kunne man hatt mye av html'en statisk. Og man har et ferdig og godt testet API for andre å bruke til å integrere med tjenesten.

  • Liker 1
Lenke til kommentar

@Digitalsitron:

 

Når det gjelder Kickstarter.com så kan den nok lages i omtrent det man vil. Konseptet er ikke så ekstremt avansert når det gjelder grunnleggende arkitektur. Det er i realiteten en mellomting mellom en rurbikkannonseløsning og nettbutikk. Men det er klart man må gøre grep for håndtere trafikk etc.

 

Personlig ville jeg heller sett på løsninger som BaseCamp, Toggle, Teamwork, Evernote etc, og kanskje finne en ny tjeneste innen dette feltet (eller bedre integrasjon). Har nemlig tro på at denne typen løsningsorienterte webapplikasjoner med klare behov for integrasjon (widgets, apps etc) har langt større potensiale enn vi ser i dag. Dette er også typisk Cloud Computing, hvor oppgaver som normalt kjøres på egen PC flyttes ut. Ja, jeg bruker mange av disse.

 

Så vil jeg ikke være så fokusert på kodebiten, koding lærer de fleste med grunnleggende kunnskap relativt fort. Jeg har kontor ved siden av en spansk jente, som for 5 mnd siden knapt hadde kodet PHP, men er utrolig god på generell metode og kodekunnskap (testing, logikk etc). Utdanning noe over ditt nivå. Ho er alt på nivå med folk som har kodet PHP i masser av år.

 

Tror du vil både lære mer av og bedre jobbsjanser om du prioriterer å lage overordna design/arkitektur for en "definert" løsing, og så som Terrasque viser, peke på hvilke løsningsvalg/teknologier som vil egne seg best for ulike deler. Selve kodinga er jo i realiteten "kurant". Det vi også kunne gi deg en meget god oversikt over teknologi, metode og løsningsvalg (samt styrker og svakheter). Du vil da også se at det ofte er mulig å bruke eksisterende løsninger/teknologi som basis (jf javascript rammeverk etc), og således kutte ned utviklingstid svært mye.

 

Personlig oppfatter jeg også ofte det som det store problemet, nemlig at altfor få er virkelig dyktige på den biten. Finnes mange svært gode kodere, men når den overordna designen er mangelfull, ja da blir det mye rart.

 

PS! Jeg er ikke utvikler i den forstand, jeg har primært jobbet med den overordna biten - dvs brukerbehov, overordna interaksjonsdesign, prosjektledelse osv.

  • Liker 1
Lenke til kommentar

Takker for utrolig gode og grundige svar.

 

@Terrasque jeg skal undersøke de løsningene du peker til og så skal du se det blir en twitterklone før jul. :)

Du vet ikke om noen gode læringsressurser som tar i bruk to eller flere av løsningene sammen?

 

@Bolson Du kommer inn på mange interessante tanker i din siste post. Jeg kunne også tenke meg å bli en software arkitekt og den "overordna" biten. Har du noen gode ressurser som lærer bort dette med dagens teknologier?

BaseCamp, Evernote og Spotify er spennende løsninger som jeg selv bruker. Hvordan vil du si at utviklingen av disse er forskjellig fra vanlige websider?

 

Hva tenker dere f.eks om: TreeHouse? Virker det solid?

Lenke til kommentar

Læringsressurser? Nei, egentlig ikke.. Divide and conquer! :p

 

Fokuser på hver enkelt en etter en, bare lag det absolutte minimum støttestruktur rundt for å teste den.

 

Vil kanskje anbefale JS -> JS ajax/dom (mot statiske filer) -> server part (node.js / twisted) -> database -> msg queue system

 

Et lite tips: JSON er veldig fin container format for å utveksle data mellom forskjellige systemer :)

 

Edit : Når jeg ser på tittelen... Det er ikke egentlig teknologier som er tingen, men konsepter.

Endret av Terrasque
  • Liker 1
Lenke til kommentar

Må si jeg synes det var veldig bra spørsmål og mange gode svar i denne tråden! Fra tid til annen henter jeg en del inspirasjon fra HighScalability.com. Der finner du masse informasjon om hvordan ulike nettjenester er bygget opp, og innimellom får man også noen tips om metoder som ikke fungerer like bra i praksis som i teorien. Etter min mening er denne lærdommen like interessant som mye annet :-)

 

Det finnes ikke noe fasitsvar på at én teknologi er overlegen en annen, eller at det er noe som vil bli industristandard de neste årene. Det finnes så mange løsninger på ett problem, og min erfaring er at det gjelder å ha kunnskap og erfaring med et utvalg av de ulike verktøyene uten å være religiøst bundet til ett spesifikt produkt.

 

Selv om PostgreSQL vs. MySQL-debatten ikke er den hotteste i dag illustrerer den etter min mening et viktig poeng. Personlig er jeg stor fan av PostgreSQL, mens vi i Mediehuset Tek har de aller fleste databasene våre i MySQL. I praksis er det få ting vi ikke klarer å løse i MySQL, og det er mye bedre at vi har god kunnskap om MySQLs styrker og svakheter, enn at fordeler kunnskapen på enda flere databaseteknologier.

 

Da er det bedre at vi heller fokuserer på ny kunnskap innen andre teknologiområder som caching (Varnish), key-value-stores (Cassandra) og søk (Solr).

  • Liker 3
Lenke til kommentar

@Terrasque Skal ta med tipsene dine videre. Spesielt tanken om konsepter over teknologier.

 

@amund Du kommer med mange bra svar selv. HighScalability.com er akkurat det jeg så etter.

Har trålet igjennom siden nå og undersøkt konsept for konsept for de største sidene, HS går i en utrolig detalj på flere av dem. (Eks Youtube)

Knallbra!

 

Om noen har forslag til effektiv trening, bøker, sider, etc for å lære seg webarkitektur eller konsepter, gjerne prosjektbasert, si i fra.

Endret av Digitalsitron
Lenke til kommentar

Siden du allerede kan Python så kan jo kanskje et Python rammeverk som bruker MVC-arkitektur være en idé? Et eksempel er Pyramid, tidligere kalt Pylons. Her brukes det et flott bibliotek kalt SQLAlchemy for models, mako for view og vanlig Python i controller. Pyramid gjør lite for deg á Django o.l., men legger en god basis. Et godt alternativ for database er PostgreSQL. For optimalisering o.l. så er det allerede gitt mye annen god info i tråden.

  • Liker 1
Lenke til kommentar

Mange bra svar her, men ser ikke at det er så mange sett fra en programmerers perspektiv, så tenkte prøve å bøte på det.

 

Men først: hva er målet med dette prosjektet ditt - hva vil du få ut av det? Hva tenker du du vil jobbe med etter utdanning? Programmerer, designer, entreprenør, konsulent eller hos bedrifter med et eksisterende produkt (som finn.no, opera e.l.)? Hvilket nivå er du på nå - hva kan du av webteknologier? (Hvilke språk er mindre viktig - du setter deg fort inn i et nytt språk, spesielt med teoretisk bakgrunn som f.eks. fra faget Programmeringsspråk på NTNU.)

 

Selv studerte jeg datateknikk ved NTNU, er nå relativt fersk som utvikler i et konsulentfirma og har jobbet på et par større og noen mindre web-prosjekter.

 

Som programmerer tror jeg det kan være veldig nyttig å lære ting fra bunnen og opp. Å ha en grunnleggende forståelse for hvordan web-teknologier generelt fungerer vil gjøre det mye enklere å lære seg de spesifikke rammeverkene seinere. Lær deg aller først hvordan nettverk-kommunikasjon foregår - spesielt HTTP og server/klient-modellen. Deretter foreslår jeg å eksperimentere litt med en enkel webserver, f.eks. https://github.com/elonen/nanohttpd og få denne til å serve en enkel, statisk webside, kanskje med noen forms, bilder o.l. Så kan du f.eks. gå videre til Sinatra, web.py, Scalatra, jax-rs, Spark e.l. "micro frameworks". JavaScript (og Ajax) tror jeg også er veldig viktig å lære seg - sjekk f.eks. ut mvc-rammeverk på http://addyosmani.github.com/todomvc/. Personlig tror jeg framtida er slike micro frameworks som gir en felles RESTful backend for JavaScript-tunge websider og mobil-apps, men dette er kun min relativt ukvalifiserte gjetning :p

 

Når det gjelder tunge, store web-prosjekter, spesielt i det offentlige har jeg inntrykk av at det går mye i Java, JSF, EJB, Hibernate o.l. For mindre prosjekter er det vel en del Rails-liknende rammeverk som Django, Play, Lift osv. Og selvfølgelig mange som bruker php enda...

Endret av wonko
  • Liker 2
Lenke til kommentar

Folk tenker litt for mye på teknologi biten enda, ser jeg..

 

La oss nå ta konseptet key-value store. Folk nevner kanskje memcache, eller cassandra, BigTable kanskje, eller MongoDB kanskje? Gjett hva YouTube, en av de største sidene på nettet bruker for key-value store? MySQL.

 

 

Det jeg ville frem til med det er at det er ikke selve teknologien som er avgjørende. Eneste plassen du er begrenset til en viss teknologi er på websider, der du må bruke html og javascript, fordi det er det browserene støtter.

 

Tror jeg skal komme med en brash uttalelse her å påstå at man *trenger* bare et språk som har nettverk og disk I/O. Det er alt man *trenger* for å lage hvilkensomhelst server tjeneste. Uansett skalering. Det *eneste* de forskjellige teknologiene (programmerings-språk, web server, database, frameworks, osv) gjør er å hjelpe deg å bruke ressursene du har tilgjengelig bedre. Hvis det jobber tregt, så lenge det er riktig designet så kan man bare hive mer hardware på det (Footnote: Vel, google ser ut til å møtt en praktisk limit over sin globale serverpark, men det er neppe noe problem for oss dødelige). Ressurser omfatter også tid og kunnskapsnivå. En DB server kutter ned på tiden og kunnskapen man må ha for å lagre og hente ut data effektivt, Web server, same. Forskjellige frameworks, same.

 

I et stort prosjekt med veldig varierende kvalitet på koderene kan Java (med sin strictness) være et utmerket valg for å utnytte kode-ressursene best mulig. I et lite enmanns prosjekt som sannsynligvis ikke blir noe stort, så er det vanlig å velge det som passer best med hvordan du tenker (ofte, så faller det sammen med hvilken tech du har brukt lengst).

 

Det er iallefall mitt synspunkt på teknologi fokuset. Og siden forskjellige prosjekter har forskjellige mål og ressurser, så tviler jeg på at man vil se en bestemt teknologi ta over.

Lenke til kommentar

Må si meg enig med de aller fleste her, tenk og planlegg først, skriv kode senere. Prøv alltid å holde ting så enkelt som mulig uten at det går ut over brukeropplevelsen. Brukeropplevelsen er alltid viktigst. Husk at du har to brukergrupper, den ene sitter i nettleseren mens den andre er utviklerne du jobber sammens med. Ikke lag noe som er unødvendig stort, komplisert og avansert, dette er din baby ikke la andre se det som et monster. Tenk alltid på målet, hva er det du ønsker å oppnå og for hvem.

 

Når det gjelder læring hør på wonko: lær deg det meste i fra bunnen og opp. Det kan faktisk være lurt å finne opp hjulet på nytt bare for å vite hvordan det fungerer. Da vet du også kanskje hvorfor bilen/babyen din sjangler når du kjører nedover vegen.

 

For meg virker det litt som om du prøver å starte i feil ende. Skalering er noe av det siste du trenger å lære. 99,99 % av alle verdens nettsteder har minimalt med trafikk og har ikke noe behov for cache. Fokuset på disse sidene er kvalitet og utviklingskost, altså hvor mye tid du bruker og ikke hvor mange brukere du klarer å presse inn i sekundet.

 

Lær deg HTML, CSS, Javascript(jQuery lib er nesten obligatorisk), viktige W3-standarder som WCAG og WAI-ARIA. Ingen ansetter noen fordi de er flink til å kode, man blir ansatt for den kunnskapen man har og evnen til å bruke denne for å lage et godt produkt(noe som brukerne liker og setter pris på).

 

TL;DR: Til private prosjekter nå benytter jeg meg av NodeJS med MongoDB og Nginx(med innebygd cache). Av den enkle grunnen at det er spennende, går kjapt å utvikle og det gjøre det mulig å lage både web- og mobilapps som er veldi rik på interaktivitet og samhandling.

  • Liker 1
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å
×
×
  • Opprett ny...