[Powered by Google Translate] [Uke 9] [David J. Malan - Harvard University] [Dette er CS50. - CS50.TV] OK. Velkommen tilbake. Dette er CS50, og dette er begynnelsen av uke 9. I dag har vi spesielt fokusere på design, ikke lenger i sammenheng med C men i sammenheng med PHP og en bit av SQL og litt av JavaScript, spesielt mot slutten av både pset 7 og også det endelige prosjektet. Faktisk, hvis du er på det punktet i det endelige prosjektet hvor antakelig som for en time eller så siden du minst begynte å gi noen trodde til det endelige prosjektet, og du tenker at du har lyst til å samarbeide med en eller to klassekamerater, hvis du har problemer med å koble med sa klassekamerater, gjerne til å fylle ut skjemaet på cs50.net/partners/form. Det stiller bare deg hvem du er, hva slags prosjekt du tenker, hvor du bor bare for logistiske årsaker. Og hvis du ønsker å holde et øye med over neste uke eller så regnearket URL der, du kan da se en skrivebeskyttet versjon av Google doc der vi samle denne informasjonen. Så hvis du ønsker å jobbe med noen, for all del gjerne nå ut til folk via den mekanismen. Men flertallet av folk gjør arbeidet solo. Det er helt greit. Så føler ikke at dette på noen måte er obligatorisk. På fredag ​​var det bare meg og noen av teamet her, tom teater for det meste. Det var 3 turister sitter oppe, så det var litt vanskelig. Hva vi snakket om var databaser og vi snakket om pset 7 litt. Og hvis du ikke skje for å fange det på video ennå, er det helt greit. Jeg skal prøve å definere noen begreper som vi ellers ville ta for gitt basert på fredagens forelesning. 

Men i dag skal vi prøve å få deg til det punktet av ikke bare å være i stand til å gjøre noe sånt pset 7 men virkelig forstå hva som skjer under panseret, særlig noen av de abstraksjoner som vi satt på plass i functions.php fil for å gjøre livet litt enklere, men slik at du til slutt forstår slik at når trening hjul komme seg i et par uker kan du likevel overleve i den virkelige verden og gjøre slike ting uten CS50 rammeverk under deg. Denne $ _SESSION, for de av dere som er kjent eller som allerede fanget video på fredag, hva SESSION la oss gjøre i en PHP-basert web-applikasjon? Dette er en superglobal variabel, som betyr at det er lik i ånden til GET og POST og noen få andre, men hva er dette tingen nyttig for? 

Hva er SESSION til? Ja. [Student] Logger inn Beklager? [Student] Logger inn Logger inn Indeed. I pset 7 bruker vi denne SESSION superglobal å lette logge inn Og hva er fint om dette superglobal er at det er en assosiativ array. En assosiativ array, tilbakekalling, er bare en matrise, men hvis indeksene ikke lenger å være tall som 012. De kan være tall eller de kan være selv strenger. Og så hvis du har dykket inn pset 7 ennå, kan du huske at vi lagrer en nøkkel kalt ID innsiden av denne assosiativ array hvis verdi er noe som 123 - uansett påloggede brukeren ID-er. Motivasjonen for dette er at selv etter at brukeren har besøkt localhost eller min hjemmeside mer generelt og de har logget inn, selv om de ikke klikker på en lenke eller gå tilbake til min hjemmeside i 5 minutter eller enda en time eller en dag, men de forlater sitt nettleservindu åpent, via denne superglobal kan jeg huske at de er logget inn 

Med andre ord, gjør det meg å lagre litt langsiktig hva jeg vil om en bruker. Og du kan tenke på det egentlig som inkarnasjonen av en handlevogn. Steder som Amazon åpenbart lar deg sette ting i en handlekurv, men HTTP, protokollen som driver nettet, er statsløs i den forstand at når du besøker et nettsted, for det meste du ikke har noen konstant nettverkstilkobling mellom nettleseren og serveren. Så snart du har lastet ned HTML og JPEG og GIF og alt det der, forbindelsen blir borte og du trenger bare en kopi av HTML og whatnot fra serveren. Men hvis serveren ønsker å huske noe om deg, byrden er på serveren til å faktisk spille denne informasjonen. Og så du programmerer som har kontroll over serveren kan sette de fleste noe du ønsker innsiden av dette superglobal assosiativ array og det vil være det neste gang brukeren kommer tilbake, enten det er minutter eller til og med dager senere, med mindre de stenge sin nettleservinduet, noe som medførte at SESSION forsvinner. Så det er flyktig lagring, er det ikke vedvarende, og det er ment å gå bort så snart brukeren lukker nettleseren - ikke bare den fanen, ofte hele nettleseren, dermed effektivt logger brukeren ut. Så hvordan er dette tingen faktisk blir gjennomført? La oss ta en rask titt på et enkelt eksempel vi så på fredag. For de som ikke kjenner, var det så enkelt som dette. Dette er en nettside der det eneste mål i livet er å fortelle meg hvor mange ganger jeg har besøkt denne siden. Dette er første gang her på mandag at jeg besøkte den, så det sier 0 ganger. 

Men hvis jeg begynner omlasting denne siden, sier det en gang, 2, 3, 4, 5, og dette vil til slutt bare holde på å telle opp, opp, opp, opp, opp for hver gang jeg faktisk klikker Last på den. Så hvordan er dette arbeidet? La meg gå inn i denne filen som heter counter.php. Den øverste delen av det er alle blå kommentarer, men interessante er her. På linje 13 kaller vi denne funksjonen session_start, og det er bokstavelig talt alt du trenger å gjøre hvis du ønsker å ha tilgang til denne spesielle superglobal kalt $ _SESSION. Det gjør det hele mulig, og vi vil se i et øyeblikk hvor det er alt mulig. I linje 16 varsel hva jeg gjør. Hvis nøkkelen, kalt teller - med andre ord, indeksverdien - "counter" Det finnes inne i denne array kalt SESSION, så hva gjør jeg med det i linjen under? Hva er linje 18 gjør? 

[Uhørlig student respons] Hva er det? [Student] Lagre verdien. Bra. Det er lagring av verdien som er i SESSION akkurat nå i en ny lokal midlertidig variabel, $ Teller i alle små bokstaver. Legg merke til at PHP er allerede å være litt lat her. Legg merke til at vi ikke har noen omtale av int eller flyte eller hyssing eller noe sånt fordi PHP er svakt skrevet, hvor du ikke trenger å spesifisere hvilken type en variabel, og i dette tilfellet her ikke jeg har selv erklært det ennå. Jeg erklærer det innsiden av disse klammeparentes og i motsetning til C, dette er faktisk greit. Uansett hvor dypt nestet en variabel erklæring er i PHP - innsiden av krøllete spenne, innsiden av krøllete seler og lignende - det vil i det øyeblikk i tid finnes for resten av programmet, for bedre eller verre. Så det blir umiddelbart global så snart du definerer det som vi gjør her. 

Ellers, hvis jeg ikke finner at det er noe i SESSION superglobal, Jeg tydeligvis initialisering denne variabelen teller til 0, dermed bare forutsatt at brukeren har aldri vært her før. Og så dette selvfølgelig er inkrementering telleren hvordan? Jeg oppdaterer verdien som er inne i dette assosiativ array ved å sette den lik uansett teller i dag er + 1. Hvis jeg ruller nedover hit til HTML på siden, det er faktisk ganske enkelt. Alt jeg har i kroppen av denne siden er: "Du har besøkt dette området så-og-så ganger." Og dette er en PHP konstruksjon. Hvis du gjør <? = Tilsvarer dette effektivt til hvilken funksjon? Det er virkelig tilsvarer noe sånt som printf, som vi har sett mange ganger i C, men som du kanskje vet allerede fra spec i pset 7, Utskriften er også en funksjon som bare skriver noe ut, betyr det ikke faktisk bruker formatkoder, og du kan faktisk si ekko også. De er alle aldri så litt annerledes selv om nettoeffekten er slutt den samme. Så denne bruken av likhetstegnet er bare en slags en elegant måte å gjøre det mer konsist enn du ellers ville være i stand til. Så det er alt dette nettstedet gjør. Det skrives ut verdien av telleren. Hvordan er dette alt faktisk skjer? Du husker kanskje en uke eller så siden vi begynte å se under panseret på hvordan en nettside fungerer ved hjelp av denne Inspector kategorien. 

Chrome har dette både i Mac-versjonen, Windows-versjonen, og selv Linux-versjonen, og Firefox og IE har lignende mekanismer der du har dette innebygd debugger innsiden av nettleseren. La oss ta en titt på følgende. Vi har fått en hel haug med faner her, og husker at venstre en er Elements, og uansett hvor godawful HTML og JavaScript er på en side, husker at med Elements fanen kan du faktisk navigere HTML hierarkisk og hyggelig og pent. Så hvis du prøver å lære fra en nettside som Google eller Facebook eller egentlig hvilken som helst nettside, skjønner at du er sannsynligvis bedre ser på kildekoden denne måten som motsetning til å se den rå kilde, som kan være et rot, som vi har sett spesielt på Googles nettsted. Så hvis jeg i stedet klikke på kategorien Nettverk her, la oss se hva som skjer når jeg besøker denne siden. Først la meg tømme hurtigbufferen. Jeg kommer til å gå inn i innstillinger i Chrome og deretter gå til Historie og deretter Fjern alle nettleserdata. Du kan bli vant til å gjøre dette for andre formål, [latter] men når det gjelder å utvikle nettsteder, er det faktisk nyttig - hvis du ler du vet. [Latter] Det er faktisk veldig nyttig når utvikle nettsteder fordi virkeligheten er ting som cookies og ting som hurtigbufrede HTML-filer, bufrede JavaScript-filer kan faktisk bli en stor hodepine, fordi hvis uansett grunn leseren bestemmer seg for å bufre noen fil og ennå du har gjort endringer i denne filen på serveren men leseren ikke har virkelig innsett at filen er endret og derfor ikke faktisk re-laste den ned selv når du klikker Oppdater-knappen, en av de mest surefire måter å bare sørge for at feilen ikke er med koden din, det er med oppførselen til nettleseren, er å gå her i nettleseren din og bare slette hele historien slik at det er ingen forvirring. 

Og hvis du virkelig ønsker å være paranoid, avslutter nettleseren, starte den, og deretter sørge for at alt fungerer som forventet. Så kort sagt, er clearing cache god når du gjør utvikling. Så her har vi kategorien Nettverk. Jeg hadde tidligere besøkt området 9 ganger, men la meg gå videre nå og klikk Reload. Og jeg er tilbake ned til 0. La oss faktisk se hvordan det er at dette SESSION superglobal blir gjennomført. Jeg kommer til å klikke på en HTTP-forespørsel som ble gjort, og denne debugging vindu lar meg se innsiden av det. Her ser jeg bare svar fra serveren, som ikke er interessant. Jeg har sett dette i en rekke måter. Men hva er teknisk interessant er overskriftene. Hvis jeg ruller nedover her og fokusere på forespørselstopptekster og klikk vis kilde, hva jeg kommer til å se er bokstavelig talt HTTP-forespørsel som bare gikk fra nettleseren min til serveren, GET blir det operative ordet og deretter / counter.php blir filnavnet, HTTP/1.1 bare å være den versjonen av HTTP som min nettleser bruker. Denne linjen her er en liten påminnelse fra nettleseren til serveren hva navnet på serveren er at den ønsker å snakke med. Og deretter resten av dette er noen ganger interessant, men ikke relevant akkurat nå. 

Dette er bare en slags nysgjerrighet. Kryptisk om denne strengen er, helst nettleseren besøker en nettside det er å informere serveren hvilken nettleser du bruker og hvilket operativsystem du bruker og hvilken versjon av dette. Så hvis du noen gang har lurt på hvordan nettsteder som CNN og whatnot vet hva de prosenter er av Mac-brukere på nettet, PC-brukere, IE-brukere, Chrome-brukere og lignende, er det fordi alle våre lesere forteller hver eneste nettstedet ut det hva vi er. Det betyr ikke nødvendigvis inneholde personlig identifiserbar informasjon, men det gjør fortelle serveren hva din IP-adresse er og hvilken nettleser og operativsystem du bruker. Så det er der denne informasjonen er. Men hva er mer interessant nå når det kommer til disse øktene er svaroverskrift. La meg Klikk Vis kilde ved respons. Hva er interessant her er et par ting. 1, fikk vi tilbake en status på 200.. Vi aldri se denne statusen kode fordi det betyr at alt er bra. Det betyr bokstavelig talt greit i motsetning til noe annet. Hva er et tall vi noen ganger ser det er ille? [Student] 404. 404, finner ikke filen, kan 403 du snubler over alt, som er forbudt, noe som betyr at du glemte å chmod noe, mest sannsynlig. Og det er en haug med andre. 

Her nede, er dette en litt gal. Jeg bare skrev denne filen for noen minutter siden ved å lime det inn i gedit. Hvorfor gjorde denne siden utløper i 1981 før det virkelig var en web? Hva skjer der? 

[Uhørlig student respons] tidsangivelsen. Men hvorfor? Det er noe vilkårlig, men det er faktisk nyttig. Hva dette sier til nettleseren min er dette PHP-filen du nettopp har bedt om er allerede utløpt. Faktisk utløpt det 30 år siden. Men hva betyr det egentlig? Det betyr bare at neste gang brukeren besøker denne siden, enten ved omlasting eller skrive inn URL i adresselinjen, sørg for at du gå og hente en ny kopi av den. Dette er liksom et eksempel på cache busting, en dum ord som bare betyr å prøve å motvirke nettlesere fra faktisk caching HTML som er blitt sendt fra en server slik at du ikke tilfeldigvis treffer reload og deretter se den samme versjonen av filen. Du faktisk vil at serveren skal sende en ny kopi. Så det faktum at det er 1981 betyr bare at det er det apparatet er å velge som en vilkårlig dato i fortiden. Men den virkelige saftig linjen er nå denne. Selv før 50 er du sannsynligvis litt kjent med informasjonskapsler. Per akkurat nå, spesielt blant de mindre komfortable eller i mellom, Hva er en informasjonskapsel i din forståelse akkurat nå selv om vi er i ferd med å gjøre din forståelse mer teknisk? Hva er en cookie? Ja. [Student] Informasjon om brukeren, som om de har skrevet brukernavn eller noe. 

Bra. Det er informasjon om brukeren, enten de har skrevet i deres brukernavn allerede. Cookies er en måte der serverne kan huske noe om en bruker. Og hva en cookie egentlig er er en tekstfil eller noen sekvens av bytes som er plantet av serveren inne i nettleseren, og innsiden av filen eller blant de byte er en slags identifikator. Kanskje det er bokstavelig talt ditt brukernavn, men oftere er det noe mer kryptisk utseende som dette tingen her - bo8dal3ct og så videre - dette virkelig stor alfanumerisk streng det er egentlig bare ment å være en unik identifikator for deg. Eller du kan tenke på det som en slags virtuell hånd-stempel. Hvis du går til noen klubb eller en fornøyelsespark, å huske at du faktisk har betalt og gått inn, satte de en liten rød klistremerke på hånden av noe slag, og som minner folk på telleren som du allerede har betalt og du kan komme og gå som du vil. Cookies er litt lik i ånden til det. Første gang jeg besøkte dette nettstedet, som jeg bare gjorde etter å fjerne min cache, webserveren, apparatet i dette tilfellet, sette et stempel på hånden min hvis navn er PHPSESSID, økt-ID, hvis verdi er dette veldig lang alfanumerisk streng. 

Så det er nå liksom emblazoned på hånden min slik at neste gang jeg traff laste eller manuelt besøke denne nettadressen i nettleseren, nettleseren min ved definisjon av HTTP kommer til å presentere hånden stempel igjen og igjen og igjen. Så selv om serveren ikke nødvendigvis vet hvem jeg er, de minst vet at jeg er den samme brukeren eller i det minste, mer spesifikt, samme nettleser. Og så dette er til syvende og sist hvordan SESSION superglobal er implementert. Serveren har ingen anelse om hvem du er når du besøker en nettside for andre eller tredje gang med mindre du leverer hånd-stempel. Og så snart du presenterer den hånden stempel, webserveren går i hovedsak inn i en liten database av sine egne og sjekker, ok, jeg har nettopp sett hånd-stempel av bruker bo8dal3ct og så videre. La meg se hva slags informasjon programmereren har lagret innsiden av superglobal om denne brukeren, og så la meg forsikre deg om at dataene er igjen inne i SESSION superglobal slik at programmereren kan re-tilgang til data selv om det ble satt noen minutter eller timer siden. Så med andre ord, cookies, som fikk en dårlig rap for noen tid på grunn av usikkerhet i nettlesere, og de kan virkelig krenke vårt personvern og alt dette, de faktisk har stor nytte fordi uten dem du ville stadig være å logge inn på hver Facebook-side du besøker eller hver Gmail e-posten du lese hvis leseren ikke har noen måte å huske at du allerede har godkjent. 

Så på denne måten cookies blir sendt frem og tilbake over ledningen. En annen kuriositet om cookies, spesielt her, er at dette er helt i klartekst. Det er ingen kryptering skjer her overhodet, og faktisk jeg bruker HTTP for øyeblikket. En av våre favoritter øyeblikk i CS50, som nå er 2 år siden, var rundt den tiden et verktøy kalt Firesheep kom ut. Dette var en gratis stykke programvare som ble gjort av en sikkerhetsforsker som en wake-up call for samfunnet å si hvor atrociously implementert visse autentiseringsmekanismer på nettet var. Så for noen tid, var Facebook nesten helt over HTTP, ingen HTTPS. Og selv om du ikke har noen anelse om hvordan krypto fungerer, er S sikker så det betyr at det er minst noen kryptering involvert. Facebook gjorde brukt til å kryptere brukernavn og passord, men så snart du har sett på din kakker eller meldinger eller din nyhetsfeed, alle som ble ukryptert. Så var Gmail til bare et år eller to siden. Hver gang du logget inn, ja, de brukte sikker kryptering men etterpå gjorde de ikke. Og hvorfor kan det være? Hvorfor ikke bare bruke kryptografi hele tiden i bruk tilfeller som dette? Hva er det? Jeg tror jeg hørte noe. [Student] Speed. Hastighet, ikke sant? Det finnes måter rundt dette. Men hvis du bare slags tenker på det logisk, hvis du krypterer noe, du trenger å gjøre minst litt mer arbeid. I pset 2 når du implementert keiseren eller Vigenere eller Crack, bare skrive ut en streng er relativt enkelt. Kryptering og deretter skrive en streng minimal krever litt mer arbeid. 

 For super populære nettsteder som Google og Facebook, Hvis du trenger å gjøre mer arbeid for hver bruker for hver enkelt nettside de besøker, som tar bare mer CPU tid. Og hvis du trenger mer CPU tid, må du kanskje flere servere, som betyr at du kanskje trenger mer penger. Og det i mange år dette bare var egentlig ikke beste praksis. Folk ville bruke SSL-kryptering bare når de måtte. Men det viste seg, og som denne karen med Firesheep gjort super klar, når dere som er for tiden på Facebook akkurat nå - Ut av nysgjerrighet, la oss se om du vil fess opp. Hvis du er på Facebook akkurat nå i noen kategori, selv om det ikke er foregrounded, er nettadressen HTTP eller HTTPS? [Flere studenter] S. S? [Latter] Okay. Noen HTTP? Bare 1? Okay. Så alle av oss kan hacke den fyren Facebook-konto akkurat nå. For det meste er dette blitt slått på som standard, i hvert fall i enkelte nettsteder. Og lang historie kort, hvis din web-trafikk er ikke kryptert, ikke bare går HTML frem og tilbake over de wifis ukrypterte, så går ting som cookies og tilbake gjennom luften uten noen form for kryptering. Så hvis du har bare en bit av programmering kunnskapsrike eller en bit av googlingen ferdigheter å finne gratis programvare som gjør dette, er å sitte alt du trenger å gjøre i Starbucks eller sitte på en flyplass der det er generelt ukryptert WiFi og bare se etter nøkkelord som Set-Cookie: eller PHPSESSID fordi hvis du har teknisk kyndige å bare se på WiFi for alle de biter som flyt gjennom luften for dette mønster, du kan si at fyren er PHPSESSID skjer for å være bo8dal og så videre. Og så igjen hvis du er tilstrekkelig teknisk kunnskapsrike eller har det riktige verktøyet, du kan da bare rekonfigurere sin egen nettleser for å begynne å presentere den hånden stempel å Facebook.com, og Facebook er bare kommer til å anta at du er den fyren fordi alt de vet er ikke hvem du er, men at du har denne unik identifikator. Så hvis du stjele den unik identifikator og presentere den til webserveren som din egen, de er bare kommer til å vise deg at personen nyhetsfeed eller vedkommendes meldinger eller kakker. 

Og jeg vil Google nå hvordan du aktiverer HTTPS for Facebook kanskje. Men det er egentlig så enkelt som det. Og så Facebook og Google og lignende har fått virkelig gode på dette, men holde et øye ut alle mer for noen nettsteder du besøker som ikke bruker HTTP og har noen form for sensitiv informasjon på dem, enten det er økonomisk eller personlig eller lignende. Hvis de ikke bruker dette, kan ganske muligens cookies som dette være svært lett stjålet og deretter forfalsket, og det er akkurat hva Firesheep gjorde. Du trengte ikke å være en programmerer. Alt du måtte gjøre var har en Internett-forbindelse, laste ned denne gratis verktøy, og hva det ville gjøre er du logge inn og så det ville vise deg de Facebook navn av alle i Sanders, i denne spesielle demonstrasjonen, rundt deg og alt du måtte gjøre var klikke på navnet sitt og programvaren automatisert prosess av sniffing som cookie, presentere det for Facebook som din egen, og voila, du logget inn Så dette er en av de "ikke gjør dette" offisielt. Hvis du har ditt eget hjemmenettverk og du ønsker å tinker, for all del, men innser dette gjør krysse linjen på et universitet miljø. 

Men målet her er virkelig å understreke ikke hvordan du gjør dette men hvordan å forsvare seg mot slike ting. Og trivielle løsningen her, selv om det i seg selv er feil, er å virkelig redusere bruk av nettsteder som ikke bruker HTTPS hele tiden. Så nettsteder som Facebook og Google har fått stadig avkrysningsbokser hvor du kan velge denne typen ting, og bankene har hatt dette i mange år for liknende grunner. Så bare en liten bit av en frykt faktor hvis vi kan. Men det er det i et nøtteskall. Det er hvordan en server husker hvem du er. Og så snart de kan huske hvem du er, kan de huske noe om deg at programmereren har lagret inne i denne spesielle superglobal kalt $ _SESSION. Og for pset 7 bruker vi det trivially bare å huske en int, nemlig den unike ID til brukeren som har logget inn, slik at vi vet at de har vært der før. Eventuelle spørsmål da på økter eller informasjonskapsler eller lignende? Firesheep fungerer ikke så godt lenger, og du må sette maskinen i en spesiell promiskuøse modus så du faktisk lytter etter trafikk foruten dere. Så hvis du laster ned Firesheep, skjønner at det ikke fullt så enkelt som det en gang var å demonstrere. OK. Og ikke gjør det i Sanders. Gjøre det hjemme. Databaser. En av de tingene vi gjorde i pset 7 meget bevisst ble vi gi deg et eksemplar database tabell for brukere som har noen bruker-IDer, noen brukernavn, og noen krypterte passord deri. Og som du ser, hvis du ikke allerede har gjort, er du nødt til å endre tabellen litt. Du kommer til å måtte legge til noen cache til hver av brukerne i denne tabellen, og du er nødt til å legge til en annen historie bord, en porteføljer bord, eller kanskje kalle det noe annet. Men i form av å tenke på hvordan du gjør dette, la oss åpne opp dette verktøyet som vi brukte på fredag, men hvis uvant, kommer maskinen med et verktøy kalt phpMyAdmin som tilfeldigvis skrevet i PHP, men dens formål i livet, etter at jeg logger inn her som jharvard med skarlagen, er å gi meg en brukervennlig måte å vise og endre min database. 

Databasen som jeg kjører på maskinen kalles MySQL. Dette er veldig populært, og det er en gratis åpen kildekode-databasen som er fantastisk enkelt å bruke, spesielt med grensesnittene som dette. Hva dette verktøyet tillater meg å gjøre, for eksempel, er rote rundt bordene. La meg gå videre og gjøre dette. På fredag ​​har vi opprettet en tabell som kalles elever som var super enkelt. Det hadde 3 kolonner - ID, navn og e-post - og jeg manuelt satt et par rader som David og Mike i dette eksempelet. La oss ta dette litt videre, og la oss anta at vi ønsker å huske mer enn bare navn og e-post om en bruker. La meg Klikk Struktur opp her på toppen. Og igjen, går det pset deg gjennom de nødvendige skritt her, så ikke bekymre deg hvis noe av dette er litt rask. Så jeg kommer til å klikke på her. Jeg kommer til å legge til noen flere kolonner etter e-post fordi jeg ønsker å legge til noe som hus. Jeg glemte å ta opp en student hus. La meg klikker Start, og nå har vi denne formen som dessverre er litt bredt fra venstre til høyre, men jeg kommer til å ringe navnet på dette feltet huset, og deretter den typen jeg har nå til å velge. Så la oss ta en kort prat om de ulike typene i MySQL fordi mens PHP er svakt skrevet og den slags spiller rask og løs med typer, i en database spesielt det er super viktig å faktisk bruke skrive til din fordel fordi en av de tingene MySQL og andre databasemotorer kan gjøre for deg er at du ikke legger falske data inn i databasen. Dette er liksom fritt feilkontroll tilgjengelig for deg. 

For huset selvsagt vi ikke ønsker at det skal være en int, som er en 32-bits verdi i MySQL. Vi snakker kort på fredag ​​om varchar, som står for variabel lengde røye. Hva er dette? Dette gjør at du kan angi at du vil at dette skal være en streng av noe slag. Du trenger egentlig ikke vite på forhånd hvor lang tid det er, så vi vil vilkårlig si et hus navn kan være 255 tegn, men du kan gå med 32, 64 - en rekke virkelig. Men fordelen med å bruke en varchar over et felt som heter røye er hva? Bare intuitivt hvis jeg ruller nedover her, merker det er røye og det er varchar. Varchar er variabel lengde røye, sjørøye er en fast lengde røye. Så kun basert på denne definisjonen, er det en fordel eller ulempe av hver av disse? Med andre ord, hvem bryr seg om skillet, eller hvorfor skulle du bry deg? 

Ja. [Student] VARCHAR har mer fleksibilitet, men tar opp mer plass i minnet. Bra. Varchar tar opp mer - La oss se. Jeg er ikke sikker på om jeg hørte det riktig. Kan du si det en gang til? [Student] Jeg sa varchar sannsynligvis har mer fleksibilitet, men det tar opp mer plass i minnet. Interessant. Okay. Varchar trolig gir deg mer fleksibilitet, men tar opp mer plass i minnet. Sistnevnte er ikke nødvendigvis sant. Det avhenger av konteksten, men la oss komme tilbake til det. 

[Uhørlig student respons] Nettopp. Det er faktisk slik at røye vil vanligvis bruker mer minne fordi en røye, som i C, er som en streng, er det en rekke tegn. Så hvis du sier en char felt av lengde 255, databasen er bokstavelig talt kommer til å gi deg 255 tegn. Og hvis huset ender opp som Mather og 6 tegn totalt, du kaster bort over 200 tegn. 

Så en varchar effektivt bruker bare så mange tegn som er nødvendig opp til en maksimal mengde. Men prisen du betaler er faktisk ytelse, potensielt. Hvis du vet på forhånd at alle dine strenger kommer til å være 8 tegn - for eksempel anta at du trenger passord av lengde 8 - oppsiden for å bruke en char felt på anledningen, men ikke ofte, er å bestemme en fast lengde for noe sånt som en passord fordi nå databasen kan bli enda smartere. Om den vet at hver char felt, hver streng i en kolonne med samme lengde, du får tilbake funksjonen av random access. Du kan hoppe rundt blant de ulike røye felt i databasen tabellen fordi tenke på en database som rader og kolonner. Så hvis hver og en av strengene er like lange, du vet at den første er på byte 0, er den neste på byte 8 og deretter 16 og deretter 24 og så videre. Så hvis alle strenger er av samme lengde, kan du hoppe rundt mye mer effektivt. Så det kan være en fordel med tanke på ytelse, men vanligvis du ikke har den luksus av å vite på forhånd, så en varchar er veien å gå. Her er en annen detalj at selv Facebook kjørte inn til slutt. Ints er stor, og vi liksom bruke dem som standard hver gang vi ønsker et nummer, men det er bare 32 bits. 

Og selv om Facebook ikke har helt 4000000000 brukere nå, Det er definitivt noen mennesker der ute med flere kontoer eller kontoer som har blitt åpnet og deretter lukket, og så Facebook selv jeg tror et par år siden måtte overgangen fra int til, som er treffende kalt, bigint, som ligger bare 64 bits i stedet. Så dette er også en design beslutning. Du ville være utrolig heldig hvis det endelige prosjektet blir oppstart, har gi 4 milliarder og 1 brukere, eller ta, I så fall bruker ints kan være litt nærsynt. Men i virkeligheten er brukerne tabellen nok greit med ints. Men for noe sånt pset 7, som din historie tabellen, du kan ha tusenvis, millioner av brukere hvis du utvikle seg til etrade.com. Så mens du kanskje ikke har mer enn 4 milliard brukere, disse brukerne du har kan ha mer enn 4 milliarder transaksjoner over tid - kjøper og selger og ting i deres historie. Så hvis du gjør forutse - igjen, disse er gode problemer å ha hvis du har så mye data - hvis du gjør forutse data over størrelsen på en int, kommer med noe sånt bigint er en retning ikke ofte nok vedtatt av designere fordi folk figur som ikke kommer til å være et problem, men det er enkelt å velge noe større enn det. Desimal vi bruker i 7 pset, som angir faste presisjon slik at du kan unngå problemer som involverer flyter og dobbeltrom og Reals og lignende. 

Og så er det noen andre felt her. Vi vil bølge våre hender på dem til en viss grad. Men datoer, klokkeslett alle har en foreskrevet format i MySQL, og fordelen av å lagre datoer som datoer og ikke varchars betyr at databasen kan faktisk formatere dem i forskjellige formater, om en amerikansk format eller europeisk format eller lignende - men du ønsker det - mye mer effektivt enn hvis det var bare noen generiske varchar. Og så er det noen andre binær, VARBINARY, blobs. Dette er binære store objekter, og du kan også lagre binære data samt geometriske data i en database. Men for oss vil vi vanligvis bryr seg om ints og varchars og lignende. La oss avslutte dette eksemplet med huset. Huset skal jeg vilkårlig si vil være 255 tegn. Så standardverdi vi kunne gjøre dette. Vi kunne som standard satt alle i Mather House, for eksempel. Det er hvordan vi kan angi at databasen sørge for at noen alltid har en verdi. Men jeg skal la det være. Faktisk, for folk som bor utenfor campus, og ikke i et hus, kanskje jeg faktisk ønsker å presisere at standardverdien for huset er NULL, og da trenger jeg å sjekke denne boksen og fortelle databasen det er greit hvis brukerens huset er NULL. 

Igjen, dette er en annen forsvarsmekanisme du kan sette på plass så du trenger ikke engang å sette den i PHP-koden nødvendigvis. Databasen vil sikre at ting er eller ikke er NULL. Og så til slutt, attributter. Ingen av disse er virkelig relevant. Binary, usignert - ingen av disse er relevante for en varchar. Indeks. Vet noen eller huske eller har en gjette på hva en indeks er for noe som huset? Dette er også faktisk en viktig og relativt enkel design beslutning. For de som ennå ikke har sett det, på fredag ​​snakket vi kort om primærnøkler. I en database tabell, er en primærnøkkel feltet eller kolonnen som identifiserer entydig rader i tabellen. Så i den gjeldende tabellen har vi IDer, har vi navn og e-poster. Hvilken av disse er den beste kandidaten til å være en primærnøkkel, hvis rolle er å identifisere rader? Sannsynligvis ID. Uten tvil, kan vi også bruke det selv? Kanskje du kan bruke e-post fordi i teorien er det unike med mindre folk deler e-postkontoer. Men realiteten er at hvis du bruker en numerisk ID som 1234, det er bare 32 bits, mens en e-postadresse kan være så mange byte eller så mange byte. Så i form av effektivitet for unike identifikatorer, det pleier å være god praksis bare å bruke en int selv om du har noen streng kandidat som du kan kanskje bruke. 

For noe sånt hus, bør dette ikke være en primærnøkkel fordi da bare en person kunne leve i Mather og en person i Currier og lignende. Likeledes bør dette ikke være unik. Forskjellen mellom primær og unikt er at i tilfelle av vårt gjeldende tabell, ID ville være primær, men e-post er ikke primært for årsaken til at vi nettopp nevnte - ytelse - men det bør likevel være unikt. Så du kan fortsatt håndheve unikhet uten å gjøre kravet at det er en super viktig primære feltet. Men dette er ganske nyttig: Index. Hvis du vet på forhånd for det endelige prosjektet, for pset 7, eller generelt, at dette feltet huset kommer til å være noe du søke på mye bruker velger søkeord eller noe annet, så kan du preemptively fortelle databasen til å arbeide sin magi og sørg for at det skaper i minnet noen fancy datastrukturer nødvendig å ekspedere søk basert på huset. Kanskje vil den bruke en hash table, kanskje det vil bruke en lenket liste. I virkeligheten, det har en tendens til å bruke et tre, kalles ofte en struktur en B-tree - ikke et binært tre, men et B-treet - som er et svært bredt treet som du kan se i en klasse som CS124, data strukturer klassen. Men kort sagt, trenger du ikke å bekymre deg for at når du bruker smart database programvare. Du kan bare fortelle det, "Indeks dette feltet slik at jeg kan søke på det mer effektivt." 

Hvis du lar dette seg og du prøver å søke etter alle i databasen som bor i Mather, det tilfaller til lineær søk. Og hvis du har 6000 undergrads alle som bor i noen hus, du kommer til å søke i hele tabellen for å finne Matherites, mens hvis du sier Index, forhåpentligvis vil det være noe nær en logaritmisk søk å finne slike studenter. Dette er bare en gratis funksjon for å slå på, selv om det kommer til en pris på en viss mengde plass. Til slutt, auto-tilvekst, dette AI-feltet, noe som betyr at bare hvis det er en int og du ikke ønsker å bry seg å øke det selv hver gang det er en ny bruker, sjekk at og hver bruker som blir satt inn vil automatisk få en ny ID. La oss klikke Lagre, og la oss nå finne feil med dette motivet. Hvis jeg går inn i Browse, legg merke til at både Mike og mitt hus er NULL. Jeg kan bruke phpMyAdmin til å redigere denne manuelt. Jeg kan gå inn her og skriv inn Mather og trykk Enter, og nå merke tabellen er forskjellig. Men merker jeg kunne gjøre noe annet også. Davids ID er 1, så phpMyAdmin igjen er bare et administrativt verktøy; dette er ikke noe brukerne noensinne kommer til å se. Så hvis jeg i stedet klikke SQL-kategorien opp toppen - og igjen, vil pset 7 introdusere deg til flere av disse søkene - Jeg kan manuelt utføre SQL Structured Query Language kommandoen UPDATE brukere SET hus = 'Pfoho' WHERE id = 1. Disse SQL-spørringer er, pent nok, ganske lesbar fra venstre til høyre. Oppdater brukere tabellen, sette feltet som heter huset til Pfoho der brukerens ID er 1. Eller jeg kan selv gjøre der email = 'malan@harvard.edu'. Så lenge som identifiserer meg, ville det fungerer like godt. Men ID tendens til å være høyere ytelse, så la oss gjøre det. La oss klikke Start. Ok, ikke lecture.users ikke eksisterer. Hva er min feil? Hva er tabellen faktisk kalt her? Det kalles studenter bare fordi det er hva vi gjorde her oppe øverst til venstre. Det kalles studenter, ikke brukere. Så klikker Gå nå. 1 rad påvirket. Query tok 0,01 sekunder. Hvis jeg klikker Bla nå, nå Malan liv i Pfoho. Så det er en annen smak av SQL, men pset vil gå gjennom en litt mer av det. 

Det er en dum avgjørelse jeg har allerede gjort her. Jeg vil hevde at denne databasen design er ineffektiv fordi flere folk jeg legger til studenter tabellen, det flere av oss begynner jeg å legge til, jo mer av TFS jeg begynner å legge til, vi kommer til å begynne å se hva oppsigelser i denne tabellen? 

Ja. [Student] Ser at det er i studenter, bruker vi den samme [hørbar] Det samme - Høyre, akkurat. Så hvis 400 mennesker bor i Mather, gi eller ta, slutt denne tabellen kommer til å ha 400 rader som sier "Mather," "Mather," "Mather," "Mather," "Mather." Vi kaster bort alle disse byte, og det er et par takeaways der. 1, er det den gale hjørnet tilfelle der hvis noen betaler en masse penger og endrer navn Mather, har vi nå nødt til å endre hele vår database tabellen. Som ikke kommer til å skje ofte, men Pfoho ble en gang kalt North House 15 år siden, så skjer det. Men det er ikke alle som overbevisende. Mer overbevisende enn et hjørne sak som det av som ønsker å oppdatere data i bulk for en database hvorfor er du lagre MATHER igjen og igjen og igjen og igjen? Det er mye tegn, 6 tegn. Kan ikke vi gjøre det enda bedre enn det, spesielt for Pforzheimer? Sikkert vi kan gjøre bedre enn at mange tegn. Hvorfor ikke bare knytte en unik identifikator med hvert hus og butikk som for hver bruker? Så la oss prøve dette. Snarere enn å bare bruke studenter tabellen, la meg gå opp til min forelesning database opp her øverst til venstre. Legge merke til her står det Lag tabell. La meg lage en ny tabell kalt hus. Antall kolonner skal være 2. Enter. Nå har jeg to felt. Jeg kommer til å kalle dette navnet, og det kommer til å bli en varchar av lengde 255, 

men det er ganske vilkårlig. La meg sette dette her nede ved konvensjonen. Så sette en ID her oppe. La oss gi hvert hus en unik identifikator. La oss gi hvert hus et navn. La oss presisere at identifikatoren skal være usignert bare ved konvensjonen å bare bruke positive tall. La oss gå videre og gi dette en auto-økning feltet for nå. Og trenger vi noe annet? La oss gå videre og klikk på Lagre. Nå har jeg en ny tabell. Legg merke som en side er dette litt kryptisk SQL kommando at du ville ha hatt å skrive inn manuelt hvis du ikke bruker et administrativt verktøy som phpMyAdmin. Så en annen grunn til at vi bruker den. Det er fantastisk nyttig slags pedagogisk fordi du kan klikke rundt og finne ut hvordan ting fungerer ved å bare kopiere og lime hva phpMyAdmin gjorde. Men Opprett tabellen kommandoen er det nettopp ble henrettet, og her er mitt bord. La meg gå videre nå og bruke rå SQL stedet oversimplify ved å klikke kategorien Sett inn. La meg gjøre INSERT INTO hus, og jeg kommer til å si navnet på huset kommer til å ha en verdi av 'Mather'. Det var det. Denne syntaksen er litt mer kryptisk. Dette er navnet på de feltene vi ønsker å sette inn. Dette er de verdiene vi ønsker å sette inn i disse feltene. La meg deretter Go. 1 rad satt tok 0,02 sekunder. La meg klikker Bla nå. 

Legg merke til om jeg klikker Bla gjennom, er det Mather, som ID er ved automatisering nummer 1. La meg gjøre en annen. La meg gå inn i SQL-kategorien. INSERT INTO hus. Navnet på huset kommer til å ha en verdi på Pfoho og så videre. Go. Og jeg kan fortsette å gjøre dette igjen og igjen og igjen. Eller hvis du blir lei med phpMyAdmin, kan du bare bruke kategorien Sett og ikke trenger å skrive den rå SQL. Du kan bare banke den ut raskere ved å skrive, for eksempel, Currier, Enter, og nå om vi klikker Bla gjennom, er det Currier med en ID på 3. Så dette er hva vi mener med auto-økning. Men nå må vi fikse noe i studenter. I elevene hva bør datatypen av huset feltet nå? Det bør være en int, ikke sant? Så målet her er å faktor ut, ellers kjent som normalisere, tabellene slik at vi ikke lagrer informasjon redundant i noen av mine tabeller. Og igjen, den veien vi var på her kommer til å si Mather, Mather, Mather, Mather, Pfoho, Pfoho, Pfoho, Pfoho, som er svært overflødig i form av wastefulness av tegn. Så la meg gå videre og endre dette ved å klikke struktur, og la meg gå videre og sjekke ut huset feltet, klikker du Endre, og nå skal jeg endre dette for å være en int. 255 er ikke lenger relevant. La meg gå videre og si det er greit hvis det er fortsatt NULL. Lagre. Nå tabellen studenter har blitt endret vellykket, og legge merke igjen huset er en int. Som en side, ignorere Tallet i parentes når det kommer til ints. 

Dette er for eldre grunner. Tilbake i dag når du ikke har GUI, du i stedet hadde en kommandolinje miljø, de 10 og 11 henholdsvis spesifisert hvor mange tegn du bør vise i terminalvinduet å faktisk vise felt. Det har ingenting å gjøre med litt lengde av selve feltet, så vi får bare ignorere det for nå. Nå må jeg gå inn i dette bordet. Og hvis David bor i Mather, bør huset ikke være 0, som er en standard int verdi nærmest NULL. Han skal leve i huset en. La oss vilkårlig si at Mike bor i Pfoho, så husnummer 2. Nå mitt bord ser litt mer kryptisk. Men vurdere effektiviteten. Jeg bruker nå bare 32 bits for å identifisere huset, noe som betyr at det er bare 1 kanoniske definisjonen av huset mitt Mather og Pfoho og det er i hus tabellen. Så hvis jeg vil nå vende disse tabellene, tenk på det på denne måten. Her har jeg mine studenter bord, og på høyre side er det disse tallene, 1 og 2. 1 er Mather, er to Pfoho. Vi har de samme tallene i denne andre tabellen, som kalles hus, 1 og 2 og 3 for de tre hus. Det vi nå ønsker å gjøre er å ha evnen i koden, PHP og SQL, å sortere av vende disse tabellene, der hvis disse er studenter og disse er husene, vi ønsker å liksom kombinere dem slik at en linje med 1, 2 linjer opp med to, og slik at vi kan finne ut hvor David og hvor Mike og hvor alle andre bor. For å gjøre dette kan vi utføre en SQL-spørring som følgende. SELECT * FROM studenter BLI hus ON - Og nå hvilke felt vi ønsker å delta på? Så students.house = houses.id. 

Litt kryptisk, men denne delen betyr bokstavelig opprette en ny midlertidig tabell det er resultatet av å bli studenter og hus. Og hvordan vil du kombinere tips av fingrene her? Still studentenes hus feltet lik husene 'ID-feltet. Og hvis jeg nå klikker Start, får jeg tilbake akkurat det jeg håpet på. David er i Mather, er Mike i Pfoho, og jeg ser også de unike identifikatorer. Men poenget er nå har jeg en komplett tabell. Og så takeaway her for pset 7 eller egentlig for det endelige prosjektet: Hvis du finner ut at du lagrer alt av informasjon redundant, enten det er et hus, kanskje det er en by, stat og ZIP hvor ZIP kan vanligvis, men ikke alltid brukes som en unik identifikator, går gjennom øvelsen mentalt og deretter med noe sånt som phpMyAdmin av factoring ut at felles data fordi spesielt som ditt nettsted får mer godt brukt og mer populært, dette er hvordan du sørger for at alt er super rask, ved å gi databasen så mange hint til unikhet som mulig. Det var mye. Eventuelle spørsmål? OK. La oss ta en 5-minutters pause der og omgruppere. OK. Det følgende er et eksempel som ble brukt for noen år siden da jeg tok CS161, som er den operativsystemer klasse på college som er kjent for å være fantastisk, men en gal mengde arbeid, og den fokuserer veldig på noen av de lavnivå problemer som oppstår i operativsystemer og også selv i en verden av databaser. 

Historien som ble fortalt av min professor, Margo Seltzer, det året var som følger. Anta at du har en liten dorm kjøleskap for deg og din samboer og dere begge virkelig liker melk. Så du kommer hjem fra klassen en dag, er romkameraten din ikke der, du åpner kjøleskapet, og du skjønner, "Oh damn, vi er ute av melk." Så du lukker kjøleskapet, du gå over gaten til CVS og få i stadig lange køer for å kjøpe melk på CVS. I mellomtiden kommer romkameraten din hjem fra hans eller hennes klasse, kommer inn i rommet, åpner kjøleskapet virkelig ønsker litt melk, åpner kjøleskapet og "Damn, ingen melk." Slik at han eller hun lukker kjøleskapet, går ut døren, og går til Abp eller et annet sted enn CVS der du ikke kommer til å støte på hverandre å gå få litt melk. Selvfølgelig noen minutter senere, begge kommer hjem og nå har du dobbelt så mye melk som du faktisk ønsket. Og å være melk, nå det kommer til å gå dårlig fordi du liker melk men du ikke liker melk, så nå har du for mye melk, så det kommer til å surne. Dette er en forferdelig, forferdelig situasjon. Hva kunne ha løst denne situasjon hvis du var den første romkamerat hjemme? Ja. [Student] Du bør ha forlatt et notat. [Latter] Bra. Du bør ha forlatt et notat. Du bør ha satt en Post-it lapp eller som å si, "Gone for melk," og deretter din romkamerat konseptuelt ville ha blitt låst ute av faktisk gjøre det. Eller du kan gå en skritt videre. Du kan bokstavelig talt låse kjøleskapet med en slags hengelås, og nå romkameraten din vil bokstavelig talt bli låst ut av kjøleskapet. Hvis vi generalisere tilbake til programmering, du kan nesten tenke på kjøleskapet som en slags variabel eller en struct, en slags beholder for informasjon. Problemet fundamentalt her er at dere begge fikk lov til å inspisere eller lese tilstanden til dette datastruktur, men du så den til forskjellige tider og ennå begge har gjort en beslutning basert på tilstanden i verden på de forskjellige øyeblikk i tid. Så hadde du låst kjøleskapet, ville du ha minst unngått romkameraten din fra å ha vært i stand til å inspisere tilstanden i verden, slik at han eller hun ikke kunne ha gjort det samme vedtaket. Så databaser, som det viser seg, har dette problemet hele tiden. 

La oss se om vi kan konstruere et scenario. Anta at du er liksom en dårlig fyr og du går til Bank of America eller en av de andre steder i plassen som har et par minibanker side ved side, og noe du har funnet ut hvordan du kan kopiere en minibank kort - ikke så vanskelig. Det er bare en magnetstripe. Og så hva du ønsker å prøve å gjøre er å spille dette spillet hvor du setter en kort inn en maskin, et annet kort i den andre maskinen, og du egentlig ønsker å prøve å ta ut penger samtidig, fordi forestille seg at historien går som følger. Maskinen til venstre tar kortet og PIN-koden, og du sier: "Gi meg 100 kr." ATM er programmert til først gjøre en utvalgt på sin database eller tilsvarende - uansett database den bruker - for å se har denne brukeren minst $ 100 i hans eller hennes konto? Hvis ja, så spytte ut $ 100 og trekke $ 100 fra sin balanse. Men selvfølgelig hvis det er flere maskiner her eller flere måter å inspisere staten som verden, bankhvelv, for å se hvor mye penger du har, anta at bare ved en tilfeldighet maskinen på venstre og høyre både ber om at spørsmålet på omtrent samme tidspunkt. 

Og dette kan sikkert skje. Minibanker er datamaskiner i disse dager. Så hvis maskinen til venstre sier, "Ja, du har minst $ 100," mellomtiden maskinen på høyre sier: "Ja, du har minst $ 100," da begge med å avslutte sine programmer og faktisk spytte ut $ 100 og si: "Tidligere du hadde 200 dollar." "La meg oppdatere variabelen til nå være $ 100 igjen på kontoen." Men hvis begge har sjekket saldoen og funnet ut at det er $ 200 og begge så gjøre regnestykket og si 200-100, maskinene har potensielt spytte ut to $ 100 regninger i hver maskin, men de har bare oppdatert sum saldo å være 100 kr. Med andre ord, har du tatt ut $ 200, men fordi de inspiserte tilstanden i verden samtidig og deretter gjort en beslutning basert på denne verdien, de kan ikke gjøre regnestykket til slutt riktig. Så i en bank situasjonen også du virkelig ønsker å ha noen form for lockout slik at så snart du har sjekket tilstanden noen variable det er veldig viktig, som saldoen, ikke la noen andre ta avgjørelser basert på det før du er ferdig gjør din greie, hvor i dette tilfellet er du ATM på venstre side. Låse alle andre ut. Du kan faktisk oppnå denne effekten i et par forskjellige måter. 

Den enkleste måten MySQL er en linje av SQL som vi ga deg i oppgavesettet spesifikasjonen som ser akkurat slik ut. Sett inn i tabellen - hva det heter - en id, et symbol, og en aksje, et antall aksjer, følgende verdier, for eksempel. Hvis du ikke har lest spec ennå, er dette et eksempel som involverer hvordan du går om kjøpe 10 aksjer i denne penny stock for president Skroob, hvis bruker-ID skjer for å være nummer 7? Dette sier INSERT INTO tabellen følgende id, symbol, og antall aksjer av 7, 'DVN.V' og 10. Men - men, men, men - den andre linjen er viktig. PÅ duplikatnøkkel UPDATE aksjer = aksjer + VALUES (aksjer). Så helt kryptisk-ser ved første øyekast. Men det faktum at denne SQL-spørringen, selv om det brytes ned to linjer, er en lang søk, betyr det at det er atomic i den forstand at denne spørringen vil enten bli utført alle sammen eller ikke i det hele tatt. Og per definisjon av MySQL, det er hvordan de implementeres dette søket. Det er ved definisjon i håndboken garantert å utføre på en gang eller ikke i det hele tatt. Motivasjonen for dette er som følger. Hvis det i dette tilfellet er det du prøver å kjøpe 10 aksjer på lager, det er slags av den samme historien som melk, det er slags av den samme historien som ATM. 

Hvis du gjør den feilen å ikke bruke denne syntaksen men i stedet velge fra databasen for å se hvor mange aksjer i dette penny stock har president Skroob, og antar at han har 10 aksjer, og deretter noen brøkdels sekund senere så gjør en UPDATE-setning, som er en annen uttalelse i SQL som sier gå videre og legge til 10 flere aksjer sin nåværende 10 slik at ideelt totalt er 20, problemet er at i dagens databasesystemer og fordi dagens datamaskiner du har flere prosessorer, flere kjerner - med andre ord, kan datamaskiner bokstavelig talt være å gjøre flere ting på en gang - det er ingen garanti for at din SELECT og UPDATE i dette tilfellet kommer til å skje rygg mot rygg. Så en dårlig scenario ville være du gjøre SELECT å se hvor mange aksjer i dette penny stock har Skroob, og så bare ved en tilfeldighet en annen database spørringen utføres - kanskje sin Skroob i et annet vindu prøver å kjøpe 10 aksjer i et annet vindu helt, mye som ATM - og anta at en annen spørring blir i mellom SELECT og UPDATE. Det kan være tilfelle at Skroob nå mister noe antall aksjer fordi en annen prosess inspiserer staten hans verden, eller han får flere aksjer enn han burde ha. Vi vil ikke gå inn i opplysninger om nøyaktig hva disse spesielle historien linjer ville være, men poenget er at hvis du må sjekke en variabler verdi og deretter ta en beslutning, hvis det er en risiko for at noen andre gjør noe i mellom disse to utsagnene, som kan skje i flerprosessorsystemer, i flerkjernede systemer, datamaskiner med evnen til å gjøre flere ting på en gang, kan dårlige ting skje som bankkontoer blir belastet feil, kjøpe dobbelt så mye melk, eller i dette tilfellet feil antall aksjer. Men det finnes en enklere måte å tenke på dette. 

Det viser seg at SQL støtter også, hvis du konfigurere tabellen riktig, noe som kalles transaksjoner, som jeg vil hevde er faktisk enda lettere å forstå enn dette, men det er ikke en 1-liner, så det er faktisk litt mer involvert. Det er bokstavelig talt en uttalelse i SQL kalt START transaksjonen. Akkurat som det er SELECT, UPDATE, INSERT, DELETE, og bli med og en haug med andre, Det er søkeord som START transaksjonen. Og hva du gjør deretter i forbindelse med pset 7 - du trenger ikke å gjøre dette for pset 7, det er eksplisitt fraskrevet som ikke er nødvendig, men for endelig prosjekter kan det være nyttig - Hvis du kaller en spørring av START transaksjonen og deretter en annen spørring og deretter en annen spørring og deretter en annen, en annen, og en annen, disse søkene vil faktisk ikke bli henrettet før du ringer SQL-setningen COMMIT, på hvilket tidspunkt, enten det er to utsagn eller 20 uttalelser, vil de alle bli henrettet på en gang, noe som betyr at ingen andre kan uhell kjøpe for mye melk eller debetkort for mye penger eller kjøpe for mange aksjer fordi alle dine spørsmål vil utføre rygg mot rygg til rygg mot rygg. Og dette er super viktig, spesielt når du gjør noe som dette. Dette er et vilkårlig eksempel som sier la oss oppdatere bankkonto ved å sette en balanse lik balanse - $ 1000 der kontonummeret er to. Og så den andre setningen er la nå er innskudd at $ 1000 i en annens bankkonto som kontonummer er en. 

Med andre ord, dette er et perfekt eksempel på hvor du ønsker å være sikker at begge disse utsagnene skje eller ikke i det hele tatt fordi ellers kunden kommer til å bli skrudd og du kommer til å ta pengene sine og ikke sette den et annet sted, eller banken kommer til å bli skrudd der du kommer til å sette pengene men faktisk ikke trekke det fra brukerens konto. Så du vil ha både av dem for å utføre sammen. Dermed inngår verden transaksjoner. Så det er noe å holde i bakhodet, ikke så mye i forbindelse med bare et avsluttende prosjekt, men hvis du ønsker å ta det endelige prosjektet et sted, Hvis du ønsker å starte opp litt selskap rundt den, Hvis du ønsker å løse noen student gruppens problem på campus og faktisk har en levende, aktivt nettsted, disse er den slags subtile feil som kan oppstå Hvis du ikke helt tenke gjennom hva som kan skje hvis to personer prøver å få tilgang til nettstedet på bokstavelig talt i samme øyeblikk i tid, der sine forespørsler ellers blir vevd sammen. 

Klar for noen JavaScript, en teaser derav? Dette er vår siste språk for semesteret. OK. Heldigvis ser JavaScript veldig, veldig, veldig lik de to språkene, C og PHP, vi har gjort så langt. Det er ingen JavaScript pset 7, men det er et utrolig nyttig verktøy når det gjelder å gjøre web-baserte endelige prosjekter eller egentlig bare webprogrammering mer generelt. Så en rask oversikt over noe som kalles DOM. Her er en super enkel nettside som egentlig bare sier hei, verden både i tittelen og i kroppen. Som innsnittet har vært foreslå for noen tid, det er faktisk et hierarki til nettsider. Jeg kunne trekke den samme bit med HTML som et tre, tenker tilbake til våre diskusjoner datastrukturer i C, som følger. Jeg har noen spesiell rotnoden kalt dokumentet node, og vi vil se analog av dette i JavaScript bare et øyeblikk. Den første barn og eneste barn av at i dette tilfellet er HTML-koden. Det er ingen direkte kartlegging av DOCTYPE. Det er en spesiell ting, så vi skal bare ignorere det når det kommer til dette DOM, Dette Document Object Model treet. Legg merke til at HTML-koden, som jeg har avbildet vilkårlig som et rektangel, har 2 barn: hode og kropp. 

De er på samme måte tegnet som rektangler. Det er meningsfullt billedlig at hodet er til venstre for kroppen. Implikasjonen er at hodet kommer først i treet. Så det er faktisk en bestilling til et tre når du tegner det slik, selv om figurene og whatnot er vilkårlig. Hodet har i mellomtiden en enkelt barn kalt tittel, og tittelen har faktisk sin egen barn, som er "Hello, World", som jeg bevisst trakk som en oval her for å gjøre det litt forskjellig fra rektangelet. Disse rektangler er elementer, mens Hallo, er verden virkelig en tekst node. Så det er en node i treet, men det er en annen type node så jeg trakk det vilkårlig annerledes. Tilsvarende har kroppen et barn som heter Hallo, verden også, så forskjellig node selv om de er tilfeldigvis den samme teksten, men jeg har trukket den med samme form. Så hvem bryr seg? Vel, hva er fint om HTML er at det har denne hierarkiske natur. Og hva er fint om JavaScript og spesielt bibliotekene som er fritt tilgjengelig og populære som jQuery, kan du navigere trestrukturen så utrolig lett. Noen av tingene vi gjorde i C med pekere og traversering trær og recursing på noder venstre barn til høyre barn, plutselig kan vi liksom ta for gitt som utrolig opplysende om ikke litt frustrerende men ikke på langt nær en effektiv måte å gå om programmering. Og så med disse høyere nivå språk som JavaScript vi vil være i stand til å navigere dette treet mye mer intuitivt. 

Og faktisk syntaksen kommer til å være ganske godt kjent. Hvis du aldri har sett JavaScript før, er dette en veldig fin referanse fra Mozilla folk, folk som gjør Firefox, så gjerne bla at det passer deg. Hva du finner - og disse lysbildene er identisk med hva vi brukte den andre dagen - Tilsvarende er viktigste borte. Så når du skriver et program i JavaScript, er det ingen hovedfunksjon. Du bare begynne å skrive kode. Men en viktig forskjell mellom JavaScript og C og PHP er at mens C og PHP så langt har blitt henrettet server side ved apparatet i dette tilfelle eller mer generelt av en server, JavaScript ved design er vanligvis utført av en nettleser. Med andre ord, kan du skrive JavaScript-kode, som vi er i ferd med å, på en server i apparatet, men du inkludere det blant HTML-koden, blant CSS din, blant dine GIFs og dine PNG og JPEG bilder slik at når brukeren besøker nettsiden din, hvis du bruker JavaScript, at JavaScript-koden kommer fra serveren til nettleseren, og det er nettleseren som faktisk utfører det. Så dette har meningsfulle konsekvenser for enda åndsverk. Det er litt dumt å begynne å tenke på å beskytte din IP når det kommer til JavaScript-kode fordi av natur av språket det blir utført regel nettleser side. 

Du kan obfuscate det, som betyr at du kan gjøre det ser gal og stygg uten mellomrom, fryktelig variabelnavn, for å gjøre det vanskeligere for folk å stjele din IP, men de viktigste er at den utføres webleser side. Selv om som en side JavaScript kan brukes server side, den vanligste måten å bruke akkurat nå er fortsatt på nettleseren. Og her er hva det ser ut som. Her er en if-else if-else konstruere akkurat som C, akkurat som PHP. Her er en boolsk uttrykk når du "eller" 2 ting sammen. Her er når du "og" 2 ting sammen. Her er en bryter uttalelse, som ligner på PHP ved at du kan slå på ulike typer verdier. Looper samme har for løkker her, som er strukturert identisk til hva vi har sett før. Mens looper, vi har fått gjøre mens sløyfer. Variabler, aldri så litt annerledes. Du trenger erklærer variabler som du gjør i PHP og C, men på samme måte er JavaScript svakt skrevet. Du trenger ikke oppgi int eller flyte eller hyssing eller noe sånt vanligvis. Du kan angi var. Du trenger ikke å angi var, men det har implikasjoner hvis du ikke gjør det. Vanligvis hvis du utelater var, du tilfeldigvis opprette en global variabel i stedet for lokale. Så la meg foreslå at du nesten alltid bare si var og så navnet på variabelen. Det er ikke en type, det er bare VaR for variabel. Dette ville være et eksempel, enten det er 123 eller "hallo, verden". Arrays er til stede og syntaktisk lik PHP. Jeg vil si VAR tall og deretter bruker jeg hakeparenteser igjen for å erklære en variabel hvis typen er array som har disse spesielle numre i det adskilt med komma. Og så til slutt, er dette den eneste som virkelig ser annerledes ut. Husk at i PHP ville vi ha gjennomført en assosiativ array for en student som Zamyla som kan se slik ut, hvor variabelen kalles student. Klammeparentesene mener her kommer en matrise. 

Det faktum at jeg ikke bruker numeriske indekser, men strenger - id, house, og navn - betyr at dette er en assosiativ array, og disse pilene med likhetstegnet og vinklet brakett betyr at nøkkelen er "ID", verdien 1; nøkkelen er "hus", er verdien Winthrop House; nøkkelen er "navn", er verdien Zamyla Chan. Så det er 3 nøkler inne i denne assosiativ array, som hver har sin egen verdi. Vi har sett at i 7 pset, eller du snart vil i JavaScript samme idé, men det kommer til å se slik ut. Så Var student - ingen dollartegn og ingen omtale av typen fortsatt, men Var - likeverdige og deretter åpne klammeparentes fordi i JavaScript når du har viktige verdi-par, du faktisk bruker noe som kalles et objekt. Og de av dere som tok APCS eller lignende kanskje husker objekter fra Java eller lignende språk. JavaScript er ikke Java, først av alt. Det var et bevisst valg år siden for å kutte ut noe annet som var populært, sitt navn, selv om det ikke har noen relasjon til fundamental JAVA selv. JavaScript har objekter, og du oppretter dem ved hjelp av krøllete brace notasjon. Objekter i JavaScript er ganske mye tilsvarer assosiative arrayer i PHP når det gjelder å lagre data innsiden av dem. 

Men enda mer kraftfullt i JavaScript kan du knytte veldig enkelt funksjoner innsiden av et objekt, og selv om du kan gjøre dette på andre språk, det er ganske vanlig paradigme, som vi skal se. Kort sagt, representerer dette objektet en student, som er spesielt Zamyla, og det er like konseptuelt, bare syntaktisk forskjellig fra dette. La oss faktisk bruker JavaScript i en fil. Det viser seg at det er en skriptmerket. Vi har sett en stil tag, og vi har sett andre HTML-koder. Skriptmerket faktisk vil inneholde noen JavaScript-kode. La meg gå inn i apparatet der vi har noen kildekoden pre-laget. Jeg har ikke lagt det ennå på nettsiden, men jeg vil gjøre det etter klassen. La oss åpne opp dette, blink.html. Tilbake på 1990-tallet, var det bokstavelig talt en HTML-kode som kalles blinking tag, og dette var en av de mest fantastiske overused koder på Internett hvor du vil besøke noen 1990 style nettside og begynne å se tekst blinker du dette, resultatene av marquis tag, som hadde teksten går slik. En av de få gangene hvor verden har faktisk blitt enige om en web standard, alle over hele linja drepte blinke tag noen år siden. Men vi kan gjenopplive den med JavaScript som en demonstrasjon av kraften du har når du kan skrive et program inne i en nettside. Først la oss hoppe over nye ting og fokusere bare på den gamle. 

Her er den gamle ting i dette eksemplet. Jeg har en HTML-kode, et hode tag, og en tittel tag. Så jeg har en kropp tag her med en div, som er tilbakekalling bare en rektangulær inndeling av siden at jeg har gitt en unik ID vilkårlig av "hilsen" til, så jeg har en måte å unikt henvise til det, har det noen veldig enkle tekst: Hei, verden. Nå la meg bla opp til toppen av denne filen og se hva som er nytt. Det første som er nytt opp toppen er skriptmerket, og innsiden av skriptmerket varsel har jeg erklært en funksjon. Å erklære en funksjon i JavaScript, ganske lik PHP, du bokstavelig talt skrive funksjonen og navnet på funksjonen, parentes, og kanskje noen argumenter hvis det tar noen. Da har jeg fått min krøllete brace som vanlig, og nå har vi noen litt ny kode, men la oss se hva dette betyr. Så Var div, betyr dette bare gi meg en variabel kalt div. Jeg kunne ha kalt det foo, men jeg ønsket å bli kalt div grunner som vil være klart i et sekund. Så viser det seg i JavaScript - og dette er JavaScript-kode innebygd i min nettside - det er en spesiell global variabel slags kalles dokument. JavaScript er faktisk et objekt-orientert språk. Vi vil ikke gå i detalj i 50 med hensyn til hva det betyr, men for nå vet at et objekt er ganske mye som en struct. Som vi så langt tilbake når du er i en av de tidligste problemet setter hvor vi legger mye informasjon i en struct, Tilsvarende er dokumenteres et spesielt struct som følger med nettleseren, kommer med en nettside. Det er ikke noe jeg har laget. Inne i dette dokumentet struktur, men har du ikke bare data men du har også funksjoner. 

Og når du har en funksjon inne i en struktur, på innsiden av et objekt, det kalles en metode. Men det er det samme. En metode er en funksjon som bare så skjer for å være inne på noe annet. Så dette betyr at denne spesielle global variabel kalt dokument har en funksjon som heter getElementById som bokstavelig talt gjør det. Det vil få deg et element fra DOM, Document Object Model treet, hvis ID er i dette tilfellet hilsen. Med andre ord, kommer all den tiden vi brukte på datastrukturer spiller inn her. Dette bildet av en DOM at vi hadde et øyeblikk siden, selv om siden er litt annerledes, hvis jeg hadde en div i dette bildet, hva document.getElementById ville gå tilbake til meg ville faktisk være en peker til rektangelet i treet, en referanse til rektangelet i treet. Så det er hva det betyr å faktisk ringe en av disse funksjonene. I dette tilfellet igjen er det en div. Det er ikke et organ eller en tittel. Så la oss se hva jeg så gjøre med dette div nå som jeg har det inne i denne variabelen kalt div. Det viser seg med JavaScript du har muligheten til å finjustere CSS på siden din dynamisk. Frem til nå, er alt av CSS vi har gjort, om enn begrenset, i stil attributter, eller hvor ellers sette vi har CSS? Jeg slags bortskjemt som en. I stil koden øverst av filen. Eller tredje plass har vært i? 

En ekstern fil, noe. Css. Så de er tre steder vi har gjort CSS så langt, men fangsten er vi hardkodet det hele. Du bestemte deg som du due i pset 7, besluttet vi før forelesning hva vår CSS ville være. Men hvis du ønsker å endre CSS, kan du faktisk gjøre det når du har en faktisk programmeringsspråk. CSS, HTML - ikke programmeringsspråk. JavaScript er. Så det viser seg at så snart du har en av disse rektangler fra treet kalt DOM, har det selv noen data inne i den. Så div som jeg bare tok fra treet har det vi kaller en eiendom innsiden av det kalt stil, og stilen hotellet har selv en egenskap kalt synlighet. Jeg ville vite dette bare ved å se opp en CSS brukermanual. Det viser seg at det er en synlighet CSS eiendom som gjør hva den sier. Det gjør noe synlig eller ikke, synlig eller ikke. Og hvordan du gjør det er dette. Jeg spør programmatisk om synligheten av denne div er skjult, hva kan jeg endre det til? Synlig. Annet hvis synligheten av denne siden ikke er skjult, logisk jeg gjør det skjult. Jeg har ingen anelse om hvorfor det er synlig og skjult og ikke synlig og usynlig. Dette var en dårlig design beslutning underveis. Men de er faktisk motsetninger i CSS: synlig og skjult. Alt dette gjør er det betyr endre CSS av filen min på og av, på og av for den aktuelle div. Men igjen, dette er en funksjon som heter blinke. Når er blink funksjon kalt? Det viser seg at det er en annen spesiell global variabel kalt vinduet, lignende i ånden til dokumentet, men mens dokumentet refererer til nettsiden din, som DOM treet, sendte HTML du fra serveren, vindu refererer til krom rundt det, på adresselinjen, tittellinjen, og alle de greiene rundt nettsiden din. 

Og det viser seg at vinduet objektet har en spesiell funksjon innsiden av det som kalles setInterval som gjør hva den sier. Det vil sette et intervall - i dette tilfellet hver 500 millisekunder - og ta en gjetning, hva det kommer til å gjøre hver 500 millisekunder? Det kommer til å utføre denne funksjonen blinker. Og hva er fint her er at vi kunne ha gjort dette i C selv om vi aldri gjorde. C har noe som heter funksjonspekere hvor du kan passere funksjoner rundt som argumenter. Tilsvarende i JavaScript kan du passere navnet på en funksjon i en annen funksjon. Og legg merke til hva jeg gjør. Jeg gjør ikke dette. Hvis jeg legger parentes etter blink, ville det bety kalle blink funksjon. Hvis jeg utelater dem, betyr at her er blink funksjon slik at setInterval kan kalle det hver 500 millisekunder. Så sluttresultatet, fryktelig om det er, er at hvis jeg går inn localhost og gå til blink.html, Jeg har nå dette skjer igjen og igjen. Og hvis jeg faktisk Inspiser Element, la oss se om vi kan se dette. La meg Inspiser Element, la meg bla ned bare litt, la meg velge Elements over her, og merker DOM innsiden av Chrome inspektør. Det er bokstavelig talt å endre frem og tilbake hver 500 millisekunder. Hvis vi går til vår venn Nate, Hvis du noen gang lurt på hvordan dette fungerer, tilsvarende idé med et intervall, men Nate er faktisk gjør veldig effektiv bruk av farger i dette tilfellet her. Så hva mer kan vi egentlig gjøre med dette? La oss åpne opp et annet eksempel og prøve noe det er programmatisk enda mer nyttig enn å gjøre ting blinker. La meg gå inn i våre skjemaer katalogen i dag og gå inn form0. Dette var den styggeste mulig form at jeg kunne komme opp med, og la meg bare vise deg hvordan det ser ut i en nettleser. 

La meg gå inn localhost / former, og dette er form0. Dette er en super stygg HTML-skjema som har noen felt for e-post, for passordet, passord, og deretter en liten avmerkingsboksen for å godta noen vilkår og betingelser. Fangsten er hvis jeg besøker dette skjemaet, og jeg ønsker ikke å gi deg min e-postadresse, Jeg ønsker ikke å godta vilkårene og betingelsene kanskje, kan jeg klikke Registrer og det lar meg gjennom uansett. Dette skjer for å sende til en dum PHP fil som heter dump.php. Alt den gjør er skrive ut innholdet i $ _GET bare for diagnostiske formål. Det var det som var innsendt av brukeren akkurat nå. Men anta at vi faktisk ønsker å validere brukerens innsending av skjemaer. La meg gå inn versjon 1. Dette er form1.html. Det ser estetisk like ille, men merker hvor lyst det er. Hvis jeg klikker Registrer uten samarbeid, får jeg skreket til. "Du må oppgi din e-postadresse." OK. Så la meg prøve det. Så malan@harvard.edu. Jeg trenger ikke et passord. Registrer deg. "Du må oppgi et passord." OK. Så jeg vil gi et passord for rød. Registrer deg. "Passord ikke stemmer." Jeg må nå skrive inn crimson her. Jeg tilfeldigvis sjekket det. Registrer deg. "Du må godta vilkårene." OK. Enig der. Registrer deg. Og nå viser det meg den diagnostiske produksjon over det. 

Så hva skjedde? Vi har hatt denne muligheten til å validere skjemaene. Faktisk, hvis du gjorde dykke inn pset 7, er det en si unnskyld funksjon som gjør det ganske enkelt å kjefte på brukeren med en melding på skjermen. Jeg bruker en litt annen mekanisme, varsling, som ikke er en funksjon som er smilt siden det gjør veldig stygge brukermeldinger. Men la oss se hva jeg gjør her. Dette er form1.html, og merker at jeg har noen ganske kjent syntaks: body-koden, form tag, handling egenskap, metode attributt. Men merker jeg har gitt min form en unik ID for bekvemmelighet. Da har jeg en e-post felt som type er tekst, et passordfelt som type er passord, bekreftelse feltet som type er passord, og deretter en avmerkingsboks som heter avtale over her, er type boksen. Og så har jeg fått en send-knappen. Men merker på toppen hva mer jeg har. Først av alt, det er en annen bruk av skriptmerket. Hvis du har noen JavaScript-kode i en annen fil, akkurat som med CSS kan du ta den med. Og du gjør det med script kilde, og deretter merke Jeg kobler tilsynelatende å googleapis.com til en svært lang vei, men med et filnavn som ender i jquery.min for minimum. js. jQuery er en super populær bibliotek for JavaScript som bare gjør JavaScript alle mer brukervennlig å bruke. Det er effektivt blitt en de facto standard. Så selv om hva du er i ferd med å se er ikke ren JavaScript per se, Det er et bibliotek på toppen av JavaScript mye som CS50 biblioteket er et lag på toppen av lavt nivå C-kode, realiteten er nesten alle på Internett bruker det. Så disse er ikke trening hjul. Dette er bare beste praksis i disse dager. Nå merker under som er mitt eget script tag, og legge merke til hva jeg har gjort her. Det viser seg at jQuery gjør noe litt fancy. JavaScript har dollartegn, men de er meningsløse. 

De er som bokstaven A eller B eller C. jQuery har bare vedtatt konvensjonen eller slags lagt beslag på det faktum at $ vil være deres spesielle symbol. Så så snart du laste denne globale JavaScript-fil her oppe med skriptmerket, du har tilgang til en spesiell global variabel som heter $. Det er mer riktig kalles jQuery, men som ikke ser nesten like sexy som $. Men $ har ingen spesiell betydning. I PHP hadde det spesiell betydning. Du måtte ha den foran en variabel. Dette er bare en sexy ting som de tok på. Hva er det som skjer her? Merker jeg har bestått til jQuery funksjon min global variabel dokument og da jeg ringer. klar. Hva jQuery hovedsak gjør er det tillater deg å ta noen vanilje JavaScript ting som dokumentobjekt, vinduet objekt, og hvis du sender den inn til jQuery funksjon - og igjen, for å være klar, er dette en funksjon som heter jQuery - hva den gjør er det tilbake til deg en spesiell versjon av dokumentet som har mer funksjonalitet knyttet til den. Så i rå JavaScript det ingen klar funksjon, men hvis du passerer dokument til jQuery funksjon først, den returnerer til deg en spesiell versjon av dokumentet objektet som har flere fancy funksjoner. Og det er grunnen til at folk liker det. Det gjør bare ting enklere å gjøre, som vi er i ferd med å se. Så hva betyr denne linjen med kode? Denne linjen med kode betyr her når dokumentet er ferdig - med andre ord, når leseren er ferdig med å lese denne filen topp til bunn - gå videre og utføre følgende funksjon. Hva er virkelig interessant i JavaScript - og PHP har dette også - er anonyme funksjoner. I JavaScript kan du erklære funksjoner som ikke har noen navn, men de har en kropp. Legg merke til hva som skjer her. 

Dette er en funksjon som heter klar, og det betyr bare gjøre følgende når hele nettsiden er klar, når det er blitt lest inn fra serveren. Hva vil du gjøre? Jeg ønsker å kjøre en del av koden. Legg merke til at vi ikke ønsker å kjøre denne koden med en gang. Hvis jeg utelatt dette, ville dette bety umiddelbart begynne å utføre disse linjer med kode. Men det faktum at jeg sier nei, nei, nei, pakk dette i en anonym funksjon som dette betyr ikke utføre den ennå, kaller det slutt. Vi så dette for et øyeblikk siden i vår forrige skjema eksempel. Hvilken funksjon vi kaller slutt, 500 millisekunder senere? Blink. Så den samme ideen. Igjen, selv om dette ser litt rart, bare ta for nå på tro at å erklære en anonym funksjon som kalles slutt, du bare skrive function () { Så hva koden skal vi kjøre til slutt? Følgende. Dette ser også litt nytt, men dette betyr her er jQuery funksjon, og dette er nå en snarvei. Denne bit med HTML nederst på skjermen selvfølgelig har noen trær representasjon. Det er ikke dette. Denne siden er mer interessant enn dette hallo, verden eksempel. Men det er noen trær som tilsvarer denne HTML. Det ville være en smerte i nakken til å gjennomføre noen form for rekursiv funksjon å starte på rotnoden og deretter finne noden som ID er registrering. Så hva jQuery gjør super lett for oss er bokstavelig talt dette. Gå videre og få meg hva div eller uansett form, uansett HTML element har en ID for registrering. Dette tilsvarer document.getElementById ('registrering'). 

Hvorfor folk liker jQuery? Fordi det er kortere å skrive. Men det er alt det er. Det er den samme ideen. Få meg koden som ID er registrering. Og når den tag, som skjer for å være en form, er sendt, gå videre og gjennomføre denne koden. Så la oss ta en titt nå på hvordan vi gjør skjema validering. Syntaksen er riktignok kryptisk i starten, men hva skjer? Hvis denne linjen med kode er sant, jeg kommer til å kjefte på brukeren å gi hans eller hennes e-postadresse. Så hva er denne linjen med kode? $ Betyr jQuery. Nå merke dette. Dette er typen som CSS. Hvis du har dykket inn i CSS ennå, vet du at dette betyr at elementet med ID er registrering. Plassen betyr finne et barn eller en etterkommer av registrering hvis navn skrives inn. Og så denne tingen i hakeparenteser er litt filter. Og selv om dette ser kryptisk, betyr dette bare gå til skjemaet som ID er registrering, gå til inngangen element innsiden av det som heter e-post, og deretter få sin verdi, uansett verdi skjer for å være - asdf hvis det er alt jeg skrev, eller malan@harvard.edu hvis det er det jeg skrev. Så hvis verdien av skjemaets e felt == ingenting, kjefte på brukeren. Annet hvis verdien av passord-feltet == ingenting, kjefte på brukeren. 

Annet hvis verdien av passord feltet ikke være lik verdien av bekreftelsesfeltet som var et annet element, kjefte på brukeren. Og så til slutt - og dette har også noen nye syntaks av sine egne, men når du har sett det, er det i alle fall litt mer fornuftig - else if form som ID er registrering har en inngang element som heter avtale og det er merket av, gå videre og kjefte på brukeren. Så jeg helt innrømme dette er helt overveldende ved første øyekast. Det er mye nytt syntaks. Men alle jQuery følger disse typer mønstre. Og ærlig, jeg visste ikke engang at dette eksisterte før for noen minutter siden. Jeg googlet "Hvordan sjekker du om en er merket i jQuery?" og dette er syntaksen, fordi det er forskjellige måter å gjøre det med faktiske rå JavaScript-kode. Så som den aller første siden av oppgavesettet 7 understreker, pset 7 er svært mye en øvelse i bootstrapping selv hvor vi har gitt, forhåpentligvis, et konseptuelt rammeverk som å takle pset. 

Men som ofte er tilfellet med webdesign, er det opp til deg virkelig å rote rundt, innlemme kodebiter og eksempler fra nettet så lenge du sitere dem I henhold til vilkårene på den første arket, og innse at det å lære HTML, CSS, JavaScript og selv SQL er egentlig ment å være dette at-home trening som vi begynner å ta disse trening hjul av. Og innser for det er så mange flere ting du kan gjøre med en nettleser. Innsiden av de fleste av disse elementene er det andre ting som kalles hendelseshåndterere. Og selv om vi bare så på de kalt onsubmit og onready, du kan gjøre ting som onkeydown, onkeyup, liker når brukeren berører en tast, kan du lytte til det og oppover. Gmail har hurtigtaster. Hvordan implementere Google hurtigtaster som C for komponere? De lytter til arrangementer, som de kalles, som onkeypress eller onkeyup og onkeydown. Hvis du noen gang har ligget musen over noen menyvalg og plutselig, voila, vises en meny eller grafikken skifter farge, hvordan gjør de det? Snarere enn å lytte til onready eller onsubmit, du lytter til onmouseover eller onmouseout. 

Så kort sagt, med disse svært enkle grunnleggende at vi har begynt å skrape i overflaten i dag og vi vil dykke i ytterligere til onsdag, du har i økende grad makt til å gjennomføre den slags ting som du allerede er kjent med. Så la oss avslutte det, og vi vil fortsette dette på onsdag. 

[CS50.TV]