Семинар Web Application Arthitecture

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

Веб-семинар

Семинар проходил в образовательном центре IBB, в котором я до этого ни разу не был и который мы с таксистом с трудом нашли :). Здание выглядит необычно, а внутри встречает приятной обстановкой и мягкими яркими диванами.

Заявленную аудиторию нашел быстро, хотя, как оказалось, ее заменили на соседнюю – чуть более просторную. Оставив вещи, пошел на вход встречать участников семинара и направлять их в нашу аудиторию. Первым пришел Володя – ведущий семинара, ну а за ним стали подтягиваться и остальные. Перед началом мероприятия каждый из участников получил бедж для распознавания друг друга и блокнот с ручкой для записывания умных мыслей. Блокнотами я обычно не пользуюсь, но в этот раз исписал его почти до половины – информационный поток просто зашкаливал!

Пару слов о Владимире Лешкевиче, ведущем семинара. У Володи за плечами 14 лет профессиональной разработки ПО; начав простым разработчиком, он прокачался до технического директора, попутно успев побыть и техлидом, и менеджером. Он занимается обучением и коучингом проектных команд по различным технологическим направлениям и процессам разработки. Проработав с Володей некоторое время на реальном проекте, я ожидал от семинара многого, и, конечно, мои надежды оправдались на все 200% - субъективно для меня это был лучший IT день за прошедшие несколько лет.

Все началось, как в первом классе – с представления себя и своего рода деятельности. Уровень участников был очень высокий – не припомню никого ниже senior software engineer. Что приятно удивило – среди участников было два человека из Могилева, специально приехавшие в Минск на семинар.

Участники

Выступления Володя проводил по четырем основным темам:

  1. Архитектура веб-приложений;
  2. Сервисно-ориентированные архитектуры;
  3. Объекты-значения в DDD;
  4. Производительность и масштабируемость веб-приложений.

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

Архитектура веб-приложений

Первой рассмотренной темой была «Архитектура веб-приложений» - наверное, самое простое, что было обсуждено в этот день. Выступление началось с опроса – что интересует участников? Основные интересующие моменты таковы:

  1. Как и где проводить границу между Model, View и Controller в паттерне MVC?
  2. Как разделять серверную и клиентскую части приложения?
  3. Как бороться с разрастанием веб-приложений?

Для начала Володя рассказал о возникновении паттерна MVC и о его первоначальном значении, которое было заложено в языке SmallTalk. Для наглядности был продемонстрирован маленький пример на том же SmallTalk, в котором изящно связывались данные с представлениями – лично меня эта кодинг-сессия приятно удивила и вызвала интерес к продемонстрированному языку. Как оказалось, большинство современных MVC фреймворков (ASP.NET MVC, Ruby on Rails, etc.) очень удалились от оригинальной концепции и выдают за MVC то ли MVP, то ли еще что другое.

Такой понятный непонятный mvc

Затем Володя представил основные проблемы веб-приложений, исходящие из модели Request-Response, заложенной в основу Веба. Существуют решения этих проблем, например, AJAX, но и они не всегда удовлетворяют требованиям и не до конца прячут низлежащий уровень от программиста и пользователя – во многом из-за проблем совместимости браузеров.

Далее была представлена эволюция паттерна MVC:

  1. Оригинальная концепция
  2. MVC model 1: Page = View + Controller, где были тесно связаны View и Controller
  3. MVC model 2: архитектура с Front Controller, Filter Chain и кучей Actions для обработки запросов.
  4. MVCS – MVC на сервисах

Для решения возникающих из-за модели Request-Response проблем стали создаваться различные фреймворки, такие как JSP, ASP. Для имитации десктопного программирования появились компонентные фреймворки ASP.NET, JSF, Tapestry, Wicket. Однако все эти фреймворки в полном соответствии с законом протекающих абстракций не давали полной изоляции и в случае проблем приводили к появлению непонятных ошибок с тяжелыми последствиями.

Проблему модели Request/Response попытались решить созданием отдельного класса приложений с «тяжелым» клиентом – Rich Internet Applications. Модель Request/Response была явно выделена в качестве отдельного компонента для связи с сервером и облегчения создания пользовательских интерфейсов. (Кстати, следует отметить один из принципов Володи – “Be Explicit!”. По нему любая неявно выраженная логика/абстракция/понятие скорее всего приведет к проблеме, которой можно было бы избежать, явно выделяя неявную концепцию.)

На данный момент популярными являются следующие RIA фреймворки:

  1. Flex/Flash
  2. Silverlight
  3. Java FX
  4. GWT – здесь, кстати, опять выскакивает закон протекающих абстракций: Java код компилируется в JavaScript, что может привести к необычным ошибкам, которые Java сама по себе вызвать не могла.

Одним из важнейших критериев качества UI фреймворков Володя считает testability – возможность тестирования написанного кода. Чаще всего для тестирования систем используются unit тесты и интеграционные тесты. На стороне unit тестов стоят скорость выполнения, простота написания и покрытия. На стороне интеграционных тестов – польза тестирования нескольких компонентов сразу, за что, правда, приходится расплачиваться значительно возрастающей сложностью тестов. Эту сложность можно преодолеть с помощью инструментов интеграционного тестирования:

  1. Selenium
  2. Fit
  3. HttpUnit

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

Как оказалось, и в стане RIA фреймворков не все так просто – вышеупомянутый оригинальный MVC нигде не встречается, везде идут лишь местные замены. К чему это приводит программиста? К необходимости постоянно дописывать свои каркасы на основе базовых классов фреймворков. Часто в качестве замены MVC используется паттерн MVP (Model – View – Presenter) – главное его отличие от MVC заключается в том, что в MVP презентер может давать команды View, а не передавать команды лишь через модель, как в оригинальном MVC.

Далее Володя продемонстрировал очередную кодинг-сессию. На этот раз мы увидели реализацию паттерна MVP на языке Java: маленькое консольное приложение действительно отлично работало и исправно конвертировало переданные ей на вход валюты :)

Кофе-пауза

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

Кофа, кофа!

Сервисно-ориентированная архитектура

Второй темой выступления была «Сервисно-ориентированная архитектура». Для старта мы рассмотрели основные критерии сервиса:

  1. Автономный;
  2. Имеет явные границы;
  3. Имеет явный контракт для взаимодействия;

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

Сервисы, как и паттерн MVC, оказались богаты на историю:

  1. RPC – Remote Procedure Call – наверное, первое, что использовалось для подобных целей
  2. XML-RPC – формализация RPC, использующая XML в качестве основного формата передачи данных
  3. Web Services – SOAP формат на основе XML.
  4. REST – Representational State Transfer
  5. SOA – сервисно-ориентированные архитектуры

Далее Володя представил плюсы и минусы SOAP Web Services. Плюсы:

  1. Открытые стандарты и протоколы
  2. Четко выверенный и разделенный интерфейс
  3. Service discovery
  4. Богатый набор инструментов
Минусы:
  1. Сложность и протекающие абстракции
  2. Несовместимость
  3. Производительность
Альтернативой SOAP WS являются REST WS:
  1. У каждого ресурса есть свой URI, по которому они доступны
  2. Представления – то, что идет вовне и видно всем
  3. Переходы состояний:
  • GET – получить
  • POST – создать
  • PUT – обновить
  • DELETE – удалить
  • Плюсы:
    • Простота запросов и действий
    • Малый порог вхождения – все очень просто
    • Масштабируемость простым копированием
  • Минусы:
    • Oчень узкий интерфейс для всего многообразия действий
    • Не очень легко настроить
    Затем Володя представил сформулированные своими коллегами принципы фронт-енд архитектур для сервисно-ориентированных систем (SOFEA – Service Oriented Front-End Architecture). Следует отметить, что этот вопрос не очень хорошо проработан и что эти принципы действительно чуть ли не в первый раз показывались публике.

    Для начала – минусы традиционного «тонкого клиента»:

    1. Обмен неструктурированными данными
    2. Связь presentation flow и обмена данными
    • Проблема с кнопкой Back (о нет, не напоминайте...)
  • Request/Response цикл
    • Нет прямого взаимодействия двух клиентов
    Принципы SOFEA:
    1. Разделение Application Download, Presentation Flow, Data Interchange
    2. Различные варианты Application Download (тонкий/толстый клиенты)
    3. Presentation Flow определяется только клиентом, не должно проходить никаких Request/Response циклов для смены экрана
    4. Обмен данными не должен быть слабым звеном
    5. B Presentation должен использоваться MVC
    Технологии, которые можно использовать для SOFEA:
    1. DHTML/AJAX:
    • JS
    • GWT
  • XML-based
    • XAML
    • MXML
  • Java
    • JavaFX
    • Java WebStart
  • Adobe Flex
  • Кофе-брейк

    На этом кофе-брейке образовательный центр IBB порадовал нас не только печеньем, но и бутербродами :) Опять все те же группки, уже более активные обсуждения – людям явно нравилось все происходящее.

    Value objects in DDD

    Тема DDD очень обширная, поэтому в данном выступлении Володя лишь провел обзор DDD и углубился именно в объекты-значения.

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

    1. Связью с бизнес-доменом
    2. Явно выделенной доменной моделью приложения
    3. Ubiquitous language – четко определенный язык
    4. Model-Driven Design – MDD – развитие приложения «от модели»
    DDD это просто!Особенности реализации DDD:
    • ООП – нативное представление естественных концепций
    • Многослойная архитектура
    • Entities – сущности
    • Value Objects – объекты-значения
    • Доменные сервисы
    • Bounding contexts - граничные контексты

    В DDD сущности несут в себе несколько основных концепций, в частности, роли в системе, ответственности в системе и identity – способность быть распознанной среди других сущностей. Объекты-значения отличаются от сущностей отсутствующей identity. Доменные сервисы объединяют ту логику, которую нельзя явно отнести ни к одной сущности. Bounding contexts используется для деления домена на поддомены.

    Мы затронули очень часто встречающийся антипаттерн – Anemic Domain Model. Этот антипаттерн характеризует такое состояние доменной модели, когда:

    1. Действие делает не модель, а его делают над моделью
    2. Primitive Obsession – одержимость простыми типами (в противовес грамотному определению объектов-значений)
    3. Сущности просто несут данные без какой-либо логики

    Володя показал несколько примеров Anemic Domain Model, для каждого из которых привел пример рефакторингов, которые оживили ее и придали ей смысл.

    Основной причиной для введения объектов-значений является необходимость представлять какие-либо данные и при этом явно держать свой контекст. В качестве примера можно привести SocialSecurityNumber вместо простого String или Identifier вместо привычного Integer. Подобный подход напоминает нам про подход «Be Explicit!», который решает многие проблемы.

    Особенности объектов-значений:

    1. Явное представление контекста домена
    2. Центры гравитации для поведения – концентрируют логику
    3. Явно определяют свой интерфейс
    4. Они всегда корректны – валидация происходит в момент создания объекта-значения и уже созданный объект-значение всегда корректен
    5. Тестируемость
    6. Локальность
    7. Когерентность – обладают высоким уровнем внутренней согласованности, как FirstName и LastName, а не FirstName и CarBestseller

    Объекты значения это не объекты для хранения данных! VO = DO + поведение. Data objects нужны только для передачи данных между различными bounding contexts, внутри доменного контекства использовать data objects нельзя. Еще одной отличительной особенностью объектов для хранения данных является полная несогласованность хранящихся в них данных. В качестве техник для активизации объектов-значений на проекте Володя привел рефакторинг и инкапсуляцию.

    Заключительный кофе-брейк

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

    Web application performance. Scalability.

    Для начала мы определились с терминологией:

    • Производительность (performance) – количество действий в единицу времени
    • Масштабируемость (scalability) – способность функционировать при увеличении доступных ресурсов
    • Доступность (availability) – способность работать в заданных интервалах времени

    Определив необходимые термины, Володя привел подходы к улучшению производительности:

    1. Определить требования к производительности приложения
    2. Обосновать выбор технологии
    3. Тестировать репрезентативно в реальных условиях
    4. Тестировать постоянно, чем раньше, тем лучше
    5. Наблюдай и диагностируй
    • Измеряй, не гадай
    • Введи счетчики производительности
    • Используй средства диагностики
  • Оптимизируй только то, что действительно надо оптимизировать
    • Три правила оптимизации:
      • Не оптимизируй
      • Еще не оптимизируй
      • Профайли и смотри, где надо оптимизировать
    • Определи, изолируй, диагностируй, улучши, проверь
  • Разделяй ответственность за производительность со всей командой
  • Далее Володя подчеркнул основные моменты клиентской производительности:

    1. Рендер страницы может быть медленным (до 80% времени загрузки страницы)
    2. Правила:
    • Минимизируй количество HTTP запросов
    • Используй Content Delivery Networks
    • Используй кеш браузера и прокси
    • Используй GZip
    • Размещай стили вверху, а скрипты внизу
    • Минимизируй количество DNS lookups
    • Вынеси JS и CSS из HTML
    • Уменьшай JS & CSS
  • Инструменты
    • YSlow
    • Google PageSpeed
    Основные аспекты доступности:
    1. Выбор: доступность или масштабируемость
    2. Измерение доступности – количество девяток. Идеал – компания Ericsson с их 99.999999% доступностью в году
    3. Уровень доступности приложения, явно указанный в контракте – допустим, не меньше 99.9999%

    Основные аспекты масштабируемости:

    1. Типы:
    • Горизонтальная – увеличиваем количество серверов
    • Вертикальная – увеличиваем мощность серверов
  • Техники:
    • Load balancing
    • Кеширование
    • Кластеризирование
    Инфраструктура масштабируемости:
    1. Load balancing
    • Stateful
    • Sticky sessions
  • Caching
    • Write policy
    • Appication caching
    • Web caching
    • Distributed caching (memcached)
  • Clustering
    • Grid-схема
  • Database
    • NOSQL подход – Not Only SQL
    • In-memory – базы данных в памяти
    • Distributed базы данных
    Еще мы слегка затронули отдельные моменты систем cloud computing:
    1. Распределенные вычисления на серверах другой компании
    2. Типы cloud computing:
    • Веб-сервисы: Saleforce.com, Google maps
    • Сервисные платформы: Google App Engine, Amazon EC2, S3

    Ну и напоследок Володя рассказал нам про принципы построения масштабируемых систем:

    1. Четко определенные требования по масштабируемости
    2. Анализ поведения пользователей – они больше сохраняют данные или просматривают их
    3. Динамика контента – общий или персональный, часто или не часто меняется
    4. Держать в уме устаревание данных – у вас всегда устаревшие данные! Следует учесть, что уровень устаревания данных определяется не вами, а вашим заказчиком и его бизнес-требованиями
    5. Придерживаться принципа subscribe/publish вместо традиционного request/response – на такой подход недавно перешли такие многомиллионные сервисы, как Twitter и Facebook
    6. Использовать Command-Query Separation
    7. Использовать Actors – независимые асинхронные модули выполнения логики, изначально появились в языке Erlang и с тех пор обеспечивают компании Ericsson заветные 99.999999% доступности в году.

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

    Громадное спасибо Владимиру Лешкевичу и компании Intetics, которые организовали этот праздник IT-счастья!

    Нашли в тексте ошибку — выделите её и нажмите Ctrl+Enter.
    Вакансии
    Новые комментарии
    Сама идея писать очередную CRM без идеи и инвестиций вгоняет меня в уныние, девочка пытается изобрести велосипед, который был изобретен еще 20 лет назад. Ничего не имею против перла, когда я пришел в веб в 2001 это был вполне современный язык, но технологии меняются, я попробовал много нового и скажу откровенно - перл устарел. Непонятно откуда такое презрение к "галерам", ведь это отличная возможность научиться работать и освоить технологии, в том числе и кодом заказчиков. Ну а если ты в своем болоте гниешь 20 лет, то естественно что и сайты у тебя будут в стиле 90ых. Бред про SEO и Ajax даже комментировать не хочется... учитывая тот факт, что ajax'у тоже не меньше 20 лет. p.s. Ну и на спектруме приходилось программировать, не только на бейсике, но и на асме и работы были вполне серьезные, проекты компилировались по 10 минут. но ведь это не означает что надо было стоять на месте и развиваться только в этом направлении
    Alexandr_Voznyak
    23.05.2018 в 00:53
    «Никогда не вкалывала на галерах». Разработчица пишет на «реликтовом» Perl и 25 лет работает в семейном бизнесе
    Мода тут ни при чём, просто когда-то перл был крутым инструментом - не было всяких пхп, а перл был высокоуровневым языком, с кучей библиотек на cpan, готовые либы для веба и так далее, можно было мириться с его дефектами, тем более, что переходили на него сишники, которым не привыкать. А в какой-то момент нормально спроектированные языки вроде питона догнали и значительно перегнали, в итоге перл лишился этих преимуществ, а новых не приобрёл. Я в какой-то момент понял, что просто не могу дальше его использовать, когда есть такие языки как питон. Не могу себя пересилить, ибо нет ответа на вопрос зачем использовать уродливый язык, зачем делать вот так if (any {$_ == $elem} @arr) { когда можно делать так if elem in arr: ? Это частный пример, но таких примеров тьма, не говоря уже о всяких use strict и другой магии которую нужно знать, чтобы было как в нормальных языках по умолчанию, когда-то даже заметку писал - https://habr.com/post/327408/.
    worldmind
    22.05.2018 в 23:46
    «Никогда не вкалывала на галерах». Разработчица пишет на «реликтовом» Perl и 25 лет работает в семейном бизнесе

    Обсуждение

    Missing-male

    IBB -- в нем уже много лет проходят крупные, включая айтишные, мероприятия.

    Это, условно, единственная приличная площадка в Беларуси с недорогими залами такой вместительности и удобной кормежкой.

    Первый байнет 2.0 там проходил (450 человек), Мастеркласс Itransition по Rubi -- 450 человек и т.п.

    Еще там ООН, посольство Германии, ресторан Вестфалия -- достаточно известное место.

    А автор даже с таксистом найти не может.

    Тезисы будут полезны только тем, кто там был. А, судя по фоткам, народу было мало.

    Гораздо полезнее было бы видео и презенташку выложить.

    C379be0fabb8e7e43522ec663293cd1d?1527034806
    Иван Сухинин
    – Sr. Director, POC and Innovation в Kibo

    Байнетом 2.0 я не интересовался, курсы по Ruby прошел в самом Itransition - и откуда мне про IBB знать?

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

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

    Dc340aa1d8c122260642004dd975f608?1401052325
    +3

    Планировалось пригласить двадцать человек в силу формата семинара. В итоге присутствовало двадцать три слушателя.

    Missing-male
    +2

    Если человек никогда не был толком в Юго-Западе, то найти IBB ему действительно не так просто. Во-вторых, вот вы к примеру, не знаете, где находится посольство Германии, хотя оно в самом центре города на Захарова (в IBB толкьо визовый отдел) и ещё кого-то при этом укоряете незнанием Минска.

    Семинар на 450 человек? Это массовая лекция, тут же судя по описанию формат был ближе к дискуссии на равных права докладчика и участников.

    Смешно читать подобные комментарии, вас кто-то обидел?

    Missing-male
    -3

    Я очень рад, что лекция удалась. Я был на других лекция Владимира, более общих. Он отличный докладчик.

    Мне не понравилось, что автор, написавший этот текст-отчет:

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

    2. Информация о самой лекции подана так, словно автор опубликовал свои собственные комментарии по ходу лекции.

    ИМХО, разобраться в этих обрывочных тезисах может только тот, кто либо сам был на лекции, либо имеет уровень подготовки не ниже докладчика. Т.е. большинству читателей этот текст БЕСПОЛЕЗЕН.

    И его так плюсуют.

    Я за то, чтобы мероприятий было больше, и чтобы профессиональных текстов о мероприятиях было больше.

    Missing-male
    insect
    – Project Manager в ETNA Software

    мы с Могилёва нашли, так что я думаю место не проблема. Вообще всё очень хорошо было проведено. Был очен впечатлён.

    Missing-male
    +4

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

    C379be0fabb8e7e43522ec663293cd1d?1527034806
    Иван Сухинин
    – Sr. Director, POC and Innovation в Kibo

    Есть маленькое подозрение, что достаточно скоро появится возможность сходить на подобный семинар ;)

    Missing-male
    -2

    вам что-то дали тезисы?

    Это как читать комментарии к Библии без самой Библии.

    Ничего ведь не понятно.

    Missing-male
    +5

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

    1) какие из перечисленных методик были на них использованы (объём покрытия юнит-тестами, отсутствие анемии доменной модели и построение не leaky abstractions и пр.)

    2) какова сложность проекта (количество человеко-лет)

    3) уровень команды

    4) прибыль (соблюдение дедлайнов)

    Это здорово продемонстрировало бы разницу между "я знаю, как сделать гугл" и "я сделал гугл".

    Dc340aa1d8c122260642004dd975f608?1401052325
    +2

    Дельное замечание!

    Создание гугла в процессе. ;)

    Fba9a393cca46bc66e9b4ecd40c66b23?1527034836
    +2

    а я думал, что мы гугл делаем, черт, конкуренты ... давайте вместе, сразу сделаем гугл 4 (ваш гугл 2 + наш гугл 2) :)))

    Df00eca34107110b6d4d8134142aefc3?1427577615

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

    C379be0fabb8e7e43522ec663293cd1d?1527034806
    Иван Сухинин
    – Sr. Director, POC and Innovation в Kibo

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

    Missing

    Жаль, не знал об этом семинаре :(

    Планирует ли компания Интетикс еще организовать и провести подобные круглые столы, привлекая в качестве коучеров других мега-техлидов?

    C379be0fabb8e7e43522ec663293cd1d?1527034806
    Иван Сухинин
    – Sr. Director, POC and Innovation в Kibo

    Смотрите на нижний комментарий Владимира :)

    Missing-female
    +1

    Да, мы планируем организовать и провести ряд семинаров по актуальным и практическим темам. Готовы рассматривать и других ведущих разработчиков в качестве коучеров.

    Приглашаем на наши следующие семинары. Следите за анонсами на ведущих Ит-ресурсах.

    Какие еще темы были бы интересны для обсуждения, кроме DDD?

    Ee0de4fca84c8c3e0d8dbe3424baf643?1401052271
    -2

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

    C379be0fabb8e7e43522ec663293cd1d?1527034806
    Иван Сухинин
    – Sr. Director, POC and Innovation в Kibo

    +1

    Прицепить не смогу, пожалуй, но направления дать смогу :) Основные книги можно посмотреть по ссылке - http://domaindrivendesign.org/books/ . Основная книга - Eric Evans, "Domain Driven Design", оттуда можно все нужное почерпнуть.

    "Послушать про DDD" - думаю, получится в обозримом будущем ;)

    Ee0de4fca84c8c3e0d8dbe3424baf643?1401052271
    -3

    спасибо.

    ай же я лошара. как зашёл, понял, что мне год назад давали эту ссылку, сколько времени упустил :(.

    Dc340aa1d8c122260642004dd975f608?1401052325
    +2

    Коллеги, как насчет устроить семинар исключительно по DDD с подробным разбором теории и демонстрацией как оно реализуется на практике? По срокам - ориентировочно в апреле.

    C379be0fabb8e7e43522ec663293cd1d?1527034806
    Иван Сухинин
    – Sr. Director, POC and Innovation в Kibo

    Я за :)

    Picture_933?1356409825
    +1

    Очень жалею, что пропустила этот семинар, поэтому следующий поддерживаю всеми руками)

    Ee0de4fca84c8c3e0d8dbe3424baf643?1401052271
    -3

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

    Missing-female
    +1

    Помимо семинаров по технологиям/архитектуре, мы планируем и ряд семинаров-круглых столов по тематике управления проектами и работы с клиентами, где ведущим будет Олег Ридченко, PMD в Intetics.

    Анонсы наших мероприятий мы размещаем на it-tut.by и на этом ресурсе, dev.by. Планируем также сделать страничку на нашем сайте.

    Picture_527?1356409813

    Поддерживаю!!!

    Missing-male
    mikeler80
    – Lead Software Engineer в EPAM

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

    для чистоты убрать бы такие выражения как: "устроили себе перерыв и разбились по кучкам с чашками свежего кофе и вкусным печеньем." Был я в IBB раз 5-6 на конференциях. Понравилось радикально всё, кроме кормежки.

    Володя сказал...Володя сделал...Володя показал Володя-Володя-Володя.

    я так понимаю обсуждение было-то двухсторонним.

    плюс за идею "как я сделал гугл"

    плюс за DDD

    Picture_2525?1356409877
    +4

    А может кто записал семинар на видео?

    Я бы с у удовольствием посмотрел бы.

    C379be0fabb8e7e43522ec663293cd1d?1527034806
    Иван Сухинин
    – Sr. Director, POC and Innovation в Kibo

    +1

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

    Ee0de4fca84c8c3e0d8dbe3424baf643?1401052271
    -3

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

    Missing-male
    -1

    Да, кстати, хочу добавить, что с моей точки зрения, начинать разговор о построении архитектуры надо с определения понятия "архитектура" и формулировки отличительных признаков хороших архитектур. В частности, необходимо изложение фундаментальных ООП принципов: SRP, OCP, LSP, ISP, DI, IoC, LoD, DRY, YAGNI и др.

    DDD, SOA и пр. должны базироваться на этих принципах, иначе сколько ни напрягайся, ничего хорошего не выйдет :)

    C379be0fabb8e7e43522ec663293cd1d?1527034806
    Иван Сухинин
    – Sr. Director, POC and Innovation в Kibo

    Семинар предполагался как мероприятие для архитекторов, т.е. для людей, которые все уже должны знать основы. Я не спорю, что эти принципы важны и рассмотреть когда-нибудь их надо, но совсем не обязательно их рассказывать на первом же семинаре :)

    P.S. С "фундаментальностью" принципов вы явно перегнули :) Из всего SOLIDа непосредственное к ООП отношение имеют лишь LSP и ISP. DRY и YAGNI с легкостью применятся и к структурному, и к функциональному программированию.

    Missing-male

    Не понимаю, разве тот факт, что DRY и YAGNI применимы не только в ООП, делает эти принципы менее фундаментальными? Я бы сказал, что это ещё более усиливает их фундаментальность :)

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

    Субъективно предположу, что хорошо будет, если 30% работающих на позиции senior-разработчиков в РБ, понимают эти основы.

    Missing-male

    вот это списочек :)

    это скорей тянет на курс лекций в вузе, причем даже не объему или сложности, а по необходимости.

    че-то слабо себе представляю где на практике нужно знать все эти аббревиатуры.

    Missing-male

    Вы не правы. Сложный, запутанный, непредсказуемый код почти всегда является следствием нарушения указанных принципов. Я не знаю почему, но многие думают, что ключевыми знаниями для проектирования являются паттерны из книги GoF. При этом, думаю, многим приходилось сталкиваться с тем, что количество применённых паттернов не уменьшает сложность проекта (а иногда и увеличивает) и количество "говнокода" в нём. Знание паттернов статично и, в отличие от SOLIDа, не даёт разработчику критериев оценки качества результата проектирования.

    C379be0fabb8e7e43522ec663293cd1d?1527034806
    Иван Сухинин
    – Sr. Director, POC and Innovation в Kibo

    >> Комметарий к посту выше

    Фундаментальность не отрицаю, отрицаю их ООП фундаментальность ;)

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

    Принципы хороши, затронуть нужно в будущем обязательно.

    Missing-male
    Александр Филипчик
    – Principal Software Engineer в PlayStation Network

    Народ, вы мну только сильно не пинайте - а почему на фотках у народа выражение лиц, как бы это сказать....

    Как будто дверью ошиблись.

    P.S.

    Обожаю форумы, на которых люди пишут о вещах, о которых только читали в книжка, а руками так и не потрогали.

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

    Легко рассуждать и квадратики рисовать. Что то стоящее сделать - вот что сложно. И учить нужно людей не ООП, DDD и другим умным словам. А умению выбрать и применить нужный инструмент в нужное время. И сделать это правильно, а не как умный дядя написал. Уже описывали полностью ООП операционку и что из этого получилось.

    Да, отбойный молоток отличная штука, вот тока плитку в туалете лучше чем-нить менее экстремальным сбивать.

    Кстати, сейчас у нас на мегонавороченный проект с кучей моднявых технологий - архитекторов ищут. И найти достойных не могут. Так что велком, приходите и докажите, что чего то стоите. На деле, а не на форуме

    C379be0fabb8e7e43522ec663293cd1d?1527034806
    Иван Сухинин
    – Sr. Director, POC and Innovation в Kibo

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

    Интереса ради, приведите, пожалуйста, пример форума "на которых люди и далее по тексту"? :)

    Вы пишете - надо применять нужный инструмент в нужное время. А кто спорит? Только проблема, что если человеку не рассказать про кувалду в сарае, он и будет забивать громадные штыри столярным молотком. Нельзя выбрать из того, чего ты не знаешь.

    Ee0de4fca84c8c3e0d8dbe3424baf643?1401052271
    -3

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

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

    Cf2d9c2f53331fb44bfbddfb85f4af36?1527034821
    +1

    >> Кстати, сейчас у нас на мегонавороченный проект с кучей моднявых технологий - архитекторов ищут.

    >> И найти достойных не могут. Так что велком, приходите и докажите, что чего то стоите. На деле, а не на форуме

    Cижу вот, размышляю, как бы это покорректней написать-то... :) Просто довольно часто замечаю такие вот "вызовы" либо со стороны руководства, либо тех, кто туда метит, по отношению к тем, кого "ищут, чтоб придти и что-то доказать"... ;) Особенно это встречается в рядах менеджеров и на интервью. Мы вам деньги платим за "возможность работать с моднявыми распоследними технологиями"- приходите и начинайте доказывать! Фас! :) Это такая схема повышения самооценки или что?

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

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

    - [важный момент] абсолютно большая часть новоиспеченных архитекторов и инженеров метит "побыстрей и сразу" в управленцы, чтоб командовать другими новоиспеченными инженерами. Естественно, при этом существенная часть рутинной работы по имплементации должна быть сделана другими, а их не хватает.

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

    И, как итог: все забывают и забивают на проблемы, опять-таки, системы образования, жалуются, что нет квалифицированных специалистов и т.д. А теперь смотрим на примерный средний возраст проджект-менеджеров, количество проектов/команд на рынке и количество (что осталось) по-настоящему квалифицированных работников на рынке. Т.е. время "активноcти в продакшне" многих квалифицированных специалистов слишком малО для того, чтобы на их место был достаточный приток специалистов.

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

    Missing-male
    Александр Филипчик
    – Principal Software Engineer в PlayStation Network

    >> - сфера образования не справляется (не новость) с поставкой новых кадров. Более того, эти новые кадры, даже при всем желании, не успевают за появляющимися невероятными темпами технологиями, которые им все равно приходится постигать самостоятельно. У меня уже давно складывается впечатление, что технологии выпускают быстрее их осознанного использования. Потому как выпуск технологий - тоже бизнес.

    В яблочко). Недавно разговаривал с одним нерусским профессором, и спросил его - "как вы думаете, какие программисты лучши - наши или из США". И ответ его был - из США. А основная причина их превосходства - даже не образование, а буквально - "они зарабатывают больше, а значит могут больше тратить на отдых и самообразование. И им так же не нужно думать, гдебы вечером подработать. Выгодней подучиться и получить еще 100к в год. Или слетать на конференцию в Германию. Или....". Вот такая печальная история.

    А насчет вызовов - вы ошиблись, я не манагер. ПРосто тот же самый дядя собеседовал у нас людей). РАздракон был полнейший. Все очень конкретно, без воды. Особенно попали те, кто считал себя архитекторами. И трабла та же - не хватка образования и глубины понимания. Умных слов наслышались, про технологии читнули - а конкретный вопрос (как на экзамене прям, например назовите по пунктам 5 недостатков ДДД :)) - и привет.

    Picture_968?1356409826
    Dreamer
    – Software Engineering Team Leader в EPAM

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

    Ну что же делать белорусам-программистам, если не платят им больше, чем американцам. Ведь не от них по сути зарплата зависит, и не могут они на это никак повлиять. Так и живем - крутимся как можем. А не будем умных слов хватать - совсем пропадем :)

    Missing-male
    +1

    я б тоже ничего по пунктам не перечислил, но посмеялся бы над тем кто это требует :)

    все-таки это один из самых недостоверных тестов, т.к. вовсе не свидетельствует о понимании проблемы.

    Missing-male
    Александр Филипчик
    – Principal Software Engineer в PlayStation Network

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

    Сколько гуру JSF не могли описать его жизненный цикл - не перечесть. И каждый видимо уверен, что оно ему не надо. Вот тока это тому надо, кто стоит между вами и работой ;). Поэтому холиварить на эту тему смысла не вижу - мы ничепго не изменим, как спрашивали, так и будут спрашивать. И причем западные заказчики такое спрашивают чаще :(.

    Missing-male
    +1

    По поводу поиска архитекторов. Не забывайте, что профессионалы работают за большие деньги, а крутые профессионалы - за очень большие деньги. Теперь прикиньте, сколько должен стоить практикующий архитектор, за плечами которого не менее 10 лет опыта, десятки завершённых проектов, широчайший кругозор, техническое чутьё и умение завершать проекты вовремя? Учитывая белорусский IT-бизнес, в котором толковый студент может получать 1.5К, зарплата архитектора должна стартовать от 3-4К. Ваша контора готова предложить такие деньги архитектору? А готова ли она предложить адекватную занятость такому специалисту? Нет - тогда руководству не стоит ныть, что тот единственный перспективный проект, сулящий большие доходы, банально некому делать. Кстати, всегда было интересно, а куда подевались архитекторы, которые проектировали предыдущие проекты компании? Или раньше работали по принципу "абы срубить баблос" и все были довольны, а тут неожиданно выяснилось, что с серьёзным проектом за серьёзные деньги такое не прокатит? А что делает ваша контора для текущего технического развития своих специалистов?

    Реалии белорусского IT таковы, что потолок зарплат технического специалиста, формируемый субъективными представлениями руководства о ценности таких сотрудников, достигается за 3-5 лет, после чего финансовый стимул развиваться в техническом направлении исчезает.

    Missing-male
    Александр Филипчик
    – Principal Software Engineer в PlayStation Network

    Беларусь - страна аутсорсинга. Клиент получает то, за что готов платить. Если вы его убедите, что Вам стоит платить такие деньги - вам их заплатят.

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

    Не повторяйте ошибок форума хартии - все пишут, но никто ничего не делает.

    > А что делает ваша контора для текущего технического развития своих специалистов?

    а что делают наши конторы? Правильно - ничего :)

    >Или раньше работали по принципу "абы срубить баблос" и все были довольны

    тут есть компании, которые работают не ради баблоса? :)


    Авторизуйтесь, чтобы оставлять комментарии

    Использование материалов, размещенных на сайте, разрешается при условии прямой гиперссылки на dev.by. Ссылка должна быть размещена в подзаголовке или в первом абзаце публикации.
    datahata — хостинг в Беларуси