Тестировать идею. Например, экспресс-доставку соевых сосисок при заказе их по вацапу. Хранить заказы, оплаты, клиентов; дать какой-то интерфейс для всего этого. Проверить, интересно ли это публике и сколько можно собрать заказов. Неважно, какой интерфейс, лишь бы не на бумажке записывать, а потом с калькулятором считать статистику.
MVC не рекомендует смешивать визуальное и цифровое, в данном построителе происходит такое смешение.
Когда есть 2 дня времени и выбор стоит между Google tables, Python, Java, Excel, no-code и бесконечные фреймворки, то реально что-то сделать только в Google tables и no-code.
И тут уж не до MVC.
Проблемы возникают в любой разработке, а no-code применяется для тестирования гипотез — чтобы что-то быстро собрать и проверить жизнеспособность идеи, а её воплощение в софте третьестепенно.
Для бухгалтеров есть свой софт, а тут речь идет про быстрые поделки, но в которых уже нужно больше, чем простая формочка с сохранением результата в таблице.
Зачем нанимать программиста для создания отчётов если можно написать просто select name, amount from wares where wares.warehouse = «main»?
Программиста нанимать следует затем, что он понимает что-то в архитектуре и может спроектировать систему, что недоступно и неинтересно пользователю. А отчеты создавать действительно может сам пользователь, и накликать его в визуальном редакторе несколько легче, чем писать SELECT… FROM… JOIN и задумываться как связать таблицы
Понимаете ли, говорить, что выражение ROUND(IF(ПТУ IS NULL, [СебестоимостьПредыдущая], ([СебестоимостьПредыдущая] * [ОстатокПредыдущий] + IF(Черновик IS NULL, — SUM(price), SUM(price))) / ([ОстатокПредыдущий] + IF(Черновик IS NULL, — SUM(qty), SUM(qty))), 2) — не программирование, это, знаете ли, маркетинговая уловка, и ничего более. Выглядит и пахнет оно как программирование, только с применимостью «хороших практик» как-то не очень.
Не программирование на языке программирования. Это формула, которую вы запросто можете встретить в ТЗ, например, которое пишет не программист.
Вы не поверите, я и в языках программирования не учу их особенности, чтобы посчитать синус, я просто пишу sin() или Math.Sin или еще что-нибудь аналогичное.
Это внутри метода, чтобы написать который (с применимостью «хороших практик») новичку нужно учиться полгода.
Функции и формулы существуют вне языков программирования (ЯП), хотя не в каждом ЯП они реализованы одинаково и прям вот все. То есть, если я знаю что такое синус — SIN(), то мне не нужно учить особенности ЯП, чтобы его посчитать. Я ставлю привычную функцию и пишу привычные формулы.
Я пост не читал, ибо много букв и ошибки режут глаз. Прокрутил до комментариев и увидел забавное сочетание про эджайл-коучей и no-code. Триггернуло. Коучам я не доверяю ни разу, а вот по второму пункту вполне себе есть прикольные примеры.
Раз вы участвуете в обсуждении, причем чаще всех, значит статья для Вас.
Мнение, опыт и наработки автора не совпадают с вашими ожиданиями, такое бывает, однако у вас какие-то тёмные истории с EAV таки были, поэтому вы так негативно активны в этом обсуждении вроде бы не относящейся к вам статьи.
Спасибо.
Статья написана в расчете получить мысли и критику таких как вы, вызнать про опыт и сомнения, протестировать подход, определить следующую планку.
Я там сравниваю также объемы данных и, с учетом того, что нормализация в нашем случае обходится дешевле и получается доступнее, объемы получаются примерно одинаковые.
По алгоритмам пока сложно сравнивать из-за большой разницы в подходах. Я планирую сделать построитель процессов в ближайшее время, чтобы показать разработку и использование алгоритмов и определиться с парадигмой, наконец.
Конечно, мы ещё не все грабли прошли, так что будем наблюдать.
Я и про EAV лет пятнадцать назад то же самое говорил. Причем включая интерфейс. Да что там 15 лет назад, в этом году на хабре обсуждали очередную реинкарнацию, причем вот ровно с теми же обещаниями, что вы тут озвучиваете.
Про интерфейс интересно, о чём вы говорили 15 лет назад. Расскажете в чем суть?
Мы сделали обещанную реинкарнацию и хотим двигаться дальше.
Тестировать идею. Например, экспресс-доставку соевых сосисок при заказе их по вацапу. Хранить заказы, оплаты, клиентов; дать какой-то интерфейс для всего этого. Проверить, интересно ли это публике и сколько можно собрать заказов. Неважно, какой интерфейс, лишь бы не на бумажке записывать, а потом с калькулятором считать статистику.
Когда есть 2 дня времени и выбор стоит между Google tables, Python, Java, Excel, no-code и бесконечные фреймворки, то реально что-то сделать только в Google tables и no-code.
И тут уж не до MVC.
Для бухгалтеров есть свой софт, а тут речь идет про быстрые поделки, но в которых уже нужно больше, чем простая формочка с сохранением результата в таблице.
Программиста нанимать следует затем, что он понимает что-то в архитектуре и может спроектировать систему, что недоступно и неинтересно пользователю. А отчеты создавать действительно может сам пользователь, и накликать его в визуальном редакторе несколько легче, чем писать SELECT… FROM… JOIN и задумываться как связать таблицы
Не программирование на языке программирования. Это формула, которую вы запросто можете встретить в ТЗ, например, которое пишет не программист.
Это внутри метода, чтобы написать который (с применимостью «хороших практик») новичку нужно учиться полгода.
Я пост не читал, ибо много букв и ошибки режут глаз. Прокрутил до комментариев и увидел забавное сочетание про эджайл-коучей и no-code. Триггернуло. Коучам я не доверяю ни разу, а вот по второму пункту вполне себе есть прикольные примеры.
Вероятно, нет.
Вот квадратики: https://m.youtube.com/watch?v=P2KQ5VA4L7Y
Вот схема, чтобы комп понял, а кода нету:
https://m.youtube.com/watch?v=K7RpGL35k_4
The service in action as #nocode tool
https://m.youtube.com/watch?v=HRDTs3JPvOc
Мнение, опыт и наработки автора не совпадают с вашими ожиданиями, такое бывает, однако у вас какие-то тёмные истории с EAV таки были, поэтому вы так негативно активны в этом обсуждении вроде бы не относящейся к вам статьи.
Но на хабре разные есть читатели, я для всех пишу.
Статья написана в расчете получить мысли и критику таких как вы, вызнать про опыт и сомнения, протестировать подход, определить следующую планку.
Но про попытки коллег интересно узнать на будущее.
По алгоритмам пока сложно сравнивать из-за большой разницы в подходах. Я планирую сделать построитель процессов в ближайшее время, чтобы показать разработку и использование алгоритмов и определиться с парадигмой, наконец.
Конечно, мы ещё не все грабли прошли, так что будем наблюдать.
В этом плане легко не будет в любом случае. Даже UI/UX у всех почти выделено в самостоятельное направление.
Общение с базой не требует квалификации IT, интерфейс можно собрать из плагинов, подключаемых до неприличия легко.
Про интерфейс интересно, о чём вы говорили 15 лет назад. Расскажете в чем суть?
Мы сделали обещанную реинкарнацию и хотим двигаться дальше.