[Powered by Google Translate] [Seminaar] [Web Development: Van idee tot uitvoering]
[Ben Kuhn] [Billy Janitsch] [Harvard Universiteit]
[Hierdie is CS50] [CS50.TV]
[Billy] Hi, ek is Billy en dit is Ben. >> [Ben] Hi.
Ons gaan vandag om te praat oor web ontwikkeling.
[WebDev] [Billy Janitsch en Ben Kuhn]
'N bietjie oor ons eerste.
Ben is 'n soort van die back-end man. Hy maak dinge werk.
En dan gaan ek in en maak hulle mooi.
Ek is grootliks betrokke by meer front-end uitleg ontwerp soort dinge,
en Ben, aan die ander kant, weet wat hy doen so hy werk op back-end dinge.
Saam het ons n paar dinge wat gemaak is.
Byvoorbeeld, verlede jaar het ons gewerk het op Gimblium wat is 'n aanlyn spel ontwikkeling studio.
Dit was ons laaste projek vir die klas,
en sedertdien het ons gemaak het Harvard Klas
wat is 'n aanlyn-raamwerk vir blaai en shopping kursusse by Harvard.
>> Ons gaan om te begin met hierdie idee vir ons webwerf.
Ons gaan Facebook te maak nie, maar vir die katte.
Voordat jy eintlik maak van hierdie webwerf,
maak nie hierdie webwerf, want dit is nie goed nie, maar ons sal dit gebruik as 'n raamwerk
en gaan deur die proses van hoe ons hierdie idee
en draai dit in 'n ware webwerf wat ons kan gebruik.
Ons begin deur die breek van die webwerf af.
Soos jy gedoen het in CS50,
jy wil om te dink oor wat die werklike komponente wat gaan in hierdie webwerf.
Basies draai dit uit 'n idee wat net soort van 'n abstrakte konsep
in 'n werklike, tasbare ding wat jy kan maak.
Ons begin deur te vra 'n paar vrae.
Wat is hierdie webwerf? Hoekom maak ons ​​dit?
Wat gaan dit gebruik word? Daardie soort van ding.
In die geval van Facebook Cat,
Ons het basies wil 'n webwerf wat kan katte sosiale netwerk met mekaar.
Die idee is dat hulle kan plaas op mekaar se mure,
hulle kommentaar, wat soort van ding kan maak.
En dit is waar ons na die funksionele komponente kom.
Ons het nou hierdie soort van raamwerk van - ons het die gebruiker profiele,
Ons het kommentaar, en ons kan plaas.
Miskien eendag sal ons influent hou en dat die soort van ding.
En ons soort wil hierdie eienskappe gaan in te prioritiseer
Ons wil graag sê, okay, dit is regtig belangrik dat almal het 'n profiel
en dat almal kan plaas op mekaar se mure.
Sekondêre dat, sou kommentaar lekker wees.
Miskien later sal ons influent hou.
So, jy wil 'n idee van wat fundamenteel tot jou projek te hê
en wat is soort van 'n meer algemene verskynsel wat later toegepas kan word.
Jy wil soort van 'n spesifieke lys in gedagte,
Maar die projek wat jy begin is nie van plan om die projek wat jy voltooi te wees met.
Met ander woorde, dinge gaan verander terwyl jy die webwerf ontwikkeling,
en jy wil die kamer te verlaat vir wat.
Ek sal draai dit om te Ben wie gaan 'n bietjie om te praat oor struktuur.
>> [Ben] Ek gaan om te praat oor die meer tegniese kant van web ontwikkeling.
Kom ons gaan net meer as 'n paar basiese beginsels eerste.
Wanneer jy doen 'n web artikels,
die hoof afdeling wat jy gaan te hê is
jy gaan 'n paar dinge aan die gang in die kliënt se kant te hê -
dit is die kode wat jy die leser neem van die werf
en die JavaScript, HTML, CSS dinge.
Dit is al wat op die kliënt kant.
Jy gaan ander kode wat loop op die bediener kant te hê
wat hou van al die data wat mense stuur vir julle,
besluit wat om te gee wat, dinge soos dat.
Dit is net 'n paar terme sodat jy ouens is almal vertroud is met wat ons praat.
Beyond daardie afdeling dit is goed om te dink van jou web artikels in terme van
'n paar van die verskillende komponente.
Wanneer jy die web-ontwikkeling te doen
een van die dinge wat jy altyd moet probeer om te doen, is om kompleksiteit te verminder.
Die meer komplekse jou kode is die kans daar is foute te maak,
hoe moeiliker is dit om later verander.
So, as jy kan breek jou artikels in 'n paar verskillende funksionele areas
Dit sal - en jy kan die soort van bedrag van kruis-area kommunikasie verminder -
wat sal help om 'n lot in die lang termyn in terme van die vermindering van foute.
>> Om beton wees, gewoonlik mense verdeel 'n web artikels in -
dit is soort van buzz woorde nou nie, maar hulle is nog steeds nuttig.
Jy kan gehoor het mense praat oor modelle, sienings, en leiers.
Modelle is die werklike data dat jou artikels gaan om te hanteer.
Byvoorbeeld, in jou kat Facebook, sal jou modelle wees -
jy het 'n model vir soos poste, en 'n model vir die gebruiker profiele, dinge soos dat.
Jou mening is hoe jy bied dat data vir jou gebruikers.
Jy kan hê 1 oog vir die soek by 'n enkele post en al die kommentaar
en 'n ander siening vir jou muur wat 'n lys van al die poste
wat gerig is op jou, en 'n ander siening vir jou nuus voer - dinge soos dat.
Ten slotte, jy het die leiers wat basies wanneer mense aan jou stuur nie poste
en jy maak updates jou back-end-stelsel,
jy inkrementeer 'n klomp van aandele, en wat ook al.
Dit is jou leiers.
>> Ek gaan word meestal praat oor modelle.
Uitsig is tegnies nie so moeilik en die kwessie is meer met die ontwerp van hulle
Controllers gaan spesifiek vir alles wat jy ontwerp wees.
Maar daar is 'n paar mooi algemene tegnieke wat jy kan gebruik
jou modelle mooier en makliker om te werk met wat ek dink is baie nuttig te maak.
Dit is meestal gaan wees oor hoe om te gaan met jou web programme data in 'n mooi manier.
Die belangrikste kwessies met modelle
is dat hulle op die kliënt en die bediener en jy het om uit te vind
a) hoe om dit te kry - al die betrokke kinders - van die bediener aan die kliënt,
en b) hoe om dit in pas te hou.
Jou gebruikers gaan wil 'n paar updates te maak.
Hulle gaan om te wil nuwe poste te maak.
Hulle gaan om te wil dinge en dinge te hou as jy hou.
Dít is die belangrikste tegniese uitdagings van die hantering van modelle.
Die eerste ding wat jy gaan om te wil om jouself te vra is
watter soort data gaan in hierdie model en watter soort navrae gaan ons wil doen -
dit wil sê, hoe gaan ons om te kyk na die modelle?
Vir jou kat Facebook byvoorbeeld
jou post gaan 'n skrywer wat verband hou met dit te hê,
sommige muur post teks, en 'n ontvanger van die muur post.
En dan kan jy wil om dit te bevraagteken in 'n klomp verskillende maniere.
Jy sal wil hê om te kyk na dit deur wie watter post geskryf het,
deur wie ontvang wat post, miskien deur die datum wat hulle gepos is.
Maar as jy gaan om dit te doen deur die datum, dan het jy 'n ander veld toe te voeg tot jou post
wanneer dit was eintlik gepos.
Hierdie 2 faktore - wat data wat jy wil gebruik en hoe jy dit wil sien -
jy moet dink oor hulle eerste omdat hulle afhanklik is van mekaar,
en dit gaan moeiliker wees om hulle by te voeg later.
>> Daar is 'n paar ander oorwegings.
Wanneer jy dink oor hoe jy te doen met modelle op die bediener
wat jy wil om te kyk na is -
jy basies wil die bediener so eenvoudig as moontlik te maak.
Doen dinge op die kliënt kant is oor die algemeen baie vinniger as jy dit kan doen bloot op die kliënt
sonder om enige soort van netwerk versoek.
Die idee is om soveel as moontlik van die vrae as wat jy kan op die kliënt te doen.
Die enigste probleem met dit
is dat as jy vra al jou data aan die begin
dan is dit gaan 'n lang tyd om te laai te neem.
So, die idee is om 'n gelukkige medium om te staak tussen genoeg data op die kliënt
dat jy die meeste van jou werk kan doen, maar daar nie net haal alles op een slag
sodat jy regtig stadig laai tye aan die begin.
Byvoorbeeld, vir jou kat data
sou jy waarskynlik wil 'n klomp van die onlangse muur poste te gaan haal.
Jy wil nie almal van hulle te gaan haal, want dit kon terug 'n paar jaar gaan.
Maar jy wil nie dit te gaan haal op 'n tyd
want dit sou 'n baie van die netwerk oorhoofse stel.
>> Dit is dikwels baie hard - wanneer jy 'n databasis bestuur -
dit is dikwels baie moeilik om te verander wat data wat jy in dit -
dit is, voeg 'n nuwe databasis kolom of iets -
so 'n goeie strategie is eintlik net 'n klomp van jou data te hou in 'n teks blob -
'n into blob - into synde JavaScript Object Notasie -
Die rede is dat dit nuttig is, want dan kan jy nuwe eienskappe voeg
om al hierdie into druppels sonder om jou databasis.
Die enigste nadeel van dit is dat as jy 'n klomp van die velde
dat jy later bygevoeg - soos verborge in daardie into blob -
dan is dit moeiliker om hulle te bevraagteken in die databasis.
Byvoorbeeld, as jy later - as jy jou post model wat ons vroeër bespreek
met net die skrywer, die ontvanger en die teks -
jy kan ook 'n into blob en dan as jy later wil 'n datum veld te voeg
jy sal nie jou databasis te verander.
Jy kan voeg net datums aan al die teks velde.
En dan sal jy in staat wees om te kyk na die mense op die kliënt se kant,
maar jy sal nie in staat wees om hulle te bevraagteken op die bediener kant
want dit is weggesteek binne hierdie teks.
>> Die ander kwessie wat jy wil om te dink oor
is hoe om jou kliënt en bediener gaan om te kommunikeer.
Jy wil dit gewoonlik te hou so eenvoudig as moontlik.
Jy kan net soos 'n get-my-hierdie data versoek
'n skep-'n-nuwe-voorwerp ding, en 'n werk-'n-ou-voorwerp versoek.
En dit sou wees al die verskillende URL's op 'n bediener wat jy -
dat die leser sal - jy kan gebruik AJAX versoeke vir al hierdie
en óf ontvang of post data.
Weereens, vir ons Kat Facebook byvoorbeeld
jy kan die URL het 'n individuele post te kry,
en jy wil 'n URL vir die skep van 'n nuwe muur post
en dalk 'n URL vir die oplaai van jou profiel foto, dinge soos dat.
Maar weereens, dit is 'n pre-haal die meeste van jou data, sodat jy nie hoef te hou
maak netwerk versoeke.
Om dié rede is, kan jy nie wil hê dat die individuele get versoek om 'n enkele post te hê,
en in plaas daarvan sou jy wil net 1 get versoek vir die hele muur.
En dan as jy probeer om 'n balans te vind, want -
hierdie gaan ook afhang van jou aansoek.
Want as jy verwag dat mense net 10 of 20 muur poste
wat sal goed wees.
Maar as jy verwag dat hulle sal duisende dan daardie versoek te lank sou neem,
en so kan jy dalk 'n kry-alles-poste-sedert parameter toe te voeg.
>> Vir al hierdie is jy waarskynlik gaan wil jou data te pas in into -
JavaScript Object notasie.
Pretty much elke taal oor into baie goed.
JQuery het hierdie mooi getJSON funksie wat al die harde werk vir jou doen.
En op PHP daar is ook 'n baie mooi into kommunikasie funksies.
So, dit is waarskynlik die beste formaat vir die stuur van jou modelle heen en weer.
>> As 'n voorbeeld van wat ons tot dusver gepraat het,
hier is 'n voorbeeld vloei vir jou kat Facebook aansoek.
Dit begin met die leser versoek om die base webwerf URL.
Die bediener sal waarskynlik stuur oor statiese HTML en 'n paar JavaScript en CSS.
Dit is gewoonlik die beste nie enige lewering op die bediener te doen.
Jy het waarskynlik wil nie -
wat die bediener is nie daar doen, is om af te gaan die lys van die muur poste
en genereer 'n HTML vir elke een en stuur wat oor.
Dit is gewoonlik die beste om dit te doen op die kliënt se kant, want anders
elke keer as jy weer wil iets teken, het jy 'n bediener versoek te maak.
En wat baie vinnig gee jou 'n baie van oorhoofse.
Dit is gewoonlik die beste om net te skip stuur af statiese HTML
en dan JavaScript en CSS wat die lewering doen op die kliënt kant.
Sodra daardie dinge kom in,
dan kan jy - in JavaScript - jy kan doen versoeke vir die muur data
en dinge soos wat, en na dat die bediener is basies net besig databasis navrae
en die nagaan van regte.
Die enigste belangrike ding is dat dit nie 'n paar ander gebruikers muur poste kan stuur oor
dat jy nie toegelaat word om te sien.
Dit kan basies 'n baie dun laag toegang tot jou databasis,
en dan is almal van die wat die data - al die menings en dinge -
diegene kan gebeur in jou leser, en dan wanneer jy 'n pos of iets te maak
jy net stuur 'n versoek.
>> Daar is ook 'n paar fancy dinge wat jy kan doen op die top van hierdie.
In terme van meer spesifieke tegniese inligting,
ontwikkeling in plain JavaScript kan wees om 'n bietjie pynlik,
so daar is 'n paar biblioteke en gereedskap wat sal help om 'n baie met dit.
Ek dink jy het al waarskynlik gehoor van jQuery wat maak doen HTML lewering
en manipulasie 'n baie makliker - het baie van die fancy funksies vir vervaag in en uit,
en doen opgewek animasies.
Daar is ook die biblioteek genoem Underscore.js.
Dit het 'n baie nuttige nut funksies, dinge wat jy sou verwag JavaScript te hê
dat dit werklik doesn't - dinge soos geskuifel 'n skikking,
die verwydering van duplikate van 'n lys, of plat te slaan 'n lys van lyste.
Dit is net 'n klein-kode monster.
Onderstreep het 'n ton van hierdie mooi funksies wat jy wil jy al die tyd het.
>> En dan is daar nog 1 biblioteek wat ek wil graag 'n bietjie van die tyd om te spandeer op
genoem Backbone.js omdat Backbone jy regtig help met modelle op die kliënt se kant
en 'n groot deel van die verwarring wat dit kan veroorsaak.
Ruggraat gee jy hierdie konsep van modelle en versamelings
in JavaScript wat basies presies soos JavaScript voorwerpe
in JavaScript skikkings, maar hulle het gebeure wanneer jy hul eienskappe te verander.
Net soos in JavaScript, kan jy 'n gebeurtenis het toe 'n knoppie gedruk kry of iets
hierdie ruggraat modelle en ruggraat versamelings sal dinge soos uitgesaai
dat wanneer hulle verander.
Dit beteken dat jy net kan skryf iets soos hierdie kode uit hier -
Dit sê, wanneer jy iets aan die poste skikking jy teken die hele muur voeg.
En dit sou sê wanneer 'n post se aantal hou verander,
jy die gebruiker dat iemand graag hul pos in kennis stel.
Of wanneer enige eiendom van 'n post verander jy teken die post.
Dinge soos wat, want anders jou red ton van die kompleksiteit
As jy nie 'n raamwerk soos hierdie het dan elke keer in jou kode wat jy verander
iets oor 'n pos, sal jy het om jouself te onthou al die lewer funksies te roep
en dinge soos wat, en as jy wou iets nuuts wat gebeur het by te voeg
elke keer as jy verander 'n post wat jy wil hê om te gaan deur middel van elke plek in jou
kode wat jy verander 'n post en voeg dat die nuwe ding.
'N raamwerk soos hierdie sal 'n baie van daardie tussen-laag kommunikasie verwyder
dit maak jou kode kompleks en moeilik om te handhaaf.
>> Daar is 'n bietjie oor sienings ook.
Ek gaan die meeste van dit te laat Billy, want hulle is tegnies nie baie moeilik.
Gebruik jQuery vir jou standpunte. Dit is prakties soos 'n noodsaaklikheid op hierdie punt.
Dit maak net alles soveel makliker.
Daar is 'n baie biblioteke.
As jy nog ingewikkeld user elemente,
As jy 'n motor-volledige ding wil of soos een van daardie fancy multi-keurders -
As jy iets soos dit wil, moet jy waarskynlik net soek om
en jy kan 'n goeie biblioteek wat sal doen wat jy wil vind.
Billy sal meer verduidelik oor die eintlik moeilik om dele van standpunte.
Ook, as 'n kant nota, ruggraat het 'n paar funksies vir die maak van menings te kommunikeer
mooi met modelle - kyk na die dokumentasie vir al hierdie biblioteke, eintlik.
Net kyk na die dokumente. Hulle is baie goed geskryf en maklik om te volg.
In die algemeen, kan jy pretty much net Google as jy probleme het.
Daar is 'n klomp mense met behulp van hulle.
Ek dink dit is as 'n finale noot.
>> Daar is ook 'n paar meer gevorderde dinge wat jy kan doen
As jy op soek is na jou web artikels ekstra ontsagwekkende te maak.
Wat jy kan doen - die nuwe HTML5 spesifikasie het 'n baie fancy dinge wat jy kan doen.
Plaaslike stoor - wat jy data in die leser kan stoor -
eerder as om terug te gaan en daar verskeie bediener vir alles,
jy kan hou sommige van hulle op die kliënt en wat kan selfs mense -
in sommige gevalle is dit selfs kan laat jy gebruik om die webblad op die regte pad.
Daar is hierdie ding genaamd websockets wat 'n ander soort van die netwerk kommunikasie
waar in plaas van net wat jy maak 'n versoek, kry jy reaksie en jy klaar is,
hou jy maak 'n verbinding met die bediener en sodat jy dinge soos kan doen
real-time updates.
So, as jy probeer om 'n chat program te maak, kan jy websockets gebruik
heen en weer te kommunikeer, sodat jy nie hoef te hou vra,
"O, bediener, het iemand my 'n chat?" elke 10 sekondes of iets.
Daar is ook 'n interessante HTML5 funksie waar jy kan maak dat dit lyk soos
die URL van die bladsy verander, sonder om te herlaai eintlik nie.
Jy kan terug gebruik en stuur knoppies sonder om 'n klomp van die netwerk versoeke.
Dinge soos dit is baie handig in terme van wat dit spoedige maar ook werk soos 'n web artikels moet nie.
>> Daar is ook hierdie ding genoem CoffeeScript.
CoffeeScript is 'n ander taal, eintlik, wat stel af te JavaScript.
Jy sal al jou kode skryf in CoffeeScript, en dan loop jy die samesteller,
en dit spoeg uit 'n JavaScript-lêer wat jy kan insluit in jou webblad.
Die rede is dat CoffeeScript is mooi omdat dit ontslae raak van 'n groot deel van die
vreemde gevalle wat JavaScript het waar is gelyk aan gelykes,
en gelyk gelykes doen verskillende dinge, of wil -
dit het mooier sintaksis vir die hantering van skikkings en funksies.
Dit is 'n bietjie uittreksel van CoffeeScript wat 'n lys van al die blokkies
vanaf 10 ^ 2-1 ^ 2 in omgekeerde volgorde.
Soos jy kan sien, CoffeeScript kan dikwels jy druk in 1 lyn
wat sou neem 5 lyne van JavaScript.
Dit kan maak dinge baie makliker.
Dit is 'n bietjie van 'n nuwe sintaks om te leer by die eerste,
maar dit is beslis sal maak dat jy meer produktief in die lang termyn.
>> Jy kan ook ander tale op die bediener gebruik as PHP -
tale soos Ruby, Python, of daar is selfs 'n projek genaamd node.js
wat jou sal laat jy gebruik JavaScript op die bediener.
Persoonlik, Ek het regtig, regtig haat PHP.
Ek het net nie geniet nie werk met dit.
As jy ook dink dat dit is 'n vreeslike cluge van 'n taal,
dan kan jy een van hierdie plaas.
In die algemeen, as jy wil om iets te doen en jy weet nie regtig hoe jy dit sou doen,
net soek op die internet.
Daar is tonne en tonne van hulpbronne, veral op -
StackOverflow is 'n groot een.
Dit is hierdie webwerf, waar programmeerders vra mekaar vrae.
Jy kan hardloop in dit as jy sukkel om op CS50 probleem stelle.
En daar is ton van die biblioteke om dit te doen pretty much enigiets wat jy wil.
As jy wil om iets te doen en jy weet nie hoe om dit te doen,
Moenie aanvaar dat dit onmoontlik is.
Kyk net rond en jy n paar goeie hulpbronne kan vind.
>> As 'n algemene draai,
die belangrikste wegneemetes is hou dinge eenvoudig.
Die meer komplekse jou kode is aan die begin
en die meer jy probeer en doen fancy dinge,
hoe langer sal dit neem om iets werklik funksioneel te kry
en hoe moeiliker sal dit wees om later verander.
So, doen dinge wat die stomme, maklike manier om die eerste.
Om saam te gaan met wat,
nie bang vir die weggooi van ou kode of die skoonmaak van dit 'n baie wees.
In die algemeen, wanneer jy eintlik iets werk,
dit is baie makliker om te dink oor as wanneer jy nog in die begin stadium
hoe sit ek dit alles saam.
Dit is die beste om die domste moontlike ontwerp wat werk te maak
en dan verbeter iteratief as om te probeer om alles die eerste keer reg te kry.
In terme van die kliënt-bediener-afdeling, probeer en hou jou bediener baie eenvoudig -
net 'n databasis en 'n paar verifikasie en moenie enige harde werk is daar nie.
Doen al jou ingewikkelde dinge op die kliënt se kant in die leser
in JavaScript soveel as wat jy kan.
Kyk rond vir biblioteke wat jou lewe beter te maak.
Altyd beter dat iemand anders geskryf kode te gebruik
As jy - en nie om dit self te skryf.
Daar is 'n baie dinge op die internet. Google is jou beste vriend.
Google is die programmeerder se beste vriend.
Ja, beslis nie bang om te kyk vir dinge wees nie.
Alle regte. En oor Billy.
>> [Billy] Eintlik, voordat ek begin met 'n paar ontwerp dinge,
Is daar iemand enige vrae vir Ben oor enigiets wat hy gepraat oor?
Goed, goed.
Weereens, laat ons weet as daar iets is nie duidelik
of as jy wil om ons te gaan oor iets wat 'n bietjie meer.
Ek gaan terug na stap 'n bietjie en praat oor die meer fundamentele dele van die ontwerp.
Ben het genoem dat die model genoem - jammer, die model kontroleerder oog stelsel
wat is 'n soort van die tegniese aspek, so ek gaan om te kyk na standpunte spesifiek,
en ek gaan om te begin met hoe jy wil ontwerp 'n siening dat mooi lyk.
Hier is soort van 'n basiese patroon vir ons kat Facebook.
Ek dink daar is 'n paar basiese beginsels in die moderne UI ontwerp
wat die moeite werd optel.
Jy kan sien daar is 'n baie wit spasie regoor die bladsy
genoeg ruimte vir die dinge.
Moenie voel jy het dinge om te muurbal in 'n bladsy.
Jy wil baie van die kamer oop te laat, en as jy gaan na byna enige moderne webwerf
sal jy sien daar is wit oral.
Daar is wit in plekke wat jy nie verwag nie.
Jy het hierdie kleur palet, en dit wys aan die begin
'n kleur palet wat jy gaan om te werk en te ontwikkel om van te kies.
Jy het ook nie - dit help 'n skrif te kies, en die manier wat jy is soort van die werk met
hierdie konkrete beginsels van ontwerp.
Jy moet jou soort, moet jy jou kleure, en dan kan jy soort
pas alles in as wat nodig is.
So, soos ek gesê het, met jou kleurskema wat jy wil die vetter kleure van jou kleur skema te gebruik
spaarsamig. Headers is mooi. Knoppies is mooi baie groot, flitsende kleure te hê.
Maar in die algemeen, as jy 'n webwerf wat 'oral kleure,
al staar jou in die gesig, dit lyk net deurmekaar, en dit is nie goed nie.
Jy wil oor die algemeen gebruik die lig kleure.
Probeer om weer af te haal 'n mooi samehangende kleurskema.
Jy kan hierdie klein spat van baie van die kleur -
wat kan kyk mooi mooi, maar jy wil hê hulle moet mooi spaarsamig te gebruik.
>> Soos ek gesê het, jy wil minimaal wees. Minder is byna altyd meer.
As jy iets kan wys of nie wys iets,
en jy is soort van onseker of dit by verstek daar moet wees -
waarskynlik jy die beste af laat dit uit. Jy kan dit altyd byvoeg in later.
Ja, hou dinge eenvoudig.
Maar die belangrikste, wil jy verskeie ontwerpe te oorweeg.
Moenie dink dat wanneer jy 'n webwerf, moet jy dit in jou kop wat jy gaan
maak die werf in 'n sekere manier, en dit gaan lyk presies soos hierdie.
Dit gaan die blou banier aan die bokant en die blou kant bar te hê
en dan die geel sub-kop ding.
Jy wil meer templates te maak.
Jy kan óf - as jy goed met Photo Shop, kan jy oop te maak en soort
ontwerp van 'n webwerf as jy dit wil hê om te kyk.
Indien nie, kan jy net gebruik om pen en papier,
maar krap tot verskeie ontwerpe.
Jy wil basies 'n opstel waarin jy het baie van die verskillende ontwerpe,
en as 'n mens eindig werk, dan is dit 'n groot.
As 'n mens eindig versuim, dan is jy altyd 'n ander een om te draai na.
In die algemeen, voel nie soos jy moet beperk word
aan enige ontwerp wat jy eers besluit op.
Ontwerpe is baie veranderlike, en 'n deel van die belangrikheid van die model
kontroleerder oog stelsel is dat jy in en uit kan wissel verskillende menings wat jy wil.
Jy kan swaai die data een manier, en dan besluit, ag, eintlik, wat nie so goed werk.
Ek dink dit is soort van te ingewikkeld of is daar 'n deel hier Dit is nie regtig werk nie,
so ek gaan net om heeltemal laat vaar hierdie siening en ruil in 'n totaal nuwe een.
Ons kan nog steeds die ou modelle en die ou leiers.
Ons kan alles doen op die bediener en die kliënt as ons sou voor.
Maar die werklike golf van die data soos vertoon gaan word effens anders.
>> Sover eintlik die implementering van die ontwerp wat jy wil,
Sodra jy het 'n paar ontwerpe geskets uit op papier of op 'n Foto-winkel of wat ook al,
daar is 'n aantal van gereedskap wat aan u beskikbaar gestel word.
Die eerste wat jy is baie vertroud is met wat jou HTML, PHP, of wat ook al
taal wat jy gebruik net die statiese bladsye op jou webwerf te kode.
Jy het 'n baie werk met HTML watter soort gee jou hierdie tags
dat jy kan sit dinge in, en basies dit is 'n manier van organisering van jou inhoud.
Byvoorbeeld, jy het die kop daar, so jy gaan 'n kop-etiket te hê,
en dit gaan 'n paar teks binnekant van dit wat waarskynlik gaan om te wees in 'n ander etiket te hê.
Dan het jy 'n sidebar dalk met 'n paar verskillende skakels,
en dié gaan almal in aparte tags.
So, basies HTML op sy hart is 'n manier om die verdeling van die bladsy hoe
jy uiteindelik wil klaarmaak.
So weer, het jy gesien dat voor.
Jy is redelik gemaklik met die werk met dit nou
gegee dat jy die laaste pset gedoen het hopelik,
sodat behoort geen probleem te wees.
>> Dan moet jy nog CSS wat basies hanteer al van die ontwerp statiese aspekte.
Dit sou hanteer al die kleure, almal van die plasing van die verskillende elemente,
waar hulle saam met respek vir mekaar,
hoe groot hulle is, die verskillende soorte Placement wat jy sal hê -
Met ander woorde, kan jy dinge so bevestig dat wanneer jy rol af hulle bly,
of jy kan dinge relatief tot ander elemente.
Al wat soort van dinge is in CSS.
Verder kan jy die verskillende versierings doen, kan jy die teks kleure,
teks effekte, al daardie soort dinge.
Ben het 'n baie goeie seminaar op hierdie naweek,
en ek sal beslis kyk wat uit as jy van plan is om te doen 'n paar fancy dinge met CSS.
CSS3 is eintlik die nuutste weergawe van CSS, en dit alle vorme van baie mooi dinge kan doen.
Dit kan verval nie, jy mooi, ronde hoeke kan hê; jy allerhande dinge kan doen
te maak jou webwerf lyk meer modern en fancy.
>> Die volgende instrument is JavaScript en jQuery wat Ben gepraat het 'n bietjie oor,
maar ek sal 'n bietjie verder te kry in.
JavaScript, as jy met dit gewerk het 'n bietjie, of ten minste dit gesien in lesing
is 'n soort van 'n manier om dinamiese doen dinge in HTML.
HTML, soos jy weet, is staties, so wanneer jy HTML kan jy dit nie wysig nie.
Maar JavaScript, in sommige maniere, is 'n manier om in staat wees om HTML te verander.
Sodat jy dit kan doen, en dit is groot, maar JavaScript is regtig 'n pyn om te werk met.
Dit is so lank en stomp en selfs die eenvoudigste dinge te doen
vereis baie lyne van JavaScript.
So, jQuery is basies 'n biblioteek vir die JavaScript dat vereenvoudig al van dat.
Dit sê, okay, as jy 'n vierkantige boks kom van links te hê
en vervaag in die bladsy sodat dit in die middel, in JavaScript wat jou sal neem -
Ek weet nie, 'n honderd lyne te doen, en dit sal 'n pyn wees,
en jy kom uit dit uit haat alles oor web ontwikkeling.
JQuery jy basies die element-dot-vervaag-in, of iets soos dit.
So, baie, baie eenvoudige funksies wat jou sal laat jy doen alle soorte van die koel animasie
en dat die soort van ding.
Die ander ding wat hierdie 2 is regtig goed vir is net doen dinamiese dinge
met die webwerf.
So, eerder as om net met jou HTML bladsy - wat vertoon sommige data, maar nie eintlik
niks doen nie - JavaScript en jQuery sal laat jy het knoppies wat jy kan kliek op,
en jy kan elemente en weer om hulle te sleep en sorteer hulle, en het 'n nuwe elemente
bygevoeg of verwyder. Jy kan voeg-delete, daardie soort van ding.
So, jQuery doen ton van die koel dinge.
En Vipul is eintlik gee 'n seminaar oor dit vandag, dink ek, teen 5-uur,
so as jy kan hou om vir so lank, sou dit - 5 of 4?
Vier. Jammer. Dit is eintlik net ná hierdie, so ek sou aanbeveel
om vas vir dit as jy kan.
JQuery is super, super nuttig, en jy sal in staat wees om baie van die baie mooi dinge om te doen met dit
vir pretty much enige web ontwikkeling projek.
>> Nou gaan ek om te kry in soort van 'n onderskeiding.
Ek het basies praat oor gebruikerskoppelvlak.
User is net die ontwerp van die site.
Maar daar is 'n soort van 'n ander konsep wat gebruikers ervaring.
Die twee is baie anders.
Interface is beslis deel van die ervaring.
Met ander woorde, wanneer jy na 'n webwerf, kan jy kyk na die koppelvlak.
Dit is deel van hoe jy die webwerf ervaar.
Maar gebruikers ervaring is meer as dit.
Gebruikers ervaring is oor wat die indruk skep dat die gebruiker kry van jou site is.
So, natuurlik, koppelvlak is 'n deel van daardie.
En dit is beslis 'n noodsaaklike deel, maar dit is nie voldoende nie.
Met ander woorde, as jy 'n mooi koppelvlak, en dit is redelik en kleurvolle en al van dat,
dit is groot, maar as die gebruiker gaan na jou site, sien 'n mooi uitleg en dit is verwar deur
alles, het geen idee hoe om iets te doen, dan natuurlik jy het 'n baie gemaak
swak webwerf.
Dit is soort van waar gebruikers ervaring kom in
Ek gaan 'n bietjie om te praat oor UX ontwerp - UX is kort vir gebruikers ervaring -
en soort van hoe jy seker dat jy 'n goeie gebruikers ervaring kan maak.
Die eerste punt is dat jy kan 'n webwerf ontwerp waar 'n gebruiker kan enigiets doen wat
dat die gebruiker moontlik wil hê.
Maar as die gebruiker kan nie uitvind hoe om daardie dinge te doen nie -
Met ander woorde, indien die gebruiker het nie 'n goeie idee wanneer hulle gaan na jou werf van,
"Ag, as ek wil my profiel te werk, dan is ek op hierdie knoppie, of as ek wil om te post op
iemand se muur, dan gaan Ek na hul muur en kliek op 'n klein boks. "
Indien die gebruiker nie weet dat, dan is jy effektief nie eintlik
wat funksies korrek geïmplementeer word.
Deel van die implementering van 'n funksie is dat die gebruikers is eintlik in staat om dit te gebruik.
En dit kan frustrerend wees - jy kan 'n webwerf te maak, en dit kan doen alle soorte
wonderlike dinge, maar dan sal jy mense toets dit en sê: "Dit kan nie doen nie.
Hoekom kan dit nie doen nie? "En jy sal terug sê vir hulle:
"Wel, dit kan. Jy moet net om te gaan in die 7 drop-down menu op hierdie onbekende
bladsy wat net is gevind deur 'n skakel aan die onderkant-regterkantste hoek "of iets.
Dit is duidelik dat jy nie wil hê dat.
Jy wil om dit te duidelik vir jou gebruikers wat hulle veronderstel is om te doen,
en dit moet eenvoudig en intuïtief vir hulle wees.
>> Nog 'n ding wat jy wil om te probeer om te doen, is, as iemand gaan om te gaan na jou site
en 9 uit 10 keer doen aksie A, en 1 uit 10 keer doen optrede B,
jy waarskynlik wil hul ervaring op aksie A. te fokus
Met ander woorde, jy wil dit baie, baie duidelik hoe A. te doen
'N moet voor-en-sentrum - gaan na die webwerf, dit sien; O, dit is reg daar.
Terwyl B natuurlik wat jy wil duidelik te wees, maar jy kan dit 'n bietjie meer los
in die agtergrond.
David gee 'n goeie voorbeeld van hierdie in lesing
wat is die Boston T stelsel.
Wanneer jy na die Boston T en jy wil 'n kaartjie te koop,
jy het om te kry in 5 spyskaarte voordat jy kan koop 'n kaartjie
vir 'n $ 2, $ 2,50 waarde, wat is hoeveel dit neem om die metro te ry
in een rigting.
Dit is 'n probleem omdat die meeste mense wat ry die metro
waarskynlik wil net om te gaan na een plek, koop hulle kaartjies, kry op die regte weg.
Dit maak nie sin dat hulle het om te gaan deur baie verskillende spyskaarte
om daar te kom.
'N beter gebruikers ervaring sal 'n vinnige knoppie op die eerste bladsy wees
wat net sê, "koop 'n een-way ticket," en dit sou sit in al die standaard
standaard waardes, en dan as iemand wil 'n ander kaartjie as om te koop,
hulle nog steeds, natuurlik, het die opsie om nie, maar vir optimale het
die algemene gebruik geval wat werklik belangrik is.
Jy kan sien voorbeelde van hierdie op Facebook, reg?
As jy gaan na Facebook en jy wil 'n status te plaas,
dit is reg aan die bokant en dit is wat jy dikwels wil doen.
Sodra jy die bladsy, kan jy die mees algemene dinge doen
jy wil doen.
As jy wil 'n bietjie meer ingewikkeld dinge soos om te doen,
sê ek wil gaan na my vriend se muur en post 'n foto op dit -
wat ek sal wil dikwels doen, maar nie so dikwels as plaas status updates -
so in daardie geval, tik ek hul naam in die boks aan die bokant, kliek op hul profiel,
En dan, nog steeds, dit is reg by die top is daar een keer het ek gekry om hul profiel.
Weereens, ek in prioriteit geskik vir die mees algemene gebruik gevalle.
>> Nog 'n belangrike ding is dat mense dikwels sal soort van probeer om te kry om hierdie
deur te sê, okay, so ek gemaak het van die site en mense vind dit verwarrend,
en dit is 'n probleem, reg?
Natuurlik, ek wil nie hê mense moet verwar word deur die inhoud van my site.
Maar die manier om dit te los, is om nie te hê om iets pop-up en gesê:
hey, ek gaan jou te leer hoe om hierdie webwerf te gebruik.
Stap 1 - klik op die knoppie. Stap 2 - gaan hier.
Seker nie, dit is 'n manier om dit - dit is 'n manier wat jy mense kan sê wat om te doen nie, maar dit is
regtig nie die optimale manier.
As ek na 'n webwerf en skielik ek gebombardeer met hierdie handleiding wat se my vertel
wat om te doen en waar om te gaan en al van dat, dit is nie pret vir my.
Dit is nie 'n goeie ervaring vir my.
Dit is soort van 'n pyn. Ek wil net begin doen dinge.
Mense gaan om af te sluit van hul dialoog,
of uit die handleiding, weet nie wat om te doen, en dan kla omdat
het jy nie vir hulle gesê wat om te doen.
Die manier om dit te los, is nie deur enige soort handleiding of rigtings -
iets soos dit.
Soveel as wat jy dit kan vermy, het jy regtig wil die gebruiker te wys wat om te doen
net deur die aard van hoe die webwerf is uitgelê.
Met ander woorde, as ek gaan na Facebook sonder aanteken,
Die eerste ding wat ek sien op die hoofblad -
dit is 'n bietjie login boks. So, duh. Ek het om aan te meld Dit is reg daar.
Terwyl, as ek na Facebook en ek het 'n bietjie skakel aan die onderkant te kliek
wat gesê het 'Teken In' en die res van die bladsy is net 'n soort van die foto of iets,
Ek wil nie regtig weet wat om te doen nie, reg? Ek sou verwar word.
So, kan dit vir my sê om daar te gaan en kliek op die knoppie om aan te meld,
of die log in knoppie kan by die top waar ek gaan om dit te sien reg wees.
Jy wil altyd vertoon word die gebruiker wat om te doen,
en dat inherent in die artikel self moet wees.
>> Wanneer jy dink oor die ontwerpe en gespot het verskillende maniere van
uitdrukking van jou webwerf, jy regtig wil om te dink oor wat die gebruikers gaan
te doen en hoe jy kan hulle wys wat om te doen.
Een laaste ding is die toets is baie, baie belangrik.
Dit is 'n groot iemand te kry - 'n vriend, kry iemand wat jy nie eens weet -
wat nog nooit gesien het die webwerf voordat die webwerf te gebruik.
Omdat jy het al die werk op die site vir ure, het jy al staar na dit,
en jy weet presies wat om te doen nie natuurlik jy gaan word die toets van die
dinge wat jy het gewerk en dat jy die werk ken.
Maar as iemand anders kom saam en maak gebruik van die terrein wat nog nooit gebruik word om dit voor,
dit is 'n unieke ervaring, want jy het iemand wat geen vorige kennis het
van die perseel gaan in dit, so hulle gaan effektief geen idee wat om te doen
of watter soort gebruik gevalle teenwoordig is vir hulle.
Dit is 'n groot. Dit is uniek, want hulle is in wese 'n persoon met 'n leë vir 'n gedagte.
Hulle kan jou vertel as daar iets is verwarrend of onduidelik.
Hulle kan gee jou 'n idee van presies wat die gebruikers ervaring van jou webwerf is.
Dit kan baie moeilik wees om te sê dat jouself, so seker ek wil u aanmoedig
as jy die ontwikkeling van jou projekte - as jy doen web-gebaseerde projekte -
mense te kry gebruik van die werf so vroeg as jy 'n soort van funksionele demo.
>> Nou gaan ek 'n bietjie oor hoe om 'n web-ontwikkeling projek te bestuur te praat.
Ons het gegaan oor hoe jy kan die tegniese back-end kant doen,
hoe kan jy 'n baie goeie site ontwerp,
en dit is 'n groot as jy werk deur jouself nie, maar -
selfs as jy werk deur jou en veral as jy werk in 'n span,
projek bestuur word 'n groot probleem.
Jy het soort van gehoor het oor die projek bestuur in verskillende vorme sedert
laerskool toe jy vertel groep werk.
Jy het om saam te werk, te kommunikeer, dit alles.
Dit geld nog almal hier, maar daar is 'n paar unieke omstandighede met
rekenaarwetenskap wat jy wil om bewus te wees, en jy wil om seker te maak jy goed hanteer maak.
Ek sal eers 'n bietjie praat oor die span wat jy sal wees in
Dit is baie belangrik om die regte grootte van 'n span saam te werk op te tel,
en in jou finale projek ek dink jy het die opsie om van te kies
tussen 1 en 4 mense as ek korrek is.
Jy wil om seker te maak dat jy nie net die keuse van die aantal mense maak
wat jy wil om te werk met, want hulle is jou vriende.
Jy wil 'n span wat 'n goeie grootte van te kies en wat sal kry om die werk gedoen.
Daar is 'n handels-af in die feit dat meer mense versus minder mense.
As jy meer mense, natuurlik meer werk gedoen kan word
want jy het baie van die mense, baie van kode, baie van die idees,
en dit is al groot.
Maar dit vereis ook 'n baie meer bestuur en 'n baie meer kommunikasie.
Met ander woorde, as jy 4 mense wat op dieselfde projek
en hulle is almal die wysiging van die dieselfde kode, min of meer hulle al die soort van behoefte om te weet
wat gaan aan, sodat dit vereis dat jy -
As jy 'n paar nuwe funksie voeg jy soort van om mense te vertel - ek-toevoeging van hierdie,
Ek is die verandering van hierdie op hierdie manier - veral as jy in die baie diep dinge
soos die modelle en die leiers wat eintlik gaan beïnvloed hoe die webwerf werk.
Die hele span moet bewus wees van dit,
sodat jy nodig het om seker te maak dat jy nie die keuse te 'n groot span wat gaan moeilik wees
dat kommunikasie te maak.
Jy wil ook nie 'n klein genoeg span wat jy nie gaan om te kies
in staat wees om te kommunikeer, want dit is net vir jou.
>> Nog 'n ding om te oorweeg is die balans van waar mense se vaardighede is.
Dit is 'n groot as jy al baie goeie programmeerders.
Maar as jy al back-end mense, dan is jou site is nie van plan om te kyk baie goeie
want jy het hierdie groot databasis, en dit het super-vinnige navrae -
wat is groot - maar wanneer jy na dit, dit is soos 'n tuiste 1990's met rooi en blou
oral, en dit is nie goed nie.
Let daarop dat Ben en ek werk as 'n span is baie mooi, want ek is soort van meer
in die voorkant, het ons albei interaksie in die middel-einde, en Ben is regtig goed met back-end dinge,
sodat werk baie goed, want ons kan enige site ontwerp en basies die gate
in die webwerf wat gevul moet word gevul kan word deur een van ons, of dalk beide.
Jy wil om seker te maak dat daar geen gate in jou span te maak.
Dit is goed as daar 'n bietjie van oorvleuel.
Met ander woorde, as jy 2 mense wat beide goed met agterkant,
wat kan goed wees as goed, want hulle mekaar kan help met probleme
dat hulle met.
Dit kan 'n probleem wees as jy net 1 persoon wat verantwoordelik is vir 'n sekere ding
en hulle hardloop in 'n probleem, so jy wil 'n bietjie van oorvleueling te hê
maar jy bowenal wil om seker te maak dat al die moontlike gate gevul te maak.
>> Die laaste ding - en dit moet duidelik wees, maar dit is dikwels nie.
Jy regtig wil word pret.
Die punt van hierdie finale projek in CS50 en dikwels die punt van die web-ontwikkeling in die algemeen
is nie om net te doen om 'n werk, want dit moet doen.
Jy regtig wil word pret, en jy wil iets wees om
dit is die motivering om te werk aan dit.
As alles wat jy maak, is 'n pyn te sit en werk op,
dan is jy nie die keuse van die regte projek.
Jy wil iets wat jy interessant vind om van te kies,
jy regtig wil hê dat die resultaat te sien, is jy opgewonde wanneer jy 'n nuwe idee oor
iets wat jy kan doen - so daar is alle vorme van projekte is daar dat ek seker
jy kan vind - almal het iets wat werklik sou intriges hulle
As dit is 'n web-gebaseerde projek te doen.
Ek sal dit weer sê nou.
As jou projek lyk soos 'n pyn en jy nie wil hê om te werk op dit,
kies 'n ander projek. Kies iets wat regtig inspireer jou.
>> Ben genoem die konsep van herhaling 'n bietjie, en ek wil om te gaan oor dit 'n bietjie.
Dit is baie belangrik om te werk in vlae waar jy iets funksionele bekom.
Dit kan groot wees as jy hierdie plan vir 'n webwerf wat gaan A, B en C te doen,
en uiteindelik sal dit daar te kry.
Maar jy vas in hierdie fase waar jy werk op dit en werk op dit,
maar niks is om gedoen. Jy hoef nie iets om te sien en 'n tasbare, funksionele ding.
Wat jy regtig wil so baie om te doen soos dit lyk soort van 'n pyn soms te
werk aan iets en dan soort van beperk dit af sodat dit ten minste op 'n stabiele, hardloop
weergawe selfs al is dit nie al die eienskappe wat jy wil.
En miskien is daar is 'n paar eienskappe wat jy regtig wil om by te voeg, maar jy kan net nie
want jy wil om hierdie webwerf te kry om 'n funksionele punt.
En so jy wil soort van die hele ontwikkelingsproses lyk soos dit.
Jy wil iewers funksionele begin - of wese begin met niks -
maar jy wil om iewers te kry baie basiese en funksionele.
En dan weer, maak 'n soort van spring en kry iewers funksionele weer.
Jy sal stadig opbou, en dit kan gaan 'n bietjie stadiger as wat dit andersins sou,
maar in die lang termyn as jy voortdurend vas in hierdie middeweg fase waar jy
nie eintlik enigiets te werk het, kan dit 'n baie groot frustrasie wees
om te werk aan jou projek, omdat jy altyd so naby aan om dit te maak werk
en dit was nog nooit werklik werk.
Jy wil om te werk in hierdie funksionele spurts,
en jy wil ook 'n paar besinning te doen nadat elkeen.
Met ander woorde, sodra jy by 'n punt waar die terrein is nou besig -
dit nie alles wat jy wil hê, maar dit nie 'n paar dinge -
jy wil om te dink, okay, is hierdie site die bereiking van die doelwit wat ek het om te doen?
Met ander woorde, indien die werf gaan X te doen, is wat ek werk het in die rigting van X?
Is al die funksies wat ek daar wou?
Verder, is dit die bediening van die algehele doel wat ek wil hê?
As jy vind dat jou site is besig om te veer in 'n ander rigting
of miskien dinge net soort van nie uit te werk, is dit dalk tyd ratte te skuif 'n bietjie wees.
Met ander woorde, dit is die moeite werd oorweging nie - dit is die moeite werd om te gooi uit idees, indien nodig
en oorweeg ek regtig werk aan wat ek wil wees.
>> Ek glo dit is my volgende punt. Moenie bang idees te laat vaar nie.
Net omdat jy spandeer baie ure op 'n funksie
en uiteindelik het dit werk nie, maar dit is regtig nie so goed gaan -
soos dit is nie so nuttig of gebruikers sukkel om dit te gebruik - dié soort van ding -
moenie bang wees om dit te gooi weg wees.
Dit suig dat jy het spandeer baie tyd daaraan werk,
maar uiteindelik wat jy wil nie 'n webwerf wat is soort van saam te stel wat deur hierdie stukke wat
soort van werk, maar nie so goed gedien het.
Ook, moenie bang wees om nuwe idees te aanvaar nie.
As iemand kom saam en sê, hey, die site lyk regtig cool, maar
sou dit nie eens wonderlik wees as dit ook gedoen het?
Net omdat dit is iets wat jy nie van plan is en iets wat nie in jou
specs, iets wat jy nie het om te doen,
moenie bang wees om dit te neem op en dan werk met dit.
Want dikwels die idees wat jy loop met die hele loop van die ontwikkeling
uiteindelik die regtig cool kenmerke van die webwerf.
>> Ek het dit voor gesê. Ek sal dit weer sê.
Testers is super, super nuttig.
Probeer om mense wat nog nooit gesien het die terrein voor te meld en te sien wat gaan aan te kry
want hulle kan nie net die nut van die terrein en die gebruikers ervaring toets,
maar hulle kan ook die funksie toets op maniere wat jy nie kan nie.
As jy 'n paar funksie wat nie 'n sekere ding
en jy weet dit gaan dieselfde ding reg te doen elke keer, dit is groot.
Maar dit kan dikwels moeilik wees om verantwoording te hoek gevalle waar 'n gebruiker kan
tik iets wat jy nie verwag het nie - juis omdat jy omskryf
die funksies jouself.
So, om iemand kom wat geen idee hoe om die webwerf te gebruik het
en om net breek dit in watter maniere waarop hulle kan doen is werklik nuttig omdat jy
'n idee van 'n totaal ander perspektief van wat op jou werf is besig
en wat herstel moet word.
>> Laaste, ek gaan om te praat oor 'n paar algemene goeie praktyke,
en jy het 'n baie van hierdie in CS50, maar hulle het ook baie, baie van toepassing in 'n projek omgewing.
Een is kommentaar. Altyd kommentaar jou kode veral as jy werk op 'n groot span.
Dit kan so irriterende om net 'n reuse-blok van die kode dat iemand geskryf wees
en miskien is dit werk, miskien is dit nie gebeur nie, maar jy het geen idee wat dit doen nie,
sodat jy het geen idee of dit nuttig is of nie en of dit daar moet wees of nie,
en as jy werk op iets anders dit is selfs moontlik dat jy werk op
dieselfde ding, so net baie, baie versigtig om bedagsaam van jou maats te wees
en skryf kode wat goed gedokumenteer.
Jy hoef nie te so ver gaan as om die hele ding waar graag as jy inkrementeer te doen
'n toonbank het 'n opmerking wat sê, ek is die toevoeging van 1 tot hierdie toonbank.
Dit hoef nie te wees dat gedetailleerde, maar vir enige funksie wat jy ooit skryf
jy moet 'n dokumentasie van wat daardie funksie presies beteken het,
wat sy insette is, en wat dit moet terugkeer.
Die manier wat jy ander mense se komponente van die webwerf kan gebruik
en jy kan werk aan die bou van iets groots.
>> Nog 'n belangrike ding is wat jy wil gereelde skoon-ups te doen.
Kode kry slordig. Moet nie sleg voel as jou kode is net heeltemal deurmekaar en 'n reuse gemors.
Dit gebeur in die web ontwikkeling altyd.
Jy is die toevoeging van nuwe funksies, die verwydering van die oues. Dinge gaan om daar te wees dat jy nie moet wees nie.
Dit is goed, maar jy wil om seker te maak om gereeld te gaan met wat.
Jy wil nie om dit te laat bou tot op die punt waar jy kan net nie iets vind
in jou kode, en jy het geen idee wat niks doen nie.
Dit is die geval met HTML.
Soms sal jy eindig met voorwerpe wat niks bevat nie,
en jy wil om ontslae te raak van hulle.
In CSS, kan jy verwys word na elemente wat nie daar is nie,
so jy wil om ontslae te raak van die kode.
In JavaScript, kan jy iets uit die HTML verwyder het.
So, jy wil om seker te maak dat jy altyd die skoonmaak maak, maak dinge mooi
soveel as wat jy kan op 'n gereelde basis.
>> Nog 'n baie nuttige ding wat ek dink nie, is baie soos uiteengesit in CS50
maar dit is die moeite werd om in is weergawe beheer.
Die idee van weergawe beheer is wanneer jy basies die dop van al die vooruitgang
jy gemaak het na jou webwerf en as op enige punt wat jy besef, o, dit was die werk
'n ruk gelede, maar dit is nie meer werk nie, kan jy terug gaan na die vorige weergawes
en kyk wat het verander sedert toe en daardie soort van ding.
Die primêre manier om dit te doen, is om met Git, en Git is hierdie hele soort stelsel wat
Ek glo Tommy MacWilliam het 'n seminaar oor die laaste jaar.
As jy in die CS50 seminare vir 2011, kan jy sy seminaar oor wat hulle sien.
Die idee van die Git is basies dat gereelde tussenposes jy maak hierdie verpligtinge
wat is maniere om te sê die terrein is in 'n mooi stabiele weergawe nou so
Ek is die verpakking is dit en stuur dit weg na 'n bediener, en dan kan jy gaan na die bediener
en kyk na al die vorige weergawes van die kode en kyk hoe dit vorder
en al wat soort van goeie dinge.
So, dit is dit basies.
So ver as die web-ontwikkeling, ons is gelukkig om rond te hou en beantwoord enige
vrae so ver as ons aanbieding.
Dit is dit. Dankie. >> [Ben] Dankie.
[Applous]
>> [Billy] Personeel, Is daar iemand enige vrae oor dinge wat ons het gedek
of dinge wat ons nie gedek dat hulle hoop ons wil bedek?
Ons wil graag diegene te beantwoord. Enigiemand?
[Lid van die gehoor] Wat is die voor-en nadele van die gebruik van Ruby of die gebruik van Python?
[Ben] Die vraag is, wat is die voor-en nadele van die gebruik van Ruby of Python
in plaas van soos PHP.
Die voordele is dat Ruby en Python is baie beter as tale PHP.
Ten minste in my mening, en ek dink in 'n baie ander mense se menings as well.
Hulle is meer vir die doen van komplekse dinge ontwerp,
en minder vir afranseling saam webblaaie regtig vinnig met
'n bietjie van 'n dinamiese inhoud.
Die nadele is dat daar 'n bietjie van - daar is meer van 'n leerproses
te kry om hulle opgestel.
Dit is, soos in PHP, kan jy net 'n HTML-lêer en jy minder-as skryf,
vraagteken, en dan moet jy skryf 'n paar kode, en dan kan jy skryf vraagteken,
groter-as, en dan is jy klaar.
In ander tale soos Ruby of Python,
jy het om te gaan deur 'n bietjie meer werk die eerste site aan die gang te kry.
Daar is ook - ten minste is dit gebruik om die saak te wees - dat daar is meer dokumentasie
beskikbaar vir PHP net omdat daar meer mense is wat dit gebruik.
Ek dink dit is nie so veel van 'n probleem nie.
Daar is beslis 'n baie goeie dokumentasie vir dinge soos Ruby on Rails
of Django vir Python is die ekwivalent.
PHP is die een wat almal se gebruik vir die jaar, en jy weet hoe dit werk.
Ruby en Python is 'n bietjie minder volwasse.
>> [Lid van die gehoor] As jy was om te kies tussen een van hulle te leer of optel,
wat sou jy verkies?
Eerlik, ek dink dit hang af van die persoon.
Ek is jammer. Die vraag was wat sou jy kies vir iemand om te leer?
Ek vind Python die mooiste persoonlik.
Daar is 'n klomp mense wat - ek het my eerste web dev projek in Python en Django.
Daar is 'n klomp mense wat graag Ruby on Rails ook.
Waarskynlik meer mense wat Ruby on Rails weet.
Eerlik, ek wil net gaan met alles wat die mense rondom jou weet
sodat jy het om mense om vrae te vra.
>> Die vraag was - op gedeelde bedieners is dit soort van hard te werk aan Python?
Dit hang af van jou hosting.
Daar is 'n aantal van die web hosts wat Python dinge plaas.
WebFaction doen dit, reg?
WebFaction is een wat ek en Billy het vir 'n paar projekte gebruik word.
Hulle is regtig baie goed. Hulle ondersteun die meeste tale.
Maar dit is waar dat PHP is baie meer algemeen ondersteun.
Dus, as jy vas op 'n web host dat slegs doen PHP, dit is 'n goeie rede PHP te gebruik.
>> [Lid van die gehoor] Ek het net in leer hoe om 'n databasis te bevraagteken,
en ek weet my SQL is al oor die plek nie, maar Ek het onlangs blootgestel aan -
en jy wys dit uit. Jy sien into en verwissel databasisse.
My SQL is nog oor die hele plek. Hoe sien jy wat gebeur?
Is daar gaan 'n groeiende tendens vir meer verwissel (onhoorbaar) te wees?
Die vraag was - ek dink daar gaan 'n neiging tot nie-SQL databasis te wees.
Byvoorbeeld, soos MongoDB. Ek dink dit is beslis waar.
My raad is meestal mySQL-verwante hier net omdat MySQL is
industrie standaard.
Persoonlik, ek het baie verkies om databasisse wat nie schemos soos MongoDB
waar jy nie die kwessie van, O, ek moet nog 'n kolom by te voeg.
Wee my, soos wat ook al kan ek doen?
Dit is baie moeilik om dit te doen op forum, maar wanneer jy iets soos Mongo
dit is baie lekkerder.
Die ander lekker ding van Mongo is dat jou rekords is eintlik JavaScript voorwerpe.
Daar is geen soort van sukses stap waar jy nodig het om hierdie databasis rye te neem
en draai hulle in 'n JavaScript voorwerp en stuur hulle oor die draad dan.
Ek dink dinge soos wat gaan wees baie, baie nuttig vir 'n vinnige web ontwikkeling in die toekoms.
>> [Billy] iets wat ek sou voeg wat net 'n algemene punt is dat
nie voel soos jy moet geleer het om al die tale wat ons het bespreek
van ons seminaar.
Dit is duidelik dat die punt is om jou 'n idee van wat daar buite gee,
en as jy geboei deur enige van die dinge wat ons genoem het Jy kan Google hulle
en lees oor hulle.
En soos ek genoem het, is daar 'n paar seminare wat handel oor presies hierdie dinge.
Daar is selfs meer seminare wat ek nie genoem het nie, wat waarskynlik kry in
hierdie dinge so goed.
Die idee is dat as jy wil om te werk aan iets, hier is die gereedskap tot jou beskikking.
Moenie oorweldig voel as jy nie seker wat die gereedskap presies,
maar weet dat hulle daar is en dat jy kan ruim gebruik maak van hulle
deur Google.
>> [Lid van die gehoor] Watter soort dinge het jy nodig om te doen seker dat jou webwerf te maak
lyk goed op mobiele toestelle?
[Billy] Mobiele toestelle is 'n bietjie hard.
Daar is 2 maniere waarop jy kan dit nader.
Die eerste manier is dat jy eintlik 'n mobiele webwerf.
Met ander woorde, jy het 'n paar soort van opsporing aan die begin
wanneer die leser die versoek om jou webwerf wat óf sê
terug hierdie siening - wat sal die vertoning vir rekenaar of laptop implementeer wees -
en hierdie ander oog vir mobiele toestelle.
Dit is 'n plek waar uitsig is baie mooi in dat jy kan pretty much ruil die
twee uit en het 'n koppelvlak wat werk regtig mooi op mobiele toestelle
en het 'n heeltemal ander een wat werk mooi op die leser toestelle.
Die probleem met dit is wat dit neem om 'n lang tyd, want dit beteken kodering
'n totaal ander koppelvlak.
Die ander manier waarop jy dit kan doen, is om -
'n baie moderne selfone sal vertoon webtuistes en probeer om hulle te lewer as 'n leser sou
en hulle hul bes doen.
Jy kan soort van probeer om die lig te bly op die bedrag van die jQuery JavaScript wat jy gebruik
wat geneig is om te wees waar dinge verkeerd kan gaan 'n bietjie.
Dit is 'n soort van die weg wat jy moet gebruik as jy nie het nie veel tyd.
As jy nie die tyd om te werk op 'n mobiele koppelvlak, dit is duidelik jou beste opsie.
>> Ek dink in die algemeen vir CS50 projekte, gaan jy een of die ander te kies.
Met ander woorde, wil jy 'n foon te maak of jy 'n lessenaar webwerf te maak.
En dat die soort van bepaal waar jy gaan met dit.
Maar as jy wil dit uit te brei later uit, waarskynlik jou beste bet is
'n ander koppelvlak vir die ander te maak.
Ek het 'n bietjie van die ervaring in die ontwikkeling WordPress-gebaseerde webwerwe.
Ek gasheer vir 'n persoonlike webwerf op WordPress vir 'n rukkie.
Diegene soorte raamwerke kan lekker wees, net soos baie basiese dinge.
Dikwels sal jy net loop in 'n baie flexibiliteit kwessies though.
Jy wil iets wat 'n sekere manier te kyk of 'n sekere manier te hê
en jy kan net nie, want dit is hard-wired in die stelsel wat
dit is hoe jy dinge wat kan 'n bietjie van 'n probleem te wees om te doen.
Sedertdien het ek soort van is meer geneig om te werk met webwerwe van die grond af.
Vir dinge soos blog databasisse en dat die soort van ding wat dit is regtig nie so moeilik om 'n raamwerk te bou.
As jy regtig strek vir tyd, kan jy natuurlik iets soos WordPress gebruik
of dat die soort van ding vir 'n blog.
Die soort dinge wat blogs winkel en doen nie regtig hard genoeg dat
as jy loop in enige van daardie soort dinge is, is jy waarskynlik die beste om net te
Maak 'n in-huis-weergawe.
>> Ek dink dit is oor dit, so dankie weer vir die komende.
Ons het dit baie geniet met jou praat ouens en hoop dat jy 'n paar dinge geleer.
[Ben] Ons is gelukkig om te praat - ons het om te gaan, maar ons is bly om te meer buite praat
As jy 'n ander vraag. Dankie weer. [Applous]
[CS50.TV]