Товарищи, кто-нибудь может подсказать нестандартные ноутбуки, у которых тачпад отсутствует как таковой, или хотя бы не занимает стандартное положение книзу от клавиатуры?
Я лично недолюбливаю ноутбуки, потому что не могу достичь комфортного положения рук на их клавиатуре, отчего удобство ввода значительно страдает. Если бы не было тачпада внизу (и всей этой панели), а сразу начиналась клавиатура, то было бы очень удобно. Пока что из таких ноутбуков я видел лишь Acer Aspire R7. В принципе, остальные его фичи, типо подвижного экрана меня не интересуют, а вот положение тачпада (кверху от клавиатуры) меня заинтересовало. Если кто знает подобные и другие решения с кастомным тачпадом или без него, буду рад ознакомиться.
Если кто будет интересоваться этим вопросом, то вот тема на SO: why ng-bind is better than {{}} in angular?. Обратите внимание не только на лучший ответ, а также и на другие.
Действительно, ng-cloak лишь косметический приём, производительность директив выше, чем скобочных выражений.
Это допустительная заморозка (да и не глубокая), при попытке изменить свойство у замороженного объекта ничего не произойдёт. Всмысле, вообще ничего, ни эксепшена, ничего. Эффекта можно достичь только в strict-mode.
В обычном же режиме, смысла от такой иммутабельности чуть более, чем нет, потому как мы уже склонировали объект.
Object.freeze и Object.seal как бы есть, но они сами являются изменяющими, т.е. они работают на объекте, а не создают иммутабельную копию. Поэтому всё равно нужно предварительно склонировать объект, а раз уж мы его склонировали, то его изменение нам не страшно и Object.freeze как бы опционален (по сути, он ничем не превосходит возможности конвенции).
В javascript не получится сделать жесткой иммутабельности. Все равно будет возможность что-то поменять. Так что это вопрос конвенции.
Насчёт конвенции вы очень верно подметили. В JS очень много вещей отданы на откуп конвенции. Но всё-таки жёсткую иммутабельность для plain-object можно сделать путём глубокого клонирования. Тем не менее, это выходит дороговато, поэтому соглашения тут выигрывают.
По поводу __proto__: MDN __proto__.
Для создания объекта с заданным прототипом нужно использовать Object.create:
// строку
var result = new Object();
// заменяем на
var result = Object.create(obj);
// строку
// result.__proto__ = obj;
// убираем
Object.create просто создаёт объект с заданным прототипом. А __proto__ это internal свойство, поэтому его использование некорректно.
Это не иммутабельность, если оригинальный user доступен. Также будут неожиданные последствия при модификации вложенных свойств.
Вместо __proto__ следует использовать Object.create.
А вообще, есть подобная идея, но для внутренних структур данных ЯП, которые будут делать экономное клонирование.
Пользовался Cordova. Всё нравится, система делает то, что заявлено: позволяет создавать проекты на вебстеке. При этом сборка, деплой на устройство делается в одну команду. Доступны плагины, которые делают доступным для JS-рантайма аппаратные фичи платформы (и не только). Установка плагинов также очень проста. Выбор платформ для деплоя тоже прост, количество платформ поражает воображение (если при этом на них ещё и будет работать, то вообще потрясно).
Cordova не обязывает ко многим вещам. От разработчика требуется предоставить главный html-файл, в котором указать скриптовый файл cordova.js. Система использует переданный файл в качестве стартового для WebView, а файл скрипта предоставит API платформы. Совершенно не ограничиваются какие бы то ни было веб-библиотеки/фрейворки. Всё ограничивается только возможностями целевого WebView (к примеру, iOS / Android поддерживают flexbox, но старые модели андроида имеют частичную поддержку).
Определённо, Cordova позволяет веб-разработчику начать делать реальное мобильное приложение ещё не обладая специфическими знаниями мобильных платформ.
Какие отношения между Cordova и PhoneGap? Кто на ком создан/от кого отпочковался/никак не связан/совместим? Я всегда считал, что PhoneGap раньше Cordova появился (и второй просто совместим по API с первым), а тут выясняется, что PhoneGap наследник Cordova.
В таком деле как выравнивание хорошо знать меру. Лично я выравниваю, но если строки не слишком «разбежались», в противном случае от выравнивания получается не польза, а вред, т.к. читаемость, наоборот, падает.
Например, я выравниваю, если у меня есть два схожих выражения, в которых длины имён переменных отличаются на 1..2 символа. Тогда можно добить одну из строк, чтобы привести её в соответствие с другой. Если же есть блок объявления переменных, в котором одна переменная имеет, скажем, четыре символа в имени, а другая 15, то я не буду выравнивать значения по умолчанию, просто потому что это один блок. Плюс, если придёт ещё одна переменная, ещё более длинная, то две предыдущих декларации придётся приводить в соответствие.
Короче, иногда, такое выравнивание может привнести в читаемость плюсы, и я считаю, что было бы очень круто эту технику знать. Но с другой стороны, её возможности далеко не безграничны.
Всё описанное в статье (включая мощную систему типов, обобщения с ограничениями, интерфейс Iterable для реализации типов с поддержкой for-each, ковариацию и контравариацию, отсутствие nil) есть в языке Ceylon (http://ceylon-lang.org/). При этом язык уже добрался до 1.0.
По непонятной для меня причине, информационные источники обходят этот язык стороной. Единственное моё предположение, что причина это JVM (хотя Scala и Clojure всё-таки более-менее известны). Кроме JVM в качестве бэкенда поддерживается JS, у авторов есть мысли по поддержке LLVM.
Рекомендую всем, у кого есть время и интерес в подобных языках, ознакомиться. Просто не мог пройти мимо статьи, в которой опять обделили Ceylon.
Ох, давно мне нигде не попадалась эта цитата, здесь, думаю, будет уместно:
Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
Во многом, но не во всём. В инфраструктуре ноды тоже есть некоторые проблемы, в частности, он кстати упомянул некоторые невыразительные ошибки.
Я думаю, потому и заняло много времени, что он считает существенными не столько архитектурные недостатки JS, сколько недостатки ноды.
Почитаю про него, спасибо.
Я лично недолюбливаю ноутбуки, потому что не могу достичь комфортного положения рук на их клавиатуре, отчего удобство ввода значительно страдает. Если бы не было тачпада внизу (и всей этой панели), а сразу начиналась клавиатура, то было бы очень удобно. Пока что из таких ноутбуков я видел лишь Acer Aspire R7. В принципе, остальные его фичи, типо подвижного экрана меня не интересуют, а вот положение тачпада (кверху от клавиатуры) меня заинтересовало. Если кто знает подобные и другие решения с кастомным тачпадом или без него, буду рад ознакомиться.
Действительно, ng-cloak лишь косметический приём, производительность директив выше, чем скобочных выражений.
В обычном же режиме, смысла от такой иммутабельности чуть более, чем нет, потому как мы уже склонировали объект.
По поводу __proto__: MDN __proto__.
Для создания объекта с заданным прототипом нужно использовать Object.create:
Object.create просто создаёт объект с заданным прототипом. А __proto__ это internal свойство, поэтому его использование некорректно.
Вместо __proto__ следует использовать Object.create.
А вообще, есть подобная идея, но для внутренних структур данных ЯП, которые будут делать экономное клонирование.
Cordova не обязывает ко многим вещам. От разработчика требуется предоставить главный html-файл, в котором указать скриптовый файл cordova.js. Система использует переданный файл в качестве стартового для WebView, а файл скрипта предоставит API платформы. Совершенно не ограничиваются какие бы то ни было веб-библиотеки/фрейворки. Всё ограничивается только возможностями целевого WebView (к примеру, iOS / Android поддерживают flexbox, но старые модели андроида имеют частичную поддержку).
Определённо, Cordova позволяет веб-разработчику начать делать реальное мобильное приложение ещё не обладая специфическими знаниями мобильных платформ.
Например, я выравниваю, если у меня есть два схожих выражения, в которых длины имён переменных отличаются на 1..2 символа. Тогда можно добить одну из строк, чтобы привести её в соответствие с другой. Если же есть блок объявления переменных, в котором одна переменная имеет, скажем, четыре символа в имени, а другая 15, то я не буду выравнивать значения по умолчанию, просто потому что это один блок. Плюс, если придёт ещё одна переменная, ещё более длинная, то две предыдущих декларации придётся приводить в соответствие.
Короче, иногда, такое выравнивание может привнести в читаемость плюсы, и я считаю, что было бы очень круто эту технику знать. Но с другой стороны, её возможности далеко не безграничны.
По непонятной для меня причине, информационные источники обходят этот язык стороной. Единственное моё предположение, что причина это JVM (хотя Scala и Clojure всё-таки более-менее известны). Кроме JVM в качестве бэкенда поддерживается JS, у авторов есть мысли по поддержке LLVM.
Рекомендую всем, у кого есть время и интерес в подобных языках, ознакомиться. Просто не мог пройти мимо статьи, в которой опять обделили Ceylon.
Я думаю, потому и заняло много времени, что он считает существенными не столько архитектурные недостатки JS, сколько недостатки ноды.