В последнее время разработчики электроники испытывают трудности с поставками электронных компонентов. Одним из решений данной проблемы является переход на "исконно китайскую" элементную базу. Это решение подкупает ценой и доступностью, но пугает плохой документацией и небольшим количеством информации на понятных нам языках. В данной публикации расскажу о любопытном микроконтроллере на ядре RISC-V и сделаю простое первое устройство - датчик концентрации углекислого газа в воздухе/мигалку OLED дисплеем и светодиодом (куда ж без мигалки светодиодом). В репозитории размещен проект для тех, кто захочет воспользоваться данными наработками.

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

Я уже написал здесь много статей на тему прокси-протоколов и прокси-клиентов, которые очень сложно детектировать и заблокировать, и которые используют пользователи в Китае, Иране, Ираке, Туркменистане, и теперь вот в России (мы здесь в отличной компании, правда?). Но довольно часто мне в комментариях писали, мол, это все отлично, но мне нужен именно VPN для целей именно VPN - доступа в частные локальные сети, либо для соединения клиентов между собой, и желательно так, чтобы его не заблокировали обезьяны с гранатой. Поэтому сегодня мы поговорим именно о VPN.

Классические OpenVPN, Wireguard и IPSec отметаем сразу - их уже давно умеют блокировать и блокировали не раз. Модифицированный Wireguard от проекта Amnezia под названием AmneziaWG — отличная задумка, но есть одно но...

Здравствуйте вам каждому. Мы — Дмитрий и Павел, специалисты по тестированию в ITFB Group. В нашей работе, как и у любого тестировщика, есть много рутинных, однотипных задач. Делать их не хочется, но без них нельзя. К счастью, нам теперь могут помогать генеративные нейросети.

Мы решили исследовать возможности ChatGPT в нашей работе: чем он может быть полезен при составлении документации, написании тестовых сценариев и генерации автотестов. Конечно, это пока что не идеальный инструмент, но мы на своём опыте убедились, что в чем-то он уже может быть полезен многим тестировщикам.

Приглашаем под кат почитать про наш опыт.

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

Я получил это письмо на свой почтовый ящик для бизнеса еще в 2022 году, и оно попало прямиком в папку спама, как это и должно было быть...

Современные веб-приложения, даже простые на вид, часто подразумевают нетривиальную архитектуру, состоящую из многих компонент. В статье «Делаем современное веб-приложение с нуля» я рассказал, как она может выглядеть, и собрал для демонстрации простейшую реализацию на стеке из нескольких популярных технологий. В неё вошёл бэкенд, фронтенд, воркер для асинхронных задач и аж два хранилища данных — MongoDB как основная база и Redis как очередь задач. В «Делаем поиск в веб-приложении с нуля» я показал, как можно добавить полнотекстовый поиск, и подключил третье хранилище — Elasticsearch.

Всё это время для простоты разработки и отладки компоненты приложения запускались локально через Docker Compose. Но как развернуть такое приложение в настоящем продакшн-окружении? Как обеспечить горизонтальное масштабирование? Как раскатывать новые релизы без простоя? 

В этой статье мы разберёмся, как разворачивать многокомпонентное веб-приложение в кластере Kubernetes на примере его локальной реализации — minikube. Мы поднимем виртуальный кластер прямо на рабочем ноутбуке, разберёмся с основными сущностями Kubernetes, запустим и соединим между собой компоненты демо-приложения и обсудим, какие ещё возможности Kubernetes пригодятся нам в суровом энтерпрайзе. Если вы занимаетесь разработкой и слышали о Kubernetes, но ещё не имели возможности пощупать его руками — добро пожаловать под кат!

Добро пожаловать в мир инновационных подходов к тестированию программного обеспечения! В данной статье я хочу поделиться своим опытом использования ChatGPT — мощной модели искусственного интеллекта — для написания Unit‑тестов.

Так начал статью ИИ по моей просьбе составить вступление к эссе о том, как использовать ChatGPT при написании Unit‑тестов. Видимо, все‑таки придется писать самому, ибо градус пафоса зашкаливает, а высокопарность вызывает испанский стыд.

В этой статье я расскажу о своих наблюдениях и размышлениях при написании Unit‑тестов с помощью ChatGPT. Я рассмотрю, как использовать ChatGPT для генерации тестовых сценариев, формулировки вопросов о правильности кода, создания заглушек (moq).

Для начала давайте вспомним, что такое Unit‑тесты.

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

При построении запроса для написания Unit‑тестов следует учитывать несколько основных принципов, которые обеспечат эффективность и качество ваших тестов. Вот некоторые из них:

При реализации потоковой обработки и анализа данных может возникнуть необходимость агрегирования записей для объединения нескольких независимых поток данных или обогащения какой-либо модели данных. Для этой цели может использоваться Kafka Streams, которая позволяет выполнять обработку данных в режиме реального времени. 

В этой статье мы рассмотрим основные компоненты Kafka Streams и теоретические аспекты их использования. Мы будем использовать последние версии технологий, доступных на сегодня: Kafka 3.4.0 и Java 17 в качестве языка программированию. Для снижения входного порога мы будем использовать только нативные возможности Kafka и Kafka Streams, и не будем рассматривать решения с использованием различных фреймворков вроде Spring.

После рассказа о том, как я получил работу в Amazon, в этом посте на reddit мне задали множество вопросов о том, как мне помог LeetCode в подготовке к собеседованиям.

В статье я отвечу на эти вопросы.

Сколько времени это заняло?

Я начал готовиться за 2-3 месяца до собеседований в BigTech. В то время я тратил по 2-3 часа в день на подготовку.

Хотите избавиться от дублирования конфигураций и зависимостей Gradle в многомодульном проекте? В данной статье я расскажу свой способ от этого избавиться и упростить себе конфигурацию новых модулей.

Статья больше ориентирована на специфику Android, но может пригодиться и другим пользователям Gradle.

Предметно-ориентированный подход (DDD, Domain-Driven Design) в проектировании программного обеспечения является наиболее эффективным способом моделирования бизнес-процессов. Сегодня мы поговорим о стратегическом и тактическом проектировании, после чего рассмотрим инструмент ускорения проектирования под названием «событийный штурм» (event storming).

В этой статье будут рассмотрены инструменты наблюдения за сетевой инфраструктурой Kubernetes и основные составляющие Observability/Наблюдаемости – мониторинг, журналы событий, метрики, распределенная трассировка и оповещения. Обсудим, как эти инструменты могут помочь обеспечить надежную и эффективную работу кластеров Kubernetes и запущенных на них микросервисах, а также какие преимущества и недостатки существуют при использовании этих решений.

Эта статья для DevOps, Kubernetes administrators и SRE инженеров, которым важно и интересно разобраться в том, как устроена сетевая инфраструктура Kubernetes, какое взаимодействие происходит на уровне ядра Linux и различных приложений (Go, Java, Python и т.п.); изучить две обширные технологии eBPF и OpenTelemetry, активно продвигаемые CNCF сообществом. А главное при помощи каких инструментов можно упростить принятие решений инженерам при использовании Kubernetes в своих проектах и продуктах.

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

Один из признанных ИТ-сообществом ответов - это, так называемый Saga паттерн. О том, что это такое, написано достаточно много, а мы займёмся его реализацией. 

Java — настолько популярный и развитый язык, что контента на любую связанную с ним тему хоть отбавляй. Будь то технические разборы, обзоры популярных библиотек с открытым исходным кодом, статьи о поиске работы Java-программистом, сравнение с другими языками — всего не перечесть. Поиск по слову «java» в гугле выдал мне около 1,56,00,00,000 (?) результатов.

Привет! Меня зовут Глеб Гончаров, и я руковожу подгруппой ИТ-инфраструктуры в СберМаркете. В работе мы широко используем Kafka как шину данных для микросервисов и не раз убедились на практике, что к инструменту важно подобрать правильный подход. Об этом сегодня и поговорим в двух частях — сначала обсудим основы, а в конце статьи будет ссылка на практические задания.

Второй уровень (Layer 2, L2) - это любая офф-чейн сеть, система или технология, построенная поверх блокчейна (обычно известного как сеть первого уровня), которая помогает расширить возможности сети базового уровня. Сети второго уровня могут поддерживать любой блокчейн для внедрения таких улучшений, как например, более высокая пропускная способность транзакций.

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

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

В Domain-Driven Design выделяют стратегические и тактические паттерны. Например, первые — это Единый язык, а вторые — Агрегаты. Я много раз слышал от коллег, что со стратегией всё понятно, но когда дело доходит до перехода на тактический уровень (до кода) — всё в тумане. Это приводит к некорректным техническим решениям, которые не могут компенсировать даже правильный настрой и близость к бизнесу. Для успеха проекта крайне важно освоить тактические паттерны, особенно Агрегаты. Всё потому, что Агрегаты инкапсулируют в себя почти всю бизнес-логику, это основа вашего приложения. В этой статье я и расскажу про Агрегаты, как они могут помочь и почему важно их освоить. Но...