Изменения

В формате обмена мнениями был очень интересный '''баркэмп про образование'''. Это, кстати, тоже тренд, проявившийся [http://softwarepeople.ru/blog/2013/12/18/spmconf-образование-vs-ит/ на круглом столе SPMconf], HappyDev и здесь. Трендом тут является не тема, а суть обсуждения. IT развилось до того уровня, когда есть потребность в подготовке кадров, которую крупные компании в свое время закрыли для себя учебными центрами, а новым этого — не хватает. И они обсуждают различные формы в практическом, деятельностном залоге. В том числе — взаимодействие с ВУЗами, где они пока не готовы открывать кафедры. Тут, кстати, все сильно зависит от местного ВУЗа. В Омске, например, университет сотрудничает с местным сообществом и за последний год они перешли от уровня взаимодействия с отдельными компаниями к скоординированной общей деятельности. Что, кстати, сразу дало позитивный эффект — после сравнения курсов, читаемых разными компаниями получилось убрать дублирование и, за счет этого сэкономить время и дать дополнительные материалы. В Ульяновске идет взаимодействие на уровне предоставления площадей. А в Пензе, и не только в ней ВУЗ относится к деятельности IT-компаний как к попыткам поживиться за счет государства, или как к потенциальному месту срубить деньги — и хочет денег даже за предоставление помещений. Потому что в образование как система — не заинтересованно в подготовке специалистов, востребованных обществом, у него по факту — совсем другие KPI. И, собственно, основным выводом обсуждения было признание этого факта и, как следствие — работа на уровне конкретных преподавателей с созданием параллельных структур образования в тех местах, где ВУЗы глухи. Да, это непрофильная деятельность и обременение, но — вполне посильное сильным IT-сообществам. И факт состоит в том, что через несколько лет оно обременением быть перестанет, поэтому ВУЗы, не включившиеся в такую деятельность — вымрут. Значит, туда им и дорога.

Теперь о том интересном, что я услышал на докладах. '''Кирилл Мокевнин ''' рассказывал про все аспекты работы с сотрудниками, которые позволяют построить не просто компанию, а сообщество увлеченных, успешно самореализующихся людей, действующих совместно. Составляющие, с одной стороны, понятные и теоретически знакомые, с другой стороны — далеко не везде такое получается и даже ставится такая задача. А между тем это — явные тренд, веление времени. Правда. успешные примеры пока ограничиваются небольшими компаниями, до 50 человек или несколько больше. Но большие, включая таких гигантов как Google и Microsoft некоторое время назад тоже начали работать в этом направлении, и я думаю, что через некоторое время тут будет прорыв. Я, кстати, буду на AgileDays рассказывать, почему это соответствует общемировым закономерностям развития, говоря [http://agiledays.ru/members/profile/211/ о системах ценностей].

Был интересный доклад Максима Зайцев. «Госуслуги«'''Госуслуги. Open: OpenSource для государства» — государства'''» — о том, как систему портала для оказания гос.услуг, разработанную и эксплуатирующуюся в Пензенской области выложили в OpenSource и в результате она является бесплатно-доступной для всех желающих. И разработчики надеются, что она вытеснит большинство других системы госуслуг, потому что многие из них были сделаны быстро в ущерб качеству и представляют собой тяжелые в эксплуатации и неповоротливые изделия, а их же необходимо развивать, подключая новые услуги. Сами разработчики при этом готовы предоставлять услуги по развертыванию системы и адаптации ее к нуждам конкретного региона, уже на платной основе, однако при открытых исходных кодах и наличии квалифицированных кадров можно обойтись и без них, во всяком случае, спектр взаимодействия весьма широк. Они спокойно на это смотрят, видя в этом еще и социальную составляющую — госуслугами пользуемся мы все и если система будет эффективна — то общество в выигрыше. А внутри системы — BPMN-движок для выстраивания процессов по оказанию услуг и их прохождению по разным ведомствам, и точки интеграции с системами конкретных ведомств, обвешанные электронными подписями и прочей достаточно тяжелой инфраструктурой, необходимой для такой системы.

Еще я был на '''нескольких докладах''', на которых рассказывали про осваивание новых для команды технологий или шаблонов реализации или даже созданию новых, например, от переходов от callback к взаимодействию через события или кодогенерации интеграционного слоя на основе описаний структур данных с аннотациями. Тут очень интересные впечатления. Когда такую вещь рассказывают с техническими подробностями, то, во-первых, это полезно тем, кто только смотрит в эту сторону, решая аналогичные задачи. А, во-вторых, хотя это куда менее очевидно, полезно тем, кто этот путь уже прошел. Дело в том, что конкретная реализация — отличается. И настоящий профессионал — тот, кто понимает, почему реализация оказалось другой и может сравнить плюсы и минусы в контексте конкретных проектов. Сами докладчики, чаще всего, это сделать не могут, потому что для них это первый опыт. Но вот, что интересно, более опытные тоже не могут — они в свое время такой путь прошли, и у них тоже единственный опыт — свой, который, при удаче, рассматривается как лучший, а при неудаче — как непригодность технологии (ну, пусть, только к их проектам). А на самом деле он, как правило, не лучший, а просто другой. Особую прелесть этим сравнением придает тот факт, что «программирование — единственная область, где с костылями быстрее, чем без них» (Максим Дорофеев), и отличие профессионала в том, что он умеет сроить баланс костылей и красивых решений. Я не хочу сказать, что сам могу всегда ответить на вопросы, сравнения разных решений но, во всяком случае, я исходно рассматриваю услышанные решения именно как другие, различаю костыли и красивые решения и пробую сравнить их и свои решения с этой точки зрения.

А сам я делал обзорный '''доклад по DDD''', акцентируя внимание на концептуальный уровень, на единый язык и построение коммуникаций, а не просто работу с моделями, и на сложное отражение в код через шаблоны, а не просто через Domain Model и RichObjects — потому что, по опыту, оно гораздо уместнее в сложных проектах. Именно эта часть, по моему опыту, часто ускользает от внимания, в результате DDD интерпретируется как достаточно простая конструкция — с существенными ограничениями по применению. Презентацию доклада можно посмотреть [http://lib.uml2.ru/Tsepkov-SECON-2014-DDD-review здесь].

 [[Category:Конференции]]{{wl-publish: 2014-03-16 12:5148:56 46 +0400 | MaksTsepkov }}[[Category:Конференции]]{{replicate-from-custiswiki-to-lib}}