Каждый год мы с друзьями коллегами ходим в баню снимаемся в новогодних клипах. А все почему? Потому что в компании Тензор, где я работаю, новый год празднуют минимум дважды: офлайн и онлайн.
Если у вас много удаленных сотрудников, обширная география филиалов или просто есть желание растормошить интровертов - велком в статью-проводник по организации онлайн-корпоратива :)
В Тензоре около 7 тысяч сотрудников и более 100 филиалов по всей стране - такой компании категорически необходима видеокоммуникация. Существует 2 соизмеримых по издержкам решения: использовать существующий продукт или реализовать свой.
В этой статье я, разработчик отдела вебинаров, расскажу, каким образом наша компания, выбрав когда-то второй путь, пришла к собственному сервису вебинаров. Пройдя несколько итераций развития, на сегодняшний день мы научились проводить видеоконференции буквально на всех наших сотрудников.
Привет, Хабр!
Поговорим о проблеме выбора DAST, который бы смог удовлетворить потребности регулярного поиска уязвимостей в web-инфраструктуре компании. Опытные пентестеры, специализирующиеся на web-приложениях, наверняка возразят: какой тут может быть выбор? Burp Suite PRO наше все! И будут правы, но на прошлом PHD мне в руки попала Позитивная карта импортозамещения (https://www.ptsecurity.com/upload/corporate/ru-ru/analytics/positive-research-2023-poster.pdf), где Positive Technologies предложили заместить иностранные DAST: Burp Suite Pro, Acunetix, Inviciti — своим решением PT BlackBox. Но чтобы коммерческим продуктам не быть едиными, заодно добавим в сравнение продукты open source.
Разберемся, импортозамещаться или приобретать через серые схемы иностранный Burp Suite Pro. Или вообще оставаться на бесплатном open source.
Недавно попался на глаза примерно такой кусок запроса, и тут прекрасно примерно все:
• множество чтений из CTE (хоть и единственной записи, но все же);
• извлечение по каждому ключу текста с раскастовкой в jsonb;
• извлечение каждого отдельного json-ключа в каждое отдельное одноименное поле;
• "ручное" преобразование текстового представления массива в json в текстовое представление PostgreSQL.
А как - правильно?
Все мы смотрим видеоролики в интернете, и каждому наверняка приходилось сталкиваться с проблемами во время просмотра. Как разработчик сервиса вебинаров, попробую разобрать эту проблематику и рассмотреть возможные решения.
Давайте представим себе ситуацию, в которой у нас есть человек, желающий посмотреть видео через интернет, и мы, как разработчики, стремимся предоставить ему эту возможность.
Большинство разработчиков рано или поздно сталкиваются с XML. Этот язык разметки настолько глубоко вошел в нашу жизнь, что сложно представить систему, в которой не используется он сам или его подмножества. Разбор XML - достаточно типовая задача, но даже в ней можно выделить несколько основных подходов. В этой статье мы хотим рассказать, зачем нам потребовалось парсить XML, какие подходы мы опробовали, а заодно продемонстрировать замеры производительности для самых популярных реализаций на C++.
В мире 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.