Проектирование и рефакторинг *

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

Спустя годы проекты обрастают тёмными местами, в которые никто не хочет соваться, поскольку их сложно понять и легко сломать. Сегодня мы посмотрим на кейс рефакторинга такого кода с переводом на ООП рельсы при помощи паттернов, причём со стилем (современным).

Привет, хабравчане!

В первой части были рассмотрены паттерны проектирования Repository и Unit of Work.

Это вторая часть цикла о DDD. В ней расскажу, как добавить к проекту событийно-ориентированную архитектуру.

Код подопытного приложения ищите в репозитории по ссылке. Подробнее о DDD и паттернах Repository и Unit of Work читайте в первой части по ссылке...

Первая часть серии - Проект «Статистика дрифта». Часть 1. Настройка
Паблик во ВКонтакте с новыми сериями без задержек выпуска на habr - Пихта DEV

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

Для реализации поставленной задачи был выполнен  пилотный проект, цель которого  ̶  получить 3D-модель генерального плана по данным лазерного сканирования. В качестве исходных данных выступило облако точек, а в качестве выходной информации  ̶  трехмерная модель генплана.

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

С одной стороны, это может быть и хорошо. Такие шаги стимулируют индустрию. Но всё же лучше понимать, что ты делаешь, иначе проекту можно сделать только хуже. В этой статье я обращаюсь к разработчикам, аналитикам и тестировщикам, которые еще не сталкивались с Kafka по работе. Помогу понять, почему все же в микросервисной среде многие не ходят просто по REST, а используют этот инструмент - что конкретно делает Kafka и когда есть смысл её применять.

Разработка PHP/VueJS пет-проекта "Статистика дрифта" в формате лайф-тайм блога.
Первая часть лфай-тайм блога написана про базовую настройку будущего приложения.

АльфаСтрахование взаимодействует с контрагентами, партнёрами, агентами и другими через различные системы документооборота, включая Диадок. Поскольку электронный документооборот (далее ЭДО) с контрагентами в системе Диадок хорошо соответствовал процессам, разработкой которых команда уже занимается, и у нас имеется опыт взаимодействия с другими внешними системами, решили создать интеграцию между системой электронного документооборота АльфаСтрахование (далее СЭД-АС) и системой Диадок. Об этой интеграции и пойдет речь в данной статье.

Приходят как-то на синк разработчик, тестировщик и time.sleep(1), а он им и говорит: ребята, мы что, в анекдоте?

→ Ну почти: они в подводке к статье про то, как тестировать мл системы, что бы не потерять $100k.

Upd: Поиском по "Upd" можно найти все корректировки, внесенные в статью после публикации в результате жаркой дискуссии в чате Effector.

Меня зовут Андрес, я руководитель команды разработки внутреннего UI-кита ВКонтакте. А это ещё одна статья про инструменты управления состоянием. Сегодня мы не будем изобретать ничего нового, а поговорим про библиотеку Effector.

TL;DR

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

В сети мало альтернативной информации про Effector, а действительно полезную трудно найти. Надеюсь, эта статья поможет немного исправить ситуацию.

(Внимание, под катом много картинок.)

Хочу поделиться нашим опытом модернизации "платёжного сервиса" – системы, которая дирижирует почти всеми нашими платежами. За год мы мигрировали с монолитного IBM WebSphere на событийную архитектуру на Java/Spring Boot, Apache Kafka и PostgreSQL. Решили проблемы с производительностью, масштабируемостью и подготовились к будущим вызовам.

Данная статья скорее написана мной для самого себя что бы помочь разобраться в книге Вона Вернона. По моему скудному мнению хоть в названии книги и фигурирует "Реализация" она не полностью поясняет все детали и понятия которыми оперирует автор. По сути эта статья рецензия + собственные заметки. Отчасти это одна из причин почему я решил написать статью именно тут а не в Notion исключительно для себя, возможно это может помочь следующему читателю более понятно погрузится в прочтение этой книги или более опытные читатели смогут поделится своими замечаниями касательно моих наблюдений.

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

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

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

Одно пространство имён для всего или же отдельные под каждую папку? Быть может, есть варианты интереснее? Рискнём и ступим на землю жестоких программистских баталий, в которых льётся цифровая кровь и рождается “истина”: какая из организаций пространств имён есть свет, а какая от лукавого.

Погрузимся вместе с техлидом и его подопечным в процесс ревью JavaScript кода и полностью отрефакторим его в функциональном стиле.

Привет! Меня зовут Анастасия. Я старший продуктовый дизайнер внутренних сервисов в Ozon Tech. Чтобы быстро решать вопросы клиентов Ozon, мы используем чат-ботов и постоянно их улучшаем. Такие боты встроены в клиентский чат, чат с продавцами, чат Ozon Travel и другие.

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

Сегодня мы рассмотрим, как реализовать так называемую event-driven архитектуру с использованием Rust.

Архитектура на основе событий (event-driven architecture, EDA) — это подход к созданию систем, где взаимодействие между компонентами системы происходит с помощью событий. Все это позволяет развязывать компоненты друг от друга и повышать их независимость, что, в свою очередь, увеличивает масштабируемость и гибкость системы.

Очень важно думать о том, чтобы приложения были надежными и защищёнными. Go — язык, который известен своей простотой и производительностью. Но ни один язык не безопасен сам по себе и об этом нужно заботится самостоятельно.

В этой статье мы поделимся с вами методами, которые помогут сделать ваши Go-приложения неприступными крепостями.

Долгое время разрабатывая микросервисы в разных командах, я сталкивался с типовой задачей: созданием максимально информативного ответа на запрос, когда произошла какая-то ошибка. Особенно это актуально для систем с пользовательским фронтендом, большим количеством интеграций или систем, которые представляют свой API как продукт. Во многих случаях это решалось выдачей сообщения «Ошибка системы» с HTTP-кодом 500. Из раза в раз меня не покидало ощущение, что решению этой задачи не уделяется должного внимания и времени. В текущем проекте нам пришлось пройти все круги ада, изменить несколько подходов и реализаций. И здесь я постарался описать, как это было, и сформулировать выводы, которые мы сделали на каждом шаге решения проблемы.