Предохранитель, если сделает backfill (заливку аномального пика или "пустоты" первым текущим валидным значением) - вряд ли что-то испортит. Он не не завысит сумму налога и вряд ли приведет к судебному иску. Не остановит дымосос и не устроит аварию.
А вот без него - "кривой" дэшборд из-за ручной правки базы после выпадения данных какого-нибудь сенсора - запросто может породить офисный кризис с разборками, увольнением и сокращением целых отделов. Самодуров и лихих на расправу руководителей - хватает везде. Плюс это функция времени пребывания на посту, возраста и влияния "банно-саунного" менеджмента. Поэтому каждый такой предохранитель - спасенные судьбы линейных руководителей. Статья полезная, вот прям слышу как наши побежали что-то подобное делать.
Монопольное положение (>80% всех "учетных" АРМ в стране, это ~3 млн. пользователей) - обязывает и расслабляет одновременно. Доля ARM только сейчас начала с ноутбуками проявлять себя. Бухгалтерия на Orange Pi 5 будет смотреться здорово и бесшумно.
Хорошая идея - использовать численные методы для пешего маршрута. Но есть стоп-факторы:
1) Низкое разрешение горизонталей делает авто-маршруты непригодными в горах. Любая карта - это упрощенная модель местности, а OpenStreetmap (лучше https://opentopomap.ru) - слишком упрощена. Сравните: на военных секретных, но всюду утекших картах Генштаба 1986-1998 гг. 1:50000 (в 1с м - 500 метров) - число узлов (поворотов) одной горизонтали на планшете составляет ~8 тысяч, а в рельефе OSM/NASA - меньше ~1 тыс. Это приводит к тому что 3/4 оврагов, ущелий, каньонов - вы не увидите, если их не обозначили вручную. Состояние этой работы для туристически активного Юга РФ (Кубань) - примерно 5% от реального.
2) При автопрокладке маршрута нужно избегать бродов, спусков в лощины, труднопроходимых зарослей, безлесных участков на солнцепеке, каменпадо- лавиноопасных мест итд. Всего этого в решении нет, хотя прикрутить - можно. Сюда можно добавить и полезную дичь, типа преимущества участков с покрытием GSM-связью, наличие родников, стоянок, или видимость геостационарных спутников связи (прмерно по пути солнца на небосводе).
Предложения: помимо рисования OSM - использовать другие данные с OSM-проекта, а именно GPS-треки реального прохождения маршрута "ножками" (нужно убрать оттуда джиперские и иные моторизованные забеги). Скорость прохождения любого отрезка (разница в Timestamp записей точек) - неплохо характеризует техническую сложность (но содержит также накопленную усталость, "физику" туриста, несущего навигатор, его груз, и иные "сезонности"). Нужны DS-технологии для очистки треков, ну а главное - нужны ГШ-горизонтали. Но вот так просто взять их и нарисовать в OSM - нельзя. Нельзя даже втупую перенести все названия хребтов и урочищ с ГШ в OSM - копирасты и бояки откатят ваши правки. А раз нет рельефа - нет и маршрута. Из опыта - примерно 5% любого горного похода идут не по маршруту, а напролом, "по азимуту", в результате потере тропы или просто потому что нашли путь лучше (новую тропу/волок). Элемент случайности - такой же завлекающий фактор в походе, как и красоты. Походим пока без авто-маршрутов.
Успех Питона парадоксален. Сторонники простых объяснений видят причину в ученых и студентах, а также "тех кто после курсов". Но датасатинисты/студенты точно не вывезли бы эту популярность. И ответы на stackoverflow (где язык тоже в топе) понаписали точно не они, а вполне профессиональные программисты (возможно владеющие и др. ЯП). Видимо малословность, срезы, списки/словари и прочий плюшки завлекли и опытных кодеров.
"Питоновость", python-style код - не пустые слова, это всегда кратко и понятно. Кто-то добавит: "... И медленно!", но будет неправ, поскольку почти все медленные места расшиваются использованием быстрых библиотек, написанных на быстрых языках, но (часто) специально для питона (numpy). Либ 400k+ и они все свободны. Легкость кодинга позволила очень много понаписать сайтов (django) и бизнес-логики, а в экономических расчетах Python потеснил даже Excel. Так что электорат языка постоянно и разнообразно вовлечен в широчайший спектр отраслей, профессий, документов, веба и хобби. Ни малейшего признака стагнации, как, скажем, в ... (добавить почти любой язык, клюющий носом вниз в рейтингах, таких - десятки).
Сохраняет лидерство Пиоон в т.ч. и потому что ругают его часто как раз за его сильные и принятые сообществом стороны (классы, наследование, декораторы, отступы вместо скобок). Попытки убедить в том что это плохо или реализовано неправильно - вызывают ~смех~ обратную реакцию роста любви к языку.
Назову не отечественные, но зато сразу две свободные не то что BI-платформы, но пригодные для создания BI-дэшбордов не хуже PowerBI/Qlik/Tableau, к концу третьего дня работы с ними:
Apache Superset
Streamlit
И если Superset прямо сложный и большой (и сразу в Docker), то Streamlit - простой и вполне легко осиливается средним бизнесом (это который до 100 млрд выручки в год, что примерно соответствует нижней части списка Top-100 РФ РБК, с численностью в таких компаниях 2-5k человек). Именно этот средний бизнес и является основным мотором экономики, именно он дремуче-бумажен, именно ему так не хватает "живого" BI, не отягощенного многомиллиоными платежами за лицензионное ПО и откат-консалтеров.
Сама аналитика (SAC, OLAP) для построения дэшбордов - легко собирается в тетрадках/блокнотах Jupyter на Python+Pandas по данным 1С, с небольшой примесью чистого SQL для получения данных из всевозможных CRM/СКУД/SCADA, в это обязаны уметь все современные экономисты (и многие уже умеют). Использование Python часто идет под флагом прототипирования/MVP, но почему-то все чаще оказывается вполне "продактским" и не падает годами. Видимо дэшборды и их созерцание - неспешно-медитативны , и оптимизаций, которые все ломают, тут никто не просит и не делает.
Есть еще одна причина - часть батарей можно перепродать гораздо дороже, чем лом по цене 21 руб./кг.
Насчет все рассортировать: средний российский завод потребляет лома в сутки - "кучку". Размеры кучки - 100м*20м, высотой 4-5 метров. Это 3-5 тыс. тн. лома, состоящие из примерно 1 млн. "предметов". Их контролем за сутки занимается около 10-30 человек. Зрительная нагрузка - колоссальная.
На практике попадается всё: сплющенные баллоны с хлором, заклинившие снаряды в артиллерийских стволах и прочие "подарки". На любом заводе раз в год что-то да взрывается, но как правило без серьезных последствий. Для этого существуют определенные регламенты поведения персонала (например, не находиться в течение первых 5 мин возле Печи после включения электрической дуги после каждой очередной подвалки лома). Есть специальные безопасные зоны, куда не долетит горячий шлак, брызги металла и окалина в случае взрыва. Спецодежда и СИЗ.
Обнаружение взрывоопасных предметов - хорошая задача для ML/CV, потому что глаз у людей замыливается, лом слишком неоднороден.
Вот именно потому что плохого лома немного (0,5 млрд. тн) и еще в 100+200 раз больше запасов чистой железной руды (1-2 место по величине запасов, кстати, занимает РФ и Украина) - именно поэтому мы имеем дело с проблемой будущих поколений.
Виноват во всем и всегда лишь один человек, генеральный директор, Но это по закону. Де факто виноваты двое: сталевар Вася и шихтовщик Петя, которые решили "выполнить план ради премии" и таки-загрузили в корзину тот самый латунированный лом.
На деле собственники все штрафы относят прямо или косвенно на персонал, т.к. другие статьи сэкономить крайне трудно. Были кейсы трагедии в Трансвааль-парке и др., но случаи рекламаций редко публикуются и доходят до kad.arbitr.ru Так что статистики считай что нет.
Да, но выход найден :-) Многократные переплавки лома (на 40-75% это автомобильный лом) сопровождаются неизбежным попаданием цветмета (латунные, бронзовые, медные детальки, в основном электротехнические) в сталь. Это приводят к постепенному накоплению меди (Cu) в стали (Fe 0.98-0.999, C 0.001-0.02). Даже мизерная доля меди сильно уменьшает прочность стали на разрыв, кручение, свариваемость итд. Имеющимися в XXI в. технологиями металлургии - атомы меди из расплава железа убрать нельзя никак - они прочно удерживаются кристаллической решеткой Fe.
Поэтому в мире около 0,5 млрд. тонн металлолома уже не подлежат переплавке из-за "замеднения". Они лежат мертвым грузом, иногда перепродаются простакам, но в основном лежат.
Заводы, имеющие доступ к железной руде, могут лишь по чуть-чуть подмешивать такой замеднённый лом в чугун или сталь из чистой Fe-руды. Но судя по растущей динамике накопления замеднённого лома - никто из крупных заводов в мире это массово не делает, т.к. это хлопотно и опасно - можно привести к браку всю плавку, а это 50000-200000$ убытков, расписанные на всю виновную смену (100-500 человек).
Поэтому металлурги всех стран соединяйтесь дружно решили спихнуть эту проблему на плечи будущих поколений. Это разумно, т.к. "глобальное тепло" или инопланетное вторжение могут слегка поменять повестку в "следующий" раз, когда наступит очередной повод задуматься о судьбе планеты.
DALL-E уже самобытен, и при этом "стоит на плечах" художников. Это два важнейших требования к искусству - быть непохожим и похожим одновременно. Восхищение сложность полотна от рук человека "не сильнее" сложности от полотна от ИИ. Оно просто другое.
Осталась требование эстетики, сверх-детализации и душевности. Ну, чтобы закрыть стили "реализм" итп. Это вопросы переобучения и мощностей железа, т.е. со временем решаемые. Бездушность тоже лечится добавлением фич в модель, нужно просто разметить данные, чем люди скоро и займутся, прячась по норам от торнадо или радиоактивных осадков.
ИИ не отнимет работу иллюстраторов, а сделает ее легче. DALL-E со товарищи будут по нарастающей теснить людей-художников на всех выставках, во многих жанрах живописи, в т.ч. технически сложных. Но отношение к нему так и останется дискриминационным - как к альтернативному арту. Но все-таки это уже искусство.
Согласен с автором. Кол-во доступных в Сети админ-скриптов для типовых админ-задач на Python vs Go соотносится, имхо, 50:1. Это хороший знак начать именно с Python. А дальше - Go. Языки Bash/CMD смотрится анахронизмом в наше время. Под Windows - админ-задач, пожалуй, до сих пор большинство, а там одни кодировки могут довести до красноглазия, не говоря про экранирование символов, работу с файлами и сетевыми пакетами итд. PowerShell под Windows не стал админ-тулом №1 (имхо).
Для грепа и построения внутренних web-сервисов у Python много "помогаек" в виде либ pandas, numpy, gradio, streamlit, их автор не упомянул. "Проблема скорости" Python с этими либами становится несущественной - многие из них написаны на быстрых и очень быстрых языках.
Аналитики, увы, тоже "ищут под (своим) фонарем", поскольку невозможно успеть собрать, имхо, и половину всех доступных данных. Погода, новостной фон, курс USD на Али, индекс числа распродаж конкурентов к их общему числу, единовременные массовые выплаты итд - все просто не успеть объять. А если речь не о ритейле, а о заводе, то вопрос "на чем больше заработали на прошлой неделе" - получит точный ответ 25/10/2022 г., после сдачи квартальной декларации по налогу на прибыль. Т.е. "посмертно".
Поэтому простые и понятные метрики типа среднего чека пока что "рулят" и будут рулить вечно. И даже их можно улучшить простыми методами. Например поделить на число сейлзов, вышедших на работу, чем резко улучшить объективность этого показателя.
Первым консультантом был Змей из Эдема (убедил-таки Еву грызануть яблочко), но большинство эффективных предприятий стали таковыми безо всякого внешнего бизнес-консалтинга, тем более что появился он недавно.
Популярность бизнес-консалтинга основана на success-story и воодушевляющих метриках, которые звучат правдоподобно и даже частично проверяемы. Но почти всегда имеет место чудовищная манипуляция: все позитивные сдвиги в "зеленую" зону - однозначно приписываются исключительно эффекту внедрения того, что сказали консультанты. А собственные успехи и прежние достижения коллектива - намеренно дезавуируются и "стираются" консалтерами, как вреднейшая привычка и "пережиток". Часто эти действия горячо одобряются собственником, который "...так и знал что работают одни идиоты".
Консалтеры весьма преуспели в умножении на 0 всего позитивного, для этого разработаны эффективные практики по "выключению" из процесса особо умных и несговорчивых (на которых не распространишь коммерческий подкуп). Иное мнение, а также сомнения - всегда признаются саботажем передового опыта, нарушением регламентов итд.
Исход консалтинговых фирм с баснословными расценками и с тем инструментарием, какой они практиковали в РФ - скорее благо, чем зло. Хотя оставшихся без работы людей, безусловно, жалко.
Статья понравилась. Не кодом, который почти что ужасен, а темой макросов в графических пакетах. И вангую рост потребности в них, геометрический. Видел воочию сколько кода на VBA в CorelDraw в немецких дизайн-студиях и рекламных агентствах. Его там много (в наших нет, можно сказать, вообще). Это GUI-утилиты полезняшки, в основном реализующие компоновочные решения при верстке, а также пакетные операции с фото, символами строк итп.
Доля Корела в Германии высока, примерно 40% (остальное условно назовем AI, и это искусственный интеллект, а Adobe Illustrator). В нашей стране официально за CorelDraw не более 25%, но много пиратки в регионах, в каждой студии он имеется (дистр корела легко и бесследно прячется, в отличие от продукции Adobe). Не могу сказать про госструктуры, но на пиратке-кореле там тоже активно рисуют, видел в около-выставочном окружении двух наших главных мероприятий в стране. В условии цейтнота и оргсуматохи ам и не такое можно увидеть.
Так вот, в труде граф. дизайнера оказалось неожиданного много около-текстовой рутины, которую VBA или Python могут взять на себя. Так как горячие клавиши недоступны части особо гордых людей - то только макросы могут повысить производительность труда до приемлемого европейского уровня. Да, он там выше. Я не видел в Германии дизайнеров, не умеющих печать вслепую или просто быстро. Ctrl+D они умеют все.
InkScape - наиболее импортозамещающий свободный пакет из всей векторной графики. Дивизионы Corel и Adobe в РФ хвалились десятками миллионов и даже миллиардом выручки в долларах, так что вопрос не праздный. Python в InkScape, расширения на нем - позволяют делать очень многое, и скорее всего обеспечат технологическое лидерство тем компаниям, которые их освоят, а не будут продолжать платить по 1 млн. руб. за рабочее место на инструментах Adobe. Данная статья - хороший старт, чтобы знать что оно вообще возможно и даже работает.
Даже если предположить что все люди, их глаза и мониторы, освещенность рабочих мест одинакова, то в сухом остатке остаются два отличия, которые как раз и объясняют всё:
Программистам, дата-сайентистам, полиграфистам, дизайнерам - приятней темная тема из-за "мягкой" разноцветной подсветки синтаксиса кода или текста. Их тексты - "электронны";
Редакторам печатных изданий, секретарям, бухгалтерам, юристам итп - приятней светлая тема, из-за монохромности, "бумажности" их текстов.
Но не только цвет текста. Программисты в среднем перечитывают код 6-8 раз, "пятнами", у них нет значимых опечаток из-за авто-дополнения в IDE, они сами выбирают себе все - цвет, жирность шрифта и цветовую гамму. И монитор они выбирают часто сами. И сидят чаще не светлых переговорках, а в темных серверных.
Редакторы/секретари - совсем другое дело: перечитывают текст меньше, в среднем 3 раза, но "сверху-вниз", у них нет авто-дополнения, они не могут поменять себе цвет, жирность шрифта и цветовую гамму. И монитор они выбирают реже, а сидят часто в светлых местах.
Отсюда и разные подходы. Иногда функции кодера/редактора совмещаются, а значит эти люди темное/светлое будут чередовать. Все это я вижу вокруг, у десятков людей в большом холдинге.
Исследования из статьи интересны, но как верно подмечено, однобоки и не описывают этих самых "двух отличий". Для себя сделал вывод что лучше всего провести свое исследование. Но актально оно будет только мне самому, потому что степень совмещения кодер/редактор у каждого своя.
MSO больше не продается бизнесу, значит импортозамещение - нужно всем, не только госорганам. Отсутствие OpenOffice|LibreOffice в "Реестре" не исключает возможность его использования даже в госорганах. И уж тем более под групповыми политиками (которыми скоро тоже будет негде рулить)
LibreOffice как раз наиболее реальный "импортозаместитель" MSO - в силу 100% доступности юзерам с ограниченными правами (без прав инсталляции), из-за реально высокой скорости работы и функционала, соразмерного с MSO и превышающего функционал конкурентов.
Все тесты в которых в статье "выиграл" VBA + MS Excel -- LibreOffice Calc выиграет, если задействовать другой встроенный в него язык программирования, не требующий, как и VBA, установки, также имеющий IDE c автодополнением и интроспекцией. Я о языке Python. Да и сам LibreOffice работает в режиме Portable, т.е. просто распаковывается на любой диск, раздел, флешку (занимая там ~1 Гб) .
Чтобы Calc c Python обогнал MS Excel c VBA в несколько раз - нужны сторонние библиотеки Pandas и Numpy (написаны на С++, Fortran итд), которые можно как установить через pip, а можно просто скачать и распаковать. Подробности описал тут: https://forumooo.ru/index.php/topic,8696.0.html Именно возможность тайком бесплатно распаковать LibreOffice с подкапотным Python и использовать в т.ч. и в госконторах - делает его растущим и перспективным средством офисной автоматизации.
Плохой не Python и Pandas, плохой был первичный код, который в оригинале статьи - отсутствует. Статья понравилась. Она на самом деле повествует о том что несколько сомнительных преобразований сделали зачем-то в Pandas, причем обернули их во вложенные функции, вызов которых в Python и мн. других динамических языках - дорог. Писали, например, датасатанисты, которые в Pandas делают все, даже файловые операции. Видимо это работало, приносило прибыль. Но прод затребовал realtime. Дальше классика. Оптимизировал программист, наивно, без Pandas, на чистом Python и получил... внезапный прирост в ~100 раз. Ничего удивительного что плохой код можно улучшить многократно, просто переписав его "на месте", тем же языком, только правильно.
А вот все дальнейшие оптимизации были стандартны и предсказуемы. Они дали ускорение с 12 сек. до 0,2 сек. (в 60 раз), что хорошо подтверждается другими подобными статьями и кейсами. Но там никакого чуда нет - вынос тяжелых функций в C/Numba/Nuitka итд хорошо известен. Да, однопоточный Python медленнее статических многопоточных языков в ~60 раз, это всем хорошо известно и питонистами не оспаривается. Потому что в 98% задач это замедление незаметно никак. А если вспомнить что на Питоне пишется в в 100 раз быстрее - то рост его популярности становится не таким уж парадоксальным.
Вывод: не стоит никого отговаривать данной статьей. Одни программисты ошибаются - другие исправляют, третьи пишут статьи с процентами ускорения вместо более понятных кратностей, видимо, для пущей важности. В промилле было бы еще быстрее.
Очень интересная статья с т. зр. применения DS. Рискну подтвердить догадку автора что "формулы оптимальных цен тщательно скрываются бизнесами". Настолько тщательно, что уже на следующий день после установки новой цены - прежняя формула невосстановимо забывается. При этом каждая такая "формула" часто вообще не формализуется, ее невозможно произнести вслух, записать значения фичей, посылов, мотивов. Либо они ложные, притворные, благовидные.
Причина забывчивости такова: решения об установке внутренних цен на важнейшие сырьевые товары (зерно, металлы, лес, цемент итд) и средства производства (землю, станки, машины) и недвижимость - принимают собственники (бизнеса), как правило, единолично. Причем в обстановке сильного информационного шума (шторма, хаоса, потока ангажированной пропаганды, дезы и, конечно, рекламы). Решение рождается в произвольный момент времени суток. Для собственников установка новой цены - та же спонтанная покупка (читай - продажа), изучение природы которой зашло в тупик. Хотя методы ее провоцирования хорошо известны и даже развиваются, рецидивы - растут.
В силу своего положения - собственники не докладывают аналитикам и нигде не фиксируют кто и что им сказал накануне, донес, пообещал или погрозил, как это иногда делает тот же ФАС. Поэтому на кривую эластичности спроса накладывается личностный фактор, который дифференцирован в моменте. На цену "от хозяина" влияют "особы, приближенные к императору", случайные гости, инфоцыгане, родственники, т.е. все лица из огромного круга общения. Круг этот вряд ли подлежит систематизации, как и их "фичастость".
Оптовые цены производителей на сырье, средства производства и недвижимость колеблются в таких же широких пределах, как и розничные (и давят на них снизу, с временным лагом на оборачиваемость). Вот почему оптимальную цену сложно получить средствами ML, т.к. часть важных фич недоступна и неизмерима. Но работа в этом направлении однозначно выявит взаимосвязи, появятся новые метрик, от уровня гормонов принимающих решения по ценам (медицинский DS) до индикаторов потребительского напряжения (фичинжиниринг статпоказателей и расчет новостных фонов на базе категоризации инфо-поводов с NLP).
Предохранитель, если сделает backfill (заливку аномального пика или "пустоты" первым текущим валидным значением) - вряд ли что-то испортит. Он не не завысит сумму налога и вряд ли приведет к судебному иску. Не остановит дымосос и не устроит аварию.
А вот без него - "кривой" дэшборд из-за ручной правки базы после выпадения данных какого-нибудь сенсора - запросто может породить офисный кризис с разборками, увольнением и сокращением целых отделов. Самодуров и лихих на расправу руководителей - хватает везде. Плюс это функция времени пребывания на посту, возраста и влияния "банно-саунного" менеджмента. Поэтому каждый такой предохранитель - спасенные судьбы линейных руководителей. Статья полезная, вот прям слышу как наши побежали что-то подобное делать.
Монопольное положение (>80% всех "учетных" АРМ в стране, это ~3 млн. пользователей) - обязывает и расслабляет одновременно. Доля ARM только сейчас начала с ноутбуками проявлять себя. Бухгалтерия на Orange Pi 5 будет смотреться здорово и бесшумно.
Хорошая идея - использовать численные методы для пешего маршрута. Но есть стоп-факторы:
1) Низкое разрешение горизонталей делает авто-маршруты непригодными в горах. Любая карта - это упрощенная модель местности, а OpenStreetmap (лучше https://opentopomap.ru) - слишком упрощена. Сравните: на военных секретных, но всюду утекших картах Генштаба 1986-1998 гг. 1:50000 (в 1с м - 500 метров) - число узлов (поворотов) одной горизонтали на планшете составляет ~8 тысяч, а в рельефе OSM/NASA - меньше ~1 тыс. Это приводит к тому что 3/4 оврагов, ущелий, каньонов - вы не увидите, если их не обозначили вручную. Состояние этой работы для туристически активного Юга РФ (Кубань) - примерно 5% от реального.
2) При автопрокладке маршрута нужно избегать бродов, спусков в лощины, труднопроходимых зарослей, безлесных участков на солнцепеке, каменпадо- лавиноопасных мест итд. Всего этого в решении нет, хотя прикрутить - можно. Сюда можно добавить и полезную дичь, типа преимущества участков с покрытием GSM-связью, наличие родников, стоянок, или видимость геостационарных спутников связи (прмерно по пути солнца на небосводе).
Предложения: помимо рисования OSM - использовать другие данные с OSM-проекта, а именно GPS-треки реального прохождения маршрута "ножками" (нужно убрать оттуда джиперские и иные моторизованные забеги). Скорость прохождения любого отрезка (разница в Timestamp записей точек) - неплохо характеризует техническую сложность (но содержит также накопленную усталость, "физику" туриста, несущего навигатор, его груз, и иные "сезонности"). Нужны DS-технологии для очистки треков, ну а главное - нужны ГШ-горизонтали. Но вот так просто взять их и нарисовать в OSM - нельзя. Нельзя даже втупую перенести все названия хребтов и урочищ с ГШ в OSM - копирасты и бояки откатят ваши правки. А раз нет рельефа - нет и маршрута. Из опыта - примерно 5% любого горного похода идут не по маршруту, а напролом, "по азимуту", в результате потере тропы или просто потому что нашли путь лучше (новую тропу/волок). Элемент случайности - такой же завлекающий фактор в походе, как и красоты. Походим пока без авто-маршрутов.
Успех Питона парадоксален. Сторонники простых объяснений видят причину в ученых и студентах, а также "тех кто после курсов". Но датасатинисты/студенты точно не вывезли бы эту популярность. И ответы на stackoverflow (где язык тоже в топе) понаписали точно не они, а вполне профессиональные программисты (возможно владеющие и др. ЯП). Видимо малословность, срезы, списки/словари и прочий плюшки завлекли и опытных кодеров.
"Питоновость", python-style код - не пустые слова, это всегда кратко и понятно. Кто-то добавит: "... И медленно!", но будет неправ, поскольку почти все медленные места расшиваются использованием быстрых библиотек, написанных на быстрых языках, но (часто) специально для питона (numpy). Либ 400k+ и они все свободны. Легкость кодинга позволила очень много понаписать сайтов (django) и бизнес-логики, а в экономических расчетах Python потеснил даже Excel. Так что электорат языка постоянно и разнообразно вовлечен в широчайший спектр отраслей, профессий, документов, веба и хобби. Ни малейшего признака стагнации, как, скажем, в ... (добавить почти любой язык, клюющий носом вниз в рейтингах, таких - десятки).
Сохраняет лидерство Пиоон в т.ч. и потому что ругают его часто как раз за его сильные и принятые сообществом стороны (классы, наследование, декораторы, отступы вместо скобок). Попытки убедить в том что это плохо или реализовано неправильно - вызывают ~смех~ обратную реакцию роста любви к языку.
Назову не отечественные, но зато сразу две свободные не то что BI-платформы, но пригодные для создания BI-дэшбордов не хуже PowerBI/Qlik/Tableau, к концу третьего дня работы с ними:
Apache Superset
Streamlit
И если Superset прямо сложный и большой (и сразу в Docker), то Streamlit - простой и вполне легко осиливается средним бизнесом (это который до 100 млрд выручки в год, что примерно соответствует нижней части списка Top-100 РФ РБК, с численностью в таких компаниях 2-5k человек). Именно этот средний бизнес и является основным мотором экономики, именно он дремуче-бумажен, именно ему так не хватает "живого" BI, не отягощенного многомиллиоными платежами за лицензионное ПО и откат-консалтеров.
Сама аналитика (SAC, OLAP) для построения дэшбордов - легко собирается в тетрадках/блокнотах Jupyter на Python+Pandas по данным 1С, с небольшой примесью чистого SQL для получения данных из всевозможных CRM/СКУД/SCADA, в это обязаны уметь все современные экономисты (и многие уже умеют). Использование Python часто идет под флагом прототипирования/MVP, но почему-то все чаще оказывается вполне "продактским" и не падает годами. Видимо дэшборды и их созерцание - неспешно-медитативны , и оптимизаций, которые все ломают, тут никто не просит и не делает.
Есть еще одна причина - часть батарей можно перепродать гораздо дороже, чем лом по цене 21 руб./кг.
Насчет все рассортировать: средний российский завод потребляет лома в сутки - "кучку". Размеры кучки - 100м*20м, высотой 4-5 метров. Это 3-5 тыс. тн. лома, состоящие из примерно 1 млн. "предметов". Их контролем за сутки занимается около 10-30 человек. Зрительная нагрузка - колоссальная.
На практике попадается всё: сплющенные баллоны с хлором, заклинившие снаряды в артиллерийских стволах и прочие "подарки". На любом заводе раз в год что-то да взрывается, но как правило без серьезных последствий. Для этого существуют определенные регламенты поведения персонала (например, не находиться в течение первых 5 мин возле Печи после включения электрической дуги после каждой очередной подвалки лома). Есть специальные безопасные зоны, куда не долетит горячий шлак, брызги металла и окалина в случае взрыва. Спецодежда и СИЗ.
Обнаружение взрывоопасных предметов - хорошая задача для ML/CV, потому что глаз у людей замыливается, лом слишком неоднороден.
Вот именно потому что плохого лома немного (0,5 млрд. тн) и еще в 100+200 раз больше запасов чистой железной руды (1-2 место по величине запасов, кстати, занимает РФ и Украина) - именно поэтому мы имеем дело с проблемой будущих поколений.
Виноват во всем и всегда лишь один человек, генеральный директор, Но это по закону. Де факто виноваты двое: сталевар Вася и шихтовщик Петя, которые решили "выполнить план ради премии" и таки-загрузили в корзину тот самый латунированный лом.
На деле собственники все штрафы относят прямо или косвенно на персонал, т.к. другие статьи сэкономить крайне трудно. Были кейсы трагедии в Трансвааль-парке и др., но случаи рекламаций редко публикуются и доходят до kad.arbitr.ru Так что статистики считай что нет.
Да, но выход найден :-) Многократные переплавки лома (на 40-75% это автомобильный лом) сопровождаются неизбежным попаданием цветмета (латунные, бронзовые, медные детальки, в основном электротехнические) в сталь. Это приводят к постепенному накоплению меди (Cu) в стали (Fe 0.98-0.999, C 0.001-0.02). Даже мизерная доля меди сильно уменьшает прочность стали на разрыв, кручение, свариваемость итд. Имеющимися в XXI в. технологиями металлургии - атомы меди из расплава железа убрать нельзя никак - они прочно удерживаются кристаллической решеткой Fe.
Поэтому в мире около 0,5 млрд. тонн металлолома уже не подлежат переплавке из-за "замеднения". Они лежат мертвым грузом, иногда перепродаются простакам, но в основном лежат.
Заводы, имеющие доступ к железной руде, могут лишь по чуть-чуть подмешивать такой замеднённый лом в чугун или сталь из чистой Fe-руды. Но судя по растущей динамике накопления замеднённого лома - никто из крупных заводов в мире это массово не делает, т.к. это хлопотно и опасно - можно привести к браку всю плавку, а это 50000-200000$ убытков, расписанные на всю виновную смену (100-500 человек).
Поэтому металлурги всех стран
соединяйтесьдружно решили спихнуть эту проблему на плечи будущих поколений. Это разумно, т.к. "глобальное тепло" или инопланетное вторжение могут слегка поменять повестку в "следующий" раз, когда наступит очередной повод задуматься о судьбе планеты.DALL-E уже самобытен, и при этом "стоит на плечах" художников. Это два важнейших требования к искусству - быть непохожим и похожим одновременно. Восхищение сложность полотна от рук человека "не сильнее" сложности от полотна от ИИ. Оно просто другое.
Осталась требование эстетики, сверх-детализации и душевности. Ну, чтобы закрыть стили "реализм" итп. Это вопросы переобучения и мощностей железа, т.е. со временем решаемые. Бездушность тоже лечится добавлением фич в модель, нужно просто разметить данные, чем люди скоро и займутся, прячась по норам от торнадо или радиоактивных осадков.
ИИ не отнимет работу иллюстраторов, а сделает ее легче. DALL-E со товарищи будут по нарастающей теснить людей-художников на всех выставках, во многих жанрах живописи, в т.ч. технически сложных. Но отношение к нему так и останется дискриминационным - как к альтернативному арту. Но все-таки это уже искусство.
Согласен с автором. Кол-во доступных в Сети админ-скриптов для типовых админ-задач на Python vs Go соотносится, имхо, 50:1. Это хороший знак начать именно с Python. А дальше - Go. Языки Bash/CMD смотрится анахронизмом в наше время. Под Windows - админ-задач, пожалуй, до сих пор большинство, а там одни кодировки могут довести до красноглазия, не говоря про экранирование символов, работу с файлами и сетевыми пакетами итд. PowerShell под Windows не стал админ-тулом №1 (имхо).
Для грепа и построения внутренних web-сервисов у Python много "помогаек" в виде либ pandas, numpy, gradio, streamlit, их автор не упомянул. "Проблема скорости" Python с этими либами становится несущественной - многие из них написаны на быстрых и очень быстрых языках.
Аналитики, увы, тоже "ищут под (своим) фонарем", поскольку невозможно успеть собрать, имхо, и половину всех доступных данных. Погода, новостной фон, курс USD на Али, индекс числа распродаж конкурентов к их общему числу, единовременные массовые выплаты итд - все просто не успеть объять. А если речь не о ритейле, а о заводе, то вопрос "на чем больше заработали на прошлой неделе" - получит точный ответ 25/10/2022 г., после сдачи квартальной декларации по налогу на прибыль. Т.е. "посмертно".
Поэтому простые и понятные метрики типа среднего чека пока что "рулят" и будут рулить вечно. И даже их можно улучшить простыми методами. Например поделить на число сейлзов, вышедших на работу, чем резко улучшить объективность этого показателя.
Первым консультантом был Змей из Эдема (убедил-таки Еву грызануть яблочко), но большинство эффективных предприятий стали таковыми безо всякого внешнего бизнес-консалтинга, тем более что появился он недавно.
Популярность бизнес-консалтинга основана на success-story и воодушевляющих метриках, которые звучат правдоподобно и даже частично проверяемы. Но почти всегда имеет место чудовищная манипуляция: все позитивные сдвиги в "зеленую" зону - однозначно приписываются исключительно эффекту внедрения того, что сказали консультанты. А собственные успехи и прежние достижения коллектива - намеренно дезавуируются и "стираются" консалтерами, как вреднейшая привычка и "пережиток". Часто эти действия горячо одобряются собственником, который "...так и знал что работают одни идиоты".
Консалтеры весьма преуспели в умножении на 0 всего позитивного, для этого разработаны эффективные практики по "выключению" из процесса особо умных и несговорчивых (на которых не распространишь коммерческий подкуп). Иное мнение, а также сомнения - всегда признаются саботажем передового опыта, нарушением регламентов итд.
Исход консалтинговых фирм с баснословными расценками и с тем инструментарием, какой они практиковали в РФ - скорее благо, чем зло. Хотя оставшихся без работы людей, безусловно, жалко.
Статья понравилась. Не кодом, который почти что ужасен, а темой макросов в графических пакетах. И вангую рост потребности в них, геометрический. Видел воочию сколько кода на VBA в CorelDraw в немецких дизайн-студиях и рекламных агентствах. Его там много (в наших нет, можно сказать, вообще). Это GUI-утилиты полезняшки, в основном реализующие компоновочные решения при верстке, а также пакетные операции с фото, символами строк итп.
Доля Корела в Германии высока, примерно 40% (остальное условно назовем AI, и это искусственный интеллект, а Adobe Illustrator). В нашей стране официально за CorelDraw не более 25%, но много пиратки в регионах, в каждой студии он имеется (дистр корела легко и бесследно прячется, в отличие от продукции Adobe). Не могу сказать про госструктуры, но на пиратке-кореле там тоже активно рисуют, видел в около-выставочном окружении двух наших главных мероприятий в стране. В условии цейтнота и оргсуматохи ам и не такое можно увидеть.
Так вот, в труде граф. дизайнера оказалось неожиданного много около-текстовой рутины, которую VBA или Python могут взять на себя. Так как горячие клавиши недоступны части особо гордых людей - то только макросы могут повысить производительность труда до приемлемого европейского уровня. Да, он там выше. Я не видел в Германии дизайнеров, не умеющих печать вслепую или просто быстро. Ctrl+D они умеют все.
InkScape - наиболее импортозамещающий свободный пакет из всей векторной графики. Дивизионы Corel и Adobe в РФ хвалились десятками миллионов и даже миллиардом выручки в долларах, так что вопрос не праздный. Python в InkScape, расширения на нем - позволяют делать очень многое, и скорее всего обеспечат технологическое лидерство тем компаниям, которые их освоят, а не будут продолжать платить по 1 млн. руб. за рабочее место на инструментах Adobe. Данная статья - хороший старт, чтобы знать что оно вообще возможно и даже работает.
Даже если предположить что все люди, их глаза и мониторы, освещенность рабочих мест одинакова, то в сухом остатке остаются два отличия, которые как раз и объясняют всё:
Программистам, дата-сайентистам, полиграфистам, дизайнерам - приятней темная тема из-за "мягкой" разноцветной подсветки синтаксиса кода или текста. Их тексты - "электронны";
Редакторам печатных изданий, секретарям, бухгалтерам, юристам итп - приятней светлая тема, из-за монохромности, "бумажности" их текстов.
Но не только цвет текста. Программисты в среднем перечитывают код 6-8 раз, "пятнами", у них нет значимых опечаток из-за авто-дополнения в IDE, они сами выбирают себе все - цвет, жирность шрифта и цветовую гамму. И монитор они выбирают часто сами. И сидят чаще не светлых переговорках, а в темных серверных.
Редакторы/секретари - совсем другое дело: перечитывают текст меньше, в среднем 3 раза, но "сверху-вниз", у них нет авто-дополнения, они не могут поменять себе цвет, жирность шрифта и цветовую гамму. И монитор они выбирают реже, а сидят часто в светлых местах.
Отсюда и разные подходы. Иногда функции кодера/редактора совмещаются, а значит эти люди темное/светлое будут чередовать. Все это я вижу вокруг, у десятков людей в большом холдинге.
Исследования из статьи интересны, но как верно подмечено, однобоки и не описывают этих самых "двух отличий". Для себя сделал вывод что лучше всего провести свое исследование. Но актально оно будет только мне самому, потому что степень совмещения кодер/редактор у каждого своя.
MSO больше не продается бизнесу, значит импортозамещение - нужно всем, не только госорганам. Отсутствие OpenOffice|LibreOffice в "Реестре" не исключает возможность его использования даже в госорганах. И уж тем более под групповыми политиками (которыми скоро тоже будет негде рулить)
LibreOffice как раз наиболее реальный "импортозаместитель" MSO - в силу 100% доступности юзерам с ограниченными правами (без прав инсталляции), из-за реально высокой скорости работы и функционала, соразмерного с MSO и превышающего функционал конкурентов.
Все тесты в которых в статье "выиграл" VBA + MS Excel -- LibreOffice Calc выиграет, если задействовать другой встроенный в него язык программирования, не требующий, как и VBA, установки, также имеющий IDE c автодополнением и интроспекцией. Я о языке Python. Да и сам LibreOffice работает в режиме Portable, т.е. просто распаковывается на любой диск, раздел, флешку (занимая там ~1 Гб) .
Чтобы Calc c Python обогнал MS Excel c VBA в несколько раз - нужны сторонние библиотеки Pandas и Numpy (написаны на С++, Fortran итд), которые можно как установить через pip, а можно просто скачать и распаковать. Подробности описал тут: https://forumooo.ru/index.php/topic,8696.0.html Именно возможность тайком бесплатно распаковать LibreOffice с подкапотным Python и использовать в т.ч. и в госконторах - делает его растущим и перспективным средством офисной автоматизации.
Плохой не Python и Pandas, плохой был первичный код, который в оригинале статьи - отсутствует. Статья понравилась. Она на самом деле повествует о том что несколько сомнительных преобразований сделали зачем-то в Pandas, причем обернули их во вложенные функции, вызов которых в Python и мн. других динамических языках - дорог. Писали, например, датасатанисты, которые в Pandas делают все, даже файловые операции. Видимо это работало, приносило прибыль. Но прод затребовал realtime. Дальше классика. Оптимизировал программист, наивно, без Pandas, на чистом Python и получил... внезапный прирост в ~100 раз. Ничего удивительного что плохой код можно улучшить многократно, просто переписав его "на месте", тем же языком, только правильно.
А вот все дальнейшие оптимизации были стандартны и предсказуемы. Они дали ускорение с 12 сек. до 0,2 сек. (в 60 раз), что хорошо подтверждается другими подобными статьями и кейсами. Но там никакого чуда нет - вынос тяжелых функций в C/Numba/Nuitka итд хорошо известен. Да, однопоточный Python медленнее статических многопоточных языков в ~60 раз, это всем хорошо известно и питонистами не оспаривается. Потому что в 98% задач это замедление незаметно никак. А если вспомнить что на Питоне пишется в в 100 раз быстрее - то рост его популярности становится не таким уж парадоксальным.
Вывод: не стоит никого отговаривать данной статьей. Одни программисты ошибаются - другие исправляют, третьи пишут статьи с процентами ускорения вместо более понятных кратностей, видимо, для пущей важности. В промилле было бы еще быстрее.
Очень интересная статья с т. зр. применения DS. Рискну подтвердить догадку автора что "формулы оптимальных цен тщательно скрываются бизнесами". Настолько тщательно, что уже на следующий день после установки новой цены - прежняя формула невосстановимо забывается. При этом каждая такая "формула" часто вообще не формализуется, ее невозможно произнести вслух, записать значения фичей, посылов, мотивов. Либо они ложные, притворные, благовидные.
Причина забывчивости такова: решения об установке внутренних цен на важнейшие сырьевые товары (зерно, металлы, лес, цемент итд) и средства производства (землю, станки, машины) и недвижимость - принимают собственники (бизнеса), как правило, единолично. Причем в обстановке сильного информационного шума (шторма, хаоса, потока ангажированной пропаганды, дезы и, конечно, рекламы). Решение рождается в произвольный момент времени суток. Для собственников установка новой цены - та же спонтанная покупка (читай - продажа), изучение природы которой зашло в тупик. Хотя методы ее провоцирования хорошо известны и даже развиваются, рецидивы - растут.
В силу своего положения - собственники не докладывают аналитикам и нигде не фиксируют кто и что им сказал накануне, донес, пообещал или погрозил, как это иногда делает тот же ФАС. Поэтому на кривую эластичности спроса накладывается личностный фактор, который дифференцирован в моменте. На цену "от хозяина" влияют "особы, приближенные к императору", случайные гости, инфоцыгане, родственники, т.е. все лица из огромного круга общения. Круг этот вряд ли подлежит систематизации, как и их "фичастость".
Оптовые цены производителей на сырье, средства производства и недвижимость колеблются в таких же широких пределах, как и розничные (и давят на них снизу, с временным лагом на оборачиваемость). Вот почему оптимальную цену сложно получить средствами ML, т.к. часть важных фич недоступна и неизмерима. Но работа в этом направлении однозначно выявит взаимосвязи, появятся новые метрик, от уровня гормонов принимающих решения по ценам (медицинский DS) до индикаторов потребительского напряжения (фичинжиниринг статпоказателей и расчет новостных фонов на базе категоризации инфо-поводов с NLP).