>> DAN ARMENDARIZ: Hej, og velkommen til en CS50 seminar om Tilpasning Cloud 9,
og CS50 IDE.
Så i dag vil vi bare snakke lidt
om nogle af de tekniske oplysninger,
går bag arkitekturen af Cloud 9, og hvordan
Vi har gennemført nogle af de plug-ins som en del af Cloud 9 at give CS50 IDE.
Så lad os bare hoppe direkte ind og begynder at tale om plug-ins.
>> Så plug-ins er virkelig på Kernen i Cloud 9 oplevelse.
Cloud 9 er den underliggende teknologi der giver os IDE,
og også terminalvinduet på bunden, sammen med workspace--
Ubuntu workspace-- at vi bruge til at samle alle vores projekter
og udfører vores problem sæt, fuldføre vores problem sæt.
Men i hjertet af alle af det, al den teknologi
er egentlig bare en flok plug-ins.
Alt er en plug-in der kan ændres,
udvidet, kan du oprette dine egne plug-ins,
kan du fjerne andre plug-ins, for virkelig at ændre
en hel del af den funktionalitet, af den eksisterende Cloud 9 IDE.
>> Så det er en eksisterende Cloud 9 miljø.
Det er egentlig bare det standard Cloud 9 miljø.
Og tage et kig på, hvordan det rent faktisk er forskellig fra CS50 IDE.
Så dette er CS50 IDE.
Bemærk at der er en vis visuel ændringer mellem de regelmæssige Cloud 9
miljø og CS50 IDE.
Konkret vil du bemærke et par ændringer.
Først og fremmest, er der færre menupunkter til at begynde med.
Der er faktisk en måde at du kan ændre det.
Det hedder Simple Mode.
>> Som standard er Simple Mode aktiveret, og der forenkler nogle af menupunkterne.
Det fjerner nogle af de mere avancerede dem,
fordi ærligt, en masse studerende, der kommer i
og behøver ikke at vide om nogle af de mere avancerede funktioner
ikke overvældet med en masse muligheder.
Men vi giver evnen til at tage off disse såkaldte uddannelse hjul
og fjern det stilladser, så folk
kan blive mere vant til de avancerede funktioner i IDE.
Umiddelbart til højre for det, der er
også en debug-knap, som i standard Cloud
9 miljø er simpelthen kaldes løb.
Men som standard, har vi konfigureret debug knappen i CS50 IDE
at hente debugger, automatisk kompilere kildekoden,
tilslutte debugger til den underliggende GDB--
og da der er køre for at udføre den debugging-- og nogle andre skridt
samt.
Også terminalvinduet på very-- eller rettere terminalen
Fanen ved konsollen sektionen på vindue i bunden af ​​skærmen,
blev omdøbt til blot at være terminal.
Mens der i standarden Cloud 9 miljø,
det faktisk viser kørende program.
På denne måde forenkler igen, GUI, bare en lille smule.
>> Vi har også tilføjet nogle knapper til den øverste højre IDE
at vise nogle grundlæggende oplysninger om den underliggende instans.
Og også vi har fjernet en af optioner på de poster
fra det yderste højre.
Så alt dette gennemføres ikke ved at modificere nødvendigvis Cloud 9
kildekode, men i stedet igennem et par
af plug-ins, som vi har gennemført hele det forløbne år eller deromkring.
Og Cloud 9 har været vært og har kører i CS50 arbejdsområde.
Eller rettere i arbejdsområder, der er udpeget som CS50 IDE'er.
>> Så virkelig det er den væsentligste forskel mellem Cloud 9 og CS50
arbejdsområder.
Der er også, i det underliggende Eksempelvis den primære ændring er
at vi installere nogle præ-konfigurerede emner som GDB,
og nogle andre grundlæggende ting, vi har oprettet, ligesom opdatering 50,
og et par andre trin, der gør hele oplevelsen en lille smule mere
forenet.
Men generelt, dette er blot en ændring af et eksisterende system
at Cloud 9 har skabt for os.
Hvad vi vil viser lidt senere
er, hvordan man rent faktisk at skabe en noget grundlæggende plug-in,
tillader os at indsætte noget i menusystem, og åbne op for en dialog.
Og hvis vi har nok tid, vil vi faktisk
se, hvordan vi kan udfylde det dialog med nogle oplysninger
fra den underliggende instans.
For os at komme til at punkt, lad os først snakke lidt
om arkitekturen i Cloud 9.
>> Så den måde, som vi er vant at interagere med Cloud 9
er helt igennem klienten.
Vi åbner op en webbrowser, vi skriver i CS50.io.
Vi til sidst, efter godkendelse, er præsenteret med IDE.
Men indse, at der er et par skridt
der rent faktisk får os til dette punkt.
Den allerførste ting er, at min klient, webbrowseren,
efter anmodning og efter godkendelse, indlæser GUI og plug-ins
fra nogle CDN, fra nogle Content Delivery Network.
Dette kan være ærligt overalt.
>> Og det er faktisk adskilt fra den underliggende instans.
Det er vigtigt at indse, at dette er faktisk bare en masse statiske filer.
Det er en flok JavaScript der er hentet fra CDN
på min webbrowser, og alle GUI, du
se her-- det er virkelig key-- al den GUI, du ser her
køres på klientsiden.
Alt det, du ser i Cloud 9 arbejdsområde
er faktisk køre i browseren.
Og noget, du sender sammen med den underliggende instans
kommunikeres med forekomst langs denne anden separat kanal,
og gemmes derefter på at havnearbejder instans.
>> Så grunden til at jeg siger dette er en havnearbejder instans
er, at den underliggende teknologi ikke bruger virtuelle maskiner,
men i stedet bruger en teknologi kaldet havnearbejder,
som dybest set allows-- tættest analogi er en virtuel maskine.
Men det er subtilt anderledes i, at der er
masser af muligheder for at drive en kombination af forskellige havnearbejder
forekomster på en enkelt maskine.
Og de kan spindes op i meget hurtig rækkefølge.
Det er ikke helt den mere streng differentiering
mellem forskellige Docker instanser som der er i virtuelle maskiner,
men der stadig er en masse differentiering og adskillelse
mellem disse forskellige instanser.
OKAY.
Så de to trin her, er vigtigt at indse,
er, at når vi går til CS50.io, vi er downloade GUI og plug-ins,
der er skrevet i JavaScript, på til browseren eller til browseren.
Og det er måske et par megabyte værd af oplysninger.
På det tidspunkt, når GUI har indlæst og plug-ins er begyndt,
derefter begynder den at kommunikere med den havnearbejder eksempel, som ikke
nødvendigvis skal være den samme server.
>> Nu er der en undtagelse til dette.
Vi kan faktisk have både levering mekanisme til GUI selv
og havnearbeider eksempel i alle af samme server, som
er faktisk noget, vi gør til offline version af Cloud 9.
Det er ikke noget, vi har publiceret meget dette efterår,
men vi har også en offline version,
giver dig mulighed for at downloade en pakket version af alle disse ting
og giver dig mulighed for at køre Cloud 9 i en offline miljø.
>> Flytning dette fra skyen og på din lokale maskine har en vis indflydelse.
I særdeleshed, du ikke længere har evnen
til at dele dit arbejdsområde med andre.
Du behøver ikke længere kan åbne Cloud 9 fra, og CS50 IDE, fra enhver computer
og se de samme filer, du arbejdede med før.
Men i stedet virker det helt på din egen lokale maskine
uden at behøve adgang til internettet.
Men stadig, selv i denne model, selv selvom vi har en virtuel maskine
som i det væsentlige kører disse ting.
>> Vi har en separat server, der er levere væsentlige Cloud 9
indhold, og så vi har en havnearbeider eksempel
der er ansvarlig for at kommunikere med denne IDE til bagenden.
OKAY.
Så hele GUI skrives helt i JavaScript
hjælp node.js og Cloud 9 SDK, som vi vil komme til på bare et minut.
Og alle de plug-ins køres på klientsiden.
Så lad os fokusere derefter en lidt ved at antage
at dette første skridt har faktisk fuldført,
og ser kun på dette havnearbejder instans.
>> Så i dette tilfælde, er dette er den standard måde
at tænke på at gøre Cloud 9 plug-in udvikling er, at du vil
at skrive kode, der vil køres i brugerens browser,
og du har mulighed for at ved hjælp af nogle API'er til at kommunikere
med den underliggende havnearbeider eksempel køre noget kode der, og gøre noget
som du måske ønsker at gøre.
Så dette vil være sammenhæng, at vi vil
skal bruge i resten af ​​denne snak.
Og bare holde denne model i tankerne.
Det vil være meget vigtigt på blot et par minutter.
Der er et par links Jeg vil vise dig.
Først og fremmest har Cloud 9 forudsat en hel del dokumentation
Det er temmelig godt, der viser, hvordan til at gøre grundlæggende plug-in udvikling.
Så hvis du går til denne URL, cloud9-sdk.readme.io,
vil du se dokumentationen der.
Og en masse af disse oplysninger at du er ved at se
kan også findes der, plus mere.
Du kan også finde open source version af Cloud 9 på denne webadresse,
github.com/c9/core, som vi bruger som en del af offline-versionen af ​​IDE,
så du vil være i stand til at have den samme Cloud 9 erfaring,
men i en offline måde.
Okay.
Så lad os tage et kig på en faktiske Cloud 9 arbejdsområde her.
Og igen, jeg ønsker at pege ud et par ting.
Det er, lige her, en normal CS50 IDE.
Og jeg har deaktiveret en mindre behagelig tilstand under menuen Vis
så jeg kan se alle af menupunkterne.
Hvad jeg vil vise dig lige nu er et par ting.
First off, hvis jeg går ind de indstillinger og derefter
klik på Plug-in manager, og skriv CS50 her,
Vi kan se, at der er i virkeligheden, et par CS50 plug-ins,
blev installeret og vores kører til aktivere de ændringer, som vi har
set til CS50 IDE.
>> Lige nu er der væsentlige to plug-ins, der kører.
Der er en kaldet Simple, som er den forenklede tilstand,
giver dig mulighed for at reducere antallet af menupunkter langs toppen,
og har denne såkaldte mindre behagelig tilstand.
Og så er der også CS50 Stats, som er måske kun lidt misvisende.
Fordi det er det, viser dig de oplysninger
om den underliggende arbejdsområde.
Det tilfører disse knapper langs øverst til højre.
Det tilfører også et menupunkt i vindue element, ind i menuen Vindue
lige her, CS50 IDE Info.
Og det er ansvarlig for at instantiere denne dialog, som vi har set her,
med alle de oplysninger, vi er vant til at se i en CS50 IDE
arbejdsområde.
OKAY.
Så der er faktisk en mere plug-in at vi har udviklet så godt.
Og der er et par andre, Vi har heller ikke offentligt frigivet.
Men en af ​​dem er den overordnede plug-in som gør det muligt GDB til at fungere.
Så en af ​​de aspekter af Cloud 9 er, at de har givet allerede
dette GUI at gennemføre en debugger.
Og en af ​​de plug-ins, vi har skabt stort set
kroge GDB med GUI baseret version af en debugger.
Og er ansvarlig for at mediere alle af anmodningerne, som en bruger måtte have,
mellem at træde over eller skabe breakpoints eller noget
langs disse linjer, at oversætte det til kommandoer, GDB kan forstå,
udstede disse kommandoer til GDB.
Og så snart GDB udsteder en reaktion, så
vi fortolker det, og opdatere GUI som nødvendigt.
>> Det er sandsynligvis en af de mere komplicerede
af de plug-ins, så i stedet, hvad vi er vil fokusere på i dag, er i virkeligheden
de Stats plug-in, og vi vil tale en lille smule om Enkel, så godt.
Så jeg nævnte før, og jeg virkelig ønsker at gøre meget, meget klart, det igen,
alt dette, at vi er se her er i det væsentlige
opererer på klientsiden.
Vi kan se et terminalvindue nedenfor, og det er naturligvis,
hvis vi skriver i kommandoer ind at der vil blive udstedt derefter
til den underliggende instans.
Tilsvarende, hvis vi åbner en ny fil og skrive nogle ting i det og gemme det,
denne fil vil blive gemt på den underliggende instans.
>> Men redaktøren selv, dette terminalvindue selv,
er alle gennemført i JavaScript og er alle en plug-in
at vi kan interagere med, og dermed ændre.
Der er en masse udvidelsesmuligheder her.
Jeg anbefaler at tage et kig på Cloud 9 s GitHub konto
at se den enorme mængde plug-ins, der er tilgængelige,
og hvor godt skrevet en masse af koden er for udvidelsesmuligheder.
Så der er noget at jeg ønsker at nævne
om det så godt, som er at der er en masse of-- der er
en masse funktionalitet, der er forudsat i præferencer
vindue, som vi har set lige hentydet til blot et par minutter siden.
>> En af de ting, vi kan gøre som IDE udviklere, eller som Cloud 9 udviklere,
er rent faktisk at injicere nogle præference paneler af vores egne.
Så den enkle tilstand eller Den mindre behagelig tilstand,
og også IDE oplysninger eller statistik plug-in,
har hver nogle præference paneler, der tillader os at ændre
adfærd for hver af dem.
Du vil opdage, at hvis jeg går til Indstillinger og gå til Brugerindstillinger,
der er en fane CS50, en der siger IDE oplysninger.
Og jeg kan ændre oplysninger opdateringshastighed.
>> Effektivt, hvad der sker i statistik plug-in
er, at hvert n-sekund, hvor n-sekunder er defineret af denne præference
panel, er oplysningerne bliver hentet fra den underliggende eksempel sendes
tilbage til klientsiden, plug-in er så
fortolkning af oplysninger fra den underliggende instans
og opdatering af GUI som nødvendigt.
Vi kan se, at lige nu dette er indstillet til 30 sekunder, og det er standard.
Men jeg kan helt sikkert ændre hvor hurtigt det sker bare
ved at ændre denne værdi.
>> Nu er en af ​​de interessante ting er, at denne præference panel, GUI,
er egentlig bare en GUI-version af et parti underliggende indstillinger
der er præsenteret i JSON.
Så hvis jeg går, for eksempel under den CS50 IDE-menuen, eller Cloud 9 menuen
afhængigt af hvilken version, du kigger på,
og gå til en af ​​disse settings-- i denne sag,
projektet settings-- den projektets indstillinger i denne sag
gælder for alle indstillinger for denne ene arbejdsområde.
Ud fra følgende betragtninger brugerindstillinger gælder til alle de arbejdsområder
at du kan have i din konto.
>> Så lige som en sidebemærkning her, at være ekstra klar,
der er en adskillelse mellem to, fordi selvom som standard, vi
har en arbejdsplads, som er CS50 IDE, hvis du
var til at klikke på din lille avatar op her og gå til instrumentbrættet,
du opdage, at du rent faktisk kan skabe yderligere arbejdsområder så godt.
Du kan se her, at jeg har en IDE 50 arbejdsområde, og også
med henblik på dette seminar, et arbejdsområde
kaldet arbejdsområde, som er lige her.
Så alligevel, jeg har forskellige præferencer.
Hver af disse kan have særskilt projekt præferencer,
men brugerindstillinger er deles blandt alle mine arbejdsområder.
Af den måde, det er også meget praktisk, hvis du
ønsker at skabe et arbejdsområde med forskellige muligheder for tilpasning.
Og det er meget praktisk at oprette en ny arbejdsplads.
Og vælge en, der kunne være forudkonfigureret på anden måde,
måske for PHP specifikt eller Django specifikt.
Eller bare skik.
Den CS50 arbejdsområde Skabelonen er den, vi
bruge det automatisk installerer Opdatering 50 og alle indstillingerne
at vi har der, herunder alle plug-ins, som vi har for CS50 IDE.
OKAY.
Men lad os vende tilbage til dette.
Så igen, der er projekter indstillinger, og det er dem
at vi ser på her.
Og bemærk, at der er en flok indstillinger,
mange af dem svarer til præference paneler, men ikke dem alle.
Men vi kan se, at her, i denne-- åh nej, jeg sætter det i brugerindstillingerne?
Måske jeg sætte det i brugerindstillingerne.
Og det, her går vi.
I brugerindstillingerne, vi kan se, at vi har en CS50 sektion,
og dette skrives til disse Cloud 9 plug-ins
at vi har implementeret.
Der er den enkle at svarer til denne enkle plug-in,
og statistik en som svarer til GUI baseret
version af præference panelet.
Opdateringshastigheden, i dette tilfælde er sat til 20 sekunder.
>> Det er alt forhåbentlig den begyndelse af nogle oplysninger
at vi faktisk vil se i en lille lidt flere detaljer, momentant.
OKAY.
Så lad os sige, vi ønsker at faktisk komme ned til det.
Vi forstår, at alle de ting der sker på klientsiden
sker faktisk på browseren, som betyder, at eventuelle plug-ins, som jeg skriver
kommer til at blive skrevet med browseren i tankerne.
Og hvis jeg rent faktisk ønsker at gøre noget på arbejdsområdet,
Jeg vil måske nødt til at indlede en slags kommunikation
mellem browseren og arbejdsområdet for at være sikker
at der faktisk opnås.
Men lad os sige, at nu Jeg ønsker at komme ned til det
og faktisk oprette min første plug-in.
Nå, den måde, du ville være i stand at gøre det er faktisk temmelig nemt.
Det har givet i Cloud 9 SDK.
Men det er at tage din eksisterende arbejdsområde navn, som
er den webadresse, som du har i toppen af din bar, og tilføje følgende til det.
?
SDK = 1 & Debub = 2.
Nu, hvad det kommer til at gøre det muligt er at SDK = vil 1 faktisk indstillet SDK
tilstand til sand, hvilket vil gøre det muligt et par ekstra ting.
Og debug = 2 vil give fejlmeddelelser at være en lille smule mere detaljeret.
>> Og så hvis du opdrage JavaScript konsol i din Chrome fanen udvikler,
du rent faktisk vil være i stand til se meget mere information
end du ellers ville.
Så jeg anbefaler at dreje begge disse på samme tid, fordi det virkelig
er nyttigt at have alt dette yderligere information.
Det er vigtigt at bemærke, at tænde debug til værdien af ​​2
betyder, at det er meget verbose, og det faktisk
vil noget mærkbart langsommere din IDE, især når lastning
eller når gør laver tunge opgaver.
Så bare holde det i tankerne.
Det er nyttigt for udvikling, men du måske ikke ønsker at have den på hele tiden.
>> Så lad os rent faktisk gør det.
Men i dette tilfælde, jeg har faktisk allerede oprettet et arbejdsområde med dette.
Så lad os se, SDK = 1 & debug = 2.
Med et par plugins forhåbentlig allerede installeret.
Okay.
Så nu, at jeg har slået SDK debug tilstand, bemærke, at vi er i debug-mode,
så vi kan se på de dev værktøjer til at se eventuelle fejl, som jeg vil gøre Offscreen.
Vi kan se, at der er en flok af fejl her.
Nu er det faktisk temmelig almindeligt for Cloud 9 at have et par fejl,
og jeg ville ikke bekymre dig om dem, indtil du
se noget, der kan være specifikke for plug-in
at du tilfældigvis være at skabe.
>> Så her, for eksempel, får vi et par 404s-- ikke fundet.
Vi ser, vi er i stand til at indlæse nogle informationer fra den underliggende instans
selv.
Og der er en masse ekstra oplysninger, men det meste af dette er vi
faktisk går til at ignorere for nu.
Da dette er temmelig fælles for et arbejdsområde
at have bare et par fejl.
OKAY.
Jeg har tænkt mig at flytte det ud af vejen og komme tilbage her.
Og nu er den nemme måde, den pæne ting om at have denne udvikler
tilstand aktiveret, er, at det giver mig mulighed til nemt at oprette en ny plug-in.
>> Så mens før jeg rent faktisk gjorde ikke har denne nye plug-in-mulighed til rådighed,
som vi kan se, om jeg går tilbage til min ikke udviklertilstand herovre,
der er ingen nye plug-in.
Ved at aktivere SDK-tilstand, jeg har en ny plug-in til rådighed
og jeg kan nemt oprette en.
I dette tilfælde, er der et par af forskellige muligheder, enkle,
en tom plug-in, en fuld plug-in, installatør, Cloud 9 bundt.
Lad os bare vælge en tomme plug-in til nu
så vi kan se en meget simpel version af en.
>> Nu mærke til, at langs venstre side, der er der nu
noget under Foretrukne, som er notering et par plug-ins
der er nu tilgængelige for mig.
Hvis jeg udvide denne, vil vi kunne se dem.
Nu jeg vil have dig til at lægge mærke til noget her, som
er, at dette ikke er faktisk indeholdt inden arbejdsområdet biblioteket
på min underliggende Ubuntu eksempel, men den er indeholdt på harddisken.
Og hvor det er placeret, fordi dette er meget nyttigt at vide,
især hvis du kommer til at gøre noget med Git,
hvor det er placeret er i en .c9 mappe / plugins.
Så hvis jeg går der, kan vi se, at nu listen over plug-ins, der er her
matcher listen plug-ins, som jeg så på den venstre side af mit arbejdsområde.
>> Nu som standard, og dette er lidt mærkeligt,
som standard, når jeg opretter en nye plug-in i et arbejdsområde,
det skaber denne plug-in, ved standard har et navn på en understregning.
Generelt, der kan forårsage nogle problemer.
Så meget næste trin at jeg normalt udfører
er bare at fjerne den særlige plug-in
og lade kun den simple plug-in, var der i starten, plugin.simple.
Og det er den eneste, der er der.
OKAY.
>> Så hvad betyder det egentlig ud?
Nå, det er, igen, en JavaScript-pakke
der omfatter nogle filer, herunder en plugin.js fil, hvor
hovedindholdet af min plug-in er placeret,
en package.json fil, som faktisk angiver
nogle metadata om denne plug-in, såsom hvem forfatteren er,
yderligere oplysninger om det, et beskrivelse af plug-in, og så videre.
Og også som standard, det skaber en tom README-fil,
og en tom testfil for dig at skabe nogle yderligere dokumentation,
og en test sele, hvis du gerne vil gøre det.
>> Så lad os bare tage et kig først på, meget hurtigt, på package.json fil.
Det er let nok at bare gå igennem det og udfylde de områder af dette
at du ønsker at udfylde, ligesom give det et navn, giver en beskrivelse,
gentage versionsnummeret alle så ofte, giver
en forfatter for hver person, der bidrager,
tilføje dem til bidragyderne sektionen, og resten af ​​det du
kan temmelig meget bare forlade som det er for nu.
>> Der er én ting, der er vigtigt at bemærke,
at under plug-ins sektion, der er en nøgle kaldet plug-in.
Og det er tilpasset til navnet JavaScript fil kaldet plugin.js.
Så dette er, hvordan Cloud 9 ved, når det læser denne package.json fil, som
af js filer til rent faktisk at indlæse.
Hvis jeg oprette yderligere js filer eller ønsker at omdøbe at js fil fra plug-in,
Jeg har også nødt til at ændre det i package.json filen.
>> Eventuelle spørgsmål fra publikum?
Ingen.
At en person, der er efter sammen med mig indtil videre.
>> OKAY.
Så jeg faktisk har skabt en par plug-ins, der allerede,
Jeg tror, ​​i dette arbejdsområde.
Så lad os komme af med nogle af disse, tilføj sdk = 1 & debug = 2, genindlæse denne arbejdsområde,
og lad os se om vi har disse plug-ins nu.
C9 / plugins.
Nu sker det.
Vi kan se nu i mine C9 / plugins i denne en, har vi plugin.1 og plugin.2.
Så vi kommer til at bare optrappe til-- blot øge mængden af ​​vanskeligheder
i hver af disse plug-ins.
Men her, hvis jeg opretter en ny plug-in, Jeg kan tilføje det til mine favoritter.
Og jeg vil bare slette dem fra det underliggende filsystem.
>> Lad os fjerne det.
Nu, hvis jeg åbner min første plug-in, og åbne plugin.js,
vi kan se her den underliggende simpel version af en plug-in.
Lad mig faktisk gå tilbage til denne anden arbejdsrum
fordi du kan i det mindste, her ser, hvad en tom plug-in faktisk ser ud.
Så under kølerhjelmen, det ser meget lig teknologi kaldet,
Jeg synes, det er RequireJS.
Bemærk at dette ikke er tilfældet virkelig se, måske,
det samme som en anden JavaScript filer, som vi måske har set.
Men i stedet, er der et par bare grundlæggende linjer, at det faktisk har.
>> Alt det her er første fortolket af IDE,
men det er faktisk ikke løbe frem specificeret.
Og jeg vil fortælle dig om, når der faktisk betyder på blot et øjeblik.
Men se, at her er der en main.consumes linje på linje 2,
og dette viser alle de plug-ins at denne plug-in er afhængig af.
Så som standard, vi måske ikke at have eventuelle afhængighed af andre plug-ins,
men når vi faktisk har brug for at afhængige af funktioner, der leveres
af andre plug-ins i IDE, vi nødt til at nævne disse plug-ins
i main.consumes linje.
Og så er vi nødt til at knytte dem til koden
nedenfor, som jeg vil vise dig på bare et øjeblik om, hvordan vi kan gøre det.
>> Main.provides giver en navn til denne plug-in
at andre plug-ins kunne brug i deres forbruger linje.
Så i dette tilfælde, min plug-in er netop sat der som standard,
og vi bør ændre det til at være gældende for vores egen plug-in,
som vi vil se på bare øjeblik.
Nu her i funktionen vigtigste, denne funktion vigtigste
er faktisk køre og fortolkes, men det gør faktisk ikke gøre meget.
Det bare bliver alt sat op, men det gør faktisk ikke starte plug-in,
trods hvad navnet lyder.
Det sker der egentlig gennem en sekvens af metoder,
er indeholdt i hele dette plug-in.
>> Så hvis jeg rulle ned, kan vi se at vi har en livscyklus, hvor
på nogle begivenhed kaldet belastning, eller nogle begivenhed kaldet unload,
nogle arrangementer rent faktisk sker.
Det er virkelig i her, hvor som plug-in begynder at disse metoder kaldes.
Så lad os være lidt mere konkret om dette og se på et eksempel.
Så her for plugin.1, hvad vi grundlæggende vil gøre
er at skabe et menupunkt kaldet CS50 Seminar Dialog 1--
fordi vi har to af them-- og vi vil
at injicere det i menuen Vindue.
Og når vi klikker på det, vi er kommer til at åbne op for en dialog,
viser os nogle meget grundlæggende oplysninger.
>> I dette tilfælde blot en Hej verden.
Så det er en meget simpel hej dialog verden
at vi kan implementere som en plug-in i Cloud 9.
Så lad os se, hvordan det rent faktisk ser ud.
Vi vil gå gennem det, bare relativt hurtigt, så vi
kan se på næste plug-in så godt.
Bemærk, at her er vi forbrugende en række plug-ins.
Vi indtager en dialog plug-in, kommandoer, menuer, og UI.
Ligner jeg faktisk er tidskrævende dialog to gange, så jeg kan fjerne det.
>> Og bemærk, at den måde, at jeg forbinder dem,
dette er slags metadata, der fortæller plug-in system, hvilke krav
faktisk er nødvendige for denne plug-in for at indlæse.
Det er også vigtigt at bemærke, den rækkefølge, plug-ins er indlæst
er ikke garanteret.
Men hvad er garanteret, at hvis jeg angive nogle plug-in som et krav,
at plug-in vil blive indlæst før denne er indlæst.
>> Så det betyder, at hvis din plug-in kræver på nogle funktioner forudsat
af noget andet i IDE, bør du være sikker på at dine plug-in-forbruger
at plug-in, så afhængigheder er sikker på at oprette din plug-in,
eller instantiere din plug-in, kun efter at der foreligger eksisterende rammer.
Så her jeg har nævnt metadata til plug-in manager,
som dem, jeg har tænkt mig at forbruge.
Og i den vigtigste funktion her, Jeg har tænkt mig at tilslut derefter
min kode til de importerede plug-ins.
>> Så jeg vil blot skabe nogle variabler,
matche navnene på hver af dem, så at jeg meget hurtigt kan referere dem
hele min kode.
Grunden til jeg importerer dialog er fordi jeg vil have min plug-in
til at fungere som en dialog plug-in.
Og den måde, at jeg er i stand til at gøre det er at, selvfølgelig,
forbinde min kode til dialogen plug-in ved at importere det
og derefter ved at specificere ved at skabe en ny dialog variabel
og tilslutte den til at importerede plug-in.
Og så ved at definere min plug-in som en ny dialog.
>> Så i initialiseringen, jeg ønsker at definere min plug-in.
Og denne variabel kaldet plug-in du vil se
bliver bare brugt almindeligt hele Cloud 9 plug-ins.
Jeg har tænkt mig at instantiere en ny dialog med nogle attributter,
give den et bestemt navn, siger, at det er muligt for brugerne at lukke den.
At det vil vise lidt x i øverste højre hjørne,
eller lidt knap i nederste højre hjørne.
Hvorvidt jeg kan vælge tekst fra det, hvad titlen på denne dialog
ville være, og så videre.
Nu er dette bare definerer dialogen, men det er endnu ikke viser det.
Jeg faktisk nødt til at definere en handling for at blive vist.
>> Og igen, jeg opfordre dig til at tage et kig på Cloud 9 SDK,
fordi der er en række dialoger og de er virkelig veldokumenteret.
Du kan se de forskellige typer at der er, og bruge dem
uanset plug-in du har i tankerne.
Nu er der kommer til at være en lastdel, og denne belastning
funktion som du husker, er bruges af plug-in livscyklus
faktisk instantiere alt og få alt klar til at gå.
Nu når denne plug-in belastninger, det gør jeg ikke ønsker, at det straks vise en dialog,
fordi dette plug-in vil indlæse sammen med resten af ​​IDE.
Og når jeg indlæser, at IDE, jeg ønsker ikke dialogen til at dukke op automatisk.
Jeg ønsker kun det at vise, når jeg klikker på menupunktet i mit vindue menupunkt
at jeg vil tilføje til det øjeblik.
>> Så der er to adskilte trin her, der er nødt til at ske.
Jeg er nødt til at skabe en kommando, og kommandoen
vil være ansvarlig for faktisk viser dialog om Cloud 9 IDE.
Og så er jeg nødt til at tilslutte, jeg nødt til at oprette et nyt vindue i menuen
element, der kører denne kommando.
Så når jeg klikker på det vindue menupunkt, at kommandoen er derefter køre
og derfor min dialog derefter vist.
Og så det er faktisk en temmelig pæn måde at tænke over det.
>> Fordi først kan jeg oprette en kommando hvis navn er CS50 Seminar Dialog 1,
der giver nogle generelle kontekst for det.
Og det vigtige bit her er at mærke til EXEC attribut, som
opregner en funktion, som vil blive kaldt i min plug-in, når denne kommando køres.
Så denne kommando er lidt ligesom en-- det er bare en vilkårlig Cloud 9
kommando, der er til rådighed til enhver Cloud 9 plug-in.
Men den aktuelle funktion, at det er vil kalde, når denne kommando køres
er funktionen show dialog i min plugin.js fil.
>> Og vi kan faktisk se disse plug-ins og listen
kommandoer, der er tilgængelige for os i Indstillinger, rul hele vejen down--
lad os se, faktisk ser vi det nu?
Plug-in manager, nej, jeg tror jeg-- det er absolut her omkring et eller andet sted.
Tja, der er en liste over kommandoer et eller andet sted, men jeg må have,
Jeg har glemt, hvor det er.
Så OK, vil vi gå videre.
Okay.
Så vi har en liste over kommandoer der er til rådighed for os,
og disse kommandoer er disse blot vilkårlige Cloud 9
kommandoer, der kører specifikke kode.
Så bare holde det i tankerne, at vi kommer til at køre showet dialogen
fungere øjeblik.
Nu når jeg rent faktisk ønsker at tilføje en menu post, kan jeg tilføje, at elementet af stien,
og bare angive præcis, hvor jeg vil det at være, Vindue / CS50 Seminar Dialog 1.
Og på det tidspunkt, jeg ønsker at oprette en ny post, der
kommer til at køre en kommando, CS50 Seminar Dialog 1.
Bemærk, at igen, det er Cloud 9 kommando Jeg har oprettet lige over.
>> Nu ønsker jeg også at oprette en lille skillevæg,
og så jeg kan gøre det samme i den efterfølgende linje.
Nu kan du måske mærke til, at så del af at definere dette menupunkt,
der er en række forbundet med det, som
faktisk siger hvor præcis Jeg vil have, at menupunkt til at være
placeret på listen over menuer.
Men du måske bemærke at jeg faktisk ikke
se nogen tal med disse menuer, som standard.
Så der er en lille skjult ting, vi kan gøre, en lille ændring til vores webadresse.
Så ud over SDK = 1 & debug = 2, Jeg vil sætte menuen til at 1--
og forhåbentlig er det menuen, ikke menuer.
Åh, det er menuer = 1.
Hold fast.
>> Og hvad vi vil se, når omladning, at IDE er, at jeg stadig er i debug-mode,
men nu er der tal forbundet med alle menuerne.
Og dette fortæller dig præcis, hvad antallet
er, når du forsøger at injicere noget som helst i denne menu system.
Så i menuen Vindue, kan jeg se, at punkt 45 er Samarbejd,
og punkt 38, før det er installatør.
Så når jeg ønsker at injicere et emne mellem de to,
Jeg ville bare vælge et nummer mellem disse to elementer.
Så jeg valgte 41 og indsat min Seminar Dialog 1 menupunkt på det sted.
>> Og det er derfor, dette antal der vises her er nummer 41.
Det er placeringen af ​​denne menupunkt i Cloud 9 menuen.
Nu tilsvarende, ville jeg at skabe en skillevæg
og tilføje det, så der er en dejlig opdeling mellem hver af disse menuen
varer.
Så tilføjede jeg, at på placering 43.
Så langt, så godt, jeg håber?
Så lad os nu faktisk se på den specifikke kode i show dialogen
det er faktisk ansvarlige til åbning denne dialog vindue.
>> Rulle ned, ser jeg, at jeg vil at have denne funktion show dialog,
og det er yderst simpel.
Jeg har tænkt mig at køre showet metode på plug-in variabel.
Og husk, at vi definerede dette plug-in variabel ovenstående som dialog.
Så bar plug-in, i dette tilfælde, er det objekt, som vi har defineret internt.
Og det kommer til at blive en ny dialog indeholdt i denne plug-in.
Og så vi faktisk refereres dette plug-in variabel i mange steder
i en typisk Cloud 9 udviklingsmiljø.
>> Vi vil se det her.
Bemærk at da vi rulle ned, Der er yderligere livscyklus.
Så bemærke, at disse reagerer til begivenheder, der er fyret
af dette formål, denne dialog objekt.
Som standard, er der laste og losse, som
er tilgængelige for alle Cloud 9 plug-ins.
Men i tilfælde af denne dialog, er der
anden begivenhed, der kan brand samt kaldt
Draw, som er fyret, når der er ved at blive trukket på skærmen,
i første instans af dialogen viser.
>> Så når det er faktisk vil blive vist,
der vil give os nogle HTML.
Og ved hjælp af bare standard HTML praksis kan vi
injicere nogle meget enkle oplysninger, vores hello verden, i den dialog.
Så hvis vi derefter rulle op, vi kan se derefter procession af ting
at det der sker.
Først skabte vi en Cloud 9 kommando at når henrettet af Cloud 9,
kommer til at affyre denne funktion.
Det kommer til at køre denne funktion kaldet viser dialog, at jeg har
skrevet i min kode.
>> Jeg har oprettet et menupunkt og knyttet til det samme kommando
at når denne post er klikket på menuen, der kommando derefter køre
og at funktionen er derefter køre.
Og inde i funktionen jeg bare vil kalde til-- jeg er
bare at udføre showet fremgangsmåde af denne plug-in, som
vil første opkald lodtrækningen metoden, og gå
at affyre denne metode ned under den tegne event handler, i vores livscyklus.
Og så vil det faktisk viser dialogen.
>> Der er også en skjul metode, således at hvis jeg har brug mulighed for at skjule
min dialog, kan jeg gøre det samme.
Så det er temmelig meget det at få alt dette til at arbejde.
Bemærk, det er hvis vi rulle ned yderligere er der en fastfrysning offentlige API.
Dette dybest set bare siger, at jeg ønsker, at disse metoder til effektivt
offentlige, men ikke kan overskrives uden for rammerne af denne plug-in.
Og derunder, i bunden, er måske den sidste,
at vi virkelig nødt til at betale meget opmærksom på her, hvilket
er, at vi kommer til at registrere vores plug-in med navnet C9 Seminar 1,
og objektet plug-in.
>> Hvilket som du vil huske, er at plug-in, plug-in
objekt, vi har været at definere hele hele denne kilde
kode.
Og C9 Seminar 1 er den streng, vi lovede
at tilvejebringe øverst af denne definition.
OKAY.
Så lad os rampe det op en lille smule og se, om vi kan gøre noget
lidt mere interessant.
Nu er dette er kun så stor.
Jeg mener, det er, det er faktisk temmelig cool, at i så få linjer kode,
kan vi ændre den eksisterende IDE og tilføje en eksisterende menupunkt
eller tilføje et nyt menupunkt, tilføje en kommando, og vise en dialog,
og bare en masse funktion, der findes.
Det er virkelig temmelig stor.
>> Men det betyder ikke gøre meget, fordi det ikke kan kommunikere med den underliggende Ubuntu
instans.
Så lad os sige, at jeg faktisk ønsker at finde ud af
nogle oplysninger om underliggende Ubuntu eksempel,
ligesom statistik plug-in gør.
Så lad os tage et kig på en lidt mere information
om, hvordan statistik plug-in værker.
Og faktisk er det meget lig dette.
Du måske huske, at der er en dialog.
Du husker muligvis, at der er nogle oplysninger, der er
vist lige langs menulinjen sammen toppen, som forhåbentlig er du nu
få en smag af hvordan vi implementeret det,
bare ved at indsætte menupunkter på specifikke point og ved at instantiere en dialog
og vise, at dialog.
>> Men vi har endnu ikke vist dig, hvordan vi kan forbinde det
til en kommando i underliggende Ubuntu instans.
Så lad os tage et kig derefter på plugin.2, der gør netop denne ting.
Vi kommer til at åbne plugin.js, som er koden for dette.
Men under menuen Vindue, hvis jeg klikker på dialog 2,
Vi kan se, at der står det stedet, hej CS50, som
ser ikke alt det lokkende, ikke?
Bortset, se denne.
Lad mig ændre noget hernede.
>> Jeg har tænkt mig at gå til min arbejdsområde og forandring seminar
til at sige noget andet, ligesom Hej, Dan.
Jeg har tænkt mig at lukke den og gemme den.
Og nu jeg har tænkt mig at re-run min menu dialog element.
Og bemærk, at det har nu ændret, hvad der står.
Hej, Dan.
Jeg synes at have gjort noget ned her i den underliggende Ubuntu instans
uden at have manipuleret nogen kode, der igen kører alene
på klientsiden.
Så der er selvfølgelig en slags kommunikation, der sker her.
>> Nu er det her en stor del af magt Cloud 9 SDK kommer ind,
er, at i denne plugin.2, Vi kan faktisk forårsage
en opfordring til at ske med underliggende eksempel
og køre nogle arbitrær kommando.
Så i dette tilfælde, har jeg faktisk skabt en meget simpel bash script
i min arbejdsplads hedder Seminar.
Så lad mig åbne det op.
Og vi kan se, at det ser sådan ud.
Det er bare en meget simpel bash script, hvis eneste formål i livet
vil være at echo denne tekst, Hej, Dan.
Eller før det, det sagde Hej, CS50.
Og det er alt det kommer til at gøre.
>> Da dette er nu en kommando, jeg kan køre.
Jeg kan faktisk køre det ned her.
Vi kan se, at det faktisk er lige en kommando, som jeg kører naturligt.
Jeg kan spørge min plug-in til at udføre dette kommandoen på den underliggende arbejdsområde
og parse oplysningerne der blev returneret fra det,
og gøre noget med det, og ændre min plug-in og den adfærd, som jeg
har i mit plug-in som et resultat. OKAY.
Så lad os se, hvordan det sker.
Vi så det meget simpelt Seminar batch script, jeg
[Uhørligt], at det rent faktisk kan køre.
>> Og lad os nu se ændringerne der er nødvendige for at binde det sammen
med dialogvinduet, og køre den.
Så her vil vi gøre stort meget det samme som vi så før.
Men se, at blandt de ting, som jeg har forbruges nu--
Ud over den dialog, som igen jeg tilfældigvis har gjort to gange,
der ikke necessary-- derudover til dialogen og kommandoerne
og menuerne plug-ins, der var nødvendigt i første for mig
at definere en ny kommando og injicere et element i menuerne,
Jeg har også denne proc plug-in.
>> Og denne proc plug-in gør det muligt os at manipulere processer
på den underliggende instans.
Jeg har tilsluttet det efter jeg har sagde, at min plug-in kræver det.
Jeg har så tilsluttet den til koden, som vi så i den vigtigste funktion.
Igen, vil jeg initialisere min dialog.
Og hvis vi flytte ned nu, vi kan se, hvordan det er anderledes.
Belastningen funktionen er den samme, så det bare at gå til at oprette en kommando
og skabe et menupunkt, og tilslut at menupunkt til denne kommando.
Men hvis vi nu rulle ned for at vise dialogen,
kan vi begynde at se, hvor de forskelle opstår.
>> Vi har funktion show dialog, som er bare at vise dialogen.
Men når jeg viser denne dialog, og når showet metode kaldes,
det brande lodtrækningen funktionen.
Og jeg har tænkt mig at derefter angive noget indhold inde i det.
Så jeg vil blot oprette en div, give det
nogle grundlæggende tekst, Hej, verden.
Men se, at her er jeg kommer til at knytte til det et id.
Og meget næste linje jeg vil at opdage, at id ved hjælp af JavaScript,
og gemme det pågældende objekt i en anden variabel
at jeg bare tænkt mig at ringe til indhold.
>> Så nu når jeg har indhold, alt hvad jeg skal gøre
blot ændre denne objektets indre HTML.
Og dialogen HTML vil derefter modificeres så godt.
Så når denne plug-in er derefter vises, hvilket kan ske
og dette er en ny begivenhed der er nyt for denne plug-in,
men der sker i hvert plug-in med dialogen, når dette vises nu,
Jeg har tænkt mig at kalde en funktion kaldet hente info.
Og denne funktion er kød af den her.
Jeg har tænkt mig at bruge denne proc plug-in, vi beskrevet ovenfor, som ved måde,
er egentlig bare en node.js bibliotek at Cloud 9 bruger her.
>> Så du kan faktisk ser op om, hvordan det
virker, hvis du går ind i Node.js dokumentation
og se op exec fil Fremgangsmåde til processer der.
Jeg har tænkt mig at køre denne specifikke kommando, hjem Ubuntu arbejdsområde
seminar, som er den samme én, der samme kommando, som jeg oprettede før.
Give det en aktuel arbejder mappe, bare
at være ultra sikkert i forhold til forbindelse med hvor det kører.
Og når der har været udfyldes og returneres,
Jeg har tænkt mig at køre dette funktion kaldet parse output.
OKAY.
Så, det kommer til at udføre en kommando på den lokale, eller rettere
fjernbetjeningen Ubuntu instans.
Når jeg får tilbage nogle oplysninger, jeg er så
vil kalde en separat funktion kaldes parse output, der
har denne signatur her, err, stdout, stderr,
og udføre nogle beregninger på dette.
Så hvis jeg fik en fejl af en slags overhovedet,
Jeg vil faktisk kontrollere, om fejl faktisk har nogle data.
Og hvis ja, så vil jeg ændre den indre HTML af dette indhold objekt, som
er du husker, vi forbundet til dialogen
ved instantiattion af denne dialog, eller på det første tegning
af denne dialog.
Jeg har tænkt mig at bare sige, at er sket en fejl.
>> Nu er dette er alt for forenklet.
Fejlværdien vil typisk indeholder noget, der var nyttigt,
måske en fejl nummer og en fejl fra selve scriptet.
Eller hvis scriptet skrev noget at standardfejlen,
at data ville blive befolket i denne parameter samt.
Og jeg kunne være en lille smule mere forsigtig med, hvad fejl
Jeg er faktisk vise folk.
Men dette simplistiske eksempel er godt nok for nu
til mindst se, hvordan alle disse funktioner.
Ellers, hvis der er ingen fejl, så er jeg bare
vil give den rå produktion af denne funktion
ind i den indre HTML af dette indhold element, og derefter opdatere min plug-in
og vise det her.
Og det er temmelig meget alle, der er nødvendigt at få dette til at køre.
Og så lad os tænke på da hvordan dette fungerer, samlet.
Da jeg først indlæst denne plug-in, ligesom den første plug-in,
Jeg har tænkt mig at tilføje en kommando, der er rådighed til noget, ethvert plug-in
i Cloud 9, kaldet CS50 Seminar Dialog 2, hvis ansvar
vil være at køre dette show dialog, som er du husker,
faktisk vil vise dialogen at jeg anmodede nedenfor.
>> Så vil jeg tilføje, at kommando i et vindue menu
så jeg har adgang til det.
Og når denne dialog anmodes om at blive vist,
Jeg vil hente nogle info fra den underliggende Ubuntu instans
ved at bruge exec fil kommando.
Undskyld mig.
Når der returneres, og jeg modtager nogle oplysninger, så på klientsiden
igen, vil jeg være i stand til at parse produktionen af ​​denne kommando
og opdatere den indre HTML af elementerne
at vi havde tilsluttet tidligere.
>> Og med det, vi så har denne fuldt funktionelle plug-in
der tillader mig at hente oplysninger fra denne vilkårlige script
at vi har skabt på vores underliggende instans.
Men igen, det er virkelig vigtigt og virkelig nøglen
at adskille hvor hver af disse ting, der sker,
at vi har alt dette klientsiden kode, der køres i browseren,
og endnu ikke har adgang til det underliggende filsystem
indtil vi faktisk køre nogle af disse kommandoer, der leveres af Cloud
9 SDK ligesom proc, og nogle andre dem der giver os mulighed for at læse nogle data,
eller læse nogle filer, hvis vi har brug for at gøre noget sådant.
>> Nu er en noget simpelt eksempel.
Der er andre ting, som vi ville måske ønsker at gøre så godt.
For eksempel, måske vi faktisk ønsker at spare nogle oplysninger
til de præferencer.
Eller måske vil vi tilføje en ny præference rude
eller noget i den retning.
Så det er noget, du kan tage et kig på Cloud 9 SDK
at få mere information om.
Men dette er virkelig nok til at komme i gang.
Så bare for at være en lille smule mere konkret om den måde, at nogle af disse ting
funktion, jeg havde lyst til at vise bare endnu et eksempel, som er blot nogle
af koden fra Stats 50 plug-in.
>> Og denne kode er dybest set baseret på disse eksempler
at du faktisk har set, men har nogle flere sikkerhedsforanstaltninger
og har nogle mere komplekse med henblik på at opnå nogle af de ekstra ting
at vi ønsker at opnå.
For eksempel, hvis jeg ønsker at være stand til at gemme nogle indstillinger,
så er jeg nødt til at have adgang til Indstillinger plug-in,
og hver gang jeg vil have at læse nogle indstillinger,
Jeg kan for eksempel tillægger forskellige begivenheder i Indstillinger plug-in.
Så hver gang indstillingerne er rød, for eksempel i min egen plug-in,
hvis jeg vil læse nogle indstillinger fra den gemte opbevaring
præferencer for brugeren, så kan jeg sætte standardindstillinger for et bestemt sted,
for specifik præference, idet JSON stil muligheder fil, som vi har
gemt tidligere, at vi har set tidligere.
>> Og hvis jeg har tænkt mig at skrive nogle indstillinger til det,
så jeg can-- eller så snart vi opdager at indstillingerne er blevet skrevet
at-- fordi for eksempel dem, indstillinger er ændret af brugeren
enten direkte i deres indstillinger fil eller præference ruden
har ændret indstillingerne fil direkte, så
Jeg kan faktisk opdatere nogle af koden eller opdatere opførsel min plug-in
baseret på de ændringer, der opstod på indstillingsfilen så godt.
Men virkelig, resten af ​​det er temmelig meget denne, som du allerede har set.
>> Vi tilføjer nogle, måske noget, der er nyt.
Så tilføjer vi en præference-fil, eller snarere en præference rude,
til vinduet Indstillinger, som igen kan du finde ud af mere information
i Cloud 9 SDK læste mig.
Men alt andet er temmelig meget, temmelig
svarer til, hvad vi så før, bare med nogle ekstra fejl kontrol
og nogle yderligere beskyttelse og nogle yderligere funktionalitet
til funktionen alle de forskellige ting, som vi har set.
Hvis du har faktisk ikke set det endnu, kan du
være gad vide hvad den underliggende kommando er i Statistikker 50 vinduet.
Det er faktisk funktion.
Tja, det is-- åh, for fanden.
Et sekund.
Hold fast.
OKAY.
Lad mig flytte denne op, så vi rent faktisk kan se hvad der sker, når jeg skriver Stats 50.
Bemærk, at i dette tilfælde kommando, jeg er ude at sætte
er virkelig igen, bare det script, der er gå til at afgive et bundt af oplysninger
i JSON format.
Og grunden til, at vi gør det denne måde er, at fordi vi
opererer, fordi vi har skrevet klientsiden kode i JavaScript,
vi kan meget nemt bare parse JavaScript objekter,
og virkelig kunne manipulere disse objekter ligesom vi ville
enhver anden JavaScript objekt.
>> Og så dette er en meget bekvem måde at give nogle oplysninger
fra den underliggende Ubuntu eksempel, såsom versionsnummer, værten
navn, om en server lytter, hvad serveren er, så videre og så videre,
og parse netop let og meget hurtigt
i plug-in, som derefter går at vise os alle af disse oplysninger.
Så igen, nøglen indsigt her at huske på
Denne adskillelse mellem den underliggende instans,
og også hvor koden bliver indlæst.
At når jeg har en klient, Det er første læsning.
Bare denne statiske JavaScript-fil fra et eller andet sted, måske CDN af en slags.
Vi har egentlig ikke at pleje for meget om dette første skridt.
>> Vi ved bare, at det er kører på klientsiden
og det er når jeg har tænkt mig at kommunikere med denne havnearbejder instans.
At vi kommer til at gøre det gennem Cloud 9 SDK.
Vi behøver faktisk ikke mulighed for, ved hjælp af JavaScript eller node.js,
at skrive direkte til det.
Vi bruger kun de eksisterende SDK API'er til at gøre denne handling for os.
Og igen, en af ​​de virkelig vigtige ting
er, at når jeg har oprettet denne, når jeg har oprettet denne plug-in,
og da jeg arbejder på det, man af de vigtige ting at gøre
er at bringe op JavaScript-konsol.
>> Fordi da dette er alt opererer på JavaScript,
på klientsiden, hvis jeg bruger en console.log method-- så bare
at vise et eksempel her.
Lad os prøve at ændre denne enkle plug-in til også logge nogle data.
Og vi vil tilføje standard ud.
Så lad os ændre det til at være lige her.
Nu når jeg udfører console.log, huske på
at eftersom dette kører på klientsiden,
Jeg vil se dette i min egen JavaScript-konsol, som
er, hvordan jeg vil så være i stand til forsøge at fejlfinde og debug
nogle af de problemer, som jeg har.
>> Bemærk, at fordi Jeg er i SDK-tilstand, er jeg
derefter stand til at manipulere plug-ins på dette tilfælde.
Så selvom det er gemt på det foreliggende tilfælde,
dette er et eksempel på det tidligere regel overtrædes, hvor Cloud 9
SDK faktisk vil trække plug-ins fra underliggende instans og derefter køre dem.
Således at på denne måde, er jeg så stand til at manipulere og konstruere
nogle plug-ins her.
Men for mig at se opdateringer til dette plug-in,
fordi det er på klientsiden, Jeg har brug for at redde denne plug-in
og læg hele arbejdsområdet, så det nye plug-in er så
downloadet på min klient, på min webbrowser, og derefter bliver brugt.
>> Så nu når jeg klikker på dette seminar Dialog 2, ser vi fortsat dette.
Men nu forhåbentlig i min JavaScript dialog, såfremt vi finder my-- vente,
hold fast.
Jeg måske nødt til at åbne dialogen frisk.
Vi bør se mine modtagne data her.
Modtagne data, Hej, Dan, som er du husker,
var en console.log operation, vi anmodet om i plug-in.
Så denne beskrivelse derefter som jeg nævnte før,
denne dialog, eller det diagram snarere, at jeg
nævnt før er hvad der sker.
Men der er en vigtig undtagelse kun for udvikling,
som er, at plug-in selv kan faktisk
gemmes på havnearbejder instans midlertidigt, da antagelig Cloud 9
ikke ønsker os at være i stand til at manipulere objekter på deres CDN.
>> Og Cloud 9 klienter efter lastning, vil finde disse plug-ins i det.
C9 plug-in mappe, og indlæse dem.
Men de er stadig sker kun på klientsiden.
Så det er bare at en undtagelse, forekommer kun
til udvikling af Cloud 9 plug-ins.
Men resten af time-- og grunden
at vi ønsker at virkelig hammer denne home--
er fordi det meste af tiden er det kommer til at køre fra CDN,
og lige til at blive kørt udelukkende fra klientsiden.
>> Normalt er der vil ikke være nogen interaktion med plug-in,
eller der ikke engang at være nogen grunden til, at plug-ins selv
faktisk gemt på underliggende havnearbeider eksempel,
undtagen i tilfælde af dette SDK udvikling.
Så igen, dette ændrer bare lidt på grund af det faktum,
at vi kører SDK tilstand.
Det kommer til at læg dem plug-ins fra udvikling,
og det eneste formål her er så Jeg kan bruge Cloud 9 til at gøre udvikling
til Cloud 9 plugins.
Men alligevel, ændrer det ikke igen, hvordan noget af det virker.
Det er stadig at blive kørt udelukkende på klientsiden.
>> Det betyder blot, at når jeg ønsker at oprette Cloud 9 plug-ins i Cloud 9,
Jeg skaber disse plug-ins, sætte dem i min.
C9 / plugins mappe i mit hjem mappe, skal du sørge for jeg er i SDK-tilstand,
genindlæse siden hver gang jeg faktisk foretage ændringer af denne plug-in,
og se hvad der sker i min JavaScript-konsol.
Bare styre min JavaScript trøste at sørge
at enhver fejlfinding oplysninger, som jeg placerer for at trøste,
eller noget andet, der måtte opstå på grund af fejl, som jeg har skrevet
i min kode eller lignende, vises der.
>> Og med det, det er virkelig nok til at komme i gang, tror jeg,
med Cloud 9 plug-ins.
Især tage et kig på SDK dokumentation, Cloud 9 giver.
Det er en fantastisk måde at få gang, og meget let
skabe nogle plug-ins til Cloud 9.
Og med det, vil jeg gerne takke jer alle meget for sammenføjning mig.
Jeg håber, du vil have det sjovt skriver plug-ins til Cloud 9.
Måske forbedre plug-ins at vi har nu, eller måske endda
tilføje nogle funktioner af din egen.
Vi glæder os til at se hvad det er, du opretter.
Indtil da, farvel.