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

Команда Spring АйО перевела статью, в которой приведено несколько правил, которые следует учитывать при написании микробенчмарков для HotSpot JVM.

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

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

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

В этой статье я хочу поделиться своим опытом использования не‑яблочного ноутбука в мире, где каждый второй айтишник считает своим долгом выложить фотографию своего рабочего места с MacBook и кружкой с лавандовым рафом. Это не попытка доказать, что «макбук плох» или, тем более, что стоит брать HP Victus (не стоит), а мой личный путь с железом, которое сопровождало меня в пути от обычного студента до уже смешарика и винтика в корпоративной машинерии. Можно сказать, история жизни и страданий с HP Victus.

Рассмотрим следующий сценарий:

template<typename T>
struct Base
{
// Есть конструктор по умолчанию
Base() = default;

// Некопируемый
Base(Base const &) = delete;
};

template<typename T>
struct Derived : Base<T>
{
Derived() = default;
Derived(Derived const& d) : Base<T>(d) {}
};
// Это assertion выполняется?
static_assert(
std::is_copy_constructible_v<Derived<int>>);

Почему выполняется это assertion? Очевидно, что скопировать Derived<int> нельзя, ведь при этом мы попытаемся скопировать некопируемый Base<int>. И в самом деле, если попробовать скопировать его, то мы получим ошибку.

Надругательство над C#, C++ и HLSL, игрища с булками и буферами, тройная полиглотность, SIMD, пепекторы, DirectX, экономия 800 Тб ОЗУ, новая парадигма программирования, многопроцессность, быстрая степень и многое другое.

В этой части я расскажу, как делал софт на собственном фреймворке, который управляет ядерной подсветкой и механической видеостеной.

Или почему найти работу в 2025 году стало практически невозможно.

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

Но сейчас всё по-другому

Всех хабровцев с началом лета! С вами Иван Клюев, я занимаюсь организацией и продвижением соревнований по программированию в России. Сегодняшний пост — репортаж о том, как сборные команды регионов боролись за Кубок России от Федерации Спортивного Программирования. Члены команд, занявших первые 3 места в своих дисциплинах, получили звания КМС (Кандидатов в Мастера спорта России).

7 советов для начинающих программистов

Заметил? Многие, кто только начал изучать программирование, сразу ныряют в сложные штуки и пытаются прыгнуть выше головы.

Я через это проходил.

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

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

В этой статье я расскажу, как всего за один вечер создал полноценный адаптивный SPA-сайт на Next.js без единой строчки кода — используя только AI и текстовые промпты.

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

Если вы думаете, что для создания SPA обязательно нужна кастомная разработка — эта история покажет, как современные AI-инструменты могут значительно упростить и ускорить процесс.

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

Всем привет!

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

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

Меня зовут Александр Певзнер, и я программирую на Си и 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).