Разработка

${habrauser}, Привет!

Я — Старов Александр, сооснователь и главный разработчик в VOLT. В процессе создания собственной криптовалюты VOLT Coin (сейчас проводится аирдроп монеты, информацию можно найти на сайте volt-ink.com, поэтому можете присоединяться) мы столкнулись с достаточной нехваткой информации в интернете. Да, у Aptos зачётная документация, но некоторые моменты либо не указаны, либо неактуальны. Поэтому информацию пришлось собирать по кусочкам.

Для чего существуют принципы ACID? Можно ответить по бумажке, сказать, что это нужно для того, чтобы каждая транзакция обрабатывалась надежно, данные оставались в безопасности и системы работали предсказуемо.

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

В этой статье вы узнаете, почему так важны принципы ACID и что это за принципы. Оставайтесь со мной, если интересно!

Laravel завоевал авторитет у бизнеса и программистов за эффективность решения задач. Автор не раз встречал суждение среди коллег, что опыт разработки на Symfony и Laravel равнозначны. Это миф. Ниже — 7 ловушек Laravel и практичных решений без отказа от фреймворка.

Раньше у меня был сайт на Тильде. Стандартные шаблоны Тильды скучные, поэтому его делал дизайнер на zero-блоках. И каждый раз, когда надо было что-то на этом сайте добавить, приходилось дергать дизайнера в духе «Привет, добавь этот отзыв на сайт, пожалуйста».

Статьи добавлять поудобнее, но тоже не идеально. На том же Вордпрессе можно просто скопировать статью из гуглдока — и все, она вместе улетит вместе со всеми скриншотами. На Тильде надо тыкать каждую картинку руками, это бесит.

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

Стало интересно, а может ли Claude Code сделать сайт на Вордпрессе. С этим вопросом я к нему и пришел.

Claude сказал, что конечно может, но Вордпресс это скучно, и лучше делать сайт на Next.js + headless CMS. Я на тот момент даже не знал, что это такое. Ну так, слышал что на Next.js сайты делают — и все. Решил, что будет интересно разобраться и попробовать.

Спойлер — у нас (у меня и Claude Code) все получилось, сайт работает, мне нравится, даже трафик из SEO не просел.

Каждый маршрут ведет себя по-разному в зависимости от времени суток, загрузки сети, погоды (да, это влияет на спутниковые каналы) и других факторов. Традиционная маршрутизация выбирает путь на основе метрик BGP (AS Path, MED), но эти метрики не учитывают реальную задержку и джиттер.

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

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

Представление - Доктор физико-математических наук, профессор РАН, генеральный директор института Айри, декан факультета искусственного интеллекта МГУ Иван Оселедец с докладом «Успехи и проблемы больших языковых моделей».

Дальше говорит Оселедец.

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

Если переходить к докладу, то недавно вышло интервью Андрея Карпаты. Очень интересный, кто не видел, посмотрите. Полтора часа, и не суммаризация . Много интересных мыслей. Одна из мыслей, за которую я так зацепился, которая была не очень очевидна.

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

Привет! Меня зовут Николай Огоров, я Big Data-инженер в Авито. В этой статье я и мой коллега Айк Оганесян расскажем, как обеспечили пользователей инструментами, которые дают им возможность самим создавать витрины в хранилище Авито без привлечения специалистов. Эта история больше про подходы, решения и философию, которые позволяют жить в парадигме, когда потребностей на создание объектов DWH стало сильно больше, чем возможностей Data-инженеров.

Я работаю старшим фронтенд-разработчиком в it-отделе одного из крупнейших федеральных застройщиков. Специфика разработки в такой непрофильной компании — сроки спускаемые сверху и вообще не имеющие корреляции с реальными ресурсами и возможностями команды. Именно поэтому мы работаем очень быстро, постоянно пытаясь получить (максимум результата)*3 за (минимум времени)/4.

В этих условиях мы делали большие интеграции с headless CMS Directus и непосредственно с бекендом, используя моковые данные на фронте.
Интеграции были большие и быстрые — и вот тут-то и стало видно, что большинство фронтенд-разработчиков не очень понимают, как подготовить интеграцию, чтобы потом было быстро и не больно заменять моки на реальные ответы. В этой статье пойдет речь о таких подходах на фронтенде,

Упереться в лимит 4 миллиарда строк в TOAST-таблице или поймать OidGen lock при массовой заливке документов — страшный сон администратора PostgreSQL. Хотя архитекторы советуют выносить файлы в S3, реальность часто диктует хранение внутри БД. Руководитель группы по оптимизации приложений Александр Попов разбирает, как работают стандартные механизмы bytea и pg_largeobject, где находятся их «бутылочные горлышки» и как эти ограничения обходятся в Postgres Pro Enterprise.

Привет, Хабр! Недавно у меня появилась задача - собрать RAG-систему для интернет-энциклопедии. В поисках решения я вышел на новый подход к гибридному RAG - “DAT: Dynamic Alpha Tuning for Hybrid Retrieval in Retrieval-Augmented Generation” (Динамическая настройка Альфа-параметра для гибридного поиска в RAG). 

Поиск по Хабру и Рунету показал, про подход DAT на русском языке еще не рассказывали, поэтому спешу поделиться находкой с вами и обсудить преимущества и недостатки этого метода. Эта статья - упрощённый пересказ научной работы. Материал будет интересен как продвинутым, так и начинающим разработчикам RAG-систем.

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

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

Данная система является полностью автономной, и инференс TensorFlow Lite-модели происходит прямо на борту микроконтроллера.

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

А что на счет самих данных, если мы их рассматриваем как продукт? Как будем оценивать их ценность, как будем планировать их развитие?

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

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

Разбираем, как привычные «найди максимум при таких-то условиях» превращаются в компактные декларативные модели, зачем вообще нужны такие упражнения, что они говорят о собеседованиях и о нашем отношении к алгоритмам — и где у подхода с MiniZinc/constraint solving проходят естественные границы.

За полгода активного использования Cursor IDE я была поражена тем, насколько этот инструмент изменил мой подход к работе. Разработка превратилась в удовольствие: поэтапное планирование, реализация, умные подсказки – агент выполняет задачи активно, быстро и, что самое главное, практически именно так, как я хочу.

Конечно, всегда есть к чему придраться, но существенных минусов становилось все меньше. Cursor-подобные IDE и LLM постоянно развиваются: с переходом на последние модели и увеличением контекстного окна, мощь инструмента достигла такого уровня, что повседневные задачи решаются за минуты, и я уже практически не задумываюсь о технической рутине.

Казалось бы, недостатков почти нет. Однако, всякий раз, приступая к новой задаче, я начинала новый чат. Мне не хотелось перечитывать свои диалоги недельной давности, искать там контекст. Но настоящая проблема возникает, когда задача переходит ко мне от другого разработчика. У меня нет доступа к его диалогу с чатом. Я не знаю, почему он принял те или иные решения, какие варианты он и AI отбросили. Мне приходится заново вводить Cursor в суть задачи, тратя время на объяснение того, что AI-агент моего коллеги уже знал.

Еще одной проблемой всегда остается отсутствие наглядного понимания хода проекта. Глядя на код, я вижу результат, но не процесс. Я не вижу, как менялась логика принятия решений и куда движется архитектура. Git Log дает мне сухие факты ("изменен файл X"), но не дает ментальной модели.

Получается парадокс: наши локальные AI-агенты умнеют с каждым днем, но как команда мы страдаем от "коллективной амнезии" и отсутствия единой картины мира. Именно это натолкнуло меня на идею Когнитивного слоя проекта (Project Cognition Layer). Если у нас уже есть инструмент, который идеально хранит историю всех изменений (Git), почему бы не "накинуть" на него когнитивный слой, понятный и человеку, и AI?

Привет, Хабр! Я Александр Лебедев, старший разработчик систем искусственного интеллекта в Innostage. В этой статье расскажу о нескольких интересных кейсах атак на ИИ-сервисы и базовых способах защиты о них. В конце попробуем запустить свой сервис и провести на нем несколько простых атак, которые могут обернуться серьезными потерями для компаний. А также разберемся, как от них защититься.

От красивых демок к законченным проектам: что я понял за полтора года работы с Claude Code

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

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

Проблема была не в промптах и не в архитектуре. Просто процесс разработки с ИИ постоянно буксовал: Claude выдавал код с API прошлого года, поиск нужной функции занимал по 15 минут, после третьего рефакторинга я терял нить и бросал проект, начинал терять что было сделано, сколько не суй ему to-do листы.

Потом я нашёл свой стек из MCP-серверов, которые действительно повысили эффективность в разных случаях от 2 до 8 раз, позволили экономить до 80% токенов, не терять контекст и совершать на 8 из 10 ошибок меньше.

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

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

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

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

Пристегивайтесь, будет интересно!

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

Привет! Меня зовут Артур, я специалист по пентестам в компании Xilant. В этой статье разберём одну из наиболее опасных уязвимостей, обнаруженных в XWiki — CVE-2024-31982, которая позволяет добиться удалённого выполнения произвольного кода (RCE) через, казалось бы, безобидную функциональность поиска.

XWiki давно занимает ключевое место среди корпоративных Wiki-платформ благодаря гибкой архитектуре и мощной системе шаблонов. Однако именно эта гибкость сыграла против неё: некорректная обработка пользовательского ввода в механизме рендеринга шаблонов привела к появлению критической SSTI-уязвимости.

В материале я покажу, как устроена брешь, как она эксплуатируется и как выглядит автоматизированный PoC, который я написал на основе анализа опубликованного исследования автора jacaba с портала Vicarius.io.