[Powered by Google Translate] [Szeminárium] [Web Development: Ötlettől a Végrehajtás] [Ben Kuhn] [Billy Janitsch] [Harvard Egyetem] [Ez CS50] [CS50.TV] [Billy] Szia, én vagyok Billy és ez a Ben. >> [Ben] Szia. Fogunk beszélni webfejlesztés ma. [Webdev] [Billy Janitsch és Ben Kuhn] Egy kicsit rólunk először. Ben van valami a back-end fickó. Ő teszi a dolgokat. És akkor megyek, és azokat elég. Én nagyrészt részt, több front-end kiadványtervezés fajta dolog, és Ben, másrészt, tudja, mit csinál, így dolgozik a back-end cucc. Együtt tettünk egy pár dolgot. Például az elmúlt évben dolgoztunk Gimblium, amely egy online játékfejlesztő stúdió. Ez volt a végső projekt az osztály, és azóta tettünk Harvard osztály amely egy online kerete böngészés és vásárlás tanfolyamok a Harvardon. 

Fogunk kezdeni ezt az ötletet a honlapunkon. Fogjuk, hogy a Facebook, de a macskák. Mielőtt valójában, hogy ezen a honlapon, nem teszik ezt a weboldalt, mert ez nem jó, de majd használni, mint egy keretet és végig a folyamatot, hogy hogyan lehetne ezt az ötletet és kapcsolja be a valódi website tudjuk használni. Kezdjük feltörik a honlapon le. Mintha már csinál CS50, szeretnénk gondolni, mi a tényleges alkatrész, hogy bemegy a honlapon. Alapvetően forgatva egy ötlet, amely csak egyfajta elvont fogalom egy igazi, kézzelfogható dolog, hogy meg tudná tenni. Kezdjük azzal, hogy felkéri néhány kérdést. Mi ezen a honlapon? Miért így? Mit fog ez használni? Ez a fajta dolog. Abban az esetben, a Facebook Macska, Alapvetően szeretnénk egy weboldal, amely lehetővé teszi a macskák social network egymással. Az ötlet az, hogy ezek után egymás falak, tudják, hogy megjegyzéseket, ilyesmi. És ez az, ahol jöttünk be a funkcionális alkatrészeket. Most már ez a fajta keretein belül -, hogy van a felhasználói profilokat, van megjegyzéseket, és küldhetnek. Talán egyszer majd a befolyó kedvel és az ilyesmit. És mi a fajta szeretnénk előtérbe ezeket a funkciókat megy be Azt akarom mondani, mint, oké, ez nagyon fontos, hogy mindenkinek van egy profil és az, hogy mindenki tegye egymás falak. Másodlagos, hogy, hogy a hozzászólások jó lenne. Talán később majd befolyó szeret. Szóval, azt szeretnénk, hogy van egy ötlete, hogy mi az alapvető, hogy a projekt és mi egyfajta általános jellemzője, hogy lehetne alkalmazni később. Azt akarod, hogy valami egy konkrét lista szem előtt tartva, de a projekt, hogy elkezd nem lesz a projekt, amit befejezni. Más szóval, a dolgok meg fognak változni közben fejlesztése az oldal, és azt szeretné, hogy teret adott. Majd fordítsa meg a Ben ki fog beszélni egy kicsit a struktúrát. 

[Ben] fogok beszélni inkább technikai oldalát webfejlesztés. Menjünk át néhány alapokat az első. Ha csinálsz egy web app, a legfontosabb részlege, hogy fogsz, hogy van, hogy fogsz, hogy néhány dolog folyik a kliens oldalon - azaz a kódot, hogy te vagy a böngésző tart a helyén és a JavaScript, HTML, CSS cucc. Ez minden, a kliens oldalon. Fogsz más kód, amely fut a szerver oldalon amely nyomon követi az összes adatot, hogy az emberek küldeni Önnek, dönti el, ki, hogy milyen, ilyesmi. Ez csak pár fogalmat, hogy ti mindannyian ismerik, mit beszélünk. Azon túl, hogy részlege ez jó arra gondolni, a webes alkalmazás szempontjából néhány különálló alkatrészeket. Ha csinálsz webfejlesztés az egyik dolog, amit mindig próbál tenni, hogy csökkentse a komplexitás. Minél összetettebb a kódot a több esélye van, hogy a hibákat, annál nehezebb változtatni később. Tehát, ha szakítani a app-ba egyes különálló funkcionális területek hogy lesz - és akkor csökkentheti az a fajta mennyiségének cross-terület kommunikáció - amely segít sokat a hosszú távon számának csökkentése tekintetében hibákat. 

Ahhoz, hogy a konkrét, általában az emberek felosztását web app a - Ezek a fajta buzz szó most, de még mindig hasznos. Lehet, hogy hallott az emberek beszélnek modellek, nézetek, és a vezérlők. Modellek a tényleges adatok az app fog foglalkozni. Például, a Cat Facebook, a modellek lennének - ha volna a modell, mint a hozzászólás, és a modell felhasználói profilok, ilyesmi. A nézetek hogyan be, hogy az adatok a felhasználók számára. Lehet, hogy 1-nézetben néztem egy hozzászólást, és az észrevételeket és egy másik nézet a fal, amely egy listát az összes álláshely , amelyek irányítják a te, és a másik nézet a hírcsatorna - ilyesmi. Végül, akkor a vezérlők, amelyek alapvetően, amikor az emberek az elküldött hozzászólás és hogy a frissítéseket a back-end rendszer, Ön növekmény egy csomó számlálók, és bármi. Ezek a vezérlők. 

Fogok beszélni főleg a modellek. Megtekintések technikailag nem olyan nehéz, és a kérdés inkább a tervezés velük Vezérlők lesz jellemző, hogy bármit is tervezése. De van néhány nagyon általános technikák segítségével hogy a modellek szebb és könnyebb dolgozni, hogy azt hiszem, nagyon hasznos. Ez leginkább lesz arról, hogyan kell kezelni a webes alkalmazások adatait egy szép módon. A fő kérdés a modellek az, hogy élnek a kliens és a szerver, és meg kell kitalálni, a) hogyan lehet őket - az összes érintett is - a szerverről a kliens, és b) hogyan tartja őket szinkronban. A felhasználók fognak szeretné, hogy néhány frissítéseket. Fognak, hogy szeretné, hogy az új hozzászólások. Ők akarnak majd, mint a dolgokat, meg ilyesmi, ha tetszik. Ezek a legfontosabb technikai kihívások kezelésének modellek. Az első dolog, amit szeretne majd kérdezd meg magadtól, milyen adat megy ebben a modellben, és milyen jellegű kérdések fogunk akarsz - azaz, hogyan fogjuk nézni a modelleket? A macska Facebook például a hozzászólás megy, hogy a szerző a hozzá kapcsolódó, Néhány falat hozzászólás szövege, valamint a címzett a fal post. És akkor érdemes lekérdezni, hogy egy csomó különböző módon. Ön is szeretné, hogy nézd meg az, aki azt írta, amely után, által, akik postai úton, amely, talán dátuma szerint írták. De ha meg akarsz csinálni dátum, akkor meg kell adni egy másik területen a post mikor azt ténylegesen írt. Ezek a 2 tényező -, hogy milyen adatokat szeretne használni, és hogyan szeretné megtekinteni, hogy - meg kell gondolni őket először, mert függnek egymástól, és ez lesz a nehezebb, hogy vegye fel őket a későbbiekben. 

Vannak más szempontok. Amikor az ember gondolkodik, hogyan foglalkozik modellek a szerveren mit akarsz, hogy nézd meg - alapvetően szeretnénk, hogy a szerver a lehető legegyszerűbb. Csinál dolgokat a kliens oldalon általában sokkal gyorsabb, ha meg tudod csinálni pusztán az ügyfél anélkül, hogy bármilyen hálózati kérésre. Az ötlet az, hogy nem annyi a lekérdezések, amennyit csak lehet a kliens. Az egyetlen probléma az, hogy az, hogy ha az Ön által kért összes adatot az elején akkor ez fog hosszú időt vesz igénybe a terhelést. Tehát az ötlet, hogy megteremtse a középutat, hogy elég adatot a kliens hogy meg tudod csinálni a legtöbb a munka ott, de nem csak a vonzó mindent egyszerre úgy, hogy Önnek valóban lassú töltési idők elején. Például, a macska adatait akkor valószínűleg szeretne letölteni egy csomó friss fal hozzászólások. Ha nem akar letölteni mindet, mert, hogy mehet vissza egy pár évig. De nem akar értük egyesével mert az be sok hálózat túlterheltsége. 

Ez gyakran igen nehéz - ha van egy adatbázis fut - ez gyakran elég nehéz megváltoztatni, amit adatok vannak benne - vagyis egy új adatbázis oszlop, vagy valami - így egy jó stratégia valójában csak hogy sok az adatokat szöveges blob - a JSON blob - JSON, hogy JavaScript Object Notation - Ennek az az oka, hogy ez hasznos, mert akkor új tulajdonságok az összes ilyen JSON foltok megváltoztatása nélkül az adatbázist. Az egyetlen hátránya, hogy ez az, hogy ha van egy csomó területen hogy hozzáadott később - mint a rejtett, hogy JSON blob - akkor ez nehezebb lekérdezésére be őket az adatbázisba. Például, ha később - ha már a poszt modell, amely a korábban tárgyalt csak a szerző, a befogadó és a szöveg - akkor is van egy JSON blob, majd ha később ki akarta egészíteni a dátum mező akkor nem kell változtatni az adatbázis. Lehet csak hozzá a dátumokat, hogy az összes szöveges mezők. És akkor képes lesz, hogy nézd meg azokat a kliens oldalon, de nem lesz képes lekérdezni azokat a szerver oldalon mert elrejtve a szöveg. 

A másik kérdés, amit akarok gondolni az, hogy a kliens és a szerver fog kommunikálni. Általában akarja tartani ezt a lehető legegyszerűbb. Lehet csak, mint a get-me-ezeket az adatokat kérés a create-a-new-object dolog, és egy update-egy-régi tárgy kérelmet. És ezeknek mind különböző URL a szerveren, amit - hogy a böngésző is - lehet használni AJAX kérések az összes ilyen és vagy fogadni vagy postai adatokat. Ismét a mi Cat Facebook például akkor lehetett volna, hogy az URL-t, hogy az egyén után, és azt egy URL-t egy új falat poszt és talán egy URL-t feltölteni a profil kép, ilyesmi. De ismétlem, ez a pre-fetch legtöbbet az adatok, így nem kell tartani hogy hálózati kérések. Ezért lehet, hogy nem szeretné, hogy az egyéni GET kérelmet egy poszt, és ahelyett, hogy azt csak akar 1 GET kérelmet az egész falat. És ha akarsz megtalálni az egyensúlyt, mert - ez is megy, hogy függ az alkalmazás. Mert ha azt várod, hogy az emberek csak 10 vagy 20 fal hozzászólás hogy minden rendben lesz. De ha azt várod, hogy majd több ezer, akkor a kérelmet túl sokáig tartana, és így érdemes felvenni a kap-all-hozzászólás-óta paramétert. 

Mindezen akkor valószínűleg szeretne majd szinkronizálni az adatokat JSON - JavaScript Object Notation. Elég sok minden nyelven foglalkozik JSON nagyon jól. JQuery van ez a szép getJSON funkció, amely mindent megtesz a kemény munka az Ön számára. És PHP ott is nagyon szép JSON kommunikációs funkciókat. Szóval, ez talán a legjobb formában az küldött a modellek oda-vissza. 

Például, hogy mit beszéltünk eddig, itt egy példa áramlását a macska Facebook alkalmazás. Úgy indul a böngésző kérő alap webhely URL-jét. A szerver valószínűleg küld több statikus HTML és néhány JavaScript és CSS. Ez rendszerint az a legjobb, hogy ne tegye teszi a szerveren. Valószínűleg nem akar - amit a szerver nem csinál ott megy le a listát, fal hozzászólás és a termelő néhány HTML mindegyiket, és küld, hogy vége. Ez rendszerint az a legjobb, hogy nem, hogy a kliens oldalon, mert különben minden alkalommal szeretnénk, hogy újra dolgozzon valamit, van, hogy a szerver kérést. És ez nagyon gyorsan ad egy csomó fölött. Ez rendszerint az a legjobb, csak a hajót küld le a statikus HTML majd a JavaScript és a CSS, amelyek nem a renderelés a kliens oldalon. Amint a cucc érkezik, akkor lehet - JavaScript - meg tudod csinálni kérelmeket a falat adatok meg ilyesmi, és azt követően, hogy a szerver alapvetően csak csinál adatbázis lekérdezések és ellenőrzése engedélyeket. Az egyetlen fontos dolog az, hogy nem küld több más felhasználóknak fal hozzászólás hogy te nem szabad látni. Ez alapvetően egy nagyon vékony réteg hozzáférést az adatbázishoz, és akkor az összes mutató adatok - az összes nézetek és dolgok - azok megtörténhet a böngészőben, majd amikor azt szeretné, hogy a postai úton vagy valami csak küldjön egy kérést. 

Van még néhány divatos cucc amit tehetünk a tetején. Ami a részletesebb technikai információk, fejlesztése egyszerű JavaScript lehet egy kicsit fájdalmas, tehát vannak olyan könyvtárak és eszközök, amelyek segítségével sokat azzal. Azt hiszem, minden bizonnyal hallott jQuery ami csinál HTML rendering és manipuláció sokkal könnyebb - sok a képzelet funkciók fakulásnak, és ki, és ezzel lendületes animációk. Van még ezt a könyvtárat néven Underscore.js. Van egy csomó hasznos segédprogram funkciók dolog, amit elvár a JavaScript, hogy hogy valóban doesnt - dolgok, mint csoszogó egy tömb, eltávolítása ismétli a listából, vagy egyengető listájának listák. Ez csak egy kis kódot mintát. Aláhúzás van egy csomó ilyen hasznos függvény, amit szeretném, ha lenne minden alkalommal. 

És akkor ott van még 1 könyvtárat, amit szeretnék eltölteni egy kis időt úgynevezett Backbone.js mert Backbone tényleg segít kezelni a modellek a kliens oldalon és sok a zavart, hogy okozhat. Backbone ad ez a fogalom a modellek és gyűjtemények A JavaScript amelyek alapvetően pontosan, mint JavaScript objektumok JavaScript tömbök, de vannak események, amikor megváltoztatja a tulajdonságait. Csakúgy, mint a JavaScript, akkor van olyan esemény, amikor egy gomb lesz kattintott, vagy valami Ezek Backbone modellek és Backbone gyűjtemények közvetíti a dolgokat, mint hogy amikor változnak. Ez azt jelenti, hogy csak írni valami ilyesmit kódrészletet itt - ez azt mondja, ha van hozzá semmit a hozzászólás tömböt dolgozza át az egész falat. És ez azt mondja, ha egy bejegyzéshez több embernek tetszik változik, akkor értesíti a felhasználót, hogy valaki szerette a post. Vagy ha vagyon utáni változtatásokat dolgozza át a post. Ilyesmi menteni tonna komplexitás különben ha nincs egy kis keretet, mint ez, akkor minden alkalommal a kód, amely megváltoztatja semmit egy post, azt kell emlékezni magát, hogy hívja a funkció teszi meg ilyesmi, és ha volna hozzá valami újat, ami történt minden alkalommal, amikor módosította a poszt azt, hogy menjen át minden helyet a kódot, amit módosított a hozzászólást, és hozzáteszi, hogy az új dolog. A keretet így eltávolítja a sok között, amely réteg kommunikáció , ami a kód bonyolult és nehéz fenntartani. 

Van egy kicsit a kilátást is. Fogom hagyni a legtöbb ez Billy, mert ők technikailag nem túl nehéz. Használja jQuery a nézeteit. Ez gyakorlatilag, mint egy szükséges ezen a ponton. Ez csak tesz mindent, így sokkal könnyebb. Sok a könyvtárak. Ha bonyolult felhasználói felület elemei, Ha azt szeretné, hogy az automatikus kitöltés dolgot, mint egy ilyen divatos multi-választók - Ha azt szeretné, valami ilyesmi, akkor valószínűleg csak keresni körül és akkor talál egy jó könyvtár, fog tenni, amit akarsz. Billy fogja magyarázni többet a valóban nehéz részei nézeteit. Továbbá, mint Mellékesen jegyzem meg, Backbone néhány funkciót készítésére nyílik kommunikálni szépen modellek - nézd meg a dokumentációt mindezen könyvtárak, valóban. Csak nézd meg a docs. Ők nagyon jól megírt és könnyen követhető. Általában, akkor nagyjából csak a Google, ha problémája van. Van egy csomó ember használja őket. Azt hiszem, ez olyan, mint egy utolsó megjegyzés. 

Van még néhány további dolog, amit tehetünk ha keres, hogy a web app extra félelmetes. Meg tudod csinálni - az új HTML5 specifikáció van egy csomó divatos dolog, amit tehetünk. Helyi tárolás - mely tárolhatja az adatokat a böngésző - ahelyett, hogy menjen vissza, és elolvassa a szerver mindent, tudod tartani egy részét az ügyfél, és még lehetővé teszi az emberek - bizonyos esetekben ez is megengedem, hogy használja a weboldal offline. Van ez a dolog, az úgynevezett WebSockets, amelyek egy másfajta hálózati kommunikáció ahol ahelyett, hogy csak csinál egy kérésem, akkor kap választ, és kész, tartod megnyit egy kapcsolatot a szerver, és így meg tudod csinálni a dolgokat, mint valós idejű frissítéseket. Tehát, ha akarták, hogy a chat app, akkor használja WebSockets kommunikálni oda-vissza, így nem kell tartani kérő, "Ó, szerver, nem valaki küld nekem a chat?" 10 másodpercenként, vagy valami. Van még egy érdekes HTML5 funkció, ahol lehet, hogy úgy néz ki, mint a Az oldal URL-jét változik anélkül, hogy valaha tényleg töltse be újra. Használhatja a Vissza és Előre gombok anélkül, hogy egy csomó hálózati kérések. Ilyesmi nagyon hasznos, hogy egyértelművé váljon, hogy gyors, de úgy működik, mint egy web app kell. 

Van még ezt a dolgot nevezett CoffeeScript. CoffeeScript egy másik nyelvet, valóban, hogy fordítja le a JavaScript. Azt írja az összes kódot CoffeeScript, majd futtatja ezt a fordító, és kiköpi a JavaScript-fájlt, akkor is az Ön weboldalára. Ennek az az oka, hogy az CoffeeScript szép, mert ez megszabadul sok a furcsa eset, hogy a javascript ahol egyenlő az egyenlők, és egyenlő az egyenlők különböző dolgokat, vagy mint - van szebb szintaxisa foglalkozó tömbök és függvények. Ez egy kis részlet a CoffeeScript, hogy létrehoz egy listát az összes négyzet 10 ^ 2-1 ^ 2 fordított sorrendben. Mint látható, CoffeeScript gyakran lehetővé teszi, hogy kifejezze az 1. sorban mi lenne, hogy 5 sornyi JavaScript. Ez lehet, hogy a dolgok sokkal könnyebb. Ez egy kicsit az új szintaxis tanulni az első, de biztosan fog neked termelékenyebb hosszú távon. 

Tudod is használ más nyelveken a szerver, mint a PHP - nyelvek, mint a Ruby, Python, vagy van még egy projekt a node.js amely segítségével JavaScript a szerveren. Személy szerint én nagyon, nagyon utálom a PHP. Csak nem szívesen dolgoznak vele. Ha Ön is úgy gondolom, hogy ez egy borzasztó cluge egy nyelv, akkor ezek egyikét használja helyette. Általában, ha akarsz valamit, és nem igazán tudom, hogy fog csinálni, csak a keresés az interneten. Vannak tonna tonna források különösen - StackOverflow egy nagy ember. Ez az a honlap, ahol programozók feltenni egymásnak kérdéseket. Lehet, hogy befut, ha voltak, amelyek bajba CS50 problémára készletek. És vannak tonna könyvtárak csinál elég sok mindent, amit szeretne. Ha akarsz valamit, és nem tudod, hogyan kell csinálni, Nem feltételezzük, hogy ez lehetetlen. Csak nézz körül, és lehet, hogy talál valami jó források. 

Általános lezárja, a fő elvitelre a dolgok egyszerű. Minél összetettebb a kód elején és minél többet próbálni, és nem divatos cucc, A hosszabb ideig fog tartani, hogy valami valóban működőképes , és annál nehezebb lesz változtatni később. Szóval, amit a buta, egyszerű módja az első. Hogy együtt haladjon, hogy ne félj, hogy eldobja a régi kódot vagy tisztítás egy csomó. Általában, ha tényleg van valami munka, ez sokkal könnyebb gondolkodni, mint amikor még az elején szakaszában Az, hogy hogyan tegyem ezt együtt. A legjobb, hogy a leghülyébb lehetséges elrendezést alkalmaz, amely majd javítani iteratív mint megpróbál mindent jól az első alkalommal. Ami a kliens-szerver részlege, próbálja tartani a szerver nagyon egyszerű - csak egy adatbázis, és néhány hitelesítés és ne tegye kemény munka van. Tegyenek meg mindent a bonyolult dolgokat a kliens oldalon a böngésző A JavaScript, amennyit csak lehet. Nézz körül a könyvtárak számára, hogy az életed jobb. Mindig jobb, hogy kódot, hogy valaki más írta ha - és nem írja meg magad. Van egy csomó dolog az interneten. A Google a legjobb barátod. A Google a programozó legjobb barátja. Igen, biztosan nem kell félni, hogy nézzen körül a dolgokat. Rendben van. És több mint Billy. 

[Billy] Valójában, mielőtt elkezdem néhány tervezési cucc, Van valakinek bármilyen kérdése Ben bármit, hogy ő beszélt? Oké, rendben. Ismét, tudassa velünk, ha valami nem világos, vagy ha azt szeretné, hogy menjen át valamit, egy kicsit. Megyek, hogy lépjen vissza egy kicsit, és megbeszéljük a mélyebb részein design. Ben említette a modell neve - Sajnálom, a modell vezérlő view rendszer amely egyfajta technikai szempontból, így fogom nézni views konkrétan, és én fogom kezdeni, hogy azt alakítani egy véleményen van, hogy jól néz ki. Itt egyfajta nagyon alapvető sablont a Cat Facebook. Azt hiszem, van néhány alapjait a modern felhasználói felület tervezés , amelyeket érdemes felvenni. Lehet észre van egy sok fehér helyet az egész oldalt, rengeteg hely a dolgokat. Nem érzem, hogy a squash a dolgokat egy oldalra. Azt akarod hagyni sok hely nyitott, és ha megy, hogy szinte minden modern website látni fogja ott fehér mindenhol. Van fehér helyeken nem számítasz rá. Itt van ez a színpaletta, és ez bölcs az elején hogy válasszon egy színpalettát, hogy fogsz dolgozni és fejleszteni. Azt is - segít, hogy válasszon egy betűtípus, és így maga a fajta munka ezek a konkrét alapjait design. Megvan a típusát, akkor a színek, és akkor milyen illeszkedik minden mást, ha szükséges. Szóval, ahogy mondtam, a színséma szeretné használni a merészebb színek a színösszeállítás takarékosan. Fejlécek szép. A gombok jó, ha nagyon nagy, feltűnő színeket. De általában, ha van egy weboldal, amely a színek mindenhol, minden bámult meg az arcát, csak úgy néz ki, zsúfolt, és ez nem jó. Azt akarod, hogy általában használja a világos színek. Próbálja meg ismét, válasszon egy szép egységes színséma. Lehet, hogy ezeket a kis fröccsenő sok szín - hogy nézd nagyon szép, de szeretné használni őket elég takarékosan. 

Mint mondtam, azt szeretné, hogy minimális. Kevesebb, szinte mindig több. Ha lehet megjeleníteni valamit, vagy nem jelenik meg valami, és te olyan biztos abban, hogy meg kell ott alapból - talán te vagy a legjobb off elhagyása. Tudod mindig hozzá később. Igen, a dolgok egyszerű. De a legfontosabb, azt szeretné, hogy több tervez. Nem hiszem, hogy ha egy oldal, van ez a fejedben, hogy fogsz hogy az oldal egy bizonyos módon, és ez fog kinézni pontosan olyan, mint ez. Úgy megy, hogy a kék fejléc a tetején, és a kék oldalsó sáv majd a sárga al-header dolog. Azt szeretnénk, hogy több sablont. Akkor sem -, ha jó a Photo Shop, akkor nyissa meg a fel, és egyfajta tervezzen egy weboldal, ahogy tetszik nézni. Ha nem, akkor csak használ toll és papír, de a semmiből fel több tervez. Azt akarod, hogy alapvetően a létre, ahol sok különböző minták, és ha valaki végül működik, akkor ez nagyszerű. Ha végül nem, akkor mindig van egy másik fordulni. Általánosságban elmondható, hogy nem érzem, akkor meg kell korlátozni hogy bármilyen tervezés kezdetben dönt. Minták nagyon változó, és részben a fontosságát, hogy a modell vezérlő view rendszer, hogy lehet cserélni, és ki a különböző nézeteket akarsz. Lehet befolyással az adatokat egy út, majd úgy dönt, ó, tényleg, ez nem működik olyan jól. Azt hiszem, ez a fajta túl bonyolult, vagy van egy része, hogy itt ez nem igazán működik, úgyhogy csak úgy, hogy teljesen elhagyják ezt a nézetet, és csere egy teljesen újat. Mi továbbra is használhatja a régi modellek, és a régi vezérlők. Meg tudjuk csinálni mindent a szerver és a kliens, ahogy azt korábban. De a tényleges hullám az adatok jelennek meg lesz kicsit más. 

Ami valójában végrehajtása a tervezési akarsz, ha van egy pár terveket vázolt fel, hogy papíron vagy a Photo Shop, vagy bármi, számos eszközt, hogy rendelkezésre álljanak az Ön számára. Az első, hogy nagyon ismeri, ami a HTML, PHP, vagy bármi nyelv, amit használ, csak a kódot a statikus oldalak a honlapon. Már sokat dolgozott HTML milyen típusú ad e címkék hogy meg tudja fogalmazni dolgokat, és alapvetően ez egy módja a szervező a tartalmat. Például, akkor a fejléc ott, szóval lesz egy fejléc tag, és ez megy, hogy egy szöveg belsejébe, ami valószínűleg lesz egy másik tag. Akkor van egy sidebar talán néhány különböző linkek, és az lesz, hogy mind a címkék elválasztásához. Szóval, alapvetően HTML a szívében egy módja annak, felosztva a lap, hogy akkor végül szeretnénk formázni. Tehát újra, akkor már láttam ilyet. Maga nagyon kényelmes dolgozik most tekintettel arra, hogy tettél az elmúlt Pset remélhetőleg így nem lehet gond. 

Akkor CSS ami alapvetően kezeli a tervezés statikai szempontokat. Ez kezeli az összes szín, mind a különböző elemek elhelyezése, ahol mennek egymáshoz képest, mekkorák, a különböző positionings, amit kellett volna - Más szóval, akkor már a dolgokat rögzíteni, hogy mikor lépjünk le maradnak, vagy lehet dolgokat, mint a többi elem. Minden, ami a fajta cucc CSS. Ezen kívül, meg tudod csinálni a különböző díszítések, akkor a szöveg színét, szöveg effekteket, minden ilyesmi. Ben adott egy igazán jó szemináriumot az utolsó hétvégén, ezért azt feltétlenül nézd, hogy ki, ha azt tervezi, hogy csinál valami extra dolgot CSS. CSS3 valójában a legújabb verziója a CSS, és meg tudja csinálni mindenféle nagyon szép dolgokat. Meg lehet csinálni gradiens, akkor szép, lekerekített sarkok, meg tudod csinálni mindenféle dolgok hogy a webhely nézel ki, a modern és divatos. 

A következő eszköz JavaScript és jQuery amely Ben beszélgettünk egy kicsit, de én egy kicsit beljebb. JavaScript, ahogy már dolgozott vele egy kicsit, vagy legalábbis látta az előadást, egyfajta módon dinamikusan csinál dolgokat a HTML-ben. HTML, mint tudjuk, a statikus, így ha egyszer már a HTML nem lehet módosítani. De a JavaScript, bizonyos szempontból, egy módja annak, hogy képes módosítani a HTML. Szóval lehet csinálni, és ez nagyszerű, de JavaScript valóban a fájdalom dolgozni. Nagyon hosszú és tompa, és hogy még a legegyszerűbb dolgokat igényel sok sornyi JavaScript. Tehát, jQuery alapvetően egy könyvtár JavaScript, amely leegyszerűsíti az egésznek. Azt mondja, rendben van, ha azt szeretnénk, hogy egy négyzet jönnek a bal és beleolvadnak az oldalt úgy, hogy van a közepén, a JavaScript, amely figyelembe - Nem tudom, a száz sor csinálni, és ez a fájdalom, és akkor jön ki belőle gyűlöli mindent a webes programozás. JQuery akkor alapvetően az elem-dot-fade-in, vagy valami ilyesmi. Szóval, nagyon, nagyon egyszerű funkciókat, amelyek segítségével nem mindenféle hűvös animációkat és ez a fajta dolog. A másik dolog, hogy ezek a 2 nagyon jó csak tesz a dinamikus dolgokat a honlap. Tehát ahelyett, csak úgy, a HTML oldal - amely megjeleníti bizonyos adatokat, de valójában nem semmit - JavaScript és jQuery segítségével már gombok akkor kattintson, és akkor húzza elemeket, és újra, hogy őket, és rendezni őket, és az új elemek hozzáadása vagy eltávolítása. Felveheti-delete, ilyesmik. Tehát, jQuery nem tonna jó dolog. És Vipul valójában ad szeminárium ma, azt hiszem, az 5-órakor, így ha maradni, hogy a hosszú, amely - 5 vagy 4? Four. Bocsánat. Ez valójában jobb után, ezért azt javasoljuk, ragasztás körül, ha tudsz. JQuery szuper, szuper hasznos, és akkor képes lesz arra, hogy nem sok igazán szép dolog vele elég sok minden webes projekt. 

Most fogok bejutni a fajta megkülönböztetés. Már beszélt alapvetően a felhasználói felület. Felhasználói felület csak a design a helyén. De van valami más koncepció, amely a felhasználói élményt. A két nagyon különböző. Interface egyértelműen része a tapasztalat. Más szóval, ha elmész egy oldalon, akkor nézd meg a felületen. Ez is része, hogy azt tapasztalja, hogy az oldalon. De a felhasználói élmény több annál. Felhasználói élmény az, hogy mi a benyomása, hogy a felhasználó megkapja a saját honlapján is. Szóval, nyilvánvaló, felület egy része ennek. És ez mindenképpen szükséges része, de ez nem elegendő. Más szóval, ha van egy szép felület, és ez szép és színes, és minden az, hogy Ez nagyszerű, de ha a felhasználó megy a webhelyre, lát egy szép elrendezését, és ez zavarba Mindent, fogalma sincs, hogyan kell csinálni semmit, akkor nyilván már tett egy igazán szegény honlapján. Ez az a fajta, ahol a felhasználói élményt jön be Fogok beszélni egy kicsit a UX tervezés - UX rövid a felhasználói élmény - és milyen, hogyan lehet benne, hogy van egy jó felhasználói élményt. Az első pont az, hogy lehet, hogy tervezzen egy weboldal, ahol a felhasználó tud csinálni semmit, hogy a felhasználó esetleg akar. De ha a felhasználó nem tudja kitalálni, hogyan kell csinálni azokat a dolgokat - Más szóval, ha a felhasználó nem egy jó ötlet, ha megy a helyén, "Ó, ha azt akarom, hogy frissíteni a profil, akkor kattintson erre a gombra, vagy ha azt akarom, hogy tegye a valakinek a fal, aztán megy a fal és kattintson egy kis doboz. " Ha a felhasználó nem tudja, hogy akkor gyakorlatilag nem ténylegesen végre ezt a funkcionalitást helyesen. Része végrehajtása funkció, hogy a felhasználók valóban tudják használni. És lehet, hogy frusztráló - lehet, hogy egy oldalon, és meg tudja csinálni mindenféle csodálatos dolgokat, de akkor lesz az emberek tesztelni, és azt mondják: "Nem erre. Miért nem lehet ezt megtenni? ", És akkor azt mondják, vissza őket, "Nos, akkor. Csak ki kell menni a 7. legördülő menüben ez a homályos oldal, hogy csak talált egy linket a jobb alsó sarokban ", vagy valami. Nyilvánvaló, hogy nem akarja ezt. Azt akarod, hogy legyen egyértelmű, hogy a felhasználók számára, hogy mit kéne csinálni, és ez legyen egyszerű és intuitív számukra. 

A másik dolog, amit szeretnék, hogy ne próbálja, ha valaki fog menni a webhely és 10-ből 9-szer ezt a cselekvést, és 10-ből 1-szer do akció B, érdemes összpontosítani tapasztalat akció A. Más szóval, azt szeretnénk, hogy nagyon, nagyon világos, hogyan kell csinálni A. A legyen front-és-központ - megy az oldal, látom, ó, ott van. Mivel B nyilván azt szeretné, hogy egyértelmű, de hagyja, hogy egy kicsit több a háttérben. David ad egy jó példa erre az előadás, amely a T-bostoni rendszert. Amikor megy a Boston T és szeretne vásárolni egy jegyet, van, hogy a 5 menü, mielőtt ténylegesen a jegy megvásárlása a $ 2, $ 2,50 értéket, ami az, hogy mennyi kell ahhoz, hogy lovagolni a metró az egyik irányba. Ez a probléma, mert a legtöbb ember, aki a metrón valószínűleg csak akar menni egy helyre, megvenni a jegyet, hogy azonnal. Ennek nincs értelme, hogy át kell esniük sok különböző menük eljutni oda. A jobb felhasználói élmény lenne egy gyors gomb az első oldalon hogy csak azt mondja, "vegyél egy egyirányú jegyet", és hogy tenné az összes szabványos alapértelmezett értékeket, és ha valaki meg akarja vásárolni egy másik jegyet, mint az, még mindig, természetesen lehetősége van, de még optimalizálva A közös használat esetén, ami igazán fontos. Láthatjuk példa erre a Facebook-on, igaz? Ha megy, hogy a Facebook és a közzétenni kívánt állapotot, ez így van, a tetején, amely az, amit gyakran akarsz. Amint belépsz az oldalra, meg tudod csinálni a leggyakoribb dolog, hogy akarsz. Ha akarsz valamivel bonyolultabb dolgok, mint, mondani akarok menni barátom falán, és tegye a képet, hogy - amit majd akarok gyakran, de nem olyan gyakran, mint a kiküldetés állapot frissítések - Tehát ebben az esetben, azt írja a nevét, a doboz tetején, kattintson a profilját, majd, mégis, ez jobb felső sarkában ott egyszer kaptam a profil. Megint optimalizált kiemelt a legtöbb közös használati esetek. 

A másik fontos dolog az, hogy sokszor az emberek egyfajta megpróbálja megkerülni ezt mondván, oké, így már készül a helyszínen, és az emberek találjanak zavaró, és ez a gond, nem igaz? Nyilvánvaló, hogy nem akarom, hogy az emberek szabad összekeverni a tartalom oldalamon. De úgy megoldani, hogy ne legyen valami felbukkan mondván: hé, én fogom tanítani, hogyan kell használni ezt az oldalt. 1. lépés - kattints erre a gombra. 2. lépés - megy itt. Persze, ez egy út körül - ez egy módja annak, hogy meg tudod mondani az embereknek, mit kell tenni, de ez valóban nem az optimális utat. Ha elmegyek egy honlapot, és hirtelen én bombázzák ez a bemutató, ami azt mondja mit kell tenni, és hová megy, és minden adott, hogy ez nem vicces. Ez nem egy jó élmény volt számomra. Ez egyfajta fájdalom. Azt akarom, hogy csak elkezd csinál dolgokat. Az emberek fognak zárni a párbeszédablak, vagy kijutni a bemutató, és nem tudja, mit tegyen, majd panaszkodni, mert még nem mondta nekik, mit kell tennie. Az út, hogy megoldja ezt nem azáltal, hogy semmiféle bemutató vagy irányban - ilyesmi. Amennyire lehet elkerülni azt, szeretné megmutatni a felhasználónak, mit kell tenni csak a természet, hogy a weboldal lefektetett. Más szóval, ha elmegyek Facebook bejelentkezés nélkül, Az első dolog, hogy látom a főoldalon - ez egy kicsit bejelentkezési ablak. Tehát, duh. Meg kell bejelentkezni Ott van. Mivel, ha én elmentem a Facebook és volt, hogy kattintson egy kicsit linkre alján hogy azt mondta: "be" és a többi lap csak valami kép, vagy valami, Én nem igazán tudom, mit tegyek, nem igaz? Én szabad összekeverni. Szóval, lehet mondani, hogy menjek oda, és kattintson a gombra, hogy jelentkezzen be, vagy a belépés gombbal lehet jobb felső sarkában, ahol fogom látni. Azt akarod, hogy mindig megmutatja a felhasználónak, mit kell tenni, és hogy kell rejlő magán az oldalon. 

Ha gondolkodik tervez és gúnyos fel különböző módon kifejezi az oldalon, akkor igazán akarok gondolni, amit a felhasználók fognak csinál, és hogyan tudja mutatni nekik, mit kell tennie. Még egy utolsó dolog tesztel nagyon, nagyon fontos. Ez nagyszerű, hogy valaki -, hogy egy barátom, hogy valaki nem tudja még - aki soha nem látta a helyszínen, mielőtt használja az oldalt. Mivel már dolgozik a helyszínen az óra, akkor már bámulta, és pontosan tudja, mit kell tennie, így nyilván fogsz, hogy teszteli a dolog, hogy már dolgozik, és hogy tudod a munka. De ha valaki jön, és használja a helyszínen, hogy soha nem használt ilyet, ez egy különleges élmény, mert van valaki, akinek nincs előzetes ismerete Az oldal megy, így fognak ténylegesen fogalmam sincs, mit kell csinálni vagy milyen használati esetek vannak jelen a számukra. Ez nagyszerű. Ez az egyedülálló, mert ők alapvetően egy személy, egy üres elme. Azt lehet mondani, ha valami zavaró vagy nem egyértelmű. Úgy adhat egy ötlet éppen a felhasználói élményt a webhely. Ez nagyon nehéz megmondani, hogy magát, így mindenképpen azt javasoljuk, ahogy te fejlődő projekteket - ha csinálsz web-alapú projektek - hogy az emberek az oldalon már van valamilyen funkcionális demo. 

Most fogok beszélni egy kicsit arról, hogyan kell kezelni a webes projekt. Már ment át, hogy meg tudod csinálni a technikai back-end oldalon, hogyan lehet alakítani egy igazán jó hely, és ez jó, ha dolgozik egyedül, de - akkor is, ha dolgozik egyedül, és főleg, ha dolgozik egy csapat, projektmenedzsment lesz egy nagy kérdés. Már a fajta hallott projektmenedzsment különböző formákban, mivel általános iskolában, amikor azt mondták, csoportmunka. Meg kell együttműködni, kommunikálni, meg minden. Mindez továbbra is érvényes, de van néhány különleges körülmények számítógép-tudomány, amely azt szeretné, hogy tisztában legyenek, és szeretné, hogy győződjön meg róla, kezelni is. Beszélni fogok először egy kicsit a csapatot, hogy akkor, hogy be Nagyon fontos, hogy vegye a megfelelő méret a csapat, hogy dolgozni, és a projekt végső Azt hiszem, a lehetőséget, hogy válasszon 1 és 4 fő, ha nem tévedek. Azt szeretnénk, hogy győződjön meg arról, hogy te nem csak a választás az embereknek a száma , hogy szeretne dolgozni, mert ők a barátaid. Azt akarod, hogy válasszon egy csapatot, hogy ez egy jó méret, és, hogy megkapja a munkát. Van egy kompromisszum, mivel több ember szemben kevesebben. Ha több ember, természetesen több munkát lehet végezni mert van sok ember, sok olyan kódot, rengeteg ötlet, és ez minden nagy. De ez is igényel sokkal több menedzsment és sokkal több a kommunikáció. Más szóval, ha van 4 ember dolgozik ugyanazon projekt és ezek mind szerkeszti ugyanazt a kódot, többé-kevésbé mindannyian fajta kell tudni mi folyik itt, ezért követeli, - ha néhány új funkcióval a fajta kell mondani az embereknek - Én ezt hozzá, Én változtass ezen a módon - különösen, ha kap az igazán mély dolgokat mint a modellek, és a vezérlők, hogy valóban fog befolyásolni, hogy hogyan is működik az oldal. Az egész csapat tisztában kell lennie azzal is, így meg kell, hogy megbizonyosodjon arról, hogy nem választotta túl nagy a csapat, hogy ez nehéz lesz , hogy ezt a kommunikációt. Ön még nem szeretne választani, elég kicsi ahhoz, csapat, akkor nem fog képes kommunikálni, mert ez csak neked. 

A másik dolog, hogy fontolja meg az egyensúlyt, ahol az emberek a készségek. Nagyon jó, ha mind nagyon jó programozók. De ha minden back-end emberek, akkor a webhely nem fog nézni nagyon jó mert van ez a nagy adatbázist, és ez nem a szuper-gyors keresési lekérdezések - ami nagyszerű - de ha megy rá, ez olyan, mint a 1990-es telek, vörös és kék mindenhol, és ez nem jó sem. Figyeljük meg, hogy Ben és én dolgozni, mint egy csapat nagyon szép, mert én vagyok a fajta több a front-end, mindketten egymásra a közepén-end, és Ben nagyon jó a back-end cucc, így működik igazán jól, mert tudjuk tervezni bármely helyszínen, és alapvetően a lyukak abban a helyszínen, hogy ki kell tölteni lehet tölteni akár egyikünk, vagy esetleg mindkettő. Azt szeretnénk, hogy győződjön meg arról, hogy nincsenek lyukak a csapat. Nem baj, ha van egy kis átfedés. Más szóval, ha van 2 ember, hogy egyszerre jó a hátsó, lehet jó is, mert ezek segíthetnek egymásnak problémák hogy vannak. Ez lehet a probléma, ha csak 1 ember, aki felelős egy bizonyos dolog és befut a probléma, ezért nem akarjuk, hogy egy kis átfedés de ami a legfontosabb, szeretnénk, hogy győződjön meg arról, hogy az összes lehetséges lyukak vannak töltve. 

Az utolsó dolog - és ez nyilvánvaló, de gyakran nem. Azt akarja, hogy jól érzik magukat. A lényeg az utolsó projekt CS50, és gyakran a pont webfejlesztés általában nem csak ezt a munkát, mert szüksége van csinál. Azt akarja, hogy jól érzik magukat, és azt szeretné, hogy, hogy valami ami motiválja, hogy dolgozni rajta. Ha bármit is, hogy a fájdalom, hogy üljön le, és a munka, akkor nem választott a projektet. Azt akarod, hogy válasszon valamit, amit érdekesnek talál, szeretné látni az eredményt, hogy izgatott vagy, ha kap egy új ötlet, valami, amit tehetne - így van mindenféle projektet, hogy ott vagyok benne megtalálható - mindenkinek van valami, ami igazán intrika őket ha csinálsz egy web-alapú projekt. Azt mondom, hogy újra most. Ha a projekt úgy tűnik, mint a fájdalom, és nem akar dolgozni rajta, válasszon egy másik projekt. Válassza ki valamit, ami igazán inspirál. 

Ben említette ezt a fogalmat az iteráció egy kicsit, és azt akarom, hogy menjen át egy kicsit. Nagyon fontos, hogy a spurts hol beszerezni valamit működőképes. Ez lehet jó, ha ezt a tervet egy honlapon, hogy fog tenni A, B, és C, és végül, hogy fog. De te megragadt ebben a szakaszban, ahol dolgozunk, és dolgoznak rajta, de semmi sem készül el. Nem kell semmit látni és kézzelfogható, működő dolog. Amit igazán akar csinálni, mint amilyennek látszik egyfajta fájdalom néha dolgozni valamit, aztán valami sapkát le úgy, hogy ez legalább egy stabil, futás verzió akkor is, ha nem rendelkezik az összes kívánt funkciókat. És talán vannak olyan jellemzők, amit igazán akar felvenni, de nem tudod azért, mert azt szeretnénk, hogy ezen az oldalon, hogy a funkcionális szempontból. És így szeretné, hogy milyen, hogy a teljes fejlesztési folyamat így néz ki. Azt akarod, hogy kezdeni valahol funkcionális - és lényegében kezdődik semmit - de szeretné, hogy valahol nagyon egyszerű és funkcionális. És akkor megint, hogy egyfajta ugrás és kap valahol funkcionális újra. Majd lassan felépíteni, és ez is megy egy kicsit lassabban, mint egyébként, de hosszú távon, ha állandóan ragadt ebben a középutat fázis, ahol valójában nem semmi munka, ez lehet egy igazán nagy frusztrációt dolgozni a projekt, mert te mindig olyan közel szerzés ez működik, és ez soha nem működik. Azt akarod, hogy dolgozni a funkcionális spurts, és azt is szeretné, hogy némi gondolkodás után mindegyiket. Más szóval, ha már olyan helyen, ahol a helyszínen már dolgozik - nem kell mindent, amit szeret, de ez nem bizonyos dolgokat - szeretnénk gondolkodni, oké, ez a honlap megvalósítása a cél, hogy azt tűzte ki, hogy csinálni? Más szóval, ha az oldal fog csinálni X, az, amit már dolgozik irányába X? Vannak az összes funkciót, amit szerettem volna ott? Sőt, van, hogy szolgálja az átfogó cél, amit akarok? Ha megállapította, hogy a webhely kezd irányt egy másik irányba vagy talán a dolgok csak egyfajta nem dolgozott ki, lehet, hogy ideje váltani fogaskerekek egy kicsit. Más szóval, akkor érdemes megfontolni - érdemes tippeket adok, ha szükséges, és figyelembe véve, én igazán dolgozik, amit én akarok lenni. 

Azt hiszem, ez az én következő pontot. Ne félj, hogy hagyjon fel ötleteket. Csak azért, mert töltött sok órát dolgozik a funkció és végül megkapta ez működik, de ez tényleg nem megy olyan jól - mintha nem az, hogy hasznos vagy felhasználók gondjai használja - az ilyesmit - ne félj, hogy dobja el. Szívás, hogy már töltött sok időt dolgozik rajta, de végül nem akarod a helyszínen, hogy ez a fajta össze ezek a darabok, amelyek a fajta munka, de nem olyan jól szolgálja. Továbbá, ne félj, hogy átfogja az új ötleteket. Ha valaki jön, és azt mondja, hé, hogy a webhely néz ki, nagyon jó, de nem lenne még jó, ha az is volt ez? Csak azért, mert ez valami, hogy nem áll szándékában, és valamit, ami nem a szemüveg, valami, amit még nem tűzte ki, hogy nem, ne félj, hogy vegye be, majd dolgozni vele. Mivel gyakran az ötlet, hogy futtatni egész folyamán a fejlődés a végén, hogy az igazán nagyszerű tulajdonsága a honlapon. 

Már mondtam ilyet. Elmondom újra. Tesztelők szuper, szuper hasznos. Próbálj meg az emberek, akik még soha nem láttam a helyszínen, mielőtt, hogy jelentkezzen be, hogy mi történik mert nem csak a teszt a hasznosságát a helyszínen, és a felhasználói élmény, de ők is tesztelni a funkciót oly módon, hogy nem lehet. Ha azt, hogy néhány funkció, amely nem egy bizonyos dolog és tudod, hogy meg fog tenni, hogy ugyanazt a dolgot helyesen minden egyes alkalommal, ez nagyszerű. De gyakran nehezen megmagyarázható sarokba az esetben, ha a felhasználó esetleg írja be valamit, amit nem számítottam - pontosan azért, mert amit megadtál a funkciók magad. Tehát, hogy valaki jöjjön az, akinek fogalma sincs, hogyan kell használni az oldalon és hogy csak törni, bármilyen módon tehetnek igazán hasznos, mert kap egy ötletet, egy teljesen más szemszögből, amit a honlap működik és ami javításra szorul. 

Végül fogok beszélni néhány általános jó gyakorlatok, és akkor már láttam egy csomó ezek CS50, de ők is nagyon, nagyon alkalmazzák a projekt környezetben. Az egyik megjegyzés. Mindig megjegyzést a kódot, főleg, ha dolgozik egy nagy csapat. Ez annyira bosszantó, hogy csak egy óriási kódrészleteket, hogy valaki írt és lehet, hogy működik, lehet, hogy nem, de fogalmam sincs, mit csinál, így fogalmam sincs, hogy ez hasznos-e vagy sem, vagy hogy kell ott lennie, vagy sem, és ha dolgozik valami más ez is lehetséges, hogy dolgozunk ugyanaz a dolog, úgyhogy nagyon-nagyon óvatos, figyelmes a többiek és kódot írni, ami jól dokumentált. Nem megy el odáig, hogy ezt az egészet, ahol tetszik, ha növelni egy számláló van egy megjegyzés, amely azt mondja, én vagyok hozzá 1 a számláló. Nem kell, hogy a részletes, de minden olyan funkciót, amit valaha is írt érdemes néhány dokumentációjában, hogy mi a funkció pontosan nem, amit a bemenetek, és mit ad vissza. Így lehet használni más emberek elemei a helyszínen és tudod dolgozni épület valami nagy. 

A másik fontos dolog, amit akarok, a rendszeres kármentesítés. Kód lesz piszkos. Ne érezd magad rosszul, ha a kódot csak teljesen olvashatatlan, és egy hatalmas rendetlenség. Ez történik a webfejlesztés mindig. Te új funkciókat, eltávolítja a régiek. Stuff lesz ott, hogy nem kell. Ez rendben van, de azt szeretnénk, hogy győződjön meg róla, hogy foglalkozzanak ezzel rendszeresen. Nem akarod, hogy hagyjuk, hogy létrejöjjön az a pont, ahol egyszerűen nem talál semmit a kódot, és fogalmam sincs, hogy mi bármit csinál. Ez a helyzet a HTML. Néha akkor a végén a tárgyat, amely nem tartalmaz semmit, és akkor szeretnénk megszabadulni e. A CSS, akkor lehet utalva elemeket, amelyek nem létezik többé, így szeretne megszabadulni, hogy a kódot. A JavaScript, lehet, hogy ki valamit a HTML. Szóval, azt szeretnénk, hogy győződjön meg arról, hogy te mindig a takarítás, a dolgok elég annyi, amennyit csak tudsz, rendszeresen. 

Egy másik nagyon hasznos dolog, nem hiszem, hogy a felvázolt nagyon sok CS50 de érdemes bekerülni verzió ellenőrzés. Az az elképzelés, verzió ellenőrzés, amikor alapvetően nyomon követése minden haladás amit tett felé a webhely, és ha bármikor rájössz, ó, ez működött egy ideje, de ez nem működik többé, akkor menj vissza a korábbi verziók és mi változott azóta, és az ilyesmit. Az elsődleges módja, hogy a Git és Git ez az egész ilyen rendszer Azt hiszem, Tommy MacWilliam tartott szemináriumot a múlt évben. Ha bemegy a CS50 szemináriumok 2011, láthatjuk a szeminárium ezt. Az az elképzelés, Git alapvetően, hogy rendszeres időközönként te, hogy ezeket a kötelezettségvállalásokat amelyek módon azt a helyszínen van egy elég stabil verzió most így Én csomagolás fel, és küld el a szerverre, és akkor mehet a szerveren és nézd meg az összes korábbi verziói a kódot, és látni, hogyan fejlődött és minden fajta jó dolog. Szóval, ez alapvetően azt. Ami a webes fejlesztés, örülünk, hogy maradjon, és válaszoljon a kérdéseket, mint amennyire a bemutatót. Ennyi. Köszi. >> [Ben] Köszönöm. [Taps] 

[Billy] Staff, van valakinek bármilyen kérdése van a dolog, amit már lefedett vagy a dolgokat, hogy már nem vonatkozik, hogy abban a reményben, mi lenne fedezni? Szívesen válaszolni ezekre. Valaki? [Közönség tagja] Mi az előnye és hátránya a Ruby vagy Python? [Ben] A kérdés az volt, mi az előnye és hátránya a Ruby és Python ahelyett, hogy, mint a PHP. A profik az, hogy Ruby és Python sokkal jobb nyelvek, mint a PHP. Legalábbis véleményem, és azt hiszem, egy csomó más emberek véleményét is. Ezeket úgy tervezték, még csinál összetettebb dolog, és kevésbé a kolosszális együtt weboldalak nagyon gyorsan egy kicsit a dinamikus tartalom. A hátránya az, hogy van egy kis - van még egy tanulási görbe kell kérni őket létre. Ez azt jelenti, mint a PHP, akkor csak egy HTML fájlt, és írsz kevésbé, mint a, kérdőjel, és akkor írni egy kis kódot, majd írsz kérdőjel, nagyobb mértékű volt, és akkor kész. Más nyelvek, mint a Ruby vagy Python, van, hogy menjen át egy kicsit több munkát kap az eredeti helyén fut. Van még - legalábbis ez szokott lenni a helyzet -, hogy van több dokumentáció rendelkezésre a PHP csak azért, mert egyre több ember használja. Azt hiszem, ez nem olyan nagy probléma többé. Ez természetesen nagyon jó dokumentáció dolgok, mint a Ruby on Rails vagy Django Python egyenértékű. PHP az egyik, hogy mindenki használ évek, és tudod, hogyan működik. Ruby és Python egy kicsit kevésbé érett. 

[Közönség tagja] Ha úgy döntesz, hogy választani közülük, hogy tanulni, vagy vegye fel, melyiket választaná? Őszintén szólva, azt hiszem, hogy attól függ, hogy a személy. Sajnálom. A kérdés az volt, ami felveszi valaki tanulni? Találom Python a legszebb személyesen. Van egy csomó ember, akik - nem az első web dev projekt Python és Django. Van egy csomó ember, akik szeretik a Ruby on Rails is. Valószínűleg több ember, akik tudják, Ruby on Rails. Őszintén szólva, én csak megy, amit az emberek tudják úgy, hogy az emberek kérdéseket feltenni. 

A kérdés az volt - megosztott szervereken ez elég nehéz dolgozni Python? Ez attól függ, a tárhely. Számos webtárhely, hogy tegye Python dolgokat. Webfaction teszi, igaz? Webfaction az egyik, hogy Billy és én már használt néhány projekt. Ők igazán nagy. Ezek támogatják a legtöbb nyelven. De az igaz, hogy a PHP sokkal szélesebb körben támogatott. Tehát, ha elakad egy internetes fogadó, hogy csak nem a PHP, hogy ez egy jó ok arra, hogy a PHP. 

[Közönség tagja] Most kaptam a tanulás, hogyan kell lekérdezni bizonyos adatbázisokhoz, és tudom, hogy az SQL egész hely, de az utóbbi időben kapott kitéve - és mutatott ki. Látod JSON és bővíthető adatbázisok. My SQL továbbra is az egész hely. Hogyan látja, hogy történik? Van-e lesz a növekvő tendencia tovább bővíthető (nem hallható)? A kérdés az volt - gondolom, ott lesz a tendencia nem SQL adatbázisok. Például, mint a MongoDB. Azt hiszem, ez mindenképpen igaz. Az én tanácsom többnyire mySQL kapcsolatos, itt csak azért, mert a MySQL ipari szabvány. Én személy szerint sokkal jobban adatbázisokat, amelyek nem rendelkeznek schemos mint MongoDB ahol nincs kérdés, ó, szükségem van egy újabb oszlopot. Jaj nekem, mintha bármit csináljak? Ez nagyon nehéz megtenni, hogy a MySQL, de ha van valami, mint Mongo ez sokkal szebb. A másik szép dolog Mongo az, hogy a rekordok valójában JavaScript objektumok. Nincs valami átalakítási lépés, ahol meg kell, hogy ezen adatbázis sorok és kapcsolja őket egy JavaScript objektumot, majd elküldi őket a vezetéket. Azt hiszem, ilyesmi lesz nagyon hasznos a gyors web-fejlesztés a jövőben. 

[Billy] Valami Hozzátenném, ami csak egy általános lényeg az, hogy Nem érzem, hogy kellett szereznie az összes nyelv általunk tárgyalt A szeminárium. Természetesen a lényeg az, hogy ön egy eszme, mi van odakint, és ha kíváncsivá minden olyan dolog, amit már említettem akkor google őket és olvassa fel őket. És ahogy már említettem, van néhány szemináriumok foglalkoznak, hogy pontosan ezeket a dolgokat. Vannak még több szemináriumot, amit még nem említettem, hogy talán kap ez a cucc is. Az ötlet az, hogy ha szeretne dolgozni valamit, itt van az eszközöket az Ön rendelkezésére. Nem érzi, túlterheltek, ha nem tudjuk, mire ezek az eszközök pontosan, de tudom, hogy ott vannak, és tudod, hogy széles körben használják őket a Google. 

[Közönség tagja] Milyen dolgok, amit tennie kell, hogy ellenőrizze, hogy a website jól néz ki a mobil eszközök? [Billy] A mobil eszközök egy kicsit nehéz. Van 2 módon lehet megközelíteni. Az első út az, hogy valóban van egy mobil weboldal. Más szóval, ha végre valamilyen kimutatási elején amikor a böngésző, hogy a kérést a honlapon, amely vagy azt mondja, vissza ezt a nézetet - melyik lesz a nézetet asztali vagy hordozható böngészők - és ez a másik nézetet a mobil eszközök. Ez egy olyan hely, ahol a nézetek nagyon kedves, hogy akkor elég sok csere a kettő, és egy felületet, hogy működik nagyon szépen a mobileszközökön , és egy teljesen más, ami működik szépen böngésző eszközök. A probléma az, hogy ez sok időt vesz igénybe, mert ez azt jelenti, kódolás egy teljesen más felületen. A másik út, hogy meg tudod csinálni, hogy - Sok modern telefonok jelenik weboldalak és próbálja teszi őket, mint egy böngésző lenne, és ők nem a legjobb. Tudod milyen próbál maradni fény mennyiségét jQuery JavaScript, amit használ amely hajlamos arra, hogy ahol a dolgok rosszra egy kicsit. Ez a fajta az út, hogy akkor érdemes használni, ha nincs annyi időnk. Ha van időd, hogy dolgozzon ki egy mobil felületen, ez nyilvánvalóan a legjobb választás. 

Azt hiszem, általában CS50 projektek fogsz szeretné választani egyik vagy a másik. Más szóval, azt szeretnénk, hogy egy mobil alkalmazás, vagy azt szeretnénk, hogy egy asztali weboldalon. És ez a fajta határozza meg, hová mész vele. De ha azt akarjuk, hogy bontsa ki később, talán a legjobb megoldás az, hogy egy másik felület a többi. Van egy kis tapasztalat a fejlődő WordPress-alapú oldalak. Én otthont egy személyes honlap a WordPress egy darabig. Ilyen jellegű keretek is lehet szép, csak nagyon alapvető dolgokat. Gyakran akkor csak befut sok testreszabható kérdés mégis. Azt akarja, hogy valami meg egy bizonyos módon, vagy egy bizonyos módon és nem tudod, mert nehéz vezetékes a rendszer ez hogyan kell csinálni a dolgokat, amely lehet egy kis probléma. Azóta a fajta volt, hajlamosabbak dolgozni helyek az alapoktól kezdve. A dolgok, mint a blog, adatbázisokat és az ilyesmit, hogy ez tényleg nem olyan nehéz, hogy egy keretet. Ha tényleg feszített az idő, akkor természetesen használhatja valami, mint a WordPress vagy ilyesmi a blog. A dolgokat, hogy a blogok tárolni, és nem nem igazán elég nehéz, hogy ha fut be bármely ilyen jellegű dolgokat, akkor talán a legjobb, csak azért, hogy hogy egy házon belüli változatban. 

Azt hiszem, ennyi, ezért még egyszer köszönöm, hogy eljöttek. Igazán élveztem veletek szóba, és remélem, hogy megtanultam néhány dolgot. [Ben] Örömmel beszélni - el kell menni, de örülünk, hogy beszéljen több külső ha van egy másik kérdés. Még egyszer köszönöm. [Taps] [CS50.TV]