GitHub *

Введение

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

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

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

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

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

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

GitHub Actions — инструмент для автоматизации рутинных действий с репозиторием и подспорье при создании CI/CD для вашего проекта.

Пользователи GitHub’а ежемесячно получают по 2000 минут, чтобы выполнять GitHub Actions на инфраструктуре сервиса. Применим это бесплатное время с пользой.

Как разработчик Flutter-приложений, даю инструкцию: как c помощью GitHub Actions на каждый pull request запускать тесты и анализатор кода, билдить артефакт и деплоить его для тестирования в Firebase.

GitHub — это платформа, дающая программистам отличные инструменты для организации работы над кодом. Но в GitHub-репозиториях, помимо кода, можно найти массу ценных учебных материалов. Я, например, занимаюсь разработкой ПО и постоянно ищу репозитории, которые могут чем-то мне пригодиться. Вот 10 моих любимых GitHub-проектов.

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

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

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

Disclaimer: Эта история произошла несколько лет назад. Но кажется, что она и до сих пор не утратила актуальности.

… Мы разрабатывали Gardenscapes. В нём всё ещё оставались следы старого Gardenscapes под Windows. Он даже был не Match-3, а Hidden Object. И никто даже и представить не мог высот, которых достигнет игра.

И вот в один прекрасный день…

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

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

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

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

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

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

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

---

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

В этой статье мы настроим пайплайн в GitHub для автоматической сборки pdf-файлов и последующей выкладки в Releases. Также поднимаем небольшой сайт-визитку с ссылкой на самые свежие сборки.

Материал будет полезен новичкам и тем, кто хочет быстро поднять CI/CD для latex встренными средствами GitHub.

Вашему вниманию простой C++ template аллокатора с потокобезопасным циклическим буфером.

Вся реализация в одном заголовочном .h файле: [fast_mem_pool.h]

Фишки, чем этот аллокатор лучше сотни подобных — под катом.

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

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

Группа молодых предпринимателей рассматривала вариант открытия своей фотостудии в Москве. Им необходимо было узнать:

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

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

Год назад моя команда выросла: усложнялась бизнес-логика, по сути, мы делились на три подкоманды — в каждой были как новички, так и те, кто работал в компании годами. Подкоманды сфокусировались на своих направлениях, и хотя все пилили биллинг, перестал работать принцип общей зоны ответственности. Да и практики, которые работали у «старичков», не всегда подходили новому коллективу.



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

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



Изучение исходников в репозитории позволяет оценить уровень безопасности приложений. Но если никто не смотрит на код, проблемы будут только расти. К счастью, у GitHub есть свои специалисты по безопасности, которые недавно обнаружили трояна в нескольких репозиториях Git. Его почему-то не заметили сами владельцы этих репозиториев. Хотя мы не можем диктовать другим людям, как управлять своими собственными хранилищами, мы можем учиться на их ошибках. В этой статье мы рассмотрим полезные приёмы работы с репозиториями.

http://mash-project.org
https://github.com/RoPi0n/mash-lang

Mash?

Это императивный язык программирования с динамической типизацией, сборкой мусора, ООП и поддержкой многопоточности.



Интересно? Тогда под кат!

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



Редактор Visual Studio Code, также известный как VS Code работает на Linux, Windows и macOS. Он занимает промежуточное положение между простым текстовым редактором исходного кода и интегрированной средой разработки (IDE), которая управляет всей вашей кодовой базой. Функциональность VS Code можно расширить с помощью плагинов. Это надёжный редактор кода, который может достойно побороться с проприетарными конкурентами.

Изначально VS Code был создан как open source продукт. Однако его готовые сборки распространяются под проприетарной лицензией Microsoft. Но не всё так плохо.

Команда DevOps инженеров из GitHub поделились своим универсальным решением для проверки качества кода. С ним можно настроить линтер для 17 языков всего в 11 строк:

name: Lint Code Base
on:
  push:
    branches-ignore:
      - 'master'
jobs:
  linter:
    runs-on: ubuntu-latest
    steps:
        - uses: actions/checkout@v2
        - uses: docker://github/super-linter:v2.1.0

Код выше является YAML конфигурацией для GitHub Actions (бесплатный CI/CD от GitHub) и далее мы разберемся с его содержимым и принципом работы.

За последние 3 года я рассмотрел более 1000 pull (merge) request’ов. За это время я многому научился — в основном тому, как не проверять код, как сделать процесс менее болезненным, что делает код хорошего качества и так далее.

Pull request должен делать только одну вещь

Это самая важная вещь, на которую стоит обратить внимание.

Делая code review, вы должны держать в голове много вещей. «Что за этим стоит?», «Как это согласуется с остальной частью кода?» и «Будет ли это хорошо работать?» Вот лишь некоторые из вопросов, на которые нужно ответить. Таким образом, когда у вас есть pull request, который пытается решить одну проблему, на некоторые из этих вопросов легче ответить.

Другим важным аспектом является размер pull request’а. Большие запросы требуют экспоненциально больше времени для рассмотрения. И когда я узнаю, что мне нужно потратить более 15 минут на запрос, вам придется подождать до пары часов.

Мне частенько приходится строить пайплайн для сборки проектов на Java. Иногда это опенсорс, иногда нет. Недавно я решил попробовать перенести часть своих репозиториев с Travis-CI и TeamCity на GitHub Actions, и вот что из этого получилось.

Субъективная попытка оценить мир open source, с позиции рядового контрибьютора, спустя два года ежедневного участия. Не претендую на истину, не напрягаю советами, только структурированные наблюдения. Возможно, эта статья поможет лично вам понять — быть или не быть open source contributor'ом.

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



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

Сегодня SIEM – это главный помощник при анализе событий ИБ: трудно представить, сколько бы потребовалось времени, чтобы вручную просматривать логи с множества источников. При этом прекращение сбора данных с источника – достаточно распространенная проблема SIEM. И далеко не всегда можно решить ее встроенными средствами – а ведь потеря событий в неподходящий момент может быть равнозначна катастрофе. Чтобы ценная информация не пропадала, мы реализовали внешнее решение для контроля работы MaxPatrol SIEM: разработали шаблон для системы мониторинга Zabbix и скрипт на питоне, которым готовы с вами поделиться. Подробности и ссылка на GitHub под катом.