Между Vim и NVim для разработки, конечно, нужно выбирать NVIM, поддержка цветов, консольных шрифтов, асинхронных плагинов и т.д. в Nvim намного лучше. С учетом, что современные терминалы - это крутые комбайны, использующие графический режим в полный рост (включая оптимизации на видеокарте), то Nvim, при грамотных настройках, выглядит очень круто.
Мне очень нравится сетап NvChad, который очень красиво выглядит из коробки, использует менеджер Mason для LSP и DAP серверов, позволяющий легко подключить LSP, линтер, форматтер - https://github.com/NvChad/NvChad
Из недостатков - LspConfig (он используется в NVim для подключения сторонних серверов) очень глючно работает в конфигурациях с несколькими Lsp серверами, заставить работать TSserver + Rome у меня не получилось, под тем же Coc все работает идеально. Обойти можно, используя Linter из-под LS-null.

После установки NvChad нужно знать пару вещей, которые облегчают жизнь, если вы новичок:

Ctrl + N - открыть дерево проекта
:Telescope keymaps - команда показывающая все key-биндинги

Upd. NvChad - это Lua сетап, VimScript уже не модно использовать в 2022 году )

#tools #vim #nvim

Награда S0ER DEVS 2022, выпущенная как NFT токен, нашла своего владельца

#award

На самом деле говорить, что ИИ "пишет" код - неправильно, все что делает ИИ - это генерирует код по шаблону. Примерно как сравнивать печать картины на принтере и рисование ее на холсте - по смыслу это разные процессы. Все что сейчас умеет ИИ - это выявлять сложные, повторяющиеся закономерности в коде и потом воспроизводить их по запросу. Кроме закономерностей ИИ научился определять контекст (по сути нейронка "запоминает" сделанное ранее и делает соответствующую коррекцию).

В итоге нейронка смогла генерировать осмысленный код, что сильно меняет расстановку сил - для бизнеса получить помощника, который будет писать шаблонный код быстрее, качественнее, да еще не уставать и не выгорать - это очень соблазнительная "конфетка".
Денег в ИИ вкладывается очень много. В России только Сбер планирует вложить 100 млрд. рублей до 2030 года. Правда, отечественный рынок AI растет сильно медленнее, чем его конкуретны в мире, но ситуацию это кардинально не меняет.
#мысли

Небольшая трансляция на тему заменят ли программистов с помощью ИИ https://youtu.be/KoalCCzAEdg

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

Все кто согласен, что youtube стал какашкой ставьте соответствующую эмоцию))))

Меня откровенно пугает уровень "критики", которую выдают современные разрабы. Посмотрел, то что показал Алексей и ужаснулся, после каждого пункта хочется спросить "и чо?", нет ровным счетом ни одного технических значимого замечания, которое имеет сколько-нибудь серьезные последствия. Автору критики хочется напомнить "помни, нейронки уже идут делать твою работу!" )))))

Кстати, какой-нибудь ChatGPT выдал бы критику примерно такого же уровня! Задумайтесь об этом пока не поздно.)


https://www.youtube.com/watch?v=ahrWKDvXpaQ

В основе любой инженерной работы лежит понятие "противоречие требований".
Противоречие требований (ПТ) – это противоречие между определенными частями, качествами или параметрами системы.
ПТ возникает при улучшении одних частей (параметров) системы за счет недопустимого ухудшения других.

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

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

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

Основные характеристики программного кода - это обычно -ility характеристики: availability, usability и т.д. в русском их, наверное, правильно назвать "-ость" характеристики: производительность, доступность, дружелюбность и т.д.

#мысли

Хочу немного поговорить про "Sqlite vs PostgreSQL".
Вчера Алексей правильно сказал, что инструмент выбирается под задачу, но не объяснил почему PostgreSQL - плохой выбор для небольших пет-проектов, которые делаются быстро и без команды.

Короткий ответ: Проблема любого сложного инструмента - это сопровождение. Если у вас не открыто достижение "администрирование PostgreSQL", то использовать его вредно для здоровья безопасности вашего проекта.

Длинный ответ: Я знаю, что программисты с рождения умеют учить, лечить и админить серваки, но правда в том, что "петух - не птица, программист - не сисадмин". У меня был забавный случай, нас попросили помочь коллегам разобраться с тем, почему им на прод постоянно заливали малварь. Это была небольшая компания, в которой работало несколько разрабов и приходящий админ. Самый "опытный" программист сразу объяснил, что "это долбанный Wordpress настолько дырявый, что мы его замучились патчить". Их версия была в том, что им заливают вирусы через дыры в WordPress. На что "грешили", то и "лечили".

Мы провели стандартный набор мероприятий по аудиту безопасности: прошлись сканерами, посмотрели логи, запустили тестовые транзакции и т.д. В итоге нашли много чего интересного, но проблема была связана с тремя детскими ошибками конфигурирования:
- файрвол настроен криво: SSH поднять на дефолтном порту и открыт для всех
- дефолтный юзер postgreSQL работает с паролем postgres
- на пользователя postgres назначен шел

Зачем на postgres нацепили sh так и осталось загадкой, я думаю, что где-то был кривой туториал без пометки "не для прода". Сама проверка postgres/postgres черезе SSH есть во многих сканерах безопасности, ботнеты тоже сканят такие вещи.

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

В небольшом приложении апнуть SQLite до PostgreSQL - это дело пары часов, максимум одного дня. Главное, чтобы при это админ был толковый и грамотно настроил инфраструктуру. Я, кстати, не умею грамотно настраивать PostgreSQL, поэтому даже и не пытаюсь, а беру SQLite для своих пет-проектов и еще не разу об этом не пожалел. )

#мысли #postgreSQL

Во-первых, сложность только повышается, а не понижается. Потому что облачная инфраструктура и вообще service as a code - это тот еще "пирожок".
Во-вторых, в облаках проблем не меньше, на вскидку, проблемы нарушения изоляции.
В-третьих, предлагать решение для уже решенной проблемы может любой, нужно предложить не просто альтернативу, а уменьшить риски, чтобы они были сопоставимы.

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

Отвечу коротко:
- не сканируют ботнеты никакие порты кроме дефолтных, это же не вручную один хост промониторить;
- не вешается в ssh на postgress никакой shell, можете погуглить про nologin
- пароль рекомендуют менять - это правда, это не отменяет того факта, что их не меняют.

И да, у автора данного комментария, все под контролем, он отлично разбирается в администрировании ))))) Ему можно не париться )))

Но надо признать, что грамотные админы действительно не переносят дефолтные порты, так как у них обычно куча железа на сопровождении и потом голову сломаешь что и куда перенесено. Им проще и эффективнее настроить файрвол и парольную защиту. Но, повторюсь, сколько угодно профессиональный программист не является таким же профессиональным админом. Поэтому, лучше сделайте простые secure by obscurity, это очевидно лучше, чем сидеть и без нормального файрвола и без хоть какого-то запутывания.

И главное помните "Если надо объяснять, то не надо объяснять". Зинаида Гиппиус (С)

"Интересно то, что программисты уверены, что именно с ними ничего подобного не случится, что они уж точно все настроят и будет все на высшем уровне" (С) S0ER

Я таки не понял, это было оскорбление? Если да, то сильно толсто для меня.

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

Еще раз для тех кто в танке, проблемы возникают после того как на postgres вешают пароль такой же как имя. С этого момента вас начинают пускать по ssh без проблем, по ssh пускают, потому что вы поставили пароль, но не убрали логин, делаете nologin и пускать перестает, чтобы попасть в своего горячолюбимого postgres нужно делать su —shell /bin/bash postgres или настраивать sudo

Правильно в данном случае не ставить пароль и нормально настроить файрвол, если хотите пароль (ну вот захотелось аж не могу), то ставите nologin (или настраиваете sshd)

Про systemd надо конкретнее, может чего не знаю, но postgresql стартанет и будет работать, может какие-то "глубокие" ошибки есть

С позиции информационной безопасности, в корпоративной архитектуре, как правило, применяются следующие ограничения (или их вариации):
- запрет суперпользователя;
- разделение на администраторов и администраторов информационной безопасности (АИБ)
- запрет на вход под служебными пользователями (если нельзя технически, то разделяют пароль между админом и АИБом, так что войти можно только вместе)
- принцип наименьших привилегий (как правило, это значит, что все работает должно работать без вмешательства или использования учетной записи суперадминистратора)

В некоторых организациях делают интересный ход, АИБ ничего не настраивает, а только контролирует и выносит "предписания", а администратор отвечает за реализацию требований. Администраторы очень не любят такое разграничение, но на практике, если объединить функции контроля и выполнения, то качество резко падает. Администраторы начинают ослаблять безопасность системы, мотивируя это тем, что "реализовать требование невозможно", в системе постоянно нарушается принцип наименьших привилегий, для администраторских задач используется суперпользователь и т.д.

Архитекторам решений, тоже прилетает от АИБов, когда я согласовывал проекты с управлениями безопасности и потом взаимодействовал с АИБами при опытной эксплуатации, то постоянно сталкивался с требованиями, которые мне казались нереализуемыми. Первое что хочется сделать в такой ситуации, это доказать, что ничего сделать нельзя, но когда начинаешь искать аргументы, то оказывается, что многие вещи можно реализовать, просто решение лежит не на поверхности.

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

Отличный видос от Максима Горшенина про конфу в Норильске. Мне очень зашло, рекомендую посмотреть. https://rutube.ru/video/1fb42c8cc877a94a58e677d2f6a17191/

Для справки, в postgresql параметры окружения лежат в юните с конфигурацией. Их легко найти в /usr/lib/systemd/system/postgresql.service (в разных ОС могут быть косметические отличия в пути). По дефолту там указывается только один параметр:

Environment=PGROOT=/var/lib/postgres

В env пользователя в режиме nologin различие будет только в том, что в PATH не будет пути к ~/.local/bin, остальное будет точно таким же как с /bin/bash

Проверял на Ubuntu и Manjaro.

Systemd, естественно, работает нормально и так, и так.

#postgresql #tip

Меня спрашивают чего я комменты не открываю? Вот из-за таких хамов и не открываю.
Со своей стороны я потратил время, проверил все безумные утверждения этого товарища, показал конкретно с командами и конфигами что он ошибается, а в ответ хамство. Причем за весь разговор ни имен переменных, ни названия дистров, ни другой конкретики.
И таких очень много. Для меня это впустую потраченное время.

P.S> поэтому хоть контент для канала сделаю, может кому пригодится для расширения кругозора.

#обида #яодинхороший

Было много споров по поводу того, что вешать на служебных пользователей шел - это плохая практика. Эта проблема переодически обсуждается и сегодня очень мало приложений, которые используют такой вариант работы.
Процесс не быстрый, вот например Bug report в Debian от 2004 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274229 исправлен он был только в 2010, потому что исправлять такие баги очень сложно, на них уже завязано куча всего, и просто так выпилить не получается.

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