Точка входа в программирование

Проверьте, успеет ли горутина Go закончить работу

go sayHello() запускает функцию как горутину: она работает одновременно с остальным кодом. Ловушка в main(): когда эта функция завершается, программа закрывается, даже если горутина не успела вывести результат.

Соберите вариант, который ждёт задачу:

package main
import (
    "fmt"
    "sync"
)
func main() {
    var wg sync.WaitGroup
    wg.Add(1)
    go func() {
        defer wg.Done()
        fmt.Println("Готово")
    }()
    wg.Wait()
}

wg.Add(1) задаёт одну ожидаемую задачу, а wg.Wait() не даёт main() закончиться раньше неё.

В примере с двумя задачами показан тот же приём. Запустите код, затем уберите wg.Wait() и сравните несколько запусков.

Перевод HSL в RGB укладывается в четыре строки без единого if

Классическая реализация hslToRgb разбирает шесть секторов цветового круга ветвлениями и отдельно обрабатывает серый. В заметке о самодельном конвертере цветов приводится компактная запись: k(n) = (n + h/30) % 12, амплитуда a = s * min(l, 1-l) и функция f, которую зовут трижды: с 0, 8 и 4. Все три канала считаются одним выражением, а серый выпадает сам: при нулевой насыщенности a = 0, и f возвращает светлоту.

Формула не авторская: то же преобразование приводит образцом спецификация CSS Color 4, так что за краевые значения можно не волноваться. Заметка короткая, остального в ней немного: почему для браузерного инструмента без сборки автор отказался от npm-пакета color и как признаёт, что писал код с плотной помощью ИИ.

Сохраните, если держите свои утилиты для цвета и не хотите тянуть зависимость ради одной математики.

Самодельный принтер показывает, как сеть встречается с памятью устройства

Код становится понятнее, когда ему приходится договариваться с настоящим устройством. В проекте Нишанта Джоши Mac находит Xteink X3 через Bonjour: устройство публикует имя, поддерживаемые форматы и адрес для заданий. Затем протокол интернет-печати IPP позволяет компьютеру спросить о возможностях и отправить документ по веб-протоколу HTTP.

Затем код упирается в память. Страница Letter при 300 точках на дюйм занимает около 8,4 МБ без сжатия, а у X3 всего 400 КБ оперативной памяти. Целиком она туда не помещается.

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

Три правила Rust объясняют, кто отвечает за память

Сборщик мусора периодически освобождает ненужную программе память. Rust работает иначе: компилятор проверяет правила работы с памятью до запуска.

У каждого значения один владелец. Когда код больше не может обратиться к нему, Rust освобождает память. Значение можно одолжить по ссылке, то есть использовать, не забирая владение: либо многим для чтения, либо одному для изменения. Смешивать варианты нельзя, что предотвращает гонки данных.

Срок жизни показывает, как долго ссылка допустима; часто Rust определяет его сам. Так ссылка не укажет на освобождённую память.

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

Перемещение в C++ не отменяет уничтожение исходного объекта

Когда std::vector создаёт новый элемент из std::move(s), исходный s остаётся в своей области видимости. При выходе из неё C++ всё равно вызывает деструктор: специальную функцию, которая срабатывает при уничтожении объекта. Если внутри есть системный вызов или удаление записи из общего реестра, даже перемещённый объект может выполнить лишнюю работу.

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

В разборе с исходным кодом повторите пример со std::vector сначала без ManualDrop, затем с ним. Сравните вывод конструкторов и деструкторов. Используйте приём только там, где значение гарантированно будет перемещено из своей области видимости.

Сократите простые функции и сразу увидите их результат

Если функция принимает значения, вычисляет одно выражение и сразу возвращает результат, её можно записать короче, стрелкой =>. Вместо блока с function и return получится одна строка:

let sum = (a, b) => a + b;

Здесь a и b — параметры функции. При вызове sum(1, 2) выражение справа вычислится, а функция вернёт 3. Для одного параметра скобки можно убрать: let double = n => n * 2;. Если параметров нет, пустые скобки остаются: () => alert("Hello!").

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

Две задачи в Copilot можно запускать параллельно без путаницы в коде

Если вы учитесь работать с ИИ-помощником, возьмите две независимые задачи: в одной попросите добавить сортировку, в другой запустить тесты. Так проще увидеть вклад каждого агента и проверить результат по частям.

В приложении GitHub Copilot сессия хранит одну задачу от начала до конца и помнит её условия. Для неё можно создать Git worktree: отдельное место, где агент меняет проект, не задевая другие сессии. Задачи идут одновременно, а переключаться между ними можно без повторных объяснений.

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

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

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

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

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

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

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

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

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

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

#python #основы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#python #основы

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

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

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

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

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

#основы

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

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

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

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

#основы

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

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

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

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

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

#sql

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

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

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

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

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

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

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

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

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

#python

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

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

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

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

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

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

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

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

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

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

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

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