LLM Fine-Tune

На текущий момент все популярные провайдеры сервисов LLM используют fine-tune с помощью файлов в формате jsonl, в которых описаны входы и выходы модели, с небольшими вариациями, например для Gemini, OpenAI, формат немного отличается.

После загрузки специально сформированного jsonl файла, начинается процесс специализации LLM модели на указанном датасете, для всех текущих известных провайдеров LLM сервисов эта услуга платная.

Для fine-tune на локальной машине с использованием ollama, я рекомендую опираться на подробное видео от YouTube канала Tech With Tim – EASIEST Way to Fine-Tune a LLM and Use It With Ollama:
https://www.youtube.com/watch?v=pTaSDVz0gok

Пример Jupyter ноутбука с подготовкой jsonl датасета из экспорта всех сообщений Telegram и запуска процесса локального fine-tune, доступен здесь:
https://github.com/demensdeum/llm-train-example

React Native краткий обзор

React Native зарекомендовал себя как мощный инструмент для кроссплатформенной разработки мобильных и веб-приложений. Он позволяет создавать нативные приложения для Android и iOS, а также веб-приложения, используя единую кодовую базу на JavaScript/TypeScript.

Основы Архитектуры и Разработки

В основе архитектуры React Native лежат нативные биндинги из JavaScript/TypeScript. Это означает, что основная бизнес-логика и вёрстка приложения пишутся на JavaScript или TypeScript. Когда требуется доступ к специфическому нативному функционалу (например, камере устройства или GPS), используются эти нативные биндинги, которые позволяют вызывать код, написанный на Swift/Objective-C для iOS или Java/Kotlin для Android.

Важно отметить, что результирующие платформы могут различаться по функционалу. Например, определённый функционал может быть доступен только для Android и iOS, но не для Web, или наоборот, в зависимости от нативных возможностей платформы.

Конфигурация и Обновления

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

Особенности Разработки и Оптимизации

React Native может генерировать в отдельные папки результирующие проекты для конкретных платформ (например, папки android и ios). Это позволяет разработчикам, при необходимости, патчить файлы результирующих проектов вручную для тонкой оптимизации или специфических настроек, что особенно полезно для сложных приложений, требующих индивидуального подхода к производительности.

Для типовых и простых приложений часто достаточно использовать Expo бандл со встроенными нативными биндингами. Однако, если приложение обладает сложным функционалом или требует глубокой кастомизации, рекомендуется использовать кастомные сборки React Native.

Удобство Разработки и Обновления

Одним из ключевых преимуществ React Native является поддержка hot reload для TypeScript/JavaScript кода во время разработки. Это значительно ускоряет процесс разработки, так как изменения кода моментально отображаются в приложении, позволяя разработчику видеть результат в реальном времени.

Также React Native поддерживает “тихие” обновления (silent update) в обход процессов ревью Google Play и Apple App Store, но это применимо только к TypeScript/JavaScript коду. Это позволяет оперативно выпускать исправления ошибок или небольшие обновления функционала без необходимости проходить полный цикл публикации через магазины приложений.

Важно понимать, что TS/JS код биндится на конкретную версию нативных зависимостей с помощью фингерпринтинга, что обеспечивает согласованность между JavaScript/TypeScript частью и нативной частью приложения.

Использование LLM в Разработке

Хотя кодогенерация с помощью LLM (Large Language Models) возможна, её пригодность не всегда высока из-за потенциально устаревших датасетов, на которых обучались модели. Это означает, что сгенерированный код может не соответствовать последним версиям React Native или лучшим практикам.

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

Pixel Perfect: Миф или реальность в эпоху декларативности?

В мире разработки интерфейсов существует расхожее понятие – “pixel perfect вёрстка”. Оно подразумевает максимально точное воспроизведение дизайн-макета до мельчайшего пикселя. Долгое время это было золотым стандартом, особенно в эру классического веб-дизайна. Однако с приходом декларативной вёрстки и стремительным ростом разнообразия устройств, принцип “pixel perfect” становится всё более эфемерным. Попробуем разобраться, почему.

Императивный WYSIWYG vs. Декларативный Код: В чём разница?

Традиционно многие интерфейсы, особенно десктопные, создавались с помощью императивных подходов или WYSIWYG (What You See Is What You Get) редакторов. В таких инструментах дизайнер или разработчик напрямую манипулирует элементами, располагая их на холсте с точностью до пикселя. Это похоже на работу с графическим редактором – вы видите, как ваш элемент выглядит, и можете точно его позиционировать. В этом случае достижение “pixel perfect” было вполне реальной целью.

Однако современная разработка всё чаще опирается на декларативную вёрстку. Это означает, что вы не говорите компьютеру “помести эту кнопку сюда”, а описываете, что вы хотите получить. Например, вместо того чтобы указывать конкретные координаты элемента, вы описываете его свойства: “эта кнопка должна быть красной, иметь отступы 16px со всех сторон и находиться в центре контейнера”. Фреймворки вроде React, Vue, SwiftUI или Jetpack Compose как раз и используют этот принцип.

Почему “Pixel Perfect” не работает с декларативной вёрсткой для множества устройств

Представьте себе, что вы создаёте приложение, которое должно одинаково хорошо выглядеть на iPhone 15 Pro Max, Samsung Galaxy Fold, iPad Pro и телевизоре с разрешением 4K. Каждое из этих устройств имеет разное разрешение экрана, плотность пикселей, соотношение сторон и физические размеры.

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

* Адаптивность и Отзывчивость: Основная цель декларативной вёрстки — создать адаптивные и отзывчивые интерфейсы. Это значит, что ваш интерфейс должен автоматически подстраиваться под размер и ориентацию экрана, не ломаясь и сохраняя читаемость. Если бы мы стремились к “pixel perfect” на каждом устройстве, нам пришлось бы создавать бесчисленное количество вариантов одного и того же интерфейса, что полностью нивелирует преимущества декларативного подхода.
* Плотность Пикселей (DPI/PPI): Устройства имеют разную плотность пикселей. Один и тот же элемент, имеющий размер 100 “виртуальных” пикселей, на устройстве с высокой плотностью будет выглядеть гораздо меньше, чем на устройстве с низкой плотностью, если не учитывать масштабирование. Декларативные фреймворки абстрагируются от физических пикселей, работая с логическими единицами.
* Динамический Контент: Контент в современных приложениях часто бывает динамическим – его объём и структура могут меняться. Если бы мы жёстко привязывались к пикселям, любое изменение текста или изображения привело бы к “разваливанию” макета.
* Различные Платформы: Помимо разнообразия устройств, существуют и разные операционные системы (iOS, Android, Web, Desktop). Каждая платформа имеет свои гайдлайны по дизайну, стандартные элементы управления и шрифты. Попытка сделать абсолютно идентичный, “pixel perfect” интерфейс на всех платформах привела бы к неестественному виду и плохому пользовательскому опыту.

Старые Подходы Не Ушли, А Эволюционировали

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

* Нативные Интерфейсные Файлы: Для iOS это были XIB/Storyboards, для Android – XML-файлы разметки. Эти файлы представляют собой pixel-perfect WYSIWYG верстку, которая затем отображается в рантайме также как и в редакторе. Этот подход никуда не исчез, он продолжает развиваться, интегрируясь с современными декларативными фреймворками. Например, SwiftUI в Apple и Jetpack Compose в Android ступили на путь чисто декларативного кода, но при этом сохранили возможность использовать классическую верстку.
* Гибридные Решения: Часто в реальных проектах используется комбинация подходов. Например, базовая структура приложения может быть реализована декларативно, а для специфических, требующих точного позиционирования элементов, могут применяться более низкоуровневые, императивные методы или же подключаться нативные компоненты, разработанные с учётом специфики платформы.

От Монолита к Адаптивности: Как Эволюция Устройств Сформировала Декларативную Вёрстку

Мир цифровых интерфейсов претерпел колоссальные изменения за последние десятилетия. От стационарных компьютеров с фиксированными разрешениями мы пришли к эпохе экспоненциального роста разнообразия пользовательских устройств. Сегодня наши приложения должны одинаково хорошо работать на:

* Смартфонах всех форм-факторов и размеров экрана.
* Планшетах с их уникальными режимами ориентации и разделенного экрана.
* Ноутбуках и десктопах с различными разрешениями мониторов.
* Телевизорах и медиацентрах, управляемых дистанционно. Примечательно, что даже для телевизоров, пульты которых могут быть простыми, как Apple TV Remote с минимумом кнопок, или наоборот, перегруженными множеством функций, современные требования к интерфейсам таковы, что код не должен требовать специфической адаптации под эти особенности ввода. Интерфейс должен работать “как бы сам собой”, без дополнительного описания того, “как” именно взаимодействовать с конкретным пультом.
* Умных часах и носимых устройствах с минималистичными экранами.
* Шлемах виртуальной реальности (VR), требующих совершенно нового подхода к пространственному интерфейсу.
* Устройствах дополненной реальности (AR), накладывающих информацию на реальный мир.
* Автомобильных информационно-развлекательных системах.
* И даже бытовой технике: от холодильников с сенсорными экранами и стиральных машин с интерактивными дисплеями до умных духовок и систем “умного дома”.

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

Классический Подход: Бремя Поддержки Отдельных Интерфейсов

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

* Разработка под iOS часто требовала использования Storyboards или XIB-файлов в Xcode, написания кода на Objective-C или Swift.
* Для Android создавались XML-файлы разметки и код на Java или Kotlin.
* Веб-интерфейсы верстались на HTML/CSS/JavaScript.
* Для C++ приложений на различных десктопных платформах использовались свои специфические фреймворки и инструментарии:
* В Windows это были MFC (Microsoft Foundation Classes), Win32 API с ручной отрисовкой элементов или с использованием ресурсных файлов для диалоговых окон и элементов управления.
* В macOS применялись Cocoa (Objective-C/Swift) или старые Carbon API для прямого управления графическим интерфейсом.
* В Linux/Unix-подобных системах часто использовались библиотеки вроде GTK+ или Qt, которые предоставляли свой набор виджетов и механизмы для создания интерфейсов, нередко через XML-подобные файлы разметки (например, .ui файлы в Qt Designer) или прямое программное создание элементов.

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

Декларативная Вёрстка: Единый Язык для Разнообразия

Именно в ответ на это стремительное усложнение и появилась декларативная вёрстка как доминирующая парадигма. Фреймворки вроде React, Vue, SwiftUI, Jetpack Compose и других представляют собой не просто новый способ написания кода, а фундаментальный сдвиг в мышлении.

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

Это стало возможно благодаря следующим ключевым преимуществам:

1. Абстракция от Деталей Платформы: Декларативные UI фреймворки специально разработаны, чтобы забыть о низкоуровневых деталях отрисовки и специфике каждой платформы. Разработчик описывает компоненты и их взаимосвязи на более высоком уровне абстракции, используя единый, переносимый код.
2. Автоматическая Адаптация и Отзывчивость: Фреймворки берут на себя ответственность за автоматическое масштабирование, изменение макета и адаптацию элементов под различные размеры экранов, плотности пикселей и методы ввода. Это достигается за счёт использования гибких систем компоновки, таких как Flexbox или Grid, и концепций, подобных “логическим пикселям” или “dp” (density-independent pixels).
3. Согласованность Пользовательского Опыта: Несмотря на внешние различия, декларативный подход позволяет поддерживать единую логику поведения и взаимодействия по всему семейству устройств. Это упрощает процесс тестирования и обеспечивает более предсказуемый пользовательский опыт.
4. Ускорение Разработки и Снижение Затрат: С одним и тем же кодом, способным работать на множестве платформ, значительно снижаются время и стоимость разработки и поддержки. Команды могут сосредоточиться на функциональности и дизайне, а не на многократном переписывании одного и того же интерфейса.
5. Готовность к Будущему: Способность абстрагироваться от специфики текущих устройств делает декларативный код более устойчивым к появлению новых типов устройств и форм-факторов. Фреймворки могут быть обновлены для поддержки новых технологий, а ваш уже написанный код получит эту поддержку относительно бесшовно.

Заключение

Декларативная вёрстка — это не просто модное веяние, а необходимый эволюционный шаг, вызванный бурным развитием пользовательских устройств, включая и сферу интернета вещей (IoT) и умной бытовой техники. Она позволяет разработчикам и дизайнерам создавать сложные, адаптивные и единообразные интерфейсы, не утопая в бесконечных специфических реализациях для каждой платформы. Переход от императивного контроля над каждым пикселем к декларативному описанию желаемого состояния — это признание того, что в мире будущего интерфейсы должны быть гибкими, переносимыми и интуитивно понятными вне зависимости от того, на каком экране они отображаются.

Программистам, дизайнерам и пользователям необходимо научиться жить в этом новом мире. Лишние детали “pixel perfect” дизайна, привязанные к конкретному устройству или разрешению, приводят к ненужным временным затратам на разработку и поддержку. Более того, такие жёсткие макеты могут просто не отработать на устройствах с нестандартными интерфейсами, таких как телевизоры с ограниченным вводом, VR- и AR-шлемы, а также другие устройства будущего, о которых мы сегодня ещё даже не догадываемся. Гибкость и адаптивность – вот ключи к созданию успешных интерфейсов в современном мире.

Raiden Video Ripper 1.0.2.0

Новая версия RaidenVideoRipper – 1.0.2.0
Добавлена поддержка темной темы для Windows 11.
Raiden Video Ripper это приложение для простой нарезки видео в форматы webm, gif.

RaidenVideoRipper 1.0.2.0 UI

Пожалуйста, посетите страницу “Релизы”, чтобы быть в курсе последних выпусков и обновлений:
https://github.com/demensdeum/RaidenVideoRipper/releases

Почему у программистов ничего не получается даже с нейросетями

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

Полная зависимость от LLM вместо понимания

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

Отсутствие контекста и устаревшие практики

Нейросети генерируют код обобщённо. Они не учитывают специфику вашей платформы, версии библиотек, ограничений окружения или архитектурных решений проекта. То, что сгенерировано, часто выглядит правдоподобно, но не имеет ничего общего с реальным, поддерживаемым кодом. Даже простые рекомендации могут не работать, если они относятся к устаревшей версии фреймворка или используют подходы, давно признанные неэффективными или небезопасными. Модели не понимают контекст — они опираются на статистику. Это означает, что ошибки и антипаттерны, популярные в открытом коде, будут воспроизводиться снова и снова.

Избыточность, неэффективность и отсутствие профилирования

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

Нейросеть не проводит профилирование, не учитывает ограничения CPU и GPU, не заботится об утечках памяти. Она не анализирует, насколько эффективно выполняется код на практике. Оптимизация — это по-прежнему ручная работа, требующая анализа и экспертизы. Без неё приложения становятся медленными, нестабильными и ресурсоёмкими, даже если выглядят «правильно» с точки зрения структуры.

Уязвимости и угроза безопасности

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

Закон Парето и суть недоработки

С нейросетями ярко работает закон Парето: 80% результата достигается за счёт 20% усилий. Модель может сгенерировать большое количество кода, создать основу проекта, раскидать структуру, оформить типы, подключить модули. Однако всё это может оказаться устаревшим, несовместимым с текущими версиями библиотек или фреймворков, и потребовать значительной ручной доработки. Автоматизация здесь работает скорее как черновик, который нуждается в проверке, переработке и адаптации под конкретные реалии проекта.

Осторожный оптимизм

Тем не менее, будущее выглядит обнадёживающе. Постоянное обновление обучающих датасетов, интеграция с актуальной документацией, автоматизированные проверки архитектуры, соответствия паттернам проектирования и безопасности — всё это может кардинально изменить правила игры. Возможно, через несколько лет мы действительно сможем писать код быстрее, безопаснее и эффективнее, полагаясь на LLM как на настоящего технического соавтора. Но пока — увы — многое приходится проверять, переписывать и дорабатывать вручную.

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

Gingerita Prototype Windows

Представляю вашему вниманию форк текстового редактора Kate под названием Gingerita. Почему форк, зачем, какая цель? Банально хочу добавить тот функционал который нужен мне в работе, чтобы при этом не ждать исправления, добавления фичей от команды Kate, или принятия моих исправлений в main ветку.
На текущий момент доступна версия прототип для Windows, практически ванильная версия Kate с минимальными изменениями. Для Gingerita я разработал два плагина – просмоторщик изображений прямо из редактора и встроенный браузер, для отладки своих веб проектов или для взаимодействия с ИИ помощниками такими как ChatGPT.

Версию для Windows можно опробовать по ссылке ниже:
https://github.com/demensdeum/Gingerita/releases/tag/prototype

Поддержка продуктов Demensdeum

Добро пожаловать на страницу поддержки!

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

Как связаться с нами:
support@demensdeum.com

Мы стараемся отвечать на обращения в течение 3-5 рабочих дней.

Что указать в письме:

Название продукта
Версию (если известна)
Подробное описание проблемы
Скриншоты или видео (если возможно)
Устройство и операционную систему, на которой возникла проблема

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

С уважением,
Команда Demensdeum

Vibe-кодерские трюки: почему LLM пока не работают с SOLID, DRY и CLEAN

С развитием больших языковых моделей (LLM), таких как ChatGPT, всё больше разработчиков используют их для генерации кода, проектирования архитектуры и ускорения интеграции. Однако при практическом применении становится заметно: классические принципы архитектуры — SOLID, DRY, CLEAN — плохо уживаются с особенностями кодогенерации LLM.

Это не значит, что принципы устарели — напротив, они прекрасно работают при ручной разработке. Но с LLM подход приходится адаптировать.

Почему LLM не справляются с архитектурными принципами

Инкапсуляция

Инкапсуляция требует понимания границ между частями системы, знания о намерениях разработчика, а также следования строгим ограничениям доступа. LLM же часто упрощают структуру, делают поля публичными без причины или дублируют реализацию. Это делает код более уязвимым к ошибкам и нарушает архитектурные границы.

Абстракции и интерфейсы

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

DRY (Don’t Repeat Yourself)

LLM не стремятся минимизировать повторяющийся код — напротив, им проще дублировать блоки, чем выносить общую логику. Хотя они могут предложить рефакторинг по запросу, по умолчанию модели склонны генерировать «самодостаточные» фрагменты, даже если это приводит к избыточности.

CLEAN Architecture

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

Что работает лучше при работе с LLM

WET вместо DRY
Подход WET (Write Everything Twice) оказывается практичнее в работе с LLM. Дублирование кода не требует от модели удержания контекста, а значит — результат предсказуемее и легче исправляется вручную. Это также снижает вероятность появления неочевидных связей и багов.

Кроме того, дублирование помогает компенсировать короткую память модели: если определённый фрагмент логики встречается в нескольких местах, LLM с большей вероятностью будет его учитывать при дальнейшей генерации. Это упрощает сопровождение и увеличивает устойчивость к “забыванию”.

Простые структуры вместо инкапсуляции

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

Упрощённая архитектура

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

Интеграция SDK — вручную надёжнее

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

Почему принципы всё же работают — но при ручной разработке

Важно понимать, что сложности с SOLID, DRY и CLEAN касаются именно кодогенерации через LLM. Когда разработчик пишет код вручную, эти принципы продолжают демонстрировать свою ценность: снижают связанность, упрощают сопровождение, повышают читаемость и гибкость проекта.

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

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

Вывод

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

Принципы SOLID, DRY и CLEAN по-прежнему актуальны — но наилучший эффект они дают в руках человека. При работе с LLM разумно использовать упрощённый, практичный стиль, позволяющий получать надёжный и понятный код, который легко доработать вручную. А где LLM забывает — дублирование кода помогает ему вспомнить.

Demens TV Heads NFT

Хочу поделиться своим новым проектом — NFT-коллекцией “Demens TV Heads”.

Это серия цифровых арт-работ, в них отражены люди разных характеров и профессий, в стиле логотипа DemensDeum.
Первая работа – Fierce “Грозный” это стилизованный автопортрет.

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

Каждая работа существует не только в Ethereum-блокчейне, но и доступна на сайте DemensDeum и в GitHub-репозитории, вместе с метаданными.

Если интересно — посмотреть или просто оценить визуально, буду рад:
https://opensea.io/collection/demens-tv-heads
https://github.com/demensdeum/demens-tv-heads-collection
https://demensdeum.com/collections/demens-tv-heads/fierce.png
https://demensdeum.com/collections/demens-tv-heads/fierce-metadata.txt

Суперпрограммист

Кто он — этот загадочный, эфемерный, почти мифический Суперпрограммист? Человек, чей код компилируется с первого раза, запускается с полпинка и сразу уходит в прод. Легенда, передаваемая в байтах от сеньора к джуну. Тот, кто пишет баги специально, чтобы другим было не скучно. Давайте честно, с теплом и иронией разберёмся, какими сверхспособностями он должен обладать, чтобы носить этот цифровой плащ.

1. Пишет на C/C++ без единой уязвимости
buffer overflow? never heard of it.
У Суперпрограммиста в C++ нет неинициализированных переменных — они сами инициализируются от уважения. Он пишет new char[256], и компилятор молча добавляет проверку границ. Где другие ставят брейкпоинт — он ставит взгляд. И баг исчезает.

2. Пишет фичи без багов и тестирования
Он не нуждается в тестах. Его код сам себя тестирует по ночам, когда он спит (хотя… спит ли он?). Любая строка — это финальная стабильная версия, сразу с поддержкой 12 языков и Accessibility уровня NASA. А если баг всё же попался — значит, Вселенная тестирует его.

3. Работает быстрее, чем AI
Пока ChatGPT печатает “Какой хороший вопрос!”, Суперпрограммист уже зарелизил новую OS, портировал её на тостер и задокументировал всё в Markdown с диаграммами. Он не спрашивает StackOverflow — он его поддерживает своими вопросами из будущего. GPT учится на его коммитах.

4. Понимает чужой код лучше, чем автор
“Я, конечно, это писал… Но я не понимаю, как это работает.” — обычный автор.
“О, это из-за рекурсивного вызова в строке 894, который завязан на побочный эффект в Regex-фильтре. Умно.” — Суперпрограммист, не моргнув.
Он читает Perl с первой попытки, понимает аббревиатуры в названиях переменных, а баги улавливает по вибрации курсора.

5. Пишет на ассемблере кроссплатформенный код
Зачем писать на Rust, если можно на чистом x86, ARM и RISC-V сразу, с флагом “работает везде”? У него своя таблица опкодов. Даже CPU задумываются перед тем, как испортить его инструкции. Он не оптимизирует — он трансцендентирует.

6. Отвечает на вопросы о сроках вплоть до секунды
“Когда будет готово?”
“Через 2 часа, 17 минут и 8 секунд. И да, это с учётом багов, перекура и одного философского вопроса в чатике.”
Если кто-то просит сделать быстрее — он просто перестраивает пространство-время через make -j∞.

7. Реверсит и чинит проприетарные фреймворки
Проприетарный SDK отвалился, API без документации, всё шифруется Base92 и кашляет SEGFAULT’ами? Для Суперпрограммиста это обычный вторник. Он откроет бинарник, вдохнёт HEX, и спустя час уже будет патч с фиксом, улучшениями производительности и добавленным dark mode.

8. Сам себе дизайнер и UX-специалист
UI у него выходит такой, что люди плачут от красоты, а кнопки угадываются интуицией. Даже кошки справляются — проверено. Он не рисует интерфейс — он открывает его внутреннюю суть, как скульптор в мраморе. Каждое нажатие вызывает восторг.

9. Проводит маркетинговые исследования между коммитами
Между git push и coffee break он успевает собрать аналитику рынка, построить воронку продаж и переосмыслить стратегию монетизации. По выходным тестирует гипотезы. У него A/B тесты запускаются автоматически, когда он открывает ноутбук.

10. Повторяет Microsoft в одиночку
Что для корпораций 10 лет и тысяча инженеров, для него — вечер пятницы и хорошая пицца. Windows 11? Сделал Windows 12. Office? Уже есть. Excel? Работает на голосовом управлении и помогает планировать отпуск. Всё работает лучше и весит меньше.

11. Разворачивает и поддерживает инфраструктуру на 1 миллион пользователей
Его домашний NAS — это Kubernetes-кластер. Мониторинг? Grafana с мемами. Он разворачивает API быстрее, чем некоторые успевают открыть Postman. У него всё задокументировано, автоматизировано и надёжно как советский чайник.

12. Техподдержка не требуется
Пользователи его ПО не жалуются. Они просто используют его с благоговением. FAQ? Не нужен. Туториалы? Интуиция подскажет. Он — единственный разработчик, у кого кнопка “Help” ведёт на страницу благодарности.

13. Не спит, не ест, не отвлекается
Он питается кофеином и чистым желанием писать код. Вместо сна — рефакторинг. Вместо еды — debian packages. Его жизненный цикл — это непрерывный цикл разработки. CI/CD — это не pipeline, это стиль жизни.

14. Общается с заказчиками без боли
“Нам надо сделать Uber, но только лучше, за два дня.” — “Смотрите: вот roadmap, вот риски, вот MVP. И давайте вы сначала определитесь с целями.”
Он умеет говорить “нет” так, что заказчик отвечает: “Спасибо, теперь я понял, чего я хочу.”

15. Моментально программирует ядерные реакторы
Сколько тепла выделяется при расщеплении ядра урана? Суперпрограммист знает. И умеет это закодить в Rust, C, Swift, даже в Excel. Его реактор не только безопасен — он ещё и обновляется по OTA.

16. Обладает знаниями во всех возможных областях
Философия, физика, налоговая отчётность Монголии — всё у него в голове. Он участвует в викторинах, где сам себе ведущий. Если чего-то не знает — просто временно выключил память, чтобы освободить место под новые знания. Сейчас вернёт.

17. Знает все алгоритмы и паттерны проектирования
Не надо объяснять ему, как работает A*, Dijkstra или Singleton. Он сам их придумал. С ним паттерны ведут себя правильно. Даже антипаттерны исправляются сами — от стыда.

18. Работал в Apple, Google и ушёл от скуки
Он был везде: Apple, Google, NASA, IKEA (тестировал интерфейс шкафов). Потом понял, что уже слишком хорош, и ушёл разрабатывать бесплатные open-source проекты ради удовольствия. Деньги ему не нужны, потому что:

19. У него пресид биткоина и он — Сатоши Накамото
Да, это он. Просто не говорит. Все кошельки с миллионами BTC на самом деле у него на флешке, замурованной в бетон. А пока он пишет backend для фермерского кооператива в глубинке, потому что “интересно же было попробовать Kotlin Multiplatform”.

Заключение: немного серьёзности
На самом деле, программисты — обычные люди.
Мы ошибаемся. Мы устаём. Иногда мы настолько уверены в себе, что не видим очевидного — и именно тогда совершаются самые дорогие ошибки в истории IT.

Поэтому стоит помнить:

* Знать всё невозможно — но важно знать, где искать.
* Работа в команде — это не слабость, а путь к лучшему решению.
* Инструменты, которые нас оберегают — не “костыли”, а броня.
* Спрашивать — нормально. Сомневаться — правильно. Ошибаться — неизбежно. Учиться — необходимо.
* Ирония — наш щит. Код — наше оружие. Ответственность — наш компас.

А легенды про Суперпрограммиста — это напоминание, что все мы иногда стремимся к невозможному. И именно в этом — настоящая магия программирования.

Почему документация — ваш лучший друг

(и как не оказаться гуру, чьи советы перестают работать после обновления)

“Apps may only use public APIs and must run on the currently shipping OS.” Apple App Review Guidelines

Если вы когда-либо начинали работу с новым фреймворком и ловили себя на мысли: “Сейчас всё сам пойму, документация — это для зануд” — вы точно не одиноки. У многих разработчиков срабатывает естественный инстинкт: сначала попробовать, и только потом — читать. Это нормально.

Но именно на этом этапе можно легко свернуть с правильного пути и оказаться в ситуации, где код работает… но только сегодня, и только “у меня”.

Почему просто “разобраться самому” — недостаточно?

Фреймворки, особенно закрытые и проприетарные, сложны и многослойны. В них много скрытой логики, оптимизаций и особенностей реализации, которые:

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

Когда вы действуете “по наитию”, можно легко построить архитектуру на случайных наблюдениях, вместо опоры на чётко описанные правила. Это приводит к тому, что код становится уязвимым к обновлениям и edge-кейсам.

Документация — это не ограничение, а опора

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

* стабильность;
* поддержку;
* предсказуемое поведение.

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

Эксперименты? Конечно. Но в рамках правил.
Любопытство — суперсила разработчика. Исследовать, пробовать нестандартное, тестировать границы — всё это необходимо. Но здесь есть важное “но”:

Экспериментировать нужно в рамках документации и best practices.

Документация — это не тюрьма, а карта. Она показывает, какие возможности действительно запланированы и поддерживаются. Именно такие эксперименты — не только полезны, но и безопасны.

Осторожно: Гуру

Иногда вы можете столкнуться с настоящими “экспертами”:

* они проводят курсы,
* выступают на конференциях,
* пишут книги и блоги,
* делятся “своим подходом” к фреймворку.

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

Такие “эмпирические паттерны” могут:

* работать только на конкретной версии фреймворка;
* быть уязвимыми к обновлениям;
* ломаться в непредсказуемых ситуациях.

Гуру — это круто, когда они уважают мануалы. В противном случае — их советы нужно фильтровать через официальную документацию.

Немного SOLID

Три идеи из принципов SOLID особенно актуальны здесь:

* Open/Closed Principle: расширяй поведение через публичные API, не лезь во внутренности.
* Liskov Substitution Principle: не полагайся на реализацию, полагайся на контракт. Нарушишь — всё сломается при замене реализации.
* Dependency Inversion: Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба типа должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

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

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

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

А если баг?

Иногда бывает, что вы всё сделали правильно, но работает некорректно. Это бывает — фреймворки не идеальны. В таком случае:

* Соберите минимальный воспроизводимый пример.
* Убедитесь, что вы используете только задокументированные API.
* Отправьте баг-репорт — вас точно поймут и, скорее всего, помогут.

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

Как выжать максимум из фреймворка

* Читайте документацию. Серьёзно.
* Следуйте гайдам и рекомендациям от авторов.
* Экспериментируйте — но в пределах описанного.
* Проверяйте советы (даже самых известных спикеров!) через мануал.
* Отлаживайте баги с минимальными кейсами и уважением к контракту.

Заключение

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

Так что: доверяйте, но проверяйте. И да, читайте мануалы. Они — ваша суперспособность.

Источники

https://developer.apple.com/app-store/review/guidelines/
https://en.wikipedia.org/wiki/SOLID
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/RTFM

Cube Art Project 2

Встречайте — Cube Art Project 2

Вторая версия воксельного редактора, полностью переписанная на чистом JavaScript без WebAssembly.
Лёгкий, быстрый и запускается прямо в браузере — ничего лишнего.

Это эксперимент: кубики, цвет, свобода и немного медитативной 3D-геометрии.
Можно менять цвета с помощью RGB-слайдеров, сохранять и загружать сцены, перемещаться по пространству и просто играться.

Управление:
— WASD — перемещение камеры
— Мышь — вращение
— GUI — настройка цвета

Онлайн:
https://demensdeum.com/software/cube-art-project-2/

Исходники на GitHub:
https://github.com/demensdeum/cube-art-project-2

Проект написан на чистом JavaScript с использованием Three.js.
Без фреймворков, без сборщиков, без WebAssembly — только WebGL, шейдеры и немного любви к пиксельной геометрии.

Сцены можно сохранять и загружать — создавайте свои миры, сохраняйте как JSON, делитесь или возвращайтесь позже к доработке.

Безопасность Docker: почему запуск от root — это плохая идея

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

Почему Docker работает от root?

Docker использует возможности ядра Linux: cgroups, namespaces, iptables, mount, networking и другие системные функции. Эти операции доступны только суперпользователю.

Вот почему:
* демон dockerd запускается от root,
* команды docker передаются этому демону.

Это упрощает работу и даёт полный контроль над системой, но вместе с этим и открывает потенциальные уязвимости.

Чем это опасно: container breakout, CVE, RCE

Container breakout

При слабой изоляции злоумышленник может использовать chroot или pivot_root для выхода на хост.

Примеры реальных атак:

* CVE-2019-5736 — уязвимость в runc, позволяла перезаписать приложение и выполнить код на хосте.
* CVE-2021-3156 — уязвимость в sudo, позволяла получить root внутри контейнера и выбраться наружу.

RCE (Remote Code Execution)

Если приложение в контейнере уязвимо и запускается от root, RCE = полный контроль над хостом.

Rootless Docker: решение проблемы

Чтобы минимизировать эти риски, в Docker появился rootless-режим. В этом режиме и демон, и контейнеры запускаются от имени обычного пользователя, без каких-либо root-привилегий. Это означает, что даже если злоумышленник получит контроль над контейнером, он не сможет навредить хостовой системе.
Есть и ограничения: нельзя использовать порты ниже 1024 (например, 80 и 443), недоступен режим –privileged, а также некоторые сетевые режимы. Однако в большинстве сценариев разработки и CI/CD rootless Docker прекрасно справляется со своей задачей и значительно повышает уровень безопасности.

Исторически запуск от root — антипаттерн

В мире UNIX/Linux с самого начала действует принцип наименьших привилегий. Чем меньше прав у процесса — тем меньше вреда он может нанести. Docker изначально требовал root-доступ, но сегодня это считается потенциальной угрозой.

Источники

https://docs.docker.com/engine/security/rootless/
https://rootlesscontaine.rs/

Неочевидная проблема Docker-контейнеров: скрытые уязвимости

Неочевидная проблема Docker-контейнеров: скрытые уязвимости

Что такое “Dependency Hell” (DH)?

“Dependency Hell” (DH) — это термин, обозначающий проблему, возникающую при управлении зависимостями в программном обеспечении. Основные её причины заключаются в конфликте версий, сложностях интеграции различных библиотек и необходимости поддерживать совместимость между ними. В DH входят следующие аспекты:

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

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

Как борьба с DH привела к созданию Docker?

В попытке решить проблемы DH разработчики искали способы создать изолированные и стабильные окружения для приложений. Docker стал ответом на этот вызов. Контейнеризация позволяет:

– Изолировать окружение: Все зависимости и библиотеки упаковываются вместе с приложением, что гарантирует стабильную работу в любом месте, где установлен Docker.
– Упрощать развертывание: Разработчик может один раз настроить окружение и использовать его для развертывания на любых серверах без дополнительных настроек.
– Минимизировать конфликты: Поскольку каждое приложение работает в собственном контейнере, риск конфликтов между зависимостями различных проектов существенно снижается.

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

Проблема устаревших зависимостей в Docker

Несмотря на все преимущества Docker, появилось новое направление проблем — устаревание зависимостей. Это происходит по нескольким причинам:

1. Контейнер застывает во времени

При создании Docker-образа фиксируется определённое состояние всех пакетов и библиотек. Даже если после сборки в базовом образе (например, `ubuntu:20.04`, `python:3.9`, `node:18-alpine`) обнаруживаются уязвимости или выпускаются новые версии, контейнер продолжает работать с изначально установленными версиями. Если образ не пересобирать, приложение может годами работать с устаревшими и потенциально уязвимыми компонентами.

2. Отсутствие автоматических обновлений

В отличие от традиционных серверов, где можно настроить автоматическое обновление пакетов через системные менеджеры (например, `apt upgrade` или `npm update`), контейнеры не обновляются автоматически. Обновление происходит только при пересборке образа, что требует дисциплины и регулярного контроля.

3. Фиксированные версии зависимостей

Чтобы обеспечить стабильность, разработчики часто фиксируют версии зависимостей в файлах вроде `requirements.txt` или `package.json`. Такой подход предотвращает неожиданные изменения, но одновременно замораживает состояние зависимостей, даже если в них впоследствии обнаруживаются ошибки или уязвимости.

4. Использование устаревших базовых образов

Базовые образы, выбранные для контейнеров, тоже могут со временем устаревать. Например, если приложение построено на образе `node:16`, а разработчики уже перешли на `node:18` из-за улучшений и исправлений, то ваше окружение останется с устаревшей версией, даже если внутри кода всё работает корректно.

Как избежать проблем с устаревшими зависимостями?

Включите в процесс CI/CD регулярные проверки на наличие устаревших зависимостей и уязвимостей:

– Для Python:

pip list --outdated

– Для Node.js:

npm outdated

– Используйте инструменты для анализа уязвимостей, например, `trivy`:

trivy image my-app

Следить за обновлениями базовых образов

Подписывайтесь на обновления базовых образов в Docker Hub или соответствующих репозиториях на GitHub, чтобы своевременно узнавать о критических исправлениях и обновлениях.

Заключение

Проблема Dependency Hell возникла не только из-за необходимости устранять уязвимости, но и как следствие сложностей в управлении и обновлении зависимостей. Docker предложил эффективное решение для борьбы с DH, обеспечив изолированные и стабильные окружения для приложений. Однако, с появлением контейнеризации возникла новая задача — необходимость регулярного обновления образов, чтобы не допустить устаревания зависимостей и появления критических уязвимостей.

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

Паттерн Builder: Поэтапное создание объекта во времени

Введение

В прошлой статье рассматривался общий случай использования паттерна Builder, но не затрагивался вариант, когда объект создается поэтапно во времени.
Паттерн Builder (Строитель) – это порождающий шаблон проектирования, который позволяет поэтапно создавать сложные объекты. Он особенно полезен, когда объект имеет много параметров или различных конфигураций. Одним из интересных примеров его использования является возможность разделения процесса создания объекта по времени.
Иногда объект нельзя создать сразу – его параметры могут становиться известными на разных этапах выполнения программы.

Пример на Python

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

import requests

def fetch_car_data():
    response = requests.get("https://api.example.com/car-info")
    return response.json()

builder = CarBuilder()

# Backend API data
car_data = fetch_car_data()
builder.set_model(car_data["model"])
builder.set_year(car_data["year"])

# User input
color = input("Car color: ")
builder.set_color(color)

gps_option = input("GPS feature? (yes/no): ").lower() == "yes"
builder.set_gps(gps_option)

car = builder.build()
print(car)

Представьте что вызов api, ввод данных происходят в разных частях приложения, или даже в разных библиотеках. Тогда использование паттерна Builder становится более очевидным, чем в простом примере выше.

Преимущества

– На выходе получается иммутабельная структура, которой не требуется хранить опциональные данные для временной сборки
– Объект собирается постепенно
– Избежание сложных конструкторов
– Код сборки объекта инкапсулируется лишь в одной сущности Builder
– Удобство понимания кода

Источники

https://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional-ebook/dp/B000SEIBB8
https://demensdeum.com/blog/2019/09/23/builder-pattern/

DemensDeum Coding Challenge #1

Стартую DemensDeum Coding Challenge #1
Приз 100 USDT
1. Надо написать рендер картинки для Windows 11 64 bit
2. Рендерить
https://demensdeum.com/logo/demens1.png
3. Картинка должна быть интегрирована в приложение
4. Графические API – Direct3D или DirectDraw
5. Выигрывает тот чье приложение получился самым малым по размеру в байтах
6. Изображение должно быть 1 в 1 попиксельно как оригинальное, сохранить цвета
7. Любые языки/фреймворки не требующие дополнительной установки -> чтобы можно было запустить сразу из приложения. Например если решение только один Python скрипт, то такое решение не подходит т.к. требуется установка Python, Pygame и запуск вручную. Хороший пример: Python скрипт завернутый вместе с Python и Pygame в exe, который запускается без дополнительных установок.
8. Сдавать в форме ссылки на публичный репозиторий с исходным кодом, инструкцией по сборке приложения. Хороший пример: проект с инструкцией по сборке в Visual Studio Community Edition

Дедлайн: 1 июня подведение итогов конкурса

Референсное решение на Zig + SDL3 + SDL3_Image:
https://github.com/demensdeum/DemensDeum-Coding-Challenge-1

Ghost Contacts

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

Приложение онлайн:
https://demensdeum.com/software/ghost-contacts/

GitHub:
https://github.com/demensdeum/GhostContacts

Почему я выбрал WordPress

Когда я задумался о создании собственного блога в 2015 году, передо мной встал вопрос: какую платформу выбрать? После долгих поисков и сравнений я остановился на WordPress. Это было не случайным выбором, а результатом анализа возможностей платформы, её преимуществ и недостатков. Сегодня я хотел бы поделиться своими мыслями и опытом использования WordPress.

Преимущества WordPress

  • Простота использования
    Одной из главных причин, почему я выбрал WordPress, является его интуитивно понятный интерфейс. Даже если вы никогда раньше не работали с CMS, освоить WordPress можно за считанные дни.
  • Огромное количество плагинов
    WordPress предоставляет доступ к тысячам бесплатных и платных плагинов. Эти расширения позволяют добавить практически любую функциональность, связанную с ведением блога, от SEO-оптимизации до интеграции социальных сетей.
  • Масштабируемость
    WordPress отлично подходит для блогов любого масштаба. Начав с простого личного блога, я знаю, что могу легко развивать его, добавляя новые функции и возможности.
  • Широкий выбор тем
    На WordPress доступно огромное количество бесплатных и платных тем, которые позволяют создать достаточно хорошо выглядящий блог в короткие сроки. Для создания индивидуального дизайна потребуется чуткая рука дизайнера.
  • SEO-дружественность
    WordPress изначально настроен на дружелюбие к поисковым системам. С помощью плагинов, таких как Yoast SEO, можно легко оптимизировать контент для улучшения его позиций в поисковой выдаче.
  • Сообщество и поддержка
    У WordPress одно из крупнейших сообществ в мире. Если у вас возникнет проблема, вы почти наверняка найдёте решение на форумах или в блогах, посвящённых платформе.
  • Поддержка мультиязычности
    Благодаря плагинам вроде WPGlobus я могу вести блог на нескольких языках, что особенно важно для работы с аудиторией из разных стран.

Недостатки WordPress

  • Уязвимость к атакам
    Популярность WordPress делает его мишенью для хакеров. Без надлежащей защиты сайт может стать жертвой атак. Однако регулярные обновления и установка плагинов безопасности помогают минимизировать риски.
  • Зависимость от плагинов
    Иногда функциональность, которую вы хотите добавить, требует установки множества плагинов. Это может замедлить работу блога и вызвать конфликты между расширениями.
  • Сложности с производительностью
    На больших блогах WordPress может начать тормозить, особенно если используется много плагинов. Для решения этой проблемы приходится оптимизировать базу данных, внедрять кэширование и использовать более мощный хостинг.
  • Стоимость некоторых функций
    Хотя базовая версия WordPress бесплатна, многие профессиональные темы и плагины стоят денег. Для получения всех возможностей иногда приходится инвестировать.

Заключение

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

Wordex — программа для скорочтения на iOS

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

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

Что такое Wordex?

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

Основные возможности Wordex

  • Режим скорочтения: текст отображается оптимизированно для быстрого восприятия. Пользователи могут регулировать скорость отображения текста в зависимости от своих потребностей.
  • Анализ прогресса: программа предоставляет подробную статистику, включая скорость чтения и динамику улучшений. Это помогает оценивать свои успехи и корректировать подход к чтению.
  • Импорт текстов: Wordex позволяет загружать собственные тексты для тренировки. Вы можете читать статьи, книги или учебные материалы прямо в приложении.
  • Интуитивно понятный интерфейс: приложение выполнено в минималистичном стиле, что делает его удобным для использования. Даже новички легко разберутся с функционалом.


Wordex Screenshot 1

Кому подойдет Wordex?

Wordex идеально подходит:

  • Студентам: которым нужно быстро читать учебные материалы и готовиться к экзаменам.
  • Бизнесменам и офисным работникам: желающим обрабатывать большой объем информации за минимальное время.
  • Любителям чтения: которые хотят читать больше книг и получать удовольствие от процесса.


Wordex Screenshot 2

Преимущества Wordex

  • Мобильность: вы можете заниматься в любом месте и в любое время благодаря приложению на iPhone или iPad.
  • Персонализация: возможность настроить отображение текста под свои потребности.


Wordex Screenshot 3

Почему стоит попробовать Wordex?

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

Заключение

Если вы хотите освоить скорочтение или улучшить существующие навыки, Wordex — отличный выбор. Простое в использовании и эффективное приложение поможет вам достичь ваших целей и сэкономить драгоценное время. Скачайте Wordex из App Store и начните тренироваться уже сегодня!

AppStore:
https://apps.apple.com/us/app/speed-reading-book-reader-app/id1462633104

Почему важен DRY

Существует множество статей на тему DRY, я рекомендую прочитать первоисточник “Программист-прагматик” за авторством Andy Hunt и Dave Thomas. Однако я всё равно вижу как у множества разработчиков вызывает вопросы данный принцип в разработке программного обеспечения.

Принцип DRY гласит о том что нам нельзя повторяться, это касается как кода, так и процессов которые мы выполняем как программисты. Пример кода который нарушает DRY:

class Client {
    public let name: String
    private var messages: [String] = []
    
    init(name: String) {
        self.name = name
    }
    
    func receive(_ message: String) {
        messages.append(message)
    }
}

class ClientController {
    func greet(client: Client?) {
        guard let client else {
            debugPrint("No client!")
            return
        }
        client.receive("Hello \(client.name)!")
    }

    func goodbye(client: Client?) {
        guard let client else {
            debugPrint("No client!!")
            return
        }
        client.receive("Bye \(client.name)!")
    }
}

Как можно увидеть в методе greet и goodbye передается опциональный инстанс класса Client, который затем нужно проверять на nil, после чего начинать работу с ним. Чтобы соблюсти метод DRY, нужно убрать повторяющуюся проверку на nil для инстанса класса. Реализовать это можно множеством путей, один из вариантов это передавать инстанс в конструктор класса, после чего необходимость в проверках отпадет.

Соблюдаем DRY с помощью специализации ClientController на единственном инстансе Client:

class Client {
    public let name: String
    private var messages: [String] = []
    
    init(name: String) {
        self.name = name
    }
    
    func receive(_ message: String) {
        messages.append(message)
    }
}

class ClientController {
    private let client: Client

    init(client: Client) {
        self.client = client
    }

    func greet() {
        client.receive("Hello \(client.name)!")
    }

    func goodbye() {
        client.receive("Bye \(client.name)!")
    }
}

Также DRY касается процессов которые происходят во время разработки программного обеспечения. Представим ситуацию при которой команде разработчиков приходится выкладывать релиз в маркет самостоятельно, отвлекая их от разработки ПО, это тоже нарушение DRY. Такая ситуация разрешается с помощью подключения CI/CD пайплайна, при котором релиз выпускается автоматически, при соблюдении определенных условий разработчиками.

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

У Стива Джобса было выражение “Строка кода, которую не пришлось писать, — это строка кода, которую вам никогда не придется дебажить.”

Источники

https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/
https://youtu.be/-msIEOGvTYM

Я помогу вам в разработке iOS для Swift или Objective-С

Рад сообщить, что теперь я предлагаю свои услуги как iOS-разработчик на Fiverr. Если вам нужна помощь в разработке качественных iOS-приложений или улучшении существующих проектов, ознакомьтесь с моим профилем:
https://www.fiverr.com/s/Q7x4kb6

Буду рад возможности поработать над вашим проектом.
Email: demensdeum@gmail.com
Telegram: https://t.me/demensdeum

Динамическая линковка Qt приложений на macOS

Сегодня я выпустил версию RaidenVideoRipper для устройств Apple с macOS и процессоров M1/M2/M3/M4 (Apple Silicon). RaidenVideoRipper это приложение для быстрого монтажа видео, которое позволяет вырезать часть видеофайла в новый файл. Также можно делать gif, экспортировать звуковую дорожку в mp3.

Далее я коротко опишу какие команды я использовал для того чтобы это осуществить. Теорию того что здесь происходит, документацию утилит, можно прочитать по следующим ссылкам:
https://www.unix.com/man-page/osx/1/otool/
https://www.unix.com/man-page/osx/1/install_name_tool/
https://llvm.org/docs/CommandGuide/llvm-nm.html
https://linux.die.net/man/1/file
https://www.unix.com/man-page/osx/8/SPCTL/
https://linux.die.net/man/1/chmod
https://linux.die.net/man/1/ls
https://man7.org/linux/man-pages/man7/xattr.7.html
https://doc.qt.io/qt-6/macos-deployment.html

Для начала установите Qt на свою macOS, также установите окружение для Qt Desktop Development. После этого соберите свой проект например в Qt Creator, далее я опишу что нужно для того чтобы зависимости с внешними динамическими библиотеками корректно отрабатывали при дистрибутизации приложения конечным пользователям.

Создайте в папке YOUR_APP.app/Contents вашего приложения директорию Frameworks, сложите в нее внешние зависимости. Для примера так выглядит Frameworks для приложения RaidenVideoRipper:

Frameworks
├── DullahanFFmpeg.framework
│   ├── dullahan_ffmpeg.a
│   ├── libavcodec.60.dylib
│   ├── libavdevice.60.dylib
│   ├── libavfilter.9.dylib
│   ├── libavformat.60.dylib
│   ├── libavutil.58.dylib
│   ├── libpostproc.57.dylib
│   ├── libswresample.4.dylib
│   └── libswscale.7.dylib
├── QtCore.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── QtCore -> Versions/Current/QtCore
│   ├── Resources -> Versions/Current/Resources
│   └── Versions
├── QtGui.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── QtGui -> Versions/Current/QtGui
│   ├── Resources -> Versions/Current/Resources
│   └── Versions
├── QtMultimedia.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── QtMultimedia -> Versions/Current/QtMultimedia
│   ├── Resources -> Versions/Current/Resources
│   └── Versions
├── QtMultimediaWidgets.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── QtMultimediaWidgets -> Versions/Current/QtMultimediaWidgets
│   ├── Resources -> Versions/Current/Resources
│   └── Versions
├── QtNetwork.framework
│   ├── Headers -> Versions/Current/Headers
│   ├── QtNetwork -> Versions/Current/QtNetwork
│   ├── Resources -> Versions/Current/Resources
│   └── Versions
└── QtWidgets.framework
    ├── Headers -> Versions/Current/Headers
    ├── QtWidgets -> Versions/Current/QtWidgets
    ├── Resources -> Versions/Current/Resources
    └── Versions

Для упрощения я распечатал только второй уровень вложенности.

Далее печатаем текущие динамические зависимости вашего приложения:

otool -L RaidenVideoRipper

Вывод для бинарика RaidenVideoRipper, который лежит в RaidenVideoRipper.app/Contents/MacOS:

RaidenVideoRipper:
	@rpath/DullahanFFmpeg.framework/dullahan_ffmpeg.a (compatibility version 0.0.0, current version 0.0.0)
	@rpath/QtMultimediaWidgets.framework/Versions/A/QtMultimediaWidgets (compatibility version 6.0.0, current version 6.8.1)
	@rpath/QtWidgets.framework/Versions/A/QtWidgets (compatibility version 6.0.0, current version 6.8.1)
	@rpath/QtMultimedia.framework/Versions/A/QtMultimedia (compatibility version 6.0.0, current version 6.8.1)
	@rpath/QtGui.framework/Versions/A/QtGui (compatibility version 6.0.0, current version 6.8.1)
	/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 2575.20.19)
	/System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Metal.framework/Versions/A/Metal (compatibility version 1.0.0, current version 367.4.0)
	@rpath/QtNetwork.framework/Versions/A/QtNetwork (compatibility version 6.0.0, current version 6.8.1)
	@rpath/QtCore.framework/Versions/A/QtCore (compatibility version 6.0.0, current version 6.8.1)
	/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
	/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/UniformTypeIdentifiers.framework/Versions/A/UniformTypeIdentifiers (compatibility version 1.0.0, current version 709.0.0)
	/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1800.101.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

Как можно увидеть у RaidenVideoRipper в зависимостях Qt и dullahan_ffmpeg. Dullahan FFmpeg это форк FFmpeg который инкапсулирует его функционал в динамическую библиотеку, с возможностью получения текущего прогресса выполнения и отмены, с помощью Си процедур.
Далее заменяйте у приложения и всех необходимых библиотек пути с помощью install_name_tool.

Команда для этого такая:

install_name_tool -change old_path new_path target

Пример использования:

install_name_tool -change /usr/local/lib/libavfilter.9.dylib @rpath/DullahanFFmpeg.framework/libavfilter.9.dylib dullahan_ffmpeg.a

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

Также бывает ошибка с путаницей зависимостей, когда у замененной вами библиотеки отсутствует символ в таблице, проверить наличие или отсутствие символа можно так:

nm -gU path

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

file path

Утилита file покажет вам к какой архитектуре принадлежит библиотека или приложение.

Также Qt требует наличия папки Plugins в папке Contents вашей директории YOUR_APP.app, скопируйте плагины из Qt в Contents. Далее проверьте работоспособность приложения, после этого можете приступать к оптимизации папки Plugins, удаляя элементы из этой папки и тестируя приложение.

Безопасность macOS

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

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

Эта инструкция работает также и для RaidenVideoRipper:

  • Отключение Gatekeeper: spctl –master-disable
  • Разрешить запуск из любых источников в Privacy & Security: Allow applications переключить на Anywhere
  • Удалить флаг карантина после скачивания с zip или dmg приложения: xattr -d com.apple.quarantine app.dmg
  • Проверите что флаг карантина (com.apple.quarantine) отсутствует: ls -l@ app.dmg
  • Дополните подтвердите запуск приложения если необходимо в Privacy & Security

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

Ссылка на сборку RaidenVideoRipper для Apple Silicon:
https://github.com/demensdeum/RaidenVideoRipper/releases/download/1.0.1.0/RaidenVideoRipper-1.0.1.0.dmg

Стабилизация видео с помощью ffmpeg

Если вы хотите стабилизировать видео и убрать дрожание камеры, инструмент `ffmpeg` предлагает мощное решение. Благодаря встроенным фильтрам `vidstabdetect` и `vidstabtransform`, можно добиться профессионального результата без использования сложных видеоредакторов.

Подготовка к работе

Прежде чем начать, убедитесь, что ваш `ffmpeg` поддерживает библиотеку `vidstab`. В Linux это можно проверить командой:

bash  
ffmpeg -filters | grep vidstab

Если библиотека не установлена, её можно добавить:

sudo apt install ffmpeg libvidstab-dev

Установка для macOS через brew:

brew install libvidstab
brew install ffmpeg

Теперь перейдём к процессу.

Шаг 1: Анализ движения

Сначала нужно провести анализ движения видео и создать файл с параметрами стабилизации.

ffmpeg -i input.mp4 -vf vidstabdetect=shakiness=10:accuracy=15 transfile=transforms.trf -f null -

Параметры:

shakiness: Уровень дрожания видео (по умолчанию 5, можно увеличить до 10 для более сложных случаев).
accuracy: Точность анализа (по умолчанию 15).
transfile: Имя файла для сохранения параметров движения.

Шаг 2: Применение стабилизации

Теперь можно применить стабилизацию, используя файл трансформаций:

ffmpeg -i input.mp4 -vf vidstabtransform=input=transforms.trf:zoom=5 output.mp4

Параметры:

input: Указывает на файл с параметрами трансформации (созданный на первом шаге).
zoom: Коэффициент масштабирования для устранения черных краев (например, 5 — автоматическое увеличение до устранения артефактов).

Автоматический анализ кода с помощью Bistr

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

Что такое Bistr?

Bistr — это утилита для анализа исходного кода, которая позволяет интегрировать локальную LLM (large language model) модель, такую как Ollama, для анализа и обработки кода. С помощью Bistr вы можете анализировать файлы на различных языках программирования, например, Python, C, Java, JavaScript, HTML и других.

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

Как работает Bistr?

  • Загрузка состояния: Когда вы начинаете анализ, утилита проверяет, было ли ранее сохранено состояние анализа. Это помогает продолжить с того места, где вы остановились, без необходимости повторного анализа тех же файлов.
  • Анализ кода: Каждый файл анализируется с использованием модели Ollama. Утилита отправляет запрос к модели для анализа конкретного фрагмента кода. Модель возвращает информацию о релевантности кода в ответ на запрос, а также предоставляет текстовое объяснение, почему данный фрагмент имеет отношение к задаче.
  • Сохранение состояния: После анализа каждого файла состояние обновляется, чтобы в следующий раз продолжить с актуальной информацией.
  • Вывод результатов: Все результаты анализа можно экспортировать в HTML-файл, который содержит таблицу с рейтингом файлов по релевантности, что помогает понять, какие части кода наиболее важны для дальнейшего анализа.

Установка и запуск

Для использования Bistr необходимо установить и запустить Ollama — платформу, которая предоставляет LLM модели на вашей локальной машине. Инструкция по установке Ollama для macOS, Windows и Linux описана ниже.

Загрузите последнюю версию Bistr из git:
https://github.com/demensdeum/Bistr/

После установки Ollama и Bistr можно запускать анализ кода. Для этого нужно подготовить исходный код и указать путь к директории, содержащей файлы для анализа. Утилита позволяет продолжить анализ с того места, где вы остановились, а также предоставляет возможность экспортировать результаты в HTML-формате для удобства дальнейшего анализа.

Пример команды для запуска анализа:


python bistr.py /path/to/code --model llama3.1:latest --output-html result.html --research "What is the purpose of this function?"

В этой команде:

–model указывает модель, которая будет использоваться для анализа.
–output-html задает путь для сохранения результатов анализа в HTML-файле.
–research позволяет задать вопрос, на который вы хотите получить ответ, анализируя код.

Преимущества использования Bistr

  • Локальное выполнение: Анализ проводится на вашем компьютере без необходимости подключаться к облачным сервисам, что ускоряет процесс.
  • Гибкость: Вы можете анализировать код на различных языках программирования.
  • Автоматизация: Вся работа по анализу кода автоматизирована, что позволяет сэкономить время и силы, особенно при работе с большими проектами.

Локальные нейросети с помощью ollama

Если у вас было желание запустить подобие ChatGPT и у вас достаточно мощный компьютер, например с видеокартой Nvidia RTX, то тогда вы можете запустить проект ollama, который позволит использовать одну из готовых LLM моделей, на локальный машине, абсолютно бесплатно. ollama обеспечивает возможность общения с LLM моделями, на манер ChatGPT, также в последней версии объявлена возможность прочтения изображений, форматирование выходных данных в формат json.

Сам проект я запускал также и на макбуке с процессором Apple M2, и мне известно что поддерживаются последние модели видеокарт от AMD.

Для установки на macOS зайдите на сайт ollama:
https://ollama.com/download/mac

Нажмите “Download for macOS”, у вас загрузится архив вида ollama-darwin.zip, внутри архива будет Ollama.app который нужно скопировать в “Applications”. После этого запускайте Ollama.app, скорее всего при первом запуске произойдет процесс установки. После этого в трее вы увиделе иконку ollama, трэй это справа сверху рядом с часами.

После этого запускайте обычный терминал macOS, и набирайте команду загрузки, установки и запуска любой модели ollama. Список доступных моделей, описания, их характеристик можно увидеть на сайте ollama:
https://ollama.com/search

Выбирайте модель с наименьшим количеством параметров, если она не влезает в вашу видеокарту на запуске.

Для примера командв запуск модели llama3.1:latest:


ollama run llama3.1:latest

Установка для Windows и Linux в целом похожа, в одном случае будет установщик ollama и дальнейшая работа с ней через Powershell.
Для Linux установка производится скриптом, однако я рекомендую использовать версию конкретно вашего пакетного менеджера. В Linux ollama запустить также можно через обычный терминал bash.

Источники
https://www.youtube.com/watch?v=Wjrdr0NU4Sk
https://ollama.com

Unreal Engine на Macbook M2

Если вы смогли запустить Unreal Engine 5 Editor на Macbook с процессором Apple, то вы могли заметить что эта штука достаточо сильно тормозит.

Чтобы увеличить производительность редактора и движка, проставьте Engine Scalability Settings -> Medium. После этого движок начнет рисовать все не так красиво, зато вы сможете нормально поработать с движком на своем макбуке.