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

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

Реподжекинг или захват репозитория / перехват контроля над репозиторием — это особый вид атак на цепочки поставок. В этой статье поговорим о том, что это такое, каков риск и как можно себя обезопасить.

Этот тип атаки привлёк мое внимание из-за своего потенциального влияния на программное обеспечение с открытым исходным кодом. В этой статье я объясню, что такое захват репозитория и что можно сделать, чтобы оставаться в безопасности. Говоря вкратце: если вы получаете все свои программные зависимости из менеджера пакетов — например, npm или PyPI, то эта атака не может на вас повлиять. Если вы берёте зависимости напрямую с GitHub, нужно быть более осторожными, но есть простое решение — заблокировать определённый ID коммита. Я поясню, как это сделать, в нескольких наиболее распространённых сценариях.

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

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

Эта статья посвящена React Spring — библиотеке анимации на основе JavaScript. Мы рассмотрим её фичи, включая различные хуки и компоненты, и то, как использовать их в приложениях.

Эта статья отражает моё личное мнение и профессиональные взгляды, учитывающие различные точки зрения в сообществе Android-разработчиков. Кроме того, я регулярно просматриваю руководства от Google для Android.

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

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

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

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

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

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

• Предварительный просмотр
• Репозиторий

Получение данных с помощью HTTP-запроса — это фундаментальное действие веб-приложений. Возможно, вы делали такие вызовы в браузере, но Fetch API поддерживается в Node.js, Deno и Bun.

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

В этом руководстве мы рассмотрим разработку веб-приложения по созданию GIF-файлов из видеороликов.

Функциональные возможности приложения:
- Создание GIF из видео на YouTube с определённым временным диапазоном.
- Предварительный просмотр результата перед выполнением фактической конвертации.

Компоненты системы:
- Клиентская часть на React (Next.js)
- Бэкенд-сервер на Node
- Node как Service Worker
- В качестве брокера сообщений — RabbitMQ
- Для хранения данных — MongoDB
- Для хранения медиафайлов — Google Cloud Storage

Полный код проекта можно найти на github, а по этой ссылке посмотреть демо-версию приложения.

Микросервисная архитектура предполагает декомпозицию монолитного приложения на несколько полностью независимо развёртываемых и масштабируемых сервисов. За пределами этого базового определения, то, что представляет собой микросервис, может быть несколько субъективным. Хотя есть несколько проверенных в бою практик, принятых такими гигантами, как Netflix и Uber, которые всегда следует принимать во внимание. И я расскажу о некоторых из них. 

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

Также их можно представить как простые правила, которым следует мозг, чтобы обрабатывать поступающую информацию с минимальными затратами.

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

В нашем мире, где каждый релиз готовится в спешке, а сами релизы выходят на регулярной основе, что вы делаете, чтобы защитить своё программное обеспечение? Что вы можете сделать, какие вообще есть варианты?

С точки зрения того, что именно представляет собой CI/CD: непрерывная интеграция программного обеспечения — это процесс, целью которого является максимально проверенный дистрибутив.

Хотя характеристику «максимально проверенный» можно интерпретировать по-разному, я полагаю, что это сводится к использованию такого количества тестов, которое позволяет бюджет, а бюджет — это деньги и время.

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

Не так давно компания McKinsey опубликовала статью, в которой утверждалось, что они могут измерить продуктивность разработчиков. Этот текст вызвал определённый резонанс, но я не видел, чтобы кто-то подробно комментировал содержание. Я решил, что это будет полезно сделать.

Я буду писать так, как будто авторы обратились ко мне за технической рецензией на свою статью. Можете считать это открытым письмом.