Anonymous
Так где ?
倫太郎
𝓖0𝓹43𝓡
Чёт в голос
sho?
Alexander
а никто jade/pug в связке с webshot не использовал? не могу понять, почему bootstrap не цепляется нормально
Alexander
вот так всегда, стоит пустить волну и решение находится сразу. Сменил 3.3.7 на 4.0beta и всё подцепилось
B
господа, кто-нибудь сталкивался с проблемами при установке mongodb на macos?
Alexander
в чем проблема?
Denis
🎁🎅🏽 Санта существует! 10 и 11 декабря в Москве состоится JavaScript-конференция HolyJS 2017 Moscow и специально среди участников наших JavaScript-сообществ в Telegram мы проводим розыгрыш трёх билетов. 🎉
1. https://t.me/react_js
2. https://t.me/reactnative_ru
3. https://t.me/js_ru
4. https://t.me/angular_ru
5. https://t.me/nodejs_ru
👉 Но сначала пару слов, о самой конференции.
HolyJS проводится уже не первый раз в Москве и собрала множество хороших отзывов. В этот раз, более 500 JavaScript-разработчиков соберутся под одной крышей для того, чтобы обсудить новости стремительно развивающейся экосистемы мира JavaScript, свежие инструменты, фреймворки, паттерны и сотни обновлений с экспертами со всего мира.
🎓 Доклады будут посвящены технологиям мира JavaScript: от фронтенда до бэкенда, от облачных технологий до десктоп-приложений. Все участники HolyJS смогут лично пообщаться со знаменитыми спикерами:
— Отец JSON Douglas Crockford, человек, без которого невозможно представить современный JavaScript;
— Lea Verou, создатель множества фреймворков и автор книг и статей по фронтенду и дизайну (http://lea.verou.me/);
— Виталий Фридман, основатель и главный редактор Smashing Magazine;
— Azat Mardan, автор множества книг, среди которых такие бестселлеры как "React Quickly", "Full Stack JavaScript", "Practical Node.js" и "Pro Express.js";
— Gerard Sans, Google Developer Expert, известный тренер и Angular-активист;
— Minko Gechev, сооснователь Rhyme.com и автор нескольких книг по Angular.
Программа конференции уже готова! Программа и регистрация: https://holyjs-moscow.ru/
🎸 Теперь к розыгрышу подарочного билета на оба дня конференции. Для принятия участия достаточно заполнить форму ниже. Приём заявок завершится в четверг, 7 декабря, в 23:59.
👉 Выигранный билет нельзя обменять/продать или передать. В случае, если вы по какой-то причине не сможете воспользоваться билетом, сообщите организаторам - https://t.me/DenisIzmaylov
📮 Победитель будет выбран случайным образом. Ваши имя и фамилия будут опубликованы, в случае победы, все остальные ответы - конфиденциальны.
🚀 Готовы? Заполняйте: https://goo.gl/forms/iBGRAgqEWsv46WUt2
Итак, всего всё получили 116 заявок. Это говорит о высоком интересе к данной конференции, с чем можно поздравить организаторов, а мы в свою очередь Поздравляем победителей в нашем сообществе:
1. Антон Косых
2. Фролкин Иван
3. Максим Шаммасов
Поздравляем ребят с победой! 🎉
Если кто-то из них не сможет быть на конференции (= не подтвердит до 14:00 Мск), то билет по порядку уходит:
1. Олег Гамега
2. Алексей Тихонов
3. Даниил Высоцкий
Спасибо всем за активность и участие!
Запись скринкаста розыгрыша билета: https://monosnap.com/file/u3zm6cDtpb3UWexVbBqBhoqgagCNKf
Mihail
Товарищи, мне нужно вытаскивать данные из 2х разных баз, из postgresql и mongo. Поддерживаемое одновременное подключение к 2м базам моим нод процессом плохая практика, и нужно сделать 2 разных бекенда, или же объединить все в одно нормальный вариант и не скажется на производительности именно с точки зрения поддержки подключения?
Таймураз
Товарищи, мне нужно вытаскивать данные из 2х разных баз, из postgresql и mongo. Поддерживаемое одновременное подключение к 2м базам моим нод процессом плохая практика, и нужно сделать 2 разных бекенда, или же объединить все в одно нормальный вариант и не скажется на производительности именно с точки зрения поддержки подключения?
Одним процессом вполне нормально. Тем более- если того требует задача
Mihail
Спасибо за ответы👍
Sergey
Товарищи, мне нужно вытаскивать данные из 2х разных баз, из postgresql и mongo. Поддерживаемое одновременное подключение к 2м базам моим нод процессом плохая практика, и нужно сделать 2 разных бекенда, или же объединить все в одно нормальный вариант и не скажется на производительности именно с точки зрения поддержки подключения?
Я даже больше скажу, поддержка одним процессом десятка подключений к одной БД - нормальная практика
Владислав
народ подскажите, мож кто видел под ноду готовый пакет, нужно рекурсивно пройтись по вложенным папкам на диске и создать базу данных, с возможностью правки в описании файлов, ну и с выводом в вебморду а еще хотелось бы по сети через вебморду загружать и скачивать файлы с диска
Макс
подскажите либу для собирания проекта в один экзешник
Таймураз
Я даже больше скажу, поддержка одним процессом десятка подключений к одной БД - нормальная практика
Он про две разные говорит
Cenator 🐈
На два сервиса из-за подключения бд ты предложил делить
А чому бы нет? Микросервисная архитектура же
Таймураз
Ну так если к одной норм, то и к разным тоже норм
пулинг соединений может быть в несколько строк конфига решен, а вот работу с разными источниками данных уже не так просто расписать
Sergey
Он же не спрашивает насколько это сложно, он спрашивает нужно ли так делать
Nikolay
А чому бы нет? Микросервисная архитектура же
Ага, чем больше сервисов, тем меньше общая надежность системы :)
Таймураз
А чому бы нет? Микросервисная архитектура же
Нахрена усложнять там, где это не требуется?) Микросервисная архитектура- не о файле на сервис
Gleb
Ага, чем больше сервисов, тем меньше общая надежность системы :)
Наоборот. Микросервисный подход это самый действенный подход уменьшить зацепление и повысить связанность. Марсимальная надёжность и масштабируемость, возможность использовать кучу языков и БД. Но да, нужно уметь готовить, впрочем как и везде.
Таймураз
Он же не спрашивает насколько это сложно, он спрашивает нужно ли так делать
Он спрашивает, правильно ли подключаться к двум разным разам из одного приложения
Ты же начал говорить о пулинге
Это абсолютно разные вещи
Таймураз
Наоборот. Микросервисный подход это самый действенный подход уменьшить зацепление и повысить связанность. Марсимальная надёжность и масштабируемость, возможность использовать кучу языков и БД. Но да, нужно уметь готовить, впрочем как и везде.
Он прав
Чем больше различных сервисов- тем сложнее система
Таймураз
Ты все правильно сказал, но слово "наоборот" неуместно
Таймураз
У нас в проекте приняли решение- сделать проект-"прослойку", который выполняет часть бизнес-логики над нашим проектом. В итоге я уже который месяц не могу запушить обновления, потому что нужно под мои изменения переписывать проект, который я в глаза не видел (это третий проект, с которым "прослойка" так же коммуницирует)
Gleb
Он прав
Чем больше различных сервисов- тем сложнее система
Если области ответственности сервисов правильно распределены, то это просто означает сложность проекта в общем. Монолит будет ещё сложнее.
Таймураз
Если области ответственности сервисов правильно распределены, то это просто означает сложность проекта в общем. Монолит будет ещё сложнее.
Дык я не об этом
И тот чувак не об этом
Gleb
У нас в проекте приняли решение- сделать проект-"прослойку", который выполняет часть бизнес-логики над нашим проектом. В итоге я уже который месяц не могу запушить обновления, потому что нужно под мои изменения переписывать проект, который я в глаза не видел (это третий проект, с которым "прослойка" так же коммуницирует)
А поднять 2 копии инстансов на 2 мажорных релиза и 2 базы на крайняк что мешает?
Таймураз
Надежность падает из-за монолитного решения- тяжелее поддерживать
А также надежность падает из-за необходимости коммуникации между процессами
Таймураз
А поднять 2 копии инстансов на 2 мажорных релиза и 2 базы на крайняк что мешает?
Нехватка ресурсов
С этим тут тоже тяжело
Таймураз
Я заебал тут всех
В итоге к январю мощности в 3 раза вырастут и можно архитектуру менять будет без нервов
Nikolay
Таймураз
Надежность падает из-за монолитного решения- тяжелее поддерживать
А также надежность падает из-за необходимости коммуникации между процессами
Так вот- в идеале нужно найти золотую середину
Nikolay
А не связанность :)
Nikolay
> Надежность падает из-за монолитного решения- тяжелее поддерживать
норрмально написанный монолит поддерживать на порядок проще, чем пачку сервисов при равных ресурсах
Gleb
Таймураз
Anonymous
ребят, подскажите пожалуйста, кто работал с mandrill и шарит в .pdf)
отправляю в письме attachment, type: 'application/pdf', name - не важно, content - содержание файла в base64, но получаю какую-то кашу:
http://dl3.joxi.net/drive/2017/12/09/0007/0175/463023/23/8de4a84a61.jpg
Dmitry
когда пишите веб приложения на ноде, используете ли подход выноса бизнес логики в слои, которые ничего не знают про http и могут рабоать с любыми интерфейсами, либо все пилите сразу и только на уровне http в контроллерах?
я разбиваю и выношу минимальные проверки на уровень роутинга
что переменные есть, они определены и всякое такое
такой код проще
- писать
- покрывать unit тестами
Алексей
Всем привет, кто нибудь пользуется time tracker'oм, можете посоветовать какой нибудь? (windows, webstorm)
Eugene
toptal
Mari
Всем привет, первый междунарождный хакатон Минск-Мадрид в IMAGURU startup hub ищет удаленных фронтендов в команды в испании и минске. Сегодня и завтра до трех, все, кому интересно присоединяйтесь и пишите в наш канал: https://t.me/blockchainthonby. О хакатоне https://imaguru.by/event/imaguru-blockchain-hackathon-2/ , https://www.facebook.com/events/337942503338814/
Nurik
Надежность падает из-за монолитного решения- тяжелее поддерживать
А также надежность падает из-за необходимости коммуникации между процессами
Бизнес логика обычно монолитна. Т.е. там много последовательных проверок и условий. То что микросервисы надежнее это миф. Если чисто логически сервис можно отнести к third party - тогда впринципе можно выносить, иначе всё станет только сложнее. И будет какой-нибудь SOA с ESB в комплекте.
Alex
Бизнес логика обычно монолитна. Т.е. там много последовательных проверок и условий. То что микросервисы надежнее это миф. Если чисто логически сервис можно отнести к third party - тогда впринципе можно выносить, иначе всё станет только сложнее. И будет какой-нибудь SOA с ESB в комплекте.
Не всегда. Бывает бизнес логика состоит из нескольких несвязных кусков. Там работа с оповещениями, вариация на тему цмс и система геймификации.
Alex
Но есть хороший тезис что сервисы надо не проектировать а выносить
ilya
я верно понимаю что получение и парсинг POST зпросов в NodeJS то по сути и есть создание REST API?
Alex
ilya
А тело уже исполняет ф-и исходя из параметров зпроса
Alex
Rest это способ организации ваших апи для работы с сущностями
Alex
А то что вы описали это обработка пост запроса))
Nurik
Не всегда. Бывает бизнес логика состоит из нескольких несвязных кусков. Там работа с оповещениями, вариация на тему цмс и система геймификации.
Оповещения можно отнести к third party. А можно пример, где бизнес логика состоит из нескольких кусков ? Просто я плохо себе это представляю.
Alex
Ну вот то что я описал это части живого проекта. Просто когда он долгоиграющий а клиент с фантазией проект растет. У меня сейчас есть cms, регистрация на конференции, каталог, тесты, оправка назначений пациентам (система для ветеринаров), набор баллов за активность, оповещалки, управление пользователями, работа с разными справочниками, интеграция с разными платформами
Alex
Плюс ещё сборка отчётов со всего этого добра, что тоже хорошо бы в сервис вынести
Nurik
А есть например зависимый элемент бизнес-логики, который вынесен в отдельный сервис ? Т.е. например пользователь может купить что-то, ТОЛЬКО в случае, если у него есть соответсвующие баллы в системе, которые достаются из другого сервиса при этом проверка на наличие балов тоже там же?
Nurik
Ну вот то что я описал это части живого проекта. Просто когда он долгоиграющий а клиент с фантазией проект растет. У меня сейчас есть cms, регистрация на конференции, каталог, тесты, оправка назначений пациентам (система для ветеринаров), набор баллов за активность, оповещалки, управление пользователями, работа с разными справочниками, интеграция с разными платформами
Вот тут да, можно вынести. Но опять же бизнес логика всё равно остаётся монолитной, даже если мы ее выносим в сервисы.
ilya
Если мне необходимо сделать DB для приложения на несколько параметров (совсем небольшая), то я могу ограничиться серваком NodeJS и просто примнимать запросы с параметрами для CRUD ?
ilya
Потому как очень сложно разобраться, слишком все разнопланово в Node, нет четких стандартов.
ilya
А мне надо быстро развернуть все.
Alex
Вот тут да, можно вынести. Но опять же бизнес логика всё равно остаётся монолитной, даже если мы ее выносим в сервисы.
Ну глобально да. Сейчас как раз все доработки перевожу из монолита в сервисы. В ядре по идее надо оставить пользователей/авторизацию, а все остальное скидывать дальше. Ну и по хорошему сервисы как и модули должны иметь иерархию без циклических зависимостей
ilya
Овтетьте мне, а то я повешусь скоро от этой темы всей, я еле начил Node POST принимать нормально.
Alex
Овтетьте мне, а то я повешусь скоро от этой темы всей, я еле начил Node POST принимать нормально.
https://www.google.com/amp/scotch.io/amp/tutorials/build-a-restful-api-using-node-and-express-4
ilya
https://medium.freecodecamp.org/building-a-simple-node-js-api-in-under-30-minutes-a07ea9e390d2
ilya
https://www.codementor.io/olatundegaruba/nodejs-restful-apis-in-10-minutes-q0sgsfhbd
ilya
Вот не могу выбрать за 10 минут хочу или за 30
ilya
Нет, но немного предстваляю что это
Alex
Это орм
Alex
https://github.com/alQlagin/code-factory/blob/master/README.md моя давняя наработка, для быстрого старта может сойдет
Nurik
Овтетьте мне, а то я повешусь скоро от этой темы всей, я еле начил Node POST принимать нормально.
Сформулируй вопрос, чтобы можно было понять, что тебе нужно, а уже исходя из этого можно будет тебе что-то посоветовать.
ilya
Сформулируй вопрос, чтобы можно было понять, что тебе нужно, а уже исходя из этого можно будет тебе что-то посоветовать.
Если мне необходимо сделать DB для приложения на несколько параметров (совсем небольшая), то я могу ограничиться серваком NodeJS и просто примнимать запросы с параметрами для CRUD ?
ilya
Нужна DB