Изобреталь изобрел идею и сделал рабочий прототип, первый запатентовал. Так что он вполне себе достоин почёта. А упора на кражу в статье нет. Даже слова такого на самом деле. Заимствование здравых идей - это нормально и не удивительно.
Тут вопрос - что это за человек. Если это бедный студент которому ноутбук подарили родители (а из уровня статьи можно предположить что так и есть), то поддерживать конечно такое нельзя, но понять и простить можно)
Эм... мы точно про литиевые акб говорим? Их вроде под током никто никогда не держит, они имеют свойства от такого взрываться. При разу не слышал чтобы контроллер в батарее такое непотребство позволял - обычно после зарядки до 100 они дальше циклируются в режиме медленного заряда в диапазоне 95-100% и это да, довольно вредно.
У li-poli и li-ion акб тот-же эффект. Чем выше заряд после 50%, тем больше вероятность выдавливания металического лития и оседания его в качестве дендритов, которые уменьшают расстояние меджу катодом и анодом, а значит и ёмкость. Хранить такие батареи лучше всего на 50% и циклировать вокруг этого числа.
На канале Pro Hi-Tech есть несколько хороших видео с интервью с учёными, занимающимися АКБ, которые рассказывают об этом подробнее, если интересно.
Скорее всего ваш монитор уже выгорел, просто вы этого не понимаете, потому что это произошло плавно и незаметно.
Примерно как садится зрение - вроде ничего не меняется - а потом надеваешь очки - и мир становится резко четче.
Т.е. если вы сейчас поставите свой монитор рядом с новым таким-же, то ощутите вау эффект от нового, т.к. картинка будет четче, равномернее и цветастее.
И microLed будут греться меньше чем oled и остальные варианты (на той же яркости) - просто потому, что у них меньше слоев, не требуется поляризационный фильтр, а значит меньше света уходит в тепло.
И если уж отвечать на ваш первый вопрос из ветки - oled - это organic LED - что означает светодиоды на основе органической химии, а microLed - это светодиоды на основе неорганической химии, но принцип попиксельного свечения у них одинаковый, и с точки зрения потребителя действительно oled и microled похожи, но назвать один другим - преступление против аббривиатур)
Есть большая ошибка про понимание oled и выгорания.
Маркетологи вогнали людям в головы самые страшные варианты выгорания (с постоянным рисунком на экране). И скорее всего специально, чтобы скрыть реальную проблему. На самом деле она глубже - даже если смотреть только динамичные сцены - пиксели всё равно будут терять яркость неравномерно. Это приведёт к тому, что картинка которая в первый день была идеальным серым листом - через период станет шумной и цветной - где-то в субпикселях сильнее выгорят зелёные, где-то синие.
При этом сейчас в OLED-ах заложен алгоритм коррекции и некоторый запас прочности - условно - первый год экран считает время которое светил каждый пиксель и делает ребалансировку яркости с его учётом (повышая напругу), и для пользователя оно будет выглядеть как - первые 2 года идеальная картинка, ещё через год - ухты какое изображение на новых тв крутое, как скакнули технологии. А на деле - просто телевизор плавно деграднул.
На мой взгляд скрам - методология для разработки маленьких стартапов или продуктов с очень простыми деталями. Когда ваша доработка - небольшая веб страница, кнопка постановки лайка, новый вариант сортировки - всё отлично, задача грумится командой, придумывается решение/дизайе/методы тестирования, бъется на части, инкремент каждый спринт - всё отлично.
Когда у вас задачи - которые только грумить надо неделю - где взаимодействие с 3мя сторонними системами, интеграция в 10 продуктовых флоу (и нет, по одному нельзя - они все связаны), и плюсом непонятна сложность. То начинается бесконечный перенос задачи из спринта в спринт, разбаланисровка команды - потому что бэкенд уже закончил, фронтенд ещё на середине, аналитики уже сидят крутят усы - скрам разваливается)
Вроде во всех языках ООП уже довольно давно пришли к концепции data классов или их аналогов - когда данные отделены от кода их обрабатывающего. И проблемы которые вы описали не существуют. Про то, что человек интерфес не написал - для этого есть генерация интерфеса в любой нормальной ide - когда ты видишь, что у тебя больше 1 случая использования - жмешь 1 кнопку и готово, а написания кода когда он не нужен - плохая практика. Переменные не data классов используются для хранения состояния - и вот во всех функциональных языках которые я в своё время трогал - с хранением состляния были огромные проблемы.
А главное, в современных языках никто не мешает брать лучшее от обоих миров. C# тот же поддерживает и делегаты и карирование функций, и методы не принадлежащие классам, и конвеерные операции. И при этом чтобы запомнить на каком месте находится пользовательский фокус, написать утилиту или сделать оптимистичный лайк - не нужно изворачиваться
Мне кажется все дело в том, что средние руководители в таких компаниях бояться, что на удалёнке начнут замечать их абсолютную бесполезность и начнут платить соответственно.
Если в офисе можно ходить по кабинетам "контролировать", проводить "ну знаешь, эти рабочие встречи", и в целом "сидеть отвечать на вопросы сотрудников".
То когда все коммуникации через интернет - то люди которые весь банкет оплачивают могут заметить - что ни одного звонка от сотрудников, ни одного решенного вопроса и ни одной адекватной рабочей встречи по факту не было, и по человек просто весь день балду гоняет, просто в офисе этого не заметно. По этому им нужно согнать всех в офис - ведь работников там не будет, опять-же оправдания активности не прокатят.
Почему сделан переход к планковской длинне в первом эксперементе? Люди же могут подумать - что это реально как-то связано с невозможностью произвести измерения из-за особенностей наших инструмнтов.
Я правильно понял из статьи - что причина, почему левитация как с графитом не находит практического применения - отношение подъемной силы к необходимому магнитному полю и это не решается никакими способами масштабирования?
А какие AI задачи (или скорее с какой производительностью) может orange pi ai и аналоги решать?
Ну типо на нем можно кантованную 8b модель запустить в реальном времени или может нейронкой звук распознавать? Или diffusion сеть завести? Интересно на что его хватит автономно.
Не знаю как там в будущем, но о чём говорить сейчас - если я сейчас даю deepseek composable функцию и прошу оптимизировать её - и он предлагает выполнить определённые действия, а потом я даю ему новый вариант, он предлагает вернуть всё как было)
Приехал к городу, оставил машину на крупной свободной загородной парковке, и поехал спокойно на ОТ. Ещё забавнее получается в вашей логике, что за городом живете вы, а парковку вам должны оплачивать жители города куда вы приехали за счет своего пространства. А давайте наоборот, все жители города приедут к вам загород, и запаркуют пространство вокруг вашего дома со всех сторон на многие километры)
Вернемя к примерам из жизни. Есть страница с фильмами - на фильм можно поставить лайк (лайк - кнопка страницы). В другом месте добавляли возможность отображать сериалы, побочным эффектом она добавилась и тут. Тесты для сералов написали (на отображение, на открытие), но упс - тест кнопки лайк забыли, тест страницы в тестовых данных содержит фильмы, там все замечально.
Что дальше? - все вылилось на прод, пользователь пошел ставить лайк и упс - прод упал, потому что нет у сериала id фильма.
А типобезопасное приложение не скомпилировалось потому что нельзя в метод лайк передать сущность сериал, будьте здрасте как говорится.
Т.е. мы избавляемся от принудительой типизации, но приходим к таким-же не менее принудительным тестам на 100% кодовой базы. А тесты как раз косвенно внутри содержат описания типов, чтобы падать в случае изменения структуры (я же не хочу чтобы мне по резултатам мержа или перепутанных параметров, в тест в поле для boolean флага прилетела строка, которая автоматом скастилась в сравнении в false, и из за этого отработало корректно до тех пор пока какой нибудь хитрец не введёт в текстовое поле true). А значит при изменении типа - всё равно придётся переписывать тест.
Как будто шило на мыло, только мыло хуже)
Кстати да, вспомнил все проекты сложнее двух файлов на языках с динамической типизацией, которые я видел - везде ~100% покрытия тестами, иначе с динамической типизацией особо не выжить)
Вот в статье как то не раскрыто - почему?
Замыкание слишком просто получить налив солёной воды между рельсами? Или боимся что ребёнок будет два рельса держать?
Изобреталь изобрел идею и сделал рабочий прототип, первый запатентовал. Так что он вполне себе достоин почёта. А упора на кражу в статье нет. Даже слова такого на самом деле. Заимствование здравых идей - это нормально и не удивительно.
Тут вопрос - что это за человек. Если это бедный студент которому ноутбук подарили родители (а из уровня статьи можно предположить что так и есть), то поддерживать конечно такое нельзя, но понять и простить можно)
Скорее всего они будут актуальны до тех пор, пока не начнут применяться твердотельные акб.
Эм... мы точно про литиевые акб говорим? Их вроде под током никто никогда не держит, они имеют свойства от такого взрываться. При разу не слышал чтобы контроллер в батарее такое непотребство позволял - обычно после зарядки до 100 они дальше циклируются в режиме медленного заряда в диапазоне 95-100% и это да, довольно вредно.
У li-poli и li-ion акб тот-же эффект. Чем выше заряд после 50%, тем больше вероятность выдавливания металического лития и оседания его в качестве дендритов, которые уменьшают расстояние меджу катодом и анодом, а значит и ёмкость. Хранить такие батареи лучше всего на 50% и циклировать вокруг этого числа.
На канале Pro Hi-Tech есть несколько хороших видео с интервью с учёными, занимающимися АКБ, которые рассказывают об этом подробнее, если интересно.
Скорее всего ваш монитор уже выгорел, просто вы этого не понимаете, потому что это произошло плавно и незаметно.
Примерно как садится зрение - вроде ничего не меняется - а потом надеваешь очки - и мир становится резко четче.
Т.е. если вы сейчас поставите свой монитор рядом с новым таким-же, то ощутите вау эффект от нового, т.к. картинка будет четче, равномернее и цветастее.
И microLed будут греться меньше чем oled и остальные варианты (на той же яркости) - просто потому, что у них меньше слоев, не требуется поляризационный фильтр, а значит меньше света уходит в тепло.
И если уж отвечать на ваш первый вопрос из ветки - oled - это organic LED - что означает светодиоды на основе органической химии, а microLed - это светодиоды на основе неорганической химии, но принцип попиксельного свечения у них одинаковый, и с точки зрения потребителя действительно oled и microled похожи, но назвать один другим - преступление против аббривиатур)
Есть большая ошибка про понимание oled и выгорания.
Маркетологи вогнали людям в головы самые страшные варианты выгорания (с постоянным рисунком на экране). И скорее всего специально, чтобы скрыть реальную проблему. На самом деле она глубже - даже если смотреть только динамичные сцены - пиксели всё равно будут терять яркость неравномерно. Это приведёт к тому, что картинка которая в первый день была идеальным серым листом - через период станет шумной и цветной - где-то в субпикселях сильнее выгорят зелёные, где-то синие.
При этом сейчас в OLED-ах заложен алгоритм коррекции и некоторый запас прочности - условно - первый год экран считает время которое светил каждый пиксель и делает ребалансировку яркости с его учётом (повышая напругу), и для пользователя оно будет выглядеть как - первые 2 года идеальная картинка, ещё через год - ухты какое изображение на новых тв крутое, как скакнули технологии. А на деле - просто телевизор плавно деграднул.
На мой взгляд скрам - методология для разработки маленьких стартапов или продуктов с очень простыми деталями. Когда ваша доработка - небольшая веб страница, кнопка постановки лайка, новый вариант сортировки - всё отлично, задача грумится командой, придумывается решение/дизайе/методы тестирования, бъется на части, инкремент каждый спринт - всё отлично.
Когда у вас задачи - которые только грумить надо неделю - где взаимодействие с 3мя сторонними системами, интеграция в 10 продуктовых флоу (и нет, по одному нельзя - они все связаны), и плюсом непонятна сложность. То начинается бесконечный перенос задачи из спринта в спринт, разбаланисровка команды - потому что бэкенд уже закончил, фронтенд ещё на середине, аналитики уже сидят крутят усы - скрам разваливается)
Вроде во всех языках ООП уже довольно давно пришли к концепции data классов или их аналогов - когда данные отделены от кода их обрабатывающего. И проблемы которые вы описали не существуют. Про то, что человек интерфес не написал - для этого есть генерация интерфеса в любой нормальной ide - когда ты видишь, что у тебя больше 1 случая использования - жмешь 1 кнопку и готово, а написания кода когда он не нужен - плохая практика. Переменные не data классов используются для хранения состояния - и вот во всех функциональных языках которые я в своё время трогал - с хранением состляния были огромные проблемы.
А главное, в современных языках никто не мешает брать лучшее от обоих миров. C# тот же поддерживает и делегаты и карирование функций, и методы не принадлежащие классам, и конвеерные операции. И при этом чтобы запомнить на каком месте находится пользовательский фокус, написать утилиту или сделать оптимистичный лайк - не нужно изворачиваться
Мне кажется все дело в том, что средние руководители в таких компаниях бояться, что на удалёнке начнут замечать их абсолютную бесполезность и начнут платить соответственно.
Если в офисе можно ходить по кабинетам "контролировать", проводить "ну знаешь, эти рабочие встречи", и в целом "сидеть отвечать на вопросы сотрудников".
То когда все коммуникации через интернет - то люди которые весь банкет оплачивают могут заметить - что ни одного звонка от сотрудников, ни одного решенного вопроса и ни одной адекватной рабочей встречи по факту не было, и по человек просто весь день балду гоняет, просто в офисе этого не заметно. По этому им нужно согнать всех в офис - ведь работников там не будет, опять-же оправдания активности не прокатят.
Попахивает расизмом)) в моих задачах ответы разных сетей примерны эквивалентны по качеству)
Почему сделан переход к планковской длинне в первом эксперементе? Люди же могут подумать - что это реально как-то связано с невозможностью произвести измерения из-за особенностей наших инструмнтов.
Я правильно понял из статьи - что причина, почему левитация как с графитом не находит практического применения - отношение подъемной силы к необходимому магнитному полю и это не решается никакими способами масштабирования?
А какие AI задачи (или скорее с какой производительностью) может orange pi ai и аналоги решать?
Ну типо на нем можно кантованную 8b модель запустить в реальном времени или может нейронкой звук распознавать? Или diffusion сеть завести? Интересно на что его хватит автономно.
Не знаю как там в будущем, но о чём говорить сейчас - если я сейчас даю deepseek composable функцию и прошу оптимизировать её - и он предлагает выполнить определённые действия, а потом я даю ему новый вариант, он предлагает вернуть всё как было)
Приехал к городу, оставил машину на крупной свободной загородной парковке, и поехал спокойно на ОТ. Ещё забавнее получается в вашей логике, что за городом живете вы, а парковку вам должны оплачивать жители города куда вы приехали за счет своего пространства. А давайте наоборот, все жители города приедут к вам загород, и запаркуют пространство вокруг вашего дома со всех сторон на многие километры)
Наоборот это тоже работает) тесты не спасают от ошибок типов - ниже я описал конкретный пример.
Вернемя к примерам из жизни. Есть страница с фильмами - на фильм можно поставить лайк (лайк - кнопка страницы). В другом месте добавляли возможность отображать сериалы, побочным эффектом она добавилась и тут. Тесты для сералов написали (на отображение, на открытие), но упс - тест кнопки лайк забыли, тест страницы в тестовых данных содержит фильмы, там все замечально.
Что дальше? - все вылилось на прод, пользователь пошел ставить лайк и упс - прод упал, потому что нет у сериала id фильма.
А типобезопасное приложение не скомпилировалось потому что нельзя в метод лайк передать сущность сериал, будьте здрасте как говорится.
Т.е. мы избавляемся от принудительой типизации, но приходим к таким-же не менее принудительным тестам на 100% кодовой базы. А тесты как раз косвенно внутри содержат описания типов, чтобы падать в случае изменения структуры (я же не хочу чтобы мне по резултатам мержа или перепутанных параметров, в тест в поле для boolean флага прилетела строка, которая автоматом скастилась в сравнении в false, и из за этого отработало корректно до тех пор пока какой нибудь хитрец не введёт в текстовое поле true). А значит при изменении типа - всё равно придётся переписывать тест.
Как будто шило на мыло, только мыло хуже)
Кстати да, вспомнил все проекты сложнее двух файлов на языках с динамической типизацией, которые я видел - везде ~100% покрытия тестами, иначе с динамической типизацией особо не выжить)