Натрапив вчора на GitButler. Автори його називають ґіт-клієнтом з можливістю «працювати в декількох гілках одночасно». І якщо позбутися мішури на кшталт фенсі UI та ШІ-шки, що пише за вас коміт-меседжі, то виникає підозріле відчуття дежавю. В Меркуріалі, який на відміну від ґіта мені завжди подобався, вже була схожа штука під назвою mq. Це щось схоже на ґітовий стейджинг, тільки багаторівневий, адже дозволяє робити цілі ланцюжки окремих маленьких патчів.

Інколи замислююся, чому перемогли C, а не Pascal (або LISP 😱), Git, а не Mercurial, тощо, і яким би був світ, де лідерство здобули зручніші тули, зроблені для людей, а не кулхацкерське лайно для вийобщиків з великим его. А ви як вважаєте?)

Буває, якийсь сервіс змушує зареєструватися чи просто вказати свій імейл, а свою основну адресу лишати абиде не хочеться. Я раніше користувався https://mailforspam.com для цього — там просто вказуєш будь-яку адресу в домені на кшталт foobar@mailforspam.com — і воно вже здатне приймати пошту. Але деякі сервіси почали блокувати по домену 🤬

Тож я перейшов на https://temp-mail.org: той цілі рандомні адреси генерує разом з доменом, котрих вочевидь обмежена кількість, але підозрюю, що достатньо велика. Я прям через телеграмного бота @TempMail_org_bot користуюся.

Впевнений, ви знаєте якісь ще альтернативи. Може щось зручніше є?

Я інколи кажу, що C++ — це хороша мова з поганими дефолтами. Маю на увазі, що мова дуже потужна і дозволяє робити купу всього, але програміста при цьому примушує тримати купу деталей в голові, щоб не схибити десь.

Нюанс полягає в тому, що мови з хорошими дефолтами я поки не бачив, хоч деякі з них намагаються виправити бодай якусь маленьку проблему, що вже непогано. Як в тому ж #Rust зробили, щоб всі «змінні» стандартно були константами. Воно ж і логічно, ні? Як часто вам насправді треба мати мутабельні змінні? З поточними практиками — дуже рідко, бо через вплив ФП ви найімовірніше просто позначаєте якесь проміжне immutable значення окремим імʼям. Але в C++ для оголошення константи програмісти мусять окрему роботу виконати — написати const. Легко забути та скіпнути? Легко.

Або додали ось в C++11 атрибути, зокрема [[nodiscard]] в C++17. Якщо функцію таким позначити, то компілятор «заохочується» 😆 видати попередження, що треба щось зробити зі значенням, що повертається. І як виявилося, подібним атрибутом можна позначити конструктор 🤯 «Навіщо?» — спитаєте ви. Я теж не одразу второпав.

Є у вас, наприклад, так званий mutex guard — така штука, яка локає мьютекс при створенні та автоматом анлокає його при виході зі скоупу (при знищенні). Як std::lock_guard, ага. Використовується наступним чином:

{
  const mega_guard lock{mutex};
  // ...
}

Річ у тім, що можна хибно написати ось такий код, і компілятор вам жодного слова не скаже:

{
  mega_guard{mutex}; // не lvalue, тож одразу знищується, звільняючи мьютекс
  // ...
}

Короч, як ви вже здогадалися, щоб уникнути останньої проблеми, можна позначити конструктор як [[nodiscard]]:

class mega_guard {
public:
  [[nodiscard]] explicit mega_guard(mutex &);
  // ...
};

Логічно? «Логічно»! 😅 Але чому це не стандартна поведінка? Ніхто того не зна. Як часто ви пишете функції, які повертають значення, яке можна ігнорувати? Нащо тоді вони його повертають? А як часто ви пишете класи, екземпляри яких ніяк не використовуються? Чисто заради сайд-ефектів чи що?

У #Nim теж так подумали й зробили всі значення non-discardable, причому компілятор одразу помилку пише, а не попередження:

proc sum(x, y: int): int =
  result = x + y

sum(3, 4)  # Error: expression 'sum(3, 4)' is of type 'int' and has to be discarded

І щоб виправити це, треба буквально сказати йому, що значення вам не потрібне:

discard sum(3, 4)

Круто, еге ж?
Вирішив пошукати, в яких ще імперативних мовах таке є, і виявилося, що в жодній! #Zig та #Swift нібито попередження видають, але це не точно. А ще в #Rust є схожий пропоузал. Чому ніхто цього не робить? Є ідеї? )

Короч, я все-таки успішно перейшов повністю на #Nushell. Користування ним реально прискорює мені деякі речі, але не тому, що він там працює якось швидше або дозволяє зробити те, чого не дозволяє зробити #Bash, а просто тому, що я інтуїтивно значно швидше знаходжу спосіб досягти своєї мети саме в ньому.

Я виріс на #DOS та #Windows, тож мене вся ця ваша #unix-ідеологія завжди трохи піддратовувала: зокрема через лицемірність щодо того, наче краще мати на кожну маленьку дію окрему штуку, яка її виконує і яку можна легко компонувати з іншими такими штуками, але на практиці у нас є десяток команд, зате в кожній по сотні --ключів. Ну короч, не зміг я себе змусити цим користуватися.

А ось Nushell залетів аж бігом, бо він дуже схожий на мови програмування, якими я й так користуюся. Врешті, як відомо, інтуїція = знання + досвід. Ну й оперувати структурованими даними завжди приємніше, ніж масивом неструктурованого тексту.

Були авжеж і труднощі. Найголовніше: про Nushell ніхто не знає 🙂 Тож якщо вам треба якось інтегрувати собі #pyenv чи може #homebrew, то доводиться робити це вручну (а для цього інколи доводиться читати bash-скрипти 😭), але в принципі у мене працює все, що мені було потрібне.

І ВСЕ Ж! Найкорисніше покращення, що я колись впроваджував у термінал, насправді працює в будь-якому шелі:

alias учше=exit

Не дякуйте )

Добре, а чи знає хтось якісь українські канали в телеграмі на теми програмування та будь-які дотичні?

У мене наразі аж пʼять є. (Не реклама, бо… не смішіть, яка тут реклама з моєю кількістю підписників). Персональна рекомендація короч:
- @bitethebyte (коли я був молодим та зарозумілим «23-річним сіньйором», цей тіпок вже парив на конференціях щось розумне; ex-CTO kasta.ua).
- @decomplexifier (це я хз хто, але мабуть теж хтось розумний; наразі неактивний щоправда).
- @re_with_arch (теж хз: різко зʼявився та різко зник в телеграмі — давно нічого не пише).
- @VW_Tooltips (ніби земляк, тобто з Харкова).
- @xanf_dev (тямущий тіпок з мого універа; на українську Ілля на жаль не перейшов, але робить свій внесок інакше).

Ще є отакий про суміжні теми: @business_ua. Я підписаний, хоча не читаю.

Якщо ви знаєте ще якісь, напишіть в коментарях будь ласка. Я б підписався, бо нема чого читати, а discoverability в телеграмі — суцільне лайно. (Ще б десь повідсвічувати своїм їб… каналом також, бо якось… 😞).

Якщо англомовні є (але не від росіянців), то теж давайте.

Microsoft не була б Microsoft, якби все було так легко. Як виявилося™, прога, що має вирішувати питання надання «безумовного» доступу, сама по собі не є доступною без окремого запиту з боку користувача )) Шукатиму спосіб, як це зашарити на всіх 😩

Зненацька натрапив на переклад книги «Learn You a #Haskell for Great Good!» (також відомої як LYAH) українською 🇺🇦. Я читав її двічі й досі вважаю найкращою книгою з хаскелю для початківців (чого на жаль не можу сказати про аналог для ерлангу). Той, хто знає мене довше, ніж 10 років, гарантовано чув про неї теж, бо я всіх тоді хаскелем запарив ))

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

Офіційний сайт перекладу тут, а оригіналу — тут.

“Our displays redefine the meaning of rapid” 😂

Про оптимізацію та шнурки (хто ще вам про таке розкаже?)

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

Комусь подобається оце сидіти два тижні, щоб вичавити ще пʼять мілісекунд з алгоритму, тоді як краще фічей зробити чи багів пофіксити. (Хоча я можу тиждень намагатися видрочити pixel-perfect UI або анімацію — чи це краще? 🤓). З іншого боку є ті, хто не париться взагалі. І потім отримуємо вебсайти Адідаса або, господи пробач, Самсунга, на яких навіть якщо ду-у-у-у-уже захотіти, то не завжди вдається щось купити, бо нерви вже не витримують.

Тож я б радше покладався на якісь бізнес-метрики, вирішуючи, чи треба щось оптимізувати. В побуті, щоправда, у мене таких нема. Зате є метрика «Та якого біса!», й коли воно накопичується, я починаю свідомо обмірковувати можливі покращення.

Наприклад, ми років 10 користувалися звичайним таким металевим кругленьким чайником зі свистком, щоб воду гріти, бо він няшний, хоч купляли його ще для газової плити. Відтоді змінили 4 квартири в 3 містах та навіть країну проживання змінили, а чайник — ні. І ось терпець урвався врешті (бо не газ давно), та я купив звичайний електрочайник, оптимізувавши час очікування (та витрати енергії) рази в три.

Але буває так, що подумати над оптимізацією якогось процесу навіть не спадає на думку. Як-от зі шнурками на взутті 😵‍💫 Ми з дружиною плюс-мінус однаково їх завʼязуємо, але у неї вони розвʼязуються самі по собі разів у 5 частіше 🤔 Погодьтеся, це не та проблема, до якої застосовуватимеш 5 whys в звичайній ситуації. Ну, може, я затягую сильніше, або може матеріал різний, хз навіть — подумав і забув, еге ж?

Але виявляється, що у звичайного «класичного» вузла є дві версії: сильна та слаба 🤯 Це справді працює: позбавляє роздратування без реєстрації та смс )) Але якщо вже взялися оптимізувати, то можна піти далі.

В інтернеті є чувак на імʼя Іен (швед, мабуть), який прям спеціалізується на різних видах шнурівок — вже 25 років їх збирає. Ви точно натрапляли на його кольорові діаграми хоч раз, бо їх всі крадуть. Памʼятаю, як ще, може, в 2005-му по них конверси по-позерські шнурував.

Виявляється №2, що не всі шнурівки суто декоративні — деякі дозволяють завʼязувати взуття значно швидше! І вже декілька років перше місце в загальному рейтингу серед всіх різновидів посідає Ukrainian lacing 🤝!

Ні, цей метод не є якоюсь загальновідомою українською спадщиною. Просто його придумав років 8 тому українець Віталій Гнатенко та назвав на честь України.

У мене на сьогодні все )

Натрапив на новий для себе редактор C++-коду — 10x. Платний, тільки під Windows, має вбудований парсер плюсів, інтеграцію з Perforce 😱 (вочевидь писався під геймдев) і виглядає доволі швидким.

Може колись спробую, якщо повернуся на вінду, а поки просто додам у #тулзи.

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