Комментарии 89
Интересная статья :)
В свое время схожим образом автоматизировал через VBA-скрипты, когда множество отделов присылали разнородные данные, которые требовалось нормализовать.
Самое сложное из практики не автоматизировать, а не повредить данные.
Как с этим боролись? :)
Читать было приятно, но не могу отделаться от ощущения, что это либо перевод, либо AI-слоп
Вот тошно уже, если честно, даже в человеческой в остальном статье, про личный опыт, видеть этот гптшный слог. Ну напиши ты своими словами как угодно, криво-косо, всё лучше будет, чем это.
Очень хочется через нейросетку статьи редачить и воды в них доливать - дообучи её на своих старых текстах, да хоть чатах в мессенджере. Чтоб хоть какая-то индивидуальность была.
Наша задача заключалась в нормализации этих данных и импорте их в систему. Процесс включал в себя открытие каждого файла, проверку колонок, переименование заголовков, проверку форматов и ручное копирование данных в мастер-таблицу. Всё это занимало 4–6 рабочих дней каждый квартал.
В далеких 90-х и нулевых, когда фразы, типа "тыж программист? принтер чтото не печатает" и "кажется у меня в компьютере микроб, дискетки долго читает" были совсем не редки, и то, юзеры маленьких компаний, которым повезло иметь в штате админа, знали к кому бежать для автоматизации подобной рутины, а уж сами айтишники на нудятину вроде вручную загловки править, или чтоб внутри табличек данные нормализовать (например, из сумм убирать окончания вроде "р." если таковые встречаются), больше 15 минут не тратили, т.к. становилось понятно, что лучше один раз процесс автоматизировать и потом всегда эту автоматизацию использовать.
А теперь, приходится только песком сыпать и смотреть как нонешние айтишнеги готовы заниматься бесполезным ручным трудом целые дни, а потом еще и статью писать на то как на погромиста озарение нашло, что оказывается можно программу написать для автоматизации ручного труда, кто бы мог подумать.
Есть обратная сторона тех самых админов и тыжпрограммстов из 90х: "зачем делать вручную за 10 минут, если можно потратить 8 часов на автоматизацию и ещё 20 на ловлю глюков". Думаю каждый в своей карьере с таким сталкивался. Экслер в "дневнике невесты программиста" это очень точно запечатлел)
"зачем делать вручную за 10 минут, если можно потратить 8 часов на автоматизацию и ещё 20 на ловлю глюков"
Затем что автоматизация это не только экономия времени, но еще и защита от дурака человеческого фактора. Плюс бонусом идет по сути документирование процесса, да кодом, да словами в БЗ было бы быстрее, но главное след остается.
nano + bash намного сложнее чем python + pandas + jupyterlab с авто дополнением и подсказками. Примерно как 10:1. Хорошо что не стали задерживаться на неудобном решении.
На pandas реально в 20 строк кода уместить весь пайплайн из статьи. При этом 15 строк даст любой AI- помогатор или беглый гуглеж/чтение примеров из документации.
Одно только экранирование кавычек в bash bat ps скриптах может легко удвоить время кодинга.
да, ну.. кавычки - наше всё. двойные, одинарный, "обратные" - это уже на автомате. все эти qw //, qr //, qq //... один раз разобрался и не соскочишь уже
А вы точно статью читали?
Покажите свой вариант скрипта из статьи на питоне?
import glob, pandas as pd
out = pd.DataFrame()
for file in glob.glob('./raw_data/*'):
out = pd.concat([out, pd.read_csv(file, sep=';|,', engine='python', usecols=['Name', 'Email', 'DOB'])], axis=0)
out.to_csv('./merged/cleaned.csv')
На написание кода выше ушло примерно 3 минуты. На экранирование кавычек в Bash, чтение манов к grep, sed и awk уйдет полчаса.
Но даже 3 минуты непозволительно много. Потому что эти 5 строк в буднях дата-аналитика вызываются вот так:
from my_lib import *
df = csv_loader()
Сделать нечто подобное на Bash тоже можно, но ценой кратного роста трудозатрат. Однако основной выигрыш от Python не во времени. Добавив всего 3 строки docstrings+doctest можно одной командой экспортировать в модуль my_lib из блокнота Jupyter все свои 20-летние наработки (сотни UDF), налету их все валидировав и протестировав на ваших же данных. Это CI/CD в чистом виде. Тут Bash точно сольется.
На написание кода выше ушло примерно 3 минуты.
А потом вечность на разборки с зависимостями, венв и прочим ужасом питона
Добавлю ещё, что пандас будет грузить в память. И много больших csv уронят скрипт напрочь.
Я бы писал на питоне без сторонних библиотек, особенно без пандаса. Довольно просто написать поточную обработку и можно обойтись без venv.
Разборки с sed, awk и bash - это другое, да.. Не ужас-ужас, а так, просто ужас (ц) :)
А что с зависимостями? pip сломался?
За свой небольшой опыт с питоном на уровне пользователя бегло пробежался по истории поиска и нашел вот такие кейсы:
ImportError: cannot import name 'escape' from 'jinja2'
Microsoft Visual C++ 14.0 or greater is required
С баш-скриптами такой беды не помню
С баш-скриптами такой беды не помню
написать на bash чего-то подобного этому jinja2, наверное, было не просто.
У Python 500k+ пакетов с миллионами "звезд" , у Bash 0, причина отсутствия ошибок прячется где-то тут.
Ошибки при импорте или при сборке сторонних либ в python - да, случаются. Но только их наверняка спровоцировал сам пользователь - обновил, не глядя, крупную системную либу, поленился набрать uv venv test2 (создать окружение, которое даже не надо активировать) или просто тупанул, скопировав непонятно откуда pip-строку. Это все лечится через болезнь, на третий раз появится чувство гигиены и осторожности и проблема исчезает.
Зря пугаете новичков "ужасами питона", особенно взаимоисключающими.
Я 10 лет обновляю ежедневно ~500 либ в production-среде, и лишь трижды ловил настоящую поломку зависимостей, это минут на 10 ступора. За это же время среды С++, NodeJS и даже Java были кратно проблемнее, и ступор длился сутками.
На pandas сейчас пишут даже системные утилиты в системном же python в Linux, никакой venv не нужно (под Windows - тем более). Предлагаю проверить "вечность" на каком-нить небесполезном кейсе, в результате уверен.
Вообще-то нет
Это сложнее если вам надо сделать один Мега скрипт для обработки всех данных.
Кстати, закрадываются сомнения что автор смог решить проблему одним Мега скриптом.
Обычно каждый поставщик данных имеет свой уникальный формат и способ передачи данных.
Решал такую проблему тупо созданием скриптов на поставщика/ источник данных.
Далее раскидывал данных по папкам структура была типа
Supplier-name/in, ./out, ./scripts
Соотвественно скрипты для этого конкретного клиента хранились рядом с данными. Разбираться и править баги было проще. Опять таки, лучше для этих целей использовать awk а не чистый bash.
Кстати я там делал выборку данных из xlsx файлов, благо это xml запакованный zip-ом.
Решал такую проблему тупо созданием скриптов на поставщика/ источник данных.
Классическая plugin «магазинная» архитектура. Там ещё нужно легко удалять эти обработчики, и соблюдать баланс между общим и частным.
В Python (и вообще во всем структурно-модульно ориентированном) - мегаскрипты не нужны, вредны и опасны. Нужна своя либа из отдельных UDF-функций (пример выше) и что-то изящное для "ручного" описания данных, например на кристально ясно читаемом языке YAML.
Утилиты типа grep/awk/sed заметно уступают быстрым pandas-методам в скорости на "толстых" файлах в десятки гигабайт (под капотом С/С++/Fortran и колоночные алгоритмы Apache Arrow). А если добавить типичной офисной "дичи" (разные кодировки, BOM/тирлим-бом-бом, офисные форматы excel/ods/txt/csv/tsv, и насущную необходимость быстро класть результат в БД как партицию за сутки) - Bash станет просто невыносим. Pandas с DuckDB/SQLite будут удобнее и в 4-6 раз быстрее в исполнении.
Наоборот, с pandas все становится медленным и хрупким.
Так может проверим? Правда если применять в дискуссии не-IT эпитеты типа "хрупким" - дела не будет.
Я для себя все давно все проверил. Чего мне с вами спорить?
В вашем же скрипте выше видно, что это по памяти будет вылетать на мало-мальски больших csv. Вдобавок, рост dataframe в цикле - это уж совсем плохая практика. Хотя бы уж append к результирующему csv делали вместо конкатенции.
Тут согласен, надо собрать список [df1, df2...] и за один прием pd.concat(). Но вылетит оно при RAM 16GB лишь на десятках десяти гигабайтных csv. А вот pd.append() советовать уже год как нельзя, deprecated.
Любой код сломается, если в данных дичь. Но на pandas можно заранее накодить конверторов и Jupyter позволяет это сделать комфортно. Удел bash + nano все таки поскромнее, несколько команд. ETL процессы не для него.
если пандас медленно, используйте polars
Я когда-то работая в детском стационаре, став заведующим столкнулся с месячными отчётами, которые в тот момент выглядели как ручное подсчитывание по журналу множества показателей. С отчетом за один месяц ещё можно было управиться за один вечер, но когда подошел срок квартального, начался ад. Со старшей медсестрой чуть не поругались. Нужно было много чего соединять, пересчитывать. В общем дал себе слово к следующему отчёту написать программу. Из прикладных более менее знал C#, базу данных выбрал ms access, т.к. и доступ удобный оказался, и поиск по русским символам работал. За месяц примерно допилил.
Медсестры которые раньше занимались этой каторгой готовы были расцеловать меня. Другие заведующие смотрели с завистью как я составляю полугодовой отчёт за 3 секунды. Но перейти на мою методику чё то не осилили. Так что внедряйте полезный софт, товарищи
Но перейти на мою методику чё то не осилили.
Ну а сейчас-то, с помогающими и любезными нейросетевыми помощниками осилили бы? Правда ведь?
Вообще последний параграф заставил вспомнить меня одно из видео @muxa_ru (вроде это) про оптимизацию производства введением в эксплуатацию инструмента "бензопила"... или не введением (может электро? не суть). Вкратце усвоил для себя так: не нужоны нам ваши пилы, как пилили годами, так и будем продолжать. И такие элементы бывали.
Когда любое новаторство натыкается на штыки. Это отношение становится в коллективе нормой, никому ничего не надо. Лишь бы не трогали и давали работу делать (абы как, медленно, мы так привыкли). Со временем, чтобы вообще не трогали работу не делать. С активным противодействием, или как бы раньше назвали: вредительством. @GreenestGiant
Ад ручной обработки данных
Да уж, доводилось заниматься.
Bash недооценён
А то.
"глупый" скрипт
Ежели работает, чего ж он "глупый"?
Последнее время обязательно перегоняю bash скрипы через DeepSeek.
Он отлично добавляет необходимые проверки и прочие вещи, которые самому лень делать.
Вот, например, что-то порядка 200 баш скриптов прогнанных через DeepSeek.
Пришлось полу-автоматизировать эту процедуру.
https://github.com/x2v0/lfspd/
Если б я в своё время не додумался до автоматизации скриптами. Я бы точно работал на другой работе.
Сенсация! Программист додумался написать скрипт! Срочно в номер! :)
С этими автоматизациями некоторые уже "доигрались", шеф прознал что сисадмин бухам половину автоматизировал, и львиную часть своей работы. И сократил часть бухов и того сисадмина.
Ничего не напоминает, как сейчас на ИИ все взвалить хотят задешево? А поставщики ИИ взяли и взвинтили цены. Хехе. Ну и правильно.
сисадмин бухам половину автоматизировал,
куул стори ;) специальные 1Сники автоматизируют да никак не выавтоматизируют. А а тут проходящий мимо сисадмин одним скриптом все задачи порешал ;)
сократил часть бухов и того сисадмина.
У этой басни ещё продолжение было.. шеф через полгода умолял того сисадмина вернуться, а то автоматизация чего-то сломалась, сама себя не чинит, а разобраться в ней никто не умеет.
В финале наш отдел упрозднили ! Аффтоматизацыя рулит !!!
На баше тяжелее писать, чем на условном питоне из-за отсутствия автодополнения и режима отладки. Удачи тем, кто будет это все поддерживать, как грица
Какая вам @$#@_ отладка? Реально мне делать нечего как по шагам смотреть. Логи - наше всё.
Я могу понять, если бинарник или обфусцированный код, но реально в дебагере смотреть свой код по шагам? Вы настолько не понимаете, что этот код делает? Ну тогда только рефакторинг.
Зачем по шагам? есть условные break points, есть возможность менять переменные, есть возможность следить за указанной переменной.. есть вещи, которые удобно делать дебагером.
Какие логи в скрипте на 100 строк? Конечно обычно я так и делаю через echo, но лучше был бы отладчик, который позволял бы остановиться и подумать в моменте. А если код не мой? И вообще его писал условный девопс/тестировщик/и тд, который ни разу не программист и пишет код просто, чтобы написать?
echo... Тем более когда пишешь не пайп-пайп-пайп, а начинаешь дробить вывод на переменные, чтобы понять, в каком месте что-то пошло не так. А затем уже перестаешь писать пайп-пайп-пайп, потому что наперед знаешь, что если напортачишь - придется разбираться и переписывать, чтобы выловить вывод команды в моменте.
Форматы файлов:
.xls,.xlsx,.csv
Извините, но это всё под экселем. Здесь, наверняка, более корректным решением будет Power Query / Power BI. Корректнее, потому что ни одна строка не останется без внимания с точки зрения синтаксиса Эксель. На выходе получится суммарная "простыня" для загрузки в базу.
Если вы программист/разработчик, тема будет явно залипательная, попробуйте. Мне помогло автоматизировать сбор отчётных данных с отделов. Да и просто интересно было.
Любая автоматизация начинается с малого. Главное начать.
Про bash vs python вы пишете что для питона:
Требовалась изолированная среда
Нужно было настраивать зависимости и версии
На мой взгляд странные аргументы. Можно писать на 3м питоне без использования фич новых версий питона и экзотических библиотек. Просто скрипт начнется с '#!/usr/bin/pyton' и вся разница. На мой взгляд дело в другом. В баше проще работать со списками файлов, пайпами и дергать внешние инструменты типа sed, awk, и.т.д. Зато в питоне можно перебирать строки руками и есть структуры данных из коробки.
Что то похожее было в организации, где один отдел должен был передавать в бухгалтерию инфу для бухгалтерии для выплаты з.п. ~700 сотрудникам на договорах ГПХ. Ежемесячно два раза. Контур экстерн не предусмотрел загрузку данных из excel, который отдел был в состоянии выгрузить из ИС, а за доработку выкатил счёт на 60 тысяч. Бухи попробовали руками вбивать договора, это заняло 2 дня. В итоге я написал CMD, который конвертирует XLSX в XML, поддерживающийся Контуром. Теперь такая конвертация занимает 30 секунд:
Вот тут подробнее рассказывала youtube.com/watch?v=_UtmfYw5ibU
за доработку выкатил счёт на 60 тысяч
непрокатило
В итоге все в выигрыше: Экстерн сэкономил время своих разработчиков, делая фичу, нужную только одному клиенту. Клиент сэкономил 60 тысяч. Win-win)
Если задача решена несложным скриптом, значит не было там 60000. Просто заградительная цена. 2000 просить несерьёзно: заказчик может решить, что и прочие услуги стоят недорого.
Несколько дней работы разработчика, тестирования тестировщиком. Сверху менеджер для постановки задач, еще отдел по работе с клиентами не забываем. Ну а вишенкой гарантийное обслуживание с бесплатной починкой багов (ака неучтенных бизнес-кейсов).
Допустим пять человеко-дней суммарно. 60к / 5 дней / 8 часов = 1500р/час. Я даже не уверен что какая-нибудь столичная контора без сотрудников на удаленке возьмется за такое.
За две тысячи рублей вам только студент-фрилансер возьмется делать. Для фирмы такое явно ниже себестоимости будет.
Вы пересказали анекдот про непрокатило, но на менеджерском диалекте. Какие несколько дней работы разработчика, если задача решается несложным скриптом? Вряд ли автор писал его несколько дней без отрыва. Скорее несколько часов. Но в трекер запишется несколько дней. Что там тестировать несколько дней? Это же тупой фильтр. Ваши тестировщик не умеют в автоматизацию? Собственно, автотестов должно хватить, но нельзя же QA оставлять без работы, они тоже хотят кушать.
Конечно же, всю эту ораву менеджеров тоже нужно кормить.
Всегда так делаю. Баш - он же по сути своей "напиши то что делаешь руками и запусти"
Bash + библиотека и иерархия зависимостей классов с зависимостями в .txt и .png готова, перевод с одного языка на другой облегчила жизнь.
Только размер картинки адовый получился, мало какая программа просмотра могла открыть
Простите, а где здесь bash? «for … in»? grep — как говорится, вот он, sed — как говорится, вот он, awk, одна штука — вижу. А bash-то где?
В итоге мы переписали скрипт в виде Python CLI / на Python:
с логированием, обработкой ошибок и тестами.
Маппинга полей через YAML
Определения и нормализации форматов даты и телефонов
Логирования и итоговой статистики
Базового интерфейса для нетехнических сотрудников
Простите, а всё-таки зачем? Всё то же самое позволяет делать баш. В своё время я как раз не стал вот этот весь питон использовать в том числе потому что "Bash был доступен, быстр в тестировании, уже установлен везде." - банально новая машина, не надо вспоминать какие библиотеки с кем дружат и в какой последовательности их надо устанавливать (да возможно сейчас питон уже ушёл от этой проблемы). Собственно для таких задач как переменные_во_внешнем_файле/парсинг/логирование/использование_операционистами переход на питон и является по сути "переписывали его во фреймворк.".
Вы питоном похоже в 2008 последний раз пользовались. Потом pip появился.
Наверное Вы правы, где-то 2008-2012, но тогда смотрел под виндой в том числе для кросс-платформенности (уроки Джавы не пошли впрок). В те же года + несколько лет после наслышан об идеальной несовместимости 2 и 3 версий, и окончательно плюнул на него. Пока за всё время не сталкивался с необходимостью именно питона, все задачи прекрасно решались на встроенных нативных средствах - баш, пш.
О, пока писал вспомнил, один раз пару лет назад он понадобился и я повторил прекрасное время, что скрипт требовал исключительно версию 2 питона, а под ней исключительно специальную версию дополнительной библиотеки (более новая на 2 минорных старше не подходила естественно и пип тут же отвалился), которую тоже поискать пришлось. В итоге подружив вот это вот всё вместе за несколько часов я выяснил что оно не работает. А связавшись с автором выяснил, что почему-то в связке питона с этой библиотекой есть какая-то несовместимость с лгбт-виндой.
об идеальной несовместимости 2 и 3 версий
Для самописных скриптов это неважно. А чужие.. Программу под qt4 на qt5 тоже не просто запустить.
с лгбт-виндой
бригаду, срочно.
Для самописных скриптов это неважно. А чужие.. Программу под qt4 на qt5 тоже не просто запустить.
Дада, а ещё очень сложно вайн под виндой запустить. Да и зачем?
Действительно, зачем запускать скрипты от python2 на python 3? Ну несовместимые. Ну и ладно. Свои прогоните через 2to3, чужие оставьте как задумано автором. Если оно актуально - он их уже переписал. Если нет.. Любителям археологии приходится страдать ;)
Много ответов есть на "зачем". Как правило самый актуальный "надо". И такой ответ будет всегда потому что из опыта ты несколько часов будешь объяснять человеку то что накопал сам потратив ещё несколько часов до этого просто затем чтоб он пожал плечами "ну да невозможно, нужно искать воркэраунд". Спрашивается зачем ты тратил эти несколько часов объясняя?
Переписывание виндового Log Parser (exe) на питоне ускорило обработку логов для начала раз в 50 (текстом: пятьдесят) и позволило обрабатывать столько логов, сколько в Log Parser просто не помещалось. оно не настолько универсальное в части возможных форматов, но то, что обрабатывает, обрабатывает на порядки быстрее.
Когда мне надоело тонны логов парсить лог парсером (время + обработка входящих) я переписал быстрей на ПШ и стало да действительно быстрей. Опять же с питоном не могу сравнить. Но при этом плюсы остались теми же - я мог отправить скрипт админам в двойном закрытом контуре госов и они мне могли прислать результат что получилось из логов. При этом мне не надо было им объяснять ну скачайте питон (ага, за второй закрытый контур обмазанный ФСТЭК-ом) и не надо им объяснять почему им надо скачать тонну логов из-за закрытого контура (а в логах могет быть чувствительная инфа) и потом туда куда скачали накачать питонов.
Код на Bash/PS с логированием парсинга, YAML, валидацией и нормализацией данных и web-GUI с логами и статистикой - будет в сотни раз многострочнее, чем на Python. Неудивительно что на Python таких примеров - десятки тысяч (блокнотов Jupyter на github, kaggle итд), а на Bash - ни одного. Но сделать - да, позволяет.
Наверное Вы правы, мне проверить данное утверждение сложно, т.к. питон я не знаю, но на баше чтение переменных из файла буквально одна строка. Валидация ещё одна * на кол-во переминных, я конечно исключаю пограничные случаи когда в поле "дата" пишут "сейчас" или по современным тенденциям "пять минут назад". и т.д.
Ну и про десятки тысяч примеров, тут будет неудивительно просто потому что питон появился одним из первых, когда лучшее что было это цмд ну или если повезёт собрать линукс собственно сам баш когда ещё rm -rf / можно было выполнить.
на баше чтение переменных из файла буквально одна строка
Если учесть, что диалектов csv значительно больше чем 1, то на python это таки будет те же 2 строки, а на bash - немаленькая простыня.
питон я не знаю
раньше этим не гордились ;) (ц)
Если учесть, что диалектов csv значительно больше чем 1, то на python это таки будет те же 2 строки, а на bash - немаленькая простыня.
Если учесть, что ксв это простой файл с делимитерами и эскейпингом, то немаленькая простыня это та же 1 строка + 2 для переменных, или плюс 1 которая запрашивает у пользователя ввести их.
раньше этим не гордились ;) (ц)
раньше жопы подтирали ветками и листиками, главное в борщевик не попасть.
раньше жопы подтирали ветками и листиками,
Точно подмечено ;) А сейчас нам доступны библиотечные функции, написанные и оттестированные умными людьми. Выпиливать из bash и awk свои способы парсить unquoted string, quoted string, escaped quotes, double quotes .. Ну, нравится наверное.
Дада, я вот это люблю библиотечные функции, когда несколько людей убивают 7+часов времени чтобы подружить или запустить библиотеки ради того, чтоб выполнить функцию, которую можно переписать за час-полтора (реальный опыт). А потом удивляются что у нас всё распухло и перемазано фреймворками. Да потому что ради хелловорлда надо накачать 18+гигов студию, 3+ гига всякие гиты-докеры и 500МБ+ всяких библиотек и зависимостей. Но да, мы доверяем какому-то "анониму", что он натестировал лучше вкупе с остальными людьми, а потом находя багу в своей имплементации либо долго ноем прося исправить либо записываемся в программисты пытаясь собрать пазл на китайском языке.
Возвращаясь к тому что писал - для файлов из внутренних одинаковых постоянных источников нет необходимости пытаться обыграть запуск скрипта при свете венеры сквозь тень марса во время парада планет и наступления 2000 года. Иногда дата это просто дата и тот кто выгружает чтоб послать файл не будет сегодня выгружать так, а завтра заскучая выгружать по-другому.
Как раз мой случай
Мне понадобилось записать логи с последовательного порта устройства, чтобы отловить программную проблему, но при подключении к компьютеру и подключении терминальной программы давался сигнал сброса на устройство, и багу при таких обстоятельствах не отловить. Плюс, ноутбук оставлять в укромном месте, чтобы только собирал логи - жирно и неудобно. В итоге на одноплатнике запустил 3 bash-скрипта и 2 udev-правила.
Один скрипт - собственно логирование порта, который завершает свою работу, если порт отключается, другой - чистит логи старше 30 дней, а третий - копирует логи на флешку, если она с именем USBLOGS.
Первое udev-правило - запускает скрипт, если видит подключение ttyACM или ttyUSB, а второе - при обнаружении флешки с меткой USBLOGS запускает скрипт на копирование логов. При этом, скопировалось или нет, можно отсмотреть только по индикатору на флешке.
Такое решение помогло отловить проблему.
Первое решение могло логировать только один порт (скрипт работал постоянно, не было udev-правила и складывал только в одну папку). Сейчас решение умеет логировать несколько портов, разделяя логи по папкам с именем НазваниеПорта_СерийныйНомер.
Сейчас этот логгер отдал испытателю, чтобы собирал логи и в случае чего их снял и передал мне на анализ, но у меня уже появилась идея улучшенной версии и ОС для логгера, и программы для логгирования, которую хочу написать на C/C++.
А еще есть волшебная вещь, стандартизация на клиентской стороне, плюс простые обработчики на вашей и вот оно счастье.
Боже, о чем статья? “Я сделал простой скрипт, он мне помог, круто”? Автор точно программист? Люди обычно такой восторг испытывают в первый год работы, а потом как-то утихает радость по баш-скриптам, потому что задачи начинаются сложнее и такие мини-тулзы уже пишутся на автомате и не считаются чем-то заслуживающим внимания, ну тулза и тулза, сегодня написал, завтра забыл.
У законодателей бы был такой восторг от "я провел новый закон/отменили старый, теперь бумажкописательства станет меньше, круто". Может и не совсем программист? А статьи и такие нужны, чтобы побуждать к действию. Даже при помощи матерей разных оттенков кожи и переписки с LLM.
когда-то из таких маленьких радостей начинался путь программиста. И удовольствия от таких задач было как бы ни больше, чем от больших рутинных проектов
Как один глупый Bash-скрипт сэкономил нам 100 часов ручной работы