Вопрос "какая репликация MySQL лучшая?" звучит часто. Ответ, как водится в сложных системах, – "зависит от ситуации". Нет универсального решения. Выбор оптимального метода репликации всегда компромисс. Приходится искать золотую середину между тем, насколько данные должны быть одинаковыми везде, скоростью работы, бесперебойностью и тем, насколько сложно все это настроить. Посмотрим внимательнее на главные способы. Это поможет сделать осознанный выбор.

Уверен, многие читатели Хабра знакомы с этим способом, ведь он существует не первый день. Чтобы сэкономить ваше время, я скажу всего два слова: comss DNS.

Все остальные - велком под кат :-)

Новый перевод от команды Spring АйО расскажет вам, каких проблем можно избежать, если пользоваться подходом «Рендеринг на стороне сервера» и в чем преимущества такого подхода в целом по сравнению с подходом Single Page Application.

Всем привет, меня зовут Вадим Макеров, я работаю в iSpring бэкенд-разработчиком.
Однажды у нас в продукте был инцидент, который привел к даунтайму LMS и происходил несколько раз, в течении нескольких дней. Причина оказалась нетривиальной и находилась на уровне сетевых настроек подключений между сервисами.

Не секрет, что ИИ-инструменты становятся все более доступными, открывая широкие возможности для решения самых разных задач. В данной статье мы представляем вашему вниманию подборку лучших бесплатных нейросетей, способных удовлетворить самые разнообразные потребности: от генерации контента и обработки данных до оптимизации рабочих процессов и организации увлекательного досуга.

Приятного прочтения!

Язык паттернов помогает избежать многих проблем: не использует широкие тесты, не использует моки, не игнорирует инфраструктуру и не требует архитектурных изменений. Он обладает мощью широких тестов, а также скоростью, надёжностью и удобством сопровождения, присущим модульным тестам. Хотя и не обошлось без компромиссов. В этой публикации подробнее рассмотрим паттерны инфраструктуры, паттерны Nullability и паттерны тестирования легаси-кода.

Автоматизированные тесты очень важны. Без них программистам приходится тратить огромное количество времени на ручную проверку и исправление кода. К сожалению, многие автотесты также тратят огромное количество времени. Простым и очевидным вариантом является создание широких тестов, которые являются автоматизированными версиями ручных тестов. Но они нестабильны и медленны.

Знающие люди используют моки и шпионы для написания изолированных тестов, основанных на взаимодействии. Их тесты надёжны и быстры, но они имеют тенденцию «блокировать» реализацию, затрудняя рефакторинг, и их приходится дополнять широкими тестами. Кроме того, часто получаются некачественные и трудные для чтения тесты.

Плохие тесты — это признак плохого проектирования, поэтому иногда используются такие техники, как гексагональная архитектура и функциональное ядро, императивная оболочка, чтобы отделить логику от инфраструктуры. Это решает проблему... для логики. Но инфраструктура часто остаётся непроверенной, и она требует архитектурных изменений, которые недоступны для существующего кода.

Этот язык паттернов описывает четвёртый вариант. Он позволяет избежать всех вышеперечисленных проблем: не использует широкие тесты, не использует моки, не игнорирует инфраструктуру и не требует архитектурных изменений. Он обладает мощью широких тестов, а также скоростью, надёжностью и удобством сопровождения, присущим модульным тестам. Но не обошлось и без компромиссов.

Привет, Хабр!

Представьте себе котика, который пытается понять синтаксис человеческого языка. Сначала он разглядывает слова, затем прислушивается к интонациям, а потом решает, что всё это слишком сложно, и отправляется ловить мышей.

Но благо, что у нас, людишек, есть возможность создания инструмента, который может разложить сложные языковые конструкции на простые и понятные части. Как раз об этом и пойдет речь в нашей сегодняшней статье — о создании парсеров на Rust.

А именно - о двух библиотеках, которые позволяют это сделать. Начнем с первой под названием nom.

DISCLAIMER: посыл этой статьи не в том, что «PostgreSQL — гавно, не используйте PostgreSQL». Посыл в следующем: «Может быть я чего-то не понимаю в этой жизни? Пожалуйста, объясните, может быть я изменю своё мнение!»

Оооо, моя любимая тема "душных" людей в IT. Чаще всего этим болеют Разработчики в возрасте и Девопсы. Основная причина наверное возраст, по моим наблюдениям люди в возрасте к любой проблеме относится дотошней и пытаются предусмотреть все пути эскалации, когда задача требует простого как таракан решения. Любой, кто работал в IT, наверняка с таким, в этой статье мы рассмотрим, кто такие душные люди, какие признаки указывают на их наличие, и самое главное — как с ними эффективно бороться.

GraphQL — невероятная технология, привлёкшая много внимания с тех пор, когда я начал в 2018 году использовать её в продакшене. Вам не придётся долго листать мой блог, чтобы увидеть, как я раньше продвигал её. После создания множества React SPA поверх путаницы нетипизированных JSON REST API технология GraphQL показалась мне глотком свежего воздуха. Я искренне поддерживал хайп вокруг GraphQL.

Однако с течением времени у меня появилась возможность выполнять развёртывания в окружениях, где больше важны не функциональные требования, а безопасность, производительность и удобство поддержки. Тогда и поменялась моя точка зрения. В этой статье я подробно расскажу о том, почему сегодня не рекомендовал бы GraphQL большинству, и поделюсь более совершенными альтернативами.

В статье для примеров я буду использовать код на Ruby с превосходной библиотекой graphql-ruby, но я уверен, что многие из перечисленных проблем не зависят от выбора языка/библиотеки GraphQL.

Если вы знаете более качественные решения или способы, напишите мне комментарий.

Давайте признаемся: подавляющее большинство пишет Java код, используя JetBrains IntelliJ IDEA Ultimate. Да, это отличная IDE. Для нее есть большое количество расширений, среда очень тесно интегрируется с Spring Framework и знает его особенности.

Тогда зачем пробовать что‑то другое?

Привет, Хабр! Меня зовут Константин Шибков, я Java‑разработчик в CDEK.

В какой‑то мере все Java‑разработчики стали заложниками IDEA. Она так привычна, что нет желания пробовать другое. Ведь всё такое удобное и знакомое за столько лет использования.

Но если у вас есть трудности с доступом к Ultimate версии, а Community вариант не достаточно функционален — самое время попробовать современную альтернативу — Visual Studio Code.

В статье делюсь опытом подготовки среды разработки и изучения вопроса: «А можно ли перейти на VSCode?».

Популярность на GitHub помогает открывать ценные возможности для разработчиков и стартапов. Подпольные магазины продают «звезды» платформы, предлагая программистам способ буквально следовать популяному слогану «Fake it till you make it».

TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД.

DDD вполне успешно решает поставленную задачу: дать разработчикам инструменты, которые позволят им справиться (корректно реализовать и поддерживать) со сложной предметной областью. Но эта победа оказалась пирровой: инструменты, обеспечивающие корректность данных в памяти, оказались неспособны гарантировать корректность данных в БД. А что толку от изначально корректных данных в памяти, если со временем (после их сохранения в БД и последующего чтения) они перестают быть корректными? По сути, у DDD есть фатальный недостаток: DDD неизбежно приводит к нарушению целостности данных (инварианта бизнес-логики) в БД.

Всем привет, меня зовут Артемий, я работаю старшим Android-разработчиком в команде пользовательского профиля в RuStore. Мой опыт в индустрии уже 8 лет. За это время я успел поработать в разных проектах и компаниях. У меня был опыт работы в проекте, в котором было свыше 300 модулей и больше 60 Android-разработчиков. Такие условия заставляют задуматься о масштабируемости на принципиально ином уровне.

Сегодня я расскажу о способах обеспечения масштабируемости проекта и как этому может навредить неправильное восприятие Чистой Архитектуры (далее — ЧА). Предупреждаю сразу, это лонгрид в двух частях!