Love the format. Each section is a commit. You can clone the repo and go through the post using git and run the commands yourself, while reading the blog post in your terminal git history.
It would be awesome to have a similar thing that would be runnable as a test. I would embed commands with expected output. If the output doesn’t match, the test fails. Integrate it into ex_doc. No more outdated “soft” documentation, like Phoenix guides.
@petecorey published it on Elixir Blog Posts. This is a really interesting article and reminds me of a friend that started over a very simple project in which he used only Plug, but after some time he discovered that he was reinventing Phoenix, so he dropped to regular Phoenix.
Coming from an OO background, I never really understood how Elixir was concurrent until I took a deeper dive into the Erlang VM––the BEAM. This article breaks down how the BEAM provides Elixir with concurrency, with a little bit of history and the help of some laundry (seriously). https://medium.com/flatiron-labs/elixir-and-the-beam-how-concurrency-really-works-3cc151cddd61
@nickdichev Great articles! Loved how they flowed!
For note, Instead of String.split("go go gophers", "") |> Enum.filter(fn x -> x != "" end) in part 2 you can instead do String.split("go go gophers", "", trim: true) to get the same result a bit faster.
A dive into implementing a 9x9 board with different data structures looking at which performs best for what task. Includes some musings on the changing performance characteristics of maps smaller/bigger than 32 elements.
In which I embark to find bugs in my statistex library with property based testing expecting to find nothing because of loose conditions and existing tests… only to find 2 bugs.
I really like the sentiment of the blogpost. If property tests find no issues - great - but more likely they find ones you would’ve never though about or you though would already work.
Thanks! I was very positively surprised with the outcome myself. If anything it really helps with thinking about your system in terms of properties and how your understanding might be wrong. In @ferd’s book there is a cool example of sending birthday emails where you expect everyone to get it on their birthday… cue 29th of February who should still get one but not “on their birthday”.
And I am still waiting for stateful testing in the stream_data. I have created something similar (stream_state), but it is very rough at the edges and I still have problems with reductions