Comments 57
Интересная статья :)
В свое время схожим образом автоматизировал через 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 точно сольется.
Вообще-то нет
Это сложнее если вам надо сделать один Мега скрипт для обработки всех данных.
Кстати, закрадываются сомнения что автор смог решить проблему одним Мега скриптом.
Обычно каждый поставщик данных имеет свой уникальный формат и способ передачи данных.
Решал такую проблему тупо созданием скриптов на поставщика/ источник данных.
Далее раскидывал данных по папкам структура была типа
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 раз быстрее в исполнении.
Я когда-то работая в детском стационаре, став заведующим столкнулся с месячными отчётами, которые в тот момент выглядели как ручное подсчитывание по журналу множества показателей. С отчетом за один месяц ещё можно было управиться за один вечер, но когда подошел срок квартального, начался ад. Со старшей медсестрой чуть не поругались. Нужно было много чего соединять, пересчитывать. В общем дал себе слово к следующему отчёту написать программу. Из прикладных более менее знал 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
Всегда так делаю. Баш - он же по сути своей "напиши то что делаешь руками и запусти"
Bash + библиотека и иерархия зависимостей классов с зависимостями в .txt и .png готова, перевод с одного языка на другой облегчила жизнь.
Только размер картинки адовый получился, мало какая программа просмотра могла открыть
Простите, а где здесь bash? «for … in»? grep — как говорится, вот он, sed — как говорится, вот он, awk, одна штука — вижу. А bash-то где?
В итоге мы переписали скрипт в виде Python CLI / на Python:
с логированием, обработкой ошибок и тестами.
Маппинга полей через YAML
Определения и нормализации форматов даты и телефонов
Логирования и итоговой статистики
Базового интерфейса для нетехнических сотрудников
Простите, а всё-таки зачем? Всё то же самое позволяет делать баш. В своё время я как раз не стал вот этот весь питон использовать в том числе потому что "Bash был доступен, быстр в тестировании, уже установлен везде." - банально новая машина, не надо вспоминать какие библиотеки с кем дружат и в какой последовательности их надо устанавливать (да возможно сейчас питон уже ушёл от этой проблемы). Собственно для таких задач как переменные_во_внешнем_файле/парсинг/логирование/использование_операционистами переход на питон и является по сути "переписывали его во фреймворк.".
Вы питоном похоже в 2008 последний раз пользовались. Потом pip появился.
Наверное Вы правы, где-то 2008-2012, но тогда смотрел под виндой в том числе для кросс-платформенности (уроки Джавы не пошли впрок). В те же года + несколько лет после наслышан об идеальной несовместимости 2 и 3 версий, и окончательно плюнул на него. Пока за всё время не сталкивался с необходимостью именно питона, все задачи прекрасно решались на встроенных нативных средствах - баш, пш.
О, пока писал вспомнил, один раз пару лет назад он понадобился и я повторил прекрасное время, что скрипт требовал исключительно версию 2 питона, а под ней исключительно специальную версию дополнительной библиотеки (более новая на 2 минорных старше не подходила естественно и пип тут же отвалился), которую тоже поискать пришлось. В итоге подружив вот это вот всё вместе за несколько часов я выяснил что оно не работает. А связавшись с автором выяснил, что почему-то в связке питона с этой библиотекой есть какая-то несовместимость с лгбт-виндой.
Код на Bash/PS с логированием парсинга, YAML, валидацией и нормализацией данных и web-GUI с логами и статистикой - будет в сотни раз многострочнее, чем на Python. Неудивительно что на Python таких примеров - десятки тысяч (блокнотов Jupyter на github, kaggle итд), а на Bash - ни одного. Но сделать - да, позволяет.
Как раз мой случай
Мне понадобилось записать логи с последовательного порта устройства, чтобы отловить программную проблему, но при подключении к компьютеру и подключении терминальной программы давался сигнал сброса на устройство, и багу при таких обстоятельствах не отловить. Плюс, ноутбук оставлять в укромном месте, чтобы только собирал логи - жирно и неудобно. В итоге на одноплатнике запустил 3 bash-скрипта и 2 udev-правила.
Один скрипт - собственно логирование порта, который завершает свою работу, если порт отключается, другой - чистит логи старше 30 дней, а третий - копирует логи на флешку, если она с именем USBLOGS.
Первое udev-правило - запускает скрипт, если видит подключение ttyACM или ttyUSB, а второе - при обнаружении флешки с меткой USBLOGS запускает скрипт на копирование логов. При этом, скопировалось или нет, можно отсмотреть только по индикатору на флешке.
Такое решение помогло отловить проблему.
Первое решение могло логировать только один порт (скрипт работал постоянно, не было udev-правила и складывал только в одну папку). Сейчас решение умеет логировать несколько портов, разделяя логи по папкам с именем НазваниеПорта_СерийныйНомер.
Сейчас этот логгер отдал испытателю, чтобы собирал логи и в случае чего их снял и передал мне на анализ, но у меня уже появилась идея улучшенной версии и ОС для логгера, и программы для логгирования, которую хочу написать на C/C++.
А еще есть волшебная вещь, стандартизация на клиентской стороне, плюс простые обработчики на вашей и вот оно счастье.
Боже, о чем статья? “Я сделал простой скрипт, он мне помог, круто”? Автор точно программист? Люди обычно такой восторг испытывают в первый год работы, а потом как-то утихает радость по баш-скриптам, потому что задачи начинаются сложнее и такие мини-тулзы уже пишутся на автомате и не считаются чем-то заслуживающим внимания, ну тулза и тулза, сегодня написал, завтра забыл.
Как один глупый Bash-скрипт сэкономил нам 100 часов ручной работы