DAVID J. MALAN: Så er vi tilbage. Så højt niveau emne i øjeblikket nu er teknologi stakke, hvilket ikke er en særlig teknisk term, det er mere af en fangst alle for enhver antallet af kombinationer af teknologier at du kan bruge til at løse problemer. Og måske den mest passende måde at starte ville være at se på sprog siden Jeg bliver raslende ned af en hel masse og de fleste alle i rummet har sikkert hørt om mindst én. 

Og så hvorfor vi ikke forsøger at skelne hvad-- skelne disse sprog og tale kort om, når du ville vælge en frem for den anden, hvordan de er slags fundamentalt forskellige, og især når du chatter med ingeniører, eller forsøger at beslutte, hvem de skal ansætte, eller hvad gennemførelsen forslag om at GreenLight, hvordan du rent faktisk ville gøre den slags beslutninger. 

Så lad os bare rasle nogle ting fra. Af de sprog folk har hørt om, hvad der kommer til at tænke på? C. OK. OK, C ++. Hvad er det? 

PUBLIKUM: Python. 

DAVID J. MALAN: Python. Fremragende. Hvad ellers? Visual Basic. Jeg hørte Java. Visual Basic-- alias VB. Java. NET, der er mere af en fangst alle for hvad er normalt C # som det sprog pågældende. Og lad mig nævne. Så vi vil vende tilbage til. Undskyld? Undskyld? 

PUBLIKUM: SQL. DAVID J. MALAN: Scratch? PUBLIKUM: SQL. DAVID J. MALAN: Åh, SQL. OKAY. SQL. Så vi vil vende tilbage til at-- faktisk, det er god-- efter pausen så godt. Hvad ellers? 

PUBLIKUM: Oracle. 

DAVID J. MALAN: Så Oracle, ikke et sprog. Faktisk ville de bruge SQL så godt. Så lad os sætte, at efter pausen samt. Og undskyld, noget herovre? PUBLIKUM: Mathematica. DAVID J. MALAN: Mathematica? Ok fint. Og MATLAB er slags på der nogle gange. 

PUBLIKUM: R. 

DAVID J. MALAN R. Lad os gå over her. Fortran. Jo da. Ældre skole. Fortran. COBOL. Jeg vil smide BASIC. GRUNDLÆGGENDE. Enhver-- 

PUBLIKUM: MATLAB? DAVID J. MALAN: MATLAB. Åh, slå dig til det. Noget? Jeg kan tænke på et par andre. Jeg kan tænke på et par andre. Og hvad var det sidste? 

PUBLIKUM: ASP. 

David J. MALAN: ASP? Ja. Active Server Pages. Det generelt ville falde ind under andre sprog, undertiden C #, så lad os forlade denne off. Men vi vil vende tilbage til det for rammer og sådan. Ellers andet? PHP er populær. Ruby er en anden. JavaScript, ikke at forveksle med Java, er en anden. Det er sådan et parti. 

Så det kan være helt sikkert overvældende, som hvis listen ikke allerede er, bare at begynde at vide, hvor du begynder. Og så heldigvis, lad os gribe dette fra et par vinkler. Først, lad os prøve at kategorisere i det mindste nogle af disse sprog i to brede spande, der minder om samtalen vi havde før pausen, hvor vi talte om kompilering, og kildekode, og maskinkode, fordi det er ikke sådan alle sprog fungerer. Så vi vil plukke ud et par eksempler of-- eller mod examples-- til denne model. 

Og så, hvorfor ikke vi tale om de programmer at disse sprog anvendes generelt til. Og helt ærligt, selvom dette er en temmelig lang liste, det er kun en delmængde af denne liste, du vil typisk trække disse dage til at løse problemer. Visse sprog er nyere end andre. Visse sprog er mere populære end andre. Så det er ikke ligesom du har sådan en overvældende opgave, før du når de beslutter blandt disse forskellige sprog. 

Så lad os gøre det. Vi havde tidligere, kildekode, og derefter havde vi maskinkode. Ups. Skrivning det forkerte ord. Machine kode. Og vi havde nogle proces i midten called-- yeah, compiler. Så compileren. 

Og hvad maskinkode faktisk kører på i sidste ende vil være din faktiske CPU. Med andre ord, af maskinkode, jeg betyder de laveste instruktioner niveau at en CPU faktisk forstår. Addition, subtraktion, flytte, gemme og operationer som det. Og så dette er den model for, hvad der er almindeligt kendt som kompilerede sprog. Måske ikke overraskende. 

Så det er den model for kompileret sprog. Men det viser sig at der er en anden klasse af sprog kaldet fortolket languages-- fortolket languages-- der er lidt anderledes. Du skriver i kildekoden, køre dem gennem en tolk, og at tolken er hvad kører på CPU. Med andre ord, hvad du ikke gør Emit er hvad, tilsyneladende? Machine kode. De nuller og ettaller, at CPU'en selv i sidste ende forstår. 

Så i denne første version, og sprog som C, ligesom vi så, du skriver i kildekode der er lidt mystisk, men i det mindste er lidt engelsk-lignende og det er mindst læsbar når man vænner sig til det. Du kører det gennem en compiler og ud du får, i sidste ende, nuller og ettaller. 

At en oversimplificering. Der er nogle andre trin i der. Faktisk, hvis du nogensinde har hørt udtrykket "assembler" det er et skridt, før de nuller og ettaller. At lidt mere læsbar, men stadig temmelig mystisk. Og så der er mellemliggende trin der er i virkeligheden foregår her. Men produktionen, i sidste ende, er disse nuller og ettaller. 

Men i den fortolkes verden, hvor du har sprog, der tolkes sprog, du faktisk springe dette skridt. Med andre ord, når man skriver en program, du lige straks køre den. Du behøver ikke kompilere det og derefter køre det, som jeg gjorde før. Du skal bare skrive det og køre det. Og hvis du ønsker at gøre en hurtig ændring, du laver en hurtig forandring, og gentag det. Så der er ingen mellemvej skridt her. 

Nu, for det program, jeg skrev tidligere, som var denne "Hello World" program, du måske med rimelighed wonder-- eller med rimelighed state-- der var ikke dengang tidskrævende at kompilere mit program. Det synes at have gjort det bare sådan. Og der er grafisk versioner af compilere. Jeg bruger en meget mystisk udgave, men du kunne ramme en play-knap og det ville faktisk gør udarbejdelse for dig. Jeg har kompileret programmet og derefter igen, for at køre det, jeg bare gøre dette. Og det output til venstre der, "Hej!" Det synes ikke alt det besværlige. Men når dine programmer er mere end blot én, to, tre, fire, fem linjer lang, kan det tage langt flere sekunder at kompilere. Undertiden endda minutter eller ganske lidt tid til at kompilere. Efter alt, nogle af de verdens største produkter er ting som operativsystemer, Microsoft Word, Microsoft Excel, som kan være hundreder af tusinder eller endda millioner af linjer kode lange, og dem ikke bare straks at udføre. 

Desuden på nettet, er det blevet moderne at bruge simpelthen fortolket sprog, delvis fordi du kan gøre en ændring som udvikleren og så bare straks genindlæse browsersiden og straks se resultatet. Og så HTML, mens ikke et programmeringssprog, er et sprog, der er fortolket. Og vi så, at samme virkning i går. Du skal bare genindlæse siden efter at en ændring i Cloud9 og-- voila-- du se et nyt resultat. 

Så hvad er forskellen her? I HTML, husker, havde vi åbne HTML, åben hoved, åben titel, tæt titel, tæt hoved, åben krop, og så videre. Vi havde alle disse tags, som vi temmelig meget sagt, fortælle browseren hvad de skal gøre. Hey browser, her kommer en HTML-side. Hey browser, her kommer titlen. Hey browser, her kommer nogle tekst, der skal være fed. Og så skal du fortælle det modsatte. Hey browser, det er det for fed tekst. Hey browser, det er det for kroppen. Og så videre. 

Og så hvad er en browser? En browser er bare en tolk. Det er et program, der nogen som Microsoft eller Google har skrevet, hvis formål i livet er at læse et sprog, der er kendt som HTML, og fortolke den. Top til bund, venstre til højre. Og helst browseren ser åben beslag, titel, tæt beslag, Det bør fortolke denne således, åh, at betyder, at jeg skulle sætte disse ord måde op her på toppen af ​​browseren. 

Så det gør bare, hvad HTML-koden siger. Men der er ingen nuller og ettaller. Der er ingen kompilering. Du gjorde det ikke. Browseren ikke gjorde det. Det er bare ikke involveret. 

Så i ånden af ​​disse igangværende emner, i dag og i går, der synes at være en vidunderlig funktion. Du sparer din kode og derefter bare køre det eller fortolke den. Der er ingen mellemliggende trin. Mon der er en omkostning? Kan ikke alle være upsides. Så hvad kan det koste være? 

PUBLIKUM: Space. 

DAVID J. MALAN: Space. Så sikker. I kompileret verden, du har ikke kun den originale kildekode, du er også at skabe og derefter formentlig spare maskinen code-- den nuller og ones-- og det er nødt til at tage nogle meget plads. Absolut. Så det koster dig mere plads. Ja? 

Målgruppe: Browsere måske fortolke anderledes. 

DAVID J. Malan: muligvis browsere fortolker det anderledes. Det er sandt. Men jeg er ikke sikker på jeg er komfortable hævder det er fordi det er fortolket. Det er mere bare fordi det er en implementering af et sprog at selv har uklarheder. Så lad os ikke helt bekræfte at en, men god fornemmelse. Hvad andet kunne den betalte pris? Andrew? 

PUBLIKUM: Du kombinerer to trin, så du derfor har stigende kompleksitet samt. 

DAVID J. MALAN: Den complex-- stigningen i kompleksitet, hvor? Til hvem? 

PUBLIKUM: Så i tolken trin, er du kombinerer tolken og compiler til bare op at-- 

DAVID J. MALAN: Ah, OK. Ironisk nok, er det nok lidt enklere at gennemføre tolken, selvom det synes at udbytte upsides af denne bekvemmelighed. Så muligvis sandt. Men det slags afhænger jeg vil sige, om sproget og om, hvordan de gik om at gennemføre det. Der kan være en meget mere kompliceret, faktisk, i compileren, bare fordi du nødt til at gå fra noget så højt niveau til noget så lavt niveau. Men en god tanke. 

Så sætte en anden måde, en kompileret program, når forvandlet til disse nuller og ettaller, ender i sproget at CPU'en taler, mens det i denne side af verden, det program, du har skrevet, den kode, du har skrevet, faktisk aldrig bliver omdannet til den faktiske sprog computeren taler. De nuller og ettaller. Det forbliver i den oprindelige, mere menneskelig venlige, mere læsbar sprog. Så hvad kunne være konsekvenser der, hvis du ikke faktisk gider konvertere dine program til meget sprog at den underliggende computer taler? 

PUBLIKUM: Might ikke forstå noget? 

DAVID J. MALAN: Might ikke forstår noget. Og det kan claim-- hvis det ikke forstod noget, det er en fejl eller mangel af funktion i fortolkeren. Så det ville være mere af en fejl end en omkostning. 

PUBLIKUM: Du har adgang til kildekoden? DAVID J. MALAN: Der er en god en. Så en ulempe her er dig synes at have adgang. Du, slutbrugeren, kan synes at har adgang til kildekoden. Og det er ikke altid tilfældet. Men det er rigtigt i tilfælde af JavaScript, som vi vil se på, efter pausen dag, som er et fortolket programmeringssprog at du skriver i kildekoden. 

Men at kildekoden bliver overført fra din server til browseren og kører i den menneskelige browser. Så her kunne hun bare åbne vindue, ligesom jeg har gjort i Chrome, og ser på det, som vi selv så på i går med Google. Det ser måske lidt uforståeligt, men det er der. Så det er absolut en pris betalt. PUBLIKUM: Performance hit? DAVID J. MALAN: Ja. Og det er den anden Biggie. Der er en performance hit. Fordi du har denne midt mand, der i sig selv er et program, mellem dig og CPU, i modsætning til bare at fodre disse rå nuller og ettaller i CPU'en, der er en præstation hit, som du tage med et fortolket sprog. Sådan at, vilkårligt, et program der kan tage en, andet til at køre på en computer eller en minut til at køre på en computer her, kan tage 10 sekunder eller 10 minutter til at køre på en computer her. Det er generelt ikke til at være, at meget af en difference-- faktor 10-- fordi der er optimeringer, du kan gøre. Men det er næsten altid langsommere. Nu bagsiden til bekymring er, godt computere, hver 12 til 18 months-- ifølge Moores lov, så at speak-- er lige ved at komme hurtigere og hurtigere. Jeg har mere og mere diskplads. Jeg har mere og mere RAM. Hvem virkelig bekymrer sig? 

Og det er sådan en rimeligt argument. Faktisk er en af ​​grundene hvorfor vi kan tolerere langsommere fortolket sprog er fordi vi mennesker ikke rigtig mærke. Computerne har fået lige så pokkers hurtigt. Ud fra følgende betragtninger tilbage i dag, især når hardware var langt mere begrænset, du havde mindre af alt, det var meget dyrere så alt koster mere, ja så du virkelig ønskede at presse ud så meget ydelse som du kunne. Men der kræves skriftligt et lavere niveau, hvis du vil, med et kompileret sprog. 

Så du tager denne præstation hit. Men generelt, upsides synes at være det værd i disse dage. Nå, bortset fra den intellektuel ejendomsret problem. Den slags læsbarhed af koden, vil vi komme tilbage til, når vi ser på JavaScript. 

Så lad os prøve at kategorisere mindst et par af disse. Så blandt de indsamlede sprog, vi ville have C, C ++, kinda, sorta, Java, selv om det er lidt af en undtagelse, for grunde, jeg vil vise dig på bare et øjeblik. C # ville være på denne liste. Vi ser på mere på bare de mere moderne sprog. Okay. Og det ser ud som masser der. Betragtninger på denne side af hegnet, vi måske have JavaScript, og Python, og PHP, og Ruby. Og er det nok for de nyere dem? Det føles rigeligt til nu. OKAY. Og så dot dot dot, da listen er uendelig. 

Og i virkeligheden, hvis vi ønsker at bare få en fornemmelse af denne-- Wikipedia, kompileret sprog. Jeg gætte, vi kan få en langt mere udtømmende liste. Så her vi går. Så her er en langt mere udtømmende liste. Og jeg håbede nogen vil gætte D som et sprog, fordi det også eksisterer, men de stoppede ved D det synes. Selv om der faktisk kunne være en E. 

Åh, faktisk, det bør være på listen i disse dage. Swift er faktisk en sprog, at Apple opfandt der nu anvendes i stigende grad så, i iPhone udvikling. Men vi vil vende tilbage til at med vores diskussion af mobil i bare en lille smule så godt. Så Swift så godt. 

Og så hvis vi går til fortolket language-- fortolket language-- så her er en endnu længere liste. Så hvis du bare google og se på Wikipedia for disse, vil du se alle mulige sprog. Men formålet er, for i dag virkelig, bare koges ned til måske dette spørgsmålet om intellektuel ejendomsret og læsbarhed af slutbrugeren og ydeevne, er en anden biggie samt. 

Så blandt disse sprog, lad mig se, om vi kan give dig blot nogle udsnit af sprog. Vi ønsker ikke at gå igennem alle sprog uendeligt. Har du nogensinde spekuleret over, hvad en bestemt sprog ser ud? Vi kunne se en øjeblik siden. Hvorfor ikke tage et par af funktionen anmodninger. Hvem vil gerne se, hvad andet sprog ser ud? Ja. 

PUBLIKUM: Java. 

DAVID J. MALAN: Java. Okay. Så lad os gå til Java. Og bare for at give dig et sample-- vi kunne skrive alle disse ud, men det ville være hurtigere blot at se på en andens kodeeksempler. Okay. Så er dette et godt eksempel? Ups. OKAY. Så her er Java-versionen af program jeg skrev tidligere, "Hello World." 

Så Java, vil du ofte se "klasse". nøgleordet Så vil du se nogle navn efter det. Du vil se krøllede parenteser ligesom vi så før, og nogle gange de går på samme linje, undertiden andre linjer, det er form for en personlig beslutning. Du vil se søgeord som "Offentlig", "statisk", "ugyldig". Men vi kunne se "main". "Main" er generelt navnet på standard-funktionen eller standard chunk kode, bliver kørt i et program. 

"Streng." Hvad gjorde vi mener med snor tidligere? Jeg brugte den slags henkastet. En streng er hvad? Et ord. Det er ligesom en sekvens af tegn. Individuelle tegn, tilbage til ryg mod ryg, som regel i et array, som vi har diskuteret. Og i virkeligheden, se denne syntaks her, de to firkantede parenteser? Det betyder, hey computer, her kommer et array af strenge. Pladsen beslag notation er almindeligt anvendt til at betegne det. Og så kan du sikkert tage en guess-- hvad betyder dette fremhævet luns af kode sandsynligvis gøre? 

PUBLIKUM: Udgangen? 

DAVID J. MALAN: Ja. Den udskriver noget til skærmen. Så "system" er en slags en reference til din computer. "Out" betyder, at din computers udgang eller skærmen. Så "system.out.print ln" betyder sandsynligvis? "Ln". Print linje, som programmører som til tilsyneladende stave nogle ord ud i deres helhed og tage genveje med andre ord. Men "ln" er linje, så print linje. Så det udskriver "Hello Verden! "Efterfulgt af en ny linje. 

Så det er det. Men Java er, hvad de vil call objektorienteret. Og ja, bare for at give et par andre definitioner der, at du måske se, der generelt er mange forskellige typer af sprog, men det mest almindelige er proceduremæssige eller tvingende sprog. Der er funktionelle sprog, der ikke gør betyde, at andre er ikke-funktionelt. Og så er der objekt-orienterede sprog. Og det er måske den bedste kategorisering af de fleste sprog at du nogensinde ville vælge for sortering af et typisk kommercielt projekt. 

Det ville være for meget af, Jeg tror, ​​en rotte hul at gå ned, for at forsøge at forklare de forskellige forskelle. Men sprogene vi har set således far-- C er en proceduremæssig eller afgørende sprog. For nylig opfundet sprog tendens til at være, undskyld, objekt-orienteret, hvilket betyder de har andre funktioner til dem. Kan jeg forklare det på denne måde? Lad os ikke engang gå dernede. 

Objektorienteret midler du kan implement-- du kan modellere den virkelige verden lidt mere effektivt. Menneskeheden, over tid, har regnet ud, wow, det ville være rart, hvis mit sprog havde denne funktion, eller at funktionen. Og det er derfor, vi har så mange sprog i verden. Rimelige mennesker, smarte mennesker, enig eller uenig og uvægerligt slags mødes på udvikle nye sprog alle sammen. 

Sag i punkt. Apple opfandt Swift i håb om formentlig sænke panelet til iPhone udvikling, fordi den tidligere language-- kaldet Objective-C, som kunne også være på vores liste her-- var meget mere mystiske og meget sværere at ombryde ens sind rundt. Og som programmering bliver velsagtens mere tilgængelig og mere bredt vedtaget af folk selv mindre tekniske, det goal-- det er en meget tapper mål at forsøge at sænke adgangsbarriere ved at gøre sprogene selv nemmere at komme i gang med, men ikke mindre kraftfuld nødvendigvis. 

Og en anden sprog. Hvorfor vi ikke tage et kig på noget som Python, som er meget på mode i disse dage. Python. Sample program. Lad os se. "Hej verden" sprog. Lad os gøre det. "Hej Verden." Lad os se, om det giver os et fint eksempel. OKAY. Så det er faktisk slags sjov. Så hvis du nogensinde google "Hello World", som sker for at være et af de første programmer nogensinde er skrevet i et moderne sprog, lige som en proof of concept, kan du se alle mulige implementeringer af dette. 

Nogle af disse sprog Jeg har ikke engang hørt om. Men du kan see-- lad os gå til Basic, den ene jeg lærte år siden, delvist. Dette var en sjov sprog, fordi du måtte, som programmøren, antal alle dine linjer. Ikke ulig, hvad jeg var gør, når jeg skrev pseudokode på den gule dokument tidligere til binær søgning, til at søge en telefonbog. 

Og så, hvis du ville at gå til en anden linje, du ville bogstaveligt skrive, gå til 10, eller gå til 20. Og hvis du skriver linjer, de konvention var at gøre, det er linje 10, dette er linie 20, er dette linie 30, 40, med intet i mellem, derved give dig selv lidt plads hvis du beslutter, vent et øjeblik, Jeg burde have tilføjet nogle mere kode et sted. Du havde stadig slags ni chancer for at klemme det i mellem dit program før du var nødt til manuelt omnummerere alt. 

Så dette er slags hvad jeg mener når jeg siger verden er kommet op med en nye funktioner. Et eller andet sted undervejs nogen indså, dreng det er dumt. Dette er blot skabe arbejde for programmøren. Så han eller hun lige slags bygget et nyt lag oven på det så du ikke behøver at bekymre dig om, hvad line numre din kode er faktisk på. 

Så når du måske vælger et sprog eller en anden? Nå, hvilke af disse sprog gør du har tendens at høre om de mest din egen verden i disse dage? Lad os falde ned Objective-C også. 

PUBLIKUM: C #. David J. MALAN: C #. Så lad mig farve. Har vi vores anden farve eller andet sted? Så C #. Og hvad ved du om C #? Alt foråret til at tænke på? 

PUBLIKUM: Det er et programmeringssprog. DAVID J. MALAN: Det er en programmeringssprog. OKAY. Det er sandt. Så vi taler om C #. C # tendens til at blive anvendt i Windows-miljøer, så hvis du skriver Microsoft-software til Windows, er C # meget almindeligt anvendt, uanset om det er til desktop-software, eller selv telefonens software på Windows-telefoner, hvis du har haft dem, eller på internettet selv også. Og i virkeligheden, måske Kareem ovennævnte ASP tidligere? Så der er også disse ting kaldet rammer, som vi kan præsentere i forlængelse. Rammer, ligesom ASP. Står for Active Server Pages. Og det er kode og en måde at programmere der generelt gør det lettere at skrive web-baserede applikationer. Med andre ord ville det være super, super irriterende at skrive en hjemmeside på det sprog C, der vi har set før, fordi du ville have til at bruge print + F, du ville have til at bruge det pågældende søgeord "Main" og de krøllede parenteser. En masse mystiske syntaks og tilgang til gennemførelse noget, der er ret kompleks. En webside. 

Og så andre sprog har udviklet sig at gøre den slags ting lettere. Og til gengæld har folk kommet op med rammer, en slags værktøjer at du kan bruge, der gør det endnu nemmere at skrive websider. Så for eksempel, for at gøre dette langt mere konkret, lad mig åbne op bare en tekstfil et øjeblik. 

Og du måske husker i går at vi sagde noget lignende, er dette en webside. HTML. Luk HTML. Lad mig springe hovedet og bare gøre kroppen her. Antag, at jeg ønskede at skrive ikke "Hello World", men "Hej David," hvor David er navn på den aktuelt indloggede bruger. Hvad noget som ASP vil gøre, eller JSP-- som er Java server Og den slags eller en række andre rammer er de ikke er sprog, per se. De er ligesom ekstra software, som du ville installere i dit miljø der bare gør det lettere at programmere. 

Så for eksempel, snarere end at gøre noget som "goddag, printf (" David ")" eller noget, der er slags co-mingling-- den slags kode, vi har set before-- du ville gøre noget meget enklere, lignende "name%." Og så disse rammer, ligesom ASP-- og jeg kan ikke huske om jeg får syntaksen lige ret for ASP. JSP er en little-- er denne ret? 

Så med ASP, er dette sortering af en speciel syntaks at nogle udviklere har besluttet dette kan hjælpe folk ud. Og jeg kan udtrykke mere kortfattet pladsholdere, f.eks. Ligesom sætte en værdi her, hvor denne værdi navn er ikke N-A-M-E, det er nogle lagret der. Så "navn" i denne sammenhæng, vi ville kalde en variabel. Algebra har variabler ligesom x, og y og z. Programmører bruge variabler, der er mere beskrivende end x, y og z, typisk. Så "navn" ville bogstaveligt være en form hukommelse beholder til noget som D-A-V-I-D, for mit navn, eller hvem ellers er logget ind på hjemmesiden. 

Og så dette er den slags bekvemmelighed du får med visse miljøer. Så C # og noget ASP ville meget almindeligvis anvendes i en Windows verden, hverken for sin desktop software eller web-server, især hvis dine servere er igen kører Microsoft Windows og Microsoft IIS-- eller Internet Information Server, hvis jeg får akronymet right-- som er Microsofts webserver. 

Så hvad andre sprog er folk bekendt med, eller har du hørt om oftere end ikke? 

PUBLIKUM: Jeg ved, at Pythons slags en populær [uhørligt]. DAVID J. MALAN: Meget populær. Så Python her bruges meget ofte i videnskabelige programmer eller data videnskab, hvor du har en masse af data, som du vil analysere og du ønsker at bruge en programmeringssprog for det. R kan almindeligvis anvendes til dette samt, i en statistisk sammenhæng. Men Python har så mange funktioner indbygget. Så mange ekstra biblioteker, som folk siger. 

Biblioteker er bare samlinger kode, som andre mennesker skrev, at du kan bruge, så du behøver ikke at genopfinde disse hjul. Og så Python er meget almindeligt bruges i data science applikationer. Men det er også meget almindeligt bruges i web-applikationer. Du kan implementere en dynamisk websted ved hjælp af Python. 

Og ved dynamisk hjemmeside, jeg betyder ikke bare statisk indhold ligesom vi skabte i går, ved bare svært kodning i den latinske tekst og andre sådanne ting, men derimod evnen at logge på, evnen til at købe noget, evnen tjek med dine indkøbsvogne eller lignende. Alt dette kræver dynamik og du brug for nogle sprog som en af ​​dem. 

PUBLIKUM: Så betyder Python har sin egen udvidelse, der ligner lide [uhørligt] DAVID J. MALAN: Det gør. Så i verden af ​​Python, Django er en meget populær ramme for Python. WSGI er en anden mekanisme, der er slags forskellig fra dette men lignende i ånden. Det er en add-on, der giver dig at køre Python kode på en server. Der er other-- ja. Så vil disse vi kalder rammer. Og det er en lille smule af et misbrug. Dette er mere af en web-server teknologi. Men vi vil holde det enkelt og sætte det i denne kolonne alligevel. 

OKAY. WSGI. WSGI. En anden thing-- og faktisk, lad mig med at flytte det til sin egen søjle, fordi jeg ville råbe på mig selv for sætte dem i samme spand. Lad os sætte dette i server funktioner, lad os sige. Det er ikke en teknisk term. 

Så her er vi måske WSGI. Der er CGI, hvilket er en ældre teknik til betjener op sprog ligesom Perl eller PHP, eller nogle andre. Igen, jeg har nævnt disse vilkår ikke så meget at slags ingrain dem, men så hvis du ser dem er det noget du bare google for at læse mere. Der er ingen reel saft til nogle af disse ting. 

Men lad os gå tilbage til sprogene. Vi talte om C #, Python. Hvad kan du bruge til web programmering i disse dage? Lad os fokusere på at stille. 

PUBLIKUM: PHP. DAVID J. MALAN: PHP. Og lad os vende tilbage til. Så PHP meget almindeligt anvendt. PHP tendens til at få en dårlig rap. Det startede som et sprog implementeret af folk, der måske ikke var nødvendigvis det bedste sprog designere. Og så du kan læse alle mulige artikler online om hvordan dårlig PHP er. Og desværre, det er en manifestation, delvist, af bare de religiøse debatter at bryde ud blandt programmører. Og det er noget værd at holde sig for øje, fra et forretningsmæssigt synspunkt, at det er meget nemt for tekniske mennesker at få alle arbejdet op med deres meninger om visse ting. Og det betyder ikke nødvendigvis, at den, råben højest eller med den stærkeste, vredeste mening er rigtigt. En masse gange, det virkelig bare ligegyldigt. 

Og så folk er bare argumenterer uanset deres egne fordomme eller komfort zoner er. Og så bør du holde det i tankerne, når de foretager en beslutning, der bare fordi nogen siger dette er det rigtige sprog for det job, der kan være sandt, men det også bare kan være det er den rigtige sprog inden for deres egne evner indstille eller komfort zone. Hvilket er ikke dårligt, men du bør indse at der kan være nogle sammenhæng der. Der er nogle objektivt forkerte udsagn, som C er det forkerte sprog til at bruge disse dage for at gennemføre hjemmesider næsten altid. Men det er ikke urimeligt at sige, at nogen af ​​disse er forkert, at vi har kredset hidtil. 

PHP har været igennem mange versioner. Så sprog tendens til at have udgave tal knyttet til dem. PHP er op til, tror jeg, version 7 nu, så det har været rundt i temmelig lang tid. Og som sprog får nyere, de ofte får nye funktioner. Men du skal være opmærksomme på dette fordi hvis din hjemmeside er blevet implementeret i version 7 af PHP men du forsøger at køre din hjemmeside, eller måske du har outsourcet udviklingen af ​​din kode til en anden, og de mail den til dig, eller sende den til dig og de siger, her, sætte dette på din webserver, hvis webserveren er et par år outdated-- uanset om det er din egen server eller en web host-- det kan faktisk ikke køre. Så det er disse former af ting, at nogen skal være opmærksomme på ved opgradering et websted eller gennemføre det for første gang. 

Jeg hørte JavaScript tidligere. Så JavaScript er en interessant én i, at den generelt klientsiden, som vi vil se efter pausen, hvilket betyder, at det kører i brugerens browser. Men du kan også køre JavaScript disse dage bruge noget, der hedder Node.js, hvor node.js er en mekanisme til drift JavaScript-kode server side, stedet for at bruge Python, eller PHP, eller andre sådanne sprog. 

JavaScript er særlig velegnet for chat programmer og real tid applikationer, mens PHP er ikke en stor sprog til at gennemføre noget ligesom en chat server, hvor brugerne holde forbindelsen til det konstant. PHP er mere af et besøg mig gang, kom tilbage et resultat, og klik derefter på et andet link nogle sekunder eller minutter fra nu. Ud fra følgende betragtninger node.js og JavaScript kan være anvendes mere for vedvarende forbindelser. Andre sprog, som du har mistanke er almindeligt anvendt til web kram? 

PUBLIKUM: Ville jQuery være en ramme? 

DAVID J. MALAN: Godt spørgsmål. Ingen. Jeg ville kalde jQuery et bibliotek, hvor igen et bibliotek er bare en masse kode at nogen har ellers skrevet, at generelt løser nogle problemer, som gør det forhåbentlig lettere for dig at gøre dit job. Og lad mig gøre et eksempel på dette i forbindelse med nettet. 

I forbindelse med internettet er der dette sprog, JavaScript, at vi vil se senere, hvor du kan sige noget lignende denne-- "Document.getElementById." Og hvad gjorde jeg kalder det i går? Først tror jeg, var den unikke id jeg gav til et element, der lignede dette. "P id =" første ">" og derefter havde vi lignende "lorem ipsum" et cetera. Så hvis jeg var at skrive et program i JavaScript eller anden måde manipulere, ændre de websider, vi legede med i går, Jeg vil bruge denne fremhævede linje kode at få denne særlige uddrag af HTML fra min side, at bestemt node, som vi vil kalde det. 

Men i jQuery, i stedet for at skrive dette, som er rå JavaScript code-- lige ud af kassen, det er hvordan du skrive det-- du vil i stedet bare sige, "#først." Det svarer. Og så kun er baseret på dette meget mystiske eksempel, hvad måske er argumentet for at bruge jQuery? Hvorfor skulle en udvikler bruge et bibliotek som jQuery, baseret på denne isolerede eksempel måske? 

PUBLIKUM: Mindre kode. 

DAVID J. MALAN: Ja. Det er mindre kode. Det er bare hurtigere at skrive. Den kontrapunkt er at det ser mere skræmmende. Du kan ikke rigtig læse det venstre til højre. Faktisk, for det er for det meste tegnsætning nu i stedet for faktiske ord, Jeg kan slags udlede, at "Document.getElementById" får et element fra dokumentet ved sin ID. Jeg kan virkelig bruge sådan aliaser fra denne ting her. 

Så det er en afvejning. Der er en raffinement, der kommer ofte med anvendelse af biblioteker, især ligesom jQuery. Men virkeligheden er jQuery har form af blive en de facto standard, således at næsten alle disse dag, der skriver JavaScript-kode bruger jQuery eller noget lide det, og ikke længere skriver sådan en ordrige udtryk som dette, fordi igen, menneskeheden har lært, wow, det var slags en forspildt chance at gøre vores liv lettere. Så mennesker gøre deres liv lettere. Godt spørgsmål. 

Andre sprog til at overveje. Jeg vil sige blandt denne liste Ruby er meget populært. Og så i en verden af Ruby, der er en ramme kaldet Rails, hvilket er meget populært. Så Ruby on Rails er et almindeligt anvendt udtryk. Også i denne verden, lad mig cirkel Java til web kram, hvor i verden af ​​Java du måtte have JSP eller Java Servlets, som er en fælles teknologi. Og dette er blot igen måder at bruge at sproget i et servermiljø. 

Så hvad betyder det? Hvis du har fået en fysisk server, ville du bogstaveligt talt downloade webserversoftware og installere det på en sådan måde at du har støtte til en af disse rammer, som du kunne til gengæld bruge en eller flere af disse sprog. Og i virkeligheden, hvis du tilmelder dig som en web vært eller nogle af skyen tjenester, vi talte om i går, ofte de ting bare kommer med maskinens konfiguration for dig. Du behøver ikke at sætte dette op manuelt. Men hvis du gjorde, det er her den rolle af systemadministratoren, så at sige, kommer i spil. Han eller hun rent faktisk ville gøre den slags ting for dig, eller den såkaldte webmaster ville ofte gøre dette for dig. Okay. Eventuelle spørgsmål om nogle af disse her? Eller muligheder på alle til at spørge om sprog? Frameworks? Så lad mig introducere bare en anden bibliotek det er også meget almindeligt i disse dage. Denne liste kunne blive ved i det uendelige. 

Og dette bibliotek er lidt begyndt at falde i unåde. Det har været omkring. Det blev udbredt af Twitter i nogen tid. Og nu masser af hjemmesider, masser af udviklere bruger det. Men nye ting kommer ud og kommer sammen. Men lad mig bare give dig en følelse af, hvad det vil sige at bruge et bibliotek. Så igen, JavaScript er en meget populær sprog. CSS eller Cascading Style Sheets, vi talte om i går. Det er også er allestedsnærværende. Ingen gør en webside i dag uden brug af HTML og CSS minimalt. Men det er ikke altid let at gøre visse ting. 

Og så lad mig gå til getbootstrap.com. Ups. Det er ikke, hvordan vi staver. Getbootstrap.com, som kommer til at føre mig til destinationssiden for dette bibliotek. Så de generøst kalder selv en ramme, der er slags slags fair, men jeg vil stadig kalde det mere af et bibliotek end en ramme. Men disse er blot diskutabel semantik. Lad mig gå til deres fane CSS og lad mig gå til noget som dette. 

Så huske, hvad vores formularer så som i går på Cloud9? Det var temmelig grim. Old school knapper. Jeg tror på knappen var grå af misligholdelse. Og alt var virkelig formateret ganske messily. Så hvis du ønsker dine webformularer til at se lidt nicer-- lade mig zoome ind her. 

Og ved pænere jeg virkelig bare betyde meget nitpicky æstetik. Så læg mærke til hvordan den e-mail boks der har en afrundet rektangulære hjørner til det. Så det er lidt renere der. Bemærk, at ordet e-mail er der, indtil jeg begynder at skrive og så går det væk. Så det er en fin lille funktion. Bemærk hvordan de ting er slags glødende pænt, som nogle af disse du få gratis fra din browser, men nogle af disse er også biblioteker, kode, som andre mennesker har skrevet, at give dig denne. 

Noget som dette giver mig min adgangskode. Denne knap er lidt mere sexet end den misligholdelse. Meget meget på mode lige nu. Lige siden iOS 7 eller deromkring, verden har fået meget fladt, mens verden før havde masser af skyggeeffekter, masser af refleksioner over ikoner. Meget gerne i tøj verden, der er modetrends der kommer og går. Nu er alt er fladt på din telefon. 

Faktisk knapper på din iPhone er nu bare blå links. Der er ikke ofte endda cirkulære knapper. Så disse er blot ting at gå ind og ud af mode, og så dette er, hvordan du kan lave en mere moderne leder webformular. Knapper. Så Bootstrap har masser af smukke knapper. Så hvis du ønsker blå knapper, grønne knapper, blå, orange, rød. Bootstrap gør det nemmere at gøre disse ting. Det er den slags ting at du kunne absolut har gjort i går med CSS og med HTML, men det er bare en smerte i nakken. Og så i stedet, hvad Bootstrap ville har du skal gøre er noget som dette. 

Hvis du ønsker en button-- viser sig dette er en HTML-tag vi ikke bruge yesterday-- og du vil have det til at se som denne grønne knap, du bogstaveligt talt bare give det en klasse, som vi gjorde taler om i går, af "BTN Btn-succes." 

Hvorfor disse ord? Twitter, forfatterne af Bootstrap, kom op med disse ord. De kunne have kaldt dem noget, de ønsker. Men hvad du får nu, er en anden på Twitter, i dette tilfælde, har regnet ud, hvordan kan du lave en knappen ser pæn og ren og grøn. De pakkede op denne funktionalitet i en CSS-klasse, kaldet "btn" og "btn-succes", så at nogen af ​​os kan nu bruge det uden at tænke over det. Så de har abstraheret væk begrebet en grøn knap så vi ikke behøver at bekymre sig om gennemføre det selv. Vi kan faktisk fokusere på at gennemføre ting af interesse for os. 

Hvis vi rulle ned her. Fejlmeddelelser på skærmen. Nogle gange du vil have lidt besked til at blive vist på toppen af ​​browseren. Enhver af os kunne gøre dette med nogle indsats, efter gårsdagens lektion men hvorfor ville du gider? Det er sådan en uinteressant æstetiske detaljer. Lad os stå på skuldrene af Bootstrap og lad dem give os ting som dette, hvor vi bogstaveligt, for at få en rød boks, bare nødt til at gøre et stykke tag med en klasse of-- ked af det. "Bg-fare" ville give os denne rødlig boks i stedet. Lad os nu gå til mere interessante ting. Hvis jeg går tilbage til toppen af denne side og gå til komponenter, nu verden bliver mere interessant. For eksempel, meget almindelig er drop down menuer som denne. Dette ville være et absolut smerte at gennemføre. Og det var ikke så længe siden, vi programmører skulle gennemføre disse former for menuer fra bunden. 

Men det er sådan en fælles paradigme at bibliotekerne som Bootstrap bare give dig mulighed for at gøre en drop down menu langt, langt lettere. Der er ingen måde at gøre det, men hvis jeg læser dokumentationen Jeg vil se, at, OK, jeg skal bruge denne HTML, hvis jeg vil have en drop down menu der opfører sig sådan. 

Ligeledes, lad os gå til knappen falde ned. Så dette er endnu mere avanceret. Hvis jeg ønsker, at dette at ligne en knap men den lille trekant betyder Jeg skal klikke på det og få denne menu, dette er at bruge et sprog kaldet JavaScript. Og vi kunne alle implementere dette i JavaScript. Men igen, det er et hjul du ikke ønsker at genopfinde. Du vil bare tage det ud hylden bibliotek til dette. 

Lad os gå til noget ligesom fremskridt barer. Så noget som dette er slags cool. Hvis du nogensinde har set en fremgang bar flytter hen over skærmen, gennemførelsen, som ofte er blot en spinning-ikon. Faktisk lige som en sidebemærkning, lad mig gå til Ajax-- hvad er det? Ajax info? Ups. Ajaxinfo. Lad mig huske adressen. Sådan der. 

Så hvis du nogensinde har set nogle animation mens siden indlæses, eller tænker, eller besparelse, eller skabe noget, du kunne se sådanne animationer som disse. Så lad os se på noget som denne her, og lad os vælge en forgrundsfarve af grøn, som føles slags venlige. Kan jeg klikker på dette? Kom en. OKAY. Vi vil bare gå med rød, fordi det er, hvad vi får. Så her har vi det. 

Så hvis du nogensinde har set dette på en skærm, hvorved pludselig ser det ud, og derefter pludselig forsvinder, hvad der er det, der er at gennemføre det? Nå, det er bare et GIF. G-I-F. Og dette er en animeret fil, som netop betyder det er ligesom en gammel skole tegneserie. Der er bare en masse forskellige rammer, der går [Stammen] og bare gentage. Og det er at skabe illusion af bevægelse. 

Så så snart en side er færdig lastning eller gøre noget, hvad gør en programmør gøre? Nå, han eller hun bare skjuler dette billede. Så alle en statuslinje er der slags ligesom en film, du ser. Du er slags uvidende om det faktum, at det ikke er faktisk at gøre noget, det er bare at flytte. 

Og så, når det er gjort fremskridt, de bare skjule det eller slå det fra. Og det er alle de magiske der foregår der. Bootstrap giver dig noget lidt amatør, hvor du kan faktisk se en procentdel, som det går, men det er også bare slags af en simpel animation. 

Lad os se på nogle endelige mere komplekse eksempler her. Noget som en modal. Er der nogen der ved, hvad en modal er? En modal vindue er generelt én, der formodes at tage kontrol over forgrunden og forhindre dig i at gøre noget andet. Det tvinger slags brugerens vægt på midten af ​​skærmen, låse dem ud, typisk, af alt andet. 

Så hvis jeg lancere denne demo, den Skærmen vil generelt blive grå. Nå, hvordan gør vi det grå? Nå, vi sandsynligvis bare ændret baggrundsfarven ligesom vi gjorde i går eller sådan noget. Måske er det en overlejring at semi-transparent. Og nu mærke, at du kan gøre fancy ting som dette. Så hvis du nogensinde klikker på en knap og ønsker en lille pop ud til at blive vist, du kan gøre det. Og så hvem bekymrer sig om all-- ikke? 

PUBLIKUM: Så med Bootstrap, at få det indarbejdet, er det så simpelt som som i går vi gjorde siden CSS? DAVID J. MALAN: Ja. Rigtig godt spørgsmål. Lad mig gå til Kom godt i gang. Og ja. Alt du skal gøre for at Anvendelse Bootstrap er hovedsagelig kopiere og indsæt disse tre lange rækker af kode i toppen af ​​din egen web page-- lederen af ​​din page-- og du er oppe og køre. Og der er forskellige måder at gøre det, ville men dette være den enkleste. 

Så hvad er nyttigt om alt dette? Tja, hvis du ikke er så meget den iværksætter af en hjemmeside men du forsøger at designe det, eller du ønsker at give nogen med wire frame diagrammer, så at sige, eller bare kunstners gengivelser af, hvad du ønsker at gøre, jeg, at dette dag, vil ofte gå til et websted ligesom Bootstrap, hvor, hvis jeg ønsker at gennemføre something-- ligesom nylig på campus vi ønskede at gennemføre et webbaseret værktøj til at navigere Harvards kursuskatalog, gør det lettere for studerende at gennemse kurser og tilføje kurser til indkøbsliste, så at sige, at slags beslutte, hvad de ønskede at tage. 

Jeg forsøgte at forestille sig for mig selv, hvilke ingredienser ville vi vil bruge til at bygge denne? Hvad ville brugergrænsefladen være? Og bare kigge gennem et site som denne eller andre sådanne bibliotek sites, du kan få inspiration, fordi wow, Jeg kan bruge denne widget, og denne widget, og denne widget. Og så virkelig, hvad programmøren starter at gøre, især i disse dage i denne mere moderne verden af ​​web-programmering, er programmering er i stigende grad om ledninger ting sammen. Slags tage dette fra hylden, dette fra hylden, dette fra hylden, og du bliver smart én at forbinde alle disse prikker, men i sidste ende bygge noget ved igen stående på skuldrene af andre, så du ikke tilbringe en måned gennemføre en dum rullemenu, der er faktisk svært at gøre, hvis du vil have det til at arbejde på Chrome, og IE og Firefox, og enhver antal andre browsere. Det er derfor, der er denne rige kommercielle og open source-software industrien såvel. 

PUBLIKUM: Så betyder Bootstrap få opdateret og du skal derefter opdatere dine links? 

DAVID J. MALAN: Det gør. Nå, ja, det gør. Bootstrap er i øjeblikket på versionen 3.3.6. Og generelt, hvad du ville do-- dette er faktisk værd at nævne. Der er hvad der er generelt kendt som en semantisk versionering system i verden. Ikke alle gør dette. 

Men hvis du har set versionsnumre der er af formen x.y.z-- så for eksempel den første version af et program kan være 1.0.0. Eller hvis det er meget, meget beta eller selv alfa-status, hvilket betyder brug på egen risiko, er det ikke virkelig klar til prime time, du kan endda begynde 0.0.1 eller nogle sådanne betegnelse. Men hvis software starter versionen 1,0, eller ækvivalent 1.0.0, typisk, hvad der er fælles disse days-- dog ikke omnipresent-- er hvis en virksomhed eller en enkelte programmør rettelser nogle fejl i nogle stykke software, der virkelig var en fejl, hvis korrektion ikke indvirkning dig på all-- det ikke ændrer programmets adfærd, det bare løser noget der ikke fungerer properly-- du ville typisk opdatere z-værdi der. Hvilket betyder en som Kareem kunne simpelthen gå ind i hans hjemmeside, blindt ændre versionsnummeret fra 1.0.0 til 1.0.1, gemme det, sende det, og i teorien ikke at bekymre sig, at han bare er brudt hans hjemmeside på grund af nogle manglende funktionalitet, fordi noget andet brød. 

I mellemtiden, hvis jeg programmør eller nogle selskab var at gøre nogle betydelige ændring, der tilføjer funktionalitet, Jeg kunne opdatere os til 1.1.0 fordi jeg er faktisk ændrer adfærd biblioteket. Jeg giver dig måske mere funktionalitet. Endelig, hvis jeg skulle faktisk grundlæggende ændre softwaren, så meget, at det vil bryde mange brugernes hjemmesider eller applikationer, så er jeg forpligtet til i denne model, at opgradere overordnede version også, som er en bryde ændring. Med andre ord, kunne jeg have ophørte støtte til dem, drop down menuen. Så hvis du opgraderer til 2,0, halvdelen din hjemmeside kan stoppe med at arbejde. Og det er en slags signal til samfundet om, hvad der er involveret i at gøre en opgradering. En god mulighed for at rejse. Andre spørgsmål? Okay. Jamen så lad os tage et kig på en sidste emne i dette segment af programmering af teknologi stakke, nemlig vedrørende mobilt. 

Så i verden af ​​mobiltelefoner i dag du have-- og iPads, og overflader, og alle den slags af enheder: du har en masse valg, når det kommer til at gennemføre et program eller en hjemmeside for din kundes mobile enheder. Så bare at angive indlysende, måske i disse dage, hvad er de platforme til udvikle til i det mobile rum? Hvilke enheder vil du måske støtte med din app eller hjemmeside? 

PUBLIKUM: Apple. DAVID J. MALAN: OK. Så Apple-enheder. Så det betyder iPhone, og at betyder iPad, og måske endda iPod. Hvad ellers? Olivier? 

PUBLIKUM: Android. 

DAVID J. MALAN: Android. OKAY. Så Android-telefoner, Android tabletter, Android Market er endda Messier because-- og selv Apple er ved at blive rodet. Ud fra følgende betragtninger engang iPhone var en vis størrelse, og iPad var en vis størrelse, og iPod var en vis størrelse, nu vi har iPad Minis, og den tynde dem, og iPhone 6 Plus og 6. Det er ved at blive noget rod. Det er blevet Android verden. 

Og jeg siger dette med slags rullende mine øjne, fordi fra en udviklers perspektiv er det en smerter i halsen, når du ikke har Steve Jobs ' vision af absolut kontrol over alle disse specifikationer. Apple stadig gør, fordi de er dem bygge hardware. Men det er en dejlig ting, hvis Jeg er en softwareudvikler, bare vide, at min iPhone vil altid at være denne store, fordi det betyder at jeg altid ved hvor meget skærmplads jeg har. Så hvis jeg ønsker at sætte et ikon i øverste venstre hjørne, det vil være i præcis samme placere på hver enkelt kundes enhed. 

Men i en verden af ​​iPhone 6s og iPhone 6 Plusser og i verden af ​​Android telefoner, det er over hele kortet. Og så det gør det sværere at programmet ting, især brugergrænseflader, fordi nu er du nødt til at begynde at arrangere dine brugergrænseflader relativt, ikke absolut. Og det samme har været tilfældet på browsere, og desktops og bærbare computere til år fordi man naturligvis har forskellige skærmstørrelser. 

Hvad ellers? Du har måske overflader, gerne fra Microsoft. Du har måske have-- PUBLIKUM: Windows-telefon. DAVID J. MALAN: Hvad er det? PUBLIKUM: Windows-telefon. DAVID J. MALAN: Ja. Så windows telefoner kan stadig findes. Kind of slags BlackBerrys, men de holde forsøger. Og så klaser af andre enheder. Så for det meste, lad os sige det er dem at bekymre sig om i øjeblikket. Bestemt Apple ting, sikkert Android ting, og blandt Windows, ligesom overfladen tabletter synes at fange på ganske godt. 

Og så blandt disse enheder, hvis du ønsker at rulle ud, lad os sige, en mobil tilstedeværelse for din selskab, hvilke typer af design beslutninger har du at gøre? Nå, vi allerede sagt i Apple verden, der er mindst to sprog der anvendes typisk. Den ene blev kaldt hvad? 

PUBLIKUM: Objective-C. 

DAVID J. MALAN: Ja. Så Objective-C, som er den ældre. Det er også det sprog, som mange Mac ansøgning fortsat skrevet på. Så den anden nyere ene var? PUBLIKUM: Swift. DAVID J. MALAN: Swift. Og dem er den slags to at vide for at imponere folk. Så i Android verden, hvilket sprog betyder Android bruge? 

PUBLIKUM: C #? 

PUBLIKUM: Java. 

DAVID J. MALAN: Java er sprog "du jour." I Windows verden, sikker, vi vil sige C # i dette tilfælde. Så allerede det er form for irriterende, fordi det er takeaway for en virksomhed ejer eller en person, der bare ønsker at udrulle en mobil tilstedeværelse? Ligesom, for pokker? Ligesom, hvis jeg ønsker at støtte en temmelig bred brugerbase, Jeg er nødt til at skrive, synes det, tre særskilte ansøgninger. En ud af et af disse sprog, en i Java, en i C #. Og selv om jeg ønsker funktionaliteten at være identiske, er det ligegyldigt. Jeg stadig nødt til at bruge forskellige sprog, fordi Apple og Microsoft, og Google al støtte forskellige miljøer. Og det har været en udfordring for år. Tilbage i dag, hvor folk bruges til at købe software ved en computer butik i skrumpe indpakket kasser, ville du enten nødt til at nå til Mac hylde, eller for-- måske denne meget lille Mac shelf-- eller større Windows hylden og købe noget software. Og meget ofte, var der ikke engang noget for dig på Mac hylden. Hvorfor? Nå, besluttede virksomheder, hvis 90% af verden, 95% af verdens har pc'er, hvorfor gider selv gennemføre ting på Mac OS? 

Som en aside-- alt digression-- hvorfor er det at Mac virker så uigennemtrængelig for virus, og orme og sikkerhedstrusler? Er Apple bedre på dette? Bedre at holde computere sikker? 

PUBLIKUM: Mindre publikum? 

DAVID J. MALAN: Det er sandsynligvis den større bit til den. Så de mange brugere af Mac-computere har længe hævdet, åh, bruger en Mac, vil du være immun over for virus, og orme og alle disse ting der længe har plaget pc'er. Det kunne være fordi Apple har bedre programmører og de skriver bedre software, eller Operativsystemet blev bedre designet. Måske, men sandsynligvis ikke. 

Det er nok, at når du er en 12-årig, eller en 30 noget slags sidder derhjemme skrivning skadelig software til at overtage verden, er du nødt til at gå efter den meget større målgruppe. De 95% af verden, som måske køre Windows eller nogle varianter heraf. Så der er en lille smule på begge sider. Men til deres kredit, Apple, så vidt jeg ved, har ikke rigtig udråbt sig som værende mere sikker, da du bare invitere drama, hvis du gøre denne påstand, vil jeg mene. 

Okay. Uden at blive alt for langt ned det, hvordan løser vi dette? Har du nødt til at købe eller har du til betale tre forskellige folk til at udvikle dine apps? Har du vælge en frem for den anden? Hvad skal guide din tænker her tror du? Kareem? Nope. En anden. 

PUBLIKUM: Bare kom med hardwaren. DAVID J. MALAN: Kom med hardwaren? Hvad mener du? 

PUBLIKUM: For miljø. [Uhørligt] DAVID J. MALAN: Så det er sandt. Men dine kunder, i mellemtiden, kan have iPhones, de måtte have Android-telefoner, de kan have tabletter lavet af Microsoft. Så hvordan kan du have en mobil strategi for alle disse forskellige brugere? Det ser ud til, at hvis det koster, lad os sige $ 1.000 til at gøre en iPhone ansøgning, går det til at koste dig $ 2.000 til at gøre en iPhone-applikation og en Android applikation, eller $ 3000 til også understøtte Windows-enheder så godt. Det er nok noget af en underdrivelse, og det måske ikke engang være en lineær sammenhæng sådan. 

PUBLIKUM: Hvis du ønsker at have en app eller ikke, kan du få lydhør hjemmeside. DAVID J. MALAN: Godt. PUBLIKUM: Eller du kan have en indfødt app. DAVID J. MALAN: Ja. Så i al denne sammenhæng her, Vi har talt om, hvad folk ville kalde native applikationer. Det er programmer, der er skrevet i sproget, der tales pågældende enhed. Så indfødte Objective-C eller Swift kode, eller i Java, eller C #. Hvilket betyder, når du downloader, lad os sige snapchat, en populær applikation, eller når du henter Facebook for en telefon, du henter enten udgave skrevet til din iPhone, eller skrevet til din Android-telefon, eller skrevet til din overflade. 

Men der er et alternativ. Som Olivier hentydede til, du rent faktisk kan bruge HTML 5 i stedet, ved hjælp af, hvad der kaldes en web ansøgning, hvor du bare implementere din mobiltelefon tilstedeværelse og enhver funktionalitet. Hvad mener jeg med mobil tilstedeværelse? Ligesom din websted, der har din kontaktoplysninger, en liste over alle dine produkter, måske det har en shopping vogn, måske du sælge ting igennem det. Uanset hvad din ansøgning er, du gennemføre den, ikke i Objective-C, eller Swift, eller Java eller C #, men i HTML 5, som var det sprog, vi kiggede i går, med JavaScript og CSS. 

Og hvad er rart om dem tre er, at for at køre dem, du har brug for lige hvad stykke software? PUBLIKUM: En webbrowser. DAVID J. MALAN: En webbrowser. Og det bedste jeg ved, alle disse enheder leveres med webbrowsere, så brugeren ikke har skal installere noget særligt. Så du kan bare fortælle din publikum, dine kunder, gå til acme.com i din browser og du vil bare har en web-baseret oplevelse der stadig fylder skærmen, men du behøver ikke at bekymre sig om alle disse omkostninger og alt dette kompleksitet. Men mon der ikke kommer at være en fangst her, ikke? Især hvis jeg påpege at et par år siden, den allerførste udgave af Facebooks mobilapplikation var for det meste en HTML 5 ansøgning. Og de har, mere nylig, genimplementeret det i deres andre applikationer. 

Så hvorfor skulle du ikke straks ønsker at sige, godt, selvfølgelig vil vi gøre det? Hvad kan de skjulte omkostninger være? 

PUBLIKUM: Performance. DAVID J. MALAN: Performance? Hvad mener du? 

PUBLIKUM: De indfødte app har mere ydeevne. 

DAVID J. MALAN: Så det er sandt, for et par grunde. Vi kan forsimpler svaret. Og huske vores diskussion af fortolket versus kompilerede sprog. Dette er HTML 5, og med det, bare for at være klart, JavaScript-- almindeligvis skrevet JS-- og CSS er alle fortolket sprog, selvom kun JavaScript er et programmeringssprog. 

Og så versus disse, hvor nogle af disse er opgjort, i det mindste disse three-- Objective-C, Java og C # - disse, i teorien burde bare være hurtigere. Men der er en anden virkelighed for-- 

PUBLIKUM: Funktionaliteter? 

DAVID J. MALAN: Hvad er det? 

Målgruppe: funktionaliteter. 

DAVID J. MALAN: Funktionalitet? Hvordan det? PUBLIKUM: Brug kameraet fra din telefon eller noget. Du kan bruge dem med browseren. DAVID J. MALAN: Præcis. De er sec-- PUBLIKUM: [uhørligt] DAVID J. MALAN: Det er en anden god en. Der er funktioner, der kommer med mobiltelefoner i dag som ikke er, ved design, for sikkerhed årsager, tilgængelige for webbrowsere. Fordi det ville være slags en uhyggelig ting, hvis bare når du besøger google.com, eller cnn.com, eller enhver website.com, at denne hjemmeside har magt til at vende på dit kamera, tage et billede af dig, og derefter bruge det. Men du ønsker ikke en tilfældig hjemmeside at du besøger for første gang at have denne evne. 

Og så hvad telefon producenter typisk gør er de bare nægte adgang til den slags oplysninger til en browser, hvilket betyder at du kan ikke gennemføre kameraet. Du kan ikke implementere push-meddelelser, de bip, som du får på skærmen med korte beskeder. Og i virkeligheden, selv GPS er eneste form af slags til rådighed for webbrowsere. Hvis du nogensinde har, på en bærbar computer eller på en mobil enhed, trukket op noget som måske CNN.com, men også lokale nyheder stationer en tendens til at gøre dette, bliver du bedt ofte med en message-- foxnews.com ønsker at vide din placering. Godkende eller afvise. 

Nå, er browseren forsøger at få adgang din GPS-oplysninger fra din telefon. Men heldigvis Microsoft, og Apple og Google har besluttet, at føles Det er en nyttig situation vi ønsker Google Maps og andre værktøjer til at arbejde, men vi ønsker ikke at krybe folk ud ved blot gør et websted for at gøre dette. Så lad os slags mødes halvvejs og bede brugeren. Men det er ikke nødvendigvis tilfældet med al hardware, ligesom kameraet og med push meddelelser og lignende, så du måske nødt til ofrer visse funktioner. Men præstationer også. Det er blevet mindre mærkbar i dag, måske som LTE fangster og hurtigere internet hastigheder på telefoner, men du kan slags mærke forskellen. Ligesom en webbaseret applikation bare føles langsommere, typisk, end en indfødt ansøgning, dels fordi en webbaseret applikation per definition er på internettet. Det taler til serverne på nettet. Og hvis din netværksforbindelse er langsom, selv rulle kan være langsom. 

Men en indfødt ansøgning, du har allerede før downloaded-- sandsynligvis når du var hjemme fra app store, eller du i det mindste på forhånd downloadet det i sin helhed tidligere, uanset din tilslutning fart- og så nu har du alle de bits, at du generelt har brug for. Bortset måske nogle data der kommer fra en server. 

Så dette er afvejninger her. Der er lidt af en mellemvej kompromis, faktisk. Og jeg tror du-- 

PUBLIKUM: Brug data offline. I de indfødte apps, kan du [uhørligt] DAVID J. MALAN: Absolut. Så der er offline problem, som er virkelig irriterende hvis du ikke kan spille nogle spil eller brug noget software bare fordi du er i en kælder eller andet sted eller i en elevator. En indfødt ansøgning er robust med større sandsynlighed mod denne, forudsat du har alle de data, du har brug for lokalt. 

Så der er en tredje mulighed her. Og lad os trække spektret som native app her og web app her. Og hvad der er i midten er noget called-- og jeg tror, ​​du måske har brugte ordet før, måske? Hybrid ansøgning. Og som ordet antyder, det er noget i midten. Det er lidt af en web-applikation og det er form for en indfødt ansøgning. 

Og hvad betyder det? Det viser sig, der er frameworks-- at bruge et udtryk fra earlier-- software at andre mennesker har skrevet for hver eneste af disse platforme. Disse og endnu andre enheder. Faktisk lade mig gå til PhoneGap, som er en sådan ramme, jeg tror Adobe ejer nu. Lad mig gå til Kom godt i gang. Lad os se. Se om jeg kan se en liste over værktøjer. Hardware. Kom godt i gang. PhoneGap hardware. 

Lad os se. PhoneGap hardware adgang. Lad mig se, om vi kan finde en lille kortlægge, at de plejede at have. Dette er på en anden lokalitet. Er det nyttigt? Ingen. Det skal nok spilde vores tid. PhoneGap hardware. Enheder. Device API. Nope, de har flyttet det. 

PhoneGap. Lad os gå et sidste kig på denne og se om jeg kan vise dig. Kom godt i gang. Installer PhoneGap. Installer mobile app. Kom nu. De har reorganiseret alt. Okay. Åh, okay. Nå, her går vi. Det er ikke alt, oplysende, men dette er hvad jeg var slags på udkig efter. 

Så PhoneGap er en ramme, som du kan downloade gratis, som giver dig nogle forret kode væsentlige. Så noget kode, som de har skrevet der ikke gør meget af noget. Men hvad det giver dig væsentlige svarer af en ansøgning, der bare sætter en store rektangel på brugerens skærm. Det betyder ikke sætte en URL bar, ligesom en browser, ikke sætte en adresse. Det bare lægger et stort rektangel. Og du konfigurerer denne store rektangel, under emhætten, faktisk gå til acme.com, eller måske m.acme.com, for mobile.acme.com, men brugeren ikke ved de er på denne adresse. Alt, hvad de ser, er den indholdet af websiden. 

Men hvad er nice om dette væsen en hybrid app er, at hvad PhoneGap og andre selskaber giver dig er de giver dig en lille smule kode i Objective-C eller Swift, eller en lille smule af kode i Java, eller en lille smule kode i C #, og i det væsentlige, alt hvad du skal give er minimalt den adressen på din web-baseret applikation. Og så samle dette alle sammen, og du har det enten adgang til websted via internettet, eller du endda cache en lokal kopi inde i programmet, og derefter gemme dig din ansøgning i iPhone-format, Android-telefon format, overflade format, eller en række andre enheder. 

Du uploader hver af disse versioner til Google Play Store, til App Store, til Windows Store, og så videre. Og nu kan du få alle dine publikum hente virkelig en indfødt app, omend det meste af koden var skrevet af en anden, men indholdet af den native app alle kommer fra, typisk din egen hjemmeside. Så du fortsætte med at skrive din hjemmeside i HTML, JavaScript og CSS. 

Så hvorfor sløre disse linjer? Hvorfor en hybridansøgning der er slags indfødte, men også form for webbaseret? Hvad er hele pointen med tilføje denne kompleksitet? Jeg mener, endda stadig, bare fra kigger gennem denne side, Kom godt i gang guide føles det har fået en hel masse trin for mig at gøre, før jeg can-- PUBLIKUM: Genbrugelighed? DAVID J. MALAN: Genbrugelighed? Hvad mener du? 

PUBLIKUM: Af kildekoden. Så den samme kode ville køre på alle de forskellige platforme. DAVID J. MALAN: Ja. PUBLIKUM: [uhørligt] DAVID J. MALAN: Perfekt. Hvis tiden er stram, og hvis du behøver ikke at mange developers-- måske har du en udvikler og han eller hun sikkert kender ikke alle disse environments-- bestemt ikke godt, og bestemt ikke kan program i alle tre samtidigt og sende tre produkter i fristen for én, du kan få ham eller hende bygge alting i HTML og JavaScript og CSS, og derefter lære en lille smule lidt om indfødte apps, lige nok til at hente en ramme som denne, til derefter uploade dit produkt til alle de forskellige app stores så du nu har en indfødt ansøgning. 

Så det virker som en win-win, men igen, for at være klar, Hvilke potentielle omkostninger eller de fælder? 

PUBLIKUM: Performance? DAVID J. MALAN: Ja. Ydeevne. Det er svært at beskrive verbalt. Så hvis du bare tage på tro en mobilapplikation, en web-applikation vil typisk udfører langsommere. Det ser måske ikke helt rigtigt, fordi i iPhone, og i Android-telefoner, og Windows-enheder, der er altid en slags standard udseende og føler at alle de knapper og menuer. 

Og virksomheder i nettet, kan du prøve at tilnærme disse æstetik med biblioteker som Bootstrap, men user-- en klog user-- vil vide, at noget er ikke helt lige her. Og det er fint, måske det er ikke en big deal. Men spørgsmålet ydeevne absolut er en big deal. Native applikationer vil være tilbøjelige til bare være meget mere fleksibel og dermed bedre. Og ja, hvad så kunne være det bedste af begge verdener? Hvis du er især en lille selskab eller en lille gruppe, du ikke har ressourcer at udvikle en app i parallel på alle tre platforme, og helt ærligt, føles som det er en dårlig idé alligevel fordi hvis du ruller det ud og om alle tre samtidigt indse, vi burde have tilføjet nogle funktioner eller gjort noget anderledes, nu du er nødt til at ordne det i tre steder, ikke én. Hvad er måske den optimale strategi her samlet, hvis ressourcer og tid er stramme? 

PUBLIKUM: Bare gør det på iOS. 

DAVID J. MALAN: Det er ikke urimeligt. iPhones, i det mindste i USA, er super populære. Android stadig synes at have dominerende markedsandel, globalt, samlet. Så du er ikke nødvendigvis repræsentativt af helheden af ​​kloden denne uge. Men det er absolut en beslutning. Jeg mener, på campus her jeg tror nogle grusomme tal eller procentdelen af ​​bachelorstuderende har iPhones og ikke Android-telefoner. Men i udlandet, det er form for det modsatte. Så du beslutter baseret på din målgruppe. Hvordan ved du, hvad din målgruppe har? 

Nå, vi lærte et trick i går. Du kunne spørge dem. Hvis du har et fangenskab publikum du kan sende dem en undersøgelse formular. Eller du kan bare gøre hvad? 

PUBLIKUM: Google Analytics? 

DAVID J. MALAN: Hvad er det? 

PUBLIKUM: Google Analytics. DAVID J. MALAN: Google Analytics. Ja. Eller endnu mere slags teknisk, bare se på dine egne webservere logs. For hvad sker der hver gang en browser, hvorvidt laptop, desktop eller telefon besøge din hjemmeside? De sender den HTTP header, som viser dig, hvad browser og OS de bruger. Så du kan udlede, med stor sandsynlighed, hvad din demografiske bruger på den måde og derefter justere. 

Så formoder, det er uacceptabelt. Det er slags dårligt for erhvervslivet, hvis Android-brugere kan ikke købe vores widgets. 

PUBLIKUM: Uanset om du er vil oplade eller ej? DAVID J. MALAN: Om du kommer til at oplade? Så OK, du får hvad du betaler for. 

PUBLIKUM: Uanset om din app er nok være fri, eller om det er gonna-- 

DAVID J. MALAN: OK. Så måske du kunne forrente omkostninger på den måde, eller--? 

PUBLIKUM: Jeg læste en undersøgelse, når det sagt flere Apple-brugere betale for apps versus-- DAVID J. MALAN: Det er rigtigt fordi de er allerede betale mere for deres enheder. Så ikke urimeligt en antagelse. 

PUBLIKUM: [uhørligt] DAVID J. MALAN: OK. Så hvis de er mere villige til at betale, derefter til helvede med de Android-brugere. De er ikke til at betale os noget alligevel. Vi kan lige så godt fokusere vores prioriteringer, i det mindste for de første par måneder eller et år, på iOS. Fuldstændig rimelig. Hvad er et mere rummeligt strategi end det? Maybe-- hvad er det? 

PUBLIKUM: [uhørligt] 

DAVID J. MALAN: En mere expensive-- så måske investere mere in-- gå videre. PUBLIKUM: Ja. Bare en mobil hjemmeside. 

DAVID J. MALAN: Så gør en mobil hjemmeside og ikke selv bekymre sig om denne kompleksitet. Eller måske en fornuftig strategi, som selv Facebook tog, er at starte med en hybrid ansøgning, fordi det ikke er at meget sværere at gøre dette end dette. Du skal bare nødt til at læse nogle dokumentation og finde ud af hvordan at uploade ting til App Store. Så måske du starter med dette, således at på dag ét, du kan støtte alle dine brugere. Og så, ligesom Facebook og andre selskaber har gjort, når du har ressourcer, du har de mennesker, hvorfor du ikke på ny at gennemføre bare iOS ansøgning. Du har stadig noget for alle, selvom det er en ringere oplevelse måske, med hybridansøgning. Men du kan gradvist rulle ud og udskifte kort sigt foranstaltninger for de hybride apps med dine mere native applikationer. 

PUBLIKUM: Men med en hybrid app du vil have adgang til mobile funktioner? 

DAVID J. MALAN: Ikke nødvendigvis. Så måske du laver en bevidst beslutning tidligt, du kan kun uploade fotos på native iPhone ansøgning om Facebook, men ikke på Android ansøgning, oprindeligt, f.eks. Og det er lidt af en hvid løgn, fordi web-applikationer har flere begrænsninger end hybrid applikationer viser det sig ud, og hvis vi læser dokumentationen for PhoneGap og ting som det, folk er kommet op med måder at give web-baserede applikationer adgang til kameraet, så længe du bruger en hybrid program. 

Hvordan kan det fungere? Fordi den hybride ansøgning, per definition, har lidt af kode i Objective-C, og Swift, og Java, eller i C #, det kan få adgang til hardware. Ikke nødvendigvis alt, men det kan meget vel være tilfældet, at du har nok adgang til at få kameraet, selv for Android-platforme, for Eksempelvis ved, at kunstig eksempel. 

Andre spørgsmål? Okay. Hvorfor vi ikke tage vores 15 minutter pause her. Vi genoptager på tre med en endelig se på web programmering, databaser, og Javascript.