GitHub *

GitHub объявил, что долгожданная темная тема, наконец, готова, ознаменовав анонс характерным крутейшим (но не без ироничным) видео, которое лучше сто раз увидеть, чем сто раз услышать.

Всем привет! Как и многие, я люблю поковыряться с каким-либо хобби-проектом, — и удовольствие получаешь и показать при случае можно, а если он способен ещё и пользу кому-то принести, то это вдвойне приятно.

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

Сегодня поговорим об секьюрити в web (да, наверное, и не только) приложениях. Прежде чем описывать подходы и фреймворки расскажу небольшую предысторию.

Предыстория

За много лет работы в IT приходилось сталкиваться с проектами в самых разных сферах. У каждого проекта были свои требования к безопасности. Если в части аутентификации все было более-менее одинаково с точки зрения требований, то способы реализации механизма авторизации получались довольно разными от проекта к проекту. Каждый раз авторизацию приходилось писать практически с нуля под конкретные цели проекта, разрабатывать архитектурное решение, потом дорабатывать с изменением требований, тестировать, и т.д. — все это обычный процесс, которого не избежать в разработке. С каждой реализацией очередного такого архитектурного подхода все больше складывалось ощущение, что можно придумать какой-то общий подход, который будет покрывать основные цели авторизации и который можно будет использовать повторно в других приложениях. В данной статье будет рассмотрен обобщенный архитектурный подход к авторизации на примере разработанного фреймворка.

Подходы к созданию фреймворка

Как обычно, прежде чем разрабатывать что-то новое нужно определиться с тем, какие проблемы будут решаться, чем фреймворк будет удобен и полезен и, возможно, уже есть готовое решение (об этом поговорим после).

Всем известны два стиля написания кода — императивный и декларативный. Императивный стиль описывает то, как получить результат, декларативный — что требуется получить в результате.

Внедряем оплату BTC куда угодно (Python)

- генерация кошелька на основе seed фразы

- проверка баланса и транзакций

- отправка BTC на другие кошельки

- создаем телеграм бота для выполнения операций с BTC

- исходники бота (github)

В статье детально, с приведением исходного кода, описывается работа, проведенная по переносу и запуску с SD-карты программной прошивки с ОС Андроид для устройств на процессоре Amlogic S912.

Катастрофа

Введение

С тех пор, как нейронные сети начали набирать популярность, большинство инженеров стали решать многие из задач ПО в области Public Safety методами deep learning. Несмотря на то что у нейросетей нет конкурентов в вопросах обнаружения (detection) и распознавания (identification) объектов, всё же они не могут похвастаться способностью анализировать и рассуждать, а лишь создают закономерности, которые не всегда можно понять или интерпретировать.

Мы придерживаемся такого мнения: для трекинга нескольких объектов более эффективными будут интерпретируемые и предсказуемые подходы, такие как, например, метод вероятностной ассоциации данных (probabilistic data association approach).

О точности трекинга и преимуществах выбранного нами подхода наглядно (подробнее в посте):

Сравнение популярного трекера Re3 (слева) и нашего компонента AcurusTrack (справа)

Дисклеймер: этот пост не претендует на почетный статус “средства от всех бед в Public Safety Software”. Мы также не заявляем, что изобрели что-либо новое. Мы лишь приводим примеры некоторых популярных подходов к решению задачи мультитрекинга, анализируем их и предлагаем собственную практическую реализацию.

Целиком проект лежит на GitHub.

В статье ранее (на португальском) я рассказал, как создать полнофункциональный бэкенд GraphQL, используя только образ Docker и файл конфигурации. Все это можно найти на сайте Azure. А сейчас давайте поговорим о том, как автоматизировать развертывания, созданные для нашего хостинга, и обновления нашей серверной части!

Целью всего этого проекта является создание серверной части для моего будущего архива содержимого, который будет размещен на моем сайте. Однако всякий раз, когда я обновляю серверную часть или меняю схему GraphQL, мне придется выполнять полное развертывание службы снова.

Вместо этого мне бы хотелось, чтобы с каждым push в главной ветке генерировалась новая версия файла и обновление отправлялось на сайт Azure. Однако я не хочу использовать для этого другие инструменты. Мне бы хотелось, чтобы весь стек был максимально простым, так как мы пользуемся только GitHub и Azure. Нет ничего проще, чем продолжать пользоваться GitHub для автоматизации, верно?

Вот почему мы будем использовать GitHub Actions