Мы живём во время, когда писать код стало… странно. Раньше ценился тот, кто держал в голове синтаксис и помнил все аргументы функции из какой-нибудь задрипанной библиотеки. Сегодня половину этого за тебя делает ИИ.
Cursor, Copilot, ChatGPT — они реально стали частью рабочего процесса. Ты ставишь задачу — и получаешь код. Ошибся? Написал криво промпт — поправил. Скорость ×10.
🚀Что меняется прямо сейчас:
Код рукамибольше не главное. Ценность — в понимании архитектуры и умении объяснить задачу ИИ так, чтобы он сделал то, что нужно.
Знание фреймворковуже не даёт того преимущества, что раньше. ИИ подскажет любой синтаксис быстрее, чем ты вспомнишь.
Конкуренция растёт: студент за неделю может собрать MVP, на которое у опытной команды ушло бы пару месяцев.
⚡Что это значит для нас, разработчиков:
Держаться за «писать код» как за главный скилл — плохая стратегия.
Реальная ценность теперь в том, чтобы делатьпродукт, а не только строки кода.
На первый план выходит мышление инженера-продуктолога: собрать всё из Lego (фреймворки, API, AI-инструменты) и превратить в работающий сервис.
💡 Для indie-hacker’ов это вообще подарок.
Не надо тратить месяцы на инфраструктуру — можно собрать MVP за вечер.
Легко проверять гипотезы, запускать пет-проекты и смотреть, что взлетит.
В итоге выигрывает не тот, кто дольше сидит в IDE, а тот, ктобыстрее тестирует и запускает.
И да — это моё оправдание, почему я оплатил Cursor. Я не трачу время на «ручной» код, я покупаю себе скорость и шанс быстрее довести идею до продакшена.
👉 Я пишу про indie-hacking, пет-проекты и эксперименты с такими инструментами у себя в телеге (ссылка в профиле)
P.S.Всё это в первую очередь работает дляклиентской части приложений. С бекендом у GPT пока сложнее, там много нюансов — но об этом расскажу в следующий раз.
У любого проекта должен быть сайт. Даже если единственный пользователь — моя мама. Мама — это идеальный QA: откроет с телефона, в дороге, через мобильный интернет, спросит «а почему замочек не зелёный?» и закроет, если что-то долго грузится. Значит, сайт должен открываться по твоему красивому домену, по HTTPS, без рыжих предупреждений, и желательно находиться в поиске.
В этой статье мы за вечер соберём и задеплоим простой сайт «с нуля» почти бесплатно: купим домен, поднимем машину с публичным IP, обернём всё в Docker, прикрутим автопродление SSL, добавим sitemap.xml и robots.txt, и вручную прокинем сайт в индексацию Google и Яндекса, чтобы он не лежал «в вакууме».
По шагам:
покупаем красивый домен
находим компьютер с публичным IP (или дешёвый VPS)
настраиваем и обновляем SSL (Let’s Encrypt, автообновление)
подключаем Google Search Console и Яндекс.Вебмастер, отправляем сайт в индекс
В конце — у тебя домен с «замочком», сайт открывается на телефоне у мамы, а поисковики знают, что ты существуешь.
Проблематика (что обычно ломается)
«Сайт есть, а доверия нет».Без HTTPS браузеры пугают пользователей. Let’s Encrypt спасает, но сертификаты живут 90 дней — если не автоматизировать продление, всё сломается в самый неудобный момент.
DNS и сеть — чёрная магия.Белый IP, порты 80/443, NAT, иногда IPv6 — легко потеряться. Мы пройдём «самый короткий путь» без лишней теории.
Зоопарк гайдов.Одни статьи переписывают учебник по Linux, другие — «магия одной кнопкой». В итоге или оверкилл, или непонятно, что происходит под капотом.
Поисковики не телепаты.Если не отдать sitemap.xml, корректный robots.txt и не «постучаться» в Search Console/Вебмастер, сайт может неделями валяться вне индекса.
Конфиги, которые не воспроизводятся.«Оно работало у меня локально» — не план. Нужна структура, которую можно повторить через месяц или перенести на новую машину за 10 минут.
Безопасность и обновления.Правильные заголовки, автопродление сертификатов, изоляция через Docker — всё это снижает риск «позвать маму — показать 502».
🛒 Шаг 1. Покупаем красивый домен
Первое, что нужно любому сайту, — свой адрес в интернете. Я обычно беру домены наreg.ru, потому что у них простой интерфейс и быстрая регистрация. Но по факту — можно использовать любой регистратор, хоть GoDaddy, хоть Namecheap, хоть вашего локального провайдера.
Процесс простой:
Вбиваем желаемый адрес в поисковую строку на сайте регистратора.
Смотрим доступные варианты и цены (будьте готовы, что .com и .ru могут сильно отличаться).
Выбираем понравившийся домен.
Оплачиваем.
💡Лайфхак: Отказываемся от всех «дополнительных услуг» — конструкторы сайтов, «хостинг за 1 рубль», SEO-пакеты и прочий мусор. Это почти всегда платные подписки, которые через месяц начнут жечь бюджет.
Дальше будем учить его показывать наш сайт и радовать маму зелёным замочком.
🌐 Шаг 2. Находим компьютер с публичным IP
Чтобы сайт был доступен мамев любое время суток, нам нужен компьютер, который:
работает 24/7;
имеетпостоянный(статический) IP;
готов тянуть на себе веб-сервер.
Вариант 1: Домашний сервер
Если у тебя дома стоит ПК, которыйникогдане выключается (например, твой старый системник или мини-сервер), можно попросить у интернет-провайдера выделенный статический IP. У меня такая услуга стоит ~200 ₽/месяц, у тебя может быть чуть дороже или дешевле.
Но надо заморочиться с локальной сетью, пробросом портов и динамическим DNS. Но для нашей задачи это лишняя головная боль — главное, чтобы в итоге у нас был:
компьютер с Ubuntu(или другой Linux-системой);
статический IP;
доступ по SSH.
Вариант 2: VPS (виртуальный сервер)
Я чаще всего беру VPS на serverspace — самая дешёвая конфигурация там обходится примерно в400 ₽/месяц. Это дороже, чем дома, но зато:
сервер гарантированно работает 24/7;
не шумит кулерами под столом;
можно выбрать локацию (Москва, Амстердам, Нью-Йорк — что душе угодно).
в настройках DNS IP адрес связан с доменомdebugtest.ru
Дальше — ставим Docker и готовим окружение.
🐳 Шаг 3. Ставим Docker и Docker Compose
Почему я люблю Docker? Потому что всё окружение можно описатьдекларативно: база, сервер, сервисы — всё в одном docker-compose.yml. Один файл — и твой проект можно поднять на любой машине за пару минут.
Для нашей цели нам нужен толькоDocker EngineиDocker Compose plugin. Ниже — команды для Ubuntu 24. Если у тебя другая версия или дистрибутив, просто загугли:
how to install docker-compose <название_твоей_системы>
Дальше — будем ставитьSSLи запускать всё это добро.
🔒 Шаг 5. Настраиваем и обновляем SSL (Let’s Encrypt)
Наша цель — чтобы мама открылаhttps://debugtest.ruи увидела зелёный замочек, а не красное «Небезопасно». Для этого используем бесплатные сертификаты от Let’s Encrypt и встроим их в наш Docker-стек.
1. Запускаем docker-compose
Переходим в папку с docker-compose.yml и стартуем контейнеры:
docker compose up
Покабез -d, чтобы видеть логи и убедиться, что Nginx поднялся без ошибок.
2. Проверяем валидацию (dry-run)
Открываемвторую SSH-сессиюк серверу и там выполняем тестовый запуск certbot:
Это проверит сертификат каждый день в 4 утра и перезапустит Nginx, если сертификат обновился.
🔍 Шаг 6. Подключаем Google Search Console и Яндекс.Вебмастер, отправляем сайт в индекс
Поисковики не телепаты. Даже если твой сайт уже крутится с идеальным SSL и sitemap.xml, Google и Яндекс могут заметить его черезнедели. Мы ускорим этот процесс вручную.
1. Google Search Console
Заходим в Google Search Console.
ЖмёмДобавить ресурс→Домен(лучше, чем URL-префикс — сразу охватывает все поддомены и https/http).
Подтверждаем владение доменом через DNS:Search Console покажет TXT-запись.Идём к своему регистратору (Reg.ru, Namecheap и т.д.).Добавляем эту TXT-запись в настройки домена.Ждём от пары минут до пары часов, пока DNS обновится.
Search Console покажет TXT-запись.
Идём к своему регистратору (Reg.ru, Namecheap и т.д.).
Добавляем эту TXT-запись в настройки домена.
Ждём от пары минут до пары часов, пока DNS обновится.
После подтверждения — заходим в менюИндексация → Файлы Sitemap.
💡 Лайфхак: сразу после добавления sitemap.xml можно зайти вПроверка URLи вручную «Запросить индексацию» главной страницы. Это ускорит попадание сайта в выдачу.
Подтверждаем владение доменом:Через загрузку HTML-файла в корень сайта.Или через метатег в <head> (если редактируешь index.html).Или через DNS TXT-запись (так же, как в Google).
Через загрузку HTML-файла в корень сайта.
Или через метатег в <head> (если редактируешь index.html).
ЖмёмОтправитьи проверяем, что файл принят без ошибок.
3. Как понять, что всё работает
В Google Search Console и Яндекс.Вебмастере появится график количества проиндексированных страниц.
Если на сайте что-то меняешь — обновляй дату <lastmod> в sitemap.xml, чтобы поисковики знали, что появилась свежая версия.
Не спеши паниковать: первые визиты ботов могут быть уже через пару часов, но полная индексация — через 2–7 дней.
📌 Теперь твой сайт:
Доступен по HTTPS.
Знает, как его индексировать (robots.txt + sitemap.xml).
Внесён в обе главные поисковые панели.
Готов к визиту мамыик появлению в Google/Яндексе.
💬 Если тебе зашёл этот формат и ты хочешь видеть больше таких разборов, у меня есть Telegram-канал, где я делюсь своими пет-проектами, экспериментами, идеями для стартапов и многим другим. Ссылка на канал — в моём профиле.
Стал смотреть в сторону локального запуска моделей. Не из-за хайпа, а скорее из-за недоверия. Причина - не сами технологии, а то, как с ними обращаются.
Облако это удобно. Но публично, если не уследил
Недавно в Google начали всплывать реальные диалоги пользователей с Grok и ChatGPT. Обычные ссылки на чаты, которые кто-то где-то засветил. Google их подхватил - и вот, они уже в выдаче. OpenAI убирали из индекса ~50 000 ссылок на публичные диалог, они подчистили Google, но забыли проArchive.org. А там всё ещё висят штуки с логинами, ключами, приватными планами.
Анализ показал: из 512 чатов20% содержали явно конфиденциальную информацию.
Поделился ссылкой? Потерял контроль
Даже если вы делитесь диалогом «только внутри команды» - дальше всё по классике:
может попасть в Google
сохраниться в Archive
быть расшаренной кем угодно
остаться в кэше навсегда
Почему вообще об этом думаю
Планирую собрать поделку: связать LLM и Obsidian. А в Obsidian у меня почти всё личное - от заметок до чувствительных штук.
И вот тут уже важно, чтобы данныене утекали наружу, даже случайно. Поэтому и смотрю в сторону локального inference - без облаков, логов и внешнего API.
🎁 Бонусы
🧮LocalScore.ai Сервис, который показывает, какие LLM потянет ваша видеокарта. Удобно, если хотите запускать модель у себя - а не в чьём-то дата-центре.
🔑ai-keys-leaks.begimher.com Ищет утёкшие API-ключи от OpenAI, Claude, Gemini и других. Не факт, что что-то сработает — 99% ключей мёртвые. Но наличие таких баз говорит о многом.
Я не стал параноиком. Но теперь всё, что потенциально приватно — я не пишу в облако. Потому что модель забудет, а интернет - нет.
Если тебе близка тема ИИ, агентных систем и ты хочешь быть в числе тех, кто не просто читает новости, а сам их делает - залетай в мой Telegram-канал debug_leg. 🔗 Ссылка - в профиле
Если вы разрабатываете агентов, интегрируете GPT в бизнес-логику или просто строите чат-ботов — уязвимости могут стать не теоретической, а очень практической болью. OWASP подготовил подробный список из 10 наиболее распространенных угроз, с которыми уже сталкиваются разработчики LLM-продуктов.
📘 Новость в том, что теперь весь список переведен на русский язык. Это полноценная PDF, где у каждого пункта есть описание, примеры, сценарии атак и меры предотвращения. Прочитать можно за вечер — сэкономите недели на разборках после продакшена.
Что внутри?
Вот несколько уязвимостей, которые стоит знать до, а не после:
🔓 Prompt Injection (LLM01)
Манипуляция промптами, когда злоумышленник через запросы влияет на поведение модели. Причем не всегда напрямую — инструкции могут быть спрятаны в других источниках: веб-страницах, описаниях или даже изображениях. 💥 Последствия: обход системных ограничений, генерация нежелательного контента, утечка данных.
🧠 Чрезмерная агентность (LLM06)
Когда ваш LLM получает слишком много возможностей и начинает действовать почти автономно. Особенно критично в агентных архитектурах: вроде хотели автоматизировать рутину — а получили сбой в цепочке действий и неожиданный запрос в продовую систему.
🕵️ Утечка системных инструкций (LLM07)
Системный prompt, на который вы надеялись, что он «где-то под капотом» — может внезапно всплыть в ответе. И да, это уже происходило в реальных кейсах.
☠️ Отравление модели и данных (LLM04)
Если используете RAG, fine-tuning или хостите датасеты от пользователей — атака может прийти снаружи. Достаточно одного вредоносного документа, чтобы искажать ответы модели.
Почему это важно?
Потому что LLM-интеграции — это не просто UX-фича, а точка доступа в критические процессы. Слишком часто в AI-продуктах безопасность оказывается "потом".
OWASP формирует этот список на основе реальных атак, багрепортов и практики. Это живой, работающий фреймворк, а не академическая выжимка.
Если вы пишете что-то на базе GPT, Claude или других LLM — этот список должен быть у вас в закладках. Потому что баг, который вы считаете “забавной фичей”, может завтра попасть в презентацию хакеров на DEF CON.
🔗 Я веду Telegram-канал, где разбираю такие истории и делюсь собственными экспериментами в инди-хакинге и запуске микро-продуктов. Ссылка — в профиле.
Интересная история из мира инди-разработки — парень, не бросая основную работу, построил SaaS-сервис, который спустя два года принес ему крупный exit.
🧪 Началось всё с личной боли. Его жена, научный сотрудник, жаловалась, как сложно читать и пересказывать научные статьи. Он решил помочь и за пару вечеров собрал MVP — SciSummary, сервис, который автоматически сокращает и упрощает академические тексты.
💡 Проект запущен в январе 2023. Уже через 3 месяца с помощью Google Ads, SEO и пары постов у инфлюенсеров сервис начал приносить $1k в месяц. В это же время он узнал, что скоро станет отцом, поэтому не стал рисковать и продолжал работать по найму (его зарплата — $250k в год), а проект развивал в свободное время (~20 часов в неделю).
📈 Спустя год: – Проект стабильно генерирует $25k MRR – В команде 6 удалённых фрилансеров – Более 700 тысяч пользователей – ARR — около $400k
🔥 В 2024 он продал 85,5% проекта, но остался в нём ведущим инженером. Причина продажи — выгорание от постоянной нагрузки и желание больше времени проводить с ребёнком.
«После сделки чувства были смешанные — радость, тревога, оцепенение. По сути, моя жизнь не изменилась. Я всё так же просто работаю».
⚙️ Что важно вынести из этого кейса:
Сторонний проект можно построить в режиме «вечернего» фриланса, если выбрать близкую нишу и не изобретать велосипед в технологиях.
Маркетинг — решает. Без грамотного продвижения даже самый полезный pet-проект останется никому не известным.
Выгорание реально. И даже любимое дело может начать давить, если работаешь без остановки 60 часов в неделю.
🎮 Автор проекта в своём профиле скромно пишет: «Люблю кодить, играть в игры и пить пиво». А по факту — запустил сервис с ARR $400k, пока качал коляску на выходных.
🔗 Я веду Telegram-канал, где разбираю такие истории и делюсь собственными экспериментами в инди-хакинге и запуске микро-продуктов. Ссылка — в профиле.
Когда мы говорим о B2C-продуктах, масштабируемости и высокой марже — мобильные игры здесь как по учебнику. Ещё 15 лет назад они выглядели как примитивные поделки. Сегодня — это полноценная индустрия с оборотом в десятки миллиардов долларов.
🚀 Взлёт: от пивного бюджета до миллиардов
Мобильный гейминг взлетел не потому, что стал «круче», а потому что оказался на стыке нескольких трендов:
Взрывной рост смартфонов
Когда телефоны стали массовыми, спрос на развлечения в кармане резко вырос. И на старте предлагать было особо нечего — качали всё подряд.
Минимальный порог входа
Игры весили до 100 МБ, не требовали консоли или отдельного железа. Зашёл в App Store — и ты уже в игре.
Free-to-play модель
Играешь бесплатно, а потом тебя ловко подводят к донату. $1–2 за ускорение, $5 — за бонус, $10 — за редкий предмет. Модель оказалась настолько эффективной, что средний чек у активных игроков доходил до $100 в месяц. А у самых "преданных" — до $10k.
Постоянный контент и удержание
Каждый день — что-то новое: улучшения, события, скины, ивенты. А ещё push-уведомления, которые не давали забыть про игру ни на минуту.
Безумные выручки
Некоторые тайтлы зарабатывали десятки миллиардов:
Honor of Kings — $15 млрд
Clash of Clans — $10 млрд
Candy Crush Saga — $10 млрд
PUBG Mobile — $9 млрд
Pokémon GO — $8 млрд
📉 А теперь — стагнация
Начиная с 2021 года рост замедлился. И если в 2018–2021 гейминдустрия на мобилках росла в среднем на 13% в год, то за последние 3 года — всего на 1,7%.
Почему так вышло?
Переедание контентом
Пользователи устали. Игр стало слишком много. Люди стали меньше играть — и меньше платить.
Пандемийный пузырь лопнул
Во время COVID-локдаунов — скачивания взлетели, доходы выросли. Но после снятия ограничений начался откат.
Проблемы с трафиком
Привлечение пользователей подорожало в 2–3 раза, а конверсии и LTV упали. Маркетинг стал затратным, особенно после изменений конфиденциальности от Apple (App Tracking Transparency) — до 96% пользователей отказались от отслеживания.
Никто не хочет инвестировать в стагнацию
Новых команд не нанимают, новые проекты не запускают. Рост? Его больше никто не ждёт. Прогноз на 2025 год — всего 2%.
💰 Зато магазины в плюсе
Google и Apple продолжают стричь комиссию: 15–30% с каждой покупки. Это миллиарды долларов ежегодно. Они активно продвигают игры в сторах и даже выкупают телерекламу для крупных тайтлов.
🎮 Так за 10–15 лет мобильный гейминг из забавы «на сдачу» стал самой прибыльной вертикалью в индустрии. А теперь — взрослеет. Медленно. Без хайпа. Но всё ещё с гигантскими деньгами внутри.
Если вам зашло — я веду Telegram-канал, где делюсь своими экспериментами в запуске приложений и микро-SaaS-проектов.
Приземляется не только публичный фондовый рынок, но и непубличный. В России началась волна банкротств, которая затронула пока в основном непубличные компании. Одним из возможных банкротов оказалась SR Space – как она себя позиционировала, первая частная аэрокосмическая компания в России.
Она занимается занимается разработкой сверхлёгких и лёгких ракет-носителей, малых спутников и ПО для аэрокосмической отрасли. Ну и дронами не в последнюю очередь. И идея, в целом, здравая, т.к. спрос на дроны высокий.
📡Кроме того, SR Space планирует создать четыре спутниковых группировки, включая SR Net — аналог системы Starlink.
Короч, планы грандиозные, но что-то пошло не так.
😳По итогам 2024 года компания показалаприрост выручки на 20% до 53,8 млн рублей, однако чистый убыток просто космический (сори за каламбур): −154 млн рублей! Т.е. компания потеряла денег в 3 раза больше, чем заработала.
В октябре 2024 года SR Space провела раунд pre-IPO на площадке MOEX Start – официальной площадке Мосбиржи. Однако роудшоу и перспективы компании инвесторов не впечатлили (хотя вроде как размещение на Моське говорит о «крутости» эмитента), в результатеона набрала всего 1,5% от запланированной суммы инвестиций – а именно 23,5 млн рублей.Ну просто слёзы, если честно.
⚡️И вот в апреле 2025 года прозвучал первый сигнала набата:ФНС приостановила операции по счетам SR Space из-за кассового разрыва, вызванного задержками поступлений по контрактам. SR Space тогда отбрехалась, что это свойственно для стартапов (ну это действительно так), однако тот факт, что компания не смогла покрыть кассовый разрыв, например, займами или выпуском облигаций, настораживает.
‼️И вот2 июля ФНС подаёт иск о банкротствероссийского «Virgin Galactic». Причина – задолженность, связанная с кассовым разрывом и временной блокировкой счетов в нескольких банках.
Гендиректор Олег Мансуров опровергает это, заявив, что компания продолжает работу – более того, она находится в процессе привлечения инвестиций. По его словам, задолженность порядка 5 млн рублей будет погашена в ближайший месяц, а иск ФНС связан именно с процессом привлечения инвестиций и не означает фактического банкротства.
И действительно, Согласно информации ресурса «Прозрачный бизнес» (создан ФНС), в начале мая 2025 года задолженность SR Space по налогам и сборам составляла 4,9 млн руб.
💸Прямо сейчас компания, по словам Мансурова, закрывает раунд А по привлечению инвестиций и готовится к IPO в обозримой перспективе. Сумма привлечённых инвестиций, правда, не разглашается.
И вот тут два очень неприятных момента:
Либо SR Space реально банкроти делает хорошую мину при плохой игре – тогда даже не нужно разбираться, почему так получилось: заказчики провели, деньги потратили не туда или же не справились с амбициозными планами. В любом случае деньги инвесторов будут потеряны.
Либо SR Space как стартап сталкивается с типичными проблемами и их преодолевает (и это нормально), ноих почему-то кошмарит ФНС. А это в России тоже ничем хорошим не заканчивается. Пример Qiwi и недавних техничных национализаций бизнеса не дают об этом забыть.
‼️В обоих случаях – красный флаг.
Вот так. Не взлетел SR Space, в общем.
Уважаемые коллеги, приглашаю в телеграм-канал, в котором я разбираю финансовые отчёты, анализирую бизнес компаний, а также даю комментарии и отвечаю на ваши вопросы https://t.me/+FDM_-iCEH8Q3NTg6
Привет. Я продолжаю разрабатывать сервер для Lineage 2 C1 на JavaScript Проект
При добавлении SoulShot функционала не добавил проверку не только на наличие оружия, но и кто атакует — игрок или NPC.
Как итог теперь все атакуют с помощью SoulShot.
Задача таких приборов преобразовать инфракрасный свет в видимый человеку диапазон. Сейчас их купить можно за одну минималку.
Почти весь тырнет считает, что первенцами в разработке ПНВ были немцы, в конце 1944, начале 1945. А вот нифига подобного.
Подобные девайсы разрабатывал и СССР в конце!!!! 30х годов (жалко, что данные девайсы были крайне редки).
Архангельский В.И. Наш первопроходец в области телевидения
Да, именно он занимаясь проблемой передачи картинки по радио не ограничился видимым спектром для глаза человеческого. А задумался об инфракрасном диапазоне и к 1937 году вместе с Тимофеевым П.В. сделал первые в СССР электронно-оптические преобразователи типов Ц-1 и Ц-2, которые вполне неплохо пахали в инфракрасе..
Параллельно с ними (а возможно и по заказу нарком обороны) ещё один гражданин СССР разрабатывал совсем не гражданскую хрень, а именно планирующую торпеду, которая должна была сбрасываться с самолёта.
Валк Сигизмунд Натанович ломает голову как же попасть сброшенной с самолёта торпедой в корабль врага
На помощь товарищу Валку С.Н. как раз и пришли разработки товарища Архангельского. Двиглы кораблей весьма ощутимо греются, потому засечь их инфракрасный след в холодных водах достаточно легко. Осталось присобачить инфракрасные тепловизоры и разработать систему наведения. Систему назвали "Квант" и испытвали с 1937 по 1938 года на ТБ-3, которому, по реультатам испытаний ноша такая не нравилась (ТБ-3 и сам по себе был еле-еле двигающимся а тут повышенная бомбонагрузка вообще сделала его слоном на льду (масса самой торпеды порешала))
Интересно, это случаем не самые первые самонаводящиеся снаряды? Если кто знает - пишите в комментах/пилите посты.
Но так же, приборы основанные на разработках Архангельского начали испытывать на танках.
Экспериментальный БТ-7 с ПНВ
Увы, Наркому обороды девайс понравился и они хотели пустить его в серию, но 1КВт электромощностей (полторы лошади с двигла снять) для инфра-прожектора, и низкая дальность обзора всего в 50 метров для танки бесполезно.. Испытания и доводки проводились с 1937 по 1939 года.
Увы. Мы не успели, и начало Великой Отечественной отодвинуло данные разработки на второй план, а жаль. Ещё бы пару лет и в серию....
Всем привет. Меня зовут Максим. Являюсь веб-разработчиком и сейчас поставил цель разработать два своих небольших проекта и довести дело до продаж.
Вообще имею большое кладбище стартапов. Их конечно нельзя назвать полностью неудачными, т.к получал с них опыт, что очень важно и полезно.
Но сейчас решил изменить подход к разработке, развитию проектов. Одно из изменений - вести заметки и делиться удачным, неудачным опытом. Возможно это поможет довести проекты до конечной цели и вполне возможно опыт, которым поделюсь будет кому-то полезен.
Для разработки выбрал два проекта: система лояльности для небольшого бизнеса и seo-мониторинг сайтов. Пока без подробностей.
Точка отсчёта - 22 мая 2025 года. Релиз seo-мониторинга - 1 июля 2025 года, система лояльности - 1 августа 2025 года.
Первый раз при разработке своих проектов сделал оценку трудозатрат и будет интересно сравнить ожидание и реальность.
Также посоветовали больше писать о проектах, делиться мыслями. Будет конечно трудно, но попробуем)
В первой главе мы с вами узнали, как и где создавались первые "шахматные автоматы", которые были всего лишь имитаторами программируемых шахматных роботов. Сегодня знакомство с первыми настоящими шахматными алгоритмами и программами.
*** Глава 2. Как роботы научились играть в шахматы ***
Чтение советской и американской прессы 70-х годов прошлого XX-го века оставляет приятное послевкусие.
Конечно, нельзя было говорить о дружбе между СССР и США, но отношения явно улучшились по сравнению с послевоенными годами.
В американской прессе мелькают сообщения о смягчении давления американской бюрократии на Коммунистическую партию США. В частности, в 1973 году федеральный окружной суд в Аризоне постановил, что большая часть закона против американских коммунистов неконституционна, и Аризона должна допустить КП США к участию в голосовании на всеобщих выборах ("Блавис против Болина").
В советской прессе насмешки над убогим мещанским западным (в основном американским) образом жизни продолжались (в духе Михаила Задорнова "ну, тупые"). Но при этом явно начала изменяться эмоциональная окраска этих насмешек. Злая язвительная сатира потихоньку менялась на добродушный юмор с весёлыми приколами.
Вот мы читаем сообщение о нищем, который обитает на богатой парижской помойке. Ничего особо интересного в этом факте нет. Не было никакого секрета в том, что на этом Западе нищих огромное количество, как блох на бродячей собаке. Но именно в этом нищем была интересная изюминка. На своём плакате, ниже стандартного объявления "подайте плиз, кто сколько может жертве холокоста, бюрократии и бездушия", нищий сделал странную и наглую приписку "доллары США не принимаю".
Не знаю, придумал журналист эту хохму, или реально зафиксировал нечто подобное, но эта короткая заметка порождает у читателей множество мыслей, начиная от надежд, что долларовая долговая пирамида скоро рухнет до желания дать нищему полезный совет: "бери, дурачок, что дают, потом ненужное выбросишь".
Учёные экономисты по обе стороны океана начинают осторожно высказывать идеи о возможности "конвергенции" капитализма и социализма. При этом, в США должны усилиться социальные гарантии для трудящихся, а в СССР для "деловых людей" должны быть предоставлены возможности для полезных экономических частных инициатив (типа строительства личных дач и не только).
Самое главное, что в такой атмосфере о прямом военном конфликте не могло быть и речи. Решались вопросы о возможностях сотрудничества в разных областях.
В 1972 году в Москве председатель Совета министров СССР Алексей Косыгин и президент США Ричард Никсон подписывают "Соглашение о сотрудничестве в исследовании и использовании космического пространства в мирных целях". В 1975 году в рамках этого соглашения был реализован совместный полёт советского и американского пилотируемых космических кораблей со стыковкой на орбите (знаменитый проект "Союз - Аполлон").
Вот в таких условиях мирной конкуренции и делового сотрудничества СССР и США с явным желанием обеих сторон уйти от прямых военных столкновений в 1974 году состоялось грандиозное событие для всех любителей шахмат и прикладного программирования: первый в мире чемпионат мира среди шахматных программ.
Состоялось это мероприятие в Стокгольме во время конгресса ИФИП (IFIP, International Federation for Information Processing).
Лидерами в области шахматного программирования были американцы. В США было 50 действующих шахматных программ, во всем остальном мире (Европа + СССР) около 20. Также в США уже был богатый опыт проведения внутренних чемпионатов. Последний чемпионат США стал отборочным к первому чемпионату мира. Лучшими оказались программы: "Чесс-4.0", "Теч-2", "Хаос" и "Острич". Они и представляли США на этом турнире.
Что же касается нашей страны, то у нас в боевом режиме была единственная программа "Каисса" и ещё несколько программ в стадиях подготовки и перспективной разработки. Именно "Каисса" и представляла СССР на этом турнире. По итогам турнира "Каисса" заняла первое место и завоевала золотую медаль весом 110 грамм.
После окончания турнира "Каисса" в виде бонусного трека сыграла дополнительную товарищескую партию с лучшей американской программой "Чесс-4.0". После долгой и упорной борьбы партия завершилась вничью.
Насколько сильно играли лучшие компьютерные программы в 1974 году? Мне представляется, если бы они играли в сегодняшних (2025 год) турнирах для людей, например, на популярном шахматном сайте "ЛиЧесс", то изначально показывали бы рейтинг в диапазоне 1800-2000 в блице с контролем 5+0. Для сравнения сегодняшние лучшие гроссмейстеры показывают здесь рейтинги 3000+ или, как минимум, около того. А если бы обсчитывали рейтинги современных лучших компьютерных программ типа "Стокфиш" и "АльфаЗирро" при их играх с людьми, то мы увидели бы рейтинги 4000+ или даже 5000+. Короче, эти современные роботы били бы всех людей без малейших шансов для последних. Примечание. При условии взаимной честной игры, но это уже совсем другая тема.
После первого чемпионата разработчики упорно работали над усовершенствованием своих программ.
В 1977 году состоялся второй чемпионат мира среди компьютерных программ в канадском городе Торонто.
Наша "Каисса" приняла участие и в этом чемпионате. Уже в первом туре чемпионка преподнесла неожиданный сюрприз для всех, включая зрителей, своих разработчиков и присутствовавших на турнире гроссмейстеров и мастеров.
Позиция из партии: "Duchess" - "Каисса", Торонто, 1977. Тур: 1.
"Каисса" до этого игравшая неплохо в этой чуть лучшей позиции вдруг делает ряд странных ходов, начиная отсюда: 29. … а5?
30. g4 Фe6
31. Лc6 a4?
32. Ф:а4 Лd6
33. Л:d6 Ф:d6
34. Фа8+
Здесь все ожидали естественного хода 34. … Крg7
Но "Каисса" вдруг ставит под бой ладью 34. … Лe8 и затем постепенно проигрывает без каких-либо шансов.
После партии, когда Каиссу спросили, в чем дело, она объяснила, что ход 34. ... Крg7 гораздо хуже, чем сделанный ею ход 34. ... Лe8.
В доказательство "Каисса" показала такой вариант:
34. ... Крg7 35.Фf8+! Крxf8 36. Сh6+ Сg7 37. Лc8+
"Каисса" демонстрирует вариант, которые не увидели даже гроссмейстеры
37. … Фd8 38. Л:d8+ Лe8 39. Л:e8X.
Специалисты, среди них были гроссмейстеры Ботвинник, Эдуард Ласкер, Ганс Берлинер, канадский международный мастер Леон Пиасетский эту комбинацию не обнаружили и объясняли народу этот заскок Каиссы "несовершенством шахматных программ".
В конечном результате турнира Каисса разделила 2—3 места с программой Duchess. Победила в чемпионате программа "Чесс-4.0".
До сих пор идут диспуты, а увидела бы программа Duchess во время партии этот выигрывающий ход 35.Фf8+
Далеко не факт, учитывая, ограниченность времени на обдумывание в турнирной партии.
В любом случае, если ход 34. ... Лe8 объективно сильнее (т.к. затягивал поражение на много ходов), то никто не будет спорить, что практических шансов больше у скромного хода 34. ... Крg7
Мне стало любопытно, а как бы в критической позиции пошла бы современная программа: 34. ... Лe8 или 34. ... Крg7 - ?
Я задал этот вопрос "Стокфишу" и получил ответ: 34. ... Лe8
Вот так!
Такие тонкие психологические моменты не понимали шахматные программы в 1977-м году, не понимают их они и сейчас, в 2025-м.
Возьмем этот факт на заметку, он нам пригодится для дальнейших рассуждений.
А как вообще роботы научились играть в шахматы? Точнее говоря, кто был их первым учителем?
Вообще говоря, много умнейших людей брались за эту интереснейшую проблему и решали её с разной степенью успеха.
Традиционно считается, что самым первым шахматным программистом в мире был Алан Тьюринг. В 1951 году он написал алгоритм Turochamp, с помощью которого машина могла бы играть в шахматы. Самое забавное, что это был чисто теоретический труд. У Алана не было компьютера, чтобы проверить свою программу на практике.
Тем не менее, его идеи были использованы другими учёными, а идеи тех, в свою очередь, новыми учёными, и вот, что мы имеем в сухом остатке.
Попробуем набросать примерный алгоритм игры в шахматы.
Что нам нужно сделать? Написать программу, которая умеет находить сильнейший ход в любой позиции.
Немного подумав, почитав разных полезных статей, становится ясно, что тут есть 2 принципиальных краеугольных камня.
Функция, которая оценивает позицию (оценочная функция).
Функция, которая как-то умеет определять максимальную глубину просмотра.
Давайте, попробуем набросать функцию, которая оценивает позицию.
Для простоты пока сделаем глубину просмотра равную одному полуходу и анализировать будем начальную позицию.
Примечание. Пусть будет 0.1 балл за одно свободное поле под атакой.
Премия за очередь хода. Пусть пока будет 0. Не уверен, что это вообще хорошая идея.
Проверку на мат проводим. Вообще, вряд ли кому-то будет мат в начальной позиции или после первого полухода. Но проверять надо.
Оценка позиции = Белые - Черные = (38.2+18)-(38.2+18) = 56.2-56.2 = 0
Теперь нам надо подобным образом оценить все позиции после всех возможных ходов.
Оценка позиции после 1-го хода белых
Ход Баллы
a3 0.0
a4 0.2
b3 0.2
b4 0.2
c3 0.2
c4 0.3
d3 0.6
d4 0.7
e3 0.9
e4 0.9
f3 0.0
f4 0.1
g3 0.2
g4 0.2
h3 0.0
h4 0.2
Кa3 0.1
Кc3 0.3
Кf3 0.3
Кh3 0.1
Получается следующий результат. Если применять данную оценочную функцию и использовать глубину расчета на 1 полуход, то в данной позиции получаются лучшие ходы: e3 или е4.
Теперь мы можем уточнить оценку начальной позиции. Если изначально она была равна 0, то после первого полухода стала равной 0.9.
Разумеется, если мы посмотрим чуть глубже (т.е. оценим все позиции после всех возможных 2-х полуходов), то оценка начальной позиции опять изменится. Наверное, она опять станет равной 0, например, после 1. e4 e6.
А если посмотреть немного глубже, хотя бы на 20 полуходов? Все это, конечно, можно сделать, посвятив этому процессу месяц или два, но это уже всё сделано до нас.
У проекта появилась чёткая архитектура управления сущностями. Теперь NPC, игроки, питомцы и другие объекты взаимодействуют в мире через систему менеджеров — рассказываю, как это работает.
В игровом мире есть разные типы сущностей: NPC, игроки (Player), питомцы (Pet) и другие. Каждая из них имеет свои состояния (движение, атака, бездействие) и требует управления.
Основные сущности и их поведение
• NPC – управляет собой (перемещение, атака, idle).
• Player – управляется игроком (те же состояния: ходьба, атака и т. д.).
• Pet – похож на NPC, но принадлежит игроку.
Менеджеры и их задачи
1. NpcManager – создаёт NPC, реагирует в случае смерти NPC.
2. PlayersManager – отвечает за вход игроков в мир.
3. PetsManager – управляет питомцами (аналогично NPC, но с привязкой к игроку).
4. EntitiesManager – главный координатор:
o Управляет NpcManager и PlayersManager.
o Обрабатывает взаимодействия (например, если игрок подошёл к NPC, оба получают информацию друг о друге).
5. VisibilityManager– отвечает за видимость объектов:
o Определяет, кто кого видит.
o Периодически обновляет списки видимости для оптимизации.
6. MovingManager – обновляет позиции всех подвижных объектов в мире.
Помните как мы бегали по горам и не придавали значение тому как быстро спускались или поднимались на них?
Как мы знаем в реальной жизни перемещаясь на плоскости горизонтальная скорость у нас постоянная.
Как только мы начинаем преодолевать горы и другие неровности то горизонтальная скорость у нас будет меньше.
Но не в мире Lineage 2 где горизонтальная скорость всегда постоянная и нее зависит от неровностей.
Связанно это с тем чтобы было проще синхронизировать персонажа на сервере и клиенте.
Ведь на сервере нет точной модели мира, а лишь примерное очертание называемое geodata.
А из-за того, что geodata приблизительно повторяет ландшафт клиента то было бы невозможно синхронизировать персонажа по Z оси.
Поэтому синхронизация идет только по X и Y оси.
Видео:
1) Горизонтальная скорость на плоскости постоянная.
2) Как было бы в жизни. Взбираясь на гору горизонтальная скорость падает.
3) Как сделано в игре. Горизонтальная скорость постоянная.
4) Демонстрация из игры. Бежит словно нет никаких гор.
Я разрабатываю эмулятор сервера для Lineage 2 Chronicle 1: Harbingers of war на Node.js.
Столкнулся с проблемой синхронизации скорости персонажа на сервере с клиентом. Когда в игре вы нажимаете мышкой в то место, куда хотите перейти то происходит плавный переход с анимацией движения. На сервере в этот момент тоже происходит движение по таймеру, но не такое плавное.
GIF
GIF
C(client) – двигается плавно из одной точки в другую. S(server) – делает прирост координат по таймеру.
Для примера я взял сборку написанную на java l2j-lisvus Сборок много. Но все они являются fork’ами проекта l2jserver https://l2jserver.com/И многое наследуется. В том числе и передвижение персонажа.
В l2j-lisvus, как и во всех сборках l2jserver перемещение персонажа на сервере идет при помощи таймера с приростом одинаковых значений.
Проблема проявляется, когда нам надо сделать какое-то действие после того, как персонаж добежал до пункта назначения. Например, нанести удар по NPC.
GIF
На коротких расстояниях проблема незаметна. Нога наступает точно в монету.
GIF
На длинных расстояниях действие атака начинается раньше, чем персонаж добегает до цели.
GIF
А если выкрутить скорость на максимум (900) то проблема расхождения очевидна. Это связанно с тем, что помимо скорости бега есть скорость ходьбы.
Как работает передвижение персонажа на сервере.
За основу взяты базовые характеристики персонажа. Скорость бега 126.
126 — это количество внутренних unit’ов за секунду.
На данной схеме идет прирост координат персонажа каждые 1000мс на 126 unit’ов. Исходя из схемы выше пример кода для действий персонажем после достижения пункта назначения:
// Прироста координат нет. Просто считаем когда персонаж дойдет до конечных координат. const distance = 1500; const playerSpeed = 126; const ticks = distance / playerSpeed; // 11.90 const time = ticks * 1000; // 11900mc
setTimeout(() => { // действие персонажа после бега }, time);
GIF
На коротких расстояниях.
GIF
На длинных расстояниях.
Расхождения на коротких расстояниях.
Расхождения на длинных расстояниях.
Зеленой зоной показана точка куда должна ступить нога персонажа если бы не было расхождений.
Рост скорости при развитии персонажа.
126 — это базовая скорость. И по мере развития персонажа будет расти и скорость передвижения. А значит расхождение будет больше. Но перед тем, как создать формулу надо подтвердить теорию, что скорость ходьбы влияет на расхождение.
Данные о характеристиках персонажа передаются от сервера к клиенту.
Выставляю значения walkSpeed: 126. Если скорость ходьбы будет равна скорости бега, то расхождения должны пропасть.
GIF
Нога персонажа достигает правильной конечной точки.
Персонаж синхронизирован и начинает атаку вовремя. Теперь надо понять, как скорость ходьбы влияет на расхождения между клиентом и сервером.
Сколько же персонаж успевает пройти перед тем, как начинает бежать?
Надо поймать момент когда ходьба переходит в бег. Для этого передадим в клиент данные, где скорость ходьбы будет больше скорости бега. Из-за этой разницы будет виден переход и можно будет рассчитать пройденное расстояние при ходьбе.
runSpeed: 10
walkSpeed: 600
GIF
Ходьба быстрее бега.
При скорости шага в 600 персонаж успевает пройти 250, прежде чем начинает бежать.
600 / 250 = 2.4
700 / 291 = 2.4
800 / 333 = 2.4
Из этого вывод, что персонаж перед тем, как начать бежать успевает пройти расстояние в 2.4 раза меньше, чем его скорость ходьбы.
Значит при скорости ходьбы 88 персонаж пройдет 36 unit’ов.
88 / 2.4 = 36
Первое деление — это начало движения (ходьба) а следующие деления — это бег.
Проводить оценку производительности при реальной нагрузке в продуктивном контуре, а не на тестовом стенде.
Не иметь метрик производительности информационной системы, оценивать производительность по обратной связи пользователей — «ой стало медленно работать».
Не проводить тестирование последствий изменений инфраструктуры на тестовом стенде, сразу проводить изменения в продуктивном контуре.
Воспринимать СУБД как черный ящик для хранения данных.
Не привлекать DBA к процессу дизайна и разработки.
[ Использовать ORM для взаимодействия с СУБД.] : по итогам дискуссии в комментариях - пункт исключён из списка особенностей.
Не анализировать коды ошибок СУБД в backend.
Не проводить нагрузочное тестирование.
Пытаться решать проблемы деградации производительности информационной системы путем подбора магической комбинации конфигурационных параметров СУБД и увеличением ресурсов серверов.
Запустить десяток SELECT ... FOR UPDATE и удивляться - почему всё тормозит.
Семь бед - один ответ. Ставь костыль изобрети велосипед.
Всем доброго времени! Наткнулся я не так давно на вот такое изображение:
И решил порассуждать не тему того, а плоха ли такая ситуация и как вообще бывает, как идет разработка backend и frontend в вещах которыми я занимался, возможно кому то будет интересно, а кому то захочется подискутировать со мной)
Во первых о понятиях, что такое "Бекенд" и "Фронтенд", я работал с разными разработчиками и даже студиями и понял что иногда эти понятия отличаются у разных людей (особенно когда речь идет о том как HR их понимает), по этому поясню что я в них вкладываю:
Frontend - "передний конец", это весь визуал который видит человек пользуясь программным обеспечением, а так же скрипты которые исполняются на стороне (на устройстве) пользователя.
на примере сайта, это его верстка, а так же javascript который перелистывает слайды, раскрывает выплывающие окна и т.д.
Backend - "задний конец", это всё что исполняется "под капотом" программы, в случае сайта это на сервере, в случае какой то настольной программы, внутрипрограмные механизмы, например обращающиеся к каким то функциям операционной системы и производя какие то расчеты и действия
на примере сайта, это его серверная часть, механизмы которые к примеру работают с базой данных, получают из неё пост для страницы на которой находится пользователь, и к примеру комментарии для этого поста и т.д.
А теперь как раз о том, что разрабатывается первее и почему.
Возьмём вебсайт, вы например хотите что бы вам сделали интернет магазин, обычно этапы разработки выглядят так:
- Создание и утверждение дизайна
- Верстка дизайна
- Подключение к верстке т.н. "Движка" или cms или "системы управления контентом", или же что очень редко и индивидуально, написания этой самой системы с нуля в порядке индивидуальной разработки и внедрения её в вёрстку.
т.е. по сути тут выходит что разработка Бекенда идёт после Фронтенда - и получается что как будто то что показано в меме это естественный ход событий и ни каких вопросов это не может вызывать?
Стоит сказать что последовательность работ которую я описал, это обычно усреденная разработка, где люди не сильно запаиваются составлением подробных ТЗ. По ней выходит то что когда готов дизайн, и на основе него вёрстка, это всё передается программисту работающему над Бэекендом, и он сразу видит, что и где ему нужно будет подключать и в каком виде: "Здесь у нас поиск, с возможностью сортировки и выбору диапазона дат постов", "Тут мы выводим чат, который обновляется каждые пару секунд" и т.д. Программист сразу визуально видит какие данные в какие элементы интерфейса ему нужно выводить, от чего ему более понятен план работ, по тому что он "визуален".
Но предположим что сроки разработки сжаты, и требуется что бы разработка обоих частей проходила одновременно, в таком случае необходимо очень точное техническое задание, где будет подробно прописано то как будет работать бэекенд, какова будет структура базы данных, какие данные при каких обстоятельствах будут из неё извлекаться, каким образом обрабатываться, в каком виде перезаписываться обратно и в какой части условного ещё не созданного даже в виде дизайна интерфейса отображаться.
Это довольно фантастический план, так как обычно не бывает заказчиков которые чётко знают как должен выглядеть их сервис\сайт\по и даже не всегда представляют себе точный его функционал.
Это всё зачастую формируется как раз во время разработки и утверждения дизайна, и по этому программист который с самого старта одновременно с дизайном начал разрабатывать свой бекенд, чаще всего обречен по ходу появления дизайна и вёрстки вносить коррективы в свою работу, а иногда даже переписывать её часть.
Но есть например аспекты которые можно на мой взгляд проработать и без дизайна, например структуру базы данных и её таблиц, создать какие то общие функции, провести базовую настройку движка или фреймфорка с которым будет работа.
Но всё же когда дизайн утверждён и верстка окончена и принята заказчиком, это уже гарантирует стабильность разработки. (при условии конечно если заказчику не взбредёт в голову что то на ходу изменять, но такие вещи должны быть учтены в договоре и проходить за дополнительную оплату)
Примерно то же самое происходит и при разработке приложения для телефона.
Программисту всегда проще подключать бекенд к чему то готовому, чем прорабатывать так называемые API (простым языком объясняя это точки доступа через которые интерфейс получает данные из бекенда) почти в слепую или по скупому ТЗ (я просто ещё не видел по настоящему подробных ТЗ за исключением тех которые в своей педантично душной манере составлял).
По этому становится очевидно что это вполне себе нормальная ситуация, когда Фронтенд давно готов, на него можно посмотреть, потыкать, а Бекенд ещё только подключается, а то ещё и вовсе в стадии разработки.
Но есть один сценарий когда бекенд идёт первее фронтенда - это когда разрабатывается какое то техническое программное обеспечение у которого изначально вовсе нет интерфейса, например какой нибудь локальный сервер - пишется собственно сама програмина, а её настройка и в целом взаимодействие с ней происходит через терминал\консоль\командную строку.
В данном случае интерфейс появляется уже после того как ПО было разработано, зачастую таким программным обеспечением можно пользоваться и без интерфейса через всё тот же терминал, отправляя команды которые ты вводишь в него вручную (прям как хакер из кинофильма), а графический интерфейс создаётся уже потом(иногда очень сильно потом) просто для удобства пользователя и отображает все стандартные и часто используемые опции (для более тонких настроек за частую используется всё равно командная строка) и по сути графический интерфейс, отправляет те же самые команды что вы бы вводили в терминал, просто делает это по нажатию на кнопочки.
На этом всё, надеюсь кому то было интересно почитать эти возможно сумбурные рассуждения, сейчас попробую выловить все грамматические ошибки в этом опусе, перед тем как нажать кнопку "опубликовать пост"😅
