Эта статья является переводом материала «When to Mock».

Использование моков в модульном тестировании является спорной темой. Автор оригинала заметил, что на протяжении всей своей карьеры в программировании он сначала перешел от «моков почти для каждой зависимости» к политике «без моков», а затем к «только моки для внешних зависимостей».

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

Привет! Меня зовут Данила, и я фронтенд-разработчик в KTS.

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

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

Очередная история успеха после череды неудач. Расскажу, чего мне стоило получить офферы от Facebook*, Google, Amazon, JP Morgan в Европе, как я готовился, сколько собесов зафейлил перед тем, как удача повернулась ко мне правильной стороной.

TL;DR. Послал сотни резюме. Прорешал около 100 задач на Leetcode. Прочел книжку по архитектуре (не той, которая про дома, а той, которая system design). Прошел 9 интервью. Получил 4 оффера. Принял 1. Жил, пока что, не очень долго, но, вполне себе, счастливо в Лондоне.

Структура данных часто пронизывает насквозь все слои приложения. При ее изменении приходится модифицировать структуру базы данных, логику работы с ними в программном коде, спецификации сервисов, интерфейс приложения. А если данные, описание их структуры и значительную часть логики обработки поместить в виртуализированное хранилище, и работать с ними как с единой онтологической моделью? Это сместит фокус с кода на данные и сделает приложения дата-центричными. Мы считаем, что такая трансформация позволит повысить скорость доставки полезных функций бизнес-пользователям и сэкономить ресурсы, требуемые на внесение изменений в приложения, открыть путь перехода к дата-центричной ИТ-архитектуре всего предприятия.

DScraft - это адаптация убер-популярной компьютерной игры Minecraft для Nintendo DS. Хотя DScraft даже близко не так популярен, как оригинальная игра, ему всё равно удалось собрать большое комьюнити, которое существует и сегодня, а саму игру загрузили более 500.000 раз только с одного моего сервера. Мне нравится думать, что это хотя бы частично из-за тех вещей в игре, которые обычно не казались возможными на платформе. Вся разработка заняла примерно полтора месяца. В основном было две вещи, которые раньше заставляли людей думать, что Minecraft на DS почти невозможен: GPU консоли и нехватка памяти.

В процессе обсуждения статьи "Почему я «мучаюсь» с JS" у меня сложилось понимание, что связка export / import в JS является базой для указания зависимостей между элементами кода (классами и функциями). А так как современные приложения вышли за рамки однофайловых и давно уже строятся из блоков, то выстраивание зависимостей между элементами кода имеет весомое значение. Настолько весомое, что в знаменитой аббревиатуре SOLID этому посвящена отдельная буква — D (Dependency inversion — инверсия зависимостей, не путать с Dependency injection — внедрение зависимостей).

Размышляя над тем, как связываются зависимые элементы кода в JS через export / import, я пришёл к выводу, что не все зависимости в коде es6-модулей SOLID'ных приложений можно описать инструкциями import. Излагаю свои соображения, чтобы коллеги могли указать, где я ошибаюсь, или подтвердить мои выкладки.