Например, перед when могло быть общее действие, которое надо сделать для всех трёх вариантов. Давай что-нибудь добавлю
По-моему, всё равно if лишний. Убрать бы его. Получается, кто-то там может слать недопустимые значения, а мы их игнорируем. Конечно, так и до enum недалеко додуматься, но вопросы остаются.
Если уже 25 вызовов с одним значением ignoreCase, то пора extract method делать.
Разумеется, я поддерживаю, что ругаться должна инспекция "вы тут зря переменную завели, воспользуйтесь лучше именованными параметрами", а не "expression is always true", просто исходно код выглядит стрёмно, и зачастую ожидаемо, что анализатор будет что-то там бурчать, особенно, когда код стрёмный.
Пример про isOption, конечно, нужно вообще без return записывать. Там ни return ни let не нужно: `isOption(s: String?) : Boolean = s?.startsWith("--") ?: false`. Ну или на String.isOption переделать (но это уже от проекта зависит)
А зачем в updatePriority примере нужен был if? Если его убрать, то станет проще читаться и будет проще поддерживать (не придётся дублировать литералы). Правильно оно ругалось на код, по делу.
command.startsWith("--data", ignoreCase) -- тоже по делу ругалось. Если хочется пояснить ignoreCase, то почему бы не использовать для этого именованные параметры? Зачем переменную объявлять? Вот так хорошо: command.startsWith("--data", ignoreCase = true)
Например, в Oracle DB курсоры без проблем переживают операцию commit и продолжают возвращать согласованные данные. Можно открыть курсор, сделать commit (или несколько) и без проблем продолжать выборку из курсора. Разумеется, у долгих курсоров есть шанс наткнуться на ORA-01555 snapshot too old, но это другая история.
Разработчики PostgreSQL почему-то посчитали, что, если транзакцию закрываем, то и курсоры нужно обязательно закрыть. При этом, фиксация транзакций в параллельных потоках никак не влияет.
Типичный подход в Oracle мире для batch обработки: открываем курсор, выбираем 10'000 записей. Обрабатываем, меняем данные, выполняем commit. Выбираем следующие 10'000 (операцией fetch bulk collect into… limit 10000) и так далее. Это позволяет не выполнять выборку каждый раз с нуля, и «выбирающий» курсор не протухает. В PostgreSQL такой подход не работает.
а дальше мы работаем уже с mapped-файлом. Из-за этого получается, что при попытке GC остановить треды в приложении мы очень долго идём в safepoint
Нельзя ли по-медленнее? Я записываю.
Как оказались связаны mmap файлы и длительность TtSP (time to safepoint)? Речь про то, что процесс обращается к памяти, и тут внезапно возникает page fault, и обработка page fault'а растягивает TtSP?
Если бы организаторы стремились к англоязычности, тогда и официальный язык конференции сделали бы английским (ну, открытие-закрытие по-английски,
слайды с приоритетом на английский язык, указатели с приоритетом по-английски и так далее).
Стоит учитывать, что доклад на конференции это не только те 60 минут времени, которые докладчик находится на сцене.
Это и возможность задать вопрос лично (до и после доклада), поэтому в программу конференции мы стараемся привлекать ключевых разработчиков.
То на каком языке говорит докладчик это далеко не единственный (и не главный!) критерий.
Например, я познакомился с René Gröschke на JPoint'е. Стал ли я от этого знатоком Gradle? Едва ли. Но зато стало проще переписываться и я могу переспросить: «Ну, как там мой pull request?».
На Joker'е я познакомился с Rémi Forax. Я его расспросил про ASM (он один из авторов), и он показал занятный проект github.com/forax/exotic. Ну, прямо на ноутбуке открыли код, он показал что к чему.
Конечно, всегда хочется, чтобы все 40+ докладов конференции были очень интересны именно мне.
Скажу честно, доклады про Spring это не моё. Но, ведь, есть и те, кому они нужны и полезны.
На конференции 4 доклада в параллель. Тематики разные, и для меня успех, это когда в каждом слоте есть хотя бы (!) один доклад, который «точно интересен».
Ещё не стоит забывать про 5ый трек: беседы в кулуарах. Часто встречается отзыв «в такой-то слот не было интересных докладов, и вместо этого беседовали со знакомыми».
Это что плохо что-ли? По-моему, так это успех. Возможно, не насколько успешный, но успех.
Рейтинг строится на основе опроса участников конференции.
Оценки Превосходно, Хорошо, Нормально, Плохо превращаются в цифры и считается среднее арифметическое (по сути это rangevoting.org )
Но тут может возникнуть ситуация, что какой-нибудь коварный докладчик позовёт своих друзей на доклад, и они все поставят оценку «Превосходно». Может ли доклад с 10-ю слушателями быть «лучшим докладом конференции»? Конечно, может и такое быть. Но на Joker'е все доклады массовые. Минимальный зал был на 300 кресел.
Чтобы такого не получалось, в оценки каждого доклада подмешиваются несколько нулевых оценок (всем одинаковое количество, и оно равно 5-10% от общего количества слушателей конференции). В результате доклады с небольшим количеством слушателей получают меньший рейтинг, чем аналогичные по средней оценке, но с большим количеством слушателей. Эта же процедура описана тут: rangevoting.org/BetterQuorum.html
Это всё теория. На практике есть много интересных эффектов.
Самый суровый — «проклятие главного зала». Практика показывает, что в «главный зал» идут даже те, кто исходно на доклад не планировал. Возможно, считают, что «раз главный зал, то и доклады самые хорошие». Возможно, лень уходить с прошлого доклада. В подобных случаях получаются отзывы в духе «Плохо: ничего нового, ничего непонятно, вода какая-то».
Докладчик виноват что-ли? А что ему с таким отзывом делать? Беда да и только.
Понятие «крутой» доклад у каждого своё (кому-то нужно Spring, а кому-то кишки JVM), и вовсе неправда, что «в главном зале всегда самый крутой». В выборе доклада может помочь докладчик (он-то свой доклад знает) и программный комитет (ПК).
Или так: если во время доклада пару раз моргнёт проектор, то всё, гарантировано будут отзывы «Плохо: проектор не работал, было плохо видно».
И это при том, что есть отдельный вопрос по техническому оснащению площадки. Там и стоит написать «у вас моргал проектор в 4-ом зале когда кто-то клал сотовый рядом с ноутбуком».
Но зачем докладчику-то писать про неработающий проектор? И зачем портить настроение докладчику? Зачем портить рейтинг?
Или так: доклад на английском языке. Об этом написано и в программе, и докладчик недвусмысленно говорит. Обязательно будет пара отзывов в таком духе: «Плохо: из-за знания английского половина доклада осталась непонятной». Да. Прямо по-русски. Докладчик виноват что-ли? Зачем ставить «Плохо», если проблем в докладе и подаче не было? К слову: ПК проводит репетиции и с англоговорящими докладчиками. Иногда советуют «не употреблять непереводимую игру слов», но в большинстве своём английский язык у докладчиков не родной, и они говорят очень простыми словами.
Но есть и обратные примеры. На каждой конференции встречается (несколько) человек, которые в комментарях к оценке доклада дополнительно пишут разбивку: «подача-5, полезность-2, применимость-4, новизна-5». Лучи добра таким писателям. И докладчику понятно, и ПК помогает сделать выводы.
bsideup, справедливости ради, пункт №2 решается, если методы withStrategy, withConfig и прочие принимают аргументы типа Builder.
Да, пущай они сами вызовут .build(), зато в клиентском коде этого мусора не будет. Или я чего-то упускаю?
В простых случаях может быть даже такое: withStrategy(KafkaContainerStrategy::builder);
Всё так и есть. Именно поэтому в 1ом пункте выводов Роман советует работать с каждым докладом, во 2ом рекомендует не затягивать работу с докладом, и не мариновать докладчиков, в 3-ем пункте настоятельно рекомендует увеличивать полезность каждого выступления. При этом статья начинается с помощи в том «как искать смысл в потенциальном докладе» (== как направить мысль докладчика в правильное русло) и продолжается тем, что ПК должен всегда помнить, что доклад готовит докладчик, а не программный комитет, и что программному комитету стоит воздержаться от советов в духе «выбрось всё, и сделай вот так».
Безусловно, эти пункты просто пропитаны негативом по отношению к докладчикам.
осталось процентов 10. Но не похоже чтобы они могли повлиять на производительность
1) У вас не реализован парсинг functionType, а это довольно мутная часть языка (леворекурсивная и всё такое)
2) У вас не реализован парсинг functionLiteral, а это тоже непростой синтаксис. Например, в конструкции class Child: Parent by delegateMethod { ... } фигурные скобки могут быть как телом класса Child, так и лямбдой-параметром к методу delegateMethod
В общем, предлагаю сначала пройти хотя бы те тесты, которые проходит ANTLR парсер, а потом уже делать какие-либо сравнения.
А почему обтекаемый отказ не даёт возможности вернуть события в позитивное русло?
Или под обтекаемым отказом считается и полнейший уход в обтекаемые фразы на любые последующие уточняющие вопросы докладчика?
Если на обтекаемые фразы докладчик начнёт по-нормальному спрашивать, то можно ли ему отвечать менее обтекаемо?
В пункт «как искать смысл» можно добавить, что «понимание в тематике доклада» всё-таки помогает искать смыслы.
В «тревожные звоночки» можно смело записывать «парный доклад».
В «прогоны» (которые стоит называть репетициями) стоит добавить самый важный пункт: «проверяйте, что название соответствует содержимому». И пункт о том, что в конце доклада должны быть выводы (которые как бы отвечают на вопросы из раздела «Как искать смысл»)
К слову, в ANTLR грамматике какая-то самодеятельность: callExpression в официальной Kotlin грамматике отсутствует. Из-за подобного растёт неоднозначность, время парсинга и наверняка будут ошибки
В начале статьи лишь слова «размер джара (парсера) = 1.4МБ».
Слово jcommon в статье вообще не встречается.
log4j тоже не встречается.
То, что в JetBrains парсер входит Kotlin runtime тоже нигде не говорится.
val empty = str?.isEmpty() ?: true if (!empty && str != null) { // 'str != null' is always true
Что только люди не напишут, лишь бы не делать по-простому (штатный механизм в stdlib): if (str.isNullOrEmpty()) { ... }
По-моему, всё равно if лишний. Убрать бы его. Получается, кто-то там может слать недопустимые значения, а мы их игнорируем. Конечно, так и до enum недалеко додуматься, но вопросы остаются.
Если уже 25 вызовов с одним значением ignoreCase, то пора extract method делать.
Разумеется, я поддерживаю, что ругаться должна инспекция "вы тут зря переменную завели, воспользуйтесь лучше именованными параметрами", а не "expression is always true", просто исходно код выглядит стрёмно, и зачастую ожидаемо, что анализатор будет что-то там бурчать, особенно, когда код стрёмный.
Пример про isOption, конечно, нужно вообще без return записывать. Там ни return ни let не нужно: `isOption(s: String?) : Boolean = s?.startsWith("--") ?: false`. Ну или на String.isOption переделать (но это уже от проекта зависит)
А зачем в updatePriority примере нужен был if? Если его убрать, то станет проще читаться и будет проще поддерживать (не придётся дублировать литералы). Правильно оно ругалось на код, по делу.
command.startsWith("--data", ignoreCase) -- тоже по делу ругалось. Если хочется пояснить ignoreCase, то почему бы не использовать для этого именованные параметры? Зачем переменную объявлять? Вот так хорошо: command.startsWith("--data", ignoreCase = true)
В Java 8+ лучше использовать
java.lang.Integer#remainderUnsigned. И биты не теряем, и проблем с отрицательными значениями нет.папка / новая папка / новая папка (2)?Например, в Oracle DB курсоры без проблем переживают операцию commit и продолжают возвращать согласованные данные. Можно открыть курсор, сделать commit (или несколько) и без проблем продолжать выборку из курсора. Разумеется, у долгих курсоров есть шанс наткнуться на ORA-01555 snapshot too old, но это другая история.
Разработчики PostgreSQL почему-то посчитали, что, если транзакцию закрываем, то и курсоры нужно обязательно закрыть. При этом, фиксация транзакций в параллельных потоках никак не влияет.
Типичный подход в Oracle мире для batch обработки: открываем курсор, выбираем 10'000 записей. Обрабатываем, меняем данные, выполняем commit. Выбираем следующие 10'000 (операцией fetch bulk collect into… limit 10000) и так далее. Это позволяет не выполнять выборку каждый раз с нуля, и «выбирающий» курсор не протухает. В PostgreSQL такой подход не работает.
Я почему-то считал, что это всё портировано и в 8
Это связанные события или нет?
Shenandoah разлива JDK 8/11 не хватает? Или в JDK13 есть что-то дополнительное?
Нельзя ли по-медленнее? Я записываю.
Как оказались связаны mmap файлы и длительность TtSP (time to safepoint)? Речь про то, что процесс обращается к памяти, и тут внезапно возникает page fault, и обработка page fault'а растягивает TtSP?
слайды с приоритетом на английский язык, указатели с приоритетом по-английски и так далее).
Стоит учитывать, что доклад на конференции это не только те 60 минут времени, которые докладчик находится на сцене.
Это и возможность задать вопрос лично (до и после доклада), поэтому в программу конференции мы стараемся привлекать ключевых разработчиков.
То на каком языке говорит докладчик это далеко не единственный (и не главный!) критерий.
Например, я познакомился с René Gröschke на JPoint'е. Стал ли я от этого знатоком Gradle? Едва ли. Но зато стало проще переписываться и я могу переспросить: «Ну, как там мой pull request?».
На Joker'е я познакомился с Rémi Forax. Я его расспросил про ASM (он один из авторов), и он показал занятный проект github.com/forax/exotic. Ну, прямо на ноутбуке открыли код, он показал что к чему.
Конечно, всегда хочется, чтобы все 40+ докладов конференции были очень интересны именно мне.
Скажу честно, доклады про Spring это не моё. Но, ведь, есть и те, кому они нужны и полезны.
На конференции 4 доклада в параллель. Тематики разные, и для меня успех, это когда в каждом слоте есть хотя бы (!) один доклад, который «точно интересен».
Ещё не стоит забывать про 5ый трек: беседы в кулуарах. Часто встречается отзыв «в такой-то слот не было интересных докладов, и вместо этого беседовали со знакомыми».
Это что плохо что-ли? По-моему, так это успех. Возможно, не насколько успешный, но успех.
Оценки Превосходно, Хорошо, Нормально, Плохо превращаются в цифры и считается среднее арифметическое (по сути это rangevoting.org )
Но тут может возникнуть ситуация, что какой-нибудь коварный докладчик позовёт своих друзей на доклад, и они все поставят оценку «Превосходно». Может ли доклад с 10-ю слушателями быть «лучшим докладом конференции»? Конечно, может и такое быть. Но на Joker'е все доклады массовые. Минимальный зал был на 300 кресел.
Чтобы такого не получалось, в оценки каждого доклада подмешиваются несколько нулевых оценок (всем одинаковое количество, и оно равно 5-10% от общего количества слушателей конференции). В результате доклады с небольшим количеством слушателей получают меньший рейтинг, чем аналогичные по средней оценке, но с большим количеством слушателей. Эта же процедура описана тут: rangevoting.org/BetterQuorum.html
Это всё теория. На практике есть много интересных эффектов.
Самый суровый — «проклятие главного зала». Практика показывает, что в «главный зал» идут даже те, кто исходно на доклад не планировал. Возможно, считают, что «раз главный зал, то и доклады самые хорошие». Возможно, лень уходить с прошлого доклада. В подобных случаях получаются отзывы в духе «Плохо: ничего нового, ничего непонятно, вода какая-то».
Докладчик виноват что-ли? А что ему с таким отзывом делать? Беда да и только.
Понятие «крутой» доклад у каждого своё (кому-то нужно Spring, а кому-то кишки JVM), и вовсе неправда, что «в главном зале всегда самый крутой». В выборе доклада может помочь докладчик (он-то свой доклад знает) и программный комитет (ПК).
Или так: если во время доклада пару раз моргнёт проектор, то всё, гарантировано будут отзывы «Плохо: проектор не работал, было плохо видно».
И это при том, что есть отдельный вопрос по техническому оснащению площадки. Там и стоит написать «у вас моргал проектор в 4-ом зале когда кто-то клал сотовый рядом с ноутбуком».
Но зачем докладчику-то писать про неработающий проектор? И зачем портить настроение докладчику? Зачем портить рейтинг?
Или так: доклад на английском языке. Об этом написано и в программе, и докладчик недвусмысленно говорит. Обязательно будет пара отзывов в таком духе: «Плохо: из-за знания английского половина доклада осталась непонятной». Да. Прямо по-русски. Докладчик виноват что-ли? Зачем ставить «Плохо», если проблем в докладе и подаче не было? К слову: ПК проводит репетиции и с англоговорящими докладчиками. Иногда советуют «не употреблять непереводимую игру слов», но в большинстве своём английский язык у докладчиков не родной, и они говорят очень простыми словами.
Но есть и обратные примеры. На каждой конференции встречается (несколько) человек, которые в комментарях к оценке доклада дополнительно пишут разбивку: «подача-5, полезность-2, применимость-4, новизна-5». Лучи добра таким писателям. И докладчику понятно, и ПК помогает сделать выводы.
Да, пущай они сами вызовут .build(), зато в клиентском коде этого мусора не будет. Или я чего-то упускаю?
В простых случаях может быть даже такое: withStrategy(KafkaContainerStrategy::builder);
Безусловно, эти пункты просто пропитаны негативом по отношению к докладчикам.
Текущая больше похожа на продолжение, чем на мотивацию идти в ПК.
1) У вас не реализован парсинг
functionType, а это довольно мутная часть языка (леворекурсивная и всё такое)2) У вас не реализован парсинг
functionLiteral, а это тоже непростой синтаксис. Например, в конструкцииclass Child: Parent by delegateMethod { ... }фигурные скобки могут быть как телом классаChild, так и лямбдой-параметром к методуdelegateMethodВ общем, предлагаю сначала пройти хотя бы те тесты, которые проходит ANTLR парсер, а потом уже делать какие-либо сравнения.
Или под обтекаемым отказом считается и полнейший уход в обтекаемые фразы на любые последующие уточняющие вопросы докладчика?
Если на обтекаемые фразы докладчик начнёт по-нормальному спрашивать, то можно ли ему отвечать менее обтекаемо?
В пункт «как искать смысл» можно добавить, что «понимание в тематике доклада» всё-таки помогает искать смыслы.
В «тревожные звоночки» можно смело записывать «парный доклад».
В «прогоны» (которые стоит называть репетициями) стоит добавить самый важный пункт: «проверяйте, что название соответствует содержимому». И пункт о том, что в конце доклада должны быть выводы (которые как бы отвечают на вопросы из раздела «Как искать смысл»)
Слово jcommon в статье вообще не встречается.
log4j тоже не встречается.
То, что в JetBrains парсер входит Kotlin runtime тоже нигде не говорится.