На Хабре чуть менее чем все так или иначе имеют опыт с KPI, а многие - и опыт в постановке KPI. Так что все понимают насколько тема сложная и поэтому все эти 'измерения командной работы' вызывают такое раздражение.
Так что совет - если описываете применение KPI, то лучше опишите свой опыт, и распишите до болтов - почему такой выбрали, как считали, кому считали, что было до, как стало после. С цифрами, разумеется.
Визуальным программированием 'by user' грезят давно, но за рамки нишевых решений оно не выходит и видимо не выйдет. Потому что слишком много вопросов возникает - от сопровождаемости кода до производительности.
Раз уж упомянули SAP - вы оценивали объем функционала внедренного SAP в сферической компании и объем доработок вашей платформы, чтобы этот SAP заместить? Если оценивали - то сколько получилось?
Чем вы лучше 1С? Почему какой то бизнес захочет выбрать вас, а не 1С?
Если честно то притягивание за уши ERP выглядит странно. ERP - это уже готовая система для управления предприятием, которую нужно тюнить и дорабатывать для каждого случая, но тем не менее она уже содержит огромный объем функционала. А у вас платформа для визуального программирования.
Попробуйте оценить сколько ресурсов вам потребуется для разработки функционала хотя бы уровня типовой конфигурации 1С. А потом забудьте про слово ERP.
Что то ваш комментарий анекдот напомнил: 'Ты слышал, Изя? Этот поц таки собирается учить нас коммерции!' :)
Процессы на таком большом заводе - это система уравнений с большим количеством переменных. Сомневаюсь что здесь есть простые решения вроде 'поменять цену без предупреждения'.
P.S. Задача выглядит простой, но судя по последней части рассказа было пролито немало крови и слез. Корпоративный мир он суровый :)
Вы учтите что собеседующий видит вас в первый раз в жизни.
Представьте себя на его месте - собеседуете человека и услышали от него что прошлые коллеги или начальство были мудаками, поэтому он и ушел. А чел еще подробно рассказывает что там был крут, сделал задачу, предупреждал начальство, а его не послушали, но хозяин барин.
Насколько эта история правда - хз, другую сторону вы не слышали.
И подумайте, в плюс будет все услышанное, или в минус.
Не все комментаторы понимают что Росатом - это конгломерат большого количества компаний. В каких то компаниях зарплата такая как написали выше, а где то есть и нормальная.
Люди в массе своей всегда выбирают более простой путь. Если проще скинуть задачу на админов - значит так и будут делать. Это не хорошо или плохо, просто таков порядок вещей и его нужно учитывать.
То как решили задачу в этом кейсе - тоже вариант, хотя несколько спорный :) Подозреваю что в компании топикстартера через какое то время маятник качнется в обратную сторону - админы станут недоступными полумифическими существами и их будут поворачивать лицом к пользователям.
Хорошо наверное быть вами :) Все четко и понятно - тут государство должно заставить, тут вендоры ПО должны договориться, а это вообще проблема MS офиса.
А в реальной жизни, если вы так или иначе отвечаете за миграцию на Линукс, или не приведи аллах ее инициировали - это ваша проблема. Если из за проблем с документооборотом продолбается важный договор или оплата по договору - финдир с плоскогубцами придет к вам, и про проблему стандартизации слушать ничего не станет.
Напрашивается аналогия — Генри Форд в свое время сделал ставку на массовые недорогие автомобили, в то время как они были скорее предметом роскоши и вещью не для всех.
valemak, Вы кажется не поняли смысла статьи — автор восхищается не меценатом, а бизнесменом и человеком, который мог подниматься на ноги даже после таких ударов.
По поводу лапши — сравнивать ее надо не с продуктами, которые требуют приготовления, а с другой готовой или почти готовой едой — вот тут по бюджетности ей мало конкурентов
Т.е. вы придумали свой макроязык с целью сократить размер текста запросов с пяти строчек до трех? :)
Навскидку вижу такие проблемы:
1. Нечитабельно. Чтобы вы не говорили, но любому другому программисту нужно будет привыкать к синтаксису, не говоря уж о том чтобы писать не задумываясь
2. _Не_ быстро — генерация программ занимает время, ваш сгенеренный код тоже далеко не оптимален — просто в силу своей универсальности
3. Динамическая генерация — зло. Вот так, безапелляционно :) Конечно иногда без них никак (очень редко), но если есть возможность обойтись без динамической генерации — лучше обойтись
Это интересное упражнение, такое наваять. Но именно как упражнение
Компания SAP гарантирует качество кода в своих приложениях благодаря ручному аудиту поставляемого кода
Ой, правда? Давно ли SAP это делает? В том числе гарантирует и для нот, которые поставляются например для российского аддона? Вы бы воздержались от таких категоричных заявлений, а то здесь же и SAP-консультанты есть
Например, использование оператора CALL TRANSACTION (который массово используется разработчиками) на проектах с разграничением доступа на уровне транзакций является небезопасным. Без указания WITH AUTHORITY-CHECK
Уточните пожалуйста, в каком году SAP настолько озаботился безопасностью CALL TRANSACTION, что позволил обходиться без ФМа AUTHORITY_CHECK_TCODE и добавил «WITH AUTHORITY-CHECK»?
В целом же: такой ресурс как хабр предполагает более технический уклон статей — т.е. конкретные примеры уязвимостей и конкретные же рекомендации по их выявлению и недопущению. А здесь же видим маркетинговый буллшит в стиле 'SAP — это круто', где за пример с натяжкой может сойти разве что CALL TRANSACTION (с учетом того что WITH AUTHORITY-CHECK добавили только в версии 740)
Тоже мучает этот вопрос. Вероятно команда скайпа не хочет официально признавать проблему, а неофициально техподдержка на форуме советует ее всем у кого проблемы. По крайней мере нашел я ее на форуме в ответе техподдержки на чью то жалобу
Как представитель команды сопровождения могу только сказать — надо стрелять за использование этого ФМа в продуктиве. Приходилось видеть как одно чудо правило диапазоны номеров напрямую в таблице, так как про тр. SNRO ему не говорили.
P.S. Не всегда к сожалению удается продавить отключение лишних полномочий у проектной команды (по политическим причинам)
ПС, не надо холивара, плиз, если что, я знаю все приимущества и недостатки обоих…
И в мыслях не было. Я действительно не знаю что такое systemd и upstart, но не в этом дело — просто хотел намекнуть автору что пара предложений с пояснением таких узкоспециализированных вещей были бы к месту.
P.S. спасибо за комментарий, стало немного понятней о чем речь
На Хабре чуть менее чем все так или иначе имеют опыт с KPI, а многие - и опыт в постановке KPI. Так что все понимают насколько тема сложная и поэтому все эти 'измерения командной работы' вызывают такое раздражение.
Так что совет - если описываете применение KPI, то лучше опишите свой опыт, и распишите до болтов - почему такой выбрали, как считали, кому считали, что было до, как стало после. С цифрами, разумеется.
Визуальным программированием 'by user' грезят давно, но за рамки нишевых решений оно не выходит и видимо не выйдет. Потому что слишком много вопросов возникает - от сопровождаемости кода до производительности.
Раз уж упомянули SAP - вы оценивали объем функционала внедренного SAP в сферической компании и объем доработок вашей платформы, чтобы этот SAP заместить? Если оценивали - то сколько получилось?
Чем вы лучше 1С? Почему какой то бизнес захочет выбрать вас, а не 1С?
Если честно то притягивание за уши ERP выглядит странно. ERP - это уже готовая система для управления предприятием, которую нужно тюнить и дорабатывать для каждого случая, но тем не менее она уже содержит огромный объем функционала. А у вас платформа для визуального программирования.
Попробуйте оценить сколько ресурсов вам потребуется для разработки функционала хотя бы уровня типовой конфигурации 1С. А потом забудьте про слово ERP.
Что то ваш комментарий анекдот напомнил: 'Ты слышал, Изя? Этот поц таки собирается учить нас коммерции!' :)
Процессы на таком большом заводе - это система уравнений с большим количеством переменных. Сомневаюсь что здесь есть простые решения вроде 'поменять цену без предупреждения'.
P.S. Задача выглядит простой, но судя по последней части рассказа было пролито немало крови и слез. Корпоративный мир он суровый :)
Вы учтите что собеседующий видит вас в первый раз в жизни.
Представьте себя на его месте - собеседуете человека и услышали от него что прошлые коллеги или начальство были мудаками, поэтому он и ушел. А чел еще подробно рассказывает что там был крут, сделал задачу, предупреждал начальство, а его не послушали, но хозяин барин.
Насколько эта история правда - хз, другую сторону вы не слышали.
И подумайте, в плюс будет все услышанное, или в минус.
... и долго :)
Не все комментаторы понимают что Росатом - это конгломерат большого количества компаний. В каких то компаниях зарплата такая как написали выше, а где то есть и нормальная.
К слову о крудах и сеньорах - вот что получил при попытке залогиниться на Хабр чтобы поставить лайк статье :)
Люди в массе своей всегда выбирают более простой путь. Если проще скинуть задачу на админов - значит так и будут делать. Это не хорошо или плохо, просто таков порядок вещей и его нужно учитывать.
То как решили задачу в этом кейсе - тоже вариант, хотя несколько спорный :) Подозреваю что в компании топикстартера через какое то время маятник качнется в обратную сторону - админы станут недоступными полумифическими существами и их будут поворачивать лицом к пользователям.
Хорошо наверное быть вами :) Все четко и понятно - тут государство должно заставить, тут вендоры ПО должны договориться, а это вообще проблема MS офиса.
А в реальной жизни, если вы так или иначе отвечаете за миграцию на Линукс, или не приведи аллах ее инициировали - это ваша проблема. Если из за проблем с документооборотом продолбается важный договор или оплата по договору - финдир с плоскогубцами придет к вам, и про проблему стандартизации слушать ничего не станет.
Кто без греха - пусть первый бросит камень...
А если кто то бросит - это либо память плохая, либо пока в начале пути, либо просто супермен.
По поводу лапши — сравнивать ее надо не с продуктами, которые требуют приготовления, а с другой готовой или почти готовой едой — вот тут по бюджетности ей мало конкурентов
Навскидку вижу такие проблемы:
1. Нечитабельно. Чтобы вы не говорили, но любому другому программисту нужно будет привыкать к синтаксису, не говоря уж о том чтобы писать не задумываясь
2. _Не_ быстро — генерация программ занимает время, ваш сгенеренный код тоже далеко не оптимален — просто в силу своей универсальности
3. Динамическая генерация — зло. Вот так, безапелляционно :) Конечно иногда без них никак (очень редко), но если есть возможность обойтись без динамической генерации — лучше обойтись
Это интересное упражнение, такое наваять. Но именно как упражнение
Уточните пожалуйста, в каком году SAP настолько озаботился безопасностью CALL TRANSACTION, что позволил обходиться без ФМа AUTHORITY_CHECK_TCODE и добавил «WITH AUTHORITY-CHECK»?
В целом же: такой ресурс как хабр предполагает более технический уклон статей — т.е. конкретные примеры уязвимостей и конкретные же рекомендации по их выявлению и недопущению. А здесь же видим маркетинговый буллшит в стиле 'SAP — это круто', где за пример с натяжкой может сойти разве что CALL TRANSACTION (с учетом того что WITH AUTHORITY-CHECK добавили только в версии 740)
Хз помогает ли это сейчас
P.S. Не всегда к сожалению удается продавить отключение лишних полномочий у проектной команды (по политическим причинам)
И в мыслях не было. Я действительно не знаю что такое systemd и upstart, но не в этом дело — просто хотел намекнуть автору что пара предложений с пояснением таких узкоспециализированных вещей были бы к месту.
P.S. спасибо за комментарий, стало немного понятней о чем речь