Ответ на пост «Как скажете...»1
суть видео
Показать полностью
1
0 просмотренных постов скрыто
Разбудите меня через тысячу лет и спросите, что делают в ИТ...
Показать полностью
10
Идея чем занять гостей за столом
Последние пару недель в голове сидит идея сделать небольшой микросервис, который позволит занять людей за столом (например, гости или коллеги, которые пришли слишком рано).
Суть кратко: люди сидят и скучают, не знают, чем можно заняться, а организатор мероприятия занят и не может уделить им время.
В основном все крутят в руках телефоны и у большинства из них есть телеграмм. Что если сконнектить их максимально быстро и помочь найти общий язык через популярные застольные игры (нет, не игры по типу "кто больше выпьет")?
Можно засунуть популярные сценарии взаимодействия за столом в бота и сделать старт с минимальным количеством телодвижений: кидаем приглашение → выбираем игру → играем и развлекаемся.
Идеально, если будут комнаты, чтобы разделить гостей по интересам, когда одни играют в одно а другие в другое.
Ну и не стоит забывать про то что нужен минимальный порог входа, чтобы один раз ткнул и уже играешь (тоже есть не надо долго думать и шарится по непонятным меню).
Никаких мини-приложений, никаких "разрешите доступ к контактам" - зовём сами кого хотим как онлайн (через готовую красивую кнопочку для старта), так и оффлайн (просто показав QR соседу за столом).
Игра работает сама: если все приняли участие в игровом раунде - переходит дальше, если кто-то вышел или стало неинтересно и он афк - кикаем их (автоматически или руками), участники решили сыграть ещё - быстро проголосовали за следующую игру и играют без головняков.
Главная идея - никто не чувствовует себя ведущим. Чтобы можно было просто прийти, найти коннект за столом, зайти, поиграть - и вернуться к вину, разговору, поиску штопора или продолжить спать в салате.
Думаю собрать такой бот, но хз будет ли он интересен кому-то кроме меня?
Ниже пару скринов просто чтобы показать как это выглядит (не реклама, просто пример реализации для скринов, бот пока что оффлайн):
Пример приглашения:
Пример игры в ассоциации:
Сделано немного, просто чтобы посмотреть насколько это вообще удобно.
Пока что без проблем адаптируется такие активности как:
- Ассоциаци
- Игра в мемы
- Игра в мафию
Если интересно, может подскажете какие игры можно адаптировать и попробовать реализовать для режима "в диалоге".
Или, может, у вас уже есть свой «лайфхак», как завести компанию без напряга и долгой подготовки заранее?
Было бы круто услышать - вдруг что-то упускаю из виду.
P. S. Возможно это очередной велосипед, если знаете сервисы которые уже реализуют такое напишите, пожалуйста
Показать полностью
2
Яндекс!!! Верни мне деньги которые ты у меня повторно списывал месяцами за подписку плюса!!! У меня есть доказательства!!!
Приветствую тебя читатель, присаживайся, госпожа фортуна приготовила нам десерт после вкусного ужина.
Лёжа сегодня и прокручивая происходящее в голове я думал как мне попасть в этот мифический аккаунт, т.к. через единый ключ яндекса этот аккаунт не отображался, что-бы понять что вообще происходит.
Оказывается что в этот аккаунт, ДЛЯ УПРАВЛЕНИЯ СВОИМИ КАРТАМИ! я могу попасть только через приложение яндексГо, опять без паролей, без всего, просто тыкаю на аккаунт и захожу.
Тут нас встречает гениальное решение (очередное) не отображать кнопку с вашими картами, толи они грузятся (но показать что они грузятся это не так гениально как вообще ничего не показывать), толи яндекс их просто прячет, не знаю, но увидел я привязанную карту на мифическом аккаунте только со второго захода в приложение
Но знаете как понять что это 1 аккаунт? По истории такси, вот сравните:
Берем аккаунт которым я пользуюсь с 2018 года -
Смотрим у него последнюю историю -
Теперь берем историю из мифического аккаунта -
Посмотрите, история "ДРУГОГО" аккаунта последними заказми точно повторяет мой аккаунт с 2018 года... какие тут можно сделать выводы?)
Видать специалисты сами запутилась в своих микросервисах)) Ну или специально так все происходит?) Что из этого вероятней я не знаю)
Как у меня вообще карта привязывалась к этому аккаунту?) Надо будет за выпиской в банк сходить.
А пока я хожу, яндекс, может ваши BigDeal инженеры которые считают RPS и рассказывают всем какие они крутые и как надо делать, скинуться и вернут мне эти деньги?))) с Августа 2024 года я так понимаю)
Вообще интересно чем это все кончится, этого достаточно что-бы идти в роспотребнадзор?) Подскажите люди)
Ну и вот вам концовочку, мы же тут за вкуснятиной, почему-то я отвязал все карты от этого аккаунта, а уменя до сих пор пишет что есть привязанные, на будущее видимо)) Или у работяг кэш не прогрелся)))
Показать полностью
6
Тонем в микросервисах вместе с Яндексом, или как отключить подписку плюса от аккаунта который вы даже не хотели создавать
Приветствую читатель! Пришлось разобраться мне со своими аккаунтами яндекса после очередного непонятного для меня списания и общения с поддержкой и думаю мне есть что сказать.
Оказывается яндекс не может найти аккаунты с одним и тем же привязанным номером телефона через свой "ключ для всех сервисов", не является ли это введением в заблуждение? Ну тут я наверное не так понял, или воспользовался не той технологией) Если честно сил нет вкладывать эмоции в текст, просто хочется подвести сухой остаток и изложить некоторые мысли.
Вообщем после второго списания, я конечно же полез искать другие аккаунты, думая что "ключи для всех сервисов" найдут все мои аккаунты привязанны к телефону, собственно по номеру телефона.
Но нет, яндекс мне выдавал 1 аккаунт, который я регестрировал относительно недавно для почты (но пожалуй больше нет)
Собственно это тот аккаунт в который я входил по НОМЕРУ ТЕЛЕФОНА ЧЕРЕЗ СМС СООБЩЕНИЯ это достаточно важный момент, НО НЕ ТОТ ПРО КОТОРЫЙ МНЕ ГОВОРИЛА ПОДДЕРЖКА КОГДА ГОВОРИЛА ПРО АККАУНТ С ВХОДОМ ПО НОМЕРУ. Потому-что оказывается, у меня уже откуда-то существует 3 аккаунт, вообще без каких либо логинов, просто мое НАСТОЯЩЕЕ ИМЯ И ФАМИЛИЯ и мой номер телефона. Подчеркиваю что этот аккаунт на мое настоящиее имя и фамилию потому-что я НИКОГДА НЕ РЕГИСТРИРУЮ АККАУНТЫ СО СВОИМ НАСТОЯЩИМ ИМЕНЕМ И ФАМИЛИЕЙ, это моя позиция и везде где я могу я максимально избегаю этого, поэтому существование такого аккаунта для меня большая загадка.
Но самая большая для меня загадка, это то, что в странный мифический аккаунт я могу зайти только через телефон!!! БЕЗ ПАРОЛЕЙ, СМС, ПРОСТО НАЖАВ НА АККАУНТ СО СВОЕГО ТЕЛЕФОНА, причем повторюсь, при поиске по этому номеру мне выдает вообще другой аккаунт!
Это вообще нормальная ситуация? Получается я могу иметь доступ к своей учетке с платными подписками только через мобильный телефон?))
Мало того что с подписками! Дак еще с картами привязанными.
Яндекс, можете прокомментировать откуда вообще этот аккаунт взялся, если я с самого 1 дня пользуюсь яндекс музыкой через второй по списку?)))
Каким-то непонятным мне образом (хотя пару мыслей на этот счет есть). Появился этот аккаунт, привязываются карты, оформляется подписка плюса и я дальше спокойно пользовался аккаунтом номер 2 НА СВОЕМ ТЕЛЕФОНЕ даже не подозревая о существовании первого, потому-что на 1 ни лайков, ничего нет, он вообще пустой полностью!
Если честно копание в этих сервисах меня очень сильно утомило, иначе пост был бы еще вчера.
У меня что, получается 4 аккаунта в яндексе, если например брать аккаунт ЯдексГо с такси? Или уже 10, просто через ваш единый ключ нельзя их найти?
Я захожу в яндексго, там я под аккаунтом с тем же номер, захожу в поддержку, меня перекидывает в яндекс плюс, там я захожу через яндекс id, в другой аккаунт (по всей видимости, но все еще по тому же норму и СМС НА ЭТОТ НОМЕР, на этом моменте уже голова начинает побаливать) захожу опять в поддержку, где-то, параллельно, пока я натыкивал кнопки открылся браузер, там уже своя движуха.
А после того как вы пробрались в чат поддержки вас встречает мега ИИ, который вот вот и начнет хотя-бы сообщения в поддержке читать (пока он сам признается что не умеет).
И после всего этого, как вишенка вам выдается вкуснейший UX дизайн, вверх искусства на стыке инженерии и пользовательского опыта, конечно же я говорю про прекрасную форму поиска подписок по платежам.
Я ведь специально отключил яндекс плюс, а тут опять списание! (на этом моменте я еще ничего не знал про второй аккаунт доступный только с телефона, через тот же самый ЯНДЕКСID!!!!!!)
В порыве горящей точки, уже с болью в голове после пути до поддержки яндекс плюса, я просто не заметил что снизу, шрифтом с легкой ноткой прозрачнсоти, что-бы не мешать пользователю))))))) было написано - ввести первые 6 цифр и последние 4 карты, НО ПОЧЕМУ ФОРМАТ КАРТЫ НЕ НАПИСАН ПРИ ОШИБКЕ?)))))))
Узрите люди, какой вкуснятиной вас кормят "топ" UX дизайнеры, программисты и менеджеры.
Почему тут 3 звездочки? Если получается мы не вводим 6 цифр карты?) ЗАЧЕМ ВООБЩЕ ДОБАВЛЯТЬ ЭТИ ЗВЕЗДОЧКИ В ПОЛЕ, ЭТО КОНТР ИНТУИТИВНО!!! Почему сразу визуально не разделить поля? Да банально сделать 2 поля (первые 6 цифр вторые 4) ВСЕ! Еще и представляете, вы не можете в это решение скопировать номер карты и вставить, поле опять запихает свои 3 звездочки, откинет ваши цифры и заброкует ввод! Да, ну тут все логично, просто на литкод нету задачки как перехватить 16 цифр от пользователя и забрать из них первые 6 и последние 4... нет, это пользователю надо проследить за всем этим, мы же ему написали там с низу до того как ошибка вылезла!
Вот такое решение было принятно после 32 созвонов/согласовний на 64 человека, учитесь у бигтеха ребятки.
А знаете почему так получается?) Потому-что все усредненно, каждое решение это групповое мышление Техническая подоплека решений, пользователь, качество продукта - это все фон как бы странно это не казалось, самой главной мотивацией для групового мышления в компаниях это деньги) Так все просто, не хочу никого обидеть, но размер компании еще не значит что там работают топ инженеры/менеджеры/дизайнеры, туда попадают люди которые прошли отбор груповым мышлением.
На этом фоне очень смешно выглядят hr, когда они с непрекрытым пафосом, гордясь что работают в яндексе общаются с инженерами снисходительно, на самом деле даже не понимая и не имея возможности осознать проблемы)
Показать полностью
3
Пояснительная бригада: микросервисы
«Теперь при помощи контейнеров можно решить проблемы, которых не было до появления контейнеров»
В Великобритании по историческим причинам очень много где используются не смесители, а два отдельных крана. Весь остальной мир гадает, как же они в итоге пользуются этими кранами. Самый рабочий вариант для нас, кто привык к смесителям, — быстро-быстро подставляют руки под одну и под другую струю.
Так вот, микросервисы — это такие отдельные сервисы в общем приложении. Но встаёт вопрос: а как их объединить? Примерно как в британской ванной: давайте быстро-быстро опрашивать то один, то другой сервис.
— Паша Вавилин, наставник на курсе по Python
Показать полностью
1
Протокол вскрытия неопознанного распределенного монолита
[Начало аудиозаписи (бодрый голос, с нотками цинизма и усталости)]
Протокол вскрытия № 666-IT/2025. Дата: 17 мая 2025 года. Время: 05:30.
- Я, ведущий DevOps-патологоанатом Сисадминов А.А., приступаю к патологоанатомическому исследованию неопознанного распределенного монолита, поступившего из ООО "Светлое Будущее" после фатального падения системы, зафиксированного 16 мая 2025 в 23:58 по московскому времени.
- Присутствуют: я, младший специалист Логинов П.Р., стажер Архитекторова Н.Ю.
- Итак, начнем. Внешний осмотр. Перед нами типичный корпоративный монолит — старожил цифрового мира. Судя по следам от PHP 5.3 в виде комментариев к коду, датированным 2011 годом, ему не меньше 14 лет. Внушительный возраст для любой системы в кровавом Энтерпрайзе, не находите, Логинов?
- Да, это почти живой мамонт!
- Отмечаю критическую анемию документации. В репозитории — одинокий README.md от 2012 года с гордой надписью "TODO: написать документацию".
- Так, что у нас тут… Kubernetes? О, да! Модный, молодежный. Оркестрация уровня «дирижер в запое». Поды висят в CrashLoopBackOff чаще, чем разработчики этого чуда видят кофейный аппарт. Логи… о, мда, логи! «Something went wrong», «Error: null», «PANIC: KERNEL PANIC (not really, just kidding, or am I?)». Креативненько, ничего Логинов, возьмите образцы на анализ.
- Первичный осмотр выявляет множественные очаги копипасты. Особенно вопиющий случай — модуль авторизации. Код проверки прав доступа размножен 47 раз с минимальными правками. Это уже не просто технический долг, это цирк абсурда ролевых моделей!
- Вижу следы восьми разных фреймворков, некоторые из которых не совместимы. Это мне напоминает "инновационный борщ, тёщи, приправленный усушенными котлетками и жаренными пельменями", брр. А вот это что? Закомментированный кусок кода с пометкой «// Игорь, это не трогай, я сам не знаю, как оно работает, но без него все падает!!!11». Игорь, если ты это слышишь, ты был не прав – оно и с ним упало. Из мешанины использованных языков программирования в разных модулях, можно предположить, что разработчики стремились изобрести свой высокоуровневый Brainf**k, совсем чуточку не успели.
- Ага, вот и причина непосредственного отказа. Один из «сервисов» решил, что ему мало 128 Гб оперативной памяти и попытался сожрать еще столько же из свопа. Классический OOM Killer пришел и сделал свою работу. Но это, так сказать, орудие убийства. Причина отказа куда глубже.
[идет продолжительная работа]
- Отказ наступила из-за необратимых изменений кода, навороченных за 13 лет разными разработчиками с их "уникальным видением". Рекомендации родственникам: кремация кодовой базы и старт с нуля. Пациент был нежизнеспособен с момента зачатия идеи в воспаленном мозгу тимлида.
- Ладно, хватит лирики. Пойду оформлять официальный протокол, Логинов, мне нужны результаты анализов. Эти бюрократы из «МинЦифЗдрава» требуют всё по форме.
[Щелчок выключения диктофона]
УТВЕРЖДАЮ
Заместитель начальника Отдела цифровой патологии и реанимации информационных систем
И.И. Кибернетиков
«18» мая 2025 г.
ПРОТОКОЛ № 666-IT/2025 патологоанатомического вскрытия информационной системы
Наименование «ИТ» организации, в которой производится вскрытие: Отдел цифровой патологии и реанимации информационных систем Департамента по надзору за стабильностью критической инфраструктуры.
Дата и время поступления системы: 17.05.2025, 04:48 (MSK)
Идентификатор «умершего»: Проект «Прорыв-2012», версия - неизвестная.
Возраст (время эксплуатации до фатального сбоя): 14 лет, 3 месяца, 2 дня (в режиме «постоянно падает, но мы поднимаем»).
Дата и время «полного отказа»: 16.05.2025, 23:58 (MSK)
Основной «клинический» диагноз (предварительное заключение службы эксплуатации): «Все сломалось, ничего не работает, пользователи в ярости, не могут закрыть спринт».
Дата и время вскрытия: 17.05.2025, 05:30 (MSK)
Вскрытие производил: Ведущий DevOps-патологоанатом Сисадминов А.А.
Присутствовали: Младший специалист по цифровой некроскопии Логинов П.Р., стажер Архитекторова Н.Ю. (сбежала через 15 минут с криком «О боже! Да я лучше бухгалтерию, буду переводить на метод ФИФО!»).
НАРУЖНЫЙ ОСМОТР СИСТЕМЫ: «Кожные пользовательские интерфейсы» недоступны, ответ сервера HTTP 503 (Service Unavailable) на всех эндпоинтах. «Трупные ошибки в логах» обильные, хаотично распределены по всем компонентам системы. «Трупное зависание процессов» наблюдается в 6 из 8 основных модулей. Сопроводительная документация-анамнез разработки фрагментарна, содержит ненормативную лексику и наскальные рисунки, не относящиеся к делу. Архитектурная схема представлена в виде эскиза на длинном бумажном чеке из КБ, вызывает сомнения.
ВНУТРЕННЕЕ ИССЛЕДОВАНИЕ СЕРВИСОВ И ПОЛОСТЕЙ СИСТЕМЫ:
«Центральная нервная система Оркестратор Kubernetes»: Версия 1.25.х (устаревшая). Множественные Pod'ы в состоянии CrashLoopBackOff и ImagePullBackOff. Обнаружены некорректно сконфигурированные readiness и liveness пробы, приводящие к преждевременному «умерщвлению» работоспособных экземпляров. Конфигурационные файлы содержат критические данные в открытом виде.
«Сердечно-сетевая система межсервисного взаимодействие»: Топология сети избыточно сложная, напоминает «Гордиев узел». Задержки при взаимодействии между «микросервисами» достигают нескольких десятков секунд. Обнаружены следы использования самописного протокола поверх HTTP/1.1 для передачи бинарных данных, что приводило к их регулярной закупорке каналов связи. «Микросервисы» по факту являются монолитными приложениями, упакованными в Docker-контейнеры, с высоким уровнем связанности (tight coupling).
«Дыхательная API Gateway система»: API Gateway перегружен из-за отсутствия кэширования и неоптимальных запросов от фронтенда. Модуль «AuthService» демонстрирует признаки «гипертрофии» (размер Docker-образа 3 Гб) и «кислородного голодания» (регулярные OOM Killed). Обнаружены многочисленные хардкод-адреса зависимых сервисов.
«Пищеварительная база данных»: Основная СУБД PostgreSQL – горизонтально шардированная. Структура БД ненормализована, наименования таблиц и полей не соответствуют общепринятым стандартам (например, tbl_prod_final_v2_important). Индексы на часто запрашиваемых полях отсутствуют. Обнаружены следы «несварения» данных (неконсистентность) между репликами. Обнаружена метастаза в виде документно-ориентированной MongoDB из одной коллекции, c полу структурированными данными.
«Опорно-двигательная кодовая база»: Код написан на смеси Python, Go и Node.js (в рамках одного «микросервиса»), в наличии остаточные следы PHP. Присутствуют многочисленные «велосипеды» (самописные решения для стандартных задач). Уровень покрытия тестами – предположительно, менее 5%. Обнаружены закомментированные участки кода с пометками «не трогать, магия» и «костыль, убрать перед релизом».
ПАТОЛОГОАНАТОМИЧЕСКИЙ ДИАГНОЗ:
Основное «заболевание»: Острая декомпенсированная архитектурная недостаточность, развившаяся на фоне тотального игнорирования принципов проектирования распределенных систем и DevOps-практик. Тип: «Распределенный Монолит с полиорганной дисфункцией микросервисов».
Осложнения: Синдром каскадного отказа модулей. Терминальная стадия технического долга. Критическая зависимость от «магического кода Игоря», о чем свидетельствуют множественные коммиты. Фатальные уязвимости безопасности.
Сопутствующие «заболевания»: Хроническое отсутствие автоматизированного тестирования. Дефицит компетентной документации. Синдром «Неприятия чужой разработки» (NIH) в тяжелой форме.
ЗАКЛЮЧЕНИЕ О ПРИЧИНЕ «ОТКАЗА» СИСТЕМЫ: «Отказ» информационной системы «Прорыв-2012» наступила в результате совокупности критических архитектурных просчетов, некомпетентной реализации, отсутствия контроля качества и пренебрежения базовыми принципами разработки и эксплуатации ПО. Непосредственной причиной остановки функционирования явился отказ модуля «AuthService» вследствие исчерпания выделенных ресурсов памяти (OOM Killer), что вызвало цепную реакцию отказа зависимых компонентов. Система стала нежизнеспособна в долгосрочной (и, как оказалось, краткосрочной) перспективе.
РЕКОМЕНДАЦИИ:
Признать проект «Прорыв-2012» полностью несостоятельным.
Провести служебное расследование с целью выявления ответственных за принятие губительных архитектурных и технических решений.
Останки системы (репозитории, артефакты сборки, конфигурации) архивировать с пометкой «Крайне токсично. Не реанимировать!».
Команде разработки в полном составе пройти курсы повышения квалификации по темам: «Основы архитектуры ПО», «DevOps для чайников», «Тестирование – это не больно».
При планировании аналогичных проектов в будущем закладывать бюджет на привлечение внешних ИТ-архитекторов и независимых стейколдеров.
Ведущий DevOps-патологоанатом
___________________ Сисадминов А.А.
М.П. (Отдела Цифровой Патологии)
Показать полностью
3