Did not read (yet)

A very interesting feedback on working remotely

Free eBooks, of quality!

Good examples on what NOT to do

Great introduction to Salesforce, clarify a lot of the terms

interesting article, especially when it talks about dark pattern. I.e., when a company starts doing something, it becomes part of its DNA. and people will use that to justify future milder actions.

Great tutorial that I should go through

So far, best quote:

If a function description includes an "and", it's wrong

Functions should do one thing and one thing only. When you're writing the function documentation and find that you added an "and", it means the function is doing more than one thing. Break that function into two and remove the "and".

This is a great read, especially since you learn about someone's mistakes.

TIL about the "Russian Woodpecker."

As a rbenv user, you can install readline and ruby_build with Homebrew:

$ brew install readline ruby-build

now set the configure options when compile Ruby:

$ RUBY_CONFIGURE_OPTS=--with-readline-dir=`brew --prefix readline` rbenv install 2.3.1

and then don't forget to add:

IRB.conf[:SAVE_HISTORY] = 1_000

in your ~/.irbrc file

Wow. Live lighting all around the world. Based on a network of lightning sensor. Wow.

I saw that talk at an Agile conference earlier this year. really good. he also recommended the book Accelerate during it, which I think is the most interesting non-technical book I’ve ever read on software engineering practices

Inverted classes: the whole lectures have already been recorded in video, the class are about answering questions and live problem solving

A good article presenting a Git branching model for development roadmap

Algorithm to the multi-armed bandit.

One strategy that has been shown to perform well time after time in practical problems is the epsilon-greedy method. We always keep track of the number of pulls of the lever and the amount of rewards we have received from that lever. 10% of the time, we choose a lever at random. The other 90% of the time, we choose the lever that has the highest expectation of rewards.

Quote from one of the top comment (https://news.ycombinator.com/item?id=19957326)

And some of my favorite simplifying patterns:

• AOP for logging; but NOT (dear god) for business logic.

• 3 levels of abstraction, and no more. If you can't figure out a way to do it in 3 levels of abstraction, then something else is wrong.

• 3 systems of state: config (global), current request and persistence (database). If you need more than that, then something is wrong with the architecture. (Ok, compilers may not be able to get away with this, but most applications can, in my experience.)

• If you use a pattern (MVC, for example) apply it to the whole system. E.g. doing IOC only in the upstream API system when the rest of the code doesn't, just makes a mess.

Very nice books written about the history of the most famous games

Interesting article on how to lock resources

TL;DR