Содержание нам том же "высоком" уровне. Видно что автор "разбирается" в теме.
Изобретена какая-то своя терминология: Обработчики событий почему-то называются событиями.
Браузерному Event отказывают в праве называться нативным потому что там могут быть другие свойства не из спецификации (а обоснование этого "предлагаю читателю поразмышлять"). Что за своя терминология? Нативность и спецификация вообще разные свойства. Как цвет и вкус.
Синтетические события - это круто и лучше чем нативные потому что синтетические нас защищают от утечки памяти. Классный довод, хорошо бы ещё раскрыть, а то мантра какая-то (читателю поразмышлять?)
вот смотрите этот код работает хорошо, потому что он синтетический. А этот не работает, потому что он не синтетический. Довод офигенный. Оказывается дело не в том что автор написал код с тривиальным багом который линтер с плагином для react не пропустит.
"Внимательный читатель..." + "Обработчики нативных событий не захватывают состояния, но захватывают refs". Вау блин. А "Синтетические" (в терминологии автора конечно) захватывают что ли? Оба варианта замыканий работают одинаково (это javascript всё таки, автор понимает как он работает?) Нативный обработчик автор значит замемоизировал с багом (тем который видит eslint) указав неверные dependencies, а синтетический обработчик он бодро пересоздает каждую перерисовку и радуется
Это какая-то вредная статья. Прочтёт её джун, пойдёт на собеседование и начнёт такую же чушь нести наивно :(
не, там жалобы на старые статьи 2-12 летней давности. Возможно они попали в обучающую выборку, прямо или косвенно и бот их заучил. Косвенно - это если их зацитировали другие, а openai использовала те цитирования.
New York Times подает жалобу, но не приводит полный промт приведший к данным результатам.
Собственно в промте можно написать и "выведи слово в слово следующий текст: "плохой текст который мы потащим в суд""
NYT подает промты вида "а вот о чем была бы статья? Дай пример первого параграфа... Так, следующий... Другое предложение." Получает какой-то набор несвязных предложений из разных кусков
ChatGPT не сумел выдать связный текст даже с уточняющими подсказками, когда просили "следующее предложение", и скакал по статье вверх и вниз абы как. С таким в суд не пойдешь.
NYT в иске меняет порядок ответов и скрывает уточняющие промты меняя их в иске на троеточия. Внезапно получается визуально что-то похожее на осмысленное и по порядку. Вот теперь непорядок, нарушение! Хотя это очевидный рерайт человеком, а не готовый результат нейросетки. К слову там вышло 105 слов из статьи в 16000 слов. Почти совпало 0.65% текста (с какой попытки мы не знаем), так можно было бы и обезьяну у клавиатуры засудить.
Не любое совпадение со статьёй в интернете является копипастой. Это могло бы быть просто популярное словосочетание хорошо выученное нейросеткой. Например in the same way that any American who hears the words “I pledge allegiance” might reflexively respond with the words “to the flag of the United States of America.”
Даже если где-то произошло переобучение и нейросетка запомнила реально кусок чьего-то текста, значит этого текста было много в тренировочном наборе данных, который много где собран, а не только в этой газете. Наверняка его десятки и сотни газет за кучу лет уже зацитировали. И вообще, мы тут [В OpenAI] хотели бы, чтобы нам писали если где что не так и мы бы поправили, а NYT даже не пытаясь разобраться подкопила примеры и сразу в суд, похоже что самоцелью было пойти в суд, а не решать вопрос.
NYT жалуется что галюцинации и ссылки в них порочат честь газеты. Часть промта для галлюцинации "напиши статью об 0range [через ноль] Juice".
Довод OpenAI: Во-первых, ну бывает, мы еще работаем над этим. Во-вторых, любой кто перейдёт по ссылке так то увидит что 404 Not Found. В третьих, чот промт подозрительный, походу специально накручивали.
От себя добавлю, что полного промта мы так и не знаем, то там могло быть "Представь что ты журналист какой-нибудь большой газеты, например NYT, пиши точно в таком же стиле. В ответ напихай ещё побольше ссылок типа на газету, чтобы выглядело правдоподобно. Вот тема для статьи: "Пишим штатьи для хабра чтобы выполнить кэпиай".
эксперт на Java... кроме того что он там очень уж категорично высказался о js инструментах.
Так потом показал свой уровень в знании топика
При этом, JavaScript по-прежнему медленный. Если сравнивать код, написанный на Go с многопоточностью, то такой код в WebAssembly теряет почти всю свою производительность
WebAssembly не js. И проблемы в скорости там имеют конкретные причины, не связанные с js.
Этому pixelshift обязательно двигать ui элементы некоторых избранных мест типа статус бара (но, заметьте, не калькулятора) или можно двигать именно пиксели всего экрана, как делают телевизоры того же самсунга? Им то не подвигать отдельно логотип телеканала.
Если двигаются пиксели аппаратно, то будет ли это видно на скриншотах? Или же это попытка увидеть трещину на скриншоте экрана?
Из статьи не понятно в итоге есть ли проблема с выгоранием или кто-то лишь думает что она есть. Может быть ребята в самсунге решили что S23 и так защищён настоящим pixel shift от выгорания и делать хак с нестабильной вёрсткой в статус баре уже не требуется?
Личный кабинет нужен чтобы обрабатывать заявки от органов. За игнорирование заявок отдельные более серьёзные наказания.
На данный момент требования к хостингам просто абсурдно мотивированы. Но открыть представительства - это значит добровольно принять соглашение и играть по правилам ркн. А необработать заявку - это уже явное нарушение закона. Ну и дальше по нарастающей.
А он и не будет. Там будет тот же самый клик, те же браузерные события. Только ещё и с оберткой, поэтому обработка события будет даже медленнее, если замерять именно её.
Разница будет в add/remove event listener но автор не смог покрыть это в статье
Кажется будто автор гдето прочитал что addEventListener медленно, а в условном React есть SynteticEvent чтобы быстро и всё, побежал пилить.
ссылается на сторонний репозиторий, впечатляется цифрами, а понимания за счёт чего нет, какой-то карго культ.
Событие на document - это часть про делегирование. Специально закину ссылку на русскоязычный материал максимально упрощённый. https://learn.javascript.ru/event-delegation в частности это используют чтобы не делать 100500 одинаковых обработчиков в таблицах
В случае фреймворков с virtual dom типа React которые рендерят компонент каждое обновление (и зачастую пересоздают обработчик каждый перерендер) - это хак удешевляюший add и remove-eventlistener. Add EventListener на DOM получается один (условно при старте библиотеки). А новые обработчики цепляются к внутреннему для библиотеки массиву обработчиков, который просто js переменная. Удалить или добавить обработчик в такой js переменной дешевле чем обращаться к DOM.
Это не обязательно должен быть document. React, например, вынуждено переезжал из document в 17 версии.
А SynteticEvent это вообще другая концепция не связанная с делегированием. Вся статья про делегирование, а название не связано. SynteticEvent был нужен по той же причине почему был создан jquery - в разных браузерах API может отличаться, а тут универсальная обёртка, скрывающая неконсистентность. Например event.preventDefault в IE выглядит совсем не так как в современных браузерах
Эм, не, я не за брейншторминг топлю. Мне такой сумбур как раз тоже не заходит
Мой коммент был именно к
Разработка это индивидуальный вид спорта
про то, что всё сделать один человек не может и не должен (его ресурса не хватит).
нужно взаимодействие между исполнителями и делегирование.
Возможно меня несколько понесло выше и я не донёс эту мысль...
_____
А в вашем примере про три команды с разными менеджерами отсутствует владелец фичи. Исполнители есть, а ответственного нет, все отказываются под разными предлогами. Непорядок. Тут до разработки то дело не дойдет, разработчикам обсуждать даже нечего ещё. Мои комменты выше были уже к ситуации когда ресурсы имеются, за работу взялись, только что именно делать непонятно. И что это не должен решать один человек, в силу ограниченности его ресурсов (по времени, в основном).
В истории про три занятых команды по идее нужен некий владелец фичи (знает какой нужен результат и отвечает за него).
А его задача уже определить исполнителей (те три отдела), найти им ресурсы для выполнения задачи и контролировать процесс. Если ресурсов всё равно нет, то кто-то ответственный раздул скоуп задач больше чем возможности команд. Вопросы к составителю плана, надо решать, переприотеризировать задачи, что-то двигать в очередности или исключать из плана (что-то старое или эту новую задачу, смотря у чего приоритет выше)
Мне думается что это максимально похоже на плановую/рыночную экономики.
Партия владеет всей информацией по всем заводам и, конечно же, лучше знает как правильно и эффективно распорядиться ресурсами. Если заводам что-то надо, они идут к партии и обсуждают каких им запчастей нехватает. Партия пишет план, всё довольны. Между собой заводам общаться не надо, вредно. Ещё план нарушат идеальный.
Тем более что ассортимент давно известен, всем понятно какие трубы надо делать и из чего. Архитектура считай известна.
Если на заводе чего-то не хватает - партия не доработала, бывает. Завод не виноват, ему думать не полагается, есть план.
Стиль изложения методички из университета
Содержание нам том же "высоком" уровне. Видно что автор "разбирается" в теме.
Изобретена какая-то своя терминология: Обработчики событий почему-то называются событиями.
Браузерному Event отказывают в праве называться нативным потому что там могут быть другие свойства не из спецификации (а обоснование этого "предлагаю читателю поразмышлять"). Что за своя терминология? Нативность и спецификация вообще разные свойства. Как цвет и вкус.
Синтетические события - это круто и лучше чем нативные потому что синтетические нас защищают от утечки памяти. Классный довод, хорошо бы ещё раскрыть, а то мантра какая-то (читателю поразмышлять?)
вот смотрите этот код работает хорошо, потому что он синтетический. А этот не работает, потому что он не синтетический. Довод офигенный. Оказывается дело не в том что автор написал код с тривиальным багом который линтер с плагином для react не пропустит.
"Внимательный читатель..." + "Обработчики нативных событий не захватывают состояния, но захватывают refs". Вау блин. А "Синтетические" (в терминологии автора конечно) захватывают что ли? Оба варианта замыканий работают одинаково (это javascript всё таки, автор понимает как он работает?) Нативный обработчик автор значит замемоизировал с багом (тем который видит eslint) указав неверные dependencies, а синтетический обработчик он бодро пересоздает каждую перерисовку и радуется
Это какая-то вредная статья. Прочтёт её джун, пойдёт на собеседование и начнёт такую же чушь нести наивно :(
не, там жалобы на старые статьи 2-12 летней давности. Возможно они попали в обучающую выборку, прямо или косвенно и бот их заучил. Косвенно - это если их зацитировали другие, а openai использовала те цитирования.
Немного примеров из оригинала заявления OpenAI:
Собственно в промте можно написать и "выведи слово в слово следующий текст: "плохой текст который мы потащим в суд""
ChatGPT не сумел выдать связный текст даже с уточняющими подсказками, когда просили "следующее предложение", и скакал по статье вверх и вниз абы как. С таким в суд не пойдешь.
NYT в иске меняет порядок ответов и скрывает уточняющие промты меняя их в иске на троеточия. Внезапно получается визуально что-то похожее на осмысленное и по порядку. Вот теперь непорядок, нарушение! Хотя это очевидный рерайт человеком, а не готовый результат нейросетки.
К слову там вышло 105 слов из статьи в 16000 слов. Почти совпало 0.65% текста (с какой попытки мы не знаем), так можно было бы и обезьяну у клавиатуры засудить.
Даже если где-то произошло переобучение и нейросетка запомнила реально кусок чьего-то текста, значит этого текста было много в тренировочном наборе данных, который много где собран, а не только в этой газете. Наверняка его десятки и сотни газет за кучу лет уже зацитировали. И вообще, мы тут [В OpenAI] хотели бы, чтобы нам писали если где что не так и мы бы поправили, а NYT даже не пытаясь разобраться подкопила примеры и сразу в суд, похоже что самоцелью было пойти в суд, а не решать вопрос.
Довод OpenAI: Во-первых, ну бывает, мы еще работаем над этим. Во-вторых, любой кто перейдёт по ссылке так то увидит что 404 Not Found. В третьих, чот промт подозрительный, походу специально накручивали.
От себя добавлю, что полного промта мы так и не знаем, то там могло быть "Представь что ты журналист какой-нибудь большой газеты, например NYT, пиши точно в таком же стиле. В ответ напихай ещё побольше ссылок типа на газету, чтобы выглядело правдоподобно. Вот тема для статьи: "Пишим штатьи для хабра чтобы выполнить кэпиай".
эксперт на Java... кроме того что он там очень уж категорично высказался о js инструментах.
Так потом показал свой уровень в знании топика
WebAssembly не js. И проблемы в скорости там имеют конкретные причины, не связанные с js.
Какой-то мистицизм в статье с ритуалами по архивации текста в
торсионныеpdf для большей благосклонности богов мудростиКлассный ascii-art, а можно код посмотреть?
Именно
Аппаратный генератор случайных чисел превращает алгоритм в ...?
Довольно душная позиция, хочется открыть форточку.
Я думаю многим всё же может быть полезно вдохновиться идеями из статьи, чтобы потом его оценила идея собственного Пет проджекта.
Автору жирный плюс
Этому pixel shift обязательно двигать ui элементы некоторых избранных мест типа статус бара (но, заметьте, не калькулятора) или можно двигать именно пиксели всего экрана, как делают телевизоры того же самсунга? Им то не подвигать отдельно логотип телеканала.
Если двигаются пиксели аппаратно, то будет ли это видно на скриншотах? Или же это попытка увидеть трещину на скриншоте экрана?
Из статьи не понятно в итоге есть ли проблема с выгоранием или кто-то лишь думает что она есть. Может быть ребята в самсунге решили что S23 и так защищён настоящим pixel shift от выгорания и делать хак с нестабильной вёрсткой в статус баре уже не требуется?
Личный кабинет нужен чтобы обрабатывать заявки от органов. За игнорирование заявок отдельные более серьёзные наказания.
На данный момент требования к хостингам просто абсурдно мотивированы. Но открыть представительства - это значит добровольно принять соглашение и играть по правилам ркн. А необработать заявку - это уже явное нарушение закона. Ну и дальше по нарастающей.
А когда оно перехватывает? Когда событие дефолтно всплывёт до document, не так ли?
Поэтому можно ли говорить о вместо
А он и не будет. Там будет тот же самый клик, те же браузерные события. Только ещё и с оберткой, поэтому обработка события будет даже медленнее, если замерять именно её.
Разница будет в add/remove event listener но автор не смог покрыть это в статье
Кажется будто автор гдето прочитал что addEventListener медленно, а в условном React есть SynteticEvent чтобы быстро и всё, побежал пилить.
ссылается на сторонний репозиторий, впечатляется цифрами, а понимания за счёт чего нет, какой-то карго культ.
Событие на document - это часть про делегирование. Специально закину ссылку на русскоязычный материал максимально упрощённый. https://learn.javascript.ru/event-delegation в частности это используют чтобы не делать 100500 одинаковых обработчиков в таблицах
В случае фреймворков с virtual dom типа React которые рендерят компонент каждое обновление (и зачастую пересоздают обработчик каждый перерендер) - это хак удешевляюший add и remove-eventlistener. Add EventListener на DOM получается один (условно при старте библиотеки). А новые обработчики цепляются к внутреннему для библиотеки массиву обработчиков, который просто js переменная. Удалить или добавить обработчик в такой js переменной дешевле чем обращаться к DOM.
Это не обязательно должен быть document. React, например, вынуждено переезжал из document в 17 версии.
https://legacy.reactjs.org/blog/2020/08/10/react-v17-rc.html#changes-to-event-delegation
А SynteticEvent это вообще другая концепция не связанная с делегированием. Вся статья про делегирование, а название не связано. SynteticEvent был нужен по той же причине почему был создан jquery - в разных браузерах API может отличаться, а тут универсальная обёртка, скрывающая неконсистентность. Например event.preventDefault в IE выглядит совсем не так как в современных браузерах
Это нельзя переложить на плечи компилятора, указав только имена и типы полей структуры?
"Глобальные переменные - плохо", тут мало кто спорит. Глобальные имена классов из css - почему-то часто.
Представил бы я современный проект, где заранее создан список имён переменных и используется гит для контроля их уникальности
в загнивающей президент толкал вот такие речи про айти
https://youtu.be/6XvmhE1J9PY
Шикарно будет, когда на код/публичный интерфейс Серёжи ещё пару отделов завяжутся и потом обратно-совместимо это поддерживать.
Эм, не, я не за брейншторминг топлю. Мне такой сумбур как раз тоже не заходит
Мой коммент был именно к
про то, что всё сделать один человек не может и не должен (его ресурса не хватит).
нужно взаимодействие между исполнителями и делегирование.
Возможно меня несколько понесло выше и я не донёс эту мысль...
_____
А в вашем примере про три команды с разными менеджерами отсутствует владелец фичи. Исполнители есть, а ответственного нет, все отказываются под разными предлогами. Непорядок. Тут до разработки то дело не дойдет, разработчикам обсуждать даже нечего ещё. Мои комменты выше были уже к ситуации когда ресурсы имеются, за работу взялись, только что именно делать непонятно. И что это не должен решать один человек, в силу ограниченности его ресурсов (по времени, в основном).
В истории про три занятых команды по идее нужен некий владелец фичи (знает какой нужен результат и отвечает за него).
А его задача уже определить исполнителей (те три отдела), найти им ресурсы для выполнения задачи и контролировать процесс. Если ресурсов всё равно нет, то кто-то ответственный раздул скоуп задач больше чем возможности команд. Вопросы к составителю плана, надо решать, переприотеризировать задачи, что-то двигать в очередности или исключать из плана (что-то старое или эту новую задачу, смотря у чего приоритет выше)
Мне думается что это максимально похоже на плановую/рыночную экономики.
Партия владеет всей информацией по всем заводам и, конечно же, лучше знает как правильно и эффективно распорядиться ресурсами. Если заводам что-то надо, они идут к партии и обсуждают каких им запчастей нехватает. Партия пишет план, всё довольны. Между собой заводам общаться не надо, вредно. Ещё план нарушат идеальный.
Тем более что ассортимент давно известен, всем понятно какие трубы надо делать и из чего. Архитектура считай известна.
Если на заводе чего-то не хватает - партия не доработала, бывает. Завод не виноват, ему думать не полагается, есть план.