Одной из приятных особенностей технологии 1С:Предприятие является то, что прикладное решение, разработанное по технологии управляемых форм, может запускаться как в тонком (исполняемом) клиенте под Windows, Linux, MacOS X, так и как веб-клиент под 5 браузеров – Chrome, Internet Explorer, Firefox, Safari, Edge, и все это – без изменения исходного кода приложения. Более того – внешне приложение в тонком клиенте и в браузере функционирует и выглядит практически идентично.
Найдите 10 отличий (под катом 2 картинки):
Окно тонкого клиента на Linux:
То же окно в веб клиенте (в браузере Chrome):
Зачем мы сделали веб-клиент? Говоря несколько пафосно, такую задачу перед нами поставило время. Уже давно работа через Интернет стала необходимым условием для бизнес-приложений. Вначале мы добавили возможность работы через Интернет для нашего тонкого клиента (некоторые наши конкуренты, кстати, на этом и остановились; другие, напротив, отказались от тонкого клиента и ограничились реализацией веб-клиента). Мы же решили дать нашим пользователям возможность выбрать тот вариант клиента, который им подходит больше.
Добавление возможности работы через Интернет для тонкого клиента было большим проектом с полной сменой архитектуры клиент-серверного взаимодействия. Создание же веб-клиента — и вовсе новый проект, начинавшийся с нуля.
Итак, требования к проекту: веб-клиент должен делать то же самое, что и тонкий клиент, а именно:
Пользовательский интерфейс в 1С описывается в визуальном редакторе, но декларативно, без попиксельной расстановки элементов; используется около трех десятков типов элементов интерфейса — кнопки, поля ввода (текстовые, цифровые, дата/время), списки, таблицы, графики и т.д.
Клиентский код на языке 1С может содержать в себе серверные вызовы, работу с локальными ресурсами (файлами и т.п.), печать и многое другое.
И тонкий клиент (при работе через веб), и веб-клиент пользуются одним и тем же набором веб-сервисов для общения с сервером приложений 1С. Реализация у клиентов, конечно, разная – тонкий клиент написан на С++, веб-клиент – на JavaScript.
Проект создания веб-клиента стартовал в 2006 году, в нем (в среднем) участвовала команда из 5 человек. На отдельных этапах проекта привлекались разработчики для реализации специфической функциональности (табличного документа, диаграмм и т.д.); как правило, это были те же разработчики, что делали эту функциональность в тонком клиенте. Т.е. разработчики заново писали на JavaScript компоненты, ранее созданные ими на C++.
С самого начала мы отвергли идею какой-либо автоматической (хотя бы частичной) конверсии C++ кода тонкого клиента в JavaScript веб-клиента ввиду сильных концептуальных различий этих двух языков; веб-клиент писался на JavaScript с чистого листа.
В первых итерациях проекта веб-клиент конвертировал клиентский код на встроенном языке 1С непосредственно в JavaScript. Тонкий клиент поступает иначе — код на встроенном языке 1С компилируется в байт-код, и затем этот байт-код интерпретируется на клиенте. Впоследствии так же стал делать и веб-клиент – во-первых, это дало выигрыш в производительности, во-вторых – позволило унифицировать архитектуру тонкого и веб-клиентов.
Первая версия платформы 1С:Предприятие с поддержкой веб-клиента вышла в 2009 году. Веб-клиент на тот момент поддерживал 2 браузера – Internet Explorer и Firefox. В первоначальных планах была поддержка Opera, но из-за непреодолимых на тот момент проблем с обработчиками закрытия приложения в Opera (не удавалось со 100%-ной уверенностью отследить, что приложение закрывается, и в этот момент произвести процедуру отключения от сервера приложений 1С) от этих планов пришлось отказаться.
Всего в платформе 1С:Предприятие есть 4 проекта, написанных на JavaScript:
Структура каждого проекта напоминает структуру Java-проектов (или .NET проектов – кому что ближе); у нас есть неймспейсы, и каждый неймспейс лежит в отдельной папке. Внутри папки лежат файлы и классы неймспейса. В проекте веб-клиента около 1000 файлов.
Структурно веб-клиент по-крупному разделяется на следующие подсистемы:
Реализация всего вышеописанного на JavaScript – дело непростое. Возможно, веб-клиент 1С – одно из самых больших client-side приложений, написанных на JavaScript – около 450.000 строк. Мы активно используем в коде веб-клиента объектно-ориентированный подход, упрощающий работу с таким большим проектом.
Для минимизации размера клиентского кода мы вначале использовали свой собственный обфускатор, а начиная с версии платформы 8.3.6 (октябрь 2014) стали использовать Google Closure Compiler. Эффект использования в цифрах – размер фреймворка веб-клиента после обфускации:
Использование Google Closure Compiler помогло нам повысить быстродействие веб-клиента на 30% по сравнению с нашим собственным обфускатором. Кроме того, на 15-25% (в зависимости от браузера) снизился объем памяти, потребляемой приложением.
Google Closure Compiler очень хорошо работает с объектно-ориентированным кодом, поэтому его эффективность именно для веб-клиента максимально высокая. Closure Compiler делает для нас несколько хороших вещей:
В качестве среды разработки веб-клиента мы используем WebStorm.
Для анализа кода мы используем SonarQube, куда интегрируем статические анализаторы кода. С помощью анализаторов мы отслеживаем деградацию качества исходного кода на JavaScript и стараемся ее не допускать.
В ходе реализации проекта мы столкнулись с рядом интересных задач, которые нам пришлось решать.
Существуют ситуации, когда обфускирование исходного кода может помешать работе системы. Код, внешний по отношению к исполняемому коду веб-клиента, вследствие обфускации может иметь имена функций и параметров, отличающиеся от тех, которые наш исполняемый код ожидает. Внешним кодом для нас является:
Чтобы избежать обфускации при взаимодействии с сервером мы используем тэг @expose:
А чтобы избежать обфускации при взаимодействии с другими окнами мы используем так называемые экспортируемые интерфейсы (интерфейсы, у которых все методы являются экспортируемыми).
Как и все разработчики, имеющие дело со сложным Веб UI, мы быстро поняли, что DOM плохо подходит для работы с динамическим пользовательским интерфейсом. Практически сразу был реализован аналог Virtual DOM для оптимизации работы с UI. В процессе обработки события все изменения DOM запоминаются в памяти и, только при завершении всех операций, накопленные изменения применяются к DOM-дереву.
Чтобы наш веб-клиент работал быстрее, мы по максимуму стараемся задействовать штатные возможности браузера (CSS и т.п.). Так, командная панель формы (расположенная практически на каждой форме приложения) отрисовывается исключительно средствами браузера, динамической версткой на базе CSS.
Для функционального тестирования и тестирования производительности мы используем инструмент собственного производства (написанный на Java и C++), а также набор тестов, построенных на базе Selenium.
Наш инструмент универсален – он позволяет тестировать практически любые оконные программы, а потому подходит для тестирования как тонкого клиента, так и веб-клиента. Инструмент записывает действия пользователя, запустившего прикладное решение «1С», в файл-сценарий. В это же время происходит запись изображений рабочей области экрана — эталонов. При контроле новых версий веб-клиента сценарии проигрываются без пользовательского участия. В случаях несовпадения скриншота с эталонным на каком-либо шаге тест считается провалившимся, после чего специалист по качеству проводит расследование – ошибка это или запланированное изменение поведения системы. В случае запланированного поведения эталоны автоматически подменяются на новые.
Инструмент также проводит замеры производительности приложений с точностью до 25 миллисекунд. В ряде случаев мы закольцовываем части сценария (например, несколько раз повторяем ввод заказа) для анализа деградации времени выполнения со временем. Результаты всех замеров записываются в лог для анализа.
Наш инструмент тестирования и тестируемое приложение
Наш инструмент и Selenium дополняют друг друга; например, если какая-то кнопка на одном из экранов поменяла свое местоположение – Selenium это может не отследить, но наш инструмент заметит, т.к. делает попиксельное сравнение скриншота с эталоном. Также инструмент в состоянии отследить проблемы с обработкой ввода с клавиатуры или мыши, так как именно их он и воспроизводит.
Тесты на обоих инструментах (нашем и Selenium) запускают типовые сценарии работы из наших прикладных решений. Тесты автоматически запускаются после ежедневной сборки платформы «1С:Предприятие». В случае замедления работы сценариев (по сравнению с предыдущей сборкой) мы проводим расследование и устраняем причину замедления. Критерий у нас простой – новая сборка должна работать не медленнее предыдущей.
Для расследования инцидентов замедления работы разработчики используют разные инструменты; в основном используется Dynatrace AJAX Edition производства компании DynaTrace. Проводится запись логов выполнения проблемной операции на предыдущей и на новой сборке, затем логи анализируются. При этом время выполнения единичных операций (в миллисекундах) может не быть решающим фактором – в браузере периодически запускаются служебные процессы типа уборки мусора, они могут наложиться на время выполнения функций и исказить картину. Более релевантными параметрами в этом случае будет количество выполненных инструкций JavaScript, количество атомарных операций над DOM и т.п. Если количество инструкций/операций в одном и том же сценарии в новой версии увеличилось – это почти всегда означает падение быстродействия, которое нужно исправлять.
Также одной из причин падения производительности может быть то, что Google Closure Compiler по какой-то причине не смог сделать inline-подстановку функции (например, потому что функция рекурсивная или виртуальная). В этом случае мы стараемся исправить ситуацию, переписав исходный код.
В случае, когда прикладному решению нужна функциональность, которой нет в JavaScript, мы используем расширения браузеров:
Наши расширения состоят из двух частей. Первая часть – то, что называется расширением браузера (как правило, написанные на JavaScript расширения для Chrome и Firefox), которые взаимодействуют с бинарным расширением, реализующим нужную нам функциональность. Надо упомянуть, что мы пишем 3 версии бинарных расширений – под Windows, Linux и MacOS. Бинарное расширение поставляется в составе платформы 1С:Предприятие и находится на сервере приложений 1С. При первом вызове с веб-клиента оно загружается на клиентский компьютер и устанавливается в браузере.
При работе в Safari наши расширения используют NPAPI, при работе в Internet Explorer — технологию ActiveX. Microsoft Edge пока не поддерживает расширения, поэтому веб-клиент в нем работает с ограничениями.
Одна из групп задач для команды разработки веб-клиента – это дальнейшее развитие функциональности. Функциональность веб-клиента должна быть идентична функциональности тонкого клиента, вся новая функциональность реализуется одновременно и в тонком, и в веб-клиенте.
Другие задачи — развитие архитектуры, рефакторинг, повышение производительности и надежности. Например, одно из направлений – дальнейшее движение в сторону асинхронной модели работы. Часть функциональности веб-клиента на настоящий момент построена на синхронной модели взаимодействия с сервером. Асинхронная модель сейчас становится в браузерах (и не только в браузерах) более актуальной, и это заставляет нас модифицировать веб-клиент путем замены синхронных вызовов на асинхронные (и соответствующего рефакторинга кода).
Найдите 10 отличий (под катом 2 картинки):
Окно тонкого клиента на Linux:
То же окно в веб клиенте (в браузере Chrome):
Зачем мы сделали веб-клиент? Говоря несколько пафосно, такую задачу перед нами поставило время. Уже давно работа через Интернет стала необходимым условием для бизнес-приложений. Вначале мы добавили возможность работы через Интернет для нашего тонкого клиента (некоторые наши конкуренты, кстати, на этом и остановились; другие, напротив, отказались от тонкого клиента и ограничились реализацией веб-клиента). Мы же решили дать нашим пользователям возможность выбрать тот вариант клиента, который им подходит больше.
Добавление возможности работы через Интернет для тонкого клиента было большим проектом с полной сменой архитектуры клиент-серверного взаимодействия. Создание же веб-клиента — и вовсе новый проект, начинавшийся с нуля.
Постановка задачи
Итак, требования к проекту: веб-клиент должен делать то же самое, что и тонкий клиент, а именно:
- Отображать пользовательский интерфейс
- Исполнять клиентский код, написанный на языке 1С
Пользовательский интерфейс в 1С описывается в визуальном редакторе, но декларативно, без попиксельной расстановки элементов; используется около трех десятков типов элементов интерфейса — кнопки, поля ввода (текстовые, цифровые, дата/время), списки, таблицы, графики и т.д.
Клиентский код на языке 1С может содержать в себе серверные вызовы, работу с локальными ресурсами (файлами и т.п.), печать и многое другое.
И тонкий клиент (при работе через веб), и веб-клиент пользуются одним и тем же набором веб-сервисов для общения с сервером приложений 1С. Реализация у клиентов, конечно, разная – тонкий клиент написан на С++, веб-клиент – на JavaScript.
Немного истории
Проект создания веб-клиента стартовал в 2006 году, в нем (в среднем) участвовала команда из 5 человек. На отдельных этапах проекта привлекались разработчики для реализации специфической функциональности (табличного документа, диаграмм и т.д.); как правило, это были те же разработчики, что делали эту функциональность в тонком клиенте. Т.е. разработчики заново писали на JavaScript компоненты, ранее созданные ими на C++.
С самого начала мы отвергли идею какой-либо автоматической (хотя бы частичной) конверсии C++ кода тонкого клиента в JavaScript веб-клиента ввиду сильных концептуальных различий этих двух языков; веб-клиент писался на JavaScript с чистого листа.
В первых итерациях проекта веб-клиент конвертировал клиентский код на встроенном языке 1С непосредственно в JavaScript. Тонкий клиент поступает иначе — код на встроенном языке 1С компилируется в байт-код, и затем этот байт-код интерпретируется на клиенте. Впоследствии так же стал делать и веб-клиент – во-первых, это дало выигрыш в производительности, во-вторых – позволило унифицировать архитектуру тонкого и веб-клиентов.
Первая версия платформы 1С:Предприятие с поддержкой веб-клиента вышла в 2009 году. Веб-клиент на тот момент поддерживал 2 браузера – Internet Explorer и Firefox. В первоначальных планах была поддержка Opera, но из-за непреодолимых на тот момент проблем с обработчиками закрытия приложения в Opera (не удавалось со 100%-ной уверенностью отследить, что приложение закрывается, и в этот момент произвести процедуру отключения от сервера приложений 1С) от этих планов пришлось отказаться.
Структура проекта
Всего в платформе 1С:Предприятие есть 4 проекта, написанных на JavaScript:
- WebTools – общие библиотеки, используемые остальными проектами (сюда же мы включаем Google Closure Library).
- Элемент управления ФорматированныйДокумент (реализован на JavaScript и в тонком клиенте, и в веб-клиенте)
- Элемент управления Планировщик (реализован на JavaScript и в тонком клиенте, и в веб-клиенте)
- Веб-клиент
Структура каждого проекта напоминает структуру Java-проектов (или .NET проектов – кому что ближе); у нас есть неймспейсы, и каждый неймспейс лежит в отдельной папке. Внутри папки лежат файлы и классы неймспейса. В проекте веб-клиента около 1000 файлов.
Структурно веб-клиент по-крупному разделяется на следующие подсистемы:
- Управляемый интерфейс клиентского приложения
- Общий интерфейс приложения (системные меню, панели)
- Интерфейс управляемых форм, включающий, в том числе, около 30 элементов управления (кнопки, различные типы полей ввода – текстовые, цифровые, дата/время и пр., таблицы, списки, графики и т.д.)
- Объектная модель, доступная разработчикам на клиенте (всего более 400 типов: объектная модель управляемого интерфейса, настройки компоновки данных, условного оформления и пр.)
- Интерпретатор встроенного языка 1С
- Расширения браузеров (используются для функциональности, не поддерживаемой в JavaScript)
- Работа с криптографией
- Работа с файлами
- Технология внешних компонент, позволяющая их использовать как в тонком, так и веб-клиенте
Особенности разработки
Реализация всего вышеописанного на JavaScript – дело непростое. Возможно, веб-клиент 1С – одно из самых больших client-side приложений, написанных на JavaScript – около 450.000 строк. Мы активно используем в коде веб-клиента объектно-ориентированный подход, упрощающий работу с таким большим проектом.
Для минимизации размера клиентского кода мы вначале использовали свой собственный обфускатор, а начиная с версии платформы 8.3.6 (октябрь 2014) стали использовать Google Closure Compiler. Эффект использования в цифрах – размер фреймворка веб-клиента после обфускации:
- Собственный обфускатор – 1556 кб
- Google Closure Compiler – 1073 кб
Использование Google Closure Compiler помогло нам повысить быстродействие веб-клиента на 30% по сравнению с нашим собственным обфускатором. Кроме того, на 15-25% (в зависимости от браузера) снизился объем памяти, потребляемой приложением.
Google Closure Compiler очень хорошо работает с объектно-ориентированным кодом, поэтому его эффективность именно для веб-клиента максимально высокая. Closure Compiler делает для нас несколько хороших вещей:
- Статическая проверка типов на этапе сборки проекта (обеспечивается тем, что мы покрываем код аннотациями JSDoc). В итоге получается статическая типизация, очень близкая по уровню к типизации в С++. Это помогает отловить достаточно большой процент ошибок на стадии компиляции проекта.
- Уменьшение размера кода через обфускацию
- Ряд оптимизаций выполняемого кода, например, такие как:
- inline-подстановки функций. Вызов функции в JavaScript – достаточно дорогая операция, и inline-подстановки часто используемых небольших методов существенно ускоряют работу кода.
- Подсчет констант на этапе компиляции. Если выражение зависит от константы, в него будет подставлено фактическое значение константы
В качестве среды разработки веб-клиента мы используем WebStorm.
Для анализа кода мы используем SonarQube, куда интегрируем статические анализаторы кода. С помощью анализаторов мы отслеживаем деградацию качества исходного кода на JavaScript и стараемся ее не допускать.
Какие задачи решали/решаем
В ходе реализации проекта мы столкнулись с рядом интересных задач, которые нам пришлось решать.
Обмен данными с сервером и между окнами
Существуют ситуации, когда обфускирование исходного кода может помешать работе системы. Код, внешний по отношению к исполняемому коду веб-клиента, вследствие обфускации может иметь имена функций и параметров, отличающиеся от тех, которые наш исполняемый код ожидает. Внешним кодом для нас является:
- Код, приходящий с сервера в виде структур данных
- Код другого окна приложения
Чтобы избежать обфускации при взаимодействии с сервером мы используем тэг @expose:
/**
* @constructor
* @extends {Base.SrvObject}
*/
Srv.Core.GenericException = function ()
{
/**
* @type {string}
* @expose
*/
this.descr;
/**
* @type {Srv.Core.GenericException}
* @expose
*/
this.inner;
/**
* @type {string}
* @expose
*/
this.clsid;
/**
* @type {boolean}
* @expose
*/
this.encoded;
}А чтобы избежать обфускации при взаимодействии с другими окнами мы используем так называемые экспортируемые интерфейсы (интерфейсы, у которых все методы являются экспортируемыми).
/**
* Экспортируемый интерфейс контрола DropDownWindow
*
* @interface
* @struct
*/
WebUI.IDropDownWindowExp = function(){}
/**
* Перемещает выделение на 1 вперед или назад
*
* @param {boolean} isForward
* @param {boolean} checkOnly
* @return {boolean}
* @expose
*/
WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly){}
/**
* Перемещает выделение в начало или конец
*
* @param {boolean} isFirst
* @param {boolean} checkOnly
* @return {boolean}
* @expose
*/
WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly){}
/**
* @return {boolean}
* @expose
*/
WebUI.IDropDownWindowExp.prototype.selectValue = function (){}We used Virtual DOM before it became mainstream)
Как и все разработчики, имеющие дело со сложным Веб UI, мы быстро поняли, что DOM плохо подходит для работы с динамическим пользовательским интерфейсом. Практически сразу был реализован аналог Virtual DOM для оптимизации работы с UI. В процессе обработки события все изменения DOM запоминаются в памяти и, только при завершении всех операций, накопленные изменения применяются к DOM-дереву.
Оптимизация работы веб-клиента
Чтобы наш веб-клиент работал быстрее, мы по максимуму стараемся задействовать штатные возможности браузера (CSS и т.п.). Так, командная панель формы (расположенная практически на каждой форме приложения) отрисовывается исключительно средствами браузера, динамической версткой на базе CSS.
Тестирование
Для функционального тестирования и тестирования производительности мы используем инструмент собственного производства (написанный на Java и C++), а также набор тестов, построенных на базе Selenium.
Наш инструмент универсален – он позволяет тестировать практически любые оконные программы, а потому подходит для тестирования как тонкого клиента, так и веб-клиента. Инструмент записывает действия пользователя, запустившего прикладное решение «1С», в файл-сценарий. В это же время происходит запись изображений рабочей области экрана — эталонов. При контроле новых версий веб-клиента сценарии проигрываются без пользовательского участия. В случаях несовпадения скриншота с эталонным на каком-либо шаге тест считается провалившимся, после чего специалист по качеству проводит расследование – ошибка это или запланированное изменение поведения системы. В случае запланированного поведения эталоны автоматически подменяются на новые.
Инструмент также проводит замеры производительности приложений с точностью до 25 миллисекунд. В ряде случаев мы закольцовываем части сценария (например, несколько раз повторяем ввод заказа) для анализа деградации времени выполнения со временем. Результаты всех замеров записываются в лог для анализа.
Наш инструмент тестирования и тестируемое приложение
Наш инструмент и Selenium дополняют друг друга; например, если какая-то кнопка на одном из экранов поменяла свое местоположение – Selenium это может не отследить, но наш инструмент заметит, т.к. делает попиксельное сравнение скриншота с эталоном. Также инструмент в состоянии отследить проблемы с обработкой ввода с клавиатуры или мыши, так как именно их он и воспроизводит.
Тесты на обоих инструментах (нашем и Selenium) запускают типовые сценарии работы из наших прикладных решений. Тесты автоматически запускаются после ежедневной сборки платформы «1С:Предприятие». В случае замедления работы сценариев (по сравнению с предыдущей сборкой) мы проводим расследование и устраняем причину замедления. Критерий у нас простой – новая сборка должна работать не медленнее предыдущей.
Для расследования инцидентов замедления работы разработчики используют разные инструменты; в основном используется Dynatrace AJAX Edition производства компании DynaTrace. Проводится запись логов выполнения проблемной операции на предыдущей и на новой сборке, затем логи анализируются. При этом время выполнения единичных операций (в миллисекундах) может не быть решающим фактором – в браузере периодически запускаются служебные процессы типа уборки мусора, они могут наложиться на время выполнения функций и исказить картину. Более релевантными параметрами в этом случае будет количество выполненных инструкций JavaScript, количество атомарных операций над DOM и т.п. Если количество инструкций/операций в одном и том же сценарии в новой версии увеличилось – это почти всегда означает падение быстродействия, которое нужно исправлять.
Также одной из причин падения производительности может быть то, что Google Closure Compiler по какой-то причине не смог сделать inline-подстановку функции (например, потому что функция рекурсивная или виртуальная). В этом случае мы стараемся исправить ситуацию, переписав исходный код.
Расширения браузеров
В случае, когда прикладному решению нужна функциональность, которой нет в JavaScript, мы используем расширения браузеров:
- для работы с файлами
- для работы с криптографией
- работа с внешними компонентами
Наши расширения состоят из двух частей. Первая часть – то, что называется расширением браузера (как правило, написанные на JavaScript расширения для Chrome и Firefox), которые взаимодействуют с бинарным расширением, реализующим нужную нам функциональность. Надо упомянуть, что мы пишем 3 версии бинарных расширений – под Windows, Linux и MacOS. Бинарное расширение поставляется в составе платформы 1С:Предприятие и находится на сервере приложений 1С. При первом вызове с веб-клиента оно загружается на клиентский компьютер и устанавливается в браузере.
При работе в Safari наши расширения используют NPAPI, при работе в Internet Explorer — технологию ActiveX. Microsoft Edge пока не поддерживает расширения, поэтому веб-клиент в нем работает с ограничениями.
Дальнейшее развитие
Одна из групп задач для команды разработки веб-клиента – это дальнейшее развитие функциональности. Функциональность веб-клиента должна быть идентична функциональности тонкого клиента, вся новая функциональность реализуется одновременно и в тонком, и в веб-клиенте.
Другие задачи — развитие архитектуры, рефакторинг, повышение производительности и надежности. Например, одно из направлений – дальнейшее движение в сторону асинхронной модели работы. Часть функциональности веб-клиента на настоящий момент построена на синхронной модели взаимодействия с сервером. Асинхронная модель сейчас становится в браузерах (и не только в браузерах) более актуальной, и это заставляет нас модифицировать веб-клиент путем замены синхронных вызовов на асинхронные (и соответствующего рефакторинга кода).
Поделиться с друзьями
GerrAlt
Подскажите пожалуйста, а поддержка вебсерверов кроме apache не планируется?
Provlax
Кроме Apache еще поддерживается IIS.
negodnik
Ух ты, IIS это прям привет из 2001 года и первый HelloWorld. Личные теплые воспоминания :)
polyn0m
Было бы здорово добавить поддержку nginx.
bnytiki
Зачем?
Учетная система на базе 1С в принципе не предназначена для таких нагрузок, которые выносит nginx.
fishca
Есть подтвержденные данные о таких нагрузках? На чем основывается ваше утверждение?
bnytiki
nginx — не сервер приложений, Карл.
Он примитивный сервер статики. Все сложное-умное nginx передает для обработки в другие подсистемы (как говорят англоязычные — «в верхний поток»)
Кластер 1С — это типичный сервер приложений.
Нагрузку которую способен держать многомудрый сервер приложений НА ПОРЯДКИ меньше нагрузки, которую способен держать простейший сервер статики.
На порядки, Карл!!! На порядки.
Не нужно никаких подтвержденных данных, пошевелить мозгами нужно.
fishca
polyn0m
Дело не в нагрузке. Я считаю nginx более современным решением. И лично для меня, самое важное — удобство работы, nginx просто удобней (глаз не дергается при чтении конфигов).
Nginx не сервер приложений, но и Apache им тоже, фактически, не является. Он значится как web-сервер. А возможность запуска приложений внутри web-сервера, на мой взгляд, немного устарела (это было здорово лет 12-15 назад). Отдельный сервер приложений является лучшим решением. Для меня в более правильной связкой выглядит: web-сервер -> сервер приложения -> приложение (nginx -> php-fpm -> скрипты, nginx -> uwsgi -> скрипты).
Поэтому и есть желание что бы была прямая связь: nginx -> 1C. Через модуль ли к nginx'у или через отдельный сервер приложений (коим, по сути, является Кластер 1С) не имеет значения.
ZEEGIN
Что мешает nginx ставить внешним, а 1С использовать в связке с apache который уже проксируется nginx`ом?
jetexe
overhead?
ZEEGIN
Ну почему же, удобно, когда много сервисов, когда нужно поддерживать разные версии платформы (на один экземпляр апача можно повесить только один модуль веб-расширения), когда есть сервисы на других языках на том же сервере с интеграцией, например с OpenID.
jetexe
В этом случае, разумеется, nginx будет замечательным выбором, но изначально это выглядело как nginx ради ngnix-а.
(изначально подумал о планировке один инстанс ngnix на одну базу)
Provlax
Почему тонкий клиент написан на С++, а не на JavaScript? Зачем два раза писать одно и тоже?
fishca
Для того чтобы огрести проблемы в виде разного поведения и потом их героически преодолевать.
hardex
Превозмогать.
Zverienish
Чтобы работать нормально на слабом клиентском железе.
AAristar
Графически — почти одно и тоже, но и скорость работы и возможности интеграции и тонкого клиента значительно больше.
alexkmbk
Имхо, по сути клиент это приложения уровня веб-браузера, а они как раз на C++ и пишуться.
andrewev
>Зачем мы сделали веб-клиент? Говоря несколько пафосно, такую задачу перед нами поставило время.
Скорее уже скоро нужно будет отказываться от обычного клиента в пользу веб-клиента и прогрессивных приложений.
vanxant
Вот объясните, нафига это в случае 1С?
Вот есть склад, на складе старый комп — франкеншейн, собранный айтишниками «из того что было». На этот комп прилетают сборочные накладные. Старшой по складу их печатает, отдаёт не самым высокоинтеллектуальным подчинённым собирать, потом помечает в системе галочками «собрано» и «отгружено». Всё.
Вот за чем на этом компе браузер и вообще интернет? Чтобы порнуху смотрели и в одноклассниках зависали вместо работы?
Drac013
Например, для реализации SaaS решений. Для упрощения инфраструктуры и затрат/рисков на ее поддержание.
bnytiki
Сервер может стоить на другом конце страны, вообще-то.
merlin-vrn
Скажите пожалуйста, а когда 1С начнёт работать с Apache HTTP актуальной версии? 2.0 уже фиг где найдёшь, 2.2 тоже уже устарел.
PeterG
Версия платформы 8.3.8 (выпущена 20.04.2016) поддерживает Apache 2.4.
ars_ivanov
В 8.3.9 (и вроде даже в 8.3.8) поддерживается апач 2.4
mgis
В последнее время сильно радуете, много полезных новшеств: веб-клиент, открытый протокол oData, расширения конфигурации. Спасибо тому, человеку который продвигает все это у вас.
alexey-lustin
2 вопроса
маленькая заметка про Web клиент — когда разбирались с автоматизированным тестирование Web клиента 1C через Silenium обратили внимание что id элементов несколько сложноваты для быстрого покрытия тестами, пришлось тоже писать обертку.
Но в целом статья очень полезна. Спасибо большое.
PeterG
Да
Да
iliabvf
Спасибо, очень интересно, хотя мы своим клиентам не рекомендуем работу с веб-клиентом, т.к. он попросту недоработан и есть серьезные ограничения. Но как маркетинг статья хорошая, да.
PeterG
А что именно вам кажется недоработанным в веб-клиенте? И какие вы видите в нем ограничения?
alexey-lustin
было только одно ограничение — внутри платформы компонент "поле HTML документа" имеет ограничение на встраивание сложных JS скриптов.
Причем ограничение только в компетенциях — есть примеры как встраивать интересные виджеты внутрь Web клиента 1С http://infostart.ru/public/398366/
Других "прям ограничений" лично мне неизвестно — за исключением конечно привычки обычных 1С разработчиков делать "перенасыщенные рабочие столы", которые все таки не Web ориентированы.
Тут большая надежда на типовые конфигурации которые задают тон в отделении "Рабочих столов" от "метаданных"
Drac013
На самом деле ограничение есть одно: необходимость использовать расширения браузера для некоторой функциональности.
Если у вас SaaS решение для мелкого бизнеса и невысокий уровень владения ИТ конечных пользователей, то это создает некоторые проблемы. Они боятся устанавливать что-либо :)
alexey-lustin
А причем тут платформа 1С ?
Это штатное поведение Web технологий — JS выполняется в зоне Sandbox и это стандарт. Хочешь расширить функциональность: вариантов 3
Доставка и управления дистрибутива тонкого клиента на компьютерах нормально решаемая задача — особенно для провайдер аSaaS решения.
Я с вами согласен — геморой есть, но он как бы НЕ платформенен, он просто такой по всей индустрии.
Drac013
Естественно, это все общее ограничение для Web-технологий. Просто это стоит учитывать, принимая решения об использование тонкого клиента или Web-клиента, только и всего.
iliabvf
— необъяснимые окна с ошибками в интерфейсах
— периодические проблемы отображения списков
— с передачей файлов побольше 1 мб проблемы
— в apache столкнулись с проблемой работы web-сервисов, пришлось откатится на IIS
PeterG
По проблемам на v8@1c.ru писали?
А что были за проблемы?
iliabvf
Кстати да, получили недавно доступ к этой тех.поддержке, и уже пишем.
Что касается apache, былв проблема с форматом веб-сервиса в том случае если не использовалась сериализация, а просто передавался в веб-сервис на 1С простой String.
На новых платформах не проверяли (и на новом Апаче тоже), у нас Apache пока что табу.
В основном Apache глючил при работе синхронизации с мобильной платформой. Только перешли на IIS сразу все стабилизировалось.
Что касается мобильного приложения на очень рады выходу 8.3.9, но есть один серьезный баг, который не получается победить, а именно, не обновляется мобильная платформа, если запускать отладку с платформы в windows, хотя в 8.3.7 — 8.3.8 это работало и это было ПРЕКРАСНО, а теперь приходится по 100 раз в день пересобирать приложение.
PeterG
А можно подробнее? Что именно не обновляется, при каких условиях и т.п.
jetexe
ВНИМАНИЕ! не разрабатывал под 1с уже два года, поэтому инфа может быть устаревшей!
Основная проблема была в работе с файлами и с упрошенными типами данных
PeterG
А можно поконкретнее?
Спасибо!
Neikist
Ну, плавающие ошибки содержащие только одну букву латинского алфавита вместо описания не напрягают практически, но можете пояснить почему событие табличной части «ПередОкончаниемРедактированияСтроки» срабатывает при преходе между ячейками одной строки? Однажды стало неприятным сюрпризом когда наткнулись.
Drac013
Конечно, есть некоторые проблемы (чаще всего временные) и трудности, но у нас уже четвертый год работает коммерческое SaaS решение (не на 1cFresh). Полет нормальный. И с каждым релизом стабильность и производительность Web-клиента растет.
PeterG
Если не секрет — почему на 1cFresh не стали SaaS решение делать?
Можно линк на сайт вашего SaaS решения?
Спасибо!
Drac013
Ответил в личку.
BrandStorm
Если не сложно, то и мне в личку. Вопросы те же.
Drac013
Ответил.
A1astor
Я правильно понимаю, что судя по архитектуре, СУБД и сервера приложений смотрят прямо в интернет из корпоративной сети?
MaestroOlmer
В интернет смотрит веб-сервер, который по корпоративной сети обращается к серверу приложений. Сервер приложений в свою очередь обращается к серверу СУБД. Прямого доступа к серверу приложений и СУБД из интернета нет.
alexey-lustin
На архитектуре нарисовано что напрямую в сервер приложений "ходит" тонкий клиент — по TCP. Если говорить правильно то "может ходить", но этот TCP порт обычно открывается только для Администратора и только внутри "периметра".
Обычные пользователи ходят по HTTP/s протоколу через тот же тонкий клиент. И через тот же Web адаптер ходит как тонкий клиент, так и Web клиент (ваш браузер скачавший JS код Web клиента 1С). Причем насколько я помню есть возможность обеспечить аутентификацию клиентскими сертификатами.
Это я к тому что если вас волнует безопасность — то стандарт де факто это:
все эти возможности платформа обеспечивает, а дальше только вопрос компетенций команды инфраструктуры и команды внедрения.
akabrr
Хочется плакать, разработчики платформы используют всю мощь современных языков и инструментов разработки, а разработчикам работающим в среде 1с об этом приходится только мечтать.
PeterG
ИМХО разработчикам бизнес-приложений «вся мощь современных языков» скорее вредит, чем помогает.
Сила 1С как раз в разумном ограничении инструментария разработчика бизнес-приложения.
Ну а если все же нужна вся мощь — есть технология внешних компонентов.
fishca
Технология внешних компонентов не панацея. Хочется иметь хотя-бы нормальную среду разработки для начала с поддержкой плагинов. Иметь возможность полностью управлять поведением «управляемых» форм.
panvartan
Сила 1С в ограничение — ну у многих мозг взрывается от «всей мощи современных языков». В отношение разумности есть большие сомнения — триада «справочник — документ — регистр» была актуальна в девяностые. Тогда да, был экстаз перевода бумажных форм в электронные. Сейчас это колодки на ногах предприятия.
По теме вопрос — на сенсорных экранах прокрутка в динамических списках пальцами работает? Что бы не новомодными кнопками внизу списка листать — а нативненько)
PeterG
Сейчас проверил на iPad в Safari — работает.
grumegargler
К сожалению, эта мысль очень сильно укоренилась в 1С, и сама по себе тоталитарна, уж простите. Ведь таким образом, вы решаете за разработчика, что ему будет лучше с одной стороны, но при этом утверждать, что выражении x++ хуже чем x = x + 1, никак нельзя.
Прикладное программирование, конечно, не имеет дело с регистрами процессора или прямой работой с памятью, но оно от этого не перестало быть программированием, мы просто решаем другие задачи.
Я думаю сильно не ошибусь, но уже более 10 лет язык 1С не развивается. Наверное, нет ни одной типовой конфигурации 1С, где кол-во строк кода было бы меньше 100 тысяч. И к чему приводит эта «простота»? Загляните в модуля, посмотрите, что там происходит, многословные префиксы и суффиксы, ни к чему не обязывающие попытки описания интерфейсов через #Область, имена общих модулей и идентификаторов длиною под 100 символов (Пример: ЭлектронныйДокументооборотСКонтролирующимиОрганамиОбновлениеИнформационнойБазы), огромные процедуры с кучей параметров, проверки внутри проверок.
Развитие языка как раз для того и нужно, чтобы писать код было проще, но почему в 1С решили, что чтобы писать код проще – нужно остановить развитие языка, просто непонятно.
Армия разработчиков 1С почти всегда голосует против нововведений по очень простой причине:
1) не хочу никого обидеть, но разработчиков на 1С как таковых не так уж и много, подавляющее большинство, занимается доработками уже созданных решений
2) Люди устали, они просто только-только свыклись с управляемыми форми, тока поняли, как переделывать всё под асинхронность, тока-тока нащупали стабильные релизы, а тут какие-то умники заряжают про интерфейсы, классы и другое в 1С. Многим, когда 500 рыл в базе, звонки каждую минуту и другой головняк, подобные заявления кажутся «несерьёзными».
Никто не говорит про ООП, но ребята, ёлы-палы, давайте что-то делать с языком, хотя бы начать с namespace-ов каких-то, ну это же уже не дело.
zirix
в 1С нет ООП?
grumegargler
нет
bnytiki
Есть в 1С ООП.
Но только встроенные (написанные разработчиками платформы) объекты.
И их кастомизация разработчиками прикладных решений под конкретную задачу.
Еще есть внешние объекты — технология внешних компонент и COM-объекты.
Neikist
Наличие объектов не показатель. Пишется все в процедурном стиле по факту, да и без возможности свои объекты добавлять это уныло.
Neikist
О да, хотя бы синтаксического сахара добавили — и то хлеб бы был, я бы порадовался даже элементарным ++ и +=, об ООП видимо вообще бессмысленно даже мечтать. Хоть за управляемые формы спасибо, гораздо лучше того что раньше было.
Apatic
ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокументИмениНуралиеваБорисаГеоргиевича (с)
akabrr
В конфигурации, в поддержке которой я участвую, 899097 строк. Скажите какие инструменты я могу использовать чтобы не допустить деградации кода? Может быть у вас есть статический анализатор для 1с кода?
alexey-lustin
Прям не могу удержаться ;-)
Есть АПК — бесплатно http://v8.1c.ru/acc/
Есть Sonar для 1С — платно https://www.silverbulleters.org/sonarqube/
Вот как это выглядит для EDT Demo проекта https://sonar.silverbulleters.org/component_measures/?id=1c-edt-demo
akabrr
Спасибо
grumegargler
из бесплатного, есть еще вот это:
https://github.com/grumagargler
там три репозитория, с тестером, и самими тестами
akabrr
Спасибо
DonAlPAtino
Евангелисты — они такие евангелисты :-)
Петр — ознакомтесь на досуге с тем, как изменилось отношение евангелистов (да и всего) MS к «айтишникам» вообще и разработчикам в частности за последние 5 лет. Очень надеюсь, что это ваше (или того кто придет вам на смену) будущее.
По делу:
1. Нужен git в разработке. Убогое хранилище с кучей костылей в придачу (сорри тем кто их вынужден делать) при разработке даже небольших проектов — это издевательство.
2. Внедрите, наконец-то, разработанный умными людьми (вместо вас) xUnit в типовые и покройте типовые тестами (что сейчас уже умные люди делают вместо вас). Глядишь не придется отзывать релизы на следующий день, а у выходящих не будет висеть по 200 только призванных вами ошибок.
А потом поговорим про «что вредит, а что помогает».
Ну и начните наконец-то работать с нами (с комьюнити) вместо утверждений, что все что вы делаете — делается для нашего же блага. Понятно, что приятнее проводить время в ресторанах с ЛПР, но внедрять и пилить все это нам, а не им.
По вашим рассказам про работу с Платформой мы понимаем, что вы знаете КАК ВЕСТИ разработку. Ужас же со средствами разработки и состоянием типовых создает жуткий когнитивный диссонанс. Пора это вам в 1С признать и что-то с этим сделать.
alexey-lustin
По пункту 2 могу все таки нужно прокоментировать:
и
это 2 неблокирующих активности. ;-)
можно и не ждать когда покроются все типовые тестами (проверка поведения), можно самому параллельно вести работы по имплементации тестирования.
что кстати уже делается https://github.com/a-sitnikov/erp2_xtests
DonAlPAtino
А потом 1С выкатит новую версию решения и… опять все тесты переписывать. Ну и позиция «среднему одинэснику все это не нужно» она же не только у 1С. У «средних одинэсников» тоже. И пример должен подать 1С. А еще лучше методологию разработки под это поправить
artbear
Насколько я понимаю, в последние годы 1С все более серьезно подходит к управлению качеством.
Есть различные наборы тестов, в т.ч. и для типовых.
Жаль, что для типовых конфигураций тестов еще маловато, похоже, и они не выносятся в общий доступ для возможности их расширения всей сетью партнеров и пользователей.
grumegargler
Я очень ценю, что делает 1С, но позволю себе немного жесткой критики.
После продолжительного использования сценарного тестирования своей разработки, есть основание серьёзно задуматься на счет глубины проработки таких тестов в самой 1С. Другими словами — качество, а не количество этих тестов.
В объекте ТестируемоеПриложение, были ошибки (и частично еще остались), которые делали практически невозможным анализ ошибок клиента тестирования. И это выявляется сразу, при прогоне тестов, почему этого не заметили внутри 1С — я думаю потому что разработчик сценарного тестирования (конфигурации) не не был осведомлен о проблеме.
Давайте на чистоту, Петр пишет, что сценарное тестирование проводится, но при этом:
1. Когда я на партнерсах спросил разработчика конфигурации сценарное тестирование 3, используется ли эта разработка внутри 1С, я получил ответ — спросите у разработчиков.
2. Собственный опыт разработки тестов, не раз выявлял ошибки в платформе. Вопрос: почему внутри 1С, их сценарные тесты для типовых конфигураций проходят?
Я думаю, как минимум, на заметку 1С нужно взять то, какого качества эти тесты, что они проводят (я про типовые конфигурации). Например, даже в последней 8.3.9, если тестом заполнять табличную часть у которой последняя колонка автовыбор незаполненного — платформа начинает забивать табличную часть новыми строками, пока не завершит работу аварийно, нет возможности проверить ошибки, выдаваемые в модальных окнах, нет возможности нажимать на ссылки в декорациях, что, например, делает невозможным прогон тестов объектов, где это используется (например, в ERP2 справочник Виды номенклатуры, там невозможно нажать на Тип номенклатуры).
Вот и застряла мысль, вроде как тесты делаются, но насколько они качественные? Очень хочу ошибаться, но видимо все эти тесты сделаны на базе записи прокликиваний на коротких дистанциях.
artbear
Хороший комментарий, спасибо!
Всегда нужно помнить, что никакое тестирование не найдет 100% ошибок :(
Возможно, что часть сценариев просто не попадалась специалистам 1С, как бы странно это не звучало :)
Я 3 или 4 года назад спрашивал у разработчика конфигурации сценарное тестирование для УФ (тогда еще был прототип, помнится), используются ли тесты сценарного тестирования в типовых конфигурациях, получил аналогичный ответ :)
alexey-lustin
Я бы по другому сформулировал — вопрос не в абстрактном качестве тестов. А в code coverage на платформе и на типовой (типовых) конфигурации.
Вот например как выглядит доработанная УТ 11
То есть запускается менеджер тестирования и Vanessa Behavior со сценариями и дальше считается покрытие.
Но это как бы к Web клиенту не совсем относится...
grumegargler
Под качеством тестов понимаются очень конкретные вещи, но формат общения, в виде комментариев на тему, не предназначен для детальных выкладок. Приведенный вами скриншот, особой ясности также не добавляет. Своим сообщением, я хотел обратить внимание автора на эту тему с тестированием, потому что она упоминалась и в прошлых статьях, надеюсь, информация дошла по назначению.
На счет Ванессы, к сожалению принцип записи тестов там такой же, как в сценарном тестировании, поэтому я и мои коллеги довольно сдержанно относимся к этому продукту.
Если у вас есть возможность продемонстрировать, на примере ERP2 (демо), создание теста за часа три-четыре: Приход / Расход / Оплата, с анализом/проверкой проводок каждого документа, формированием/проверкой отчетов и затем переиспользование этого теста для организации другой цепи сценария, с другими товарами/услугами/валютой/контрагентами внутри, тогда это бы полностью закрыло все вопросы, говорю честно, не только для меня, но и для многочисленных 1С программистов. Из всего, что я видел по ванессе, выступления и другие ролики, содержат по большей части методику и технику развертывания.
У системы Тестер, с которой вы наверняка знакомы, очень мало инструментов по формированию отчетов по результатам тестирования, и других аналитических возможностей с дружественным интерфейсом, но с одной задачей он справляется хорошо — возможность быстро и коллективном режиме создавать тесты, не только как описал заказчик в тех задании, но и насколько качественно хочет это сделать сам разработчик или руководитель тестирования, покрывая всевозможные отклонения, нажатие кнопок, которые могут генерировать или задавать лишние вопросы и другое. На своей практике, именно этот момент мы считаем ключевым, и именно прогон таких тестов не раз показывал наличие ошибок в платформе.
alexey-lustin
если вы смотрели ролики "по Ванессе", то знаете что называется он правильно Vanessa Stack, а тот продукт который я указал выше называется Vanessa Behavior. Я не призывал вас его использовать — как говорит наш друг "больше инструментов, хороших и разных".
у нас другая методология чем у Вас — мы руководствуемся стандартами ИТ на эту деятельность. ГОСТ, ISO и т.д. тут подробней https://www.youtube.com/watch?v=r3belFHR2sw
Бизнес цели заказчика, персоны, критерии достижимости целей, пользовательские истории критерии успешности, сценарии использования — это заместо технического задания.
Вместо руководителя тестирования — у нас QA инженер и релиз-менеджер.
Ну а коллективная разработка и накопление требований у нас в DCVS (который GIT)
Поэтому тут спорить бессмысленно — указанный вами сценарий с оплатой мы делали за 40 минут для ERP 2 и Бухгалтерии 3.0, но на мой взгляд это совсем не показатель.
Я в своем сообщении указал, что термин "качество тестов", абстрактный и оценка "качества" зависит от "персонального мнения и харизмы", то есть субъективизма оценивающего.
Поэтому я и предлагаю перейти к формулировкам:
и что самое главное
и еще главней
потому как доработчики типовых работают на "почасовке", поэтому за качеством не следят от слова "совсем", а если и следят — то делают это почему долго и за деньги заказчика, то есть опять же "за часы". Хотя вроде как если почитать стандарты http://www.apkit.ru/committees/education/meetings/standarts.php то получается в стоимость часа должна включаться валидация решения на предмет соответствия исходным требованиям и на предмет качества выбранных решений и кода.
напомню есть средние значения по рынку
обратите внимание "качество не тестов, а именно команды"
на указанном выше скриншоте просто показано, что для 1С языка эту информацию можно подсчитать, померять и иметь в качестве "прозрачной" метрики — в итоге перестать спорить и устраивать священные войны "кто молодец, а кто нет"
P.S. "тестов нет" (с)
grumegargler
Спасибо за развернутый комментарий!
Но самое важное из всего сказанного я вижу здесь:
Вот именно в этом месте я думаю наши точки зрения и расходятся, потому что это как раз и показатель, и это очень важно. Видимо, у нас разная выборка проблем. Стандарты, методики, терминология – это всё полезная информация. А вот ситуация, что в часы не вкладывают тестирование, это факт, который практически никак не подвержен изменениям под влиянием вышеуказанных знаний. Расшифрую: вы сколько угодно долго можете убеждать программиста пилящего обработку для инфостарта (выражения взято из ваших роликов) что тестирование – это эффективно, и ему воздастся за это, но в тоже самое время, утверждаете, что время потраченное на разработку теста – не показатель. Я против той точки зрения, что 1с-программисты такие вот «тёмные» люди, стандартов не читавшие, а вот если прочтут, то спустится на них озарение.
И совершенно неважно, как вы называете руководителя тестирования, QA-инженером или еще как-то, но если инструментарий не позволяет делать работу эффективно, все остальные процессы становятся неинтересными.
У вас есть много роликов и по часу, и по полтора. Если есть возможность сделать ролик на 40 минут, где в реальном времени создаётся указанный мной выше библиотечный тест – вы сделаете большой шаг навстречу обычному программисту.
alexey-lustin
Вы опять не читаете что я пишу, и что пытаюсь до вас донести.
Я говорил о метриках — математических. А не об абстрактных сентенциях. В частности о покрытии кода проверками поведения.
Выше вы предлагали "Улучшать качество тестов", я предлагаю использовать другую формулировку "Увеличивать покрытие кода и метаданных проверками". Потому что качество тестов НЕ измерить, а покрытие очень даже можно. Цифры тем и полезны что прозрачны для понимания.
Ваш инструмент чудесен, вы молодец, коллеги из ТехноНиколь также молодцы.
grumegargler
Я не думаю, что у нас есть четкий предмет для спора. У вас системный подход, сверху и донизу, тут вообще никаких нет вопросов. И я думаю, что 1С тоже делает тоже всё по стандартам, по критериям, и цифровые показатели покрытия у них на высоте. Тут как раз всё четко и понятно, а не понять, о чем вы пишите – невозможно. Другой вопрос — это не всегда работает. При всем богатстве методик и численных оценок, остается неудобный вопрос – почему тестирование на коленке, выявляет проблемы быстрее и раньше, чем тестирование по науке. Не подумайте, что я анархист какой-то, я тоже вижу порядок через игру по правилам, просто этот вопрос призван акцентировать внимание не только на методике по всей цепи, а и задуматься над тем, как происходит процесс разработки тестов, как организована сама рутина.
P.S. Спасибо за мою положительную оценку. Компанию ТехноНиколь я не знаю.
Fragster
Люто поддерживаю. А то примеры типа «а тут мы викинем ассерт, так как на ноль делить нельзя» уже запепехали. Даешь реальные
кейсытесты!grumegargler
может быть вам будет интересно это решение: https://github.com/grumagargler/tester
bnytiki
Вы можете выгружать объекты конфигурации в множество мелких файлов.
Затем отправлять их на git.
Получать с git.
И загружать эти объекты в конфигурацию.
Это уже давно как реализовано.
Neikist
Когда про это последний раз слышал — у людей проблемы с идентификаторами предопределенных данных были, хотя помню смутно, могу и ошибаться конечно. А так да, в принципе подход рабочий, благо в одну строчку в командной строке выгрузка и загрузка происходит.
ZEEGIN
Скорее всего проблемы были из-за не понимания механизма предопределенных данных. Вот описание Статья о предопределенных на http://курсы-по-1с.рф/
Git и загрузка-выгрузка в файлы тут не при чем
Zack
Тому же python это почему то не вредит. И есть частные случаи, когда данные ограничения не совсем разумны. Если бы 1С работали с комьюнити, то смогли выявить тот инструментарий, который очень бы пригодился. А те «1Сники», кто только отчеты клепает продолжили бы их клепать на своем СКД, не пугаясь «всей мощи языка 1С».
Serginio1
Которую забросили. Только добавили возможность передачи двоичных данных. Но вот, то что просят многие это возврат из функций объектов ВК и передача в параметрах объектов ВК (и объектов 1С как это сделано в COM варианте) даже в планах нет. А там особо то ничего и не нужно делать. Просто подсчет ссылок только на стороне 1С и время жизни только на время вызова метода.
То есть для ДД это можно, а для других объектов 1С это нельзя (в том числе и объектов ВК).
Serginio1
Но вот для модальных и для асинхронных методов нужно вводить аналог C# async await.
О замыканиях не просит только ленивый. Опять же в управляемых формах серверный и клиентский код можно писать в одном модуле. И это прекрасно, но еще было бы эффективнее вызывать серверный код в виде замыкания, где бы захватывались переменные метода. Это бы значительно сократило время написания.
значение=ВызватьСерверныйМетод({ код который выполняется на сервере})
Ну и про свои чаяния про .Net Core в 1С промолчу
Zack
Есть разные варианты дикого подобия .Net Core в 1С, чем 1С очень гордится. ссылка
Serginio1
1С этим не гордится. Это мои статьи.
Как и эти
Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux II
1С, Linux, Excel, Word, OpenXML, ADO, Net Core
Которые есть и на этой площадке Мои публикации
К моему огромному сожалению интеграция с .Net Core 1C не нужно. А вот например Samsung вполне использует Tizen C# API reference
bolonov
>разработчикам работающим в среде 1с об этом приходится только мечтать.
На мой взгляд:
— % таких разработчиков невелик
— львиная доля 1С-разработчиков решает прикладные задачи клиентов с минимальной технической морокой. Собственно за это и спасибо 1С
DonAlPAtino
И любимый девиз таких разработчиков «фигак-фигак» и в продакшен. То, что люди привыкли сидеть в яме не значит, что там надо сидеть постоянно. Никаких проблем у 1С вывести разработку на современный уровень нет. Было бы желание, а разработчики подтянуться. Зато сколько проблем уйдет.
«львиная доля 1С-разработчиков решает прикладные задачи клиентов с минимальной технической морокой.» имеется в виду очевидно минимальные задачки типа бухгалтеру отчетик налабать видимо… Это да… Никаких проблем и git с тестами не нужен. Но там кто-то (не 1С ли) решил с SAP конкурировать. Хотя может только по размерам бюджетов и сопутствующим им вещам :-)
Apatic
5 лет проработал 1С-ником, да и сейчас часто с ней сталкиваюсь, поэтому выскажу свое ИМХО.
Хотя, по-хорошему, это тема для отдельной большой статьи.
Как мне кажется, вопрос развития (а значит усложнения) средств разработки — это еще и вопрос экономики. Сейчас порог вхождения в мир «программирования на 1С» довольно низок. Есть куча стажеров/студентов/фрилансеров, которые поддерживают чьи-то базы на минимальном техническом уровне (обработку написать, реквизит добавить и т.д.). Это не хорошо и не плохо, это просто как есть, такова потребность рынка и 1С с партнерами ее удовлетворяет.
Усложнение средств разработки, усложнение языка и т.д. может привести к повышению порога вхождения, что в конечном итоге приведет к тому, что в профессии будут оставаться только люди более высокого уровня, а время на подготовку таких специалистов вырастет. В конечном итоге это приведет к удорожанию стоимости (а рынок 1С-ников и так подогрет не слабо) таких специалистов и сокращению их численности.
А этого 1С, подозреваю, допускать не хотела бы. Не говоря уж о бизнесе.
Понимаю, что это лишь один из возможных сценариев, но он кажется мне правдоподобным.
С другой стороны, я помню баттхерт от введения управляемых форм и как долго люди привыкали к ним. Думаю, введение существенных изменений в средства разработки 1С будет не болезненнее, чем переход на УФ,
medvedevia
Ну javascript развивается, куча фреймворков появилось, паттерны начинают юзать (MVVM например), веб-разработки при этом меньше не стало. Мне кажется ошибочным мнением, что развитие языка и платформы оттолкнет новых разработчиков, может даже наоборот привлечет как раз таки профи. На начальном этапе может и надо было сделать 1С массовым ПО, поэтому тут любые средства хороши, чтобы привлечь побольше разработчиков, но надо двигаться дальше. Поначалу ведь ты был сам себе менеджер, консультант и разработчик, а теперь на проекте это разные люди, и даже есть новые роли — например эксперт по технологическим вопросам. Всё вокруг изменилось, а язык остался прежним, с этим уже пора что-то делать…
bnytiki
Язык таких вещей не меняют по 3 раза в год.
До сих пор в эксплуатации огромное количество автоматизированных систем, созданных на предыдущей версии 1С — на v7, которая появилась еще в конце прошлого века.
Бизнесу (клиентам 1С) нужно решение проблем, а не модные фичи ради фич.
Проблема решается? Ну и зачем тогда тратить огромные деньги все переписывая.
Фичи языков не нужны в 1С.
Потому что то, что в других языках программисты решают самостоятельным написание кучи кода — в 1С решает платформа. И программисту остается просто выбрать нужную фичу (объект) для решения проблемы и чуть-чуть ее кастомизировать.
А не писать с нуля как это принято в других языках.
fishca
В 1С 7.7 ой как не хватало множественных табличных частей и до сих пор это тормозит достаточно сильно, хотя это можно реализовать на других объектах. И это не модная фича ради фичи, которая появилась в 8.х
Neikist
Во первых пишутся новые системы, в т.ч. с нуля, во вторых не обязательно ломать обратную совместимость.
akabrr
Множественный отбор в списках в 7.7 на уровне платформы реализован не был, однако с помощью 1С++, разработанной комьюнити, это было реализовано. И реализовано красиво, с помощью классов, вставить табличное поле было не сложнее чем в 8ке.
Zack
«львиная доля 1С-разработчиков решает прикладные задачи клиентов с минимальной технической морокой.»
Все почти так, но очень часто возникают проблемы и иного рода, если бы был инструмент, то можно было бы их решить без «костылей» в виде внешних компонент и каких-то скриптов на питоне.
bnytiki
Не приходится.
У 1С узкоспециализированный язык (и узкоспециализированный runtime и система объектов/классов), предназначенный для решения вполне конкретных задач.
Замечу — для весьма быстрого решения.
Никакие там «современные мощные языки» и рядом не лежали по скорости разработке в той сфере, для которой 1С и предназначена.
А для нестандартных вещей — есть COM-объекты, технологии внешних компонент и web-сервисов и пр. Да в конце концов есть HTTP. Вы можете написать сторонний софт и общаться с ним по REST API.
bnytiki
Этого не нужно, учитесь интегрировать.
https://habrahabr.ru/company/1c/blog/308420/
Миллионами методов 1С сие умеет.
akabrr
Спасибо за ценное указание. Я каждый день чему нибудь учусь. Но похоже вы не поняли про что я писал.
artbear
+1 За описание схемы тестирования и за использование различных инструментов тестирования
alkresin
Это, конечно, хорошо, но для вашей флагманской конфигурации УПП 1.3, которую используют производственные предприятия, тонкий и веб-клиенты практически почти бесполезны, поскольку они не поддерживают многие необходимые функции.
o4karek
На данный момент флагманская — ERP 2.х, разве нет?
alkresin
Здесь, например: v8.1c.ru/enterprise/ УПП названа флагманской. Местные 1с конторы предлагают именно это.
o4karek
Но по факту — ERP 2.2 :)
По приведенной ссылке — баг, исправим.
alkresin
Тогда исправьте и информацию о том, что 1с сервер поддерживает, например, PosgreSQL. Реальные внедренцы отказываются с ней работать, ссылаясь на кучу проблем и уверяя, что не могут в этом случае обеспечить нормальное функционирование системы, вынуждая клиентов тратить большие деньги на приобретение windows server и mssql с клиентскими лицензиями.
Но проблема, вообще-то, не в информации на сайте, а в том, что внедренцы предлагают именно УПП — возможно потому, что ERP они не знают в достаточной степени, ну и потому что ERP заметно дороже.
Drac013
В случае с PostgreeSQL опять-таки проблема компетенций. Есть немало довольно серьезных проектов, которые работают на данной СУБД.
alkresin
Так где же взять компетентных внедренцев? Понимаю, вопрос риторический…
Drac013
Боюсь, это проблема не только области 1С :)
sergeypr
В данном случае не внедренцы нужны, а грамотные администраторы — у меня 5 клиентов (конфиги: Бух, УТ, Комплексная) работают на PostgreSQL и, если год назад все было, согласен очень печально, то сейчас никаких вопросов — все работает и хорошо!
Более того, при правильной настройке PostgreSQL под железо сервера, на 2 предприятиях тест Гилева выполняется быстрее, чем в MS SQL (на том же железе!)
o4karek
Давайте не смешивать кислое и фиолетовое.
По приведенной ссылке имеется фактологическая ошибка.
Ваше утверждение о том, что 1С: Предприятие не поддерживает работу с PostgreSQL — это только ваше утверждение. Почему мифические внедренцы предлагают УПП и MS SQL — это отдельный вопрос. Радикально простой ответ на этот вопрос звучит так: эти внедренцы ничего другого не знают. Подозреваю, что мир не монохромен, и правильный ответ не так радикален.
Предлагается все-таки не разбрасываться абстрактными утверждениями (их много и у вас и у меня), а быть несколько более конструктивными. Если есть проблемы с PostgreSQL — пишите в поддержку: эти ошибки будут анализироваться и исправляться.
alkresin
У меня нет проблем с PosgreSQL: просто не было возможности с ними столкнуться, по настойчивому требованию внедренцев (отнюдь не мифических, просто не хочу ославить их на всю страну, как бы к ним ни относился) директору пришлось пойти на покупку windows и mssql.
Представители 1С иногда заявляют публично, что Линукс не интересует клиентов, процент внедрений на нем очень мал. Да потому и мал, что внедренцы отказываются ставить на него 1С. По некомпетентности ли, или из-за реальных проблем — вам лучше судить.
o4karek
Если у вас нет проблем — тогда зачем вы тиражируете чьи-то заявления, причин которых не понимаете? В ситуации, когда внедренец честно говорит: у меня нет компетенций по Линуск/Мак/Звездам смерти, я имею компетенции по Виндоуз/Юникс/Телепортаторам, по этому и предлагаю вам то, что предлагаю, никакого криминала сходу не видно. Есть честное предупреждение о своих возможностях. Печально, если отсутствие своих компетенций прикрывается обвинениями продукта в невозможности сделать что-то.
И прямо есть ссылки на такие заявления представителей 1С?
Да вроде не отказываются. Судя по партнерскому форуму — Линукс используется достаточно часто.
beho1der
Насколько знаю, нету особых проблем с PosgreSQL, производительность не сколько не уступает mssql. Настройка PosgreSQL не слишком сложное занятие.
alkresin
Проблема не в PostgreSQL, нисколько не сомневаюсь что она не уступает mssql. Проблема в 1С — взять хотя бы тему с блокировками на уровне записи. И в тех многочисленных «партнерах» 1С, которые внедряют этот продукт на местах.
kxl
Более того, даже всячески отговаривают от ERP 2.x, якобы по сыроватости последней…
PeterG
Видимо у них нет экспертизы по внедрению ERP.
УПП сейчас нами особо не развивается, его сменил ERP.
Ну а по части «сыроватости» — пользователями 1С:ERP стали более 1300 компаний, продукт вполне зрелый.
kxl
Ну, я не могу знать их мотивов… По большей части типовые конфы — шаблон с различным уровнем наполнения.
А так уже лет 8 занимаюсь допиливанием УПП для нужд различных производств (от упаковки кофе до совхозов, молокозаводов и т.д.) и не скажу, что она тоже не была сыроватой… Так и помрет…
skive
1) Насколько реально мигрировать с УПП 1.3 на ERP 2.0 с переносом всех данных?
2) Есть ли смысл такой миграции? Какие преимущества?
3) Когда планируете завершить жизненный цикл и поддержку УПП 1.3?
Заранее спасибо за ответы.
PeterG
Обычно мигрируют, перенося не всю информацию, а остатки и нормативно-справочную информацию. В составе 1С:ERP есть инструменты для переноса. Вот здесь есть информация по этому поводу, см. доклады с мероприятия «Телеконференция „Новые возможности для бизнеса — переход с 1С: УПП на 1С:ERP“»
УПП больше не развивается, делаются только изменения для поддержки текущего законодательства и исправление найденных ошибок.
Официального решения пока нет, но предупредим за 3 года о снятии с поддержки.
PeterG
Сайт поправим, спасибо!
aiydas
Использовать Google Closure Library и завязаться на их «строгий» код стайл, было очень разумно, для такого крупного проекта. Наверняка это сэкономило кучу денег и времени на реализацию и поддержку веб версии клиента.
marmyshev
А можно по подробней (может не понял из статьи?), о текущих отличиях функциональности тонкого клиента и веб-клиента?
PeterG
Отличий практически нет. Имеется в виду — вся новая функциональность, которая реализуется в тонком клиенте, реализуется и в веб-клиенте. И наоборот.
bogdan_sukonnov
Самое логичное использование веб-клиента 1С — создание «личных кабинетов» внешних пользователей. Тут куча очевидных плюсов для всех сторон процесса. Поэтому я часто выбираю именно эту технологию для решения подобных задач и просто в восторге от простоты реализации. Но есть серьезная проблема — чаще всего требуется прикреплять файлы в программу, а порой это основная задача веб-приложения. И, к сожалению, сделать удобный интерфейс пользователя не прибегая к костылям пока не удается. Нет drag'n'drop, для загрузки файлов открываются уродливые дополнительные окна, увеличивая число кликов. Поэтому и мне, и коллегам приходится использовать поле HTML документа и там запускать самописное веб-приложение с реализацией нужных функций. Каждый пишет свой клиентский и серверный велосипед и костыль для связи этого зоопарка с 1С. Ситуация ужасная. Уверен, если эта проблема в платформе будет решена, использование веб-клиента 1С для личных кабинетов и систем документооборота существенно возрастет.
reallord
Сейчас уже есть «почти» нормальный REST, очень многие вещи можно напрямую читать/писать через ajax.
И тогда полностью отвязываемся от дизайна 1С.
DonAlPAtino
Оно конечно да. Но для web-клиента может писать «простой одинэсник», а для REST придется позвать хорошего разработчика frontend. А как выше утверждают господа из 1С — «мы для вашего блага урезаем функционал» :-)
serh1o
Скажите, пожалуйста, как реализована работа с оборудованием: банковские терминалы, ФР, весы, — через расширения и технологии внешних компонент?
PeterG
Да
BrandStorm
А на каких платформах? Моя тщетная попытка с 1cfresh и Linux клиентом заставить работать USB ФР не увенчалась успехом.
PeterG
Можно подробнее?
Решение во 1cfresh?
В нашем 1cfresh.com или в вашем?
Веб-клиент на Linux?
Из него цепляете внешнюю компоненту?
ComodoHacker
В сторону TypeScript не смотрите?
И немного оффтопик: какие планы насчет ПолеHTMLДокумента под Linuх? А под Windows — IE на все времена?
Klaster
Тут человек интересуется, цитирую:
Источник: Кто на Хабре не забанен, спросите у 1С – когда они выкинут IE из платформы?ripreal
Не умаляю достоинств разработчиков веб клиента, но перенести по сути десктопный оконный интерфейс в веб-браузер — это жесть! Ставлю дырявый пятицентовик на то, что за пределами локальной сети, такой если можно выразится «сайт» ни один собственник не захочет выставить на обзор публики.
Почему нельзя было пойти по стопам SAP DYNPRO и реализовать внутри конфигуратора возможность наклепать собственных форм на java/javacript? Или почему нельзя пойти по стопам собственных разработчиков мобильной платформы, которые сначала тоже решили сделать десктопную копию интерфейса, а потом поняли, что облажались и реализовали отдельный интерфейс по мобильным стандартам?
Fragster
в B2B сегменте достаточно часто используется. Тем более, что реализовать в веб клиенте 1с личный кабинет партнера или агента со всеми отчетами и прочим — дело часов.
Drac013
Во-первых, эту проблему постарались решить введя новый интерфейс Такси. Получилось довольно неплохо.
Во-вторых, некоторые десктопные решения просто-таки на ура воспринялись незнакомой с 1С публикой. В частности, вкладочный интерфейс страницы.
В-третьих, это все-таки не сайт. Чтобы сделать публичный сайт, придется выдать немереную сумму денег за одни только лицензии. А вот в качестве личного кабинета партнера — очень даже подходит.
jetexe
Кока-колла, в частности ДоброеПартнерство.РФ
bnytiki
На картинках изображен вовсе не обычный десктопный интерфейс.
Перед тем как делать «универсальный интерфейс» для браузера и для полноценного клиента — 1С реализовала специальный webоподобный интерфейс на десктопе.
Старый, классический десктопный — тоже остался доступен (не для веба, разумеется).
bnytiki
Путь SAP DYNPRO — тупиковый.
Они добровольно отказываются от своей силы, от специализации на вполне конкретных прикладных вещах, где программисты могли бы много времени экономить.
В 1С все сделано правильно. Несколько секунд — и у вас есть и структура БД, и формы для записи-чтения работают автоматически.
Neikist
А потом чтобы по требованию консультантов реализовать поведение этих форм и объектов не предусмотренное платформой все равно приходится повторять функционал платформы, но со своими изменениями в логике работы + это глючит естественно и тормозит, ибо реализация не нативная. приходится такие костыли на десятки тысяч строк городить что ну его…
ZEEGIN
Очень интересно посмотреть на сценарии поведения на формах, которые могут потребоваться консультантам-аналитикам и которые невозможно реализовать в управляемых формах.
Neikist
Не «невозможно реализовать» а «приходится повторять функционал платформы, но со своими изменениями в логике работы», например у нас есть справочник со своими иерархиями которые неограниченно могут создавать пользователи, есть возможность изменять положение в иерархии документами (с историей предыдущих положений естественно), строить иерархии по произвольному реквизиту и т.п. А теперь представьте мучения со всем этим добром когда пользователи для данного справочника требуют поведение аналогичное другим справочникам, в т.ч. с отборами по иерархии, отчетов и т.п. вещей. Ну или вообще банальный пример когда не нравится стандартный платформенный порядок кнопок командной панели, приходится ради перемещения одной кнопки убирать автозаполнение и закидывать их вручную.
Fragster
Храните историю иерархии в периодическом РС, подчиненном регистратору (наряду с текущей иерархией, которая стандартная платформенная). Далее во всех отчетах на СКД эта произвольная иерархия подключается за 3 минуты. Несколько лет назад делалось подобное такое для бюджетирования, правда без «изменения иерархии документами», просто с хранением того, кто и когда иерархию поменял.
Neikist
Так и делаем, но помимо отчетов это нужно еще в формах подбора, плюс в некоторых сценариях работы необходимо программно работать с этой иерархией. При этом в текущем проекте планируется что в этом справочнике не один миллион элементов будет.
Fragster
не знаю за миллионы, но РС с nested sets показал себя неплохо на сотнях тысяч наименований.
ZEEGIN
Если такое называть костылями… Платформа дает переопределить? В чем костыль? В том, что есть желание, чтобы платформа догадалась о том, что вы хотите переопределить и сделала это за вас?
А вообще, хорошей практикой считается именно отключение автозаполнения для кнопочек, а произвольная иерархия — это проблема выбранного вами архитектурного решения, тут стоит подумать о другой реализации.
Neikist
Произвольная иерархия (точнее множество создаваемых пользователями иерархий) это требование наших консультантов. А костыль в том что полностью аналогичный внешний вид как у платформы без диких извращений сделать не удается.
А тут все просто, требуется в этих формах давать выбор иерархии, возможность перемещения, удаления и прочих стандартных команд, но поведение так просто не переопределить… В общем это вылилось в несколько тысяч строк кода формы, и еще пару десятков тысяч строк в общих модулях (ну там еще специфичный функционал правда дополнительно реализован) Это в дополнение к тому что чатсть приходится дублировать в другие формы где требуется работа с этими иерархиями.
Neikist
Насчет нативной неверно выразился, имел в виду что когда это реализовано разработчиками платформы, гарантированно оттестировано — оно гораздо лучше чем реализованное вчерашними студентами на коленке.
Neikist
Хотя изрядную долю говнокода возникшего вследствие спешки и написания конфигурации на управляемых формах методом копипаста кода из конфигурации на обычных формах отрицать к сожалению не могу.
Но тем не менее каждый при своем мнении останется, редко когда кто то кого то переубеждает в спорах в интернете. Вы, как я понимаю, так и продолжите стоять на том что язык следует максимально упрощать, я по прежнему буду считать что возможность создавать объекты например как это реализовано в js (ни разу не писал на нем, но на википедии примеры посмотрел), возможность использовать функции первого класса, замыкания (для обработки оповещения и перехода на сервер например) и тому подобные вещи только добавят удобства и больше возможностей по написанию хорошо структурированного и лаконичного кода.
ZEEGIN
Кстати говоря, управляемая форма — не нативная, это обычные формы были такими.
Управляемая форма представляет из себя xml файлик с описанием. И он либо составляется платформой автоматически, либо по тому конструктору, в котором все переопределено вами. Поведение исполнения программы не зависит от описания того как расположены кнопочки на форме. Потому не понимаю почему это может «тормозить» да еще и «естественно». И, заметьте, ни одной строчки кода)
hamnsk
Друзья, лучше оптимизируйте свою консоль кластера, крайне убогое приложение, как таковых функций по менеджменту лицензий в нем нет, хотя такие вещи есть у любого софта (кроме вашего). Элементарно посчитать с какого пакета сколько лицензий отдалось, это нужно делать вручную. Да и вообще оно не очень информативно.
Уделите еще внимание оптимизации работы с БД, создание кучи временных таблиц, на каждый чих обращение к БД. Научитесь кешировать запросы, и использовать хранимые процедуры и все возможности современных серверов БД. Реализовать это не так трудно было бы желание.
Вообще если брать конфигурацию под вашу систему и под веб приложение выполняющее те же задачи, то можно сильно удивиться, что приложение написанное под веб работает быстрей и на меньших ресурсах. Поэтому иногда проще либо написать самому либо взять готовую ERP систему или CRM систему написанную на PHP, PYTHON.
Единственный неоспоримый плюс вашей системы это система отчетов. Это так на вскидку.
А еще ваша система не умеет HTTP2.0, SFTP, Network Share и тд…
У меня складывается мнение, что вы живете в каменном веке, и реализовываете свой беклог по задачам 15 летней давности.
pag93783
К сожалению, про отношение к разработке платформы под 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-клиенте.
svcoder
В статье есть неточность — нет никакого байт-кода в 1С. Байт-код должен быть на языке низкого уровня, а в 1С это просто закодированные инструкции встроенного языка.
Также интересно, почему отказались от поддержки на тонком клиенте таблицы значений и дерева значений? Выход конечно есть — массив со структурами, но все-таки почему?
Sjam
Несмотря на все преимущества web-клиента он все еще не работает с подписями-шифрованием, периодические проблемы с файловыми операциями.
alexkmbk
Работает с подписями веб-клиент, за счет внешних компонент, которые доступны в браузерах.
Sjam
Вот только внешние компоненты работают не в линуксах.
fishca
Если написать по технологии Native API, то будет работать и там.
Sjam
Т.е. 1С заявляет о работе компонент, по факту «Если написать по технологии Native API, то будет работать и там», так? Где-то обман закрался. Не так ли?
fishca
Старые компоненты писанные на технологии СОМ в линухах работать естественно не будут. Новый писанные с помощью Native API будут. Не вижу обмана, это прописано в документации к платформе.
Sjam
Если вы не понимаете о чем я пишу, давайте закончим. Или хотя бы разберитесь с тем, что есть и что работает в Линуксах от 1С, а что нет.
fishca
Не знаю о каких внешних компонентах вы ведете речь, а имею ввиду вот это: Глава 34. Внешние компоненты
Serginio1
>>С самого начала мы отвергли идею какой-либо автоматической (хотя бы частичной) конверсии C++
Я понимаю, что это был 2006 год. Но сейчас вроде
Asm.js стал ещё быстрее