А вы правильно оформляете commit-message?
Я надеюсь, что да, но на всякий случай приведу несколько распространенных рекомендаций по оформлению коммитов. Если я что-то упустил, жду вас в комментариях.
🔹Длина заголовка коммита не должна превышать 50 символов
Это сделано исключительно для удобства чтения журнала проекта.
🔹Формат заголовка коммита зависит от соглашений в конкретной команде.
В разных проектах разные требования к формату заголовка. Например, есть требование в начале заголовка размещать номер тикета: "WTF-42: some question fix". Или же в начале заголовка указывать компонент, в который были внесены изменения "tests: unit: add some question test". Точка в конце заголовка не ставится.
🔹Заголовок коммита содержит краткое описание проделанных изменений.
Заголовок коммита должен отвечать на вопрос: какие изменения были сделали в проекте? Не более. Подробности и причины сделанных изменений нужно перенести в тело коммита.
🔹Между заголовком коммита и телом нужно оставлять пустую строку.
Очередная рекомендация, которая повышает читаемость журнала. В консоли эта рекомендация не сильно заметна, а вот GitLab и GitHub с помощью пустой строки умеют отображать заголовок коммита и скрывать его тело.
🔹Тело коммита не ограничено, а вот строка в теле коммита не должна превышать 72 символа.
Тело коммита не является обязательным, но его наличие позволяет без изучения кода лучше понять, что и почему было сделано. Т.е. если был исправлен баг, то нужно описать условия при которых он проявлялся и каким образом был исправлен. Если новая фича, нужно написать на основе каких требований она была добавлена. Можно приложить ссылки на спецификации, обсуждения, но нужно быть уверенным, что ссылки останутся актуальными через несколько лет. Важно: не нужно писать в теле коммита, как вы делали задачу.
🔹Уточните, нужно ли подписывать коммит.
Чаще всего это требование встречается при работе с open source продуктами. Коммит подписывается с помощью закрытого ключа, таким образом, вы подтверждаете вашу идентичность.
p.s.: а еще шаблон коммита можно прописать в git pre-commit hook
Технические посты тут t.me/neverending_cpp
Не курсиками едиными…
Хочу чуть подробнее развить тему, которую затронул в своем предыдущем посте Как меня приняли за уважаемого человека, по одной ссылке
Дисклеймер: в низу поста будет ссылка на мой ТГ, кому не нравиться - пройдите мимо.
Тему обучения IT. Как преподаватель, я с большим уважением отношусь к желанию людей учиться любыми способами: самостоятельно, под руководством наставников, на онлайн/оффлайн курсах. Это мне очень нравиться.
Особое уважение я испытаю к самоучкам — это люди, которые сделали себя сами, с огромной мотивацией к самосовершенствованию и познанию нового. Пусть их знания могут оказаться фрагментарными, но зато они могут научиться всему, чему захотят, в кратчайшие сроки. По-моему, это самые лучшие кандидаты на IT вакансии, где постоянно надо учиться новому. Но чаще вижу подобных людей среди фрилансеров или предпринимателей. Не потому что их не берут или они не соответствуют уровню, а просто потому что они предпочитают выгребать по жизни сами. Хотя исключений тоже хватает или мне просто так везло.
Если с мотиваций к обучению не все хорошо или нет желания ходить по граблям долго, можно немного сократить дистанцию. Грабли никуда не денутся, их просто станет меньше, удастся срезать некоторые углы. При таком подходе нужна платежеспособность и умение договариваться. Если все есть в наличии, то можно обратиться к человеку с опытом, желательно, чтобы не только с опытом работы, но и обучения, но это не шибко критично, как мне кажется.
Наставник/преподаватель сможет ускорить процесс обучения, подберет нужные слова для мотивации, перескажет информацию в более понятной форме, задаст нужный фокус, чтобы не распылялось внимание. Это все важно, но не основное. Самое главное - к такому человеку всегда можно обратиться за помощью и он сможет задать правильный вопрос, который подтолкнет мыслительный процесс в нужную сторону. Если не помогло - даст совет. А если и от него не было проку - покажет на примере, как надо делать, и сможет объяснить, что это не единственный вариант, а возможно ещё покажет другие способы докопаться до сути и подчеркнет нюансы. Хороший, но крайне не бюджетный вариант, учиться придется года полтора-два, от 8 до 10 занятий в месяц, можно реже, но и общий срок обучения будет дольше. Кто-то из преподавателей не особо лютует по ценам, но у некоторых они очень даже кусаются.
Курсы — вот это самая непонятная для меня субстанция.
Начнем с вопроса к бесплатным курсам: «Кто платит, чтобы они появились?». Работа по созданию курса проделывается не маленькая. Это десятки, а возможно и сотни человеко-часов. В чем выгода? Не понимаю, но уважаю команды людей, которые берутся за такое дело. Сам неоднократно прибегал к помощи бесплатных курсов в начале своего пути.
К платным вопросов нет, там для меня все понятно, исключая пару моментов. Зачем они вообще нужны, если вся информация и так есть в разбросанных по сети статьях или бесплатных курсах, практически в том же виде, в котором представлена на курсе?
Из онлайн курсов сам покупал однажды один курс по SMM: как по мне — очень много воды и минимум полезной информации. Думал, не повезло, но в тот год ко мне массово повалили студенты различных онлайн школ разного пошиба, где обучали разработке на Python, Java, JS, backend, fullstack и прочего, и этот поток шел года четыре. Да и сейчас он не стал особо меньше, что странно.
Заглядывал я в их курсы, прям проматывал ролики, что им выдавали в програме обучения. В целом, курсы своих денег стоят, но, видимо, с подачей информации что-то не так раз люди ищут помощь на стороне. Не буду говорить, что при моей подаче люди понимают с первого раза, но у нас хотя бы нет дедлайнов и мы можем мусолить одну тему столько, пока не удастся развеять туман и дать правильное понимание проблемы.
С другой стороны, можно сказать, что у курсов есть куча бонусов. Сертификат, который не особо где котируется, но есть места, где может помочь. Гарантия трудоустройства — последний раз, когда видел договор, там обещали целых три приглашения на собеседования, после которых снимали с себя все гарантии, сейчас может что поменялось. Ментор — один на несколько десятков студентов, с которым можно попытаться решить вопрос через переписку. Все это несколько спорные бонусы, но все же есть реальный плюс - групповые проекты. Они позволяют почувствовать ад, который ждет выпускников этих курсов, если они решат работать по новой специальности. Узнать, что тебя ждет в будущем - это прям не оспоримый профит, который дает возможно еще передумать.
Платные курсы - спорная вещь,. Кому-то помогают, но я вживую таких людей не встречал. Поэтому, если меня спрашивают, идти на них или нет, всем говорю, что не надо. Может с оффлайн курсами ситуация другая, но, честно, сомневаюсь. По своему опыту скажу: вытянуть группу людей на один уровень - задача нереальная, ну или это должна быть ультра малая группа человека 3-4, где каждому можно уделить необходимый ему квант внимания.
Если и идти на курсы, то на бесплатные, а потом наращивать на полученный каркас знания из открытых источников. Все же IT — это не магический мир, где знания передаются в закрытых школах и никогда не выходят за их пределы, все есть в сети.
Ссылка на мой канал, где, к сожалению, или счастью, нет никаких курсиков, только мысли, заметки, впечатления от работы в IT и куча нытья: https://t.me/it_hat
С какой книги C++ разработчику начать изучение Python?
Я рекомендую начать с книги "Простой Python".
Книга состоит из двух частей. Первая часть занимает около 200-х страниц и содержит описание базового синтаксиса Python, которого вполне хватит, чтобы переписать Python-сервис на C++ или написать интеграционные тесты на PyTest. Основы Python даны достаточно сжато, поэтому при чтении книги у вас не будет возникать чувство скуки, из-за того что базовые конструкции (например, циклы) разжевываются по несколько десятков страниц. Разработчику на С++ вполне реально изучить первую главу за пару вечеров.
Вторая часть содержит обзор различных областей применения Python. Глава интересна не только с точки зрения применения Python, но и в целом для знакомства с различными технологиями в современном мире разработки.
Технические посты тут t.me/neverending_cpp
С чего начать изучения ООП?
Я бы рекомендовал начать с вдумчивого и неторопливого чтения книги Гради Буч "Объектно-ориентированный анализ и проектирование". Книга содержит в себе в основном теоретические, я бы даже сказал академические, изложения принципов ООП. В книге мало кода, поэтому её могут читать даже новички без опыта в программировании. Прочитав эту книгу вы сможете с легкостью проходить теоретическую часть собеседования, а также поддерживать дискуссии на темы пользы и вреда множественного наследования, инвариантов и их места в инкапсуляции и т.д.
А какие ваши любимые книги по основам ООП?
UPD:
Технические посты тут t.me/neverending_cpp
С какой книги начать изучение С++?
Этим постом я открою серию постов про книги для самообразования и заодно отвечу на традиционный вопрос всех новичков в С++: с какой книги начать изучение С++? Мой вариант: "Язык программирования C++. Базовый курс", Стенли Б. Липпман, Жози Лажойе, Барбара Э. Му, 5 издание с поддержкой стандарта С++11. На мой взгляд, эта книга соблюдает баланс между теорией и полезной практикой и содержит много примеров использования STL. Если вы по каким-то причинам мало работали с STL, также рекомендую полистать Липпмана. Книга не утомит вас однообразными задачами с вводом/выводом в консоль и разбором принципов ООП на примерах мяукающих кошек и гавкающих собак😉 Из минусов: нет многопоточки, достаточно старый (тем не менее до сих пор очень востребованный на рынке) стандарт С++11.
#книги
UPD:
Технические посты тут t.me/neverending_cpp
Порочность воли: многогранный феномен
"Порочность воли" – это понятие, которое веками волнует умы философов, психологов, социологов и писателей. Оно описывает состояние, когда воля человека направлена на совершение действий, противоречащих моральным принципам, общественным нормам или его собственным представлениям о правильном.
Однако "порочность воли" – это не просто однозначное определение. Его значение зависит от контекста, в котором оно употребляется, и от точки зрения, с которой рассматривается.
Философский взгляд
В философии "порочность воли" часто связывается с понятием греха, морального падения и утраты добродетели. В этом контексте "порочность воли" – это не просто слабость или ошибочное решение, а глубокое внутреннее состояние, которое может быть следствием грехопадения, первородного греха или других философских концепций. Философы рассматривают "порочность воли" как проблему, требующую глубокого осмысления и решения, которое часто ищется в духовных практиках, самосовершенствовании и поисках истины.
Психологический взгляд
В психологии "порочность воли" может описывать состояние, когда человек испытывает сильное желание совершить действие, которое он сам считает неправильным или вредным. Это может быть связано с зависимостями, импульсивным поведением, нарушениями самоконтроля и другими психическими проблемами. Психологи рассматривают "порочность воли" как симптом некоторой глубинной проблемы, которая требует профессиональной помощи.
Социальный взгляд
В социологии "порочность воли" рассматривается как феномен, который может приводить к различным социальным проблемам, таким как преступность, насилие, наркомания, аморальное поведение и т.д. Причин этого феномена может быть много – от недостатка образования и бедности до социальной изоляции и отсутствия моральных ценностей. Социологи акцентируют внимание на системе и окружении, которые могут способствовать порождению "порочности воли".
Литературный взгляд
В литературе "порочность воли" часто используется как художественный образ, который помогает раскрыть внутренний мир персонажа, его мотивы, конфликты и моральные дилеммы. "Преступление и наказание" Ф. Достоевского, "Фауст" И. Гёте, "Дон Жуан" Лорда Байрона – все эти произведения проникнуты темой "порочности воли", которая становится движущей силой сюжета и отражает глубокие философские и психологические проблемы человека.
В заключении, "порочность воли" – это сложное и многогранное понятие, которое не всегда легко определить. Это не означает полное отсутствие моральных принципов, а скорее отражает сложную внутреннюю борьбу, психические расстройства или неблагоприятные жизненные обстоятельства. Для понимания "порочности воли" необходимо учитывать контекст, в котором она употребляется, и изучать ее с разных точек зрения.
Понравилась статья? Хотите узнать больше о "порочности воли" и других интересных темах?
Подпишитесь на мою страницу в социальной сети, чтобы не пропустить новые публикации!
https://vk.com/roman_dmitrievich_ceo
Оцените статью, нажав на сердечко, и оставьте комментарий, чтобы поделиться своими мыслями!
Ваше мнение очень важно для меня! 😉
Почему у вас не получается программировать. Часть 2
Вокруг ИТ продолжает курсировать зашкаливающее количество мифов, а рынок труда превратился в конкретный цирк. Наверное, единственный способ хоть чуть-чуть сгладить безумие — это продолжать помогать новичкам преодолеть порог входа. А то они совсем уже дичь творить начали)) Короче, спустя 2 года - держите вторую часть заметки.
Я искренне советую новичкам вчитаться. Пусть даже за один раз переварить не получится. Вполне возможно, сэкономите время, нервы и деньги на учебу.
Содержание
Важная ошибка новичков.
Работа по алгоритму.
Как выглядит типичная работа программиста.
Почему так получилось?
А как тогда разрабы вообще работают?
Очень поверхностно — что теперь делать новичкам?
Важная ошибка новичков
Реально важная штука, которую начинающие как правило не осознают — в программировании нет полностью повторяющихся, шаблонных задач. Вообще.
А теперь надо объяснять, о чем я.
Работа по алгоритму
Объяснить проще на примере. И чтобы далеко не ходить, возьмем простой и всем знакомый. Как в очень упрощенном виде выглядит работа кассира?
Поздорвался -> пакет нужен? -> пропикал -> карта или наличка? -> досвидания.
Это алгоритм. Кассир один раз его запомнил, а затем повторяет для каждого следующего покупателя. И на следующий день так же. Эту работу можно условно назвать шаблонной, т.к. там есть алгоритм, шаблон. (Да, я в курсе, что кассиры делают еще кучу другой работы, но для примера достаточно)
В реальности алгоритм обычно сложнее. Там есть ответвления, условия. Да и просто неожиданности и человеческий фактор. Если наличка, то так. Если карта, то по-другому. А если пьяный покупатель дебоширит, то время импровизаций.
Но это все-таки алгоритм. И большая часть покупателей полностью впишется в шаблон: заберет покупки, пробурчит «спасибо» и отчалит, следующий.
Алгоритм может быть еще навороченнее и больше, с бОльшим количеством условий и «импровизаций». Например в работе бухгалтера. При этом в норме работа бухгалтера все-таки +/- повторяется - каждый месяц, квартал или хотя бы год.
И именно к такой работе привыкли многие люди. Они ожидают примерно такого расклада. А иногда даже не представляют, как может быть по-другому.
Мы еще готовы ожидать всякого внезапного от работы с людьми. Но от работы с кодом новички часто ждут четкости, точности и лютой стандартизированности. А зря.
Как выглядит типичная работа программиста?
Сегодня ты создаешь автоматическую отправку смс. Через неделю добавляешь к какой-то статистике возможность сохранить ее в эксель. Затем чинишь отвалившуюся оплату. А потом добавляешь новую фичу в ваш древний телеграм-бот.
И все эти задачи больше не повторятся, они одноразовые. Но будут другие, опять о чем-то новом.
При этом:
С смс ты раньше вообще никогда не работал(при опыте в несколько лет).
Статистику эту видишь в первый раз (но хотя бы сохранение в эксель раньше делал, три года назад, на другой работе, в совершенно другом проекте, где все по-другому).
Что там могло отвалилось в оплате, понятия не имеешь.
О существовании у вас телеграмм бота вообще не знал.
И естественно, никто тебе не покажет, как делать эту работу. Ни учителя в вузе, ни преподы на курсе, ни коллеги, ни начальник. Никто не сможет выдать тебе никакого полноценного алгоритма действий.
Здесь важный момент. Коллеги не будут рассказывать, не потому что ты уже должен знать. И даже не потому что злые. А потому что ты должен сам разобраться.
Еще штрих к картине: Со всеми этими вещами(статистика, смс и тп) ты можешь вообще не пересечься следующие год-два. Либо вообще не пересечься больше никогда, ни на одной работе. А даже если на следующей работе у тебя и будет телеграмм-бот, то от предыдущего он может отличаться как дельфин от жирафа. Ну хотя бы оба млекопитающие.
В реальности же программист вообще выкидывает нафиг из головы все подробности, как только закрывает задачу. При таком объеме проходящей через тебя инфы это здоровая защита) Даже если тебе через месяц прилетит задача на исправление бага в твоем же коде, ты не сразу въедешь. Каждый раз как в первый)
И вся эта движуха — при работе в одной компании, на одном проекте, на стабильной работе. Постоянно. Каждый день/неделю/месяц что-то новое. И никаких подробных объяснений.
Почему так получилось?
Надеюсь, теперь более-менее понятно, что я имею в виду, когда говорю «нет шаблонных задач». Теперь надо рассказать, почему так вообще вышло.
Здесь на самом деле все просто. Любая шаблонная работа в программировании автоматизируется моментально. Самими разрабами. За это и платят)
Если нужно создать 50 очень похожих телеграмм ботов, разраб не будет это делать руками. Он один раз напишет код, который позволит автоматически нагенерить хоть 50, хоть 500 ботов. В крайнем случае пишется код, который позволит менеджеру в пару кликов эти боты создавать. (Вы может видели конструкторы тг ботов. Вот, это именно оно)
Если нужно прикрутить сохранение из веба в эксель к 17-ти отчетам, оно не создается под каждый отчет отдельно. Один раз пишется софт, умеющий выгружать файлы. И потом просто подключается ко всем отчетам. А разраб скачет дальше, работать с какой-нибудь отправкой емейлов.
На более базовом уровне это вообще выглядит вот так: Если программист в трех местах воткнул в программу одинаковый код, строчек так на 15, к нему сразу возникают вопросы. Потому что в норме весь повторяющийся код сразу выносится в отдельный «кусок» (метод, функцию, класс, модуль, файл, библиотеку, фреймворк, что угодно) и потом просто используется везде, где нужно.
А тк задачи моментально автоматизируются, то они и не повторяются. А раз нет повторений, то каждая задача делается в первый и единственный раз. А значит, нет и никаких инструкций.
Поэтому не бывает такой работы в программировании, куда бы ты пришел, а тебе говорят: «нам нужно 15 одинаковых телеграмм-ботов в месяц». Ты говоришь «круто! Нас как раз на курсе учили». Потом коллеги объясняют тебе детали, всё показывают. И следующие два года ты пишешь только ботов.
Поэтому курсы типа «мы научим вас писать тг бот и парсер» часто бесполезны полностью.
А как тогда разрабы вообще работают?
Ок, но как жить совсем без нормальных инструкций? Когда даже на учебе их получить нереально.
Вкратце — программист и есть тот чел, который инструкции пишет. Только не для людей, а для компа. Банально, но на удивление не всем очевидно — любая инструкция не истина в последней инстанции. Она кем-то когда-то была создана. Ну вот и создаем.
Поэтому работа программиста заключается в том, чтобы решение изобрести. Это не означает изобрести что-то совершенно прорывное, новое или велосипед. Но для каждой конкретной задачи конкретное решение создается впервые. И только один раз. Потому что дальше оно работает «само», тк автоматизировано. А новая задача будет уже отличаться. Могут быть задачи на так называемую доработку. Но они тоже означают «придумать, изобрести, как добавить сюда новые фичи».
Программист почти никогда не знает заранее и точно, как он будет выполнять свою работу. Если опытный — то примерно конечно представляет. Но в любой момент может вывалиться любая неожиданная дичь даже в самой банальной задаче. Потому что конкретно эта задача делается в первый раз.
Поэтому, кстати, разрабы частенько называют сроки в стиле «от двух часов до двух недель». Или говорят, что могут назвать примерные сроки только после того, как часа два(дня два) поработают над задачей. А потом эти сроки регулярно продалбывают, потому что дичь все-таки вывалилась. Особенно, если код древний.
И именно поэтому коллеги не дадут тебе инструкций. Потому что готовой у них нет, а придумать для тебя алгоритм действий — это значит буквально сделать за тебя всю работу. Нафига тогда тут ты?)
Конечно, у программистов тоже есть рутина и свои шаблоны. Но это обычно на уровне «лучшие практики», «архитектурные паттерны». В лучшем случае туториал, из которого для твоей задачи сработает процентов 70.
Это и близко не про «нажимаешь сюда, потом сюда. Здесь делаешь так, а здесь вот так. Эту задачу надо решать вот так, а эту вот эдак». Короче, понимание рутины заметно отличается от бытового. И понимание шаблонов тоже)
Очень поверхностно — что теперь делать?
Совсем кратко — учиться изобретать. Так себе совет, конечно. Но пошаговый план дать не могу, тк... ну вы поняли) Научиться изобретать можно только на практике, изобретая что-нибудь. Не повторяя за другими, а делая что-то простое, но своё.
Умение изобретать, кстати, включает в себя умение не изобретать велосипеды) Нужно учиться использовать готовые инструменты. И понимать, когда лучше готовый инструмент, а когда писать своё. Но опять же — решать это вы должны сами, тк это вы пишите инструкцию.
Нужно учиться именно создавать свои, новые решения. Не учиться решать задачи какого-то типа. Потому что типовых не будет.
Без этих навыков не стоит идти даже на стажера.
База, конечно, нужна. Для этого подойдут первые уроки любого бесплатного курса. Зубрить не надо, но простые понятия можно в голову залить заранее. Про архитектуру можно почитать, но в самом начале вы всё равно ничего не поймете. Это уже следующий этап. Без него можно остаться говнокодером, но спешить закапываться в архитектуру тоже не надо.
А дальше один из самых действенных способов — придумать себе простой проект и начать его делать. Только не тот, который можно буква в букву скопировать из туториала.
Если вы сделали по туториалу калькулятор и у вас всё с первого раза запустилось — вы ничему не научились. Это не имеет отношения к реальной работе.
А вообще, лучше самостоятельно определять, что и в каком порядке учить. Т.к. умение это делать — тоже часть навыка создавать собственные инструкции. Так что тренируйтесь)
Про то, как учиться работать без инструкций и не пугаться, я наверное когда-нибудь еще напишу. Но на сегодня хватит)
Если возникли вопросы — это хорошо, спрашивайте в комментах