Fork me on GitHub

godspeed you black emperor

❤️ 8

(map make-poetry-line (take 5 (drop 3 (range))))

Lennart Buit07:08:28

If I really want to code something out, I need repetitive high paced music like pendulum. That - for me - has a chance to get me in that ‘flow’ state 🙂


I listen to Retrowave / Synthwave / Outrun for that reason 🙂


Try Squarepusher for the “flow”.


It usually makes me feel small, with a sensation of a considerable weight put on my chest, and as if enclosed in an invisible container just looking at my screen with small POV and the sides of what I’m seeing blurred.

Lennart Buit08:08:46

that sounds like a … terrible sensation :’)


Groove salad from

👍 4
Carmine Casciato12:08:23

Yacht Music playlist on Spotify


Comes with some science attached to it


there was a website making fun of java annotations with made up examples does anyone has a link?


For traditional CQRS+event-sourcing, commands are sent from client to server before any events + state-creation occurs. I'd like to change this a little -- allow immediate processing of certain commands on the client to generate local events & state, then synchronize these with the backend at a later time. I suspect this will require a rewinding+replay capability to handle conflicts. Could anyone recommend any resources that cover this topic?


Is it only certain types of commands or does it depend on the client which one? Like you have doFoo and want it on the client only on certain conditions, but you do eventually want all the FooResult on the server?


Only certain types of commands. For instance, I don't want clients to be able to execute create-user command without backend validation, but I do want them to be able to execute a create-todo. I'd like the client apps to immediately accept some commands, then generate events, then generate the corresponding local state (such as a datastructure for a TODO item). I want this to apply the original command on the backend once received, then if the backend generates a different event (e.g. conflict), the client to be able to rewind related events & replay them -- possibly asking for user input if the conflict can't be programmatically resolved.


^ I'm still clarifying this in my head, but it's roughly the flow that should happen... the CQRS+event sourcing resources I can find all assume you'll ship commands to the backend before clients receive state, but this would result in a poor client experience in the case of a mobile app. So I want to be able to "cheat" with a CQRS+ES equivalent of "optimistic updates"


If you just have all the added-todo events send to the back end it would be fine right, with some id to prevent duplication. I also struggle with 'proper' CQRS but it seems more complicated than needed for a lot of things. In the case of todo's it might even make more sense to send complete todosUpdated events to the server.


Sending the event may be the way to go -- not sure if sending the command is necessary other than just persisting it for the historical record. I'll keep working at it -- pretty sure I can tease out the right flow once I start adding tests & find which scenarios break


As an aside, I've seen a few sources claim full system CQRS+ES is an anti-pattern... I'm not convinced yet, but I'm convinced to find out 😉 IMO there's some interesting capabilities to be discovered here, especially as the command+event code is being shared between frontends & backends.


In I didn't let the commands get all the way to the frontend. But the GraphQL it uses is driven by commands + events. Might give some inspiration.


This is an excellent resource to parse through -- it'll take me a while, but thank you. I'm interested in exactly how the Heartbeat, Synchronizer, & Command handler is used in this setup... the system I'm building has an Onyx runtime to process commands from Kafka & a Datomic instance to power the frontends, so different pieces trying to achieve a similar effect


a Monger related question: i'm trying to insert-many with ordered option set to false. insert-many does not seem to accept any option other than WriteConcern although mongo supports it.


how do I get around this?!


@veix.q5 I don't see an insert-many in the latest version of Monger's source -- which namespace is that in, or do you mean insert-batch?


I'm not seeing much in the MongoDB Java API that relates to ordered/unordered, except for the builders for the BulkWriteOperation type? I don't see anything in Monger that deals with that. So I think you'll be doing some Java interop at this point...