Почему масштабировать вообще сложно?

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

Основная причина тут в том, что как только вы начинаете изменять какую-то большую систему, она начинает разваливаться. Ну, за исключением тех случаев, когда у вас вообще всё на 100% покрыто тестами. Однако, в реальном мире история с покрытием тестами такова, что код современных приложений покрыт (в лучшем случае) примерно на 1%.

Может быть, 100% покрытие тестами — это реальность не только для библиотек, утилит или компиляторов (ведь мы можем формализовать их поведение математически), но и для веб-приложения? Да не, фигня какая-то...

Привет! Меня зовут Сергей, я один из разработчиков продукта «Сервис персонализации» в компании Sportmaster Lab, и в этом посте я расскажу про SonarQube – платформу для непрерывного анализа и измерения качества программного кода, разработанную компанией SonarSource.

Сейчас SonarQube является чем-то вроде отраслевого стандарта. В частности, это стандарт центра компетенций Sportmaster Lab. В своей работе SonarQube использует статический анализ кода: реальное его выполнение не требуется, так как анализируются именно «исходники». Предмет анализа этого инструмента — потенциальные ошибки и уязвимости, стандарты оформления кода, наличие тестов и уровень покрытия ими, а также дублирование кода и его поддерживаемость. SonarQube поддерживает большое количество языков программирования, его можно встраивать в конвейер CI/CD и в вашу среду разработки. А еще — файлы отчетов сторонних инструментов (Eslint, Stylelint, OWASP Dependency Check и многие другие).

В этой статье вы узнаете:

• как работать с SonarQube;

• как он может помочь вам в работе и сделать ваш код лучше.

Эта статья — мой сугубо личный опыт работы с SonarQube в качестве пользователя, поэтому я не буду останавливаться на таких «административных» моментах, как развертывание SonarQube, создание в нем нового проекта и настройка его интеграции с GitLab.

Привет! В рамках своей работы в beeline tech мы часто взаимодействуем с геоданными. Для решения проблем, связанных с хранением, обработкой и анализом большого объема распределенных пространственных данных, мы используем Apache Sedona (бывший Geospark). Мы — Денис Афанасьев, аналитик больших данных, и Женя Рыбалкин, инженер больших данных, под катом расскажем, почему выбрали именно этот инструмент и что он умеет. А чтобы показать, зачем вообще работать с геоданными, давайте возьмем пример расчета посещаемости хоккейных матчей в Москве, как-никак плей-офф в разгаре.

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

Следствием такого развития, как в количественном, так и в качественном плане, стал ощутимый рост того объёма данных, который все эти устройства генерируют. Ну и что нам с ними делать? Давайте разберемся на примере геоданных!

Зачем вообще кому-то нужны геоданные?

Все говорят про webpack-module-federation - микрофронты тут, микрофронты там.
— "А мы уже внедрили", "а мы уже построили микрофронтовую-архитектуру", "мы релизим независимо".

Но начинаешь расспрашивать, "а что сделали", "а как связали" - выходит что за всеми этими броскими фасадами скрывалось добавление вызова ModuleFederationPlugin(...) на уровне рядового потребителя, в лучшем случае с подстройкой конфигурации под локальный и продуктовый стенды. А независимые релизы - обычный авто деплой trunk'а.

На этом фоне доклады, повествующие о динамическом развертывании k8s pod'ов с версиями микрофронтов, указанных в заголовках браузера (на базе argo-cd) производят вау-эффект. Но даже все эти истории имеют один общий недостаток.

На вопрос:
— А как вы реализовали SSR?

Следует ответ:
— Мы не стали этого делать, у нас админка / дэшборд / MVP / *.