Теперь официально, я тупее ИИшки...

Есть код управления связанным списком, в который мне реально тяжело погружаться и дебажить.

Играя с ним в этой демке я заметил иногда бажное поведение и предвкушая пару часов пытливого дебага попросил Opus написать тест по аналогии с моделькой приложения.

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

Коммит фикса.

Поиграться с демкой: https://stackblitz.com/github/reatom/reatom/tree/v1000/examples/reatom-jsx. Это, кстати, очень крутой шоукейс перфа reatom/jsx - создайте 10к элементов и поперетаскивайте их - все летает. А потом попробуйте это сделать на другом фреймворке =)

P.S. в демке драг вниз работает хорошо, а драг элемента вверх почему-то все дергает, опус не смог пофиксить, у вас есть идеи?))

Opus (Thinking) только что опять заваншотил сложную багу внутри реатома.
(скажите, если эти темы вас уже достали)
Интересно что думал он над ней минуты две точно, а потом выдал простое решение и все. Я очень-очень удивился, но потом решил перепроверить на других моделях:

- Grok Code - начал какую-то ваще левую вещь править, остановил не дождавшись результата

- Gemini 3 Pro Preview - решил проблему, но по дороге зачем-то сломал и потом героически починил все тесты, и еще добавил ненужную логическую проверку, которую потом не удалил.

- GPT-5.1 Codex Max - оч долго думал (как и опус) потом сделал рабочее и продуманное решение, но которое мне все же чуть меньше подходит

- Sonnet 4.5 (Thinking) - повторил подвиг опуса, но через большее число шагов.

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

Большая просьба ко всем пролайкать и порепостить новость про релиз Reatom v1000:

- Статья на dev.to

- Пост в x.com

- Красивый лендос (просто напоминаю)

Через три часа в artalogg будем писать адаптеры реатома к разным библиотека: solid, preact, vue (самое сложное) и посмотрим на "нативные" сигналы (tc39 proposal)

да

Preact очень порадовал своими option hooks, они позволили дергать реактивно атомы прям в JSX (без доп оберток):

const count = atom(0, 'count')

const Counter = () => (
  <div>
    Count: {count() /* <-- magic here */}
    <button onClick={wrap(() => count.set((s) => s + 1))}>+</button>
  </div>
)

Так что, можно пользоваться: https://v1000.reatom.dev/reference/preact

К сожалению, автоматический wrap для колбеков, пока, не понятно как сделать. Еще подумаю, но, возможно, придется предлагать дорабатывать хуки.

2025 Огромный рост ИИ требует немыслимое количество ресурсов.

2026 Производство переориентируется на ДЦ (дата-центры), потребительская электроника становится дороже.

2027 ДЦ имеют значительное преимущество в производительности над частными устройствами, софт естественно подстраивается под это.

Рынок перестроился, все завязано на ИИ, который не работает на портативных устройствах, а портативные устройства не имеют смысла без ИИ.

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

2029 И восстали машины из пепла ядерного огня...

2029 В очередном патч релизе ChatGPT не правильно указываются зависимости useEffect и происходит каскадный перегруз и отключение серверов, в том числе тех что управляли инфраструктурой. К этому моменту количество обслуживающего все сети мира кода увеличилось в 1000 раз из-за вайбкодинга и понять и поднять существующую инфру человеку оказывается невозможным. Наступают темные века...

Главная проблема, по моей практике, заключается не размере памяти или скорости цпу, а в скорости доступа к памяти, это место где производительность чаще всего сыпется.

Т.е. да, иногда что-то дешевле пересчитать, чем иметь это в доп переменной, но не потому что переменная забивает память (и увеличивает работу GC), а потому что ходить за этой переменной в лишнее замыкание может быть дороже.

Все так :)

LLM помогает решать самые большие проблемы в программировании (скрин реальный, только что на работе сделал).

Меня заставили написать этот занудный пост XD:

Почему в настройках следует называть булеан опции так, чтобы их дефолт значение было false.

Причин несколько:

Двойное отрицание при использовании

// Если юзер активен
if (user.isActive) { ... }

// не неактивен
if (!user.isInactive) { ... }

Принцип "минимального конфига" или CoC (Convention over Configuration) или YAGNI (You Aren't Gonna Need It).

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

- По умолчанию функция выключена (false)
- Пользователь явно включает (true)

Feature Proof
В какой-то момент булеан может потребовать больше уточнения, включить как именно.
Ну например:

minification: false | true | { loose: boolean }

Когда мы передаем { loose: boolean } это как бы естественно нам говорит что оно будет включено с этими настройками

Альтернативы сильно хуже, ну например:

disableMinificaton: { loose: boolean }

или

disableMinificaton: false,
minificationOptions: {
  loose: boolean 
}

Lofree Flow Lite.

Подустал от клавы мака, захотелось попробовать что-то новое. Долго выбирал между этой и Nuphy AIR75 v3, которая дороже и не понятно какие свичи надо было брать, так что решил попробовать Lofree.

Звук - идеально, как и мечтал, очень доволен. Щелкающий, но не оч громкий.

Тактильно - тоже кайфовая, пластик хороший. НО: 1) ход клавиш под углом имеет трение, немного коробит, но думаю очень быстро привыкну; 2) руки сразу привыкли и начали печатать вслепую, но трацепивидность клавишь и глубина хода подбешивают, много лишних касаний других кнопок (ни на что не влияет, чисто ощущения так себе), мб привыкну; 3) свичи линейные - мне не в кайф, хочется тактильно чувствовать "поп-ит".

Сверху клавы мака встает нормально на ножках (под углом), без них жмет на кнопки.

Самое большое удивление и проблема - кнопка Win, и других версий не бывает 🤦‍♂️

В целом, доволен, но попробую вернуть и взять Nuphy с Brown свичами, т.е. тактильными, а не линейными.

P.S. бежевый на картинке выглядел классно и в живую она супер, но с моим голубым маком не оч сочитается.

Абстрактно вышло... Вот мои тейк:

- "функциональный" дизайн кода, через набор параметризированных функций / компонентов и их комбинации - избыточная абстракция из стародавних времен бедности стандартной библиотеки.

До сих пор часто можно встретить ФРП (Rx и тп), "глупые компоненты" с props drilling, логику из нескольких не переиспользумых утилит с бОльшим числом параметров, чем этих утилит. Кмк это все антипаттерны в современной разработке.

У нас достаточно системных утилит и фреймворков, что бы сфокусироваться на логике приложения и не разбивать ее на "читаемые блоки" (кмк это устаревший взгляд на код). Напомню, выносить код в функции даже при дублировании логики не всегда надо, DRY не обязателен.