Не знав про існування таких звітів 👇 Прикольна штука, хоча й не зовсім по моєму профілю.

ISO C++ створили щорічне опитування пару днів тому (валідне буде тиждень всього).

Останнім часом на С++ тиск підсилився, бо той же Rust з memory safety підпирає. Доходить до того, що Страуструп вкотре виправдовується, мовляв, «нормальна безпечна мова — то у вас руки зі сраки».

Я в чомусь згоден, у чомусь — ні. Але ви подивіться на запитання. Наприклад, «що вас найбільше дратує в розробці на C++?» І у відповідях зокрема аж три окремі можливості зазначити, що «memory safety для мене не є проблемою» 😂 (А багатьом програмістам і справді пофігу, бо це ж не вони гроші втрачатимуть якщо що).

Або: «чи дозволено вам на роботі користуватися модулями з C++20?» Ну, дозволено-то дозволено, але ж вони не працюють нормально — підтримка компіляторами щось якось частково є, а білд-системи здебільшого не альо тощо.

C++ точно не помре найближчим часом, але хз навіть, які перспективи.

Ну ви-то більшість і не плюсисти мабуть взагалі. А я на C++ досі пишу тільки тому, що мені подобається робити UI на #QML 🙂

Є якийсь такий прикол у мене, що я завжди віддаю перевагу водонепроникним виробам та виробам з титану. Ну тобто якщо поряд будуть два пристрої, й один з них буде з титану або водонепроникний, або водонепроникний з титану 🤩, то я оберу його!

Це, мабуть, з тих часів пішло, коли я вирішив готуватися до зомбі-апокаліпсиса років 12 тому 😐 (Мені тоді ще складно було уявити, що zомбі на наші землі реально прийдуть).

Але як і в будь-якій справі, самих лише інструментів замало, треба і знання відповідні мати. Додатково збентежує той факт, що жодна людина у світі не знає, як зробити олівець. Тож я потроху собі почав хоча б якихось книжок збирати, ну там як парник для розсади зробити або про ті ж вузли. Без електроживлення, щоправда, від цих книжок користі буде не дуже багато. Втім на менш песимістичний сценарій може стати у пригоді.

І ось сьогодні — вже навіть не памʼятаю як — я дізнався про такий формат як ZIM, який призначений для збереження вебсайтів-баз знань на кшталт Вікіпедії чи Stack Overflow для офлайн-перегляду. А з моїм прагненням колись повністю перейти на local-first та self-hosted штуки, виглядає доволі цікаво. Є ось опенсорс-прога для завантаження та перегляду zim-файлів: Kiwix.

#TIL

Я усвідомлюю, що мені просто впадлу вчити #Rust, тож я й не вчу, але все одно лишалося це відчуття, що може весь хайп не з порожнього місця і що може варто було б звернути увагу.

Друган в коментарях до іншого допису вже наводив приклади, і ось зараз рєпа cve-rs нарешті закрила для мене це питання остаточно. Memory safety — це брехня, розходимося 😂

В плюсах доволі нерідко перевантажують метод залежно від того, чи сталим є сам обʼєкт, чи ні. Ну, наприклад, контейнер може оголошувати метод, що повертає ітератор на початок якось так (спрощено):

T* MyContainer::begin();
const T* MyContainer::begin() const;

тобто якщо обʼєкт сталий, то і вказівник повертає такий, через який не можна поміняти те, на що він вказує, а якщо обʼєкт мутабельний, то і вказівник теж.
(Якщо ви не в темі, то отой const, що після дужок, фактично відноситься до неявного this, який потрапляє в метод).

Але в QHash (хеш-мапа в #Qt) оператор для доступу до елемента по ключу, як ми сьогодні з друганами виявили в ході обговорення, якогось хєра оголошений отак:

T& operator[](const Key& key);
const T operator[](const Key& key) const;

На перший погляд, все ок 🙂 Окрім того незначного факту, що константний оператор якогось хєра повертає не const T& (тобто не референс), а const T 🤯 Іншими словами, воно щоразу те значення, яке ви дістаєте з хеш-мапи по ключу для читання, зайвий раз копіює.

Фішка в тому, що ніхто в C++ ніколи не повертає const T, бо це безглуздо. Повертають або просто T, або const T&. Тож я вангую, що це баг, про який компілятор вам ніколи нічого не скаже, бо з його погляду все в порядку.

Зайве нагадування про те, що всі ці бібліотеки, котрими тисячі або навіть мільйони людей користуються, пишуть не якісь суперпрограмісти, а такі ж посередні, як ми всі з вами 😎😂

Дуже подобається мені, коли домовляєшся, наприклад, про співбесіду, а тобі одразу кидають запрошення в календар, де і час заповнений, і адреса або посилання на онлайн-нараду.

Або домовляєшся відвідати лікаря чи там в банк зайти по кредит, а тобі гоп — інвайт на пошту.

Або бачиш новину про прийдешню конференцію, де написано: «Ось тоді-то й тоді-то відбудеться — save the date!». І хоп, кнопку тиснеш, завантажуєш ics-файл, щоб в календар собі швидко додати з усіма деталями.

І знаєте, хто так робить? Ніхто, блядь. Ну може 1 з 10 випадків буває, що хтось аж настільки «досвідчений». У решті ж — бери та створюй сам.

Причому ж у багатьох випадках людина «на тому боці» собі все одно цю подію в календар додає. Чого не заінвайтити просто? Не розумію прикола, короч 🙂 (Ну ок, може бути випадок, коли «внутрішній» івент містить у собі більше інфи, яку не хочеться шарити назовні, але все ж).

Інша популярна нині й у дечому зворотна тема — це Calendly. Там свій календар просто підʼєднуєш, а воно тобі створює сторінку, за допомогою якої інші можуть у твоєму календарі букати слоти. І це ок працює, коли ти хочеш до свого страхового агента прийти на консультацію, наприклад.

Але буває, що комусь щось треба від тебе, а не навпаки. Проте вона чи він тобі одразу фігак посилання, мовляв, «обери час, коли ти мені зможеш допомогти». В принципі нічого не маю проти, але тут варто усвідомлювати, що це один з психологічних гачків: ти власноруч заходиш на сторінку, щоб обрати таймслот для бесіди — інвестуєш свої зусилля фактично. А люди дуже неохоче втрачають інвестиції 🤑 Тож коли ти так робиш, то шанси, що ти погодишся допомогти, зростають (бо вже вклався часом). Звучить як дрібниця, але це реально працює 🙂

Тримайте одну з найперших же ознак, що менеджер(ка) не справляється зі своїми обовʼязками: вона чи він постійно спізнюється на наради або в останню мить їх скасовує, а інколи взагалі не приходить.

Чому мова саме про менеджерів, а не якихось програмістів? Бо причини різні. Програміст зазвичай спізнюється тупо через брак дисципліни, а керівник — або через нездатність керувати очікуваннями, або через нездатність керувати часом.

З дисципліною все просто ніби — «забув», «стало впадлу», «не хотів відриватися від роботи» тощо. З останнього сміюся найбільше, бо деякі програмісти досі думають, що їхня робота — це писати код.

Що маю на увазі під керуванням очікуваннями? Мені регулярно трапляється, що керівник вважає нараду опціональною для себе, бо думає, що й без нього все мусять порішати, а решта сидить та чекає, бо не можуть без нього рішення прийняти. Навіть топменеджерам це притаманно. Тут зазвичай неправильне делегування просто: коли обовʼязки делегували, а повноваження — ні.

З керуванням часом цікавіше трохи. (Мова про власний час звісно, бо ми тільки ним здатні керувати). Тут реальних причин трохи більше вже: відсутність делегування (призводить до того, що весь календар забитий нарадами), намагання «захистити команду» від зайвих нарад (ефект той самий, особливо початківці — «вчора програмісти» — страждають), недостатнє розуміння обовʼязків (тож ходиш усюди, куди запросили, щоб збагнути хоч щось), планування впритул (коли пріоритетніші та менш пріоритетні наради нон-стоп) тощо.

Для вирішення останнього MS Outlook навіть фічу має: коли плануєш подію на годину, він останні 10 хвилин відрізає та створює запрошення на 50 хвилин натомість, а якщо подія на пів години, то 5. Тільки це не працює безумовно, бо мало в календарі позначити — треба ще під час наради вміти сказати «ні» (в сенсі, що час вийшов і продовжувати не можемо). В решті випадків вміння казати «ні» теж би допомогло до речі, окрім першого хіба що.

Але найвідповідальніший момент, коли треба вміти сказати «ні» — це пропозиція підвищення 😱 Я не про гроші, а про позицію. Річ у тім, що зі зміною позиції ті обовʼязки, які треба виконувати, також можуть доволі сильно змінюватися, і в якийсь момент опиняєшся в позиції, де робиш те, що тобі не до душі, тобто займаєшся не сродною працею. Але на «пониження» ніхто не йде, тож в довгостроковій перспективі це призводить до того, що всі керівні позиції займають некомпетентні люди.

Але не поспішайте таврувати ваших менеджерів як некомпетентних 😅 Складність полягає у тому, що не завжди одразу зрозуміло, чи це простір для зростання, чи вже досяг власної стелі.

Я маю в голові приклади конкретних людей звісно, але найголовніший приклад — це я сам. Я був в усіх цих ситуаціях, з обох боків причому, і робив усі можливі помилки. І навіть маю власні приклади «даун-шифту».

Коли став тімлідом вперше, якось так втомився, що при зміні компанії повернувся в чисте програмування. Щоправда, як доволі швидко зʼясувалося, програмування перестало бути мені цікавим як процес для заробляння грошей, тож я знов пішов у менеджмент.

Іншим разом керував командою на 30+ людей декілька років. Було цікаво і корисно, але не моє. Все-таки найбільшу радість мені зараз приносять якісь маленькі затишні проєкти на команду до восьми людей плюс-мінус.

Знаю також людей (навіть серед моїх підписників є), кого я особисто дуже поважав у ролі менеджерів, бо реально круті, але вони повернулися до «чистого» програмування і з того часу не жаліються ніби 🙂

Отож, якщо ви постійно спізнюєтеся на наради, то може варто тойво…? ))

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

Це те, що називається культура компанії 😁

Просто подивіться оце ☝️

Я називаю себе програмістом, що інколи щось дизайнить, а мій знайомий є дизайнером, що інколи кодить (але обидва працюємо менеджерами 😅), і майже кожна розмова з ним додає мені якихось корисних інсайтів. Ось вчора він приніс мені відос.

Коли я кажу людям, що девелоперські #тулзи не мусять бути лайном, вони мені у відповідь:
🤪 «IDE не потрібна» 🤪 «я грепаюсь по логах» 🤪 «а що не так з гітом?» 🤪 «проєкт збирається всього лише за 40 хвилин на тредріппері» 🤪 тощо 🤪

Тим часом компанія з трьох людей, що робить дуже офігезні ігри:
• оновлюють асети без перезавантаження програми;
• компілюють код у файлі на 13к рядків(!) на кожне натискання клавіші(!!) та оновлюють його теж у рантаймі(!!!)
• у будь-який момент можна поставити брякпоїнт будь-де та пройтися по кроках вперед та назад!
• завдяки хот-релоаду кода, вони компілюють код для профайлінга за потреби вже на запущеній програмі;
• всі дії з моменту запуску програми зберігаються у повністю reproducible послідовність включно зі всіма рекомпіляціями та перезавантаженнями коду або ресурсів, яку можна переносити на інші компи, й воно працюватиме;
• можна тегнути будь-яке місце в коді якимсь додатковим контекстом (timestamp, наприклад), щоб потім швидко знайти саме те місце в коді та саме той момент часу, коли це трапилося;
• все це інтегровано з білд-системою та системою контролю версій.

Я хз, що тут ще додати. Мій поточний тулсет на тлі цього — це наче бричка з кіньми поряд з зорельотом.