На выходных разбирался с инфраструктурой в монорепе реатома и нужно было решить несколько задач: мигрировать с nx на turbo, из-за этого использовать другой кодген для нового пакета, сделать что-то для упрощения публикации новых версий пакетов.
Почему с nx на turbo? Первый был для меня не удобен во многих мелочах, особенно в расширении для vscode на которое я возлагал большие надежды. Это еще терпимо, но я ни раз сталкивался с какими-то ошибками: какие-то заводил, какие-то просто не понимал как дебажить, воспроизводить и репортить - падает ошибка при запуске билда с графом на десяток пакетов, а откуда и почему не ясно.
На турбо оказалось норм, он меньше дает, но и попроще как-то - я это ценю.
По ссылке выше ишье как раз на багу в кодгене. Меня это напрягало, но было терпимо потому что сам формат был удобный - заводишь папку с кучкой файлов в которых просто специальным синтаксисом указываешь ключевые слова для изменения. В итоге, можно самому просто копирнуть папку и глобальным реплейсом за 5 секунд персонализировать темплейт в пакет. Удобно. Но как автоматизировать это другими инструментами, после миграции на турбо, я не нашел. Все говорят про plop, но он как будто заточен на кодснипеты. У меня простая задача - скопирнуть папку и сделать глобал реплейс.
Решил не привносить доп пакеты с доп сложностью, а написать свой скрипт - вышло достаточно коротко и внятно кмк.
С публикацией пакетов такая проблема: их много и следить за тем что изменилось очень тяжело, а как паблишить автоматически из CI я ещё не разобрался и не уверен можно ли вообще - у меня юбикей для OTP. Хотелось инструмент который может просто подсказать какие пакеты не актуальны в нпм. Я уже давно использовал npmjs.com/package/@jsdevtools/npm-publish и вроде норм, хотя оказалась что он не читает publishConfig.tag из пакаджисона - можно было бы запулреквестить, но я заметил что версию пакета он получает простой командой
В общем, я доволен тем что сейчас так просто можно пилить свои небольшие скрипты и std ноды достаточно богато, а где его не хватает можно использовать простой концептуально zx.
Почему с nx на turbo? Первый был для меня не удобен во многих мелочах, особенно в расширении для vscode на которое я возлагал большие надежды. Это еще терпимо, но я ни раз сталкивался с какими-то ошибками: какие-то заводил, какие-то просто не понимал как дебажить, воспроизводить и репортить - падает ошибка при запуске билда с графом на десяток пакетов, а откуда и почему не ясно.
На турбо оказалось норм, он меньше дает, но и попроще как-то - я это ценю.
По ссылке выше ишье как раз на багу в кодгене. Меня это напрягало, но было терпимо потому что сам формат был удобный - заводишь папку с кучкой файлов в которых просто специальным синтаксисом указываешь ключевые слова для изменения. В итоге, можно самому просто копирнуть папку и глобальным реплейсом за 5 секунд персонализировать темплейт в пакет. Удобно. Но как автоматизировать это другими инструментами, после миграции на турбо, я не нашел. Все говорят про plop, но он как будто заточен на кодснипеты. У меня простая задача - скопирнуть папку и сделать глобал реплейс.
Решил не привносить доп пакеты с доп сложностью, а написать свой скрипт - вышло достаточно коротко и внятно кмк.
С публикацией пакетов такая проблема: их много и следить за тем что изменилось очень тяжело, а как паблишить автоматически из CI я ещё не разобрался и не уверен можно ли вообще - у меня юбикей для OTP. Хотелось инструмент который может просто подсказать какие пакеты не актуальны в нпм. Я уже давно использовал npmjs.com/package/@jsdevtools/npm-publish и вроде норм, хотя оказалась что он не читает publishConfig.tag из пакаджисона - можно было бы запулреквестить, но я заметил что версию пакета он получает простой командой
npm view package-name version и взяв тот же zx запили свой скрипт, избавив нодмодули от лишнего веса.В общем, я доволен тем что сейчас так просто можно пилить свои небольшие скрипты и std ноды достаточно богато, а где его не хватает можно использовать простой концептуально zx.
👍5
artalog
До круглого числа осталось 35 человек. Поделитесь ссылкой t.me/artalog/187 ;)
Уфффф. Циферка так быстро прыгнула, что 1024 проскользнула между 1019 и 1027 🤩
Спасибо всем новым подписчикам и, конечно, всем тем кто был тут в этом году! Приятно видеть реакции на посты и еще больше приятно узнавать что-то новое в комментариях к ним. 🔥
С января я начал делать посты каждый день и думал что меня хватит месяца на 2-3, но сейчас в закладках десятки тем и не хватает лишь времени их переработать в текст. Впереди еще много интересного😀
Напомню, самое интересное в закрепе: t.me/artalog/187
Конечно, невозможно не поблагодарить и посоветовать дружественные каналы, способствовавшие как росту этого канала, так и моему интелектуальному развитию:
@xanf_dev
@sergeysova
@melikhov_dev
@xufostation
@msosnovfeed
@valya_reads_issue
@bearlogin_dev
@kirjs_ru
@gorshochekvarit
@defront
Спасибо всем новым подписчикам и, конечно, всем тем кто был тут в этом году! Приятно видеть реакции на посты и еще больше приятно узнавать что-то новое в комментариях к ним. 🔥
С января я начал делать посты каждый день и думал что меня хватит месяца на 2-3, но сейчас в закладках десятки тем и не хватает лишь времени их переработать в текст. Впереди еще много интересного
Напомню, самое интересное в закрепе: t.me/artalog/187
Конечно, невозможно не поблагодарить и посоветовать дружественные каналы, способствовавшие как росту этого канала, так и моему интелектуальному развитию:
@xanf_dev
@sergeysova
@melikhov_dev
@xufostation
@msosnovfeed
@valya_reads_issue
@bearlogin_dev
@kirjs_ru
@gorshochekvarit
@defront
Please open Telegram to view this post
VIEW IN TELEGRAM
❤22🔥8
astro.build
Генератор сайтов, который умеет сразу в React/Vue и ещё пачку шаблонизаторов, вырезая их рантайм, даже при использовании useState и тп!
Потыкал, рекомендую: хорошая дока, дефолты, все достаточно просто, при этом эффективно. Очень порадовала поддержка TS внутри их собственных темплейтов (.astro). Простые дерективы для точечного описания загрузки компонент.
Немного критки.
Тс в шаблонах иногда выдает не правильные типы в саджестах.
Не минифицирует по умолчанию стили из
Дважды писал в дискорд с проблемами (1, 2), ни разу не ответили.
У меня задача простая: в монорепе держать док билдер в папке
Но, в итоге, это решение вышло удобным, потому что для пакетов с пустым ридми (за всем не успеешь) я показываю код из файла с тестами - мне показалось это хорошим решением, например. А вот код синхронизации.
Генератор сайтов, который умеет сразу в React/Vue и ещё пачку шаблонизаторов, вырезая их рантайм, даже при использовании useState и тп!
Потыкал, рекомендую: хорошая дока, дефолты, все достаточно просто, при этом эффективно. Очень порадовала поддержка TS внутри их собственных темплейтов (.astro). Простые дерективы для точечного описания загрузки компонент.
Немного критки.
Тс в шаблонах иногда выдает не правильные типы в саджестах.
Не минифицирует по умолчанию стили из
public.Дважды писал в дискорд с проблемами (1, 2), ни разу не ответили.
У меня задача простая: в монорепе держать док билдер в папке
docs, а доки писать в packages/**/README.md. Из-за какого-то не правильного, с моей точки зрения, внутреннего резолвинга импортов либ я не могу импортировать .md файлы из папки вне docs. Попробовал засимлинкать ридмишки из пакаджей внутрь докс - та же проблема. Пришлось копировать весь контент.Но, в итоге, это решение вышло удобным, потому что для пакетов с пустым ридми (за всем не успеешь) я показываю код из файла с тестами - мне показалось это хорошим решением, например. А вот код синхронизации.
Astro
Astro builds fast content sites, powerful web applications, dynamic server APIs, and everything in-between.
❤5🥰1
Вот вам крутой кейс для AI подсказчиков: сначала пишем код, а типы сгенерить помогут.
Вообще я скучаю по копайлоту. Он по ряду причин был для меня лучше табнайна. Кстати, вот ещё неплохая альтернатива: https://mutable.ai/
Вообще я скучаю по копайлоту. Он по ряду причин был для меня лучше табнайна. Кстати, вот ещё неплохая альтернатива: https://mutable.ai/
👍1
Языки программирования, синтаксис, семантика, прагматика, рекомендую к просмотру.
Использовал материалы из этой лекции при подготовке своего доклада (и статьи) 4 года назад. Сохранились заметки:
Свойства человеческого интелекта сильно отличаются от свойств вычислительной машины.
Машина - это большой конечный автомат, точнее конечный преобразователь (трансдьюсер). Ее инструкции - набор переходов(?). Человеку сложно оперировать такими понятиями, особенно в большой программе.
Программные инструменты программиста, особенно ЯП, расчитаны на что бы помочь декомпозировать и повысить уровень абстракции машинного кода.
Эволюция ЯП в улучшении абстракций: машинные коды, переменные (асемблер), процедуры и условные переходы (фортран), структуры (алгол68, паскаль), ООП, функции высшего порядка и развитые системы типов.
Но чем выше уровень абстракции, тем больше падает эффективность программы (условно, 1 уровен абстракции вдвое понижает вычислительную производительность)
C 28 по 45 минуты продолжая про историю языков программирования:
Алгол68 - имел на тот момент невероятно мощную и математически доказательную систему типов, но слишком сложную в использовании.
COBOL - на нем написано невероятно много кода, который до сих пор поддерживается, но ломающая версионность делает его использование очень сложным.
ПЛ/1 - ЯП со свободным синтаксисом и [уникальной] возможностью управлять точностью вычислений. В нем можно было делать слишком много (приведение разнообразных типов) и разобраться в итоговом коде было сложно.
"логические" языки, вроде PROLOG сложно назвать языками программирования.
Изначально ООП подразумевал концепцию объектов, которые просто обмениваются сообщениями
Будущее программирования - функциональщина
Язык в общем и язык программирования в частности: синтаксис (набор правил формализации), семантика (описание семантического домена - набора функций), прагматика.
Перебор возможных вариантов работы [с данными] программы очень похоже формальное математическое доказательство - это называется Соответствие Карри — Ховарда. Отличие, от математического доказательства, написание программы заключается в том что логика построения программы строится не на формальных доказательствах, а интуитивных умозаключениях программиста (накладывая абстрактный мыслительный процесс на формализацию ЯП).
Семантика позволяет конкретизировать до формального уровня интуитивное представление кода программы. Иначе говоря "с первого взгляда" код может иметь одну логику поведения, но учитывая семантику можно "увидеть" дополнительные аспекты \ ветвления алгоритма.
Использовал материалы из этой лекции при подготовке своего доклада (и статьи) 4 года назад. Сохранились заметки:
Свойства человеческого интелекта сильно отличаются от свойств вычислительной машины.
Машина - это большой конечный автомат, точнее конечный преобразователь (трансдьюсер). Ее инструкции - набор переходов(?). Человеку сложно оперировать такими понятиями, особенно в большой программе.
Программные инструменты программиста, особенно ЯП, расчитаны на что бы помочь декомпозировать и повысить уровень абстракции машинного кода.
Эволюция ЯП в улучшении абстракций: машинные коды, переменные (асемблер), процедуры и условные переходы (фортран), структуры (алгол68, паскаль), ООП, функции высшего порядка и развитые системы типов.
Но чем выше уровень абстракции, тем больше падает эффективность программы (условно, 1 уровен абстракции вдвое понижает вычислительную производительность)
C 28 по 45 минуты продолжая про историю языков программирования:
Алгол68 - имел на тот момент невероятно мощную и математически доказательную систему типов, но слишком сложную в использовании.
COBOL - на нем написано невероятно много кода, который до сих пор поддерживается, но ломающая версионность делает его использование очень сложным.
ПЛ/1 - ЯП со свободным синтаксисом и [уникальной] возможностью управлять точностью вычислений. В нем можно было делать слишком много (приведение разнообразных типов) и разобраться в итоговом коде было сложно.
"логические" языки, вроде PROLOG сложно назвать языками программирования.
Изначально ООП подразумевал концепцию объектов, которые просто обмениваются сообщениями
Будущее программирования - функциональщина
Язык в общем и язык программирования в частности: синтаксис (набор правил формализации), семантика (описание семантического домена - набора функций), прагматика.
Перебор возможных вариантов работы [с данными] программы очень похоже формальное математическое доказательство - это называется Соответствие Карри — Ховарда. Отличие, от математического доказательства, написание программы заключается в том что логика построения программы строится не на формальных доказательствах, а интуитивных умозаключениях программиста (накладывая абстрактный мыслительный процесс на формализацию ЯП).
Семантика позволяет конкретизировать до формального уровня интуитивное представление кода программы. Иначе говоря "с первого взгляда" код может иметь одну логику поведения, но учитывая семантику можно "увидеть" дополнительные аспекты \ ветвления алгоритма.
YouTube
Языки программирования, синтаксис, семантика, прагматика
Языки программирования, синтаксис, семантика, прагматика. Когнитивные особенности человеческого мышления и их влияние на развитие языков программирования. Языки программирования в ретроспективе. Процедурное, объектно-ориентированное, логическое и функциональное…
👍15👎2
Реактивные примитивы для выражения семантики данных.
по следам этого тредам
В джаваскрипте нельзя описать некоторые поля объекта readonly, а некоторые перезаписываемыми. Все или ничего. ТС может немного помочь, но и это не всегда удобно. К тому же у нас могут быть поля модификация которых доступна только для определенных модулей.
Реактивные примитивы помогают это описать и реализовать. Данные только для чтения мы оставляем нативными примитивами, данные для мутации заворачиваем в базовые атомы (можно мутировать). А комплексные данные заворачиваем в компьютед атомы, которые зависят от заданных при инициализации значений, но не должно меняться откуда-то извне.
Компьютедами решается важная проблема двунаправленного биндинга: мы не можем менять их значения снаружи - в типах и ЖСе это выразить нельзя или очень муторно. А с атомами все само работает, еще и реактивное :)
P.S. есть линзы и молекулы, которые позволяют менять компьютеды извне, но тк это специальная доп абстракция - это норм.
по следам этого тредам
В джаваскрипте нельзя описать некоторые поля объекта readonly, а некоторые перезаписываемыми. Все или ничего. ТС может немного помочь, но и это не всегда удобно. К тому же у нас могут быть поля модификация которых доступна только для определенных модулей.
Реактивные примитивы помогают это описать и реализовать. Данные только для чтения мы оставляем нативными примитивами, данные для мутации заворачиваем в базовые атомы (можно мутировать). А комплексные данные заворачиваем в компьютед атомы, которые зависят от заданных при инициализации значений, но не должно меняться откуда-то извне.
Компьютедами решается важная проблема двунаправленного биндинга: мы не можем менять их значения снаружи - в типах и ЖСе это выразить нельзя или очень муторно. А с атомами все само работает, еще и реактивное :)
P.S. есть линзы и молекулы, которые позволяют менять компьютеды извне, но тк это специальная доп абстракция - это норм.
❤4
reactive-computed-bench
После ананоса сигналов преакта многие ринулись писать свои аналоги. А потом начали их бенчмаркать 🌚
Но что мерить и как? Нашли тест о Cellx, который проверяет возможности строить глубоковложенные связи(!) и немного его поменяв начали гонять все эти преакты. usignal от автора uhtml включился в борьбу. Начали находить узкие места и баги в реализации, в общем тема горячая, было интересно. А потом пришел Joachim Viide и выдал Signal Boosting для преакта - очень рекомендую почитать.
Конечно, в определенный момент начали обсуждать релевантность данного бенча и тут подсуетился я. У меня уже давно был бенч в репе реатома, но его использование другими авторами было не удобно - не было простого апи для описания сетапа и итерации, нужно было много копипастить и придумывать имена. Ну и я вынес его в отдельную репу и сильно зарефакторил, ссылка в шапке. Вот как выглядит тест эффектора.
Я уже писал какими критериями руководствовался при написании этого бенча и считаю его достаточно правдоподобным, надеюсь что он для многих будет удобен 🙂
Планы на будущее: вынести каждый тест в отдельный файл, опубликовать как нпм-пакет для простосты тестирования на других устройствах (нужно сначала разобраться что там с
После ананоса сигналов преакта многие ринулись писать свои аналоги. А потом начали их бенчмаркать 🌚
Но что мерить и как? Нашли тест о Cellx, который проверяет возможности строить глубоковложенные связи(!) и немного его поменяв начали гонять все эти преакты. usignal от автора uhtml включился в борьбу. Начали находить узкие места и баги в реализации, в общем тема горячая, было интересно. А потом пришел Joachim Viide и выдал Signal Boosting для преакта - очень рекомендую почитать.
Конечно, в определенный момент начали обсуждать релевантность данного бенча и тут подсуетился я. У меня уже давно был бенч в репе реатома, но его использование другими авторами было не удобно - не было простого апи для описания сетапа и итерации, нужно было много копипастить и придумывать имена. Ну и я вынес его в отдельную репу и сильно зарефакторил, ссылка в шапке. Вот как выглядит тест эффектора.
Я уже писал какими критериями руководствовался при написании этого бенча и считаю его достаточно правдоподобным, надеюсь что он для многих будет удобен 🙂
Планы на будущее: вынести каждый тест в отдельный файл, опубликовать как нпм-пакет для простосты тестирования на других устройствах (нужно сначала разобраться что там с
performance.now() в браузере сейчас).GitHub
GitHub - artalar/reactive-computed-bench
Contribute to artalar/reactive-computed-bench development by creating an account on GitHub.
🔥6👍1
artalog
reactive-computed-bench После ананоса сигналов преакта многие ринулись писать свои аналоги. А потом начали их бенчмаркать 🌚 Но что мерить и как? Нашли тест о Cellx, который проверяет возможности строить глубоковложенные связи(!) и немного его поменяв начали…
Важное замечание: в результатах отчетливо видно положение реатома ближе к концу списка. В среднем, реатом в раза три медленее самого быстрого решения.
Как же так, спросите вы? Я тут про перформансы и оптимизации рассказываю, а сам не могу либу сделать хотя бы в половину быструю солида?
Реатом под капотом делает очень дорогую операцию - создает кучу новых долгоживущих объектов. Каждый апдейт пораждает новый иммутабельный граф.
В простом коде вашей фичи это излишне, но и оверхед не будет заметен. Зато в более сложных случаях мы получаем из коробки стабильные стактрейсы и простую возможность дебажить апдейты любой сложности: синхронные и асинхронные. Попозже раскажу об этом подробнее, сейчас может звучать не поонятно, но я уверен что это очень ценная фича.
Это еще не все 🙂
Реатомовские атомы по умолчанию стейтлесс и работают только в каком-то контексте, который пользователь (разработчик приложения) должен создавать сам. Это упрощает тестирование и множественное инстанцирование (SSR) до одной строчки кода - создание нового контекста. Стоимость этой фичи можно наглядно увидеть в разнице бенча
Из этой же фичи следует отсутствие необходимости брать отдельную либу для DI - реатома вполне достаточно для большинства задач на фронте. Пакет
Как же так, спросите вы? Я тут про перформансы и оптимизации рассказываю, а сам не могу либу сделать хотя бы в половину быструю солида?
Реатом под капотом делает очень дорогую операцию - создает кучу новых долгоживущих объектов. Каждый апдейт пораждает новый иммутабельный граф.
В простом коде вашей фичи это излишне, но и оверхед не будет заметен. Зато в более сложных случаях мы получаем из коробки стабильные стактрейсы и простую возможность дебажить апдейты любой сложности: синхронные и асинхронные. Попозже раскажу об этом подробнее, сейчас может звучать не поонятно, но я уверен что это очень ценная фича.
Это еще не все 🙂
Реатомовские атомы по умолчанию стейтлесс и работают только в каком-то контексте, который пользователь (разработчик приложения) должен создавать сам. Это упрощает тестирование и множественное инстанцирование (SSR) до одной строчки кода - создание нового контекста. Стоимость этой фичи можно наглядно увидеть в разнице бенча
effector и effector (fork).Из этой же фичи следует отсутствие необходимости брать отдельную либу для DI - реатома вполне достаточно для большинства задач на фронте. Пакет
testing и гайд к нему уже готовится.❤5👍1🤔1💩1
useEvent отменили 💁♂️Напомню, в реакте есть проблема паразитных зависимостей, которые нужны лишь по запросу, но тк прокидывать в хуки их нужно синхронно, изменяясь они ломают мемоизацию и могут пораждать большие или просто избыточные ветви ререндеров. В сообществе эта проблема давно известна и каждый решает ее как может, вот вам самое маленькое и корректное решение:
export function useEvent<T extends (...args: any[]) => any>(callback: T): T {
const ref = useRef({
stableFn: ((...args) => ref.current.callback(...args)) as T,
callback,
});
// useLayoutEffect for React <18
useInsertionEffect(() => {
ref.current.callback = callback;
});
return ref.current.stableFn;
}
👍10💩1🤣1
В 2015 заканчивалось мое обучение на специалиста по информационной безопасности.
Учился я в МФПУ Синергия на вечерке.
Полезной нагрузки там было минимум по целому ряду причин. Но весной на госах мне повезло с вопросом и я сдал их на отлично, хотя программу знал максимум на 5%.
На работе в этот момент у меня было все ещё лучше, я был руководителем направления и получал кучу актуальных знаний. В общем, я как-то заморочился с вопросом справедливости моих оценок и бросил универ, забив на диплом, потому что посчитал что такая корочка - вранье и оскорбление, а не резльутат труда, которым можно гордиться.
Учился я в МФПУ Синергия на вечерке.
Полезной нагрузки там было минимум по целому ряду причин. Но весной на госах мне повезло с вопросом и я сдал их на отлично, хотя программу знал максимум на 5%.
На работе в этот момент у меня было все ещё лучше, я был руководителем направления и получал кучу актуальных знаний. В общем, я как-то заморочился с вопросом справедливости моих оценок и бросил универ, забив на диплом, потому что посчитал что такая корочка - вранье и оскорбление, а не резльутат труда, которым можно гордиться.
❤20💔8🤔3
artalog
Архитектура веба В комментариях к этому посту Никиты Прокопова опять начался дискурс об ошибочном применении веба (точнее браузерных технологий) для написания приложений. Мол, только нативные технологии, только хардкор, только так можно контролировать перф…
Только что @Akiyamka мне напомнил об еще одной важной архитектурной составляющей веба, добавил в пост (прочитайте целиком, если еще не видели):
8. The last, but not least. Исходники веб страницы открыты и кто угодно может их инспектировать и модифицировать. Редкая фича в нативке. Профит для пользователя в этом огромный: режим для чтения, контрастная тема, блокировщик рекламы, да просто свои стили или скрипты. Конечно, с этим есть сложности, особенно в плане безопасности. Но в конечном итоге, открытые платформы более надежны: они открыты для непредвзятого аудита и хотфиксы к ним делать проще.
8. The last, but not least. Исходники веб страницы открыты и кто угодно может их инспектировать и модифицировать. Редкая фича в нативке. Профит для пользователя в этом огромный: режим для чтения, контрастная тема, блокировщик рекламы, да просто свои стили или скрипты. Конечно, с этим есть сложности, особенно в плане безопасности. Но в конечном итоге, открытые платформы более надежны: они открыты для непредвзятого аудита и хотфиксы к ним делать проще.
👍14
Не знаю каким видео сегодня с вами поделиться, поэтому давайте сделаем AMA в 18-00 (GMT+3). Полайвкодю разнообразную работу на реатомом и поотвечаю на любые вопросы.
👍4