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

За годы работы я подробно изучил, как центральные процессоры (CPU) выполняют код и как они устроены внутри. Дело в том, что я участвовал в разработке ядра Linux и ScyllaDB, а этот код очень близок к металлу. Я даже немного баловался с Verilog, безрезультатно попытавшись собрать моё собственное ядро RISC-V.

Графические процессоры (GPU) в отличие от обычных в основном оставались для меня чёрным ящиком, несмотря на то, что поработать с ними всё-таки довелось. Помню, что экспериментировал с NVIDIA RIVA 128 или чем-то подобным, проверяя, как там работает DirectX. Тогда такие процессоры ещё не выделялись на фоне ускорителей 3D-графики. Я также пытался идти в ногу со временем и немного упражнялся в программировании элементарных шейдеров на современных GPU. Но я никогда глубоко не вдавался в работу с GPU, и мои взгляды можно назвать CPU-центричными.

Однако, поскольку сегодня наблюдается всплеск рабочих нагрузок, связанных с ИИ, и, в частности, приходится работать с большими языковыми моделями (БЯМ), графические процессоры становятся незаменимыми для современных вычислений. К задачам, решаемым с применением ИИ, относятся масштабные прикладные тензорные операции, в том числе — сложение и перемножение матриц. А это уже работа для GPU. Но как современный GPU выполняет их, и насколько при этом возрастает эффективность по сравнению с выполнением таких же рабочих нагрузок на CPU?

Привет, Хабр! Я Никита Иванов, техлид команды «Видео» в KION. В ИТ я уже девять лет, а последние пять работаю с Go. Сегодня расскажу, какую задачу считаю идеальной для собеседования на позицию Go-разработчика. Этот текст — переработка моего доклада с митапа МТС True Tech Go, видеоверсию можно посмотреть тут.

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

Шардирование, двухфазный коммит и распределенные транзакции окружены определенными мифами и заблуждениями. Например, может быть достаточно неочевидно, что двухфазный коммит обеспечивает только атомарность транзакций, но не их изоляцию. Поэтому мы решили написать пост, который бы помог разобраться в этих сложных вещах и сделать правильный выбор, когда Postgres'а Вам станет мало и Вы столкнётесь с шардированием.

Стартапам нужно ответственнее относиться к безопасности

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

Вообще, я менеджер.

Но когда-то писал код и всегда любил это занятие. Серьезно прогал мобильные приложения, и даже заработал за один из ответов на SO больше 100 звездочек.

Но с тех пор прошла куча времени.

И последнее время меня вновь увлекла эта тема. А как она может увлечь современного человека, измученного миллиардом фреймворков и отставшего от прогресса лет на 15?
Конечно-же курсором и вайб-кодингом.

И я начал кодить.

Собрал несколько ботов, потом замахнулся на CMS. Сейчас даже делаю свою тулзу для запуска LLM-пайплайнов с импортом их из n8n.

Но в процессе всего этого неизменно сталкивался с двумя проблемами

1) Cursor (и брат его Windsurf) паршивейшим образом обходится с нетипизированными и слабо-типизированными языками. Изобретает названия переменных, меняет их по ходу, и вообще, забивает на это огромный и толстый... За пределами этого кодит он неплохо. Но данная штука лично у меня порождает 90% багов.
2)...

Привет, Хабр! Я Борис Ермаченко, фронтенд-разработчик сервисов для физических лиц ПСБ. В этой статье рассмотрим, как с помощью ESLint построить архитектуру в проекте, и поговорим про несколько подходов.

Также прикладываю бонус — демо-проект, где можно экспериментировать и пробовать все подходы.

2035 год. Мир больше не нуждается в тех, кто хочет просто войти в IT.

Всё началось с автоматизации простых задач. Сначала — тесты. Потом — верстка. Потом — интеграции, бэкенд, фронт, дизайн, продакт-решения. GPT-10 умел собирать целые MVP по описанию идеи в голосовом сообщении. Midjourney Designer Suite проектировал UI лучше, чем весь Dribbble вместе взятый. Запускать стартап стало делом десяти минут и кредитной карты.

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

Недавно я задался вопросом: а возможно ли написать для ARM нативную программу, которая будет бесшовно работать сразу на 4-х операционных системах без необходимости перекомпиляции для разных платформ и ABI. Мне очень хотелось реализовать возможность писать кроссплатформенные эльфы для мобильных телефонов из нулевых и попытаться портировать на них эмуляторы ретро-консолей. Погрузившись в документацию на исполняемые форматы, я пришёл к выводу, что да — это возможно и смог реализовать такую программу на практике без читерства по типу VM! Всех гиков приглашаю под кат!

Друзья, всем привет, в последнее время в нашей среде завелась такая пикантная паника: "ИИ скоро заменит всех программистов, и мы станем не нужны!". Причём кричат так, будто бы уже завтра мы все проснёмся безработными. Но давайте вспомним, мы видели разные "замены" в IT: когда-то пугали, что калькуляторы заменят математиков, компьютеры — бухгалтеров, в 90-е уверяли, что языки высокого уровня отымут профессию разработчика, а сейчас нас пугают нейросетями. Одни предрекали, что low-code убьёт программистов, другие — что автоматизация заменит всех, но все эти прогнозы оказались преувеличением. Поэтому я встречаю такие пресказания скорее с интересом, а не с паникой.

Мэтт Годболт, знаменитый разработчик Compiler Explorer — потрясающий человек, вам стоит найти в вебе и изучить весь созданный им контент. Именно этим и занимался, просматривая Correct by Construction: APIs That Are Easy to Use and Hard to Misuse. Я уже больше двадцати лет работаю с C/C++, поэтому эта тема была мне близка.

Когда я смотрел его доклад, ко мне постоянно приходила мысль: «Да! И именно поэтому в Rust это делается так». После просмотра видео я подумал, что этот доклад — отличный способ понять, как Rust помогает разработчикам не только в безопасности по памяти, и в своей статье я расскажу об этом.

Но прежде нам следует поговорить о поднятых Мэттом проблемах и о том, как он предлагает решать их в C++. Сделайте себе одолжение и посмотрите доклад целиком, а я разберу один из его пунктов.

Началось все с того, что при проектировании своего устройства на микроконтроллере ATtiny 85, которое должно было работать от встроенного li‑ion аккумулятора, я изначально не задавался целью измерения заряда АКБ, поскольку в этом не было необходимости. Однако, собрав все устройство на печатной плате, я подумал над тем, почему бы не добавить такую возможность.

Прочитав в Интернете, как это можно было реализовать, стало ясно, что сделать это вряд ли удастся, поскольку все порты PB[0:5] уже были заняты и, следовательно, не было возможности применения АЦП с аналогового пина (при чем порт PB0 я не мог настроить на вход опорного напряжения AREF - он должен был использоваться как управляющий выход).

Долгое изучение состояния регистров АЦП в datasheet на ATTiny 85 привело меня к следующей идее: в качестве опорного напряжения может быть выбрано само напряжение питания VCC (биты REFS [0:2] регистра ADMUX установлены в 0), а в качестве измеряемого ‑ напряжение VBG с внутреннего стабилизатора в 1.1В (биты MUX [3:0] регистра ADMUX установлены соответственно в 1100). То есть, для измерения напряжения питания не нужно ничего, кроме, собственно, самого питания VCC!

Многие из вас помнят, какими были 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С. За это время я успел его изучить, полюбить, возненавидеть, снова полюбить и, наконец, написать эту статью, чтобы поделиться своими впечатлениями, страданиями и неожиданными открытиями.