Побачив на ютюбі (та навіть почав дивитися) відео про бортовий комп'ютер Аполона і програмне забезпечення до нього. Цікаво, ділюся: 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
Спочивай з миром, легендо

По ділу сказано:)

На днях Rust-ентузіасти у лиці команди Astral Software написали у своєму блозі про uv, черговий інструмент для екосистеми Python, написаний на Rust - https://astral.sh/blog/uv
Якщо коротко - прирости швидкості у визначенні та встановленні залежностей колосальні (від 7 до 115 разів!)
Як то водиться, поки що uv у стадії розробки, і для ваших важливих речей краще користуватися перевіреними рішеннями, в котрих фокус на стабільності та сумісності (я про умовний pip).
Але - у Astral Sofrware амбіційні цілі, роудмап та, начебто, непогано все поки виходить, тому можна стежити та (можливо) експериментувати в очікуванні нових версій uv та інших корисностей.

Якщо матимете 20 хвилин на вихідних - ось цікава стаття про зліт і падіння операційної системи os/2, і, заодно, про взаємовідносини між Microsoft та IBM:
https://arstechnica.com/information-technology/2019/11/half-an-operating-system-the-triumph-and-tragedy-of-os2/
🙂