В этой статье рассказываем про распределенные транзакции - зачем они нужны в микросервисной архитектуре и какие у нас есть варианты реализации. Рассказ ориентирован на тех, кто не в теме - кому непонятно, зачем на простую транзакцию накручивать столько сложностей, это ведь удлиняет разработку и увеличивает количество точек отказа. Поясним зачем это нужно, приведем примеры проектов и немного пофилософствуем.
Одно пространство имён для всего или же отдельные под каждую папку? Быть может, есть варианты интереснее? Рискнём и ступим на землю жестоких программистских баталий, в которых льётся цифровая кровь и рождается “истина”: какая из организаций пространств имён есть свет, а какая от лукавого.
Погрузимся вместе с техлидом и его подопечным в процесс ревью JavaScript кода и полностью отрефакторим его в функциональном стиле.
Привет! Меня зовут Анастасия. Я старший продуктовый дизайнер внутренних сервисов в Ozon Tech. Чтобы быстро решать вопросы клиентов Ozon, мы используем чат-ботов и постоянно их улучшаем. Такие боты встроены в клиентский чат, чат с продавцами, чат Ozon Travel и другие.
В этой статье я расскажу о том, как мы с командой переработали конструктор, расширили круг его пользователей, с какими проблемами столкнулись и как решали их в условиях ограниченного времени.
Сегодня мы рассмотрим, как реализовать так называемую event-driven архитектуру с использованием Rust.
Архитектура на основе событий (event-driven architecture, EDA) — это подход к созданию систем, где взаимодействие между компонентами системы происходит с помощью событий. Все это позволяет развязывать компоненты друг от друга и повышать их независимость, что, в свою очередь, увеличивает масштабируемость и гибкость системы.
Очень важно думать о том, чтобы приложения были надежными и защищёнными. Go — язык, который известен своей простотой и производительностью. Но ни один язык не безопасен сам по себе и об этом нужно заботится самостоятельно.
В этой статье мы поделимся с вами методами, которые помогут сделать ваши Go-приложения неприступными крепостями.
Важное дополнение по итогам анализа комментариев и минусов к публикации.
С моей личной точки зрения - я за то, что бы всё , что не касается СУБД было вынесено из СУБД: бизнес-функции, агрегация, сортировка, ограничения и проверки корректности данных, ссылочная целостность - пусть рассчитывается и обрабатывается на уровне backend. Это позволит загрузить очень интересной работой современное поколение разработчиков , задействовать новые возможности фреймворков и ORM и позволит специалистам DBA сконцентрироваться на своей прямой работе - связанной с сопровождением и оптимизацией производительности СУБД. Если эта мысль не была понятна, прошу прощения. Теперь, наверное точки над i - расставлены.
Долгое время разрабатывая микросервисы в разных командах, я сталкивался с типовой задачей: созданием максимально информативного ответа на запрос, когда произошла какая-то ошибка. Особенно это актуально для систем с пользовательским фронтендом, большим количеством интеграций или систем, которые представляют свой API как продукт. Во многих случаях это решалось выдачей сообщения «Ошибка системы» с HTTP-кодом 500. Из раза в раз меня не покидало ощущение, что решению этой задачи не уделяется должного внимания и времени. В текущем проекте нам пришлось пройти все круги ада, изменить несколько подходов и реализаций. И здесь я постарался описать, как это было, и сформулировать выводы, которые мы сделали на каждом шаге решения проблемы.
Изначально этот материал планировался как урок в PHP-курсе по полиморфизму. Но он, в конце концов, перерос сам урок, и я решил сделать из него отдельную статью. В ней практически ничего PHP-специфичного, поэтому рекомендуется для прочтения всем без исключения.
Напомню, что модель классов PHP взята из Java. Наличие интерфейсов и всех сопутствующих элементов очень сильно влияет на способ организации кода в PHP. Этот способ часто отличается от того, как организуется код в JavaScript, Ruby или Python. И ещё больше отличается от таких языков, как Clojure или Elixir. И всё это на фоне того, что в каждом из этих языков есть ООП.
ООП в этих языках настолько разное, что PHP-программисты, попадающие в Ruby или JavaScript, не понимают, как так можно писать, ведь многие подходы противоречат их представлениям о мире. То же самое происходит и в обратной ситуации.
Так где же правда? Правда в том, что есть вещи, которые действительно определяют архитектуру кода. И это не структура классов, не наличие интерфейсов и не использование полиморфизма.
Возьмём тот же MVC. В нём говорится о слоях, об их задачах (зонах ответственности) и способе взаимодействия друг с другом. Это крайне важно для модульности. В модульной системе отсутствуют циклические зависимости. В MVC ничего не говорится про классы и ООП в целом, потому что между этими понятиями нет связи. Реализовать MVC можно в любом языке общего назначения, каким бы он ни был. То же самое можно сказать обо всех других архитектурных шаблонах.
Архитектура опирается на особенности среды, в рамках которой она применяется, а не на конструкции языка. Например, в вебе господствует HTTP, который построен вокруг концепции "запрос-ответ". Именно поэтому микрофреймворки разных языков выглядят так похоже, независимо от того, есть там ООП или нет: в каждом микрофреймворке есть запрос, ответ и обработчик ответа.
Подробнее о разработке я пишу в своем телеграм-канале организованное программирование. Присоединяйтесь если статья понравилась :)
О, таблица merchants2? Да, у нас закончились столбцы в merchants, поэтому мы сделали merchants2.Когда я начинал программировать в детстве, я не знал, что людям платят за программирование. Даже когда я закончил среднюю школу, я полагал, что мир «профессиональной разработки» выглядит совсем иначе, чем код, который я писал в свободное время. Когда мне посчастливилось устроиться на свою первую работу в сфере программного обеспечения, я быстро понял, насколько я ошибался и насколько был прав. Моя первая работа была испытанием огнем, и по сей день та кодовая база остается худшей и лучшей кодовой базой, в которой мне довелось работать. Хотя кодовая база навсегда останется запертой в проприетарных стенах той конкретной компании, я надеюсь, что смогу поделиться с вами некоторыми самыми забавными и страшными историями из нее.
Привет, хабравчане!
В серии статей расскажу, что такое DDD (domain-driven design) и какие у него преимущества и недостатки. Разберемся, когда применять подход и как сочетать его с FastAPI, популярным ASGI фреймворком на Python.
В этой части рассмотрим паттерны проектирования Repository и Unit of Work. С их помощью мы работаем через интерфейсы. Паттерны помогают в разделении кода на слои: основная логика приложения представляется внутренними слоями, а используемые технологии - внешними.
Я прочитал замечательную статью за авторством @rplacroixи загорелся идеей воплотить механики окружающей среды, подобные линейке игр Divinity: разлитую нефть можно поджечь, огонь можно потушить водой, а яд неожиданно взрывается от огня. Здесь я буду больше обращать внимание на реализацию в коде, чем на достоверную копию механик из игр Divinity. Я покажу некоторые кусочки кода с пояснениями, а в конце будет небольшая демонстрация прототипа игры с этой системой.
Сегодня я программирую на Raku. Raku — это молодой язык с длинной историей, сестринский язык к языку Perl. Я хочу продемонстрировать самые сильные стороны этого языка в контексте прототипирования игры и частично сравнить их с оригинальной статьей, языком имплементации которой был выбран Python. В течение статьи я буду оставлять раскрывающиеся блоки с объяснением тех или иных особенностей языка Raku, если вам интересно.
Всем привет! Меня зовут Дмитрий, я Frontend-разработчик в VK. В этой статье расскажу немного о том, как мы знакомились с замечательной архитектурой FSD (Feature-Sliced Design), как мы рефакторили свои проекты под неё. И, самое главное, что из этого вышло. Постараюсь заинтересовать вас, чтобы и вы смело её внедряли в свои проекты. FSD — это, пожалуй, то, чего так не хватало в Frontend-мире.
Ах, если бы пользователи всегда разбирались в предметной области и передавали в наши замечательные алгоритмы только допустимые данные… Но реальность беспощадна, и проверки аргументов — необходимость. В статье посмотрим, как определение своего значимого типа может с этим помочь.
Недавно попробовали со своим проектом пройти на акселератор. Создали еще давно очень простое решение: "Разработка отечественной платформы Умного дома и Интернета вещей на базе платы ESP32, а также создание соответствующего образовательного курса"
Если кому интересно, здесь актуальная информация.
Проектом заинтересовались в НТИ, понаслышке я слышал, что это дает: отобранные проекты, которые получат хорошие баллы на демо дне, получат субсидию из средств, которыми финансируется НКО организаторов. Нас пригласили в акселератор в рамках программы Архипелаг.
Если преакселерацию с другим проектом мы проходили раньше за 2 недели, а понаслышке я знаю, что в акселераторе могут готовить и месяцами, то здесь сроки были суперсжатые. Когда я получил приглашение по почте, то понял, что где-то уже полторы недели и остается. Я начал со сбора команды, ибо был бардак. Я наивно предполагал, что в такие сроки мы успеем собрать всех, кто заинтересовался на странице проекта какой-либо информацией. Пока я собирал контакты и всем писал, я параллельно привлекал команду из уже знакомых людей, с которыми мы сработались.
О неприступные стены удобной архитектуры растущего приложения сломано много копий. Это, в принципе, довольно предсказуемо. У всех нас свой бэкграунд, опыт разработки и способ работы с абстракциями. Что для одного чисто и понятно, для другого может быть сумбурно и перемешано. Я хочу рассказать о том выборе, который был сделан год назад и который за эти месяцы себя прекрасно показал.
Техники оптимизации функции авторизации в современных веб-приложениях.
В статье рассматриваются эффективные подходы к управлению точной авторизацией с использованием Amazon Verified Permissions (читай Cedar Engine). Вы узнаете о техниках пакетной авторизации и кэширования ответов, которые помогут значительно повысить производительность и отзывчивость приложений.
Часто задается вопрос: как эффективно и быстро обработать огромные объемы информации? Ответом на этот вызов стала концепция MapReduce, разработанная в недрах Google.
MapReduce — это парадигма программирования, созданная для обработки и генерации больших объемов данных с использованием параллельных распределенных алгоритмов. Основная фича проста: сначала данные разбиваются на небольшие части (фаза Map), а затем результаты этих частей агрегируются в финальный результат (фаза Reduce).
За последние три года размер данных Notion увеличился в 10 раз из‑за роста количества пользователей и объёмов контента, с которым они работают. Удвоение этого показателя происходило каждые 6–12 месяцев. Нам нужно было справиться со стремительным ростом размеров данных, соответствуя при этом постоянно растущим требованиям, которые выдвигали критически важные сценарии использования наших продуктов и аналитических систем. Особенно это справедливо в применении к новым функциям Notion AI. Для того чтобы решить эти задачи нам нужно было создать озеро данных Notion и обеспечить его масштабирование. Вот как мы это сделали.
