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/🧵