Comments 799
Я надеюсь, что все больше разработчиков 1с будут смотреть на мир через парадигму «я знаю, какой язык лучше подойдет для этой задачи», не боясь изучать и применять python, js, c++, c# или java. Кроме того, хочется, чтобы и новые разработчики приходили с таким отношением, это во многом зависит от того, на сколько привлекательной будет инфраструктура разработки для молодых разработчиков, которые не боятся нового, не боятся совмещать.
Мой кейс таков: я начал «разрабатывать» год назад с 1с, а благодаря знакомству с oscript за последние полгода успел решить бизнес задачи на python и js, познакомишись с bootstrap, mvp, docker.
Мой кейс таков: я начал «разрабатывать» год назад с 1с, а благодаря знакомству с oscript за последние полгода успел решить бизнес задачи на python и js, познакомишись с bootstrap, mvp, docker.
Никто не заметил тут пропаганду oscript, ага. Еще одна поделка сбоку к 1с, не поддерживаемая вендором. И бизнес 1с автор не знает и не понимает. Бизнес в том, чтобы создать массовый спрос на работу фирм партнёров, которым выгодно массово продавать клиентам коробки и лицензии и попутно — бесконечные обновления, доработки и «работу» недоученных специалистов, сменяющих друг дружку каждый день (ибо их легион). Клиентам, кроме траты денег, это не приносит ничего хорошего, но и альтернатив не много (и неспроста). Лишь бухгалтерия и ЗУП могут считаться относительно полезными решениями, помогающими бизнесу отчитываться перед государством. Все остальные решения и их перепиленные армиями одинесников вариации — создают лишь проблемы бизнесу, которые нужно постоянно решать, постоянно оплачивая труд радующихся такому положению вещей «недоучек». Это всегда намного дороже, чем профильные облачные решения и сервисы, покупаемые в аренду.
Еще одна поделка сбоку к 1с, не поддерживаемая вендором
Какой ужас. Сообщество разработчиков делает open source инструменты для автоматизации своей работы без участия вендора. Ни для одной платформы такого нет, только в богомерзкой 1С.
Клиентам, кроме траты денег, это не приносит ничего хорошего, но и альтернатив не много (и неспроста).… Это всегда намного дороже, чем профильные облачные решения и сервисы, покупаемые в аренду.
Угу. Так и есть. Хорошо для 1С, что кроме вас этого никто не понял, поэтому бизнес продолжает покорно платить 1С за то, что та им создает проблемы. Это ведь так типично для бизнеса — не считать свои деньги, да.
Ну теперь-то вы им глаза открыли, надеюсь?
Хорошо для 1С, что кроме вас этого никто не понял, поэтому бизнес продолжает покорно платить 1С за то, что та им создает проблемы
Конечно хорошо для 1С. Монополия всегда хороша для монополиста.
Как же монополия? Вон, смотрите и ls fusion есть, и ofBiz, и SAP, и Dynamics, и на C# вон кто-то сам себе написал решение. И все лучше чем 1С.
Просто бизнес он глупый. Продолжает есть кактус за свои деньги.
Ах, да. Точно. Забыл. Законодательство в стране меняется, потому что 1С договорилась с налоговой, чтобы заработать на ИТС. Именно так.
Как там у Гоголя?
«Год 2000 апреля 43 числа. <...>Теперь передо мною все открыто. Теперь я вижу все как на ладони. А прежде, я не понимаю, прежде все было передо мною в каком-то тумане.»
Просто бизнес он глупый. Продолжает есть кактус за свои деньги.
Ах, да. Точно. Забыл. Законодательство в стране меняется, потому что 1С договорилась с налоговой, чтобы заработать на ИТС. Именно так.
Как там у Гоголя?
«Год 2000 апреля 43 числа. <...>Теперь передо мною все открыто. Теперь я вижу все как на ладони. А прежде, я не понимаю, прежде все было передо мною в каком-то тумане.»
Ах, да. Точно. Забыл. Законодательство в стране меняется, потому что 1С договорилась с налоговой, чтобы заработать на ИТС. Именно так.
Как раз проблема именно в сложном законодательстве. В частности, в области бухгалтерского учета (неоправданная сложность) и начисления заработной платы (во многом из-за того, что налоги на зарплату платит организация, а не сотрудник, но и опять же ненужная сложность). Плюс нет стандартной, для всего мира, разделения на финансовые (Bil / Invoice) и товарные (Receipt / Shipment) документы, так как ТОРГ-12 в себе совмещает оба документа сразу.
Такая вот специфика делает невозможным использование многих мировых продуктов, а относительно небольшой рынок — невыгодным адаптацию для их вендоров. За счет этого и обеспечивается монополия. Без этого была бы значительно сильнее конкуренция, и 1С не был бы монополистом. Впрочем это касается многих других отраслей в РФ.
О да, сложное законодательство только в РФ. В США, например, совсем простое. Наверное именно по этой причине многие производители ПО для бизнеса там даже ни не берутся самостоятельно посчитать, например, Sales Tax. Он всего навсего зависит от Штата, дня недели, месяца, времени суток, типа товара, наличия льгот, лиценщий, праздников и т.п.
Так вот откуда списали драконий покер:
Понимаешь, условные модификаторы зависят от определенных переменных, вроде дня недели, числа игроков, положения стульев и тому подобного. А поскольку этот матч организован загодя, мы знаем, какими будет большинство этих переменных. Например, играть будете только вы двое, а ты, как вызванный на матч, имеешь право выбрать стул… займи, между прочим, стоящий лицом к югу.
Насколько помню в мире "белых людей" прайс производителей софта ExVAT то есть в прайсе не учитываются локальные налоги. Я считаю это правильно. По какой окончательной формуле будет показана для меня цена это вопрос к торговой площадке. Если производитель желает продать мне напрямую, то заморачиваются с платежной системой. НДС, доставка до меня и прочее.
Насколько помню в мире «белых людей» прайс производителей софта ExVAT то есть в прайсе не учитываются локальные налоги. Я считаю это правильно. По какой окончательной формуле будет показана для меня цена это вопрос к торговой площадке. Если производитель желает продать мне напрямую, то заморачиваются с платежной системой. НДС, доставка до меня и прочее.
Это вынуждено.
Если вы про ЕС — банально — там НДС очень разный в разных странах. Если про США, то там налог с продаж разный в разных местах.
В РФ в этом нет необходимости — ибо всё едино.
Загадка почему в Японии налог с продаж нужно самому добавлять, там вроде нет сложных исключений.
Ах, да. Точно. Забыл. Законодательство в стране меняется, потому что 1С договорилась с налоговой, чтобы заработать на ИТС. Именно так.
Как раз проблема именно в сложном законодательстве
Е-рун-да.
Как человек со всем этим работающий утверждаю.
На предприятиях зачастую:
торговая конфигурация 1С + бухгалтерская, между ними загрузка выгрузка.
или
производственная конфигурация 1С + бухгалтерская 1С, между ними загрузка выгрузка
или
другой вариант для оперативного управленческого учета + бухгалтерская 1С, между ними загрузка-выгрузка.
И т.п.
Так вот основное, от чего зависит ежедневная работа фирмы — это именно производственная или торговая конфигурация или иная конфигурация для оперативного управленческого учета. Которые не обновляются и по несколько лет (старейшие в строю из мне лично известных — аж с 2004 года в эксплуатации). Не обновляются — имеется ввиду, свежими версиями от самой 1С, где все последние веяния законодательства учтены.
Не обновляются по причине глубоких доработок.
Не обновляются — потому что это попросту не нужно.
Не нужны в оперативном управленческом учете все изменения законодательства. Исключения имеются. Но их крайне мало.
Чувствительной к законам является только бухгалтерская 1С. Да, та обновляется часто.
За последние 20 лет можно по пальцам одной руки пересчитать что именно пришлось сколько-нибудь серьезно изменять в производственной/торговой/оперучетных, чтобы привести к требованиям законодательства.
Онлайн-кассы, учет алкоголя. Корректировочные счета-фактуры — да и то не для всех, многие делают их в бухгалтерской 1С. Изменение транспортных документов, но это не такое уж и сложное изменение. И… да пожалуй все. Мелкие изменения форм документов, типа добавить ГТД в счет-фактуру — ну такого плана изменения еще раза 10 за 20 лет были критичны, но я не считаю это за серьезную проблему. На этом всё.
В львиной доле случаев достаточно просто регулярно обновлять бухгалтерскую свежими версиями от 1С.
К чему я это?
К тому, что обладая действительно классным продуктом вы вполне можете конкурировать с 1С — просто заняв нишу торговых/производственных/пр. предназначенных для оперативного учета.
А ведь, утверждаю из опыта, именно там и основные деньги. Если вещи нужны фирме как воздух. Это ее ежедневная деятельность. Это её конкурентное преимущество и пр. и пр.
А бухгалтеркая нужна, по сути, раз в квартал/раз в месяц, когда нужно налоги считать.
И загрузку-выгрузку в бухгалтерскую вы вполне осилите реализовать, это не сложно на фоне остальных задач, что вам предстоят. Если уж способны реализовать замену производственной/торговой/оперучетной 1С — то интегрироваться с бухгалтерской 1С вам будет совсем не сложно.
Полностью с Вами согласен насчет относительной неважности бухгалтерского и фискального учета.
Но тут другая проблема. Я сейчас достаточно подробно изучаю западные решения (в большей степени Odoo) — хочется сделать открытое и бесплатное решение, которое подойдет как к западной модели, так и к постсоветской. И есть принципиальное отличие в плане документов. Я это уже упоминал выше.
У них во всех решениях всегда три документа: Order / Invoice / Shipment. У них нормально, когда Вам поставляют товар в течение месяца без каких-либо документов с ценами. Вы их приходуете по какой-то условной цене из заказа. А потом вам выставляют на них счет (причем цена может не совпасть с ценой в заказе). В постсовке же вы не можете без финансового документа (например, ТОРГ-12 или ТТН, в котором есть цены) оприходовать товар.
И, например, вот это обстоятельство достаточно сильно влияет на логику процессов приемки и отгрузки. По этой причине тот же Odoo из коробки под РФ ну никак не подходит. Если конечно, не делать двойной ввод в 1С и иметь разную себестоимость в Odoo и 1C.
Но тут другая проблема. Я сейчас достаточно подробно изучаю западные решения (в большей степени Odoo) — хочется сделать открытое и бесплатное решение, которое подойдет как к западной модели, так и к постсоветской. И есть принципиальное отличие в плане документов. Я это уже упоминал выше.
У них во всех решениях всегда три документа: Order / Invoice / Shipment. У них нормально, когда Вам поставляют товар в течение месяца без каких-либо документов с ценами. Вы их приходуете по какой-то условной цене из заказа. А потом вам выставляют на них счет (причем цена может не совпасть с ценой в заказе). В постсовке же вы не можете без финансового документа (например, ТОРГ-12 или ТТН, в котором есть цены) оприходовать товар.
И, например, вот это обстоятельство достаточно сильно влияет на логику процессов приемки и отгрузки. По этой причине тот же Odoo из коробки под РФ ну никак не подходит. Если конечно, не делать двойной ввод в 1С и иметь разную себестоимость в Odoo и 1C.
И, например, вот это обстоятельство достаточно сильно влияет на логику процессов приемки и отгрузки. По этой причине тот же Odoo из коробки под РФ ну никак не подходит. Если конечно, не делать двойной ввод в 1С и иметь разную себестоимость в Odoo и 1C.
Вы путаете отгрузку, где себестоимость не нужна и аналитику, где уже важна себестоимость.
Их можно считать сразу, а можно и не сразу — зависит от бизнес-требований.
Мне известны вполне себе крупные бизнесы, которые свою себестоимость видят раз в месяц в лучшем случае.
Эта вещь не всегда связанная с отгрузкой.
Но есть бизнесы (низкоприбыльные), где себестоимость важна для каждой отгрузки. Иначе можно впухнуть.
Прежде чем браться за такой проект вам следут поработать полноценным разработчиком для той же 1С (нормальным, а не обновляльщиком типовых конфигураций) хотя бы года 3 (лучше 5-7), причем в разных придприятиях с разным учетом (или у франча, что разные предприятия обслуживает), чтобы начать понимать такие вещи.
Которые специалисту очевидны.
Вы не поняли меня. Чтобы было понятнее, ответьте мне на простой вопрос:
Могу ли я в РФ ЗАКОННО отгрузить покупателю товар без каких-либо документов, в которых указаны цены, а он в свою очередь принять его (в том числе и по бухгалтерскому учету)? Документы на оплату с ценами при этом ему выставить через месяц.
А в англосаксонских и европейских моделях учета — это в порядке вещей.
Могу ли я в РФ ЗАКОННО отгрузить покупателю товар без каких-либо документов, в которых указаны цены, а он в свою очередь принять его (в том числе и по бухгалтерскому учету)? Документы на оплату с ценами при этом ему выставить через месяц.
А в англосаксонских и европейских моделях учета — это в порядке вещей.
Могу ли я в РФ ЗАКОННО отгрузить покупателю товар без каких-либо документов, в которых указаны цены, а он в свою очередь принять его (в том числе и по бухгалтерскому учету)? Документы на оплату с ценами при этом ему выставить через месяц.
Это вообще не проблема софта и программиста.
Это проблема юриста и бухгалтера.
Знаю многих что так делают. С 1С.
Как это соответствует закону — не знаю.
Спросите лучше на форуме бухгалтеров.
По крайней мере под такой способ отгрузки никак доработать 1С не просят — значит, устраивает штатный механизм.
Так мне не надо спрашивать у бухгалтеров. У меня очень большой опыт в этой области. И ответ простой: незаконно. И понятно почему — кризис доверия между бизнесом и государством.
А в других странах — это стандартная схема. И поэтому там во многих местах другие процессы, под которые и заточены у них многие программы. По этой причине большинство из них не подходит для РФ из коробки и требует, как минимум, адаптации.
А в других странах — это стандартная схема. И поэтому там во многих местах другие процессы, под которые и заточены у них многие программы. По этой причине большинство из них не подходит для РФ из коробки и требует, как минимум, адаптации.
Так мне не надо спрашивать у бухгалтеров. У меня очень большой опыт в этой области. И ответ простой: незаконно. И понятно почему — кризис доверия между бизнесом и государством.
Ваш большой опыт не знает что такое договор ответственного хранения и агентский договор?
А в других странах — это стандартная схема. И поэтому там во многих местах другие процессы, под которые и заточены у них многие программы. По этой причине большинство из них не подходит для РФ из коробки и требует, как минимум, адаптации.
Разумеется, не подходит, если брать как полное комплексное решение всех задач.
Но упомянутая вами схема с осуществлением сначала отгрузки, а уже потом отложенной реализации — вполне себе реализуема.
Проблема скорее будет в печатных формах документов, если их изменение не предусмотрено в «импортном» решении.
Но не в самой сути учета.
уже потом отложенной реализации — вполне себе реализуема
Как она может быть реализуема, если незаконна?
Как Вы сделаете печатную форму документа в Odoo для Delivery Order, если там в документе цен нет вообще? Что Вы там напечатаете?
Ваш большой опыт не знает что такое договор ответственного хранения и агентский договор?
Какое отношение договор ответственного хранения и агентский договор имеет к обычной продаже компанией А компании В? Давайте только, без костылей.
уже потом отложенной реализации — вполне себе реализуема
Как она может быть реализуема, если незаконна?
Как Вы сделаете печатную форму документа в Odoo для Delivery Order, если там в документе цен нет вообще? Что Вы там напечатаете?
Потому что законна. Выше я написал какие бывают подходящие виды договоров для этого.
Да и не только. Вы забываете, что отгрузка товара != переход прав собственности.
Обычно это так, да. Это и ввело вас в заблуждение.
То есть Вы предлагаете при внедрении Odoo со всеми покупателями заключать договора комиссий / ответственных хранений? Даже если им просто пачку бумаги продаете?
а потом вы за эту пачку выставляете цену равную в пропорции НДС уплаченному за квартал и требуете с государства возмещения ибо доверие между бизнесом и государством? Имхается мне за такие схемы в любом государстве будут ожидать проблемы.
Вопросы определения НДС и прибыли. Прибыль считается как разница выручки и затрат. Затраты >= себестоимость. Если себестоимость is null то Прибыль is null тоже, а это не тот ответ, который устроит ФНС в конце налогового периода. Схема с определением себестоимости и НДС входящего в конце налогового периода мысль конечно заманчивая, но см. п.1
Вопросы определения НДС и прибыли. Прибыль считается как разница выручки и затрат. Затраты >= себестоимость. Если себестоимость is null то Прибыль is null тоже, а это не тот ответ, который устроит ФНС в конце налогового периода. Схема с определением себестоимости и НДС входящего в конце налогового периода мысль конечно заманчивая, но см. п.1
Посмотрите вот эти ссылки:
https://www.odoo.com/documentation/user/13.0/inventory/management/reporting/valuation_methods_anglo_saxon.html
https://www.odoo.com/documentation/user/13.0/inventory/management/reporting/valuation_methods_continental.html
Там внизу примеры, когда цены в заказе (PO) отличаются от цен в накладной/счете(Invoice). И посмотрите, как у них вообще проводки разносятся по счетам, и какие там счета есть.
Например, как Вам такой классный счет, как:
23000 Goods Received Not Purchased
Какой его аналог в РФ (это именно не неоплаченные, а некупленные товары)?
https://www.odoo.com/documentation/user/13.0/inventory/management/reporting/valuation_methods_anglo_saxon.html
https://www.odoo.com/documentation/user/13.0/inventory/management/reporting/valuation_methods_continental.html
Там внизу примеры, когда цены в заказе (PO) отличаются от цен в накладной/счете(Invoice). И посмотрите, как у них вообще проводки разносятся по счетам, и какие там счета есть.
Например, как Вам такой классный счет, как:
23000 Goods Received Not Purchased
Какой его аналог в РФ (это именно не неоплаченные, а некупленные товары)?
некупленные, т.е. взятые на хранение? чем ответственное хранение не подходит, сейчас попробуй еще найти дурака который не через ответственное хранение работает, вплоть до самой покупки в рознице. Правда ЭДО с онлайн фискальниками скорее всего положит конец этой налогоуменьшающей практике или даст начало использованию ИИ в прогнозировании остатка собственного товара и продаж в ближней перспективе
Отгружайте на ответственное хранение по любым ценам с правом продажи. Отгружайте на комиссию, опять же указав цены по которым товар уйдет конечному потребителю, отражайте на забалансе суммы прихода плюс минус по рыночным ценам кого бы они там сильно волновали, как мне кажется проблема надумана.
Отгрузить можете.
Принять к складскому учету без цен можно, к бухгалтерскому — нельзя.
Принять к складскому учету без цен можно, к бухгалтерскому — нельзя.
Пропаганда, какое прекрасное слово!
Я, кстати, еще бы понял, если бы Вы заманивали в свои сети консультантов или продавцов, т.к. программистам 1с не нужен, как и самой 1с и партнерам. Уже лет пять все в 1с свято уверены в том, что программы 1с не надо дорабатывать, достаточно устанавливать и консультировать по типовым возможностям. Это — долгосрочная стратегия вендора. Все делается ради удешевления стоимости работы специалиста и понижения порога вхождения нового "мяса". И это еще не многие знают, что продавцы и менеджеры фирм-партнеров 1с получают зарплаты и премии в разы больше программистов (такова многолетняя практика распределения прибыли). Зачем зазывать в этот бизнес программистов, которые априори хотят решать полезные и сложные задачи?
А теперь просто посмотрите на ситуацию глазами студента, которому нужно купить квартиру, т.к. после вечеринки студентка от него залетела и жениться — придется:
25 килорублей «стажер» на частичной занятости, пока диплом не получил. 60-80 килорублей — «помошник программиста 1С» на первый год после института. 150-200 килорублей с примерно третьего года после института до пенсии. Стабильно. Независимо от кризисов. Не надо каждый год осваивать новый фреймворк. Не надо шесть раз в год разбираться как в новомодной парадигме правильно делать 3-д эффекты при открытии формы ввода… Никаких нервотрепок, никаких авралов, при желании — все свободное время можно посвятить подработкам, которые дают хорошую «прибавку к пенсии», т.к. очень много мелких фирм, которые не могут себе позволить платить ежегодную мзду интегратору, но которым пару раз в год что-то надо в 1С подправить…
Я бы сам уже лет десять бы как подался бы в 1С, но лично у меня любое соприкосновение с финансами и бухгалтерией вызывает уверенность, что они должны быть запрещены как особо извращенные виды пыток. Но я был знаком с несколькими людьми, у которых подобная работа вызывает радость, экстаз и чувство глубокого удовлетворения.
25 килорублей «стажер» на частичной занятости, пока диплом не получил. 60-80 килорублей — «помошник программиста 1С» на первый год после института. 150-200 килорублей с примерно третьего года после института до пенсии. Стабильно. Независимо от кризисов. Не надо каждый год осваивать новый фреймворк. Не надо шесть раз в год разбираться как в новомодной парадигме правильно делать 3-д эффекты при открытии формы ввода… Никаких нервотрепок, никаких авралов, при желании — все свободное время можно посвятить подработкам, которые дают хорошую «прибавку к пенсии», т.к. очень много мелких фирм, которые не могут себе позволить платить ежегодную мзду интегратору, но которым пару раз в год что-то надо в 1С подправить…
Я бы сам уже лет десять бы как подался бы в 1С, но лично у меня любое соприкосновение с финансами и бухгалтерией вызывает уверенность, что они должны быть запрещены как особо извращенные виды пыток. Но я был знаком с несколькими людьми, у которых подобная работа вызывает радость, экстаз и чувство глубокого удовлетворения.
Никаких нервотрепок, никаких авралов
Очень смешно))
т.к. очень много мелких фирм, которые не могут себе позволить платить ежегодную мзду интегратору, но которым пару раз в год что-то надо в 1С подправить…
Ну с такими обычно и проблем больше. Вам же они тоже не захотят платить
но лично у меня любое соприкосновение с финансами и бухгалтерией вызывает уверенность, что они должны быть запрещены как особо извращенные виды пыток
А еще там есть жесткие дедлайны. Зайдите как-нибудь в бухгалтерию в последний день сдачи отчетности по НДС
Зайдите как-нибудь в бухгалтерию в последний день сдачи отчетности по НДС
Гы! Я однажды пытался жениться на девушке-бухгалтере. И свидания в очереди на Главпочтамте, т.к. ей надо успеть отправить конверты с отчетами в налоговую до полуночи, а другие отделения, естественно, давно закрыты, были далеко не самой большой экзотикой.
И да, еще важный момент, не надо путать бухгалтерию и программиста 1С. Программист 1С никак в подготовке отчетов не участвует и никакой ответственности за то, что бухгалтера опоздали или накосячили — не несет. Если вдруг программист накосячил так, что к отчетному периоду от него что-то кому-то нужно… Ну это нужно тщательно постараться. И уметь. И иметь опыт.
Очень смешно))
Ага. То, что у 1С-ника считается авралом, у ГИПа и ПМа на строительстве, например, ЦОДа называется «как здорово, что отпуск, и тебя никто не дергает!»
Я когда гиповал, «в отпуске» обычным делом было штук пять звонков в день с необходимостью принять решение, ошибка в каждом из которых (все ещё) может вылиться в пару лет отсидки…
угумс, и начинаются авралы по НДФЛ, мы ж про «стандартный ЗУПе»?
Авралы по НДСу возникают вне зависимости от используемого ПО, хоть Бух хоть эксель, хотя конечно же, стандартный бух сам вбивает первичку, сам проверяет наличие документов, обзванивает поставщиков, подрядчиков и т.д. Авралы возникают по тысяче причин, среди которых далеко не последнее это резкое переобувание руководства при получении реальных цифр за период отчетности и желание с ними что то да сделать. И ПО тут пятым в очереди.
Авралы по НДСу возникают вне зависимости от используемого ПО, хоть Бух хоть эксель, хотя конечно же, стандартный бух сам вбивает первичку, сам проверяет наличие документов, обзванивает поставщиков, подрядчиков и т.д. Авралы возникают по тысяче причин, среди которых далеко не последнее это резкое переобувание руководства при получении реальных цифр за период отчетности и желание с ними что то да сделать. И ПО тут пятым в очереди.
Я бы сам уже лет десять бы как подался бы в 1С, но лично у меня любое соприкосновение с финансами и бухгалтерией вызывает уверенность, что они должны быть запрещены как особо извращенные виды пыток
Т.к. у меня бухгалтерия экстаз не вызывает, то в части именно бухучета клиенты были переведены на типовые бухгалтерии с получением обновлений от вендора.
А вот сопутствующие задачки (с финансами связанные косвенно) типа WMS | логистики | интеграций с удовольствием решаю. Так что там не все так плохо.
Иногда возникает вопрос: «а чего бы все это не делать на java», но один из ответов — внезапно, некоторые собственники не хотят решений не на 1С. Не потому что «1С это супер, ничего лучше нет», а потому что они на подсознательном уровне не хотят плодить зоопарк систем, т.к. чувствуют, что поддержку если что, им будет искать сложнее/дороже.
Плюс у некоторых есть негативный опыт с проваленными внедрениями и при этом позитивный при работе/внедрении 1С (это примерно как у некоторых комментаторов в этой статье, но с противоположным знаком).
Попервости тоже 1С-ом зарабатывал. Потом на С перешел и сейчас Java-Kotlin. На яве стрессов и дедлайнов хватате, но от работы во франче 1С у меня самые жуткие воспоминания остались в плане нервотрепок. Весь негатив (зачастую вполне заслуженный) по поводу 1С и фирмы которую ты представляешь — на тебя изливается. А народ, который пользуется услугами франча весьма… специфичный… за копейку удавятся и тебе весь мозг съедят, а от этих копеек твой доход напрямую зависит.
Когда ушел оттуда — мне обычная разработка показалась просто заповедником спокойствия и околонулевого стресса. Я уж лучше буду фреймворки каждый год изучать, тем более что мне это интереснее чем изучать очередные нововведения в бухучете.
Да и не нужно это так часто делать, тот-же спринг, например, один из основных используемых фреймворков на Яве, он вполне эволюционно развивается, новые важные изменения в нем не так часто происходят, что-бы их изучение как-то напрягало. А большинство хайповых тем вообще в IT, и изучать нет особого смысла — бабочки однодневки.
Когда ушел оттуда — мне обычная разработка показалась просто заповедником спокойствия и околонулевого стресса. Я уж лучше буду фреймворки каждый год изучать, тем более что мне это интереснее чем изучать очередные нововведения в бухучете.
Да и не нужно это так часто делать, тот-же спринг, например, один из основных используемых фреймворков на Яве, он вполне эволюционно развивается, новые важные изменения в нем не так часто происходят, что-бы их изучение как-то напрягало. А большинство хайповых тем вообще в IT, и изучать нет особого смысла — бабочки однодневки.
Ну опять же, «Работа с 1С != Работа во франче» и «Работа с 1С != Работа с бухгалтерией». Так-то да, франч это бизнес по продаже коробок + потогонка с простыми задачами за мелкий прайс, в большинстве своем. Но в какой-нибудь условной веб-студии будет плюс минус тоже самое.
Стоит только перейти к разработке условно-коробочного решения или проектным работам и появляется спокойствие, время на изучение и использование современных технологий (в т.ч. и не 1С) и т.д.
Стоит только перейти к разработке условно-коробочного решения или проектным работам и появляется спокойствие, время на изучение и использование современных технологий (в т.ч. и не 1С) и т.д.
Я в сфере 1с проработал более 15 лет, и за это время деградация кадров шла по экспоненте. И завтра этот ваш студент будет конкурировать за поддержку 1с с бывшими дворниками, продавцами и другими специалистами широкого профиля. Поэтому да, ипотеку придется платить 25 лет.
Самое интересное, что автор этого поста и автор oscript — это одно и тоже лицо :)
Андрей, спасибо тебе за твою работу! Реально в одиночку сделал просто мега инструмент. Используем oscript для сборки и тестирования своего решения.
Теперь что касается: «бизнес 1с автор не знает и не понимает». Наоборот! Все достаточно точно и по делу. Бизнес сам решает платить вендору или партнёрам или нет. Верно? Если бизнес платит, значит его все устраивает и у него нет других альтернатив. Да, все далеко не идеально, но есть вещи, которые очень удобны. Помню, как в 2007 знакомился с 1С и был впечатлён в 1С 7.7 табличным документом и посекционным выводом в отчетах (до этого имел счастье работать с Fast Report в Delphi), а тут все было настолько просто и функционально, что я был просто шокирован.
Андрей, спасибо тебе за твою работу! Реально в одиночку сделал просто мега инструмент. Используем oscript для сборки и тестирования своего решения.
Теперь что касается: «бизнес 1с автор не знает и не понимает». Наоборот! Все достаточно точно и по делу. Бизнес сам решает платить вендору или партнёрам или нет. Верно? Если бизнес платит, значит его все устраивает и у него нет других альтернатив. Да, все далеко не идеально, но есть вещи, которые очень удобны. Помню, как в 2007 знакомился с 1С и был впечатлён в 1С 7.7 табличным документом и посекционным выводом в отчетах (до этого имел счастье работать с Fast Report в Delphi), а тут все было настолько просто и функционально, что я был просто шокирован.
Легионы недоучек, проблемы бизнесу решениями от 1С…
Суть в том, что за такие деньги других вменяемых альтернатив нет. И бизнес выбирает 1С за то, что есть уже готовые решения их проблем, которые можно довольно-таки легко подпилить. И есть масса специалистов, пусть даже недоучек и, кого вы там назвали…
Возьмите Java, вы даже недоучку с трудом найдёте, а готового решения для бизнеса российского вообще нет.
На самом деле все понимают, что 1С то подвинуть не сложно: сделайте аналогичные решения позволяющие автоматизировать учёт и отчётность. Да хотя бы отчётность автоматизируйте, а учёт, как показывает практика, всё равно, кто во что гаразд делает у себя. Однако, воз и поныне там. Ни кто напрягаться не хочет. Потому что это затратно на первоначальном этапе. Чтобы написать и выкатить в массы такой продукт и приучить бизнес к нему, нужно десятилетие. Мало кто может себе позволить 10 лет работать в убыток, чтобы потом получать какие-то крохи в конкуренции с «монополистом».
Монополии то нет у 1С. Ну, может быть тот факт что наше законодательство налоговое сильно извращено и постоянно меняется, и за это кто-то приплачивает — это может такое быть в нашей стране. Но в остально, ни кто не припятствует выйти на рынок и сразиться с 1С. Но желающих не возникает. Бизнес устраивает то, что есть.
Отдельно от лица недоучек вам отвечу. В станах python, java и проичих хватает также недоучек, которых берут, за неимением лучшего, или же по знакомству, и в довольно-таки крупных компаниях, даже государственного сектора процветает такой говнокод, за такие деньги высокие, что 1С'ники отдыхают, даже самые занюханные франчи. А, кстати, и про аутсорсеров от java тоже наслышан. Там тоже процветает схема, продавать за дорого стажоров, под видом крутых специалистов. А специалистов, только на презентациях показывают заказчикам, чтобы пыль в глаза бросить.
Автор весьма качественно, хорошо описал общий взгляд на ситуацию. Хоть и сам мне этот человек не вызывает тёплых чувств, но следует отдать должное — статья хороша. И рекламы оскрипта я не увидел. Хоть, и знаю о скрипт. Более того, пока не дочитал до конца и не увидел автора, даже не догадался, что это за личность в мире 1С. А я слежу за ними. Не нужно свою желчь выплёскивать везде. Аргументируйте свою критику более детально, в характере написанной статьи.
Суть в том, что за такие деньги других вменяемых альтернатив нет. И бизнес выбирает 1С за то, что есть уже готовые решения их проблем, которые можно довольно-таки легко подпилить. И есть масса специалистов, пусть даже недоучек и, кого вы там назвали…
Возьмите Java, вы даже недоучку с трудом найдёте, а готового решения для бизнеса российского вообще нет.
На самом деле все понимают, что 1С то подвинуть не сложно: сделайте аналогичные решения позволяющие автоматизировать учёт и отчётность. Да хотя бы отчётность автоматизируйте, а учёт, как показывает практика, всё равно, кто во что гаразд делает у себя. Однако, воз и поныне там. Ни кто напрягаться не хочет. Потому что это затратно на первоначальном этапе. Чтобы написать и выкатить в массы такой продукт и приучить бизнес к нему, нужно десятилетие. Мало кто может себе позволить 10 лет работать в убыток, чтобы потом получать какие-то крохи в конкуренции с «монополистом».
Монополии то нет у 1С. Ну, может быть тот факт что наше законодательство налоговое сильно извращено и постоянно меняется, и за это кто-то приплачивает — это может такое быть в нашей стране. Но в остально, ни кто не припятствует выйти на рынок и сразиться с 1С. Но желающих не возникает. Бизнес устраивает то, что есть.
Отдельно от лица недоучек вам отвечу. В станах python, java и проичих хватает также недоучек, которых берут, за неимением лучшего, или же по знакомству, и в довольно-таки крупных компаниях, даже государственного сектора процветает такой говнокод, за такие деньги высокие, что 1С'ники отдыхают, даже самые занюханные франчи. А, кстати, и про аутсорсеров от java тоже наслышан. Там тоже процветает схема, продавать за дорого стажоров, под видом крутых специалистов. А специалистов, только на презентациях показывают заказчикам, чтобы пыль в глаза бросить.
Автор весьма качественно, хорошо описал общий взгляд на ситуацию. Хоть и сам мне этот человек не вызывает тёплых чувств, но следует отдать должное — статья хороша. И рекламы оскрипта я не увидел. Хоть, и знаю о скрипт. Более того, пока не дочитал до конца и не увидел автора, даже не догадался, что это за личность в мире 1С. А я слежу за ними. Не нужно свою желчь выплёскивать везде. Аргументируйте свою критику более детально, в характере написанной статьи.
И бизнес 1с автор не знает и не понимает. Бизнес в том, чтобы создать массовый спрос на работу фирм партнёров
А может господин комментатор не знает и не понимает бизнес 1с? В 90-е и 00-е вендору было экономически выгодно развивать партнерскую сеть в целях экспансии. Но уже в конце 00-х началась политика покупки крупных партнеров.
В настоящий момент партнеры плачут, что вендер сначала дал бизнес, а теперь отнимает его у них — как можно теперь продавать коробки, если сейчас засилие аренды во фреше, как можно продавать сервис ИТС, если его стал предоставлять Инфостарт (1с имет долю владения), который кроме стандартного пакета дает плюшки в виде доступа к своей гигантской базе наработок???
А думаете франчам интересно быть просто «кузнецей кадров» для рынка и превращать за свой счет вчерашних студентов в завтрашних штатных сотрудников для своих же клиентов? Думаете выгодно вместо использования налаженного конвейера продаж вкалывать за каждую копейку?
Да нет там лярдов, коллега. Узкая геморойноемкая специфика, на очень ограниченные, очень скупые и стагнирующие рынки, клиенты которых (их и так не сотни) после каждого скачка бакса сыпятся как осенние листья. Какой смысл вкладываться в долгую в падающий рынок с туманными перспективами масштабирования, жесточайшей зависимостью от вендора и вероятностью подсесть на реализации всех тех хотелок нашего правительства? Когда как мировой рынок все еще не окучен?
Интересно. Какое может быть типичное использование у oscript?
Вообще, его довольно успешно «продали» 1С-никам как замену powershell — т.е. вроде и решаешь задачи вне 1С, а вроде как и на привычном языке пишешь.
В итоге на нем реализовали ряд решений из мира «взрослого DevOps и CI/CD», только с местным, так сказать, колоритом. Фактически — снизили порог входа для 1С-ников в мир современных технологий.
В итоге на нем реализовали ряд решений из мира «взрослого DevOps и CI/CD», только с местным, так сказать, колоритом. Фактически — снизили порог входа для 1С-ников в мир современных технологий.
Редкая статья про 1с от 1сника с которой я согласен за исключением некоторых спорных пунктов но которые обсасывали во всех спорах по 10 раз и повторяться бессмысленно. Упомяну разве что пару мелочей
К сожалению даже в компаниях где 1сников десятки — это скорее исключение чем правило. Также к этому пункту могу отнести что как работодатели так и другие 1сники ооочень редко желают развиваться как программист в целом, а не как программист на фреймворке. Также коммьюнити в основном очень сильно оторвано от коммьюнити других программистов, что мешает перенимать полезные практики.
Как человек делавший (по крайней мере на то время 17-18 год) самый крупный проект на мобильной 1с для предприятия (магнит тогда 3к лицензий на мобильную платформу купил) — в этом пункте вы ну ооооочень лукавите. Во первых разработка рест апи и механизма синхронизации при больших объемах справочников, необходимости работы оффлайн и невозможности удобно собирать логи — та еще боль, а для среднестатистического 1сника и вовсе задача с которой он ни разу не сталкивался. Во вторых — все равно пришлось начинать вникать в нативную разработку чтобы реализовать рядом пару других приложений мобильных для общения с мобильной 1с чтобы удовлетворить требования. В третьих из за ограничений платформы мы вообще едва не попали на необходимость писать все на нативе с нуля поскольку 1с не проходила аудит безопасников магнита. Им нужна была довольно тесная интеграция приложения с мдм системой, шифрование базы и прочее, а все это возможно только через подключение SDK вендора к приложению. И внешней компонентой это не решалось ибо требовало именно что встроить очень крепко, прямо в платформенный код. Да, сейчас, когда я уже год только и занимаюсь нативной разработкой под андроид я бы это осилил, но боюсь это бы противоречило лицензионному соглашению с 1с, сделало бы практически невозможной обновление (ибо не факт что патч бинарника одной платформы подошел бы к другой) и заняло бы дофига времени. В итоге аудит мы прошли, но чисто административными методами, а бодания заняли примерно год.
На сегодняшний день, хранение исходников 1С в git с привязкой коммитов к задачам в Jira, ревью в Crucible, накатка кнопкой из Дженкинса и отчеты Allure о тестировании кода в 1С и даже статический анализ в SonarQube — это уже далеко не новость, а, скорее, мейнстрим в компаниях где есть много разработки на 1С.
К сожалению даже в компаниях где 1сников десятки — это скорее исключение чем правило. Также к этому пункту могу отнести что как работодатели так и другие 1сники ооочень редко желают развиваться как программист в целом, а не как программист на фреймворке. Также коммьюнити в основном очень сильно оторвано от коммьюнити других программистов, что мешает перенимать полезные практики.
Мобильное приложение. С недавних пор вы можете писать и мобильные приложения, находясь в той же самой экосистеме. Тут чуть сложнее, чем с веб-клиентом, специфика устройств заставляет писать специально под них, но, тем не менее — вы не нанимаете отдельную команду мобильных разработчиков. Если нужно приложение для внутренних нужд компании (когда мобильное решение корпоративной задачи важнее желтого дизайна UI) — просто пользуетесь той же платформой из коробки.
Как человек делавший (по крайней мере на то время 17-18 год) самый крупный проект на мобильной 1с для предприятия (магнит тогда 3к лицензий на мобильную платформу купил) — в этом пункте вы ну ооооочень лукавите. Во первых разработка рест апи и механизма синхронизации при больших объемах справочников, необходимости работы оффлайн и невозможности удобно собирать логи — та еще боль, а для среднестатистического 1сника и вовсе задача с которой он ни разу не сталкивался. Во вторых — все равно пришлось начинать вникать в нативную разработку чтобы реализовать рядом пару других приложений мобильных для общения с мобильной 1с чтобы удовлетворить требования. В третьих из за ограничений платформы мы вообще едва не попали на необходимость писать все на нативе с нуля поскольку 1с не проходила аудит безопасников магнита. Им нужна была довольно тесная интеграция приложения с мдм системой, шифрование базы и прочее, а все это возможно только через подключение SDK вендора к приложению. И внешней компонентой это не решалось ибо требовало именно что встроить очень крепко, прямо в платформенный код. Да, сейчас, когда я уже год только и занимаюсь нативной разработкой под андроид я бы это осилил, но боюсь это бы противоречило лицензионному соглашению с 1с, сделало бы практически невозможной обновление (ибо не факт что патч бинарника одной платформы подошел бы к другой) и заняло бы дофига времени. В итоге аудит мы прошли, но чисто административными методами, а бодания заняли примерно год.
Ну закидоны безопасников отдельная тема. И да, разработка под мобилку ведется специально, не в рамках того же самого приложения, как правило. Но тем не менее, это есть во фреймворке и есть классы приложений, которые можно делать без прибегания к внешним компонентам и всякому нативному.
Было бы классно послушать Ваш рассказ о реальном положении дел в мобиле для 1С и о том проекте
Да собственно уже почти все рассказал. Мобильный клиент это они придумали годно, но мобильное приложение — жесть. Сейчас может получше — но еще в 18 году было все до сих пор дико забаговано, разработка неудобна, и ни за что серьезное без знаний нативной разработки лучше не браться, выйдет все равно фигня.
Тоже занимаюсь разработкой и поддержкой мобильного приложения на платформе 1С. Ничего не изменилось:)
Сочувствую(( Хотя я пару новостей хороших слышал, например когда мы начинали еще даже редактора форм под мобилки не было, потом его хоть добавили, под конец проекта, когда уже все сделано было.
Я занимался поддержкой мобильного приложения для супервайзеров в аэропорту. Бэк тоже 1С, синхронизация через web-сервисы. Мобильная платформа 1с не подходит для систем, критичных к производительности. Скорость работы низкая по сравнению с нативными приложениями, т.к. девайсы были не первой свежести со старым андроидом. Стабильность работы никакая, фоновая синхронизация из-за проблем со связью виснет, лечится только перезапуском приложения. Вылазили системные ошибки при синхронизации, вылечилось, правда обновлением версии мобильной платформы.Ну и ограниченная функциональность, пришлось разбираться во внутренностях андроид для решения проблем взаимодействия с другим приложением. Но зато быстрый прототип, это да.
И еще — если к вам пришел наниматься 1С-ник, то 1С-ника можно смело ставить на должность лида аналитиков.
Похоже у кого-то скоро собеседование… </мысли в слух>
Редкой объективности статья про 1С. Впрочем, видя кем она написана — не удивительно. Респект.
Хочется добавить, что если очень нужно, брендировать интерфейс 1С теперь тоже умеет, просто это отдельная фича и не для всех.
Цвета перекрасить — вполне для всех. Стили в управляемом приложении стали доступны (с 8.3.13) и перекрасить приложение можно.
Поддерживаю
Опят показывает, что в обсуждениях про 1С никогда не удаётся поставить точку )
Скоро все закончится. Сейчас тренд — облачные решения и сервисы, работа с большими данными, микросервисы и т.п. В этих сферах 1с пролетает мимо и с большим свистом. Архитектура микросервисов позволяет взять и переписать любой сервис на НОВОЙ технологии, если она появилась, на ЛЮБОМ языке или фреймворке, если он лучше старого. Это избавляет от ловушек легаси, в которой застряла 1с и скоро просто утонет после того, как появятся государственные облачные сервисы, решающие задачи с учетом и отчетностью. Непонимание этой тенденции не оставляет в покое многих пытаться безуспешно выходить с технологиями прошлого века на международные рынки и тягаться там на поле с местными мастодонтами. Это глупо, как и глупо пытаться искать программистов 1с в среду, где зарабатывают на консалтинге и продажах коробок/лицензий.
Да, но два нюанса.
Первый — для того, чтобы клиент (маленькая шаражка на 10 человек) ощутила от этого выгоды — она должна быть клиентом SaaS сервиса (в котором внутри и отказоустойчивость, и микросервисы и все-все-все), но тут внезапно выясняется, что, во-первых, Ваши данные — не Ваши (они в облаке и принадлежат ему), а, во-вторых, если Вам очень нужна какая-то функциональность, то ее могут реализовывать годами, ибо Вы — не в приоритете. В случае НОРМАЛЬНЫХ SaaS (типа Slack) это решается богатым АПИ, которое клиент может использовать и тягать любые данные к себе. И наоборот.
Второй момент — получается, все эти микросервисы и прочее могут позволить только большие клиенты, т.к. у них есть возможность отстегивать за это кучу денег. Это реально дорого. Сложность программного обеспечения перемещается из одного уровня (в монолите вся сложность где-то внутри) на уровень связи между всеми этими микросервисами. С одной стороны, это позволяет быть просто супер-гибкими (действительно -не нравится микросервис — взяли, выкинули, внедрили новый). С другой — шаурмячная себе это позволить в принципе не сможет, но это ей и не нужно.
> как появятся государственные облачные сервисы, решающие задачи с учетом и отчетностью.
Это вообще мечта всех, наверное… Чтобы были качественные облачные гос. сервисы… экономящие деньги и силы граждан и других клиентов.
Первый — для того, чтобы клиент (маленькая шаражка на 10 человек) ощутила от этого выгоды — она должна быть клиентом SaaS сервиса (в котором внутри и отказоустойчивость, и микросервисы и все-все-все), но тут внезапно выясняется, что, во-первых, Ваши данные — не Ваши (они в облаке и принадлежат ему), а, во-вторых, если Вам очень нужна какая-то функциональность, то ее могут реализовывать годами, ибо Вы — не в приоритете. В случае НОРМАЛЬНЫХ SaaS (типа Slack) это решается богатым АПИ, которое клиент может использовать и тягать любые данные к себе. И наоборот.
Второй момент — получается, все эти микросервисы и прочее могут позволить только большие клиенты, т.к. у них есть возможность отстегивать за это кучу денег. Это реально дорого. Сложность программного обеспечения перемещается из одного уровня (в монолите вся сложность где-то внутри) на уровень связи между всеми этими микросервисами. С одной стороны, это позволяет быть просто супер-гибкими (действительно -не нравится микросервис — взяли, выкинули, внедрили новый). С другой — шаурмячная себе это позволить в принципе не сможет, но это ей и не нужно.
> как появятся государственные облачные сервисы, решающие задачи с учетом и отчетностью.
Это вообще мечта всех, наверное… Чтобы были качественные облачные гос. сервисы… экономящие деньги и силы граждан и других клиентов.
Не совсем так. Облачные решения — это сфера еще более массовая, чем тот сегмент рынка, что сейчас есть у 1с. И решения делаются еще более приспособленными для массоаого пользователя. И по цене в том числе. А от государства они будут еще и бесплатными.
шаурмячная себе это позволить в принципе не сможет, но это ей и не нужно
Согласно закона Конвея, микросервисная архитектура как раз идеально подходит для сети шаурмячных, т.к. не только отражает социальные связи между шаурмье, но и в некоторой степени является подобием самого процесса изготовления шаурмы (не нравится майонез — выкидываешь и заменяешь его чесночным соусом).
А если серьезно, то как раз в мелким клиентам всякие «1С:Fresh», «МойСклад» и т.д. легче заходят. Без всякой доработки. Такой парадокс, что те кто может себе позволить платить деньги за доработку SAAS решения, предпочитает сервер держать поближе к себе (ну или в каком-нибудь надежном далеком датацентре, но на своем выделенном сервере).
Спасибо! Отличный обзор! Очень посмеялся, очень хорошо написано, жизненно.
конструкции finally У меня есть гипотеза, что эта конструкция отсутствует из-за того, что не подобрали удачного перевода ее на русский язык :)
можно было сделать
ПОПРОБУЙ
здесь_код
ИСКЛ
обработка_ошибок
НАКОНЕЦ
обработка_finallyвидимо, выглядит некрасиво
1С весьма достойный продукт. В своем ценовом диапазоне я вообще не знаю аналогов, напишите в комментариях, если таковые есть. Однако, отток разработчиков из экосистемы становится все заметнее, а это "утечка мозгов", как ни крути. Отрасль жаждет модернизации.
не хватает сравнения с "великим и ужасным" SAP.
«накряйняк» прикольней)
Лучше так: :)
ПОПРОБУЕМ
здесь_код
НЕВЫШЛО
обработка_ошибок
ИВСЁТАКИ
обработка_finally
Есть ещё слова "эпилог", "финал" (или "финиш"), "исход", так же по смыслу может подойти слово "однако".
конструкции finally У меня есть гипотеза, что эта конструкция отсутствует из-за того, что не подобрали удачного перевода ее на русский язык :)
В конце концов,
Попытка
Исключение
ПослеПопытки
КонецПопытки
Было бы хорошо еще добавить в статье, что 1С — это монолит, и обладает всеми монолитными минусами, в то время, как прогрессивное человечество запрыгивает на микросервисную платформу.
как прогрессивное человечество запрыгивает на микросервисную платформу.
Только почему-то все забывают цену "впрыжка" туда....
Не всё можно загнать в микросервисы
я кстати думал об этом. это не невозможно. над CI/CD нужно будет конечно поработать, плюс нужна совершенно иная система обмена данными (на нормальных технологиях и отличных от текущих принципах), плюс облачную интеграцию закостылить (сквозная авторизация, балансировка и пр), но в целом, думаю, я смог бы запилить систему с нормальным откликом. Другое дело — кто готов вывалить мешок денег за это? ))
А много ли в мире учётных систем на микросервисах? Ну то есть не чтоб мелочёвка сбоку, а чтобы прямо главную книгу банка или что-то подобное на микросервисах?
А 1С предназначена исключительно для "главной книги банка"?
А ещё разные системы могут быть взаимно-интегрированы или пользоваться одними и теми же данными. Ещё здорово разделять сервисы для дополнительной устойчивости. Если система подсчёта кредитного рейтинга упала, то система работы с дебетовым счётом не должна от этого сильно страдать.
Аргумент "НЕ НУЖНО" выглядит по меньшей мере странно.
Не совсем монолит, но в силу изначального рождения как продукт исключительно для учёта, дальнейшие "мутации" не могли ослабить доминанту. 1С это очень хорошее решение для учета. В первую очередь для учета в торговли в РФ. Это было заложено в продукт "с рождения".
В силу этой генетической особенности решения, игрища с разными подходами к эволюционному развитию мало применимы и вредны. 1С это не нужно от слова совсем.
Даже отдельные разработки которые велись в стране не на базе 1С, но могли интегрироватся не могли улучшить ситуацию. Отдельные разрабатываемые модули "взлетели" и даже есть удачные примеры внедрения, но массового интереса к этим продуктам нет, и не планируется быть массовым.
Аналогично с Дамгаардом. Решение было с рождения приспособлено для учета и планирования на производственно-сбытовых предриятиях.
Не упомянут очень важный минус. Все современные типовые конфигурации 1С очень громоздкие и неповоротливые, сделаны по принципу «пихай всё что только можно сразу в типовое решение». Отсюда страшнейшие проблемы с производительностью. Причем как-то это исправить со стороны программиста 1С не возможно: в 1С не знают что такое модуляризация и внедрение зависимостей. Ну т.е. совсем не знают.
Есть функционал подсистем и функциональных опций, но он прямо скажем очень слабо развит.
В результате этой раздутости, помимо проблем производительности, возникают проблемы и с касомизацией под конкретного заказчика, любая доработка, даже казалось бы не значительная, выливается очень серьёзными трудозатратами — посмотрите стоимости внедрений современных ERP-УПП-БУ-УТ где-нибудь на тендерных площадках.
Есть функционал подсистем и функциональных опций, но он прямо скажем очень слабо развит.
В результате этой раздутости, помимо проблем производительности, возникают проблемы и с касомизацией под конкретного заказчика, любая доработка, даже казалось бы не значительная, выливается очень серьёзными трудозатратами — посмотрите стоимости внедрений современных ERP-УПП-БУ-УТ где-нибудь на тендерных площадках.
Не упомянут очень важный минус. Все современные типовые конфигурации 1С очень громоздкие и неповоротливые, сделаны по принципу «пихай всё что только можно сразу в типовое решение». Отсюда страшнейшие проблемы с производительностью.
На самом деле, нет.
Проблема, безусловно, касается монстроидальной УПП, но УПП уже почила в бозе (более развиваться не будет, только поддержка).
Все прочие (не буду говорить за криворукие поделки низкоквалифицированных программистов мелких фирмочек, речь тут только за фирменные типовые прикладные решения) — вполне себе юзабельные.
Не забывайте, что 1С работает на рынке готовых решений. Поэтому «сел и сразу поехал» это принципиальный момент. Подобные вещи должны удовлетворять требованиям большинства потенциальных покупателей. Следовательно, быть максимально универсальными. Следовательно, немалый объем кода.
Любой программист средней руки сможет написать существенно быстрее работающее но узкозаточенное решение (по крайней мере должен уметь, иначе он не программист средней руки, а так, начинающий). Что и создает иллюзию, что код 1С плохой.
Но стоит этому программисту, написавшему быстрый софт что решает мизерную часть задач от задач полной 1С, начать расширять функционал — он сразу поймет, что уровня 1С ему никогда не достичь с сохранением той же производительности, что и у маленького решения.
Да, это практически именно то, что я хотел сказать.
«сел и сразу поехал» это принципиальный момент.
Посчитайте стоимость серверного железа и лицензий на серверное ПО (1С, MS, MS SQL) при нагрузке хотя бы в 100 человек online. Чтобы на типовом решении «сесть и сразу поехать» нужен очень большой бюджет. И становится весьма спорно, а перевешивают ли плюсы минусы.
Ну серверное железо в любом случае нужно, независимо от стека технологий. Без сервера не заработает. Железо на "100 человек онлайн" нужно весьма скромное. Лицензии да, нужны, но тут какое дело — если надо 100 человек но нет денег на лицензии, значит не нужно 100 человек. Обычно, если решение делается под сотни пользователей — покупаются ключи по 500 и бюджет особо не смущает. А когда нет денег на сотку, то скорее всего, конторка слабовата, хоть и хочет себе "большой" сервер.
Если вам продали клиентские лицензии по 500 рублей, вас, я извиняюсь, обманули. Ну и, соответственно, вся дальнейшая математика неверна.
Железо на «100 человек онлайн» нужно весьма скромноеЭто либо у нас разные представление о скромности, либо вас обманули дважды.
«по 500» это не «по 500 рублей», а «комплект лицензий по 500 штук».
Железо на «100 человек онлайн» нужно весьма скромное
Это либо у нас разные представление о скромности, либо вас обманули дважды.
Зарплата, налоги, офис на 100 человек — это порядка 10 000 000 рублей ежемесячно из расчета средней 50 000 зарплаты на человека.
И что по сравнению с 10 000 000 рублей ежемесячных трат вы считаете дорогим в вопросе одноразовых трат на покупку сервера?
Это простому человеку сумма кажется большой.
А для предприятия со 100 сотрудниками — покупка серверного оборудования вовсе не самая значительная трата в течение года. На фоне то же зарплаты или аренды помещений стоимость сервера теряется.
Тут у вас слишком грубые расчеты, смысла нет. Это с одной стороны, а с другой стороны, внедряя типовое решение на более-менее сложном объекте, вы столкнетесь с необходимостью доработок и кастомизации под заказчика, и тут все прелести типового решения как универсального и подходящего всем (как позиционируется), опять же выльются очень серьёзными трудозатратами, а это время и деньги к которым нужно быть готовым.
Тут у вас слишком грубые расчеты, смысла нет.
Затраты в 10 млн. рублей в месяц на 100 сотрудников, на запрату, налоги, офис — даже заниженные.
вы столкнетесь с необходимостью доработок и кастомизации под заказчика, и тут все прелести типового решения как универсального и подходящего всем (как позиционируется), опять же выльются очень серьёзными трудозатратами, а это время и деньги к которым нужно быть готовым.
Я этими разработками занимаюсь профессионально уже очень много лет.
Нет ничего страшного.
Главное:
По сравнению с 100% разработкой под себя — доработка типового решения это тьфу, копейки. Ну и времени куда как меньше. И результат гарантированее.
Исключения бывают, когда целесообразно сделать именно не типовое, именно с нуля. Но это именно что исключения.
доработка типового решения это тьфу, копейки… Я этими разработками занимаюсь профессионально уже очень много лет.
Нет ничего страшного.
Так что, получается, мы с вами живем на копейки…
Нет, это не копейки, очень серьезная работа с довольно большим порогом вхождения, с очень крепкими нервами, ну и с высокими зарплатами.
И наверняка, бизнес хотел бы это исправить, но пока не может.
Так что, получается, мы с вами живем на копейки…
Разумеется.
Бизнес не стал бы платить, если ли бы для него это были действительно существенные деньги.
Фокус в том, что «для предприятия копейки, а для человека очень даже дофига».
Нет, это не копейки, очень серьезная работа с довольно большим порогом вхождения, с очень крепкими нервами, ну и с высокими зарплатами.
И наверняка, бизнес хотел бы это исправить, но пока не может.
Не вижу никакой неразрешимой проблемы.
Есть только одна-единственная сложность: всё дело только в том, что за человек занимается принятием решений — где брать типовую, а где пилить своё.
Какова квалификация этого конкретного человека и каковы конкретные требования бизнеса.
доработка типового решения это тьфу, копейки
В корне неверное мнение, покупка коробки — это да, тьфу копейки. Но на этом только все начинается. Я знаю очень много заваленных примеров внедрения решений 1С, тут можно назвать и УТ, и УПП, и ERP, местами даже ЗУП умудряются завалить. Вот в чем проблема.
В корне неверное мнение, покупка коробки — это да, тьфу копейки. Но на этом только все начинается. Я знаю очень много заваленных примеров внедрения решений 1С, тут можно назвать и УТ, и УПП, и ERP, местами даже ЗУП умудряются завалить. Вот в чем проблема.
Я этим занимаюсь профессионально очень много лет. Видел и удачные внедрения без каких-либо доработок вовсе. Видел и переписанные с нуля.
Утверждаю, что типично — всего лишь очень небольшие изменения вносятся в код. Этого достаточно подавляющему большинству предприятий для начала эксплуатации 1С: Предприятия.
Потом, возможно, будут еще доработки. Но для начала эксплуатации множество доработок при внедрении — не типичная ситуация.
Не означает, конечно, что описанной вами ситуации нет в принципе. Отчего же — есть. Но нечасто.
Я эти ситуации в своей карьере хорошо помню, так как это хорошие деньги мне лично. К сожалению они не типичны, не часты.
Посчитайте стоимость серверного железа и лицензий на серверное ПО (1С, MS, MS SQL) при нагрузке хотя бы в 100 человек online. Чтобы на типовом решении «сесть и сразу поехать» нужен очень большой бюджет. И становится весьма спорно, а перевешивают ли плюсы минусы.
1) Почему MS-SQL, а не бесплатный PostgreSQL, с которым 1С уже много лет умеет работать?
2) Давайте посчитаем на 100 человек ежемесячный бюджет. Зарплата + налоги + физические рабочие места. При зарплате в 50 000 рублей в месяц — это около 10 000 000 рублей расходов в месяц. Ежемесячно. Что на этом фоне разовая стоимость внедрения (последующая тех. поддержка уже значительно дешевле чем первичное внедрение)?
Это нам, простым людям, кажется, что сумма огромная. Но для предприятия — это обычные оперативные расходы для осуществления его деятельности каждый день и каждый месяц.
Поймите, предприятие интересует вовсе не бездумная экономия на всем и вся. Предприятие интересует оперативное решение его бизнес-задач с возможной минимизацией расходов при этом. Если экономия где-то невозможна в принципе, если где-то экономия ухудшает решение первичных бизнес-задачи — предприятие не экономит на таких вещах. Первичны решения бизнес-задач — именно они и дают прибыль.
И становится весьма спорно, а перевешивают ли плюсы минусы.
Фирму интересуют не столько деньги, сколько сроки. Ибо не успел — и потерял кучу потенциальной прибыли.
«Сел и поехал» VS «Разрабатывать своё в течение пары лет» (с рисками что не получится, что специалист уйдет)?
Бизнес уже дал ответ на это.
Лет 20 назад не пилил своё только ленивый. Сейчас — типично как раз что подавляющее большинство сидит на готовых решениях (в большинстве это 1С: Предприятие).
Разумеется, не типовые решения имеют место быть. И платят за них хорошо.
Я как раз этим и занимаюсь — очень не типовой автоматизацией.
Но если есть возможность интегрировать в проект уже готовые решения на 1С, решающие свою часть задач, то я всегда за это. Пусть даже, на первый взгляд, это и в ущерб моем доходу, ведь не я это делаю за отдельные деньги. Но на практике проект начинает приносить прибыль гораздо раньше. И значение продуктов 1С в этом значильно. Проект начинает приносить прибыль — владелец доволен, владелец имеет все увеличивающиеся финансовые возможности, — поэтому охотно тратит еще и еще больше на развитие проекта (и на мою работу по уникальным разработкам в т. ч.)
Уникальные не типовые куски проекта делают у меня только отдельные специфические задачи, только те, где они заведомо на порядки выгоднее типовых решений.
Почему MS-SQL, а не бесплатный PostgreSQL, с которым 1С уже много лет умеет работать?
А потому что вы не сможете привести реальный пример внедрения какой-нибудь типовой конфигурации 1С на PostgreSQL, к сожалению.
Да ладно! Господин Дорошкевич, если вы нас слышите, не могли бы вы набросать зачетных примеров внедрения на постгресах?
Сомневаюсь, что он что-то толковое ответит… Франчи обычно работают по принципу — выставил клиенту побольше заоблачных часов и свалил поскорее и подальше, пока тот не опомнился. А разгребать будут совсем другие ребята.
Если вы думаете, что PostgreSQL — это серебряная пуля, поздравляю, вы молоды и только в начале пути.
Если вы думаете, что PostgreSQL — это серебряная пуля, поздравляю, вы молоды и только в начале пути.
У меня достаточно хороший опыт эксплуатации 1С на постгрес, в-основном нетиповых, поэтому, раз уж вы спрашивали именно про типовые, я и призвал Антона. А так — постгрес отлично работает на 1С, да, требует тюнинга, ну так и MS требует, это же норма вроде как — настраивать вверенную систему.
А есть толковые мануалы для людей уровня сисадмина — как тюнить Postgress для 1С? Сталкивались с тем, что на Postgress проблемы с производительностью, переходишь на MS SQL — проблемы уходят.
У нас нет опыта тюнинга Postgress, рекомендуем приобретать MS SQL. Клиент приобретает.
Возможно, это неправильно, но клиенту надо работать здесь и сейчас, он не будет ждать, пока мы найдем причину тормозов в связке Postgress + 1С, а MS SQL вполне отработан.
У нас нет опыта тюнинга Postgress, рекомендуем приобретать MS SQL. Клиент приобретает.
Возможно, это неправильно, но клиенту надо работать здесь и сейчас, он не будет ждать, пока мы найдем причину тормозов в связке Postgress + 1С, а MS SQL вполне отработан.
Толковые мануалы — мануалы по постгресу и иногда ради любопытства заглядывание в планы запросов. Обычно все решаемо. Запросы очень часто могут работать на разных СУБД с разной скоростью, это норма. Вполне себе бывают запросы, которые ложатся на MS, но работают на PG. Кроме того, для нагруженных 1С существует коммерческая версия PostgresPro, которая по бенчмаркам уделывает коммерческий же MS SQL (но я ее не щупал).
он не будет ждать, пока мы найдем причину тормозов в связке Postgress + 1С, а MS SQL вполне отработан.
И да, безусловно задачу клиента за его деньги надо делать на том инструменте, которым вы владеете лучше. Не надо внедрять постгрес ради постгреса.
Открою вам пару секретов:
1) Тюнингом параметров всех проблем производительности не решить. Бенчмарки дело хорошее, но если бы всё было так просто, никто бы и не смотрел в сторону MS SQL.
2) Цена коммерческой версии PostgresPro сопоставима с ценой MS SQL, политика лицензирования также похожа (есть варианты на ядра, есть на пользователей). Думаю, очевидно, почему так.
1) Тюнингом параметров всех проблем производительности не решить. Бенчмарки дело хорошее, но если бы всё было так просто, никто бы и не смотрел в сторону MS SQL.
2) Цена коммерческой версии PostgresPro сопоставима с ценой MS SQL, политика лицензирования также похожа (есть варианты на ядра, есть на пользователей). Думаю, очевидно, почему так.
Хм… тюнингом не решить, переписыванием запросов не решить, а чем решить?
В прошлом холиваре один внедренец предлагал сначала реорганизовать бизнес-процесс клиента, а только потом лезть в оптимизацию.
В зависимости от степени неадекватности существующих процессов у клиента это может быть и не самый плохой путь.
Хотя, справедливости ради, не совсем понятно — причем тут оптимизация запросов — типа, а давайте у вас закупщики будут вносить информацию только до обеда, продажники — после обеда, а бухгалтера вообще по ночам работают, чтобы программа не тормозила?
P.S. вот пока писал, вспомнил, что на одном из мест работы похожим образом была организована работа фин. отдела, потому что много лет назад обмен между ИС запускали вручну. и пару раз в день («так исторически сложилось»). Меняли процесс в обратную сторону — запустили регулярный автоматический обмен, но так и не нашли понимания у привыкших к старому режиму финансистов, даже просили «вернуть как было».
Хотя, справедливости ради, не совсем понятно — причем тут оптимизация запросов — типа, а давайте у вас закупщики будут вносить информацию только до обеда, продажники — после обеда, а бухгалтера вообще по ночам работают, чтобы программа не тормозила?
P.S. вот пока писал, вспомнил, что на одном из мест работы похожим образом была организована работа фин. отдела, потому что много лет назад обмен между ИС запускали вручну. и пару раз в день («так исторически сложилось»). Меняли процесс в обратную сторону — запустили регулярный автоматический обмен, но так и не нашли понимания у привыкших к старому режиму финансистов, даже просили «вернуть как было».
У того комментатора посыл был в том что если запросы тяжелые или их нужно делать часто — значит нужно менять бизнес процессы чтобы их не было. Всегда. А оптимизировать запросы бессмысленно и неправильно поскольку на его взгляд разрабатывать качественную с технической точки зрения систему дорого и долго. Нужно брать коробку и подгонять бизнес процессы к ней. Если бизнес процессы не укладываются в коробки — значит они неправильны.
Ну, если заменить «всегда нужно» на «возможно нужно», то мнение имеет право на жизнь.
Так делает сап, это их прямо методичка: наши процессы выверены и непогрешимы, если у нас чего то нет — вам это не нужно. Ну а то, что склад называется "завод" это надо просто принять и поверить. С вас $2 млн
Это, кстати часто правильно.
Проблема в том, что там не просто тюнинг. Там иногда надо запросы полностью переписывать для быстрого выполнения (у них оптимизиторы по разному работают). А, учитывая, что типовые сплошь на плоском псевдо-SQL, то очень тяжело сделать, чтобы они одновременно эффективно выполнялись на обоих базах. Поэтому видимо в 1С просто тюнингуют их под MS SQL, а на PostgreSQL — как получится. Понятно, что франчам тогда логичнее не связываться с PostgreSQL.
Ну прям очень странно так говорить.
Открываешь справочник внедренных решений, содержащий отчеты от фирм партнеров и смотришь.
Любому клиенту или внедренцу можно позвонить и спросить действительно ли это так.
А что тут странного. Приведите пример УТ, ERP, БУ, где 100+ рабочих мест на PostgerSQL. Ну есть ДО 300 рабочих на PostgreSQL 1c.ru/rus/partners/solutions/solution.jsp?SolutionID=968986. Но это документооборот всего лишь. Сравнение вообще ни о чем, не та интенсивность работы, ни тот функционал.
Мне известно внедрение в одном федеральном министерстве на 1000+ пользователей на постгрес.
Фрешик https://1cfresh.com
Мы сейчас используем PostgeSQL в нашем облаке на типовых отраслевых 1С конфигурациях. На нодах от 100 до 300 активных пользователей. Работает отлично.
Вот вы говорите, что при ежемесячных тратах бизнеса 10 000 000 на 100 человек, цена закупки это копейки. Это справедливо для небольшого количества фирм с бешенной маржинальностью. У большинства, при расходах в 10 000 000 рублей в месяц, реальная прибыль максимум 10% в наличном эквиваленте. А теперь еще возьмите во внимание то, что это для сотрудников деньги какой-то «фирмы». Для собственника, который принимает решение о затратах, это прямой убыток из кармана. Причем прям ровно на сумму затрат. А теперь подумайте, что таких разовых закупок как закупка серверов, каждый месяц хватает. После этого вы поймете почему в подавляющем количестве фирм, которые не живут на гос датациях, закупка всякого «важнейшего» с точки зрения айтишников, железа — это не копейки.
Кстати в целом согласен. Поскольку есть некоторый опыт участия в разработке коробок — что то модульное сделать действительно почти нереально. Как то, пусть не идеально, это получается у БСП, но там над этим работает большая команда крутых профессионалов, в других продуктах от 1с и франчей таких команд немного, если вообще есть.
критики 1С критикуют ее с позиции «не осиливших»не очень вяжется с правосудием на картинке, хотя наличие пункта «1С должна умереть» в голосовалке заставляет признать мужество автора )
Спасибо автору, после такой статьи, можно перестать скрывать что пишешь на русском )
А зачем было скрывать? Даешь каминг-ауты! ))))
Если бы проблемой языка была русскоязычность… Автор как раз вполне верно описал минусы языка. Вот без шуток — из современных языков вижу наиболее подходящим для платформы дарт. Многопоточности нет, есть изоляты работающие по модели акторов и встраивающиеся в механизм асинхронности через async/await. Типизация по умолчанию статическая, но есть простенький вывод типов позволяющий меньше кода писать. Причем работает не только для переменных но и для параметров функций. Также есть тип dynamic для совсем маргинальных случаев. Очень удобные методы работы с коллекциями
А вот с тем что не нужны лямбды — не согласен. Опять же — офигенно удобный способ работы с коллекциями в сочетании с возможностью использовать функции как объекты первого класса. ООП считаю тоже стоило бы иметь, но раз уж столько противников его завоза в 1с — ввели хотя бы те же экстеншен методы, позволяло бы стандартным объектам платформы добавлять новую функциональность.
например collection if/for вообще до того ни в каких языках не видел
Dart 2.3 also introduced collection if and collection for, which you can use to build collections using conditionals (if) and repetition (for).
Here’s an example of using collection if to create a list with three or four items in it:
Here’s an example of using collection for to manipulate the items of a list before adding them to another list:
Here’s an example of using collection if to create a list with three or four items in it:
var nav = [
'Home',
'Furniture',
'Plants',
if (promoActive) 'Outlet'
];Here’s an example of using collection for to manipulate the items of a list before adding them to another list:
var listOfInts = [1, 2, 3];
var listOfStrings = [
'#0',
for (var i in listOfInts) '#$i'
];
assert(listOfStrings[1] == '#1');А вот с тем что не нужны лямбды — не согласен. Опять же — офигенно удобный способ работы с коллекциями в сочетании с возможностью использовать функции как объекты первого класса. ООП считаю тоже стоило бы иметь, но раз уж столько противников его завоза в 1с — ввели хотя бы те же экстеншен методы, позволяло бы стандартным объектам платформы добавлять новую функциональность.
Вот функции первого порядка — однозначно нужны. Насчет лямбд и сложностей с областями видимости замыкаемых переменных — уже не уверен на все 100.
Ну лямбда не обязательно должна контекст замыкать. Часто этого и не нужно. Впрочем и замыкания нередко бывают полезны. В той же java замыкание может только final переменные захватывать, сами понимаете — сложностей тут немного. В котлине вот правда можно любые переменные и свойства захватывать — но как то тоже проблем не возникало.
Ну лямбда по-определению может что-то захватывать. Т.е. если в языке есть лямбды — они должны предоставлять такую возможность, или нельзя заявлять, что в языке есть лямбды.
Как минимум вики-чан и stackoverflow с вами не согласны.
wiki
In computer programming, an anonymous function (function literal, lambda abstraction, or lambda expression) is a function definition that is not bound to an identifier. — условия о замыкании нет.
SO
A lambda is just an anonymous function — a function defined with no name. — аналогично.
Я перед каментом почитал википедию: "Применяется как правило для объявления анонимных функций по месту их использования, и обычно допускает замыкание на лексический контекст, в котором это выражение использовано." Это определение совпадает с тем, как я себе понимал отличия собственно лямбда-функций от просто функций, как объектов первого класса. Я, конечно, могу ошибаться, но и в достоверности камента на stackoverflow тоже позволю себе усомниться.
Замыкание контекста собственно допускают замыкания, которые могут быть как анонимными функциями (лямбдами) так и неанонимными. Это не неотъемлимое свойство лямбды. Насколько помню всю эту мутную теорию лямбда исчисления (неплохо разбиралось в подкасте «Мысли и методы», пусть поверхностно, но мне глубже и не надо) — там вообще не описывается прикладная реализация, но параметры в записи лямбды там указываются вроде явно, как параметры анонимной функции это все выглядит. Плюс те же анонимные функции в java вполне себе считаются лямбдами хотя не могут захыватывать изменяемые переменные, например.
Окей, тогда я поясню мысль: функции первого порядка в 1С нужны. Замыкания — не уверен.
Анонимные функции нужны тоже. Иначе будет скоуп замусориваться функциями нужными только в одном месте.
Да, нужны. Но нужна ли им возможность захвата внешнего контекста?
В 1с под вопросом. Все таки в массе квалификация разработчиков около нуля и они не факт что осилят. А вообще нужна, имхо)
Зачем это осиливать? Это как раз естественное поведение, которое разработчик ждет. Если он упоминает внешнюю переменную, то ждет, что именно она и будет в лямбда-функции.
Если он упоминает внешнюю переменную а лямбда в языке не поддерживает замыкание на изменяемых переменных — должна падать ошибка компиляции. Поверьте, встречал разных программистов, и мнения у них даже насчет банальных вещей нередко не сходятся.
Вам нагуглить классический пример с лямбдой и циклом for по замыкаемой переменной?
ОбработкаОповещения + ДополнительныеПараметры.
В php решено конструкцией use, в js — доступностью всего контекста. Или как это правильно написать?
В php решено конструкцией use, в js — доступностью всего контекста. Или как это правильно написать?
Да ну, в 1с (как и в общем случае в обычной бизнес-логике) половина кода — это унылое перекладывание данных в коллекциях в циклах. Лямбды и мапы типа laravel collections сделали бы это занятие гораздо приятнее и веселее.
Вторая половина — это запросы, и аналог linq to sql тоже очень бы пригодился. Причем 1с вроде бы тоже так думает и даже что-то сделала, но настолько неудобное, что этим никто не пользуется.
Вторая половина — это запросы, и аналог linq to sql тоже очень бы пригодился. Причем 1с вроде бы тоже так думает и даже что-то сделала, но настолько неудобное, что этим никто не пользуется.
Вот только 1с в последнее время позиционирует себя отнюдь не как система для ларьков. В том и дело.
И нет, студенту с тем же дартом или питоном разобраться не сложнее чем с язком 1с, а преимущества они дают значимые. Хотя конечно более заметные только при разработке конфигураций с нуля или создании больших подсистем новых. И поддержке с рефакторингом созданного.
И нет, студенту с тем же дартом или питоном разобраться не сложнее чем с язком 1с, а преимущества они дают значимые. Хотя конечно более заметные только при разработке конфигураций с нуля или создании больших подсистем новых. И поддержке с рефакторингом созданного.
Я если что говорю о замене встроенного языка 1с с сохранением всей 1сной инфраструктуры и стандартных конфигураций. Т.е. тот же ЗУП на платформе 1с но вместо встроенного языка дарт или питон. А не о написании прикладных решений с нуля для замены ЗУП того же.
Ну питон не самый лучший вариант. Дарт больше бы подошел. А дают эти языки более выразительные средства для построения абстракций которые нужны при больших доработках/разработках систем с нуля, а так же упрощают сопровождение и рефакторинг.
Говорю вам как человек перешедший с 1с на котлин — работа очень облегчается за счет отличной инструментальной поддержки, а средства построения абстракций позволили бы например для каждой конфигурации делать свой DSL, для конкретной предметной области конфигурации. Ну правда простые средства для построения DSL это к дарту и питону относится меньше чем к котлину, тем не менее котлин и посложнее в освоении чем язык 1с, а вот дарт и питон освоить ни разу не труднее, и любой кто освоил 1с смог бы и их с тем же успехом освоить. Тот же питон используют часто вообще не программисты, а как раз специалисты в своей области. Биологи, экономисты и прочие для анализа данных.
Говорю вам как человек перешедший с 1с на котлин — работа очень облегчается за счет отличной инструментальной поддержки, а средства построения абстракций позволили бы например для каждой конфигурации делать свой DSL, для конкретной предметной области конфигурации. Ну правда простые средства для построения DSL это к дарту и питону относится меньше чем к котлину, тем не менее котлин и посложнее в освоении чем язык 1с, а вот дарт и питон освоить ни разу не труднее, и любой кто освоил 1с смог бы и их с тем же успехом освоить. Тот же питон используют часто вообще не программисты, а как раз специалисты в своей области. Биологи, экономисты и прочие для анализа данных.
Все просто объясняется, ни разу не тем что язык 1с такой хороший, во время создания 1с их язык был по тем меркам более менее современным, да и задачи они гораздо проще решали чем сейчас, потому они очень хорошо зашли на рынок СНГ плюс они удачно организовали бизнес модель с франчайзингом и теперь за счет этого имеют массовость и запас капитала (человеческого и финансового) на противостояние конкурентам, что конкуренты тоже понимают.
С тех пор языки эволюционировали очень сильно, в отличие от языка 1с, но бодаться с 1с на рынке СНГ за мелкие фирмочки разрабам на этих языках очень сложно за счет того что потребуется просто огромное количество трудозатрат на разработку похожего фреймворка с нуля, нескольких прикладных решений на нем, а так же просто гигантские затраты на маркетинг, завоевание доверия клиентов которые выбирают пусть менее удачные но проверенные временем решения, и создание сети разработчиков подготовленных для работы с этим фреймворком.
В общем успех 1с на рынке СНГ объясняется отнюдь не технологическим превосходством (под которым я понимаю в т.ч. удобство разработки и поддержки решений).
И нет, если бы сложность разработки не зависела от языка — мы бы так до сих пор и писали на C/asm/алголе и прочих динозаврах.
С тех пор языки эволюционировали очень сильно, в отличие от языка 1с, но бодаться с 1с на рынке СНГ за мелкие фирмочки разрабам на этих языках очень сложно за счет того что потребуется просто огромное количество трудозатрат на разработку похожего фреймворка с нуля, нескольких прикладных решений на нем, а так же просто гигантские затраты на маркетинг, завоевание доверия клиентов которые выбирают пусть менее удачные но проверенные временем решения, и создание сети разработчиков подготовленных для работы с этим фреймворком.
В общем успех 1с на рынке СНГ объясняется отнюдь не технологическим превосходством (под которым я понимаю в т.ч. удобство разработки и поддержки решений).
И нет, если бы сложность разработки не зависела от языка — мы бы так до сих пор и писали на C/asm/алголе и прочих динозаврах.
Я тоже вас не понимаю. У вас какое то искаженное представление о мире по моим ощущениям. В котором вы считаете что 1с захватило дорогие рынки. При том что наиболее денежный ентерпрайз сидит на C#/java/scala/etc. Наиболее опытные разработчики и ИТ компании вовсе на рынок СНГ не смотрят. Зачем, если работать на забугорье выгоднее.
А захватывать дешевые рынки с малыми фирмочками не очень выгодно, а потребует в СНГ дофига затрат. Кроме 1с никому это особо не нужно. Невелика потеря.
А захватывать дешевые рынки с малыми фирмочками не очень выгодно, а потребует в СНГ дофига затрат. Кроме 1с никому это особо не нужно. Невелика потеря.
Почему, по прошествии стольких лет, остальные системы так и не переключились на бизнес.
Если вы чего-то не видите, это не означает что чего-то нет.
Проекты вроде сбора данных из различных систем крайне трудно сделать типовым решением, чтобы тиражировать как 1С. Они всегда на заказ, под ключ и зачастую под NDA. Потому что системы бывают весьма разнообразными и важными для бизнеса.
То, что имеет маркетинговое имя и продвигается в медиа — это кубики для сборки продукта. Например для запуска по расписанию вроде Apache Airflow, для мониторинга ELK, для обработки вроде Apache Spark или компоненты для хранения вроде того же Hadoop.
Извините заранее, немного вклинюсь в ваше диалог.
> Не понимаю. Честно
Хм… Я вот вижу противоречие. Чуть выше пытаться доказать, что 1С полностью захватил нишу, а потом удивляться, почему в неё не лезут другие. Так все просто. Рынок занят и для откусывания от него куска нужно вложить большем, чем этот рынок способен дать.
> Не понимаю. Честно
Хм… Я вот вижу противоречие. Чуть выше пытаться доказать, что 1С полностью захватил нишу, а потом удивляться, почему в неё не лезут другие. Так все просто. Рынок занят и для откусывания от него куска нужно вложить большем, чем этот рынок способен дать.
Друзья и коллеги, в последнее время на Хабре участились статьи с хейтом в адрес 1С, как платформы для разработки, и выступлениями ее защитников. Эти статьи обозначили одну серьезную проблему
Эти статьи обозначили известность, распространенность и популярность продукта 1С: Предприятие.
Из чего последовало: а почему бы не попиариться за счет хейта такого продукта?
Ровно то же происходило и с MS, когда положение MS было не поколебимо на рынке ОС. Не пинал MS только ленивый.
Ну банально: сколько я соберу комментов/лайков под статьёй про какую-нибудь MyCRM (название выдумано)? 1-2-5?
А стоит написать про 1С, да обкакать покрасивше — так я только для начала заполучу сходу десятки комментариев от тех, кто 1С действительно знает и способен объективно мне возражать. Так и тех, кто не в теме и просто пришёл
Если человек хорошо представляет о чем говорит, то почему бы ему про это не написать? Грамотная и годная техническая статья.
Я вообще за большее количество статей от людей с большим опытом, а не от "двадцатитрехлетних синьеров" пишухих очередную CMS/убийцу_гугла/фрейворк.
Я вообще за большее количество статей от людей с большим опытом, а не от "двадцатитрехлетних синьеров" пишухих очередную CMS/убийцу_гугла/фрейворк.
Если человек хорошо представляет о чем говорит, то почему бы ему про это не написать? Грамотная и годная техническая статья.
Да, конкретно этот человек — представляет то, о чем он пишет.
Я про другие статьи.
Например:
О сравнении специализированного решения 1С с языками программирования общего назначения.
Тем безусловно, будет понятная большинству Хабра, что пишет именно на языках общего назначения. Им будет приятно почувствовать превосходство своего инструментам по решению любых задач.
В этих статьях почему-то не пишется о том, что типовая задача «БД + форма ввода данных» полноценно решается в 1С за 10 секунд (буквально, без преувеличения). Наверное, потому что в языках общего назначения это решается за в десятки раз большее время в самом оптимистичном случае? И хайпа на такой статье не словишь — ведь ты покажешь не плюсы, а минусы языков, на которых пишет большая часть Хабра?
А вы действительно думаете что microsoft не за что ругать что тогда что сейчас? Вы их продукцией не пользуетесь?
А вы действительно думаете что microsoft не за что ругать что тогда что сейчас? Вы их продукцией не пользуетесь?
Бездумная ура-риторика типа «MS говно делает, даешь Linux, он заведомо хорош просто потому что бесплатен и открыт и наплевать на корявый графический интерфейс Linux»? Я про такое.
Ругают MS только потому что она на верху пищевой цепочки.
Альтернативы уступают по универсальности Винде, умеют значительно меньше, но при этом все равно содержат огромное количество косяков.
Только крайне узкоспециализированные, ограниченные решения (типа голой командной строки Linux, без GUI) не конкурируют с Windows по количеству косяков.
Я люблю десятку винду (хотя пишу это сообщение из под manjaro). Но то что кто то по каким то причинам является лидером рынка не повод его не ругать. Линукс выигрывает в одних аспектах, мак в других. Винда что то среднее со своими плюсами и минусами, но ругать ее можно очень много за что и нужно. Как и линкусы с маками. По крайней мере я регулярно все три системы поливаю.
Но то что кто то по каким то причинам является лидером рынка не повод его не ругать.
Вопрос как ругать.
Вот статья автора вполне себе объективна.
Я же вам привел в пример ситуацию когда ругают просто ради хайпа, просто пользуясь умонастроениями относительно топового продукта, ожидая с большой вероятностью получить плюсики просто за не за что.
На самом деле, довольно сложно сделать эту, казалось бы, простую задачку — сквозной нумератор сущностей, с разрезом уникальности по некоторому набору ключей, префиксацией, так чтобы это не блокировало базу при параллельном вводе данных.
Запросто это делается.
И еще — если к вам пришел наниматься 1С-ник, то 1С-ника можно смело ставить на должность лида аналитиков.
И он вам такого захардкодит, будете разбирать до скончания времен. 1с программеры просто обожают хардкодить и привязываться ко всяким неочевидным штукам. Я уже более сотни раз ловил на вещах типо привязки обработки пользователей к их расположению в дереве.
Кроме того, вы ка кто элегантно обошли тот факт, что 1с использует СУБД как тупую хранилку.
Забыли упомянуть про фантастический оверхед выборок.
А как весело 1с обращается с тем же pg, это просто нечто: когда я увидел lock на information_schema да еще с таймаутом в 5 минут, мне хотелось убивать.
Так же к очень серьезным недостаткам стоит отнести их зоопарк конфигураций в той же мере как и к достоинствам. Нужно проверять дотошно вообще все аспекты, которые когда-либо могут пригодиться. Скажем, когда в последний раз я видел УТ, в ней небыло даже намека на профили/группы пользователей, а в комплексной уже пожалуйста.
Запросто это делается.
Если учесть контекст "(и потом «ой, а почему у нас дырки»)", то задача
сквозной нумератор сущностей, с разрезом уникальности по некоторому набору ключей, префиксацией, так чтобы это не блокировало базу при параллельном вводе данных.
становиться сложнее.
Берете общий sequence и вперед, как первый вариант.
Окей. Отмасштабируйте решение на 4 движка СУБД и добавьте периодичность нумерации по ключам "Год/месяц/день", "Вид сущности" и возможность указания произвольного префикса в начале генерируемого номера.
Про движки ответ у меня простой: любой каприз за ваши деньги. Oracle/MSSQL/PostgreSQL имеют схожий функционал, я думаю разобраться можно.
Как видите, ВСЕ ваши требования сейчас реализованы. Хотя вроде «Вид сущности» пропустил, но тут надо описание сути, понимаете же, мне ничего не стоит еще конкатенацию добавить.
create table my_precious_docs(
id serial,
doc_number varchar not null,
doc_year char(4) not null default to_char(current_date, 'YYYY'),
doc_sum decimal(18,2) not null default 0,
primary key(id),
unique(doc_year,doc_number)
);
create or replace function id_for_year() returns trigger
language plpgsql AS
$$
declare
seqname text := 'seq_' || new.doc_year;
prefix char(1) := 'Н'; -- можно и в справочник
begin
if seqname is not null then
execute 'create sequence if not exists ' || seqname;
execute 'select $1||nextval($2)' into new.doc_number using prefix,seqname::regclass;
end if;
return new;
end;$$;
create trigger id_for_year before insert on my_precious_docs for each row
execute procedure id_for_year();
Как видите, ВСЕ ваши требования сейчас реализованы. Хотя вроде «Вид сущности» пропустил, но тут надо описание сути, понимаете же, мне ничего не стоит еще конкатенацию добавить.
В соединение1 выполнили insert. Выполнился инкремент sequence. В соединении2 происходил такой же процесс. Они выполнялись транзакционно (допустим на уровне serializable). Соединение1 долго тупило и в итоге получили rollback. Вопросы:
1) возникла ли при этом блокировка?
2) возникла ли при это дыра в сквозной нумерации?
1) возникла ли при этом блокировка?
2) возникла ли при это дыра в сквозной нумерации?
>Отмасштабируйте решение на 4 движка СУБД и добавьте периодичность нумерации
ANSI SQL вам в помощъ.
Но зачем такое в трезвом уме и памяти?
Это такое извращенное видение мира одноэсника?
Делает так, потому что может?
ANSI SQL вам в помощъ.
Но зачем такое в трезвом уме и памяти?
Это такое извращенное видение мира одноэсника?
Делает так, потому что может?
Он не решает задачу «без дырок» в условиях конкурентного доступа и минимизации блокирования.
Тогда в примере выше ставим default для doc number а тригер переделываем под after insert
Т.е. когда произошел commit, так?
Усложним задачу: нужна сквозная нумерация на несколько таблиц, например счета-фактуры и счета-фактуры на аванс — это разные сущности, хранящиеся в разных таблицах с разной структурой данных, которые должны иметь общий нумератор.
Еще усложним задачу: нумерация должна зависеть от владельца: т.е. есть какой-то реквизит таблицы, колонка, по которой идет кластеризация данных таблицы: например: НоменклатураПоставщиков всегда зависит от Контрагента, и надо нумеровать для каждого контрагента отдельно в рамках одной таблицы.
Еще усложним задачу: разработчик не хочет писать эти кучу триггеров, он хочет присвоить метаданные для таблицы в которых опишет правила нумерации, и по правилам нумерации они должны распространится на сущность, если правила не заданы для каждой сущности надо сделать нумерацию по-умолчанию.
Не усложнили ниразу, тригер пишется один, в него заворачиваем все ваши условия скопом, по справочникам и забываем.
Имя, сестра, имя даешь статью "как правильно сделать энумератор с заданными условиями". И посмотрим.
А что смотреть, тут по моему все ваши случаи описаны. Вы поймите, что заданные условия у всех разные, у меня сейчас структура сложнее и я в первую очередь думаю о том, чтобы не накосячил тот кто полезет в саму структуру БД.
Если выдадите списочком условия то вполне можно подумать, даже с плюсами и минусами подходов.
Если выдадите списочком условия то вполне можно подумать, даже с плюсами и минусами подходов.
И мы придем к выводу, что я прав насчет "задача сделать энумератор становится не такой простой, как кажется на первый взгляд"
Обычная рядовая задача. С моей точки зрения я ее решил 8 коментариев назад.
Зы вы кстати этой «отпиской» уклонились от ответа на сотальные доводы)
Зы вы кстати этой «отпиской» уклонились от ответа на сотальные доводы)
Наверное решили, я не проверял под нагрузкой. Осталось портировать на синтаксис 3-х других СУБД и вы молодец. А задача автоматически становится не такой уж простой.
Я не понял, щачем Вы сравнили реализацию в платформе с реализацией на sql. В платформе 1с нумераторы НЕ реализуются на sql, и вопросы с дырками там тоже есть, особенно при управляемых блокировках, потому и существует у нумератора опциональная настройка "заимствования" номера. Вопрос дырок скорее бизнес-вопрос, а не системный. Эта задача решается на уровне бизнес логики в любом языке, ничуть не хуже, чем это сделано а платформе, и даже лучше, т.к. иногда можно сделать в разы проще и производительнее. Я это делаю постоянно и без проблем, подключением нужного класса нумератора, если нужно. Кстати, очень редко нужно, везде хватает автоинкремента и составного представления номера.
Нет, не решил:
- after insert — это не тоже самое, что before commit. Между after insert и commit есть промежуток времени, в который может прилететь rollback.
- если используете честный before commit, то не можете в одной транзакции вставить связанные документы. Не знаю, правда, нужно ли это в контексте 1С и подобных систем.
Сиквенс вы можете использовать в разных таблицах.
Второй вариант:
Второй вариант:
create table documents(
document_id serial not null
)
create table orders(
order_specific field varchar
)
inherits documents
Прямо-таки запросто? Ну-ка ну-ка? Слабо оформить в виде туториала на Хабре или хотя бы основную идею здесь в каменте пояснить?
выше пояснил один из путей
Это отписка, а не путь решения. Вопрос был — сможете ли вы написать более развернутое решение/описание идеи в виде статьи, с возможностью критики сообществом Хабра. Попробуйте и увидите, что sequence не подойдет.
В виде статьи точно нет, у меня просто нет времени пока. А решение вон сверху, критикуйте
UPD я вообще очень плохо пишу абстрактные вещи, вот если бы полностью вы написали что и почему, тогда интересней)
Ну например я ничего плохого в дырках не вижу
UPD я вообще очень плохо пишу абстрактные вещи, вот если бы полностью вы написали что и почему, тогда интересней)
Ну например я ничего плохого в дырках не вижу
Ну например я ничего плохого в дырках не вижу
Вы как разработчик конечно не видите. Даже более, понимаете, что попытка их избежать приводит к понижению производительности. Но бизнес в ряде случае бывает другого мнения.
Ну например я ничего плохого в дырках не вижу
Не знаю, как сейчас, но несколько лет назад законодательство требовало, чтобы нумерация счетов-фактур была последовательной и без пропусков. А это уже из области внешних требований (на которые нельзя влиять).
Ну например я ничего плохого в дырках не вижу
Зато это хорошо видит налоговая, которая придет в компанию с вопросом, куда делить документы между номерами и почему их нет в декларации!
Внесу финальных пять копеек.
На технарям конечно кажется, что «ну чего страшного, ну дырка и дырка». Но взгляните на это с другой стороны. Бух. отчетность это кипы физической бумаги. И вот наша условная МарьВанна делает сверку листая бумажные доки смотря при этом на нумерацию: "1… 2… 4… Ой, 3 нет… это документ не распечатали? Потеряли? Сейчас поищем...". И начинаются раскопки в недрах учетной системы с целью понят, был ли вообще документ 3. При сквозной последовательной нумерации наличие дырки сразу говорит о том, что документ где-то продолбали без заглядывания в учетную систему.
На технарям конечно кажется, что «ну чего страшного, ну дырка и дырка». Но взгляните на это с другой стороны. Бух. отчетность это кипы физической бумаги. И вот наша условная МарьВанна делает сверку листая бумажные доки смотря при этом на нумерацию: "1… 2… 4… Ой, 3 нет… это документ не распечатали? Потеряли? Сейчас поищем...". И начинаются раскопки в недрах учетной системы с целью понят, был ли вообще документ 3. При сквозной последовательной нумерации наличие дырки сразу говорит о том, что документ где-то продолбали без заглядывания в учетную систему.
Я уже более сотни раз ловил на вещах типо привязки обработки пользователей к их расположению в дереве.
Речь видимо о том, когда группа пользователей (ветка в вашей терминологии), в которую входит пользователь, выполняет конкретные функции? Скажем, стоит поместить пользователя в группу «Бухгалтера» и он автоматически получает доступ к финансовым документам.
К минусам можно отнести недостаточно гибкую настройку (которая при этом вполне себе может быть реализована дополнительно).
К плюсам — явность, очевидность использования для рядового пользователя, который точно не забудет поставить нужные галочки прав для нового сотрудника.
Вывод: вполне разумное решение для небольшого предприятия без выделенного сисадмина.
Нет, речь не о группе, а о папочке в которой в данный момент находится пользователь.
Если есть отдельный справочник, в котором расписано соответствие «папочки» свойствам пользователя — то почему нет? Это нормально и хорошо. Плохо когда оно (имя элемента) действительно захардкожено.
Пользователь находиться в группе «продажники», потом бух берет его и тащит в папку «уволенные», ибо список уже запредельный, отчет делает «кряк», и никто не в курсе, потому что документации нету от слова совсем.
и никто не в курсе, потому что документации нету от слова совсем.
Все денег стоит.
Хорошее документирование — существенно поднимает стоимость разработки и снижает скорость. А в бизнесе крайне важно «сделать еще вчера».
Иногда выгоднее полагаться на память разработчика, если он постоянный; на комментарии в отчете; или просто лишний раз попросить разработчика слазить в код проверить.
А иногда и талмуд с документацией (там другая проблема — и как в ней найти нужное в подробнейшей документации).
Универсального на все случаи идеального варианта решения нет.
Нуда, куда веселее, когда перетянул пользователя в другую папочку и у тебя отчеты раком встали.
Нуда, куда веселее, когда перетянул пользователя в другую папочку и у тебя отчеты раком встали.
Проблема высосана из пальца.
Если информирование разработчиков о косяках поставлено нормально, то максимум после второй такой ситуации перетягивание будет запрещено программно или сопровождаться комментариями, к чему это приводит, чтобы пользователь сам решал.
Ну а то что Вы никогда не косячите, я уже понял.
Впрочем, в это не верю.
и? на что 1с в бухгалтерии заменить предлагается?
В 1С качественная изоляция прикладного кода от слоя работы с БД. Там нельзя типизировать таблицы на низком уровне и косяки малокомпетентных джуниоров на уровне БД там невозможны.
Так ето и беда 1С для средних и крупных баз.
Использование БД как хранилища таблиц, не учитивая возможности БД катие как партиции форенкеи, тригери и тд. Сколько костилей из за етого.
Работа с БД для меня одина из наиболее слабых сторон в 1С
Партиции-то почему нельзя использовать? Секционирование — сколько угодно. Отсутствие хранимок обусловлено необходимостью поддержки 5 разных движков СУБД (включая файловый), это понятное ограничение, может хорошее, может плохое, но понятное. то же с триггерами. А уж про форейнкеи я вообще помолчу. Только ленивый не говорил, что это довольно спорное изобретение при всех кажущихся плюсах.
FK спорен? Это в каком смысле? Нормальная РСУБД решает вопрос консистентности данных на своем уровне и не приходится тащить эту логику в рантайм приложения. Какие тут могут быть сомнения в полезности данного механизма?
Лень искать критику FK, думаю вы сможете ее найти. Общий смысл — FK нужны там где они нужны, а не просто "везде, где есть связи".
Ну тогда оно ни сколько не спорное при использовании там, где они нужны.
Ну вот в кейсах применения 1С — не нужны. Вернее не так, минусы от их использования перевешивают плюсы.
И какие минуса (отсуствие битих ссилок)?
А с партиции 1с не поддерживает, ви их создаете на уровне БД, что кстати запрещено лицензионним соглашением. Ну и они чудно пропадут при перестроении.
А с партиции 1с не поддерживает, ви их создаете на уровне БД, что кстати запрещено лицензионним соглашением. Ну и они чудно пропадут при перестроении.
У вас кнопка ы поломалась )
Минусы, если не ошибаюсь, были описаны в одной из статей Сергея Нуралиева о том, почему в 1С нет FK. Эти доводы весьма объективны, можно поискать статью.
А так — да, иногда битые ссылки это не плохо, а наоборот — хорошо. Вопрос компромисса между бизнес-кейсами и минимально-достаточной непротиворечивости данных. Еще можно вспомнить такие вещи, как шардинг, например. Это не в 1С, но в таких системах FK тоже часто лишний груз.
Вот и главное. Для меня даные в БД должны быть достоверными, а не с формолировкой
По поводу FK — они берут на себе огромную часть БЛ. Имеют оверхед в виде необходимости индексов.
Ну и поверхносное гугление статью не дало.
Ну а поддержка многих баз — ето лиш говорит о том что 1С нормально не поддерживае ни одну.
А и да «ы» у меня нет. пользуюсь буфером обмена :)
минимально-достаточной непротиворечивости данных. Да и выбор в етом 1С мне не дал.
По поводу FK — они берут на себе огромную часть БЛ. Имеют оверхед в виде необходимости индексов.
Ну и поверхносное гугление статью не дало.
Ну а поддержка многих баз — ето лиш говорит о том что 1С нормально не поддерживае ни одну.
А и да «ы» у меня нет. пользуюсь буфером обмена :)
Пишите лучше сразу на украинском. Мы всяко поймем, и это будет удобнее чем царапание мозга при чтении встреченных несуществующих слов.
Вы бы не могли, для разнообразия, отвечать по существу?
Все равно что человек заявляет, я бы с удовольствием услышал другую точку зрения. Вы говорите FK не нужны? ок, можно аргументы? Без посылов в гугл
Про партиционирование сейчас из каждого утюга, но по сути 99% фирм оно нафиг не сдалось.
Про партиционирование сейчас из каждого утюга, но по сути 99% фирм оно нафиг не сдалось.
Вы говорите FK не нужны? ок, можно аргументы?
Да запросто.
С голыми FK не столь гибко получается.
В 1С есть несколько способов перехвата записи/удаления объекта — выбирай удобный.
Там можно куда как более извращенную бизнес-логику реализовать. Что полезно при этом: в момент этой проверки вы имеет доступ ко всей прикладной сути.
В терминах СУБД этот функционал называется trigger.
P.S.:
В каком-то виде FK в 1С имеются, кстати.
Не скажу на уровне СУБД или на уровне движка платформы — не проверял/или проверял давно и не помню.
Но вы далеко не во всех случаях можете удалить объект из БД, если он где-то еще используется.
Другой довод против FK — зависимость от той или иной нормализации. А нормализация влияет на производительность и на удобство. То есть опять таки малая гибкость. Чтобы сделать FK нам нужно заточиться на определенную структуру.
Что вступает в противоречие с концепциями 1С: быстрая разработка, удобство, оперативные изменения под постоянно изменяющиеся бизнес-процессы.
Когда вы делаете отдельную таблицу только, чтобы включить FK, а для иного дела таблица и не нужна — это не гуд.
FK безусловно хорошо себя показывает только в сравнительно простой бизнес-логике. Но по мере усложнения — уже не все так однозначно.
С голыми FK не столь гибко получается.
Не столь гибко что? Неконсистентные записи создавать? Ну это да, бедаа…
В терминах СУБД этот функционал называется trigger.
всю жизнь мечтал осуществлять контроль целостности ручками)
Не скажу на уровне СУБД или на уровне движка платформы
На уровне движка, с бд 1с обращается как с тупой хранилкой.
всю жизнь мечтал осуществлять контроль целостности ручками)
Видимо, вы только начинаете карьеру и еще не сталкивались с сколько нибудь сложными бизнес-процессами, когда без этого никуда.
На уровне движка, с бд 1с обращается как с тупой хранилкой.
И это правильно.
Позволяет реализовать крайне гибкие бизнес-процессы, которые контролировать одними только средствами СУБД или невозможно или гораздо более трудоемко.
Видимо, вы только начинаете карьеру и еще не сталкивались
Если вы архитектуреные споры переводите на личности то вам пора заканчивать с карьерой.
с сколько нибудь сложными бизнес-процессами, когда без этого никуда.
Пример в студию.
когда без этого никуда
Нуда, а вы видимо никогда не видели развивающийся годами продукт, где этим никуда обмазано все сверху донизу в таком объеме, что даже тронуть страшно, а нужно.
Поглядите код модулей регистров в 1С в типовых, к примеру. Реализовать подобные необходимые для решения бизнес задач вещи на голых FK? Вы быстро начнете объяснять что это не нужно, невозможно, что эти идиотские бизнес-процессы и пр.
Но бизнесу это надо и подобные отмазки, что вы не можете это сделать — просто заставят вас уволить. И на 1С это легко решается.
Вы и сами привели такой пример:
Вот именно поэтому это и плохое решение.
Вариант предлагаемый 1С гораздо удобнее в модернизации при отличной гибкости.
Ага. Сложность на голых FK разрастается крайне радикальными темпами.
Но бизнесу это надо и подобные отмазки, что вы не можете это сделать — просто заставят вас уволить. И на 1С это легко решается.
Пример в студию.
Вы и сами привели такой пример:
Нуда, а вы видимо никогда не видели развивающийся годами продукт, где этим никуда обмазано все сверху донизу в таком объеме, что даже тронуть страшно, а нужно.
Вот именно поэтому это и плохое решение.
Вариант предлагаемый 1С гораздо удобнее в модернизации при отличной гибкости.
даже тронуть страшно
Ага. Сложность на голых FK разрастается крайне радикальными темпами.
Поглядите код модулей регистров в 1С в типовых,
точнее, каких? там все примитивно.
Вот именно поэтому это и плохое решение.
Это как раз ручные проверки целостности данных.
Ага. Сложность на голых FK разрастается крайне радикальными темпами.
Что такое голых? А есть одетые? И с чего бы вдруг им разрастаться? Ну конкретно, пример, один.
точнее, каких? там все примитивно.
Разумеется, должно быть просто по возможности.
Тот кто усложняет код безосновательно — попросту плохой программист.
Поглядите те из них, где бизнес-логика посложнее, где кода побольше.
Что такое голых? А есть одетые? И с чего бы вдруг им разрастаться?
«Одетые» — это те, что аналоги решения 1С, trigger, где можно куда как больше фантазии реализовать.
«Голые» — это только foreign key
И с чего бы вдруг им разрастаться?
Вы же сами написали:
обмазано все сверху донизу в таком объеме, что даже тронуть страшно, а нужно.
Вам виднее, где это.
Это как раз ручные проверки целостности данных.
Ну конкретно, пример, один.
Я уже дал вам отсылку — см. модули регистров. Возьмите тот, что побольше.
И представьте что вы это реализуется только через FK.
«Там есть сложные штуки, но где — не скажу», классный разговор.
Если у вас нет доступа к конфигурации 1С — любой пример вам ничего не даст. Бизнес логика все же вещь такая, что её нужно смотреть в комплексе, чтобы понять.
Если есть доступ к типовой конфурации — просто поглядите.
Если вы действительно понимаете о чем речь — там и искать ничего не нужно.
Сразу заходите в модули регистров и просто смотрите.
Я уже дал вам отсылку — см. модули регистров. Возьмите тот, что побольше.
Офигенная ссылка, может в ленинскую библиотеку сразу?
И представьте что вы это реализуется только через FK.
Делал
Если у вас нет доступа к конфигурации 1С
Во первых есть во вторых я итак помню половину ее структуры.
Сразу заходите в модули регистров и просто смотрите.
Смотрю, не вижу ничего сверхъестественного.
Офигенная ссылка, может в ленинскую библиотеку сразу?
Для того, что понимает тот аспект, что мы тут с вами обсуждаем — ссылка вполне конкретная.
Модуль именно что регистра.
В типовой конфигурации.
Той что у вас под рукой.
Это вполне конкретное место.
И представьте что вы это реализуется только через FK.
Делал
Что с того? Строго говоря, можно и на ассемблере операционную систему написать. Но какими усилиями и куда за это время ушли конкуренты.
Вы же и сам прокомментировали ситуацию так:
Нуда, а вы видимо никогда не видели развивающийся годами продукт, где этим никуда обмазано все сверху донизу в таком объеме, что даже тронуть страшно, а нужно.
Так вот в варианте предлагаемом 1С — не страшно.
Даже с вычурной бизнес-логикой.
Смотрю, не вижу ничего сверхъестественного.
Именно!
Потому что в варианте предлагаемом 1С это выглядит удобно для программиста.
Код и не должен быть замороченным — такой код пишет плохой программист. Код хорошего программиста должен быть понятным со стороны.
Для того, что понимает тот аспект, что мы тут с вами обсуждаем — ссылка вполне конкретная.
Нет не конкретная, потому что регистры — примитивные структуры данных.
И представьте что вы это реализуется только через FK.
И ничего страшного. Аргументов от вас как небыло так и нет
И вы сами прокомментировали ситуацию так:
Этот коммент относился к контролю целостности в ручном режиме, и выше это уже указано, дважды.
Даже с вычурной бизнес-логикой.
Пример «вычурной» бизнес логики я тоже так и не увижу?
Конечно. Потому что в варианте предлагаемом 1С это выглядит удобно для программиста.
А в каком варианте это неудобно? Когда база контролирует это дело? Вы как видите внешние ключи сразу потом обливаться начинаете?
ЗЫ я понял, для меня спор — способ получить новые знания. Для вас — место где нужно перекричать оппонента и доказать правоту. Аргументы и примеры в студию пожалуйста или позвольте мне откланяться.
Распределённые базы попроектируйте. Как раз до этого момента многие в FK верят. :)
Например при распределенной БД (мега фича 1с, которой нигде больше не видел) можно сделать узел на складе, в который будут прилетать только складские ордера, и вместо документов оснований для них — будут битые ссылки. При этом сама база узла будет работать на десктопного уровня компьютере и размером быть в единицы процентов от основной. Вообще эта технология позволяет вместо одного сервера на 2000+ сотрудников по стране сделать 10-100 серверов по филиалам и суммарно нехило сэкономить на железе. Да и в надежности тоже. Те же каналы связи в каком-нибудь Сыктывкаре часто оставляют желать лучшего. А в случае поломке на месте можно пустить (временно) в базу на уровень выше по иерархии и отпочковать клон нужного узла после починки сервера на месте.
1. Вы про индексы?
2. Тогда нужно продолжать мысль. И запилили свой контроль целостности и добавили к нему «проверку структуры дб», «исправление структуры бд» или просто на консистентность данных им плевать.
1с отказывается от контроля целостности не изза «цены». Ключи являются ценой использования их абстракции.
2. Тогда нужно продолжать мысль. И запилили свой контроль целостности и добавили к нему «проверку структуры дб», «исправление структуры бд» или просто на консистентность данных им плевать.
1с отказывается от контроля целостности не изза «цены». Ключи являются ценой использования их абстракции.
А кто по вашему претендует на место №2 или является таковым?
Тремя руками голосую за ту часть, которая касается развития языка (то что надо и что не надо). Умри Денис, лучше не предложишь!
А можно более подробно, что плохого в ООП в бизнес-приложениях?
Например, вот логика. Есть класс Контрагент. Документы вроде Счет должны ссылаться на Контрагент. От него наследуется Физическое лицо и Организация. У первого есть свойства Имя, Отчество и Фамилия, а у Организация — Форма собственности, ИНН, ОКПО и т.д.
Альтернатива этому без ООП — просто закинуть все свойства в Контрагент и показывать и использовать их в зависимости от какого-то boolean (или типа). Но это тоже самое, что говорить, что зачем нужен полиморфизм, если все можно сделать на if'ах.
Например, вот логика. Есть класс Контрагент. Документы вроде Счет должны ссылаться на Контрагент. От него наследуется Физическое лицо и Организация. У первого есть свойства Имя, Отчество и Фамилия, а у Организация — Форма собственности, ИНН, ОКПО и т.д.
Альтернатива этому без ООП — просто закинуть все свойства в Контрагент и показывать и использовать их в зависимости от какого-то boolean (или типа). Но это тоже самое, что говорить, что зачем нужен полиморфизм, если все можно сделать на if'ах.
Почему если говорят про ооп в бизнес приложениях так любят бизнес домен вспоминать? Причем почему то обязательно про наследование. ООП оно же чисто для служебного кода основные плюшки дает. DI, композиция объектов с поведением, повышенное удобство переиспользования и прочее. И вот для бизнес логики его не хватает. А бизнес сущности — уж фиг с ними, раз так большинство желает.
В 1с можно наследоваться от базовых классов, в данном примере Организация, Контрагент и ФищЛицо это классы унаследованные от базового класса Справочник. Или проще — это справочники.
В каких случаях для какого решения надо от каких классов базовых наследоваться можно почитать в стандарте:
https://its.1c.ru/db/v8std#content:683:hdoc
В общем случае наследование в бизнес сущностях это зло в любом языке. Наследование применяется хорошо на всяких технических абстракциях, а в 1С это все на себя взяла платформа и разработчикам конфигураций предоставляется удобный инструмент составления композиций классов не загружая разработчиков наследованием.
Организация, Контрагент и ФищЛицо это классы унаследованные от базового класса Справочник
Вы не поняли логики. ФизЛицо наследуется от Контрагент, так как ФизЛицо является Контрагентом, также как и Организация. Это не 3 разных сущности.
Такое наследование потом в базу складывать — то еще удовольствие. И всякие костыли в ORM-фреймворках типа EF, которые авторы усложняют и закостыливают ради обеспечения гибкого наследования в языке. 1С же наоборот — отказалась от наследования ради снижения сложности и повышения адекватности ORM.
За отображение этой логики на базу данных должна отвечать платформа. Разработчику должно быть все равно какие запросы при этом генерируются, ведь он же работает не с базой данных, а с логикой платформы.
Все зависит от конкретной платформы. Где-то наследование может быть сделано костылями, а где-то — нет.
И всякие костыли в ORM-фреймворках типа EF
Все зависит от конкретной платформы. Где-то наследование может быть сделано костылями, а где-то — нет.
Я хорошо знаю Entity Framework. Там это костыли. Но я сильно, очень сильно сомневаюсь, что ближайший конкурент hibernate сделал как-то иначе и лучше.
Разработчику должно быть все равно какие запросы при этом генерируются
это прекрасно. Да, разработчику, как правило и все равно. А потом сервера ложатся под нагрузкой. И EF-Core генерирует гораздо более говенные запросы, чем тот же 1С. И да, что в 1С, что в .NET рядовой разработчик даже не задумывается над тем, что пойдет в СУБД.
Однако, мой опыт (безусловно субъективный) показывает, что 1С-ники гораздо сильнее заморачиваются с оптимизацией запросов, чем их коллеги из мира .net
Если в EF сделали плохую оптимизацию запросов, то это не значит, что во всех платформах и ORM кривые запросы. А в том же 1С автоматически даже не делается JPPD, и его надо делать вручную 1С-разработчику.
Я не говорил, что во всех плохо. Расскажите, в какой это делается хорошо?
В lsFusion, например, мы очень много времени и сил потратили на то, чтобы оптимизировать все запросы под выполнение их СУБД (пока только в PostgreSQL). Автоматическая поддержка JPPD — это самая простая из оптимизаций.
lsFusion это не ORM общего назначения, уж простите. Допускаю, что там что-то оптимизировано, но, без обид, я смотрел вашу демку. Впечатляет ровно никак. Я буду рад, если у вас получится, конкуренция это хорошо, это путь к развитию.
Согласен. ORM еще нужно устранять «семантический разрыв» между универсальным языком общего назначения и реляционной базой данных. Поэтому там, в любом случае, прозрачную оптимизацию сделать не получится (разработчику всегда нужно будет понимать, что он делает, и как это отражается на базе данных).
Но основное мое утверждение то касалось не ORM. А того, что ООП в бизнес-приложениях (именно в высокоуровневых платформах) можно и нужно использовать.
Но основное мое утверждение то касалось не ORM. А того, что ООП в бизнес-приложениях (именно в высокоуровневых платформах) можно и нужно использовать.
lsFusion это очень странная штука:
попытки пиара за счет 1С, при чем не очень красивые, которые скорее вызывают негатив к продукту lsFusion чем к 1С, попытки реализовать непонятно что и непонятно для кого используя при этом то, что другие не используют, потому что это не нужно, в lsFusion преподносится как маст хэв.
Лично у меня встреча в тексте lsFusion ассоциируется с тем, что скоро будет вброс какой-то ненужной бесполезной хрени.
Это вы ультиму erp пропустили.
Да ладно, отличная ж была система. Жаль не сохранились статьи про «слабосильные 1С и SAP» — согревали кресло холодными зимними вечерами.
Но зато на их новом сайте diaspar.business можно в буллшит-бинго играть, например.
Но зато на их новом сайте diaspar.business можно в буллшит-бинго играть, например.
Лично у меня встреча в тексте lsFusion ассоциируется с тем, что скоро будет вброс какой-то ненужной бесполезной хрени.
И как правило, так и происходит, бгггг
Понимаете, нужно/не нужно — относительное понятие. Если Вы считаете, что ООП в бизнес-приложениях не нужно, то это Ваше право. Но у других людей может быть другая точка зрения.
Я бы сказал не «негатив к продукту», а «негатив к команде».
В 1с в качестве реквизита можно указать т.н. составной тип, т.е. либо то, либо другое, либо хоть черт лысый (список типов накликивается мышкой). В интерфейсе автоматом реализован выбор — сначала выбирается тип сущности, затем сама сущность. Ну, либо некоторые этапы могут программно пропускаться. В типовых же раньше было так: Справочник контрагентов, в нем ссылка на юр/физ лицо. Такой себе депенденси инжекшен.
На самом деле нет, физ лицо не является контрагентом, физлицом называют сущность, которая описывает реального человека. Например это может быть водитель или сотрудник или курьер.
Организацией называют собственную организацию, потому что обычно в базе ведут учет несколько компаний и совершают межфирменные продажи — интеркомпани.
То, что вы имеете ввиду: определение типа контрагента решается добавлением реквизита перечисления: ЮрЛицо, ФизЛицо, ИП, НеРезидент. С точки зрения бизнеса людей пришедших брать за нал надо отделять от тех, кто имеет ИП и ставит подпись с печатью. Так же как не резиденты юридические оформляют сделки иначе чем простые ооошки.
Действительно в контрагент добавляются некоторые реквизиты которые не используются для некоторых типов в зависимости от значения реквизита типа. Обычно это не представляет проблем, потому что просто скрывают их с формы и добавляют правило проверки значений реквизитов иное. Например ИНН для ЮрЛица — 10 символов, для ИП — 12 символов, а у физ лица его может вообще не быть.
Очень дельный дельный разбор. Спасибо большое
Идентификаторы записей в БД. 1С приняла волевое решение — все идентификаторы ссылок абсолютно синтетические и всё тут. И нет проблем с распределенными базами и обменами.
Производительность и место таблиц и индексов. Разве нет?
Одно дело, когда ключами являются LONG (как в lsFusion), другое дело, когда, например, 32-байтные строки. Понятно, что JOIN'ы по LONG'ам будут гораздо быстрее и потреблять меньше памяти, чем по 32-байтной строке.
стоп-стоп, чейта UUID вдруг стал 32-БАЙТНОЙ строкой? В LsFusion, раз уж вы упомянули, авторы заранее заложили сложность создания распределенных баз данных и обменов между системами. Да, памяти меньше. Если критерием оптимизации является память — long хорошее решение. Если критерием оптимизации является стоимость реализации бизнес-кейса — long ужасное решение.
Если ваше решение доживет до необходимости запуска распределенных обменов на нем — вас ждет сюрприз.
Я же написал: «например». Преимущества long, что это тип, который нативный для процессора и лучше всего обрабатывается на низком уровне. Понятно, что UUID занимает всего в 2 раза больше, но архитектура процессора 64-битная пока-что.
В современном мире необходимости распределенных баз уже значительно меньше. У нас есть клиент на 570 магазинов в деревнях и селах и даже там, нет проблема с интернетом. Но, в целом, сделать UUID вместо LONG — достаточно несложно.
Если ваше решение доживет до необходимости запуска распределенных обменов на нем — вас ждет сюрприз.
В современном мире необходимости распределенных баз уже значительно меньше. У нас есть клиент на 570 магазинов в деревнях и селах и даже там, нет проблема с интернетом. Но, в целом, сделать UUID вместо LONG — достаточно несложно.
1с идентификаторы это не UUID это поля типа bytea, где в hex живет одинэсовский айди с перестановками.
А сколько он занимает? И получается, что в запросах идет JOIN по bytea?
[_IDRRef] [binary](16)
4 байта плюс 32 шестнадцатеричных символа. Два шестнадцатеричных символа на байт, итого 20 (наврал вначале, забыл что там два на байт)
Да джоин идет по нему, плюс ко многим ключам есть еще 2 поля с указанием на тип таблицы и ее id.
Да джоин идет по нему, плюс ко многим ключам есть еще 2 поля с указанием на тип таблицы и ее id.
Это вы как так лихо посчитали?
Хм, если это так, то это действительно сильная потеря производительности. Наверное, стоило бы автору указать в статье и недостатки такого подхода.
Разница в производительности на выборках и джойнах ключа 8 байт (long) и 16-байтного binary настолько мала на общем фоне, что это точно можно не учитывать. Так-то посмотреть и строки в однобайтных кодировках меньше занимают. И binary collation быстрее. И тот же RCSI гораздо дороже для отдельных запросов, но его точно надо включать в MS SQL.
Друзья и коллеги, в последнее время на Хабре участились статьи с хейтом в адрес 1С...
Можно хотя бы пару ссылок для примера?
Вот, например, статья от открытой и бесплатной альтернативы: Почему не 1С
Негусто для «в последнее время участились». Хейтом, кстати, та статья не является — это разбор некоторых проблем 1С с подробной технической аргументацией.
Дело в том, что даже конструктивную критику иногда воспринимают, как просто «хейт». Но это в больше степени касается 1С. Статью Почему не SQL почему-то никто не начал называть «хейтом SQL»…
Возможность сразу писать бизнес логику да еще и на родном языке это просто мечта, 1С отличный российский продукт.
Зачем вообще finally? Если посмотреть на поток выполнения программы, от него ни жарко ни холодно (особенно когда нет типа перехватываемого исключения):
Скрытый текст
Изначально — для контроля ресурсов. Потом там много интересного навертели, особенно в части логирования и трассировки.
finally обычно используют для зачистки. Если пользовали какой-то ресурс, который надо освободить независимо от того было исключение или не было.
И чем это отличается освобождением ресурсов после КонецПопытки? А уж сколько шишек набито из-за ТранзакцияАктивна — не пересчитать. Больше, наверное, только с НПП в преставлениях чисел.
Тем, что за "КонецПопытки" в случае исключения не всегда надо заходить. А коли так — то надо писать освобождение ресурсов 2 раза — внутри Попытки и внутри Исключения. Странно, что вы до сих пор с этим не столкнулись, будучи 1С-ником.
<troll-mode>возможно вы не паритесь из-за не освобожденных ресурсов</troll-mode>
А зачем за него не заходить? Пишите освобождение ресурсов один раз — после КонецПопытки и с высокой долей вероятности в него попадете. См. картинку в исходном комментарии.
Хм… мне сложно это прокомментировать. Вы точно программист?
Я просто не пойму чем принципиально отличаются картинки в исходном комментарии, учитывая, что в любой квадратик можно закинуть любое количество строк кода. Мы же про логический (да и не только) поток выполнения программы говорим. Если картинка с finally должна быть другой, то нарисуйте (почему на вы? столько раз общались на ISevent и та ты) нужную. Быстро можно прям онлайн plantuml.com, исходный вариант моей картинки:
мануал тут: plantuml.com/ru/activity-diagram-beta
Скрытый текст
@startuml
start
:Программа;
if (Попытка) then (Исключение)
:Обработка исключения;
endif
:Программа;
stop
start
:Программа;
if (Попытка) then (Исключение)
:Обработка исключения;
endif
:Finally;
:Программа;
stop
@endumlмануал тут: plantuml.com/ru/activity-diagram-beta
Что будет если «Обработка исключения» тоже бросит исключение? А что делать если я в «Обработка исключения» просто хочу залоггировать исключение и пробросить его выше по стеку?
>Что будет если «Обработка исключения» тоже бросит исключение?
будет необработанное исключение
>А что делать если я в «Обработка исключения» просто хочу залоггировать исключение и пробросить его выше по стеку?
в Исключение надо залогировать ошибку и вызвать оператор ВызватьИсключение. Если без параметров — то прокинется исходное исключение, если с параметром — то будет исключение с текстом, который мы передадим.
Это не относится к обсуждению, нужен ли finally в 1с и вообще. Это относится к языку 1с.
будет необработанное исключение
>А что делать если я в «Обработка исключения» просто хочу залоггировать исключение и пробросить его выше по стеку?
в Исключение надо залогировать ошибку и вызвать оператор ВызватьИсключение. Если без параметров — то прокинется исходное исключение, если с параметром — то будет исключение с текстом, который мы передадим.
Это не относится к обсуждению, нужен ли finally в 1с и вообще. Это относится к языку 1с.
будет необработанное исключение
Которое вполне может быть обработано кодом выше по стеку (и это нормально). Только вот без finally код после блока не выполнится, и вы можете легко получить неосвобожденный ресурс.
в Исключение надо залогировать ошибку и вызвать оператор ВызватьИсключение. Если без параметров — то прокинется исходное исключение, если с параметром — то будет исключение с текстом, который мы передадим.
И если я например хочу освободить какую-нибудь блокировку при выходе из функции, то мне надо это освобождение написать в нескольких местах и следить за тем, чтобы случайно ее не забыть?
Ну тут можно долго спорить. В 1с, например, есть вложенные попытки исключения. Да и вообще обойти без finally практически любой случай можно (а то продолжая вопросы можно задать вопрос: а если в finally будет исключение, то что...). Отсутствие finally меня беспокоит намного меньше отсутствия async/await или хотя бы анонимных функций.
И чем это отличается освобождением ресурсов после КонецПопытки?
Тем, что мы хотим вернуть результат сразу, как мы его получили.
var q = new SomeResource()
try
return q.Process()
finally
q.Dispose()(да, я знаю, что using читаемее, но внутри using тот же finally)
1С с Oracle не складывается. совсем, никак, вообще. Бились-бились, и оставили эхпорт XML через api-сервисы с одной и другой стороны. Иначе, увы, никак это не сложить.
Костыли, но работают.
Мне в 1С не нравится только то, что она заточена исключительно под СНГ, если у вас бизнес с замашкой на международный, то 1С тут не подходит. Ну и мои личные заморочки, так как в предыдущей компании все бизнес процессы были построены вокруг самописной SQL DB? и webapp вокруг нее. А с 1С я как бизнес-аналитик столкнулась не так давно и после простой самописной SQL+JAVA + C# — 1C сервер это гребаный черный ящик, в который и заглянуть то страшно, хотя бизнес-процессы ни разу не сложнее.
Грамотный 1С разработчик может из коробки сваять что угодно, от CRM до полноценного бекэнда web app с фин-потоками через него. но хороших разрабов в этой сфере мало, на питоне процент хороших разработчиков повыше будет.
Костыли, но работают.
Мне в 1С не нравится только то, что она заточена исключительно под СНГ, если у вас бизнес с замашкой на международный, то 1С тут не подходит. Ну и мои личные заморочки, так как в предыдущей компании все бизнес процессы были построены вокруг самописной SQL DB? и webapp вокруг нее. А с 1С я как бизнес-аналитик столкнулась не так давно и после простой самописной SQL+JAVA + C# — 1C сервер это гребаный черный ящик, в который и заглянуть то страшно, хотя бизнес-процессы ни разу не сложнее.
Грамотный 1С разработчик может из коробки сваять что угодно, от CRM до полноценного бекэнда web app с фин-потоками через него. но хороших разрабов в этой сфере мало, на питоне процент хороших разработчиков повыше будет.
Мне в 1С не нравится только то, что она заточена исключительно под СНГ, если у вас бизнес с замашкой на международный, то 1С тут не подходит.
Если вы про фреймворк "1С:Enterprise", то при чем тут какая-либо страна? Это же база данных+сервер+набор классов для складывания денежных сумм. Что хочешь, то и пиши. Конкретные приложения, написанные на этом фреймворке, с бизнес-логикой под СНГ — да, они для СНГ, но это же конкретные приложения, а не платформа. Их так писали специально.
Вот приложение не для СНГ, но на 1С, например: https://www.accountingsuite.com/
>А с 1С я как бизнес-аналитик столкнулась не так давно и после простой самописной SQL+JAVA + C#
В 1С несколько лет назад сделали очень удобный механизм внешних источников для работы как раз с «голыми» базами. При этом с таблицами из них можно совершенно бесшовно (так, что и не поймешь родная она 1Ски или внешняя) на клиенте работать со списками, формами, записью.
В 1С несколько лет назад сделали очень удобный механизм внешних источников для работы как раз с «голыми» базами. При этом с таблицами из них можно совершенно бесшовно (так, что и не поймешь родная она 1Ски или внешняя) на клиенте работать со списками, формами, записью.
перестроиться с голых баз, где вся архитектура простая, самописная и изучена вдоль и поперек на коробочную 1С не очень просто. Хотя аналогии с фреймворками шикарны.
В работе столкнулась с кейсами, что WS на 1С делают невозможной обновление конфигурации. Тут или WS и интеграция с голыми базами, или костыли из регламентыных заданий зато с возможность обновления продуктов. Для Бух и Зуп возможность быстрого обновления особенно важна.
В работе столкнулась с кейсами, что WS на 1С делают невозможной обновление конфигурации. Тут или WS и интеграция с голыми базами, или костыли из регламентыных заданий зато с возможность обновления продуктов. Для Бух и Зуп возможность быстрого обновления особенно важна.
Мне в 1С не нравится только то, что она заточена исключительно под СНГ, если у вас бизнес с замашкой на международный, то 1С тут не подходит
А вы говорите про а) какую-то конфигурацию или б) платформу без конфигурации?
Если б) — можете немного развернуть тезис? Почему не подходит?
1c продукт платный. И пришлось столкнуться с проблемой покупки лицензий на нужную конфигурацию в Израиле и его донастройкой. То есть там 1С по сути нужна только для учета и отчетности, SAP делает тоже самое, и его приобретение, настройка, обслуживание и интеграция с внешними источниками данных проще, за счет большого числа специалистов в регионе.
конфигурации не лицензируются, лицензируется сама 1С на количество юзеров. И вот где-где, но в Израиле-то должно быть довольно много бывших соотечественников. Среди них нет 1С-ников?
В смысле не лицензируются? А как же СЛК? Да и вообще что то не помню я конфигураций для которых лицензии не нужны.
СЛК это левая херня, по-моему deprecated давно. Хотя допускаю, что региональная конфа для Израиля могла быть и с отдельным ключом, встроенным разработчиками. Но это вопрос к авторам приложения, а не к платформе.
СЛК к типовым конфам от 1С — не применяется. СЛК — это партнерские конфигурации (включая совместные и т.д.).
Уточнения про партнерские не было. Да и тем не менее лицензии нужно покупать что на партнерские что на от 1с конфигурации.
Лицензии нужно покупать не на конфигурации, а на платформу.
Лицензирование очень простое:
1. лицензия на сервер (по количеству серверов)
2. лицензии на пользователей (по количеству одновременных пользователей)
[3. лицензии на конфигурации — СЛК и аналоги]
Другими словами, если вы используете ERP на 64-разрядном сервере, и в этой конфе работает 1050 пользователей, то вам надо купить:
1. 1 лицензию на 64-разрядный сервер
2. 1050 платформенных клиентских лицензий
Больше ничего.
Если используется партнерская конфигурация, там может потребоваться(!) купить еще сколько-то лицензий на саму конфигурацию, которые (конфигурации) тоже лицензируются по рабочим местам.
Платформенные лицензии, действительно, не зависят от того, что используется: хоть полностью собственная конфигурация, хоть полностью типовая.
Лицензирование очень простое:
1. лицензия на сервер (по количеству серверов)
2. лицензии на пользователей (по количеству одновременных пользователей)
[3. лицензии на конфигурации — СЛК и аналоги]
Другими словами, если вы используете ERP на 64-разрядном сервере, и в этой конфе работает 1050 пользователей, то вам надо купить:
1. 1 лицензию на 64-разрядный сервер
2. 1050 платформенных клиентских лицензий
Больше ничего.
Если используется партнерская конфигурация, там может потребоваться(!) купить еще сколько-то лицензий на саму конфигурацию, которые (конфигурации) тоже лицензируются по рабочим местам.
Платформенные лицензии, действительно, не зависят от того, что используется: хоть полностью собственная конфигурация, хоть полностью типовая.
N лицензий на сервер, если кластер отказоустойчивый, по-моему
А вот на этой страничке ни цены ли на лицензии конфигураций указаны? В т.ч. и от 1с.
если у вас бизнес с замашкой на международный, то 1С тут не подходит
К сожалению, после истории с nginx, экспансия 1С на международный рынок очень сильно осложнится. И это уже не будет связано с качеством самой платформы.
Интересно, как эти 2 истории у вас коррелируют? После истории с Касперским — возможно, но после nginx-то почему?
Потому что в РФ государству (в широком смысле) очень легко разушить бизнес. Нет нормальных сдержек (независимый суд, политическая конкуренция, институт репутации, наконец), как в странах наших западных партнеров.
Ситуация с ngnix модельная — захотелось кому-то прессануть коммерсов от ИТ в надежде отжать баблишка, например — наслали маскишоу с автоматами с обыском домой. Почему — а потому, что ничего серьезного в случае даже если дело не взлетит силовикам не будет. Это ж не Запад какой-нибудь, где б если такая история произошла, то было бы всестороннее рассмотрение дела — кто заказывал, кто принимал решение автоматчиков домой к программисту приводить, со встречными исками, с послед-ми потерями постов высоких чинов. А тут в лучшем случае (стучу по деревяшке, т.к. еще не факт) просто дело прикроют, мол, чуваки, обознались, сорян.
Ситуация с ngnix модельная — захотелось кому-то прессануть коммерсов от ИТ в надежде отжать баблишка, например — наслали маскишоу с автоматами с обыском домой. Почему — а потому, что ничего серьезного в случае даже если дело не взлетит силовикам не будет. Это ж не Запад какой-нибудь, где б если такая история произошла, то было бы всестороннее рассмотрение дела — кто заказывал, кто принимал решение автоматчиков домой к программисту приводить, со встречными исками, с послед-ми потерями постов высоких чинов. А тут в лучшем случае (стучу по деревяшке, т.к. еще не факт) просто дело прикроют, мол, чуваки, обознались, сорян.
Хорошо, но как это отвечает на мой вопрос и диалог о том, что 1С-у сложно будет выйти на международный рынок из-за истории в nginx.
Ну и да, представительства 1С и партнеров уже есть в Турции, Канаде, США, Германии, Испании и еще где-то. Это считается неким выходом на международный рынок?
Представьте, что вы средней руки компания, например, из Польши или Германии. И у вас есть нужда в автоматизации бизнеса. История эта обычно довольно мозгоемкая, а иногда и капиталоемкая. В любом случае вам хочется решения «всерьез и надолго». А в России вы знаете, что не очень стабильно все. Точнее так — то, что там стабильно (перекос в строну гос-ва), то не располагает к стабильности бизнесов, населяющих ее. Вот и подумаете вы, а стоит ли с ИТ-компанией из такой страны связываться.
Представьте, что вы средней руки компания, например, из Польши или Германии. И у вас есть нужда в автоматизации бизнеса. История эта обычно довольно мозгоемкая, а иногда и капиталоемкая. В любом случае вам хочется решения «всерьез и надолго». А в России вы знаете, что не очень стабильно все.
Разработка будет вестись местными партнерами.
От того, что головное подразделение, которое разаботкой платформы (типовые конфигурации из РФ не нужны за границей) занимается вдруг сменится собственник — вы даже не факт что заметите.
По крайней мере не средней руки, а довольно крупные торговые сети, при вхождении на рынок России, зачастую вполне себе адаптируют свои системы руками именно что местных подразделений.
На Хабре есть статьи сети стройматериалов из Франции, если не ошибаюсь.
Там процесс разработки расписан и доводы, почему поручили нашему подразделению (тому ИТ-подразделению сети французской, что в РФ). А потом им и Казахстан поручили. Просто потому что отдел сильный. Просто потому что им проще с казахстанцами разговаривать.
Нормальный бизнес взвешивает и потом принимает решения.
Бизнес, что принимает решения на основании только эмоциональных факторов, которые вы тут привели — не может быть успешным.
>От того, что головное подразделение, которое разаботкой платформы занимается вдруг сменится собственник — вы даже не факт что заметите
Это было бы правдой, если бы платформа была:
1. открытой, как какой-нибудь Хром
2. с большим международным (а не только русскоязычным) сообществом
>эмоциональных факторов, которые вы тут привели
Этот «эмоциональный», как вы метко выразились, фактор называется политический риск (https://en.wikipedia.org/wiki/Political_risk). В нашей стране он, к сожалению, выше чем в среднем по Европе, например. И истории типа ngnix'а его точно не уменьшают.
Это было бы правдой, если бы платформа была:
1. открытой, как какой-нибудь Хром
2. с большим международным (а не только русскоязычным) сообществом
>эмоциональных факторов, которые вы тут привели
Этот «эмоциональный», как вы метко выразились, фактор называется политический риск (https://en.wikipedia.org/wiki/Political_risk). В нашей стране он, к сожалению, выше чем в среднем по Европе, например. И истории типа ngnix'а его точно не уменьшают.
Это было бы правдой, если бы платформа была:
1. открытой, как какой-нибудь Хром
2. с большим международным (а не только русскоязычным) собществом
Вы привели не более чем эмоциональный аргумент.
Не рациональный.
В противном случае проприетарного софта давно бы не существовало как класса.
Нет.
Собственники регулярно сменяются.
Лично Вы даже не знаете этого, и лично продолжаете пользоваться теми же продуктами.
Новый собственники мечтает заполучить себе бизнес чтобы продолжить его эксплуатировать.
Тут возможны ньюансы, что новых собственник хуже разбирается в бизнеса и постепенно через много лет лет (бизнес-то крупный) сойдет на нет. А возможно, что и нет, ведь он не сам управляет, а ставит менеджера.
Возможны ньюансы, что изменится сам продукт постепенно и очередная версия вам не понравится. Но вам то что? У вас уже есть старая налаженная версия. А переход на новую все равно бы потребовал серьёзнейших работы по переработке кода.
Но в общем случае смена собственника не означает, что продукт прекращает свое существование.
Да и то, что собственник один и тот же — отнюдь не гарантирует, что ему не надоело, что он не потерял деловую хватку, что он не проводит 100% времени на Гавайах или Канарах, а его бизнес в это время постепенно отстает от конкурентов всё больше и больше.
> Собственники регулярно сменяются.
В ИТ это часто связано с послед-м закатом технологий, разработанных исходным собственником. Примеры:
DEC > Compaq > HP (где VAX? VMS? PDP?)
Sun Microsystems > Oracle (где SPARC?)
Sybase > SAP (где одноименная СУБД?)
>Новый собственники мечтает заполучить себе бизнес чтобы продолжить его эксплуатировать.
Ваша категоричность суждений умиляет :)
Это не всегда так. В мире ИТ есть много примеров, когда бизнес приобретался для
— убийства конкурента и включения его наработок в продукты покупателя
— покупки чисто его клиентской базы
В ИТ это часто связано с послед-м закатом технологий, разработанных исходным собственником. Примеры:
DEC > Compaq > HP (где VAX? VMS? PDP?)
Sun Microsystems > Oracle (где SPARC?)
Sybase > SAP (где одноименная СУБД?)
>Новый собственники мечтает заполучить себе бизнес чтобы продолжить его эксплуатировать.
Ваша категоричность суждений умиляет :)
Это не всегда так. В мире ИТ есть много примеров, когда бизнес приобретался для
— убийства конкурента и включения его наработок в продукты покупателя
— покупки чисто его клиентской базы
И истории типа ngnix'а его точно не уменьшают.
Давайте не будем банальный спор из-за 40 миллиардов рублей, который возник из-за неявно оформленной интеллектуальной собственности, не совсем чистое оформление которой Сысоев и не скрывал, считать политическим.
Это банальные разборки из-за денег.
В любом случае, если ты получил 40 миллиардов, то ты должен быть готов, что сейчас у тебя образуется огромное количество внебрачных детей; что к тебе начнут приставать самые разнообразные изобретатели вечных двигателей, нуждающиеся в инвестициях, что твоего ребенка похитят ради выкупа и к пр. неприятностям больших денег.
Не вижу ничего необычного, чтобы неявно оформленная интеллектуальная собственность не стала интересной тому, кто на таких же птичьих правах может на неё претендовать.
Ведь даже если суд присудит 10% от 40 миллиардов — это уже неплохо, это уже выгодно.
Но это не политические разборки. Это банальные разборки из-за больших денег между возможными владельцами интеллектуальных прав.
Проблемы в том что банальные разборки из за денег решаются людьми с автоматами задерживающими людей и изымающими технику.
Проблемы в том что банальные разборки из за денег решаются людьми с автоматами задерживающими людей и изымающими технику.
Государство разумеется участвует в разрешение споров между хозяйствующими субъектами, когда дело доходит до противостояния на таком уровне наклала стратей.
Или вы предполагает, что всё должно было ограничиться личными звонками Мамута Сысоеву? Чтобы Мамут канючил: «Игореша, ну отдай деньги». Так что ли?
Конечно, в данном конкретном случае смысл обысков непонятен. Что там хотели изъять с компьютеров? Исходники nginx, которые давным-давно уже по всему миру разбросаны?
Полагаю, что следователи, разумеется, не вникали в суть бизнеса nginx. И поступили ровно так же как и поступили бы с каким-нибудь торговым предприятиям — изъять документы поставщиков, покупателей и искать в них несоответствие по налогам, например. Но у nginx оказалось нечего изымать.
Следователи прочитали сумму иска и решили что следует не иначе как с маски-шоу приходить, ибо у человека с 40 миллиардами намного больше, чем у простого человека возможностей по тому как смыться. Понятно, что это типовое и нормальное решение в какой-то другой ситуации было бессмысленно в данной конкретной ситуации.
И, кстати, кто-нибудь может пояснить — а за что конкретно Сысоев со товарищами получили 40 миллиардов? За исходники nginx? За право нанимать Сысоева? Да каким бы крутым разработчиком он ни был — не стоит это право столько. nginx не настолько сложный софт.
«nginx+» и другие коммерческие продукты и да, команда. IBM вот ред хат за миллиарды долларов купил многие полагают только из за команды а не из за технологий.
Силовики может и поступили как привыкли, но тот кто принимал решение возбудить уголовное дело без доказательств (не верю что они есть у рамблера) он чем думал?
Силовики может и поступили как привыкли, но тот кто принимал решение возбудить уголовное дело без доказательств (не верю что они есть у рамблера) он чем думал?
Силовики может и поступили как привыкли, но тот кто принимал решение возбудить уголовное дело без доказательств (не верю что они есть у рамблера) он чем думал?
А почему тот человек должен думать об виновности Сысоева или невиновности?
Точку в этом деле должен ставить суд. И только суд.
Есть заявление.
Проводятся, направленные на сохранения улик. Если Сысоев злоумышленник, то запросто может и документы уничтожить.
Пусть даже Сысоев и не виноват, но априори, до суда, все равно меры по сохранению улик принять нужно.
А до решения суда следственные органы не знают злоумышленник ли Сысоев. Была бы у них машина времени — не делали бы лишней работы, узнав, что в будущем суд выиграет Сысоев.
(не верю что они есть у рамблера)
Еще раз:
Есть заявление.
Но решить существенны ли доказательства или нет — может только суд.
Что думаете вы — неважно.
А почему тот человек должен думать об виновности Сысоева или невиновности?
Точку в этом деле должен ставить суд. И только суд.
Есть заявление.
Ага, а по заявлению от меня в офис рамблера тоже маски шоу прискачут?
Ага, а по заявлению от меня в офис рамблера тоже маски шоу прискачут?
Если вы можете позволить себе действительно квалифицированных юристов, которые знают как это оформить правильно.
Мы многое не знаем в той сфере, просто мы не специалисты в тех областях. Вот нам и кажется, что это неествественно быстро.
Я как-то интересовался у юриста — приостановить сделку по квартире, заблокировать счета и т.п. вещи можно и простому человеку сделать почти мгновенно (ну день-два), если знать как это оформить.
Другое дело — последствия.
Во встречном иске убытки от приостановления деятельности Рамблера повешают на вас, если ваши доказательства окажутся не доказательствами.
Оно вам надо?
Конкретно в данном случае Мамут не так то и рискует. Иск то от ошфора, на котором, поди и нет никакого имущества. Захочет ли Сысоев дать сдачи по взрослому, судиться, пройти по цепочке до реального владельца ошфора?
Зачем это нужно Сысоеву при наличие 40 миллиардов? Тут Мамут ничем и не рискует. Сумма полученной Сысоевым компенсации будет смешной в масштабах 40 миллиардов.
Это вам будет не смешно, потому как убытки Рамблера и ваша зарплата несопоставимы.
Но, впрочем, все возможно.
Мне тот же юрист рассказывал что существуют профессиональные сутяжники. Даже приводил конкретный пример такового, с кем он лично сталкивался.
Человек живет тем, что постоянно и непрерывно судится из-за всякой ерунды. Например, с ЖКЖ. Типа температура горячей воды на 1 градус меньше нормы. Отдельный судебный иск за каждый день такой температуры.
И, должен вам сказать, очень даже неплохо живет этот профессиональный вымогатель, по сути. Хоть он и использует законные методы и судебную систему.
Скажем так, автомобиль у него не из дешевых.
При желании вы тоже можете засудить Рамблер, Яндекс, Гугль. Если правильно подойдете к искам, глядишь, они от вас откупятся кругленькой суммой. Только чтобы вы не тратили драгоценное время их юристов на микроиски, например.
Полагаю, что следователи, разумеется, не вникали в суть бизнеса nginx. И поступили ровно так же как и поступили бы с каким-нибудь торговым предприятиям — изъять документы поставщиков, покупателей и искать в них несоответствие по налогам, например.
Это то и плохо. Рядовое хозяственное дело — и уголовный процессв особокрупном. Это не неуплата налогов, не контрабанда, просто одно юрлицо решило что другое неправо. И что? Это дает такое право делать силовые акции?
И, кстати, кто-нибудь может пояснить — а за что конкретно Сысоев со товарищами получили 40 миллиардов? За исходники nginx? За право нанимать Сысоева? Да каким бы крутым разработчиком он ни был — не стоит это право столько. nginx не настолько сложный софт.
Это столько стоит, раз это купили. Это единственное мерило.
Это то и плохо. Рядовое хозяственное дело — и уголовный процессв особокрупном. Это не неуплата налогов, не контрабанда, просто одно юрлицо решило что другое неправо. И что? Это дает такое право делать силовые акции?
Достаточно хорошо объясняющий комментарий из другой статьи на Хабре:
habr.com/en/news/t/480908/#comment_21029022
1. Т.е. основания есть. Достаточные или нет — другой вопрос, который должен решить суд.
2. Суду должно быть наплевать на мнение. Иначе — как раз беспредел и причина для возмущения.
3. Если есть дело, а оно есть, то должны проводится ОРМ, направленные в том числе на сохранение улик. Для это и нужны люди в форме. Не приятно, но увы иначе никак. Или думаете никто не прячет сервера, жёсткие диски и папки с документами? И да, неприятно и стрёмно, но жизнь есть жизнь. Собственно на такие случаи в крупных компаниях и есть юристы
> Да каким бы крутым разработчиком он ни был — не стоит это право столько. nginx не настолько сложный софт.
Извините, но это чушь. Или зависть (да, я тоже в каком-то смысле завидую Сысоеву — он молодец). Насчет сложный — наверное, уже нет. Но в ТО время — это реально было ноу-хау.
Извините, но это чушь. Или зависть (да, я тоже в каком-то смысле завидую Сысоеву — он молодец). Насчет сложный — наверное, уже нет. Но в ТО время — это реально было ноу-хау.
> Да каким бы крутым разработчиком он ни был — не стоит это право столько. nginx не настолько сложный софт.
Извините, но это чушь. Или зависть (да, я тоже в каком-то смысле завидую Сысоеву — он молодец). Насчет сложный — наверное, уже нет. Но в ТО время — это реально было ноу-хау.
Извините, но чушь вы написали.
Там речь о 40 миллиардах рублей.
Полноценное решение типа nginx можно реализовать и оттестировать с нуля и за в сотни раз меньшую сумму и за разумные сроки в 1-2 года.
При этом ничто вам не мешает пользоваться параллельно бесплатным nginx, пока идет разработка.
Причина, по которой F5 потратил на приобретение фирмы nginx столько миллиардов — совсем иная.
Вот эту причину и хотелось бы понять.
Насчет сложный — наверное, уже нет. Но в ТО время — это реально было ноу-хау.
Речь то вовсе не о донате в признание былых заслуг Сысоева. Зачем? Если продукт открытый? Ну хотели бы поблагодарить — обошлись бы меньшей суммой.
А о покупке чего-то. Но чего? Не открытых же исходников nginx.
Почему? А капитализация владельца? В руках F5 nginx — это дорогой актив. И то что он открытый — сути дела не меняет.
Почему? А капитализация владельца? В руках F5 nginx — это дорогой актив. И то что он открытый — сути дела не меняет.
В смысле, пустить пыль в глаза инвесторам?
:) Почему пыль? Актив — это не только станок и стена из бетона. MS миллиарды стоит не из-за того что ее windows и office от копирования защищены, а потому что она их кодом владеет и пользователей дохрена. У гугла вон тоже все бесплатно, и что? На их продуктах полмира подсажено.
:) Почему пыль? Актив — это не только станок и стена из бетона. MS миллиарды стоит не из-за того что ее windows и office от копирования защищены, а потому что она их кодом владеет и пользователей дохрена. У гугла вон тоже все бесплатно, и что? На их продуктах полмира подсажено.
Исходный код MS для большей части мира недоступен.
И при попытке его использовать, если вы его заполучили как-то — вы столкнетесь с дорогими неприятностями юридического свойства.
Гугль отдает в общее пользование только второстепенный код, который никак не могут повлиять на его бизнес. А вот логика работы поискового ядра — коммерческая тайна.
Теперь объясните мне — что именно дает F5 владение общедоступным nginx? Лицензия которого прямо говорит, что, мол, «бери и используй на здоровье».
Я еще добавлю.
>Теперь объясните мне — что именно дает F5 владение общедоступным nginx? Лицензия которого прямо говорит, что, мол, «бери и используй на здоровье».
Есть же кейсы, когда всякие монги-редисы, почуяв, что деньги текут мимо них, переходят с условно «всеразрешающей» лицензии на «ограниченную». Это очень спорный вопрос с юридической точки зрения, т.к. опен сурс — дело коллективное и по идее нужно получить согласие ВСЕХ контрибьюторов на смену лицензии… Но это не выглядит НЕ РЕАЛЬНЫМ… Более того. Есть объективная проблема, что nginx БЕЗ ФИЧ и поддержки актуальных протоколов — будет не нужен. Вот будущее — выходит условный HTTP/3. В бесплатном nginx его поддержи очевидно сейчас нет. А коммерсы купив его тупо не будут вкладываться в развитие открытой ветки (как вариант). Зато в платном варианте будет все необходимое.
Поясню, что то, что я написал — возможный, но не обязательно вероятный, сценарий. А может все будет совсем по-другому.
>Теперь объясните мне — что именно дает F5 владение общедоступным nginx? Лицензия которого прямо говорит, что, мол, «бери и используй на здоровье».
Есть же кейсы, когда всякие монги-редисы, почуяв, что деньги текут мимо них, переходят с условно «всеразрешающей» лицензии на «ограниченную». Это очень спорный вопрос с юридической точки зрения, т.к. опен сурс — дело коллективное и по идее нужно получить согласие ВСЕХ контрибьюторов на смену лицензии… Но это не выглядит НЕ РЕАЛЬНЫМ… Более того. Есть объективная проблема, что nginx БЕЗ ФИЧ и поддержки актуальных протоколов — будет не нужен. Вот будущее — выходит условный HTTP/3. В бесплатном nginx его поддержи очевидно сейчас нет. А коммерсы купив его тупо не будут вкладываться в развитие открытой ветки (как вариант). Зато в платном варианте будет все необходимое.
Поясню, что то, что я написал — возможный, но не обязательно вероятный, сценарий. А может все будет совсем по-другому.
Компания, за недорого, покупает рынок сбыта высоконагруженных решений для инета (30% всех сайтов). В этот канал теперь можно предлагать ПО, сервисы, поддержку, да массу всего. Это их рынок, их клиенты. Условный нетфликс обратится скорее к ним, чем к разработчику аналога, если только аналог не на порядок лучше, а вот это сделать уже и на порядок сложней. И зачем тогда тратиться на разработку аналога?
Условный нетфликс обратится скорее к ним, чем к разработчику аналога, если только аналог не на порядок лучше, а вот это сделать уже и на порядок сложней. И зачем тогда тратиться на разработку аналога?
Кого пугают такие смешные сложности на таких масштабах ресурсов, что можно пустить на разработку? Конкретный Cloudflare, пилит сам.
На базе готового. Но сам и в том числе и с использованием трудоемкого assembler.
Netflix также имеет такую возможность.
Это очень узкий рынок. Все друг друга знают.
Здесь покупка клиентской базы не столь важна, когда ты покупаешь клиентов, с которыми никогда бы не познакомился сам.
На более массовых рынках — согласен, покупка клиентской базы стоит того.
Ваши аргументы серьезно уступают в основательности аргументации, что привел gecube
Вы помните истории, когда покупали компании, только из-за того, что у них были патенты, коллектив или еще что-либо нематериальное?
> Полноценное решение типа nginx можно реализовать и оттестировать с нуля и за в сотни раз меньшую сумму и за разумные сроки в 1-2 года.
По Вашим словам могу предложить Вам самим написать продукт такого же уровня. Ну, а фигли — если это всего лишь 1 год и фикс прайс.
Я сам не фанат nginx (по определенным причинам), вижу сильные альтернативы, которые появились буквально недавно — envoy, traefik.
Но и не могу не отметить сильную сторону nginx — каждый школьник его знает, он уже проник во многие организации (клиентская база) и под него напилено уже очень много модулей и собрана масса экспертизы.
> Полноценное решение типа nginx можно реализовать и оттестировать с нуля и за в сотни раз меньшую сумму и за разумные сроки в 1-2 года.
По Вашим словам могу предложить Вам самим написать продукт такого же уровня. Ну, а фигли — если это всего лишь 1 год и фикс прайс.
Я сам не фанат nginx (по определенным причинам), вижу сильные альтернативы, которые появились буквально недавно — envoy, traefik.
Но и не могу не отметить сильную сторону nginx — каждый школьник его знает, он уже проник во многие организации (клиентская база) и под него напилено уже очень много модулей и собрана масса экспертизы.
По Вашим словам могу предложить Вам самим написать продукт такого же уровня. Ну, а фигли — если это всего лишь 1 год и фикс прайс.
Разделите 40 миллиардов на 100 и посчитайте скольким высококвалифицированнейшим программистам вы сможете оплачивать этот год.
Я сам не фанат nginx (по определенным причинам), вижу сильные альтернативы, которые появились буквально недавно — envoy, traefik.
Все правильно. Их не столь уж недоступно сложно сделать.
Но и не могу не отметить сильную сторону nginx — каждый школьник его знает, он уже проник во многие организации (клиентская база) и под него напилено уже очень много модулей и собрана масса экспертизы.
Безусловно.
Но какой с этого прок F5?
Она и без покупки nginx вполне себе могла это всё использовать.
А брать деньги за всемирное использование nginx (как в своем время поступил хитрый немецкий институт, что держал патент на MP3) — лицензия не позволяет.
Вы помните истории, когда покупали компании, только из-за того, что у них были патенты, коллектив или еще что-либо нематериальное?
Может быть и так.
Но какие патенты могут быть в открытом решение. Как минимум такие вещи в коде прописываются (в комментарии номер патента).
> Она и без покупки nginx вполне себе могла это всё использовать.
Вы почему-то забываете про вполне коммерческий продукт NGINXPlus и возможность заказать у разработчиков поддержку.
Это в России не принято платить разработчикам за консалт — сами с усами, «наши админы разберутся — им же зарплату платят»
Мое мнение — F5 просто хочет консолидировать свои аппаратные решения и свежекупленный программный балансировщик (коим и является nginx) в некое пакетное предложение, новый продукт, с которым они в конечном счете вернутся на рынок.
Вы почему-то забываете про вполне коммерческий продукт NGINXPlus и возможность заказать у разработчиков поддержку.
Это в России не принято платить разработчикам за консалт — сами с усами, «наши админы разберутся — им же зарплату платят»
Мое мнение — F5 просто хочет консолидировать свои аппаратные решения и свежекупленный программный балансировщик (коим и является nginx) в некое пакетное предложение, новый продукт, с которым они в конечном счете вернутся на рынок.
Вы почему-то забываете про вполне коммерческий продукт NGINXPlus и возможность заказать у разработчиков поддержку.
Мое мнение — F5 просто хочет консолидировать свои аппаратные решения и свежекупленный программный балансировщик (коим и является nginx) в некое пакетное предложение, новый продукт, с которым они в конечном счете вернутся на рынок.
А это уже разумное объяснение. Довольно правдоподобное.
В отличие от ерунды, что тут пишут про цель покупки другие комментаторы.
Инвестиция в сырье для твоего продукта, чтобы потом это сырье переварить и продавать продукт созданный на его основе — это да.
Затраты на такое не выглядят большими. Все равно отобьется при будущих продажах.
Политика в том, что кому-то позволено мгновенно возбудить уголовное дело и выслать силовую поддержку, а кому-то, даже при наличии денег — нет.
Все верно, только, кажется, что при наличии денег — все таки "да" в любом случае. Вопрос размера денег
Политика в том, что кому-то позволено мгновенно возбудить уголовное дело и выслать силовую поддержку, а кому-то, даже при наличии денег — нет.
Вы о чем вообще?
Разве Сысоев пытался возбудить уголовное дело, но ему и 40 миллиардов не помогли это сделать?
В приципе и вы можете мгновенно инициировать уголовное дело, есть такая срочная практика, когда судебное решение будет принято оперативно. Например, чтобы мгновенно заморозить незаконное по вашему мнению переоформление квартиры.
>Но это не политические разборки. Это банальные разборки из-за больших денег между возможными владельцами интеллектуальных прав.
Ну да. Если у тебя есть ресурс с автоматчиками, почему бы не попробовать пощипать соседа, правда? Особенно зная, что если и не получиться ничего отщипнуть, то сосед на тебя встречный иск не подаст — у него же(лоха) автоматчиков нет, хахаха.
Ну да. Если у тебя есть ресурс с автоматчиками, почему бы не попробовать пощипать соседа, правда? Особенно зная, что если и не получиться ничего отщипнуть, то сосед на тебя встречный иск не подаст — у него же
> На Хабре есть статьи сети стройматериалов из Франции, если не ошибаюсь.
говорите напрямую — LEROY MERLIN. И это еще вопрос, что там осталось в нем французского (кроме названия)
говорите напрямую — LEROY MERLIN. И это еще вопрос, что там осталось в нем французского (кроме названия)
А зачем, по-Вашему, F5 начал рассылать письма своим клиентам с уверением, что мы ничего кроме nginx в России не разрабатываем?
История nginx о том, что интеллектуальная собственность в России нестабильна. А это всегда риски.
И опять же, для западного бизнеса есть риски связываться с использованием закрытой платформы, которая может в любой момент, по чьей-то прихоти оказаться под санкциями.
История nginx о том, что интеллектуальная собственность в России нестабильна. А это всегда риски.
И опять же, для западного бизнеса есть риски связываться с использованием закрытой платформы, которая может в любой момент, по чьей-то прихоти оказаться под санкциями.
для западного бизнеса есть риски связываться с использованием закрытой платформы, которая может в любой момент, по чьей-то прихоти оказаться под санкциями.
Мне что-то подсказывает, что на решения судов РФ, особенно на сомнительные, западному бизнесу слегка положить. Но да, история неприятная, кто бы спорил.
Также есть мнение, что бренд внедренной ERP системы помогает увеличить капитализацию компании. И этот фактор не в пользу 1С. Не знаю насколько капитализация при этом действительно вырастает, но знаю пару примеров компаний, которые купили SAP именно по этой причине. Болезненные попытки его внедрить особого успеха не имели, по факту все осталось работать на 1С, но зато можно смело заявлять инвесторам, что в «компании внедрено решение международного уровня».
Я малость не в теме, но скажите — а Битрикс подпадает под обсуждение в статье? Потому что мне изредка приходилось иметь дело с этой платформой. Но сейчас я зарёкся…
Любопытно, что в хотелки языка 1С записали сильную типизацию и функции первого класса.
Что насчет зависимых типов?
Зависимые типы — это как?
Вот тут достаточно хорошо описано.
Окститесь, зависимых типов и в мейнстримных ЯП общего назначения то нет, концепция сложная слишком и требующая многих телодвижений. Признаюсь честно — я вот только поверхностно представляю несколько прикладных случаев их использования, но самой концепции не понимаю. Я правда и не изучал специально их, но все равно.
В моем понимании, внедрение зависимых типов может сделать маленькие юнит-тесты ненужными. Плюс юнит-тесты не могут наверняка проверить даже такую функцию:
def isSpecialCase(data:Int): Boolean = {
data== 5
}Ну не писать же нам в тестах
(Int.MinValue to 4) ++ (6 to Int.MaxValue).foreach { v => assert(!isSpecialCase(v)) }
assert(isSpecialCase(5))Есть еще один жирный минус это не востребованность 1с за пределами стран СНГ, а это говорит о том что у разработчиков без смены специализации практически нету шансов переехать в другую страну.
Я бы не рекомендовал особенно молодым разработчикам тратить на 1с своё время, даже если сейчас нету в планах переезжать. Считаю что важно иметь свободу выбора и если вы работаете на внутренний рынок то делаете это осознанно, без сожеления и без мысли о том что где-то трава зеленее.
Вопрос к автору вам за последние 15 лет никогда не хотелось пожить за пределами СНГ?
Поработать в интернациональной команде? Иметь возможность переехать в любую точку планеты никак удалёнщик, а как востребованный специалист? Увидеть и разобраться как работает бизнес в других странах?
Я бы не рекомендовал особенно молодым разработчикам тратить на 1с своё время, даже если сейчас нету в планах переезжать. Считаю что важно иметь свободу выбора и если вы работаете на внутренний рынок то делаете это осознанно, без сожеления и без мысли о том что где-то трава зеленее.
Вопрос к автору вам за последние 15 лет никогда не хотелось пожить за пределами СНГ?
Поработать в интернациональной команде? Иметь возможность переехать в любую точку планеты никак удалёнщик, а как востребованный специалист? Увидеть и разобраться как работает бизнес в других странах?
Вопрос к автору вам за последние 15 лет никогда не хотелось пожить за пределами СНГ
Нет, не хотелось. Я и сейчас могу уехать в любую точку мира и пожить там, в т.ч. как специалист. Или как турист. Но я не хочу. Мне достаточно отпуска в 10-15 дней чтобы погрузиться в атмосферу и начать скучать по дому.
Поработать в интернациональной команде было бы интересно, но опять же — мне необязательно для этого переезжать куда-то навсегда. У меня был такой опыт, довольно короткий — работа как работа, разве что пришлось смириться с тем, что я намного менее убедителен, когда выступаю на неродном языке. Есть проблема со словарным запасом, скоростью сочинения доводов и поясняющих аналогий. Подтянуть язык мне бы хотелось, но опять же — из гуманитарных соображений, я вообще люблю языки и общение, это не из сугубо профессиональных соображений.
Если говорить про "не учи 1С, не сможешь свалить", то это, на мой взгляд, абсурдный довод. Востребованность айтишника измеряется не количеством фреймворков, которые он знает, а способностью решать задачи. Если ты кроме 1С ничего не смог изучить за время карьеры, то ты и в России так себе специалист. А 1С-ники очень сильны в анализе процессов, в построении моделей, в проектировании. Эти знания пригодятся в любой экосистеме.
Вот не скажите. Это извечный спор, и хоть я сам придерживаюсь другого мнения — но большинству работодателей важен именно опыт на конкретном стеке к сожалению (З.Ы. можно еще выехать на алгоритмах, CS, дизайне систем и прочем, есть компании которые забивают на стек и смотрят на базу — но это нужно быть действительно гораздо выше среднего уровня и таких специалистов небольшие и средние фирмы не набирают).
У меня просто есть знакомые ИТ-шники и в Канаде и Германии. Я бы не сказал, что они живут как-то лучше меня в повседневной жизни. Но это холиварный вопрос. Давайте про технологии.
Если работодатель формально подходит к вопросу (независимо от того, прав работодатель или «HR навставлял умных слов в вакансию») про «опыт на конкретном стеке», то нужно тогда вообще ориентироваться не на «только не 1С», а тупо мониторить на каком стеке больше всего вакансий и изучать только его. С точки зрения мат. ожидания хороший путь, да. Но со своими рисками.
Но вообще, часто сталкиваюсь, что «опыт работы с 1С» на должностях, которые подразумевают разработку каких-нить WMS или учетных систем, работадателями считается плюсом.
Плюс, все-таки надо понимать, что условный «web разработчик», который 10 лет пилил интернет-магазины, без командной разработки, использования контроля версий и т.д., тоже работодателю будет не особо интересен. И тут мы возвращаемся к «если ты кроме 1С ничего не смог изучить».
Но вообще, часто сталкиваюсь, что «опыт работы с 1С» на должностях, которые подразумевают разработку каких-нить WMS или учетных систем, работадателями считается плюсом.
Плюс, все-таки надо понимать, что условный «web разработчик», который 10 лет пилил интернет-магазины, без командной разработки, использования контроля версий и т.д., тоже работодателю будет не особо интересен. И тут мы возвращаемся к «если ты кроме 1С ничего не смог изучить».
Очень многие подходят именно формально. Потому что часто нужно «здесь и сейчас» а не завтра. И нет времени на вникание специалистом в используемый стек. И да, 1с действительно в плане работодателя ограничивает, тогда как на других стеках вакансии есть почти везде. С этой точки зрения достаточно ограничиться «любая из более менее распространенных технологий по вкусу».
Я как-то раньше не задумывался о переезде, но то какой трэш творится в стране с ИТ в последнее время, а так же состояние экономики начинает очень напрягать и мысль уже кажется вполне логичной, пусть пока никаких шагов не планирую.
Я как-то раньше не задумывался о переезде, но то какой трэш творится в стране с ИТ в последнее время, а так же состояние экономики начинает очень напрягать и мысль уже кажется вполне логичной, пусть пока никаких шагов не планирую.
>Если говорить про «не учи 1С, не сможешь свалить», то это, на мой взгляд, абсурдный довод.
Немного другая причинно-следственная связь. Я лично от нескольких молодых (до 30) спецов слышал аргумент типа — зачем мне учить 1С, если нигде в мире он не нужен. Все эти ребята и девчата рассматривали релокацию (Европа, Канада).
И для понимания — я сам патриот 1C с 20 летним (без шуток) стажем. И мне искренне обидно, что так вот оно получается, причем совсем не вине 1C.
Немного другая причинно-следственная связь. Я лично от нескольких молодых (до 30) спецов слышал аргумент типа — зачем мне учить 1С, если нигде в мире он не нужен. Все эти ребята и девчата рассматривали релокацию (Европа, Канада).
И для понимания — я сам патриот 1C с 20 летним (без шуток) стажем. И мне искренне обидно, что так вот оно получается, причем совсем не вине 1C.
Про "сильны в анализе процессов" я бы поспорил. Далеко не все, и многие мыслят парадигмами 1с конфигураций, и это уже жирный минус. Да, и стоимость аналитика на порядок ниже программиста.
Решения на базе 1С продаются в Китае, Турции, Вьетнаме, Канаде, Германии, США.
Не так широко, как хотелось бы, наверное, 1С, но тем не менее процесс идёт.
www.accountingsuite.com
www.1ci.com/applications/1c-drive
toronto.1cbit.ru
Не так широко, как хотелось бы, наверное, 1С, но тем не менее процесс идёт.
www.accountingsuite.com
www.1ci.com/applications/1c-drive
toronto.1cbit.ru
Я бы не рекомендовал особенно молодым разработчикам тратить на 1с своё время, даже если сейчас нету в планах переезжать.
В таком ключе, я бы вообще не рекомендовал молодым людям становиться разработчиками. Есть и другие способы уехать на ПМЖ за границу.
del
Да уж. В плане консервативности у 1С все превосходно. Писал на 1С примерно до 8-го года, в принципе на свой кусок булки с маслом зарабатывал, но потом все-же соскочил — очень уж угнетало то что как разработчику там развиваться особенно некуда, слишком узкий мирок.
Вот почитал эту статью — и смотрю в принципе с тех времен там мало что нового появилось (если с позиции рядового 1С-ника смотреть). А язык программирования, даже по сравнению с многословной Явой… В общем негатива ни к 1С ни к адептам платформы не испытываю, но очень рад что в свое время набрался смелости и соскочил (а это было не так просто).
Вот почитал эту статью — и смотрю в принципе с тех времен там мало что нового появилось (если с позиции рядового 1С-ника смотреть). А язык программирования, даже по сравнению с многословной Явой… В общем негатива ни к 1С ни к адептам платформы не испытываю, но очень рад что в свое время набрался смелости и соскочил (а это было не так просто).
как разработчику там развиваться особенно некуда
Это все-таки не совсем так. Или я не совсем понимаю, что такое «развиваться как разработчику».
Решать сложные технические задачи? Развивать сложные системы (пользователей все больше, объемы все больше, нагрузка все выше), причем так, чтобы они не рассыпались при очередном обновлении? Какие-никакие новшества регулярно появляются (веб-, мобильный, внешние источники). Спектр задач достаточно широкий, вопросы интеграций опять-таки.
Да, какие-то вещи на 1С сделать нельзя (часть упомянута в статье), но это ж не значит, что «нельзя развиваться»?
Я не говорил про отсутствие задач. Я говорил о развитии именно как программиста. В 1С развитие — это в основном миграция либо в бизнес (внедрение 1С и налаживание бизнес процессов предприятия), либо в системное администрирование. Я эти направления не считаю чем-то недостойным или неперспективным — там может быть интереснее и выгоднее, но лично мне там неинтересно. А сидеть до пенсии и править формочки в Конфигураторе, подстраивая их под очередной каприз законодательства, пока в типовой не исправят… ну это такое… мягко говоря не то о чем я мечтал становясь программистом.
1С это не только «1С: Бухгалтерия» или «1С: Зарплата», все таки. Посмотрите, допустим на «УНФ». Есть специализированные решения типа «1С: Интеграция» или «2is: Интеграция» (просто чтобы упомянуть еще и хотя бы одно не типовое решение).
Да, это все еще разработка на 1С, но уже в отрыве от «капризов законодательства» и гораздо ближе к «развитию как разработчика». Таких проектов и работодателей мало, но становится в последнее время все больше.
Да, это все еще разработка на 1С, но уже в отрыве от «капризов законодательства» и гораздо ближе к «развитию как разработчика». Таких проектов и работодателей мало, но становится в последнее время все больше.
Говорю как человек работавший над разработкой коробки к законодательству не привязанной от слова совсем. Нишиша. Та же история, день сурка. Все развитие либо в девопс, админство, оптимизацию запросов и бд и подобное, либо в бизнес домен. Развития как программиста после какого то уровня — 0.
Все равно не понимаю вашу логику.
Берем двух разработчиков:
Первый пишет, допустим, интеграционную шину на 1С. Начинает с простых вещей типа штатного плана обмена и выгрузки по правилам в XML, потом начинает накручивать поверх веб-сервисы, внешние источники, json, rabbitMQ и т.д. и т.п… Развивается. Допустим, в какой-то момент все что есть в платформе он уже изучил и использовал. Все возможные ситуации обработал. Развитие продукта закончилось, разработчику остается только править на этом проекте баги и заниматься оптимизацией под какие-то конкретные бизнес-кейсы.
Вопрос, второй разработчик, который все то же самое будет пилить на Java/.Net/C++ разве не такой же путь пройдет? И точно так же не упрется разве в какой-то момент в потолок развития продукта? Ок, он будет каждые N лет заниматься переписыванием этого всего с Java X на Java X+10 и рефакторингом, ну так и на 1С тоже можно так же делать.
Если не устраивает — и первому и второму нужно искать другой проект. Не улавливаю в чем разница-то?
Берем двух разработчиков:
Первый пишет, допустим, интеграционную шину на 1С. Начинает с простых вещей типа штатного плана обмена и выгрузки по правилам в XML, потом начинает накручивать поверх веб-сервисы, внешние источники, json, rabbitMQ и т.д. и т.п… Развивается. Допустим, в какой-то момент все что есть в платформе он уже изучил и использовал. Все возможные ситуации обработал. Развитие продукта закончилось, разработчику остается только править на этом проекте баги и заниматься оптимизацией под какие-то конкретные бизнес-кейсы.
Вопрос, второй разработчик, который все то же самое будет пилить на Java/.Net/C++ разве не такой же путь пройдет? И точно так же не упрется разве в какой-то момент в потолок развития продукта? Ок, он будет каждые N лет заниматься переписыванием этого всего с Java X на Java X+10 и рефакторингом, ну так и на 1С тоже можно так же делать.
Если не устраивает — и первому и второму нужно искать другой проект. Не улавливаю в чем разница-то?
Вряд ли мы придем к одной точке зрения. Это ощущение довольно трудно формализуемо, но все что вы описываете — чисто прикладные, утилитарные вещи. В 1с что бы ты не делал — остаешься в рамках платформы, даже если что то сбоку прикручиваешь. Это не говоря о том что в основном пишешь на очень простом языке не дающем возможности разгуляться, на который очень плохо переносятся считающиеся лучшими практики от других программистов и прочее. А так же поголовное(за редкими исключениями) стремление работодателей задавить любой инженерный интерес и заставить разработчика идти изучать прикладные решения от 1с, сертификаты по ним получать и прочее (в свободное время!!), когда нормальному инженеру интереснее бы было почитать про новый подход в разработке, применение хороших практик, алгоритмы, ОС, математику, теорию ЯП и прочие интересные вещи.
Это ощущение довольно трудно формализуемо, но все что вы описываете — чисто прикладные, утилитарные вещи
Разработка это в принципе «прикладные, утилитарные вещи». Давайте все-таки разделять «Software Engineering» и «Computer Science». Изучение «алгоритмов, теории ЯП» это не «развитие как разработчик», извините.
Приведу аналогию про врачей. Есть хирург, а есть анестезилог. И вот анестезиолог ходит и жалуется «не могу развиваться как врач, вон у хирурга столько всяких ножичков, он в кишочках копается, а мне только следить за внешними показателями типа дыхания надо и пару раз укол сделать за операцию, никакого развития». Ну или «работаю проктологом, каждый день одно и то же, а вот у меня друг грудные импланты ставит — сказка, а не работа». Кто гинеколог, проктолог, венеролог и т.д. в контексте разработки ПО решайте сами.
Возвращаясь к разговору о наших виртуальных программистах. Какой из перечисленных врачей «больше врач»? Какой из них «больше развивается как врач» в процессе своей работы?
заставить разработчика идти изучать прикладные решения от 1с, сертификаты по ним получать и прочее
Для компании-франчайзи — логичное желание. Компании из реального сектора на наличие сертификатов наплевать.
Но им не наплевать на знание прикладных решений 1с и партнеров.
Даже если вернуться к чисто утилитарным вещам — в 1с все очень ужасно с построением собственных абстракций, что тоже не способствует. Также жестко навязана архитектура системы. Это даже если забыть что программирование не ограничивается учетными системами, а в разработке других систем и подходы с паттернами и архитектурами другие. Где тут развитие если вечно в одной парадигме сидеть.
Даже если вернуться к чисто утилитарным вещам — в 1с все очень ужасно с построением собственных абстракций, что тоже не способствует. Также жестко навязана архитектура системы. Это даже если забыть что программирование не ограничивается учетными системами, а в разработке других систем и подходы с паттернами и архитектурами другие. Где тут развитие если вечно в одной парадигме сидеть.
Но им не наплевать на знание прикладных решений 1с и партнеров.
Наплевать, если они их не используют. Из лично моего опыта — типовые (Бух, ЗУП) на поддержке у франчей, внутренний отдел разработки пилит внутренние решения. Знание типовых может являться плюсом, если нужно интеграцию подпилить, но не более.
Где тут развитие если вечно в одной парадигме сидеть
Если вы все время «прыгаете» между разными (принципиально) системами и предметными областями в других языках, то вы тоже не особо «развиваетесь», как бы. Наработка опыта и изучение вот этого всего тоже не бесплатна. В итоге вы либо вечный мидл (в лучшем случае, в худшем — манкикодер), либо выбираете-таки конкретное направление.
Про жестко навязанную архитектуру в принципе не соглашусь. Подходы, например, к обменам даже в упомянутых мной интеграционных решениях разные. Причем архитектурно разные. Да, есть определенные ограничения и необходимость действовать в рамках предоставленных базовых классов, но такими уж «жесткими» я бы эти ограничения не назвал.
Причем, на мой взгляд, как раз архитектурные паттерны на 1С вполне хорошо ложатся.
Ну в общем я уже говорил что вряд ли мы придем к единой точке зрения.
Ну я ж не проповедник, чтобы вас в свою веру обращать. Просто, ИМХО, вы путаете «академический интерес к программированию» и «разработка как инженерная дисциплина».
Первое, это про чтение Кнута, Танненбаума, реляционной алгебры и бог знает чего еще.
Но реально «без ограничений» развиваться и применять на практике (зарабатывая при этом) вы это сможете либо выступая на конференция/преподавая на курсах, либо уйдя в open source или разработку своего ЯП.
При этом, применять на практике (с ограничениями) все это можно и в рамках 1С фреймворка или любого другого фреймворка.
Во втором случае, нужно изучать практически применимые вещи и всякие стандарты/паттерны/«стек А версии B», потому что это востребовано на рынке. Любому работодателю нужно выполнение конкретных задач, на конкретном стеке, увы. В общем случае, даже развитие конкретного разработчика выше/шире определенного уровня не нужно — платить придется больше, а то и вообще переманят.
Первое, это про чтение Кнута, Танненбаума, реляционной алгебры и бог знает чего еще.
Но реально «без ограничений» развиваться и применять на практике (зарабатывая при этом) вы это сможете либо выступая на конференция/преподавая на курсах, либо уйдя в open source или разработку своего ЯП.
При этом, применять на практике (с ограничениями) все это можно и в рамках 1С фреймворка или любого другого фреймворка.
Во втором случае, нужно изучать практически применимые вещи и всякие стандарты/паттерны/«стек А версии B», потому что это востребовано на рынке. Любому работодателю нужно выполнение конкретных задач, на конкретном стеке, увы. В общем случае, даже развитие конкретного разработчика выше/шире определенного уровня не нужно — платить придется больше, а то и вообще переманят.
Вот серьезно, когда я заявляю каким угодно разработчикам о любопытстве к теории или расширению кругозора в программировании — мне качают головой с пониманием. Сами такие, другое дело что времени из-за изучения свежих фреймворков не всегда хватает. Когда заявляешь такое 1сникам — все крутят у виска и советуют лучше сходить курс по какой нибудь ERP посмотреть. Разница довольно заметна между коммьюнити. Это даже если забыть про довольно бурное постоянное развитие в сфере архитектур и подходов к построению систем или UI приложений. serverless, микросервисы, монолиты и еще разные вариации архитектур на беке. Распределенные системы. Большие данные. На клиенте же вечные споры декларативный vs императивный подход к построению UI, входящий в моду однонаправленный поток данных. MVI/MVP/MVVM/VIPER/MVC и прочее. Плюс бурное развитие языков программирования позволяющее все более удобные абстракции строить и писать более читаемый и надежный код. А оглядываясь на 1с в лучшем случае что то интересное при интеграциях разве что делать приходится, и то внутри 1с чаще всего, что сильно ограничивает.
Ну ты же знаешь, где найти правильное 1С-ное коммьюнити, разве нет? ;)
Знаю конечно, но это все же меньшая часть. К тому же физически сосредоточенная в паре городов. Почему то очень сомневаюсь что найду подобное в своем городе, ибо в самом крупном франче в нем я работал и там было именно как я описал. В отличие от — недавно был на локальном митапе где go разработчик рассказывал о пет проекте как раз на serverless архитектуре для общения с использованием шифрования на эллиптических кривых. Поскольку у меня до сих пор висит в списке на изучение флаттер который толком никак не потрогаю — есть небольшая вероятность что присоединюсь и сделаю на нем мобильную морду для этого пет проекта в целях любопытства. А казалось бы один город, одни люди, но кто то делает что то прикольное, а кто то сертификаты по конфигурациям получает.
мне качают головой с пониманием. Сами такие, другое дело что времени из-за изучения свежих фреймворков не всегда хватает. Когда заявляешь такое 1сникам — все крутят у виска
Т.е. первые кивают («да, мы тоже такие продвинутые и в тренде»), но не делают («нет времени», «нет денег», «страна не та»), а вторые прагматично предлагают тратить время на что-то, что можно легко монетизировать? =)
Если 1С-ники будут кивать с пониманием, но не будут изучать, т.к. времени нет, это исправит для вас ситуацию?
Если уж использовать аналогии — это как работа фельдшера в деревне и хирурга в крупной больнице. Фельдшер тоже нужен, но если ему интересна хирургия — выше определенного уровня он не прыгнет, как бы не старался (оставаясь фельдшером).
Сколько с 1С работал — 99% задач было именно что-то из разряда: «у нас типовая на типовую не накатилась, иди разберись», «вышло постановление ФНСГРУФСБМЧСГКЧП о том что форма дока изменилась, и теперь нужно запятую поставить вот тут, а это подчеркивание перенести туда, типовая еще не обновилась — давай сделай»… Самое интересное было что-либо из разряда «у нас вот приходят письма по электронке с прайсами, надо бы их автоматически загружать».
Пока был джуном — это все было не то что-бы сильно интересно, но норм, а дальше…
Сколько с 1С работал — 99% задач было именно что-то из разряда: «у нас типовая на типовую не накатилась, иди разберись», «вышло постановление ФНСГРУФСБМЧСГКЧП о том что форма дока изменилась, и теперь нужно запятую поставить вот тут, а это подчеркивание перенести туда, типовая еще не обновилась — давай сделай»… Самое интересное было что-либо из разряда «у нас вот приходят письма по электронке с прайсами, надо бы их автоматически загружать».
Пока был джуном — это все было не то что-бы сильно интересно, но норм, а дальше…
Ну у меня уже лет 7 таких задач не было, я уже по ним заскучать успел. Может у вас в выборе задач что-то подправить?
Программист .net или java, сидящий на проекте поддержки legacy сталкивается ровно с теми же проблемами. Это вопрос проектов и задач, а не фреймворка/языка.
Я сильно подозреваю, что значительный процент разработчиков на всех языках, занимается именно поддержкой legacy. Это если не упоминать еще всяких разработчиков на фреймфорках типа workforce/salesforce, которые часто упоминаются как «та же 1С, только на английском».
Т.е. проблемы те же.
Я сильно подозреваю, что значительный процент разработчиков на всех языках, занимается именно поддержкой legacy. Это если не упоминать еще всяких разработчиков на фреймфорках типа workforce/salesforce, которые часто упоминаются как «та же 1С, только на английском».
Т.е. проблемы те же.
Сколько с 1С работал — 99% задач было именно что-то из разряда: «у нас типовая на типовую не накатилась, иди разберись», «вышло постановление ФНСГРУФСБМЧСГКЧП о том что форма дока изменилась, и теперь нужно запятую поставить вот тут, а это подчеркивание перенести туда, типовая еще не обновилась — давай сделай»… Самое интересное было что-либо из разряда «у нас вот приходят письма по электронке с прайсами, надо бы их автоматически загружать».
Пока был джуном — это все было не то что-бы сильно интересно, но норм, а дальше…
Вы сейчас описали типичные задачи для джуна — не более.
Мне почему-то все больше попадалась «нестандартная интеграция с внешним софтом», «существенное изменение движения по регистрам для таких то целей», «навороченная система ценообразования, скидок и бонусов» и т.п.
Фактически вы работали в поддержке, а не в разработке.
Идея 1С с типовыми конфигурациями — как раз и означает, что большая часть работы — это именно поддержка.
Но я изначально ориентировался на разработку, так что описанных вами неинтересных задач у меня был самый мизер.
Вряд ли мы придем к одной точке зрения. Это ощущение довольно трудно формализуемо
Вы вряд ли придете к одной точки зрения с вашим оппонентам.
Но по другой причине:
Эти вещи нужно рассматривать не столь абстрактно, а только относительно конкретной прикладной задачи. И с конкретными программистами.
А ощущения тут совершенно не при чём.
Еще есть такой путь развития — стать руководителем таких же бедолаг и "впаривать" им все то, что тут уже в комментах предлагали за 1с.
Жаль, что нет кармы плюсануть статью, но это лучший расклад по полкам!!!
Андрей, очень круто и по делу!
PS:
— как «эксперт» считаю что сервер приложений не так уж плох как сказано в статье ))
— действительно ли серверная часть других систем и решений работает так идеально, что 1с на ее фоне выглядит бледно?
Андрей, очень круто и по делу!
PS:
— как «эксперт» считаю что сервер приложений не так уж плох как сказано в статье ))
— действительно ли серверная часть других систем и решений работает так идеально, что 1с на ее фоне выглядит бледно?
Если сравнивать «фреймворк» 1С: Предприятия, то сравнивать надо с такими-же фреймворками, где отправить клиенту счёт в PDF по почте решается за две минуты написания строки в коде: отправить_по_почте_pdf(client). Если таковых фреймворков не существует, то лучше не сравнивать даже c .NET Framework, так как на .NET можно написать аналог 1С: Фреймерворк, а вот на 1С ну никак не напишешь .Net framework. Потому что .net фреймворк более низкого уровня.
PS. Статья хорошая, мне понравилась, но база в xml… До сих пор считаю это непонятным решением.
С точки зрения простоты — положил файл, где захотел и не нужен мне админ, это неплохое решение, по сравнению с каким-нибудь sql установленным локально. Но с точки зрения производительности и объёма… При этом у фирмы всегда есть какой-нибудь айтишник на подхвате и тут разницы нет в одном xml-файле база, или в файле sql. Проблемы есть со всеми вариантами, но вариант с sql выгоднее бизнесу конечного покупателя.
PS. Статья хорошая, мне понравилась, но база в xml… До сих пор считаю это непонятным решением.
С точки зрения простоты — положил файл, где захотел и не нужен мне админ, это неплохое решение, по сравнению с каким-нибудь sql установленным локально. Но с точки зрения производительности и объёма… При этом у фирмы всегда есть какой-нибудь айтишник на подхвате и тут разницы нет в одном xml-файле база, или в файле sql. Проблемы есть со всеми вариантами, но вариант с sql выгоднее бизнесу конечного покупателя.
Например, задача послать клиенту счет в PDF решается за час работы студента. Та же задача на .NET решается покупкой проприетарной библиотеки, либо парой дней или недель кодинга сурового бородатого разработчика.
Вот тут Вы преувеличиваете. Не знаю, как в .Net, для Java есть, например, JasperReports. Бесплатная библиотека по формированию отчетов, с достаточно неплохой тулзой по редактированию шаблонов, которая один раз прикручивается и точно также, практически одной командой, прекрасно формируется PDF. А также еще поддерживает xlsx, docx, odt и много других форматах.
И в целом, не стоит забывать про важную проблему 1С — закрытость и проприетарность. Для Java можно часто найти бесплатную библиотеку практически под что угодно. Например, нужно было считать mdb формат (Access) — без проблем нашли.
Jasper по сравнению с 1С уже критиковал speshuric в комментариях к соседней статье про 1С.
Там был другой контекст (drill-down и прочее, которое скорее отношение к BI имеет). Здесь же речь идет конкретно о формировании PDF. Вы просто так написали в статье, как будто в .Net или Java — это очень сложно. Но это не так.
в Jasper после нормального 1с репортера что-то сделать — это мазохизм. Я не ярый пропагандист 1с, но в некоторых вещах он покрывает другие решения как бык овцу. BI, кстати. к ним не относится. Но генерация отчетов и печатных форм там почти идеальная.
Что только не пробовали. Его, пожалуй только excel обгонит по сочетанию результат/простота, да и то только в неструктурированной отчетности.
Что только не пробовали. Его, пожалуй только excel обгонит по сочетанию результат/простота, да и то только в неструктурированной отчетности.
Вы уточните, пожалуйста, все таки что и с чем Вы сравниваете. Печатные формы и отчеты — это две абсолютно разные вещи.
Под печатными формами подразумевается то, что выводится на печать в формате, например, A4 (или любом другом размере страниц). Именно для этого и используется формат PDF.
И при формировании PDF то, что 1С уделывает JasperReports — очень спорное утверждение. Учитывая то, что PDF — это по сути графический формат, а в 1С — табличный.
Если речь идет об именно формировании отчетности (то есть вывода пользователю агрегированной информации в разных срезах), то логичнее сравнивать не с JasperReports, а например с Tableau или Imply. И там тоже сравнение явно не в пользу 1С.
Под печатными формами подразумевается то, что выводится на печать в формате, например, A4 (или любом другом размере страниц). Именно для этого и используется формат PDF.
И при формировании PDF то, что 1С уделывает JasperReports — очень спорное утверждение. Учитывая то, что PDF — это по сути графический формат, а в 1С — табличный.
Если речь идет об именно формировании отчетности (то есть вывода пользователю агрегированной информации в разных срезах), то логичнее сравнивать не с JasperReports, а например с Tableau или Imply. И там тоже сравнение явно не в пользу 1С.
Ценник на Tableau еще упомянуть забыли )
Я для примера привел Tableau. Есть, например, Power BI. Там более гуманный ценник. И ничего, что 1С — тоже не бесплатный?
Если сравнить с Табло или Пентахо — считай бесплатный )) А ведь они только агрегаторы-визуализаторы. Кто-то должен еще заплатить за создание UI для операционных работников
Давайте не перескакивать с темы на тему. Изначально я указал неточность в статье, что в (.Net/Java) сложно реализовать печать в PDF. Потом почему-то перескочили на отчеты, а теперь уже операционные работники пошли.
В целом в OLTP систему вешать отчеты — это тоже палка о двух концах. Если большие объемы, то аналитику все равно лучше выводить в отдельную BI базу, вроде бесплатного Druid, а не реляционные базы.
В целом в OLTP систему вешать отчеты — это тоже палка о двух концах. Если большие объемы, то аналитику все равно лучше выводить в отдельную BI базу, вроде бесплатного Druid, а не реляционные базы.
Есть аналитика для аналитиков а есть аналитика для операционистов.
Работнику склада не нужно знать все а только сколько заказов в работе и сколько товара в каких ячейках, утрированно.
Аналиьикам же нужно понимать динамику работы кладовщиков и выявлять нелеквиды на складе.
В первом случае внешняя система не нужна, во втором может быть полезна.
В прочем 1С предлагает решения для каждой потребности
Работнику склада не нужно знать все а только сколько заказов в работе и сколько товара в каких ячейках, утрированно.
Да, только ему это часто надо не в виде отчетов, а в конкретных бизнес-процессах на конкретных формах. И при этом вводить данные на основе того, что он видит. Отчеты для этого несильно помогут. Тут важно делать гибкий интерфейс, в котором сразу и аналитика, и пользовательский ввод. И в 1С с этим есть определенные проблемы. Например, нельзя делать редактирование в динамических списках.
С точки зрения программиста 1с отчет и печатная форма — схожие понятия. Взять некие данные (запросом, чтением реквизитов, голым расчетом или просто из шаблона ...) и положить их в печатную форму. Во что потом форму печатать в бумагу, excel, pdf не суть важно. Важно то, что степень тюнинга — очень высокая, и можно сильно балансировать сложность отчета давая пользователю массу параметров настройки отчета.
Сравнение с BI не прокатывает. Мы выгружаем пользовательские данные в PowerBI, Amazon QuickSight, немного в Tableau. Везде результат один — срезы и игра кубиками — супер, но нюансовые отчеты приходится даже тем у кого 1С нет в учете, делать на нем. Просто чтобы добиться подобного результата на вышеперечисленных системах — времени надо вагон. А 1С, да еще не из типовой а из подготовленного для BI хранилища — это задача для стажера в перерыве между парами
Сравнение с BI не прокатывает. Мы выгружаем пользовательские данные в PowerBI, Amazon QuickSight, немного в Tableau. Везде результат один — срезы и игра кубиками — супер, но нюансовые отчеты приходится даже тем у кого 1С нет в учете, делать на нем. Просто чтобы добиться подобного результата на вышеперечисленных системах — времени надо вагон. А 1С, да еще не из типовой а из подготовленного для BI хранилища — это задача для стажера в перерыве между парами
Да ужасен этот Jasper, и всякие Birt. После красивейших отчётов 1С, больно смотреть на другие отчёты, простите. А по скорости разработки отчётов в 1с ничто не сравнится. И по стоимости.
Отличная статья, говорю как разработчик, сменивший стек с 1С на Python.
Андрюх, спасибо за статью! Молодец, что выдержал направленное сравнение фреймворка (а не конкретных приложений или самой компании).
В разных фрейворках есть плюсы и минусы.
Я за то, чтобы развивать язык 1С (как ЯП) и фреймворк (ака само 1С: Предриятие).
Зная разработку на других языках/фреймворках- могу сказать, в Java (например) делать бизнес приложение уровня «типовой от 1С» — это суцидно. Да, может кому-то прикольно, но для бизнеса и стратегического развития, имхо, суицидно.
Я один раз, чуть не ввязался в такой проект на Python, хоть сам имею стаж 3-4 года на питоне, но Слава Богу, могу понять что это, с технологической стороной — утопичный проект (был и есть).
Нет, делать решение уровня типовой на 1С на Java это очень прибыльно и выгодно. Если ты исполнитель на данном контракте и деньги вперед.
Т.е. SAP Hybris это утопичный проект?
Ага. Та еще хрень. Лично участвовал в проекте пересадки крупного ритейлера с этой дряни на 1С, причем ритейлер очень сильно мечтал закопать этот Хайбрис и не вспоминать.
И сколько компаний могут позволить себе такую разработку и не умереть (ака «суицидно»)? С фреймворком от 1С такую разработку может себе позволить любой франч 10-20 программистов.
Это я топлю за преимущества фреймворка 1С :)
Далее, вопросы доработкам (открытости кода) и распространения… — в закрытом проекте на Java — тут много сложно-решаемых вопросов...
Код там вполне открытый, для клиента, разумеется. 1С тоже, формально — что-бы получить код надо купить конфу, а код платформы и вовсе недоступен. В этом плане САП более открытый, там все исходники есть.
Доработки — никаких проблем, доводилось немного заниматься — код есть, изучай и дорабатывай.
Доработки — никаких проблем, доводилось немного заниматься — код есть, изучай и дорабатывай.
О да, мне тоже приходилось видеть SAP Netweaver. Садись изучай и дорабатывай. переменные Z_YM084002, функции DLT_MTRANS_001_UBRM24, и IDE после которой Конфигуратор 1С будет даром бессмертных богов. Спасибо, не нужно.
Я про Hybris писал, так как вживую видел только его. Там нормальный код и IDE можно использовать какое захочешь, я Идею использовал, например.
Да я в общем-то это не в том плане что «1С маздай, САП рулез!!!!» а в том что аналоги есть, а сложнее они или нет — это еще как сказать, конфигурировать типовую 1С несложно, но там под капотом движок, который не думаю что проще того-же хайбриса, просто в случае с 1С вы его исходники не видите и не увидите никогда.
Да я в общем-то это не в том плане что «1С маздай, САП рулез!!!!» а в том что аналоги есть, а сложнее они или нет — это еще как сказать, конфигурировать типовую 1С несложно, но там под капотом движок, который не думаю что проще того-же хайбриса, просто в случае с 1С вы его исходники не видите и не увидите никогда.
Я видел хайбрис мельком. По-моему там под капотом то же самое, что и в типовых 1С — бизнес-логика и обеспечивающие ее вспомогательные модули. Т.е. код что Хайбриса, что 1С:ERP доступен разработчику. А доступность кода сервера приложений Hybris — не уверен, что он доступен.
Хотел написать что нифига подобного… потом призадумался, сам не слишком сильно в это погружался (видимо потому что почувствовал что меня опять в аналог 1С затягивает, хоть и с западным уклоном :)))), но процентов на 80 уверен что никакого сервера приложений там нет. Из проприетарщины возможно только какие-то библиотеки, но их штатный дизасемблер из JDK вполне нормально показывает.
Единственная нормальная статья о сравнении 1С с другими языками и средами разработки во всем интернете. Сразу видно, что человек работал с 1С, а не гавноджуниор жава или C#'пей поработавший месяц на 1С и поливающий его гавном. К слову сказать сами 1Сники местами ненавидят 1С за многие вещи, что и раскрыл автор статьи, но по скорости разработки бизнес-приложений никто и никогда не обгонит 1С, как не тужьтесь и не брызжите слюной.
Простых бизнес приложений с небольшой нагрузкой. Попробуете запустить десятки тысяч пользователей или же замахнуться на очень крупный и нагруженный бизнес логикой проект (который еще и меняться будет со временем) — почуствуете всю боль динамической типизации, унылого рефакторинга, отсутсвия ФП и ООП, принятых часто в 1сных командах подхода писать без тестов, унылостью хранилища и прочими вещами что приносят боль.
Ну тут вопрос в направлении боли. А еще можно прочувствовать боль от глючащих ORM, самописных ролевых моделях доступа с дырками, трах с корректной печатью документов и необходимостью делать руками ВьюМодели под каждый класс предметной области… Боль, она разная бывает :)
Это конечно да, но тем не менее очень многие предпочитают не ту боль что в 1с.
Справедливости ради те кто на js пишут — часто часть боли 1сников ощущают, но у тех то хоть инструменты есть позволяющие программистам чуть расслабиться, да возможность транспиляции из нормальных языков в крайнем случае.
Справедливости ради те кто на js пишут — часто часть боли 1сников ощущают, но у тех то хоть инструменты есть позволяющие программистам чуть расслабиться, да возможность транспиляции из нормальных языков в крайнем случае.
Многие разработчики — да предпочтут эту боль, т.к. им нравится долго и бесконечно перестраивать абстракции и играть в творца. А бизнесу нравится чтобы было быстро и приносило деньги.
Но быстро как раз не получится из за той боли что я описал. Со временем тех долг растет что замедляет разработку, а рефакторинг настолько сложен что на него время не выделяется. Причем правилу бойскаута следовать не выйдет поскольку просто страшно трогать в этом нагромождении легаси что то без поддержки тайп чекеров, статических анализаторов, тестов и прочего. Мержи тоже превращаются в боль по тем же причинам.
Про юзабельность иде я написал в статье достаточно четко — она не на нуле, она в минусе. Тут я вроде как солидарен, не?
Писать без тестов — каждый сам себе злобный буратино. Возможность писать «с тестами» присутствует. И не одна.
Только в коммьюнити в массе это не принято и вероятность попасть в команду где этим не занимаются и не хотят об этом слышать выше. Так же большая проблема писать юнит тесты без соблюдения DI принципа, а соблюдать его в 1с практически нереально ибо все жестко завязывается на реализацию. В лучшем случае придется фейковые общие модули заводить с обработками, и выглядит это настолько дико и ужасно — что лучше бы вообще не делать.
На счет тестов соглашусь — в 1С есть механизмы для этого, только никто их не использует. Да и не принято у 1Сников тратить на тестирование времени больше чем на разработку, потому как попробуйте объяснить своему директору говнорю-бизнесмену, который нанял вас за 3 копейки, что тестирование это важно. Малый и средний бизнес, для которого и создавался как мне кажется 1С изначально, не приемлет таких трудозатрат и времени — нужен быстрый результат. Собственно наверное поэтому в первых версиях 8-ки и не было механизмов для разработки автотестов.
Потому что механизмы убогие и начинаются не там. Нахера, извините, сценарное тестирование форм, когда нет модульных и интеграционных тестов? А их нет, потому что модульность не завезли, DI не завезли, мокать невозможно, в IDE поддержки нет.
Извините, но вы даже близко не попали.
Были бы тесты, была бы и поддержка в IDE, и моки, и поэтессы наверное.
Но отсутствуют они совсем по другим причинам.
Были бы тесты, была бы и поддержка в IDE, и моки, и поэтессы наверное.
Но отсутствуют они совсем по другим причинам.
Потому что механизмы убогие и начинаются не там. Нахера, извините, сценарное тестирование форм, когда нет модульных и интеграционных тестов? А их нет, потому что модульность не завезли, DI не завезли, мокать невозможно, в IDE поддержки нет.
Типичный разработчик не эти глобальные вещи меняет вовсе.
То что вы написали — эти вещи только сама 1С да те кто полноценные конфигурации разрабатывают — тем и нужно. А там есть способы.
Практически все разработчики типовых используют тестирование — ERP/УПП, БП, ЗУП. Они об этом неоднократно говорили.
Вот франчи — да, там это скорее редкость. Но опять-таки это от культуры конкретной команды зависит.
Вот франчи — да, там это скорее редкость. Но опять-таки это от культуры конкретной команды зависит.
Практически все разработчики типовых используют тестирование — ERP/УПП, БП, ЗУП. Они об этом неоднократно говорили.
Вот франчи — да, там это скорее редкость. Но опять-таки это от культуры конкретной команды зависит.
И от задач.
Если это не какой-нибудь там Рарус, что полноценные конфигурации сам пишет — так задача у франча чаще «местного значения», весьма локальная, редко когда есть необходимость что-то полноценно тестировать.
Гораздо больше необходимость фунционального тестирования с пользователями (не автоматизированного тестирования), когда не столько технические ошибки выявляются, а вносятся корректировки в бизнес-процесс по мере знакомства пользователя с результатами разработки.
В этой схеме отдельное юнит-тестирование смысла не особо и полезно.
На счет тестов соглашусь — в 1С есть механизмы для этого, только никто их не использует. Да и не принято у 1Сников тратить на тестирование времени больше чем на разработку, потому как попробуйте объяснить своему директору говнорю-бизнесмену, который нанял вас за 3 копейки, что тестирование это важно
В известных мне веб-проектах — реализованные отдельные механизмы автоматизированного тестирования тоже редкость.
В 1С тоже кто-то использует, кто-то нет.
Ну и плюс специфика — этот функционал нужен еще вчера. А через три дня он будет уже изменен. А через полгода уже выключен.
Поэтому, чаще всего, фактически происходит тестирование на живую. Так нужно ради быстрых изменений бизнес-процессов.
А вот при написании сложных больших разработок, создаваемых как единое целое — вполне себе используется в 1С тестирование.
На счет большой нагрузки — ни разу не спорю, но как указал автор, хозяевам 1С интересно все, что интересно бизнесу и большие нагрузки это важно, видимо поэтому в последних релизах появились механизмы позволяющие распределять таблицы одной базы по разным дискам или что то типа того. В свое время появились механизмы разделения итогов, управляемые блокировки и т.д. Что уж говорить, если в 1С 8.0 не было даже пакетных запросов. Сама платформа, как я понял, разрабатывается в таком ключе, что бы как можно быстрее дать готовое решение, а уже потом его оптимизировать — это наблюдается на протяжении всей истории платформ 1С8x. Отсюда собственно и скорость выхода новых релизов платформы с адским количество глюков, но зато быстро и что то новенькое, так сказать «рашн хард стайл программинг». В целом можно сказать, что 1С постоянно движется в направлении оптимизации и масштабируемости, пытается оседлать, так сказать, высокие нагрузки. И уже сейчас встречаются статьи где описывают успешно реализованные распределенные архитектуры на базе 1С которые выдерживают эти самые десятки тысяч пользователей. Да — ад, да — такое могут единицы, может и решения не тривиальные и не по учебнику, но уже есть зачатки и как то оно работает.
Честно — не помню решений на десятки тысяч пользователей. На десяток — да, видел в одном из отчетов. Впрочем по бумаге и купленным лицензиям у того же магнита 5к пользователей почти было должно быть на проекте что мы делали, по факту работало одновременно с системой хорошо если пара тысяч. Так что то что на бумаге — еще хз что там по факту.
я такие делал. и они из разряда "на 1с" быстро переходят в разряд "на sql", "на python" и т.п, а в 1с только формы ввода и остаются.
я такие делал. и они из разряда «на 1с» быстро переходят в разряд «на sql», «на python» и т.п, а в 1с только формы ввода и остаются.
Видимо, вы сталкивались с крайне простыми бизнес-процессами, где дешево сделать на универсальных инструментах и это оправдано.
Так как узкоспециализированное но низкофункциональное решение (которое, имхо, должен быть способен написать любой квалифицированных программист средней руки) — безусловно будет высокопроизводительным.
Но, если речь идет о чем то сколько-нибудь сложном, полнофункциональном, универсальном — стоимость разработки и особенно поддержки — на упомянутых вами инструментах становится непомерно высока.
При обсуждении темы про русский синтаксис почему-то никто никогда не вспоминает, или даже не задумывается, о другом аспекте. Дело вообще не в простоте для новичков. И совсем не в том, что синтаксис на родном языке, и так в чём-то легче.
Это просто удобно. Это просто ОЧЕНЬ удобно!
Автоматизируя бизнес-процессы в России, очень удобно именовать все сущности на русском языке. Не пытаться переводить их на английский, зачастую неправильно, не уродовать безумным транслитом. Практически любой большой проект автоматизации на других средствах вызывает порой гомерический хохот при виде наименований объектов и сущностей на латинице. Особенно с учетом того, что часто разработчики не очень хорошо знают английский.
А теперь представьте написание кода, где все сущности именованы на русском, может даже переменные можно именовать на кириллице, но синтаксис самого языка — исключительно латиница! Да вы через неделю активной разработки раздолбаете Ctrl-Shift на клавиатуре, а потом словите нервный срыв!
Я уж не знаю, сам ли Сергей Нуралиев в своё время придумал этот ход, но это оказалось отличной идеей для средств автоматизации учета именно в России. Ну и конечно же это совсем не значит, что как-то ограничивает продукты компании именно Россией, для всех остальных Андрей правильно заметил — всегда есть синонимы на латинице.
Это просто удобно. Это просто ОЧЕНЬ удобно!
Автоматизируя бизнес-процессы в России, очень удобно именовать все сущности на русском языке. Не пытаться переводить их на английский, зачастую неправильно, не уродовать безумным транслитом. Практически любой большой проект автоматизации на других средствах вызывает порой гомерический хохот при виде наименований объектов и сущностей на латинице. Особенно с учетом того, что часто разработчики не очень хорошо знают английский.
А теперь представьте написание кода, где все сущности именованы на русском, может даже переменные можно именовать на кириллице, но синтаксис самого языка — исключительно латиница! Да вы через неделю активной разработки раздолбаете Ctrl-Shift на клавиатуре, а потом словите нервный срыв!
Я уж не знаю, сам ли Сергей Нуралиев в своё время придумал этот ход, но это оказалось отличной идеей для средств автоматизации учета именно в России. Ну и конечно же это совсем не значит, что как-то ограничивает продукты компании именно Россией, для всех остальных Андрей правильно заметил — всегда есть синонимы на латинице.
Да никто уже 300 лет не вспоминает про русский синтаксис, всем давно уже все равно на двуязычность. Откуда у вас такие стереотипы?
Практически любой большой проект автоматизации на других средствах вызывает порой гомерический хохот при виде наименований объектов и сущностей на латинице.
Либо у вас странное чувство юмора, либо вы видели исключительно какие-то поделки говнокодеров. Сколько разных проектов видел — именование сущностей стандартно делается на английском, этих сущностей не так много и даже не зная английского запомнить их не сложно. А если так уж охота «угореть по русскому» — та же Ява, как пример, давно поддерживает юникод и не запрещает писать все на русском (кроме операторов, само собой).
даже не зная английского запомнить их не сложно
А еще, не зная английского можно называть классы VypuskProduktsii, BillData, имея в виду BillDate и даже KladovshikAccessRights, имея в виду вообще хер знает что.
Что, не попадались такие вещи от серьезных профессионалов своего дела, которые не марают руки об 1С?
От серьезных нет, не встречалось. Обычно это стиль джунов, вчерашних студентов, и за такое именование в нормально поставленном процессе на ревью их постоянно бьют по рукам и заставляют переименовывать. Если вижу такое в коде — это один из основных признаков новичка. Сейчас даже не зная английского (что довольно странно для разработчика — не знать его на уровне хотя-бы чтения документации) не составляет никакой проблемы подобрать перевод с помощью того-же гуглопереводчика или словаря, хотя-бы. Да просто спросить, обычно разработчики не в вакууме пишут, спросить у соседа как лучше назвать «ВыпускПродукции» — это не «зашквар».
С помощью гугла переводчика коллеги перевели название документа «Забор», имелось ввиду — забор груза, как fence.
Сейчас даже не зная английского
Знание языка знанию языка рознь.
Вы можете свободно общаться в магазине или на рынке по английски, но не знать терминов скажем химических.
Уже не говоря, что в разных регионан могут быть свои особенности названий.
Даже в пределах одного города не общеупотребимые термины сильно отличаются по применению. Неоднократно встречал, когда на предприятиях стабильные коллективы давным давно придумали себе «птичий язык» для частоупотребляемых понятий.
Привет вселенной розовых пони! В нашей вселенной во всех российских банках в Java-коде и в базах данных творится совершенно другое. Там идентификаторы в лучшем случае через гугл-транслейт написаны. Плюс ещё терминология бизнеса не совпадает с обратным переводом. И именно поэтому в банках трудятся тысячи аналитиков — если по-честному, то половина их работы разбараться в этой мешанине из идентификаторов.
Аналогично. Русскоязычные аналитики пишут англоязычные слова в спецификациях на разработку, понимание терминологии (а стало быть смысла задачи) съезжает куда-то в пропасть, т.к. писанину аналитика берет потом такой же русскоязычный джава кулхакер и пишет код, как он понял термины и задания, а потом они начинают друг-с-другом общаться (на русском) и выяснять, что каждый из них видит в спецификации. А говнокод и бардак у 1С-ников, ага
Ну да, а если эти говнокодеры перейдут на русский, то все у них в момент наладиться и пони порозовеют, ага.
Как ни странно, они станут хотя бы лучше понимать о чем задача. После ухода из области 1С я постоянно наблюдаю жалкие потуги команд изъясняться в семантическом поле ломаноанглийских идентификаторов. Это печально и такого никогда не происходит на обсуждении задач в командах 1С-ников.
Ну да, а если эти говнокодеры перейдут на русский, то все у них в момент наладиться и пони порозовеют, ага.
Исчезнет ненужно для внутрироссийской разработки лишнее звено, которое превращает процесс в детскую игру «испорченный телефон» (когда выстраиваются в цепочку и на ухо по очереди передают друг другу фразу, что к концу цепочки преобразуется в нечто странное).
Следовательно, качество результата (скорость его получения) улучшится, да.
Одно дело когда вы можете однозначно спросить у представителя предметной области просто произнеся пусть непонятный вам термин, но правильный.
Другое дело, когда вы переводите его с английского с искажением смысла.
Проблем нет только в общекомпьютерной терминологии, в универсальной терминологии, в простейших понятиях.
А стоит погрузиться в предметную область — все становится очень и очень непросто.
Даже профессиональный переводчик, если он не специализируется на этой области — и тот переведет некорректно.
Что же от программистов ожидать, у которых первичный навык должен быть совсем иным — все же программирование первичный навык.
Сколько разных проектов видел — именование сущностей стандартно делается на английском, этих сущностей не так много и даже не зная английского запомнить их не сложно.
1) Ну это вы такие проекты видели. Я вот видел наименования сущностей на итальянском и французском — это жесть, работать невозможно, если ты языка не знаешь.
2) А еще зачастую встречал, когда из-за слабого знания языка термины прикладной области или воспринимаются программистами с ошибками (что вообще страшно) или попросту разработка идет крайне медленно.
Ваша ситуация когда все просто — когда речь идет об универсальных терминах. Стоит копнуть глубже, погрузившись в предметную область (если эта область не ИТ), то все — приехали, вокруг вас фактически иероглифы. И вроде бы разжеванное другим разработчиком длинное название метода/класса/переменной дает вам не больше понимания о программе, чем просто i1, i2, i3.
Если вы не разбираетесь в предметной области, то тут и знание языка не сильно поможет и придется в ней разбираться, или не лезть в код, который совсем не понимаешь. Тут, возможно, скорее даже лучше когда человек видит что он совсем ничего не понимает, чем ложное ощущение понятности кода из-за знакомых слов. Непонимание хотя-бы заставит разобраться и быть осторожнее с правками.
Если вы не разбираетесь в предметной области, то тут и знание языка не сильно поможет
Программист + разбирающийся в предметной области + на не родном языке = золото в количестве веса тела этого программиста.
В подавляющем большинстве все гораздо-гороздо проще.
Речь то о том, что использование родного языка позволяет худо-бедно, но разбираться даже в той предметной области, что ты знаешь не идеально.
P.S.:
Согласно вашей формулировке программист заведомо более квалифицирован чем любой другой специалист в предметной области, так как программист должен знать предметную область + программирование.
А это не так.
Если вы не разбираетесь в предметной области, то тут и знание языка не сильно поможет и придется в ней разбираться, или не лезть в код, который совсем не понимаешь. Тут, возможно, скорее даже лучше когда человек видит что он совсем ничего не понимает, чем ложное ощущение понятности кода из-за знакомых слов. Непонимание хотя-бы заставит разобраться и быть осторожнее с правками.
Э неет, не согласен. Так приятно, конечно думать, будучи программистом, но это не так. Программист должен разбираться в предметной области, что-бы говорить на одном языке со специалистами, так-же как и взаимодействующим с разработчиками специалистам полезно хоть немного быть в теме. Но уровень этого «разбираться» может быть разным. Даже среди узких специалистов нет одного уровня квалификации — всегда кто-то лучше, кто-то хуже разбирается, а того что просто разбирается в предмете, но не является специалистом, называть заведомо более квалифицированным — это не корректно.
Не понял, зачем вы ко мне процитировали это, где вы у меня это нашли:
Это вообще не ко мне вопрос.
Но вот на это отвечу:
В идеале, — да.
Фактически — такой программист автоматически становится золотым. Ибо он «специалист по предметной области» + «еще и программист».
Именно поэтому в серьезных проектах, где цена подобных специалистов зашкаливала бы — и существую специальные методологии постановки задачи.
Чтобы человек даже не разбирающийся в предметной области, мог бы задачу выполнить корректно.
Но хотя бы минимальное знание предметной области — крайне желательно, да. Однако на практике — это очень преочень минимальное знание. Только чтобы могли хотя бы побеседовать (в данном контексте — с бухгалтерами).
То, что «программист должен знать бухгалтерские проводки» — это ошибочное суждение. Бухгалтер должен говорить программисту какие проводки в каком случае. Программист должен только знать слово проводка.
А скажем приведенный мною пример «Вычет на ребенка с налога на доходы физических лиц», который может встретиться где-то в переменной — нужен как раз для того, чтобы программист смог спросить у бухгалтера — а что это такое и как это считать.
Но если данный термин будет на английском из-за какого-то дурацкого принципа не программировать с использованием русского языка — то мы получим просто ухудшение качества работы. Знаете такую детскую игру «испорченный телефон», когда по цепочке на ухо друг другу передают какой то смысл, и на другом конце цепочки смысл оказывается искаженным? Вот это оно самое.
Ради чего? Ради того, чтобы показать кому-то как ты круто знаешь английский язык?
Если вы не разбираетесь в предметной области, то тут и знание языка не сильно поможет и придется в ней разбираться, или не лезть в код, который совсем не понимаешь....
Это вообще не ко мне вопрос.
Но вот на это отвечу:
Программист должен разбираться в предметной области
В идеале, — да.
Фактически — такой программист автоматически становится золотым. Ибо он «специалист по предметной области» + «еще и программист».
Именно поэтому в серьезных проектах, где цена подобных специалистов зашкаливала бы — и существую специальные методологии постановки задачи.
Чтобы человек даже не разбирающийся в предметной области, мог бы задачу выполнить корректно.
Но хотя бы минимальное знание предметной области — крайне желательно, да. Однако на практике — это очень преочень минимальное знание. Только чтобы могли хотя бы побеседовать (в данном контексте — с бухгалтерами).
То, что «программист должен знать бухгалтерские проводки» — это ошибочное суждение. Бухгалтер должен говорить программисту какие проводки в каком случае. Программист должен только знать слово проводка.
А скажем приведенный мною пример «Вычет на ребенка с налога на доходы физических лиц», который может встретиться где-то в переменной — нужен как раз для того, чтобы программист смог спросить у бухгалтера — а что это такое и как это считать.
Но если данный термин будет на английском из-за какого-то дурацкого принципа не программировать с использованием русского языка — то мы получим просто ухудшение качества работы. Знаете такую детскую игру «испорченный телефон», когда по цепочке на ухо друг другу передают какой то смысл, и на другом конце цепочки смысл оказывается искаженным? Вот это оно самое.
Ради чего? Ради того, чтобы показать кому-то как ты круто знаешь английский язык?
По поводу цитаты — извините, копипаста вслепую иногда приводит к таким казусам :)
Там должно было быть
Там должно было быть
P.S.:
Согласно вашей формулировке программист заведомо более квалифицирован чем любой другой специалист в предметной области, так как программист должен знать предметную область + программирование.
Я с вами в принципе согласен, по поводу квалификации, не должен программист в проводках разбираться лучше бухгалтера. Но вот когда я этим занимался — насмотрелся на… «девочек» бухгалтерш, которые в бухучете разбирались хуже меня (а я в нем тоже не был знатоком). Впрочем это загоняет дискуссию уже совсем в какие-то дебри.
Согласен, я слышал от одного главного бухгалтера такое мнение: «бухгалтер не обязательно должен знать проводки, есть же программа, она должна правильно все сделать». Мои попытки возразить — не увенчались успехом.
Ага, и классика жанра — «Опять ваша дурацкая 1С все не правильно посчитала, а мне завтра отчет сдавать, ААААААААААААААААААААААА!!!!!!!!»
Потом выясняется что «специалист» просто «не умеет в бухучет», как сейчас принято говорить, и начинаешь терпеливо преподавать истерящей даме краткий курс бухучета (при том что сам в нем не то что-бы очень..) Жуть! Как вспомню, так вздрогну, слава богу теперь этим не занимаюсь.
Потом выясняется что «специалист» просто «не умеет в бухучет», как сейчас принято говорить, и начинаешь терпеливо преподавать истерящей даме краткий курс бухучета (при том что сам в нем не то что-бы очень..) Жуть! Как вспомню, так вздрогну, слава богу теперь этим не занимаюсь.
Но вот когда я этим занимался — насмотрелся на… «девочек» бухгалтерш, которые в бухучете разбирались хуже меня (а я в нем тоже не был знатоком).
Эти бухгалтерши по факту были операторами ввода данных.
Ничего удивительного. Бухгалтера эникеев тоже нередко называют программистами.
«Не так много» ??!!! Охренеть, откройте ERP, хотя нет, давайте попроще, откройте БП как самую простую и посмотрите все сущности.
Много кто поддерживает юникод, только как правильно заметил longmaster через неделю вы раздолбаете Ctrl-Shift (хотя Alt-Shift удобней), а потом проклянете этот проект.
Много кто поддерживает юникод, только как правильно заметил longmaster через неделю вы раздолбаете Ctrl-Shift (хотя Alt-Shift удобней), а потом проклянете этот проект.
Удобнее капс). У меня вот в последнее время левый мизинец немеет и иногда болит, виню то что часто приходилось раскладку переключать))
вот если будете на двух языках писать, то совсем отсохнет
Вот я как раз 4 года и писал на 1с, причем что & что <> вводил именно переключая раскладку а не через alt+38 и подобное.
Видел я и ERP и БД всевозможные, «букв» много, но подавляющее большинство понятий там составлено из относительно небольшого количество слов. Как в любом нормальном ЯП ключевых слов с десяток.
А если буквы посмотреть их вообще 33 штуки, но слов поболее будет.
Как будет на английском «Книга учета доходов расходов» или " Данные о корректировке сведений о застрахованных лиц СЗВ КОРР"
В любой случае писать на том языке на котором говорят пользователи работающие с ПО, намного проще.
Как будет на английском «Книга учета доходов расходов» или " Данные о корректировке сведений о застрахованных лиц СЗВ КОРР"
В любой случае писать на том языке на котором говорят пользователи работающие с ПО, намного проще.
The book of income and expense
Гуглоперевод. Вполне понятный на мой взгляд, не вижу никакой проблемы.
Гуглоперевод. Вполне понятный на мой взгляд, не вижу никакой проблемы.
Перевести на английский словосочетание «Книга учета доходов и расходов» будет затруднительно. У англичан и американцев такую книгу, насколько мне известно, использовать для ведения учета не принято. Учет доходов и расходов обычно ведется отдельно, например в sales ledger и purchase ledger. Более того, набор книг и журналов, используемых для ведения финансового учета коммерческой организации, и формы этих книг и журналов устанавливает сам хозяйствующий субъект по своему усмотрению, а не правительство и не министерство финансов.
Мы говорим о том что бы на английском писать программы для русскоязычных пользователей.
Мы говорим о том что бы на английском писать программы для русскоязычных пользователей.
И практически сразу спотыкаемся. Следите за руками:
Системный аналитик, ставящий задачу, оказывается знакомым с англоязычными терминами предметной области и использовал более правильное
«sales ledger, purchase ledger»
А программист, незнакомый с предметной областью, использовал просто кальку с английского, что дал ему Гуглепереводчик (ну или сам он знает английский без спец. терминов предметной области — наверняка и без Гуглепереводчика так же перевел бы и сам):
«The book of income and expense»
И это еще мы на самой поверхности. В конце концов, «The book of income and expense» с английского Гуглепереводчиком переводится и обратно нормально, я проверил только что.
А теперь берем другой распространенный термин:
«Вычет на ребенка с налога на доходы физических лиц»
Гуглеперевод:
«Deduction per child from personal income tax»
Обратный гуглеперевод:
«Удержание на ребенка с подоходного налога»
Повторим еще раз:
«Child Income Tax Withholding»
Обратно:
«Удержание подоходного налога с детей»
Налога с детей???
Качество гугл-переводчика — это та самая притча…
Полагаться на его перевод в чуть более или менее серьёзных вещах — это стрелять себе в ногу.
Впрочем, говоря на чистоту, тут никто не может похвастаться. Косячит и яндекс, и deepl, и все остальные. Просто перевод основанный на «статистической» модели, или как там Гугл говорил правильно, другим быть не может.
Полагаться на его перевод в чуть более или менее серьёзных вещах — это стрелять себе в ногу.
Впрочем, говоря на чистоту, тут никто не может похвастаться. Косячит и яндекс, и deepl, и все остальные. Просто перевод основанный на «статистической» модели, или как там Гугл говорил правильно, другим быть не может.
Почему-то, эти тупые забугорные программисты не плюются от того что пишут на своём родном языке, а не на «китайском» например)) А русского программиста это почему-то оскорбляет))
Дело вообще не в простоте для новичков. И совсем не в том, что синтаксис на родном языке, и так в чём-то легче.
Это просто удобно. Это просто ОЧЕНЬ удобно!
Из-за отсутствия на русской раскладке некоторых символов пунктуации, что есть только в латинской — есть и неудобства.
Но использование названий объектов прикладной области на языке, что ты знаешь с детства, а не начал учить только в школе — да, это безусловно удобно.
«Вычет на ребенка с налога на доходы физических лиц» в английском переводе только путает программиста, это да.
Если только речь не идет об автоматизации какого-нибудь британского предприятия, коим владеет бывший наш и по ностальгии внедряющий у себя на предприятии 1С.
Согласен:
1) Компания 1С решает свои проблемы и проблемы клиентов за деньги.
2) По оценке рынка специалистов и проблем предприятий с ним
3) 1С это хорошо потому что быстрая отдача для клиента из коробки
Теперь по существу:
1) 1C это не фреймворк, это программа вроде Access, несмотря на сильно расширенный функционал и появление 2 звена в виде сервера предприятия.
2) Не знаю как сейчас, но меня терзают сильные сомнения в знаке равенства между ЕЕ Java и 1С по крайней мере 5-10 лет назад
3) 1С хорошо работает на ларьках и сети ларьков и масштабирует именно на торговых предприятиях. В остальных случаях где бизнес логика сильно отличается от торговли ,1С не работает.Но это не волнует компанию 1С они заботятся о самом крупном и простом секторе рынка — шавермочные и ларьки.
4) Не знаю как сейчас, но несколько лет назад оптимизация SQL, которая позволяла не заботится о квалификации джуна была не сильно лучше запроса, написанного этим самым джуном и на базе в несколько десятков ГБ отчет можно было ждать вечность, но это не расстраивало бизнес которому надо здесь и сейчас и поэтому я лично наблюдал 4ПК подключенных к монитору через KVM с запущенными с утра отчетами, которые вечером можно было послать руководству по почте.
5) В посте описанная простота входа сильно компенсируется тем что программист 1С это 90% технолог\специалист по бизнес логике\ПМ\консультант по работе с 1С
Итого: если торговая компания или около того — хорошо
если нет, то это сильно странный выбор
страна большая и в глубинке фуллстек кодера не найти
Все выше сказанное написано с учетом того что Bitrix это отдельный продукт.
1) Компания 1С решает свои проблемы и проблемы клиентов за деньги.
2) По оценке рынка специалистов и проблем предприятий с ним
3) 1С это хорошо потому что быстрая отдача для клиента из коробки
Теперь по существу:
1) 1C это не фреймворк, это программа вроде Access, несмотря на сильно расширенный функционал и появление 2 звена в виде сервера предприятия.
2) Не знаю как сейчас, но меня терзают сильные сомнения в знаке равенства между ЕЕ Java и 1С по крайней мере 5-10 лет назад
3) 1С хорошо работает на ларьках и сети ларьков и масштабирует именно на торговых предприятиях. В остальных случаях где бизнес логика сильно отличается от торговли ,1С не работает.Но это не волнует компанию 1С они заботятся о самом крупном и простом секторе рынка — шавермочные и ларьки.
4) Не знаю как сейчас, но несколько лет назад оптимизация SQL, которая позволяла не заботится о квалификации джуна была не сильно лучше запроса, написанного этим самым джуном и на базе в несколько десятков ГБ отчет можно было ждать вечность, но это не расстраивало бизнес которому надо здесь и сейчас и поэтому я лично наблюдал 4ПК подключенных к монитору через KVM с запущенными с утра отчетами, которые вечером можно было послать руководству по почте.
5) В посте описанная простота входа сильно компенсируется тем что программист 1С это 90% технолог\специалист по бизнес логике\ПМ\консультант по работе с 1С
Итого: если торговая компания или около того — хорошо
если нет, то это сильно странный выбор
страна большая и в глубинке фуллстек кодера не найти
Все выше сказанное написано с учетом того что Bitrix это отдельный продукт.
Я, конечно, заапрувил комментарий, но все что в нем написано, это настолько мимо кассы, что аж слов нет.
Это реальная компания, которая страдала от 1С, точнее от того что 1С не заточена под крупный бизнес. Мы же о реальном бизнесе на реальной земле и о том как 1С заботится о этом бизнесе. Помню как после обновления сервер предприятия перестал падать 2-3 раза в день, и в этом обновлении появились процессы(там был странный алгоритм смерти и рождения этих процессов) в этом сервере предприятия, но падать он не перестал, просто падал реже, а бизнес тот круглосуточный и в договорах за простои штрафы. Вы ведь заметили что я обсуждаю продукт из коробки, главную модель продажи 1С? Другая компания в этом же холдинге изначально использовала Oracle на самом нагруженном по данным направлении и не знала таких проблем.
Я намекаю на то, что надо очень криво и через одно место внедрить 1С, чтобы наблюдать описываемые вами эффекты. Набрать студентов за доширак, например, а бюджет внедрения попилить...
Да да да. Я тут как то яндекс моней дей ходил и на мой вопрос -«а почему в платежке распечатанной нет информации о платеже и плательщике?» мне ответили что это баги. Вот и вы заняли странную позицию. Я же четко написал что после апдейта оно падать перестало само собой.Да и конфа там была почти полностью топовой т.к. от программистов было одно название. Да и к счастью российского бизнеса сервер 1с предприятия это не оракл с его десятками сертификаций и там. А отрицать главное конкурентное преимущество 1с такое как набрать студентов за доширак не стоит. Вы видимо давно джунов не искали по рынку.
Помню как после обновления сервер предприятия перестал падать 2-3 раза в день, и в этом обновлении появились процессы в этом сервере предприятия, но падать он не перестал, просто падал реже, а бизнес тот круглосуточный и в договорах за простои штрафы. Вы ведь заметили что я обсуждаю продукт из коробки, главную модель продажи 1С?
Вряд ли тут проблема самой 1С.
Мне кажется, что тут проблема в конкретных специалистах.
Возможно, в руководстве, что не одобрила финансирование решений на другой платформе/глубокую доработку 1С.
Возможно, в технических специалистах.
Например, такое часто бывает при бурном росте, когда вчера ты был эникей, сегодня сисадмин, а завтра начальник отдела ИТ, но знания у тебя так фантастически не выросли, как название твоей должности/зарплата.
Другая компания в этом же холдинге изначально использовала Oracle на самом нагруженном по данным направлении и не знала таких проблем.
Узкоспециализированное решение (написанное грамотным разработиком конечно) завсегда будет иметь преимущество в этом пункте перед решением универсальным.
Другое дело, что узкоспециализированное быстрое решение — еще и малофункциональное и не гибкое. И разработка/доработка его не дешёва и не быстра (кроме самый примитивных ситуаций).
Поэтому нужно балансировать:
Когда-то выгоднее использовать уже готовое универсальное,
а когда выгоднее узкоспецилизированное созданное под конкретную задачу.
А если вы намекаете что 1С это не продукт, а платформа, то давайте попробуем внедрить ее в телекоме ну например попробуем заменить Zabbix или что нибудь еще. Для упрощения задачи агенты мониторинга предлагаю оставить любые левые.
Здесь намекает автор, что вы вообще не поняли статью.
То, что вы высказываете свою боль — это понятно. Но не по теме данной статьи.
Одно дело обсуждать Фреймворк, другое дело обсуждать «компанию» и третье дело обсуждать какой-то конкретный неназванный продукт (приложение, конфигурацию) написанную на этом фреймворке.
То, что вы высказываете свою боль — это понятно. Но не по теме данной статьи.
Одно дело обсуждать Фреймворк, другое дело обсуждать «компанию» и третье дело обсуждать какой-то конкретный неназванный продукт (приложение, конфигурацию) написанную на этом фреймворке.
Автор написал свое видение, я с ним не согласился по тому что счел в его описании важным. А посте было и стратегии компании и ее политике и то что важно для нее и ее клиентов. Как бы какая статья такой комент, в статье не только аксесс\фреймворк обсуждался.
А боль не моя кстати, а клиентов 1С.И тех кто с 1С работает, т.к. они никак не могут повлиять на стабильность работы сервера 1С предприятия и остается молиться на следующее ежемесячное обновление.
А боль не моя кстати, а клиентов 1С.И тех кто с 1С работает, т.к. они никак не могут повлиять на стабильность работы сервера 1С предприятия и остается молиться на следующее ежемесячное обновление.
Статью не читали, да? Там четко написано где не надо делать на 1С
В остальных случаях где бизнес логика сильно отличается от торговли ,1С не работает
А зачем брать в качестве основы для такого бизнеса торговую конфигурацию от 1С?
Полно же специализированных решений.
Да и торговля — для многих видов деятельности вполне универсальный механизм.
Лично адаптировал торговые конфигурации под различные производства, к примеру. Там львинная доля кода все так же переиспользуется.
Самые серьезные доработки только для одного единственного документа «Выпуск продукции с расчетом издержек». Очевидно, что в торговой конфигурации такого нет.
В ответ на вопрос: а зачем: тут решает доступность специалиста. Внедрять и поддерживать изначально специализированное решение, но с которым никто не знаком в ближайшем окружении — далеко не всегда выгоднее, чем просто допилить под себя то, что ты уже знаешь.
Но не спорю, что, разумеется, всегда можно найти сферу деятельности под которую 1С не годится.
Есть масса вещей, которые не торговля и не производство. Представьте, допустим, РЖД и попробуйте угадать где кроме бухгалтерии используется 1С и сколько там всего что не укладывается в конфигурации 1с.
Более того, я нигде не сказал, что надо делать все и на 1С. Я как раз сказал ровно обратное
Я не против вашей статьи в целом, просто заагрился на то что вы назвали 1С — фреймворк \среда разработки(«Считайте, что это Spring или ASP.NET, выполняемый некоторой средой выполнения (JVM или CLR соответственно).»).
Разве эта аналогия неверна? В каком месте?
Дело в том, что 1С и является фреймворком)
Представьте, допустим, РЖД
О. Да вы типичный пример привели. Серьезно. Типичный?
Не стоит переживать за РЖД при их-то финансовых возможностях.
Впрочем я на это ваше высказывание уже ответил заранее:
habr.com/en/post/480658/#comment_21028022
Но не спорю, что, разумеется, всегда можно найти сферу деятельности под которую 1С не годится.
Тогда возьмем итог статьи где сказано — «1С это фреймворк быстрой разработки приложений (RAD) для бизнеса и заточен под это.»
РЖД бизнес? 1С Фреймворк?
зачеркните лишнее.
РЖД бизнес? 1С Фреймворк?
зачеркните лишнее.
Нуу… софт для томографов это тоже бизнес. И для авиации. Но это же не значит, что туда надо ставить 1С. Я не верю что вы недостаточно умны, чтобы понять ложность собственной аналогии.
Ок, разжую. Вот есть объекты в ООП, но суть не в этом, вот если основные объекты бизнес логики это не документ\отчет\печатная форма\продажа, то 1С не вариант.
Приведи пример объекта бизнес логики, который не ложится на абстракцию 1С.
Все кроме продаж\бухгалтерии, не?
Нравятся мне люди, аргументирующие словом "всё" на просьбу назвать что-то конкретное )
Откуда вы такое берете вообще?
Есть четкая методика того какие объекты 1С для каких задач надо использовать.
https://its.1c.ru/db/v8std#content:683:hdoc
Любые бизнес процессы компании и большинство механизмов автоматизации не связанные непосредственно с бизнес процессами ложатся на эти объекты, если не все. На 1С можно автоматизировать что угодно, от учета бензина на заправке с автоматическим считыванием датчиками состояния в цистернах до полной роботизированной автоматизации складского учета.
Вот, например, ребята мобильное приложение для отслеживание занятий фитнесом сделали https://play.google.com/store/apps/details?id=com.rarus.gyms
Кто-то делает планировщик занятий в университете.
Кто-то делает управление картотеками и библиотеками.
Производство. Строительство. Медецина. Сельское хозяйство. Культура. Оказание услуг. CRM. Управление зарплатой и кадрами. Управление проектами (вот, например, открытый проект https://github.com/BlizD/Tasks управления задачами с канбан доской).
Системы управления инфраструктурой и мониторингом серверов.
Да почти любые бизнес задачи можно решить.
Опять же, что не стоит решать на 1С отлично написано в статье.
У меня была возможность пойти по пути темной стороны еще в те времена когда v8 на горизонте не предвиделось.Да сейчас понимаю что тогда над было становиться франшизером и стричь бабло, но не судьба, я тогда увлекся юниксом, сайтиками и много чем еще т.к. мне тогда сильно не понравились приколы с изменением задним числом и перепроведением(так вроде называлось) базы и косяки с остатками если это перепроведение падало на 3 дне и это мне досталось от франчайзи. Хотя речь не о франчайзи, а о странной бизнес логике типовой конфы исправления задним числом (торговля и склад) и последующих мучительно долгих перепроведениях.Т.е. если я правильно понял остатки меняются если документ создан\исправлен в определtнном интервале дат, если это было давно, то крути верти документами как хочешь, остатки те же- «как те такое Илон Маск?»
Это я все к тому что смотреть эти красивые картинки и буклеты желания нет.
Это я все к тому что смотреть эти красивые картинки и буклеты желания нет.
Хотя я вспомнил почему 1С такая, весь бизнес изначально был построен на торговле подпиской ИТС и чем глючнее софт тем охотнее подписку берут, в то время контролировать лицензии или пиратство было очень затруднительно.
весь бизнес был построен совсем на другом и ИТС появилась очень сильно потом, когда рынок уже был захвачен. Тогда подписочная модель обновлений 1С всех возмутила. А сейчас MS Office и антивирусы по подписке и вроде как никто не удивляется...
Как минимум в трех аэропортах используется система на базе 1С, которая выводит данные на табло в терминалах, озвучивает с помощью движка text-to-speech аудиооповещения, обменивается данными с сайтами, принимает и отправляет телеграммы авиакомпаниям и много чего еще…
У меня есть знакомый программист, его основная задача интегрировать обмен из разных сторонних приложений в 1С и обратно. И это страшное слово ОБРАБОТКА, которое призвано решать все проблемы обмена между приложениями с помощью ТЕКСТОВЫХ ФАЙЛОВ. Полагаю там то же нечто подобное практикуется.
Темный у вас знакомый, сейчас можно использовать RabbitMQ.
Хотя в прочем 1С работает и с другими механизмами интеграций
https://v8.1c.ru/platforma/integraciya/
У нас с вами уже как то был в телеге спор на тему того что 1с принудительно заставляет партнеров кто новую коробку делает по 1с: совместно лепить обмен через КД, а КД это файлы. И даже несмотря на то что есть возможность якобы через веб сервисы работать — и там тоже файл. Потому что коробка. Потому что нужно чтобы было как все давно привыкли и более современные подходы — ни-ни. Причем из за специфики именно КД 2, хотя конфа только совсем недавно разрабатывалась. Что там сейчас кстати с кастомизацией enterprise data для КД 3, это разрешено при разработке коробок?
Простите, КД это «сериализация в XML по определенным правилам». Транспорт обмена в БСП, если я ничего не путаю, это не только файлы, а еще и веб-сервисы, например.
КД 3 не является «улучшенной версией» и заменой КД 2, в общем случае. Это по сути другой продукт, с другими задачами.
КД 3 не является «улучшенной версией» и заменой КД 2, в общем случае. Это по сути другой продукт, с другими задачами.
Вот только по веб сервисам передаются ровно те же файлы, о чем я выше писал. Причем эти файлы расчитаны только на 1с, чтобы читать их из других систем — придется те еще костыли городить а хотелось при разработке сделать все таки достаточно универсальный рест апи для того чтобы сторонние, в т.ч. не 1сные системы подключались без особых проблем. Но нельзя.
Ну дык… unix way «все это файл» и все такое.
С учетом того, что в них кроме просто данных, может содержаться еще и логика обработки их в приемнике, ничего удивительного.
Это, согласитесь, не совсем претензия, что для обмена 1С-1С нужно использовать 1С. Если обмен 1С-«Что-то», то да, КД не лучший вариант, но по крайней мере знакомый неизвестному 1С-нику, который будет решение обслуживать/внедрять.
Причем эти файлы расчитаны только на 1с
С учетом того, что в них кроме просто данных, может содержаться еще и логика обработки их в приемнике, ничего удивительного.
Это, согласитесь, не совсем претензия, что для обмена 1С-1С нужно использовать 1С. Если обмен 1С-«Что-то», то да, КД не лучший вариант, но по крайней мере знакомый неизвестному 1С-нику, который будет решение обслуживать/внедрять.
С учетом того, что в них кроме просто данных, может содержаться еще и логика обработки их в приемнике, ничего удивительного.
Вот про это я и говорю. Это настолько дико повышает зацепление систем — что ужас просто. Страшно с этим работать. Чтобы интегрироваться с какой то системой мало знать свою систему и прочесть просто документацию по api чужой, нужно еще разобраться в чужой бизнес логике, чужой организацией и хранением данных, а потом связать правилами обмена две системы в дикий клубок.
Не говоря уж о необходимости после каждого обновления проверять на актуальность, хотя нормальный api сохраняет стабильность довольно долго ибо есть возможность сохранять контракт при изменении внутренностей.
Для решения этой проблемы как раз КД 3 и делали.
НО! надо понимать, что вот все эти готовые инструменты (при всем их удобстве), это реверанс в сторону типовых конфигураций на поддержке и попытке снизить порог требований к поддержке.
Я сам не большой фанат КД или, допустим, БСП, но вполне понимаю плюсы обоих решений.
НО! надо понимать, что вот все эти готовые инструменты (при всем их удобстве), это реверанс в сторону типовых конфигураций на поддержке и попытке снизить порог требований к поддержке.
Я сам не большой фанат КД или, допустим, БСП, но вполне понимаю плюсы обоих решений.
А вот КД 3 раздражает залоченным по сути форматом, насколько я помню ситуацию.
Потому что он другую проблему решает — обмен опять же между/с типовыми, без необходимости переписывать правила в обеих базах, если одна из конфигураций изменилась.
В КД 3 можно добавлять свои поля в существующие схемы. Опять же — решение для вполне конкретного круга задач.
В КД 3 можно добавлять свои поля в существующие схемы. Опять же — решение для вполне конкретного круга задач.
А если в формат не вписываешься — беда. Нормального способа сделать обмен и угодить 1с нет.
Что значит «не вписываешься»? КД 3 это обмен между базами конкретными видами документов.
Вашему решению с чем нужно было обмениваться и какими данными? Можно в общих чертах, без конкретики.
Но в неком абстрактном случае (обмен с типовой, нестандартными данными и необходимость получения шильдика от 1С) — да, возможно и нет более «нормального» метода, чем использовать КД 2, со всеми его минусами.
Вашему решению с чем нужно было обмениваться и какими данными? Можно в общих чертах, без конкретики.
Но в неком абстрактном случае (обмен с типовой, нестандартными данными и необходимость получения шильдика от 1С) — да, возможно и нет более «нормального» метода, чем использовать КД 2, со всеми его минусами.
Данные об оборудовании, ремонтах, наработке оборудования, статистике отказов, выявленных дефектах, критичности этого дела, плюс еще что то в таком духе, уже больше года прошло, не помню уже ничего. Обе конфы наши 1С: ТОИР <-> 1С:RCM
Как я понимаю, тут КД 3 не подходит в принципе.
КД 2, с учетом того, что это обмен между вашими (как компании-разработчика) коробочными решениями, как раз-таки подходит отлично.
В такой ситуации не совсем понятно возмущение о необходимости «разобраться в чужой бизнес-логике». Даже проблем при обновлении не будет — если правила «сломались», то вы сами и виноваты в изменении конфигурации.
КД 2, с учетом того, что это обмен между вашими (как компании-разработчика) коробочными решениями, как раз-таки подходит отлично.
В такой ситуации не совсем понятно возмущение о необходимости «разобраться в чужой бизнес-логике». Даже проблем при обновлении не будет — если правила «сломались», то вы сами и виноваты в изменении конфигурации.
Т.е. о разработчиках что будут внедрять решение заботиться не нужно. Ну как бы да, у вендора тоже заботы о разработчиках 0, но это же не значит что должны все так же поступать.
Возможно решения будут внедряться отдельно (хотя немного маловероятно), интеграция будет не с 1с системой, у кого то уже будет стоять сильно доработанная система другого релиза и ее нужно будет интегрировать с новой версией другой системы. Проблем можно горы найти.
Возможно решения будут внедряться отдельно (хотя немного маловероятно), интеграция будет не с 1с системой, у кого то уже будет стоять сильно доработанная система другого релиза и ее нужно будет интегрировать с новой версией другой системы. Проблем можно горы найти.
Нет, как раз 1С и заботится о разработчиках, которые будут внедрять систему, поэтому и требует чтобы вы использовали стандартный способ обмена 1С-1С — Конвертацию данных. Которую условный средний 1С-ник знать должен. А вот специфический экзотический обмен, который вы придумаете — не обязательно.
Причем еще раз повторимся, для тех, кто будет это читать и не в курсе (я вот специально проверил сейчас), что такое «1С: Совместно» — это по сути набор требований от компании 1С к продуктам, которые кто-то хочет включить в общий прайс по всей партнерской сети 1С. При этом 1С еще и обязуется, что в случае если компания-разработчик вдруг исчезнет, взять решение на поддержку. Логично, что появляется требование к стандартам и используемым инструментам.
Не хотите продавать решение через партнерскую сеть? Ок, можете не использовать КД 2.
Причем еще раз повторимся, для тех, кто будет это читать и не в курсе (я вот специально проверил сейчас), что такое «1С: Совместно» — это по сути набор требований от компании 1С к продуктам, которые кто-то хочет включить в общий прайс по всей партнерской сети 1С. При этом 1С еще и обязуется, что в случае если компания-разработчик вдруг исчезнет, взять решение на поддержку. Логично, что появляется требование к стандартам и используемым инструментам.
Не хотите продавать решение через партнерскую сеть? Ок, можете не использовать КД 2.
Ну, видимо у нас разные понятия о заботе о программистах)
Смотрите, какая получается ситуация.
Есть компания А — вендор платформы и владелец большой партнерской сети. Есть компания Б — на этой платформе делающая решение.
Компания Б хочет, чтобы компания А продавала ее решение через свою партнерску сеть + дала повесить на нее шильдик «Проверено вендером — Решение качественное» + взяла на себя риски поддержки этого решения, если вдруг компания Б исчезнет (понятно, что исчезать не планирует, но поддержка от вендора это еще один плюсик в глазах потенциального покупателя).
Компания А в ответ, предъявляет документ, которыей можно найти у нее на сайте, в которых описаны стандарты и критерии соответствия продукта шильдику «Проверено».
Пока у вас вопросов нет? С точки зрения бизнеса, без разницы причем, это делает 1C/Google/Apple/Microsoft или кто-то еще.
Откуда появился этот список требований? А именно из условия «гарантируем поддержку» и «утверждаем что решение качественно», соответственно, требуется, чтобы код был написан в соответствии со стандартами вендора, не использовались недокументированные возможности платформы и максимально использовались типовые инструменты.
Цель — забота о тех людях, которым придется поддерживать решение, тех кому придется решение внедрять и использовать, ну и о себе как о бизнесе, куда уж без этого.
Что конкретно в этой ситуации вас не устраивает?
Есть компания А — вендор платформы и владелец большой партнерской сети. Есть компания Б — на этой платформе делающая решение.
Компания Б хочет, чтобы компания А продавала ее решение через свою партнерску сеть + дала повесить на нее шильдик «Проверено вендером — Решение качественное» + взяла на себя риски поддержки этого решения, если вдруг компания Б исчезнет (понятно, что исчезать не планирует, но поддержка от вендора это еще один плюсик в глазах потенциального покупателя).
Компания А в ответ, предъявляет документ, которыей можно найти у нее на сайте, в которых описаны стандарты и критерии соответствия продукта шильдику «Проверено».
Пока у вас вопросов нет? С точки зрения бизнеса, без разницы причем, это делает 1C/Google/Apple/Microsoft или кто-то еще.
Откуда появился этот список требований? А именно из условия «гарантируем поддержку» и «утверждаем что решение качественно», соответственно, требуется, чтобы код был написан в соответствии со стандартами вендора, не использовались недокументированные возможности платформы и максимально использовались типовые инструменты.
Цель — забота о тех людях, которым придется поддерживать решение, тех кому придется решение внедрять и использовать, ну и о себе как о бизнесе, куда уж без этого.
Что конкретно в этой ситуации вас не устраивает?
Вы сами прекрасно ответили, забота о бизнесе и заказчиках. То что разработчикам в 90% подобных случаев было бы удобнее с мессадж брокерами или рест апи работать, ибо позволило бы унифицировать и документировать интерфейсы, что часто упростило бы разработку и поддержку — вендору на удобство конечных разработчиков все равно.
Вы почему-то проблемы компании, в которой работали, приписываете 1С. Это не 1С просила разрешить включить ваше решение в свой прайс, а ваш работодатель туда просился. Он мог бы разрешить вам реализовывать интеграцию как угодно, но справедливо понимал, что решение будет лучше продаваться, если договориться с вендором платформы.
И второе. Каким именно разработчикам, в 90% случаев было бы удобнее работать с мессадж брокерами, и протоколами, которые придумала ваша компания, если они все умеют (или должны уметь) работать с КД и на КД построены обмены в типовых (и многих не типовых решениях)? Вы опять путаете «разработчикам было бы интересно разобраться» и «разработчикам было бы удобнее/проще/быстрее».
Я сейчас не говорю о том, что КД лучшее решение, ни разу. Даже в решении «1С: Интеграция», которое вполне себе «1С: Совместимо», правила КД появились не сразу, насколько я знаю. Сначала там вообще использовались XSLT преобразования и это обозначалось как «плюс».
И второе. Каким именно разработчикам, в 90% случаев было бы удобнее работать с мессадж брокерами, и протоколами, которые придумала ваша компания, если они все умеют (или должны уметь) работать с КД и на КД построены обмены в типовых (и многих не типовых решениях)? Вы опять путаете «разработчикам было бы интересно разобраться» и «разработчикам было бы удобнее/проще/быстрее».
Я сейчас не говорю о том, что КД лучшее решение, ни разу. Даже в решении «1С: Интеграция», которое вполне себе «1С: Совместимо», правила КД появились не сразу, насколько я знаю. Сначала там вообще использовались XSLT преобразования и это обозначалось как «плюс».
Это не проблемы моего прошлого франча что 1с загоняет партнеров палками в прошлый век? Как раз то что все работает на КД и конца и края этой порочной практике не видно — и показывает отсутствие заботы о разработчиках. Использовать такие решения как основные — это боль. Обязательно нужно знать обе конфигурации. Обязательно следить за версиями и доработками, для каждой пары разных конфигураций свои правила и прочее подобное.
Ну и никто не говорит про свои протоколы, нормальные документированные рест апи с json/xml например. Или MQ — тоже документировать и только в путь.
Даже если разработчику потребуется расширить интерфейсы обмена — поддерживать их будет все равно гораздо проще чем правила.
Ну и никто не говорит про свои протоколы, нормальные документированные рест апи с json/xml например. Или MQ — тоже документировать и только в путь.
Даже если разработчику потребуется расширить интерфейсы обмена — поддерживать их будет все равно гораздо проще чем правила.
1с загоняет партнеров палками в прошлый век
Да не загоняет никого 1С. Тут скорее «не дают из каменного века выйти», причем в конкретной ситуации — «у нас вот есть партнеры, они умеют в КД, есть клиенты, у которых специалисты точно умеют в КД и пачка типовых, в которых из коробки есть КД, хотите чтобы ваш продукт вместе с ними продавался — используйте КД».
Вы ведь понимаете, что если вы будете использовать нестандартный обмен, то его придется прикручивать во все типовые/отраслевые/другие «1С: Совместимо/Совместно» и придется заставлять партнеров изучать то, что вы придумали. Это не вариант от слова «совсем». Тем более «поддерживать будет гораздо проще, чем правила» — вам возможно будет проще.
Мне тоже было проще сделать свой обмен в ряде случаев (хотя как минимум в одном стоило воспользоваться форматом Enterprise, т.к. приемником была типовая БП3 на поддержке), но среднему 1С-нику это нафиг не нужно и ему это не проще. Да блин, даже среднему не-1Снику проще XML-ки гонять, а не MQ изучать.
Вот вы не лестно отзывались об Apple. Представьте ситуацию, вы делаете какой-нить модный фитнес-браслет, приходите с ним к Тиму Куку и говорите, «а давайте назовем его Apple SuperWatch, наклеим на него значок яблочка и продавать вы его будете в своих фирменных магазинах. но есть один нюанс — он работает только с телефонами Android». Вы понимаете, куда он вас пошлет с такой идеей?
Вы снова смотрите с т.з. бизнеса и с т.з. именно текущей ситуации. Да, это выгодно, но разработчикам менее удобно. Разработчикам было бы проще сделай 1с новую технологию. Да хотя бы более полноценный механизм расширения enterprise data позволяющий именно что каждой конфигурации декларировать поверх стандартного набора (либо набора чужой конфигурации) не просто новые поля, но новые данные. Да транспорт модифицировать для более удобной интеграции не 1сных систем — и то хлеб был бы, лучше чем то что сейчас.
Вы смешиваете два несвязанных вопроса:
— развитие платформы/решений и
— конкретную специфическую сертификацию решения.
1С как разработчик платформы добавляет поддержку JSON.
1С как разработчик решений выпускает «1С: Интеграцию» (кстати, работает не только через КД 2, и при этом имеет статус «1С: Совместно», так что дискуссия наша вообще странно выглядит — получается, что вы могли делать обмен как угодно, при условии наличия в конфигурации подсистемы из БСП) и «Конвертацию 3».
1С как поставщик решений, поддерживает существующий обмен с правилами КД2 и исходя из существующих и использующихся решений, требует (для сертификации по «1С: Совместно») использование КД2.
— развитие платформы/решений и
— конкретную специфическую сертификацию решения.
1С как разработчик платформы добавляет поддержку JSON.
1С как разработчик решений выпускает «1С: Интеграцию» (кстати, работает не только через КД 2, и при этом имеет статус «1С: Совместно», так что дискуссия наша вообще странно выглядит — получается, что вы могли делать обмен как угодно, при условии наличия в конфигурации подсистемы из БСП) и «Конвертацию 3».
1С как поставщик решений, поддерживает существующий обмен с правилами КД2 и исходя из существующих и использующихся решений, требует (для сертификации по «1С: Совместно») использование КД2.
Ладно, дальше уже по десятому кругу продолжим друг другу одно и то же повторять. Я продолжу говорить что с т.з. добавления удобства разработчикам 1с не делает ничего почти и намеренно сохраняет неудобные технологии из бизнес целей, вы что 1с из бизнес целей выгодно сохранять текущие механизмы которые уже выучила куча разработчиков которых можно найти в каждом селе.
Но вообще ветка началась с того что человек из 1с пеняет другому комментатору что есть уже более современные технологии и их используют, на что я возвразил что вендором эти технологии никак не освещаются и не продвигаются, а вместо этого вендор продвигает старые механизмы. Хотя уверен, даже если в БСП таки встроят кролика или другого брокера как транспорт — все равно по прежнему будет все реализовано на правилах обмена стандартных которые приносят горы боли.
Но вообще ветка началась с того что человек из 1с пеняет другому комментатору что есть уже более современные технологии и их используют, на что я возвразил что вендором эти технологии никак не освещаются и не продвигаются, а вместо этого вендор продвигает старые механизмы. Хотя уверен, даже если в БСП таки встроят кролика или другого брокера как транспорт — все равно по прежнему будет все реализовано на правилах обмена стандартных которые приносят горы боли.
1с загоняет партнеров палками в прошлый век
Да не загоняет никого 1С. Тут скорее «не дают из каменного века выйти», причем в конкретной ситуации — «у нас вот есть партнеры, они умеют в КД, есть клиенты, у которых специалисты точно умеют в КД и пачка типовых, в которых из коробки есть КД, хотите чтобы ваш продукт вместе с ними продавался — используйте КД».
Тысячу лет уже как не имеют статуса партнера, так как 1С требует продаж, а мне интересна разработка.
И подобных вольных разработчиков, не повязанных ограничениями, что накладывает партнерский договор с 1С — полным-полно.
Нет никакой проблемы и без КД
Да я и не говорю что есть проблема. Тут ситуация с вполне конкретным прохождением сертификации со специфическими требованиями.
Какие-нить сертификации для использования в банках и пострашнее может оказаться. Да блин, какие-нить условные налоговые вообще IE с ActiveX требуют — корпоративный рынок, мать его.
Какие-нить сертификации для использования в банках и пострашнее может оказаться. Да блин, какие-нить условные налоговые вообще IE с ActiveX требуют — корпоративный рынок, мать его.
1C не заботится о крупном бизнесе и интеграция корпоративных приложений с эко-системой 1С их мало волнует.А на программистов им тем более положить, делюги крутятся лавеха мутится.
wrong
1C не заботится о крупном бизнесе и интеграция корпоративных приложений с эко-системой 1С их мало волнует.
Даже в среднем бизнесе интеграция — дело очень уникальное.
Что уж про крупный говорить. Который, к слову, без вопросов может себе позволить нанять квалифицированных разработчиков, чтоб допилили.
Это не так и сложно. Штатно платформа 1С поддерживает несколько разных технологий интеграции — выбирай подходящую и вперед.
Насчет «1С принудительно заставляет тех, кто делает коробку 1С: Совместимо». Ну… так вы же хотите шильду «1С: Совместимо»? Значит нужно использовать «стандартный» вариант обмена с другими конфигурациями.
Apple вон тоже требования к приложениям на свою ОС предъявляет, и ничего — все живы вроде. А они даже не дарят за это значок «Одобрено стандартами Стива Джобса» =)
Apple вон тоже требования к приложениям на свою ОС предъявляет, и ничего — все живы вроде. А они даже не дарят за это значок «Одобрено стандартами Стива Джобса» =)
Тогда возьмем итог статьи где сказано — «1С это фреймворк быстрой разработки приложений (RAD) для бизнеса и заточен под это.»
РЖД бизнес? 1С Фреймворк?
зачеркните лишнее.
По поводу абсолютно любого инструмента можно найти примеры, где он не работает или работает плохо.
Впрочем, полагаю автор процитированного вами имел ввиду — не для бизнеса, а для учёта в бизнесе.
1С и в телекоме можно использовать.
Только разумеется не в обработке миллионов звонков с оперативным разрывом связи, когда деньги заканчиваются на балансе. А, скажем, в учете прибылей и издержек — 1С вполне себе подходит и для телекома.
Есть масса решений для 1С, которые не торговля и не производство. Я уж не говорю про отраслевые решения не от вендора и разнообразные самописки для внутреннего использования.
А с учетом того, что в статье вопроса конкретных решений на платформе вообще не касались, непонятно зачем вы изливаете тут свою боль о неудачном внедрении.
А с учетом того, что в статье вопроса конкретных решений на платформе вообще не касались, непонятно зачем вы изливаете тут свою боль о неудачном внедрении.
Есть много мест, где требуется учет. Но сваять на Платформе систему управления движением лично мне в голову не придет. Хотя, наверное, и это возможно.
ЗЫ: Во времена 7.0 мне предлагали написать на этой платформе биллинг сотовой связи DAMPS. И директор конторы, где я тогда работал, очень сильно расстраивался после того, как на переговорах я открестился от этой идеи.
ЗЫ: Во времена 7.0 мне предлагали написать на этой платформе биллинг сотовой связи DAMPS. И директор конторы, где я тогда работал, очень сильно расстраивался после того, как на переговорах я открестился от этой идеи.
Во времена 7.0 мне предлагали написать на этой платформе биллинг сотовой связи DAMPS. И директор конторы, где я тогда работал, очень сильно расстраивался после того, как на переговорах я открестился от этой идеи.
Возможно вы зря открестились.
Если учесть при написании решения с нуля — платформа 1С предоставляет всего лишь довольно шустрый интерфейс доступа к СУБД (если не использовать автоматику 1С по работе с СУБД типа расчетов итогов регистров).
Директор то не знал, что написанное с нуля решение не позволит ему в дальнейшем ни нанимать дешевых программистов ни не переучивать пользователей.
Ему вполне можно было сказать — вот результат на 1С, давай деньги.
А еще честнее было объяснить — что даже если написать на 1С и даже когда она работает, то ему не получится сэкономить как я выше написал.
Так-то я видел биллинги написанные на чем угодно. На PHP и MyMSL, например. Включая ядро биллинга. Причем на том движке MySQL, что без полноценной поддержки транзакций. Строго говоря, может и не надо транзакций — зато быстро.
Просто потому что руководству фирмы попался именно что веб-программист, которые более ничего не знал.
эээ…
начнем с простого — дата в 7.0 (которая в языке была доступна) не предполагала времени от слова совсем. В этой связи некоторые вещи было сделать нельзя by design (ну или изобретать собственный формат даты+времени). Возможности интеграции 7.0 — только COM, dbf и текстовые файлы. Интерфейс 7.0 назвать шустрым… немного нельзя. В интерфейсе 7.0 отсутствовало столько возможностей, что я их перечислять устану.
И проблема была в том, что писать этот биллинг надо было мне. А написать это было нельзя. Я не считаю, что 1с-ник должен любой ценой запихать платформу в любую видимую дырку. Ведь потом с этим надо будет как-то жить.
Любой инструмент имеет границы применимости. На условном БелАЗе сложно работать в такси в Москве. И на условной Камри не менее сложно возить породу в карьере.
начнем с простого — дата в 7.0 (которая в языке была доступна) не предполагала времени от слова совсем. В этой связи некоторые вещи было сделать нельзя by design (ну или изобретать собственный формат даты+времени). Возможности интеграции 7.0 — только COM, dbf и текстовые файлы. Интерфейс 7.0 назвать шустрым… немного нельзя. В интерфейсе 7.0 отсутствовало столько возможностей, что я их перечислять устану.
И проблема была в том, что писать этот биллинг надо было мне. А написать это было нельзя. Я не считаю, что 1с-ник должен любой ценой запихать платформу в любую видимую дырку. Ведь потом с этим надо будет как-то жить.
Любой инструмент имеет границы применимости. На условном БелАЗе сложно работать в такси в Москве. И на условной Камри не менее сложно возить породу в карьере.
Это мой любимый пример — Феррари — полное дерьмо, щебня мало влезает, а бензина жрет много.
начнем с простого — дата в 7.0 (которая в языке была доступна) не предполагала времени от слова совсем.
Ну и в голых СУБД дата со временем появилась не сразу.
Обходились как-то.
Скажем использовать целое число в формате unix timestamp. Или даже строку.
Возможности интеграции 7.0 — только COM, dbf и текстовые файлы.
http с официальной внешней компонентой v7plus
Да и перечисленного вами вполне хватило бы для очень многих задач. Было бы желание.
Точнее, если вопрос стоял так:
Много денег и обязательно 1С — вполне можно сделать полноценный биллинг на 1С. С файловой базой данных 1Сv7 довольно шустра была.
В интерфейсе 7.0 отсутствовало столько возможностей, что я их перечислять устану
А нужны ли они?
Вон, системы заказа авиабилетов до сих пор с текстовыми терминалами работают.
Базового функционала интерфейса 1С для очень многих вещей более чем достаточно.
Конечно, можно сделать изящнее на более развитой по интерфейсу платформе. Но разве это обязательно?
Ведь директор, скорее всего, потому и хотел 1С, чтобы не переучивать персонал на другой интерфейс.
А написать это было нельзя. Я не считаю, что 1с-ник должен любой ценой запихать платформу в любую видимую дырку. Ведь потом с этим надо будет как-то жить.
Если речь не идет о миллионах абонентов (а в описанном вами случае скорее речь о десятках тысяч в пике) то вполне можно.
В те годы только предоплатная система была у операторов связи. И даже биллинги ведущих МТС/Билайна мало что умели в оперативном режиме делать.
Разумеется, каждой задаче свой инструмент.
Например, оперативный сегмент написать на другом инструменте. И подгружать в 1С данные для дальнейшей не спешной обработки.
Я обратил внимание на вашу фразу:
«Мне предложили написать биллинг на 1С и директор очень огорчился когда я отказался».
Если огорчение директора можно было уменьшить взяв у него денег побольше, то почему бы и нет.
Технически задача вполне себе реализуема.
Технически задача вполне себе реализуема.
Попробуйте :) Именно на 7.0 (никаких 7.5 или, упаси Бог, 7.7).
Я не знаю (и тогда и сейчас), как адекватно (по производительности и устойчивости) реализовать эту задачу.
Если у вас получится — с удовольствием поучусь, как надо. Учиться никогда не поздно.
http с официальной внешней компонентой v7plus
На 7.0 не было такой компоненты. Там и внешних компонент-то не было :)
Базового функционала интерфейса 1С для очень многих вещей более чем достаточно.
Честное слово, вы, похоже, не представляете себе «базового функционала интерфейса» версии 7.0.
Например, оперативный сегмент написать на другом инструменте.
Вот именно это мне и предлагалось написать :)
Огорчился мой директор, а не директор оператора.
Вот именно это мне и предлагалось написать :)
Огорчился мой директор, а не директор оператора.
Полагаю, что ваш директор огорчился, потому что ему посулили хороший куш.
Директор оператор тоже был доволен, потому что ему сказали что сделают неожиданно дешево.
Видите ли, эти директора — она далеки от технических вещей.
И вам, мне и нашим коллегам они платят деньги именно потому, что техническими специалистами являемся именно мы и это наша задача объяснять им что и как делать. И как это делать правильно.
Когда такая ситуация мне встречается — я понимаю, что где-то рядом много денег. Начинаю разговаривать подробнее и в результате или выхожу на крупный проект (при этом совсем не обязательно, что на первоначальной технологии) или человек понимает, что это его фантазии.
Я полагаю, что каждая проблема имеет свой инструмент для решения. И использовать для решения неподходящий инструмент — это показатель квалификации исполнителя. Другими словами — это непрофессионализм. И по результатам таких заходов появляется огромная масса тормозящих 1с-ов, которая неспособная справится с мизерной нагрузкой. Особенно после того, как ее немного поправили.
Мне и тогда (и после) платили деньги за то, что я решал проблемы, а не умножал их. У внедренца (хотя, скорее, у продажника, все-таки) должно быть хорошее качество: в нужный момент сказать: стоп! это выходит за рамки применимости инструмента. Мы или меняем инструмент или корректируем задачу.
Обсуждаемая статья тем и хороша, что черным по белому говорит: Платформа, как инструмент, имеет границы применимости. И важно понимать эти границы и вообще и в каждом конкретном случае.
Мне и тогда (и после) платили деньги за то, что я решал проблемы, а не умножал их. У внедренца (хотя, скорее, у продажника, все-таки) должно быть хорошее качество: в нужный момент сказать: стоп! это выходит за рамки применимости инструмента. Мы или меняем инструмент или корректируем задачу.
Обсуждаемая статья тем и хороша, что черным по белому говорит: Платформа, как инструмент, имеет границы применимости. И важно понимать эти границы и вообще и в каждом конкретном случае.
Если у вас получится — с удовольствием поучусь, как надо. Учиться никогда не поздно.
Движок DBF один из быстрейших в мире был в своё время.
Если учесть при написании решения с нуля — платформа 1С предоставляет всего лишь довольно шустрый интерфейс доступа к СУБДтолько к своей СУБД — это важно. 1С монолит и все начиная от структуры данных до форм отчетов пользователь будет получать из 1С. Да да да, технически возможно, но практически только из экосистемы 1С.
1С не модульное решение, в отрыве от любой части своей экосистемы она на практике не выживает.
Как понять не выживает? В каком месте?
пример Java живет как продукт и с наличием сервера бд и без него как и с наличием веб и других оберток, так и без них, как и при любом формате базы этой бд если он есть. Это язык и машина, условно. Модульная система. И вот про нее можно сказать что это «всего лишь язык и машина для выполнения кода»
1С теоретически умеет так же, можно подключится к БД своей структуры и работать с ней, но на практике 1С это полный стек начиная от бд, структуры бд, объектов для работы с этой структурой бд и всеми утилитами обслуживания этой бд и «предметно-ориентированным»* языком, заточенным под работу с этими объектами этой стрктуры бд и интерфейсом, так же заточенным под эти самые объекты. Внедрятся туда себе, в общем то, дороже и рушится основная концепция 1С внешней простоты, спеца на 1сплюсы найти очень непросто, и решения тоже очень не простые.
В других применениях 1с на долгом промежутке не выживает. Я таких долгоживущий решений в отрыве от всей этой экосистемы не видел, хотя и сам по молодости писал.
*сама предметно-ориентированность языка как бы намекает что это не для доступа к любой СУБД, а только СУБД своего собственного формата. Ваше решение не будет открыто. Управлять составом и свойствами таблиц будет платформа, обмен инфо с этой СУБД (гарантированный) возможен только с уровня приложения и с использованием объектов1С (запросы с языком запросов и СКД точно такие же объекты1С). (можно и на прямую, но до первой реструктуризации)
1С теоретически умеет так же, можно подключится к БД своей структуры и работать с ней, но на практике 1С это полный стек начиная от бд, структуры бд, объектов для работы с этой структурой бд и всеми утилитами обслуживания этой бд и «предметно-ориентированным»* языком, заточенным под работу с этими объектами этой стрктуры бд и интерфейсом, так же заточенным под эти самые объекты. Внедрятся туда себе, в общем то, дороже и рушится основная концепция 1С внешней простоты, спеца на 1сплюсы найти очень непросто, и решения тоже очень не простые.
В других применениях 1с на долгом промежутке не выживает. Я таких долгоживущий решений в отрыве от всей этой экосистемы не видел, хотя и сам по молодости писал.
*сама предметно-ориентированность языка как бы намекает что это не для доступа к любой СУБД, а только СУБД своего собственного формата. Ваше решение не будет открыто. Управлять составом и свойствами таблиц будет платформа, обмен инфо с этой СУБД (гарантированный) возможен только с уровня приложения и с использованием объектов1С (запросы с языком запросов и СКД точно такие же объекты1С). (можно и на прямую, но до первой реструктуризации)
Java — это язык программирования. Некорректно сравнивать язык программирования с фреймворком у которого жесткая зависимость от ORM-системы, на чем бы тот фреймворк не был написан.
И поверьте, 1С-как-язык-программирования прекрасно себе живет в отрыве и от базы данных и от объектов 1С.
Мне кажется что вы согласны со мной в оценке что 1С это не «шустрый интерфейс для связи с СУБД» (во первых не шустрый, во вторых не только интерфейс, в третьих решений для связи с любыми субд на порядок или несколько меньше, чем для связи с БД в формате 1с). И ценность у 1С именно что в комплексе (быстро и сразу все).
//Про onescript не знал, но я не очень вижу реальную сферу его применения, право слово. Был бы к месту красивый пример, где onescript выступил бы в роли Д'Артаньяна.
//Про onescript не знал, но я не очень вижу реальную сферу его применения, право слово. Был бы к месту красивый пример, где onescript выступил бы в роли Д'Артаньяна.
да, я согласен насчет интерфейса к БД — я тоже не понял этого довода уважаемого комментатора.
Про 1скрипт — это был контраргумент на вашу фразу, мол Java "про нее можно сказать что это «всего лишь язык и машина для выполнения кода»".
Про язык 1С (именно про язык, как про синтаксис и некие правила выполнения выражений) можно сказать то же самое, приведя в пример 1Скрипт, который "живет как продукт и с наличием сервера бд и без него как и с наличием веб и других оберток, так и без них, как и при любом формате базы этой бд если он есть." Реальная сфера применения — это утилиты для администрирования 1С-а 1С-никами.
Перечень вот тут Страничка, кстати, тоже написана на 1script
Ну вообще-то, платформа позволяет доступ и обработку внешних таблиц, как своих. Теоретически можно использовать её как интерфейс, а данные хранить не в собственной базе, а во внешней. Но… оно нужно?
только к своей СУБД — это важно. 1С монолит и все начиная от структуры данных до форм отчетов пользователь будет получать из 1С. Да да да, технически возможно, но практически только из экосистемы 1С.
1С не модульное решение, в отрыве от любой части своей экосистемы она на практике не выживает.
Речь конкретно об 1C v7.
Формат её данных довольно прост.
Файловая БД — это стандартный DBF. Что значат какие поля — нетрудно догадаться. Да и описания готовые есть.
Вариант v7 под SQL — обладает той же структурой данных (в результате она плохо адаптирована под реляционные СУБД, так как рождена была для файловых).
Существуют (ну или точнее существовали) продукты, которые напрямую извлекали данные из БД 1С.
Это не сложно для программиста средней руки.
Вы бы ещё про 6.0 вспомнили… Автор в своей статье говорит конкретно про платформу 1С: Предприятие 8. Зачем уходить от темы.
Вы бы ещё про 6.0 вспомнили…
А при чем тут я?
Проследите ветку с начала — началось все с этого воспоминания времен v7.0, когда человеку предложили написать на ней биллинг, v8 тогда не было:
habr.com/en/post/480658/#comment_21028146
Написать биллинг на 1С v6 это нет.
А на v7 уже реально. Она была довольно шустрой, если знать как её готовить. Быстрее чем v8 (на огромных масштабах данных v8 быстрее, но биллингу совсем не обязательно все данные перебирать, достаточно ограничиться «горячими»).
Вы не в теме, вы не правы
Возможность типизации на уровне, например, TypeScript (как следствие более развитые средства анализа кода в IDE, рефакторинг, меньше обидных косяков)
Вот тут близкая мне тема.
Хочу немного (совсем чуть-чуть) не согласиться с тобой, ибо в новой IDE для 100% типизации кода есть все возможности.
Другой глобальный вопрос — сделают ли во фреймворке режим для рантайма — чтобы тип нельзя было менять (жесткая типизация), но на этапе написания кода и компиляции — это уже сейчас есть возможность сделать.
Тут — как раз «движение вперед» для языка 1С есть.
для 100% типизации кода есть все возможности.
Это поэтому она у меня на 16 гигах даже не стартует, да?
:) Наверное по другой причине)) я регулярно на 8Гб стартую ERP и работает…
Сможешь выдать онлайн-мастер класс по запуску ЕДТ на моем ноуте? А то у нас как раз темы для стримов заканчиваются :)
А сколько времени старт занимает, если не секрет?
А сколько времени старт занимает, если не секрет?
Старт самой IDE занимает одинаково (примерно) хоть на ERP, хоть на любом микроскопическом проекте. 10-20 секунд у меня (тут все зависит от CPU и SSD).
Дальше уже после старта есть фаза (условно) «Инициализации проекта», она сильнее зависит от объема проекта, т.к. проверяет актуальность данных на диске и с последнего запуска. Но если проект не менялся, пока IDE была выключена — то обычно 15-20 секунд.
Так же далее идет открытие редакторов, которые были открыты в прошлой сессии — это еще время итд… а они за собой тянут немедленный старт внутренних сервисов… что тоже время.
У меня на ноуте не стартует даже виртуальная машина Java в дефолтных настройках EDT. Грит "нимагу и всё". Я честно не пытался вникать, руки не дошли. Наверное там что-то надо подкрутить, но сам факт того что надо подкручивать после установки — меня напрягает
Так сколько всего получается холодный старт, от запуска до «можно нормально работать»?
Всю ветку не осилил, но своих пару копеек вставлю:
1 — идея о самопрограммирующем бухгалтере умерла не родившись, имхо и язык и объектную модель уже давно напрашивается привести в соответствие новой идее — программируют программисты.
2 — хочется строгой типизации и весь доступный спектр sql инструментов желательно в какой нибудь крайней редакции.
3 — фронт энд бэк разработка расходятся навсегда
ну и 4 — отсутствие нормальной среды разработки лимитирует конечно
1 — идея о самопрограммирующем бухгалтере умерла не родившись, имхо и язык и объектную модель уже давно напрашивается привести в соответствие новой идее — программируют программисты.
2 — хочется строгой типизации и весь доступный спектр sql инструментов желательно в какой нибудь крайней редакции.
3 — фронт энд бэк разработка расходятся навсегда
ну и 4 — отсутствие нормальной среды разработки лимитирует конечно
1. Лозунг «Доступно и всерьез» (ИМХО) последний раз применялся в Бух 6.0. И там бухгалтер вполне мог самопрограммировать (и таких бухов было немало). А уже 7.5 такого лозунга и применения не предполагала.
тогда черт же Вас возьми, коллега, объясните мне почему СКД перепиливает запросы и не имеет возможности отключить эту очень полезную фичу? Почему до сих пор тянется эта волокита с типизацией, но так уныло она реализована на уровне запросов к БД?
Из за этих вещей новые объекты, которые должны были стать драйвером развития, используются в проценты от своей мощности, т.к. ну блин работает как то странно, лучше буду запросом выбирать выборку и на сервере приложений обсчитывать. или Ну в СКД загружу результат своего уже много раз оптимизированного запроса, а там уже только отрисую табдок. К чему это все? За что цепляются? Ведь банально отбирают инструменты балансировки нагрузки между серверами трехзвенки, так что же это тогда за трехзвенка? И таких вопросов много, это ж только наболевшие
Из за этих вещей новые объекты, которые должны были стать драйвером развития, используются в проценты от своей мощности, т.к. ну блин работает как то странно, лучше буду запросом выбирать выборку и на сервере приложений обсчитывать. или Ну в СКД загружу результат своего уже много раз оптимизированного запроса, а там уже только отрисую табдок. К чему это все? За что цепляются? Ведь банально отбирают инструменты балансировки нагрузки между серверами трехзвенки, так что же это тогда за трехзвенка? И таких вопросов много, это ж только наболевшие
За стабильность и обратную совместимость.
Просто представьте, что в какой-то момент времени раз и новая версия получит другую реализацию СКД. Ну вот совсем другую. И внезапно те 100500 миллионов отчетов в разных информационных системах начнут возвращать другие цифры. Тут после существенных переработок генератора форм было столько криков и стонов, а тут отчеты…
Мы радостно используем послезнание для анализа и критики решений, принятых 5-10-15-20 лет назад. Но только люди, принимавшие те решения а) не имели наших послезнаний и б) имели другой опыт и взгляды на разработку (не плохие взгляды, а другие).
Просто представьте, что в какой-то момент времени раз и новая версия получит другую реализацию СКД. Ну вот совсем другую. И внезапно те 100500 миллионов отчетов в разных информационных системах начнут возвращать другие цифры. Тут после существенных переработок генератора форм было столько криков и стонов, а тут отчеты…
Мы радостно используем послезнание для анализа и критики решений, принятых 5-10-15-20 лет назад. Но только люди, принимавшие те решения а) не имели наших послезнаний и б) имели другой опыт и взгляды на разработку (не плохие взгляды, а другие).
Поставил 1с на одной виртуалке, включил в постгресе, на другой виртуалке, log_min_duration = 0, ушел на выходные домой — 30 гигов диска на виртуалке с постгресом забито сообщениями о десятках тысяч запросов к базе, о каких-то временных таблицах, обращениями к одинэсовским системным таблицам. А ведь даже приложение на другой не было запущено, просто зарегистрирована и загружена база на 2 гига. Представлю как она гробит SSD, эта кривая дрянь. И это я ещё не смотрел в какой момент упала виртуалка от нехватки места на диске.
Переопределение было и в 7.7 версии, к слову.
Переопределение было и в 7.7 версии, к слову.
И ничего о «регламентных задания» в фреймворке 1С вы не слышали? :) Ну так можно про любой Фреймворк сказать: он делает какую-то непонятную Мне хрень — значит Фреймворк отстой.
Наверное и о «блокировке регламентных заданий» в базе вы не слышали… :)
Как бэ, напрашивается вопрос: зачем стараться пользоваться тем, что не хочешь нормально изучать? (я про Фреймворк 1С, а не про конкретное приложение).
Наверное и о «блокировке регламентных заданий» в базе вы не слышали… :)
Как бэ, напрашивается вопрос: зачем стараться пользоваться тем, что не хочешь нормально изучать? (я про Фреймворк 1С, а не про конкретное приложение).
Странно, приложение интенсивно работающее с базой данных, интенсивно работает с базой данных… С чего бы это?
1С как таковая была закрыта. Я могу понять регламентные работы вследствие действий пользователя. Но когда она двое суток тысячи запросов слала однотипных в БД — этого я понять не могу. Да ещё и в таких объёмах.
Зачем всё это было надо? Отлавливали баг с разными результатами в отчетах при включенном и выключенном enable_indexscan. Как отлавливали — закрывалось окно 1С, постгрес останавливался, постгресовые логи вычищались, запускался постгрес, запускалась 1С, в 1С выполнялся отчет, 1С закрывался, стопорился постгрес — за 7-10 минут по полмиллиона строк в логах. Название конфигурации уже не помню, что-то там бюджетное. После этого всего я закрыл 1С на машине с виндой и ушел домой на выходные. Т.е. от клиента к базе запросов быть не могло.
Баг в пг нашли и вылечили, относящихся к нему запросов из 1с было порядка 20 штук — создать временные таблицы, создать на основании временных таблиц другие временные таблицы, на их основании ещё, а уже после этого получить, из третьих по счёту таблиц, результат. Ну, понятное дело — система только запустилась, решила там что-то посмотреть. Но всё равно — попытайтесь мне объяснить — что значат 499980/5= ~99996 запросов за десять минут во время запуска. А я с балкона посмотрю…
Я работал с 1С начиная с 6.0 версии, её мельком зацепил, но годик пообслуживал. На восьмой версии в 2005 году у меня батарейка села и я занялся SQL. А до того, параллельно с учёбой — писал на клиппере и FoxPro. Так что если я вижу более пятисот тысяч строк логов за десять минут, в приложении которое ничего не делает для пользователя, и считаю это ненормальным — это значит что это ненормально.
Зачем всё это было надо? Отлавливали баг с разными результатами в отчетах при включенном и выключенном enable_indexscan. Как отлавливали — закрывалось окно 1С, постгрес останавливался, постгресовые логи вычищались, запускался постгрес, запускалась 1С, в 1С выполнялся отчет, 1С закрывался, стопорился постгрес — за 7-10 минут по полмиллиона строк в логах. Название конфигурации уже не помню, что-то там бюджетное. После этого всего я закрыл 1С на машине с виндой и ушел домой на выходные. Т.е. от клиента к базе запросов быть не могло.
Баг в пг нашли и вылечили, относящихся к нему запросов из 1с было порядка 20 штук — создать временные таблицы, создать на основании временных таблиц другие временные таблицы, на их основании ещё, а уже после этого получить, из третьих по счёту таблиц, результат. Ну, понятное дело — система только запустилась, решила там что-то посмотреть. Но всё равно — попытайтесь мне объяснить — что значат 499980/5= ~99996 запросов за десять минут во время запуска. А я с балкона посмотрю…
Я работал с 1С начиная с 6.0 версии, её мельком зацепил, но годик пообслуживал. На восьмой версии в 2005 году у меня батарейка села и я занялся SQL. А до того, параллельно с учёбой — писал на клиппере и FoxPro. Так что если я вижу более пятисот тысяч строк логов за десять минут, в приложении которое ничего не делает для пользователя, и считаю это ненормальным — это значит что это ненормально.
Никогда не был хейтером в адрес 1С, у нее есть своя ниша, есть свой рынок и отрицать это бессмысленно. НО!)) с появлением таких фреймворков как django ,flask, spring boot и прочие практически коробочные решения для того, что бы сделать здесь и сейчас что то уже работающее показывающее, но не бухгалтерию) интерес к ней пропал.
Окей, давайте по второму кругу: как на перечисленных фреймворках сделать сквозной нумератор документов по набору ключей, недырявую модель распределения прав доступа и печать накладных в PDF?
Очевидно, что можно сделать все перечисленные пункты, насколько быстро?
Дело в том, что понятие "сделать здесь и сейчас что то уже работающее показывающее" слишком обобщенное. В статье приведен пример приложения для ларька с шаурмой — учет покупки, продажи, в разрезе покупных и продажных цен, учетом остатков по складам, разграничением доступа, веб-клиентом и отчетностью с возможностью drill-down и вывода в PDF. На 1С я сделаю за 2 часа. Кто меньше?
эм)) все это я делал)
Подключаешь нужную тебе либу и работаешь), а в той же джанге ролевая модель из коробки-каркас конечно, но очень даже удобная.
По поводу печати, берешь либо какая тебе нравится, а не ту какую тебе пихает вендор ))
я например долго юзал aeroolib очень удобно)
В общем это я могу сделать за 2-3 дня ))
Подключаешь нужную тебе либу и работаешь), а в той же джанге ролевая модель из коробки-каркас конечно, но очень даже удобная.
По поводу печати, берешь либо какая тебе нравится, а не ту какую тебе пихает вендор ))
я например долго юзал aeroolib очень удобно)
В общем это я могу сделать за 2-3 дня ))
Похоже вы в пролёте (вопрос был «кто меньше 2х часов?») а тут 2-3 дня… да ещё нужно знать конкретные либы что там и как подключается, юзается и реализуется…
Это ещё не любого «питониста с улицы» возьми и он тебе сделает за 2-3 дня...
Odoo, ErpNext меньше 2х часов)
Не сидите в коробке одного фреймворка, и не бычтесь, это вам не к лицу
Не сидите в коробке одного фреймворка, и не бычтесь, это вам не к лицу
Все-таки, вы не правы — Odoo, ErpNext — это не фреймворки, это конкретные бизнес-приложения. Я понимаю что там поднизом лежат какие-то фреймворки — вот с ними нужно сравнение, если вы в них специалист — прошу, поделитесь.
Ну почитайте внимательно задачу: взять голый Фреймворк и сделать на нем конкретную бизнес-задачу.
Тут могу только предложить: «фреймворки в студию!» и давайте сравнительный анализ :)
Ну почитайте внимательно задачу: взять голый Фреймворк и сделать на нем конкретную бизнес-задачу.
Не сидите в коробке одного фреймворка, и не бычтесь, это вам не к лицу
Тут могу только предложить: «фреймворки в студию!» и давайте сравнительный анализ :)
Это с чего вы взяли, что Odoo и ERPnext это не фреймворки а Бизнес приложения)))))
Вы можете установить Odoo без единого модуля и работать с ним как с фреймворком), Вы оперируете фактами как то извращенно, когда Вам удобно выдаете за фреймворк, а когда нет за Бизнес приложение)
Установите себе Odoo и вы поймете, что это фреймворк, со встроеными уже готовыми решениями для Печати, GUI и тд, и при всем этом СВОБОДНАЯ от вендора и лепите на нее все что мир изобретает каждый день.
Лично у меня был опыт создания приложения для учета рабочего времени компании, и мы взяли пустой фреймворк Odoo, и на его базе сделали свое приложение. Код открыт, делай что хочешь, а odoo дает только удобную orm, работа с печатью, api и GUI. и мы не зависили от того что там есть у него в коробе, лепили на него что хотели из мира python и не только.
github.com/odoo/odoo — клоньте, удаляйте папку addons и у вас пустой фреймворк для созидания)
Но мне кажется вы все равно будете стоять на своем, по одной причине, вы человек-фреймворк, привязанный к чему то одному, и у вас все остальное проходит через призму 1С
Вы можете установить Odoo без единого модуля и работать с ним как с фреймворком), Вы оперируете фактами как то извращенно, когда Вам удобно выдаете за фреймворк, а когда нет за Бизнес приложение)
Установите себе Odoo и вы поймете, что это фреймворк, со встроеными уже готовыми решениями для Печати, GUI и тд, и при всем этом СВОБОДНАЯ от вендора и лепите на нее все что мир изобретает каждый день.
Лично у меня был опыт создания приложения для учета рабочего времени компании, и мы взяли пустой фреймворк Odoo, и на его базе сделали свое приложение. Код открыт, делай что хочешь, а odoo дает только удобную orm, работа с печатью, api и GUI. и мы не зависили от того что там есть у него в коробе, лепили на него что хотели из мира python и не только.
github.com/odoo/odoo — клоньте, удаляйте папку addons и у вас пустой фреймворк для созидания)
Но мне кажется вы все равно будете стоять на своем, по одной причине, вы человек-фреймворк, привязанный к чему то одному, и у вас все остальное проходит через призму 1С
Проблема лишь в том, что Вы думаете, что все программисты мечтают программировать программы для ларьков с шаурмой. Это и есть основной просчет. Сейчас тренд — облачные решения и сервисы, работа с большими данными, микросервисы и т.п. В этих сферах 1с пролетает мимо и с большим свистом. Кстати, о микросервисах. Вы писали выше некоторые рассуждения на их счет. И тут ошибка, микросервисы нужны не ради микросервисности. Архитектура микросервисов позволяет взять и переписать любой сервис на НОВОЙ технологии, если она появилась. Это избавляет от ловушек легаси, в которой застряла 1с и скоро просто утонет после того, как появятся государственные облачные сервисы, решающие задачи с учетом и отчетностью.
Резюме. Вам лучше зазывать в 1с не программистов, а экономистов, продавцов и консультантов, они там лучше пригодятся, и легче нанимать, и дешевле, и выход из этого бизнеса будет легче.
Резюме. Вам лучше зазывать в 1с не программистов, а экономистов, продавцов и консультантов, они там лучше пригодятся, и легче нанимать, и дешевле, и выход из этого бизнеса будет легче.
Кстати) вспомнил фреймворки которые все это сделают за 2 часа
Odoo, ErpNext, я думаю их куда больше, нее сидите в коробке одного фреймворка
Odoo, ErpNext, я думаю их куда больше, нее сидите в коробке одного фреймворка
… — я не вижу на рынке достойного конкурента. За одну и ту же цену вы получаете фреймворк финансового приложения, кластеризуемый балансируемый сервер, с UI и веб-мордой, с мобильным приложением, с отчетностью, интеграцией и кучей еще чего.
Apache OfBiz или его производные.
Все Вами описанное более-менее есть. Все сделано на современных технологиях.
Тоже фреймворк, тоже надо допиливать. Тоже куча плюсов и минусов.
Но OfBiz сделан намного качественнее по каждому указанному Вами аспекту.
Я смотрел и на 1C и на OFBiz с точки зрения именно как «бизнесмен», потом как «системный аналитик». Аспекты реализации и особенности работы — детально не анализировал. Но пока — меня вполне устраивает, все криво-косо, так или иначе — но работает. И простую бизнес-логику реализует быстро и без особых хлопот.
Посмотрел демку OfBiz — по сценарию ввода данных для пользователя скорее напоминает SAP R3. Вот про "криво-косо но работает" пожалуй соглашусь, но как эта фраза коррелирует с "OfBiz сделан намного качественнее по каждому указанному Вами аспекту"?
Посмотрел демку OfBiz
Как «бизнесмен», которому не лень было ковыряться в софте, я работал и на 1С (от версии 4 до 8), и делал проекты на ACCPAC и смотрел иные системы. 1С мне нравилась, даже писали какие-то отчеты и разные добавки к ней.
6 месяцев назад стал искать на чем можно сделать в стартапе «операционную систему бизнеса» (реализация модулей концепции GERAM). Чтобы она работала на этапах реализации проекта от «идеи» до «операционная деятельность».
Использую OfBiz не долго, поэтому могу не все точно описать, не взыщите.
Демка не передает чудес этого продукта. Выглядит все похоже, морда и front-end везде более-менее похожие. Сама логика работы — очень разная от 1С. Если коротко — то люди взяли продуманное решение, по сути книгу «The Data Model Resource Book. A Library of Universal Data Models for All Enterprises» Len Silverston и реализовали ее в виде фреймворка. И не только ее, но и видать много чего еще.
Опишу только начало, про установку.
Я 27 лет работал исключительно на инфраструктуре MS.
Год назад перешел на Linux. Убунту. Так что опыта не особо.
Прочитал как ставить Ofbiz. Типа «Download» OFBiz и "./gradlew ofbiz". И чё? типа все?
Не поверилось, вроде сложная штуковина. Все заработало со второго раза. И то, только по моей глупости не с первого.
Потом были муки с документацией на продукт. Пока не догадался скачать указанную выше книгу и прочитать. Понял, почему нет отдельной документации. Не особо нужна, все описано в этой книге.
Функционал программы — огромный. Все, что мне нужно сейчас и будет нужно в ближайшие несколько лет — вроде все есть.
Система идет в исходных кодах. Разработка, доработка — стандартными инструментами от Apache.
СУБД — вроде бы тоже любая.
Производительность при высокой нагрузке? А фиг его знает. Мне пока не надо, но вроде никаких особых ограничений нет.
Модель событий? Открытая, все видно и доступно.
API? Да вроде все инструменты там стандартные, все есть.
Развертывание на Линукс? У меня заняло 20 минут, а я не особо спец.
Контейнер? Да вроде изначально так и работает.
Поддержка? Наверное какая-то есть. Пока не было нужды к ним обращаться.
Настройка? Да не особо вижу разницу, объем работы примерно одинаковый с тяжелыми корпоративными пакетами. Да и в 1С не особо меньше.
Цена? Да вроде небольшая, «полная стоимость владения» сопоставимая с 1С (но это пока только прикидки)
Красивая «морда» для e-сommerce? Тоже вроде бы не особо сложно.
Пока так.
1с это реально один из лучших решений сейчас для бизнеса. Для России точно самое лучшее. Касаемо языка тоже один из лучших языков для создания бизнес решений. 1с устарел? Наверно это скорее уже относится к java/c#, которые так же создавались как бизнес языки в середине 90х. И они уже слишком сложные на данный момент. Вокруг той же java уже существует с 10к разных упрощений. Ну и плюс 1с, как отметил автор — это универсализм специалиста. Он в состоянии как спроектировать решение, написав тз со слов клиента, так и реализовать его. А вот, если взять тех же java/c# разработчиков, здесь все намного сложнее и уж как повезет. Ибо сложность языков не дает в полной мере сосредоточиться на предметной области
я для своего бизнеса написал собственную ERP систему на C#, не жалею
В прошлой статье я защищал 1С, а в этой, ну, пусть из латентного нонконформизма, но налью таки бочку дёгтя.
1С сейчас в современном IT-ландшафте, как чемодан без ручки — нести тяжело, выбросить жалко. Для 2003-2004 года интеграция в IT-ландшафт была суперской, но, чёрт подери, ко мне того и гляди на собеседование придут люди рождённые в те годы. Что я под этим подразумеваю — ниже.
Слааабые возможности интеграции. Что у нас есть в 1С для общения с другими приложениями? Файлы, COM-объекты, внешние компоненты, HTTP-запросы, SMTP/POP3, ODBC-подобные соединения с СУБД, плюс ещё некоторая достаточно экзотическая мелочёвка. Причём всё вышепереписленное с кучей оговорок:
- Файлы по сути только текстовые. Работа с бинарными файлами — раньше была совсем не возможна, а сейчас низкоуровневый трешак, который я не смогу обосновать по стоимости разработки прикладных решений. Только если жизненно важно что-то простое разобрать. Отдать вендору должное — на файлах у него достаточно много неплохих стандартизованных отраслевых решений.
- SMTP/POP3 — э, ну вы же всёрьёз не считаете, что это способ сделать API?
- COM-объекты — доступны только под Windows (а уже и сервер умеет с linux жить, и клиенты не все это умеют), тупиковая ветвь эволюции. Ну камон, эта тема была в тренде 20(!) лет назад, закопайте уже таки стюардессу.
- HTTP-запросы реализованы очень низкоуровнево. Ну то есть простые GET по HTTP ещё куда ни шло, но, например, какой-нибудь SPNEGO реализовать уже совсем не весело. HTTPS, кстати, долго был недоюзабельный. Вкупе с ещё одной проблемой 1С (отвратительной модульностью и сложностью переиспользования технического кода) это приводит к тому, что разработчики прикладных решений часто говорят "ну его нафиг, давайте файлами обмениваться".
- ODBC-подобные соединения с СУБД — это только чтобы забирать данные из витрин. Серьёзный "контрактный" API на этом не строят.
- Внешние компоненты (ВК). Теоретически "вы можете всё". Ахаха. Теоретически. Практически это некий самописный аналог IDispatch (привет, динозавры!!!) со своим ГПСЧ и практикантками. Их и было-то не много — в основном для интеграции с торговыми устройтсами, а году в 2005-2006 1С поменяла нутро этого формата (ушла от явного использования COM по сути и от интерактивных возможностей) и с тех пор их совсем почти не пишут. При написании надо либо дофига делать руками, либо делать кучу нетривиального тулинга, а для этого надо много времени. Готовых публичных и полезных ВК если и появляется, то точно не больше 2 штук в год. Теоретически можно даже из 1С работать с .NET (Elisy .Net Bridge), а практически он не развивается, например, .NET Core там нет. Ну и даже там всё не просто.
Кому кажется этого достаточно, тот застрял в 2005 году. А я хочу: HTTP/2, GraphQL, gRPC, сериализацию в Protobuf, удобную интеграцию с kafka, RabbitMQ, ActiveMQ (и прочими ZeroMQ, nanomsg), хочу подключаться к MongoDB, Cassandra, Hadoop, хочу использовать комфортно распространённые API (ну, например, файлы в S3 хранить), хочу использовать SSO и аутентифицировать сервис 1С без хранения креденшелов. Это только то, что сходу вспомнилось. На самом деле этот список каждый день прирастает.
Слабая интеграция в инфраструктуру современного IT. Да у 1С по сих пор даже работа с доменом AD и внешней аутентификацией всё ещё в детском состоянии! Максимум, что есть — указание, что Вася Пупкин может аутентифицироваться как PupkinVD@my.company. Нет корректной работы с группами, OU, блокированием/удалением, нет работы с корпоративным RBAC, нет альтернативных сервисов аутентификации (KeyCloack, например, или аутентификация в google том же). Интеграция с корпоративным мониторингом на ELC на уровне "принципиально возможна". То есть как бы её никто не запрещает делать, но там делать, прямо скажем, немало. Про успешную интеграцию в WAF и DLP просто не слышал. Интеграция с мессенджерами, телефонией и exchange — примитивна. Зато в 1С сканер ШК и фискальный регистратор почти всегда из коробки заводится, ну да.
Слабые интерфейсные возможности. Пока сценарий работы кнопкутык, кнопкутык, полевбил, контрол-энтер, то всё прекрасно. Шаг вправо-влево и "не шмогла". Кто не согласен — вперёд покажите мне прототип интерактивного редактора markdown (хотя бы только с жирным и наклонным шрифтом) или интерактивную работу с картой (и нет, вам не поможет ГеографическаяСхема).
О, кстати, про ГеографическаяСхема. Отдельно упомяну "кладбище невзлетевших фич". Это целая гора фич, которые или просто оказались не нужны или были хреново сделаны или вышли не так и не тогда, когда нужно было.
Просто списком с минимальными комментариями:
- ГеографическаяСхема — в этом виде оказалась никому не нужна. Вышла очень рано, не продумана инфраструктура. Сейчас проще пользоваться либо настоящими картами (яндекс, гугл), либо сторонними севисами/решениями
- Статистический анализ данных — во многом опередил своё время, но сделан был "не для людей". Сейчас это делают либо в питон/юпитер, либо в табло/повербиай/клик. Очень обидно за державу. Они делали (хотели делать, точнее) кластерный анализ, пока остальные в том же классе всё ещё фильтровали эксель. Бигдата за несколько лет до хайпа.
- Бизнес-процессы. Сделаны хуже, чем даже Elma, а это ещё надо постараться. Где-то как-то используются, обязательно присутствуют на экзамене 1С: Специалист (в жизни достаточно редко). Для сравнения посмотрите на эту же Elma или на Camunda или на любую другую BPM-систему.
- Веб-сервисы (wsdl). Не успели появиться, как по факту списаны на свалку истории (заменены REST и MQ в нормальном, не 1С, мире)
- Fast Infoset. Его место в нормальном мире занял ProtoBuf фактически.
- Полнотектовый поиск не то чтобы совсем дохлый, но опять же — то как он сделан и подан не оставляет ему шансов быть в топе фич.
- Сводная диаграмма — на фоне СКД и отчётов просто не взлетела.
- Макеты текстовых документов. Крутая фича (нужна, если нужно отчёты в TXT формате делать). Но она никому почти не нужна.
- Срез первых в регистре сведений. Ну просто оказался не нужен.
- IBM DB2 RIP
Ну а в разработке, как я уже отметил, всё плохо с модульностью решений и сложностью переиспользования технического кода. И по мне так БСП не пример того, как это "победили", а пример того, как это "проиграли".
Во многом согласен, разве что по поводу интерфеса оговорочка — благодаря тому что вебкит наконец встроили в платформу — можно более менее на веб технологии расчитывать. Но в целом это выглядит… Мда, костылем. Да еще и на мобилках раньше были большие проблемы.
SMTP/POP3 — э, ну вы же всёрьёз не считаете, что это способ сделать API?
А как по вашему отчетики в ФНС, ПФР отправляются (собственно, один из главных источников дохода фирмы 1С)?
Это скорее к ФНС/ПФР вопрос, доколе!?
А что изменится если они перейдут на HTTP2/Protobuf или что-то другое?
В 1С в своё время более-менее приличная поддержка http (запросы, ответы) появилась только из-за того что один из контролирующих органов принимал отчёты через сайт, в котором сессия в заголовках ответа приходила. До этого заголовки ответа штатными средствами нельзя было получить
Работа с бинарными файлами — раньше была совсем не возможна, а сейчас низкоуровневый трешак, который я не смогу обосновать по стоимости разработки прикладных решений.
А можно пример где работа с бинарными файлами сделана на порядок лучше?
HTTP-запросы реализованы очень низкоуровнево. Ну то есть простые GET по HTTP ещё куда ни шло, но, например, какой-нибудь SPNEGO реализовать уже совсем не весело
А конкретней можно чего вам не хватает при работе c HTTP?
А можно пример где работа с бинарными файлами сделана на порядок лучше?
C, C++, C#, Java, Python, Rust, Go (и ещё несколько сотен языков)
В 1С методы работы с чтением двоичных данных (которые появились в 8.3.9-8.3.10 в 2016 и 2017 годах — совершенно недавно по энтерпрайз меркам) предоставляют весьма низкоуровневые возможности: чтение примитивных числовых и строковых данных. Нет удобных инструментов чтения сразу в структуры данных. Да что там! Даже банально float прочитать — уже изголяться. Да что там float! Даже отдельных методов для знаковых/беззнаковых нет.
А так как с модульностью и переиспользованием кода в 1С задница и юнит-тесты писать заколебёшься, то даже относительно простые потоки данных читать — боль-боль-боль.
А конкретней можно чего вам не хватает при работе c HTTP?
Я не говорю "не хватает". Я говорю "низкоуровневые". То есть сделать можно всё, как можно всё написать на ассемблере. Теоретически — да. Практически даже обращение к простому сервису с аутентификацией и последующий разбор результатов это какие-то невменяемые портянки кода по сравнению, например, с JS. В качестве примера попробуйте какой-нибудь список тикетов из Jira или GitLab по фильтру вытащить, только по-честному с правильной не-basic аутентификацией, без хранения пароля пользователя.
Вроде и делается всё, но уж так это многословно.
В качестве примера попробуйте какой-нибудь список тикетов из Jira или GitLab по фильтру вытащить, только по-честному с правильной не-basic аутентификацией, без хранения пароля пользователя.
Вроде и делается всё, но уж так это многословно.
Сахара языку конечно не хватает, но в целом терпимо (см. КоннекторHTTP)
Заголовки = Новый Соответствие;
Заголовки.Вставить("PRIVATE-TOKEN", <your_access_token>);
issues = КоннекторHTTP.GetJson(
"https://gitlab.example.com/api/v4/issues?labels=foo,bar&state=opened",
Неопределено,
Новый Структура("Заголовки", Заголовки));
Я вот не определился, читерство это или нет :) Но в одном определился: ваш КоннекторHTTP — крутейшая вещь. Спасибо за наводку, я, как архитектор уже начал обсуждение использование этой библиотеки у нас.
Собственно, мне кажется, что это то, как должна была выглядеть работа с HTTP в платформе.
И написана прям добротно-добротно:
- Код структурирован, даже области используются — уважуха.
- Методы небольшие, всё как надо. Декомпозиция на функции очень разумная.
- Экспортные функции выделены в отдельный блоки и каждая экспортная функция со стандартным комментом
- Код стандартно отформатирован, без грязноты практически, комменты по делу, нет широченных строк. Ну это же читается, как поэма!
- Даже есть какой-никакой CI, статанализ и тесты.
Не скажу, что это нельзя улучшить, но на пару уровней выше кода, который я вижу в среднем.
Что показалось спорным
- Я сначала хотел умилиться использованию
Знач, но потом понял, что то ли я не понимаю ваших принципов использованияЗнач, то ли они полуслучайные. Первый попавшийся примерРазбитьСтрокуПоСтроке(Знач Строка, Разделитель)— почему первый параметр сЗнач, а второй без? - Тесты. Хардкод в тестах это лучше, чем хардкод в коде, но всё равно плохо. Если модуль собирается без доступа к Интернет, например, то тесты в текущем виде можно выкинуть. По-хорошему, параметры тестов нужно вынести отдельно. Вариантов тут масса, можно, например, вынести их в форму, можно макет, можно в какие-нибудь предопределённые данные. Лично я выносил в макет.
- Тесты. Нет раздельного запуска тестов, но это лучше решать не локально для данной библиотеки, а делать фреймворк, а это задача сразу гораздо больше.
- Тесты. Отчёт по тестам не для автоматизации. Но это тоже скорее вопрос к отсутствию фреймворка.
- По коду тоже есть что сказать, но такие вещи проще и правильнее через PR делать.
И вообще, README.md почти готовая статья на хабр. Ну как "почти" — процентов на 40-60, но это самые важные проценты — скелет и мясо статьи. Не хватает по сути только описания контекста, в котором возникла задача и почему именно так решена, плюс какие-то нюансы поясняющие. Добейте, опубликуйте. Я штук 3-5 голосов-плюсиков точно подгоню, если кинете ссылку (да и EvilBeaver, думаю тоже).
Спасибо за высокую оценку!
Конкретно в данной функции: исходное значение копируется в переменную Строка и после этого я могу ее изменять (что и происходит) и не придумывать новую переменную. С параметром Разделитель я никаких модификаций не произвожу, поэтому и без Знач. В целом изначально закладывался смысл защититься от изменений исходных данных.
В некоторых местах Знач лишний. Скорей всего потому что изначально он был нужен, а потом изменив тело метода, я не поменял параметры.
В тесты я не вкладывался, сделал по минимуму. Много что можно было бы улучшить, но пока желания нет
Код я писал с очень большими паузами, выпадая из контекста. Поэтому могут встретиться какие-то странные вещи.
Сначала было MVP, которого мне хватало для моих задач. Потом я перестал заниматься задачами связанными с 1С, но жалко было бросать библиотеку. Поэтому решил допилить и опубликовать.
Сейчас я ее уже не использую, но иногда что-то доделываю если кто-то что-то просит.
Я сначала хотел умилиться использованию Знач, но потом понял, что то ли я не понимаю ваших принципов использования Знач, то ли они полуслучайные. Первый попавшийся пример РазбитьСтрокуПоСтроке(Знач Строка, Разделитель) — почему первый параметр с Знач, а второй без?
Конкретно в данной функции: исходное значение копируется в переменную Строка и после этого я могу ее изменять (что и происходит) и не придумывать новую переменную. С параметром Разделитель я никаких модификаций не произвожу, поэтому и без Знач. В целом изначально закладывался смысл защититься от изменений исходных данных.
В некоторых местах Знач лишний. Скорей всего потому что изначально он был нужен, а потом изменив тело метода, я не поменял параметры.
Тесты.
В тесты я не вкладывался, сделал по минимуму. Много что можно было бы улучшить, но пока желания нет
По коду тоже есть что сказать, но такие вещи проще и правильнее через PR делать.
Код я писал с очень большими паузами, выпадая из контекста. Поэтому могут встретиться какие-то странные вещи.
Сначала было MVP, которого мне хватало для моих задач. Потом я перестал заниматься задачами связанными с 1С, но жалко было бросать библиотеку. Поэтому решил допилить и опубликовать.
Сейчас я ее уже не использую, но иногда что-то доделываю если кто-то что-то просит.
С параметром Разделитель я никаких модификаций не произвожу, поэтому и без Знач.
Тут в другом дело. Я уже лет 15 убеждён, что 1С сделала ошибку, не сделав Знач по умолчанию (как поступили авторы C# c ref). По-хорошему почти-почти всё, кроме того, что явно модифицируется и отдаётся обратно должно быть знач.
Чемодан без ручки — очень точное сравнение. Весь такой красивый и качественный чемодан, но без ручки.
Одна из проблем 1С, что она не построена на базе технологии с виртуальными машинами (вроде .Net/Java). Да, при этом были бы дополнительные проблемы, но тогда подключение каких-то специфических редких вещей решалось бы просто добавлением зависимости в pom.xml (если Maven) и относительно небольшого кода по интеграции с самой платформой (так как все бы было в одной виртуальной машине).
Многое точно, про интерфейсы например. но про интеграции… работа с бинарными файлами точно по интеграции прямо необходимо? Много ты знаешь популярных форматов обмена, основанных на бинарке? Протобуф еще далеко не мейнстрим. А json вроде как текстовый.
В опенсорсе есть адаптер для AMQP (RabbitMQ) — модно и молодежно… С чем таким надо интегрироваться, что из 1С нельзя?
По авторизации — тоже да. Однако, в последних версиях вроде как OpenID и OIDC прикрутили. Не пробовал, говорят работает (KeyKloack и прочее сюда)
GraphQL и gRPC — да было бы неплохо, но в кровавом ентерпрайзе тоже пока не мейнстрим, скорее хипстерство.
В целом, приятно видеть продолжение статьи, хоть и в виде комментария, все по делу.
В статье не хватает рассмотрения еще некоторых особенностей. Однопоточный синхронный медленный интерпретатор. Нет возможности запуска асинхронных функций с получением результата не через базу (фоновые задания не предлагать!). Примитивная сборка мусора (алгоритм начала 90х). Нет разрешения циклических ссылочных зависимостей (сервер приложений легко течет по памяти, и нет средств поиска неисправности). Все эти факторы не позволяют реализовывать сложную бизнес-логику на встроенном языке (и поэтому есть такой распространенный паттерн запихивания бизнес логики в один запрос к базе). Но ее упорно напихивают в типовые решения.
Вроде же средства поиска циклических зависимостей добавили? Оно теперь вроде как в ТЖ их отображает, да можно какой то опцией заставить платформу при их нахождении ронять все) Но да, механизмы сборки мусора заставляют плакать. Особенно учитывая квалификацию многих разрабов.
Однопоточный синхронный медленный интерпретатор.
Ну сравните с Python — там сам интерпретатор такой же "Однопоточный синхронный медленный". Асинхронность и быстрость снаружи интерпретатора.
Примитивная сборка мусора
И у Python тоже! :) тот же самый refcount (о, кстати, в Kotlin Native, если ничего за год не изменилось — тоже).
python
Kotlin native
Из современных языков не считая крестов я только свифт знаю который опирается только на механизм подсчета ссылок и сильные/слабые ссылки для разрешения проблем. Во всех остальных давно так или иначе более умные gc. Да, у свифта по этой причине не будет пауз на сборку мусора, но насколько я знаю вполне существуют конкурентные сборщики мусора которые пусть дают свой оверхед, но не делают остановку мира. Плюс вроде как деление на поколения и частая работа сборщика тоже неплохо позволяет снизить проблемы с этим в случае если мир таки останавливаем.
The standard implementation of Python, CPython, uses reference counting to detect inaccessible objects, and another mechanism to collect reference cycles, periodically executing a cycle detection algorithm which looks for inaccessible cycles and deletes the objects involved.
Kotlin native
Q: What is Kotlin/Native memory management model?
A: Kotlin/Native provides an automated memory management scheme, similar to what Java or Swift provides. The current implementation includes an automated reference counter with a cycle collector to collect cyclical garbage.
Из современных языков не считая крестов я только свифт знаю который опирается только на механизм подсчета ссылок и сильные/слабые ссылки для разрешения проблем. Во всех остальных давно так или иначе более умные gc. Да, у свифта по этой причине не будет пауз на сборку мусора, но насколько я знаю вполне существуют конкурентные сборщики мусора которые пусть дают свой оверхед, но не делают остановку мира. Плюс вроде как деление на поколения и частая работа сборщика тоже неплохо позволяет снизить проблемы с этим в случае если мир таки останавливаем.
>Из современных языков не считая крестов я только свифт знаю который опирается только на механизм подсчета ссылок и сильные/слабые ссылки для разрешения проблем
Rust тоже только rc использует.
По моему опыту текущая ситуация с управлением памятью в 1С не является сколь-нибудь серьезной проблемой:
1. Код, допускающий утечки, сейчас можно отладить с помощью инструментов платформы (https://its.1c.ru/db/metod8dev#content:5859:hdoc)
2. Кластер серверов давно доступен в 64х битном варианте и чисто административными средствами — рестартом процессов по достижении заданного порога памяти — можно сделать незаметным отстутствие честного gc
Короче, на мой вкус вполне нормальный компромисс
Rust тоже только rc использует.
По моему опыту текущая ситуация с управлением памятью в 1С не является сколь-нибудь серьезной проблемой:
1. Код, допускающий утечки, сейчас можно отладить с помощью инструментов платформы (https://its.1c.ru/db/metod8dev#content:5859:hdoc)
2. Кластер серверов давно доступен в 64х битном варианте и чисто административными средствами — рестартом процессов по достижении заданного порога памяти — можно сделать незаметным отстутствие честного gc
Короче, на мой вкус вполне нормальный компромисс
Сейчас бы сравнивать язык нацеленный на системное программирование с прикладными)) Но да, про него забыл. Тем не менее это уж точно никак нельзя записать в плюсы 1с, а вот минус значимый. Перезапускать сервер тоже так себе идея, выгонять пользователей и все такое.
> Перезапускать сервер тоже так себе идея, выгонять пользователей и все такое.
Перезапускать сервер не надо. В кластере 1С работают процессы-вокеры, которыми кластер сам рулит. Вы в настройках кластера указываете порог памяти, при достижении которого вокером кластер автоматом запускает новый вокер, переносит на него все данные сеансов с которыми работал старый вокер, останавливает старый вокер. При этом сеансы продолжают жить (пользователь этого не замечает), просто начинают работать с другим серверным процессом-вокером.
Перезапускать сервер не надо. В кластере 1С работают процессы-вокеры, которыми кластер сам рулит. Вы в настройках кластера указываете порог памяти, при достижении которого вокером кластер автоматом запускает новый вокер, переносит на него все данные сеансов с которыми работал старый вокер, останавливает старый вокер. При этом сеансы продолжают жить (пользователь этого не замечает), просто начинают работать с другим серверным процессом-вокером.
Угу, а ничего что утекшая память в тех самых сеансах и висит в т.ч.?
Сеансы обычно имеют ограниченное время жизни (часы), существенно меньшее чем время жизни кластера от старта до рестарта. По собственному опыту — кластер, обслуживающий несколько сотен сеансов, рестартуем не чаще раза в несколько недель.
Автоматический рестарт процессов-вокеров кластером подчищает старые ошметки.
Автоматический рестарт процессов-вокеров кластером подчищает старые ошметки.
Вы ни разу не встречались с пользователями что в принципе не выключают комп и не закрывают приложения? Я вот сам такой.
Встречался, конечно. Такие «вечные» сеансы можно обыгрывать настройка параметров ИБ (https://v8.1c.ru/platforma/parametry-informacionnoy-bazy/).
Еще раз — рассказываю чисто по собственному опыту. Текущее положение дел по управлению памятью в кластере 1С не доставляет неудобств при наличии 64х битной версии и минимальных усилиях по администрированию кластера. Т.е. это (управление памятью) на мой взгляд вот точно не стоит рассматривать как ахиллесову пяту платформы.
Еще раз — рассказываю чисто по собственному опыту. Текущее положение дел по управлению памятью в кластере 1С не доставляет неудобств при наличии 64х битной версии и минимальных усилиях по администрированию кластера. Т.е. это (управление памятью) на мой взгляд вот точно не стоит рассматривать как ахиллесову пяту платформы.
Я тоже. Но пока пользователь ничего не делает, память у него не течет.
А так есть решение, программно сбрасывать сеансы в нерабочее время.
А так есть решение, программно сбрасывать сеансы в нерабочее время.
Отличная ссылка (https://its.1c.ru/db/metod8dev#content:5859:hdoc)! Во всех следующих обсуждениях можно копипастить оттуда цитаты, чтобы все программисты видели, с каким добром им придется иметь дело :)
А с каким добром? Управление памятью по счетчику ссылок. Что-то необычное там написано разве? То, что рантаймы со сборщиком мусора позволяют циклично ссылающимся объектам все-таки уничтожаться, не отменяет того, что код с циклично ссылающимися объектами — говнокод. И тут уже не язык виноват, что афтар так видит свой граф объектов.
А вот нифига не говнокод, например банальный пример со вью в том же андроиде. Активити ссылается на вью, но и вью как минимум имеет ссылку на контекст активити, а нередко и на саму активити когда навешиваются слушатели. И это вполне нормальная ситуация. И примеров таких можно море раскопать. В случае с подсчетом ссылок это решается слабыми ссылками, но это не для 1с.
В любом случае, для платформы позиционирующей себя как платформу для разработчиков в т.ч. очень низкого уровня — не очень косяк.
В любом случае, для платформы позиционирующей себя как платформу для разработчиков в т.ч. очень низкого уровня — не очень косяк.
С подсчетом ссылок придется городить костыли чтоб память не текла.
Какие костыли? В деструкторе сделать delete[] children, а в деструкторах листьев — декремент счетчика ссылок на родителя.
Если это кресты как раз тут то память и потечет. Потому что если у детей есть свои дети — массив children мы то освободим, но сами потомки продолжат существовать, на них то их children ссылаются а сами они ссылаться на свои подчиненные элементы.
Вот тут как раз выход в слабых ссылках (например на родителя).
Вот тут как раз выход в слабых ссылках (например на родителя).
Вот, тут более удобные средства поиска цикл. ссылок разобраны wonderland.v8.1c.ru/blog/razvitie-sredstv-diagnostiki
Ну сравните с Python — там сам интерпретатор такой же «Однопоточный синхронный медленный».
Вы это про какой python? CPython многопоточный.
Асинхронность и быстрость снаружи интерпретатора.
Серьезно? Асинхронность снаружи? Что такое yield и как работает знаете?
Лучшие алгоритмисты — это выпускники матмеха/физмата. Лучшие руководители команд — это люди с хорошим классическим образованием и практикой, знающим монографию Дрюри не понаслышке. 1С — это прокладка между налогоплательщиками и МНС. Установи мораторий на изменение налогового и бухгалтерского законодательства лет на 10, и 1С канет в лету.
1С — платформа интересная, много чего сделано на ее базе, но типовые продукты на ее базе в первую очередь рассчитаны на обслуживание интересов МНС, но никак не коммерческих предприятий.
1С — платформа интересная, много чего сделано на ее базе, но типовые продукты на ее базе в первую очередь рассчитаны на обслуживание интересов МНС, но никак не коммерческих предприятий.
>И еще — если к вам пришел наниматься 1С-ник, то 1С-ника можно смело ставить на должность лида аналитиков. Понимание задачи, предметной области, навыков декомпозиции у них развито великолепно.
>Человек обучен думать о смысле задачи в первую очередь, о связях между объектами предметной области, при этом имеет технический бэкграунд по интеграционным технологиям и форматам обмена данными.
Ржу и плакаю =) 95% не знают протоколов от слова совсем, нет в голове понятия. Не понимают даже элементарный rest web api, понятие делового моделирования в стиле OOP для них дырка, управления версиями конфигураций-кода почти неведомо,… там длинный список
Больше половины не знают что такое програмный автомат. Просто нет элементарных базовых знаний.
Когда одноэсники беседуют по проекту, у меня время цирка. По жизни стараюсь держатся от них подальше.
«Ну у них сайт написан… на языке… не 1C», «Мне не нужно знать этот ваш SOAP» — из разговоров.
>Человек обучен думать о смысле задачи в первую очередь, о связях между объектами предметной области, при этом имеет технический бэкграунд по интеграционным технологиям и форматам обмена данными.
Ржу и плакаю =) 95% не знают протоколов от слова совсем, нет в голове понятия. Не понимают даже элементарный rest web api, понятие делового моделирования в стиле OOP для них дырка, управления версиями конфигураций-кода почти неведомо,… там длинный список
Больше половины не знают что такое програмный автомат. Просто нет элементарных базовых знаний.
Когда одноэсники беседуют по проекту, у меня время цирка. По жизни стараюсь держатся от них подальше.
«Ну у них сайт написан… на языке… не 1C», «Мне не нужно знать этот ваш SOAP» — из разговоров.
Ну плохие вам коллеги попались, сочувствую. Есть такое в отрасли, это проблема низкого порога входа. Но есть и такие, кто делает CI, статический анализ, автотесты и интеграцию через Kafka, считая rest api слишком скучным и простым.
>Ну плохие вам коллеги попались, сочувствую.
И так _20_ лет, все плохие попадаются? =)
И еще — на 100 одноэсников только 2 знали английский что бы что-то сказать и читать.
Егожмать, английский — язык индустрии.
98 % чуваков не могут понять что-то, что написано на базовом индустриальном языке.
>Это проблема низкого порога входа.
Вообще-то наличие огромного количества приставок к бухгалтерии и учету и десяткам «рогов и копыт» — тяжелая социальная проблема. Там, на этой проблеме, одноэсники и кормятся, на проблеме. Даже не думая сильно. То есть 95% на этом пороге входа и остаются.
А че типа, мы и так нужные. Мы тут B2B из левого угла в правый и обратно автоматизируем.
В других, здоровых, странах таких проблем нет. Вооще другой диапазон автоматизации.
>Но есть и такие, кто делает CI, статический анализ, автотесты…
Да, наверное есть. Двое. Прячутся.
Давеча поймал такого 1с аналитика, глагольствовал об «enterprise resourse planning»
Задал ему вопрос, найдите мне, сэр, хоть что-то из планирования кейсов-програм-проектов производства-процессов в будущем, а не фиксации пост-фактум, тут яркий монолог про желтый рай и сдулся.
2019 год, если че.
Другой упорол четыре терабайта блобов в SQL базу. Пока производство не встало.
Раздутая «1c типа разработка» без альтернатив, иных понятий, иных компетенций, с дешевой до-индусской ставкой труда — это один из признаков социального заболевания.
И так _20_ лет, все плохие попадаются? =)
И еще — на 100 одноэсников только 2 знали английский что бы что-то сказать и читать.
Егожмать, английский — язык индустрии.
98 % чуваков не могут понять что-то, что написано на базовом индустриальном языке.
>Это проблема низкого порога входа.
Вообще-то наличие огромного количества приставок к бухгалтерии и учету и десяткам «рогов и копыт» — тяжелая социальная проблема. Там, на этой проблеме, одноэсники и кормятся, на проблеме. Даже не думая сильно. То есть 95% на этом пороге входа и остаются.
А че типа, мы и так нужные. Мы тут B2B из левого угла в правый и обратно автоматизируем.
В других, здоровых, странах таких проблем нет. Вооще другой диапазон автоматизации.
>Но есть и такие, кто делает CI, статический анализ, автотесты…
Да, наверное есть. Двое. Прячутся.
Давеча поймал такого 1с аналитика, глагольствовал об «enterprise resourse planning»
Задал ему вопрос, найдите мне, сэр, хоть что-то из планирования кейсов-програм-проектов производства-процессов в будущем, а не фиксации пост-фактум, тут яркий монолог про желтый рай и сдулся.
2019 год, если че.
Другой упорол четыре терабайта блобов в SQL базу. Пока производство не встало.
Раздутая «1c типа разработка» без альтернатив, иных понятий, иных компетенций, с дешевой до-индусской ставкой труда — это один из признаков социального заболевания.
В других, здоровых, странах таких проблем нет. Вооще другой диапазон автоматизации.
Ой, вот только про розовых заграничных пони не надо, я как бы в курсе чем там автоматизирован малый и средний бизнес. Уже и в каментах тут много про это писали, как там в "здоровых странах" с этим.
>я как бы в курсе чем там автоматизирован малый и средний бизнес.
«приход-уход-склад» массово в sass, и несильно напрягает.
пяток лидеров, поключиться дело 10-15 минут.
но автоматизация это несколько больше чем «приход-уход-склад»
впрочем, предполагаю, это вам вряд ли ведомо.
я понимаю, вы защищате свое мировозрение, но дело в том, что трава все равно зеленая, небо голубое, а перекос в массу дешевых «одноэсников» «поправить склад-бухгалтерию» нигде нигде больше не существует, кроме как в великой с ее вымороченным социумом.
«приход-уход-склад» массово в sass, и несильно напрягает.
пяток лидеров, поключиться дело 10-15 минут.
но автоматизация это несколько больше чем «приход-уход-склад»
впрочем, предполагаю, это вам вряд ли ведомо.
я понимаю, вы защищате свое мировозрение, но дело в том, что трава все равно зеленая, небо голубое, а перекос в массу дешевых «одноэсников» «поправить склад-бухгалтерию» нигде нигде больше не существует, кроме как в великой с ее вымороченным социумом.
Автор умолчал еще об одном недостатке: в 1С из «поздние версии» не совместимы с ранними, иначе говоря код, написанный в версии Version8_1 может уже не работать в Version8_3_10, его необходимо менять. Это все равно, что Excel документ 97 г. не откроется в Office 2010.
На это прямо указывает Справка 1С: ОбъектМетаданныхКонфигурация, свойство
РежимСовместимости (CompatibilityMode)
На это прямо указывает Справка 1С: ОбъектМетаданныхКонфигурация, свойство
РежимСовместимости (CompatibilityMode)
"Несовместимы"? Или как раз наоборот, "совместимы" и даже есть флаг принудительного выключения фич, чтобы ваше легаси работало на новом рантайме? Автор не умолчал, но может недостаточно акцентировал, что новые рантаймы могут быть бажными и приносить проблемы. Да, такая неприятность с 1С есть, я думал что раскрыл это, но перечитав, понял, что недостаточно. А вот с совместимостью по коду — все хорошо.
"-все хорошо"
Не работал в 1С, но, извините, как оценивать цитату из той же Справки:
«ПланСчетовМенеджер.<Имя плана счетов> (ChartOfAccountsManager.<Имя плана счетов>)
Метод
УстановитьОбновлениеПредопределенныхДанных (SetPredefinedDataUpdate)
Описан:
… Доступность:
Сервер, толстый клиент, внешнее соединение.
Вызов метода выполняет обращение к серверу.
Примечание:
В режиме совместимости конфигурации Версия8_3_4 доступность метода не зависит от использования в сеансе разделителей.
В режиме совместимости конфигурации Версия8_3_3 необходимость обновлять определяется следующим образом:
Обновление не будет производиться:
если в метаданных или в данных установлено НеОбновлятьАвтоматически,
если в метаданных или в данных установлено Авто, и текущий узел является периферийным.
В противном случае предопределенные данные будут обновлены и/или созданы при первом обращении к данным.
»
Не работал в 1С, но, извините, как оценивать цитату из той же Справки:
«ПланСчетовМенеджер.<Имя плана счетов> (ChartOfAccountsManager.<Имя плана счетов>)
Метод
УстановитьОбновлениеПредопределенныхДанных (SetPredefinedDataUpdate)
Описан:
… Доступность:
Сервер, толстый клиент, внешнее соединение.
Вызов метода выполняет обращение к серверу.
Примечание:
В режиме совместимости конфигурации Версия8_3_4 доступность метода не зависит от использования в сеансе разделителей.
В режиме совместимости конфигурации Версия8_3_3 необходимость обновлять определяется следующим образом:
Обновление не будет производиться:
если в метаданных или в данных установлено НеОбновлятьАвтоматически,
если в метаданных или в данных установлено Авто, и текущий узел является периферийным.
В противном случае предопределенные данные будут обновлены и/или созданы при первом обращении к данным.
»
При использовании конфигурации, которая написана на старой версии платформы, предусмотрен режим совместимости. Обратный вариант запуска (конфигурация новая, а платформа старая) не всегда возможен, да.
Ну и в .Net так же и в java, что именно вас удивляет?
Более того, если брать ваш пример с Excel, то, внезапно, не все возможности Excel 2010 поддерживаются форматом 97 года, о чем вам программа и сообщит, при попытке сохранения документа.
P.S. пример вообще не в кассу. он не про «не будет работать», а про «в новой версии изменилось поведение».
Ну и в .Net так же и в java, что именно вас удивляет?
Более того, если брать ваш пример с Excel, то, внезапно, не все возможности Excel 2010 поддерживаются форматом 97 года, о чем вам программа и сообщит, при попытке сохранения документа.
P.S. пример вообще не в кассу. он не про «не будет работать», а про «в новой версии изменилось поведение».
Так и оценивать — вы обновляете платформу — все ваши конфигурации автоматом работают в том режиме совместимости, для которого они разработаны. Поведение не изменяется. Программист читает примечания к релизу, подготавливает исходный код и поднимает режим совместимости. Если оно ему нужно, конечно. И тогда начинает раотать по новому.
Это не недостаток, это стандартная практика. Что-то обратно совместимо, что-то не совместимо.
.Net 2.0 не полностью совместим с .Net 4.6, а с .Net Core и подавно.
Код, написанный на Java 1.8 надо переписать чтоб запустить на Java 11.
Режим совместимости как раз нужен для того чтобы запустить в новой версии старое поведение. Что бы на 8.3.16 система работала так де как 8.2.14 ей устанавливается режим совместимости. Хочешь использовать все новое: смени режим и адаптируй всю кодовую базу.
Потому сравнение не верно. Он откроется и будет работать.
А можно уточнить о переходе с 1.8 на 11? Что то о таком не слышал (специально правда и не интересовался, все таки на андроиде даже восьмая жава полноценно недоступна, иногда добавляют фичей из нее в дешугаринг d8 но до сих пор не все покрыто и не будет судя по всему).
Давайте я вам стандартную фразу из ченджлога платформы приведу (с нее каждый список изменений начинается). Эта фраза описывает добавку нового режима совместимости.
Возможность запуска конфигураций, разработанных в версии 8.3.15 и более младших, в версии 8.3.16, без внесения изменений в конфигурацию и без изменений структур данных. Это позволяет при переходе на версию 8.3.16 сначала выполнить переход без внесения изменений в конфигурацию, а потом, внести необходимые изменения и снять режим совместимости. Так же это позволяет иметь возможность после перехода на версию 8.3.16, при необходимости, использовать для работы с информационной базой и версию 8.3.15. Это можно делать, как до снятия режима совместимости, так и после (установив вновь режим совместимости).
Поддержу автора, всё нужно рассматривать в сравнении, у 1с есть как и плюсы, так и минусы, сам когда начилал знакомится с данным продуктом, понимал что не 1с единым, нужно это понимать. Ведь тебе не кто не запрещает решать задачу эффективно спользуя другие языки
О каком холиваре вообще идет речь? И так всем все понятно и все знают о недостатках 1С. Лично я всем начинающим и студентам настоятельно советую держаться как можно дальше 1С, если вам не безразлично ваше будущее как разработчика.
Необходимость плотно поработать с продуктами западных компаний в бизнес-сфере и столкновение с реальными проблемами, очень сильно излечивают от пренебрежительного отношения к 1С. Может где-то и есть тот самый волшебный и технологичный софт, который пишется по чудесным спецификациям умных аналитиков, не менее умными программистами, использующими последние веяния технологий. Но сталкиваясь с реальностью далеко не маленьких, и с виду вполне технологичных контор, понимаешь, что все, что в этом мире приносит деньги, сильно завязано на legacy. а это формат csv, горы старого софта, который даже не подумают менять, файловый обмен, море excel, mainframe и туча людей, которые далеко не боги ни в аналитике ни в программировании. И в какую обертку микросервисов и веб-технологий его не заверни — внутри он тот же махровый монстр и никто его переписывать не будет. В мире финансов — так почти везде. Территория бывшего союза, кстати, гораздо более прогрессивна в этом плане. И далеко не в последнюю очередь из-за 1С.
Я в разное время работал и с 1С и с SAP и с Галактикой.
Сейчас я работаю с Парусом.
И вообще не понимаю, как можно в трезвом уме и светлой памяти выбрать 1С вместо Паруса в крупной организации.
Понятное дело, если организация мала, если совсем нет программистов, если всё устраивает «из коробки».
Но если коробочное решение не подходит, а не подходит оно для крупных организаций всегда, то Парус в разы лучше.
С точки зрения IT, Парус в разы лучше и SAPа и Галактики и 1С.
Сейчас я работаю с Парусом.
И вообще не понимаю, как можно в трезвом уме и светлой памяти выбрать 1С вместо Паруса в крупной организации.
Понятное дело, если организация мала, если совсем нет программистов, если всё устраивает «из коробки».
Но если коробочное решение не подходит, а не подходит оно для крупных организаций всегда, то Парус в разы лучше.
С точки зрения IT, Парус в разы лучше и SAPа и Галактики и 1С.
Аргументы? Я, понимаете какое дело, и видел парус и много слышал про него. Вот то, что я видел — никак не соответствует тому, что рекламируют те, кто про него рассказывает.
Диалог каждый раз такой:
— Парус на Оракле и поэтому он лучше SAP и 1С вместе взятых
— А чем именно
— Да всем!
— Например?
— Он для больших баз, которые только Оракл тянет
— Что это за базы такие?
— Больше терабайта!!!
— Только Оракл такое тянет?
— Да! и Парус!
— Окей, с базой понятно, а сама система чем лучше?
— Всем!
— А конкретнее?
— Всем! Лучше! Во всем!
Единственно чем Парус хорош — это ценой. Охотно покупают гос. организации, военные заводы и пр. Очень приятные суммы можно откатывать и закатывать. Кроме этого сектора Парус на рынке отсутствует, к сожалению. Прямо совсем не наблюдается.
- Для того, чтобы программировать под Парус не надо учить какой-то ещё язык. Знаний SQL и VB/JS/Perl/Python/Pascal более чем достаточно; а это значит, что для работы с Парусом проще найти специалиста, потому как для начала работы с ним вполне достаточно университетских знаний SQL;
- Самые критичные и важные и многие менее критичные и менее важные ограничения бизнес-логики заложены в "ядро" системы. А потому продать больше, чем произведено; исправить проводку в закрытом периоде и т.п. в разы сложнее, нежели в том-же 1С;
- Данные нормально хранятся в таблицах Oracle/PostgreSQL, а потому интегрировать самописные системы в разы проще с Парусом, потому-что не надо обмениваться всякими SOAP/WSDL/XML… это те-же таблицы в которые точно-также инсёртишь/апдейтишь/...
- Неимоверно качественно "изкоробки" работает учёт кадров и зарплаты, планирование производства; и он ещё крайне гибкий; Остальное тоже хорошо работает, но в остальном слишком много нюансов у каждого предприятия, а потому варианта "изкоробки" достаточно не бывает;
- Контроль прав на уровне базы данных (это про Парус 8, а не 10, который трёхзвенка); Т.е. нет какой-то прослойки для распределения прав;
- Если поднабраться опыта — то, опять таки, за счёт возможностей программирования "низкого уровня" — непосредственно в базе, — можно творить чудеса.
- Довольно мощный инструментарий "Табличных приложений" — мощная "интеграция" с электронными таблицами и MSProject;
- Довольно мощный инструментарий "Многомерных отчётов" — вполне себе OLAP, не самый мощный, не BI, но в большинстве случаев достаточно и этого;
- Довольно мощный инструментарий "Отчётов Drill-Down", чтоб в удобной форме отображать из каких первичных данных получились итоговые значения;
- Довольно мощный инструментарий "Регламентированных отчётов", — тут у меня нет слов, чтоб описать это как-то. Инструмент мощный, многогранный, удобный;
- Имеющиеся системы проще переводить именно на Парус, всё потому-же, что данные доступны просто в таблицах Oracle/PostgreSQL; Их проще наполнять имеющимися данными, синхронизировать и т.п.
- Парус — это не "чёрный ящик", как 1С. Если что-то где-то происходит, то всегда можно пройтись по коду, или тем-же дебагером, и понять что происходит. В 1С, зачастую, не понятно как там всё устроено. А на такую систему полагаться в критичных бизнес-процессах очень стрёмно.
Ваш ответ тянет на статью. Может оформите отдельно?
Хотелось бы еще стоимость и лицензионную политику, чтобы понять. смотреть, для своих целей или нет.
Парус — это не «чёрный ящик», как 1САбсолютно так же всё тожно пройти отладчиком
не надо обмениваться всякими SOAP/WSDL/XML… это те-же таблицы в которые точно-также инсёртишь/апдейтишь
Ну дальше можно не читать… Предлагать в 2019 году интеграцию посредством прямых инсертов в СУБД в качестве конкурентного преимущества, это прямо скажем удивляет! Ну и остальное по мелочи. Что и требовалось доказать — Парус это отличный способ отмыть баблишка в госсекторе, поэтому он нигде кроме как в нем не представлен от словам совсем. И подходы внедренцев и интеграторов от Паруса точно такие-же совковые, я знаю нескольких.
Самописная учетная система, основная база около терабайта, 1500 одновременно работающих пользователей. Небольшая часть работает в режиме толстого клиента, остальные тонкий и веб-клиенты. Никаких тормозов нет. Так что очень даже неплохо подходит большим предприятиям.
тот случай когда коментарии читать интереснее чем явную пропаганду 1С (где явные минусы плюсами сделали :-D )
На хабре же есть представители 1С (компании), может быть они как-то прояснят свое отношение к состоянию разработки в их фреймворке?
Им нельзя, мамка не велит ) Я за них отдуваюсь… Состояние разработки описано в статье — с точки зрения IDE все пока что так себе. Есть новая IDE в статусе беты. Когда на нее пересядет вся отрасль — мой прогноз — очень нескоро, не раньше 5 лет в будущее.
Да, я представитель 1С. 1С — лучшая система в мире. Покупайте и программируйте только на 1С. Это быстро, качественно и недорого.
Прочитал от корки до корки. Автору огромный респект за статью!
И все таки, мне кажется, open source захватит мир. Это не нормально, что идет отток программистов. Это не нормально что сама 1С — черный ящик. У меня лично складывается ощущение что 1С-ом правят какие то "волшебники".
Мне кажется в идеальном мире должна быть какая то другая бизнес модель. Ну как например у того же nginx. А все эти закрытые ядра, уже пройденный этап — Internet Explorer например.
Microsoft уже однажды профукал мобильных разработчиковМожет ли с 1С произойти тоже самое?
Полностью осгласен с автором, хотя на 1С не пишу уже лет 8.
Про недоспециалистов, которых легион, и которых шлют к вам учиться, вместо оказания полноценной поддержки. Так извините, пусть представитель ЯП/фреймворка/экосистемы в которой таких недоспециалистов нет, бросит в меня камень. Этот легион везде!!! И бороться надо с безграмотностью, а не с 1С.
Про недоспециалистов, которых легион, и которых шлют к вам учиться, вместо оказания полноценной поддержки. Так извините, пусть представитель ЯП/фреймворка/экосистемы в которой таких недоспециалистов нет, бросит в меня камень. Этот легион везде!!! И бороться надо с безграмотностью, а не с 1С.
«Используешь 1С — забудь про алгоритмы», помогите бабушке сдать отчетность в налоговую, а то что-то вся оборотка красная и непонятно откуда минусы. Статья хорошая, позновательная,
НО программист 1С <> инженер-программист
НО программист 1С <> инженер-программист
Лишь бы ляпнуть и пойти. Много ли в Java-разработке для предприятий тех алгоритмов, ась? А неучей там и подавно полно. Я насмотрелся, не проведешь.
Я не ляпнул, 1С-ом занимался с 2009-2018 г. сразу выбрал 8.0 а не 7.7, хоть и 7.7 имела доминирующее положение (даже сейчас есть конторы, которые сидят на 7.7, но только из-за того, что перенос данных и доработок стоит космос). Доминирующей работой специалиста 1С является поиск ошибки, приводящей к неверной отчетности, которую допустил пользователь при вводе данных (взять то же неоперативное проведение), а то что так делать нельзя — никому не интересно, т.к. руководитель послушает бухгалтера, чем программиста (особенно молодого). Так что 1С считаю хорошей учетной системой, НО, только в рамках того, что от нее требуется — учет прихода/расхода. То, что ПДФ создается одной строчкой в 1С — не считаю преимуществом, т.к. то же самое можно сделать и в ООП благодаря полиморфизму ;)
То, что ПДФ создается одной строчкой в 1С — не считаю преимуществом, т.к. то же самое можно сделать и в ООП благодаря полиморфизму
Именно полиморфизму? Точно не инкапсуляции?
А вы точно программист ООП или проверяете? Или вас смущает что может быть созданы объекты ReportPDF, ReportXLS и ReportTXT имеющие общего родителя с функцией вывода результата? К чему это больше подходит, к сокрытию или расширению функционала?
del — предыдущий камент отредактирован.
Меня смущает, что вы продолжаете ляпать про ООП и полиморфные объекты, а речь идет про конкретные реализации вывода в PDF на промышленных языках. Нет хорошей реализации вывода. А уж в какой класс "программист ООП" это потом вставит — совершенно несущественный вопрос.
А вот это как раз и существенный вопрос, т.к. программирование на 1С не особо заставляет думать над архитектурой (все уже придумали до нас). Вот это«куда вставить» потом боком и выходит, т.к. код разместил специалист в модуле формы и при обновлении все конечно же слетело :).
1С делает все, чтобы снизить стоимость разработчика. Взять те же самые управляемые формы и СКД. Все можно настроить из Предприятия, НО, пользователи же не хотят учиться и разбираться как это работает, поэтому проще взять кодера 1С, он и принтер подключит, и кофеварку починит, и оборотку исправит, онжепрограммист. А то, что в клиент-серверном варианте 1С не работает бар-код, это нормально, «можно же файловую базу развернуть, у вас все-равно мало людей с базой работает». Это мне внедренец 1С посоветовал ))))
Я ничего не имею против 1С, хорошая учетная система. Но называть сопровожденцев 1С — программистами, на мой взгляд не корректно, хотя бы в силу того, что в документации 1С нет описания типов данных и количества объема памяти, выделяемых для хранения. Хотя зачем это 1С…
И к стати, по поводу PDF — habr.com/ru/post/112707, статья от 2011 года, когда в 1С и в помине PDF-а не было.
1С делает все, чтобы снизить стоимость разработчика. Взять те же самые управляемые формы и СКД. Все можно настроить из Предприятия, НО, пользователи же не хотят учиться и разбираться как это работает, поэтому проще взять кодера 1С, он и принтер подключит, и кофеварку починит, и оборотку исправит, онжепрограммист. А то, что в клиент-серверном варианте 1С не работает бар-код, это нормально, «можно же файловую базу развернуть, у вас все-равно мало людей с базой работает». Это мне внедренец 1С посоветовал ))))
Я ничего не имею против 1С, хорошая учетная система. Но называть сопровожденцев 1С — программистами, на мой взгляд не корректно, хотя бы в силу того, что в документации 1С нет описания типов данных и количества объема памяти, выделяемых для хранения. Хотя зачем это 1С…
И к стати, по поводу PDF — habr.com/ru/post/112707, статья от 2011 года, когда в 1С и в помине PDF-а не было.
Оооо да. Поверьте, я видел и даже руками пробовал все эти библиотеки и не спроста гневаюсь на ситуацию с PDF в .NET
Вы прежде чем дальше со мной спорить, просто поверьте, что я не говорю с потолка ничего и никогда. Не пытайтесь выглядеть смешнее чем сейчас, например, рассуждая о том чего нет в документации 1С, когда оно там есть.
Какой вид сортировки используется в 1С?
В каком месте?
В динамическом списке
За сортировку отвечает СУБД, и не важно где вы программируете, в 1С, либо в каком-нибудь серьезном ООП проекте на Java или C++.
Вы что применяете знания ООП для сортировки или каждый раз пишите сортировку пузырьком на С++?
Вы что применяете знания ООП для сортировки или каждый раз пишите сортировку пузырьком на С++?
Если вы работали с 1С, то знаете, что прямого доступа к СУБД не имеется, а только через «сервер приложений», а как оно там устроено — знают только разработчики.
Ну в целом скорее полиморфизму кстати наверно)) Правда полиморифизм не только в ООП есть, просто ООП позволяет той самой инкапсуляцией типам поведение добавить.
Да. Человек занимается фундаментальными нерешенными проблемами вывода в pdf средствами ООП, а также сортировкой. Вы — автоматизацией бизнес-процессов. Чувствуете разницу?
Я за 20 лет писал на разных языках. При этом писать эвристики для NP-полной задачи мне пришлось только на 1С. Так что, не сочиняйте! Там все как и в других ЯП.
Не сказал бы я что Конфигуратор на столько плох, чтоб его ругать. Мне кажется, «плохому танцору всегда яйца мешают». Вот хранилище, контроль версий — это жесть какая-то в 1С. А конфигуратор пойдёт.
Про феноменальность и крутость печатных форм улыбнуло. С виду это дейстительно крутым кажется. А когда в деталях заморачиваешься, разбираешься, там такое встречаешь?.. Плакать хочется. Некоторые очевидные вещи приходится на коленях делать. При том, что в форматировании текста, это очевидные потребности. В общем, если не лукавить, то хорошие документы текстовые одним шрифтом, одним стилем можно сделать, а если ваш заказчик, любит написать договор с жирненькими словечками, наклонными буковками выделять слова, то там вы красиво ничего стоящего не делаете. Будет мучительная боль. Вообще с табличными документами в 1С нельзя допускать работать педантов, которые любят, чтобы не было лишнего, отступы были правильны и прочая непечатная хрень помещаемая не к месту их возмущает. (намекая на себя). Если вы курсовые, дипломные работы оформляли не как все пробельчиками, межстрочный интервал энтерами, а делали всё, как положено по стилям, с настройкой отступов межстрочных интервалов в стиле, как это в Word реализовано, то тут вы будете плакать, рыдать, ненавидеть 1С, и мечтать о расправе с Нуралиевым.
Про феноменальность и крутость печатных форм улыбнуло. С виду это дейстительно крутым кажется. А когда в деталях заморачиваешься, разбираешься, там такое встречаешь?.. Плакать хочется. Некоторые очевидные вещи приходится на коленях делать. При том, что в форматировании текста, это очевидные потребности. В общем, если не лукавить, то хорошие документы текстовые одним шрифтом, одним стилем можно сделать, а если ваш заказчик, любит написать договор с жирненькими словечками, наклонными буковками выделять слова, то там вы красиво ничего стоящего не делаете. Будет мучительная боль. Вообще с табличными документами в 1С нельзя допускать работать педантов, которые любят, чтобы не было лишнего, отступы были правильны и прочая непечатная хрень помещаемая не к месту их возмущает. (намекая на себя). Если вы курсовые, дипломные работы оформляли не как все пробельчиками, межстрочный интервал энтерами, а делали всё, как положено по стилям, с настройкой отступов межстрочных интервалов в стиле, как это в Word реализовано, то тут вы будете плакать, рыдать, ненавидеть 1С, и мечтать о расправе с Нуралиевым.
Я собственно об этом выше и писал, что не стоит смешивать печатные формы и отчеты. Это разные механизмы, и у них разные задачи. Печатные формы, в любом случае, должны строиться в графическом формате (типа CrystalReports, FastReports, JasperReports и т.д.).
Вот каким боком ваш ответ относится к комментарию, на который вы вроде как отвечаете?
Где там про смешение отчетов и печатных форм (я уж не говорю, что вообще «смешение» это существует только в воображении команды ls fusion)?
Более того, насчет «в графическом формате» — zurapa как раз и пишет, что «в графическом формате неудобно», в контексте сложных (читай «со сложным форматированием и кучей динамически изменяемых реквизитов») печатных форм.
Где там про смешение отчетов и печатных форм (я уж не говорю, что вообще «смешение» это существует только в воображении команды ls fusion)?
Более того, насчет «в графическом формате» — zurapa как раз и пишет, что «в графическом формате неудобно», в контексте сложных (читай «со сложным форматированием и кучей динамически изменяемых реквизитов») печатных форм.
Да, свободные печатные формы со стилевым оформлением — это сильно хуже, поскольку делаются на основе табличного документа со всеми плюсами и минусами. В случае договоров проще через вордовский или ОО шаблон, это да.
Но это родовой признак редактора — заточенность под отчеты и табличные документы, что не отменяет его удобства в этом направлении.
Но это родовой признак редактора — заточенность под отчеты и табличные документы, что не отменяет его удобства в этом направлении.
ри том, что в форматировании текста, это очевидные потребности. В общем, если не лукавить, то хорошие документы текстовые одним шрифтом, одним стилем можно сделать, а если ваш заказчик, любит написать договор с жирненькими словечками, наклонными буковками выделять слова, то там вы красиво ничего стоящего не делаете.
У меня наверное недостаточно опыта в таких задачах (менее требовательные заказчики?), но редко возникали проблемы с форматированием. В крайних случаях решалось с помощью шаблонов Word (для каких-нибудь договоров/счетов с хитрыми колонтитулами и факсимиле, когда не хотелось морочиться с копанием во встроенном табличном документе).
Формально, вашу задачу можно попробовать решать с помощью объекта «HTML документ», но да, там тоже будет боль.
Вообще, интересно было бы иметь возможность вставлять форматированный текст в конкретные ячейки табличного документа (или наоборот — вставлять табличный документ в форматированный текст). С другой стороны — в том же Excel такой возможности тоже нет (или есть?).
Большое спасибо за статью, удивительно здравый текст по такой холиварной теме. Очень редко профи дают себе труд высказаться, обычно обсуждают люди, слабо разбирающиеся в предмете) Единственный вопрос к слову «фреймворк». В моем понимании фреймворк- это что-то, написанное на языке. Джанго, Симфони, БСП- это фреймворки. А Платформа 1с все же платформа, как Питон, Джава и Си шарп, на мой взгляд. Фреймворк, включенный в платформу уже не очень фреймворк, на мой взгляд.
Просто в случае 1С на уровне платформы реализованы некоторые высокоуровневые абстракции из предметной области, поэтому граница «платформа/фреймворк» немного размыта.
Ну и есть такой любопытный момент, как «встроенные в платформу обработки» (просмотр списка активных пользователей, просмотр журнала регистрации), которые с одной стороны — недоступны для редактирования разработчиком (хотя можно подменять их вызов своими) и «зашиты» на уровне платформы, а с другой — являются обработками написанными на встроенном языке 1С (вообще, при переходе с 7 версии 1С на 8ую, меня дико радовало именно расширение возможностей встроенного языке, когда для многих объектов платформы, которые в предыдущих версиях были «черным ящиком», стали добавлять API).
Кстати, некоторые вещи наоборот, сначала появлялись как библиотеки на встроенном языке, а в последствии были встроены на уровне платформы (для увеличения быстродействия — строковые функции, например, или необходимости работы на более низком уровне — версионирование объектов).
Ну и есть такой любопытный момент, как «встроенные в платформу обработки» (просмотр списка активных пользователей, просмотр журнала регистрации), которые с одной стороны — недоступны для редактирования разработчиком (хотя можно подменять их вызов своими) и «зашиты» на уровне платформы, а с другой — являются обработками написанными на встроенном языке 1С (вообще, при переходе с 7 версии 1С на 8ую, меня дико радовало именно расширение возможностей встроенного языке, когда для многих объектов платформы, которые в предыдущих версиях были «черным ящиком», стали добавлять API).
Кстати, некоторые вещи наоборот, сначала появлялись как библиотеки на встроенном языке, а в последствии были встроены на уровне платформы (для увеличения быстродействия — строковые функции, например, или необходимости работы на более низком уровне — версионирование объектов).
Андрей, даже не представляю как вы перечитываете эти 700+ комментариев…
Есть ЕРП-Платформа. Тоже как и 1С «суперфреймворк» в вашей терминологии.
Как технически устроена можно здесь почитать https://erp-platforma.com/s?tex=1
Плюсы:
Работает сильно быстрее чем 1С и все конфигурирование в вебе.
Ценовой диапазон ниже
PDF — по сути одной галочкой
Программирование построено на концептуальном подходе аналогичном PL\SQL + как в экселе из ячеек строится интерфейс что тоже в целом понятно для пользователя.
Т.е. для человека имеющего опыт работы с БД — низкий прогр вхождения.
Минусы:
Нет такой экосистемы вокруг. Причина — компания не зарабатывает 60 миллиардов в год как 1С.
Нет бухглатерии. За ненадобностью. Можно разработать такую конфигурацию — но нет смысла. Большие трудозатраты — а на выходе маркетинговая конкуренция с 1С, которая будет проиграна в виду сильно разных весовых категорий.
(есть CRM, Управление проектами, HelpDesk, Документооборот и т.д. — то что востребовано)
Почему ЕРП-Платформа сильно быстрее работает: 1С хранит в БД только данные (насколько я понимаю). Обработку программ производит в ядре-интерпритаторе. Т.е. во время работы надо интерпретировать и выполнять, производить считывание данных из БД, их обработку, запись результатов и т.д.
ЕРП-Платформа делает по другому. Ядро само при разработке компилирует программы в процедуры и триггера в БД. И получает быстро-работающие элементы на уровне базы. В итоге ядру не нужно затрачивать ресурсы на интерпретацию программы, а просто нужно обратиться к уже скомпилированному элементу. Который кстати еще и произведет обработку данных на уровне БД без передачи ядру.
Ядру только надо построить интерфейс в зависимости от конфигурации и прав доступа, и обратиться к базе данных для получения или обработки нужной информации, которая сразу будет предоставлена и обработана на уровне БД.
Так же у ЕРП-Платформы нет проблем с обработкой событий. Это просто получается автоматически через триггера в БД. И я даже не могу себе представить, с какими сложностями 1С-овцы это реализовывали у себя в ядре… И даже думаю что если напрямую в БД изменить какие-то данные, 1С это не обработает, даже если в конфигурации стоит обработка на это событие. 1С просто не узнает об этом…
Настройка серверов — веб сервер и сервер БД. Это очень отработанные в мире вещи.
В своем ценовом диапазоне я вообще не знаю аналогов, напишите в комментариях, если таковые есть.
Есть ЕРП-Платформа. Тоже как и 1С «суперфреймворк» в вашей терминологии.
Как технически устроена можно здесь почитать https://erp-platforma.com/s?tex=1
Плюсы:
Работает сильно быстрее чем 1С и все конфигурирование в вебе.
Ценовой диапазон ниже
PDF — по сути одной галочкой
Программирование построено на концептуальном подходе аналогичном PL\SQL + как в экселе из ячеек строится интерфейс что тоже в целом понятно для пользователя.
Т.е. для человека имеющего опыт работы с БД — низкий прогр вхождения.
Минусы:
Нет такой экосистемы вокруг. Причина — компания не зарабатывает 60 миллиардов в год как 1С.
Нет бухглатерии. За ненадобностью. Можно разработать такую конфигурацию — но нет смысла. Большие трудозатраты — а на выходе маркетинговая конкуренция с 1С, которая будет проиграна в виду сильно разных весовых категорий.
(есть CRM, Управление проектами, HelpDesk, Документооборот и т.д. — то что востребовано)
Почему ЕРП-Платформа сильно быстрее работает: 1С хранит в БД только данные (насколько я понимаю). Обработку программ производит в ядре-интерпритаторе. Т.е. во время работы надо интерпретировать и выполнять, производить считывание данных из БД, их обработку, запись результатов и т.д.
ЕРП-Платформа делает по другому. Ядро само при разработке компилирует программы в процедуры и триггера в БД. И получает быстро-работающие элементы на уровне базы. В итоге ядру не нужно затрачивать ресурсы на интерпретацию программы, а просто нужно обратиться к уже скомпилированному элементу. Который кстати еще и произведет обработку данных на уровне БД без передачи ядру.
Ядру только надо построить интерфейс в зависимости от конфигурации и прав доступа, и обратиться к базе данных для получения или обработки нужной информации, которая сразу будет предоставлена и обработана на уровне БД.
Так же у ЕРП-Платформы нет проблем с обработкой событий. Это просто получается автоматически через триггера в БД. И я даже не могу себе представить, с какими сложностями 1С-овцы это реализовывали у себя в ядре… И даже думаю что если напрямую в БД изменить какие-то данные, 1С это не обработает, даже если в конфигурации стоит обработка на это событие. 1С просто не узнает об этом…
Настройка серверов — веб сервер и сервер БД. Это очень отработанные в мире вещи.
1С — Добро и зло. Расстановка точек в холиварах вокруг 1С