Программирование *

Здравствуйте,

Меня зовут Александр Певзнер, и я программирую на Си и Go. Go обычно ассоциируется с бакендом, микросервисами и вот этим вот всем. Но я использую его необычным образом: я пишу на нём системное ПО.

Почему я это делаю именно на Go? Этот язык привлекает меня своей простотой, лаконичностью, ясной семантикой, прекрасной документацией и великолепной стандартной библиотекой.

Одна из моих программ, ipp-usb, написанная на Go, входит во все дистрибутивы Linux и *BSD и делает возможным использование принтеров и сканеров, которые подключаются к USB и поддерживают IPP over USB протокол - т.е., примерно всех современных.

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

Это всё начиналось для меня, как хобби, но сейчас это - часть моей оплачиваемой работы.

В силу особенностей моей работы меня не очень интересуют такие вещи, как поддержка миллиона запросов в секунду и прочий high load (это не значит, что мои программы тормозные. Но никто не дёргает системный принтер миллион раз в секунду). Но зато приходится разбираться с некоторыми другими непростыми штуками.

Об одной из таких штук и пойдёт речь в этой статье.

Понадобился мне для одного проекта на Go встроенный скриптинг. Ну т.е., чтобы программа могла всосать в себя скрипт, который определяет некоторые аспекты её поведения.

Размышляя о том, на каком языке программа должна скриптоваться, в выбирал между JS, Lua и Python.

Однако, JS и Lua - слишком нишевые языки. JS ассоциируется у всех с вебом а Lua - с разработкой игр. Таким образом, выбор естественным образом пал на Python. Этот язык знают все, а я испытываю некоторую надежду, что скрипты для моей программы буду писать не только я. Хотя сам я, должен признаться, Python не знаю и не люблю :)

Таким образом, осталось только придумать, как встроить интерпретатор Python-а в программу на Go.

Я постарался охватить только основы, но текст всё равно получился очень длинным.

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

Меня многие спрашивали, как им пользоваться, но здесь интереснее то, как вообще может прийти в голову мысль писать скрипты на C++ — не слишком ли сложно это будет? Оказывается, нет, не очень. Вот уже несколько лет я пишу на C++ скрипты для одной большой и одной не очень большой игры, и меня почти не посещало ощущение, что виной каким-то возникающим при этом проблемам являются язык C++ или связанные с ним скриптовые API. Я много лет программирую на Lua, а до этого пользовался обычным C. Но сейчас современный идиоматический C++ — то, что мне нужно. Причём, я могу писать на этом языке как в самом игровом движке, так и за его пределами, при этом опираясь (буквально) на одни и те же абстракции и оперируя одинаковыми структурами данных. Наконец, C++ просто очень мощный. Правда, я признаю, что о вкусах не спорят, и при работе с C++ также не обойтись без компромиссов.

Этот роадмэп мы начали собирать ещё в прошлом году вместе с нашей командой мидл-бэкендеров. Хотелось системно оформить весь стек технологий, с которым реально работает современный backend-разработчик на Python — от базовых тем вроде HTTP и SQL до CI/CD, микросервисной архитектуры, Kubernetes, облаков, безопасности и брокеров сообщений.

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

Работа без логов, это как вождение автомобиля вслепую. Ехать можно, но недолго и не туда.

Почти в каждом проекте логи нужны. И нужны инструменты, которые умеют с ними работать. А с этим исторически у нас была проблема.

В облаке Amvera, проекты пользователей, в большинстве своём, небольшие. А инструменты на рынке, такие как Elasticsearch очень требовательны к выделяемым ресурсам и сложны в настройке.

Странно поднимать телеграм-бота, который потребляет 100 мб. оперативной памяти и ставить для его логов Elastic на 16 Гб.

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

Всем привет! Меня зовут Александр Кулик, я .NET-разработчик из проекта шопинга в Т-Банке. Занимаюсь бэкенд-разработкой по интеграции и адаптации данных от наших партнеров и внешних сервисов, а также созданием собственных разработок в области платежных операций для B2B-сферы.

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

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

В последнее время часто звучат мрачные прогнозы (и даже скрытая реклама) о том, что крупные языковые модели (LLM) уничтожат программирование как профессию. Многие обсуждения лишены нюансов, поэтому я хотел бы внести свои пояснения. С одной стороны звучат заявления вроде: «Я использовал $LLM_SERVICE_PROVIDER, чтобы создать маленькую временную программу, и скоро все программисты останутся без работы за $ARBITRARY_TIME_WINDOW». С другой – категорический отказ признавать какую-либо пользу таких инструментов. Думаю, лучше всего прояснить эту ситуацию можно на примере другой отрасли, где подобные технологии появились раньше: перевод.

В прошлой главе мы перенесли A* на F#, после чего в образовательных целях занялись выдёргиванием его «кишок» наружу. Тогда процесс «потрошения» не был завершён до конца, но сегодня мы его добьём. Что касается метагейма, то мы продолжим путь от функции к конструктору и даже успеем слегка залезть на «ту сторону».

В декабре 2024 года я сел за написание дипломного проекта. Хотелось сделать не просто формальность для зачёта, а что-то реально рабочее, полезное и интересное. Так родилась идея RuFA Станции — по сути, «говорящей банки» с пинами, через которую можно было управлять внешними устройствами. Представьте себе что-то вроде умной колонки, которой можно сказать: «RuFA, подай 5V на пин 13», — и она выполнит.

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

«Слушай, ну это... идея так себе. Ты можешь лучше».

Каждый разработчик рано или поздно сталкивается с вопросом: как организовать проект так, чтобы он не превратился в хаос? Или как исправить проект, в котором уже царит хаос?

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

В этот момент мы начинаем задаваться вопросом: «а как нужно писать и организовывать код на самом деле?». В поисках ответа мы читаем статьи, смотрим обучающие видео, доклады и неизбежно натыкаемся на Feature‑Sliced Design (FSD).

Привет Habr!

Я уже начинал предыдущую свою статью Yast Another Config Manipulation или зачем изобретать велосипед? словами благодарности книге Натальи Самойленко Python для сетевых инженеров

Начну и эту. Если вы сетевой инженер и не знакомы с Python — начните с этой книги!
А еще помочь вам может моя библиотека Astarmiko — это продвинутый Python‑инструментарий для управления и автоматизации корпоративной сетевой инфраструктуры через SSH который родился при пошаговом выполнении заданий из книги.

Так как в моем распоряжении была вся корпоративная сеть (нашего филиала), мне быстро наскучило играть в «песочнице».

В современном обучении программированию, как правило, основное внимание уделяется парадигме объектно-ориентированного программирования (OOP) и вытекающей из неё методологии объектно-ориентированного проектирования (OOD). Определённый ренессанс в наше время испытывает парадигма функционального программирования, но практически никогда в связке с ней не рассматривается функциональное проектирование. Попытаемся осветить наше видение этих вопросов.

Если вы работаете с Keycloak и сталкивались с необходимостью интеграции внешних пользовательских данных — этот материал для вас.

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

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

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

Всем привет!

Меня зовут Илья, я работаю в Райффайзен Банке. Мы пишем свои бэкенд-сервисы на Java и Kotlin, поэтому зачастую приходится переключаться с одного языка на другой. Из-за этого невольно начинаешь сравнивать подходы и механизмы одного языка с его JVM-собратом. Сегодня я бы хотел поговорить об одном из таких механизмов — пропагации ошибок и исключений.

Используете ли вы в своем коде исключения? Ответ кажется странным, так как исключения являются неотъемлемой частью Java. Но что, если я спрошу, используете ли вы исключения для управления логикой своей программы?

Автор статьи Modern SAT solvers: fast, neat and underused утверждает, что SAT-солверы «преступно мало используются в нашей отрасли». [SAT — Boolean SATisfiability Solver, то есть солвер, способный находить присвоения, делающие истинными сложные булевы выражения. Более подробно я писал о них ранее.] Какое-то время назад я задался вопросом, почему: как получилось, что они настолько мощны, но ими никто не пользуется? Многие специалисты заявили, что причина в неудобстве кодирования SAT: они лучше предпочтут работать с инструментами, которые выполняют компиляцию в SAT.

Я вспомнил об этом, когда прочитал пост Райана Бергера о решении «задачи ферзей с LinkedIn» как задачи SAT.

Вкратце опишу задачу про ферзей (Queens). У нас есть сетка NxN, разделённая на N областей, и нам нужно разместить N ферзей так, чтобы в каждом столбце, строке и области находился ровно один. Ферзи могут находиться на одной диагонали, но не соседствовать по диагонали.

Сначала я недооценил document.currentScript, но оказалось, что он отлично подходит для передачи параметров конфигурации прямо в теги <script> — и это далеко не все.

Порой я натыкаюсь на давно существующие браузерные API в JavaScript, о которых, по идее, я должен был узнать гораздо раньше. Например, window.screen или метод CSS.supports(). К счастью, я понял, что не один такой. Помню, как однажды упомянул window.screen в посте и получил неожиданно много комментариев от людей, которые тоже впервые о нем слышали. Это меня немного приободрило — я почувствовал себя не таким уж глупым.

Видимо, дело не в том, как давно существует API, а в том, насколько он полезен в реальных задачах. Если window.screen почти нигде не используется, о нем легко забыть.

Но иногда все же появляется неожиданный шанс применить одну из этих малоизвестных возможностей. Похоже, я как раз нашел такой случай для document.currentScript — и намерен использовать его по максимуму.

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

Статья будет интересна фронтенд‑разработчикам. Из неё вы узнаете, как создать универсальное ядро для веба и натива, получить вместо запутанных асинхронных вызовов чёткие последовательности действий и убрать визуальные артефакты при одновременных пользовательских действиях.

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

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

В этой заметка я представил свой алгоритм определения пересечений интервалов и его разбор.

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

Думаю, если не всем, то многим знакома ситуация, когда рабочие задачи висят, а заставить себя сесть за них, сосредоточиться и сделать очень трудно: то задачи кажутся неинтересными, то общая усталость и выгорание сказывается. Как однажды сказал мой знакомый, который работает видеографом: «волны нет, а г..но делать я не хочу». Ну, видеографы — люди совсем творческие и у них нет таких четких дедлайнов как у нас, программистов, во всяком случае, у моего знакомого точно их не было, так что мог себе позволить ждать вдохновения.

Надеюсь, в этом тексте вы сможете найти для себя что‑то полезное при организации своего нескучного рабочего процесса:‑)

Еще давно я определил для себя, что мне нужно разнообразие в повседневной деятельности, иначе я очень быстро начинаю скучать и страдать от приступов кризиса среднего возраста. Также я понял, что меня вдохновляют инструменты («когда в руках молоток — все вокруг кажется гвоздями» — это про меня). Далее я расскажу мой путь, по которому я постепенно шел, ища подходящие инструменты для вдохновения и куда я в конечном итоге пришел и нахожусь в этом состоянии уже 3 года и пока мне все нравится.

Компания Trail of Bits уже несколько лет сотрудничает с репозиторием PyPI, помогая добавлять в проект новые возможности и улучшать стандартные параметры безопасности в экосистеме управления пакетами Python.