[Powered by Google Translate] [Seminar] [Web Development: Fra idé til gjennomføring] [Ben Kuhn] [Billy Janitsch] [Harvard University] [Dette er CS50] [CS50.TV] [Billy] Hei, jeg er Billy og dette er Ben. >> [Ben] Hei. Vi skal snakke om webutvikling i dag for å bli. [Webdev] [Billy Janitsch og Ben Kuhn] Litt om oss først. Ben er liksom den back-end fyr. Han gjør ting fungerer. Og så går jeg inn og gjøre dem pen. Jeg er i stor grad involvert med flere front-end layout design type ting, og Ben, derimot, vet hva han gjør, så han jobber på back-end ting. Sammen har vi gjort et par ting. For eksempel, i fjor jobbet vi på Gimblium som er en online spillutvikling studio. Det var vårt siste prosjekt for klassen, og siden da har vi gjort Harvard Class som er en online rammeverk for surfing og shopping kurs ved Harvard. 

Vi kommer til å starte med denne ideen for vår hjemmeside. Vi kommer til å lage Facebook, men for katter. Før du faktisk gjøre dette nettstedet, ikke gjør dette nettstedet fordi det er ikke bra, men vi vil bruke det som et rammeverk og gå gjennom prosessen med hvordan vi tar denne ideen og slå den inn i en reell nettsted vi kan bruke. Vi vil begynne med å bryte nettstedet ned. Som du har gjort i CS50, du ønsker å tenke på hva som er de faktiske komponenter som går inn i dette nettstedet. I utgangspunktet vri fra en idé som er like liksom et abstrakt begrep til en ekte, konkret ting som du kan gjøre. Vi starter med å spørre noen spørsmål. Hva er dette nettstedet? Hvorfor gjør vi det? Hva er det skal brukes til? Den slags ting. Når det gjelder Facebook Cat, vi i utgangspunktet ønsker et nettsted som lar kattene sosialt nettverk med hverandre. Tanken er at de kan legge ut på hverandres vegger, de kan legge inn kommentarer, den slags ting. Og det er der vi kommer inn i de funksjonelle komponenter. Vi har nå denne typen rammen av - vi har brukerprofiler, har vi kommentarer, og vi kan legge inn. Kanskje en dag vil vi influent liker og den slags ting. Og vi slags ønsker å prioritere disse funksjonene går i. Vi ønsker å si som, ok, det er veldig viktig at alle har en profil og at alle kan legge ut på hverandres vegger. Sekundært til det, ville kommentarer være hyggelig. Kanskje senere på vi vil influent liker. Så du ønsker å ha en idé om hva som er grunnleggende for prosjektet og hva er liksom en mer generell funksjon som kan brukes senere. Du vil liksom ha en spesifikk liste i tankene, men prosjektet at du starter med ikke kommer til å være det prosjektet som du er ferdig med. Med andre ord, ting kommer til å endre mens du utvikle området, og du ønsker å gi rom for det. Jeg skal slå den over til Ben som kommer til å snakke litt om struktur. 

[Ben] Jeg skal snakke om den mer tekniske siden av webutvikling. La oss bare gå over noen grunnleggende først. Når du gjør en web-app, hovedinndelingen som du er nødt til å ha er du kommer til å ha noen ting som skjer i klientsiden - det vil si koden som du er leseren tar fra området og Javascript, HTML, CSS ting. Det er alt på klientsiden. Du kommer til å ha annen kode som kjøres på serversiden som holder styr på alle data som folk sender inn til deg, bestemmer hvem som skal gi hva, sånne ting. Dette er bare noen terminologi, slik at dere er alle kjent med hva vi snakker om. Utover det divisjon det er godt å tenke på din web app i form av et par av adskilte komponenter. Når du gjør webutvikling en av de tingene som du bør alltid være å prøve å gjøre er å redusere kompleksiteten. Jo mer kompleks koden er jo mer sjanse er det for å gjøre feil, desto vanskeligere er det å endre senere. Så, hvis du kan bryte opp programmet ditt i noen distinkte funksjonelle områder som vil - og du kan redusere slags mengden av kryss-området kommunikasjon - som vil hjelpe deg mye i det lange løp i forhold til å redusere feil. 

For å være konkret, vanligvis folk dele opp en web app til - disse er slags buzz ord nå, men de er fortsatt nyttig. Du har kanskje hørt folk snakke om modeller, visninger og kontrollere. Modeller er de faktiske data som programmet ditt kommer til å forholde seg til. For eksempel, i Pon Facebook, ville modellene være - du vil ha en modell for som innlegg, og en modell for brukerprofiler, sånne ting. Dine synspunkter er hvordan du presenterer disse dataene til brukerne. Du har kanskje en visning for å se på et enkelt innlegg og alle kommentarene og et annet syn på veggen din som har en liste over alle innleggene som er rettet mot deg, og et annet syn for din nyhetsfeed - sånne ting. Til slutt, har du kontrollerne som er utgangspunktet når folk sender deg innlegg og du gjør oppdateringer til din back-end system, du øke en haug med tellere, og hva som helst. De er dine kontrollerne. 

Jeg kommer til å snakke mest til om modeller. Visninger er teknisk sett ikke så vanskelig, og problemet er mer med utformingen av dem Controllers kommer til å være konkret til hva du designer. Men det er noen ganske generelle teknikker du kan bruke for å gjøre modellene finere og enklere å jobbe med det jeg synes er veldig nyttig. Dette er for det meste kommer til å dreie seg om hvordan man skal håndtere dine web apps data på en fin måte. De største problemene med modeller er at de lever på klienten og serveren, og du må finne ut a) hvordan du får dem - alle relevante seg - fra serveren til klienten, og b) hvordan å holde dem i sync. Brukerne kommer til å ønske å gjøre noen oppdateringer. De kommer til å ønske å lage nye innlegg. De kommer til å ønske å like ting og ting hvis du har slike. De er de største tekniske utfordringene med å håndtere modeller. Det første du kommer til å ønske å stille deg selv er hva slags data går i denne modellen, og hva slags spørsmål vi kommer til å ønske å gjøre - det vil si, hvordan skal vi se på de modellene? For katten din Facebook eksempel innlegget ditt kommer til å ha en forfatter forbundet med det, noen innlegg på veggen tekst, og en mottaker av veggen innlegget. Og så kan det være lurt å spørre som i en haug med forskjellige måter. Du ønsker å se på det etter som skrev som innlegg, etter som fikk som legger inn, kanskje etter datoen de ble lagt ut. Men hvis du kommer til å gjøre det etter dato, så må du legge til et annet felt til innlegget ditt av når det ble faktisk lagt ut. Disse to faktorene - hvilke data du vil bruke, og hvordan du ønsker å se den - du bør tenke på dem først, fordi de er avhengige av hverandre, og det kommer til å bli vanskeligere å legge dem senere. 

Det er noen andre hensyn. Når du tenker på hvordan du avtale med modeller på serveren hva du ønsker å se på er - du i utgangspunktet ønsker å gjøre server så enkelt som mulig. Gjør ting på klientsiden er generelt mye raskere hvis du kan gjøre det rent på klienten uten å gjøre noen form for forespørsel nettverk. Ideen er å gjøre som mange av de spørsmål som du kan på klienten. Det eneste problemet med at er at hvis du ber om alle dine data i begynnelsen så det kommer til å ta lang tid å laste. Så, er det lurt å finne en gyllen middelvei mellom det å ha nok data på klienten at du kan gjøre det meste av arbeidet der, men ikke bare hente alt på en gang slik at du får veldig treg lasting i begynnelsen. For eksempel, for katten din data ville du sannsynligvis ønsker å hente en haug av nyere vegg innlegg. Du ville ikke ønsker å hente alle av dem fordi det kunne gå tilbake et par år. Men du ikke ønsker å hente dem en om gangen fordi det ville innføre en masse nettverk overhead. 

Det er ofte ganske vanskelig - når du har en database som kjører - det er ofte ganske vanskelig å endre hvilke data du har i det - det vil si legge til en ny database kolonne eller noe - så en god strategi er egentlig bare for å holde mye av dine data i en tekst blob - en JSON blob - JSON er Javascript Object Notation - Grunnen til det er nyttig er fordi da kan du legge til nye egenskaper til alle disse JSON blobs uten å endre databasen. Den eneste ulempen til det er at hvis du har en haug med felt at du har lagt til senere - som skjult i at JSON blob - da er det vanskeligere å spørre dem inne i databasen. For eksempel, hvis du senere - hvis du hadde ditt innlegg modell som vi diskuterte tidligere med bare forfatteren, mottaker og teksten - du kan også ha en JSON blob og hvis du senere ønsket å legge til et datofelt ville du ikke trenger å endre databasen. Du kan bare legge til datoer til alle tekstfeltene. Og så ville du være i stand til å se på dem på klientsiden, men du ville ikke være i stand til å spørre dem på serversiden fordi det er skjult inne i teksten. 

Det andre problemet som du ønsker å tenke på er hvordan klienten og serveren kommer til å kommunisere. Du vanligvis ønsker å holde dette så enkelt som mulig. Du kan bare ha som en get-me-dette data forespørsel, en lage-en-ny-objekt ting, og en oppdatering-en-gammel-objekt forespørsel. Og disse vil alle være ulike nettadresser på en server som du - at nettleseren vil - kan du bruke AJAX-forespørsler for alle disse og enten motta eller legg til dine data. Igjen, for vår Cat Facebook eksempel du kunne ha den URL for å få et individuelt innlegg, og du vil ha en URL for å lage en ny vegg post og kanskje en URL for å laste opp ditt profilbilde, sånne ting. Men igjen, det er å pre-hente de fleste av dine data, slik at du ikke trenger å holde gjør nettverksforespørsler. Derfor kan du ikke ønsker å ha den enkelte får forespørsel om en enkelt innlegg, og i stedet ville du bare ønsker en GET-forespørsel for hele veggen. Og så hvis du prøver å finne en balanse fordi - dette er også kommer til å avhenge av din søknad. Fordi hvis du venter på at folk bare har 10 eller 20 vegg innlegg som vil være i orden. Men hvis du venter de vil ha tusenvis da at forespørselen ville ta for lang tid, og så kan det være lurt å legge et få-all-innlegg-siden parameter. 

For alle disse er du sannsynligvis kommer til å ønske å synkronisere data i JSON - Javascript Object Notation. Ganske mye hver språk omhandler JSON veldig godt. JQuery har denne fine getJSON funksjon som vil gjøre alt det harde arbeidet for deg. Og på PHP er det også veldig hyggelig JSON kommunikasjonsfunksjoner. Så, det er nok det beste formatet for sending av dine modeller frem og tilbake. 

Som et eksempel på hva vi har snakket om så langt, her er et eksempel flyt for din Cat Facebook-applikasjon. Det starter med nettleseren ber om basen webadresse. Serveren sannsynligvis ville sende over statisk HTML og noen Javascript og CSS. Det er vanligvis best å ikke gjøre noe gjengivelse på serveren. Du har sannsynligvis ikke vil - hva serveren ikke gjør det kommer ned på listen over veggen innlegg og generering av en HTML for hver enkelt, og å sende den over. Det er vanligvis best å gjøre det på klientsiden fordi ellers hver gang du ønsker å re-tegne noe, må du lage en server forespørsel. Og at svært raskt gir deg mye overhead. Det er vanligvis best bare å skip sender ned statiske HTML og deretter Javascript og CSS som vil gjøre gjengivelsen på klientsiden. Så snart at ting kommer inn, da kan du ha - i Javascript - du kan gjøre forespørsler om veggen data og sånt, og etter at serveren er i utgangspunktet bare å gjøre databasespørringer og sjekke tillatelser. Det eneste viktige er at det ikke kan sende over noen andre brukere vegg innlegg at du ikke har lov til å se. Det kan i utgangspunktet være en svært tynn tilgang lag til databasen, og deretter alle de som viser data - alle visningene og sånt - de som kan skje i nettleseren din, og deretter når du ønsker å lage et innlegg eller noe du bare sende en ny forespørsel. 

Det er også noen fancy ting du kan gjøre på toppen av dette. I form av mer spesifikk teknisk informasjon, utvikling i ren Javascript kan være litt smertefullt, så er det noen biblioteker og verktøy som vil hjelpe deg mye med det. Jeg tror du har vel alle hørt om jQuery som gjør gjør HTML-gjengivelse og manipulasjon mye lettere - ha masse fancy funksjoner for fading inn og ut, og gjør Zippy animasjoner. Det er også dette biblioteket kalt Underscore.js. Den har en masse nyttige nyttefunksjoner, ting som du forventer Java å ha at det virkelig doesnt - ting som shuffling en matrise, fjerne duplikater fra en liste, eller flatere en liste av lister. Dette er bare en liten kodeeksempel. Strek har massevis av disse fine funksjoner som du skulle ønske du ville ha hele tiden. 

Og så er det en mer bibliotek som jeg ønsker å bruke litt tid på kalt Backbone.js fordi Backbone virkelig hjelper deg med å håndtere modeller på klientsiden og mye av forvirringen at det kan føre til. Backbone gir deg dette konseptet med modeller og samlinger i Javascript som er utgangspunktet akkurat som Javascript objekter i Javascript-matriser, men de har hendelser når du endrer deres egenskaper. Akkurat som i Javascript, kan du ha en hendelse når en knapp blir klikket eller noe disse Backbone modeller og Backbone samlinger vil kringkaste ting som at når de endres. Det betyr at du bare kan skrive noe sånt som dette kodebit her - dette sier, når du legger noe til innlegg matrisen du tegne hele veggen. Og dette vil si når et innlegg nummer av slike endringer, du varsle brukeren om at noen likte sine innlegg. Eller når noen eiendom i et innlegg endringer du tegne innlegget. Sånne ting vil spare deg tonnevis av kompleksitet fordi ellers hvis du ikke har noen rammer som dette så hver gang i koden som du endrer noe om et innlegg, ville du må huske selv å kalle alle rendringen funksjoner og sånn, og hvis du ønsket å legge til noe nytt som har skjedd hver gang du endret et innlegg du måtte gå gjennom hvert sted i din kode som du endret et innlegg og legge til at nye ting. Et rammeverk som dette vil fjerne mye av det mellom-lags kommunikasjon som gjør koden komplisert og vanskelig å vedlikeholde. 

Det er litt om utsikt også. Jeg kommer til å la det meste av dette til Billy fordi de er teknisk sett ikke så veldig vanskelig. Bruk jQuery for dine synspunkter. Det er praktisk talt som en nødvendighet på dette punktet. Det gjør bare alt så mye enklere. Det finnes en rekke biblioteker. Hvis du har kompliserte brukergrensesnitt-elementer, hvis du vil ha en autofullfør ting eller liker en av de fancy multi-velgere - hvis du vil ha noe sånt, bør du nok bare søke rundt og du kan finne en god bibliotek som vil gjøre hva du vil. Billy vil forklare mer om de faktisk vanskelige deler av utsikten. Også, som en side note, har Backbone noen funksjonalitet for å lage visninger kommunisere pent med modeller - se på dokumentasjonen for alle disse bibliotekene, faktisk. Bare se på de docs. De er svært godt skrevet og lett å følge. Generelt, kan du ganske mye bare Google hvis du har problemer. Det er mange mennesker som bruker dem. Jeg tror dette er som en siste kommentar. 

Det er også noen mer avanserte ting som du kan gjøre hvis du er ute etter å lage din web app ekstra awesome. Du kan gjøre - den nye HTML5-spesifikasjonen har en masse fancy ting du kan gjøre. Lokal lagring - som er at du kan lagre data i nettleseren - snarere enn å måtte gå tilbake og lese serveren for alt, du kan beholde noe av det på klienten og at selv lar folk - i enkelte tilfeller kan det også la deg bruke nettsiden offline. Det er dette som kalles WebSockets som er en annen form for nettverkskommunikasjon der i stedet for bare du gjør en forespørsel, får du svar og du er ferdig, du holde åpne en forbindelse til serveren, og slik at du kan gjøre ting som real-time oppdateringer. Så, hvis du prøvde å lage en chat app, kan du bruke WebSockets å kommunisere frem og tilbake, slik at du ikke ville ha til å holde ber om, "Oh, server, gjorde noen sende meg en prat?" hvert 10. sekund eller noe. Det er også en interessant HTML5 funksjon der du kan gjøre det ser ut som URL-en til siden er i endring uten å måtte faktisk laste det. Du kan bruke frem og tilbake-knappene uten å gjøre en haug med nettverksforespørsler. Sånne ting er veldig nyttig i forhold til å gjøre det rask, men også fungere som en web-app skal. 

Det er også dette som kalles CoffeeScript. CoffeeScript er et annet språk, faktisk, sammenstiller det ned til Javascript. Du ville skrive all koden i CoffeeScript, og deretter kjøre denne kompilatoren, og den spytter ut en Javascript-fil som du kan inkludere i din webside. Grunnen til at CoffeeScript er fint fordi det blir kvitt mye av rare saker som Java har der er lik likemenn, og tilsvarer likemenn gjøre forskjellige ting, eller liker - den har bedre syntaks for å håndtere matriser og funksjoner. Dette er en liten bit av CoffeeScript som produserer en liste over alle rutene fra 10 ^ 2-1 ^ 2 i motsatt rekkefølge. Som du kan se, lar ofte CoffeeScript du uttrykker i en tråd hva ville ta fem linjer med Javascript. Det kan gjøre ting mye enklere. Det er en liten bit av ny syntaks å lære i starten, men det definitivt vil gjøre deg mer produktiv i det lange løp. 

Du kan også bruke andre språk på serveren enn PHP - språk som Ruby, Python, eller det er enda et prosjekt kalt node.js som vil la deg bruke Java på serveren. Personlig, jeg virkelig, virkelig hater PHP. Jeg bare ikke liker å jobbe med det. Hvis du også tror at det er en forferdelig cluge av et språk, så kan du bruke en av disse i stedet. Generelt, hvis du ønsker å gjøre noe, og du ikke helt vet hvordan du vil gjøre det, bare søke på Internett. Det er tonn på tonn med ressurser, spesielt på - Stackoverflow er en stor en. Det er dette nettsted der programmerere spørre hverandre spørsmål. Du har kanskje kjørt inn i den hvis du skulle ha problemer på CS50 øvingsoppgaver. Og det er tonnevis av bibliotekene for å gjøre stort sett alt du ønsker. Hvis du ønsker å gjøre noe, og du ikke vet hvordan du gjør det, ikke anta at det er umulig. Bare se deg rundt, og du kan finne noen gode ressurser. 

Som en generell bryte opp, de viktigste takeaways er å holde ting enkelt. Jo mer kompleks koden er i begynnelsen og jo mer du prøver og gjøre fancy ting, jo lengre tid vil det ta å få noe faktisk funksjonell og jo vanskeligere vil det være å endre senere. Så, gjøre ting på den dumme, enkle måten først. Å gå sammen med det, ikke vær redd for å kaste bort gammel kode eller rydde det opp mye. Generelt, når du faktisk har noe arbeids, det er mye lettere å tenke på enn når du er fortsatt i begynnelsen stadier hvordan kan jeg sette alt dette sammen. Det er best å gjøre det dummeste mulig design som fungerer og deretter forbedre det iterativt enn å prøve å få alt riktig første gang. I forhold til klient-server-divisjon, prøve og holde serveren din veldig enkelt - bare en database og noen autentisering og ikke gjøre noe hardt arbeid der. Gjør alle dine kompliserte ting på klientsiden i nettleseren i Javascript så mye du kan. Se deg rundt for bibliotekene som gjør livet ditt bedre. Alltid bedre å bruke kode som noen andre skrev hvis du - og ikke for å skrive det selv. Det er en masse ting på internett. Google er din beste venn. Google er programmererens beste venn. Ja, definitivt ikke være redd for å se seg om etter ting. OK. Og over til Billy. 

[Billy] Egentlig før jeg begynner med noen design ting, Er det noen som har noen spørsmål til Ben om noe som han snakket om? Ok, bra. Igjen, gi oss beskjed hvis noe er uklart eller hvis du vil at vi skal gå over noe litt mer. Jeg kommer til å gå tilbake litt og snakke om de mer fundamentale deler av design. Ben nevnte modell kalt - beklager, modellen kontrolleren view system som er liksom det tekniske aspektet, så jeg kommer til å se på utsikten spesielt, og jeg kommer til å starte med hvordan du vil utforme et syn som ser fin. Her er litt av en virkelig grunnleggende mal for vår Cat Facebook. Jeg tror det er noen grunnleggende i moderne UI design som er verdt å plukke opp. Du kan legge merke til det er en mye tomrom over hele siden, god plass til ting. Føler ikke at du må ta knekken på ting på en side. Du ønsker å forlate masse plass åpen, og hvis du går til nesten hvilken som helst moderne nettside du vil se det er hvitt overalt. Det er hvit på steder du ikke forventer. Du har denne fargepaletten, og det er lurt i begynnelsen å velge en fargepalett som du kommer til å jobbe med og utvikle. Du også - det hjelper å velge en skrifttype, og på den måten du liksom jobbe med disse konkrete grunnleggende av design. Du har din type, du har dine farger, og deretter kan du slags passe alt annet i etter behov. Så, som jeg sa, med fargevalget du vil bruke dristigere farger for ditt fargevalg sparsomt. Overskrifter er fin. Knappene er fint å ha virkelig store, prangende farger. Men generelt, hvis du har en nettside som har farger overalt, alle stirrer deg i ansiktet, det bare ser rotete, og det er ikke bra. Du vil vanligvis bruke lyse farger. Prøv å, igjen, plukke en ganske sammenhengende fargevalg. Du kan ha disse små sprut av masse farger - som kan se ganske fin, men du ønsker å bruke dem ganske sparsomt. 

Som jeg sa, du vil være minimal. Mindre er nesten alltid mer. Hvis du kan vise noe eller ikke vise noe, og du er litt usikker på om det skal være der som standard - sannsynligvis du er best av å forlate det ut. Du kan alltid legge det inn senere. Ja, holde ting enkelt. Men viktigst av alt, du ønsker å vurdere flere design. Tror ikke at når du gjør et nettsted, har du det i hodet ditt som du kommer til å gjøre området på en bestemt måte, og det kommer til å se ut akkurat som denne. Det kommer til å ha blått øverst på toppen og den blå siden bar og deretter den gule sub-header ting. Du ønsker å lage flere maler. Du kan enten - hvis du er flink med Photo Shop, kan du åpne den opp og liksom designe en nettside som du liker det å se. Hvis ikke, kan du bare bruke penn og papir, men skraper opp flere design. Du vil i utgangspunktet ha en satt opp der du har mange ulike design, og hvis man ender opp med å jobbe, så det er flott. Hvis man ender opp sviktende, så har du alltid en til å slå til. Generelt, ikke føler at du bør være begrenset til hvilken design du først bestemme. Design er svært variabel, og en del av betydningen av modellen kontrolleren visning systemet er at du kan bytte inn og ut ulike visningene du vil. Du kan påvirke dataene på én måte, og deretter bestemme, oh, faktisk, som ikke fungerer så godt. Jeg tror det er litt for komplisert eller det er en del her som virkelig ikke fungerer, så jeg skal bare helt forlate dette synet og swap i en helt ny en. Vi kan fortsatt bruke de gamle modellene og de gamle kontrollerne. Vi kan gjøre alt på serveren og klienten som vi ville gjort før. Men selve bølgen av dataene som vises kommer til å være litt annerledes. 

Såvidt faktisk implementere design du ønsker, når du har noen design skisserte på papir eller på Photo Shop eller hva, det finnes en rekke verktøy som er gjort tilgjengelig for deg. Den første du er godt kjent med som er HTML, PHP, eller hva språket du bruker bare å kode de statiske sidene på nettstedet ditt. Du har jobbet mye med HTML hvilken type gir du disse kodene at du kan sette ting i, og i utgangspunktet er det en måte å organisere innholdet. For eksempel, har du overskriften der oppe, så du kommer til å ha en header tag, og det kommer til å ha litt tekst på innsiden av det som sannsynligvis kommer til å være i en annen kode. Da har du en sidebar kanskje med noen forskjellige linker, og de skal alle være i egne koder. Så, i utgangspunktet HTML på sitt hjerte er en måte å dele opp siden hvor du til slutt ønsker å formatere den. Så igjen, du har sett det før. Du er ganske komfortabel med å jobbe med det nå gitt at du har gjort den siste PSett forhåpentligvis, så det burde ikke være noe problem. 

Da har du CSS som i utgangspunktet håndterer alt av design statiske aspekter. Det ville håndtere alle farger, alt av plassering av forskjellige elementer, hvor de går i forhold til hverandre, hvor store de er, de forskjellige typer posisjoneringer som du ville ha - med andre ord, kan du ha ting fikset slik at når du blar nedover de blir, eller du kan ha ting i forhold til andre elementer. Alt av den slags ting er i CSS. Dessuten kan du gjøre ulike dekorasjoner, kan du ha tekstfarger, teksteffekter, alt av den slags ting. Ben ga en virkelig god seminar om dette sist helg, og så ville jeg definitivt sjekke det ut hvis du har tenkt å gjøre noen fancy ting med CSS. CSS3 er faktisk den nyeste versjonen av CSS, og det kan gjøre alle slags virkelig fine ting. Det kan gjøre gradienter, du kan ha fine, avrundede hjørner, og du kan gjøre alle slags ting å gjøre nettstedet ditt ser mer moderne og fancy. 

Den neste verktøyet er Javascript og jQuery som Ben snakket litt om, men jeg får litt lenger inn. Javascript, som du har jobbet med det en liten bit, eller i det minste sett det i foredrag, er en slags måte å dynamisk gjør ting i HTML. HTML, som dere vet, er statisk, så når du har HTML du ikke kan endre det. Men Javascript, på noen måter, er en måte å være i stand til å endre HTML. Så du kan gjøre det, og det er flott, men Java virkelig er en smerte å jobbe med. Det er så lenge og stumpe og å gjøre selv de enkleste ting krever mye av linjer med Javascript. Så, er jQuery utgangspunktet et bibliotek for Javascript som forenkler alt dette. Den sier, ok, hvis du ønsker å ha en firkantet boks kommer fra venstre og visne inn i siden slik at det er i midten, i Javascript som ville ta - Jeg vet ikke, noen hundre linjer å gjøre, og det ville være en smerte, og du kommer ut av det å hate alt om webprogrammering. JQuery du i utgangspunktet har element-dot-fade-in, eller noe sånt. Så, veldig, veldig enkle funksjoner som lar deg gjøre alle slags kule animasjoner og den slags ting. Den andre tingen som disse to er veldig bra for bare gjør dynamiske ting med nettstedet. Så, i stedet for bare å ha en HTML-side - som viser noen data, men gjør faktisk ikke gjøre noe - Javascript og jQuery vil la deg ha knapper som du kan klikke på, og du kan dra elementer og re-order dem og sortere dem, og har nye elementer lagt til eller fjernet. Du kan legge Sletting, den slags ting. Så, gjør jQuery tonnevis av kule ting. Og Vipul er faktisk å gi et seminar på det i dag, tror jeg, på 5-o'clock, så hvis du kan holde rundt så lenge, som ville - 5 eller 4? Fire. Unnskyld. Det er faktisk rett etter dette, så jeg vil anbefale stikker rundt for det hvis du kan. JQuery er super, super nyttig, og du vil være i stand til å gjøre mange virkelig fine ting med det for stort sett alle web utviklingsprosjekt. 

Nå kommer jeg til å komme inn i form av et skille. Jeg har snakket i utgangspunktet om brukergrensesnitt. Brukergrensesnittet er bare utformingen av området. Men det er liksom et annet konsept som er brukeropplevelsen. De to er veldig forskjellige. Interface er definitivt en del av opplevelsen. Med andre ord, når du går til et nettsted, du ser på grensesnittet. Det er en del av hvordan du opplever nettstedet. Men brukeropplevelsen er mer enn det. Brukeropplevelsen er om hva inntrykk av at brukeren får fra nettstedet ditt er. Så, åpenbart, er grensesnittet en del av det. Og det er definitivt en nødvendig del, men det er ikke tilstrekkelig. Med andre ord, hvis du har et fint grensesnitt, og det er pen og fargerik og alt det, det er flott, men hvis brukeren går til nettstedet ditt, ser en pen layout og det er forvirret av alt, har ingen anelse om hvordan du gjør noe, så åpenbart at du har gjort en virkelig dårlig nettside. Det er liksom der brukeropplevelsen kommer i. Jeg kommer til å snakke litt om UX design - UX er en forkortelse for brukeropplevelse - og hva slags hvordan du kan sørge for at du har en god brukeropplevelse. Det første punktet er at du kan designe et nettsted der en bruker kan gjøre noe som at brukeren muligens ønsker. Men hvis brukeren ikke kan finne ut hvordan du gjør disse tingene - med andre ord, hvis brukeren ikke har en god idé når de går til din side av, "Å, hvis jeg ønsker å oppdatere profilen min, så jeg klikker på denne knappen, eller hvis jeg ønsker å legge ut på noens vegg, så går jeg til deres vegg og klikk på en liten boks. " Hvis brukeren ikke vet det, så du effektivt har faktisk ikke implementert den funksjonaliteten riktig. En del av å implementere en funksjon er at brukerne faktisk er i stand til å bruke den. Og det kan være frustrerende - du kan lage et nettsted, og det kan gjøre alle typer fantastiske ting, men så har du folk teste det og si: "Det kan ikke gjøre dette. Hvorfor kan det ikke gjøre dette? "Og du vil si tilbake til dem, "Vel, det kan. Du trenger bare å gå inn i den syvende rullegardinmenyen på denne obskure side som bare er funnet ved en link nederst til høyre "eller noe. Selvfølgelig trenger du ikke ønsker det. Du vil at det skal være klart for brukerne hva de er ment å gjøre, og den skal være enkel og intuitiv for dem. 

En annen ting som du ønsker å prøve å gjøre er, hvis noen kommer til å gå til nettstedet ditt og ni av ti ganger gjør handling A, og en av 10 ganger gjør handling B, har du sannsynligvis ønsker å fokusere sin erfaring på handling A. Med andre ord, du vil gjøre det veldig, veldig klart hvordan du gjør A. En bør være front-og-senter - gå til området, se det, oh, det er rett der. Mens B åpenbart du ønsker å være klar, men du kan la den være litt mer i bakgrunnen. David gir et godt eksempel på dette i foredraget, som er den Boston T-systemet. Når du går til Boston T og du ønsker å kjøpe en billett, du må få inn 5 menyer før du faktisk kan kjøpe en billett for en $ 2, $ 2,50 verdi, som er hvor mye tid det tar å kjøre T-banen i en retning. Det er et problem fordi de fleste som rir T-banen sannsynligvis bare ønsker å gå til ett sted, kjøpe sin billett, få på med en gang. Det gir ikke mening at de må gå gjennom mange forskjellige menyer for å komme dit. En bedre brukeropplevelse ville være en rask knapp på den første siden som bare sier, "kjøpe en enveisbillett," og som ville sette i alle standard standardverdiene, og deretter hvis noen ønsker å kjøpe en annen billett enn det, de fortsatt, selvfølgelig, har muligheten til, men du har optimalisert for den common-use case som er virkelig viktig. Du kan se eksempler på dette på Facebook, ikke sant? Hvis du går til Facebook, og du ønsker å publisere en status, det er helt på toppen som er hva du ofte ønsker å gjøre. Så snart du går inn på siden, kan du gjøre de vanligste tingene som du ønsker å gjøre. Hvis du ønsker å gjøre litt mer kompliserte ting som, si at jeg ønsker å gå til min venns vegg og legge inn et bilde på det - som jeg ønsker å gjøre ofte, men ikke så ofte som poste statusoppdateringer - så i dette tilfellet, jeg skriver navnet sitt i boksen øverst, klikk på profilen sin, og da, likevel, det er rett på toppen der en gang jeg har fått til sin profil. Igjen, jeg har optimalisert i prioritet for de vanligste-bruksmåter. 

En annen viktig ting er at ofte folk vil liksom prøve å komme seg rundt dette ved å si, ok, så jeg har gjort området og folk finner det forvirrende, og det er et problem, ikke sant? Selvfølgelig, jeg vil at folk skal bli forvirret av innholdet på nettstedet mitt. Men måten å løse det er å ikke ha noe dukker opp og sa, hei, jeg kommer til å lære deg hvordan du skal bruke dette området. Trinn 1 - Klikk på denne knappen. Trinn 2 - gå her. Jada, det er en vei rundt det - det er en måte at du kan fortelle folk hva de skal gjøre, men det er egentlig ikke den optimale måten. Hvis jeg går til en nettside og plutselig jeg bombardert med denne opplæringen som forteller meg hva du skal gjøre og hvor du skal dra og alt dette, det er ikke morsomt for meg. Det er ikke en god opplevelse for meg. Det er litt vondt. Jeg vil bare begynne å gjøre ting. Folk kommer til å lukke ut av deres dialogboksen eller komme seg ut av opplæringen, ikke vet hva de skal gjøre, og deretter klage fordi du har ikke fortalt dem hva de skal gjøre. Måten å løse dette på er ikke ved å gi noen form for opplæringen eller retninger - noe sånt. Så mye du kan unngå det, du virkelig ønsker å vise brukeren hva du skal gjøre bare av naturen av hvordan nettstedet er lagt ut. Med andre ord, hvis jeg går til Facebook uten å logge på, den første tingen som jeg ser på hovedsiden - det er litt innloggingsboksen. Så, duh. Jeg må logge i. Det er rett der. Mens hvis jeg gikk til Facebook, og jeg hadde til å klikke litt linken nederst som sa 'logg inn' og resten av siden var bare en slags bilde eller noe, Jeg ville egentlig ikke vet hva de skal gjøre, ikke sant? Jeg ville bli forvirret. Så kunne den fortelle meg å dra dit ned og klikk på knappen for å logge inn, eller logg inn-knappen kan være rett på toppen der jeg kommer til å se det. Du vil alltid være å vise brukeren hva de skal gjøre, og som bør være iboende i selve siden. 

Når du tenker på design og spottet opp forskjellige måter uttrykke din side, du virkelig ønsker å tenke på hva brukerne skal skal gjøre og hvordan du kan vise dem hva de skal gjøre. En siste ting er testing er veldig, veldig viktig. Det er flott å få noen - få en venn, få noen du ikke vet selv - som aldri har sett stedet før å bruke nettstedet. Fordi du har jobbet på stedet i flere timer, har du stått og stirret på det, og du vet nøyaktig hva du skal gjøre så åpenbart at du kommer til å teste ting som du har jobbet med, og som du vet arbeid. Men hvis noen andre kommer sammen og bruker nettstedet som aldri har brukt det før, det er en unik opplevelse, fordi du har noen som ikke har forkunnskaper av området går inn i det, slik at de er nødt til effektivt ingen anelse om hva jeg skal gjøre eller hva slags bruk tilfeller er til stede for dem. Det er flott. Det er unike fordi de er egentlig en person med en blank for et sinn. De kan fortelle deg om noe er forvirrende eller uklart. De kan gi deg en idé om nøyaktig hva brukeropplevelsen på nettstedet ditt er. Det kan være veldig vanskelig å si at selv, så definitivt jeg vil oppfordre deg som du utvikler dine prosjekter - hvis du gjør web-baserte prosjekter - å få folk til å bruke området så tidlig som du har noen form for funksjonell demo. 

Nå skal jeg snakke litt om hvordan man skal håndtere en web utviklingsprosjekt. Vi har gått over hvordan du kan gjøre det teknisk back-end side, hvordan du kan designe en veldig god side, og det er flott hvis du jobber med deg selv, men - selv om du jobber med deg selv, og spesielt hvis du arbeider på et lag, prosjektledelse blir et stort problem. Du har liksom hørt om prosjektledelse i ulike former siden barneskolen når du ble fortalt gruppearbeid. Du må samarbeide, kommunisere, alt dette. Det gjelder alle fortsatt her, men det er noen unike omstendigheter med informatikk som du ønsker å være klar over, og du vil være sikker på at du håndterer godt. Jeg skal snakke først litt om det laget som du vil være i. Det er veldig viktig å velge riktig størrelse på et team som skal jobbe på, og i det ferdige prosjektet jeg tror du har muligheten til å velge mellom 1 og 4 personer hvis jeg er riktig. Du ønsker å være sikker på at du ikke bare velge antall personer at du ønsker å jobbe med fordi de er dine venner. Du ønsker å velge et lag som er en god størrelse og som vil få jobben gjort. Det er en trade off i å ha flere mennesker versus mindre folk. Hvis du har flere folk, kan åpenbart mer arbeid må gjøres fordi du har masse folk, masse kode, masse ideer, og det er alt flott. Men det krever også mye mer ledelse og mye mer kommunikasjon. Med andre ord, hvis du har fire personer som jobber på samme prosjekt og de er alle å redigere den samme koden, mer eller mindre de alle slags behov for å vite hva som skjer, så det krever at du - hvis du legger til noen nye funksjon du liksom måtte fortelle folk - jeg legger dette, Jeg endrer dette på denne måten - spesielt hvis du kommer inn i den virkelig dype ting som modeller og kontrollerne som faktisk kommer til å påvirke hvordan nettstedet fungerer. Hele laget må være klar over det, så du må sørge for at du ikke velger en for stor gruppe som kommer til å bli vanskelig å gjøre at kommunikasjonen. Du kan heller ikke ønsker å velge en liten nok lag som du ikke kommer til å være i stand til å kommunisere fordi det er bare deg. 

En annen ting å vurdere er balansen mellom hvor folks ferdigheter er. Det er flott hvis du er alle virkelig gode programmerere. Men hvis du er alle back-end folk, så nettstedet ditt ikke kommer til å se veldig bra fordi du har dette stor database, og det gjør super-raske søk - som er flott - men når du går til det, er det som en 1990 nettsted med rød og blå overalt, og det er ikke bra heller. Legg merke til at Ben og jeg jobber som et team er veldig fint fordi jeg er liksom mer i fronten, vi begge samhandle i midten-slutten, og Ben er virkelig bra med back-end ting, slik som fungerer veldig bra, fordi vi kan designe noen av sidene og i utgangspunktet hullene i det området som trenger å bli fylt kan besettes av enten en av oss, eller muligens begge deler. Du ønsker å være sikker på at det ikke er noen hull i laget ditt. Det er greit hvis det er litt av overlapping. Med andre ord, hvis du har to personer som er både bra med bakenden, som kan være god også fordi de kan hjelpe hverandre med problemer at de har. Det kan være et problem hvis du bare har en person som er ansvarlig for en bestemt ting og de kjører inn i et problem, slik at du ønsker å ha en liten bit av overlapping men du viktigst vil være sikker på at alle de mulige hullene er fylt. 

Det siste - og dette burde være innlysende, men det er ofte ikke. Du virkelig ønsker å være å ha det gøy. Poenget med denne avsluttende prosjekt i CS50 og ofte poenget med web-utvikling generelt er ikke å bare gjøre en jobb fordi det er behov for å gjøre. Du virkelig ønsker å være å ha det gøy, og du vil være å gjøre noe som er å motivere deg til å arbeide med den. Hvis alt du gjør er vondt å sette seg ned og jobbe på, så du ikke velger riktig prosjekt. Du ønsker å velge noe som du synes er interessante, du virkelig ønsker å se resultatet, er du begeistret når du får en ny idé om noe du kan gjøre - så det er alle slags prosjekter det at jeg er sikker på at du kan finne - alle har noe som ville virkelig intriger dem hvis de gjør en web-basert prosjekt. Jeg sier det igjen akkurat nå. Hvis prosjektet virker som en smerte, og du ikke ønsker å jobbe med det, velge et annet prosjekt. Velg noe som virkelig inspirerer deg. 

Ben nevnt dette begrepet køyring litt, og jeg ønsker å gå over den litt. Det er veldig viktig å jobbe i spruter hvor du få noe funksjonelt. Det kan være stor hvis du har denne planen for et nettsted som kommer til å gjøre A, B, og C, og til slutt vil det komme dit. Men du sitter fast i denne fasen hvor du jobber med det, og jobber med saken, men ingenting er å få gjort. Du har ikke noe å se og en konkret, funksjonelle ting. Hva du virkelig ønsker å gjøre så mye som det virker litt vondt noen ganger til jobbe med noe, og så liksom toppen av det hele, slik at det er minst på et stabilt, kjører versjonen, selv om den ikke har alle de funksjonene du ønsker. Og kanskje er det noen funksjoner som du virkelig ønsker å legge til, men du kan bare ikke fordi du ønsker å få dette området til et funksjonelt synspunkt. Og så du vil slags ha hele utviklingsprosessen ser sånn. Du ønsker å starte et sted funksjonell - eller egentlig starte med ingenting - men du vil få et sted svært enkel og funksjonell. Og så igjen, gjør et slags hopp og få et sted funksjonell igjen. Du vil sakte bygge opp, og det kan gå litt saktere enn det ellers ville ha gjort, men i det lange løp hvis du stadig fast i denne middelvei fase hvor du ikke egentlig har noe å jobbe, kan det være en virkelig stor frustrasjon å arbeide med prosjektet ditt fordi du er alltid så nær å få det til å fungere, og det har aldri faktisk jobber. Du ønsker å jobbe i disse funksjonelle spruter, og du også ønsker å gjøre noen refleksjoner etter hver enkelt. Med andre ord, når du er på et punkt hvor området arbeider nå - det har ikke alt du liker, men det gjør noen ting - du ønsker å tenke, ok, er dette stedet å nå målet om at jeg satt ut for å gjøre? Med andre ord, hvis området kommer til å gjøre X, er det jeg har jobbet i retning av X? Er alle de funksjoner som jeg ønsket det? Og dessuten er det som serverer den generelle formål som jeg vil? Hvis du synes at nettstedet ditt er i ferd med å bøye av i en annen retning eller kanskje ting bare slags er ikke trener, kan det være på tide å skifte gir litt. Med andre ord, er det verdt å vurdere - det er verdt å kaste ut ideer om nødvendig og vurderer jeg virkelig jobber mot det jeg ønsker å være. 

Jeg tror det er mitt neste punkt. Ikke vær redd for å forlate ideer. Bare fordi du har brukt mange timer arbeider på en funksjon og endelig fikk det til å fungere, men det er virkelig ikke går så bra - som det ikke er så nyttig eller brukere har problemer med å bruke den - den slags ting - ikke vær redd for å kaste den bort. Det suger at du har brukt mye tid på å jobbe med det, men til syvende og sist du ikke vil ha et nettsted som er slags satt sammen av disse brikkene som slags arbeid, men er ikke så godt servert. Også, ikke vær redd for å omfavne nye ideer. Hvis noen kommer og sier hei, det nettstedet ser veldig kult, men ville det ikke engang være flott om det også gjorde dette? Bare fordi det er noe som du ikke hadde tenkt og noe som ikke er i din specs, noe som du ikke har satt ut for å gjøre, ikke vær redd for å ta den på og deretter arbeide med det. Fordi ofte ideer som du kjører med i løpet av utviklingen ende opp som de virkelig kule funksjoner på nettsiden. 

Jeg har sagt dette før. Jeg sier det igjen. Testere er super, super nyttig. Prøv å få folk som aldri har sett stedet før å logge seg på og se hva som skjer fordi de kan ikke bare teste nytten av nettstedet og brukeropplevelsen, men de kan også teste funksjonaliteten på måter som du ikke kan. Hvis du gjør noen funksjon som gjør en bestemt ting og du vet at det kommer til å gjøre det samme riktig hver eneste gang, det er flott. Men det kan ofte være vanskelig å gjøre rede for hjørne tilfeller der en bruker kan skriv noe som du ikke var ventet - nettopp fordi du definerte funksjonene selv. Så, for å ha noen komme på som ikke har noen anelse om hvordan å bruke området og til å bare bryte det i hvilken måte de kan gjøre er veldig nyttig fordi du få en idé fra et helt annet perspektiv på hva på webområdet fungerer og hva som må repareres. 

Sist, kommer jeg til å snakke om noen generell god praksis, og du har sett mange av disse i CS50, men de er også veldig, veldig gjelde i et prosjekt innstilling. Den ene er kommentarer. Alltid kommentere koden din, spesielt hvis du arbeider på et stort team. Det kan være så irriterende å bare ha en gigantisk blokk med kode som noen har skrevet og kanskje det fungerer, kanskje ikke, men du har ingen anelse om hva den gjør, så du har ingen anelse om det er nyttig eller ikke, eller om det skal være der eller ikke, og hvis du jobber med noe annet det er også mulig at du jobber med det samme, så bare være veldig, veldig forsiktig med å være hensynsfull av jevnaldrende og skrive kode som er godt dokumentert. Du trenger ikke å gå så langt som å gjøre hele greia der liker hvis du øke en teller har en kommentar som sier, jeg legger en til denne disken. Det trenger ikke å være så detaljert, men for enhver funksjon som du noen gang å skrive du bør ha noen dokumentasjon på hva som fungerer akkurat gjør, hva dens innganger er, og hva det skal returnere. På den måten kan du bruke andre folks komponenter av nettstedet og du kan jobbe mot å bygge noe stort. 

En annen viktig ting er at du ønsker å gjøre regelmessige opprydding. Koden blir rotete. Ikke føl deg dårlig hvis koden din er bare helt uleselig og en gigantisk rot. Det skjer i webutvikling alltid. Du legger til nye funksjoner, fjerne gamle. Stuff kommer til å være der som ikke burde være. Det er greit, men du vil være sikker på å håndtere det regelmessig. Du ønsker ikke å la det bygge seg opp til et punkt der du bare ikke kan finne noe i koden din, og du har ingen anelse om hva noe betyr. Det er tilfelle med HTML. Noen ganger vil du ende opp med gjenstander som ikke inneholder noe, og at du ønsker å bli kvitt de. I CSS, kan du henvise til elementer som ikke er der lenger, slik at du ønsker å bli kvitt den koden. I Javascript, kan du ha fjernet noe fra HTML. Så du ønsker å være sikker på at du alltid rydde opp, noe som gjør ting ganske så mye som du kan på en jevnlig basis. 

En annen virkelig nyttig ting som jeg ikke tror er skissert veldig mye i CS50 men det er verdt å komme inn er versjonskontroll. Ideen om versjonskontroll er når du i utgangspunktet holde styr på all den fremgang du har gjort mot nettstedet ditt, og hvis på noe punkt du skjønner, oh, dette var i arbeid en stund siden, men det virker ikke noe mer, kan du gå tilbake til tidligere versjoner og se hva som har endret seg siden da, og den slags ting. Den primære måten å gjøre det på er med Git, og Git er hele denne type system som Jeg tror Tommy MacWilliam ga et seminar om i fjor. Hvis du går inn i CS50 seminarer for 2011, kan du se hans seminar om det. Ideen om Git er utgangspunktet at med jevne mellomrom du gjør disse forpliktelsene som er måter å si det området er i en ganske stabil versjon akkurat nå så Jeg emballasje det opp og sende det bort til en server, og så kan du gå til denne serveren og se på alle tidligere versjoner av koden din og se hvordan det er kommet og all den slags gode ting. Så, det er i utgangspunktet det. Såvidt webutvikling, er vi glade for å holde rundt og svare på eventuelle spørsmål når det gjelder vår presentasjon. Det var det. Thanks. >> [Ben] Thanks. [Applaus] 

[Billy] Staff, er det noen som har noen spørsmål om ting som vi har dekket eller ting som vi ikke har dekket at de håpet vi ville dekke? Vi vil gjerne svare på dem. Anyone? [Publikummer] Hva er fordeler og ulemper med å bruke Ruby eller Python? [Ben] Spørsmålet var, hva er fordeler og ulemper med å bruke Ruby eller Python i stedet for som PHP. Proffene er at Ruby og Python er mye bedre språk enn PHP. I hvert fall i min mening, og jeg tror på en rekke andre folks meninger også. De ble laget mer for å gjøre komplekse ting, og mindre for ronket sammen nettsidene virkelig raskt med en liten bit av dynamisk innhold. Ulempene er at det er en liten bit av - det er mer av en læringskurve å få dem satt opp. Det er, som i PHP, kan du bare ha en HTML-fil, og du skriver mindre enn, spørsmålstegn, og deretter du skrive noen kode, og deretter skriver du spørsmålstegn, større enn, og så er du ferdig. I andre språk som Ruby eller Python, du må gå gjennom en litt mer arbeid for å få det første stedet kjører. Det er også - i hvert fall brukt det til å være tilfelle - at det er mer dokumentasjon tilgjengelig for PHP bare fordi det er flere personer som bruker det. Jeg tror ikke det er så mye av et problem lenger. Det er sikkert veldig god dokumentasjon for ting som Ruby on Rails eller Django for Python er tilsvarende. PHP er den som alle har vært brukt i årevis, og du vet hvordan det fungerer. Ruby og Python er litt mindre moden. 

[Publikummer] Hvis du skulle velge mellom en av dem til å lære eller plukke opp, som ville du foretrekke? Ærlig talt, jeg tror det avhenger av personen. Jeg beklager. Spørsmålet var hvilken ville du velge for noen til å lære? Jeg finner Python den fineste personlig. Det er mange mennesker som - Jeg gjorde mitt første web dev prosjektet i Python og Django. Det er mange mennesker som liker Ruby on Rails også. Trolig flere som vet Ruby on Rails. Ærlig talt, ville jeg bare gå med hva folk rundt deg vet slik at du har folk til å stille spørsmål. 

Spørsmålet var - på delte servere er det litt vanskelig å jobbe med Python? Det avhenger av din hosting. Det finnes en rekke web-verter som vil legge Python ting. WebFaction gjør det, ikke sant? WebFaction er en som Billy og jeg har brukt for noen prosjekter. De er virkelig flott. De støtter de fleste språk. Men det er sant at PHP er mye mer utbredt støtte. Så, er hvis du sitter fast på et webhotell som bare gjør PHP som en god grunn til å bruke PHP. 

[Publikummer] Jeg kom akkurat inn i å lære hvordan å spørre noen databaser, og jeg vet at min SQL er over alt, men jeg nylig fikk utsatt til - og du pekte den ut. Du ser JSON og utvid databaser. My SQL er fortsatt over alt. Hvordan ser du på at det skjer? Er det kommer til å være en økende tendens til mer utvid (hørbar)? Spørsmålet var - Jeg tror det kommer til å være en trend mot ikke-SQL-databaser. For eksempel, som MongoDB. Jeg tror det er definitivt sant. Mitt råd var mest mySQL-relatert her bare fordi mySQL er industristandard. Personlig, jeg foretrekker mye databaser som ikke har schemos som MongoDB der du ikke har spørsmålet om, oh, jeg trenger å legge til en annen kolonne. Ve meg, som hva gjør jeg? Det er veldig vanskelig å gjøre det på MySQL, men når du har noe som Mongo det er mye hyggeligere. Den andre fine ting om Mongo er at postene er faktisk Javascript objekter. Det er ingen form for konvertering trinnet der du trenger for å ta disse database rader og gjøre dem om til en Javascript-objekt og deretter sende dem over ledningen. Jeg tror sånne ting kommer til å bli veldig, veldig nyttig for rask webutvikling i fremtiden. 

[Billy] Noe jeg ville legge til noe som er bare et generelt poeng er at føler ikke at du burde ha lært alle språkene vi har diskutert fra vår seminar. Tydeligvis poenget er å gi deg en idé om hva som er der ute, og hvis du er fascinert av noen av de tingene vi har nevnt kan du google dem og les deg opp på dem. Og som jeg nevnte, er det noen seminarer som omhandler nettopp disse tingene. Det er enda flere seminarer som jeg ikke har nevnt det trolig komme inn dette ting også. Tanken er at hvis du ønsker å arbeide med noe, her er verktøyene til din disposisjon. Ikke føle seg overveldet hvis du ikke er helt sikker på hva disse verktøyene gjør nøyaktig, men vet at de er der ute, og at du kan gjøre utstrakte bruken av dem av Google. 

[Publikummer] Hva slags ting du trenger å gjøre for å være sikker på ditt nettsted ser bra ut på mobile enheter? [Billy] Mobile enheter er litt vanskelig. Det er to måter du kan nærme seg det. Den første måten er at du faktisk har et mobilnettsted. Med andre ord, du utfører noen form for påvisning i begynnelsen når nettleseren kommer med forespørselen til din nettside som enten sier returnere denne visningen - som blir utsikten for stasjonære eller bærbare nettlesere - og denne annen visning for mobile enheter. Det er et sted hvor utsikten er virkelig fint i at du kan ganske mye å bytte to og har et grensesnitt som fungerer veldig fint på mobile enheter og har en helt annen en som fungerer fint på leser enheter. Problemet med det er at det tar lang tid fordi det betyr koding en helt annen grensesnitt. Den andre måten du kan gjøre det er - Mange moderne telefoner vil vise nettsider og prøver å gjengi dem som en nettleser ville, og de gjør sitt beste. Du kan slags prøve å holde lyset på mengden av jQuery Java du bruker som har en tendens til å være der ting kan gå galt en liten bit. Dette er liksom den måten at du bør bruke hvis du ikke har så mye tid. Hvis du har tid til å jobbe på en mobil grensesnitt, det er tydeligvis det beste alternativet. 

Jeg tror generelt for CS50 prosjekter, du kommer til å ønske å velge det ene eller det andre. Med andre ord, du vil lage en mobil app, eller du ønsker å lage en stasjonær nettside. Og den slags avgjør hvor du går med det. Men hvis du ønsker å utvide den ut senere, trolig det beste alternativet er å gjøre et annet grensesnitt for den andre. Jeg har litt erfaring i å utvikle WordPress-baserte nettsteder. Jeg arrangerte en personlig nettside på WordPress for en stund. Slike rammer kan være fint bare som helt grunnleggende ting. Ofte vil du bare kjøre inn i en masse å skreddersy problemer skjønt. Det er lurt å ha se noe på en bestemt måte, eller være en bestemt måte og du bare ikke kan fordi det er hard-telegrafert inn i systemet som Dette er hvordan du trenger å gjøre ting som kan være litt av et problem. Siden da har jeg slags vært mer tilbøyelig til å jobbe med nettsteder fra grunnen av. For ting som blogg databaser og den slags ting det er egentlig ikke så vanskelig å bygge et rammeverk. Hvis du virkelig strukket for tiden, kan du selvfølgelig bruke noe sånt som WordPress eller den slags ting for en blogg. Den slags ting som blogger butikken og gjøre er egentlig ikke vanskelig nok til at hvis du kjører inn i noen av slike ting, er du sannsynligvis best bare å lage en in-house-versjon. 

Jeg tror det handler om det, så takk igjen for at du kom. Vi likte å snakke med dere, og håper at du har lært noen ting. [Ben] Vi er glade for å snakke - vi må gå, men vi er glade for å snakke mer utenfor hvis du har et annet spørsmål. Takk igjen. [Applaus] [CS50.TV]