Да, стало бы значительно дольше писать тот же код, мучительно сложно придумывать созвучные типу имена. И скорости Питону это не прибавило бы нисколько.
Выбирая динамический язык - мы клянемся себе в аккуратности в обмен на быстрое прототипирование. А в статическом языке, пока пропишешь все объявления - запал пропадает, вплоть до нехоти. Питон не даёт простоя идеям. В утилитах, DataScience и админ-скриптах на страничку - это важно. В больших программах и для команд в 5+ разрабов - стоит подумать ещё раз о смене языка на статический компилируемый
Немного в защиту лежачего. Возьмем, к примеру, реальный завод с 2 тыс. работников и 30 млрд. выручки в год. Статистика локального GitLab сервера говорит мне о том что 70% нашего кода написано на Python, и что это DS/ML-код и админ-утилиты или web-приложения "по требованию". Этот код постоянно дописывается, буквально ежедневно. Админ-утилиты, DS-утилиты, MVP-продукты - это тоже "инструментарий", против которого озаглавлена статья. Но позвольте, если что-то постоянно дописывается - компилируемый язык будет хуже интерпретируемого. Статический будет хуже динамического. И да, простой requirements.txt на сетевой шаре достаточен для 99% рабочих мест. Даже виртуальное окружение тут избыточно. Даже при ежедневном бездумном каскадном обновлении всех либ - поломка случается пару раз в год. Windows BSOD-ит и то чаще.
Если ваш py-код нужно защитить на уровне 80% других защищенных программ - есть готовые либы для этого. Для оставшихся 20% есть вынос функций в зашифрованные С-либы/exe. Или да, используйте другие языки программирования. Правда это почти никого никогда ни от чего не спасло. Но я охотно приведу примеры серийных, тиражных, общеизвестных дорогостоящих платных программ (стоимостью 800-3500 евро), которые десяток лет кряду(!) никто не смог взломать. По странному стечению обстоятельств это музыкальные программы/DAW: Steinberg Cubase/Nuendo и Propellerhead Reason Studio. Их перестали ломать после того как заметную часть двух хакерских группировок... взяли на работу в эти самые компании, для защиты ПО от себе подобных. Это сработало, но стоило компаниям очень дорого - их на рынке сильно потеснили более дешевые альтернативы. А часть халявщиков, исчислявшаяся миллионами - отвернулась, утратив возможность крякать свежие версии. Одним словом, защита ПО невероятно сложна и решаема она экзотическими, часто неповторимыми более методами. Ставить в укор Python-у то что его код слишком открыт - некрасиво.
Типизация, как и проблема смешивания табуляции и пробелов в Python-коде - абсолютно надуманы. Их давно, лет уже как пять, нет. Современные IDE могут навсегда вам запретить присваивать переменные без указания типа. Любая попытка отладки/запуска - даcт ошибку линтера. Сразу. Это ничем не отличается от поведения компилируемых языков, разве что в Python выдаст сбой мгновенно, а в других нужно секунды подождать.
Символ табуляции вы при всем желании не введете в IDE (он будет заменен на 4 пробела). Но эти две страшилки (про типизацию и табуляцию) - мы с уверенностью обнаружим в каждой анти-змеиной статье или ее обсуждении. Становится просто смешно. И страшно за молодежь, принимающую такие страшилки за чистую монету. Приходится уговаривать людей проверить самим такое поведение в IDE.
Питон есть за что ругать - за медлительность, за вариативность путей достижения целей, не по дзену, и еще раз за медлительность. Но ругать его за массово признаваемые его же плюсы - несерьезно.
Отталкиваться нужно от расчётов. Рыночных цен it-проектов вы нигде не найдёте. В статье логичный и употребимый процесс описан верно и полезно. Менеджер может по опыту других проектов поставить трудозатраты за всех. Все равно сумма умножается на 2...3, ошибка некритична.
Не путайте конфигурацию сервера 1С и клиентских АРМ на aarch64/amd64. Толстый клиент 1C на АРМ буха не просит больше 2 Гб RAM. Самые большие типовые таблицы/отчеты из 1С, - скажем, Отчет по Закупкам компании с выручкой 20 млрд. в год, за 5 лет - потребуют еще 1-2 Гб RAM. Это вполне посильные объемы для одноплатников размером с кредитку и ценой 3-6 тыс. руб. И это не тонкий клиент, а полноценный десктоп с Linux и офисным софтом. На минималках.
Предохранитель, если сделает 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 раза, но "сверху-вниз", у них нет авто-дополнения, они не могут поменять себе цвет, жирность шрифта и цветовую гамму. И монитор они выбирают реже, а сидят часто в светлых местах.
Отсюда и разные подходы. Иногда функции кодера/редактора совмещаются, а значит эти люди темное/светлое будут чередовать. Все это я вижу вокруг, у десятков людей в большом холдинге.
Исследования из статьи интересны, но как верно подмечено, однобоки и не описывают этих самых "двух отличий". Для себя сделал вывод что лучше всего провести свое исследование. Но актально оно будет только мне самому, потому что степень совмещения кодер/редактор у каждого своя.
Да, стало бы значительно дольше писать тот же код, мучительно сложно придумывать созвучные типу имена. И скорости Питону это не прибавило бы нисколько.
Выбирая динамический язык - мы клянемся себе в аккуратности в обмен на быстрое прототипирование. А в статическом языке, пока пропишешь все объявления - запал пропадает, вплоть до нехоти. Питон не даёт простоя идеям. В утилитах, DataScience и админ-скриптах на страничку - это важно. В больших программах и для команд в 5+ разрабов - стоит подумать ещё раз о смене языка на статический компилируемый
Немного в защиту лежачего. Возьмем, к примеру, реальный завод с 2 тыс. работников и 30 млрд. выручки в год. Статистика локального GitLab сервера говорит мне о том что 70% нашего кода написано на Python, и что это DS/ML-код и админ-утилиты или web-приложения "по требованию". Этот код постоянно дописывается, буквально ежедневно. Админ-утилиты, DS-утилиты, MVP-продукты - это тоже "инструментарий", против которого озаглавлена статья. Но позвольте, если что-то постоянно дописывается - компилируемый язык будет хуже интерпретируемого. Статический будет хуже динамического. И да, простой requirements.txt на сетевой шаре достаточен для 99% рабочих мест. Даже виртуальное окружение тут избыточно. Даже при ежедневном бездумном каскадном обновлении всех либ - поломка случается пару раз в год. Windows BSOD-ит и то чаще.
Если ваш py-код нужно защитить на уровне 80% других защищенных программ - есть готовые либы для этого. Для оставшихся 20% есть вынос функций в зашифрованные С-либы/exe. Или да, используйте другие языки программирования. Правда это почти никого никогда ни от чего не спасло. Но я охотно приведу примеры серийных, тиражных, общеизвестных дорогостоящих платных программ (стоимостью 800-3500 евро), которые десяток лет кряду(!) никто не смог взломать. По странному стечению обстоятельств это музыкальные программы/DAW: Steinberg Cubase/Nuendo и Propellerhead Reason Studio. Их перестали ломать после того как заметную часть двух хакерских группировок... взяли на работу в эти самые компании, для защиты ПО от себе подобных. Это сработало, но стоило компаниям очень дорого - их на рынке сильно потеснили более дешевые альтернативы. А часть халявщиков, исчислявшаяся миллионами - отвернулась, утратив возможность крякать свежие версии. Одним словом, защита ПО невероятно сложна и решаема она экзотическими, часто неповторимыми более методами. Ставить в укор Python-у то что его код слишком открыт - некрасиво.
Типизация, как и проблема смешивания табуляции и пробелов в Python-коде - абсолютно надуманы. Их давно, лет уже как пять, нет. Современные IDE могут навсегда вам запретить присваивать переменные без указания типа. Любая попытка отладки/запуска - даcт ошибку линтера. Сразу. Это ничем не отличается от поведения компилируемых языков, разве что в Python выдаст сбой мгновенно, а в других нужно секунды подождать.
Символ табуляции вы при всем желании не введете в IDE (он будет заменен на 4 пробела). Но эти две страшилки (про типизацию и табуляцию) - мы с уверенностью обнаружим в каждой анти-змеиной статье или ее обсуждении. Становится просто смешно. И страшно за молодежь, принимающую такие страшилки за чистую монету. Приходится уговаривать людей проверить самим такое поведение в IDE.
Питон есть за что ругать - за медлительность, за вариативность путей достижения целей, не по дзену, и еще раз за медлительность. Но ругать его за массово признаваемые его же плюсы - несерьезно.
Отталкиваться нужно от расчётов. Рыночных цен it-проектов вы нигде не найдёте. В статье логичный и употребимый процесс описан верно и полезно. Менеджер может по опыту других проектов поставить трудозатраты за всех. Все равно сумма умножается на 2...3, ошибка некритична.
Не путайте конфигурацию сервера 1С и клиентских АРМ на aarch64/amd64. Толстый клиент 1C на АРМ буха не просит больше 2 Гб RAM. Самые большие типовые таблицы/отчеты из 1С, - скажем, Отчет по Закупкам компании с выручкой 20 млрд. в год, за 5 лет - потребуют еще 1-2 Гб RAM. Это вполне посильные объемы для одноплатников размером с кредитку и ценой 3-6 тыс. руб. И это не тонкий клиент, а полноценный десктоп с Linux и офисным софтом. На минималках.
Предохранитель, если сделает 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 раза, но "сверху-вниз", у них нет авто-дополнения, они не могут поменять себе цвет, жирность шрифта и цветовую гамму. И монитор они выбирают реже, а сидят часто в светлых местах.
Отсюда и разные подходы. Иногда функции кодера/редактора совмещаются, а значит эти люди темное/светлое будут чередовать. Все это я вижу вокруг, у десятков людей в большом холдинге.
Исследования из статьи интересны, но как верно подмечено, однобоки и не описывают этих самых "двух отличий". Для себя сделал вывод что лучше всего провести свое исследование. Но актально оно будет только мне самому, потому что степень совмещения кодер/редактор у каждого своя.