Я вот всегда новую информацию изучал по мере необходимости. Столкнулся с реальной задачей – начал изучать, разобрался, запомнил. Таким образом не тратил время на "обучение ради обучения", и за весь путь собрал огромную базу знаний у себя в голове. Это всегда работало, однако к середине 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).
Но это не попало в мои первые 3 действия. Можно объяснять пользователю, что возможность была, но какой смысл, если он уже ушёл. Эта статья нужна чтобы обратить внимание на важность получения обратной связи от пользователей, и на проверку багов, а не для того чтобы убедить, что в Кошельке невозможно найти способ связаться с поддержкой.
Действительно интересная статья, и вправду нужно использовать ИИ чтобы обрести суперсилу, а не бояться, что ИИ заменит. Пускай заменяет и ускоряет рутину! И более того – сейчас особо выбора нет, можно бояться, а можно учиться использовать ИИ чтобы быть эффективным. Если не учиться – обгонят. И именно учиться, т.к. не умея пользоваться ИИ, можно даже ухудшить рабочий процесс 🧐 Но как говорится – это не rocket science, главное действовать, изучать, применять.
Критикуете - предлагайте) Как бы вы это сделали?)
Вот вот
Добавил специально для вас 🤠
Я вот всегда новую информацию изучал по мере необходимости. Столкнулся с реальной задачей – начал изучать, разобрался, запомнил. Таким образом не тратил время на "обучение ради обучения", и за весь путь собрал огромную базу знаний у себя в голове. Это всегда работало, однако к середине 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).
😁 юмор же тоже должен присутствовать в статье, чтобы не скучно было читать такую стену текста
вам плюсик за внимательность к пасхалкам ✅
Небольшой кнопки в подвале каждого экрана было бы достаточно.
Но это не попало в мои первые 3 действия. Можно объяснять пользователю, что возможность была, но какой смысл, если он уже ушёл. Эта статья нужна чтобы обратить внимание на важность получения обратной связи от пользователей, и на проверку багов, а не для того чтобы убедить, что в Кошельке невозможно найти способ связаться с поддержкой.
Рад привествовать, уважаемый
Прошёлся по тексту ещё раз, благодарю за замечание
Они такие :-)
Я смотрю тут под каждой статьёй не дадут расслабиться господа орфографисты-пунктуологи! Бдят изо всех сил!
Я стараюсь писать грамотно, правда! :D
Действительно интересная статья, и вправду нужно использовать ИИ чтобы обрести суперсилу, а не бояться, что ИИ заменит. Пускай заменяет и ускоряет рутину! И более того – сейчас особо выбора нет, можно бояться, а можно учиться использовать ИИ чтобы быть эффективным. Если не учиться – обгонят. И именно учиться, т.к. не умея пользоваться ИИ, можно даже ухудшить рабочий процесс 🧐 Но как говорится – это не rocket science, главное действовать, изучать, применять.