Через несколько минут расскажу на коротком стриме что здесь происходит и почему это круто.

https://t.me/xufostation/758

В подкасте гость не разделяет РП и ФРП, потому что у нас в индустрии практически нет теоретических исследований РП в целом, но большинство материалов связано с практикой ФРП.

Я уже не раз говорил что MobX, Excel и кучка мелких ООРП либ доказывают что реактивность может быть совсем вне контекста функционального программирования.

Нужно понимать что ФП и ООП на столько огромны, что включают в себя синтаксические, семантические и архитектурные особенности описания кода и построения его интерфейсов в целом. Упрощенно можно разделить их на функции высшего порядка и композицию, против классов и их наследования. И это вообще никак не пересекается с реактивным программированием, как простым паттерном переноса явных связей в коде в рантайм, через интерфейс подписки. Одно другому не противорчечит и даже не помогает / мешает.

Как правильно было замечено в начале подкаста - реактивное программирование отлично решает проблему связанности одного источника и нескольких потребителей.

https://artalar.github.io/csb-trpr1/

Расскопал вот такое вот старье в песочницах. Игрался с генерацией анимированного задника для lofi.

(код)

- перезагрузкой страницы выбираем симпотичный цвет
- настраиваем скорость в левом верхнем углу
- по Enter включаем фулскрин

Там бы хорошо еще какой-то lofi стрим на фон добавить, контролы красивые запилить. И главный челендж, на котором я остановился, переписать на генерацию статического текста (кода) кейфрема (это возможно).
Если кто хочет - форкайте, поделитесь потом что вышло 🙂

https://t.me/fxnim/51

На выходных пару часов дебажил Uncaught promise exception, искренне думая что в третьем случае, аналогично второму, ошибки не будет. Пофиксил, понятно, как в четвертом случае.

Ну бывает 😓

ну вобще тут история интересная, его изначально для фетча и делали, но по итогу решили сделать как отдельную апи
https://developer.chrome.com/blog/abortable-fetch/#the-history

Использовать разные либы для навигации, форм, сетевого кеша и остальных стейтов, вместо одного стейт менеджера с кучкой доменных хелперов, это тоже самое что использовать разные IoC для каждой из этих задач.
Есть системные домены, а есть бизнесовые: первые должны использовать одинаковый тулинг, вторые делиться и быть разграниченными.

Адаптеры - рак современной разработки. Без наличия и попыток создать базовые примитивы для обработки конкурентных процессов и транзакций системное качество кода и конечных продуктов будет всегда заметно ниже возможного.

Я уже рассказывал о том что реактивные библиотеки не могут дружить между собой при наличии собственных (отдельных) очередей подписок. Это принципиально блокирует возможность делать атомарные транзакции и мутировать временные данные (что есть хорошо). Те негативно сказывается на стабильности и производительности приложения

cc t.me/JentlemanS/205382

Так же, адаптеры скрывают проблему консистентности системных утилит, позволяя написать просто сейчас, ухудшая дебаг и поддержку потом.

А ваш? 🙂
firstpr.me

Забавно и по делу https://www.youtube.com/c/Fireship

Ok, вот материал поглубже.

В вебе до сих пор часть задач драгендропа нужно решать ручками или либами. Причем сложную часть, нативный днд апи позволяет решать достаточно скромный список задач (по моему опыту), при этом он плохо задизайнен и в разных браузерах имеет разные баги. Единственный неоспоримый плюс - возможность трекать межоконные перетаскивания.

А чем события мыши отличаются от событий тача и почему спек последнего несколько (было?)?

О всей этой истории легаси в докладе @rdvornov:

https://youtu.be/4o9joROJVHg?list=PLXObawgXpIfyH7XRtAN1JgFd6FJVzURdV

​​Отличный технический стендап про кодировки — то, как компьютеры хранят и обрабатывают текст и почему раньше мы регулярно сталкивались с «Р·Р°РїСѓСЃРє», «Đ·Đ°Đ¿ÑƒÑ�Đº» и «п╥п╟п©я┐я», а теперь всё норм.

Куча супер классных примеров и баек из жизни. Например, почему концерт Билли Джоэля в Ленинграде называется на всех стриминингах «kohuept» (это в конце восьмидесятых так вбили слово КОНЦЕРТ на латинице) или почему город Aarhus стоит в конце алфавитного списка (виноваты вторая мировая и гугл).

Мечтаю сделать про это эпизод подкаста и не уверен, что у нас получится увлекательнее; целый час удовольствия https://www.youtube.com/watch?v=gd5uJ7Nlvvo

Небольшой ликбез по видам тестирования

Недавно в личной беседе выяснилось, что некоторые разработчики путают виды тестирования и уровни тестирования. В свое время мне помог разобраться ресурс www.protesting.ru во всех этих терминах.

В зависимости от преследуемых целей тестирования выделяют следующие виды:

Функциональные виды тестирования

Базируются на функциях и особенностях, а также взаимодействии с другими системами. Функциональные виды тестирования рассматривают внешнее поведение системы. Бывают следующие подвиды:

> Функциональное тестирование (Functional testing)
> Тестирование безопасности (Security and Access Control Testing)
> Тестирование взаимодействия (Interoperability Testing)

Более того функциональные виды тестирования могут иметь свои уровни, то есть то, над чем производятся тесты: над отдельным модулем, группой модулей или системой, в целом. Отсюда соответственно выделяют следующие уровни:

> Компонентное или Модульное тестирование (Component Testing or Unit Testing)
> Интеграционное тестирование (Integration Testing)
> Системное тестирование (System Testing)
> Приемочное тестирование (Acceptance Testing)

Нефункциональные виды тестирования

Описывают тесты, необходимые для определения характеристик программного обеспечения, которые могут быть измерены различными величинами. В целом, это тестирование того, "Как" система работает.

> Все виды тестирования производительности:
— нагрузочное тестирование (Performance and Load Testing)
— стрессовое тестирование (Stress Testing)
— тестирование стабильности или надежности (Stability / Reliability Testing)
— объемное тестирование (Volume Testing)
> Тестирование установки (Installation testing)
> Тестирование удобства пользования (Usability Testing)
> Тестирование на отказ и восстановление (Failover and Recovery Testing)
> Конфигурационное тестирование (Configuration Testing)
> Тестирование безопасности (Security and Access Control Testing)

Связанные с изменениями виды тестирования

После проведения необходимых изменений, таких как исправление бага/дефекта, программное обеспечение должно быть перетестировано (протестировано снова) для подтверждения того факта, что проблема была действительно решена.

> Дымовое тестирование (Smoke Testing)
> Регрессионное тестирование (Regression Testing)
> Тестирование сборки (Build Verification Test)
> Санитарное тестирование или проверка согласованности/исправности (Sanity Testing)

Хотите узнать больше деталей по каждому виду тестирования? Полистайте www.protesting.ru

На прошлой неделе разгорелся спор в комментариях к посту про не авторазворачивание типа для результата промиса - почитайте, там интересно.

Локально проблему можно исправить так: type MyPromise<T> = Promise<Awaited<T>>. Почему же не сделать такой тип для Promise по умолчанию?

Ну я проверил, уже с вложенностью в 20 ТС кидает Type instantiation is excessively deep and possibly infinite.

Повспоминаю свои истории косяков немного. Без записи 😁