Рынок труда не просто так называется рынком, это торги. И как по мне вполне нормально уточнить, есть ли вариант удаленки вместо гибрида, или поторговаться на счет вилки (котоую в 90% случаев на хх просто не указывают и попробуй угадай какая вилка в компании, никто не хочет первым называть цифру). Гибрид тоже у всех разный, у кого-то 1 день в неделю, а у кого-то 3-4. По поводу рекрутера - если бы они отсеивали так как вы пишете, то уж точно конверсия у меня была бы горааааздо выше. Но автоотказы явные у половины компаний, другая половина просто болт забивает и даже статусы не могут кликнуть (1 нажатие). Про "ускорение" и прочее - не просто так появилась эта чушь, увы, но спасибо хх с их иишкой и рекрутерам которые на это реагируют забивая на чтение резюме по факту. (Сам лично видел как это выглядит в кабинете рекрутера, да и на ютубе уже есть видео с обзором кабинета, мнооого интересного можно узнать, и про перс данные в том числе)
Я вот смотрю как работают большинство ХРюш с ххру... с введением там ИИ стало прям душно. Я видел кабинет кадровика, как твое резюме отображается, и понятно откуда ноги растут с "ускорил на 25%", именно иишка на это реагирует и подсвечивает что мол вот годный кандидат. Плюс ключевые слова, рассчитывает процент совпадения, при чем ОЧЕНЬ криво. Эти хрюши даже не читают само резюме, они смотрят что им там говорит ИИшка. У меня 15 лет в разработке, 5 лет в арзитектуре, но я не подхожу на архитектора) это забавно) и видно как автоматом через 15-30 минут после отклика в 4 утра прилетает молчаливый автоотказ. Есть всякие менторы помогальщики, которые через свой лк рекрутера помогают твое резюме адаптировать под поисковую выдачу, в том числе ИИшную обработку, и наверное такое не просто так появилось и пользуется спросом.
Все это говорю как человек, который 2 месяца на хх сидит и видит в какую помойку весь процесс превратился.
Рынок найма сломан, с обеих сторон. Со стороны соискателей вкатунами, иишниками и накрутчиками. Со стороны рекрутеров - нежеланием смотреть кандидатов самостоятельно и перекладывание на автоматизированные системы (видел, плавали, знаем) и иишки.
Лучше сделайте чтобы личный кабинет не лагал, а то любую вкладку открываешь и ждешь по 5-10-15 секунд, иногда дольше, и это при том что проектов и серверов раз два и обсчелся... из-за этого любое действие в лк - это тупо боль!
Как по мне пост явно в хаб "я пиарюсь" должен быть, но никак не в хабах по go, typescript или react. Спустя десяток лет читать гошном хабе про то, что в нем есть каналы и они удобны - имхо мало для попадания в данный хаб. Технички вообще никакой в посте, даже тех самых примеров новомодных ликвид гласов и фильтра для svg, чтобы хоть что-то похожее на техничку было, но и этого нет...
Ну и несколько странно читать в начале что "я решил с нуля разработать", а потом в тексте встречать "мы". А такой ли уж это петпроект, или коммерция изначально?
Интересный путь. Но вопрос, почему не стали смотреть на готовые варианты? Тот же krakend на гошке, опенсорсный, так же к нему плагины можно писать. Конфигурация шаблонизируется, можно просто json. Плюс у него большое комьюнити, что решает проблему bus-фактора, есть много чего из коробки.
Почему же? В статье автор упомянул что скейл в простое равен нулю. То есть если нет джобов, то по таймауту они отскейлятся в 0 и их не будет. Плюс из админки гитлаба они так же исчезнут. Когда надо при старте виртуалки/раннера он появится в группе. Единственное это нужно контролировать обновление раннеров, но делается это централизованно.
У меня самого так в яндекс клауде крутятся раннеры через docker-machine с плагином для яндекса. Довольно удобно. Плюс расписание настроено, что в будни в рабочее время всегда 1 свободный раннер должен быть, в остальное время скейл до нуля с айдл таймаутом в 30 минут.
Честно говоря я так и не понял сути и ценности бота. Чем он лучше избранного в телеге (он же чат с самим собой), в котором вместо тегов можно использовать эмодзи и фильтровать по ним. При этом данные не улетают сторонним разработчикам ботов.
При этом для доступа к избранному можно написать простой скрипт, который будет еще и бекапить данные в какое-то хранилище. Ну и экспорт чата в самой телеге на крайний случай...
"и доступны только Вам, больше никто к ним не имеет доступ" - И даже бот? И даже владелец бота? И даже друзья владельца бота? Мне кажется, вы несколько лукавите, разве нет?
Неплохой вариант, за статью лайк. В целом давно такое использую у себя.
От себя добавлю:
Ответ для internal error я бы вынес в константу или в байт массиве и его бы отдавал наружу. Там сработает оптимизатор при сборке. (На сколько я помню).
Для типовых ошибок лучше завести отдельные методы, в которых уже будет занесено и коды и сообщения для пользователя. Это позволит в структуре хранить и обрабатывать коды не только для http и при этом имея отдельные методы для ошибок это снизит количество случаев где надо помнить какие коды для какой ошибки, упростит написание документации, больше переисполтзования и тд. Все ошибки могут быть реализованы в отдельном пакете и прикрутить авто-документирование. Это крайне удобно по итогу (особенно когда 100500 ошибок в большом проекте и нужно вести их в доке). Ну и для кастомных случаев остается публичный метод с передачей параметров в функцию. Либо сделать структуру приватной и сделать обращение к ней более строгое. В общем вариантов как улучшить всегда есть.
И да, я тоже в свое время ломал голову как адекватно прикрутить проброс ошибок.
Вы хотя бы можете писать там посты... Я вот не могу даже зайти в учетку зареганную через Яндекс. А если зашел чудом, то не могу переключиться ни на одну другую через Яндекс паспорт 😂 зато через вк авторизация кое как работает...
Дайте в свободный доступ образ! Верните в зад все как было! А то ни тест не получить, инструкция по получению доступа к тесту - 404 на сайте, в лк не зарегистрироваться. В общем у нас все как всегда, ни байтика опенсорсу, все за деньги?
А как вы решаете проблему, когда нужно записать в базу и сразу сделать чтение данных с учетом записанных? Если писать только в мастер, а читать из слейвов, то есть риск не получить данные. Если и писать и читать из мастера - то не получится подразмазать нагрузку. Как вы решаете такие проблемы, особенно с учетом синхрониус коммит офф? Буду благодарен за инфу :)
Нет, слайс увеличивается не всегда в 2 раза. Автор забыл упомянуть изменения в go 1.14 и 1.20 (и в 1.21 вроде как планируются еще изменения по оптимизации).
Спасибо за ответ :) про vault понял. За delay спасибо, не натыкался, посмотрю. Ну и по pgeon надеюсь все таки выложат. Вообще с CDC в пг все сложно))) это не тарантул ?
Спасибо за статью! Интересно было бы еще посмотреть на вашу обертку открытия соединений с чтением из vault, и разделяете ли вы соединения с мастером и слейвом, если да то как? 2 соединения и пакет для работы с конкретной базой куда передается 2 соединения и выбирается в зависимости от того что делает метод (читает или пишет). Или реплика только для фейловера (HA), а не для балансировки нагрузки?
По поводу контекста, чтобы копировать, но без cancel можно вытащить код detach метода, вроде так называется, из пакета context (почему он там приватный так и не понял, крайне полезная штука), позволяет копировать контекст (все что в нем, включая трейс, логгер и прочие переменные) не боясь что он отменится (приходилось с таким играться в errgroup).
Люблю разные новые тулзы находить и тут увидел pgeon - что это и где можно почитать? Гугл мне что-то не очень в этом помог :)
А про нормальные апи гейтвеи не слышали? Тот же kong, krakend и тд. У того же кракена есть интеграция с кроликом. Более того в вашем примере рейтлимит, проверку авторизации и прочие ништяки апи гейтвеев реализовывать будет адски геморройно, что есть из коробки у решений которые под это заточены.
Именно это и случилось. Оригинальный репозиторий minio ушел в public archive и предлагается использовать AIStor...
Рынок труда не просто так называется рынком, это торги. И как по мне вполне нормально уточнить, есть ли вариант удаленки вместо гибрида, или поторговаться на счет вилки (котоую в 90% случаев на хх просто не указывают и попробуй угадай какая вилка в компании, никто не хочет первым называть цифру). Гибрид тоже у всех разный, у кого-то 1 день в неделю, а у кого-то 3-4. По поводу рекрутера - если бы они отсеивали так как вы пишете, то уж точно конверсия у меня была бы горааааздо выше. Но автоотказы явные у половины компаний, другая половина просто болт забивает и даже статусы не могут кликнуть (1 нажатие). Про "ускорение" и прочее - не просто так появилась эта чушь, увы, но спасибо хх с их иишкой и рекрутерам которые на это реагируют забивая на чтение резюме по факту. (Сам лично видел как это выглядит в кабинете рекрутера, да и на ютубе уже есть видео с обзором кабинета, мнооого интересного можно узнать, и про перс данные в том числе)
Я вот смотрю как работают большинство ХРюш с ххру... с введением там ИИ стало прям душно. Я видел кабинет кадровика, как твое резюме отображается, и понятно откуда ноги растут с "ускорил на 25%", именно иишка на это реагирует и подсвечивает что мол вот годный кандидат. Плюс ключевые слова, рассчитывает процент совпадения, при чем ОЧЕНЬ криво. Эти хрюши даже не читают само резюме, они смотрят что им там говорит ИИшка. У меня 15 лет в разработке, 5 лет в арзитектуре, но я не подхожу на архитектора) это забавно) и видно как автоматом через 15-30 минут после отклика в 4 утра прилетает молчаливый автоотказ. Есть всякие менторы помогальщики, которые через свой лк рекрутера помогают твое резюме адаптировать под поисковую выдачу, в том числе ИИшную обработку, и наверное такое не просто так появилось и пользуется спросом.
Все это говорю как человек, который 2 месяца на хх сидит и видит в какую помойку весь процесс превратился.
Рынок найма сломан, с обеих сторон. Со стороны соискателей вкатунами, иишниками и накрутчиками. Со стороны рекрутеров - нежеланием смотреть кандидатов самостоятельно и перекладывание на автоматизированные системы (видел, плавали, знаем) и иишки.
Лучше сделайте чтобы личный кабинет не лагал, а то любую вкладку открываешь и ждешь по 5-10-15 секунд, иногда дольше, и это при том что проектов и серверов раз два и обсчелся... из-за этого любое действие в лк - это тупо боль!
Как по мне пост явно в хаб "я пиарюсь" должен быть, но никак не в хабах по go, typescript или react. Спустя десяток лет читать гошном хабе про то, что в нем есть каналы и они удобны - имхо мало для попадания в данный хаб. Технички вообще никакой в посте, даже тех самых примеров новомодных ликвид гласов и фильтра для svg, чтобы хоть что-то похожее на техничку было, но и этого нет...
Ну и несколько странно читать в начале что "я решил с нуля разработать", а потом в тексте встречать "мы". А такой ли уж это петпроект, или коммерция изначально?
Короче, пустой и чисто рекламный пост, имхо.
Интересный путь. Но вопрос, почему не стали смотреть на готовые варианты? Тот же krakend на гошке, опенсорсный, так же к нему плагины можно писать. Конфигурация шаблонизируется, можно просто json. Плюс у него большое комьюнити, что решает проблему bus-фактора, есть много чего из коробки.
Почему же? В статье автор упомянул что скейл в простое равен нулю. То есть если нет джобов, то по таймауту они отскейлятся в 0 и их не будет. Плюс из админки гитлаба они так же исчезнут. Когда надо при старте виртуалки/раннера он появится в группе. Единственное это нужно контролировать обновление раннеров, но делается это централизованно.
У меня самого так в яндекс клауде крутятся раннеры через docker-machine с плагином для яндекса. Довольно удобно. Плюс расписание настроено, что в будни в рабочее время всегда 1 свободный раннер должен быть, в остальное время скейл до нуля с айдл таймаутом в 30 минут.
Честно говоря я так и не понял сути и ценности бота. Чем он лучше избранного в телеге (он же чат с самим собой), в котором вместо тегов можно использовать эмодзи и фильтровать по ним. При этом данные не улетают сторонним разработчикам ботов.
При этом для доступа к избранному можно написать простой скрипт, который будет еще и бекапить данные в какое-то хранилище. Ну и экспорт чата в самой телеге на крайний случай...
"и доступны только Вам, больше никто к ним не имеет доступ" - И даже бот? И даже владелец бота? И даже друзья владельца бота? Мне кажется, вы несколько лукавите, разве нет?
Неплохой вариант, за статью лайк. В целом давно такое использую у себя.
От себя добавлю:
Ответ для internal error я бы вынес в константу или в байт массиве и его бы отдавал наружу. Там сработает оптимизатор при сборке. (На сколько я помню).
Для типовых ошибок лучше завести отдельные методы, в которых уже будет занесено и коды и сообщения для пользователя. Это позволит в структуре хранить и обрабатывать коды не только для http и при этом имея отдельные методы для ошибок это снизит количество случаев где надо помнить какие коды для какой ошибки, упростит написание документации, больше переисполтзования и тд. Все ошибки могут быть реализованы в отдельном пакете и прикрутить авто-документирование. Это крайне удобно по итогу (особенно когда 100500 ошибок в большом проекте и нужно вести их в доке). Ну и для кастомных случаев остается публичный метод с передачей параметров в функцию. Либо сделать структуру приватной и сделать обращение к ней более строгое. В общем вариантов как улучшить всегда есть.
И да, я тоже в свое время ломал голову как адекватно прикрутить проброс ошибок.
Вы хотя бы можете писать там посты... Я вот не могу даже зайти в учетку зареганную через Яндекс. А если зашел чудом, то не могу переключиться ни на одну другую через Яндекс паспорт 😂 зато через вк авторизация кое как работает...
А может оно и к лучшему? 😂😂😂
Дополняя самого себя, у нас как всегда чтобы чем-то воспользоваться нужно потрудиться и поискать. Оказывается переехали на Artifactory и теперь образы находятся здесь: https://dl.astralinux.ru/ui/native/mg-generic/alse/cloud/
Дайте в свободный доступ образ! Верните в зад все как было! А то ни тест не получить, инструкция по получению доступа к тесту - 404 на сайте, в лк не зарегистрироваться. В общем у нас все как всегда, ни байтика опенсорсу, все за деньги?
А как вы решаете проблему, когда нужно записать в базу и сразу сделать чтение данных с учетом записанных? Если писать только в мастер, а читать из слейвов, то есть риск не получить данные. Если и писать и читать из мастера - то не получится подразмазать нагрузку. Как вы решаете такие проблемы, особенно с учетом синхрониус коммит офф? Буду благодарен за инфу :)
Нет, слайс увеличивается не всегда в 2 раза. Автор забыл упомянуть изменения в go 1.14 и 1.20 (и в 1.21 вроде как планируются еще изменения по оптимизации).
Формула роста такова:
Следить за ней можно вот тут в исходниках: go/src/runtime/slice.go
https://go.googlesource.com/go/+/2dda92ff6f9f07eeb110ecbf0fc2d7a0ddd27f9d вот тут изменения
на эту тему тут на хабре есть хорошая статейка - https://habr.com/ru/articles/525940/
если коротко - зависит от ситуации и от того что будет делать функция в которую передается этот слайс.
еще бы в сравнение gloo-edge
Спасибо за ответ :) про vault понял. За delay спасибо, не натыкался, посмотрю. Ну и по pgeon надеюсь все таки выложат. Вообще с CDC в пг все сложно))) это не тарантул ?
Спасибо за статью! Интересно было бы еще посмотреть на вашу обертку открытия соединений с чтением из vault, и разделяете ли вы соединения с мастером и слейвом, если да то как? 2 соединения и пакет для работы с конкретной базой куда передается 2 соединения и выбирается в зависимости от того что делает метод (читает или пишет). Или реплика только для фейловера (HA), а не для балансировки нагрузки?
По поводу контекста, чтобы копировать, но без cancel можно вытащить код detach метода, вроде так называется, из пакета context (почему он там приватный так и не понял, крайне полезная штука), позволяет копировать контекст (все что в нем, включая трейс, логгер и прочие переменные) не боясь что он отменится (приходилось с таким играться в errgroup).
Люблю разные новые тулзы находить и тут увидел pgeon - что это и где можно почитать? Гугл мне что-то не очень в этом помог :)
А про нормальные апи гейтвеи не слышали? Тот же kong, krakend и тд. У того же кракена есть интеграция с кроликом. Более того в вашем примере рейтлимит, проверку авторизации и прочие ништяки апи гейтвеев реализовывать будет адски геморройно, что есть из коробки у решений которые под это заточены.