Всем привет! Давайте сегодня разберем: как не выгорать после работы и находить силы на себя ☺️?

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

Чтобы получалось продолжать продуктивно заниматься своими дополнительными делами после работы - нужно повышать не только продуктивность, но и физическую и ментальную выносливость 🤨.

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


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

Чем более грамотное восстановление получает организм, тем проще вливаться в умственный труд ☺️. Все это еще можно усилить хорошим питанием и равномерным сном, но это достаточно обширные и индивидуальные темы 🥸.

Если у вас на этом этапе как и у меня назрел вопрос: "А как тогда можно хорошо и качественно восстанавливаться?" - мы на правильном пути.


Давайте разберем то, что я недавно открыл для себя. Эти вещи прям сильно помогают включаться в работу, а после нее восстанавливаться и эффективно отдыхать ⌨️. Если говорить кратко, то это:

• Регулярный контрастный душ 🚿;

• Еженедельная баня 😤.

Для начала более подробно рассмотрим контрастный душ, так как он более доступен и делается чаще, чем баня. Основные преимущества и нюансы 🤯:

1. Утренний контрастный душ включает нервную систему и позволяет быстрее избавиться от утренней сонливости. Этот эффект помогает сразу вкатиться в работу;

2. Повышается концентрация, ощущается прилив сил;

3. При регулярном контрастном душе тренируется сердце, а также тело более легко реагирует на изменение температуры: при жаре - меньше потеешь, при холоде - меньше мерзнешь;

4. Основной нюанс контрастного душа заключается в том, что его не нужно делать на ночь, так как это может повлиять на качество сна, а сон - это основа восстановления в целом;

5. Начинать ввод контрастного душа по утрам нужно постепенно: самый хороший способ - уменьшать температуру воды с прохладной до максимально холодной;

6. Также важный нюанс - заканчивать контрастный душ холодной водой.


Теперь давайте перейдем к бане 😺. Для себя пока что выделил два основных варианта парки: "спортивный" и "для восстановления". На первый взгляд они не сильно отличаются, но влияют на организм по-разному 🤔:

1. Спортивный вариант парки 😏:

• 4 захода в парилку;

• Между каждым заходом в парную - следует обливаться холодной водой из ведра.

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

• В самом конце лучше всего выпить бутылку боржоми, чтобы восстановить водно-солевой баланс.

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

2. Вариант парки для восстановления ☺️:

• 4 захода в парилку;

• Между каждым заходом в парную - просто медленно остываем в предбаннике в течение 15-20 минут и не забываем про питье воды;

• Лучше всего париться в тишине и желательно без слишком яркого света;

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

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


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


Под конец отмечу, что я писал на основе своего опыта, интересно какой опыт у вас 🥸. Если в целом такой формат понравился вам, то могу еще рассказать про то, что ввел в свой распорядок дня, чтобы получалось работать продуктивно и долго 👍.


#статья 📚

⚙️ Аналитика и системное мышление


Тут собраны посты про аналитику, данные, метрики и системное мышление: как смотреть на цифры, разбирать задачи и не обманываться красивыми выводами.


📁 Мышление и подход:

📎 Почему математика, код и аналитика — одна цепочка
📎 Данные сами по себе ничего не значат
📎 Что я понял за 2 года в аналитике
📎 ИИ и аналитика: одних хардов уже мало
📎 ИИ не убивает разработчиков, а убирает часть рутины


📁 Данные, метрики и расчёты:

📎 Как продукты докручивают через метрики и A/B-тесты
📎 Корреляция и регрессия простыми словами (ч.1)
📎 Корреляция и регрессия: расчёт на примере (ч.2)
📎 Задача оптимизации простыми словами


📁 Фокус и продуктивность:

📎 WIP: меньше задач в работе — больше сделано
📎 Парето и перфекционизм: где 20% дают 80%
📎 Почему мы откладываем важное на потом (ч.1)
📎 Прокрастинация как формула, а не лень (ч.2)
📎 Формула прокрастинации на Python (ч.3)
📎 Зачем выписывать задачи перед работой


📁 Системы и интеграции:

📎 Три архитектуры приложений простыми словами
📎 REST и SOAP: в чём разница
📎 Очереди и брокеры сообщений — зачем они
📎 Контракты обмена: Swagger, WSDL, XSD


📁 Задачи и разборы:

📎 Две задачки на логику с разбором
📎 Задача про день рождения Шерил
📎 Задача про антифрод, банящий не тех, кого нужно


#навигация 📝

Всем привет 🥸! Сегодня в голову пришла интересная мысль, поэтому хочу поделиться ей с вами. Давайте порассуждаем о тишине как о функции восстановления ⌨️.


Основной тезис:

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

Давайте разберемся в этом с помощью базовой математики 🤔. Чтобы это сделать представим наш мозг в виде системы с входом и выходом:

dx/dt = f(x(t), u(t)), где:

• x(t) - внутреннее состояние, а именно: уровень нагрузки, стресса, фокусировки 😱;

• u(t) - внешний сигнал, а именно: сообщения, короткие и длинные видео в сети, сериалы, шум, и прочее 🫣.

Когда u(t) постоянно активно, наша система перегружена. Внешний сигнал не дает ей вернуться к спокойствию, т.е. состояние x(t) постоянно колеблется, иногда даже хаотично 🤪.


Причем тут тишина?

Если ты отключаешь телефон и остаешься наедине с собой, то по сути ты убираешь весь u(t) 🤡. Из-за этого, изначальное уравнение упрощается, а именно становится таким:

dx/dt = f(x(t), 0).

Другими словами, наша система начинает эволюционировать самостоятельно, т.е. только за счет внутренних процессов 🤯. И если функция f - устроена разумно (а наш мозг умеет самоисцеляться 😁), то через некоторое время:

x(t) → x*, где x* является устойчивым и сбалансированным состоянием.

Если привести аналогию, то это как постоянно трясти стакан с мутной водой - вода не успевает стать прозрачной 😡. Но если перестать делать тряску - со временем вода станет прозрачной, так как вся муть осядет 🥱.


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

Каждое сообщение или просмотр видео - как добавление того самого высокочастотного шума 🥵.

А вот пара-тройка часов тишины, в нашем случае, это как фильтр низких частот: очищает мозг от лишнего и оставляет только самое важное ☺️.


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


Если есть желание поделиться своими размышлениями, с удовольствием почитаю в комментариях 🥸. Ну или можете проголосовать реакциями как обычно:


⌨️, 😎, ☺️ - пробовал такое, мне помогает.

🤔, 🤨, 😄 - ни разу так не делал, попробую!


#статья 📚

Всем привет 🤨! Сегодня хочу поделиться с вами своими размышлениями об объектно-ориентированном программировании — сокращенно "ООП". В общем и целом, это не только полезно при написании кода, но и удобно при обычном мышлении. Давайте кратко разберем 👍.


Начнем с основного тезиса ⌨️:

ООП — это стиль написания кода, при котором всё строится вокруг объектов. Объекты, по сути, являются сущностями из реального мира, у которых есть свойства (характеристики) и методы (поведение, действия, которые объект может выполнять).

Почему ООП удобно и полезно применять 🤔:

1. Привычный способ мышления.
В жизни мы мыслим объектами, например: машина, человек, заказ, сообщение. У каждого из этих объектов есть свои определенные свойства и действия, которые объект совершает. В ООП код пишется по тому же принципу, поэтому его можно понимать даже "на слух" ☺️.

2. Методы делают поведение объекта наглядным.
Каждый объект может сам выполнять действия. Например, у объекта "Пользователь" может быть метод ".войти( )", ".сделать заказ( )" и ".отправить_сообщение( )". То есть мы не вызываем абстрактную функцию где-то в коде — мы буквально говорим: "данный объект делает вот это действие". Такой подход и приближает код к реальному мышлению 🤯.

3. Переиспользуемость.
Создаем один класс — можем создавать сколько угодно объектов на его основе, не дублируя логику для каждого объекта ☺️.

4. Легче масштабировать.
Когда проект растёт, ООП позволяет добавлять новые классы и методы, не ломая старую логику. Можно сказать, что каждый объект отвечает сам за себя 😎.

5. Просто объяснять другим.
Вместо того чтобы описывать кучу функций и их вызовы, можно просто объяснить: "у объекта есть метод, он делает вот такое действие", — и это воспринимается естественно 😎.


Давайте теперь посмотрим на простой и понятный пример, в котором реализован класс "Car" со своими свойствами и методами 🚙:

class Car:
    def __init__(self, brand, color, body_type):
        # свойства машины
        self.brand = brand
        self.color = color
        self.body_type = body_type
        self.is_moving = False
        self.direction = None

    # метод, описывающий движение машины вперед
    def drive_forward(self):
        self.is_moving = True
        self.direction = "вперёд"
        print(f"{self.color} {self.body_type} {self.brand} - едет {self.direction}.")

    # метод, описывающий движение машины назад
    def drive_backward(self):
        self.is_moving = True
        self.direction = "назад"
        print(f"{self.color} {self.body_type} {self.brand} - едет {self.direction}.")

    # метод, описывающий остановку машины
    def stop(self):
        if self.is_moving == True:
            self.is_moving = False
            self.direction = "остановился"
            print(f"{self.color} {self.body_type} {self.brand} - {self.direction}.")
        else:
            print(f"{self.color} {self.body_type} {self.brand} - уже стоит.")

# Пример использования
my_car = Car("Toyota", "Черный", "Джип")
my_car.drive_forward()
my_car.stop()
my_car.drive_backward()
my_car.stop()
my_car.stop()

Если запустить данный код, получим следующее 🥸:

Черный Джип Toyota - едет вперёд.
Черный Джип Toyota - остановился.
Черный Джип Toyota - едет назад.
Черный Джип Toyota - остановился.
Черный Джип Toyota - уже стоит.

Кратко о том, что делает код выше😎:

• Создает машину с маркой, цветом и типом кузова;

• Определяет методы движения машины вперед и назад, а также ее остановку;

• Позволяет машине "знать": едет ли она сейчас и направление ее движения;

• При каждом совершенном действии — выводит понятное сообщение.

Также этот класс "Car" легко масштабируется — можно добавить: скорость, поворотники, расход топлива и т.д. Постепенно код можно превратить в полноценную симуляцию машины, но это уже другая тема 🌚.


В итоге, ООП — это способ приблизить код к реальному миру 😱. Когда ты мыслишь объектами, логика приложения / сайта / софта становится более естественной, понятной и устойчивой к изменениям 😍.


🤔, 🤨, ✨ - потестирую код у себя на ПК!

😎, ☺️, ⌨️ - достаточно просто представить в голове.


#статья 📚

Давно хотел собрать статистику своего канала за год 🎮.


Сегодня я это сделал, но статистика будет примерно за 13 месяцев: с 25.05.2024 до 22.06.2025 ⌨️:

• За это время на канал подписались ~ 1178 человек.
Благодарен каждому за это.

• Общее количество просмотров на всех постах ~ 54982 (не считая этот пост).
Считаю, что цифра очень сильная, дальше больше.

Напоминаю, что вы можете 🥱:

• Поддержать канал голосом, чтобы я мог настраивать кастомное оформление, вот ссылка: https://t.me/boost?c=2187172722

• Поделиться ссылкой на вступление в этот канал с друзьями (спасибо, это действительно помогает): https://t.me/+VZi8XKZsg7s3NmNi

P.S. К слову, статистику своего канала я собирал с помощью telegram API, расскажу кратко, через что пришлось пройти, было интересно 🥸:

1. Сначала зарегистрировал приложение, чтобы получить api_id и api_hash;

2. Затем установил библиотеку telethon в jupyter notebook (я использовал его);

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

4. В финале, написал скрипт, который выводит: общее кол-во постов в канале, словарь формата {количество просмотров на посте, первые 50 символов поста} и просто общее количество просмотров на всех постах.

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

Но ничего, для первого раза — считаю, что вполне приемлемо 😎.


#лайф 🤝🏻

Всем привет! Сегодня будет пост в лайф-режиме 😺.

Недавно начал работу над личным проектом, который связан с Telegram Web App. Давно хотел попробовать разработать встроенное в Telegram приложение 🌚.

Так как проект личный, собираю MVP версию локально на своем компьютере, тестирую интерфейс и структуру данных 🤔. Идею приложения планирую раскрыть позже, когда основной функционал будет готов 🥵.


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

• Frontend (веб-интерфейс внутри Telegram Web App):

1. Расширение Flutter (на Dart) — кроссплатформенная основа, удобно использовать, когда разработка такого рода приложения делается первый раз;

2. Material Design через стандартные Flutter Widgets — удобно использовать для создания первичного интерфейса;

3. Управление состоянием — через setState и callback-подход, хоть примерная суть ясна, пока что все равно разбираюсь;

4. Про адаптивную верстку еще не думал, хотя уже нужно 👍.

• Telegram Web App:

1. Интеграция через встроенный WebView Telegram — скоро перейду к этому этапу, когда соберу MVP версию;

2. Планирую подключить telegram.WebApp JS API для взаимодействия с Telegram UI, чтобы можно было получать информацию о пользователе приложения;

3. Возможно, позже предстоит разобраться с Telegram Bot API для внешнего хранения данных 🥵.

• Backend и хранилище данных: если говорить честно, то это самое сложное, поэтому пока что ожидает проработки 😡.


Теперь кратко распишу инструменты, которыми пользуюсь при разработке:

1. VS Code — думал, что после универа не пригодится мне, но я ошибался;

2. Flutter SDK — установил и настроил прямо в VS Code;

3. Git — будет нужен для контроля версий моего приложения.

Что заметил по ходу 🐱:

Flutter даёт быстрое визуальное отображение, можно взаимодействовать с кнопками — это очень удобно. Но синтаксис сложный, также не всегда очевидный в мелочах: тонкости верстки, кастомизации и отладки требуют времени и экспериментов 👊. Но так как сейчас вышел в долгожданный отпуск, надеюсь, что со временем проблем не будет ⌨️.


Если такой формат интересен — накидайте реакций, и позже я расскажу про архитектуру приложения (когда будет готов MVP) 😎.


Также, было бы интересно услышать от вас темы для будущих постов, у меня конечно же есть план, но мне интересно сравнить его с вашим представлением 🤔!


#лайф 🤝🏻

Всем привет ⌨️! Решил выйти на связь во второй половине отпуска и поделиться с вами тем, что делал 😎.

Сегодня опять будет лайтовый пост в лайф-режиме.


В начале прошлой недели получилось посетить:

• Калугу 😎.

Мне очень нравится этот город, там можно классно погулять вечером, а также посидеть на набережной реки Оки.

• Тулу 🥱.

Тула тоже мне понравилась, но фаворитом в этой отпускной поездке остается, конечно же, Калуга. Отличие Тулы в том, что это огромный город, и мне он чем-то напомнил Москву, если честно.

Отмечу, что катался по этим городам на своей машине 🤔. Тут есть плюсы и минусы:

Плюсы 🤯:

• Очень красивые и живописные дороги, по которым приятно ехать.

• Новые впечатления от вождения за пределами Москвы и области.

Минусы 😵:

• Сильно устает спина.

• Отсутствие нормального кондиционера в машине.

• Иногда бывают пробки, ибо дорожные работы.

В итоге, проехал километров 700, наверное 🤪.


На самом деле, очень люблю такие поездки — много чего вынес для себя, хотя длятся они совсем недолго и быстро пролетают 😨.


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


P.S. Накидайте реакций, если были в Калуге и Туле. Также можете в комментариях поделиться своим мнением и инсайдами об этих городах, с кайфом почитаю 👍.


#лайф 🤝🏻

Всем привет 😐! Думаю, что практически каждый рано или поздно задается вопросом: "Почему с возрастом время летит быстрее?" Давайте попробуем разобрать подробнее 😤.


Основной тезис:

"Годы пролетают как дни" — классическая жалоба взрослого человека 😵.

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


Первичный разбор того, что происходит:

Мозг упаковывает воспоминания 🤔.

В юности все новое: места, лица, эмоции — каждый день мощно и быстро занимает свое место в памяти ☺️. А взрослость, в большинстве случаев, — это рутина: дом → работа → дом, одни и те же маршруты, одни и те же действия 🥵. Новизны мало, поэтому мозг "архивирует" такие дни в сжатом формате. При попытке подумать о таких днях — на ум приходит мало воспоминаний, а, следовательно, возникает ощущение, что эти дни пролетели очень быстро 💨.


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

Пусть:

• t — объективное календарное время;

• τ(t) — субъективное время, а именно то, как мы его ощущаем;

• N(t) — количество новых или уникальных событий за единицу времени.

Сходу можем сказать, что:

• В детстве N(t) ≫ 1, т.е. много новых событий, поэтому время ощущается длиннее;

• В возрасте N(t) ≪ 1, т.е. много событий повторяется, поэтому время сжимается в памяти.

Далее, обернем нашу основную идею: "чем больше событий зафиксировано мозгом, тем длиннее воспринимается отрезок времени", — в дифференциальное уравнение 😁:

dτ / dt = N(t) / N₀,

где N₀ — нормировочная константа (например, среднее количество новых событий в день у ребенка) 😎.


Затем предлагаю описать, как меняется N(t) со временем 🤯. Первое, что приходит в голову — оно экспоненциально убывает, т.е.:

N(t) = N₀ * e⁻ᵅᵗ,

где α > 0 — параметр "привыкания" или "рутинности" 🤪.


Следующим шагом давайте подставим N(t) в наше изначальное уравнение и выведем из него τ(t):

dτ / dt = e⁻ᵅᵗ ⇒ τ(t) = (1 - e⁻ᵅᵗ) / α.

В итоге, теперь можем разобрать то, что у нас получилось ⌨️:

1. Полученная формула для τ(t) — отображает объем субъективного времени, который "накопился" к моменту t 🌚.

Вывод:
Функция τ(t) получилась простой и интуитивно понятной — она быстро растет в начале, а потом выходит на определенное плато.

2. Что происходит в детстве, когда t — малые? Если разложить полученную функцию τ(t) в ряд Тейлора, получим следующее: τ(t) = t - (α * t²) / 2 + ... . Отсюда, можно понять, что при t ⭢ 0: τ(t) ≈ t 😱.

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

3. Что происходит в зрелом возрасте, когда t — более большие? Для простоты скажем, что t ⭢ ∞. Тогда e⁻ᵅᵗ будет стремиться к 0. Следовательно τ(t) ⭢ 1 / α 😡.

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

Несмотря на не очень позитивный вывод в п.3. — все-таки можно "замедлять" время в зрелом возрасте, а именно занижать параметр α, который отвечает за рутинность и привыкание:

• С помощью изучения чего-то нового 👍;

• С помощью путешествий ☺️;

• С помощью новых знакомств и общения 😎;

• И так далее 🙄.

#статья 📚

Сегодня пришло в голову написать пост на наболевшую тему — если можно так выразиться ⌨️.

Азарт, лудомания и математика: почему выигрыши — это иллюзия 😓?

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

Давайте отложим эмоции и посмотрим на это через призму математики 🤯.



1. Математическая часть простым языком:

Сперва рассмотрим, что такое математическое ожидание. Оно обозначается как 𝔼 — это среднее значение выигрыша или проигрыша, если повторить игру очень много раз 🫣.

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

𝔼 = Σ( {вероятность исхода}ₖ * {выплата}ₖ ), где k — это разные варианты исходов в одной игре (выигрыш, проигрыш, джекпот и так далее).

Если значение 𝔼 отрицательное — значит, игрок в минусе в долгосрочной перспективе, даже если пару раз ему повезёт 🥵.



2. Как устроена лудомания?

Основная проблема таких игр не в разовом проигрыше, а в том, что игрока заставляют вернуться. Если возник вопрос: "каким образом?", ответ ниже:

• Редкие выигрыши — дают дофамин, поэтому хочется играть ещё 🤪;

• Иллюзия контроля — игрок часто думает, что почти угадал, что вот-вот повезет 😡;

• Психология потерь — игрок хочет отыграться, поэтому продолжает дальше, думая, что сможет вернуть проигранное 🤬.

Вроде все очевидно, но зацепляет такая схема очень сильно и часто безвозвратно ☠.



3. Давайте теперь посчитаем математическое ожидание прибыли для самых популярных азартных игр. Отмечу, что математическое ожидание прибыли — это разница между математическим ожиданием и стоимостью одной игры 🤔. Поехали:


• Лотерея 🗑.

- Стоимость билета: 100 рублей.
- Главный приз: 1.000.000 рублей.
- Шанс на главный приз: 1 из 10.000.000.
- Остальные выигрыши проигнорируем для упрощения расчетов (на суть это не повлияет).

Расчет:
𝔼 = ( 1 / (10^7) * (10^6) ) + ( 9999999 / (10^7) * 0 ) = 0.1 рубля.

Вычитаем стоимость билета:
0.1 - 100 = -99.9 рубля — это математическое ожидание прибыли с каждого билета.

Итог: игрок теряет в среднем 99.9 рублей с каждого билета ❌.

• Слоты 🗑.

- Ставка: 100 рублей.
- Шанс выиграть 5.000 рублей: 0.5%.
- Шанс выиграть 200 рублей: 10%.
- Проигрыш: 89.5%.

Расчет:
𝔼 = 0.005 * 5000 + 0.10 * 200 + 0.895 * 0 = 25 + 20 = 45 рублей.

Вычитаем стоимость ставки:
45 - 100 = -55 рублей — это математическое ожидание прибыли с каждой ставки.

Итог: игрок теряет в среднем 55 рублей за ставку ❌.

• Ставки на спорт 🗑.

- Ставка: 100 рублей.
- Коэффициент выигрыша: 1.85.
- Шанс выигрыша: 50%.
- В случае выигрыша игрок получает: 100 (изначальная ставка) + 85 (выигрыш).
- В случае проигрыша игрок получает: 0 рублей.

Расчет:
𝔼 = 0.5 * 185 + 0.5 * 0 = 92.5 рубля.

Вычитаем стоимость ставки:
92.5 - 100 = -7.5 рублей — это математическое ожидание прибыли с каждой ставки.

Итог: игрок теряет в среднем 7.5 рублей за ставку ❌.

4. Итоговый вывод.

Во всех случаях математическое ожидание прибыли отрицательное 😱. Даже если где-то игроку повезло — это всего лишь везение на короткой дистанции 🥸.

А если учитывать второй пункт — такие игры в 99.9% случаев затягивают на долгую дистанцию, на которой игрок в жестком минусе 😐.



P.S. Если у вас есть истории, которые связаны с азартными играми, — можете поделиться в комментариях, я почитаю. Ну и реакции как всегда приветствуются, куда же без них ☺️.


#статья 📚

Как я загнал себя в переутомление и что из этого вышло.


Всем привет! В последнюю неделю словил сильное переутомление 🎮. Решил разобрать это по полочкам — может, кто-то узнает себя 🫡.


С чего всё началось?

После отпуска чувствовал, что у меня энергии на двоих. Каждый день состоял из спорта, работы, проектов до глубокой ночи. Первая неделя — огонь, силы будто бесконечные 😎. На самом деле я просто тратил их без меры 😡.


Первые звоночки, которые не были замечены мной.

• Сильная зависимость от кофеина;
• Тяга к фастфуду в формате «вдруг захотелось»;
• Игнорирование полноценного сна.

Итог этих резко развившихся и регулярных действий — простуда 😱.

На самом деле для меня это редкость, особенно летом. Обычно я болею глубокой осенью, и то очень редко 🤔.


Вторая ошибка, которую я допустил.

Простуда прошла, но я не сделал выводы, которые делаю сейчас. Из-за этого через пару дней спина и шея сказали «привет» 😎. Причина очевидна — слишком много времени в сидячем положении и не всегда с правильной осанкой 🙃.


Что пришлось менять, чтобы восстановиться?

Когда понял, что я просто физически себя измотал, пришлось отказаться от:

• Силовых тренировок;
• Бани;
• Читмилов;
• Кофеина.

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

Взамен активностям, от которых на время отказался, добавил:

• Плотную растяжку для спины, шеи и всего организма;
• Турник;
• Активную ходьбу.

В ежедневном рационе оставил только домашнюю еду, а в качестве напитка воду 😐. Приложил максимальные усилия, чтобы спать стабильно по 8 часов в день — оказывается, это одно из самых сложных 🥵.


Результат, который не заставил себя ждать.

Два дня такого «детокса» — и организм реально сказал «спасибо». Чувствую, как возвращаюсь в привычный ритм 👍.


Вывод: рост и развитие требуют ресурса. Если расходуешь его без меры — расплачиваешься здоровьем 🫣.


А вы сталкивались с переутомлением? Как выбирались? Уверен, что можно подчеркнуть что-то полезное из ваших историй 😍.


#лайф 🤝🏻

Всем привет 🌎! Ранее я уже писал, что занимаюсь разработкой своего приложения. Сегодня расскажу, как собрал простой прототип интерфейса с «in-memory» хранением данных, т.е. без серверов и БД 🪨.


Что означает «in-memory» применительно к данным?

Если говорить кратко, то это способ держать данные в оперативной памяти. Он очень быстрый и удобный для обработки данных прямо в прототипе приложения 🚶. Единственная проблема в том, что после перезапуска все данные исчезают, поэтому для серьёзных приложений добавляют сохранение информации в БД или на сервере 🧠.


Опишем «in-memory» простыми словами.

Для начала представьте три места, где можно хранить информацию:

• Один листок бумаги на столе ✍️.

Он всегда под рукой, на него можно быстро что-то записать, но место ограничено. Если вы отойдёте от стола, листок уберут — восстановить его уже не получится.

• Журналы в шкафу рядом со столом 📂.

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

• Большой склад в соседнем здании 🔒.

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

Соответствия такие:

• Один листок бумаги на столе — это «in-memory» хранение данных 👩‍💻.

• Журналы в шкафу рядом со столом — хранение данных на сервере или в БД 😎.

• Большой склад в соседнем здании — хранение данных в облаке 🤑.

В итоге «in-memory» — это тот самый одиночный лист бумаги на столе 🤬. Данные живут в памяти приложения, всё работает очень быстро, но при перезапуске или обновлении приложения данные сбрасываются 👊.


Теперь немного про мой прототип приложения, который работает с «элементами» и «событиями».

Я сделал интерфейсную часть и для быстрого тестирования выбрал «in-memory»-модель, т.е. все данные хранятся в памяти одной вкладки, в которой открыт интерфейс приложения ⌨️.


Что храню?

• Список элементов items.

У каждого элемента в списке есть: ID, наименование, флаг "True/False", счетчик, время создания, время обновления.

• Журнал событий events.

Каждая запись журнала событий фиксирует, что случилось с элементом и когда.

Почему это удобно для прототипа моего приложения?

1. Очень быстро: без сети и «сложных» настроек 🧐.

2. Быстрые итерации: изменил → проверил → переделал. Идеально, когда оттачиваешь интерфейс 😤.

3. Сейчас этап тестирования интерфейса: добавить тестовые записи прямо в код проще, чем разворачивать полноценную БД ☠.


Что будет дальше?

Как только закончу интерфейсную часть, так сразу разверну БД для хранения данных, потому что их потеря при обновлении приложения станет критичной 🥵. К тому же корректное хранение данных в БД необходимо, если приложением начинают пользоваться несколько пользователей 🤯.


P.S. Про структуру приложения написал обезличенно, так как до MVP-версии с БД и вариантом в формате Telegram Web App ещё далеко. Можете попробовать угадать в комментариях, что за приложение, или просто накидать реакций — они всегда приветствуются 😐.


#лайф 🤝🏻

Сегодня задумался над тем, как оформляю посты.

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


Обращаюсь к вам, какой вариант оформления вам ближе всего и нужно ли оно вообще?

1. Структурированный текст.

2. Структурированный текст с выделением слов жирным шрифтом.

3. Структурированный текст, выделение жирным, эмодзи 👩‍💻.


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

🤔 — я за вариант №1.

⌨️ — я за вариант №2.

☺️ — я за вариант №3.


#лайф 🤝🏻

Сегодня решил вспомнить про свойство Парето или принцип 80/20, а также увязать его с перфекционизмом. Поехали 🤯!

Основной тезис:

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

Вытекающий вопрос:

Каким образом не уехать в бесполезный перфекционизм, который очень сильно увеличивает стоимость задачи, но не изменяет ее ценность 🤔?

Давайте посмотрим на прикладную суть принципа Парето.

Это скорее не конкретные цифры, а определенный паттерн, например: 90/10, 80/20, 70/30 и так далее 💀. Тут самое главное, что у любой задачи есть ядро, дающее основную ценность, и хвост, в рамках которого задача доводится до идеала или конца 🥸. Рассмотрим примеры:

• Пишем приложение 👩‍💻.

- Ядро: работающая MVP-версия.
- Хвост: темная тема, аналитика событий, офлайн-версия.

• Решаем 5 схожих задач по физике 😦.

- Ядро: освоить основные формулы и понять логику решения таких задач.
- Хвост: альтернативные методы решения, расчет погрешностей.

• Пишем пост ⌨️.

- Ядро: понятно написанный текст.
- Хвост: форматирование текста и эмодзи.

Где включается нездоровый перфекционизм и при чем тут хвост задачи?

Этот перфекционизм включается, когда вы находитесь в том самом хвосте задачи, а ваш фокус смещен со «сделать полезно и хорошо» на «сделать идеально настолько, насколько это возможно». С каждым часом правки всё мельче, аргументы всё эстетичнее, а итог почти не меняется 😕. Растут только затраты времени, энергии и нервов 😐.


Что с этим делать?

Давайте построим общую логику 👍. Если думать о задаче как об обмене пользы за час на цену этого часа, получается следующее:

• В начале польза за час высокая, поэтому мы быстро собираем ядро 🟦.

• По мере продвижения польза за час падает, мы переходим в область хвоста задачи 👷‍♂️.

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


Какие нюансы нужно учитывать?

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

• Работа с навыком 🥵.

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

• Пороговые задачи 🥵.

Итог таких задач: «все или ничего», «работает или не работает». К таким задачам можно подходить оптимально, например: довели ее до порога, а уже потом включаем принцип 80/20.

• Задачи, связанные с надежностью и риском 😐.

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

• Задачи, связанные с личным вкусом и эстетикой 🚶.

В таких задачах порогом является то, как итог этой задачи видит исполнитель. Главное не поднимать порог бесконечно, а после его преодоления включать принцип 80/20. На мой взгляд, это идеальный вариант для таких задач.

• Задачи, связанные с написанием кода 🖥.

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

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

🤔 Ядро задачи закрыто?

🤔 Что заметно улучшится через час работы над задачей?

🤔 Какая метрика сейчас главная?

🤔 Есть ли более простой способ доработки?

Если ясных ответов нет — скорее всего, ты кормишь перфекционизм, а не увеличиваешь результат 🧠.


P.S. Как будто логику, которую описал, можно свести к обычной задаче оптимизации. Если хотите накидайте реакций, а я сделаю это в следующем посте 🥱!


#статья 📚

Всем привет! Последний день лета — самое время для лёгкого лайф-поста 👍.

Странно осознавать, что 1 сентября больше не про учёбу и трёхмесячных каникул уже нет, но чувство «конца лета» всё равно то самое, школьное 😦.

Эти выходные выдались неожиданно тёплыми — идеально, чтобы поностальгировать по июльской жаре, которая длилась совсем недолго.


Заодно словил «архитектурную яму» в своём приложении ⚙️.

Вчера вообще ничего не получалось: любые доработки — мимо. Помог вот такой набор действий:

1. Отдых от любой деятельности на несколько часов — всё-таки такой подход помогает мне разгрузить голову и все переосмыслить мощно и быстро 😎.

2. Смена обстановки — достаточно было просто выйти на улицу 🚶.

3. Встреча с друзьями и живое общение 🖥.

4. Почти написал пост с задачей оптимизации — да-да, он почти готов, я не забыл про него 🖨.

Ну и добил день качественным 8-часовым сном.


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

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

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


P.S. Фотокарточку с водоема прилагаю.


#лайф 🤝🏻

Всем привет уже по-классике! Возвращаюсь к вам с задачей оптимизации, которую обещал рассмотреть в прошлых постах 🔍.


Кратко о том, что буду делать:

• Моделирую задачу так, что польза B(x) — растёт, но с насыщением 🥸.

• Цена часа C(x) будет линейной 👍.

• Цель задачи в том, чтобы максимизировать чистую пользу N(x). К слову, N(x) = B(x) – C(x) 🥵.

• Останавливаемся, когда прирост пользы за следующий час сравнялся с ценой следующего часа. Формально: B'(x) ⩽ C'(x), где B'(x) = C'(x) — это "порог" остановки 🤯.

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

• x ⩾ 0 — это затраченные усилия. Будем измерять их в часах 🚶.

• B(x) = Bₘₐₓ · (1 – e⁻ᵅˣ), α > 0 — это то, как работает польза. На старте она быстро растёт, а затем из-за насыщения рост утихает 👩‍💻.

• С(x) = c · x, c > 0 — это стоимость часа 🤑.

• N(x) = B(x) – C(x) — это чистая польза, которую мы получаем 🥇.

Дальше найдем максимум чистой пользы N(x). Сделаю это по шагам, чтобы ничего не упустить:

• Так как B(x) и C(x) — гладкие (дифференцируемые) функции, справедливо следующее: N'(x) = B'(x) – C'(x) ☺️.

• Теперь проанализируем N'(x) = B'(x) – C'(x). По сути, B'(x) — это сколько пользы принесет следующий час, а С'(x) — это сколько следующий час будет стоить. Если B'(x) > C'(x) — выгодно делать задачу дальше, так как прибавка чистой пользы за следующий час положительная. Если B'(x) < C'(x) — прибавка чистой пользы за следующий час будет отрицательной, а это уже плохо и нас не устраивает. В итоге, приходим к тому, что в момент B'(x) = C'(x) накопления чистой пользы будут максимальными 🪨.

• Проверим "кандидата на максимум" с прошлого шага, чтобы удостовериться в том, что он глобальный, а не локальный. Видим, что B''(x) < 0, C''(x) = 0. Отсюда следует, что N''(x) < 0 ⇒ "кандидат на максимум" — глобальный, а это нам и нужно 😗.

• Теперь давайте рассмотрим уравнение остановки B'(x) = C'(x), ну и найдем точку остановки, которую я обозначу как x*. Делаем: B'(x) = C'(x) ⇔ α · Bₘₐₓ · e⁻ᵅˣ = c ⇔ x* = (1/α) · (ln(α · Bₘₐₓ) – ln(c)) 🥱.

• Не забудем отметить, что с учётом изначального ограничения x ⩾ 0 — оптимум усилий, затраченных на задачу, это {0, x*}, то есть: либо 0, либо x*. Тогда если на предыдущем шаге α · Bₘₐₓ ⩽ с, то x* ⩽ 0. В этом случае оптимум усилий на задачу равен 0. Отсюда следует, что углубляться в задачу невыгодно.

Сходу добавим числовой пример, чтобы стало яснее:

• Допустим Bₘₐₓ = 100, α = 0.6, с = 8.

• Тогда x* = (10/6) · (ln(60) – ln(8)) ≈ 3.36 часа.

• B(x*) = 100 · (1 – e^(-0.6 · 3.36)) ≈ 86.68.

• С(x*) = 8 · 3.36 = 26.88.

• N(x*) = 59.8.

Итог: исходя из расчетов, 3.36 часа работы над задачей дают 87% пользы 🥇. Дальше начинается хвост задачи, в котором каждый процент пользы даётся всё большим и большим количеством часов, а общая стоимость задачи всё сильнее и сильнее растёт, хотя из существенного уже мало что меняется 😕.


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

• Если вводим минимальный порог пользы (под этим порогом можно понимать MVP задачи), сначала доходим до этого порога, а уже после его пересечения используем логику с B'(x) ⩽ C'(x) 🤔.

• Если вводим штрафы за баги, которые могут возникнуть из-за игнорирования хвоста, то подключаем логику убывания вероятности бага с увеличением усилий над задачей. Работаем над задачей до тех пор, пока вероятность возникновения багов не снизится до приемлемого уровня, после — останавливаемся🤔.

P.S. Заморочился с оформлением и структурой поста, поэтому так поздно. Это прям наглядный пример траты времени на "хвост" задачи 😁.


☺️ — здраво!
✨ — закинул пост другу.
⌨️ — распишу усложненные задачи оптимизации на бумажке.


#статья 📚

👨‍💻 Мои проекты: боты и приложения


Тут собраны посты про мои проекты: Telegram-боты, Telegram-приложения, инфраструктура и деплой, запуски, ошибки и решения по ходу разработки.

Proof of work + Build in public в одном лице.


📁 Готовые проекты (можно потестить):

📎 Таймтрекер — @TimeTrackerTGBot
📎 Бот для деловой переписки — @TextHelperTGBot


📁 Telegram Web App:

📎 Начал делать Telegram Web App
📎 Прототип интерфейса с in-memory хранением
📎 Мини-апп: темы, свайпы и рефакторинг
📎 Почему притормозил с базой данных
📎 Полировка приложения и мысли к 26 годам
📎 Прогон приложения по краевым кейсам
📎 Веб-разработка, ИИ-фон и чужая витрина


📁 Telegram-бот:

📎 Нюансы разработки бота, которые легко пропустить
📎 Запустил бота — отдаю на живой тест
📎 Честно: бот не взлетел


📁 Инфраструктура и деплой:

📎 Миграция таймтрекера на новый стек
📎 Почему выбрал инфраструктуру на одной VM
📎 Перенос проектов на новую инфраструктуру


#навигация 📝

Сегодня решил разобраться в том, что такое WIP, и как он влияет на выполнение рабочих или личных задач 🤔. Поехали 🚘!

Для начала: WIP (Work in Progress) — это количество задач, которые у исполнителя в работе 🔍.


Основной тезиc:

Чем выше WIP, тем ниже общий прогресс по задачам. Ты тратишь все больше сил на переключения и «въезжания» в контекст, а не на сами задачи 😦.

Посмотрим с точки зрения интуиции:

Когда задач много — тебе приходится постоянно менять контекст: то по одной задаче дернули, то по другой. Знакомая ситуация, правда 🥸?

Подводный камень кроется в том, что каждый прыжок между задачами — это своеобразный «разгон» мозга: вспомнить, где остановился, понять, что еще нужно сделать, подумать какие есть риски и так далее 😐.

Может так получиться, что весь день уйдет на такие «разгоны», и субъективное «я весь день занимался задачами» практически не конвертируется в реальный результат 🥵.


Теперь давайте построим простую модель, чтобы углубиться в проблему 🤯:

• Пусть мы работаем блоками по T минут.

• В каждом блоке у нас в работе k задач (это и есть наш WIP).

• Время входа в контекст i-й задачи — это τᵢ минут.

• Сложность i-й задачи — это cᵢ, cᵢ > 0.

• Усталость, настроение и прочие вещи, которые связаны с исполнителем, обернем в безразмерный коэффициент μ, который может быть разным между блоками, но в рамках одного блока μ = const и μ > 0.

• Также нам нужен перевод сложности задачи в минуты, чтобы не было конфликтов размерности, обозначим его γ.

Дальше опишем сколько времени теряем за блок из T минут, беря в работу k задач 🤑:

Loss(k) = ∑(τᵢ) + μ · γ · ∑(cᵢ).

Зная потери за блок из T минут — мы можем посчитать полезную долю времени за этот блок 🌚:

P(k) = 1 – Loss(k) / T.

Отсюда сразу можем заключить, что:

• P(k) убывает при росте количества задач k 🔍.

• P(k) убывает при росте сложностей задач ∑(cᵢ) 🔍.

• Видно критическую зону, когда Loss(k) ⩾ T. Если такое вдруг происходит, то полезная доля времени P(k) ⩽ 0. Переводя на русский язык — рабочий блок полностью «сгорел» на переключениях между задачами, а прогресса по этим задачам нет 🔍.

Наглядный числовой пример:

Пусть T = 60 минут, μ = 3, γ = 1, k = 4. Так как у нас четыре задачи:

• τ₁ = 2 мин., с₁ = 1 — это для задачи №1 📔.

• τ₂ = 4 мин., с₂ = 4 — это для задачи №2 📔.

• τ₃ = 5 мин., с₃ = 7 — это для задачи №3 📔.

• τ₄ = 7 мин., с₄ = 9 — это для задачи №4 📔.

Тогда:

• P(4) = 1 – (81 / 60) = 1 – 1.35 = –0.35 = –35%. По сути, это случай, когда весь рабочий блок ушел на переключения между задачами 🔥.

• P(3) = 1 – (47 / 60) ≈ 1 – 0.78 = 0.22 = 22%. Выкинули задачу №4, картина улучшилась ⛰.

• P(2) = 1 – (21 / 60) = 1 – 0.35 = 0.65 = 65%. Выкинули задачи №3 и №4, картина стала еще лучше 🥇.

• P(1) = 1 – (5 / 60) ≈ 1 – 0.08 = 0.92 = 92%. Оставили только задачу №1 — идеальный вариант 💎.

В итоге, можем свести рассуждения и аналитику к практическим советам:

• Идеальный лимит WIP — это 1 или 2 задачи за рабочий блок, чаще всего это оптимально ⌨️.

• Если группировать задачи, которые идут в рабочий блок по контексту, то можно сильно снизить время входа в контекст ∑(τᵢ) по этим задачам. Такой подход поможет увеличить количество полезной работы 🖥.

• Если не успел доделать задачу, которую взял в рабочий блок — оставь небольшую заметку с контекстом «на чем остановился?». При добавлении такой задачи в новый блок — ее время входа в контекст τ будет меньше, а значит ты освобождаешь часть времени блока на полезную работу ✍️.

• Можно декомпозировать сложные задачи на более простые. Дробление уменьшит сложность задачи c, и ты сможешь набрать в рабочий блок несколько мелких и простых задач 🟦.

• Также можно влиять на коэффициент состояния исполнителя μ, уменьшая его, но если не получается — при больших μ нужно уменьшать WIP. В таком случае все будет ок 🔮.

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


⌨️ — так и есть.
🖥 — мой WIP > 2.
💎 — поделюсь примером WIP в комментариях.


#статья 📚

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


Чтобы это сделать, мне пришлось уехать в другой город, а именно в Санкт-Петербург ☔️.


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


Кстати, вчера ночью произошла микропобеда над моим приложением:

Я полностью закончил работать над MVP-версией архитектуры и визуала ⏳.

Все-таки Flutter помогает практически сразу смотреть на то, что ты создаешь — это огромный плюс 🥇. Еще я явно осознал, зачем разбивать код своего проекта по различным папкам с сервисами, утилитами и так далее. Это мега-удобно, если проект уходит за 1000 строк, просто поверьте на слово 🔮.


Я думал, что следующий шаг — это прикручивание БД, но нет. Проще оставить это на потом, а первым делом обернуть приложение в Telegram Web App и отредактировать верстку прям в нем (это 100% надо будет делать) 🖥.

Да и к тому же, после обертки уже можно будет получать ID пользователя из init data, а следовательно не нужно будет заморачиваться с авторизацией, но работа с БД все равно будет строиться вокруг уникального пользователя 🤨.

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


Еще, буквально вчера, узнал, что JavaScript считается родным для встроенных приложений в Telegram. Да и слышу я об этом языке постоянно в последнее время. Посетила мысль поучить его с нуля. Думаю, что стоит развить эту мысль до чего-то реального. Остается только сделать изучение не душным и полезным, но это так — мелочи 🔍.


Я еще ни разу не рассказывал про суть своего приложения — попробуйте накидать идеи о нем в комментариях ✍️.

Ну и если тут есть те, кто разбирается или что-то пишет на JavaScript — буду благодарен, если подсветите подводные камни 🆘.


P.S. Фотокарточку как обычно прилагаю в конце поста.


⌨️ — держи в курсе.
🍾 — люблю СПб.
💡 — напишу в комментарии, а может и не напишу.


#лайф 🤝🏻

Как же хорошо разгрузить голову и сфокусироваться на отдыхе и ходьбе — каждый раз в этом убеждаюсь ☺️.

Практически всегда такой отдых конвертируется в новые идеи и цели 🕺.


За три дня вот такие результаты, это прям классика уже:

• шаги: 85298.

• расстояние: 67,92 км.

Фотокарточка с пруфами внизу поста, как обычно 👈.


Хоть мой отпуск продолжается, но я планирую погрузиться в свое приложение и в этот канал 🎮.


Что касается канала — собрал несколько новых тем для постов:

• Хотели бы почитать про QR-коды, и про то, как они работают 👩‍💻?

• Или лучше взять тему, которая не так сильно связана с точными науками 😀?

Как же хорошо, когда бэк-лог тем для постов наполняется быстрее, чем темы вылетают из него.


⌨️ — лучше без точных наук.
🖥 — жду про QR коды.
💎 — почитаю и то, и то.


#лайф 🤝🏻

Всем привет ⌨️. По итогам прошлого поста давайте разберём основу структуры QR-кода. Также посмотрим, почему камера не путается, когда его считывает. Делаем 1-ую часть 🎮!


Кратко про QR-код.

QR-код — это квадратная матрица одинаковых клеток (модулей), в которых хранятся 0 или 1. У каждой такой клетки есть адрес в формате: [№ строки, № столбца]. Вся суть QR-кода заключается в том, где именно лежат служебные поля (группы клеток) и каким образом данные раскладываются по «свободным» клеткам 👩‍💻.


Что нужно, чтобы камера считала QR-код?

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


Теперь подробно про служебные поля:

• Опорные угловые маркеры — это большие «мишени» в правом верхнем, левом верхнем и левом нижнем углах. Размер такого маркера 7×7 клеток и ещё белая рамка толщиной в 1 клетку вокруг него 🤔.

• Синхронизирующие линии — это две дорожки из клеток, цвета которых чередуются: то чёрный, то белый. Расположены они всегда в одних местах: это 6-я строка и 6-й столбец матрицы, если нумеровать строки и столбцы с 0. Отметим, что эти линии тянутся между опорными угловыми маркерами и не заходят в их области 😐.

• Выравнивающие метки — это маленькие «мишени» 5×5 внутри поля QR-кода. Такие метки не могут лежать на опорных угловых маркерах и на синхронизирующих линиях. В небольших QR-кодах они обычно видны в нижней правой части. Если QR-код большой, то таких меток несколько. Вообще они очень важны, так как помогают правильно считывать QR-код с кривых поверхностей, нивелируя искажения 👍.

• Тихая зона — это пустая рамка вокруг QR-кода шириной в 4 клетки, отделяющая QR-код от фона 🫣.

• Поле формата — в нем указан уровень защиты от ошибок и номер маски-узора QR-кода 🌚.

• Поле версии — в нем указывается номер версии, но только если она ⩾ 7 ☺️.

• Фиксированная чёрная клетка в известной позиции — это просто дополнительная отметка для распознавания ☺️.

Тут важно отметить, что в служебных полях ваши данные не передаются 🙌🙌.


А как данные оказываются в свободных клетках?

Опишем этот процесс по шагам:

• Берём две самые правые колонки ✍️.

• Идём снизу вверх: в каждой строке работаем с правой клеткой пары, потом с левой ✍️.

• Дошли до верха — сдвигаемся на две колонки влево ✍️.

• Идём сверху вниз, начиная с правой клетки пары, заканчивая левой клеткой ✍️.

• Далее, просто повторяем до тех пор, пока не дойдем до конца ✍️.

Если во время обхода встречаются служебные поля, то просто пропускаем их и идём дальше 🚶.


А сколько данных можно записать в QR-код?

Это зависит от размера и версии QR-кода: чем больше сторона матрицы, тем больше информации можно передать. Давайте опишем зависимость длины стороны матрицы от версии:

сторона = 21 + 4 · (версия – 1).

Отметим, что вне зависимости от роста версии — синхронизирующие линии все равно остаются в 6-й строке и 6-м столбце 🖥.


Зачем используется маска, если все и так может работать?

Перед выкладкой данных в матрицу к ним применяют маску, которая перекрашивает часть клеток, меняя их цвет на противоположный, по понятному правилу, например: «перекрасить, если сумма номера строки и столбца чётная» ⚙️.

Такой подход делает картинку QR-кода равномерной: без огромных однотонных пятен и длинных повторов, которые мешают распознаванию 🔍.

Важно то, что служебные поля маска не трогает. Поэтому номер маски успешно передаётся в служебном поле формата, о котором писал выше. Зная этот номер, камера выполняет обратное перекрашивание ⏳.


Кстати, часто слышу о том, что QR-код может считываться при ~30% повреждений, но это не совсем так. Тут важно отметить, что речь именно об ошибках в свободных клетках. Если повреждены служебные поля QR-кода, то считывание может сломаться и при меньших повреждениях 🤯. Вот такой итог ☠!


P.S. Ниже приложил QR-код моего канала, теперь вижу на нем служебные поля, да и на других QR-кодах тоже 😀.


😎 — здраво.
💡 — жду 2-ую часть.
🍾 — теперь тоже вижу служебные поля.


#статья 📚