GitHub *

1. Цель

Целью является составить полный список инструментов, которые облегчают писать конфигурацию/код Ansible в трёх популярных редакторах: VS Code, Atom, JetBrains PyCharm (в данном случае проще эту IDE рассмотреть как редактор). Под инструментами я имею ввиду: линтеры, форматтеры (спик инглиш!), подсветка синтаксиса, автодополнение. Будет рассмотрена текущая активность в разработке инструментариев и предложено моё субъективно-оценочное суждение что должно быть в "идеальном" инструменте. Я пользовался всего одним инструментом из рассмотренных, поэтому в обзоре не будет моей субъективной оценки со стороны пользователя, только то что смог найти в общем доступе.

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

Для меня эта идея стала основой многих собственных разработок, начиная с программ для решения Судоку, подсчёта времени нахождения за компьютером, имитации работы пользователя ПК с помощью самописных скриптов (всё это ещё в давние времена), и заканчивая более сложными проектами.

И вот, среди прочих родилась простая идея: "А почему бы не автоматизировать отслеживание новых выпусков ИТ-подкастов с помощью Telegram-бота и GitHub Actions? Чтобы просто подписаться на telegram-канал и получать актуальные выпуски подкастов по мере их выхода.

Конечно, можно скачать специализированные приложения, типа "Poket Casts", либо подписаться на RSS, но лично для меня использование Telegram-канала является самым удобным, простым и привычным.

Так был создан telegram-канал @awesome_russian_podcasts, куда в автоматическом режиме публикуются новые выпуски множества ИТ-подкастов, собранных в моём репозитории. Собственно, о процессе создания этого канала (его техническую часть) я и хочу рассказать далее.

@octokit/rest изначально не является оригинальной разработкой GitHub, и представляет собой адаптацию github — самого популярного пакета 2017 года от пользователя @bkeepers. В этом посте будем говорить про @octokit/rest — теперь официальный JavaScript SDK для GitHub REST API.

Представляем вам перевод статьи Simon Holdorf, опубликованной на сайте medium.com. В ней вы найдете ссылки на полезные репозитории, с помощью которых можно прокачать навык разработки ПО.


Фото с ресурса Unsplash. Автор: Vishnu R Nair

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

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

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

Некачественные снимки напрямую снижают прибыль.

• Как приложению распознавать нечеткие фотографии на уровне алгоритма?
• Как измерить четкость RGB-изображения?

Публикуем перевод статьи, которую мы нашли на hackernoon.com. Ее автор, Thiago Miranda, пишет о том, как сделать работу с Git более удобной и эффективной.

И снова здравствуйте, дорогие друзья. Мы опять готовимся окунуться в прекрасный мир OSINT.



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

Часть 1 — Что такое Maltego и зачем оно нужно

Часть 2 — Интерфейс и базовое устройство

Часть 3 — Maltego и OSINT в Facebook

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

Из общения с разработчиками настольных приложений мы узнали, что многие хотят узнать, как быстро настраивать рабочие процессы непрерывной интеграции и непрерывного развертывания (CI/CD) для WPF и Windows Forms, чтобы пользоваться многими преимуществами пайплайнов CI/CD, такими как:

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

Поэтому мы создали пример приложения (GitHub) для демонстрации возможностей DevOps в ваших приложениях, с использованием недавно выпущенного GitHub Actions.

Кроме огромных репозиториев с источниками для подготовки к интервью, здесь много чего интересного

Я собрал список из десяти отличных репозиториев на Github, которые помогут вам существенно расширить свои знания.

А я его перевел, т.к. показалось, что пост многим будет интересен. Перевод очень вольный: я опустил нерелевантные промо-ссылки и гипер эмоциональные похвалы автора оригинала, чтобы оставить только суть. Еще, обновил цифры, чтобы информация была более актуальной к моменту публикации этого перевода. Итак, перейдем к списку.

В мире информационной безопасности часто задаются вопросом об исследовании открытых источников на получение личной информации — будь то защищающая сторона (например, для контроля периметра, выявления открытых уязвимостей) или пентестеры (поиск точки входа, аудит периметра и т. д.). Рассмотрим один из таких источников — hunter.io, — работу с которым мы оптимизировали, написав под него новую библиотеку. Подробности и ссылка на GitHub под катом.

REPL (read-eval-print loop) бесполезен в Python, даже если это волшебный IPython. Сегодня я предложу одно из возможных решений этой проблемы. В первую очередь доклад и мое расширение TheREPL будет полезны тем, кого интересует более быстрая и эффективная разработка, а также тем, кто пишет stateful-системы.


— Меня зовут Александр, я в Яндексе работаю программистом. Пишем мы в моей команде на Python, на Go пока не перешли. Но в свободное от работы время я, как ни странно, тоже программирую и делаю это на очень динамическом языке — Common Lisp. Он, пожалуй, даже более динамический, чем Python. Его особенность заключается в том, что сам процесс разработки устроен несколько иначе. Он более интерактивный и итеративный, потому что в REPL на Lisp вы можете делать всё: создавать новые и удалять старые модули, добавлять методы, классы и удалять их, переопределять классы и т. д.

На этой неделе состоялся релиз новой версии нашего плагина для Grafana, предназначенного для мониторинга kubernetes-приложений DevOpsProdigy KubeGraf v1.3.0.

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

• интеграция с k8s-api для построения карты ваших приложений, сгруппированных по неймспейсам / нодам-кластера + привязка к конкретным pod’ам/сервисам;
• сводная страница со всеми ошибками / предупреждениями о работе нод и приложений кластера;
• возможность инсталляции плагина с облачными k8s-провайдерами через авторизацию с помощью bearer-tokena.

Что нового в версии 1.3.0:

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

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

Как это сделать средствами самого git: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.

В общем суть метода уже изложена, ниже лишь немного подробностей.

В данной статье я хочу подробно рассмотреть процесс публикации с нуля Java артефакта через Github Actions в Sonatype Maven Central Repository используя сборщик Gradle.

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

Наша команда разработки инструментов Visual Studio для Unity видит свою миссию в повышении производительности разработчиков Unity. В Visual Studio 2019 коллеги представили инструменты Unity, набор диагностик и исправлений кода, специфичный для Unity. Сегодня мы рады анонсировать, что Unity Analyzers стали Open Source. Подробности под катом.

Предисловие переводчика

Пару месяцев назад на Гитхабе случайно наткнулся на ссылку «Open source guides» и не мог оторваться. Где-то за неделю я внимательно прочитал все 10 разделов. Конечно, я и раньше знал про open source: читал разные статьи (например, «Понять Open Source»), использовал такие проекты в работе, обращался с вопросами к сообществам, сообщал о багах, рыскал в issues и, даже делал неуклюжие попытки что-то улучшать, хотя бы документацию. И само собой, сердцем я был с этими ребятами, которые делятся софтом и знаниями по его использованию. Тем не менее, понятие об open source у меня было скорее смутное и обрывочное. А эта статья добавила ясности.

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

Вне зависимости от вашего отношения к open source, думаю, вы найдёте в этой серии из 10 статей много интересных идей и фактов: организационных, психологических, юридических, этических и технических.

Я дал прочитать этот текст нескольким непрограммистам, они сказали, что всё поняли. А в заголовке статьи я намеренно поставил «исходник» без «кода», потому что данная тема актуальна не только для программистов, а почти для любой интеллектуальной деятельности в формате открытого проекта.

Привет!

С появлением Github Actions проявил инициативу и интегрировал простенький (но вполне эффективный) CI/CD в наш небольшой, но уже как 2 года живой проект Flowwow.

Зачем?



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

Как минимизировать факапы на продакшене, расскажу ниже.

Автор и мейнтейнер нескольких опенсорсных проектов, Эндрю Галлант пытается снять напряжённость, которая в последнее время накопилась в части опенсорсного сообщества. Крики души «Каково быть мейнтейнером свободного ПО», «Неблагодарный opensource» и другие жалобы мейнтейнеров породили дискуссию об агрессивности, грубости, неблагодарности, эмоциональном выгорании и тяжести бескорыстной поддержки проектов. Пост опубликован 19 января 2020 года, — прим. пер.

Хочу отойти от традиции говорить почти строго на технические темы — и поделюсь частью личных отношений со свободным и открытым программным обеспечением (FOSS). Хотя все люди разные, надеюсь, что обмен мнениями поможет наладить взаимопонимание, сопереживание и доверие в нашем сообществе.

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

Это ни в коем случае не призыв о помощи. Речь о понимании. Я не призываю изменить экономику FOSS или обсуждать моё психическое здоровье. Я не говорю о привлечении дополнительных мейнтейнеров. Просто хочу поделиться своей историей и попытаться увеличить эмпатию в сообществе FOSS.

Целевая аудитория: все, кто занимается опенсорсом.

Хочу сделать автономного дрона, который бы сам мог найти дорогу к цели и обратно, при этом обойти все препятствия ни кого не задев. Решил начать с нейросети и вебки. Так и получился этот проект

Системы контроля версий уже давно стали повседневным инструментом разработчика. В больших монорепозиториях требования к ним оказываются весьма специфическими. Из-за этого компании либо адаптируют существующие решения, как это делает Facebook с Mercurial и Microsoft с Git, либо разрабатывают собственные системы: Piper и CitC в Google и Arc VCS в Яндексе.

В докладе разработчик Владимир Кихтенко kikht рассказывает, зачем Яндексу понадобилась собственная система контроля версий и как она работает. Рассмотрим её со стороны рядового разработчика: как получить доступ к исходному коду, отвести ветку для разработки и интегрировать изменения в общую кодовую базу. Заглянем под капот — узнаем про внутреннее представление данных и их отображение в виртуальной файловой системе с рабочей копией. Обсудим трудности при реализации функций VCS в виртуальной файловой системе и при ленивой загрузке данных. Поговорим о том, как обеспечивать надежность серверной инфраструктуры репозитория. В конце можно посмотреть неофициальную запись доклада.

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