Под рефлектами я имел ввиду отражение кого-либо экземпляра класса (его данных) в/из БД.
Да, сейчас стало понятней, что имелось ввиду, благодарю. Т.е. получается этакий линтер по типам и самим параметрам + возможность отслеживать, не нраушится ли флоу вследствии изменений структуры БД? Вот это инетресно, да.
Вопрос немного из другого разреза разработки - а зачем вообще пытаться что-то рефлектить "из SQL", или "из языка"?
В чем проблема использовать БД как фронт использует бэк, делая запросы к хранимкам (если уж там есть сложная логика)? В таком случае при миграциях приложение вообще трогать не нужно будет, если старый вид данных, конечно, можно как-то получить. Достаточно изменить хранимку в БД - т.е. при bзменении БД вы остаетесь в парадигме лишь этой БД.
Что касается тестов - естественно, они внешние должны быть, тут ничего не сделать, но эндпоинты на хранимках избавляют от необходимости переделывать те тесты, которые уже были для них написаны, и нужно просто написать тесты только для нового или изменившегося функционала.
Вообще, использовать рефлекты при работы с БД - это очень заманчивая, но очень порочная практика, как и ORM, ИМХО. Это ускоряет старт, но жутко мешает потом в жизненном цикле. Обычные запросы и более понятны (не надо гадать, во что они там трансформируются промежуточным слоем) и легче могут быть оптимизированы или вообще заменены. Единственная проблема - смена БД. Но это крайне редкая проблема, можно сделать миграцию и ручками раз в 10 лет.
Вы реально думаете, что сравнивать сколько потребляется памяти в нэтиве DOM элементов и js объекты, которые потом плюсом рендерится в элементы DOM - это действительно корректно? Особенно если учитывать нагрузку на CPU при этом.
Ваша фраза звучит примерно так "CSS проигрывает FastApi", ага.
Любой инструмент работает в контексте, так вот, если без фреймворка и нативно, без сборщиков и тд требуется нарисовать "красивый и удобный интерфейс", то у веб-компонент просто не существует конкурентов.
И рассматривать их надо не как конкурентов фреймоворков, а как дополнительная киллер-фича, которую можно использовать совместно, это же касается и shadow DOM.
mol, если его сделать честным, а не как делает автор, например исключая оффскрин ноды и сравнивая с либами где они честно присутствуют ни какими плюсами по скорости обладать не будет, а с таким самодуром во главе - и подавно.
Делается очень просто, если компонент нормально отправляет события, и чуть сложнее, если нет.
Именно потому, что ты вообще не понимаешь и не принимаешь ничего кроме своего, ты и не можешь разобраться, как работать с веб-компонентами. Тебе куча народа это уже говорила, но, как говорится - "а еслим читан, то не понят, а если понят - то не так".
@nin-jin - это нездоровый автор поделия под названием mol и всей его экосистемы, не умеющий ни общаться, ни принимать каую-либо критику, а @cmyser очень похож на его альтер-эго.
@Synopticum раньше не встречал, но судя по его ответам, пахнет точно такойже cat-piss - либо тотже лагерь, либо альтер-эго.
Не прошу с этим ничего делать.
А вот я, наборот, прошу @Exosphere что-нибудь с этим сделать, ибо эти персонажи реально достали, как и весь их братвополь.
Что до веб-компонент - это лучшее и реально полезное, что случалось с вебом за последнее время.
Реальные аргументы про что? Про то, что в статье абсолютно надуманная дичь типа впихивания JSON в атрибуты? Для этого какие-то аргументы нужны, серьезно?
Что значит поддерживается руками? Это можно сделать автоматизировано без каких-либо проблем, в том числе и при сборке.
Можете даже свой кастомный префикс впихнуть в библиотеку, если необходимо и библиотека грамотно написана.
Внезапно использование внутри одного скопа одинаковых наименований приводит к конфликту наименований - как так?! Никогда такого ведь не было, и вот опять!
А если серьезно - а как должно было-бы быть? Браузер должен разруливать нейминг за программиста? )
Ну те придумали как всегда сферическую проблему и донкихотите?)
Зачем JSON хранить в атрибуте? Вас кто-то заставляет?
Чтобы не было конфликтов, достаточно, чтобы у тэгов был свой префикс для каждого модуля - и это нормально.
Ну и да, естественно, когда вы делаете дичь, ее трудно делать - и это тоже вполне нормально.
Веб-компоненты - это одно из самых ожидаемых и удачных нововведений (особенно с возможностью изоляции через shadowdom) в браузерах, и да, если пытаться не понимать их, и тыкать каменным топором, как вы привыкли - будет больно.
Я рассмотрел далеко не все проблемы веб-компонент
Вы рассмотрели лишь свое непонимание и старые подходы к новой технологии - не надо пинять на технологию, если руки кривые.
Просто ИМХО заголовок "Делаем" означает что это не первая поставка ) Ну и если вы только отправили первую партию - у вас пока прототип, ибо робот для произодства, без обкатки на этом самом производстве, это, извините, прототип и ничего более - до реального робота ему еще как до луны пешком.
Окей, что насчет сравнения с мировыми брэндами? В чем лучше? В чем хуже? В чем преимущества? Насколько сопоставима математика? Стоимость для примерно одинаковых по спекам устройств?
Тут ведь тех. ресурс, уж извините - джинсу тут не любят, для этого есть другие ресурсы типа VC и тд.
Реальное видео работы вашего манипулятора рядом с реальным станком можно посмотреть (туже загрузку болванки)? Того же M13? Ибо на сайте я вижу только 3D-рендеры и все.
На какиех предприятиях внедрено? Как в плане конкуренции с FANUC / ABB / Kuka?
Пока у меня впечатление, что у вас что-то возможно есть, возможно как-то связано с роботами, но по тому что я вижу - только на бумаге, либо 1 тестовый образец.
Приведите пример такой транзакции, чтобы понять точно о чем разговор.
Так как обычно данные описаны именно на уровне данных и бизнеса, и они просто протягиваются через слои, которые с ними работают. От языка там только названия, никакой доп. сложности ни инструменты, ни слои к данным не добавляют. К общей архитектуре - да, ибо каждый слой - это отдельный сервис.
Т.е. грубо говоря как у вас есть сейчас, и к чему вы хотите прийти на примере. После этого можно будет поговорить предметно.
Дело не в языке, а в сложности того, что им описывают, а язык вообще можно хоть какой использовать, если верно сложность понять - хоть на 1C писать, хоть на асме.
Зоопарк протоклов не от того, что там матрешка, а от того что данные, которые пытются формализовать очень сложные + ограничение каналов связи + ограничение клиентов - оттуда и вложенность и указание только нужных полей и тд.
Вы гуманитарий? - ибо очень похоже - им постоянно такие идеи приходят в голову, но они, к сожалению, не более чем от не понимания того, что происходит и как это работает.
Под рефлектами я имел ввиду отражение кого-либо экземпляра класса (его данных) в/из БД.
Да, сейчас стало понятней, что имелось ввиду, благодарю. Т.е. получается этакий линтер по типам и самим параметрам + возможность отслеживать, не нраушится ли флоу вследствии изменений структуры БД? Вот это инетресно, да.
Вопрос немного из другого разреза разработки - а зачем вообще пытаться что-то рефлектить "из SQL", или "из языка"?
В чем проблема использовать БД как фронт использует бэк, делая запросы к хранимкам (если уж там есть сложная логика)? В таком случае при миграциях приложение вообще трогать не нужно будет, если старый вид данных, конечно, можно как-то получить. Достаточно изменить хранимку в БД - т.е. при bзменении БД вы остаетесь в парадигме лишь этой БД.
Что касается тестов - естественно, они внешние должны быть, тут ничего не сделать, но эндпоинты на хранимках избавляют от необходимости переделывать те тесты, которые уже были для них написаны, и нужно просто написать тесты только для нового или изменившегося функционала.
Вообще, использовать рефлекты при работы с БД - это очень заманчивая, но очень порочная практика, как и ORM, ИМХО. Это ускоряет старт, но жутко мешает потом в жизненном цикле. Обычные запросы и более понятны (не надо гадать, во что они там трансформируются промежуточным слоем) и легче могут быть оптимизированы или вообще заменены. Единственная проблема - смена БД. Но это крайне редкая проблема, можно сделать миграцию и ручками раз в 10 лет.
Ну, либо я не понял сути вопроса.
Вы реально думаете, что сравнивать сколько потребляется памяти в нэтиве DOM элементов и js объекты, которые потом плюсом рендерится в элементы DOM - это действительно корректно? Особенно если учитывать нагрузку на CPU при этом.
Если да - у меня больше вопросов нет)
Кому они проигрывают? Что опять за чушь?!
Ваша фраза звучит примерно так "CSS проигрывает FastApi", ага.
Любой инструмент работает в контексте, так вот, если без фреймворка и нативно, без сборщиков и тд требуется нарисовать "красивый и удобный интерфейс", то у веб-компонент просто не существует конкурентов.
И рассматривать их надо не как конкурентов фреймоворков, а как дополнительная киллер-фича, которую можно использовать совместно, это же касается и shadow DOM.
Критику он не принимает, для него есть только его поделие и все, остальные, кто не с ним - идиоты - это не признак здоровости.
Кроме этого он не гнушается манипуляциями и переходами на личности, что тоже не признак ума или чего-то ещё.
Чтобы не быть голословным, вот последняя его статья, где все отлично видно, особенно в комментах https://habr.com/ru/articles/1014708/
mol, если его сделать честным, а не как делает автор, например исключая оффскрин ноды и сравнивая с либами где они честно присутствуют ни какими плюсами по скорости обладать не будет, а с таким самодуром во главе - и подавно.
Делается очень просто, если компонент нормально отправляет события, и чуть сложнее, если нет.
Именно потому, что ты вообще не понимаешь и не принимаешь ничего кроме своего, ты и не можешь разобраться, как работать с веб-компонентами. Тебе куча народа это уже говорила, но, как говорится - "а еслим читан, то не понят, а если понят - то не так".
@nin-jin - это нездоровый автор поделия под названием mol и всей его экосистемы, не умеющий ни общаться, ни принимать каую-либо критику, а @cmyser очень похож на его альтер-эго.
@Synopticum раньше не встречал, но судя по его ответам, пахнет точно такойже cat-piss - либо тотже лагерь, либо альтер-эго.
А вот я, наборот, прошу @Exosphere что-нибудь с этим сделать, ибо эти персонажи реально достали, как и весь их братвополь.
Что до веб-компонент - это лучшее и реально полезное, что случалось с вебом за последнее время.
Реальные аргументы про что? Про то, что в статье абсолютно надуманная дичь типа впихивания JSON в атрибуты? Для этого какие-то аргументы нужны, серьезно?
Что значит поддерживается руками? Это можно сделать автоматизировано без каких-либо проблем, в том числе и при сборке.
Можете даже свой кастомный префикс впихнуть в библиотеку, если необходимо и библиотека грамотно написана.
Внезапно использование внутри одного скопа одинаковых наименований приводит к конфликту наименований - как так?! Никогда такого ведь не было, и вот опять!
А если серьезно - а как должно было-бы быть? Браузер должен разруливать нейминг за программиста? )
Ну те придумали как всегда сферическую проблему и донкихотите?)
Зачем JSON хранить в атрибуте? Вас кто-то заставляет?
Чтобы не было конфликтов, достаточно, чтобы у тэгов был свой префикс для каждого модуля - и это нормально.
Ну и да, естественно, когда вы делаете дичь, ее трудно делать - и это тоже вполне нормально.
Веб-компоненты - это одно из самых ожидаемых и удачных нововведений (особенно с возможностью изоляции через shadowdom) в браузерах, и да, если пытаться не понимать их, и тыкать каменным топором, как вы привыкли - будет больно.
Вы рассмотрели лишь свое непонимание и старые подходы к новой технологии - не надо пинять на технологию, если руки кривые.
А разве кто-то не понимал сразу, что это помойка?
Вопрос лишь в ударении )
Именно так + вводить этаж до посадки это разрыв шаблона.
В час пик наблюдаешь людей "А мы уже 10 могут ждём лифт С"...
Вот это уже по делу, ИМХО, с этого и надо было статью начинать. Благодарю.
Просто ИМХО заголовок "Делаем" означает что это не первая поставка )
Ну и если вы только отправили первую партию - у вас пока прототип, ибо робот для произодства, без обкатки на этом самом производстве, это, извините, прототип и ничего более - до реального робота ему еще как до луны пешком.
Окей, что насчет сравнения с мировыми брэндами? В чем лучше? В чем хуже? В чем преимущества? Насколько сопоставима математика? Стоимость для примерно одинаковых по спекам устройств?
Тут ведь тех. ресурс, уж извините - джинсу тут не любят, для этого есть другие ресурсы типа VC и тд.
Начиналось с прикольной невозможной фигуры, а кончилось все безликой п..й, простите.
Ну и конечно, новое лого и слоган - это главное для облака, от щас заживем!
Реальное видео работы вашего манипулятора рядом с реальным станком можно посмотреть (туже загрузку болванки)? Того же M13? Ибо на сайте я вижу только 3D-рендеры и все.
На какиех предприятиях внедрено? Как в плане конкуренции с FANUC / ABB / Kuka?
Пока у меня впечатление, что у вас что-то возможно есть, возможно как-то связано с роботами, но по тому что я вижу - только на бумаге, либо 1 тестовый образец.
Биографию Альтушки прочтите - и все встанет на свои места )
Божечки! Вот код для любого устройства с микрофоном)
Приведите пример такой транзакции, чтобы понять точно о чем разговор.
Так как обычно данные описаны именно на уровне данных и бизнеса, и они просто протягиваются через слои, которые с ними работают. От языка там только названия, никакой доп. сложности ни инструменты, ни слои к данным не добавляют. К общей архитектуре - да, ибо каждый слой - это отдельный сервис.
Т.е. грубо говоря как у вас есть сейчас, и к чему вы хотите прийти на примере.
После этого можно будет поговорить предметно.
да, да, никогда такого не было и вот опять )))
Дело не в языке, а в сложности того, что им описывают, а язык вообще можно хоть какой использовать, если верно сложность понять - хоть на 1C писать, хоть на асме.
Зоопарк протоклов не от того, что там матрешка, а от того что данные, которые пытются формализовать очень сложные + ограничение каналов связи + ограничение клиентов - оттуда и вложенность и указание только нужных полей и тд.
Вы гуманитарий? - ибо очень похоже - им постоянно такие идеи приходят в голову, но они, к сожалению, не более чем от не понимания того, что происходит и как это работает.