https://www.npmjs.com/package/mongoose-plugin-autoinc —--------------------- Посвежее

Спасибо.

помогите решить траблу подробности на кодепен https://codepen.io/Puryk/pen/OQGOaw

помогите решить траблу подробности на кодепен https://codepen.io/Puryk/pen/OQGOaw

Спасибо за токен, можно чекать бота)))

помогите решить траблу подробности на кодепен https://codepen.io/Puryk/pen/OQGOaw

id=msg.chat.id это ид токо кто пишет

from.id лучше не юзать, там может быть и бот написавший тебе

Спасибо за токен, можно чекать бота)))

да похуй что долго нового создать чтоль

да похуй что долго нового создать чтоль

Особенно когда можно сбросить токен xD

id=msg.chat.id это ид токо кто пишет

да там через рекваст делаеться на 23 строке

Короче выше смотри

Особенно когда можно сбросить токен xD

++

++

msg.chat.id юзай

msg.chat.id юзай

как это относиться к тому что я не могу нормально жсон распарсить ?

там вот такая ебала приходит из того что я н7е могу нормально распарсить жсон {"ok":false,"error_code":400,"description":"Bad R equest: message text is empty"}

там вот такая ебала приходит из того что я н7е могу нормально распарсить жсон {"ok":false,"error_code":400,"description":"Bad R equest: message text is empty"}

Потому что нужно строку отправлять 2 параметром в sendMessage

Просто отправь data.title

да я поробовал так но не вкатывало но ок сейчас еше раз попробую

bot.sendMessage(chatId, data.title);

вот сейчас так попробую

но я уже так делал не вкатывало

но я уже так делал не вкатывало

Посмотрел детально твой кусок json, хрен разберешь. Но как я понял там массив статей. Вот и исходи из этого

Посмотрел детально твой кусок json, хрен разберешь. Но как я понял там массив статей. Вот и исходи из этого

++

она там в таком формате должна приходить

https://newsapi.org/docs/get-started

Ну так имея json разбирай что нужно. Это ж просто

data.articles массив. Перебирай его и бери из объекта title. Собирай в некую строку все. Отправлял эту строку боту

так смари какой он приходит

url: 'https://www.bloomberg.com/news/articles/2018-03-02/j-c-penney-foot- locker-pummeled-after-holiday-sales-disappoint', urlToImage: 'https://assets.bwbx.io/images/users/iqjWHBFdfxIU/iKefc1Gw2JL U/v0/1200x800.jpg', publishedAt: '2018-03-02T15:54:06Z' }, { source: [Object], author: 'Natasha Lomas', title: 'MIT study shows how much driving for Uber or Lyft sucks', description: 'Ride-hailing giants Uber and Lyft are delivering pitiful le vels of take-home pay to the hundreds of thousands of US independent contractors providing their..', url: 'https://techcrunch.com/2018/03/02/mit-study-shows-how-much-driving- for-uber-or-lyft-sucks/', urlToImage: 'https://tctechcrunch2011.files.wordpress.com/2017/07/gettyim ages-696625076.jpg', publishedAt: '2018-03-02T15:45:39Z' }, { source: [Object], author: 'Kate Taylor', title: 'LL Bean has raised the minimum age to buy a gun - and it\'s part of a trend that\'s sweeping the industry', description: 'L.L. Bean has followed the lead of Walmart and Dick\'s Spor ting Goods and raised its minimum age for gun sales to 21.', url: 'http://www.businessinsider.com/ll-bean-rei-and-dicks-update-gun-con trol-policies-2018-3', urlToImage: 'https://amp.businessinsider.com/images/5693a784e6183e1d008b8 45c-750-375.jpg', publishedAt: '2018-03-02T13:59:28Z' }, { source: [Object], author: 'Sylvan Lane', title: 'Senators look to Fed chief for support on easing bank rules', description: 'Jerome Powell, a Republican, signaled support for much of t he legislation.', url: 'http://thehill.com/policy/finance/376332-senators-look-to-powell-fo r-support-on-reg-rollback', urlToImage: 'http://thehill.com/sites/default/files/powelljerome_030118gn _lead.jpg', publishedAt: '2018-03-01T21:40:53Z' } ] } Unhandled rejection Error: 400 {"ok":false,"error_code":400,"description":"Bad R equest: message text is empty"}

data.articles массив. Перебирай его и бери из объекта title. Собирай в некую строку все. Отправлял эту строку боту

а может рили так ок спс

Добрый вечер.

🖖

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

Всё на ноде.

Планируется подключить всех по локалке.

Но я подозреваю что есть и другие способы.

А кто по сетям шарит

У меня есть ноут ubuntu с динамическим ip и vds со статикой. Можно как то через vds попасть в ноут?

Через сервер как то пробросить может

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

авторизация, чувак

авторизация, чувак

+

на vds поднять впн и ходить по нему

У меня есть ноут ubuntu с динамическим ip и vds со статикой. Можно как то через vds попасть в ноут?

ssh -l<login> <vds-ip-or-domain> -D<your-local-ip-address>:<port> -C -N пример, ssh -lroot 8.8.8.8 -D192.168.1.11:16777 -C -N в браузере ставишь socks-прокси 192.168.1.1:16777 и будет щастье (ну или поставить, например, 127.0.0.1:9999 - та же фигня будет) п.с... оу.. затупил, надо же наоборот на ноут через vds.. сорян..

еще вариант с динамическим ip - воспользоваться DynDNS сервисами. типа noip.com

клиент можно на роутере заюзать, или поставить програмульку на ноут

/help@ShowJsonBot

/help@ShowJsonBot

Используется MongoDB. На сайте должна быть возможность отправки документов, при этом один документ может быть отправлен нескольким пользователям. Вопрос в следующем, где хранить информацию о том, кому был послан документ? Вижу только два варианта: 1. Создать каждому пользователю отдельное поле documents, которое будет являться массивом и хранить id каждого документа адресованного ему. 2. Каждому документу задать поле receivers, которое будет являться так же массивом, но будет хранить id пользователей, которым адресован документ. Какой из подходов следует использовать?

Используется MongoDB. На сайте должна быть возможность отправки документов, при этом один документ может быть отправлен нескольким пользователям. Вопрос в следующем, где хранить информацию о том, кому был послан документ? Вижу только два варианта: 1. Создать каждому пользователю отдельное поле documents, которое будет являться массивом и хранить id каждого документа адресованного ему. 2. Каждому документу задать поле receivers, которое будет являться так же массивом, но будет хранить id пользователей, которым адресован документ. Какой из подходов следует использовать?

Думаю тебе стоит использовать метод FTS - Fuck This Shit

в первом случае секс возникает при удалении (например) документа во втором случае секс возникает при каждом запросе документа для конкретного пользователя

Думаю тебе стоит использовать метод FTS - Fuck This Shit

блэт, я уже пошел гуглить, что такое FTS

в первом случае секс возникает при удалении (например) документа во втором случае секс возникает при каждом запросе документа для конкретного пользователя

А что если сделать и то и другое? Вроде как меньше оргии должно получиться.

тогда и там и там будет секс)

ну вот да, монга немножко посасывает, когда нужно запилить связи между коллекциями

тогда и там и там будет секс)

Эмм, почему?

А что если сделать и то и другое? Вроде как меньше оргии должно получиться.

смотри. тебе нужно ограничить доступ к документу для юзера Илья тебе нужно сунуться и в юзера Илья, и в документ.recievers и кикнуть оттуда илью

смотри. тебе нужно ограничить доступ к документу для юзера Илья тебе нужно сунуться и в юзера Илья, и в документ.recievers и кикнуть оттуда илью

Это ведь лучше, чем перебирать 100000 документов в поисках Ильи. Всего пару запросов, и всё, разве не так?

а в каком случае тебе придется перебирать 100000 документов в поисках ильи ?

а в каком случае тебе придется перебирать 100000 документов в поисках ильи ?

В случае, если имя "Илья" записан в документе, и мне его нужно оттуда удалить.

Используется MongoDB. На сайте должна быть возможность отправки документов, при этом один документ может быть отправлен нескольким пользователям. Вопрос в следующем, где хранить информацию о том, кому был послан документ? Вижу только два варианта: 1. Создать каждому пользователю отдельное поле documents, которое будет являться массивом и хранить id каждого документа адресованного ему. 2. Каждому документу задать поле receivers, которое будет являться так же массивом, но будет хранить id пользователей, которым адресован документ. Какой из подходов следует использовать?

Ни один из этих двух?

Это, конечно, монга, но разве нельзя сделать еще одну таблицу, в которой будет инфа о том, кому отправлен документ?

Ни один из этих двух?

Чего в замен предлагаете?

Куда меньше секса будет и при поиске и при удалении

Это, конечно, монга, но разве нельзя сделать еще одну таблицу, в которой будет инфа о том, кому отправлен документ?

Никак не могу себе этого представить. Почему в таком случае нельзя в документе описать получателей?

смотри, какой финт ушами я те придумал берешь и пилишь коллекцию docpermissions в которой userId documentId

Два поля: user_id, document_id

На каждого получателя по записи

смотри, какой финт ушами я те придумал берешь и пилишь коллекцию docpermissions в которой userId documentId

ну ладно, все придумано до меня (

Вообще, конечно, лучше взять БД вместо монги и не парить мозг (:

аминь. год блесс скл

Два поля: user_id, document_id

Значит если "doc1" отправили Васе, Пете и Кате, то записываем в следующем виде: "Катя" : doc1, "Петя" : doc1, "Вася" : doc1, ?

нет

смотри, какой финт ушами я те придумал берешь и пилишь коллекцию docpermissions в которой userId documentId

😂😂

В виде трех строк: user_id: Катя, doc_id: doc1 user_id: Петя, doc_id: doc1 user_id: Вася, doc_id: doc1

(ну, трех документов)

Как там в монге записи именуются

В виде трех строк: user_id: Катя, doc_id: doc1 user_id: Петя, doc_id: doc1 user_id: Вася, doc_id: doc1

вот да. если нужно взять по юзеру - ищешь в этой коллекции по юзеру, если по доку - ищешь по доку. удалить док - поиск по доку+удалить всех

такая, буферная коллекция для двунаправленной связи

вот да. если нужно взять по юзеру - ищешь в этой коллекции по юзеру, если по доку - ищешь по доку. удалить док - поиск по доку+удалить всех

И под новый док, писать новый user_id, если он даже существует, верно?

И под новый док, писать новый user_id, если он даже существует, верно?

Пардон, что?

Например, есть doc2 и он адресован Пете. Мы просто вставляем новую строку user_id: Петя, doc_id: doc2.

В виде трех строк: user_id: Катя, doc_id: doc1 user_id: Петя, doc_id: doc1 user_id: Вася, doc_id: doc1

нужно выдать все доки юзеру - ищешь по user_id нужно выдать всех юзеров в этом документе - ищешь по doc_id