В общем когда-то (уже достаточно давно) я пытался отслеживать свои траты и делать какой-то анализ этих данных. Я знал про таблицу из Т-Ж, всякие коинкиперы и другие прилаги. Проблема всех этих приложений (как мне казалось), что все они заставляют вас считать эти сраные копейки, сколько ты потратил на кофе, сколько ты потратил на обед. Записывать все это в ручном режиме казалось мне каким-то бесовством.

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

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

Я придумал название КопиКупи, купил домен, даже нашел дизайнера и нарисовал первые макеты, но лень и прокрастинация так и не дали этому проекту возможности родиться.

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

#идеястартапа

Помню году так в 2011-2012 я помогал с кодом на одной (на тот момент достаточно популярной) блоггинг платформе mmm-tasty и Андрей Зотов, в какой-то момент пытавшийся оживить проект, рассказывал как важно в самом начале придумать хорошее название. И один из важных моментов хорошего названия это его читаемость и воспринимаемость на слух, с чем у тейсти как раз, очевидно, были проблемы.

Представляю этот разговор с инвестором:

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

https://incrussia.ru/news/mmhmm-2/

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

Примерно, в 2012-2013 пришли первые запросы на интеграцию сервисов онлайн-телефонии, а этим ребятам требуется постоянный коннект с сокетом, чего та версия системы предоставить не могла, так как каждый переход между страницами полностью обновлял страницу. Мы начали делать SPA (Single Page Application). В то время я прочитал книгу Стояна Стефанова “JavaScript. Шаблоны” и как любой уважающий себя начинающий разработчик начал применять новые знания в деле - писать свой велосипед. Так зародился мой модульный загрузчик DepmanJS (от Dependency Manager). Вот пример модуля:

depman.use([], function () {
return {
sum: function (a, b) {
return a+b;
}
};
}, 'sum.calculator’);

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

Я его даже начал внедрять в редизайн-версии amoCRM, но по мере продвижения по задачам это все больше казалось плохой затеей. Каждый раз появлялись какие-то новые кейсы, которые не покрывала библиотека. Например, нужно было использовать сторонние библиотеки, которые либо регистрировали свою переменную в window, либо поддерживали нотацию AMD (о существовании которой я еще не знал). Я на коленке запилил поддержку сторонних библиотек через конфиг. И так постоянно - помимо решения основной поставленной бизнес задачи я решал какие-то мной же изобретенные проблемы из-за своего велосипеда.

В какой-то момент я понял, что делаю что-то не то, а может я увидел AMD запись в какой-то из библиотек, уже не помню, но я начал искать существующее готовое решение. И, конечно же, оно нашлось - requirejs. На тот момент это был самый популярный по звездочкам на гитхабе проект такого рода, а всеми любимого сейчас webpack не было еще в зародыше (хотя может в зародыше уже был, но точно не в опенсорсе). В нем были решены все те проблемы, которые я уже решил в своем Depman, и которые мне предстояло бы решить, если бы я не прекратил заниматься самореализацией.

❞ Забавно, что не зная о существовании requirejs, мой модульный загрузчик получался с очень схожим API и структурой конфига.

Этот момент стал первой значительной трансформацией меня как разработчика, потому что с этого момента я понял, что всегда когда хочется начать писать какой-то свой велосипед надо хорошо поискать и в 99% случаев уже есть готовая библиотека решающая твою задачу, оттестированная и поддерживаемая сообществом, с продуманным и удобным API.

Про внедрение requirejs, систему виджетов расскажу в следующей части.

А дальше что? Пароли в открытый доступ сольют? Долбоебы

​​1Password, лучшая хранилка паролей, удалила приложение из русского апстора.

Вот это, извините, полный пиздец. Этим приложением пользуются журналисты и другие люди под ударом для того, чтобы защититься от властей.

А что делать, если у человека уже там все пароли, и новый телефон, или он удалил приложение для пересечения границы?

Я могу понять эмоции, но суть взрослого поведения — это то, что несмотря на эмоции мы выбираем, что делаем. Где ответственность, Карл?

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

Salesbot Designer

Наткнулся я тут на опенсорсную либу для построения node-based редакторов - reactflow.dev и решил написать историю создания нашего в #amocrm Salesbot дизайнера. Тем более, глянув в дев-тулзы и код, оказалось, что схема работы либы архитектурно очень похожа на нашу, а учитывая что, судя по гитхабу и блогу, зарелизились они в 2020 году - есть мнение, что сэйлсбота они как минимум видели или даже изучали.

Дело было в 2018 году перед релизом и конфой в Сан-Франциско, у нас тогда уже был бот, который работал через JSON-спецификацию и использовался в основном в наших собственных аккаунтах, ну и у тех, кто работал с партнерами. Появилась задача сделать визуальный редактор, чтобы любой юзер мог без помощи разработчиков сконструировать хотя бы простой сценарий бота с запросом контактных данных, это и было показано в демо на презентации.

И вот сидя в Варшаве, ожидая сначала записи на собеседование на визу в США, а потом паспорта с вклеенной визой (вот было время, да?) я пилил наш конструктор ботов. Так как до этого я не делал таких задач сначала попытался поискать примеры на существующих решениях, погуглил D3.js, но каких-то готовых вариантов не нашел, поискал на гитхабе, тоже ничего толкового от чего можно оттолкнуться не нашлось. Это сейчас с такими библиотеками у них целая категория, а тогда ничего подобного не было.

Я начал экспериментировать в CodeSandbox, для начала пробовал рисовать на канвасе и зачем-то хотел решать коллизии стрелок, но меня вовремя остановили, остался вот такой прототип. Канвас не подошел еще и потому, что по дизайну нам нужно было редактирование “по месту” в перетаскиваемом блоке, а нормальной ui библиотеки для канваса, чтобы были все необходимые контролы (плюс они еще и должны быть в привычном для пользователя системы виде) - тоже не было.

Поэтому в какой-то момент мне пришла идея, чтобы блоки были обычными div-элементами, а стрелки рисовались на отдельной svg-ноде, которая бы лежала внизу под ними. Для drag’n’drop’а изначально я заюзал jQuery UI, так как она использовалась внутри amoCRM, а для зума и панорамирования в редакторе - jquery.panzoom.

Рабочая область src/workarea/index.js Cостоит из блоков и связей.

Блок src/workarea/block/index.js Вьюшка блока. Блок можно перетаскивать и добавлять в него экшены.

Экшен src/workarea/action/index.js Это базовый структурный элемент блоков, каждый блок должен содержать хотя бы один экшен. Примеры экшенов: сменить этап сделки, установить значение поле, отправить сообщение и тд.

Стрелки src/workarea/connections/connection.js Обычная стрелка от одного блока к другому. Каждая стрелка знает из какого блока она начинается (start_block) и в какой блок ведет (end_block). В этих свойствах хранятся модели соответствующих блоков. При перетаскивании у них обновляется x, y координаты, изменение которых слушают стрелки и также реагируют на изменение.

Стрелка goto src/workarea/connections/goto_connection.js Ведет не напрямую к конечному блоку, а рисует голубой прямоугольник с индексом конечного блока. Используется если goto ведет на какой-то предыдущий шаг, либо если goto перескакивает на несколько шагов вперед.

Спустя пару лет после создания конструктор ботов понадобился и в другом нашем проекте амо | корпоративный мессенджер. И вот тут я пожалел, что не подумал сразу о переиспользовании и довольно сильно на старте завязался на стек amoCRM. Так как пока конструктор был частью продукта он был построен на том же backbone + jquery, а вынув его в отдельную библиотеку для amoCRM получился хоть и небольшой, но оверхед по этим компонентам, однако, lazy-loading нас выручит и не будем сильно переживать по этому поводу.

Конечно, к тому моменту, когда потребовалось вытащить это все добро в самостоятельную библиотеку накопилось уже много опыта и что-то можно было сделать по-другому, но релиз был и в amoCRM и в мессенджере, поэтому времени было немного - я где-то за неделю-полторы распилил конструктор в отдельную библиотеку, выделил собственные сущности конструктора, внешние сущности типа полей (для amoCRM это поля сделок, например, а для мессенджера это собственные поля бота или формы внутри бота), избавился от зависимости от jQuery UI, переписав на нативные события, так как она довольно большая и все-таки грузить два ее экземпляра в amoCRM не хотелось.

Дальше конструктор нужно было оформить как переиспользуемый модуль. Вынес его в отдельный репозиторий в гите и на тот момент (это примерно 2020 год) я выбрал способ подключения в проект как git submodule, хотя сейчас бы рассмотрел lerna или модуль из внутреннего репозитория в package.json.

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

На выходных обновил персональную страницу.

Во-первых, недавно я купил домен egor.sh. Да, 16к рублей на reg.ru в год и 83$ - 30% по нагугленной скидке за 5 минут на godaddy за 2 года.

Во-вторых, обновил основной фреймворк nextjs до 13 версии. Мне всегда он нравился как с точки зрения DX, так и фокуса на производительности работы. Вам не нужно ковыряться в конфигах, чтобы все само собиралось как в прод, так и в дев с оптимальными настройками.

В новой версии завезли React Server Components, по-моему первые из всех разработчиков фреймворков. Новую файловую структуру, мидлвэры для модификации запроса до того как он будет обработан. Например, у меня из запроса получается заголовок Accept-Language и по нему показывается английская версия, если предпочтительный язык браузера пользователя не русский.

Из коробки доступна оптимизация изображений, nextjs за вас сожмет картинку на лету и пользователь загрузит ее в минимальном обьеме для его устройства.

Ну и вишенка на торте это облачный сервис от создателей фреймворка - Vercel. Во-первых, интеграция с гитхабом через OAuth и все, что нужно потом сделать для деплоя приложения это пуш в мастер. Так же доступны тестовые стенды, env-переменные и все-все-все, что необходимо нормальному сервису. Во-вторых, сам фреймворк отлично интегрирован в эту систему и сжатие изображений, про которое я говорил выше, кеширует результаты на их же CDN. Так же в CDN можно закешировать результаты работы API-запросов, если требуется, и делается это минимальным количеством телодвижений в коде.

В общем, да, я в восторге от того как фреймворк и сервис развивается.

Ну и по-мелочи еще перевел стили на tailwindcss с поддержкой темной темы, попробовал в 3d с react-three-fiber (текстура для шара там мегабайт весит, поэтому грузится долго - пока было лень придумывать что-то с заглушкой, а с пол тычка не получилось).

Посмотреть вживую egor.sh или в коде https://github.com/egorshar/homepage

Tinkoff оказывается "пробует" в open-source, наткнулся на их github-аккаунт.

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

Забавно другое, это, собственно, их тот самый open-source. Бегло глянув репы, выглядит это как сборничек своих велосипедов, зачем-то вынесенный в паблик. Похоже, что основа кодовой базы или когда-то была, или до сих пор написана на Angular и решения оттуда так близки команде, что они пытаются перетащить их на рельсы других библиотек, это я про tramvai.

Или набор утилит utils.js с обязательным бенчмарком, что оно быстрее и тоньше lodash, только самым первым почему то сравнивается импорт полной библиотеки lodash, но это ладно, так положено во всех бенчмарках, лол.

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

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

Хороший пример организации большого и сложного приложения на nextjs 13 (написано на typescript). Причем это не стартер, а прям прилага, которую можно изучать как пример того, как выглядит современное веб-приложение с использованием данного фреймворка. Тут и новый роутинг, и серверные компоненты, и остальные новые фичи. Ну и темная тема в комплекте, конечно 🫡

Million.js

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

Когда-то в мир пришел React и все начали повторять как мантру, что он очень быстрый из-за своего механизма virtual-DOM. Кто-то может даже слышал мем 'the virtual DOM is fast', often said to mean that it's faster than the *real* DOM. Пошло это с конфы 2013 года с кор разрабом React, который это сказал. Правда потом он поправился в духе, что “вы можете написать что-то на ассемблере и превзойти компилятор C, так же как вы можете руками манипулировать с DOM и сделать что-то быстрее, чем React, но с React вы можете разрабатывать не задумываясь о производительности, а приложение будет по умолчанию быстрым”. Если хотите почитайте первоисточник из блога svelte.

Если коротко, то virtual-DOM это всегда оверхед, потому что для синхронизации состояния приложения с реальным DOM-ом (так называемой “реконсиляции”) будет всегда происходить дополнительная работа браузера.

И вот тут на сцену в белом выходит Million.js (если что у них на сайте прикольная демка, можете поиграться).

Суть его работы в статическом анализе, с помощью которого динамические части виртуального DOM выделяются в некую мапу EditMap, в этой мапе грубо говоря хранятся инструкции для редактирования реального DOM-дерева и при изменении состояния компонента реальный DOM обновляется напрямую через этот EditMap. Однако, хоть они и заявляют, что “just wrap your React components” - у всего на свете есть своя цена. Поэтому есть куча ограничений, например, нельзя в conditional return или вывод дочернего JSX. Вот например, что нельзя из доки (а мы ведь это все часто используем):

function IllegalComponent({ name, initial }) {
const [count, setCount] = useState(initial.count);
const greeting = `Hello ${name}!`;

if (count > 10) {
return <div>Too many clicks!</div>; // ❌ don't use conditionals
}

return (
<div>
{greeting}
<button onClick={() => setCount(count + 1)}>
{<div>{count}</div> /* ❌ don't pass JSX */}
</button>
</div>
);
}

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

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

Короче, эти умельцы научились по сигналам из аппарата МРТ с помощью модели Stable Diffusion генерировать видео “что сейчас видит человек, который подключен к аппарату”. На картинке коты сверху это видео, которое показывается человеку, коты снизу это сгенерированные нейросетью кадры на основе сигналов, считанных из головного мозга.

WAT?

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

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

Во-первых, если тупо раз в, к примеру, 120 мс обновлять позицию курсора, то уже анимация получается рваной, так плюс, что в реальной жизни к такому тротлингу надо прибавить еще от 5 до 15 мс. Итог в реальном приложении с сетевыми лагами будет еще хуже.

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

Следующий вариант решения - это spring animations. Тут отличие от обычной transition-анимации в том, что используются не только координаты до и после, но и текущий импульс. За счет этого анимация получается более плавной.

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

Как всегда в первоисточнике все более точно и с крутыми демками, поэтому почитайте и потестите, если интересно.

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

Такс, почти неделю ничего не писал, исправляюсь.

Когда мы говорим про React и стейт-менеджмент почти всегда мы думаем про Redux и это не значит, что других нет, просто это уже такой стандарт и все им пользуются (и не всегда оправданно), что я как-то и не следил, что нового в этой теме появляется.

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

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

import { create } from 'zustand'

const useBearStore = create((set) => ({
bears: 0,
increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
removeAllBears: () => set({ bears: 0 }),
}))

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

function BearCounter() {
const bears = useBearStore((state) => state.bears)
return <h1>{bears} around here ...</h1>
}

Либа небольшая по размеру, имеет 30к звезд на гитхабе, решает многие дефолтные проблемы гонок, потери контекста и тд. Ну и посмотрите какой параллакс из 2013 у них на сайте.