I have read the initial pages of the book and I am amazed with it until now 
The books seems to start with Phoenix 1.3.* and Elixir 1.5.*, and my question is if this are still the versions being used in the current stage of the book?
There was a pull request merged into the Conduit repo which upgraded dependencies, such as Phoenix to v1.4.
The way I’ve authored the book is to include a link to a GitHub commit at the end of each section which contains the changes being introduced and discussed. This hopefully means following along to changes is straightforward for the reader. Unfortunately the downside of this approach for authoring is that I need to rebase git history to apply changes such as upgrading dependencies since this will affect commits from almost the beginning of the project’s history. Doing so then involves many hours spent resolving merge conflicts! Luckily the code examples included in the book are pulled from the git repository so I can safely rewrite history and quickly update the snippets included in the book.
My current plan is to finish writing the chapters to sync the book’s content with the sample repo and then deal with backporting any upgrades.
2 Likes
While you can guarantee the book is up to date with the git repo, you cannot guarantee that the book instructions to run commands will yield the same results, because the versions are not the same. For example running mix phx.new will end up with different folder structures, depending on the version of Phoenix being used, and the same will be true for other commands.
So I would prefer that you would lock the book to the exact versions of Elixir and Phoenix to be used, so that we can always reproduce the book at anytime in the future by using the same exact versions you used while writing the book. Also the versions for dependencies should be defined without wildcards to try to give the same guarantees of reproducibility.
Another important version to lock is the one being used in Postgres.
Ensuring dependency versions match the source in the GitHub repository is what I was referring to when I mentioned the time needed to be spent rebasing and resolving merge conflicts. When I back port the upgrade to Phoenix v1.4 I will start from the first commit where the Phoenix folder structure is created and work forward. I’ve already done this for the upgrade from Phoenix v1.2 to v1.3 which was a major rework of the structure.
Locking the version of dependencies is a good point to make so that the code can be reproduced in the future.
1 Like
It really sounds like a huge work, but I think that having Elixir and Phoenix versions up to date when you release the book will be good for the sales
Yes, I really think that locking them is important, and you should have them visible in the README of the git repo and also make them very visible in the book introduction. Another good idea would be to release a docker image for the book, where you could easily pin the versions being used. I can help you here 
Afterwards when a major shift happens in the Elixir or Phoenix way of doing things you may consider to do another release of the book to reflect them, but we the readers will always know what exact versions to use in order to reproduce what is in the book
I am reading the book and the source code and it is a great example/entrypoint for CQRS/ES. I want just to say thank you @slashdotdash for sharing this great job (I have bought the book to support it, I think it is really valuable).
4 Likes
I am wondering if the book is stale at this moment, because last update was in 24 May 2019… Any plans to resume it @slashdotdash?
4 Likes
I’m wondering the same thing. @slashdotdash, is this still being worked on?
3 Likes
Despite the book being out-of-date, it is still extremely useful for learning how to use Commanded. I’m working my way through it and trying to get it to work with the latest versions of Elixir and Phoenix.
Useful resources for getting the book code working:
- ElixirConf Warsaw 2021 talk
- Example code from the talk
- Git pull of Conduit repository upgrade to 1.0
The example code from the ElixirConf talk doesn’t include tests so you can’t pull related ideas from that. (The one issue I’m having right now is automatically resetting the test database between tests.)
If anyone has found an open-source repo of an application that uses a recent version of Commanded with working tests, do share since that may help me and others working through the book.
Might make sense to have a book club forum on this title for readers to support each other…
2 Likes
And looks like I may have answered my own question with this resource!
2 Likes
