Just purely from a sales perspective, I’d strongly advise you to update it to 1.3. People are going to look at the book, see that Phoenix 1.3 is out and then see the book covers 1.2…and that will make them hesitate. You’re going to have a much longer sales cycle for this one if it gets updated for 1.3.
12 Likes
@lance sure, I understand 
Maybe you could put some hints in a paragraph covering storage possibilities.
Anyhow, keep up the good work! thanks again! 
2 Likes
+1 for expanding into persistence.
2 Likes
I couldn’t agree more!
2 Likes
Nice book, already started the journey, its cool that you just start diving in into the business logic, but I really miss Tests. After the first Module (Coordinates) it would be better to just start with tests. It would actually save much more time, because you don’t need to go to the console and test it manually.
3 Likes
This book does not teach Phoenix, however. You probably should have some knowledge of it when starting reading it.
3 Likes
25% off, got lured in. But I bet it’s the best 16 dollars I’ve spent in a while 
3 Likes
Bought it too some days ago, can’t wait for you @lance to finish it! Learned a lot through your lessons so far!
Thanks a lot!
2 Likes
Great to hear that you’re enjoying the book. Thanks for the feedback!
is this book suitable for beginners and step by step type of flow? or more like tips and tricks?
Define beginners. This book won’t teach you “Elixir the language” nor “Phoenix the framework”. You must have some prior knowledge .
It creates a game as a means of explaining Agents, GenServers, Supervisors, Finite state machines and the structure of an Elixir application. It does a pretty good job at this. Unfortunately the Supervisors and FSM chapters are not ready yet. Then it combines the game, as a library, in a Phoenix app.
It goes step by step all the way.
1 Like
i see, so once i know elixir and phoenix, this book will be the next step… should I also know OTP and Erlang before this book?
How come this book doesn’t cover elixir 1.4 and phoenix 1.3?
Definitely you don’t need to know Erlang to follow this book. I don’t know Erlang and I had no problem at all following the book. After all it is an elixir book 
.
You also don’t need to know OTP. This is one of the things this book will teach you.
How come this book doesn’t cover elixir 1.4 and phoenix 1.3?
The book is still in beta. Who knows in what ways the author will change it until the final release.
1 Like
Thanks 
Thanks for your interest in the book!
I think that if you feel pretty comfortable in Elixir, you’ll be fine. As @voger said, we’ll walk you through all the steps, and you’ll learn a good chunk of OTP along the way. The main element of Phoenix that we work with is a channel, and we’ll build that step by step as well.
When the next beta is released, all the code will work with Elixir 1.4. As things currently stand, for the context of this book, the only thing that will change for Phoenix 1.3 is the pathname to the channel we’ll build and the output of the “tree” command inside a newly generated project. We’ll definitely update those things in an upcoming beta release.
1 Like
I grabbed the book and had a (virtual) leaf through, and I would have two main comments:
First, perhaps I didn’t read the book page properly, but I had the impression going in that this was going to be much more advanced than it was. The PragProg page shows the skill level as “intermediate to expert”, and while I agree that it is not a beginner book, I would not call it expert-level either. By “have previous experience with Phoenix and Elixir” I took “have built complete, if maybe simple, applications with them” rather than “know how the syntax works and how a Phoenix interface is structured”. I think clarifying exactly the target audience of the book may be beneficial.
Second, I take issue with the way that the entire game state is represented in a bunch of processes referring to each other by holding PIDs. I think the best way to say what I mean is to simply refer to this great article by Saša Jurić. The way this is implemented in the book smells really strongly of trying to make Agents behave like objects, which is a common mistake for those moving over from OOP, but should in fact be explicitly called out in a book like this, instead of impliedly encouraged.
I think at a certain point you mentioned that “trying to store the whole game state in a functional tree structure is a recipe for bugs because coordinates can belong to both islands and board and we’d have to update them in both places”. The answer to that problem is to normalise the way you’re storing the coordinate data, so you’re only storing it once. It’s certainly not to make each little piece of your state be a separate process!
As has been discussed many times over on this forum, separate processes should be used when a separate concern, either separate in time or separate in failure domain, is present.
Further, what happens when these processes die? They are all linked it seems, so one failure will take down the entire system. If you insist on using them to model the state, perhaps it is at least an opportune time to put them into a custom Supervisor and use Registry to register them with the coordinate/board they represent?
I’m sure it is not the intention of the book to do so, but while I applaud the decoupled, “Phoenix is not your app” approach, I feel it either itself falls or encourages people to fall into common traps when structuring Elixir apps and modelling their domains therein.
I don’t mean to be too negative—I think the concept of the book is great, and a practical walkthrough of how to build something fun but useful is a great way to convey the concepts, but I also think it’s crucial that the approaches set by the book are 100% defensible (to avoid saying “right”) and push people towards actually using the great many tools Elixir gives us in the way they were designed to be used.
16 Likes
Good points! I too think it’s much more advanced than I thought, but so far, so good.
One thing that worried me a bit is the absence of tests, on development cyrcle… but I’m sure the author’s purpose was to be more practical. So, the dev should have a good base before reading the book.
As I said, good points of view!
2 Likes
Absolutely this! I see this being done wrong in so many places (not just Elixir) in regards to functional design. Normalize the data so if coords need to be shared then have them share an ‘id’ to a coord in some coord storing table. I find data-flow and/or (pure) ECS designs fantastic for this (I use these both in C++ heavily). But they definitely should not be stored in different processes! That is an entirely wrong abstraction here.
Plus everything else @mjadczak said. 
2 Likes
This is a very good post. This is why I love the Elixir community.
Lance and I are working with some great reviewers to make sure we address this feedback. We’re going to shift the approach for the two chapters in question, the chapter on modeling and the chapter on wrapping the result in OTP.
As a popular book in the community, we want to make sure that the guidance we give is sound.
Thanks again for a great post.
20 Likes
I’d love to learn more about using OTP for the business logic in our web apps, but skipping over persistence makes this kind of pointless. Does it at least describe how to hook into the OTP processes to save their state somewhere?
3 Likes
