Саша говорит

2021-11-29 14:29:53 Как вы пишете тесты на штуковины, которые внутри имеют кучу асинхронщины и совершают какие-то действия неявно?

Проблема такая:

Дёргаем ручку, которая стартует некий процесс
Ждём пока не произойдут какие-то действия (например, оно сделает два внешних запроса)
Как понять, что после того как мы дождёмся ожидаемых действий код не делает каких-то дополнительных, которых быть не должно?

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

У себя решаю это объектом индикации работы, который имеют практически все такие асинхронные обработчики. Когда что-то начали делать — зарегистрировали таск в этом объекте. Когда закончили — финишировали его. Если счётчик текущих задач больше нуля значит что-то ещё происходит. Плюс возможность подписки на изменения этого статуса, объединения нескольких статусов в один.

Тогда получается что у всего приложения есть состояние «я ещё что-то делаю». С ним тесты писать становится куда приятнее. Мы не ждём N определённых событий, мы дёргаем что нам нужно, дожидаемся пока система скажет что она в idle-режиме, после чего смотрим, что она в итоге сделала.

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

Пример — фреймворк для телеграм-ботов telegraf. Я могу сделать инстанс бота, дать ему урл фейкового телеграма (где поднимаю свой моковый сервер ботового телеграм-апи), вызвать метод «держи апдейт, обработай». Но сколько мне затем нужно подождать после этого чтобы взглянуть на массивчики сообщений которые бот отправил — непонятно. Ибо внутри обработчики выполняются в цепочках промисов, которые разбиты отдельными асинхронными операциями самой бизнес-логики.

Для этого кейса пришлось выкинуть использование библиотечной логики middlewares, обработчиков команд и написать вместо этого своё, которое умеет говорить, когда собственно обработка всех событий завершена и больше ничего происходить не будет. Открыть/Комментировать

2021-11-23 17:21:49 По поводу прошлого поста — я врал. В итоге пришлось полтора дня потратить, чтобы всё посчитать самому. Открыть/Комментировать

2021-11-18 09:58:50 Нужна ли программисту математика? Как человек слегка помешанный на теории типов сказал бы что программирование и есть конструктивная математика (если система типов позволяет описывать теоремы). Но если на общечеловеческом, то чаще всего нет. Ещё точнее — смотря чем приходится заниматься.

Только что словил такой пример. Нужно мне картинку повернуть на какой-то градус. А вместе с ней прямоугольник выделения.

Сразу начинаешь думать, ёмаё, сейчас придётся полчаса на листочке синусы/косинусы вспоминать и гуглить, как точку повернуть относительно некой оси вращения.

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

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

Опять никакого фана :) Открыть/Комментировать

2021-10-28 10:41:05 Что-то захотелось небольшой перевод реддитового поста сделать, понравилась мысль.

https://zen.yandex.ru/media/id/607d6fdbc5028366d9b988dd/617a48baebd05d78a724c187
https://www.reddit.com/r/gamedev/comments/qeqn3b/despite_having_just_58_sales_over_38_of_bug/ Открыть/Комментировать

2021-10-12 02:01:05 Не знаю уже сколько месяцев по капельке рефакторю Shieldy (телеграм-бот для каптчи в группах). Начал с того чтобы прогнать prettier, пофиксить eslint'ом всё. Затем зачем-то захотел включить strict-режим у тайпскрипта. В итоге так много всего наменял, что стало очевидно, что без тестов в мастер мне самому страшно это мержить, начал их писать, да так и не закончил (хотя фундамент заложен).

Однако он и так более или менее работает, что уже радует. Форкал из-за того, что не приняли PR с фичой кастомного каптча-вопроса. Ну, как не приняли, просто забили, так и висит уже почти полгода. Зато какие-то премиумные фичи допиливаются. А боты уже научились и примеры решать, и картинки разгадывать, и по баклажанам нажимать.

Сегодня посоветовал ещё одному чату добавить немного сесуриту, оставлю тут инструкцию, на всякий случай:

Добавьте @sesuritu_bot , дайте ему прав на удаление сообщений и выдачу банов.

Затем отправить такую фигню:


/setConfig@sesuritu_bot
captchaType: custom
restrict: false
noChannelLinks: false
adminLocked: true
strict: true
deleteEntryOnKick: true
cas: false
allowInvitingBots: false


Включит кастомный тип каптчи, будет удалять “Someone joined the group” если не прошёл каптчу. Затем:

/addCustomCaptcha

Там ответить на сообщение с вопросом, затем с ответом. Например:

Вопрос: Каков ответ на главный вопрос жизни, Вселенной и всего такого?
Ответ: 42,сорок два,сорокдва

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

Дисклеймеры: поддержка у бота такая себе, не особо находится время им заниматься, но если пинганёте, что он упал, то за сутки точно должен буду починить; машинка на которой он сейчас крутится копеечная, но по моим прикидкам этот бот не будет использоваться в таком количестве чатов с такой активностью, чтобы начать педалировать. А если будет, то по тому что я в нём видел, там оптимизировать и оптимизировать, оно и на кофемолке может пережёвывать всё что приходит. Но этим я тоже заниматься пока не планирую. Открыть/Комментировать

2021-09-16 11:56:38 Докинул себе push-it и push-it-force алиасов, жить стало попроще:


fixup = commit --amend --no-edit
upstream-it = "!bash -c 'BRANCH=`git rev-parse --abbrev-ref HEAD`; git branch --set-upstream-to=origin/$BRANCH $BRANCH'"
push-it = "!bash -c 'BRANCH=`git rev-parse --abbrev-ref HEAD`; git push origin $BRANCH'"
push-it-force = "!bash -c 'BRANCH=`git rev-parse --abbrev-ref HEAD`; git push origin --force-with-lease $BRANCH'"


Это самые бесячие операции, когда нужно копировать название текущей ветки постоянно. Надеюсь, что rev-parse меня не подведёт и я не запушу какой мастер с форсом, когда нахожусь в ветке которая там же находится, где и другая. Открыть/Комментировать

2021-08-18 09:43:26 До текущего места работы встречался/читал только про следующие архитектуры (относительно бэкенда):

Монолит — всё влазит на один сервер и пока хватает, масштабировать пока приходится только БД.
12factor — группа независимых фронтендов, нагрузка на которые балансируется, они могут ходить в другие сервисы, плюс это всё приятно деплоится и конфигурируется.
Кворумы — назову так сервисы, которые формируются из группы серверов, которые занимаются одним типом задачи, но перекладывают работу друг другу. Обычно это базы/очереди всякие.
Микросервисы — когда типов задач становится много и их выполнение разделяют по разным сервисам, ну а они ходят друг к другу сами/через очереди.
Копролит — был хороший такой монолит, но стало сильно дорого в сервер добавлять процессоры и оперативку, часть монолита вынесли в другой монолит и на самом деле просто вызов кода стал асинхронным.

Ну и вот сейчас познакомился с, как написали в комментариях на хабре, «гибрид Service Mesh и API Gateway».

Чуть больше почитать можно тут — https://habr.com/ru/company/yandex/blog/520134/ . А я кратенько расскажу, в чём суть и почему лично мне это нравится.

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

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

Чем это выглядит приятным для меня?

У запроса есть уникальный идентификатор, который можно глянуть в заголовках ответа. С ним можно сходить в trace'илку, оно покажет все запросы которые делались для выполнения этого запроса и одним взглядом можно понять, какой сервис виноват.
Когда тебе возвращаются какие-то левые данные от финального сервиса и ты не понимаешь, это он косячит, или оригинальные данные кривые, можно добавить запросу магический параметр что добавит в ответ телеметрию, где будут все запросы и все ответы между сервисами, которые были совершены для обработки этого запроса. Крааайне удобно иметь возможность глянуть на сырые данные.
Разрабатывать любую из частей сервиса очень удобно, один раз даже попробовал. Разворачиваешь кусок системы на дев-машине, а затем просто идёшь на обычный тестовый стенд и в запрос добавляешь магический параметр который говорит «подмени вершину графа такого типа вон той машинкой». В итоге сервисы начнут ходить к тебе (точнее аппхост, когда один из сервисов попросится по этому типу) и не нужно поднимать весь остальной зоопарк.
Можно смотреть в одну точку сбора ошибок, чтобы увидеть, что каким-то сервисам явно нехорошо.

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

И минусы явно сильно компенсируются удобством разработки/отладки. Открыть/Комментировать

2021-08-17 01:21:30 Сон не пошёл, пошла идея приложухи.

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

Так вот, про приложуху: очередной таск-менеджер для такого лентяя как я.

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

Но это всё не то. Оно работает только тогда когда тебе на самом деле никакие приложухи не нужны, ибо лишь бы дело было, оно будет делаться. Глаза горят, руки делают, просыпаться легко, постоянный поток. А когда ты себя и таймер помодорки не можешь заставить запустить, либо вполне можешь посередине сказать «не, ерунда, пойду поем», всё не так хорошо.

У меня обычно нет каких-либо прям срочных задач вне работы, главное чтобы их количество не росло и желательно чтобы иногда схлопывалось в ноль. Плюс хотелось бы чтобы планирование автоматизировало эти самые вопросы вроде «что сегодня поесть» и «чувак, давай сегодня хотя бы кружок вокруг квартала».

Я джва года хочу такую игру, суть такова...

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

Ну а дальше всё ограничивается только фантазией придумывания правил. Можно, например, сделать карту, которая говорит «сегодня идёшь в магазин, берёшь там A, B, C; завтра вместо карты этого типа юзаешь эту, вот рецепт борща». Одноразовые задания говорят «вместо сброса выкинь меня». Немного пустых карт полного безделия. Пара джокеров разных типов, позволяющих без штрафа перевытянуть карту, либо замешать её в колоду без штрафа. Открыть/Комментировать

2021-07-25 20:57:25 Слоупочу лет на десять, только сейчас узнал:

> IOS is a trademark or registered trademark of Cisco in the U.S. and other countries and is used by Apple under license.

wut? Открыть/Комментировать

2021-07-15 08:01:07 Чем больше я на нём пишу, тем больше мне кажется, что TypeScript это заговор. Не в том смысле, что все им обезумели и это плохо, нет. Это хитрый заговор типоманьяков, чтобы незаметно принести в массы более сильные типизации, что крайне плохо получается классическим Haskell/Idris путём.

Есть такая штука как лямбда-куб, существует всего три «мощности» типизации:

значения зависящие от типов — здесь находится подавляющее большинство современных типизированных ЯП, это дженерики функций/классов (кроме Go )
типы зависящие от типов – это не дженерик-типы, как можно подумать, а возможность делать функции над типами. Чтобы, например, вернуть совсем другой тип (с другими полями и методами), если он параметризирован числом, а не строкой.
типы зависящие от значений – это не C++ шаблоны, как можно подумать, а возможность задавать значениям характеристики и валидировать их на этапе компиляции. Чтобы, например, у массива физически нельзя было вызвать получение элемента за его границами (не буду в этом после снова объяснять, как это возможно).

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

И тут приходит TypeScript и говорит «буду ECMAScript типизировать». Все крутят пальцем у виска, мол, он же изначально динамический, чего ты там типизировать собрался, это безумие. Примерно так оно и есть, что-то хорошо типизируется, что-то хуже. И чтобы покрыть все возможности динамического JS приходится прокачивать систему типов.

... вдруг у нас появляются всякие Conditional Types и много всего остального, на чём такого можно наворотить, что сон потеряешь как это увидишь. Я просто уверен, что из общеиспользуемых ЯП в тайпскрипте первым появятся зачатки зависимых типов. И это будет подано под соусом вроде «мы тут в стандарте вот такую вот функцию хитрую нашли, мы её вот так вот типизировали, для этого ввели вот такой вот странный механизм, но всё работает». И никто ничего не заметит, что теперь чтобы написать функцию нужно теорему доказать, BWAHAHAHA. Открыть/Комментировать