• Какие компиляторы css2 sass,scss,less Вы знаете?

    MarcusAurelius
    @MarcusAurelius Куратор тега Node.js
    автор Impress Application Server для Node.js
    Я лично использую https://www.npmjs.com/package/node-sass он же на гитхабе https://github.com/sass/node-sass
    Это лучшее, что я смог найти. Хоть я не большой знаток и не большой любитель стилей или вообще браузерной верстки, но выбирать пакеты из npm приходится. Поэтому пару советов есть, чтобы исключить долгие страдания и сомнения, нужно принять систему формальных критериев и измеримых величин, все лучше, чем выбирать по смутным интуициям:
    1. Список претендентов можно сделать по поиску, статьям, Хабру, Стековерфлову и по вот этим ресурсам: nodeframework.com https://github.com/sindresorhus/awesome-nodejs https://github.com/vndmtrx/awesome-nodejs
    2. Сначала я сравниваю по количеству звезд в Github и NPM, по количеству скачиваний, по давности последнего коммита и их общему количеству, по контрибьюторам и тому, что делается в пулреквестах и ишьюсах (как быстро устраняются баги, реагируют ли разработчики на проблемы вообще, все это сразу видно). Нужно выявить дохлые проекты и их отбросить.
    3. Потом ставлю их себе и сравниваю исходники. Чем меньше размер исходников и приятнее стиль кода, тем лучше. Отбрасываю монстров, у которых огромные репозитории и сомнительный код. Оставляю самые лаконичные или даже минималистичные (люблю минимализм). Ну и, для этого конкретного случая нужно сравнить результаты и качество генерируемого css.
    4. После этого проверяю на скорость/производительность. Для чего нужно сделать тесты. В этом случае нужно взять пример файла scss стилей посложнее и прогнать его через каждую библиотеку по 1млн раз и сравнить цифры.
    Ответ написан
    Комментировать
  • Где разместить nodejs сервер?

    MarcusAurelius
    @MarcusAurelius Куратор тега Node.js
    автор Impress Application Server для Node.js
    Я отдаю предпочтение физическим серверам, это неизмеримо удобнее, чем неуправляемые хостинги типа хероку и нодеджицу, и значительно лучше, чем виртуалки, которые теряют производительность и лейтенси на слое виртуализации. Если нужно добиться действительно хорошего latency (отклик или отзывчивость) то другого решения нет, но прошу не путать это с производительностью т.е. rps (request per second) на виртуалках можно даже дешевле поднять, а вот отзывчивость системы на железе выше. Но это не всегда так критично. Кроме того, советую сделать таблицу и рассчитать стоимость одного ядра или даже 1Ghz для всех вариантов. Из-за ограничений ноды в памяти одного процесса, имеет смысл делать расчеты исходя из пропорции 2гб на 1cpu.
    Я использую вот что:
    1. Для маленьких проектов ($5 в месяц это очень хорошо) https://www.digitalocean.com/
    2. Для проектов среднего уровня (кое-кто на них ругается, но у меня лично никогда проблем не было с ними) https://www.hetzner.de/
    3. Для крупных проектов (есть замечательные 40-ядерные сервера MG-256) www.ovh.ie
    Ответ написан
    Комментировать
  • Что из себя представляет Apple Touch Icon?

    Expany
    @Expany
    $this->get('skill');
    Ответ написан
    Комментировать
  • Какой Javascript framework выбрать для новичка?

    aen
    @aen
    Keep calm and 'use strict';
    Вот до тех пор пока все будут учить фреймворки, а не принципы проектирования и то как работает браузер, у нас и будут появляться быдлокодеры. Это мысли в слух. Не в обиду автору.

    Фреймворк это просто инструмент. Он за вас решит ряд вопросов. Позволит какие-то фичи сделать быстрее за счет того, что они уже были решены ранее. Но любой фреймворк можно изучить и применять за приемлемое время при условии, что у вас будут достаточно прокачанные скиллы по js, по тому как работает браузер, по тому как передается информации между клиентов и сервером (сокеты, xhr, cors и прочие свистелки).

    Если вы новичок, то просто пишите код. Ставьте задачи. Смотрите как эти задачи решены были ранее в рамках любого фреймворка или библиотеки, прочитайте исходники.

    Фреймворки, к сожалению, весьма подвержены моде. Раньше был тренд на Backbone.js, затем под ореолом Гугла все подхватили Angular.js, сейчас начинается повальное увлечение React.js. Завтра появится, что то новое, все кинутся на него.

    Если вы хотите максимально быстро зарабатывать, то посмотрите требования в вакансиях. Рынок сам вам скажет, что ему нужно.

    Если вы хотите просто прокачаться, но посмотрите примеры решения типовой задачи TodoMVC на разных фреймворках. Выберите то, что вам будет понятнее всего.

    А человек, который на ваш вопрос "Что мне изучать?" быстро и легко назовет имя любого фреймворка, скорее всего сам еще недостаточно прокачался, потому как он видимо не понимает, что нет "серебряной пули". Нет идеального фреймворка, который бы решал все ваши задачи.
    Ответ написан
    Комментировать
  • Пример из статьи на Хабре. Утечка памяти?

    Привет, 3y3 :)

    Чтобы проще было разобраться в этом примере - посмотрим вначале на более простой.
    var theThing = null;
    
    var replaceThing = function () {
      var priorThing = theThing; 
      theThing = {
        longStr: new Array(1000000).join('*'),  // создаем 1Mб объект
        someMethod: function () { 
          console.log("Hi, JS-dude!")
        }
      };
    };
    setInterval(replaceThing, 1000);    // вызываем 'replaceThing' каждую секунду


    Здесь при каждом вызове в theThing записывается новый объект, у которого функция someMethod, через замыкание, хранит ссылку на внешнюю область видимости, включающую в себя priorThing, т.е. предыдущий объект.

    Получается, что каждый новый объект ссылается на предыдущий, они образуют цепочку в памяти.

    Если запустить этот код, то по этой логике будет утечка. В старых браузерах - обязательно будет.

    Пруф:
    4c8a6c47b3764be1bc65e6a8df8cfed6.png

    Современные браузеры, конечно, умнее. FF и Chrome увидят, что переменная priorThing не используется и удалят её из памяти, так что старый объект благополучно умрёт.

    Чтобы этого не происходило, в исходном примере сделан "финт ушами": переменная используется в некой функции unused:
    var theThing = null;
    
    var replaceThing = function () {
      var priorThing = theThing;
      ///////////////////
      var unused = function() {
        console.log(priorThing);
      };
      ///////////////////
      ...
    }
    setInterval(replaceThing, 1000);    // вызываем 'replaceThing' каждую секунду


    Несовершенство сборщика мусора (3y3, видимо, лучшего мнения о нём) приводит к тому, что в этом случае сборщик мусора "не просекает", что переменная-то ненужная, и очистки не происходит.

    Пруф Firefox:
    bdd1210bf5174a13bec4d27652124e70.png

    Пруф Chrome (цепочка объектов в памяти):
    f1da7a209bcb4012b89468907b3df274.png

    Вот, собственно, и причина.
    Ответ написан
    4 комментария