C++ + IT

А на твои отклики не приходит ответ? Или, что ещё хуже, тебе сразу отказывают?
Давай разберёмся.

Знаешь, как выглядит большинство резюме C++ разработчиков? Примерно так:
Январь 2024 — по настоящее время
ИТЦ "СамаяЛучшаяКампания" — Ведущий программист
- Разработка приложений для нужд производства
- Написание тестов

Май 2023 — Декабрь 2024
ОАО "ОтличнаяКомпания" — Старший инженер-программист
- Создание виджетов на Qt
- Написание документации
- Ведение переговоров с заказчиком

и так далее...

Выглядит знакомо? Увы, такие резюме обречены на провал.

Почему?

Парсеры. Машина просто проигнорирует такой текст. А значит, твоё резюме не попадёт в базу крупной компании или рекрутингового агентства.

Ручной отбор. Даже если компания проверяет резюме вручную, оно, скорее всего, окажется в самом конце списка кандидатов. А то и сразу получит отказ.

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

В чём проблема?

Как думаешь, что именно не так с этим резюме? Или во всём виноват рынок с его странными требованиями?

Пример первый. Давайте посмотрим на код ниже (да, он собирается и запускается):
class A
{};

class B
{
public:
B(const A &)
{}
};

void foo(const B &)
{}

int main()
{
A a;
foo(a);
}

Я специально убрал все лишние строчки из кода, чтобы вы смогли сосредоточиться на всей абсурдности происходящего: при вызове функции foo тип A преобразовывается в тип В, при этом мой компилятор даже с выкрученными флагами ворнингов не выдал мне никакого предупреждения. Что-то мне подсказывает, что это не то поведение, которое можно завещать потомкам (т.е. разрабам, которые будут работать с вашим кодом).
Если воспользоваться услугами сайта https://cppinsights.io/, можно увидеть, что компилятор преобразует код функции main в следующий:
int main()
{
A a;
foo(B(a));
return 0;
}
Т.е. в момент вызова функции foo из объекта класса A создается временный объект класса B.
Фиксится эта проблема с помощью использования спецификатора explicit перед конструктором класса B.

Продолжение следует.

Сегодня попытаемся разобраться кто есть кто в мире онлайн IT образования. Пост будет полезен как людям, которые хотят изучить какую-то технологию, так и разработчикам, которые хотят попробовать себя в роли... учителя, репетитора, преподавателя, наставника, ментора.

Учитель. Учит детей в школе. Поэтому, если вы хотите учить детишек писать код, вам туда🙃 Я не работал в школе и включил этот пункт исключительно, чтобы обозначить "потенциальную возможность".

Репетитор. Проводит индивидуальное обучение. Подразумевается, что репетитор будет нянчиться со студентом и изучать тему до тех пор, пока студент "не останется доволен". Спокойно относитесь к тому, чтобы на протяжении месяца разбирать тему циклов? Вам сюда. Потенциальные клиенты - это в основном новички без опыта в программировании, которые хотят выучить C++ быстро и желательно с минимальными затратами, или школьники-студенты с низкой мотивацией, которых привела мама. Как результат, стартовая ставка в час критически ниже, чем у преподавателя и ментора. Стоит рассмотреть, если у вас нет опыта разработки, но вы студент профильного it-вуза, либо как один из способов развития личного бренда.

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

Ментор. Через свой опыт помогает менти в достижении его целей. Цель запроса к ментору может быть абсолютно разной: от "разобрать арифметику указателей" до "подготовить резюме" и "пробить потолок 300к". Ментор в отличие от преподавателей и репетиторов не разжевывает тему, а указывает на пробелы в знаниях студента и прорабатывает со студентом путь к преодолению проблем. Опыт разработки обязателен. Я занимаюсь менторство уже более двух лет и мне нравится эта деятельность по двум причинам:
- нестандартные запросы, с которыми действительно интересно работать. А не вот это вот в 100 раз "помогите мне решить задание с шифром Цезаря" (пасхалочка для моих бывших коллег из Skillfactory)
- возможность помогать менти в достижении их целей. Особенно, если цель - это офер, а менти без опыта в IT=) Работу в онлайн школах я могу сравнить со случайным прохожим, у которого студент спросил, как дойти из пункта А в пункт Б. "У красного здания повернуть направо". Дойдет студент до цели - не понятно. Ментор - это навигатор: тут поверни направо, а вот тут сэкономим пару месяцев твой жизни и пройдем коротким путем, ты у цели, поздравляю, маршрут окончен😎

Наставник. Да, это перевод слова "ментор". Но в онлайн образовании используется несколько в ином контексте. Наставник прикрепляется к курсу, потоку или стажировке и выполняет роль человека, к которому можно обратиться за помощью в решении технического вопроса, составлению резюме или в целом за порцией мотивации. Я несколько раз занимал роль наставника. Последний раз это была на стажировке в НТР. По окончанию стажировки более 70 % моих студентов получили офер от НТР. Не исключаю, что это совпадение, но воспоминая все равно приятные🙂

Перед тем, как разобрать, что такое live lock, вспомним, что такое dead lock.

Deadlock bug на простейшем примере
Два потока захватывают мьютексы в разном порядке. Это может привести к ситуации, что планировщик запустит на выполнение поток 1, поток 1 захватит мьютекс 1, после чего планировщик приостановит выполнение потока 1 и запустит на выполнение поток 2. Поток 2 захватит мьютекс 2. Независимо от того, какой поток будет выполняться дальше, программа зависнет, т.к. потоки будут ждать разблокировки мьютексов (поток 1 - мьютека 2, поток 2 - мьютека 1), которая никогда не произойдет.

#include <iostream>
#include <thread>
#include <mutex>

void thread1(std::mutex& mutex1, std::mutex& mutex2)
{
std::lock_guard<std::mutex> lock1(mutex1);
std::cout << "Thread 1 acquired mutex1\n";

std::lock_guard<std::mutex> lock2(mutex2);
std::cout << "Thread 1 acquired mutex2\n";
}

void thread2(std::mutex& mutex1, std::mutex& mutex2)
{
std::lock_guard<std::mutex> lock2(mutex2);
std::cout << "Thread 2 acquired mutex2\n";

std::lock_guard<std::mutex> lock1(mutex1);
std::cout << "Thread 2 acquired mutex1\n";
}

int main()
{
std::mutex mutex1;
std::mutex mutex2;

std::thread t1(thread1, std::ref(mutex1), std::ref(mutex2));
std::thread t2(thread2, std::ref(mutex1), std::ref(mutex2));

t1.join();
t2.join();
}

Fix dead lock bug
В современном C++ баг, описанный выше, исправляется с помощью использования std::scoped_lock

#include <iostream>
#include <thread>
#include <mutex>

void thread1(std::mutex& mutex1, std::mutex& mutex2)
{
const std::scoped_lock lock(mutex1, mutex2);
std::cout << "Thread 1 acquired mutex1 and mutex2\n";
}

void thread2(std::mutex& mutex1, std::mutex& mutex2)
{
const std::scoped_lock lock(mutex1, mutex2);
std::cout << "Thread 2 acquired mutex1 and mutex2\n";
}

int main()
{
std::mutex mutex1;
std::mutex mutex2;

std::thread t1(thread1, std::ref(mutex1), std::ref(mutex2));
std::thread t2(thread2, std::ref(mutex1), std::ref(mutex2));

t1.join();
t2.join();
}

Больше технических постов тут t.me/neverending_cpp

Мэтт Вайсфельд "Объектно-ориентированный подход". Автору удалось осветить в этой книге практически все темы, касающиеся ООП, и сделать это всего лишь на 250 страницах (!): разбор принципов ООП на примерах, рекомендации по проектированию классов, извечный вопрос применимости множественного наследования, разбор принципов SOLID с внятными примерами и даже паттерны! Притом качество и глубина изложения материала не пострадала. Книгу можно читать как новичку, так и разработчику с опытом. Новичок получит в ней ценные ориентиры для дальнейшего углубленного изучения ООП, разработчику с опытом книга поможет упорядочить свои знания или подготовиться к ООП-нагруженному собеседованию.

Технические посты тут t.me/neverending_cpp

Я надеюсь, что да, но на всякий случай приведу несколько распространенных рекомендаций по оформлению коммитов. Если я что-то упустил, жду вас в комментариях.
🔹Длина заголовка коммита не должна превышать 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