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

Меня зовут Маша. Да, как‑то даже во взрослом возрасте все меня так называют. Работаю в IT или около IT сфере еще со студенческих времен. Чего только не насмотрелась… но сегодня не об этом. Сейчас занимаю должность системного аналитика в Ростелеком Информационные Технологии.

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

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

Всем привет! Меня зовут Татьяна, я работаю пресс-секретарем в региональном филиале «Ростелекома». В сфере пиара тружусь более 15 лет и все эти годы уделяю особое внимание мониторингу инфополя. Отслеживание упоминаний бренда в СМИ – важная часть работы компании с репутацией. Умение оперативно анализировать публикации позволяет не только поддерживать имидж компании, но и своевременно реагировать на любые изменения в восприятии бренда.

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

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

Побежали!

Меня зовут Алешин Алексей и я бегаю. В целом, я всегда увлекался спортом. Звезд с неба не хватал, но и последним не был. Я занимался футболом, единоборствами, большим теннисом, мог погонять в баскет и волейбол благодаря высокому росту. Поэтому, когда я стал немного «побегивать», это не казалось чем‑то странным. Бег позволял мне оставаться в нормальной физической форме, разгружать голову без посторонней помощи. 

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

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

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

В этой статье мы разберем практический подход к решению этих проблем с помощью pg_anon – инструмента для автоматической анонимизации данных в PostgreSQL. Я постараюсь рассказать вам основной сюжет работы с производственными данными, не замедляя при этом разработку.

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

В моей первой статье на сайте об автоматизации оборудования Juniper в качестве подопытного выступал коммутатор, который стоит под столом, и до которого имеется полный прямой доступ по сети. Однако, такая ситуация скорее исключение. Практически всегда сейчас используют для доступа на сетевые устройства Jump Host. В этой статье я хотел бы рассмотреть, какие решения мы можем использовать при автоматизации работы с сетевым оборудованием на Python, чтобы учесть наличие промежуточного устройства.

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

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

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

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

В статье рассматриваются основные принципы и особенности использования Redis в режиме Pub/Sub для масштабируемых и высоконагруженных приложений. Описаны два подхода к обеспечению высокой доступности — Redis Sentinel и Redis Cluster, их преимущества, ограничения и примеры настройки. Приведены примеры использования Pub/Sub в реальных системах, а также практические конфигурации и код для настройки отказоустойчивого кластера Redis. Статья предназначена для разработчиков, которые ищут решения для создания надежных систем обмена сообщениями с высокой производительностью и отказоустойчивостью.

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

Для начала определим цель текущей работы. Это МВП для проверки бизнес-гипотезы - мы можем забыть о “техдолге” и бежать вперед для получения нужных метрик. Надо сделать пару задач, где сроки “вчера” - вставляем подходящие решения с мыслью о будущем рефакторинге. Тут главное правильно понять дальнейшее развитие проекта, чтобы после наших технических решений были понятны масштабы работ по накопившимся обязательствам. Это как с кредитом, который мы берем в банке и будем возвращать в будущем, да еще и с процентами. Проведите верхнеуровневый анализ проекта и поймите на каком вы этапе и куда хотите прийти.  Картинка в помощь.

Рассмотрим, как использовать Elasticsearch в качестве поискового движка в приложениях на Spring Boot. Поговорим о стратегии реализации полнотекстового поиска, эффективной индексации сущностей JPA и их связей. Уделим внимание использованию аннотаций полей, настройке релевантности с помощью весовых коэффициентов и реализации нечёткого поиска для обработки вариаций запросов. Также обсудим методы настройки синонимических связей, многоуровневых фильтров и ранжирования результатов по релевантности для повышения качества поиска.

Приветствую вас, дорогие читатели. Тружусь в IT сфере с 2016 года. Так вышло, что свое ремесло я нашел не сразу и пробовал себя в программировании, аналитике и теперь занимаю должность руководителя проекта. Простыми словами управляю командой в Ростелеком Информационные технологии. Меня зовут Радик. Приятно познакомиться

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

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

Один раз мне задали вопрос: чем бизнес‑аналитик отличается от секретаря? Казалось бы, разработке ПО в России уже больше 2х десятков лет, но роль бизнес‑аналитика до сих пор вызывает вопросы.

В принципе, вместо секретаря можно добавить любую другую профессию и спросить: а чем БА отличается от бухгалтера, от юриста или технического писателя?

Всем привет. Меня зовут Ирек, и я в профессиональном IT с 2012 года. Прошел путь от специалиста службы поддержки до разработчика. На данный момент занимаюсь автоматизацией тестирования в компании РТК ИТ.

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

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

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

Мы — два сотрудника Ростелеком ИТ Алешин Алексей и Сердюк Нэлля. Наши проекты — большие порталы по видеонаблюдению на государственных мероприятиях (Единый день голосования, Единый государственный экзамен).

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

В 2024 году на рынке существует довольно большое количество экосистем цифровых продуктов: как для B2C-сегмента, так и для B2B. И если просто в поисковике вбить «как создать экосистему», вы получите кучу статей от аналитиков, продактов, бизнеса. Однако, если попробовать сформулировать запрос с конкретикой по дизайну (например, «как создать дизайн для экосистемы продуктов»), мы получаем классную выдачу, в которой экосистемой называют дизайн-систему. И это ужасная подмена понятий, так как дизайн-система является всего лишь одним (хоть и очень значимым) из ингредиентов вкуснейшего экосистемного дизайн-борща.

Что же входит в этот борщ?

Добрый день, Habr! Меня зовут Сергей, я старший эксперт в компании Ростелеком. В зоне моей ответственности эксплуатация сетевого оборудования компании (в основном маршрутизаторы и коммутаторы). Когда счет устройств, с которыми необходимо работать, идет на тысячи, обойтись без автоматизации решительно невозможно.

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

Идея этой статьи родилась из обсуждения в чате канала «UI фэйл» (https://t.me/uifail), который ведёт мой коллега и друг Денис Пушкарь. В процессе сборки материала я обращался к коллегам из других команд и направлений (в том числе разработки, тестирования и аналитики), чтобы подтвердить или опровергнуть свои умозаключения, так как тема весьма обширная, а пишет статью по ней человек из сферы дизайна.

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

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

Ниже по тексту я распишу трудности, с которыми сталкивается специалист в IT на всём протяжении своего роста, и о которых очень мало говорят.