Weekly Digest 20180917-23
This is actually a digest post for the most recent 2 weeks. Below are short summaries of what I read, learned and tried. This list is also a way to organize some topics I would like to explore more.
Reading #1: Goodbye Redux (English)
This article briefed through the history of front-end development since 2009. It stated what was the problem, how we solved them and what we kept doing after that act. In the end, it stated a recommended approach for the original problem with new technologies we now have.
It starts from solving a simple issue but we may make the solution get more complicated than we expected.
Reading #2: RxJava 沉思录 (Chinese)
When I heard Reactive, I thought it was another design pattern in programming which is another variation like Observer pattern. This 4-episode series summarized the author’s understanding of RxJava, which was implemented based on Reactive programming paradigm. Reactive programming is more than a pattern and it is more like a development and design framework, i.e. domain driven development.
Reading #3: The Nature of Software Development (still reading)
I personally think this is more like a book for managers, team leaders, or bosses. From the chapters I read, it keeps stating the primary thing of developing a software, “deliver the value”. No matter what are the values and who cares them, delivering ASAP makes everything simpler to predict, develop and manage. To deliver as soon as possible, it’s naturally implement and release feature by feature. Hmm, wait. This sounds familiar. Are we talking about Agile Development?
By the way, I like the drawings inside. They make the concept easier to understand.
Practice #1: Ruby Enumerator and Enumerator::Lazy
After studying some Elixir, I was fascinated by its Stream module. Which allows me to conduct many different operations on the source but can be lazy. I tried to find the exact same behavior in Ruby so I found Enumerator::Lazy.
Basically, the usage of Enumerator and Enumerator::Lazy are the same except the .lazy method which make the collection behaves differently. But how to make a lazy collection behaves the same? Just use .force in the end.
What are the benefit? Evaluations happen as late as you want. Code like (1..1_000_000_000).select(&:even?).map(&:to_s) runs right after the first .select. Well, this is terrible and we don’t need to mention the .map after the .select.
