I still got a lot out of the book, but I agree with you. Showing how to store the state and regenerate it is the missing piece.
Iād like to suggest that this desired chapter on persistence might be better for another and fairly different book. I disagree that itās pointless to cover this stuff without covering persistence. There is plenty to cover in what it is doing and to do a decent job on the various persistence options and their tradeoffs well could double the books size and dilute itās focus.
This book has a good clear focus. Using purely functional modules instead of agents as suggested in SaÅ”a JuriÄās article poses a really nice counter to the style in this book and it would seem important to try and flesh out the pros and cons of each in some way if possible, but SaÅ”aās own Blackjack example would clearly need revision once other very simple elements were added as he noted himself.
I think some fleshing out of this space in between these two options would be valuable, but I think somebody else should be left the fertile ground of persistence for a different book.
I think the goal of the book is to show programmers a new type of web development available to them. However, very few people could make use of that without understanding how persistence plays into the design. It doesnāt need to be complex.
Iām pretty confident that youāll want to be closer to SaÅ”aās style. The processes-for-everything style presented in early versions of the book creates a big spanning tree of mutable data with the added problem of being overly complex. You lose too many advantages of functional programming that way.
I expect the book will improve on both of these fronts.
Well it may not need to be complex. But it may need to be written. I promise to look at this application in detail. Iām excited for the link, but itās not a book. Maybe it should be? I see the focus of this book as a concrete example of how you can separate your state from your framework and as more of an example of an option than a formula for how you should do stuff.
The thing is that I think that this book explains an idea well, and it seems that a bunch of folk who have deep experience want it to explain their better and more refined practices, which Iād love to hear about, but you canāt talk about a camel without having that strange creature in front of you to draw reference to.
One of the things I like about Elixir is that it takes a very āfirst do no harmā approach to things and I understand that you guys are following that, but it takes the camel and it takes the words and Iām thankfull for this camel and these words.
Incidentally watching the presentation now. Really appreciate it.
I bought the book and I can honestly recommend it (even though itās not even finished, yet). There is one bitter pill for me, though, and thatās the amount of redundancy in the authorās manner of writing (āchaining/adding/composing togetherā, for example, where the ātogetherā is entirely superfluous, and he sometimes manages to even use double redundancies, which always makes me cringe a bit).
Yes, itās nothing serious, itās just that excessive redundancy in language is a major pet peeve on mine, all the more when itās coming from a (really good) programmer, who should give examples in keeping it DRY in the first place.
Redundancies aside, the book is excellent and really explains important concepts, instead of just hinting at them and then doing things that have been done, talked about and explained a hundred times. The application is fun to build and the beautiful decoupling is also something that doesnāt have enough space in currently available Books and Tutorials about Elixir, OTP and Phoenix.
Give it a try!
Purchased and used the ElixirForum coupon code, canāt wait to get time to read it!!
Wow - this is just above and beyond. Drastic āmid-voyage course correctionā despite the consequences, dedication to a quality product, you have to respect that!
So - donāt bother with any more errata?
Sometimes, beta happens. We just got some great technical feedback from people we trust in the Elixir community. Since the book is so far along, the feedback was especially painful, but we have decided to incorporate it before we go forward with the rest of the book. We chose to use Agents as a way to approach OTP, but we overused them. Unfortunately, that sent the wrong message about good application design in Elixir, and we sincerely apologize for that. The next beta will put functional principles front and center. Weāll use separate processes only when the design calls for them, and weāll stick to plain modules and functions when it doesnāt. So youāre getting a better book. The downside is that it will take some time. You wonāt see the next beta version until approximately mid-May. Know that we have your best interests in mind. As one of the more popular Elixir books right now, we want our guidance to be rock solid, so weāre enlisting some great talent in our review process to improve the book. Since itās delaying our betas, we wanted you to know.
Thanks for your readership and your patience.
I already had amazing respect for the Prags as publishers and this just reinforces it. Additionally, @lance, this canāt be easy on you personally, and I appreciate your devotion to the book. For what itās worth, if I can help, let me know.
Thanks so much for your support @peerreynders!
Iāll be honest, rewriting chapters is no fun, but what would be worse is releasing a book that isnāt the absolute best it can be.
For your errata question, if you have any for chapters 6 and 7, send them along. I would say itās probably better to hold off on any for the other chapters for now.
Thank you so much @gregvaughn! I appreciate your support. Iāll let you know if thereās anything you can do. <3
@lance, howās the beta update going? I have to say I deeply admire the way youāve handled feedback from the forum. I canāt wait to dive in to your next release!
Thank you so much @jeramyRR!
A brand new Chapter 2 is in the editorial/review process, so the best estimate that I can give you is āsoonā. But it is coming, and I think itās going to be worth the wait.
@lance: Just a thought --> It might be really interesting to save the old version of the game at that point in the book (the one youāre currently rewriting to be different), to be able to compare it with the new one. For me, many good insights come from looking at āThis is one way we could do X, here are the pros/consā, and āThis is the idiomatic (IMO) way to approach doing X, it has these pros/consā. I donāt know whether that fits into the structure of the book, but if not directly in there, then maybe as an errata / some way to be able to compare the code of both approaches at the same point?
Thanks @alathon!
Yes, I have a plan for this. Itās unlikely that Iāll tackle this kind of comparison/contrast of the two approaches in the book itself, but I think it would make a good blog post or two once the book is done.
Just got an email saying the new Chapter 2 is ready!
beta 3 has been released
Iāve been following the examples in the book, and for the most part implementing the code in my own github repo. I just implemented the redone chapter 2 (with tests as well!)
I originally did the first three chapters before it was announced chapter 2 would be redone. When chapters 3 and 4 are redone, I intend to implement those as well.
I have learned a lot about OTP and good elixir development from this book so far. Having done the chapter 2 exercises before and after beta, I want to say the updated exercises better reflect the business logic of the application.
Thanks @lance - loving the book so far!
I also think it would be great covering how to persist data to a DB, and how to unload processes from memory when theyāre idle. I guess that in a real-world application we canāt have everything into memory at once.
b4 is out now