December 2012 - Pharo-users

Re: [Pharo-users] CQRS and Event Sourcing in Smalltalk

by Norbert Hartl

Am 13.12.2012 um 20:36 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > On 13 Dec 2012, at 17:56, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Am 13.12.2012 um 17:27 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >>>> Hi all, >>>> >>>> Please, anyone knows a Pharo framework to implement CQRS and/or Event Sourcing? >>> >>> I read in diagonal the paper of martin fowler and I would say just some command patterns? >>> + some meta modeling? >>> no? >> >> Well, you can give that particular answer to _a lot_ of problems :) I think the important part is the "event store" and how you snapshot state. So it is more or less a persistence question. Staying in-image it is rather easy. I use an approach where I still have the business objects holding state. But state is altered through commands and every command emits a set of events that get written to a timeline. The objects analyzing the timeline are more CQRS like because the state evolves out of the timeline. So I have an >> >> Event class with instVar time (aDateAndTime) >> A timeline is a sorted collection (by time) of events. >> An object has a stream on the timeline. Its position is the positional information about the snapshot state. >> Snapshot state is updated by following the stream (next: 100, upToDate: â¦ upToEventType:â¦) >> >> Altogether you have sources that put events on the timeline. Separated from that you have the consumer that reads the snapshot state and updates it. >> >> Norbert > > Sounds really cool and exciting, Norbert. > I think many people including myself are thinking along those lines. > Next time we meet you'll have to show me ;-) > Sure :) I think this approach has some benefits. Normal objects can be seen as the only and most actual snapshot of a state changing history. The history gets discarded immediately. But this history has a great value in itself being able to replay/undo things or develop new values that can be applied at a later moment. We just need to look at the debugger. A stack or context chain is just a collection of moments in time. If you go up the stack we go back in time. But objects stay in the now. It would just be perfect if the object state would go back in time as well. Let's take a networked service as an example. If we look more closely we can see a snapshot of data is about actuality and consistency. We always like to have consistent data. But actuality is ambiguous in a concurrent media with non-deterministic latencies like the internet. If we separate these we find the need to have data that is consistent at any point in time. But reading the data does not have to return the newest state available. So we divide the process into three things: adding state change, updating state snapshot, reading state snapshot. The adding is an append-only operation that can be done in a very fast way by the persistence and has less issues when it comes to concurrency. Updating the state snapshot from the state change events can be done according to the needs for actuality or performance. Just to make it clear: In this approach there is also just one entity that is updating the state, so more concurrency problems solved. Finally reading the state can be done in multiple ways. Either you read the provided snapshot or you update the snapshot to the newest value in your private copy of a state holder. This time again you are not changing something concurrent. A more real life example is one of our products. I changed to model to emit events 6 month ago. Well, using GemStone I didn't have to think about persistence. It is just a persisted collection with a few million events in it. 3 month _after_ I started to collect events I started to think about what data I actually need to show on the web UI. Having all the history in my hand I can derive plenty of different values just afterwards. Every value has a stream on the events collection. So every value has its own cursor in history. New values just start at the beginning of the collection and catch to now. Old ones have just little to update. I hope this is useful somehow, Norbert

Dec. 14, 2012

Re: [Pharo-users] CQRS and Event Sourcing in Smalltalk

by Sven Van Caekenberghe

On 13 Dec 2012, at 17:56, Norbert Hartl <norbert(a)hartl.name> wrote: > Am 13.12.2012 um 17:27 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >>> Hi all, >>> >>> Please, anyone knows a Pharo framework to implement CQRS and/or Event Sourcing? >> >> I read in diagonal the paper of martin fowler and I would say just some command patterns? >> + some meta modeling? >> no? > > Well, you can give that particular answer to _a lot_ of problems :) I think the important part is the "event store" and how you snapshot state. So it is more or less a persistence question. Staying in-image it is rather easy. I use an approach where I still have the business objects holding state. But state is altered through commands and every command emits a set of events that get written to a timeline. The objects analyzing the timeline are more CQRS like because the state evolves out of the timeline. So I have an > > Event class with instVar time (aDateAndTime) > A timeline is a sorted collection (by time) of events. > An object has a stream on the timeline. Its position is the positional information about the snapshot state. > Snapshot state is updated by following the stream (next: 100, upToDate: â¦ upToEventType:â¦) > > Altogether you have sources that put events on the timeline. Separated from that you have the consumer that reads the snapshot state and updates it. > > Norbert Sounds really cool and exciting, Norbert. I think many people including myself are thinking along those lines. Next time we meet you'll have to show me ;-) Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 13, 2012

Re: [Pharo-users] CQRS and Event Sourcing in Smalltalk

by StÃ©phane Ducasse

>>> Please, anyone knows a Pharo framework to implement CQRS and/or Event Sourcing? >> >> I read in diagonal the paper of martin fowler and I would say just some command patterns? >> + some meta modeling? >> no? > > Well, you can give that particular answer to _a lot_ of problems :) yes the article was not really clear. > I think the important part is the "event store" and how you snapshot state. So it is more or less a persistence question. Staying in-image it is rather easy. I use an approach where I still have the business objects holding state. But state is altered through commands and every command emits a set of events that get written to a timeline. The objects analyzing the timeline are more CQRS like because the state evolves out of the timeline. So I have an > > Event class with instVar time (aDateAndTime) > A timeline is a sorted collection (by time) of events. > An object has a stream on the timeline. Its position is the positional information about the snapshot state. > Snapshot state is updated by following the stream (next: 100, upToDate: â¦ upToEventType:â¦) > > Altogether you have sources that put events on the timeline. Separated from that you have the consumer that reads the snapshot state and updates it. > > Norbert

Dec. 13, 2012

Re: [Pharo-users] CQRS and Event Sourcing in Smalltalk

by Norbert Hartl

Am 13.12.2012 um 17:27 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> >> Hi all, >> >> Please, anyone knows a Pharo framework to implement CQRS and/or Event Sourcing? > > I read in diagonal the paper of martin fowler and I would say just some command patterns? > + some meta modeling? > no? Well, you can give that particular answer to _a lot_ of problems :) I think the important part is the "event store" and how you snapshot state. So it is more or less a persistence question. Staying in-image it is rather easy. I use an approach where I still have the business objects holding state. But state is altered through commands and every command emits a set of events that get written to a timeline. The objects analyzing the timeline are more CQRS like because the state evolves out of the timeline. So I have an Event class with instVar time (aDateAndTime) A timeline is a sorted collection (by time) of events. An object has a stream on the timeline. Its position is the positional information about the snapshot state. Snapshot state is updated by following the stream (next: 100, upToDate: â¦ upToEventType:â¦) Altogether you have sources that put events on the timeline. Separated from that you have the consumer that reads the snapshot state and updates it. Norbert

Dec. 13, 2012

Re: [Pharo-users] Nautilus class methods button feedback. + show method comment on hover.

by StÃ©phane Ducasse

On Dec 13, 2012, at 8:46 AM, Peter H. Meadows wrote: > 1) When browsing code in nautilus how do you know if a class has class methods? > > Sometimes I forget to look for them because many classes don't have > any. Could the button be changed to give visual feedback when a class > has class methods? Maybe tell the user the number of methods? > > The comment button could do the same, although we already have the red > exclamation mark to show classes without comments (which is a great > way of encouraging people to comment their classes). > > 2) Something that would make a big difference to me is showing the > method comment when you hover the pointer over a method. Then I > wouldn't have to give methods super long names, because I could put > details in the comment and get at them quickly. A fly by help to see comments would be really cool.

Dec. 13, 2012

Re: [Pharo-users] CQRS and Event Sourcing in Smalltalk

by StÃ©phane Ducasse

> > Hi all, > > Please, anyone knows a Pharo framework to implement CQRS and/or Event Sourcing? I read in diagonal the paper of martin fowler and I would say just some command patterns? + some meta modeling? no? > > Thank you! > > Rafael Luque

Dec. 13, 2012

CQRS and Event Sourcing in Smalltalk

by Rafael Luque

Hi all, Please, anyone knows a Pharo framework to implement CQRS and/or Event Sourcing? Thank you! Rafael Luque

Dec. 13, 2012

Re: [Pharo-users] Book recommendations

by Bernat Romagosa

Smalltalk with Style is one of my favourites! I've read it three times and keep coming back to it for advice every now and then :) 2012/12/13 dimitris chloupis <thekilon(a)yahoo.co.uk> > thats good to hear , I ordered it together with "Pharo by Example" and > "The Supercollider Book". They will be arriving here on Monday. "Smalltalk > Practice Patterns" was the only one I had doubts about so its good to know > that you liked it. And thanks for that link. > > ------------------------------ > *From:* Davorin Rusevljan <davorin.rusevljan(a)gmail.com> > *To:* A friendly place where any question about pharo is welcome < > pharo-users(a)lists.gforge.inria.fr> > *Sent:* Thursday, 13 December 2012, 12:04 > *Subject:* Re: [Pharo-users] Book recommendations > > > On Thu, Dec 13, 2012 at 7:22 AM, Peter H. Meadows < > peter.h.meadows(a)googlemail.com> wrote: > > There is some good stuff at http://stephane.ducasse.free.fr/FreeBooks.html > > > What else? Is 'Smalltalk Best Practice Patterns' by Kent Beck still > relevant to pharo? > > > For me it is one of the best Smalltalk books. > > Also, one of my favorite oldies is late David N Smith Smalltalk FAQ. > Obviously there is some information which is way out of date, but I really > like his style. > > http://udos.users.dolphinmap.net/archive/DavesSmalltalkFAQ.pdf > > > > > > > > > -- Bernat Romagosa.

Dec. 13, 2012

Re: [Pharo-users] Book recommendations

by dimitris chloupis

thats good to hear , I ordered it together with "Pharo by Example" and "The Supercollider Book". They will be arriving here on Monday. "Smalltalk Practice Patterns" was the only one I had doubts about so its good to know that you liked it. And thanks for that link. ________________________________ From: Davorin Rusevljan <davorin.rusevljan(a)gmail.com> To: A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr> Sent: Thursday, 13 December 2012, 12:04 Subject: Re: [Pharo-users] Book recommendations On Thu, Dec 13, 2012 at 7:22 AM, Peter H. Meadows <peter.h.meadows(a)googlemail.com> wrote: There is some good stuff at http://stephane.ducasse.free.fr/FreeBooks.html > > >What else? Is 'Smalltalk Best Practice Patterns' by Kent Beck still >relevant to pharo? > For me it is one of the best Smalltalk books. Also, one of my favorite oldies is late David N Smith Smalltalk FAQ. Obviously there is some information which is way out of date, but I really like his style. http://udos.users.dolphinmap.net/archive/DavesSmalltalkFAQ.pdf

Dec. 13, 2012

Re: [Pharo-users] Book recommendations

by Davorin Rusevljan

On Thu, Dec 13, 2012 at 7:22 AM, Peter H. Meadows < peter.h.meadows(a)googlemail.com> wrote: > There is some good stuff at http://stephane.ducasse.free.fr/FreeBooks.html > > > What else? Is 'Smalltalk Best Practice Patterns' by Kent Beck still > relevant to pharo? > For me it is one of the best Smalltalk books. Also, one of my favorite oldies is late David N Smith Smalltalk FAQ. Obviously there is some information which is way out of date, but I really like his style. http://udos.users.dolphinmap.net/archive/DavesSmalltalkFAQ.pdf

Dec. 13, 2012