80 Matching Annotations
  1. Dec 2022
  2. Oct 2022
  3. Sep 2022
  4. Aug 2022
    1. Links are bi-directional. If you link two processes and one of them crashes, the other side will crash too (unless it is trapping exits). A monitor is uni-directional: only the monitoring process will receive notifications about the monitored one. In other words: use links when you want linked crashes, and monitors when you just want to be informed of crashes, exits, and so on.

      link 是双向的,如果你 link 两个进程,一个进程 crash 会导致另一个进程也 crash(除非它阻止退出?)。monitor 是单项的,只有正在监听的进程会收到被监听进程的消息。换句话说,当你希望绑定 crashed 关系,使用 link。 当你希望收到crash,exit 等消息时,使用 monitor

  5. Jul 2022
  6. Jun 2022
  7. May 2022
  8. Feb 2022
  9. Jan 2022
  10. Nov 2021
  11. Aug 2021
  12. Jun 2021
  13. May 2021
  14. Feb 2021
  15. Dec 2020
  16. Oct 2020
  17. Jul 2020
  18. Jun 2020
  19. May 2020
  20. Mar 2020
  21. Jan 2020
  22. Nov 2019
  23. Jul 2019
  24. Jun 2019
  25. Dec 2018
  26. Nov 2018
  27. Oct 2018
  28. Sep 2018
    1. This is a transcript of a talk given at ElixirDaze and CodeBEAMSF conferences in March of 2018, dealing with supervision trees and with the unexpected.
  29. Dec 2017
  30. Aug 2017
  31. Apr 2017
    1. The choice between maps, structs, and keyword lists, or between string keys and atom keys, is not always clear, and improper decisions can lead to headaches. This article promotes simple guidelines to keep the Elixir programmer out of trouble: Use string-keyed maps for data which has just arrived from an external source. Convert external data to structs as soon as possible. Use ExConstructor or something similar to abstract away the handling of string-keyed maps. Use structs almost everywhere else in your program. Use other atom-keyed maps sparingly. Use keyword lists only to provide arguments to a function. These rules of thumb have improved the quality of our code here at Appcues, and we hope they can help you out too.
  32. Mar 2017
  33. Feb 2017
    1. Just reading an interesting document wherein elixir takes an important placehttp://arxiv.org/pdf/1601.05976.pdf49 . BPM (business process management), for those who never heard of it, is a sort of Model Driven Development; in BPM you model a workflow / process mostly visual and use this model for execution. So the process that was hidden in your code becomes visible and maintainable for business specialists (I mean specialists that do not code). It can be used together with other MDD parts like BRM (business rules management). Here the rules are extracted out of the code. Even the screen / form builder where you visually compose your forms is a form of MDD. You can choose to create executable models (for example an xml or json that can be interpreted by your code), generate code based on your model or choose a mix. I prefer executable models. Here a company that did a lot of research which names key advantages: https://www.mendix.com/blog/the-power-of-mendix/30 .
    1. In this paper, we propose to rethink the dominantlogic of how to model business processes. We think that an actorbased approach supports in a much better way the fundamentalnature of business processes. We present a proposal for a compilerarchitecture to model and execute business processes as a setof communicating microservices that are hosted on a generalpurpose virtual machine for distributed execution.