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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

не спорю.
однако ж масса проектов, где есть... хм... читатели.

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

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

я видел много людей, которым ИНТЕРЕСНО.
но я видел ОЧЕНЬ мало людей, у которых была бы отдельная аксапта для исследовательских нужд.

Цитата:

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

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

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

ключевое слово "удобно" )

[Bobkov]

Цитата:

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

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

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

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

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

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

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

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

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

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

[mazzy]

Цитата:

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

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

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

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

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


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

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

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

[Андре]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

Цитата:

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

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

[mazzy]

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

[Андре]

Цитата:

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

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

[mazzy]

Цитата:

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

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

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

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

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

[Андре]

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

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

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

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

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

[belugin]

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

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