Kurgan-Telecom Ru | Информационные технологии

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

Мне давно хотелось услышать мнение DevOps про практики FinOps, и вот в подкасте FinOpsWeekly вышло интервью с участием Виктора Фарчича, в котором он в присущей ему провокационной манере говорит о том, как одно дополняет другое и как девопсы видят оптимизацию со своей стороны. Предлагаемые решения в основном рассчитаны на Kubernetes, но основной посыл и обсуждаемые тренды так или иначе актуальны для многих компаний: эфемерные среды разработки, right-sizing и масштабирование.

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

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

В данной статье я хочу поделиться опытом и рассказать о том, как системным аналитикам улучшить Sequence-диаграммы (диаграммы последовательностей) с помощью лучших практик.

Я покажу, как некоторые подходы из мира программирования (те самые best practices и идеи из Clean Code) помогают рисовать sequence-диаграммы чище и понятнее. 

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

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

Прохладное утро... Щелчок... Зажигалка подносится ко рту, где своей очереди ждет сигарета.

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

У каждого из нас есть события, которые становятся триггерами нашего взросления

Привет, Хабр! Некоторые функции DAX из Power BI могут выглядеть интуитивно понятными, но при детальном рассмотрении ведут себя не совсем ожидаемо. Например, SUMMARIZE не агрегирует «сразу», в месте использования, но SUMMARIZE реализуется через «виртуальную», «отложенную» агрегацию за счет сохранения состояния. Для суммы, т.е. SUM, промежуточное состояние и есть сумма и особенности SUMMARIZE не проявляются, но для любой другой агрегации (например, среднего AVERAGE) становится понятно, что в Power BI уже учитывается так называемое состояние для корректного расчета SUMMARIZE, т.е. данные по всем записям сохраняются в состоянии. В других СУБД единственный аналог — только State и Merge комбинаторы из ClickHouse, поэтому для иллюстрации состояний будет рассмотрен пример из ClickHouse, соответствующий DAX с SUMMARIZE и AVERAGE. Интересующимся особенностями SUMMARIZE в Power BI — добро пожаловать под кат :)

Работая над сайтом завода «ЭЛЕКТРОконнект», мы столкнулись с задачей, знакомой всем, кто делает проекты для технического B2B. На первый взгляд, всё просто: обновить сайт, сделать понятнее, удобнее, современнее. Но под этой простотой задачей скрывается целый пласт системных особенностей от отраслевых стандартов до внутренней логики работы с заявками, где каждая форма и таблица это часть производственного процесса.

Я не буду учить вас вести переговоры. Если вы читаете эту статью, то, возможно, разбираетесь в теме даже лучше меня. Теории полно — книги, курсы, гениальные методики. Обращайтесь к ним.

Лично мне всегда не хватало практики.

Представляем наш синтез для языков России и СНГ. В этот раз получилось покрыть 20 языков, всего 95 голосов. От старой демки этот релиз отличается следующим:

Модель поддерживает SSML;

Модель стала быстрее ещё на 20-25% (она и так была супер быстрой);

С живыми дикторами были подписаны договоры на запись их голоса;

Запись велась в максимально высоком из практически доступного качестве;

Для ряда языков опубликованы модели простановки ударений и / или словари с ударениями в рамках silero-stress;

К модели синтеза применены все оптимизации, как к нашей прошлой публичной модели;

Для демки мы брали шумные публичные данные низкого качества. В этот раз всё хорошо - как следствие существенно выросло качество синтеза.

Какие главные проблемы технической документации? Во-первых, ее нет, во-вторых, если она есть, то не актуальна.

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

Существует три класса задач, которые решает техническая документация:

1. Описать наши требования к системе и принятые решения

2. Описать текущее состояние системы

3. Объяснить пользователю, как работать (\разворачивать\эксплуатировать) с системой.

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

Второй тип документации — описание текущего состояния системы. Так как мы не хотим разрыва между описанием системы и самой системой, мы будем пытаться генерировать человеко-читаемое описание из кода и конфигурации. Назовем этот подход Code as Docs.

Третий тип — различные виды пользовательской документации. Эту форму документации мы постараемся минимизировать, сделав понятным наши интерфейсы и встроив подсказки прямо в процесс работы пользователя с системой. Назовем это подходом No Docs.

На этом можно было бы и закончить, но пройдемся подробнее по каждому пункту.

Самые интересные новости финансов и технологий в России и мире за неделю: в РФ маркетплейсы воюют с банками, иноагентам поднимают НДФЛ до 30%, мем Страдающего Средневековья с Сашей признали экстремистским, Безос выпустил на улицы свое робо-такси, Гугл дропнул разрывную Gemini 3, а Grok немного перехвалил Илона Маска.

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

В этой части цикла, посвященного разработке электропривода, мы сосредоточимся на его электронной составляющей. Рассмотрим топологии силовых узлов AC/DC, DC/DC и DC/AC электропривода, подбор электронных компонентов, а также ключевые нормативные стандарты, которых необходимо придерживаться при проектировании. Отдельный раздел будет посвящен выбору вычислительной платформы для управляющей платы — FPGA, DSP, SoC и другие варианты. Кроме того, затронем вопросы функциональной безопасности (safety) в электронике и требования к безопасной работе электропривода.

Авито — это не просто доска объявлений. Это настоящий музей народного творчества, странных ракурсов и загадочных предметов. Мы все видели эти фото: размытый диван в темноте, «селфи» чайника в зеркале или ковер, который видел еще Брежнева.

Но что, если бы эти продавцы имели доступ к технологиям будущего?

Ранее я уже писал здесь о языковой модели Déiwos-Lókwos GPT, способной общаться на праиндоевропейском языке, подсказывать слова из праиндоевропейского лексикона и переводить тексты (особенно стихи) на праиндоевропейский. В прошлой заметке я делал реконструктивный эксперимент с переводом своего стихотворения на праиндоевропейский, «обкатывая модель».

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

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

Три урока тайм-менеджмента от компьютеров

Что общего у вашего распорядка дня и работы процессора? Оба сталкиваются с проблемой планирования задач. В этой статье вы узнаете, как принципы из информатики — от алгоритмов планирования в Linux до техники «coalescing interrupts» — могут революционно изменить ваш подход к тайм-менеджменту. Автор предлагает три конкретных урока: отказ от поиска идеального порядка, группировка однотипных задач и принятие стратегии «достаточно хорошо». Эти методы помогут вам меньше планировать и больше успевать, вернув себе состояние спокойной концентрации.

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

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

В этой статье автор делится ошибками и «особенностями» Xcode, которые больше всего его раздражают. Главный совет: держитесь подальше от этой IDE и всегда ищите альтернативы.