[Powered by Google Translate] [Seminarium] [Webbutveckling: Från idé till genomförande] [Ben Kuhn] [Billy Janitsch] [Harvard University] [Detta är CS50] [CS50.TV] [Billy] Hej, jag heter Billy och det här är Ben. >> [Ben] Hej. Vi kommer att tala om webbutveckling idag. [Webdev] [Billy Janitsch och Ben Kuhn] Lite om oss först. Ben är en slags back-end kille. Han gör saker och ting fungerar. Och så går jag in och göra dem vackra. Jag är i hög grad involverad i mer front-end layout design såna saker, och Ben, å andra sidan, vet vad han gör så han fungerar på back-end grejer. Tillsammans har vi gjort ett par saker. Till exempel, förra året arbetade vi på Gimblium som är ett online spelföretag. Det var vårt sista projekt för klassen, och sedan dess har vi gjort Harvard Class som är en online-ramverk för att surfa och shopping kurser vid Harvard. 

Vi kommer att börja med den här idén för vår webbplats. Vi kommer att göra Facebook, men för katter. Innan du faktiskt göra den här webbplatsen, gör inte denna webbplats, eftersom det inte är bra, men vi kommer att använda den som ett ramverk och gå igenom processen för hur vi tar den här idén och göra den till en riktig hemsida som vi kan använda. Vi börjar med att bryta hemsida ner. Precis som du har gjort i CS50, du vill tänka på vad är den verkliga komponenter som går in i denna webbplats. I grund och botten att vrida den från en idé som är bara typ av ett abstrakt begrepp till en verklig, konkret sak som du skulle kunna göra. Vi börjar med att ställa några frågor. Vad är det här webbplatsen? Varför gör vi det? Vad kommer det att användas till? Sånt. I fallet med Facebook Katt, vi i grund och botten vill ha en webbplats som låter katter sociala nätverk med varandra. Tanken är att de kan skriva på varandras väggar, de kan lämna synpunkter, den sortens saker. Och det är där vi kommer in i de funktionella komponenter. Vi har nu denna typ av ram - vi har användarprofiler, vi har synpunkter, och vi kan lägga upp. Kanske en dag kommer vi att inflödet gillar och sånt. Och vi slags vill prioritera dessa funktioner går i. Vi vill säga som, okej, det är verkligen viktigt att alla har en profil och att alla kan lägga upp på varandras väggar. Sekundärt till detta, skulle kommentarerna vara trevligt. Kanske senare kommer vi att inflödet gillar. Så, vill du ha en uppfattning om vad som är grundläggande för ditt projekt och vad blir liksom en mer generell funktion som skulle kunna tillämpas senare. Du vill sorts har en särskild lista i åtanke, men projektet att du börjar med inte kommer att vara det projekt som du är klar med. Med andra ord, saker och ting kommer att förändras när du utvecklar webbplatsen, och du vill lämna utrymme för det. Jag ska vända den till Ben, som kommer att prata lite om strukturen. 

[Ben] Jag kommer att tala om den mer tekniska sidan av webbutveckling. Låt oss bara gå igenom några grunderna först. När du gör en web app, huvud divisionen som du kommer att ha är du kommer att ha en del saker händer i klientsidan - dvs den kod som du är webbläsaren tar från platsen och JavaScript, HTML, CSS grejer. Det är allt på klientsidan. Du kommer att ha annan kod som körs på serversidan som håller reda på alla data som folk skickar in till dig, bestämmer vem att ge vad, sånt. Detta är bara en del terminologi så att ni alla känner till vad vi pratar om. Utöver detta division det är bra att tänka på din web app i form av ett par olika komponenter. När du gör webbutveckling en av de saker som du alltid ska försöka göra är att minska komplexiteten. Ju mer komplex din kod är det större chans finns det att göra fel, desto svårare är det att ändra senare. Så, om du kan dela upp din app i några distinkta funktionella områden det kommer - och du kan minska den typ av mängden tvär området kommunikation - som kommer att hjälpa dig mycket i det långa loppet när det gäller att minska buggar. 

För att vara konkret, brukar folk dela upp en web app till - dessa slags modeord nu, men de är fortfarande användbart. Du kanske har hört folk prata om modeller, vyer och controllers. Modeller är de faktiska uppgifter som din app kommer att ta itu med. Till exempel i din katt Facebook, skulle dina modeller vara - du skulle ha en modell för liknande inlägg, och en modell för användarprofiler, sånt. Dina synpunkter är hur du presenterar dessa data för dina användare. Du kanske har en vy för att titta på ett enda inlägg och alla kommentarer och en annan vy för din vägg som har en lista med alla inlägg som är riktade till dig, och en annan vy för ditt nyhetsflöde - sånt. Slutligen, har du de registeransvariga som i grunden när folk skickar inlägg och du gör uppdateringar för din backend-system, du öka en massa diskar, och vad som helst. De är dina controllers. 

Jag kommer att tala mest om modellerna. Åsikter är tekniskt sett inte så svårt och frågan är mer med att utforma dem Controller kommer att vara specifika för vad du skapar. Men det finns några ganska generella tekniker du kan använda för att göra dina modeller trevligare och lättare att arbeta med det jag tycker är mycket bra. Detta är främst kommer att handla om hur man ska hantera din webb apps data på ett trevligt sätt. De viktigaste frågorna med modeller är att de lever på klienten och servern och du måste lista ut a) hur man får dem - alla relevanta sådana - från servern till klienten, och b) hur man håller dem i synk. Dina användare kommer att vilja göra några uppdateringar. De kommer att vilja göra nya inlägg. De kommer att vilja att vilja saker och grejer om du har gillar. De är de största tekniska utmaningarna i att hantera modeller. Det första som du kommer att vilja fråga dig själv är vilken typ av data som går i denna modell och vilken typ av frågor som vi kommer att vilja göra - det vill säga, hur ska vi titta på modellerna? För din katt Facebook exempel ditt inlägg kommer att ha en författare i samband med det, någon vägg inlägg text, och en mottagare av väggen inlägget. Och då kanske du vill fråga det i en massa olika sätt. Du skulle vilja se på det med vem som skrev vilken post, av vem fick som posta, kanske efter det datum de publicerades. Men om du ska göra det efter datum, då måste man lägga till ytterligare fält till ditt inlägg om när det faktiskt skrivit. Dessa två faktorer - vilka data som du vill använda och hur du vill visa det - du bör tänka på dem först eftersom de är beroende av varandra, och det kommer att vara svårare att lägga till dem senare. 

Det finns några andra överväganden. När du funderar på hur du hanterar modeller på servern vad du vill titta på är - du i princip vill göra servern så enkel som möjligt. Att göra saker på klientsidan är i allmänhet mycket snabbare om du kan göra det enbart på klienten utan att göra någon form av nätverksbegäran. Tanken är att göra så många av de frågor som du kan på klienten. Det enda problemet med det är att om du begär alla data i början då det kommer att ta lång tid att ladda. Så är tanken att hitta en gyllene medelväg mellan att ha tillräckligt med data på klienten att du kan göra det mesta av ditt arbete där, men inte bara hämta allt på en gång så att du får riktigt långsamma laddningstider i början. Till exempel, om din katt uppgifter skulle du förmodligen vill hämta ett gäng nya vägg inlägg. Du vill inte att hämta dem alla eftersom det skulle kunna gå tillbaka ett par år. Men du vill inte hämta dem en i taget eftersom det skulle medföra en hel del nätverks overhead. 

Det är ofta ganska svårt - när du har en databas igång - Det är ofta ganska svårt att ändra vilka data du har i det - det vill säga, lägga till en ny databaskolumn eller något - så en bra strategi är egentligen bara för att hålla en hel del av dina data i en text blob - en JSON blob - JSON är JavaScript Object Notation - Anledningen till det är användbart är för då kan du lägga till nya egenskaper till alla dessa JSON blobbar utan att ändra din databas. Enda nackdelen med det är att om du har en massa områden att du lagt till senare - som gömd i det JSON blob - då är det svårare att fråga dem i databasen. Till exempel, om du senare - om du hade ditt inlägg modell som vi diskuterade tidigare med bara författaren, mottagaren och texten - du kan också ha en JSON klump och sedan om du senare vill lägga till ett datumfält du inte skulle behöva ändra din databas. Du kan bara lägga till datum till alla textfält. Och då skulle du kunna titta på dem på klientsidan, men du skulle inte kunna fråga dem på serversidan eftersom det är gömd inuti den texten. 

Den andra frågan som du vill tänka på är hur din klient och servern kommer att kommunicera. Du vill oftast att hålla detta så enkelt som möjligt. Du kan bara ha som en get-me-begäran uppgifter, en skapa-en-ny-objektet sak, och en begäran om uppdatering-en-gammal-objekt. Och dessa skulle alla vara olika webbadresser på en server som du - att webbläsaren skulle - kan du använda AJAX förfrågningar för alla dessa och antingen ta emot eller skicka data. Återigen, för vår Cat Facebook exempel du kan ha den adressen för att få ett enskilt inlägg, och du skulle ha en URL för att skapa en ny vägg inlägg och kanske en URL för att ladda upp din profilbild, sånt. Men återigen, det är att i förväg hämta de flesta av dina data så att du inte behöver hålla göra nätverksförfrågningar. Därför kanske du inte vill ha den enskilde få begäran om en enda post, och i stället skulle du bara vill ha en get begäran om hela väggen. Och sedan om du försöker att hitta en balans, därför att - Detta kommer också att vara beroende av din ansökan. För om du förväntar sig att folk bara har 10 eller 20 vägg inlägg det kommer att bli bra. Men om du förväntar sig att de kommer att ha tusentals då denna begäran skulle ta för lång tid, och så kanske du vill lägga till ett få-alla-inlägg-sedan parameter. 

För alla dessa är du antagligen kommer att vilja synkronisera dina data i JSON - JavaScript Object Notation. Ganska mycket varje språk behandlar JSON mycket väl. JQuery har denna fina getJSON funktion som kommer att göra allt det hårda arbetet för dig. Och om PHP finns det också mycket fina JSON kommunikationsfunktioner. Så, det är nog det bästa formatet för att skicka dina modeller och tillbaka. 

Som ett exempel på vad vi har pratat om hittills, Här är ett exempel flöde för din katt Facebook-applikation. Det börjar med din webbläsare begär basen webbadress. Servern förmodligen skulle skicka över statisk HTML och en del JavaScript och CSS. Det är oftast bäst att inte göra någon rendering på servern. Du kanske inte vill - vad servern inte gör det kommer ner på listan av vägg inlägg och generera lite HTML för var och en och skicka det över. Det är oftast bäst att göra det på klientsidan för annars varje gång du vill åter rita något, måste du göra en förfrågan server. Och det mycket snabbt ger dig en hel del overhead. Det är oftast bäst att bara fartyg sänder ner statiska HTML och sedan JavaScript och CSS som kommer att göra rendering på klientsidan. Så fort det där kommer in, då kan du ha - i JavaScript - du kan göra förfrågningar för väggen uppgifter och sånt, och efter att servern är i princip bara gör databasfrågor och kontroll av behörigheter. Det enda viktiga är att den inte kan skicka över några andra användare vägg inlägg att du inte är tillåtet att se. Det kan i princip vara ett mycket tunt tillgång lager till din databas, och sedan alla som visar data - alla de åsikter och grejer - som kan hända i din webbläsare, och sedan när du vill göra ett inlägg eller något du bara skicka en förfrågan. 

Det finns också en del snygga grejer som du kan göra på toppen av detta. När det gäller mer specifik teknisk information, utvecklas i vanlig JavaScript kan vara lite smärtsamt, så finns det vissa bibliotek och verktyg som hjälper dig en hel del med det. Jag tror att ni alla säkert hört talas om jQuery som gör att göra HTML-rendering och manipulation mycket enklare - har massor av snygga funktioner för blekning in och ut, och göra zippy animationer. Det är också detta bibliotek heter Underscore.js. Den har en hel del användbara nyttofunktioner, saker som du förväntar JavaScript för att ha att det verkligen doesnt - saker som att blanda en matris, ta bort dubbletter från en lista, eller tillplatt en lista med listor. Detta är bara ett litet kodexempel. Streck har en ton av dessa fina funktioner som du önskar att du skulle ha hela tiden. 

Och så finns det mer 1 bibliotek som jag skulle vilja spendera lite tid på heter Backbone.js eftersom Backbone hjälper verkligen dig att hantera modeller på klientsidan och en hel del av den förvirring som kan orsaka. Backbone ger detta koncept av modeller och samlingar i JavaScript, som är i grunden precis som JavaScript-objekt i JavaScript-matriser, men de har händelser när du ändrar deras egenskaper. Precis som i JavaScript, kan du ha en händelse när en knapp blir klickade eller något dessa Backbone modeller och Backbone kollektioner kommer att sända saker som att när de byter. Det betyder att du bara kan skriva något sådant här kodsträng här - detta säger, när du lägga till något till det inlägg arrayen du rita om hela väggen. Och detta skulle säga när en post har flera gillar förändringar, du meddela användaren att någon gillade deras inlägg. Eller när någon egenskap hos ett inlägg ändrar du rita om inlägget. Saker som kommer att spara massor av komplexitet för annars om du inte har någon ram som detta då varje gång i din kod som du ändrar något om ett inlägg, skulle du komma ihåg dig själv att kalla alla gör funktioner och sånt, och om du ville lägga till något nytt som hände varje gång du ändrat ett inlägg skulle du behöva gå igenom varje rum i ditt kod som du ändrade ett inlägg och lägga till det nya sak. En ram som detta kommer att ta bort en hel del av det mellan-lager kommunikation som gör din kod komplexa och svåra att underhålla. 

Det finns lite om utsikten också. Jag kommer att lämna det mesta av detta till Billy eftersom de är tekniskt mycket svårt. Använd jQuery för dina synpunkter. Det är nästan som en nödvändighet på denna punkt. Det gör bara allt så mycket lättare. Det finns en hel del bibliotek. Om du har komplicerade delar av användargränssnittet, om du vill ha en automatisk komplettering sak eller gillar en av dessa tjusiga multiväljare - Om du vill ha något liknande, bör du nog bara söka runt och du kan hitta ett bra bibliotek som kommer att göra vad du vill. Billy kommer att förklara mer om de faktiskt svåra delar av åsikter. Också, som en liten not, har vissa funktioner för att göra vyerna kommunicera Backbone fint med modeller - titta på dokumentation för alla dessa bibliotek, faktiskt. Titta bara på docs. De är mycket välskriven och lätt att följa. I allmänhet kan du ganska mycket bara Google om du har problem. Det finns många människor som använder dem. Jag tror att det är som en sista anmärkning. 

Det finns också några mer avancerade saker som du kan göra om du letar efter för att göra din web app extra häftigt. Du kan göra - den nya HTML5-specifikationen har en massa fina saker du kan göra. Lokal lagring - vilket är att du kan lagra data i webbläsaren - i stället för att gå tillbaka och granska på servern för allt, du kan behålla en del av det på klienten och att till och med låter folk - i vissa fall kan det till och med låter dig använda webbsidan offline. Det är det här som kallas WebSockets som är en annan typ av nätverkskommunikation där istället för att bara du gör en förfrågan får du svar och du är klar, du håller öppna en anslutning till servern och så att du kan göra saker som realtidsuppdateringar. Så, om du försöker göra en chat app, kan du använda WebSockets att kommunicera fram och tillbaka så att du inte skulle behöva hålla begär, "Åh, server, var det någon skicka mig en pratstund?" var 10 sekunder eller något. Det finns också en intressant HTML5 funktion där du kan få det att se ut som webbadressen till sidan förändras utan att någonsin behöva faktiskt ladda om den. Du kan använda knapparna Bakåt och Framåt utan att göra en massa förfrågningar från nätverket. Sånt är verkligen användbart när det gäller att göra det snabbt, men också fungera som en web app borde. 

Det är också denna sak kallad CoffeeScript. CoffeeScript är ett annat språk, faktiskt, sammanställer det ner till JavaScript. Du skulle skriva all kod i CoffeeScript, och sedan kör denna kompilator, och den spottar ut en JavaScript-fil som du kan inkludera i din webbsida. Anledningen till att CoffeeScript är trevligt är att det tar bort en hel del av konstiga fall att JavaScript har var lika jämlikar, och lika likar gör olika saker, eller vilja - den har trevligare syntax för att hantera arrayer och funktioner. Detta är en liten snutt av CoffeeScript som producerar en lista på alla rutor från 10 ^ 2-1 ^ 2 i omvänd ordning. Som ni ser, låter CoffeeScript ofta du uttrycka i 1 rad vad skulle ta fem rader JavaScript. Det kan göra saker och ting mycket enklare. Det är en liten bit av ny syntax för att lära sig i början, men det definitivt kommer att göra dig mer produktiv i det långa loppet. 

Du kan även använda andra språk på servern än PHP - språk som Ruby, Python, eller det finns även ett projekt kallat node.js som låter dig använda JavaScript på servern. Personligen är jag verkligen, verkligen hatar PHP. Jag bara inte tycker om att arbeta med det. Om du också tycker att det är ett fruktansvärt cluge av ett språk, då kan du använda en av dessa i stället. Generellt gäller att om du vill göra något och du vet inte riktigt hur du skulle göra det, bara söka på Internet. Det finns massor och massor av resurser, särskilt om - Stackoverflow är en stor en. Det är denna webbplats där programmerare ställa frågor till varandra. Du kanske har stött på det om du hade problem på CS50 problemsamlingar. Och det finns massor av bibliotek för att göra i stort sett allt du vill. Om du vill göra något och du inte vet hur man gör det, ta inte för givet att det är omöjligt. Se dig omkring och du kan hitta några bra resurser. 

Som en allmän avsluta, de viktigaste hämtställen är att hålla det enkelt. Ju mer komplexa koden är i början och ju mer du försöker och gör snygga grejer, desto längre tid tar det att få något som faktiskt fungerar och desto svårare blir det att ändra senare. Så, gör saker den stumma, enkelt sätt först. För att gå med på det, var inte rädd för att kasta bort gamla koden eller städa upp en hel del. Generellt, när du faktiskt har något arbete, det är mycket lättare att tänka på än när du är fortfarande i början stadier om hur jag sätter detta alla tillsammans. Det är bäst att göra det dummaste möjliga design som fungerar och sedan förbättra det iterativt än att försöka få allt rätt första gången. När det gäller klientserverdivision, försöka hålla din server mycket enkel - bara en databas och en del autentisering och inte gör något hårt arbete där. Gör alla dina komplicerade saker på klientsidan i webbläsaren i JavaScript så mycket du kan. Titta runt för bibliotek som gör ditt liv bättre. Alltid bättre att använda kod som någon annan skrev om du - och inte för att skriva det själv. Det finns en massa saker på Internet. Google är din bästa vän. Google är programmerarens bästa vän. Ja, definitivt inte rädd för att titta runt efter saker. Okej. Och över till Billy. 

[Billy] Egentligen, innan jag börjar med någon konstruktion grejer, är det någon som har några frågor till Ben om något som han talade om? Okej, bra. Återigen, låt oss veta om något är oklart eller om du vill att vi ska gå över något lite mer. Jag kommer att gå tillbaka lite och prata om de mer grundläggande delarna av design. Ben nämnde modellen heter - sorry, modellen controller view-system som är typ av den tekniska aspekten, så jag kommer att titta på utsikten specifikt, och jag ska börja med hur du skulle utforma en vy som ser bra ut. Här är lite av en riktigt grundläggande mall för vår katt Facebook. Jag tror att det finns vissa grundprinciper i modern gränssnittsdesign som är värt att plocka upp. Du kan märka att det finns en hel del tomt utrymme över hela sidan, gott om utrymme för saker. Inte känna att du måste squash saker i en sida. Du vill lämna gott om plats öppen, och om du går till nästan alla moderna hemsida ser du att det finns vitt överallt. Det är vitt på platser som du inte förväntar dig. Du har denna färgpalett, och det är klokt i början att välja en färgpalett som du kommer att arbeta med och utveckla. Du också - det hjälper till att välja ett typsnitt, och på det sättet du är sorts arbetar med dessa konkreta grunderna i design. Du har din typ, du har dina färger, och sedan kan du slags passar allt annat i så behövs. Så, som sagt, med din färgschema du vill använda de djärvare färgerna i ditt färgschema sparsamt. Rubriker är trevliga. Knappar är trevligt att ha riktigt stora, flashiga färger. Men i allmänhet, om du har en webbplats som har färger överallt, alla stirrar dig i ansiktet, det bara ser rörigt, och det är inte bra. Du vill i allmänhet använda ljusa färger. Försök att, återigen, plocka en ganska enhetlig färgschema. Du kan ha med små stänk av massor av färg - som kan se ganska trevligt, men du vill använda dem ganska sparsamt. 

Som jag sa, du vill vara minimal. Mindre är nästan alltid mer. Om du kan visa något eller inte visa något, och du är typ av osäkra på om det ska vara där som standard - förmodligen är du bäst av att lämna ut den. Du kan alltid lägga till det senare. Ja, hålla det enkelt. Men viktigast av allt, vill du överväga flera mönster. Tro inte att när du gör en hemsida, har du det i ditt huvud att du kommer att göra området på ett visst sätt, och det kommer att se ut exakt så här. Det kommer att ha den blå sidhuvudet längst upp och den blå sidofältet och sedan den gula sub-header sak. Du vill göra flera mallar. Du kan antingen - om du är bra med Photo Shop, kan du öppna upp och liksom designa en hemsida som du vill att det ska se. Om inte, kan du bara använda papper och penna, men repa upp flera mönster. Du vill i princip ha en uppsättning upp där du har massor av olika utföranden, och om man slutar arbeta, så är det bra. Om man hamnar misslyckas, då har du alltid en annan att vända sig till. I allmänhet inte känner för att du ska begränsas till vad design du först besluta om. Ringar är mycket variabel, och en del av vikten av modellen controller view-system är att du kan byta in och ut olika vyer som du vill ha. Du kan svänga datan ett sätt, och sedan bestämma, åh, faktiskt, som inte fungerar så bra. Jag tycker det är lite för komplicerat eller det finns en del här som inte verkligen fungerar, så jag ska bara helt överge denna uppfattning och swap på en helt ny. Vi kan fortfarande använda de gamla modellerna och de gamla styrenheter. Vi kan göra allt på servern och klienten som vi skulle innan. Men själva vågen av de data som visas kommer att vara något annorlunda. 

Så långt som att faktiskt genomföra den design som du vill, när du har några mönster skiss på papper eller på Photo Shop eller vad som helst, det finns ett antal verktyg som görs tillgängliga för dig. Det första du är väl förtrogen med vilken är din HTML, PHP, eller vad språk du använder bara för att koda de statiska sidor på din webbplats. Du har arbetat mycket med HTML vilket slags ger dig dessa taggar att du kan sätta saker i, och i grunden är det ett sätt att organisera ditt innehåll. Till exempel, du har huvudet uppe, så du kommer att ha en rubrik tagg, och det kommer att ha någon text på insidan av det som förmodligen kommer att vara i en annan tagg. Då har du en sidebar kanske med några olika länkar, och de som kommer att alla vara i separata taggar. Så i princip HTML i centrum är ett sätt att dela upp sidan hur du så småningom vill formatera den. Så återigen, har du sett det tidigare. Du är ganska bekväm med att arbeta med det nu med tanke på att du har gjort det sista pset förhoppningsvis, så det borde inte vara några problem. 

Då har du CSS som i princip hanterar alla de design statiska aspekter. Det skulle hantera alla de färger, som alla placeringen av olika element, där de går i förhållande till en annan, hur stora de är, de olika typer av positioneringar som du vill ha - med andra ord, kan du ha saker fast så att när du bläddra ner de stannar, eller så kan du ha saker i förhållande till andra element. Allt sånt är i CSS. Dessutom kan du göra olika dekorationer, kan du ha textfärger, texteffekter, alla såna saker. Ben gav ett riktigt bra seminarium om detta förra helgen, och så skulle jag definitivt kolla att om du planerar att göra några snygga saker med CSS. CSS3 är faktiskt den nyaste versionen av CSS, och det kan göra alla möjliga riktigt fina saker. Det kan göra övertoningar, du kan ha fina, rundade hörn, du kan göra alla möjliga saker att göra din webbplats ser mer moderna och snygga. 

Nästa verktyg är JavaScript och jQuery som Ben pratade lite om, men jag får en lite längre in. JavaScript, som du har arbetat med det lite, eller åtminstone sett det i föreläsning, är lite av ett sätt att dynamiskt göra saker i HTML. HTML, som ni vet, är statisk, så när du har HTML du inte kan ändra det. Men JavaScript, på vissa sätt, är ett sätt att kunna modifiera HTML. Så du kan göra det, och det är bra, men JavaScript är verkligen jobbigt att arbeta med. Det är så lång och trubbig och att göra ens de enklaste saker kräver massor av rader av JavaScript. Så, är jQuery grunden ett bibliotek för JavaScript som förenklar allt detta. Den säger, okej, om du vill ha en fyrkantig låda kommer från vänster och tona in på sidan så att det är i mitten, i JavaScript som skulle ta - Jag vet inte, hundra rader för att göra, och det skulle vara en smärta, och du kommer ut ur det hata allt om webbprogrammering. JQuery du i princip ha elementet-dot-fade-in, eller något liknande. Så, mycket, mycket enkla funktioner som låter dig göra alla typer av häftiga animationer och sånt. Den andra saken som dessa två är riktigt bra för är att bara göra dynamiska saker med webbplatsen. Så, istället för att bara ha din HTML-sida - som visar vissa uppgifter, men inte egentligen göra vad som helst - JavaScript och jQuery kommer att låta dig få knappar som du kan klicka på, och du kan dra element och åter ordning dem och sortera dem, och få nya element till eller tas bort. Du kan lägga till-delete, den sortens saker. Så, jQuery gör massor av coola saker. Och Vipul faktiskt ger ett seminarium om det i dag, tror jag, vid 5-klockan, så om du kan stanna kvar så länge, skulle det - 5 eller 4? Fyra. Ursäkta. Det är faktiskt direkt efter detta, så jag skulle rekommendera hålla sig runt för det om du kan. JQuery är super, super bra, och du kommer att kunna göra massor av riktigt fina saker med det för ganska mycket varje webbutveckling projekt. 

Nu ska jag komma in i form av en skillnad. Jag har pratat i grunden om användargränssnitt. Användargränssnittet är bara utformningen av webbplatsen. Men det blir liksom ett annat begrepp som är användarupplevelsen. De två är mycket olika. Interface är definitivt en del av upplevelsen. Med andra ord, när du går till en webbplats, du ser på gränssnittet. Det är en del av hur du upplever webbplatsen. Men användarupplevelsen är mer än så. Användarupplevelsen är vad intrycket att användaren får från din webbplats är. Så, naturligtvis, är gränssnittet en del av detta. Och det är definitivt en nödvändig del, men det är inte tillräckligt. Med andra ord, om du har ett trevligt gränssnitt, och det är ganska och färgstark och allt detta, det är bra, men om användaren går till din webbplats, ser en vacker layout och det är förvirrad av allt, har ingen aning om hur man gör något, uppenbarligen så har du gjort en riktigt dålig hemsida. Det blir liksom där användarupplevelse kommer in Jag ska prata lite om UX designen - UX står för användarupplevelse - och typ hur man kan se till att du har en bra användarupplevelse. Den första punkten är att du kan designa en hemsida där en användare kan göra något som att användaren eventuellt vill. Men om användaren inte kan lista ut hur man gör dessa saker - med andra ord, om användaren inte har en bra idé när de går till din webbplats på, "Åh, om jag vill uppdatera min profil, klicka jag på den här knappen, eller om jag vill lägga upp på någons vägg, då går jag till deras vägg och klicka på en liten låda. " Om användaren inte vet att, då du faktiskt har faktiskt inte genomfört denna funktion korrekt. En del av att genomföra en funktion är att användarna faktiskt kan använda den. Och det kan vara frustrerande - du kan göra en sida, och det kan göra alla typer av underbara saker, men då har du folk testa den och säga: "Det kan inte göra det här. Varför kan man inte göra det? "Och du kommer att säga till dem, "Ja, det kan. Det är bara att gå in i den 7: e rullgardinsmenyn på denna obskyra sida som bara hittas av en länk längst ned till höger "eller något. Självklart vill du inte det. Du vill att det ska vara klart för användarna vad de ska göra, och det bör vara enkelt och intuitivt för dem. 

En annan sak som du vill försöka göra är att, om någon kommer att gå till din webbplats och 9 av 10 gånger gör handling A, och 1 av 10 gånger gör handling B, du förmodligen vill fokusera sina erfarenheter om åtgärder A. Med andra ord, vill du göra det väldigt, väldigt tydligt hur man gör A. En bör vara front-och center - gå till platsen, ser det, åh, det är just där. Av följande skäl B uppenbarligen du vill vara tydlig, men du kan lämna det lite mer i bakgrunden. David ger ett bra exempel på detta i föreläsning, vilket är det Boston T-systemet. När du går till Boston T och du vill köpa en biljett, du måste komma in i fem menyer innan du faktiskt kan köpa en biljett för en $ 2, $ 2,50 värde, vilket är hur mycket det tar att åka tunnelbana i en riktning. Det är ett problem eftersom de flesta människor som rider tunnelbanan förmodligen bara vill gå till ett ställe, köper sin biljett, komma på direkt. Det är inte rimligt att de måste gå igenom massor av olika menyer att komma dit. En bättre användarupplevelse skulle vara en snabb knapp på första sidan som bara säger, "köpa en enkelbiljett," och som skulle sätta in alla standard standardvärden, och sedan om någon vill köpa en annan biljett än så, de fortfarande, naturligtvis, har möjlighet till, men du har optimerat för gemensam användning fall som verkligen är viktigt. Du kan se exempel på detta på Facebook, eller hur? Om du går till Facebook och du vill lägga upp en status, det är högst upp vilket är vad du ofta vill göra. Så fort du kommer in på sidan, kan du göra de vanligaste sakerna som du vill göra. Om du vill göra något mer komplicerade saker som, säga att jag vill åka till min kompis vägg och lägga upp en bild på den - som jag kommer att vilja göra ofta, men inte så ofta som att publicera statusuppdateringar - så i så fall, jag skriver deras namn i rutan högst upp, klicka på deras profil, och sedan, ändå är det högst upp där när jag har fått till sin profil. Återigen har jag optimerat i prioritet för de fall de vanligaste användningsområden. 

En annan viktig sak är att ofta människor kommer slags försök att komma runt detta genom att säga, okej, så jag har gjort på platsen och människor finner det förvirrande, och det är ett problem, eller hur? Självklart vill jag inte att folk ska bli förvirrade av innehållet på min webbplats. Men sättet att lösa det är att inte ha något dyker upp säger, hej, jag ska lära dig hur du använder denna webbplats. Steg 1 - klicka på denna knapp. Steg 2 - gå hit. Visst, det är en väg runt det - det är ett sätt att du kan tala om för folk vad de ska göra, men det är egentligen inte det optimala sättet. Om jag går till en webbplats, och plötsligt jag bombarderas med den här guiden som talar för mig vad man ska göra och vart man ska gå och allt det där, det är inte roligt för mig. Det är inte en bra erfarenhet för mig. Det är lite av en smärta. Jag vill bara börja göra saker. Folk kommer att stänga av deras dialogrutan eller få ut av läraren, inte vet vad de ska göra, och sedan klaga eftersom du inte har berättat för dem vad de ska göra. Sättet att lösa detta är inte genom att ge någon form av handledning eller riktningar - något liknande. Så mycket som du kan undvika det, du verkligen vill visa användaren vad som ska göras bara genom den typ av hur webbplatsen är anlagd. Med andra ord, om jag går till Facebook utan att logga in, det första som jag ser på huvudsidan - det är lite inloggningsruta. Så, duh. Jag måste logga in Det är rätt där. För om jag gick till Facebook och jag var tvungen att klicka på en liten länk längst ner som sade att "logga in" och resten av sidan var bara någon slags bild eller något, Jag skulle inte riktigt vad jag ska göra, eller hur? Jag skulle förväxlas. Så skulle det kunna tala om för mig att gå dit ner och klicka på knappen för att logga in, eller inloggningsknappen kan vara högst upp där jag ska se det. Du vill alltid att visa användaren vad som ska göras, och det borde vara inneboende i själva sidan. 

När du funderar på mönster och hånar upp olika sätt att uttrycka din webbplats, vill du verkligen att tänka på vad användarna kommer att göra och hur du kan visa dem vad de ska göra. En sista sak är att testa är riktigt, riktigt viktigt. Det är bra att få någon - få en vän, få någon som du inte vet ens - som aldrig sett platsen innan för att använda webbplatsen. Därför att du har arbetat på plats i timmar, du har stirrat på den, och du vet exakt vad du ska göra så uppenbart att du kommer att kunna testa saker som du har arbetat med och att du vet arbete. Men om någon annan kommer och använder sajten som aldrig har använt det tidigare, det är en unik upplevelse för att du har någon som inte har någon tidigare kunskap av platsen går in i den, så de kommer att ha ett effektivt ingen aning om vad jag ska göra eller vilken typ av användningsfall är närvarande för dem. Det är bra. Det är unika eftersom de är i grunden en person med en tomt för en själ. De kan berätta om något är förvirrande eller oklart. De kan ge dig en uppfattning om exakt hur användarens upplevelse av din webbplats är. Det kan vara väldigt svårt att säga det själv, så definitivt skulle jag uppmuntra dig som du utvecklar dina projekt - om du gör webbaserade projekt - att få folk att använda webbplatsen så tidigt som du har någon form av fungerande demo. 

Nu ska jag prata lite om hur man ska hantera ett webbutvecklingsprojekt. Vi har gått igenom hur man kan göra den tekniska back-end sidan, hur man kan utforma en riktigt bra plats, och det är bra om du arbetar själv men - även om du arbetar själv och speciellt om du arbetar på ett lag, projektledning blir en stor fråga. Du har sorts hört om projektledning i olika former sedan grundskolan när du fick höra grupparbete. Du måste samarbeta, kommunicera, allt detta. Det gäller alla fortfarande här, men det finns några unika förutsättningar med datavetenskap som du vill vara medveten om, och du vill vara säker på att du hanterar väl. Jag ska prata först lite om det lag som du ska vara i. Det är mycket viktigt att välja rätt storlek i ett team som arbetar med, och i ditt slutprojekt jag tror att du har möjlighet att välja mellan 1 och 4 personer, om jag är rätt. Du vill se till att du inte bara ska välja det antal personer som du vill arbeta med, eftersom de är dina vänner. Du vill välja ett lag som är en bra storlek och som kommer att få jobbet gjort. Det finns en avvägning i att ha fler människor kontra mindre folk. Om du har fler människor, kan uppenbarligen mer arbete göras eftersom du har massor av folk, massor av kod, massor av idéer, och det är allt bra. Men det kräver också mycket mer hantering och mycket mer kommunikation. Med andra ord, om du har 4 personer som arbetar med samma projekt och de är alla redigerar samma kod, mer eller mindre de alla slags behov av att veta vad som händer så det kräver att du - Om du lägger till några nya funktion du liksom måste berätta - jag lägger till detta, Jag ändrar det på det här sättet - speciellt om du kommer in i riktigt djupa grejer liksom de modeller och de styrenheter som faktiskt går att påverka hur webbplatsen fungerar. Hela laget måste vara medveten om det, så du måste se till att du inte ska välja för stort ett lag som kommer att bli hård att göra denna kommunikation. Du vill inte heller att välja en så liten grupp som du inte kommer att kunna kommunicera eftersom det är bara du. 

En annan sak att tänka på är balansen där människors kompetens är. Det är bra om du är alla riktigt bra programmerare. Men om du är alla back-end människor, då din webbplats kommer inte att se mycket bra eftersom du har denna stora databas, och det gör det supersnabba sökfrågor - vilket är bra - men när du går till det, det är som en 1990: s webbplats med rött och blått överallt, och det är inte bra heller. Lägg märke till att Ben och jag arbetar som ett team är mycket trevligt eftersom jag är typ av mer i fronten, vi båda samverkar i mitten-slutet, och Ben är riktigt bra med back-end grejer, så det fungerar riktigt bra att vi kan utforma en webbplats och i princip hålen på den platsen som behöver fyllas kan fyllas av någon av oss, eller möjligen båda. Du vill vara säker på att det inte finns några hål i ditt team. Det är okej om det är lite av överlappning. Med andra ord, om du har två personer som är både bra med bakdelen, det kan vara bra också, eftersom de kan hjälpa varandra med problem att de har. Det kan vara ett problem om du bara har 1 person som är ansvarig för en viss sak och de stöter på ett problem, så du vill ha en liten bit av överlappning men du framför allt vill vara säker på att alla möjliga hål är fyllda. 

Det sista - och det borde vara självklart, men det är ofta inte. Du vill verkligen ha kul. Poängen med denna sista projekt i CS50 och ofta den punkt av webbutveckling i allmänhet är inte att bara göra ett jobb, eftersom den behöver göra. Du vill verkligen att ha roligt, och du vill att göra något som är motiverande dig att arbeta på det. Om vad du än gör är jobbigt att sitta ner och arbeta på, då du inte ska välja rätt projekt. Du vill välja något som du tycker är intressant, du verkligen vill se resultatet, du är upphetsad när du får en ny idé om något man kunde göra - så det finns alla typer av projekt där som jag är säker på du kan hitta - alla har något som verkligen skulle intriger dem om de gör ett webbaserat projekt. Jag säger det igen just nu. Om projektet verkar vara en smärta och du inte vill arbeta på det, Välj ett annat projekt. Välj något som verkligen inspirerar dig. 

Ben nämnde detta begreppet iteration en bit, och jag vill gå över den lite. Det är verkligen viktigt att arbeta i spurter där du få något funktionellt. Det kan vara bra om du har denna plan för en webbplats som kommer att göra A, B och C, och till slut kommer dit. Men du är fast i denna fas där man jobbar på det och jobbar på det, men ingenting har blir gjort. Du behöver inte ha något att se och en konkret, funktionell sak. Vad du verkligen vill göra så mycket som det verkar lite av en smärta ibland arbeta med något och sedan sorts mössa bort det så att det är åtminstone på en stabil, kör version, även om den inte har alla funktioner du vill ha. Och kanske finns det vissa funktioner som du verkligen vill lägga till, men du kan bara inte eftersom du vill få hemsidan till en funktionell utgångspunkt. Och så du vill slags ha hela utvecklingsprocessen ser ut som det. Du vill börja någonstans funktionell - eller väsentligen börja med ingenting - men du vill komma någonstans mycket grundläggande och funktionella. Och sedan igen, gör en sorts hopp och få någonstans funktionell igen. Du kommer att långsamt bygga upp, och det kan gå lite långsammare än annars, men i det långa loppet, om du ständigt fastnat i denna medelväg fas där du egentligen inte har något arbete, kan det vara en riktigt stor frustration att arbeta på ditt projekt eftersom du är alltid så nära att få det att fungera, och det har aldrig faktiskt arbetar. Du vill arbeta i dessa funktionella spurter, och du också vill göra en del eftertanke efter varje. Med andra ord, när du är vid en punkt där platsen arbetar nu - det har inte allt du vill, men det gör vissa saker - du vill tänka, okej, är denna sida uppnå målet som jag föresatt sig att göra? Med andra ord, om platsen kommer att göra X, är vad jag har att arbeta i riktning mot X? Är alla de funktioner som jag ville ha det? Och dessutom är det tjänar det övergripande syftet som jag vill? Om du upptäcker att din webbplats börjar svänga i en annan riktning eller kanske saker bara typ av inte tränar, kan det vara dags att växla lite. Med andra ord, det är värt att överväga - det är värt att kasta fram idéer om det behövs och med tanke arbetar jag egentligen mot vad jag vill bli. 

Jag tror att det är min nästa punkt. Var inte rädd för att överge idéer. Bara för att du tillbringade många timmar arbetar på en funktion och slutligen fick det fungerar men det verkligen inte går så bra - som om det inte är så bra eller användare har problem med att använda det - den sortens saker - var inte rädd för att kasta bort det. Det suger att du har spenderat mycket tid att arbeta på det, men i slutändan du inte vill ha en webbplats som är typ av som satts samman av dessa bitar som typ av arbete, men är inte så väl. Dessutom, var inte rädd för att anamma nya idéer. Om någon kommer och säger, hej, den platsen ser riktigt cool men skulle det inte ens vara bra om det också gjorde detta? Bara för att det är något som du inte hade för avsikt och något som inte är i din specifikationer, något som du inte har föresatt sig att göra, var inte rädd för att ta på den och sedan arbeta med det. Eftersom ofta de idéer som du kör med under hela utvecklingen hamna de riktigt häftiga funktioner på webbplatsen. 

Jag har sagt det förut. Jag säger det igen. Testare är super, super bra. Försök att få folk som aldrig har sett platsen innan för att logga in och se vad som händer eftersom de kan inte bara testa användbarheten av webbplatsen och användarupplevelse, men de kan också testa funktionen på ett sätt som du inte kan. Om du gör någon funktion som gör en viss sak och du vet att det kommer att göra samma sak på rätt sätt varje gång, det är bra. Men det kan ofta vara svårt att ta hänsyn till hörn fall där en användare kan skriver något som du inte väntade - just därför att du definierat funktionerna själv. Så, för att ha någon komma på som inte har någon aning om hur man använder webbplatsen och att bara bryta det på något sätt de kan göra är verkligen användbart eftersom du få en idé från ett helt annat perspektiv på vad på din webbplats fungerar och vad som behöver repareras. 

Slutligen kommer jag att tala om några generella god praxis, och du har sett en hel del av dessa i CS50, men också verkligen, verkligen gäller i en miljö projekt. En är kommentarer. Comment alltid din kod speciellt om du arbetar på ett stort team. Det kan vara så irriterande att bara ha en jätte block av kod som någon har skrivit och kanske det fungerar, kanske inte, men du har ingen aning om vad den gör, så du har ingen aning om det är bra eller inte, eller om det ska vara där eller inte, och om du arbetar på något annat är det ens möjligt att du arbetar med samma sak, så det är bara att vara väldigt, väldigt noga med att vara omtänksam mot dina kamrater och skriva kod som är väl dokumenterade. Du behöver inte gå så långt som att göra det hela där gillar om du ökar en räknare har en kommentar som säger, jag lägger till 1 till den här disken. Det behöver inte vara så detaljerat, men för någon funktion som du någonsin skriver Du bör ha någon dokumentation om vad som fungerar exakt gör, vad dess ingångar är, och vad den ska visa. Så att du kan använda andras delar av webbplatsen och du kan arbeta för att skapa något stort. 

En annan viktig sak är att du vill göra regelbundna rengöringar. Code blir rörigt. Känn dig inte illa om din kod är bara helt oläsbart och en gigantisk röra. Det händer i webbutveckling alltid. Du lägger till nya funktioner, ta bort gamla. Saker kommer att vara där som inte borde vara. Det är bra, men du vill vara säker på att ta itu med det regelbundet. Du vill inte låta det bygga upp till den punkt där du inte kan hitta något i koden, och du har ingen aning om vad som helst gör. Det är fallet med HTML. Ibland kommer du att sluta med föremål som inte innehåller någonting, och du vill bli av med dem. I CSS, kan du hänvisa till element som inte finns längre, så du vill bli av med denna kod. I JavaScript, kanske du har tagit bort något från HTML. Så, vill du vara säker på att du alltid städa upp, göra saker ganska så mycket du kan på en regelbunden basis. 

En annan riktigt bra sak som jag inte tror är skisseras mycket i CS50 men det är värt att komma in är versionshantering. Idén om versionshantering är när du i princip hålla reda på alla framsteg du har gjort till din webbplats och om det vid något tillfälle du inser, åh, detta arbetade ett tag sedan men det inte fungerar längre, kan du gå tillbaka till tidigare versioner och se vad som har förändrats sedan dess och sånt. Det primära sättet att göra det är med Git, och Git är hela denna typ av system som Jag tror Tommy MacWilliam gav ett seminarium om förra året. Om du går in i CS50 seminarier för 2011, kan du se hans seminarium på det. Idén med Git är i grunden att regelbundet du gör dessa åtaganden vilka är sätt att säga platsen är i en ganska stabil version just nu så Jag förpackning upp den och skickar den iväg till en server, och sedan kan du gå till den servern och titta på alla tidigare versioner av din kod och se hur det har gått och alla den sortens bra grejer. Så, det är i princip det. När det gäller webbutveckling, vi är glada att stanna kvar och svara på alla frågor så långt som vår presentation. Det var allt. Tack. >> [Ben] Tack. [Applåder] 

[Billy] Personal, är det någon som har några frågor om saker som vi har täckt eller saker som vi inte har täckt att de hoppades att vi skulle täcka? Vi skulle gärna svara på dem. Någon? [Publiken] Vilka är för-och nackdelar med att använda Ruby eller använda Python? [Ben] Frågan var, vad är för-och nackdelar med att använda Ruby eller Python istället för som PHP. Proffsen är att Ruby och Python är mycket bättre språk än PHP. Åtminstone i min mening, och jag tror på en massa andra människors åsikter också. De var utformade mer för att göra komplicerade saker, och mindre för handtralla tillsammans webbsidor riktigt snabbt med lite av dynamiskt innehåll. Nackdelarna är att det finns en liten bit av - det är mer av en inlärningskurva att få dem att bygga upp. Det är, liksom i PHP, kan du bara ha en HTML-fil och du skriver mindre än, frågetecken, och sedan skriva lite kod, och sedan skriver du frågetecken, större-än, och sedan är du klar. På andra språk som Ruby eller Python, du måste gå igenom lite mer arbete för att få den första platsen igång. Det finns också - åtminstone det brukade vara fallet - att det finns mer dokumentation tillgängliga för PHP bara för att det finns fler människor som använder det. Jag tror att det är inte så mycket en fråga längre. Det finns verkligen mycket bra dokumentation för saker som Ruby on Rails eller Django för Python är motsvarande. PHP är den som alla har använt i flera år, och du vet hur det fungerar. Ruby och Python är lite mindre mogen. 

[Publiken] Om du skulle välja mellan någon av dem att lära sig eller plocka upp, vilket skulle du föredra? Ärligt talat, jag tror att det beror på personen. Jag är ledsen. Frågan var vilket skulle du välja för någon att lära sig? Jag tycker Python den trevligaste personligen. Det finns en massa människor som - Jag gjorde min första web dev projekt i Python och Django. Det finns en massa människor som gillar Ruby on Rails också. Förmodligen fler människor som känner Ruby on Rails. Ärligt talat, jag skulle bara gå med vad människor runt omkring dig vet så att du har folk att ställa frågor. 

Frågan var - på delade servrar är det ganska svårt att arbeta med Python? Det beror på ditt webbhotell. Det finns ett antal webbhotell som kommer att lägga upp Python grejer. Webfaction gör det, eller hur? Webfaction är en som Billy och jag har använt för vissa projekt. De är riktigt bra. De stöder de flesta språk. Men det är sant att PHP är mycket brett stöd. Så, om du har fastnat på ett webbhotell som bara gör PHP, det är en bra anledning att använda PHP. 

[Publiken] Jag kom precis på att lära sig att fråga några databaser, och jag vet att min SQL är överallt, men jag nyligen blev utsatt för - och du påpekade det. Du ser JSON och expanderbara databaser. My SQL är fortfarande överallt. Hur ser du på det som händer? Kommer det att bli en allt större tendens till mer utbyggbart (ohörbart)? Frågan var - tror jag att det kommer att bli en trend mot icke-SQL-databaser. Till exempel, som MongoDB. Jag tror det är definitivt sant. Mitt råd var mestadels mySQL relaterade här bara för att MySQL är branschstandard. Personligen föredrar jag mycket databaser som inte har schemos som MongoDB där du inte har frågan om, åh, jag behöver lägga till en kolumn. Ve mig, liksom vad gör jag? Det är väldigt svårt att göra det på MySQL, men när du har något som Mongo det är mycket trevligare. Den andra fina Mongo är att dina poster är faktiskt JavaScript-objekt. Det finns ingen typ av omvandlingssteg där du måste ta dessa databasrader och förvandla dem till ett JavaScript-objekt och sedan skicka dem över tråden. Jag tror att sånt kommer att bli mycket, mycket användbart för snabb webbutveckling i framtiden. 

[Billy] Något jag skulle lägga till som är bara en allmän punkt är att inte känna att du borde ha lärt sig alla de språk som vi har diskuterat från vårt seminarium. Uppenbar poängen är att ge dig en uppfattning om vad som finns där ute, och om du är nyfiken på någon av de saker vi har nämnt kan du Googla dem och läsa på dem. Och som jag nämnde, finns det några seminarier som behandlar just dessa saker. Det finns ännu fler seminarier som jag inte har nämnt det förmodligen komma in det här också. Tanken är att om du vill arbeta på något, här är de verktyg till ditt förfogande. Känn dig inte överväldigad om du inte är riktigt säker på vad dessa verktyg gör exakt, men vet att de är ute och att du kan göra omfattande användning av dem av Google. 

[Publiken] Vilken typ av saker du behöver göra för att se till att din webbplats ser bra på mobila enheter? [Billy] Mobila enheter är lite svårt. Det finns två sätt att närma sig den. Det första sättet är att du faktiskt har en mobil webbplats. Med andra ord, gör du något slags upptäckt i början när webbläsaren gör förfrågan till din webbplats som antingen säger returnera denna uppfattning - som kommer att vara den vy för stationära eller bärbara webbläsare - och det andra vy för mobila enheter. Det är en plats där åsikter är verkligen trevligt att du kan ganska mycket swap den två ut och har ett gränssnitt som fungerar riktigt fint på mobila enheter och har en helt annan en som fungerar fint på läsar enheter. Problemet med det är att det tar lång tid eftersom det innebär kodning ett helt annat gränssnitt. Det andra sättet som du kan göra det är - en hel del moderna telefoner kommer att visa webbsidor och försöka göra dem som en webbläsare skulle, och de gör sitt bästa. Du kan slags försök att stanna ljus på mängden jQuery JavaScript du använder som tenderar att vara där saker kan gå fel lite. Detta är en slags det sätt som du bör använda om du inte har så mycket tid. Om du har tid att arbeta på ett mobilt gränssnitt, det är uppenbarligen det bästa alternativet. 

Jag tycker generellt för CS50 projekt, du kommer att vilja välja det ena eller det andra. Med andra ord, vill du göra en mobil app eller om du vill göra en stationär webbplats. Och den sortens avgör var du än går med det. Men om du vill bygga ut den senare, förmodligen din bästa insats är för att göra ett annat gränssnitt för den andra. Jag har lite erfarenhet av att utveckla Wordpress-baserade webbplatser. Jag var värd en personlig hemsida på Wordpress för en stund. Dessa typer av ramar kan vara trevligt lika mycket grundläggande saker. Ofta kommer du bara stöta på en hel del customizability frågor ändå. Du vill ha något som ser ut på ett visst sätt eller vara på ett visst sätt och du kan bara inte för att det är fastprogrammerade i systemet som detta är hur du måste göra saker som kan vara lite av ett problem. Sedan dess har jag typ av varit mer benägna att arbeta med webbplatser från grunden. För saker som blogg databaser och sånt det är verkligen inte så svårt att bygga en ram. Om du verkligen sträckt för tiden, kan du naturligtvis använda något som Wordpress eller sånt för en blogg. Den typ av saker som bloggar butik och gör är egentligen inte svårt nog att om du kör in i någon av dessa typer av saker, är du förmodligen bäst att bara göra en egen version. 

Jag tror att det är om det, så tack igen för att du kom. Vi gillade verkligen prata med er och hoppas att ni lärt lite grejer. [Ben] Vi är glada för att prata - vi måste gå men vi är glada för att prata mer utanför om du har en annan fråga. Tack igen. [Applåder] [CS50.TV]