Mikä on WikiWiki?
nettipäiväkirja
koko wiki (etsi)
viime muutokset
(nettipäiväkirja 19.10.2015) Olin tänään Pycon Finland -tapahtumassa.
Hyvin perustavanlainen upbeat-puhe. Käsitteli yksikkö-, integraatio- ja toiminnallisuustestausta, yleisökysymyksinä tulivat invarianttitestaus, suorituskykytestaus ja fuzzaus.
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.
Olennaisesti ehdottaa tällaista arkkitehtuuria:
(kerberos-logout: $ kdestroy; kerberos-login: $ kinit <ktunnus-principal>)
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.
Rakentaa asyncio.coroutine:n päälle (joka myös on event loop -abstraktio)
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-features)
Asyncio:ta katsellessa tulee mieleen oma rakas Selecting vuosien takaa, joka hoiti homman perinteisellä olio-ohjelmoinnilla: http://sange.fi/~atehwa/selecting/Selecting/
"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.
Pikalinkit: