В защиту автора могу сказать, что, к сожалению, на текущем месте работы мне подобных мероприятий сильно не хватает, и при выборе "получить в этом году прибавку" или "с этого года у нас будут вменяемые и работающие процессы разработки/онбординга/обмена опытом", я выбрал бы второе.
Как раз отличный пример. Потому что зафиксированное время - просто один из объективных фактов. А вот интерпретация этого факта (да еще и с выборочным учетом или не учетом контекста и других объективных фактов...) про "... - мудак, а остальные приходят..". Может Иванов ушел домой на час позже, а Сидоров и Петров после обеда в карты резались. Может он накануне за Ивановым и Петровым говнокод разгребал всю ночь, а под утро вырубился и проспал. И так далее. И это я еще не пытаюсь даже влезть в вопросы "а что происходит в другие дни?" и "а может быть у него вне работы что-то случилось?" (не говоря уж про бытовуху типа пробок).
"1C-программисты" это такой зонтик, под которым находятся совершенно разные люди:
Разработчики типовых и отраслевых коробочных решений внутри самой 1С + в фирмах партнерах (как правило, это именно разработчики, но с хорошим знанием предметки)
Собственно, упомянутые ниже внедренцы/консультанты/сопровождение (тут может быть в разных пропорциях намешан бизнес-анализ, разработка, кастомизация и просто установка обновлений)
Штатные сотрудники компаний, в которых используются системы на 1С (тут вообще под словом "1с-программист" могут понимать что угодно, как поддержку чужих решений, так и разработчики какого-то внутреннего проекта).
Есть люди, которые специализируются на вопросах производительности 1С-систем (с уклоном в DBA). и т.д.
Т.е. ответ "нет, не всегда это просто кастомизировал и свободен". Сейчас все чаще наблюдаю уход от "Вася на все руки мастер, и 1С настроит, и сервер, и принтер", к нормальным командам и процессам (с выделенными QA и BA, с современными процессами и технологиями).
Это не более чем вопрос привычки. Т.е. мне, допустим, комфортно читать код на английском, если это не 1С (мысленно на русский при этом не перевожу), а вот читать код 1С на английском - "ломает" (этакий своеобразный "эффект зловещей долины" только для программирования - мозг понимает, что это 1С, но какой-то неправильный =)).
Я вас вполне понимаю =) Меня это решение в MS Excel тоже всегда удивляло. У 1С, кстати, с этим проблем чуток поменьше - т.е. английский и русский можно (в случае с всякими "ФабрикаXDTO", к сожалению, иногда и нужно) смешивать, и вроде с большего работает нормально, хотя и не без косяков.
И вы только что точно описали причину, по которой большинство решений на 1С было написано на русском, при наличии англоязычных вариантов ключевых слов.
Тут скорее претензии к преподавателю, т.к. для учебных задач вполне можно было бы и на английском писать (благо есть даже статьи и видеокурс на курсере той же).
Уже полтора года прошло с вашей хвалебной статьи о LS Fusion (ну та, где "отличная система, гораздо лучше чем 1С, отличное описание в маркетинговых описаниях, надо будет на днях попробовать скачать и установить"). Может настало время все-таки скачать и посмотреть? =)
Это специфическая проблема ТСа. Он регулярно находит "гениальные" решения придуманных им проблем, игнорируя решения "общепринятые", просто раньше это не выходило за рамки 1С-форумов.
Только при этом придется еще и типовой код переписывать и в будущем все его изменения самостоятельно поддерживать. А в этом случае уже все равно - есть возможность подписаться или нет.
Платформа позволяет подписаться на: 1) запись всего объекта в БД 2) на интерактивное изменение значения в поле, которое связано со свойством объекта (в контексте формы), но ни один ни второй вариант не решат проблему @Naf2000.
В комментарии описана ситуация часто возникающая при доработке уже существующего решения, в котором часть полей объекта недоступна для изменения пользователем, а пересчитывается/заполняется на основании значений других полей.Причем реализовано авторами решения это может быть так, что этот пересчет происходит только при интерактивном тыканьи кнопок на форме, а если нужно, например, программно поменять/создать объекты (импорт из другой системы, к примеру), приходится этот код дублировать.
Собственно, наличие событий изменений свойств само по себе проблему тоже не решит - упрется в то, что нужно будет или переписывать логику типового решения, либо ждать пока это сделает сам вендор.
Ну на моем опыте ( может мне попадались такие компании ), но в первые годы бизнеза действительно 1с незаменимая вещь, но потом, когда компания сильно растет(ну если растет) платформа не может уже дать того, что нужно
Немного уточню. В первые годы бизнеса, 1С очень дешевая (как с точки зрения лицензий, так и с точки зрения зарплат 1С-ников) и доступная (в плане поиска внедренцев на типовые решения) вещь. Но как только компания сильно растет, доработка/настройка/обслуживание 1С резко вырастает в цене (ох, какая неожиданность - сложные кастомные решения на большое число пользователей - это дорого), а специалистов которые могут (и главное - хотят) решать эти вопросы не всегда удается найти. Т.е. прямо противоположная ситуация с условными ODOO - разработчик, который будет щелкать интеграции с BI, может как от огня сбежать от необходимости поддерживать в актуальном состоянии печатные формы, да и денег попросит, скорее всего, побольше.
Вы бы к примеру взялись сконвертировать уникальное приложение обратно в Delphi или любой другой язык за цену лицензии?
Лично я - вряд ли, мой опыт хождения по граблям в основном ограничивается 1С, поэтому не взялся бы.
Сама платформа никакой "монолитности" не добавляет, если решение и правда из двух табличек. Да, скорее всего будет работать медленнее, чем нативное, но серьезного оверхеда не будет.
Если абстрактный пример - то упрется все в наличие ТЗ (или наличие человека, который разбирается в 1С и может по конфигурации это ТЗ написать).
P.S. Цена лицензии - тоже понятие растяжимое. Может быть и правда дешевле все переписать, хоть на Delphi, хоть на, прости господи, Access'е, чем покупать лицензии. Но так-то на Delphi искать разработчиков в 2021 году, мне кажется, сложнее, чем на 1С.
Та БД к бухгалтериии не имела ни малейшего отношения, т.е. вся стандартная конфигурация была просто выброшена
90% решений на 1С тоже к бухгалтерии отношения не имеют, в общем-то. При этом стоимость именно готовых решений на 1С - копеечная. Вопросы скорее в стоимости пользовательских / серверных лицензий. И внедрении/адаптации.
Перенести можно было на любую платформу, человек сделал на том чем владел, ни с кем не согласовав. Позже руководство было вынуждено приобрести лицензию на платформу.
Какой-то 1С-ниндзя, который незаметно для руководства переписывает все на 1С, а руководство это замечает только когда он уволился =)
А к простой БД с исходниками приложения добавился необъятный монолит, который придётся допиливать у соответствующих специалистов. КМК получился не самый оптимальный вариант для пары табличек и пары формочек.
А монолит-то необъятный откуда появился, если исходная система была из пары табличек и пары формочек? Все-таки либо 1С-ник взял что-то готовое (допустим, была база из двух табличек по расходу материалов на производстве, а 1С-ник развернул ERP) или руководство "забыло упомянуть", как этот монолитный монстр вырос из их же "хотелок" на этапе замены Delphi на 1С. Так-то небольшую базу из пары табличек на 1С напилить и сопровождать будет скорее всего дешевле, чем на Delphi (если там и правда была пара табличек) - любой студент справится.
Там же можно скачать полную версию, с демо базой данных. Там же есть и линк на демку, работающую он-лайн
Да, на оффсайте демку я нашел, просто вот при беглом взгляде "вау"-эффекта не испытал - поэтому и поинтересовался чем-то конкретным, чтобы исключить синдром утенка.
По вашим наводкам посмотрю (модели данных, каталоги и т.д.), спасибо. Вполне возможно, что что-то полезное почерпну.
И да, Ofbiz вовсе не идеал. Глюков - куча. Но мне больше нравится
Что бы он еще где-то был, этот идеал. Везде набор компромисов и граблей.
Бывают случаи, когда используется только платформа — наблюдал БД, пересаженную с Delphi/Paradox сотрудником по собственной инициативе, просто потому что мог
Бывает, да. Я допустим так работаю ("совершенно уникальные конфигурации" в смысле, а не "перевел на 1С потому что мог"). О рисках всегда предупреждаю заранее. В чем вы видите проблему?
В защиту автора могу сказать, что, к сожалению, на текущем месте работы мне подобных мероприятий сильно не хватает, и при выборе "получить в этом году прибавку" или "с этого года у нас будут вменяемые и работающие процессы разработки/онбординга/обмена опытом", я выбрал бы второе.
Как раз отличный пример. Потому что зафиксированное время - просто один из объективных фактов. А вот интерпретация этого факта (да еще и с выборочным учетом или не учетом контекста и других объективных фактов...) про "... - мудак, а остальные приходят..". Может Иванов ушел домой на час позже, а Сидоров и Петров после обеда в карты резались. Может он накануне за Ивановым и Петровым говнокод разгребал всю ночь, а под утро вырубился и проспал. И так далее. И это я еще не пытаюсь даже влезть в вопросы "а что происходит в другие дни?" и "а может быть у него вне работы что-то случилось?" (не говоря уж про бытовуху типа пробок).
"1C-программисты" это такой зонтик, под которым находятся совершенно разные люди:
Разработчики типовых и отраслевых коробочных решений внутри самой 1С + в фирмах партнерах (как правило, это именно разработчики, но с хорошим знанием предметки)
Собственно, упомянутые ниже внедренцы/консультанты/сопровождение (тут может быть в разных пропорциях намешан бизнес-анализ, разработка, кастомизация и просто установка обновлений)
Штатные сотрудники компаний, в которых используются системы на 1С (тут вообще под словом "1с-программист" могут понимать что угодно, как поддержку чужих решений, так и разработчики какого-то внутреннего проекта).
Есть люди, которые специализируются на вопросах производительности 1С-систем (с уклоном в DBA). и т.д.
Т.е. ответ "нет, не всегда это просто кастомизировал и свободен". Сейчас все чаще наблюдаю уход от "Вася на все руки мастер, и 1С настроит, и сервер, и принтер", к нормальным командам и процессам (с выделенными QA и BA, с современными процессами и технологиями).
Это не более чем вопрос привычки. Т.е. мне, допустим, комфортно читать код на английском, если это не 1С (мысленно на русский при этом не перевожу), а вот читать код 1С на английском - "ломает" (этакий своеобразный "эффект зловещей долины" только для программирования - мозг понимает, что это 1С, но какой-то неправильный =)).
Я вас вполне понимаю =) Меня это решение в MS Excel тоже всегда удивляло.
У 1С, кстати, с этим проблем чуток поменьше - т.е. английский и русский можно (в случае с всякими "ФабрикаXDTO", к сожалению, иногда и нужно) смешивать, и вроде с большего работает нормально, хотя и не без косяков.
И вы только что точно описали причину, по которой большинство решений на 1С было написано на русском, при наличии англоязычных вариантов ключевых слов.
Тут скорее претензии к преподавателю, т.к. для учебных задач вполне можно было бы и на английском писать (благо есть даже статьи и видеокурс на курсере той же).
Для MESSAGE expression это тоже работает, верно? Вроде бы в документации это явно не отражено.
Уже полтора года прошло с вашей хвалебной статьи о LS Fusion (ну та, где "отличная система, гораздо лучше чем 1С, отличное описание в маркетинговых описаниях, надо будет на днях попробовать скачать и установить"). Может настало время все-таки скачать и посмотреть? =)
Это специфическая проблема ТСа. Он регулярно находит "гениальные" решения придуманных им проблем, игнорируя решения "общепринятые", просто раньше это не выходило за рамки 1С-форумов.
".... — Мудрый филин, а как же мы станем ёжиками?
И ответил филин:
— Ребята, вы меня ерундой не грузите. Я стратегией занимаюсь. "
Только при этом придется еще и типовой код переписывать и в будущем все его изменения самостоятельно поддерживать. А в этом случае уже все равно - есть возможность подписаться или нет.
Платформа позволяет подписаться на: 1) запись всего объекта в БД 2) на интерактивное изменение значения в поле, которое связано со свойством объекта (в контексте формы), но ни один ни второй вариант не решат проблему @Naf2000.
В комментарии описана ситуация часто возникающая при доработке уже существующего решения, в котором часть полей объекта недоступна для изменения пользователем, а пересчитывается/заполняется на основании значений других полей.Причем реализовано авторами решения это может быть так, что этот пересчет происходит только при интерактивном тыканьи кнопок на форме, а если нужно, например, программно поменять/создать объекты (импорт из другой системы, к примеру), приходится этот код дублировать.
Собственно, наличие событий изменений свойств само по себе проблему тоже не решит - упрется в то, что нужно будет или переписывать логику типового решения, либо ждать пока это сделает сам вендор.
Справедливости ради, например Резолюция Генеральной Ассамблеи ООН A/RES/ES-10/19 тоже выглядит как "США против всего мира".
Немного уточню. В первые годы бизнеса, 1С очень дешевая (как с точки зрения лицензий, так и с точки зрения зарплат 1С-ников) и доступная (в плане поиска внедренцев на типовые решения) вещь. Но как только компания сильно растет, доработка/настройка/обслуживание 1С резко вырастает в цене (ох, какая неожиданность - сложные кастомные решения на большое число пользователей - это дорого), а специалистов которые могут (и главное - хотят) решать эти вопросы не всегда удается найти. Т.е. прямо противоположная ситуация с условными ODOO - разработчик, который будет щелкать интеграции с BI, может как от огня сбежать от необходимости поддерживать в актуальном состоянии печатные формы, да и денег попросит, скорее всего, побольше.
Пора писать "Повесть о том, как один разработчик десять agile-коучей прокормил".
Лично я - вряд ли, мой опыт хождения по граблям в основном ограничивается 1С, поэтому не взялся бы.
Сама платформа никакой "монолитности" не добавляет, если решение и правда из двух табличек. Да, скорее всего будет работать медленнее, чем нативное, но серьезного оверхеда не будет.
Если абстрактный пример - то упрется все в наличие ТЗ (или наличие человека, который разбирается в 1С и может по конфигурации это ТЗ написать).
P.S. Цена лицензии - тоже понятие растяжимое. Может быть и правда дешевле все переписать, хоть на Delphi, хоть на, прости господи, Access'е, чем покупать лицензии. Но так-то на Delphi искать разработчиков в 2021 году, мне кажется, сложнее, чем на 1С.
90% решений на 1С тоже к бухгалтерии отношения не имеют, в общем-то. При этом стоимость именно готовых решений на 1С - копеечная. Вопросы скорее в стоимости пользовательских / серверных лицензий. И внедрении/адаптации.
Какой-то 1С-ниндзя, который незаметно для руководства переписывает все на 1С, а руководство это замечает только когда он уволился =)
А монолит-то необъятный откуда появился, если исходная система была из пары табличек и пары формочек? Все-таки либо 1С-ник взял что-то готовое (допустим, была база из двух табличек по расходу материалов на производстве, а 1С-ник развернул ERP) или руководство "забыло упомянуть", как этот монолитный монстр вырос из их же "хотелок" на этапе замены Delphi на 1С. Так-то небольшую базу из пары табличек на 1С напилить и сопровождать будет скорее всего дешевле, чем на Delphi (если там и правда была пара табличек) - любой студент справится.
Да, на оффсайте демку я нашел, просто вот при беглом взгляде "вау"-эффекта не испытал - поэтому и поинтересовался чем-то конкретным, чтобы исключить синдром утенка.
По вашим наводкам посмотрю (модели данных, каталоги и т.д.), спасибо. Вполне возможно, что что-то полезное почерпну.
Что бы он еще где-то был, этот идеал. Везде набор компромисов и граблей.
Бывает, да. Я допустим так работаю ("совершенно уникальные конфигурации" в смысле, а не "перевел на 1С потому что мог"). О рисках всегда предупреждаю заранее. В чем вы видите проблему?