Comments 53
Молодец! Я тоже пошёл по этому пути, только с Github Copilot, Astro, Cloudflare Pages + кучи кастомного кода и ещё больше тестов этого кода (около 3к), чтобы довести сайт до стандарта scientific blog (кучи разной метадаты).
Вставь ссылочку на свой сайт, чтобы посмотрели на результаты. Если что, то вот мой
https://molyanov.ru
Вот мой =)
Над Astro тоже думал, долго выбирал между ним и Next.js. Остановился на втором, потому что он популярнее, а CC как-то стабильнее с более популярными стеками работает
Крутяк! Я тоже задумываюсь над созданием своего сайта. Статья как раз поможет мне преодолеть свою лень :)
Если не секрет, сколько денег потратил на нейронки для этого проекта?
Я думаю подписки за $20 хватит да глаза.
У CC разве что проблема оплатить - нужна карта и телефон из одной страны, если не ошибаюсь.
У меня Max подписка на Claude за $200. Ее хватает на все проекты и на работу за пределами вайбкодинга
Но я оч много с нейронками общаюсь. И работаю часто в нескольких окнах сразу — пока в одном чет делается, во втором планируем и обсуждаем.
С Max100 иногда упирался в лимиты. Некритично, но бесило — хочется уже доделать задачу, пока помнишь, а не ждать час. Поэтому взял Max200.
А сколько из этой подписку ушло именно на этот сайт — фиг знает. Учитывая, что я его 3 дня всего делал, можно сказать, что 1/10 от всей подписки, то есть $20 =)
а во сколько обошелся по деньгам новый сайт при разработке? в рамках месячной подписки на cc?
Чуть выше ответил. У меня Max подписка за $200, я очень много всего делаю в Claude. Сайт сделал за 3 дня, можно считать, что это 1/10 месячной подписки =)
Если бы брал подписку чисто ради сайта, то взял бы Max за $100, думаю, уложился бы в лимиты
Ну и VPS, на котором сайт лежит, стоит 700₽ в месяц
На подписке в 20$ он бы упирался в 5-ти часовые лимиты (у клауд кода каждые 5 часов лимит сбрасывается), но пусть не 3 дня, а 6 потратил бы. Но это 20$ всего. Или 100$ подписки за глаза.
Да, клёвые маленькие проекты - вайбкодить в кайф. Отвечаю предыдущему комментаторы думаю, что в подписку за 20 баксов уложился край 200 если дока и пр.
Скрытый текст
А почему была идея, что сео просядет? Next с ssr и разметкой за щеки даёт тильде и wp.
AI делал оптимизацию?
Я вот таким образом пытаюсь толкать AI SEO. https://thai-residence.com/info-guide/investment
Но тут приходится как пауку разметку плести. Если бы не AI, я бы только улыбался 😃
Судя по скринам контент статический, что-то вроде блога, зачем тогда Next.js, которые нужен для динамических сайтов как приложения? Подозреваю, что хватило бы просто любой Headless CMS и статических страниц. Но чат занесло не в ту дверь и пошло поехало... (На самом деле на чём его обучили, туда и занесло)
Так то оно вроде как круто, но можно навайбкодить и свой фреймворк, свой HTTP-сервер, базу данный свою изобрести на своём Linux-дистрибутиве и взяться наконец за свой язык программирования, всё-же чат делает, как-то оно будет работать...
Если у чата стояла задача продавать подписку, то он отлично с ней справился и крепко вас подсадил на неё.
Вот я тоже смотрю и не понимаю к чему все это, там так описано, будто средней нагрузки saas сервис делают, а там просто сайт визитка... Без план мода с этим прекрасно справится любая ии если детализировать что хочешь)
Что там за SEO тоже не ясно, если в данном случаи seo это просто скорость по lighthouse, ну.... Здорово)
Я обсуждал это с СС, он предлагал и такой вариант тоже. Выбрал next.js, потому что интересно к сайту в будущем всякие штуки добавлять.
Ну например, я хочу сделать в блоге скрипт-типограф, который висячие предлоги автоматически исправляет. Или автоматом посты из Тг репостить на сайт.
Как я понял, на next.js это проще и удобнее, чем потом к статическому сайту прикручивать что-то
Claude посоветовал Next, потому что это популярный фреймворк, на котором он хорошо натаскан - вот автор и лепил на чем всевышний наказал :)
Ну, это сейчас любой дурак с нейронкой может по глупости докатиться до изобретения собственного языка программирования. А вот в наше время, мы до такого рода глупостей сами докатывались, своим умом, без подсказок GPT.
Я делал ЯП "sequence". Ключевая особенность: сиквенс-программы хранятся "снаружи", на других серверах, которым мы (а мы ведь параноики) не доверяем. Предназначение программ - мониторинг, получение данных о системе. Но главное - программа даже в теории не может быть "вредной". Она не может создавать файлы, не может изменять их, не может перегрузить систему. Более того, на sequence нельзя даже вечный цикл сделать! Каждая программа на sequence - просто по архитектуре завершается за заранее известное количество шагов.
На sequence можно написать полезную мониторинговую программу. Можно написать глупую, бесполезную. Но нельзя написать вредную.
То есть, если вы с гитхаба скачиваете и запускаете скомпилированный бинарь - вы рискуете. Если бы скачивали сиквенс программу - риска бы не было.
Но язык получился ужасным, я сам на нем писал с трудом, это было противно, и в конечном итоге я его похоронил.
Не поделитесь примерчиком?
Отвратительное под катом 1
"sequence": {
"1": {
"path": "/var/log",
"command": "DIR"
},
"3": {
"field": "size",
"command": "SORT"
},
"2": {
"command": "FILTER",
"argline": "type=='REG'"
},
"5": "TOP 10",
"4": "REV",
"6": "FORMAT {path} {size}"
}Добавка
"sequence": {
"10": "CONNECTIONS",
"30": "SORT field=port",
"20": "FILTER status=='LISTEN' and proto=='tcp' and basename != 'smtpd'",
"40": "FORMAT {proto}:{port} {basename}"
}То есть, каждая программа - это своего рода конвейер, похожий на ls | grep xxxxx | wc -l но там был еще псевдо-fork, (естественно, процессы он не плодил, просто создавал несколько веток и каждую обрабатывал после другой). Например, один из методов мониторинга брал все подмонтированные диски и по каждому смотрел сколько на них места и репортил на сервер N индикаторов.
Задумка была в том, что коды скриптов держатся на сервере, там же можно их из админки править, модифицировать, подключать новые (например, на этом сервере что-то еще начинаем проверять, а на другом - отключаем какую-то проверку) и все это без риска (для пользователям) исполнения кода, который загружается с внешнего сервера. Загружается заведомо безопасный код.
Получилось. Работало. Но получилось излишне тяжеловесно, гиперусложненно и эстетически отвратительно. Перешел на дизайн, когда на клиенте просто крутятся скриптики, каждый в stdout выдает разные показатели, и это все уходит в мониторинг. Получилось очень просто, понятно, легковесно ну и вполне безопасно. Но без возможности управления ими из веб-морды (надо включить-отключить - логинишься на сервер и по аналогии с a2enmod/a2ensite одной командой делаешь). Урок извлек такой: не каждую автоматизацию, фичу надо делать.
Вместо этого ужаса сейчас (в простом случае) можно написать скрипт на любом языке (пайтон, шелл) который (в простом случае) просто напечатает, например:
NAME server1:df:/home
DETAILS: /home has has 60% free
STATUS: 60
Я как раз сейчас делаю свою СУБД с нейронками. Я уже давно придумал уникальную СУБД, которая позволит разгрузить бекенд и переложить большую часть нагрузки на самих клиентов, чтобы даже моя VPS за 75₽ в месяц потянула мою будущую соцсеть даже с десятками тысяч пользователей. Некогда было ей заняться, а с нейронками дело пошло.
Из контекста не понятно шутка это, или нет
Не шутка. Я пишу свою соцсеть, где пользователи смогут писать код шейдеров и не только, всё выполняться в браузере и публиковаться как посты. В общем , убийца ShaderToy. Искал решения, как сделать это, чтобы потом практически не платить за инфраструктуру. Придумал такую СУБД, публичные фрагменты которой можно выложить на CDN и по HTTP Range-запросами находить всё, что надо, прямо с клиента. Бекенд только будет изредка выдавать карту, чтобы клиент знал, где искать актуальную версию данных, а также для записи и данных, требующих контроля. И то скорее всего такие данные будут тоже на CDN, но в зашифрованном виде, а бекенд будет только ключи выдавать.
А CDN такое, ну, бесплатно обслуживать будет
Cloudflare бесплатно проксирует же, правда в РФ с ним проблемы, но я нашёл некоторые костыли, чтобы только для блокирующих его провайдеров использовалась прокси-VPS. Конечно при большой нагрузке Cloudflare может прийти с требованием платить, но это вроде очень большая нагрузка должна быть. Вряд ли это случится до того, как я хорошо заработаю на своём проекте, и это станет неважным. А если не заработаю, то и не придут, смогу поддерживать его в рабочем состоянии практически бесплатно.
Как минимум, не надо платить за вычисления, можно захостить всё на слабом серваке с большими дисками и быстрой сетью. И моя СУБД хорошо экономит место и трафик за счёт блочного сжатия большей части данных и упаковки метаданных. Если традиционные БД весят намного больше, чем сырые данные, которые там лежат, то у меня будет в разы меньше.
Не понял, зачем мне минус поставили. Неужели такая архитектура никому не интересна? Даже если идея выкладывать данные на всеобщее обозрение кажется стрёмной, можно ведь захостить её внутри контура компании, а клиентами сделать бекенд, любое количество микросервисов и т.п., и БД не будет боттлнеком даже если вырастет до терабайтов.
Мне кажется, вполне разумный подход. Особенно, если на практике сработал/сработает. А в случае, если проект взлетит, получит много пользователей и будет приносить деньги - тогда уже и затраты на CDN, если потребуются, могут окупаться.
Я не уверен, нужно ли только это делать как СУБД именно (архитектурно не тот уровень). Выглядит вообще как обычный файловый интерфейс с fseek(). Может быть можно как-то сделать через FUSE? Тогда можно запустить настоящую субд, например, sqlite поверх этого. По аналогии с S3fs - она делает на системе виртуальные файлы (их на диске нет), а по мере запросов - скачивает их с S3. Может быть даже она и заменяет то что вы делаете, если в качестве CDN использовать S3.
Я далек от графики и shader, shadertoy - для меня непонятные слова. Но что делает база - она прямо какой-то SQL поддерживает (или другой язык запросов) или просто имеет какой-то индекс примари ключей и может выдавать данные по ключу (нужна записать с PK=12345 - скачиваем 12345.bin)?
Я пытаюсь сделать именно СУБД с таблицами и с запросами по одной таблице - хотя бы уровня SELECT без JOIN'ов и GROUP BY по функционалу - сам язык SQL для этого необязательно делать. Каждая таблица - это директория с набором файлов-сегментов типа 0.seg, 1.seg, 2.seg, и т.д. по мере накопления данных. Когда файл вырастает большой, начинаем писать новый, а старый сжимается блоками и фиксируется навсегда как read-only файл - его можно раздавать и кешировать. Если элемент обновился, он уже попадёт в новый сегмент, а в архиве зависнет старая версия. Чтобы найти именно последнюю версию, надо у сервера спросить карту, которая скажет, в каком архиве последняя версия или она ещё в живом сегменте.
По сути, сегмент таблицы - это массив байт в начале и массив смещений элементов в конце плюс другие метаданные для поиска (даты и т.п.). Первым запросом читаем конец файла - смещения и другие метаданные сегмента, проходимся по ним на клиенте, а вторым по найденному смещению достаём сами данные сжатого блока, где лежит искомый элемент.
В своей СУБД сразу делаю VFS, чтобы можно было работать как с БД в памяти, так и в локальном файле или удалённом сервере без необходимости что-то монтировать в ОС.
SQLite через абстракцию от ФС тоже можно заставить работать, но это будет медленно, так как она не приспособлена для таких задержек. Там B-деревья и сканирование по строкам с множеством чтений файла друг за другом - пинг будет складываться. И её неудобно пилить на много файлов, потому что каждый станет своей отдельной БД. Там оверхед на метаданные, и сжатие только через плагины, причём менее эффективное, так как вроде мелкими блоками работает.
Другое дело - своя СУБД, специально предназначенную для поиска элементов за минимальное количество прыжков по файлу - за 2, и автоматическую упаковку старых данных в отдельные read-only файлы. Постепенно такие архивные файлы будут копиться, но сервер БД всегда будет работать только с текущим не дописанным сегментом и держать компактную карту с интервалами ключей, по которым можно определить какие файлы-архивы стоит смотреть для запроса. А в архивах будет искать сам клиент, предварительно получив актуальную карту с сервера. Большую часть карты можно тоже хранить в архивах, а с сервера только получать дельту, можно даже в режиме реал-тайм подписки.
Такой сайт с таким воркфлоу, без всяких там нейронок, делается в пол тыка на связке hugo (gohugo.io) + github/gitlab + netlify. Заплатить нужно только за домен.
Делается, но для этого нужно знать, что такое Hugo, как настроить GitLab CI, что такое Netlify, и как это все связать. А автор - не разработчик
По hugo есть документация и куча готовых шаблонов и примеров, нужно лишь вставить свой контент. Что такое gitlab ci вообще знать не нужно - всё настраивается автоматически в пару кликов в аккаунте netlify. Нажимаете кнопку чтобы создать сайт на основе репозитория, авторизуетесь и готово.
Может тот же Claude Code или Cursor знают Hugo не хуже Next.js'a.
Я разработчик, но для меня Hugo - довольно простой и логичный, а Next.js - настоящий большой фреймфорк который надо учить.
Гугл, нейросети, ютуб да и просто разные хабы и форумы, где можно забить "как максимально дешево сделать сайт такого вот типа"..
очередной велосипед в мире веб разработки
1) Про организацию работы с нейронкой, хороший подход.
2) Про админку - вы можете и её навайбкодить , просто не хотите, т.к. там дольше возиться:)
3) Зависимость от платной нейросети ничем не лучше зависимости от стороннего платного программиста.
Нейронкой я и так постоянно пользуюсь, и для рабочих, и для личных задач. То есть ради сайта даже подписку отдельную покупать не пришлось. Переехать на другую модель тоже не сложно. Можно поменять Claude на Geminy/Codex/Cursor CLI за 15 минут.
Ну и как-то мне не нравится живого человека гонять по рутинным задачам в духе «добавь отзыв на сайт». Разработчики достойны большего, чем такой фигней заниматься. А тут нейронка делает сама, и быстро, это удобно
Работает - и хорошо. Но меня "эстетически" это тоже бесит, мы запрягаем нечеловеческий интеллект, где-то там сотни видеокарт жужжат кулерами, и все это просто чтобы добавить отзыв на сайт, то что делается за полсекунды.
А потом удивляемся, почему в 1957 году запустили спутник, а у нас в кармане мощностей в тысячи раз больше чем тогда во всем мире, а даже задачу "добавить отзыв" надо ждать заметно ощутимое время.
Работает принцип, что "задача потребляет все доступные на нее ресурсы", а раз вы уже купили ресурсов на 200 баксов в месяц -- вы не сделаете это экономно :-)
Лучше уж пусть тот же клод написал бы (один раз) админку или перетащил сайт на Hugo + decap cms или другую.
+1. Можно предложить специальное выражение: "энергетически неэтичная деятельность". Сюда же блокчейны на механизме консенсуса "proof-of-work" (которые тоже молотят энергию на тепло).
В данном случае (блог) задачу можно сделать гораздо эффективнее не теряя никого оттенка-элемента эффективвности (отзыв добавится быстрее, дешевле и будет выглядеть точно так же). А в блокчейнах с proof of work - вряд ли можно оптимизировать - можно только поставить иную задачу, но у нее будет уже иной экономический смысл (Например, можно завести "центробанк" который будет своим авторитетом подтверждать транзакции - но тогда получится крипта с уже другими свойствами, зависимая от этого "ЦБ").
Это примерно как "искать и копать золото для слитков - очень дорого, давайте лучше использовать олово или воду". Золото - это ведь тоже пруф-ов-ворк, только надо не простые числа искать и песок в золотоносной реке промывать.
3) Зависимость от платной нейросети ничем не лучше зависимости от стороннего платного программиста.
Я даже не знаю с чего начать дискуссию...
Это работает, пока сайт маленький и статический. Как только появится необходимость в ролевой модели доступа, модерации комментариев, интеграции с еком - очень быстро придете к тому, что нужна... да, CMS. И вайбкодить придется с нуля
Так это маленький личный сайт, там кроме пары лендингов и блога ничего и не будет. Если надо будет что-то сложное делать, то конечно — тут без CMS не обойтись. И если это будет что-то важное-сложное, то я лучше разработчика привлеку, чем сам буду ковыряться, я не настолько хорошо в этом разбираюсь пока что
Все, о чем написал комментатор – уже в коробке Next.js по сути. Next.js взят не случайно клод кодом, на нем можно строить очень серьезные вещи (на нем их и строят большинство компаний в мире). Клод код спокойно напишет CMS сам, тем более если она не свехсложная. Просто модель не забывайте переключать в клод коде на Opus командой /model.
С удовольствием порекомендую Cloudflare Workers вместо VPS. Несложный квест, который делает сайт ещё быстрее :)
Я выбил 100/100.
В России как минимум мобильные операторы блочат Cloudflare. Мне пришлось для них настраивать редирект напрямую на свою VPS, которая проксировала с Cloudflare.
С лайтхаусом - я тоже выбил четыре сотни (специально вот задрачивался до мелочей ради спортивного интереса), но со временем результаты сползли. Видимо, они как-то меняют требования со временем (не было времени долго разбираться). (Это никак не возражение против Cloudflare Workers, только, наверное, Pages? Или их сейчас вроде объединили в одно)
Автор красава! Не разменивает по мелочам собственную экспертизу и знатно экономит на смузихлёбах.
ну нееее ... вы показываете тесты десктопной версии, а они почти у всех 90 - 100. Глобальная же задача - это оптимизация под мобильные, а там у вас 68 из 100, то есть даже не зелёная зона (https://developers.google.com/speed/pagespeed/insights/?url=https://molyanov.ru/&hl=ru)
И вот "красные" показатели на мобильных:
First Contentful Paint 3,4 сек.
Largest Contentful Paint 6,1 сек.
Speed Index 5,3 сек.
Я недавно протестировал кучу платформ, если найду силы, сделаю пост с результатами теста.
Ммм... то что можно было сделать за день сделано за три... тоде что ли в вайбкодеры податься
Ссылку на сайт необязательно, а вот ссылку на репозиторий было бы интересно глянуть. У меня тоже есть админка полностью написанная Claude Code. Она работает, задачи выполняет, но его код я бы не стал никому показывать. Даже с учётом того, что совсем полный треш я исправлял так, как написана админка на стеке который я знаю. Как то пытался навайбкодить flutter приложение(не мой стек), получалась полная шляпа.
последние инсайды по вайбкодингу - вайбкодеры уже не парятся о технологиях, базах, деплое, средах, на код вообще не смотрят, только чистый бизнес хардкор (постановка задач, фичи). дешевле попросить переделать 7 раз, соптимизировать и попросить агента самого найти ошибки чем смотреть код. проекты растут до огромных размеров и при этом работают. увы и ах... как некогда была изобретена java чтобы задействовать сотни тысяч индусов взамен сложного для них C++, так завтра заменят и их
Я сделал сайт с Claude Code вместо админки — и это очень удобно