• Что можно положить в механизм Dependency Injection в Angular?
    +1
    Чтобы уж полностью проникнуться, без всякой магии Angular, то вот: inversify.io — годный контейнер. Давно пользуюсь и на бэке и на фронте.
  • Быстрый старт с WebComponents
    +2

    Ставьте пакеты локально и пользуйтесь npx. Глобальные зависимости зло, не только js и npm касается.

  • Загрузчик модулей для node js с поддержкой локальных модулей и загрузки модулей по требованию
    0
    Загружаем мы не просто файлы, а программный код, которые нужно скомпилировать и выполнить, что может потянуть ещё зависимости. Многие модули зависят от других модулей и решают этот вопрос с помощью синхронного require.

    Зачем это?
  • Загрузчик модулей для node js с поддержкой локальных модулей и загрузки модулей по требованию
    +2
    Здесь ещё вот какой момент. Вызов require — синхронный. Так как он отложен и будет вызван неизвестно когда, скорее всего его вызов попадётся в асинхронном коде. Что доставляет следующие неприятности:
    1. Ожидание файлового ввода-вывода, что порочит идею асинхронного кода.
    2. exception в этом коде уронит ноду (приятной отладки).

    Вызов синхронного кода во время работы сервиса (не консольной утилиты) — это всегда зло. Поэтому загружаем все модули на старте и если что-то не то, получаем просто не загрузившееся приложение, что быстро диагностируется и лечится.

    В общем не дай бог я увижу проект с таким вот подходом…
  • Смартфон с мощным аккумулятором. Версия DEXP: 10 моделей от 4 490 до 13 990 рублей, от 3 000 до 5 200 мАч
    0
    то есть с желтым цветом вместо белого

    Не подтверждаю. Белый цвет имеется, как белый.
    Если дадите инструкции как правильно посмотреть на него (под солнцем или в полной темноте), чтобы он стал жёлтым, обязательно посмотрю.
  • Смартфон с мощным аккумулятором. Версия DEXP: 10 моделей от 4 490 до 13 990 рублей, от 3 000 до 5 200 мАч
    0
    Ну так и вставили бы его в обзор, чтобы обозначить недостатки и достоинства. Я, как писал в комментарии, за объективную картину. А телефон с батарейкой в 5000 мАч всё-таки эту картину дополняет, не находите?
    Потребитель должен знать своих героев, а производитель должен бороться за потребителя. Разве не так?
  • Смартфон с мощным аккумулятором. Версия DEXP: 10 моделей от 4 490 до 13 990 рублей, от 3 000 до 5 200 мАч
    +1
    Пользуюсь пока что всего 4 дня. Пытаюсь понять сколько будет работать при нормальном использовании (звонки, браузер пару часов в день в метро), чтобы не вырубать всё подряд (или переходить в экстремальный режим, т.е. только телефон).

    Пока что понял только одно. Skype — зло. Сожрал 60% заряда при том что я всего-лишь пару раз написал сообщение и раз десять сообщения почитал. Вырубил его к чертям. Skype и смартфон, к сожалению, — не совместимы.

    Поставил тёмную тему — она нормальная в плане дизайна, но более экономичная.
    Отключил из автозагрузки приложения которыми не пользуюсь.

    Второй день идёт — заряд больше 50%. По моим прогнозам, дня 4 продержится.

    Когда закончу анализ, ещё покручу настройки, вероятнее всего отпишу подробный комментарий, прямо в блог highscreen`а здесь.
  • Смартфон с мощным аккумулятором. Версия DEXP: 10 моделей от 4 490 до 13 990 рублей, от 3 000 до 5 200 мАч
    +5
    Highscreen Power Five в обзор добавить постеснялись?
    5000 мАч, 4 ядра, 1.3 ГГц, 16/1.5 память, LTE, 5" экран, Android 5.0

    P.S. Я не от них, просто пользователь этого аппарата. Хотел бы видеть картину более актуальной, раз уж Вы это анонсировали.
  • Легковесный модуль для HTTP запросов
    +3
    А кто-то предпочёл бы увидеть следующее:
    req.post(...).then(...)
  • Пишем maintainable код
    +8
    Лёгкая, понятная статья с простыми примерами. Может и лишнее, но в конце можно по пунктам перечислить «привычки» как итог.
  • Разработка на ES6 для браузеров
    +6
    А что, минификацию кода умеет делать только Google Closure Compiler? Для этого нужно такую зависимость от JAVA тащить?
  • OSI: Интернет, которого не было
    0
    Забавная статья. Насколько я понял, OSI, кроме модели, которая описана в учебниках, ещё и разрабатывала непосредственно реализации протоколов для каждого уровня. Т.е. от деятельности OSI осталась только модель, а уже конкретные протоколы Интернета были предложены DARPA.

    От статьи остаётся ощущение, что OSI провалилась полностью и покрыта забвением, и у меня вопрос:
    Один из самых популярных стэков протоколов (Ethernet/IP/TCP/HTTP) разве не укладывается в модели OSI?

    Здесь Ethernet нормально делится на два слоя (помимо MAC-адресации, есть ведь ещё какой-то протокол на уровне электрических сигналов), а HTTP просто объединил в себе три последних прикладных уровня.

    Картинка для напоминания…
  • SummaryJS: самое интересное из мира JavaScript за последнюю неделю
    +2
    Было бы здорово, если бы перед каждой ссылкой висел флажок языка (rus/eng)
  • Одностраничный магазин на Phalcon PHP + AngularJS. Работа над ошибками
    –3
    За предыдущую статью поставил минус (без сожалений).
    За эту плюс (недостатки есть, но прогресс очень приличный) и в карму плюс (за стремление к совершенству).
  • Sortable v1.0: Новые возможности
    0
    Может я не правильно выразился, но…
    var ngRepeat = [].filter.call(el.childNodes, function (node) {
         return (
               (node.nodeType === 8) &&
               (node.nodeValue.indexOf('ngRepeat:') !== -1)
            );
      })[0];
    


    … разве это не лазить по DOM`у в поисках модели (её имени)?

    и потом…
    // Прасим название переменных элемента и массива
      ngRepeat = ngRepeat.nodeValue.match(/ngRepeat:\s*([^\s]+)\s+in\s+([^\s|]+)/);
    

  • Sortable v1.0: Новые возможности
    0
    Лазать по DOM`у в поисках модели, да ещё и комментариях, которые оставляет angular — это просто жесть.
    Если уж и хотите уделать зубров (которые не додумались до такого), примите как совет:
    <ul ng-sortable="item in items" options="sortableOptions">
        <li>{{ item }}</li>
    </ul>
    


    P.S. Я таким образом dropdown для css фреймворка делал.
    <dropdown items="item in items" default-text="select items" on-select="onSelect(item)">
        {{item.description}}
    </dropdown>
    
  • HTML/CSS/JS + Node.js + node-webkit = Кроссархитектурные приложения
    0
    Согласен, это довольно логичный вывод.
  • Вселенная npm
    +1
    Есть заявка. Неплохо бы было получить top 100 супер звёзд (с самым большим количеством связей). Просто для анализа. Кто такие и чем занимаются.
  • Вселенная npm
    +3
    Вы сделали мне утро. Спасибо.
  • Новый WebStorm 9: просто лучше. Поддержка Meteor, React и JSX, интеграция с Gulp, PhoneGap и многое другое
    +1
    В 9-й версии пока не заметил. Действительно стало лучше.
  • Новый WebStorm 9: просто лучше. Поддержка Meteor, React и JSX, интеграция с Gulp, PhoneGap и многое другое
    +1
    Может кто-нибудь сказать почему WebStorm при срабатывании точки останова в node.js иногда очень долго вычисляет переменные? Иногда процесс вычисления затягивается «навсегда».
    Например, я заметил, что переменные в которых лежит Buffer с большой вероятностью очень долго «раскрываются».
  • Семь принципов создания современных веб-приложений
    +4
    У меня тоже. Хотя это и перевод, это нисколько не умаляет проделанного труда.
  • Как мы делали аналитику для высоконагруженного сайта
    +2
    1. fs.exists — проверка на существование файла
    2. Что Вам помешало написать вместо этого
    image = fs.readFileSync('p.gif');

    вот это
    
    fs.readFile('p.gif', function(err, data){
      if (err}{ return; // TODO }
      image = data;
    });
    


    Никогда не вызывайте синхронные методы после того как «процесс пошёл».
    К тому же, закэшировать картинку в памяти можно при старте приложения. Вот там, кстати, можно воспользоваться синхронным методом.
  • Как мы делали аналитику для высоконагруженного сайта
    +3
    Глаз зацепился, не могу оторвать…
    image = fs.readFileSync('p.gif');
    

    … прям в середине асинхронного кода.

    Как это понимать?
  • Тонкости nodejs. Часть I: пресловутый app.js
    0
    В реальности так и делаю, здесь просто для краткости.
    Хорошо, что отметили, пусть останется для читателей.
  • Тонкости nodejs. Часть I: пресловутый app.js
    0
    Не совсем понял где Вы увидели у меня смешение интерфейса и логики? Может в моём коде не хватает комментариев для лучшего понимания…
    1. Код конроллёров полностью вынесен из http-интерфейса. Я отметил в коде, что каждый контроллёр находится в отдельном файле и список его входных параметров чётко обозначен. Это даёт им хорошую тестируемость и переиспользование.
    2. Код http-интерфейса практически не растёт с ростом методов. Увеличивается только модель интерфейса (в коде это routes). Таким образом отпадает надобность его тестировать вообще.

    В вашем варианте у Вас всё-таки остаётся код в интерфейсе.
    server.get('/file', function(req, res, next){
        app.file(req.query.file, function(err, file){
            if (err) return next(err);
    
            res.type('text/plain').end(file);
        });
    });
    

    Вам придётся написать на него тест. Но в таком варианте Вы этого сделать не сможете. Это довольно сложно. А сложных тестов быть не должно.

    Поправьте, если я что-то не понял.
  • Тонкости nodejs. Часть I: пресловутый app.js
    +3
    Вы только в начале пути. В последнем своём проекте, о котором я напишу после его окончания, я сделал следующее:
    1. Разделил собственно приложение (настройка express app) и функции, которые обрабатывают запросы (назвал их контроллёрами)
    2. Функции-контроллёры получают список входящих параметров с помощью инъекций по полной аналогии с angular framework.

    Т.е. просто применил MVC шаблон. Это реально освободило меня от шаблонного кода и я больше сосредоточен на логике функций-контроллёров.

    Если схематично, то получается следующее:
    // listCtrl.js
    module.exports = listCtrl = function(request, response, app) {
    };
    listCtrl.$inject = ['request', 'response', 'app'];
    
    // fileCtrl.js
    module.exports = fileCtrl = function(request, response, app) {
    };
    fileCtrl.$inject = ['request', 'response', 'app'];
    
    // app.js
    var routes = [
      {
        path : '/',
        method : 'get',
        controller : require('./controllers/listCtrl.js')
      },
      {
        path : '/file',
        method : 'get',
        controller : require('./controllers/fileCtrl.js')
      }
    ];
    
    // middleware которая набивает маршрутами и обработчиками express по модели, делает инъекции при вызове контроллёра и т.д.
    express.use(router(routes));
    
    


    Главным бонусом такого подхода является отличная тестируемость функций-контроллёров (из-за внедрения зависимостей). Когда закончу проект, посмотрю что получилось и выложу на суд общественности.
  • Технология от Яндекса, которая избавит нас от бумажных билетов в кино и очередей в кассу
    –13
    Но мы надеемся, что люди, которые не ходили в кино, боясь очередей или общения с кассирами

    Таким людям только хороший психоаналитик поможет, а уж точно не Smartpass.
  • Pooling соединений к базе данных на node.js
    +1
    Раз уж исходники на GitHub`е, зачем Вы продублировали эти простыни на хабр, и даже под спойлер не убрали?
  • Bundle Transformer: Летние обновления
    0
    Борьба с ветряными мельницами все эти бандлы в ASP.NET. На каком этапе развития находится технология, по сравнению с grunt/gulp?
  • Пишем тестопригодный javascript
    +3
    Избегайте создания приватных свойств с помощью замыканий

    Подобные советы, автору поста не плохо бы оставить при себе и не мутить воду. Публичный интерфейс класса (объекта) должен быть самодостаточным для использования и не должен содержать ничего лишнего (всякие _foo и т.д.). Для чего нужно тестировать приватные части алгоритма ума не приложу. Что он хочет выяснить таким тестом? Что приватный код работает правильно? Это не даёт никакой гарантии, что публичный метод, который его использует, тоже будет работать правильно. Тестировать нужно только публичные методы. Только это даёт гарантию.
    Вместо подобного совета, я бы лучше порекомендовал использовать тулу для анализа покрытия кода тестами. Пользы вагон, и, к тому же, при её использовании, многие вопросы по поводу внутренней жизни приватных функций отпадают сами сабой.
  • Сюрреализм на JavaScript. Советы по разработке на NodeJS
    0
    Не спорю. Синхронная работа возможна во время первоначальной загрузки (если точнее, до первого асинхронного вызова). Так же как впрочем не страшны и throw в этот момент. Но как только приложение сделало асинхронный вызов, например, начало читать сокет, после этого всё: никаких синхронных вызовов и throw.
  • Сюрреализм на JavaScript. Советы по разработке на NodeJS
    +8
    Совет 1. SQL запросы лучше хранить отформатированными
    Совет 2. Жизнь становится проще, когда API различных компонентов принимает на вход любой формат

    Общий совет, подойдёт к любому ЯП.

    Совет 3. Разукрасьте консоль и отформатируйте вывод информации

    Как только Вы наиграетесь с консолью и начнёте весь лог укладывать в БД, Вы откатитесь к первоначальному нечитаемому логу. Решение более сложное. В development окружении сойдёт консоль, в production — уже нужно прибивать любую раскраску.

    Совет 4. Оборачивайте все API в try/catch

    Не используйте throw в runtime и не нужно ничего оборачивать. Используйте принятый стандарт записи callback-функции. function callback(err, result).
    Совет 5. Собирайте запросы в конфиги
    Совет 6. Выносите все в конфиги

    Общий совет, подойдёт к любому ЯП.
    Совет 7. Работа с файлами и Модуль Social Link для СЕО

    Не понятно при чём здесь node.js вообще. Но вот следующее, я бы охарактеризовал как вредный совет:
    Притом, чтобы не страдать с callback-функциями и различными проблемами асинхронности, всю работу с файлами я всегда делал в синхронном режиме.

    Вы нарушаете саму идеологию асинхронного ввода/вывода, за что Вам будет больно.
    Совет 8. Без callback`ов жизнь проще

    Тоже в раздел вредных советов. Используйте callback`и. Не нравится, или говнокод получается — вас спасут promise`ы. Или не пишите на javascript, найдите другой язык… без колбеков.

    Итого:
    4 общих совета по программированию вообще. Даже не знаю зачем они, это приходит с опытом;
    1 совет так себе, буду считать, что полезный (про консоль). Вреда от него не будет;
    1 бессмысленный совет использовать try catch в асинхронном потоке исполнения ( скорее вредный );
    2 совета вредных для javascript в принципе. (синхронная работа с вводом/выводом и боязнь коллбеков);
  • RabbitMQ — отложенные сообщения
    0
    Что происходит, если я закладываю в очередь два отложенных сообщения с разным TTL? Например: Message 1/ TTL 1000, и сразу за ним Message 2/ TTL 500.

    P.S. Пардон, когда набирал, первого комментария ещё не было.
  • Ускоренная разработка веб/мобильного приложения
    +1
    Какие у Вас были мотивы не использовать готовые build системы (grunt/gulp), а писать самопальный скрипт?
  • Deb.js: самый крохотный отладчик в мире
    0
    Присоединяюсь к комментарию @DenAmir.
    Я не понимаю, это тонкий троллинг автора или что? Вместо пошаговой отладки автор предлагает прикрутить сомнительный костыль, который идёт вразрез с best practice.
  • Секретные записки в коде
    +13
    Стараюсь придерживаться правила: «Почему это делается»
  • Книжка Discover Meteor переведена на русский
    0
    На заметку: пока что Meteorite не поддерживает ОС Windows

    Убило всё желание. Javascript как бы… господа.
  • Анализируем Хабрахабр с помощью Google Page Speed
    +1
    Спасибо за обзор.
  • Оставьте ссылку на свой профиль — и добавьте к себе одного хабражителя
    +1
    Javascript: AngularJs, Node.js
    brainstorage
    github