Може буду інакше думати колись, але на разі - гарно проаналізовано і сказано про наш робочий час.
Три хвилини читати, може бути цікаво як інженерам, так і менеджерам
https://onengineering.substack.com/p/why-engineers-need-to-be-bored

Github викотив новий супер-пупер пошук по коду, кажуть, шукає вдвічі швидше, ще й розуміє контекст - можна шукати елементи конфігурації, наприклад, чи символи (змінні), які містять те, що ви шукаєте. Останнім часом цей інтелектуальний пошук та чатботи прямо усюди О_о.
https://github.blog/2023-05-08-github-code-search-is-generally-available/

Трапився текст від Martin Heinz про бібліотеки, яких, на його думку, не вистачає в стандартній бібліотеці. Не вистачає хлопцю (чи дядьку) батарейок, їх, звісно, багато не буває.

Для тих, хто хоче за 20 секунд, трішки прокоментую про що він пише:
1) boltons - набір інструментів для роботи з json, часом та ітераторами.iterutils.get_path виглядає прикольно - можна діставати значення по ключам з вкладених словників. Подібне, пам'ятаю, є в toolz.
2) Автор згадує more-itertools - назва говорить сама за себе, у тексті є посилання на огляд.
3) sh - альтернатива subprocess
4) validators - сюрприз, бібліотека з набором валідаторів. Виглядають досить прямолінійно і прагматично. Майбуть, може замінити ваші пайдентіки та маршмелоу у простих випадках
5) thefuzz - бібліотека для фаззі порівняння тексту, це завжди трішки магічно і круто
6) stackprinter - красивенько друкує стек та значення локальних змінних там де щось зламалося
7) icecream - наче може допомогти дебажити, показуючи вам, який саме код виконався, покликаний замінити прінти та логи (так-так, звичайно).
8) freezegun - мокає час в тестах
9) dirty_equals - супер, дозволяє 'приблизно' порівнювати значення в тестах (частина списку, частина словнику, майже однакове число, і тому подібне)
10) pyperclip - контрол-С, контрол-V прямо з рантайму. Копіювати щось в буфер буває корисно?
11) tqdm - дозволяє відображати прогрес бари, кому подобається естетика TUI - треба брати.

Посилання: https://martinheinz.dev/blog/96
Ну і гарного тижня всім

Плейліст з останнього PyCon US. Цікаво побачити у списку доповідь Брюса Екеля, автора книжки про те як думати на Java, а серед інших доповідачів є і сам Гвідо та інші відомі (та невідомі) нам люди
https://www.youtube.com/playlist?list=PL2Uw4_HvXqvY2zhJ9AMUa_Z6dtMGF3gtb

Побачив на ютюбі (та навіть почав дивитися) відео про бортовий комп'ютер Аполона і програмне забезпечення до нього. Цікаво, ділюся: https://www.youtube.com/watch?v=B1J2RMorJXM

Випадково побачив доволі непогану шпаргалку по python. Може комусь згодиться
https://gto76.github.io/python-cheatsheet/

Доволі непогана стаття про AWS S3. Як на мене)

https://www.allthingsdistributed.com/2023/07/building-and-operating-a-pretty-big-storage-system.html

Хороший текст щоб прочитати наприкінці робочого тижня: https://tonsky.me/blog/disenchantment/
Він не новий, проте залишається дуже актуальним - в ньому міркування про той сучасний софт, який ми будуємо. Може все так, а може і ні:)

Ну і ще ось пʼятничне гарне:
https://t.me/tipaproit/634

Python давно вже став де-факто стандартним інструментом для обробки даних. Тепер він є ще й в Microsoft Excel, і це просто цікава і дещо неочікувана новина.
Що панове в Microsoft наступне придумають? Linux в Windows уже є (і наче нормально працює).
https://techcommunity.microsoft.com/t5/microsoft-365-blog/introducing-python-in-excel-the-best-of-both-worlds-for-data/ba-p/3905482

Не знайомий з паном Євгенієм, але дуже класно і зрозуміло пише про повсякденні важливі речі, ось тут - приклад ситуації XY, яка, буває виникає при вирішенні робочих питань

XY problem

Час від часу зустрічаю ситуацію, коли хтось приходить з питанням як щось зробити без пояснення того яку проблему він чи вона намагається вирішити. Після двох-трьох уточнючих питань з’ясовується, що початкову проблему можна вирішити кардинально іншим шляхом. В такого типу питань є навіть загальноприйнята назва XY Problem:

The XY problem is asking about your attempted solution rather than your actual problem

Помічати такі питання за собою і за іншими, це одна з soft-skill навичок, яку можна легко опанувати не виходячи з дому.

Далі вигаданий приклад діалогу з таким питанням:

— як зробити декілька паралельних запитів в react-query?
— […поснює як це зробити…]. А для чого тобі це?
— у мене є API, щоб дістати інфо про користувача і мені треба для кожного повідомлення на форумі показати телефон автора цього повідомлення.
— давай краще в API, яке повертає список повідомлень, додамо потрібні тобі поля і тоді тобі взагалі не треба буде робити паралельні запити. Тим паче, що ми вже так повертаємо імʼя автора.
— точно! піду зроблю це на бекенді!

Хто хоче виконувати js у python рантаймі, ваші мрії здійснилися:)
Всім гарного пʼятничного вечору та вихідних попереду!

https://github.com/Distributive-Network/PythonMonkey

Всім привіт! Якщо ви хочете щось намалювати в ретро стилі, чи зробити таку собі презентацію наче як з кінця 80-х минулого сторіччя (або ще кучу всього), ось додаток: https://internet-janitor.itch.io/decker
Трішки поклацав - інтерфейс як на маку 1984 року, результат - також ніби як з того самого маку, однозначно в букмарки, буде чекати свого часу;)

Вийшла нова версія Python - 3.12
Деталі оновлення ось тут:
https://docs.python.org/3.12/whatsnew/3.12.html

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

Дуже коротке і зрозуміле пояснення концепції блум фільтру з візуалізацією тут: https://www.jasondavies.com/bloomfilter/
Про мушку тут: https://www.pnas.org/doi/10.1073/pnas.1814448115

За цим посиланням, https://clig.dev/ - шикарний та доволі стислий посібник по побудові інтерфейсів командного рядка. Класно, що перша частина - принципи (Philosophy of command line interfaces), а друга - безпосередньо практичні поради (Guidelines). Дуже багато посилань на інші джерела якщо хочеться ще більше зануритися в історію та деталі.
Збережу тут, в нагоді точно стане рано чи пізно🤗

Дуже сильно грубо кажучи, сучасна програмна інженерія - це або про інтенсивні обчислення, або про інтенсивну роботу з даними (а поміж цими екстрмумами - суміш одного з другим у різних пропорціях та ще й з суміжними дисциплінами комп'ютерних наук, але ключовим частіше за все як раз є або дані, або обчислення).
І от якщо ви хочете робити інженерію даних, яка зараз у тренді та дуже актуальна, то ось вам шалена підбірка ресурсів - https://github.com/DataEngineer-io/data-engineer-handbook.
Тут перелічені книжки, спільноти, ютюб канали, розсилки, лінкедіни, телеграм канали, твіттер, інстаграми і тіктоки (дожилися🙄), наведені посилання на компанії, курси та сертифікації що стосуються інженерії даних. Можна знайти на будь-який смак та потребу. В мене тільки одне питання до сучасного світу - коли це все встигати просто продивитися🤯, там книжок тільки з півтора десятки!

Ось тут за посиланням (https://www.inngest.com/blog/python-errors-as-values) коротенький текст, який узагальнює кілька підходів до обробки помилок в Python:
1) класичний спосіб, коли функція піднімає помилку і перериває потік виконання
2) спосіб як у Go, коли значення, яке повертає функція - завжди кортеж, де можлива помилка - останній елемент

def get_user(user_id: str) -> tuple[User | None, Exception | None]

3) спосіб як у Rust, коли функція повертає обʼєкт обгортку. Навіть бібліотека для цього є - https://github.com/rustedpy/result, та й виглядає симпатично

def get_user(user_id: str) -> result.Result[User, Exception]

4) підхід запропонований авторами - повертати юніон результату та помилки:

def get_user(user_id: str) -> User | Exception

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

Четвертий варіант - цікавий. Юніони - це популярно, але в іншому вигляді. Звичне та розповсюджене використання юніона це

def get_user(user_id: str) -> User | None

що тотожно опціональному типу, коли функція повертає результат, який може бути None типом.
Повертати помилку в юніоні - виглядає більш гнучко та інформативно, при цьому не так багатослівно як з кортежами і обгортками, проте функція не тільки інформує, що обʼєкт не знайдено, але ще й підказує чому. І це без try/except=) Що ж, це ще одна опція, тож маємо варіанти на будь-який смак;)

https://twitter.com/Bertrand_Meyer/status/1742613897675178347
Спочивай з миром, легендо