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

Вот вам маленькая задачка на программирование: реализуйте такой макрос, который принимает в качестве аргумента числовое выражение (числа могут быть целыми или с плавающей точкой) и:

Многие из вас помнят, какими были IT-школы 10 лет назад. Это были просто сайты с полезными курсами по различным языкам программирования. Не было агрессивного маркетинга и обещаний звездных зарплат. Можно было с гордостью говорить о том, что ты прошёл какие-то курсы. Но главное — эти курсы действительно работали: после них удавалось устроиться на работу. Сейчас всё стало значительно хуже по всем направлениям. Перенасыщенный рынок, конкуренция между школами, вынужденная смена бизнес-модели, появление AI — всё это превратило IT-образование в то, каким мы видим его сегодня: в большой, неповоротливый и неэффективный организм с утраченной репутацией. Давайте разберёмся, как так получилось, и главное — что с этим делать.

Привет! С вами Леша Жиряков, техлид backend-команды витрины онлайн-кинотеатра KION и по совместительству пропагандист Python: в МТС я возглавляю Python-гильдию. Но как бы много я ни говорил про преимущества этого ЯП, многие стандартные инструменты экосистемы ограничены. Тот же pip не всегда эффективно разрешает конфликты зависимостей, например при сложных иерархиях пакетов. Это сказывается на производительности команд разработчиков, особенно когда проекты растут и кодовая база увеличивается.

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

Сегодня хочу обсудить два таких инструмента — Ruff и uv. Давайте посмотрим, как эти технологии могут трансформировать повседневный рабочий процесс и сэкономить нам время. Погнали!

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

Эта серия статей родилась как заметки на полях к замечательной книге Game Engine Architecture, книга большая, объемная и охватывает все аспекты создания движка. Но там нет нюансов практической разработки. А чтобы видеть нюансы надо понимать не только теорию, все же GAE больше теория, но знать как работает код игры изнутри. Чтобы понимать как, и главное почему, используются выбранные механизмы внутри игры, чтобы видеть проблемы с производительностью и архитектурой, как их искать и как чинить, для этого придется понять как работают и как создавались игровые движки.

Если мне не изменяет память - Кармак сказал, что лучший способ [создания игр] — написать собственный движок ( "The right move is to build your own engine" ), на что многие возразят: это вовсе не так просто. Но папа Doom'a известен не только своим вкладом в разработку игровых движков, но и довольно часто высказывался критически о развитии игровых движков в целом, и о преимуществах создания собственных технологических решений вместо использования готовых.

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

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

Что-то в этой идее пробудило любопытство автора, поэтому в статье он попытался удовлетворить его и ответить на вопрос: как на самом деле хранятся изображения?

За годы своего развития C# существенно эволюционировал; одна из самых мощных фич языка — это сопоставление с образцом (pattern matching).

Работая недавно над небольшим хобби-проектом, я наткнулся на такую прекрасную строку кода C#.

if (person is not null and { Age: > 18 })

{}

Выглядит изящно. Откровенно говоря, она заставила меня призадуматься.

Годами я писал проверки на null и свойства-аксессоры классическим образом:

if (person != null && person.Age > 18)

{}

Функционально? Да. Удобочитаемо? Не особо. Безопасно? Спорно, особенно когда код становится сложнее.

Я решил создать шорт YouTube об этом современном синтаксисе. Это небольшое забавное напоминание о том, что C# позволяет при помощи сопоставления с образцом комбинировать проверки на null и обращение к свойству в одно условие.

Я понятия не имел, что это короткое видео приведёт к гораздо более глубокому исследованию, и покажет мне, насколько полезно и универсально сопоставление с образцом в современном C#.

Эта фича повышает читаемость, уменьшает объём бойлерплейта и обеспечивает более выразительную обработку логики.

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

Здравствуйте, уважаемые читатели!

В этой статье я хотел бы поделиться необычным и вдохновляющим проектом — реализацией арканоида в текстовом VGA-режиме, написанного полностью на Rust, без использования стандартной библиотеки и даже без аллокации памяти (#![no_std] + no_alloc).

Проект работает напрямую с VGA-памятью и PS/2 клавиатурой через порт 0x60, создавая абсолютно нативную игру в стиле 80-х, но с современным вниманием к качеству кода. И всё это — с участием милого талисмана Platinum-tan.

Привет, Хабр (и просто случайные читатели, зашедшие сюда в поисках истины или интересной статейки на пару минут)!

Так вышло, что последние полгода я провёл в тесных объятиях «Личного кабинета сотрудника» на Элементе — новом языке программирования от 1С. За это время я успел его изучить, полюбить, возненавидеть, снова полюбить и, наконец, написать эту статью, чтобы поделиться своими впечатлениями, страданиями и неожиданными открытиями.

Привет! Я ex. Разработчик из VK, сейчас принял оффер от Ozon'a, и за последний месяц я прошел собеседования в 4х бигтех компаниях: Ozon, Avito, Wildberries и T-Bank и везде дошел до финалов/офферов. Пообщавшись во многих группах, посвященных Go-разработке, я понял, что много умных ребят готовясь к собесам не имеют четкой системы подготовки, и из-за этого заваливают технические собесы в компании. Не претендуя на истину в последней инстанции, предлагаю свою методику подготовки к собесам, которая помогла мне и моим знакомым подготовиться к техническим собесам во все популярные ру-бигтехи.

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

Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

Используем силу уравнений Ньютона и численных методов для моделирования динамики простых плоских мешей в реальном времени! В конце вы сможете моделировать падение ножниц ✂️ как на анимации

Раз в несколько лет я устраиваю в нашей исследовательской группе челлендж «Напиши медленный код». Цель – написать код с минимально работоспособным количеством инструкций на цикл (IPC) с условием, чтобы этот код выполнялся на заранее подобранном сервере с архитектурой x86.

На первый взгляд, это абсурд В сущности, так и есть. Однако есть в этой безумной задаче и некоторая методическая ценность. Инженеры, проектирующие процессоры, прилагают все усилия ради достижения наивысшего возможного IPC… даже для очень неэффективного кода. Так и задумано, что писать код с очень высоким показателем IPC непросто. Следовательно, челлендж «Напиши медленный код» оказывается заковыристым упражнением, вынуждающим задумываться, как именно работает процессор, и как применить себе на пользу его острые углы.

Недавно прогремел пост Артура Думчева (@arturdumchev), как халява якобы уходит из программирования. Можете ознакомиться с ним, чтиво достойное. Особенно комментарии.

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

Давайте начнем с точно того же определения, как было у Артёма: «для меня халява — это гарантированный результат за вложенные усилия. Логика повествования требует такого определения, дальше всё будет ясно».

А дальше ясно, что из неверно поставленного условия может следовать что угодно.

Меня зовут Олег, и в Яндексе мы с командой занимаемся Python-обвязкой вокруг нашей базы данных YDB. Python знаменит «батарейками в комплекте», широким ассортиментом библиотек на все случаи жизни, включая богатую экосистему для работы с базами данных. Есть свой интерфейс DBAPI (PEP-249), несколько конкурирующих ORM и многочисленные уровни абстракции между софтом и базами. В этой статье — о том, как мы делали полноценную интеграцию нашей базы данных с Apache Superset: чтобы достаточно было выбрать YDB из выпадающего меню и начать визуализировать аналитические данные.

В IT-сообществе не утихают споры о ценности формального образования. Одни считают, что только фундаментальное образование формирует инженерное мышление. Другие уверены, что самоучки не уступают выпускникам вузов благодаря свободному доступу к фреймворкам и онлайн-ресурсам. Мы в Artezio провели круглый стол с экспертами отрасли и собрали аргументы с обеих сторон и разобрались, кого ищут работодатели в эпоху, когда код пишут LLM.

Всем привет! С вами Леша Жиряков, техлид backend-команды витрины онлайн-кинотеатра KION. Сегодня будет обзор Python 3.14 — в общем и целом он построен на официальной документации, которая ежедневно обновляется в преддверии финального релиза. Так что «улыбаемся и читаем» (привет, «Мадагаскару»), но сильно не напрягаемся.

Когда уже релиз? Скоро, коллеги, скоро. Финальная версия должна появиться на свет 7 октября. Багфиксы будут выходить примерно каждые два месяца в течение двух лет, а обновления безопасности — вплоть до 2030 года. Пока можно насладиться новыми фичами 7-ой альфа-версии. Точнее, последней альфа-версией — дальше нас ждет бета. Ну, погнали!