Доклад Александра Макарова для Съесть собаку #10: PHP, 12/10/2017.
Тезисы:
- Что такое архитектура сайта и зачем она нужна
- Виноват ли фреймворк в плохой архитектуре
- Где выход из сложности и регрессий
- Что делать со сложным доменом
- Выводы.
Прагматичный подход к разработке гибких программных системAlexander Byndyu
В докладе рассматриваются практики, принципы и методики, позволяющие разработчикам создавать гибкое, легко масштабируемое программное обеспечение. Раскрываются принципы ортогональности, принцип DRY и др. Рассматривается энтропия в коде и как с ней бороться. Рассматриваются основные факторы, отличающие программиста-прагматика от обычного.
По материалам конференции .NET разработчиков http://www.dotnetconf.ru/Materialy/Pragmatichnii_podhod_k_razrabotke_gibkih_sistem
Менторская сессия для junior разработчиков #1
Программирование сильно шагнуло в перед за годы своего существования, но даже в современном программировании нам приходится возращаться к парадигмам и технологиям, которые уже считались устаревшими. Мы обсудим существующие парадигмы, разберемся в чем принципиальная разница, поймем когда какая более эффективна.
О спикере: Dmitry Moskalenko [CТО at WOXAPP]
● Опыт разработчика - 8 лет (web, Android, IoT)
● Опыт СТО - 4 года
● Основные языки программирования - Python, PHP,
Java
● Хобби - Machine learning, Deep learning, IoT, crossfit
● Глава орг. комитета IT Clubs Project (iOS, JS, PHP)
● Был ментором в IT школе
REQ Labs 2014. Smart Business Modelling: A Key to Success in Enterprise Autom...Alex V. Petrov
Приходя первыми на объект автоматизации, аналитики выполняют крайне ответственную работу по изучению, моделированию и предварительной оптимизации деятельности предприятия. Разнообразие созданных на сегодня подходов и языков описания бизнес-процессов способно вселить в начинающего и даже опытного специалиста веру в то, что инструменты и нотации можно выбирать наугад. Но не все «пути аналитика» ведут к успеху возложенной на него миссии.
Доклад «Умелое описание бизнес-процессов — залог успешной автоматизации» на наглядных примерах демонстрирует проверенную временем, но неоправданно малоизвестную в России методологию многоуровневого описания бизнес-процессов в целях их автоматизации. Вооружившись ею, читатели смогут легко и просто формировать наглядные модели процессов, понятные и значимые для основных заинтересованных сторон проекта; выявлять и описывать основные успешные сценарии выполнения бизнес-процессов; находить альтернативные и исключительные сценарии и задавать правильные вопросы, помогающие устанавливать мельчайшие нюансы будущей программной и внепрограммной реализации таковых.
Слайды для лекции о паттернах, что я давал в Aller Media Norge в 2019.
Ссылка на исходник на GDocs:
https://docs.google.com/presentation/d/1CL2umKOcEeBehJ_hFlaD7P5pdoey_trCTeSnd5TiBSI/edit?usp=sharing
UML2. Eleven Trivial Tips for BPMN Modellers [1.01, RUS]Alex V. Petrov
«Дорога в тысячу ли начинается с первого шага», — гласит китайская мудрость. Простые, правильные и понятные модели бизнес-процессов — своеобразный «знак качества», скреплять которым свою работу мечтает каждый профессионал-аналитик. Однако достижение нужного качества моделей у многих занимает годы непрерывной работы, а такой запас времени — непозволительная роскошь в стремительно развивающемся мире ИТ- и управленческого консалтинга. Многим не добавляет оптимизма и общепризнанный на сегодня открытый международный стандарт BPMN 2.0, допускающий чересчур много равновозможных решений одной и той же задачи в области моделирования.
В ходе общения с аудиторией на дискуссионном онлайн-семинаре Сообщества аналитиков UML2.Ru мы представили ряд простых способов повышения качества BPMN-моделей бизнес-процессов. Придерживаясь этих рекомендаций, вы вместе с участниками семинара сможете:
* унифицировать личную и командную технику моделирования процессов;
* добиться однозначного толкования моделей различными заинтересованными сторонами;
* преодолевать самые известные ограничения BPMN, не нарушая стандарт OMG и не выходя за рамки возможностей промышленных инструментов;
* заложить основу корпоративного соглашения о моделировании на описательном и аналитическом уровне.
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
Как гласит один из постулатов современной системной инженерии, любая сложная инженерная система есть иррациональное единство функции и конструкции, и информационные системы — не исключение.
Постичь внутреннюю онтологическую двойственность таких систем — значит научиться отчетливо видеть альтернативные пути удовлетворения потребностей заинтересованных сторон, осознанно, а не интуитивно различать ограничения и требования, элементы ИТ-архитектур и элементы ИТ-решений, идентифицировать внешние и внутренние интерфейсы систем в их надсистемах и многое-многое другое.
SPb BA & SA Night. Learning a New Business Domain [1.01, RUS]Alex V. Petrov
Известные и неизвестные приемы освоения новых предметных областей — обязательный инструмент в арсенале успешного аналитика. Именно им был посвящен II «Вечер системного и бизнес-анализа» в С.-Петербурге, прошедший 05 сентября 2015 г. Ключевые темы: индукция и дедукция, концептуальные модели и онтологии, разбор примеров, командная работа и менторство.
Прагматичный подход к разработке гибких программных системAlexander Byndyu
В докладе рассматриваются практики, принципы и методики, позволяющие разработчикам создавать гибкое, легко масштабируемое программное обеспечение. Раскрываются принципы ортогональности, принцип DRY и др. Рассматривается энтропия в коде и как с ней бороться. Рассматриваются основные факторы, отличающие программиста-прагматика от обычного.
По материалам конференции .NET разработчиков http://www.dotnetconf.ru/Materialy/Pragmatichnii_podhod_k_razrabotke_gibkih_sistem
Менторская сессия для junior разработчиков #1
Программирование сильно шагнуло в перед за годы своего существования, но даже в современном программировании нам приходится возращаться к парадигмам и технологиям, которые уже считались устаревшими. Мы обсудим существующие парадигмы, разберемся в чем принципиальная разница, поймем когда какая более эффективна.
О спикере: Dmitry Moskalenko [CТО at WOXAPP]
● Опыт разработчика - 8 лет (web, Android, IoT)
● Опыт СТО - 4 года
● Основные языки программирования - Python, PHP,
Java
● Хобби - Machine learning, Deep learning, IoT, crossfit
● Глава орг. комитета IT Clubs Project (iOS, JS, PHP)
● Был ментором в IT школе
REQ Labs 2014. Smart Business Modelling: A Key to Success in Enterprise Autom...Alex V. Petrov
Приходя первыми на объект автоматизации, аналитики выполняют крайне ответственную работу по изучению, моделированию и предварительной оптимизации деятельности предприятия. Разнообразие созданных на сегодня подходов и языков описания бизнес-процессов способно вселить в начинающего и даже опытного специалиста веру в то, что инструменты и нотации можно выбирать наугад. Но не все «пути аналитика» ведут к успеху возложенной на него миссии.
Доклад «Умелое описание бизнес-процессов — залог успешной автоматизации» на наглядных примерах демонстрирует проверенную временем, но неоправданно малоизвестную в России методологию многоуровневого описания бизнес-процессов в целях их автоматизации. Вооружившись ею, читатели смогут легко и просто формировать наглядные модели процессов, понятные и значимые для основных заинтересованных сторон проекта; выявлять и описывать основные успешные сценарии выполнения бизнес-процессов; находить альтернативные и исключительные сценарии и задавать правильные вопросы, помогающие устанавливать мельчайшие нюансы будущей программной и внепрограммной реализации таковых.
Слайды для лекции о паттернах, что я давал в Aller Media Norge в 2019.
Ссылка на исходник на GDocs:
https://docs.google.com/presentation/d/1CL2umKOcEeBehJ_hFlaD7P5pdoey_trCTeSnd5TiBSI/edit?usp=sharing
UML2. Eleven Trivial Tips for BPMN Modellers [1.01, RUS]Alex V. Petrov
«Дорога в тысячу ли начинается с первого шага», — гласит китайская мудрость. Простые, правильные и понятные модели бизнес-процессов — своеобразный «знак качества», скреплять которым свою работу мечтает каждый профессионал-аналитик. Однако достижение нужного качества моделей у многих занимает годы непрерывной работы, а такой запас времени — непозволительная роскошь в стремительно развивающемся мире ИТ- и управленческого консалтинга. Многим не добавляет оптимизма и общепризнанный на сегодня открытый международный стандарт BPMN 2.0, допускающий чересчур много равновозможных решений одной и той же задачи в области моделирования.
В ходе общения с аудиторией на дискуссионном онлайн-семинаре Сообщества аналитиков UML2.Ru мы представили ряд простых способов повышения качества BPMN-моделей бизнес-процессов. Придерживаясь этих рекомендаций, вы вместе с участниками семинара сможете:
* унифицировать личную и командную технику моделирования процессов;
* добиться однозначного толкования моделей различными заинтересованными сторонами;
* преодолевать самые известные ограничения BPMN, не нарушая стандарт OMG и не выходя за рамки возможностей промышленных инструментов;
* заложить основу корпоративного соглашения о моделировании на описательном и аналитическом уровне.
ITGM #5. System Duality and Its Practical Effect on Business Analysis [1.0, RUS]Alex V. Petrov
Как гласит один из постулатов современной системной инженерии, любая сложная инженерная система есть иррациональное единство функции и конструкции, и информационные системы — не исключение.
Постичь внутреннюю онтологическую двойственность таких систем — значит научиться отчетливо видеть альтернативные пути удовлетворения потребностей заинтересованных сторон, осознанно, а не интуитивно различать ограничения и требования, элементы ИТ-архитектур и элементы ИТ-решений, идентифицировать внешние и внутренние интерфейсы систем в их надсистемах и многое-многое другое.
SPb BA & SA Night. Learning a New Business Domain [1.01, RUS]Alex V. Petrov
Известные и неизвестные приемы освоения новых предметных областей — обязательный инструмент в арсенале успешного аналитика. Именно им был посвящен II «Вечер системного и бизнес-анализа» в С.-Петербурге, прошедший 05 сентября 2015 г. Ключевые темы: индукция и дедукция, концептуальные модели и онтологии, разбор примеров, командная работа и менторство.
Introduction
What are design patterns?
List of design patterns in Drupal 8 core
Patterns explanation in simple words
Usage examples from Drupal 8 core
https://drupalcampkyiv.org/node/59
Mad Stream продолжается!
Нам повезло пригласить нашего Senior Backend Разработчика, Solution Architect, Нурадила Алымкулова, поделиться знаниями с нами.
Нурадил работал в разработке разнообразных систем банка, телекоммуникационных компаниях - одним словом, в энтерпрайзах. Теперь Нурадил хочет поделиться своими огромным опытом и наблюдением в разработки сложных систем.
На этом стриме Нурадил выступит с темой “Проектирование архитектуры приложения 101” мы начнем с:
описания бизнес-требований с помощью последовательных диаграмм;
разберем классовые диаграммы;
опишем поведение программы с помощью флоу-диаграм.
На данном стриме мы пройдем путь создания приложения от начала до конца! После стрима у нас обязательно будет сессия вопросов и ответов.
Mad Stream начнется в 19.30, в этот четверг 12-го ноября!
Ссылка на трансляцию:
https://youtu.be/tKymOf3O9gc
Netpeak Group продолжает серию образовательных мероприятий — #NetpeakTalks в Одессе.
В рамках этих встреч у тебя будет возможность обсудить с практикующим спикером наболевшие темы, связанные с R&D, дизайном, менеджментом, интернет-маркетингом, QA, Customer Success, аналитикой и др. (все темы от встречи к встрече не повторяются и отличаются друг от друга).
Тема#3: Масштабируемое приложение на PHP
Краткий план:
1. Теория принципов и паттернов проектирования.
2. Примеры использования принципов и паттернов в коде (разберём какие "плюшки" даёт каждый случай).
3. Важность слабосвязанного кода (IoC).
4. Как "под капотом" работают IOC контейнера.
_____________________
Информацию об этом и следующих мероприятиях ты можешь отследить:
FaceBook: https://www.facebook.com/NetpeakTalks/
Телеграм: https://t.me/netpeaktalks
__________
Плейлист с выступлениями на YouTube: https://www.youtube.com/playlist?list=PL8LIMl0TjrcDtSS_lM5jqH-huK5FCq44A
__________
В данном докладе мы рассмотрим пять основных принципов дизайна классов в объектно-ориентированном проектировании, которые известны, как принципы SOLID. А также как обеспечить достаточный уровень гибкости, связанности, управляемости, стабильности и понятности кода.
INFOSYSTEMS. How to Measure Software Architecture [1.01, RUS]Alex V. Petrov
Прошедший в «Академии информационных систем» (г. Москва) семинар «Как измерить архитектуру ПО?» ответил на вопрос о том, реально ли оценить архитектуру программной системы и сказать, насколько она полна, качественна, подвержена тем или иным недостаткам. В ходе семинара слушатели узнали, какие архитектурные метрики существуют, какие из них — признаны отраслью, в чем состоит их польза и как подходить к их применению в условиях производства.
Классифицируем текст в iOS без CoreML: как и зачем? EatDog
Доклад Вячеслава Володько для Съесть собаку #16: iOS 21/03/2019
Тезисы:
- Классификация текстов с помощью встроенных в iOS SDK средств.
- Ограничения NLLanguageRecognizer и MLTextClassifier.
- Построение собственного классификатора текстов.
- Техники, которые позволяют встроить классификатор в AppExtension.
- Оценка эффективности классификатора.
macOS app development for iOS devs: expand your horizonsEatDog
Доклад Юлии Ващенко для Съесть собаку #16: iOS, 21/03/2019
Тезисы:
- Преимущества разработки под macOS для iOS программистов.
- UIKit vs AppKit.
- Подготовка к релизу Marzipan на наших платформах.
- Взгляд на macOS & iOS с точки зрения их истории.
- Технологии, специфичные для десктопа.
- Демо: Современное межпроцессорное общение.
- Бонус для iOS разработчиков, посетивших доклад.
Доклад Антона Минашкина для Съесть собаку #15, 27/11/18
Тезисы:
- Почему DI – такой популярный design pattern в Android;
- Что особенного в DI для Kotlin;
- Практическая польза и опции DI.
Быстрый в имплементации и в работе мониторинг с использованием ELKEatDog
Доклад Ивана Мельничука на "Съесть собаку"#14: PHP, 20/09/2018
Тезисы:
Как начать кастомно логировать приложение при минимальных усилиях;
Как выглядит готовый стек логирования ELK;
Немного о наболевшем или как доказать заказчику в чем проблема сайта;
Google Analytics семплирует данные, а вы можете узнать больше.
Доклад Евгения Кузьмина для "Съесть собаку" #14: PHP, 20/092018
Тезисы:
Построение процесса continuous integration/delivery на примере Laravel-приложения;
Структура организации авто-тестирования;
Интеграция запуска тестов и деплоя на CI сервере Jenkins;
Применение Docker в связке с AWS ElasticBeanstalk для blue-green деплоя.
Как мы экспериментируем в больших микросервисных системахEatDog
Доклад Александра Баранецкого для Съесть собаку #13, 14/06/2018.
Тезисы:
- Как сделать гибкой разработку на микросервисной системе, в которой более 100 узлов;
- Как минимизировать ошибки и их цену;
- Как мягко обеспечить миграции версий и эволюцию всей системы в целом.
Доклад Александра Котыни на Съесть собаку #13, 14/06/2018.
Тезисы:
- Зачем использовать Redis;
- Эволюция внедрения Redis в крупный проект и подводные камни при его использовании;
- Варианты достижения высокой доступности и отказоустойчивости;
- Наш сценарий.
Доклад Антона Немцева для Съесть собаку #12: JavaScript, 15/03/2018.
Тезисы:
- Зачем, ну зачем нам это?!
- Что именно мы ограничиваем и как выбираем кодстайл;
- Правила и ограничения при написании скриптов, стилей и рабочего процесса;
- Напишем свой собственный npm-пакет с целью особо изощренного насилия;
- Правила и ограничения для рабочего процесса на стороне систем контроля версий;
- Что дальше?
Refactor to Reactive With Spring 5 and Project ReactorEatDog
Доклад Олега Докуки для Съесть собаку #11: Java, 21/12/2017.
Тезисы:
- Проблемный обзор не реактивных приложений;
- Обзор реактивной архитектуры;
- Spring 5 в качестве ключевого решения;
- Spring 4 to Spring 5: пошаговый рефакторинг;
- Анализ результатов
- Демо.
Доклад Владимира Цукура для Съесть собаку #11: Java, 21/12/2017.
Тезисы:
- Обзор REST как архитектурного стиля;
- Всегда ли REST-образные API — это лучший выбор;
- Использование GraphQL в Java-контексте;
- API GraphQL: опыт WIX;
- GraphQL: где хайп, а где польза;
- Выводы: когда какой стиль API выбрать.
Доклад Ивана Мосева для Съесть собаку #10: PHP, 12/10/2017.
Тезисы:
- Места обитания: где разворачивать свои микросервисы
- Взаимоотношения в стае: как микросервисы общаются между собой
- Микросервисы и человек: авторизация пользователей и роутинг
- Содержание в неволе: как разрабатывать микросервисы локально
- Выводы.
Доклад Антона Молдована, Software Architect, для Съесть собаку #9, 15/06/2017.
Тезисы:
- Большая роль TDD и DI
- Проблемы с TDD и DI
- Суть альтернативного подхода Dependency Rejection
- Разрушительная перспектива с TDD without Mocks
- Выводы.
Доклад Сергея Калинца, Software Architect, для Съесть собаку #9, 15/06/2017.
Тезисы:
- Проблемы стандартного процесса разработки
- Понятие CI pipeline
- Решения для автоматизации сборки, тестирования и развертывания
- Инструменты для эффективной разработки
- Использование тестовых двойников в .NET
- Концепция "живого кода"
- Демонстрация применения современных библиотек и инструментов для эффективного написания кода.
Доклад Дмитрия Науменко для "Съесть собаку #8", PHP, 20/04/17.
Тезисы:
- Понятие DDD и его цели
- Концепции и паттерны применяемые в DDD
- Использование подходов DDD в разработке приложений
- Преимущества и недостатки
- Выводы.
Доклад Максима Гопея для "Съесть собаку #8", PHP, 20/04/17
Тезисы:
- Моделирование угрозы
- Виды атак и уязвимостей в коде
- Как проверять безопасность систем
- Выводы.
Нельзя просто так взять и сделать версионирование APIEatDog
"Нельзя просто так взять и сделать версионирование API"
Почему важно иметь версионирование и какие проблемы оно решает
Какие есть подходы к версионированию API
Какие инструменты и решения предоставляют популярные веб-фреймворки
Почему версионирование - это не просто и как решить возникшие трудности
Выводы
API в SAAS, с облаком и без: ресурсы, SLA, балансировка, расширяемостьEatDog
"Особенности SaaS под углом платного доступа к API и ресурсам"
Проблемный домен — введение в управление ресурсами SaaS решения
SLA и требования к отказоустойчивости
Алгоритмы балансировки запросов API
Расширяемость решения в облачной инфраструктуре
Вычислительная сложность задач и управлении запросами пользователей
Пути решения и выбор инструментов, расширение их возможностей
Выводы
2. О себе
• 8 лет занимаюсь фреймворком Yii и другим открытым
кодом.
• Параллельно работал над коммерческими проектами.
• Участвую в PHP-FIG.Автор нескольких книг и
rmcreative.ru.
• В этом году провожу эксперимент с Patreon.
9. Фреймворк — не архитектура.
Он не построит архитектуру за вас.
10. Фреймворк ничего не знает об элементах
вашего приложения и не может определить
интерфейсы для взаимодействия этих
элементов.
Но может дать начальный шаблон и
инфраструктуру.
В случае Yii это MVC.
13. Controller
• Принимает данные извне (GET, POST, консольный ввод).
• Отдаёт данные в нужном виде в Model и View.
• Не реализует логику, не занимается форматированием или
формированием ответа.
14. View
• Получает подготовленные контроллером данные.
• Форматирует данные для ответа.
• Никогда не работает с внешними данными, базой или
пользовательским вводом напрямую.
15. Model
• Не Model в Yii!
• Не ActiveRecord!
• M в MVC - не один класс, а целый доменный слой.
• Получает подготовленные контроллером данные,
обрабатывает их, возвращает результат.
• Никогда не работает с внешними данными или
пользовательским вводом напрямую.
• Не занимается форматированием или формированием
ответа.
27. Open-closed
Класс или модуль должен
скрывать детали реализации ,
но иметь чётко определённый
интерфейс, который позволяет
как использовать модуль или
класс , так и расширять его
наследованием.
28. Liskov substitution
- принцип об иерархии и
наследовании.
Классическое определение очень запутанное. Можно
проще.
Когда мы реализовываем новый класс, наследуясь от
существующего, новый должен быть с тем же интерфейсом
и вести себя абсолютно так же в тех же ситуациях. Так,
чтобы программа работала, если подсунуть ей как
родителя, так и наследника.
29. Interface segregation
Интерфейс не должен определять больше
функциональности, чем используется за один раз.
Это как Single Responsibility, только для интерфейсов.
Если интерфейс описывает более одной задачи,
разбиваем его на несколько интерфейсов.
36. • Служащие одной цели классы собираются в модули (Не
модули Yii! Не конкретные классы! Логические рамки).
• Внутри модуля используем его классы напрямую. Нет
смысла абстрагироваться.
• Используемые модулем классы, но не связанные с ним,
используются только через интерфейсы.
• Модулю наплевать на то, как он получит зависимости.
40. Active Record
• Делает одновременно слишком много.
• Притягивает к себе бизнес-логику (ей не место в
AR).
• Позволяет достичь цели очень быстро.
• Удобен.
43. Что описывать?
• Модули: структура компонентов.
• Компоненты и коннекторы: взаимодействие компонентов.
• Размещение: физическое распределение компонентов по
серверам.
52. Большие проекты (> 6 месяцев).
Цель — получить архитектуру, близкую к
реальному процессу, используя термины
реального процесса.
53. Структурные блоки
• Value object — значение, которое может включать в себя
другие значения.
• Entity — объекты, которые можно идентифицировать.
Взяв два объекта и сравнив их, можно определить, тот
же это объект или нет.
• Aggregate — группа объектов. Имеет главный Entity, без
которого вся группа не имеет смысла (root).
Транзакционно целостна.
55. Главные паттерны
• Repository — сохраняет чистые объекты и загружает их.
Чаще всего речь идёт про базу данных. Не AR!
• Доменный сервис — использует entity для какой-то
полезной работы. Всё ещё не зависит ни от чего вне
домена.
• Сервис приложения — предоставляется фреймворком
(components). Может использовать доменный сервис для
работы с доменом.
56. DDD действительно нужен
не часто
• Сложно.
• Оверхед.
• Абстрактно.
• Плохо натягивается на "бедный" домен.