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

[Lemming]

Как я уже говорил в других топиках, я пишу Open Source ERP систему для SMB. Пока что я занят исследованиями и бОльшая часть времени уходит на JavaScript и вообще Frontend.

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

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

То есть, по сути вопрос звучит так: смог ли бы программист уровня Линукса Торвальдся повторить в одиночку за лет, примерно, 20 аксапту версии, скажем, 3.0 c поправками на современные веб-реалии. Я ни в коем случае не ставлю себя в один ряд с создателем Linux, я просто пытаюсь понять насколько утопична моя затея!?

[belugin]

Если речь идёт обо всем вместе а не только о платформе, то т вряд ли. Мне кажется, столько в одну голову просто не влезет.

Надо одновременно быть фуллстеком и консультантом по многим модулями и странам.

Да и цель такую вряд ли стоит ставить. Если заниматься маркетингом то после появления успешного mvp должны присоединиться другие люди.

А какое позиционирование у вашей системы?

[Lemming]

Цитата:

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

А какое позиционирование у вашей системы?

Пока что никакого, потому что система "есть" только в голове и обрывках R&D кода, причем из этих обрывков можно только маркетинговый лэндинг собрать и всё. Хочется для малого и среднего бизнеса. На Российский рынок ориентируюсь в последнюю очередь из-за одного сильного игрока, который сделал почти "бесплатную" Open Source и 10 лет занимается маркетингом, а не платформой.

По функционалу есть вообще безумная идея: взять международную аксапту 3.0 и начать переносить функционал на свою платформу, собственно в связи с этой идеей я и задал этот вопрос.

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

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

[sukhanchik]

Для ответа на вопрос нужна самая главная информация - будет ли спрос на эту систему?
Вот например, в Почте России взамен Microsoft Office внедряют российскую разработку MyOfiice. Соответственно, кто-то "пролез" и "убедил" сделать это внедрение в рамках импортозамещения. Мнение пользователей и обслуживающего персонала естественно никто не спрашивал.

Так и тут. Если есть понимание, как организовать спрос - система будет. А уровень знаний разработчика - не сильно важен. Даже если предположить, что Basic - чистое детище Билла Гейтса (в разных источниках ставится под сомнение его единоличное авторство), а не каждый программист может придумать язык программирования, то тот же Microsoft деньги сделал отнюдь не на нём, а на предустановленной системе MS-DOS на тех компьютерах, которые выпускались IBM-ом.
Соответственно, если есть возможность (в виде деловых связей), которые могут организовать массовое пилотное внедрение, то система жить будет. Если нет - то скорее всего идея утопична.

[Lemming]

Цитата:

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

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

Речь идет об Open Source проекте, причем это что-то вроде детской мечты стать космонавтом или лётчиком, поэтому система должна не на связях выехать, а за счет своих других положительных качеств. Если я на ней ничего не заработаю вообще в денежном выражении, но она будет где-то использоваться, то для меня это успех!

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

p.s. Никаких связей нет, причем даже те что были по аксапте кроме как через этот форум не доступны.

[mazzy]

Цитата:

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

То есть, по сути вопрос звучит так: смог ли бы программист уровня Линукса Торвальдся повторить в одиночку за лет, примерно, 20 аксапту версии, скажем, 3.0 c поправками на современные веб-реалии. Я ни в коем случае не ставлю себя в один ряд с создателем Linux, я просто пытаюсь понять насколько утопична моя затея!?

1.
Вопрос хороший. На этот вопрос ответ - нет.
https://www.youtube.com/watch?v=n1F_MfLRlX0

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

2.
Несомненно, что сам Линус создал git, как форк от существующей системы контроля версий. git являлся инструментом разработки для той самой группы разработчиков Линукса.

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

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

предыдущие переломные моменты:
* 8бит -> 16бит (появление IBM PC)
* 16бит -> 32бита (до сих пор Windows структуры для передачи данных 16битные, а кое-где встречаются каталоги типа System32)
* 32бита -> 64бита (многие не особо заметили)
* растровая графика -> 3d графика (в том числе шрифты)

после каждого переломного момента, компоненты фронтенда менялись кардинально. Ну кто теперь в зравом уме помнит Turbo Vision или какие-нибудь OWL с MFC...

вот и сейчас похоже будет очередной перелом и очередная смена компонент для фронтенда.
"Опять придется покупать Белый альбом Битлз" (С) Люди в чёрном.

4.
что могу сказать за "JavaScript и вообще Frontend"
JavaScript слишком низкоуровневый код для сложного ERP приложения.
Какие-нибудь планировщики задач с десятком контролов на нем еще получаются
а вот сотни контролов - уже неуправляемо.

Grid с полями для JavaScript почти невозможным по сложности объектом. А уж грида со вкладками и подробными сведениями на вкладках вообще не видел.
https://www.npmjs.com/search?q=grid

скорее для фронтенда стоит взять уровень повыше. типа того же Vaadin
https://vaadin.com/components/vaadin-grid/java-examples

[Lemming]

Идея с позиционированием следующая: предполагается платформа под лицензией Apache 2.0, следующим слоем идет то, что я решил назвать Fundamentals - это основные таблицы и справочники, что-то вроде SYS слоя в аксапте. Эти две части мне вероятно предстоит делать одному, вопрос сколько времени это займет и насколько это реально в одиночку сделать!?

Далее, если процесс пойдет хорошо и появятся инвесторы, предстоит сделать уже ERP, которую можно продавать в облаках и on-permise. Ну и для всего этого есть партнеры, которые будут продвигать свои решения с локальной функциональностью.

[mazzy]

Цитата:

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

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

"инвесторам" прежде всего надо ответить на вопрос, чем ЭТО отличается от уже существующих.

я, например, отслеживаю эти
https://github.com/mazzy-ax?tab=stars&q=erp

[mazzy]

Цитата:

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

Как я уже говорил в других топиках, я пишу Open Source ERP систему для SMB.

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

[Lemming]

Цитата:

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

"инвесторам" прежде всего надо ответить на вопрос, чем ЭТО отличается от уже существующих.

В моем всбудораженном сознании зреет план как сделать реально обновление стандарта, не ломая партнерские решения и разработку in-house. То есть, я реально думаю и исследую вопрос о том, как можно соврешенно разным компаниям, условно говоря, коммитить в одну и ту же форму. С удвольствием читаю тут на форуме всё то, что касается Extension, увы D365FO видел только на картинках и видео-роликах. Если я это не придумаю, то это будет личный жирный минус в чашу весов о моей затее.

[mazzy]

Цитата:

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

В моем всбудораженном сознании зреет план как сделать реально обновление стандарта, не ломая партнерские решения и разработку in-house.

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

примеры:
* vBulletin, на котором крутится этот форум (и вообще форумные движки)
* Mantis Bug Tracker - https://www.mantisbt.org/ - интересная реализация форм с плагинами. Формы получаются такие же "механистичные", как в ранних аксаптах
* FAR Manager
* nginx
* Gradle, NPM и другие менеджеры пакетов

в общем, плагины.

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

3.
чтобы понять каким мог быть интерфейс D365FO, стоит зарегистрироваться и посмотреть на https://portal.azure.com/
как там реализован infolog, как реализованы гриды и детальные сведения. и прочее.
как устроен портал ажура внутри - не знаю.

[Lemming]

Цитата:

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

1.
Легко. Изначально закрытая система с плагинами.

Есть одна проблема, которая всё усложняет -- расширение таблиц, то есть добавление в них полей. Вообще, я придумал как, но как говорит один бывший коллега "практика - критерий истины". Надо писать рабочий пример.

[Lemming]

Цитата:

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

3.
чтобы понять каким мог быть интерфейс D365FO, стоит зарегистрироваться и посмотреть на https://portal.azure.com/
как там реализован infolog, как реализованы гриды и детальные сведения. и прочее.
как устроен портал ажура внутри - не знаю.

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

[mazzy]

Цитата:

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

Есть одна проблема, которая всё усложняет -- расширение таблиц, то есть добавление в них полей. Вообще, я придумал как, но как говорит один бывший коллега "практика - каритерий истины". Надо писать рабочий пример.

легко. наследование таблиц, которое вводили в ax2012, это на самом деле расширение таблиц.

ядро отвечает за join таблиц расширений.
каждый плагин получает tableBase join tablePluginN

этот способ категорически не работает с внешними генераторами отчетов и внешними потребителями данных. собственно из-за чего наследование таблиц в ax2012 и выпилили - майкрософт топил за Reporting Service

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

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

[Lemming]

Цитата:

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

легко. наследование таблиц, которое вводили в ax2012, это на самом деле расширение таблиц.

ядро отвечает за join таблиц расширений.
каждый плагин получает tableBase join tablePluginN

Ты можешь привести пример алгоритма наследования на примере таблицы SalesTable или LedgerTrans, вот нам нужно туда поля добавить, у нас есть формы и отчеты, которые работают со оригинальной таблицей, что будет с ними?

[belugin]

Цитата:

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

Вложение 13170

Идея с позиционированием следующая: .

Что такое позиционирование
Позиционирование — это задача определения места товара, услуги, личности в сознании потребителя.

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

Правильно позиционированный продукт подразумевает:

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

[Lemming]

Sorry, Максим, торможу потому что ночь почти не спал.

В общем, сейчас реально тяжело и рано всё расписывать, но если в целом: во-первых, обновления не ломающие in-house доработки, во-вторых открытая лицензия, в третьих полноценный язык программирования с мощным DSL для описания бизнес-логики. (я думаю над Kotlin || Scala, но сегодня ночью увидел это и до утра бродил по их репозиториям).

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

[Lemming]

И да, многие ругают D365FO, я с ней знаком только по постам на форуме и открытой документации, но вот с точки зрения технологий они сделали то, что было разумным в их обстоятельствах. Во всяком случае, я пришел к таким выводам в процессе исследования разных вопросов для своей системы. И кстати, микрософту проще, у них есть Х++, а не только армия программистов. У меня есть только GitHub

[sukhanchik]

Цитата:

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

Ты можешь привести пример алгоритма наследования на примере таблицы SalesTable или LedgerTrans, вот нам нужно туда поля добавить, у нас есть формы и отчеты, которые работают со оригинальной таблицей, что будет с ними?

Решение, не требующее плагинов.
SalesTable
SalesTable_RU (SalesTable_RU.SalesTable == SalesTable.RecId). Связь 1:1 или 1:0 (1 - SalesTable, 0 - SalesTable_RU)
SalesTable_BR (SalesTable_BR.SalesTable == SalesTable.RecId) Связь 1:1 или 1:0 (1 - SalesTable, 0 - SalesTable_BR)

А вот обратиться в стандартном коде к новой таблице естественно не получится. Тут уже нужен "хук", как говорит mazzy
В D365FO сделали отдельный объект АОТа "Расширения таблиц" (также для форм) и дальше при билде все расширения "склеиваются" между собой и синхронизация добавляет все поля из всех расширений. При этом расширения (формально, по заявлению MS) могут линковаться при билде в абсолютно любой последовательности и нет возможности отследить их порядок (точнее MS оставляет за собой право пересмотреть порядок в любой момент времени)

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

[fed]

Цитата:

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

Sorry, Максим, торможу потому что ночь почти не спал.

В общем, сейчас реально тяжело и рано всё расписывать, но если в целом: во-первых, обновления не ломающие in-house доработки,

А ты уверен, что вообще есть спрос на обновления ? Мне казалось что есть спрос на стабильные решения, и на исправления тех ошибок, которые на данном конкретном внедрении создают проблемы. Но как показывает практика, эти ошибки можно и без вендора править...