"У меня такая же нога, но не болит". Это я к тому, что у вас работает - замечательно, но наверное не стоит свои внутренние стандарты продавливать в массы, тем более в обсуждении, которое к оптимизации запроса вообще не имело отношения.
Любопытства ради, а что конкретно, по сравнению с OfBiz "криво, косо и устарело" (может где-то можно покрутить демку, сравнить, не перелопачивая наугад всю документацию и тыкаясь в кнопки)? Вы про платформу или про конкретные решения на платформах?
Недавно проходил вебинар/мастер-класс по оптимизации запросов для 1С, где конкретная компания рассказывала о своих внутренних стандартах. В частности - про замену "Не..." на внутренние соединения, которая (возможно, но сама компания не проверяла) в определенных условиях, дают прирост, а может быть и не дают, но "так заведено" (что нормально для внутренних стандартов). После чего астрологи объявили неделю карго-культа по оптимизации и переписыванию запросов.
Про апгрейд вообще — v8.1c.ru/priobretenie-i-vnedrenie/otvety-na-tipovye-voprosy-po-litsenzirovaniyu-1s-predpriyatiya-8 Вопрос 34.
Явно про Базовые/Проф/Корп там вроде бы не написано, но возможность апгрейда есть. Расчет по стандартной формуле (доплата за переоформление, доплата разницы в стоимостях но не меньше определенного процента). С одного решения на другой вопрос не в как таковом апгрейде, а в том, что есть линейки типа УТ — КА — ERP у которых часть кодовой базы общая, а есть решения для разных отраслей, там методология учета может отличаться и это в любом случае перевнедрение.
Я вполне допускаю, что «упомянутый здесь Neikist» что-то подтвердил, увы, он не является для меня беспрекословным авторитетом.
И я не понимаю, почему вы все сводите к каким-то политическим аналогиям.
Ну да ладно. За сим прекращаю оффтопик.
Эм. Т.е. вы не являетесь представителем компании-разработчика, которая утверждает, что их технология опережает весь мир и который ссылается на свои же (своих коллег) статьи, о том, что она лучше чем 1С?
Извините, видимо что-то перепутал.
В статье упомянуты конкретные проблемы связанные с экосистемой и «Developers! Developers! Developers!». И нет практически ничего про техническую составляющую (кроме боли автора из-за необходимости работать с «устаревшими» неуправляемыми формами). Изменение подхода к взаимодействию с сообществом разработчиков и пользователей, это вполне себе фундаментальное изменение, а не перестановка кроватей.
Про технологическое отставание, попробую намекнуть еще прозрачнее — пиарьте свой продукт в своем блоге =)
В статье отражен взгляд конкретного человека на проблемы 1С-экосистемы, причем со стороны разработчика. Соответственно и предложенные решения — это мнение конкретного человека.
Озвучивать мнение разработчиков «убийцы-1С/аксапты/экселя/сапа» по вопросам технологического отставания платформы он вроде бы не обязан — оно вполне отражено в их собственных статьях.
каждый апдейт приходится выкачивать руками, заливать в своё репо… расскажите кто нибудь ребятам из 1с что нативные репозитории в линуксе умеют аутентификацию сотней разных способов а качать дистрибутив с сайта это прошлый век
Ну вы еще скажите, что не надо дистрибутивы в rar архив (или 2-3 вложеннных zip-архива) класть. На святое замахнулись =)
Потому что когда они НЕ сравнивают себя с 1С (или SQL, или еще кем-то), то их статьи игнорируют (никто не пишет комментариев, плюсы только от 20 сотрудников компании на Хабре).
Я будучи 1С-ником на эту тему копья ломал в спорах с коллегами.
Как обычно позиционируются low-code (а особенно RPA) системы — «у вас есть закрытая система, и вам нужно с ней интегрироваться». Казалось бы — 1С не является закрытой системой и стоимость ее доработки может быть ниже, чем внедрение поверх еще какой-нить Элмасофт24на7. И все равно, мечты об RPA волнуют разум.
Причины (ИМХО, конечно же):
1) Хороший маркетинг («не какой-то ваш унылый 1С, а красивые ролики и сайтики», «модно, стильно, молодежно», отличный способ указать в резюме хайповый термин)
2) Иллюзия, что «можно все сделать самим без всяких программистов».
3) Недоверие к 1С-никам, которые обслуживают систему.
4) Внезапно, партнерские компании 1С не хотят морочиться с доработками типовых, им интереснее продать лицензии, типовую коробку, обновлять ее без доработок, а сверху продать еще и RPA систему (посмотрите список партнеров у указанных в статье компаний, например).
я бы переформулировал в «не все люди хотят развиваться так, как от них ожидают другие люди». Может человек в свободное время вместо английского языка изучает вязание или на тайский бокс ходит.
Так это пример, про который я говорил в самом начале. По сути это хаки, которые использовать не нужно. В конце концов, в той же БСП есть, если мне не изменяет память, функции получения вот этих «ДокументСсылка» и всяких модулей менеджера по переданной ссылке на объект.
Но на практике, 90% кода все-таки будет не в виде «if A equals(Б) then», а обращение к методам и работа с переменными, которые все равно написаны на великом и могучем.
Но я понимаю проблему. Сам когда сталкивался с кодом на 1С на английском испытывал боль, при этом с кодом на других ЯП такой проблемы нет.
Но в первом примере суть всем понятна, а во втором только 1Сникам
Ведь синтаксис помощник тоже будет на английском. Хотя в этом я начал сомневаться. Давно это было. Но вроде есть описание процедур на английском
Да, описание дублируется для двух языков.
Так что, это решит проблему открыли в России значит на русском, открыли в другой локале значит на английском
Не знаю, суть в том, что все равно на одном из языков будет солянка из русского и английского. Я наверное все-таки не понимаю, в чем будет профит от перевода только ключевых слов. Ход программы от этого понятнее не станет.
Другой вопрос, почему методы нельзя автоматом переводить в зависимости от локали. Вроде раз есть поддержка двух языков то и перевести совсем не сложно
А смысл?
Ну т.е. строка
«Процедура МояЛучшаяПроцедура(МояПеременная) Экспорт»
станет выглядеть как
«Procedure МояЛучшаяПроцедура(МояПеременная) Export».
Это, мне кажется, не решит проблему.
вот в этом и проблема, что не только вы не понимаете
смотрите, 1С позволяет писать код на английском. Но большинство 1С-ников пишет его на русском («так исторически сложилось»). Вы пишете код на английском и можете получить проблемы с универсальными обработками, причем не из-за языка, а из-за использования разработчиками универсальных решений, допустим, БСП. Да, увы, если вы эту библиотеку не используете — будет ошибка. Но это в любом ЯП так будет.
И сам принцип интересен — типо если кто то что то не делает, то почему мы должны? Я верно уловил посыл?
не совсем, верно. Посыл скорее в том, что «если все косячат, то нужно обсуждать проблему, а не одного выбранного представителя косячащих».
Ну и на будущее — читайте с первого комментария, тогда все поймете
Ну и на будущее, я вам и на первый комментарий отвечал, если вы не заметили. Так что я внимательно прочитал все. Боль понимаю, но согласиться с критикой не могу.
Значит, я угадал.
"У меня такая же нога, но не болит". Это я к тому, что у вас работает - замечательно, но наверное не стоит свои внутренние стандарты продавливать в массы, тем более в обсуждении, которое к оптимизации запроса вообще не имело отношения.
Любопытства ради, а что конкретно, по сравнению с OfBiz "криво, косо и устарело" (может где-то можно покрутить демку, сравнить, не перелопачивая наугад всю документацию и тыкаясь в кнопки)? Вы про платформу или про конкретные решения на платформах?
Недавно проходил вебинар/мастер-класс по оптимизации запросов для 1С, где конкретная компания рассказывала о своих внутренних стандартах. В частности - про замену "Не..." на внутренние соединения, которая (возможно, но сама компания не проверяла) в определенных условиях, дают прирост, а может быть и не дают, но "так заведено" (что нормально для внутренних стандартов). После чего астрологи объявили неделю карго-культа по оптимизации и переписыванию запросов.
Все верно, только 1С это не "любой CRM на Java". Во-первых потому, что не совсем CRM, во-вторых, потому что не на Java.
Явно про Базовые/Проф/Корп там вроде бы не написано, но возможность апгрейда есть. Расчет по стандартной формуле (доплата за переоформление, доплата разницы в стоимостях но не меньше определенного процента). С одного решения на другой вопрос не в как таковом апгрейде, а в том, что есть линейки типа УТ — КА — ERP у которых часть кодовой базы общая, а есть решения для разных отраслей, там методология учета может отличаться и это в любом случае перевнедрение.
И я не понимаю, почему вы все сводите к каким-то политическим аналогиям.
Ну да ладно. За сим прекращаю оффтопик.
Извините, видимо что-то перепутал.
Про технологическое отставание, попробую намекнуть еще прозрачнее — пиарьте свой продукт в своем блоге =)
Озвучивать мнение разработчиков «убийцы-1С/аксапты/экселя/сапа» по вопросам технологического отставания платформы он вроде бы не обязан — оно вполне отражено в их собственных статьях.
Ну вы еще скажите, что не надо дистрибутивы в rar архив (или 2-3 вложеннных zip-архива) класть. На святое замахнулись =)
Как обычно позиционируются low-code (а особенно RPA) системы — «у вас есть закрытая система, и вам нужно с ней интегрироваться». Казалось бы — 1С не является закрытой системой и стоимость ее доработки может быть ниже, чем внедрение поверх еще какой-нить Элмасофт24на7. И все равно, мечты об RPA волнуют разум.
Причины (ИМХО, конечно же):
1) Хороший маркетинг («не какой-то ваш унылый 1С, а красивые ролики и сайтики», «модно, стильно, молодежно», отличный способ указать в резюме хайповый термин)
2) Иллюзия, что «можно все сделать самим без всяких программистов».
3) Недоверие к 1С-никам, которые обслуживают систему.
4) Внезапно, партнерские компании 1С не хотят морочиться с доработками типовых, им интереснее продать лицензии, типовую коробку, обновлять ее без доработок, а сверху продать еще и RPA систему (посмотрите список партнеров у указанных в статье компаний, например).
я бы переформулировал в «не все люди хотят развиваться так, как от них ожидают другие люди». Может человек в свободное время вместо английского языка изучает вязание или на тайский бокс ходит.
Но я понимаю проблему. Сам когда сталкивался с кодом на 1С на английском испытывал боль, при этом с кодом на других ЯП такой проблемы нет.
Мягко говоря, спорное утверждение =)
Да, описание дублируется для двух языков.
Не знаю, суть в том, что все равно на одном из языков будет солянка из русского и английского. Я наверное все-таки не понимаю, в чем будет профит от перевода только ключевых слов. Ход программы от этого понятнее не станет.
А смысл?
Ну т.е. строка
«Процедура МояЛучшаяПроцедура(МояПеременная) Экспорт»
станет выглядеть как
«Procedure МояЛучшаяПроцедура(МояПеременная) Export».
Это, мне кажется, не решит проблему.
смотрите, 1С позволяет писать код на английском. Но большинство 1С-ников пишет его на русском («так исторически сложилось»). Вы пишете код на английском и можете получить проблемы с универсальными обработками, причем не из-за языка, а из-за использования разработчиками универсальных решений, допустим, БСП. Да, увы, если вы эту библиотеку не используете — будет ошибка. Но это в любом ЯП так будет.
не совсем, верно. Посыл скорее в том, что «если все косячат, то нужно обсуждать проблему, а не одного выбранного представителя косячащих».
Ну и на будущее, я вам и на первый комментарий отвечал, если вы не заметили. Так что я внимательно прочитал все. Боль понимаю, но согласиться с критикой не могу.