JSON.parse на ответе модели работает ровно до четырёхсотого запроса

Большинство туториалов про вызов языковой модели заканчиваются строчкой JSON.parse(response.content). На первом десятке тестов она работает. Потом модель придумывает дату, возвращает восемь элементов массива там, где по схеме допустимо пять, или отдаёт валидный JSON, в котором тихо не хватает поля.

Автор наткнулся на это, делая инструмент для резюме: на вход приходят двухколоночные PDF, таблицы, которые не совсем таблицы, и даты примерно в четырнадцати форматах, а на выходе нужны строгие поля, потому что их сразу видит человек.

Разбор целиком про слой между «модель вернула текст» и «приложению есть чему доверять»: три способа ограничить вывод, почему схему стоит спроектировать раньше, чем удлинять промпт, и как устроить повторный запрос, который не сожжёт бюджет.

#ии

Разложите по полочкам четыре места, где живёт ваш файл в Git

Git следит за изменениями в проекте, чтобы можно было откатиться назад и увидеть, что именно менялось. Новички обычно заучивают три команды подряд и не понимают, зачем их три, если хватило бы одной.

Смысл в том, что файл проходит четыре места. Рабочий каталог — обычная папка на диске, где вы правите app.py. Область подготовки, она же staging, это витрина: туда вы кладёте только те изменения, которые войдут в следующий коммит, командой git add app.py или git add . для всех сразу. Коммит записывает подготовленное в локальную историю, а git push отправляет её на GitHub.

Проверьте на своём проекте: поправьте два файла, добавьте в staging только один и вызовите git status. Они окажутся в разных списках, и это лучший ответ на вопрос, зачем нужен промежуточный шаг. Разбор с командами.

#основы

В Python шесть предобъявленных констант, и каждая ведёт себя по-своему

True, False, None, __debug__, Ellipsis и NotImplemented. Автор разбирает, чем они отличаются, и различий больше, чем ожидаешь.

Первая тройка это вообще не идентификаторы, а собственные лексические токены: разрешаются в лексере, а не при обычном разрешении имён. Побочный эффект в том, что выражение x.True даёт SyntaxError, и больше в языке так не ведёт себя ничего.

Отдельный случай __debug__: обычный идентификатор, но единственный, которому нельзя присвоить значение, причём даже как атрибуту. При этом x.__debug__ даёт уже AttributeError, потому что синтаксически это законно. Хорошая заметка на вечер, если любите тёмные углы языка.

Что выбрать под неизменяемые объекты: обычный класс или dataclass

Обычный класс порождает изменяемые экземпляры, пока вы явно не запретите менять атрибуты. Отсюда и вопрос, который разбирает автор: где для неизменяемых данных проходит граница между ручным классом и dataclass.

В разборе три части: как сделать неизменяемость на голом классе, что даёт __slots__ для памяти и контроля атрибутов, и что из этого закрывает dataclass(frozen=True) без ручной работы.

Тема из тех, где каждый однажды принимает решение по привычке и живёт с ним годами. Хороший повод пересмотреть привычку на конкретных примерах.

Почему добавленный индекс иногда не ускоряет запрос

«Добавь индекс, и станет быстрее» — фраза, которую слышит каждый новичок. Не обязательно: индекс занимает место на диске, замедляет запись и требует поддержки при каждом изменении данных.

Поэтому проектирование начинается с одного вопроса: какие запросы приложение на самом деле выполняет. Не какие могло бы, а какие реально идут в базу. Разбор сначала объясняет, за счёт чего индекс вообще ускоряет выборку, и только потом переходит к чтению своих запросов.

Возьмите свой учебный проект и выпишите пять самых частых запросов, прежде чем создавать первый индекс. Половина вопросов отпадёт сама.

«Любимый вид спорта» — вопрос из каждой школьной анкеты, и он снова здесь. SpaceWeb исполнилось 25, и вместе с Типичным программистом был выпущен целый спецпроект в этом духе: лучший друг, обои на рабочий стол и другие штуки, а вокруг — аська, скайп, биткоин и другое из 2001–2026 годов.

Между вопросами — история развития веба и самой компании, а в конце — небольшой взгляд в будущее, промокод на услуги SpaceWeb и результат: какой ты носитель информации.

Почему шифровать по-новому советуют сейчас, хотя квантового компьютера ещё нет

Криптография, которая сегодня защищает ваши ключи, HTTPS и подписи, опирается на задачи, которые обычные компьютеры не решают за разумное время. Достаточно большой квантовый компьютер часть из них решит. Постквантовая криптография это алгоритмы, устойчивые и к тем и к другим.

Возражение напрашивается: такого компьютера пока нет, значит, можно подождать. Мешает атака «собери сейчас, расшифруй потом»: противник записывает ваш шифрованный трафик сегодня и лежит с ним, пока не появится возможность его вскрыть.

Отсюда правило, которое стоит запомнить в начале пути: если данные должны остаться тайной через десять лет, угроза уже настоящая, а не будущая. Разбор объясняет это без математики.

Рекурсия становится понятной, если разбирать её на связном списке

Автор честно пишет, что структуры данных на C++ дались ему тяжелее всего за год, и дольше прочего не давалась именно связка связных списков с рекурсией.

Половину сложности объясняет разница с массивом. В массиве всё лежит рядом в памяти, и элемент берётся по индексу. В связном списке каждый узел хранит значение и указатель на следующий: чтобы добраться до пятого, надо пройти через четыре предыдущих.

Именно эта пошаговость и делает список удобным для рекурсии: функция обрабатывает текущий узел и передаёт следующий сама себе. Разбор с кодом стоит сначала повторить на бумаге, а потом уже запускать.

Почему одна модель выдаёт то 45, то 793 токена в секунду

Токены в секунду это универсальный спидометр локальных моделей: цифру приводят в каждом бенчмарке и каждом обзоре видеокарты. И это одно из самых обманчивых чисел в области.

Разброс не опечатка. Та же модель показывает 45 или 793 токена в секунду в зависимости от условий замера, и главный фактор — конкурентность: бенчмарк на одного пользователя и нагрузка на десяток запросов дают принципиально разные числа.

Разбор объясняет, что такое токен, почему число так пляшет и как читать чужой бенчмарк, не обманывая себя. Полезно до того, как выбирать железо по чужим графикам.

ORM, ODM и вебхуки: пять слов из чужого кода, которые пора расшифровать

Как только беретесь за что-то сложнее учебной задачи, в текстах начинают попадаться Drizzle, ORM, ODM, webhook, Clerk и LocalTunnel. Звучат как термины из другой профессии, а на деле за каждым стоит простая мысль.

ORM, например, это прослойка, которая позволяет коду на JavaScript или TypeScript разговаривать с SQL-базой, не выписывая сырой SQL в каждом месте. Drizzle делает именно это. Короткий разбор проходит по всем пяти.

Прочитайте и попробуйте объяснить каждое своими словами вслух за полминуты. Запнулись — значит, поняли не до конца, и это нормальный результат первого захода.

Соберите Discord-бота на Python и заодно разберитесь с асинхронностью

Со стороны бот выглядит сложно: отвечает на сообщения, помнит куски разговора, живёт круглосуточно. На деле это программа на Python, которая подключается к Discord, ждёт событие и решает, как на него ответить.

Как учебный проект он хорош тем, что за одного бота вы трогаете сразу несколько тем: команды, события, асинхронный Python, хранение состояния пользователя, переменные окружения и простейший деплой. Обычно это учат по отдельности и не видят, как оно соединяется.

Туториал начинает с совсем маленького бота и наращивает по одной функции. Каждый шаг можно запустить и увидеть результат, а не ждать финала.

#python

Фильтры GitHub показывают только ваши задачи вместо общей ленты

В живом репозитории висят сотни issue (задач и баг-репортов) и пул-реквестов, то есть предложенных правок кода. Найти глазами то, что назначили именно вам, нереально. У GitHub для этого есть свой язык поиска: is:issue оставляет в списке только задачи, а assignee:@me убирает всё, что закреплено не за вами. Условия пишутся через пробел, порядок не важен.

Откройте github.com/issues, впишите в строку поиска is:issue assignee:@me, потом добавьте is:open и посмотрите, как список сокращается на каждом шаге. Тот же синтаксис работает в поиске по любому репозиторию.

В блоге GitHub из таких фильтров собирают сохранённые вкладки в приложении Copilot: свои задачи, пул-реквесты, которые ждут вашего ревью, и то, что уже закрыто.

#инструменты

Первый запрос к базе можно написать в браузере, ничего не устанавливая

Знакомство с SQL (язык запросов к базам данных) часто застревает на установке: сервер базы, клиент, учебные таблицы. Всё это можно пропустить.

На sql-practice.com база уже загружена и задания написаны: пишете первый SELECT (запрос на выборку строк) и сразу видите таблицу с ответом. Захотите создать свои таблицы и показать результат другому человеку, откройте DB Fiddle. Аккаунт не нужен ни там, ни там.

Один нюанс. Одни тренажёры выполняют запросы внутри браузера, и данные с компьютера никуда не уходят. Другие отправляют всё, что вы вставили, на чужой сервер. Поэтому рабочие данные для тренировки не подходят: берите учебные или выдуманные.

Начните с одного задания на sql-practice.com, а обзор бесплатных песочниц прочитайте потом.

#sql

Карта из 14 шагов: что нужно знать новичку, кроме синтаксиса

Частая ловушка старта — взять популярный язык и пойти по случайным урокам. Синтаксис вроде даётся, но остаётся чувство, что вокруг куча всего, о чём никто не предупредил: терминал, редактор, история изменений кода, устройство интернета.

Роадмап на freeCodeCamp закрывает как раз это: 14 тем, с которыми разработчики имеют дело каждый день — от устройства компьютера и данных до Git, который хранит историю правок в коде. Задача не выучить всё сразу, а узнать, что эти вещи вообще существуют.

Пройдитесь по списку и отметьте пункты, о которых не слышали. Возьмите один и потратьте вечер: посмотрите, что это и зачем нужно. Следующий курс ляжет уже на понятное место.

#основы

Что делать, когда код не работает и непонятно, где он ломается

Первая реакция на ошибку обычно такая: менять строки наугад, пока не заработает. Причину так и не узнаете, а через день баг вернётся.

В гайде freeCodeCamp отладка разложена на шаги. Прочитать текст ошибки целиком: там есть файл и номер строки, с которых начинать. Сузить область: закомментировать кусок кода или вывести значения переменных в консоль, чтобы найти место, где данные становятся не такими, как вы ждали. Объяснить код вслух хоть резиновой утке: часть багов находится на середине фразы.

Когда консоли перестанет хватать, поставьте точку останова в отладчике VS Code или браузера: программа замирает на нужной строке и показывает все переменные.

Возьмите последнюю ошибку, которую чинили наугад, и пройдите по этому порядку. И повторите сценарий, из-за которого баг вылез: иначе почините симптом, а не причину.

#основы

Сообщение об ошибке в Python подсказывает, где сломался код, если читать его с конца

Программа упала, в терминале простыня красного текста, которую хочется закрыть не читая. А имя ошибки и пояснение стоят в последней строке. NameError: переменной с таким именем нигде не создано, обычно опечатка. IndexError: вы просите шестой элемент у списка из пяти. Строки выше показывают файл и номер строки, где всё оборвалось.

Когда имя понятно, а причина нет, ставьте print перед подозрительным местом и сверяйте значения переменных с тем, что ожидали. Если print становится слишком много, включайте встроенный отладчик pdb: он останавливает программу в нужной точке и показывает значения прямо там. Хендбук freeCodeCamp по отладке разбирает имена ошибок подробнее и учит работать с pdb.

Возьмите ошибку, на которой застряли недавно, и разложите её по схеме: имя, пояснение, номер строки.

#python #основы

Как перестать теряться в чужом коде: начните с первой версии Git

Открыть незнакомый репозиторий и закрыть его через минуту — обычное дело: файлов сотни, с какого начинать, непонятно.

freeCodeCamp предлагает тренироваться не на зрелом проекте, а на его ранней версии, и разбирает самый первый вариант Git: десяток файлов на C, написанных в 2005 году. В них уже видно главное: как содержимое файла складывается на диск под именем, которое посчитано из самого содержимого.

Попробуйте повторить: склонируйте репозиторий Git, выполните git log --reverse --oneline | head -1 и найдите самый ранний коммит, а git checkout на него вернёт папку к тому состоянию. Начните с файла read-cache.c и выпишите своими словами, что делает каждая функция. Не знаете C? Всё равно полезно: вы тренируете не язык, а умение распутывать чужой проект по именам функций и порядку вызовов.

#инструменты

Как перестать плодить папки «проект_финал_2» и доверить версии Git

Пока проект маленький, копии папок кажутся нормальным способом ничего не потерять. Через месяц вы уже не помните, в какой из них рабочий вариант.

Git ведёт этот учёт за вас: программа стоит на вашем компьютере и записывает, что и когда изменилось в файлах, поэтому к любой прошлой версии можно вернуться. GitHub работает в интернете: туда те же файлы выкладывают, чтобы была запасная копия и чтобы над проектом работали вдвоём.

Начните с малого: поставьте Git, выполните git init в папке с любым учебным скриптом и сохраните первую версию через git add и git commit. Потом сломайте файл нарочно и верните прошлую версию через git restore: так команды запоминаются быстрее, чем по конспекту.

Руководство freeCodeCamp ведёт дальше: ветки, слияние и что делать, когда правки конфликтуют.

#основы #инструменты

Порядок, в котором стоит учить основы Python, чтобы не застрять на середине

Новичка обычно топит не сложность языка, а разрозненность: переменные из одного урока, циклы из другого, а как из этого собирается программа, непонятно.

Гид freeCodeCamp выкладывает основы в один маршрут: установка Python и редактор, «Hello, World», переменные и типы данных, операторы, условия if/elif/else, циклы for и while, затем break и continue, и только в конце функции.

Читать его подряд бесполезно. После каждого раздела печатайте пример руками, а потом ломайте: поменяйте одно значение и посмотрите, что ответит Python. К разделу про функции у вас накопятся куски кода, из которых собирается маленький скрипт: функция считает, условие выбирает, цикл повторяет.

#python #основы

Проект готов, а пользователей нет: с чего начать, чтобы вашу работу увидели

Знакомая ситуация: учебный сервис дописан, ссылка отправлена в чат, и ничего не происходит. Автор freeCodeCamp в 2022 году собрал маленький сервис в свободное время и позже продал его за несколько тысяч долларов. Его вывод — написать код сегодня дешевле, чем добыть к нему внимание.

Понятный следующий шаг из статьи: разложить путь пользователя на точки касания. Где человек впервые увидел проект, что понял с первого экрана, дошёл ли до регистрации. Дальше подключается аналитика и считаются два числа: доля ушедших с первой страницы и доля дошедших до целевого действия. По ним видно, что чинить: непонятный заголовок или длинную форму.

Нарисуйте эти шаги для своего проекта и отметьте, где теряете человека. В разборе freeCodeCamp дальше идут способы найти первых пользователей без рекламного бюджета.

#инструменты