Cіпласпластик

На жаль піти на свята з відчуттям відсутності незакритих питань не вийшло все одно. Клієнт, якого я просив десять разів підготувати всі документи заздалегідь і якому я надіслав реліз-кандидат заздалегідь, декілька днів після фінального делівері мовчав, потім в останній день написав «I'll confirm the acceptance today» (замість просто «accepted, bro» — в чому сенс взагалі?!), а потім авжеж не написав, поставив авто-реплай та пішов у відпустку до середини січня 🤡 Врешті надвечір він-таки згадав, написав мені в зовсім інший імейл-тред, мовляв, ось тобі підписаний delivery protocol, та прикріпив до листа старий файл за жовтень 🤡🤦 Повнісінька зневага до праці інших людей. Не робіть так.

Скільки часу треба, щоб побудувати ефективну команду? У нас на це пішло близько трьох років. (Насправді менше, я думаю, але «докази» у вигляді чітких результатів зʼявилися тільки зараз). Більшість з цього часу ми працювали над одним продуктом, який виростили фактично з нуля до дивовижного рівня. Але кожен реліз у нас затримувався на 2–3 тижні відносно плану, і це трохи дратувало. Ретроспективно я бачу, що скоріш за все наші естімейти завжди були плюс-мінус вірними, але затримка, що виникла одного разу, далі просто переносилася з майлстоуну в майлстоун, хоча варто було просто хоч раз докинути ці два — три тижні в план та виправити зсув. Втім нещодавно нам випала нагода зробити ще один новий продукт з нуля у вельми стиснуті терміни — за три місяці. По естімейтах ніби все виходило ок, хоча план і був доволі щільний та амбіційний. Ми почали на тиждень пізніше, бо знов затрималися з попереднім проєктом, а скінчили десь на тиждень раніше! Дуже приємно хоч зрідка щось встигати до дедлайнів 😅 Користуючись нагодою, до вашої уваги найкоротший майстер-клас з естимації:

Домножуйте початкові числа на півтора, а краще на два 😉

Командо, якщо ви це читаєте, то дякую ще раз за чудову роботу та приємне спілкування 😊 Пишаюся вами та всім, чого ми разом досягли! (І шкода, що з нового року наші шляхи розходяться. Але це не вперше, тож може ще зійдуться назад).

Всі, мабуть, вже давно в темі, а от я тільки нещодавно відкрив для себе таку штуку як SponsorBlock. Це таке розширення для ютубу, яке дозволяє одним людям помічати на відосах відрізки з різним офтопом, рекламою та рекомендаціями, «тисніть палець вгору, підписуйтеся на канал», опенінги/ендінги/титри тощо, а іншим (або тим самим) людям — цим всім користуватися. Наприклад, автоматично чи вручну пропускати. Типовий краудсорсинг короч. На скріншоті вище як раз показано, як хтось позначив «основну частину» в доповіді про C++ довжиною в годину 😂 Користуйтеся короч, але памʼятайте, що якщо вам реально подобається зміст відео, то краще справді хоча б поставити 👍. Бо це реально підтримка. У них там конкуренція по метриках — жах ) (Та й тут уподобайки нікому не завадять до речі!)

Якщо раніше я рекомендував уникати префіксів в назвах класів, то чимдалі переконуюся, що з цього треба робити саме правило. Я про оті всі ваші vstring, CString, TString (хто памʼятає?), QString тощо, але не тільки про них. Підозрюю, ця згубна звичка пішла з тих часів, коли мови програмування були значно примітивнішими, але вже майже чверть XXI сторіччя позаду, альо. Всі(?) використовувані в сучасному програмуванні мови мають засоби для скоупінгу імен на кшталт неймспейсів, кваліфікованих імпортів тощо. Отже, на прикладі нашої поточної проги для мультимоніторного слайд-шоу (ну, що замовили…): є, значить, у нас модель дисплеїв, доступних в системі. Як вона називається? DisplayModel авжеж. Нормальна лаконічна та зрозуміла назва. Для цієї моделі є відповідна вьюшка, яка створює для кожного елементу моделі делегат. Вгадайте назви? DisplayView та DisplayDelegate, ага. Нє, ну а шо. Ще є DisplayInfo, DisplayIdentificationOverlay і тому подібне. Мій перший ментор казав, що

якщо щось повторюється двічі, то варто було б вже замислитись, а якщо тричі — то обовʼязково треба якось узагальнювати.

Якщо мова про C++, то можна зробити namespace, і тоді в найгіршому випадку назви будуть: Display::Model, Display::View, Display::Delegate, тобто всього на два символи : більше — а в найкращому можна зробити по місцю використання using namespace Display, а далі просто писати Model, View та Delegate. Зазвичай в книжках не рекомендують писати using namespace, бо новачкам легко налажати, але при зваженому використанні це дуже корисна конструкція. Наш поточний підхід полягає в тому, що в cpp-файлі з реалізацією класу ми прям одразу пишемо using, або в деяких інших місцях в тій самій бібліотеці, але не в інших місцях використання. Іншими словами, якщо ти в контексті предметної області, то можна писати короткі імена, а якщо зовні — то повні. В #QML того самого можна досягти за допомогою qualified imports. Наприклад, маючи модуль під назвою display, можна імпортувати його в глобальний скоуп імен через import display і писати всюди Model, View та Delegate, але QML трохи всратий в цьому плані, бо дозволяє… ммм… to shadow (затіняти?) імена з раніше імпортованих модулів і навіть не пише ворнінг. Тож краще одразу імпортувати як import display as Display або навіть import display as D, якщо надто впадлу, і тоді імена компонентів перетворюються на D.Model, D.View та D.Delegate відповідно. Що маємо в результаті? По-перше, відсутні тавтологічні назви а ля Display::DisplayModel, в яких немає жодного сенсу, по-друге, потенційно писати менше, бо можна користуватися коротшими назвами доти, доки (по-третє) не буде конфліктів імен, які легко вирішуються повними назвами. Недоліки також є: треба трохи більше контролю за тим, що, де та як писати. В ідеалі авжеж хотілося б мати тулзу, в яку можна зашити всі свої правила іменування та організації коду, причому не тупі банальності на кшталт «змінні з маленької, класи з великої» або «camelCase, а не snake_case», а щось глибше, як-от «короткі назви всередині ліби — повні назви зовні».

Завжди мріяв про монітор на електронних чорнилах. І вже пʼять місяців у мене такий є. Розписав деякі неочевидні нюанси отут. Якщо раптом у вас є запитання, лишайте їх в коментарях.

Інколи навіть в лінуксі можна побачити щось прийнятне на вигляд. На днях натрапив на тайловий композитор під Wayland — Hyprland. На плюсах написаний, до речі.

Зробили з друганом лібу на С++ та байндінги для #QML, щоб керувати Elgato Stream Deck напряму без їхньої офіційної апки (ну й емулятор також на випадок, якщо фізичного пристрою немає). Точніше як зробили… Здебільшого він зробив авжеж, але мені як менеджеру теж можна хизуватись, я вважаю 😇 В імплементації протокола надихалися лібою на Python, яка в свою чергу списувала у ліби на Node.js. Так і живемо 🤷‍♂️ Поки що немає, що ще показати, але як буде більш-менш стабільним, скину посилання.

Тру сторі. (Я належу щонайменше трьом категоріям).

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

You are in the middle of a refactoring session and your boss comes in and demands that you fix something immediately. You might typically use git-stash to store your changes away temporarily, however, your working tree is in such a state of disarray (with new, moved, and removed files, and other bits and pieces strewn around) that you don’t want to risk disturbing any of it. Instead, you create a temporary linked worktree to make the emergency fix, remove it when done, and then resume your earlier refactoring session.

Я бував в подібній ситуації неодноразово. В деяких випадках я навіть просто робив другий клон рєпи, хоча це не завжди зручно, особливо коли вона важить 20+ ГБ 😅 Користуйтеся на здоровʼя. #TIL

Але ще цікавіше — їхній, з вашого дозволу… кхм…, instrument cluster. Та й не тільки їхній, а в цілому на мотоциклах здебільшого. Чого вони всі виглядають, наче NFS: Underground вийшла вчора? Я ще розумію, коли подібне робили на багатосегментних дисплеях, але ж зараз це тупо піксельний екран — малюй там, що хочеш. Я б попрацював на проєкті HMI для мотів, ех. (А то забагато там механічних контролів, час переходити на тач ггг). Хоча у мене на Хонді до речі вельми непогано візуально виглядає, проте, по фічах нуль.

О, а оце вже точно цікаво. Kawasaki зробила гібридний мот 🙂🏍 з двигуном на майже півлітра та мотором на 9 кВт (мені це ні про що не каже, але може хтось шарить). Кажуть, наче, пального має витрачати як 250cc, а від нуля до сотні жене наче літровий. (А ще назад може їхати 😍). Кавасакі мені не подобаються. Памʼятаю, керував якимсь Ninja на 400 кубів, і вражений не був ) Але сам тренд з гібридами цікавий. Тільки не розумію оцієї теми з використанням пального. Дивишся автівки такий, а там пишуть: споживання 1,1 л / 100 км. І спочатку думаєш: «WTF?» — А далі авжеж одразу: «А-а-а-а, plug-in hybrid…» — Так ось запитання: а чого електрику не враховують ніде, наче вона безплатна? ) Писали б краще вже, скільки воно жере, коли батарейка в нуль.

Як довго працюєш над чимось, то зазвичай око замилюється, і стає важко раціонально оцінювати результати праці. Це актуально, мабуть, для будь-чого, де критеріїв для оцінювання або немає, або вони дуже складні: мистецтво, програмування тощо. Тож зрештою думка трохи підмагнічується чи то до «все лайно», чи до «наскільки ж офігенно». Час мені автівку нову брати, тож думаю, чи не взяти собі щось трохи дорожче цього разу, ніж моя Куга. Пішов дивитись Мерседеси, бо дарма ми MBUX робимо вже 9 років чи шо? (Хоча я особисто цим вже два роки не займаюсь безпосередньо). Коли бачиш систему щодня, катаєшся на S-class та EQS задля тестування та переймаєшся за фічі, які треба заделіверити вчасно, то фокус з простого користування зміщується в професійний бік. А тут сів в GLC, потикався, замислився над повсякденним використанням. Інтерʼєр безперечно крутезний, інфотейнмент-система наша дуууже крута — тупо найкраще, що є на ринку — дуже швидка й красива. Звук в моєму Форді взагалі в порівнянні наче годинник «Montana» проти студійного запису 😂 АЛЕ! Я раптом збагнув, що окрім навігації у своєму автомобілі я здебільшого користуюся ще двома крутилками: гучність та температура. І все. А тут клімат повністю сенсорний на тачскріні, а гучність — маленький тачбар справа під екраном, причому + та − навіть не реагують на натискання чи дотик — тільки на свайп. І коли гучність регулюєш, то на екрані зʼявляється слайдер, але без циферок )) Ми з дружиною звикли, що коли разом їдемо, то ставимо на 6–7, щоб і музло норм чутно було, і поговорити можна. Коли я сам їжджу, то на 9 ставлю. А тут тупо слайдер. Ну добре, годі про «преміальний» GLC. Сіли потім з дружиною в «бюджетний» GLA — і це зовсім інша справа! Нормальні хардварні контроли. І коштує на 30к євро менше 😅 Так, я розумію, що різниця між ними не тільки в цьому, але що важливіше обʼєктивно: дрібнички, які дратуватимуть щоразу, як сідаєш за кермо, чи ті пів секунди при розгоні від 0 до 100? В GLA навіть ручки на дверях зсередини зручніші ) Дуже дивні відчуття.

‍Хочу вам розповісти за “ДрукАрмію”. Це дуже крута ініціатива з 3д-друку різних невеличких конструкцій, які потім використовуються в армії і навколо. У них є лендінг з прикладами і розрахунками економії. В мене ще є розповіді про приблизно такі самі гроші, але про дрони — проте не вистачає даних, щоб тут описати. В мене вже кілька друзів долучилося — і здається, що такий умовно кустарний підхід має сенс має сенс, бо поставити друкування на поток і зробити індустріальним виходить дуже дорого: місця займає багато, друкує довго і потребує обслуговування. А коли ти робиш це сам вдома, то воно стоїть собі у куточку і сильно багато часу не займає. :) А ДрукАрмія - це маркетплейс фактично, зв’язує виробництво (вас) і покупців (військових), просто без грошей. Тож якщо ви про це не чули, або не задумувалися, то може це саме час. 😁 Бо кількість запитів на друк росте куди швидше кількості друкарів.