Эх, после прочтения сразу внутренняя кухня мессенджера Telegram вспомнилась: где выпускники СПбГУ замутили собственный "язык программирования" для простых RPC-запросов к серверу, чтобы не использовать JSON...в итоге JSON все равно пришлось использовать, передавая его с помощью своей костыльной TL-схемы.
"Раздутость" - это слишком общий термин. "В компании, поставляющей сложнейший софт для моделирования производственных процессов" может просто не быть такого же числа процессов и клиентов, которые есть у Twitter - от того и 1.5 тысячи сотрудников хватает с головой для поддержки деятельности на должном уровне. Иметь 1 процесс, требующий серьезных навыков программирования, не эквивалентно по числу микросервисов множеству процессов, не требующих серьезных навыков программирования.
Как показывает многолетняя практика, можно составить всеобъемлющую базу знаний, но невозможно её поддерживать в актуальном состоянии длительное время. Более того, попытки побороть это могут привести к обратному эффекту - дезинформации: либо уставший инженер не так (не там) изложит свои мысли, либо технический писатель не так поймет и не правильно зафиксирует то, что ему объяснил уставший инженер. Статический текст не работает, одним словом. Со временем приходишь к тому, что единственно надежный способ закреплять знания и опыт должен быть динамичным: в виде строгих процессов BPM (в любой среде мониторинга процессов) или с помощью банальной автоматизации процессов (CI\CD) - это работает.
Текстовую базу знаний еще можно оправдать, когда она представляется базой указателей, которая лишь прочертит общий путь, но не даст всеобъемлющих ответов на интересующие вопросы (простой текст просто не способен это сделать). А указатели уже могут указывать и на живых людей, и на чаты.
Классное расследование! Очень повезло, что веб-сервер был сконфигугрирован неверно, и при переходе по IP адресу фишингового домена удалось попасть на Iserver.pro - иначе, на этом бы расследование могло и закончиться.
Имхо, именно в таком мышлении кроется проблема технологического роста большинства стартапов. "Оптимизацию" тоже нужно уметь проводить: найти баланс между "масштабируемостью" и "преждевременностью" — большое искусство.
В целом ситуация выглядит как результат классической незрелости процессов в российских IT- и около IT-шных организациях. Причины такой безалаберности могут корнями уходить в человеческий фактор, который не был «обмазан» регламентами/бизнес-процессами с целью нивелирования. И в конечном счете все могло вылиться в то, что внутри организации какой-нибудь оператор технической поддержки на автомате, увидев какую-нибудь стандартную форму обращения, слил ваши ПД какому-то третьему лицу, которое вполне себе представляло уровень незрелости «Регистратор Р01».
Хорошо, когда у вас уже выстроенная культура разработки, способствующая зелёному росту. Но на начальных стадиях, когда вы только в процессе построения такой культуры в молодой организации/команде, и многое зависит от людей, которые склонны уходить из организации из-за желания "все и сразу", иной раз задумываешься: "а не являются ли диктаторские методы единственным правильным решением в данный момент?..".
У меня для вас хорошие (плохие) новости — для того, чтобы подделать "Переписку с Мадонной" не обязательно было мучаться с нативными приложениями — с таким же успехом можно было подделать HTML в весовой версии)
Но с точки зрения реверса Instagram — спасибо за статью: ещё одна новая статья про внутреннюю работу Instagram всегда полезна
CDP на продакшн хроме + мобильные прокси - вот и весь секрет практически гарантированного обхода любых детектов.
А самый простой вариант реализации связки - через Playwright.
Да и зачем это все, когда можно просто купить маркированную рекламу у канала...
Ну и бот для защиты канала от накрутки в копилку - @channel_guardian_bot
А остались ли другие "падения по другой причине" остаётся загадкой и по настоящий день...
Мобильные клиенты сделаны на основе официальных опенсорсных клиентов Wireguard?
В этом вся проблема любых компаний-"китов": становятся китами и начинают наглеть, осознавая, что кроме них выбора у людей особо нет.
Эх, после прочтения сразу внутренняя кухня мессенджера Telegram вспомнилась: где выпускники СПбГУ замутили собственный "язык программирования" для простых RPC-запросов к серверу, чтобы не использовать JSON...в итоге JSON все равно пришлось использовать, передавая его с помощью своей костыльной TL-схемы.
"Раздутость" - это слишком общий термин. "В компании, поставляющей сложнейший софт для моделирования производственных процессов" может просто не быть такого же числа процессов и клиентов, которые есть у Twitter - от того и 1.5 тысячи сотрудников хватает с головой для поддержки деятельности на должном уровне. Иметь 1 процесс, требующий серьезных навыков программирования, не эквивалентно по числу микросервисов множеству процессов, не требующих серьезных навыков программирования.
А ради чего все эти заморочки? Чтобы каждый раз в браузере при открытии сайта сбербанка не тыкать "Доверять этому сертификату"?
Как показывает многолетняя практика, можно составить всеобъемлющую базу знаний, но невозможно её поддерживать в актуальном состоянии длительное время. Более того, попытки побороть это могут привести к обратному эффекту - дезинформации: либо уставший инженер не так (не там) изложит свои мысли, либо технический писатель не так поймет и не правильно зафиксирует то, что ему объяснил уставший инженер. Статический текст не работает, одним словом. Со временем приходишь к тому, что единственно надежный способ закреплять знания и опыт должен быть динамичным: в виде строгих процессов BPM (в любой среде мониторинга процессов) или с помощью банальной автоматизации процессов (CI\CD) - это работает.
Текстовую базу знаний еще можно оправдать, когда она представляется базой указателей, которая лишь прочертит общий путь, но не даст всеобъемлющих ответов на интересующие вопросы (простой текст просто не способен это сделать). А указатели уже могут указывать и на живых людей, и на чаты.
Классное расследование! Очень повезло, что веб-сервер был сконфигугрирован неверно, и при переходе по IP адресу фишингового домена удалось попасть на Iserver.pro - иначе, на этом бы расследование могло и закончиться.
Имхо, именно в таком мышлении кроется проблема технологического роста большинства стартапов. "Оптимизацию" тоже нужно уметь проводить: найти баланс между "масштабируемостью" и "преждевременностью" — большое искусство.
У всех монолитов одна судьба: смерть либо трансформация в микросервисы :)
Нужна ли компании масштабируемость?
Когда станет нужно, будет уже поздно
Хорошо, когда у вас уже выстроенная культура разработки, способствующая зелёному росту. Но на начальных стадиях, когда вы только в процессе построения такой культуры в молодой организации/команде, и многое зависит от людей, которые склонны уходить из организации из-за желания "все и сразу", иной раз задумываешься: "а не являются ли диктаторские методы единственным правильным решением в данный момент?..".
У меня для вас хорошие (плохие) новости — для того, чтобы подделать "Переписку с Мадонной" не обязательно было мучаться с нативными приложениями — с таким же успехом можно было подделать HTML в весовой версии)
Но с точки зрения реверса Instagram — спасибо за статью: ещё одна новая статья про внутреннюю работу Instagram всегда полезна