Pull to refresh
3

User

Send message

Любой человек. Называется "человеческий фактор".

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

Ну вообще до дебильных и бесполезных webextensions было ещё два варианта работы с расширениями, один «классический но с многопоточностью и без xul», который был ничем особо не хуже старого — все потроха были доступны, для многопоточности — апи, и один через спец sdk(этот не успел попробовать). И только потом решили на мороз выкинуть основную свою фичу.
Конкретно с gmail проще добавить точку в произвольном месте, он их фильтрует: mymail@gmail.com === my.mail@gmail.com; и это уже везде будет работать.
Агрессивность нужна. Убирать надо конкретные триггеры.
Нет никакого одного конкретного кошелька с 1kk btc. Есть первый известный, на котором на данный момент чуть больше 66 btc и то большей части стараниями любителей писать на исторических памятниках. Сатоши хитрый тип: он для каждого намайненого блока использовал новый адрес. После того как стати майнить другие люди — его кошельки от других отличить особо нельзя. Есть некие технические паттерны по которым эти 1kk и насчитали, но ничего на 100%.
Почему хитрый тип? Всё просто: если б он майнил на один счёт, то как только по такому счёту прошла бы хоть одна транзакция, цена btc бы разом стала равна 0. А так Сатоши может спокойно потихоньку по мере надобности обналичивать свежие счета.)
Осталось написать babel transform который всё это сделает за нас и можно будет спасть спокойно. Не возьмётесь?)
P.S.
array.some(x => Boolean(x))
->
array.some(Boolean)
:)
Не ну директор и владельцы конторы просто отличные парни.

Кто знает. Мб админ ничего никому не сказал про предложение «проклятых вымогателей», просто: «Шеф! Все пропало!». Потом «героически» караулил домен, с каждым днём чувствуя как всё больше начинает пахнуть горелым. Но пронесло. А в конце просто зарегал новые домены на себя «чтоб такого больше не было»(со мной любимым же ничего не может случиться).

На достоверность не претендую, но вариант вполне возможный.)
Они примерно на месяц и зажимают. Если за месяц клиент не проявил активности — смысла держать дольше нет.
Лучше ли? Согласен что от проекта к проекту на Vue встречается всякое самое разное, но, как по мне, работать с этим всё равно стократ приятнее.)

Да и useCallback выкинуть - в ref положить массив\объект и функцию-обёртку сразу же первым ключом.)

В целом да, согласен, конечно. Но это, вполне очевидно, как раз тот самый 1% edge-case, когда надо подумать. Вполне интересная задачка, понятное узкое место, а не скучная рутина.)

"computed от computed за O(1)"

0_o, а это нужно?

Имхо, Vue 2 самое близкое пока, что видел к этому идеалу. (В Vue 3 просрали все полимеры.)

Я мог бы согласиться, но каждый выбор мемоизировать или нет заставляет меня думать: "подгружать" контекст, подгружать особенности, анализировать необходимость, делать выбор. Каждый раз когда я думаю о таких мусорных, не относящихся к конкретной задаче, вещах, я трачу своё время, и, главное, своё "процессорное время". Пускай в каждом конкретном случае это немного, но в целом - это заметно сказывается на продуктивности. Гораздо приятнее или мемоизировать всегда, или "мемоизировать потом", потому что это можно сделать навыком, не требующим мышления.

В целом, я считаю что фреймворк/библиотека должен думать за меня в 99% случаев, оставляя на меня edge-case вещи, действительно требующие осознанного решения. Идиоматичный же реакт заставляет меня либо думать в этих самых 99% случаев, либо забить(тем или иным образом), но чувствовать себя говнокодером(пусть даже и неоправданно).

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

Да, в button onClick мемоизация не нужна, но вот при следующей итерации на месте button окажется CoolButton, где она нужна, но её, по недогляду, не будет.

Так оно сломаное. Пропусти мемоизацию в одном месте и оно водопадом обрушится до самого конца.
Я прекрасно знаю идеологию реакт: «забей на оптимизацию сейчас, оптимизируй узкое место потом».
Проблема в том, что она не работает. Нет никакого узкого места. Каждый компонент в котором забили на оптимизацию — «чуть-чуть» тормозит. Потом они складываются в кучку и получается Patreon.
Тормоза размазаны по всем компонентам и починить можно, только переписав каждый. Ну или переписав «достаточно», чтоб тормозить стало незаметно. До следующего раза.
Во втором случае memo на Container, очевидно, сломается. О чём они, собственно, и толкуют.
По факту в реакте практически невозможно без профилирования сказать полезна ли мемоизация в конкретном случае, т.к. из-за архитектурных особенностей всё зависит по большей части не от человеческой логики, а от глубокой логики js-движка.

В этом вопросе я скорее согласен с этими ребятами Why We Memo All the Things.
Более-менее «защитить» можно элементарно. Запоминать предыдущие точку и время запроса и сравнивать с новой. Если скорость перемещения больше ~250км/ч — клиент на подозрении, если повтор — бан за нарушение условий использования.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity