DAVID J. MALAN: Så vi er tilbake. Så høyt nivå Temaet i øyeblikket nå er teknologi stabler, som ikke er et spesielt teknisk term, det er mer av en fange alle for alle antall kombinasjoner av teknologier som du kan bruke til å løse problemer. Og kanskje den mest passende måte å starte ville være å se på språk siden Jeg fortsetter å lire av en hel haug og mest alle i rommet har sannsynligvis hørt av minst ett. 

Og så hvorfor ikke vi prøve å skille what-- skille disse språkene og snakke kort om når du vil velge en over den andre, hvordan de er slags fundamentalt forskjellige, og særlig når du chatter med ingeniører, eller prøver å bestemme hvem du skal leie, eller hva implementering Forslaget til greenlight, hvordan ville du faktisk gjøre slike avgjørelser. 

Så la oss bare skrangle noen ting av. Av språkene folk har hørt om, hva som kommer til tankene? C. OK. OK, C ++. Hva er det? 

PUBLIKUM: Python. 

DAVID J. MALAN: Python. Utmerket. Hva annet? Visual Basic. Jeg hørte Java. Visual Basic-- a.k.a. VB. Java. NET, som er mer av en fange alle for hva som er normalt C # som språk i spørsmålet. Og la meg nevne det. Så vi vil komme tilbake til det. Unnskyld? Beklager? 

PUBLIKUM: SQL. DAVID J. MALAN: Ripe? PUBLIKUM: SQL. DAVID J. MALAN: Oh, SQL. OK. SQL. Så får vi komme tilbake til at-- faktisk, det er bra-- etter pause også. Hva annet? 

PUBLIKUM: Oracle. 

DAVID J. MALAN: So Oracle, ikke et språk. Egentlig ville de bruke SQL også. Så la oss sette det etter pause også. Og sorry, noe over her? PUBLIKUM: Mathematica. DAVID J. MALAN: Mathematica? Ok sikkert. Og MATLAB er slags på det noen ganger. 

PUBLIKUM: R. 

DAVID J. MALAN: R. La oss gå over her. Fortran. Ja visst. Eldre skolen. Fortran. COBOL. Jeg skal kaste ut BASIC. BASIC. Noen-- 

PUBLIKUM: MATLAB? DAVID J. MALAN: MATLAB. Oh, slå deg til det. Hva som helst? Jeg kan tenke meg et par andre. Jeg kan tenke på noen andre. Og hva var den siste? 

PUBLIKUM: ASP. 

DAVID J. MALAN: ASP? Yeah. Active Server Pages. Som vanligvis ville falle under andre språk, noen ganger C #, så la oss la det ut. Men vi vil komme tilbake til dette for rammer og slikt. Alt annet? PHP er populært. Ruby er en annen. Javascript, for ikke å bli forvirret med Java, er en annen. Det er litt mye. 

Så det kan være absolutt overveldende, som om listen ikke er allerede bare å begynne å vite hvor du skal begynne. Og så heldigvis, la oss nærme seg dette fra noen vinkler. Først, la oss prøve å kategorisere i det minste noen av disse språkene i to brede skuffer, som minner om samtalen vi hadde før pause, hvor vi snakket om kompilering, og kildekoden, og maskinkode, fordi det er ikke slik alle språk fungerer. Så vi vil plukke ut noen få eksempler of-- eller mot examples-- til denne modellen. 

Og så, hvorfor gjør ikke vi snakke om programmene at disse språkene er vanligvis brukt for. Og ærlig talt, selv om Dette er en ganske lang liste, det er bare en undergruppe av denne listen som du vanligvis trekke fra disse dager å løse problemer. Enkelte språk er nyere enn andre. Enkelte språk er mer populære enn andre. Så det er ikke som du har slik en overveldende oppgave før du når du bestemmer blant disse ulike språk. 

Så la oss gjøre dette. Vi hadde tidligere, kildekode, og da vi hadde maskinkode. Uff. Skrive feil ord. Maskinkode. Og vi hadde noen prosess i midten called-- yeah, kompilatoren. Så kompilatoren. 

Og hva maskinkode faktisk kjører på i enden kommer til å være den faktiske CPU. Med andre ord, etter maskinkode, jeg mener de laveste Instruksjoner nivå at en CPU faktisk forstår. Addisjon, subtraksjon, flytte, lagre, og operasjoner som det. Og så dette er modellen for hva som er vanligvis kjent som kompilerte språk. Kanskje ikke overraskende. 

Så dette er modellen for kompilerte språk. Men det viser seg at det er en annen klasse av språk kalt tolket languages-- tolket languages-- som er litt annerledes. Du skriver i kildekoden, løpe dem gjennom en tolk, og at tolk er det som kjører på CPU. Med andre ord, hva du gjør ikke Emit er hva, tilsynelatende? Maskinkode. De nuller og enere at CPU selv til slutt forstår. 

Så i denne første versjonen og språk som C, som vi så, du skrive i kildekoden som er litt uforståelige, men minst det er slags engelsk-lignende og det er minst lesbar når du blir vant til det. Du kjører den gjennom en kompilator og ut du får, til slutt, nuller og enere. 

At en overforenkling. Det er noen andre trinn i der. Faktisk, hvis du noen gang har hørt begrepet "assembly" det er ett trinn før nuller og enere. At en litt mer lesbar, men fortsatt ganske uforståelige. Og så det er mellomtrinn som faktisk skjer her. Men produksjonen, til slutt, er disse nuller og enere. 

Men i tolkes verden, hvor du har språk som er tolket språk, du faktisk hoppe over dette trinnet. Med andre ord, når du skriver et programmet, du bare umiddelbart kjøre den. Du trenger ikke kompilere den og deretter kjøre den, som jeg gjorde før. Du bare skrive det og kjøre det. Og hvis du ønsker å gjøre en rask endring, du gjør en rask endring, og kjør det. Så det er ingen mellomtrinn her. 

Nå, for det programmet jeg skrev tidligere, som var denne "Hello World" program, du kanskje rimelig wonder-- eller med rimelighet kunne state-- det var ikke den tiden tidkrevende å kompilere programmet mitt. Det ser ut til å ha gjort det akkurat sånn. Og det er grafisk versjoner av kompilatorer. Jeg bruker en veldig uforståelige versjon, men du kunne treffe en avspillingsknapp og det ville faktisk gjøre kompilering for deg. Jeg har samlet programmet og deretter igjen, for å kjøre den, jeg bare gjøre dette. Og det utganger til venstre der, "Hello!" Det ser ikke ut alt det tunge. Men når programmene er mer enn bare en, to, tre, fire, fem linjer lange, kan det ta langt flere sekunder å kompilere. Noen ganger med minutter eller ganske mye tid å kompilere. Tross alt, noen av Verdens største produkter er ting som operativsystemer, Microsoft Word, Microsoft Excel, som kan være flere hundre tusen eller til og med millioner av linjer med kode lange, og de som ikke gjør det bare øyeblikkelig start. 

Videre på nettet, er det blitt moderne å bruke bare tolket språk, delvis fordi du kan gjøre en endring som utvikleren og så bare umiddelbart på nytt skjermbildet og umiddelbart se resultatet. Og så HTML, mens ikke et programmeringsspråk, er et språk som er tolket. Og vi så at samme effekt i går. Du bare laste siden på nytt etter at en endring i Cloud9 og-- voila-- du ser en ny resultat. 

Så hva er forskjellen her? I HTML, husker, hadde vi åpne HTML, åpen hode, åpen tittel, nær tittelen, nær hodet, åpent legeme, og så videre. Vi hadde alle disse kodene som vi ganske mye er sagt, fortelle leseren hva de skal gjøre. Hei nettleser, her kommer en HTML-side. Hei nettleser, her kommer den tittelen. Hei nettleser, her kommer noen teksten som skal være fet. Og så forteller det motsatte. Hei leseren, det er det for fet skrift tekst. Hei nettleser, det er det for kroppen. Og så videre. 

Og så hva er en nettleser? En nettleser er bare en tolk. Det er et program som noen liker Microsoft eller Google har skrevet, hvis formål i livet er å lese et språk, kjent som HTML, og tolke den. Topp til bunn, venstre til høyre. Og helst nettleseren ser åpent brakett, tittel, tett brakett, det skal tolke det som betyr, oh, at betyr at jeg bør sette disse ordene måte her oppe på toppen av nettleseren. 

Så det bare gjør hva HTML-koden sier. Men det er ingen nuller og enere. Det er ingen samling. Du gjorde ikke det. Nettleseren gjorde det ikke. Det er bare ikke involvert. 

Så i ånden av disse pågående emner, i dag og i går, som synes å være en flott funksjon. Du sparer koden og deretter bare kjøre den eller tolke den. Det finnes ingen mellomliggende trinn. Sikkert er det en kostnad? Kan ikke alle være oppsider. Så hva kan det koste være? 

PUBLIKUM: Space. 

DAVID J. MALAN: Space. Så sikker. I den kompilerte verden, må du ikke bare den originale kildekoden, du er også å skape og da antagelig spare maskinen code-- den nuller og ones-- og det er kom til å ta opp en viss mengde plass. Absolutt. Så det koster deg mer plass. Ja? 

Målgruppe: Nettlesere kanskje tolke annerledes. 

DAVID J. Malan: nettlesere kan tolke det annerledes. Det er sant. Men jeg er ikke sikker på at jeg komfortabel hevde det er fordi det er tolket. Det er mer bare fordi det er en implementering av et språk som selv har uklarheter. Så la oss ikke helt bekrefte at en, men god anelse. Hva annet kan den prisen? Andrew? 

PUBLIKUM: Du kombinerer to trinn, slik at du derfor har økt kompleksitet i tillegg. 

DAVID J. MALAN: The complex-- økningen i kompleksitet der? For hvem? 

PUBLIKUM: Så, i tolk trinn, du kombinere tolk og kompilator for bare fører opp to-- 

DAVID J. MALAN: Ah, OK. Ironisk nok, er det sannsynligvis en liten enklere å gjennomføre tolk, selv om det ville synes å avkastning oppsider av dette lettere. Så muligens sant. Men den slags kommer an på, jeg vil si, på det språket og om hvordan de gikk om å implementere det. Det kan være mye mer kompleksitet, faktisk, i kompilatoren, bare fordi du har å gå fra noe så høyt nivå til noe så lavt nivå. Men en god tanke. 

Så sagt på en annen måte, en kompilert program, når den er slått inn i disse nuller og enere, ender opp i språket at CPU taler, mens det på denne siden av verden, programmet du har skrevet, koden du har skrevet, faktisk aldri blir konvertert inn i selve språket datamaskinen taler. De nuller og enere. Det forblir i den opprinnelige, mer menneskelig vennlig, mer lesbar språk. Så hva kan være konsekvensen der, ikke hvis du gjør faktisk bry konvertere Programmet til den aller språk at den underliggende data taler? 

PUBLIKUM: Might ikke forstå noe? 

DAVID J. MALAN: Might ikke forstår noe. Og det kan claim-- hvis den ikke forsto noe, det er en feil eller mangel av funksjonen i tolk. Slik det vil være mer av en feil enn en kostnad. 

PUBLIKUM: Du har tilgang til kildekoden? DAVID J. MALAN: Det er en god en. Så en ulempe her er du ville synes å ha tilgang. Du, sluttbrukeren, kan synes å har tilgang til kildekoden. Og det er ikke alltid sant. Men det er sant i tilfelle av Javascript, som vi skal se på etter pause i dag, noe som er et tolket programmeringsspråk som du skriver i kildekoden. 

Men at kildekoden blir overført fra serveren til nettleseren og kjører i den menneskelige nettleser. Så her hun kunne bare åpne vindu, som jeg har gjort i Chrome, og ser på det, så vi oss selv kikket på i går med Google. Det kan se litt uforståelig, men det er der. Så det er absolutt en pris som er betalt. PUBLIKUM: Ytelse hit? DAVID J. MALAN: Ja. Og det er den andre biggie. Det er en forestilling hit. Fordi du har denne midt mann, som selv er et program, mellom dere og CPU, i motsetning å bare mate disse rå nuller og enere i CPU, det er en ytelse hit som du ta med et tolket språk. Slik at, vilkårlig, et program som kan ta ett sekund å kjøre på en datamaskin eller en minutt å kjøre på en datamaskin her, kan ta 10 sekunder eller 10 minutter å kjøre på en datamaskin her. Det er generelt ikke til å være det mye av en difference-- faktor på 10-- fordi det er optimaliseringer du kan gjøre. Men det er nesten alltid tregere. Nå baksiden til denne bekymringen er det, vel datamaskiner, hver 12 til 18 months-- henhold til Moores lov, så å speak-- er bare å få raskere og raskere. Jeg har mer og mer diskplass. Jeg har mer og mer RAM. Som virkelig bryr seg? 

Og det er litt av en rimelig argument. Faktisk er en av grunnene Derfor kan vi tolerere tregere tolket språk er fordi vi mennesker egentlig ikke merke. Datamaskinene har fått bare så utrolig fort. Mens tilbake i dag, spesielt når maskinvaren var mye mer begrenset, du hadde mindre av alt, Det var mye dyrere slik at alt koster mer, vel da du virkelig ønsket å presse ut så mye ytelse som du kunne. Men det kreves skriftlig et lavere nivå, om du vil, med et kompilert språk. 

Så du tar denne ytelsen hit. Men generelt, oppsider ser ut til å være verdt det i disse dager. Vel, med unntak av åndsverk problemet. Den slags lesbarhet av koden, vil vi komme tilbake til når vi ser på Javascript. 

Så la oss prøve å kategorisere minst et par av disse. Så blant de kompilerte språk, vi ville ha C, C ++, ganske, sorta, Java, selv om det er litt av et unntak, for grunnene til at jeg skal vise deg i bare et øyeblikk. C # ville være på denne listen. Vi skal se på mer på bare de mer moderne språk. Greit. Og det virker som mange der. Mens på denne siden av gjerdet, vi kan ha Javascript, og Python, og PHP og Ruby. Og er det nok for de mer nyeste bildene? Det føles nok for nå. OK. Og så dot dot dot, Siden listen er endeløs. 

Og faktisk, hvis vi bare vil få en følelse av dette-- Wikipedia, kompilerte språk. Jeg gjetter vi kan få en langt mer uttømmende liste. Så her vi går. Så her er en mye mer uttømmende liste. Og jeg håpet noen ville gjette D som et språk fordi det også eksisterer, men de stoppet på D det ville virke. Selv om det kan faktisk være en E. 

Oh, faktisk, bør dette være på listen i disse dager. Swift er faktisk en språk som Apple oppfant som nå brukes i økende grad så, i iPhone utvikling. Men vi vil komme tilbake til at med vår diskusjon av mobil i bare litt også. Så Swift også. 

Og så hvis vi går til tolket language-- tolket language-- så her er en enda lengre liste også. Så hvis du bare google og ser på Wikipedia for disse, vil du se alle slags språk. Men hensikten er, for i dag egentlig, bare koker ned til kanskje dette Spørsmålet om intellektuell eiendom og lesbarhet av sluttbrukeren og for å ytelse, er en annen sak også. 

Så blant disse språkene, la meg se om vi kan gi deg bare noen eksempler språk. Vi ønsker ikke å gå gjennom alle språkene det uendelige. Har du noen gang lurt på hva en bestemt språk ser ut? Vi fikk se et øyeblikk siden. Hvorfor kan ikke vi ta et par av funksjonen forespørsler. Hvem ønsker å se hva annet språk ser ut? Yeah. 

PUBLIKUM: Java. 

DAVID J. MALAN: Java. Greit. Så la oss gå til Java. Og bare for å gi deg en sample-- vi kunne skrive alle disse ut, men det vil være raskere bare se på andres eksempelkode. Greit. Så er dette et godt eksempel? Uff. OK. Så her er Java-versjonen av program jeg skrev tidligere, "Hello World". 

Så Java, vil du ofte se søkeordet "klasse". Da vil du se noen navn etter det. Du vil se klammeparentes som vi så før, og noen ganger går de på samme linje, også andre linjer, det er litt av en personlig avgjørelse. Du vil se søkeord som "Offentlig", "statisk", "ugyldig." Men vi fikk se "main". "Main" er vanligvis navnet på standardfunksjon eller standard mengde koder som blir drevet i et program. 

"String". Hva var det vi mener med streng tidligere? Jeg brukte den slags tilfeldig. En streng er hva? Et ord. Det er som en sekvens av tegn. Individuelle tegn, tilbake til rygg mot rygg, vanligvis i en matrise, som vi har diskutert. Og faktisk, se denne syntaksen her, de to hakeparenteser? Det betyr, hei datamaskin, her kommer en rekke strenger. Den hakeparentes notasjon er vanligvis brukt for å betegne at. Og så kan du sannsynligvis ta en guess-- hva betyr dette uthevet mengde koder sannsynligvis gjøre? 

PUBLIKUM: Utgangen? 

DAVID J. MALAN: Ja. Den skriver noe til skjermen. Så "system" er en slags en referanse til datamaskinen. "Out" betyr at datamaskinen er utgang eller skjermen. Så "System.out.print ln" betyr sannsynligvis? "Ln". Skriv linje som programmerere som til tilsynelatende stave noen ord ut i sin helhet og ta snarveier med andre ord. Men "ln" er linje, så print linje. Så det skrives ut "Hello Verden! "Etterfulgt av en ny linje. 

Så det er det. Men Java er hva de vil call objektorientert. Og ja, bare for å gi en par andre definisjoner der som du kanskje Se, generelt, der finnes mange forskjellige typer av språk, men den vanligste er prosessuelle eller imperative språk. Det er funksjonell språk, som ikke bety at andre er ikke-funksjonelle. Og så er det objektorienterte språk. Og dette er kanskje den beste kategorisering av de fleste språk at du noen gang ville velge for sortering av en typisk kommersielt prosjekt. 

Dette ville være for mye av, Jeg tror, ​​av en rotte hull å gå ned, for å prøve å forklare de forskjellige forskjeller. Men språk vi har sett og dermed far-- C er en prosessuell eller en imperative språk. Flere nylig oppfunnet språk pleier å være, beklager, objekt-orientert, noe som betyr de har andre egenskaper til dem. Kan jeg forklare det på denne måten? La oss ikke engang gå ned dit. 

Objektorienterte midler du kan implement-- du kan modellere den virkelige verden litt mer effektivt. Menneskeheten, over tid, har funnet ut, wow, det ville være fint om mitt språk hadde denne funksjonen, eller at funksjonen. Og det er derfor vi har så mange språk i verden. Fornuftige mennesker, smart folk, enig eller uenig og alltid liksom kommer sammen på utvikle nye språk alle sammen. 

Sak i punkt. Apple oppfant Swift i håp om antagelig senke baren til iPhone utvikling, fordi den forrige language-- heter Objective-C, noe som kan også være på vår liste her-- var mye mer uforståelige og mye vanskeligere å bryte ens sinn rundt. Og som programmering blir uten tvil mer tilgjengelig og mer generelt vedtatt av folk selv mindre teknisk, den goal-- det er en veldig tapper mål å prøve å senke barrieren for å komme ved å gjøre språkene selv lettere å komme i gang med, men ikke mindre kraftig nødvendigvis. 

Og ett annet språk. Hvorfor kan ikke vi ta en titt på noe som Python, noe som er veldig mye på moten i disse dager. Python. Prøveprogram. La oss se. "Hello World" språk. La oss gjøre dette. "Hei verden." La oss se om dette gir oss et fint eksempel. OK. Så dette er faktisk like gøy. Så hvis du noen gang google "Hello World", som skjer for å være en av de første programmene noensinne er skrevet i et moderne språk, akkurat som et bevis på konseptet, kan du se alle slags implementasjoner av denne. 

Noen av disse språkene Jeg har ikke engang hørt om. Men du kan see-- la oss gå til Basic, den jeg lærte år siden, delvis. Dette var et morsomt språk fordi du måtte, som programmerer, nummer alle dine linjer. Ikke ulikt det jeg var gjør når jeg skrev pseudokode på den gule dokument tidligere for binære søk, for å søke en telefonbok. 

Og så, hvis du ønsket å gå til en annen linje, du ville bokstavelig talt skriver, gå til 10, eller gå til 20. Og hvis du skriver linjer, de konvensjonen var å gjøre, er denne linjen 10, dette er ledningen 20, er denne linje 30, 40, med ingenting i mellom, og dermed gi deg selv litt rom hvis du bestemmer deg, vent litt, Jeg burde ha lagt noen mer kode et sted. Du hadde fortsatt slags ni sjanser til å presse som i mellom programmet før du måtte manuelt nummerere alt. 

Så dette er litt av hva jeg mener når jeg sier at verden har kommet opp med nye funksjoner. Et sted langs veien noen realisert, gutt dette er dumt. Dette er bare å skape arbeide for programmereren. Slik at han eller hun bare slags inne et nytt lag på toppen av det slik at du ikke trenger å bekymre deg om hvilken linje tall koden er faktisk på. 

Så når kan du velge ett eller annet språk? Vel, hvilke av disse språk vil du pleier å høre om de fleste i din egen verden i disse dager? La oss slippe ned Objective-C også. 

PUBLIKUM: C #. DAVID J. MALAN: C #. Så la meg farge. Har vi vår andre farger eller annet sted? Så C #. Og hva vet du om C #? Noe våren til tankene? 

PUBLIKUM: Det er et programmeringsspråk. DAVID J. MALAN: Det er en programmeringsspråk. OK. Det er sant. Så vi snakker om C #. C # har en tendens til å bli brukt i Windows-miljøer, så hvis du skriver Microsoft-programvare for Windows, er C # svært vanlig, enten det er for desktop programvare, eller selv telefonens programvare på Windows-telefoner, hvis du har hatt dem, eller på nettet selv også. Og faktisk, kanskje Kareem nevnte ASP tidligere? Så det er også disse ting som kalles rammeverk, som vi kan presentere i forlengelsen. Strukturer som ASP. Står for Active Server Pages. Og dette er kode og en metode for programmering som vanligvis gjør det lettere å skrive web-baserte applikasjoner. Med andre ord, det ville være super, super irriterende å skrive et nettsted i språket C som vi har sett før, fordi du må bruke print + F, du må bruke dette søkeordet "Main" og klammeparentes. Mye av uforståelige syntaks og tilnærming til å implementere noe som er nokså komplisert. En nettside. 

Og så andre språk har utviklet seg for å gjøre den slags ting enklere. Og i sin tur, har folk kommet opp med rammer, liksom verktøy som du kan bruke som gjør det enda enklere å skrive websider. Så for eksempel, for å gjøre dette mye mer konkret, la meg åpne opp bare en tekstfil for et øyeblikk. 

Og du kanskje husker i går at vi sa noe liker, er dette en nettside. HTML. Lukk HTML. La meg hoppe over hodet og bare gjøre kroppen her. Anta at jeg ønsket å skrive ikke "Hello World" men "Hei David," hvor David er Navnet på den påloggede brukeren. Hva noe sånt ASP vil gjøre, eller JSP-- som er Java-server pages-- eller hvilket som helst antall av andre rammeverk er de ikke språk, per se. De er akkurat som tilleggsprogramvare som du vil installere i ditt miljø som bare gjør det lettere å programmere. 

Så for eksempel, snarere enn å gjøre noe sånt som "hei, printf (" David ")" eller noe som er slags co-mingling-- hva slags kode vi har sett before-- du ville gjøre noe mye enklere, som "name%." Og så disse rammene, som ASP-- og jeg husker ikke om jeg får syntaksen akkurat for ASP. JSP er en little-- er dette riktig? 

Så med ASP, er denne liksom en spesiell syntaks at noen utviklere har bestemt dette kan hjelpe folk ut. Og jeg kan uttrykke mer konsist plassholdere, for eksempel. Som sette en verdi her, hvor denne verdien navnet ikke N-A-M-E, det er noen verdi lagret der. Så "navn" i denne sammenheng vi vil kalle en variabel. Algebra har variabler som x, og y, og z. Programmerere bruker variabler som er mer beskrivende enn x, y, og z, typisk. Så "navn" vil bokstavelig talt være en slags minne beholder for noe sånt D-A-V-I-D, for mitt navn, eller hvem som helst ellers er logget inn på nettstedet. 

Og så dette er den type stor du får med visse miljøer. Så C # og noe som ASP vil veldig som vanligvis benyttes i et Windows verden, enten for sin desktop programvare eller web server, spesielt hvis serverne er i sving kjører Microsoft Windows og Microsoft IIS-- eller Internet Information Server, hvis jeg får akronym right-- som er Microsofts webserver. 

Så hva andre språk er folk som er kjent med, eller har du hørt om oftere enn ikke? 

PUBLIKUM: Jeg vet at Pythons slag av en populær [hørbar]. DAVID J. MALAN: Veldig populært. Så Python her brukes svært ofte i vitenskapelige applikasjoner eller data vitenskap, hvor du har mye av data som du ønsker å analysere og du vil bruke en programmeringsspråk for det. R kan ofte bli brukt for det også, i en statistisk sammenheng. Men Python har så mange funksjoner innebygd. Så mange ekstra biblioteker, som folk sier. 

Bibliotekene er bare samlinger kode som andre mennesker skrev at du kan bruke slik at du trenger ikke å gjenoppfinne disse hjulene. Og så Python er svært vanlig brukes i datavitenskap applikasjoner. Men det er også veldig vanlig brukes i web-applikasjoner. Du kan implementere en dynamisk nettside ved hjelp av Python. 

Og ved dynamisk nettside, jeg betyr ikke bare statisk innhold som vi opprettet i går, etter bare hardt koding i den latinske teksten og andre slike ting, men heller evnen å logge på, evnen til å kjøpe noe, muligheten til å sjekke ut med handlekurver eller lignende. Alle som krever dynamikk og du trenger noen språk som en av dem. 

PUBLIKUM: Det gjør Python har sin egen forlengelse, ligner liker [hørbar] DAVID J. MALAN: Det gjør. Så i en verden av Python, er Django et svært populært rammeverk for Python. WSGI er en annen mekanisme som er slags forskjellig fra denne men ligner i ånden. Det er en add-on som lar deg å kjøre Python kode på en server. Det er other-- ja. Så vil disse vi kaller rammer. Og det er litt av et misbruk. Dette er mer av en web-server teknologi. Men vi vil holde det enkelt og sette det i denne kolonnen likevel. 

OK. WSGI. WSGI. En annen thing-- og faktisk, la meg flytte det til en egen kolonne, fordi jeg vil kjefte på meg selv for sette dem i samme bøtte. La oss sette dette inn i serveren funksjoner, la oss si. Det er ikke et teknisk begrep. 

Så her kan vi være WSGI. Det er CGI, som er en eldre teknikk for å tjene opp språk som Perl eller PHP, eller noen andre. Igjen, jeg har nevnt disse vilkårene ikke så mye å slags ingrain dem, men slik at hvis du ser dem det er noe du bare google for å lese mer. Det er ingen reell juice til noen av disse tingene. 

Men la oss gå tilbake til språk. Vi snakket om C #, Python. Hva annet kan du bruke for web programmering i disse dager? La oss fokusere på det likevel. 

PUBLIKUM: PHP. DAVID J. MALAN: PHP. Og la oss komme tilbake til den. Så PHP er svært vanlig. PHP har en tendens til å få en dårlig rap. Det startet som et språk implementert av folk som kanskje ikke var nødvendigvis de beste språk designere. Og slik at du kan lese alle slags artikler på nettet om hvor ille PHP er. Og dessverre, dette er en manifestasjon, delvis, av bare de religiøse debatter som bryter ut blant programmerere. Og dette er noe verdt å holde i tankene, fra et forretningsmessig perspektiv, som det er veldig lett for tekniske folk å få alle jobbet opp med sine meninger om visse ting. Og det betyr ikke nødvendigvis at en roping høyest eller med den sterkeste, sinteste mening er riktig. Mange ganger, det virkelig bare spiller ingen rolle. 

Og så folk bare krangler uansett sine egne fordommer eller komfortsoner er. Og så bør du holde det i tankene når du gjør en beslutning, som bare fordi noen sier dette er riktig språk for jobben, som kan være sant, men det også bare kan være den er riktig språk i sin egen dyktighet sett eller comfort zone. Som ikke er dårlig, men du bør innse at det kan være noen sammenheng der. Det er noen objektivt gale uttalelser, som C er feil språk å bruke i disse dager for å gjennomføre nettsteder nesten alltid. Men det er ikke urimelig å si at noen av disse er galt at vi har sirklet så langt. 

PHP har gått gjennom mange versjoner. Så språk tendens til å ha versjon tallene knyttet til dem. PHP er opp til, tror jeg, versjon 7 nå, så det har eksistert i ganske lang tid. Og som språk få nyere, de ofte får nye funksjoner. Men du må være oppmerksom på dette fordi hvis nettstedet har vært implementert i versjon 7 av PHP, men du prøver å kjøre ditt nettsted, eller kanskje du har outsourcet utviklingen av koden din til noen andre, og de post det til deg, eller sende det til deg og de sier her, legg dette på webserveren din, hvis webserveren er noen år outdated-- enten det er din egen server eller en web host-- det kan faktisk ikke kjøre. Så disse er typer ting som noen må være oppmerksom på ved oppgradering et nettsted eller implementere det for første gang. 

Jeg hørte Javascript tidligere. Så Javascript er et interessant man ved at det er vanligvis klientsiden, så vi får se etter pause, noe som betyr at det kjører i brukerens nettleser. Men du kan også kjøre Javascript disse dager ved hjelp av noe som kalles Node.js, der Node.js er en mekanisme for å kjøre Javascript-kode server side, stedet for å bruke Python, eller PHP eller andre slike språk. 

Javascript er spesielt godt egnet for chat programmer og sanntids programmer, mens PHP er ikke en stor språk for å gjennomføre noe som en chat-server, hvor brukerne holde kontakten med det hele tiden. PHP er mer av et besøk meg en gang, får tilbake et resultat og deretter en annen link noen sekunder eller minutter fra nå. Mens Node.js og Javascript kan være brukes mer for vedvarende tilkoblinger. Andre språk som du mistenker blir ofte brukt for web ting? 

PUBLIKUM: Vil jQuery være et rammeverk? 

DAVID J. MALAN: Godt spørsmål. Ingen. Jeg vil kalle jQuery bibliotek, hvor igjen et bibliotek er bare en haug med kode at noen andre har skrevet at generelt løser noen problemer som gjør det forhåpentligvis lettere for deg å gjøre jobben din. Og la meg gjøre ett eksempel på dette i sammenheng med nettet. 

I sammenheng med banen er det dette språket, Javascript, at vi vil se senere, hvor du kan si noe sånt dette-- "Document.getElementById." Og hva gjorde jeg kaller det i går? Først tror jeg, var den unike ID jeg ga til et element som så ut som dette. "P id =" første ">", og da vi hadde som "lorem ipsum", et cetera. Så hvis jeg skulle skrive et program i Javascript for å liksom manipulere, endre websider som vi lekte med i går, Jeg vil bruke denne uthevede linjen med kode å få den aktuelle HTML- fra min side, det bestemt node, som vi kaller det. 

Men i jQuery, i stedet for å skrive dette, noe som er rå Javascript code-- bare ut av boksen, det er hvordan du skrive it ville du i stedet bare si, "#først." Det er tilsvarende. Og så bare basert på dette svært uforståelige eksempel, hva kanskje er argumentet for å bruke jQuery? Hvorfor skulle en utvikler bruke et bibliotek som jQuery, basert på denne isolerte eksempel kanskje? 

PUBLIKUM: Mindre kode. 

DAVID J. MALAN: Ja. Det er mindre kode. Det er bare raskere å skrive. Motstykket er at det ser mer skremmende. Du kan egentlig ikke lese det venstre til høyre. Faktisk, fordi det er det meste tegnsetting nå i stedet for faktiske ord, Jeg kan slags antyde at "Document.getElementById" får et element fra dokumentet ved sin ID. Jeg kan egentlig bruke noe slikt huskeregler fra denne tingen her. 

Så det er en trade off. Det er et raffinement som kommer ofte med å bruke bibliotekene, spesielt som jQuery. Men realiteten er jQuery har form av å bli en de facto standard, slik at nesten alle disse dager som skriver Javascript-kode bruker jQuery eller noe liker det, og ikke lenger skriver slike en detaljert uttrykk som dette, fordi igjen, menneskeheten har lært, wow, det var liksom en tapt mulighet å gjøre livet enklere. Så mennesker gjøre livet enklere. Godt spørsmål. 

Andre språk å vurdere. Jeg vil si blant denne Listen Ruby er ganske populær. Og så i en verden av Ruby, det er et rammeverk kalt Rails, som er svært populær. Så Ruby on Rails er en brukte uttrykk. Også i denne verden, la meg sirkel Java for web ting, hvor i verden av Java du kan ha JSP, eller Java Servlets, som er en felles teknologi. Og dette er bare igjen måter å bruke at språket i en servermiljø. 

Så hva betyr dette? Hvis du har en fysisk server, ville du bokstavelig talt laste ned serverprogrammet og installere det på en slik måte at du har støtte for en av disse rammene, som du kan i sin tur bruke ett eller flere av disse språkene. Og i virkeligheten, hvis du registrerer deg for som en web host eller noen av skyen tjenestene vi snakket om i går, ofte ting kommer bare med maskinens konfigurasjon for deg. Du trenger ikke å sette dette opp manuelt. Men hvis du gjorde, dette er hvor den rollen av system administrator, så å si, kommer inn i bildet. Han eller hun vil faktisk gjøre denne typen ting for deg, eller den såkalte webmaster vil ofte gjøre dette for deg. Greit. Eventuelle spørsmål om noen av disse her? Eller noen muligheter på alt for å spørre om språk? Rammeverk? Så la meg presentere bare ett annet bibliotek det er også svært vanlig i disse dager. Denne listen kunne gå på uendelig. 

Og dette biblioteket er slags begynner å falle i unåde. Det har eksistert. Det ble popularisert av Twitter for noen tid. Og nå mange nettsteder, mange utviklere bruker den. Men nye ting kommer ut og kommer sammen. Men la meg bare gi deg en følelse av på hvilken måte det å bruke et bibliotek. Så igjen, er Javascript et svært populært språk. CSS, eller Cascading Style Sheets, vi snakket om i går. Det også, er allestedsnærværende. Ingen som gjør en nettside i dag uten å bruke HTML og CSS minimal. Men det er ikke alltid lett å gjøre visse ting. 

Og så la meg gå til getbootstrap.com. Uff. Det er ikke hvordan vi stave. Getbootstrap.com, som kommer til å føre meg til destinasjonssiden for dette biblioteket. Så de sjenerøst kaller seg et rammeverk som er slags form for rettferdig, men jeg vil fortsatt kalle det mer av et bibliotek enn et rammeverk. Men dette er bare arguable semantikk. La meg gå til deres CSS-kategorien og la meg gå til noe som dette. 

Så husker hva våre skjemaer så som i går på Cloud9? Det var ganske stygg. Old school knapper. Jeg tror på knappen var grå av misligholde. Og alt var virkelig formatert ganske messily. Så hvis du vil at webskjemaer for å se litt nicer-- la meg zoome inn her. 

Og bedre jeg egentlig bare mener veldig nitpicky estetikk. Så legger merke til hvordan e-boksen har det en avrundet rektangulære hjørner til det. Så det er litt renere der. Legg merke til at ordet e-post er det før jeg begynner å skrive og deretter går det unna. Så det er en fin liten funksjon. Legg merke til hvordan ting er slags glødende pent, som noe av dette du får gratis fra nettleseren din, men noe av dette er også biblioteker kode som andre mennesker har skrevet som gir deg dette. 

Noe sånt som dette gir meg passordet mitt. Denne knappen er litt mer sexy enn den misligholde. Veldig mye på moten akkurat nå. Helt siden iOS 7 eller så, Verden har fått veldig flat, mens verden før hadde massevis av skygger, mye refleksjoner på ikoner. Mye som i klær verden, det er motetrender som kommer og går. Nå er alt flatt på telefonen. 

Faktisk knappene på iPhone er nå bare blå koblinger. Det er ikke ofte selv sirkulære knapper. Så dette er bare ting som går inn og ut av moten, og så dette er hvordan du kan lage et mer moderne utseende webskjema. Knapper. Så Bootstrap har mange pene knapper. Så hvis du vil blå knapper, grønne knapper, blå, oransje, rød. Bootstrap gjør det lettere å gjøre disse tingene. Dette er den slags ting at du kan absolutt har gjort i går med CSS og med HTML, men det er bare en smerte i nakken. Og så i stedet, hva Bootstrap ville har du gjør er noe som dette. 

Hvis du ønsker en button-- viser seg at dette er en HTML-tag vi ikke bruke yesterday-- og du vil den skal se sånn grønn knapp, du bokstavelig talt bare gi den en klasse, som vi gjorde snakker om i går, av "btn btn-suksess." 

Hvorfor disse ordene? Twitter, forfatterne av Bootstrap, kom opp med disse ordene. De kunne ha kalt dem alt de vil. Men hva du får nå er noen andre på Twitter, i dette tilfellet, har funnet ut hvordan du gjør en knappen ser fin og ren og grønn. De pakket opp denne funksjonaliteten i en CSS-klasse, kalt "btn" og "btn-suksess", slik at noen av oss kan nå bruke den uten engang å tenke på den. Så de har abstrahert bort oppfatningen av en grønn knapp slik at vi ikke trenger å bry seg om implementere det selv. Vi kan faktisk fokusere på å implementere ting av interesse for oss. 

Hvis vi bla nedover her. Feilmeldinger på skjermen. Noen ganger du vil ha en liten melding skal vises på toppen av nettleseren. Enhver av oss kunne gjøre dette med noen innsats, etter gårsdagens leksjon, men hvorfor skulle du bry deg? Det er slik en uinteressant estetisk detalj. La oss stå på skuldrene til Bootstrap og la dem gi oss ting som dette, hvor vi bokstavelig talt, for å få en rød boks, må bare gjøre et avsnitt tag med en klasse of-- beklager. "Bg-fare" ville gi oss dette rødlig boksen i stedet. Nå la oss gå til mer interessante ting. Hvis jeg går tilbake til toppen av denne siden og gå til komponenter, nå verden blir mer interessant. For eksempel, er meget vanlig drop down menyer som dette. Dette ville være en absolutt smerte å gjennomføre. Og det var ikke så lenge siden at vi programmerere måtte gjennomføre disse typer menyer fra scratch. 

Men det er en slik felles paradigme at bibliotekene som Bootstrap bare gi deg muligheten til å lage en nedtrekksmenyen langt, langt lettere. Det er ingen måte å gjøre det, men hvis jeg leser dokumentasjonen Jeg ville se det, OK, jeg skal bruke denne HTML hvis jeg vil ha en rullegardinmeny som oppfører seg sånn. 

Tilsvarende, la oss gå til knappen falle ned. Så dette er enda mer avansert. Hvis jeg vil at dette skal se ut som en knapp men den lille trekanten betyr Jeg skal klikke på det og få denne menyen, dette er å bruke et språk som kalles Javascript. Og vi kan alle gjennomføre dette i Javascript. Men igjen, er dette et hjul du ikke ønsker å gjenoppfinne. Du ønsker bare å ta den av sokkelen bibliotek for dette. 

La oss gå til noe som fremdriftsindikatorer. Så noe som dette er litt kult. Hvis du noensinne har sett en fremgang bar beveger seg over skjermen, implementering som ofte er bare en spinnende ikon. Faktisk, akkurat som en side, la meg gå til Ajax-- hva er det? Ajax info? Uff. Ajaxinfo. La meg huske adressen. Det vi går. 

Så hvis du noen gang har sett noen animasjon mens siden lastes, eller tenker, eller lagrer, eller skape noe, du kan se slike animasjoner som disse. Så la oss se på noe som dette her, og la oss velge en forgrunnsfarge av grønn, som føles slags vennlig. Kan jeg klikker på denne? Kom en. OK. Vi skal bare gå med rød fordi det er det vi får. Så her har vi det. 

Så hvis du noen gang har sett dette på en skjerm, hvor plutselig den vises, og deretter plutselig forsvinner, hva er det som er å gjennomføre det? Vel, dette er bare en GIF. G-I-F. Og dette er en animert fil, som nettopp betyr det er som en gammel skole tegneserie. Det er bare en haug med forskjellige rammer som skal [stamming] og bare gjenta. Og det er å skape illusjon av bevegelse. 

Så så snart en side er ferdig lasting eller gjøre noe, hva gjør en programmerer gjøre? Vel, han eller hun bare skjuler dette bildet. Så alt en fremdriftslinje er er snill av som en film du ser på. Du er liksom uvitende om det faktum at det ikke er faktisk gjør noe, det er bare å flytte. 

Og så, når det er gjort framskritt, de bare skjule det eller slå den av. Og det er all magi det som skjer der. Bootstrap gir deg noe litt mer avansert, hvor du faktisk kan se en prosentandel som det går, men det er også bare en slags av en enkel animasjon. 

La oss se på noen endelige mer komplekse eksempler her. Noe sånt som en modal. Er det noen som vet hva en modal er? Et modalt vindu er vanligvis en som er ment å ta kontroll over forgrunnen og hindre deg fra å gjøre noe annet. Den slags tvinger brukeren hensyn til midten av skjermen, låse dem ut, typisk av alt annet. 

Så hvis jeg starter denne demoen, den Skjermen vil generelt bli grå. Vel, hvordan gjør vi det grå? Vel, vi sannsynligvis bare endret bakgrunnsfargen som vi gjorde i går eller noe sånt. Kanskje det er et overlegg det semi-transparent. Og nå legger merke til at du kan gjøre fancy ting som dette. Så hvis du noen gang klikker på en knapp og vil ha en liten pop ut til å vises, du kan gjøre det. Og så hvem bryr seg om alle-- ja? 

PUBLIKUM: Så med Bootstrap, for å få det innarbeidet, er det så enkelt som som i går vi gjorde CSS-stiler siden? DAVID J. MALAN: Ja. Virkelig godt spørsmål. La meg gå til Komme i gang. Og ja. Alt du trenger å gjøre for å bruk Bootstrap er egentlig kopiere og lime inn disse tre lange linjer av kode i toppen av din egen web page-- hodet på page-- og du er oppe og går. Og det er forskjellige måter å gjøre det, ville men dette være den enkleste. 

Så hva er nyttig om alt dette? Vel, hvis du ikke er så mye den iverksetter av et nettsted men du prøver å designe den, eller du ønsker å gi noen med wire ramme diagrammer, så å si, eller bare kunstnerens gjengivelser av hva du ønsker å gjøre, jeg, til denne dag, vil ofte gå til et nettsted som Bootstrap, der hvis jeg ønsker å implementere something-- som nylig på campus vi ønsket å gjennomføre en web-basert verktøy for å navigere Harvards kurskatalogen noe som gjør det lettere for studenter å bla gjennom kurs og legge kurs til handleliste, så å si, til slags bestemme hva de ønsket å ta. 

Jeg prøvde å forestille seg for meg selv, hva ingrediensene ville vi vil bruke til å bygge dette? Hva ville brukergrensesnittet bli? Og bare se gjennom et område som denne eller andre slike biblioteksider, du kan få inspirasjon, fordi wow, Jeg kan bruke denne widgeten, og denne widgeten, og denne widgeten. Og så virkelig hva programmereren starter å gjøre, spesielt i disse dager i denne mer moderne verden av web-programmering, er programmering er stadig om kabling ting sammen. Sorter med å ta dette hyllevare, dette hyllevare, dette hyllevare, og du er den smarte ett for å koble alle disse prikker men til slutt bygge noe med det igjen står på skuldrene til andre, slik at du ikke tilbringe en måned implementere en dum rullegardinmenyen som faktisk er vanskelig å gjøre hvis du vil den skal fungere på Chrome, og IE og Firefox, og eventuelle rekke andre nettlesere. Dette er grunnen til at det er denne rike kommersielle og åpen kildekode bransjen også. 

PUBLIKUM: Så betyr Bootstrap får oppdatert og du må deretter oppdatere koblingene? 

DAVID J. MALAN: Det gjør. Vel, ja, det gjør det. Bootstrap er for tiden på versjon 3.3.6. Og generelt hva du ville do-- dette er faktisk verdt å nevne. Det er det som er generelt kjent som en semantisk versjons Systemet i verden. Ikke alle gjør dette. 

Men hvis du har sett versjonsnumre som er på formen x.y.z-- så for eksempel, den første versjonen av et program kan være 1.0.0. Eller hvis det er veldig, veldig beta, eller til og med alfa-status, det vil si bruk på egen risiko, er det ikke virkelig klar for prime time, du kan selv starte 0.0.1 eller noe slikt betegnelse. Men hvis programvaren starter på versjon 1.0, eller ekvivalent 1.0.0, Vanligvis er det vanlig disse days-- men ikke omnipresent-- er hvis et selskap eller en individuelle programmerer fikser noen feil i noen stykke programvare som virkelig var en feil, hvis korreksjon bør ikke innvirkning på deg på alle-- det ikke endrer programmets oppførsel, det bare løser noe som ikke virket properly-- du ville vanligvis oppdaterer z-verdien der. Hvilket betyr noen som Kareem kan bare gå inn i hans nettside, blindt endrer versjonsnummeret fra 1.0.0 til 1.0.1, lagre det, sende den, og i teorien, ikke trenger å redd for at han bare brutt sin nettside på grunn av noen mangel på funksjonalitet, fordi noe annet blakk. 

I mellomtiden, hvis jeg programmerer eller noen selskap var å gjøre noen betydelige endring som legger til funksjonalitet, Jeg kan oppdatere oss til 1.1.0 fordi jeg er faktisk endre oppførselen til biblioteket. Jeg gir deg kanskje mer funksjonalitet. Til slutt, hvis jeg skulle faktisk fundamentalt endre programvaren så mye at det vil bryte mange brukere nettsteder eller applikasjoner, da er jeg nødt til, i denne modellen, til oppgradere hovedversjonsnummeret også, som er et brudd forandring. Med andre ord, kan jeg ha avviklet støtte for de dråpe gardinmenyen. Så hvis du oppgraderer til 2.0, halv ditt nettsted kan slutte å fungere. Og dette er liksom et signal til samfunnet om hva som er involvert i å gjøre en oppgradering. En god mulighet til å øke. Andre spørsmål? Greit. Vel la oss ta en titt på en endelig Temaet i dette segmentet av programmering av teknologi stabler, nemlig relatert til mobil. 

Så i en verden av mobiltelefoner i dag du Opptaktene og iPads, og overflater, og alle slike av devices-- du har en rekke valg når det gjelder implementering et program eller en nettside for kundens mobile enheter. Så bare å oppgi åpenbare, kanskje i disse dager, hva er plattformer til utvikle for i mobilen? Hvilke enheter kan det være lurt å støtte med din app eller nettside? 

PUBLIKUM: Apple. DAVID J. MALAN: OK. Så Apple-enheter. Så det betyr at iPhone, og at betyr iPad, og kanskje til og med iPod. Hva annet? Olivier? 

PUBLIKUM: Android. 

DAVID J. MALAN: Android. OK. Så Android-telefoner, Android tabletter, Android Market er enda Messier because-- og selv Apple blir rotete. Mens det var en gang iPhone var en viss størrelse, og iPad var en viss størrelse, og iPod var en viss størrelse, nå vi har iPad Mini, og den tynne seg, og iPhone 6 Plus og 6. Det blir et rot. Det blir Android verden. 

Og jeg sier dette med slags rullende mine øyne fordi fra en utviklers perspektiv, er det en smerte i nakke når du trenger ikke Steve Jobs ' visjon om absolutt kontroll i løpet av alle disse spesifikasjonene. Apple gjør likevel fordi de er de som bygger maskinvaren. Men det er en fin ting, hvis Jeg er en programvareutvikler, å bare vite at min iPhone er alltid kommer å være så stor fordi det betyr at jeg alltid vet hvor mye skjermen eiendomsmegling jeg har. Så hvis jeg ønsker å sette et ikon i øvre venstre hjørne, det kommer til å være i nøyaktig samme plassere på hver enkelt kundes enhet. 

Men i en verden av iPhone 6s og iPhone 6 Plusser og i verden av Android telefoner, det er over hele kartet. Og så det gjør det vanskeligere å programmere ting, spesielt brukergrensesnitt, fordi nå må du begynne å arrangere brukergrensesnittene relativt, ikke absolutt. Og det samme har vært tilfelle på nettlesere, og stasjonære og bærbare datamaskiner for år fordi du, selvfølgelig, har ulike skjermstørrelser. 

Hva annet? Du har kanskje flater, som fra Microsoft. Du kan Opptaktene PUBLIKUM: Windows-telefon. DAVID J. MALAN: Hva er det? PUBLIKUM: Windows-telefon. DAVID J. MALAN: Ja. Slik at Windows-telefoner kan fortsatt bli funnet. Slags form for Blackberrys, men de fortsette å prøve. Og så bunter av andre enheter. Så for det meste, la oss si at disse er de å bry seg om i øyeblikket. Gjerne Apple ting, absolutt Android ting, og blant Windows, som overflate tabletter synes å være fange på ganske godt. 

Og så blant disse enhetene, Hvis du ønsker å rulle ut, la oss si, en mobil tilstedeværelse for din selskap, hva slags design beslutninger trenger du å gjøre? Vel, vi allerede har sagt i Apple verden, det er minst to språk som vanligvis er anvendt. En het hva? 

PUBLIKUM: Objective-C. 

DAVID J. MALAN: Ja. Så Objective-C, som er den eldste. Det er også det språket som mange Mac programmer er fortsatt skrevet i. Da den andre nyere en var? PUBLIKUM: Swift. DAVID J. MALAN: Swift. Og de er den type to å vite for å imponere folk. Så i Android verden, hvilket språk gjør Android bruker? 

PUBLIKUM: C #? 

PUBLIKUM: Java. 

DAVID J. MALAN: Java er språket "du jour." I Windows verden, sikker, vi vil si C # i så fall. Så allerede dette er slags irriterende, fordi det er takeaway for en virksomhet eieren eller noen som bare ønsker å rulle ut en mobil nærvær? Som, for faen? Som, hvis jeg ønsker å støtte en ganske bred brukerbase, Jeg har til å skrive, det ville virke, tre separate programmer. En i ett av disse språkene, en i Java, en i C #. Og selv om jeg vil ha funksjonaliteten å være identiske, spiller det ingen rolle. Jeg trenger fortsatt å bruke ulike språk fordi Apple og Microsoft, og Google all støtte forskjellige miljøer. Og dette har vært en utfordring i mange år. Tilbake i dag, da folk pleide å kjøpe programvare på en databutikk i krympe pakket esker, ville du enten nødt til å rekkevidde for Mac hylle, eller for-- kanskje dette svært liten Mac shelf-- eller større Windows sokkelen og kjøpe noen programvare. Og veldig ofte, det var ikke engang noe for deg på Mac sokkel. Hvorfor? Vel, selskapene besluttet om 90% av verden, 95% av verdens har PC-er, hvorfor bry selv implementere ting på Mac OS? 

Som en aside-- totalt digression-- hvorfor er det at Mac virker så ugjennomtrengelig for virus, og ormer og sikkerhetstrusler? Er Apple bedre på dette? Flinkere til å holde datamaskiner sikre? 

PUBLIKUM: Mindre publikum? 

DAVID J. MALAN: Det er sannsynligvis større bit av den. Så mange brukere av Mac-maskiner har lenge hevdet, oh, bruker en Mac, vil du være immun mot virus, og ormer og alle disse tingene som har lenge plaget PCer. Det kan være fordi Apple har bedre programmerere og de skriver bedre programvare, eller operativsystemet ble bedre utformet. Kanskje, men sannsynligvis ikke. 

Det er nok at når du er en 12-åring, eller en 30 noe liksom sitte hjemme å skrive skadelig programvare til å ta over verden, du kommer til å gå etter den mye større målgruppe. 95% av verden som kanskje kjøre Windows eller noen varianter av disse. Så det er litt på begge sider. Men deres kreditt, Apple, så vidt jeg vet, har egentlig ikke spioner seg selv som å være sikrere, siden du bare invitere drama om du gjøre som hevder, vil jeg tro. 

Greit. Uten å bli for langt ned det, hvordan løser vi dette? Har du å kjøpe eller har du å betale tre forskjellige mennesker til å utvikle programmene dine? Har du plukker en over den andre? Hva skal lede din tenker her tror du? Kareem? Nope. Noen andre. 

PUBLIKUM: Bare kom med maskinvaren. DAVID J. MALAN: Kom med maskinvaren? Hva mener du? 

PUBLIKUM: For miljø. [Hørbar] DAVID J. MALAN: Så det er sant. Men kundene, i mellomtiden, kan ha iPhones, de kan ha Android-telefoner, de kan ha tabletter laget av Microsoft. Så hvordan har du en mobil strategi for alle disse forskjellige brukere? Det synes som om det koster, la oss si $ 1000 for å gjøre en iPhone søknad, det kommer til å koste deg $ 2000 for å gjøre en iPhone-applikasjon og en Android applikasjon, eller $ 3000 å også støtte Windows-enheter også. Det er nok litt av en statement, og det kan ikke engang være en lineær sammenheng sånn. 

PUBLIKUM: Hvis du vil ha en app eller ikke, kan du ha responsive nettside. DAVID J. MALAN: Good. PUBLIKUM: Eller du kan ha en innfødt app. DAVID J. MALAN: Ja. Så i all denne sammenheng her, Vi har snakket om hva folk vil kalle native applikasjoner. Det er programmer som er skrevet i morsmål for enheten. Så innfødte Objective-C eller Swift kode, eller i Java, eller i C #. Hvilket betyr at når du laster ned, la oss sier snapchat, et populært program, eller når du laster ned Facebook for en telefon, du laster ned enten versjon skrevet for iPhone, eller skrevet for din Android-telefon, eller skrevet for din overflate. 

Men det er et alternativ. Som Olivier ble berget, du kan faktisk bruke HTML 5 i stedet, ved hjelp av det som kalles en web program, der du rett og slett implementere mobil nærvær og noen funksjonalitet. Hva mener jeg med mobil nærvær? Som ditt nettsted som har din kontaktinformasjon, en liste over alle dine produkter, kanskje det har et kjøpesenter cart, kanskje du selge ting gjennom den. Uansett søknaden din er, du implementere det, ikke i Objective-C, eller Swift, eller Java eller C #, men i HTML 5, som var språket vi sett på i går, med Javascript og CSS. 

Og hva er fint om de som tre er at å kjøre dem, du trenger bare hva stykke programvare? PUBLIKUM: En nettleser. DAVID J. MALAN: En nettleser. Og det beste jeg vet, alle disse enheter leveres med nettlesere, slik at brukeren ikke har nødt til å installere noe spesielt. Så du kan bare fortelle din publikum, dine kunder, gå til acme.com i nettleser og du vil bare har en web-basert opplevelse som fortsatt fyller skjermen, men du trenger ikke å bekymre deg for alle disse kostnadene, og alle av denne kompleksiteten. Men sikkert er det kommer å være en fange her, ikke sant? Spesielt hvis jeg påpeke at et par år siden, den aller første versjonen av Facebooks mobilapplikasjon var hovedsakelig en HTML 5 søknad. Og de har, mer nylig, reimplemented det i sine andre anvendelser. 

Så hvorfor skulle du ikke umiddelbart vil si, vel, selvsagt vi kommer til å gjøre dette? Hva kan de skjulte kostnadene bli? 

PUBLIKUM: Ytelse. DAVID J. MALAN: Ytelse? Hva mener du? 

PUBLIKUM: De innfødte app har mer ytelse. 

DAVID J. MALAN: Så det er sant, for et par grunner. Vi kan overforenkle svaret. Og husker vår diskusjon av tolket versus kompilerte språk. Dette er HTML 5 og med det, bare for å være klart, JavaScript-- ofte skrevet JS-- og CSS er alle tolket språk, selv om bare Javascript er et programmeringsspråk. 

Og så sammenlignet med disse, der noen av disse utarbeides, i hvert fall disse three-- Objective-C, Java og C # - disse, i teorien skal bare være raskere. Men det er en annen virkelighet for-- 

PUBLIKUM: Funksjonalitet? 

DAVID J. MALAN: Hva er det? 

PUBLIKUM: Funksjonalitet. 

DAVID J. MALAN: Funksjonalitet? Hvordan det? PUBLIKUM: Bruk kameraet av telefonen eller noe. Du kan bruke de med nettleseren. DAVID J. MALAN: Nettopp. De er sec-- PUBLIKUM: [uhørlig] DAVID J. MALAN: Det er en annen god en. Det er funksjoner som kommer med mobiltelefoner i dag som ikke er det, av design, for sikkerhet årsaker, tilgjengelig for nettlesere. Fordi det ville være slags en skummel ting hvis bare når du besøker google.com, eller cnn.com, eller noen website.com, at denne nettsiden har makt til å snu på kameraet, ta et bilde av deg, og deretter bruke den. Men du ville ikke ha en tilfeldig nettside at du besøker for første gang å ha denne muligheten. 

Og så hva telefonen produsenter vanligvis gjør er de bare nekte adgang til den slags informasjon til en nettleser, som betyr at du kan ikke gjennomføre kameraet. Du kan ikke gjennomføre push-varslinger, pipene som du får på skjermen med korte meldinger. Og faktisk er enda GPS eneste form av typen tilgjengelig for nettlesere. Hvis du noen gang, på en bærbar PC eller på en mobil enhet, trakk opp noe som kanskje CNN.com, men også lokale nyheter stasjoner tendens til å gjøre dette, blir du bedt ofte med en message-- foxnews.com ønsker å vite hvor du befinner deg. Godkjenne eller avslå. 

Vel, er nettleseren prøver å få tilgang GPS-informasjon fra telefonen. Men heldigvis Microsoft, og Apple og Google har bestemt at føles som det er en nyttig situasjon, vi ønsker Google Maps og andre verktøy for å arbeide, men vi ønsker ikke å krype folk ut ved å bare slik at hvilken som helst nettside til å gjøre dette. Så la oss liksom møtes halvveis og spørre brukeren. Men det er ikke nødvendigvis tilfelle med all maskinvare, for eksempel kameraet og med push underretninger og lignende, så du må kanskje ofre visse funksjoner. Men ytelsen også. Det blir mindre merkbar i dag, kanskje som LTE fanger på og raskere Internett-hastigheter på telefoner, men du kan slags føle forskjellen. Som en web-basert applikasjon bare føles tregere, typisk, enn en opprinnelige programmet, dels fordi en web-basert applikasjon ved definisjon er på internett. Det snakker til servere på nettet. Og hvis nettverkstilkoblingen er treg, selv rulle kan være treg. 

Men en opprinnelige programmet, må du allerede forhånds downloaded-- sannsynligvis når du var hjemme fra App Store, eller du minst pre-lastet ned den i sin helhet tidligere, uansett tilkobling speed-- og så nå har du all biter som du vanligvis trenger. Bortsett fra kanskje noen data som kommer fra en server. 

Så disse er avveininger her. Det er en slags mellom kompromiss, faktisk. Og jeg tror you-- 

PUBLIKUM: Bruk data offline. I de innfødte apps, kan du [uhørbart] DAVID J. MALAN: Absolutt. Så det er den vanlige utgaven, som er veldig irriterende hvis du ikke kan spille noen spill eller bruk noen programvare bare fordi du er i en kjeller et sted eller i en heis. En opprinnelige programmet er spenstig med høyere sannsynlighet for det, forutsatt at du har all dataene du trenger lokalt. 

Så det er et tredje alternativ her. Og la oss trekke spekteret som innfødt app her og web app her. Og hva er i midten er noe called-- og jeg tror du kan ha brukte ordet før, kanskje? Hybrid-programmet. Og som ordet tilsier, det er noe i midten. Det er litt av en web-applikasjon og det er litt av en opprinnelige programmet. 

Og hva betyr dette? Det viser seg at det er frameworks-- å bruke et begrep fra earlier-- programvare som andre har skrevet for hver og en av disse plattformene. Disse og ennå andre enheter. Faktisk, la meg gå til PhoneGap, som er et slikt rammeverk som jeg tror Adobe nå eier. La meg gå til Komme i gang. La oss se. Se om jeg kan se en liste over verktøy. Maskinvare. Starter. PhoneGap maskinvare. 

La oss se. PhoneGap hardware tilgang. La meg se om vi kan finne en liten kartlegge at de pleide å ha. Dette er på et annet nettsted. Er dette nyttig? Nei. Det er skal kaste bort vår tid der. PhoneGap maskinvare. Enheter. Device API. Nope, de har flyttet den. 

PhoneGap. La oss gå en siste titt på denne og se om jeg kan vise deg. Starter. Installer PhoneGap. Installer appen. Kom igjen. De har omorganisert alt. Greit. Å, ja vel. Vel, her vi går. Dette er ikke alle som opplysende, men dette er hva jeg var litt ute etter. 

Så PhoneGap er et rammeverk som du kan laste ned gratis som gir deg noen starter kode, i hovedsak. Så noen kode som de har skrevet som ikke gjør mye av noe. Men hva det gir deg hovedsak er tilsvar av et program som bare setter en stor rektangel på brukerens skjerm. Det setter ikke en URL bar, som en nettleser, setter ikke en adresse. Det setter bare en stor rektangel. Og du konfigurere denne store rektangel, under panseret, å faktisk gå til acme.com, eller kanskje m.acme.com, for mobile.acme.com, men brukeren ikke vet de er på denne adressen. Alt de ser er Innholdet på nettsiden. 

Men hva er fint om dette vesenet en hybrid app er at det PhoneGap og andre selskaper gir deg er de gir deg en liten bit av koden i Objective-C eller Swift, eller en liten bit av koden i Java, eller en liten bit av koden i C #, og i hovedsak, alt du trenger å gi er minimal den adressen til web-basert applikasjon. Og så du pakke dette alle sammen, og du har det enten få tilgang til nettstedet via internett, eller du selv cache en lokal kopiere inne i søknaden, og deretter lagrer din søknad i iPhone-format, Android-telefon format, overflate format, eller hvilket som helst antall av andre enheter. 

Du laster opp hver av disse versjonene til Google Play-butikken, til App Store, til Windows Store, og så videre. Og nå kan du ha alle dine publikum laste ned virkelig en innfødt app, riktignok det meste av koden var skrevet av noen andre, men innholdet i den innfødte app alle kommer fra, typisk, ditt eget nettsted. Så du fortsetter å skrive ditt nettsted i HTML, Javascript og CSS. 

Så hvorfor dimme disse linjene? Hvorfor har en hybrid applikasjon det er slags innfødte, men også form for web basert? Hva er hele poenget med legge denne kompleksiteten? Jeg mener, selv fortsatt, bare fra skotter gjennom denne siden, Komme i gang føles som det har en hel rekke skritt for meg å gjøre før jeg can-- PUBLIKUM: Gjenbruk? DAVID J. MALAN: Gjenbruk? Hva mener du? 

PUBLIKUM: Av kildekoden. Så den samme koden kjøres på alle de forskjellige plattformene. DAVID J. MALAN: Ja. PUBLIKUM: [uhørlig] DAVID J. MALAN: Perfect. Hvis tiden er stramt, og hvis du har ikke så mange developers-- kanskje du har en utbygger og han eller hun sikkert kjenner ikke alle disse environments-- absolutt ikke bra, og absolutt ikke kan programmet i alle tre samtidig og sende tre produkter i tiden tillatt for en, du kan ha ham eller henne med å bygge alt i HTML og Javascript og CSS, og deretter lære en bitte liten litt om native apps, akkurat nok til å laste ned et rammeverk som dette, deretter laste opp produktet til alle de ulike app-butikkene slik at du nå har en opprinnelige programmet. 

Så det virker som en vinn-vinn, men igjen, for å være klar, hva er den potensielle kostnader eller feller? 

PUBLIKUM: ytelse? DAVID J. MALAN: Ja. Opptreden. Det er vanskelig å beskrive verbalt. Så hvis du bare ta på tro en mobil applikasjon, en webapplikasjon vil vanligvis utføre saktere. Det kanskje ikke ser helt riktig, fordi i iPhone, og i Android-telefoner, og Windows-enheter, er det alltid en slags standard utseende og føler til alle knapper og menyer. 

Og selskapene i nettet, kan du prøve å tilnærme disse estetikk med biblioteker som Bootstrap, men user-- en slu user-- kommer til å vite at noe er ikke helt rett her. Og det er greit, kanskje det er ikke en stor avtale. Men ytelsesproblemet absolutt er en stor avtale. Native applikasjoner vil tendens til å bare være mye mer responsiv og derfor bedre. Og ja, hva da kan være det beste fra begge verdener? Hvis du er spesielt en liten bedrift eller en liten gruppe, du ikke har ressurser å utvikle en app i parallell på alle tre plattformer, og ærlig, føles som det er en dårlig idé uansett fordi hvis du ruller den ut og på alle tre samtidig skjønner, vi burde ha lagt til noen funksjoner eller gjort noe annerledes, nå du må fikse det i tre stedene, ikke én. Hva er kanskje den optimale strategi her samlet, hvis ressurser og tid er tett? 

PUBLIKUM: Bare gjør det på iOS. 

DAVID J. MALAN: Det er ikke urimelig. iPhones, i hvert fall i USA, er super populære. Android synes fortsatt å ha dominerende markedsandel globalt, samlet. Så du er ikke nødvendigvis representative av helheten av verden denne uken. Men det er absolutt en avgjørelse. Jeg mener, på campus her jeg tror noen fryktelig tall eller prosentandel av studenter har iPhone og ikke Android-telefoner. Men i utlandet, er det slags motsatt. Så du bestemmer deg basert på publikum. Hvordan vet du hva publikum har? 

Vel, vi har lært et triks i går. Du kan be dem. Hvis du har en fange publikum du kan sende dem en undersøkelse form. Eller du kan bare gjøre det? 

PUBLIKUM: Google Analytics? 

DAVID J. MALAN: Hva er det? 

PUBLIKUM: Google Analytics. DAVID J. MALAN: Google Analytics. Yeah. Eller enda mer slags teknisk, bare se på dine egne webservere logger. Fordi hva som skjer hver gang en nettleser, om bærbare, stasjonære eller Telefonen besøker nettstedet ditt? De sender som HTTP header som viser du hvilken nettleser og operativsystem de bruker. Så du kan antyde, med stor sannsynlighet, hva demografiske bruker den måten og deretter justere. 

Så antar det er uakseptabelt. Det er liksom dårlig for virksomheten dersom Android-brukere kan ikke kjøpe våre widgets. 

PUBLIKUM: Enten du er skal lade eller ikke? DAVID J. MALAN: Enten du kommer til å lade? Så OK, du får hva du betaler for. 

PUBLIKUM: Enten app er skal være gratis eller om det er gonna-- 

DAVID J. MALAN: OK. Så kanskje du kan hente inn kostnader på den måten, or--? 

PUBLIKUM: Jeg leste en studie en gang som sa at Flere Apple-brukere betale for apps versus-- DAVID J. MALAN: Det er sant fordi de allerede betale mer for sine enheter. Så ikke urimelig antagelse. 

PUBLIKUM: [uhørlig] DAVID J. MALAN: OK. Så hvis de er mer villige til å betale, så til helvete med Android-brukere. De kommer ikke til å betale oss noe likevel. Vi kan like godt fokusere våre prioriteringer, i hvert fall for de første månedene eller et år, på iOS. Helt rimelig. Hva er et mer inkluderende strategi enn det? Maybe-- hva er det? 

PUBLIKUM: [uhørlig] 

DAVID J. MALAN: En mer expensive-- så kanskje investere mer in-- gå videre. PUBLIKUM: Yeah. Bare et mobilnettsted. 

DAVID J. MALAN: Så gjør en mobile nettside og ikke selv bekymre deg for dette kompleksitet. Eller kanskje en fornuftig strategi, som selv Facebook tok, er å starte med en hybrid søknad fordi det ikke er det mye vanskeligere å gjøre dette på enn dette. Du må bare lese noen dokumentasjon og finne ut hvordan å laste opp ting til App Store. Så kanskje du starter med denne, slik at på dag en, du kan støtte alle brukere. Og så, akkurat som Facebook og andre selskaper har gjort, når du har ressurser, du har folk, hvorfor ikke du re-implementere bare iOS søknad. Du har fortsatt noe for alle, selv om det er en dårligere opplevelse kanskje med hybrid-programmet. Men du kan gradvis rulle ut og erstatte kort sikt tiltak av hybrid apps med dine mer native applikasjoner. 

PUBLIKUM: Men med en hybrid app du vil ha tilgang til mobile funksjoner? 

DAVID J. MALAN: Ikke nødvendigvis. Så kanskje du gjør en bevisst beslutning tidlig, du kan bare laste opp bilder på opprinnelige iPhone-applikasjon for Facebook, men ikke på Android-applikasjonen, innledningsvis, for eksempel. Og det er litt av en hvit løgn, fordi web-applikasjoner har flere restriksjoner enn hybride applikasjoner det viser ut, og hvis vi leser dokumentasjonen for PhoneGap og ting som det, folk har kommet opp med måter å gi web-baserte applikasjoner adgang til kameraet, så lenge du bruker en hybrid applikasjon. 

Hvordan fungerer det? Fordi hybrid søknad, per definisjon, har en bit av koden i Objective-C, og Swift, og Java, eller i C #, det kan få tilgang til maskinvaren. Ikke nødvendigvis alt, men det kan godt være slik at du har nok tilgang til å få kameraet, selv for Android-plattformer, for eksempel, i den contrived eksempel. 

Eventuelle andre spørsmål? Greit. Hvorfor kan ikke vi ta vår 15 minutters pause her. Vi vil starte opp igjen med tre med en endelig se på web-programmering, databaser, og Javascript.