Don’t forget you can get 35% off the ebook with your forum discount, use code ‘devtalk.com’
Available in beta now
Don’t forget you can get 35% off the ebook with your forum discount, use code ‘devtalk.com’
Available in beta now
https://twitter.com/redrapids/status/1117082473194766336
https://twitter.com/redrapids/status/1117082474545385472
https://twitter.com/redrapids/status/1117082475426131968
https://twitter.com/redrapids/status/1117082476315324418
Can’t wait! Congrats @JEG2
And I completely agree with the change of name - I think it reflects the difference between working with Elixir and other languages too; in Elixir you much more feel like you are designing a system or are a system architect. I feel more like a software engineer when thinking about working with Elixir and Phoenix, whereas with Rails I always felt like a Rails user (not even a Rails developer).
This sounds awesome.
Will be waiting for this.
The only other book so far is The Little Elixir & OTP Guidebook By Benjamin Wei Hao.
Good to have more books on OTP.
I wouldn’t dismiss
just because it’s doesn’t use Elixir. It goes towards explaining the reasoning behind how OTP approaches the problems that it solves.
In some way I see (p.175)
This forms part of the supervision strategy of a system and in some situations is put in place not by the developer, who focuses only on what particular workers have to do, but by the architect, who has an overall view and understanding of the system and how the different components interact with each other.
reflecting the sensibility of
DESIGN captures the essence of how to layer better than programming.
Also none of this contradicts Source Code is the Design. Code is an expression of design and design is influenced by the design-time and runtime capabilities of the target environment (however the mere existence of code is not evidence of intentional design).
Oh thanks for the advices.
I’m actually doing Benjamin Hao’s book currently.
I’ll give the Manning’s Erlang one a try.
Elixir in Action covers OTP and I prefer it over The Little Elixir & OTP Guidebook, worth adding to your list.
Excited for this book!
Beta 1 is available now. Already bought it!
Another book that teaches us how to program in layers. How interesting.
I have a question though, do they teach how to decouple our app logic from OTP, or are they intrinsically connected ?
Will surely check it out, I am fan so I can’t miss this out
I’m looking forward to look into your book! Hope it delivers just like almost every single one I got from pragprog. Going to get it just after I finish reading property testing one
I’m about to buy the book !! exciting week-end to come
Greetings from Paris, France
I feel this is a major focus of our writing, but obviously I am biased. You might be able to watch the book club thread to see if others agree.
Just bought it!
Got it. Thanks for arranging useful content.
Thank you just purchased a copy with the code ElixirForum
. I’m looking foward to this, I still feel like a lot of us are still writing Elixir code but not really OTP code. Maybe it’s just me.
Hopefully this book unlocks a way of thinking about Elixir and OTP apps and gives us more leverage over this beast of a tool that is Erlang and OTP.
Bought it
What James said. It’s basically the topic of the book.
I bought the book and thus far I am enjoying it a lot.
There are a couple of things I would like to point out however.
On page 49, the authors define the quizzes structure. One of the examples is as follows:
templates (%{ "category" => [Template.t]})
However, in the code used in the book, the notation most prevalent is the .
notation (template.category
instead of template["category"]
for example).
Why did the authors choose this approach instead of using atoms?
templates (%{ category: [Template.t]})
I know the authors address this by saying this is not a book about Dialyzer and that using it would add to the code.
However they do good job specifying types for the Data layer. As a reader, I would have been delighted to have more Dialyzer into the book. But this is just a personal opinion !
Loving the book thus far !
Strings vs. Atoms
Categories need to be strings, because they are eventually going to be entered by teachers creating content. Large amount of dynamic atom creation could crash the BEAM.
Typespecs
In some early versions of the book, we had the typespecs in the code. Sadly, it made things worse. It really added to the weight of an already code heavy book and it raised the mental overhead needed to get through it, in our opinion.
With regards to the type specs, if the only issue at hand is clutter within the book would possibly another way to address this be to have a repo with the example which had type specs? I understand this is more work to maintain and may have other issues, I mainly mean that there may be ways of adding that information without making the code directly in the book harder to get through.
On the whole I have been enjoying the book, need to get back into it as I put it down when waiting on new chapters and have been sucked into other things, the part I have read though has been extremely valuable.
Yes, what you are asking for is possible, of course.
We did try to think of other ways to handle this issue which is why we have the section describing all the data structs for the quiz project.