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

Если вам неудержимо хочется использовать оборудование из музея для современной разработки — статья специально для вас.

Stack Overflow, некогда главная платформа для программистов, переживает кризис: за два года трафик упал почти на 90%. Что стало причиной — изменившиеся привычки пользователей или ошибки самой платформы? Давайте попробуем разобраться в происходящем. А еще посмотрим, что администрация делает для спасения и что ждет сообщества разработчиков в новой реальности, где ответы на вопросы находятся быстрее, чем успеваешь их задать.

8 лет назад я исправил опечатку в чужом репозитории, а сейчас регулярно делаю коммиты в проекты, которые использую, и даже вошел в core team библиотеки с 27000 звёзд на GitHub

В этой статье покажу, что участие в Open Source проще, чем кажется. Расскажу, как регулярная работа с чужим кодом помогает быстрее разбираться в незнакомых кодовых базах, писать тесты и лучше документировать решения. А также объясню, почему публичная активность на GitHub выгодно отличает вас от других разработчиков, особенно в эпоху повсеместного использования ИИ.

Эта статья — краткая заметка о двух связанных друг с другом эмпирических правилах.

Поднимайте If вверх

Если внутри функции есть условие if, то подумайте, нельзя ли его переместить в вызывающую сторону:

// ХОРОШО

fn frobnicate(walrus: Walrus) {

... }

// ПЛОХО

fn frobnicate(walrus: Option<Walrus>) {

let walrus = match walrus {

Some(it) => it,

None => return,

};

...

}

В подобных примерах часто существуют предварительные условия: функция может проверять предусловие внутри и «ничего не делать», если оно не выполняется, или же может передать задачу проверки предварительного условия вызывающей её стороне, а при помощи типов (или assert) принудительно удовлетворить этому условию. Подъём проверок вверх, особенно в случае предварительных условий, может иметь лавинообразный эффект и привести к уменьшению общего количества проверок. Именно поэтому и возникло это правило.

На написание этой статьи меня вдохновила история Из бариста в программиста. Как я освоила SQL за неделю и стала тимлидом в IT-компании меньше, чем за год

Ещё пару лет назад моим основным стеком были: бутылка "Балтики девятки", пакет из «Пятёрочки» и лежание на скамейке под обновления погоды.

На дворе 2025 год, а я всё ещё продолжаю делать видеоигры. Если верить archive.org, я начал заниматься этим двадцать лет назад! Достаточно долгий срок для одного увлечения...

Когда я рассказываю о том, над чем работаю, люди часто спрашивают меня, как я делаю игры, и их часто удивляет (а иногда и тревожит?), когда я говорю, что не пользуюсь коммерческими игровыми движками. Существует какой-то стереотип, что если ты делаешь игры не в популярном инструменте наподобие Unity или Unreal, это значит, что ты чуть ли не вручную пишешь ассемблерный код.

Я искренне считаю, что создание игр без огромного «многофункционального» движка может быть проще и интереснее, а часто и позволяет оптимальнее тратить вычислительные ресурсы. Я не делаю игру, в которой «есть всё», поэтому мне не нужны 90% фич, предоставляемых движками. Все мои игры обладают конкретным стилем и у меня есть конкретные способы работы с моими инструментами. Часто оказывается так, что используемым по умолчанию реализациям фич в крупных движках наподобие Unity не хватает столь многого, что мне всё равно приходится писать их самостоятельно. В конечном итоге, мои проекты по большей мере оказываются моими собственными инструментами и системами, а движок становится необходим лишь для создания удобного UI и части рендеринга...

Тут можно задаться вопросом, а зачем вообще использовать движок? Что он даёт? Зачем я позволяю инструменту потенциально препятствовать моей работе, когда его владельцы внезапно принимают неэтичные и ужасные бизнес-решения? Или выпускают обновление, которое требуется для запуска моей игры на консолях, но ломает всю систему в игре, заставляя переписывать её? Зачем я ежедневно борюсь с этим для работы с движком, пока я постепенно заменяю все его стандартные системы и он постепенно становится только загрузчиком ресурсов и фреймворком UI редактора?

Что такое TypeScript? Официальная документация отвечает так: “TypeScript — это JavaScript с синтаксисом типов”. Однако некоторые считают TypeScript своеобразным слиянием двух языков: языка для манипулирования значениями JavaScript и языка для манипулирования типами.

Cистема типов TypeScript Тьюринг-полная. Это означает, говоря по-простому, что система может решить любую вычислительную задачу при наличии некоторого представления входных и выходных данных.

Можно ли использовать это знание на практике? Как избежать крайностей от примитивного аннотирования типов до избыточного усложнения?

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

Показанным ниже кодом вы можете проверить на високосность год в интервале 0 ≤ y ≤ 102499 всего примерно тремя командами CPU:

bool is_leap_year_fast(uint32_t y) {

return ((y * 1073750999) & 3221352463) <= 126976;

}

Как это работает? Ответ на удивление сложен. В статье я объясню процесс; в основном он связан с забавным битовым жонглированием. В конце мы обсудим применение этого кода на практике.

Нас ждёт мозговыносящая смесь 64/32-битного ассемблера и старого-доброго C++. Мы сделаем собственную реализацию... Волокон (fibers) без вызова Win API и звонков в службу спасения.

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

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

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

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

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

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

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

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

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

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

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

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

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

Началось все с того, что при проектировании своего устройства на микроконтроллере 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-образование в то, каким мы видим его сегодня: в большой, неповоротливый и неэффективный организм с утраченной репутацией. Давайте разберёмся, как так получилось, и главное — что с этим делать.

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

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

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

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