Эволюция корпоративных Web приложений. Молотков Андрей D2D Just.NETDev2Dev
Для многих enterprise-разработка ассоциируется с бесконечным унаследованным кодом, устаревшими технологиями и неповоротливыми монолитами. Использование подходов построения сервис-ориентированной архитектуры может существенно улучшить ситуацию. Мы пишем небольшие приложения с чёткой зоной ответственности и покрытием модульными тестами, используем современные протоколы OData и OAuth, а legacy-приложения развиваем подключением повторно используемых модулей. В своем докладе я расскажу о том, чего удалось добиться за последние пару лет, какие роли мы выделили и с какими сложностями столкнулись.
Как мы данные готовили ORM и все-все-все в приложении Почта Mail.Ru / Кирилл ...Ontico
1. Описание предметной области, объектов и понятий, с которыми работает приложение.
2. Выделение сущностей и связей между сущностями, представление в терминах ORM.
3. Описание конфигурации ORM и ObjectCache.
4. Работа с БД
- применение паттерна Команда и Компоновщик для выполнения операций на БД;
- конфигурация исполнителя команд;
- команда как транзакция в БД;
- инструменты, доступные ORMLite для реализации транзакций.
5. Проблема доступа из UI потока к данным, изменяемым в других потоках.
6. Memoization подход для решения проблемы доступа из разных потоков.
7. Описание архитектуры кэшей с применением memoization.
8. Задача поддержания когерентности кэшей;
- использование HaMeR framework для актуализации UI кэша;
- использование механизма блокировок и батч-операций над данными в кэшах.
9. Ограничения ORM ObjectCache при работе с объектами DAO.
10. Реализация DAO с расширенными возможностями работы с ObjectCache.
Алексей Лустин. Непрерывная проверка качества кода.ScrumTrek
Я расскажу о нашем двухлетнем опыте использования инженерной практики «Continious Inspection» и платформы SonarQube при организации кросс-языковой разработки в процессе «непрерывной поставки» (CI-CD для языков Java, C#, JavaScript, typeScript и Gherkin) при автоматизированном code-review.
Доклад Сергея Аверина на DevConf 2013. "Распространенные ошибки применения ба...Badoo Development
Доклад не про БД в чистом виде а про архитектуру веб-приложений, использующих БД.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
Подробно:
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, которые потом в реальной жизни никогда не понадобятся.
• Или проектируется архитектура, которая якобы дает отказоустойчивость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологическая» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки событий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и небольших команд, техническим руководителям.
Badoo — это большая социальная сеть с более чем 180 млн. пользователей. Большинство новых фич в нашей компании мы предварительно оцениваем посредством A/B тестирования. Вот уже примерно год мы используем собственный высоконагруженный фреймворк тестирования, при этом по моему мнению он очень прост, понятен, и не требует огромных ресурсов на разработку и поддержку. В докладе я расскажу вам о том, почему мы пришли к собственному решению, его архитектуру и принципы работы. Я уверен, каждый из вас может сделать что-то подобное для своего проекта и начать принимать более обоснованные решения.
Тезисы:
* Как мы раньше тестировали
* Почему мы сделали свой инструмент
* Архитектура: API, граф. интерфейсы, транспорт, скрипты, БД
* Структура теста
* Основные правила А/Б тестирования
* Оценка результатов, примеры отчетов
* И заключительная часть про то, что от человека с головой полностью не избавиться
Для кого доклад:
Для разработчиков и техн. менеджеров соц. сетей, сайтов объявлений, блогов с рассылками, проектов, продающих что-то через e-mail расслыки, разных коммьюнити-сайтов, банков и вообще проектов, где взаимодействие с каждым клиентом долгосрочное.
Сложность:
Несмотря на то, что конференция называется Highload++, я уверяю, что представленную здесь архитектуру может потянуть проект с посещаемостью в 1000 чел в день и тремя программистами в штате. Закодить все, что здесь рассказано на PHP займет меньше недели одного человека. А результат, между прочим, пожно вполне изменрять в живой прибыли.
Антон Бевзюк; Матвей Григорьев. Domain Driven Design: строительные блоки, цем...ScrumTrek
Мы знаем, как важно разговаривать с бизнесом на едином языке и отражать эти знания в коде. Но как отразить эти знания в объектах максимально просто? Из каких блоков построить удобный домен? В докладе мы разберемся с Сущностями, Репозиториями, Value-объектами, Сервисами и другими типами объектов, упрощяющими создание доменной модели. Осторожно: много кода и технических деталей. Разработчики всех мастей, ждем вас. Менеджеры, вас ждет секция про мотивацию и подбор команды :)
Порядок для скорости. Система структурирования фронтендовой части веб-приложе...Ontico
Расскажем о системе структурирования и версионности фронтендовой части веб-приложений:
• как вести учет поколений и версий дизайна;
• как проводить анализ консистентности фронтенда;
• как построить автоматическую систему документации по элементам;
• насколько такой подход влияет на общую скорость разработки.
Система структурирования фронтенда в Superjob - это более 200 элементов и 2000 представлений.
Видео: http://www.youtube.com/watch?v=vz0U3jQpHSM
Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят.
Эволюция корпоративных Web приложений. Молотков Андрей D2D Just.NETDev2Dev
Для многих enterprise-разработка ассоциируется с бесконечным унаследованным кодом, устаревшими технологиями и неповоротливыми монолитами. Использование подходов построения сервис-ориентированной архитектуры может существенно улучшить ситуацию. Мы пишем небольшие приложения с чёткой зоной ответственности и покрытием модульными тестами, используем современные протоколы OData и OAuth, а legacy-приложения развиваем подключением повторно используемых модулей. В своем докладе я расскажу о том, чего удалось добиться за последние пару лет, какие роли мы выделили и с какими сложностями столкнулись.
Как мы данные готовили ORM и все-все-все в приложении Почта Mail.Ru / Кирилл ...Ontico
1. Описание предметной области, объектов и понятий, с которыми работает приложение.
2. Выделение сущностей и связей между сущностями, представление в терминах ORM.
3. Описание конфигурации ORM и ObjectCache.
4. Работа с БД
- применение паттерна Команда и Компоновщик для выполнения операций на БД;
- конфигурация исполнителя команд;
- команда как транзакция в БД;
- инструменты, доступные ORMLite для реализации транзакций.
5. Проблема доступа из UI потока к данным, изменяемым в других потоках.
6. Memoization подход для решения проблемы доступа из разных потоков.
7. Описание архитектуры кэшей с применением memoization.
8. Задача поддержания когерентности кэшей;
- использование HaMeR framework для актуализации UI кэша;
- использование механизма блокировок и батч-операций над данными в кэшах.
9. Ограничения ORM ObjectCache при работе с объектами DAO.
10. Реализация DAO с расширенными возможностями работы с ObjectCache.
Алексей Лустин. Непрерывная проверка качества кода.ScrumTrek
Я расскажу о нашем двухлетнем опыте использования инженерной практики «Continious Inspection» и платформы SonarQube при организации кросс-языковой разработки в процессе «непрерывной поставки» (CI-CD для языков Java, C#, JavaScript, typeScript и Gherkin) при автоматизированном code-review.
Доклад Сергея Аверина на DevConf 2013. "Распространенные ошибки применения ба...Badoo Development
Доклад не про БД в чистом виде а про архитектуру веб-приложений, использующих БД.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
Подробно:
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, которые потом в реальной жизни никогда не понадобятся.
• Или проектируется архитектура, которая якобы дает отказоустойчивость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологическая» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки событий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и небольших команд, техническим руководителям.
Badoo — это большая социальная сеть с более чем 180 млн. пользователей. Большинство новых фич в нашей компании мы предварительно оцениваем посредством A/B тестирования. Вот уже примерно год мы используем собственный высоконагруженный фреймворк тестирования, при этом по моему мнению он очень прост, понятен, и не требует огромных ресурсов на разработку и поддержку. В докладе я расскажу вам о том, почему мы пришли к собственному решению, его архитектуру и принципы работы. Я уверен, каждый из вас может сделать что-то подобное для своего проекта и начать принимать более обоснованные решения.
Тезисы:
* Как мы раньше тестировали
* Почему мы сделали свой инструмент
* Архитектура: API, граф. интерфейсы, транспорт, скрипты, БД
* Структура теста
* Основные правила А/Б тестирования
* Оценка результатов, примеры отчетов
* И заключительная часть про то, что от человека с головой полностью не избавиться
Для кого доклад:
Для разработчиков и техн. менеджеров соц. сетей, сайтов объявлений, блогов с рассылками, проектов, продающих что-то через e-mail расслыки, разных коммьюнити-сайтов, банков и вообще проектов, где взаимодействие с каждым клиентом долгосрочное.
Сложность:
Несмотря на то, что конференция называется Highload++, я уверяю, что представленную здесь архитектуру может потянуть проект с посещаемостью в 1000 чел в день и тремя программистами в штате. Закодить все, что здесь рассказано на PHP займет меньше недели одного человека. А результат, между прочим, пожно вполне изменрять в живой прибыли.
Антон Бевзюк; Матвей Григорьев. Domain Driven Design: строительные блоки, цем...ScrumTrek
Мы знаем, как важно разговаривать с бизнесом на едином языке и отражать эти знания в коде. Но как отразить эти знания в объектах максимально просто? Из каких блоков построить удобный домен? В докладе мы разберемся с Сущностями, Репозиториями, Value-объектами, Сервисами и другими типами объектов, упрощяющими создание доменной модели. Осторожно: много кода и технических деталей. Разработчики всех мастей, ждем вас. Менеджеры, вас ждет секция про мотивацию и подбор команды :)
Порядок для скорости. Система структурирования фронтендовой части веб-приложе...Ontico
Расскажем о системе структурирования и версионности фронтендовой части веб-приложений:
• как вести учет поколений и версий дизайна;
• как проводить анализ консистентности фронтенда;
• как построить автоматическую систему документации по элементам;
• насколько такой подход влияет на общую скорость разработки.
Система структурирования фронтенда в Superjob - это более 200 элементов и 2000 представлений.
Видео: http://www.youtube.com/watch?v=vz0U3jQpHSM
Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят.
Tech Talks @NSU: Рассказ о разных профессиях в IT-индустрии, или почему не вс...Tech Talks @NSU
http://techtalks.nsu.ru
20 февраля 2013. Рассказ о разных профессиях в IT-индустрии, или почему не все выпускники IT-специальностей пишут код (Семён Факторович, Noveo)
«Семен Факторович (Noveo, Новосибирск) рассказывает о разных профессиях в IT-индустрии и о вариантах карьерного роста IT-специалиста»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
DevOps Fest 2020. Максим Безуглый. DevOps - как архитектура в процессе. Две к...DevOps_Fest
Сотни вопросов о структуре и процессах, которые ставят и решают архитекторы и практики DevOps на примере решений в своем проекте.
Взаимоопределяющие вопросы архитектуры, DevOps, бизнеса и разработки.
Взрыв сложности - представьте, что вместо простого gmail подобного почтового SPA вам нужно построить и развивать новый sendmail на сервере + thunderbird для клиентов (desktop, мобильную и веб версию) по SAAS multi tenant модели.
2. Задачи
• Повысить скорость разработки новой функциональности без
ущерба для существующей
• Снизить время подключения нового специалиста
• Повысить bus factor
• Повысить качество планирования, «усреднить»
производительность членов команды
• Снизить количество багов и регрессии в каждой итерации
4. Интересные факты
• «Сделать продукт» – в 6 раз дольше, чем «написать код»
• Норма рисков в разработке ПО 250%-300% (поэтому нормальный
fixed price – дорогой, а не нормальный – рискованный)
• Код в 10 раз чаще читают, чем пишут
• Производительность разработчиков по разным данным
отличается в 6-28 раз
• Регрессионное тестирование может никогда не закончиться
• Для разработки ПО нет хороших стандартов или ГОСТов
7. B for Behavior
• Вы моделируете предметную модель, а не структуру ORM
• Вы не делаете пустых конструкторов
• Вы не пренебрегаете инкапсуляцией
• Вы определяете поведение, а не структуру хранения
8. Ключевые термины DDD
• Bounded Context
• Ubiquitous Language
• Entity
• Value Object
• Specification
9. DDD
• ОЧЕНЬ дорого
• Работает хорошо в устоявшихся бизнес-процессах
• Иногда – это единственный способ сделать то, что нужно
• Плохо масштабируется
• Сложно реализовать в высоконагруженных приложениях
• Плохо работает в стартапах
• Не подходит для построения отчетов
• Требует особого внимания с ORM
• Слова Entity лучше избегать, потому что его все понимают по своему
• С LINQ стандартная реализация Specification «не работает»
12. Вам скорее всего
не нужен Event Sourcing
• Мы вообще не обсуждаем эту тему сегодня, потому что вы скорее
всего не разрабатываете ПО для банка
• А если разрабатываете, то у вас уже есть Audit Log и нет нужды
рассказывать то, что вы уже знаете
14. In / Out
• Принимает на вход и возвращает DTO (желательно immutable), а
не доменные объекты
• В отсутствии команд Query всегда возвращает одинаковый
результат
• Команды изменяют состояние системы
16. CQRS over HTTP
• GET– это Query
• POST/PUT/PATCH/DELETE – это Command
17. CQRS
• Event Sourcing требует CQRS, но не наоборот
• Дешево
• Подходит везде
• Масштабируется
• Не требует 2 хранилища данных. Эта одна из возможных реализаций, а не
обязаловка
• Обработчик команды может возвращать значение. Если не согласны
спорьте с Грегом Янгом и Дино Эспозито, а не со мной
• Если обработчик возвращает значение он хуже масштабируется, однако есть
async/await, но надо понимать как они работают