Обновить
1056.88

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

Искусство создания компьютерных программ

Сначала показывать
Порог рейтинга

TypeScript и C++ в одном бинаре. Первый open source-проект от МойОфис

Команда МойОфис выложила в open source собственную разработку — компилятор tsnative. Это кроссплатформенный инструмент, который объединяет удобство TypeScript с производительностью C++ в одном приложении. Исходники — на GitHub под лицензией Apache 2.0.

Компилятор tsnative — это первая и ключевая часть более масштабного проекта под названием AntiQ, в котором мы переосмысляем подход к кроссплатформенной разработке без тяжёлых фреймворков.

AntiQ разделен на два самостоятельных компонента. Сейчас в open source опубликован только tsnative — главный модуль, в котором сосредоточена основная логика и заложены архитектурные принципы всей платформы.

Зачем это нужно?

tsnative — это кроссплатформенный компилятор, преобразующий TypeScript в нативный машинный код. Он обеспечивает бесшовную интеграцию с C++ без glue-кода или JavaScript-движков, объединяя удобство высокоуровневой разработки с производительностью системного кода. В результате вы получаете один бинарник, собранный из двух языков.

Как это работает:

  • C++-функции помечаются TS_EXPORT;

  • генерируются .d.ts-декларации для TS;

  • TypeScript- и C++-код собираются через LLVM;

  • на выходе — один исполняемый файл, без обёрток.

// math.cpp
#include "TS.h"
TS_EXPORT int add(int a, int b) {
return a + b;
}
// index.ts
console.log(add(2, 3)); // -> 5
// index.ts
console.log(add(2, 3)); // -> 5

Проект может быть интересен тем, кто:

  • делает нативные приложения, но хочет писать часть логики на TS;

  • ищет замену закрытым коммерческим компиляторам;

  • любит ковыряться в сборке, кросс-компиляции и низкоуровневом коде.

Открытый код — не просто «выложили и забыли». Мы хотим, чтобы проектом пользовались, коммитили, обсуждали. Поэтому будем рады pull request’ам, issue и звёздочкам. Всё как обычно :)

Исходники на GitHub

Если у вас есть вопросы или комментарии, вы можете задать их в чате проекта: https://t.me/antiqmyoffice

Теги:
Всего голосов 33: ↑33 и ↓0+36
Комментарии12

Мой код, мой кофе, мой хаос

Для ЛЛ: перечислены способы мотивации сотрудников, которые вам могут показаться банальными

Недавно на работе разгорелся жаркий спор. Двое наших разработчиков сцепились из-за выбора библиотеки для работы с датами в монорепе на js. Один был фанатом Luxon, утверждая, что она идеально подходит для сложных задач с датами и временем. Второй клялся, что Date-fns – в это лучший выбор, потому что она лёгкая, быстрая и позволяет использовать только нужные функции, не раздувая проект.

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

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

Разрешение конфликта

Чтобы выйти из тупика, я предложил компромисс: «Ребята, давайте так. Каждый из вас реализует свою часть проекта с использованием своей библиотеки. На проверку идей у вас 2 дня, потом сравним, что получилось». Они согласились, и весь накал спора тут же утих – оба погрузились в работу, стремясь доказать, что их выбор лучший.

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

В таких случаях я обычно:

  • Развожу спорщиков по разным проектам

  • Или принимаю сам решение какую технологию использовать далее

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

Мотивация-шмотивация

Несмотря на подзаголовок, я приведу реально применённые способы поднятия мотивации разработчиков:

  1. Деньги-деньги, решают многое. Сюда же незапланированные премии.

  2. Повышение должности сотрудника (иногда даже без повышения зарплаты, не везде корректно настроены грейды). Был «разработчик», стал «Ведущий разработчик», потом «Старший разработчик» и т.д.

  3. Обновляешь ноутбук работнику. Иногда для сотрудника это долгожданное обновление, и это очень повышает его мотивацию и лояльность к компании (ну или к тому, кто её выбил).

  4. Про лишние дни отдыха тоже понятно.

  5. Оплата билетов на конференции по IT-тематике (а они не всем по карману сейчас), покупка лицензий на удобный софт.

  6. Признание заслуг в разработке проекта перед вышестоящим начальством и текущей командой. Хотя это должно быть по умолчанию в команде.

Этих пунктов может быть ещё очень много, везде индивидуально.

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

Если есть чем поделиться, как вас мотивировали - прошу в комментарии.

Теги:
Всего голосов 9: ↑4 и ↓5-1
Комментарии0

Gemini 2.5 Deep Think получила первую официальную золотую медаль IMO среди AI-систем

20 июля 2025 года Google DeepMind совершила прорыв: их модель Gemini 2.5 в режиме Deep Think стала первой AI-системой, официально получившей золотую медаль на Международной математической олимпиаде (IMO). Разбираемся, что это значит для развития искусственного интеллекта и когда технология станет доступна разработчикам.

Что произошло на IMO 2025?

Gemini 2.5 Deep Think набрала 35 из 42 возможных баллов, решив 5 из 6 олимпиадных задач за отведённые 4,5 часа. Главная особенность — все решения проходили на естественном языке без формальных переводов в системы вроде Lean или Coq.

Это кардинально отличается от предыдущих попыток. Например, AlphaGeometry от Google в 2024 году достигла только серебряного уровня в геометрических задачах, при этом тратила дни на решение одной задачи и требовала мощных вычислительных кластеров.

Важно: OpenAI заявляла о золотом уровне для своих моделей o1/o3, но официального признания от комитета IMO они не получали.

Архитектура Deep Think: мульти-агентное мышление

Технологический прорыв Deep Think заключается в нескольких ключевых инновациях:

1. Множественные потоки рассуждений

Модель запускает несколько параллельных "агентов", каждый из которых исследует свой путь решения. Затем результаты объединяются для финального анализа — подход, схожий с Grok 4 Heavy от xAI.

2. Увеличенное время на размышления

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

3. Специализированное обучение с подкреплением

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

Доступность и ценообразование

Здесь начинаются проблемы. Google выпустила две версии Deep Think:

  1. IMO Gold версия — доступна только избранным математикам и исследователям

  2. Bronze версия — публично доступна через подписку Google AI Ultra

Стоимость Bronze версии:

  • $124.99/мес первые 3 месяца

  • $249.99/мес в дальнейшем

  • Включает: Deep Think, Veo 3 (генерация видео), 30 ТБ хранилища

Ограничения Bronze версии:

  • Время ответа: 30-60 секунд на сложные запросы

  • Ограниченное количество запросов в день

  • Упрощённые возможности по сравнению с IMO-версией

Критический взгляд: стоит ли овчинка выделки?

Реакция комьюнити неоднозначная. Основные претензии:

  1. Неоправданно высокая цена: многие пользователи отмечают, что подписка Ultra даёт те же квоты API, что и бесплатный аккаунт

  2. Медленная работа: 30-60 секунд ожидания не подходят для продуктивной работы

  3. Неясные перспективы: Google не сообщает, когда IMO-версия станет доступна публично

Значение для индустрии

Успех Deep Think на IMO знаменует переход от "умных автодополнений" к системам, способным к настоящему рассуждению. Это открывает новые возможности:

  • Научные исследования: помощь в доказательстве теорем и решении сложных задач

  • Инженерия: анализ комплексных технических проблем

  • Образование: персонализированное обучение математике и логике

Что дальше?

Google обещает API-доступ к Deep Think "в ближайшие недели", но пока только для "доверенных партнёров". Полноценная IMO-версия может остаться исследовательским инструментом надолго.

Для разработчиков это означает ожидание: пока что Deep Think — это скорее демонстрация возможностей, чем готовый продукт для интеграции.

Выводы

Gemini 2.5 Deep Think действительно совершила исторический прорыв, став первой AI-системой с официальной золотой медалью IMO. Однако коммерческая реализация пока разочаровывает: высокие цены, ограниченный функционал и неясные перспективы развития.

Если вам нужна скорость и код — оставайтесь с GPT-4, Claude или o1. Если же готовы платить за глубокие рассуждения и не спешите — Deep Think может стать интересным инструментом.

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии1

Где учиться фронтенду

Привет! Мы на Хабр Карьере собираем сотни онлайн-курсов в IT или digital на маркетплейсе курсов и каждую неделю делаем подборки обучений для тех, кто хочет учиться какой-то специализации с нуля или для тех, кто уже в профессии, но чувствует, что хочет прокачать навыки.

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

HTML/CSS

Разметка и стилизация веб-страниц. HTML задаёт структуру, CSS отвечает за внешний вид, адаптивность и анимации.

JavaScript

Язык для добавления интерактивности на веб-страницах. Используется в браузере и на сервере (через Node.js), лежит в основе большинства фронтенд-фреймворков.

Git

Система контроля версий. Позволяет отслеживать изменения в коде, работать в команде и управлять ветками разработки.

React

JavaScript-библиотека для создания UI. Использует компонентный подход и виртуальный DOM. Разрабатывается Facebook.

Angular

Фреймворк от Google для построения SPA. Включает собственную архитектуру, TypeScript, DI, роутинг и инструменты для тестирования.

Vue.js

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

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

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

→ Смотреть курсы по всем специализациям

Теги:
Всего голосов 4: ↑1 и ↓30
Комментарии1

minimal vscode: открываем окна

Нет, не от духоты, ее в видео как раз не будет 🌚️️️️
Видео короткое, динамичное, практичное.

Перед тем как учиться пользоваться vscode, необходимо:

  1. Её поставить

  2. Научиться её открывать

  3. Располагать её на рабочем пространстве

Мой конфиг: https://github.com/sobolevn/dotfiles

В видео поговорили про: hotkey managers, тайлы, всякие красивости для macos.

Менеджеры горячих клавиш:

Тайловые менеджеры:

Полезности:

Теги:
Всего голосов 15: ↑13 и ↓2+14
Комментарии3

BPN vs MVM

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

В одном файле эта задача реализована в архитектуре BPN (Business Process Notation), о которой рассказывал раньше здесь. А во втором файле тот же код организован по архитектуре MVVM.

Код и в том, и в другом файле написан с помощью Claude Sonnet. В случае с BPN структурировал код вручную, следуя бизнес-процессам. А во втором случае попросил Клода сделать рефакторинг, используя традиционный современный подход и он выбрал MVVM.

Что можно сказать в итоге, сравнивая архитектуру в том, и другом случае. 

Объём кода

В BPN варианте 270 строки кода с комментариями, в MVVM - 524.

Т.е., в MVVM случае кода практически в 2 раза больше.

Количество сущностей, объектов.

BPN - один класс и 3 раширения к нему.

MVM - 6 классов, 1 структура, 3 протокола, каллбэки, фабрика, расширение.

Архитектура

BPN - монолит.

MVVM - вью и модель, анимация и аудио как сервисы, роутер, отдельная структура для хранения значений свойств и т.д.

Что лучше

Как всегда, каждый из подходов имеет свои плюсы и минусы.

В BPN нравится, что можно видеть модель процесса, в данном случае модель одной из задач приложения.

Что такое “Модель”

Наиболее традиционны 2 понимания термина “модель”.

В одном случае, это структура данных, модель объекта.

Например:

struct Person {

let firstName: String

let lastName: String

var age: Int

}

В другом случае, под моделью понимается всё, что не относится к интерфейсу.

Но есть и третье понимание модели - это модель приложения, или модель отдельных процессов внутри приложения. Т.е., составные части приложения (процесса) и их последовательность.

В BPN файле такая модель проступает наглядно:

Модель процесса "Обратный отсчет"
Модель процесса "Обратный отсчет"

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

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

Conclusion

На относительно небольших проектах архитектура MVVM может быть избыточна. Здесь могут использоваться более простые варианты.

BPN позволяет видеть целостную модель задачи (процесса, приложения).

Теги:
Рейтинг0
Комментарии10

Интеграция PVS-Studio c AppSecHub

Компания PVS-Studio и платформа AppSec.Hub заключили технологическое партнёрство для обеспечения интеграции статического анализатора кода PVS-Studio в экосистему DevSecOps.

AppSec.Hub — это платформа для автоматизации процессов Application Security, которая позволяет объединять различные инструменты анализа, тестирования и мониторинга безопасности приложений.

Отчёт анализатора PVS-Studio теперь можно загрузить для просмотра в платформу AppSecHub вручную с помощью пользовательского интерфейса инструмента либо с помощью специальной утилиты командной строки.

Подробнее о работе PVS-Studio в AppSec.Hub можно прочитать в посвящённом этому разделе документации.

Также мы провели вебинар с коллегами из AppSec Solutions, чтобы на практике показать, как инструменты работают вместе, а также поделиться полезным опытом в интеграции статического анализа в DevSecOps.

Теги:
Всего голосов 1: ↑1 и ↓0+2
Комментарии0

Хотите подтянуть свои знания Go?

Тогда новый бесплатный курс для вас!

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

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

Несколько материалов для старта.

Открыть курс →

Теги:
Всего голосов 6: ↑6 и ↓0+9
Комментарии1

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

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Быстрые сборки с функцией Rollback в Amvera Cloud

Ранее в Amvera Cloud, были возможны откаты только путём новой сборки из нужного коммита в Git-репозитории. Помимо этого, использовалась медленная технология сборки.

Мы ускорили сборки до 10 раз и сделали возможность быстрого отката к предыдущим версиям!

Стало легче откатывать приложение, в случае ошибок.

Подключить быстрые сборки можно в разделе проекта «Контроль версий».

Интерфейс управления версиями сборок
Интерфейс управления версиями сборок

Новые сборки

  1. Быстрее старых до 10 раз.

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

Amvera Cloud – облако для простого запуска проектов со встроенным CI/CD (деплой идёт через Git или загрузку файлов в интерфейсе), бесплатными https-доменами, мониторингом работы приложений, встроенным проксированием до ведущих LLM и собственным инференсом LLaMA.

Вам не нужно думать о настройке инфраструктуры. Git push amvera master и ваш проект запущен. Зарегистрируйтесь и получите 111 рублей на тест. 

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

LeetCode ponts кому-нибудь помогли?

Мне на LeetCode постоянно LeetCode point-ы добавляют. У кого-нибудь есть реальный пример полезного применения этих points? У меня их 26 штук уже. Делать пока с ними ничего невозможно. А что реально полезного от них можно получить? Можно ли RMT-ить их? У кого получалось

Теги:
Всего голосов 4: ↑2 и ↓20
Комментарии2

Выводим Соера на чистую воду разбирая дискуссию с ним про принципы SOLID

Топ перлов

  • Если ты манки-патчишь объекты, то ты функциональщик.

  • Ты должен сначала залезть на гору, а потом уже решить надо было тебе сюда или нет.

  • Если люди по разному воспринимают принцип - это здорово, ведь он подталкивает людей к размышлению.

  • SOLID позволяет легче (т.е. не задумываясь) принимать не идеальные (т.е. сомнительные) решения.

Упомянутые материалы

Копилка благодарностей

Теги:
Всего голосов 10: ↑4 и ↓6-2
Комментарии0

Использование случайностей в функциональном тестировании


Для кого эта статья?

  • Инженеры по автоматизации и разработчики тестов — вам точно будет интересно.

  • Обычные разработчики, если вы заинтересованы в качестве продукта, а не считаете тесты "расплатой за грехи" или "прихотью менеджмента" — тоже.

А кого, возможно, не заинтересует

Если у вас постоянно есть падающие тесты, и никто не разбирается в причинах, а просто смотрят на процент "зелёных" и "красных", — эта статья может показаться бесполезной.

Откуда вообще эта идея?

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

На первый взгляд — всё логично. Но на практике:

  • увеличивается время прогона (особенно для UI-тестов);

  • растёт вероятность нестабильности (flaky-тесты);

  • тесты зачастую дублируют поведение друг друга.

Наглядный пример

Допустим, у нас есть UI-тест, проверяющий переходы по меню на сайте. Стартовая страница содержит меню для перехода на страницы A, B, C, D.

Сценарий теста:

  1. Открываем стартовую страницу.

  2. Выбираем пункт в меню.

  3. Проверяем, что оказались на нужной странице.

Что делает большинство:

  • Пишут четыре теста: переход на A, на B, на C и на D.

  • Или параметризуют тест: гоняют один и тот же сценарий с разными входными.

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

Проблема

Если тест проверяет функциональность, то логично оставить один вариант— переход на страницу A. Экономите ресурсы, всё стабильно и функциональность проверяется. Но однажды приходит тимлид с вопросом:

Почему тесты не поймали баг с переходом на страницу D?

В этом случае экономия не оправдалась

Что делать?

Тест — это тоже код. Он может быть не стабильным. И чем чаще он запускается, тем быстрее мы понимаем, стабилен он или нет.

А теперь возвращаемся к примеру с меню:

Что, если каждый раз случайным образом выбирать один из пунктов (A, B, C, D)?

  • Экономим ресурсы: запускается один тест вместо четырёх.

  • С течением времени мы случайным образом "покроем" все пункты.

  • Чем чаще прогоняются тесты, тем быстрее мы обнаружим баг (например, если страница C не открывается).

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

Это не ноу-хау

Такой подход давно известен — он называется property-based testing.

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

Что важно помнить

  • Использование случайности не должно усложнять тест. Логика должна быть понятна и читаема.

  • Если тест упал, он должен сообщить, что именно пошло не так, даже если данные были сгенерированы случайно.

  • Рандомизация — всего лишь один из способов сделать тесты более эффективными, но это не универсальное решение

  • Иногда стоит логировать/фиксировать сгенерированные данные, особенно при падении теста — чтобы потом воспроизвести баг

Итог

Рандомизация в тестировании — мощный инструмент:

  • помогает экономить ресурсы;

  • расширяет покрытие;

  • стимулирует стабильность и надёжность тестов.

Но применять её стоит с умом: понимать, зачем, где, и в каком объёме.

А как у вас это устроено? Используете ли вы property-based подход в тестах? Или всё ещё параметризуете всё подряд? Буду рад услышать ваши мнения, кейсы и даже критику.

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии2

Ближайшие события

Есть для альтернатива Delphi в 2025 году для простых кроссплатформенных приложений?

Навеяно обсуждением статьи про Дельфи в 2025.

Q1: Если сейчас есть задача по-быстрому сбацать что то с формами под винду - какая есть альтернатива дельфи?

Q2: А если так же быстро накидать, только кроссплатформенное приложение и без зависимостей?

И мой ответ

A: Не находишь, что 3000$ за кроссплатформенный дизайнер форм слишком дорого? Даже за хороший.

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

Все может использоваться бесплатно и без особых претензий на функциональность. Единственное, иногда бывает нужно еще нарисовать какой то чарт/график и загрузить/записать данные в БД/XML/JSON - с этим могут быть нюансы с конкретным вариантом.

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

  1. GNOME Builder (ex.Anjuta). GTK multilang IDE

  2. Cambalache (ex.Glade) - GTK form builder

  3. Qt Creator

  4. FLUID for FLTK

  5. wxFormBuilder for wxWidgets 

  6. Projucer for JUCE

  7. Ultimate++ 

  8. NetBeans GUI design tool for Java Swing 

  9. TKproE (TCL/TK Programming Environment)

  10. Lazarus

  11. MSEide+MSEgui Pascal

  12. GTK# Visual Designer MonoDevelop (retired)

  13. Xamarin.Forms GTK Backend (discontinued for NET MAUI)

  14. JavaFX Scene Builder

  15. Pygubu Tkinter a GUI for Python

    Может еще что и забыл, либо не попалось на глаза.

Теги:
Всего голосов 8: ↑4 и ↓40
Комментарии15

За более чем 30 лет работы в IT я зарабатывал на жизнь программированием на языках Assembler, Basic, C, C++, Fortran, Lisp, Pascal, PL/I, Python, REXX, Scheme (в алфавитном порядке), а также руководством подобными процессами. Занимался я преимущественно системным программированием, то есть, так сказать, производством средств производства; но не только.

Вот какой получился рейтинг языков программирования в моей жизни:

– больше всего строк кода я написал на ассемблере, причём в основном бесплатно, в процессе обучения;
– больше всего по продолжительности я программировал на Паскале (не то чтобы это было свойство самого Паскаля, а просто время такое было);
– больше всего удовольствия я получал от использования PL/I;
– самой дорогой в перерасчёте на строчку кода была моя программа на REXX (так сказать, антипод ассемблера в моей карьере);
– самый сложный код я писал на Scheme.

Выводов делать не буду.

Теги:
Всего голосов 8: ↑6 и ↓2+9
Комментарии4

Последовательность Фибоначчи может конвертировать мили в километры с небольшой погрешностью

5 миль ≈ 8 км (5 и 8 - числа Фибоначчи). Реальность: 5 миль = 8.04672 км.

Почему?
1 миля = 1.609344 километра (точное значение).
Золотое сечение (φ) ≈ 1.618034

Погрешность возникает потому что отношение Fₙ₊₁ / Fₙ стремится к φ ≈ 1.618034, а точное соотношение миля/км = 1.609344.

Относительная погрешность: (1.618034 - 1.609344) / 1.609344 * 100% ≈ 0.54%.

Решил по фану реализовать конвертор милей в километры на C. Ссылка тут.

Advanced distance converter: miles to kilometers
Usage: ./bin/fib_miles2km [OPTIONS] [distance]

Options:
  -h, --help                     Show help information
  -f, --fib=ARG                  Convert miles to km using basic Fibonacci
  -b, --basic=ARG                Convert miles to km using standard formula
  -i, --fib-interp=ARG           Convert using Fibonacci interpolation
  -c, --fib-cache=ARG            Convert using cached Fibonacci
  -g, --fib-golden=ARG           Convert using golden ratio

Не знаю зачем, но прикольно :)

Теги:
Всего голосов 13: ↑12 и ↓1+18
Комментарии1

Представлен открытый репозиторий с коллекцией гайдов по почти всем стекам технологий — от операционных систем и языков программирования до паттернов проектирования и принципов дизайна. Все гайды сжаты и структурированы, включая популярные языки программирования — Python, Java, Go, JS, Rust, всё об инструментах, редакторах кода и IDE, а также шпаргалки по горячим клавишам, библиотеки и фреймворки для работы.

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии1

АГЕНТЫ И АГЕНТНАЯ ЭКОНОМИКА. 17.07.25.

Микро-дайджест недели.

=> Если мы будем следить за ходом их мысли (рассуждениями ИИ-агентов), то мы сможем лучше их понимать и управлять ими. Этот манифест за безопасность Chain of Thought Monitorability подписали вчера ведущие исследователи индустрии.

Но по факту весь ризонинг, демонстрируемый пользователю, может оказаться внешней декорацией, а решение LLM может принимать исходя из совершенно другой логики и других связей, то есть не тех, которые они демонстрируют в цепочках рассуждений. Другое дело с мультиагентными системами, там есть возможность сохранить прозрачность, даже в случае деградации "честного" Chain-of-Thought у отдельных моделей.

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

=> Не любите вайб дебаггинг также как и я? На подходе инженер Azimov, и его ключевое отличие от текущих код-генераторов в том, что он не только генерит код, по словам разработчика он его будет "понимать".

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

=> Деньги любят тишину. Я попробовал угадать, что за продукт выкатит бывшая CTO Open AI Мира Мурати, которая недавно подняла еще 2 млрд $ на seed-раунде при оценке 12 млрд $, при этом никто не знает, а чем собственно занимается ее стартап Thinking Machines Lab AI. Читайте в новой статье

=> Open Deep Research это агент для глубоких исследований с открытым исходным кодом, созданный на основе LangGraph и совместимый с вашими источниками данных, LLM и MCP-серверами. Подробно в блоге

И краткий обзор на YT демонстрирующий архитектуру такого агента и принципы разработки, как запустить агента локально с помощью LangGraph Studio и как быстро протестировать его с помощью Open Agent Platform.

=> AWS стремится стать универсальным центром для ИИ-агентов от Anthropic, IBM, Perplexity и других. Amazon Bedrock AgentCore - ожидаемый релиз комплексного подхода AWS для создания и развертывания различных ИИ-агентов. Одно место, любые агенты, все под рукой. Иначе бизнес начинает сходить с ума от разнообразия выбора, в котором он в общей массе не очень то пока разбирается.

AWS представил комплексный набор сервисов корпоративного уровня, которые помогают разработчикам быстро и безопасно развертывать и эксплуатировать ИИ-агенты в любом масштабе, используя любую платформу и модель, размещенную на Amazon Bedrock или в другом месте. Здесь все подробности. А здесь коротко в видео на YT.

=> Хотите собирать низко висящие фрукты лиды? Есть такое решение Orange Slice. Они собирают разные рыночные сигналы по вашим ICP и определяют тех, кто заинтересуется вашим продуктом, а затем преподносят вам их словно "на блюдечке", с различными нюансами и деталями, так что остается только продать 😉

=> Посмотрите на Runway Act-Two - я впечатлен, модель захвата движения нового поколения с существенным улучшением качества и поддержкой отслеживания головы, лица, тела и рук. Для Act-Two требуется только видеозапись движения и референсный персонаж.

Lionsgate и AMC Networks уже участвуют в проекте, изучая модель будущих производственных процессов для Голливуда.

=> И напоследок, вот такой фреймворк, эмулирующий функциональность Grok Heavy с помощью мультиагентной оркестровки. И никаких $300

***

Предыдущие материалы и выпуски дайджеста, там до сих пор много интересных инсайтов. Более 50% из них имеют длинный горизонт актуальности. О новых бизнес-моделях и ИИ-стартапах: Айвентор и Фред

Теги:
Всего голосов 6: ↑4 и ↓2+2
Комментарии0

За создание аниме-аватаров для чат-бота Grok в xAI платят до $440 тыс. в год. Разработчику нужно создавать реалистичных ИИ-аватаров, вовсю тестировать геймплей во всех ситуациях и работать с голосовыми командами. Требования — Python, Rust, WebSocket, WebRTC и опыт работы iOS.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Откровения евангелистов БЯМ (LLM) для целей софтостроения генерируются публикуются с высокой скоростью. Не только на хабре, LinkedIn заполнен ими "под завязку". Прочитывать всё невозможно, да и не нужно, но некоторый тренд в изложении присутствует.

К сожалению, авторы много пишут о процессе, забывая собственно цели. Упоминание о функциональной сложности программы, как правило, отсутствует. Длина описаний процесса может создать ложное впечатление о развесистой функциональности, хотя большинство примеров находятся на уровне "записная книжка". В этом нет ничего плохого, просто не забываем, что 30 лет назад RAD типа Delphi умели создавать такие же "книжки" без написания кода вообще: достаточно было "накидать" компонентов на форму, настроить, связать их, и нажать "Run".

Накидали, и что дальше?

За словами "писать на близком к естественному языку", скрывается постепенное создание быстро растущего "промпта" - детальной спецификации, местами - псевдокода. Как следствие, необходимо иметь версии таких "исходников", как и раньше для кода (об этом практически не пишут). Для сторонних пакетов, API служб и прочих зависимостей не забываем указывать версии. По сравнению с таким "псевдокодом" техзадание может показаться увлекательной беллетристикой. Речь идет по сути о конечных спецификациях, ведь программирование - не столько кодирование (от силы 20% времени), сколько детальное проектирование и стабилизация.

Размер спецификаций псевдокода вкупе с описаниями контекста среды могут превзойти собственно размеры генерируемого кода, написанного программистом на формальном ЯВУ. Спецификации придется так же хранить в Git, и нервно просматривать, что же изменилось в сценариях, почему, ***, вместо слова "опять" кто-то написал "снова".

Для детерминированности процесса желательно, чтобы моделька была в том же состоянии, что и на предыдущем этапе генерации, но для внешних БЯМ-сервисов это недостижимо. Напомню, что компиляторы и классические генераторы кода (CASE, MDD) - детерминированные.

На первый план выходят тесты, их нужно писать "больше и лучше", потому что под капотом теперь только "черный ящик", "белого" больше нет. Тесты нужно постоянно обновлять в зависимости от объема изменений. Если ваши новые спецификации меняют 20% существующей кодовой базы, то тестов придется менять вдвое больше, принимая 2:1 за стандартное соотношение тестов к коду. Для языков без статической типизации тестирование еще более усложняется.

В реальных проектах написание сотен строк в день - это режим стартапа, причем на "нулевом цикле". Достаточно быстро программист приходит к естественной норме десятков строк в день, остальное время занимает понимание текущего потока проблем, поиск ошибок, интеграция и стабилизация. Хороший программист минимизирует объем порождаемого кода. Нужно ли включать БЯМ для написания 50 строк в день - вопрос.

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

Напоследок накину немного философского. Евангелисты любят упоминать, что человеческий мозг и БЯМы работают на одних и тех же принципах. Часто выясняется, что курса "Аналоговые ЭВМ" на их потоке уже не было, что несколько удручает. Еще более простой вопрос на примере несуществующей (пока?) телепортации: "Человек на входе телепортера и на выходе - это одна и та же личность?"

Теги:
Всего голосов 3: ↑2 и ↓1+2
Комментарии6

Вклад авторов