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

Банковские сервисы по умолчанию не должны падать, и даже прилечь на секундочку, и даже когда мы обновляемся. Ведь даже секунды могут привести к потерям с множеством нулей. Чтобы этого не произошло мы используем blue-green deployment.

Простым языком blue-green deployment - способ развертывания, который позволяет обновлять приложения не отклоняя ни одного запроса, без остановок. Как это сделать, расскажу и покажу на примере. Статья подойдет DevOps-инженерам и бэкенд-разработчикам, особенно на HighLoad-проектах, а также моим будущим коллегам, как методичка по безрисковым релизам, чтобы прод не падал каждые 2 недели по графику релизов (а такое тоже бывало).

Смоделируем ситуацию: у вас есть приложение на JVM (без разница, будь то Kotlin, Java или Scala), а еще у вас есть уверенность в себе и немного не хватает ответственности.

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

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

Мне кажется, любой уважающий себя программист на +- хобби проекте захочет навернуть нереально крутое самописное решение, чем, собственно говоря, я и занялся.

Всем привет! Добро пожаловать на презентацию об immutable infrastructure – достигая недостижимого идеала. Перед тем как мы начнем, хотел бы сделать небольшое вступление.

Ошибка в консоли вашего браузера

Эта статья является конспектом книги «От монолита к микросервисам». Материал статьи посвящен декомпозиции БД во время процесса разложения монолита на микросервисы.

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

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

Однако, прежде чем начнем разделять БД, мы должны рассмотреть трудности, связанные с управлением одной совместной БД.

19 декабря 2020 г. на Хабре вышла статья «Интуитивное объяснение интеграла».

В комментариях к ней некоторые пользователи указали, что объяснение получилось не очень интуитивным, например:

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

Но конкретно интегралы это такая тема, которую надо описать или короче, чем у вас, или намного дольше.
Иначе и школьник не поймет, и те, кто знает, ничего нового не откроют."

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

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

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

Подробный гайд о том, как работать с ботами — под катом.

Предисловие

Решил я что то сделать полезное. Был проект в котором мы должны были вместо старого сервиса сделать новый, но лучше. Сервис большой получился, 10к строк бизнесс-правил+код на джаве 15к строк. Сейчас уже раза в два больше. Но так как логики много и никто толком уже многого не помнит (за тем нас и призвали, что бы были тесты, доки и минимум багов) надо было сравнить старый сервис и новый. Что бы наши тестеры не умерли от старости, пытаясь все проверить я подумал и написал сервис, который дергал апи старого и нового, сравнивал и сливал разницу ответов в базу, что бы тестеры проверили и мы пофиксили разницу. Но вот проблема, на входе у нас много параметров и возможных их значений, это же миллиарды комбинаций будут, проверять несколько месяцев с полной нагрузкой, да и похожих много.
В итоге сначала была рождена идея взять и сократить возможные изменения параметров и вообще выкинуть некоторые из перебора, а потом была взята на вооружение Pairwise testing теория и она позволила закинуть все параметры и все значенеия и все проверить целиком.

Однажды я вел вебинар про то, как принимать 10 000 ивентов в секунду. Показал картинку, зрители увидели сиреневый слой, и началось: «Ребят, а зачем нам все эти кафки и рэббиты, неужели без них не обойтись»? Мы и ответили: «Зачем-зачем, чтобы пройти собес!»

Очень смешно, но давайте я все-таки объясню.

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

Для будущих студентов курса «Infrastructure as a code in Ansible» и всех интересующихся подготовили перевод полезного материала.

Также приглашаем записаться на открытый урок по теме «Управление Kubernetes при помощи Kubespray».

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

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

Публикую продолжение сборника вопросов-ответов с собеседований на Backend-Java-разработчика. В первой части мы прошлись по Java и Spring. А в этой поговрим о Hibernate, базах данных, паттернах и практиках разработки, об одной популярной библиотеке, поддержке и сопровождении наших приложений, а также посмотрим на альтернативные шпаргалки и подведём итоги.

Когда-то я проходил серию собеседований на Backend-Java-разработчика и записывал вопросы себе на будущее, чтобы потом можно было пробежаться и освежить память. Подумалось, что, вероятно, данный сборник будет полезен не только мне, поэтому сдул с него пыль, набросал ответов и делюсь с сообществом. На оригинальность и исключительность не претендую: подобные статьи уже были и на Хабре, и много где ещё — в конце (во второй части) приведу список ссылок, чтобы шпаргалка была максимально полной.

Точно установить сложность всех вопросов не берусь — на разном уровне их потребуется раскрыть с различной степенью подробности. Я написал ответы где-то на плюс-минус middle, щедро приправив ссылками для дальнейших изысканий. На самые популярные вопросы сразу перенаправляю в источники с готовыми ответами. Заодно посмотрим по ссылкам в статье, насколько Хабр может помочь в подготовке к собесам.

Текста получилось много, поэтому пришлось разбить на две части. В первой поговорим про Java и Spring, а обо всём остальном — во второй. Вторая часть тут

В данном руководстве мы рассмотрим подключение и настройку системы логирования в Spring Boot проекте и отправку логов в ELK с помощью Filebeat. Руководство предназначено для разработчиков начального уровня.

Логирование и зачем оно нужно

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

Следующий вопрос — это удобство доступа к логам. Обычно при локальном тестировании мы видим лог в консоли приложения, а на тестовым стенде — в специальных лог файлах на сервере. Удобно ли и безопасно ли каждый раз подключаться к стенду, искать нужную директорию и читать файлы логов оттуда? Практика показывает что нет и это вторая проблема которую призван решить ряд продуктов, обеспечивающих удобный доступ к логам и поиск в них важной информации. Сегодня мы очень кратко поговорим о одной из групп таких продуктов, так называемом стеке ELK (Elasticsearch — Logstash — Kibana) и более подробно о Filebeat — Open source продукте, обеспечивающем удобный механизм доставки логов до ELK.

HashiCorp показала новый проект Waypoint на HashiCorp Digital. Он использует файл на основе HCL для описания сборки, поставки и выпуска приложений для различных облачных платформ, начиная от Kubernetes и заканчивая AWS и Google Cloud Run. Можно представить, что Waypoint — это сложенные вместе Terraform и Vagrant для описания процесса сборки, поставки и выпуска ваших приложений.

Казалось бы, разработчики Terraform предлагают достаточно удобные best practices для работы с AWS-инфраструктурой. Только есть нюанс. Со временем количество окружений увеличивается, в каждом появляются особенности. Появляется почти копия стека приложений в соседнем регионе. И Terraform-код нужно аккуратно скопировать и отредактировать согласно новым требованиям или сделать снежинку.

Мой доклад про паттерны в Terraform для борьбы с хаосом и ручной рутиной на крупных и долгих проектах.