Привет, Хабр! Однажды я проводил небольшое тестирование виртуалок различных хостер-провайдеров и сравнивал их между собой — оказывается, с тех пор прошло уже аж пять лет. Ну и в том тестировании условия у всех серверов были одинаковые, т. к. тестировались сходные конфигурации.

Сегодня хотел бы рассказать о том, как себя ведут самые дешёвые (в ценовом диапазоне от 100 до 300 рублей) предложения от популярных хостеров. 

28 ноября 2025 года для многих началось с жалоб на WhatsApp. Текстовые сообщения и медиафайлы у части пользователей не доходят, а также при попытке голосового или видеовызова клиент бесконечно висит на статусе «Подключение», после чего сбрасывает звонок.

Операторы связи («МегаФон», «Билайн») рапортуют о штатной работе сети. И технически они не врут: связность есть, IP-адреса Meta (по большей части) доступны. Проблема лежит глубже — на уровне L7 фильтрации ТСПУ.

Эти выходные прошли под эгидой Connection Reset. Пока новостные каналы писали расплывчатое «пользователи жалуются на сбои», мы в чатах и на тестовых стендах пытались понять физику процесса.

Распределенные системы (aka микросервисы) набрали популярность и применяются все шире в современных реалиях. Сервисов становится больше, привычные задачи для них решаются сложнее, усложнились и вопросы аутентификации и контроля доступа.

В статье рассмотрим различные подходы использования API Gateway как части более общего API security-решения в контексте его работы с токенами доступа, выделяя преимущества, недостатки и связанные с ними вопросы безопасности. Также разберем, почему нужно ограничивать область действия access token и может ли API Gateway помочь и в данном вопросе.

Статья написана на основе материала, с которым выступал на PHDays 2025 и CodeFest 15.

Продолжаем нашу серию статей с разбором работы Китайского Firewall'а (GFW). В этой статье углубимся в техническую часть этой системы

Мы скачали 500 ГБ утечку из Великого Китайского Файрвола чтобы вам не пришлось и решили их изучить. Разбираемся, как он работает, кого обслуживает и как его обходят.

Привет, это Костя из Cloud.ru, я вернулся после долгого перерыва, чтобы снова открыть цикл коротких статей про Typescript. В этот раз поговорим о важном — дистрибуции типов. Зачем она вообще нужна, когда и как применяется, а также как работает. Как обычно интересное — под катом.

Всем привет, я Кирилл, и я оказался на рынке труда осенью 2025 года. Давайте разберем, почему же нам, разработчикам с большим стажем перестали приходить отклики, количество собеседований уменьшилось до нуля, а со всех сторон все HR-специалисты трубят о нехватке кадров в IT. А также рассмотрим новую боль всех HR-ов. Статья носит статистический характер, пару советов и философские высказывания автора, и немного юмора.

В первой части мы озвучили следующие тезисы:

- автотесты нужны не для экономии на тестировщиков, а чтобы сократить до минимума циклы разработки и узнавать об ошибках практически мгновенно;

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

- тесты ломают разработчики, поэтому им за них отвечать - все виды тестов должны писать и поддерживать разработчики;

- с полным автоматическим регрессом можно и нужно ставиться в прод после каждого изменения в кодовой базе;

- главный шаблон поставки в прод изменений - конвейер развертывания (Deployment Pipeline);

- конвейер делится на 2 главные фазы: commit stage и acceptance stage;

- первая фаза - быстрые тесты (до 5 минут), чтобы быстро узнать, что ветка сломана и её надо скорее чинить;

- вторая фаза - приёмочные тесты (до 1 часа), чтобы узнать, можно ли ставить в прод изменения.

Про быстрые тесты мы поговорили во второй части. Пришло время поговорить про короля автотестов - приёмочное тестирование.

Вы, наверное, слышали, что тесты — это хорошо, что тесты надо писать. И, возможно, даже согласны с этим.

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

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

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

TL;DR: eslint-plugin-interface-method-style гарантирует, что ваши TypeScript реализации соответствуют стилю, определенному в интерфейсах. Если интерфейс объявляет метод (method(): void), реализация должна быть методом. Если объявлено свойство-функция (method: () => void), нужна стрелочная функция. Это предотвращает баги с правилом unbound-method и делает код предсказуемым.

Ссылочный тип данных Object является базовым для всех ссылочных типов в TypeScript подобно тому как в JavaScript Object является прототипом всех остальных ссылочных типов.

Помимо того, что в TypeScript существует объектный тип Object , представляющий одноименный конструктор из JavaScript, также существует тип object , представляющий любое объектное значение. Поведение типа указанного с помощью ключевого слова object и интерфейса Object различаются.

Переменные, которым указан тип с помощью ключевого слова object , не могут хранить значения примитивных типов, чьи идентификаторы (имена) начинаются со строчной буквы ( number , string и т.д.). В отличие от них тип интерфейс Object совместим с любым типом данных. Возникает ошибка: Error: Type X is not assignable to type 'object' (Тип X не может быть назначен типу «объект»).

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

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

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

Отсюда сформулируем главные вопросы, на которые мы ответим в этой статье:

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

- Если все же да, то как тогда писать юнит-тесты? Какие есть подходы, и какой лучше выбрать?

Короче, всё как обычно: как и нафига?

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

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

О том, как в рамках кейса мы избавились от спагетти-зависимостей, поделили сервис на чёткие слои, упростили поддержку и масштабирование кода, — рассказываем под катом. Плюс делимся рекомендациями: кому и при каких сценариях связка «DDD Lite + микросервисы» может пригодиться.

В прошлой статье я рассказал, как мы пришли к DDD и про его очень важную особенность — единый язык, на котором легче и дешевле разговаривать с бизнесом. Еще мы рассмотрели разработку, ведомую моделью. Когда вначале стоит не выполненная по требованию фича, а абстрактная модель, созданная по требованиям и имеющая отражения в различных представлениях. Все эти области оперируют терминами единого языка и реализованы максимально похожими, чтобы каждый, кто будет работать с проектом, смог разобраться в любой из них.

Сегодня поговорим о том, как приручить непосредственно исходные коды программ, как они архитектурно представляются. Расскажу про идеи, которые мы используем для построения прозрачной и понятной модели, чтобы ее было легко развивать вместе с заказчиком. Эти подходы касаются и архитектуры, и хранения исходного кода, и вообще в целом вопросов разработки. Также расскажу про практические сложности. Формат статьи не позволяет включить огромное количество кейсов, поэтому приведу только два примера.

Часто в больших компания всё поделено на большие системы. А если система «Legacy», т.е. устаревшая, то часто внутри неё собрано очень много разнородного функционала. По сути такие системы представляют из себя монолитных монстров.

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

Границы систем размыты, нет чёткого понимания, что должно входить в систему, а что нет.

Команды сильно специализированы на конкретную систему и не могут участвовать в доработке никакой другой системы.

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

Можно ли исправить ситуацию коренным образом?

Вернон, в своей книге «Implementing DDD» много говорит об архитектуре Порты и Адаптеры, как о более продвинутом уровне Слоистой Архитектуры. Хотелось бы услышать ваше мнение на этот счёт.

Введение

Привет, Хабр! Предлагаю вашему вниманию перевод статьи Implementing SOLID and the onion architecture in Node.js with TypeScript and InversifyJS автора Remo H. Jansen

В этой статье мы рассмотрим архитектуру, известную как слоистая (onion). Слоистая архитектура — подход к построению архитектуры приложения, придерживающийся принципов SOLID. Он создан под влиянием DDD и некоторых принципов функционального программирования, а также, активно применяет принцип инъекции зависимостей.

Предпосылки

Данный раздел описывает некоторые подходы и принципы разработки программного обеспечения, необходимые для понимания слоистой архитектуры.

Принцип разделения ответственности

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

Команда Python for Devs подготовила перевод статьи о том, как можно освободить десятки гигабайт места в PostgreSQL без удаления данных и индексов. TL;DR: удаляем неиспользуемые индексы, чистим bloat, пересобираем таблицы и используем частичные индексы, чтобы хранить только то, что реально нужно.