какая ужасная логика) ничто не растёт бесконечно, тем более без объективных на то причин. а здесь ещё и ценность самого ограниченного "ресурса" сомнительная - от любой другой крипы по скорости транзакций/стоимости комиссий биткоин кратно отстаёт, а ничего нового не предложил за все эти годы. т.е. всё то, что может делать биткоин, могут делать другие монеты, но ничего из того, что сверх этого могут делать другие монеты, биткоин делать не может. одна лишь ограниченная эмиссия никак не повод для бесконечного роста стоимости, если сама монета толком нигде не применяется.
циклы роста, о которых пишут выше, буквально отражают пик/спад интереса криптосообщества/инвесторов к биткоину, которые с свою очередь происходили по каким-то внешним причинам - ковид, Трамп подписал указ о создании крипторезерва, проще говоря какой-то хайп или наоборот, негативная обстановка. сам биткоин и его ограниченное конечное количество к этому отношения не имеют в принципе, это всего лишь человеческий фактор + прочие штуки типа "эффекта толпы", "синдрома упущенной выгоды", не более.
при этом я не говорю, что биткоин точно рухнет. вообще не обязательно. если богатые мира сего решат, что биткоину стоит расти - то конечно будет рост)
Утверждая ты же "в короткую" их продал ? На какую сумму ? Можно скриншотик ?
Сняли с языка) что толку от таких утверждений, если они не подкреплены сделками. а если не подкреплены, то это и не утверждения вовсе, потому что автор сам в них не верит
и шуточной ответки в виде собственно этого поста, именно вы пригласили автора оригинального поста назад на хабр?) правда ненадолго, там снова read only
какие охотники-собиратели,выживание в джунглях и способы измерения интеллекта - что за пустая графомания. давайте я вам суть материала максимально кратко выжму:
"если самостоятельно не писать код, не размышлять над его логикой - то мозг забудет, как это делается". и вы это простое(очевидно, истинное, как и в отношении любых других не базовых навыков) утверждение пытаетесь сейчас своей графоманией оспорить, верно?
Поддержу, у меня с десяток вопросов на Stack Overflow, большинство из них связаны с библиотекой echarts. Это те случаи, когда не хватает документации либо происходят непонятные баги, которые воспроизводятся только у тебя.
И нейронка в таких случаях не поможет, потому что ей неоткуда брать инфу - будет выдавать нерабочий бред, а потом извиняться. Оставалось только уповать на мудрость прошедших огонь и воду с этой библиотекой разработчиков или ковырять исходники самостоятельно. Так что маня мирок скорее по другую сторону существует)
Я не обязан дать вам готовый код, я всего лишь хочу показать вам такой подход
Удивительно) ещё и подход заточен под конкретную библиотеку react, которая создана для работы с картами - а у этого явно есть своя специфика.
Базовое использование выглядит так:
useEffect(() => {
// проверяем необходимость обновить коллбек
if (tool == "pin" && drawmode) {
// создаем простую функцию как и всегда
let handleClick = (e: MapMouseEvent) => {
//
// логика
//
};
// вешаем ивент
ME.click.pin = (e) => handleClick(e);
return () => {
// удаляем по необходимости
ME.click.pin = (e) => () => {};
};
}
}, [...]);
Выглядит ужасно. То есть каждый раз, когда нужно повесить новый хендлер на onClick по конкретному элементу, мы вместо этого устанавливаем какой-то глобальный onClick, который будет меняться вот так в каждом useEffect?
На самом деле уже давно придумали такую штуку, как делегирование событий. Когда например вместо того, чтобы вешать 10 хендлеров на 10 одинаковых по функционалу дочерних элементов, мы вешаем 1 хендлер на родителя, вытащив id потомка(или что нам нужно для успешной обработки события) через event.target. Вам возможно именно этого и не хватало? В любом случае незнание базы языка вряд ли может привести к каким-то действительно серьёзным открытиям/новым архитектурам. Скорее наоборот, в данном случае второго буквально вытекает из первого, причём вытекает сомнительного качества
интересные вещи происходят в материалах автора: 13 лайков, 1 коммент(не считая моего) за почти сутки, который не представляет из себя ничего осмысленного, зато аж 83 добавления в закладки. и эта динамика просматривается по всем статьям, при том, что технически сложной информации, которая могла бы пригодиться в будущем, нет. т.е. самой цели добавлять такой материал в закладки для последующего "вдруг пригодится" тоже нет.
легко объяснить, зачем например добавлять в закладки мануал по созданию расширения для браузера или симуляции 20 млн частиц в javascript. но зачем кому-то добавлять в закладки пост о том, как работает менторство? 9 лайков и аж в в 5 с лишним раз больше закладок. что, кто-то спустя годы захочет прочесть чьи-то рассуждения на эту тему? не уверен)
разрыв в 2, ну в 3 раза ещё можно объяснить, при том, что у материала есть какая-никакая активность в виде лайков/комментов(действительно интересен пользователям), и само собой имеется какая-то если не уникальная, то хотя бы редко всплывающая, ценная информация, которую захочется где-то сохранить. ничего похожего здесь нет, зато разница между активностью под постами и закладками в 5-7 раз - это пожалуйста) дурно пахнет
В эту игру можно играть в обе стороны) я например могу сказать, что подобному материалу про LLM ставят плюсы те, кто за LLM очевидно топит. потому что это - надежда на беззаботное будущее, в котором наконец-то получится зарабатывать "как айтишники". как не топить-то за такое, если программировать не получается?) на мой взгляд мало похоже на объективную оценку.
придумывать, за что кто-то кому-то ставит плюсы/минусы - так себе идея. вы конечно можете подобным образом отвечать на неудобный аргумент про рейтинг материала, но факт останется фактом. а именно: о стадиях принятия хабровчан речь вести рановато
а вы на основании чего такие выводы сделали? у материала, при достаточно большом количестве комментариев, общий рейтинг вот на данный момент - 0. как-то не похоже, что он отражает мнение большинства хабровчан. или это такое удобное обобщение?
насколько я понимаю, среднему современному городскому жителю, который сколь-либо разнообразно питается и которого устраивает своё состояние здоровья, не нужно чем-либо особенным дополнять свой рацион
тот случай, когда лучше жевать, чем говорить) как вы наберёте необходимое количество всех витаминов и минералов из еды? они же все не лежат в одном месте, а разбросаны по разным источникам питания. в то время как стабильный уровень тех или иных веществ в крови должен быть в норме каждый день. ну то есть не получится в себя запихать столько еды, чтобы получить всё то, что организму нужно/чего не хватает.
а ему жёстко не хватает, как уже писали выше, как минимум витамина Д - "инфа сотка". в вашем же случае наверняка не хватает много чего ещё, раз вы к бадам относитесь как к чему-то бесполезному, и соответственно не употребляете. устанавливается сей факт простейшим походом в ближайшую лабораторию по сдаче крови на анализы, но кто этим будет заниматься, правда же?)
очередные влажные фантазии, поток которых льётся на хабре вот уже много лет. а новое слово "вайбкодинг" вдохнуло в этот поток новую жизнь. суть из раза в раз не меняется - "мы теперь можем сами!".
да, можете(не то чтобы правда прям так уж сами), и как признаётесь в тексте - на уровне прототипа. а дальше-то что? дальше будете звать разработчиков, а разработчики будут писать с нуля, и вы им за это время переписывания с нуля заплатите. потому что за ковыряние в том, что навайбкодил человек, далёкий от программирования, попросят ещё больше. и даже в таком случае ковыряться в этом скорее всего не захотят.
То есть вы от меня требуете рабочего примера широко применяемой технологии(то, что гуглися в два счёта по запросу допустим react-hook-form + yup), но примеры своего полностью рабочего решения, сопоставимого по юзабельности(с переиспользованием и т.д.) писать не хотите, потому что
Неужели нужно не просто короткий пример накидывать для понимания общей концепции, а что-то полностью готовое
именно это я и называю кашей, когда проверки пишутся прямо в сеттере в несколько этажей if. более того - а как это масштабировать? мне в каждой форме, где понадобится что-то проверить, нужно будет в функции setSomething писать этажи проверок? в то время как валидаторы позволяют вместо этой каши использовать
Вынужден снова ссылаться на тот же пример, потому что вы сами пишете "Честно говоря, не понимаю почему и вы, и автор приводите эти примеры". Именно поэтому и привожу, потому что разница гигантская. С одной стороны каша, с другой цепочка методов + переиспользование. Не, если для вас валидация одного поля, которая выглядит так(валидация формы из 10 полей наверное будет с 3 экрана кода в редакторе)
// введенная сумма больше разрешенной
if (evt.target.validity.rangeOverflow) {
this.errors.set('paymentSum', `Не больше ${CARD_MAX_PAYMENT_SUMM}`)
}
// введенная сумма меньше разрешенной
if (evt.target.validity.rangeUnderflow) {
this.errors.set('paymentSum', `Не меньше ${MIN_PAYMENT_SUMM}`)
}
// сумма не введена
if (evt.target.validity.valueMissing) {
this.errors.set('paymentSum', `Введите сумму`)
}
не является проблемой, то дальше разговаривать в общем-то не о чем
затем, что ваш тезис "блокчейн = скам" - ложь. блокчейн - это технология. а скам, ну вы сами знаете) и стоит явно отделять одно от другого. иначе можно кричать что интернет это скам(происходит чаще всего в интернете), деньги это скам(цель собственно скама). звучит как минимум сомнительно, правда?
ну, я пытался) вы буквально написали то же самое, что и я выше
то есть технология-то ни разу не про какой-то скам, но её увы очень просто применять в подобных целях, и вышеупомянутый хомяк - прекрасный пример гадостливого её использования. в целом "игра на блокчейне" зачастую и правда повод задуматься)
вам нужно обычно показать текст ошибки - а что не так заполнено-то. к примеру пароль - это минимум 8 символов, обязательно строчные+заглавные буквы и обязательно цифры. дальше несколько сценариев:
пользователь ввёл меньше 8 символов - показываем красный текст, что символов нужно обязательно 8 или больше.
пользователь ввёл 8 и более символов, но пароль не соответствует требованиям безопасности - показываем красный текст о том, что пароль слабоват
т.е. уже двумя способами нужно валидировать одно поле и показывать разные ошибки в зависимости от ошибок в валидации;
в сложных формах поля бывают взаимосвязаны. допустим если в выпадающем списке по соседству выбрана страна РФ, то ИНН состоит 10 цифр, если же страна другая - то и количество цифр будет другим. представляете, какая каша начнётся, если все эти валидации описывать прямо в хендлерах или в разметке? а завязываться на значение соседнего поля - где его хранить в таком случае?
Валидаторы(я использую yup в связке с react-hook-form) позволяют в одном месте и указать нужный текст ошибки на каждую проверку
string()
.required('Введите ссылку')
.url('Неправильный формат ссылки')
.matches(/^https:\/\/vk.com\/(.*)/, 'Ссылка должна содержать https://vk.com/')
// настойчиво просим ссылку на профиль vk
Здесь проверяется, что оплата производится с карты, и в таком случае происходит проверка на максимальную сумму. если же выбрана оплата с банковского счёта, то вернётся true, т.е. тест выполнится сразу с положительным результатом. ещё при изменении paymentType.value можно было подменить схему, убрав из неё вызов test в принципе.
Как всё это будет выглядеть без валидаторов - страшно подумать
"Идея беззаботного вайба" - как же классно звучит! и не надо признаваться себе в том, что ты по каким-то причинам не можешь освоить программирование. ты просто идейный, ну)
какая ужасная логика) ничто не растёт бесконечно, тем более без объективных на то причин. а здесь ещё и ценность самого ограниченного "ресурса" сомнительная - от любой другой крипы по скорости транзакций/стоимости комиссий биткоин кратно отстаёт, а ничего нового не предложил за все эти годы. т.е. всё то, что может делать биткоин, могут делать другие монеты, но ничего из того, что сверх этого могут делать другие монеты, биткоин делать не может. одна лишь ограниченная эмиссия никак не повод для бесконечного роста стоимости, если сама монета толком нигде не применяется.
циклы роста, о которых пишут выше, буквально отражают пик/спад интереса криптосообщества/инвесторов к биткоину, которые с свою очередь происходили по каким-то внешним причинам - ковид, Трамп подписал указ о создании крипторезерва, проще говоря какой-то хайп или наоборот, негативная обстановка. сам биткоин и его ограниченное конечное количество к этому отношения не имеют в принципе, это всего лишь человеческий фактор + прочие штуки типа "эффекта толпы", "синдрома упущенной выгоды", не более.
при этом я не говорю, что биткоин точно рухнет. вообще не обязательно. если богатые мира сего решат, что биткоину стоит расти - то конечно будет рост)
Сняли с языка) что толку от таких утверждений, если они не подкреплены сделками. а если не подкреплены, то это и не утверждения вовсе, потому что автор сам в них не верит
а как так вышло, что после вашего коммента
и шуточной ответки в виде собственно этого поста, именно вы пригласили автора оригинального поста назад на хабр?) правда ненадолго, там снова read only
какие охотники-собиратели,выживание в джунглях и способы измерения интеллекта - что за пустая графомания. давайте я вам суть материала максимально кратко выжму:
"если самостоятельно не писать код, не размышлять над его логикой - то мозг забудет, как это делается". и вы это простое(очевидно, истинное, как и в отношении любых других не базовых навыков) утверждение пытаетесь сейчас своей графоманией оспорить, верно?
Поддержу, у меня с десяток вопросов на Stack Overflow, большинство из них связаны с библиотекой echarts. Это те случаи, когда не хватает документации либо происходят непонятные баги, которые воспроизводятся только у тебя.
И нейронка в таких случаях не поможет, потому что ей неоткуда брать инфу - будет выдавать нерабочий бред, а потом извиняться. Оставалось только уповать на мудрость прошедших огонь и воду с этой библиотекой разработчиков или ковырять исходники самостоятельно. Так что маня мирок скорее по другую сторону существует)
Тот случай, когда качество постера напрямую отражает качество материала
Зато придумал новую архитектуру ивентов. Но
Удивительно) ещё и подход заточен под конкретную библиотеку react, которая создана для работы с картами - а у этого явно есть своя специфика.
Выглядит ужасно. То есть каждый раз, когда нужно повесить новый хендлер на onClick по конкретному элементу, мы вместо этого устанавливаем какой-то глобальный onClick, который будет меняться вот так в каждом useEffect?
На самом деле уже давно придумали такую штуку, как делегирование событий. Когда например вместо того, чтобы вешать 10 хендлеров на 10 одинаковых по функционалу дочерних элементов, мы вешаем 1 хендлер на родителя, вытащив id потомка(или что нам нужно для успешной обработки события) через event.target. Вам возможно именно этого и не хватало? В любом случае незнание базы языка вряд ли может привести к каким-то действительно серьёзным открытиям/новым архитектурам. Скорее наоборот, в данном случае второго буквально вытекает из первого, причём вытекает сомнительного качества
интересные вещи происходят в материалах автора: 13 лайков, 1 коммент(не считая моего) за почти сутки, который не представляет из себя ничего осмысленного, зато аж 83 добавления в закладки. и эта динамика просматривается по всем статьям, при том, что технически сложной информации, которая могла бы пригодиться в будущем, нет. т.е. самой цели добавлять такой материал в закладки для последующего "вдруг пригодится" тоже нет.
легко объяснить, зачем например добавлять в закладки мануал по созданию расширения для браузера или симуляции 20 млн частиц в javascript. но зачем кому-то добавлять в закладки пост о том, как работает менторство? 9 лайков и аж в в 5 с лишним раз больше закладок. что, кто-то спустя годы захочет прочесть чьи-то рассуждения на эту тему? не уверен)
разрыв в 2, ну в 3 раза ещё можно объяснить, при том, что у материала есть какая-никакая активность в виде лайков/комментов(действительно интересен пользователям), и само собой имеется какая-то если не уникальная, то хотя бы редко всплывающая, ценная информация, которую захочется где-то сохранить. ничего похожего здесь нет, зато разница между активностью под постами и закладками в 5-7 раз - это пожалуйста) дурно пахнет
Возможно потестим с командой плагины, спасибо за материал)
В эту игру можно играть в обе стороны) я например могу сказать, что подобному материалу про LLM ставят плюсы те, кто за LLM очевидно топит. потому что это - надежда на беззаботное будущее, в котором наконец-то получится зарабатывать "как айтишники". как не топить-то за такое, если программировать не получается?) на мой взгляд мало похоже на объективную оценку.
придумывать, за что кто-то кому-то ставит плюсы/минусы - так себе идея. вы конечно можете подобным образом отвечать на неудобный аргумент про рейтинг материала, но факт останется фактом. а именно: о стадиях принятия хабровчан речь вести рановато
а вы на основании чего такие выводы сделали? у материала, при достаточно большом количестве комментариев, общий рейтинг вот на данный момент - 0. как-то не похоже, что он отражает мнение большинства хабровчан. или это такое удобное обобщение?
тот случай, когда лучше жевать, чем говорить) как вы наберёте необходимое количество всех витаминов и минералов из еды? они же все не лежат в одном месте, а разбросаны по разным источникам питания. в то время как стабильный уровень тех или иных веществ в крови должен быть в норме каждый день. ну то есть не получится в себя запихать столько еды, чтобы получить всё то, что организму нужно/чего не хватает.
а ему жёстко не хватает, как уже писали выше, как минимум витамина Д - "инфа сотка". в вашем же случае наверняка не хватает много чего ещё, раз вы к бадам относитесь как к чему-то бесполезному, и соответственно не употребляете. устанавливается сей факт простейшим походом в ближайшую лабораторию по сдаче крови на анализы, но кто этим будет заниматься, правда же?)
очередные влажные фантазии, поток которых льётся на хабре вот уже много лет. а новое слово "вайбкодинг" вдохнуло в этот поток новую жизнь. суть из раза в раз не меняется - "мы теперь можем сами!".
да, можете(не то чтобы правда прям так уж сами), и как признаётесь в тексте - на уровне прототипа. а дальше-то что? дальше будете звать разработчиков, а разработчики будут писать с нуля, и вы им за это время переписывания с нуля заплатите. потому что за ковыряние в том, что навайбкодил человек, далёкий от программирования, попросят ещё больше. и даже в таком случае ковыряться в этом скорее всего не захотят.
То есть вы от меня требуете рабочего примера широко применяемой технологии(то, что гуглися в два счёта по запросу допустим react-hook-form + yup), но примеры своего полностью рабочего решения, сопоставимого по юзабельности(с переиспользованием и т.д.) писать не хотите, потому что
иронично. полагаю, что "это другое")
именно это я и называю кашей, когда проверки пишутся прямо в сеттере в несколько этажей if. более того - а как это масштабировать? мне в каждой форме, где понадобится что-то проверить, нужно будет в функции setSomething писать этажи проверок? в то время как валидаторы позволяют вместо этой каши использовать
Вынужден снова ссылаться на тот же пример, потому что вы сами пишете "Честно говоря, не понимаю почему и вы, и автор приводите эти примеры". Именно поэтому и привожу, потому что разница гигантская. С одной стороны каша, с другой цепочка методов + переиспользование. Не, если для вас валидация одного поля, которая выглядит так(валидация формы из 10 полей наверное будет с 3 экрана кода в редакторе)
не является проблемой, то дальше разговаривать в общем-то не о чем
затем, что ваш тезис "блокчейн = скам" - ложь. блокчейн - это технология. а скам, ну вы сами знаете) и стоит явно отделять одно от другого. иначе можно кричать что интернет это скам(происходит чаще всего в интернете), деньги это скам(цель собственно скама). звучит как минимум сомнительно, правда?
ну, я пытался) вы буквально написали то же самое, что и я выше
вам нужно обычно показать текст ошибки - а что не так заполнено-то. к примеру пароль - это минимум 8 символов, обязательно строчные+заглавные буквы и обязательно цифры. дальше несколько сценариев:
пользователь ввёл меньше 8 символов - показываем красный текст, что символов нужно обязательно 8 или больше.
пользователь ввёл 8 и более символов, но пароль не соответствует требованиям безопасности - показываем красный текст о том, что пароль слабоват
т.е. уже двумя способами нужно валидировать одно поле и показывать разные ошибки в зависимости от ошибок в валидации;
в сложных формах поля бывают взаимосвязаны. допустим если в выпадающем списке по соседству выбрана страна РФ, то ИНН состоит 10 цифр, если же страна другая - то и количество цифр будет другим. представляете, какая каша начнётся, если все эти валидации описывать прямо в хендлерах или в разметке? а завязываться на значение соседнего поля - где его хранить в таком случае?
Валидаторы(я использую yup в связке с react-hook-form) позволяют в одном месте и указать нужный текст ошибки на каждую проверку
И иметь доступ контексту, а именно
Здесь проверяется, что оплата производится с карты, и в таком случае
происходит проверка на максимальную сумму. если же выбрана оплата с банковского счёта, то вернётся true, т.е. тест выполнится сразу с положительным результатом. ещё при изменении paymentType.value можно было подменить схему, убрав из неё вызов test в принципе.
Как всё это будет выглядеть без валидаторов - страшно подумать
То, что вы такой не один, не говорит о том, что есть какие-то сложности или проблемы) потому что дофига у кого их не возникло
"Идея беззаботного вайба" - как же классно звучит! и не надо признаваться себе в том, что ты по каким-то причинам не можешь освоить программирование. ты просто идейный, ну)