diff options
| -rw-r--r-- | content/posts/2021-02-13-jsonnet/index.md | 42 | ||||
| -rw-r--r-- | content/posts/2024-12-15-posse/index.md | 64 | ||||
| -rw-r--r-- | content/posts/2024-12-17-infra/index.md | 45 | ||||
| -rw-r--r-- | content/posts/2024-12-30-irc/index.md | 49 | ||||
| -rw-r--r-- | content/posts/2024-12-31-new-year/index.md | 42 | ||||
| -rw-r--r-- | content/posts/2025-04-05-tabs-or-spaces/index.md | 243 |
6 files changed, 328 insertions, 157 deletions
diff --git a/content/posts/2021-02-13-jsonnet/index.md b/content/posts/2021-02-13-jsonnet/index.md index 91a7ec2..f53103c 100644 --- a/content/posts/2021-02-13-jsonnet/index.md +++ b/content/posts/2021-02-13-jsonnet/index.md @@ -12,35 +12,24 @@ title: Jsonnet # Jsonnet -Редко такое бывает, что случайно натыкаешься на какую-то технологию и она -вызывает вау-эффект и буквально переворачивает всё верх дном. На днях для меня -такой технологией стал [Jsonnet](https://jsonnet.org/) от Google. - -В кратце, это надмножество JSON являющееся языком описания шаблонов. Пока звучит -не очень круто, да? На деле это офигенный Тьюринг полный функциональный язык, -результатом выполнения которого будет сформированый JSON (и не только) -документ(или несколько документов[^1]). +Редко такое бывает, что случайно натыкаешься на какую-то технологию и она вызывает вау-эффект и буквально переворачивает всё верх дном. На днях для меня такой технологией стал [Jsonnet](https://jsonnet.org/) от Google. + +В кратце, это надмножество JSON являющееся языком описания шаблонов. Пока звучит не очень круто, да? На деле это офигенный Тьюринг полный функциональный язык, результатом выполнения которого будет сформированый JSON (и не только) документ(или несколько документов[^1]). [^1]:https://jsonnet.org/learning/getting_started.html#multi -Если интересно, рекомендую сразу переходить к туториалу — -https://jsonnet.org/learning/tutorial.html. +Если интересно, рекомендую сразу переходить к туториалу — https://jsonnet.org/learning/tutorial.html. ## Почему же это круто? -Ну, во-первых, он реально мощный и простой. С его помощью можно формировать -документы любой сложности. +Ну, во-первых, он реально мощный и простой. С его помощью можно формировать документы любой сложности. -Во-вторых, его можно встроить в свою программу на Go (и не только, но на Go — -проще всего — https://jsonnet.org/ref/bindings.html), и это даст бесплатно -мощный DSL для написания очень гибких конфигов. +Во-вторых, его можно встроить в свою программу на Go (и не только, но на Go — проще всего — https://jsonnet.org/ref/bindings.html), и это даст бесплатно мощный DSL для написания очень гибких конфигов. -В третьих, ну камон, приятно же когда компьютер берет на себя рутинную работу по -формированию больших и сложных JSON’ов! +В третьих, ну камон, приятно же когда компьютер берет на себя рутинную работу по формированию больших и сложных JSON’ов! ## Пример -Накидал простенький пример который формирует конфигурацию пайплайна для -гипотетической CI системы: +Накидал простенький пример который формирует конфигурацию пайплайна для гипотетической CI системы: ```json local map(arr, predicate) = // определяем функцию map @@ -96,17 +85,8 @@ local commands = ['go build', 'go test']; // Общая часть Круть же! -Да, на небольшом примере не очень показательно, но даже тут, скажем, при -добавлении новой цели сборки будет достаточно слегка подправить массив tasks и -автоматически сформируется все остальное, а не копипаст целой секции и ручная -правка в нужных местах. +Да, на небольшом примере не очень показательно, но даже тут, скажем, при добавлении новой цели сборки будет достаточно слегка подправить массив tasks и автоматически сформируется все остальное, а не копипаст целой секции и ручная правка в нужных местах. -Я оставил за скобками то, что этот шаблонизатора позволяет формировать не только -JSON но и фактически любой другой текстовый формат. И даже из одного скрипта -формировать несколько документов разного формата. При этом локальные переменные -будут использоваться общие. Теоретически, если упороться, можно одним скриптом -сформировать весь /etc на новом сервере. Почему бы и нет?:) +Я оставил за скобками то, что этот шаблонизатора позволяет формировать не только JSON но и фактически любой другой текстовый формат. И даже из одного скрипта формировать несколько документов разного формата. При этом локальные переменные будут использоваться общие. Теоретически, если упороться, можно одним скриптом сформировать весь /etc на новом сервере. Почему бы и нет?:) -Не знаю смог ли передать ощущение своего восторга, но я охренеть как рад и жду -выходных, чтобы с головой нырнуть в эту технологию, которая открывает столько -новых интересных перспектив!
\ No newline at end of file +Не знаю смог ли передать ощущение своего восторга, но я охренеть как рад и жду выходных, чтобы с головой нырнуть в эту технологию, которая открывает столько новых интересных перспектив!
\ No newline at end of file diff --git a/content/posts/2024-12-15-posse/index.md b/content/posts/2024-12-15-posse/index.md index 630d983..3297dae 100644 --- a/content/posts/2024-12-15-posse/index.md +++ b/content/posts/2024-12-15-posse/index.md @@ -13,63 +13,36 @@ title: POSSE # POSSE -Решил я перейти к использованию практики POSSE. Что это такое? Аббревиатура -расшифровывается примерно следующими способами: +Решил я перейти к использованию практики POSSE. Что это такое? Аббревиатура расшифровывается примерно следующими способами: -**P** - Publish или Post, **OS** - Own Site, **SE** - Syndicate Elsewhere (мне -больше нравится, Share Everywhere) +**P** - Publish или Post, **OS** - Own Site, **SE** - Syndicate Elsewhere (мне больше нравится, Share Everywhere) -Это практика, когда изначально любой материал публикуется на полностью -подконтрольном собственном сайте, а только затем переразмещаяется на всякие -социальные сети, типа ВК, Телеги и прочих Мастодонов. +Это практика, когда изначально любой материал публикуется на полностью подконтрольном собственном сайте, а только затем переразмещаяется на всякие социальные сети, типа ВК, Телеги и прочих Мастодонов. <!--more--> ## Почему это важно? -- Во-первых, **платформы ненадежны**. Любая платформа в любой момент может - сделать что угодно с вашим контентом, или закрыться. -- Во-вторых, **право собственности**. Не секрет, что у платформ весьма вольное - представление об авторском праве на материалы размещаемые пользователями. С - одной стороны, у них неограниченное право распоряжения контентом для любых - целей, а с другой никакой ответственности за содержание контента. Не слишком - ли кучеряво? - - А следуя POSSE, я и все кто следуют POSSE — сохраняют первоисточник под своим - контролем, отдавая платформам лишь небольшой огрызок от контента. Да, у меня - не больно какой-то великий контент, за который стоит трястись, но я всё равно - предпочту сохранить за собой все права на него. -- В-третьих, **за пользователем остаётся право** выбирать где ему удобнее - следить за контентом. Либо на первоисточнике, с помощью божественного RSS (к - чему я бы хотел призывать), либо на удобной платформе куда происходит - синдикация. -- В-четвёртых, ... А давайте, я не буду пересказывать вот эту - [статью](https://indieweb.org/POSSE)? 😉 В общем, это правильная и нужная - практика. Как минимум, на долгосрок. Платформы приходят и уходят, а файлы (в - виде markdown моего блога) останутся на всегда. +* Во-первых, **платформы ненадежны**. Любая платформа в любой момент может сделать что угодно с вашим контентом, или закрыться. +* Во-вторых, **право собственности**. Не секрет, что у платформ весьма вольное представление об авторском праве на материалы размещаемые пользователями. С одной стороны, у них неограниченное право распоряжения контентом для любых целей, а с другой никакой ответственности за содержание контента. Не слишком ли кучеряво? А следуя POSSE, я и все кто следуют POSSE — сохраняют первоисточник под своим контролем, отдавая платформам лишь небольшой огрызок от контента. Да, у меня не больно какой-то великий контент, за который стоит трястись, но я всё равно предпочту сохранить за собой все права на него. +* В-третьих, **за пользователем остаётся право** выбирать где ему удобнее следить за контентом. Либо на первоисточнике, с помощью божественного RSS (к чему я бы хотел призывать), либо на удобной платформе куда происходит синдикация. +* В-четвёртых, ... А давайте, я не буду пересказывать вот эту статью[1]? 😉 В общем, это правильная и нужная практика. Как минимум, на долгосрок. Платформы приходят и уходят, а файлы (в виде markdown моего блога) останутся на всегда. + +=> https://indieweb.org/POSSE [1] ## Что я сделал чтобы следовать POSSE? -Ну для начала, у меня сильно чесались руки переделать дизайн блога. Вроде, -получилось так, как я и хотел, в стиле сайтов начала-середины 2010х. Просто -потому что могу, кто же мне тут что запретит 😉. Тем самым я улучшил UX блога, -до хотя бы терпимого. Походу дела, при редизайне, я порасставил правильных тегов -и микроформатов для правильной синдикации с другими платформами. +Ну для начала, у меня сильно чесались руки переделать дизайн блога. Вроде, получилось так, как я и хотел, в стиле сайтов начала-середины 2010х. Просто потому что могу, кто же мне тут что запретит 😉. Тем самым я улучшил UX блога, до хотя бы терпимого. Походу дела, при редизайне, я порасставил правильных тегов и микроформатов для правильной синдикации с другими платформами. + +Далее, я перепилил немного улучшил программку, которую написал уже достаточно давно, которая читает RSS моего блога и отправляет новые посты в Телеграм канал. Вот она, если что: [2] -Далее, я перепилил немного улучшил программку, которую написал уже достаточно -давно, которая читает RSS моего блога и отправляет новые посты в Телеграм канал. -Вот она, если что: https://git.neonxp.ru/posse +=> https://git.neonxp.ru/posse [2] -Кстати, в очередной раз напоминаю о [RSS ленте](https://neonxp.ru/feed/) блога. -Эта лента — это самый правильный способ подписки на блог! +Кстати, в очередной раз напоминаю о RSS ленте [3] блога. Эта лента — это самый правильный способ подписки на блог! -Так же из этой ленты автоматически подтягиваются посты в VK группу. Это сделано -встроенным механизмом VK, за что им определенно респект! Не часто можно -встретить нечто подобное на закрытых платформах (помним, же как Google убивал -RSS?)! +=> https://neonxp.ru/feed/ [3] -Сейчас прорабатываю идеи по синдикации и в Fediverse [^1]. -[^1]: пока думаю, синдицировать через узел Betula +Так же из этой ленты автоматически подтягиваются посты в VK группу. Это сделано встроенным механизмом VK, за что им определенно респект! Не часто можно встретить нечто подобное на закрытых платформах (помним, же как Google убивал RSS?)! Так же в ближайших планах и запилить WebMentions и прочие плюшки с ИндиВеба. @@ -79,5 +52,6 @@ RSS?)! ## Ссылки по теме -- https://indieweb.org/POSSE -- https://www.theverge.com/2023/10/23/23928550/posse-posting-activitypub-standard-twitter-tumblr-mastodon
\ No newline at end of file +=> https://indieweb.org/POSSE + +=> https://www.theverge.com/2023/10/23/23928550/posse-posting-activitypub-standard-twitter-tumblr-mastodon
\ No newline at end of file diff --git a/content/posts/2024-12-17-infra/index.md b/content/posts/2024-12-17-infra/index.md index d20814a..2a04fac 100644 --- a/content/posts/2024-12-17-infra/index.md +++ b/content/posts/2024-12-17-infra/index.md @@ -18,32 +18,26 @@ draft: true ## Сервер -Во-первых, недавно я почти полностью переехал с арендуемого сервера, на свой -собственный, сервер, который просто стоит у меня в комнате. +Во-первых, недавно я почти полностью переехал с арендуемого сервера, на свой собственный, сервер, который просто стоит у меня в комнате. -Именно он вынесен в заголовочное изображение и целиком помещается, даже не на -ладони, а просто на кончиках пальцев! +Именно он вынесен в заголовочное изображение и целиком помещается, даже не на ладони, а просто на кончиках пальцев! Конкретно, железо: -- **OrangePi 3B 8Gb** — выбран в первую очередь за свою дешевизну и, самое -главное, M.2 разъём -- **NVME SSD 1Tb** — собственно, жесткий диск моего микросервера -- **Корпус с активным охлаждением** — не самое необходимое, но хотелось, чтобы -выглядело красиво +* **OrangePi 3B 8Gb** — выбран в первую очередь за свою дешевизну и, самое главное, M.2 разъём +* **NVME SSD 1Tb** — собственно, жесткий диск моего микросервера +* **Корпус с активным охлаждением** — не самое необходимое, но хотелось, чтобы выглядело красиво + <!-- more --> ## Программное обеспечение -По сути, на первом уровне, установлены armbian -(https://www.armbian.com/orangepi3b/), веб—сервер Caddy -(https://caddyserver.com/), да Docker. Всё остальное уже внутри Docker'а. +По сути, на первом уровне, установлены armbian (https://www.armbian.com/orangepi3b/), веб—сервер Caddy (https://caddyserver.com/), да Docker. Всё остальное уже внутри Docker'а. ## Caddy -Caddy у меня работает в основном как reverse-proxy для Docker'а. -Без лишних слов, вот конфиг: +Caddy у меня работает в основном как reverse-proxy для Docker'а. Без лишних слов, вот конфиг: ``` { @@ -71,8 +65,7 @@ comments.neonxp.ru { Из него я убрал всё, что не относится к непосредственно блогу. -Сам блог у меня собирается с помощью Hugo и загружается в `/var/www/neonxp.ru` с -помощью rsync[^4], а оттуда уже раздается с помощью Caddy. +Сам блог у меня собирается с помощью Hugo и загружается в `/var/www/neonxp.ru` с помощью rsync[^4], а оттуда уже раздается с помощью Caddy. [^4]: https://git.neonxp.ru/blog.git/tree/Makefile#n11 @@ -102,20 +95,18 @@ volumes: remark42: ``` -Как понятно из этого docker-compose.yml — дополнительно поднимаются два -контейнера: +Как понятно из этого docker-compose.yml — дополнительно поднимаются два контейнера: -- remark42 — система комментариев -- posse — моя программка, которая чекает RSS блога и репостит его в Telegram +* remark42 — система комментариев +* posse — моя программка, которая чекает RSS блога и репостит его в Telegram ## Остальное -Конечно же, на этой железке крутится не только блог, но и несколько других -сервисов для личного использования +Конечно же, на этой железке крутится не только блог, но и несколько других сервисов для личного использования -- Nextcloud — личное облако -- Vaultwarden — хранилище паролей -- SOPDS — личная библиотека Либрусека -- Git хостинг и Container registry — для разработки и хранения кода +* Nextcloud — личное облако +* Vaultwarden — хранилище паролей +* SOPDS — личная библиотека Либрусека +* Git хостинг и Container registry — для разработки и хранения кода -Но об этом я расскажу в другой раз 😉
\ No newline at end of file +Но об этом я расскажу в другой раз 😉 diff --git a/content/posts/2024-12-30-irc/index.md b/content/posts/2024-12-30-irc/index.md index 80402bb..3270abf 100644 --- a/content/posts/2024-12-30-irc/index.md +++ b/content/posts/2024-12-30-irc/index.md @@ -14,30 +14,18 @@ draft: true # IRC -Когда-то единственным способом общения в сети в режиме реального времени был -исключительнольно протокол IRC. И всем бы он был хорош — простой, лёгкий, может -работать на чём угодно. Но времена изменились и мы погрязли во всяких -телеграммах да вотсаппах (пока не запрещенные на территории России, к -сожалению). - -Это грустно, но закономерно. Но делает ли это ИРКу плохой? Да нет конечно! И -лично меня притягивают именно такие надёжные и простые вещи — открытые, -текстовые протоколы, софт для которых можно написать чуть ли не на коленке для -любого электрочайника. - -Например, даже на таких устройствах[^1], я вполне себе могу представить клиент к -ИРКе, но не представлю клиента телеграма. +Когда-то единственным способом общения в сети в режиме реального времени был исключительнольно протокол IRC. И всем бы он был хорош — простой, лёгкий, может работать на чём угодно. Но времена изменились и мы погрязли во всяких телеграммах да вотсаппах (пока не запрещенные на территории России, к сожалению). + +Это грустно, но закономерно. Но делает ли это ИРКу плохой? Да нет конечно! И лично меня притягивают именно такие надёжные и простые вещи — открытые, текстовые протоколы, софт для которых можно написать чуть ли не на коленке для любого электрочайника. + +Например, даже на таких устройствах[^1], я вполне себе могу представить клиент к ИРКе, но не представлю клиента телеграма. [^1]: https://club.hugeping.ru/blog/IYMX9ZdAnn0dA1RBO5JH#IYMX9ZdAnn0dA1RBO5JH -И недавно я обнаружил, что IRC не только не умер, но и развивается, -осовременивается! Сейчас есть актуальная современная версия протокола -[IRCv3](https://ircv3.net/), которая не потеряла былой простоты и -интерперабельности! +И недавно я обнаружил, что IRC не только не умер, но и развивается, осовременивается! Сейчас есть актуальная современная версия протокола [IRCv3](https://ircv3.net/), которая не потеряла былой простоты и интерперабельности! # Мой IRC -Короче, не затягивая сильно, я запустил для теста небольшой свой сервачок, куда -и приглашаю забежать на огонёк и посидеть в ламповой олдскульной атмосфере: +Короче, не затягивая сильно, я запустил для теста небольшой свой сервачок, куда и приглашаю забежать на огонёк и посидеть в ламповой олдскульной атмосфере: В любом современном IRC клиенте: @@ -49,29 +37,16 @@ draft: true # Чем он хорош? -Ну помимо вышеуказанных простоты и интерперабельности протокола, можно выделить -и то, что поскольку общение чисто текстовое, без всяких гифок, картинок и -прочего. Казалось бы, это же скорее минус? А вот и не обязательно. В каком-то -роде это мотивирует к конструктивному общению, когда надо хоть немного включать -мозг и думать что писать. Таким обазом, повышается осмысленность общения и -появляется определённая самодисциплина. Примерно так же, как и в переписке по -e-mail, что я тоже весьма и весьма уважаю. +Ну помимо вышеуказанных простоты и интерперабельности протокола, можно выделить и то, что поскольку общение чисто текстовое, без всяких гифок, картинок и прочего. Казалось бы, это же скорее минус? А вот и не обязательно. В каком-то роде это мотивирует к конструктивному общению, когда надо хоть немного включать мозг и думать что писать. Таким обазом, повышается осмысленность общения и появляется определённая самодисциплина. Примерно так же, как и в переписке по e-mail, что я тоже весьма и весьма уважаю. # Станет ли оно популярным? -Да нет, конечно! Это всегда будет исключительно нишевая гиковская игрушка. И это -даже хорошо. Лампово. Так же как и обычные текстовые блоги, например. Но это не -значит, что это не имеет право на жизнь. +Да нет, конечно! Это всегда будет исключительно нишевая гиковская игрушка. И это даже хорошо. Лампово. Так же как и обычные текстовые блоги, например. Но это не значит, что это не имеет право на жизнь. -Ну и да, это одна из технологий, которые я отношу к тем, что пригодятся -человечеству в случае кризисов. +Ну и да, это одна из технологий, которые я отношу к тем, что пригодятся человечеству в случае кризисов. # Альтернативы? -Самая хорошая альтернатива, что я вижу — это протокол Matrix, который выглядит -как новомодный хипстерский IRC с JSON поверх HTTP(S). С моей точки зрения, у -него есть серьёзные недостатки, но считаю, что он вполне себе займёт ту же нишу. +Самая хорошая альтернатива, что я вижу — это протокол Matrix, который выглядит как новомодный хипстерский IRC с JSON поверх HTTP(S). С моей точки зрения, у него есть серьёзные недостатки, но считаю, что он вполне себе займёт ту же нишу. -Всякие телеграммы и прочее завязанное на конкртеного вендора я не рассматриваю -как альтернативы. Да, они удобные, популярные, но мертворожденные, как -технология.
\ No newline at end of file +Всякие телеграммы и прочее завязанное на конкртеного вендора я не рассматриваю как альтернативы. Да, они удобные, популярные, но мертворожденные, как технология. diff --git a/content/posts/2024-12-31-new-year/index.md b/content/posts/2024-12-31-new-year/index.md index 7c602a9..0dab3d1 100644 --- a/content/posts/2024-12-31-new-year/index.md +++ b/content/posts/2024-12-31-new-year/index.md @@ -16,31 +16,39 @@ title: С Новым Годом! В этот день принято подводить итоги года. Ну и я подведу немного: -- Поступил на второе высшее в институт брака. Раз уж нет классического высшего, - что ещё остаётся то ;) -- В аккурат под конец года разрешились проблемы на работе. Причем разрешились - настолько удачно, что я почти что жду окончания новогоднего отпуска, чтобы - скорее начались трудовыебудни. -- Стал активно вести блог. Но всё равно не оставляет подспудное ощущение, что - уже стал надоедать этим тем, кто подписан. После каждого поста жду что кто-то - да отпишется :) Но мне нравится его вести, так что, уже не остановлюсь :) -- Ездили с новоиспеченной супругой на Кавказ. Самое яркое — посетили - обсерваторию в Нижнем Архызе. Под впечатлением, купили по приезду настоящий - телескоп! -- Начали строить свой домик в деревне. Но пока ещё до заселения далеко, вот - только окна поставили. +* Поступил на второе высшее в институт брака. Раз уж нет классического высшего, что ещё остаётся то ;) +* В аккурат под конец года разрешились проблемы на работе. Причем разрешились настолько удачно, что я почти что жду окончания новогоднего отпуска, чтобы скорее начались трудовыебудни. +* Стал активно вести блог. Но всё равно не оставляет подспудное ощущение, что уже стал надоедать этим тем, кто подписан. После каждого поста жду что кто-то да отпишется :) Но мне нравится его вести, так что, уже не остановлюсь :) +* Ездили с новоиспеченной супругой на Кавказ. Самое яркое — посетили обсерваторию в Нижнем Архызе. Под впечатлением, купили по приезду настоящий телескоп! +* Начали строить свой домик в деревне. Но пока ещё до заселения далеко, вот только окна поставили. Под катом приложу фоточки наиболее ярких моментов, пожалуй. <!--more--> -  -  +=> 1.webp [img] Институт брака + + + +=> 2.webp [img] Выхожу с работы + + + +=> 3.webp [img] Собаньки на Кавказе + + + +=> 4.webp [img] Своя личная обсерватория + + + +=> 5.webp [img] Домик в деревне +  + Вот как-то так :) -А пока, возвращаемся к новогоднему столу и готовимся встретить наступающий 2025 -год! +А пока, возвращаемся к новогоднему столу и готовимся встретить наступающий 2025 год! Надеюсь, всё у нас у всех будет хорошо в этом наступающем новом году!
\ No newline at end of file diff --git a/content/posts/2025-04-05-tabs-or-spaces/index.md b/content/posts/2025-04-05-tabs-or-spaces/index.md new file mode 100644 index 0000000..2edea61 --- /dev/null +++ b/content/posts/2025-04-05-tabs-or-spaces/index.md @@ -0,0 +1,243 @@ +--- +title: Табы или пробелы? +description: +date: 2025-04-05T16:53:27+03:00 +categories: + - Размышления +tags: + - размышления +location: Казань +image: +--- + +Так получилось, что с Нового Года я ничего в блог не писал. Тому причина в личной загруженности, и в не менее личной лени. Так же я делал некоторые эксперименты над самим блогом, потому что моё внутреннее чувство прекрасного не даёт мне просто остановиться и не трогать то, что работает. + +Но всё же, я чувствую внутреннюю потребность написать небольшую заметку с размышлениями, которые недавно приходили ко мне в голову. + +А связаны они с тем, что есть определённые догмы в индустрии, которые непонятно (ну или понятно) почему появились, и которым слепо следуют, хотя, как будто они уже не имеют смысла. + +<!--more--> + +## Вечный спор + +Для затравки, «вечный спор» табы или пробелы использовать в коде для отсутпов. Лично для меня здесь не то что выбор очевиден, для меня очевидно, что и самого выбора то нет. Конечно же, только табы! Отступ пробелами просто не имеет права на жизнь, и вот почему: + +* Во-первых, это просто какой-то костыль, использовать пробел не по назначению. Наверное, не очень очевидно, но назначение пробела — это именно разделение слов. Невероятно! А наначение таба — как раз таки форматирование отступа. Давайте использовать инструменты по назначению! +* Во-вторых, и самое главное, как по мне, это гибкость табуляции. Я, как читающий код, волен сам выбирать размер отступа. Например, если у меня узкий экран (смартфон, например) — я выберу отступ в 2 *визуальных* пробела. Наоборот, если бы у меня было слабое зрение — я бы выбрал отступ в бо́льшее число *визуальных* пробелов. +* В-третьих, исходя из предыдущего пункта, я считаю, что использование именно пробелов — это диктование автором исходника мне своей воли в виде своих предпочтений (например, только 4 пробела, и никак иначе!). А какого чёрта? Это буквально насилие! Зачем? Я считаю, это не допустимо. Пусть у каждого будет возможность выбирать себе настройки отображения на *своей* машине под *свои* вкусы, а не вкусы автора! +* В-четвёртых, самое малозначительное — это то, что таб это 1 байт, а пробелов обычно больше чем 1 байт (от 2 до 8). Я считаю этот аргумент малозначительным, т.к. уж что что, а места на носителях информации нынче в достатке. Но тем не менее, это один из аргументов! + +А что по аргументам за пробелы? Да нет их. Ну окей, предположим, что есть. Во многих кодстайлах (PEP-8, PSR итп) закреплены именно пробелы. Я не понимаю, почему, вроде как, умные люди которые эти стандарты придумывали так сделали. Возможно, привычка. Но является ли привычка каких-то людей аргументом? Наверное, нет. И самое грустное, что эти стандарты уже не поменять, ибо с их использованием *уже* написаны мегатонны кодов. + +Единственное, меня радует, что хотя бы в стандарте форматирования моего любимого языка Go этой откровенной чуши нет. В Go отступы приняты табами и только ими. + +Сразу скажу, я говорил только про отступы в начале строки, но не про отступы внутри строки, например, чтобы выстраивать значения подряд идущих констант в одну ровную колонку. Там, вроде как, пробелы вполне оправданы. Но это не точно. Я пока не решил для себя. + +Думаю, здесь насчёт табов и пробелов можно завершить. Если есть что накинуть — пишите письма, e-mail внизу страницы. + +## Вечный консенсус + +Про табы и пробелы была скорее затравочка. Там, как мне кажется, всё очевидно. Но есть менее очевидная, но как мне кажется очень родственная тема. Эта тема вызывает сильно меньше споров, т.к. вроде как в ней уже есть консенсус. Но этот консенсус ошибочен! + +А говорю я про форматирование длины строк! А именно, т.н. hard-wraps и soft-wraps. Если коротко, при hard-wraps в текст в точках переноса (например, на 80 или 120 колонке) вставляются символ переноса строк (`\n`), при мягком переносе текст остается на одной строке, но выглядит так, как будто он разделен на несколько строк. + +А начну я с небольшой предыстории, как я к этому пришёл. Как я уже писал в начале, у меня есть постоянное шило в седалище, которое не даёт мне просто остановиться и использовать то, что работает, как минимум, в контексте этого блога. И из последнего куда я смотрел — протокол Gemini[1]. Разбирая его, меня сначала немного удивила его особенность, а именно: + +=> https://geminiprotocol.net/ [1] + +> Text in Gemtext documents is written using "long lines", i.e. you (or your editor) shouldn't be inserting newline characters every 80 characters or so. Instead, leave it up to the receiving Gemini client to wrap your lines to fit the device's screen size and the user's preference. This way Gemtext content looks good and is easy to read on desktop monitors, laptop screens, tablets and smartphones. + +> Note that while Gemini clients will break up lines of text which are longer than the user's screen, they will not join up lines which are shorter than the user's screen, like would happen in Markdown, HTML or LaTeX. This means that, e.g. "dot point" lists or poems with deliberately short lines will be displayed correctly without the author having to do any extra work or the client having to be any smarter in order to recognise and handle that kind of content correctly. + +Сначала, я подумал, да это же нифига не удобно, что используются длинные строки, а не склеиваются разделённые одним переносом как в Markdown! Более того, это моё возмущение подогревалось тем, что я всё это время был сторонником как раз hard-wraps и форматировал что код, что markdown для блога по 80 или 120 колонке. Потому что так всегда и везде было принято. Но потом вчитавшись, я понял, что как раз таки «склеивание» Markdown это максимально неправильное поведение! Оно порождает такие минусы, как более сложный парсинг, который должен обрабатывать по разному один и два переноса строк, неочевидность, когда пишешь текст в редакторе, а отображается он совсем по другому, потенциальные ошибки, когда абзацы внезапно склеиваются, и т.п. + +При этом, парсинг Gemtext поразительно простой. В общем случае, достаточно парсить по строке, и не думать о предыдущем состоянии (относится текущая строка к предыдущему параграфу или таки нет). Единственное исключение — преформатированный текст, при парсинге которого надо помнить состояние. Но и это очень просто, достаточно держать единственный флаг который говорит, мы сейчас в нормальном состоянии или в состоянии преформатированного текста. И переключать этот флаг когда очередная строка начинается с *```*. Вообще, Gemtext кажется наиболее правильным и приятным для меня языком разметки. Наверное, я на него перейду. Но потом, сейчас нет времени. + +К чему я тут углубился в описание формата Gemtext? А вот к чему: только после прочтения спеки этого формата до меня сошло озарение, что использование длинных, а не обрезанных по 80 или 120 или ещё какую колонку более правильное не только для формата разметки, но и для обычного кода! + +И вот аргументы: + +* Во-первых, все редакторы кода поддерживают soft-wrap и каждый волен выставить для своего личного редактора удобную ему длину строки, а не подчиняться привычкам автора кода. +* Во-вторых, за длину в 80 символов топят в основном старпёры что-то там говорящие про терминалы шириной в 80 символов. Только и этот аргумент не понятен. Когда вы в последнее время видели терминал в 80 символов? Не эмулятор терминала, а именно сам терминал? Ну даже, хорошо, пусть будет этот терминал в 80 символов. Но он что, не умеет переносить? Подозреваю, что может. И в чём тогда проблема? Непонятно. Короче, требование в 80 символов (ну или более современное в 120) выглядит как высосанное из пальца, потому что под ним нет реальной основы кроме каких-то там исторических причин на доисторическом железе. +* В-третьих, см. пункт про насилие автора кода над читателем кода. Например, опять таки, узкий монитор например. И на нём не soft-wrapped текст может вызывать горизонтальную прокрутку. И это убого. +* В-четвёртых, да, это усложняет парсинг. Это слабый аргумент, я знаю. Как пример, правильный парсер Markdown (не буду тут бомбить про количество разных стандартов Markdown) пишется не то чтобы очень просто. В это же время, написать парсер Gemtext который полностью покроет спецификацию — дело максимум часа-двух для любого, кто программирует больше, хотя бы, нескольких месяцев! + +В общем, как и в случае с табо-пробелами я не вижу ни одной достойной причины делать жесткие переносы строк по какой-то длине! + +Возможно, я что-то упустил — тоже можно по этому поводу поспорить со мной в электропочте. Возможно, я даже поменяю мнение, но наврядли. + +## Update 06.04.25 + +Как я и просил, один хороший человек, Владислав (https://t.me/c/1331521959/2285), написал ответ. Прокомментирую его здесь: + +> Мне есть что сказать про ширину таба и 80 символов. + +> Аргумент про разную ширину таба работает слабо: многие стили предполагают его фиксированную длину. Если ставить другой, то форматирование ломается. + +> Пример: ядро Linux, где ширина таба 8, и аргументы функций "плывут" при другой ширине. + +Я не единожды видел этот аргумент, но он как раз и кажется мне слабым. Большая ли разница для читающего код, как именно он его видит: + +``` +// tabsize=2 + func someFunc( + one, + two, + three, + ) +... + callOfSomeFunc = someFunc( + "one", + "two", + "three", + ) +``` + +или так + +``` +// tabsize=4 + func someFunc( + one, + two, + three, + ) +... + callOfSomeFunc = someFunc( + "one", + "two", + "three", + ) +``` + +или даже так + +``` +// tabsize=8 + func someFunc( + one, + two, + three, + ) +... + callOfSomeFunc = someFunc( + "one", + "two", + "three", + ) +``` + +Кажется, что для 8 пробелов на таб всё сильно уезжает, но раз человек себе так настроил — то как будто его право и наверное были основания? + + +> Про 80 символов. Дело вообще не в размере терминала или ширине перфокарты. Некоторые программисты разделяют редактор на две вкладки, чтобы смотреть два файла. + +И тогда soft-wrap как раз и вместит весь код в каждую из половинок без горизонтальной прокрутки, о чём я и говорю. + +> Некоторые используют большой шрифт. С шириной в 120 символов мы лишаем из возможности удобно читать код. К тому же, я считаю этот аргумент важным, 120 символов - это способ замаскировать плохой код. Чувак сделал 5 уровней вложенности в коде? Отлично! Главное чтобы в 120 символов влезло. + +Всё так! Возможно, я не очень подробно расписал, но основная моя мысль в том, что такое жесткое ограничение мне кажется просто надуманным и взятым с потолка. А если я после функции хочу написать небольшой коммент и он ну никак не влезает на пяток символов? Новую строку ради этого делать? Ну как-то бредово. А для указанного случая гораздо лучше бы звучало ограничение в стандарте типа «не используйте больше 3 уровней вложенности в коде». Это хотя бы имело вполне себе обоснование, то что скорее всего такой код просто архитектурно неверен и его стоит пересмотреть. + +> Конечно, можно сказать что есть длинные константы или имена функций, но этот спор становится менее однозначным. Как по мне вполне хороший консенсус - это 100 символов в строке + +Здесь не согласен. Здесь опять «магическая константа» с потолка. + +> В целом, эти срачи мне кажутся достаточно поверхностными. Они в своем корне несут вопрос "как повысить читаемость кода?", но акцентируются на мелочах. + +Согласен. Мелочи. Но почему и бы про мелочи не поговорить :) Из них по отдельности всё и строится (избитая фраза, да). В больших стандартах обычно говорится просто декларативно «только пробелы, отступ 4 пробела, длина строк 120» и всё. А зачем и почему — опускается, как будто всем всё и так понятно. Мне вот не очень. Чувствую себя ребёнком спрашивающим «Почему небо синее?». Потому что мне кажется, что под этим требованием нет объективного требования кроме «так принято». А «так принято» я часто и принимаю как валидный аргумент, например, когда прихожу в какой-то проект, но в сути своей аргументом не является. + +> Хотелось бы иметь какие-то объективные метрики, какая-то работа в этом направлении была проделана, но, как я понял, это, во-первых, недостаточно точные метрики, а во-вторых, недостаточно развитая история. https://seeinglogic.com/posts/visual-readability-patterns/ + +Интересная статья, спасибо, с удовольствием прочитал. В целом, по выводам (https://seeinglogic.com/posts/visual-readability-patterns/#8-patterns-for-improving-code-readability) согласен. Метрика по Хольстеду (или как это перевести?) выглядит интересно, тем что она чётко считается (хотя когда я руками считал, что-то у меня не сошлось с примером :) ). + +Из объективных метрик, тут вскользь ещё упоминалась цикломатическая сложность, которая вполне себе имеет право на жизнь. + +А так же, только что пришло в голову что можно читабельность кода оценивать как вторую (?) производную от отступов по непустым строкам. При этом, чем эта производная ближе к нулю — тем лучше. + +То есть, грубо говоря вот такой «код»: + +``` +_____ + ________ + _____ + _______ + ___ + ___ + _____ + __ + ____ +___ +``` + +Лучше чем, такой: + +``` +_____ + ________ + _____ + _______ + ___ + ___ + _____ + __ + ____ + ___ +``` + +Это стоит ещё подумать, это буквально пришло в голову только что, пока читал статью. + +P.S.: Из забавного + +> As others have written, computers are fast and premature optimization is a bad thing. + +Сначала они пишут «computers are fast» а потом происходит такое: [2] + +=> https://tonsky.me/blog/disenchantment/ru/ [2] + + +## Update 06.04.25 - 2 + +Со вчерашнего дня я решил дополнить немного ещё. + +Во-первых, хочу немного снизить градус холиворности и радикальности. Ещё раз упомяну что не вижу проблем для выравнивания пробелами текста внутри строки. То есть например, вот так: + +``` +→ → ConstWithLongName = 0 +→ → Const1 = 1 +→ → Const2 = 2 +→ → Const3 = 3 +``` + +для меня вполне нормально кажется. Даже более того, табы *внутри* строки кажутся плохим решением. Я говорю только про отступы в начале строки. + +Во-вторых, насчёт длинных строк. Я расписал немного сумбурно и в одну кашу смешал как код, так и просто текст. Не стоило так. Хоть это и разные сущности, но я всё равно считаю жесткое ограничение необоснованным ни там ни там. Но по разным причинам: + +* Для обычного текста ограничение в N символов выглядит таким же не обоснованым, как, например, требование автора «Читайте мои тексты только шрифтом Arial 12pt». Глупость? Глупость. +* Так же встречал, что люди используют это ограничение при написании электронных писем. Это выглядит как минимум странно. Письмо пишется для кого? Для получателя, т.е. читателя. Почему отправитель за читателя решает то, как у него будет отображаться письмо? Я часто читаю почту со смартфона с узким экраном, но средним шрифтом (чтобы меньше напрягать глаза). И горизонтальная прокрутка выглядит не очень. Горизонтальная прокрутка вообще почти всегда выглядит не очень и её стоит избегать всеми силами. +* Для кода же история другая. Я не настолько поехал чтобы требовать всё писать в одну строку. Если у функции в сигнатуре много (больше одного - двух) аргументов — то это отличная идея написать их в столбик, а не в длинную линию, которая ещё неизвестно как перенесётся. Я против именно переноса только из-за магической константы колиечества символов. + +Да и вообще я ни от кого ничего не требовал. Я предлагаю только задуматься, а обоснованны ли «общепринятые» вещи? Может, уже прошло какое-то время и ситуация поменялась и удобнее и эффективнее выбрать что-то другое? + +И как будто стоит абстрактному «читателю», к которому я отсылал, в этом посте, решать этот вопрос техническими средствами, типа editorconfig + pre-commit хуки на форматирование в принятый в команде формат? Возможно да. Иначе получится, что борясь за личную свободу — нарушаешь чужую свободу <del>писать говнокод</del>. + +А .editorconfig я себе такой в home положил: + +```.editorconfig +[*] +indent_style = tab +tab_width = 4 +end_of_line = lf +charset = utf-8 +trim_trailing_whitespace = true +insert_final_newline = true +soft_wrap = true + +[*.{yml,yaml}] +indent_style = space +indent_size = 2 + +[*.json] +indent_size = 2 +``` + +Вроде как, покрывает основное. |