То есть, по определению человеческих взаимодействий, подтверждения навыков должны быть взаимовыгодны, и наибольшее сомнение вызывает выгода для подтверждающего.
Тут могут быть либо какие-то “отцовские” альтруистичные чувства: “Давай, дружок, мы тебя взрастили на галере, но тебя ждет крупное плаванье, а я тут как-нибудь доживу свои годы”.
Либо взаимовыгодная похвала: “Сегодня со шхуны прыгаешь ты, а завтра — я, похвалим же друг друга”.
Либо материальная выгода, я CEO из хомяка ставлю вам лайк за парочку тапов.
Либо просто сеть вкатунов, подталкивающая друг друга повыше к борту крупного лайнера.
Не вижу предпосылок, чтобы эта метрика стала ключевым показателем.
К 2035-му у проблемы появилось решение: теперь айтишники активнее всего добавляют в резюме подтверждения навыков от работодателей и коллег. Резюме без подтверждений от других людей автоматически уезжают в конец очереди. Поэтому соискатели подтверждают навыки, чтобы получать офферы. Некоторые площадки с работой даже запретили составлять резюме без подтверждений.
Для меня такие подтверждения всегда казались моветоном. Как в басне Крылова про кукушку и петуха.
Если я меняю место работы, то, как правило, не от хорошей жизни, и с прошлого места работы мне либо не особо нужны подтверждения от коллег, либо коллеги, из-за крабьей ментальности, не будут честны и лестны, провожая меня приятными словами в линкедине.
На своем примере: уходя с прошлого места работы, более-менее честный и открытый отзыв я мог бы получить от своего ПМа. Но если мой ПМ не числится в определенного порядка и белизны кукушечно-петушином графе, то для случайного рекрутера это выглядит как кукушко-петушиный граф из двух человек — меня и ПМа.
for (;;) {
Map<String, String> currentMap = parameters.get();
Map<String, String> newMap = new HashMap<>(currentMap);
newMap.put(key, value);
newMap = Collections.unmodifiableMap(newMap);
if (parameters.compareAndSet(currentMap, newMap)) {
break;
}
}
Очень классно в busy-waiting лупе плодить объекты, хотя конечно в сценарии использования этого кода вряд ли будет больше двух спинов, но пример может быть заразителен.
А мне как-то для какой-то задачи не хватило в котлине | оператора. Но там можно сделать.
foo() or bar()
Performs a logical or operation between this Boolean and the other one. Unlike the || operator, this function does not perform short-circuit evaluation. Both this and other will always be evaluated.
Т.е Вы предлагаете как решение: пускать на тестовый стенд по plain аутентификации кого угодно. Окей, почему тогда не реврайтить запрос через nginx на admin/admin? Те же яйца только проще. Не говоря уже о том, что plain аутентификация в настоящее время повсеместно заменяется Oauth SSO и ваше решение никак не поможет уйти от тестовых учеток/ролей/групп.
fun getTaskById(taskId: Long): Task = taskRepository.findByIdOrNull(taskId)
?: throw TaskNotFoundException(HttpStatus.NOT_FOUND, "Задача с $taskId не найдена")
Благо в Spring есть Kotlin extension findByIdOrNull для CrudRepository а работа с Optional в котлин коде считается моветоном :)
P.S. Ещё DELETE по спецификации REST должен быть идемпотентный, так что нет смысла проверять на наличие в репозитории, правильнее будет просто молча вызывать deleteById
А зачем мне обрабатывать исключение? Если мне нужно мутировать содержимое для вызывающего код, то выброс исключения UnsupportedOperationException будет очевидным fail-fast поведением.
Если мне нужно мутировать содержимое в рамках моего кода то все и так давно используют (неявно) подход с копированием коллекции ака
unknownList.stream() .map() .filter()
Да и вообще в современном конкаренси ФП мире бест практис писать чистые функции. А это значит без модификации исходной коллекции и сигнатура в таком случае будет.
<T> List<T> addSomethingToList(List<T> list)
Я бы очень хотел конечно чтобы в Java были отдельные интерфейсы для мьютабл и имьютабл коллекций. Чтобы были и Intersection Types и Union Types и вообще чтобы все было по теории категорий и ругалось на этапе статического анализа. Но к сожалению реальность немного иная.
Можно например завести под задания по расписанию отдельные cron-cli микросервисы и менеджить кластерность, расписание и жизненный цикл через k8s
Можно даже оставить формирование отчета вашему многокластерному монолиту с точкой входа в виде эндпоинта, а по крону будет запускаться микросервис который вызовет соответствующий эндпоинт.
То есть, по определению человеческих взаимодействий, подтверждения навыков должны быть взаимовыгодны, и наибольшее сомнение вызывает выгода для подтверждающего.
Тут могут быть либо какие-то “отцовские” альтруистичные чувства: “Давай, дружок, мы тебя взрастили на галере, но тебя ждет крупное плаванье, а я тут как-нибудь доживу свои годы”.
Либо взаимовыгодная похвала: “Сегодня со шхуны прыгаешь ты, а завтра — я, похвалим же друг друга”.
Либо материальная выгода, я CEO из хомяка ставлю вам лайк за парочку тапов.
Либо просто сеть вкатунов, подталкивающая друг друга повыше к борту крупного лайнера.
Не вижу предпосылок, чтобы эта метрика стала ключевым показателем.
Для меня такие подтверждения всегда казались моветоном. Как в басне Крылова про кукушку и петуха.
Если я меняю место работы, то, как правило, не от хорошей жизни, и с прошлого места работы мне либо не особо нужны подтверждения от коллег, либо коллеги, из-за крабьей ментальности, не будут честны и лестны, провожая меня приятными словами в линкедине.
На своем примере: уходя с прошлого места работы, более-менее честный и открытый отзыв я мог бы получить от своего ПМа. Но если мой ПМ не числится в определенного порядка и белизны кукушечно-петушином графе, то для случайного рекрутера это выглядит как кукушко-петушиный граф из двух человек — меня и ПМа.
Очень классно в busy-waiting лупе плодить объекты, хотя конечно в сценарии использования этого кода вряд ли будет больше двух спинов, но пример может быть заразителен.
А мне как-то для какой-то задачи не хватило в котлине | оператора. Но там можно сделать.
А если OAuth/SSO провайдер один для всех окружений? Или вообще сторонний, вроде Google/Github
Т.е Вы предлагаете как решение: пускать на тестовый стенд по plain аутентификации кого угодно. Окей, почему тогда не реврайтить запрос через nginx на admin/admin? Те же яйца только проще. Не говоря уже о том, что plain аутентификация в настоящее время повсеместно заменяется Oauth SSO и ваше решение никак не поможет уйти от тестовых учеток/ролей/групп.
Есть ещё https://mermaid.js.org/syntax/sequenceDiagram.html он будет посвежее, поддерживается искаропки gitlab'ом. И одна из киллерфич, что он генерирует DOM с копипастабельными текстами, а не картинку.
Но и минусов хватает: меньше фич (нельзя сбрасывать автонамберы, или делать в одну линию стрелочки), куча плагинов под конфлюенс сомнительного производства. Ну и возможны какие-нибудь XSS дыры https://securitylab.github.com/advisories/GHSL-2021-1058_GHSL-2021-1060_mermaid_js/ из-за того же DOM'а
А ещё лучше так
Благо в Spring есть Kotlin extension
findByIdOrNullдляCrudRepositoryа работа сOptionalв котлин коде считается моветоном :)P.S. Ещё DELETE по спецификации REST должен быть идемпотентный, так что нет смысла проверять на наличие в репозитории, правильнее будет просто молча вызывать
deleteByIdКогда уже Шаблонный метод начнут вносить в антипаттерны?
Он нарушает принцип composition over inheritance, и вынуждает реализации знать о внутренностях суперкласса
А зачем мне обрабатывать исключение? Если мне нужно мутировать содержимое для вызывающего код, то выброс исключения UnsupportedOperationException будет очевидным fail-fast поведением.
Если мне нужно мутировать содержимое в рамках моего кода то все и так давно используют (неявно) подход с копированием коллекции ака
unknownList.stream() .map() .filter()Да и вообще в современном конкаренси ФП мире бест практис писать чистые функции. А это значит без модификации исходной коллекции и сигнатура в таком случае будет.
<T> List<T> addSomethingToList(List<T> list)Я бы очень хотел конечно чтобы в Java были отдельные интерфейсы для мьютабл и имьютабл коллекций. Чтобы были и Intersection Types и Union Types и вообще чтобы все было по теории категорий и ругалось на этапе статического анализа. Но к сожалению реальность немного иная.
Так не нужен, что c 1998 года используется.
Должен кому? Я указал на документацию к интерфейсу которую стоит учитывать если хочешь работать с листами с учетом LSP.
Ну если быть честным, то в документации add к интерфейсу List написано следующее.
* @throws UnsupportedOperationException if the {@code add} operation * is not supported by this listконечно документация такой себе контракт, но все же контракт.
И по хорошему клиентский код принимающий List должен учитывать что add может выбросить
UnsupportedOperationExceptionВроде как да. Мне так же инетересно можно ли вызвать утечку памяти переполняя пул строк, они ведь оттуда не выгружаются?
Можно например завести под задания по расписанию отдельные cron-cli микросервисы и менеджить кластерность, расписание и жизненный цикл через k8s
Можно даже оставить формирование отчета вашему многокластерному монолиту с точкой входа в виде эндпоинта, а по крону будет запускаться микросервис который вызовет соответствующий эндпоинт.