radimrehurek.com: Practical Data Science in Python

End-to-end example: automated spam filtering

http://www.johndcook.com : Object oriented vs. functional programming

From Michael Feathers:

OO makes code understandable by encapsulating moving parts.
FP makes code understandable by minimizing moving parts.

This explains some of the tension between object oriented programming and functional programming. The former tries to control state behind object interfaces. The latter tries to minimize state by using pure functions as much as possible.

It’s understandable that programmers accustomed to object oriented programming would like to add functional programming on top of OO, but I believe you have to make more of an exclusive commitment to functional programming to get the most benefit. For example, pure functions are easier to debug and to execute in parallel due to their lack of side effects. But if your code is only semi-functional, you can’t have the same confidence in testing your code or in spreading it across processors.

James Hague argues that 100% functional purity is impractical and that one should aim for 85% purity. But the 15% impurity needs to be partitioned, not randomly scattered across your code base. A simple strategy for doing this is to use functional in the small and OO in the large.Clojure also has some very interesting ideas for isolating the stateful parts of a program.

http://www.johndcook.com/blog/2010/11/03/object-oriented-vs-functional-programming/

vladmihalcea.com: A BEGINNER’S GUIDE TO TRANSACTION ISOLATION LEVELS IN ENTERPRISE JAVA

http://vladmihalcea.com/2014/12/23/a-beginners-guide-to-transaction-isolation-levels-in-enterprise-java/

A relational database strong consistency model is based on ACID transaction properties. In this post we are going to unravel the reasons behind using different transaction isolation levels and various configuration patterns for both resource local and JTA transactions.

Apache Camel <-> Enterprise Integration Patterns

In order to understand what Apache Camel is, you need to understand what Enterprise Integration Patterns are.

Paris Review: http://www.theparisreview.org/blog/2014/09/05/the-beauty-of-code/

theparisreview.org

as software programs grow bigger and more complex, the code they comprise tends to become unreadable and incomprehensible to human beings. Programmers like to point out that if each line of code, or even each logical statement (which may spread to more than one physical line), is understood to be a component, software systems are the most complicated things that humans have ever built: the Lucent 5ESS switch, used in telephone exchanges, derives its functionality from a hundred million lines of code; the 2008 Fedora 9 distribution of Linux comprises over two hundred million lines of code. No temple, no cathedral has ever contained as many moving parts. So if you’ve ever written code, you understand in your bones the truth of Donald Knuth’s assertion, “Software is hard. It’s harder than anything else I’ve ever had to do.” If you’ve ever written code, the fact that so much software works so much of the time can seem profoundly miraculous.

The Literate Programmer: The microservice declaration of independence

In order for "microservice architecture" to be a useful way of characterising systems, it needs an accepted and well-understood definition. Mark Baker laments the lack of a precise description, because he feels its absence compromises the value of the term:

Really unfortunate that the Microservices style isn't defined in terms of architectural constraints #ambiguity #herewegoagain

In their article, Martin and James have this to say about the style's definition:

We cannot say there is a formal definition of the microservices architectural style, but we can attempt to describe what we see as common characteristics for architectures that fit the label.

I'm still optimistic that a clearer picture is yet to emerge, though it might not be as unambiguous as the REST architectural style, which is defined in terms of six constraints.

My own opinion is that microservice architectures can be understood through a single abstract architectural constraint which can be interpreted along many different degrees of freedom.

X can be varied independently of the rest of the system.

What might X be? There are many qualities that might be locally varied in an architecture to beneficial effect. Here are some ways we could introduce novelty into a service without wishing to disturb the greater system:

• Select implementation and storage technology
• Test
• Deploy to production
• Recover from failure
• Monitor
• Horizontally scale
• Replace

There are other aspects of systems that are harder to formalise, but which the human beings that work on our software systems might wish to do with without being troubled by the fearsome complexity of the whole architecture:

• Understand
• Describe
• Work on with a close-knit team
• Share two pizzas in celebration of a new feature

I don't wish to imply that this is an exhaustive list. To me, the commonality lies in the concept of independent variation, not the kinds of variation themselves.

The microservice declaration of independence