Elastinen osaajapilvi

Maailmassa on miljoona hyvää syytä olla käymättä töissä. Jotkut niistä pätevät jopa niinkin hyvään yritykseen kuin Codento. Jos haluat vaikkapa opiskella täyspäiväisesti, pitää neljän kuukauden kesäloman, kyllästyt jokaiseen firmaan aina viimeistään 6kk kohdalla tai ajatus esimiehestä ei vaan sovi sinulle, niin päivätyö ei ehkä ole sinua varten.

Koska et ole yksin tilanteesi kanssa, olemme keksineet tähän ratkaisun. Jos mielelläsi hengailisit kanssamme päiväsaikaan softaprojektien merkeissä ja rahaakin olisi kiva ansaita, mutta et kuitenkaan halua Codentoon töihin, voit ryhtyä CCP:ksi.

CCP, eli Codento Certified Partners on joukko itsenäisiä ammatinharjoittajia, jotka tekevät töitä Codenton softaprojekteissa oman yhtiönsä kautta tai freelancereina. Jotkut tekevät pääasiassa Codenton projekteja, toiset taas vain satunnaisia keikkoja kauttamme.

CCP ei ole mikään plussakorttikerho, johon pääsee ihan vain täyttämällä paperin. Haastattelemme kaikki CCP-ehdokkaat samaalla piinallisella tarkkuudella kuin työnhakijatkin. Osaamisvaatimuksetkin ovat oman alan (oli se sitten backend, front end, käli, projektiveto, QA tai mikä vaan) suhteen yhtä tiukat kuin työntekijöilläkin, mutta fokus saa olla kapeampi. Käytettävyyssuunnittelija-CCP:n ei tarvitse koodata.

Yrityksen kannalta CCP-malli on kätevä “osaajapilvi”. Meillä on tarjolla projekteihin enemmän väkeä kuin mitä olemme ehtineet tai uskaltaneet rekrytoida. Kustannussäästö se ei sen sijaan ole.  Itse asiassa tulisi Codentolle halvemmaksi palkata aktiiviset CCP:t suoraan palkkalistoille. Mutta kun yhä useampi softan tekijä ei halua täysipäiväistä työsuhdetta.

Jos siis näet jonkun tuttavasi Linkedin-profiilissa lyhenteen CCP, tiedät että:

  1. Hän on oman alansa pätevä osaaja.
  2. Hänellä on kunnia kuulua Codenton ammattilaisten osaajapilveen.

PS. CCP:itä haetaan koko ajan lisää siinä kuin työntekijöitäkin. Jos kiinnostuit, siirry rekrysivulle.

Tämän artikkelin on kirjoittanut Otso Kivekäs ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Interaktiivinen Git rebase Emacsissa onnistuu näin

Innokas Emacs– sekä Git-käyttäjä on todennäköisesti havainnut että Emacs ja git rebase -i eivät noin vaan toimi hyvin yhdessä. Tämä on harmi koska Gitin interaktiivinen rebase on aivan mainio toiminnallisuus versionhallintajärjestelmässä.

Missä ongelma on? Se on siinä, että rebase-komento haluu käynnistää tekstinmuokkaimen (engl. editor) muokkaamaan väliaikaista tiedostoa, joka määrittää rebase-komennon toimet. Mutta:

  • Kun jo olet Emacsissa, et halu käynnistää uutta Emacsia pelkästään rebase-komentoa varten.
  • Et myöskään halu poistua Emacsista (käyttäen shellin job
    control
    -toiminnallisuutta tai muuten), koska silloin menetät ympäristösi kuten esim. nykyisen työhakemistosi.
  • Etkä halu käynnistää terminaaliemulaattoria Emacsin sisällä (“M-x term”) rebase-komennon ajoa varten, koska sekin vain aiheuttaisi rekursiivisen tekstinmuokkaimen käynnistämisen tekstinmuokkaimen sisällä.

Ihanne olisi että voisi ajaa rebase-komennon samoin kuin muut shell-komennot suoraan Emacsista (“M-x shell-command”), ja että väliaikaisen tiedoston sisältö ilmestyisi nykyisen Emacsin puskuriin muokattavaksi. Miten saavuttaa tämän?

Koska Gitin rebase-komento käyttää EDITOR-ympäristömuuttujassa määriteltyä tekstinmuokkainta, sille pitäisi tässä ympäristömuuttujassa saada syötettyä jonkun kommennon jolla edellä mainittu saisi saavutettua. Tämä voisi onnistua esim. “emacsclient”-apuohjelmalla. Ratkaisu koostuu seuraavasta:

  1. Valmista asettamalla tarvittavat ympäristömuuttujat Emacsissa: (setenv “EDITOR” “emacsclient”). Seuraavaksi mahdollista emacsclientin ottaa yhteyttä nykyiseen Emacsiin ajamalla “M-x server-start”.
  2. Suorita sitten rebase-komento: “M-x shell-command” + git rebase
    -i &
    . Muista &-merkki jotta komento ajetaan asynkronisesti — muuten komento jää lukkoon.
  3. Voila! Rebase-komennon tuottama väliaikainen tiedosto ilmestyy nykyisen Emacsin uuteen puskuriin muokattavaksi. Muokkaa sitä toiveidesi mukaan, ja lopeta kirjoittamalla “C-x #” joka päättää muokkaamisen ja antaa rebase-komennon jatkaa suorittamista.

Tämä mahdollistaa git rebase -i -komennon käyttöä Emacsin sisältä, mikä on tarpeellista, jos haluaa Gitistä irti täyden tehon.

Tämän artikkelin on kirjoittanut Markus Holmberg  ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Kun taivas putosi ja netti hajosi

Kuukausi sitten IP-osoitteet loppuivat. Taivas ei vielä pudonnut Internetin päälle. Todennäköisesti kuitenkin luet tätä Internetin välityksellä. Asiasta uutisoitiin ihan valtamediassakin, mutta suurin osa raportoinnista jätti minut kylmäksi. Joko sorruttiin pahoihin teknisiin virheisiin tai sitten nokkela toimittaja vertasi IP-osoitteita johonkin sellaiseen, mihin IP-osoitteet eivät kovin luontevasti vertaudu. Listaan parhaat lukemani artikkelit alempana.

IP-osoitteita on kahta sorttia. Ensimmäistä tyyppiä ovat version 4 mukaiset IP-osoitteet (IPv4), joiden loppumisesta puhun. Toista tyyppiä ovat uudemmat IPv6-osoitteet. Nämä eivät ole keskenään yhteensopivia. Nykyisin Internetissä käytetään pääasiassa IPv4-osoitteita. Tulevaisuudessa jollain aikavälillä siirrytään käyttämään IPv6-osoitteita—oikeastaan olisi pitänyt siirtyä jo. Tämä siirtymä kuitenkin maksaa, vaatii työtä ja on paikoin vaikeaa. Siksi sitä ei ole tehty.

Dramatis Personae

IP-osoitteita (molempia versioita) käytetään datapakettien välitykseen Internetiin kytkettyjen tietokoneiden välillä. IP-osoitteita jaetaan käyttöön hierarkisen organisaation mukaan.

Ylimpänä on Internet Assigned Numbers Authority (IANA). IANA vastaa koko IPv4-avaruudesta ja sen hallinnasta. IANA jakaa (tai oikeastaan jakoi) IPv4-osoiteavaruutta /8-verkoissa, joihin mahtuu 16,8 miljoonaa osoitetta.

Näin isoja lohkoja ei myönnetä (nykyään) millekään käyttäjäorganisaatiolle suoraan. Välissä toimivat alueelliset numerointiorganisaatiot eli Regional Internet Registryt. Näiden vakiintunut lyhenne on RIR, jota käytän loppuartikkelissa.

RIRejä on viisi kappaletta. Amerikoissa ARIN ja LACNIC, Afrikassa AfriNIC, Aasiassa ja Australiassa APNIC ja Euroopassa RIPE. RIRit pilkkovat IANAlta saamansa lohkot pienempiin palasiin ja jakavat nämä eteenpäin paikallisille toimijoille (Local Internet Registry eli LIR).

LIR on useimmiten Internet-palveluntarjoaja, suuremman luokan yritys tai akateeminen instituutio. Tästä eteenpäin osoiteavaruuden organisointi on kunkin LIRin sisäinen asia. Kaikki päätelaitteet saavat siis IP-osoitteensa LIRin ylläpitämästä järjestelmästä. Välissä on vielä muutama kerros verkkohallintaa, mutta niistä en voi mitään yleispätevää sanoa.

Lähimmän LIRin voit löytää RIPEn karttapalvelun avulla. Helsingin kantakaupungista löytyy pari tusinaa LIRiä.

Eli mikä loppui

Viimeisen vajaan kahden vuosikymmenen aikana IANA ja sen edeltäjät ovat annostelleet IPv4-osoiteavaruutta /8-verkoissa. Tällaisia verkkoja voi olla edes teoriassa korkeintaan 28 eli 256 kappaletta. Käytännössä luku on historiallisista syistä johtuen pienempi. Esimerkiksi kokeelliseen käyttöön varattu “Class E”-lohko syö 16 kasiverkkoa.

Vuoden alussa IANAlla oli vielä seitsemän jakamatonta kasiverkkoa. Tammikuun lopussa APNIC pyysi IANAlta kahta verkkoa, minkä jälkeen saldoksi jäi viisi jakamatonta verkkoa. IANA ja RIRit ovat aikaisemmin diilanneet tätä tilannetta varten IPv6-siirtymäsopimuksen. Potin pienentyessä viiteen kasiverkkoon, ne jaetaan tasaisesti kaikkien RIRien kesken. Tämä tapahtui 4.2.2011. Alempana kuvaan hieman, mitä kukin RIR aikoo näillä lohkoillaan tehdä.

Koko maailman IPv4-varasto ei siis ole tyhjentynyt hetkessä. RIReillä on toimivaraa vielä kuukausiksi tai vuosiksi. Nyt tapahtunut “loppuminen” on vasta ensimmäinen rajapyykki. Loppukäyttäjään vaikuttavaan osoitepuutokseen menee vielä vuosi tai pari.

Mitä sitten?

IANAn arkut ovat tyhjät. Seuraavaksi allokoitavat osoitteet RIReiltä yksi kerrallaan. Kun RIRien potti pienenee tietyn rajan alle (useimmilla RIReillä /8-verkko), ne aktivoivat omat IPv6-siirtymäsuunnitelmansa. Niiden peruselementit ovat alla:

  • LIReille myönnetään kerrallaan enää minimiallokaatio, käytännössä satoja tai tuhansia osoitteita.
  • Näitäkin lohkoja myönnetään äärimmäisen kitsaasti. Euroopan RIPE ja Aasian APNIC antavat yhden lohkon per LIR. LACNIC ei anna vanhoille asiakkailleen mitään.
  • Lohkojen myöntäminen on myös koplattu IPv6-siirtymään. RIPE myöntää lohkoja vain, jos LIRillä on myös IPv6-lohko. AfriNIC taas antaa IPv6-lohkon automaattisesti IPv4-lohkon kanssa.

Kun nämäkin loppuvat, siirrytään loppupeliin. IANA ja RIRit käyvät parhaillaan keskustelua, miten osoitteiden kierrätys hoidetaan tässä vaiheessa.

Loppukäyttäjälle tilanne ei näy kovinkaan selvästi. Hän saa aina jostain IP-osoitteen. Se on kuitenkin tilapäinen ja jaettu yhä useamman käyttäjän kanssa. (Katso esimerkiksi Carrier Grade NAT.) Tämä aiheuttaa uusia ja erikoisia virhetilanteita, joita on hankala ratkoa. Yhteydet katkeavat, palvelimiin ei saada yhteyttä, paketit reitittyvät oudosti.

Outoja oireita, tosin erilaisia, aiheuttaa myös siirtyminen IPv6-osoitteisiin. Se on kuitenkin ainoa pitkällä tähtäimellä toimiva ratkaisu.

Sanasto

IANA
Internet Assigned Number Authority
RIR
Regional Internet Authority
LIR
Local Internet Authority
AfriNIC
APNIC
ARIN
LACNIC
RIPE NCC
Afrikan, Aasian, Pohjois-Amerikan, Etelä-Amerikan ja Euroopan RIR:t

Muita hyödyllisiä lähteitä

Olen nähnyt joitain hyvähköjä yleistajuisia juttuja aiheesta:

Tämän artikkelin on kirjoittanut Antti Rasinen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.