Как создать портфолио на github

Инструкция по оформлению профиля на GitHub

Правильно оформленный профиль на GitHub очень важен для поиска работы: для интервьюера это единственная возможность увидеть ваш код и оценить вас в деле. Мы попросили Георгия Бабаяна, основателя и CEO школы программирования Elbrus Bootcamp, рассказать, как оформить профиль, чтобы показать себя с лучшей стороны.

Георгий Бабаян

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

10 правил оформления профиля на GitHub

Хорошая фотография

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

Имя и фамилия

Обязательно напишите свои имя и фамилию, а не только никнейм, чтобы профиль легко было сопоставить с резюме.

Адрес электронной почты

Убедитесь, что email для связи с вами доступен всем. Для этого зайдите в настройки профиля: там есть специальная кнопка «сделать публичным». Избегайте адресов в духе sexybaby@mail.ru — используйте ящик в доменной зоне.com с понятным неймингом. Не делайте публичным email, который привязан к вашему аккаунту GitHub: это повышает вероятность взлома аккаунта и демонстрирует слабое владение правилами безопасности в интернете.

Биография

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

Ссылка на соцсеть

Добавьте ссылку на профессиональную соцсеть, которую вы ведёте наиболее активно и подробно.

Репозитории

Прикрепляйте только те репозитории, которые вы хотите показать будущему работодателю. Удалите «детские» проекты! Никому не интересно смотреть на «Hello, world!».
Если репозитория ещё нет, сделайте проект сами: создайте чат-бот или простое приложение о погоде — что-то, что поможет увидеть вас в деле.

Забота о читателе

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

README

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

Команда

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

Визуализация

Идеально, если у вас получится прикрепить к проекту гифку или видео, которое показывает, как всё работает.

7 ловушек GitHub — ошибки в оформлении, которые часто делают программисты

Неочевидная команда запуска

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

Мусор в коде

Уберите отовсюду консоль-логи, принты, выводы ошибок и глупые комментарии. Как-то раз я собеседовал на должность преподавателя приятного кандидата и уже собирался предложить ему работу. А затем обнаружил в его коде функцию, которая не делала ничего. Рядом с ней красовался комментарий: «Нужно удалить».

Ошибки в коде

Обязательно прогоните код через линтер: он проверит код на ошибки, укажет на баги и найдёт подозрительные конструкции.

Ключи и пароли в коде

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

Непонятные коммиты

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

Низкая активность

Очень важно постоянно держать зелёным ваш график активности («contributions»). Чтобы не создавалось впечатления, что вы не работаете, создайте специальную папку «Мои решённые алгоритмы». Добавляйте в неё всю релевантную активность: «алгоритм решения судоку», «алгоритм сортировки», чтобы было видно, что вы постоянно что-то делаете.

Плохой стиль

Соблюдайте стайлгайд своего языка — PEP8 для Python, Airbnb Style Guide для JavaScript, Airbnb Ruby Styleguide для Ruby и так далее. Так вы продемонстрируете заботу о комфорте коллег и уважение к принятым в сообществе нормам.

8 steps to publishing your portfolio on GitHub

A portfolio is a way in which you showcase your work samples for the skills that are stated by your Curriculum Vitae (CV). Having it online is an added advantage since anyone from all over the world is able to see it by just clicking on your portfolio’s link.

GitHub is a web-based platform for version control using git. It is also where users can collaborate on or adopt open-source projects, fork code, share ideas and more. On the other hand, Git is a distributed open-source version control system that was created by Linus Torvalds— the same person who created Linux. You can consider GitHub as a website while Git is a tool that keeps track of your files and modifications to those files in a repository or “repo” that are being hosted by the website. It is easier and free to set-up a GitHub account and host your portfolio using GitHub pages.

Requirements to host your portfolio using GitHub

Have aGitHubaccount.
Have knowledge on how to useGit and GitHub.
Understand howGitHub-pageswork- Free hosting as well though this is not mandatory.
A website theme- Bootstrap theme or an HTML/CSS template but NOT a WordPress theme. Some of the recommended sources for the themes are listed below.

The 8 steps

5. Login to your GitHub account or create one if you don’t have any.

Create a new repository named username.github.io. For instance, if your GitHub username is brianmwevi, then your repository name would be brianmwevi.github.ioand GitHub pages will automatically take this to be your homepage. Add a description if any and click on ‘Create repository’.
Navigate to Start Bootstrap,Bootstrap Zero,Luis Zuno’s blog,Themezy,Bootstrapmade or any other place where you can download a quick portfolio template. Uncompress your download if compressed. I picked a pink theme from Themezy and downloaded it to my local machine.

(Please be aware of the license before downloading- some people release their work under an open/permissive license whereas others impose copyright restrictions, and you’re breaking the law if you violate copyright).

Create a directory/folder where you want to manage your site. I created mine in Documents/myWork/projects/Portfolio.
After doing so, launch your terminal/command prompt and clone your remote/online repository to your local machine (in the directory that you created) by running the following command;

NB: Remember to replace the URL with your own.

6. Copy the contents of your downloaded template into the cloned repository directory. Make sure the index.html file is at the root of this directory.

7. Change directory (cd) into the cloned repository and run the following commands respectively pressing enter after each

Enter the username and password when prompted after running the last command.

8. Navigate to http://brianmwevi.github.io (http://username.github.io) to see your newly created online portfolio.

Things to note

If you are deploying to GitHub pages for the first time, you may need to wait for 10–15 minutes before you see the actual site.
You can also set up a custom domain if you want to. Say: http://brianmwevi.com that will be redirected to your GitHub hosted page.
Whenever you would like to make changes to your created portfolio repository, make them locally and push the modifications to your remote repository using the commands in step 7. DO NOT make the changes directly to the pages.
You can also make your own Blog on GitHub using Jekyll themes.

Thanks for reading! You can check out my simple GitHub portfolio that I have created and learn something from it. Don’t forget to leave a comment or pose a question if any.

Как оформить профиль на GitHub так, чтобы он работал при поиске работы

Алексей Руденко, Director of Data Management в Ring Ukraine, написал статью о том, как начинающим разработчикам оформить профиль на GitHub так, чтобы он стал дополнительным преимуществом на собеседовании. Статья была опубликована на сайте DOU.UA. Представляем ее вашему вниманию.

Photo by Caleb White on Unsplash

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

Я уже более 15 лет управляю процессами создания продуктов — от гипотез до устойчивых продаж. Последние два года вместе с fellow kottans помогаю новичкам и свитчерам приобретать новые технические скиллы в разработке, развивать soft skills и находить первую работу в IT. Часто вижу у людей проблемы с презентацией своих навыков и личных проектов, в частности профиля и репозиториев на GitHub, поэтому и решил написать этот материал.

Сразу договоримся о контексте: речь будет идти о настройке профиля на GitHub для поиска работы.

Нужно ли это

Чаще всего от кандидата на позицию разработчика ожидают определённого уровня технических знаний. Новичкам особенно тяжело: практики мало, опыта прохождения технических интервью тоже не хватает или совсем нет. А ещё прескрининг… Код кандидата, написанный до интервью, может стать конкурентным преимуществом. Тестовые задания дают не только для того, чтобы проверить умение писать алгоритмы и оперировать структурами данных, но и чтобы увидеть подходы к решению задачи, структуру проекта и код. Любой код, доступный на этапе прескрининга, может стать предметом изучения интервьюеров ещё до первой встречи. И кто знает, возможно, вам дадут меньше тестовых заданий или вовсе обойдутся без них. А тесты — это же всегда стресс, сказывающийся на качестве работы.

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

Существуют различные взгляды на открытые портфолио проектов на облачных VCS (GitHub, GitLab и подобных). Многие опытные разработчики считают, что на профиль никто не смотрит. Для некоторых тим- и техлидов увидеть code style и способ организации кода в проекте (особенно в отношении кандидата-джуна) лучше, чем услышать 1000 слов на собеседовании. Правильное оформление профиля и двух-трёх наиболее показательных репозиториев на GitHub поможет обойти конкурентов. А когда по итогам цикла собеседований остаётся несколько равноценных кандидатов, то каждый бит информации может оказаться решающим — в том числе и проекты на GitHub.

Во всяком случае, если уж и указывать линк на GitHub-профиль в резюме, то точно есть смысл помочь ревьюеру увидеть самое главное.

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

Если профиль пустой, возникает закономерный вопрос: зачем в резюме добавлена ссылка на GitHub-профиль и почему в списке проектов — пусто? Ответ «Ну, если надо, то добавлю» — плохой.

Начнём с проектов.

Что показать, если показать нечего

Никто не ожидает увидеть уникальный проект на 100500 строк кода. Оценивать, скорее всего, будут уровень владения шаблонами проектирования, стиль кода, способность написать минимальную документацию, навыки работы с Git. Почему это всё важно? Потому что это о коммуникации. Это то, чего будут ожидать от сотрудника, помимо написания собственно кода. Код пишется в первую очередь для других людей.

Разумеется, могут оценить и уровень владения технологиями. Одно дело — прочитать в резюме «CSS3 — средний» или услышать ответ на вопрос «А что ты умеешь в JavaScript?». И совершенно другое — увидеть в репозитории хорошо читаемый код, отражающий действительные технические навыки.

Оговорка для педантов: ясно, что обмануть можно и там, и там. Но в этой статье речь не об этом классе проблем.

Выберите два-три проекта, которые наилучшим образом отражают ваши навыки. Учебные тоже годятся (быстро допили незаконченные). Или добавьте одну-две простых игры типа крестики-нолики, Frogger или Memory Game. Все новички делают что-нибудь такое, но не все завершают и показывают. Не ищите оригинальности — это всё ради демонстрации навыков и умений. Демо не обязательно должны быть сложными, с анимациями, встроенным видео и миллионом визуальных эффектов. Достаточно одной фишки.

Вот отличный пример работы студентки курса по фронтенду, а теперь разработчицы в MacPaw Mary Fedirko — погодное радио (нажми кнопку ON). В этом проекте она продемонстрировала творческий подход не только к написанию «очередного JS-фреймворка», но и к дизайну и внешнему представлению в целом. Нестандартный вид учебного проекта — это и дополнительная мотивация в процессе выполнения (делать подобные интерфейсы в разы интереснее), и повышение вероятности того, что на такой проект работодатель обратит внимание.

Было бы здорово, если бы кто-то сделал ревью вашего кода.

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

Ещё один источник проектов — хакатоны. Онлайн, оффлайн, локальные/международные — выбирайте на свой вкус. Их ежемесячно проводятся десятки. Кроме того, указание хакатонов и митапов в резюме — ясный индикатор заинтересованности в профессии.

Еще один совет: лучше учебные репы, чем ноль реп. При прочих равных условиях кандидат с даже «примитивными» проектами выигрывает у кандидата с отсутствующими общедоступными следами деятельности. Репозитории можно удалять, архивировать и сделать приватными — так профиль со временем будет становиться всё более профессиональным.

Оформляем репозиторий

Цель оформления репозитория — показать товар «лицом». В этом контексте проигрывают те, кто оформляет проект в стиле «сами разберитесь, как моё приложение запустить, чтобы увидеть, как оно работает». Потому что это всё может быть очевидно для автора, но не для стороннего наблюдателя.

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

Краткое описание и ссылка на публикацию

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

Начать просто — нажмите кнопку Edit.

В вебе выглядит так:

Источник: kottans stats by Igor Kurkov

Из Description, кстати, формируется содержание тега <title> страницы проекта, if you know what I mean.

Документация

Чаще всего README.md содержит одну только строку: # project-name.

Что должно быть в README.md:

О чём проект? Например: «A movies database web application», «Rick and Morty universe REST server».
Зачем этот проект? Например: «I mastered CSS animations, CSS Grid, CSS Flexbox» (пункты, разумеется, оформить отдельными буллет-поинтами).
Ссылка на демо (да-да, ещё раз повторить то, что уже есть в описании — overcommunication не грех).
Инструкции по сборке и запуску проекта. Это вот всё git clone … , yarn build … и прочее — как во взрослых проектах.
Структура проекта, архитектура приложения, API — это тоже показывает навыки, необходимые разработчику.

Пишите всё это в синтаксисе markdown. Так мы демонстрируем владение ещё одним полезным навыком.

Цель этого не только дать читателю хорошее представление о проекте, но ещё показать отношение к документированию (не любить писать документацию можно будет потом) и базовые навыки подготовки документации. Смотрите, например, учебный проект с использованием The Movie Database API.

Источник: Movie Database by Vlad Vorobiov

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

GitHub даже подскажет, по какому адресу теперь можно обнаружить опубликованный сайт. Перенесите эту информацию в описание проекта.

Вот так README.md может выглядеть, когда опубликован:

Источник: Git course. Проект на GitHub

Продвинутые техники

Скриншоты, скринкасты

Если у приложения есть человеческий интерфейс, скриншоты в документации добавят очков.

А скринкаст в виде гифки сделает демо ещё более наглядным. Пример: описание задачи в курсе по фронтенду. Гифку лучше захостить за пределами GitHub, допустим, на imgur.

Чем сделать такую гифку? Например, oCam for Windows. Можно записать скринкаст с помощью QuickTime для Mac или встроенными средствами Windows 10 (Win+G) и затем сконвертировать с помощью MOV to GIF или MP4 to GIF.

Для записи работы в терминале хорошо подходит asciinema.

Topics

На будущее: topics помогают проекту появиться в поисковых запросах. Какие ключевые слова вписывать? Начните с используемых в проекте технологий: JavaScript, ReactJS, Python, Java, C#, Laravel, PHP, REST, MongoDB, Node, PostgreSQL, SPA, web app, AMP, CSS, HTML… Добавьте два-три ключевых слова о самом проекте: game, casual game, database, movies, weather, demo, educational, tutorial… GitHub ещё что-нибудь подскажет из своего списка.

Источник: React patterns, demo by Vitalii Ovcharenko

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

Промежуточный summary

На хорошо оформленный репозиторий можно дать прямую ссылку в резюме. Указывайте ее прямо в разделе Skills или Education — где релевантно. Это должна быть ссылка не такого вида github.com/username/repo, а аккуратная и лаконичная, хоть и выглядящая немного «по-инженерному», например: react-patterns project. Тут реальный путь скрыт за описанием проекта. Щёлкать по линкам уж все умеют, а читабельность заметно лучше.

Оформляем профиль

Титульная страница профиля на GitHub позволяет быстро оценить активность пользователя. Для ее оформления также можно использовать альтернативную визуализацию (на примере профиля Bohdan Kovalchuk) — прямо берите и вставляйте в резюме чарты.

Но давайте сравним два профиля на GitHub.

Источник: профиль на Github by Aleksey Ivanov

Чем отличается второй:

не рандомная аватарка;
есть имя (если профиль — ваше резюме, то чего стесняться?);
статус явно говорит о том, что Алексей открыт к предложениям о работе;
коротко описаны скиллы (Front-end, React, NodeJS);
есть ссылка на профиль в LinkedIn;
есть 6 отобранных проектов, с которых заинтересованный посетитель и начнёт изучение портфолио.

Зайдите в свой профиль сейчас, нажмите Customize your pins и добавьте хотя бы 2-3 самых показательных проекты. Затем в настройках профиля заполните всё, что возможно.

Делаем личное портфолио на GitHub

Знаете ли вы, что проект вида username.github.io после публикации доступен, собственно, под таким именем? Вот пример личного сайта-портфолио (проект на гитхабе, Ruslan Sakevych):

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

Стиль кода

Мы уже говорили, что код пишется для других людей? Ещё раз повторим: код пишется для других людей. Это значит, что код должен быть читаемым. Соблюдение стиля кода, принятого в вашем технологическом стеке, адекватный нейминг переменных, классов, функций, модулей и файлов — это всё важно в работе. Если человек этому не следует даже в самых маленьких своих проектах, где он царь и бог, вряд ли можно ожидать, что он будет это хорошо делать в других. Вероятность есть, конечно, но по опыту — очень низкая.

Так что «причешите» код, который планируете показывать. Линтеры вам в помощь (заодно научитесь настраивать, если ещё не умеете). Можно, не стесняясь, брать преднастроенные проекты — Open Source. Например, ESLInt-Prettier-Husky boilerplate для JS фронтенда или EodData CLient (Python, Aleksey Ivanov). Для вашего стека придётся поискать или поспрашивать кого-нибудь.

Коммиты

Комментарии коммитов тоже пишутся для других людей. Комментарии вида «added file», «fixed», «add code» и подобные (осторожно, вредные советы!) говорят о недостаточно хорошо развитых навыках изложения мысли и нелюбви к людям, которые будут читать ваш код. Самое время приобретать правильный навык. И лучше немного помучаться над текстами коммитов в учебных или пет-проектах, чем потом выслушивать от старших по званию коллег ворчливые замечания или вообще не найти желающих сделать код ревью.

Вот один из примеров читабельной истории коммитов: frontend project lvl1 by Sergey Shramko.

Простое решение

Чтобы не заниматься всем вышенаписанным, можно просто никому никогда не признаваться в наличии профиля на GitHub. Нет материала — нечего критиковать.

Итого

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

Свидетельства «очевидцев» из числа моих знакомых разработчиков-новичков:

Евгений, Front-end Developer: «У меня спрашивали про самый интересный проект: что делает, почему так, логику и связи модулей. Ещё открывали другой проект и по нему тоже задавали вопросы. Я уже пару месяцев как трудоустроился. По моему мнению, что сработало: 1. Множество тестовых задач с других собесов, часть из которых опубликовал на гитхабе; 2. Собственные нетипичные и работающие микропроекты».

Лена, Front-end Developer: «Задавали вопросы по моим проектам на нескольких собеседованиях. Смотрели портфолио. На одном просили прокомментировать самый интересный проект из примеров на гитхабе».

А у вас когда-нибудь смотрели портфолио? Помогало ли портфолио при поиске работы?

Что ещё почитать по связанным темам

Credits

Спасибо команде kottans и персонально Christina Landvytovych, Oleksandr Lapshyn за поддержку и contribution в материалы статьи.

В качестве иллюстраций здесь используются проекты разработчиков, которые так или иначе имеют отношение к комьюнити kottans. Если вам какой-то из проектов понравится, не пожалейте поставить ⭐ на GitHub — вам обязательно воздастся ��