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

Для меня таким старым надёжным другом стала программа TreePad Lite. Она со мной уже без малого 30 лет. Мне очень близок минимализм TreePad: простота интерфейса, отсутствие необходимости установки, нетребовательность к ресурсам, открытый формат файлов, отсутствие каких-либо зависимостей от сторонних библиотек и интернета.

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

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

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

Привет! Я работаю в компании Bercut, которая более 20 лет занимается разработкой и поддержкой ПО для операторов сотовой и фиксированной связи. Сегодня я хочу рассказать о наших подходах к сокращению времени простоя продуктивного комплекса при установке обновлений схемы данных на СУБД Oracle. Целевая аудитория — начинающие и продолжающие разработчики, которым интересно узнать о различных вариантах распараллеливания и ускорения работы DDL, DML и прочих штуках, облегчающих процесс отладки и установки.

Привет! Я работаю в компании Bercut, мы более 20 лет занимается разработкой и поддержкой ПО для операторов сотовой и фиксированной связи. Прошел путь от инженера в отделе сопровождения до менеджера продукта. В последние годы работаю ведущим специалистом в отделе администрирования (Senior DBA) и решаю проблемы производительности высоконагруженных биллинговых базах данных, обслуживающих от сотен тысяч до десятков миллионов абонентов. Сегодня я хочу рассказать про проблему построения оптимального плана выполнения запроса при использовании коллекций в качестве входных переменных запроса и вариантах ее решения.

В технической документации часто встречаются фразы с использованием страдательного залога. Параметры там «задаются», файлы «сохраняются», а программа «запускается». Ох, опасная эта форма для строгих и однозначных описаний! Почему же страдательный залог заставляет читателей страдать? Будем разбираться...

Привет! Столкнулся с тем, что быстро не нашел простой инструкции, как с использованием 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). Если вы технический переводчик или вам просто интересна тема  локализации ПО —

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

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

А что же программисты?...

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

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

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

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

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

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

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

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

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

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

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

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

Привет! Меня зовут Женя Голева, я занимаюсь developer relations с 2016 года, и постоянно вижу профессиональных чатах холивары о нашей работе. Люди спорят, кто такие деврелы, кто занимается не деврелом, а какие виды деврелов наоборот имеют право на существование и очень нужны в команде. 

Ответы на многие похожие вопросы уже есть — в книге Мэри Тенгвал “The Business Value of Developer Relations”.  Я заручилась поддержкой автора и издательства-правообладателя и перевела главу “Building a Developer Relations Team / What’s in a name?” для русскоязычного сообщества. У вас впереди 10 коротких и ёмких разделов про цели и задачи всей команды Developer Relations на старте и в процессе развития, про то, какие роли и специализации могут быть востребованы на разных этапах, что кандидатам необходимо знать и уметь на входе, а что — вовсе не обязательно и можно добрать в процессе работы.

Эта статья будет полезна в первую очередь тем, кто хочет разобраться в специфике направления developer relations: если вы СТО или СЕО, то вам скорее будут полезны первые несколько разделов и последний, если вы уже занимаетесь деврелом или очень хотите начать, здесь будут ответы на вопросы, как войти в профессию или куда в ней развиваться дальше.

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

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

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

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

Сегодня расскажу, что нужно делать и чего избегать, чтобы построить максимально производительную систему на примере СУБД Оракл.