На Хабре вышла статья под моим авторством, буду рад вашим визитам
https://habr.com/ru/companies/wildberries/articles/905238/

#habr #android

На днях попробовал сделать аналог стекломорфизма из iOS 26 для Android Compose.

Мои попытки вылились в небольшую библиотеку, которая добавляет настраиваемый стеклянный контейнер для вьюшек.

Подробнее можно посмотреть в репозитории https://github.com/Mortd3kay/liquid-glass-compose

Из интересного в разработке:
0. Compose не умеет вычитывать пиксели не из дочерних вьюх – пришлось идти на ухищрение и оборачивать всю конструкцию в контейнер.
1. Стекло хотелось сделать настраиваемым – референсы брал с этих проектов раз два три.
2. Настраиваемость стекла сильно ограничивает в использовании displacement-карт, поэтому решил преломлять цвет алгоритмически.
3. Моделировать реальную линзу неэффективно и не нужно, поэтому была разработана хитрая имитация – здесь очень помогал Cursor.
4. Отражение соседних элементов требовало написания RayMarching'а – как по мне, это дорого, поэтому для блика стекла просто берется цвет пикселей на небольшом расстоянии от границы.

Месяц назад я решил принять участие в контесте Telegram – нужно было переработать экран профиля, добавив кнопки и анимацию подарков, как это сделано на iOS.
Сегодня объявили результаты и я вошел в число тех, кто занял 2 место – очень приятно, учитывая, что это мой первый опыт в подобных соревнованиях. Не успел осилить размытие под кнопками и эффект прилипания аватарки при сворачивании, но все равно вышло неплохо. Даже порефачил немного код:)

Ниже представлен результат моей работы:

Недавно решил сделать свое первое расширение для браузера. На пробу взял простую идею – уведомлять пользователя, если он просматривает экстремистский контент или сайт (актуально в связи с последними поправками).

В качестве источника данных решил использовать официальный сайт Минюста РФ. Написал простенький парсер, который вытягивает все ссылки из материалов. Также добавил поиск по совпадению метаданных страницы с цитатами.

Алгоритм пока работает очень просто и часто может ругаться на простые запросы – для этого добавил возможность прятать такие запросы в белый список.

Расширение можно поставить через Chrome Web Store https://chromewebstore.google.com/detail/%D1%80%D0%B5%D0%B5%D1%81%D1%82%D1%80-%D1%8D%D0%BA%D1%81%D1%82%D1%80%D0%B5%D0%BC%D0%B8%D1%81%D1%82%D1%81%D0%BA%D0%B8%D1%85-%D0%BC%D0%B0%D1%82/hekgklmbcplgagdemhopbpfkecaphade?hl=en-US

По мотивам доклада с митапа подготовили новую статью на Хабре.
https://habr.com/ru/companies/wildberries/articles/939526/

#habr #android

Как ИИ может убить ваш проект (и что из этого можно вынести)

Когда пишешь пет-проект, хочется сфокусироваться на продукте, а не на инфраструктуре. Так и я решил отдать ИИ задачу сгенерировать docker-compose.yml. Ниже представлен небольшой кусок этого конфига:

redis:
  image: redis:7-alpine
  container_name: redis
  ports:
    - "6379:6379"  
  restart: unless-stopped
  networks:
    - app-network
  healthcheck:
    test: ["CMD", "redis-cli", "ping"]
    interval: 10s
    timeout: 5s
    retries: 3

На первый взгляд ничего такого – поднимаем контейнер с редисом на 6379 порту, делаем healthcheck по таймауту. Всё заработало с первого раза: контейнер поднялся, приложение общалось с Redis, я задеплоил это на прод-сервер и забыл.

Через пару месяцев захотел подключить админку к Redis… и обнаружил неприятную вещь: подключиться можно без пароля и даже без SSH. Redis был доступен напрямую из интернета на стандартном порту 6379.

Проверил логи – и увидел регулярные (раз в несколько дней) атаки:
- Создание REPLICAOF на внешний сервер,
- Попытки записать SSH-ключи через CONFIG SET dir и CONFIG SET dbfilename,
- Последующая очистка логов через FLUSHALL.

К счастью, Redis использовался только как очередь (Celery), данные не критичны, и утечки не произошло. Но это могло закончиться иначе.

Я также проверил основную БД (PostgreSQL) – у неё тоже был открыт порт, но там я вручную прописал нестандартное имя пользователя и сложный пароль. Даже так – в логах были попытки брутфорса под root, admin, test и т.п.

Кто это делал?
Не целевые хакеры – просто боты, сканирующие весь IPv4-пространство в поиске открытых Redis, MongoDB, PostgreSQL и т.д. Они работают 24/7. Если ваш сервис публично доступен – он уже в их прицеле.

Что делать?
- Не используйте ports в docker-compose, если сервис не должен быть доступен извне. Внутри сети Docker достаточно expose (или вообще ничего – по умолчанию контейнеры в одной сети видят друг друга).
- Всегда включайте аутентификацию: даже в Redis можно задать requirepass через переменную окружения или конфиг.
- Никогда не доверяйте «готовым» конфигам от ИИ без аудита – особенно в инфраструктуре.
- Если ваш проект доступен из интернета – считайте, что он атакуется сразу после деплоя.

Безопасность – не опция. Особенно когда ИИ делает всё «за вас».

#AI #Docker #Redis

Как не терять время при переключении веток?

Многие системы сборки предполагают кэширование результатов, чтобы ускорять последующие сборки. Но когда параллельно работаешь над несколькими задачами, этот кэш приходится пересобирать при каждой смене ветки.
Для решения этой проблемы можно сделать копии репозиториев, и в каждой работать над отдельной задачей. Вы можете подумать, что этот подход противоречит идее VCS, но сам Git предоставляет такой механизм – называется он Git Worktree.

Как работает:
Командой git add worktree ../feature-branch-project main вы создаете проект по соседству с вашим. Если не указывать название ветки, то она принимает название директории (feature-branch-project) и ответвляется от ветки, указанной в конце (main). Поработав с веткой, мы можем вызвать команду git worktree remove ../feature-branch-project для удаления копии.

Чем это лучше обычной инициализации репозитория в другой папке:
1. Все рабочие деревья находятся в одном пространстве – fetch актуализирует информацию везде, новые ветки видны всем, есть возможность сделать rebase по ветке, которая находится в другом дереве.
2. Не требуется заново настраивать конфиг гита, если он у вас кастомный для проекта.
3. Создание и удаление копии присходит одной командой из любого дерева.

Какие есть ограничения:
1. Нельзя в двух деревьях переключиться на одну ветку. Сделано для поддержания консистентности, достаточно просто отводить ветки и делать изменения в них.
2. Если в вашем проекте есть завязка на .git директорию (например, работа с хуками из .git/hooks), то эта функциональность может сломаться, потому что во всех деревьях .git – это ссылка на директорию в оригиналом проекте. Для обхода этой проблемы можно закомментировать ломающий функционал и скрыть изменение из индекса комадной git update-index --skip-worktree changed_file, тогда изменение не попадет в коммит, даже если сделаем git add -A.

#git #worktree