Раз уж меня в чате спросили, по каким направления я подавал резюме, думаю, что и здесь можно поделиться моим экспериментом.
204 · Двойная подача
Я тут начал практиковать двойную подачу резюме на вакансии. В чём её суть? Сначала я откликаюсь на вакансию со своим обычным резюме. Затем в течение 10-20 минут подаю отклик с другого аккаунта, используя объективно слабо подходящее резюме. Второе резюме должно практически гарантированно получать отказ. К примеру, в моём случае я отправляю резюме бывшего дизайнера на позицию разработчика без релевантного опыта и профильных курсов. Проделав такую подачу насколько раз, можно сделать определенные выводы.
Что же даёт двойная подача? Если говорить в общем, мы хотим понять, насколько наше резюме работает лучше, чем объективно плохое. Так как резюме подаются практически одновременно, то велика вероятность, что они попадут в один кластер просматриваемых резюме. Затем мы смотрим на время ответа работодателя. И тут возможны несколько вариантов.
Вариант 1. Оба резюме не получают отклика или получают отказ (практически) одновременно. Это плохой вариант: он означает, что наше основное резюме работает не лучше плохого и не может пройти первичный фильтр. Стоит отдельно отметить, что первичный фильтр может быть разным — ключевые слова, время отклика и т.д.
Вариант 2. Основное резюме получает отказ через несколько дней после отказа по плохому резюме. Это означает, что наше резюме прошло самый первичный отбор, но было отклонено на одном из последующих этапов. На мой взгляд, хорошее резюме в большинстве случаев должно следовать именно этому паттерну.
Вариант 3. Оба резюме получают приглашение на следующий этап. Тут всё просто: вероятнее всего, вакансия — скам.
Вариант 4. Хорошее резюме получает отказ, а плохое не получает ответа. Я считаю, что это тоже хороший вариант. Самый первичный фильтр пройден, а на следующем этапе было принято решение отказать. Плохое же резюме не прошло даже первичный отбор.
В общем, как видите, если человек не может найти работу, он найдёт чем заняться, пока ищет работу 😅
6 · 321 · Ссылка
нажмите — покажем
нажмите — покажем
Можете меня поздравить, я наконец начал пользоваться нейронками. В обнимку с клодом 4.7 смог написать код нового воркера, который параллельно процессит задачи из очереди на базе postgresql. Признаюсь честно - сам бы я такое не написал. Точнее думал бы, что написал, но оно бы не работало. Клод нашёл просто немеряное количество багов с взятием и освобождением ресурсов на всех итерациях. Сжёг на это приличное количество токенов, но оно таки работает. Можете посмотреть пример если у кого-то есть похожая задача:
https://github.com/IgorZyktin/omoide/tree/main/omoide/workers/parallel
Попутно мне пришлось устроить манкипатч в asyncpg-lostream. Временно руками исправил код прямо внутри установленной библиотеки т.к. там есть баг в одном месте. В итоге я сделал форк. Думаю надо будет исправить в нём найденный баг, собрать и залить на pypi. Автор оригинального проекта написал его 4 года назад и уже год в гите не появлялся, не думаю, что есть смысл ему писать с предложением исправления
D S И руки не доходят. давно смотрел в сторону minio, но всё времени никак нет сесть его настроить. это ж виртуалку надо выделить, диск в неё просунуть, я пока с проксмоксом сильно на вы. так что по старинке храню файлы на диске, а лью сквозь постгрес. зато удобно работать можно их смотреть, редактировать и всё такоеS
Воркер был мне нужен для процессинга операций от пользователя на файловой системе. Это загрузка новой картинки, удаление старой, копирование из одного места в другое. Все эти операции могут исполняться параллельно, но только с одной записью за раз. В pg есть таблица со списком команд на исполнение.
Флоу работы такой:
1. Выгрести из таблицы 10 команд через select for update skip locked.
2. Посмотреть id записей для которых эти команды написаны. Попытаться взять лок в pg на эти id через pg_locks.
3. Если удалось взять блокировку, сделать 10 корутин и запустить их внутри task group для параллельного исполнения.
4. Внутри есть process pull executor, в который можно засунуть CPU-bound задачи.
5. По завершению мы отпускаем локи на записи.
6. Если несколько команд работало с одним и тем же postgres large object, он остаётся жить до тех пор, пока не завершится последняя команда которой он нужен.
В итоге пользователь приходит на сайт, загружает несколько картинок. Они сохраняются в pg large object. Для каждой делается задача на сохранение на диск и вот этот воркер или несколько таких воркеров их процессят. В воркере ограничение на 5 процессов, так что 5 штук жмутся параллельно для каждого инстанса воркера (пока один, но скоро будут два).
Ещё qwen3 мне сильно помог. У меня была проблема с тем что я задал слишком мелкий раздел под систему при установке на машину и там постоянно кончалось место. Он мне сказал, что у меня там оказывается LVM и можно изменить размер одной, ну двумя, командами. А я уже планировал операционку переустанавливать...
Ссылка
нажмите — покажем
нажмите — покажем
И всё ради возможность смотреть вот такое
https://omoide.cc/preview/79524637-1806-448f-99d0-e53eae95bdb3?q=%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D1%91%D0%BD%D0%BD%D1%8B%D0%B5+%D1%80%D0%BE%D0%BB%D0%B8%D0%BA%D0%B8+&page=1