Мир находится в постоянном движении, вид за окном неуловимо меняется каждую секунду и никогда не повторяется дважды. Однако мы привыкли к относительной стабильности окружающей реальности. Будущее пугает нас своей неизвестностью и непредсказуемостью. Мы пытаемся его прогнозировать, строить какие-то долгосрочные планы. Но в любой момент может произойти «маловероятный» катаклизм и мы поймём, что все прогнозы погоды оказались пустышкой. Совсем другое дело — прошлое. Оно кажется нам надёжным и неизменным...

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

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

Как же лучше писать и оформлять примечания в технических текстах?

«Ваша документация — отстой!», «Я её никогда не читаю, всё равно там ерунда написана!», «Эти документаторы опять всё напутали», «Да любая нейросеть быстро напишет это в сто раз лучше», «Там никогда не найти ничего нужного», «А разве у нас есть документация?»

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

Какую программу вы обычно запускаете сразу после загрузки операционной системы? Кто-то сразу стартует браузер — поглядеть, кто там сегодня в Интернете (на Хабре) неправ. У многих — это редактор кода: «Я, как утром встал, сразу за дрель!». Возможно, вы сначала привычно открываете мессенджеры и почту — проверить, что там нового и важного.

Я обычно сразу после запуска операционки открываю свой Любимый Файловый Менеджер. Это «переходящее звание» — в разные периоды моего компьютерного прошлого этой чести «удостаивались» разные приложения с классическим двухпанельным интерфейсом. Сначала это был простой, но универсальный Norton Commander. Потом появился DOS Navigator со всяческими классными фичами: CD-плеер, телефонная книга с дозвоном по модему, встроенный табличный редактор и прочие прекрасные и поразительные для тех лет вещи.

Когда Windows прочно вытеснил DOS и все понемногу забыли про файл autoexec.bat, звание моего любимого файлового менеджера плавно перешло к Total Commander. Он продержался довольно долго, но в какой-то момент в мою жизнь буквально ворвался FAR...

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

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

Дисклеймер. Все совпадения фрагментов этого текста с реальными комментариями в вашей документации совершенно случайны. При написании этого текста не пострадал ни один проверяющий.

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

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

Давайте ненадолго перенесёмся в школьные годы и вспомним уроки математики и физики. Помните, чему равно число π? Естественно, помните, мы же на Хабре! А чему равно π в квадрате? Это тоже странный вопрос. Конечно, 9,87. А чему равно ускорение свободного падения g помните? Ещё бы, это число так тщательно вдолбили в нашу память, что захочешь — не забудешь: 9,81 м/c². Конечно, оно может варьироваться, но для решения базовых школьных задачек мы обычно использовали именно это значение.

А теперь, внимание, следующий вопрос: а с какого это перепугу π² примерно равно g?

В статье я хочу рассказать об одной очень интересной теории разработки документации на системы и программы. Её авторы утверждают, что создали ни много ни мало «Великую Единую Теорию Документации» (The Grand Unified Theory of Documentation). Мы привыкли с опаской относиться к заявлениям о том, что кто-то обнаружил сокровенную истину и раскрыл её профессиональному сообществу. В теории изложены идеи и правила, которые мы встречаем в разных методиках разработки документации и сами применяем на практике.

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

Эта статья о том, как правильно передавать секреты запускаемым программам.

Бывает встречаются Unix-системы, на которых некоторые администраторы передают процессам пароли в открытом виде, совершенно не заботясь о том, что их видят все пользователи данной системы.

Если вы смогли зайти на систему под непривилегированным пользователем, то вы можете набрать команду, отображающую список запущенных процессов

$ ps -ef

и возможно и увидеть некоторые секреты, которых видеть не должны, например, у одного из процессов ниже открыт пароль basicAuth.password (пароль в тексте изменен).

$ strings /proc/1101/cmdline
/usr/local/bin/vmagent
--remoteWrite.url=http://vm-cluster.local:1234/api/v1/write
--remoteWrite.basicAuth.username=user-rw
--remoteWrite.basicAuth.password=123456
--promscrape.config=/usr/local/etc/vmagent-config.yml

Как же быть? Есть несколько способов этого избежать.

Привет! Я – Ольга Красильникова. У меня за плечами 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 внутри виртуальной машины... "Фу...", - скажут некоторые. И будут неправы. Почему?

Всем привет!

Сегодня поговорим о немного нетипичной для меня теме, а именно — Apache Superset. Обычно я пишу длинные «философские» статьи «на свободную тему», но в этот раз — это будет туториал. Так что кому‑то может показаться банальностью, но, опять таки, вдруг кому поможет. Почему‑то именно по суперсету на Хабре оскорбительно мало материалов. Да, у него в целом неплохая документация, но она все же — документация, поэтому в меру сухая, в ней нет дополнительных объяснений, примеров. Попробуем хоть немного исправить эту ситуацию.

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

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

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

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

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

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

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

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