Прим. от кожаного мешка: Интересно, чатгпт лучше справилась?
Toyota Представляет Симулированную Механическую Коробку Передач для Электромобилей: Новинка с Неограниченным Количеством Скоростей
Электромобили постепенно входят в нашу жизнь, но для многих автолюбителей отсутствие классического "механика" остается препятствием на пути к полной гармонии с электротранспортом. Компания Toyota предложила оригинальное решение этой проблемы, представив патент на симулированную механическую коробку передач для своих электромобилей.
Согласно недавно опубликованному патенту, в этой системе теоретически нет ограничения на количество "передач". Изображения, приложенные к техническому документу, даже демонстрируют версии с до 14 скоростями. Но как это работает на практике?
В документе подробно описывается, что водитель может выбрать любое количество передач в соответствии со своими предпочтениями. Например, можно установить шесть или более ступеней, или даже меньше шести. Главное здесь – свобода выбора для водителя.
Но стоит уточнить, что речь идет не о какой-то электро-механической системе, создающей физические затворы передач в соответствии с желаниями пользователя. Вместо этого, будет фиксированное количество реальных "ворот"; скорее всего шесть, хотя в качестве примера Toyota приводит четыре. Переключение передач происходит так же, как и в обычной механике, но рычаг может возвращаться в нейтральное положение после использования. Затем, проходя через передачи, виртуальный паттерн сдвигается к следующему набору "режимов". Так, выбрав шестую передачу, на дисплее может появиться приглашение переключиться на седьмую и так далее.
Звучит запутанно? Возможно, именно поэтому автопроизводители никогда не стремились к созданию более чем семиступенчатых механических коробок передач для обычных легковых автомобилей. Но когда речь идет о симуляции механической коробки, Toyota считает, что предоставление выбора пользователям – это не что-то вредное.
Это новшество от Toyota обещает добавить новые ощущения в управление электромобилями, приближая их к традиционным автомобилям с ДВС и, возможно, сделав их более привлекательными для широкого круга автолюбителей. Следите за обновлениями – эра электромобилей только начинается, и каждый день приносит что-то новое и удивительное.
Несколько лет назад мы фантазировали на тему таких интерфейсов в телефоне. Продумывали UX всех взаимодействий. Класс, что у вас получилось зарелизиться!
С технической точки зрения, многие SPA-фреймворки умеют из коробки в навигацию. А наличие подобного механизма помимо положительного влияния на UX еще и упрощает разработку, что ведет к ускорению процесса.
PWA-установка на домашний экран довольно простая (по-сравнению, с установокой приложения из Аппстора, например, ввод пароля (а такое бывает) напрочь застопорит процесс установки).
А PWA обладает полноэкранным режимом. Из бонусов -- процесс установки может быть отложен до первого успешного раунда или даже игры.
Именно. В свое время отказался от красивого синтаксиса dot нотаций, когда одна из подобных фич грузила дополнительную библиотеку. Например, в такой карточке (а она может быть одна на всю страницу) нужно отобразить график.
А здесь начинает ломаться tree-shaking. И даже если мы будем использовать такой компонент без графика (дополнительной библиотекой), она притащится вся и целиком, даже если не используется, получается мертвый код налицо.
Если же вместе с dot-нотацией идет в комплекте babel-плагин, тогда уже лучше.
А как по-вашему, браузер хранит их? Собственным механизмом разметки бинарного пространства, предоставленном физическим носителем? Нет, это все лежит в файле того или иного формата. В процессе работы -- в оперативной памяти, а затем сохраняет в файл.
Возражу, в таком смысле можно было бы сконфигурировать webpack на генерацию статических svg, со свойствами fill="currentColor" и т.д., и не иметь оверхеда.
Автоматический бандлинг имеет смысл, так как на среднем проекте очень часто используется максимум 5-10-20 общих иконок (стрелочки, человечки, т.д.), если у вас на проекте сотни разных иконок, то скорее всего, довольно весомая часть из них встречается в одном React-компоненте, который и стоит отправлять в отдельный чанк, возможно, с целом куском UI-я, который окружает эту иконку.
Конечно, при бесконечном большом проекте, конечно, бесконечное число иконок будет иметь смысл превратить в бесконечное число мини-чанков, однако в таком крайнем случае просто svg-иконки как svg-файлы будут самым верным решением.
Хорошая статья для понимания того как работает процесс бандлинга. Однако, оверхед в 1,5мб довольно высок, и многие фреймворки имеют автоматическое создание чанков по страницам, компонентам, где оверхед чанка уже незаметен.
Зачем? на работу/учебу и обратно. Я предпочту припарковать и зарядить, чем тащить с собой еще 5кг-10кг батарей. Не хочу переплачивать за ненужный функционал, которы мне вредит.
Должен быстро заряжаться до полной емкости
Тут либо первое, либо второе. Но с этим пунктом я согласен. Однако, время заряда небольшой батарее будет меньше, чем батареи большей емкости.
Не должен бояться заморозков.
Согласен. Возможно, в модели для северных регионов. Не хочу переплачивать за ненужный функционал.
Должен быть более «тяговитым»
Зачем? Чтобы убиться?
Должен быть безопасным
Согласен. Тогда он должен быть легким и не-«тяговитым»
должен продаваться по цене, доступной российскому покупателю.
Делим на ноль.
И с таким подходом про самокат у авторов получается Батут Рогозина.
Дизайн-система — это UI kit, превращенный в код и связанный с ним, т. е. это система [UI kit] [+] [код].
Т. е. UI kit ≠ дизайн-система!
Не уверен, насчет определений, однако согласен с утверждением, о неравенстве.
В моем понимании:
Дизайн-система -- это набор правил и консистентность в цветах, отступах, комбинациях. Грубо говоря, когда говорят "У нас есть Дизайн-система", подразумевают наличие (или желание) имплементированной логики базовых элементов дизайна.
UI-kit -- это набор компонентов, которые могут следовать дизайн-системе. Однако, этот kit может быть имплементирован где угодно: в коде, графическом редакторе. В отличие от дизайн-системы -- UI-kit, это готовый к использованию набор элементов.
Цифра здесь скорее всего с потолка, однако, потерянное время на код-ревью может быть существенным. А одинаковость кода уменьшает когнитивную нагрузку. А этот фактор имеет долговременный эффект.
Будет горизонтальный скролл страницы на iOs, если не прикрыть overflow: hidden; , который может обрезать тени, вызвать дополнительные визуальные баги или отсутствие работы backdropFilter.
А еще проблемы с width: 100%; или необходимость calc()
Да, вот что меня действительно раздражает, так этот момент, когда компонент написан, но тут возникает задача пробросить ref, и начинается синтаксический ад с forwardRef и Typescript. Пока все скобочки в нужном порядке расставишь, все желание кодить пропадает =)
Но по идее мы можем глобально расширить тип HTMLAttributes, либо же создать новый тип-дженерик, который принимал бы на вход параметры для data-атрибутов.
Вот пример (может кому пригодится), с глобальной модификацией:
Одно время я тоже ими пользовался, даже перевел статью про выход пятой версии. Однако, не очень гладкая интеграция с Mui четвертой версии заставила перейти на JSS объектный синтаксис. А сейчас, в пятой версии этой великолепной библиотеки, разработчики взяли emotion как решение по умолчанию.
Возможно, стоит задуматься о возврате к простому kebab-case синтаксису css без upperCase девиаций =)
В первом случае у вас настоящий LLM-ный рандом.
В гистограмме же используется Python, и там, наверняка, используется функция
random().Прим. от кожаного мешка: Интересно, чатгпт лучше справилась?
Toyota Представляет Симулированную Механическую Коробку Передач для Электромобилей: Новинка с Неограниченным Количеством Скоростей
Электромобили постепенно входят в нашу жизнь, но для многих автолюбителей отсутствие классического "механика" остается препятствием на пути к полной гармонии с электротранспортом. Компания Toyota предложила оригинальное решение этой проблемы, представив патент на симулированную механическую коробку передач для своих электромобилей.
Согласно недавно опубликованному патенту, в этой системе теоретически нет ограничения на количество "передач". Изображения, приложенные к техническому документу, даже демонстрируют версии с до 14 скоростями. Но как это работает на практике?
В документе подробно описывается, что водитель может выбрать любое количество передач в соответствии со своими предпочтениями. Например, можно установить шесть или более ступеней, или даже меньше шести. Главное здесь – свобода выбора для водителя.
Но стоит уточнить, что речь идет не о какой-то электро-механической системе, создающей физические затворы передач в соответствии с желаниями пользователя. Вместо этого, будет фиксированное количество реальных "ворот"; скорее всего шесть, хотя в качестве примера Toyota приводит четыре. Переключение передач происходит так же, как и в обычной механике, но рычаг может возвращаться в нейтральное положение после использования. Затем, проходя через передачи, виртуальный паттерн сдвигается к следующему набору "режимов". Так, выбрав шестую передачу, на дисплее может появиться приглашение переключиться на седьмую и так далее.
Звучит запутанно? Возможно, именно поэтому автопроизводители никогда не стремились к созданию более чем семиступенчатых механических коробок передач для обычных легковых автомобилей. Но когда речь идет о симуляции механической коробки, Toyota считает, что предоставление выбора пользователям – это не что-то вредное.
Это новшество от Toyota обещает добавить новые ощущения в управление электромобилями, приближая их к традиционным автомобилям с ДВС и, возможно, сделав их более привлекательными для широкого круга автолюбителей. Следите за обновлениями – эра электромобилей только начинается, и каждый день приносит что-то новое и удивительное.
Несколько лет назад мы фантазировали на тему таких интерфейсов в телефоне. Продумывали UX всех взаимодействий. Класс, что у вас получилось зарелизиться!
С технической точки зрения, многие SPA-фреймворки умеют из коробки в навигацию. А наличие подобного механизма помимо положительного влияния на UX еще и упрощает разработку, что ведет к ускорению процесса.
PWA-установка на домашний экран довольно простая (по-сравнению, с установокой приложения из Аппстора, например, ввод пароля (а такое бывает) напрочь застопорит процесс установки).
А PWA обладает полноэкранным режимом. Из бонусов -- процесс установки может быть отложен до первого успешного раунда или даже игры.
Так процесс онбоардинга будет еще проще.
Мне кажется, но вы спорите с нейросетью =)
P.S.: Отвечаю ли я нейросети?
P.P.S.: Нейросеть ли я?
Именно. В свое время отказался от красивого синтаксиса
dotнотаций, когда одна из подобных фич грузила дополнительную библиотеку. Например, в такой карточке (а она может быть одна на всю страницу) нужно отобразить график.А здесь начинает ломаться tree-shaking. И даже если мы будем использовать такой компонент без графика (дополнительной библиотекой), она притащится вся и целиком, даже если не используется, получается мертвый код налицо.
Если же вместе с dot-нотацией идет в комплекте
babel-плагин, тогда уже лучше.А как по-вашему, браузер хранит их? Собственным механизмом разметки бинарного пространства, предоставленном физическим носителем? Нет, это все лежит в файле того или иного формата. В процессе работы -- в оперативной памяти, а затем сохраняет в файл.
Возражу, в таком смысле можно было бы сконфигурировать webpack на генерацию статических svg, со свойствами
fill="currentColor"и т.д., и не иметь оверхеда.Автоматический бандлинг имеет смысл, так как на среднем проекте очень часто используется максимум 5-10-20 общих иконок (стрелочки, человечки, т.д.), если у вас на проекте сотни разных иконок, то скорее всего, довольно весомая часть из них встречается в одном React-компоненте, который и стоит отправлять в отдельный чанк, возможно, с целом куском UI-я, который окружает эту иконку.
Конечно, при бесконечном большом проекте, конечно, бесконечное число иконок будет иметь смысл превратить в бесконечное число мини-чанков, однако в таком крайнем случае просто
svg-иконки какsvg-файлы будут самым верным решением.Хорошая статья для понимания того как работает процесс бандлинга. Однако, оверхед в 1,5мб довольно высок, и многие фреймворки имеют автоматическое создание чанков по страницам, компонентам, где оверхед чанка уже незаметен.
Зачем? на работу/учебу и обратно. Я предпочту припарковать и зарядить, чем тащить с собой еще 5кг-10кг батарей. Не хочу переплачивать за ненужный функционал, которы мне вредит.
Тут либо первое, либо второе. Но с этим пунктом я согласен. Однако, время заряда небольшой батарее будет меньше, чем батареи большей емкости.
Согласен. Возможно, в модели для северных регионов. Не хочу переплачивать за ненужный функционал.
Зачем? Чтобы убиться?
Согласен. Тогда он должен быть легким и не-«тяговитым»
Делим на ноль.
И с таким подходом про самокат у авторов получается Батут Рогозина.
Но... mobx рекомендовано использовать с хуками =)
> чему он там "научится"
самому главному -- человеческой натуре
А книги -- это цензурированное и отфильтрованное проявление культуры в довольно узком спектре
А вы правда не видите связи между ламповостью, уменьшением количества интересных статей и отъездом специалистов?
А можно все то же самое, но завернуть все картинки под спойлер?
Могу порекомендовать к чтению эту статью https://habr.com/ru/post/649381/
Особенно актуально в UI-kit'ах
Не уверен, насчет определений, однако согласен с утверждением, о неравенстве.
В моем понимании:
Дизайн-система -- это набор правил и консистентность в цветах, отступах, комбинациях. Грубо говоря, когда говорят "У нас есть Дизайн-система", подразумевают наличие (или желание) имплементированной логики базовых элементов дизайна.
UI-kit -- это набор компонентов, которые могут следовать дизайн-системе. Однако, этот kit может быть имплементирован где угодно: в коде, графическом редакторе. В отличие от дизайн-системы -- UI-kit, это готовый к использованию набор элементов.
Цифра здесь скорее всего с потолка, однако, потерянное время на код-ревью может быть существенным. А одинаковость кода уменьшает когнитивную нагрузку. А этот фактор имеет долговременный эффект.
Будет горизонтальный скролл страницы на iOs, если не прикрыть
overflow: hidden;, который может обрезать тени, вызвать дополнительные визуальные баги или отсутствие работыbackdropFilter.А еще проблемы с
width: 100%;или необходимостьcalc()Да, вот что меня действительно раздражает, так этот момент, когда компонент написан, но тут возникает задача пробросить ref, и начинается синтаксический ад с forwardRef и Typescript. Пока все скобочки в нужном порядке расставишь, все желание кодить пропадает =)
Но по идее мы можем глобально расширить тип HTMLAttributes, либо же создать новый тип-дженерик, который принимал бы на вход параметры для data-атрибутов.
Вот пример (может кому пригодится), с глобальной модификацией:
Одно время я тоже ими пользовался, даже перевел статью про выход пятой версии. Однако, не очень гладкая интеграция с Mui четвертой версии заставила перейти на JSS объектный синтаксис. А сейчас, в пятой версии этой великолепной библиотеки, разработчики взяли emotion как решение по умолчанию.
Возможно, стоит задуматься о возврате к простому kebab-case синтаксису css без upperCase девиаций =)