Pull to refresh
34
ionicman@ionicman

User

11
Subscribers
Send message

Очень наивно полагать, что с выходом нового метода, все кто его реализуют - сразу реализуют все правильно и по стандарту)))

А спустя год уже будет куча легаси, в котором все будет реализовано по новому и не менее криво.

Именно поэтому не надо плодить новые сущностии сверх необходимости, в надежде что "вот с ними то все сразу будет по другому"!

Если "придерживаться RFC", то что мешает реализовать и стандартизировать это для GET с телом? 

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

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

Стандарт всегда лучше хаоса, но не тогда, когда сам стандарт это хаос.

А всего-то нужно было утвердить тело для GET ну и DELETE заодно, которое, внезапно, из RFC и не было никогда запрещено.

Ещё один пример, того, что люди, которые все это придумывают и сидят в различных коммитетах далеки как от программирования, так и от элементарного здравого смысла.

А потом нам с вами с этим мучиться.

P. S. очень смешно читать, что вот дескать POST меняет данные, а GET нет - это всего лишь соглашение, которое ещё и нарушается довольно часто в сложных проектах, а сделать можно как угодно.

А почему в stm32 вдруг стало нельзя по тактам программировать?

Если вы про HAL, то вроде никто не заставляет его использовать.

У меня есть проект на stm32 (не такой как в статье, но все же) в котором именно по тактам один кусок работает без каких-либо проблем, да, во внимание нужно больше принимать, так как проц куда навороченней, но это не проблема.

Дак при такой системной частоте разве это не получится? 44kHz было лишь примером что может слабый проц.

А что, ШИМа у него тоже нет? ))) Если есть - то это и есть DAC. А ШИМ можно еще и через DMA делать, а можно и вообще прерыванием и битбангом, если нет аппартаного.

Недоумеваю - я (и куча других людей) делали воспроизведление WAV ATTINY85, которая 8-битная с 16MHz, и да, она одновременно еще и успевала читать это с SD, а не просто играть, при этом вполне себе на 44kHz.

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

Не смог допройти, хотя брался несколько раз.

Атмосфера реально классная, но игра размазана на огромное пространство плюс очень очень много механик.

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

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

Хуже $mol может быть только само-переведенный $mol)

Причём ещё и прогнанный через LLM, получивший за это кучу эмодзи и абсолютно бесполезный для читателя, ибо все это уже кучу раз опсосано со всех сторон.

Не выдержал Дмитрий, тоже ушёл в нейрослоп.

P. S. Надменный слог автора в купе с абсолютно надуманными примерами даже LLM не смогла погасить)

Под рефлектами я имел ввиду отражение кого-либо экземпляра класса (его данных) в/из БД.

Да, сейчас стало понятней, что имелось ввиду, благодарю. Т.е. получается этакий линтер по типам и самим параметрам + возможность отслеживать, не нраушится ли флоу вследствии изменений структуры БД? Вот это инетресно, да.

Вопрос немного из другого разреза разработки - а зачем вообще пытаться что-то рефлектить "из 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) в браузерах, и да, если пытаться не понимать их, и тыкать каменным топором, как вы привыкли - будет больно.

Я рассмотрел далеко не все проблемы веб-компонент

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

А разве кто-то не понимал сразу, что это помойка?

1
23 ...

Information

Rating
6,289-th
Registered
Activity