17 Matching Annotations
  1. Sep 2022
    1. (I feel like I tweeted about this and/or saw it somewhere, but can't find the link)

      visible-web-page looks to have been published and/or written on 2022 June 26.

      I emailed Omar a few weeks earlier (on 2022 June 7) with with a link to plain.txt.htm, i.e., an assembler (for Wirth's RISC machine/.rsc object format) written as a text file that happens to also allow you to run it if you're viewing the text file in your browser.

      (The context of the email was that I'd read an @rsnous tweet(?) that "stuff for humans should be the default context, and the highly constrained stuff parsed by the computer should be an exceptional mod within that", and I recognized this as the same principle that Raskin had espoused across two pieces in ACM Queue: The Woes of IDEs and Comments Are More Important Than Code. Spurred by Omar's comments on Twitter, I sent him a link to the latter article and plain.txt.htm, and then (the next day) the former article, since I'd forgotten to include it in the original email.)

  2. Aug 2022
  3. Jul 2022
    1. 事件处理数据的变化,代码的变化呢? 我们可以将这里视为三种广泛的代码更改:新功能、缺陷修复和时序逻辑。

      Event Source的挑战,除了与非事件溯源的系统交互即外部互动(含外部更新和外部查询),还包括代码的变更本身。主要设计 时序逻辑的调整、bug fix 和 新 feat 开发

    2. 构建事件处理程序逻辑

      实现事件的记录可以通过事务处理脚本,也可以通过实体类处理。前者适用于简单的逻辑场景。

    3. Complete Rebuild:我们可以完全丢弃应用程序状态并通过在空应用程序上重新运行事件日志中的事件来重建它。 时间查询:我们可以在任何时间点确定应用程序的状态。从概念上讲,我们通过从空白状态开始并将事件重新运行到特定时间或事件来做到这一点。我们可以通过考虑多个时间线(类似于版本控制系统中的分支)来进一步实现这一点。 事件重播:如果我们发现过去的事件不正确,我们可以通过反转它和以后的事件来计算后果,然后重播新的事件和以后的事件。(或者实际上是通过丢弃应用程序状态并按顺序使用正确事件重播所有事件。)相同的技术可以处理以错误顺序接收的事件——这是与异步消息通信的系统的常见问题。

      通过对事件的记录,我们可以完全的将历史重现,也可以查询特定时间点的程序状态。历史的部分重现也可以用于debug。 典型代码就是VCS,git保留了项目开发的完整历史。

    1. i mean i have a whole speech about that

      @03:06:54:

      Blow: I mean I have a whole speech about that that I can link you to as well.

      Should that be necessary? "Links" (URLs) are just a mechanical way to follow a citation to the source. So to "link you" to it is as easy as giving it a name and then saying that name. In this case, the names are URLs. Naming things is said to be hard, but it's (probably) not as hard as advertised. It turns out that the hard part is getting people to actually do it.

  4. Jun 2022
    1. Okay, so the original source seems to be Proteus (A Journal of Ideas). ~~Specifically, vol. 3, iss. 1.~~ (Thanks to Nikos Katsikis by way of Neil Brenner for helping track this down.)

  5. Jan 2022
    1. This was great for passing things between services where fire-and-forget was adequate.

      In which cases, "fire-and-forget" is not adequate?

  6. Jul 2021
  7. Nov 2019
    1. The second type of these “Imperative Shell” services execute side-effects outside of the bounded context, such as sending an email, SMS, or mobile push notification to a user, or calling out to some other external service.

      What if the bounded context is about managing side effects — say we are implementing a transactional mail service. Should we separate the “functional core” recording mail processing events from the “imperative shell” which performs the actual SMTP?

  8. Sep 2019
    1. Independently on how the schema changes are handled, managing these changes is one of the most complex and error prone drawbacks associated with event sourcing. A strategy should be prepared upfront and considered on the system design.

      Plan for schema evolution upfront.

    2. Also your events will be based on a SomethingCreated or SomethingUpdated which has no business value at all. If the events are being designing like this then it is clear you’re not using DDD at all and you’re better of without event sourcing.

      litmus test

    1. I think you don't hear much about using Kafka for event sourcing primarily because the event sourcing terminology doesn't seem to be very prevalent in the consumer web space where Kafka is most popular.
    1. Another way to get consistency is to assure serialized writes, i.e using the single-writer principle, meaning we make sure all writes concerning a particular entity ID occur on a single thread.

      This is the akka-cluster approach?

    2. If the business logic fails we return an error to the client but if it succeeds a new event is emitted. In that case we must be able to save the new event to our event store with a guarantee that no other event has been stored for this particular entity ID in the meantime, or we would risk breaking the consistency of our domain objects.
    3. One alternative would be to have one topic per entity

      Other alternative: have a consumer group write a read model to a database, indexed by entity id.

  9. Jun 2016
    1. A Crowd-authoring Project on theScholarship of Educational Technology

      Lily, Abdulrahman Essa Al. 2015. “A Crowd-Authoring Project on the Scholarship of Educational Technology.” Information Development, December, 266666915622044. doi:10.1177/0266666915622044.