Pull to refresh

Comments 25

Есть Зло
Есть Великое Зло
И есть Пет-проекты
п.с. я их тоже местами люблю!

Не понимаю, за что заминусовали статью. По мне так советы толковые, особенно для тех, кто только знакомится с гитом и кто намерен завлечь работодателя петами. Хорошая подача - залог того, что вкладку с проектом не закроют сразу со словами "Чёт какая-то муть, не хочу разбираться".

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

Увы, уже некоторое время наблюдаю как "минусятся" вполне толковые статьи разного уровня, связываю с большим кол-вом новых пользователей условно говоря уровня "пикабу", где минусы за просто так щедрой рукой разлетаются (надеюсь никого не обидел, сам на пикабу захожу подеградировать)

Так сказать, статью не читал, но минус поставлю, понимаю, встречался с таким, к сожалению, некоторых это отталкивает в дальнейшем от написания статей, это печально

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

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

Отдельное спасибо за информацию про спойлеры )

Вам спасибо за добрые слова)

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

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

Рекрутеры, может, и не откроют, но это отличная отправная точка для разговора. За 5-10 минут у любого проекта находятся места, о которых можно поговорить. Так что перед собеседованием я ставил DnD на 10 минут, чтобы успеть сделать чай и ознакомиться с резюме.

Как - понятно. Осталось понять, зачем так напрягаться. Среднестатистическая хрюшка всё равно ничерта там не поймёт, даже если заглянет. А на собесе проще так рассказать, что к чему. Главное, самому не забыть. И вот, чтобы не забыть, надо записать в README.

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

Да тоже далеко не все смотрят, по опыту знаю. А если и посмотрят, их будут интересовать не красивые картиночки в README, а то, как построена архитектура проекта, как написан код. По крайней мере, меня бы интересовало именно это. Плевать, насколько красиво оно оформлено. Если под красивым фантиком известная субстанция, то конфеткой это не назовёшь.

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

Однако, очевидно, что все пункты следует выделить каким-то образом, например **жирным шрифтом**, чтобы отслеживалась структура.

Разделы в README обычно принято отделять заголовками (маркдаун тэги #, ##, ### и т.д.) , а не жирным шрифтом.

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

Размер заголовков "регулируется" количеством символов # перед текстом заголовка

Да, я знаю, необходимый мне размер добивался кажется 4 или 3, и я подумал, что легче выделить жирным, насколько я помню, чтобы не громоздить много #

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

Вот так надо оформлять read me для пет проектов

https://github.com/torvalds/linux

Ну не согласен

Проект должен быть интересен тебе в первую очередь, но если проект крутой почему бы чуть чуть не запариться над оформлением и сделать проект более интересным для работодателей?

У меня за все случаи подачи резюме только один раз было такое, что тот, кто будет проводить техническое собеседование, взглянул на то, что я делаю на своём GitHub'e. Кандидатов на одну позицию сейчас просто океаны, никто не станет смотреть на пет-проекты, даже резюме глазами пробегают ну очень бегло

Я изучал код кандидатов на гитхабе. Откуда у вас сведения, что это было лишь однажды?

Интервьюер сам мне это сказал уже на собеседовании

Это говорит о том, что как минимум один раз, а не только один раз

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

Я не буду вдаваться в синтаксис md

И очень зря, потому что выбранный для обозначения секций `**жирный шрифт**` — моветон. Примерно такой же, как и центровка текста пробелами в «богатом» документе.

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

Ещё я б указал на важность tldr, но не б

Sign up to leave a comment.

Articles