GitHub *

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

^{Рыжик помогает мне ревьюить код. А когда ему что-то не нравится — тоже настоящий Терминатор}

«Code review Терминатор», — однажды назвал меня коллега после особо продуктивного ревью. С одной стороны, это тешило ЧСВ и было приятно. С другой — коллега действительно научился чему-то новому, и это позволило писать ему более качественный код. Так что win-win.

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

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


Ничего не предвещало. Смеркалось.

Tree of Dragons II by surrealistguitarist

Для тех, кто каждый день использует Git, но чувствует себя неуверенно, команда Mail.ru Cloud Solutions перевела статью фронтенд-разработчика Шейна Хадсона. Здесь вы найдете несколько трюков и советов, которые могут немного облегчить работу с Git, а также подборку статей и мануалов более продвинутого уровня.

Прежде чем фича попадет на прод, в наше время сложных оркестраторов и CI/CD предстоит пройти долгий путь от коммита до тестов и доставки. Раньше можно было кинуть новые файлы по FTP (так больше никто не делает, верно?), и процесс «деплоя» занимал секунды. Теперь же надо создать merge request и ждать немалое время, пока фича доберётся до пользователей.

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

Тикеты на GitHub бывают разные: запросы на реализацию каких-то возможностей, отчёты об ошибках, жалобы от клиентов, оповещения от систем безопасности, ретроспективы для команды и т. д. Здесь мы рассмотрим, как команда может использовать и обсуждать их.

Содержание:

• Что такое тикет?
• Публичный или приватный?
  
  • Для публичных тикетов
  • Для приватных тикетов
• Оценка
  
  • Оценка по приоритетности
  • Оценка по степени влияния
  • Оценка по величине ущерба
  • Оценка по размеру
  • Оценка по критерию MoSCoW
  • Оценка по частоте
  • Совокупная оценка
• Обсуждение оценок
• Шаблон тикета
• Запуск постмортемов
• Безобвинительные постмортемы

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


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

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

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

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

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

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

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

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

Я собрал список из десяти отличных репозиториев на 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 к этой ветке оставить свои замечания.

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

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

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

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

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

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

Привет!

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

Зачем?



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

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