Версия 20:02, 15 ноября 2010

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

О конференции в целом и подготовке докладов

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

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

Из мелочей - питание действительно было на уровне. А вот WiFi - нет, из 3 поставленных точек реально работала только одна (conf1) и то - со сбоями, и сигнал от не не везде был.

А еще организаторы сказали (на открытие, по-моему), что было 1200 участников. Как они их посчитали - загадка. Потому что на открытии конференции и на докладе Страуструпа все были в большом зале на 550 мест (как значится в программе). Зал был заполнен плотненько, но все-таки вряд ли существенно больше, чем на половину. На банковской секции - не больше 30-35 человек. В общем, получается человек 300 максимум. Единственное возможное объяснение - на конференции было очень много мероприятий с отдельной регистрацией и оплатой. Если их все сложить, то общее число будет больше, но это просто одного человека несколько раз посчитали. Вот так.

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

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

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

Часть программного комитета четко выдерживает "научность" конференции, и явно это формулировала. Не жестко, но тем не менее по уровню научной статьи - обзор аналогов, позиционирование в отрасли, заключения. На самом деле, тут ничего страшного нет - если бы они это заявили, то почти любому докладу научность в этом объеме придается за час-другой. И в принципе, это делает статью лучше - если за уши не притягивать. Только они не заявили, а вместо этого - выложили требования к оформлению, на которые, говорят, никто не смотрел (что есть плевок докладчикам). Только научность - это палка о двух концах. В общем-то ее придать можно чему угодно и она совершенно не говорит о качестве доклада. Что я лично и наблюдал. Хотя из зала некоторые участники полагали научность правильным направлением. Кстати, в самом программном комитете по поводу научности единого мнения нет. Николай Пунтиков, который будет руководить комитетом в следующем году, не считает ее правильным направлением развития. Основная идея у них - это неспециализированное общение программистов. Кстати, было предложение одного из импортных участников сделать еще отдельный трек отвергнутых докладов. В общем, замечания, претензии и идеи организаторам были высказаны, будем надеется, что в следующем году будет лучше. Хотя закрытие не показало, что это услышано.

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

Классификация докладов

Когда пишешь впечатления от большого количества докладов на конференции, интересно их классифицировать. Самое простое, конечно, по темам, и тут выделяется несколько очевидных групп.

1. Интересно для моей работы
2. Интересно для общего развития
3. Не интересно как узкоспециальное.
4. Не интересно как поверхностное или потому что автор плохо владеет темой.

Однако, это - классификация в контексте моего интереса к определенным темам. А вот можно ли классифицировать независимо от этого? Я выделил несколько групп, и дальше попробую уложить в них слышанные доклады.

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

2. Доклады о практиках - конкретных проектах или применяемых методах, в которых методология тем или иным образом оставлена в тени.

2.1. Доклад о новых практиках и методах и их применении в работе. Методология при этом остается на заднем плане, однако присутствует и адекватна.

2.2. Доклад о реальных проекты, сделанные по известным методологиям, которым поэтому не уделяется особого внимания, акцент на особенностях, встретившихся в конкретном проекте.

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

3. Доклады о методологиях, не подтвержденные практикой.

3.1. Презентации современных методологий. Сюда относятся как чистые презентации методов, например, SOA, так и практически все вендорские доклады, потому что продукты представляются как средство обеспечение той или иной прогрессивной методологии.

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

3.3. Большая методология в общем виде развернута над маленькой задачей. Доклад - надувание щек вокруг крутизны этой методологии, которая часто излагается в общем виде, со сложными формулами.

Наибольшую ценность, с моей точки зрения, представляют доклады 1 и 2.1, дальше идут 2.2, 3.1, 3.2. Естественно, если доклад достаточно хорошо структурирован и изложен. После названия доклада - моя оценка по 5-бальной школьной шкале - это когда двоек почти нет, и вообще учителям надо бороться за успеваемость.

Новые методологии на реальных проектах

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

Максим Цепков (CustIS) Учет ценных бумаг - сделать сложное простым

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

Я не буду здесь воспроизводить доклад, презентация выложена на slideshare, а статья, посланная на конференцию - на lib.custis.ru.

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

Мина Бустром (SunGard Front Arena) Case Study на примере организации, работающей по Agile (5)

Замечательный доклад по-английски о реальном проекте интеграции, в ходе которого методология Model Driven Arcitecture, изначально ориентированная на разработку в рамках водопадной модели, была преобразована исходя из принципов Agile-программирования и как результат получена прагматичная версия Model Driven Development в рамках конкретного проекта. "Light agile principles + complex mda approach = own pragmatic mdd approach!" В докладе очень большая методологическая часть, и это не результат ретроспективного осмысления, они так строили процесс - я после доклада об этом отдельно спрашивал.

Сам проект - реинжиниринг сложившихся информационных потоков между зоопарком корпоративных приложений. Использовался некоторый внутренний протокол tnp, частично описанный, а частично специфицированный в заголовочных C++-файлах с комментариями, причем описания местами не соответствовали реализации. Руководство не хотело большого проекта реинжиниринга и особо не инвестировало, в организации был отрицательный опыт применения классического mda, а у них самих опыта больших интеграционных проектов не было. При этом C++ реализация сдерживала развитие интеграции, что-то там стрельнуло с размером для типов данных. Так что с точки зрения программистов реинжиниринг был необходим, но полноценный водопад запустить они не могли. Плюс, они уже некоторое время работали по agile-методологиям и верили в это.

В целом за 6 месяцев они задачу успешно решили. Сначала выбрали общую архитектуру и инструменты. Обмен - через xml-форматы с xsl-преобразованиями как общеизвестную платформу, решили не использовать тяжелых фреймворков и средств моделирования, включая uml, потребовали совпадения логической и физической модели. А дальше - ели слона по частям. Выделяли некоторый фрагмент информационных потоков, в рамках спринта проводили анализ и reverse engeneering из кодов для восстановления модели данных и реализовывали основной сценарий, в следующих спринтах - наращивали подробности и особые случаи, потом переключались на следующий фрагмент. Для reverse engeneering сделали собственный tool.

Приличная завершающая часть доклада, была посвящена урокам, которые они извлекли из проекта. Следование жестким принципам XP признали полезным. Так же как жесткое соответствие логического и физического уровня моделей. Отказ от тяжелых mda-средств - тоже. Еще - жесткое разделение концепций.

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

Новые практики и методы работы в реальных проектах

Доклад о новых практиках и методах и их применении в работе. Современная методология автору известна, присутствует и адекватна, при этом остается на заднем плане. Предлагаемые практики местами ее опережают или являются неожиданной комбинацией, которая методологически не осмыслена. Как и майнстрим современного течения по организации проектов - agile методологии, которые прежде всего - наборы практик.

Стас Фомин (CUSTIS) Agile Learning: Эффективные инструменты (6)

Да-да, я не ошибся - оценка 6 по пятибальной шкале - за живость подачи материала и взаимодействие с аудиторией. Хотя сам доклад несколько сумбурный, и на мой взгляд, у Стаса были лучшие доклады, на конференции он сильно выше среднего уровня. Стас экспериментировал с новой формой интерактива на докладе, и как при всяком эксперименте - не все гладко и сразу получилось. С другой стороны, он успешно конкурировал с обеденным перерывом, и люди - они его слушали, а не пошли обедать. Правда, он не довел это до логического завершения и не занял все время обеда. В общем, уходить с доклада совершенно не хотелось даже мне, которому материал был знаком. А юмор - он запоминается. Например, о том, кто важен в процессе разработки: менеджеры - они управляют и организуют, тестировщики - они заботятся о качестве, а программисты - они же только новые баги плодят, так что когда надо сокращать - не задумывайтесь :)

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

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

Стас регулярно выступает на SECR и других конференциях. Но доклады не являются повторением и в этом году он презентовал то, что было достигнуто недавно, в частности, инструменты для создания статей-презентаций в вики, блоги-форумы на основе вики. Но основная нацеленность доклада - именно на то, чтобы заинтересовать массы слушателей. Тем более, что они были в основной массе новые. Правда, получилась оборотная сторона - слабая структурированность, сумбурность доклада. Это - минус. Но, в конце концов, структурированной информации в инете много, и найти ее - не проблема. Надо проявлять инициативу, пробовать разные возможности, экспериментировать. И находить способы.

Насколько получилось это донести и инициировать активность в слушателях - посмотрим. Все-таки, это сложная задача. Во всяком случае, есть общедоступный http://wikisandbox.custis.ru, сделанный Стасом специально для того, чтобы каждый мог попробовать этим пользоваться. А сами инструменты являются общедоступными и бесплатными. Стас распространяет установленную у нас конфигурацию для быстрого старта, обещает выложить в opensource, но пока не успевает.

Александр Орлов (Happy-PM.com) Трудности перехода в менеджеры в разных типах ИТ компаний (5)

Слушал только конец, это жаль. Интересный доклад про работу IT-менеджера в непрофильной компании - как в ней действовать, как общаться с окружением. Для разработчика, ставшего менеджером. Особенности того, что IT там - обслуживание, поэтому часто выделяют по остаточному принципу, особенно если не говоришь с бизнесом на их языке. И подходы к разговору с бизнесом. Понятная разработчику аналогия - взаимоотношения разработчиков и админов в IT-компании.

Сильно нового лично я не услышал, поле информации знакомое - и из общения вокруг, и из книг (у Йордана в Смертельном марше много есть, и не только у него). Но, все равно, доклад - интересен.

Реальные проекты по известным методологиям

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

Владимир Рубанов, Андрей Пономаренко (ИСП РАН) Генерация тестов (4)

Полное название доклада: Автоматическая генерация базовых тестов для программных интерфейсов.

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

Они его написали. Он работает по заголовкам функций (на C++), при необходимости применяется псевдоразметка - если в функции передаются объекты, то их может быть нужно конструировать достаточно корректно, могут быть ограничения на допустимые значения аргументов. В принципе автогенерация работает, даже если ничего дополнительно не описывать. Генерация идет в свой фреймворк запуска тестов и несколько стандартных - q2c и еще какой-то, связанный с opengroup.

Каждую функцию фреймворк вызывает по одному разу с допустимыми аргументами и проверит, что она не упала, а если есть код ответа - то проверит его на OK. Потом пропустить через него библиотеку - и гордо (или формально) заявлять о 100% покрытия тестами.

Все это опубликовано http://ispras.linux-foundation.org/index.php/API_Sanity_Autotest, сторонние тоже разработчики используют, чтобы сделать формальное покрытие поверх фрагментарных тестов, написанных вручную.

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

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

Реальные проекты и практики без методологии

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

Презентации современных методологий

Сюда относятся как чистые презентации методов, например, SOA, так и практически все вендорские доклады, потому что продукты представляются как средство обеспечение той или иной прогрессивной методологии.

Леонид Феликсон (SOA Systems) Манифест СOA: Достижение общего понимания СOA и сервис-ориентации (4)

Возможно, я слушал не совсем этот доклад - этот на основных днях, а я слушал Феликсона на банковском дне вместо заявленного в программе доклада Томаса Ерла. Да, аббревиатура "СOA" - из официальной программы конференции. Забавно смотрится. Сам доклад - вполне профессиональное и детальное изложение SOA-манифеста и целей, которые хотелось бы достигнуть. Целей тут две, и обе направлены на поворот сознания.

Первая цель - собственно интеграция. "Теперь программисты не стремятся писать код, кроме некоторых испытывающих от этого кайф. Вместо этого они берут готовый код и комбинируют его для получения нужного функционала. И идея SOA - в том, чтобы было легко это сделать." Это пересказ, а не цитата, но смысл передан. У меня это вызвало ассоциации с идеей постиндустриального общества, в котором реальное производство переносится в Китай и другие подобные страны, а в развитых - остаются услуги. Лично я к этой идее отношусь скептически, как в рамках общества в целом, так и в рамках программирования в частности. И таки примеры, как google, приводимые сторонниками, меня не убеждают, но, тем не менее, вопросы интеграции и комбинации готовых продуктов - они достаточно актуальны, а многие программисты и вендоры оставляют их на заднем плане при продумывании и реализации своих продуктов. Лозунг обращен к ним и призван повернуть сознание. Правда, серебряной пули тут нет, и как инструмент SOA не сильно отличается от других архитектур и подходов, которых было множество. А хорошо интегрированных систем все-таки не получается. Наверное, задача сложнее и одного лозунга тут недостаточно :)

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

Лично я, в общем-то, знал, что SOA - просто бренд. Но вот идеология вокруг этого, обесценивающая разработку как таковую - она меня огорчила, да. По-моему, это - отрыв от реальности. А еще я осознал для себя, что SOA не связан с объектно-ориентированным подходом, они находятся в разных плоскостях и сервис, в общем случае, объектом не является. Это, скорее, просто некоторый набор процедур.

Джордж Шарков (ESI) Разработка ПО: от исследований к бизнесу (4)

Доклад по-английски. На философскую тему, что такое разработка - исследование (research) или бизнес. И основной проблеме, с этим связанной - не гарантированном результате и рисках из этого следующих. Со сравнением с другими отраслями, например, созданием бытовой техники, которое тоже исследование местами. Идея в том, что создание технологий - это действительно исследование, а вот их претворение в практику (adoption to production) - это уже бизнес. Эти стадии надо четко различать, формулировать бизнесу. И надо учиться доводить технологические идеи до практики как гарантированный бизнес-процесс.

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

Новые идеи на модельных задачах

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

Таланов и другие (Fujitsu) Автоматизация производства ПО при помощи Concept mining (5)

Полный список авторов и название: Максим Таланов, Андрей Крехов, Айдар Махмутов (Fujitsu Technology Solution) Автоматизация производства ПО при помощи Concept mining и использования вероятностных рассуждений поверх семантической базы знаний в области софтверной инженерии.

Ребята делают систему, которая позволит автоматически исполнять change request'ы заказчика, сформулированные на естественном английском языке, с аудитом аналитика, выдавая готовый код (sic!!). Пока у них демо на модельных примерах, в этом году запланирован выход в продакшн и они оценивают, что смогут до 25-60% запросов на изменение своих приложений обрабатывать автоматически. Потому как тупые запросы. А сложные - да, к программистам, как сейчас.

Основные идеи таковы. Пока мы копаем код лопатой, а нужно - экскаватор. Пока не изобрели. Есть генераторы, но нельзя сделать merge, точечно вмешаться, достроить порождение по аналогии. Потому что приложения-генераторы - не понимают, что делают, там тупой формат кода. А хочется - интеллектуальной генерации по некоторому близкому к естественному описанию. Упоминались какие-то предшественники, но я не запомнил. Была простая система, прототип. Но желание довести до продакшн. Добавить самообучение по опыту. Питер Морг и Бертран Рассел. И это не ИИ, решаем только простые задачи.

Для обучения - память, знания а не данные RDB storage, лингвистика - stanford parser, понимательный компонент - самое сложное, пытается сопоставить предикаты с моделью. Генератор идей - самый проработанный, стохастический генератора и тренер - зубрежка. Если по аналогии нашли решение, ок, иначе - стохастическая генерация, вероятностная логика. Оценивает эксперт.

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

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

В текущем представлении, на котором отлаживаются - 3 тысячи концепций, как-то отно работает. Проект лежит на google source (вроде), после презентации можно было взять CD с демо. Я взял, но еще не смотрел.

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

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

Надувание научных щек над мини-практикой

Большая методология в общем виде развернута над маленькой задачей. Доклад - надувание щек вокруг крутизны этой методологии, которая часто излагается в общем виде, со сложными формулами.

Другие доклады

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