[Powered by Google Translate] [Seminar] [Webudvikling: Fra idé til implementering]
[Ben Kuhn] [Billy Janitsch] [Harvard University]
[Dette er CS50] [CS50.TV]
[Billy] Hej, jeg er Billy, og det er Ben. >> [Ben] Hej.
Vi kommer til at tale om webudvikling i dag.
[Webdev] [Billy Janitsch og Ben Kuhn]
Lidt om os først.
Ben er en slags back-end fyr. Han gør tingene fungerer.
Og så går jeg ind og gøre dem smukke.
Jeg er stort set involveret med mere front-end layout design slags ting,
og Ben, på den anden side, ved, hvad han laver, så han arbejder på back-end stuff.
Sammen har vi gjort et par ting.
For eksempel sidste år har vi arbejdet på Gimblium som er en online spil udvikling studie.
Det var vores endelige projekt for klassen,
og siden da har vi gjort Harvard Class
som er en online ramme for browsing og shopping kurser på Harvard.
>> Vi vil starte med denne idé til vores hjemmeside.
Vi kommer til at gøre Facebook, men for katte.
Før du faktisk gøre denne hjemmeside,
gør ikke denne hjemmeside, fordi det er ikke godt, men vi vil bruge det som en ramme
og gå gennem processen med hvordan vi tager denne idé
og gøre det til en reel hjemmeside, vi kan bruge.
Vi vil starte med at bryde hjemmesiden ned.
Ligesom du har gjort i CS50,
du ønsker at tænke på, hvad er de faktiske komponenter, der går ind i denne hjemmeside.
Dybest set dreje det fra en idé, som er lige slags et abstrakt begreb
til en reel, håndgribelig ting, du kunne gøre.
Vi starter med at spørge nogle spørgsmål.
Hvad er dette websted? Hvorfor gør vi det?
Hvad det kommer til at blive brugt til? Den slags ting.
I tilfælde af Facebook Cat,
vi dybest set ønsker en hjemmeside der lader katte socialt netværk med hinanden.
Tanken er, at de kan skrive på hinandens vægge,
de kan gøre kommentarer, den slags ting.
Og det er her, vi kommer ind i de funktionelle komponenter.
Vi har nu den slags rammer - vi har brugerprofiler,
vi har kommentarer, og vi kan sende.
Måske en dag vil vi tilløb sympatier og den slags ting.
Og vi slags ønsker at prioritere disse funktioner går i.
Vi ønsker at sige ligesom, okay, det er virkelig vigtigt, at alle har en profil
og at alle kan skrive på hinandens vægge.
Sekundært til det, ville kommentarer være rart.
Måske senere vi influent lide.
Så du ønsker at have en idé om, hvad der er afgørende for dit projekt
og hvad der er en slags mere generel funktion, der kan anvendes senere.
Du ønsker at slags har en specifik liste i tankerne,
men det projekt, du starter med, er ikke til at være det projekt, du er færdig med.
Med andre ord, er tingene kommer til at ændre, mens du udvikler sitet,
og du ønsker at give plads til det.
Jeg vil vende det til Ben, hvem der kommer til at tale lidt om struktur.
>> [Ben] Jeg har tænkt mig at tale om den mere tekniske side af web-udvikling.
Lad os bare gå over nogle grundlæggende først.
Når du laver en web-app,
den vigtigste division, som du er nødt til at have, er
du kommer til at have nogle ting i gang i klientsiden -
det vil sige, den kode, du browser tager fra stedet
og JavaScript, HTML, CSS ting.
Det er alt på klientsiden.
Du kommer til at have en anden kode, der kører på serveren side
der holder styr på alle de data, som folk sender ind til dig,
afgør, hvem der giver hvad, den slags.
Dette er blot nogle terminologi, så du fyre er alle bekendt med, hvad vi taler om.
Ud over at division er det godt at tænke på din web-app i form af
et par forskellige komponenter.
Når du laver webudvikling
en af ​​de ting, som du bør altid forsøge at gøre, er at reducere kompleksiteten.
Jo mere kompleks din kode er jo større chance er der for at lave fejl,
jo sværere er det at ændre senere.
Så hvis du kan bryde op din app i nogle bestemte funktionelle områder
der vil - og du kan reducere den slags beløb på tværs af området kommunikation -
som vil hjælpe dig meget i det lange løb i form af reduktion af bugs.
>> For at være konkret, som regel folk opdele en web-app i -
disse er slags buzz ord nu, men de er stadig nyttige.
Du har måske hørt folk tale om modeller, synspunkter og controllere.
Modeller er de faktiske data, som din app kommer til at beskæftige sig med.
For eksempel i din kat Facebook, ville dine modeller være -
ville du have en model for lignende stillinger, og en model for brugerprofiler, den slags.
Dine synspunkter er, hvordan du præsentere disse data til dine brugere.
Du har måske 1 view for at kigge på en enkelt post og alle kommentarerne
og en anden visning til din væg, der har en liste over alle de stillinger
som er rettet til dig, og en anden visning for din news feed - den slags.
Endelig har du de controllere, som dybest set, når folk sende dig indlæg
og du foretager opdateringer til din back-end system,
du tilvækst en masse tællere, og hvad ved jeg.
Det er dine controllere.
>> Jeg har tænkt mig at være overvejende tale om modeller.
Synspunkter er teknisk set ikke så svært, og spørgsmålet er mere med at designe dem
Controllere vil være specifikke for hvad du designer.
Men der er nogle temmelig generelle teknikker, du kan bruge
for at gøre dine modellerne pænere og nemmere at arbejde med, som jeg mener er meget hjælpsomme.
Dette er for det meste vil være om hvordan man skal håndtere dine web apps data på en pæn måde.
De vigtigste problemer med modeller
er, at de lever på klienten og serveren, og du er nødt til at regne ud
a) hvordan man får dem - alle relevante dem - fra serveren til klienten,
og b), hvordan man kan holde dem i sync.
Dine brugere vil ønsker at gøre nogle opdateringer.
De vil ønsker at gøre nye stillinger.
De vil ønsker at lide ting og ting, hvis du har sympatier.
De er de vigtigste tekniske udfordringer at håndtere modeller.
Den første ting, du vil ønsker at spørge dig selv, er
hvilken slags data går i denne model, og hvilken form for henvendelser vil vi ønsker at gøre -
det vil sige, hvordan skal vi se på de modeller?
For din kat Facebook eksempel
dit indlæg kommer til at have en forfatter forbundet med det,
nogle Væg tekst, og en modtager af muren indlæg.
Og så skal du måske ønsker at forespørge, at i en masse forskellige måder.
Du ønsker at se på det med hvem der skrev hvilke indlæg,
ved der modtog som skrive, måske på den dato, de blev bogført.
Men hvis du vil gøre det efter dato, så er du nødt til at tilføje et andet felt til dit indlæg
på, når det faktisk blev skrevet.
Disse 2 faktorer - hvilke data, du vil bruge, og hvordan du ønsker at se det -
du skal tænke på dem først, fordi de er afhængige af hinanden,
og det vil være vanskeligere at tilføje dem senere hen.
>> Der er nogle andre overvejelser.
Når du tænker på hvordan du håndtere modeller på serveren
hvad du ønsker at se på, er -
du dybest set ønsker at gøre serveren så enkel som muligt.
Gør ting på klientsiden er generelt meget hurtigere, hvis du kan gøre det alene på klienten
uden at gøre nogen form for anmodning netværk.
Ideen er at gøre så mange af de forespørgsler, som du kan på klienten.
Det eneste problem med,
er, at hvis du beder om alle dine data i begyndelsen
så der kommer til at tage lang tid at indlæse.
Så ideen er at finde en gylden middelvej mellem at have nok data på klienten
at du kan gøre det meste af dit arbejde der, men ikke bare hente alt på en gang
så du får virkelig langsom load tider i begyndelsen.
For eksempel, for din kat data
ville du sikkert vælge at hente en masse af de seneste væg stillinger.
Du ville ikke ønsker at hente dem alle, fordi der kunne gå tilbage et par år.
Men du ikke ønsker at hente dem én ad gangen
fordi det ville indføre en masse netværk overhead.
>> Det er ofte ganske hårdt - når du har en database kørende -
Det er ofte ganske svært at ændre, hvilke data, du har i det -
det vil sige, tilføje en ny database kolonne eller noget -
så en god strategi er faktisk bare at holde en masse af dine data i en tekst klat -
en JSON klat - JSON er JavaScript Object Notation -
Grunden, der er nyttige, fordi så kan du tilføje nye egenskaber
til alle disse JSON klatter uden at ændre din database.
Den eneste ulempe til dette er, at hvis du har en masse felter
at du har tilføjet senere - ligesom skjult i denne JSON klat -
så er det sværere at forespørge dem inde i databasen.
For eksempel, hvis du senere - hvis du havde dit indlæg model, som vi diskuterede tidligere
med blot forfatteren, modtager og tekst -
du kan også have en JSON klat og derefter, hvis du senere ønsker at tilføje et datofelt
ville du ikke nødt til at ændre din database.
Du kan bare tilføje datoer til alle tekstfelter.
Og så ville du være i stand til at se på dem på klientsiden,
men du ville ikke være i stand til at forespørge dem på serveren side
fordi det er skjult inde i teksten.
>> Det andet spørgsmål, som du ønsker at tænke på
er, hvordan din klient og din server kommer til at kommunikere.
Du ønsker som regel at holde dette så simpelt som muligt.
Du kan bare have som en get-mig-denne anmodning data
en create-a-new-objekt ting, og en update-en-gammel-objekt anmodning.
Og disse vil alle være forskellige webadresser på en server, som du -
at browseren vil - du kan bruge AJAX anmodninger om alle disse
og enten modtage eller sende data.
Igen, for vores kat Facebook eksempel
kunne du have denne webadresse til at få en individuel post
og du ville have en URL til at oprette en ny mur indlæg
og måske en URL til at uploade dit profilbillede, den slags.
Men igen, det er til at pre-hente de fleste af dine data, så du ikke behøver at holde
gør netværksanmodninger.
Af denne grund, kan du ikke ønsker at have den individuelle komme anmodning om en enkelt stilling,
og i stedet vil du bare ønsker 1 get anmodning om hele væggen.
Og så hvis du forsøger at finde en balance, fordi -
dette også kommer til at afhænge af din ansøgning.
Fordi hvis du forventer, at folk kun har 10 eller 20 væg stillinger
der vil være fint.
Men hvis du forventer, at de vil have tusindvis da, at anmodningen ville tage for lang tid,
og så du måske ønsker at tilføje en få-alle-indlæg-siden parameter.
>> For alle disse du sikkert vil ønsker at synkronisere dine data i JSON -
JavaScript Object Notation.
Stort set hver eneste sprog omhandler JSON meget godt.
JQuery har denne nice getJSON funktion, der vil gøre alt det hårde arbejde for dig.
Og på PHP er der også meget rart JSON kommunikationsfunktioner.
Så det er nok det bedste format til at sende dine modeller frem og tilbage.
>> Som et eksempel på, hvad vi har talt om indtil nu,
her er et eksempel flow for din kat Facebook-applikation.
Det starter ud med din browser anmoder om basen hjemmeside URL.
Serveren sandsynligvis ville sende over statisk HTML og nogle JavaScript og CSS.
Det er normalt bedst ikke at gøre nogen præstationen på serveren.
Du har sandsynligvis ikke ønsker at -
hvad serveren er ikke at gøre der er på vej ned af listen over væg stillinger
og generere nogle HTML for hver enkelt og sende det forbi.
Det er normalt bedst at gøre det på klientsiden fordi ellers
hver gang du ønsker at re-tegne noget, er du nødt til at lave en server anmodning.
Og at meget hurtigt giver dig en masse af overhead.
Det er normalt bedst bare at skibet sender ned statisk HTML
og derefter JavaScript og CSS, der vil gøre rendering på klientsiden.
Så snart, at ting kommer ind,
så kan du få - i JavaScript - du kan gøre anmodninger om muren data
og den slags, og efter at serveren er dybest set bare at gøre databaseforespørgsler
og kontrol tilladelser.
Det eneste vigtige er, at det ikke kan sende over nogle andre brugeres væg stillinger
at du ikke får lov til at se.
Det kan principielt være et meget tyndt lag adgang til din database,
og så alle de viser data - alle de synspunkter og kram -
dem kan ske i din browser, og så når du ønsker at gøre en post eller noget
du bare sende en ny anmodning.
>> Der er også nogle smarte ting, du kan gøre på toppen af ​​dette.
I form af mere specifikke tekniske oplysninger,
udvikling i almindelig JavaScript kan være en lille smule ondt,
så der er nogle biblioteker og værktøjer, der vil hjælpe dig meget med det.
Jeg tror, ​​du har alle sikkert hørt om jQuery, der gør laver HTML rendering
og manipulation meget nemmere - har masser af smarte funktioner til fading ind og ud,
og gør zippy animationer.
Der er også dette bibliotek kaldet Underscore.js.
Det har en masse nyttige nyttefunktioner, ting, som du ville forvente at JavaScript have
, at det virkelig gør ikke - ting som blander et array,
fjernelse af dubletter fra en liste, eller udfladning en liste af lister.
Dette er blot et lille kodeeksempel.
Understregning har et væld af disse dejlige funktioner, som du ønsker du ville have hele tiden.
>> Og så er der 1 mere bibliotek, som jeg gerne vil bruge en lille smule tid på
kaldet Backbone.js fordi Backbone virkelig hjælper dig med at håndtere modeller på klientsiden
og en masse af den forvirring, det kan forårsage.
Backbone giver dig dette koncept af modeller og samlinger
i JavaScript, der er dybest set nøjagtig ligesom JavaScript objekter
i JavaScript arrays, men de har begivenheder, når du ændrer deres egenskaber.
Ligesom i JavaScript, kan du have en begivenhed, når en knap bliver klikket eller noget
disse Backbone modeller og Backbone samlinger vil udsende ting som
at når de ændres.
Det betyder, at du bare kan skrive noget som dette stump kode her -
det siger, når du tilføjer noget til det indlæg matrix du gentegne hele væggen.
Og det vil sige, når en post nummer af folk ændrer sig,
du underrette brugeren om, at nogen kunne lide deres indlæg.
Eller når et formuegode af en post ændrer du gentegne indlæg.
Ting som der vil spare dig for tonsvis af kompleksitet, fordi ellers
hvis du ikke har nogle rammer, som denne derefter hver gang i din kode, som du ændrer
noget om et indlæg, ville du nødt til at huske dig selv at ringe til alle gør funktioner
og den slags, og hvis du ønskede at tilføre noget nyt, at der skete
hver gang du ændrede et indlæg, du er nødt til at gå igennem hver sted i dit
kode, som du ændrede en post og tilføjer, at nye ting.
En ramme som dette vil fjerne en masse af det mellem-lag kommunikation
der gør din kode komplekse og svære at vedligeholde.
>> Der er en lille smule om synspunkter også.
Jeg har tænkt mig at forlade det meste af dette til Billy, fordi de er teknisk set ikke meget vanskeligt.
Brug jQuery for dine synspunkter. Det er næsten ligesom en nødvendighed på dette punkt.
Det bare gør det hele så meget lettere.
Der er en masse af biblioteker.
Hvis du har komplicerede bruger-interface elementer,
hvis du vil have en auto-complete ting eller som en af ​​de smarte multi-vælgere -
hvis du vil have noget lignende, bør du nok bare søge rundt
og du kan finde et godt bibliotek, som vil gøre hvad du vil.
Billy vil forklare mere om de faktisk vanskelige dele af synspunkter.
Også, som en side bemærkning, Backbone har nogle funktioner til at gøre synspunkter kommunikere
pænt med modeller - se dokumentationen for alle disse biblioteker, faktisk.
Bare se på de docs. De er meget velskrevet og let at følge.
I almindelighed, kan du stort set bare Google, hvis du har problemer.
Der er en masse mennesker, der bruger dem.
Jeg tror, ​​det er som en afsluttende bemærkning.
>> Der er også nogle mere avancerede ting, du kan gøre
hvis du søger at gøre din web-app ekstra awesome.
Du kan gøre - den nye HTML5-specifikationen har en masse smarte ting, du kan gøre.
Lokal lagring - som er du kan gemme data i browseren -
snarere end at skulle gå tilbage og granske serveren for alt,
du kan holde noget af det på klienten, og at selv lader folk -
i nogle tilfælde kan det endda lade dig bruge websiden offline.
Der er denne ting kaldet WebSockets som er en anderledes form for netværkskommunikation
hvor der i stedet for bare du laver en anmodning, du får svar, og du er færdig,
du holder åbne en forbindelse til serveren og så kan du gøre ting som
real-time opdateringer.
Så hvis du prøvede at lave en chat app, kan du bruge WebSockets
at kommunikere frem og tilbage, så du ikke ville have til at holde anmoder om,
"Åh, server, gjorde nogen sende mig en chat?" hvert 10. sekund eller noget.
Der er også en interessant HTML5 funktion, hvor du kan få det til at ligne
webadressen på den side, ændrer uden nogensinde at skulle faktisk genindlæse den.
Du kan bruge frem og tilbage knapperne uden at gøre en masse af anmodninger netværk.
Ting som der er virkelig nyttige i form af at gøre det hurtigt, men også fungerer som en web-app skal.
>> Der er også denne ting kaldet CoffeeScript.
CoffeeScript er et andet sprog, faktisk, der kompilerer ned til JavaScript.
Du vil skrive al din kode i CoffeeScript, og så skal du køre denne compiler,
og den spytter en JavaScript-fil, som du kan medtage i din webside.
Grunden til, at CoffeeScript er rart, fordi det bliver fjernet en masse af de
mærkelige sager, Javascript, hvor lig ligemænd,
og lig ligemænd gøre forskellige ting, eller kan lide -
det har pænere syntaks til håndtering af arrays og funktioner.
Dette er en lille stump CoffeeScript der producerer en liste over alle de firkanter
fra 10 ^ 2 til 1 ^ 2 i omvendt rækkefølge.
Som du kan se, CoffeeScript lader ofte du udtrykke i 1 linje
hvad ville tage 5 linjer JavaScript.
Det kan gøre tingene meget nemmere.
Det er en lille smule af ny syntaks til at lære i første omgang,
men det helt sikkert vil gøre dig mere produktiv i det lange løb.
>> Du kan også bruge andre sprog på serveren end PHP -
sprog som Ruby, Python, eller der er endda et projekt kaldet node.js
der vil lade dig bruge JavaScript på serveren.
Personligt er jeg virkelig, virkelig hader PHP.
Jeg kan bare ikke lide at arbejde med det.
Hvis du også synes, det er en forfærdelig cluge af et sprog,
så kan du bruge en af ​​disse i stedet.
I almindelighed, hvis du ønsker at gøre noget, og du ikke rigtig ved, hvordan du ville gøre det,
bare søge på internettet.
Der er tonsvis og tonsvis af ressourcer især på -
StackOverflow er en stor en.
Det er denne hjemmeside, hvor programmører stille hinanden spørgsmål.
Du har måske løbe ind i det, hvis du havde problemer på CS50 problemet sæt.
Og der er tonsvis af biblioteker til at gøre stort set alt, du ønsker.
Hvis du ønsker at gøre noget, og du ikke ved hvordan man gør det,
ikke antage, at det er umuligt.
Bare se dig omkring, og du kan finde nogle gode ressourcer.
>> Som en generel indpakke,
de vigtigste grillbarer er at holde tingene simple.
Jo mere kompleks din kode er i begyndelsen
og jo mere du forsøger at gøre fancy ting,
jo længere vil det tage at få noget faktisk funktionel
og jo sværere vil det være at ændre senere.
Så gør tingene på den dumme, nem måde først.
At gå sammen med,
skal du ikke være bange for at smide gamle kode eller rense det op en masse.
I almindelighed, når du rent faktisk har noget arbejde,
det er meget lettere at tænke på, end når du er stadig i begyndelsen etaper
af hvordan sætter jeg det hele sammen.
Det er bedst at gøre det dummeste mulige design, der virker
og dermed forbedre det iterativt end at forsøge at få alting rigtigt første gang.
Med hensyn til klient-server division, så prøv og holde din server meget enkel -
bare en database og nogle autentificering og ikke gør noget hårdt arbejde der.
Gør alle dine komplicerede ting på klientsiden i browseren
i JavaScript så meget som du kan.
Kig rundt for biblioteker, der gør dit liv bedre.
Altid bedre at bruge kode, som en anden skrev
Hvis du - og ikke at skrive det selv.
Der er en masse ting på internettet. Google er din bedste ven.
Google er programmør bedste ven.
Ja, absolut ikke være bange for at kigge rundt efter ting.
Ok. Og over til Billy.
>> [Billy] Faktisk, før jeg starter med nogle design ting,
nogen der har nogen spørgsmål til Ben om noget, han talte om?
Okay, godt.
Igen, lad os vide, hvis noget er ikke klart
eller hvis du gerne vil have os til at gå over noget lidt mere.
Jeg har tænkt mig at træde lidt tilbage og snakke om de mere fundamentale dele af design.
Ben nævnte model kaldet - undskyld, model controller view-system
som er en slags det tekniske aspekt, så jeg har tænkt mig at kigge på udsigt specifikt
og jeg har tænkt mig at starte med, hvordan du ville designe en visning, der ser pænt.
Her er lidt af en virkelig grundlæggende skabelon for vores kat Facebook.
Jeg tror, ​​der er nogle grundlæggende i moderne UI design
der er værd at tage op.
Du kan mærke der er en masse hvid plads over hele siden,
masser af plads til ting.
Må ikke føler at du er nødt til at mase tingene på en side.
Du ønsker at forlade masser af plads åben, og hvis du går til næsten enhver moderne hjemmeside
vil du se, at der er hvidt overalt.
Der er hvidt i steder, du ville forvente.
Du har denne farvepalet, og det er klogt i begyndelsen
at vælge en farvepalet, som du kommer til at arbejde med og udvikle sig.
Du skal også - det hjælper at vælge en skrifttype, og den måde, du slags arbejder med
disse konkrete grundlæggende elementer i design.
Du har din type, du har dine farver, og derefter kan du slags
passer alt andet i efter behov.
Så, som jeg sagde, med dit farveskema, du vil bruge mere dristige farver i din farvesammensætning
sparsomt. Headers er nice. Knapperne er rart at have virkelig store, prangende farver.
Men generelt, hvis du har en hjemmeside, der har farver overalt,
alle stirrer dig i ansigtet, det bare ser rodet, og det er ikke godt.
Du ønsker at generelt bruge lyse farver.
Prøv at, igen, vælge en temmelig sammenhængende farveskema.
Du kan have disse små stænk af masser af farve -
der kan se temmelig rart, men du ønsker at bruge dem temmelig sparsomt.
>> Som jeg sagde, du ønsker at være minimal. Mindre er næsten altid mere.
Hvis du kan vise noget eller ikke vise noget,
og du er slags usikker på, om det skal være der som standard -
sandsynligvis du bedst off forlader det ud. Du kan altid tilføje det senere.
Ja, holde tingene simple.
Men vigtigst af alt, du ønsker at overveje flere designs.
Tror ikke, at når du laver en hjemmeside, du har det i dit hoved, at du kommer til at
gøre området på en bestemt måde, og det kommer til at se ud nøjagtig som dette.
Det kommer til at have den blå overskrift i toppen og den blå side bar
og derefter den gule sub-header ting.
Du ønsker at foretage flere skabeloner.
Du kan enten - hvis du er god med Photo Shop, kan du åbne det op og sortering af
designe en hjemmeside, som du kan lide det skal se ud.
Hvis ikke, kan du bare bruge pen og papir,
men ridse op flere designs.
Du ønsker at dybest set har et sæt op hvor du har masser af forskellige designs,
og hvis man ender arbejde, så det er fantastisk.
Hvis man ender ikke, så du altid har en anden til at henvende sig til.
I almindelighed, ikke føler at du skal begrænses
til, hvad design du oprindeligt beslutte.
Design er meget varierende, og en del af betydningen af ​​den model
controller view-system er, at du kan bytte ind og ud af forskellige synspunkter, du ønsker.
Du kan svaje data den ene vej, og derefter beslutte, åh, faktisk, der ikke fungerer så godt.
Jeg synes, det er lidt for kompliceret, eller der er en del her, der er ikke rigtig fungerer,
så jeg bare at helt opgive dette synspunkt og swap i en helt ny.
Vi kan stadig bruge de gamle modeller og de gamle controllere.
Vi kan gøre alt på serveren og klienten, som vi ville før.
Men den egentlige bølge af data som vises, kommer til at være lidt anderledes.
>> Så langt som rent faktisk gennemfører det design, du ønsker,
når du har et par designs skitseret på papir eller på Photo Shop eller hvad,
der er en række af værktøjer, der stilles til rådighed for dig.
Det første du er meget fortrolig med, som er din HTML, PHP, eller hvad
sprog, du bruger blot at kode de statiske sider på dit websted.
Du har arbejdet meget med HTML, hvilken slags giver dig disse tags
at du kan sætte tingene i, og dybest set er det en måde at organisere dit indhold.
For eksempel har du overskriften deroppe, så du kommer til at have en header tag,
og det kommer til at have noget tekst inde i det, som sandsynligvis kommer til at være i et andet tag.
Så har du en sidebar måske med nogle forskellige links,
og dem vil alle være i separate tags.
Så dybest set HTML på sit hjerte er en måde at dele op på siden, hvordan
du i sidste ende ønsker at formatere den.
Så igen, har du set det før.
Du er temmelig komfortabel med at arbejde med det nu
givet at du har gjort det sidste PSET forhåbentlig
så der bør være noget problem.
>> Så har du CSS, som dybest set håndterer alle de design statiske aspekter.
Det vil håndtere alle de farver, alle positionering af forskellige elementer,
hvor de går i forbindelse med hinanden,
hvor store de er, de forskellige typer af positioneringer som du ville have -
med andre ord, kan du har tingene fast, så når du ruller ned de ophold,
eller du kan have ting i forhold til andre elementer.
Alle den slags ting er i CSS.
Desuden kan du gøre forskellige dekorationer, kan du få tekst farver,
tekst effekter, som alle den slags ting.
Ben gav et virkelig godt seminar om dette sidste weekend,
og så ville jeg helt sikkert tjekke det ud, hvis du planlægger at gøre nogle smarte ting med CSS.
CSS3 er faktisk den nyeste version af CSS, og det kan gøre alle mulige virkelig pæne ting.
Det kan gøre hældninger, og du kan få pæne, afrundede hjørner, og du kan gøre alle mulige ting
at gøre dit website ser mere moderne og fancy.
>> Det næste værktøj er JavaScript og jQuery som Ben snakkede lidt om,
men jeg får en lidt længere ind.
JavaScript, som du har arbejdet med det en lille smule, eller i det mindste set det i foredrag,
er lidt af en måde dynamisk gør ting i HTML.
HTML, som du ved, er statisk, så når du har HTML kan du ikke ændre det.
Men JavaScript, på nogle måder, er en måde at være i stand til at ændre HTML.
Så du kan gøre det, og det er fantastisk, men JavaScript er virkelig en smerte at arbejde med.
Det er så lang og sløv og gøre selv de simpleste ting
kræver masser af linjer af JavaScript.
Så jQuery er dybest set et bibliotek for JavaScript, der forenkler alt dette.
Den siger, okay, hvis du vil have en firkantet kasse kommer fra venstre
og fade ind på siden, så den er i midten, i JavaScript, der ville tage -
Jeg ved det ikke, hundrede linjer til at gøre, og det ville være en smerte,
og du kommer ud af det hade alt om web programmering.
JQuery du dybest set har det element-dot-fade-in, eller noget lignende.
Så meget, meget simple funktioner, der vil lade dig gøre alle mulige smarte animationer
og den slags ting.
Den anden ting, at disse 2 er virkelig godt for bare at gøre dynamiske ting
med hjemmesiden.
Så i stedet for bare at have din HTML-side - som viser nogle data, men faktisk ikke
gøre noget - JavaScript og jQuery vil lade dig få knapper, som du kan klikke på,
og du kan trække elementer og genbestille dem og sortere dem, og få nye elementer
tilføjes eller fjernes. Du kan tilføje, slette, den slags ting.
Så jQuery gør tonsvis af cool ting.
Og Vipul er faktisk at give et seminar om det i dag, tror jeg, på 5-klokken,
så hvis du kan holde sig rundt i så længe, ​​at ville - 5 eller 4?
Four. Undskyld. Det er faktisk lige efter dette, så jeg vil anbefale
stikning rundt for det, hvis du kan.
JQuery er super, super nyttige, og du vil være i stand til at gøre masser af virkelig gode ting med det
for stort set alle web udviklingsprojekt.
>> Nu vil jeg gå ind i sådan en forskel.
Jeg har talt dybest set om brugergrænsefladen.
Brugergrænsefladen er bare design af hjemmesiden.
Men der er lidt andet koncept, som er brugeroplevelse.
De to er meget forskellige.
Interface er afgjort en del af oplevelsen.
Med andre ord, når du går til et websted, du ser på grænsefladen.
Det er en del af, hvordan du oplever sitet.
Men Brugeroplevelsen er mere end det.
Brugeroplevelsen er om, hvad det indtryk, at brugeren får fra dit websted er.
Så naturligvis interface er en del af.
Og det er absolut en nødvendig del, men det er ikke tilstrækkeligt.
Med andre ord, hvis du har en dejlig brugerflade, og det er temmelig og farverige og alt dette,
det er fantastisk, men hvis brugeren går til dit websted, ser en smuk layout og det er forvirret af
alt, har ingen idé om, hvordan at gøre noget, så selvfølgelig har du lavet en rigtig
dårlig hjemmeside.
Det er slags hvor brugerens oplevelse kommer ind
Jeg har tænkt mig at tale lidt om design UX - UX er en forkortelse for brugerens oplevelse -
og art af, hvordan du kan sikre dig, at du har en god brugeroplevelse.
Det første punkt er, at du kan designe en hjemmeside, hvor en bruger kan gøre noget,
at brugeren muligvis ønsker.
Men hvis brugeren ikke kan finde ud af at gøre disse ting -
med andre ord, hvis brugeren ikke har en god idé, når de går til dit websted af,
"Åh, hvis jeg vil opdatere min profil, så jeg klikker på denne knap, eller hvis jeg ønsker at skrive på
nogens væg, så jeg går til deres væg, og klik på en lille boks. "
Hvis brugeren ikke kender det, så du effektivt har faktisk ikke
implementeret denne funktionalitet korrekt.
En del af at gennemføre en funktionalitet er, at brugerne faktisk er i stand til at bruge det.
Og det kan være frustrerende - du kan lave en hjemmeside, og det kan gøre alle former for
vidunderlige ting, men så har du folk teste det og sige, "Det kan ikke gøre dette.
Hvorfor kan det ikke gøre det? "Og du vil sige tilbage til dem,
"Tja, det kan. Du skal bare nødt til at gå ind i det 7. drop-down menuen på denne obskure
side, der kun findes ved et link nederst højre hjørne "eller noget.
Det er klart, du ikke ønsker det.
Du vil have det til at stå klart for dine brugere, hvad de skal gøre,
og det bør være enkel og intuitiv for dem.
>> En anden ting, som du ønsker at prøve at gøre, er, hvis nogen kommer til at gå til dit websted
og 9 ud af 10 gange gør handling A, og 1 ud af 10 gange gør handling B,
du sandsynligvis ønsker at fokusere deres erfaringer på handling A.
Med andre ord, du ønsker at gøre det meget, meget klart hvordan A.
A skal være front-og-center - gå til webstedet, se det, åh, det er lige der.
Mens B selvfølgelig, du ønsker at være klar, men du kan efterlade det lidt mere
i baggrunden.
David giver et godt eksempel på dette i foredrag,
som er Boston T systemet.
Når du går til Boston T og du ønsker at købe en billet,
du nødt til at komme ind i 5 menuer, før du rent faktisk kan købe en billet
for en $ 2, $ 2,50 værdi, hvilket er, hvor meget det tager at ride metroen
i én retning.
Det er et problem, fordi de fleste mennesker, der er ridning metroen
sandsynligvis blot ønsker at henvende sig ét sted, købe deres billet, komme på det samme.
Det giver ikke mening, at de er nødt til at gå gennem masser af forskellige menuer
at komme dertil.
En bedre brugeroplevelse ville være en hurtig knap på den første side
der bare siger "købe en enkeltbillet ', og der ville sætte i alle standard
standardværdier, og så hvis nogen ønsker at købe en anden billet end det,
de stadig, selvfølgelig, har mulighed for at, men du har optimeret for
common-use case som er virkelig vigtigt.
Du kan se eksempler på dette på Facebook, ikke?
Hvis du går på Facebook, og du ønsker at skrive en status,
det er helt i top, hvilket er hvad du ofte ønsker at gøre.
Så snart du træder ind i siden, kan du gøre de mest almindelige ting, som
du ønsker at gøre.
Hvis du ønsker at gøre lidt mere komplicerede ting som,
sige, at jeg ønsker at gå til min vens væg og sende et billede på det -
som jeg ønsker at gøre ofte, men ikke så ofte som udstationering statusopdateringer -
så i dette tilfælde, jeg skriver deres navn i boksen øverst, skal du klikke på deres profil,
og så stadig, det er helt i top der, når jeg har fået til deres profil.
Igen, jeg har optimeret i prioritet for de mest almindelige-use cases.
>> En anden vigtig ting er, at folk ofte vil slags forsøge at komme omkring dette
ved at sige, okay, så jeg har lavet hjemmesiden, og folk finder det forvirrende,
og det er et problem, ikke?
Det er klart, jeg ikke vil have folk til at blive forvirret af indholdet af min hjemmeside.
Men den måde at løse det er ikke at have noget poppe op siger,
hey, jeg har tænkt mig at lære dig, hvordan du bruger denne hjemmeside.
Trin 1 - klik på denne knap. Trin 2 - gå her.
Sure, det er en måde omkring det - det er en måde at du kan fortælle folk, hvad de skal gøre, men det er
virkelig ikke den optimale måde.
Hvis jeg går til en hjemmeside, og pludselig jeg bombarderet med denne tutorial, der fortæller mig,
hvad de skal gøre, og hvor gå og alt dette, det er ikke sjovt for mig.
Det er ikke en god oplevelse for mig.
Det er lidt af en smerte. Jeg ønsker bare at begynde at gøre ting.
Folk kommer til at lukke ud af deres dialogboksen
eller komme ud af tutorial, ikke ved, hvad de skal gøre, og derefter klage, fordi
du ikke har fortalt dem, hvad de skal gøre.
Den måde at løse dette er ikke ved at give nogen form for tutorial eller retninger -
noget lignende.
Så meget som du kan undgå det, du virkelig ønsker at vise brugeren, hvad de skal gøre
blot ved karakteren af, hvordan hjemmesiden er lagt ud.
Med andre ord, hvis jeg går til Facebook uden at logge ind,
den første ting, jeg ser på forsiden -
det er lidt loginbokse. Så duh. Jeg er nødt til at logge ind Det er lige der.
Henviser til, at hvis jeg gik til Facebook, og jeg var nødt til at klikke på et lille link nederst
der sagde "Log ind", og resten af ​​den side var bare en slags billede eller noget,
Jeg ville ikke rigtig ved, hvad de skal gøre, ikke? Jeg ville blive forvirret.
Så kunne det fortælle mig at gå derned, og klik på knappen for at logge ind,
eller log ind-knappen kan være helt i toppen, hvor jeg har tænkt mig at se det.
Du ønsker at altid være at vise brugeren, hvad de skal gøre,
og det bør være indbygget i selve siden.
>> Når du tænker på design og spottende op forskellige måder
udtrykke dit websted, du virkelig ønsker at tænke over, hvad brugerne vil
gøre, og hvordan du kan vise dem, hvad de skal gøre.
En sidste ting er test er virkelig, virkelig vigtigt.
Det er fantastisk at få nogen - få en ven, få en person, du ikke kender endnu -
som aldrig har set stedet før at bruge hjemmesiden.
Fordi du har arbejdet på stedet i timevis, har du været stirre på det,
og du ved præcis, hvad de skal gøre, så selvfølgelig du kommer til at teste
ting, som du har arbejdet på, og at du ved arbejde.
Men hvis en anden kommer og bruger det websted, der aldrig har brugt det før,
Det er en unik oplevelse, fordi du har en person, der ikke har nogen forudgående kendskab
af stedet går ind i det, så de kommer til at have en effektiv ingen idé hvad de skal gøre
eller hvilken slags use cases er til stede for dem.
Det er godt. Det er enestående, fordi de er hovedsagelig en person med en blank for et sind.
De kan fortælle dig, hvis noget er forvirrende eller uklare.
De kan give dig en idé om præcis, hvad brugerens oplevelse af dit site er.
Det kan være meget svært at sige, at dig selv, så helt sikkert jeg vil opfordre dig
som du udvikler dine projekter - hvis du laver web-baserede projekter -
at få folk bruger webstedet så tidligt som du har en form for funktionel demo.
>> Nu vil jeg til at snakke lidt om, hvordan man styre en web-udviklingsprojekt.
Vi har gået over, hvordan du kan gøre det teknisk back-end siden,
hvordan du kan designe en rigtig god hjemmeside,
og det er fantastisk, hvis du arbejder med dig selv, men -
selv hvis du arbejder ved dig selv, og især hvis du arbejder på et hold,
projektledelse bliver et stort problem.
Du har slags hørt om projektledelse i forskellige former siden
grundskole da du fik at vide, gruppearbejde.
Du er nødt til at samarbejde, kommunikere, alt dette.
At alle stadig gælder her, men der er nogle unikke omstændigheder med
datalogi, som du ønsker at være opmærksom på, og du vil være sikker på du håndtere godt.
Jeg vil tale først lidt om det hold, du vil være i.
Det er meget vigtigt at vælge den rigtige størrelse af et team, der skal arbejde på,
og i dit sidste projekt, jeg tror, ​​du har mulighed for at vælge
mellem 1 og 4 personer, hvis jeg er korrekt.
Du ønsker at sikre, at du ikke bare vælge antallet af personer
at du ønsker at arbejde med, fordi de er dine venner.
Du ønsker at vælge et team, der er en god størrelse og der vil få arbejdet gjort.
Der er en afvejning i at have flere mennesker versus færre folk.
Hvis du har flere mennesker, kan naturligvis mere arbejde gøres
fordi du har masser af mennesker, masser af kode, masser af ideer,
og det er alle store.
Men det kræver også en masse mere ledelse og en masse mere kommunikation.
Med andre ord, hvis du har 4 personer, der arbejder på det samme projekt
og de er alle redigerer den samme kode, mere eller mindre de alle slags behov for at vide
hvad der foregår, så det kræver, at du -
hvis du tilføjer nogle nye funktion, du slags nødt til at fortælle folk - jeg tilføje dette,
Jeg skifter det på denne måde - især hvis du kommer ind i virkelig dybt stuff
ligesom modeller og controllere, der er faktisk kommer til at påvirke, hvordan stedet fungerer.
Hele holdet skal være klar over det,
så du skal sørge for du ikke at vælge for stor et hold, der kommer til at være hård
at gøre denne kommunikation.
Du har heller ikke lyst til at vælge en lille nok hold, som du ikke kommer til at
være i stand til at kommunikere, fordi det er bare dig.
>> En anden ting at overveje, er balancen i hvor folks kompetencer er.
Det er fantastisk, hvis du er alle rigtig gode programmører.
Men hvis du er alle back-end mennesker, så dit websted ikke kommer til at se meget godt
fordi du har denne store database, og det gør superhurtige søgeforespørgsler -
der er stor - men når du går til det, det er ligesom et 1990 site med rød og blå
overalt, og det er ikke godt.
Bemærk, at Ben og jeg arbejder som et team er meget rart, fordi jeg er en slags mere
i den forreste ende, vi begge interagerer i midten-slutningen, og Ben er virkelig godt med back-end stuff,
så der fungerer rigtig godt, fordi vi kan designe et websted og dybest set hullerne
i det websted, der skal udfyldes, kan besættes af enten den ene af os, eller måske begge dele.
Du ønsker at sikre, at der ikke er huller i dit team.
Det er okay, hvis der er en smule overlap.
Med andre ord, hvis du har 2 personer, der er både gode med bagenden,
der kan være god som godt, fordi de kan hjælpe hinanden med problemer
at de har.
Det kan være et problem, hvis du kun har 1 person, der er ansvarlig for en bestemt ting
og de løber ind i et problem, så du ønsker at have en lille smule af overlapning
men du vigtigst ønsker at sikre, at alle de mulige huller er fyldt.
>> Den sidste ting - og det burde være indlysende, men det er ofte ikke.
Du virkelig ønsker at have det sjovt.
Pointen med denne afsluttende projekt i CS50 og ofte det punkt af web udvikling generelt
er ikke bare at gøre et job, fordi det skal gøre.
Du virkelig ønsker at have det sjovt, og du ønsker at gøre noget
der er at motivere dig til at arbejde på det.
Hvis uanset hvad du gør, er en smerte at sidde ned og arbejde på,
så er du ikke at vælge det rigtige projekt.
Du ønsker at vælge noget, du finder interessant,
du virkelig ønsker at se resultatet, er du ophidset, når du får en ny idé om
noget, du kunne gøre - så der er alle former for projekter, der som jeg er sikker
du kan finde - alle har noget, der virkelig ville intriger dem
hvis de laver et web-baseret projekt.
Jeg vil sige det igen lige nu.
Hvis dit projekt virker som en smerte, og du ikke ønsker at arbejde på det,
vælge et andet projekt. Vælg noget, der virkelig inspirerer dig.
>> Ben nævnt dette begreb iteration lidt, og jeg ønsker at gå over det en smule.
Det er virkelig vigtigt at arbejde i ryk hvor du får noget funktionelt.
Det kan være fantastisk, hvis du har denne plan for en hjemmeside, der kommer til at gøre A, B og C,
og i sidste ende vil det komme dertil.
Men du sidder fast i denne fase, hvor du arbejder på det og arbejder på det,
men intet er ved at blive gjort. Du behøver ikke have noget at se og et håndgribeligt, funktionel ting.
Hvad du virkelig ønsker at gøre så meget som det ser ud sådan en smerte undertiden
arbejde på noget, og derefter slags cap det, så det er i det mindste på et stabilt, løb
version, selvom det ikke har alle de funktioner, du ønsker.
Og måske er der nogle funktioner, som du virkelig ønsker at tilføje, men du kan bare ikke
fordi du ønsker at få denne hjemmeside til en funktionel punkt.
Og så du ønsker at slags have hele udviklingsprocessen ligne det.
Du ønsker at starte et sted funktionelle - eller i det væsentlige starte med ingenting -
men du ønsker at få et sted meget grundlæggende og funktionelle.
Og så igen, lave en slags hoppe og få et sted funktionelle igen.
Du vil langsomt bygge op, og det kan gå lidt langsommere end det ellers ville,
men i det lange løb, hvis du konstant sidder fast i denne mellemvej fase, hvor du
faktisk ikke har noget arbejde, kan det være en rigtig stor frustration
at arbejde på dit projekt, fordi du altid er så tæt på at få det til at virke,
og det er faktisk aldrig arbejdet.
Du ønsker at arbejde i disse funktionelle ryk,
og du også ønsker at gøre nogle overvejelser efter hver enkelt.
Med andre ord, når du er på et punkt, hvor sitet er nu arbejder -
det ikke har alt, hvad du kan lide, men det gør nogle ting -
du ønsker at tænke, okay, er dette site gennemførelsen af ​​det mål, jeg satte mig for at gøre?
Med andre ord, hvis webstedet kommer til at gøre X, er hvad jeg har at arbejde i retning af X?
Er alle de funktionaliteter, som jeg ønskede der?
Og i øvrigt er det tjener det overordnede formål, som jeg ønsker?
Hvis du opdager, at din hjemmeside er begyndt at dreje i en anden retning
eller måske ting bare slags ikke arbejder ud, kan det være tid til at skifte gear en lille smule.
Med andre ord, er det værd at overveje - det er værd at smide idéer hvis det er nødvendigt
og overvejer jeg virkelig arbejder hen imod det, jeg ønsker at være.
>> Jeg tror, ​​det er mit næste punkt. Må ikke være bange for at opgive idéer.
Bare fordi du har brugt masser af timer arbejder på et træk
og endelig fik det til at virke, men det er virkelig ikke går så godt -
ligesom det ikke er det nyttigt eller brugere har problemer med at bruge det - den slags ting -
ikke være bange for at smide det væk.
Det stinker, at du har brugt en masse tid på at arbejde på det,
men i sidste ende du ikke ønsker et websted, der er slags sat sammen af ​​disse stykker,
slags arbejde, men er ikke så godt tjent.
Også, ikke være bange for at tage nye ideer.
Hvis nogen kommer og siger, hey, at webstedet ser rigtig cool, men
ville det ikke engang være dejligt, hvis det også gjorde det?
Bare fordi det er noget, du ikke havde til hensigt, og noget, der ikke er i din
specs, noget, som du ikke har sat sig for at gøre,
vær ikke bange for at tage det på og derefter arbejde med det.
Fordi ofte de ideer, som du kører med i løbet af udvikling
ender med at blive de rigtig seje funktioner på hjemmesiden.
>> Jeg har sagt det før. Jeg vil sige det igen.
Testere er super, super nyttigt.
Prøv at få folk, der aldrig har set stedet før at logge på og se, hvad der foregår
fordi de ikke kun kan teste nytten af ​​stedet og brugerens oplevelse,
men de kan også teste funktionaliteten på måder, du ikke kan.
Hvis du laver nogle træk, der gør en bestemt ting
og du ved, det kommer til at gøre det samme ting rigtigt hver eneste gang, det er fantastisk.
Men det kan ofte være svært at redegøre for hjørne tilfælde, hvor en bruger kan
skriver noget, som du ikke forventer - netop fordi du har defineret
funktionerne selv.
Så at nogen kommer på, hvem der har ingen idé om, hvordan du bruger sitet
og bare bryde det, uanset på hvilken måde, de kan gøre, er virkelig nyttig, fordi du
få en idé fra en helt anden perspektiv af, hvad på dit websted fungerer
og hvad der skal repareres.
>> Sidste, jeg vil tale om nogle generelle god praksis,
og du har set en masse af disse i CS50, men de har også virkelig, virkelig gælder i et projekt indstilling.
Den ene er kommentarer. Kommentere altid din kode, især hvis du arbejder på et stort hold.
Det kan være så irriterende at bare have en kæmpe blok af kode, som nogen har skrevet
og måske det virker, er det måske ikke, men du aner ikke, hvad det gør,
så du har ingen idé om det er nyttigt eller ej, eller om det skal være der eller ej,
og hvis du arbejder på noget andet, er det endda muligt, at du arbejder på
de samme ting, så bare være meget, meget omhyggelig med at være hensynsfuld af dine kammerater
og skrive kode, der er veldokumenteret.
Du behøver ikke at gå så langt som til at gøre det hele, hvor gerne, hvis du tilvækst
en tæller har en kommentar, der siger, jeg tilføjer 1 til denne tæller.
Det behøver ikke at være så detaljeret, men for enhver funktion, du nogensinde du skriver
du bør have en vis dokumentation for, hvad der fungerer præcist gør,
hvad dens input er, og hvad det skal returnere.
På den måde kan du bruge andre folks dele af webstedet
og du kan arbejde hen imod at bygge noget stort.
>> En anden vigtig ting er, du ønsker at gøre regelmæssig oprensninger.
Kode bliver rodet. Må ikke føle sig dårligt, hvis din kode er bare helt uoverskueligt, og en kæmpe rod.
Det sker i webudvikling altid.
Du tilføjer nye funktioner, fjerne gamle. Ting bliver der, som ikke bør være.
Det er fint, men du vil være sikker på at beskæftige sig med det regelmæssigt.
Du ønsker ikke at lade det bygge op til det punkt, hvor du bare ikke kan finde noget
i din kode, og du har ingen idé om, hvad noget gør.
Det er tilfældet med HTML.
Nogle gange vil du ende op med objekter, der ikke indeholder noget,
og du ønsker at slippe af med dem.
I CSS, kan du referere til elementer, der ikke er der længere,
så du ønsker at slippe af med denne kode.
I JavaScript, måske du har fjernet noget fra HTML.
Så du vil være sikker på at du altid rydde op, hvilket gør tingene temmelig
så meget som du kan på en regelmæssig basis.
>> En anden rigtig nyttig ting, som jeg ikke tror er skitseret meget i CS50
men det er værd at komme ind, er versionskontrol.
Ideen med versionsstyring er, når du er dybest set at holde styr på alle de fremskridt,
du har lavet til dit websted og hvis du på noget tidspunkt du indser, åh, det var i orden
et stykke tid siden, men det fungerer ikke mere, kan du gå tilbage til tidligere versioner
og se, hvad der har ændret sig siden da, og den slags ting.
Den primære måde at gøre det er med Git og Git er hele denne form for system, der
Jeg tror Tommy MacWilliam gav et seminar om sidste år.
Hvis du går ind i CS50 seminarer for 2011, kan du se hans seminar om det.
Idéen om Git er dybest set, at med jævne mellemrum du laver disse forpligtelser
der er måder at sige stedet er i en temmelig stabile version lige nu, så
Jeg pakker den op og sende det væk til en server, og så kan du gå til denne server
og se på alle tidligere versioner af din kode og se, hvordan det skred
og alle den slags gode ting.
Så det er dybest set det.
Så vidt webudvikling, vi er glade for at holde sig omkring og besvare eventuelle
spørgsmål så langt som vores præsentation.
Det er det. Thanks. >> [Ben] Thanks.
[Bifald]
>> [Billy] Personale, nogen der har nogen spørgsmål om ting, som vi har dækket
eller ting, som vi ikke har dækket, at de håbede vi ville dække?
Vi ville være glade for at besvare dem. Nogen?
[Publikum medlem] Hvad er fordele og ulemper ved at bruge Ruby eller ved hjælp af Python?
[Ben] Spørgsmålet var, hvad er fordele og ulemper ved at bruge Ruby eller Python
i stedet for ligesom PHP.
De professionelle er, at Ruby og Python er meget bedre sprog end PHP.
I hvert fald i min udtalelse, og jeg tror i en masse andre folks meninger så godt.
De var designet mere til at gøre komplekse ting,
og mindre for tæv sammen websider virkelig hurtigt med
en lille smule af dynamisk indhold.
Ulemperne er, at der er en lille smule af - der er mere af en indlæringskurve
at få dem sat op.
Det er, ligesom i PHP, kan du bare have en HTML-fil, og du skriver mindre end,
spørgsmålstegn, og så skal du skrive noget kode, og så skal du skrive spørgsmålstegn,
større end, og så er du færdig.
På andre sprog som Ruby eller Python,
du nødt til at gå igennem en lidt mere arbejde for at få den oprindelige hjemmeside kørende.
Der er også - i hvert fald det plejede at være tilfældet - at der er mere dokumentation
tilgængelig for PHP, bare fordi der er flere mennesker, der bruger det.
Jeg tror, ​​der er ikke så meget af et problem længere.
Der er sikkert meget god dokumentation for ting som Ruby on Rails
eller Django til Python er tilsvarende.
PHP er den ene, som alle har været brugt i årevis, og du ved, hvordan det fungerer.
Ruby og Python er en lille smule mindre modne.
>> [Publikum medlem] Hvis du skulle vælge mellem en af ​​dem til at lære eller samle op,
hvilket ville du foretrække?
Helt ærligt, jeg tror det afhænger af personen.
Undskyld. Spørgsmålet var, som ville du vælge for nogen til at lære?
Jeg finder Python den pæneste personligt.
Der er en masse mennesker, der - jeg gjorde mit første web dev projekt i Python og Django.
Der er en masse mennesker, der kan lide Ruby on Rails også.
Sandsynligvis flere mennesker, der kender Ruby on Rails.
Helt ærligt, ville jeg bare gå med uanset de mennesker omkring dig ved,
så du har folk til at stille spørgsmål.
>> Spørgsmålet var - på fælles servere er det lidt svært at arbejde på Python?
Det afhænger af din hosting.
Der er en række af værter, der vil poste Python ting.
WebFaction gør det, right?
WebFaction er en, Billy og jeg har brugt til nogle projekter.
De er virkelig stor. De støtter de fleste sprog.
Men det er sandt, at PHP er langt mere bred opbakning.
Så hvis du sidder fast på en web-vært, som kun gør PHP, der er en god grund til at bruge PHP.
>> [Publikum medlem] Jeg har lige fået i at lære at forespørge nogle databaser,
og jeg kender min SQL er over det hele, men jeg fik for nylig udsat for -
og du påpegede det. Du ser JSON og udvides databaser.
My SQL er stadig over det hele. Hvordan ser du, at det sker?
Er der vil være en stigende tendens til mere udvides (uhørligt)?
Spørgsmålet var - tror jeg der kommer til at være en tendens i retning af ikke-SQL databaser.
For eksempel, som MongoDB. Jeg tror, ​​det er absolut sandt.
Mit råd var hovedsagelig mySQL-relateret her kun fordi mySQL er
industristandard.
Personligt foretrækker jeg langt databaser, der ikke har schemos som MongoDB
hvor du ikke har problemet med, åh, jeg nødt til at tilføje en anden kolonne.
Ve mig, ligesom hvad gør jeg?
Det er meget svært at gøre det på mySQL, men når du har noget som Mongo
det er meget pænere.
Den anden gode ved Mongo er, at dine oplysninger er faktisk JavaScript objekter.
Der er ingen form for konvertering trin, hvor du nødt til at tage disse database rækker
og gøre dem til en JavaScript objekt og derefter sende dem over wiren.
Jeg tror, ​​den slags, der vil være meget, meget nyttigt for hurtig webudvikling i fremtiden.
>> [Billy] Noget jeg vil tilføje, som er blot en generel pointe er, at
føler ikke, at du burde have lært alle de sprog, vi har diskuteret
fra vores seminar.
Naturligvis pointen er at give dig en idé om, hvad der er derude,
og hvis du er fascineret af nogen af ​​de ting vi har nævnt kan du google dem
og læse op på dem.
Og som jeg nævnte, er der et par seminarer, der beskæftiger sig med netop disse ting.
Der er endnu flere seminarer, som jeg ikke har nævnt, der sandsynligvis komme ind
denne ting så godt.
Ideen er, at hvis du ønsker at arbejde på noget, her er de værktøjer til din rådighed.
Må ikke føle sig overvældet, hvis du ikke er helt sikker på hvad disse værktøjer gøre præcis,
men ved, at de er derude, og at du kan gøre omfattende brug af dem
af Google.
>> [Publikum medlem] Hvilken slags ting har du brug for at gøre for at sikre dit website
ser godt ud på mobile enheder?
[Billy] Mobile enheder er lidt hårdt.
Der er 2 måder, du kan gribe det an.
Den første måde er, at du rent faktisk har en mobil hjemmeside.
Med andre ord, du udfører en slags opdagelse i begyndelsen
når browseren fremsætter anmodningen til din hjemmeside, der enten siger
returnere dette synspunkt - som vil være udsigten til stationære eller bærbare browsere -
og denne anden udsigt til mobile enheder.
Det er et sted, hvor synspunkter er virkelig rart i, at du kan temmelig meget swap den
to ud og have en grænseflade, der fungerer rigtig fint på mobile enheder
og har en helt anden en, der fungerer fint på browser-enheder.
Problemet med det er det tager lang tid, fordi det betyder kodning
en helt anden grænseflade.
Den anden måde at du kan gøre det er -
en masse moderne telefoner vil vise hjemmesider og forsøge at gøre dem som en browser ville,
og de gør deres bedste.
Du kan slags prøve at bo lys på mængden af ​​jQuery JavaScript du bruger
som har tendens til at være, hvor tingene kan gå galt en lille smule.
Dette er en slags af den måde, som du skal bruge, hvis du ikke har så megen tid.
Hvis du har tid til at arbejde på en mobil interface, der er selvfølgelig din bedste mulighed.
>> Jeg tror generelt for CS50 projekter, du vil ønsker at vælge det ene eller det andet.
Med andre ord, du ønsker at gøre en mobil app eller du ønsker at lave en desktop hjemmeside.
Og den slags bestemmer, hvor du går med det.
Men hvis du ønsker at udvide det ud senere, sandsynligvis din bedste chance er
til at foretage en anden grænseflade til den anden.
Jeg har en lille smule erfaring i at udvikle WordPress-baserede sites.
Jeg vært for en personlig hjemmeside på WordPress for en stund.
Disse typer af rammer kan være rart lige så meget grundlæggende ting.
Ofte vil du bare løbe ind i en masse customizability problemer selv.
Du ønsker at have noget at se på en bestemt måde, eller være på en bestemt måde
og du kan bare ikke, fordi det er hårdt kabel i systemet,
dette er, hvordan du er nødt til at gøre ting, som kan være lidt af et problem.
Siden da har jeg slags været mere tilbøjelige til at arbejde med websteder fra jorden op.
For ting som blog databaser og den slags ting, det er virkelig ikke så svært at opbygge en ramme.
Hvis du virkelig strakt i tid, kan du jo bruge noget som WordPress
eller den slags ting til en blog.
Den slags ting, som blogs butik og gør er ikke rigtig hårdt nok at
hvis du kører ind i nogen af ​​disse slags ting, er du nok bedst bare at
foretage en in-house version.
>> Jeg tror, ​​det er om det, så tak igen for at komme.
Vi nød virkelig taler til jer, og håber, at du har lært nogle ting.
[Ben] Vi er glade for at tale - vi er nødt til at gå, men vi er glade for at tale mere uden
hvis du har et andet spørgsmål. Tak igen. [Bifald]
[CS50.TV]