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

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

Для себя и, надеюсь, кого-то ещё, я предлагаю эти три разбора, на мой взгляд, основополагающих статей мира ML. Приятного прочтения.

Привет, Хабр! Я Иван Попов, ведущий инженер ЦК платформенных и интеграционных решений РСХБ-Интех. Java — мой самый любимый язык программирования, я всю жизнь работал только на нём. Сейчас я работаю в банке и хочу разрушить стереотип  о том, что в банках все работают на Vegas. На java мы очень много работаем, тем более если видим, что новая технология позволяет нам оптимизировать процессы разработки (а количество интеграций огромное). 

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

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

BEIR — это бенчмарки поиска информации, ориентированные на сценарии использования в формате «вопрос-ответ».

Мой хобби-проект SearchArray добавляет в Pandas полнотекстовый поиск. Поэтому естественно, чтобы ощутить трепет от моих потрясающих навыков разработчика, я решил использовать BEIR для сравнения SearchArray с Elasticsearch (с тем же запросом + токенизацией). Поэтому я потратил субботу на интеграцию SearchArray в BEIR и измерение релевантности и производительности с корпусом MSMarco Passage Retrieval (8 миллионов документов).

Барабанная дробь...

Этой весной, с 8 апреля по 23 мая, Хабр совместно с GitVerse запустил сезон Open source. Идея была простой: предложить IT-сообществу поделиться своими историями работы с открытым кодом. 

За время сезона было опубликовано 80 статей, которые в совокупности набрали около полумиллиона просмотров, 2000 плюсов и 1500 комментариев. Авторы делились опытом — от первых робких коммитов в популярные репозитории до создания собственных проектов, изменивших жизнь тысяч разработчиков. А читатели, в свою очередь, поддерживали, хвалили, критиковали и даже рассказывали, как тот или иной проект изменил их работу или жизнь.

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

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

Концепция этого цикла начиналась с простого переноса тайловых миров на F#. Однако в процессе его описания я основательно растёкся по древу, за счёт чего у нас образовался большой подготовительный этап из пяти глав про языковые фичи и прочую «фундаменталочку». Думаю, что с подготовкой закончено, поэтому сегодня мы обратимся непосредственно к тайловым мирам.

Но начнём мы практически с конца — с адаптации поиска пути. Это несложная задачка, но в процессе её решения мы успеем закрепить пройденный материал и по инерции заскочить в новый.

Всем привет!

В этой статье мы будем обсуждать, как писать масштабируемые и поддерживаемые интерфейсы на Jetpack Compose: от базовых компонентов до архитектурных практик. Разбираем иерархию, принципы проектирования, naming, порядок параметров и антипаттерны.

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

Всем привет! В статье расскажу, как я написал игру Дебаггер на Python и добавил к ней графический интерфейс на Tkinter. Мне хотелось сделать простую игру на IT тематику, поэтому я скопировал игровую механику из игры Сапер и теперь нам нужно отметить все баги на игровом поле или наш код сломается.

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

Наступил Steam Next Fest 2025 — нам стало доступно 2500 (!) демок игр, которые выйдут в релиз уже в этом году!

Из них под тег programming выставлен только у 18. Давайте посмотрим на каждую из них!

для бизнеса, разработки и другой работы

По моему практическому рабочему опыту, вот так:

Claude 4
* Sonnet => лучше всех пишет код, идеально держит контекст. Отлично пишет тексты и шутит. Подходит для создания ИИ-бота.
* Opus => неоправданно дорогой, всего на 20% лучше Sonnet.
Контекст — до 200 тыс. токенов.

Gemini-2.5
* Pro => вторая по силе написания кода. Хорошо подходит для архитектуры приложений, может быть тебе “другом”. Слабо пишет тексты.
* Flash => всё то же, но на 40% хуже, зато одна из самых быстрых моделей. Подходит для ИИ-звонаря.
Контекст — до 1 млн токенов.

GPT-4

* 4.5 => очень хорошо пишет тексты, креативен, но шутит хуже Claude. Очень человечный и эмпатичный.
* 4.1 => отлично структурирует посты, очень логичен, неплохо пишет код. Идеально держит промпт — хорошо подходит для ИИ-ботов.
* 4.1 mini / nano => если нужна оптимизация цены общения для ИИ-бота или простые задачи (например, определение темы диалога, саммари и др.). Работают заметно быстрее обычного 4.1.
* 4o => хорош тем, что видит/создаёт картинки.
Контекст — до 1 млн токенов.

GPT-o
* o3 => подходит для сложных логических задач, планирования архитектуры приложений (хотя мне Gemini нравится больше), отлично для аналитики.
* o4-mini => если нужно быстро что-то посчитать математически.
* o4-mini-high => подходит для написания кода, но уступает Gemini и Claude. Зато лучше чем gpt-4o работает с картинками.
Контекст — до 200 тыс. токенов.

Deepseek
* R1 => устарел, но по-прежнему самая дешёвая “размышляющая” модель. Хорош для аналитики, например звонков. Можно развернуть на своём сервере.
* V3 => на уровне 4.1 mini, только дешевле. Также можно использовать для ИИ-ботов, разворачивать у себя на сервере/облаке.
Контекст — до 64 тыс. токенов.

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

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

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

Финансовое моделирование — это не просто таблички. Это способ прогнозировать, принимать решения и быть на шаг впереди. Мы, финансисты, любим Excel за простоту, в то же время, ненависть к этому чудесному инструменту возрастает пропорционально количеству переменных в формулах. И, когда задач становится больше, — он начинает тормозить и сильно раздражать.

Ниже я расскажу:

- Почему я, как гуманитарий, начала осваивать Python.
- Как связка Excel + Python работает на практике.
- Как один и тот же проект ведёт себя в этих двух мирах.

Привет, Хабр! Меня зовут Владимир Раду, я Backend-разработчик в Рунити. Однажды мы с командой встали перед дилеммой: как навести порядок внутри монолита. Админка одного из сайтов нашей группы компаний — большой и довольно возрастной проект. Он охватывает множество задач и сценариев: от управления ценами до редактирования контента. Со временем стало очевидно, что нужно снижать связанность компонентов и разводить бизнес-части. Так появилась идея перейти к модульной архитектуре.

Внутри о том, что у нас получилось из рефакторинга легаси, как мы выстраивали работу с модулями и объединяли в логичную структуру разрозненные части системы. Будет полезно разработчикам, которые работают с легаси и хотят встать на путь оптимизации проекта — без переписывания с нуля.

Я считаю, что при работе с Go в контексте нашей отрасли внедрение зависимостей (dependency injection, DI) часто имеет плохую репутацию из-за DI-фреймворков. Но сама по себе DI как техника довольно полезна. Просто её объясняют слишком большим количеством ОО-жаргона, что приводит к ПТСР у тех, кто перешёл на Go, чтобы сбежать из культа банды четырёх.

Знаю, что тема уже изъезжана вдоль и поперек, но я хотел бы поделиться своим видением Open/Close Principle из всеми любимым SOLID подходу к построении архитектуры софта. Ведь дядюшка Боб херни не посоветует, все таки опыта ему не занимать, поскольку он с 70х годов в разработке и знает базу, что нам и нужно. Да современный софт ушел далеко от того какой он был в 70-х, когда писали логические цепочек на перфокартах, делая дырки в картоне и компиляция занимала прямо прапорционально количеству этих самы карточек, где скорость выполнения считалась количеством символов в минуту. За все это время Дядюшка Боб собирал лучшие практики из которых и получились эти 5 принципов, которые помогут построить софт, который будет не так сильно с течением времени влиять на стоимость одной строки кода. (О чем он и пишет в своей книги «Чистая архитектура»).

Хочу отметить то, что есть мнение, что принципы SOLID — это про ООП и для языков, которые не следуют этой парадигме это не актуально, нет. Эти принципы построения архитектуры приложения не зависят от языка.

Если вы читали книгу «Чистая архитектуры» и дошли до Open/Close principle (SOLID) и из примера ничего не поняли, тогда вы пришли по адресу, поскольку я буду рассматривать именно этот пример. Для меня лично OCP это один из принципов, который заставляет продумывать архитектуру приложения, что очень важно.

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

Привет, Хабр! Статья будет посвящена любимому мной IaC. Чтобы ввести в курс дела, кратко расскажу про VMmanager и текущую реализацию продукта. Затронем варианты, как можно работать с VMmanager с подходом Infrastructure as Code, а основная часть — про развертывание платформы VMmanager и управление виртуальными машинами в ней с помощью Ansible.

В Java существует две реализации интерфейса List: ArrayList и LinkedList. Какая из них лучше? Как выбрать подходящую для вашего приложения? В данной статье мы сравним их различия, производительность и потребление памяти, чтобы помочь вам определиться с выбором.

Недавно я работал над достаточно большим проектом на Rust. К моему удивлению, мне никак не удавалось заставить тесты работать правильно.

Команда cargo test запускала выполнение всех тестов в репозитории, но спустя пару миллисекунд все тесты завершались сбоями из-за не очень знакомой мне ошибки:

Io(Os { code: 24, kind: Other, message: "Too many open files" })

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

Попробуем заглянуть в непосредственное будущее языков программирования, сред разработки и профессии в целом без попытки сглаживать углы