Все потоки

В XVI веке японцы, не отрываясь от бесконечных войн феодальных домов, познакомились с пришельцами из-за морей с далёкого запада. Европейцы обладали многими полезными знаниями и технологиями наподобие мушкетов и заводных механизмов — и японские интеллектуалы стали увлечённо изучать языки, науку и культуру иноземцев. Одной из удививших их вещей стало то, что в английском, голландском и испанском языках дни недели назывались в той же самой смысловой последовательности, что и в японском, и в китайском. Воскресенье везде было днём Солнца (или Бога), понедельник — днём Луны. Далее чуть сложнее, с участием древних богов и даосских стихий, но в целом в той же астрономической логике небесных тел или связанных с ними божеств. Как получилось, что одна и та же схема именования дней недели уже не первое тысячелетие присутствует в языках очень разных и отдалённых друг от друга стран? Попробуем разобраться.

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

Я здесь, чтобы сказать вам: дело было не в вас.

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

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

«Напиши учебник. Тот самый, который мы заслужили».

Что ж, это он. Глава первая. Забудьте всё, что вы знали. Мы начинаем с нуля.

Мы отправимся в путешествие к самым основам человеческого мышления. Мы увидим, как драма, начавшаяся 2500 лет назад с простого вопроса о летящей стреле, породила всю современную науку — от физики до нейросетей.

Пристегнитесь. Мы погружаемся.

Если бы мне платили каждый раз, когда меня спрашивают: «А почему нам не выдают парашюты?», я бы уже летал не на Boeing, а на личном Gulfstream.

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

А знаете, что действительно экономит вам жизнь? Не парашют, не катапульта и не чудо-капсула. Вас спасают скучные штуки, нормативы на 90 секунд эвакуации, негорючие кресла, злой бортпроводник, который орет «Сумки бросили!», и миллионы часов налета, на которых инженеры и пилоты отточили сценарии так, чтобы вы вообще никогда не увидели катастрофу своими глазами.

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

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

При выборе серверной архитектуры важно не только учитывать текущие задачи, но и просчитывать расходы на модернизацию на горизонте 3–5 лет. В этой статье мы расскажем, какие принципы заложили в собственный сервер и как это поможет бизнесу сегодня и в будущем. Подробности под катом!

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

Имея малую долю художественных навыков или даже просто «чувства прекрасного» с толикой терпения и усидчивости, своими золотыми можно делать удивительные вещи, тем более что современные технологии и материалы позволяют, например, легко работать с такой сложной субстанцией, как стекло, даже не слишком подготовленным барышням и школьникам. Речь пойдёт о небольших декоративно-прикладных работах из цветного стекла, и двух простых вариантах светильников на их основе. Светильники на основе витража, тоже демонстрируют работу из стекла на просвет, но по сравнению с витражами классическими — мобильнее, проще адаптируются в обстановку, легко заменяются и не зависят от внешнего освещения. В части №1 мы рассмотрели светильник-ящик, при должном исполнении, внушительно, под стать самому витражу, выглядящий, требующий однако, некоторого столярного навыка, оборудования и места для пыльных и пахучих (отделка) работ. Предлагаемые же здесь варианты подсветки намного проще и лучше приспособлены для хоббийных стеснённых квартирно-балконных условий.

Приветствую всех!
В прошлый раз я уже рассказывал, как устроен и как работает современный карточный таксофон и какими методами защиты он обладает.

Но оставался ещё один блок, который я тогда так и не упомянул. К моему удивлению, в интернете не так много информации по тому, как он устроен и как работает. Именно о нём мы сейчас и поговорим, а заодно и узнаем, как и от чего он вообще защищает.

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

Пришёл ноябрь, а это значит, что Хабр и ЭКОПСИ завершили очередное масштабное исследование и составили новый рейтинг IT-брендов работодателей. Давайте вместе узнаем, как изменился рынок за 2025 год.

Итак, некоторое время назад, я осознал, что для мелкого прототипирования печатных плат мне уже не хватает возможностей ЛУТ/фоторезиста (да и сверлить всё равно потом отверстия надо), поэтому задумал я перейти на следующий уровень — делать мелкие партии печатных плат с помощью ЧПУ фрезера, который и был благополучно приобретён, модели Lunyee 3018 Pro Ultra, и весь дальнейший рассказ будет о том, что это за зверь.

Думаю, что многим будет интересно... ;-)

Допустим, вам нужно протестировать LLM на сотни миллиардов или почти триллион параметров в локальной среде — на своих данных, которые вы не хотите отдавать в облако. Задача сводится к сравнительным экспериментам или вообще к развертыванию решения внутри своей сети под небольшую нагрузку, если пользователей мало. Масштаб этих моделей ведет к проблеме: памяти одной видеокарты не хватит, а использование серверов с несколькими GPU может повлечь большие расходы на инфраструктуру.

В таких случаях альтернативой становится запуск LLM на центральном процессоре (CPU), который хотя и медленнее GPU, но гораздо дешевле. Например, если сервер с двумя CPU обойдется за месяц в 150 000 ₽, то сервер с GPU — более 700 000 ₽. Конечно, сервер с GPU может «прожевать» больше запросов. Но если вам столько не надо?

Привет, Хабр! Меня зовут Никита Староверов, я системный архитектор в Selectel. В этой статье рассмотрю, насколько реалистично запускать современные крупные языковые модели исключительно на CPU. А еще — покажу, какие инструменты и подходы позволяют загружать и выполнять такие модели, какие требования к железу и насколько производительность системы остается приемлемой для практического использования.

Мой стаж как больного человека, зависимого от никотина, 11 лет. С июня сего года я больше не употребляю никотин никаким образом. Отказ произошёл одним днем без абстинентного синдрома и отката. Но есть важный нюанс — для этого мне понадобился год. Мне удалось освободиться не совсем стандартным способом, который оказался самым действенный из всего, что я пробовал.

Привет, Хабр! Сегодня я расскажу и покажу, как собрать радиоконструктор гитарной педали реверберации от китайской компании Landtone с добавлением интересной и полезной модификации — стереофонического выхода.

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

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

Все мы начинали с print() для отладки, но в серьезных проектах это превращается в хаос. Стандартный logging? Мощно, но громоздко. Пора это исправить.

Loguru — это библиотека, которая делает логирование простым, как print(), и мощным, как logging, но без боли и десятков строк конфигурации. В статье покажу, как одной строкой настроить цветные логи, автоматическую ротацию файлов и ловить исключения с полным контекстом переменных. Заходите, чтобы сделать свою отладку в разы приятнее.

В современном ИТ сложилась парадоксальная ситуация.

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

Парадокс объясняется просто: в современном ИТ отвратительная организация. Настолько отвратительная, что многих её директоров впору увольнять, потому что именно они отвечают за её значительную часть, но многого не делают.

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

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

Даже если они не из ИТ-сферы.

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

Мне захотелось понять, насколько далеко я смогу зайти, оставив в computer vision только самый минимум: одни лишь 8-битные изображения в градациях серого; никаких сложных структур данных, старый добрый C, немного байтовых массивов и единственный файл заголовка. В конце концов, изображение — это ведь просто прямоугольник из чисел, не так ли?

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

Нашему VDS-хостингу — 10 лет. За это время нас серьёзно пытались купить четыре раза, ещё пару раз — несерьёзно.

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

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

У каждого, кто работает с высоконагруженными системами, своя коллекция боевых шрамов. Знаете эти истории про инциденты, когда всё идёт совсем не по плану? У меня тоже есть такая — очень показательная. Правильные инструменты, лучшие практики, опытная команда — и всё равно куча проблем. Это хороший повод рассказать, почему даже самых продвинутых инструментов может быть недостаточно, когда не видишь всей картины.

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

React — популярная библиотека JavaScript, которая заслуженно пользуется популярностью у фронтендеров. А вот Angular часто называют избыточно усложненным и даже отчасти устаревшим. Мне довелось поработать на реальных проектах и с тем, и с другим, каждый раз проходя путь от «да как на этом вообще можно работать» до «человечество не придумало ничего лучше».

Привет! Я Полина, фронтенд-разработчик в Selectel. В этой статье я решила залезть в темные уголки React и Angular, чтобы лично посмотреть, что же там происходит. Для чистоты эксперимента я выбрала шесть типовых несложных задач, для решения которых подойдет и фреймворк, и библиотека. Подробности под катом.

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

Откройте любой пулл‑реквест в проекте с любой «чистой архитектурой» и вы скорее всего увидите не обсуждение бизнес‑логики, а срач. «Это нельзя класть в UseCase, это логика домена!», «Зачем тут еще один DTO, мы же просто поле прокидываем!», «Этот интерфейс не нужен, у нас никогда не будет другой реализации!». Полагаю, очень много людей с таким сталкиваются.

Эта статья — о том, почему архитектура из спасения превратилась в тонны говнокода. И, что самое главное, — как прекратить этот хаос и, наконец, начать просто писать код, который работает, а не «следует всем концепциям».