Вычисление обратной матрицы, а именно, вычисление алгебраических дополнений и определителя матрицы займёт большое количество машинных ресурсов при квадратной матрицы высокого порядка. В статье описывается решение и приводятся результаты обращения квадратной матрицы методом решения системы AX = E, где A, X, E - квадратные матрицы порядка n, X - обратная A матрица, E - единичная матрица, 
и методом LU декомпозиции.
В работе над React-проектами код почти всегда живёт дольше, чем кажется на старте: требования меняются, команда растёт, появляются новые сценарии и интеграции. В таких условиях выигрывает не тот, кто «быстрее собрал», а тот, кто оставил после себя понятную структуру — с предсказуемой логикой, прозрачными зависимостями и минимальным количеством скрытых допущений.
В данной статье мы расскажем о принципах «чистого кода» в React, которые используем в повседневной разработке, и покажем их на коротких примерах.
В 1936 году Алан Тьюринг, пытаясь формализовать пределы вычислений, сформулировал вопрос, навсегда изменивший не только компьютерную науку, но и наше понимание границ познания. Этот вопрос — известная как «Проблема остановки» — звучит обманчиво просто: можно ли создать алгоритм, который, анализируя код любой программы и её входные данные, заранее и безошибочно определит, завершится ли её работа или же она уйдёт в бесконечный цикл? Казалось бы, речь идёт о чисто технической задаче, мечте каждого программиста об идеальном отладчике. Однако ответ Тьюринга, уместившийся в элегантное и почти язвительное доказательство от противного, оказался оглушительным: нет, такой алгоритм принципиально невозможен. В этой статье мы не только разберём суть этого гениального доказательства, которое построено на самореференции и логическом парадоксе, подобном «лжецу», но и визуализируем его ход с помощью наглядного кода в MATLAB, превратив абстрактную логику в динамическую демонстрацию. Мы увидим, как гипотетическая «всезнающая» программа H неминуемо запутывается в сетях, расставленных специально сконструированной программой-провокатором 
, приводя к неразрешимому противоречию в любом исходе. Это открытие — не просто академическая курьёзность. Оно устанавливает фундаментальный, алгоритмический предел: существуют чётко поставленные вопросы, на которые мы никогда не получим однозначный «да» или «нет» от любой вычислительной машины. Мы проследим глубокую связь этого результата с теоремой Гёделя о неполноте, обсудим другие неразрешимые проблемы, такие как проблема соответствия Поста, и затронем трезвые последствия для современной разработки, верификации программ и даже для мечтаний о создании всесильного искусственного интеллекта. Эта история — о том, как осознание непреодолимой границы стало одним из самых мощных интеллектуальных достижений человечества, чётко очертив то, что мы можем знать, и указав на бескрайние области того, что мы знать не в силах.
Мы в OpenIDE хорошо понимаем, что среда разработки — это не просто набор инструментов и функций. Это пространство, в котором разработчик проводит значительную часть своего времени: думает, экспериментирует, ошибается и создаёт новое. Именно поэтому для нас особенно важны открытость, доступность и ощущение живого диалога внутри экосистемы.
IDE - это не только кодовый редактор, вспомогательные инструменты и графические интерфейсы. IDE - это комьюнити. Люди, которые расширяют возможности платформы, находят нестандартные решения, закрывают реальные боли и делятся своим опытом с другими. Именно они превращают среду разработки из продукта в экосистему — живую и дышащую.
И когда до Нового года остаётся совсем немного времени, а сил на сложные технические материалы почти не остаётся, мы решили немного сменить ритм. Вместо глубоких разборов — лёгкое, тёплое и предпраздничное чтение. Так появилась идея серии интервью с участниками нашего комьюнити — людьми, которые создают плагины для OpenIDE.
Привет, Хабр!
Cегодня разберём экспериментальную фичу Kotlin 2.2 — контекстные параметры. C помощью контекстных параметров функции и свойства могут объявлять зависимости, которые неявно передаются при вызове.
Допустим, есть сервис логирования UserService, который нужно часто передавать во многие функции. Без контекстных параметров пришлось бы всюду писать fun outputMessage(users: UserService, msg: String). С параметрами контекста достаточно объявить функцию так:
Микросервисный подход казался выбором по умолчанию в последнее десятилетие. «Делай микросервисы – и будет хорошо», – намекал опыт построения огромных программных систем. Вместе с тем в последнее время в сети всё чаще встречаются мнения, что «не нужны нам эти микросервисы», и тому есть причины.
Статья инспирирована переводом Распределенный монолит: тихий убийца мечты о микросервисах и некоторыми комментариями, отражающими, что тема описана не слишком подробно. Покажу видение данной темы немного с другой стороны.
Инерциальные модули (IMU, Inertial Measurement Unit) выполненные в виде MEMS-датчиков давно используются в смартфонах, игровых контроллерах, носимых устройствах, и т.д. В такой модуль входит акселерометр и гироскоп, вся обработка выполняется на основном процессоре смартфона или микроконтроллера. Для обработки поступающих данных от инерциального модуля, процессор должен быть постоянно в состояние активности. Например, для носимой электроники данный фактор не позволит отправить основной процессор в спящий режим. Вторая проблема заключается в большом лаге между наступлением события и реакции. Например, если необходимо обрабатывать события удара, пока ОС обработает поступающие данные и сделает вывод об ударе, времени на реакцию будет немного. Для решения указанных задач, и не только, компания STMicroelectronics разработала модуль LSM6DSV320X с искусственным интеллектом где вся обработка данных выполняется в самом модуле.
Всем привет!
В первой части мы в общих чертах посмотрели на различия GitHub Actions и GitLab, а также начали разбирать структуру файла .gitlab-ci.yml.
В этой части продолжим разбираться с параметрами и особенностями конфигурации: триггеры, job’ы, артефакты и многое другое.
Не понимаете, «что тут происходит»? Рекомендую начать с первой части:: по ссылке.
Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и практическими примерами из реальных проектов. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.
На страницах Хабра не раз встречались статьи, которые прямо (или косвенно) озвучивали утверждение, что операторы языков программирования "case" и "switch" являются "синтаксическим сахаром" т.е. являются более удобной и наглядной записью последовательности операторов "if". В комментариях, с моей стороны, отмечалось недоумение, по поводу таких заявлений. Для справки приведу общий вид оператора "case" из языка программирования Турбо Паскаль.
case <ключ выбора> of
значение_1: операторы; ... значение_N: операторы;
else операторы;
end;
Когда я учился в университете основам Турбо Паскаля, наш преподаватель сознательно делал акцент на том, что данная синтаксическая конструкция, после вычисления ключа выбора, переходит на соответствующие вычисленному ключу операторы. То есть, без перебора всех ключей, сразу. В этом особенность данного оператора и его принципиальное отличие от последовательности операторов "if" (функционально эквивалентных). Так меня учили.
Авторы статей, считающие иначе, проявили завидное упорство (в комментариях), отстаиваю свою позицию, что привело к желанию разобраться в этом вопросе. (Однажды был даже такой удивительный случай, когда, вероятно начинающий программист, написал статью приблизительно следующего содержания: «А что если ключей выбора очень много? Перебор всех вариантов это долго. А что если попытаться оптимизировать такой нерациональный оператор как „case“, „switch“.» И далее рецепты по оптимизации. После справедливых замечаний в комментариях автор статью удалил. Ну что же, с кем не бывает.)
BIM давно зарекомендовал себя в гражданском и промышленном проектировании. А можно ли использовать информационное моделирование для технологических схем?Демид Сентемов, инженер-проектировщик технологических процессов, разработчик программных решений, ответил на этот вопрос утвердительно. С помощью компонента «СПДС» Платформы nanoCAD и среды API MultiCAD его команда разработала собственный продукт «Промпроектор», предназначенный для создания технологических схем по принципу BIM. Первым пользователем приложения стала компания «РИОС-Инжиниринг», которая уже опробовала новое решение при моделировании технологической схемы для установки реформинга бензина.
Когда вы вводите в командную строку docker run nginx — кажется, что произошло какое-то волшебство: за считанные секунды появляется полностью изолированная среда. Но здесь нет никакой магии, а просто инженерия ядра Linux. Давайте подробнее разберём эту тему подробнее и изучим, что именно происходит внутри ядра, когда Docker создаёт контейнер.
Доброго времени суток, коллеги!
Меня зовут Влад, и в этом году я поступил в университет MBZUAI (Mohamed bin Zayed University of Artificial Intelligence, Абу-Даби, ОАЭ) – первый в мире университет по искусственному интеллекту. Основанный в 2019 году, он уже успел занять лидирующие позиции среди ведущих лабораторий мира в области ИИ. Так, по данным рейтинга CSRankings на момент написания данной статьи университет занимает 10-е место в мире. Слышали про Сэма Альтмана, основателя OpenAI, компании, создавшей ChatGPT? 26 сентября этого года MBZUAI торжественно присвоил ему степень PhD.
Привет, Хабр! Меня зовут Кирилл Курдюков, и мы с командой делаем YDB (СУБД Яндекса). Как и с языками программирования, популярность СУБД определяется не только их возможностями, но и экосистемой.
В предыдущей статье я рассказал о том, как разработать Java-клиент для распределённой СУБД и интегрировать его с популярными ORM. А из этой статьи вы узнаете, как под капотом работает ADO.NET, почему управление пулом сессий может сильно влиять на ваш код работы с базой данных и какой стратегии обработки ошибок можно придерживаться для разработки отказоустойчивых сервисов. Статья будет полезна тем, кто изучает особенности взаимодействия в распределённых системах или просто хочет научиться лучше писать клиентский код, работающий с современными распределёнными системами.
Кто-то кайфует от новых возможностей и говорит, что теперь всё будет делаться с AI. Кто-то называет ерундой, говорит AI ничего не может, и придумывает таким разработчикам клички типа “Саша GPT”. Кто-то готовится к обороне кода как Егор Бугаенко (@yegor256) в своём видео “Как защитить код от AI”: https://www.youtube.com/watch?v=GPJ-LfRpxM4 (очень рекомендую посмотреть)
На какой стороне вы? Новаторов или староверов?
Делюсь своим видением происходящего, с какими плюсами и ограничениями столкнулся на практике.
Я налоговый юрист и автор телеграм-канала «Налоговый Инсайдер». В моей работе есть рутинные задачи, которые сложно автоматизировать стандартными средствами вроде Excel. Одна из таких задач — расчет пени по НДС при подаче уточненной налоговой декларации.
В этой статье я расскажу, как не написав самостоятельно ни строчки кода с помощью Gemini и ChatGPT я прошел путь от идеи до работающего приложения на Flask , и с какими неочевидными техническими проблемами (вроде устаревшего Python на хостинге и CGI-скриптов) столкнулся гуманитарий-юрист пытаясь запустить современную программу на обычном хостинге.
Когда я взялся полноценно портировать API Windows с C на Lua, одна из самых интересных и занимательных задач заключалась в том, как делать обратные вызовы к коду C из функций Lua. Без них значительная часть API — например, WNDPROC – осталась бы бесполезной.
Первая часть цикла «Разбираем net/http на практике»: создаём с нуля сервис DeadDrop — аналог Privnote для безопасной передачи самоуничтожающихся сообщений и файлов.
На чистой стандартной библиотеке net/http разбираем основы:
• запуск HTTP-сервера
• маршрутизация в ServeMux
• написание middleware (логирование и recovery от panic)
• работа с HTML-шаблонами и layout’ами
• подключение статики через http.FileServer и embed.FS
В итоге получаем работающий сервер с красивой главной страницей, формой создания «ячейки» и базовой архитектурой проекта — всё без внешних зависимостей.
Идеально для начинающих и тех, кто хочет глубоко понять внутренности популярных фреймворков вроде Gin и Echo. Пишем код вместе!
В этой статье я хотел бы рассмотреть микросервисные паттерны под другим углом. Когда я начинал изучение микросервисных паттернов, у меня постоянно был вопрос: Так это же было в другом паттерне. Я решил немного структурировать их: объединить по похожим элементам. Кластеризировать микросервисные паттерны достаточно тяжело так как каждый паттерн по‑своему уникален, однако для запоминания на собеседованиях или для себя это сделать можно. Основной контент статьи — картинка, далее идёт описание, чтобы всё было в одном месте.
Эта статья предназначена для более быстрого запоминания/повторения паттернов микросервисов. Кое‑где я приводил кейсы, которые могут быть непонятны новичкам. Здесь нет подробных кейсов применения каждого паттерна так как иначе статья получилась бы на другую тему. Для удобства я приложил ссылки — чтобы избежать дублей.
Это первая статья о том, как идея проходит путь от прототипа до полноценного продукта — с участием архитектуры на каждом шагу. Формат — ADR (Architecture Decision Records): каждое решение зафиксировано по дням, чтобы показать реальную эволюцию проекта. Продукт вымышленный, проблемы — настоящие. Те самые, с которыми сталкиваются архитекторы и команды. Документация и код — в открытом доступе на GitHub.
