если мы обсуждаем приложение и оно не может работать без карты - карта - это костыль к приложению.
Все билеты и денежные средства от пополнений привязаны к аккаунту в транспортной системе. Физическая карта - просто ключ для доступа к билетам на аккаунте. На карте напечатан номер этого аккаунта и он же прописан в чипе. Виртуальная "карта" в приложении - тот же самый аккаунт, только без физической карты. Считайте слово "карта" синонимом слова "аккаунт" и тогда станет понятнее.
Я понимаю, вас смущает момент, что сущность "билет" не существует отдельно от сущности "аккаунт". Отдельно билет без каких-либо привязок можно купить только в кассе метро. Это будет картонка с чипом. Можно считать её лайт версией карты тройки с фиксированным количеством предоплаченных поездок.
Можно. Просто два раза прикладываете карту (транспортную, банковскую), телефон или qr-код виртуальной тройки. В первый раз проходит ребёнок, во второй раз взрослый.
Да. Есть приложение для покупки билетов. Называется "тройка".
вот это что-то более-менее похожее, но без карты "тройка" похоже что еще не научились обходиться
Собственно, мосметро и является оператором карт "тройка". Непонятно что вы имеете ввиду. Если б карта называлась "московское метро" вместо "тройка", то вопросов у вас бы не возникло?
это все воркэраунды, вопрос был про приложение для покупки билетов, без доп. костылей в виде транспортной карты
Если вы имеете ввиду билеты по типу как в теарты и музеи, когда на почту присылают PDF со штрих-кодом, то такого в метро нет. Билеты записываются на аккаунт транспортной карты и они бывают разных типов: абонементные на количество дней/поездок или же "Билет «Кошелек»" (да, это его официальное название), который просто хранилище денег, откуда списывается стоимость поездки при проходе через турникет. Туда же можно записывать билеты на пригородный транспорт, а не только на метро.
А что это, если не лог? Почти то же самое, что nginx пишет в свои логи. Вот только nginx не пишет тело post запросов и у ответа логгирует только http код. А в своём приложении вы можете логгировать всё. Если ваше приложение - это REST API, то логгировать запрос и ответ - маст хэв. Это потом позволит отрабатывать вопросы вида "почему мой запрос был криво обработан?" и по логам будет понятно, что клиент прислал кривой запрос.
Профилирование - это не метрики. Для mysql профиль запроса - это список действий, которая база совершила для обработки одного конкретного запроса. Выглядит вот так: +--------------------------------+----------+
| Status | Duration |
+--------------------------------+----------+
| starting | 0.000015 |
| checking query cache for query | 0.000021 |
| checking permissions | 0.000003 |
| Opening tables | 0.000007 |
| System lock | 0.000004 |
| Table lock | 0.000023 |
| init | 0.000005 |
| optimizing | 0.000005 |
| executing | 0.000025 |
| end | 0.000003 |
| end | 0.000001 |
| query end | 0.000002 |
| storing result in query cache | 0.000003 |
| freeing items | 0.000003 |
| closing tables | 0.000004 |
| logging slow query | 0.000002 |
| cleaning up | 0.000001 |
+--------------------------------+----------+ Графана откуда эти данные возьмёт?
Профилировка очень выручает в моменты, когда база начинает необъяснимо тормозить. По профилю видно где конкретно затык у базы и дальше проще понять что именно нужно сделать для устранения тормозов.
> Кстати, насчёт графаны - длинные логи там смотреть неудобно. Смотрите в файле тогда.
> А вот что писать в INFO и TRACE как-то не очень очевидно. Опишите какой у вас сервис и я подскажу. Но в целом, уровни зависят от того, что вы хотите делать с логами.
Логи уровня ERROR и выше обычно отправляются на email разработчикам. FATAL и выше уже отправляются в СМС/мессенджеры. INFO - это просто обычное нормальное выполнение приложения. Сюда записывают данные, которые помогают решить максимум вопросов, возникаюших у клиентов, пользующихся вашим сервисом и ваших сотрудников, которые тоже пользуются или эксплуатируют ваш сервис. DEBUG используется для более подробных логов. Например, значения ключевых переменных, на основе которых делается какой-то важный выбор по ходу исполнения кода. DEBUG - это расширенный INFO. Эта инфа нужна для траблшутинга более сложных и нестандартных ситуаций. TRACE - максимально подробные данные. Возможно даже требующие дополнительных действий в коде как в моём примере про профилировку mysql запросов. В обычной ситуации на проде никто не делает профилировку запросов. Но иногда нужно.
Так как DEBUG и TRACE обычно гораздо более объёмные, чем INFO, то чаще всего приложение запускают с базовым уровнем логгирования INFO. Это значит, что в логи будет записываться только инфа с уровнем INFO и выше, а всё остальное игнорироваться. DEBUG, TRACE включаются по мере необходимости для исследования сложной и нестандартной проблемы, а затем снова выключаются. То есть это данные, которые нужны время от времени, а не на постоянной основе.
Всегда имеет смысл логгировать входящий запрос и ответ на него. Если в процессе обработки запроса делаются запросы в другие сервисы, то аналогично логгируем запрос к сервису и его ответ. Дальше уже по мере жизни проекта будут добавляться более подробные логи.
Обычно много уровней используется в старых проектах с долгой историей. На старте хватает двух - INFO и ERROR. В ERROR записываются исключения, которые смогли вылезти на самый верх (обычно такие провоцируют 500 ошибку). Ещё туда можно засунуть какую-нибудь специфическую ошибку при обращении к удалённому API, типа "закончились деньги на аккаунте" или "аккаунт заблокирован". Я настраиваю логгирующие фреймворки, чтобы они отправляли все события с уровнем ERROR в sentry. В моём коде никогда не вызывается sentry напрямую.
Хороший вариант сразу логгировать все имеющиеся SQL запросы с уровнем TRACE вместе со временем выполнения запроса и количеством выбранных/затронутых строк. Далее настроить чтобы в лог записывались уровни INFO и выше. В дальнейшем при возникновении тормозов или непонятного поведения базы просто переключить уровень лога на TRACE и внимательно смотреть в логи. Маньяки могут ещё добавить профилирование запросов. Грубо говоря: if (log.isLevel(TRACE)) { db.query("SET profiling = 1"); db.query(sql); profile = db.query("SHOW PROFILE"); log.trace(profile); db.query("SET profiling = 0"); } else { db.query(sql); }. Кстати говоря, это отличный пример более тонкой разницы в уровнях. Сам запрос можно логгировать на уровне TRACE, а профайлинг на TRACE2. Или запрос на DEBUG, профайлинг на TRACE.
В java мире этот вопрос был решен давно и навсегда. Исключение обычно можно передать последним параметром при вызове лог метода и оно будет автоматически отформатировано и записано в лог с учётом вложенных исключений, если они есть. В текстовых файлах будет стек трейс столбиком с отступами, в sentry трейс тоже корректно раскладывается и склеивается с другими такими же. Если сконфигурировать json formatter, то каждый фрейм будет элементом массива. И всё это не меняя ни единой строчки кода.
Вариант попроще - закрыть интернет и сделать pull. Не знаю насчёт подмана, но утилита docker в описании ошибки напишет url, до которого не может достучаться. Что-то типа Error response from daemon: Get https://index.docker.io/v1/users/: dial tcp: ... i/o timeout. Далее берёте домен, смотрите какие на нём IP адреса (например, командами host, nslookup, dig) и прописывете в свой фаервол. Повторяете pull, смотрите какой новый домен вылез в ошибке и прописываете его. Повторяете процедуру, пока ошибки не закончатся.
Но есть загвоздка. IP адреса у докер хаба регулярно меняются, поэтому недостаточно один раз найти какие-то адреса и прописать их. Да и поддоменов у него тоже дофига. Так что будете регулярно разбираться почему докер хаб снова отвалился и какие у него теперь новые актуальные адреса.
По классике эта проблема решается использованием прокси сервера. Например, squid. На фаерволе разрешаете интернет только прокси серверу (в линуксе это возможно при помощи модуля -m owner --uid-owner). В настройках прокси разрешаете домены '*.docker.io' и '*.docker.com'. Далее настраиваете подман на использование прокси (опять же, не могу сказать как это делается у подмана, но для докера есть мануал). И всё. Проблема решена.
В дальнейшем наверняка потребуется открыть доступ к репозиториям для обновления ос (для дебиана это '*.debian.org', для убунту 'archive.ubuntu.com', 'security.ubuntu.com'), затем к другим реестрам контейнеров, например, github ('ghcr.io', 'pkg-containers.githubusercontent.com'), google ('gcr.io'), редхат ('quay.io') и может ещё какие-нибудь. Управлять этим на уровне фаервола хоть и принципиально возможно, но крайне муторно.
Так же через прокси легко обходить блокировки. Например, когда докер хаб заблокировал РФ, я просто поднял ещё один прокси в хецнере и на основном прокси сервере настроил проксирование докеровских доменов через хецнер. И когда коллеги из соседних команд ещё даже не до конца поняли что случилось и что делать, у меня уже всё работало.
Как человек, съевший собаку на СМС вообще и на SMPP в частности, советую тем, кто собирается внедрять у себя смски, трижды подумать: так уж сильно ли вашему бизнесу нужны именно они. Любой канал для коммуникаций будет лучше смс - email, мессенджеры, пуши. Особенно для передачи чувствительной информации - одноразовых кодов, паролей, списаний со счёта и т.п.
Смс - крайне ненадежный вариант в плане качества доставки. Одна из популярных причин недоставки - нехватка свободной памяти в телефоне. Свободной памяти, Карл! На современных телефонах с 256 ГБ памяти! И ещё много других прикольных и не очень ситуаций.
Смс - крайне ненадёжный вариант в плане безопасности. За примерами далеко ходить не нужно. А ещё большинство сайтов, требующих номер телефона, очень слабо реализуют валидацию по смс. Из-за этого появилось такое печально известное явление как смс-бомбинг. Для бизнеса есть ещё риск попасть на бабки через тот же самый смс бомбинг или утечку пароля от смс сервиса, что мощно накрутит счета у поставщика смс услуг. Таких случаев тоже видел немало. И поставщики не стесняются посудиться.
Однажды я давал советы как можно улучшить защиту своих смс форм.
Но если вы всё же решитесь внедрить смс, то старайтесь выбрать какой угодно протокол, только не SMPP. Казалось бы, SMPP - стандартный протокол для передачи смс, поддерживаемый всеми операторами и агрегаторами. Реализуй один раз и можешь безболезненно менять поставщиков хоть каждый день. Но это неправда. Выбирая SMPP вы выбираете путь боли и страданий. Реализация SMPP у разных поставщиков отличается, а сам по себе протокол очень сложный и низкоуровневый. Начать хотя бы с того, что он бинарный, что само по себе становится непреодолимой преградой при траблшутинге для большинства программистов. Ещё в SMPP большое количество нюансов и тонкостей. Взять хотя бы эту статью: "data_coding: 0x08, // Кодировка сообщения (0x08 для Unicode, 0x00 для GSM7)". 0x08 - это unicode, но не указана какая именно кодировка из всего семейства юникодов. По спецификации SMPP - это древневековый UCS-2, но по факту все на рынке поддерживают UTF-16BE. А 0x00 - это "message center specific" по спецификации. То есть кодировка, которая может отличаться от поставщика к поставщику. У кого-то это GSM 03.38, у кого-то latin1, у кого-то ASCII или даже юникод какой-нибудь. Да и что значит GSM7? Это упакованный в 7 бит вариант GSM 03.38? Ну и ещё возникают вопросы про параметры source_addr_ton/npi. Значения 1/1 используются только если отправитель указывается в виде номер телефона, что в РФ уже много лет как запрещено, а для альфанумерического отправителя надо задавать 5/0. Так что в статье скорее всего ошибка в примере. Раз уж даже специалисты не смогли написать нормальный пример для этой статьи, то впервые сталкивающиеся с SMPP протоколом либо сойдут с ума, либо познают дзен. И это я ещё не затрагиваю крайне хитрый вопрос с отправкой длинных многосегментных смс.
Поэтому оказывается проще отдельно реализовать HTTP API каждого отдельного поставщика, чем мучиться с SMPP.
Совет обычным пользователям. Если сервис использует смс для входа, то по возможности настройте более приличный вариант. TOTP, например, который много где поддерживается. Даже в госуслугах. Учитывая, что современные мошенники почти всегда фокусируются именно на взломе госуслуг, то лучше не откладывайте и перейтине на подтверждение входа на госуслуги через TOTP прямо сейчас.
Это если шлем уже активирован и на него можно что-то поставить. Новый Quest 3 при первом включении лезет в интернет проверять обновления и проверяет до бесконечности. Пропустить этот этап нельзя. Причём VPN на роутере не помогает. Это косяк прошивки. Помогает только обновление через adb sideload.
Мне больше нравится байка про алгоритм покупки автомобиля, авторство которого приписывают Сеймуру Крэю:
Вы идете в магазин, ближайший к вашему дому, показываете на машину, ближайшую к двери, и говорите: «Я беру эту». Этот алгоритм позволяет тратить минимум времени на не очень важные дела (покупку автомобилей) и оставляет большую часть времени на важные (разработку суперкомпьютеров).
Во всех мокрых зонах установили датчики протечки (в том числе в зону инсталляции смывного бачка, коллекторов, под ванную). Их подключили к модулю Нептун со своей автоматизацией (выбор проектировщика)
Проектировщик выбрал нептун, потому что родной WB-MWAC отсутствует в продаже.
Все билеты и денежные средства от пополнений привязаны к аккаунту в транспортной системе. Физическая карта - просто ключ для доступа к билетам на аккаунте. На карте напечатан номер этого аккаунта и он же прописан в чипе. Виртуальная "карта" в приложении - тот же самый аккаунт, только без физической карты. Считайте слово "карта" синонимом слова "аккаунт" и тогда станет понятнее.
Я понимаю, вас смущает момент, что сущность "билет" не существует отдельно от сущности "аккаунт". Отдельно билет без каких-либо привязок можно купить только в кассе метро. Это будет картонка с чипом. Можно считать её лайт версией карты тройки с фиксированным количеством предоплаченных поездок.
Можно. Просто два раза прикладываете карту (транспортную, банковскую), телефон или qr-код виртуальной тройки. В первый раз проходит ребёнок, во второй раз взрослый.
Да. Есть приложение для покупки билетов. Называется "тройка".
Собственно, мосметро и является оператором карт "тройка". Непонятно что вы имеете ввиду. Если б карта называлась "московское метро" вместо "тройка", то вопросов у вас бы не возникло?
Если вы имеете ввиду билеты по типу как в теарты и музеи, когда на почту присылают PDF со штрих-кодом, то такого в метро нет. Билеты записываются на аккаунт транспортной карты и они бывают разных типов: абонементные на количество дней/поездок или же "Билет «Кошелек»" (да, это его официальное название), который просто хранилище денег, откуда списывается стоимость поездки при проходе через турникет. Туда же можно записывать билеты на пригородный транспорт, а не только на метро.
Да. Это расширение для x86 команд называется AES-NI. Реализовано и у AMD в том числе.
А что это, если не лог? Почти то же самое, что nginx пишет в свои логи. Вот только nginx не пишет тело post запросов и у ответа логгирует только http код. А в своём приложении вы можете логгировать всё. Если ваше приложение - это REST API, то логгировать запрос и ответ - маст хэв. Это потом позволит отрабатывать вопросы вида "почему мой запрос был криво обработан?" и по логам будет понятно, что клиент прислал кривой запрос.
Профилирование - это не метрики. Для mysql профиль запроса - это список действий, которая база совершила для обработки одного конкретного запроса.
Выглядит вот так:
+--------------------------------+----------+ | Status | Duration | +--------------------------------+----------+ | starting | 0.000015 | | checking query cache for query | 0.000021 | | checking permissions | 0.000003 | | Opening tables | 0.000007 | | System lock | 0.000004 | | Table lock | 0.000023 | | init | 0.000005 | | optimizing | 0.000005 | | executing | 0.000025 | | end | 0.000003 | | end | 0.000001 | | query end | 0.000002 | | storing result in query cache | 0.000003 | | freeing items | 0.000003 | | closing tables | 0.000004 | | logging slow query | 0.000002 | | cleaning up | 0.000001 | +--------------------------------+----------+Графана откуда эти данные возьмёт?
Профилировка очень выручает в моменты, когда база начинает необъяснимо тормозить. По профилю видно где конкретно затык у базы и дальше проще понять что именно нужно сделать для устранения тормозов.
> Кстати, насчёт графаны - длинные логи там смотреть неудобно.
Смотрите в файле тогда.
> А вот что писать в INFO и TRACE как-то не очень очевидно.
Опишите какой у вас сервис и я подскажу. Но в целом, уровни зависят от того, что вы хотите делать с логами.
Логи уровня ERROR и выше обычно отправляются на email разработчикам. FATAL и выше уже отправляются в СМС/мессенджеры. INFO - это просто обычное нормальное выполнение приложения. Сюда записывают данные, которые помогают решить максимум вопросов, возникаюших у клиентов, пользующихся вашим сервисом и ваших сотрудников, которые тоже пользуются или эксплуатируют ваш сервис. DEBUG используется для более подробных логов. Например, значения ключевых переменных, на основе которых делается какой-то важный выбор по ходу исполнения кода. DEBUG - это расширенный INFO. Эта инфа нужна для траблшутинга более сложных и нестандартных ситуаций. TRACE - максимально подробные данные. Возможно даже требующие дополнительных действий в коде как в моём примере про профилировку mysql запросов. В обычной ситуации на проде никто не делает профилировку запросов. Но иногда нужно.
Так как DEBUG и TRACE обычно гораздо более объёмные, чем INFO, то чаще всего приложение запускают с базовым уровнем логгирования INFO. Это значит, что в логи будет записываться только инфа с уровнем INFO и выше, а всё остальное игнорироваться. DEBUG, TRACE включаются по мере необходимости для исследования сложной и нестандартной проблемы, а затем снова выключаются. То есть это данные, которые нужны время от времени, а не на постоянной основе.
Всегда имеет смысл логгировать входящий запрос и ответ на него. Если в процессе обработки запроса делаются запросы в другие сервисы, то аналогично логгируем запрос к сервису и его ответ. Дальше уже по мере жизни проекта будут добавляться более подробные логи.
Обычно много уровней используется в старых проектах с долгой историей. На старте хватает двух - INFO и ERROR. В ERROR записываются исключения, которые смогли вылезти на самый верх (обычно такие провоцируют 500 ошибку). Ещё туда можно засунуть какую-нибудь специфическую ошибку при обращении к удалённому API, типа "закончились деньги на аккаунте" или "аккаунт заблокирован". Я настраиваю логгирующие фреймворки, чтобы они отправляли все события с уровнем ERROR в sentry. В моём коде никогда не вызывается sentry напрямую.
Хороший вариант сразу логгировать все имеющиеся SQL запросы с уровнем TRACE вместе со временем выполнения запроса и количеством выбранных/затронутых строк. Далее настроить чтобы в лог записывались уровни INFO и выше. В дальнейшем при возникновении тормозов или непонятного поведения базы просто переключить уровень лога на TRACE и внимательно смотреть в логи. Маньяки могут ещё добавить профилирование запросов. Грубо говоря:
if (log.isLevel(TRACE)) { db.query("SET profiling = 1"); db.query(sql); profile = db.query("SHOW PROFILE"); log.trace(profile); db.query("SET profiling = 0"); } else { db.query(sql); }. Кстати говоря, это отличный пример более тонкой разницы в уровнях. Сам запрос можно логгировать на уровне TRACE, а профайлинг на TRACE2. Или запрос на DEBUG, профайлинг на TRACE.В java мире этот вопрос был решен давно и навсегда. Исключение обычно можно передать последним параметром при вызове лог метода и оно будет автоматически отформатировано и записано в лог с учётом вложенных исключений, если они есть. В текстовых файлах будет стек трейс столбиком с отступами, в sentry трейс тоже корректно раскладывается и склеивается с другими такими же. Если сконфигурировать json formatter, то каждый фрейм будет элементом массива. И всё это не меняя ни единой строчки кода.
Вариант попроще - закрыть интернет и сделать pull. Не знаю насчёт подмана, но утилита docker в описании ошибки напишет url, до которого не может достучаться. Что-то типа
Error response from daemon: Get https://index.docker.io/v1/users/: dial tcp: ... i/o timeout. Далее берёте домен, смотрите какие на нём IP адреса (например, командами host, nslookup, dig) и прописывете в свой фаервол. Повторяете pull, смотрите какой новый домен вылез в ошибке и прописываете его. Повторяете процедуру, пока ошибки не закончатся.Но есть загвоздка. IP адреса у докер хаба регулярно меняются, поэтому недостаточно один раз найти какие-то адреса и прописать их. Да и поддоменов у него тоже дофига. Так что будете регулярно разбираться почему докер хаб снова отвалился и какие у него теперь новые актуальные адреса.
По классике эта проблема решается использованием прокси сервера. Например, squid. На фаерволе разрешаете интернет только прокси серверу (в линуксе это возможно при помощи модуля -m owner --uid-owner). В настройках прокси разрешаете домены '*.docker.io' и '*.docker.com'. Далее настраиваете подман на использование прокси (опять же, не могу сказать как это делается у подмана, но для докера есть мануал). И всё. Проблема решена.
В дальнейшем наверняка потребуется открыть доступ к репозиториям для обновления ос (для дебиана это '*.debian.org', для убунту 'archive.ubuntu.com', 'security.ubuntu.com'), затем к другим реестрам контейнеров, например, github ('ghcr.io', 'pkg-containers.githubusercontent.com'), google ('gcr.io'), редхат ('quay.io') и может ещё какие-нибудь. Управлять этим на уровне фаервола хоть и принципиально возможно, но крайне муторно.
Так же через прокси легко обходить блокировки. Например, когда докер хаб заблокировал РФ, я просто поднял ещё один прокси в хецнере и на основном прокси сервере настроил проксирование докеровских доменов через хецнер. И когда коллеги из соседних команд ещё даже не до конца поняли что случилось и что делать, у меня уже всё работало.
Собственно, где в статье про перехват HTTP/HTTPS?
Ожидал увидеть как вкрывают HTTPS, а на деле увидел "ЧАТ GPT".
Вероятно, кабель забыли/поленились добавить в пучок и силовые провода, идущие параллельно витой паре:
Как человек, съевший собаку на СМС вообще и на SMPP в частности, советую тем, кто собирается внедрять у себя смски, трижды подумать: так уж сильно ли вашему бизнесу нужны именно они. Любой канал для коммуникаций будет лучше смс - email, мессенджеры, пуши. Особенно для передачи чувствительной информации - одноразовых кодов, паролей, списаний со счёта и т.п.
Смс - крайне ненадежный вариант в плане качества доставки. Одна из популярных причин недоставки - нехватка свободной памяти в телефоне. Свободной памяти, Карл! На современных телефонах с 256 ГБ памяти! И ещё много других прикольных и не очень ситуаций.
Смс - крайне ненадёжный вариант в плане безопасности. За примерами далеко ходить не нужно. А ещё большинство сайтов, требующих номер телефона, очень слабо реализуют валидацию по смс. Из-за этого появилось такое печально известное явление как смс-бомбинг. Для бизнеса есть ещё риск попасть на бабки через тот же самый смс бомбинг или утечку пароля от смс сервиса, что мощно накрутит счета у поставщика смс услуг. Таких случаев тоже видел немало. И поставщики не стесняются посудиться.
Однажды я давал советы как можно улучшить защиту своих смс форм.
Но если вы всё же решитесь внедрить смс, то старайтесь выбрать какой угодно протокол, только не SMPP. Казалось бы, SMPP - стандартный протокол для передачи смс, поддерживаемый всеми операторами и агрегаторами. Реализуй один раз и можешь безболезненно менять поставщиков хоть каждый день. Но это неправда. Выбирая SMPP вы выбираете путь боли и страданий. Реализация SMPP у разных поставщиков отличается, а сам по себе протокол очень сложный и низкоуровневый. Начать хотя бы с того, что он бинарный, что само по себе становится непреодолимой преградой при траблшутинге для большинства программистов. Ещё в SMPP большое количество нюансов и тонкостей. Взять хотя бы эту статью: "
data_coding: 0x08, // Кодировка сообщения (0x08 для Unicode, 0x00 для GSM7)". 0x08 - это unicode, но не указана какая именно кодировка из всего семейства юникодов. По спецификации SMPP - это древневековый UCS-2, но по факту все на рынке поддерживают UTF-16BE. А 0x00 - это "message center specific" по спецификации. То есть кодировка, которая может отличаться от поставщика к поставщику. У кого-то это GSM 03.38, у кого-то latin1, у кого-то ASCII или даже юникод какой-нибудь. Да и что значит GSM7? Это упакованный в 7 бит вариант GSM 03.38? Ну и ещё возникают вопросы про параметры source_addr_ton/npi. Значения 1/1 используются только если отправитель указывается в виде номер телефона, что в РФ уже много лет как запрещено, а для альфанумерического отправителя надо задавать 5/0. Так что в статье скорее всего ошибка в примере. Раз уж даже специалисты не смогли написать нормальный пример для этой статьи, то впервые сталкивающиеся с SMPP протоколом либо сойдут с ума, либо познают дзен. И это я ещё не затрагиваю крайне хитрый вопрос с отправкой длинных многосегментных смс.Поэтому оказывается проще отдельно реализовать HTTP API каждого отдельного поставщика, чем мучиться с SMPP.
Совет обычным пользователям. Если сервис использует смс для входа, то по возможности настройте более приличный вариант. TOTP, например, который много где поддерживается. Даже в госуслугах. Учитывая, что современные мошенники почти всегда фокусируются именно на взломе госуслуг, то лучше не откладывайте и перейтине на подтверждение входа на госуслуги через TOTP прямо сейчас.
AppImage ещё.
KRaft этот безумно сырой. Рано они его в прод выкатили.
Это если шлем уже активирован и на него можно что-то поставить. Новый Quest 3 при первом включении лезет в интернет проверять обновления и проверяет до бесконечности. Пропустить этот этап нельзя. Причём VPN на роутере не помогает. Это косяк прошивки. Помогает только обновление через adb sideload.
Мне больше нравится байка про алгоритм покупки автомобиля, авторство которого приписывают Сеймуру Крэю:
Проектировщик выбрал нептун, потому что родной WB-MWAC отсутствует в продаже.
Так кнопка возврата должна быть у получателя, а не отправителя.
Это фейковая вакансия, чтобы привлечь внимание к настоящей.
Изначально речь шла про беллсофт. Либерика осталась за беллсофтом. Беллсофт - американская компания, поддерживающая санкции.
Аксиом - продукт не для широких масс. Он не может быть полноценной заменой либерики.
Она перестала быть нашей после переезда в США.
Не перерегистрируют. Рынок к тому моменту уже будет занят сбером и прочими нашими компаниями.
К тому же кто даст гарантию, что беллсофт после возвращения снова не сбегут?
Компания по вашей ссылке ликвидирована. Несите другую.