Да не то, чтобы - скорее, программистам она изначально и не нужна была. Таска в трекере, постановка в вики, код в git'е - и "Программировай!"
А вот координация работ в рамках крупного проекта, который ведет *цать участников - таки ой. Скорее всего почта окажется "общим знаменателем" - распределенная, fault-tolerant за счет этой самой "распределенности", дает минимальный уровень "неотказуемости" с практически нулевыми накладными, даже поиск больмень работает - в общем, если не пытаться превращать в "систему электронного документооборота" или прости осспыдя, "файлообменник" - то живее всех живых и альтернатив на горизонте того-этого... не вырисовывается.
Нееее... в моем понимании, "фрактал звиздеца" несколько более многогранен.
А кто сказал, что приложение вот с этим набором зависимостей запустится на вот этой версии интерпретатора\ос?
А какие из зависимостей можно задаунгрейдить не поломав все к чертям?
А можно ли использовать более старую версию самого приложения\библиотеки?
А что делать с зависимостями, которые требуют вот сборки кода? Ну, какой-нибудь драйвер для постгре?
А есть ли версия вот этого вот драйвера под эту вот ХП?
А будет старая версия работать с вот этой вот версией постгри (Привет, tls 1.3)?
Тут даже наличие интернета не всегда спасает, если что...
Контейнеризация приложений с рантаймом помогает... не всегда. В том плане что немае под XP доскеров да и под, например, mac m1 собирать надо отдельно. Пару раз неожиданно выручал даже не pyinstaller, а вовсе nuitka - но то прям ОЧЕНЬ такоЭ.
Ниет. В смысле, он туда определенную версию интерпретатора запихнет - и на ХПшке она работать не будет, да и кроссплатформенно собрать - не выйдет, насколько я помню.
ЕМНИП, там создание ветки - что-то вроде симлинка, вот работа со слияниями - таки боооль, но с учетом того, что (у нас) базовый флоу и не предполагал "по-ветке-на-фичу" - не то, чтобы совсем уж жить мешало...
Нееее... все не так страшно - гит уже ушел куда-то на уровень "инфраструктуры" и большинство людей просто не имеют с ним дела. Ну, примерно как с TCP\IP - он абсолютно ужасен, мало кто понимает, как ЭТО работает в реальной жизни со всей её разнообразием - но всем примерно "пофиг" и нужды лезть в какой-нибудь wireshark последние лет 20 у абсолютного большинства людей не возникает. Так и с git'ом - ну да, страшно. Ну да, ужас - но если аккуратно тыкать его трехметровой палкой через прослойки клиентов-ide-web-service'ов и работать условно не с "git'ом" а с "github'ом" - то оно и ничотак, жить можно. Ну да, периодически конечно случаются... удивительности вида "дактожзналото?!!!" - но чем дальше, тем меньше с т.з. обычных людей.
Есть перечень бизнес-процессов, обеспечиваемых набором ИТ-систем. Ролевые модели интегрированы с AD с кодификацией имен ресурсных групп. Есть оргструктура предприятия в виде набора OU, есть иерархия сотрудников, построенная через поле manager. Задача - визуализация + поиск аномалий с возможностью смены детализации (граф больше 100к узлов) и переходу к метаинформации.
Делал через запись дампа АД в бд с версионностью, операции на графе с помощью redisgraph, визуализация через генерацию графов server-side на лету "по первому обращению", при смене хэша - перегенерация, заняло около двух недель - и вроде даже все еще используется.
Я для решения (как мне кажется) схожей задачи (Визуализации оргструктуры предприятия - проектов - полномочий по данным из AD с возможностью перключения детализации между уровнями\слоями) использовал graphviz + графовую бд с оберткой на фласке - предполагаю, что операции по поиску на графе\отсечению\визуализации подграфов будут сильно проще\лучше реализованы - ну и в тыкву оно с ростом числа объектов не превратиться - в отличие от.
Так еще раз - "какую задачу решаем"? Зачем вам "выгружать в эксель"? Чтобы что? А связывать - зачем? Подгрузить перечень объектов по слоям? А откуда он у вас в базе? У вас есть CMDB, в которой почему-то нет возможности связывать объекты разных типов или что?
Не, ПЭО как функция - осталась, но стала централизованной и из то ли 8 то ли 12 человек на заводе сначала осталось два - а через годик ноль. Насчет соотношения зарплат и результата собственник вроде не возражал - а завод так и вовсе уменьшению ФОТа был рад - затраты на корп. функцию по другой статье идут.
Вот как раз после внедрения в Холдинге ERP ПЭО на заводах сократили. Вот прям совсем полностью - а так да, они бы конечно с удовольствием (нет) гребли бы это все и дальше - пааадумаешь, сотне человек пару неделек поразбираться\заполнять повторно пачку экселей, профакапив расходование средств в процессе? Экая, право, ерунда - никто ж не умер :).
И нет, не способны. В принципе. Инструмент не предусматривает какую-либо автоматизацию разработки\сборки\тестирования\тиражирования\масштабирования\инфобеза\недостающее-вписать вот прям совсем и провоцирует bad practice этой самой "разработки" практически во всех аспектах. 99 из 100 на выходе будет unmaintainable решение с bus factor=1 вида "выкрасить-и-выбросить". Круг задач вида "для себя и кота" - пуркуа бы не па, но подобные вещи имеют тенденцию расползаться - и замечается это все несколько позже, чем хотелось бы. Чем отвечать на вопросы "Хрен ли вы столько возитесь? Да я! Да на экселе!!! Да за две недели!!!11" - дешевле и проще негра нанять.
Оу, е. Видел я несколько раз просто ФАНТАСТИЧЕСКИ разрушительные последствия такой "наколенной автоматизации". Вот например планово-экономический отдел крупненького завода додумался вести планы\бюджеты отделов в эксельках на файловом сервере в структере папОчек и консолидировать их отдельной экселькой с кучей где абсолютных, а где относительных ссылок с прелессстями вида "бюджет_последняя_неудалять!!!.xlsx", "самаяноваяпапка0220202" и тэ дэ - а потом структура файлового сервера чуть-чуть, самую капельку, малость - поменялось и "кровь-кишки-разэтосамило!" почти на месяц. Или пара чьюдо-кейсов с попыткой масштабировать решение на ацессе - а как "круто" получилось "в лоб" опубликовать эксельку на шарике примотав к ней пару формочек... и ведь какое-то время - работало, а потом "дактожзнал-то?! сделайтештанибудь!!!!111". Или вот замечательная идея "сделаем из эксельки и pi-datalink" сервер отчетов для MES-системы... что тут могло пойти не так?
И ведь всплывает все это обычно на стадии "тут уже ничего не спасти, г-дь, жги!!!" В общем, за SMB-сегмент не скажу, а в крупняке - за такое уже бьют. И даже иногда ногами. Идея завести специально обученного негра-гомосексуалиста-по-воспитательной-работе-с-населением пока еще не находит одобрения у HR - но при попытке воспроизвести вот этот вот "кровавого ада жопный содом" средствами R7 или там еще какой импортозамещайки - думаю, согласятся уже и они.
Эммм... языки не становились и не становятся "легче" - с чего бы? Классическая сишечка - проста, империтивное программирование какой-нибудь синхронной однопоточки - просто - но ты попробуй на этой "простоте" делать сложные вещи :). А вот современный ООП, макрофреймворки, построенные на нем - дохрена сложная штука сами по себе - но таки да, позволяют относительно успешно справляться со сложностью предметной области.
А какой NiFi взят за основу, и как собираетесь бежать за апстримом, если не секрет?
Да не то, чтобы - скорее, программистам она изначально и не нужна была. Таска в трекере, постановка в вики, код в git'е - и "Программировай!"
А вот координация работ в рамках крупного проекта, который ведет *цать участников - таки ой. Скорее всего почта окажется "общим знаменателем" - распределенная, fault-tolerant за счет этой самой "распределенности", дает минимальный уровень "неотказуемости" с практически нулевыми накладными, даже поиск больмень работает - в общем, если не пытаться превращать в "систему электронного документооборота" или прости осспыдя, "файлообменник" - то живее всех живых и альтернатив на горизонте того-этого... не вырисовывается.
Это была замечательная иллюстрация исходному комменту :)
en masse ушло в прошлое вместе с редактированием конфигурации на сервере же?
Нееее... в моем понимании, "фрактал звиздеца" несколько более многогранен.
А кто сказал, что приложение вот с этим набором зависимостей запустится на вот этой версии интерпретатора\ос?
А какие из зависимостей можно задаунгрейдить не поломав все к чертям?
А можно ли использовать более старую версию самого приложения\библиотеки?
А что делать с зависимостями, которые требуют вот сборки кода? Ну, какой-нибудь драйвер для постгре?
А есть ли версия вот этого вот драйвера под эту вот ХП?
А будет старая версия работать с вот этой вот версией постгри (Привет, tls 1.3)?
Тут даже наличие интернета не всегда спасает, если что...
Контейнеризация приложений с рантаймом помогает... не всегда. В том плане что немае под XP доскеров да и под, например, mac m1 собирать надо отдельно. Пару раз неожиданно выручал даже не pyinstaller, а вовсе nuitka - но то прям ОЧЕНЬ такоЭ.
Ниет. В смысле, он туда определенную версию интерпретатора запихнет - и на ХПшке она работать не будет, да и кроссплатформенно собрать - не выйдет, насколько я помню.
ЕМНИП, там создание ветки - что-то вроде симлинка, вот работа со слияниями - таки боооль, но с учетом того, что (у нас) базовый флоу и не предполагал "по-ветке-на-фичу" - не то, чтобы совсем уж жить мешало...
Нееее... все не так страшно - гит уже ушел куда-то на уровень "инфраструктуры" и большинство людей просто не имеют с ним дела. Ну, примерно как с TCP\IP - он абсолютно ужасен, мало кто понимает, как ЭТО работает в реальной жизни со всей её разнообразием - но всем примерно "пофиг" и нужды лезть в какой-нибудь wireshark последние лет 20 у абсолютного большинства людей не возникает. Так и с git'ом - ну да, страшно. Ну да, ужас - но если аккуратно тыкать его трехметровой палкой через прослойки клиентов-ide-web-service'ов и работать условно не с "git'ом" а с "github'ом" - то оно и ничотак, жить можно. Ну да, периодически конечно случаются... удивительности вида "дактожзналото?!!!" - но чем дальше, тем меньше с т.з. обычных людей.
Обычный офисный работник точно так же НЕ знает VBA, как и python :)
Есть перечень бизнес-процессов, обеспечиваемых набором ИТ-систем. Ролевые модели интегрированы с AD с кодификацией имен ресурсных групп. Есть оргструктура предприятия в виде набора OU, есть иерархия сотрудников, построенная через поле manager. Задача - визуализация + поиск аномалий с возможностью смены детализации (граф больше 100к узлов) и переходу к метаинформации.
Делал через запись дампа АД в бд с версионностью, операции на графе с помощью redisgraph, визуализация через генерацию графов server-side на лету "по первому обращению", при смене хэша - перегенерация, заняло около двух недель - и вроде даже все еще используется.
Я для решения (как мне кажется) схожей задачи (Визуализации оргструктуры предприятия - проектов - полномочий по данным из AD с возможностью перключения детализации между уровнями\слоями) использовал graphviz + графовую бд с оберткой на фласке - предполагаю, что операции по поиску на графе\отсечению\визуализации подграфов будут сильно проще\лучше реализованы - ну и в тыкву оно с ростом числа объектов не превратиться - в отличие от.
Но вашу задачу я все еще не представляю\понимаю.
Так еще раз - "какую задачу решаем"? Зачем вам "выгружать в эксель"? Чтобы что? А связывать - зачем? Подгрузить перечень объектов по слоям? А откуда он у вас в базе? У вас есть CMDB, в которой почему-то нет возможности связывать объекты разных типов или что?
Не-по-ни-мать.
Может я чего не понимаю - но выглядит как попытка переизобрести archimate из палка-и-веревка...
Не, ПЭО как функция - осталась, но стала централизованной и из то ли 8 то ли 12 человек на заводе сначала осталось два - а через годик ноль. Насчет соотношения зарплат и результата собственник вроде не возражал - а завод так и вовсе уменьшению ФОТа был рад - затраты на корп. функцию по другой статье идут.
А какую задачу решаем?
Вот как раз после внедрения в Холдинге ERP ПЭО на заводах сократили. Вот прям совсем полностью - а так да, они бы конечно с удовольствием (нет) гребли бы это все и дальше - пааадумаешь, сотне человек пару неделек поразбираться\заполнять повторно пачку экселей, профакапив расходование средств в процессе? Экая, право, ерунда - никто ж не умер :).
И нет, не способны. В принципе. Инструмент не предусматривает какую-либо автоматизацию разработки\сборки\тестирования\тиражирования\масштабирования\инфобеза\недостающее-вписать вот прям совсем и провоцирует bad practice этой самой "разработки" практически во всех аспектах. 99 из 100 на выходе будет unmaintainable решение с bus factor=1 вида "выкрасить-и-выбросить". Круг задач вида "для себя и кота" - пуркуа бы не па, но подобные вещи имеют тенденцию расползаться - и замечается это все несколько позже, чем хотелось бы. Чем отвечать на вопросы "Хрен ли вы столько возитесь? Да я! Да на экселе!!! Да за две недели!!!11" - дешевле и проще негра нанять.
Оу, е. Видел я несколько раз просто ФАНТАСТИЧЕСКИ разрушительные последствия такой "наколенной автоматизации". Вот например планово-экономический отдел крупненького завода додумался вести планы\бюджеты отделов в эксельках на файловом сервере в структере папОчек и консолидировать их отдельной экселькой с кучей где абсолютных, а где относительных ссылок с прелессстями вида "бюджет_последняя_неудалять!!!.xlsx", "самаяноваяпапка0220202" и тэ дэ - а потом структура файлового сервера чуть-чуть, самую капельку, малость - поменялось и "кровь-кишки-разэтосамило!" почти на месяц. Или пара чьюдо-кейсов с попыткой масштабировать решение на ацессе - а как "круто" получилось "в лоб" опубликовать эксельку на шарике примотав к ней пару формочек... и ведь какое-то время - работало, а потом "дактожзнал-то?! сделайтештанибудь!!!!111". Или вот замечательная идея "сделаем из эксельки и pi-datalink" сервер отчетов для MES-системы... что тут могло пойти не так?
И ведь всплывает все это обычно на стадии "тут уже ничего не спасти, г-дь, жги!!!" В общем, за SMB-сегмент не скажу, а в крупняке - за такое уже бьют. И даже иногда ногами. Идея завести специально обученного негра-гомосексуалиста-по-воспитательной-работе-с-населением пока еще не находит одобрения у HR - но при попытке воспроизвести вот этот вот "кровавого ада жопный содом" средствами R7 или там еще какой импортозамещайки - думаю, согласятся уже и они.
Ну, до недавнего времени дроны были примерно такой модели:
https://ura.news/news/1052521174
Ну, as for me - мне тоже кажется, что пик популярности DSL мал-мала прошел.
Эммм... языки не становились и не становятся "легче" - с чего бы? Классическая сишечка - проста, империтивное программирование какой-нибудь синхронной однопоточки - просто - но ты попробуй на этой "простоте" делать сложные вещи :). А вот современный ООП, макрофреймворки, построенные на нем - дохрена сложная штука сами по себе - но таки да, позволяют относительно успешно справляться со сложностью предметной области.