Снегопат

[quote="orefkov"]SerMaxim, как мне кажется, пытается поставить телегу впереди паравоза, пытаясь под инструмент выдумать технологию работы.
А имхо, надо четко определить методологию работы, что куда и как идет, и лишь потом, имея полное понимание того, что же нужно, подбирать инструмент.
При необходимости дотачивая его там, где необходимо.
Тогда уже будут конкретные вопросы к возможностям Снегопата, на которые я смогу ответить - есть это или могу сделать или невозможно.[/quote]

Может быть оно так. Хочется поставить на поток процесс документирования внесения изменений в базу. В свое время имел обширный опыт работы с JavaDocs в среде Eclipse. Хочется чего-то аналогичного...

orefkov писал(а):SerMaxim, как мне кажется, пытается поставить телегу впереди паравоза, пытаясь под инструмент выдумать технологию работы.
А имхо, надо четко определить методологию работы, что куда и как идет, и лишь потом, имея полное понимание того, что же нужно, подбирать инструмент.
При необходимости дотачивая его там, где необходимо.

+1

SerMaxim, как мне кажется, пытается поставить телегу впереди паравоза, пытаясь под инструмент выдумать технологию работы.
А имхо, надо четко определить методологию работы, что куда и как идет, и лишь потом, имея полное понимание того, что же нужно, подбирать инструмент.
При необходимости дотачивая его там, где необходимо.
Тогда уже будут конкретные вопросы к возможностям Снегопата, на которые я смогу ответить - есть это или могу сделать или невозможно.

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

Ну почему же нет:
1. Сравнение конфигурации с конфигурацией ИБ.
2. Сравнение конфигурации с конфигурацией хранилища.

Вопрос неоднозначный, на какой временной шкале хотим видеть лог действий программиста непонятен.
1. Допустим тот же Colorer цветом показывает сохраненные изменения и еще не сохраненные. Если рассматривать, что именно сейчас я подправил - видно без проблем.
2. Как выше уже писал, написал 10-50 строк текста, сохранил конфигурацию - в сравнении с конфигурацией БД можно увидеть изменения (в принципе пройтись скриптом по метаданным базы и сравнить с метаданными конфигурации не составляет труда - даже скрипт есть, который отслеживает начало изменений любых метаданных и можно для ускорения сравнивать не все объекты конфигурации, а только те, что в логе изменений).
3. В конце дня, после тестирования, проверки работы делаем перед "поместить в хранилище" сравнение с конфигурацией хранилища и видим все наши изменения за день, можно хоть отчетом делать.

ИМХО: логирование изменяемых объектов программистом необходимо в 1 случаи:
Кодим - сохраняем конфу - сохраняем в БД - кодим - сохраняем конфу - кодим - перед сохранением тут хочется посмотреть, а что же изменилось после предыдущего сохранения в конфигурацию. Из снегопата можно показать только, что этот объект возможно был изменен, т.е. точно ли он изменен можно только сравнив с конфигурацией БД.

Ну и полностью все впихнуть в конфигуратор все равно не получиться, например сложные отчеты на СКД лучше всего пишутся в консоле отчетов в режиме предприятия.

[quote="sosnae"][url]http://ssh.sosna.zp.ua/owncloud/public.php?service=shorty_relay&id=Rcr8aYV9J3[/url] но пока это только концепт, в сильно промышленных масштабах не использовал.
Сейчас на примере снегопатовских скриптов тестирую redmine + code review и синхронизацию git с fossil.
[quote]- Иногда программистам хочется именно анализировать взаимный код когда идет крупный проект, чтобы понимать кто что куда написал, зачем и для кого[/quote] пока мне приглянулась такая система просмотра истории, посмотреть можно по адресу [url=http://ssh.sosna.zp.ua/redmine/projects/scripts/repository/diff/SpellChecker.js?rev=5ffdb91222b0540c9444356cf4f62454de33449e&review_id=2]пример code-review[/url], для примера создал пользователя test и пароль test1 .
Неспешно пишу скрипты по получению из cf и внешних обработок дерева файлов и в виде исходников коммиту в git. Т.е. хочу попробовать такую связку (что бы автоматом, один раз настроил и забыл) основная ветка в хранилище от 1С равняется tunk ветки в git , локальные коммиты "бинарников" от 1С (cf, epf, erf) в ветке "dev". В git хочу добавить пару хуков по распаковке cf, epf, erf в исходники и коммит в репозитарий с иходниками с аналогичным комментарием, данный репо уже подключен к redmine и там [url=http://ssh.sosna.zp.ua/redmine/projects/scripts/repository/statistics]красиво отображаем статитстику[/url][url=http://ssh.sosna.zp.ua/redmine/projects/scripts/repository/revisions/5ffdb91222b0540c9444356cf4f62454de33449e/annotate/extSearch.js]и кто и чего и когда подправил в коде[/url]

[quote]- Коммитом считать помещение в хранилище - ужас как долго[/quote] согласен, поэтому я использую внешние системы версионного контроля ,в течении дня, для микрокоммит.

Вообще самое трудное это комментарий к коммиту, даже иногда при помещении в хранилище не знаешь, что написать.[/quote]

Именно поэтому и хотел чтобы по максимуму все фиксировалось из конфигуратора. Пока как я понимаю штатно созданных скриптов (чтобы их просмотреть в демо-версии), показывающих что и где программист сделал нету. Верно понимаю?

http://ssh.sosna.zp.ua/owncloud/public.php?service=shorty_relay&id=Rcr8aYV9J3 но пока это только концепт, в сильно промышленных масштабах не использовал.
Сейчас на примере снегопатовских скриптов тестирую redmine + code review и синхронизацию git с fossil.

- Иногда программистам хочется именно анализировать взаимный код когда идет крупный проект, чтобы понимать кто что куда написал, зачем и для кого

пока мне приглянулась такая система просмотра истории, посмотреть можно по адресу пример code-review, для примера создал пользователя test и пароль test1 .
Неспешно пишу скрипты по получению из cf и внешних обработок дерева файлов и в виде исходников коммиту в git. Т.е. хочу попробовать такую связку (что бы автоматом, один раз настроил и забыл) основная ветка в хранилище от 1С равняется tunk ветки в git , локальные коммиты "бинарников" от 1С (cf, epf, erf) в ветке "dev". В git хочу добавить пару хуков по распаковке cf, epf, erf в исходники и коммит в репозитарий с иходниками с аналогичным комментарием, данный репо уже подключен к redmine и там красиво отображаем статитстикуи кто и чего и когда подправил в коде

- Коммитом считать помещение в хранилище - ужас как долго

согласен, поэтому я использую внешние системы версионного контроля ,в течении дня, для микрокоммит.

Вообще самое трудное это комментарий к коммиту, даже иногда при помещении в хранилище не знаешь, что написать.

Добрый день, можно скинуть файлик на файлообменник - очень интересно посмотреть, а то пишут "У вас нет необходимых прав для просмотра вложений в этом сообщении. "

Идея с коммитами самая логичная и я к ней склоняюсь в первую очередь, но:
- Коммитом считать помещение в хранилище - ужас как долго
- Иногда программистам хочется именно анализировать взаимный код когда идет крупный проект, чтобы понимать кто что куда написал, зачем и для кого
- а как программист решить за одну правку несколько различных задач не проверив их в работе я не представляю: А очень просто - сказали исправить ошибку там-то и там-то, он заходит и оптимизирует код допустим который там видит, но чужой. Хочется понимать что он делает и зачем.

Одним словом я не понимаю пока что как можно достучаться до внутренностей самой разработки в конфигураторе сторонними средствами, может посоветуете?

Может вам прийти к атомарным коммитам? Т.е. каждый коммит это минимально необходимые изменения для решения одной задачи, т.е. за для решения 10 задач у программиста будет 10 коммитов в отдельной системе, а итоговый уже идет в хранилище.
Для затравки у меня допустим сейчас в fossil есть 2 ветки dev и trunk , в dev все текущие commit, в trunk попадает только из хранилища и выглядит это как merge trunk с dev, для истории и последующих программистов оставлен стандартный сценарий работы от 1С, а для меня видны мелкие правки для каждой отдельной задачи, а так же в redmine виден каждый коммит с привязкой к каждой задаче.

SerMaxim писал(а):За один сеанс программист может решать множество задач

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

p.s.: то что я описал пока работает с жуткими костылями и не имеет права называться пока хоть каким то решением.

Добрый день.

1. Разумеется цель не перехват событий клавиатуры, а собрать кто что делал, где и когда. За один сеанс программист может решать множество задач,
2. Если есть скрипт перехвата событий между сохранениями, то, вероятно его можно настроить и для более глобальных дел... Есть ли вариант разработки скриптов по заказу чтобы получить готовый результат, который уже самостоятельно наворачивать в рамках отдельного договора?

По изменениям в метаданных - при каждом изменении генерируется событие, которое можно обработать в скриптах.
Есть наброски скрипта - логгера, что изменяли во время сеанса.

Отлавливать каждую клавишу - в-принципе возможно, но зачем - не понимаю, работать надо с более "крупными" событиями.

Скрипты, направленные на построение систем управления проектами - никто не запрещает их делать. Есть желание - начинайте. Будут конкретные проблемы/затыки - буду решать, вместе победим.

Аддины можно делать не только на скриптовых языках. Практически хоть на чем можно делать.
Вот только ковырять, как запустить интерпретатор 1С в Конфигураторе - я честно говоря не собираюсь.
Имхо, овчинка выделки не стоит, и даже если получится, то полученный результат не оправдает затраченных усилий.