Сохраняй посты, комментируй и ставь оценки
Иногда попадаются интересные комментарии.
В программировании комментарии есть лишь пояснения в отношении кода, а не как на сайтах, где комментарий - это ответ.
В зависимости от ЯВУ комментарии могут отделяться по-разному. В JS/TS и С/С++ используются двойная косая или косая и звёздочка.
А теперь матюки. На английском.
Учитывая, что EditorJS используется и на Вомбате, то эти матюки актуальны и здесь 🤭
Привет. Я продолжаю разрабатывать сервер для Lineage 2 C1 на JavaScript Проект
Работая с предметами, создал фичу — многослойный щит 😂
Блог про разработку сервера для Lineage 2 в телеге https://t.me/lineage2js
No-code выглядит соблазнительно.
Не надо учиться кодить. Разработчики не нужны. Накликал интерфейс - и запускай единорога.
Звучит красиво.
А на деле - быстро превращается в болото.
Недавно видел пример: ребята сделали приложение для изучения испанского языка на no-code.
Через месяц им пришлось переписать всё на код.
Причина простая - костыли.
И это не открытие. Я ещё лет десять назад видел такие штуки.
Delphi, Microsoft Access, Lotus Notes, позже Oracle APEX — там тоже можно было натыкать кнопочек, набросать интерфейс, и оно даже работало.
Но стоило захотеть что-то серьёзнее - и упираешься в потолок платформы.
В итоге такие проекты либо переписывают, либо бросают.
No-code повторяет ту же историю.
Хочешь добавить функцию - нельзя. Делаешь костыль.
Хочешь ещё - снова костыль.
Через месяц костылей так много, что проект перестаёт развиваться.
Да, есть исключения. Специализированные инструменты работают классно.
Тильда для лендингов. Airtable для таблиц. Retool для дашбордов.
Но это не «замена программистов», а «ускоритель для специалистов».
А универсальные конструкторы «сделай любое приложение без кода» - это мираж.
Ты вроде строишь продукт, а на деле собираешь небоскрёб на болоте.
Я сам часто запускаю проекты и пишу про эти попытки, удачные и не очень.
Так что тема no-code для меня не теория, а наблюдения из практики.
Привет. Я продолжаю разрабатывать сервер для Lineage 2 C1 на JavaScript Проект
В первом же квесте Fighter's Tutorial (даёт SP и карту мира) столкнулся с любопытным моментом. Охота на внешне одинаковых NPC, но на деле разных!
Речь пойдет только о квесте для людей на острове Talking Island Village.
В чём подвох?
В мире Lineage есть два NPC с одинаковым именем - Bearded Keltir.
Внутри сервера это разные NPC: ID 12082(tuto_keltir) и ID 481(keltir).
По квесту Fighter's Tutorial надо добыть Keltir Fang.
Убивайте Bearded Keltir, пока не получите Keltir Fang x4.
Как различать Bearded Keltir?
У этих NPC есть несколько зон spawn'a. Некоторые зоны пересекаются и в одной зоне могут находиться разные Bearded Keltir.
Так например если вы решите проходить квест возле Talking Island Village то вот на что надо обратить внимание:
* Keltir Fang падает с шансом в 100%. Если не упал, то вы убили не того NPC.
* С нужного Bearded Keltir не падает дроп. Дроп у ID 12082(tuto_keltir) отсутствует.
Вывод
Лучше всего проходить квест возле Cedric's Training Hall так как там одна из зон появления Bearded Keltir они же ID 12082(tuto_keltir).
Блог про разработку сервера для Lineage 2 в телеге https://t.me/lineage2js
Инди‑разработчик одновременно пишет код, рисует иконки, настраивает аналитику и считает, хватит ли выручки, чтобы дожить до следующего релиза. В голове при этом орут шесть голосов — от художника‑перфекциониста до паникёра, который шипит: «не лезь в серяк, всё сломаешь». Недавно я это сполна почувствовал, когда на финальной прямой запуска моего расширения для Chrome под Европу Google заблокировал рекламный кабинет — весь запуск был заточен под поисковый трафик, и в один момент канал просто исчез.
Расширение жило за счёт идеи: забираем тёплый поисковый трафик из Google Ads, ведём на продукт, дальше монетизируем. Аудитория — Европа, так что нормальной альтернативы Google по объёму и качеству трафика, по сути, нет. На финальной части запуска, когда оставалось включить бюджеты и смотреть на конверсии, рекламный кабинет схлопнулся по политике: без внятных объяснений, с размытыми формулировками и стандартной отпиской.
В голове мгновенно нарисовались четыре сценария:
И вот тут во мне в полный голос заговорили все внутренние персонажи — от паникёра до художника. Чтобы не принимать решение «на ощущениях», я вытащил метод шести шляп.
Метод шести шляп — это техника Эдварда де Боно, где мышление делится на шесть режимов: факты, эмоции, риски, выгоды, креатив и модерацию. Вместо того чтобы держать всё в голове одновременно и метаться, ты по очереди «надеваешь» шляпы и смотришь на одну и ту же ситуацию под разными углами.
Для инди‑разработчика это особенно полезно: обычно решения принимает либо внутренний паникёр (чёрная шляпа), либо вдохновлённый художник (зелёная/красная), а белая и жёлтая — факты и выгоды — просто молчат.
Классика такая:
Ниже — как я разобрал свою блокировку Google Ads по этим шляпам.
Сначала — сухие факты без истерики.
На этом этапе задача — увидеть реальность без «всё пропало» и «да нормально, сейчас разбанят».
Здесь вообще не нужен рационал — только то, что ощущается.
Смысл — признать, какие решения ты принимаешь просто из страха или обиды, чтобы потом не маскировать это под «рациональный выбор».
Дальше — максимально пессимистичный взгляд на каждый сценарий.
Чёрная шляпа нужна, чтобы честно увидеть, где ты можешь потерять больше, чем готов.
Теперь тот же список, но с вопросом «что здесь может пойти хорошо?».
Жёлтая шляпа возвращает понимание, что в каждом сценарии есть не только «помереть», но и «выиграть» — вопрос цены и горизонта.
Здесь цель — не выбирать между A/B/C, а придумать C1, C2, D.
Например:
Зелёная шляпа — это место, где из «всё или ничего» появляется несколько ступеней и промежуточных экспериментов.
На этом этапе я собрал всё выше в конкретный план.
Что решил:
Какие метрики для себя отметил:
Синяя шляпа — это момент, когда ты перестаёшь бесконечно «думать» и признаёшь: да, это не идеальное решение, но это проверяемый эксперимент с понятными правилами и горизонтом.
Если у тебя сейчас:
Когда начал прогонять через шляпы не только монетизацию, но и такие аварийные ситуации, стало заметно, что во мне чаще всего орёт чёрная шляпа (паникёр) и иногда красная (обида/страх), а факты и выгоды просто не доходят до стола.
Если тебе заходит формат разборов решений инди‑разработчика (с цифрами, факапами и рабочими фреймворками), залетай в мой Telegram‑канал. Там чаще, короче и местами больнее
Помимо неинтуитивности интерфейса, есть критические ошибки. Например, утеря текстовых полей в черновике, если на создание поста уходит несколько дней. Угарно, что подписи к картинкам сохраняются, но не текст между ними. Просрёшь так самый важный длиннопост этого квартала - и уже не будешь создавать новые. Во всяком случае, не будешь создавать посты с нуля здесь, переносить лишь с других сайтов, а это в совокупности с отсутствием читателей на многие спссфссские топики уже большой шаг в направлении того, чтобы перестать пользоваться Вомбатом вообще. Почему, собс-на, я и перестал постить. Жду начала открытой беты в Лиспублике, по их реализации редактора будет видно, имеет ли ещё смысл иметь амбиции автора в сложившейся ситуации с отечественными развлекательными сайтами.
Сам факт того, что черновик всего один, когда у конкурентов по 10-20, а костыль с отложенной публикацией тоже критически сломан - это отдельный повод держать огнетушитель рядом с креслом.
LLM-модели подарили нам новый тренд в инди-хакинге. В соцсетях пишут, что «ИИ заменит программистов», а разработчики разбирают код от нейросетей и почти всегда приходят к выводу: поддерживать это будет очень больно.
Я сам пишу на Kotlin и считаю его лучшим языком для продакшн-разработки. Но для vibe-кодинга он подходит слабо: слишком мало данных, и модели плохо справляются с нетиповыми задачами. Поэтому почти все мои сайд-проекты сегодня живут на JS и Python.
Ещё недавно для меня это было пыткой. Я привык к статической типизации, и писать на языках с рантайм-проверками казалось болью. Но с появлением GPT всё изменилось. За меня код пишет нейроджун, а я больше внимания уделяю структуре базы, архитектуре и взаимодействию компонентов. В духе «чтобы под транзакцией не ходить по HTTP» и тому подобное.
И тут я поймал инсайт: я даже не собираюсь поддерживать этот код. Проще и дешевле будет переписать всё заново через ту же нейросеть. Получается, код становится одноразовым. А иногда — и целые сервисы. Сгенерировать новый микросервис с нуля оказывается быстрее и выгоднее, чем тянуть старый.
У такого подхода есть минусы. Всё держится на тестах: контрактные тесты, сценарные тесты, чёткие спецификации взаимодействий. Без них это превращается в хаос. Поэтому главный совет для vibe-кодеров звучит так: сначала пишем тесты, а потом генерим код нейросетью.
Я пробую этот подход на своих пет-проектах и делюсь результатами в телеграме 👉 ссылка в профиле
Привет. Я продолжаю разрабатывать сервер для Lineage 2 C1 на JavaScript Проект
Копаясь в серверных файлах наткнулся на пасхалку.
На острове Talking Island Village в храме Einhasad есть два NPC, которые стоят рядом друг с другом и имеют имена Harrys и Petron.
У каждого NPC на сервере есть цифровой ID и текстовый ID.
Так, например, для Harrys(ID 7035) его текстовый ID - Harry, а для Petron(ID 7036) - Potter
Таким образом, если сложить их ID, получится - Harry Potter
npc_beginguild_coach7035[harry]level=70...npc_end
npc_begin
guild_coach
7036
[potter]
level=70
...
npc_end
Блог про разработку сервера для Lineage 2 в телеге https://t.me/lineage2js
В первой главе мы с вами узнали, как и где создавались первые "шахматные автоматы", которые были всего лишь имитаторами программируемых шахматных роботов. Сегодня знакомство с первыми настоящими шахматными алгоритмами и программами.
© 2025 Константин Оборотов
=== Список всех глав
Глава 2. Как роботы научились играть в шахматы *
===
*** Глава 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 году состоялся второй чемпионат мира среди компьютерных программ в канадском городе Торонто.
Наша "Каисса" приняла участие и в этом чемпионате. Уже в первом туре чемпионка преподнесла неожиданный сюрприз для всех, включая зрителей, своих разработчиков и присутствовавших на турнире гроссмейстеров и мастеров.
"Каисса" до этого игравшая неплохо в этой чуть лучшей позиции вдруг делает ряд странных ходов, начиная отсюда: 29. … а5?
30. g4 Фe6
31. Лc6 a4?
32. Ф:а4 Лd6
33. Л:d6 Ф:d6
34. Фа8+
Но "Каисса" вдруг ставит под бой ладью 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 принципиальных краеугольных камня.
Функция, которая оценивает позицию (оценочная функция).
Функция, которая как-то умеет определять максимальную глубину просмотра.
Давайте, попробуем набросать функцию, которая оценивает позицию.
Для простоты пока сделаем глубину просмотра равную одному полуходу и анализировать будем начальную позицию.
Опять же для простоты, чтобы не перенапрягать мозг, возьмем для оценки позиции следующие факторы (первые, которые пришли в голову).
Материал.
Количество пробиваемых полей (ударов по свободным полям).
Премия за очередь хода.
Проверка: нет ли кому-то вообще мата (пата) в данной позиции?
Материал Белые = 2Л*4.5+2К*3.0+2С*3.1+1Ф*9.0+8п*1.0=9+6+6.2+9+8=38.2
Материал Черные = 2Л*4.5+2К*3.0+2С*3.1+1Ф*9.0+8п*1.0=9+6+6.2+9+8=38.2
Количество пробиваемых полей Белые = 14 (пешки) + 4 (кони) = 18 (1.8 баллов)
Количество пробиваемых полей Черные = 14 + 4 = 18 (1.8 баллов)
Примечание. Пусть будет 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 полуходов? Все это, конечно, можно сделать, посвятив этому процессу месяц или два, но это уже всё сделано до нас.
...
Первоисточник:
===
Проводить оценку производительности при реальной нагрузке в продуктивном контуре, а не на тестовом стенде.
Не иметь метрик производительности информационной системы, оценивать производительность по обратной связи пользователей — «ой стало медленно работать».
Не проводить тестирование последствий изменений инфраструктуры на тестовом стенде, сразу проводить изменения в продуктивном контуре.
Воспринимать СУБД как черный ящик для хранения данных.
Не привлекать DBA к процессу дизайна и разработки.
[ Использовать ORM для взаимодействия с СУБД.] : по итогам дискуссии в комментариях - пункт исключён из списка особенностей.
Не анализировать коды ошибок СУБД в backend.
Не проводить нагрузочное тестирование.
Пытаться решать проблемы деградации производительности информационной системы путем подбора магической комбинации конфигурационных параметров СУБД и увеличением ресурсов серверов.
Запустить десяток SELECT ... FOR UPDATE и удивляться - почему всё тормозит.
Ну и конечно, куда же без ВЕЧНОГО
Только , сейчас шаманские камлания называются более современно - митинги и конфколлы. Суть действия же не никак не изменилась.
Как и результат ...
МурМур - это не только про котиков. Это Mergin Request или запрос слияния. Некое изменение кода.
Иногда подобное изменение безболезненно.
Но часто приходится сидеть часами, чтобы принести свои правки к актуальной версии.
P.S. Если вам противна тема разработки, то лучше добавьте меня в игнор.
Термин A-Player сначала звучит как что-то из спорта, но в IT под этим обычно понимают людей, которые тащат команду на новый уровень. И это не всегда «сеньор с 10 годами опыта». Иногда это может быть джун, который смотрит на работу шире, чем просто строчки кода.
A-Player отличается не количеством выданного кода, а подходом. Он думает о продукте, а не о том, чтобы накрутить ещё один сервис ради красоты архитектуры. Он делает жизнь коллег проще, поднимает планку в команде и берёт на себя задачи так, что другим не нужно держать их в голове. С ним процессы двигаются быстрее, а продукт становится лучше. 🚀
Я понял это на собственном опыте, когда начал активно запускать пет-проекты. Там ты одновременно разработчик, продукт, дизайнер, саппорт и менеджер. Ты не можешь спрятаться за «моя часть готова, дальше не моя проблема». Ты видишь весь цикл: от идеи до первых пользователей. И именно это формирует продуктовое мышление, которое отличает A-Player от «просто хорошего кодера».
В стартапах и небольших командах такие люди решают исход проекта. Один A-Player может дать ценности больше, чем пять «средних». Не потому что он пишет в пять раз больше строк, а потому что думает в пять раз шире. Он видит проблемы раньше, берёт на себя ответственность и фокусируется на том, что действительно двигает продукт вперёд.
По сути, каждый пет-проект — это маленький тренажёр 🏋️ для прокачки этих навыков. Ты учишься брать ответственность целиком, думать о ценности для пользователя и экономить время — своё и потенциальной команды. В карьере это очень заметно: такие навыки ценят куда выше, чем знание конкретного фреймворка.
Хочешь стать ближе к A-Player? Начни с простого вопроса: то, что ты делаешь сегодня, делает ли продукт лучше и жизнь коллег проще? Если да — значит, ты на правильном пути.
Я пишу о своём пути в indie-hacking и пет-проектах в телеграме. Если интересно наблюдать за процессом изнутри - ссылка в профиле ✨
Интересная история из мира инди-разработки — парень, не бросая основную работу, построил SaaS-сервис, который спустя два года принес ему крупный exit.
🧪 Началось всё с личной боли. Его жена, научный сотрудник, жаловалась, как сложно читать и пересказывать научные статьи. Он решил помочь и за пару вечеров собрал MVP — SciSummary, сервис, который автоматически сокращает и упрощает академические тексты.
💡 Проект запущен в январе 2023. Уже через 3 месяца с помощью Google Ads, SEO и пары постов у инфлюенсеров сервис начал приносить $1k в месяц. В это же время он узнал, что скоро станет отцом, поэтому не стал рисковать и продолжал работать по найму (его зарплата — $250k в год), а проект развивал в свободное время (~20 часов в неделю).
📈 Спустя год:
– Проект стабильно генерирует $25k MRR
– В команде 6 удалённых фрилансеров
– Более 700 тысяч пользователей
– ARR — около $400k
🔥 В 2024 он продал 85,5% проекта, но остался в нём ведущим инженером. Причина продажи — выгорание от постоянной нагрузки и желание больше времени проводить с ребёнком.
«После сделки чувства были смешанные — радость, тревога, оцепенение. По сути, моя жизнь не изменилась. Я всё так же просто работаю».
⚙️ Что важно вынести из этого кейса:
🎮 Автор проекта в своём профиле скромно пишет: «Люблю кодить, играть в игры и пить пиво». А по факту — запустил сервис с 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-проектов.
Привет. Я продолжаю разрабатывать сервер для Lineage 2 C1 на JavaScript Проект
При добавлении SoulShot функционала не добавил проверку не только на наличие оружия, но и кто атакует — игрок или NPC. Как итог теперь все атакуют с помощью SoulShot.
Блог про разработку сервера для Lineage 2 в телеге https://t.me/lineage2js
Привет! Хочу поделиться своим проектом, который решил возродить пару недель назад — мессенджер на Python. Не сомневаюсь, что такие штуки уже есть на просторах интернета и могут быть лучше того, что делаю я, но меня это не интересует. Мне нравится делать что-то самому, разбираться и по возможности «не зависеть» от чего-то.
Это чат с клиентской и серверной частью, который работает через сокеты. На данный момент всё происходит в консоли, но в планах GUI на PyQt5. Сервер поднимается локально, клиенты подключаются к нему и начинают взаимодействовать с помощью различных команд. Клиент должен иметь аккаунт на сервере для ряда функций, поэтому первым делом он регистрируется либо входит в аккаунт. Показываю команды пользователя ниже.
🔐 Авторизация и регистрация
/reg <юзернейм> <пароль> <пароль> — зарегистрироваться на сервере
/auth <юзернейм> <пароль> — аутентифицироваться на сервере
👤 Профиль и общение
/set_nick <никнейм> — установить отображаемый никнейм
/msg <никнейм> <сообщение> — отправить личное сообщение
/offline_sms — получить сообщения, пришедшие в ваше отсутствие
/get_users — посмотреть список пользователей
📂 Файлы
/all_files [количество] — показать последние файлы (все, если число не указано)
/send_file <никнейм> <имя_файла> [текст] — отправить файл из папки data/files
/load_file <имя_файла> — скачать файл, присланный вам
🛠️ Системные
/help — показать эту справку
/exit — выход из программы
На сервере я сделал CLI-команды для админа:
/users_dict — посмотреть словарь с пользователями
/close_server — безопасное закрытие сервера
/help — эта справка
Если честно, всё было в меру сложно. Конечно, чем больше папок и файлов, тем больше нужно помнить в голове и сложнее организовывать что-либо. Но всё же трудненько было сделать систему для обмена файлами, потому что пришлось параллельно думать об очереди сообщений, и в моменте я вообще ничё не понимал. Я ожидал, что придётся дебажить, но на удивление пришлось этим заниматься не очень-то и долго — всего день.
Хочу также затронуть некоторые технологии, которые я применял. Одна из них — хэширование (hashlib + secrets). Я применял его для регистрации и аутентификации пользователей, чтобы по сети не гуляли пароли. Однако всё равно можно перехватить запрос на авторизацию:
request = self.encode({
'type': 'auth',
'username': parts[0],
'hash': hash_b64
})
И по сути войти в чужой аккаунт, скопировав этот запрос и отправив на сервер от себя. Типа да, пароль никто не узнает, но хэш-то стырить можно. В общем, не всё идеально.
Ещё я использую потоки (threading) для параллельных задач. Например, приём и отправка запросов идут в разных потоках на клиенте. А на сервере вообще под каждого клиента свой поток запускается.
Также недавно узнал про классную штуку в Python — декораторы. Очень хорошо очищают код и местами упрощают логику. Ещё датаклассы — аналогично упрощают жизнь, особенно при перекрёстных передачах параметров в экземпляры классов, коих у меня немало.
Как уже говорил, буду делать GUI, ещё хочу уведомления о сообщениях, локальную историю переписок и шифрование. Шифрование буду делать симметричное — самый незапарный вариант, для чата с друзьями за глаза.
Кстати, я не просто так это всё делаю: хочу в будущем купить Raspberry Pi и поднять свой сервер для этого мессенджера. Ну и по мелочи: группы (может и не добавлю, так как на 10 человек незачем), мобильная версия, если прям будет желание, ну и оптимизация, безопасность и так далее.
Кто хочет посмотреть — велкам, можно даже пулл-реквесты делать)
И мой Telegram-канал, где рассказываю и про другие проекты:
Все вокруг хвалят Supabase за скорость. И да, я тоже повелся. Как бэкендера меня поначалу знатно корежило от того, что фронт ходит тупо прямиком в базу. Но ради быстрой доставки фичей я зажмурился.
Спойлер: пилится-то всё реально быстро. Только потом ты ловишь тихие баги, пропадающие логи и жесткий вендор-лок. Я собрал на Supabase уже несколько проектов и успел поседеть.
Короче, вот за что вы будете страдать на бесплатном тарифе (да и не только на нем).
Логи.Их просто нет
Точнее, они живут ровно 24 часа. Упало что-то в пятницу вечеро - в понедельник с утра ты дебажишь святым духом. Встроенный поиск это вообще кровь из глаз. Без какого-нибудь Datadog или Logflare там тупо не выжить.
Edge-функции и проклятые холодные старты
Это отдельный котел. Писать надо на Deno, так что половина привычных npm-пакетов идет лесом. Лимиты на вызовы жесткие, долгую таску не запустить. Но самое бесячее — холодные старты. Пока поднимется пул коннектов к базе, проходит до трех секунд. В моем сервисе post-cooler.ru edge-функция отдает HTML для линк-страничек. Я смотрю в метрики и плачу: кликов куча, а дожидаются загрузки единицы. Конверсия просто умирает на этапе бесконечного лоадера.
Палево с доменами в OAuth
Юзер логинится через Google, а в окне авторизации торчит <project-id>.supabase.co. Я когда делал photo math, целый час дебажил эту хрень. Думал, что сам где-то накосячил — на локалке-то всё выглядело нормально! Оказалось, не баг, а фича. Хочешь свой домен? Плати.
Хаос со схемами БД
Экспорт схем из дашборда выпилили еще в 2025 году. Сейчас помогаю проекту the-signal переехать на селф-хост. До этого код там писали vibe-кодеры, которые вообще не парились про миграции. Вытащить дамп схемы из облака было той еще болью. Без жесткой дисциплины база очень быстро превращается в неуправляемую помойку.
Тормоза локальной разработки
Я постоянно прыгаю между проектами. И каждый гребаный раз supabase start лезет тянуть свежие Docker-образы. Поднимает 10+ контейнеров, а ты сидишь и тупишь в терминал. Весь кайф от "быстрой" разработки улетучивается.
Тихие RLS-ошибкиRLS (Row Level Security) ошибается молча.
Накосячил в политиках? БД тебе не скажет. UPDATE просто вернет 0 affected rows, а SELECT подтянет половину данных.
Транзакции и боль SQL-функций
Через REST API нельзя сделать нормальную транзакцию на несколько таблиц. Нужно атомарно создать юзера, профиль и настройки? Обломись. У меня пока ничего не отвалилось, но я с ужасом жду, когда в базе начнут копиться "осиротевшие" записи.Чтобы это обойти, приходится писать логику на PL/pgSQL прямо в базе. Редактор там примитивный, автокомплита толком нет и дебажить то еще удовольствие.
Вендор-лок
Клиентский SDK намертво завязан на специфичный синтаксис PostgREST и их собственные токены. Если однажды решишь переехать на нормальный самописный бэк: придется рефакторить вообще весь клиентский код.
Короче. Для MVP или пет-проекта, чтобы просто проверить гипотезу на коленке - это топ. Да, часть этих костылей можно вылечить, если закинуть денег и перейти на платную версию. Но возникает резонный вопрос: за те же 25 баксов в месяц можно спокойно поднять Supabase на нормальной VPS-ке и вообще забыть про лимиты.
Кто еще сидит на Supabase или Firebase? С чем боретесь? И есть тут те, кто уже психанул и переехал на свой бэк?
Дебаж 🐞с ноги 🦶
В недавнем видосе я рассказывал, что сейчас читаю Талеба (в частности, его идеи вокруг "Антихрупкости"). И вот на днях на работе поймал идеальный личный пример одной из его любимых метафор Прокрустова ложа.
Суть там в чем: в мифе разбойник Прокруст укладывал гостей на свою железную кровать. Если человек был слишком длинным, то он отрубал ему ноги, если коротким - вытягивал суставы. Талеб переносит это на нашу жизнь: когда живая, сложная реальность не влезает в наши жесткие модели и системы, мы предпочитаем обкорнать реальность, лишь бы она поместилась.
А теперь к практике. Как говорят таксисты: блог и инди-хакинг - это для души, а вообще у меня и настоящая работа есть. Я бэкенд-лид в команде, которая пилит платформу для масс-найма (курьеры, сборщики).
Недавно обсуждали с ребятами, почему в какой-то момент автоматизация процессов начинает буксовать: фича обходится дорого, а позитивного эффекта от нее всё меньше. Оцифровать ведь можно только то, что уже жестко формализовано.
А дальше классика: 20% эйчаров закрывают 80% вакансий. И тут возникает моя самая наивная мысль: ну так давайте пилить фичи специально под этих топов!
Но тут кроется засада. Выясняется, что процессы самых эффективных ребят очень сложно загнать в рамки. У них свои паттерны, подходы, интуиция. И когда пытаемся натянуть на них стандартный флоу, мы строим для них то самое Прокрустово ложе. Пытаясь впихнуть нестандартного, сильного спеца в удобные для системы формочки, мы буквально "отрубаем ему ноги". Мы заставляем его работать "как положено", лишая тех самых фишек, которые и делали его звездой.
Получается забавный парадокс: классическая автоматизация мешает сильным, но отлично помогает "слабым". Среднего сотрудника надо меньше учить, он быстрее вкатывается. А если он уйдет, найти замену гораздо проще, а порог входа сильно снижается за счет жесткого и автоматизированного рабочего процесса.
Как наброс на будущее: возможно, дальше мы придем к персональной автоматизации. Когда не человек подстраивается под приложение, а интерфейсы собираются под конкретного спеца и его стиль работы. Грубо говоря: когда мы научимся с помощью ИИ на лету менять размер кровати, а не рубить людям ноги.
Начал играться локально с Ollama. Это, можно сказать, интерфейс для общения с нейронками.
При этом модели нейронок скачиваются и используются локально.
Модель codellama вполне удовлетворяет, но она понимает только английский. С которым уже проблемы у меня.
Искал другие доступные модели, которые умеют в русский язык. Например llama3. Но они такую чушь несут...
ChatGPT, конечно, и русский понимает, и ответы вполне приемлемые. Но он же там, в этих ваших интернетах. Хотелось бы получить интернетонезависимый способ с более-менее адекватными ответами с русского на русский.
Бюджет: 20ГБ видеопамяти.
2004 год. Тогда я был студентом. Юным и инициативным.
Задался вопросом: а какого хрена драйверы по большей части проприетарные? Можно же сделать их на основе нейросетей. Да, нейронки уже тогда существовали. Скормить тренировочные данные для текущей системы и норм. По типу как компилируются драйверы.
Но ни одна из ОС такого тогда не предоставляло. Вот и начал писать свою ОС. С нуля. Буквально.
Дошёл до
