Things learned this week #1
Decided to make a post with short overviews of interesting materials that trapped to my eye during a week. I have found such kind of posts useful for myself, hope you will also find something interesting here or suggest some related stuff in comments.
Video talks, tutorials
Modern approach for synchronizing distributed systems. Shows how to fight against inconsistency, deadlocks and race conditions in distributes systems.
Awesome resource where you can find a nice overview of core rxjs concepts.
Protocol oriented programming in Swift (video)
I’m not very familiar with Swift, but this talk was quite interesting. Describes what protocol oriented programming means and shows how classes can bring a ton of complexity to your system.
Blog posts, specs or articles
How great programmers avoid bugs
Interesting comparison of the different approaches for writing high-quality code from famous software engineers. The key point, I think, is that whenever you write your code you should prove that it actually works. That thing can be made by different instruments, some of them are better than others but that should be in any case (tests, mathematical or logical proofs).
Seems like nothing new but useful to keep in mind when preparing some presentation with numbers, statistics, and analytics. My thought here is that the key idea of all charts and diagrams in your presentation is not about showing how smart are you or that thing that you are talking about but to help people to get the key point of your presentation.
More advanced approach to work with asynchronous operations in redux than redux-thunk.
The most discussed topic in Clojure community for the last week. Don’t have a clear picture of how that spec will work, but seems like it will execute static type check for code with specs. I think in any case that is the step forward, but need to look closer.
Funny story, just worth reading.
Eliminating nondeterminism in tests
Nice post by Martin Fowler. Highlights the main problem that comes with nondeterministic operations in software tests. The main source of evil is IO that brings unpredictable behaviour and makes our tests flaky. Author suggests a couple of ways of solution to that problem. Nothing new but useful to remember and apply in practice.
Projects
Fancy algorithm visualization tool. I was also thinking about creating something like that.