Сохранение значения переменных в SaleBot при перезапуске/повторной отправке блока.

Пока разбирался с одной из задач, возникла необходимость сохранить значения переменных если человек повторно заходит в тот или иной блок.

Допустим нужно отправить человеку ссылку на канал. Через калькулятор можно сгенерировать новую, но вот вопрос, а зачем плодить эти ссылки (если они не одноразовые)?

isFirst = if (isFirst == None, 'default', isFirst)

Вот такая нехитрая конструкция отлично справляется с задачей. Если у пользователя нужной переменной не существует — её значение при проверке будет None.

Соответственно проверяем, и если переменной не существует - она будет создана с значением по умолчанию.

Если же переменная на момент проверки уже существует, тогда переменной будет присвоено значение самой себя и перезаписи/обнуления не произойдет.

Возможно кому и очевидная вещь, но сегодня эта конструкция просто сделала мой день =)

Так что забирайте, если кто не знал 🤝

#лайфхак

Друзья, коллеги, я вот тут пока без контента.

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

А ещё смуту наводить не охота, но неделя пока идет, будто колдуна нахер послал напряженная.

Уже был отчасти пост у меня посвященный тому, что практически все работает, мягко говоря, не стабильно. Дак вот и дальше подкидывают дровишек.

Есть у меня одна черта характера такая, своеобразная. Ну не люблю я жопочасы. Когда оплата идет в зависимости от потраченного времени. Просто по тому, что в такой конфигурации, как правило, количество задач растет, качество описания к ним неизбежно падает, а сама суть задач находится где-то на очень тонкой и хрупкой грани здравого смысла.

А мне очень не нравится заниматься бесполезной херней. Даже за деньги.

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

А суета — НЕ работа.

Здесь же недавно Telegram разродился требованием политики обработки данных в ботах, угрожают выносить ботов при её отсутствии. Пинают на Apple, мол это они, а мы хорошие, но не подчинится не можем.

А мне вот интересно стало, в Telegram и в Apple вообще суть ботов понимают, не? Боты это интерфейс взаимодействия, не более. И вешать политики обработки данных на бота это примерно как составлять ту же самую политику обработки данных для монитора компьютера. На экранчике ж тоже чужие никнеймы мелькают. Ещё как мелькают. И данные обрабатываются. В мониторах свой процессор есть. Ну так вот чую, маразм дойдет и до этого.

Google таблички наши, внезапно тоже могут попасть под прицел. Трансграничная передача данных там нашлась. В общем все наши данные Google сразу начальству в ФБР передает. Так наверно думают. В общем и за таблички может прилететь.

Хотя толку от этих всех законов и политик, особенно, что касается персональных данных я не вижу.
Колл-центры с мест не особо отдаленных цветут и пахнут. Мне всякие спамеры в день раз по 15-30 звонят.

Куда не плюнь - подпишите политику обработки данных. А если не хочешь — нахрен с пляжа в принципе. В общем как обычно, суеты навезли. Всему и всем пожалуйста соответствуй. Да, на ситуацию с утечками данных, хакерскими атаками и спамерами мы повлиять не можем, но это уже совсем другая история. Но вот вам новые нормы — еб**сь разбирайтесь с ними.

А нам же мало этого? Другие компании в рамках конкурентной борьбы отношения выясняют. То интеграцию вынесут, то со стора удалят. То в принципе с платформы и будут всячески противодействовать кастомным решениям. Мрак какой-то на самом деле происходит.

И я, честно говоря, чёт как-то под устал от всей этой херни. Как итог ведь, суеты стало больше. А КПД всего этого мракобесия около нуля. И страдают другие компании, специалисты и чей-то бизнес которые люди развивали и продолжают развивать вопреки, а не благодаря.

Так ведь как-то выходит?

На этой ноте я пожалуй уйду в закат. Sorry, за поток сознания, но гляди, может кто из вас приведёт меня в чувства и скажет, что я чет не так понял или наоборот узнает, что он(а) не одни с такими же мыслями и выводами.

Замедление YouTube и прочие радости

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

А ещё вангую, что цены на дисковое хранилище, если не взлетят, то как минимум повысится. А где-то появится, как недавно в SaleBot. Вот вам 2Гб, все что выше — сходи оплати. Дальше будет веселее.

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

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

Многие кинулись на облачные хранилища и вот к чему приводит вся эта «облачность». Мой совет, абсолютно всем, кто меня читает: запасайтесь жесткими дисками. Дальше будет только веселее.

Кто умеет в Linux и хранит дома устаревший компик, советую почитать вот это.

В остальном, чем меньше в вашей жизни облачных решений, тем спокойнее вам будет. Настоятельно рекомендую зарезервировать оффлайн все данные которые есть у вас где-то в сети. Вероятность потери всего этого весьма высока, независимо от того, пользуетесь вы отечественными или зарубежными сервисами. Если вам реально дороги ваши данные — ваш путь хранение оффлайн. Жесткие диски на несколько терабайт нынче не особо дорогие. Дешевле годовых подписок на разные сервисы.

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

* Реклама. Был таргет. Теперь таргета нет, а рекламу где-то можно, где-то нельзя. А где можно, нужно ещё маркировать. Результат один — запустить и провести РК.

* Платежи. Подключил платежку. Максимум кассу. Теперь платежи делятся на международные и внутренние. Для разных платежей разные чеки, банки. Для работы с некоторыми странами нужны отдельные платежные системы которые работают только в этих странах. Нужно иметь несколько юр.лиц. Результат один — получение оплат.

* Начало продаж. Надо была всего оферта и реквизиты в подвале сайта. Сейчас оферта, политика ПД, политика обработки ПД, трансграничные ПД, разрешение на рекламные рассылки. Результат тот же — начало продаж.

* Публикация видео. Залил на YouTube или хранилище. Теперь для одних учеников YouTube, для других RuTube. Либо платить (доплачивать) за хранилище. А результат ведь один и тот же.

Заметьте, на сколько больше нужно телодвижений для достижения одних и тех же целей.

И это я ещё не припомнил, как GetCourse отключили Prodamus, а SaleBot упразднил интеграции с Amo/Bitrix.

И дорогие коллеги, этот тренд на рост уровня сложности я наблюдаю очень и очень отчетливо. Подозреваю, дальше будет только «веселее».

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

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

Знаете прикол, нет я не выпадаю, не забил и т.п Просто срань всякую писать не охота и превращать канал в филиал ООО «Нытинг продакшн»

Но последнее время, свое состояние описать иначе, чем «профессиональное подгорание» попросту не могу. Бомбит ежедневно.

И ведь есть повод. Вот очередная порция. Miro решили внезапно вернутся, точнее оставить в покое бесплатные аккаунты.

Зато ливнуть решил Notion. И сделали это они эффектно — сливая пользовательские данные. Халатность это, баг или хрен знает, что там ещё — откровенно пофигу. Не удивляет уже ничего. Но у ребят из Notion, при экспорте своих файлов можно случайно экспортнуть соседний проект. Чужой естественно.

👉🏻 Пруфы здесь 👈🏻

Комментировать только портить.

Ну и есть ли смысл смотреть презентацию 16го айфона или график красноречивее оказался?

Озадачился я тут на досуге рассыльщик свой написать 👨‍💻

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

На самом деле в моменте довольно быстро написал рабочий прототип. А там несколько дней потратил на доработки. Конечно до готового продукта как в космос раком далеко 🙃

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

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

Если кто не знал, я давно о сильно увлечен гражданской авиацией.

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

Я пока не готов описывать весь функционал, в частности многое все еще переписывается и меняется. Однако мне удалось сделать некое подобие автоматического сегментирования. Например, ядро вполне способно автоматически распознавать ошибки при отправке голосовых/видео пользователям премиум подписки с выключенным запретом.

Каждая рассылка актуализирует состояние клиента. Попутно система не даст выполнить рассылку по телеграм чатам и каналам, даже если очень хочется. Или отправить markdown-разметку обычным текстом.

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

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

В тоже время это готовое и не к чему не привязанное ядро, которое в теории можно связать с любым внешним интерфейсом: хоть веб, хоть десткоп, хоть бот. Само ядро может работать на любом VPS и по тому в целом можно настроить рассылку даже с колес.

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

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


А вам если интересно наблюдать за развитием проекта (или за тем как быстро я на это забью) тогда не переключайтесь 😉

Кстати готов ответить на вопросы в комментариях)

По поводу «ничего интересного в отправке сообщений» выше я слегка погорячился 🙃

На самом деле есть. Я конечно не имею ввиду вызов функции sendMessage. Однако сам процесс отправки сообщений штука, как минимум разнообразная, как минимум по тому, что есть несколько способов это сделать.

▫️через Bot API
▫️через MTProto
▫️через Local Bot API

У каждого способа свои преимущества и недостатки.

Первый способ, Bot API, можно сказать, что это отправка «как обычно» Ничего шибко нового.

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

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

Local Bot API и вовсе занятная история.

Обычный Bot API это точно такой же Local Bot API сервер, но работает он на домене телеги и на их физических серверах и с чутка подрезанными лимитами.

Local Bot API же позволяет снять ряд ограничений с Bot API и по сути позволяет работать с ботами точно так же как и обычно, без подключения к MTProto напрямую, но с рядом отличий. Например в бот можно спокойно отправлять файлы до 2Гб, а не 50Мб как это происходит при использовании Bot API телеграма.

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

Все дело в том, бот не станет просто так работать с локальным бот-сервером и бот нужно переключить.
Для этого нужно выполнить команду logOut. Но после выполнения этой команды бот разлогиниться с серверов телеграма и при первом соединении с локальным бот-сервером залогиниться в нем. В свою очередь это означает, что конструктор ботов, к которому был привязан этот бот потеряет возможность взаимодействовать с ним.

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

Расскажи чем ты занимаешься, не называя свой род деятельности и должность, но что бы все поняли 😁

Я тут хожу который день ковыряю себе мозги тем, а надо ли пилить какой-то материал по поводу правильной работы с self-hosted медиа файлами.

Что это такое?
Основная идея в том, что у вас свой сервер и со своего сервера можно творить разнообразный беспредел. Раздавать видео (просто просмотр), сделать себе на сайт трансляцию, можно организовать свой рестрим (одновременная трансляция на несколько сервисов)

Я в теме потокового вещания не гуру, но и далеко не первопроходец и не первый день.

Другой вопрос, что возможно кому-то не охота будет поднимать свой сервер или сложно это сделать.

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

Просто не очень охота пилить что-то такое в стол, лишь бы было.

А по тому внимание опрос 📋

Что такое потоковое видео и как все это устроено?

Если интересно, смотрите по ссылке: Потоковое видео своими руками (теория)

Таких заметки будет минимум две:

▫️Теоретическая часть (ответ на вопросы, а зачем и почему так?)

▫️ Практическая часть (ответ на вопрос, а собственно как это сделать?)

Так сделано, что бы не перегружать информацией в практической части и если кто-то захочет повторить, то не возникало чувство недосказанности и вопросов, а зачем так то все делать?

📍В текущей статье постарался максимально подробно и на пальцах рассказать, что такое потоковое видео, почему это хорошо, а почему не очень.

📍Почему возникла такая необходимость?

📍Что не так с VPN при воспроизведении потоковых видео.

P.S. Это моя первая статья в которой все графические материалы я отрисовывал с нуля самостоятельно 🥲 По этому если где-то что-то не стыкуется, или оскорбляет чувства перфекционистов — извиняйте 🤷‍♂️
Я предупредил 😅

Не OBS-кой и Zoom единым))

Что бы как-то развлечься в 4м часу ночи решил так сказать, тряхнуть стариной 👴

Ведем ночной эфир на онлайн-радио 📻

Когда ну очень надо было оповестить о изменениях 😁

Email2Webhook

Друзья, не поверите…

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

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

И вот я день собирался с мыслями, но понял, что печет оно меня 🥵

В итоге сегодня вечером засел и написал простенький микросервис который с определенным интервалом опрашивает почтовый сервер на предмет не прочитанных сообщений и передает их на указанный url в виде JSON.

Он не умеет читать вложения (да и не особо-то надо) но основные параметры регистрирует. И этого мне пока достаточно.

Ещё лежал думал, что не плохо было бы при заходе на новый проект, хотя бы пароли от того же GetCourse сразу автоматически вносить в менеджер паролей (эт дело у меня тоже свое) или же информация о оплате нового заказа или после сдачи ДЗ куратору в бот или в чат выслать, новую покупку в Telegram (такое решение у меня уже есть и без емейлов, но тем не менее)

А ещё не охота забивать голову оплатами разных сервисов, особенно когда их много, а так… Смотрим емейл отправителя, ищем в письме контрольные слова. Если это похоже на «письмо счастья» шлем вебхук на условный сейлбот и оповещаем всех причастных, что пора оплачивать очередной сервис.

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

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

Если тема интересная, накидывайте реакций и как только найду что-то вменяемое — поделюсь ссылочкой и инструкцией по развертыванию.

По второй, практической части, работы с потоковыми видео тоже помню, пилю 🪚 Ну вот отвлекся случайно чуть-чуть 🤏 Но все будет.


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

Новая жизнь GetCourse

В первую очередь хотел поблагодарить всех, кто пришел на мой канал с конференции GETC. Постараюсь оправдать ваше доверие 😉

На этой же конференции дважды поднималась тема взаимодействия с Chatium. И вот собственно об этом и пост.

Ещё в прошлый раз мельком затрагивалась тема этого приложения. Я посмотрел и отчасти отнесся с некой долей скепсиса к возможностям чатиума. А оказалось очень зря. В этот раз решил прям предметно разобраться и на примере живого проекта построил интеграцию между Тильдой и геткурсом. По сути классика, да не совсем.

Суть задачи в том, что на тильде собраны формы для разных источников трафика. Информацию с этих форм необходимо передать на GetCourse. Дополнительно, заказчик пожелал, что бы информация не просто передавалась в GetCourse, но и производилась запись в доп.поля.

При этом не создавались дубли заказа от одного и того же лида. И чтобы GetCourse учитывал только последнее заполнение формы. Допустим клиент увидел сторис в известной соц.сети и заполнил анкету. А затем встретил ту же анкету и заполнил её уже с поста в Telegram.

GetCourse должен создать нулевой заказ, а затем обновить содержимое доп.полей на информацию с последней заполненной анкеты.

Решить в лоб такого рода квест не выйдет. Можно писать интеграцию на уровне API GetCourse. Но едва ли реализуемо обновление уже существующего заказа. Да и к тому же нужен отдельный сервер или хостинг.
Время на решение задачи было с запасом и я решил в «бою» опробовать Chatium.

Все, начиная от маршрутов для вебхука заканчивая хранилищем и логикой я полностью реализовал силами Chatium за пару вечеров.

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

Методы getcourse-sdk позволили добавлять заказ, писать комментарий и самое главное — обновлять информацию в заказе. Попутно накидал не сложный виджет и подвязал его к карточке клиента.

Сказать, что я остался доволен как слон, ничего не сказать 🙃

На самом деле, года полтора назад я в целом утратил интерес к GetCourse как таковому. Да, были и есть проекты на сопровождении. Переодически что-то там делаю. Но спектр своего внимания я чуть более чем полностью сместил в сторону разработки серверных решений и SaleBot (к последнему во многом благодаря хорошему API и возможностью использовать код на Python внутри конструктора), а GetCourse остался за бортом.

Но вот вся эта история с Chatium в целом вдохнула желание снова начать более плотно работать с геткурсом. Возможностей API там достаточно, есть где разгуляться. И былой скепсис как ветром сдуло 😁

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

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

Так что будь разработчиком, но не будь как Саша и не забивай на что-то просто из-за дефицита времени и недостаточной осведомленности о новой для себя системе 🥂