Mac mini, Ubuntu та Codex: як за кілька годин я підготував середовище для розробки інтернет-магазину
Це перша стаття із серії чотирьох матеріалів про розробку реального інтернет-магазину за допомогою Codex. У цій серії я хочу показати не теоретичний експеримент і не демонстраційний проєкт, створений спеціально для статті. Йдеться про конкретний інтернет-магазин, який я розробляю для реального замовника. У статтях будуть реальні приклади, скриншоти середовища розробки, фрагменти роботи з Codex, технічні рішення, проблеми, які виникали під час розробки, і способи їх вирішення. Водночас я свідомо не буду публікувати назву магазину та пряме посилання на нього. Це реальний комерційний проєкт, тому з міркувань професійної етики та безпеки частина інформації залишиться закритою. Моя мета інша — показати сам процес розробки та те, наскільки сильно він змінюється, коли Codex використовується не просто для генерації окремих фрагментів коду, а як постійний технічний інструмент протягом усього життєвого циклу проєкту.
Серія статей
1. Mac mini, Ubuntu та Codex: як за кілька годин я підготував середовище для розробки інтернет-магазину
Ви читаєте цю статтю. Починаємо практично з нуля: Mac mini M4, Parallels, окрема Ubuntu 24. 04, LAMP, локальний домен, WordPress, WooCommerce та Flatsome. Я покажу, як приблизно за 4–5 годин пройшов шлях від чистої віртуальної машини до готової основи магазину, а наступного дня переніс поточну версію проєкту на хостинг.
2. Від шаблону до реального магазину: як я розробляю WordPress/WooCommerce-проєкт разом із Codex
Друга частина буде вже безпосередньо про розробку магазину. Покажу, як із встановленого WordPress та Flatsome поступово формується реальний сайт: структура каталогу, категорії, сторінки, блог, робота з demo content, налаштування WooCommerce та зміна стандартної поведінки WordPress під конкретні вимоги проєкту. Окремо хочу показати сам принцип взаємодії з Codex: коли я описую не конкретну команду чи рядок коду, а бізнес-завдання та очікуваний результат, а Codex уже працює з файлами, WordPress, базою та конфігурацією.
3. Codex як другий розробник: власний функціонал, автоматичні тести та швидкий деплой WordPress-проєкту
Третя частина буде присвячена тому, що починається, коли можливостей WordPress, WooCommerce та шаблону вже недостатньо. Власний PHP-код, додатковий функціонал, виправлення, автоматичні тести, перевірка старих функцій після нових змін та перенесення перевірених правок із локального середовища на сервер. Тут я хочу окремо розглянути, як тести змінюють роботу з AI: Codex не просто створює новий код, а може перевірити його, знайти регресію та виправити проблему ще до деплою.
4. Чому я відмовляюся від OpenServer: одна Ubuntu VM — один проєкт — один Codex
Четверта стаття буде вже про висновки щодо самого середовища розробки. Замість одного OpenServer або однієї Linux-системи з десятком локальних сайтів — окрема віртуальна Ubuntu-машина для кожного серйозного проєкту. На ній знаходиться саме той серверний стек, який потрібен конкретному сайту, його конфігурація, локальна копія, SSH-налаштування production-сервера та весь робочий контекст проєкту. Різні версії PHP, баз даних, бібліотек та серверних компонентів різних проєктів більше не повинні конфліктувати між собою. А разом із Codex така VM фактично перетворюється на самодостатнє робоче середовище конкретного проєкту, де зберігається не тільки код, а й накопичений контекст роботи: конфігурації, технічні характеристики, зображення, документація, історія рішень та інша інформація, необхідна для подальшої підтримки.
Почнемо із середовища
Отже, це перша частина серії. Перш ніж говорити про каталог товарів, WooCommerce, власний функціонал або автоматичні тести, потрібно було створити місце, де все це буде розроблятися. Моєю стартовою точкою був Mac mini M4. А приблизно через 4–5 годин у мене вже була готова технічна основа реального інтернет-магазину. Почалося все з чистої Ubuntu.
Mac mini M4 як основна машина для розробки
Основним робочим комп'ютером для цього проєкту став Mac mini M4 у базовій конфігурації:
Для веброзробки його продуктивності цілком достатньо. Значно важливішим обмеженням для мене став внутрішній накопичувач обсягом 256 ГБ. Віртуальна Linux-машина разом із системою, серверним програмним забезпеченням, проєктом, базою даних та іншими файлами поступово займає досить багато місця. Тому сам образ віртуальної машини я виніс на зовнішній SSD. У результаті macOS і основні програми залишаються на внутрішньому накопичувачі Mac mini, а серверне середовище живе окремо й не забирає місце на 256-гігабайтному SSD. Для віртуалізації я використовую Parallels Desktop.
Ubuntu за п'ять хвилин
Для проєкту я використав Ubuntu 24. 04. Однією з переваг Parallels виявилося швидке стандартне розгортання Linux. Я не витрачав час на ручне створення VM, завантаження ISO та проходження повної процедури встановлення операційної системи. Стандартне швидке розгортання дозволило приблизно за 5 хвилин отримати вже запущену Ubuntu, з якою можна було починати працювати. Для цього експерименту час важливий. Мені хотілося оцінювати не тільки те, чи можна виконати певне завдання за допомогою AI, а й скільки часу проходить від початку роботи до практичного результату. Отже, перша контрольна точка:приблизно 5 хвилин — і чисте Linux-середовище готове до роботи. Образ VM при цьому одразу знаходиться на зовнішньому SSD і не перевантажує внутрішній накопичувач Mac mini.
Навіщо взагалі окрема Ubuntu
WordPress можна запустити й без окремої Linux-машини. Але я свідомо хотів отримати середовище, максимально схоже на майбутній сервер. Тому всередині Ubuntu розгортався звичайний LAMP-стек:
Такий підхід дозволяє працювати з конфігураціями вебсервера, PHP, правами файлів, журналами, базою даних та SSH практично так само, як це відбувається на реальному хостингу. Віртуальна машина при цьому залишається ізольованою від основної системи. Якщо експеримент із конфігурацією закінчиться невдало, це не перетворює macOS на суміш різних версій PHP, серверів, баз даних та залежностей.
Перед роботою з Codex я сформував вимоги
Тут є важливий момент. Я не ставив Codex завдання на кшталт:
Встанови мені WordPress.
До початку роботи в мене вже були сформовані певні технічні вимоги до середовища. Я розумів, який серверний стек хочу отримати, як повинен працювати локальний сайт, які параметри PHP потрібні, як повинні оброблятися зображення, які обмеження необхідно змінити та якою має бути кінцева конфігурація. Тобто Codex отримував не абстрактне прохання «зробити сервер», а досить точно сформульоване технічне завдання. І це, на мою думку, принципово важливо для роботи з AI. Чим точніше описаний очікуваний результат, тим менше часу потім витрачається на виправлення того, що AI зрозумів не так.
Від чистої Ubuntu до WordPress приблизно за дві години
Після запуску Ubuntu основна робота перейшла в термінал. За допомогою Codex потрібно було підготувати весь серверний стек. Сюди входили:
- оновлення Ubuntu;
- встановлення Apache;
- встановлення та налаштування бази даних;
- створення бази та користувача для WordPress;
- встановлення PHP;
- встановлення необхідних PHP-модулів;
- налаштування параметрів PHP;
- налаштування Apache;
- створення VirtualHost;
- локальний домен;
- правильні права доступу;
- перевірка служб;
- аналіз логів;
- встановлення WordPress;
- початкове налаштування сайту.
Окремо були задані правильні параметри PHP для роботи із зображеннями, завантаження файлів та інших операцій, які знадобляться майбутньому магазину. Codex міг не просто запропонувати команди, а пройти весь ланцюжок: перевірити поточний стан системи, виконати необхідні дії та після цього перевірити результат. У підсумку приблизно за дві години був розгорнутий не тільки LAMP. За цей час я отримав уже працюючий WordPress, локальний домен і встановлений шаблон майбутнього магазину.
Flatsome як основа магазину
Для цього проєкту я вибрав Flatsome. Це популярна WordPress-тема, орієнтована передусім на WooCommerce-магазини. Тому після встановлення WordPress завдання не закінчувалося активацією теми. Потрібно було підготувати Flatsome саме під майбутній сайт. І тут почався наступний цікавий етап роботи з Codex. Замість того щоб самостійно проходити десятки пунктів WordPress Admin, я описував, який результат хочу отримати, а Codex виконував технічну частину роботи.
Ще кілька годин — і замість демосайту вже була заготовка магазину
Після розгортання сервера й WordPress я перейшов до базової структури самого сайту. Це зайняло ще кілька годин. Я визначав, що потрібно зробити, а Codex виконував завдання. Наприклад:
- створити потрібну структуру каталогу;
- виконати основні налаштування WordPress;
- підготувати структуру блогу;
- визначити базові параметри магазину;
- прибрати непотрібні блоки Flatsome;
- видалити частину демонстраційних даних;
- залишити ті елементи demo content, які можуть бути корисними;
- прибрати зайві сторінки;
- підготувати основні елементи майбутньої структури сайту.
Це вже була зовсім інша робота, ніж встановлення пакетів Linux. Фактично я почав працювати більше як людина, яка описує потрібний результат, а не як оператор WordPress, який вручну натискає десятки кнопок в адміністративній панелі. Я говорив Codex, що потрібно змінити. Він виконував. Я перевіряв результат і давав наступне завдання.
Через 4–5 годин була готова болванка магазину
Якщо рахувати від початку роботи, картина вийшла приблизно такою:
У результаті приблизно через 4–5 годин після початку роботи в мене була вже не чиста Ubuntu і навіть не порожній WordPress. Це була готова технічна заготовка інтернет-магазину, яку можна було переходити наповнювати реальними товарами, категоріями, текстами та зображеннями. Для мене це одна з найважливіших цифр цього експерименту.
Наступного дня сайт уже був на хостингу
Я не хотів тримати результат роботи виключно на локальній машині. Є ще одна практична причина якомога раніше мати робочу версію проєкту в інтернеті — замовник може бачити процес розробки. Тому вже наступного дня я підготував на хостингу SSH-доступ і поставив Codex наступне завдання: перенести поточний проєкт із локального середовища на сервер. Знову ж таки, сам процес міграції сайту складається з цілого набору дрібних операцій:перенести файли, перенести базу даних, перевірити конфігурацію, змінити адреси, налаштувати права, перевірити роботу вебсервера та переконатися, що після перенесення сайт поводиться так само, як локально. Це та робота, яку можна виконувати вручну. Але Codex робить подібні операції дуже швидко. У результаті вже на ранньому етапі розробки в мене одночасно були:локальне робоче середовище — для розробки;іверсія на хостингу — для демонстрації поточного результату замовнику.
Чому я не підключав Git
У цьому проєкті я свідомо не став підключати Git як центральний елемент процесу розробки. Git незамінний у командній розробці, коли кілька програмістів паралельно змінюють один проєкт, потрібні гілки, merge, code review та синхронізація роботи. Але цей експеримент має іншу модель. За допомогою Codex значно більший обсяг роботи я можу виконувати самостійно. Для конкретно цього проєкту мені не потрібна постійна колективна розробка. Тому основна робоча копія проєкту знаходиться локально. Але відмова від Git у такому сценарії не означає відмову від резервного копіювання. Навпаки.
Локальна розробка без Git вимагає нормальних бекапів
Якщо локальна машина стає основним місцем розробки, резервна копія проєкту обов'язкова. Особливо коли Codex має можливість активно змінювати файли та конфігурацію. Тому для мене частиною такого робочого процесу є окремий зовнішній накопичувач для резервних копій. Фактично виходить кілька рівнів:
Це дозволяє активно експериментувати з автоматизацією, але при цьому не залежати від одного диска або однієї копії проєкту.
Ще одна важлива річ — автоматичні тести
Чим більше роботи передається AI, тим важливішою стає автоматична перевірка результату. Тому для додаткового функціоналу Codex не тільки пише код, а й створює тести. Наприклад, якщо до стандартного WordPress/WooCommerce додається власна логіка, після наступної зміни потрібно бути впевненим, що старий функціонал не перестав працювати. Без тестів це часто означає ручну перевірку:відкрити сторінку, виконати дію, перевірити результат, пройти інший сценарій, переконатися, що попередня функція не зламалася. І повторювати це після кожної суттєвої правки. З автоматичними тестами частину цієї роботи можна виконувати за секунди. Codex вносить зміну, запускає відповідні тести, бачить помилку, якщо щось було зламано, і може одразу перейти до її виправлення. Це особливо важливо не на першому тижні існування сайту, а пізніше, коли проєкт накопичує десятки власних доробок.
Тести прискорюють і подальший деплой
Автоматичні тести змінюють ще одну частину процесу — публікацію наступних правок. Коли замовник просить змінити вже працюючий функціонал, головний ризик полягає не тільки в тому, чи працюватиме нова функція. Потрібно переконатися, що вона не зламала те, що працювало раніше. Тому робочий цикл поступово стає таким:завдання → зміни Codex → тести → локальна перевірка → перенесення на сервер → контроль результату. Чим більше функціоналу покрито тестами, тим швидше і спокійніше можна вносити наступні зміни. Для довготривалої підтримки проєкту це може виявитися навіть важливішим, ніж швидкість початкової генерації коду.
Що в цьому експерименті насправді робить Codex
Після цього етапу мені складно називати Codex просто інструментом для написання коду. У межах одного проєкту він уже допомагав:
- працювати з Ubuntu;
- розгортати LAMP;
- налаштовувати Apache;
- конфігурувати PHP;
- працювати з базою даних;
- встановлювати WordPress;
- налаштовувати локальний домен;
- готувати Flatsome;
- очищати та перебудовувати структуру WordPress;
- переносити проєкт на хостинг через SSH;
- створювати додатковий функціонал;
- писати для нього автоматичні тести;
- перевіряти зміни перед наступним деплоєм.
А моя роль поступово зміщується від виконання кожної технічної операції до формулювання вимог, контролю архітектури та перевірки результату.
4–5 годин від чистої Ubuntu до основи реального магазину
Саме час став для мене одним із найцікавіших результатів першого етапу. Приблизно через п'ять хвилин після початку роботи я мав Ubuntu. Приблизно через дві години — налаштований сервер, локальний домен, WordPress і Flatsome. Через 4–5 годин — очищену та налаштовану основу майбутнього інтернет-магазину, готову до наповнення. Наступного дня — робочу копію на хостингу, яку вже можна показувати замовнику. Звичайно, Codex не скасовує необхідність розуміти Linux, WordPress, серверну конфігурацію або саму логіку веброзробки. Навпаки: щоб правильно поставити завдання і оцінити результат, потрібно розуміти, що саме має бути зроблено. Але він радикально скорочує кількість ручної технічної роботи між постановкою завдання та готовим результатом. І для мене це набагато цікавіше, ніж просто можливість попросити AI:
Напиши мені PHP-функцію.
У цьому проєкті я хочу перевірити інше:наскільки далеко один розробник із правильно організованим AI-інструментарієм може пройти шлях, для якого раніше доводилося витрачати значно більше власного часу або залучати кількох спеціалістів. Перший результат — 4–5 годин від чистої віртуальної машини до готової основи інтернет-магазину. Далі починається вже найцікавіше: товари, структура каталогу, власний функціонал, автоматизація, тести та поступове перетворення цієї заготовки на повноцінний робочий магазин.
This article is based on my own practical experience, real-world projects, and lessons learned along the way. I share approaches and solutions that I have personally used, tested, or explored in my work.