Что за велосипед из YAML и CSV? Если хоть один объект в массиве содержит не скалярный атрибут, то это превращается в обычный YAML с явным указанием числа элементов массива. Зачем? В случае массива "плоских" объектов будет CSV опять же с указанием числа элементов. Снова: зачем?
В 101 раз повторено одно и то же с упрощёнными примерами, а таким важным вещам, как типизация, уделена одна строчка между делом. data.get("username") почему-то не попадает под критикуемую далее категорию магических констант. Хотя не раз в одном продукте видел user_name в одном месте и username в другом. И где тот интересный баланс между YAGNI и обкладыванием dataclass'ами всего подряд? Или выбор между NamedTuple и dataclass? Или вообще протоколом?
Из интересного увидел только использование ветки else в try: впервые встречаю среди прочитанного кода, и очень интересная рекомендация по использованию: вынести в try только потенциально опасный кусок. А как же читаемость? Код друг за другом - все понятно, ожидаемые исключения в конце ветками - тоже понятно. А эта конструкция смотрится странно, даже интересно, что вдохновило дизайнеров языка на такое. Какая реальная польза от else вместо описания happy-path и обработки разных исключений разом без детализации, кто же там споткнулся?
Скорее всего потому, что это курсовая/дипломная работа, судя по структуре и nir_7_semestr. Часто наблюдаемое явление: из питона по простому импорту CSV пушки по воробьям. В целом, если бы модели были объявлены через классы orm и менялся только энджин в алхимии, прилагался код-запускатор запросов и измеритель времени выполнения, сбрасыватель кешей/буферов и т.п (короче говоря, готовая настройка тестов), можно было бы сказать, что для простоты автоматизации и измерений. Но тут он просто потому что. Учитывая ещё то, что файлы локальные, и все названные СУБД умеют импортировать CSV нативной, без внешнего pandas.
Там была куча фич для слабого диалапа, которая позволяла использовать интернет адекватно, был свой менеджер загрузок, блокировщик мусора и многое такое, что сейчас надо ставить плагинами (или просто уже не актуально). Еще нее была прекрасная мобильная версия со многими фичами десктопа, которая была единственным адекватным браузером на j2me.
Кастомизаторы рабочего стола нужны для того, чтобы в выходные сесть и позалипать в рабочий стол пару часов? А потом понаблюдать за загрузкой ЦПУ полчаса. Ну серьезно, за последние 10 лет на рабочий стол приходилось смотреть 20 секунд после перезагрузки компьютера, дальше открываются рабочие инструменты и начинается дело. Аналогично с сортировкой ярлычков: все супер нужное закрепляется на панели задач, все остальное ищется через win -> ввод названия. Помнится, в детстве было интересно группировать ярлычки, начиная с win10 это потеряло смысл вообще. Из обеих подборок только кастомный тайлинг, пожалуй, хорош.
Кстати, да. Некоторые СУБД сами понимают, что можно сделать UNION или сперва скан по одному столбцу, а потом фильтр. А тут под конкретный запрос менять схему хранения: выглядит ужасными костылями
У проводок же ещё сто пятьдесят аналитик, кроме счета, какого размера будет граф в сколько-нибудь реальном учете? Какую бизнес-задачу решаем? Да, красиво, интересно. Вопрос только в конечной цели.
copy поддерживает commit/rollback, так что судьбу импортированных записей можно решить самому, в том числе в случае удачного завершения (в отличие, к примеру, от ораклового sqlldr). В статье бы, конечно, стоило добавить описание работы "под капотом", чтобы было понятно, за счёт чего это достигается (что это не просто fast=true).
Про МДМ вообще непонятно. Ну, например, есть у нас справочник номенклатур на 1.5 млн позиций. Как заводить меппинг для него? Или про сырой слой DWH. Загружаются к нам данные в виде девятиэтажных вложенных массивов, как их разбираем по объектам и проводим дедубликацию, какой тут подход?
Безотносительно качества примеров, советы в конце статьи - это примерно как говорить "не нарушайте законы, вас могут поймать". Что теряет кандидат, когда обманывает? Ничего, только свое время. При этом получает хороший шанс проскочить в какое-нибудь "богатое" место, где денег очень много, а процессы настолько запутанные, что затеряться там на годик вполне можно. Дальше идём в новое место. И таким образом, все также не имея никакого толкового опыта, этот пилигрим уже имеет реальные записи в резюме с возможностью их подтвердить, но вообще не понимает ничего: потому что крудошлепил/заполнял формочки по шаблону/делал как сказали. А причины тут две: нет никакого способа таких вот накручивателей отсеивать заранее и готовность слишком богатых компаний брать с рынка хоть кого-то, потому что могут. А потом они идут в другие места с соответствующими запросами, и тратят чужое время на тех. собесе. Только в минусе не кандидат, а компания и собеседующие. Знает он там, как должен (не)работать какой-то говнокод или нет - вообще дело десятое. Если человек может внятно объяснить, что именно и зачем он делал, какие задачи решал, как и почему именно так - это уже успех. Часто даже это не могут объяснить (ну я там данные загружал, ну иногда инциденты приходили, искал). А то, что вместо кортежа получится генератор, можно увидеть при первом же запуске кода, и для этого не нужно обладать какими-то особенными знаниями.
Как уже отметили, у Excel есть большой плюс: GUI и привычность пользователю. И обычно шаг от наколеночного решения до опромышливания - гигантский. Если хочется убрать вырвиглазный ВПР (индекс поискпоз куда гибче, кстати), то в качестве первого приближения можно было бы использовать стандартный Power Query:
Всё остаётся в том же файле с тем же интерфейсом.
Можно разделить большой файл сырых данных на отдельные файлы а-ля горячее/холодное хранение и обновлять только горячие данные без ожидания обновления всех формул.
Гибкость не хуже SQL. Есть много настроек через кликание мышкой.
Никакого питона, который неоткуда взять случайному пользователю в компании.
Ноль дополнительной инфраструктуры (ведь Postgres и планируемый Airflow мы не в воздухе запускаем)
Никаких дополнительных проблем с доступами и полномочиями: все на уровне того же файла.
Можно по-прежнему собирать данные из разных источников и локально крутить-вертеть независимо от технологий и интеграций: экспорт поддерживается в том или ином виде почти везде.
Если когда-то наступят светлые времена, можно прозрачно для пользователя подменить некоторые таблицы на таблицы СУБД: для пользователя ничего не изменится, есть pushdown.
Питоны - это классно, но только для упрощения жизни себе. Для того, чтобы такое решение можно было распространить в компании, надо провести очень немало организационных мероприятий и приложить ему усилий, а все это помимо никуда не девающейся сложность настройки и последующей актуализации/доработки.
Это не вписывается в интересы компании. А как же обновления ради обновлений? Сейчас же почти везде так. Передвинули меню, в фильтры добавили никому ненужные критерии и убрали нужные, добавили тормозов и рекламы. И вот уже бэклог того, что нужно фиксить в следующем релизе. А ваш проект выкатил и даже сопровождать не надо, вообще беспредел.
Ни разу не видел в сапе, чтобы перемещения в логистике каким-то образом решались через сторно, в том числе в компаниях с непростой логистикой. Во-первых, там разнесены логистика и бухгалтерия, и не все шевеления в логистике шевелят бухгалтерию, а во-вторых, там достаточно сущностей, которые могут корректно отражать промежуточные состояния заказа без необходимости что-либо сторнировать. И учитывать финансовые и логистические документы до/после фактической поставки. Какие-то выдуманные истории, вы сап видели дальше, чем скрин из SPRO? Я не адепт сапа, и мне все равно, на какой платформе что-то там работает (таковы исходные условия, надо под них подстроиться), но доводы очень слабые. Технологически он зрелый, имеет возможность кастомизации (в том числе через костыли, как любой другой инструмент), причем одно и то же можно настроить по-разному, он выполняет свою задачу, и пользователям в целом плевать на ущербный интерфейс через несколько месяцев работы. А если в какой-то критический момент он встанет раком, ИТ директору не придется изворачиваться, почему он выбрал "этот сап" - потому что проверено многими. Экспериментировать с различными платформами, когда один час простоя твоего предприятия выливается в миллионы денег, не каждый рискнёт.
Я давненько не бывал на собесах сам, но при просмотре кандидатов как раз исхожу из того, чем он занимался ранее: если может внятно рассказывать, можно в случайном месте навести фокус и услышать детали (а не "ну там это потому что ХЗ ТЗ"), на неизвестные подходы/технологии может найти аналогию в своем опыте и объяснить - значит, человек умеет понимать и разбираться. А если 5 лет работал и ответы из серии "в фреймворке X это надо делать вот так", то и у себя он дальше "говорят, что надо так" не уйдет.
Вообще в boto3 put_object умеет принимать на вход стрим, поэтому в текущей реализации без дополнительного кода по обработке частично упавшей загрузки можно сразу соединить вход и выход без явного использования метода read(put_object сам его вызовет под капотом). Заодно неплохо сэкономить на локальном хранилище/памяти.
Исходя из типичного содержания статей по ИИ выходит, что в эпоху ИИ на самом деле важно наличие вайба, инсайтов и неумения программировать (именно программировать, а не набирать код). Интересен вопрос: можно ли имея только вайб раздобыть инсайт от того же ИИ, или источником инсайнов должно быть что-то внешнее относительно этой системы? И как набрать команду вайбкодеров с вайбами, которые будут суммироваться в продукт, а не ноль (вдруг у двух вайбкодеров противоположные вайбы?). Вот такую бы статью запилили для разнообразия.
Описанный флоу выглядит вывернутым наизнанку, потому что в самом пайплайне можно сделать билд, затем тест, а уже работающее потом упаковать в образ и задеплоить. Но если хочется контейнеризовать, а потом тестировать, то в билде собираем образ, пушим в реестр (Github Packages/Gitlab container registry/Dockerhub), потом оттуда забираем образ для стейджа test, указав его явно в файле пайплайна:
test:
stage: test
image: dockeraccount/myapp:test_version_tag
script: |
pytest #example
Тогда и логи, и репорты прокинуть можно без лишних приседаний, и не нужно писать скриптовую обёртку, чтобы запустить контейнер с нужными параметрами, войти в него, а только потом запускать команды теста. Если контейнер нужен как что-то сбоку для тестов (например, СУБД), то в .gitlab-ci.yml, например, есть секция services, где также можно указать нужный кастомный image из первого шага, а тесты запускать в самом контейнере джоба.
Это же шутка, да?)
https://about.readthedocs.com/
https://pypi.org/
https://www.python.org/
https://kubernetes.io/docs/home/
При этом: https://peps.python.org/pep-0000/
Что за велосипед из YAML и CSV? Если хоть один объект в массиве содержит не скалярный атрибут, то это превращается в обычный YAML с явным указанием числа элементов массива. Зачем? В случае массива "плоских" объектов будет CSV опять же с указанием числа элементов. Снова: зачем?
В 101 раз повторено одно и то же с упрощёнными примерами, а таким важным вещам, как типизация, уделена одна строчка между делом.
data.get("username")почему-то не попадает под критикуемую далее категорию магических констант. Хотя не раз в одном продукте виделuser_nameв одном месте иusernameв другом. И где тот интересный баланс между YAGNI и обкладыванием dataclass'ами всего подряд? Или выбор между NamedTuple и dataclass? Или вообще протоколом?Из интересного увидел только использование ветки
elseвtry: впервые встречаю среди прочитанного кода, и очень интересная рекомендация по использованию: вынести вtryтолько потенциально опасный кусок. А как же читаемость? Код друг за другом - все понятно, ожидаемые исключения в конце ветками - тоже понятно. А эта конструкция смотрится странно, даже интересно, что вдохновило дизайнеров языка на такое. Какая реальная польза отelseвместо описания happy-path и обработки разных исключений разом без детализации, кто же там споткнулся?Скорее всего потому, что это курсовая/дипломная работа, судя по структуре и
nir_7_semestr. Часто наблюдаемое явление: изпитона по простому импорту CSVпушки по воробьям. В целом, если бы модели были объявлены через классы orm и менялся только энджин в алхимии, прилагался код-запускатор запросов и измеритель времени выполнения, сбрасыватель кешей/буферов и т.п (короче говоря, готовая настройка тестов), можно было бы сказать, что для простоты автоматизации и измерений. Но тут он просто потому что. Учитывая ещё то, что файлы локальные, и все названные СУБД умеют импортировать CSV нативной, без внешнего pandas.Там была куча фич для слабого диалапа, которая позволяла использовать интернет адекватно, был свой менеджер загрузок, блокировщик мусора и многое такое, что сейчас надо ставить плагинами (или просто уже не актуально). Еще нее была прекрасная мобильная версия со многими фичами десктопа, которая была единственным адекватным браузером на j2me.
Кастомизаторы рабочего стола нужны для того, чтобы в выходные сесть и позалипать в рабочий стол пару часов? А потом понаблюдать за загрузкой ЦПУ полчаса. Ну серьезно, за последние 10 лет на рабочий стол приходилось смотреть 20 секунд после перезагрузки компьютера, дальше открываются рабочие инструменты и начинается дело. Аналогично с сортировкой ярлычков: все супер нужное закрепляется на панели задач, все остальное ищется через win -> ввод названия. Помнится, в детстве было интересно группировать ярлычки, начиная с win10 это потеряло смысл вообще. Из обеих подборок только кастомный тайлинг, пожалуй, хорош.
Кстати, да. Некоторые СУБД сами понимают, что можно сделать UNION или сперва скан по одному столбцу, а потом фильтр. А тут под конкретный запрос менять схему хранения: выглядит ужасными костылями
Чтобы настраивать внешний вид стоит присмотреться к BolgenOS
У проводок же ещё сто пятьдесят аналитик, кроме счета, какого размера будет граф в сколько-нибудь реальном учете? Какую бизнес-задачу решаем? Да, красиво, интересно. Вопрос только в конечной цели.
copyподдерживает commit/rollback, так что судьбу импортированных записей можно решить самому, в том числе в случае удачного завершения (в отличие, к примеру, от ораклового sqlldr). В статье бы, конечно, стоило добавить описание работы "под капотом", чтобы было понятно, за счёт чего это достигается (что это не просто fast=true).Про МДМ вообще непонятно. Ну, например, есть у нас справочник номенклатур на 1.5 млн позиций. Как заводить меппинг для него? Или про сырой слой DWH. Загружаются к нам данные в виде девятиэтажных вложенных массивов, как их разбираем по объектам и проводим дедубликацию, какой тут подход?
Безотносительно качества примеров, советы в конце статьи - это примерно как говорить "не нарушайте законы, вас могут поймать". Что теряет кандидат, когда обманывает? Ничего, только свое время. При этом получает хороший шанс проскочить в какое-нибудь "богатое" место, где денег очень много, а процессы настолько запутанные, что затеряться там на годик вполне можно. Дальше идём в новое место. И таким образом, все также не имея никакого толкового опыта, этот пилигрим уже имеет реальные записи в резюме с возможностью их подтвердить, но вообще не понимает ничего: потому что крудошлепил/заполнял формочки по шаблону/делал как сказали. А причины тут две: нет никакого способа таких вот накручивателей отсеивать заранее и готовность слишком богатых компаний брать с рынка хоть кого-то, потому что могут. А потом они идут в другие места с соответствующими запросами, и тратят чужое время на тех. собесе. Только в минусе не кандидат, а компания и собеседующие. Знает он там, как должен (не)работать какой-то говнокод или нет - вообще дело десятое. Если человек может внятно объяснить, что именно и зачем он делал, какие задачи решал, как и почему именно так - это уже успех. Часто даже это не могут объяснить (ну я там данные загружал, ну иногда инциденты приходили, искал). А то, что вместо кортежа получится генератор, можно увидеть при первом же запуске кода, и для этого не нужно обладать какими-то особенными знаниями.
Как уже отметили, у Excel есть большой плюс: GUI и привычность пользователю. И обычно шаг от наколеночного решения до опромышливания - гигантский. Если хочется убрать вырвиглазный ВПР (индекс поискпоз куда гибче, кстати), то в качестве первого приближения можно было бы использовать стандартный Power Query:
Всё остаётся в том же файле с тем же интерфейсом.
Можно разделить большой файл сырых данных на отдельные файлы а-ля горячее/холодное хранение и обновлять только горячие данные без ожидания обновления всех формул.
Гибкость не хуже SQL. Есть много настроек через кликание мышкой.
Никакого питона, который неоткуда взять случайному пользователю в компании.
Ноль дополнительной инфраструктуры (ведь Postgres и планируемый Airflow мы не в воздухе запускаем)
Никаких дополнительных проблем с доступами и полномочиями: все на уровне того же файла.
Можно по-прежнему собирать данные из разных источников и локально крутить-вертеть независимо от технологий и интеграций: экспорт поддерживается в том или ином виде почти везде.
Если когда-то наступят светлые времена, можно прозрачно для пользователя подменить некоторые таблицы на таблицы СУБД: для пользователя ничего не изменится, есть pushdown.
Питоны - это классно, но только для упрощения жизни себе. Для того, чтобы такое решение можно было распространить в компании, надо провести очень немало организационных мероприятий и приложить ему усилий, а все это помимо никуда не девающейся сложность настройки и последующей актуализации/доработки.
Это не вписывается в интересы компании. А как же обновления ради обновлений? Сейчас же почти везде так. Передвинули меню, в фильтры добавили никому ненужные критерии и убрали нужные, добавили тормозов и рекламы. И вот уже бэклог того, что нужно фиксить в следующем релизе. А ваш проект выкатил и даже сопровождать не надо, вообще беспредел.
Ни разу не видел в сапе, чтобы перемещения в логистике каким-то образом решались через сторно, в том числе в компаниях с непростой логистикой. Во-первых, там разнесены логистика и бухгалтерия, и не все шевеления в логистике шевелят бухгалтерию, а во-вторых, там достаточно сущностей, которые могут корректно отражать промежуточные состояния заказа без необходимости что-либо сторнировать. И учитывать финансовые и логистические документы до/после фактической поставки. Какие-то выдуманные истории, вы сап видели дальше, чем скрин из SPRO? Я не адепт сапа, и мне все равно, на какой платформе что-то там работает (таковы исходные условия, надо под них подстроиться), но доводы очень слабые. Технологически он зрелый, имеет возможность кастомизации (в том числе через костыли, как любой другой инструмент), причем одно и то же можно настроить по-разному, он выполняет свою задачу, и пользователям в целом плевать на ущербный интерфейс через несколько месяцев работы. А если в какой-то критический момент он встанет раком, ИТ директору не придется изворачиваться, почему он выбрал "этот сап" - потому что проверено многими. Экспериментировать с различными платформами, когда один час простоя твоего предприятия выливается в миллионы денег, не каждый рискнёт.
Да-да, очень напоминает статьи Minerva Soft, и уровень вовлечённости резко падает
Я давненько не бывал на собесах сам, но при просмотре кандидатов как раз исхожу из того, чем он занимался ранее: если может внятно рассказывать, можно в случайном месте навести фокус и услышать детали (а не "ну там это потому что
ХЗТЗ"), на неизвестные подходы/технологии может найти аналогию в своем опыте и объяснить - значит, человек умеет понимать и разбираться. А если 5 лет работал и ответы из серии "в фреймворке X это надо делать вот так", то и у себя он дальше "говорят, что надо так" не уйдет.Вообще в boto3
put_objectумеет принимать на вход стрим, поэтому в текущей реализации без дополнительного кода по обработке частично упавшей загрузки можно сразу соединить вход и выход без явного использования методаread(put_objectсам его вызовет под капотом). Заодно неплохо сэкономить на локальном хранилище/памяти.Исходя из типичного содержания статей по ИИ выходит, что в эпоху ИИ на самом деле важно наличие вайба, инсайтов и неумения программировать (именно программировать, а не набирать код). Интересен вопрос: можно ли имея только вайб раздобыть инсайт от того же ИИ, или источником инсайнов должно быть что-то внешнее относительно этой системы? И как набрать команду вайбкодеров с вайбами, которые будут суммироваться в продукт, а не ноль (вдруг у двух вайбкодеров противоположные вайбы?). Вот такую бы статью запилили для разнообразия.
Описанный флоу выглядит вывернутым наизнанку, потому что в самом пайплайне можно сделать билд, затем тест, а уже работающее потом упаковать в образ и задеплоить. Но если хочется контейнеризовать, а потом тестировать, то в билде собираем образ, пушим в реестр (Github Packages/Gitlab container registry/Dockerhub), потом оттуда забираем образ для стейджа test, указав его явно в файле пайплайна:
Тогда и логи, и репорты прокинуть можно без лишних приседаний, и не нужно писать скриптовую обёртку, чтобы запустить контейнер с нужными параметрами, войти в него, а только потом запускать команды теста. Если контейнер нужен как что-то сбоку для тестов (например, СУБД), то в .gitlab-ci.yml, например, есть секция services, где также можно указать нужный кастомный image из первого шага, а тесты запускать в самом контейнере джоба.