Изменения

Пользуясь новогодними праздниками , собрал свои посты-репортажи с [https://2019.secrus.org/ SECR-2019] в отчет. Я участвую в SECR с 2010 года, это была десятая для меня и пятнадцатая по счету конференция. И не я один стабильно учатсвует участвую в конференции, так что SECR для меня - не только качественные доклады, но и погружение в атмосферу общения, встреча со многими знакомыми.

Но, надо отметить, что доклады тоже были очень интересными и разнообразными. Широкая тематическое поле - отличительная особенность SECR, она дает возможность посмотреть на то, что происходит в IT в целом, на новые направления развития. Она - не единственная такая конференция, в 2019 я был и на Highload , и на РИТ, но на SECR спектр разнообразия тем - больше. Доклады - достаточно глубокие, а не обзорные, однако ПК специально работает с докладчиками, чтобы доклад был интересен для широкого круга участников, а не только узким специалистам. Впрочем, судите сами. Помимо моего отчета хочу рекомендовать [https://www.facebook.com/evgeny.aslamov/posts/2550465501704954 отчет Евгения Асламова] и [https://katyastep.wordpress.com/2019/12/10/по-следам-конференции-software-engineering-conference-russia-secr-2019-в-санк/ отчет Екатерины Степалиной]. Наверняка можно найти и другие.

[https://www.facebook.com/mtsepkov/posts/2608898432500428 Пост на FB] http://0x1.tv/20191114AA Asger Alstrup Palm. The open source, functional programming platform flow. Представление платформы функционального реактивного программирования с собственным языком, в режиме живой демонстрации кода, развертываемой от hello world к более сложным конструкциям интерфейса, которые представляют собой поток вложенных абзацев, создаешь создаваемый в визуальном редакторе, а далее отражаемом как верстка экрана. UI при этом создается для всех мобилок, html и desktop, и есть прозрачное взаимодействие с серверной частью - единый язык и платформа для full stack приложений, при этом на серверной части можно интегрироваться с Java, mysql и другими платформами. Реактивное программирование позволяет легко связывать элементы интерфейса, дает графические возможности и так далее. В целом доклад довольно любопытный, но, на мой взгляд, не хватает изюма, киллер-фич нового подхода. Когда [http://0x1.tv/20131024-25 в 2012 Светлана Исакова впервые представляла Kotlin], там был блестящий доклад, в котором сравнивали типичное старое и то, что дает новое, при чем причем на сложных примерах. Здесь такой динамики не хватало, жаль.

[https://www.facebook.com/mtsepkov/posts/2608943662495905 Пост на FB] http://0x1.tv/20191114BB Евгений Асламов (Evgeny Aslamov) из ЛАНИТ. 22 вопроса архитектора - рассказ про чек-лист, который в ЛАНИТ нормирует результат работы архитектора - о чем он должен подумать и примерно в каком порядке. При этом архитектор - человек или коллектив. Вопросы достаточно масштабные, практически задают темы - эксплуатация, масштабирование и так далее. При этом проверка по чек-листу означает (а) указание артефакта и места в нем, где описано, или явное указание на отсутствие артефакта и (б) при отсутствии решения - описать причину отсутствия. Полный чек-лист был показан, а дальше в форме историй рассказ о том, как отдельные пункты появлялись. От первых пунктов: фиксация важных решений по процессу; принимать решения об архитектурных подходах, например, выборе DDD , заранее , и далее - к тоже понятным пунктам: думать заранее про отказоустойчивость; писать логи; думать заранее о том, как в логах разобраться; помнить о viewpoint, а не ограничиваться суперсложной архитектурной диаграммой для всех; поддерживать целостность разных viewpoint за счет метамодели архитектуры; доносить эту целостность до команды. И в заключении - помнить об ограничениях при выборе новых технологий, которые, к сожалению, ограничивают компетенциями разработки и эксплуатации - не полностью отказываясь, а как постепенное апробирование.

[https://www.facebook.com/mtsepkov/posts/2608973945826210 Пост на FB] http://0x1.tv/20191114AB Дмитрий Павлов из Apache Software Foundation: Что такое настоящий open source (и почему его меньше, чем вы думаете). На доклад забежал в самом конце, после доклада "22 вопроса по архитектуре". Но успел на заключение, в котором подводились итоги. Доклад надо будет посмотреть, выводы же были подтверждены историями , и там наверняка интересно. А выводы про проверку open source такие. (1) Проверяйте лицензию - бывает, что в подробностях написано что-то совсем другое, чем open source. (2) Поискать реальное community. Не работают ли все в одной компании? Кто принимает решения, насколько это документировано, как можно повлиять. (3) Кто владелец бренда? Если не коммерческая некоммерческая организация - хорошо.

[https://www.facebook.com/mtsepkov/posts/2609122569144681 Пост на FB] http://0x1.tv/20191114BD Роман Цирульников, Яндекс.Деньги. Микросервисные архитектуры с позиции инженерии систем. Достаточно неожиданный взгляд на архитектуру stakeholder-driven систему. Началось все с того, что в микросервисной архитектуре сервис не является самодостаточным элементом, сервисов становится очень много , и они образуют системы, которым присуще поведение, отсутствующее у отдельных элементов, сложность возрастает и не помещается в одну голову. И надо выделять системы микросервисов, проводя границы, которая относительно произвольна, в соответствии с принципом "Система в глазах смотрящего", она не существует объективно. И Роман предлагает выделять границы, основываясь на стейкхолдерах и их интересах, применяя принцип Дейкстры separation of concent concerns именно исходя из интересов стейкхолдеров. При этом предметом архитектуры перестают быть технологии, наоборот, она начинает строится строиться через арбитраж различных интересов.

Компания ЛАНИТ - крупные заказчики и коммерческие организации. Они в последнее время хотят Agile - раз в две недели показ, обратная связь и главное чтобы , что удовлетворенность заказчика важнее условий контракта! Но при этом фиксированный бюджет и контракт надо выполнить полностью. И это накладывало свои особенности.

[https://www.facebook.com/mtsepkov/posts/2611553652234906 Пост на FB] http://0x1.tv/20191115AC Ольга Павлова. Логические основания дизайна интерфейсов. Доклад начался с утверждения, что исходя из многолетнего опыта, никакой логике логики в организации интерфейсов нет. Хотя у многих есть большая потребность в том, чтобы эта логика была - и потому ее можно выдумать и представить, чтобы наличие логики успокаивало. Отсутствие логики имеет глубокие основания: проектирование интерфейсов - задача создания, применение синтетических методов, а логический вывод - это аналитический метод, он не решает задачи синтеза. Разрыв, который преодолевается на этом пути - перейти от слов к картинкам. И в докладе были практики, которыми они этот разрыв преодолевают, и различные примеры проектов, и большая боль по поводу того, что люди как-то слабо эти практики используют, хотя они довольно просты. Продолжение - в комментариях.

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

* Собираем продукт из ничего. Много букв, аналитическая простыня, углубляющая в разные детали. А сесть и рисовать экраны было невозможно. Зацепиться было не за что. Зацепились волевым усилием: "через неделю - 100 картинок, каких -нибудь". Их выложили заказчику, он оказался доволен и ушел делать дальше.* Проектируем главную страницу. Языковая школа, которая хорошо организует изучение немецкого языка, и взялись взялась за английский. Люди делают custdev 8 часов в день, но это им никак не помогало сделать главную страницу и начать разговор. Картинка: люди приходят отвечать на вопросы, давайте на них отвечать - и это отвергается. А дальше пошли не из знания, а из НЕ знания: чем школа отличается от языковых курсов, они ответили на этот вопрос - главная страница стала явной.

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

* Самое простое - линейный wizard-сценарий, диалог системы с человеком. Очень просто. Почему-то таких сценариев - ноль. Я лично думаю, что кто может - не приходят к ним.

* Карта фокусов. Примеры - веб и mobailmobile. Структура интерфейсов - не дерево. И не один экран. Как изложить структуру - нет прямого подхода. Когда пользователь смотрит на систему - он смотрит на точку. И именно эти точки - фокусы. Они могут быть размазаны по экранам. Пример - недооформленный заказ.

* Инсайт как джокер. Если исследовать поведение людей целиком - будет общая картина, она описывает ВСЕ.Мило аналитикоманалитикам, но результаты - скучны, и дизайнеры НЕ могут их учесть, ей не разу не удалось заставить, хотя информация - о пользователях. Метод - вытаскивать из массы материала интересные кусочки, смотреть, что дизайнера драйвит, а что - нет.

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

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