08 августа 2016

Напочитать: Психо



1. О том, что геймдеэв потерял всякую совесть и страх и манипулирует людьми.
2. Зачем вам нужна девочка на телефоне и что хотят все эти люди - социнжиниринг для атак на  офис.
3. Иерархия оказалась вредна для кооперации в группе - да,ладно ?!?!?
4. Тут пошла волна выступлений,  подкастов и статей  про то как быть программисту-тестировщику в возрасте. Тренд собственно туда и идет - отрасль взрослеет, как ни крути.
5. Зак Холлман, который раньше был в GitHub говорит нам следующее -
But look around: how many small, less-than-50-person startups are doing work like that? The dirty secret is most startups for the first few years are glorified CRUD apps, and finding well-rounded and diverse people who can have the biggest impact tend to be the ones who are comfortable wearing a lot of hats.
ну и далее, о том почему Startup interviewing is fuked.  И, да, бложек Зака попал в реестр блокировки РосКомПозора , но я думаю вы справитесь :)
6. О том что нужно нанимать личность, а не сборник навыков/ответов на вопросы.
7. Эффект IKEA - люди склонны переоценивать стоимость если они вложили туда немного своего труда.
8. О том что такое внутренние коммуникация и зачем оно надо.
9. То чаво не может быть - Open Salary. Очень интересно если кто-нибудь еще накидает ссылок на эту тему.
10. Google открыл свой курс для менеджеров.
11. Сет Годин про то что нужно делать/делают маленькие команды на ежедневной основе.
12. Как оценить что угодно методом Ферми.
13. Паттерны холакратии - посмотрите на свою орг.структуру в контексте этого, может чего узнаете.
14. Почему большинству студентов пиздец на рынке труда
Ну и самое главное - Бертран Рассел, о важном
Пассивное принятие знаний учителя легко даётся большинству молодых людей. Оно не подразумевает усилий независимого мышления и кажется разумным, ведь учитель знает больше учеников. К тому же, это способ завоевать благосклонность учителя. Однако привычка пассивного принятия имеет катастрофические последствия для дальнейшей жизни. Она заставляет людей искать себе лидера и принимать в качестве лидера любого, кто обосновался в этом положении. Она порождает власть церквей, правительств, партий и прочих организаций, посредством которых простых людей обманным путём заставляют поддерживать старые системы, губительные для страны и для них самих. Если бы целью было научить учеников думать, то вместо того, чтобы заставлять их принимать готовые выводы, образование осуществлялось бы по-другому: было бы меньше спешки в объяснении, больше обсуждения, больше возможностей для учеников выражать свои мысли. И, в первую очередь, было бы стремление возбудить любовь к интеллектуальному поиску.


21 июля 2016

Напосмотреть: North, Dan North




Английский язык для меня не родной (с чего бы это!), поэтому слушать низкопробные и дохлые доклады на английском у меня долго не получается.
 К тому же английский, по моему стойкому убеждению, является самым информационно-емким языком - то что на русском будет звучать как сложноподчиненное предложение в английском умещается в три слова.
Живых  докладчиков на английском языке тоже есть, но те кто делает это регулярно на системной основе - мало.
Один из таких - Dan North (@tastapod).
За последние две недели из разных источников я посмотрел три его видео и все они хороши.


Про то почему Agile не скалируется и что из этого следует

Про паттерны delivery

Про простоту


Ну и в качестве вишенки на вершине тортика - Dave Thomas про то почему у всех аллергия на слово Agile

20 июня 2016

Мероприятие: QA Meetup в Нижнем Новгороде


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

Место

Нижний Новгород, Центр Международной Торговли.
Площадка хорошая, центра города, отличный вид из окна. Погода дала жару, поэтому даже мне совесть не позволяет предъявить претензии к кондиционерам.


Организация

Все хорошо, все вовремя.

Доклады

Наталья Чуфырина рассказала про то как учить людей автоматизации и как это делают они. Полезно, особенно в ряде моментов которые изучил своим лбом и на своей шкуре.

Юлия Сомова про микросервисы которые помогают автоматизации тестирования Почты@Mail.Ru. Слушая доклад Юли я пришел к мысли? что спустя какое-то время любая большая (ну или значимая) автоматизация тестирования становится похожей на соседей по отрасли.

Алексей Халайджи про автоматизацию тестирования IOS - хорошо и с инсайтами.

Максим Богуславский - про то как взращивать в себе автоматизатора. Годно.

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

Был еще один докладчик, но его выступление я смотрел с "другой стороны баррикад".

Слайды презентации



Видео - спасибо киностудии Boguslavsky Films и главному режиссеру, сценаристу и видеооператору Максу Богуславскому за то, что попытался сделать из моего выступления блокбастер :) . Видео остальных докладов будет позже.

Часть 1


Часть 2



Код лежит на гитхабе
https://github.com/kronar/testcontainers-eval

16 июня 2016

Напочитать: Автоматизация тестирования: Disruptor


Два доклада про тестирование в LMAX  вдохновили.
Потому и  Disruptor.

1. Адовый рассказ про то как делать Continuous Delivery на биржеквых проектах от LMAX.
2. Продолжение темы, только более философское, но тоже от выходца из LMAX.
3. Про автоматизированное тестирование CRIU и суровый линуксовый жесткач
4.  Подборка статей от пользователя @irony_iron на хабре про автоматизацию очень сурового системного тестирования - антивирусы и перезагрузки, инсталляторыавтологины в винду. Очень хардкорно!
5. XPath, JsonPath... теперь GPath - очередная path-нотация для JSON. Но в RestAssured.
6. Про то как скалировать тестирование на Robot Framework под Docker - презентация, видео, код
7. Про Jenkins Workflow - с картинками и примерами.
8. Log4J теперь говорят не тормозит.
9. Almost 16% of our tests have some level of flakiness associated with them! This is a staggering number; it means that more than 1 in 7 of the tests written by our world-class engineers occasionally fail in a way not caused by changes to the code or tests - и другие интересности от Google как они борятся с  flaky tests. Спойлер: все банально!!!
10. Про автоматизацию тестирования c мобильными устройствами , но не теми про которые вы подумали.
11. Маленький хак для тех кто использует Spring Test.
12. Гойко Аджич про то как сократить издержки на большие тестовые наборы - на самом деле тэги по функциональности, отсутствие зависимостей при запуске тестов, выделение утилитарного слоя кода, хорошие имена для тестов.
13. Про то как взять и упороться функциональщиной из Java8 в Selenium-тестах - с примерами и картинками.
14. Очень полезная вещь - Jenkins-у можно править конфиги удаленно, сам несколько раз пользовался.
15. PowerShell и Jenkins.
16. Github выпустил Spectron 3.0 - тестовый фреймворк для своего поделия Electron (Desktop приложения на node.js) написанный поверх  CrhomeDriver и WebDriverIO.
17. Maven + JUnit + интегрционные тесты  и все как мы любим.

10 июня 2016

Книга: Уильям Детмер. Теория ограничений Голдратта.

Собственно давно я не писал обзоров на книги.
Тому была масса причин: во-первых, пачка книжек купленная у МИФа (Кэрол Дуэк и Осознанность) оказались полным фуфлом, где авторы размазывают одну мысль на 400 страниц, а во-вторых, хотелось хорошего, "тяжелого", чтива, с хардкором, мыслями, так чтобы котелок кипел.
Вот собственно и достал с полки ту книгу, которая стояла в списке на прочтение еще с момента отзыва на нее Макса Дорофеева.


Итак, если вы не читали "Цель" и "Цель-2" Голдратта и/или не знакомы с Теорией Ограничений, то нырять в эту книжку вам не стоит вообще - ни в скафандре, ни без него.
Как я писал ранее, во втором томе "Цели" Голдратт обрисовал практические случаи применения тех или иных инструментов, но не расскзаал методику, видимо оставляя для себя возможность заработать не только на книге, но и на тренингах.

Собственно говоря, книга Детмера закрывает этот пробел, ну или является единственной (возможно только мне) известной попыткой закрыть таковой именно в виде книги, а не поездки на тренинг за огромную кучу денег.

Итак, "мыслительные инструменты" Голдратта по факту состоят из 5 деревьев которые нужно  последовательно применять при проведении изменений:

  1. Дерево текущей реальности - чтобы понять что менять
  2. Диаграмма рзарешения конфликтов - чтобы понять конфликт интересов который не позволяет провести изменения 
  3. Дерево будущей реальности - чтобы проверить куда приведут изменения и приведут ли они туда куда нужно, какие еще последствия будут
  4. Дерево перехода - позволяет ответить на вопрос "что еще нужно для того чтобы все получилось?" и определить с какими препятствиями вы столкнетесь.
  5. План перехода - пошаговый план проведения изменений, вытекающий из предыдущих 4 пунктов. 
Читая книгу, меня не покидало ощущение того, что я все это уже где-то видел и даже делал.
Не, ну на самом деле: дерево текущей реальности - это Root-Cause Analysis как ни крути, диаграмма разрешения конфликтов - это суть есть mind-map, только выстроенный по определенной семантике.

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

Собственно наверное рафинированным смыслом книги и является - вложить в голову читателю две вещи:

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

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

Итого
Читать - стоит.
Голдратту за "мыслительные инструменты" - 4 с минусом - мог бы и сам с нормальными примерами расписать.
Детмеру и российскому изданию - 3 с минусом - только потому, что тренинги стоят сильно много денег.

07 июня 2016

Анонс: 17 июня - QA Meetup в Нижнем Новгороде


17 июня в Нижнем Новгороде будет проходить QA Meetup.


Адрес:  г. Нижний Новгород, Ковалихинская, д.8, Центр Мировой Торговли, Медиа Страйк Холл (10 этаж)

А ну и да, спойлер доклада, как обычно




02 июня 2016

Они учат тестировщиков программировать



История и причины возникновения научной дисциплины
критически важны для понимания самой дисциплины.
Н.М. Светлов, первая лекция по Теории Систем и Системному Анализу.


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

Вы знаете кто такой Бэри Боэм? 
Это все было задолго до всяких Lean/Minimal Viable Product, а идеи-то те же.

Так вот, разработка Боэма и тестирование Бейзера - это одна история нашего тестирования, да и вообще всего IT.
Точнее даже первая, которую в контексте тестирования начал Джерри Вайнберг в 1958 году:

We made the first separate testing group that I know of historically (I’ve never found another) for that Mercury project because we knew astronauts could die if we had errors.We took our best developers and we made them into a group. It’s job was to see that astronaut's didn’t die. They built test tools and all kinds of procedures and went through all kinds of thinking and so on. The record over half a century shows that they were able to achieve a higher level of perfection (but it wasn’t quite perfect) than had ever been achieved before or since.


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

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

И тестировали этот коммерческий софт тогда в том числе и те, кто вышел из околовоенки.
Именно этим я объясняю лично себе, то количество "незаменяемого" софта написанного на COBOL/FORTRAN и прочем - это хороший софт написанный для коммерции, но с критериями качества, унаследованными от "военки".
Вообще весь второй этап  можно охарактеризовать одним словом - специализация.
Потому, что тогда нужно было делать много сравнительно похожего софта, это было массовое производство, с присущей ему специализацией и конвеером.
Нужно рисовать много UI, нужно много администрировать БД, нужно писать много технической документации.
И специализация людей для каждого этапа - дело вполне себе логичное и даже эффективное.

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

Так вот, собственно говоря, причем здесь "Они учат тестировщиков программировать" ??

А вот, на мой взгляд, ситуация из которой выросло тестирование в первом этапе нашей истории - когда мы делаем высокорисковые проекты, с совершенно непонятным результатом, в совершенно неизвестном домене, где все во что ни плюнь - пипец (!!!), инновации!!!! -  она структурно идентична той ситуации которая сейчас, на третьем этапе нашей истории, наблюдается на рынке, когда все хотят автоматизацию тестирования, чтобы тестировщики валидировали продуктовые идеи, умели читать логи и мониторить продакшен,да еще и в юзабилити разбирались.
С той лишь разницей, что тогда были системы ПВО/ПРО / межконтинентальные ракеты/ Буран , а теперь AirBNB/ беспилотные автомобили/Amazon Prime, который доставляет покупки дронами.

Это все, кстати, и не про тестировщиков тоже - у погромистов (опечаток тут нет) те же самые попабольки - давайте, вы, погромисты, будете знать как это все разворачивается в продакшене, как и где и из чего сделан CI, построите мониторинги, будете работать с метриками с продакшена, запускать A/B тесты на живых пользователях и при этом не требовать прибавку к зарплате на ношпу и анальгин (виски вам может еще наливать???) за то что это типа не ваша работа.
Термин full-stack developer шагает по сайтам для поиска работы.
Потому что в большинстве случаев сейчас не нужно "хорошо, но только вот это", нужно "нормально, но все", так чтобы взлетело, а там посмотрим что пользователи скажут, подкрутим.

Тестировщиков учат программировать, програамистов тестировать и все это в угоду одному - скорости бизнеса.

Все разговоры и выступления типа Testing is Dead/Testing is not Dead - это все стандартная пропаганда молодой поросли, чтобы побыстрее вытеснить старую плесень ну или нечто сродни рыку молодого льва в саванне, когда старших нет рядом и никто не может дать по башке.

Тестирование не живо, и не мертво.
Оно просто эволюционирует, равно как и вся отрасль.
Не надо делать из этого трагедии, нужно делать выводы и строить планы.
Планы развития.
Планы развития себя.

Совершенствоваться не обязательно. Выживание — дело добровольное. © Эдвард Деминг.

P.S. откопал в просторах интернетов вот такую вот летопись

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 дал очень много - он дал стандарт и создал целую экосистему вокруг себя.