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?
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