Как вы думаете: смог бы Линус Торвальдс в одиночку за 20 лет полностью повторить Асапту версии 3.0?

[mazzy]

Цитата:

Сообщение от George Nordic

Да, можно взять код приложений 4,0 / 2009 и портировать его на "свой" движок. Вопрос, насколько это законно?

не-не-не. ни в коем случае.
я имел в виду открытые компоненты (бесплатные и условно платные)
типа cuba, vaadin, spring, data-gridы всевозможные.

Цитата:

Сообщение от George Nordic

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

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

Цитата:

Сообщение от George Nordic

Не скажи. Очень хороший задел был сделан.

был. согласен.
был - это правильное слово.

Цитата:

Сообщение от George Nordic

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

тоже согласен.

[AlexSD]

Цитата:

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

Поэтому легенда так себе, фиговенькая. Особенно, если она правда.

Мы там как-то суммировали количество кода российской + восточноевропеской локализации. Получилось что-то около 1 милиона строк. При том, что весь остальной "западный" функционал был тогда 3 миллиона строк. Не скажу, что это был только чистый код. Кажется, мы там просто суммировали количество строк в xpo. Но не в этом дело, а дело в соотношении между локализацией и основным кодом.
Вот этот миллион строк в 4-ке аптейкали 2 ПМа, 5 разработчиков и 3 тестера. Времени еле-еле хватало что бы только переложить код из 3-ки в 4-ку. При этом набо было добавлять и новый функционал для новых законов. 2009-ю делали большим количеством людей, но не сильно много.

"Каждый день к девяти утра я должен идти в мой магистрат. Я не скажу, что это подвиг, но вообще что-то героическое в этом есть ..." (С)

[twilight]

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

[Raven Melancholic]

Цитата:

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

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

Да, идея там хорошая. Но в чистом виде использовать сложно. Видимо разработана под определенные кейсы, а при других ситуациях сопоставление ломается.
Пытались взять её в чистом виде для Польской дочки, но с остальным польским функционалом получилась каша.
Это, кстати, как пример что нужно досконально продумывать и тестировать в системе плагинов/микросервисов - один плагин может ломать работу другого.

[fed]

Цитата:

Сообщение от Raven Melancholic

Это, кстати, как пример что нужно досконально продумывать и тестировать в системе плагинов/микросервисов - один плагин может ломать работу другого.

Позволю себе переформулировать это так: Система плагинов при обновлениях экономит время на апгрейде кода, но сильно повышает время на тестирование результата обновления. Как раз потому, что в системе со слоями или какими-то бранчами Version Control можно проанализировать большую часть изменений и взаимосвязей между ними статически, просто за счет анализа кода, а в системе с плагинами - только динамически, тестируя то что получилось.
И что-то мне кажется что экономия на апгрейде кода не окупает повышенные трудозатраты на тестирование.
Так что если бы новую ERP проектировал я (c), то я бы начал ее проектирование с какой-то смеси технологии слоев и технологии TFS (но не GIT). А с плагинами пущай микрософт мучается.

[Logger]

Цитата:

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

... А с плагинами пущай микрософт мучается.

Неее. Ему то пофиг. Это мы будем мучаться.

Напомнило:

Цитата:

- Папа, ты теперь будешь меньше пить ?
- Нет сынок, это теперь ты будешь меньше есть.

[mazzy]

Цитата:

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

Позволю себе переформулировать это так: Система плагинов при обновлениях экономит время на апгрейде кода, но сильно повышает время на тестирование результата обновления.

согласен.

но есть внешние системы (olap, отчеты)
для внешних систем нужна метаинформация.
о relation, о правах, о типах, о конфигурационных ключах...

внутренние структуры типа utilElements - не катят. (См. как мучаются в ER)
хранить как relation и constraints в MS SQL? а как права, типы форматирование?

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

чтобы "подключать", базовая система должна предоставлять базовые объекты (тип, класс, форма, отчет, таблица, запрос и т.п.)
базовая система не должна предоставлять бизнес-логику совсем. (см. системы сборки в java - maven и gradle)

[mazzy]

Цитата:

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

чтобы "подключать", базовая система должна предоставлять базовые объекты (тип, класс, форма, отчет, таблица, запрос и т.п.)

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

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

отдельная тема - отладчик.
все существующие в аксапте сложные фреймворки типа расчета зарплаты, финансовых отчетов, финансовой разноски, reporting service, AIF - это боль при отладке. некоторые псевдовнешние подсистемы типа ER, Retail Sync Service и пр. вообще не имеют отладчика.

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

мы видим код бизнес-логики, потом хоп - xRecord, а потом myTable.validationWrite.
или наш класс, потом хоп - xInfo, а потом снова выныриваем в другом нашем методе. Примерно так.

[belugin]

Цитата:

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

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

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

После чего мы получаем систему со слоями. Преобразовав версию 1 и версию 2 такой системы можно приступать к анализу диффа.

Цитата:

TFS (но не GIT).

А чем гит не угодил?

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

Потребитель, правда, норовит вместо следования предписаниям посмотреть на текущую реализацию и привязаться к ней

[belugin]

Цитата:

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

некоторые псевдовнешние подсистемы типа ER, Retail Sync Service и пр. вообще не имеют отладчика.

Есть, но, конечно, далеко не студия. И профайлер тоже есть, да.

Цитата:

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

мы видим код бизнес-логики, потом хоп - xRecord, а потом myTable.validationWrite.
или наш класс, потом хоп - xInfo, а потом снова выныриваем в другом нашем методе. Примерно так.

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

Не хочешь видеть чужого кода - не видишь. Хочешь видеть - видишь.

[fed]

Цитата:

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

После чего мы получаем систему со слоями. Преобразовав версию 1 и версию 2 такой системы можно приступать к анализу диффа.

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

Цитата:

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

А чем гит не угодил?

Ну мне кажется что Git слишком гибкий и тяжелый для данной проблемы. На конкретном проекте редко когда больше 5-7 разработчиков работает, редко когда больше двух активных веток разработки ведется, редко когда нет онлайна к репозиторию исходных текстов и тд и тп. В такой ситуации, особых преимуществ Git не дает, а шансов прострелить самому себе ногу - в Git гораздо больше.
Идеальным было бы что-то типа TFSVC, но с возможностью импорта diff между двумя версиями как новой ветки.
Еще можно было бы подумать на тему, что было бы, если бы система хранения версий знала бы о семантике метаданных и могла бы показывать например разницу между двумя версиями таблицы как "таблицу", но с одним индексом, тремя полями (с разной подсветкой в зависимости от типа изменения) и т.п. Это не стало бы прорывом, но затраты на мерджинг уменьшило бы раза в 2-3. Кроме того - если система версий знает о семантике объектов, то можно было бы сделать какие-то пользовательские расширения, которые например позволяли бы мерджить какие-то типы объектов автоматически, выдывали бы варнинги при всяких сомнительных мерджах и несовместимых изменениях и тд и тп.

[belugin]

Цитата:

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

Не очень понял, что ты хочешь сказать. В D365FO способа сравнить тексты двух версий нет.

Взять XPO из старой версии, взять XPO из новой версии, сравнить.

Цитата:

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

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

В данном треде мы обсуждаем идеи топикстартера. Это и есть гипотетическая новая система.

Соответственно вопрос, то, про что ты говоришь - фундаментальное ограничение или недостаток тулинга.

Цитата:

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

В такой ситуации, особых преимуществ Git не дает, а шансов прострелить самому себе ногу - в Git гораздо больше.

В целом согласен. Да, гит сложнее, но его знают больше.

[mau]

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

В Аксапте, как мне кажется, наоборот, уровень описания слишком низкий - таблица, класс, форма, отчет, специфические сущности.Это по сути высший технологический уровень. Порой не хватало элементов AOT типа справочник, журнал, документ, бизнес-процесс (который потом появился).

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

[Ace of Database]

Цитата:

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

В Аксапте, как мне кажется, наоборот, уровень описания слишком низкий - таблица, класс, форма, отчет, специфические сущности.Это по сути высший технологический уровень. Порой не хватало элементов AOT типа справочник, журнал, документ, бизнес-процесс (который потом появился).

Вот и мне интересно, они специально так делают? Всякие заказы на продажу, складские журналы, спецификации, сопоставления, маршруты комплектации, заказы на производство. Это же все можно засунуть в "документы". И обрабатывать их одинаковым API у которого наружу выставлены одинаковые методы. Вместо это сделали так, что каждый тип документа надо обрабатывать по-своему, изучать его кишки, изучать его структуру классов.
Прикладной программист, по сути, превращается в некоего хакера.
Пусть к "документу" будет низкоуровневый доступ как к таблице. Но хочется чтобы классы, которые обрабатывают "документы" имели одинаковые внешние точки вызова.Меня именно запутанность и разношерстность классов напрягает. А доступ к документам на уровне таблиц - это как раз преимущество.
Даже если брать не Аксапту, а например, сравнить веб-аутлук и майл-ру. В веб-аутлуке все запутано, где-то сообщения снизу вверх идут, где-то сверху вниз. И как-то мало полезной информации на экране, хотя весь экран загроможден чем-то. А в майл-ру с первых же дней использования сразу все понятно. Мне кажется, американские разработчики софта как-то запутались. И странно то, что те разработчики, которые делали удобные инструменты, например Борланд, исчезли. А остались те, которые делают неудобные Я например, в 1989 году не осилил Microsoft MSC, а на Борланд ТурбоВижн написал многооконный текстовый редактор с подсветкой синтаксиса и перекрывающимися окнами в текстовом режиме DOS. А на турбо-ассемблере написал графический редактор с закрашиванием областей.
Я 17 лет работаю со всеми версиями Аксапты, и все равно считаю Аксапту парадоксальной. Но такова жизнь Квантовая запутанность, жизнь состоит из парадоксов. И само явление жизни - это чудо. Поэтому я воспринимаю всю эту корявость как должное - просто я попал в ту вселенную, где такая Аксапта. Волновая функция вселенной так чудит.

[ax_mct]

Цитата:

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

Я хочу понять, что если допустим у меня есть ещё лет 20, когда у меня будет хватать сил целыми днями кодировать, реально ли создать продукт, с которым потом на старости лет заниматься маркетингом, привлечением сообщества и прочим?

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

Вот к примеру красивый движок что еще 5 лет назад произвело на меня впечатление
https://devdocs.magento.com/guides/v...e/plugins.html
С удовольствием бы работал в подобной стройной системе вместо копания в не поймешь что.

[ax_mct]

Цитата:

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

С ERP как с социальными сетями: никого не волнуют технологии, пока проект не набрал критическую массу. Odoo такая популярная в мире открытых КИС не потому что она на питоне написана или как-то удобно, а потому что там инвестиций 50 миллионов долларов и у них есть деньги не только на разработчиков, но и на мощный маркетинг.

В любом случае, начинать надо с западного рынка, хотя тут как говорится "куда ни кинь — всюду клин", потому что тут 1С, там Odoo. Я из-за этого много раз говорил себе, что всё мол, хватит - это невозможно, но я каждую ночь ложусь с мыслями об этом проекте и часто ловил себя на мысли, что если я сейчас просто устросюь работать программистом или консультантом, и забуду о своей идее, то в глубокой старости я сильнее всего буду жалеть именно о том, что не сделал, что не попробовал, что не приложил все усилия чтобы обойти все препятствия и завершить хотя бы одно внедрение!

Реальный challenge это не писать еще один 101 движок, который не лучше и не хуже, а взять тот же Odoo и внедрить его в реальном бизнесе. Все расширится что нужно и андреналина хватит. А потом уехать на этом опыте куда-нибудь в Эстонию и писать там свою ERP хоть на Haskell.

Чтобы ориентироваться на западный рынок вам надо туда переехать.

[Lemming]

Цитата:

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

Чтобы ориентироваться на западный рынок вам надо туда переехать.

Не вопрос, первая страна для этого США, одной ногой я уже там

[Lemming]

Год назад я ещё раздумывал о Российском рынке, но сейчас думаю хрен бы с ним. Вот моё видео годовалой давности Как нам конкурировать с 1С Если понравится, поддержите лайками и репостами в своих социальных сетях!

[Lemming]

Оказывается два года прошло с момента записи видео.

[miklenew]

Иногда почитываю форум, смотрю и ностальгирую.
Почитал тему, посмотрел видео.
Возник вопрос, а когда же это было. Посмотрел резюме.
С аксой я закончил работать в 2009 год.
Т.е уже 12 лет где то прошло.
А до сих пор помню inventtable, itemid, purchtable, purchline, salestable, invenmovement, ledgertrans. Аксапта 3.0, 4.0 для меня осталась лучшей средой для разработчика.
Самой кайфовой. Но MS всё делало тогда, чтоб похоронить продукт, или наоборот не делало, то что нужно было делать.
Перед самым уходом получил два сертификата по ах. Были мысли найти работу на стыке 1с и акс. Но такое так и не подвернулось. Один раз был близок, но поздно офер прислали.
Сейчас работаю в франче топ 5. Специализация внедрение 1С ERP.
По сути в моём послужном списке горстка разных бумажек:
MB6-509 Microsoft Dynamics™ AX 4.0 Trade & Logistics
MB6-507 Microsoft Dynamics™ AX 4.0 Financials

1С:Профессионал. Платформа 1С:Предприятие 8.2
1С:Профессионал. Зарплата и управление персоналом 8
1С:Профессионал. Управление торговлей 8
1С:Профессионал. Бухгалтерия 8
1С:Специалист. Платформа 1С:Предприятие 8
1С:Специалист-консультант. Бухгалтерия 8
1С:Специалист-консультант. Управление торговлей 8
1С:Специалист-консультант. Зарплата и управление персоналом 8
1С:Профессионал. ERP Управление предприятием 2
1С:Специалист-консультант по внедрению подсистем "Управление производством и организация ремонтов" в 1С:ERP 2
1С:Профессионал по технологическим вопросам

С последним видео, много что не так. Кирил, если моих знаний будет достаточно, напиши в личку, можем по скайпу или вотсап потрещать (за жизнь, за аксу, за 1С)
Не укладывается в моей голове зачем бороться с 1С, если можно возглавить?
Т.е. возненавидеть 1с, бросить здесь родных и близких и уехать забугор, это норм, а просто перейти в 1С где большой недостаток айтишников, плюс море удалёнки, это не норм.