В мире баз данных, где каждая миллисекунда на счету, а объемы информации растут как на дрожжах, выход PostgreSQL 18 стал настоящим подарком для разработчиков и администраторов. Это не просто косметический апгрейд, а глубокая перестройка подкапотных механизмов, от облачных хранилищ до высоконагруженных OLAP-систем. Давайте разберемся, что там в этом релизе появилось и/или изменилось.
Привет! Нет, вы не ошиблись — это действительно историческая статья. Но не о Риме, а о статическом анализе кода. Хотя... чем он хуже? У него тоже есть свои императоры-родоначальники, войны с багами и даже падения (пожалуйста, не запускайте анализ на некомпилируемом коде).
Я долго не понимал, почему «Размышление о Римской империи» стали одним из самых популярных мемов прошлого года, пока сам не начал ловить себя на навязчивых мыслях о статическом анализе. Разобравшись в его истории, я решил поделиться с вами этим исследованием.
Меня зовут Владислав Столяров, я руководитель команды анализа безопасности продуктов в мультипродуктовой экосистеме МойОфис. Кстати, идея статического анализа напрямую связана с компиляторами (разбор кода, как никак). Поэтому уместно вспомнить, что недавно мы открыли исходный код собственного компилятора tsnative, позволяющего использовать в одном приложении сразу два языка — TypeScript и C++. Скачать и поисследовать можно по ссылке (лицензия Apache 2.0).
А теперь вернёмся к истории статического анализа. Пойдём по порядку и и попробуем восстановить хронологию его становления...
Занимаясь проектированием систем ПО, идите самым простым путём из возможных.
Причём эту рекомендацию можно применять на удивление широко. Я искренне верю, что так можно делать всегда. Эта техника подходит для исправления багов, обслуживания имеющихся систем и проектирования новых.
Многие инженеры, продумывая дизайн системы, представляют себе некий её «идеал»: что-то стройное, практически бесконечно масштабируемое, удобно распространяемое и так далее. Я же считаю, что это абсолютно ошибочный подход к проектированию ПО. Напротив, нужно вложить всё это время в глубокий анализ имеющейся системы, а затем реализовать простейшее рабочее решение.
Привет, Хабр! На связи Олег Сивченко @OlegSivchenko редактор направления «Компьютерная литература».
Наша первая статья в корпоративном блоге вызвала ваш огромный интерес (+122) и оживлённое обсуждение с участием 30 пользователей (считая нас). На наш взгляд, вас заинтересовал вопрос авторских черновиков и доработки их до полноценных рукописей. Развивая тему, связанную со свободным ПО, хочу рассказать вам сразу о трёх наших знаковых книгах, посвящённых операционной системе Linux. Эти книги написал легендарный харьковский программист Олег Иванович Цилюрик (1951 — 2024), к сожалению, не дождавшийся выхода в свет 2-го издания своей книги «Linux и Go. Эффективное низкоуровневое программирование» (оглавление). Opus Magnum, принадлежащий его перу и вышедший у нас в марте 2023 года, называется «Расширения ядра Linux. Драйверы и модули» (оглавление). Кроме того, мы выпустили экзотический и по-своему незаменимый труд Олега Ивановича, который называется «Сети Linux. Модели и приложения» (оглавление), посвящённый настройке, эксплуатации и внутренней организации оверлейной сети Yggdrasil (октябрь 2023). Эта книга очень хорошо вписалась по духу и уровню в разрабатываемую нишу кибербезопасности, и, судя по отзывам на маркетплейсах, незаменима в нашу эпоху не столь свободного Интернета. Наконец, Олег Иванович самоотверженно справился с переводом одной книги O’Reilly —«Изучаем eBPF: программирование ядра Linux для улучшения безопасности, сетевых функций и наблюдаемости», вышедшей у нас в июле 2024 года. Давайте расскажу о двух из этих книг немного подробнее.
В 90-х и 2000-х студия Impressions Games выпускала отличные исторические градостроительные симуляторы. Я играл во все игры этой серии от незабываемого Caesar 3, который вообще был первой моей компьютерной игрой на отцовском компуктере, до Императора про древний Китай. Но египетский Pharaoh и греческий Zeus запомнились намного четче, но вот почему я сказать не берусь.
Единственное серьёзное отличие между Фараоном и Зевсом в нетехническом плане — это были графические ресурсы, внутри же там полностью сменилась вся команда и со слов старожилов сменился движок, но серия уже была известна и многочисленные отличия по возможности скрыли, перенеся практически без изменений разные механики из Фараона в Зевс, да похоже перестарались, и многим сейчас игра покажется скорее дополнением, а не полноценной номерной частью серии.
Привет, Хабровчане!
Это продолжение моего дневника разработки DIY струйного принтера предыдущая часть:
DIY Open Source принтер. Часть 0
В прошлый раз одной из поднятых проблем стал интерфейс между ПК и устройством. В данной статье я постараюсь решить вопрос подключения STM32 по USB и убедить Windows и Linux что это принтер.
Содержание
§1. Кратко о USB
§2. Поиск реализаций USB Printer Class для STM32
§3. Реализация USB Printer Class для STM32
§4. Тест на Windows
§5. Тест на Linux
§6. Как добавить поддержку печати изображений?
Привет, Хабр! Меня зовут Алексей Николаевский, и мы с командой делаем СУБД Яндекса. С 2013 года в Яндексе использовали Kafka для потоковой передачи данных. Но Kafka со временем перестала справляться с растущими объёмами, и в 2017 году мы перешли на своё решение.
Брокер сообщений YDB Topics во многом вдохновлялся Kafka: в нём также есть топики, партиции и аналогичные способы работы с данными. Но есть и существенные отличия, о которых в конце прошлого года я рассказал на московской конференции HighLoad. Под катом — адаптированная для Хабра статья по мотивам этого доклада: про архитектуру транзакций в обеих системах и интересные для разработчиков детали и нюансы, которые мы обсуждали на конференции.
Команда AI for Devs перевела статью, в которой автор делится прогнозами о будущем ИИ-агентов в 2025 году. Его выводы: несмотря на шумиху, «автономные агенты» столкнутся с экономическими и техническими барьерами. Почему текущий подход к архитектуре агентов не сработает и какие методы действительно приносят результат — читайте в статье.
Большие языковые модели (LLM, Large Language Model), как подсказывает их название, часто отличаются значительными размерами и слишком велики для того, чтобы нормально работать на обычных компьютерах. Масштабы этих моделей могут измеряться миллиардами параметров. Обычно для обеспечений достойной скорости их работы необходимы GPU с серьёзными объёмами видеопамяти (VRAM).
Из-за этого проводится всё больше и больше исследований, посвящённых уменьшению размеров подобных моделей. Исследователи совершенствуют обучение моделей, используют адаптеры, прибегают к другим способам их оптимизации. Один из главных приёмов уменьшения размеров моделей называется квантованием (quantization).
Приветствуем, коллеги!
Вы читаете первую статью от имени издательства «БХВ» (BHV) из Санкт-Петербурга, которое наконец-то решило официально обосноваться на Хабре и попробовать систематизировать нашу работу на этой великолепной платформе, объединив рекламный контент, тизеры и спойлеры в корпблоге. Меня зовут Олег Сивченко, я тружусь в БХВ менеджером проектов в области компьютерной литературы 4+ года, одновременно работаю в редакции Хабра, где веду небесспорный, но очень интересный научно-популярный блог @OlegSivchenko и блог с IT-переводами @Sivchenko_translate Кроме меня в команде БХВ есть ещё один маститый хабровчанин, пишущий под псевдонимом Валентин Холмогоров @Holmogorov — ведущий редактор журнала «Хакер», ранее работавший в отрасли кибербеза, руководил командой технических писателей. Так что, феномен хаброблога и хабрааудитории для нас не в новинку. Далее — немного о нашем издательстве.
Если вы осваиваете JavaScript, то наверняка знаете об операторах rest и spread. Первый группирует несколько значений, второй - разгруппировывает. Но давайте посмотрим чуть глубже.
Привет, Хабр! Меня зовут Александр Дудукало, я автор базового курса по JavaScript. В этом тексте на примерах разберемся, что означает каждый оператор и как использовать их на практике. Подробности под катом!
Как следует отображать на экране результат деления 3.0 на 10.0 ? Сколько цифр следует вывести, если пользователь не указал точность?
Скорее всего, вы даже не знали, что вывод на экран чисел с плавающей запятой — это сложная проблема, настолько сложная, что по ней написаны десятки научных статей, причём последний прорыв был относительно недавно, в 2016 году. На самом деле, это одна из самых сложных частей поддержки чисел с плавающей запятой в среде выполнения языка.
Давайте продолжим разговор о самой неоптимизированной в мире библиотеке эмуляции плавающей точки при помощи целочисленной арифметики.
Это вторая статья из цикла «Санпросвет о плавающей точке»:
2. Вывод чисел с плавающей точкой на экран <- вы тут
Сколько часов в день вы проводите в терминале? Часто задумываетесь о том, что какую-то операцию можно сделать быстрее? Любите привлекать внимание коллег необычным видом своего рабочего стола? Сегодня я решил собрать не просто интересные приложения, позволяющие повысить продуктивность работы, но и те, которые однозначно вызовут внимание окружающих и вопросы в стиле «а что это за софтина такая?».
Так что временно отвлекитесь от работы и мигающего курсора, налейте себе кофейку и посмотрите, какие эмуляторы терминала позволят вам вывести рабочие процессы на новый уровень, а заодно прокачать визуальное и информационное пространство используемой оболочки.
В мире Data Science написание нейронных сетей, кажется чем‑то очень трудоёмким, доступным для понимания лишь математикам с многолетним опытом. Многие руководства, начинаются со сложных объяснений backpropagation, градиентного спуска и т.п, от которых у новичков складывается впечатление, что написание нейросетей — им не по силам. В данной статье, я хочу развеять подобные убеждения и показать пример, написания простейшей нейронной сети на python. Мы не будем углубляться в теоретические основы высшей математики. Вместо этого, мы просто возьмем данные, напишем код, посмотрим на результат и проанализируем его.
Привет, Хабр! Меня зовут Глеб, я Java-разработчик в Сбере. Сегодня я хочу рассказать про исторический контекст двух фундаментальных подходов к системе типов в программировании.
Наверное, каждый разработчик, знает, что такое статическая и динамическая типизация (или хотя бы одно из этих понятий). Действительно, все современные языки программирования можно отнести либо к статически, либо к динамически типизированным. Идеи, лежащие в основе этих подходов, достаточно легко объяснить на пальцах: при строгой типизации мы знаем все типы, используемые нашей программой, ещё во время её компиляции.
При динамическом же подходе эта информация для нас открывается только во время выполнения программы (run-time) — это даёт больше гибкости и потенциального удобства при написании кода, однако влечёт за собой множество очевидных проблем: любая ошибка, связанная с типами данных, просто не будет выявлена на этапе компиляции и потребует дополнительного тестирования.
Сегодня я хочу рассказать, как вообще зародились эти два подхода, и как они пришли к тому виду, в каком мы знаем их сейчас.
PostgreSQL 18 вот-вот выйдет, и это не просто минорное обновление, а настоящий прорыв для разработчиков и администраторов БД. В новом переводе от команды Spring АйО рассмотрим ключевые новинки — асинхронный I/O для ускорения чтения, поддержка UUID версии 7 с улучшенной сортировкой, skip scans в B-tree индексах, виртуальные вычисляемые столбцы и даже OAUTH 2.0 для аутентификации. Всё это делает Postgres ещё более быстрым, гибким и современным.
Недавно мне понадобилось сэмулировать работу с плавающей точкой только при помощи целочисленной арифметики, поскольку флоаты были недоступны. Полез я было в интернет за готовой библиотекой, и чуть не утонул. Мало того, что я не нашёл того, что искал, это бог с ним. Я обнаружил, что в интернете кто-то неправ. :)
Оказалось, что форумы кишат людьми, которые не до конца понимают, как компьютеры манипулируют числами. Например, мемасик с КПДВ я стянул с реддита (перечеркнул его я). Кто-то настолько был напуган страшными ошибками округления чисел с плавающей точкой, что даже смешную картинку смастерил. Только вот проблема в том, что 0.5 + 0.5 в точности равно 1.0.
Таким образом, я решил засучить рукава, и изобрести велосипед. То есть, написать самую неоптимизированную C++ библиотеку для эмуляции IEEE754 32-битных чисел с плавающей точкой при помощи исключительно 32-битной целочисленной арифметики. Библиотека уложится в несколько сотен строк кода, и в ней не будет никакого битхакинга. Задача написать понятный код, а не быстрый. А заодно хорошенько его документировать серией статей.
Итак, этим полукреслом мастер Гамбс начинает новую партию мебели, или статья первая: поговорим о числах и компьютерах.
Хочу поделиться своим опытом разработки крупных игровых проектов на C++, где производительность и стабильность — это не просто приятные бонусы, а абсолютно естественные требования к разработке. За годы работы над движками и играми я понял, что подход к управлению памятью очень сильно влияет на весь проект. В отличие от многих приложений - игры, особенно большие, часто работают часами без прерываний и должны поддерживать стабильный фреймрейт и отзывчивость. Когда проседание fps или фриз происходит на глазах у сотен тысяч игроков, вам уже никто не поможет — ущерб уже нанесен, а в steam полетели отзывы о кривизне рук разработчиков.
Однажды моя команда закончила работу над довольно интересным проектом, который портировали больше двух лет на плойку. Движок старый, большой и мощный, но работа с памятью была ориентирована на ПК времен конца 2000-х, и что меня поразило, так это насколько сильно большая часть кодовой базы зависела от динамической памяти во время выполнения. На ограниченном железе (далеко не у всех есть PS5 pro) и в условиях жёстких требований к сертификации на консолях такие решения быстро превращаются в проблему.
В разработке для консолей (про мобильные устройства я молчу, потому что игра не влезает по памяти даже в восемь гигов) с ограниченными ресурсами, архитектура с частыми аллокациями не просто неэффективна — она становится реальной угрозой для стабильности проекта. Каждое выделение памяти в куче влечёт за собой накладные расходы: это дополнительные !миллисекунды! (в целом на кадре) задержки, риск большой фрагментации памяти, и непредсказуемое поведение в долгой игровой сессии. После двух часов игры постоянные операции с кучей буквально «сжигают» половину бюджета кадра.
Сегодня речь пойдёт о том, как превратить приблизительные оценки сроков выполнения задач в надёжные прогнозы, и о том, как рассказывать об этих прогнозах другим.
Оценка сроков выполнения задач — это важное дело. Но, в то же время, подобные оценки доставляют массу неприятных эмоций множеству инженеров и программистов. Оценки сроков являются источником напряжения, которое возникает между командами разработчиков и всеми теми, кто так или иначе с ними взаимодействует. Это — менеджеры, другие отделы компаний, клиенты.
Всё дело в том, что почти все до сих пор неправильно рассказывают другим об этих оценках.
Оригинал этой статьи НЕ загружается с веб-сервера, работающего на одноразовом вейпе. Если вы хотите увидеть сам сервер, то это можно сделать здесь. В остальном контент идентичен.
Предыстория
Уже пару лет я собираю коллекцию одноразовых вейпов, полученных от друзей и членов семьи. Поначалу я только извлекал аккумуляторы для «будущих» проектов (это точно не синдром Плюшкина), но в последнее время одноразовые вейпы стали гораздо более продвинутыми. Не хотел бы я быть юристом, которому придётся доказывать, что устройство с разъёмом USB C и перезаряжаемым аккумулятором можно классифицировать, как «одноразовое». К счастью, в ближайшее время я не планирую подаваться в юриспруденцию.
В прошлом году я разбирал одну из этих технологичных сосок для взрослых и заметил нечто любопытное: вместо обычной чёрной капли, которой заливают ASIC (Application Specific Integrated Circuit), я увидел небольшую интегральную схему с маркировкой «PUYA». Не буду винить читателей, если это название не вызвало у вас того же восторга, что и у меня — большинство людей никогда его не слышало. Эта компания больше всего знаменита своими флэш-чипами, но впервые я узнал о них из поста Джея Карлсона о самом дешёвом флэш-микроконтроллере. Это довольно мощные крошечные микроконтроллеры ARM Cortex-M0+.
За последний год у меня скопилось довольно много таких одноразок с PY32; это были разные модели вейпов одного производителя. Я не буду бесплатно рекламировать табачный бренд, но выражу благодарность проектировщику за маркировку на отладочных контактах!
