Раннее писал о том, что появилась идея сделать очень полезного и перспективного бота в телеграм.
Пару вечеров 🌃 за ноутом и допилил функционал выбора города.
Очень ограничивает скудность 😭 доступного функционала для ботов: у кнопок нет ни стилей, ни возможности пометить их не активными. Работаю с тем, что есть. Когда выпущу бота в beta, буду собирать с вас обратную связь 😉, в том числе и по удобству использования.
Впереди ещё много работы, длинный путь. Надеюсь, я его осилю и проект не заброшу.
Пару вечеров 🌃 за ноутом и допилил функционал выбора города.
Очень ограничивает скудность 😭 доступного функционала для ботов: у кнопок нет ни стилей, ни возможности пометить их не активными. Работаю с тем, что есть. Когда выпущу бота в beta, буду собирать с вас обратную связь 😉, в том числе и по удобству использования.
Впереди ещё много работы, длинный путь. Надеюсь, я его осилю и проект не заброшу.
🔥3🥰1
Долгожданный релиз
Сегодня для меня праздничный день 🥳 В конце недели был залит релиз, которого очень ждал. Помните, ранее рассказывал, как собирал куб данных? К сожалению, дособирать его тогда до конца мне не удалось, т.к. промежуточные данные не были готовы. А еще в процессе разработки не учел пару небольших моментов 🤬
Думаю, для большего понимания ситуации, лучше начать описывать предметно, что я делал. Так будет наглядней и яснее, почему же у меня столько радости от релиза.
Итоговой целью 🎯 всех этих телодвижений является получение средневзвешенной ставки эквайринга для партнера. На входе у нас таблица на десятки миллионов строк. В ней находятся ставки по каждой торговой точке 🏪
Рядом у нас есть другая табличка где-то на 50 миллионов строк. Она содержит оборот 💰 по каждому терминалу. В добавок к этому чуду есть кросс-таблица, которая хранит в себе инфу в каких торговых точках какой терминал стоит.
А вишенкой на торте является справочник, который хранит в себе приоритизацию ставок одних типов карт над другими.
Получение средневзвешенной ставки происходит по такой логике: берем все терминалы, смотрим в каких торговых точках они стоят, и назначаем им ставки. Далее считаем оборот по всем терминалам с одной и той же ставкой, умножаем его на ставку, складываем с другими терминалами партнера и делим на общий оборот. Формула простая как табуретка, только тут, как в известном анекдоте, есть нюанс 😁 А точнее их тут дофига.
Во-первых, в лоб это все не объединишь - не хватит оперативной памяти. Для этого-то мне и пришлось разбивать данные на кубы, постепенно укрупняя "срезы" данных.
Во-вторых, работая с большим массивом данных, ты обязательно встречаешься с какими-то коллизиями: то какие-то обороты нереалистичные, то нет ставки по обязательным типам карт, то происходит дублирование записей, которое все портит.
В-третьих, в задачке из большого количества шагов обязательно что-то упустишь, а исправление косяка возможно только в следующем релизе 🥲
Сегодня для меня праздничный день 🥳 В конце недели был залит релиз, которого очень ждал. Помните, ранее рассказывал, как собирал куб данных? К сожалению, дособирать его тогда до конца мне не удалось, т.к. промежуточные данные не были готовы. А еще в процессе разработки не учел пару небольших моментов 🤬
Думаю, для большего понимания ситуации, лучше начать описывать предметно, что я делал. Так будет наглядней и яснее, почему же у меня столько радости от релиза.
Итоговой целью 🎯 всех этих телодвижений является получение средневзвешенной ставки эквайринга для партнера. На входе у нас таблица на десятки миллионов строк. В ней находятся ставки по каждой торговой точке 🏪
Рядом у нас есть другая табличка где-то на 50 миллионов строк. Она содержит оборот 💰 по каждому терминалу. В добавок к этому чуду есть кросс-таблица, которая хранит в себе инфу в каких торговых точках какой терминал стоит.
А вишенкой на торте является справочник, который хранит в себе приоритизацию ставок одних типов карт над другими.
Получение средневзвешенной ставки происходит по такой логике: берем все терминалы, смотрим в каких торговых точках они стоят, и назначаем им ставки. Далее считаем оборот по всем терминалам с одной и той же ставкой, умножаем его на ставку, складываем с другими терминалами партнера и делим на общий оборот. Формула простая как табуретка, только тут, как в известном анекдоте, есть нюанс 😁 А точнее их тут дофига.
Во-первых, в лоб это все не объединишь - не хватит оперативной памяти. Для этого-то мне и пришлось разбивать данные на кубы, постепенно укрупняя "срезы" данных.
Во-вторых, работая с большим массивом данных, ты обязательно встречаешься с какими-то коллизиями: то какие-то обороты нереалистичные, то нет ставки по обязательным типам карт, то происходит дублирование записей, которое все портит.
В-третьих, в задачке из большого количества шагов обязательно что-то упустишь, а исправление косяка возможно только в следующем релизе 🥲
Дабы не затягивать пост и не делать его лонгридом, скажу, что на каждом шаге у меня были трудности. Где-то я их мог решать сам, где-то исправление данных в ведении другой команды. Что-то можно починить только через общение с другим отделом.
Мы программисты в большинстве свое интроверты. Подобное кросс-командное взаимодействие дается намного сложнее, чем самая трудная техническая задачка. Но это часть работы, приходится делать.
Вот через такие дебри 🌲🌳🌲 иногда приходится пробираться, что бы получить довольно посредственный результат. Итогом этой правки станут более точные расчеты, более близкие к реальности.
Мне кажется, что подобные задачи, это те самые 80% из закона Парето, которые дают 20% результата. Расскажите в комментариях, часто ли вам приходится делать такие масштабные задачи, но с неочевидной выгодой?
Мы программисты в большинстве свое интроверты. Подобное кросс-командное взаимодействие дается намного сложнее, чем самая трудная техническая задачка. Но это часть работы, приходится делать.
Вот через такие дебри 🌲🌳🌲 иногда приходится пробираться, что бы получить довольно посредственный результат. Итогом этой правки станут более точные расчеты, более близкие к реальности.
Мне кажется, что подобные задачи, это те самые 80% из закона Парето, которые дают 20% результата. Расскажите в комментариях, часто ли вам приходится делать такие масштабные задачи, но с неочевидной выгодой?
Московский урбанистический форум
Посетил сегодня выставку "достижений народного хозяйства", а точнее возможностей в городе Москве. По большей части всё так или иначе относилось к теме здоровья.
В первую очередь было показано оборудование, которое есть в московских больницах (да и в российских наверно тоже). Было много обучающих и интерактивных стендов. Можно было попробовать себя как в роли сотрудника скорой, который делает прямой массаж сердца и искусственное дыхание лёгких, так и в роли хирурга, который делает операцию. Так же были представлены тренажеры для колоноскопистов, УЗИстов и многих других.
Ещё наткнулся на несколько перспективных разработок в области здоровья. Например аппарат, печатающий органы (щитовидная железа для мыши). Первый человеческий орган (почку) планируют к 2026 году.
Был на выставке и впечатляющий павельон Вредные привычки. Там наглядно показан вред ожирения, курения и употребления алкоголя. Манекены очень реалистичны.
Посетил сегодня выставку "достижений народного хозяйства", а точнее возможностей в городе Москве. По большей части всё так или иначе относилось к теме здоровья.
В первую очередь было показано оборудование, которое есть в московских больницах (да и в российских наверно тоже). Было много обучающих и интерактивных стендов. Можно было попробовать себя как в роли сотрудника скорой, который делает прямой массаж сердца и искусственное дыхание лёгких, так и в роли хирурга, который делает операцию. Так же были представлены тренажеры для колоноскопистов, УЗИстов и многих других.
Ещё наткнулся на несколько перспективных разработок в области здоровья. Например аппарат, печатающий органы (щитовидная железа для мыши). Первый человеческий орган (почку) планируют к 2026 году.
Был на выставке и впечатляющий павельон Вредные привычки. Там наглядно показан вред ожирения, курения и употребления алкоголя. Манекены очень реалистичны.
Когда сверка данных приносит удовольствие
Моей самой не любимой работой в программировании является сверка данных🆘 Это занятие меня никак не развивает. Ты просто сидишь и ищешь ошибку. Причин для её возникновения миллион и надо перебрать кучу разных вариантов преобразования данных, что бы найти косяк в алгоритме 🤯
Сегодня у меня была такая задача, только в этот раз я от неё кайфанул 🤩 Ранее я писал, что собирал куб данных для получения средневзвешенной ставки. После успешного заполнения таблиц пришла очередь проверить корректность значений🧑🎓
Сначала пытался решить задачу глобально, взяв для проверки крупного партнёра. Это было ошибкой. Слишком много записей приходится выгружать, сравнивать. Время выполнения запроса не мгновенное, да и строк слишком много, легко запутаться😵💫 Решил спуститься до уровня одной торговой точки.
Не буду расписывать все шаги, что пришлось выполнить. Скажу только, что сначала получил итоговые значения для точки в экселе. А под конец дня получил их же через запросы в свои кубы. Данные совпали до 4 знака после запятой. Кайф! 🥳
Приятно осознавать, что результат, к которому шёл несколько месяцев (подготовка одних таблиц, выверка других, написание алгоритмов обработки) достигнут, причём с высочайшей точностью 🎯 И конечно приятно, что всё проделано не зря. Теперь и расчёты будут точнее и аналитика детальнее.
А от чего в работе кайфуете вы?
Моей самой не любимой работой в программировании является сверка данных
Сегодня у меня была такая задача, только в этот раз я от неё кайфанул 🤩 Ранее я писал, что собирал куб данных для получения средневзвешенной ставки. После успешного заполнения таблиц пришла очередь проверить корректность значений
Сначала пытался решить задачу глобально, взяв для проверки крупного партнёра. Это было ошибкой. Слишком много записей приходится выгружать, сравнивать. Время выполнения запроса не мгновенное, да и строк слишком много, легко запутаться
Не буду расписывать все шаги, что пришлось выполнить. Скажу только, что сначала получил итоговые значения для точки в экселе. А под конец дня получил их же через запросы в свои кубы. Данные совпали до 4 знака после запятой. Кайф! 🥳
Приятно осознавать, что результат, к которому шёл несколько месяцев (подготовка одних таблиц, выверка других, написание алгоритмов обработки) достигнут, причём с высочайшей точностью 🎯 И конечно приятно, что всё проделано не зря. Теперь и расчёты будут точнее и аналитика детальнее.
А от чего в работе кайфуете вы?
Please open Telegram to view this post
VIEW IN TELEGRAM
Вчера делал презентацию для выступления. Решил, что данный материал будет полезен и вам.
В работе регулярно встречаются задачи, которые необходимо выполнять с определенной периодичностью. Например, обновление раз в час цен в интернет-магазине. Для этого в cron кладется задание на выполнение скрипта по расписанию. Может так случиться (а случается это довольно часто), что скрипт не успевает выполниться за отведенное время. Через час запускается еще одна такая же задача. Два скрипта работают параллельно. Спустя еще час запускается третий скрипт. Нагрузка на сервер возрастает. Избежать такой ситуации помогает проставление неких маркёров или флагов, которые показывают, что процесс еще запущен и второй экземпляр запускать не надо. Существует 2 хороших и 2 так себе варианта решения этой проблемы.
Плохие варианты это хранить флаг в оперативке (кэш) или базе данных. Если кэш сбросят или перезагрузят кэширующий сервер, ваш флаг пропадет и привет дублирующий процесс. Если ваш флаг в базе и случился какой-то сбой, перезагрузка сервера, то новый скрипт вообще не запустится. У вас в базе флаг, что процесс запущен. Придется лезть в базу и обновлять значение. Оба эти варианты еще плохи тем, что в случае необработанной ошибке в скрипте, вас ждут те же проблемы, что написал выше.
Продолжение ⬇️
В работе регулярно встречаются задачи, которые необходимо выполнять с определенной периодичностью. Например, обновление раз в час цен в интернет-магазине. Для этого в cron кладется задание на выполнение скрипта по расписанию. Может так случиться (а случается это довольно часто), что скрипт не успевает выполниться за отведенное время. Через час запускается еще одна такая же задача. Два скрипта работают параллельно. Спустя еще час запускается третий скрипт. Нагрузка на сервер возрастает. Избежать такой ситуации помогает проставление неких маркёров или флагов, которые показывают, что процесс еще запущен и второй экземпляр запускать не надо. Существует 2 хороших и 2 так себе варианта решения этой проблемы.
Плохие варианты это хранить флаг в оперативке (кэш) или базе данных. Если кэш сбросят или перезагрузят кэширующий сервер, ваш флаг пропадет и привет дублирующий процесс. Если ваш флаг в базе и случился какой-то сбой, перезагрузка сервера, то новый скрипт вообще не запустится. У вас в базе флаг, что процесс запущен. Придется лезть в базу и обновлять значение. Оба эти варианты еще плохи тем, что в случае необработанной ошибке в скрипте, вас ждут те же проблемы, что написал выше.
Продолжение ⬇️