Эпиграф:
Приходит чувак к музыкантам, в группу просится. Те у него и спрашивают: 
- А ты на гитаре играть умеешь? 
- Нет. 
- А на барабанах? 
- Тоже не умею. 
- Может ты поешь? 
- Не пою. 
- Зачем ты нам тогда нужен? 
- Знаете, я просто офигенный друг!

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

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

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

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

// ХОРОШО

fn frobnicate(walrus: Walrus) {

... }

// ПЛОХО

fn frobnicate(walrus: Option<Walrus>) {

let walrus = match walrus {

Some(it) => it,

None => return,

};

...

}

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

Привер, Хабр!

В копилку статей про DeepSeek, которых здесь уже великое множество, хочу забросить ещё пять копеек в виде практического отчёта о инсталляции на Xeon, о котором меня попросили в комментариях к посту «Мануал по запуску полной модели DeepSeek-R1 локально...». Кому любопытно — может заглянуть под кат, ну а тем, кто уже выполнил упражнение по установке — вероятно будет совершенно неинтересно.

Давеча наткнулся в экс-Твиттере на интересный тред (https://x.com/carrigmat/status/1884244369907278106?s=52) о том, как запустить самую мощную (на сегодня) ИИ reasoning модель DeepSeek-R1 прямо у себя под столом.

DeepSeek-R1 — это одна из топовых моделей (из Китая), наделавших много шума (и не только), для задач логики, математики и программирования. Она настолько умная, что может (с некоторыми оговорками) "конкурировать" с решениями от OpenAI, но при этом её можно запустить локально, без интернета, без смс и полностью контролировать весь процесс.

Почему это круто?
* все данные остаются с вами, никакие сторонние сервисы не получат доступ к вашим запросам.
* запуск на своём железе избавляет от затрат на облачные сервисы.
* модель способна решать сложные задачи и выдавать результаты на уровне профессионалов.

В статье я расскажу:
* какое оборудование нужно для запуска DeepSeek-R1.
* чем локальный запуск отличается от серверного.
* какие возможности открывает эта модель и как она может быть полезна.
* как сохранить безопасность и приватность при работе с ИИ.

В этом мануале описано, как настроить локальный запуск модели DeepSeek-R1 Q8, сохраняя максимальное качество и производительность без дистилляции или уменьшенной квантизации. Общая стоимость сборки составит около ~$6,000, и ниже приведены все необходимые ссылки на компоненты и инструкции.

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

Нет, это не обязательно саботаж. Иногда это банальная прокрастинация, страх ошибиться, потеря мотивации, или просто неумение сказать: «я застрял». Но проблема‑то реальная. Если не ловить и не разруливать — команда тонет в самообмане, а ты — в вечных переносах.

Разберёмся, почему разработчики врут (осознанно и не очень), какие признаки надо замечать раньше, и как перевести разговор из «всё нормально» в «честно, я залип». С кейсами, приёмами и без розовых очков.

Picturephone навел шороху в СМИ не меньше, чем первый iPhone, но так и не дождался своего звездного часа. Его история началась задолго до первой презентации в 1964-м, а дизайн воплощал фантазии кинематографистов о связи будущего. Вот только когда будущее наступило, люди оказались к нему не готовы. Пресса называла Picturephone проявлением «инженерного высокомерия» и чем-то «слишком опередившим свое время».

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

Сначала представлюсь: меня зовут Нина, я дочь физика, редактор техноблогов, а еще пишу для команды спецпроектов в МТС. Надеюсь, вам понравится читать этот текст так же, как мне понравилось над ним работать — в том числе искать старые газеты и фотографии. Если будут вопросы, пишите в комментариях, постараюсь на все ответить. Начнем!

В прошлых частях мы подключились к Godot, обсудили адаптацию к API и разобрались с устройством тела функции. Дальше в планах было перейти к входным и выходным данным, от них к общей архитектуре и далее снова к особенностям API. Если бы я отстрелялся быстрее, то так бы и было, но я возился слишком долго (об этом чуть ниже), из-за чего до моей телеги успел доползти читатель с типовым набором набивших оскомину вопросов. Допускаю, что я собрал всю коллекцию практикующих читателей, но мне хочется верить, что где-то прячется «молчаливое большинство» с аналогичными проблемами. Поэтому я решил передвинуть некоторые рассуждения из конца цикла в середину.

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

Сегодня мы продолжим разбирать базовые концепции реактивности, изложенные Райаном Карниато (Ryan Carniato), автором SolidJS. Если ранее мы затрагивали производные и их планирование, то сегодня разберём более сложную тему — асинхронность в контексте реактивного программирования. Эта концепция добавляет новый уровень сложности, поскольку требует учёта динамических процессов, выходящих за рамки синхронных операций.

Мне лично это удивительно, но оказывается, что до последних пор мы не знали, как появляются седые волосы. Мы просто видели, что у некоторых людей седина появляется чаще и раньше. Почему? Что за это отвечает? Есть ли способы с этим бороться, кроме пересадки волос?

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

Мы успели слетать в космос, походить на Луне, и уже трижды побывали на самом дне Марианской впадины. А тайна седых волос, которые растут почти у каждого на голове, была разгадана только два года назад.

Объяснение тут довольно непростое (отсюда тег “Сложно” в этой статье, если что).

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

Делюсь личным опытом превращения старенького ноутбука ASUS X552CL (Intel i5-5200U, 12 ГБ RAM, SSD + HDD), выпущенный 12 лет назад, в полноценный домашний сервер под Linux Ubuntu Server 24.04.5 LTS.

Получилось что-то вроде мини-датацентра на дому — он хранит файлы на жёстком диске с бэкапом в облаке, Docker-контейнеры крутит для дата-аналитики и даже имеет легковесный интерфейс XFCE, при этом есть потенциал к росту до терминала для управления умным домом. Расскажу, почему было решено отказаться от WSL на рабочем ноутбуке Huawei, как настроить удалённый доступ через xRDP (чтобы не было чёрного экрана), запустить там Docker, сборку Superset и JupyterLab с Anaconda (с разными версиями Python), прикрутить Samba-шару для домашнего использования и организовать бэкап в облачном хранилище. В этой статье будет немного технических деталей, щепотка шуток и парочка мемов с советскими плакатами.

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

Финансы, ритейл, соцсети, облака – везде свои тараканы, но требования схожи: чтобы летало и не падало. Балансировка нагрузки – это как фундамент для небоскреба. Криво зальешь – все рухнет. И вот тут стандартный Round Robin, при всей его простоте, часто оказывается тем самым кривым фундаментом.

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

Чуть более 51 года назад с мыса Канаверал взлетела ракета с тремя астронавтами и космическим автомобилем. После трехдневного полёта на Луну двое астронавтов забрались в веретенообразный посадочный аппарат и совершили короткий спуск на поверхность, где ещё три дня собирали камни и дрифтовали на космическом автомобиле. Затем они вернулись в корабль, присоединились к своему коллеге на орбите и отбыли на Землю. Их капсула упала в южной части Тихого океана 19 декабря 1972 года. Эта миссия, «Аполлон-17», станет последней на сегодняшний момент, когда люди выходили за пределы низкой околоземной орбиты.

Если верить НАСА, в конце 2026 года американцы снова будут ходить по Луне. Эта миссия называется «Артемида-3», и её лунный сегмент очень похож на «Аполло-17» без космического корабля. Два астронавта высадятся на Луну, соберут камни, сделают сэлфи и примерно через неделю после посадки присоединятся к своим коллегам на орбите, чтобы вернуться на Землю.

Но если «Аполлон-17» стартовал на одной ракете и обошёлся в 3,3 миллиарда долларов (в пересчёте на доллары 2023 года), то первая посадка «Артемиды» предполагает десяток или два запусков тяжёлых ракет и стоит столько, что НАСА отказывается называть общее число (один ветеран бюджетирования НАСА оценивает её в 7-10 миллиардов долларов).[1] Одноразовый посадочный аппарат для этой миссии будет самым тяжёлым из когда-либо летавших космических аппаратов, и все же научный результат миссии — маленькая коробка камней — будет меньше, чем то, что прилетело домой на «Аполлоне-17». И весь план зависит от технологий, которые ещё не изобретены и станут надёжными и практичными в течение следующих восемнадцати месяцев.

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

Знакомый каждому сценарий: добавляем новую опцию, правим сразу несколько мест и... допускаем ошибку. Опечатки в тегах, забытые дефолтные значения, «мертвые» конфиги, которые годами живут в проекте, отнимая внимание и время. Звучит болезненно, правда?

Я решил, что хватит терпеть это, и вдохновился простотой стандартного пакета flag, где каждая опция — это буквально одна строка кода. Представьте: больше никакой беготни по структурам и файлам! В zerocfg вы объявляете опцию, дефолтное значение и документацию в одной строке — лаконично, понятно, надёжно.

Делимся в комментах ссылками на свои проекты, получаем обратную связь, знакомимся и исследуем чужие продукты! 

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

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