Applied Performance Theory
Дивився цю доповідь мабуть ще в 2018 й зараз вирішив передивитися. Одна з моїх улюблених доповідей про scalability. Доповідь про теорію й як характер навантаження впливає на поведінку системи. Однозначно рекомендую до перегляду!

Додав в список на my-talks - https://my-talks.net/awesome-technical-talks/kavya-joshi-applied-performance-theory

Hacking Google 😎
Документальний серіал на 1.5 години про те, як Google працює над безпекою й цікаві приклади взломів. Звісно зроблено для широкої аудиторії й драматично так зрежесовано, але вийшло пізнавально.

Насолоджуйтесь: https://www.youtube.com/playlist?list=PL590L5WQmH8dsxxz7ooJAgmijwOz0lh2H

JS Fwdays Europe - ще одна конференція від друзів🙂

Якщо дивитися онлайн, то безкоштовно. Якщо хочете доступ до записів й інші плюшки, тоді платно, але для підписників каналу отримав промокод зі зніжкою в 10% - AF6287B461

Плануються доповіді про: micro-frontends, Fullstack Components, JS фреймворки майбутнього, React 18, Playwright, e2e тестування etc
Серед спікерів: Chen Hui Jing, Kent C. Dodds, Steve Kinney, Артем Захарченко, Tejas Kumar та інші.

Конференція планувалася повністю англомовною, але оскільки багатьом простіше сприймати контент українською, то у якості експерименту, буде синхронний переклад треку В. Для перегляду українською мовою буде окремий плеєр на сайті.

ПОСИЛАННЯ: https://bit.ly/3UEOxWn

10% від вартості квитків йде на підтримку України🇺🇦

Чудова доповідь про те, як працює менеджмент пам’яті в різних реалізаціях Python. Інші мови мають подібні прийоми.

Наприклад, для Perl ви можете запустити цей код в консолі:
perl -MDevel::Peek -E 'my $num = 10; print Dump($num); my $string = "hello"; print Dump($string)'
і побачити внутрішні параметри змінних, які дуже схожі на cpython. Колись доводилоси оптимізувати споживання пам'яті й там є хитрі штуки.

Також JavaScript V8 робить pointer tagging, як це робить micropython – гугли V8 Small Integers(SMIs). Мені довелося зіткнутися з цим, коли оптимізував движок електронних таблиць у JS. Був дуже цікавий кейс, коли массив виду [a, b, c, d, e] я зконвертував в [a, b, [c, d, e]] й це дало великий буст в перформансі, хоча здавалося, що має зробити навпаки. Спрацювало, оскільки c, d, e - це адреса ячейки й це цілі числа, які влазять в 31 біт, що дозволило це масив упакувати в неперервну область пам'яті як native array

Доповідь додав в свій список (підписуйся 😉) - https://my-talks.net/awesome-technical-talks/kavya-joshi-the-memory-chronicles-a-tale-of-two-pythons

Raymond Hettinger "Modern Python Dictionaries"
Одна з найкращих доповідей про хештаблиці й техніки їх оптимізацій, які реально працюють в Python 3.6 й вище.
Хештаблиці одна з базових структур даний й одна з найбільш важливих. Практично кожен інженер знає, як вони працюють, але мало хто знає про додаткові оптимізації базового алгоритму. В доповіді поазано з десяток різноманітних оптимізацій на дуже простих прикладах. Однозначно рекомендую цю доповідь - багато цікавих ідей, які можуть допомогти й в інших ситуаціях.

Додав в свій список цікавих доповідей: https://my-talks.net/awesome-technical-talks/raymond-hettinger-modern-python-dictionaries

PS: Доповідь про фундаментальні штуки, не звертайте уваги, що це на прикладі Python

LIVR v2.5 з асинхронною валідацією

Багато років тому я шукав валідатор, який буде вміти наступне:
1. Декларативний опис валідації
2. Мати можливість валідувати ієрархічні структури.
3. Не зупиняти валідацію на першій помилці, а перевіряти всі поля й повертати інформацію о помилці в структурованому вигляді.
4. Видаляти поля, для який не описані правила валідації
5. Можливість легко додавати свої правила валідації
6. Бути мінімалістичним й не робити зайвого (як генерація форм й тд).
7. Мати фільтри, для зміни даних.
8. Серіалізація правил валідації (можливість зберегти правила валідації в файл, в базу, передати по мережі).
9. Має реалізацію під різні мови програмування й сумісний не тільки по правилам, а й по формату опису помилок.

Я на той час перепробував багато валідаторів й були цікаві, але у кожного була якась проблема. Тому я написав спеціфікацію https://livr-spec.org/ з тест кейсами (а тестів там багато), а потім вже почали з'явлитися імплементації під різні мови.

В деталях про все можна почитати в цьому пості - "LIVR – Data Validation Without Any Issues"

JavaScript версія має ще декілька особливостей:
✅ Ніяких зовнішних залежностей
✅ Працює в в NodeJs й в браузері
✅ Validator (без правил) менше 1KB (min+gzip)
✅ Validator з усіма правилами 3.93KB (min+gzip)
✅ Є додатковий пакет правил - livr-extra-rules

Не вистачало тільки асинхронної валідації й сьогодні додав й її (в доках - AsyncValidator).

ПОСИЛАННЯ НА NPM: https://www.npmjs.com/package/livr

Доречі, confme теж використовує LIVR. Але й без валідації confme корисна штука 🤓

Зараз всі почали гратися з OpenAI GPT3 й як не зміг це пропустити. Мій перший запит до чатбота.
Закінчення топ - "The software engineers became known as the "power engineers," and they were hailed as heroes for their ability to keep the city running, even in the darkest of times." 😁😁😁

Open AI GPT3 чат-бот вміє й українською 😜

Чат бот пише компоненти на React й відповідає на питання з співбесід краще ніж я. Вже треба міняти спеціальність на іншу чи й там штучний інтелект нас витіснить? :)

"One React mistake that's slowing you down"

Натрапив на цікавий пост про проектування API компнентів. Часто бувають ситуації, коли необхідні дані для компонента знаходяться десь вгорі по ієрархії компонентів. Й для того, щоб передати щось вниз, дані мають пройти декілька слоїв. Що з цим роботи?

Давайте здалеку.
Це одна із проблем, яка виникає, коли ви працюєте з React. Насправді, така проблема виникає в принципі в програмуванні. Наприклад, коли нам необхідно передати колбек в функцію, й нам потрібен доступ до стейту(змінних), то нам допомогають замикання. Якщо ж замикання не підтримуються мовою (Java чи інше), то ми тут можна обрати інше рішення:
1. Міняти API колбека, щоб він приймав стейт зовні й передавати його від викликаючої функції. В React це схоже на випадок, коли ми передаєм пропси через дерево компонентів.
2. Зберігати стейт в глобальних змінних. В React це схоже на випадок з контекстом.
3. Інкапсулювати стейт в ООП-ному об'єкті й передавати об'єкт з внутрішнім стейтом й зробити метод call/execute/run/handle/whatever. Й це буде аналог замикання. Навіть є такий патерн - "команда", або функтори (ті, що callable objects) в Python. В React це схоже на передачу children.
4. Інше

Що обрати? Як кажуть - "it depends". Автор статті радить передавати children й, в контексті його прикладу з лейаутом, я з ним згоден. Але завжди зважуйте на свій конкретний випадок.

Загальна ідея, коли ви проектуєте API React компонента така сама, як й проектування будь-якого іншого API. API компонента залежить від його відповідальності. Припустимо, що у нас є TweetsFeed й всередені є дві колонки твітів. Ієрархія може виглядята так:
TweetsFeed => RightContent => TweetDetails

Це не відповідальність RightContent зібрати дані для якогось TweetDetails, який ми вирішили розмістити з правого боку, але й можливо це й не відповідальність TweetDetails збирати дані (оскільки він тільки візуалізує). Тоді можна зробити врапер навколо TweetDetails, який вятигне дані, але можливо взагалі відповідальність всього TweetsFeed тільки в візуалізації й ніхто в TweetsFeed не має тягнути дані зовні самостійно. Всі ці "можливо" це про відповідальність компонента й коли ми проектуємо, ми спочатку думаємо про відповідальність компонента, а потім вже думаємо про API й як передати дані.

СТАТТЯ: https://epicreact.dev/one-react-mistake-thats-slowing-you-down/

Цей день настав 😉
Нарешті я запустив ютуб канал й записав перше відео.
У мене була ідея робити велики відео (по 1-2 години) з зануренням в деталі, але зрозумів, що зараз на це не знайду часу, тому вирішив, що краще почну з чогось коротшого й з тим, що не вимагає монтажу. Вже є контент план на найближчі місяці - буду потрохи записувати й викладати.

ВІДЕО: https://www.youtube.com/watch?v=wYkiKaT8whY
Підписуйтесь! По темі відео залишайте коментарі на ютубі під відео.

Як вам перше відео?

Що з гарного програміста може зробити поганого?

В минулий раз були 3 речі, які роблять програміста краще. Зараз 3 речі, які роблять програміста гірше.

ВІДЕО: https://www.youtube.com/watch?v=_j8ACibMJ0s

Підписуйтесь! По темі відео залишайте коментарі на ютубі під відео.

PS: На підході відео про Code Review 😉

Кожного місяця ми переказуємо прибуток компанії на рахунок ЗСУ. Щомісячний звіт - https://t.me/webbylab/147 (перевалили за 10 млн грн) 🇺🇦💪❤️

Жабаскрипт не працює
Сьогодні тестував пошук по "Жабаскрипт" та "JabaScript" на ютубі й виявилося, що ютуб нічого не знаходить.
1. Коли шукаю по "JabaScript", то показує примітку: "Показано результати по JavaScript, якщо хочете шукати саме по JabaScript, то натисніть сюди".
2. Якщо шукати по "Жабаскрипт", то взагалі видає тільки про Javascript, навіть без примітки.

Тобто виходить, що така гра слів на юутуб каналі це пагано, оскільки ютуб вважає це опечаткою при пошуку.

В той самий час, коли шукаю по "Фундаментально про програмування", то канал знаходиться відразу.

Ось думаю тепер, як перейменувати канал. Поки ідея залишити тільки "Фундаментельно про програмування". Що думуєте? Є ще варіанти?

PS: Доречі опублікував нове відео на каналі сьогодня про Code Review

Як покращити Code Review? Як працює Code Review в Google?

ВІДЕО: https://youtu.be/Xv92EsebyvU

Підписуйтесь! По темі відео залишайте коментарі на ютубі під відео 😉

Ну що? Готові до 2023 без русні? 🙂
А так буде - рашка розвалиться, а Україна переможе! Всіх з наступаючим новим роком! Миру, щастя, здоров'я всім вам й близьким! 🇺🇦💪

Книга "The Staff Engineer's Path" by Tanya Reilly, 2022
Хоч я її ще не дочитав, але готовий вже рекомендувати 🙂
Позиція Staff Software Engineer це щось нове й не завжди зрозуміле, окрім того у тебе ймовірно не буде старшого staff-а, який тобі пояснить, що це те таке, оскільки у стафф інженерів зазвичай немає підлеглих.

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

Ця книга про Staff+ розвиток й буде корисна не тільки сеніорам, а й починаючим CTO, які в невиликих компаніях часто одноосібно закривають ці функції. Також, можливо, у когось виникало питання де ж software architects в FAANG, то ця функція також закривається стафф інженерами.

Цікаво, що Principal Engineer й Director в FAANG це часто один й той самий рівень й можливий перехід з однієї вертикалі в іншу. Тобто це два варіанти розвитку, які йдуть поруч.

Якщо цікавилися, що робить Staff Software Engineer, то книга дає структуровану відповідь на це питання