GitHub *

Катастрофа

Введение

С тех пор, как нейронные сети начали набирать популярность, большинство инженеров стали решать многие из задач ПО в области 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

Привет, Хабр! Наверное, у каждого из нас есть такой файлик, куда мы припрятываем что-то полезное и интересное для себя. Какие-то ссылки на статьи, книги, репозитории, мануалы. Это могут быть закладки в браузере или даже просто открытые вкладки, оставленные на потом. Со временем все это разбухает, ссылки перестают открываться, а большая часть материалов просто устаревает.

А что если поделиться этой годнотой с сообществом и выложить этот файлик на гитхаб? Тогда ваши труды могут быть полезны еще кому-нибудь, а поддерживать актуальность можно совместно, принимая обновления от желающих через старые добрые PR'ы. Именно для этого предназначен проект Awesome lists. Он входит в ТОП-10 репозиториев гитхаба, обладает 138К звезд, и ссылка на ваши труды может оказаться прямо в его корневом README, что привлечет огромную аудиторию к вашему творчеству. Правда, для этого придется немного постараться. О моем опыте таких стараний хочу поделиться с вами.

Меня зовут Максим Грамин. В КРОК занимаюсь Java-разработкой и исследованиями в области БД. В этом посте я расскажу, что такое Awesome Lists и как сделать свой настоящий официальный awesome-репо.

У нас 350+ человек и 400+ репозиториев на Github-е. В каждой репе может быть несколько админов, и они творят, что считают нужным, — естественно, случается так, что один человек не знает, что делает другой. Когда нам в инфре надоело смотреть на мучения других и добавлять/удалять людей вручную, мы решили, что перейдем централизованное управление, Infrastructure as Code.

И в качестве платформы выбрали Terraform.

«У меня есть кубики с буквами О, П, А…»

Смотрите сами: вот проект, вот история коммитов.

Список контрибьюторов с главной страницы репозитория:

Ссылки на аватарках ведут на странички профилей реальных людей.

Всё на месте. Кроме плашечки "Verified" как здесь:

Знатоки Git и GPG, не торопитесь проматывать ленту: эта статья не про необходимость подписывать свои коммиты. Она про неявные допущения, которые мы делаем, пользуясь "интуитивно-понятными" монстрами GitHub и GitLab и доверяя им контроль доступа к нашим репозиториям.

• какое общее состояние рынка фотостудий: растет, стабильный или падает?
• какова сезонность рынка?
• сколько они смогут заработать?
• где лучше открывать залы?
• какую сумму вкладывать в проект?
• на сколько сильная конкуренция на рынке?

• создание простой SQLite базы данных;
• запись информации с помощь Python;
• чтение данных и перевод в формат DataFrame;
• обновление парсинга с учетом данных БД.

Как запустить свой DS/ML/AI/Tech блог с минимумом сложностей связанных с хостингом и деплойем этого блога.

Привет, хабр! Продолжаю делиться полезными подборками. Я уже публиковал посты с Github репозиторими (Часть 1 и Часть 2), а также подборку из 10 книг для разработчиков. Решил, не останавливаться:) Кому интересно — добро пожаловать под кат.