Автор размышляет о своем пути с CSS, изначально приняв Tailwind за его структуру, но теперь переходит на ванильный CSS. Это изменение было вызвано желанием глубже понять CSS и улучшить свои навыки. Автор подробно описывает новую структуру CSS, включая импортированный сброс, компонентный стиль, предопределенные цветовые переменные и систему размеров шрифтов, адаптированную из Tailwind. Они также используют служебные классы, создают основу для глобальных стилей и сознательно управляют отступами. Адаптивный дизайн больше полагается на CSS-сетки, отходя от подхода Tailwind, ориентированного на медиа-запросы. Система сборки использует esbuild для производственной сборки, хотя это и не обязательно во время разработки. Автор излагает основные причины миграции, ссылаясь на зависимость от системы сборки, улучшение знаний CSS, ограничения Tailwind и стремление к более семантичному HTML. В заключение они обсуждают такие функции, как @layer, и признают преимущества Tailwind, по-прежнему находя ценность в его принципах.

Автор перестал использовать Tailwind, но скучал по его удобным цветовым палитрам. Они искали альтернативы цветовой системе Tailwind, чтобы улучшить свой рабочий процесс. Им были нужны предопределенные цветовые палитры, особенно для простоты использования в CSS. Автор попросил предложить палитры на Mastodon и решил собрать ответы. В посте перечислены несколько цветовых палитр, таких как uchū, flexoki и reasonable colours. Также предлагаются различные другие палитры и системы дизайна в качестве вариантов для рассмотрения. Представлен ряд генераторов цветовых схем, хотя автор считает их сложными в использовании. Дополнительные цветовые инструменты, включая информацию о дальтонизме и функцию oklch CSS, также представлены. Автор надеется, что этот ресурс будет полезен им самим и другим, ищущим решения для цветов в CSS.

Автор стремится писать фронтенд на JavaScript, не полагаясь на Node.js. Серьезной проблемой стало отсутствие эффективных методов тестирования фронтенд-кода. Предыдущие попытки с Playwright были признаны медленными и требовали Node.js. Для решения этой проблемы автор изучил возможность запуска тестов непосредственно во вкладке браузера, вдохновившись работой Алекса Чана над минималистичным фреймворком для юнит-тестирования в браузере. Хотя подход Чана был сосредоточен на юнит-тестах, автор стремился проводить сквозные интеграционные тесты для Vue-компонентов без процесса сборки Node.js. Автор использовал QUnit в качестве фреймворка для тестирования, оценив его кнопку "повторить тест" для отладки. Процесс включал настройку Vue-компонентов путем их глобального экспорта и создание функции `mountComponent` для их рендеринга в невидимом, скрытом от страницы div. Данные для тестов управлялись путем сброса базы данных посредством POST-запроса на выделенный конечный пункт. Базовый тест затем рендерил компонент и проверял его содержимое. Основные возникшие проблемы включали ожидание завершения асинхронных операций, что привело к разработке функции `waitFor()`. Определение правильного элемента или условия для ожидания оказалось сложным, что вызвало предложения по рефакторингу приложения для повышения надежности. Автор также экспериментировал с добавлением CSS-классов для идентификации элементов, отмечая, что библиотеки, такие как Testing Library, рекомендуют более доступные подходы. Обработка форм представляла трудности, поскольку простое присвоение значений было недостаточным; требовалось вызывать соответствующие DOM-события. Это подчеркнуло, почему библиотеки для тестирования пользовательского интерфейса могут упростить такие задачи. Покрытие тестами было частично оценено с помощью встроенных инструментов разработчика Chrome, хотя процесс требовал специфических настроек и действий для работы с бандлированным JavaScript. Несмотря на кривую обучения, автор нашел этот опыт приятным и выразил оптимизм по поводу создания надежного набора тестов для своих фронтенд-проектов. Они также рассматривают дальнейшее изучение библиотек, таких как Testing Library, которая предлагает UMD-сборку, совместимую с выполнением только в браузере, и размышляют о том, как интегрировать тесты, ориентированные на браузер, в CI-среды.

Автор был вдохновлен полезностью примеров в man-страницах и улучшил их для инструментов dig и tcpdump. Основная цель заключалась в предоставлении наиболее базовых примеров для редких пользователей или новичков. Такой подход, ориентированный на новичков и редких пользователей, оказался эффективным и хорошо принятым. Автор счел процесс рецензирования ценным, что привело к более точной информации, которую можно найти в man-страницах. Они узнали о полезных функциях tcpdump, таких как флаг `-v` при сохранении пакетов. Несмотря на общий скептицизм по отношению к документации, автор теперь оптимистично смотрит на потенциал высококачественных, точных man-страниц. Чтобы избежать изучения roff, для обновлений man-страницы tcpdump был создан пользовательский скрипт для преобразования markdown в roff. Это включало разбор абстрактного синтаксического дерева Markdown и генерацию кода roff. Автор также исследовал историю и эволюцию roff и проекта mandoc. Возникло любопытство относительно технических и культурных различий в практике документирования между системами BSD и Linux.

Автор размышляет об улучшении страниц справки, побуждаемый трудностями поиска информации в них. Он рассматривает возможность включения листов быстрого доступа, как те, что встречаются в `perlcheat`, для быстрого справочного материала. Вдохновленный примерами из страниц справки `rsync` и `strace`, он предлагает сводки опций и организацию на основе категорий. Автор подчеркивает популярность примеров, ссылаясь на подход OpenBSD и стратегию примера на опцию в странице справки `curl`. Он также подчеркивает ценность форматов таблиц, как видно в `man ascii`, для более легкого просмотра информации. Автор противопоставляет использование проектом GNU "информационных" руководств страницам справки, отмечая ограничения терминальных страниц справки. Он обсуждает инструменты, такие как `tldr.sh` и Dash, и размышляет о том, как улучшить страницы справки в рамках их ограниченного формата. Он особенно ценит примеры, но открыт для других улучшений дизайна.

Автор любит изучать зрелые технологии и недавно начал использовать Django для веб-проекта. Четкая структура Django с ключевыми файлами, такими как `urls.py` и `models.py`, помогает автору легко понять проект. Встроенный интерфейс администратора Django обеспечивает простое управление данными, а ORM упрощает взаимодействие с базами данных, а автоматические миграции оптимизируют изменения в базе данных. Автор ценит документацию Django и предпочитает использовать SQLite для небольших проектов из-за ее простоты. Подход Django "все включено" упрощает такие задачи, как защита от CSRF и настройка электронной почты. Автор все еще учится, но считает набор функций Django привлекательным. Файл настроек остается несколько пугающим из-за его глобального характера и отсутствия немедленного обнаружения опечаток. Автор экспериментирует с настройкой электронной почты, используя различные бэкенды. Автор рад изучать Django, поскольку в основном работал с отдельными бинарными файлами Go или статическими сайтами. Автор благодарит Марко Роджерса за поощрение использования ORM.

Автор решил улучшить документацию Git после написания постов в блоге и зинов. Они сотрудничали с Мари для создания документа "модели данных", объясняющего основные концепции Git, такие как объекты, ссылки и индекс. Автор обновил введения к нескольким man-страницам Git, таким как `git push` и `git pull`. Они поняли, что для выявления проблем в документации необходим более доказательный подход. Автор попросил тестовых читателей в Mastodon предоставить отзывы о существующей документации. Тестовые читатели выявили запутанную терминологию, неясные предложения и несоответствия в документации. Эта обратная связь помогла автору улучшить man-страницы для `git add`, `git checkout`, `git push` и `git pull`. Автор посчитал изменения для `git push` и `git pull` наиболее интересными, включая определения для "upstream branch" (вышестоящая ветка) и "push refspec" (спецификация ссылки для отправки). Участие в разработке Git включало изучение процесса разработки, в том числе использование сервера Discord и GitGitGadget. Они нашли сообщество Git гостеприимным и получили помощь от многих участников. Автор также создал пользовательскую программу просмотра списков Git для навигации по архивам рассылок.

Автор перешел с Vim/Neovim на Helix, текстовый редактор, привлеченный простотой интеграции языковых серверов. После многих лет борьбы со сложными конфигурациями Vim, встроенные функции Helix оказались привлекательными. Функции поиска и быстрого доступа в Helix особенно полезны и ценны. Автор легко адаптировался к сочетаниям клавиш Helix, хотя некоторые привычки Vim требовали корректировки. Автор нашел, что множественные курсоры и переключение буферов в Helix предпочтительнее макросов и вкладок Vim. Однако автор отмечает некоторые неудобства, включая проблемы с переносом списков и отсутствие постоянной отмены и автоперезагрузки. Несмотря на эти трудности, автор адаптировался к Helix, находя переход проще, чем ожидалось. Простая конфигурация редактора является значительным преимуществом по сравнению со сложностью предыдущей настройки. Автор в основном использует Helix в терминале, организуя проекты с помощью выделенных окон. Автор доволен Helix после трех месяцев использования, но остается открытым к возможному возвращению к Vim.

Автор выпустил новый зиин под названием "Секретные правила терминала", который объясняет, как работает терминал, и содержит советы и хитрости по использованию программ терминала. Автор ежедневно использует терминал в течение 20 лет, но все еще имел много заблуждений о том, как он работает. Терминал имеет множество мелких несоответствий, например, иногда позволяет использовать клавиши со стрелками для перемещения, а иногда нет. "Правила" работы терминала трудно понять, потому что он состоит из множества различных программных компонентов. Зиин объясняет, как четыре компонента терминала (оболочка, эмулятор терминала, программы и драйвер TTY) взаимодействуют между собой, и предоставляет основные соглашения о том, как все работает в терминале. Автор узнал удивительно много во время написания зиина, включая то, как настроить свою оболочку и понять управляющие последовательности. Зиин доступен для покупки в формате PDF или печатной версии, а также предлагается упаковка из 15 зиинов автора. Автору помогали многие люди, в том числе технический рецензент, написавший PuTTY, и человек, разбирающийся во внутренних механизмах работы терминала. Печатная версия будет отправлена в августе, и автору придется подождать поступления заказов, чтобы определить тираж. Зиин доступен за 12 долларов, и автор надеется, что он поможет читателям лучше понять и использовать терминал.

Автор не является программистом на языке C, но периодически ему нужно компилировать программы на языке C/C++ из исходного кода. Раньше он полагался на других для компиляции, но после перехода на Mac ему пришлось научиться компилировать программы самостоятельно. Для компиляции программы на языке C необходимо установить компилятор C, установить зависимости программы, запустить ./configure, если необходимо, и запустить make. Автор объясняет, как установить компилятор C, установить зависимости и запустить ./configure. Он также обсуждает общие проблемы, которые могут возникнуть во время компиляции, такие как проблемы зависимостей и ошибки компилятора. Автор объясняет, как исправить эти проблемы, передавая флаги компилятору и линковщику. Он также дает советы о том, как построить конкретные файлы, посмотреть, как другие системы пакетирования построили тот же C, и установить бинарный файл. Автор заключает, что понимание основ работы программ на языке C может быть полезным, даже если вы не являетесь программистом на языке C.

Коды ANSI-последовательностей используются для повышения удобства работы с терминалом, но они не полностью стандартизированы, что приводит к проблемам надёжности. Автор узнал о кодах ANSI-последовательностей во время изучения работы терминала и захотел понять стандарты, которые их регулируют. Коды последовательностей используются эмуляторами терминала для связи с программами и бывают двух типов: входные коды для нажатий клавиш и движений мыши, а также выходные коды для таких задач, как изменение цвета текста и перемещение курсора. Стандарт ECMA-48, опубликованный в 1976 году, определяет общие форматы кодов последовательностей и некоторые конкретные коды, но он не является исчерпывающим. Последовательности управления Xterm — это другой набор кодов последовательностей, широко внедрённый эмуляторами терминалов, хотя они и не являются формальным стандартом. База данных terminfo, управляемая ncurses, хранит коды последовательностей для различных терминалов, и некоторые программы используют её для определения того, какие коды следует использовать. Однако некоторые программы предпочитают не использовать terminfo и вместо этого жёстко кодируют «единый общий набор» кодов последовательностей, работающих в большинстве эмуляторов терминалов. Нет чёткого соглашения относительно того, что представляет собой этот общий набор, но, вероятно, он включает коды из VT100, ECMA-48 и xterm. Несмотря на трудности, стандартизация кодов ANSI-последовательностей может привести к более богатому опыту работы с терминалом, и автор надеется, что более чёткий ландшафт стандартов мог бы способствовать инновациям в эмуляторах терминалов и приложениях.

Чтобы добавить каталог в переменную PATH, сначала необходимо определить, какой shell вы используете. Это можно сделать, запустив команду `ps -p $$ -o pid,comm=`. По умолчанию shell в Linux - bash, а в Mac OS - zsh. Далее необходимо найти файл конфигурации вашего shell, который обычно находится в следующих местах: ~/.zshrc для zsh, ~/.bashrc для bash и ~/.config/fish/config.fish для fish. Однако файл конфигурации bash может быть одним из трех вариантов: ~/.bashrc, ~/.bash_profile или ~/.profile, и вам может потребоваться проверить, какой из них используется. После нахождения файла конфигурации вашего shell необходимо определить, какой каталог добавить в переменную PATH. Это можно сделать, проверив инструкции по установке программы, которую вы пытаетесь запустить, или используя команду, специфичную для инсталлятора, например, `npm config get prefix` для Node/npm. После того, как вы нашли правильный каталог, необходимо дважды проверить, что он правильный, попробовав запустить программу из этого каталога. Затем необходимо отредактировать файл конфигурации вашего shell, чтобы добавить каталог в переменную PATH. Синтаксис для этого различается в зависимости от shell: bash и zsh используют `export PATH=$PATH:~/directory`, а fish - `set PATH $PATH ~/directory`. Наконец, необходимо перезапустить shell, чтобы изменения вступили в силу. Если программа все еще не работает, вам может потребоваться добавить каталог в начало переменной PATH вместо конца, или вам может потребоваться добавить каталог в переменную PATH другим способом, если вы запускаете программу из IDE или cron-задания. Кроме того, некоторые инсталляторы могут предоставлять скрипт для автоматической настройки переменной PATH, который можно запустить, добавив строку в файл конфигурации вашего shell. Однако вы можете предпочесть добавить каталог в переменную PATH вручную.

Был проведен опрос для сбора информации о самых раздражающих вещах при использовании терминала, на который ответили 1600 человек. Респонденты в основном были опытными пользователями, из которых 40% использовали терминал более 21 года, а 95% - не менее 4 лет. К основным категориям раздражений относились: запоминание синтаксиса, переключение терминалов, проблемы с цветами, клавиатурные сокращения и проблемы с копированием и вставкой. Другими распространенными раздражениями были: обнаружение функций, крутая кривая обучения, история, плохая документация и проблемы со скроллингом. Некоторые пользователи также упоминали, что чувствуют себя неуютно или боятся при использовании терминала, а другие имели проблемы со скриптами shell, несовместимыми аргументами командной строки и производительностью. Опрос также показал, что многие пользователи испытывают трудности с синхронизацией точечных файлов на разных системах и управлением окнами с помощью вкладок tmux и вкладок терминала. Некоторые пользователи упоминали, что чувствуют себя перегруженными возможностями терминала и хотели бы получить более упрощенный опыт. Результаты опроса будут использованы для создания зины о терминале. В целом, опрос подчеркивает сложности и проблемы использования терминала, даже для опытных пользователей.

Автор размышляет о том, что составляет «современный» опыт работы с терминалом, включая такие функции, как многострочный копипаст, бесконечная история команд и поддержка 24-битного цвета. Он признаёт, что достижение такого опыта может быть сложным из-за множества вовлечённых компонентов, включая оболочку, эмулятор терминала и текстовый редактор. Личный подход автора к созданию современного терминала включает использование оболочки fish, эмулятора терминала с поддержкой 24-битного цвета и neovim с пользовательской конфигурацией. Тем, кто не хочет тратить много времени на настройку, автор предлагает использовать fish или zsh с oh-my-zsh, эмулятор терминала с поддержкой 24-битного цвета и текстовый редактор, например, micro или helix. Однако автор отмечает, что даже с этими вариантами получение современного опыта работы с терминалом может быть сложным из-за проблем с оболочкой, текстовым редактором и отдельными приложениями. Оболочка может быть особенно проблематичной, поскольку популярные оболочки, такие как bash и zsh, требуют настройки для обеспечения удовлетворительного опыта. Текстовый редактор также может быть проблемой: такие варианты, как vim и emacs, требуют значительной конфигурации, а nano предоставляет ограниченные возможности. Автор отмечает, что отдельные приложения также могут вызывать проблемы, и что отладка этих проблем может занимать много времени. В конечном итоге, автор заключает, что достижение современного опыта работы с терминалом требует терпения, экспериментов и готовности вносить небольшие изменения и адаптироваться к новым инструментам и конфигурациям.

Программы в терминале ведут себя последовательно, несмотря на отсутствие стандартов. Они следуют определённым правилам, таким как завершение работы неинтерактивных программ при нажатии Ctrl-C, завершение работы TUI при нажатии 'q' и завершение работы REPL при нажатии Ctrl-D на пустой строке. Большинство программ поддерживают ключевые привязки readline, отключают цвета при записи в конвейер и используют '-' для обозначения stdin/stdout. Эти правила носят описательный, а не предписывающий характер, и понимание их помогает эффективно использовать программы в терминале.

Буферизация является обычным явлением в терминальных программах для улучшения производительности путем группировки вывода до достижения определенного порогового размера. Это может вызвать проблемы, когда данные добавляются медленно в конвейер, поскольку программы могут буферизовать свой вывод и никогда не записывать его. Grep и подобные программы по умолчанию используют блоковую буферизацию при записи в конвейеры, но используют строковую буферизацию при записи в терминалы, что объясняет, почему команда "tail -f /some/log/file | grep thing1 | grep thing2" может не отображать вывод. Несколько команд буферизуют свой вывод, включая grep, sed, awk, tcpdump и jq, в то время как команды, такие как tail, cat и tee, не делают этого. Языки программирования, такие как C, Python, Ruby и Perl, также могут буферизовать вывод, с различными методами для отключения буферизации. Когда нажимается Ctrl-C на конвейере, вывод программы может быть потерян, поскольку сигнал получен до того, как буфер может быть сброшен. Буферизация также происходит при перенаправлении в файл, но обычно она ведет себя, как ожидается, с содержимым буфера, записанным перед выходом программы. Чтобы избежать буферизации, можно запустить программу, которая быстро завершается, использовать флаг "--line-buffered" с grep, переписать команду с помощью awk, использовать stdbuf или использовать unbuffer, чтобы заставить программу вести себя так, как если бы она писала в терминал. Идеальное решение зависит от конкретной ситуации, с unbuffer, как надежным выбором для его последовательного поведения. Хотя буферизация обычно не является обычной проблемой, она может возникнуть, когда данные медленно добавляются в конвейер. Переменная окружения для отключения буферизации была бы полезна, но ее проектирование и реализация представляют собой сложные задачи.

Автор предпочитает писать JavaScript без системы сборки и делится своим опытом импортирования библиотек без использования системы сборки. Он объясняет три основных типа файлов JavaScript, которые может предоставить библиотека: файлы "классических" глобальных переменных, модули ES и модули CommonJS. Автор демонстрирует, как найти файлы в сборке NPM библиотеки и обсуждает использование importmaps для использования модулей ES в браузере. Он также упоминает использование esm.sh для преобразования модулей CommonJS в модули ES. Автор предоставляет примеры использования Chart.js, @atcute/oauth-browser-client и @atproto/oauth-client-browser, обсуждая различные подходы для каждого из них. Он отмечает, что использование importmaps требует поддержки браузера, что может быть проблемой для старых браузеров. Автор также упоминает использование esbuild в качестве альтернативы importmaps. Наконец, он кратко излагает три типа файлов JavaScript и как их определить и использовать.

Автор создал на своем сайте новый раздел под названием «TIL» (сегодня я узнал), чтобы сохранять интересные инструменты и факты, которые он публикует в социальных сетях. Цель этого раздела — создать место для хранения этой информации без необходимости писать полноценную запись в блоге. Автор часто публикует «крутые вещи» в Mastodon и Bluesky, но у него не было места, где он мог бы их отслеживать. Этот новый раздел вдохновлен блогом TIL Саймона Уиллисона, но записи автора гораздо короче. Автор создал новую папку для раздела TIL, добавил пользовательский стиль и настроил отдельный канал RSS. Раздел TIL предназначен в основном для личного использования автора как способ отслеживания полезных ссылок и инструментов. Автор использует этот раздел уже пару недель и обнаружил, что он хорошо работает. Автор является поклонником идеи «POSSE» (публикуй на своем собственном сайте, синдицируй в другом месте), но ему проще выделять отдельные категории контента, которые он хочет сохранить на своем собственном сайте. У автора есть списки электронной почты и каналы RSS для записей в блогах и комиксов, и он может добавить в свой список рассылки сводку записей TIL. Автор предпочитает сохранять некоторое содержимое временным, например опросы и шутки, и архивировать только отдельные категории контента.

Автор исследует концепцию управляющих кодов в терминале, таких как Ctrl-A, Ctrl-C и Ctrl-W, и то, как они работают. Существует 33 управляющих символа ASCII, которые можно разделить на категории: коды, обрабатываемые драйвером терминала операционной системы, коды, соответствующие буквальным нажатиям клавиш, и коды, используемые readline. Автор отмечает, что нет реальной структуры, которая определяет, какие коды входят в какие категории, поскольку они развились органически. Всего существует только 33 управляющих кода, что означает, что если вы хотите использовать Ctrl-1 в качестве клавиатурной комбинации, это не имеет смысла, поскольку это то же самое, что нажать клавишу 1. Автор также отмечает, что Ctrl+Shift+C не является управляющим кодом, и его поведение зависит от эмулятора терминала. Официальные имена управляющих кодов ASCII не очень полезны, поскольку они были первоначально определены для телеграфных машин и с тех пор были переопределены. Автору трудно использовать Ctrl-M и Ctrl-I в качестве клавиатурных комбинаций, поскольку они эквивалентны клавишам Enter и Tab соответственно. Автор предоставляет скрипт на Python для определения, какие управляющие коды отправляются при нажатии различных комбинаций клавиш. Автор отмечает, что некоторые управляющие коды, такие как Ctrl-W и Ctrl-U, могут обрабатываться по-разному в зависимости от того, находится ли терминал в каноническом или неканоническом режиме. Наконец, автор признает, что существует множество ограничений и конфликтов, связанных с управляющими кодами, и что не вся эта информация обязательно полезна на практике.

Автор программы Mess With DNS столкнулся с проблемой, когда программа вышла за пределы доступной памяти и была завершена из-за нехватки оперативной памяти, что привело к проблемам с резервным скриптом. Чтобы решить эту проблему, автор решил попробовать уменьшить потребление памяти программой. Программа загружает базу данных IP-адресов в память, что занимало примерно 117 МБ памяти. Автор попробовал три разных подхода для уменьшения потребления памяти. Первый подход заключался в использовании SQLite для хранения данных на диске, что решило первоначальную проблему с памятью, но имело проблемы с хранением IPv6-адресов и был в 500 раз медленнее, чем исходный бинарный поиск. Второй подход заключался в использовании trie, но он использовал больше памяти и был медленнее, чем исходный бинарный поиск. Третий подход заключался в том, чтобы заставить массив использовать меньше памяти, удалив дубликаты полей Name и Country, что снизило потребление памяти с 117 МБ до 65 МБ, а затем переключение на netip.Addr вместо net.IP, что сэкономило еще 20 МБ памяти, в результате чего общий объем составил 46 МБ. Автор смог сэкономить 70 МБ памяти в общей сложности.

Автор записи в блоге решил обновить свою версию Hugo с 0.40 до 0.135, несмотря на то, что старая версия работала нормально. Он задокументировал изменения, которые ему пришлось сделать во время процесса обновления, в том числе замену вызовов шаблонов, обновление ссылок на страницы и изменение значения "следующий" и "предыдущий" в своей теме. Автор также должен был обновить свои файлы Markdown, чтобы они работали с новым рендерером Goldmark, который заменил старый рендерер Blackfriday. Это потребовало изменения способа написания Markdown, включая смешение HTML и Markdown, использование угловых кавычек и отступы вложенных списков. Автор также должен был настроить рендерер Goldmark, чтобы отключить подсветку кода и использовать старый метод для генерации идентификаторов заголовков. Он написал скрипт для сравнения вывода рендереров Blackfriday и Goldmark и использовал его для выявления и исправления проблем с своими файлами Markdown. Автор отмечает, что процесс обновления был трудоемким и не без своих проблем, но в конечном итоге считает, что это было стоило того, чтобы иметь более будущепroof рендерер Markdown. Он также упоминает, что, скорее всего, ему придется сделать аналогичные изменения при обновлении своего другого сайта, wizardzines.com, который все еще использует более старую версию Hugo.

Вчера я размышлял о том, сколько времени мне потребовалось, чтобы найти цветовую схему терминала, которая мне в основном нравится. Я спросил людей в Mastodon о проблемах с цветами терминала и получил много интересных ответов. Одной из распространенных жалоб было то, что "синий на черном" трудно читать. Я использую модифицированную тему Solarized для своего терминала, которой я очень доволен. Некоторые новые инструменты, такие как fd и bat, поддерживают темы, что может помочь с проблемами контраста. Я также упомянул функцию "минимального контраста" в некоторых терминалах, которая автоматически регулирует цвета для лучшего контраста. Другие проблемы включают неправильную установку TERM, выбор "хороших" цветов, настройку nethack/mc для правильного отображения, отключение цветов командами при записи в конвейер, нежелательные цвета в ls и других командах, а также цвета в vim.

Автор делится своими опытом работы над веб-сайтом на языке Go, обсуждая различные инструменты и техники, которые он изучил по ходу дела. Он упоминает использование sqlc для генерации кода Go из запросов SQL, что упрощает процесс взаимодействия с базами данных. Автор также высоко оценивает встроенный веб-сервер и инструментарий Go, а также его системно-ориентированную природу, которая делает легким выполнение низкоуровневых операций, таких как запуск ioctl. Он сравнивает свой опыт работы с Go с опытом работы с Rails, отмечая, что хотя Rails feels magical, но его труднее вернуться к нему после перерыва. Автор также подчеркивает новые функции в Go, такие как установка ограничения памяти для сборщика мусора и улучшенная поддержка маршрутизации в стандартной библиотеке.

Fish - это популярная оболочка, предлагающая улучшенный пользовательский опыт благодаря нескольким ключевым функциям. Среди них есть автоматические подсказки истории, умная автозаполняемость, легкое вставление многострочных команд, пользовательский интерфейс для завершения вкладок и хорошо спроектированный по умолчанию приглашение с интеграцией Git. Кроме того, Fish имеет полноценную систему истории с функцией поиска и избегает повреждения терминала из-за случайного отправления двоичных данных. Она отключает потенциально разрушающую комбинацию клавиш Ctrl+S, предоставляет глобальную утилиту для изменения пути и имеет подсветку синтаксиса для несуществующих команд. Кроме того, Fish предлагает упрощенный синтаксис цикла, легче редактировать многострочные тексты и удобные сочетания клавиш Ctrl+стрелка влево/вправо для навигации по словам. Хотя могут быть ограничены инструкции по интеграции некоторых инструментов с Fish, она стала более общепринятой, и пользователи могут вернуться к POSIX-оболочкам, когда это необходимо. Fish особенно подходит тем, кто ценит минималистичную конфигурацию, appreciates ее настройки по умолчанию и хочет оболочку с интуитивным и функциональным дизайном.

Месс Витх DNS - это платформа для изучения функциональности DNS, позволяющая создавать и редактировать записи. Оригинальная реализация DNS имела ограничения, включая запрещенные доменные имена с подчеркиваниями, отсутствие поддержки записи CNAME, и отсутствие типов записей SVCB и HTTPS. Чтобы решить эти проблемы, автор интегрировал PowerDNS, открытый исходный сервер DNS с HTTP API, заменив предыдущую реализацию DNS. Это привело к трудностям в перехвате запросов DNS и проектировании API, соответствующего потребностям frontend. Для обработки ошибок автор настроил пользовательские сообщения об ошибках, чтобы обеспечить более четкую информацию, обрабатывая ответы ошибок API PowerDNS и проводя основную валидацию ввода. SQLite заменил Postgres для управления базами данных из-за OOM kills, возникающих с Postgres. Библиотека Vue.js была обновлена до версии 3, что сопровождалось переходом к использованию встроенных в браузер инструментов валидации форм и реализацией глобального хранилища состояния для управления frontend. Проект был разделен на фазы для управляемой реализации, включая обновление Vue, создание хранилища состояния, переработку бэкэнд API и интеграцию PowerDNS. Обновленный веб-сайт уже вышел и работает хорошо, решив прежние DNS-проблемы, сообщенные пользователями.

Автор, случайный программист на Go, столкнулся с ошибкой, которая выявила фундаментальное недопонимание того, как структуры копируются при присваивании в Go. Это недопонимание возникло из-за того, что структуры копируются при присваивании, а не передаются по ссылке, что привело к неожиданному поведению при изменении структуры после ее присваивания другой переменной. Автор был удивлен этим поведением, поскольку его опыт работы с другими языками привел к убеждению, что переменные передаются по ссылке. Это заблуждение было еще больше усложнено автором пониманием передачи по значению и передачи по ссылке в аргументах функций, которое он не распространил на присваивание переменным. Кроме того, автор узнал, что под-slice в Go разделяют одну и ту же основную массивную строку с оригинальным slice, что означает, что добавление к под-slice может непреднамеренно изменять оригинал. Кроме того, автор получил ясность в разнице между приемниками значения и указателями в методах Go, поняв, что приемники указателей необходимы, когда метод должен изменять структуру, на которой он вызван. Автор похвалил ресурс "100 ошибок Go" за его ясный и лаконичный формат, который позволил ему быстро найти и узнать из общих ловушек Go. Наконец, автор перечислил другие ценные ресурсы Go, включая "Go по примерам", "go.dev/play" и статические инструменты анализа, такие как "staticcheck" и "golangci-lint."

Ввод текста в терминале может быть сложным из-за несовместимостей между программами. Базовые функции, такие как клавиши-стрелки, могут не поддерживаться. Readline, библиотека, которая обеспечивает возможности редактирования текста, широко используется и поддерживает разные сочетания клавиш. Программы без поддержки readline могут быть улучшены с помощью rlwrap. Некоторые программы используют собственные системы ввода, которые имитируют readline или предоставляют дополнительные функции. Понимание используемой системы ввода позволяет увеличения предсказуемости. Общие сочетания клавиш включают Ctrl+A для начала строки, Ctrl+E для конца и Ctrl+R для поиска в истории. Многие оболочки поддерживают привязки клавиш vi как альтернативный режим ввода. Диагностика системы ввода (нет системы ввода, readline или custom) позволяет настроить использование доступных функций. Однако есть дополнительные сложности, связанные с вводом текста в терминале, которые не охвачены в этом резюме.

Управление заданиями - это функция в вашем терминале, которая позволяет управлять процессами, перемещая их между тремя состояниями: передний план, фоновый режим и остановка. Она включает команды, такие как fg, bg, Ctrl+z, jobs, kill, disown и wait. Fish, bash и zsh все поддерживают управление заданиями, но оно может использоваться по-разному в каждом терминале. Некоторые люди предпочитают управление заданиями вместо использования вкладок терминала, потому что им нравится видеть все свои терминалы на экране одновременно. Оно может быть полезным для убийства процессов, которые не реагируют на Ctrl+C, запуска GUI-приложений или ресурсоемких программ в фоновом режиме и для настройки переменных окружения для нескольких команд. Управление заданиями также может быть необходимо в ситуациях, когда вы находитесь в однопользовательском режиме или подключены по SSH к машине без tmux или screen.

"Как работает Git" - это новый комикс Джулии Эванс, который стремится развеять мифы вокруг Git, популярной системы управления версиями. Комикс адресован пользователям, имеющим годы опыта работы с Git, но все еще страдающим от него, с целью прояснить распространенные заблуждения и дать более глубокое понимание его внутренней логики. Эванс признает запутанный характер терминологии Git, сообщений об ошибках и нестабильного поведения, но подчеркивает, что преодоление этих сложностей становится привычным с опытом. Комикс фокусируется на поведении пользовательского интерфейса и том, как оно связано с внутренними процессами Git, избегая чрезмерного внимания к внутренним работам. В него также включены печатный чит-шит и HTML-транскрипт для доступности. Несмотря на подчеркивание сложностей Git, Эванс остается энтузиастом этого инструмента, ценя его скорость, обратную совместимость и доступность бесплатных опций хостинга. Создание комикса включало сотрудничество с разными людьми, включая Мари-Клер Ле Бланк Фланаган за ясные объяснения, Владимира Кашиковича за дизайн обложки и 66 бета-читателей за обратную связь. Комикс доступен для покупки в формате PDF или печатном виде, с отправками печатных заказов в июле.

Сообщения об ошибках в Git могут быть запутанными, особенно для начинающих. Автор анализирует несколько распространенных ошибок, подчеркивая их сложности и предлагая практические решения. Одна из проблем с улучшением этих сообщений заключается в том, что трудно определить, являются ли изменения действительно полезными. Автор отмечает, что обслуживание Git является сложным и включает в себя факторы, такие как перевод на разные языки и ограниченное финансирование усилий по улучшению. Тем не менее, некоторые предложения по улучшению ошибок включают в себя более четкие различия между разошедшимися и отстающими ветками и уменьшение подавляющего количества опций, предлагаемых пользователям при разрешении разошедшихся веток. Кроме того, автор подчеркивает важность понимания внутренней логики Git, такой как разница между ветками и путями в контексте команд, таких как `git checkout`. Понимая эти нюансы, пользователи могут лучше интерпретировать ошибки и эффективно работать с интерфейсом командной строки Git.

Автор экспериментирует с хобби, не связанными с компьютером, включая вязание крохотных кактусов. Они делятся своими опытом, включая используемые шаблоны, типы пряжи и техники. Сначала используя бесплатные шаблоны, теперь они предпочитают покупать шаблоны, чтобы поддержать создателей. Они подчеркивают радость модификации шаблонов и принятие ошибок как возможностей для обучения. Вместо безопасных глаз, они вышивают глаза и используют обрезки пряжи в качестве маркеров стежков, чтобы упростить процесс. Автору трудно считать в вязании, но они находят способ преодолевать это с помощью визуального осмотра и приближения. Они исследовали разные веса пряжи и бренды, экспериментируя с мерином, хлопком и акрилом. Размер крючка кажется менее важным для проектов кактусов. Автор научился основным стежкам и подходит к новым стежкам, начиная с шаблонов и ища руководство в видеороликах на YouTube. Они создали вещи, такие как слон, кактусы и в работе мышь. Автор ценит тактильную природу вязания, социальный аспект и минимальное пространство, требующееся для материалов. Они подчеркивают прощение вязания, позволяющее экспериментировать и принимать ошибки.

Автор провел опросы на Mastodon, чтобы собрать информацию о том, как люди используют и воспринимают Git, открыв неожиданные факты. Самым распространенным стратегией слияния является "merge", с только 30% использующих "rebase" регулярно. Несмотря на периодические конфликты, только 14% потеряли работу из-за проблем с Git за последние годы. Многие пользователи не знакомы с терминами, такими как "HEAD", "ref" и "fast-forward", что побудило автора быть осторожным в их использовании. Интересно, что большинство предпочитает Git по сравнению с SVN, а между Git и Mercurial есть разделенные предпочтения. Заметно, что 71% пользователей отображают текущую ветку в своей оболочке приглашения. Автор делится результатами опросов по git-концепциям, таким как коммиты, ветки и git-окружение, предоставляя ценные впечатления о пользовательских впечатлениях и предпочтениях.

Понятие "текущей ветки" в Git, казалось бы, очевидное, представляет собой определенную неопределенность при ближайшем рассмотрении. Пока Git-словарь определяет его как контент файла .git/HEAD, другие интерпретации существуют, включая вывод "git status", последнюю выбранную ветку и приглашение оболочки. Эти интерпретации часто совпадают, но расходятся в конкретных сценариях, таких как состояния отсоединенной головы, выбранных тегов и промежуточных состояний ребейза. Например, при выборе тега .git/HEAD хранит ID коммита, а "git status" отображает имя тега для удобства пользователя. Аналогично, во время ребейза "git status" подчеркивает состояние ребейза, в то время как приглашение оболочки может указывать на оригинальную ветку. Даже "git init" вводит неясность, где "текущая ветка" автоматически устанавливается без явного выбора. Более того, возникают сложности с голыми репозиториями, где "git status" и "git checkout" неработоспособны. Эти нестыковки подчеркивают ограничения жесткого определения "текущей ветки" и подчеркивают важность контекстного понимания. Определение "текущей ветки" как цели для новых коммитов, хотя и в основном верное, теряет силу во время ребейза, где коммит в конечном счете попадает на оригинальную ветку. Идея "текущей ветки" как контекста для операций Git имеет смысл, но есть расхождения, например, "git status" ведет себя иначе в голых репозиториях. В конечном счете, понимание особенностей "текущей ветки" требует признания ее контекстно-зависимой природы и полагается на комбинацию индикаторов, таких как .git/HEAD, вывод "git status" и последнее действие выбора для полного понимания.

Автор статьи провел опрос на Mastodon, спрашивая людей, как уверены они в понимании того, как работает HEAD в Git, и результаты показали, что многие люди были неуверены или не имели представления. Автор изначально считал, что HEAD - это простой вопрос, но обнаружил, что это более сложно, чем он себе представлял, после того как провел последующие разговоры с другими. HEAD может относиться к разным вещам, включая файл .git/HEAD, "ревизионный параметр" HEAD в командах, таких как git show HEAD, и разные способы использования HEAD в выводе Git. Файл .git/HEAD содержит либо имя ветки, либо ID коммита и определяет текущую ветку в Git. Если .git/HEAD содержит ID коммита, Git называет это "отсоединенным состоянием HEAD", что означает, что нет текущей ветки. В отсоединенном состоянии HEAD новые коммиты не будут прикрепляться к какой-либо ветке и могут быть трудными для поиска или могут быть удалены сборщиком мусора Git. Автор объясняет, как интерпретировать вывод различных команд Git, использующих HEAD, включая git status, git log и конфликты слияния. Они также предлагают, что терминология Git вокруг HEAD могла бы быть более последовательной и интуитивной.

- Обработка извлечений: `pull.ff only` или `pull.rebase true` для избежания создания коммитов слияния, когда ветка upstream расходится. - Читаемость конфликтов слияния: `merge.conflictstyle zdiff3` улучшает видимость конфликтов слияния, отображая оригинальный код посередине. - Автоматическая модификация коммитов: `rebase.autosquash true` объединяет коммиты `fixup!` с их целями во время ребейза. - Автоматическое складывание: `rebase.autostash true` запускает `git stash` перед и после ребейза. - Автоматизация пуша: `push.default current` или `push.default simple` пушит текущую ветку в соответствующую удаленную ветку; `push.autoSetupRemote true` настраивает отслеживание для первого пуша. - Ветка по умолчанию: `init.defaultBranch main` создает ветку `main` вместо `master` в новых репозиториях. - Улучшение сообщений коммитов: `commit.verbose true` отображает разницу коммита в редакторе сообщений коммита. - Автоматическое разрешение конфликтов: `rerere.enabled true` запоминает и автоматизирует разрешение конфликтов слияния. - Автокоррекция: `help.autocorrect 10` позволяет Git выполнять автокоррекции после задержки. - Визуализация разницы: `core.pager delta` использует просмотрщик разницы с подсветкой синтаксиса; `diff.algorithm histogram` улучшает видимость перестановки функций. - Глобальный файл gitignore: `core.excludesfile` указывает на глобальный файл gitignore. - Раздельные конфиги Git: `includeIf` позволяет использовать разные конфигурации для личных и рабочих репозиториев. - Предотвращение повреждения данных: `transfer.fsckobjects` и связанные настройки обнаруживают и предотвращают повреждение данных. - Другие заметные опции: игнорирование виновников, сортировка веток, настройки цвета, выбор редактора, очистка коммитов, настройки ядра, инструменты разницы, настройки слияния, пуш тегов, безопасность ребейза и формат даты в логах.

Разветвленные ветки возникают, когда локальная ветка и ее удаленный аналог имеют разные истории. Признание разветвления является ключевым, и способов узнать это включают `git status`, `git push`, или `git pull`. Разрешение разветвления зависит от ситуации. Один из подходов - сохранять оба изменяемых набора с помощью `git pull --rebase`. Чтобы отбросить удаленные изменения, используйте `git push --force`, но используйте `git push --force-with-lease` для дополнительной безопасности. Альтернативным способом является перезапись локальных изменений с помощью `git reset --hard origin/main`. Эти решения предлагают варианты для разрешения разветвления в зависимости от рабочего процесса и ситуации.

Директория .git содержит важную информацию для системы управления версиями Git. HEAD указывает на текущую ветку. Ветки, коммиты, деревья и блобы образуют ядро Git, храня историю коммитов, списки файлов и фактический код соответственно. Журналы изменений отслеживают изменения в ветках, тегах и HEAD. Ветки отслеживания удаленных репозиториев хранят последние коммиты из удаленных веток, а теги отмечают конкретные коммиты. Складывает неопубликованные изменения. .git/config хранит настройки репозитория. Хуки могут быть использованы для автоматизации действий перед коммитом. Площадка подготовки (индекс) готовит файлы к коммиту. Это общий обзор позволяет понять основы директории .git, но не охватывает всех ее тонкостей.

Понимание Git-коммитов является сложным и разным у разных людей. Опрос показал, что 51% считают коммиты как диффы (изменения между версиями), 42% - как снимки (текущее состояние файлов), а только 4% - как историю предыдущих коммитов. Внутри Git хранит коммиты как снимки, что позволяет ускорять время чекаута. Однако он также использует пакфайлы для сжатия данных, храня файлы как дельты (разницы) для экономии места. Несмотря на это реализацию на основе снимков, Git-разницы вычисляются реконструированием снимков из дельт и сравнением их. Один из "неправильных" ментальных моделей - считать коммиты как диффы от предыдущего коммита, что, хотя и не точное, все еще может быть полезным в повседневном использовании. Самый распространенный ментальный модуль, рассматривающий коммиты как диффы, соответствует типичному фокусу на изменениях кода. Другие модели, такие как снимки, полезны для понимания перемещения файлов и коммитов слияния. Кроме того, люди могут связывать коммиты с дополнительной информацией (например, электронными письмами, разговорами) или видеть их как "до" и "после" состояния.

Мотивированный проблемами с ad-hoc изменениями при использовании Ansible, автор решил установить NixOS на сервере, что предоставляло больше контроля над пакетами и пользователями. Процесс установки NixOS включал использование nixos-infect, копирование сгенерированной конфигурации, создание flake и развертывание изменений с помощью nixos-rebuild. Чтобы запустить службу Go на сервере, автор определил конфигурацию службы в одном файле .nix, что позволило создавать пользователей динамически и обеспечивать постоянное хранение. Несмотря на сложности синтаксиса языка Nix, автор оценил надежность и централизованное управление конфигурациями, предлагаемые NixOS. Однако остаются вопросы касательно конкретных проверок, выполняемых во время nixos-rebuild, и упрощенного потока работы для развертывания обновлений служб. В целом, автор считает NixOS перспективным, несмотря на возникающие трудности в отладке и изучении синтаксиса языка.

В этом году автор работал над публикацией зина, объясняющей, как целые числа и числа с плавающей точкой представлены в памяти. Они также создали инструмент для визуализации того, как переменные представлены в памяти, под названием "шпион памяти". Кроме того, автор выпустил площадку для экспериментов с представлением целых чисел под названием "целое.обнаженное". В рамках более масштабного проекта автор стремился продемонстрировать, как реализовать стэк сетевого взаимодействия с помощью Python. Первая часть этого проекта, "Реализация DNS за выходные", была выпущена и вызвала множество реализаций на различных языках. Автор прочитал ключевую лекцию о том, как сделать сложные концепции доступными. Они также опубликовали несколько блог-постов и разработали прототипы, связанные с Git, включая "git-commit-folders" и "git-oops". Автор нанял менеджера по операциям, чтобы управлять логистикой своего бизнеса, что позволило ему сосредоточиться на написании и кодировании. Они перешли на Mastodon и нашли эту платформу более подходящей для технических обсуждений. Автор размышляет о трудностях завершения проектов, признавая, что они часто занимают больше времени, чем ожидается. Они выражают благодарность за поддержку, которая позволяет им заниматься своей уникальной работой.

- Проект под названием "git-commit-folders" предлагает новый подход к визуализации коммитов Git, монтируя их как папки. - Поддерживаются файловые системы FUSE, NFS и WebDAV, с NFS как основным фокусом из-за отсутствия поддержки символьных ссылок в WebDAV. - Чтобы сохранять синхронизацию реализаций, был создан основной интерфейс FS, с адаптерами для NFS и WebDav. - Огромное количество коммитов в репозитории управляется путем организации их в папки по префиксу и кэширования упакованных хешей коммитов. - Отладка включала анализ пакетов NFS с помощью Wireshark и обработку ошибок, таких как "не является директорией" и "устаревший файловый дескриптор". - Номера inode генерируются путем хеширования путей файлов, чтобы избежать петель. - Директория "branch_histories" в настоящее время отображает только последние 100 коммитов для каждого ветвления. - Подмодули в настоящее время игнорируются. - Поддержка NFSv4 доступна, но преимущества над NFSv3 неясны. - Проект стремится сделать внутреннюю структуру Git более интуитивной, представляя коммиты как папки.

Многие люди интуитивно воспринимают ветвь Git как ответвление с родительской ветвью. Однако Git внутренне определяет ветвь как полную историю каждого предыдущего коммита, а не только "ответвления" коммиты. Это означает, что каждая ветвь содержит ту же полную историю. Внутри Git ветви хранятся как текстовые файлы с последним ID коммита. Поскольку Git не имеет понятия иерархии между ветвями и нестандартного интерфейса для изоляции ответвленных коммитов, это может быть запутанным. Ветвь по умолчанию GitHub имеет особые привилегии, подчеркивая понятие "особой ветви", несмотря на иерархическую нейтральность Git.

Автор, изначально скептически относящийся к хлопьям Nix, отправился в путешествие по изучению их полезности, проводя аналогию с контейнерами Docker для большей ясности. Признавая превосходство хлопьев в воспроизводимости и управлении зависимостями, автор стремился использовать их для поддержания централизованного списка системных пакетов, ища преимущества в настройке системы и удалении программного обеспечения. В результате серии проб и ошибок автор преодолевал трудности, такие как неотслеживаемые файлы в репозиториях Git, включение не свободных пакетов и разрешение проблем с относительными путями зависимостей от хлопьев. Используя 'nix develop' и 'buildEnv', автор успешно создал каталог символьных ссылок, представляющих желаемые пакеты. Однако процесс не обошелся без препятствий, и автор столкнулся с ошибками, связанными с хуками сборки, которые мешали прогрессу. Несмотря на трудности, автор оставался упорным в изучении хлопьев, ища более гладкий и управляемый подход к своей работе с Nix в управлении пакетами. Автор нашел существующие объяснения хлопьев трудными для понимания, полагаясь вместо этого на аналогии и практические эксперименты, чтобы развивать свое понимание. Хотя начальное знакомство автора с хлопьями было сопряжено с трудностями, его приверженность овладению этим аспектом Nix подчеркивает желание иметь более надежный и эффективный опыт управления пакетами.

Автор, изначально неправильно понимая git cherry-pick как просто применение патча, углубляется в его реальное функционирование, открывая более тонкий процесс, связанный с "трехсторонним слиянием". Ошибочное понимание возникло, когда автор пытался разрешать конфликты слияния с помощью метода патча, что не удалось, в отличие от ожидаемого поведения git cherry-pick. Более глубокое исследование исходного кода git показало, что cherry-pick использует трехстороннее слияние, понятие, незнакомое автору на тот момент. Это побудило исследовать трехсторонние слияния, которые, по сути, включают слияние двух файлов путем сравнения их с оригинальной версией (базовой). Это понятие распространяется на применение патчей в git, где версии файла до и после коммита, а также текущий файл, составляют три версии, используемые в слиянии. Cherry-pick, rebase и revert все используют эту стратегию трехстороннего слияния, отличаясь в основном порядком и интерпретацией базовой и целевой версий. Автор вводит термин "трехсторонний патч", чтобы описать эту технику, подчеркивая ее преимущество в предоставлении большего контекста для слияния по сравнению с традиционными патчами. Хотя git apply обычно обрабатывает традиционные патчи, она также предлагает флаг --3way для проведения трехсторонних слияний. Это исследование подчеркивает изумительную работу по использованию трехсторонних слияний для применения патчей в git, предлагая единый подход для различных операций, оставаясь прозрачным для пользователей, которые могут придерживаться знакомого понятия "применения патча". Автор признает сложность слияния в git, намекая на понятия, такие как рекурсивные слияния и множественные алгоритмы слияния, с рекомендацией книги "Building Git" для более глубокого изучения. Наконец, автор выражает восхищение изумительным дизайном механизма патчирования git, хваля его интуитивность и эффективность.