Всем привет! В этой статье я собрал практические фишки работы с Telegram Mini App: что здесь реально проще, чем в обычном вебе, какие возможности Telegram дает из коробки, и что чаще всего вызывает затруднения при разработке.
В языке C++ перегрузки функций и шаблонов исторически были и остаются мощным инструментом для выражения различных реализаций одного и того же интерфейса. Многим перегрузки видятся как удобный способ дать одно имя разным функциям, но на практике понимание того, как компилятор выбирает нужную перегрузку, может стать источником ошибок и недоразумений. Компилятор же руководствуется сложным набором правил, которые мы ему предоставили, учитывает не только типы аргументов, но и порядок специализаций, преобразования типов, const-квалификаторы, шаблонные параметры и многое другое. А ошибки, возникающие при перегрузках, часто трудно диагностировать, поскольку сообщение компилятора может ссылаться на глубоко вложенные детали реализации вместо очевидного исходного кода. Об этом была предыдущая статья...
С введением концептов и ограничений (requires) язык получил возможность управлять этой сложностью на уровне интерфейса. Вместо того чтобы надеяться на магию перегрузки и изощрённые трюки вроде SFINAE, мы теперь можем прямо выражать намерения: какие свойства должен иметь тип, чтобы функция или шаблон были корректны, что позволило перейти от «магии разрешения перегрузок» к декларативному описанию требований к типам.
Давайте теперь поговорим о том, что именно делают ограничения (requires) в современном C++ и почему появление этого механизма стало таким важным шагом в развитии шаблоннов. Тут надо сделать немного шаг в сторону и вспомнить, что исторически шаблоны в C++ были мощным, но довольно опасным инструментом, еще одним языком в языке, на котором можно было сделать почти всё, было бы желание. В итоге компилятор позволял подставить или подхачить любой тип, а проверка того, «подходит ли он на самом деле», откладывалась до момента инстанцирования, что нередко приводило к ошибке далеко от места вызова, а сообщение о непосредственном ��есте ошибки превращалось в многостраничный отчёт о внутренней кухне компилятора и как он работает с шаблонами. requires меняют эту модель, позволяя описывать ожидания от типа явно и прямо в объявлении функции или класса.
Некоторое время назад я обнаружил, что мой доселе чистый и светлый интернет стал подвержен проблеме, которую лично я охарактеризовал как "подзатупы". В данной статье описано, как мне удалось решить данную проблему "малой кровью" путем разработки простого, но от того не менее эффективного решения для репликации IP-пакетов через разные интернет-каналы.
Всем привет! Недавно я опубликовал статью, в которой сказал что она будет последней по Easy Maven т.к. все что можно я уже делегировал Maven - импорт проекта, запуск тасков, анализ зависимостей. Но недавнее обилие багов в IDEA 2025.3 связанных как с зависанием так и повышенным потреблением памяти Maven проектами, окунуло меня в баг трекер IDEA, где я нашел много похожих проблем, которые также затрагивают и мавен индексы. Помню как меня самого это раздражало, когда IDEA чуть ли не при каждом открытии, начинает сканировать локальный репозиторий. Про это даже писали в комментариях - где ответ был один - отключить это. Плюс недавно один из постов в тг канале (спасибо за это @javadev), еще больше убедил меня в том, что так дальше жить нельзя и я решил поправить проблему поиска зависимостей так как я ее вижу - не изобретать велосипед, а делегировать поиск туда, где это уже реализовано. Ведь как известно: самый лучший код - тот который ты не написал. Посмотрим что из этого вышло.
Если на минуту задуматься, великая это вещь - колесо. Человечество значит разок его попробовало и все. Подсело. Теперь почти ни дня без колеса. Завертелось всё, закрутилось, как хоровод вокруг новогодней ёлки.
Так и я намедни сделал для семейных развлечений свою вариацию на тему игры «Поле чудес», а в поле чудес кто главный герой? Нет, нет, отнюдь не «импозантный мужчина в усах». Я имел в виду – красавец барабан. А барабан это что? Правильно, барабан – колесо. Поэтому, один раз научившись вращать двухмерное колесо в игре на движке Godot я уже не смог остановиться. Захотелось мне это колесо еще где-нибудь использовать на благо прогрессивного человечества.
А тут как раз каникулы длинные нарисовались. И чтобы не было соблазна все выходные сидеть в теплых светодиодных лучах монитора, я сделал простенькое колесо фортуны, которое поможет мне с выбором занятия на день.
И как всегда готов поделится результатом с вами.
Аннотация
Год Красной Лошади начинается с кода.
Первый день 2026-го. За окном — хрустальная тишина, налитая зимним светом. В комнате — только монитор и пустая командная строка. Пока город медленно просыпается после боя курантов, у нас с вами, инженеров и кодёров, есть идеальный момент: между прошлым годом и рабочими буднями зияет цифровая пустота. Давайте заполним её огнём.
Что, если вместо тысячного «Hello, World!» или очередного скучного графика, наши скрипты устроят настоящее огненное шоу? В духе наступившего года Красной Лошади — яростное, стремительное, неуправляемо-красивое. Если за окном нет праздника — мы создадим свой. Свою вселенную, где искры не гаснут, а фейерверки взрываются по нашему желанию. Прямо здесь. Прямо сейчас. Первого января, когда всё ещё можно.
Новогодняя симуляция — это не просто игрушка. Это идеальный полигон, где красота сталкивается с математикой лоб в лоб. Вы видите волшебство: ракета взмывает, замирает на миг — и взрывается снопом огненных брызг. Но под этой магией — чистая, честная физика. Дифференциальные уравнения диктуют полёт. Стохастика правит хаосом разлёта. Фракталы плетут снежинки. Это шанс доказать, что MATLAB — не сухой инструмент для расчётов, а кисть. Холст. Дирижёрская палочка для симфонии из нулей и единиц.
В этой статье мы не будем ходить вокруг да около. Мы возьмём законы Ньютона, щепотку случайных чисел и горсть пикселей — и соберём из них фейерверк. С нуля. Прямо на ваших глазах. Напишем движок, который дышит. Заставим частицы танцевать. Добавим ветру — словно от взмаха гривы той самой Красной Лошади. И в конце — самое главное — вы получите не просто скрипт. Вы получите власть над праздником. Меняйте гравитацию. Рисуйте новые узоры. Создавайте свои миры.
Год только начался. Давайте встретим его не как потребители, а как творцы. Первый взрыв — уже в следующей строке кода.
Firebase - динамическое переключение проектов в iOS приложении
В этой статье мы глубоко погрузимся в технические детали работы с Firebase и рассмотрим:
- Как и почему можно использовать Firebase проект без регистрации Bundle ID
- Традиционные способы переключения Firebase конфигураций (compile-time)
- Динамическое переключение проектов во время работы приложения (runtime)
- Практический пример: миграция пользовательских данных между приложениями
- Безопасность и важные моменты
Всем привет!
Прямо в канун Нового года — а именно 31 декабря — Telegram представил крупное обновление Bot API 9.3. И не просто представил, а громко заявил: «Революция ИИ в чатах».
И, если пробежаться по списку изменений, масштаб обновления для ботов действительно ощущается — особенно в проектах, где используется ИИ. Давайте вместе пройдёмся по чейнджлогу и посмотрим, что Telegram приготовил нам в подарок на Новый год.
Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и новостями. А прямо сейчас у нас там ещё и проходит новогодний розыгрыш.
Привет, Хабр!
2025 год выдался богатым на конференции и митапы, которые мы успели посетить, а некоторые даже организовать. В этой статье мы совершим небольшой тур по городам и событиям этого года, важным для нашей команды.
Buckle up, folks!
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.
Привет, Хабр!
Cегодня разберём экспериментальную фичу Kotlin 2.2 — контекстные параметры. C помощью контекстных параметров функции и свойства могут объявлять зависимости, которые неявно передаются при вызове.
Допустим, есть сервис логирования UserService, который нужно часто передавать во многие функции. Без контекстных параметров пришлось бы всюду писать fun outputMessage(users: UserService, msg: String). С параметрами контекста достаточно объявить функцию так:
Микросервисный подход казался выбором по умолчанию в последнее десятилетие. «Делай микросервисы – и будет хорошо», – намекал опыт построения огромных программных систем. Вместе с тем в последнее время в сети всё чаще встречаются мнения, что «не нужны нам эти микросервисы», и тому есть причины.
Статья инспирирована переводом Распределенный монолит: тихий убийца мечты о микросервисах и некоторыми комментариями, отражающими, что тема описана не слишком подробно. Покажу видение данной темы немного с другой стороны.
