А ще там на днях #Python 3.12 релізнувся. Особисто для себе я багато цікавого не знайшов.

Наразі найкращим, що було за останній час, досі є pattern matching з 3.10.

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

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

Тож якщо ви про це не чули, або не задумувалися, то може це саме час. 😁 Бо кількість запитів на друк росте куди швидше кількості друкарів.

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

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

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

Якщо раніше я рекомендував уникати префіксів в назвах класів, то чимдалі переконуюся, що з цього треба робити саме правило. Я про оті всі ваші 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», а щось глибше, як-от «короткі назви всередині ліби — повні назви зовні».