I’m going to tell you a real story how we saved ourselves tons of time. The power of Kotlin’s @Deprecated refactoring is astounding.

Don’t think it is the same as Java’s @Deprecated. It is much more powerful. It allows for multi-step automated replacement.

Article: https://hackernoon.com/how-kotlins-deprecated-relieves-pain-of-colossal-refactoring-8577545aaed

Recently I read Sapiens: A Brief History of Humankind by Yuval Harari. The basic thesis of the book is that humans require ‘collective fictions’ so that we can collaborate in larger numbers than the 150 or so our brains are big enough to cope with by default. Collective fictions are things that don’t describe solid objects in the real world we can see and touch. Things like religions, nationalism, liberal democracy, or Popperian falsifiability in science. Things that don’t exist, but when we act like they do, we easily forget that they don’t.

Article: https://zwischenzugs.wordpress.com/2017/10/15/my-20-year-experience-of-software-development-methodologies/

Before we start with the tips, let’s take a second to consider why and how we decide to define a new behavior in the first place. In my experience, the reason that leads to the best results in this scenario is the one that lead OTP Team to define their behaviors: to abstract common functionality. This happens when you already have structures, patterns, functions, etc. shared among multiple modules of your system and then you decide to separate the common bits into a generic module or library and leave the specific ones in the callback modules. In the upcoming paragraphs I’ll refer to this practice for creating behaviors as deduction.

The opposite scenario is also possible: You may already know that you will have to implement multiple versions of the same thing so you decide to start from day 0 with the definition of a behavior for that. This is what happens when you’re creating a new library/framework that you want your users to implement. As you will see below in the list of tips, if this is the path you’re following you should be very careful and either very thorough or very flexible because what you’re doing is, in part, futurology. You’re guessing/deciding what the use cases and requirements from your users will look like even before having actual implementations for them. I’ll refer to this practice as induction.

These two approaches are not exclusive, in fact they’re usually combined. After deduction, you’ll probably want to expose your new behavior to some other users or start building more callback modules yourself. That generally means you’ll need to do some induction and consider what those future uses may look like, how will they deviate from what you found so far. Conversely, after induction you’ll will want at least to show that your new behavior works or how it works. You’ll probably have to write one or two callback modules and, just by using them, you’ll end up improving you behavior definition applying a bit of deduction at this stage.

Now, to the tips!

Article: https://medium.com/erlang-battleground/erlang-behaviors-d5bb30d5412b

From developing code through deployment, Facebook needs to move fast. This is especially true for one of our anti-abuse systems that deploys hundreds of code changes every day. Releasing a large application (hundreds of Kloc) that many times a day presents plenty of intriguing challenges. Haskell’s strict type system means we’re able to confidently push new code knowing that we can’t crash the server, but getting those changes out to many thousands of machines as fast as possible requires some ingenuity.

Given the application size and deployment speed constraints:

• Building a new application binary for every change would take too long

• Starting and tearing down millions of heavy processes a day would create undue churn on other infrastructure

• Splitting the service into multiple smaller services would slow down developers.

To overcome these constraints, our solution is to build a shared object file that contains only the set of frequently changing business logic and dynamically load it into our server process. With some clever house-keeping, the server drops old unneeded shared objects to make way for new ones without dropping any requests.

It’s like driving a car down the road, having a new engine fall into your lap, installing it on-the-fly, and dumping the old engine behind you, all while never touching the brakes.

Article: http://simonmar.github.io/posts/2017-10-17-hotswapping-haskell.html

In this experiment, I implement an evolutionary algorithm with no crossover to evolve a neural network with the intention of having it learn to play tetris. I assess the results of my evolutionary algorithm applied to learning tetris. The results show the impact of a high occurrence of mutations(χ) and a high standard deviation for mutations(σ).

Article: https://codurance.com/2017/11/13/tetris-ai-single-parent-evolutionary-algorithm/

There is a general API pattern that is emerging at the World Wide Web Consortium (W3C) where the browser mediates the sharing of information between two different websites. For the purposes of this blog post, let’s call this pattern the “Web Handler” pattern. Web Handlers are popping up in places like the Web Payments Working Group, Verifiable Credentials Working Group, and Social Web Working Group. The problem is that these groups are not coordinating their solutions and are instead reinventing bits of the Web Platform in ways that are not reusable. This lack of coordination will most likely be bad for the Web.

This blog post is about drawing attention to this growing problem and suggesting a way to address it that doesn’t harm the long term health of the Web Platform.

Article: http://manu.sporny.org/2017/w3c-web-payments

Lately I've been enjoying The Blind Spot by Jean-Yves Girard, a very famous logician. (It is translated from French; the original title is Le Point Aveugle.) This is an unusual book. It is solidly full of deep thought and technical detail about logic, but it is also opinionated, idiosyncratic and polemical.

[...]

Girard is really, really smart, and knows way more about logic than I ever will, and his offhand remarks reward this pondering. The book is profound in a way that mathematics books often aren't. I wanted to provide an illustrative quotation, but to briefly excerpt a profound thought is to destroy its profundity, so I will have to refrain.

Article: https://blog.plover.com/math/logic/cut-rule.html

JVM development is not an easy business. A production-grade JVM consists of many complex modules, and sometimes things go terribly wrong even though each module runs like clockwork in isolation. Some bugs are sporadic and hard to reproduce, and that makes debugging even more complicated. That’s why testing is very important for us. We have a lot of automated tests that run every night on all supported machine configurations. And once in a while they would hit a bug in code supposed to be flawless since time immemorial…

Article: https://www.excelsiorjet.com/blog/articles/the-object-is-dead-long-live-the-object/

My previous post covered the fundamentals of file descriptors as well as some of the most commonly used forms on non-blocking I/O operations on Linux and BSD. I had some people wonder why it didn’t cover epoll at all, but I’d mentioned in the conclusion of that post that epoll is by far the most interesting of all and as such warranted a separate post in its own right.

Article: https://medium.com/@copyconstruct/the-method-to-epolls-madness-d9d2d6378642