Pycon Finland 2015

Mon, 19 Oct 2015 13:47:26 +0000

(nettip�iv�kirja 19.10.2015) Olin t�n��n Pycon Finland -tapahtumassa.

!!! Testaus

Hyvin perustavanlainen upbeat-puhe. K�sitteli yksikk�-, integraatio- ja toiminnallisuustestausta, yleis�kysymyksin� tulivat invarianttitestaus, suorituskykytestaus ja fuzzaus.

!!! Viestiloki sovelluksen pohjana

Mielenkiintoinen puhe, miten webbisovellusten arkkitehtuuria helpotetaan sill�, ett� sis�iseen kommunikaatioon k�ytet��n ('''kunnollisia''') viestijonosoftia (RabbitMQ, Redis, Kafka, EventStore). Puhuja jollain tavoin fanitti Kafka+Python-yhdistelm��. Ihmettelenp�; t�m� kommentti n�ytt�� olevan aika hyvin kohdillaan: https://gist.github.com/markrendle/26e423b6597685757732

Periaatteessa idea on t�m�: aina, kun teet jotain tilamuutoksia (eli perinteisesti, kun kirjoitat tietokantaan), ty�nn�t muutokset pysyv��n jonoon ja annat taustapalveluiden lukea ne sielt�. T�llaisia taustapalveluita ovat esimerkiksi tietokanta, v�limuisti, notifikaattorit, analytiikkaty�kalut ja datan varmuuskopiot. T�m� on periaatteessa kiva arkkitehtuuri, mutta jos haluat n�ytt�� tehdyn muutoksen saman tien palvelun k�ytt�j�lle, sinun pit�� joko tehd� notifikaatiomekanismi, jolla tietokanta kertoo saaneensa tiedon perille, tai sitten vain feikkaat ja n�yt�t palautesivun ik��n kuin se tulisi tietokannasta.

!!! FreeIPA apuna webbisovellusten integroimisessa AD:iin

Olennaisesti ehdottaa t�llaista arkkitehtuuria:

* FreeIPA integroidaan AD:iin yhten� mets�serverin� (forest node) ja laitetaan cross-domain trust siten, ett� FreeIPA pystyy kyselem��n AD:sta tietoja * Serverit integroidaan SSSD:ll� FreeIPAan (jolloin ei tarvita AD-lisenssej�) * Python-sovellukset voivat k�ytt�� Ipsilon-kirjastoa ottaakseen yhteytt� IdP:ihin SAML:lla * Ipsilonissa on my�s oma IdP-toteutus joka on integroitu FreeIPA:an (eli jonkinlainen vaihtoehto Shibbolethille?) * Mutta: jos k�ytt�� GSSAPI-tietoista selainta, Ipsilon-palvelin ilmeisesti osaa pyyt�� Kerberos-tiketin? (FF:n about:config:ssa on network.negotiate-auth.trusted-uris -asetus siit�, miss� domaineissa yritet��n katsoa k-tiketit l�pi) (kerberos-listaus: $ klist) * Ipsilon-client antaa webisovellukselle paljon MELLON_-alkuisia ymp�rist�muuttujia

(kerberos-logout: $ kdestroy; kerberos-login: $ kinit )

!!! Asphalt-systeemi

Jonkinlainen modulaarinen Twisted; yritys tehd� node.js:n kaltainen ekosysteemi Pythonille? My�s yritys laittaa pystyyn jonkinlaisia kehitysstandardeja samalla. Mutta oikeastaan koko esityksest� puuttui kunnon "miksi"-osuus. Lueteltiin olemassa olevien frameworkien ongelmia, mutta minulle ei selvinnyt, mit� t�ll� Asphaltilla yritet��n saada aikaan.

T�ss� on merkillisen paljon vakiotapoja hallinnoida ohjelman komponenttien metadataa, miksi? Olennaisesti Asphaltissa k��rit��n olemassa olevien kirjastojen luokat ja palvelut Asphalt-komponenteiksi, mutta mit� lis�arvoa se tarjoaa yli ihan tavallisten kirjastojen? (Vastaus kysytt�ess�: komponentit pystyv�t "vakioiduin tavoin" keskustelemaan kesken��n, ��h, mit�h�n t�m� tarkoittaa.)

Ainoa hy�dylliselt� n�ytt�v� idis: metodit voidaan dekoroida @blocking tai @asynchronous sen mukaan, halutaanko ne suorittaa thread poolissa vai asyncloopissa. Dekoraatiotko huolehtivat t�st� koodaajan puolesta?

Esiintyj� on j�nn�. Tiet�� selv�sti aika hyvin, mit� on tekem�ss�, eik� n�yt� j�nnitt�v�n esiintymist�, mutta ei ole yht��n innostava eik� n�iss� esitellyiss� projekteissa ole keit��n muita kehitt�ji� mukana :/ Ja tuotoskin vastaa t�t�, kaikessa on jotenkin ylisuunniteltu fiilis, tulee v�h�n samanlainen "mihin t�t� tarvitaan" -olo kuin esim. BEEP-protokollasta. Ja esimerkki tulee 50 minuutin teoreettisen arkkitehtuurin esittelyn j�lkeen.

!!! Async / await

Rakentaa asyncio.coroutine:n p��lle (joka my�s on event loop -abstraktio)

* @asyncio.coroutine def foo(): -> async def foo(): (��h, mit� yield from tekee?) * yield from foo() -> await foo() * with (yield from foo) as x: -> async with foo as x: * __aenter__ ja __aexit__ tulevat kutsutuiksi ilmeisesti, kun k�ytet��n async with -rakennetta. * for row in (yield from foo): -> async for row in foo: * __aiter__ ja __anext__ "async iterable"

Ilmeisesti "yield from foo()" == "for x in foo(): yield x", juu.

Oikeastaan se, mist� kannattaa ottaa selv��, on asyncio-kirjasto (https://docs.python.org/3/library/asyncio.html) eik� t�m� syntaktinen sokeri. Twistediss� pit�� kirjoittaa event-pohjaiset ohjelmat takaperin, koska Pythonissa ei ole yleist� rakennetta nimett�m�lle funktiolle, mutta t�m� restrukturoi ne korutiineiksi.

Mutta: onko korutiineja nyky��n kahdenlaisia? Mit� asyncio.coroutine tekee? Joka tapauksessa nyky��n on siis ilmeisesti paljon kirjastoja, joissa ihan tavallisetkin operaatiot on mallinnettu generaattoreina, jotka yieldaavat jotain, kun haluavat luovuttaa suorituksen muualle. await/yield from on normaali tapa tehd� alirutiinikutsu tuollaisen generaattorin ''sis�ll�''.

Tavallaan Pythonissa kehitet��n syntaktista tukea er��nlaiselle call-with-current-continuation:lle ja siihen liittyv�lle dynamic-wind:lle. Outoa.

Olen my�s jotenkin missannut generaattoreiden kaksisuuntaisuuden (g.send() ja https://docs.python.org/2/whatsnew/2.5.html#pep-342-new-generator-featur es)

Asyncio:ta katsellessa tulee mieleen oma rakas Selecting vuosien takaa, joka hoiti homman perinteisell� olio-ohjelmoinnilla: http://sange.fi/~atehwa/selecting/Selecting/

!!! Bugien etsint�

"Te, jotka vain kirjoitatte koodia, olkaa huomaavaisia ja miettik�� niit�, jotka tulevat j�lkeenne. Ottakaa kiinni niist� 'kun on aikaa' -kehitysteht�vist�."

"Ei ole kovin hankalaa lukea koodia, mutta sen kehittymishistorian ymm�rt�minen on jo vaikeaa"

Adam Tornhill: /Code as a Crime Scene/ "Combining forensics with software engineering", voiko esim. bugeja l�yt�� samalla metodologialla kuin todenn�k�isi� murhapaikkoja?

Code city environment: mapataan komponentit ja alikomponentit alueiksi 2d-tasolle, tiedostot ovat rakennuksia joiden korkeus on monimutkaisuus, koko on tiedoston koko ja v�ri on esim. tuoreus.

Erilaisia ty�kaluja MSR:iin ("mining software repositories"): Git + Code Maat + D3

Tuloksia: hierarkkinen moduulilistaus + v�rilliset ympyr�t koodin kirjoittajan mukaan. Helppo tunnistaa omia alueita, helppo tunnistaa yhteis�llisesti yll�pidettyj� juttuja.

Ent�s se bugien etsint�? Etsitty Djangon l�hdekoodista kohdat, joita koskettaa commit jonka viestiss� /Fix... #[0-9|]/. Miss� pahimmat bugit? DB-moduulissa. Ja seh�n vastaa Django-kehitt�jien kokemuksia? Bugien todenn�k�isyys kasvaa my�s, kun samaa koodia aktiivisesti kehitt�vien kehitt�jien m��r� kasvaa. Ja bugifixien kanssa korreloi se, ett� on paljon pieni� commiteja.

Voisiko t�llaista tietoa hy�dynt��? Gitiss� voisi olla hookeja, jotka varoittavat siit�, ett� siit� on aiemmin l�ytynyt bugeja / sit� on editoitu paljon yhtaikaisesti. "Warning: bugs ahead".

Yksi visualisointi: git blame:n sijaan tuoreuden mukaan v�ritetty versio, johon lis�t��n kohdat, jossa joskus oli bugi. Tai profilointi-informaatio. N�m� voisivat olla asioita, joita lis�isi CI-servereiden koodin�kymiin.

My�s korrelaatioiden etsint� voisi olla hy�dyllist�, kuten esimerkiksi organisaatiorakenteen vertaaminen koodin rakenteeseen (ks. https://en.wikipedia.org/wiki/Conway%27s_law) tai profilointidatan vertaaminen koodin kirjoittaneisiin ihmisiin.

Testitapausten kattavuuden vertailu muihin metriikoihin.

----

* [merkint�: 2015-10] * [atehwa] * [kategoria: p�iv�kirjamerkint�] * [teos: python] * [python] * [vaihdettavat komponentit]