Расскажу про redux-saga и почему о них важно знать каждому

TypedMap

Разгребал гисты и нашел типизированную версию иммутабельной мапы - это почти что 80lvl по программированию на типах.

В реальности это можно использовать для управления коллекцией брендированных типов.

ЗЫ а вот тред в ТС чатике о дебаге и создании этого кода.

Revolution OS (правильный перевод)

Я иногда забываю что идея открытых знаний и свободно переиспользуемого тулинга достаточно уникальна для ИТшки. Некоторые мои родственники или знакомые даже не подозревают как радикально иначе можно строить бизнес или просто делать какие-то дела. Фильм будет понятен и доступен любому “уверенному пользователю ПК”, рекомендую 🙂

https://t.me/nikitonsky_pub/390

Дизайн это не киллер фича, это основа комфорта, который прибавляет или вычитает от общего впечатления.
Амазон не меняется, потому что пользователь не любит когда что-то меняется, пользователю лучше всего что-то привычное, потому что оно понятно и предсказуемо, те комфортно.

Хороший дизайн - эффективен в том что бы быстро провести пользователя по целевому процессу, который заканчивается тратой его денег.

Что бы пользователь не тупил, интерфейс должен быть привычный и понятный.
Привычным его можно сделать скопировав дизайн практики из платформы где запускается приложение (веб/десктоп/нейтив). Кстати узнать о них можно из гайдов по доступности.
А что бы интерфейс был понятный нужна прям толика дизайна для выделения ключевых элементов. Ну или скрытия второстепенных.

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

Возвращаясь к амазону. Если у вас есть киллер фича и вы можете на ней сильно вырасти - не играйтесь с дизайном, а сделайте максимально просто и понятно. Сэкономите на настоящем и будущем.
Добавить брендинг проще чем его поменять.

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

Почему с nx на turbo? Первый был для меня не удобен во многих мелочах, особенно в расширении для vscode на которое я возлагал большие надежды. Это еще терпимо, но я ни раз сталкивался с какими-то ошибками: какие-то заводил, какие-то просто не понимал как дебажить, воспроизводить и репортить - падает ошибка при запуске билда с графом на десяток пакетов, а откуда и почему не ясно.
На турбо оказалось норм, он меньше дает, но и попроще как-то - я это ценю.

По ссылке выше ишье как раз на багу в кодгене. Меня это напрягало, но было терпимо потому что сам формат был удобный - заводишь папку с кучкой файлов в которых просто специальным синтаксисом указываешь ключевые слова для изменения. В итоге, можно самому просто копирнуть папку и глобальным реплейсом за 5 секунд персонализировать темплейт в пакет. Удобно. Но как автоматизировать это другими инструментами, после миграции на турбо, я не нашел. Все говорят про plop, но он как будто заточен на кодснипеты. У меня простая задача - скопирнуть папку и сделать глобал реплейс.
Решил не привносить доп пакеты с доп сложностью, а написать свой скрипт - вышло достаточно коротко и внятно кмк.

С публикацией пакетов такая проблема: их много и следить за тем что изменилось очень тяжело, а как паблишить автоматически из CI я ещё не разобрался и не уверен можно ли вообще - у меня юбикей для OTP. Хотелось инструмент который может просто подсказать какие пакеты не актуальны в нпм. Я уже давно использовал npmjs.com/package/@jsdevtools/npm-publish и вроде норм, хотя оказалась что он не читает publishConfig.tag из пакаджисона - можно было бы запулреквестить, но я заметил что версию пакета он получает простой командой npm view package-name version и взяв тот же zx запили свой скрипт, избавив нодмодули от лишнего веса.

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

До круглого числа осталось 35 человек.

Поделитесь ссылкой t.me/artalog/187 ;)

astro.build

Генератор сайтов, который умеет сразу в React/Vue и ещё пачку шаблонизаторов, вырезая их рантайм, даже при использовании useState и тп!

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

Немного критки.
Тс в шаблонах иногда выдает не правильные типы в саджестах.
Не минифицирует по умолчанию стили из public.
Дважды писал в дискорд с проблемами (1, 2), ни разу не ответили.

У меня задача простая: в монорепе держать док билдер в папке docs, а доки писать в packages/**/README.md. Из-за какого-то не правильного, с моей точки зрения, внутреннего резолвинга импортов либ я не могу импортировать .md файлы из папки вне docs. Попробовал засимлинкать ридмишки из пакаджей внутрь докс - та же проблема. Пришлось копировать весь контент.

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

Вот вам крутой кейс для AI подсказчиков: сначала пишем код, а типы сгенерить помогут.

Вообще я скучаю по копайлоту. Он по ряду причин был для меня лучше табнайна. Кстати, вот ещё неплохая альтернатива: https://mutable.ai/

Привет, Ереван!

Языки программирования, синтаксис, семантика, прагматика, рекомендую к просмотру.

Использовал материалы из этой лекции при подготовке своего доклада (и статьи) 4 года назад. Сохранились заметки:

Свойства человеческого интелекта сильно отличаются от свойств вычислительной машины.

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

Программные инструменты программиста, особенно ЯП, расчитаны на что бы помочь декомпозировать и повысить уровень абстракции машинного кода.

Эволюция ЯП в улучшении абстракций: машинные коды, переменные (асемблер), процедуры и условные переходы (фортран), структуры (алгол68, паскаль), ООП, функции высшего порядка и развитые системы типов.

Но чем выше уровень абстракции, тем больше падает эффективность программы (условно, 1 уровен абстракции вдвое понижает вычислительную производительность)

C 28 по 45 минуты продолжая про историю языков программирования:
Алгол68 - имел на тот момент невероятно мощную и математически доказательную систему типов, но слишком сложную в использовании.
COBOL - на нем написано невероятно много кода, который до сих пор поддерживается, но ломающая версионность делает его использование очень сложным.
ПЛ/1 - ЯП со свободным синтаксисом и [уникальной] возможностью управлять точностью вычислений. В нем можно было делать слишком много (приведение разнообразных типов) и разобраться в итоговом коде было сложно.
"логические" языки, вроде PROLOG сложно назвать языками программирования.
Изначально ООП подразумевал концепцию объектов, которые просто обмениваются сообщениями
Будущее программирования - функциональщина
Язык в общем и язык программирования в частности: синтаксис (набор правил формализации), семантика (описание семантического домена - набора функций), прагматика.

Перебор возможных вариантов работы [с данными] программы очень похоже формальное математическое доказательство - это называется Соответствие Карри — Ховарда. Отличие, от математического доказательства, написание программы заключается в том что логика построения программы строится не на формальных доказательствах, а интуитивных умозаключениях программиста (накладывая абстрактный мыслительный процесс на формализацию ЯП).

Семантика позволяет конкретизировать до формального уровня интуитивное представление кода программы. Иначе говоря "с первого взгляда" код может иметь одну логику поведения, но учитывая семантику можно "увидеть" дополнительные аспекты \ ветвления алгоритма.

Реактивные примитивы для выражения семантики данных.

по следам этого тредам

В джаваскрипте нельзя описать некоторые поля объекта readonly, а некоторые перезаписываемыми. Все или ничего. ТС может немного помочь, но и это не всегда удобно. К тому же у нас могут быть поля модификация которых доступна только для определенных модулей.

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

Компьютедами решается важная проблема двунаправленного биндинга: мы не можем менять их значения снаружи - в типах и ЖСе это выразить нельзя или очень муторно. А с атомами все само работает, еще и реактивное :)

P.S. есть линзы и молекулы, которые позволяют менять компьютеды извне, но тк это специальная доп абстракция - это норм.

reactive-computed-bench

После ананоса сигналов преакта многие ринулись писать свои аналоги. А потом начали их бенчмаркать 🌚

Но что мерить и как? Нашли тест о Cellx, который проверяет возможности строить глубоковложенные связи(!) и немного его поменяв начали гонять все эти преакты. usignal от автора uhtml включился в борьбу. Начали находить узкие места и баги в реализации, в общем тема горячая, было интересно. А потом пришел Joachim Viide и выдал Signal Boosting для преакта - очень рекомендую почитать.

Конечно, в определенный момент начали обсуждать релевантность данного бенча и тут подсуетился я. У меня уже давно был бенч в репе реатома, но его использование другими авторами было не удобно - не было простого апи для описания сетапа и итерации, нужно было много копипастить и придумывать имена. Ну и я вынес его в отдельную репу и сильно зарефакторил, ссылка в шапке. Вот как выглядит тест эффектора.

Я уже писал какими критериями руководствовался при написании этого бенча и считаю его достаточно правдоподобным, надеюсь что он для многих будет удобен 🙂

Планы на будущее: вынести каждый тест в отдельный файл, опубликовать как нпм-пакет для простосты тестирования на других устройствах (нужно сначала разобраться что там с performance.now() в браузере сейчас).

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

Как же так, спросите вы? Я тут про перформансы и оптимизации рассказываю, а сам не могу либу сделать хотя бы в половину быструю солида?

Реатом под капотом делает очень дорогую операцию - создает кучу новых долгоживущих объектов. Каждый апдейт пораждает новый иммутабельный граф.

В простом коде вашей фичи это излишне, но и оверхед не будет заметен. Зато в более сложных случаях мы получаем из коробки стабильные стактрейсы и простую возможность дебажить апдейты любой сложности: синхронные и асинхронные. Попозже раскажу об этом подробнее, сейчас может звучать не поонятно, но я уверен что это очень ценная фича.

Это еще не все 🙂
Реатомовские атомы по умолчанию стейтлесс и работают только в каком-то контексте, который пользователь (разработчик приложения) должен создавать сам. Это упрощает тестирование и множественное инстанцирование (SSR) до одной строчки кода - создание нового контекста. Стоимость этой фичи можно наглядно увидеть в разнице бенча effector и effector (fork).
Из этой же фичи следует отсутствие необходимости брать отдельную либу для DI - реатома вполне достаточно для большинства задач на фронте. Пакет testing и гайд к нему уже готовится.