В таком варианте было бы здорово, конечно! Но даже не знаю, насколько это реально в принципе, потому что VR-очки должны покрывать большой угол обзора. Т.е. экран должен быть очень широким. Если только будет придумана какая-то технология, которая решит эту задачу каким-то иным образом.
Про пункты 1, 2 и 3 — это просто боль :) Но такова, видимо, человеческая природа, приходится это принимать и терпеливо вытаскивать из людей всё, что необходимо, повторяя вопрос по 10 раз.
Я тоже тестил некоторые из этих приложений. Но вот главное выбранное вами — Spatial — не доводилось, с интересом пощупаю. Мои личные ощущения — это всё круто и меня пока приводит в восторг. Horizon Workrooms нравится визуально-эстетически.
Надеюсь, все эти шлемы будут уменьшаться в толщине и весе постепенно, разрешение будет увеличиваться и т.д.
Видеочаты передают видео, поэтому тормоза. Здесь же передаются легковесные значения — позиционирование человека и т.д. В общем, чисто математика. Плюс аудио, конечно. У меня не было опыта, чтобы что-то серьёзно запаздывало. Но конечно, всё будет зависеть от скорости интернета.
У контроллера довольно толстая рукоятка. Но на практике это вполне функционально, рисовать получается. Мельчить, конечно, не получится.
Устают ли глаза — лично у меня обычно не устают. Но некоторые особо чувствительные люди жалуются, им не очень комфортен VR как таковой. Поэтому тут всё индивидуально.
Не увидел в статье эзотерики (в плане мистики), если честно, но домыслы и собственный анализ — это да.
К вашему списку книг ещё бы добавил:
«Победи прокрастинацию» Петра Людвига — небольшая и очень дельная книга, где автор опирается на исследования и лучшие практики, ну и теория тоже есть: лимбическая система, неокортекс и т.д.
«Терапия настроения» Дэвида Бернса — в одной из глав автор подробно пишет о прокрастинации в контексте депрессии, в целом книга посвящена методу когнитивно-поведенческой терапии.
Важность личного осмысления никто не отменял, но да, гораздо эффективней обратиться к научным исследованиям и наработкам в этой теме.
Я для себя называл «базовой платформой» то, что автор называет здесь «зверем». На мой взгляд, нельзя эту нашу часть слишком примитивизировать и относиться к ней высокомерно или пренебрежительно (у многих есть такое из-за затяжного конфликта с этой частью себя; плюс влияние стереотипа «зверь»). Но… там тысячи лет эволюции, она часто бывает мудрее, чем наше сознательное понимание и целеполагание, и вообще обычно сопротивляется неспроста. Мы склонны забывать про её РЕАЛЬНЫЕ потребности — пренебрегаем отдыхом, заставляем себя подолгу заниматься тем, что нам реально не по душе (длинные и очень сложные рабочие задачи, например). Да даже живём зачастую не той жизнью, которой хотелось бы, но это отдельная большая тема. Эта наша часть вообще не всегда про примитивные (ну условно) удовольствия. Мотивировать её вкусняшками… ну такое себе. Мне зачастую энергию для действия даёт отдых, возвращение внимания к себе, забота о себе, качественное общение и т.д., а вот примитивные удовольствия — в гораздо меньшей степени. Т.е. нужно смотреть на реальные потребности тела и психики, налаживать контакт с собой. «Обманывать» зверя, как пишет автор, — на мой взгляд, это шаг к разладу. Ставить себе задачу «запустить IDE» и награждать себя за это — это уже признак того, что что-то не так, и борьба со следствием.
Там написано, что это будет новый шрифт и он будет опубликован в скором времени. Но как минимум сейчас замечательный Fira Code (https://github.com/tonsky/FiraCode) умеет лигатуры.
Если вы про момент «ul > li, table td» — я также где-то в документации об этом читал, что в некоторых случаях это допустимо. Сейчас не могу найти. Если мне это вдруг показалось, поправьте меня. Или вы меня просто неправильно поняли? Смысл в том, что если я создаю блок-таблицу, в которой — я точно знаю — никаких других вложенных таблиц использоваться не будет, то будет избыточно навешивать на каждый tr и td дополнительный класс элемента, т.к. эти узлы уже связаны с родительским узлом, уже сами по себе семантичны, дополнительной семантики навешиванием класса не требуется. Возможно, это не суперстрого по суперстрогому БЭМ, но вполне допустимо при ручном применении БЭМ, о чем и была речь.
О типографике внутри блока докладчик также упоминает. Так в чем же не БЭМ?
Они не лезут вовне контейнера, но лезут внутрь, во вложенные контейнеры. Вы же можете использовать вложенные блоки (если использовать терминологию БЭМ). А что, если внутри этих блоков используются элементы с одинаковыми именами классов? Тогда CSS, примененный к элементу внешнего блока, будет влиять на элементы внутреннего блока, и вам придется бороться с этими стилями. Как вариант — использовать “>” в селекторе. Но тогда встает следующая проблема — если структура блока достаточно сложная, то вам придется использовать умопомрачительные конструкции типа > div > div > div > .element. Селекторы превращаются в жуть, и вы также завязываетесь на структуру блока. Модификация структуры блока будет означать необходимость внимательного и порой напряженного отслеживания отражения этой структуры в CSS.
С другой стороны, использование именования по БЭМ позволяет решить вышеописанную проблему изящным способом. У вас нет жуткой многоэтажной структуры селекторов, элементы вложенных блоков не влияют друг на друга, и бонусом — вы сразу видите, к какому блоку принадлежит данный элемент, когда, например, инспектируете страницу. А еще бонусом — ускорение рендеринга страницы (не нужно недооценивать — в некоторых сложных верстках весьма ощутимое).
Единственное, с чем я могу согласиться, что именование БЭМ выглядит довольно пугающе. Я решил лично для себя эту проблему тем, что именую блоки, элементы и модификаторы по-своему. Например:
Menu — блок;
Menu-item — элемент блока;
Menu--fixed — модификатор.
Я не использую bem-tools, а пишу код традиционно, поэтому для меня читабельные имена классов очень важны. И я пришел к такому компромиссу. Ну и в некоторых случаях действительно красивее и правильнее будет использовать просто вложенные селекторы — типа ul > li, table td и т.д., т.к. они не нуждаются в дополнительном именовании. Например, задавая типографику внутри контента статьи, да и порой в других случаях. Тут нужно смотреть по ситуации, без фанатизма.
Главное — понять, какие проблемы решает БЭМ и взять полезное из его методологии. Не нужно считать популярность БЭМа исключительно следствием продвижения его Яндексом и недооценивать сознательность использующих его разработчиков.
Не мной, а автором Vue. Я всего лишь перевел (так сказать, для полноты картины).
Я-то вообще «ровен» к разным библиотекам и ни в коем случае на агитирую за Vue и против Riot.
Спасибо за ваше дополнение. Лично я обязательно взгляну на Riot поближе.
Кстати, на сайте Vue есть сравнение и с Riot: vuejs.org/guide/faq.html.
По какой-то причине не вошло в перевод. Переведу:
Riot 2.0 предоставляет схожую модель, основанную на компонентах (в Riot они называются тегами — “tag”), с минимальным и прекрасно спроектированным API. Я думаю, что Riot и Vue разделяют многие архитектурные принципы. Тем не менее, несмотря на то, что Vue является чуть более «тяжелым», чем Riot, он также предлагает некоторые существенные преимущества:
Настоящий условный рендеринг (Riot выводит все “if” ветки и просто прячет / показывает их);
Значительно более мощный ротер (API роутинга, предоставляемый Riot, просто крайне минимальный);
Более зрелая поддержка инструментов (см. webpack + vue-loader);
Система «эффектов перехода» (transition effect) (Riot не имеет таковой);
Лучший статус поддержки (на 31 августа 2015 г. Riot имеет 25 открытых багов, в то время как у Vue их 0);
Лучшая производительность (Riot, по факту, использует скорее прямую проверку (dirty checking), чем virtual-dom, и потому страдает от тех же проблем с производительностью, что и Angular).
От себя могу добавить, что автор Vue действительно крайне оперативно реагирует на задачи. Как-то я написал ему о встреченном баге, и он буквально тут же его исправил.
Но отметить всё же надо, что микрофон в Oculus Quest 2 очень приличный. Я записывал видео и отметил для себя, как же чётко и чисто пишется голос.
В таком варианте было бы здорово, конечно! Но даже не знаю, насколько это реально в принципе, потому что VR-очки должны покрывать большой угол обзора. Т.е. экран должен быть очень широким. Если только будет придумана какая-то технология, которая решит эту задачу каким-то иным образом.
Про пункты 1, 2 и 3 — это просто боль :) Но такова, видимо, человеческая природа, приходится это принимать и терпеливо вытаскивать из людей всё, что необходимо, повторяя вопрос по 10 раз.
Я тоже тестил некоторые из этих приложений. Но вот главное выбранное вами — Spatial — не доводилось, с интересом пощупаю. Мои личные ощущения — это всё круто и меня пока приводит в восторг. Horizon Workrooms нравится визуально-эстетически.
Надеюсь, все эти шлемы будут уменьшаться в толщине и весе постепенно, разрешение будет увеличиваться и т.д.
Видеочаты передают видео, поэтому тормоза. Здесь же передаются легковесные значения — позиционирование человека и т.д. В общем, чисто математика. Плюс аудио, конечно. У меня не было опыта, чтобы что-то серьёзно запаздывало. Но конечно, всё будет зависеть от скорости интернета.
У контроллера довольно толстая рукоятка. Но на практике это вполне функционально, рисовать получается. Мельчить, конечно, не получится.
Устают ли глаза — лично у меня обычно не устают. Но некоторые особо чувствительные люди жалуются, им не очень комфортен VR как таковой. Поэтому тут всё индивидуально.
ru.wikipedia.org/wiki/Псевдонаука
Эзотерика:
ru.wikipedia.org/wiki/Эзотеризм
Эзотерика — это про тайные духовные и мистические учения и практики. Вы же пишете про псевдонауку.
К вашему списку книг ещё бы добавил:
Важность личного осмысления никто не отменял, но да, гораздо эффективней обратиться к научным исследованиям и наработкам в этой теме.
По поводу других вариантов именования блоков, элементов и модификаторов:
ru.bem.info/method/naming-convention/#Альтернативные-схемы-именования
Если вы про момент «ul > li, table td» — я также где-то в документации об этом читал, что в некоторых случаях это допустимо. Сейчас не могу найти. Если мне это вдруг показалось, поправьте меня. Или вы меня просто неправильно поняли? Смысл в том, что если я создаю блок-таблицу, в которой — я точно знаю — никаких других вложенных таблиц использоваться не будет, то будет избыточно навешивать на каждый tr и td дополнительный класс элемента, т.к. эти узлы уже связаны с родительским узлом, уже сами по себе семантичны, дополнительной семантики навешиванием класса не требуется. Возможно, это не суперстрого по суперстрогому БЭМ, но вполне допустимо при ручном применении БЭМ, о чем и была речь.
О типографике внутри блока докладчик также упоминает. Так в чем же не БЭМ?
С другой стороны, использование именования по БЭМ позволяет решить вышеописанную проблему изящным способом. У вас нет жуткой многоэтажной структуры селекторов, элементы вложенных блоков не влияют друг на друга, и бонусом — вы сразу видите, к какому блоку принадлежит данный элемент, когда, например, инспектируете страницу. А еще бонусом — ускорение рендеринга страницы (не нужно недооценивать — в некоторых сложных верстках весьма ощутимое).
Единственное, с чем я могу согласиться, что именование БЭМ выглядит довольно пугающе. Я решил лично для себя эту проблему тем, что именую блоки, элементы и модификаторы по-своему. Например:
Menu — блок;
Menu-item — элемент блока;
Menu--fixed — модификатор.
Я не использую bem-tools, а пишу код традиционно, поэтому для меня читабельные имена классов очень важны. И я пришел к такому компромиссу. Ну и в некоторых случаях действительно красивее и правильнее будет использовать просто вложенные селекторы — типа ul > li, table td и т.д., т.к. они не нуждаются в дополнительном именовании. Например, задавая типографику внутри контента статьи, да и порой в других случаях. Тут нужно смотреть по ситуации, без фанатизма.
Главное — понять, какие проблемы решает БЭМ и взять полезное из его методологии. Не нужно считать популярность БЭМа исключительно следствием продвижения его Яндексом и недооценивать сознательность использующих его разработчиков.
Не мной, а автором Vue. Я всего лишь перевел (так сказать, для полноты картины).
Я-то вообще «ровен» к разным библиотекам и ни в коем случае на агитирую за Vue и против Riot.
Спасибо за ваше дополнение. Лично я обязательно взгляну на Riot поближе.
По какой-то причине не вошло в перевод. Переведу:
От себя могу добавить, что автор Vue действительно крайне оперативно реагирует на задачи. Как-то я написал ему о встреченном баге, и он буквально тут же его исправил.