Как видно из таймлайна этого канала - создал я его еще в 2018 году, но прокрастинация и лень сделали свое дело, первое сообщение было написано только в 2020. Что ж, попробую все-таки его оживить, может быть, что-то и получится.

Меня зовут Егор Шарапов @egorshar, я лид фронтэнд разработчик в amoCRM, общий опыт веб-разработки более 10 лет. Здесь буду делиться своими мыслями, примерами решений и писать про последние штуки в веб (и не только) разработке, которые меня зацепили.

Stay tuned!

Интересное видео о создании оригинального Prince of Persia.

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

https://youtu.be/sw0VfmXKq54

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

https://github.blog/2020-04-14-github-is-now-free-for-teams/

Когда-то ещё в школе я ходил на дополнительные занятия по программированию. Я тогда ещё только начал вообще разбираться, что такое функция, цикл и тд, все мои знания были на уровне html/css и простых сайтов.

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

Я решил какую-то очередную задачу быстрее всех, сказав об этом преподавателю он посмотрел на код и сказал: «Хорошо, а как решить это за один проход цикла?» Вместо ожидаемой похвалы за быстрое решение, я вернулся к обдумыванию задачи и поиску более производительного решения.

С того момента при решении любой задачи я сам задаю себе этот вопрос.

... Microsoft стала использовать правило Цукерберга “Двигайся быстро и ломай. Если ничего не ломаешь, значит, двигаешься недостаточно быстро” ...

Спасибо Марк, теперь у меня есть, что ответить, когда обнаружили, что сломалась какая-то штука в системе. Мы просто очень быстро двигаемся.

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

И тогда я попробовал реализовать свою концепцию финансового планирования личного бюджета. Базовая идея основывается на таблице, мы задаем ежемесячный доход, потом задаем ежемесячные постоянные траты (аренда, коммуналка, 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). Причем это не стартер, а прям прилага, которую можно изучать как пример того, как выглядит современное веб-приложение с использованием данного фреймворка. Тут и новый роутинг, и серверные компоненты, и остальные новые фичи. Ну и темная тема в комплекте, конечно 🫡