Как то не вяжется тонкая настройка, в контексте HTML5 и использования для этого С++ :-). А так да — Студия позволяет редактировать исходный код не только C++.
Там все равно что писать. Вот зачем sleep(1), когда спокойно хватило бы и sleep(1000). Да и можно было прицепиться на служебные пины RTS CTS и вообще ничего не писать в порт, и обойтись без цикла. Но и так неплохо.
И опять двойка. :-)
Имеется ввиду защита от такого: > var a = { b:'b'}; > for(var i in a) console.log(i); b > Object.prototype.c = 'c'; > for(var i in a) console.log(i); b c
По Windows iPXE образы пришлось подбирать — одна машина грузилась только с kkpxe, другая только с kpxe. Они там что то патчат при загрузке. Т.е. подключение на int 80h это в некотором смысле хак.
Как раз недавно игрался с бездисковой загрузкой. Только грузил Win 7 с iSCSI target. А ubuntu просто по NFS. Спасибо — про debootstrap не знал. По обеим темам есть неплохие пошаговые руководства в сети. Гораздо интереснее, мне лично, вопрос как правильно настроить образ системы, чтобы с него безболезненно могло грузиться много машин. Для Windows наверно проще всего держать разные образы под разные машины и хранить их в файловой системе поддерживающей дедупликацию. Хотя вот тоже вопрос… Можно ведь сделать и общий ридонли образ, вайл подкачки отключать, а данные специфичные для каждой машины перенаправлять на меньший индивидуальный раздел. Короче эта тема интересней :-)
А это хитрость такая использовать arguments в качестве формального аргумента или просто плохой стиль?
И еще не понял смысла первого заворота в nextTick.
Это все замечания к функции all.
Все равно я не понимаю как это работает с прототипами. Ну, допустим, если у меня простое свойство, тогда все понятно изменяя scope мы изменим только его свойство, а старое останется в прототипе. Но если у меня в scope массив и я сделаю в него push, я же изменю массив в прототипе, и вся магия развалится.
Вы так ссылаетесь на эти нюансы, как будто там написана истина в последней инстанции. К сожалению не могу привести ответную ссылку. Могу сказать только что утверждения там спорные:
1. Насчет POJO — это не совсем верно, поскольку в контроллер нам подсовывают клон объекта с предыдущей итерации. Или я не понимаю как это работает. Про клонирование, кстати, ни слова не сказано. Впрочем, да может быть POJO это лучше чем необходимость объявлять объекты особого типа, но опять же это не объект, который мы создаем сами. И кстати эти контроллеры в глобальном пространстве имен выглядят подозрительно. Надеюсь, их можно спрятать.
2, Насчет того что множественное обновление массива вызывает обновление UI на каждой итерации. Так это легко обходится. И есть выбор — обновлять для каждого или для всех. Что в Angular на этот счет?
В общем я думаю подход Angular vs Knockout это тема скорее для холивара. Потому что объективных преимуществ нет ни у того ни у другого. Я говорю именно о подходе. Angular несомненно более развитый фреймфорк в целом.
Просто Knockout не дает готового решения как структурировать свое приложение. Это оставлено на откуп разработчика.
Кому то достаточно сделать простую модель, а кому то надо делать сложное приложение. И с Knockout можно избежать каши, просто рецепта нет. В этом есть как положительные так и отрицательные моменты. То же относится и к AngularJS — вам дают готовый рецепт структурирования и у этого подхода тоже есть плюсы и минусы.
Ничего не путаю. Может он там и контролирует что-то, но не реальную картинку с DMP. У меня на столе стоит DMP4400. Я на 100% уверен, что скриншот с него по сети взять нельзя. Возможно есть новые прошивки. Возможно это проблема именно DMP4400, есть и другие плееры. Может что-то поменялось. Мой проект с Cisco закончился в прошлом году.
по-моему нормальная производительность — Fiddle
Имеется ввиду защита от такого:
> var a = { b:'b'};> for(var i in a) console.log(i);b> Object.prototype.c = 'c';> for(var i in a) console.log(i);bcif (с.hasOwnProperty(v)) this[v] = c[v];а то что сейчас лишено смысла.
hasOwnPropertyвот в этом кусочке не помешала быfor(var v in c) { this[v] = c[v]; }По Windows iPXE образы пришлось подбирать — одна машина грузилась только с kkpxe, другая только с kpxe. Они там что то патчат при загрузке. Т.е. подключение на int 80h это в некотором смысле хак.
по Windows 7:
www.thogan.com/site2/archives/10
jonmccune.wordpress.com/2011/12/19/diskless-windows-7-with-iscsi-and-gpxe/
По убунте:
help.ubuntu.com/community/DisklessUbuntuHowto
мне во всяком случае хватило. По убунте использовал еще одно. Не могу сейчас найти.
Да не все заработало сразу как по маслу, но справился.
argumentsв качестве формального аргумента или просто плохой стиль?И еще не понял смысла первого заворота в nextTick.
Это все замечания к функции
all.1. Насчет POJO — это не совсем верно, поскольку в контроллер нам подсовывают клон объекта с предыдущей итерации. Или я не понимаю как это работает. Про клонирование, кстати, ни слова не сказано. Впрочем, да может быть POJO это лучше чем необходимость объявлять объекты особого типа, но опять же это не объект, который мы создаем сами. И кстати эти контроллеры в глобальном пространстве имен выглядят подозрительно. Надеюсь, их можно спрятать.
2, Насчет того что множественное обновление массива вызывает обновление UI на каждой итерации. Так это легко обходится. И есть выбор — обновлять для каждого или для всех. Что в Angular на этот счет?
В общем я думаю подход Angular vs Knockout это тема скорее для холивара. Потому что объективных преимуществ нет ни у того ни у другого. Я говорю именно о подходе. Angular несомненно более развитый фреймфорк в целом.
Кому то достаточно сделать простую модель, а кому то надо делать сложное приложение. И с Knockout можно избежать каши, просто рецепта нет. В этом есть как положительные так и отрицательные моменты. То же относится и к AngularJS — вам дают готовый рецепт структурирования и у этого подхода тоже есть плюсы и минусы.
kramer.ru/products/catalogue/twisted-pair/667
это так, первое что знаю навскидку. На самом деле их полно разных.