20.02.2016, 16:25 | #21 |
Moderator
|
Цитата:
все говорят про "узлы АОТ".
собственно говоря, я и хочу понять - а почему так правильно? не удобнее ли с точностью до методов? Когда я этим занимался, меня интересовали ответы на такие вопросы, как - 1) кто и когда менял этот объект (желательно с ссылкой на запрос) 2) какие объекты и как поменялись при решении данной задачи. Для ответа на эти вопросы мне хватало детализации до объектов. Цитата:
а почему бранчи, а не подкаталоги, например?
А файлы в папках.... ну это просто отдельные сущности, никак не связанные друг с другом. Система просто не понимает, что это одно и то же. Цитата:
просто для каждого языка (ну, или для каждой платформы уже есть устоявшиеся соглашения). например, исходный код в каталоге src, юнит-тесты в каталоге test, документация в каталоге doc.
Цитата:
а почему?
можешь подробнее? |
|
20.02.2016, 16:29 | #22 |
Участник
|
Цитата:
на аксфоруме была замечательная идея: = вместо отдельных и очень дорогостоящих обращений к com-объектам Excel для заполнения отдельных ячеек = сначала создать двумерный массив System.object(,) заполнить его... = и уже его вставить в Excel одним COM- или .net-вызовом. ускоряет экспорт в эксель на порядок-два. = для какой версии Аксапты это сделано? = как именно создавался системный массив? = куда подсмотреть чтобы сделать так же? в какие строчки кода? = наконец, даже если я нашел xpo-проект и сделал форк для своей версии, то куда я должен положить свои наработки, чтобы люди это увидели и тоже использовали? еще сценарии использования: = человек написал exportXPO куда его положить, чтобы попросить у других совета и/или codeReview? = сделал дополнительный удобный метод для SysQuery - куда положить? где посмотреть удобные методы, сделанные другими людьми? = и т.п. собственно вот типичные сценарии использования. каждое действие должно выполняться удобно и с минимальными усилиями. иначе мне проще тупо написать свое и никуда ничего не выкладывать. что собственно и происходит. |
|
20.02.2016, 16:33 | #23 |
Moderator
|
Цитата:
иначе мне проще тупо написать свое и никуда ничего не выкладывать
И проектом поделились, и code review провели. И даже кто-то поставил. |
|
20.02.2016, 16:39 | #24 |
Участник
|
Цитата:
Как правильно обмениваться аксаптовскими проектами [, которые содержат только нестандартные объекты]? как можно ответить на данный вопрос? и какие задачи можно решать, на твой взгляд? Цитата:
вопрос твой не видел. ответил здесь Как правильно выкладывать проекты по Аксапте на github, например? и снова до объектов. а почему до объектов то? почему не до методов? да, я знаю, что стандартная аксапта одним движением создает XPO с точностью до узла АОТ. это единственная причина по которой вы все говорите об "объекте АОТ"? Цитата:
Сообщение от Андре
То есть, если у меня бранчи - это разные версии Ax, то поправив багу в одном бранче я могу ее более-менее автоматически перекинуть на другой.
... А файлы в папках.... ну это просто отдельные сущности, никак не связанные друг с другом. Система просто не понимает, что это одно и то же. но ведь разные версии, как правило, должны быть ОЧЕНЬ разными. или нет? можешь рассказать свой опыт? Цитата:
Цитата:
поскольку у меня всегда была отдельная тестовая аксапта, которую я мог портить и восстанавливать из контрольной точки... я например, как раз сначала заливал - смотрел примерно что получается. а потом либо просто откатывал на контрольную точку, либо откатывал и уж после этого занимался мержем. вот мне и интересно, а как это делают другие? поэтому и спрашиваю. |
|
20.02.2016, 16:42 | #25 |
Участник
|
ну, вот, снова!
снова ты отвечаешь в стиле "в принципе можно сделать". да верю я что можно! у меня то ключевое слово - удобно! кстати, согласись, что такие правки было бы удобнее предлагать и вносить в проект pull request'ом и/или делая ответы на issue в баг-трекере )))) Последний раз редактировалось mazzy; 20.02.2016 в 16:48. |
|
20.02.2016, 17:04 | #26 |
Moderator
|
Цитата:
а почему до объектов то? почему не до методов?
Цитата:
но ведь разные версии, как правило, должны быть ОЧЕНЬ разными. или нет?
можешь рассказать свой опыт? Я делаю отдельную ветку для каждого клиента. Есть базовая ветка master - это то базовое решение, которое мы ставим всем новым клиентам. Как только появляется новый клиент, от ветки master создается новая ветка, в которой будут уже вестись все доработки по новому проекту. Если я вижу, что какие-то из доработок могут быть полезны всем, я нужные коммиты сливаю с master. Цитата:
снова ты отвечаешь в стиле "в принципе можно сделать".
А вообще могу предложить два варианта - минимум и максимум Сначала минимум - сделай просто страничку, где собраны все готовые проекты. Со скринами и описанием. Теги не то. Многие не догадываются по ним искать. Многие не знают по каким искать. Теперь максимум, ну раз ты уж так глубоко в эту тему погрузился Была у меня когда то идея, но не было времени, написать свой инсталлятор Ax проектов. Смысл (в моей задумке заключался в том), что вместе с XPO проектом разработчик должен выкладывать некий XML файл, в котором описаны правила. Правила могут быть следующие: - Импортировать файл <some.xpo> - Проверить, есть ли в системе класс с таким именем (если нет, прервать установку) - Проверить, есть ли в системе метод с такой-то контрольной суммой (если нет, метод кто-то менял и импортировать опасно) - Перед импортом проекта загрузить и выполнить job - То же самое, но после импорта проекта - Создать добавить определенный MenuItem в нужный раздел Menu ну, и так далее.... |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
20.02.2016, 21:59 | #27 |
Участник
|
Мне кажется тут необходимо ответить на вопрос - а какие предполагаются способы использования выложенного кода. Мне видится два способа:
1) Почитать исходники, чтобы понять, как это сделано и почему так. Тут нужна во-первых - наглядность представления кода (например, удобная навигация между частями выложенного кода, подсветка синтаксиса, перекрестные ссылки и переход по ним). Во-вторых - нужно чтобы было удобно задавать автору вопросы по контексту, автору было бы удобно отвечать, а пользователю - получать эти ответы. Мне кажется, гитхабу вообще еще далеко до этого, а тем более в отношении Аксапты 2) Попробовать запустить, чтобы оценить пользовательский интерфейс. Тут нужна среда запуска, без нее я не представляю как. Не знаю технологий современной аксапты, но предполагаю, что можно сделать некий сервис, на котором будет по запросу автоматически инициализироваться аксапта нужной версии, наверное с демо-данными, выложенный код будет автоматически заливаться в нее, пользователь будет иметь доступ к этой аксапте через инет. Мне кажется, этот способ использования технологически уже имеет мало отношения к гитхабу, а значит и к теме данной ветки. Последний раз редактировалось Bobkov; 20.02.2016 в 22:07. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
20.02.2016, 22:22 | #28 |
Участник
|
- для искодников - GitHub просто потому, что это делают все, даже MS
- для установки nuget или chocolatey (я не знаю как GitHub интегрируюется с пакетными менеджерами) - я уже давно на новых виртуалках разворачиваю нужный софт командой cinst max.environment - там же будут и зависимости. Или свой репозиторий nuget/chocolatey Желательно чтобы тулзы ставились в отдельные модели (правда сами .axmodel мало применимы из за отуствия совместимости мжеду старшими и младшими версиями, наверное, надо как констроль версий каждый раз собирать из xpo) |
|
20.02.2016, 22:43 | #29 |
Участник
|
Цитата:
Сообщение от mazzy
как и во всех остальных проектах разработки...
нет проблемы что-то сделать в принципе - разработать можно все что угодно. есть сугубо экономический вопрос - будут ли затраченные усилия пользователя меньше, чем разобраться и сделать самому свой велосипед. если необходимо приложить усилия больше некоего порога, то люди просто не будут пользоваться "этой фигней". Единственная проблема, что большинство вещей, которые для нормальных программеров является обыденностью, для нас, конфигурастов вешь неизведанная Цитата:
например, сейчас проекты по аксапте на гитхаб не выкладываются.
например, на аксфоруме проекты выкладываются одним xpo-шником. и никто не следит за версиями... повторное использование проектов с аксфорума - та еще задача по затратам усилий. - Результат круче, если не писать дополнительное сообщение в форум или блог, а подправить вики - это дольше повторно используемо (вот, кстати, у Фаулера, bliki - он часто как часть блога анонсирует правки к старым статьям), но все предпочитают писать в блоги, так как авторство и просто - Результат круче, если не выкладывать xpo кучей на форум, а оформить как пакет пакетного менеджера чтоб было легко ставить + проект на гитхабе, чтобы было легко смотреть и трекать баги - Результат круче, если не дописать пару строк в CustVendSettle.settleNow, а досконально разобраться, как там что устроено и сделать такую модификацию, чтобы все вместе было просто и понятно (тут, опускаем последующий апгрейд для простоты), но большинство предпочитает залепить конкретную дырку каким угодно кривым способом. Т.е. удобнее для выкладывания для массы чем экспорт + пост на аксфорум не сделаешь (если только вендор не озаботится). Вопрос, можно ли найти хотя бы несколько энтузиастов, которые начнут на постоянной основе контрибьютить во что-то другое? Я кстати, в свое время сделал доморощенный пакетный менеджер для Ax (лучше б прикрутил http://chocolatey.org), но никто кроме меня им так и не пользуется См. также фейл с erpkb |
|
24.02.2016, 10:45 | #30 |
Участник
|
Цитата:
Цитата:
Сообщение от belugin
Я кстати, в свое время сделал доморощенный пакетный менеджер для Ax (лучше б прикрутил http://chocolatey.org), но никто кроме меня им так и не пользуется
https://habrahabr.ru/post/143996/ https://habrahabr.ru/post/210626/ да, aptitude - предельно удобная штука в Unix-мире. |
|
24.02.2016, 11:01 | #31 |
Участник
|
Да, у меня есть скрипт, который развертывает chocolatey, добавляет туда локальные репозитории (где хранятся пакеты для софта, который я использую, как внутренний так и Open Source), а затем вызывает cinst для переданной строчки
в итоге я ставлю софт на свежей машине строчкой типа \\mydesktop\choco\get max.environment, где max.environment это пакет в котором хранятся только зависимости. X++: <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> |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|