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

Время не стоит на месте. Вспоминая те далекие дни, когда все ходили в офис, пили утренний кофе в лоби‑баре, работали бок о бок в просторных оупенспейсах, а вечерами посещали корпоративный фитнес зал, становится немного грустно. Но что поделать... надо принимать обстоятельства и адаптироваться под них. Все‑таки творчество не терпит ограничений, особенно в сфере ИТ. Если кому‑то удобнее решать рабочие задачи в домашнем кресле — ОК! Значит пришло время научиться взаимодействовать с удаленщиками. Мы — создатели экосистемы СБИС, в ней есть супер‑удобные сервисы для такого режима работы — видеозвонки и вебинары. Утренние созвоны с командой, совещания, обсуждение насущных вопросов, возможность увидеться через 1000 км. и все это не выходя из дома.

Вебинары так вообще способны одновременно подключить до 10К человек! Согласитесь, удобно и время экономим, и во всех проектах без отрыва участвуем.

С работой разобрались, а что с развлечениями?

Давайте знакомиться, меня зовут Москалева Ирина, я — директор по развитию персонала Компании Тензор. Хочу похвастаться нашей насыщенной корпоративной онлайн‑жизнью и, главное, подчеркнуть, что всё создаётся руками увлеченных сотрудников, так сказать идейных энтузиастов. Итак, по порядку, сначала о сообществах по интересам:

При разработке приложений регулярно возникает задача кэширования каких-то данных, которые из хранилища должны читаться много чаще, чем писаться. Давайте рассмотрим на примере простого теста, когда и на каком механизме эффективнее организовать его для JavaScript-приложения - на Map или на Object.

Решим сегодня простую, казалось бы, задачу: как на PostgreSQL можно в строке провести замены по набору пар строк. То есть в исходной строке 'abcdaaabbbcccdcba' заменить, например, 'а' -> 'x', 'bb' -> 'y', 'ccc' -> 'z' и получить 'xbcdxxxybzdcbx'.

Фактически, мы попробуем создать аналог str_replace или strtr.

В нашем сервисе мониторинга и анализа PostgreSQL доступ к серверам осуществляется по протоколу SSH. В качестве ssh-клиента мы используем популярный модуль SSH2 , однако при передаче данных большого объема этот модуль вносит существенные задержки в event loop. Как их можно снизить - расскажем в этой статье.

В большинстве учетных систем, типа нашего СБИС, рано или поздно возникает проблема быстрого отображения реестра, в который по просьбам бизнес‑пользователей накручено несколько комбинируемых фильтров с очень редкой выборкой, ну никак не ложащихся в вашу красивую структуру базы данных и индексов базовой таблицы реестра — что‑нибудь типа "список продаж покупателям, чей день рождения выпадает на 29 февраля".

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

На примере простой задачи клонирования ключей объекта посмотрим, есть ли реальные альтернативы по производительности столь презираемой JavaScript-разработчиками функции eval().

Подобная задача возникает, если оригинальное значение ключа надо оставить у объекта, а как-то обработанное - положить рядом в новый соответствующий ключ. То есть, для начала, из {"a" : 1, "b" : 2} надо получить {"a" : 1, "a-copy" : 1, "b" : 2, "b-copy" : 2}.

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

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

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

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

Если не видели дайджест за прошлый год — время наверстать упущенное!

Привет ХАБР. Тема, которой посвящена эта статья с одной стороны важна, ведь в кибер-пространстве «неспокойно». Каждый день приходят новости, что ту или иную компанию взломали хакеры, получили дампы или зашифровали данные. Защищаться от кибер-угроз, выстраивая целую инфраструктуру из всевозможных средств защиты хорошо и нужно, но никогда не стоит забывать о разведке. В кибер-пространстве как в армии. Хорошо, когда на границах вырыты окопы, дежурит артиллерия и ПВО, но без разведки не понятно куда и чем противник будет атаковать. В цифровом мире базовая военная стратегия в целом не отличается. Разведка важна и нужна, чтобы быть готовыми и собирать данные, которые собирают злоумышленники о вас и вашей инфраструктуре. В этой статье разберем вопрос о том как создавалось направление кибер-разведки(OSINT open-source intelligence ) в компании.

С чего зародилась идея создания направления OSINT?

В наше время стал мейнстримом тренд на защиту персональных данных и всякой конфиденциалки в компании. Запрос на поиск источников утечек и их закрытия очевиден. Самое сложное расставить приоритеты или ответить на вопрос: "Что будем собственно искать?" Если открыть внутренние документы любой компании, то сведений, составляющих какую-либо из тайн (персональные, конфиденциальные, коммерческие) большое количество. Важно выбрать те, которые являются самыми важными для контроля и утечки которых реально можем находить и устранять.

Путем расстановки приоритетов и реальных возможностей мы выделили основные направления для OSINT:

Достаточно часто при проектировании схемы БД возникает задача сохранить по основной сущности некоторый набор простых второстепенных данных.

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

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

Давайте посмотрим, какие варианты хранения таких данных мы можем использовать в PostgreSQL, и какой из них окажется в разы более эффективным.

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

Как больно наступить на грабли в совсем простом, казалось бы, запросе?

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

Наверняка, многие из вас пользуются explain.tensor.ru - нашим сервисом визуализации PostgreSQL-планов или уже даже развернули его на своей площадке. Но визуализация конкретного плана - это лишь небольшая помощь разработчику, поэтому в "Тензоре" мы создали сервис, который позволяет увидеть сразу многие аспекты работы сервера: медленные или гигантские запросы, возникающие блокировки и ошибки, частоту и результаты проходов [auto]VACUUM/ANALYZE.

И сегодня мы, наконец, готовы представить вам демо-режим этого сервиса, куда вы самостоятельно можете загрузить лог своего PostgreSQL-сервера и наглядно увидеть, чем он у вас занимается.

В прошлых частях цикла мы:

- рассмотрели базовые концепты работы с многопоточностью в JavaScript на примере среды Node.js;

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

- использовали разделяемую память и Atomics-операции как самое быстрое средство обмена большими блоками данных;

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

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

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

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

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

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

Привет, ХАБР. В настоящее время для каждой компании стает ребром вопрос информационной безопасности. С одной стороны растет количество кибер-атак, с другой растет ответственность компаний за сохранность информации, тех же персональных данных. Как говорится, ставки со всех сторон растут и поэтому наличие в штате сотрудников, осуществляющих инфобез уже не является вопросом, а скорее аксиомой. В этом статье, на основе своего профессионального опыта я расскажу, как можно защищать внешние информационные ресурсы компании, через их регулярный пентест и почему важно пентестить на регулярной основе.

 Для простого понимания сути темы, отвечу на типичные вопросы:

Что такое Пентест?

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

Почему безопасностью должен заниматься отдельный сотрудник, не отвечающий за настройку/работу сервиса?

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

Я слышал, что есть основное разделение инфобезопасников на защищающихся (blue team) и атакующих (red team). Так чем этот подход плох?

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

Но тут возникает две проблемы:

1. как эффективно доставить данные в обрабатывающий поток

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

В этом нам как раз и помогут два рассматриваемых в этой статье концепта работы с многопоточностью: разделяемая (shared) память и потокобезопасные (thread-safe, Atomics) операции над ней.

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

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

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

В прошлой статье мы рассмотрели реализацию эффективной очереди на основе "эластичного" кольцевого буфера, а в этой попробуем разобраться с особенностями использования модуля Worker threads в Node.js - какие проблемы внедрения многопоточности будут нас ждать при попытках сделать код более производительным, и узнаем, как их можно обойти, применяя типовые концепты.

Начнем с достаточно типовой задачи: мы получаем некоторые сообщения, и нам их надо как-то обработать. В качестве тестового примера сгенерируем эти сообщения самостоятельно, и посмотрим, за какое минимальное время мы сможем вычислить SHA-256-хэш для каждого из них.