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

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

В результате этого оценивания уже можно “поиграть” показателями: время, ресурсы, качество (содержание) и приступить к подбору наиболее подходящего их сочетания. Так же, выявленные объемы и зависимости функциональности позволят делить будущий продукт на модули, подсистемы, контуры и прочие части, обеспечивая поэтапное воплощение, распределение ресурсов и ответственности, снижая риски провала благодаря дроблению. Для решения подобных задач нам очень пригодится умение эффективно определять Границы проекта и управлять ими.

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

Этот текст для начинающих любителей электроники. Поделюсь опытом использования трех ключевых приборов в моей мастерской — лабораторного блока питания (ЛБП) DS310S, мультиметра Mestek DM100C и USB-осциллографа Hantek 6022BE. Подробно расскажу, как использую каждый прибор, с реальными примерами из практики. Надеюсь, будет полезно!

Изучение способов выявления и формализации функций системы, особенно актуальны для современных тенденции ИТ-рынка, связанных с развитием Сервисных моделей и архитектуры микросервисов. Затронем тезисно эти подходы.

Diplodoc — опенсорс‑платформа для работы с документацией в парадигме Docs as Code, которая создаётся в Яндексе силами команд Yandex Infrastructure и Yandex Cloud и является частью наших опенсорс‑инструментов. С её помощью мы собираем всю документацию компании. Это суммарно более 300 тысяч статей в более чем 2500 документационных проектов и порядка 6000 запусков Diplodoc CLI каждый день.

На таких объёмах нам важно быть эффективными — умеренно расходовать ресурсы сборочных ферм и при этом собирать проекты как можно быстрее, чтобы документаторы могли увидеть финальный результат без смены контекста на чай.

Со временем, скорость CLI заметно деградировала. С одной стороны, платформа прирастала полезными функциями, это увеличивало время обработки контента, с другой — размер документации вырос и для некоторых продуктов перевалил за тысячу файлов.

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

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

Привет, Хабр! Сегодня расскажу о таком девайсе, как лазерный гравер. Честно говоря, всегда казалось, что это «круто, но не для меня», пока я не купил Atomstack A5 Pro. Немного о нем я рассказывал тут. Сейчас хочу рассказать о нем подробнее, поскольку до сих пор продолжаю с ним регулярно работать.

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

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

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

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

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

Сегодня я расскажу о проблеме, которая уже к 30 годам касается каждого десятого, а по достижению пенсионного возраста встречается у 80% людей. И это больные суставы.

Что это и зачем?

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

Я также прекрасно понимаю, что некоторые люди читают мои статьи только ради шуток и картинок. Что ж, весёлые шутки и смешные картинки вы получите.

В MWS мы используем платформы для совместной работы и автоматизации, которые легко подключить, настроить и использовать без нагрузки на ИТ-отдел (например, MWS Tables). Но если вам привычнее работать не покидая пределы консоли, собрали терминальные инструменты, которые помогут вывести продуктивность на новый уровень: планировщики задач, органайзеры и вот это всё.

Поток — это последовательность элементов данных, предоставляемых за некоторое время. Концепция потока (stream) позволяет обрабатывать или передавать данные поэлементно, а не как одно целое. Потоки особенно полезны в сценариях, когда приходится работать с большими множествами данных, непрерывными данными или данными реального времени.

Я довольно давно искал менеджер заметок после того, как ушел Notion и заблокировал мой аккаунт. Я перепробовал довольно много всякого. Где-то меня не устраивал интерфейс, где-то глючная P2P-синхронизация, где-то отсутствие нативных приложений.

Сегодня расскажу про то что нашел для и себя и как это похостить.

Среди ИТ специалистов ходит анекдот, что системные администраторы делятся на 10 категории, на тех кто пока не делает бэкап, и на тех, кто уже делает резервное копирование данных. А так как самой частой причиной отказов в ЦОДах является – сбой электропитания, то обеспечение надежного электрического питания для компьютера (да и для любой другой цифровой техники) является наиглавнейшей задачей.

К сожалению, большинство простых (офисных) источников бесперебойного питания выпускаются либо вообще без возможности дистанционного/автоматизированного контроля его состояния (только звуковое оповещение), либо имеют подключение по USB с собственным протоколом связи и проприетарным приложением, которое обладает самым минимумом функций (наверное маркетологи таким образом ненавязчиво подталкивают потребителей к покупке более дорогих моделей своего оборудования).

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

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

Некоторое время настрадавшись с подключением UPS по USB с помощью проприетарных программ, я решил разобраться с данной проблемой кардинально - сделать простенький контроллер состояния батареи источника бесперебойного питания со стандартным протоколом связи ИБП, который бы подошел для любого типа и модели источника бесперебойного питания при использования дома или в небольшом офисе.

Всем привет!

В этой статье, я вам расскажу про свой личный опыт работы с виртуальными сетевыми лабораториями. Хочу начать своё повествование с небольшой предыстории — как я пришёл к теме.