Эффективный метод подготовки к ревью

Juks, после прочтения статьи и Ваших комментариев появился какой-то диссонанс.

С одной стороны вы говорите:

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

С другой стороны, у вас есть такие заходы:

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

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

Если сложить дважды два в Вашей интерпретации, то получается, что "Эффективный метод подготовки к ревью" это должны быть немного другие принципы:

• не будь морально/материально должен;

• будь тем, на ком держится весь проект и периодически намекай, что покинешь проект (не обязательно увольняться, можно переместиться горизонтально/вертикально);

• дружи с "правильными" людьми и организуй "клики" (группы) с коллегами по принципу с кем дружим; против кого дружим;

• и т.д. всё по классике корпоративных войн.

Или всё не так? Скорее всего, список "эффективных" методов намного длиннее. Использовали ли Вы такие методы (всё таки 5 лет - это серьёзно)? Какой эффект?

И, возможно, отдельная статья про принципы "эффективного взаимодействия с системой оценки 360 градусов" будет более полезна?

И да, всё выше написанное - это сарказм. Это же очевидно?!

std::launder: зачем и когда нужен

Сарказм:

Ну вы же на С++ пишете! Откуда такое пренебрежительное отношение к Idle?:

struct Idle { /* … / };

struct Busy { int job_id; / … */ };

...

alignas(Busy) std::byte buf[sizeof(Busy)];

Хотя бы минимальную защиту от дурака:

static_assert(sizeof(Idle) <= sizeof(Busy));

если лень с максимальным размером возиться.

Мало ли какие программисты в будущем будут? Захотят в Idle сохранять состояния пяти предыдущих Busy?

---

Не-Сарказм:

За статью спасибо! Эти постирушки ... они такие, что чёрт ногу сломит!

Современный C++23/26: концепты, корутины и многое другое в высокопроизводительных службах

Уточнюсь:

Потому что это перевод!

Это проблема не перевода (как можно подумать). Это проблема другого автора и профессия переводчика.

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

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

Поэтому:

Про неточности: делаем разбор и обсуждение в комментариях.

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

Современный C++23/26: концепты, корутины и многое другое в высокопроизводительных службах

Потому что это перевод!

Там и про корутины немного странно:

кооперативную многозадачность

обработка событий в режиме реального времени

по-моему слабо сочетаются. Вообще, реальное время на несколько событий очень хорошо дружит как раз с обычными потоками (хотя и получается поджирание ресурсов), ну или уже код запускать в ядре ОС (модули ядра и т.п.).

В общем - это перевод.

Возможное расширение языка C++ операцией скалярного произведения

По-моему, в текущем виде это всё очень притянуто за уши и слишком "местечково": если слева от "=" - то итерируем, если справа от "=" то что-то итерируем-складываем. Т.е. в одном случае одномерное остаётся одномерным, а в другом случае одномерное становится скаляром.

Возможно, выходом было бы отделить итерирование от всего остального. Например, ваш пример:

C[>i][>j] = A[i][>k] * B[>k][j];

Превратить во что-то:

C[>i][>j] = SUMM(A[i][>k] * B[k][j]);

Какие отличия:

• явное задание количества "итерирований": есть по i, j, k - по одной штуке. У B[k][j] своей итерации нет;

• результат A[i][>k] * B[k][j] - это одномерный массив (так как всего одна итерация по k) из результатов умножений;

• функция суммирования SUMM задаётся явно, принимает массив чего-то, возвращает сумму. Технически сюда можно и пользовательские функции затолкать.

Как результат, получаем в целом компактную запись с отработкой всяких случаев, когда элементами массивов являются разные штуки (условно: структуры, которые можно умножать и складывать).

Также, отдельно лучше/придётся продумать, когда индексы не-числовые: например, когда значениями индекса являются строки (или другие абстрактные ключи).

Один за всех, и этого достаточно: мой эзотерический язык программирования Single

Ну, если уж следовать "[мар|сарк]азму", то есть пара вопросов к новому языку:

• как предполагается мёрджить изменения из разных веток. Т.е. Вася Пупкин в условном git-е сделал бранч и добавил функционал. И Маша Старцева тоже сделала свою ветку (задача сама себя не сделает, так ведь?) и также добавила функционал. Как это мёрджить? Как минимум нужен либо плагин, который выравнивает куски кода, либо делать разбиение на строки. Но тогда нужен какой-то стайлгайд! Не думали об этом?

• Как предполагается вести отладку работающей программы? Отладчик не планируете создать?

Почему вы любите плохие продукты

По-моему, вот здесь всё и зарыто:

Я убеждён, что изменения в продуктах (читай редизайны) это неизбежная эволюционная необходимость

Такое ощущение, что бизнесы меряются "длиной и толщиной".

Однако, у такого подхода есть и контрпримеры: например, мой браузер (firefox) периодически обновляется, но дизайн (на мой скромный взгляд) каким был - таким и остался. И пользуюсь им. И таких программ ... ну много их. Когда их обновляют для исправления ошибок - это нормально; когда делаются изменения ради изменений - это уже из разряда: "ну нам же нужно что-то продавать?!".

---

Сарказм: Поэтому статью нужно назвать:

Как управлять вселенной не привлекая внимание санитаров заработать бабла на втюхинге того, что никому не нужно.

Создание объектов без конструктора по умолчанию в C++: искусство владения памятью

Насколько понял, идеи, использованные в статье используются (и имеют смысл) только для pod (можно даже сузить до trivially_copyable) типов.

И тогда предлагаемое решение выглядит очень уж замороченным для "условной" десериализации данных.

По-моему, здесь напрашивается вариант с созданием экземпляра через один из штатных способов (конструктор с параметрами/фабрика и др.) и потом делаем копирование через memcpy или вычитывание из файла. И если тип is_trivially_copyable, то это штатно разрешено. В ином случае - вам это не нужно.

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

---

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

Геймдев и Менеджмент: почему зарабатывают GGG, Rockstar и CDProjekt

Немного сарказма:

Такое ощущение, что статья сама по себе, а вывод сам по себе. Читаем вывод:

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

Читаем статью и суммируем принципы успеха:

... Заняли ... атаковали ... пустую нишу ... создали новый рынок

На мой скромный взгляд, это та самая гениальность игры и креативность создателей. ?

Инвестировали в качество ... крутости продукта ... поддержки продуктов

можно, конечно, сказать, что качество как раз и относится к "удержанию аудитории" или это "принципы работы", но что-то мне подсказывает, что вы хотели сказать в другом ключе :)

Итак, что правильнее?:

Статья или Вывод?

---

Повторюсь, это сарказм.

Мы в ответе за тех, кого сгенерировали

Сарказм: про статью понятно; плюс реклама канала. Сущность (пардонь-те, сейчас много пишется от ИИ), которая рассуждает о минимизации мусора, и приглашает на свой канал чтобы ... видимо создать больше мусора.

Однако, если бы видосики были бы из vk/rutube/чтотодоступное - то было бы немного приятнее, хотя бы не нужно прыгать через три буквы.

Простая отрисовка емодзи в атлас из таблицы .ttf (NotoColorEmoji)

Сарказм: даже если оставить в стороне ваш очаровательный микс чистого Си и C++ (с чем связано?) и фатальную нелюбовь к обработке ошибок (например, даже при наличии файла вам могут его не дать открыть и тем более записать - по многим причинам), остаются вопросы по коду.

Пардонь-те, зачем такие изыски: сначала декремент указателя, потом инкремент?:

    data--;
    t[i].tag[0]=readu8(data++);
    t[i].tag[1]=readu8(data++);
    t[i].tag[2]=readu8(data++);
    t[i].tag[3]=readu8(data++);
    t[i].tag[4]='\0';
    data++;

Может слегка исправить возможный баг: переписать:

u8 readu8(u8 *tempN)
{
  u8 t=tempN[1] ;

  return t;
}

как:

u8 readu8(u8 *tempN)
{
  u8 t=tempN[0] ;

  return t;
}

Прим.: индекс изменить с 1 на 0.

По-идее должно быть легче и понятнее.

Или, как вариант, в этом подходе есть "верхний" смысл ... Не раскроете тему?

Онбординг, который выматывает всех. Как учить джунов с помощью ИИ

Основные непонятки по статье:

--- Подмена понятий:

Сотрудник выкатывает релиз без финальной проверки

Персонал не знает, как перезапустить расписание

Решили «сэкономить» на обучении 40 000 сотрудников

Вопрос: и причём здесь онбординг? Из поисковика: Онбординг (от англ. onboarding) — это процесс адаптации сотрудника в новой компании (прим. по п. 3: там обучение внешних сотрудников, и не новичков).

--- Подмена понятий:

ИИ уже сейчас неплохо помогает ускорить адаптацию и онбординг новых сотрудников

2. Назначаем ответственных

За задачей, как и всегда, должен стоять человек. А лучше — несколько.

Получается как в анекдоте: давай я понесу чемодан, а ты понесёшь меня.

--- ? Другая вселенная ?

Признавайтесь, сколько раз сегодня заходили в приложение своего онлайн-банка, чтобы поиграть в «5 букв»?

Ответ: Нисколько. Вообще не знал, что такое "5 букв" - пришлось спрашивать поисковик.

У нас точно одинаковые вселенные? А то что-то лор какой-то глючный.

Успешный проект

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

---

Посмотрел на бумажные источники: там про успешность вообще не говорят. В основном только про вхождение в требуемые рамки сроков/бюджета/качества(функционала). Развитие команды. В общем, про именно "успешность" там исчезающе мало.

---

Если поискать в интернете и явно отбрасывать "срок-бюджет-качество", то можно, например, найти (https://pm-way.com/materials/material/show/2):

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

и подобные утверждения явно не единичные.

Т.е. это некоторое "удовлетворение"; некоторых "заинтересованных сторон".

Поэтому, учитывая логичное предположение, что основные заинтересованные стороны это не только исполнитель и заказчик, лучше понятие "успешность" не использовать. Вообще не использовать.

---

Вот в проектном управлении любят "измеряемые" сущности - вот и используйте нечто "измеряемое"! А "успешность" - это совсем из другой оперы.

Как убить архитектуру за три спринта: практическое руководство

С одной стороны, статья соответствует заголовку (т.е. заявленным целям).

С другой стороны, она несколько однобока, так как (и это очевидно), в такие игры можно играть вдвоём.

Берём легендарную книгу "Путь камикадзе" легендарного автора Эдварда Йордона, открываем на условной 94 странице и начинаем читать.

Читать, что сроки работ нужно удвоить и добавить её чуть-чуть.

Или читать, что такое "китайская пытка водой": кап, кап, кап.

Если уж совсем смотреть реально: почему вы считаете, что

На исправление боли потратили огромное количество времени и по итогу вынесли логику на уровень сервиса.

это плохой результат (хотя из статьи можно сделать такое предположение)? Если бизнес устраивает сначала сделать на костылях, а потом переделать "по-нормальному" (хотя бы условно) - то кто мы такие, чтобы его (бизнес) переубеждать?

Проще нужно быть. Проще!

Экскурс в историю Agile и Kanban, или Топ 10 причин перейти на итеративно-функциональный метод

Конечно же, это всё сарказм ... в котором есть доля сарказма:

---

Интервью с издателем (сарказм):

• Итак, сегодня на дворе 2004 год и мы обсуждаем слегка устаревшую книгу "Управление программными проектами" Роберта Фатрелла, издание 2002 года (перевод 2004). Я понимаю, что уже прошло 2 года с момента оригинального издания, но всё же, что вы можете рассказать интересного о ней? Полагаю нашим слушателям это будет интересно.

• Это очень интересная книга, в которой описаны различные подходы к организации разработки ПО. Начинается всё, стандартно, с формализованного водопада (waterfall). Но есть и более современные методики.

• Например, какие? Что вы можете посоветовать нашим слушателям?

• Для начала можно рассмотреть "прототипирование" (для любопытных слушателей: глава 4, страница 144). В ней предлагается строить рабочую модель системы как макет или прототип. Сначала делается первая версия прототипа, потом она основании общего плана производится "доработка" макета: дорабатываются функции, базы данных и пользовательский интерфейс. Всё это основано на фазе "быстрого анализа", которая с учётом общего плана задаёт общий тон и направление разработки. Все доработки находятся на виду у "пользователя" и постоянно делается подгонка и утверждение решений с учётом эксплуатации.

• Отличная схема разработки! Правда у неё есть одна существенная зависимость: нужно работать с пользователем, постоянно делать подгонку. Есть какие-то другие процессы, которые не такие старые, как водопад (всё таки уже 2004 год на дворе!)?

• Конечно-конечно. Не всё же заканчивается на водопаде и прототипировании. Есть ещё такая хорошая модель: "инкрементная" (также для внимательных слушателей: глава 4, страница 155). В ней вы делаете небольшие доработки продукта. Каждая доработка это как обособленная функция: её может делать отдельный человек. Также допускается одновременная разработка нескольких "инкрементов". Естественно, это делается разными разработчиками. В целом, вся модель следует общему плану, по которому добавляется функционал - "инкремент". Причём в процессе нет явной связи с пользователем и можно создавать инкремент, который не будет законченным (готовым) решением, но позволит сделать другие, полезные пользователю функции.

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

---

Очевидно, сарказм: прошло больше 20 лет ... И?

Системные вызовы Linux, которые должен знать каждый разработчик

Согласен, я изначально ошибочно подумал, что речь именно про libc (которая при обсуждении python перепрыгивает на glibc). Но с упором именно на syscall становится вообще не понятно, для кого сей труд.

---

Первый заход:

Просто цитата:

Хотя функции malloc(), calloc(), realloc() и free() не являются системными вызовами напрямую, они работают поверх них. Эти функции — часть стандартной библиотеки libc, которая под капотом использует brk() и mmap() для выделения и освобождения памяти.

Второй заход:

Заходим сюда: https://syscalls.mebeim.net/?table=riscv/64/rv64/latest и смотрим на syscall-ы других архитектур, не x86-64. И ... там нет open! (э-э-э, openat2 ?).

---

В общем, очень чудесато.

Системные вызовы Linux, которые должен знать каждый разработчик

Если говорим про работу именно с файлами, то лучше указать функции fopen/fclose/... (в смысле: лучше, чем open/close/...).

---

Общее впечатление от статьи сильно двоякое:

• с одной стороны, знать такие вещи полезно (общее развитие и т.д.);

• с другой стороны, в продуктовой разработке (основной язык C++14 и позднее) пишешь код так, чтобы этих функций не было даже на горизонте. При любой возможности использовать stl / boost / др. уходишь в библиотеки. Причины такого подхода: стабильность работы, кроссплатформенность.

Сарказм:

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

IBM обязала сотрудников отдела продаж работать не из дома минимум три раза в неделю

Компания активно нанимает персонал в Индии, сократив наём в США.

Слава Боинга покоя не даёт?

Запретить нельзя использовать: о проблеме использования LLM при обучении инженеров-программистов

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

Как сторонний пример, рассмотрим управление автомобилем:

- более полувека назад умение управлять автомобилем подразумевало и хорошее знание механической части (условно-минимально: сам меняешь масло и тормозные колодки).

- сейчас управление автомобилем это (упрощённо) жмёшь педали и едешь. Если что-то не так - отправляешься на сервис.

- сейчас помимо массового пользователя автомобилем всё равно есть мастера/механики. И есть гоночные автомобили со своими мастерами и другие профессионалы. Однако, все эти мастера (в массе своей) начинали знакомство с автомобилем именно в виде: включил передачу/drive и нажал педаль - и оно поехало.

--

К чему этот опус?

Возможно, уровень "студент + LLM умеет писать что-то" принять как за базовый? А уже потом отрывать от сиськи LLM и учить вглубь? Ну не всегда же программированию начинают учить с отладчика?!

Да, Согласен, мысль местами странноватая, но аналогии для такого тоже есть. Не думали в таком направлении?

NVRAM из EEPROM

По-моему, в коде есть проблемы поболее, чем "затёртая до дыр" eeprom :(

Что с порядком байт: little-endian vs big_endian? (У вас little-endian);

Также, возможно, если предположить перенос кода на C++ (или вдруг в чистом Си расширят UB), то лучше не использовать запись в одно поле union и чтение из другого (type-pinning).