Согласен с предыдущими комментаторами, что сильно зависит от вида занятий. Я лично видел людей, которым не особо нравились силовые тренировки и кардио, но которые чуть ли не светились после занятия по спортивной/силовой йоге.
Очень похоже, что подделка – на настоящих с торца есть зеленая надпись Wago. На ютюбе есть сравнения, и там показано, насколько тоньше пластина в подделке.
Сразу скажу, что мой ответ не для флейма, я просто постараюсь объяснить свою позицию. Я с большим уважением отношусь и к SJK Алексея, и к вашему, Андрей, async-профайлеру.
В SJK мне нравится, во-первых, вывод в html+js, он намного удобнее svg. Он, например, позволяет выделить фрейм, и он подсветится в нескольких стек трейсах, и выдаст суммарную частоту, с которой этот фрейм встречался. И это мне действительно было полезно в работе, когда, например, в сумме по трём стэкам один фрейм встречался с частотой в 77%.
А во вторых, я профилирую энтерпрайз-приложения, которые находятся в зелёной зоне кривой Шипилёва, то есть мне нет никакой необходимости ни в нативных стеках, ни в том, чтобы профайлер был лишён проблемы safepoint bias. Обычно мои перформанс-слонопотамы отнимают 60-80% работы программы. Их с любым профайлером будет видно, просто мне нравятся флейм-графы за их наглядность.
Я часто пользуюсь SJK для снятия флейм-графов с джава-приложений. У неё есть несколько достоинств:
не обязательно прописывать дополнительные флаги для приложения, то есть можно снимать прямо на проде;
не нужен перл-скрипт для получения svg, всё уже есть внутри;
кроме svg, она умеет выдавать html+js, в котором можно динамически включать-выключать потоки, или, например, посмотреть более крупно только тот стек вызовов, который нас интересует.
Из недостатков можно отметить, что стек не будет включать нативные вызовы ОС (зеленая часть на графиках в статье), но для моих задач возможностей SJK было более чем достаточно.
Про dynamic sampling, я думаю, стоит сказать, что он работает только на фазе hard parse. Как и «подсматривание параметров», оно же bind peeking. И это довольно сильно ограничивает его полезность. Потому что если запрос уже разобран, и есть план выполнения в кэше, никакого динамического сэмплирования не случится.
Мы используем Flyway (правда для Оракла), можно использовать Liquibase.
И там, и там, есть repeatable миграции. Во Флайвее это те, что начинаются с буквы R. А в Liquibase это делается через атрибут runOnChange.
Ну я к тому, что если хочется нормализации, то можно ввести сущность «роль на проекте», и к ней уже прилинковать скиллы.
А если есть желание автоматически раскладывать из какого-нибудь hh.ru по табличкам, то там будет прямо набор скиллов у человека. Или набор скиллов у человека на конкретном проекте. То есть схема в обоих случаях будет другая.
Я думаю, что скиллы неправильно так привязывать к проекту. Потому что, например, в одном и том же проекте могут работать специалисты по фронтенду, бэкэнду, и, например, девопсу. Это не говоря уже о тестировщиках и аналитиках. И скиллы у всех этих групп будут разные.
Мне больше нравится другое определение Закона Деметры – через пример.
Когда вы хотите что-то купить, надо дать деньги, а не, например, кошелёк, из которого можно взять деньги.
То есть в методы надо передавать минимально, только то, что им нужно, а не какой-то объект-контейнер, из которого это что-то можно достать.
Мой коллега для этого использует javacc, там файл грамматики как бы смешан с джава-кодом, в чем есть как минусы (не такое красивое разделение, как в ANTLR), так и плюсы (гибкость, и, если все сделать правильно, производительность)
У нас сейчас ретро раз в спринт (2 недели), где мы делаем всё, что тут описано, но приходить туда совсем не хочется. Потому что на ретро мы высасываем проблемы из пальца, а потом голосуем, обсуждаем, и принимаем какие-то решения, которые никому не интересны, потому что и проблем-то, по большому счету, не было.
открыть курсор без хранимки — это, например, выполнить вот такой код:
begin
open :p_cursor for
select *
from my_table t
where t.business_date = :p_business_date
and t.account_id = :p_account_id
order by t.time_stamp desc;
end;
В PL/SQL Developer'е это делается в Test Window. Он сам находит, что в этом куске кода три переменных привязки. И, соответственно, указывается, что p_cursor — это курсор, p_business_date — дата (с указанием конкретной), а p_account_id — число (с указанием конкретного). Можно этот кусок кода выполнить, потом кликнуть на многоточие рядом со словом p_cursor в табличке с переменными привязки, и увидеть результат.
Это очень удобно, когда хочется позапускать запрос, который тормозит, и причем обязательно сделать это с переменными привязки, а не с литералами, потому что с литералами будет другой план выполнения. А тут можно взять один плохо работающий запрос, и позапускать его, в условиях, максимально близких к тому, как это работает в хранимке (или к тому, как он запускается, например, из Джавы). И можно, пока он работает, в бэкграунде в браузере сессий его найти, и посмотреть план выполнения, и SQL Monitoring Report, если он есть. На этом этапе можно найти проблему с запросом, и поправить её.
Собственно, поэтому и хочется видеть в DataGrip (а точнее в Idea Ultimate) и некий аналог Test Window, для удобного (!) запуска с переменными привязки; и настраиваемый браузер сессий.
Поддерживаю, у PL/SQL Developer’а есть две фичи, которых я больше нигде не видел, и которые невероятно удобны.
Test Window, где можно задать любой блок кода, и выполнить его, задав переменные привязки. Особенно удобно это с курсорами. Я попробовал это в IntelliJ Idea. У меня, конечно, получилось запустить хранимку, которая возвращает курсор, но удобство так себе. Как и в Oracle SQL developer. А просто открыть курсор, и посмотреть его, без хранимки, и вообще никак, а я этим постоянно пользуюсь для отладки запросов.
вторая фича – это гибко настраиваемый браузер сессий. Можно настроить любые запросы, например сессии с открытыми транзакциями; сессии, которые съели много темпа; сессии из dba_blockers/dba_waiters и так далее. И в дочернем гриде тоже можно настроить любые запросы, например SQL Monitoring report, план выполнения, события одидания сейчас, и накопленные за сессию/стейтмент. У ДатаГрипа вообще пока нет браузера сессий.
Вызов метода в конструкторе (да и вообще любой код, кроме присваивания полей) – тоже антипаттерн (смотри, например, Мишко Хевери), потому что это нарушает тестируемость кода. Вы не сможете вызвать конструктор, и не вызвать метод init. Уж лучше в таком случае оставить @PostConstruct. А еще лучше сделать фабрику, которая в нужном порядке проинициализирует нужные вам объекты, и в ней не будет никакой магии вроде @PostConstruct, и уже эту фабрику вызвать в @Configuration-файле.
Коллега рассказывал, что они переводили проекты с разных языков программирования на Джаву, в том числе и с Кобола. И делали они это при помощи грамматики, написанной на JavaCC.
В опросе нет такого пункта, что использовал бы парсер-генератор, но другой.
Согласен с предыдущими комментаторами, что сильно зависит от вида занятий. Я лично видел людей, которым не особо нравились силовые тренировки и кардио, но которые чуть ли не светились после занятия по спортивной/силовой йоге.
Очень похоже, что подделка – на настоящих с торца есть зеленая надпись Wago. На ютюбе есть сравнения, и там показано, насколько тоньше пластина в подделке.
У меня был LandStalker с возможностью сохранения для Sega MegaDrive 2, всё работало.
промахнулся веткой, ответил в общий тред случайно
Сразу скажу, что мой ответ не для флейма, я просто постараюсь объяснить свою позицию. Я с большим уважением отношусь и к SJK Алексея, и к вашему, Андрей, async-профайлеру.
В SJK мне нравится, во-первых, вывод в html+js, он намного удобнее svg. Он, например, позволяет выделить фрейм, и он подсветится в нескольких стек трейсах, и выдаст суммарную частоту, с которой этот фрейм встречался. И это мне действительно было полезно в работе, когда, например, в сумме по трём стэкам один фрейм встречался с частотой в 77%.
А во вторых, я профилирую энтерпрайз-приложения, которые находятся в зелёной зоне кривой Шипилёва, то есть мне нет никакой необходимости ни в нативных стеках, ни в том, чтобы профайлер был лишён проблемы safepoint bias. Обычно мои перформанс-слонопотамы отнимают 60-80% работы программы. Их с любым профайлером будет видно, просто мне нравятся флейм-графы за их наглядность.
Я часто пользуюсь SJK для снятия флейм-графов с джава-приложений. У неё есть несколько достоинств:
Из недостатков можно отметить, что стек не будет включать нативные вызовы ОС (зеленая часть на графиках в статье), но для моих задач возможностей SJK было более чем достаточно.
Про dynamic sampling, я думаю, стоит сказать, что он работает только на фазе hard parse. Как и «подсматривание параметров», оно же bind peeking. И это довольно сильно ограничивает его полезность. Потому что если запрос уже разобран, и есть план выполнения в кэше, никакого динамического сэмплирования не случится.
Хорошая статья. Только для того, чтобы убрать «лишний» код в виде конструкторов необязательно переходить на Котлин. Достаточно использовать Ломбок.
Мы используем Flyway (правда для Оракла), можно использовать Liquibase.
И там, и там, есть repeatable миграции. Во Флайвее это те, что начинаются с буквы R. А в Liquibase это делается через атрибут runOnChange.
Ну я к тому, что если хочется нормализации, то можно ввести сущность «роль на проекте», и к ней уже прилинковать скиллы.
А если есть желание автоматически раскладывать из какого-нибудь hh.ru по табличкам, то там будет прямо набор скиллов у человека. Или набор скиллов у человека на конкретном проекте. То есть схема в обоих случаях будет другая.
Я думаю, что скиллы неправильно так привязывать к проекту. Потому что, например, в одном и том же проекте могут работать специалисты по фронтенду, бэкэнду, и, например, девопсу. Это не говоря уже о тестировщиках и аналитиках. И скиллы у всех этих групп будут разные.
Мне больше нравится другое определение Закона Деметры – через пример.
Когда вы хотите что-то купить, надо дать деньги, а не, например, кошелёк, из которого можно взять деньги.
То есть в методы надо передавать минимально, только то, что им нужно, а не какой-то объект-контейнер, из которого это что-то можно достать.
Мой коллега для этого использует javacc, там файл грамматики как бы смешан с джава-кодом, в чем есть как минусы (не такое красивое разделение, как в ANTLR), так и плюсы (гибкость, и, если все сделать правильно, производительность)
У нас сейчас ретро раз в спринт (2 недели), где мы делаем всё, что тут описано, но приходить туда совсем не хочется. Потому что на ретро мы высасываем проблемы из пальца, а потом голосуем, обсуждаем, и принимаем какие-то решения, которые никому не интересны, потому что и проблем-то, по большому счету, не было.
Я, может, что-то пропустил, но я не понял, зачем переходить с mySQL на PostgreSQL? mySQL чем-то не устраивал?
открыть курсор без хранимки — это, например, выполнить вот такой код:
В PL/SQL Developer'е это делается в Test Window. Он сам находит, что в этом куске кода три переменных привязки. И, соответственно, указывается, что p_cursor — это курсор, p_business_date — дата (с указанием конкретной), а p_account_id — число (с указанием конкретного). Можно этот кусок кода выполнить, потом кликнуть на многоточие рядом со словом p_cursor в табличке с переменными привязки, и увидеть результат.
Это очень удобно, когда хочется позапускать запрос, который тормозит, и причем обязательно сделать это с переменными привязки, а не с литералами, потому что с литералами будет другой план выполнения. А тут можно взять один плохо работающий запрос, и позапускать его, в условиях, максимально близких к тому, как это работает в хранимке (или к тому, как он запускается, например, из Джавы). И можно, пока он работает, в бэкграунде в браузере сессий его найти, и посмотреть план выполнения, и SQL Monitoring Report, если он есть. На этом этапе можно найти проблему с запросом, и поправить её.
Собственно, поэтому и хочется видеть в DataGrip (а точнее в Idea Ultimate) и некий аналог Test Window, для удобного (!) запуска с переменными привязки; и настраиваемый браузер сессий.
Поддерживаю, у PL/SQL Developer’а есть две фичи, которых я больше нигде не видел, и которые невероятно удобны.
А почему не классические Liquibase или Flyway?
Вызов метода в конструкторе (да и вообще любой код, кроме присваивания полей) – тоже антипаттерн (смотри, например, Мишко Хевери), потому что это нарушает тестируемость кода. Вы не сможете вызвать конструктор, и не вызвать метод init. Уж лучше в таком случае оставить @PostConstruct. А еще лучше сделать фабрику, которая в нужном порядке проинициализирует нужные вам объекты, и в ней не будет никакой магии вроде @PostConstruct, и уже эту фабрику вызвать в @Configuration-файле.
Коллега рассказывал, что они переводили проекты с разных языков программирования на Джаву, в том числе и с Кобола. И делали они это при помощи грамматики, написанной на JavaCC.
В опросе нет такого пункта, что использовал бы парсер-генератор, но другой.