Привет! Я – Ольга Красильникова. У меня за плечами 18 лет работы в сфере управления и развития персонала в компаниях Евросеть, М.Видео, Yota, МТС, Coca-Cola, Heineken. Сейчас работаю менеджером по обучению в Bercut. А еще я карьерный психолог, коуч (более 800 часов коучинговой практики). Верю, что любая работа может стать ресурсом для человека.

За последний год я провела больше 400 карьерных консультаций и коуч-сессий (как внутри компании, так и в частной практике), и вот фразы, которые я слышала почти в каждой сессии:

• «ненавижу свою работу»;
• «как же меня бесят мои коллеги»;
• «мой руководитель – идиот»;
• «мне все это надоело, это никому не нужно»;
• «сил нет больше терпеть».

Как сделать так, чтобы энергии, спокойствия и счастья в работе было больше, даже если сейчас много усталости и хочется бросить все? И что может помочь бизнесу удерживать, развивать и вовлекать ИТ-специалистов?

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

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

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

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

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

Для диагностики модулей есть хорошая программа memtest86+, но если памяти у нас 1ТБ, то полное тестирование растягивается на несколько дней, а бизнес не может так долго ждать.

Как же быть? В этой публикации я поделюсь опытом тестирования памяти сервера Gigabyte R292-4S0 с СУБД на Enteprice Linux 8 (EL8) и 1 ТБ памяти двумя методами:

С EFI загрузкой memtest86+ v7;

С автоматизированным созданием сотни libvirt-KVM виртуальных машин с memtest86+ внутри.

Запуск memtest внутри виртуальной машины... "Фу...", - скажут некоторые. И будут неправы. Почему?

Привет! Меня зовут Дмитрий Миронюк, я старший технический писатель в компании Bercut. До этого работал системным администратором, специалистом внедрения и поддержки, программировал IP-телефонию, успел поработать тимлидом. Но как в итоге стал техническим писателем расскажу в другой раз. Сегодня поговорим о ревью и комментариях. Приведу реальные примеры из личного опыта, а также поделюсь наблюдениями, как процесс ревью повлиял на мое сознание.

Привет! Столкнулся с тем, что быстро не нашел простой инструкции, как с использованием SSL и SASL настроить безопасный кластер из нескольких Linux узлов Zookeeper, и решил это исправить.

В этой статье поговорим о том, как:

• Настроить Zookeeper в кластере из трех узлов без шифрования (Plain);

• Добавить шифрование во внутрикластерное взаимодействие (Quorum TLS);

• Создать сертификаты для подключения к узлам Zookeeper клиентов (Server TLS);

• Создать сертификаты для подключения клиентов к узлам (Client TLS);

• Добавить авторизацию в шифрованный кластер (SASL with MD5);

• Показать на примере, как работают ACL, посмотреть, чем отличается суперпользователь super от всех остальных (как работает ACL в действии).

Привет! Меня зовут Сергей, я технический эксперт в компании Bercut. Когда-то увлекался Delphi и J2ME, издал несколько книг на эти темы, а сейчас создаю высоконагруженные приложения для баз данных.

Первой СУБД, с которой я познакомился — случилось это в далеком 2002 году, — была PostgreSQL. Тогда я, студент 4-го курса ТИУ, должен был разработать систему электронного документооборота для университета. Система представляла собой WEB-приложение, написанное на языке C, работающее на сервере под ОС UNIX и хранящее информацию в PostgreSQL. С тех пор мое основное поле деятельности - базы данных. А PostgreSQL стала одной из самых популярных СУБД в мире.

В Bercut мы занимаемся разработкой и развитием IT-продуктов, решений для операторов цифровых услуг и мобильных сервисов. Наши системы работают на различном железе, разных СУБД и обслуживают 24x7x365 в режиме онлайн сотни миллионов абонентов по всему миру.

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

Чем же так занимательно число 6174? Казалось бы, это обычное натуральное чётное четырёхзначное число. Не лучше и не хуже, чем, скажем, соседние 6173 и 6175. Оно даже не является простым. Тем не менее, это число имеет своё собственное название — постоянная Капрекара. А ещё оно относится к так называемым «числам великой радости».

Давайте разбираться, что же в этом числе такого особенного. Займёмся несложными вычислениями...

Всем привет! Меня зовут Владислав Москалёнок, и я работаю техническим переводчиком и редактором в сфере телекома и IT уже более 20 лет. Сегодня хочу поделиться опытом команды Bercut в цифровизации переводческих процессов. Из статьи вы узнаете, как мы реализовали комплексное решение, где сочетается технология накапливаемой памяти (TM) и нейронного машинного перевода (NMT). Если вы технический переводчик или вам просто интересна тема  локализации ПО —

Как техлид я занимаюсь обучением всех новых сотрудников нашего отдела. У меня подготовлена обширная программа, по которой я рассказываю новичкам обо всех внутренних процессах, инструментах и методиках. Многие сотрудники, только пришедшие в нашу компанию, бывают приятно удивлены продуманной программе адаптации. У нас новеньким уделяют много времени и внимания, обучают, всё демонстрируют и объясняют.

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

Привет! Меня зовут Владислав Кучинский. Я начинал свой карьерный путь в IT с разработки на С++ и Java, а сейчас являюсь руководителем группы Platform Event Management в компании Bercut.

Сегодня я расскажу историю создания платформы Business Rules Engine (BRE) Bercut – системы обработки событий в реальном времени. Поделюсь опытом удачных и не очень решений, которые в итоге все же стали удачными. К моменту начала разработки BRE я был руководителем отдела и осуществлял различные роли: был аналитиком, архитектором, сам что-то кодировал, внедрял, тестировал.

Итак, под катом – история преодоления сложностей, с которыми мы столкнулись во время проекта, и выводы, к которым пришли.

Привет, меня зовут Денис Агапитов, я руководитель группы Platform Core компании Bercut. Работаю в компании без малого 20 лет, из них 18 пишу на Java.

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

Эта статья основана на реальной практике борьбы с "OutOfMemory: direct memory".

Было у отца два сына. И оставил он им наследство — камень драгоценный. А чтобы никого не обидеть, поставил он перед сыновьями условие: нельзя тот камень ни пилить, ни продавать. Можно только по очереди владеть им. И повелось так — каждый год камень переходил от одного брата к другому. Потом камнем по очереди владели их потомки, потом потомки их потомков… И длилось так вечно.

Этой притчей итальянский математик, монах и философ Гвидо Гранди пытался объяснить решение задачи, которую сам же и сформулировал. В 18 веке её считали парадоксом и предлагали разные варианты решения. Долгое время она не давала покоя математикам.

Задача Гранди формулируется очень просто: какой результат мы получим, если будем до бесконечности складывать 1 и -1?

Привет! Меня зовут Александр Голиков, я работаю в компании Bercut. Наша компания разрабатывает и развивает IT-решения для операторов цифровых услуг и мобильных сервисов. Коротко говоря, мы помогаем цифровизации бизнеса. В компании я занимаюсь виртуализацией, СХД, мониторингом, разработкой и интеграцией продуктов Bercut c операционными системами. Для агрегации данных и анализа мы используем Prometheus.

В этой статье рассмотрю одну из конфигураций Prometheus в отказоустойчивом режиме, познакомлю вас с Karma alert dashboard и продемонстрирую написание алертов. Напишу несколько простых включений Go Template и рассмотрю ситуацию, где такие включения противопоказаны. Продемонстрирую, как на основе меток можно сделать исключения из общих правил и обучу Prometheus самостоятельно чинить поломки.

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

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

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

Задачи окружают нас повсюду — и дома, и на работе, и во всяческих аспектах нашей повседневной жизни. У каждого со временем появляются собственные приёмы и методики работы со списками задач. Кто-то предпочитает модные приложения и продвинутые программы, кто-то по старинке всё записывает в бумажный ежедневник. А некоторые вообще не занимаются специальным планированием, но при этом чудесным образом всё успевают.

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