(Из ленты MaksWiki — Блог:Максима Цепкова [ru])

Две недели назад был в Новосибирске на #CodeFest. И очень доволен, я бы сказал, что организаторы сделали конференцию моей мечты — с большим количеством обзорных докладов от экспертов, которые раскрывают современные трендовые темы. При этом не поверхностно, а с погружением в детали, да еще складывая мозаику разных трендов, про которые, в общем-то, знаешь в целостную картину. В этом и ценность — когда тема на хайпе, то достаточно сложно получить целостную картину, прорываясь через поверхностное представление, хайповый флейм и отдельные аспекты. Если плотно следишь — ты в теме, но вот на это время не всегда есть. Доклады на конференции были разной ширины темы — и общий доклад по искусственному интеллекту от Ивана Ямщикова, и доклады по конкретным современным фреймворкам и работе с ними, но в любом случае спикеры показывали очень глубокое знание темы, давали не только общие концепты, но и детали.

Наряду с большим количеством технических потоков, были потоки про управление и лидерство, что, в общем-то не удивительно на современных IT-конференциях, как писал полгода назад, IT стремительно и всерьез осваивает soft skill. Если говорить об охвате тематики по площади, то, наверное, не хватало потока аналитиков, но вполне возможно, что для аудитории конференции это не очень актуально. В любом случае, восемь параллельных треков и 2500 участников — это очень круто, конференция — растет. И я очень благодарен организаторам за приглашение выступить.

Мой доклад

Я сам рассказывал про Прозрачность движения к результату в Agile для руководства на секции управления. Может показаться, что проблема надумана, ведь и Scrum и Kanban включают средства, которые делают работу прозрачной. Но они хорошо работают только когда у тебя есть лишь несколько команд, за которыми ты плотно следишь, а когда команд становится много, то необходимо делать над ними надстройку. Особенно если речь идет о разнородной среде, в которой не все команды работают по Agile или способы организации сильно отличаются, например, о командах подрядчиков. И я собрал в своем докладе спектр методик и подходов, на которые можно опираться, конструируя собственную систему прозрачности — потому что, как обычно, тут нет типового решения на все случаи жизни, надо отталкиваться от ситуации. Как, собственно, во всех случаях — почему-то никого не удивляет, что для разработки сайта универсального инструмента и шаблона нет, а вот в области управления многие почему-то ждут универсальных решений, хотя управление ни разу не проще, чем разработка сайтов :)

Ну а теперь — заметки с тех докладов, на которых я был. Отмечу, что я был на очень малой части докладов, потому что, как я уже писал, было восемь параллельных треков. А еще значительную часть времени я общался на разные темы: доклады можно послушать в записи, а общение — это то, что невосполнимо. А еще я в ходе конференции дал большое интервью в прямом эфире радио ЦФТ.

Заметки с докладов

Пост на FB Sander Hoogendoorn, keynote. Наверное, я — не релевантный слушатель, слишком много знаю. Но вот правда, совершенно не интересно слушать доклад от основ, да еще с известными образами, что MVP — это эволюция от скейта через самокат, велосипед, мотоцикл до автомобиля, а не колеса — кузов — автомобиль; что нужен roadmap, а не план; с картинкой scrum — не интересно. Во второй половине пошло немного более современное, но тоже известное. Фреймворки масштабирования, но только SAFe и Spotify из 6-7, со словами «не используйте, они сложные». Антипаттерн Red Spring — не превращайте каждый спринт в мини-проект, на котором команда выдыхается, а переходите к continious delivery, и автотесты вам в помощь. Stop doing projects. И потому — не используйте Scrum Guide. А ключевая штука — ясная коммуникация. А чем больше команда — тем она сложнее, каждый с каждым.

Живая комната как рабочее пространство вместо строгих офисов, фан. И резкое переключение: самоорганизация — сложна, выводит из зоны комфорта. А фан — он где — в зоне комфорта? Если да — то зачем он нужен. А если в зоне комфорта его нет — то где он? Или фан считается невозможным самоорганизовать? Cynefin framework — он тоже во всех презентациях. И почти как картинка, его использование как рабочей схемы, а не красивой картинки из такого рассказа фиг поймешь.

В общем, честно не понимаю. Зачем такой рассказ от гуру? Чтобы прописные истины приняли из уважения к авторитету? Так ведь не поймут… И наверняка у спикера было что интересное рассказать для профи, с переднего края. Может, новички бы и не поняли — но у них был бы вызов.

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

Пост на FB Илья Комса, Wargaming. У гитхаба — contitnous integration, commit — на продакшн. Есть боты, которые мониторят твиттер и при жалобах — откатывают версии. Это — круто. Они к этому идут, но есть сложности… Например, выкатка только в ночной минимум игроков — а значит если появятся проблемы утром в пик игроков, то откатить или быстро починить нельзя будет. Впрочем, они работают над тем, чтобы использовать в продакшн горячую перезагрузку модулей. И оперативно переключать режимы через feature toggles, в том числе — для бета-пользователей, платных пользователей, A/B-тестирования и откатов новых фич. А в целом, почему Wargaming рассказывает в секции frontend — потому что они часть функционала делают на встроенном браузере на основе chromium для быстрой разработки новых фич.

Пост на FB Мысль после доклада Ильи Комса. К вопросу о continious integration, за который ратовали на общем докладе как must. Фишка в том, что continious integration сейчас — лишь техническая проблема. Да, не нулевая, да, с определенной стоимостью, но — решаемая. Но при этом реальный релизный цикл для многих проектов должен быть не просто непрерывным, а управляемым. Например, у wargaming он ограничен циклом маркетинга. И надо проектировать и закладывать в процессы именно управляемый, а не непрерывный цикл, что сильно сложнее, и, если честно, я не слышал хороших докладов об общих подходах для этого. Предпочитают рассказывать простые случаи, а со сложными — пусть каждая компания разбирается по своему. Компании, конечно, разбираются — но кто будет делать обобщение опыта?

Пост на FB Михаил Шатихин. Как можно сделать контроль типов на JS? Есть хипстерские вещи — #Kotlin, #Closure. А в enterprise — #Typescript (2.8.1) и #Flow 0.69. Это на заметку авторам Kotlin — о том, как его воспринимают :) А в целом доклад — о том, какие проблемы устраняет типизация, и какие альтернативы. Типизация позволяет устранить проблемы опечаток, правильных аргументов функций, нормальный автокомплит с типизацией. А так эти проблемы вылезут только на бою, ну или надо плотно покрывать автотестами.

TypeScript — для уверенных людей. Если не мечетесь, и знаете все свои типы — используйте TypeScript. Flow — анализатор, он сделан для того, чтобы добавлять контроль в legacy-код понемногу. TypeScript при примитивном использовании сильно меняет код, так, что хочется его выкинуть и вернуться на Flow. А реально есть некоторое количество концептов, их надо знать и использовать — и тогда будет реальное счастье. И дальше был рассказ про конкретные правильные способы использования. С записью живого кодирования.

Пост на FB Михаил Шатихин. Anders Hejlsberg автор Turbo Pascal, Delphi и C#: большие кодовые базы на JS становятся readonly, а ведь их надо развивать :) И это подвигло Андерса написать поверх JS нормальный типизированный TypeScript :)

Пост на FB Михаил Шатихин. В ответ на вопрос про разные способы сборки: «У меня все быстро собирается, я даже не успеваю за кофе сходить» :)

Пост на FB Сергей Рыжиков 1С-Битрикс. Доклад о стратегии развития продукта: позиционирование без прямых конкурентов, но занимая их области как комплексное решение; суперкомфортная лицензионная политика — на компанию, а не на разработчика; многое другое. И успех — развитие только за свои, с окупаемостью за год и переходу к генерации прибыли. Важная мысль — думайте о своей аудитории и выводе продукта сразу, а не через долгого кодирования, и смотрите за стратегиями конкурентов — ее достаточно легко отследить и достроить по публичным маркетинговым сообщениям, и тогда их новые повороты не будут неожиданностью. В общем-то, мысль кажется очевидной, но ей часто пренебрегают. Я слушал только кусочек доклада, потому что в перерыве зацепился за коммуникацию. Что мне понравилось — это доклад «просто о сложном», без навороченных моделей история успеха. Впрочем, понятно, что простота — кажущаяся, вряд ли на материалах доклада можно повторить успех битрикс. Тем не менее, направления входа — обозначены.

Пост на FB Артур Бекеров из IBM. Knowledge-based Chatbots — медицинский помощник для self-assesment и для записи к специалисту минуя терапевта. Делают азу знаний, сопрягают с chatbot-платформой. В базе: Пациент — Заболевание — Симптомы, Заболевание — Части тела — Специалисты. На русском, поэтому отдельная проблема — с наполнением базы данных, на русском медицинской онтологии и связки с симптомами нет, поэтому исходниками были учебники из медицины, в pdf-виде. Которые обрабатывались не вручную, а автоматически, не только распознавание, но и выделение семантических связей для наполнения базы. Еще интересно, что многое делается стандартными решениями, проблемой проекта было наполнить базу знаний, а вот нормализация фраз пациента, чтобы по нему построить запрос к базе данных — выполняется стандартной библиотекой.

Пост на FB Иван Ямщиков. Развитие прикладного искусственного интеллекта. Великолепный доклад, обзор что уже есть, что будет завтра, что будет, но неясно когда. Из интересного для меня — что выделение объектов, связей и смыслов машины делают успешно, есть примеры обработки афиш большого театра с выделением смыслов и много другого. Успешные самообучающиеся системы в закрытых средах, которые самообучаются с нуля не зная правил, различным играм, и побеждают игроков-людей. Но вот команда на команду — пока не играют, слишком велика неопределенность, это действие в открытых средах, беспилотники, они развиваются. В будущем — естественный язык, проходящий тест Тьюринга — для полноценной коммуникации. Есть альтернативный способ — флешка в мозг, но по его мнению — будет позднее. Как и сильный искусственный интеллект, для которого, к тому же, пока нет операбельного критерия — как и для сознания и осознанности. А в заключении — 12 тем,которые можно взять и сделать, не надо исследовать. Например, голосовой душ, или словомер для детей, или офисный цветок, который по веб-камере контролирует осанку и многое другое. И темы для afterperty — что такое «умный», что такое «образ». Спасибо!

Пост на FB Уже после доклада Иван Ямщиков про развитие искусственного интеллекта у меня возник вопрос: чем он отличается от первого пленарного доклада Sander Hoogendoorn про Agile, что Иван мне понравился, а Сандер показался тривиальным? В принципе, то, что рассказывал Иван я тоже знал из разных источников. Но у Ивана оно собрано вместе, в единую карту, при чем с погружением, вернее, с наметками, для погружения нет времени. И неважно, что эти глубины не будут понятны для специалистов, и с намеченными мостиками между фрагментами карты. А вот у Сандера — были фрагменты вместо единой карты, разрозненные и в адаптированном «комиксном» виде, в котором соединения и погружения — не предполагается. Потому что комикс дает метафору, и метафоры между собой — не стыкуются, они придуманы именно для фрагмента. И целостная картина — не собирается…

Пост на FB Артем Каличкин. Почему вы думаете, что у вас Scrum, а там его нет и не надо. Доклад — борьба с идеей, что все методологии придуманы, и надо только правильно внедрить. Он еще помнит hipe RUP, когда тоже казалось, что все придумано. А сам доклад — детальный разбор внедрения методологий из позиции «делаем все, как гуру сказал, не отступая ни на миллиметр». Призыв к критическому мышлению к таким тезисам, и к отношению к методологиям как к набору практик, из которых применяешь что нужно. Подтвержденный разными кейсами проектов из собственной жизни, где применялись смешанные конструкции, адекватному проекту. Собственно, mainstream идет туда же, OMG Essence: каждому проекту — свой метод.

Пост на FB Артем Каличкин. Ожидания от методологии — в том, чтобы незрелую команду сделать зрелой, а методология только для зрелой команды — просто не нужна.

Пост на FB Светлана Русова. Смарт-контракты и оракулы — как верифицировать данные для блокчейна и смарт-контрактов. Обзор виртуальной машины Etherium и особенностей разработки контрактов в виртуальной машине, где ты платишь за операции и не можешь изменить код. Главное, что я понял — поскольку исправление ошибки становится невозможным, то становится невозможной отладка. И в целом мы по сути выходим из области разработки софта в область разработки инженерных изделий, при чем еще и без возможности ремонта — то есть примерно в область разработки спутников, которые после запуска нельзя отремонтировать, можно только потерять. Но при этом разработка смарт-контрактов будет достаточно массовой, гораздо более массовой, чем разработка спутников. И это, по идее, должно вызвать новый виток инженерной мысли по способам разработки инженерных изделий (а не просто софта). Посмотрим, к чему это приведет.

Пост на FB Алексей Натёкин. Откуда вырос и куда растет Data Science? Хороший комплексный обзор о том, как открытия и прорывы по разным из 5 основных направлений (статистика, математика, визуализация, data technology, computer science) с 1960-х (с ретро до открытия регрессии Гауссом в 1795) приводила к реальному прогрессу и параллельно — к смене hipe-бирочки, которую всем продают маркетологи. Такая история смены содержания и бирок.

Пост на FB Алексей Натёкин. Основная проблема — нельзя до анализа гарантировать результат от data science. Кейс — на двух очень похожих игрушках одной студии, по одной — плохо предсказывали уход игроков, зато получалось возвращать, а в другой — хорошо предсказывали, но зато без их возвращения.

Пост на FB #CodeFest Завершился вдохновляющим докладом. Александра Лысковского. Любой бизнес = IT, но ни бизнес, ни IT ещё пока об этом не знают. Об IT-шных компаниях, продающих традиционный товар и делающих вид, что там «то же самое», хотя внутри — совсем другое: Uber, Netflix, Додо-пицца, Тинькофф, Яндекс-здоровье. При этом целевая модель — не нынешняя, Uber ориентируется на то будущее, когда в такси вместо водителя будет робот, и это — 70% стоимости перевозок, а он при этом будет на первом месте. И именно под это получает инвестиции. А Netflix — это не кинотеатр, они реально анализируют поведение зрителей и учатся делать сюжеты лучше чем люди, запуск 700 сериалов в год, а в перспективе — следить за направлением взгляда и еще выстраивать сцены. И Яндекс-здоровье — это медицина, где основным диагностом будет не врач, а бот. А еще IT-шники идут и меняют другие отрасли, потому что лучше всех умеют планировать, делать распределенные команды, автоматизировать, а еще — привлекают самые большие инвестиции на ранних этапах — как Tesla, которая делает вид, что она — не производитель, а IT-компания. И IT-шники на самом деле делают это лучше других — поэтому призыв к IT — идите и меняйте мир.

В комментариях к посту — большая дискуссия о том, могут ли IT-шники поменять мир или нет.

Источник