I'm a Ruby developer from Westchester, New York. I'm interested in web application and internal infrastructure development. Mostly I like to build simple things that work really well.
#CuriousWanderer
#InveterateLearner
#Father
#Entrepreneur
#WebDeveloper
#SkidmoreGrad
#BootcampGrad
#FormerlyIncarcerated
| Writings | https://rossney.net |
| Gitlab | https://gitlab.com/dcr8898 |
| Github | https://github.com/dcr8898 |
#Ruby perf question: What's the fastest way to iterate over segments in an HTTP route? (ex. "/users/:id/postst/:post_id")
I currently .split on "/" and call .each on the array. I thought I could avoid creating an array and perhaps gain speed by "consuming" the string directly. I tried three ways.
* Split a segment at a time.
* Use pointers to index over the string.
* Use String Scanner (regex).
The array is always faster. 🤔
Please boost to reach any big brains too busy to follow me. 😉
@ismasan Finally, the logic for compiling the current state of the object lives in a completely different object: a projection.
The projection receives the history of events from the stream, and knows what account entity methods to call to apply each event.
This all feels weird to me because it feels like the business rules surrounding the account concept in this example are divided among three different objects: a handler, the entity, and the projection.
5/🧵
@ismasan In XState, you define your state machine as a JSON object. This may seem tedious, but the object is easily translated to a diagram--and back to an object. It's even possible to edit the diagram to change the code.
This seems valuable in creating a shared mental model of the state machine, and in evaluating its correctness.
I thought maybe Eventide would justify this approach by treating the account entity as a pure data object, but it contains behavior as well (see `withdraw`).
4/🧵
@ismasan I've been re-reading the Eventide docs (for at least the third time). I came back to this simplified example from the introduction page. http://docs.eventide-project.org/
I wanted to look at it again from the Decide-Evolve-React perspective. The method doesn't have the precise function signature of Decide (command, state) -> event(s).
It does accept a command (with account_id and amount data elements). But it then uses the account_id to obtain the current state from an account "store."
1/🧵
@ismasan In XState, you define your state machine as a JSON object. This may seem tedious, but the object is easily translated to a diagram--and back to an object. It's even possible to edit the diagram to change the code.
This seems valuable in creating a shared mental model of the state machine, and in evaluating its correctness.
I thought maybe Eventide would justify this approach by treating the account entity as a pure data object, but it contains behavior as well (see `withdraw`).
4/🧵
@ismasan Finally, the logic for compiling the current state of the object lives in a completely different object: a projection.
The projection receives the history of events from the stream, and knows what account entity methods to call to apply each event.
This all feels weird to me because it feels like the business rules surrounding the account concept in this example are divided among three different objects: a handler, the entity, and the projection.
5/🧵
* The handler knows (piecemeal) when to change state.
* The entity contains methods that mutate its state.
* The projection is a translation layer that knows what entity methods to call, with what parameters, based on the events it receives.
I had envisioned the entity as a stateful, immutable object that would be instantiated with its current attributes, including state. This object could respond to a given command, including arguments, and reply with the appropriate event(s).
6/🧵
@ismasan Likewise, if an instance of the same object is asked to *apply* an event (including arguments), it would respond with a new instance of itself in the appropriate state, with update attributes.
No one seems to be thinking along those lines, but making sense of three separate business objects is a lot to absorb for me.
I will keep reading . . . 🧐
fin 🧵.
@ismasan Thanks again for taking the time to read and respond! 🤓 I will read the sources you gave to understand more.
My concern with this fragmented approach is that it will be more difficult to form and hold a mental model of the life cycle of these concepts in an app.
Being able to convert a state machine to a state chart and back is a huge help in this regard. How will anything like that be possible with such fragmented parts?
@ismasan Me neither, but I'm starting to come around to the event-first view. Taking a good look at Sequent now . . .
Thanks again!
ismasan