Продолжаю своё знакомство (первый опыт контакта был описан в посте про функциональные и интеграционные тесты) с детищем mail.ru - in-memory NoSQL базой данных Tarantool.

In-memory значит, что все данные она держит в оперативной памяти, то есть работает как кэш. Изначально это и был кэш над mysql. Постепенно тарантул мутировал и превратился в настоящего Арагога: под капотом интерпретатор языка Lua для написания хранимок, но можно запросы делать и на sql (к NoSQL базе, да).

Основные отличия от главного конкурента - кэша Redis - состоят в том, что Redis умеет работать как кэш для MongoDB, но при этом тарантул позволяет делать намного более сложные выборки: Redis работает как ключ - значение, то есть, выражаясь языком SQL, у него есть только индексированный primary key.

Тарантул же умеет строить сложносочинённые индексы из многих частей (до 256). Так что если нужны сложные но очень быстрые выборки - тарантул ваш выбор. Для пользователя тарантул не слишком дружелюбен. Впрочем, возможно дело в том, что официальной библиотеки для работы с тарантулом на c# от mail нету. Есть некая опенсорсная поделка, которая работает, и работает нормально, но в использовании она какая-то неудалая.

Данные в тарантуле лежат в space-ах - аналоге sql таблиц в виде кортежей: как строка в таблице. Но, в отличие от sql, жёстко фиксированы типы только столбцов, по которым строятся индексы. В остальных может быть суп из данных. Впрочем, если хочется, можно жёстко задать схему данных при создании space-а.

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

Предположим, хранятся у нас данные вида:
Id, Дата рождения, Фамилия, Имя, Отчество, Должность, Статус (работает/не работает), произвольная информация в следующих колонках. Индекс типа TREE (бинарное дерево под капотом) строится по всем полям, кроме Id. Он сможет отвечать на следующие запросы:

Фамилия
Фамилия + Имя
Фамилия + Имя + Отчество
Фамилия + Имя + Отчество + Должность
Фамилия + Имя + Отчество + Должность + Статус

В вот Фамилия + Должность - уже нет, для такого нужно создавать отдельный индекс или отправляться писать sql-запрос, который отрабатывает медленнее чем lua.

Первое знакомство с тарантулом скорее положительное, работает шустро. Главная претензия к шарповой обертке, там при написании кода получается дикая лапша, а еще без плясок с бубнами мне не удалось отправить в тарантул Guid (uuid, уникальный 128 байтовый идентификатор): превратил в строку, отправил в таком виде на сервер, там распарсил Guid обратно, что конечно дикость, но пока сойдет.

#tarantool
#кодинг

Начал знакомство с фронтендом: мир ReactJS ждёт.

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

Выбрал самый популярный из двух используемых для работы фреймворков (Vue и ReactJS).

Начал знакомство со среды разработки и на этом чуть не сломался: стандартный Visual Studio Code прям очень удручил, в итоге поставил WebStorm и дело сразу пошло.

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

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

Не прошло и двух месяцев, как я начал работать с Тарантулом, и только сейчас я наткнулся на красивое: https://try.tarantool.io/

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

#tarantool

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

В качестве базы данных использовал MongoDB. Вместо хранимок, продуманной схемы базы данных, primary и foreign ключей у меня теперь класс на 30 строк, позволяющий положить и прочитать любой другой класс из монги.

Update отдельных полей не предусмотрен, только insert, replace или find. Логика для замены и поиска передаётся в виде лямбда выражения. "Таблицы" - монговские коллекции - создаются по ситуации.

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

#кодинг

Прошли два месяца работы с тарантулом, и я наконец осознал (и отладил) адекватный способ хранить там слабо структурированную информацию: отправлять туда массив байтов byte[] из c#, а внутри тарантула соответствующее поле - string.

Принимать - тоже byte[]. string в тарантуле лежит просто как произвольная последовательность байт. Соответственно, никто не мешает хранить в этой куче байтов guid, который иначе без лишних преобразований из c# в тарантул не прокинуть.

Или - сериализовать в байты структуру (struct в c#, что-то типа класса, но хранится в стеке), или, вообще, использовать protobuf.

#tarantool
#кодинг

В условиях микросервисной архитектуры важную роль играют брокеры сообщений - обычно RabbitMQ или Kafka.

В кратце, соотношение плюсов и минусов между такое:
RabbitMQ - просто и сердито.
Kafka - сложнее, но лучше масштабируемо + возможность хранить историю прошедших сообщений.

Узнал еще преимущество Kafka: она оказывается умеет напрямую работать с базами данных: MongoDB, Tarantool, PostgreSQL, без самописных прослоек.

Впервые нашёл применение такому паттерну синхронизации межпоточного взаимодействия как семафор. Если в 2х словах, он ограничивает число потоков, проходящих через него. Поставил условные 50, и если к нему придут одновременно 1000 потоков, возникнет затор из ожидающих.

Я умудрился положить монгу большим числом параллельных запросов, при некоторых условиях их выстреливало больше 1000 сразу, после чего монга начинала кричать "остановись, демон" и кидала исключение. Семафор на 60 потоков меня спас, теперь всё отлично.

Погружаюсь в зловонную яму бездны фронтенда, а если точнее - React.js

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

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

#front
#react

Самый любимый человек - жена - завела канал, про книги, детские и взрослые.

Если кому интересна квантовая механика 0+ или развлекательное фентази - добро пожаловать.

P.S. Мы теперь семья блоггеров:)

В одном чате была затронута тема электробезопасности, потому выложу сюда байку по теме.

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

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

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

Одногруппники мне не поверили, потому трое по очереди брались за стенд под напряжением одной рукой и за "землю" - второй стенд - другой. Все соответственно получили. Откопали мультиметр - померяли - 220В.

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

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

Превращение человека в дачника во фронтендера стремительно и необратимо (с)

Вроде бы начал осознавать функциональные компоненты вместе с хранилищем состояний - Redux-ом. А React-то прикольный! Похоже, в стадиях заражения js-ом как мыслевирусом я сразу перепрыгнул на 5ю ступень.

На задворках сознания появилось желание вернуться к диссертации и сделать UI десктопного приложения на связке react + electron.

#front
#кодинг

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

Класс интерпретатора js внутри c# с вероятностью 10% создаётся косячным и при попытке использования (то есть интерпретации километрового js-скрипта) плюёт пустой эксепшн (без описания проблемы).

Воспроизводится только на 64 битах, 32 битная (которая использовалась при дебаге в те времена по дефолту) версия отрабатывает идеально.

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

И вот наступил момент запуска в прод, 64 бита и нагрузка. Пиковая нагрузка, внезапно съедается 100% ЦПУ, машина виснет (эксепшн - довольно тяжёлая операция). На поиск проблемы у меня-джуна ушло около месяца.

P.S. Это было в легаси коде.

#байки

Да, починилось всё очень просто: вместо создания экземпляра интерпретатора для каждого запуска скрипта (хз зачем так было сделано) я стал использовать синглтон, который создавался рекурсивно и проверялся простым скриптом "а = 0".

Небольшая ремарка о монге.

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

Если появляются дублирующиеся ключи - кидается исключение. Логично было бы ожидать, что запись всей пачки будет отменена. Но нет: все документы, которые могут провалятся в базу.

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

Возможно, есть обходные пути, но поведение "из коробки" - такое.

#кодинг
#mongodb

Наткнулся на подборку небольших околонаучных бложиков от уважаемого @trueresearch
Читал еще не все каналы, но подборка прям огонь:

Наступает пора конференций и отпусков, когда мой канал традиционно снижает активность. Тем не менее, я остаюсь на связи в комментариях и через @RResearcherBot, а посты продолжат иногда выходить — просто не слишком регулярно.

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

Авторское о жизни в науке и образовании:

https://t.iss.one/seryogaBombit - задорно-ироничный блог новоиспечённого кандидата технических наук
https://t.iss.one/consordino - блог почвоведа, личные мысли автора, рассказы о работе и немного научпопа
https://t.iss.one/VetusDepartment - замолкавшая и восставшая недавно Старая кафедра
https://t.iss.one/kavunnaya - блог квантово-механического теоретика
https://t.iss.one/sciencylife - живой канал биолога, немного в стиле Твиттера
https://t.iss.one/mikhail_ignatov31 - канал преподавателя философии из Белгорода
https://t.iss.one/tisnu_channel - о книгах и науке
https://t.iss.one/ragootootoo - блог преподавателя, с честными историями из жизни родной кафедры
https://t.iss.one/kantius - канал Анны Кулешовой об этике публикаций и многом другом
https://t.iss.one/Halls_of_Pilipenko - канал сурового проректора (наиболее живой из виденных мной аналогичных каналов)
https://t.iss.one/TiberiusRu - канал химика-материаловеда из Швейцарии

С уклоном в научпоп:

https://t.iss.one/newbioethics – блог о биотехнологиях
https://t.iss.one/sciscent - научный канал о духах (которые во флаконе, а не на спиритическом сеансе)
https://t.iss.one/ananikovlab - канал научной школы академика Ананикова
https://t.iss.one/memory_studies - про исследования памяти и истории, с юмором
https://t.iss.one/tozhe_nauka - прекрасный микроскопический канал о математических методах в литературоведении
https://t.iss.one/courageous_geologist - фоточки и мемы от геологов
https://t.iss.one/macevagram - исследования еврейских кладбищ
https://t.iss.one/georg_chronicles - что-то на инженерном
https://t.iss.one/radio_73 - ламповейший канал радиолюбителя, если не сказать радиофила

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

Всё это время я шёл true linux-way: цеплялся к контейнеру и прыгал по файловой системе через консоль, для просмотра текста используя vi.

Больше года я ходил вокруг стека ELK, думая, что вот надо, надо. Но никак не складывалось. И вот стукнуло: пора.

ELK - стандартное средство для сбора, хранения и визуализации логов. Расшифровывается как Elasticsearch (поиск и хранение) + Logstash (собор из разнородных источников) + Kibana (Визуализация).

Попытался завести в докере вместе со всем остальным решением образ sebp/elk. Не взлетело: не хватило оперативки (у меня было 16 Гб). Ну чтож, добавил её, стало 64.

Взлетело! Процесс vmmem, который по сути является внутренним линуксом винды, стал есть 36 Гб (!).

Относительно быстро разобрался, как писать логи стандартным инструментом Serilog из c# напрямую в эластик, соответственно Logstash стал мне не нужен, отключил его запуск в контейнере с elk.

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

#кодинг

Как нормальные люди пишут тесты? Выявляют кейсы, которые надо протестировать, пилят в той или иной форме генератор тестовых данных, покрывают кейсы тестами, а потом гоняют их и радуются.

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

Я попробовал, больше не буду идти на поводу у низменных желаний. Тесты написались мгновенно, закрыли существенную часть бизнес логики, всё просто отлично. Я продолжил работу над проектом и каждый раз при провале теста мне приходилось разбирать происшествие с двух сторон: что я сломал? Хм, вроде ничего. А теперь посмотрим юзеркейс и добьёмся воспроизводимости.

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

#кодинг