LaFilmFabrique_BLOG

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

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

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

[Опрос, 1 мин] Публикация статей на DOU

И совершенно другое — увидеть в репозитории хорошо читаемый код, отражающий действительные технические навыки. Во всяком случае, если уж и указывать линк на GitHub-профиль в резюме, то точно есть смысл помочь ревьюеру увидеть самое главное. Можно на news.ycombinator.com такие статьи постить. Попробуйте alonecoder.github.io/habrconverter или что-то подобное для того, чтобы из документа получить код с тегами.

Нет совместной работы над статьей

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

Нет совместной работы над статьей

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

[Опрос, 1 мин] Публикация статей на DOU

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

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

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

Ну смотрите я к примеру написал техническую статью на Medium.Не супер открытие конечно, но в моей области что бы все это вместе собрать я потратил кое-какое время. Тут dou.ua/forums/new появился визуальный редактор, копипаста в него по идее более-менее нормально должна работать. 2) Да, топик будет добавлен, но не опубликован (премодерация), можно в заголовке указать что-то типа (топик еще не готов), чтобы его не опубликовали случайно. Например, у них вначале не было своего хостинга картинок.

На dou разделение на статьи/топики есть, объяснения критериев нет. Сейчас этого разделения нет, но все равно есть объяснение, что они хотят видеть на своем ресурсе и поощряют пользователей добавлять такой контент. Вот пример на хабре, где они поясняют какие статьи они хотели бы видеть у себя на площадке, по категориям и с объяснениями.

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

Но с ростом аудитории придется линейно увеличивать количество редакторов. Это не очень хорошо масштабируется и в итоге упрется в количество редакторов. В этой статье я бы хотел обсудить опыт пользователей DOU по публикации статей в ленте и на форуме. Некоторые статьи получаются достаточно большими и их не получается написать за один подход. Хотелось бы иметь возможность сохранить черновик и вернуться к нему позже. Или в случае негативной реакции на статью убрать ее в черновики на доработку.

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

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

IT курсы онлайн от лучших специалистов в своей отросли https://deveducation.com/ here.