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

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

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

В иерархических структурах регулярно возникает потребность определить ближайшего общего предка в дереве, он же наименьший общий предок (Lowest (Least) Common Ancestor).

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

Привет! Меня зовут Денис, и я отвечаю за контейнерную инфраструктуру в Тензоре. Начну с начала. Когда-то Kubernetes-кластеров у нас не было. Зато были 2 дата-центра и 20 тыс. виртуальных машин на тысяче железных серверов. На этом великолепии и «крутились» продукты компании Тензор.

И появилась задача — перенести весь софт в контейнеры и в кубер. 

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

Ах, да, на данный момент у нас 30 K8s-кластеров на 4 площадках, 350+ нод. И мы активно мигрируем приложения с ВМ в K8s.

Поднимите руки те, у кого есть номер телефона... Вау, лес рук! Но знаете ли вы, что скрывается за этим набором цифр?

Среди применяемых в PostgreSQL методов доступа к данным Index Only Scan стоит особняком, считаясь у многих разработчиков "волшебной пилюлей" для ускорения работы запроса - мол, "Index Scan - плохо, Index Only Scan - хорошо, как только получим его в плане - все станет замечательно".

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

Всем привет от мобильной платформы компании "Тензор"! Меня зовут Галина и в этой статье я хочу поделиться историей развития нашего Share Extension и рассказать о том, как он превратился в отдельный модуль, конфигурируемый за счёт подключенных внешних зависимостей.

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

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

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

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

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

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

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