Все потоки

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

Имеется фрезерный станок ЧПУ. Было принято решение, переделать его систему управления, используя ядро Cortex M3. В общем и целом, существуют программные пакеты, позволяющие сделать это. Например GRBL. Однако, у меня своя специфика. Для реализации ПО, потребовались математические операции sin(x), cos(x), sqrt(x). И я задумался над их реализацией в формате фиксированной точки.

Рассмотрим техники построения и улучшения RAG систем: от нарезания текстов на куски, до продвинутых способов улучшения качества ответа.

Этим блогом можно пользоваться как шпаргалкой для проектирования своего RAG-а и/или для подготовки к собеседованиям.

Все полезные ссылки и материалы, на которые я опирался будут в конце.

Что такое Passkeys?

Вот уже пару лет чат-боты, основанные на больших языковых моделях, «гремят» на весь интернет. Поражают своими возможностями и делают то, о чем около 15 лет назад можно было услышать только в фантастических сюжетах. При этом важно что, сейчас Large Language Model (LLM) дошли до широкого круга потребителей и все могут их увидеть и протестировать. В связи с этим возникают дискуссии, размышления, статьи-прогнозы на тему того, как искусственный интеллект (ИИ) изменит рынок труда, кого заменят, сократят, а кто останется и т.д. Профессия QA и процессы тестирования тоже не остались без подобных рассуждений. 

Привет, Хабр! Меня зовут Андрей, я QA-специалист в компании SimbirSoft. В этой статье хочу поделиться опытом и впечатлениями моих коллег в использовании ИИ для рабочих задач.

Утверждается (хотя, источник этого утверждения остается неизвестным), что туманность NGC 1499 получила своё название за сходство с формой береговой линии штата Калифорния. Но кто именно дал туманности это название — вопрос открытый. Тут есть пара интересных совпадений. Во-первых, если наблюдать эту туманность из центральной части штата Калифорния, то она будет проходить ровно через зенит — географическая широта центра штата и склонение туманности совпадают. Во-вторых, открыл туманность Эдвард Эмерсон Барнард в 1884 году, будучи в то время еще любителем астрономии (он стал сотрудником Ликской обсерватории три года спустя — в 1987 года, а эта обсерватория находится как раз в штате Калифорния).

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

С 18 по 20 апреля 2025 г. на площадке НИУ МИЭТ в Зеленограде прошёл четвертый инженерный хакатон SoC Design Challenge, организованный компанией YADRO совместно с Передовой инженерной школой «Средства проектирования и производства электронной компонентной базы» МИЭТ. Более 250 студентов очной формы обучения со всей России собрались, чтобы на практике решить задачи по проектированию и верификации систем на кристалле (SoC) на базе RISC‑V.

В рамках треков «RTL проектирование», «UVM верификация», «Системная верификация СнК» и «Топологическое проектирование» участникам предстояло не только продемонстрировать знания цифровой и аналоговой схемотехники, но также и получить призы — FPGA платы и другие инженерные гаджеты. Все задачи формировались действующими специалистами отрасли и преподавателями МИЭТ, что делало соревнование максимально приближённым к реальным производственным кейсам.

Команда студентов-сотрудников компании Аквариус, трое студентов 4‑го курса НИЯУ МИФИ (каф. 27) команда «Свидетели ошибок»:

1. Силкин Никита Романович

2. Скворцов Ярослав Максимович

3. Никонов Александр Андреевич

За три дня напряжённой работы «Свидетели ошибок» набрали 76 баллов из максимальных 100 и уверенно опередили ближайших соперников на 28 баллов, заняв 1 место среди остальных команд в треке UVM верификации.

Как команда готовилась и добилась победы

Скворцов Я. М.

Хакатон длился три дня с 9:00 до 20:00. Сначала мы подробно разработали верификационный план по спецификации устройства, определили ключевые функции и ошибки для проверки. После этого разделили обязанности: каждый взял часть тестового окружения и приступил к реализации. Регулярные обсуждения архитектурных решений позволили быстро интегрировать результаты и довести тестбенч до рабочего состояния. Локализация багов оказалась самой трудоёмкой частью: требовалось крайне внимательно и с пониманием просматривать результаты тестов. Благодаря эффективной коммуникации и сплочённой атмосфере команда справилась с этой задачей, и мы одержали победу.

С 1995 года аналитики Gartner выпускают ежегодный доклад «Цикл Хайпа», который показывает состояние разных многообещающих технологий вроде больших языковых моделей, беспилотных автомобилей, солнечных панелей и так далее.
 
Каждый отчет строится вокруг S-образной кривой, где показано, в какой точке находится та или иная технология: пребывает на пике ажиотажа, разочаровывает или внедряется. Ожидается, что разработки, попавшие в «Цикл Хайпа», сильно повлияют на бизнес и общество. Составители кривой Gartner не сами оценивают технологии, а опираются на ожидания инвесторов, бизнеса и общества, ну, и шумиху вокруг разработок. В общем, чтобы понять, насколько хорошо люди прогнозируют будущее, можно покопаться в старых графиках Gartner.

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

Я часто пользуюсь в работе BI системами и всегда было интересно, что же там под капотом, насколько это сложная система. Спойлер - очень сложная! И я решил разобраться в вопросе и чуть более подробно. После подготовки этой статьи стало реальнее понятнее, откуда же все таки готовилось нападение, как работает тот же Power BI. Но вероятно, нужно будет перечитать некоторые моменты дважды. В тех местах, и понятиях, которые я сам не с первого раза понял, я добавлял дополнительное описание.

На связи @Menzorg Горишь идеей, но быстро выгораешь? Или, наоборот, погружаешься в код с головой, забывая о дедлайнах? Используя диалектику Гегеля, исследуем, как сосуществуют и борются две противоположности разработчика: жгучая мотивация и всепоглощающее состояние потока.

24 апреля ITU (Международное сообщество телекоммуникации) совместно с UN Women присоединились в девушкам по всему миру, чтобы праздновать «Международный день девушек в информационных и коммуникационных технологиях». Цель мероприятия – воодушевлять, поощрять и поддерживать женщин за выбор технических (математика, физика, информатика, науки) профессий, а также привлекать коммьюнити для продвижения сотрудничества с ними. 

Мы решили поговорить с нашими коллегами женского пола и спросить про их путь в ИТ: как они оказались в сфере, сталкивались ли с гендерным неравенством. Цель материала — рассказать про историю успеха коллег, высококвалифицированных и востребованных специалистов в ИТ. 

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

Му будем рады увидеть ваше мнение или историю в комментариях.  

Как ты решила перейти в ИТ? 

Анна Оборина, ведущий продуктовый дизайнер: По сути, ИТ-сфера сама нашла меня. Я рисовала всю свою жизнь, а после университета сразу попала на должность дизайнера. Пришлось прямо в бою осваивать графические редакторы. Знакомые предложили поработать на поддержке интернет-сайтов и оказалось, что они на чистом HTML —  срочно освоила. Затем предложили самой рисовать и собирать сайты. А спустя несколько лет развилось направление продуктового дизайна — вот тут я и осталась. Любовь с первого взгляда.

Анна Жаркова, лид мобильной разработки: Я шла в ИТ целенаправленно. Училась я хорошо, многое получалось, но хотелось нормальную насущную специальность, а к медицине душа не лежала. Родители отвели меня на профтестирование. Результаты показали, что мне самая дорога в ИТ. По совпадению, когда мы вернулись домой, увидели воткнутую в дверь рекламу курсов по разработке для подростков (тогда этого было ну очень мало). Еще одним совпадением стал звонок моей бабушки, которая сообщила, что мой дядя (мамин брат) решил подарить мне первый компьютер. Против таких явных знаков свыше идти было бы странно.

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

Представьте, что вы — повар в ресторане. Вы приготовили новое блюдо, но не пробуете его перед подачей гостю. Результат? Клиент может отравиться или остаться недоволен вкусом. Точно так же в программировании: без проверки код может содержать ошибки, которые проявятся в самый неподходящий момент. Unit-тесты — это как дегустация блюда перед подачей. Они проверяют отдельные части кода (методы, классы) на корректность, чтобы вы были уверены: всё работает так, как задумано.

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

Прекрасная возможность:

Использовать Julia – один из лучших языков программирования, который почему-то считается нишевым. Область его применения гораздо шире HPC. Он идеально подходит для решения самых разных задач.

Научиться как правильно публиковаться на GitHub.

Научиться делать линуксовые пакеты.

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

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

На связи Анна Астахова, директор по развитию ИТ-интегратора «Белый код». Сегодня бизнесу также, как и студентам, нужны знания. На примере одного из проектов рассказываю, как работает бизнес-аналитика в образовании. 

Привет, Хабр! Это Иван Чаплыгин, руководитель отдела переводов компании КРОК. Сегодня речь пойдет про Agile. Вы, конечно, все на нем собаку съели, а может, и не одну.  И сколько agile-коучей обитает на Хабре, одному богу известно. Но в области ИТ-переводов, вечно находящейся на стыке технических и гуманитарных знаний, гибкость оказалась тоже очень кстати. К Agile мы пришли не в результате цифровой трансформации, коучинговых сессий или серии онлайн-тренингов. Все гораздо банальнее. Методом проб и ошибок мы изобрели свой переводческий «agile-велосипед», чтобы ехать с ветерком. Подробности о том, как мы дошли до жизни такой - под катом. 

Всем привет! Продолжаю свой цикл материалов про создание успешного продукта. В прошлых статьях (часть 1; часть 2; часть 3) я рассказал более чем о 12 рабочих моделях построения продуктовых команд. Сегодня разберем ошибки, которые мешают компаниям развиваться.