• Meteor.js расцветает или чахнет?

    PQR
    @PQR
    Не согласен с предыдущим оратором (@geeek), в частности с утверждением
    В общем если хочешь быть в тренде - бери
    - Meteor совсем не в тренде.

    Если дать краткий и резкий ответ на вопрос "расцветает или чахнет?" - отвечу: интерес к Meteor чахнет, не смотря на все усилия команды разработки.

    Компания MDG (Meteor Development Group) подняла $31M инвестиций (https://www.crunchbase.com/organization/meteor) и хотела всё сделать круто, стать мейнстримом, а потом зарабатывать на хостинге Meteor проектов - такой план монетизации. Хостинг они, кстати, сделали. И в какой-то момент было много хайпа вокруг Meteor, казалось, что всё идёт по плану. Полтора года назад вышел Meteor 1.0 (октябрь 2014), потом была пара хороших релизов, которые убрали всю "сырость": Meteor 1.1 и 1.2.

    Но в середине 2015 стало понятно, что никаким мейнстримом они не стали, мейнстрим нынче React!
    Не смотря на простоту старта и скорость разработки с Meteor, были очевидны следующие минусы:

    1. Собственная система пакетов со своим центральным репозиторием https://atmospherejs.com - посмотрите на счётчики скачивания пакетов, это крохи по сравнению с npm. Посмотрите на активность разработки основных пакетов - всё очень тухленько.

    2. Собственная система сборки. С одной стороны всё работает из коробки, с другой стороны в неё не вклинишься (это сложно). Плюс всякие странные условности, что всё в глобальном пространстве имён и ваши js файлы загружаются в алфавитном порядке. В Meteor 1.3 частично решили проблему, ходят слухи, что в будущем будут использовать webpack.

    3. Собственный шаблонизатор blaze (похож на handlebars). В начале blaze выглядел хорошо, но теперь все внезапно пишут на React и многие потирают руки в ожидании Angular 2, в итоге blaze оказался ещё один велосипедом, с которым не понятно что делать.

    4. На бекенде всё ещё Node 0.10. Даже с Node 0.12 Meteor уже не работает из-за некоторых бинарных зависимостей! Обещали в будущих версиях обновиться с поддержкой Node 4.

    5. Метеор сильно завязан на MongoDb. Чтобы реактивно доставлять новые/изменившиеся данные от сервера в бразуер они парсят логи Mongo. Были попытки сделать аналогичное для SQL баз, но не увенчались успехом. В итоге встречайте их новый проект Apollo, который поверх GraphQL и не привязан к конкретной реализации бекенда www.apollostack.com А что теперь будет со старым добрым DDP?

    6. Ваше Meteor приложение одной командой можно упаковать в мобильное приложение Cordova - выглядит круто, но сейчас время ReactNative и вот мы читаем обсуждения на форумах, что возможно, они таки интегрируются с ReactNative, но когда?

    Подводя итог: ребята из MDG подняли кучу денег и хотели сделать всё сами: свои пакеты, свою сборку, свой шаблонизатор, свой реактивный протокол (DDP) и чтобы всё работало из коробки. И они сделали это!

    Только это оказалось никому не нужно, т.к. для пакетов все сидят на npm, сборка должна быть гибкой (и поэтому у нас есть gulp и webpack), самый модный шаблонизатор нынче - это React, реактивный протокол GraphQL и базы на сервере люди любят разные, а не только MongoDb. А Meteor, по сути, остался на обочине всей экосистемы и движухи вокруг JavaScript. Поняв это, MDG начали двигаться в сторону JS комьюнити и первый шаг сделан: Meteor 1.3 поддерживает нормальные модули ES2015, npm пакеты, рендринг через React и Angular. Но Meteor 1.3 - это куча костылей поверх старого велосипедного Meteor. Почитайте их планы на будущее в официальном блоге, хотя бы в этом посте: info.meteor.com/blog/announcing-meteor-1.3 - им по сути предстоит переписать всё заново! И первые ласточки такого "переписывания" - это выделение проекта Apollo.

    Возможно, со второй попытки они всё сделают правильно и Meteor 2.0 действительно выстрелит. Если только у них деньги не закончатся раньше.

    Сейчас можно взять Meteor и эффективно зарабатывать на маленьких/средних фриланс проектах, когда нужно сделать быстро и не думать о долгосрочной поддержке.
    Если же вы делаете большой продукт, то вас ждут большие потрясения и изменения в экосистеме Meteor.
    Ответ написан
    4 комментария
  • Java. N ферзей, на доске, нужен алгоритм для проверки, "а что, если ферзь может стоять на том же месте" или как найти все способы?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    Самый очевидный алгоритм:
    Очевидно, что в одой вертикали или горизонтали не может быть двух ферзей. Таким образом, все варианты можно представить как перестановки N чисел от 1 до N, где позиция числа - это номер вертикали, а само число - номер горизонтали. Остаётся сгенерировать такие перестановки и проверить в них диагонали, если |Pi-Pj| = |i-j|, то ферзи стоят на одной диагонали и позиция недопустима.
    Ну а дальше можно оптимизировать алгоритм, проверяя диагонали ещё на стадии генерации перестановок.
    Ответ написан
    Комментировать
  • Какой свитч подойдет для 10+ ип-камер с питанием по пое?

    @nfire
    Это просто скопированное и слегка отредактированное описание какой-то конкретной модели. Где вы его взяли?
    Ответ написан
    6 комментариев
  • В чем моя причина провала тестового задания Яндекса?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Ну давайте я покритикую:

    возьмем файлик

    1) вы не разобрались как объявлять методы у прототипов с новой нотацией `class`:

    class Travelsort {
        constructor() {}
        sortTickets(tickets) {}
    }


    2) вы не умеете пользоваться исключениями.
    if (!Array.isArray(cards)) {
        throw new ValueError('Wrong input');
    }


    3) использование let там где должен использоваться const

    4) в принципе использование переменных там где их быть не должно

    5) вы зачем-то реализовали свою функцию сортировки, я не увидел в требованиях отсутствия возможности использовать старый добрый Array.prototype.sort

    6) Общие замечания по кодинг стайлу. snake_case там где должен быть camelCase, пишите с большой буквы то что должно быть с маленькой и т.д.

    7) нарушения принципа единой ответственности. У вас объеткт умеет и сортировать и писать куда-то. Это категорически плохо.

    8) Если исправить 7-ой пункт то наш класс превращается просто в функцию.

    Далее... берем следующий файлик

    1) если вы пишите комментарии к таким маленьким кускам кода - стало быть у вас хромает именование вещей. Все должн быть понятно просто из названий методов/функций/переменных. При работе в команде над серьезными проектами это немаловажно, ибо код чаще читают чем пишут и экономить нужно именно это время.

    2) вы зачем-то тут в прототип объекта строки впихиваете функции для парсинга CSS. Таким образом мы нарушаем принцип единой ответственности. Да и в целом расширять без надобности прототипы объектов как-то не ок.

    Чуть дальше проскролил - вы пытаетесь расширить прототип строк для того что бы добиться API jquery? ух, батенька.

    3) очень много дублирования.

    4) очень плохо с protected variations.

    Справедливости ради, ваш код входит в категорию ">50% JS кода", так что не расстраивайтесь. Просто для работы в яндексе нужен чуть более высокий уровень и понимание вещей.
    Ответ написан
    17 комментариев