Скорее было бы клёво почитать ребят, которые начали играться с LeapMotion. Сенсорные панели уже не тот UX.
Сразу вспоминаю сцену из Мстителей, где Тони раскидал содержимое папки на воздух.
Это специализированный вариант браузера Chromium, переделанный так, чтобы быть в первую очередь текстовым редактором, а не веб-браузером. Каждое окно Atom — это отдельная локальная веб-страница.
То есть это node-webkit (или это самописный аналог)?
Кто-нибудь уже получил инвайт?
Похоже, я вас не понял. Мой поинт в том, что если зависимость есть, то в FRP она будет выражена явно, в виде формулы. В событийной схеме — нет. А зависимости есть всегда. Если в нашей модели компонент Б зависит от компонента А, то в FRP, в коде, мы получим ровно эту зависимость. Это не является сильной связанностью.
мы получаем некоторые сложности при разработке или адаптации на проекте
По-моему, наследником событий является FRP. Это, по сути, те же самые подписки, но «в другую сторону». Плюс в том, что FRP в коде как раз и выражает (практически дословно) кто на кого подписан.
А описанный вами минус — неопределенность триггеров и подписчиков — по мне вообще является плюсом событийной модели, потому что как раз независимость источника от приёмников события (да и наоборот) как раз постулируется как преимущество подписки в противовес прямому вызову.
/lib
Сюда можно положить свои и сторонние библиотеки
Чем обусловлено желание складывать библиотеки в libs? Можно складывать их в node_modules, оформлять минимальный пакет и получать возможность require из любого места проекта.
По моему мнению основная проблема не в самом :hover, а в том, что он не подходит для модели тач-устройств. Скорее нужно перерабатывать UI под тач-устройства идеологически. Приведу очень грубый пример: показываем некоторый вспомогательный элемент по hover. Тач-вариант: показываем его в дефолтном состоянии. Да, интерфейс станет более загруженным (разной степени загруженности, в зависимости от количества элементов с таким поведением), но и более понятным в тач-варианте: исчезнет целый промежуточный шаг с наведением. Безусловно, задача это нетривиальная и требует неслабой проектировки и продумывания.
Кстати, аналогичным образом работают и всплывающие подсказки: на устройствах с курсором всплывающие подсказки весьма удобны, они не загромождают интерфейс (т.к. не видны постоянно), но дают моментальную контекстную помощь по практически любому элементу. На тач-девайсах это не работает. Я думаю, в результате появились гайды, которые появляются при первом старте приложения. Во многом они повторяют те самые старые добрые всплывающие подсказки, но отображаются все и сразу, одной серией, потому что после не будет возможности их показать.
трёхмерный эффект создан путём простого добавления двух вертикальных белых линий
В то время как комментаторы справедливо замечают, что эффект достигается не путём создания этих линий, а путём выведения некоторых объектов на передний план. Здесь фактическая ошибка.
А то, что кто-то заметил (несмотря на ошибку в тексте), то они молодцы.
Я тут с вами согласен:
По идее, любой объект со значимой структурой можно вместо представления одним файлом, представить иерархией, где нижележащие файлы будут предоставлять доступ к отдельным (атомарным) параметрам. При этом, imo, не ломается принцип «всё есть файл», просто мы получаем что что-то является не одним файлом, а несколькими. При этом всё остаётся файлами.
Я также считаю, что можно пойти далее и обобщить: «всё есть поток». Потоки можно разделить на ввод и вывод и работать с ними через унифицированный интерфейс. По сути это FRP.
Больше спасибо за статью, обязательно прочитаю и все остальные части.
Тема очень интересная и я в свободное время ей занимаюсь.
Когда-то я писал движок вики-подобного языка разметки. Первая ошибка, которую я допустил было смешивание уровней токенизации и построения дерева из последовательности токенов (т.е. tokenizer / lexer). Полученная штука была жутковатой, в частности, её было сложно модифицировать, было множество специальных кейсов, введение новых синтаксисов вводило новые специальные кейсы и ломало работу уже существующих.
Потом я писал шаблонизатор, в нём я осуществил разбивку этих двух этапов, в результате код стал очень простой и здоровый. Собственно, этот шаг мне видится разумным, но есть один связанный вопрос, который меня занимает.
Предположим у нас есть некоторый ЯП. Что считать токеном? Пусть в ЯП есть литералы строк: набор символов заключённых в двойные кавычки. По сути, это может быть один токен, который достаточно легко описать одной регуляркой (если регулярки поддерживают ленивость). Но если пойти дальше, то оказывается, что внутри строки тоже не всё так просто, могут быть эскейп последовательности, существует интерполяция. НО при этом внутри строки не действуют обычные токены языка. То есть внутри строки нет for, if, нет чисел и нет других строк. И ещё там важны пробелы, т.е. это значащие символы. Это означает, что токен строки это отдельный подъязык со своей грамматикой.
Получается, что на этапе токенизации мы должны заморачиваться с каким-то переключением контекста итп вещами, хотя этот этап должен быть очень простым. Налицо анализ последовательности токенов. То есть уровни всё таки как-то проникают друг в друга!? Мой вопрос в том, как разрешается это затруднение? Где кончается токенизация и начинается синтаксический анализ?
Понял вас. Собственно, я так и предполагал, хотя на мгновение у меня была мысль, что они использовали какой-то хитрый способ создания фокуса на произвольный DOM. Это позволило бы делать фокус на «виджетах». И свой набор комбинаций в рамках одного виджета.
но и для одного или нескольких отдельных элементов DOM
Для каких конкретно элементов? Подразумеваются элементы формы, которые могут принимать фокус, или произвольные куски DOM? В случае последнего: на чём основывается работа этого?
Продолжая об удобстве программиста, я всегда считал, что нумерация с единицы это здорово, потому что тогда можно использовать 0 в качестве индикатора отсутствия результата, который имеет тривиальную проверку в блоке if. Сейчас же нужно сравнивать с какой-то иной константой (например -1), что визуально загрязняет проверку.
С другой стороны в строготипизированных языках это «слишком нестрого», и если есть типы-объединения, то можно пойти ещё дальше и возвращать какой-нибудь Either<Index, Nothing> там, где индекс может быть, а может не быть.
Это мастхев фича. В языках новой волны требования к параметрам обобщений стараются делать сразу в основе языка.
Например в Rust это сделано через трейты/типажи.
В языке Ceylon более многословно, но и достаточно читабельно, через специальное ключевое слово. В последнем есть также поддержка ковариантности и контравариантности через ключевые слова out и in.
Сразу вспоминаю сцену из Мстителей, где Тони раскидал содержимое папки на воздух.
Ещё бы простую и логичную рисовалку SVG, которая генерит чистый код, вообще был бы день редакторов.
Кто-нибудь уже получил инвайт?
О каких сложностях идёт речь?
А описанный вами минус — неопределенность триггеров и подписчиков — по мне вообще является плюсом событийной модели, потому что как раз независимость источника от приёмников события (да и наоборот) как раз постулируется как преимущество подписки в противовес прямому вызову.
Чем обусловлено желание складывать библиотеки в libs? Можно складывать их в node_modules, оформлять минимальный пакет и получать возможность require из любого места проекта.
Кстати, аналогичным образом работают и всплывающие подсказки: на устройствах с курсором всплывающие подсказки весьма удобны, они не загромождают интерфейс (т.к. не видны постоянно), но дают моментальную контекстную помощь по практически любому элементу. На тач-девайсах это не работает. Я думаю, в результате появились гайды, которые появляются при первом старте приложения. Во многом они повторяют те самые старые добрые всплывающие подсказки, но отображаются все и сразу, одной серией, потому что после не будет возможности их показать.
В то время как комментаторы справедливо замечают, что эффект достигается не путём создания этих линий, а путём выведения некоторых объектов на передний план. Здесь фактическая ошибка.
А то, что кто-то заметил (несмотря на ошибку в тексте), то они молодцы.
По идее, любой объект со значимой структурой можно вместо представления одним файлом, представить иерархией, где нижележащие файлы будут предоставлять доступ к отдельным (атомарным) параметрам. При этом, imo, не ломается принцип «всё есть файл», просто мы получаем что что-то является не одним файлом, а несколькими. При этом всё остаётся файлами.
Я также считаю, что можно пойти далее и обобщить: «всё есть поток». Потоки можно разделить на ввод и вывод и работать с ними через унифицированный интерфейс. По сути это FRP.
Это лучше перевести как «путём продвижения активной точки на следующую позицию».
Тема очень интересная и я в свободное время ей занимаюсь.
Когда-то я писал движок вики-подобного языка разметки. Первая ошибка, которую я допустил было смешивание уровней токенизации и построения дерева из последовательности токенов (т.е. tokenizer / lexer). Полученная штука была жутковатой, в частности, её было сложно модифицировать, было множество специальных кейсов, введение новых синтаксисов вводило новые специальные кейсы и ломало работу уже существующих.
Потом я писал шаблонизатор, в нём я осуществил разбивку этих двух этапов, в результате код стал очень простой и здоровый. Собственно, этот шаг мне видится разумным, но есть один связанный вопрос, который меня занимает.
Предположим у нас есть некоторый ЯП. Что считать токеном? Пусть в ЯП есть литералы строк: набор символов заключённых в двойные кавычки. По сути, это может быть один токен, который достаточно легко описать одной регуляркой (если регулярки поддерживают ленивость). Но если пойти дальше, то оказывается, что внутри строки тоже не всё так просто, могут быть эскейп последовательности, существует интерполяция. НО при этом внутри строки не действуют обычные токены языка. То есть внутри строки нет for, if, нет чисел и нет других строк. И ещё там важны пробелы, т.е. это значащие символы. Это означает, что токен строки это отдельный подъязык со своей грамматикой.
Получается, что на этапе токенизации мы должны заморачиваться с каким-то переключением контекста итп вещами, хотя этот этап должен быть очень простым. Налицо анализ последовательности токенов. То есть уровни всё таки как-то проникают друг в друга!? Мой вопрос в том, как разрешается это затруднение? Где кончается токенизация и начинается синтаксический анализ?
Заранее спасибо.
tabindexработает только для форм, точнее, элементов ввода.Для каких конкретно элементов? Подразумеваются элементы формы, которые могут принимать фокус, или произвольные куски DOM? В случае последнего: на чём основывается работа этого?
if. Сейчас же нужно сравнивать с какой-то иной константой (например -1), что визуально загрязняет проверку.С другой стороны в строготипизированных языках это «слишком нестрого», и если есть типы-объединения, то можно пойти ещё дальше и возвращать какой-нибудь
Either<Index, Nothing>там, где индекс может быть, а может не быть.Например в Rust это сделано через трейты/типажи.
В языке Ceylon более многословно, но и достаточно читабельно, через специальное ключевое слово. В последнем есть также поддержка ковариантности и контравариантности через ключевые слова out и in.
Справедливости ради стоит отметить, что я не ставлю в /usr через make install. Обычно ставлю в /opt или ~/opt.
Да и ряд более редкого софта тоже, бывает, приходиться собрать.