Как стать автором
Обновить

Комментарии 167

Подскажите пожалуйста, а поддержка вебсерверов кроме apache не планируется?
Кроме Apache еще поддерживается IIS.
Ух ты, IIS это прям привет из 2001 года и первый HelloWorld. Личные теплые воспоминания :)
Было бы здорово добавить поддержку nginx.
Зачем?
Учетная система на базе 1С в принципе не предназначена для таких нагрузок, которые выносит nginx.

Есть подтвержденные данные о таких нагрузках? На чем основывается ваше утверждение?

nginx — не сервер приложений, Карл.

Он примитивный сервер статики. Все сложное-умное nginx передает для обработки в другие подсистемы (как говорят англоязычные — «в верхний поток»)

Кластер 1С — это типичный сервер приложений.

Нагрузку которую способен держать многомудрый сервер приложений НА ПОРЯДКИ меньше нагрузки, которую способен держать простейший сервер статики.

На порядки, Карл!!! На порядки.
Не нужно никаких подтвержденных данных, пошевелить мозгами нужно.
не верю
Дело не в нагрузке. Я считаю nginx более современным решением. И лично для меня, самое важное — удобство работы, nginx просто удобней (глаз не дергается при чтении конфигов).

Nginx не сервер приложений, но и Apache им тоже, фактически, не является. Он значится как web-сервер. А возможность запуска приложений внутри web-сервера, на мой взгляд, немного устарела (это было здорово лет 12-15 назад). Отдельный сервер приложений является лучшим решением. Для меня в более правильной связкой выглядит: web-сервер -> сервер приложения -> приложение (nginx -> php-fpm -> скрипты, nginx -> uwsgi -> скрипты).

Поэтому и есть желание что бы была прямая связь: nginx -> 1C. Через модуль ли к nginx'у или через отдельный сервер приложений (коим, по сути, является Кластер 1С) не имеет значения.
Что мешает nginx ставить внешним, а 1С использовать в связке с apache который уже проксируется nginx`ом?
overhead?
Ну почему же, удобно, когда много сервисов, когда нужно поддерживать разные версии платформы (на один экземпляр апача можно повесить только один модуль веб-расширения), когда есть сервисы на других языках на том же сервере с интеграцией, например с OpenID.
В этом случае, разумеется, nginx будет замечательным выбором, но изначально это выглядело как nginx ради ngnix-а.
(изначально подумал о планировке один инстанс ngnix на одну базу)
Почему тонкий клиент написан на С++, а не на JavaScript? Зачем два раза писать одно и тоже?
Для того чтобы огрести проблемы в виде разного поведения и потом их героически преодолевать.
Превозмогать.
Чтобы работать нормально на слабом клиентском железе.
Графически — почти одно и тоже, но и скорость работы и возможности интеграции и тонкого клиента значительно больше.
Имхо, по сути клиент это приложения уровня веб-браузера, а они как раз на C++ и пишуться.
>Зачем мы сделали веб-клиент? Говоря несколько пафосно, такую задачу перед нами поставило время.
Скорее уже скоро нужно будет отказываться от обычного клиента в пользу веб-клиента и прогрессивных приложений.
Вот объясните, нафига это в случае 1С?
Вот есть склад, на складе старый комп — франкеншейн, собранный айтишниками «из того что было». На этот комп прилетают сборочные накладные. Старшой по складу их печатает, отдаёт не самым высокоинтеллектуальным подчинённым собирать, потом помечает в системе галочками «собрано» и «отгружено». Всё.
Вот за чем на этом компе браузер и вообще интернет? Чтобы порнуху смотрели и в одноклассниках зависали вместо работы?
Например, для реализации SaaS решений. Для упрощения инфраструктуры и затрат/рисков на ее поддержание.
Сервер может стоить на другом конце страны, вообще-то.

Скажите пожалуйста, а когда 1С начнёт работать с Apache HTTP актуальной версии? 2.0 уже фиг где найдёшь, 2.2 тоже уже устарел.

В 8.3.9 (и вроде даже в 8.3.8) поддерживается апач 2.4
В последнее время сильно радуете, много полезных новшеств: веб-клиент, открытый протокол oData, расширения конфигурации. Спасибо тому, человеку который продвигает все это у вас.
НЛО прилетело и опубликовало эту надпись здесь
Sonar JS — вот этот плагин http://docs.sonarqube.org/display/PLUG/JavaScript+Plugin ?

Да

на скриншоте Сонара написано TRUNK — почему не Master? Там SVN ?

Да
Спасибо, очень интересно, хотя мы своим клиентам не рекомендуем работу с веб-клиентом, т.к. он попросту недоработан и есть серьезные ограничения. Но как маркетинг статья хорошая, да.
А что именно вам кажется недоработанным в веб-клиенте? И какие вы видите в нем ограничения?
НЛО прилетело и опубликовало эту надпись здесь
На самом деле ограничение есть одно: необходимость использовать расширения браузера для некоторой функциональности.
Если у вас SaaS решение для мелкого бизнеса и невысокий уровень владения ИТ конечных пользователей, то это создает некоторые проблемы. Они боятся устанавливать что-либо :)
НЛО прилетело и опубликовало эту надпись здесь
Естественно, это все общее ограничение для Web-технологий. Просто это стоит учитывать, принимая решения об использование тонкого клиента или Web-клиента, только и всего.
— необъяснимые окна с ошибками в интерфейсах
— периодические проблемы отображения списков
— с передачей файлов побольше 1 мб проблемы
— в apache столкнулись с проблемой работы web-сервисов, пришлось откатится на IIS
По проблемам на v8@1c.ru писали?

— в apache столкнулись с проблемой работы web-сервисов, пришлось откатится на IIS

А что были за проблемы?
Кстати да, получили недавно доступ к этой тех.поддержке, и уже пишем.
Что касается apache, былв проблема с форматом веб-сервиса в том случае если не использовалась сериализация, а просто передавался в веб-сервис на 1С простой String.
На новых платформах не проверяли (и на новом Апаче тоже), у нас Apache пока что табу.
В основном Apache глючил при работе синхронизации с мобильной платформой. Только перешли на IIS сразу все стабилизировалось.

Что касается мобильного приложения на очень рады выходу 8.3.9, но есть один серьезный баг, который не получается победить, а именно, не обновляется мобильная платформа, если запускать отладку с платформы в windows, хотя в 8.3.7 — 8.3.8 это работало и это было ПРЕКРАСНО, а теперь приходится по 100 раз в день пересобирать приложение.
не обновляется мобильная платформа, если запускать отладку с платформы в windows

А можно подробнее? Что именно не обновляется, при каких условиях и т.п.
ВНИМАНИЕ! не разрабатывал под 1с уже два года, поэтому инфа может быть устаревшей!

Основная проблема была в работе с файлами и с упрошенными типами данных
Основная проблема была в работе с файлами и с упрошенными типами данных

А можно поконкретнее?
Спасибо!
Ну, плавающие ошибки содержащие только одну букву латинского алфавита вместо описания не напрягают практически, но можете пояснить почему событие табличной части «ПередОкончаниемРедактированияСтроки» срабатывает при преходе между ячейками одной строки? Однажды стало неприятным сюрпризом когда наткнулись.
Конечно, есть некоторые проблемы (чаще всего временные) и трудности, но у нас уже четвертый год работает коммерческое SaaS решение (не на 1cFresh). Полет нормальный. И с каждым релизом стабильность и производительность Web-клиента растет.
Если не секрет — почему на 1cFresh не стали SaaS решение делать?
Можно линк на сайт вашего SaaS решения?
Спасибо!
Ответил в личку.
Если не сложно, то и мне в личку. Вопросы те же.
Ответил.
Я правильно понимаю, что судя по архитектуре, СУБД и сервера приложений смотрят прямо в интернет из корпоративной сети?
В интернет смотрит веб-сервер, который по корпоративной сети обращается к серверу приложений. Сервер приложений в свою очередь обращается к серверу СУБД. Прямого доступа к серверу приложений и СУБД из интернета нет.
НЛО прилетело и опубликовало эту надпись здесь
Хочется плакать, разработчики платформы используют всю мощь современных языков и инструментов разработки, а разработчикам работающим в среде 1с об этом приходится только мечтать.
ИМХО разработчикам бизнес-приложений «вся мощь современных языков» скорее вредит, чем помогает.
Сила 1С как раз в разумном ограничении инструментария разработчика бизнес-приложения.
Ну а если все же нужна вся мощь — есть технология внешних компонентов.
Технология внешних компонентов не панацея. Хочется иметь хотя-бы нормальную среду разработки для начала с поддержкой плагинов. Иметь возможность полностью управлять поведением «управляемых» форм.
Сила 1С в ограничение — ну у многих мозг взрывается от «всей мощи современных языков». В отношение разумности есть большие сомнения — триада «справочник — документ — регистр» была актуальна в девяностые. Тогда да, был экстаз перевода бумажных форм в электронные. Сейчас это колодки на ногах предприятия.

По теме вопрос — на сенсорных экранах прокрутка в динамических списках пальцами работает? Что бы не новомодными кнопками внизу списка листать — а нативненько)
По теме вопрос — на сенсорных экранах прокрутка в динамических списках пальцами работает? Что бы не новомодными кнопками внизу списка листать — а нативненько)


Сейчас проверил на iPad в Safari — работает.
ИМХО разработчикам бизнес-приложений «вся мощь современных языков» скорее вредит, чем помогает.

К сожалению, эта мысль очень сильно укоренилась в 1С, и сама по себе тоталитарна, уж простите. Ведь таким образом, вы решаете за разработчика, что ему будет лучше с одной стороны, но при этом утверждать, что выражении x++ хуже чем x = x + 1, никак нельзя.
Прикладное программирование, конечно, не имеет дело с регистрами процессора или прямой работой с памятью, но оно от этого не перестало быть программированием, мы просто решаем другие задачи.

Я думаю сильно не ошибусь, но уже более 10 лет язык 1С не развивается. Наверное, нет ни одной типовой конфигурации 1С, где кол-во строк кода было бы меньше 100 тысяч. И к чему приводит эта «простота»? Загляните в модуля, посмотрите, что там происходит, многословные префиксы и суффиксы, ни к чему не обязывающие попытки описания интерфейсов через #Область, имена общих модулей и идентификаторов длиною под 100 символов (Пример: ЭлектронныйДокументооборотСКонтролирующимиОрганамиОбновлениеИнформационнойБазы), огромные процедуры с кучей параметров, проверки внутри проверок.
Развитие языка как раз для того и нужно, чтобы писать код было проще, но почему в 1С решили, что чтобы писать код проще – нужно остановить развитие языка, просто непонятно.

Армия разработчиков 1С почти всегда голосует против нововведений по очень простой причине:
1) не хочу никого обидеть, но разработчиков на 1С как таковых не так уж и много, подавляющее большинство, занимается доработками уже созданных решений

2) Люди устали, они просто только-только свыклись с управляемыми форми, тока поняли, как переделывать всё под асинхронность, тока-тока нащупали стабильные релизы, а тут какие-то умники заряжают про интерфейсы, классы и другое в 1С. Многим, когда 500 рыл в базе, звонки каждую минуту и другой головняк, подобные заявления кажутся «несерьёзными».

Никто не говорит про ООП, но ребята, ёлы-палы, давайте что-то делать с языком, хотя бы начать с namespace-ов каких-то, ну это же уже не дело.
НЛО прилетело и опубликовало эту надпись здесь
нет
Есть в 1С ООП.
Но только встроенные (написанные разработчиками платформы) объекты.
И их кастомизация разработчиками прикладных решений под конкретную задачу.
Еще есть внешние объекты — технология внешних компонент и COM-объекты.

Наличие объектов не показатель. Пишется все в процедурном стиле по факту, да и без возможности свои объекты добавлять это уныло.
О да, хотя бы синтаксического сахара добавили — и то хлеб бы был, я бы порадовался даже элементарным ++ и +=, об ООП видимо вообще бессмысленно даже мечтать. Хоть за управляемые формы спасибо, гораздо лучше того что раньше было.
ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокументИмениНуралиеваБорисаГеоргиевича (с)
В конфигурации, в поддержке которой я участвую, 899097 строк. Скажите какие инструменты я могу использовать чтобы не допустить деградации кода? Может быть у вас есть статический анализатор для 1с кода?
НЛО прилетело и опубликовало эту надпись здесь
Спасибо
Спасибо
Евангелисты — они такие евангелисты :-)
Петр — ознакомтесь на досуге с тем, как изменилось отношение евангелистов (да и всего) MS к «айтишникам» вообще и разработчикам в частности за последние 5 лет. Очень надеюсь, что это ваше (или того кто придет вам на смену) будущее.
По делу:
1. Нужен git в разработке. Убогое хранилище с кучей костылей в придачу (сорри тем кто их вынужден делать) при разработке даже небольших проектов — это издевательство.
2. Внедрите, наконец-то, разработанный умными людьми (вместо вас) xUnit в типовые и покройте типовые тестами (что сейчас уже умные люди делают вместо вас). Глядишь не придется отзывать релизы на следующий день, а у выходящих не будет висеть по 200 только призванных вами ошибок.
А потом поговорим про «что вредит, а что помогает».
Ну и начните наконец-то работать с нами (с комьюнити) вместо утверждений, что все что вы делаете — делается для нашего же блага. Понятно, что приятнее проводить время в ресторанах с ЛПР, но внедрять и пилить все это нам, а не им.
По вашим рассказам про работу с Платформой мы понимаем, что вы знаете КАК ВЕСТИ разработку. Ужас же со средствами разработки и состоянием типовых создает жуткий когнитивный диссонанс. Пора это вам в 1С признать и что-то с этим сделать.
НЛО прилетело и опубликовало эту надпись здесь
А потом 1С выкатит новую версию решения и… опять все тесты переписывать. Ну и позиция «среднему одинэснику все это не нужно» она же не только у 1С. У «средних одинэсников» тоже. И пример должен подать 1С. А еще лучше методологию разработки под это поправить
Насколько я понимаю, в последние годы 1С все более серьезно подходит к управлению качеством.
Есть различные наборы тестов, в т.ч. и для типовых.

Жаль, что для типовых конфигураций тестов еще маловато, похоже, и они не выносятся в общий доступ для возможности их расширения всей сетью партнеров и пользователей.
Жаль, что для типовых конфигураций тестов еще маловато, похоже, и они не выносятся в общий доступ для возможности их расширения всей сетью партнеров и пользователей.

Я очень ценю, что делает 1С, но позволю себе немного жесткой критики.

После продолжительного использования сценарного тестирования своей разработки, есть основание серьёзно задуматься на счет глубины проработки таких тестов в самой 1С. Другими словами — качество, а не количество этих тестов.

В объекте ТестируемоеПриложение, были ошибки (и частично еще остались), которые делали практически невозможным анализ ошибок клиента тестирования. И это выявляется сразу, при прогоне тестов, почему этого не заметили внутри 1С — я думаю потому что разработчик сценарного тестирования (конфигурации) не не был осведомлен о проблеме.

Давайте на чистоту, Петр пишет, что сценарное тестирование проводится, но при этом:
1. Когда я на партнерсах спросил разработчика конфигурации сценарное тестирование 3, используется ли эта разработка внутри 1С, я получил ответ — спросите у разработчиков.
2. Собственный опыт разработки тестов, не раз выявлял ошибки в платформе. Вопрос: почему внутри 1С, их сценарные тесты для типовых конфигураций проходят?

Я думаю, как минимум, на заметку 1С нужно взять то, какого качества эти тесты, что они проводят (я про типовые конфигурации). Например, даже в последней 8.3.9, если тестом заполнять табличную часть у которой последняя колонка автовыбор незаполненного — платформа начинает забивать табличную часть новыми строками, пока не завершит работу аварийно, нет возможности проверить ошибки, выдаваемые в модальных окнах, нет возможности нажимать на ссылки в декорациях, что, например, делает невозможным прогон тестов объектов, где это используется (например, в ERP2 справочник Виды номенклатуры, там невозможно нажать на Тип номенклатуры).

Вот и застряла мысль, вроде как тесты делаются, но насколько они качественные? Очень хочу ошибаться, но видимо все эти тесты сделаны на базе записи прокликиваний на коротких дистанциях.
Хороший комментарий, спасибо!

Всегда нужно помнить, что никакое тестирование не найдет 100% ошибок :(
Возможно, что часть сценариев просто не попадалась специалистам 1С, как бы странно это не звучало :)

Я 3 или 4 года назад спрашивал у разработчика конфигурации сценарное тестирование для УФ (тогда еще был прототип, помнится), используются ли тесты сценарного тестирования в типовых конфигурациях, получил аналогичный ответ :)
НЛО прилетело и опубликовало эту надпись здесь
Под качеством тестов понимаются очень конкретные вещи, но формат общения, в виде комментариев на тему, не предназначен для детальных выкладок. Приведенный вами скриншот, особой ясности также не добавляет. Своим сообщением, я хотел обратить внимание автора на эту тему с тестированием, потому что она упоминалась и в прошлых статьях, надеюсь, информация дошла по назначению.
На счет Ванессы, к сожалению принцип записи тестов там такой же, как в сценарном тестировании, поэтому я и мои коллеги довольно сдержанно относимся к этому продукту.
Если у вас есть возможность продемонстрировать, на примере ERP2 (демо), создание теста за часа три-четыре: Приход / Расход / Оплата, с анализом/проверкой проводок каждого документа, формированием/проверкой отчетов и затем переиспользование этого теста для организации другой цепи сценария, с другими товарами/услугами/валютой/контрагентами внутри, тогда это бы полностью закрыло все вопросы, говорю честно, не только для меня, но и для многочисленных 1С программистов. Из всего, что я видел по ванессе, выступления и другие ролики, содержат по большей части методику и технику развертывания.
У системы Тестер, с которой вы наверняка знакомы, очень мало инструментов по формированию отчетов по результатам тестирования, и других аналитических возможностей с дружественным интерфейсом, но с одной задачей он справляется хорошо — возможность быстро и коллективном режиме создавать тесты, не только как описал заказчик в тех задании, но и насколько качественно хочет это сделать сам разработчик или руководитель тестирования, покрывая всевозможные отклонения, нажатие кнопок, которые могут генерировать или задавать лишние вопросы и другое. На своей практике, именно этот момент мы считаем ключевым, и именно прогон таких тестов не раз показывал наличие ошибок в платформе.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за развернутый комментарий!
Но самое важное из всего сказанного я вижу здесь:
показанный вами сценарий с оплатой мы делали за 40 минут для ERP 2 и Бухгалтерии 3.0, но на мой взгляд это совсем не показатель.

Вот именно в этом месте я думаю наши точки зрения и расходятся, потому что это как раз и показатель, и это очень важно. Видимо, у нас разная выборка проблем. Стандарты, методики, терминология – это всё полезная информация. А вот ситуация, что в часы не вкладывают тестирование, это факт, который практически никак не подвержен изменениям под влиянием вышеуказанных знаний. Расшифрую: вы сколько угодно долго можете убеждать программиста пилящего обработку для инфостарта (выражения взято из ваших роликов) что тестирование – это эффективно, и ему воздастся за это, но в тоже самое время, утверждаете, что время потраченное на разработку теста – не показатель. Я против той точки зрения, что 1с-программисты такие вот «тёмные» люди, стандартов не читавшие, а вот если прочтут, то спустится на них озарение.
И совершенно неважно, как вы называете руководителя тестирования, QA-инженером или еще как-то, но если инструментарий не позволяет делать работу эффективно, все остальные процессы становятся неинтересными.
У вас есть много роликов и по часу, и по полтора. Если есть возможность сделать ролик на 40 минут, где в реальном времени создаётся указанный мной выше библиотечный тест – вы сделаете большой шаг навстречу обычному программисту.
НЛО прилетело и опубликовало эту надпись здесь
Я не думаю, что у нас есть четкий предмет для спора. У вас системный подход, сверху и донизу, тут вообще никаких нет вопросов. И я думаю, что 1С тоже делает тоже всё по стандартам, по критериям, и цифровые показатели покрытия у них на высоте. Тут как раз всё четко и понятно, а не понять, о чем вы пишите – невозможно. Другой вопрос — это не всегда работает. При всем богатстве методик и численных оценок, остается неудобный вопрос – почему тестирование на коленке, выявляет проблемы быстрее и раньше, чем тестирование по науке. Не подумайте, что я анархист какой-то, я тоже вижу порядок через игру по правилам, просто этот вопрос призван акцентировать внимание не только на методике по всей цепи, а и задуматься над тем, как происходит процесс разработки тестов, как организована сама рутина.
P.S. Спасибо за мою положительную оценку. Компанию ТехноНиколь я не знаю.
Люто поддерживаю. А то примеры типа «а тут мы викинем ассерт, так как на ноль делить нельзя» уже запепехали. Даешь реальные кейсытесты!
Вы можете выгружать объекты конфигурации в множество мелких файлов.
Затем отправлять их на git.
Получать с git.
И загружать эти объекты в конфигурацию.

Это уже давно как реализовано.
Когда про это последний раз слышал — у людей проблемы с идентификаторами предопределенных данных были, хотя помню смутно, могу и ошибаться конечно. А так да, в принципе подход рабочий, благо в одну строчку в командной строке выгрузка и загрузка происходит.
Скорее всего проблемы были из-за не понимания механизма предопределенных данных. Вот описание Статья о предопределенных на http://курсы-по-1с.рф/

Git и загрузка-выгрузка в файлы тут не при чем
Тому же python это почему то не вредит. И есть частные случаи, когда данные ограничения не совсем разумны. Если бы 1С работали с комьюнити, то смогли выявить тот инструментарий, который очень бы пригодился. А те «1Сники», кто только отчеты клепает продолжили бы их клепать на своем СКД, не пугаясь «всей мощи языка 1С».
Которую забросили. Только добавили возможность передачи двоичных данных. Но вот, то что просят многие это возврат из функций объектов ВК и передача в параметрах объектов ВК (и объектов 1С как это сделано в COM варианте) даже в планах нет. А там особо то ничего и не нужно делать. Просто подсчет ссылок только на стороне 1С и время жизни только на время вызова метода.
То есть для ДД это можно, а для других объектов 1С это нельзя (в том числе и объектов ВК).
Но вот для модальных и для асинхронных методов нужно вводить аналог C# async await.
О замыканиях не просит только ленивый. Опять же в управляемых формах серверный и клиентский код можно писать в одном модуле. И это прекрасно, но еще было бы эффективнее вызывать серверный код в виде замыкания, где бы захватывались переменные метода. Это бы значительно сократило время написания.

значение=ВызватьСерверныйМетод({ код который выполняется на сервере})

Ну и про свои чаяния про .Net Core в 1С промолчу
Есть разные варианты дикого подобия .Net Core в 1С, чем 1С очень гордится. ссылка
1С этим не гордится. Это мои статьи.
Как и эти
Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux II

1С, Linux, Excel, Word, OpenXML, ADO, Net Core

Которые есть и на этой площадке Мои публикации
К моему огромному сожалению интеграция с .Net Core 1C не нужно. А вот например Samsung вполне использует Tizen C# API reference
>разработчикам работающим в среде 1с об этом приходится только мечтать.

На мой взгляд:
— % таких разработчиков невелик
— львиная доля 1С-разработчиков решает прикладные задачи клиентов с минимальной технической морокой. Собственно за это и спасибо 1С

И любимый девиз таких разработчиков «фигак-фигак» и в продакшен. То, что люди привыкли сидеть в яме не значит, что там надо сидеть постоянно. Никаких проблем у 1С вывести разработку на современный уровень нет. Было бы желание, а разработчики подтянуться. Зато сколько проблем уйдет.
«львиная доля 1С-разработчиков решает прикладные задачи клиентов с минимальной технической морокой.» имеется в виду очевидно минимальные задачки типа бухгалтеру отчетик налабать видимо… Это да… Никаких проблем и git с тестами не нужен. Но там кто-то (не 1С ли) решил с SAP конкурировать. Хотя может только по размерам бюджетов и сопутствующим им вещам :-)
5 лет проработал 1С-ником, да и сейчас часто с ней сталкиваюсь, поэтому выскажу свое ИМХО.

Хотя, по-хорошему, это тема для отдельной большой статьи.

Как мне кажется, вопрос развития (а значит усложнения) средств разработки — это еще и вопрос экономики. Сейчас порог вхождения в мир «программирования на 1С» довольно низок. Есть куча стажеров/студентов/фрилансеров, которые поддерживают чьи-то базы на минимальном техническом уровне (обработку написать, реквизит добавить и т.д.). Это не хорошо и не плохо, это просто как есть, такова потребность рынка и 1С с партнерами ее удовлетворяет.
Усложнение средств разработки, усложнение языка и т.д. может привести к повышению порога вхождения, что в конечном итоге приведет к тому, что в профессии будут оставаться только люди более высокого уровня, а время на подготовку таких специалистов вырастет. В конечном итоге это приведет к удорожанию стоимости (а рынок 1С-ников и так подогрет не слабо) таких специалистов и сокращению их численности.
А этого 1С, подозреваю, допускать не хотела бы. Не говоря уж о бизнесе.

Понимаю, что это лишь один из возможных сценариев, но он кажется мне правдоподобным.

С другой стороны, я помню баттхерт от введения управляемых форм и как долго люди привыкали к ним. Думаю, введение существенных изменений в средства разработки 1С будет не болезненнее, чем переход на УФ,
Ну javascript развивается, куча фреймворков появилось, паттерны начинают юзать (MVVM например), веб-разработки при этом меньше не стало. Мне кажется ошибочным мнением, что развитие языка и платформы оттолкнет новых разработчиков, может даже наоборот привлечет как раз таки профи. На начальном этапе может и надо было сделать 1С массовым ПО, поэтому тут любые средства хороши, чтобы привлечь побольше разработчиков, но надо двигаться дальше. Поначалу ведь ты был сам себе менеджер, консультант и разработчик, а теперь на проекте это разные люди, и даже есть новые роли — например эксперт по технологическим вопросам. Всё вокруг изменилось, а язык остался прежним, с этим уже пора что-то делать…
Язык таких вещей не меняют по 3 раза в год.

До сих пор в эксплуатации огромное количество автоматизированных систем, созданных на предыдущей версии 1С — на v7, которая появилась еще в конце прошлого века.

Бизнесу (клиентам 1С) нужно решение проблем, а не модные фичи ради фич.
Проблема решается? Ну и зачем тогда тратить огромные деньги все переписывая.

Фичи языков не нужны в 1С.
Потому что то, что в других языках программисты решают самостоятельным написание кучи кода — в 1С решает платформа. И программисту остается просто выбрать нужную фичу (объект) для решения проблемы и чуть-чуть ее кастомизировать.
А не писать с нуля как это принято в других языках.

В 1С 7.7 ой как не хватало множественных табличных частей и до сих пор это тормозит достаточно сильно, хотя это можно реализовать на других объектах. И это не модная фича ради фичи, которая появилась в 8.х

Во первых пишутся новые системы, в т.ч. с нуля, во вторых не обязательно ломать обратную совместимость.
Множественный отбор в списках в 7.7 на уровне платформы реализован не был, однако с помощью 1С++, разработанной комьюнити, это было реализовано. И реализовано красиво, с помощью классов, вставить табличное поле было не сложнее чем в 8ке.
«львиная доля 1С-разработчиков решает прикладные задачи клиентов с минимальной технической морокой.»
Все почти так, но очень часто возникают проблемы и иного рода, если бы был инструмент, то можно было бы их решить без «костылей» в виде внешних компонент и каких-то скриптов на питоне.
Не приходится.

У 1С узкоспециализированный язык (и узкоспециализированный runtime и система объектов/классов), предназначенный для решения вполне конкретных задач.

Замечу — для весьма быстрого решения.
Никакие там «современные мощные языки» и рядом не лежали по скорости разработке в той сфере, для которой 1С и предназначена.

А для нестандартных вещей — есть COM-объекты, технологии внешних компонент и web-сервисов и пр. Да в конце концов есть HTTP. Вы можете написать сторонний софт и общаться с ним по REST API.
Этого не нужно, учитесь интегрировать.
https://habrahabr.ru/company/1c/blog/308420/
Миллионами методов 1С сие умеет.
Спасибо за ценное указание. Я каждый день чему нибудь учусь. Но похоже вы не поняли про что я писал.
+1 За описание схемы тестирования и за использование различных инструментов тестирования
Это, конечно, хорошо, но для вашей флагманской конфигурации УПП 1.3, которую используют производственные предприятия, тонкий и веб-клиенты практически почти бесполезны, поскольку они не поддерживают многие необходимые функции.
На данный момент флагманская — ERP 2.х, разве нет?
Здесь, например: v8.1c.ru/enterprise/ УПП названа флагманской. Местные 1с конторы предлагают именно это.
Но по факту — ERP 2.2 :)
По приведенной ссылке — баг, исправим.
Тогда исправьте и информацию о том, что 1с сервер поддерживает, например, PosgreSQL. Реальные внедренцы отказываются с ней работать, ссылаясь на кучу проблем и уверяя, что не могут в этом случае обеспечить нормальное функционирование системы, вынуждая клиентов тратить большие деньги на приобретение windows server и mssql с клиентскими лицензиями.
Но проблема, вообще-то, не в информации на сайте, а в том, что внедренцы предлагают именно УПП — возможно потому, что ERP они не знают в достаточной степени, ну и потому что ERP заметно дороже.
В случае с PostgreeSQL опять-таки проблема компетенций. Есть немало довольно серьезных проектов, которые работают на данной СУБД.
Так где же взять компетентных внедренцев? Понимаю, вопрос риторический…
Боюсь, это проблема не только области 1С :)
В данном случае не внедренцы нужны, а грамотные администраторы — у меня 5 клиентов (конфиги: Бух, УТ, Комплексная) работают на PostgreSQL и, если год назад все было, согласен очень печально, то сейчас никаких вопросов — все работает и хорошо!
Более того, при правильной настройке PostgreSQL под железо сервера, на 2 предприятиях тест Гилева выполняется быстрее, чем в MS SQL (на том же железе!)
Давайте не смешивать кислое и фиолетовое.
По приведенной ссылке имеется фактологическая ошибка.
Ваше утверждение о том, что 1С: Предприятие не поддерживает работу с PostgreSQL — это только ваше утверждение. Почему мифические внедренцы предлагают УПП и MS SQL — это отдельный вопрос. Радикально простой ответ на этот вопрос звучит так: эти внедренцы ничего другого не знают. Подозреваю, что мир не монохромен, и правильный ответ не так радикален.
Предлагается все-таки не разбрасываться абстрактными утверждениями (их много и у вас и у меня), а быть несколько более конструктивными. Если есть проблемы с PostgreSQL — пишите в поддержку: эти ошибки будут анализироваться и исправляться.
У меня нет проблем с PosgreSQL: просто не было возможности с ними столкнуться, по настойчивому требованию внедренцев (отнюдь не мифических, просто не хочу ославить их на всю страну, как бы к ним ни относился) директору пришлось пойти на покупку windows и mssql.
Представители 1С иногда заявляют публично, что Линукс не интересует клиентов, процент внедрений на нем очень мал. Да потому и мал, что внедренцы отказываются ставить на него 1С. По некомпетентности ли, или из-за реальных проблем — вам лучше судить.
Если у вас нет проблем — тогда зачем вы тиражируете чьи-то заявления, причин которых не понимаете? В ситуации, когда внедренец честно говорит: у меня нет компетенций по Линуск/Мак/Звездам смерти, я имею компетенции по Виндоуз/Юникс/Телепортаторам, по этому и предлагаю вам то, что предлагаю, никакого криминала сходу не видно. Есть честное предупреждение о своих возможностях. Печально, если отсутствие своих компетенций прикрывается обвинениями продукта в невозможности сделать что-то.
Представители 1С иногда заявляют публично, что Линукс не интересует клиентов, процент внедрений на нем очень мал

И прямо есть ссылки на такие заявления представителей 1С?
Да потому и мал, что внедренцы отказываются ставить на него 1С.

Да вроде не отказываются. Судя по партнерскому форуму — Линукс используется достаточно часто.
Насколько знаю, нету особых проблем с PosgreSQL, производительность не сколько не уступает mssql. Настройка PosgreSQL не слишком сложное занятие.
Проблема не в PostgreSQL, нисколько не сомневаюсь что она не уступает mssql. Проблема в 1С — взять хотя бы тему с блокировками на уровне записи. И в тех многочисленных «партнерах» 1С, которые внедряют этот продукт на местах.
Более того, даже всячески отговаривают от ERP 2.x, якобы по сыроватости последней…
Видимо у них нет экспертизы по внедрению ERP.
УПП сейчас нами особо не развивается, его сменил ERP.

Ну а по части «сыроватости» — пользователями 1С:ERP стали более 1300 компаний, продукт вполне зрелый.
Ну, я не могу знать их мотивов… По большей части типовые конфы — шаблон с различным уровнем наполнения.
А так уже лет 8 занимаюсь допиливанием УПП для нужд различных производств (от упаковки кофе до совхозов, молокозаводов и т.д.) и не скажу, что она тоже не была сыроватой… Так и помрет…
1) Насколько реально мигрировать с УПП 1.3 на ERP 2.0 с переносом всех данных?

2) Есть ли смысл такой миграции? Какие преимущества?

3) Когда планируете завершить жизненный цикл и поддержку УПП 1.3?

Заранее спасибо за ответы.
1) Насколько реально мигрировать с УПП 1.3 на ERP 2.0 с переносом всех данных?

Обычно мигрируют, перенося не всю информацию, а остатки и нормативно-справочную информацию. В составе 1С:ERP есть инструменты для переноса. Вот здесь есть информация по этому поводу, см. доклады с мероприятия «Телеконференция „Новые возможности для бизнеса — переход с 1С: УПП на 1С:ERP“»

2) Есть ли смысл такой миграции? Какие преимущества?

УПП больше не развивается, делаются только изменения для поддержки текущего законодательства и исправление найденных ошибок.

3) Когда планируете завершить жизненный цикл и поддержку УПП 1.3?

Официального решения пока нет, но предупредим за 3 года о снятии с поддержки.
Сайт поправим, спасибо!
Использовать Google Closure Library и завязаться на их «строгий» код стайл, было очень разумно, для такого крупного проекта. Наверняка это сэкономило кучу денег и времени на реализацию и поддержку веб версии клиента.
Одна из групп задач для команды разработки веб-клиента – это дальнейшее развитие функциональности. Функциональность веб-клиента должна быть идентична функциональности тонкого клиента


А можно по подробней (может не понял из статьи?), о текущих отличиях функциональности тонкого клиента и веб-клиента?
о текущих отличиях функциональности тонкого клиента и веб-клиента

Отличий практически нет. Имеется в виду — вся новая функциональность, которая реализуется в тонком клиенте, реализуется и в веб-клиенте. И наоборот.
Самое логичное использование веб-клиента 1С — создание «личных кабинетов» внешних пользователей. Тут куча очевидных плюсов для всех сторон процесса. Поэтому я часто выбираю именно эту технологию для решения подобных задач и просто в восторге от простоты реализации. Но есть серьезная проблема — чаще всего требуется прикреплять файлы в программу, а порой это основная задача веб-приложения. И, к сожалению, сделать удобный интерфейс пользователя не прибегая к костылям пока не удается. Нет drag'n'drop, для загрузки файлов открываются уродливые дополнительные окна, увеличивая число кликов. Поэтому и мне, и коллегам приходится использовать поле HTML документа и там запускать самописное веб-приложение с реализацией нужных функций. Каждый пишет свой клиентский и серверный велосипед и костыль для связи этого зоопарка с 1С. Ситуация ужасная. Уверен, если эта проблема в платформе будет решена, использование веб-клиента 1С для личных кабинетов и систем документооборота существенно возрастет.
Сейчас уже есть «почти» нормальный REST, очень многие вещи можно напрямую читать/писать через ajax.
И тогда полностью отвязываемся от дизайна 1С.
Оно конечно да. Но для web-клиента может писать «простой одинэсник», а для REST придется позвать хорошего разработчика frontend. А как выше утверждают господа из 1С — «мы для вашего блага урезаем функционал» :-)
Скажите, пожалуйста, как реализована работа с оборудованием: банковские терминалы, ФР, весы, — через расширения и технологии внешних компонент?
Да
А на каких платформах? Моя тщетная попытка с 1cfresh и Linux клиентом заставить работать USB ФР не увенчалась успехом.
Можно подробнее?
Решение во 1cfresh?
В нашем 1cfresh.com или в вашем?
Веб-клиент на Linux?
Из него цепляете внешнюю компоненту?
В сторону TypeScript не смотрите?

И немного оффтопик: какие планы насчет ПолеHTMLДокумента под Linuх? А под Windows — IE на все времена?
Тут человек интересуется, цитирую:
одинесники очередной раз рассказывают, как они летают в космоспилят тонких и веб-клиентов, с последующим их тестированием.
Пока они там еще теплые, спросите их – сколько они еще собираются жевать говно мамонтаиспользовать ИЕ в ПолеHTMLДокумента?
Источник: Кто на Хабре не забанен, спросите у 1С – когда они выкинут IE из платформы?
Не умаляю достоинств разработчиков веб клиента, но перенести по сути десктопный оконный интерфейс в веб-браузер — это жесть! Ставлю дырявый пятицентовик на то, что за пределами локальной сети, такой если можно выразится «сайт» ни один собственник не захочет выставить на обзор публики.

Почему нельзя было пойти по стопам SAP DYNPRO и реализовать внутри конфигуратора возможность наклепать собственных форм на java/javacript? Или почему нельзя пойти по стопам собственных разработчиков мобильной платформы, которые сначала тоже решили сделать десктопную копию интерфейса, а потом поняли, что облажались и реализовали отдельный интерфейс по мобильным стандартам?

в B2B сегменте достаточно часто используется. Тем более, что реализовать в веб клиенте 1с личный кабинет партнера или агента со всеми отчетами и прочим — дело часов.
Во-первых, эту проблему постарались решить введя новый интерфейс Такси. Получилось довольно неплохо.
Во-вторых, некоторые десктопные решения просто-таки на ура воспринялись незнакомой с 1С публикой. В частности, вкладочный интерфейс страницы.
В-третьих, это все-таки не сайт. Чтобы сделать публичный сайт, придется выдать немереную сумму денег за одни только лицензии. А вот в качестве личного кабинета партнера — очень даже подходит.
Кока-колла, в частности ДоброеПартнерство.РФ
На картинках изображен вовсе не обычный десктопный интерфейс.

Перед тем как делать «универсальный интерфейс» для браузера и для полноценного клиента — 1С реализовала специальный webоподобный интерфейс на десктопе.

Старый, классический десктопный — тоже остался доступен (не для веба, разумеется).
Путь SAP DYNPRO — тупиковый.
Они добровольно отказываются от своей силы, от специализации на вполне конкретных прикладных вещах, где программисты могли бы много времени экономить.
В 1С все сделано правильно. Несколько секунд — и у вас есть и структура БД, и формы для записи-чтения работают автоматически.
А потом чтобы по требованию консультантов реализовать поведение этих форм и объектов не предусмотренное платформой все равно приходится повторять функционал платформы, но со своими изменениями в логике работы + это глючит естественно и тормозит, ибо реализация не нативная. приходится такие костыли на десятки тысяч строк городить что ну его…
Очень интересно посмотреть на сценарии поведения на формах, которые могут потребоваться консультантам-аналитикам и которые невозможно реализовать в управляемых формах.
Не «невозможно реализовать» а «приходится повторять функционал платформы, но со своими изменениями в логике работы», например у нас есть справочник со своими иерархиями которые неограниченно могут создавать пользователи, есть возможность изменять положение в иерархии документами (с историей предыдущих положений естественно), строить иерархии по произвольному реквизиту и т.п. А теперь представьте мучения со всем этим добром когда пользователи для данного справочника требуют поведение аналогичное другим справочникам, в т.ч. с отборами по иерархии, отчетов и т.п. вещей. Ну или вообще банальный пример когда не нравится стандартный платформенный порядок кнопок командной панели, приходится ради перемещения одной кнопки убирать автозаполнение и закидывать их вручную.
Храните историю иерархии в периодическом РС, подчиненном регистратору (наряду с текущей иерархией, которая стандартная платформенная). Далее во всех отчетах на СКД эта произвольная иерархия подключается за 3 минуты. Несколько лет назад делалось подобное такое для бюджетирования, правда без «изменения иерархии документами», просто с хранением того, кто и когда иерархию поменял.
Так и делаем, но помимо отчетов это нужно еще в формах подбора, плюс в некоторых сценариях работы необходимо программно работать с этой иерархией. При этом в текущем проекте планируется что в этом справочнике не один миллион элементов будет.
не знаю за миллионы, но РС с nested sets показал себя неплохо на сотнях тысяч наименований.
Если такое называть костылями… Платформа дает переопределить? В чем костыль? В том, что есть желание, чтобы платформа догадалась о том, что вы хотите переопределить и сделала это за вас?

А вообще, хорошей практикой считается именно отключение автозаполнения для кнопочек, а произвольная иерархия — это проблема выбранного вами архитектурного решения, тут стоит подумать о другой реализации.
Произвольная иерархия (точнее множество создаваемых пользователями иерархий) это требование наших консультантов. А костыль в том что полностью аналогичный внешний вид как у платформы без диких извращений сделать не удается.

Управляемая форма представляет из себя xml файлик с описанием. И он либо составляется платформой автоматически, либо по тому конструктору, в котором все переопределено вами. Поведение исполнения программы не зависит от описания того как расположены кнопочки на форме. Потому не понимаю почему это может «тормозить» да еще и «естественно». И, заметьте, ни одной строчки кода)

А тут все просто, требуется в этих формах давать выбор иерархии, возможность перемещения, удаления и прочих стандартных команд, но поведение так просто не переопределить… В общем это вылилось в несколько тысяч строк кода формы, и еще пару десятков тысяч строк в общих модулях (ну там еще специфичный функционал правда дополнительно реализован) Это в дополнение к тому что чатсть приходится дублировать в другие формы где требуется работа с этими иерархиями.
Насчет нативной неверно выразился, имел в виду что когда это реализовано разработчиками платформы, гарантированно оттестировано — оно гораздо лучше чем реализованное вчерашними студентами на коленке.
Хотя изрядную долю говнокода возникшего вследствие спешки и написания конфигурации на управляемых формах методом копипаста кода из конфигурации на обычных формах отрицать к сожалению не могу.
Но тем не менее каждый при своем мнении останется, редко когда кто то кого то переубеждает в спорах в интернете. Вы, как я понимаю, так и продолжите стоять на том что язык следует максимально упрощать, я по прежнему буду считать что возможность создавать объекты например как это реализовано в js (ни разу не писал на нем, но на википедии примеры посмотрел), возможность использовать функции первого класса, замыкания (для обработки оповещения и перехода на сервер например) и тому подобные вещи только добавят удобства и больше возможностей по написанию хорошо структурированного и лаконичного кода.
Кстати говоря, управляемая форма — не нативная, это обычные формы были такими.

Управляемая форма представляет из себя xml файлик с описанием. И он либо составляется платформой автоматически, либо по тому конструктору, в котором все переопределено вами. Поведение исполнения программы не зависит от описания того как расположены кнопочки на форме. Потому не понимаю почему это может «тормозить» да еще и «естественно». И, заметьте, ни одной строчки кода)
Друзья, лучше оптимизируйте свою консоль кластера, крайне убогое приложение, как таковых функций по менеджменту лицензий в нем нет, хотя такие вещи есть у любого софта (кроме вашего). Элементарно посчитать с какого пакета сколько лицензий отдалось, это нужно делать вручную. Да и вообще оно не очень информативно.

Уделите еще внимание оптимизации работы с БД, создание кучи временных таблиц, на каждый чих обращение к БД. Научитесь кешировать запросы, и использовать хранимые процедуры и все возможности современных серверов БД. Реализовать это не так трудно было бы желание.

Вообще если брать конфигурацию под вашу систему и под веб приложение выполняющее те же задачи, то можно сильно удивиться, что приложение написанное под веб работает быстрей и на меньших ресурсах. Поэтому иногда проще либо написать самому либо взять готовую ERP систему или CRM систему написанную на PHP, PYTHON.

Единственный неоспоримый плюс вашей системы это система отчетов. Это так на вскидку.

А еще ваша система не умеет HTTP2.0, SFTP, Network Share и тд…
У меня складывается мнение, что вы живете в каменном веке, и реализовываете свой беклог по задачам 15 летней давности.
К сожалению, про отношение к разработке платформы под Linux, как к падчерице, соглашусь. В частности, очень большая проблема при текущем внедрении, сервер под Linux медленно отдаёт данные web-клиенту, например при пролистывании сформированного табличного документа (при сохранении mxl-файл занимает около 2.6 Мб) после каждой второй-третьей страницы притормаживает на 3-5 секунд (по firebug именно передача данных от сервера к клиенту), одно ядро 100% загрузки, потом отвисает. На сервере Debian 8 x64, Apache 2.4, отдали 8 ядер под него, 16 Гб оперативки. Простейший офисный компьютер с windows server 2008 и IIS таких задержек себе не позволяет. Уже больше 6 месяцев пишу в техподдержку 1С, но ощущение, что в никуда. :-( Ну и так, по мелочи, проблемы с отображением нестандартных шрифтов (OpenGost), записью данных, содержащих русские буквы, на внешний MS SQL.
Но нужно и похвалить специалистов: в новых релизах то, что некрасиво выглядит в конфигураторе, тонком и толстом клиентах под Linux, нормально отображается в web-клиенте.
В статье есть неточность — нет никакого байт-кода в 1С. Байт-код должен быть на языке низкого уровня, а в 1С это просто закодированные инструкции встроенного языка.
Также интересно, почему отказались от поддержки на тонком клиенте таблицы значений и дерева значений? Выход конечно есть — массив со структурами, но все-таки почему?
Несмотря на все преимущества web-клиента он все еще не работает с подписями-шифрованием, периодические проблемы с файловыми операциями.

Работает с подписями веб-клиент, за счет внешних компонент, которые доступны в браузерах.
Вот только внешние компоненты работают не в линуксах.

Если написать по технологии Native API, то будет работать и там.

Т.е. 1С заявляет о работе компонент, по факту «Если написать по технологии Native API, то будет работать и там», так? Где-то обман закрался. Не так ли?

Старые компоненты писанные на технологии СОМ в линухах работать естественно не будут. Новый писанные с помощью Native API будут. Не вижу обмана, это прописано в документации к платформе.

Если вы не понимаете о чем я пишу, давайте закончим. Или хотя бы разберитесь с тем, что есть и что работает в Линуксах от 1С, а что нет.
>>С самого начала мы отвергли идею какой-либо автоматической (хотя бы частичной) конверсии C++

Я понимаю, что это был 2006 год. Но сейчас вроде

Asm.js стал ещё быстрее

Например, после компиляции кода C++ в Asm.js с помощью компилятора Emscripten раньше потеря производительности была примерно двукратной, теперь же код Asm.js медленнее нативной программы не более чем в полтора раза.
Подскажите, а конфигуратор тоже через веб работает? Можно ли в браузере запустить конфигуратор или только десктоп для разработки?
Конфигуратор работает только на десктопе.
Интересно, а зачем в браузере?
Да наверное не за чем в целом. Читал статью и стало интересно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий