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

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

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

Многие люди, кто не работает в сфере разработки электроники, представляют себе процесс разработки достаточно просто: разрабатываем схему, трассируем плату, пишем прошивку. А что еще надо?

В статье я опишу, как устроен типовой процесс разработки электроники на самом деле – на примере и с картинками (это может быть маленькая или большая компания, процесс плюс-минус схож). За пример мы возьмем некую материнскую плату компьютера (процессор в данном случае не принципиален) и разберем типовой процесс разработки такой материнской платы.

2025 год приносит новый виток трансформации для HR в IT. Сегодня управление талантами – это не просто работа с кадрами, а стратегический инструмент для роста бизнеса. На российском рынке ситуация усложняется двойным давлением: с одной стороны — нехватка IT-специалистов, с другой — необходимость адаптации к локальным решениям после ухода глобальных игроков.

Согласно исследованию Gartner, 75% компаний внедряют ИИ для управления персоналом, а Deloitte утверждает, что 78% сотрудников ожидают индивидуализированного подхода. Но как российским IT-компаниям идти в ногу с мировыми трендами в условиях санкций и технологических ограничений? Как адаптировать передовые практики, учитывая специфику локального рынка?

Меня зовут Камиля — я руководитель отдела по персоналу, коуч ICF и HRBP с 15-летним опытом, и в этой статье поделюсь ключевыми трендами и практическими рекомендациями для HR-профессионалов, которые помогут преодолеть вызовы и ускорить рост вашего бизнеса в 2025 году.

В современном мире границы между работой и личной жизнью становятся все более размытыми. Особенно это заметно в ИТ: здесь гибкий график, удаленная работа и постоянная доступность через мессенджеры стали нормой. В таких условиях часто звучат два термина: work-life balance (баланс между работой и жизнью) и work-life blend (смешение работы и жизни). Но в чем их разница? И как понять, какой подход подходит именно вам? И что вы можете предложить членам своей команды, как руководитель?

Всем привет! Я Алеся, тренер-методист и руководитель отдела обучения ИТ-компании, преподаватель в ВышкаDigital и Innopolis. Уже более 10 лет я занимаюсь обучением и развитием сотрудников в ИТ-сфере, помогая специалистам находить баланс между профессиональными задачами и личной жизнью. Эта статья — результат моих наблюдений, опыта и практики.

История Эльбрус-3

В период с 1984 по 1985 год, когда завершалась разработка первых процессоров «Эльбрус-2», команда Эльбруса под руководством Бориса Арташесовича Бабаяна приступила к предварительным работам над машинами следующего поколения. В 1985 году ИТМиВТ получил государственный заказ на проектирование и создание машины с теоретической максимальной производительностью в 10 ГФлопс. Основные требования к «Эльбрусу-3» оставались такими же, как и к «Эльбрусу-1» и «Эльбрусу-2». Особое внимание уделялось высокой производительности как в научных, так и в универсальных вычислениях, надёжности и совместимости программного обеспечения с ранними моделями «Эльбруса».

В конструкции «Эльбруса-1» и «Эльбруса-2» присутствовал ряд недостатков, которые делали их неподходящими в качестве основной машины с требуемой производительностью, необходимой в государственном применении. Помимо архитектурных ограничений в производительности, требовалось получать больше информации о выполнении программного кода и зависимостях команд и данных в момент исполнения, которая не была доступна динамическому планировщику в момент исполнения.

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

Каждый день мы читаем success stories, слышим от коллег и знакомых об их феноменальных успехах, смотрим на их фантастические достижения по проектам. Да мы и сами в одно время вели своеобразный реестр побед команды и хвалились успехами на коммселлах (это одна из регулярных церемоний из Lean-технологий для формирования культуры непрерывного совершенствования команды).

И как-то так получилось, что в обществе сформировалось негласное табу на разговоры о неудачах. Безусловно, делиться успехами полезно, но жизнь многогранна и состоит не только из удачных моментов, но и из неудачных тоже. И вот однажды я узнал про мероприятие под названием Fuckup Nights: о нем в статье и пойдет речь.

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

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

Возможно, вы, как и я, уже сталкивались с ситуацией, когда Wi-Fi сеть на вашем предприятии оставляет желать лучшего: зоны с плохим покрытием, обрывы соединений в самых неподходящих моментах, задержки передачи данных и много больше.

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

Говорят, из кошки не сделать тигра, но сегодня мы попробуем добавить «корпоративности» очень простому и популярному ВПН-решению. OpenVPN Community Edition является решением с открытым кодом, очень популярным в мире и довольно безопасным. В корпоративной среде его использование часто бывает проблематично – отсутствуют важные функции, позволяющие разворачивать решение большому количеству пользователей с минимальными затратами.

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

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

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

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

Когда мы говорим про решения на базе ИИ, кто-то может представлять себе просто обученные модели машинного обучения или нейросети, кто-то магический черный ящик, который умеет «делать магию» и желательно с «точностью 100%», а кто-то просто кусок кода, который надо заставить работать. И с определенной точки зрения каждый будет прав. Кто и в какой части прав, как все происходит чаще всего и какие типовые ошибки ждут на пути внедрения решений на базе ИИ – об этом решил рассказать в статье ниже.

VPN обеспечивает доступ удаленных пользователей в корпоративную сеть. Решений много, но выбор оптимального не всегда очевиден. В данной статье хотел бы поделиться опытом внедрения и использования такого продуктового решении как Always On VPN от компании Microsoft. Подчеркну, что это не просто технология постоянно работающего соединения (многие вендоры используют похожие слова), а название продукта или даже целой экосистемы.

Статья будет полезна архитекторам решений и тем, кто планирует внедрять VPN на основе технологии Always On VPN (или еще сомневается). В документации вендора вопросы, затронутые в данной статье совсем не освещены и понять возможные трудности можно только на основе личного опыта.

Недавно был представлен 8-ядерный процессор следующего Loongson 3A6000 на базе ядра LA664, а знакомый энтузиаст смог приобрести плату на данном процессоре (модель процессора LS3A6000-HV и чипсет LS7A2000).

MQTT (Message Queue Telemetry Transport) — легковесный протокол обмена сообщениями для публикации/подписки сообщений, на настоящий момент этот протокол является основным стандартом в Интернете Вещей (IoT). Брокер MQTT — главный узел (серверное ПО) для подключения IoT устройств и обмену сообщений между ними. На текущий момент доступно более 20 брокеров MQTT с исходным кодом, что затрудняет выбор архитекторами и разработчиками программного обеспечения. В статье будут рассмотрены и сравнены некоторые из самых популярный MQTT-брокеров.

Привет, Хабр! С вами Дарина – инженер второй линии поддержки платформы или просто бывший участник второй линии UNIX team на международном ритейл-проекте.

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

Привет, Хабр.

В одном из проектов, связанных с мониторингом, мы используем Clickhouse, Prometheus, VictoriaMetrics, Grafana, Alertmanager и Vector.dev. Кстати, что общего у всех этих компонентов? Они написаны не на Java – это было одним из требований проекта, но речь ниже пойдет не об этом, а о Vector.dev.

Хорошая статья про Vector.dev есть на Хабре – но мы решили проверить свою карму, затащив Vector.dev в PoC. На текущий момент полет вполне нормальный: используем ограниченное количество source и sink’ов: File, Clickhouse, HTTP, JournalD и, конечно, сам Vector и его логи (немного погоняли kubernetes_logs, кстати, интересный доклад по теме логов Kubernetes был на недавней VK Kubernetes Conf’23).

В России все больше пользователей и организаций используют российские Linux системы. Но при подготовке пакетов для комплексных решений на этих системах могут возникнуть сложности, связанные с несовместимостью ПО, необходимостью настройки пакетов и т.д. В этой статье рассмотрю основные проблемы, с которыми наша команда столкнулась при развертывании проектного решения на российских Linux системах: Astra Linux, Alt Linux, Red OS. Этот опыт будет полезен для команд разработки, которые переходят на Linux и ранее не работали с ними.

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

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

Тест разработан Гарольдом Керноу (CCTA) в 1972 году на языке Algol-60, в 1973 появляется реализация на языке Fortran, а в 1996 году появляется реализация Роя Лонгботтома на языке C. Тест очень прост и включает около 150 инструкций с восемью активными циклами, три из которых выполняются с помощью вызовов процедур.

Доминирующий цикл, на который обычно приходится 30-50% времени, выполняет вычисления с плавающей запятой посредством вызовов процедур. Оценка производительности выражена в миллионах операций Whetstone в секунду (MWIPS). Для лучшей оценки производительности процессор должен иметь блок FPU.