suj1th

I guess it's best if Jeremy starts the repo himself, and we contribute to it. But I agree; cannot understate the importance of solutions to make the best use of this book.

Thank you for sharing an interesting paper. The similarity between Raft and Viewstamped Replication is easy to gauge. The original Raft paper too acknowledges this similarity. OTOH, the similarity between Paxos and Raft is not very apparent (to me). The paper in the link seems to predate Raft, and only considers VR, Zab and multi-Paxos.

Can you elaborate a bit more on the STAR approach? A link, perhaps, on how to use it when giving a talk?

A similar learning experience for me was when I was exploring Apache Calcite. That again is only query, and no storage. It has a concept of 'adapters' which, I assume, is similar to the postgres-like foreign data wrappers you mention.

Thanks for sharing the blog-post. I use Scala on Docker, and the features/fixes you mention certainly helps me in simplifying my deployments.

A similar situation was seen in India, when Uber entered the market. Most of the then-existing hail-taxi users were users of Ola (the home-grown service). Users here use both apps at the same time (comparing ride prices to make the choice). This meaning Uber and Ola eat into each other's revenues and markets across cities in India.

In a way, I am trying to link it with the central limit theorems. But, I may be woefully lost. I am just a novice in this.

The short answer is I don't know. However, the convenience of simplifying the calculations is, in my opinion, a win. Again, I am myself not convinced. Probably, my premise on the ubiquitousness of normality assumption on the residuals in ARMA models is itself flawed.

I can relate to this. I grew up in India when India was a closed economy, with anything (commodities or services) either too expensive or limited by license raj. My father, being a lowly government official, did have a steady but meagre income. Groceries and mortgage were always on his mind. But, he also had his habit of never borrowing, in spite of dire need. Never kept a credit card either (to this day). I have learnt that brand of frugality from him.

not to mention, some awesome references at the end of each chapter. I had made it a point after each chapter to randomly pick an interesting reference and read that as well.

I have recently started organising little snippets of learning I gather during work using dnote (https://dnote.io/). For instance, I have organised multiple 'books' around topics such as regex, Apache Spark configurations and others. The best part is that it works right off the terminal. But as a downside, it is not the best way to take extensive notes; only 1-2 liners.

The counter argument for this is that far too many blog posts stretch an idea, opinion or observation into far too many words, when a single tweet could suffice to state them. I think this post is an excellent example of this.

So would you say people who do master complex mathematical concepts too learn from examples, rather than a deductive approach of understanding pure theory?

IMO, deductive learning is limiting ( we are limited by the span of our examples), but it has great recall value. Inductive learning is harder to commit to long-term memory; particularly, when learning something which you find scant use for in your day-to-day life. Again, I can see this is not general, and could vary considerably across individuals.

If you're looking for an ML kind of experience, Kotlin is a joke, it doesn't even have pattern matching.

Can't agree with this more. I just cannot figure the raison d'être of Kotlin.

Personally, I started out in Scala as a 'casual' user using it as better Java/Kotlin. But, I have certainly seen myself gradually gravitate towards Haskell-inspired style. For many like me (with more exposure to OOP than FP in early career), it is a pedagogical device into FP. With regards to the future of Scala, particularly tooling, Scala may still be able to retain its 'casual' users with its recent focus on tooling : http://scala-lang.org/blog/2018/02/14/tooling.html

I don't see how this is true. The bitmap vs bloom-filters argument is more about accuracy (BFs have a one-way error, Bitmaps do not). The datasets' density/sparsity has no bearing on efficiency, AFAIK. Would you elaborate your reasoning?

As somebody who works with Scala, List comprehensions (and associated filters) were indeed a surprise to me as well when I started hacking in Haskell. Their resemblance to logic programming makes it so much more elegant, and so much easier to reason about.

which distributed database was it? Just curious.