Продвинутый курс. МГ сессия от 24.11.10
Свежие видео-ответы на вопросы участников продвинутого курса.
Сегодня мы рассмотрели следующие вопросы.
1. Групповая разработка конфигураций.
После просмотра главы о групповой разработке впечатление о механизме хранилище конфигурации сложилось как о каком-то довольно таки «тяжелом» инструменте. Данное первое впечатление обманчиво? Пока заинтересовало лишь использование хранилища конфигурации одним разработчиком, для хранения версий дорабатываемой конфигурации. При использовании же данного механизма именно для групповой разработки, мне кажется, он оправдает себя только именно при четко модульной разработке\доработке какой-либо конфигурации. Когда есть несколько человек, у которых есть свой «кусок», они захватываютего и в волю с ним резвятся, перекидывая потом все это в хранилище для актуализации данных у других разработчиков. Захват же мелких блоков, таких как формы\макеты, иногда, конечно же, может быть удобен и оправдан, но опять же, по моему мнению, в большинстве случаев это дополнительные действия, которые могут «напрягать» и даже замедлять в целом процесс разработки\доработки конфигурации. Используете ли вы сами в своей работе механизм групповой разработки? Насколько прав\не прав я в своих мыслях?
2. Разработка отчетов в консоли.
Разрабатываю запросы в типовой обработке консоли для СКД фирмы 1С – Консоль отчетов.erf Файл разработанных отчетов сохраняется с расширением .dcf Какие есть варианты, чтобы наиболее просто и быстро преобразовать этот разработанный файл в обычный внешний отчет, не требующий запуска Консоли отчетов?
3. Использование Linux.
Мы хотим для нескольких расположенных в разных местах города (не связанных в локальную сеть) точек обеспечить доступ к единой базе, построив следующую архитектуру сервер приложений Linux веб-сервер Apache субд Postgree клиент Linux: обеспечить доступ через интернет через веб-интерфейс или тонкого клиента На сайте 1с написано, что особенности рабочих серверов под управлением Linux не могут взаимодействовать с СУБД Microsoft SQL Server, не поддерживается работа с СОМ-объектами, аутентификация на сервере выполняется по протоколу Kerberos, не доступна работа с Интернет-соединением. Значит ли последний пункт , что обеспечить доступ через интернет при такой инфраструктуре будет нельзя и работать через интернет можно только на Windows сервере? И что не будет работать стандартный обмен между , скажем, бух и торг, настроенные через прямое подключение к базе?
4. Обмен данными. Схема “Место создания и центр”.
В 7.7 был механизм “Место миграции” элементов. Я мог для общих справочников выставить «Все ИБ», для конкретных – «Место создания и центр». Как подобное сделать в 8-ке? Предполагаю, что Для общих справочников выставить авторегистрацию Для справочников у которых в 7.7 было место создания и центр убрать авторегистрацию изменений и заполнять программно получателя Центральную базу при записи на перифирии. И в каждом таком справочнике заводить реквизит для обозначения места создания
5. Создание нового узла.
Как я понял из уроков по РИБ, оптимальным будет создание ПБ отдельно из файла конфигурации, а затем подключение ее в план обмена установкой главного узла. В итоге получу чистую базу. А вот как дальше заполнить ее только общими справочниками? Метод ЗарегистрироватьИзменения() для нового узла записывает как я понял все объекты с признаком авторегистрации – а это будут и все документы всех баз (там тоже стоит признак авторегистрации). Как их исключить? Вариант выполнить этот метод, а затем при отправке сообщения фильтровать в событии ПриОтправкеДанныхПодчиненному мне не кажется удобным из соображений производительности. Ведь при регистрации будут отмечены все документы ЦБ – а это большой объем данных.
6. Оптимизация отображения списков.
Можно ли в конфигурации 8.2 на толстом клиенте сконвертированным из 8.1 выборочно открыть форму списка документов, отрисовываемую только на сервере, как в управляемом приложении, или надо целиком все менюшки и интерфейсы переделывать? Стоит задача упп 1.2 старое сконвертированное ускорить по отображению списков с минимальными усилиями
Немного прокомментирую человека, который насколько я понял, не работал до этого момента с хранилищем и задает вопросы, наподобие:
Захват же мелких блоков, таких как формы\макеты, иногда, конечно же, может быть удобен и оправдан, но опять же, по моему мнению, в большинстве случаев это дополнительные действия, которые могут «напрягать» и даже замедлять в целом процесс разработки\доработки конфигурации
Ответ очень простой. А как Вы, в количестве минимум 2-ух человек, без хранилища, сможете параллельно разрабатывать одну конфигурацию?
Я с хранилищем работаю не первый год (еще с 8-ой версии) и могу сказать, что это мега-удобно даже для одного человека, не говоря уже о коллективной разработке. Про падении скорости работы с хранилищем при значительном объеме метаданных конфигурации могу заметить только, что у нас это лечилось обрезанием хранилища раз в 3 месяца. Эмпирически было вычислено, что хранить всю историю изменений больше этого срока особо резона не имело.
Igor, полностью поддерживаю Вас! :)
Мой опыт работы в группе разработки из 6 человек говорит, что использование хранилища чрезвычайно удобно!
Еще ни здесь, ни в видеоуроках не было отмечено 2 аспекта улучшений при использовании хранилища:
1. Можно не комментировать код на предмет “Дата такая-то, я такой-то поменял этот кусок кода”. У каждого есть свой личный доступ к хранилищу и оно само ведет всю историю изменений. А при написании комментариев к коду сосредоточиться на действительно полезном описании кода. А с появлением в 8.2 комментария к каждому обновлению можно еще и кратко описывать общий смысл публикуемых в хранилище изменений.
2. Нельзя случайно что-то изменить в конфигурации. Никогда не бывало при разработке, что открыл форму, где-то мышью случайно что-то потянул – и уже форма изменилась? А если один такой небрежный мах мышкой произойдет в дереве конфигурации, со случайным копированием того или иного объекта?
Только вот в видеоуроках не были рассмотрены (кроме обычного файлового доступа по сети) еще 2 способа работы с хранилищем: через http и через tcp. Может быть, какой-то из этих способов окажется производительнее?
Про падении скорости работы с хранилищем при значительном объеме метаданных конфигурации могу заметить только, что у нас это лечилось обрезанием хранилища раз в 3 месяца. Эмпирически было вычислено, что хранить всю историю изменений больше этого срока особо резона не имело.
А можно сохранить и старые изменения, путем предварительной (перед обрезанием) резервной копии каталога с хранилищем. Ведь с хранилищем можно работать и отдельно от текущей конфигурации – просто открыв ее в Конфигураторе.
Спасибо очень здорово!
Отлично :) спасибо
Спасибо за совсем простой способ преобразования отчетов из консоли в обычные!
Уже использую в работе.
:)
+100, очень удобно через xml