(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]