• JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    Да я вот так тоже нашему PM говорил, а он что-то там про сроки, заказчиков и контракты талдычит :)
    Лучший код — это понятный любому, который делает то что надо и не делает того, чего не надо. И отгруженный вовремя.
  • JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    Загрузка модулей в ноде — операция синхронная и блокирующая.

    Да, синхронная, нет, не блокирующая. Она начинает проходить по дереву зависимостей и тому, что недорезолвилось — ставит флаг. Именно поэтому в принципе возможны циркулярные зависимости (хоть они и зло). Кроме того новая реализация, которая ES6 modules import — вообще асинхронная.
    У вас в примерах уже есть строчка antiniteSys.ensureAllIsReady(), можно старт процесса повесить на этот вызов.

    Нет, `.ensureAllIsReady()` это проверка, которая в случае фейла бросает эксепшен. Потому что лучше совсем не взлететь, чем взлететь непонятно на чем, в смысле что не все разрезолвилось.
    Или на первый вызов execute если почему-то решили ensureAllIsReady не вызывать.
    Некрасиво.
    Если вопрос стоит так — сделать что-то сложно выглядящее по-простому или что-то просто выглядящее, но сложное внутри — ИМХО нужно выбирать последнее.
    Какая, в сущности разница, как устроен черный ящик, если он работает как надо?
  • JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    Те сообщения об ошибках, который я предлагаю выкинуть — никогда не будут происходить в принципе.

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

    Сложность в том что этих этапов нет, оно начинает разрешаться при импорте домена и как-то там себе разрешается или нет, новый импорт домена — новый цикл разрешений с учетом «ждущих» зависимостей. И если вы 100% уверены что дерево зависимостей корректно и нет асинхронных инициализаций — не нужно даже дожидаться `. onReady()`. Для введения этапов придется жестко задавать момент старта всего процесса, что выглядит не так изящно, и я сейчас не уверен что это сработает всегда. При написании проекта я ориентировался на нативный стиль того, как нода поступает с разрешением зависимостей.
    Но мысли интересные, я подумаю.
  • JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    Спасибо за ваш интерес к коду и приведеные примеры, но я не уверен в корректности его поведения. Если проект Вас заинтересовал — приглашаю присоединится на github. Я всегда очень лоялен к мердж-реквестам, проходящим тесты и соблюдающим стилистику кода, благо standart — очень простой стиль.
  • JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    Ох, немного неудобно так код обсуждать, в отрыве от него самого.
    Но давайте попробую общё — во-первых я не могу себе позволить упрощать код, выкидывая сообщение об ошибках. А так как у нас много ленивых вычислений — верить нельзя никому.
    Например — нельзя упросить `proxyUpcomingExecute`, потому что в момент его бинда к `doRequireCall` вполне возможно что `grantedItem.layer` просто отсутствует.
    И так много где.
    И это мы еще не вспоминаем об асинхронной инициализации сервисов.
  • JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    Не совсем понимаю вопрос.
    Если он в том «почему не все со всеми» — так это и не нужно и неудобно будет, здесь четкое понимание зависимостей прямо в конфигурации видно.
    Если «динамическое разрешение доступа» — то по факту-то оно как раз статическое, при сборке всех зависимостей и разрешается.
  • Модули вместо микросервисов
    –1
    Надо же, примерно в это время я и писал свой Antinite, а коллеги с хабра говорят «нечего выкладывать такое в интернеты, забирай обратно».
    Ведь перспективная тема же?
    Ваша статья очень полезна, помогла разобраться в понятиях.
  • JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    странно, а вот википедия говорит что
    Класс — абстрактный тип данных в объектно-ориентированном программировании, задающий общее поведение для группы объектов; модель объекта.

    Ну и да, что-то по вашему получается «не читал, но осуждаю». Почитайте, бывает интересно.
  • JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    Получилось красиво, не спорю.
    Но у Вас сервис-потребитель ограничивает себя сам, а у меня сервис-поставщик и домен, в рамках которого он (поставщик) заявлен, контролирует доступность ресурса. Т.е. никто не берет чужого не потому что все честные, а потому что замок висит. В этом вся разница.
  • JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    Хорошо, положим в TS у нас вроде бы есть приватные методы и поля. Пусть с ними.

    Давайте зайдем все же рассмотрим вариант интеграции с DI.
    В любом варианте мы в итоге имеем что-то типа
    class Foo {
      constructor(dependency1, dependency2, dependency3) {
        this.ext1 = dependency1
        this.ext2 = dependency2
        this.ext3 = dependency3
      }
     doFoo1 (dataIn) {
         this.ext1.callFn(dataIn)
      }
    }
    

    так? Если не брать совсем экстремальные варианты то вроде бы так. А значит при необходимости сделать тест нашего Foo нам надо на минуточку — найти что за объекты пробрасываются в конструктор (а если это довольно далеко от корня — могут быть нюансы), далее — найти методы этих зависимостей, которые используются (по всему коду), далее — сделать на них моки.
    Или, используя велосипед — просто посмотреть в перечисление require и дать именно те методы, которые там перечислены. Все! Больше никаких зависимостей у класса нет и быть не может.
    Статически объявленная гранулярность зависимостей на уровне методов.
    Нет, не нужно? Точно?
  • JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    Если у вас большой размер кода и нужно грамотно разделять зоны ответственностей модулей, то самое время внедрить Typescript, а не устраивать валидацию в рантайме.

    Вероятно я плохо себе представляю возможности Typescript. Каким образом в нем можно разделить видимость методов, кроме как написав кучу оберток интерфейсов?
    Про Proxy: во-первых, это уже часть стандарта языка, поддерживается в stable версии Node. Во-вторых, несмотря на использование Proxy, код остаётся типизированным и предсказуемым. В нем всегда можно проследить где метод декларируется и где вызывается. А в вашем подходе найти концы не представляется возможным

    И что нам дает типизированность кода в вопросе доступа к методам? И видимо у меня не получилось донести идеи. Первое — концы конечно же можно найти — система в любой момент может отдать граф зависимостей. Приспособить его к тому же Atom — дело техники. Далее — приведенная Вами библиотека — классический вариант DI, разве что с TS интерфейсами, которые существуют только до момента транспилинга. И сам автор указывает на то, что извлечь из контейнера объект следует в самом верху дерева, после чего приходится носиться с этим объектом как с писаной торбой и прокидывать его дальше вглубь. Или прокинуть контейнер и получить -500 к карме. В этом отношении даже древнючий intravenous и то лучше, правда с ним мы так же в итоге не понимаем что откуда берется и что куда девается.
  • JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    Интерфейсы, контракты — что-то такое слышали, но в JS, уж если у нас как-то получен объект — то ВСЕ его методы доступны. Все варианты сделать методы как бы приватными — черная магия чистой воды.
    А как ограничиваеся использование в вашем решении?

    Пример маловат, из него не все очевидно, мой просчет.
    Все методы, объявленные в `export` конечно же будут доступны компонентам, которые имеют на это права. Но! Обычно объект имеет и приватные методы, которые используются для вынесения кода в аккуратные логичные сущности. И как мы помним, приватны они только на уровне договоренности (см первый абзац ответа). В случае использования Antinite экспортируется ТОЛЬКО то, что описано в экспорте. К приватным методам (не объявленным в экспорте) доступа нет. Вообще нет. Совсем. Никак.
    Ровно как у компонентов с правами на методы уровня «чтение» не будет доступа к методам других уровней. Совсем.
    И да, библиотека патчит исходные объекты. Потому что она ими владеет по праву использования. Как по мне — грех тянущий максимум на написание хорошего комментария ошибки.
    Советую посмотреть на Typescript и библиотеки вроде InversifyJS.

    Что именно в Typescript позволяет реализовать хотя бы DI? В Typescript есть что-то для контроля доступа к синглтонам? Аудит их использования?
    InversifyJS — забавная вещица, но вот вы мне патчить исходные объекты запрещаете, а там во весь рост Proxy используются, которы мало того что пока в драфте, так еще и, положа руку на сердце, делают тоже самое, по сути.
  • JavaScript — заполняем нишу между микросервисами и объектами — «нано-сервисы»
    0
    Давайте по существу, что там у нас с «функциями с сайд-эффектами и приватными полями»?
  • Построение модульной системы на основе Nodejs
    +1
    Ох. Вы только не обижайтесь, идея здравая, но её качество вам бы подкачать.

    var workerCount = require('os').cpus().length;
    

    не делайте так, процы с гипертрейдингом (или как там называется эта маркетинговая шляпа) наивно отдают х2 ядер, что по факто вранье и толком не работает. Вынесите в конфиг.

    Статус 999 — детский сад. Есть rfc на статусы ответов, возьмите подходящий код.

    Забудьте про синхронные вызовы. ИМХО их использование нельзя оправдать ничем. Ну разве что эмм. невысоким уровнем разработчика. Очень невысоким.

    Забудьте про global. Или реквайрте явно, или передавайте параметром. Глобали вообще нет оправданий, даже если это написал Ризинг. Но он так не сделает.

    Именование функций местами сбивает с толку. Не пишут ok, пишут isOk, ибо булен-флаг.

    И последнее (на что у меня хватило сил) — реквайр ноды устроен хитро и конечно же кеширует последующие require, но идея делать его на каждый запрос вызывает оторопь.

    В общем у вас есть место для улучшений.
  • Хитрые льготные периоды
    0
    Вот таки да, у нас реклама висит — «отдохните в отпуске в кредит!»
    ИМХО если денег нет — какой нафик отпуск?
    На деньги, которых у них нет люди покупают вещи которые им не нужны :)
  • lodash (underscore) — знай свою стандартную библиотеку
    0
    А, собственно, что Вам мешает использовать кастомный фильтр, который преобразует «максимальную строку» в число?
  • Дизайн и архитектура в ФП. Часть 2
    +1
    Здорово описано, ждём продолжения.
  • JavaScript to APK. Подводные камни разработки под Android для тех, кого задолбал PhoneGap. Построение мостов из Java в JavaScript
    –2
    Ох, как-то привык в JS к тому что создать объект ничего не стоит, так что совсем красиво не сделать, в яве хешмапы жуть какая-то (как-то раньше пристально не смотрел на нее).

    А вообще конечно по нормальному нужно вести от общего к частному

    vw.setScrollBarVerticalEnabled(false);
    


    Что все равно ужасно, но хоть логичнее по структуре.
  • JavaScript to APK. Подводные камни разработки под Android для тех, кого задолбал PhoneGap. Построение мостов из Java в JavaScript
    0
    Вот за такое API
    vw.setVerticalScrollBarEnabled(false);
    


    Разработчика нужно п… дить кирзачами отрывать руки дать в репу заставить самого этим пользоваться.
    Этож просто какая-то жесть.

    А по итогу-то что получается — только Java, только хардкор? Как не посмотрю — все кривенько :(
  • Как будут защищать детей от вредной информации?
    +16
    Меня больше всего во всем этом цирке 2 вещи забавят:
    1. Никто не боится демонстрировать в магазинах фрагменты трупов расчлененных млекопитающих, отличающихся от людей на 2-3% по ДНК. Никого не беспокоят выставленные свиные головы и прочее. А видите ли человеческий трупик — это прям ужас-ужас!
    2. Все больше вводится всякого маразма «оградить и не пущать», но строго до 18! С первым звонком взрослой жизни опекаемое доселе чадо получает обязанность взять в руки огнестрел и уже получить навык «зачистки». Так вот, без лишних ласк.

    Нужно не от информации «вредной» защищать, а учить критически мыслить и верно ещё оценивать — но они же на самом деле не идиоты — рыть самим себе могилки :-)

    В чистом итоге — сраное ханжество, морализм, попил бюджетов и попрание прав и свобод.
  • Нагружаем Node под завязку (2-я из 12 статей о Node.js от команды Mozilla Identity)
    0
    Если посмотреть в кот — либа ужасна
    this._MAX_KIDS = (options.max_processes || Math.ceil(require('os').cpus().length * 1.25));
    

    тут в трех местах поперхнутся можно.
    И самое главное — непонятно зачем извращаться с поддержкой очередей если есть async? Ну допилить кое-чего по мелочи, но там все красивое уже есть.
  • CoffeeScript: Подробное руководство по циклам
    0
    Пример от этого удачнее не становится.

    counter = 5
    console.log counter-- until counter is 2
    
  • CoffeeScript: Подробное руководство по циклам
    0
    В данном случае, для получение значений массива использовать нужно именно of, а не in.

    ой ли?
    вот две записи, дающие одинаковый результат
    result_in = ( val for val in ['a', 'b', 'c'][0...2])
    result_of = ( val for key, val of ['a', 'b', 'c'][0...2])
    

    Но почему первая — корректна, а вторая — путь на темную сторону?
    Потому что:
    var key, result_in, result_of, val;
    
    result_in = (function() {
      var _i, _len, _ref, _results;
      _ref = ['a', 'b', 'c'].slice(0, 2);
      _results = [];
      for (_i = 0, _len = _ref.length; _i < _len; _i++) {
        val = _ref[_i];
        _results.push(val);
      }
      return _results;
    })();
    
    result_of = (function() {
      var _ref, _results;
      _ref = ['a', 'b', 'c'].slice(0, 2);
      _results = [];
      for (key in _ref) {
        val = _ref[key];
        _results.push(val);
      }
      return _results;
    })();
    

    Мы же не будем спорить о том, насколько неэффективно обращаться с массивом как объектом?
  • CoffeeScript: Подробное руководство по циклам
    0
    Алсо —
    expr = /foo*/g;
    alert "#{array[0]} : #{expr.lastIndex}" until (array = expr.exec('foofoo')) is null
    

    пример явно не удачный, потому как это же явно
    expr = /foo/g
    console.log "#{array[0]} : #{expr.lastIndex}" while array = expr.exec 'foofoo'
    
  • CoffeeScript: Подробное руководство по циклам
    0
    Алсо —
    alert i for i in [1..10] when i % 2 is 0
    

    ИМХО удачнее будет
    for i in [1..10] when not( i % 2) then console.log i
    
  • CoffeeScript: Подробное руководство по циклам
    0
    Алсо — с места
    [value for i, value of ['a', 'b', 'c'][0...2]] # a, b
    

    и до конца раздела — это вы о чем?
    Во-первых не нужно писать of [arr], нужно in [arr]
    Во вторых — смысла конструкции вообще не понял — может проще сразу было
     ['a', 'b', 'c'][0...2]
    

    не?
  • CoffeeScript: Подробное руководство по циклам
    0
    Эм, за напоминание о слайсах — спасибо, в отместку — там опечатка есть
    [list1, list2 ...]  #[1,2,3,4,5,6] 
    

    Не, чтобы получить плоский список надо сказать
    [list1..., list2...]
    
  • Нам не нужен ваш кофе
    +1
    лучше null
  • Нам не нужен ваш кофе
    +3
    Бла-бла-бла — кидалтское нытье и занудство.

    Автору стоит вернуться к взрослой реальности.
    Не хотите наш CS — ну и xрен с вами! Не нравится ответ на SO на CS — ну и хрен с вами!
    Это ваши проблемы и не вам мне указывать где что и на чем писать.
    Я же не начинаю ныть, что вот тут книжка по алгоритмам на сях, тут — на лиспе, а тут вообще не пойми чего? Раз оно надо мне, значит и с этим я разберусь.
  • Impress: многоцелевой сервер приложений для Node.js
    0
    Ну, многослойные абстракции нам дает DI, за связанностью следит ООП, а сокращать код помогают mixin-ы.

    Я как бы не настаиваю, но есть некие best practice, игнорировать которые черевато боком, мне ли не знать.

    Но в любом случае — успехов, хоть я лично за unix-way и держусь подальше от комбайнов.
  • Impress: многоцелевой сервер приложений для Node.js
    +1
    Есть такой вопрос провокационный — а почему Вы не пишите на node.js?

    Зачем Вы изобрели собственный механизм импорта\экспорта?
    Почему не используете сторонние клиентские библиотеки — для работы с датой, строками и т.д? Всякие lodash-underscore уже стандарт де-факто.

    Я уж молчу про то, что использование global — жуткий моветон, который еще как-то можно простить в тестах, но в продакшен-коде — ни-ни.
  • Разбор регулярных выражений
    0
    Что-то мне подсказывает, что криворукие люди не напишут в продакшен машину регулярных выражений.

    А что быстрее будет работать — честно говоря пофик, микрооптимизации меня никогда не интересовали.
  • Разбор регулярных выражений
    –1
    Вот лучше бы Фридла почитали, чтобы вместо ужаса типа
    (www\.[A-z\d\.\+\-]+) было что-то типа /(w{3}\.[-a-z\d+.]+)/i
  • YAMD: еще один велосипед для описания модулей в JS
    0
    Только ComonJS, только хардкор :)

    Пишем на coffee, жмем clinch-ем и вуаля!
    Получается что-то типа такого — демо и исходники.
  • jsFind. Выборка данных из массива объектов
    0
    Ниже куча ссылок на подобные проекты.
    Плюс еще есть TinyData, которая полноценный запросник по слабоструктурированным данным :)
  • Почем оптимизация или «бесплатных завтраков не бывает»
    0
    Ну, этой книги у меня нет, однако если мы о тупом баге в стеках — то он довольно давно поправлен почти во всех браузерах.

    Изменения в спеках и объяснялка на SO.

    Я вот знаю про скрытые классы при создании объекта, про преобразования массива если он содержит разные типы данных, про преобразование полиморфных функций, а вот по поводу «скомпилированной сущности» в отношении регулярок — не, не видел. Может лишнего удумали?
  • Почем оптимизация или «бесплатных завтраков не бывает»
    +1
    О как.
    Могу я попросить ссылку на документацию (вероятно в реализациях браузеров?) об этом факте?
  • Почем оптимизация или «бесплатных завтраков не бывает»
    –1
    Он и инлайновый-то каждый раз новый создается — пруф
    Просто инлайновый быстрее — по многим очевидным причинам.
  • Почем оптимизация или «бесплатных завтраков не бывает»
    0
    ХМ… пруф?

    У меня вот как-то другие получаются результаты:
      var n, re1, re2, res;
    
      re1 = /test/;
    
      re2 = /test/;
    
      res = (function() {
        var _i, _results;
    
        _results = [];
        for (n = _i = 0; _i <= 1; n = ++_i) {
          _results.push(/test/);
        }
        return _results;
      })();
    
      console.log('re1 === re1 ->', re1 === re1); // re1 === re1 -> true
    
      console.log('re1 === re2 ->', re1 === re2); // re1 === re2 -> false
    
      console.log('res[0] === res[1] ->', res[0] === res[1]); // res[0] === res[1] -> false
    


    Или я не верно понял идею?

    поиск продолжается с места предыдущего найденного результата

    Это о чем? я знаю только о поведении реплейса с флагом 'g' и экспериментальном флаге 'y', но у нас тут другая ситуация вроде.

    PS. А за что человека-то заминусовали — все верно заметил.
  • Почем оптимизация или «бесплатных завтраков не бывает»
    0
    Кто знает :) Строим на века, вдруг в этом месте будет лаг и интерфейс пользователя фризоваться начнет? :)

    На мой вкус ничего там делать было не надо, данных проФайЛера (я правильно понял?) не было конечно — virgin premature.