Fascinating deep dive into hitting and overcoming the scaling issues affecting the sync engine Linear built.

Paul Robert Lloyd:

This small website provides a list of words that you can refer to when naming something like an HTML class, custom CSS property or JavaScript function. Each word links to a page on Wordnik, an online dictionary that does the hard work of providing multiple definitions and listing related words.

Kent Beck:

The fundamental, inescapable problem? What is in the system is a flawed reflection of what is going on in reality. We want what is in the system to be as close as possible to reality, but we also need to acknowledge that consistency between the system & reality will only ever be approached, not achieved. The system will record changes in reality eventually, but by then we may have made decisions that need to be undone.

Andrew Harmel-Law:

The moves in software delivery towards ever-increasing team autonomy have, in my mind at least, heightened the need for more architectural thinking combined with alternative approaches to architectural Decision Making.

Good technical design decisions are very dependent on context. Teams that regularly work together on common goals are able to communicate regularly and negotiate changes quickly. These teams exhibit a strong force of alignment, and can make technology and design decisions that harness that strong force. As we zoom out in a larger organisation an increasingly weak force exists between teams and divisions that work independently and have less frequent collaboration. Recognising the differences in these strong and weak forces allows us to make better decisions and give better guidance for each level, allowing for more empowered teams that can move faster.

The general idea of an “Islands” architecture is deceptively simple: render HTML pages on the server, and inject placeholders or slots around highly dynamic regions. These placeholders/slots contain the server-rendered HTML output from their corresponding widget. They denote regions that can then be “hydrated” on the client into small self-contained widgets, reusing their server-rendered initial HTML.

From a couple years ago. The section dispelling dogma that’s arisen around the approach was particularly interesting (from 22:40).

Max Kreminski:

Monads are a solution to a specific problem: the problem of repetitive code. If you write enough code in a functional programming language, you start to notice that you’re writing a lot of suspiciously similar code to solve a bunch of superficially different problems. Wouldn’t it be nice if you could just write this code once and then reuse it, instead of rewriting it slightly differently every time? I’m omitting a lot of detail here, but this is effectively what monads allow you to do.

Rails to React.

A look into some of the inspiration and decisions in the design of Elixir.

Eric Evans on avoiding the pursuit of perfection when using DDD.

Jesper L. Andersen:

In the recent years, I have adopted a method for system design, which I think yields good results. For a lack of better word, I overloaded “stack” yet again, and use it as a metaphor for this design.

Jan Stenberg quoting Eric Evans:

Evans points out that a microservice, which should be autonomous, can be a good bounded context, but emphasizes that this does not mean that a service always is a bounded context, something that developers sometimes interpret it as.

Robert Reppel:

… smaller subsystems communicate via agreed-upon contracts (commands and events). Each has their own data store. Eventsourcing and the CQRS pattern are used to reduce coupling (and therefore the potential for side effects) to a minimum.

Viewing software architecture decisions as selling options.

Nice coverage of different hypertext types. Start with HAL.

Nathan Peck:

Airtime uses AWS Simple Notification Service (SNS) and AWS Simple Queue Service (SQS) to power the pub/sub event backbone that connects producer services to consumer services.

A collection of practices and patterns out in the wild.

A look at using queues for submitting commands.

Nice concept summary.

Dan McKinley:

If you think about innovation as a scarce resource, it starts to make less sense to be on the front lines of innovating on databases. Or on programming paradigms.

Truth Labs:

“Dashboard”, “Big Data”, “Data visualization”, “Analytics” — there’s been an explosion of people and companies looking to do interesting things with their data. I’ve been lucky to work on dozens of data-heavy interfaces throughout my career and I wanted to share some thoughts on how to arrive at a distinct and meaningful product.

Michael Feathers:

It’s funny. I can’t count the number of times I’ve seen organizations with large monolithic software applications move toward SOA. It’s easy to think that we’ve learned a lesson in the industry and that services are just the new “best practice.” Surely we would’ve started with them if we were just starting development now. Actually, I think the truth is a bit more jarring. Different architectures work at different scales. Maybe we need to recognize that and understand when to leap from one to another.

Simon Marlow:

Haskell isn’t a common choice for large production systems like Sigma, and in this post, we’ll explain some of the thinking that led to that decision. We also wanted to share the experiences and lessons we learned along the way. We made several improvements to GHC (the Haskell compiler) and fed them back upstream, and we were able to achieve better performance from Haskell compared with the previous implementation.

Dave Copeland:

We’ve given up on “fat models, skinny controllers” as a design style for our Rails apps—in fact we abandoned it before we started. Instead, we factor our code into special-purpose classes, commonly called service objects. We’ve thrashed on exactly how these classes should be written, so this post is going to outline what I think is the most successful way to create a service object.

Elisabeth Hendrickson:

I prefer:

• Recovery over Perfection
• Predictability over Commitment
• Safety Nets over Change Control
• Collaboration over Handoffs

Ultimately all these statements are about creating responsive systems.

Scott Wlaschin:

But now we have something much more abstract, a set of generalized requirements that can apply to all sorts of things:

Martin Fowler:

Kent Beck came up with his four rules of simple design while he was developing ExtremeProgramming in the late 1990’s. I express them like this.

Loup:

Object Oriented Programming died several times already. This time might be the last.

Michael Feathers:

I strongly believe that there is a law of conservation of complexity in software. When we break up big things into small pieces we invariably push the complexity to their interaction.