[Powered by Google Translate] [Seminario] [Web Development: El Ideo por Efektivigo] [Ben Kuhn] [Billy Janitsch] [Universitato Harvard] [Ĉi tiu estas CS50] [CS50.TV] [Billy] Saluton, mi estas Billy kaj ĉi tiu estas Ben. >> [Ben] Saluton. Ni iras por paroli pri ttt evoluo hodiaŭ. [Webdev] [Billy Janitsch kaj Ben Kuhn] Iom pri ni unue. Ben estas speco de la dorso-fino ulo. Li faras tion labori. Kaj poste mi iros kaj faros ilin belaj. Mi estas grandparte implikita kun pli front-end aranĝo dezajno speco de ŝtofo, Kaj Ben, aliflanke, ĝi scias kion faras tia li laboras sur dorso-fino vazaro. Kune ni faris kelkajn aferojn. Ekzemple, pasintjare ni laboris sur Gimblium kiu estas interreta ludo evoluo studio. Tio estis nia lasta projekto por la klaso, kaj ekde tiam ni jam faris Harvard Klaso kio estas reta kadro por foliumi kaj aĉeti kursoj ĉe Harvard. 

Ni tuj komenci kun tiu ideo por nia retejo. Ni tuj faros Facebook, sed por katoj. Antaŭ vi reale fari ĉi tiu retejo, ne faras ĉi tiun retejon ĉar ĝi ne estas bona, sed ni uzos ĝin kiel kadro kaj trairu la procezo de kiel ni prenu tiun ideon kaj igi ĝin vera retejon ni povas uzi. Ni komencu per rompanta la retejo malsupren. Kiel vi estis faranta en CS50, vi volas pensi pri kio estas la efektiva komponantoj kiuj iros al tiu retejo. Esence turnante gxin de ideo, kiu estas ĝuste ia abstrakta koncepto en la reala, palpebla, kion vi povis fari. Ni komencu per demandante iujn demandojn. Kio estas ĉi paĝo? Kial ni faras ĝin? Kio estas ĝi tuj estu uzata por? Ke tia afero. En la kazo de Facebook Kato, ni esence volas retejo kiu ebligas katoj socia reto kun ĉiu alia. La ideo estas ke oni povas sendi en alies muroj, Ili povas fari komentojn, ke tiaj aferoj. Kaj tio estas kie ni venos en la funkciaj komponantoj. Ni nun havas tian kadro de - ni havas uzanto profiloj, ni havos komentojn, kaj ni povos sendi. Eble iam ni influa homo kaj tiajn aferojn. Kaj ni ia volas primar tiujn trajtojn irante in Ni volas diri kiel, bone, tio estas vere grava, ke ĉiuj havas profilon kaj ke ĉiu povas afiŝi en alies muroj. Malĉefa al tiu, komentojn estus agrabla. Eble poste ni influa homo. Do, vi volas havi ideon pri kio estas nepre necesa por via projekto kaj kio estas speco de pli ĝenerala trajto kiu povus esti aplikata poste. Vi volas ian havas specifan listo en menso, sed la projekto ke vi komencu per ne tuj estos la projekton ke vi finas kun. En aliaj vortoj, tion tuj ŝanĝos dum vi evoluantaj la lokon, kaj vi volas lasi spacon por tio. Mi igos ĝin al Ben, kiuj tuj paroli iomete pri la strukturo. 

[Ben] Mi iras por paroli pri la pli teknika flanko de ttt evoluo. Ni simple iru super iu basics unue. Kiam vi faras retejo app, la ĉefa divido ke vi tuj devas havi estas Vi tuj havos kelkajn necesajxojn okazanta en kliento flanko - tio estas, la kodo kiun vi estas retumilo prenas de la retejo kaj la Javascript, HTML, CSS vazaro. Jen ĉio pri la kliento flanko. Vi tuj havos aliajn kodon kiu funkcias sur la servilo kiuj subtenas spuro de ĉiuj datumoj, ke homoj sendu al vi, decidu kiu donos kio, da tio. Ĉi tio estas nur iuj terminaro por ke vi uloj estas ĉiuj familiara kun kio ni parolas. Preter tio divido estas bone pensi pri via ttt app en terminoj de paro de klaraj komponantoj. Kiam vi faras ttt evoluo unu el la aferoj, kiujn vi devus ĉiam provi fari estas redukti kompleksecon. Ju pli kompleksa via kodo estas la pli ŝancon tie estas fari cimojn, la malfacila ĝi estas ŝanĝi poste. Do, se vi povas disrompi vian app en kelkaj distingaj funkcia areoj kiuj volas - kaj vi povas malpliigi la varon de kvanto de kruco-spaco komunikado - kiuj helpos vin tre longtempe en terminoj de reduktanta cimojn. 

Por esti konkreta, kutime homoj disdividi retejo app en - jen estas ia zumado vortoj nun, sed ili estas ankoraŭ utila. Vi eble aŭdis homojn paroli pri modeloj, vidoj, kaj regiloj. Modeloj estas la realaj datumoj ke via app tuj pritrakti. Por ekzemplo, en viaj Kato Facebook, viaj modeloj estus - Vi ŝatus havi modelon por kiel afiŝojn, kaj modelo por uzanto profiloj, da tio. Viaj opinioj estas kiel vi prezentu tiu datumo por viaj uzantoj. Vi eble havas 1 vidon por rigardi sola fosto kaj cxiuj komentoj kaj malsaman vidpunkton pri via muro kiu havas liston de ĉiuj afiŝoj ke estas direktitaj al vi, kaj malsama vido por via novaĵo-servo - necesajxojn kiel tio. Fine, vi havos la regiloj kiuj estas esence kiam homoj sendas vin afiŝojn kaj vi faros ĝisdatigoj por via dorso-fino sistemo, vi pliigo faskon da vendotabloj, kaj kio ajn. Tiuj estas viaj regiloj. 

Mi iras por paroli plejparte pri modeloj. Vidoj estas teknike ne tiu malfacila kaj la temo estas pli kun desegni ilin Regiloj tuj estu specifaj al kiom vi desegnante. Sed estas iu bela ĝeneralaj teknikoj oni povas uzi fari viajn modelojn pli agrabla kaj pli facile labori kun tiu mi pensas estas tre helpema. Tio estas plejparte tuj estos pri kiel trakti kun via retejo apps datumoj en bela vojo. La ĉefaj temoj kun modeloj estas ke ili vivas sur la kliento kaj la servilo kaj vi devas diveni a) kiel akiri ilin - ĉiuj gravaj aĵoj - de la servilo al la kliento, kaj b) kiel gardi ilin en sync. Viaj uzantoj tuj volas fari iujn ĝisdatigoj. Ili tuj volas fari novajn afiŝojn. Ili tuj volas ŝatas tion kaj Okaze se vi havas gustojn. Tiuj estas la ĉefaj teknikaj defioj de kontraktanta kun modeloj. La unua afero, kiun vi tuj volas demandi vin mem estas kia datumoj iras en tiun modelon kaj kia pridemandojn ni tuj volas fari - tio estas, kiel ni tuj rigardi la modeloj? Por viaj Kato Facebook ekzemplo, via afisxo tuj havos aŭtoro asociita kun ĝi, iu muro tekston, kaj ricevanto de la muro post. Kaj tiam vi eble volas demandi ke en faskon de malsamaj manieroj. Vi volus rigardi ĝin per kiu verkis kion post, per kiu ricevis kiu sendi, eble laŭ la dato ili estis eldonita. Sed se vi faros tion laŭ dato, tiam vi devas aldoni alian kampon por via afisxo de kiam ĝi estis reale afiŝis. Tiuj 2 faktoroj - kion datumoj vi volas uzi kaj kiom vi volas rigardi ĝin - vi devus pensi pri ili unue ĉar ili dependas de ĉiu alia, kaj gxi tuj estos pli malfacila por aldoni ilin poste. 

Ekzistas kelkaj aliaj konsideroj. Kiam vi pensas pri tio, kiel vi agas kun modeloj en la servilo kion vi volas rigardi estas - vi esence volas fari la servilon tiel simpla kiel ebla. Farante necesajxojn sur la kliento flanko estas ĝenerale multe pli rapide, se vi povas fari ĝin pure en la kliento sen fari ian reton peton. La ideo estas fari kiel multaj el la pridemandojn kiel vi povas sur la kliento. La sola problemo pri tio estas ke, se vi petos ĉiuj viajn datumojn al la komenco tiam, ke tuj prenas longan tempon ŝarĝi. Do, la ideo estas bati feliĉa mezaj inter havi sufiĉe da datumoj en la kliento ke vi povas fari plimulton de via laboro tie sed ne nur ricevado ĉio samtempe tiel ke vi ricevas vere malrapida ŝarĝo fojojn en la komenco. Ekzemple, por via kato datumoj vi verŝajne volas venigi faskon da freŝaj muro afiŝoj. Vi ne volas venigi ĉiuj el ili ĉar tio povus reiri paro da jaroj. Sed vi ne volas venigi ilin unuope ĉar tio estus enkonduki multajn reto superkape. 

Ĝi estas ofte tre malfacile - kiam vi havas datumbazon kurado - ĝi estas ofte sufiĉe malfacile ŝanĝi kion datumoj vi havas en ĝi - te aldoni novan datumbazon kolumno aŭ io - tial unu bona strategio estas fakte ĝuste teni multajn viajn datumojn en teksto blob - a JSON blob - JSON esti JavaScript Objekto Skribmaniero - La kialo, ke estas utile estas ĉar tiam vi povas aldoni novajn propraĵoj al ĉiu el tiuj JSON _blobs_ sen ŝanĝi vian datumbazon. La sola malavantaĝo al tio estas ke, se vi havas faskon da kampoj ke vi aldonis poste - kiel kaŝita en tiu JSON blob - tiam ĝi estas pli malfacila por konsulti ilin ene de la datumbazo. Ekzemple, se vi poste - se vi havis vian postenon modelo kiun ni diskutis pli frua kun nur la aŭtoro, la ricevanto kaj de la teksto - vi povus havi ankaŭ JSON blob kaj poste, se vi poste volas aldoni iun daton kampo vi ne devus ŝanĝi vian datumbazon. Vi povus simple aldoni datojn al ĉiuj de la teksto kampoj. Kaj tiam vi povos rigardi tiujn sur la kliento flanko sed vi ne povos konsulti ilin sur la servilo ĉar ĝi estas kaŝita en tiu teksto. 

La alia afero ke vi volas pensi pri estas kiel via kliento kaj la servilo tuj komuniki. Vi kutime deziras teni ĉi tiel simpla kiel ebla. Vi povas nur devas kiel get-min-ĉi datumoj peton, oni kreos-a-nova-objekto ion kaj ĝisdatigon-an-malnova-objekto peton. Kaj ĉi tiuj ĉiuj estas malsamaj URLoj en servanto, ke vi - ke la retumilo havus - vi povas uzi AJAX petoj por ĉiuj el tiuj kaj ĉu ricevi aŭ post datumojn. Denove, por nia kato Facebook ekzemplo, vi povus havi tiun URL por akiri individuan post, kaj vi havus la URL por kreado de nova muro post kaj eble la URL por alŝuti vian profilon bildo, da tio. Sed denove, tio estas al la antaŭ-fetch plejparto de viaj datumoj por ke vi ne devas teni farante reto petojn. Por tiu kialo, eble vi ne volas havi tiun individuon get peto por unu posteno, kaj anstataŭ vi volas nur 1 get peto por la tuta muro. Kaj tiam se vi provas trovi ekvilibron ĉar - tio estas ankaŭ tuj dependos en via kandidatiĝo. Ĉar se vi esperas, ke homoj nur havas 10 aŭ 20 muro afiŝojn ke estos bone. Sed se vi atendis ili devos miloj tiam tiu peto prenus tro longa, kaj tiel vi eble volas aldoni get-tuta-afiŝojn-ekde parametro. 

Por ĉiu el tiuj vi probable tuj volas sinkronigi viajn datumojn en JSON - Javascript Objekto Skribmaniero. Sufiĉe da ĉiu lingvo traktas JSON tre bone. JQuery havas ĉi belan getJSON funkcio kiu faros ĉion de la laboremo por vi. Kaj en PHP-tie estas ankaŭ tre belaj JSON komunikado funkcioj. Do, tio estas probable la plej bona formato por sendi viajn modelojn tien kaj reen. 

Kiel ekzemplon de tio, kion ni parolis ĝis nun, jen ekzemplo fluo por via kato Facebook apliko. Ĝi startas for kun via retumilo petante la bazo retejo URL. La servilo eble sendus super statika HTML kaj iuj JavaScript kaj CSS. Ĝi estas kutime pli bone ne fari ajnan bildigo sur la servilo. Vi probable ne volas - kion la servilo ne faras tie iras malsupren en la listo de muro afiŝojn kaj generante iuj HTML por ĉiu kaj sendante ke super. Ĝi estas kutime bona por fari tion en la kliento flanko ĉar alie ĉiufoje kiam vi volas re-cxerpi ion, vi devas fari servilo peton. Kaj tio tre rapide donas al vi multan superkape. Ĝi estas kutime bona nur por ŝipon sendas malsupren statika HTML kaj tiam JavaScript kaj CSS kiuj faros la desegnadon en la kliento flanko. Apenaŭ Okaze venos, tiam vi povas havi - en JavaScript - vi povas fari petojn por la murego datumoj kaj da tio, kaj post ke la servilo estas esence nur faras datumbazo pridemandojn kaj kontrolinte permesojn. La sola grava afero estas, ke gxi ne povas sendi pli ol kelkaj aliaj uzantoj muro afiŝojn ke vi ne permesis vidi. Ĝi povas esence esti tre maldika tavolo aliro al via datumbazo, kaj tiam ĉiuj el la montrante la datumoj - ĉiuj el la vidpunktoj kaj aĵoj - tiuj povas okazi en via retumilo, kaj tiam, kiam vi volas fari fosto aŭ io vi simple sendu alian peton. 

Ekzistas ankaux iom da fantazio stuff vi povas fari sur supro de ĉi. En terminoj de pli specifaj teknikaj informoj, evoluantaj en ebenaĵo JavaScript povas esti iomete dolora, tial estas kelkaj bibliotekoj kaj iloj, kiuj helpos al vi multon kun tio. Mi kredas ke vi jam ĉiuj probable aŭdis pri jQuery kion faras faras HTML desegnadon kaj manipulado multe pli facile - ili havas multajn fantazio funkcioj por malapero kaj eliros, kaj farante Zippy kuraĝigoj. Ekzistas ankaŭ tiun bibliotekon nomitan Underscore.js. Ĝi havas multe da utilaj utileco funkcioj, stuff, ke vi devus atendi JavaScript por havi ke tio vere doesn't - aĵoj kiel barajar tabelo, forigo duobligitaj el listo, aŭ ebenigo listo de listoj. Ĉi tio estas nur malgranda kodo specimeno. Substreko havas ton de tiuj agrablaj funkciojn kiuj vi deziras, ke vi havus la tutan tempon. 

Kaj tiam tie estas ankoraŭ 1 biblioteko kiu mi ŝatus pasigi iomete da tempo sur vokis Backbone.js ĉar Backbone vere helpas vin trakti kun modeloj en la kliento flanko kaj multajn el la konfuzo ke ĝi povas kaŭzi. Backbone donas al vi tiun koncepton de modeloj kaj kolektoj en JavaScript kiuj estas esence tute same kiel JavaScript objektoj en JavaScript arrays sed ili havas eventojn kiam vi ŝanĝos iliajn ecojn. Same kiel en JavaScript, vi povas havi okazaĵon kiam butono gets klakis aŭ io tiuj Backbone modeloj kaj Backbone kolektojn elsendos aĵojn kiel ke kiam ili ŝanĝiĝos. Tio signifas ke vi povas nur skribi ion kiel tiu cxi de kodo tie - tio diras, kiam vi aldonas ion al la afiŝojn tabelo vi redesegni la tuta muro. Kaj tion dirus kiam post la numero de homo ŝanĝas, vi informas la uzanton ke iu ŝatis sian postenon. Aŭ kiam ajn iu propraĵo de fosto ŝanĝas vi redesegni la fosto. Stuff kiel kiu savos vin tunojn da komplekseco ĉar alie se vi ne havas iun kadron kiel ĉi tiam ĉiufoje en via kodo, ke vi ŝanĝu ion pri fosto, vi devus memori mem nomi cxiujn redonu funkcioj kaj da tio, kaj se vi volis aldoni ion novan, ke okazis ĉiufoje kiam vi modifita post vi devus iri tra cxiu loko en via kodo kiun vi modifita fosto kaj aldonu ke ion novan. Ablono ŝatas ĉi forigos multon de tiu inter-tavolo komunikado kiu faras via kodo kompleksa kaj malfacile subteni. 

Estas iomete pri opinioj same. Mi tuj forlasi plejparto de ĉi Billy ĉar ili estas teknike ne tre malfacila. Uzu jQuery pro viaj opinioj. Ĝi estas preskaŭ kiel neceso je ĉi tiu punkto. Ĝi simple faras ĉiun tiom pli facile. Ekzistas multe da bibliotekoj. Se vi estus komplika uzanto-interfacon elementoj, se vi volas automobil-pleneco aĵo aŭ egala al iu el tiuj fantazio mult-selectores - se vi volas ion kiel tion, vi devus probable simple serĉu ĉirkaŭe kaj vi povas trovi bonan bibliotekon kiu faros kion vi volas. Billy klarigos pli pri la reale malfacilaj partoj de opinioj. Ankaŭ, kiel flanka noto, Backbone havas iujn funcionalidad por fari vidpunktoj komuniki bele kun modeloj - rigardas la dokumentadon por ĉiuj el tiuj bibliotekoj, fakte. Nur rigardu la dokumentojn. Ili estas tre bone skribita kaj facila por sekvi. Ĝenerale, oni povas sufiĉe tre simple Google, se vi havos problemojn. Ekzistas multe da homoj uzas ilin. Mi pensas ĉi tiu estas kiel fina noto. 

Ekzistas ankaux iom pli progresinta, kiu vi povas fari se vi serĉas por fari vian ttt app ekstra timinda. Vi povas fari - la nova HTML5 specifo havas multan imago tion vi povas fari. Loka stokado - kiu estas vi povas stoki datumoj en la foliumilo - prefere ol devi reiri kaj peruse la servilo pro ĉio, vi povas konservi iom da ĝi sur la kliento kaj ke eĉ permesas homojn - en kelkaj kazoj tio povas eĉ lasos vin uzi la retpaĝon senkonekta. Tie estas tiu afero nomata websockets kiu estas malsama speco de reto komunikado kie anstataŭ ĝuste vin fari unu peto, vi ricevas respondon kaj vi faris, vi gardos malfermi konektiĝi al la servilo kaj tiel vi povas fari tion kiel reala tempo ĝisdatigoj. Do, se vi provis fari babilejon app, vi povus uzi websockets komuniki tien kaj reen por ke vi ne devus konservi petante, "Ho, servilo, cxu iu sendis al mi babilejo?" ĉiu 10 sekundoj aux io. Estas ankaŭ interesa HTML5 trajto, kie vi povas fari gxin rigardi kiel la adreso de la paĝo ŝanĝas sen iam devi reale reŝargi ĝin. Vi povas uzi reen kaj plusendu butonoj sen fari faskon de reto petojn. Stuff kiel tio estas vere utila en terminoj de farante ĝi speedy sed ankaŭ funkcias kiel ttt app devus. 

Ekzistas ankaŭ jenon nomata CoffeeScript. CoffeeScript estas malsama lingvo, efektive, kiu kompilas malsupren al JavaScript. Vi skribus vian tutan kodon en CoffeeScript, kaj tiam vi kuros ĉi-tradukilo, kaj ĝi sputas el JavaScript-dosiero, kiun vi povas inkludi en vian retpaĝon. La kialo ke CoffeeScript estas bela estas ĉar ĝi liveras de multa el la weird kazoj tiu JavaScript havas kie egalas egaluloj, kaj egalas egaluloj fari malsamajn aĵojn, aŭ ŝatus - ĝi havas pli agrablan sintakson por kontraktanta kun arrays kaj funkcioj. Tiu estas iom fragmento de CoffeeScript kiu produktas liston de ĉiuj kvadratoj el 10 ^ 2 al 1 ^ 2 en inversa ordo. Kiel vi povas vidi, CoffeeScript ofte ebligas esprimi en 1 linio kio prenus 5 linioj de JavaScript. Ĝi povas fari aferojn multe pli facila. Estas iom da nova sintakso por lerni unue, sed certe faros vin pli produktivaj en la longa. 

Vi povas ankaŭ uzi aliajn lingvojn en la servilo ol PHP - lingvoj kiel Ruby, Python, aŭ tie estas eĉ projekton nomitan node.js ke lasos vin uzi Ĝavaskripton en la servilo. Persone, mi vere, vere malamas PHP. Mi simple ne ĝuas laboris kun ĝi. Se vi ankaŭ opinias, ke ĝi estas terura cluge de lingvo, tiam vi povas uzi unu el tiuj anstataŭe. Ĝenerale, se vi volas fari ion, kaj vi ne vere scias kiel vi farus tion, nur pristudi la interreto. Esas tunoj kaj tunoj da rimedoj speciale je - StackOverflow estas granda. Ĝi estas paĝaro, kie programistoj petas reciproke demandoj. Vi povus kuri en ĝin, se vi havas problemojn je CS50 problemo aroj. Kaj ekzistas tunoj da bibliotekoj por fari preskaŭ ĉion, kion vi volus. Se vi volas fari ion, kaj vi ne scias kiel fari ĝin, se vi ne supozas ke ĝi estas neebla. Nur rigardu ĉirkaŭe kaj vi eble trovos kelkajn bonajn rimedojn. 

Kiel ĝenerala wrap supren, la ĉefa takeaways estas konservi aferojn simplajn. Ju pli kompleksa via kodo estas je la komenco kaj ju pli vi provu kaj faru fantazio stuff, la jam ne prenos por akiri ion vere funkcian kaj la pli malfacila estos ŝanĝi poste. Do, faru tion, la mutaj, facila vojo antauxe. Iri kune kun tio, ne havi timon de forjxetis malnova kodo aŭ purigi ĝin multe. Ĝenerale, kiam oni fakte havas ion laborista, ĝi estas multe pli facile pensi, ol kiam vi estas ankoraŭ en la komenco etapoj de Kiel do mi metis ĉi ĉiuj kune. Ĝi estas bona por fari la dumbest eblaj dezajno kiu funkcias kaj tiam plibonigi ĝin ripete ol provi akiri ĉion dekstre la unua fojo. En terminoj de kliento-servilo dividon, provu kaj gardu vian servanton tre simpla - nur datumbazon kaj kelkaj aŭtentokontrolo, kaj ne faru iujn malfacila laboro tie. Ĉu ĉiuj viaj altnivelaj informoj pri la kliento flanko en la foliumilo en JavaScript tiom kiom vi povas. Rigardu ĉirkaŭe por bibliotekoj kiuj faras vian vivon pli bona. Ĉiam pli bone uzi kodon, kiun iu alia skribis se vi - kaj ne skribi ĝin vi mem. Tie estas multe da taskoj sur la Interreto. Google estas via plej bona amiko. Google estas la programisto la plej bona amiko. Jes, definitive ne timu rigardi ĉirkaŭe por aĵoj. Ĉiuj pravas. Kaj super Billy. 

[Billy] Fakte, antaŭ mi komencu per kelkaj dezajno stuff, ĉu iu havas demandojn por Ben pri io ajn, kion li parolis? Konsentite, bona. Denove, lasu nin scii se io ne estas klara aux se vi ŝatus ni transiru io iom pli. Mi iras al retropaŝi iom kaj paroli pri la pli fundamentaj partoj de dezajno. Ben menciis la modelo nomata - bedaŭras, la modelo regilo view sistemo kio estas speco de la teknika aspekto, do mi iras rigardi vidpunktoj specife, kaj mi tuj komencu per kiom vi deziras desegni vidpunkto ke aspektas bela. Jen speco de vere baza ŝablono por nia kato Facebook. Mi pensas ke estas iuj fundamentoj en moderna UI dezajno kiuj valoras repreni. Vi povas rimarki ke estas multe da blanka spaco ĉie en la paĝo, multo de spaco por aĵoj. Ne sentas kiel vi havas premplatigi aĵojn enen paĝo. Vi volas lasi multajn ĉambro malfermita, kaj se vi iros al preskaŭ ajna moderna retejo vi vidos ke estas blanka ĉie. Tie estas blankaj en lokoj vi ne atendas. Vi havas ĉi paletro, kaj ĝi estas saĝa al la komenco elekti paletro, ke vi iras labori kun kaj disvolvi. Vi ankaŭ - ĝi helpas por elekti tipografía, kaj aliflanken vi speco de laboro kun tiuj konkretaj fundamentojn de dezajno. Vi havas viajn tipo, vi havas viajn kolorojn, kaj tiam vi povos ia adapti ĉion alian en tiom bezonataj. Do, kiel mi diris, kun via kolorskemon vi volas uzi la revenante pli aŭdacaj koloroj de via kolorskemon ŝpareme. Headers estas bela. Butonoj estas agrable havi vere grandaj, okulfrapaj koloroj. Sed ĝenerale, se vi havas retejon, kiu havas kolorojn ĉie ĉiuj gapante al vi en la vizaĝon, li nur aspektas cluttered, kaj gxi estas ne bona. Vi volas ĝenerale uzas lumon koloroj. Provu denove, pluki belan kohera kolorskemon. Vi povas havi tiujn iom salpicaduras de partoj de la koloro - kiu povas aspekti bela agrabla, sed oni volas uzi ilin belaj ŝpareme. 

Kiel mi diris, ke vi volas esti minimuma. Malpli estas preskaŭ ĉiam pli. Se vi povas montri iun aŭ ne montras ion, kaj vi estas speco de necertaj ĉu ĝi devus esti tie defaŭlte - probable vi estas bona ekstere lasante ĝin. Vi ĉiam povas aldoni ĝin en postaj. Jes, gardu tion, simpla. Sed plej grave, ke vi volas konsideri plurajn dezajnoj. Ne pensu, ke kiam vi faros lokon, vi havas gxin en via kapo ke vi iras al ke la paĝaro en certa vojo, kaj gxi tuj aspektas ekzakte kiel ĉi tio. Ĝi tuj havi la bluajn kaplinio ĉe la supro kaj la blua flanko trinkejo kaj tiam la flava sub-header afero. Vi volas fari plurajn ŝablonojn. Vi povas ĉu - se vi estas bona kun Foto Butiko, vi povas malfermi, ke supre kaj ia desegni retejo kiel vi ŝatas ĝin rigardi. Se ne, vi povas simple uzi plumon kaj paperon, sed scratch up multnombraj dezajnoj. Vi volas esence havas starigis kie vi havas multajn malsamajn dezajnoj, kaj se oni finas labori, tiam tio estas granda. Se oni finas maltrafante, tiam vi ĉiam havas alian turni al. En ĝenerala, ne sentas kiel vi devus esti devigata al kiom dezajno vi komence decidi. Dezajnoj estas tre varia, kaj parto de la graveco de la modelo regilo view sistemo estas ke vi povas interŝanĝi en kaj ekster malsamajn vidpunktojn vi deziras. Vi povas svingiĝi datumoj unu vojo, kaj tiam decidi, ho, vere, tio ne funkcias bone. Mi pensas, ke estas speco de tro komplika aŭ ekzistas parton tie ĉi kio ne vere funkcias, do mi simple tuj tute forlasi tiun vidpunkton kaj interŝanĝan en tute nova. Ni povas ankoraŭ uzi la malnovajn modelojn kaj la maljuna regiloj. Ni povas fari ĉion sur la servilo kaj kliento kiel ni farus antaŭe. Sed la efektiva ondo de la datumoj, kiel montrita tuj estos iomete malsamaj. 

Koncerne reale realiganta la dezajno vi volas, iam vi havas malmultajn dezajnoj skizis sur papero aŭ sur Foto Butiko aŭ kio ajn, ekzistas pluraj iloj kiuj disponigis al vi. La unua vi estas tre familiara kun kio estas via HTML, PHP, aŭ kion ajn lingvo vi uzas nur kodigi la statika paĝojn en via retejo. Vi laboris multe kun HTML, kiun specon de donas al vi tiujn etikedoj ke vi povas meti tion en, kaj esence estas maniero de organizi vian enhavon. Ekzemple, vi havos la kaplinion tie supre, do vi tuj havos kaplinio etikedo, kaj gxi tuj devos tekston interne de ĝi, kiu estas probable tuj estos en alia etikedo. Tiam vi havas sidebar eble kun kelkaj malsamaj ĉeneroj, kaj tiuj, kiuj iras al ĉiuj esti en apartaj etikedojn. Do, esence HTML cxe lia koro estas maniero de dividanta la paĝon kiel vi eventuale volas formati ĝin. Do denove, vi jam vidis tiun antaŭe. Vi estas belaj komfortaj kun labori kun ĝi nun komisiite, ke vi jam faris la lastan pset espereble, tiel, ke devus esti neniu problemo. 

Tiam vi havos CSS kiu esence pritraktas ĉiujn el la dezajno statika aspektoj. Estus manipuli ĉiuj koloroj, ĉiuj la investon de diversaj elementoj, kie ili iros kun respekto al unu la alian, kiom grandaj ili estas, la malsamaj specoj de posicionamientos ke vi havus - en aliaj vortoj, oni povas esti aferoj fiksita por ke kiam vi rulumu malsupren ili restu! aux vi povas havi tion relativa al aliaj elementoj. Ĉiuj tiaj aĵoj estas en CSS. Plue, vi povas fari malsamaj dekoracioj, vi povas havi tekston koloroj, teksto efektojn, ĉiuj de tiu speco de ŝtofo. Ben donis vere bona seminario pri ĉi lasta semajnfino, kaj tiel Mi certe kontroli, ke ĉu vi planas esti farante iun fantazio aferojn kun CSS. CSS3 estas fakte la plej nova versio de la CSS, kaj oni povas fari cxiajn vere bela aferojn. Ĝi povas fari gradientes; vi povas havi bela, rondoformaj anguloj; vi povas fari ĉiajn aĵojn fari retpagxon aspektas pli moderna kaj fantazio. 

La sekva ilo estas JavaScript kaj jQuery kiu Ben parolis iomete pri, sed mi prenos iom pli internen. Javascript, kiel vi jam laboris per ĝi iomete, aŭ almenaŭ vidis ĝin en prelego, estas ia formo de dinamike fari aĵoj en HTML. HTML, kiel vi scias, estas statika, do iam vi havos la HTML vi ne povas redakti ĝin. Sed JavaScript, en kelkaj manieroj, estas maniero por povi modifi la HTML. Do vi povas fari tion, kaj tio estas granda, sed JavaScript vere estas doloro por labori kun. Ĝi estas tiel longa kaj obtuzaj kaj fari ecx la plej simplaj aferoj postulas amason da linioj de JavaScript. Do, jQuery estas esence biblioteko por JavaScript kiuj simpligas la tuta de tiu. Ĝi diras, bone, se vi volas havi kvadrata skatolo venas de maldekstre kaj fadas en la pagxo por ke ĝi estas en la mezo, en JavaScript kiu prenus - Mi ne scias, cent linioj fari, kaj ke estus doloro, kaj vi alvenis el ĝi malamante cxion pri ttt programado. JQuery vi esence havas la elemento-dot-fade-en, aux iel simile. Do, tre, tre simplaj funkcioj kiuj lasos vin fari ĉiajn cool kuraĝigoj kaj tian aferon. La alia afero ke tiuj 2 estas vere bona por ĝi simple fari dinamikajn aferojn per la retpaĝaro. Do, prefere ol nur havi vian HTML-paĝo - kiu vidigas iujn datumojn sed ne reale fari ion - JavaScript kaj jQuery lasos vin havas butonojn kiuj vi povas alklaki, kaj vi povas treni elementoj kaj re-ordon ili kaj ordigi ilin, kaj havi novajn elementojn aldonita aŭ forigita. Vi povas aldoni-delete, ke tiaj aferoj. Do, jQuery faras tunoj de cool aferojn. Kaj Vipul estas reale donanta seminario pri gxi hodiaux, mi kredas, en la 5-unua horo, do se vi povas meti ĉirkaŭ pro tiu longa, kiuj volas - 5 aŭ 4? Kvar. Pardonon. Ĝi estas vere tuj post tio, do mi rekomendus bati ĉirkaŭ ĝin, se vi povas. JQuery is super, super utila, kaj vi povos fari multajn vere bela aferojn kun ĝi cxar preskaux neniu ttt evoluo projekto. 

Nun mi iros al enir ia distingo. Mi jam parolis esence pri uzantinterfaco. Uzanto interfaco estas nur la dezajno de la retejo. Sed estas ia alia koncepto kiu estas uzanto sperto. La du estas tre malsama. Interfaco estas definitive parto de la sperto. En aliaj vortoj, kiam vi iros al loko, vi rigardas la interfaco. Tio estas parto de kiel vi spertas la retejo. Sed uzanto sperto estas pli ol tio. Uzanto sperto estas pri tio, kion la impreson, ke la uzanto ricevas el via loko estas. Do, evidente, interfacon estas parto de tiu. Kaj ĝi estas definitive necesa parto, sed ĝi ne estas sufiĉa. En aliaj vortoj, se vi havas belan interfacon, kaj ĝi estas bela kaj bunta kaj ĉiuj el tiu, tio estas granda, sed se la uzanto iras al via retejo, ekvidas belan aranĝon kaj ĝin konfuzita per ĉio, havas nenian ideon kiel fari ion, do evidente vi jam faris vere malriĉa retejo. Tio estas speco de kie uzanto sperto venas in Mi iras por paroli iomete pri UX dezajno - UX estas mallonga por uzanto sperto - kaj tipon de kiel vi povas certigi ke vi havas bonan sperton de uzanto. La unua punkto estas ke vi povas desegni retejo kie uzanto povas fari ion, ke uzanto eble volu. Sed se la uzanto ne povas diveni kiel fari tion - en aliaj vortoj, se la uzanto ne havas bonan ideon, kiam ili iras al via retejo de, "Ho, se mi volas aktualigi mian profilon, tiam mi klaki tiun butonon, aŭ se mi volas sendi al ies muro, tiam mi iros al sia muro kaj klaku sur malgranda skatolo. " Se la uzanto ne scias, ke tiam vi efektive havas ne reale implementado ke funcionalidad korekte. Parto de efektivigo funcionalidad estas ke la uzantoj estas vere povi uzi ĝin. Kaj gxi estu frustra - vi povus fari retejon, kaj ĝi povas fari ĉiajn mirindaĵojn, sed tiam vi devos homoj testi ĝin kaj diras, "Tio ne povas fari ĉi tion. Kial ne povas gxin fari tion? "Kaj vi diros reen al ili, "Nu, ĝi povas. Vi nur devas iri en la 7a falmenuo en tiu obskura paĝo ke nur oni trovas por la ligilo malsupre-dekstre-mana angulo "aŭ io. Evidente, vi ne volas tion. Vi volas ke ĝi estu klara al viaj uzantoj, kion ili supozis fari, kaj ĝi estu simpla kaj intuitiva por ili. 

Alia afero, kiun vi volas provi fari estas, se iu tuj iros al via ejo kaj 9 el 10 fojojn fari agon A, kaj 1 el 10 fojojn fari agon B, vi verŝajne volas enfokusigi sian sperton pri agado A. En aliaj vortoj, vi volas fari ĝin tre, tre klara kiel fari A. A estu antaux-kaj-centro - iru al la loko, vidu; oh, tio estas prava. Dum B evidente vi volas esti klara, sed vi povas lasi gxin iom pli en la fono. David donas bonan ekzemplon de tio en prelego, kiu estas la Boston T sistemo. Kiam vi iras al la Boston T kaj vi volas acxeti bileton, vi devos eniri en la 5 menuoj antaŭ ol vi povos efektive aĉeti bileton por $ 2, $ 2.50 valoro, kiu estas kiel multe ĝi prenas por rajdi la metroo en unu direkto. Tio estas problemo, ĉar la plej multaj homoj, kiuj sidas la metroo probable nur volas iri al unu loko, ili aĉetas ilian bileton, get sur tuj. Ĝi ne havas sencon, ke ili devos iri tra multaj malsamaj menuojn alveni. Al bona uzanto sperto estus rapida butonon sur la unua paĝo ke nur diras, 'aĉeti unudirektan bileton', kaj tio metus en ĉiu de la normo defaŭlta valorojn, kaj tiam, se iu volas aĉeti alian bileton ol tio, Ili ankoraŭ, kompreneble, ili havas la eblon, sed vi jam optimumigita por la komuna uzo kazo kiu estas vere grava. Vi povas vidi ekzemplojn de tiu en Facebook, right? Se vi iras por Facebook kaj vi volas sendi statuso, ĝi estas ĝuste ĉe la supro, kiu estas kion vi ofte volas fari. Tuj kiam vi eniras la paĝon, vi povas fari la plej komunaj aferoj vi volas fari. Se vi volas fari iomete pli komplika aferoj kiel, diru mi volas iri al mia amiko la muro kaj sendi foton pri ĝi - kiun mi volas fari ofte, sed ne tiel ofte kiel posting statuso ĝisdatigoj - tial en tiu kazo, mi tajpas ilia nomo en la skatolo en la supro, klaku sur siaj profilon, kaj tiam, ankoraŭ, ĝi estas rajto je la supro tie iam mi alvenis al sia profilo. Denove, mi jam optimumigita en prioritato por la plej komuna uzo de la kazoj. 

Alia grava afero estas, ke ofte homoj ian provos preni ĉirkaŭ ĉi dirante, bone, do mi faris la retejon kaj personoj estas trovi ĝin malklara, kaj tio estas problemo, ĉu ne? Evidente, mi ne volas popolon esti konfuzitaj de la enhavo de mia retejo. Sed la maniero solvi tiun ne estas havi ion pop up dirante: bona, mi iros instrui al vi kiel uzi la retejon. Paŝo 1 - klaku ĉi-butonon. Paŝo 2 - iru tien. Certe, tio estas vojo ĉirkaŭ ĝi - ĝi estas formo kiun vi povas diri al homoj tion, kion fari, sed estas vere ne la optimuma vojo. Se mi iras al retejo, kaj subite mi bombardita kun ĉi lernilo ke'S telling me kion fari kaj kien iri, kaj ĉiuj el tiu, tio ne estas amuza por mi. Ĝi ne estas bona sperto por mi. Ĝi estas speco de doloro. Mi volas nur komenci fari aferojn. Homoj tuj fermos el iliaj dialogujo, aŭ eliri la lernilo, ne scias kion fari, kaj tiam plendas pro Vi ne sciigis al ili, kion fari. La vojo al solvi ĉi tiu estas ne donante al ajna speco de lernilo aŭ direktoj - io kiel tio. Kiom ajn vi povas eviti gxin, vi vere volas montri al la uzanto kion fari nur per la naturo de kiel la retejo estas elspezata. En aliaj vortoj, se mi iras al Facebook sen ensalutante, la unua afero, kiun mi vidas sur la ĉefa paĝo - ĝi estas iom ensaluto skatolo. Do, duh. Mi devas ensaluti Ĝi pravas tie. Dum, se mi iris al Facebook kaj mi devis klaku iom ligilon ĉe la malsupro kiu diris 'saluti' kaj la resto de la paĝo estis nur ia bildo aŭ io, Mi ne vere scias kion fari, ĉu ne? Mi devus esti konfuzita. Do, gxi povus diri al mi iri tien kaj alklaku la butonon por ensaluti, aŭ la loglibro en butono eblis dekstren ĉe la supro, kie mi estas vidonta lin. Vi volas ĉiam esti indiko al la uzanto, kion fari, kaj tio devus esti imanenta en la paĝo mem. 

Kiam vi pensas pri dezajnoj kaj moka malsamajn manierojn de esprimi vian lokon, vi vere deziras pensi pri tio, kion la uzantoj estas tuj esti faranta kaj kiel vi povas montri al ili, kion fari. Unu lasta afero estas provoj estas vere, vere grava. Ĝi estas granda por akiri iun - get amiko, get iu vi ne scias eĉ - kiu neniam vidis la lokon antaŭ uzi la retejon. Ĉar vi jam estis laborante en la retejo dum horoj, vi estis gapante lin, kaj vi scias ekzakte kion fari do evidente vi tuj povas provi la aferoj kiujn vi jam estis laborante en kaj por ke vi sciu laboro. Sed se iu alia venas kune kaj uzas la retejon kiu neniam uzis ĝin antaŭe, tio estas unika sperto ĉar vi havas iun kiu havas neniun antaŭan konon de la loko iras en ĝin, do ili tuj devos efektive nenian ideon kion fari aux kian uzon kazoj estas donacon por ili. Tio estas granda. Tio estas unika, ĉar ili estas esence persono kun vakua por menso. Ili povas diri al vi, se io estas konfuza aŭ malklara. Ili povas doni al vi ideon pri precize kio la uzanto sperto de via retejo estas. Ĝi povas esti tre malfacile diri, ke vi mem, do certe mi kuraĝigas vin kiel vi evoluantaj viaj projektoj -, se vi faras ttt-bazitaj projektoj - akiri homoj uzanta la lokon kiel frua kiel vi havas ia funkcia demo. 

Nun mi iros por paroli iomete pri kiel mastrumi ttt evoluo projekto. Ni iris super vi kiel fari la teknikan back-end flanko kiel vi povas desegni vere bona retejo, kaj tio estas tre bone, se vi laboras per vi mem, sed - eĉ se vi laboras per vi mem kaj speciale se vi laboras en teamo, projektmastrumado iĝas granda demando. Vi havas ian aŭdis pri projektmastrumado en malsamajn formojn ekde elementa lernejo, kiam vi rakontis grupo laboro. Vi devas kunlabori, komuniki, ĉio de tio. Ke ĉiuj ankoraŭ validas ĉi tie, sed ekzistas kelkaj solaj cirkonstancoj kun komputiko, ke vi volas esti konscia de, kaj vi volas certigi vin manipuli bone. Mi parolos unue iom pri la teamo, ke vi estos in Ĝi estas tre gravaj por kapti la dekstra grandeco de teamo por labori plu, kaj en via fina projekto mi pensas ke vi havas la eblon elekti inter 1 kaj 4 homoj, se mi estas korekta. Vi volas certigi ke vi estas ne nur elekti la nombron de homoj ke vi deziras labori per ĉar ili estas viaj amikoj. Vi volas elekti teamo, tio estas bona grandeco kaj kiu ricevos la laboron farita. Tie estas komerco off en havante pli da homoj kontre malpli homoj. Se vi havas pli da homoj, evidente pli da laboro povas esti farita ĉar vi havas multajn homojn, multajn kodo, multajn ideojn, kaj jen ĉio granda. Sed ĝi ankaŭ postulas multe pli da uzado kaj multe pli komunikadon. En aliaj vortoj, se vi havas 4 homojn laborante en la sama projekto kaj ili ĉiuj estas redaktado de la sama kodo, pli aŭ malpli ĉiuj speco de bezono scii kio okazas tiel postulas vi - se vi aldonas iom da novaj funkcioj vi ian havas por diri al la homo - I'm adicianta ĉi, Mi ŝanĝi ĉi tion en tiu maniero - speciale se vi enir la vere profunda stuff kiel la modeloj kaj la regiloj kiuj efektive tuj influos kiamaniere la retejo funkcias. La tuta teamo bezonu konscii pri tio, do vi devas certigi ke vi ne elekti tro granda teamo kiu tuj estos malfacila fari, ke komunikado. Vi ankaŭ ne volas elekti sufiĉe malgranda teamo, ke vi ne tuj povos komuniki ĉar ĝi estas nur vi. 

Alia afero konsideri estas la pesilo de kie popola kapabloj estas. Estas bonege, se vi ĉiuj vere bonaj programistoj. Sed se vi estas tuta dorso-fino popolo, tiam via retejo ne tuj aspektas tre bona ĉar vi havas tiun grandan datumbazon, kaj ĝi faras la super-rapida serĉo pridemandojn - kio estas grandaj - sed kiam vi iras al ĝi, ĝi estas kiel 1990-ejo kun ruĝaj kaj bluaj ĉie, kaj tio ne estas bona ĉu. Rimarku, ke Ben kaj mi laboras kiel teamo estas tre bela ĉar mi estas ia pli en la antaŭa fino, ni ambaŭ interagas en la mezo-finon, kaj Ben vere bona kun dorso-fino stuff, por ke funkciu vere bone ĉar ni povas desegni ajnan lokon kaj esence la truoj en tiu ejo kiuj bezonas esti plenigita povas plenigi per ĉu unu el ni, aux eble ambaux. Vi volas certigi, ke ne estas truoj en via teamo. Ĝi estas bone, se estas iom de koincido. En aliaj vortoj, se vi havas 2 personoj, kiuj estas ambaŭ bonaj kun dorso fino, ke povas esti bona tiel, ĉar ili povas helpi unu la alian kun problemoj ke ili havas. Ĝi povas esti problemo, se vi nur havas 1 persono, kiu estas respondeca pri certa afero kaj ili kolizias problemo, do vi ne volas havi iom de koincido sed vi plej grave volas certigi, ke ĉiuj el la eblaj truoj estas satigebla. 

La lasta afero - kaj tio devus esti evidenta, sed ĝi estas ofte ne. Vi vere volas esti amuze. La punkto de tiu fina projekto en CS50 kaj ofte la punkto de ttt evoluo ĝenerale estas ne nur faru laboron ĉar ĝi bezonas fari. Vi vere volas esti amuziĝas, kaj vi volas esti farante ion tio estas la motivi vi labori sur ĝi. Se kion ajn vi faras estas doloro sidigxi kaj laboros plu, tiam vi ne estas elekti la rajton projekto. Vi volas elekti iun kiu vi trovas interesa, vere vi volas vidi la rezulton, vi estas ekscitita, kiam vi acxetas novan ideon pri io, kion vi povus fari - do tie estas ĉiaj projektoj tie ke mi estas certa vi povas trovi - ĉiuj havas iun kiu havus vere intrigi ilin se ili faras ttt-bazita projekto. Mi tion diri ĝin denove nun. Se via projekto ŝajnas kiel doloro kaj vi ne volas labori pri tio, elekti alian projekton. Elektu iun kiu vere inspiras vin. 

Ben menciis tiun koncepton de ripeta iom, kaj mi volas iri super gxi iom. Ĝi estas vere gravaj por labori bobelkrevoj kie vi akiri ion funkcia. Ĝi povas esti tre bone, se vi havas tiun planon paĝaro, kiu tuj fari A, B, kaj C, kaj finfine ĝi alvenos tie. Sed vi estas enfiksita en ĉi tiu fazo kie vi laboras en gxi kaj laborante sur ĝi, sed nenio iĝas farita. Vi ne havas ion por vidi kaj palpebla, funkcia afero. Kion vi vere volas fari tiel, kiel tio ŝajnas ia doloro foje al labori sur io kaj tiam ia ĉapo ĝin tiel ke ĝi estas almenaŭ ĉe stabila, kurante Versio eĉ se ĝi ne havas ĉiujn trajtojn vi deziras. Kaj eble estas kelkaj trajtoj kiujn vi vere volas aldoni, sed vi nur ne povas ĉar vi volas ricevi tiun retejon al funkciaj punkto. Kaj tial vi volas specon de havi la tutan disvolviĝ-procezon aspektas tiel. Vi volas komenci ie funkcia - aŭ esenco komencu per nenio - sed vi volas ricevi ie tre baza kaj funkcia. Kaj cetere, faras ian salto kaj ricevi ie funkcia denove. Vi devos malrapide edifi kaj ĝi povus iri iom pli malrapida ol ĝi farus alie, sed en la longa, se vi senĉese estas enfiksita en ĉi mezo teron fazo, kie vi ne vere havas nenion laboras, povas esti vere granda frustriĝo labori pri via projekto, ĉar vi estas ĉiam tiel proksimaj al ricevas ĝin laborante, kaj gxi neniam vere funkciis. Vi volas labori en tiuj funkciaj bobelkrevoj, kaj vi ankaux volas fari iu reflekto post cxiu. En aliaj vortoj, kiam vi estas en punkto kie la paĝaro estas nun laboras - ĝi ne havas ĉion kion vi ŝatas sed ĝi faras iuj aĵoj - vi volas pensi, estas bone, estas ĉi lokon plenumi la celon, ke mi ekiris por fari? En aliaj vortoj, se la loko estas tuj fari X, estas kion mi laboras en la direkto de X? Ĉu ĉiuj el la funcionalidades ke mi volis tie? Kaj cetere, estas tio servas la entuta celo, kiun mi volas? Se vi trovante ke via retejo komencas Veer en malsama direkto aŭ eble aĵojn nur speco de ne laboras ekstere, povas esti la tempo por ŝanĝi dentaĵoj iomete. En aliaj vortoj, indas konsideri - ĝi valoras eljxetante ideojn, se necese kaj konsiderante mi vere laboras al kio mi deziras esti. 

Mi kredas, ke estas mia sekva punkto. Ne timu forlasi ideojn. Nur ĉar vi pasigis multajn horojn laboras pri esprimilo kaj fine akiris ĝin laborante sed vere ne iras tiel bone - kiel ĝi ne estas tiom utila aŭ uzantoj havas problemojn uzante ĝin - tiaj aferoj - ne timu ĵeti ĝin for. Mamo ke vi jam elspezis multan tempon laborante en ĝi, sed finfine vi ne volas loko kiu estas speco de kunmetita per tiuj pecoj, ke speco de laboro, sed ne estas tiu puto utilis. Ankaŭ, ne timu brakumi novajn ideojn. Se iu venas kune kaj diras, bona, ke retejo aspektas vere malvarmeta sed ne volis ŝin ankoraŭ tre bone, se ĝi ankaŭ faris tion? Nur ĉar tio estas io kion vi ne intencis, kaj iu kiu ne estas en via specs, io, kion vi ne ekiris fari, ne timu preni ĝin kaj tiam labori kun ŝi. Ĉar ofte la ideoj kiujn vi kuras kun la tuta paso de evoluo finu estante la vere malvarmeta trajtojn de la retejo. 

Mi jam diris tion antaŭe. Mi tion diri ĝin denove. Testers estas super, super utila. Provu instigi personojn kiuj neniam vidis la retejo antaŭ ol ensaluti en kaj vidu kio okazas ĉar ili povas ne nur testi la utilecon de la ejo kaj la uzanto sperto, sed ili povas ankaŭ testi la funcionalidad en manieroj kiuj vi ne povas. Se vi faras iuj karakterizaĵo kiu faras iun aĵon kaj vi scias tion tuj fari tion saman aferon korekte ĉiun solan fojon, ke estas granda. Sed ĝi povas ofte esti malfacile klarigebla angulo kazoj kie uzanto forteco tajpi ion ke vi ne atendis - ĝuste ĉar vi difinis La trajtoj mem. Do, havi iun eniri en kiu ne havas ideon kiel uzi la ejo kaj al la ĵus rompi ĝin en ajn manieroj oni povas fari estas vere utila, ĉar vi ideon de plene malsamaj perspektivoj de kio en via retejo laboras kaj kion bezonas riparon. 

Lasta, mi iras por paroli pri iu ĝenerala bono praktikoj, kaj vi vidis multon de tiuj en CS50, sed ili ankaŭ vere, vere apliki en projekto opcio. Unu estas komentoj. Ĉiam komenti vian kodon speciale se vi laboras en granda teamo. Ĝi povas esti tiel ĝenaj al nur devas giganta bloko de kodo ke iu estas skribita kaj eble gxi funkcias, eble ne, sed vi havas nenian ideon, kion ĝi faras, do vi tute ne scias ĉu ĝi estas utila aŭ ne, aŭ ĉu ĝi devus esti tie aŭ ne, kaj se vi laboras en alia aĵo ĝi estas eĉ ebla ke vi laboras en La sama afero, do nur tre, tre zorga esti atenti la bezonojn de viaj kolegoj kaj registran kodon kiu estas bone dokumentita. Vi ne devas iri tiel for kiel fari la tuta afero kie ŝatus, se vi pliigo nombrilo havas komenton kiu diras, mi aldonas 1 al ĉi vendotablo. Ĝi ne devas esti, ke detala, sed pro ajna funkcio kiu vi iam skribis vi devus havi iom da dokumentado de kio tiu funkcio akurate faras, kion lia enigoj estas, kaj kion ĝi devas reveni. Tiel vi povas uzi fremdajn komponantoj de la retejo kaj vi povas labori por konstrui ion grandan. 

Alia grava afero estas ke vi volas fari regulajn purigoj. Kodo gets senorda. Ne sentas malbone se via kodo estas nur tute nelegebla kaj giganta salaton. Tio okazas en ttt evoluo ĉiam. Vi aldonas novajn funkciojn, demetante malnovaj. Stuff tuj estos tie, ke ne devus esti. Tio estas bone, sed vi volas certigi pritrakti kiu regule. Vi ne volas lasi konstrui ĝis la punkto kie vi simple ne povas trovi ion en via kodo, kaj vi ne havas ideon kion ion faras. Tio estas la kazo kun HTML. Kelkfoje vi finos kun objektoj kiuj ne enhavas ion, kaj vi volas forigi el tiuj. En CSS, vi povas raporti al elementoj kiuj ne estas tie plu, tiel vi volas liveri de tiu kodo. En JavaScript, vi povus esti forigitaj ion de la HTML. Do, vi volas certigi ke vi estas ĉiam purigi, farante aferojn bela tiom kiom vi povas sur regula bazo. 

Alia vere utila afero, kiun mi ne pensas ke estas konturita tre multe en CS50 sed ĝi valoras por eniri estas versio kontrolon. La ideo de versio kontrolo estas kiam vi esence konservanta trako de la tuta progreso vi faris al via retejo kaj se, je iu ajn punkto vi rimarkos, aj, ĉi tio estis laborante faras momenton sed ĝi ne funkcias plu, vi povas iri reen al antaŭaj versioj kaj vidi, kio ŝanĝiĝis de tiam kaj tiaj aferoj. La ĉefa maniero por fari tion estas kun Git kaj Git estas ĉi tuta speco de sistemo kiu Mi kredas, Tommy MacWilliam donis seminarion pri la pasinta jaro. Se vi iras en la CS50 seminarioj por 2011, vi povas vidi lian seminarion pri tio. La ideo de Git estas esence, ke je regulaj intervaloj vi farante tiujn devontigojn kio estas vojoj dirante la retejo estas en bela stalo versio nun tiom Mi ujoj gxi supren kaj sendante ĝin al servilo, kaj tiam vi povas iri al tiu servilo kaj rigardi ĉiujn antaŭajn versiojn de via kodo kaj vidi kiel ĝi estas progresinta kaj ĉiujn kiuj speco de bona aĵo. Do, tio estas esence ĝin. Koncerne ttt evoluo, ni estas feliĉaj pusxi ĉirkaŭe kaj respondos ajnan demandojn, kiel malproksime kiel nia prezento. Estas tio. Dankon. >> [Ben] Dankon. [Aplaŭdo] 

[Billy] Personaro, ĉu iu havas demandojn pri aferoj, kiujn ni kovris aŭ aĵoj, kiujn ni ne kovris, ke ili estis kun la espero ni volus kovri? Ni ŝatus respondi al tiuj. Iu? [Spektantaro membro] Kiuj estas la avantaĝoj kaj malavantaĝoj de uzante Ruby aŭ uzante Pitono? [Ben] La demando estas, kio estas la avantaĝoj kaj malavantaĝoj de uzante Ruby aŭ Python anstataŭ kiel PHP. La avantaĝoj estas, ke Ruby kaj Python estas multe pli bona lingvoj ol PHP. Almenaŭ en mia opinio, kaj mi pensas en amaso de aliaj homoj opiniojn tiel. Ili estis desegnitaj pli por fari kompleksajn aferojn, kaj malpli por whacking kune retpaĝojn vere rapide kun iomete da dinamika enhavo. La malavantaĝoj estas ke estas iomete da - estas pli de lernado kurbo por akiri ilin starigis. Tio estas, kiel en PHP, vi povas simple havi la HTML-dosieron kaj vi skribos malpli-ol, demandosigno, kaj tiam vi skribos iom da kodo, kaj tiam vi skribos demandosigno, granda-ol, kaj tiam vi finos. En aliaj lingvoj kiel Ruby aŭ Python, Vi devas iri tra iom pli da laboro por alveni la komenca ejo kurado. Tie estas ankaŭ - almenaŭ ĝi kutimis esti la kazo - ke ekzistas pli dokumentado disponebla por PHP nur ĉar tie estas pli da homoj uzas ĝin. Mi pensas ke ne estas tiom granda demando plu. Tie estas certe tre bona dokumentado por aĵoj kiel Ruby on Rails aŭ Django por Pitono estas la ekvivalento. PHP estas kiu ĉies estis uzante dum jaroj, kaj vi scias kiel ĝi funkcias. Ruby kaj Python estas iomete malpli matura. 

[Spektantaro membro] Se vi estus elekti inter unu el ili por lerni aŭ repreni, kiun vi preferas? Honeste, mi opinias, ke dependas de la persono. Mi bedaŭras. La demando estis kiu vi elektu iun por lerni? Mi trovos Pitono la plej bela persone. Ekzistas multe da homoj, kiuj - mi faris mian unuan ttt dev projekto en Python kaj Django. Ekzistas multe da homoj kiuj ŝatas Ruby on Rails ankaŭ. Probable pli da homoj kiuj scias Ruby on Rails. Honeste, mi simple iru kun kiom la homoj ĉirkaŭ vi scias tiel, ke vi havas homojn por demandi demandojn. 

La demando estis - on dividis serviloj estas speco de forte labori sur Pitono? Tio dependas de via gastigo. Estas nombro de ttt gastigantoj kiuj afiŝos Pitono vazaro. WebFaction faras tion, ĉu ne? WebFaction estas tiu kiu Billy kaj mi uzis por iuj projektoj. Ili estas vere granda. Ili apogas plej lingvoj. Sed estas vera ke PHP estas multe pli vaste subtenata. Do, se vi estas hokita sur ttt militistaron, kiu nur faras PHP, tio estas bona kialo por uzi PHP. 

[Spektantaro membro] Mi ĵus eniris lerni kiel demandi iun datumbazojn, kaj Mi konas miajn SQL estas ĉie en la loko, sed mi ĵus atingis elmontrita al - kaj vi indikis ĝin. Komprenu JSON kaj ampliable datumbazoj. Mia SQL estas ankoraŭ ĉie en la loko. Kiel vi vidas, ke okazas? Estas tie tuj estos kreskanta tendenco por pli ampliable (inaudibles)? La demando estis - ja mi pensas, ke okazas al esti emo al ne-SQL-datumbazoj. Ekzemple, kiel MongoDB. Mi pensas ke estas sendube vera. Mia konsilo estis plejparte mySQL-rilataj tie nur ĉar mySQL estas industrio normo. Persone, mi multe preferas datumbazoj kiuj ne havas schemos kiel MongoDB kie vi ne havas la temon de, ho, mi bezonas aldoni alian kolumnon. Ve al mi, kiel ajn mi faru? Estas tre malfacile fari tion sur mySQL, sed kiam vi havos ion kiel Mongo ĝi estas multe pli agrabla. La alia bela afero pri Mongo estas ke viaj raportoj estas vere JavaScript celoj. Tie estas neniu speco de konvertiĝo ŝtupo kie vi bezonas preni tiujn datumbazo vicoj kaj turni ilin enen JavaScript objekto kaj poste sendos ilin super la drato. Mi kredas necesajxojn kiel tiu tuj estos tre, tre utila por rapida ttt disvolviĝo en la estonteco. 

[Billy] Io mi aldonus kiu estas nur ĝenerala punkto estas ke ne sentas kiel vi devus esti lerninta ĉiuj lingvoj ni diskutis de nia seminario. Evidente la punkto estas por doni al vi ideon pri kio estas tie ekstere, kaj se vi estas interesita pri iu ajn el la aferojn ni jam menciis vi povas Guglas ilin kaj legis sur ili. Kaj kiel mi menciis, ekzistas kelkaj seminarioj kiuj traktas kun precize tion. Tie estas eĉ pli seminarioj, kiujn mi ne menciis, ke probable enir tiun materialon kiel bone. La ideo estas ke, se vi volas labori pri io, jen la iloj estas je via dispono. Ne sentas malgxojas, se vi ne estas vere certas kion tiuj iloj fari precize, sed sciu, ke ili estas tie ekstere kaj ke vi povas fari vastan uzon de ili de Google. 

[Spektantaro membro] Kiajn aferojn vi bezonas fari por certigi vian retejon aspektas bone en porteblaj aparatoj? [Billy] Mobile aparatoj estas iom malmola. Estas 2 manieroj vi povas alproksimigi ĝin. La unua maniero estas, ke vi efektive havas mobile retejo. En aliaj vortoj, vi plenumi iun specon de detekto komence kiam la retumilo estas farante la peton al via retejo, kiun ĉu diras revenu ĉi vidpunkto - kiu estos la vidon por labortabla aŭ tekkomputilo foliumiloj - kaj tiu alia vidpunkto por porteblaj aparatoj. Tio estas loko kie opinioj estas vere bela en kiuj vi povas sufiĉe tre swap la du ekstere kaj havas interfacon kiu funkcias vere bele en porteblaj aparatoj kaj havas tute malsamajn kiu funkcias bele sur retumilo aparatoj. La problemo kun tio estas prenas longan tempon, ĉar ĝi signifas kodigon plene malsama interfaco. La alia vojo, ke vi povas fari tion estas - multaj modernaj poŝtelefonoj montros retejoj kaj provu redonu ilin kiel retumilo volis, kaj ili faros sian plejeblon. Vi povas ia provos resti lumo de la kvanto de jQuery JavaScript vi uzas kio emas esti kie aĵoj povas iri malbone iom. Tio estas speco de la vojo, kiun vi devus uzi se vi ne havas tiom da tempo. Se vi ja havas la tempon por labori sur mobile interfacon, estas evidente via plej bona opcio. 

Mi kredas ĝenerale por CS50 projektoj, vi tuj volas elekti unu aŭ la alia. En aliaj vortoj, vi volas fari mobile app aŭ vi volas fari labortabla retejo. Kaj tiu speco de determinas kie vi iri kun tio. Sed se vi volas pligrandigi ĝin poste, probable vian plej bonan vetas estas por fari alian interfaco por la aliaj. Mi havas iom da sperto en evoluantaj WordPress-bazitaj ejoj. Mi gastigis personan retejon pri WordPress dum kelka tempo. Tiuj specoj de kadroj povas esti bela same tre bazajn aferojn. Ofte vi simple kolizii multajn customizability temoj kvankam. Vi volas havi ion rigardi iu maniero aŭ esti certa maniero kaj vi nur povas ne ĉar ĝi estas malfacila-telegramis al la sistemo, ke jen kiel vi devas fari tion, kion povas esti iom de problemo. Ekde tiam mi specon de estintaj pli emas labori kun lokoj de la tero supren. Por aĵoj kiel blog datumbazojn kaj ke tia afero estas vere ne estas tiel malfacila por konstrui kadro. Se vi vere tirita por momento, vi povas kompreneble uzi iun kiel WordPress aux ke tia afero por blogo. La specoj de aferoj kiujn blogoj vendejo kaj fari ne estas vere malfacila sufiĉas ke se vi uzas en iu el tiuj specoj de aferoj, vi estas probable pli ĝuste fari en-domo versio. 

Mi pensas ke temas pri tio, do dankon denove pro veni. Ni vere ĝuis paroli al vi uloj kaj esperas, ke vi lernis kelkajn aferojn. [Ben] Ni estas kontentaj paroli - ni devas iri, sed ni estas kontentaj paroli pli ekstere se vi havas alian demandon. Danke denove. [Aplaŭdo] [CS50.TV]