Category Archives: Техдок

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

Одними из классических способов запуска macOS на PC машинах исторически были:
* Hackintosh
* Виртуализация, например с помощью VMWare

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

С недавних пор появилась возможность запускать macOS в Docker. Это стало возможным благодаря проекту Docker-OSX, который предоставляет готовые образы macOS для запуска в Docker. При этом стоит отметить, что Docker-OSX не является официальным проектом Apple и не поддерживается ею. Тем не менее, он позволяет запускать macOS в Docker и использовать ее для разработки и тестирования приложений.

Один из первых проектов по запуску macOS в Docker:
https://github.com/sickcodes/Docker-OSX

Однако запустить полноценно мне так и не удалось, после загрузки в мено Recovery OS, у меня просто отваливалась клавиатура и мышь, и я не мог продолжить установку. При этом в первом boot меню, клавиатура работает. Возможно дело в том что этот проект уже не так активно поддерживается, и есть некие специфические проблемы при запуске на Windows 11 + WSL2 + Ubuntu.

Один из самых активных проектов на данный момент:
https://github.com/dockur/macos

Позволяет запускать macOS в Docker, интерфейс работает через браузер путем проброса VNC(?). После запуска macOS доступна по адресу http://localhost:5900

Данный проект мне удалось запустить и установить macOS Big Sur (минуточку 2020 года) на Windows 11 + WSL2 + Ubuntu, но только изменив compose файл, а именно:

environment:
    VERSION: "11"
    RAM_SIZE: "8G"
    CPU_CORES: "4"

VERSION: “11” – это версия macOS, в данном случае Big Sur
RAM_SIZE: “8G” – это объем оперативной памяти, выделяемый для macOS
CPU_CORES: “4” – это количество ядер процессора, выделяемых для macOS

На текущий момент запуск macOS tahoe (16) также возможен, но есть ряд проблем которые пытаются доблестно решить разработчики проекта.

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

Экосистема Swift активно развивается за пределами платформ Apple, и сегодня писать на нём под Windows вполне комфортно, используя Windows Subsystem for Linux (WSL2). Стоит учитывать, что для сборок под Linux/WSL доступен облегченный вариант Swift — без проприетарных Apple-фреймворков (таких как SwiftUI, UIKit, AppKit, CoreData, CoreML, ARKit, SpriteKit и других специфичных для iOS/macOS библиотек), однако для консольных утилит и бэкенда этого более чем достаточно. В этой заметке мы шаг за шагом разберём процесс подготовки окружения и сборки компилятора Swift из исходных кодов внутри WSL2 (на примере Ubuntu/Debian).

Обновляем список пакетов и саму систему:

sudo apt update && sudo apt upgrade -y

Устанавливаем необходимые зависимости для сборки:

sudo apt install -y \
  git cmake ninja-build clang python3 python3-pip \
  libicu-dev libxml2-dev libcurl4-openssl-dev \
  libedit-dev libsqlite3-dev swig libncurses5-dev \
  pkg-config tzdata rsync

Устанавливаем компилятор и компоновщик (LLVM и LLD):

sudo apt install -y llvm lld

Клонируем репозиторий Swift со всеми зависимостями:

git clone https://github.com/apple/swift.git
cd swift
utils/update-checkout --clone

Устанавливаем `swiftly` и готовый swift с swiftc

curl -O https://download.swift.org/swiftly/linux/swiftly-$(uname -m).tar.gz && \
tar zxf swiftly-$(uname -m).tar.gz && \
./swiftly init --quiet-shell-followup && \
. "${SWIFTLY_HOME_DIR:-$HOME/.local/share/swiftly}/env.sh" && \
hash -r

Запускаем сборку (это займёт продолжительное время):

utils/build-script \
  --release-debuginfo \
  --swift-darwin-supported-archs="x86_64" \
  --llvm-targets-to-build="X86" \
  --skip-build-benchmarks \
  --skip-test-cmark \
  --skip-test-swift \
  --skip-ios \
  --skip-tvos \
  --skip-watchos \
  --skip-build-libdispatch=false \
  --skip-build-cmark=false \
  --skip-build-foundation \
  --skip-build-lldb \
  --skip-build-xctest \
  --skip-test-swift

После завершения сборки добавляем путь к компилятору в PATH (укажите ваш путь до папки сборки):

export PATH=/root/Sources/3rdparty/build/Ninja-RelWithDebInfoAssert/swift-linux-x86_64/bin/swiftc:$PATH

Проверяем, что установленная версия Swift работает:

swift --version

Создаём тестовый файл и запускаем его:

echo "print(\"Hello, World!\")" > hello.swift
swift hello.swift

Также можно скомпилировать бинарный файл и запустить его:

swiftc hello.swift
./hello

Источники

• Getting Started with Swift on Windows
• Swiftly (инструмент для управления версиями)
• Сборка Swift из исходных кодов

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

Спойлер: Вы, возможно, пользуетесь паттерном Интерпретатор прямо сейчас, просто читая этот текст в браузере!

Один из самых ярких и, пожалуй, самых важных примеров использования этого паттерна в индустрии — это JavaScript. Язык, который изначально создавался “на коленке”, сегодня работает на миллиардах устройств именно благодаря концепции интерпретации.

10 дней, которые перевернули интернет

История создания JavaScript полна легенд. В 1995 году Брендан Эйх (Brendan Eich), работая в Netscape Communications, получил задание: создать простой скриптовый язык, который мог бы выполняться прямо в браузере (Netscape Navigator), чтобы делать веб-странички интерактивными. Руководство хотело что-то с синтаксисом, похожим на сверхпопулярный тогда Java, но предназначенное не для профессиональных инженеров, а для веб-дизайнеров.

У Эйха было всего 10 дней на написание первого прототипа языка, который тогда назывался Mocha (затем LiveScript, и только потом JavaScript из маркетинговых соображений). Спешка была не случайной: на пятки наступала корпорация Microsoft, которая в это же время активно готовила свой собственный скриптовый язык VBScript для встраивания в браузер Internet Explorer. Netscape нужно было срочно выпустить свой ответ, чтобы не проиграть в надвигающейся браузерной войне.

Времени писать сложный компилятор в машинный код просто не было. Очевидным и самым быстрым решением для Эйха стала архитектура классического Интерпретатора.

Первый интерпретатор (SpiderMonkey) работал так:

1. Он читал текстовый исходный код скрипта со страницы.
2. Лексический анализатор разбивал текст на токены.
3. Парсер строил Абстрактное Синтаксическое Дерево (AST). В терминах паттерна Интерпретатор это дерево состояло из терминальных выражений (строки, числа вроде 42) и нетерминальных (вызовы функций, операторы вроде If, While).
4. Затем виртуальная машина шаг за шагом “обходила” это дерево, выполняя заложенные в нем инструкции у каждого узла (вызывая метод, аналогичный Interpret()).

Контекст (Context) и Объекты

Помните объект Context, который мы должны были передавать в метод Interpret(Context context) в классической реализации? Он нужен интерпретатору для хранения текущего состояния памяти.

В случае с JavaScript роль этого контекста на верхнем уровне играет Глобальный объект (например, window в браузере). Когда ваш AST-узел пытается, скажем, вывести текст на экран через document.write(“Hello”), интерпретатор обращается к своему контексту (объекту document) и вызывает нужный внутренний API браузера.

Именно благодаря интерпретатору JavaScript смог так легко взаимодействовать с DOM (Document Object Model) — всё это просто объекты в контексте, к которым обращаются узлы дерева.

Эволюция интерпретатора: JIT Компиляция

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

С появлением движка V8 от Google (встроенного в Chrome) в 2008 году произошла революция. Инженеры поняли, что одного интерпретатора недостаточно для современного веба. Движок усложнился: он по-прежнему строит AST-дерево, но теперь использует JIT (Just-In-Time) компиляцию.

Современные JS-движки (V8, SpiderMonkey) работают как сложный конвейер:

1. Быстрый и “тупой” базовый интерпретатор начинает выполнять ваш JS код моментально, даже не дожидаясь его компиляции (здесь по-прежнему работает классический паттерн).
2. Параллельно, движок отслеживает “горячие” участки кода (циклы или функции, которые вызываются тысячи раз).
3. Эти участки компилируются JIT-компилятором напрямую в оптимизированный машинный код, минуя медленный интерпретатор.

Именно это сочетание моментального старта интерпретатора и вычислительной мощи компиляции позволило JavaScript захватить мир, став языком серверов (Node.js) и мобильных приложений (React Native).

Интерпретатор в игровой индустрии

Несмотря на доминирование C++ в тяжелых вычислениях, паттерн Интерпретатор является индустриальным стандартом в геймдеве для создания игровой логики. Зачем? Чтобы геймдизайнеры могли делать игры без риска «уронить» движок или необходимости его постоянно перекомпилировать.

Отличным историческим примером является UnrealScript — язык, на котором была написана логика игр серий Unreal Tournament и Gears of War в Unreal Engine 1, 2 и 3. Текст компилировался в компактный байт-код абстрактной машины, который затем шаг за шагом 해석(интерпретировался) виртуальной машиной движка.

Визуальные граф-скрипты (Blueprints)

Сегодня на смену тексту пришло визуальное программирование — система Blueprints в Unreal Engine 4 и 5.

Если вы когда-либо открывали Blueprint в Unreal Engine, вы видели множество блоков-узлов (Nodes), соединенных «проводами». Архитектурно, весь граф Blueprints — это огромное Абстрактное Синтаксическое Дерево (AST), нарисованное на экране:

1. Терминальные выражения (Terminal Expressions): Узлы-константы. Например, узел, который просто хранит число 42 или строку. Они возвращают конкретное значение при интерпретации.
2. Нетерминальные выражения (Non-Terminal Expressions): Вычислительные узлы (сложение Add) или узлы контроля потока (Branch). У них есть входы-аргументы, которые интерпретатор сначала рекурсивно вычисляет, прежде чем выдать результат на выходной пин.

А роль контекста здесь играет память экземпляра конкретного игрового объекта (Actor). Interpreter Machine безопасно “гуляет” по этому графу, запрашивая данные и выполняя переходы.

Где еще используется Интерпретатор?

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

• Интерпретируемые языки программирования (Python, Ruby, PHP). Весь их рантайм базируется на классическом паттерне. Например, эталонная реализация CPython сначала парсит ваш .py скрипт в AST, компилирует его в байт-код, а затем огромная виртуальная машина (цикл вычисления) интерпретирует этот байт-код шаг за шагом.
• Java Virtual Machine (JVM). Изначально Java код компилируется не в машинные инструкции, а в байт-код. Когда вы запускаете приложение, JVM работает как интерпретатор (правда, с агрессивной JIT-компиляцией, как и в V8).
• Базы данных и SQL. Когда вы отправляете SQL-запрос (SELECT * FROM users) в PostgreSQL или MySQL, движок базы данных выступает в роли интерпретатора. Он проводит лексический анализ, строит AST-дерево запроса, генерирует план выполнения и затем буквально «интерпретирует» этот план, перебирая строки таблиц.
• Регулярные выражения (RegEx). Любой движок регулярных выражений внутри парсит строковый паттерн (например, ^\d{3}-\d{2}$) в граф состояний (NFA/DFA Автомат), по которому затем проходит внутренний интерпретатор, сопоставляя каждый вводимый символ с вершинами этого графа.
• Unity Shader Graph / Unreal Material Editor — интерпретируют визуальные узлы в модульный шейдерный код (GLSL/HLSL).
• Blender Geometry Nodes — интерпретируют математические и геометрические операции для процедурной генерации 3D-моделей в реальном времени.

Итог

Паттерн Интерпретатор давно вышел за рамки «написать свой калькулятор». Это мощнейший индустриальный стандарт. От JavaScript-движков, которые ежедневно исполняют гигабайты кода за кулисами браузеров, до игровых конструкторов, позволяющих строить сложную логику без знания C++ — интерпретаторы остаются одной из важнейших архитектурных концепций в современной IT-разработке.

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

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

Пример 1: Упрощённая схема запуска игры
Чтобы понять принцип работы, давайте представим простую схему запуска игры.

Эта схема показывает идеальный сценарий, когда всё происходит без сбоев. Но в реальной жизни всё гораздо сложнее.

Пример 2: Расширенная схема запуска игры с загрузкой данных
Современные игры часто требуют подключения к интернету для загрузки данных пользователя, сохранений или настроек. Давайте добавим эти шаги в нашу схему.

Эта схема уже более реалистична, но что произойдёт, если что-то пойдёт не так?

Как было: Игра, которая “ломалась” при потере интернета

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

В такой ситуации блок-схема их кода выглядела бы так:

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

Как стало: Исправление по жалобам пользователей

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

Вот как выглядит исправленная блок-схема, где учтены оба сценария:

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

Неопределенное поведение

Зависания и ошибки — это лишь один из примеров непредсказуемого поведения программы. В программировании существует понятие неопределённого поведения (Undefined Behavior) — это ситуация, когда стандарт языка не описывает, как должна вести себя программа в определённом случае.

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

Пример из языка C:

Представьте, что разработчик скопировал строку в буфер, но забыл добавить в конец нулевой символ (`\0`), который отмечает конец строки.

Вот как выглядит код:

#include 

int main() {
char buffer[5];
char* my_string = "hello";

memcpy(buffer, my_string, 5);

printf("%s\n", buffer);
return 0;
}

Ожидаемый результат: “hello”
Реальный результат Непредсказуем.

Почему так происходит? Функция `printf` с спецификатором `%s` ожидает, что строка завершается нулевым символом. Если его нет, она продолжит читать память за пределами выделенного буфера.

Вот блок-схема этого процесса с двумя возможными исходами:

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

С развитием больших языковых моделей (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 забывает — дублирование кода помогает ему вспомнить.