Какую ОС и ее ядро профессор Таненбаум (автор популярной книги «Современные операционные системы») в начале 1990-х назвал устаревшей и «гигантским шагом назад в 1970-е»?
Anonymous Quiz
14%
a
18%
b
50%
c
18%
d
В нашем публичном чатике (https://t.me/+iXw5mU2jeE9hZWI6) вас ожидает один дополнительный вопрос)
Telegram
The Head: публичный чатик
Придумываем идеи, создаем новые технологии и улучшаем существующие.
Канал в tg: @headlessdevs
https://thehead.ru
Канал в tg: @headlessdevs
https://thehead.ru
Яндекс Пэй исключил поддержку веб-интерфейса для оплаты в мобильных приложениях, при этом кроссплатформенные приложения на Flutter остались без поддержки со стороны Яндекс Пэй.
Наши разработчики это исправили. Сначала в мобильном приложении Адамаса. А затем было решено опубликовать наше SDK и сделать его доступным для всех.
По этому поводу коллеги написали статью на Хабре: https://habr.com/ru/articles/875834/
Если вы тоже разрабатываете на Flutter и ищете способ интеграции Яндекс Пэй, наше SDK доступно на pub.dev: ypay (github) и ypay_inventory (github)
Наши разработчики это исправили. Сначала в мобильном приложении Адамаса. А затем было решено опубликовать наше SDK и сделать его доступным для всех.
По этому поводу коллеги написали статью на Хабре: https://habr.com/ru/articles/875834/
Если вы тоже разрабатываете на Flutter и ищете способ интеграции Яндекс Пэй, наше SDK доступно на pub.dev: ypay (github) и ypay_inventory (github)
🔥3
Всем привет! Наш новый год начался с огромного количества дней рождения наших замечательных коллег. Всем ребятам были вручены подарки, которые отражали их мечты, стремления и увлечения. Всех ребят еще раз С Днем Рождения!
🔥6❤3
Есть у нас один проект, переданный нам уже готовым для развития и поддержки. Делала его когда-то одна именитая компания из Екатеринбурга.
Мы сразу заподозрили неладное: небольшой региональный магазин построен с попытками построить архитектуру, присущую большим сервисам и командам: здесь можно найти и несколько админок на разных стеках — для работы всего двух человек (и обе приходится использовать), и кластер k8s, и балансировщик нагрузки (traefik), стоящий перед единственным nginx, и аналог s3 для хранения штук 5 PDF и сотни jpeg'ов. Конечно, все это работает на единственном недорогом виртуальном сервере — даже не физическом — с уже давно неподдерживаемой ОС и никогда не обновлявшимися пакетами.
О документации ко всему безобразию, конечно, и говорить не приходится — ни единой строчки.
На днях к нам приходит запрос: клиенты не могут просматривать некоторые свои заказы в личном кабинете и не могут оплачивать их.
Начинаем разбираться. Небольшие заказы можно просмотреть и оплатить без каких-либо проблем. Но если в заказе более 100 позиций, сервер долго обрабатывает запрос на получение. данных заказа и возвращает 500–504 ошибки.
Первая мысль разработчиков: классическая N+1 при работе с БД через ORM (ошибки есть только при наличии 100+ наименований в заказе).
А оплата сама по себе может быть недоступна из-за ограничений фискальных накопителей — длина документа сильно ограничена, и чтобы уложиться в нее в драйверах и API часто устанавливают ограничение в 99 наименований для чека и транзакции в платежном сервисе).
Мы сразу заподозрили неладное: небольшой региональный магазин построен с попытками построить архитектуру, присущую большим сервисам и командам: здесь можно найти и несколько админок на разных стеках — для работы всего двух человек (и обе приходится использовать), и кластер k8s, и балансировщик нагрузки (traefik), стоящий перед единственным nginx, и аналог s3 для хранения штук 5 PDF и сотни jpeg'ов. Конечно, все это работает на единственном недорогом виртуальном сервере — даже не физическом — с уже давно неподдерживаемой ОС и никогда не обновлявшимися пакетами.
О документации ко всему безобразию, конечно, и говорить не приходится — ни единой строчки.
На днях к нам приходит запрос: клиенты не могут просматривать некоторые свои заказы в личном кабинете и не могут оплачивать их.
Начинаем разбираться. Небольшие заказы можно просмотреть и оплатить без каких-либо проблем. Но если в заказе более 100 позиций, сервер долго обрабатывает запрос на получение. данных заказа и возвращает 500–504 ошибки.
Первая мысль разработчиков: классическая N+1 при работе с БД через ORM (ошибки есть только при наличии 100+ наименований в заказе).
А оплата сама по себе может быть недоступна из-за ограничений фискальных накопителей — длина документа сильно ограничена, и чтобы уложиться в нее в драйверах и API часто устанавливают ограничение в 99 наименований для чека и транзакции в платежном сервисе).
Начали исследовать выборки из БД и ответы бекенда на разные запросы. И вот, что увидели (см. скриншоты).
Для каждого товара в заказе бекенд находил и возвращал не только данные товарной позиции, но полный список пользователей, которым понравился товар, все дерево категорий/разделов каталога, список пользователей, купивших товар, корзины, где товар присутствует, и многое-многое другое.
Конечно, выбрать из БД такой массив данных занимает немало времени. Да и объем данных был, мягко говоря, большим.
Мы убрали выборку лишних данных, стали возвращать только товарные позциии — ровно то, что требовалось показать в личном кабинете. И тут же все стало работать как часы.
Тем не менее, оплатить такой заказ все еще было нельзя. Здесь уже сработало то самое ограничение на 99 товаров в заказе.
Для каждого товара в заказе бекенд находил и возвращал не только данные товарной позиции, но полный список пользователей, которым понравился товар, все дерево категорий/разделов каталога, список пользователей, купивших товар, корзины, где товар присутствует, и многое-многое другое.
Конечно, выбрать из БД такой массив данных занимает немало времени. Да и объем данных был, мягко говоря, большим.
Мы убрали выборку лишних данных, стали возвращать только товарные позциии — ровно то, что требовалось показать в личном кабинете. И тут же все стало работать как часы.
Тем не менее, оплатить такой заказ все еще было нельзя. Здесь уже сработало то самое ограничение на 99 товаров в заказе.
🔥4😁3☃1