Home

Designing Data-Intensive Applications - Chapter 4 - Encoding and Evolution

Designing Data-Intensive Applications - Chapter 4 - Encoding and Evolution

Translations: RU
Earlier this year the book club of our company has studied excellent book: Martin Kleppmann - Designing Data-Intensive Applications This is the best book I have read about building complex scalable software systems. 💪 As usually I prepared an overview and mind-map. Chapter 4: What is evolvability. Backward and Forward compatibility Approaches to encode data: JSON, XML, and their binary variants Thrift and Protobuf Apache Avro Models of data flow Through databases Through services: REST, SOAP, RPC and the future Through message brokers - when they are better and when they are not Much more details in the mind-map:
Designing Data-Intensive Applications - Chapter 3 - Storage and Retrieval

Designing Data-Intensive Applications - Chapter 3 - Storage and Retrieval

Translations: RU
Earlier this year the book club of our company has studied excellent book: Martin Kleppmann - Designing Data-Intensive Applications This is the best book I have read about building complex scalable software systems. 💪 As usually I prepared an overview and mind-map. Chapter 3: Data structures: Log-structured. SSTables / LSM-trees (when we don’t update anything but write to the end). A very cool idea of how to store data.
Designing Data-Intensive Applications - Chapter 2 - Data Models and Query Languages

Designing Data-Intensive Applications - Chapter 2 - Data Models and Query Languages

Translations: RU
Earlier this year the book club of our company has studied excellent book: Martin Kleppmann - Designing Data-Intensive Applications This is the best book I have read about building complex scalable software systems. 💪 As usually I prepared an overview and mind-map. Chapter 2: What is data model. Different relations between the data. Relational, Document, Graph data models. Which one is better and when. Schema-on-write, schema-on-read (schemaless). Data locality.
Designing Data-Intensive Applications - Chapter 1 - Reliable, Scalable, and Maintainable Applications

Designing Data-Intensive Applications - Chapter 1 - Reliable, Scalable, and Maintainable Applications

Translations: RU
Earlier this year the book club of our company has studied excellent book: Martin Kleppmann - Designing Data-Intensive Applications This is the best book I have read about building complex scalable software systems. 💪 As usually (to better learn) I prepared an overview and mind-map. Chapter 1: Building blocks of the apps What is Reliability, Scalability and Maintainability. Examples and definitions. Faults and Failures Performance, Load, Latency and Response Time Operability, Simplicity, Evolvability Why you should randomly kill your servers 😅 How Twitter delivers 12,000 tweets per second to 300,000 readers per second.
Golang introduces generics

Golang introduces generics

Translations: RU
Golang FINALLY introduces GENERICS (aka templates, aka type parameters) in release 1.18 (in Feb 2022) I remember the early 2000s when generics where added to C#, and how they were awaited… These days Go is my favourite language for writing highly-scalable solutions and generics are the key thing I’ve been waiting for. They should significantly simplify design of the apps in some cases. My mind map with key things you should know:
Daily Stand-up: You're Doing It Wrong!

Daily Stand-up: You're Doing It Wrong!

Translations: RU
Do you use daily standup meetings? How standard daily standups are organized Everyone (one-by-one) is asked about: yesterday activities, today activities, blockers. But this approach has common problem: people are not always listen to others! Because the next person thinks what to say when it’s their turn. There is a better model - “Walking the Board” Discuss every ticket on the board one-by-one. The person who worked on the ticket says a few words, can raise any problems that are immediately addressed.
Clean Architecture - PART IV - Component Principles

Clean Architecture - PART IV - Component Principles

Translations: RU
The book club of our company has chosen a new wonderful book for reading: Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design Fourth part of the book is about principles of combining components into software systems. This part is more interesting. It contains: Overview of components history: Relocatability, Linkers Three principles of Component Cohesion REP: The Reuse/Release Equivalence Principle CCP: The Common Closure Principle CRP: The Common Reuse Principle Three principles of Components Coupling ADP: The Acyclic Dependencies Principle SDP: The Stable Dependencies Principle SAP: The Stable Abstractions Principle I especially enjoyed this chapter because of presented metrics that could be used to measure(!
Clean Architecture - PART III - Design Principles

Clean Architecture - PART III - Design Principles

Translations: RU
The book club of our company has chosen a new wonderful book for reading: Robert Martin - Clean Architecture - a Craftsman’s Guide to Software Structure and Design 👍 Third part of the book is about SOLID principles Single Responsibility Principle: A module should be responsible to one, and only one, actor. Open-Closed Principle: A software artifact should be open for extension but closed for modification Liskov Substitution Principle: S is a subtype of T if instead of instance of T we can always use an instance of S Interface Segregation Principle: use interfaces to reduce dependency upon changes Dependency Inversion Principle: avoid dependencies on volatile concrete elements I didn’t learn anything new from here (but I am in software engineering for 20+ years already ;).
Comparison of Front-end frameworks: Angular, React, Vue

Comparison of Front-end frameworks: Angular, React, Vue

Translations: RU
When you are starting a new software solution need to select a technology for Frontend. There are currently three leading technologies: Angular, React, and Vue. But how do you choose from them? Our team has experience with all of them, but usually the choice is made on the basis “who is available from the team and what they prefer”. I wanted a deeper Pros and Cons comparison, and I found it in great short Udemy course :