Вряд ли есть место для хранения кода лучше, чем GitHub. И даже небольшое портфолио аккуратного и выразительного кода может оказаться главным козырем кандидата в борьбе с конкурентами за вакансию. Ваше (и мое дело) написать статью в гугл доксе с картинками и остальным, редакторское дело—выкладывать ее на сайт. Дело в том, что это заметно разного типа ресурсы. форматирование markdown Hacker News он сохранить ссылку и пообсуждать её, но если повезёт — вдруг будет жуткий подскок интереса.
[Опрос, 1 мин] Публикация статей на DOU
Ну смотрите я к примеру написал техническую статью на Medium.Не супер открытие конечно, но в моей области что бы все это вместе собрать я потратил кое-какое время. Тут dou.ua/forums/new появился визуальный редактор, копипаста в него по идее более-менее нормально должна работать. 2) Да, топик будет добавлен, но не опубликован (премодерация), можно в заголовке указать что-то типа (топик еще не готов), чтобы его не опубликовали случайно. Например, у них вначале не было своего хостинга картинок.
Как оформить профиль на GitHub так, чтобы он работал при поиске работы
Вы написали большую статью на 3000 слов и 100 ссылок с форматированием и вложенными списками 2х или 3х уровней. И теперь это все нужно из гуглдокс перенести в непойми что, не потерять закрывающие теги и все это без предпросмотра. Некоторые статьи пишутся несколькими людьми.
Нет совместной работы над статьей
Существуют различные взгляды на открытые портфолио проектов на облачных VCS (GitHub, GitLab и подобных). Многие опытные разработчики считают, что на профиль никто не смотрит (см. Простое решение). Для некоторых тим- и техлидов увидеть code style и способ организации кода в проекте (особенно в отношении кандидата-джуна) лучше, чем услышать 1000 слов на собеседовании. Правильное оформление профиля и двух-трёх наиболее показательных репозиториев на GitHub поможет обойти конкурентов. А когда по итогам цикла собеседований остаётся несколько равноценных кандидатов, то каждый бит информации может оказаться решающим — в том числе и проекты на GitHub. Я уже более 15 лет управляю процессами создания продуктов — от гипотез до устойчивых продаж.
[Опрос, 1 мин] Публикация статей на DOU
В этом проекте она продемонстрировала творческий подход не только к написанию «очередного JS-фреймворка», но и к дизайну и внешнему представлению в целом. Выберите два-три проекта, которые наилучшим образом отражают ваши навыки. Учебные тоже годятся (быстро допили незаконченные).
- Неплохой кейс для прокачки Data Science скиллов.
- Это странно, но приходится искать сторонний хостинг, выкладывать туда картинки, указывать на них ссылки в статье и надеяться, что через время картинки все так же будут доступны.
- Тут dou.ua/forums/new появился визуальный редактор, копипаста в него по идее более-менее нормально должна работать.
- А где тогда держать основное тело статьи?
Нет совместной работы над статьей
Например, один автор согласовывает разные части статьи с другими соавторами. В таком случае приходится использовать гуглдокс, где можно комментировать текст построчно. И затем переносить согласованный текст в DOU.
Конечно, первое, что увидит ревьюер, — титульная страница профиля, с которой его нужно провести на конкретный проект или проекты. Тут все должно быть информативно и удобно. Кстати, было бы интересно увидеть статистику по DOU за все годы по статьям, комментариям, пользователям. Было бы видно как растут и растут ли вообще.
Неплохой кейс для прокачки Data Science скиллов. Вот фиг их поймёшь, западников, почему так… Я согласен, топики про то как прикрутить REST API к агрегатору больше собирают.
На dou разделение на статьи/топики есть, объяснения критериев нет. Сейчас этого разделения нет, но все равно есть объяснение, что они хотят видеть на своем ресурсе и поощряют пользователей добавлять такой контент. Вот пример на хабре, где они поясняют какие статьи они хотели бы видеть у себя на площадке, по категориям и с объяснениями.
Но с ростом аудитории придется линейно увеличивать количество редакторов. Это не очень хорошо масштабируется и в итоге упрется в количество редакторов. В этой статье я бы хотел обсудить опыт пользователей DOU по публикации статей в ленте и на форуме. Некоторые статьи получаются достаточно большими и их не получается написать за один подход. Хотелось бы иметь возможность сохранить черновик и вернуться к нему позже. Или в случае негативной реакции на статью убрать ее в черновики на доработку.
И совершенно другое — увидеть в репозитории хорошо читаемый код, отражающий действительные технические навыки. Во всяком случае, если уж и указывать линк на GitHub-профиль в резюме, то точно есть смысл помочь ревьюеру увидеть самое главное. Можно на news.ycombinator.com такие статьи постить. Попробуйте alonecoder.github.io/habrconverter или что-то подобное для того, чтобы из документа получить код с тегами.
В самом верху страницы проекта есть место для краткого описания и ссылки на работающую задеплоенную версию. Если ваш проект можно опубликовать — сделайте это, хотя бы на GitHub pages. Даже автоматически сгенерированная страница из документации — уже что-то. Во-первых, хоть как-то индексируется гуглом, а во-вторых, позволяет выработать привычку оформлять проект полностью. Вот отличный пример работы студентки курса по фронтенду, а теперь разработчицы в MacPaw Mary Fedirko — погодное радио (нажми кнопку ON).
В профиле пользователя есть возможность запинить до 6 проектов. Выберите (или создайте) те, которые лучше всего демонстрируют ваши навыки, и приступайте к их оформлению. Эта статья о том, как начинающим разработчикам оформить профиль на GitHub так, чтобы он стал дополнительным преимуществом на собеседовании.
Но на нём самом больше нескольких строк обычно не постят. А где тогда держать основное тело статьи? Ну я как то написал но сказали что это уже есть на хабре. Но если у меня выбор между хабром и доу то выбор очевиден. Разумеется, могут оценить и уровень владения технологиями. Одно дело — прочитать в резюме «CSS3 — средний» или услышать ответ на вопрос «А что ты умеешь в JavaScript?
IT курсы онлайн от лучших специалистов в своей отросли https://deveducation.com/ here.