Всем привет. Меня зовут Виктор Степанов, я 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 обычно остаётся стабильным и только иногда дополняется новыми деталями. Но как его правильно и быстро сделать?
На прошлой неделе в Софии, столице Болгарии, закончилась работа над стандартом C++26, который помимо контрактов, std::execution и всего прочего теперь включает и рефлексию.
В этой статье будет продемонстрирован один из примеров её использования: преобразование строк в формате JSON в объекты C++ на этапе компиляции.
В новом переводе от команды Spring АйО подробно разбираются концептуальные, методологические и технические ошибки, на которые легко наткнуться при попытке протестировать такие механизмы, как synchronized и ReentrantLock. Автор объясняет, почему микробенчмарки часто измеряют не то, что вы думаете, и почему для получения осмысленных результатов лучше использовать макротесты или полагаться на экспертов.
HTML Builder — визуальный конструктор HTML-структур с drag-and-drop интерфейсом для библиотеки @vue-dnd-kit/components!
🔹 HTML Builder позволяет создавать HTML-структуры без написания кода
🔹 Включает рабочую область, палитру компонентов, дерево элементов и панель настроек
🔹 Сейчас это ранняя бета с минимальным функционалом, но уже можно оценить концепцию
Идеально подходит для создания прототипов и визуальных редакторов CMS.
🔗 Демо: https://zizigy.github.io/html-builder/
🔗 GitHub: https://github.com/ZiZIGY/html-builder
Ищу обратную связь по UI/UX и функциональности. Какие фичи хотели бы видеть? Что можно улучшить в интерфейсе? И тд тп.
Намедни в своём канале я решил сделать эксперимент, получится ли почти с нулевым бюджетом сделать простой ИИ-сервис обёртку на трендовую тему, и чтобы это было за 4-7 дней.
В итоге мне скинули пару залетевших рилсов, где авторы стали пробовать смотреть физиогномику через GPT, хотя результаты у них там даже для ненаучной методики были так себе.
В итоге мы с партнёром решили быстро сделать такого ИИ-бота (соотносит черты лица и характер, ненаучно, развлекательный контент), который анализирует вероятный характер пользователя, как его воспринимают другие и так далее. Посмотреть его можно тут, он бесплатный на 1-2 раза.
Примерно в 2012-2013 году в сообществе сисадминов стали много говорить о технологии под названием «Borg». Складывалось впечатление, что это какая-то система управления контейнерами, основанная на Linux и применяемая в Google — с её помощью они эксплуатируют свои внутренние ресурсы. Терминология по этой системе немного озадачивала; внутри кластеров, состоящих из «ячеек» (cells), в ней находились какие-то «борглеты», но суть уже на данном этапе начинала ускользать. В системе существовали концепции «сервисов» (services) и «заданий» (jobs), так, что приложения могли при помощи сервисов откликаться на пользовательские запросы, после чего система собирала задания в пакеты, и эти пакетные задания уже выполнялись достаточно долго.
Затем 7-го июня 2014 года состоялся первый коммит в Kubernetes. Это греческое слово означает «кормчий», и в течение первых трёх лет существования этой технологии решительно никто не понимал, как его правильно произносить. Поэтому пришлось сдаться и позволить простым смертным обозначать его как k8s.
Как вы, наверно, знаете, из-за наличия в компьютере различных кэшей (L1, L2, L3...) и того, что операции с памятью выполняются с линиями кэша размером примерно 64 байт каждая, для обеспечения максимальной производительности мы должны писать программы, обеспечивающие локальность.
(Разумеется, диск здесь не показан)
Но насколько хорошо вы это осознаёте? Допустим, у нас есть массив чисел с плавающей запятой и массив индексов первого массива. Есть программа, складывающая числа из первого массива в порядке, определяемом вторым массивом. То есть в этом примере мы будем складывать ε + α + δ + ζ + β + γ в таком порядке:
Давайте рассмотрим всего два случая: индексы идут в порядке от первого до последнего или в произвольном порядке. До того, как я начал писать этот пост, я не мог ответить ни на один из следующих вопросов:
1. Насколько большим должен быть массив, чтобы разница производительности вычисления в двух порядках стала заметной?
2. Сколько в среднем тратится на каждый элемент в порядке от первого до последнего?
3. Насколько медленнее произвольный порядок последовательного в случае массивов, умещающихся в RAM?
4. Насколько медленнее произвольный порядок последовательного в случае массивов, не умещающихся в RAM?
5. Достаточно ли стандартного тасования Фишера-Йейтса для массивов перемешанных индексов для получения произвольного порядка?
6. Насколько медленнее порядок от первого до последнего в случае массивов, не умещающихся в RAM, при использовании файлов с отображением в память?
7. Максимально ли быстры файлы с отображением в память?
Если вы уже знаете ответы на эти вопросы, то это замечательно! Если же нет, то делайте ваши предположения и проверьте их, прочитав пост.
Команда Rust рада сообщить о новой версии языка — 1.88.0. Rust — это язык программирования, позволяющий каждому создавать надёжное и эффективное программное обеспечение.
Если у вас есть предыдущая версия Rust, установленная через rustup, то для обновления до версии 1.88.0 вам достаточно выполнить команду:
$ rustup update stableЕсли у вас ещё не установлен rustup, вы можете установить его с соответствующей страницы нашего веб-сайта, а также посмотреть подробные примечания к выпуску на GitHub.
Если вы хотите помочь нам протестировать будущие выпуски, вы можете использовать канал beta (rustup default beta) или nightly (rustup default nightly). Пожалуйста, сообщайте обо всех встреченных вами ошибках.
Люди с самых древних времён интересовались тремя главными вопросами мироздания: почему горит огонь, какой формы земля и мёртв ли Хабр. На последний я постараюсь ответить. И если коротко - я понятия не имею. Быстрый сбор статистики и интерпретация результатов растянулась в несколько раз, ведь чем дальше тем становится всё больше и больше вопросов. А искать ответы - вообще и близко не моё любимое занятие, поэтому все данные будут опубликованы для открытого доступа и возможно кто-то сможет уменьшить количество этих чертовски важных вопросов.
Привет, Хабр! У каждого JS-разработчика есть своя история. История о том, как он впервые встретился с этим. Сидишь, пишешь код, всё логично, всё под контролем. И тут, чтобы проверить одну мелочь, открываешь консоль и из чистого любопытства пишешь:
[] + {} // Получаешь: "[object Object]"
// Хм, ладно, массив привел себя к строке, а объект стал... объектом. Логично.{} + [] // Получаешь... 0 ???
// ЧТО?!
Стоп. Как это вообще возможно? Мы только что поменяли местами два операнда и получили совершенно другой тип данных. Кажется, будто язык издевается над нами.
Нет, речь не про кэш в памяти. Так было бы слишком просто. У нас сегодня будет препарирован ORM, который честно запрашивает данные у реляционной СУБД, маппит в объекты, подключает связи и отдаёт в логику приложения в виде объектов. И всё на порядки быстрее, чем прямой запрос из кода приложения.
Да, здесь есть нюанс. Об этом нюансе, а также о том, зачем я написал в пятый раз кастомный ORM и будет эта статья. Эта разработка тесно переплетена с моей личной историей, когда я переходил с одной работы на другую, а затем был уволен. Я не хочу оставлять сухой технический текст, поэтому эта статья будет скорее рассказом моей работе в этой компании.
Код в статью я старался включать по минимуму. Он точно не полный и возможно ошибочный, потому что дорабатывался по мере написания статьи. Полный и исправленный вариант будет доступен по ссылке в конце статьи.