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

Когда спрашиваю у людей на собесах, или когда в команде решаем, как клепать очередной проект, такое порой слышу, что становится страшновато. Мне кажется, лет через 5 все компании будут обитать в мультивселенной безумия из “микросервисов”, которую они себе радостно построили, уходя от этих ваших страшных “монолитов”.

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

“Электронщики, как учит нас Парацельс, самозарождаются среди паяльников, радиодеталей, универсальных плат и проводов” (@teap0t)

Возможно, это действительно так, но без хорошей книги - учебника или справочника, которые служат катализатором, этот процесс может так и не завершиться. А лучшей книгой для начинающих разработчиков электронных схем и практически библией электронщиков последние сорок лет, считается "Искусство схемотехники" (англ. - The Art of Electronics) Пауля Хоровица и Уинфилда Хилла.

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

Меня увлекла тема отказоустойчивости, а конкретно - отказоустойчивой работы с файлами. В этой статье я попытался соединить все полученные знания:

Кто участвует в процессе записи

Ошибки, которые могут произойти

Что от нас зависит, а что нет

И самое главное - как это этого защититься

Написать этот материал меня побудило... отсутствие хороших статей по корутинам в C++ в русскоязычном интернете, как бы странно это не звучало. Ну серьезно, C++20 существует уже несколько лет как, но до сих пор почти все статьи про корутины, что встречаются в рунете, относятся к одному из двух типов. Или обзор начинается с самых глубин и мелочей, пересказывая cppreference, а потом автор выдыхается и все сводится к "ну а дальше все понятно, возьмите и примените это в своем коде", что напоминает известную картинку с совой. Либо иногда в статьях рассматривается применение корутин на примере генераторов, и этим все и ограничивается. Но, давайте будем честны, генераторы — это замечательно, но за все время моей многолетней карьеры разработчика я, вероятно, делал что‑то подобное генераторам разве что разок, в то время как асинхронный ввод‑вывод приходится использовать почти в каждом проекте. И поэтому меня гораздо больше интересует реализация асинхронного ввода‑вывода с использованием корутин, а не генераторы. Поэтому пришлось разбираться во всем самому.

Аналогичную же задачу решает переход на ipv6, но при этом он требует поддержки со стороны самого транслятора, в то время как Tor абсолютно самостоятелен, хоть он и не является настоящим p2p.

Есть много локальных аналогов ChatGPT, но им не хватает качества, даже 65B модели не могут конкурировать хотя бы с ChatGPT-3.5. И здесь я хочу рассказать про 2 открытые модели, которые всё-таки могут составить такую конкуренцию.

Речь пойдет о OpenChat 7B и DeepSeek Coder. Обе модели за счет размера быстры, можно запускать на CPU, можно запускать локально, можно частично ускорять на GPU (перенося часть слоев на GPU, на сколько хватит видеопамяти) и для такого типа моделей есть графический удобный интерфейс.

И бонусом затронем новую модель для качественного подробного описания фото.

UPD: Добавлена информация для запуска на Windows с ускорением на AMD.

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

Для меня таким старым надёжным другом стала программа TreePad Lite. Она со мной уже без малого 30 лет. Мне очень близок минимализм TreePad: простота интерфейса, отсутствие необходимости установки, нетребовательность к ресурсам, открытый формат файлов, отсутствие каких-либо зависимостей от сторонних библиотек и интернета.

Я - автор двух пакетов, входящих более-менее во все дистрибутивы Linux: sane-airscan и ipp-usb.

Кроме того, sane-airscan входит во все основные дистрибутивы BSD (FreeBSD, NetBSD и OpenBSD) и в ChromeOS. ipp-usb в ChromeOS не взяли потому, что он написан на Go, а у них там очень жестко с размером исполняемых файлов, вместо этого они написали свое на Rust, но предпочли бы взять моё изделие, если бы могли. Совсем недавно появился порт ipp-usb на FreeBSD, вероятно, другие BSD тоже скоро подтянутся.

Вместе эти два пакета образуют стек "бездрайверного" сканирования документов для Linux и *BSD, а в перспективе нескольких лет, когда старые сканеры, наконец, вымрут, вероятно других драйверов и не останется.

Кроме того, ipp-usb делает возможным "бездрайверную" печать на USB-устройствах.

Здесь я хочу рассказать, каково оно, быть автором популярных OpenSource пакетов. Хоть эта работа и не принесла мне особых денег (на что я, впрочем, особо и не рассчитывал), она принесла мне бесценный опыт.

В целом, я полагаю, продвижение OpenSource пакетов структурно близко к продвижению на рынок программных продуктов. Занимаясь этой деятельностью, очень хорошо начинаешь понимать разницу между (1) написать программу, которая работает для меня (2) написать программу, которую можно назвать продуктом (3) вывести продукт на рынок.

Первое занимает гораздо меньше времени, чем второе. Второе - гораздо меньше времени, чем третье.

Привет, Хабр! Меня зовут Дмитрий Луцив, я работаю в СПбГУ на кафедре системного программирования, веду ряд IT-дисциплин на математико-механическом факультете в лабаратории компании YADRO и помогаю вузам актуализировать образовательные программы под задачи индустрии.

Я давно не программировал на С++, но стараюсь не отставать от изменений, происходящих в языке. Книга «C++ 20 в деталях» заинтересовала меня личностью автора (на секунду, это Райнер Гримм) и возможностью познакомиться с новым источником знаний о «плюсах». Решил ее прочитать, чтобы понять, кому материал будет полезен и могу ли я его рекомендовать. Под катом расскажу, что в книге хорошего, а что можно было бы сделать лучше, а также дам список дополнительных источников для специалистов разного уровня.

В свободное время я восстанавливаю старенькую, но довольно известную игру Pharaoh. Это ситибилдер, выпущенный в прошлом веке и разработанный Impressions Games. Технология рендеринга в этой игре была значительным достижением для своего времени и способствовала созданию впечатляющей атмосферы Древнего Египта, которая погружает игрока в проработанное окружение, удивляет вниманием к мелким деталям и передает богатство и разнообразие древнеегипетских пейзажей. В этой статье я опишу алгоритм отрисовки города, зданий, объектов, анимации и формат карты оригинальной игры.

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

Современные веб-приложения, даже простые на вид, часто подразумевают нетривиальную архитектуру, состоящую из многих компонент. В статье «Делаем современное веб-приложение с нуля» я рассказал, как она может выглядеть, и собрал для демонстрации простейшую реализацию на стеке из нескольких популярных технологий. В неё вошёл бэкенд, фронтенд, воркер для асинхронных задач и аж два хранилища данных — MongoDB как основная база и Redis как очередь задач. В «Делаем поиск в веб-приложении с нуля» я показал, как можно добавить полнотекстовый поиск, и подключил третье хранилище — Elasticsearch.

Всё это время для простоты разработки и отладки компоненты приложения запускались локально через Docker Compose. Но как развернуть такое приложение в настоящем продакшн-окружении? Как обеспечить горизонтальное масштабирование? Как раскатывать новые релизы без простоя? 

В этой статье мы разберёмся, как разворачивать многокомпонентное веб-приложение в кластере Kubernetes на примере его локальной реализации — minikube. Мы поднимем виртуальный кластер прямо на рабочем ноутбуке, разберёмся с основными сущностями Kubernetes, запустим и соединим между собой компоненты демо-приложения и обсудим, какие ещё возможности Kubernetes пригодятся нам в суровом энтерпрайзе. Если вы занимаетесь разработкой и слышали о Kubernetes, но ещё не имели возможности пощупать его руками — добро пожаловать под кат!

Откройте любую статью с обзором HTTP/1.1. Скорее всего, там найдётся хотя бы один пример запроса и ответа, допустим, такие:

GET / HTTP/1.1
Host: localhost

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Content-Length: 38
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
<h1>Привет!</h1>

Теперь откройте статью с обзором HTTP/2 или HTTP/3. Вы узнаете о мультиплексировании запросов, о сжатии заголовков, о поддержке push-технологий, но вряд ли увидите хоть одно конкретное сообщение. Ясно, почему так: HTTP/1.1 — текстовый протокол, тогда как сиквелы к нему бинарные. Это очевидное изменение открывает дорогу ко множеству оптимизаций, но упраздняет возможность просто и доступно записать сообщения.

Поэтому в этой статье предлагаю покопаться в кишках у HTTP/2: разобрать алгоритмы установки соединения, формат кадров, примеры взаимодействия клиента с сервером.

Как для мобильных разработчиков менялся Android с 2014 года и до сегодняшнего дня? Казалось бы, можно просто открыть официальное описание каждой версии и узнать. Но интереснее не просто читать сухие чейнджлоги, а вместе вспомнить все и из отдельных фактов сделать общие выводы. 

В июне я выступил с докладом об этом на конференции Mobius, а теперь для аудитории Хабра публикую его текстовую версию. Если есть что добавить — пишите в комментариях!

Работая в компании Gaijin несколько лет назад, мне довелось поучаствовать в портировании пары игр компании на консоль Nintendo Switch, тогда вовсю завоевывающую новые рынки. Для меня это стало первым крупным проектом на этой платформе. А с учетом, что ни команда, ни разработчик движка с платформой, системой сборки и вообще экосистемой Нинтендо знакомы не были, то все грабли приходилось искать и бережно на них наступать. Чтобы опробовать возможности новой платформы, параллельно с портированием игры, был написан внутренний middleware (связка dagor engine + nxsdk + jam) и код обрастал всевозможными тестами, build matrix, бенчмарками, прогоном стабильности и другими внутренними проверками. Надо отметить что на момент 2018 года, в самом switch sdk не было реализовано часть posix функций вроде poll и send/receive, и большая часть функций для работы с файлами, posix прослойку нужно было писать самим. Дошли тогда руки и до написания различных бенчмарков для функций стандартной библиотеки, и были замечены некоторые аномалии в поведении части тригонометрических функций в различных режимах сборки. Для справки, sdk использует урезанный вариант musl libc (https://www.musl-libc.org/), все статически линкуется в один большой бинарник clang'ом от Нинтендо 9 версии (2018 год), который потом запускается на консоли. Доступа к исходникам самой libc в исполнении Нинтендо у нас не было, но всегда можно посмотреть дизасм и боле менее представить что происходит.