Программирование *

5 марта 2025 года в Steam вышла игра Bongo Cat. Милый котик из мема, стучащий своими лапками по столу каждый раз, когда вы нажимаете какую-либо клавишу или кликаете мышью.
Люди в умилении, пишут восторженные отзывы. Игра набрала 98% положительных отзывов, что превосходит такие шедевры как Detroit Become Human, Lethal Company, Subnautica... Мило, прикольно, необычно.

Чувствуете подвох? :)

Эта игра убивает ваши драгоценные системные ресурсы. Каким образом счётчик нажатий с метой в виде небольших украшений и скинов может требовать больше ресурсов, чем некоторые игры?!

Разберём игру по косточкам ("основная часть"), найдём ошибку автора и сделаем выводы ("часть выводов").

Возможно это было уже давно, но я увидел только сегодня.

А именно, когда начинается новый чат в Claude, то там появляются такие подменюшки под окном для чата

Write - Learn - Code - Life Stuff - Claude’s Choice

Кликнул ради интереса последнюю, открылся ещё целый список. И он, кстати, все время меняется.

В общем, это заготовки для начала чата по определённой теме, т.е., образец готового промта. Мне попалась на глаза тема "Узнать об архитектурных концепциях". И поскольку живёшь в мире программирования, то первая мысль об архитектурных паттернах )). Но оказалось, что это именно об архитектуре как строительстве чего-то в реальном, физическом мире.

Тем не менее, интересным оказалось другое. В автоматически начатом чате даётся пример промта, который полезно рассмотреть с точки зрения того, что ИИ учитывает и на что обращает внимание при выполнение запроса.

Мне очень нравится идея потоков данных в Node.js - data streams. Они используются всюду: чтение файлов, сетевые запросы, архивирование файлов.

Не путать с потоками выполнения процессов - threads! Это совсем другое!

Есть много хороших статей по философии, теории и применении потоков, Хабр не стал исключением:
Ментальная модель потоков в Node.js

Много раз я сталкивался с необходимостью реализовывать свои потоки данных. И каждый раз я путался с кучей методов: write, push, _write, _read, с кучей событий - end, close, finish. В чем отличие write от _write?! Буквально почти все время, когда я имею дело с потоками у меня открыты доки Node.js - https://nodejs.org/api/stream.html.

Недавно, в моей статье про кастомный транспорт для ShadowSocks мне потребовался функционал передачи разных потоков данных по одному потоку (каналу)данных. Это задача мультиплексирования данных.

Я думаю, что эта задача является хорошей практикой для новичков в Node.js и программистов, любящих кодить всякие алгоритмы.
Во время программирования я встретился с несколькими "программистскими задачами" aka "подводными камнями", которые мне пришлось решить, и это было увлекательно, что и вылилось в данную статью.

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

Вычисление обратной матрицы, а именно, вычисление алгебраических дополнений и определителя матрицы займёт большое количество машинных ресурсов при квадратной матрицы высокого порядка. В статье описывается решение и приводятся результаты обращения квадратной матрицы методом решения системы AX = E, где A, X, E - квадратные матрицы порядка n, X - обратная A матрица, E - единичная матрица, и методом LU декомпозиции.

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

В данной статье мы расскажем о принципах «чистого кода» в React, которые используем в повседневной разработке, и покажем их на коротких примерах.

В 1936 году Алан Тьюринг, пытаясь формализовать пределы вычислений, сформулировал вопрос, навсегда изменивший не только компьютерную науку, но и наше понимание границ познания. Этот вопрос — известная как «Проблема остановки» — звучит обманчиво просто: можно ли создать алгоритм, который, анализируя код любой программы и её входные данные, заранее и безошибочно определит, завершится ли её работа или же она уйдёт в бесконечный цикл? Казалось бы, речь идёт о чисто технической задаче, мечте каждого программиста об идеальном отладчике. Однако ответ Тьюринга, уместившийся в элегантное и почти язвительное доказательство от противного, оказался оглушительным: нет, такой алгоритм принципиально невозможен. В этой статье мы не только разберём суть этого гениального доказательства, которое построено на самореференции и логическом парадоксе, подобном «лжецу», но и визуализируем его ход с помощью наглядного кода в MATLAB, превратив абстрактную логику в динамическую демонстрацию. Мы увидим, как гипотетическая «всезнающая» программа H неминуемо запутывается в сетях, расставленных специально сконструированной программой-провокатором , приводя к неразрешимому противоречию в любом исходе. Это открытие — не просто академическая курьёзность. Оно устанавливает фундаментальный, алгоритмический предел: существуют чётко поставленные вопросы, на которые мы никогда не получим однозначный «да» или «нет» от любой вычислительной машины. Мы проследим глубокую связь этого результата с теоремой Гёделя о неполноте, обсудим другие неразрешимые проблемы, такие как проблема соответствия Поста, и затронем трезвые последствия для современной разработки, верификации программ и даже для мечтаний о создании всесильного искусственного интеллекта. Эта история — о том, как осознание непреодолимой границы стало одним из самых мощных интеллектуальных достижений человечества, чётко очертив то, что мы можем знать, и указав на бескрайние области того, что мы знать не в силах.

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

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

И когда до Нового года остаётся совсем немного времени, а сил на сложные технические материалы почти не остаётся, мы решили немного сменить ритм. Вместо глубоких разборов — лёгкое, тёплое и предпраздничное чтение. Так появилась идея серии интервью с участниками нашего комьюнити — людьми, которые создают плагины для OpenIDE.

Привет, Хабр! Мы — Настя, Эвелина и Михаил — бэкенд-разработчики Т-Банка, пишем код на Scala и горим желанием его популяризировать. Всех с наступающим Новым годом, желаем сходимости типов во всей вашей жизни! 

Приветствуем любую обратную связь! (づ ◕‿◕ )づ

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

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-скриптов) столкнулся гуманитарий-юрист пытаясь запустить современную программу на обычном хостинге.