Рубрика «архитектура» - 19

В первой части представлена концепция Red Architecture — подход, упрощающий взаимодействие между компонентами в сложных системах, и предназначенная в первую очередь для клиентских приложений. Для полного понимания текущей статьи необходимо познакомиться с данной концепцией здесь.

Red Architecture — красная кнопка помощи для сложных и запутанных систем — часть 2 (пример с миллиардом ячеек) - 1

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

У нас есть клиетское приложение — редактор таблиц, в нём отображается лист таблицы. Экран у пользователя настолько большой, что на нём помещается 1 000 000 000 (один миллиард) табличных ячеек. Всё усложняется тем, что наш табличный редактор подключен к облаку для возможности совместного редактирования таблицы, поэтому изменения в любой из одного миллиарда ячеек “где-то в облаке” должны быть сразу же отображены нашему пользователю.

Паттерн Red Architecture позволяет реализовать данную функцию просто и с высокой производительностью.
Читать полностью »

Как знают держатели дебетовых банковских карт Райффайзенбанка, карта является лишь инструментом доступа к счету: она не имеет собственного баланса, по ней доступны только те средства, которые есть на текущем счете клиента. В этой статье мы расскажем об архитектуре технического решения, которое позволяет картам и счетам в нашем банке использовать единый баланс. И также вы узнаете о том, как был организован проект, который позволил нам эту архитектуру реализовать.
Читать полностью »

Red Architecture — красная кнопка помощи для сложных и запутанных систем - 1

В начале несколько слов о названии, почему Red?

Всё просто. Любому явлению, которое претендует на определённый уровень целостности, необходим идентификатор. На такой идентификатор люди ссылаются в обсуждениях и сразу становится понятно о чём речь. В случае с архитектурой не стоит делать попытку описать в названии суть, любая архитектура это сложная вещь. Поэтому — просто Red!

Наверное у кого-то возникнет вопрос — а зачем нужна ещё одна архитектура?

Основная суть всех архитектурных нововведений в уменьшении связей в коде, т.н. code decoupling. И как следствие, улучшение тестируемости, поддержки, упрощению ввода новых функций и т.д. Но пока ни одна архитектура не признана “идеальной”, остаётся много неприкладных проблем, над которыми программисты ломают голову. Предложения по улучшению архитектур будут продолжаться до тех пор пока “идеальная” архитектура не будет найдена, т.е., вероятно будут продолжаться всегда.

Задача Red Architecture — свести сложность реализации логики приложения к минимуму, оставляя при этом нетронутыми возможность применения и все преимущества других паттернов проектирования.

Red Architecture имеет один класс, необходимый для своей реализации, и четыре соглашения.

Red Architecture — красная кнопка помощи для сложных и запутанных систем - 2
Читать полностью »

Выбранный UI-фреймворк – вред. Архитектурные требования – профит - 1

Мы не замечаем, но услуги и продукты, которыми мы пользуемся, постоянно усложняются.

  • Войти в метро теперь – не просто кинуть пятачок, а приложить карту Тройка, записанную на телефон и учитывающую пересадку.
  • Позвонить по телефону и посмотреть телевизор – давно уже не провести два провода в квартиру и вносить фиксированную абонентскую плату, а triple play с кучей опций и возможностей.
  • Посмотреть дневник сына – на святое же покусились! – теперь можно с планшета, заодно ответив на комментарий классного руководителя о его неудовлетворительном поведении.

Ну и я уже молчу про всякие Tinkoff, Apple Pay, Google Now, умные дома и многое другое.

Как следствие, в любой компании растут IT-отделы. То, чем раньше занимались несколько десятков сотрудников, сейчас делают команды из тысяч и десятков тысяч человек (кстати, поделитесь в комментариях, как выросли ваши IT-отделы).

Такие большие команды вынуждены более ответственно подходить к выбору технологий, в том числе и UI-фреймворков. И вот вам вброс: неважно, какой UI-фреймворк выбран. И даже вредно ограничивать себя выбором одного фреймворка. Но абсолютно не вредно и даже необходимо следовать правилам использования этих фреймворков.
Читать полностью »

Поезда пригородного сообщение — электрички — остаются одним из самых массовых видов пассажирского транспорта в России. За год ими пользуются миллионы пассажиров, которые проезжают суммарно сотни миллиардов километров на тысячах электричек. Только в январе 2017 года, по данным столичного департамента транспорта, опубликованным в едином хранилище данных правительства Москвы (ЕХД), пассажиропоток пригородного железнодорожного транспорта составил 42,6 млн человек. Это выше на 4,1% по сравнению с показателями прошлого года.

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

Меня зовут Александр Подлевских, я ведущий инженер-разработчик компании Туту.ру, тимлид в команде электричек, и в статье расскажу про технические детали и сложности построения онлайн расписания, как все это работает, каким образом мы используем данные, предоставляемые РЖД, и как наши пользователи помогают нам поддерживать расписание в актуальном состоянии, не догадываясь об этом.

Опыт Туту.ру: Как устроено расписание электричек - 1
График движения поездов — это отображение процесса движения поезда в декартовой системе координат. В таком виде представляется график движения поездов на железной дороге.
Читать полностью »

Правила управления переменными в препроцессорах и методика переопределения настроек

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

Предыстория

В 2014 году в компании начали редизайн проекта и в основу вёрстки мы положили свежий на тот момент Bootstrap 3.0.1. Использовали мы его не как отдельную стороннюю библиотеку, а тесно заинтегрировали с нашим собственным кодом: отредактировали переменные под наш дизайн и компилировали кастомизированный Бутстрап из LESS исходников самостоятельно. Проект оброс собственными модулями, которые использовали бутстраповские переменные и добавляли в файл с настройками свои новые переменные.

В тот момент я думал, что это правильный подход.

Читать полностью »

Вот и подоспели материалы с фестиваля РИТ++ 2017. Мы выступили там с докладами по темам machine learning, front-end и mobile разработки и провели отдельный тематический блок, посвященный микросервисам. Под катом – видеозаписи выступлений на этой секции наших докладчиков и коллег из других компаний. Обязательно загляните, чтобы узнать о подходах к работе с микросервисами и интересных приемах, которые реально использовать для решения ваших задач.

Расставляем точки над микросервисами. Секция Avito на РИТ++ 2017 (Видео) - 1
Читать полностью »

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

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

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

image
Читать полностью »

image

Мы уже рассказали вам о хранилище Avito, картинках, медиапикере, но главный вопрос так и оставался нераскрытым: какая она, архитектура платформы, из каких компонентов состоит и какой стек использует. Вы просили рассказать об аппаратной составляющей Avito, используемой системе виртуализации, СХД и так далее — ну что же, отвечаем.
Читать полностью »

Чек-лист по выживанию сайта - 1

В последнее время я как-то подозрительно часто наблюдаю примитивнейшие однотипные и довольно легко решаемые проблемы на самых разных web-проектах. Разные базы, разные языки, разные сферы деятельности и схемы монетизации. Всех их объединяет одно — лозунг «бизнес не дает переписать». Продолжающийся или только-только оконченный этап рапид-разработки растущего и агрессивно отжимающего у конкурентов долю рынка проекта родил огромную кучу т.н. «говнокода». Сомнительные архитектурные решения либо уже приносят кучу проблем, либо обещают их в будущем, но работают. Поток новых требований не дает времени навести порядок даже в инфраструктуре, не говоря уже о коде. Если вам такая ситуация знакома — добро пожаловать под кат поностальгировать, поучиться чему-то новому и/или поучить нас. Кому поржать, а кому и поплакать.

«Это все только для хайлода» — скажет вдумчивый и прозорливый читатель. Плох тот веб-проект, который не мечтает стать популярным хайлодом.

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js