https://github.com/nodejs/citgm

А можно как-то закрутить swagger чтобы он только генерил доки, по уже существующей апи, просто мне очень не нравится идея автоматической генерации роутов, через swagger, и я не понимаю почему нельзя просто прописать анотацию и получить на выходе простые доки

Друзья, кто знает примеры open-source, библиотек и Starter Kits для Telegram-ботов вне зависимости на любом языке программирования. Чтобы всем было удобней - создал curated-list. Добавляйте и подписывайтесь на обновления: + https://github.com/DenisIzmaylov/awesome-telegram-bots

Добавил примеры с Node.js :) Если кто делал бота и хочет его опубликовать на GitHub, то самое время :)

@DenisIzmaylov Делал бота для взаимодействия Jira и Telegram. Шлет сообщения в канал, например при создании тикета. https://github.com/A11oW/telegramChannelBot

Фантастика! Круто. Добавишь его в список? :)

Отправил пулл реквест

Замерджил :) Спасибо ?

Пожалуйста =)

? Парни, берите пример! :)

хах

у много ботов делал, но вот что-то публиковать на гитхаб не осмеливался

Смелей, откройся миру :)

Ну, надо смотреть правде в глаза, кому вообще нужны мои сурсы, они же кривые

не откроешь, не узнаешь :)

Зря ты так. Найти что то кривое и подпилить под себя чуточку проще, чем совсем с 0 делать, и да, появится фидбэк где нужно подтянуть. Рост быстрее будет.

Как-то в твиттере прочитал что-то в духе: "Боитесь выкладывать свой код на гитхаб, потому что его увидят и обсмеют? Не бойтесь, на самом деле никто его все равно смотреть не будет" :)

Зря ты так. Найти что то кривое и подпилить под себя чуточку проще, чем совсем с 0 делать, и да, появится фидбэк где нужно подтянуть. Рост быстрее будет.

+100500

Парни, ещё раз всем спасибо за Pull Requests! Список начал серьезно расти. Работодатели уже начали посматривать на примеры ваших ботов, так что будьте готовы к неожиданным приятным предложениям. :)

@DenisIzmaylov Делал бота для взаимодействия Jira и Telegram. Шлет сообщения в канал, например при создании тикета. https://github.com/A11oW/telegramChannelBot

у нас тут в обсуждении родилось название для твоего бота: Teleslack

=) примерно для этого его и сделал. Раньше работали в слэке был бот. Потом переехали в телеграм, бота не стало.

Всем привет. Александр Бурцев PM в МФТИ ЦИОТ, образовательные платформы. CEO BramaBrama.com разработка web сервисов на Python/Django. Есть задачи в области mobile dev. Узнал о группе через канал devconf, где делал доклад по конвейерной разработки сложных web-проектов.

@DenisIzmaylov Потерялся раздел с Node.js примерами (затерся Rust). сделал пул реквест.

Всем привет) Подскажите а чем сейчас лучше писать сервер? Что юзать для роутинга? что для работы с базой данных? Может есть полноценные фреймворки? Было было круто с поддержкой es2016+. Задача - небольщой restApi сервер + работа с сокетами

go (на nodejs: hapi + sequelize + socket.io/sockjs)

@DenisIzmaylov Потерялся раздел с Node.js примерами (затерся Rust). сделал пул реквест.

Да, спасибо, что заметил :)

go (на nodejs: hapi + sequelize + socket.io/sockjs)

вопрос именно про nodejs) Go не расмариваем

А что именно подразумевается под es2016? es7?

да

А что собственно подразумевается под поддержкой es2016?)

es6, es7 можно через тот же babel норм использовать.

А что собственно подразумевается под поддержкой es2016?)

мне кажется что промисы

Просто вопрос поставлен так

Ну

Как сказать

Что на него нкак и не ответить)

Что значит с поддержкой es2016?

Любая либа из нпа будет так или иначе работать с языком, он же обратно совместим

Чем версия ноды новее, тем больше новых фич из коробки

Если хочется использоавть фичи, которых из коробки нет - тогда babel

Вариантов не так много)

Можно писать хоть на es3, хоть на 2033, это же зависит исключительно от версии ноды

А так есть модный Koa

(который уже устарел)

и теперь есть koa2 где они вернулись обратно от yield к промисам

ну вот к примеру koa2 неплохо работает с генераторами и async/await

Как по мне, так страый добрый express из зе бест

поиспользуй его с генераторами, угу

Но зачем?

Незачем? Ну ок, используйте голые промисы дальше

Это не ответ.

Вполне себе ответ. Если ты не видишь проблемы, то ты с ней не столкнулся

Так в чем их проблема-то?

Если не считать синтаксического мусора, то хреново реализовывать любую нетривиальную (выходящую за цепочку последовательных вызовов и их параллельных (all/any) комбинаций) логику.

ой ладно вам. На промисах писать нетривиальную логику одно удовольствие

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

Промисы, конечно, тоже не панацея

Если нужен какой-нибудь асинхронный map, то я обычно обращаюсь за помощью к async caolan'a

на async await гораздо проще делать очень много вещей

на async await гораздо проще делать очень много вещей

Это понятно, но async/await это все же сахар для промисов

нет, это сахар для генераторов

+

Генераторы это способ писать аля синхронный код. Попробуй написать на промисах долгий запрос, параллеьно с которым идут несколько запросов, каждый из которых может сфейлится и пока выполняется первый, их нужно повторить, если сфейлились оба, то запустить долгий запрос заново. Ну и т.д. Я не говорю, что прям вот везде менять надо промисы на промисы+async-await, наборот —- в большинстве случаев не надо это делать просто ради того, чтобы делать. Но и пилить что-то с нуля на промисах, когда есть async-await я смысла не вижу

хз, я вообще сейчас .then не юзаю

Генераторы это способ писать аля синхронный код. Попробуй написать на промисах долгий запрос, параллеьно с которым идут несколько запросов, каждый из которых может сфейлится и пока выполняется первый, их нужно повторить, если сфейлились оба, то запустить долгий запрос заново. Ну и т.д. Я не говорю, что прям вот везде менять надо промисы на промисы+async-await, наборот —- в большинстве случаев не надо это делать просто ради того, чтобы делать. Но и пилить что-то с нуля на промисах, когда есть async-await я смысла не вижу

подобное надо делать на потоках) rxjs

В том-то и дело, что не сделаешь это на потоках. А где сделаешь, там они и не нужны

ERROR: S client not available

что не сделаешь?

хз, я вообще сейчас .then не юзаю

Вот кстати сам then (который по факту map, ибо промис тоже реализует функтор) имеет проблему: логика пишется как бы с двух сторон: и по присваиваниям (промисы) и по транформациям (действие, которое передаёшь в then)

В отличие от

*flatMap

Ну, "map" я применил скорее как fmap. А что за ним, map или flatMap это не суть

нет, это сахар для генераторов

Позвольте с вами не согласится, это как раз таки сахар для промисов

https://github.com/tc39/ecmascript-asyncawait

И?

Так же на всех async function можно будет вызывать Promise.all()

И?

И?

Что и? Я просто сказал, что async/await это сахар для промисов, а не для генераторов

Это не так) промисы как есть, так и остались

Да

А функции, которые помечены как async, будут отдавать промисоподобный объект

Помимо того, все промисы можно будет await'ить

1. Появились промисы

2. Появились генераторы

3. Генераторы стали использовать, чтобы запускать промисы

4. Для генераторов сделали сахар - async-await

Что и? Я просто сказал, что async/await это сахар для промисов, а не для генераторов

Бред

Это на генераторах

Обычные продолжения

Функции, из которых можно выйти и снова войти

aka continuation

Генераторы с промисами позволили это реализовать

Так, народ, кто охренел?

@DenisIzmaylov Ты дорекламировался телеграм-ботов =).

И что случилось?)

https://www.npmjs.com/package/botfather кто-то добрый скриптом публикует в нпм раз в 10 минут одну и ту же версию.

59 коммитов, 4125 релизов.

Причём статистика загрузок npm сейчас выглядит так: https://gist.github.com/ChALkeR/bc93a9fc32d5486cee6c3e152ee16593

А как так происходит?)