F# käyttäjäryhmän esitys
Lyhyesti monista ajankohtaisista aiheista.
Diojen tarkemmat selosteet notes-osuudessa.
Copy: https://docs.google.com/presentation/d/1DnXOeBLUt6SUh_OtxgLTYp4Za6sdOJF1nqYBPitBiNg/edit?usp=sharing
Same in English:
http://www.slideshare.net/thorium/message-passing-nosql-13005795
2. Ennuste…
Erilaisten tiedontuottajien määrä
kasvaa
Prosessorien ja kommunikaation
määrä kasvaa
Emme tunne ajoympäristöä…
(Voi olla esim. pilvi; Azure)
3. Turing, tilakoneet ja oliot
Substantiivit vs. verbit
• Kuka omistaa toiminnan?
• Olio vs. tapahtuma (event)
Tilakoneen ongelmat:
• Kompleksisuus: Missä mennään?
• Kuka aiheutti nykytilan? Miten toistetaan?
• Asynkronisuus-ongelmat, lukitukset
4. Tilan kapselointi:
Tyyppi vs Luokka vs Monad
Helpottavat toiminnallisuuksien ohjelmointia “tietyssä kontekstissa”
Tyyppi Luokka Monad
• Ei tilaa • Tila voi paljastua • Kuin tilaa ei olisi
suoraa • Tila paljastuu
• Tila näkyy myös ulos vasta
metodien kautta poistuttaessa
ulos
5. Domain-mallin rooli
Tarkoitettu kehittäjille
• Kone ei itse mallista hyödy
Yrittää mallintaa pelikenttää
• Haitat vs. hyödyt?
Roolit
• Aktiivinen / aneeminen
• Voiko malli muuttua?
11. Actors
Ei paljasta tilaansa ulospäin
Käyttää message passingia
• Voi kutsua muita
• …tai itseään
12. Agents
Ei paljasta tilaansa
ulospäin
• Ottaa vastaan pyyntöjä
Käyttää message passingia
• Voi kutsua muita
• …tai itseään
13. Continuation
Reify: Kauanko haaveillaan ja koska suoritetaan?
Mahdolliset toiminnot: jatko, lopetus tai virhe
Church vs. Call-with-current-continuation (call/cc)
14. NoSQL: Tieto ilman skeemaa
Dokumenttitietokannat
• Ei ID:itä
• Dualismi SQL-kantojen kanssa
• RavenDB, MongoDB
Big Data
• Loki-tiedostot, GPS-data, yms.
• Hadoop, MapReduce
Editor's Notes
F#User Group presentationhttp://www.meetup.com/FSharpHelsinki/events/64378772 v.1.0.2, finnish/suomiTämä esitys kuvaa lyhyen tiivistelmän monista ajankohtaisista aiheista.
Pilvi on hypeä, mutta siihen liittyy oikeitakin asioita… Tietolähteiden määrä kasvaa Prosessorien monimuotoisuus kasvaa Kommunikaation osapuolten erilaisuus kasvaaEhkä teoreettinen malli erkanee fyysisestä arkkitehtuurista: Esim. Windows Azure koittaa piilottaa fyysisen arkkitehtuurin. Ajoympäristö ei välttämättä ole tiedossa.F#:lle on suora Azure-tukiout-of-the-box.Lisätietoa: http://archive.msdn.microsoft.com/fsharpazure
Nykyisin olio-ohjelmointi on usein substantiiveilla, eikä verbeillä.Tämä on outoa koska:Toiminnallisuus on se mitä asiakas tilaa, verbejäParametrien järjestys on outo: Olio itse on usein pääasiallinen parametrinsa, paluuarvo määritellään usein ensimmäisenä ja loput parametrit (joita ei pitäisi edes olla) seuraavat metodin jälkeen.Turing on pitkään ollut oikeassa, mutta onko enää?Tulevaisuudessa on seuraavia haasteita: Prosessorien määrän kasvaessa ohjelmien tilallisuus ei voi jatkua nykyisellään
Tyyppi:Käytetään ohjelman oikeellisuuden tarkistukseenLuokka: Paljastaa tilansa toiminnallisuuksien kauttaMonad: Normaalia imperatiivisen oloista ohjelmointia välittämättä tilastaMonad ja luokka ovat tyypin alijoukkoja.Brian Beckman: Don'tfear the Monad: http://channel9.msdn.com/Shows/Going+Deep/Brian-Beckman-Dont-fear-the-MonadsKontekstejaesim: nullable, lista, asynkronisuus, pilvi, …F#, Cloudcomputing as a monad: http://www.m-brace.netF# Computationexpressions, aka. monads:Rajapinta: http://msdn.microsoft.com/en-us/library/dd233182.aspxToteutus: http://blogs.msdn.com/b/dsyme/archive/2007/09/22/some-details-on-f-computation-expressions-aka-monadic-or-workflow-syntax.aspxMonad rakennetaan builderilla, sisässä ohjelmoidaan normaaliin tapaan, ympärillä mymonad { … }. C#:ssa monadin sisällä ohjelmoitava LINQ:a.Dynaamisella tyypityksellä on etunsa, ja se on hyvä silloin jos rakennetaan pieniä asioita, joita ei tarvitse ylläpitää.
Domain-mallilla ohjataan ajattelua tietyille raiteille (hyvässä ja pahassa).Mikä olisi huono domain-malli?- Sellainen, jossa toiminnallisuus on väärien luokkien kyljessä.Voiko domain-malli muuttua, itsestään, ajanmyötä?Saavatko kehittäjät ja muut ihmiset kuvan muuttuvasta mallista?Rooli: Missä validointi ja business-logiikka? Miten rajoittaa domain? Mallinnetaanko sillä koko maailmaa vai vain keskeisiä ongelmia?Real-timeDomainModelwith F#: http://www.simontylercousins.net/journal/2012/5/6/nooo-nosql-real-time-domain-model.html
Perus operaatiot ovat pohjimmiltaan samat, tekniikasta riippumatta…F# MapReduceAzurella: http://msdn.microsoft.com/en-us/magazine/gg983490.aspx
Reaktiivinen ohjelmointi perustuu siihen, että tapahtumat, eventit, voidaan ajatella ikuisina laiskoina listoina.Se tekee asynkronisesta ohjelmoinnista normaalia joukko-operaatio-ohjelmointia.Helpottaa huomattavasti kun asynkronisiatapahtumia on paljon: Ei lukkoja, ei tilaa, ei luokkamuuttuja-tarkistuksia(/tupla-koodausta)-eventhandlereihin.F#:ssa tuki suoraa, mutta laajempi tuki Microsoft ReactiveExtensions kautta.Reactiveextensions, teoriassa perustuu continuationiin:http://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Brian-Beckman-and-Erik-Meijer-Inside-the-NET-Reactive-Framework-RxReactiveextensions käytännössä: http://channel9.msdn.com/Blogs/codefest/DC2010T0100-Keynote-Rx-curing-your-asynchronous-programming-bluesReactiveextensionsobservable as F# monad: https://gist.github.com/165605/ee7329952053d06d013d91059f33fe0f2ef0630fSubject on luokka, joka sisältää sekä kuuntelijan, että kuunneltavan.ReplaySubject on luokka, joka toistaa kaikki tapahtumat (myös menneet) uudelle kuuntelijalle.
CQRS & EventSourcing-malli: Erotetaan luku- ja kirjoitusoperaatiot toisistaan. - Lukuoperaatiot ovat helppoja kyselyitä ”välimuistiin” (esim. noSQL-kanta).- Kirjoitusoperaatiot tapahtuvat event-historiaan (eventstorage), joka on pääasiallinen tietovarasto- Asynkronisesti historia puretaan aikanaan ja suoritetaan itse logiikka (=Domain-modelaggregointi). Tulokset tallennetaan lukuvälimuisteihin.Tapahtumahistoria (“EventLoop”) tarjoaa ilmaisen “audit-trail”-toiminnallisuuden ja muitakin etuja.Toiminnallisuus on itse asiassa sama kuin ReactiveExtensionsReplaySubject, vaikka näkökulma on vähän eri.CQRS, Event-Sourcing on F#: https://github.com/Thorium/SimpleCQRS-Fsharp
Messagepassing on yksi vaihtoehto toteuttaa asynkronisuus ilman eksplisiittisiä lukkoja.Sanoma voidaan kuljettaa myös (asynkronisesti) itse itselle. Täten saadaan helposti aikaan rekursio ja esim. tapahtumahistoria.(Rekursion ei tarvitse näkyä ulospäin.)
Actor-malli on teoria, joka käyttää “Actor”eita rinnakkaislaskennan alkioina. Actor voi Prosessoida tietoa Varastoida tietoa Kommunikoida muiden actoreiden kanssaActorkapseloi tilansa.The Actormodel: http://channel9.msdn.com/Shows/Going+Deep/Hewitt-Meijer-and-Szyperski-The-Actor-Model-everything-you-wanted-to-know-but-were-afraid-to-ask
F#MailboxProcessor-luokka käyttää agents-mallia.Ei sisällä suoria lukkoja, vaan kaikki odottavat vuoroaan… (Jono)Vähän kuin lista omassa asynkronisessa taustasäikeessään.Suorituskyky hyvä: Asynkroniset operaatiot vastaavat heti Synkronointia vaativat operaatiot käyttökelpoisia vielä miljoonilla alkioilla (perus kannettavallakin, kunhan muisti ei lopu).Simppeli esimerkki mitä message-passingreal-time-domain-model voisi olla: http://www.fssnip.net/bP
Esimerkiksi LINQ-metodit ottavat parametriksi funktioita, joita suoritetaan tietyssä pisteessä.Tällainen piste operaatiosta toiseen, “Continuation”, on vähän kuin funktionaalinen GOTO.Se on oleellinen yhdisteltäessä toiminnallisuutta (functioncomposition).Reify (/Reification) tarkoittaa käskyä suorittaa päättelypuu. (Esim. C# sivuvaikutus Ienumerable<T> .ToList())Perus C-ohjelmointikielessä puolipistettä “;” voisi ajatella continuation-monadina; sillä on kolme vaihtoehtoa, mitä voi tapahtua: Jatketaan seuraavaan käskyyn ja välitetään parametrina koko maailma Lopetetaan suoritus Nostetaan virheOn olemassa eri tyylisiä continuationeita:Church-style (esim. Haskell), perustuu partialapplicationiin (osittainen suoritus), ja siihen, että viimeinen parametri jää pois ennen suoritustaCall-with-current-continuation “call/cc” (esim. Scheme), perutsuu siihen, että viimeisenä parametrina kuljetetaan seuraava suoritusLisää aiheesta: http://stackoverflow.com/a/10325698/17791
Jos tiedolla on skeema, niin F# 3.0 Type-Providers on mainio vaihtoehto.Aina skeemaa ei kuitenkaan ole: Skeeman rakentaminen ja tiedon konvertointi siihen voi olla työlästäVaikka dokumenttikannoilla ei ole ID-pohjaisia relaatioita, viittausmekanismi dualismi SQL-kantojen kanssa:Samat asiat voidaan tehdä: http://queue.acm.org/detail.cfm?id=1961297MapReduce on itse asiassa samat joukko-operaatiot kuin normaalistikin, tällä kertaa ne vain suoritetaan kontroloimaan hajatuettua ympäristöä.Raven DB: http://skillsmatter.com/podcast/design-architecture/building-software-ayendes-wayNoSQLRavenDB on F#: http://ravendb.net/docs/client-api/fsharpHadoop on Windows Azure: http://channel9.msdn.com/Events/windowsazure/learn/Hadoop-on-Windows-AzureGenericbasedFramework for .Net HadoopMapReduce Job Submissionhttp://blogs.msdn.com/b/carlnol/archive/2012/04/29/generic-based-framework-for-net-hadoop-mapreduce-job-submission.aspxDon Syme, F# 3.0 InformationRichProgramming: http://skillsmatter.com/podcast/scala/fsharp3