У заказчика собственные требования и к графическому интерфейсу, и к формату/форме отчетов, и к принципам разграничения доступа к данным - в код залезать придется. ...а для для примитивных случаев есть Excel.
Для оптимизации при работе с нативными обьектами вовсе не нужно быть академиком, достаточно знать SQL, особенности конкретной СУБД и иметь некоторый опыт. А ваша система - лишние уровни абстракции, и всё ради борьбы с выдуманной проблемой. Где, например, вы возьмёте специалистов, готовых броться с IDEAV?
Современные солнечные коллекторы могут и +300°С в теплоносителе обеспечить. Тепло теряется, но вовсе не из-за неэффективности поглощающего свет покрытия абсорбера (кстати, тот же оксид титана используется), а в основном в процессе дальнейшей передачи тепла потребителю...
Новость о новой технологии получения материала, который "возможно,может быть полезен", вот и всё.
А у меня была Электроника ВМ-18, уже "щелевая" система установки кассет. А электронная схема была такой же, почти. Я что-то там даже настраивал внутри, пока не продал жаждущему иметь видео. Сам я как-то не впечатлился возможностями видеомагнитофонов, максимум - детям "Чудеса на виражах" записывал и другие мультяшки.
У нас свой вариант EAV, часто очень привлекательно для клиентов: "вот смотрите, вы всё сами сможете, без привлечения разработчиков" - продавцы довольно успешно охмуряет клиентов. Реальность ВСЕГДА оказывается сложнее простых примеров от продавцов, и попавшие в ловушку клиенты привлекают нас, разработчиков. А уж мы вовсю страдаем, натягивая сову на глобус. Масштабируемость, нестандартные бизнес - правила, сложность интеграции с существующими фреймворками (например, с системой отчетов), проблема автоматизации переноса метаданных, трудности с поиском специалистов, готовых во всем этом вариться...
... а вы не думали сохранить low-code генератор, но генерировать не eav - структуры, а живые, настоящие таблички и др. объекты конкретной СУБД? Имхо, можно было бы многое упростить.
Крутяк. А мой один проект как-то незаметно на линуксовый сначала Firebird 3.0, а потом и на RedBase 3.0 перекинули. Экспериментаторы чёртовы, а не клиенты. Были бы udf-ки - фиг бы у них что получилось.
Я сперва в проекте базу с 2.0 на 3.0 проапгрейдил (с большим скрипом из-за проблем с юникодом в метаданных), а дальше клиенты уже сами втихую развлекались. Надо было хоть каких-нибудь udf наваять, чтобы не безобразничали.
Пример работы с Документом, Справочником, Журналом. Тексты триггеров, меняющих физические данные при модификации данных хранимок/вьюх. Работа со ссылочными данными (наприпер: как вы добавляете справочные данные, которых не оказалось в списке выпавшего комбо).
Про процесс модификации структуры расскажите. Как вы переносите новые метаданные из тестовой стстемы в рабочую?
Я свой древний Fujitsu-Siemens проапгрейдил: заменил блок клавиатуры на новый, вместо hdd поставил ssd, памяти поставил больше, чем предполагалось производителем (не было тогда модулей такой ёмкости), заменил ячейки 18650 в батарее на новые, установил Linux... ага, всё на удивление шустро "летает". Вот только ползоваться им совсем не хочется: TFT экран ужасен, по сравнению с матрицами современных дисплеев, крошечной тачпад, вентилятор шумит, звук "беее...", да и вес 3кг совсем не распрлагает к мобильности. Энергию жрет как не в себя, от батареи вмего часа три может...
Так и не придумал, для чего его можно использовать.
Купил в итоге себе (тонкий, легкий, быстрый, тихий, холодный,...) Lenovo ThinkPad и не нарадуюсь, а старый куда-то на полку.
Тут чистый маркетинг: якобы пользователь сам сможет написать нужное расширение или "на коленке" что-то поправить, и приводятся простейшие примеры, очень привлекат потенциальных покупателей.
...в реальности, требуются сложные вещи, которые пользователь заказывает (часто - у разработчика базовой стстемы). Разработчик в итоге страдает от ограничений скриптового языка. К примеру, нас отчетная система расширяется скриптовыми модулями. За 20 лет существования системы не припомню, чтобы пользователь накодил что-то вменяемое. Позже была добавлена система плагинов, плагины могут быть реализованы на любом ЯП, поддерживающем интерфейсы. А прежнюю скриптовую систему по просьбе продавцов выпиливать не стали, ибо покупатели клюют на такую фичу, ну и легаси.
... наверное, можно (в качестве рекламного шага - "вот что у нас есть!") реализовать и скриптовую систему как вариант реализации интерфейсов плагинной системы, чисто для продавцов.
Зачем выдумывать фантастические варианты?
https://youtu.be/PBkhKOywZxE?si=m_vA34NmUQl4oFoS&t=21m36s
А разве поибыль при добыче крипты не гарантированно деградирует?
А зачем вообще начали совершать сие шаманство над рабочим аккумулятором? Он стал плохо крутить стартер или что?
И - это вообще нормально - снять с авто аккумулятор на неделю[++]?
У заказчика собственные требования и к графическому интерфейсу, и к формату/форме отчетов, и к принципам разграничения доступа к данным - в код залезать придется. ...а для для примитивных случаев есть Excel.
Для оптимизации при работе с нативными обьектами вовсе не нужно быть академиком, достаточно знать SQL, особенности конкретной СУБД и иметь некоторый опыт. А ваша система - лишние уровни абстракции, и всё ради борьбы с выдуманной проблемой. Где, например, вы возьмёте специалистов, готовых броться с IDEAV?
Современные солнечные коллекторы могут и +300°С в теплоносителе обеспечить. Тепло теряется, но вовсе не из-за неэффективности поглощающего свет покрытия абсорбера (кстати, тот же оксид титана используется), а в основном в процессе дальнейшей передачи тепла потребителю...
Новость о новой технологии получения материала, который "возможно,может быть полезен", вот и всё.
А у меня была Электроника ВМ-18, уже "щелевая" система установки кассет. А электронная схема была такой же, почти. Я что-то там даже настраивал внутри, пока не продал жаждущему иметь видео. Сам я как-то не впечатлился возможностями видеомагнитофонов, максимум - детям "Чудеса на виражах" записывал и другие мультяшки.
У нас свой вариант EAV, часто очень привлекательно для клиентов: "вот смотрите, вы всё сами сможете, без привлечения разработчиков" - продавцы довольно успешно охмуряет клиентов. Реальность ВСЕГДА оказывается сложнее простых примеров от продавцов, и попавшие в ловушку клиенты привлекают нас, разработчиков. А уж мы вовсю страдаем, натягивая сову на глобус. Масштабируемость, нестандартные бизнес - правила, сложность интеграции с существующими фреймворками (например, с системой отчетов), проблема автоматизации переноса метаданных, трудности с поиском специалистов, готовых во всем этом вариться...
... а вы не думали сохранить low-code генератор, но генерировать не eav - структуры, а живые, настоящие таблички и др. объекты конкретной СУБД? Имхо, можно было бы многое упростить.
Не, не нужно.
Наверное, не "хранимки", а "внешние функции"?
...
Крутяк. А мой один проект как-то незаметно на линуксовый сначала Firebird 3.0, а потом и на RedBase 3.0 перекинули. Экспериментаторы чёртовы, а не клиенты. Были бы udf-ки - фиг бы у них что получилось.
Я сперва в проекте базу с 2.0 на 3.0 проапгрейдил (с большим скрипом из-за проблем с юникодом в метаданных), а дальше клиенты уже сами втихую развлекались. Надо было хоть каких-нибудь udf наваять, чтобы не безобразничали.
Ох нихрена себе - (с)
Девушек мало среди рыбаков. Утром приедешь на водоём, весь берег в мужиках, дев очень мало. С этим что-то нужно делать.
Картинки давайте! :)
Пример работы с Документом, Справочником, Журналом. Тексты триггеров, меняющих физические данные при модификации данных хранимок/вьюх. Работа со ссылочными данными (наприпер: как вы добавляете справочные данные, которых не оказалось в списке выпавшего комбо).
Про процесс модификации структуры расскажите. Как вы переносите новые метаданные из тестовой стстемы в рабочую?
Матрица на моем матовая (1280x800), но качество картинки очень чувствительно к углу зрения; работать можно, но не очень хочется.
А три часа стало из-за того, что я элементы 18650 поставил бо'льшей емкости; сразу не больше двух часов тянул.
Esprimo V5545
Сколько впустую потраченных сил...
Я свой древний Fujitsu-Siemens проапгрейдил: заменил блок клавиатуры на новый, вместо hdd поставил ssd, памяти поставил больше, чем предполагалось производителем (не было тогда модулей такой ёмкости), заменил ячейки 18650 в батарее на новые, установил Linux... ага, всё на удивление шустро "летает". Вот только ползоваться им совсем не хочется: TFT экран ужасен, по сравнению с матрицами современных дисплеев, крошечной тачпад, вентилятор шумит, звук "беее...", да и вес 3кг совсем не распрлагает к мобильности. Энергию жрет как не в себя, от батареи вмего часа три может...
Так и не придумал, для чего его можно использовать.
Купил в итоге себе (тонкий, легкий, быстрый, тихий, холодный,...) Lenovo ThinkPad и не нарадуюсь, а старый куда-то на полку.
Вопрос: зачем заменять обезьяну, почему просто не подселить новую? И - куда дели ту обезьяну, что заменили?
Тут чистый маркетинг: якобы пользователь сам сможет написать нужное расширение или "на коленке" что-то поправить, и приводятся простейшие примеры, очень привлекат потенциальных покупателей.
...в реальности, требуются сложные вещи, которые пользователь заказывает (часто - у разработчика базовой стстемы). Разработчик в итоге страдает от ограничений скриптового языка. К примеру, нас отчетная система расширяется скриптовыми модулями. За 20 лет существования системы не припомню, чтобы пользователь накодил что-то вменяемое. Позже была добавлена система плагинов, плагины могут быть реализованы на любом ЯП, поддерживающем интерфейсы. А прежнюю скриптовую систему по просьбе продавцов выпиливать не стали, ибо покупатели клюют на такую фичу, ну и легаси.
... наверное, можно (в качестве рекламного шага - "вот что у нас есть!") реализовать и скриптовую систему как вариант реализации интерфейсов плагинной системы, чисто для продавцов.