Здесь не будет песен и сказок о том какой крутой и недооценённый язык Forth:) По совокупности обстоятельств он скорее уже история. Однако некоторые связанные с ним аспекты поучительны и перспективны (например, для энтузиастов и разработчиков языков и компиляторов) — и хочется их записать на память, да и поделиться с коллегами.
-
n8n — это мощный инструмент, который я, как и многие инженеры, полюбил за гибкость и простоту. Он позволяет собрать практически любую интеграцию, как из конструктора, но с возможностью в любой момент залезть «под капот» с кастомным JavaScript. Идеально.
Но у этой мощи есть и обратная сторона. Сложные воркфлоу превращаются в лабиринт из нод, где каждая требует тонкой настройки десятков полей. Постоянное переключение между вкладками документации, написание JSON-объектов, парсинг API через Curl, дебаггинг бесконечных ошибок... Знакомо? Время на продумывание логики уходило на рутину. И мне, как и многим, пришла в голову «гениальная» идея: а что, если всю эту рутину возьмет на себя ИИ?
Это история о том, как я прошел путь от веры в универсального агента до создания практичной группы ассистентов, которые не заменяют, а реально ускоряют работу.
Привет, Хабр! Какое‑то время назад, в процессе изучения bash‑скриптов, старался углубляться в тему и искал себе больше практики посредством решения любых, даже мельчайших задач. Одной из таких был скрипт, удаляющий временные файлы, старые дампы, папки node_modules от давно забытых проектов. Нашёл его на днях совершенно случайно. Протестил его на виртуалке, скрипт рабочий, но ужасно костыльный и неприятный визуально.
Какая у меня появилась идея? Проверить, сможет ли ChatGPT сделать то же (и насколько качественно), что и я, но грамотнее и «элегантнее». Результат получился весьма поучительным: ИИ отлично справился с архитектурой, но очень пытался угробить систему парой строчек. Далее расскажу, как это было.
В арсенале разработчиков есть целый ящик с инструментами, каждый из которых обещает облегчить жизнь программиста. Но во всем этом разнообразии спрятался один супергерой, который выручает в самых сложных ситуациях. И имя этому герою — CMake!
В современных приложениях централизованная аутентификация и авторизация играют ключевую роль в обеспечении безопасности и удобства пользователей. Именно с такой задачей мы столкнулись в компании NAUKA при создании "Платформы" — экосистемы, предназначенной для функционирования наших решений и разработки собственных прикладных приложений. В качестве основного компонента системы аутентификации и авторизации был выбран Spring Authorization Server.
Настоящая статья - это небольшой практический обзор реализации SSO-сервера на основе технологии Spring Authorization Server с акцентом на решении типовых проблем, которые возникают при её использовании в реальной системе. Мы рассмотрим как технические детали, так и архитектурные решения, которые помогут создать надежный и масштабируемый сервер авторизации.
Я устроился в Apple в октябре 1995 года. В это время Apple кружилась в сливном отверстии раковины, готовясь отправиться в канализацию. Возможно, вы помните все эти разговоры о том, что Apple скоро закроется. Немного странно, что она продолжала нанимать сотрудников, но, очевидно, в Apple считали, что им всё равно нужен ещё один «графический инженер» для работы над технологией QuickdrawGX. Тогда мне был 31 год, я жил в Канзасе и программировал игры для Macintosh. Разумеется, в компании решили, что я хорошо подойду на эту должность.
Процесс собеседования оказался для меня совершенно неожиданным и новым (подробно о нём написано здесь), но в конечном итоге мне предложили работать графическим инженером QuickdrawGX в Apple Computer, Inc.
Переезжать с моей девушкой, всеми вещами (и двумя кошками) из Канзаса в Калифорнию было безумно сложно, но мы справились. Как окажется позже, мне предстояло ещё многое узнать о программировании, да и о профессионализме в целом. И тут я сразу понял, что, возможно, взялся за задачу, которая мне не по зубам (как программисту). Другие инженеры Apple были дружелюбными, но и очень умными. (Наверно, мне стоит подробнее написать о панике, которую я ощущал первое время; казалось, будто я случайно забрёл в глубокую часть бассейна.)
Впрочем, постепенно (примерно через полгода) я, так сказать, вошёл в колею, и начал справляться с работой немного увереннее. Но вскоре я всё равно понял, что по-прежнему остаюсь недисциплинированной деревенщиной, не совсем отвечающим стандартам Профессиональной Корпорации™.
Вскоре после моего прихода в компанию проект QuickdrawGX расценили провалившимся, меня перевели в новую команду (ColorSync) и чуть позже выдали новый проект. У Apple было стандартное окно, в котором пользователь мог выбирать цвет, оно называлось Color Picker («Палитра»). Кроме того, в то время Apple начинала переход с чипов Motorola 68K на новые, более быстрые чипы PowerPC (PPC). Моя задача заключалась в том, чтобы проект Color Picker, написанный для чипов 68K, компилировался для новой архитектуры PPC.
Я начал пользоваться платформой Linear пару месяцев назад. То, с чем я столкнулся, затянуло меня в кроличью нору деталей local-first-разработки (локально-ориентированной разработки), которые изменили мой взгляд на веб-приложения.
Метод Верле́ — один из самых элегантных и простых численных способов решать уравнения движения. Его можно встретить и в молекулярной физики, и в геймдеве (cloth sim 🧦). Недавно я сделал короткое видео с его наглядной демонстрацией (см. YouTube Shorts под катом и зеркало на GitHub).
В этом посте я хочу показать, как идея «чисто позиционного» интегрирования без явного использования скоростей превращается в рабочую анимацию, начиная с простых примеров, заканчивая сетками и игрой в бильярд 🎱
Кажется, про TDD давно всё известно: сперва тест — потом код — получаем покрытие. Но на деле его суть понимают неправильно — как критики, так и сторонники.
Эта статья — не инструкция и не религиозная проповедь. Это разбор заблуждений. Причём речь пойдёт не только о критиках TDD, но и о его сторонниках.
TDD часто воспринимают как способ добиться максимального покрытия или как дисциплину «писать тесты вперёд». Но настоящая цель — не в тестах, а в итеративном проектировании поведения и архитектуры.
Если вам кажется, что TDD — это занудно, медленно, не подходит к реальному коду или убивает гибкость — возможно, вы всё делали правильно.
Но с совершенно другими целями.
Именно поэтому вам не понравилось.
Разберёмся, что такое TDD на самом деле — и почему вы, скорее всего, не знаете TDD.
Считается, что на конференции лучше всего запоминаются первое и последнее выступления. И тут я не являюсь исключением, так как при посещении С++ Zero CostConf 2025 мне сильнее всего запомнились как раз первый и последний доклады, но думаю не только из-за эффекта края, но и по той причине, что они были для меня самыми интересными и именно ради них и я решил съездить в Москву из далекой российской глубинки.
Но мне не хочется писать про само мероприятие, тем более, что видеозапись всех выступлений выложена на сайте конференции C++ Zero Cost Conf 2025 и пересказывать технически детали докладов не имеет смысла.
Однако прошедшее мероприятие было очень необычным и запоминающимся: мне удалось попробовать себя в роли вайб-кодера, а по результатам общения с докладчиками — написать два предложения в комитет по стандартизации C++ от России. Поэтому я всё же решил поделиться с читателями «Хабра» своими впечатлениями от некоторых докладов конференции и собственными выводами о вайб-программировании.
Привет, Хабр!
В C/C++ давно принято встраивать Python в приложения для скриптовой логики и плагинов. Именно эта экосистема много лет давала повод развивать в CPython идею нескольких изолированных интерпретаторов в одном процессе. Долгое время это было только в C-API: создаёшь новый интерпретатор через Py_NewInterpreter, живёшь с одним общим GIL и кучей глобального состояния. В Python 3.12 появилось ключевое изменение — GIL стал на-интерпретатор (каждый subinterpreter со своим GIL), но доступ был только через C-API. В 3.14 подвезли полноценный высокоуровневый Python-API: модуль concurrent.interpreters и InterpreterPoolExecutor.
Теперь можно писать параллельный код без multiprocessing, но с изоляцией уровня «почти процесс».
Дальше разберёмся, что это такое, когда это уместно вместо multiprocessing.
Мне тут попалась идеальная статья про DI в который нашелся очень интересный пример для разбора. Есть фундаментальные основы, которые почему то никто не хочет сформулировать, а начинающим разработчикам, которые впервые сталкиваются с концепцией DI, в первую очередь надо бы рассказать эти фундаментальные основы, но почему то нет желающих это сделать и у меня даже есть предположения, почему это не получается, я попробую их как-то выразить в том числе.
Я знаю что искать ошибки в статьях начинающих на Хабре это плохой тон, и я вряд ли выйду в плюс с такой статьей, но как говорится: Платон мне друг, но истина дороже.
В предыдущей статье мы выяснили как создать два класса (Хост и Енкодер, класс А и класс В) один из которых (А) не может работать без использования функций другого класса (В, а может, и без данных из этого класса В не может работать), но при этом совершенно не зависит от этого класса В! То есть класс А может запросто работать с любым другим классом (C, D, … ) вместо класса В, при некотором условии изложенном в предыдущей статье. По моему, та статья может быть хорошей разминкой для понимания концепции Внедрения Зависимостей. И, определенно, эта статья может считаться продолжением темы практической архитектуры ПО.
В настоящее время от игроков, желающих участвовать в онлайновых многопользовательских сеансах, в античитерских движках обязательно требуется включить безопасную загрузку (Secure Boot) и встроенный доверенный платформенный модуль (fTPM). Удастся ли таким образом обуздать читеров, или же это бесплодная попытка купировать разрастающуюся проблему?
Привет, Хабр!
В экосистеме C# за последние два релиза случилось ровно то, чего многим не хватало для аккуратной работы со списками значений. В C# 12 появились collection expressions — синтаксис вида [1, 2, 3] со spread-элементами .., который конвертируется в массивы, Span, ReadOnlySpan, интерфейсы коллекций и любые правильно устроенные типы. В C# 13 к этому добавили params-коллекции: теперь params может быть не только массивом, а почти любой поддерживаемой коллекцией, включая спаны и неизменяемые контейнеры.
Привет, Хабр!
Меня зовут Дмитрий, я бэкенд-разработчик в SENSE и последние 10 лет пишу серверную часть на Java. Эта статья — продолжение серии гайдов по Spring GraphQL, где в первой части мы с нуля подняли проект и подключили GraphQL к Spring Boot, а во второй разобрались с SchemaMapping, DataLoader и реализацией запросов посложнее.
Сегодня двигаемся дальше: разберём валидацию данных, работу с заголовками (headers), обработку ошибок, подключение кастомных скаляров и директив. А ещё посмотрим, как работать с интерфейсами и union-типами, и напишем клиент для GraphQL-сервиса.
Поехали!
Искусственный интеллект уже здесь и он повсюду: от производственных линий трубопрокатных заводов до брейнрот-контента в вашей ленте. С вами снова Михаил Семенов, ведущий юрисконсульт Cloud.ru и человек, который 6 лет прослужил в прокуратуре.
Сегодня предлагаю обсудить слона в комнате, а именно: что вам будет с точки зрения закона, если AI, который вы разрабатываете или закупаете для своей компании, ошибется, некорректно сработает или будет использован для нарушения чужих прав. Ныряйте под кат, там разберем какие правовые документы регулируют это у нас и за рубежом, в какую сторону скорее всего будет развиваться законодательство в сфере AI и что предусмотреть в доке, договорах и регламентах уже сейчас, чтобы потом не пришлось тушить пожары. Постараюсь сильно не грузить и сразу переводить с юридического на человеческий.
Для многих рынок ИИ-решений представляется как конкурентная борьба облачных и open source-моделей, но спектр применения языковых моделей постоянно расширяется, закрывая все более узкие ниши. И сейчас все больше команд, даже среди лидеров, выкладывают свои специализированные модели в общий доступ открытыми не только для запуска, но и дообучения и доработок. Эти модели часто имеют более скромные системные требования по сравнению с облачными. Иногда настолько, что некоторые из них можно запускать на мобильных и встраиваемых устройствах даже без специальных нейро- или графических вычислителей. Такие тенденции требуют от ИТ-специалистов навыков в обращении с моделями, некоторые из которых мы рассмотрим в данной статье на примере настройки модели, ассистирующей в разработке программного кода на локальном ПК. Учитывая высокую динамику развития индустрии ИИ, приведенные решения не могут быть ультимативными и актуальными, однако, возможно, кому-то он помогут продвинуться в освоении навыков работы с LLM-моделями (Large Language Models - Большие языковые модели).
Чаще всего мы падаем не на сложных алгоритмах и не на асинхронных гонках. Главные враги — самые простые куски кода, те, на которые даже не хочется тратить внимание. В этой статье я делюсь опытом и наблюдениями о том, как «архитектура сомнений» помогает не доверять очевидному, и почему программисту полезно быть немного параноиком.
Не торопитесь пролистывать эту статью. Я не собираюсь, подобно множеству других статей на Хабре, рассказывать о плюсах или минусах вайб-кодинга и сравнивать это с плюсами и минусами традиционного программирования. Потому что сравнивать нечего, ведь не случилось ничего такого, что бы как-то значительно изменило ситуацию. По сути, я буду говорить о том же, о чём говорил в предыдущей статье ( https://habr.com/ru/articles/938028/ -Михаил Елисейкин «IT-лягушка и новая нормальность» ) - о том, что мир меняется, а наши о нём представления от этих изменений отстают.
Привет, меня зовут Алекс Гусев и я хочу обсудить предсказуемость LLM. Я очень тепло отношусь к Моделям и меня очень огорчают заявления, что Модели непредсказуемы. Они предсказуемы, только не всегда. В общем-то, как и люди - для многих людей мы можем предсказать их поведение в определённых ситуациях, хотя ни один человек не является полностью предсказуемым даже для самого себя.
