16 мая 2016

Конференции: goto; Conference Стокгольм

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

Место 

Швеция, Стокгольм, здание Мюнхенской пивоварни.
По утверждениям аборигенов - это самая большая и самая крутая площадка в городе, там проводят свои мероприятия  Oracle и Microsoft.
Вид с балкона на центр Стокгольма с другой стороны пролива конечно отличный, но площадка так себе. Основная проблема, как и в большинстве мест - вентиляция. Мероприятие было рассчитано на 200-300 человек, и если бы был аншлаг, то дышать было бы нечем совсем.


Организация 

Может конечно я уже зажрался посещая конференции типа CodeFest и Joker/JPoint, может особенности национального менталитета и иные cultural references, но организация страдала по мелочам то тут, то там.
В нагрузку к кофе от кейтеринга ребята поставили еще одну привозную кофеварку с двумя баристами, у которых за два дня так и не удалось попить кофе, обед организован весьма странно, несмотря на избыток места. WiFi как и на любой нормальной конференции должен лежать, но работал скрипя и падая.

В общем и целом - на 4 балла из 5.



Доклады

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


День первый

Adrian Cockcroft про простоту и сложность систем - открывающий keynote. Очень хорошо, глубоко и с мыслью как и положено быть keynote-докладам.

Ian Missingham про то что есть AWS Lambda и как его надо использовать - это могло бы быть просто хорошим выступлением евангелиста AWS Lambda , но live-demo пусть даже и с минимальным написанием кода обработчика нажатия кнопки на отдельном устройстве - это бесценно и замечательно продает концепцию Internet of Things.

Ken Sipe про то зачем вам Mesos - опять же технический евангелист Mesos, с очень хорошо подвешенным языком и попыткой Live Demo. За рассказ - 5, за проваленное demo - 2, итого 3+.

Madny Waite про то как пользоваться Kubernetes - лично меня уже поражает как 2 или 3 человека из Google могут ездить с одним и тем же выступлением по разными конференциям и показывать один и тот же пример развертывания nginx в облаке. Позор жеж.

Rodrigue Schaefer про то как Zalando (это магазин шмоточный) себя на микросервисы пилили и для чего это. Отличное, но совершенно не техническое выступление - оно про бизнес, про то что это дает.

Adrian Mouat про небезопасность Docker и что с этим делать - доклад который нужно разобрать на цитаты, положить на полочку, а если у вас уже есть Docker в продакшене - нарезать на таски в  джиру.  Очень приземленно и практически, с примерами и картинками.

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

Afterparty

Ну тут надо сказать сыграли те же cultural references - 3/4 участников конференции дружно встали и вышли, так как никакого afterparty им нафиг не надо, лечь бы пораньше спать.
Остались спикеры да и то не все, и часть участников. Расстраиваться нечему - небольшое количество народа позволило пообщаться с Эдрианом Кокрофтом и Рэнди Шупом за кружкой пива и поеданием бекона. В качестве развлекухи организаторы пригнали какого-то фокусника, но я видел что он залип в какой-то компании которая общалась на тему Docker-контейнеров - у него afterparty точно удалось. Вообще, за доступ к телам докладчиков после первого дня организаторам стоит поставить отдельный плюсик.

День второй

Организаторы видимо посчитали, что интересные доклады должны быть в первый день, во второй был почти один sales bullshit.

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

Tom Wilkie -  о проблемах мониторинга,визуализации и трассировки облачных инфраструктур. Все сказанное - оно очень правильное, а вот все показанное никак не внушает веры в то что это можно натянуть более чем на 100 сервисов.  А ну и да - хипстерский Go.

Steven Borelli про то как Cisco запилило свой облачный шедулер поверх творчества HashiCorp - этот доклад как нельзя лучше иллюстрирует то количество hype-а и buzz-a  вокруг облачных  технологий, которое сейчас есть на рынке - все пытаются снять пенку, даже Cisco.

Andrew Phillips про то что не тестированием единым сыт должен быть разработчик, метрики с продакшена тоже смотреть надо. Скрытый product-placement Dynatrace.

Мысли 

Собственно говоря, вся конференция рассказывает нам о том что идея облаков прижилась,теперь решаются практические задачи по ее внедрению в реальный бизнес. Облачные шедулеры типа Kubernetes, Mesos, Nomad - то самое ядро, которого не хватало. При том все игроки рынка расчитаны на средний маштаб оперирования  - до 100 сервисов и оперирования через  публичные облака типа Amazon/DigitalOcean. Бизнесу это все продается под соусом того, что вам не нужно ждать пока ваши инженеры поставят/настроят сервера - идите и делайте бизнес, ставьте эксперименты. будьте быстрее конкурентов,а мы (облачные вендоры) вам уже помогли, давайте уже платите деньги - Ian Missingham очень хорошо проиллюстрировал это на примере вот этого вот проекта, где David Guetta собирал сэмплы миллиона голосом для гимна чемпионата европы по футболу,а Amazon им в этом помогал. Стоимость инфраструктуры на амазоне в этом случае была просто копеечной по сравнению с развертыванием реального железа, особенно в контексте краткосрочного и контекстного проекта.

Стокгольм

Стокгольм оставил у меня впечатление чего-то среднего между Ригой, Вильнюсом и Таллином, но только с инфраструктурой Вены, что ли.
Очень спокойно, чистый и свежий воздух за счет того что море рядом (зимой наверное вообще очень свежо), спокойные люди на улицах. Мне повезло с погодой.
Ну и да - цены. Цены в Стокгольме просто конские. Проезд на автобусе от Арланды до Стокгольма - 12 евро (для сравнения в Вене 4-8, автобус - 8), кружка пива - от 6 евро, стрит-фуд - в районе 10.

Если еще раз и поеду на goto Conference, то в другую локацию.

12 мая 2016

Напосмотреть: Иди ты на ...


Очень много с goto Conf. 
Да и сам я в Стокгольме на goto Conference.

1.  О том как масштабировать системы деплоймента

2. О хорошей концепции 4К - классы, компонены, контейнеры, контекст - Simon Brown
3. О том насколько на самом деле софт дырявый и почему все так этого боятся
4. О том что такое техническое лидерство

5. Андрей Себрант о том что такое Data Science/Cognitive Science куда мы все катимся

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


И да, отчет с самой goto Conf воспоследуэ...

06 мая 2016

Безалкогольное пиво, резиновые женщины и Maven без XML


Все написанное ниже не претендует на сколь-нибудь значимую долю объективности и является едва оформленным потоком сознания, коий  нашел выход в лоно этой уютной днявочки лишь через мое редкое импульсивное графоманство. Даже более - без прекрасных  выступлений Баруха, Антона и Жени, равно как и отличного доклада Саши и Кирилла ничего этого бы не написалось. Ребята, спасибо вам за вдохновение: если чо - ругать можете идти в комменты. 


Сейчас Maven не ругает только ленивый.
Хотя нет - даже ленивый ругает.

Если посмотреть внутрь всей этой критики, то по сути все сводится к 3-4 пунктам:
  1. XML
  2. Скачивает тысячи гигабайт зависимостей
  3. Невозможность написать что-то свое быстро, невозможность ad-hoc кастомизации сборки
  4. Принципы резолвинга зависимостей
     
Начнем с последнего - принципы резолвинга зависимостей - про это вот тут вот написал один очень неглупый Барух. Мне дополнить сюда нечего - maven не идеален, под это дело понаставили всяких костылей типа enforcer-plugin, в Gradle кстати тоже их есть (читать с момента про Fine-tuning the dependency resolution process) и думаю еще будет. Почему я так думаю?  Потому что проблема транзитивных зависимостей или попросту dependency hell просто так вот не решается - тут надо что-нибудь умное придумать с монадами, haskell-ом и страшной математикой.

Едем дальше, вверх по списку - невозможность написать что-то свое быстро, невозможность налету кастомизировать билд под свои нужды.
Ну тут, имхо, все очень  правильно и хорошо. Почему?
Потому что :
  1. 99.95% Java проектов на этой планете относятся к категории bloody enteprise (кровавый ынтырпрайз), поставляя из себя стандартный JAR/WAR/EAR, который замечательно собирается maven уже много лет, запускается в Jetty, ставится в app server и далее по списку. Gradle это тоже все наверное умеет, иначе нафиг оно вообще надо.

    Android приложения я сюда даже относить не буду - Google прописал gradle как официальный build tool для своей платформы и спорить с этим конечно можно ( а ведь до того как это было maven-ом и android собираали, дада) , но наверное не за чем.

    К слову, оставшиеся 0.05% от общей численности Java проектов на планете я отношу к проектам с уникальной природой, которым позволительно как пользоваться и не maven/пользоваться gradle / вообще написать свой build tool типа bazel от Google.  
  2. Если вам нужно что-то кастомизировать для своего проекта, то для этого во всех инструментах сборки есть плагины. Отличне maven от gradle в том, что в случае с gradle вы можете написать плагин в коде самого проекта и подключить его. Ну или вынести в отдельный проект, как того требует maven.

    Плагины можно писать и там, и там.  Тестировать их тоже можно  и в maven, и в gradle, с той лишь разницей что в maven харнесс для тестирования плагинов внешне напоминает окаменевшее говно мамонта, а в gradle testkit пока еще не устаканился - его переколбашивают с каждым релизом, поэтому у меня вызывает ассоциации с ... не буду говорить с чем. Если же хочется очень быстро нагавнокодить скриптец в билд файле - то идите уже в пункт 3 данной части повествования.
  3. Волшебный Groovy и желание творить. Пфф.... ну что сказать, давайте сначала. Вы серьезно думаете, что все инженеры в вашей команде хорошо разбираются в том как устроена сборка их  проекта ? Нет, даже так - вы УВЕРЕНЫ что все инженеры в вашей команде хорошо разбираются в том как устроена сборка проекта ?  Подозреваю, что среди читателей моего уютненького найдутся и те кто ответит  положительно на оба вопроса. Но, en masse, это, по моим наблюдениям, не так.  По моим наблюдениям 3/4 девелоперов не вникают туда. Соответственно их кастомизации на времени сборки проекта и качестве его результата могут отразится вполне однозначно с совершенно неоднозначными последствиями и временем их устранения.  Проще говоря - иметь возможность говнокодить в файлах сборки должны компетентные люди. Вот тут еще один  неглупый  Барух  про это хорошо разложил. Некомпетентным там делать нечего, пусть идут и пишут плагины, еще лучше плагины с тестами. 
Ладно, задержались тут, давайте дальше - maven скачивает полинтернета.
Каждый раз когда я такое слышу у меня в голове начинает пищать модем 56К - да, я настолько стар, что помню когда они впервые появились, потому что до этого были 32К.
Я еще помню интернет по карточкам. (А еще выход Windows 95, оригинальные D-Track и Carmageddon. Какой же я старый.)

Короче - большинство из вас живет в странах с хорошим интернетом, maven и gradle кэшируют скачанные зависимости весьма неплохо, а при наличии в середине между вами и центровыми репозиторями прокладки в виде Nexus/Artifactory проблема как бы сводится минутам к 5 за которые вы успеете хотя бы один раз грязно обругать maven перед коллегами на кухне за чашкой кофе и пойдете себе дальше работать.  Пустое это.

И вот мы добрались до вершины нашего тортика и вишенки на нем - XML.

Хипстеры при виде XML

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

А xml файл на 2000 строчек - это не страшно, и пускать кровь тут нет повода.  С этим можно жить и работать. Знаете почему ?  Потому что у xml в maven есть схема !!! Которая не позволит вам далеко уйти, если вы косячите.

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

Не нравится XML - ок, maven умеет не только XML.

Рецепт наступления счастья:
  1. Идем сюда, читаем статью http://www.infoq.com/news/2015/03/maven-polyglot 
  2. Ставим себе и на сервер CI версию Maven 3.3.1 и старше.
  3. Идем на гитхаб
    1. Если вы любите YAML, то идем сюда и можем увидеть там такое вот


      Ну а если заинлайнить плагины, то еще компактнее

    2. Если вам не надо YAML, а хочется чего-то еще - то вам вот сюда.
    3. Сравниваем с оргинальным  pom.xml, который приложен  у меня в проекте.
  4. Впендюриваем это все себе в проект живем дальше спокойно, с maven.
Вместо послесловия

Когда то давно, в 2006-2007 годах я работал в аутсорсинге и переходя с проекта на проект видел везде одно и тоже - файл build.xml и папочку /lib с заботливо сложенными бинарями внутри.

После того как я попал на проект с maven жить стало легче, стандартнее и веселее.
Maven по сравнению с Ant дал очень много - он дал стандарт и создал целую экосистему вокруг себя.