Привет народ, подскажите, вот это вот работает через хуки? https://github.com/go-telegram-bot-api/telegram-bot-api

Привет народ, подскажите, вот это вот работает через хуки? https://github.com/go-telegram-bot-api/telegram-bot-api

Работает

Привет народ, подскажите, вот это вот работает через хуки? https://github.com/go-telegram-bot-api/telegram-bot-api

На вопрос "как?" - смотри тамошние доки

То что работает, я надеюсь)) Вопрос не об этом, это через хуки, или в цикле опросы крутит?

Там буквально в ReadMe содержится рабочий пример

Я не знаю Го, поэтому код не смотрел.

То что работает, я надеюсь)) Вопрос не об этом, это через хуки, или в цикле опросы крутит?

Вроде как данные на канал слушает. В обычном режиме ежесекундно опрашивает на наличие новых событий

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

А, да, нашёл If you need to use webhooks (if you wish to run on Google App Engine), you may use a slightly different method.

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

Бред не бред, но так работают боты, которые не могут себе позволить сертификаты

Бред не бред, но так работают боты, которые не могут себе позволить сертификаты

для таких ботов летом стартует один проект..

для таких ботов летом стартует один проект..

Звучит интересно, но всё упирается в вопрос доверия

сейчас в ЗБТ

Звучит интересно, но всё упирается в вопрос доверия

тоже верно

Бред не бред, но так работают боты, которые не могут себе позволить сертификаты

А разве они на самоподписанных не работают?

А разве они на самоподписанных не работают?

Работают, но там свои ньюансы

Какие?

Какие?

Точно не помню, но слегка больше ограничений должно быть, чем если бы ты по чесноку юзал обычные сертификаты

Хм, бред.

Тут топай в доки самого телеграм

Хм, бред.

Как по мне - всё честно

Бред в смысле про ограничения. Всё также работает: Примечание: При подключенном и настроенном вебхуке метод getUpdates не будет работать. При использовании самоподписанного сертификата, вам необходимо загрузить публичный ключ с помощью параметра certificate. На текущий момент отправка обновлений через вебхуки доступна только на эти порты: 443, 80, 88, 8443.

https://tlgrm.ru/docs/bots/api#setwebhook

https://tlgrm.ru/docs/bots/api#setwebhook

Желательно смотреть доки самого телеграма, а не любительские пересказы и переводы. Мало ли

А так - ну, раз нет, то нет. Но с ключами всё равно придётся повозиться

Да нормально уже давно все с сертификатами в Телеграме, что с доверенными, что с самоподписанными

С сертификатами для ботов, в смысле. Имеешь только самоподписанный сертификат - не проблема, при коннекте отправляешь его на сервер и все, тебя там знают по этому сертификату.

Ну да, я тоже так думаю.

✌️

Ребят, буду оч благодарен за совет. Делаю экспорт данных из БД в несколько форматов. Есть порядка 100 табличек в БД, каждая является либо родителем либо дочерней таблицей для другой таблицы, отношения почти везде один-ко-многим Выглядит так что неплохо написать функцию для сбора мапы объектов какого-то типа и последующего наполнения страктов, но не пойму как без рефлексии наполнять стракты разных типов, у них же разное количество и тип полей. Есть конечно вариант написать 60-80-100 функций, которые будут наполнять стракт нужного типа из среза sql.Rows, но какое-то странное решение на мой взгляд

сделай с рефлексией. даже делать ничего не надо, ормы именно это и делают.

А производительность не сильно упадет?

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

можешь сделать кодогенерациюх этих 60-80-100 функций

более по-русски было бы тогда уж писать "структы", чо мелочиться-то? :)

и "функи"

более по-русски было бы тогда уж писать "структы", чо мелочиться-то? :)

По делу нечего сказать?)

по делу уже сказали.

по делу уже сказали.

И поэтому надо докопаться до общепринятого сленга? Логика!

да я что? Пиши "стракты", если нравится. :)

я просто минуту думал, что это вобще такое :)

можешь сделать кодогенерациюх этих 60-80-100 функций

Была еще идея сделать фейковый интерфейс и на каждый стракт по пустой функции, чтобы потом их можно было в один массив под эгидой полиморфизма запихнуть. Но это не решает проблему что во всех таблицах разные поля, и это тоже надо как-то по страктам распихивать.

может сделать без страктов на пустых интерфейсах? эти стракты как-то из схемы бд еще расписывать придется ведь.

Вот именно

может сделать без страктов на пустых интерфейсах? эти стракты как-то из схемы бд еще расписывать придется ведь.

Интерфейсы это дорого.

Но стракты вроде сами напрашиваются, очень уж удобный их экспорт в разные форматы, добавил дескрипторы и вперед

можно попробовать нагенерировать дефинишны страктов вместе с конструкторами по sql-схеме

И, если честно, меня немного пугает что в чате "pro.go" запускают курс "базовый js"

можно попробовать нагенерировать дефинишны страктов вместе с конструкторами по sql-схеме

Ну т.е. возвращаемся опять к кодогенерации. Что в принципе не самый худший вариант, насколько я понимаю производительность при этом не упадет

но вероятно это будет не очень-то просто, особенно со связями между таблицами, и если все эти 100 таблиц эволюционировали и создавались разными людьми в разное время.

Ну т.е. возвращаемся опять к кодогенерации. Что в принципе не самый худший вариант, насколько я понимаю производительность при этом не упадет

Вернее из всего предложенного она будет максимальной

но вероятно это будет не очень-то просто, особенно со связями между таблицами, и если все эти 100 таблиц эволюционировали и создавались разными людьми в разное время.

Не, тут просто. Уровней вложенности как правило 2, изредка 3 Есть старые куски кода на пхп с которых можно взять пример связей

Как насчет варианта не играть в типы и просто взять питон

Не любитель я питона

Perl?

Да и какой вопрос перфоманса

Весь перфоманс будет в ио

И там вопрос производительности сильно влияет на смысл всей затеи

)

Весь перфоманс будет в ио

Там перформанс да, в ио и в склеивании мап по сути

И там вопрос производительности сильно влияет на смысл всей затеи

Слишком гиперболизируешь мимопитонодрочер

ERROR: S client not available

В общем, при такой сложной базе, чтобы все было аккуратно, проще написать типовую прогу, которая сначала будет лезть в стракту базы и строить стракты и относящиеся к ним фанки в отдельном файлике под эту базу. После чего и юзать. Или рефлексировать по посинения

при чем, очень может быть, что кто-то такое уже и писал. поискать можно

при чем, очень может быть, что кто-то такое уже и писал. поискать можно

Спасибо за дельный совет

Поищу, мб свое напишу. База - почти монга, это геймдев где сущностей до задницы и связей между ними тоже, но экспорт очень уж долгий, хочется ускорить. Запросы к БД можно(и нужно) пускать параллельно т.к. они по сути независимы.

смысл в параллелизме при импорте? На передачу данных больше времени уйдет, чем на обработку в экспортный вид. про io намекали уже

параллелизм хорошо только при ловле блох, как-то так старики поговаривали, кажется :)

смысл в параллелизме при импорте? На передачу данных больше времени уйдет, чем на обработку в экспортный вид. про io намекали уже

Как-то не увидел тут противоречий. Запросы долгие, идут последовательно. Данных много, но не убийственно, в 2Гб оперативки пока укладывались при экспорте. Если параллельно запускать - все упрется в длительность запроса + передачу данных + оверхед на склейку данных. Умозрительно пока выглядит в разы быстрее чем есть сейчас.

а откуда возьмутся данные-то для параллельного "склеивания", если запросы долгие? :)

а откуда возьмутся данные-то для параллельного "склеивания", если запросы долгие? :)

А там много данных независимых. Который можно параллельно выбрать и потом в один стракт запихнуть.

Склеивать нужно по сути только связанный таблицы, которых не так много. Ну т.е. условно 100 таблиц, из них если разбить по связям останется 30 корневых и 70 дочерних. 30 пускаем параллельно со сборкой дочерних

Ну, что ж... если параллельная обработак поможет загрузить сервер db не на долго, но за то полносью - то, конечно, обязательно надо так и сделать! Это радует, если удается что-то заставить поработать по полной. :)

а то понаделали мощных сервеаков, которые даже питоном не нагрузишь... блин, вон все на Django пишут.. В общем, это ужасно, конгда сервер простаивает!

Сервак не сказать что мощный, но судя по эксплейнам - бд больше времени тратит на поиск, нежели на передачу данных. И от параллельности тут должен быть приличный выигрыш.

Всем привет, уже просто устал искать решение. Как получить доменное имя по айпи?

Всем привет, уже просто устал искать решение. Как получить доменное имя по айпи?

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

Всем привет, уже просто устал искать решение. Как получить доменное имя по айпи?

Какое из?

На один адрес может ууазвать сотни имен

все

Точнее неограниченное количество

все

Никак

Такова природа днс. Есть отдельные решения, но они очевидно не дают 100% результат

Даже до 80% не дотянет

Всем привет, уже просто устал искать решение. Как получить доменное имя по айпи?

dig -x 173.194.220.102 ;; ANSWER SECTION: 102.220.194.173.in-addr.arpa. 86387 IN PTR lk-in-f102.1e100.net. Не?

И прилетаешь на облако

это не решает задачу если кастомный resolv.conf

Если пользователь IP-адреса не озаботился тем, чтобы сделать соответствующую PTR-запись, то никак не узнать.

кастомный resolv.conf?

а некастомный - это какой? nameserver 8.8.8.8 ? :)

Строго говоря, если у кого-то такой кастомнай resolv.conf, что он не в состоянии пользоваться DNS - сам себе буратино, что ж поделаешь?