Жабаскрипт (веде Віктор Турський)

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

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

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

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

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

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

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

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

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

"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/

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

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

Зараз всі почали гратися з 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." 😁😁😁

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

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

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

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

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

Чудова доповідь про те, як працює менеджмент пам’яті в різних реалізаціях 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

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% від вартості квитків йде на підтримку України🇺🇦

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

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

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

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

Awesome technical talks 😎
Думав, де сбирати цікаві доповіді, які мені часом траплаються й зрозумів, що можна створити додатковий аккаунт на my-talks. Це як інстаграм, тільки для доповідей. Й як в інстаграмі ви можете викладати персональний контент й робити власне портфоліо доповідей або можна зробити аккаунт для агрегації чужого цікавого контента 😁

Якщо хочете отримувати сповіщення про нові доповіді, то підписуйтесь на аккаунт https://my-talks.net/awesome-technical-talks

Why Event Sourced Systems Fail [eng] / Greg Young
Класна доповідь від Грега для перегляду у вихідний.
Грег - батько івент сорсингу. Й в доповіді він розповідає про класичні проблеми й непорозуміння з цим підходом. Доповідь мені дуже сподобалася й починає Грег з основ - що таке Event Sourcing.

Я помітив, що люди часто плутають CQRS й Event Sourcing. CQRS значно ширший підхід й основна ідея, що у нас у нас різні об'єкти доменої модели для запису й читання (є класний слайд у Грега про це). Й цей підхід можна зустріти в багатьох проектах (й WebbyLab багато разів доводилося його використовувати). Event Sourcing теж передбачає таке саме розділення, але каже про те, що основним джерелом правди є збережені івенти. Такий підхід вже зустрічається не так часто, хоча мені доводилося реалізовувати цей паттерн (робив доповідь про це в 2018).

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

✅ ДОПОВІДЬ ВІД ГРЕГА "Why Event Sourced Systems Fail [eng]": https://www.youtube.com/watch?v=FKFu78ZEIi8

✅ МОЯ ДОПОВІДЬ з 2018 "Offline mode for a mobile application, Redux on server, event sourcing [ru]": https://my-talks.net/viktor-turskyi/offline-mode-for-a-mobile-application-redux-on-server-and-a-little-bit-about-event-sourcing

Автоматизовані тести для React фронтенду
Писати тести на фронті складно й часто вони є крихкими. Пару місяців тому робив доповідь на цю тему й спробував проаналізувати різноманітні підходи. Ну й поділився баченням, як зробити тести менш крихкими. В доповіді поступово йду від бази й закінчую вже робочим рішенням.

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

Щомісячний звіт https://t.me/webbylab/137
Підтримуємо ЗСУ! 🇺🇦💪