Koding med koding

Cloud IDEs har eksistert en liten stund nå, og de har vært ganske bra for ting som parprogrammering, eller tilfeller der du vil kode konsekvent uansett hvor du er. Koding kom bare ut av privat beta, og de vil gjerne ta dette begrepet et par skritt videre, med deres "sky økosystem".

I denne artikkelen vil vi se på hva Koding er, så vel som noen av fordelene du kan få fra å bruke den.

Koding er litt vanskelig å forklare, fordi det ikke er et produkt som ligner det på markedet. For å bedre illustrere alle sine bevegelige deler, la oss dele opp tjenesten og begynne med utviklingsmiljøet.


Utviklingsmiljøet

Når du registrerer deg for Koding, får du ditt eget underdomen (.kd.io) til din egen VPS, og noen er innebygd i webapps for å administrere de nye ressursene dine..

Gjennom administrasjonen har du muligheten til å opprette andre underdomener på toppen av din nåværende nettadresse, og spinn opp nye VPS'er gjennom en brukervennlig brukergrensesnitt.


VM

Nå er disse VMene ikke dine gjennomsnittlige mikroinstanser som tilbyr mange tjenester, disse er fullverdige VM med tilgang til åtte prosessorer og en full GB RAM, slik at du enkelt kan kjøre omtrent alle apper, og hvis du vil leke med ting som klyngeoppsett eller nettverk, kan du enkelt slå opp flere forekomster for bare $ 5 per måned.

Så når det gjelder prosessorkraft, kan disse tilfellene potensielt være like kraftige som din egen datamaskin, og de er definitivt bedre enn å laste inn en lokal virtuell maskin.

Det som folkene over ved Koding prøver å gjøre, er å gi utviklere mulighet til å lære gjennom eksperimentering og bare prøve ting som de ikke nødvendigvis vil prøve lokalt, eller bare ikke ha ressurser til å gjøre det.

Disse tilfellene initialiseres om noen sekunder, og hvis du gjør feil og ødelegger noen systemfiler, kan du enkelt bare starte på nytt på serveren, og det vil gjenopprette alt under hjemmemappen. I hovedsak har du en ny forekomst, men alle filene du opprettet i hjemmemappen, blir bevart.

En annen ting de gir, som faktisk er en ganske stor avtale i noen situasjoner, er root-tilgang til alle serverne dine. Koding er en veldig gjennomsiktig tjeneste, du får en VM, og du kan bokstavelig talt gjøre hva du vil med det. Alt du kan gjøre med en standard VPS, kan du gjøre med deres VM.

OS og språk

Når det gjelder tilfeller selv, kommer de med Ubuntu installert, og stort sett alle språk jeg kan tenke på, inkludert:

  • PHP
  • node.js
  • Rubin
  • Perl
  • Haskell

Blant annet, så er du ganske bra å gå ut av esken.

Apps

Med Koding har du slags to lag med applikasjoner. Du har VM, som, som jeg nevnte, kan du kjøre alt du vil ha på, men i tillegg har du Koding Apps som er web-apper som kjører på Koding selv, og gjennom dem kan du administrere alle dine Koding-ressurser.

Noen av standardappene du har tilgjengelig for deg, er ting som administrasjonspaneler for databaser eller rammer og redaktører for kode og bilder. Standard kodeditoren som kommer forhåndsinstallert, er Ace-kodeditoren for vanlig utvikling, eller Firepad hvis du vil arbeide sammen gjennom samarbeidsprogrammet.


Foruten alle disse veldig kule appene, har du muligheten til å lage din egen. De er skrevet ved hjelp av vanlig JavaScript (CoffeScript) og KD-rammen (fra Koding). Nå fordi de nettopp har kommet ut av beta, er det egentlig ikke en ferdig dokumentasjonsside ennå, men det finnes to Koding apps tilgjengelig (kodepad og app maker) som er bygget for å gi deg en slags struktur, med eksempler. I tillegg til de, vil jeg anbefale å søke Github for ".kdapp" og bare se på hvordan andre apps ble bygget for å få en ide om hva slags ting som er mulige og hvordan å oppnå dem.

Samlet sett har det en følelse av et operativsystem for skyen der du har VM-ene som ressurser, men Koding-appene tillater deg å administrere ressursene dine og sette dem opp akkurat slik du vil. Dette betyr at hvis firmaet ditt har en slags boilerplate-oppsett, kan du opprette en kdapp som vil konfigurere en ny VM med filene og programvaren du trenger, og når du spinner opp en ny forekomst, kan appen konfigurere det akkurat slik du liker.

I tillegg kan kdapps være et frittstående verktøy som bare endrer filer som Ace-editoren, eller bildeditorer som er tilgjengelige. Dette betyr at hvis du legger inn tiden, kan du i hovedsak bygge din egen dev-miljø, med alle de egendefinerte verktøyene som gjør deg mer effektiv på å bygge apper.

Alt jeg har nevnt til nå, dekker egentlig bare halvparten av det som Koding er, og det er utviklingsmiljødelen. Koding har også en sosial / organisatorisk side av det, som komplimenterer utviklingsfunksjonene og øker plattformens verdi.


Utviklerfellesskap

Som standard, når du registrerer deg for Koding, legges du til Koding "gruppen"; Alle funksjonene, som aktivitetsvarsler, emner, kodeoppslag, etc ... kommer alle fra denne standardgruppen. Det er litt kult å få alle oppdateringene fra brukere over hele verden, og du kan filtrere etter emne ved å gå til emnesiden og velge noe du er interessert i. Men hvor disse funksjonene virkelig viser potensial, er når du lager din egen gruppe.


Hvis du bruker Koding som en gruppe, kan du dra nytte av alle disse funksjonene for å enkelt se hva dine kolleger har gjort, få oppdateringer og utdrag fra dem, og filtrer alle innleggene ved prosjekt ved hjelp av emnene som tagger.

I en gruppe kan du opprette delte VMer som flere brukere kan ha tilgang til, eller kreditere brukere i gruppepengene, slik at de kan lage egne VM-er og jobbe privat.

Det er en av de situasjonene hvor de nok kunne ha sluppet utviklingsmiljøet for skyen, det sosiale nettverket eller prosjektledelsen, og det ville ha passet et marked; men å ha dem alle sammen og gratis, er noe å virkelig tenke på.

Jeg har sagt mange positive ting om skymiljøer, men det er noen ulemper når man sammenligner dem med å utvikle lokalt som er verdt å nevne minst.


Cloud vs lokal utvikling

ulempene

En av de viktigste tingene er at du egentlig ikke får det jeg vil kalle en IDE. Hvis du for eksempel ser på ess-editoren, er det en flott editor, men når du stabler den opp mot en fullverdig IDE som PhpStorm, sammenligner de ikke. Ess er bare en kodeditor, mens PhpStorm inneholder alle verktøyene du trenger fra testing til refactoring, alt i ett app.

Den andre ulempen er bare latens, nå sammenlignet med andre web-IDEer, jeg har ikke hatt for mye av et problem med dette på Koding, men likevel sammenligner det ikke med et lokalt oppsett. Når du utfører en handling som å åpne et dokument, kan det noen ganger ta et sekund å åpne.

For å oppsummere kan det hende at utviklingen på Internett ikke har alle verktøyene du er vant til å jobbe med, og det kan ikke være så fort som å gjøre det lokalt. Men når du utvikler seg lokalt, mister du på de kraftige VM og alle prosjektledelse / sosiale funksjoner.

Heldigvis behøver du ikke gjøre noe valg. Redigeringskode online er alltid mulig, slik at du ikke trenger å ofre på den fronten, men hvis du foretrekker å kode lokalt med dine egne verktøy, har du full SSH-tilgang til maskinene dine. Så om du vil bruke FTP, SCP, GIT eller noe annet verktøy for å overføre endringene dine til serveren, får du disse alternativene, akkurat som en standard VPS.


Sette opp SSH & Rsync

Nå har jeg allerede dekket hvordan du installerer en ren GIT-repo for å distribuere til serveren din, så det er overflødig å dekke denne prosessen på nytt, men la oss se på å sette opp Koding-kontoen din med en SSH-nøkkel og bruke rsync til å overføre prosjektet til og fra koding.

For den ukjente er rsync et verktøy for overføring av store prosjekter til og fra datamaskinen. Hvor det er forskjellig fra noe som SCP, og årsaken til at det er bra å jobbe med store prosjekter, er det at den skal skanne filene både lokalt og eksternt, og bare overføre filene som har endret seg. Hvis du jobber med noen form for prosjekt, skal du ha noen rammesystemfiler, noen boilerplate-kilder, bilder osv. .. og du vil ikke sende dem på alle forespørsler, så rsync er et veldig godt valg for ting som dette.

Det er ikke så bra som GIT, du får ingen form for versjonskontroll, men hvis du bruker Koding som et testmiljø, og du bare vil kaste filer opp, eller trekke dem ned, er rsync verktøyet for jobben.

Det første trinnet er ganske enkelt, og det er å få SSH-oppsett; du trenger bare å ta tak i din offentlige nøkkel (på en Mac du kan kjøre katt .ssh / id_rsa.pub | pbcopy fra et terminalvindu for å kopiere nøkkelen) og legg den til på kontosiden din på Koding. Den neste tingen du trenger å gjøre er å konfigurere datamaskinen til å koble til. Koding krever at du bruker sin proxy som en tunnel til serveren din, så på et Unix-basert system kan du bare opprette en fil som heter 'config'med følgende innsiden (du må erstatte dette med ditt Koding brukernavn):

 Host * .kd.io Bruker  ProxyCommand ssh %[email protected] nc% h% p

Hvis du er på et Windows-system, kan du se i veiledningen for å se hvordan du konfigurerer proxyen med Putty.

Med det på plass kan du kjøre:

 ssh vm-..koding.kd.io

Så for eksempel bruker brukernavnet mitt, på den første standard VM (som er nummer 0) du vil kjøre følgende:

 ssh vm-0.gabrielmanricks.koding.kd.io

Hvis alt gikk bra, bør du koble til og se Koding terminal meldingen. Hvis den ikke vil koble til, må du passe på at du legger til den offentlige nøkkelen og sørg for at VM er på i Koding (VM-en slår av når du ikke har brukt dem i ca 20 minutter).

Med det oppsettet kan vi nå opprette et lokalt prosjekt. Vi trenger egentlig ikke noe fancy her, så for dette eksempelet skal jeg bare lage en enkel hei verdens HTML-fil inne i en tom mappe:

    Koding Demo   

Hei rsync

Lagre denne filen i din prosjekter mappe og kjør deretter:

 rsync -rvza --delete ./ vm-..koding.kd.io:~/Web/

Dette vil kopiere hele innholdet i gjeldende lokale mappe til den eksterne katalogen, og slette eventuelle eksterne filer som ikke er i gjeldende mappe. Hvis du noen gang gjør endringer eksternt, kan du enkelt trekke dem ned ved å reversere stiene slik:

 rsync -rvza vm-..koding.kd.io:~/Web/ ./

Nå er disse kommandoene litt lange, og hvis du planlegger å utvikle på denne måten, vil du ønske å lage noen snarveier. En enkel måte er å bare opprette bash aliaser, men du kan ha flere servere, og for hver du trenger et alias for hver retning, så la oss bare lage et enkelt bash-skript som kan godta VM-nummeret sammen med brukernavnet og ønsket retning du vil at filene skal gå, og den vil utføre overføringen.


Bash Primer

Jeg skal ikke dekke alle Bashs syntaks, bare de delene vi trenger for dette skriptet.

Først trenger vi variablene, inne i et bash script du definerer variabler ved å skrive name = verdi. For eksempel, hvis vi ønsket å angi en variabel som inneholder en melding, ville vi skrive:

 melding = "Hei"

Det bør ikke være noen mellomrom rundt likestillingsskiltet for at det skal fungere. Når du er satt, kan du deretter hente verdien av en variabel ved å skrive navnet med et dollarskilt før det. Så for å skrive ut variabelenes verdi, ville vi skrive:

 ekko $ melding

I tillegg til variablene du definerer og angir, kan du bruke et par globale variabler som er angitt av miljøet ditt. Disse kan være forskjellige i henhold til oppsettet ditt, men de vi skal bruke er $ USER for den innloggede brukeren og $ PWD for den nåværende mappen. Du kan se hvilke variabler som er i ditt miljø ved å legge til printenv til koden din. Dette vil skrive ut alle miljøets nåværende variabler.

Den neste tingen vår skript trenger, er å kunne akseptere kommandolinjearguder. Dette er faktisk veldig enkelt å gjøre, da de blir nummererte variabler. Så $ 1 representerer den første parameteren, $ 2 er den andre og så videre.

Det siste vi må bruke i skriptet vårt er hvis uttalelser. Disse ligner på hvordan du vil skrive en if-setning i de fleste programmeringsspråk, med noen merkbare quirks:

 hvis [uttrykk] gjør noe her, gjør noe annet her fi

I bash-skript har du uttrykket mellom et par firkantede parenteser, og du må legge igjen et mellomrom mellom parentesene og uttrykket. Du bør også merke seg at deretter linje er et krav. Den siste forskjellen, som er litt annerledes, og som finnes i andre bash-strukturer, er fi søkeord. I utgangspunktet skriver du bare om bakover, det er det samme for en bryteretning, for eksempel starter du bryterblokken med sak og så avslutter du det med ESAC (saken reversert).

Så med denne informasjonen, la oss lage et enkelt skript for å hjelpe oss med å laste opp og laste ned koden vår til Koding:


Bygge vårt skript

Til å begynne med, trenger vi hele shebang å fortelle datamaskinen å kjøre den som et skalskript, og da vil jeg opprette en enkel hjelperfunksjon som vil fortelle brukeren hvordan man bruker denne kommandoen:

 #! / bin / sh-funksjon koding_usage echo "Bruk: koding [push | pull]  "utgang 1

Hvis du er ny for å avslutte koder, 0 betyr at det har gått ut vellykket, og er standard returnert når et skript er ferdig, mens alt annet er en utgangskode for når en feil har oppstått. Så hvis denne funksjonen blir kalt, betyr det at skriptet ikke ble brukt riktig, og vi vil avslutte med en feilkode.

Deretter må vi sørge for at argumentene ble sendt riktig inn og i prosessen, samle dem og lagre dem i noen hjelpevariabler:

 hvis ["$ 1" = ""]; ekko "Command Required" koding_usage fi hvis ["$ 1"! = "push"] && ["$ 1"! = "pull"]; deretter ekko "Du kan bare trykke eller trekke" koding_usage else command = $ 1 fi hvis ["$ 2" = ""]; deretter ekko "VM-nummer påkrevd" koding_usage annet vmnumber = $ 2 fi hvis ["$ 3" = ""]; da brukernavn = $ USER annet brukernavn = $ 3 fi

I denne koden foretar vi fire forskjellige sjekker:

  1. Vi sjekker om det er en første parameter
  2. vi sjekker for å sikre at den første parameteren er enten 'trykk'eller'dra'
  3. Vi sørger for at det er en andre parameter
  4. Vi kontrollerer om den tredje parameteren ble satt

I de tre første hvis uttalelser, hvis det var et problem vi ekko ut en melding og deretter ringe vår hjelper metode fra oven. For det siste, men hvis ingen brukernavn ble levert, bruker vi bare brukernavnet som er innlogget for øyeblikket. Så hvis datamaskinens brukernavn er det samme som ditt Koding brukernavn, kan du la den siste parameteren av.

Det siste vi må gjøre, er faktisk å kjøre rsync-kommandoene basert på kommandoen som er forespurt (trykk eller trekk):

 hvis ["$ command" = "push"]; deretter rsync -rvza - delete $ PWD / vm- $ vmnumber. $ username.koding.kd.io: ~ / Web-annet rsync -rvza vm- $ vmnumber. $ brukernavn.koding.kd.io: ~ / Web / $ PWD fi

Du kan se at vi bare plasserer variablene vi samlet inn (sammen med gjeldende mappe $ PWD) rett inn i kommandoen. Siden dette er et shell-skript, kan du bare plassere shell kommandoer rett inn, som jeg gjorde over

Lagre filen og gi den navnet Koding og gjør det kjørbar (du kan gjøre dette ved å kjøre chmod + x koding) og sist men ikke minst, flytt denne filen til din bin mappe:

 mv koding / usr / local / bin /

Hvis du gjorde alt riktig, bør du kunne kjøre Koding og se vår brukermelding komme opp. Så nå kan du gjøre en rask endring til eksempelprosjektet ovenfor og bare kjøre:

 koding push 0

Forutsatt at du ikke trenger brukernavn eiendom, og din nåværende mappe blir overført som webkatalog på serveren din, navngitt vm-0. Det samme gjelder for hvis du gjør endringer online, kan du cd inn i den lokale prosjektmappen og løp:

 koding pull 0

Og du vil motta alle oppdateringene.


Konklusjon

Koding er et veldig kraftig verktøy for prototyping og læring gjennom eksperimentering. Det har virkelig kule sosiale og prosjektledelse evner og å kunne kode med noen andre, leve, kan gjøre en stor forskjell når du prøver å feilsøke noen kode. For ikke å nevne at alt er gratis, betyr det at det egentlig ikke er grunn til at du ikke vil bruke dette.

Jeg liker virkelig ideen om å ha kd apps som kjører utenfor VMs, og jeg tror det blir kult å se hvor folk vil ta det og hva slags verktøy folk skal bygge.

Du kan registrere deg for Koding ved å besøke koding.com.

Takk for at du leser, jeg håper du likte det, hvis du har spørsmål, vær så snill å gi meg en kommentar nedenfor, på twitter eller via Nettuts + IRC-kanalen (#nettuts på freenode).