[Powered by Google Translate] [Seminar] [Web Development: van idee tot uitvoering] [Ben Kuhn] [Billy Janitsch] [Harvard University] [Dit is CS50] [CS50.TV] [Billy] Hoi, ik ben Billy en dit is Ben. >> [Ben] Hi. We gaan praten over web development vandaag. [Webdev] [Billy Janitsch en Ben Kuhn] Een beetje over ons eerste. Ben is een soort van de back-end vent. Hij maakt dingen werken. En dan ga ik in en maken ze mooi. Ik ben voornamelijk bezig met meer front-end lay-out ontwerp soort dingen, en Ben, aan de andere kant, weet wat hij doet, zodat hij werkt op back-end spul. Samen hebben we een paar dingen. Bijvoorbeeld, vorig jaar hebben we gewerkt aan Gimblium dat is een online game development studio. Dat was onze laatste project voor de klas, en sindsdien hebben we Harvard klasse hebben gemaakt dat is een online kader voor browsen en winkelen cursussen op Harvard. 

We gaan beginnen met dit idee voor onze website. We gaan naar Facebook te maken, maar voor katten. Voordat u daadwerkelijk deze website, u deze website niet te maken, want het is niet goed, maar we zullen het gebruiken als een kader en gaan door het proces van hoe we dit idee en zet hem in een echte website die we kunnen gebruiken. We beginnen met het breken van de website naar beneden. Zoals je hebt gedaan in CS50, je wilt nadenken over wat zijn de werkelijke componenten die verder gaan in deze website. Het in principe draaien vanuit een idee dat is gewoon soort van een abstract begrip in een echt, tastbaar ding dat je zou kunnen maken. We beginnen met een aantal vragen. Wat is deze website? Waarom maken we het? Wat gaat het worden gebruikt? Dat soort dingen. Bij Facebook Cat, we eigenlijk willen een website die katten sociale netwerk kunnen met elkaar. Het idee is dat ze kan plaatsen op muren elkaars ze kunnen commentaar, dat soort dingen te maken. En dat is waar we in de functionele componenten komen. We hebben nu dit soort kader van - we hebben gebruikersprofielen, we hebben commentaar, en we kunnen plaatsen. Misschien op een dag zullen we sympathieën en dat soort dingen behoud hiervan. En we soort van deze mogelijkheden wilt naar binnen te prioriteren We willen zeggen zoals, oke, het is echt belangrijk dat iedereen een profiel en dat iedereen kan posten op muren elkaars. Secundair aan dat, zou commentaren mooi zijn. Misschien later zullen we houdt behoud hiervan. Dus, wilt u een idee van wat er fundamenteel voor uw project en wat is een soort van een meer algemene functie die later kan worden toegepast. U wilt een soort van een specifieke lijst in het achterhoofd, maar het project dat je begint met is niet van plan om het project dat u klaar bent met zijn. Met andere woorden, dingen gaan veranderen terwijl je de site aan het ontwikkelen bent, en je wilt om ruimte te laten voor. Ik zal het woord aan Ben die gaat een beetje te praten over structuur. 

[Ben] Ik ga het hebben over de meer technische kant van webontwikkeling. Laten we gaan over een aantal basics eerste. Als je doet een web-app, de belangrijkste divisie die je gaat moet hebben is je gaat wat dingen gaande in de client-side hebben - dat wil zeggen, de code die je browser neemt van de site en de JavaScript, HTML, CSS spul. Dat is alles wat op de client zijde. Je gaat andere code die op de server draait hebben die bijhoudt van alle gegevens die mensen sturen om u, beslist wie wat, dat soort dingen geven. Dit is slechts enkele terminologie, zodat jullie allemaal vertrouwd zijn met wat we over praten. Voorbij die afdeling is het goed om na te denken van uw web-app in termen van een paar van de afzonderlijke componenten. Als je doet webontwikkeling een van de dingen die je altijd moet proberen te doen is om de complexiteit te verminderen. Hoe complexer de code is het meer kans er is om bugs te maken, hoe moeilijker het is om later te veranderen. Dus, als je kunt breken uw app in een aantal verschillende functionele gebieden dat zal - en je kunt het soort hoeveelheid cross-area communicatie verminderen - dat zal u helpen een hoop op de lange termijn in termen van vermindering van bugs. 

Om concreet te zijn, meestal mensen verdelen een web app in - zijn dit soort buzz woorden nu, maar ze zijn nog steeds nuttig. Misschien heb je mensen horen praten over modellen, views en controllers. Modellen zijn de feitelijke gegevens die uw app gaat behandelen. Bijvoorbeeld, in uw Cat Facebook, zou je modellen - zou je een model voor, zoals berichten, en een model voor gebruikersprofielen, dat soort dingen hebben. Uw mening is hoe presenteren u deze gegevens aan uw gebruikers. Je zou 1 oog voor het kijken naar een enkele post en alle opmerkingen hebben en een andere kijk voor je muur die een lijst van alle berichten heeft die gericht zijn aan u, en een andere kijk voor je nieuwsfeed - dat soort dingen. Tot slot, heb je de controllers die in feite zijn als mensen om u berichten en je updates om uw back-end systeem te maken, je een heleboel tellers verhogen, en wat dan ook. Dat zijn je controllers. 

Ik ga vooral praten over modellen. Bekeken zijn technisch niet zo moeilijk en het probleem is meer met ze te ontwerpen Controllers gaan specifiek voor wat je het ontwerpen zijn. Maar er zijn een aantal mooie algemene technieken die u kunt gebruiken om uw modellen mooier en makkelijker om mee te werken die volgens mij zeer nuttig maken. Dit wordt meestal gaat worden over hoe om te gaan met uw web-apps gegevens op een leuke manier. De belangrijkste kwesties met modellen zijn dat ze leven op de client en de server en je moet uitzoeken a) hoe ze te krijgen - alle relevante degenen - van de server naar de client, en b) hoe ze te synchroon te houden. Uw gebruikers zullen willen wat updates te maken. Ze zullen willen nieuwe berichten maken. Ze zullen willen dingen en dat soort dingen als je wil. Dat zijn de belangrijkste technische uitdagingen van omgaan met modellen. Het eerste dat je gaat jezelf wilt stellen is wat voor gegevens gaat in dit model en wat voor soort vragen gaan we willen doen - dat wil zeggen, hoe gaan we kijken naar de modellen? Voor uw kat Facebook bijvoorbeeld, uw post gaat naar een auteur verbonden aan, sommige muur na tekst, en een ontvanger van de muur na. En dan wilt u misschien te vragen dat in een heleboel verschillende manieren. Je zou willen kijken door wie welk bericht heeft geschreven, door die ontvangen die posten, misschien door de datum waarop ze zijn geplaatst. Maar als je gaat om het te doen op datum, dan moet je een ander veld toe te voegen aan je bericht wanneer het daadwerkelijk is geplaatst. Deze 2 factoren - welke gegevens u wilt gebruiken en hoe je het wilt bekijken - je moet eerst over hen denken, omdat ze afhankelijk zijn van elkaar, en het zal moeilijker zijn om ze later toe te voegen. 

Er zijn een aantal andere overwegingen. Wanneer u denkt over hoe je omgaat met modellen op de server wat je wilt kijken is - je eigenlijk wilt dat de server zo eenvoudig mogelijk te maken. Dingen doen op de client zijde is over het algemeen veel sneller als je het puur kan doen op de client zonder enige vorm van verzoek van het netwerk. Het idee is om zo veel van de vragen als je kan op de client doen. Het enige probleem met dat is dat als u een verzoek alle gegevens aan het begin dan dat gaat een lange tijd om te laden. Dus, het idee is om een ​​middenweg te vinden tussen het hebben van voldoende gegevens over de cliënt die u het meest van uw werk kunt doen daar, maar niet alleen ophalen alles in een keer zodat je echt lange laadtijd aan het begin. Bijvoorbeeld, voor uw kat gegevens zou u waarschijnlijk willen een heleboel recente prikbordberichten halen. Je zou niet willen om ze allemaal te halen, want dat kon terug een paar jaar. Maar je wilt niet dat ze een te halen op een moment want dat zou veel van het netwerk overhead introduceren. 

Het is vaak heel moeilijk - als je eenmaal een database onder - is het vaak heel moeilijk om te veranderen welke data je hebt in het - dat wil zeggen, voeg een nieuwe database kolom of iets - dus een goede strategie is eigenlijk alleen maar om veel van uw gegevens in een tekst blob te houden - een JSON blob - JSON dat JavaScript Object Notation - De reden dat het handig is want dan kun je nieuwe eigenschappen toe te voegen om al deze JSON blobs zonder de database te veranderen. Het enige nadeel daarvan is dat als je een heleboel velden die u hebt toegevoegd later - zoals verborgen in dat JSON blob - dan is het moeilijker om ze een query in de database. Bijvoorbeeld, als je later - als je je post model hadden dat we eerder besproken met alleen de auteur, de ontvanger en de tekst - je zou ook een JSON blob en dan als je later wilde een datum veld toe te voegen zou u niet om uw database te veranderen. Je kon gewoon data toe te voegen aan alle van de tekstvelden. En dan zou je kunnen kijken naar die op de client zijn, maar je zou niet in staat zijn om ze te doorzoeken op de server want het is verborgen in die tekst. 

Het andere probleem dat u wilt nadenken over is hoe uw klant en uw server gaan communiceren. Je meestal willen dit zo eenvoudig mogelijk te houden. Je kunt gewoon als een get-me-deze gegevens verzoek, een create-a-new-object ding, en een verzoek actualisering-een-oude-object. En dat zal dan uitsluitend verschillende URL's op een server die u - dat de browser zou - u AJAX verzoeken te gebruiken voor al deze en ofwel te ontvangen of post gegevens. Nogmaals, voor onze Cat Facebook bijvoorbeeld, kon je dat URL moet een afzonderlijk bericht te krijgen, en je zou een URL hebben voor het creëren van een nieuwe muur bericht en misschien een URL voor het uploaden van uw profielfoto, dat soort dingen. Maar nogmaals, dat is een pre-fetch meeste van uw gegevens, zodat u niet hoeft te houden maken van het netwerk verzoeken. Om die reden, zou je niet willen dat individuele krijgen verzoek om een ​​enkele post hebben, en in plaats daarvan zou je gewoon wilt 1 get verzoek om de hele muur. En dan als je probeert om een ​​evenwicht omdat - dit gaat ook afhangen van uw aanvraag. Want als je verwacht dat mensen slechts 10 of 20 prikbordberichten dat komt wel goed. Maar als je verwacht dat ze zullen duizenden hebben dan is dat verzoek zou te lang duren, en dus je zou willen om een ​​get-alle-berichten-sinds parameter toe te voegen. 

Voor al deze je waarschijnlijk gaat om uw gegevens wilt synchroniseren in JSON - JavaScript Object Notation. Vrijwel elke taal bezighoudt met JSON zeer goed. JQuery heeft deze mooie getJSON functie dat al het harde werk voor u zal doen. En op PHP er is ook heel mooi JSON communicatiefuncties. Dus, dat is waarschijnlijk het beste formaat voor het verzenden van uw modellen heen en weer. 

Als voorbeeld van wat we hebben gesproken over tot nu toe, hier is een voorbeeld-stroom voor uw Cat Facebook applicatie. Het begint met uw browser vraagt ​​de basis URL van de website. De server waarschijnlijk zou sturen over statische HTML-en JavaScript-en CSS. Het is meestal het beste elke weergave op de server niet te doen. U heeft waarschijnlijk niet willen - wat de server is er niet te doen gaat de lijst van muur berichten en het genereren van een aantal HTML-code voor een ieder en het verzenden van dat voorbij. Het is meestal het beste om dat te doen op de client, omdat anders elke keer dat u opnieuw wilt tekenen iets, moet je een server verzoek. En dat heel snel geeft je veel overhead. Het is meestal het beste gewoon schip zendt statische HTML en dan JavaScript en CSS die de rendering doen op de client. Zodra dat spul komt, dan je kunt hebben - in JavaScript - u kunt verzoeken doen voor de muur gegevens en dat soort dingen, en na dat de server is eigenlijk gewoon doen database queries en het controleren van machtigingen. Het enige belangrijke is dat het niet kan versturen over een aantal andere gebruikers prikbordberichten dat je niet mag zien. Het kan een zeer dunne laag voor toegang tot de database in principe zijn, en dan al het tonen van de gegevens - alle standpunten en Simon - die kunnen gebeuren in uw browser, en dan als je wilt een bericht of iets maken stuur je gewoon een ander verzoek. 

Er is ook een aantal mooie dingen die je kunt doen op de top van dit. In termen van meer specifieke technische informatie, ontwikkelen in gewone JavaScript kan een beetje pijnlijk, dus er zijn een aantal bibliotheken en tools die u helpen een hoop mee. Ik denk dat je waarschijnlijk allemaal gehoord over jQuery waardoor doen HTML rendering en manipulatie een stuk makkelijker - hebben veel luxe functies voor het vervagen in en uit, en het doen van zippy animaties. Er is ook deze bibliotheek genoemd Underscore.js. Het heeft een heleboel nuttige nutsfuncties, dingen die je zou verwachten JavaScript te hebben dat het echt Doesnt - dingen zoals schuifelen een array, het verwijderen van duplicaten uit een lijst, of afvlakking een lijst van lijsten. Dit is slechts een klein voorbeeld code. Underscore heeft een ton van deze mooie functies die je zou willen dat je de hele tijd te hebben. 

En dan is er nog 1 bibliotheek die ik zou graag een beetje tijd te besteden aan genoemd Backbone.js omdat Backbone echt helpt je om met modellen op de client en veel van de verwarring kan veroorzaken. Backbone geeft u dit concept van modellen en collecties in JavaScript die in feite zijn precies hetzelfde als JavaScript-objecten in JavaScript arrays maar ze hebben gebeurtenissen wanneer je hun eigenschappen veranderen. Net als in JavaScript, kunt u een gebeurtenis wanneer een knop wordt geklikt of iets deze Backbone modellen en Backbone collecties zullen dingen als uitzenden dat wanneer ze veranderen. Dat betekent dat je gewoon zoiets als dit stukje code kan schrijven hier - dit zegt, wanneer je iets toe te voegen aan de berichten matrix je de hele muur opnieuw te tekenen. En dit zou zeggen wanneer een post nummer 'likes verandert, u de gebruiker dat iemand graag hun post te melden. Of wanneer een eigenschap van een bericht wijzigt u de post opnieuw te tekenen. Dat soort dingen zullen u want anders redden ton complexiteit als je geen enkele kader als dit dan elke keer in je code die je verandert iets over een post, zou je moet jezelf niet vergeten om alle renderen functies aanroepen en dat soort dingen, en als je wilde iets nieuws dat gebeurd voegen elke keer dat u een bericht bewerkt zou je moeten gaan door elke plaats in uw code die u een bericht bewerkt en voeg dat nieuwe ding. Een kader als deze zal veel van dat tussen-layer communicatie verwijderen dat maakt uw code complex en moeilijk te handhaven. 

Er is een klein beetje over uitzicht ook. Ik ga het grootste deel van dit over te laten aan Billy omdat ze technisch niet erg moeilijk. Gebruik jQuery voor uw standpunten. Het is bijna als een noodzaak op dit punt. Het maakt alles zo veel makkelijker. Er zijn veel bibliotheken. Als je user-interface-elementen zijn ingewikkeld, als je wilt een auto-complete ding of van een van die chique multi-selectors - als je zoiets wilt, moet je waarschijnlijk gewoon zoeken rond en je kunt een goede bibliotheek die zal doen wat je wilt vinden. Billy zal meer uitleg geven over het eigenlijk moeilijk delen van standpunten. Ook, zoals een kanttekening, Backbone heeft een aantal functies voor het maken van visie geven mooi met modellen - kijk naar de documentatie voor al deze bibliotheken, eigenlijk. Kijk maar naar de docs. Ze zijn zeer goed geschreven en gemakkelijk te volgen. In het algemeen kun je vrijwel alleen Google als je problemen hebt. Er zijn een heleboel mensen gebruik van maken. Ik denk dat dit als een laatste opmerking. 

Er zijn ook enkele meer geavanceerde dingen die je kunt doen als u op zoek bent naar uw web-app extra awesome. U kunt dit doen - de nieuwe HTML5-specificatie heeft een heleboel mooie dingen die je kunt doen. Lokale opslag - die u kunt opslaan van gegevens in de browser - in plaats van terug te gaan en kennisnemen van de server voor alles, je kunt er wat van op de client te houden en dat ook laat mensen - in sommige gevallen zelfs kan laten u de webpagina offline te gebruiken. Er is dit ding heet WebSockets die een ander soort netwerk communicatie zijn waar in plaats van dat je een verzoek doen, antwoord krijg je en je bent klaar, je blijft een verbinding met de server te openen en dus kun je dingen doen, zoals real-time updates. Dus, als je probeert om een ​​praatje app te maken, je kon WebSockets gebruiken om heen en weer te communiceren, zodat je niet zou moeten blijven aanvragen, "Oh, server, heeft iemand stuur me een praatje? ' elke 10 seconden of zo. Er is ook een interessante HTML5 functie waar je kunt laten lijken de URL van de pagina verandert, zonder ooit te hebben om daadwerkelijk te herladen. U kunt back gebruiken en knoppen doorsturen zonder het doen van een stelletje netwerk verzoeken. Dat soort dingen is erg handig in termen van het maken van het snelle maar ook werken als een web app zou moeten. 

Er is ook dit ding heet CoffeeScript. CoffeeScript is een andere taal, in feite, dat compileert omlaag naar JavaScript. Je zou al uw code te schrijven in CoffeeScript, en dan heb je deze compiler draaien, en hij spuugt een JavaScript-bestand dat u kunt opnemen in uw webpagina. De reden dat CoffeeScript is leuk is omdat het zich ontdoet van een groot deel van de rare gevallen dat JavaScript heeft waar gelijk gelijken, en is gelijk gelijken doen verschillende dingen, of willen - het heeft mooiere syntax voor het omgaan met arrays en functies. Dit is een klein fragment van CoffeeScript dat een lijst van alle pleinen produceert 10 ^ 2 naar 1 ^ 2 in omgekeerde volgorde. Zoals u kunt zien, CoffeeScript laat vaak je uitdrukken in 1 lijn wat 5 regels JavaScript zou nemen. Het kan dingen een stuk makkelijker maken. Het is een beetje van nieuwe syntax te leren op het eerste, maar het is zeker een hogere productiviteit op de lange termijn zal maken. 

U kunt ook gebruik maken van andere talen op de server dan PHP - talen zoals Ruby, Python, of er is zelfs een project genaamd Node.js dat laat je JavaScript gebruiken op de server. Persoonlijk ben ik echt een hekel aan PHP. Ik heb gewoon niet genieten van het werken met het. Als je ook denken dat het een vreselijke cluge van een taal, dan kun je in plaats daarvan gebruik van een van deze. In het algemeen, als je iets wilt doen en je weet niet echt hoe je het zou doen, gewoon zoeken op het internet. Er zijn tonnen en tonnen van middelen vooral op - StackOverflow is een geweldig. Het is deze website waar programmeurs elkaar vragen. Je zou kunnen hebben tegenkomen als je problemen hadden met het op CS50 probleem sets. En er zijn vele bibliotheken voor vrijwel alles wat je zou willen doen. Als je iets wilt doen en je weet niet hoe dat te doen, ga er niet vanuit dat het onmogelijk is. Gewoon rond te kijken en je zou een aantal goede middelen te vinden. 

Als algemene wrap up, de belangrijkste afhaalrestaurants zijn dingen eenvoudig te houden. Hoe complexer uw code is aan het begin en hoe meer je probeert te doen fancy dingen, hoe langer het duurt om iets daadwerkelijk functioneel te krijgen en hoe moeilijker het zal zijn om later te veranderen. Dus, doe dingen eerst de domme, gemakkelijke manier. Om mee te gaan met dat, wees niet bang voor het weggooien van oude code of op te ruimen veel. In het algemeen, als je eigenlijk iets werken, het is veel makkelijker om na te denken over dan wanneer je nog in de beginfase hoe zet ik dit allemaal samen. Het beste is om de domste mogelijke ontwerp dat werkt maken en te verbeteren vervolgens iteratief dan te proberen om alles goed te krijgen de eerste keer. In termen van client-server-divisie, proberen en houd je server heel eenvoudig - slechts een databank en een aantal authenticatie en geen harde werk daar doen. Doe al je ingewikkelde dingen op de client in de browser in JavaScript zoveel als je kunt. Kijk rond voor bibliotheken die u het leven aangenamer te maken. Altijd beter om code te gebruiken die iemand anders heeft geschreven als u - en niet om het zelf te schrijven. Er is een heleboel dingen op het internet. Google is je beste vriend. Google is de beste vriend van de programmeur. Ja, zeker niet bang om rond te kijken naar spullen. Oke. En over Billy. 

[Billy] Eigenlijk, voordat ik begin met een aantal ontwerp spullen, Heeft iemand enig vragen voor Ben over alles wat hij sprak over? Oke, goed. Nogmaals, laat het ons weten als er iets niet duidelijk is of als u wilt dat wij gaan over iets een beetje meer. Ik ga een stap terug een beetje en praten over de meer fundamentele onderdelen van het ontwerp. Ben hebben het model genaamd - sorry, het model controller view systeem dat is een soort van het technische aspect, dus ik ga kijken naar uitzicht specifiek, en ik ga beginnen met hoe je zou het ontwerpen van een standpunt dat er mooi uitziet. Hier is wel een heel basic template voor onze Cat Facebook. Ik denk dat er een aantal basisvoorwaarden in moderne UI-ontwerp die de moeite waard oppakken zijn. Je kunt merken dat er veel witte ruimte over de hele pagina, voldoende ruimte voor de dingen. Niet het gevoel dat je dingen squash in een pagina. U wilt veel ruimte open te laten, en als je naar vrijwel elke moderne website je zult zien dat er overal wit. Er is wit in plaatsen je niet zou verwachten. Je hebt dit kleurenpalet, en het is verstandig in het begin een kleurenpalet dat je gaat om te werken met en te ontwikkelen kiezen. U kunt ook - het helpt om een ​​lettertype kiezen, en op die manier je soort van werken met deze concrete fundamenten van het ontwerp. Je hebt je type, heb je je kleuren, en dan kan je soort van past alles in als dat nodig is. Dus, zoals ik al zei, met uw kleurenschema dat u wilt de bolder kleuren van uw kleurenschema gebruiken spaarzaam. Headers zijn mooi. Knoppen zijn mooi om echt te groot, flashy kleuren hebben. Maar in het algemeen, als je een website die kleuren heeft overal, alle staren je in het gezicht, het ziet er gewoon rommelig, en het is niet goed. U wilt het algemeen gebruik van lichte kleuren. Probeer, opnieuw, kies een mooi samenhangend kleurenschema. U kunt deze kleine spatten van veel kleur hebben - die kan kijken vrij aardig, maar je wilt ze vrij spaarzaam gebruiken. 

Zoals ik al zei, je wilt minimaal. Minder is bijna altijd meer. Als je iets kunt weergeven of niet weergeven iets, en je bent soort van onzeker of alles moet er standaard - Waarschijnlijk kun je het beste het verlaten van het uit. U kunt altijd in later. Ja, de dingen eenvoudig te houden. Maar belangrijker nog, u wilt meerdere ontwerpen te overwegen. Denk niet dat als je een site te maken, heb je het in je hoofd dat je gaat maken van de site op een bepaalde manier, en het gaat om te kijken precies zo. Het gaat om de blauwe balk aan de bovenkant en de blauwe kant bar en dan de gele sub-header ding. U wilt meerdere sjablonen te maken. U kunt - als je goed met Photo Shop bent, u kunt openen die op en soort het ontwerpen van een website als je het leuk om te kijken. Zo niet, kunt u gewoon gebruik maken van pen en papier, maar krassen meerdere ontwerpen. U wilt in principe een set-up waar je veel verschillende designs, en als men eindigt werken, dan is dat geweldig. Als men uiteindelijk niet, dan heb je altijd een ander te wenden tot. In het algemeen, niet het gevoel dat je moet worden beperkt naar wat ontwerp dat u in eerste instantie beslissen over. Ontwerpen zijn zeer variabel, en een deel van het belang van het model controller view systeem is dat je kunt wisselen in en uit verschillende weergaven die u wilt. U kunt de gegevens zwaaien op een manier, en dan beslissen, oh, eigenlijk, dat die goed werkt niet. Ik denk dat het soort van te ingewikkeld of er is hier een rol die niet echt werkt, dus ik ga gewoon steek te laten, dit standpunt en swap in een totaal nieuwe. We kunnen nog steeds gebruik maken van de oude modellen en de oude controllers. We kunnen alles doen op de server en client als we zou eerder. Maar de werkelijke golf van de gegevens weergegeven zal iets anders zijn. 

Voor zover daadwerkelijk de uitvoering van het ontwerp dat u wilt, als je eenmaal een paar ontwerpen geschetst op papier of op Photo Shop of wat dan ook, er zijn een aantal hulpmiddelen die voor u beschikbaar zijn gemaakt. De eerste je bent zeer vertrouwd met wat je HTML, PHP, of wat dan ook taal die u gebruikt alleen de statische pagina's op uw website te coderen. Je hebt veel gewerkt met HTML welk soort geeft u deze tags dat je dingen in kunt zetten, en eigenlijk is het een manier van het organiseren van uw inhoud. Bijvoorbeeld, je hebt de header daar, dus je gaat naar een header-tag hebben, en het gaat om wat tekst erin die waarschijnlijk gaat worden in een andere tag hebben. Dan heb je een zijbalk misschien met een aantal verschillende schakels, en die gaan allemaal in tags te scheiden. Dus, eigenlijk HTML bij zijn hart is een manier van het verdelen van de pagina hoe je uiteindelijk wilt formatteren. Dus nogmaals, heb jou eerder gezien. Je bent behoorlijk comfortabel met het werken met het nu gezien het feit dat je de laatste pset hopelijk heb gedaan, dus dat moet geen probleem zijn. 

Dan heb je CSS die in feite behandelt alle van het ontwerp statische aspecten. Het zou alle kleuren, alle positionering van verschillende elementen te behandelen, waar ze gaan ten opzichte van elkaar, hoe groot ze zijn, de verschillende soorten positioneringen die u zou hebben - in andere woorden, je kunt dingen vast, zodat wanneer je naar beneden scrollt ze blijven, of kun je dingen ten opzichte van andere elementen hebben. Al dat soort dingen is in CSS. Bovendien kunt u verschillende decoraties doen, kunt u tekst kleuren hebben, teksteffecten, al dat soort dingen. Ben gaf een echt goede seminar over dit afgelopen weekend, en dus zou ik zeker dat nagaan als je van plan een aantal mooie dingen te doen met CSS. CSS3 is eigenlijk de nieuwste versie van CSS, en het kan allerlei echt leuke dingen te doen. Het kan verlopen doen, je kunt mooie, afgeronde hoeken hebben, je kunt allerlei dingen doen om uw website kijken meer modern en fancy. 

Het volgende gereedschap is JavaScript en jQuery die Ben praatte een beetje over, maar ik zal een beetje verder te krijgen in. JavaScript, als je hebt gewerkt met het een beetje, of op zijn minst gezien in collegezaal, is een soort van een manier van dynamisch dingen doen in HTML. HTML, zoals u weet, is statisch, dus zodra je HTML kunt u deze niet wijzigen. Maar JavaScript, in sommige opzichten, is een manier om te kunnen om HTML te wijzigen. Dus u kunt dat doen, en dat is geweldig, maar Javascript is echt een pijn om mee te werken. Het is zo lang en stompe en zelfs de eenvoudigste dingen te doen vergt veel van de lijnen van de webbrowser. Dus, jQuery is eigenlijk een bibliotheek voor JavaScript dat al die vereenvoudigt. Het zegt, oke, als je wilt een vierkante doos van links komen hebben en verdwijnen in de pagina, zodat het in het midden, in JavaScript, dat zou duren - Ik weet het niet, een honderd regels te doen, en het zou een pijn, en je komt uit het haten van alles over web programmeren. JQuery je in principe het element-dot-fade-in, of iets dergelijks. Dus, zeer, zeer eenvoudige functies die zal u laten doen allerlei leuke animaties en dat soort dingen. Het andere ding dat deze 2 zijn echt goed voor is gewoon dynamische dingen te doen met de website. Dus, in plaats van alleen het hebben van uw HTML-pagina - die eigenlijk een aantal gegevens worden weergegeven, maar niet alles doen - zal Javascript en jQuery laten heb je knoppen waarop u kunt klikken op, en u kunt elementen en re-order te slepen en sorteren, en hebben nieuwe elementen toegevoegd of verwijderd. U kunt toevoegen-delete, dat soort dingen. Dus, jQuery doet ton leuke dingen. En Vipul is eigenlijk het geven van een seminar op het vandaag, geloof ik, bij 5-uur, dus als je rond kunt vasthouden zo lang, dat zou - 5 of 4? Four. Sorry. Het is eigenlijk direct na deze, dus ik zou aanraden om te blijven als je kunt. JQuery is super, super handig, en je zult in staat zijn om veel echt leuke dingen mee doen voor vrijwel elke web development project. 

Nu ga ik om in vorm van een onderscheid. Ik heb eigenlijk het over user interface. Gebruikersinterface is enkel het ontwerp van de site. Maar er is een soort van een ander concept dat is user experience. De twee zijn zeer verschillend. Interface is zeker een deel van de ervaring. Met andere woorden, wanneer je naar een site, je kijkt naar de interface. Dat is een deel van de manier waarop u de site ervaart. Maar gebruikerservaring is meer dan dat. User experience is over wat de indruk dat de gebruiker krijgt van uw site is. Dus uiteraard interface is een onderdeel van. En het is zeker een noodzakelijk onderdeel, maar het is niet voldoende. Met andere woorden, als je een mooie interface, en het is mooi en kleurrijk en dat alles, dat is geweldig, maar als de gebruiker naar uw site, ziet een mooie lay-out en het is in de war door alles, heeft geen idee hoe om iets te doen, dan is het duidelijk dat je een echt gemaakt slechte website. Dat is een soort van waar gebruikerservaring komt inch Ik ga een beetje praten over UX design - UX is een afkorting voor user experience - en een soort van hoe kunt u ervoor zorgen dat u een goede gebruikerservaring. Het eerste punt is dat je een website kan ontwerpen waar een gebruiker iets kan doen die gebruiker mogelijk wil. Maar als de gebruiker niet kan achterhalen hoe die dingen te doen - in andere woorden, als de gebruiker niet beschikt over een goed idee wanneer ze naar uw site van, "O, als ik wil mijn profiel aanpassen, dan heb ik op deze knop klikt, of als ik wil posten op muur van een ander, dan ga ik naar hun muur en klik op een doosje. " Als de gebruiker niet weet dat, dan heb je effectief eigenlijk niet geïmplementeerd die functionaliteit correct. Een deel van de uitvoering van een functie is dat de gebruikers daadwerkelijk in staat zijn om het te gebruiken. En het zou frustrerend zijn - je zou een site te maken, en het kan alle soorten doen prachtige dingen, maar dan moet je mensen testen en zeggen: "Het kan dit niet doen. Waarom kan het niet doen? 'En je komt terug tot hen zeggen: "Nou ja, het kan. Je moet gewoon naar de 7e drop-down menu te gaan op deze obscure pagina die alleen wordt gevonden door een link onderaan-rechtse hoek "of iets. Uiteraard wil je niet dat. Je wilt dat het duidelijk aan uw gebruikers wat ze moeten doen, en het moet eenvoudig en intuïtief voor hen. 

Een ander ding dat je wilt proberen te doen is, als iemand gaat naar uw site en 9 van de 10 keer doen actie A, en 1 van de 10 keer doen actie B, wilt u waarschijnlijk hun ervaring over de actie A. richten Met andere woorden, je wilt het heel, heel duidelijk hoe A. doen A moet voor-en-centrum - ga naar de site, zie het, oh, het is daar. Overwegende B natuurlijk je wil duidelijk zijn, maar je kunt het een beetje meer te verlaten op de achtergrond. David geeft een goed voorbeeld van deze in collegezalen, die de Boston T systeem. Als je naar de Boston T en u wilt een kaartje kopen, je moet krijgen in 5 menu's voordat je daadwerkelijk kunt een kaartje kopen voor een $ 2, $ 2,50 waarde, dat is hoeveel het kost om de metro in een richting. Dat is een probleem omdat de meeste mensen die het rijden van de metro waarschijnlijk gewoon wilt gaan naar een plek, kopen hun kaartje, krijgen meteen. Het heeft geen zin dat ze moeten gaan door veel verschillende menu's om er te komen. Een betere gebruikerservaring zou een sneltoets op de eerste pagina worden dat gewoon zegt: 'koop een one-way ticket,' en dat zou zetten in alle standaard standaardwaarden, en dan als iemand wil een ander kaartje dan die kopen, ze nog steeds, natuurlijk, hebben de mogelijkheid om, maar je hebt geoptimaliseerd voor het common-use case die is echt belangrijk. U kunt voorbeelden van te zien op Facebook, toch? Als je naar Facebook en u wilt een stand te plaatsen, het is vlak aan de top en dat is wat je vaak wilt doen. Zodra u de pagina invoert, kunt u de meest voorkomende dingen doen die je wilt doen. Wilt u iets meer ingewikkelde dingen doen zoals, zeggen dat ik wil naar de muur van mijn vriend en post een foto op het - die ik zal willen vaak doen, maar niet zo vaak als het plaatsen van status updates - dus in dat geval, ik hun naam te typen in het vak bovenaan, klik op hun profiel, en dan nog, het is juist aan de top er eens ik heb gekregen om hun profiel. Nogmaals, ik heb geoptimaliseerd prioriteit voor de meest voorkomende use cases. 

Een ander belangrijk ding is dat vaak mensen zullen soort proberen om dit te omzeilen door te zeggen, oke, dus ik heb de site gemaakt en de mensen vinden het verwarrend, en dat is een probleem, toch? Uiteraard wil ik niet dat mensen te verwarren door de inhoud van mijn site. Maar de manier op te lossen, dat is niet om iets pop-up te zeggen, hey, ik ga je leren hoe je deze site te gebruiken. Stap 1 - Klik op deze knop. Stap 2 - ga hier. Tuurlijk, dat is een weg omheen - het is een manier dat je mensen kunt vertellen wat te doen, maar het is echt niet de optimale manier. Als ik naar een website en opeens ben ik gebombardeerd met deze tutorial die vertelt me wat te doen en waar te gaan en dat alles, dat is niet leuk voor mij. Het is niet een goede ervaring voor mij. Het is een soort van een pijn. Ik wil gewoon beginnen met het doen van dingen. Mensen gaan sluiten uit hun dialoogvenster of uit de tutorial, niet weten wat te doen, en dan klagen omdat je hebt ze niet verteld wat te doen. De manier om dit op te lossen is niet door het geven van enige vorm van tutorial of richtingen - iets dergelijks. Zo veel als je het kunt vermijden, je echt wilt om de gebruiker te laten zien wat je moet doen alleen door de aard van hoe de website wordt aangelegd. Met andere woorden, als ik naar Facebook zonder aan te melden, het eerste wat ik zie op de hoofdpagina - het is een beetje login box. Dus, duh. Ik moet loggen Het is daar. Overwegende dat, als ik naar Facebook en ik moest op een kleine link onderaan dat zei 'inloggen' en de rest van de pagina is het gewoon een soort van beeld of iets, Ik zou niet echt weten wat te doen, toch? Ik zou verwarren. Dus, zou het me vertellen om daar beneden te gaan en klik op de knop om in te loggen, of de log in knop zou gelijk kunnen hebben op de top waar ik ga om het te zien. U wilt altijd met de gebruiker wat te doen, en dat zou inherent zijn aan de pagina zelf. 

Als u denkt over het ontwerpen en het bespotten van verschillende manieren van uiten van uw site, wil je echt nadenken over wat de gebruikers gaan moeten doen en hoe je ze kunt laten zien wat je moet doen. Een laatste ding is testen is echt heel belangrijk. Het is geweldig om iemand - krijgen een vriend, iemand die je niet eens kennen - die nog nooit van de site heeft gezien voordat de site te gebruiken. Omdat je hebt gewerkt op de site voor uren, je hebt staren, en je weet precies wat te doen natuurlijk je gaat het testen van de dingen die je hebt gewerkt en dat je weet werk. Maar als iemand anders komt langs en maakt gebruik van de site die nog nooit eerder heeft gebruikt, dat is een unieke ervaring, omdat je iemand die geen voorkennis hebben van de site in te gaan op het, dus ze gaan te hebben effectief geen idee wat te doen of wat voor soort use cases voor hen aanwezig zijn. Dat is geweldig. Dat is uniek omdat ze in wezen een persoon met een blanco voor een geest. Zij kunnen u vertellen als er iets is verwarrend of onduidelijk. Zij kunnen u een idee van precies wat de gebruikerservaring van uw site is te geven. Het kan heel moeilijk zijn om te vertellen dat jezelf, dus zeker ik wil u aanmoedigen als je de ontwikkeling van uw projecten - al doe je web-based projecten - om mensen die de site zo vroeg als je een soort van functionele demo. 

Nu ga ik een beetje over hoe je een web development project te beheren praten. We hebben laten zien hoe je de technische back-end kant kan doen, hoe je een echt goede website kan ontwerpen, en dat is geweldig als je werkt door jezelf, maar - zelfs als je werkt door jezelf en vooral als je werkt in een team, projectmanagement wordt een groot probleem. Je hebt een soort gehoord over projectmanagement in verschillende vormen sinds basisschool wanneer u groepswerk verteld. Je moet samenwerken, communiceren, dat allemaal. Dat geldt allemaal nog hier, maar er zijn enkele unieke omstandigheden met informatica die u wilt op de hoogte van, en wilt u ervoor zorgen dat u goed omgaan. Ik ga eerst een beetje praten over het team dat je in inch Het is erg belangrijk om de juiste grootte van een team te werken op te halen, en in uw uiteindelijke project Ik denk dat je de mogelijkheid om te kiezen tussen de 1 en 4 personen als ik het goed heb. U wilt ervoor zorgen dat je niet alleen het kiezen van het aantal mensen dat je wilt werken, omdat ze zijn je vrienden. U wilt een team dat is een goede maat kiezen en dat zal de klus te klaren. Er is een afweging in het hebben van meer mensen versus minder mensen. Als u nog meer mensen, kan uiteraard meer werk worden gedaan want je hebt veel mensen, veel code, veel ideeën, en dat is allemaal geweldig. Maar het vereist ook veel meer het beheer en veel meer communicatie. Met andere woorden, als je 4 mensen die werken aan hetzelfde project en ze zijn allemaal bewerkt dezelfde code, meer of minder ze allerlei behoefte om te weten wat er aan de hand dus het u vereist - als je nog wat nieuwe functie toe te voegen u soort hebben om mensen te vertellen - ik ben het toevoegen van deze, Ik verander dit op deze manier - vooral als je in het echt diep spul als de modellen en de controllers die daadwerkelijk gaan beïnvloeden hoe de site werkt. Het hele team moet zich bewust zijn van het, dus je moet ervoor zorgen dat je niet de keuze te groot een team dat zal moeilijk zijn om die communicatie te maken. Je wilt ook niet een klein genoeg team dat je niet gaat om te kiezen kunnen communiceren, want het is alleen jij. 

Een ander ding om te overwegen is het saldo van waar de vaardigheden van mensen zijn. Het is geweldig als je echt goed programmeurs. Maar als je alle back-end mensen, dan is uw website is niet van plan heel goed te kijken want je hebt deze grote databank, en het doet supersnel zoekopdrachten - wat geweldig is - maar als je naar het, het is als een site van 1990 met rode en blauwe overal, en dat is ook niet goed. Merk op dat Ben en ik werken als een team zijn erg leuk, want ik ben een soort meer in de front-end, we zowel interactie in het midden-einde, en Ben is echt goed met back-end spul, zodat werkt echt goed, omdat we een site kunnen ontwerpen en in principe de gaten in die site die moeten worden opgevuld kan worden ingevuld door een van ons, of misschien beide. U wilt ervoor zorgen dat er geen gaten in je team. Het is oke als er een beetje overlap. Met andere woorden, als je 2 mensen die zowel goed met back-end zijn, dat kan goed zijn maar ook omdat ze elkaar kunnen helpen met problemen dat ze hebben. Het kan een probleem zijn als je alleen maar 1 persoon die verantwoordelijk is voor een bepaald ding en ze lopen in een probleem, dus je wilt wel een beetje overlap hebben maar je vooral wilt u ervoor zorgen dat alle mogelijke gaten gevuld. 

Het laatste wat - en dit zou duidelijk moeten zijn, maar het is vaak niet. Wil je echt te hebben plezier. Het punt van dit laatste project in CS50 en vaak het punt van web ontwikkeling in het algemeen is niet om gewoon een baan, want het moet doen. Wil je echt plezier te hebben, en je wilt te maken van iets dat is het motiveren u om eraan te werken. Als alles wat je maakt is een pijn om te gaan zitten en te werken aan, dan ben je niet kiezen van het juiste project. U wilt iets dat je interessant vindt te kiezen, je echt wilt om het resultaat te zien, je opgewonden bent wanneer u een nieuw idee over te krijgen iets wat je zou kunnen doen - dus er is allerlei projecten daar dat ik ben er zeker van u kunt vinden - iedereen heeft iets dat hen echt zou intrigeren als ze doen een web-based project. Ik zal het nogmaals zeggen op dit moment. Als uw project lijkt een pijn en je niet wilt werken, kiezen voor een ander project. Kies iets dat je echt inspireert. 

Ben vermeld dit concept van iteratie een beetje, en ik wil gaan over het een beetje. Het is echt belangrijk om te werken in spurts waar je iets functioneel te krijgen. Het kan geweldig zijn als u dit plan voor een website die gaat doen A, B, en C, en uiteindelijk zal het er te komen. Maar je vastzit in deze fase waar je mee bezig en aan het werken, maar er is niets gedaan krijgen. Je hoeft niet alles te zien en een tastbaar, functioneel ding. Wat je echt wilt doen zo veel als het lijkt soort van een pijn soms werken aan iets en dan soort van dop het af, zodat het in ieder geval op een stabiel, hardlopen versie zelfs als het niet alle functies die u wilt heeft. En misschien zijn er een aantal functies die je echt wilt toevoegen, maar je kan het gewoon niet want je wilt deze site te krijgen om een ​​functioneel oogpunt. En dus je wilt soort hebt de hele ontwikkelingsproces uitzien. U wilt ergens functionele starten - of in wezen beginnen met niets - maar je ergens erg basic en functioneel te krijgen. En dan weer, maak een soort van jump en krijg weer ergens functioneel. Je zult langzaam opbouwen, en het misschien een beetje trager dan het zou anders gaan, maar op de lange termijn als je voortdurend vast in deze middenweg fase waarin je niet daadwerkelijk iets werkt, kan het een echt grote frustratie te werken aan uw project, omdat je altijd zo dicht bij het krijgen van het werken, en het is nooit echt werkt. U wilt werken in deze functionele spurts, en u wilt ook enige reflectie doen na elk een. Met andere woorden, zodra je op een punt waar de site nu werkt - het niet alles wat je wilt hebben, maar het doet sommige dingen - wilt u misschien denken, oke, is deze site het realiseren van de doelstelling die ik uiteengezet te doen? Met andere woorden, als de site gaat X doen, is wat ik werkzaam richting X? Zijn alle functionaliteiten die ik daar wilde? En bovendien is het dienen van het algemene doel dat ik wil? Als je het vinden dat uw site begint te neigen in een andere richting of misschien dingen gewoon soort zijn niet uit te werken, kan het tijd om te schakelen een beetje zijn. Met andere woorden, het is het overwegen waard - het is de moeite waard gooien ideeën indien nodig en gezien ben ik echt aan het werk in de richting van wat ik wil zijn. 

Ik geloof dat mijn volgende punt. Wees niet bang om ideeën te verlaten. Gewoon omdat je besteed veel uren werken aan een functie en eindelijk het werkt, maar het is echt niet zo goed gaat - alsof het niet zo nuttig of gebruikers problemen hebben met het gebruik ervan - dat soort dingen - wees niet bang om weg te gooien. Het zuigt dat je veel tijd hebt besteed aan het werken, maar uiteindelijk ga je niet een site die soort in elkaar zit door deze stukken willen dat soort werk, maar zijn niet zo goed bediend. Ook moet je niet bang zijn voor nieuwe ideeën. Als iemand komt langs en zegt: hey, die site ziet er echt cool, maar zou het niet eens geweldig zijn als het dit ook deden? Gewoon omdat dat is iets dat je niet van plan was en iets dat niet in uw specs, iets dat je niet te doen hebben uiteengezet, wees niet bang om het op te nemen en dan werken. Omdat vaak de ideeën die u uitvoert met de hele loop van de ontwikkeling uiteindelijk wordt het echt coole functies van de website. 

Ik heb dit al eerder gezegd. Ik zeg het nogmaals. Testers zijn super, super handig. Proberen om mensen die nog nooit van de site hebben eerder gezien om in te loggen en te zien wat er aan de hand te krijgen omdat ze niet alleen het nut van de site en de gebruikerservaring kan testen, maar ze kunnen ook de functionaliteit te testen op een manier die je niet kunt. Als u enkele functie die een bepaald ding maakt en je weet dat het gaat om dat zelfde ding goed te doen elke keer, dat is geweldig. Maar het kan vaak moeilijk zijn om rekening te houden hoek gevallen waarin een gebruiker kan Typ iets dat je niet verwacht - juist omdat u hebt gedefinieerd de functies zelf. Dus, om iemand komen op die geen idee heeft hoe de site te gebruiken en gewoon breken in welke manieren ze kunnen doen is erg handig omdat je een idee vanuit een heel ander perspectief van wat op uw site werkt en wat moet worden gerepareerd. 

Eindelijk, ik ga praten over een aantal algemene goede praktijken, en je hebt veel van deze gezien in CS50, maar ze ook echt, echt passen in een project omgeving. Een is opmerkingen. Comment altijd uw code vooral als je werkt aan een groot team. Het kan zo vervelend om gewoon een gigantische blok code dat iemand geschreven zijn en misschien werkt het, misschien niet, maar je hebt geen idee wat het doet, dus je hebt geen idee of het nuttig is of niet of dat het er moet zijn of niet, en als je werkt aan iets anders is het zelfs mogelijk dat je bezig bent hetzelfde, dus gewoon heel, heel voorzichtig rekening met uw collega's te zijn en code schrijven dat is goed gedocumenteerd. Je hoeft niet zo ver gaan om de hele zaak waar leuk vinden als je verhogen doen een teller hebben een reactie die zegt, ik ben het toevoegen van 1 tot deze teller. Het hoeft niet dat gedetailleerd te zijn, maar voor elke functie die u ooit aan het schrijven bent moet je wat documentatie van wat die functie precies doet hebben, wat de ingangen zijn, en wat het zou moeten terugkeren. Op die manier kunt u andere onderdelen van de site die mensen gebruiken en je kunt werken aan het opbouwen van iets groots. 

Een ander belangrijk ding is dat je wilt regelmatig schoon-ups doen. Code krijgt rommelig. Voel je niet slecht als je code is gewoon helemaal onleesbaar en een gigantische puinhoop. Dat gebeurt in web ontwikkeling altijd. Je bent het toevoegen van nieuwe functies, het verwijderen van oude. Spul gaat om daar te zijn dat niet zou moeten zijn. Dat is prima, maar je wilt er zeker van om regelmatig te gaan met dat. Je wilt niet te laten bouwen tot het punt waar je gewoon niets vinden in je code, en je hebt geen idee wat iets doet. Dat is het geval met HTML. Soms zul je eindigen met voorwerpen die niets bevatten, en je wilt om zich te ontdoen van die. In CSS, kunt u verwijzen naar elementen die er niet zijn meer, dus je wilt om zich te ontdoen van die code. In JavaScript, zou je iets uit de HTML hebt verwijderd. Dus, wilt u ervoor zorgen dat je altijd opruimen, het maken van dingen vrij zo veel als je kan op een regelmatige basis. 

Een ander echt nuttig ding dat ik denk niet dat is zeer geschetst in CS50 maar het is de moeite waard om in is versie controle. Het idee van versiebeheer is wanneer je eigenlijk bent het bijhouden van alle vooruitgang je hebt gemaakt naar uw site en als u op enig moment realiseer je je, oh, dit werkte een tijdje geleden, maar het werkt niet meer, kunt u teruggaan naar de vorige versies en zien wat er is veranderd sinds die tijd en dat soort dingen. De belangrijkste manier om dat te doen is met Git, en Git is dit hele soort systeem dat Ik denk dat Tommy MacWilliam gaf een seminar over het afgelopen jaar. Als je in de CS50 seminars voor 2011, kunt u zijn seminar op dat zien. Het idee van Git is eigenlijk dat op gezette tijden je het maken van deze toezeggingen die manieren om te zeggen de site is in een vrij stabiele versie nu bent zo Ik ben het verpakken en verzenden van het weg aan een server, en dan kun je naar die server en kijken naar alle vorige versies van uw code en zien hoe het vorderde en al dat soort goede dingen. Dus, dat is eigenlijk het. Voor zover web ontwikkeling, we zijn blij om te blijven en beantwoorden alle vragen wat onze presentatie. Dat is het. Bedankt. >> [Ben] Bedankt. [Applaus] 

[Billy] Personeel, heeft iemand nog vragen hebben over dingen die we hebben behandeld of dingen die we niet hebben behandeld dat ze hoopten we zouden dekken? We zouden blij zijn om die te beantwoorden. Iedereen? [Toeschouwer] Wat zijn de voors en tegens van het gebruik van Ruby of Python? [Ben] De vraag was, wat zijn de voor-en nadelen van het gebruik van Ruby of Python in plaats van zoals PHP. De pluspunten zijn dat Ruby en Python zijn veel beter talen dan PHP. Althans in mijn mening, en ik denk dat in veel van de adviezen van andere mensen ook. Ze waren meer voor het doen van complexe dingen ontworpen, en minder voor elkaar meppen webpagina's heel snel met een beetje van dynamische inhoud. De nadelen zijn dat er een klein beetje - er is meer van een leercurve om hen opzetten. Dat is, net als in PHP, kunt u gewoon een HTML-bestand en je minder-dan schrijven, vraagteken, en dan schrijf je een code, en vervolgens vraagteken je schrijft, groter-dan, en dan ben je klaar. In andere talen zoals Ruby of Python, je moet gaan door een beetje meer werk om de eerste site draaiend te krijgen. Er is ook - althans vroeger het geval te zijn - dat er meer documentatie beschikbaar voor PHP, alleen maar omdat er meer mensen die het gebruiken. Ik denk dat het niet zo veel van een probleem meer. Er is zeker een zeer goede documentatie voor dingen zoals Ruby on Rails of Django voor Python is het equivalent. PHP is degene die iedereen is al gebruikt voor jaren, en je weet hoe het werkt. Ruby en Python zijn een beetje minder volwassen. 

[Toeschouwer] Als je moet kiezen tussen een van hen om te leren of pick-up, wat zou je het liefst? Eerlijk gezegd, ik denk dat afhankelijk van de persoon. Het spijt me. De vraag was welke zou je kiezen voor iemand om te leren? Ik vind Python de mooiste persoonlijk. Er zijn een heleboel mensen die - ik heb mijn eerste web dev project in Python en Django. Er zijn een heleboel mensen die graag Ruby on Rails ook. Waarschijnlijk meer mensen die Ruby on Rails weten. Eerlijk gezegd, zou ik gewoon gaan met wat de mensen om je heen weten zodat je mensen om vragen te stellen. 

De vraag was - op gedeelde servers is het een beetje moeilijk om te werken aan Python? Dat hangt af van uw hosting. Er zijn een aantal web hosts die Python spul zal posten. Webfaction doet dat, toch? Webfaction is er een die Billy en ik heb gebruikt voor een aantal projecten. Ze zijn echt geweldig. Ze ondersteunen de meeste talen. Maar het is waar dat PHP is veel meer breed gedragen. Dus, als je vast zit op een webhost die alleen doet PHP, dat is een goede reden om PHP te gebruiken. 

[Toeschouwer] Ik ben net in het leren hoe je query sommige databases, en ik weet dat mijn SQL is all over the place, maar ik kreeg onlangs blootgesteld aan - en je erop gewezen. Je ziet JSON en uitbreidbaar databases. Mijn SQL is nog steeds all over the place. Hoe ziet u dat gebeuren? Komt er een groeiende tendens voor meer uitbreidbaar (onhoorbaar) zijn? De vraag was - ik denk dat er gaat een trend naar niet-SQL databases. Bijvoorbeeld, zoals MongoDB. Ik denk dat is zeker waar. Mijn advies was vooral hier MySQL-gerelateerde alleen omdat MySQL is industriestandaard. Persoonlijk heb ik veel liever databases die niet schemos zoals MongoDB hebben waar je niet het probleem van hebben, oh, ik moet nog een kolom toe te voegen. Wee mij, als wat moet ik doen? Het is heel moeilijk om dat te doen op MySQL, maar als je iets als Mongo hebben het is veel mooier. Het andere leuke van Mongo is dat uw administratie zijn eigenlijk JavaScript-objecten. Er is geen soort van conversie stap waar je nodig hebt om deze databank rijen nemen en zet ze in een JavaScript-object en vervolgens stuur ze over de draad. Ik denk dat soort dingen gaat zeer, zeer nuttig te zijn voor een snelle web-ontwikkeling in de toekomst. 

[Billy] Iets wat ik zou toevoegen dat is gewoon een algemeen punt is dat niet het gevoel dat u alle talen die we hebben besproken moeten hebben geleerd van ons seminar. Uiteraard is het punt is om u een idee van wat er daar te geven, en als je geïntrigeerd door een van de dingen die we hebben vermeld je kunt ze googlen en lezen over hen. En zoals ik al zei, zijn er een paar seminars die zich bezighouden met juist deze dingen. Er zijn nog meer seminars die ik niet heb genoemd die waarschijnlijk krijgen in dit spul ook. Het idee is dat als je wilt werken aan iets, hier zijn de tools tot uw beschikking. Voel je niet overweldigd als je niet echt weet wat deze tools precies doen, maar weten dat ze er zijn en dat je kan ruim gebruik maken van hen door Google. 

[Toeschouwer] Wat voor dingen heb je nodig om te doen om te zorgen dat uw website te maken ziet er goed uit op mobiele apparaten? [Billy] Mobiele apparaten zijn een beetje hard. Er zijn 2 manieren waarop u kunt benaderen. De eerste manier is dat je eigenlijk een mobiele website. Met andere woorden, je een soort van detectie uitvoeren begin wanneer de browser is die het verzoek om uw website, die ofwel zegt terug deze visie - die het uitzicht voor desktop of laptop browsers zal zijn - en deze andere weergave voor mobiele apparaten. Dat is een plaats waar de uitzichten zijn heel mooi in dat u kunt vrij veel swap de twee uit en hebben een interface die echt mooi werkt op mobiele apparaten en hebben een totaal andere die goed werkt op browser apparaten. Het probleem met dat is het duurt een lange tijd, omdat het betekent codering een totaal andere interface. De andere manier dat je het kunt doen is - veel moderne telefoons zullen websites weer te geven en probeer ze te maken als een browser zou doen, en ze doen hun best. U kunt soort proberen licht te blijven op de hoogte van jQuery JavaScript u gebruikt die de neiging heeft te zijn waar dingen mis kan gaan een beetje. Dit is een soort van de weg die je moet gebruiken als je niet zo heel veel tijd. Als je wel de tijd om te werken aan een mobiele interface, dat is natuurlijk de beste optie. 

Ik denk dat in het algemeen voor CS50 projecten, je gaat te willen om een ​​of het ander te kiezen. Met andere woorden, je wilt een mobiele app te maken of wilt u een desktop website te maken. En dat soort bepaalt waar je met dat. Maar als je wilt later uit te breiden uit, waarschijnlijk uw beste weddenschap is naar een andere interface voor de andere te maken. Ik heb een beetje ervaring in het ontwikkelen WordPress-gebaseerde sites. Ik organiseerde een persoonlijke website op WordPress voor een tijdje. Dat soort kaders kan leuk zijn net zo zeer fundamentele dingen. Vaak zul je alleen nog maar in een veel aanpasbaarheid kwesties wel. U wilt iets kijken op een bepaalde manier of zijn op een bepaalde manier en je kan het gewoon niet, want het is hard-wired in het systeem dat dit is hoe je dingen die een beetje een probleem kan zijn doen. Sindsdien heb ik soort is meer geneigd om te werken met sites uit de grond omhoog. Voor zaken als blog databases en dat soort dingen het is echt niet zo moeilijk om een ​​kader op te bouwen. Als je echt uitgerekt voor tijd, kunt u natuurlijk gebruik maken van iets als WordPress of dat soort dingen voor een blog. Het soort dingen die blogs op te slaan en te doen zijn niet echt hard genoeg dat als je loopt in een van dat soort dingen, ben je waarschijnlijk het beste gewoon om maken van een in-house versie. 

Ik denk dat is het zo'n beetje, dus nogmaals bedankt voor het komen. We hebben echt genoten van het praten met jullie en hopen dat u sommige dingen geleerd. [Ben] We zijn blij om te praten - we moeten gaan, maar we zijn blij om meer buiten te praten Als u een andere vraag. Nogmaals bedankt. [Applaus] [CS50.TV]