После знакомства с Ангуляром мне в голову пришла следующая метафора.
Предположим, у нас есть некоторое приложение. Мы, как архитектор этого приложения, знаем как в нём организованы потоки данных. В приложении мы задекларировали эти потоки данных и то как их следует обрабатывать в виде некоторого кода. То есть у нас описаны некоторые конкретные блоки, которые связаны конкретными линиями-направлениями данных.
В противовес этому, Ангуляр представляет собой что-то вроде «множества универсум», где всё связано со всем. В первый момент это вызывает wow-эффект. В самом деле, путём нескольких деклараций и пары строк кода мы организовали полноценный ввод пользователя, обработку и автоматическое обновление представления (!). Но в дальнейшем становится ясно, что такая полносвязная схема имеет свои побочные негативные эффекты: низкая производительность и сложность восприятия.
Я был очень рад услышать, что идёт разработка Angular 2, который (как и обязано мажорному релизу) будет обладать существенными изменениями, и в частности упрощениями, выпиливанием целой кипы фич. Также, существует разработка angular-light, которая освещалась на Хабре и ознаменована той же цели: упростить и оздоровить Ангуляр.
После использования Ангуляра я пришёл к выводу, что лучше строить приложение, основываясь на явных потоках данных. Для этого лучше всего подходит идея FRP. Что замечательно, FRP прекрасно компонуется с существующими библиотеками (я считаю, компонуемость — это очень хороший признак действительно здоровой концепции), например, можно использовать jQuery для получения источников данных (пользовательские события, которые инициируют flow/поток), так и для отображения ($.text, $.html в конце цепочек), также FRP прекрасно дружит со всеми существующими шаблонизаторами.
В общем, явное лучше неявного, FRP и компонуемость это будущее.
Всё, что линкуется (статически или динамически) с кодом под GPL, тоже подпадает под действие GPL.
Означает ли это, что я не могу опубликовать своё приложение на Node.js на условиях GPL, потому как чуть более чем 95% моих зависимостей доступны под пермиссивными лицензиями (MIT)?
Clash in the Clouds отличное дополнение, его хорошо бы тоже в довесок портировать. Кто не пробовал, очень рекомендую: это мод-арена, по максимуму использующий экшн-составляющую игры. Всем ценителям конкретно боевой системы игры должно крайне понравиться.
А насколько востребованы такие сложные шаблоны формата? Я это к чему: в действительности у нас есть DOM. Обычно интерактивные элементы (типо счётчиков) находятся в собственных элементах и манипуляция с ними производится какой-то MV-либой, либо аналогичным ей самописным участком в кодобазе. То есть на практике может стать так, что нам нужно максимум зарегать функции из такой локализационной либы в качестве фильтров в MV.
Эти строки формата могут в полной мере раскрыться только в генерации на сервере, но в эпоху интерактивных/одностраничных/изоморфных (выбрать нужное) приложений, такой кейс становится всё более редким.
Всё зависит от степени фанбойства. Я играл в клубе, сидя на табуретке, за телевизором с кинескопом, у которого размер «зерна» на экране был такой, что я мог разглядеть его не вставая с табурета. Если уж говорить о восприятии, то может надо раскопать и телевизор тех лет? Я лично играю на эмуле, сидя за ЖК-дисплеем и даже немножко кастомным антиалиасингом. Ощущения есть: саундтрек, геймплей, вот это всё.
Нужно ли активировать стрим? Или он будет включаться автоматически?
Юзкейс следующий: предположим, я хочу чтобы мой стрим мог смотреть любой пользователь, но при этом я хочу стримить только отдельные сеансы игры.
У меня гибридное приложение Android/WebView не стартовало, пока я поочерёдно не указал кучу прав, которые этому приложению в действительности не нужны. В запале нашли аналогичную проблему, описанную на SO, там ответом тоже предлагалось дать приложению кучу прав. Быстро пофиксили, и забыли. А вообще надо разобраться, прилага совершенно локальная и куча прав ей абсолютно не нужна.
если создать внешнюю оболочку, способную держать жесткость при ударе
У меня была идея костюма, который не позволяет телу переходить в опасные для него позиции. То есть, допустим, двигаем мы рукой: пока движение в пределах безопасного костюм не затрудняет движений (насколько это возможно, конечно, с учётом некоторых потерь), а если, скажем, рука пытается перейти в какой-нибудь болевой скрут или перелом, то костюм мгновенно блокируется в граничном состоянии. В таком костюме, положим, в лотос не сядешь, но для боевых или производственных ситуаций это и не нужно. Вы о таком говорите?
Тут ещё интересный дальнеший вывод: если создать такой костюм, который позволит делать такие вещи, то при наращивании его прочности можно будет говорить, что он защищает от всего, кроме перегрузок.
Я и не говорю, что все привыкнут. Лично я в данном плане придерживаюсь позиции, что хорошо натюнингованная Лиса это всегда лучше чем workflow, навязанный авторами любого конкретного браузера (даже если workflow-то хороший). Так что макофильские замашки я сам особо не котирую. Но всё равно не могу отрицать, что работа проделана существенная, все изменения имеют некоторую идею за собой.
Цветовая маркировка вкладок — здравая. Это позволит серьёзно сократить время поиска нужной вкладки. Вот группирование вкладок лично я не люблю и никогда подобное не включаю. В своё время пользовался панорамой в Лисе, но сейчас просто стараюсь лимитировать количество одновременно читаемого контента (вкладок), это, кстати, хорошо сказывается на сосредоточенности.
Предположим, у нас есть некоторое приложение. Мы, как архитектор этого приложения, знаем как в нём организованы потоки данных. В приложении мы задекларировали эти потоки данных и то как их следует обрабатывать в виде некоторого кода. То есть у нас описаны некоторые конкретные блоки, которые связаны конкретными линиями-направлениями данных.
В противовес этому, Ангуляр представляет собой что-то вроде «множества универсум», где всё связано со всем. В первый момент это вызывает wow-эффект. В самом деле, путём нескольких деклараций и пары строк кода мы организовали полноценный ввод пользователя, обработку и автоматическое обновление представления (!). Но в дальнейшем становится ясно, что такая полносвязная схема имеет свои побочные негативные эффекты: низкая производительность и сложность восприятия.
Я был очень рад услышать, что идёт разработка Angular 2, который (как и обязано мажорному релизу) будет обладать существенными изменениями, и в частности упрощениями, выпиливанием целой кипы фич. Также, существует разработка angular-light, которая освещалась на Хабре и ознаменована той же цели: упростить и оздоровить Ангуляр.
После использования Ангуляра я пришёл к выводу, что лучше строить приложение, основываясь на явных потоках данных. Для этого лучше всего подходит идея FRP. Что замечательно, FRP прекрасно компонуется с существующими библиотеками (я считаю, компонуемость — это очень хороший признак действительно здоровой концепции), например, можно использовать jQuery для получения источников данных (пользовательские события, которые инициируют flow/поток), так и для отображения (
$.text,$.htmlв конце цепочек), также FRP прекрасно дружит со всеми существующими шаблонизаторами.В общем, явное лучше неявного, FRP и компонуемость это будущее.
Добавлю-ка энтропии habrahabr.ru/company/ibm/blog/201440/#comment_6958086.
Эти строки формата могут в полной мере раскрыться только в генерации на сервере, но в эпоху интерактивных/одностраничных/изоморфных (выбрать нужное) приложений, такой кейс становится всё более редким.
В двух предыдущих частях просто не было детей. В Daggerfall и Arena не знаю.
Юзкейс следующий: предположим, я хочу чтобы мой стрим мог смотреть любой пользователь, но при этом я хочу стримить только отдельные сеансы игры.
Тут ещё интересный дальнеший вывод: если создать такой костюм, который позволит делать такие вещи, то при наращивании его прочности можно будет говорить, что он защищает от всего, кроме перегрузок.
Цветовая маркировка вкладок — здравая. Это позволит серьёзно сократить время поиска нужной вкладки. Вот группирование вкладок лично я не люблю и никогда подобное не включаю. В своё время пользовался панорамой в Лисе, но сейчас просто стараюсь лимитировать количество одновременно читаемого контента (вкладок), это, кстати, хорошо сказывается на сосредоточенности.