Фриланс умер в РФ. Говорю как человек, который всю жизнь зарабатывал ТОЛЬКО фрилансом в ИТ. Самая крутая фриланс-биржа (ХабрФриланс естественно) вообще закрылась. На "зеленой бирже из двух букв" раньше в час несколько заказов было, сейчас раз в несколько дней дай бог если один заказ появится. И ещё не факт что вас выберут - откликнутся сто кандидатов, из которых немалая часть будет обещать нереалистично короткие сроки (которые они конечно потом сорвут, но это уже потом), и до ужаса демпинговать. Я человек с >12 лет опыта senior fullstack разработки, у меня мощное портфолио, куча положительных отзывов и ни одного отрицательного. Я не могу найти ИТ-проект ни в фрилансе ни в биржах найма (а-ля ХХ) уже 2 месяца, прикладывая ежедневные усилия. Вот и думайте сами. https://habr.com/ru/articles/1045714/
Я и без Cursor и Claude один тянул то, на что нужна была команда (чему есть расписанные подтвержденные кейсы). Вопрос ведь не в том, что вакансий нет. Они есть. Но не пробиться через AI HR-фильтры.
Хоть куда - мне не подходит вариант, у меня одна аренда дома стоит 150к и к тому же я обеспечиваю семью. Я не могу рассматривать для себя оплату ниже 300к. На заграницу работать – это гораздо легче сказать, чем сделать. Вы сам работаете за границу? В курсе что сейчас практически никто не хочет работать с кандидатами из РФ? Сюда же необходимость англ. портфолио, англ. отзывов, и прочее.
Я вот всегда новую информацию изучал по мере необходимости. Столкнулся с реальной задачей – начал изучать, разобрался, запомнил. Таким образом не тратил время на "обучение ради обучения", и за весь путь собрал огромную базу знаний у себя в голове. Это всегда работало, однако к середине 2026 даже это не помогает найти работу, о чём недавно написал статью.
Вот да, и к тому же сейчас важно наличие колоссального опыта в этом. Будто ещё совсем недавно вообще не было этих мультиагентных систем, а сейчас уже каждый должен кучу проектов за выходные в продакшен навайбкодить при помощи виртуальных команд ИИ-агентов. Откуда этому опыту взяться, если на такие позиции требуется сразу наличие такого опыта? При том, что если такой опыт отсутствует, на весь остальной опыт глубокого практического понимания fullstack-разработки, могут просто закрыть глаза.
Сейчас порог вхождения в новые технологии сильно снизился благодаря ИИ. Можно консультироваться на любую тему, и даже писать код на своём стеке, после чего просить переписать на необходимый. Или просить сгенерировать код по техническому описанию на нужном стеке, а затем объяснить как работают отдельные строки, и почему именно так. Это впечатляет на самом деле. Я использую Cursor, он наиболее удобен мне показался. Сначала было сопротивление, типа того что и без него норм, знания же есть, а сейчас понимаю что если не начал бы его использовать, будто в ногу себе выстрелил бы. Сейчас сам процесс разработки сильно трансформировался. И плюсы свои в этом тоже есть.
У меня "наблюдая, сидя на заборе" сложилось впечатление, что C уходит в прошлое, а Go всё активнее популяризуется сейчас, и явно будет востребован в будущем. Возможно я ошибаюсь, но мне так это видится..
Я бы обратил на него внимание, даже вскользь: что-то мне подсказывает, что он с тех пор вполне мог улучшиться.
Я вот за весь путь в каких только не бывал вариациях: и когда работа одна, и когда две, и когда слишком много нагрузки, а также когда вообще работы нет. И вот когда работы много, всяко лучше, чем когда её вообще нет. Так как хотя бы понятно что конкретно делать, и откуда придут финансы. Рано ли – тут как сказать, обычно за 3-4 дня активного поиска удаётся ещё повыбирать из ±5 офферов. Тут же за два месяца ни собеса. Unique...
Вам же желаю найти и получить подходящий оффер! Кстати если у Вас имеется опыт Go, вакансий на удалёнку с этим стеком я видал побольше, чем С. Не думали поискать работу на Go? Он сейчас активно становится востребованным!
Освободившись после релиза крупного проекта где я интегрировал API множества нейросетей в один бот, я начал искать full-time занятость, и сегодня написал статью по итогам двух месяцев поиска. В двух словах – со стороны соискателя процесс выхода на собес через рынок ИТ-вакансий джоб-бордов выглядит мягко говоря неутешительно. Более подробно приглашаю почитать. Вот что интересно – даже с многократным успешным опытом разработки сложных проектов с нуля до релиза и первых оплат, можно очень долгое время сидеть без работы. Что парадоксально - в этот же момент работодатели ищут хороших спецов, и им грубо говоря некого нанимать, т.к. те кого они ищут, не проходят HR-фильтры...
С теоретической точки зрения вы абсолютно правы: в классических реляционных СУБД (PostgreSQL, MySQL) механизмы, которые мы называем "вертикальным секционированием", по факту реализуются через декомпозицию таблиц (нормализацию), что перекладывает часть ответственности за атомарность создания связей на прикладной уровень или триггерную логику.
Однако в стоит разделить два аспекта:
Терминологический: Почему это называют секционированием, а не просто "перестройкой структуры"? В контексте Highload-систем термин "секционирование" (partitioning) чаще относится к стратегии оптимизации IOPS и памяти. Если мы выносим редко используемые BLOB или тяжелые TEXT поля в отдельную таблицу, чтобы уменьшить размер основной "горячей" таблицы и ускорить Full Table Scan / Index Scan — мы решаем задачу физического размещения данных, а не логического моделирования. Именно поэтому закрепился термин "вертикальное секционирование" — как описание цели действия, а не механизма СУБД.
Проблема эквивалентности схем: Ваше замечание про утрату NOT NULL через связь 1:1 абсолютно обосновано - в классическом SQL действительно нет нативного механизма "Deferred Check" для перекрестных внешних ключей, который бы гарантировал транзакционную вставку в две таблицы как в одну "атомарную" сущность на уровне схемы.
Примечание: В PostgreSQL это частично решается через DEFERRABLE INITIALLY DEFERRED внешние ключи, но это всё равно требует двух операций вставки в рамках одной транзакции.
Вы правы в том, что "нативного" вертикального секционирования (как прозрачного для пользователя механизма, аналогичного горизонтальному декларативному секционированию в PG 11+) в мейнстримных РСУБД практически нет. То, что мы имеем — это "рукотворный" паттерн.
Но называть это "просто перестройкой" тоже не совсем полно, так как цель здесь не нормализация ради чистоты данных, а управление физическим слоем хранения. Мы осознанно меняем "гарантии целостности на уровне схемы" на "производительность и масштабируемость", что является типичным архитектурным компромиссом (trade-off).
А резюме-то вы так и не прикрепили..) На словах тут каждый Лев Толстой
Фриланс умер в РФ. Говорю как человек, который всю жизнь зарабатывал ТОЛЬКО фрилансом в ИТ. Самая крутая фриланс-биржа (ХабрФриланс естественно) вообще закрылась. На "зеленой бирже из двух букв" раньше в час несколько заказов было, сейчас раз в несколько дней дай бог если один заказ появится. И ещё не факт что вас выберут - откликнутся сто кандидатов, из которых немалая часть будет обещать нереалистично короткие сроки (которые они конечно потом сорвут, но это уже потом), и до ужаса демпинговать. Я человек с >12 лет опыта senior fullstack разработки, у меня мощное портфолио, куча положительных отзывов и ни одного отрицательного. Я не могу найти ИТ-проект ни в фрилансе ни в биржах найма (а-ля ХХ) уже 2 месяца, прикладывая ежедневные усилия. Вот и думайте сами. https://habr.com/ru/articles/1045714/
Я и без Cursor и Claude один тянул то, на что нужна была команда (чему есть расписанные подтвержденные кейсы). Вопрос ведь не в том, что вакансий нет. Они есть. Но не пробиться через AI HR-фильтры.
Хоть куда - мне не подходит вариант, у меня одна аренда дома стоит 150к и к тому же я обеспечиваю семью. Я не могу рассматривать для себя оплату ниже 300к. На заграницу работать – это гораздо легче сказать, чем сделать. Вы сам работаете за границу? В курсе что сейчас практически никто не хочет работать с кандидатами из РФ? Сюда же необходимость англ. портфолио, англ. отзывов, и прочее.
Критикуете - предлагайте) Как бы вы это сделали?)
Вот вот
Добавил специально для вас 🤠
Я вот всегда новую информацию изучал по мере необходимости. Столкнулся с реальной задачей – начал изучать, разобрался, запомнил. Таким образом не тратил время на "обучение ради обучения", и за весь путь собрал огромную базу знаний у себя в голове. Это всегда работало, однако к середине 2026 даже это не помогает найти работу, о чём недавно написал статью.
Вот да, и к тому же сейчас важно наличие колоссального опыта в этом. Будто ещё совсем недавно вообще не было этих мультиагентных систем, а сейчас уже каждый должен кучу проектов за выходные в продакшен навайбкодить при помощи виртуальных команд ИИ-агентов. Откуда этому опыту взяться, если на такие позиции требуется сразу наличие такого опыта? При том, что если такой опыт отсутствует, на весь остальной опыт глубокого практического понимания fullstack-разработки, могут просто закрыть глаза.
Ну попробуйте найти работу откликнувшись 3 раза в день, или вообще в месяц 😁
Вы делегировали задачи другим людям?
Вот с ИИ что-то похожее.
Важно уметь технически точно поставить задачу, описав все нюансы, используя естественный интеллект.
И когда ИИ сгенерирует код, будто проверяя пул-реквест, необходимо проревьюить его. Можно одобрить, или отклонить, или попросить часть поправить.
И ИИ генерирует практически мгновенно. Тот же CRUD API для сущности в БД может написать за секунды полностью.
Сейчас порог вхождения в новые технологии сильно снизился благодаря ИИ. Можно консультироваться на любую тему, и даже писать код на своём стеке, после чего просить переписать на необходимый. Или просить сгенерировать код по техническому описанию на нужном стеке, а затем объяснить как работают отдельные строки, и почему именно так. Это впечатляет на самом деле. Я использую Cursor, он наиболее удобен мне показался. Сначала было сопротивление, типа того что и без него норм, знания же есть, а сейчас понимаю что если не начал бы его использовать, будто в ногу себе выстрелил бы. Сейчас сам процесс разработки сильно трансформировался. И плюсы свои в этом тоже есть.
У меня "наблюдая, сидя на заборе" сложилось впечатление, что C уходит в прошлое, а Go всё активнее популяризуется сейчас, и явно будет востребован в будущем. Возможно я ошибаюсь, но мне так это видится..
Я бы обратил на него внимание, даже вскользь: что-то мне подсказывает, что он с тех пор вполне мог улучшиться.
Я вот за весь путь в каких только не бывал вариациях: и когда работа одна, и когда две, и когда слишком много нагрузки, а также когда вообще работы нет. И вот когда работы много, всяко лучше, чем когда её вообще нет. Так как хотя бы понятно что конкретно делать, и откуда придут финансы. Рано ли – тут как сказать, обычно за 3-4 дня активного поиска удаётся ещё повыбирать из ±5 офферов. Тут же за два месяца ни собеса. Unique...
Вам же желаю найти и получить подходящий оффер! Кстати если у Вас имеется опыт Go, вакансий на удалёнку с этим стеком я видал побольше, чем С. Не думали поискать работу на Go? Он сейчас активно становится востребованным!
Освободившись после релиза крупного проекта где я интегрировал API множества нейросетей в один бот, я начал искать full-time занятость, и сегодня написал статью по итогам двух месяцев поиска. В двух словах – со стороны соискателя процесс выхода на собес через рынок ИТ-вакансий джоб-бордов выглядит мягко говоря неутешительно. Более подробно приглашаю почитать. Вот что интересно – даже с многократным успешным опытом разработки сложных проектов с нуля до релиза и первых оплат, можно очень долгое время сидеть без работы. Что парадоксально - в этот же момент работодатели ищут хороших спецов, и им грубо говоря некого нанимать, т.к. те кого они ищут, не проходят HR-фильтры...
Расстрелять этого иноагента! Замедлить ему всё что можно!
😁
272 МИЛЛИОНА комбинаций
List item
...
Верно! В любом случае лично я счёл статью достаточно интересной и полезной, потому и опубликовал её переведённую на русский язык версию.
С теоретической точки зрения вы абсолютно правы: в классических реляционных СУБД (PostgreSQL, MySQL) механизмы, которые мы называем "вертикальным секционированием", по факту реализуются через декомпозицию таблиц (нормализацию), что перекладывает часть ответственности за атомарность создания связей на прикладной уровень или триггерную логику.
Однако в стоит разделить два аспекта:
Терминологический: Почему это называют секционированием, а не просто "перестройкой структуры"? В контексте Highload-систем термин "секционирование" (partitioning) чаще относится к стратегии оптимизации IOPS и памяти. Если мы выносим редко используемые
BLOBили тяжелыеTEXTполя в отдельную таблицу, чтобы уменьшить размер основной "горячей" таблицы и ускорить Full Table Scan / Index Scan — мы решаем задачу физического размещения данных, а не логического моделирования. Именно поэтому закрепился термин "вертикальное секционирование" — как описание цели действия, а не механизма СУБД.Проблема эквивалентности схем: Ваше замечание про утрату
NOT NULLчерез связь 1:1 абсолютно обосновано - в классическом SQL действительно нет нативного механизма "Deferred Check" для перекрестных внешних ключей, который бы гарантировал транзакционную вставку в две таблицы как в одну "атомарную" сущность на уровне схемы.Примечание: В PostgreSQL это частично решается через
DEFERRABLE INITIALLY DEFERREDвнешние ключи, но это всё равно требует двух операций вставки в рамках одной транзакции.Вы правы в том, что "нативного" вертикального секционирования (как прозрачного для пользователя механизма, аналогичного горизонтальному декларативному секционированию в PG 11+) в мейнстримных РСУБД практически нет. То, что мы имеем — это "рукотворный" паттерн.
Но называть это "просто перестройкой" тоже не совсем полно, так как цель здесь не нормализация ради чистоты данных, а управление физическим слоем хранения. Мы осознанно меняем "гарантии целостности на уровне схемы" на "производительность и масштабируемость", что является типичным архитектурным компромиссом (trade-off).
😁 юмор же тоже должен присутствовать в статье, чтобы не скучно было читать такую стену текста
вам плюсик за внимательность к пасхалкам ✅