• Атакуем Joker 2019 полностью: как прошла самая крупная Java-конференция в России
    +3
    Если бы организаторы стремились к англоязычности, тогда и официальный язык конференции сделали бы английским (ну, открытие-закрытие по-английски,
    слайды с приоритетом на английский язык, указатели с приоритетом по-английски и так далее).

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

    Например, я познакомился с René Gröschke на JPoint'е. Стал ли я от этого знатоком Gradle? Едва ли. Но зато стало проще переписываться и я могу переспросить: «Ну, как там мой pull request?».
    На Joker'е я познакомился с Rémi Forax. Я его расспросил про ASM (он один из авторов), и он показал занятный проект github.com/forax/exotic. Ну, прямо на ноутбуке открыли код, он показал что к чему.

    Конечно, всегда хочется, чтобы все 40+ докладов конференции были очень интересны именно мне.
    Скажу честно, доклады про Spring это не моё. Но, ведь, есть и те, кому они нужны и полезны.
    На конференции 4 доклада в параллель. Тематики разные, и для меня успех, это когда в каждом слоте есть хотя бы (!) один доклад, который «точно интересен».

    Ещё не стоит забывать про 5ый трек: беседы в кулуарах. Часто встречается отзыв «в такой-то слот не было интересных докладов, и вместо этого беседовали со знакомыми».
    Это что плохо что-ли? По-моему, так это успех. Возможно, не насколько успешный, но успех.
  • Реактивный мир: открытый бесплатный доступ к докладам конференции Joker 2018 + обзор лучшей десятки
    +8
    Рейтинг строится на основе опроса участников конференции.
    Оценки Превосходно, Хорошо, Нормально, Плохо превращаются в цифры и считается среднее арифметическое (по сути это rangevoting.org )

    Но тут может возникнуть ситуация, что какой-нибудь коварный докладчик позовёт своих друзей на доклад, и они все поставят оценку «Превосходно». Может ли доклад с 10-ю слушателями быть «лучшим докладом конференции»? Конечно, может и такое быть. Но на Joker'е все доклады массовые. Минимальный зал был на 300 кресел.

    Чтобы такого не получалось, в оценки каждого доклада подмешиваются несколько нулевых оценок (всем одинаковое количество, и оно равно 5-10% от общего количества слушателей конференции). В результате доклады с небольшим количеством слушателей получают меньший рейтинг, чем аналогичные по средней оценке, но с большим количеством слушателей. Эта же процедура описана тут: rangevoting.org/BetterQuorum.html

    Это всё теория. На практике есть много интересных эффектов.

    Самый суровый — «проклятие главного зала». Практика показывает, что в «главный зал» идут даже те, кто исходно на доклад не планировал. Возможно, считают, что «раз главный зал, то и доклады самые хорошие». Возможно, лень уходить с прошлого доклада. В подобных случаях получаются отзывы в духе «Плохо: ничего нового, ничего непонятно, вода какая-то».
    Докладчик виноват что-ли? А что ему с таким отзывом делать? Беда да и только.

    Понятие «крутой» доклад у каждого своё (кому-то нужно Spring, а кому-то кишки JVM), и вовсе неправда, что «в главном зале всегда самый крутой». В выборе доклада может помочь докладчик (он-то свой доклад знает) и программный комитет (ПК).

    Или так: если во время доклада пару раз моргнёт проектор, то всё, гарантировано будут отзывы «Плохо: проектор не работал, было плохо видно».
    И это при том, что есть отдельный вопрос по техническому оснащению площадки. Там и стоит написать «у вас моргал проектор в 4-ом зале когда кто-то клал сотовый рядом с ноутбуком».
    Но зачем докладчику-то писать про неработающий проектор? И зачем портить настроение докладчику? Зачем портить рейтинг?

    Или так: доклад на английском языке. Об этом написано и в программе, и докладчик недвусмысленно говорит. Обязательно будет пара отзывов в таком духе: «Плохо: из-за знания английского половина доклада осталась непонятной». Да. Прямо по-русски. Докладчик виноват что-ли? Зачем ставить «Плохо», если проблем в докладе и подаче не было? К слову: ПК проводит репетиции и с англоговорящими докладчиками. Иногда советуют «не употреблять непереводимую игру слов», но в большинстве своём английский язык у докладчиков не родной, и они говорят очень простыми словами.

    Но есть и обратные примеры. На каждой конференции встречается (несколько) человек, которые в комментарях к оценке доклада дополнительно пишут разбивку: «подача-5, полезность-2, применимость-4, новизна-5». Лучи добра таким писателям. И докладчику понятно, и ПК помогает сделать выводы.
  • Строители против синтаксиса Java
    0
    bsideup, справедливости ради, пункт №2 решается, если методы withStrategy, withConfig и прочие принимают аргументы типа Builder.
    Да, пущай они сами вызовут .build(), зато в клиентском коде этого мусора не будет. Или я чего-то упускаю?

    В простых случаях может быть даже такое: withStrategy(KafkaContainerStrategy::builder);
  • Я так хотел попасть в программный комитет конференции, и вот я здесь, и что мы будем делать?
    +1
    Всё так и есть. Именно поэтому в 1ом пункте выводов Роман советует работать с каждым докладом, во 2ом рекомендует не затягивать работу с докладом, и не мариновать докладчиков, в 3-ем пункте настоятельно рекомендует увеличивать полезность каждого выступления. При этом статья начинается с помощи в том «как искать смысл в потенциальном докладе» (== как направить мысль докладчика в правильное русло) и продолжается тем, что ПК должен всегда помнить, что доклад готовит докладчик, а не программный комитет, и что программному комитету стоит воздержаться от советов в духе «выбрось всё, и сделай вот так».

    Безусловно, эти пункты просто пропитаны негативом по отношению к докладчикам.
  • Я так хотел попасть в программный комитет конференции, и вот я здесь, и что мы будем делать?
    +1
    Роман, а была ли статья «а зачем мне вообще идти в ПК»?
    Текущая больше похожа на продолжение, чем на мотивацию идти в ПК.
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    +2
    осталось процентов 10. Но не похоже чтобы они могли повлиять на производительность


    1) У вас не реализован парсинг functionType, а это довольно мутная часть языка (леворекурсивная и всё такое)

    2) У вас не реализован парсинг functionLiteral, а это тоже непростой синтаксис. Например, в конструкции class Child: Parent by delegateMethod { ... } фигурные скобки могут быть как телом класса Child, так и лямбдой-параметром к методу delegateMethod

    В общем, предлагаю сначала пройти хотя бы те тесты, которые проходит ANTLR парсер, а потом уже делать какие-либо сравнения.
  • Я так хотел попасть в программный комитет конференции, и вот я здесь, и что мы будем делать?
    0
    А почему обтекаемый отказ не даёт возможности вернуть события в позитивное русло?
    Или под обтекаемым отказом считается и полнейший уход в обтекаемые фразы на любые последующие уточняющие вопросы докладчика?

    Если на обтекаемые фразы докладчик начнёт по-нормальному спрашивать, то можно ли ему отвечать менее обтекаемо?
  • Я так хотел попасть в программный комитет конференции, и вот я здесь, и что мы будем делать?
    +2
    Супер!

    В пункт «как искать смысл» можно добавить, что «понимание в тематике доклада» всё-таки помогает искать смыслы.

    В «тревожные звоночки» можно смело записывать «парный доклад».

    В «прогоны» (которые стоит называть репетициями) стоит добавить самый важный пункт: «проверяйте, что название соответствует содержимому». И пункт о том, что в конце доклада должны быть выводы (которые как бы отвечают на вопросы из раздела «Как искать смысл»)
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    0
    К слову, в ANTLR грамматике какая-то самодеятельность: callExpression в официальной Kotlin грамматике отсутствует. Из-за подобного растёт неоднозначность, время парсинга и наверняка будут ошибки
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    0
    В начале статьи лишь слова «размер джара (парсера) = 1.4МБ».
    Слово jcommon в статье вообще не встречается.
    log4j тоже не встречается.
    То, что в JetBrains парсер входит Kotlin runtime тоже нигде не говорится.
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    +1
    JavaCC парсер пока содержит не всю грамматику

    А какой процент unit-test'ов (я про официальные Kotlin тесты) проходит этот парсер?

    Например, JavaCC парсер считает, что -789 относится к определению переменной x, хотя это, очевидно, не так:

    fun getResult() {
    val x = 123 + 456
    - 789
    }
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    0
    Как тут можно что-то не так понять?

    Ясно как: никому и в голову не придёт, что вы, помимо необходимого, в jar включаете десяток-другой абсолютно лишних зависимостей.
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    0
    Ещё раз: проблема не в конкретных цифрах, а в том, что они означают совсем не то, что читатель предполагает. Вы пишете, что «парсер на ANTLR занимает столько-то», и логично предполагать, что там «парсер+необходимая ANTLR обвязка».
    А по факту же, вы туда вкладываете свои commons (которые занимают половину результитрующего jar), log4j, commons-lang и далее по списку.
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    0
    Стоит упомянуть, что теперь большую часть занимает не ANTLR и не парсер, а yk.yast:common:jar и yk:jcommon:jar
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    0
    1) А зачем в зависимостях указывать <artifactId>antlr4</artifactId>, когда во время выполнения достаточно <artifactId>antlr4-runtime</artifactId>?
    2) Зачем в jar-with-dependencies включать junit и hamcrest, ведь они только для тестов нужны? Зачем в измеряемый jar включать log4j и commons-lang3, которые вообще не используются в коде? Измерять нужно не jar-with-dependencies, а результат работы maven-shade-plugin'а. Либо оставляйте только реально нужные зависимости. Если всю эту ерунду удалить, то получается где-то 1 мегабайт.
    3) Если удалить и yk/jcommon, то получается похоже на результат KvanTTT
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    0
    Если бы речь шла о скорости работы SQL запроса в enterprise приложении, то, да, её можно и без JMH измерить. А тут наоборот: JMH проще, быстрее и точнее.

    1) Вообще говоря, «производительность» автор объявляет первым требованием
    2) В JMH без проблем можно измерять «холодный старт». И измерять это можно более полно, т.к. в JMH есть встроенный механизм Forks — будут запускаться отдельные Java машины
    3) Код на JMH гораздо компактнее, чем «рукописный». В итоге, человеку со стороны проверить гораздо проще
    4) В JMH встроено много разнообразных профайлеров. Автор приводит цифры без какого-либо анализа того *почему* цифры именно такие
  • Компилируем Kotlin: JetBrains VS ANTLR VS JavaCC
    +3
    1) 21-ый век на дворе, а JMH почему-то не пахнет. Как так? Набросал замер на JMH — получается, что IntelliJ парсер в 4 раза быстрее чем JavaCC.
    2) GaugeKotlinIntellijParser зачем-то пересоздаёт окружение при каждом парсинге. Зачем так? Его же переиспользовать можно и нужно.
    3) yk.jcommon.utils.IO#readFile(java.lang.String) не закрывает файл
  • Нагрузочное тестирование: с чего начать и куда смотреть
    0
    Наверняка, я видел далеко не все нагрузочные тесты в Netcracker, но Gatling наблюдать не приходилось. Полагаю, дело в том, что, в подавляющем большинстве случаев, нам миллионы запросов в секунду не нужны. В JMeter'е более-менее пишутся сложные тесты (зайти туда-то, нажать такую-то кнопку и т.п.), и порог вхождения невелик.
  • Нагрузочное тестирование: с чего начать и куда смотреть
    +1
    Зависит от проекта, но сам по себе браузерный тест приходится использовать тогда, когда нужно измерить время работы end-to-end (довольно часто хватает отдельного тестирования серверной части и сбора базовых метрик с QA).

    Если интересно, могу рассказать об этом на https://heisenbug-moscow.ru/ 8-9 декабря

    Selenium в нагрузке используется в двух вариациях:
    1) Основную нагрузку подаём JMeter'ом, а Selenium запускаем в штучном количестве. При этом backend загружен на должном уровне, из Selenium'а получаем времена работ браузера (с учётом всех JS/CSS), и не требуется держать огромный ботнет этих самых Selenium'ов. Понятие «огромный», конечно, растяжимо, поэтому я под ним понимаю «более 1-2 браузеров».
    2) Нагрузку подаём армией из Selenium'ов. Тут требуется больше нагрузочных машин чем в варианте №1, но при этом мы получаем больше данных за ту же длительность тестирования. Больше размер выборки — больше точность, и больше выбросов мы можем поймать.

    Как строится тест?

    В чём вопрос? Тест либо пишется специально (наиболее востребованный и/или подозрительный в плане производительности), либо адаптируется имеющийся функциональный. Как правило, в функциональных тестах много разнообразных проверок, которые в нагрузке не столь важны, поэтому 1-в-1 брать не получается.
  • Реализация интерактивных диаграмм с помощью ООП на примере прототипа редактора UML-диаграмм. Часть 2
    0
    Ещё библиотека-фреймворк (LGPL) на тему диаграмм: http://www.adaptagrams.org/ (пример интеграции в Swing приложение: http://mbeddr.com/2015/03/05/graphicalSM.html)