1. Тут Вы правы. Готов согласиться с компилятором/парсером вначале, и даже пожалуй это стоит поменять в статье! Например, пресловутый spotbugs по-другому и не может, т. к. анализирует байт-код. Есть экзотические случаи, например, в пайплайне для Ansible playbooks статический анализ лучше ставить перед парсингом, т. к. там он легковеснее. Но это именно что экзотика )
2. Вариант с фиксацией количества срабатываний относительно релиза – мне он намного менее симпатичен… — ну да, он менее симпатичен, менее техничен, зато очень практичен :-) Главное — это общий метод, руководствуясь которым я, имея любую кодовую базу и любой анализатор (не обязательно ваш), используя палки и желуди groovy и shell скрипты на CI, могу эффективно внедрить статанализ — где угодно, в сколь угодно страшном проекте. Кстати, вот сейчас мы подсчитываем ворнинги в разбивке по модулям и тулам, но если разбить ещё более гранулированно (по файлам), то это будет ещё ближе к методу сравнения старых/новых. Но у нас прижилось так, и я как-то полюбил этот ratcheting за то, что он стимулирует разрабов следить за общим количеством ворнингов и сбивать это количество потихоньку. Если бы был метод старых/новых, стимулировало ли бы это разрабов следить за кривой количества ворнингов? — может быть, да, может, нет.
По п. 3 ответили ниже, сейчас продолжу ответ в той ветке.
Евгений, большое спасибо за содержательный отзыв на статью! Да, мою озабоченность насчёт «действия на неокрепшие умы» в моём посте Вы уловили совершенно правильно!!!
Причём обвинять-то здесь никого нельзя, т. к. авторы статей/докладов про анализаторы не имеют задачи делать статьи / доклады про анализ. Но после недавних постов Andrey2008 и lany я решил, что больше не могу молчать )))
Спасибо за отзыв!
1. Ну это лотерея. Из моего опыта — где-то найдёт, где-то не найдёт. Я пытался донести в статье, что не стоит надеяться на одноразовое применение.
2. Я имел в виду примеры «реально найденных багов» из статей про анализаторы. Они конечно реально найденные, но искать их именно в том проекте никто не просил.
Вопрос к Артёму, переход JUnit4->JUnit5 был заявлен как один из вариантов использования даже в описании доклада. Наверное, Артёму всё же по ходу нужно было конвертировать хитрые аннотации Allure. А может быть, он (как и я) не знал о том, что такая инспекция вообще есть и её можно включить )))
Интересно, как ею воспользоваться? 2018.2 Ultimate. Взял проект с Junit4. Не показывает квикфикс над тестовым классом. ОК, затянул в Мавен всю историю с JUnit5. Не показывает квикфикс )))
Понятно! Каждый случай диктует свои ограничения. Просто, раз уж там всё в докерах, я бы, например, попытался Terraform-ом поднимать машину, ставя на неё докер и присоединяя к Swarm, а потом использовать Swarm rolling update. Впрочем, советы давать как сделать лучше — это не мешки ворочать))
Спасибо большое за доклад, имхо больше народу должны знать про Terraform и использовать его в повседневной работе!
Глубоко задумался над тем, что же такого плохого в докладах про PageObject :-)) Если доклад содержательный — всегда найдётся много тех, кому он полезен, среди людей, желающих прокачаться в той или иной теме (а зачем ещё делают доклады и конференции)? Ну и всегда найдутся люди, которые заявят: «это и так известно и никому не нужно».
Не за что, мне это всё равно скоро предстоит писать-объяснять)
В Celesta 6.x в папке score лежат CelestaSQL-скрипты + Python-код + кодогенерированные на Python классы доступа. Python-код запускается через celesta.runPython("proc.name"...). Необходим внешний сервис, который выполняет метод runPython (чаще всего Flute).
В Celesta 7.x в папке score челесту интересуют исключительно SQL-ники. Классы доступа кодогенерируются на Java (например, с помощью celesta-maven-plugin). Точка входа на уровне сервисных классов выглядит так:
@Service
public class HelloService {
@CelestaTransaction
public String hello(CallContext cc) {
....
}
}
В этом случае HelloService может запускаться из контроллера, например
@Autowired
HelloService srv;
@GetMapping(value = "/{name}")
public String hello(@PathVariable String name) {
CallContext cc = new CallContext(name);
return srv.hello(cc);
}
И тут уже не важно, на чём написан контроллер и сервис. Может на Java, может на Groovy. Может, на Kotlin. А может — почему нет? — на JRuby или всё том же Jython. В последних двух случаях надо с интеграцией повозюкаться, но в целом не вижу проблемы. Интересное свойство JRuby паковаться в .jar/.war тут может помочь.
Касательно C-extensions — у JRuby, естественно, нет прямой совместимости с ними. Но, со слов Чарльза, это не большая беда, т. к. всего несколько процентов Ruby-библиотек их используют, а для самых важных Ruby-библиотек, зависящих от C (например, парсер XML) написаны «Java-заменители».
Всё это — со слов самого Чарльза, конечно. Но говорил он убедительно
Я смотрел и на Groovy, и на JRuby. Но тогда Jython казался лучшим выбором: перспективный язык Python, живой (тогда) проект, легко встроить в Java-приложение. В итоге через несколько лет мы получили: 1) отставание от спецификации языка 2) с большинством библиотек из pip либо несовместимость, либо просадка по производительности 3) баги в самой имплементации языка. Жить, однако, можно. По утверждениям Чарльза, всех этих проблем в JRuby нет. Как оно обстоит на самом деле — это надо слушать независимые свидетельства :-)
Касательно же Celesta — новости близко!!! :-) На одном из наших проектов мы используем ветку версии 7.x. Сейчас мы доведём до ума эту ветку, доработаем тесты, обновим документацию и тогда я где-нибудь напишу пост. Если вкратце, произошло вот что:
1) вовсе убрали из Celesta зависимость от Jython,
2) кодогенерируем классы курсоров на чистой Java, а не на Python,
3) сделали spring-boot-starter и в целом теперь основной сценарий использования Celesta 7.x — это бэкенд на спрингбуте, всё это должно стать гораздо интереснее Java-разработчикам,
4) инвертировали контроль — теперь не Celesta вызывает процедуры, а из процедур используется Celesta как сервис. Т.е. это значит, что Celesta становится возможно использовать из любого JVM языка. На практике — мы уже сейчас пишем на Celesta в чистой Java. Я, возможно, для статьи сделаю демо-пример на Groovy.
Увы и ах, всё это — дорогой ценой того, что вся написанная на Jython-е кодовая база перестала быть совместимой. Но надо двигаться дальше с новыми проектами. Jython-ориентированную ветку 6.x и все Jython-проекты мы будем поддерживать ещё долго.
Очень круто, что ребята позвали Чарльза, для меня это был актуальный и полезный доклад.
Языку Ruby, конечно, здорово повезло, что в него зашёл такой человек, как Чарльз — и теперь есть JRuby. Который, оказывается, не просто «ещё одна» имплементация языка, а по многим параметрам лучшая имплементация языка, важный игрок в экосистеме Ruby, подпитывающий экосистему со своей стороны.
К сожалению, такого не произошло с Python. Когда несколько лет назад мы начинали использовать Jython, это был ещё живой проект, сейчас же его развитие слишком медленное, а проблемы накапливаются как снежный ком. При том что у стратегически у проекта Jython были все шансы оказаться успешнее, чем JRuby — в силу популярности и востребованности языка Python в наше время. Ставка, в своё время сделанная нами на Jython, надо это признать, проиграла. Выбери мы Groovy или JRuby — результат был бы лучше.
C JRuby я вижу только одну проблему. Ruby мне не очень нравится как язык — он наследник Perl с его «there's more than one way to do it», и потому там легко наколбасить «эзотерический» код )
Спасибо. Я спрашиваю не чтобы подвергнуть сомнению то, что вы предлагаете — просто я сам ломаю голову над тем, как поощрять чтение технической литературы в компании. И пока не вижу лёгких путей.
В книге DDIA 12 глав. Реально было 12 встреч? С перерывами на отпуска/больничные/«завтра дедлайн, давайте пропустим» сколько же месяцев это заняло? Не было соблазна забить? (Это книга большая и трудная, понятно что с другими полегче, но вообще это показательная штука.)
Вопрос про совместное чтение. Насколько я понял, вы распределяете главы книги по людям и каждому требуется прочитать за неделю назначенную главу и подготовить докладик. А если есть логическая связь между главами? Для некоторых книг ведь невозможно читать одну главу, вырвав из контекста.
(DDIA — великолепная книга, ликбез по большому кругу вопросов, must read для современного архитектора приложений)
Значит, Yarg больше нацелен на широту форматов вывода.
Xylophone работает только на электронных таблицах, всё строится вокруг модели прямоугольных диапазонов, которые «прирастают» снизу или сбоку и worksheet-ов. В PDF выводить он может, но это понятно что — это таблица, отрисовываемая через XSL-FO. Потенциально можно было бы сделать HTML-вывод, но не было такого юзкейса.
Мы пытались сделать по аналогии репортер для ворда, но недовольны результатом: самое сложное в репортинге в документ ворда — это таблицы, с их merge-ем ячеек получается целая история. Нет, в общем, такой же красивой модели, как в случае с электронной таблицей.
Cлучай, когда заказчик хочет отчёт именно в ворде — довольно редкая история, но случающаяся. В остальных случаях, конечно, проекрасно подходит PDF.
Для интеграции с не-Java-миром: говорите, YARG может работать как микросервис. А какие сервисы он предоставляет как микросервис? Можно ли сформировать из ERP-системы JSON, который скормить YARG-у и он отрисует красивый отчёт на базе этого JSON?
нацелена как на Word, так и на Excel (Xylophone нацелен только на Excel),
потому возможная структура генерируемых отчётов именно на Excel навскидку у Yarg проще, чем у Xylophone. Не вижу примеров с горизонтальной итерацией или итерацией по листам книги (хотя может быть просто плохо смотрю, и тут кубаводы может быть что-то могут сказать)
заточено на использование совместно с кубой (в документации видим визуальные билдеры). Xylophone полностью самодостаточен (хотя опять же, может быть, я недооцениваю самодостаточность yarg)
Насчёт ODF: в Xylophone разделены механизмы формирования отчёта (копирования кусков шаблона и подстановки выражений в ячейки) и формирования собственно выходного документа.
Поэтому добавить в Xylophone ODF-вывод является нетрудной задачей, и более того, есть уже даже класс ODFReportWriter, который, однако, в текущий момент — заглушка. За всё время реализовать поддержку ODF так и не потребовалось. Но мы принимаем пулл реквесты))
2. Вариант с фиксацией количества срабатываний относительно релиза – мне он намного менее симпатичен… — ну да, он менее симпатичен, менее техничен, зато очень практичен :-) Главное — это общий метод, руководствуясь которым я, имея любую кодовую базу и любой анализатор (не обязательно ваш), используя
палки и желудиgroovy и shell скрипты на CI, могу эффективно внедрить статанализ — где угодно, в сколь угодно страшном проекте. Кстати, вот сейчас мы подсчитываем ворнинги в разбивке по модулям и тулам, но если разбить ещё более гранулированно (по файлам), то это будет ещё ближе к методу сравнения старых/новых. Но у нас прижилось так, и я как-то полюбил этот ratcheting за то, что он стимулирует разрабов следить за общим количеством ворнингов и сбивать это количество потихоньку. Если бы был метод старых/новых, стимулировало ли бы это разрабов следить за кривой количества ворнингов? — может быть, да, может, нет.По п. 3 ответили ниже, сейчас продолжу ответ в той ветке.
Причём обвинять-то здесь никого нельзя, т. к. авторы статей/докладов про анализаторы не имеют задачи делать статьи / доклады про анализ. Но после недавних постов Andrey2008 и lany я решил, что больше не могу молчать )))
1. Ну это лотерея. Из моего опыта — где-то найдёт, где-то не найдёт. Я пытался донести в статье, что не стоит надеяться на одноразовое применение.
2. Я имел в виду примеры «реально найденных багов» из статей про анализаторы. Они конечно реально найденные, но искать их именно в том проекте никто не просил.
Вопрос к Артёму, переход JUnit4->JUnit5 был заявлен как один из вариантов использования даже в описании доклада. Наверное, Артёму всё же по ходу нужно было конвертировать хитрые аннотации Allure. А может быть, он (как и я) не знал о том, что такая инспекция вообще есть и её можно включить )))
Спасибо большое за доклад, имхо больше народу должны знать про Terraform и использовать его в повседневной работе!
Не за что, мне это всё равно скоро предстоит писать-объяснять)
В Celesta 6.x в папке score лежат CelestaSQL-скрипты + Python-код + кодогенерированные на Python классы доступа. Python-код запускается через
celesta.runPython("proc.name"...). Необходим внешний сервис, который выполняет метод runPython (чаще всего Flute).В Celesta 7.x в папке score челесту интересуют исключительно SQL-ники. Классы доступа кодогенерируются на Java (например, с помощью celesta-maven-plugin). Точка входа на уровне сервисных классов выглядит так:
В этом случае HelloService может запускаться из контроллера, например
И тут уже не важно, на чём написан контроллер и сервис. Может на Java, может на Groovy. Может, на Kotlin. А может — почему нет? — на JRuby или всё том же Jython. В последних двух случаях надо с интеграцией повозюкаться, но в целом не вижу проблемы. Интересное свойство JRuby паковаться в .jar/.war тут может помочь.
Касательно C-extensions — у JRuby, естественно, нет прямой совместимости с ними. Но, со слов Чарльза, это не большая беда, т. к. всего несколько процентов Ruby-библиотек их используют, а для самых важных Ruby-библиотек, зависящих от C (например, парсер XML) написаны «Java-заменители».
Всё это — со слов самого Чарльза, конечно. Но говорил он убедительно
Касательно же Celesta — новости близко!!! :-) На одном из наших проектов мы используем ветку версии 7.x. Сейчас мы доведём до ума эту ветку, доработаем тесты, обновим документацию и тогда я где-нибудь напишу пост. Если вкратце, произошло вот что:
1) вовсе убрали из Celesta зависимость от Jython,
2) кодогенерируем классы курсоров на чистой Java, а не на Python,
3) сделали spring-boot-starter и в целом теперь основной сценарий использования Celesta 7.x — это бэкенд на спрингбуте, всё это должно стать гораздо интереснее Java-разработчикам,
4) инвертировали контроль — теперь не Celesta вызывает процедуры, а из процедур используется Celesta как сервис. Т.е. это значит, что Celesta становится возможно использовать из любого JVM языка. На практике — мы уже сейчас пишем на Celesta в чистой Java. Я, возможно, для статьи сделаю демо-пример на Groovy.
Увы и ах, всё это — дорогой ценой того, что вся написанная на Jython-е кодовая база перестала быть совместимой. Но надо двигаться дальше с новыми проектами. Jython-ориентированную ветку 6.x и все Jython-проекты мы будем поддерживать ещё долго.
Языку Ruby, конечно, здорово повезло, что в него зашёл такой человек, как Чарльз — и теперь есть JRuby. Который, оказывается, не просто «ещё одна» имплементация языка, а по многим параметрам лучшая имплементация языка, важный игрок в экосистеме Ruby, подпитывающий экосистему со своей стороны.
К сожалению, такого не произошло с Python. Когда несколько лет назад мы начинали использовать Jython, это был ещё живой проект, сейчас же его развитие слишком медленное, а проблемы накапливаются как снежный ком. При том что у стратегически у проекта Jython были все шансы оказаться успешнее, чем JRuby — в силу популярности и востребованности языка Python в наше время. Ставка, в своё время сделанная нами на Jython, надо это признать, проиграла. Выбери мы Groovy или JRuby — результат был бы лучше.
C JRuby я вижу только одну проблему. Ruby мне не очень нравится как язык — он наследник Perl с его «there's more than one way to do it», и потому там легко наколбасить «эзотерический» код )
В книге DDIA 12 глав. Реально было 12 встреч? С перерывами на отпуска/больничные/«завтра дедлайн, давайте пропустим» сколько же месяцев это заняло? Не было соблазна забить? (Это книга большая и трудная, понятно что с другими полегче, но вообще это показательная штука.)
(DDIA — великолепная книга, ликбез по большому кругу вопросов, must read для современного архитектора приложений)
Значит, Yarg больше нацелен на широту форматов вывода.
Xylophone работает только на электронных таблицах, всё строится вокруг модели прямоугольных диапазонов, которые «прирастают» снизу или сбоку и worksheet-ов. В PDF выводить он может, но это понятно что — это таблица, отрисовываемая через XSL-FO. Потенциально можно было бы сделать HTML-вывод, но не было такого юзкейса.
Мы пытались сделать по аналогии репортер для ворда, но недовольны результатом: самое сложное в репортинге в документ ворда — это таблицы, с их merge-ем ячеек получается целая история. Нет, в общем, такой же красивой модели, как в случае с электронной таблицей.
Cлучай, когда заказчик хочет отчёт именно в ворде — довольно редкая история, но случающаяся. В остальных случаях, конечно, проекрасно подходит PDF.
Для интеграции с не-Java-миром: говорите, YARG может работать как микросервис. А какие сервисы он предоставляет как микросервис? Можно ли сформировать из ERP-системы JSON, который скормить YARG-у и он отрисует красивый отчёт на базе этого JSON?
Поэтому добавить в Xylophone ODF-вывод является нетрудной задачей, и более того, есть уже даже класс ODFReportWriter, который, однако, в текущий момент — заглушка. За всё время реализовать поддержку ODF так и не потребовалось. Но мы принимаем пулл реквесты))