О, наш язык может изучать двусмысленно, но, проблема нейросетей, по моему наблюдению, это ещё и то, что они плохо держат контекст, а когда данных очень много - они игнорируют некоторые данные. Особенно если много входных и выходных данных. Поэтому, на данном этапе они не могут заменить человека. Что то простое делать они могут, как раз если входные данные небольшие. Делать компоненты чего то большого да, делать сразу что то большое - нет,
это я так, образно написал, вариантов, на самом деле масса, плюс, я бы расценивал его как крайний, в случае какого нибудь форс - мажора, когда нужно очень резко отобрать права. а так, вот допустим, можно еще сделать временную проверку всех пользователей на блокировку аккаунта, до тех пор пока access не протухнет, по сути, такая нагрузка будет длиться в течение 10 минут. по миркосервисам - тут зависит больше от изначальной организации их работы, можно сразу учитывать жесткие действия, такие как замена ключа. Например..... (тут нажно подумать) ну например могу прикинуть что если есть такая необходимость, то можно в очереди, в каждом запросе передавать токен и проверять его валидность, тогда если в очереди есть много запросов, и ключ сменили, и токен висел в очереди а потом пришел, на какой то сервис, и по скольку токен уже не валиден то и запрос будет отклонен. ну как то так, но, к слову, если это банковское приложение, можно организовать жизненный цикл токена не 10 минут, а, например, 30 секунд. этого же никто не запрещает, к слову, как конкретно в банке организовано я не особо в курсе, но думаю что подобным образом,
Документы десятилетней давности - исключение. Такие документы редко где есть и редко бывает надобность их открывать, кроме того, готовые документы правильнее хранить в пдф на выходе.
Было время, у нас поставили всем либру на работе, потому как выделять деньги на офис от Майкрософт не захотели потому что ценник порядочны оказался, машин, к слову, более 300 штук, и помножить эти 300 компов нужно на 10000 рублей получается весьма порядочная сумма.
В итоге it отдает взял и поставил на все компы либру.
Началась "вонь": у меня дома Майкрософт офис, я делаю документ вот так, а тут он открывается "вот так", ПОСТАВЬТЕ МНЕ СРОЧНО МАЙКРОСОФТ ОФИС!!!!!
на вполне себе справедливое замечание: просто дома поставьте себе либру и пользуйтесь ей, был какой то тотальный игнор. Люди не хотели ставить себе либру не потому что она, допустим, плохо работает, а потому что потому. И, что так же смешно, они описывали "незаменимые" фичи офиса от Майкрософт, но сами ими никогда не пользовались.
К слову, когда нужно было работать с большими таблицами, то у либры скорость открытия файла, поиска по таблице была значительно выше.
Тут ещё такой момент что врят ли нужно будет в каком то приложении "моментально" отбирать права, это в основном только банкам и надо, но и у них - тоже самое с сикретами,
Для монолита вполне себе можно использовать jwt, да и мгновенно никто не запрещает отзывать токены.
Схема простая: refresh хранится в базе, и он по базе и проверяется. Хотим отозвать - помечаем как блок и refresh перестает работать. Если использовать чисто этот сценарий, то сессия потухнет в период времени до 10 - 15 минут.
Для отзыва access токена можно идти немного по другому пути, без бд, например, (это только пример а не истинна в последней инстанции) можно сделать список заблокированных access токенов, допустим через переменную окружения или типа того. Да даже через текстовый файл, это неважно. И сверять каждый раз все входящие access токены с этим списком, до тех пор, пока токен не протухнет. То бишь, ввести проверку на 10 - 15 минут. Учитывая что refresh уже заблокирован, access обновление не получит.
Типа того.
НО ВОТ БОЛЕЕ ПРАВИЛЬНЫЙ ВАРИАНТ:
Имеем два сикрета, на каждый токен,
В базе так же держим refresh и его обновление.
Меняем сикрет у access,
Абсолютно у всех пользователей протухнет access, они "пойдут" его менять, и у того кто имеет заблокированный refresh тот ничего не получит.
Вы упустили, скорее всего, хороших инженеров, а набрали, в итоге, хороших операторов нейросетей.
У меня был опыт работы с одной компанией, которая так же делает бессмысленные технические интервью.
Проблема была в том, что они так же на серьезных щах "умничают" на собеседованиях, рассказывают какие они крутые профи, но продукт, который они делают, работает отвратительно.
Возникает вопрос, а как такие профессионалы делают на столько отвратительный продукт? А очень просто: они отсеяли всех хороших инженеров. Потому как операторы нейросетей даже не смотрят на код, который им сгенерировала нейронка. Они его тупо не понимают. И не читают. Им банально лень читать, скопировал, вставил, о, работает. То что работает плохо он не понимает. Что бы прочитать код и разобраться в нем нужно, как минимум, время. Но на собеседованиях этого времени не дают. И тут приходит кандидат, который за секунды разбирает код. И находит все 34 ошибки. Гений, не иначе. (Сарказм).
Сколько я видел различных продуктов, столько я видел максимально тупых глюков этих продуктов умноженных на 10.
У меня вообще закралась мысль, что подобные интервью созданы специально, что бы бездари, которые пришли после 2 недельных курсов во время ковида не теряли места, а инженеры не могли найти нормальную работу.
Тот же Яндекс взять, у них тех собеседование проходит в режиме "быстрее - бегом", время на подумать? Нет, вы что, подумать ответ на вопрос нужно было ещё за час до самого вопроса. И сами интервьюеры там - школьники что ли.... Которые, например, на позицию сениора спрашивают "а что такое дата класс в котлин". Это идиотизм.
Меня сразу смутило название: физик.... А с каких пор физики занимаются подобными делами?
По поводу багов: ну есть где то баг, который никогда не увидят 99% пользователей? Ну и фиг с ним.
Помню, читал, когда то давно, mindcraft, который спонсировался microsoft уже тестировал web сервера windows nt и gnu/linux, типа он в 5 раз быстрее оказался. (Типа оказался), хотя независимые тестировщики указали что gnu/linux работает ни чуть ни хуже, а где то даже и лучше.
Автор проделал, без сомнения, большую работу, систематизируя свой подход. Однако, при ближайшем рассмотрении, он создал не систему отбора лучших инженеров, а элитный клуб для любителей олимпиадных задач и викторин на знание, который в современных реалиях абсолютно неэффективен.
Лайв-кодинг в блокноте - главный провал методики Это самая абсурдная и оторванная от жизни часть. Требовать писать код в онлайн-редакторе без привычной IDE - это как просить хирурга провести операцию перочинным ножом, а потом удивляться, что он не помнит точное латинское название каждого инструмента.
Проверка памяти, а не интеллекта. Современная разработка - это не про запоминание всех методов Collectors или сигнатур функций. Это про умение решать бизнес-задачи с помощью инструментов. IDE - наш главный инструмент. Отказывая в нём, интервьюер проверяет не способность мыслить, а банальную зубрежку.
Искусственный стресс. Никто не пишет код в таких условиях. Это искусственно созданная стрессовая ситуация, которая отсеивает не плохих разработчиков, а тех, кто хуже справляется с бессмысленным давлением.
Игнорирование реальности. Автор сам пишет про Spring Boot, Hibernate, Kotlin. Все эти технологии подразумевают активное использование IDE для навигации, автодополнения и рефакторинга. Заставлять писать на них код вслепую - это полный нонсенс и демонстрация непонимания рабочего процесса.
Гонка вооружений с нейросетями, которую невозможно выиграть Автор создает настолько сложные и "хитрые" задачи, что сам же толкает кандидатов на жульничество.
Стимуляция обмана. Чем сложнее и академичнее задача, тем выше соблазн быстро "спросить" у ChatGPT. В итоге соревнование идет не в знаниях, а в скорости и незаметности использования нейросетей.
Неверный результат. Вместо того чтобы нанять человека, который умеет рассуждать, компания нанимает лучшего "оператора" нейросети. Автор жалуется на некомпетентность, но его же система и способствует ее сокрытию.
"Хитрые" SQL-задачи и Code Review как поиск "пасхалок" Подход к базам данных и ревью кода страдает той же болезнью - фокусом на эзотерических знаниях, а не на практической ценности.
SQL-акробатика. Автор сам признает, что большинство использует ORM, но упорно продолжает гонять кандидатов по "оконным функциям" и "хитрым группировкам". Да, это полезно знать, но для 95% задач бэкенд-разработчика это не является ключевым навыком. Гораздо важнее уметь спроектировать нормальную модель данных, а не написать монструозный запрос, который потом никто не сможет поддерживать.
Ревью ради ревью. Задача ревью - улучшить код и помочь коллеге, а не сыграть в "найди 10 отличий" с кодом, который нарочно написан как можно хуже. Этот "фрагмент реальной enterprise-системы" выглядит как свалка всех возможных анти-паттернов. Хороший инженер может не найти все 34 "ошибки", потому что в реальной жизни он бы написал этот код совершенно иначе с самого начала.
Итог: Кого на самом деле ищет автор? Эта система отбирает людей, которые:
Обладают феноменальной памятью.
Отлично справляются с бессмысленным стрессом.
Имеют опыт решения олимпиадных задач.
Либо очень хорошо умеют жульничать.
Но являются ли они лучшими командными игроками, архитекторами и инженерами, способными создавать и поддерживать сложные системы? Очень сомнительно.
В погоне за "идеальным" кандидатом, который знает наизусть все тонкости SQL и JDK, автор рискует упустить десятки отличных, прагматичных инженеров, которые просто хотят делать свою работу с помощью современных инструментов, а не сдавать экзамены из прошлого века.
А насчёт авторской разработки - лукавство, это скорее базовая модель, как раз в учебных целях она и применяется. Когда на занятиях берут и тестируют датчик, на определенном расстоянии что бы загорелся светодиод.
Я про "уж чья бы корова мычала", потому что WhatsApp там у себя делает ровно тоже самое что и max. Но, по отношению к нам, включил режим "вынепанимаетеэтодругое",
В принципе да,
Как хорошо что я пользуюсь gnu/linux и не имею подобных проблем,
О, наш язык может изучать двусмысленно, но, проблема нейросетей, по моему наблюдению, это ещё и то, что они плохо держат контекст, а когда данных очень много - они игнорируют некоторые данные. Особенно если много входных и выходных данных. Поэтому, на данном этапе они не могут заменить человека. Что то простое делать они могут, как раз если входные данные небольшие. Делать компоненты чего то большого да, делать сразу что то большое - нет,
Хм... Странно, я недавно WeChat поставил, получил СМС и все работает. Ничего никто не сканировал....
Фраза "я люблю свою семью" тоже запатентована, и она точно была создана и использована так сказать до патента,
это я так, образно написал, вариантов, на самом деле масса, плюс, я бы расценивал его как крайний, в случае какого нибудь форс - мажора, когда нужно очень резко отобрать права. а так, вот допустим, можно еще сделать временную проверку всех пользователей на блокировку аккаунта, до тех пор пока access не протухнет, по сути, такая нагрузка будет длиться в течение 10 минут.
по миркосервисам - тут зависит больше от изначальной организации их работы, можно сразу учитывать жесткие действия, такие как замена ключа. Например..... (тут нажно подумать) ну например могу прикинуть что если есть такая необходимость, то можно в очереди, в каждом запросе передавать токен и проверять его валидность, тогда если в очереди есть много запросов, и ключ сменили, и токен висел в очереди а потом пришел, на какой то сервис, и по скольку токен уже не валиден то и запрос будет отклонен.
ну как то так,
но, к слову, если это банковское приложение, можно организовать жизненный цикл токена не 10 минут, а, например, 30 секунд. этого же никто не запрещает, к слову, как конкретно в банке организовано я не особо в курсе, но думаю что подобным образом,
Документы десятилетней давности - исключение. Такие документы редко где есть и редко бывает надобность их открывать, кроме того, готовые документы правильнее хранить в пдф на выходе.
Меня позиция адептов Майкрософта всегда удивляла,
Было время, у нас поставили всем либру на работе, потому как выделять деньги на офис от Майкрософт не захотели потому что ценник порядочны оказался, машин, к слову, более 300 штук, и помножить эти 300 компов нужно на 10000 рублей получается весьма порядочная сумма.
В итоге it отдает взял и поставил на все компы либру.
Началась "вонь": у меня дома Майкрософт офис, я делаю документ вот так, а тут он открывается "вот так", ПОСТАВЬТЕ МНЕ СРОЧНО МАЙКРОСОФТ ОФИС!!!!!
на вполне себе справедливое замечание: просто дома поставьте себе либру и пользуйтесь ей, был какой то тотальный игнор. Люди не хотели ставить себе либру не потому что она, допустим, плохо работает, а потому что потому. И, что так же смешно, они описывали "незаменимые" фичи офиса от Майкрософт, но сами ими никогда не пользовались.
К слову, когда нужно было работать с большими таблицами, то у либры скорость открытия файла, поиска по таблице была значительно выше.
А в чем проблема просто везде поставить либру и пользоваться только ей? Вы же знаете что за каждую копию офиса от Майкрософт вы платите деньги?
Тут ещё такой момент что врят ли нужно будет в каком то приложении "моментально" отбирать права, это в основном только банкам и надо, но и у них - тоже самое с сикретами,
Для монолита вполне себе можно использовать jwt, да и мгновенно никто не запрещает отзывать токены.
Схема простая: refresh хранится в базе, и он по базе и проверяется. Хотим отозвать - помечаем как блок и refresh перестает работать. Если использовать чисто этот сценарий, то сессия потухнет в период времени до 10 - 15 минут.
Для отзыва access токена можно идти немного по другому пути, без бд, например, (это только пример а не истинна в последней инстанции) можно сделать список заблокированных access токенов, допустим через переменную окружения или типа того. Да даже через текстовый файл, это неважно. И сверять каждый раз все входящие access токены с этим списком, до тех пор, пока токен не протухнет. То бишь, ввести проверку на 10 - 15 минут. Учитывая что refresh уже заблокирован, access обновление не получит.
Типа того.
НО ВОТ БОЛЕЕ ПРАВИЛЬНЫЙ ВАРИАНТ:
Имеем два сикрета, на каждый токен,
В базе так же держим refresh и его обновление.
Меняем сикрет у access,
Абсолютно у всех пользователей протухнет access, они "пойдут" его менять, и у того кто имеет заблокированный refresh тот ничего не получит.
Вот и все.
Вы просто плохо читали правила тетради. Там, перед смертью, можно заставить человека что то сделать.
Поэтому нужно написать что то в стиле: "разблокировать Ютуб и телеграм потом повеситься".
Вы упустили, скорее всего, хороших инженеров, а набрали, в итоге, хороших операторов нейросетей.
У меня был опыт работы с одной компанией, которая так же делает бессмысленные технические интервью.
Проблема была в том, что они так же на серьезных щах "умничают" на собеседованиях, рассказывают какие они крутые профи, но продукт, который они делают, работает отвратительно.
Возникает вопрос, а как такие профессионалы делают на столько отвратительный продукт? А очень просто: они отсеяли всех хороших инженеров. Потому как операторы нейросетей даже не смотрят на код, который им сгенерировала нейронка. Они его тупо не понимают. И не читают. Им банально лень читать, скопировал, вставил, о, работает. То что работает плохо он не понимает. Что бы прочитать код и разобраться в нем нужно, как минимум, время. Но на собеседованиях этого времени не дают. И тут приходит кандидат, который за секунды разбирает код. И находит все 34 ошибки. Гений, не иначе. (Сарказм).
Сколько я видел различных продуктов, столько я видел максимально тупых глюков этих продуктов умноженных на 10.
У меня вообще закралась мысль, что подобные интервью созданы специально, что бы бездари, которые пришли после 2 недельных курсов во время ковида не теряли места, а инженеры не могли найти нормальную работу.
Тот же Яндекс взять, у них тех собеседование проходит в режиме "быстрее - бегом", время на подумать? Нет, вы что, подумать ответ на вопрос нужно было ещё за час до самого вопроса. И сами интервьюеры там - школьники что ли.... Которые, например, на позицию сениора спрашивают "а что такое дата класс в котлин". Это идиотизм.
Меня сразу смутило название: физик.... А с каких пор физики занимаются подобными делами?
По поводу багов: ну есть где то баг, который никогда не увидят 99% пользователей? Ну и фиг с ним.
Помню, читал, когда то давно, mindcraft, который спонсировался microsoft уже тестировал web сервера windows nt и gnu/linux, типа он в 5 раз быстрее оказался. (Типа оказался), хотя независимые тестировщики указали что gnu/linux работает ни чуть ни хуже, а где то даже и лучше.
Вот эта статья что то подобное мне напоминает.
Автор проделал, без сомнения, большую работу, систематизируя свой подход. Однако, при ближайшем рассмотрении, он создал не систему отбора лучших инженеров, а элитный клуб для любителей олимпиадных задач и викторин на знание, который в современных реалиях абсолютно неэффективен.
Лайв-кодинг в блокноте - главный провал методики Это самая абсурдная и оторванная от жизни часть. Требовать писать код в онлайн-редакторе без привычной IDE - это как просить хирурга провести операцию перочинным ножом, а потом удивляться, что он не помнит точное латинское название каждого инструмента.
Проверка памяти, а не интеллекта. Современная разработка - это не про запоминание всех методов Collectors или сигнатур функций. Это про умение решать бизнес-задачи с помощью инструментов. IDE - наш главный инструмент. Отказывая в нём, интервьюер проверяет не способность мыслить, а банальную зубрежку.
Искусственный стресс. Никто не пишет код в таких условиях. Это искусственно созданная стрессовая ситуация, которая отсеивает не плохих разработчиков, а тех, кто хуже справляется с бессмысленным давлением.
Игнорирование реальности. Автор сам пишет про Spring Boot, Hibernate, Kotlin. Все эти технологии подразумевают активное использование IDE для навигации, автодополнения и рефакторинга. Заставлять писать на них код вслепую - это полный нонсенс и демонстрация непонимания рабочего процесса.
Гонка вооружений с нейросетями, которую невозможно выиграть Автор создает настолько сложные и "хитрые" задачи, что сам же толкает кандидатов на жульничество.
Стимуляция обмана. Чем сложнее и академичнее задача, тем выше соблазн быстро "спросить" у ChatGPT. В итоге соревнование идет не в знаниях, а в скорости и незаметности использования нейросетей.
Неверный результат. Вместо того чтобы нанять человека, который умеет рассуждать, компания нанимает лучшего "оператора" нейросети. Автор жалуется на некомпетентность, но его же система и способствует ее сокрытию.
"Хитрые" SQL-задачи и Code Review как поиск "пасхалок" Подход к базам данных и ревью кода страдает той же болезнью - фокусом на эзотерических знаниях, а не на практической ценности.
SQL-акробатика. Автор сам признает, что большинство использует ORM, но упорно продолжает гонять кандидатов по "оконным функциям" и "хитрым группировкам". Да, это полезно знать, но для 95% задач бэкенд-разработчика это не является ключевым навыком. Гораздо важнее уметь спроектировать нормальную модель данных, а не написать монструозный запрос, который потом никто не сможет поддерживать.
Ревью ради ревью. Задача ревью - улучшить код и помочь коллеге, а не сыграть в "найди 10 отличий" с кодом, который нарочно написан как можно хуже. Этот "фрагмент реальной enterprise-системы" выглядит как свалка всех возможных анти-паттернов. Хороший инженер может не найти все 34 "ошибки", потому что в реальной жизни он бы написал этот код совершенно иначе с самого начала.
Итог: Кого на самом деле ищет автор?
Эта система отбирает людей, которые:
Обладают феноменальной памятью.
Отлично справляются с бессмысленным стрессом.
Имеют опыт решения олимпиадных задач.
Либо очень хорошо умеют жульничать.
Но являются ли они лучшими командными игроками, архитекторами и инженерами, способными создавать и поддерживать сложные системы? Очень сомнительно.
В погоне за "идеальным" кандидатом, который знает наизусть все тонкости SQL и JDK, автор рискует упустить десятки отличных, прагматичных инженеров, которые просто хотят делать свою работу с помощью современных инструментов, а не сдавать экзамены из прошлого века.
А на что фотографировали? На зенит какой нибудь?
А насчёт авторской разработки - лукавство, это скорее базовая модель, как раз в учебных целях она и применяется. Когда на занятиях берут и тестируют датчик, на определенном расстоянии что бы загорелся светодиод.
Хм.... Может я чего то не понимаю, но в чем проблема поднять свой сервер с бд? Хотя бы облачный vps и поставить на него postgre.
Или дело в цене? На сколько облачный сторонний должен быть дешевле и на сколько оправдано его использовать?
Я про "уж чья бы корова мычала", потому что WhatsApp там у себя делает ровно тоже самое что и max. Но, по отношению к нам, включил режим "вынепанимаетеэтодругое",
Вот уж кто бы, а WhatsApp пишет про частное и безопасное общение. Это же тот самый WhatsApp, который Пентагону сливает просто все что можно слить, да?
Я вообще не вижу абсолютно никакого смысла в использовании собственными продуктами от Microsoft.
Я, конечно, понимаю что люди привыкли, но год из года наступать на одни и те же грабли, при этом даже не пытаясь перейти на альтернативу...