Есть некоторая ирония в том, как простые инструменты решают сложные задачи. Пока технические форумы гудят от обсуждений Kubernetes, пайплайнов машинного обучения и микросервисных архитектур, я хочу на минуту отвлечься и поговорить о чем-то до безобразия простом: Bash-скрипте. Не особенно изящном. Без функций. Без параметров. Без проверок корректности. Просто линейный, безжалостно прагматичный shell-скрипт, который за год сэкономил нам несколько недель работы.
Это история не о красоте кода, а об его полезности. Не о совершенстве, а о решении реальных проблем в условиях нехватки времени, терпения и мотивации команды. Если вы разработчик, системный администратор, специалист по данным или просто устали от рутинных задач — этот пост для вас.
Исходная точка: Ад ручной обработки данных
Мы работали с партнёрской организацией, которая по историческим причинам настаивала на передаче данных в виде таблиц. И не одной чистой таблицы — сотен. Ежеквартально мы получали более 200 файлов от разных отделов. У каждого были свои особенности:
Заголовки колонок отличались: "Name", "First Name", "FName"
Форматы дат варьировались между американским (MM/DD/YYYY) и европейским (DD/MM/YYYY)
Форматы файлов:
.xls,.xlsx,.csvИногда данные вообще присылались в теле письма
Наша задача заключалась в нормализации этих данных и импорте их в систему. Процесс включал в себя открытие каждого файла, проверку колонок, переименование заголовков, проверку форматов и ручное копирование данных в мастер-таблицу. Всё это занимало 4–6 рабочих дней каждый квартал.
Точка невозврата
После ещё одной бессмысленно потраченной пятницы, когда я вручную чистил кривые CSV-файлы, я не выдержал. Открыл терминал и ввёл nano normalize.sh. Я не знал, как будет выглядеть этот скрипт, и, честно говоря, мне было всё равно. Мне просто хотелось хоть чего-то, что избавит меня от этой рутины.
Единственное требование: он должен работать. Даже если будет хрупким. Даже с жёстко зашитыми путями. Даже если он будет глупым. Боль бездействия была хуже, чем риск сделать неидеально.
Первая версия
Вот как выглядел самый первый вариант:
#!/bin/bash
INPUT_DIR="./raw_data"
OUTPUT_FILE="./merged/cleaned.csv"
# Start with header
echo "Name,Email,DOB" > $OUTPUT_FILE
for file in "$INPUT_DIR"/*; do
cat "$file" | \
grep -v -i "name\|first name\|fname" | \
sed 's/;/,/g' | \
awk -F',' '{print $1","$2","$3}' >> $OUTPUT_FILE
doneЧто делал этот скрипт:
Открывал каждый файл из заданной папки
Удалял заголовки по типичным ключевым словам
Преобразовывал точки с запятой в запятые
Извлекал и выводил первые три столбца
Это было надёжно? Нет. Покрывало все случаи? Тоже нет. Но за считанные минуты мы получали пригодный для импорта CSV-файл. Это дало нам импульс.
Быстрые победы
Мы сразу заметили несколько плюсов:
Экономия времени: вместо 4–6 дней — менее часа
Стабильность: даже базовый скрипт действует одинаково каждый раз
Масштабируемость: новые файлы? Просто добавь и запусти снова
Повышение морального духа: команда могла тратить время на анализ данных, а не на копирование
Мы начали постепенно улучшать скрипт. Не переписывали его во фреймворк. Не делали микросервис. Просто добавляли нужные штуки:
Регулярки для нормализации форматов даты
Проверка и пропуск проблемных строк
Обработка ошибок при неудачной загрузке файла
Отправка email-уведомления через
mailxпри завершении
Позже мы сделали обёртку, чтобы младшие специалисты могли запускать его одной командой.
Почему не Python или Pandas?
Отличный вопрос. В итоге — да, мы перешли на них.
Но на старте Python был препятствием:
Требовалась изолированная среда
Нужно было настраивать зависимости и версии
Сложнее и дольше итерации
Люди, выполнявшие задачу, не были разработчиками
Bash был доступен, быстр в тестировании, уже установлен везде. Это оказалось важнее красоты. Со временем, когда процесс стабилизировался, мы переписали его на Python — с логированием, обработкой ошибок и тестами.
Но прорыв дал именно тот первый Bash-скрипт. Он доказал, что автоматизация возможна. И сэкономил нам недели работы, пока мы создавали замену.
Чему мы научились
1. Лучший инструмент — тот, который ты будешь использовать
Забудьте про тренды и холивары. Если вы можете автоматизировать задачу сегодня с помощью Bash — делайте это. Идеальный стек может так и не прийти.
2. Не бойтесь несовершенства
Первая версия не обязана быть чистой. Даже хорошей. Главное — чтобы она уменьшала боль. Остальное можно доделать потом.
3. Решайте свои проблемы, а не абстрактные задачи
Мы не планировали строить пайплайн. Мы хотели перестать тратить пятницы на одно и то же. Это стало нашим ориентиром.
4. Bash недооценён
Для одноразовых скриптов, парсинга логов, работы с файлами и пайплайнов — Bash до сих пор один из самых эффективных инструментов. Он портативен, быстр и мощен в умелых руках.
5. Документация — это важно
Когда скрипт начали использовать другие, мы добавили простой README, структуру папок (raw_data/, merged/, logs/) и понятные комментарии. Этого оказалось достаточно, чтобы превратить личную поделку в командный актив.
Что было дальше
В итоге мы переписали скрипт в виде Python CLI с поддержкой:
Маппинга полей через YAML
Определения и нормализации форматов даты и телефонов
Логирования и итоговой статистики
Базового интерфейса для нетехнических сотрудников
Но до этого мы бы не дошли без скромного Bash-скрипта. Он визуализировал процесс, дал нам уверенность и поддержку команды.
Даже сейчас, в экстренных ситуациях или при одноразовых задачах, мы клонируем и используем именно его. Он стал нашим прототипом по умолчанию.
Заключение
Индустрия обожает сложность — новые фреймворки, архитектуры, подходы. Но в реальных командах самые большие выигрыши приходят от беспощадно простых решений.
Этот Bash-скрипт не был умным, красивым или масштабируемым. Но он работал. А это, порой, важнее всего.
Если у вас есть задача, которая постоянно отнимает время — попробуйте сначала решить её глупо. Откройте терминал. Напишите самое простое решение. Доработаете позже. Главное — сделать это сегодня.
Вполне возможно, что именно этот "глупый" скрипт окажется самым умным вашим решением за год.
Комментарии (56)
mSnus
18.07.2025 15:28Читать было приятно, но не могу отделаться от ощущения, что это либо перевод, либо AI-слоп
Sabiko
18.07.2025 15:28Вот тошно уже, если честно, даже в человеческой в остальном статье, про личный опыт, видеть этот гптшный слог. Ну напиши ты своими словами как угодно, криво-косо, всё лучше будет, чем это.
Очень хочется через нейросетку статьи редачить и воды в них доливать - дообучи её на своих старых текстах, да хоть чатах в мессенджере. Чтоб хоть какая-то индивидуальность была.
Politura
18.07.2025 15:28Наша задача заключалась в нормализации этих данных и импорте их в систему. Процесс включал в себя открытие каждого файла, проверку колонок, переименование заголовков, проверку форматов и ручное копирование данных в мастер-таблицу. Всё это занимало 4–6 рабочих дней каждый квартал.
В далеких 90-х и нулевых, когда фразы, типа "тыж программист? принтер чтото не печатает" и "кажется у меня в компьютере микроб, дискетки долго читает" были совсем не редки, и то, юзеры маленьких компаний, которым повезло иметь в штате админа, знали к кому бежать для автоматизации подобной рутины, а уж сами айтишники на нудятину вроде вручную загловки править, или чтоб внутри табличек данные нормализовать (например, из сумм убирать окончания вроде "р." если таковые встречаются), больше 15 минут не тратили, т.к. становилось понятно, что лучше один раз процесс автоматизировать и потом всегда эту автоматизацию использовать.
А теперь, приходится только песком сыпать и смотреть как нонешние айтишнеги готовы заниматься бесполезным ручным трудом целые дни, а потом еще и статью писать на то как на погромиста озарение нашло, что оказывается можно программу написать для автоматизации ручного труда, кто бы мог подумать.
Newbilius
18.07.2025 15:28Есть обратная сторона тех самых админов и тыжпрограммстов из 90х: "зачем делать вручную за 10 минут, если можно потратить 8 часов на автоматизацию и ещё 20 на ловлю глюков". Думаю каждый в своей карьере с таким сталкивался. Экслер в "дневнике невесты программиста" это очень точно запечатлел)
NAI
18.07.2025 15:28"зачем делать вручную за 10 минут, если можно потратить 8 часов на автоматизацию и ещё 20 на ловлю глюков"
Затем что автоматизация это не только экономия времени, но еще и защита от
дуракачеловеческого фактора. Плюс бонусом идет по сути документирование процесса, да кодом, да словами в БЗ было бы быстрее, но главное след остается.
economist75
18.07.2025 15:28nano + bash намного сложнее чем python + pandas + jupyterlab с авто дополнением и подсказками. Примерно как 10:1. Хорошо что не стали задерживаться на неудобном решении.
На pandas реально в 20 строк кода уместить весь пайплайн из статьи. При этом 15 строк даст любой AI- помогатор или беглый гуглеж/чтение примеров из документации.
Одно только экранирование кавычек в bash bat ps скриптах может легко удвоить время кодинга.
D_Dementy
18.07.2025 15:28да, ну.. кавычки - наше всё. двойные, одинарный, "обратные" - это уже на автомате. все эти qw //, qr //, qq //... один раз разобрался и не соскочишь уже
mc2
18.07.2025 15:28А вы точно статью читали?
Покажите свой вариант скрипта из статьи на питоне?
economist75
18.07.2025 15:28import 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')economist75
18.07.2025 15:28На написание кода выше ушло примерно 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 точно сольется.
Kahelman
18.07.2025 15:28Вообще-то нет
Это сложнее если вам надо сделать один Мега скрипт для обработки всех данных.
Кстати, закрадываются сомнения что автор смог решить проблему одним Мега скриптом.Обычно каждый поставщик данных имеет свой уникальный формат и способ передачи данных.
Решал такую проблему тупо созданием скриптов на поставщика/ источник данных.Далее раскидывал данных по папкам структура была типа
Supplier-name/in, ./out, ./scripts
Соотвественно скрипты для этого конкретного клиента хранились рядом с данными. Разбираться и править баги было проще. Опять таки, лучше для этих целей использовать awk а не чистый bash.
Кстати я там делал выборку данных из xlsx файлов, благо это xml запакованный zip-ом.
vkni
18.07.2025 15:28Решал такую проблему тупо созданием скриптов на поставщика/ источник данных.
Классическая plugin «магазинная» архитектура. Там ещё нужно легко удалять эти обработчики, и соблюдать баланс между общим и частным.
economist75
18.07.2025 15:28В Python (и вообще во всем структурно-модульно ориентированном) - мегаскрипты не нужны, вредны и опасны. Нужна своя либа из отдельных UDF-функций (пример выше) и что-то изящное для "ручного" описания данных, например на кристально ясно читаемом языке YAML.
Утилиты типа grep/awk/sed заметно уступают быстрым pandas-методам в скорости на "толстых" файлах в десятки гигабайт (под капотом С/С++/Fortran и колоночные алгоритмы Apache Arrow). А если добавить типичной офисной "дичи" (разные кодировки, BOM/тирлим-бом-бом, офисные форматы excel/ods/txt/csv/tsv, и насущную необходимость быстро класть результат в БД как партицию за сутки) - Bash станет просто невыносим. Pandas с DuckDB/SQLite будут удобнее и в 4-6 раз быстрее в исполнении.
axmed2004
18.07.2025 15:28Я когда-то работая в детском стационаре, став заведующим столкнулся с месячными отчётами, которые в тот момент выглядели как ручное подсчитывание по журналу множества показателей. С отчетом за один месяц ещё можно было управиться за один вечер, но когда подошел срок квартального, начался ад. Со старшей медсестрой чуть не поругались. Нужно было много чего соединять, пересчитывать. В общем дал себе слово к следующему отчёту написать программу. Из прикладных более менее знал C#, базу данных выбрал ms access, т.к. и доступ удобный оказался, и поиск по русским символам работал. За месяц примерно допилил.
Медсестры которые раньше занимались этой каторгой готовы были расцеловать меня. Другие заведующие смотрели с завистью как я составляю полугодовой отчёт за 3 секунды. Но перейти на мою методику чё то не осилили. Так что внедряйте полезный софт, товарищи
VADemon
18.07.2025 15:28Но перейти на мою методику чё то не осилили.
Ну а сейчас-то, с помогающими и любезными нейросетевыми помощниками осилили бы? Правда ведь?
Вообще последний параграф заставил вспомнить меня одно из видео @muxa_ru (вроде это) про оптимизацию производства введением в эксплуатацию инструмента "бензопила"... или не введением (может электро? не суть). Вкратце усвоил для себя так: не нужоны нам ваши пилы, как пилили годами, так и будем продолжать. И такие элементы бывали.
Когда любое новаторство натыкается на штыки. Это отношение становится в коллективе нормой, никому ничего не надо. Лишь бы не трогали и давали работу делать (абы как, медленно, мы так привыкли). Со временем, чтобы вообще не трогали работу не делать. С активным противодействием, или как бы раньше назвали: вредительством. @GreenestGiant
axmed2004
18.07.2025 15:28Да не нужны там никакие нейронки. Нужно было просто руками добавлять каждого выписанного пациента в базу ms access
VADemon
18.07.2025 15:28Это сарказм на тему того, что благодаря новым инструментам люди вот-вот начнут делать то, за что раньше бы не взялись. Оказывается, что дело в
кадрахлюдях.
LexD1
18.07.2025 15:28Ад ручной обработки данных
Да уж, доводилось заниматься.
Bash недооценён
А то.
"глупый" скрипт
Ежели работает, чего ж он "глупый"?
x2v0
18.07.2025 15:28Последнее время обязательно перегоняю bash скрипы через DeepSeek.
Он отлично добавляет необходимые проверки и прочие вещи, которые самому лень делать.
Вот, например, что-то порядка 200 баш скриптов прогнанных через DeepSeek.
Пришлось полу-автоматизировать эту процедуру.
https://github.com/x2v0/lfspd/
Moog_Prodigy
18.07.2025 15:28С этими автоматизациями некоторые уже "доигрались", шеф прознал что сисадмин бухам половину автоматизировал, и львиную часть своей работы. И сократил часть бухов и того сисадмина.
Ничего не напоминает, как сейчас на ИИ все взвалить хотят задешево? А поставщики ИИ взяли и взвинтили цены. Хехе. Ну и правильно.
randomsimplenumber
18.07.2025 15:28сисадмин бухам половину автоматизировал,
куул стори ;) специальные 1Сники автоматизируют да никак не выавтоматизируют. А а тут проходящий мимо сисадмин одним скриптом все задачи порешал ;)
сократил часть бухов и того сисадмина.
У этой басни ещё продолжение было.. шеф через полгода умолял того сисадмина вернуться, а то автоматизация чего-то сломалась, сама себя не чинит, а разобраться в ней никто не умеет.
yaroslavp
18.07.2025 15:28На баше тяжелее писать, чем на условном питоне из-за отсутствия автодополнения и режима отладки. Удачи тем, кто будет это все поддерживать, как грица
Yami-no-Ryuu
18.07.2025 15:28Какая вам @$#@_ отладка? Реально мне делать нечего как по шагам смотреть. Логи - наше всё.
Я могу понять, если бинарник или обфусцированный код, но реально в дебагере смотреть свой код по шагам? Вы настолько не понимаете, что этот код делает? Ну тогда только рефакторинг.
randomsimplenumber
18.07.2025 15:28Зачем по шагам? есть условные break points, есть возможность менять переменные, есть возможность следить за указанной переменной.. есть вещи, которые удобно делать дебагером.
yaroslavp
18.07.2025 15:28Какие логи в скрипте на 100 строк? Конечно обычно я так и делаю через echo, но лучше был бы отладчик, который позволял бы остановиться и подумать в моменте. А если код не мой? И вообще его писал условный девопс/тестировщик/и тд, который ни разу не программист и пишет код просто, чтобы написать?
VADemon
18.07.2025 15:28echo... Тем более когда пишешь не пайп-пайп-пайп, а начинаешь дробить вывод на переменные, чтобы понять, в каком месте что-то пошло не так. А затем уже перестаешь писать пайп-пайп-пайп, потому что наперед знаешь, что если напортачишь - придется разбираться и переписывать, чтобы выловить вывод команды в моменте.
mgairat
18.07.2025 15:28Форматы файлов:
.xls,.xlsx,.csv
Извините, но это всё под экселем. Здесь, наверняка, более корректным решением будет Power Query / Power BI. Корректнее, потому что ни одна строка не останется без внимания с точки зрения синтаксиса Эксель. На выходе получится суммарная "простыня" для загрузки в базу.
Если вы программист/разработчик, тема будет явно залипательная, попробуйте. Мне помогло автоматизировать сбор отчётных данных с отделов. Да и просто интересно было.
Nick0las
18.07.2025 15:28Любая автоматизация начинается с малого. Главное начать.
Про bash vs python вы пишете что для питона:
Требовалась изолированная среда
Нужно было настраивать зависимости и версииНа мой взгляд странные аргументы. Можно писать на 3м питоне без использования фич новых версий питона и экзотических библиотек. Просто скрипт начнется с '#!/usr/bin/pyton' и вся разница. На мой взгляд дело в другом. В баше проще работать со списками файлов, пайпами и дергать внешние инструменты типа sed, awk, и.т.д. Зато в питоне можно перебирать строки руками и есть структуры данных из коробки.
jingvar
18.07.2025 15:28На баше просто нативно и короче обращение к файлам или спискам, но если логика обработки чуть сложнее то ад. Глупо отрицать питон как парсер данных и размахивать башем. Так же как на ансибле этим заниматься.
A1ejandro
18.07.2025 15:28Что то похожее было в организации, где один отдел должен был передавать в бухгалтерию инфу для бухгалтерии для выплаты з.п. ~700 сотрудникам на договорах ГПХ. Ежемесячно два раза. Контур экстерн не предусмотрел загрузку данных из excel, который отдел был в состоянии выгрузить из ИС, а за доработку выкатил счёт на 60 тысяч. Бухи попробовали руками вбивать договора, это заняло 2 дня. В итоге я написал CMD, который конвертирует XLSX в XML, поддерживающийся Контуром. Теперь такая конвертация занимает 30 секунд:
Вот тут подробнее рассказывала youtube.com/watch?v=_UtmfYw5ibU
randomsimplenumber
18.07.2025 15:28за доработку выкатил счёт на 60 тысяч
непрокатило
Newbilius
18.07.2025 15:28В итоге все в выигрыше: Экстерн сэкономил время своих разработчиков, делая фичу, нужную только одному клиенту. Клиент сэкономил 60 тысяч. Win-win)
randomsimplenumber
18.07.2025 15:28Если задача решена несложным скриптом, значит не было там 60000. Просто заградительная цена. 2000 просить несерьёзно: заказчик может решить, что и прочие услуги стоят недорого.
JBFW
18.07.2025 15:28Всегда так делаю. Баш - он же по сути своей "напиши то что делаешь руками и запусти"
PlatinumKiller
18.07.2025 15:28Bash + библиотека и иерархия зависимостей классов с зависимостями в .txt и .png готова, перевод с одного языка на другой облегчила жизнь.
Только размер картинки адовый получился, мало какая программа просмотра могла открыть
CorruptotronicPervulator
18.07.2025 15:28Простите, а где здесь bash? «for … in»? grep — как говорится, вот он, sed — как говорится, вот он, awk, одна штука — вижу. А bash-то где?
LeVoN_CCCP
18.07.2025 15:28В итоге мы переписали скрипт в виде Python CLI / на Python:
с логированием, обработкой ошибок и тестами.
Маппинга полей через YAML
Определения и нормализации форматов даты и телефонов
Логирования и итоговой статистики
Базового интерфейса для нетехнических сотрудников
Простите, а всё-таки зачем? Всё то же самое позволяет делать баш. В своё время я как раз не стал вот этот весь питон использовать в том числе потому что "Bash был доступен, быстр в тестировании, уже установлен везде." - банально новая машина, не надо вспоминать какие библиотеки с кем дружат и в какой последовательности их надо устанавливать (да возможно сейчас питон уже ушёл от этой проблемы). Собственно для таких задач как переменные_во_внешнем_файле/парсинг/логирование/использование_операционистами переход на питон и является по сути "переписывали его во фреймворк.".
1pyxa1
18.07.2025 15:28Вы питоном похоже в 2008 последний раз пользовались. Потом pip появился.
LeVoN_CCCP
18.07.2025 15:28Наверное Вы правы, где-то 2008-2012, но тогда смотрел под виндой в том числе для кросс-платформенности (уроки Джавы не пошли впрок). В те же года + несколько лет после наслышан об идеальной несовместимости 2 и 3 версий, и окончательно плюнул на него. Пока за всё время не сталкивался с необходимостью именно питона, все задачи прекрасно решались на встроенных нативных средствах - баш, пш.
О, пока писал вспомнил, один раз пару лет назад он понадобился и я повторил прекрасное время, что скрипт требовал исключительно версию 2 питона, а под ней исключительно специальную версию дополнительной библиотеки (более новая на 2 минорных старше не подходила естественно и пип тут же отвалился), которую тоже поискать пришлось. В итоге подружив вот это вот всё вместе за несколько часов я выяснил что оно не работает. А связавшись с автором выяснил, что почему-то в связке питона с этой библиотекой есть какая-то несовместимость с лгбт-виндой.randomsimplenumber
18.07.2025 15:28об идеальной несовместимости 2 и 3 версий
Для самописных скриптов это неважно. А чужие.. Программу под qt4 на qt5 тоже не просто запустить.
с лгбт-виндой
бригаду, срочно.
economist75
18.07.2025 15:28Код на Bash/PS с логированием парсинга, YAML, валидацией и нормализацией данных и web-GUI с логами и статистикой - будет в сотни раз многострочнее, чем на Python. Неудивительно что на Python таких примеров - десятки тысяч (блокнотов Jupyter на github, kaggle итд), а на Bash - ни одного. Но сделать - да, позволяет.
9a75sd
18.07.2025 15:28Как раз мой случай
Мне понадобилось записать логи с последовательного порта устройства, чтобы отловить программную проблему, но при подключении к компьютеру и подключении терминальной программы давался сигнал сброса на устройство, и багу при таких обстоятельствах не отловить. Плюс, ноутбук оставлять в укромном месте, чтобы только собирал логи - жирно и неудобно. В итоге на одноплатнике запустил 3 bash-скрипта и 2 udev-правила.
Один скрипт - собственно логирование порта, который завершает свою работу, если порт отключается, другой - чистит логи старше 30 дней, а третий - копирует логи на флешку, если она с именем USBLOGS.
Первое udev-правило - запускает скрипт, если видит подключение ttyACM или ttyUSB, а второе - при обнаружении флешки с меткой USBLOGS запускает скрипт на копирование логов. При этом, скопировалось или нет, можно отсмотреть только по индикатору на флешке.
Такое решение помогло отловить проблему.
Первое решение могло логировать только один порт (скрипт работал постоянно, не было udev-правила и складывал только в одну папку). Сейчас решение умеет логировать несколько портов, разделяя логи по папкам с именем НазваниеПорта_СерийныйНомер.
Сейчас этот логгер отдал испытателю, чтобы собирал логи и в случае чего их снял и передал мне на анализ, но у меня уже появилась идея улучшенной версии и ОС для логгера, и программы для логгирования, которую хочу написать на C/C++.
L1stiks
18.07.2025 15:28А еще есть волшебная вещь, стандартизация на клиентской стороне, плюс простые обработчики на вашей и вот оно счастье.
vvzvlad
18.07.2025 15:28Боже, о чем статья? “Я сделал простой скрипт, он мне помог, круто”? Автор точно программист? Люди обычно такой восторг испытывают в первый год работы, а потом как-то утихает радость по баш-скриптам, потому что задачи начинаются сложнее и такие мини-тулзы уже пишутся на автомате и не считаются чем-то заслуживающим внимания, ну тулза и тулза, сегодня написал, завтра забыл.
VADemon
18.07.2025 15:28У законодателей бы был такой восторг от "я провел новый закон/отменили старый, теперь бумажкописательства станет меньше, круто". Может и не совсем программист? А статьи и такие нужны, чтобы побуждать к действию. Даже при помощи матерей разных оттенков кожи и переписки с LLM.
randomsimplenumber
18.07.2025 15:28У законодателей бы был такой восторг
Я навайбкодил законопроект.. Звучит как план.
FabrLik
Интересная статья :)
В свое время схожим образом автоматизировал через VBA-скрипты, когда множество отделов присылали разнородные данные, которые требовалось нормализовать.
Самое сложное из практики не автоматизировать, а не повредить данные.
Как с этим боролись? :)