Как эволюционировали OCR-программы
Инструменты для распознавания текста (OCR) появились еще в 1960-х, но только последние 20 лет они используются для чтения документов и облегчают нашу с вами жизнь.
За этот период направление получило мощное развитие: от простого считывания перешло к мультимодальной форензике и антифроду. Подробнее про историю этого увлекательного процесса можно прочитать в этой статье.
Инструменты для распознавания текста (OCR) появились еще в 1960-х, но только последние 20 лет они используются для чтения документов и облегчают нашу с вами жизнь.
За этот период направление получило мощное развитие: от простого считывания перешло к мультимодальной форензике и антифроду. Подробнее про историю этого увлекательного процесса можно прочитать в этой статье.
👍1
Если вы когда-нибудь работали в кровавом энтерпрайзе на Java, этот репозиторий может вызвать у вас флешбеки и легкую панику. Разработчики создали пародийный проект FizzBuzz Enterprise Edition — ту самую задачу с собеседований про деление чисел на 3 и 5, но написанную «серьёзными бизнесменами для серьёзных бизнес-целей».
Вместо десяти строк кода авторы наворотили гигантскую архитектуру. Внутри бесконечные вложенные папки, десяток фабрик, интерфейсы для интерфейсов и классы с названиями в духе
Отдельный вид искусства в этом проекте — раздел Issues. Пользователи активно подыгрывают авторам и создают гениальные тикеты. Например, кто-то пожаловался, что код написан слишком качественно и потребовал ухудшить его, чтобы соответствовать реальным индустриальным стандартам. Или предлагают уволить бизнес-аналитика, потому что он слишком понятно объяснил задачу, и требуют добавить больше уровней абстракции, чтобы никто не смог найти, откуда импортируется код.
@prog_stuff
Вместо десяти строк кода авторы наворотили гигантскую архитектуру. Внутри бесконечные вложенные папки, десяток фабрик, интерфейсы для интерфейсов и классы с названиями в духе
FizzBuzzOutputGenerationContextVisitor.
Отдельный вид искусства в этом проекте — раздел Issues. Пользователи активно подыгрывают авторам и создают гениальные тикеты. Например, кто-то пожаловался, что код написан слишком качественно и потребовал ухудшить его, чтобы соответствовать реальным индустриальным стандартам. Или предлагают уволить бизнес-аналитика, потому что он слишком понятно объяснил задачу, и требуют добавить больше уровней абстракции, чтобы никто не смог найти, откуда импортируется код.
@prog_stuff
😁4❤3👍1
Scientific American собрали свежую статистику о том, как нейросети влияют на жизнь разработчиков. Изначально все надеялись, что ИИ разгрузит инженеров, но реальные цифры показывают обратную картину: программисты стали работать больше и чаще перерабатывать по вечерам.
Главные причины такого парадокса:
— Падает стабильность релизов. Нейросети выдают код мгновенно, но его нужно тщательно проверять. Отчёт DORA подтверждает, что активное использование ИИ напрямую связано с ростом откатов и горячих фиксов на проде.
— Растут ожидания руководства. Бизнес замечает ускорение и требует закрывать больше задач. В итоге инженеры берут дополнительный объем, а количество их коммитов в нерабочие часы выросло почти на 20%
— Усложняется отладка. Инженеры объективно хуже понимают сгенерированную логику. Когда такой код ломается, на поиск причин и исправление багов уходит гораздо больше сил.
Получается, что инструменты действительно ускоряют написание новых блоков, но вся экономия времени полностью сгорает на этапах тестирования и ревью. А если вы начинаете писать код быстрее, в качестве награды менеджеры просто накидывают вам больше новых тикетов.
Полная статья: https://www.scientificamerican.com/article/why-developers-using-ai-are-working-longer-hours/
@prog_stuff
Главные причины такого парадокса:
— Падает стабильность релизов. Нейросети выдают код мгновенно, но его нужно тщательно проверять. Отчёт DORA подтверждает, что активное использование ИИ напрямую связано с ростом откатов и горячих фиксов на проде.
— Растут ожидания руководства. Бизнес замечает ускорение и требует закрывать больше задач. В итоге инженеры берут дополнительный объем, а количество их коммитов в нерабочие часы выросло почти на 20%
— Усложняется отладка. Инженеры объективно хуже понимают сгенерированную логику. Когда такой код ломается, на поиск причин и исправление багов уходит гораздо больше сил.
Получается, что инструменты действительно ускоряют написание новых блоков, но вся экономия времени полностью сгорает на этапах тестирования и ревью. А если вы начинаете писать код быстрее, в качестве награды менеджеры просто накидывают вам больше новых тикетов.
Полная статья: https://www.scientificamerican.com/article/why-developers-using-ai-are-working-longer-hours/
@prog_stuff
👍8
Разработчик Рич Уайтхаус написал жёсткую статью о том, почему он полностью разочаровался в опенсорсе и перестал писать бесплатный код. По его мнению, вся эта культура в итоге просто помогает крупным корпорациям обесценивать работу обычных инженеров.
Главные мысли из его лонгрида:
— компании годами используют открытые репозитории как бесплатную ресурсную базу, при этом регулярно забивая на лицензии;
— бум нейросетей только добил ситуацию, корпорации молча скормили своим моделям десятилетия чужого труда без оглядки на авторское право;
— внутри самих опенсорсных комьюнити процветает токсичность, синдром вахтера и бесконечные споры ради раздутого эго мейнтейнеров.
Уайтхаус уверен, что идея писать код на общее благо отлично звучит только в теории. На практике любые полезные наработки быстро и безвозмездно забирают гиганты индустрии. В итоге это бьёт по нам самим. Ценность разработчиков на рынке падает, потому что бизнесу становится выгоднее вкладываться в серверы и ИИ, бесплатно обученный на нашем же коде.
Полная статья: https://richwhitehouse.com/index.php?postid=77
@prog_stuff
Главные мысли из его лонгрида:
— компании годами используют открытые репозитории как бесплатную ресурсную базу, при этом регулярно забивая на лицензии;
— бум нейросетей только добил ситуацию, корпорации молча скормили своим моделям десятилетия чужого труда без оглядки на авторское право;
— внутри самих опенсорсных комьюнити процветает токсичность, синдром вахтера и бесконечные споры ради раздутого эго мейнтейнеров.
Уайтхаус уверен, что идея писать код на общее благо отлично звучит только в теории. На практике любые полезные наработки быстро и безвозмездно забирают гиганты индустрии. В итоге это бьёт по нам самим. Ценность разработчиков на рынке падает, потому что бизнесу становится выгоднее вкладываться в серверы и ИИ, бесплатно обученный на нашем же коде.
Полная статья: https://richwhitehouse.com/index.php?postid=77
@prog_stuff
👍8❤3🔥1
В блоге NixCI вышла отличная статья, которая ставит под сомнение привычный всем нам процесс работы с непрерывной интеграцией. Обычно мы воспринимаем CI как удалённый сервер (GitHub Actions, GitLab CI), куда мы пушим код и ждём заветную зелёную галочку. Но у этого подхода есть огромный минус — длинная петля обратной связи.
Классический флоу выглядит так: закоммитил → запушил → подождал раннер → подождал установку зависимостей и тесты → переключил контекст на другую задачу → вернулся, увидел красный крестик и пытаешься вспомнить, что вообще делал.
Автор предлагает концепцию Local-First CI. Идея в том, что вся пайплайн-логика должна быть описана так, чтобы она могла локально выполниться на машине разработчика до пуша в репозиторий.
Какие плюсы у локального CI:
— Скорость. Рабочие машины разработчиков (особенно современные Mac) часто гораздо мощнее стандартных бесплатных раннеров (у тех же GitHub Actions всего 4 vCPU и 16 GB RAM).
— Фокус. Вы не переключаете контекст. Ошибка падает сразу, и вы фиксите её, оставаясь в потоке.
— Отсутствие вендор-лока. Если весь ваш CI — это условный баш-скрипт
— Локальная воспроизводимость. Больше не нужно делать коммиты с названиями
Есть и минусы, конечно.
Главная проблема наивного подхода с
Решением автор логично называет воспроизводимые сборки (reproducible builds), в частности — использование Nix. Команда
Полная статья: https://blog.nix-ci.com/post/2026-03-09_ci-should-fail-on-your-machine-first
@prog_stuff
Классический флоу выглядит так: закоммитил → запушил → подождал раннер → подождал установку зависимостей и тесты → переключил контекст на другую задачу → вернулся, увидел красный крестик и пытаешься вспомнить, что вообще делал.
Автор предлагает концепцию Local-First CI. Идея в том, что вся пайплайн-логика должна быть описана так, чтобы она могла локально выполниться на машине разработчика до пуша в репозиторий.
Какие плюсы у локального CI:
— Скорость. Рабочие машины разработчиков (особенно современные Mac) часто гораздо мощнее стандартных бесплатных раннеров (у тех же GitHub Actions всего 4 vCPU и 16 GB RAM).
— Фокус. Вы не переключаете контекст. Ошибка падает сразу, и вы фиксите её, оставаясь в потоке.
— Отсутствие вендор-лока. Если весь ваш CI — это условный баш-скрипт
./ci.sh в корне проекта, вам всё равно, где его запускать. Вы не привязаны к специфичным YAML-файлам конкретного провайдера.— Локальная воспроизводимость. Больше не нужно делать коммиты с названиями
fix ci, try again, maybe now?, пытаясь вслепую угадать, почему тест падает на сервере, но работает у вас.Есть и минусы, конечно.
Главная проблема наивного подхода с
./ci.sh — рассинхрон сред. У вас локально macOS и gcc 15, а на сервере Ubuntu и gcc 14. У вас замусоренная папка с билдами и завалявшийся .env, а CI стартует с чистого листа.Решением автор логично называет воспроизводимые сборки (reproducible builds), в частности — использование Nix. Команда
nix flake check гарантирует, что локальное и удалённое окружение будут абсолютно идентичными вплоть до версий системных библиотек . Но даже без Nix, максимальный перенос логики проверок в локальную среду (например, через Docker) — это отличная практика для ускорения разработки.Полная статья: https://blog.nix-ci.com/post/2026-03-09_ci-should-fail-on-your-machine-first
@prog_stuff
❤2👍2💯1
Интересная мысль из недавних обсуждений: «ИИ не сделает вас богатым, а вот починка багов в сгенерированном ИИ-мусоре — сделает». Сейчас все увлеклись генерацией кода: джуны, менеджеры и стартаперы штампуют проекты целыми кусками с помощью Claude и Copilot. В результате на свет появляется так называемый «AI slopware» — код, который вроде бы работает на демо-стенде, но внутри представляет собой неподдерживаемое спагетти.
Проблема в том, что нейронки отлично пишут куски кода, но они не понимают архитектурных ограничений, бизнес-логики и скрытых зависимостей всей системы. Когда этот сгенерированный код попадает в продакшен, он неизбежно начинает ломаться. И вот тут выясняется, что человек, который просто нажимал Tab и принимал подсказки от ИИ, не способен починить баг, потому что он не понимает, как этот код работает под капотом.
Автор поста считает, что золотая лихорадка ИИ-стартапов и бесконечных «ChatGPT-обёрток» скоро пойдёт на спад. А вот горы некачественного, сгенерированного кода останутся в корпоративном секторе на десятилетия.
В ближайшие годы самой высокооплачиваемой и востребованной работой станет не написание новых фичей, а хардкорный дебаггинг и рефакторинг этого самого «ИИ-мусора». Компании будут готовы платить огромные деньги инженерам с глубоким пониманием систем, способным разгрести архитектурные катастрофы, оставленные автогенераторами.
Умение вслепую промтить нейросети перестанет быть преимуществом. Главным навыком снова станет фундаментальное понимание того, как работают технологии.
Полный текст: https://boreal.social/post/ai-wont-make-you-rich-but-fixing-bugs-in-ai-slopware-will
@prog_stuff
Проблема в том, что нейронки отлично пишут куски кода, но они не понимают архитектурных ограничений, бизнес-логики и скрытых зависимостей всей системы. Когда этот сгенерированный код попадает в продакшен, он неизбежно начинает ломаться. И вот тут выясняется, что человек, который просто нажимал Tab и принимал подсказки от ИИ, не способен починить баг, потому что он не понимает, как этот код работает под капотом.
Автор поста считает, что золотая лихорадка ИИ-стартапов и бесконечных «ChatGPT-обёрток» скоро пойдёт на спад. А вот горы некачественного, сгенерированного кода останутся в корпоративном секторе на десятилетия.
В ближайшие годы самой высокооплачиваемой и востребованной работой станет не написание новых фичей, а хардкорный дебаггинг и рефакторинг этого самого «ИИ-мусора». Компании будут готовы платить огромные деньги инженерам с глубоким пониманием систем, способным разгрести архитектурные катастрофы, оставленные автогенераторами.
Умение вслепую промтить нейросети перестанет быть преимуществом. Главным навыком снова станет фундаментальное понимание того, как работают технологии.
Полный текст: https://boreal.social/post/ai-wont-make-you-rich-but-fixing-bugs-in-ai-slopware-will
@prog_stuff
👍3✍2
На Tproger вышла статья со сравнением антивирусов специально под рабочие процессы разработчиков.
Главная проблема такого софта в том, что он часто тормозит тяжёлые сборки или ошибочно блокирует нужные утилиты.
Коллеги из редакции сайта проверили:
— Насколько сильно фоновые проверки нагружают систему в рабочие часы.
— Как разные продукты справляются с изоляцией подозрительных скриптов и фишингом.
— За какие дополнительные функции действительно стоит платить из своего кармана.
Полная статья: https://tproger.ru/articles/kakoj-antivirus-my-vybrali--proverili-3-antivirusa-po-cene--aler
@prog_stuff
Главная проблема такого софта в том, что он часто тормозит тяжёлые сборки или ошибочно блокирует нужные утилиты.
Коллеги из редакции сайта проверили:
— Насколько сильно фоновые проверки нагружают систему в рабочие часы.
— Как разные продукты справляются с изоляцией подозрительных скриптов и фишингом.
— За какие дополнительные функции действительно стоит платить из своего кармана.
Полная статья: https://tproger.ru/articles/kakoj-antivirus-my-vybrali--proverili-3-antivirusa-po-cene--aler
@prog_stuff
❤2✍1🌚1
BYOVD: как детектить атаку, если EDR слаб перед ней
Есть такая техника, при которой EDR — мощнейшее ПО для мониторинга, обнаружения и реагирования на угрозы — бессессильно. Эта техника называется BYOVD (Bring Your Own Vulnerable Driver). С ее помощью злоумышленники проникают в систему, повышают привилегии и потом совершают мошенничество. Именно BYOVD был одним из ключевых этапов при атаках на СДЭК, Аэрофлот, «Верный».
Как обезопасить свою проект от этой напасти? В статье — готовая стратегия обнаружения и чек-лист для вашей инфраструктуры.
Есть такая техника, при которой EDR — мощнейшее ПО для мониторинга, обнаружения и реагирования на угрозы — бессессильно. Эта техника называется BYOVD (Bring Your Own Vulnerable Driver). С ее помощью злоумышленники проникают в систему, повышают привилегии и потом совершают мошенничество. Именно BYOVD был одним из ключевых этапов при атаках на СДЭК, Аэрофлот, «Верный».
Как обезопасить свою проект от этой напасти? В статье — готовая стратегия обнаружения и чек-лист для вашей инфраструктуры.
Разработчик Эрик Ленгьел (Eric Lengyel) сделал огромный подарок для индустрии графики и геймдева. Он досрочно, за 12 лет до истечения срока, передал патент на свой знаменитый алгоритм Slug в общественное достояние.
Slug — это метод рендеринга шрифтов (и векторной графики) на GPU напрямую из кривых Безье, вообще без использования предзапечённых текстур или атласов. Это позволяет отрисовывать идеально чёткий, сглаженный текст любого размера и под любым углом. Алгоритм уже 10 лет является индустриальным стандартом: лицензию на него покупали Blizzard, id Software, Adobe, Ubisoft и другие гиганты.
Главная математическая фишка последних версий Slug — это «динамическое расширение» (dynamic dilation). Вершинный шейдер на лету высчитывает матрицу трансформации и автоматически расширяет полигон каждого глифа ровно на полпикселя в экранном пространстве. Это гарантирует, что растеризатор не потеряет ни одного сглаженного пикселя на границах букв, и при этом не тратит ресурсы GPU на отрисовку лишнего пустого пространства (как это бывает при фиксированном отступе).
Теперь использовать эту технологию можно абсолютно бесплатно в любых проектах. Автор уже выложил эталонные шейдеры (вершинный и пиксельный) на GitHub под лицензией MIT: https://github.com/EricLengyel/Slug
@prog_stuff
Slug — это метод рендеринга шрифтов (и векторной графики) на GPU напрямую из кривых Безье, вообще без использования предзапечённых текстур или атласов. Это позволяет отрисовывать идеально чёткий, сглаженный текст любого размера и под любым углом. Алгоритм уже 10 лет является индустриальным стандартом: лицензию на него покупали Blizzard, id Software, Adobe, Ubisoft и другие гиганты.
Главная математическая фишка последних версий Slug — это «динамическое расширение» (dynamic dilation). Вершинный шейдер на лету высчитывает матрицу трансформации и автоматически расширяет полигон каждого глифа ровно на полпикселя в экранном пространстве. Это гарантирует, что растеризатор не потеряет ни одного сглаженного пикселя на границах букв, и при этом не тратит ресурсы GPU на отрисовку лишнего пустого пространства (как это бывает при фиксированном отступе).
Теперь использовать эту технологию можно абсолютно бесплатно в любых проектах. Автор уже выложил эталонные шейдеры (вершинный и пиксельный) на GitHub под лицензией MIT: https://github.com/EricLengyel/Slug
@prog_stuff
❤2❤🔥1👍1
В блоге Dochia вышла интересная статья о том, как нейросети незаметно возвращают нас к методологии Waterfall.
В эпоху классического Agile мы привыкли работать короткими итерациями с минимальными требованиями. Идея состояла в том, чтобы не тратить месяцы на детальные спецификации. Бизнес все равно изменит планы, а писать код долго и дорого. Дешевле было быстро сделать базовую фичу, получить обратную связь и переделать.
С приходом продвинутых ИИ агентов математика процесса сильно изменилась:
— агенты пишут код невероятно быстро и дёшево;
— они совершенно не умеют додумывать контекст и работать с абстрактными задачами, как это делают живые разработчики;
— любая недосказанность в промте превращается в ошибочную архитектуру, которую вы обнаружите только через несколько спринтов.
Чтобы ИИ выдавал рабочий результат, ему нужна максимально подробная и жёсткая спецификация с описанием всех контрактов и граничных случаев. То есть именно то, за что разработчики так не любили Waterfall.
Формируется новая парадигма. Написание ТЗ снова становится самым дорогим этапом, в котором незаменим человек. Код при этом превращается в дешёвый одноразовый расходник. Вы пишете подробные требования, отдаёте их нейросети, показываете результат пользователям, и если что-то не так, просто меняете ТЗ и генерируете проект заново.
Автор замечает, что это может стать большой проблемой для индустрии. Большинство из нас пришли в профессию, чтобы писать код, а не составлять многостраничные спецификации для нейросетей.
Ссылка на полную статью: https://blog.dochia.dev/blog/waterfall-returning/
@prog_stuff
В эпоху классического Agile мы привыкли работать короткими итерациями с минимальными требованиями. Идея состояла в том, чтобы не тратить месяцы на детальные спецификации. Бизнес все равно изменит планы, а писать код долго и дорого. Дешевле было быстро сделать базовую фичу, получить обратную связь и переделать.
С приходом продвинутых ИИ агентов математика процесса сильно изменилась:
— агенты пишут код невероятно быстро и дёшево;
— они совершенно не умеют додумывать контекст и работать с абстрактными задачами, как это делают живые разработчики;
— любая недосказанность в промте превращается в ошибочную архитектуру, которую вы обнаружите только через несколько спринтов.
Чтобы ИИ выдавал рабочий результат, ему нужна максимально подробная и жёсткая спецификация с описанием всех контрактов и граничных случаев. То есть именно то, за что разработчики так не любили Waterfall.
Формируется новая парадигма. Написание ТЗ снова становится самым дорогим этапом, в котором незаменим человек. Код при этом превращается в дешёвый одноразовый расходник. Вы пишете подробные требования, отдаёте их нейросети, показываете результат пользователям, и если что-то не так, просто меняете ТЗ и генерируете проект заново.
Автор замечает, что это может стать большой проблемой для индустрии. Большинство из нас пришли в профессию, чтобы писать код, а не составлять многостраничные спецификации для нейросетей.
Ссылка на полную статью: https://blog.dochia.dev/blog/waterfall-returning/
@prog_stuff
🙈5🔥1
Если вы помните эссе Пола Грэма про Founder Mode, то сооснователь GitLab Сид Сийбрандий нашёл этой концепции самое нетривиальное применение. В 2022 году у него обнаружили редкий рак костей, а после первого этапа лечения случился рецидив. Врачи сообщили, что стандартные протоколы исчерпаны.
Вместо того чтобы смириться, Сид перестал делегировать медицинские решения больницам. Он взял управление ситуацией в свои руки, нанял бывшего руководителя из компании 10x Genomics на роль проектного менеджера своего здоровья и собрал личную команду учёных.
Его инженерный подход к онкологии выглядел так:
— команда сделала полное секвенирование клеток опухоли и использовала ИИ для поиска скрытых закономерностей в анализах;
— Сид выложил 25 терабайт своих медицинских данных в открытый доступ, чтобы любой исследователь в мире мог изучить их и предложить решение;
— глубокий анализ данных помог найти в Германии экспериментальную терапию, которая точечно била по уязвимости именно его формы опухоли;
— параллельно с собственным лечением он запустил семь стартапов в сфере биотеха для развития персонализированной медицины.
На данный момент рак у Сида не обнаруживается. Конечно, такой индивидуальный подход доступен только людям с огромными ресурсами. Но, блин, семь новых компаний, ребят. Это как минимум круто.
Полная статья: https://tprg.ru/a19w
@prog_stuff
Вместо того чтобы смириться, Сид перестал делегировать медицинские решения больницам. Он взял управление ситуацией в свои руки, нанял бывшего руководителя из компании 10x Genomics на роль проектного менеджера своего здоровья и собрал личную команду учёных.
Его инженерный подход к онкологии выглядел так:
— команда сделала полное секвенирование клеток опухоли и использовала ИИ для поиска скрытых закономерностей в анализах;
— Сид выложил 25 терабайт своих медицинских данных в открытый доступ, чтобы любой исследователь в мире мог изучить их и предложить решение;
— глубокий анализ данных помог найти в Германии экспериментальную терапию, которая точечно била по уязвимости именно его формы опухоли;
— параллельно с собственным лечением он запустил семь стартапов в сфере биотеха для развития персонализированной медицины.
На данный момент рак у Сида не обнаруживается. Конечно, такой индивидуальный подход доступен только людям с огромными ресурсами. Но, блин, семь новых компаний, ребят. Это как минимум круто.
Полная статья: https://tprg.ru/a19w
@prog_stuff
❤5
Открываешь Claude или Cursor, просишь нейросеть сделать лендинг или телеграм-бота. Через пару часов действительно есть рабочий прототип.
А потом либо форма отправляет заявки в никуда, потому что подключение к БД собрано без обработки ошибок, либо вообще весь сайт ложится после первой реальной нагрузки. В этом кроется главная ловушка вайбкодинга: нейросети умеют писать код, но архитектуру и инфраструктуру всё равно приходится продумывать человеку.
Если вы уже пробовали писать код с ИИ, но хотите перейти от прототипов на коленке к продуктам, которые можно развивать и масштабировать, обратите внимание на курс Яндекс Практикума PRO «Вайбкодинг».
Чем будете заниматься во время обучения:
— Соберёте 3+ продукта: лендинг, CRM-систему и сервис бронирования.
В расширенных тарифах — ещё и телеграм-бота.
— Попробуете разное ИИ-окружение, в том числе Replit, Lovable, Cursor, DeepSeek, Giga Code.
— Изучите базы данных и интеграции: подключите PostgreSQL, настроите API, чтобы заявки не терялись, а уведомления приходили.
— Разберетесь в архитектуре и тестировании, чтобы добавление новых функций не рушило старые.
Курс подойдет предпринимателям, продактам, маркетологам, поэтому навыки программирования не обязательны.
Попробовать свои силы можно на бесплатной вводной части: https://tprg.ru/17RL
Это #партнёрский пост
А потом либо форма отправляет заявки в никуда, потому что подключение к БД собрано без обработки ошибок, либо вообще весь сайт ложится после первой реальной нагрузки. В этом кроется главная ловушка вайбкодинга: нейросети умеют писать код, но архитектуру и инфраструктуру всё равно приходится продумывать человеку.
Если вы уже пробовали писать код с ИИ, но хотите перейти от прототипов на коленке к продуктам, которые можно развивать и масштабировать, обратите внимание на курс Яндекс Практикума PRO «Вайбкодинг».
Чем будете заниматься во время обучения:
— Соберёте 3+ продукта: лендинг, CRM-систему и сервис бронирования.
В расширенных тарифах — ещё и телеграм-бота.
— Попробуете разное ИИ-окружение, в том числе Replit, Lovable, Cursor, DeepSeek, Giga Code.
— Изучите базы данных и интеграции: подключите PostgreSQL, настроите API, чтобы заявки не терялись, а уведомления приходили.
— Разберетесь в архитектуре и тестировании, чтобы добавление новых функций не рушило старые.
Курс подойдет предпринимателям, продактам, маркетологам, поэтому навыки программирования не обязательны.
Попробовать свои силы можно на бесплатной вводной части: https://tprg.ru/17RL
Это #партнёрский пост
👍1👌1🤪1
Хочу стать техлидом — большая подборка материалов
Развиваться в техническом лидерстве — это не просто полезно, но и стратегически важно. Хороший техлид должен разбираться не только в коде, но и в архитектуре, управлении командами и даже бизнесе.
В этой подборке собрано 100+ крутых ресурсов: книги, блоги, рассылки и эксперты, которых стоит читать. Тут есть всё — от глубокой системной архитектуры до навыков эффективного менеджмента. Не стоит гнаться за всем сразу, лучше выбрать несколько направлений и прокачиваться в них.
Сохраняем мастхев для карьеры в этом репозитории
#подборка #en
Развиваться в техническом лидерстве — это не просто полезно, но и стратегически важно. Хороший техлид должен разбираться не только в коде, но и в архитектуре, управлении командами и даже бизнесе.
В этой подборке собрано 100+ крутых ресурсов: книги, блоги, рассылки и эксперты, которых стоит читать. Тут есть всё — от глубокой системной архитектуры до навыков эффективного менеджмента. Не стоит гнаться за всем сразу, лучше выбрать несколько направлений и прокачиваться в них.
Сохраняем мастхев для карьеры в этом репозитории
#подборка #en
GitHub
GitHub - gregorojstersek/resources-to-become-a-great-engineering-leader: List of books, blogs, newsletters and people!
List of books, blogs, newsletters and people! Contribute to gregorojstersek/resources-to-become-a-great-engineering-leader development by creating an account on GitHub.
Отправить email из скрипта — вызов одной функции. Сделать так, чтобы он дошёл до инбокса и не улетел в спам — инженерия.
На Tproger вышел перевод с пошаговым разбором того, как почта работает под капотом на уровне инфраструктуры:
— Цепочка доставки: MUA (клиент), MTA (сервер пересылки), MDA (агент доставки).
— Как SMTP ищет маршрут до целевого домена через DNS и MX-записи.
— Подробный разбор SPF, DKIM и DMARC, это база, которую нужно понимать, чтобы ваши транзакционные письма не отбивались серверами получателей.
— Разница между протоколами извлечения IMAP и POP3.
Годный технический фундамент, чтобы понимать, на каком именно узле отваливаются письма сброса пароля с вашего продакшена: https://tprg.ru/XOao
@prog_stuff
На Tproger вышел перевод с пошаговым разбором того, как почта работает под капотом на уровне инфраструктуры:
— Цепочка доставки: MUA (клиент), MTA (сервер пересылки), MDA (агент доставки).
— Как SMTP ищет маршрут до целевого домена через DNS и MX-записи.
— Подробный разбор SPF, DKIM и DMARC, это база, которую нужно понимать, чтобы ваши транзакционные письма не отбивались серверами получателей.
— Разница между протоколами извлечения IMAP и POP3.
Годный технический фундамент, чтобы понимать, на каком именно узле отваливаются письма сброса пароля с вашего продакшена: https://tprg.ru/XOao
@prog_stuff
Какие доки может распознавать ИИ
Субботнее разглядывательное: у нас на сайте вышла статья про задачи, в которых помогает распознавание документов. Так вот, там уйма наглядных примеров с картинками: какие документы под силу нейросетке, и как это распознавание выглядит. Всех приглашаю к залипанию.
А вы любите разглядывать документы?😏
Субботнее разглядывательное: у нас на сайте вышла статья про задачи, в которых помогает распознавание документов. Так вот, там уйма наглядных примеров с картинками: какие документы под силу нейросетке, и как это распознавание выглядит. Всех приглашаю к залипанию.
А вы любите разглядывать документы?😏
Автор этой статьи прогнал JOIN на таблице из миллиарда строк и проверил, насколько оправдан страх перед этой операцией.
Главный вывод: JOIN сам по себе не дорогой. Дорогими его делают конкретные вещи: отсутствие индексов на join-колонках, выбор SELECT * с широкими строками и неправильный порядок фильтрации.
Тезисы из бенчмарка:
— Правильно проиндексированный JOIN на миллиарде строк отрабатывает быстрее, чем денормализованная «One Big Table» при выборке нескольких колонок.
— OBT начинает выигрывать только когда нужно вытащить почти все колонки широкой строки, но это редкий паттерн.
— Главные виновники медленных JOIN-запросов: отсутствие индексов → full scan, CAST() в условии join → план не использует индекс, агрегация после join вместо до него.
Полезно перечитать, если у вас есть коллега, который денормализует всё подряд «ради производительности».
@prog_stuff
Главный вывод: JOIN сам по себе не дорогой. Дорогими его делают конкретные вещи: отсутствие индексов на join-колонках, выбор SELECT * с широкими строками и неправильный порядок фильтрации.
Тезисы из бенчмарка:
— Правильно проиндексированный JOIN на миллиарде строк отрабатывает быстрее, чем денормализованная «One Big Table» при выборке нескольких колонок.
— OBT начинает выигрывать только когда нужно вытащить почти все колонки широкой строки, но это редкий паттерн.
— Главные виновники медленных JOIN-запросов: отсутствие индексов → full scan, CAST() в условии join → план не использует индекс, агрегация после join вместо до него.
Полезно перечитать, если у вас есть коллега, который денормализует всё подряд «ради производительности».
@prog_stuff
Tproger
SQL JOIN не дорог: бенчмарк на 1 млрд строк в DuckDB и PostgreSQL
Тесты на DuckDB и PostgreSQL показали: JOIN на 1 млрд строк быстрее и дешевле по CPU, чем One Big Table. Смотрите графики и SQL-код бенчмарка.
👍2🤝2👎1
USB устроен как сетевое программирование — только это мало кто объясняет именно так
Endpoint — это порт. Дескриптор устройства — аналог DNS-записи. Хост всегда инициирует соединение, устройство только отвечает. Если вы работали с сокетами, модель USB окажется неожиданно знакомой.
Перевод на Tproger разбирает USB с разработческой точки зрения: четыре типа передачи данных, как читать дескрипторы, и главное — как написать полноценный драйвер в userspace через
В качестве практического примера — Fastboot-клиент на C++ примерно в 50 строк.
Материал стоит отложить: он даёт концептуальную рамку, после которой USB перестаёт быть чёрным ящиком.
Endpoint — это порт. Дескриптор устройства — аналог DNS-записи. Хост всегда инициирует соединение, устройство только отвечает. Если вы работали с сокетами, модель USB окажется неожиданно знакомой.
Перевод на Tproger разбирает USB с разработческой точки зрения: четыре типа передачи данных, как читать дескрипторы, и главное — как написать полноценный драйвер в userspace через
libusb, без единой строки кода ядра.В качестве практического примера — Fastboot-клиент на C++ примерно в 50 строк.
Материал стоит отложить: он даёт концептуальную рамку, после которой USB перестаёт быть чёрным ящиком.
9 нативных API браузера, ради которых обычно зря ставят npm-пакет
Справочник-пособие на случай, когда в следующий раз рука потянется к
Дальше интереснее:
Полезно сохранить и перечитать, когда в следующий раз захочется тянуть в проект uuid, focus-trap или очередной модал.
Справочник-пособие на случай, когда в следующий раз рука потянется к
npm install: разбор девяти вещей, которые браузер уже умеет сам. requestIdleCallback для фоновых задач, :focus-within вместо сорока строк JS на focus и blur, navigator.onLine и события offline/online для PWA, requestAnimationFrame вместо setInterval на 16 мс, container queries для самодостаточных компонентов.Дальше интереснее:
crypto.randomUUID() вместо самописных «достаточно случайных» ID, нативный <dialog> с фокус-трапом и доступностью из коробки, Web Speech API для распознавания речи и @supports для CSS feature detection.Полезно сохранить и перечитать, когда в следующий раз захочется тянуть в проект uuid, focus-trap или очередной модал.
Устали от уймы API-ключей и танцев с бубном вокруг OpenAI, Claude и Gemini?
Снять эту головную боль может один API-роутер.
Разбираемся на Tproger, почему три разных API могут тормозить ваш проект и как подключить GPT-5.4, Claude Sonnet 4.6 и Gemini 3.1 Pro через единую точку входа без переписывания кода.
Кратко о содержании:
— Что умеет хороший роутер: fallback, балансировка, кеш, единый биллинг.
— Пошаговый гайд подключения через одни API на Python и Node.js.
— Реальный кейс: мультимодельный бот с авто-переключением за 30 минут.
— Подводные камни: контекстные окна, latency, rate limits (и как их обойти).
Читать материал: https://tprg.ru/YWhU
Снять эту головную боль может один API-роутер.
Разбираемся на Tproger, почему три разных API могут тормозить ваш проект и как подключить GPT-5.4, Claude Sonnet 4.6 и Gemini 3.1 Pro через единую точку входа без переписывания кода.
Кратко о содержании:
— Что умеет хороший роутер: fallback, балансировка, кеш, единый биллинг.
— Пошаговый гайд подключения через одни API на Python и Node.js.
— Реальный кейс: мультимодельный бот с авто-переключением за 30 минут.
— Подводные камни: контекстные окна, latency, rate limits (и как их обойти).
Читать материал: https://tprg.ru/YWhU
TanStack тихо съедает экосистему React — история про то, как реально меняются экосистемы
Два года назад TanStack означал одно — React Query. Сегодня это восемь взаимосвязанных библиотек: Query, Router, Table, Form, Start, Store, DB и AI. Они постепенно вытесняют Next.js, React Router, Redux, React Hook Form и Zustand — не анонсами и не виральными твитами, а по одной зависимости за раз.
Цифры из State of React 2026 показательны: у TanStack Query 68% использования и 1% негатива, у Next.js — тот же охват, но негатива в 17 раз больше. Причина структурная: библиотеки headless, сквозная типизация идёт от URL до server functions, и вы владеете кодом, а не воюете с фреймворком.
Перевод колонки с dev.to стоит сохранить, даже если вы не пишете на React. Редкий случай, когда видно, как технологический сдвиг идёт снизу — через решения отдельных разработчиков, а не через маркетинг. Полезная оптика, если строите долгосрочный фронтенд-проект.
Два года назад TanStack означал одно — React Query. Сегодня это восемь взаимосвязанных библиотек: Query, Router, Table, Form, Start, Store, DB и AI. Они постепенно вытесняют Next.js, React Router, Redux, React Hook Form и Zustand — не анонсами и не виральными твитами, а по одной зависимости за раз.
Цифры из State of React 2026 показательны: у TanStack Query 68% использования и 1% негатива, у Next.js — тот же охват, но негатива в 17 раз больше. Причина структурная: библиотеки headless, сквозная типизация идёт от URL до server functions, и вы владеете кодом, а не воюете с фреймворком.
Перевод колонки с dev.to стоит сохранить, даже если вы не пишете на React. Редкий случай, когда видно, как технологический сдвиг идёт снизу — через решения отдельных разработчиков, а не через маркетинг. Полезная оптика, если строите долгосрочный фронтенд-проект.