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

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

Привет! Меня зовут Ваня, последние несколько лет я занимаюсь backend-разработкой в Сравни. Моя команда разрабатывает интеграции с сервисами наших партнёров, код пишем на PHP и Symfony Framework.

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

В этой статье я расскажу о том, как в Messenger-компоненте Symfony устроен механизм повторной обработки сообщений при ошибках (или по-простому – механизм ретраев), а также поделюсь опытом его использования и некоторыми важными нюансами его работы.

Привет, Хабр!

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

Redis и Memcached – два из самых популярных и мощных инструментов для реализации кэширования. Redis, изначально разработанный как in-memory хранилище данных, позволяет эффективно хранить и быстро извлекать информацию в памяти, что делает его идеальным выбором для кэширования. Memcached, с другой стороны, специализируется исключительно на кэшировании данных и предоставляет простой, но мощный способ ускорить доступ к данным.

Вопрос подготовки релизов и внесения новых изменений стоит перед любыми командами. Но чем масштабнее сфера применения каждого конкретного решения, тем важнее не допустить downtime, связанного с ошибками в новом функционале. В этом посте я расскажу о том, почему нам в Леруа Мерлен потребовалось развивать новый механизм работы с обновлениями, из-за чего не подошел ни один из популярных инструментов и что мы стали делать в итоге. Также мы обсудим различные подходы к организации функций Feature Toggle. Если вы тоже интересуетесь этой темой, приглашаю под кат!

В мае 2018 года Европа переключится на обновлённые правила обработки персональных данных, установленные Общим регламентом по защите данных (Регламент ЕС 2016/679 от 27 апреля 2016 г. или GDPR — General Data Protection Regulation). Данный регламент, имеющий прямое действие во всех 28 странах ЕС, заменит рамочную Директиву о защите персональных данных 95/46/ЕС от 24 октября 1995 года. Важным нюансом GDPR является экстерриториальный принцип действия новых европейских правил обработки персональных данных, поэтому российским компаниям следует внимательно отнестись к ним, если услуги ориентированы на европейский или международный рынок.

Новый регламент предоставляет резидентам ЕС инструменты для полного контроля над своими персональными данными. С мая 2018 года ужесточается ответственность за нарушение правил обработки персональных данных: по GDPR штрафы достигают 20 миллионов евро (около 1,5 млрд руб.) или 4% годового глобального дохода компании. В настоящей статье мы проанализировали новые правила обработки персональных данных в ЕС и сформулировали рекомендации для российских компаний по методам реагирования на GDPR.

По традиции, для самых жаждущих и нетерпеливых, эта статья будет о:

• С чего начинается построение любой архитектуры?

• За счет чего реализуются потенциальные бизнес возможности?

• Кто нужен для реализации намеченных возможностей?

• Как создать цифровые продукты, которые будут удовлетворять требованиям заказчиков, вписываться в намеченные сроки и бюджеты?

• Из чего должна складываться структура продукта и как он должен реализовывать функциональные требования?

Если нет интереса к предисловию, то переходите к первому "почему". Для тех, кто хочет сложить причинно-следственные связи - добро пожаловать.

Всем привет!

Меня зовут Михаил Копченин, я backend-разработчик сервиса биллинга #CloudMTS.

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

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

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

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

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

Код-ревью сам по себе - не панацея. Его можно построить так, чтобы помочь проекту. Но эта польза не гарантирована - полно примеров, которым код-ревью идет во вред. Поговорим о том, где здесь скрываются подводные грабли и как провести код-ревью лучше.

Мы в API отказались от большого количества unit-тестов в пользу большого количества интеграционных/системных, чтобы тестировать меньшим количеством кода большее количество функций, а также наблюдать за взаимодействием разных частей системы.

На самом деле мы просто решили писать тесты не на отдельные классы/методы, а на интерфейс api, которым пользуются клиенты - на сервисы этого API. Тестируя их, мы убиваем двух зайцев: проверяем логику работы сервисов api + форматирование результата.

А такое тестирование сопряжено с несколькими проблемами.

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

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

В последнее время все больше и больше набирает обороты тема "архитектура как код", имея в виду или управление архитектурой систем с помощью кода, или управление кодом архитектуры системы. Есть уже ряд ПО, в том числе Российского. Но не смотря на многочисленные, я бы даже сказал, баталии с авторами в группах Телеграмм, так и не понял, чего же там код и чего же там управление. Все как-то получается рисование диаграмм, описывая их кодом. Ну возможно - с динамической подгрузкой данных.
Вот и решил попробовать изложить свое понятие, что такое "управление архитектурой как кодом".

Сегодня в сообществе ИТ архитекторов, поддерживающих подход “Архитектура как код”, все чаще появляются упоминания о его перспективах выйти на уровень нового индустриального стандарта. Можно было бы сказать, что любое общество должно быть амбициозным и видеть себя в “Центре Вселенной”. Поэтому, не стоит об этом раньше времени статьи написывать. Но важно заметить, что архитекторы облечены ролью и должностью существенно влиять на решения о выборе стека и подходов в крупных компаниях. Поэтому, кажется, важно уже сегодня рассказать, что лежит в основе таких предположений.

• Именования переменных, классов и функций
• Вспомогательных функций
• Комментариев к коду
• Перечислений/словарей/запечатанных классов и так далее
• Упорядочивания и именования пакетов

Зависит ли эффективность от меньшего количества нажатий на клавиши?

• Мне или кому-то другому никогда не придётся читать или исправлять то, что я написал в прошлом
• Я нечасто забываю при чтении функции, в чём смысл одной или нескольких переменных
• Мне время от времени не приходится писать действительно сложный и запутанный код
• Я могу переименовывать функции, классы или свойства внешних библиотек с непонятными или нелогичными названиями во что-то более разумное

В последние годы PHP динамично развивался с появлением новых версий языка, содержащих ряд новых фич, депрекаций и более строгий синтаксис. Кроме того, библиотеки и фреймворки, такие как Symfony, постоянно претерпевают изменения: каждые полгода появляются новые минорные релизы, а каждые два года - мажорные, наиболее существенные. Для нас в Westwing очень важно регулярно обновлять имеющуюся кодовую базу, чтобы она оставалась работоспособной, безопасной и актуальной. К счастью, в сообществе PHP появилось множество инструментов, способствующих улучшению кодовой базы.

Представьте, что вы начали разработку нового Android-приложения. Поначалу особых проблем не будет. Вы реализовали лишь самые базовые функции. Экранов немного, и все они простые. Вам легко ориентироваться в коде. Вы бодро добавляете одну фичу за другой. Но со временем разработка усложняется: кода становится много, главный экран обрастает большим количеством UI-элементов и логики, экраны образуют сложные цепочки переходов. Приходится ломать голову, чтобы добавить что-то новое, не сломав ничего из старого. Скорость разработки падает. Знакомая ситуация?

Существует эффективный способ борьбы со сложностью — компонентный подход. Мы в MobileUp применили его в трех крупных Android-приложениях и теперь не представляем, как жили без него раньше.

Меня зовут Артур, я тимлид в компании MobileUp. Я помогу вам освоить компонентный подход. Постараюсь сделать это как можно проще и увлекательнее.

Вас ждет серия статей. Это первая из них — теоретическая. В ней мы рассмотрим, какие сложности встречаются в Android-приложениях, и почему MVVM и Clean Architecture не панацея против них. Я расскажу, что такое компонентный подход и в чем его преимущества. А в конце статьи будут ссылки на материалы для углубленного изучения.

Наткнулся на данную статью случайно, когда находился в очередном поиске ответа на вопрос "Как же так?!" в интернете. Автор данной статьи занимается мобильной разработкой, но тем не менее его наблюдения и выводы касательно владения кодом разительно перекликаются с моими:

Однажды я работал в одной компании, где девизом команды разработки была фраза «Ты владеешь тем, что пишешь». Это отлично мотивирует нести ответственность за любой написанный код. Но сказать проще чем сделать.

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