Как правильно выкладывать проекты по Аксапте на github, например?

[Андре]

Цитата:

все говорят про "узлы АОТ".
собственно говоря, я и хочу понять - а почему так правильно?
не удобнее ли с точностью до методов?

Система контроля версий - это просто инструмент. Он позволяет тебе решать твои задачи. А какие у тебе задачи ?

Когда я этим занимался, меня интересовали ответы на такие вопросы, как - 1) кто и когда менял этот объект (желательно с ссылкой на запрос) 2) какие объекты и как поменялись при решении данной задачи.

Для ответа на эти вопросы мне хватало детализации до объектов.

Цитата:

а почему бранчи, а не подкаталоги, например?

Ммм... да тут даже сложно в двух словах описать. Например, коммиты (изменения) сделанные в одном бранче я могу накатить на другой бранч. То есть, если у меня бранчи - это разные версии Ax, то поправив багу в одном бранче я могу ее более-менее автоматически перекинуть на другой.

А файлы в папках.... ну это просто отдельные сущности, никак не связанные друг с другом. Система просто не понимает, что это одно и то же.

Цитата:

просто для каждого языка (ну, или для каждой платформы уже есть устоявшиеся соглашения). например, исходный код в каталоге src, юнит-тесты в каталоге test, документация в каталоге doc.

Как я понимаю, эти соглашения вызваны средствами сборки тестирования и разработки, которые есть в том или ином языке. Ну, то есть, если это C - то скорее всего я найду Makefile. В Ax - ты все равно ручками будешь проект импортировать. По этому я не вижу здесь места для каких то соглашений (до тех пор пока не появятся автоматизированные инструменты сборки/импорта).

Цитата:

а почему?
можешь подробнее?

Ну потому что я не могу себе представить опытного разработчика Ax, который неглядя зальет проект. Он его сначала прогонит через инструмент сравнения объектов в Ax. А значит выполнит весь этот merge ручками.

[mazzy]

Цитата:

Сообщение от Андре

Потому, что кроме автора никому это не интересно ? Ну, по крайне мере участие в развитии, про сам проект я не буду говорить.

Типичный пример использования - экспорт в Эксель.

на аксфоруме была замечательная идея:
= вместо отдельных и очень дорогостоящих обращений к com-объектам Excel для заполнения отдельных ячеек
= сначала создать двумерный массив System.object(,) заполнить его...
= и уже его вставить в Excel одним COM- или .net-вызовом.
ускоряет экспорт в эксель на порядок-два.

= для какой версии Аксапты это сделано?
= как именно создавался системный массив?
= куда подсмотреть чтобы сделать так же? в какие строчки кода?
= наконец, даже если я нашел xpo-проект и сделал форк для своей версии, то куда я должен положить свои наработки, чтобы люди это увидели и тоже использовали?


еще сценарии использования:
= человек написал exportXPO куда его положить, чтобы попросить у других совета и/или codeReview?
= сделал дополнительный удобный метод для SysQuery - куда положить? где посмотреть удобные методы, сделанные другими людьми?
= и т.п.

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

что собственно и происходит.

[Андре]

Цитата:

иначе мне проще тупо написать свое и никуда ничего не выкладывать

Было бы желание - Еще один импорт курсов валют
И проектом поделились, и code review провели. И даже кто-то поставил.

[mazzy]

Цитата:

Сообщение от Андре

Система контроля версий - это просто инструмент. Он позволяет тебе решать твои задачи. А какие у тебе задачи ?

я ж писал:
Как правильно обмениваться аксаптовскими проектами [, которые содержат только нестандартные объекты]?

как можно ответить на данный вопрос?
и какие задачи можно решать, на твой взгляд?

Цитата:

Сообщение от Андре

Когда я этим занимался, меня интересовали ответы на такие вопросы, как - 1) кто и когда менял этот объект (желательно с ссылкой на запрос) 2) какие объекты и как поменялись при решении данной задачи.

а... ты про сценарии использования... ты в майкрософте щас что ли?
вопрос твой не видел. ответил здесь Как правильно выкладывать проекты по Аксапте на github, например?

Цитата:

Сообщение от Андре

Для ответа на эти вопросы мне хватало детализации до объектов.

и снова до объектов.
а почему до объектов то? почему не до методов?

да, я знаю, что стандартная аксапта одним движением создает XPO с точностью до узла АОТ.
это единственная причина по которой вы все говорите об "объекте АОТ"?

Цитата:

Сообщение от Андре

То есть, если у меня бранчи - это разные версии Ax, то поправив багу в одном бранче я могу ее более-менее автоматически перекинуть на другой.
...
А файлы в папках.... ну это просто отдельные сущности, никак не связанные друг с другом. Система просто не понимает, что это одно и то же.

а... интересная мысль. спасибо... надо подумать...

но ведь разные версии, как правило, должны быть ОЧЕНЬ разными. или нет?
можешь рассказать свой опыт?

Цитата:

Сообщение от Андре

средствами сборки
...
В Ax - ты все равно ручками будешь проект импортировать.

*задумчиво* спасибо тебе добрый фей... надо подумать... возможно, что-то в этом есть.

Цитата:

Сообщение от Андре

Он его сначала прогонит через инструмент сравнения объектов в Ax. А значит выполнит весь этот merge ручками.

ну... чтобы тратить силы на merge ручками нужно хотя бы в общих чертах определиться что это за хрень.

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

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

вот мне и интересно, а как это делают другие?
поэтому и спрашиваю.

[mazzy]

Цитата:

Сообщение от Андре

Было бы желание....

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

у меня то ключевое слово - удобно!

кстати, согласись, что такие правки было бы удобнее предлагать и вносить в проект pull request'ом и/или делая ответы на issue в баг-трекере ))))

[Андре]

Цитата:

а почему до объектов то? почему не до методов?

Потому что на мой субъективный взгляд это был достаточный уровень детализации.

Цитата:

но ведь разные версии, как правило, должны быть ОЧЕНЬ разными. или нет?
можешь рассказать свой опыт?

Не обязательно. А вообще по разному. Иногда думаешь, что будет чуть-чуть отличаться, а через месяц - уже совсем другая хрень

Я делаю отдельную ветку для каждого клиента. Есть базовая ветка master - это то базовое решение, которое мы ставим всем новым клиентам. Как только появляется новый клиент, от ветки master создается новая ветка, в которой будут уже вестись все доработки по новому проекту. Если я вижу, что какие-то из доработок могут быть полезны всем, я нужные коммиты сливаю с master.

Цитата:

снова ты отвечаешь в стиле "в принципе можно сделать".

Не, я скорее о том, что ничего не надо делать.

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

Сначала минимум - сделай просто страничку, где собраны все готовые проекты. Со скринами и описанием. Теги не то. Многие не догадываются по ним искать. Многие не знают по каким искать.

Теперь максимум, ну раз ты уж так глубоко в эту тему погрузился Была у меня когда то идея, но не было времени, написать свой инсталлятор Ax проектов. Смысл (в моей задумке заключался в том), что вместе с XPO проектом разработчик должен выкладывать некий XML файл, в котором описаны правила.

Правила могут быть следующие:

- Импортировать файл <some.xpo>
- Проверить, есть ли в системе класс с таким именем (если нет, прервать установку)
- Проверить, есть ли в системе метод с такой-то контрольной суммой (если нет, метод кто-то менял и импортировать опасно)
- Перед импортом проекта загрузить и выполнить job
- То же самое, но после импорта проекта
- Создать добавить определенный MenuItem в нужный раздел Menu

ну, и так далее....

[Bobkov]

Цитата:

Сообщение от mazzy

для начала бы сделать, чтобы было удобно использовать выложенное.

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

1) Почитать исходники, чтобы понять, как это сделано и почему так.

Тут нужна во-первых - наглядность представления кода (например, удобная навигация между частями выложенного кода, подсветка синтаксиса, перекрестные ссылки и переход по ним).

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

Мне кажется, гитхабу вообще еще далеко до этого, а тем более в отношении Аксапты

2) Попробовать запустить, чтобы оценить пользовательский интерфейс.

Тут нужна среда запуска, без нее я не представляю как. Не знаю технологий современной аксапты, но предполагаю, что можно сделать некий сервис, на котором будет по запросу автоматически инициализироваться аксапта нужной версии, наверное с демо-данными, выложенный код будет автоматически заливаться в нее, пользователь будет иметь доступ к этой аксапте через инет.

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

[belugin]

- для искодников - GitHub просто потому, что это делают все, даже MS
- для установки nuget или chocolatey (я не знаю как GitHub интегрируюется с пакетными менеджерами) - я уже давно на новых виртуалках разворачиваю нужный софт командой cinst max.environment - там же будут и зависимости. Или свой репозиторий nuget/chocolatey

Желательно чтобы тулзы ставились в отдельные модели (правда сами .axmodel мало применимы из за отуствия совместимости мжеду старшими и младшими версиями, наверное, надо как констроль версий каждый раз собирать из xpo)

[belugin]

Цитата:

Сообщение от mazzy

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

Я думаю, если и делать свой велосипед, то только из стандартных деталей. Это мегаламеризм не использовать уже готовое а выдумывать свое без анализа.

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

Цитата:

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

Очень немногие люди когда легко что-то сделать не очень удобно но легко сделать, предпочитают легко сделать, но не очень удобно.

- Результат круче, если не писать дополнительное сообщение в форум или блог, а подправить вики - это дольше повторно используемо (вот, кстати, у Фаулера, bliki - он часто как часть блога анонсирует правки к старым статьям), но все предпочитают писать в блоги, так как авторство и просто

- Результат круче, если не выкладывать xpo кучей на форум, а оформить как пакет пакетного менеджера чтоб было легко ставить + проект на гитхабе, чтобы было легко смотреть и трекать баги

- Результат круче, если не дописать пару строк в CustVendSettle.settleNow, а досконально разобраться, как там что устроено и сделать такую модификацию, чтобы все вместе было просто и понятно (тут, опускаем последующий апгрейд для простоты), но большинство предпочитает залепить конкретную дырку каким угодно кривым способом.

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

Я кстати, в свое время сделал доморощенный пакетный менеджер для Ax (лучше б прикрутил http://chocolatey.org), но никто кроме меня им так и не пользуется

См. также фейл с erpkb

[mazzy]

Цитата:

Сообщение от belugin

я уже давно на новых виртуалках разворачиваю нужный софт командой cinst max.environment - там же будут и зависимости.

Цитата:

Сообщение от belugin

Я кстати, в свое время сделал доморощенный пакетный менеджер для Ax (лучше б прикрутил http://chocolatey.org), но никто кроме меня им так и не пользуется

cinst - жто chocolatey?
https://habrahabr.ru/post/143996/
https://habrahabr.ru/post/210626/

да, aptitude - предельно удобная штука в Unix-мире.

Цитата:

Сообщение от belugin

См. также фейл с erpkb

[belugin]

Цитата:

Сообщение от mazzy

cinst - жто chocolatey?

Да, у меня есть скрипт, который развертывает chocolatey, добавляет туда локальные репозитории (где хранятся пакеты для софта, который я использую, как внутренний так и Open Source), а затем вызывает cinst для переданной строчки

в итоге я ставлю софт на свежей машине строчкой типа \\mydesktop\choco\get max.environment, где max.environment это пакет в котором хранятся только зависимости.

<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
  <metadata>
    ...
    <dependencies>
      <dependency id="far" />
      <dependency id="conemu" />
      ...
      <dependency id="ditto" />
      <dependency id="kdiff3" />
    </dependencies>
  </metadata>

Есть еще http://www.boxstarter.org/ поверх choco но мне стремновато вообще все проводить через какой-то левый сервис, генерирующий скрипты на каждый чих.