GitHub *

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

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

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

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

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

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

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

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

Mash?

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

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

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

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

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

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

Давным-давно…

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