Мой первый язык программирования, если так вообще можно сказать, был редактор карт к варкрафту третьему. А что, базы дает — ветвление, циклы, события, последовательность действий и огромная мотивация, в отличие от бесполезной программы на си.
Я сдался с постоянными переделками конфига и просто поставил regolith. Пока все нравится. Есть нарекания, но позволяет начать работать сразу с каким-ни-каким интерфейсом.
Вы со Швецией путаете, наверное, с конкретно этой историей. Только если почитать ту же медузу про эту историю, не все так просто: с точки зрения Швеции, нелегально проживающий отец без постоянной работы в одиночестве должен воспитывать трех детей. Какие шансы у этих детей стать успешными в сложившейся ситуации? Звучит, конечно, это все пугающе и страшно, но отец пошел дальше: выкрал детей (да, родительских прав его не лешили, но решили что конкретно этим детям лучше будет жить не с ним пока у него не нормализуется ситуация). Чего он вообще ожидал?
А ещё это должен быть достаточно мощный лазер чтобы ионизировать воздух. В противном случае вроде как потери неизбежны, да и квадратичны по отношению к расстоянию.
Радиус обнаружения у РЛС до 300-400 км у су-35, когда ракеты летают до 100 км (Р-77). Иными словами это клевый миф, но вы точно успеете друг друга обнаружить пока долетите на дистанцию атаки.
Пробовали обходиться только ракетами, не зашло, авиационные пушки всё еще на месте.
Хоть ракеты и могут поражать целы с перегрузкой до 12Г, они летают по одной из трех не самых крутых схеме наведения, для каждый из которых есть известная траектория ухода, а еще ловушки и прочее.
А еще мы, как человечество, не практиковались в реальном воздушном бою очень давно. Выясниться что мы не можем догнать друг друга, как прошлый раз.
По поводу выпирания: у меня был такой переходник и я уронил телефон. Не повезло, упал прям на этот адаптер, который выпирал даже из пластикового чехла. Итог — сеточка на экране прямиком из этого места. Понимаю, что шанс один на миллион, но осадок остался.
Насколько я понял, смысл приложения на Айфоне в том, чтобы с Айфона контролировать покупки ребенка на Xbox/Microsoft Store, а не наоборот, с винды контролировать айфон. Все равно у приложения на Айфоне прав никаких ничего внутри Айфона контролировать не будет.
Тем, что это работает в экосистеме microsoft. Как вы через родное айфоновское приложение запретите ребенку покупать что-то в microsoft store? И что, если у одного из детей (или у вас) андроид?
Ну вот хочу я сканер отпечатка пальца под экран. Как это должно решаться в модульном смартфоне? Или face id. Да и фронтальная камера туда же. Сейчас их вообще под экран ставят. И вы скажете "можно просто сделать сверху как раньше рамку широку, куда будут доставляться модули", на что я отвечу — хочу под экран. Не хочу широких рамок. Да и опять же, вот хочу крутую фронтальную камеру и face ID. А что если их выпускают разные компании, это два модуля и туда просто не лезут? Универсальный супер-экран, который подключается и как экран, и как датчики? Только стоить будет как два смартфона, конечно, а так да. Да и форма должна его заранее поддерживать.
А кто сказал что стандарт будет один? Если будет хоть надежда на популярность, кто-то выпустит другой стандарт и приехали. "Мне адаптер с гугло модуля на леново модуль". Ну и заодно, в бюджетные телефоны собирают самые компромисные решения. Самостоятельно из модулей будет гораздо дороже собрать. В конце концов, в готовую сборку не включена стоимость разработки модуля и так далее.
GPIO решает эту проблему на ура. Сам хочу телефон с закрытыми крышечкой пинами как в распбери. Но был же Essential phone, и где он сейчас? (Там были контакты для подключаемых устройств). Да и вообще, в телефоне есть USB-C, берите да используйте, в чем проблема?
Айфон итак используют для контроля разной перефирии. Я лично видел как айпад используют как большую кнопку чтобы колу в стаканчик наливать. Глупо, но работает. А вообще есть bluetooth. Модульность тут попросту ни к чему.
Да кого мы обманываем — если бы этот проект вышел в свет, он бы стал причиной кардинальных изменений всей индустрии разработки гаджетов.
Да чушь всё это и, видимо, гугл это вовремя понял. Современные телефоны просто невероятно плотно упакованы, а тут минимум четверь объема — просто ферма, на которую все навешивать. Лучше бы батарею большую сделали. Ну и об довольно полезных свойствах как влаго- и пылезащищенность можно забыть. Да и я не представляю себе как заменил бы какой-либо модуль кроме экрана или батареи. А для этого достаточно сделать телефон просто легко доступным к разбору (и потерять влагозащищенность), а не городить непонятно что. Ну и заодно интересно, как бы они решили проблему с камерами, которых сейчас много, им нужна широкая шина данных и все в этом духе. Было бы как с процессорами интел и их сокетами — вроде как модульно, а вроде как и менять каждый раз нужно (благо живет не два года, а больше). Ну и главное: если бы концепция была работающей, а проблема только в том что "как же перепродавать телефон" кто-то бы да выпустил такой телефон. Не гуглом едины. Хотя бы крышкой вместо магнитов модули держать. И где оно?
О том же Fairphone 3 пишут что он стоит в два раза больше своих спек, а как быстро он устареет морально? (Как по мне, он морально устарел еще до выхода).
Blocks вообще выглядит как типичный фрод с кикстартера.
Да, понимаю вас. Только хотел в комментарии выше написать "я бы рассказал на примере как оно работает внутри", но комментарий быстро разросся настолько, что его полезность стала совсем сомнительной. Но я все еще верю в то, что задание из серии "написать свой движок для хуков" может хорошо объяснить некоторые тонкости и странности хуков, например, почему порядок их вызова очень важен.
Что-то самодельное из серии:
function executeInContext(fn, tag) { }
function effect(effectFn) {}
// usage:
const callsCount = {};
function getCallsCount(tag) { return ++callsCount[tag]; };
function foo() {
console.log(effect(getCallsCount)); // эффект вызывает функцию и передает её контекст
}
executeInContext(() => {
foo(); // 1
foo(); // 2
foo(); //3
}, 'context 1');
executeInContext(() => {
foo(); // 1
foo(); // 2
}, 'context 2')
И как на этом построить тот же useState, и как сделать чтобы можно было вызвать два разных useState в пределах одной функции, и что эти "контексты" в реакте называются Fiber, и у них есть ссылка на метод "перерисовать" (пересчитать в данном случае) и тогда должно быть понятно как оно работает.
Да, я понимаю, что это обучающая статья, но мне кажется, что useCallback является слегка более базовой концепцией, и введение в хуки можно было сделать на чем-то более простом. Вот пример как это делают в библиотеке. Я понимаю, что треть логики связана с "leading", и можно сократить, но все равно впечатляет.
Хук useEffect в момент размонтирования компонента вызывает функцию, которую мы возвращаем из тела этого хука. В нашем случае будет вызвана clearTimer() и последний запланированный отложенный вызов будет отменен.
А еще он будет выполнен при переключении cleanUp, что в случае переключения с true на false сбросит последнюю операцию. Маловероятно, конечно, что кто-то будет его переопределять в рантайме, но, потенциально, это может создать кучу непониманий.
Из более значимого замечания: ваш хук каждый раз возвращает новую функцию, что просто очень плохо.
Рассмотрим ваш же пример:
const handleChange = async (event, newValue) => { /* ... */ }; // функция пересоздается каждый раз как компонент перерисован
<Slider /*... */
onChange={handleChange} // поэтому в слайдер каждый раз передается новая ссылка на функцию (новая функция в целом)
/>
Это означает что React.memo работать не будет и компонент будет перерисован каждый раз. Иногда со всякими кнопками и чекбоксами в этом проблем нет, однако бывают компоненты со сложной логикой и, обычно, они являются частью формы. Соответственно, если какое-то поле в форме изменилось, перерисована будет вся форма, за счет чего она может сильно тормозить и быть неотзывчивой.
Для исправления, очевидно, нужно обернуть handleChange в React.useCallback:
const handleChange = React.useCallback(event => { /* ... */ }, [ debouncedValueCheck ]); // упс, debouncedValueCheck пересоздается каждый раз когда компонент вызван, т.е. handleChange так же пересоздается.
Вообще необходимость расставлять React.useCallback для хуков — большая пролема. Хуже того, что часто нужно решать "стоит ли оно того", ведь эта операция не бесплатная сама по себе.
И в качестве решения приводите типичную ошибку мидла: решать через реакт и js то что проще и правильнее сделать на css. Хотя пункт, в целом, понятен.
Второй пример слегка высосан из пальца и правильное решение будет вообще абстрагироваться от этого и использовать одну из миллиона возможных оберток, я бы все же сделал пример с таймером как наиболее часто встречающимся.
Про тесты вы сами правильно написали. В итоге копипаста ради копипасты, причем это не рассписал только ленивый, есть даже в документации самого реакта.
Да, мне тоже кажется слегка неудобным судорожно махать рукой чтобы эта перчатка считала что-то в трафике. И я сперва подумал что это будет просто дополнение к обычным жестам — подниманием руки чтобы указать остановку, руку влево — поворот налево, разве что с поворотом направо неудобно выходит (нужна вторая перчатка).
Вообще с рождением Иисуса много проблем
Например чисто технически, Иисус родился в 7-4 годах до нашей эры (хах, т.е. до рождества Христова)
Религиоведы и теологи, придерживающиеся точки зрения, что Иисус является реальной исторической личностью, а не мифом, утверждают, что он родился в период с 7 года до н. э. по 4 год до н. э.[3] и умер в период с 30 по 33 год
Мой первый язык программирования, если так вообще можно сказать, был редактор карт к варкрафту третьему. А что, базы дает — ветвление, циклы, события, последовательность действий и огромная мотивация, в отличие от бесполезной программы на си.
Я сдался с постоянными переделками конфига и просто поставил regolith. Пока все нравится. Есть нарекания, но позволяет начать работать сразу с каким-ни-каким интерфейсом.
Просто невероятно натянутый способ собирать данные о местоположении пользователей. Хотя озвученная цель, безусловно, похвальная.
Вы со Швецией путаете, наверное, с конкретно этой историей. Только если почитать ту же медузу про эту историю, не все так просто: с точки зрения Швеции, нелегально проживающий отец без постоянной работы в одиночестве должен воспитывать трех детей. Какие шансы у этих детей стать успешными в сложившейся ситуации? Звучит, конечно, это все пугающе и страшно, но отец пошел дальше: выкрал детей (да, родительских прав его не лешили, но решили что конкретно этим детям лучше будет жить не с ним пока у него не нормализуется ситуация). Чего он вообще ожидал?
Ах да, и подать можно. Долго, сложно, но можно.
Да, конечно же, моя ошибка. Я имел ввиду что в воздухе неизбежно сигнал будет затухать даже при очень точной направоенности
А ещё это должен быть достаточно мощный лазер чтобы ионизировать воздух. В противном случае вроде как потери неизбежны, да и квадратичны по отношению к расстоянию.
Ну не совсем.
Радиус обнаружения у РЛС до 300-400 км у су-35, когда ракеты летают до 100 км (Р-77). Иными словами это клевый миф, но вы точно успеете друг друга обнаружить пока долетите на дистанцию атаки.
Пробовали обходиться только ракетами, не зашло, авиационные пушки всё еще на месте.
Хоть ракеты и могут поражать целы с перегрузкой до 12Г, они летают по одной из трех не самых крутых схеме наведения, для каждый из которых есть известная траектория ухода, а еще ловушки и прочее.
А еще мы, как человечество, не практиковались в реальном воздушном бою очень давно. Выясниться что мы не можем догнать друг друга, как прошлый раз.
По поводу выпирания: у меня был такой переходник и я уронил телефон. Не повезло, упал прям на этот адаптер, который выпирал даже из пластикового чехла. Итог — сеточка на экране прямиком из этого места. Понимаю, что шанс один на миллион, но осадок остался.
Насколько я понял, смысл приложения на Айфоне в том, чтобы с Айфона контролировать покупки ребенка на Xbox/Microsoft Store, а не наоборот, с винды контролировать айфон. Все равно у приложения на Айфоне прав никаких ничего внутри Айфона контролировать не будет.
Тем, что это работает в экосистеме microsoft. Как вы через родное айфоновское приложение запретите ребенку покупать что-то в microsoft store? И что, если у одного из детей (или у вас) андроид?
Выглядит, безусловно, интересно, но я бы сразу уже шел с библиотекой recoil
Ну вот хочу я сканер отпечатка пальца под экран. Как это должно решаться в модульном смартфоне? Или face id. Да и фронтальная камера туда же. Сейчас их вообще под экран ставят. И вы скажете "можно просто сделать сверху как раньше рамку широку, куда будут доставляться модули", на что я отвечу — хочу под экран. Не хочу широких рамок. Да и опять же, вот хочу крутую фронтальную камеру и face ID. А что если их выпускают разные компании, это два модуля и туда просто не лезут? Универсальный супер-экран, который подключается и как экран, и как датчики? Только стоить будет как два смартфона, конечно, а так да. Да и форма должна его заранее поддерживать.
А кто сказал что стандарт будет один? Если будет хоть надежда на популярность, кто-то выпустит другой стандарт и приехали. "Мне адаптер с гугло модуля на леново модуль". Ну и заодно, в бюджетные телефоны собирают самые компромисные решения. Самостоятельно из модулей будет гораздо дороже собрать. В конце концов, в готовую сборку не включена стоимость разработки модуля и так далее.
GPIO решает эту проблему на ура. Сам хочу телефон с закрытыми крышечкой пинами как в распбери. Но был же Essential phone, и где он сейчас? (Там были контакты для подключаемых устройств). Да и вообще, в телефоне есть USB-C, берите да используйте, в чем проблема?
Айфон итак используют для контроля разной перефирии. Я лично видел как айпад используют как большую кнопку чтобы колу в стаканчик наливать. Глупо, но работает. А вообще есть bluetooth. Модульность тут попросту ни к чему.
Это все хорошо, но ещё есть power supply specification, которая позволяет устройству получать заряд без данных
Да чушь всё это и, видимо, гугл это вовремя понял. Современные телефоны просто невероятно плотно упакованы, а тут минимум четверь объема — просто ферма, на которую все навешивать. Лучше бы батарею большую сделали. Ну и об довольно полезных свойствах как влаго- и пылезащищенность можно забыть. Да и я не представляю себе как заменил бы какой-либо модуль кроме экрана или батареи. А для этого достаточно сделать телефон просто легко доступным к разбору (и потерять влагозащищенность), а не городить непонятно что. Ну и заодно интересно, как бы они решили проблему с камерами, которых сейчас много, им нужна широкая шина данных и все в этом духе. Было бы как с процессорами интел и их сокетами — вроде как модульно, а вроде как и менять каждый раз нужно (благо живет не два года, а больше). Ну и главное: если бы концепция была работающей, а проблема только в том что "как же перепродавать телефон" кто-то бы да выпустил такой телефон. Не гуглом едины. Хотя бы крышкой вместо магнитов модули держать. И где оно?
О том же Fairphone 3 пишут что он стоит в два раза больше своих спек, а как быстро он устареет морально? (Как по мне, он морально устарел еще до выхода).
Blocks вообще выглядит как типичный фрод с кикстартера.
Да, понимаю вас. Только хотел в комментарии выше написать "я бы рассказал на примере как оно работает внутри", но комментарий быстро разросся настолько, что его полезность стала совсем сомнительной. Но я все еще верю в то, что задание из серии "написать свой движок для хуков" может хорошо объяснить некоторые тонкости и странности хуков, например, почему порядок их вызова очень важен.
Что-то самодельное из серии:
И как на этом построить тот же useState, и как сделать чтобы можно было вызвать два разных useState в пределах одной функции, и что эти "контексты" в реакте называются Fiber, и у них есть ссылка на метод "перерисовать" (пересчитать в данном случае) и тогда должно быть понятно как оно работает.
Да, я понимаю, что это обучающая статья, но мне кажется, что useCallback является слегка более базовой концепцией, и введение в хуки можно было сделать на чем-то более простом. Вот пример как это делают в библиотеке. Я понимаю, что треть логики связана с "leading", и можно сократить, но все равно впечатляет.
А еще он будет выполнен при переключении cleanUp, что в случае переключения с true на false сбросит последнюю операцию. Маловероятно, конечно, что кто-то будет его переопределять в рантайме, но, потенциально, это может создать кучу непониманий.
Из более значимого замечания: ваш хук каждый раз возвращает новую функцию, что просто очень плохо.
Рассмотрим ваш же пример:
Это означает что React.memo работать не будет и компонент будет перерисован каждый раз. Иногда со всякими кнопками и чекбоксами в этом проблем нет, однако бывают компоненты со сложной логикой и, обычно, они являются частью формы. Соответственно, если какое-то поле в форме изменилось, перерисована будет вся форма, за счет чего она может сильно тормозить и быть неотзывчивой.
Для исправления, очевидно, нужно обернуть handleChange в React.useCallback:
Вообще необходимость расставлять React.useCallback для хуков — большая пролема. Хуже того, что часто нужно решать "стоит ли оно того", ведь эта операция не бесплатная сама по себе.
И в качестве решения приводите типичную ошибку мидла: решать через реакт и js то что проще и правильнее сделать на css. Хотя пункт, в целом, понятен.
Второй пример слегка высосан из пальца и правильное решение будет вообще абстрагироваться от этого и использовать одну из миллиона возможных оберток, я бы все же сделал пример с таймером как наиболее часто встречающимся.
Про тесты вы сами правильно написали. В итоге копипаста ради копипасты, причем это не рассписал только ленивый, есть даже в документации самого реакта.
Да, мне тоже кажется слегка неудобным судорожно махать рукой чтобы эта перчатка считала что-то в трафике. И я сперва подумал что это будет просто дополнение к обычным жестам — подниманием руки чтобы указать остановку, руку влево — поворот налево, разве что с поворотом направо неудобно выходит (нужна вторая перчатка).
Вообще с рождением Иисуса много проблем
Например чисто технически, Иисус родился в 7-4 годах до нашей эры (хах, т.е. до рождества Христова)
Вики
Да и я не понимаю как можно было умереть в плавающий день...