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

Недавно вышла отличная книга PostgreSQL Mistakes and How to Avoid Them от Jimmy Angelakos — системного архитектора, практика и давнего участника сообщества PostgreSQL. Книга подробно разбирает распространённые ошибки, с которыми сталкиваются разработчики и администраторы при работе с PostgreSQL, и предлагает практичные решения: от тонкостей конфигурации и миграции до антипаттернов в SQL и выбора типов данных.

Я перевёл одну из ключевых глав этой книги — про неправильное использование типов данных. В ней подробно объясняется, почему, например:

timestamp without time zone может ломать логику расчёта интервалов;

money — это не то, чем кажется (и почему он опасен);

char(n) и varchar(n) не дают ожидаемой экономии и даже вредны;

serial — это прошлый век, а identity — настоящее.

Глава будет полезна всем, кто работает с PostgreSQL в проде — особенно backend-разработчикам, независимо от языка и фреймворка. Если вы проектируете схемы БД, пишете SQL-запросы или просто хотите избежать неприятных грабель — стоит прочитать.

CLL в ISPA — переносимый язык семантических действий для генераторов парсеров. Объявление переменных, условий и циклов, генерация AST и кода на C++ без привязки к языку парсера. Пример, разбор и сравнение с ANTLR, Bison.

Привет, Flutter-разработчики! 👋

Я автор телеграм-канал FlutterPulse! Месяц выдался жарким — и не только из-за погоды ☀️ Мы запустили новую рубрику, пересобрали формат пакетов и собрали для вас крутую подборку новостей, гайдов и видео. Поехали! 👇

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

Мне очень нравится знаменитая цитата Ричарда Фейнмана:

«То, что я не могу создать, я не понимаю»

Она кажется мне великолепной, и я считаю, что она справедлива для многих областей знания (если немного творчески подойти к значению слова «создать»). Наверно, этому принципу я обязан за всё, в чём по-настоящему хорош. Кто-то скажет, что стоит стараться не изобретать велосипед, но они ошибаются: нужно изобретать собственный велосипед, потому что так вы узнаете о его устройстве больше, чем после прочтения тысячи книг.

Сегодня, в 2025 году, красота и ремесло написания ПО подвергаются разрушению. ИИ угрожает тем, что заменит нас (или, по крайней мере, заберёт все самые приятные аспекты нашего ремесла), а разработка ПО становится всё более стандартизированной, выверенной, упакованной и индустриализированной. Разработке программного обеспечения нужно больше простых удовольствий. Я выяснил, что создание хобби-программ — отличный способ снова напомнить себе, почему вообще я начал работать с компьютерами.

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

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

Меня зовут Екатерина Петрова, я автор медиа «вАЙТИ» и аналитик. Перечитывая свой любимый роман И. Ильфа и Е. Петрова «Двенадцать стульев», а именно сцену с архивариусом Коробейниковым, я вдруг поняла: его бумажный архив ордеров на имущество бывших дворян не что иное, как идеальный пример реляционной базы данных. Алфавитные указатели — это индексы, книги учета — таблицы с первичными ключами, ордера — настоящие транзакции.

Привет, Хабр!

Я не знаю, как у вас, а у меня перед глазами все еще маячат толстенные исходники WinForms-эра на C#, где любой порядочный объект, умеющий держать ручку к файлу или сокету, строго реализует IDisposable. Закрыл — молодец, забыл — получи warning от IDE и пару нехороших утечек в production.

В Python, увы-ях, аналогичный контракт традиционно строили на del и контекст-менеджерах. Первый: если объект в циклическом мусоре, финализатор может не вызваться вообще; к тому же при выключении интерпретатора порядок разрушения объектов хаотичен. Второй (with ... as) шикарен, но требует явного вызова, а значит — дисциплины.

С выходом PEP 442 и появлением weakref.finalize мы получили «почти IDisposable» — финализатор, которому не страшны циклы, и который честно отработает даже на shutdown, если правильно обращаться.

Я посвящу этой теме целый пост, потому что она «не помещается в окно Овертона»; чтобы люди хотя бы начали понимать, что я пытаюсь описать, мне обычно приходится показывать видео, которое я выложил под катом.

Всем привет. Меня зовут Виктор Степанов, я frontend chapter lead на платформе СберТеха GitVerse. Хочу рассказать про внутреннюю «механику» V8 и показать, как писать более быстрый код. Поехали!

В далёком 1951 году был опубликован роман Айзека Азимова «Основание». Он рассказывает о событиях ещё более далёкого 19 997 года: человечество освоило межзвёздные перелёты, превратилось в Галактическую Цивилизацию, изобрело научные методы психоистории для точного предсказания будущего и в итоге пришло к осознанию необходимости создания Галактической Энциклопедии — базы знаний, накопленных человечеством за многие тысячи лет своего существования. Цель энциклопедии — быть не просто справочником по типу Википедии, а практическим руководством, которое позволяет даже изолированной человеческой популяции пройти путь развития от каменного века до межзвёздных перелётов всего за несколько столетий.

По мнению Айзека Азимова, подобная глобальная база знаний является необходимым условием для фактического бессмертия человеческой цивилизации. В этом я с ним полностью согласен. Но я так и не дочитал книгу до конца, потому что довольно быстро основное внимание автора перешло от интересной научно-фантастической идеи к довольно банальным политическим интригам. Меня в первую очередь интересует техническая сторона «Основания» — как может быть устроена информационная система Галактической Энциклопедии сегодня? Исходя из возможностей современных технологий, за 17 972 года до суда над Гэри Селдоном, изгнания Энциклопедистов с Трантора на Терминус и старта полномасштабной работы над глобальной базой знаний человечества во вселенной Айзека Азимова.

Вмире стартапов назревает сдвиг: классический подход Minimum Viable Product (MVP) больше не гарантирует успеха. Если раньше пользователи были готовы мириться с сырыми прототипами, которые «просто работали», то в 2025 году планка качества поднялась так высоко, что одной лишь функциональности уже недостаточно. Современные пользователи ожидают продуманный и приятный UX с первого касания — продукт должен не только работать, но и вызывать восторг. Здесь на сцену выходит концепция Minimum Lovable Product (MLP): стратегия запуска, ориентированная на создание любимого продукта с первого дня. Разберёмся, почему MVP теряет актуальность, чем отличается MLP и как компаниям адаптироваться, чтобы завоёвывать сердца пользователей в 2025 году.

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

Прогресс вносит свои коррективы, и в разработке ПО появляется новая сущность — так называемый «искусственный интеллект». Что же это такое? Это точно не язык программирования и не фреймворк, но это уже и не инструмент (в привычном нам понимании). В то же время, это ещё далеко не полноценный коллега. Поэтому возникает потребность в осмыслении роли этой новой сущности, способов и целей её использования.

В этой статье, обобщив известный мне опыт, я предлагаю вниманию сообщества концепцию ПРОСТА. Данная концепция ставит своей целью описание роли искусственного интеллекта в процессе разработки программного обеспечения и состоит из шести принципов:

Промпт — первым приоритетом!
Разбор результата и рефлексия
Однозначность и определённость
Самостоятельность сотрудника
Творчество и тактика
Амбициозность апгрейда

Рассмотрим каждый из этих принципов подробнее.

Всем привет, 

Команда devhands.io сделала с Владимиром Перепелицей интервью, посвященное сравнению наиболее популярных решений в области очередей и брокеров сообщений — Kafka, RabbitMQ, NATS.

Владимир — эксперт по большим проектам, очередям и Tarantool, Solution Architect в Exness, создатель S3 в VK Cloud, регулярный спикер и член ПК конференций Highload. А мы, R&D-центр devhands.io, разрабатываем образовательные программы по хайлоаду, перформансу, архитектуре, базам данных и другим направлениям.

Под катом – расшифровка интервью.

Твит, который подтолкнул меня к реализации описанного в статье мини-проекта.

Взявшись за эту задачу, я около двух часов ваял небольшой скрипт, который будет скрейпить данные из базы крейтов Rust crates.io и анализировать их для выяснения, какие пакеты чаще скачиваются для работы (то есть в будние дни), а какие для развлечения (то есть в выходные).

Привет, Хабр!

Первый Java Rock Stars Meetup прошёл на ура (обзор первого митапа см. тут) и вы сказали, что хотели бы ещё. Ну, что ж, мы услышали, приняли и сделали.

В конце мая мы провели второй Java Rock Star Meetup при поддержке сообщества Spring АЙО в Москве на той же площадке Casa Picassa, только в соседнем лофте. В этот раз мы выбрали площадку с большей вместимостью, поскольку кол-во регистраций в этот раз было сильно выше (как и дошедших до локации участников), чему мы были несказанно рады!

Под катом — записи докладов, фото, видео и как это было.

Все шире звучат сообщения о процентах программного кода в компаниях, который был сгенерирован ИИ-ассистентом. Оценки этих сообщений сильно разнятся: от прогнозов о скором увольнении всех программистов до негативного отношения к сгенерированному программному коду. Как бы то ни было – ИИ-ассистент программиста существует и будет занимать свое повседневное место. Пока он не готов заменить человека, но свою пользу уже вносит. Эту пользу ощущают специалисты с опытом и могут правильно использовать как сгенерированные части, так и подсказки ИИ-ассистента.

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

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

Если вы решили вайбкодить новый проект, то самым первым шагом должен стать PRD (Product Requirements Document).

Что такое PRD?

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

После PRD хорошо бы сразу создать ещё два документа:

* tasks.md — детализация задач вашего проекта. Этот файл может меняться и дополняться в процессе работы: сделали текущие задачи → придумали новые → обновили файл.

* docs.md — более техническая документация, которая пишется параллельно реализации задач. Она не обязательна для маленьких проектов, поэтому подробнее о ней поговорим в следующем посте.
(md - это не домен, это файлы расширения Markdown)

Сам PRD обычно остаётся стабильным и только иногда дополняется новыми деталями. Но как его правильно и быстро сделать?