☺️ СОКОТРИС: ЗАДАЧКА С ФЕСКОЙ ☺️ Что такое игра для разработчика? Это вдохновение! Это творчество! И если вы думаете, что сейчас будет циничное упоминание о необходимости игрой заработать денег — НЕТ! Я просто порой настолько погружаюсь в разработку, что ловлю ветер вдохновения и на всех парусах плыву по реке творчества 😎 Разработка игры вообще всегда становится задачкой со звёздочкой ⭐️ 🔘Как сделать интересно? 🔘Что добавить? 🔘Что убрать? 🔘Как подружить между собой механики и при этом придумать что-то, чего ещё не было? Именно такой задачкой стала наша с Женей попытка скрестить Сокобан и Тетрис ✨✨✨ Кто следит за чатом, тот помнит моё длиннющее описание механик. А теперь у нас есть первый прототип 🟢 Что тут происходит? Есть Соко — маленький робот-архивариус Вселенной, педантичный клерк в смешной красной феске. После катастрофы он восстанавливает повреждённые файлы миров 💊 Проблема в том, что сами миры «схлопнулись» из 3D в 2D. Поэтому Соко может двигаться только влево-вправо в текущей проекции. Поворачиваем ракурс — и бывшая глубина становится новой горизонталью 📊 Нужно, переключаясь между проекциями, дотолкать тетрис-фигуру до нужного места. Вроде Сокобан. Вроде Тетрис. Но в какой-то момент начинаешь думать уже не только «куда толкнуть?», а «с какой стороны на это вообще посмотреть?» И у нас получился первый прототип: 🖥 https://freeprogrammer.ru/games/socotris/ Чтобы было чуть понятнее: X — место, куда должна попасть фигура O — реальное положение героя S — его положение в текущей проекции F — рычаг, на котором можно повернуть фигуру Перемещаемся Соко влево-вправо в текущей проекции и пытаемся доставить фигуру куда нужно 🎁 Понятно, что сначала это выглядит как какая-то чёрная магия 👍 Но игра никуда не торопит. Можно покрутить ракурсы, потыкать, поломать голову — и, возможно, поймать тот самый момент, когда механика внезапно начинает складываться в голове ➕ И вот теперь мне очень интересно ваше мнение: В это можно играть? Понятно ли, что вообще нужно делать? Возникает ли желание разобраться? Дальше у нас два пути: 🔘Сделать более привычный Сокобан с тетрис-фигурами и препятствиями 🔘Оставить эту странную механику и развивать именно её, улучшая UI и подачу Я пока остановился на втором 🤩 Нишево? Да. Но, может быть, кому-то именно такого странного Сокобана и не хватало 🐢

Что делать, если все заинтересованные стороны по-своему правы Одна из сложных ситуаций в работе менеджера продуктов: когда в обсуждении вариантов решения каждый стейкхолдер приводит свои веские аргументы, конфликтующие друг с другом, — но нужно договориться. ➡️ Отдел продаж хочет добавить интеграцию с конкретной системой, потому что без нее крупный клиент не подпишет контракт. ➡️ Команда разработки говорит, что интеграция потребует серьезных изменений в архитектуре и создаст новую статью расходов на поддержку. ➡️ Менеджер продукта уже провел исследование среди действующих клиентов и считает, что ресурсы стоит вложить в другую проблему, которая касается большого сегмента пользователей. ➡️ CEO напоминает, что выход в сегмент, из которого пришел крупный заказчик, — одна из стратегических целей года. Решение предстоит принять, учитывая все аргументы, интересы и последствия. Что особенно важно при этом не упустить — рассмотрим ниже на примере. 1️⃣ Сначала разберитесь, что именно стоит за позицией участника Допустим, менеджер по продажам хочет закрыть сделку, чтобы выполнить KPI и закрыть свои личные финансовые нужды. В разработке треть команды уходит в отпуск, и ресурсов на быстрый запуск интеграции просто нет. Команда продукта уже прошла часть пути для повышения LTV действующих клиентов и не хочет бросать, пока есть возможность вовремя добавить востребованную функцию. А CEO делает на новый сегмент большую ставку из-за его платежеспособности — и надеется за счет этого вывести компанию на самоокупаемость, потому что привлекать инвестиции стало сложнее. 2️⃣ Сведите аргументы к общим критериям Когда каждая сторона защищает свою ценность, нужно привести аргументы к одному знаменателю — стоимости: 🔵 Каковы минимальные требования конкретного клиента и сколько ресурсов потребуется на разработку? 🔵 Какие технические последствия и статьи расходов создаст? 🔵 Какой коммерческий эффект ожидаем? 🔵 Можно ли использовать решение для других клиентов и какой объем рынка им можно охватить?  Тогда становится понятно, между какими величинами стоит выбор. 3️⃣ Проверьте цену отказа от каждого варианта Если не делаем интеграцию, то: 🟦 сохраняем архитектуру; 🟦 экономим ресурс и можем завершить разработку функции для действующих пользователей, от которой ожидаем прироста LTV на 2%; 🟦 рискуем потерять крупного клиента; 🟦 откладываем выход в новый сегмент на 3–4 месяца и теряем возможность получить критически важные Х миллионов, а это означает необходимость срочно искать инвесторов или сокращать издержки. Так становятся ясны возможные последствия не только активных действий, но и бездействия. 4️⃣ Распишите все возможные варианты и последствия Чтобы понять, какой вариант решения действительно будет оптимальным, полезно создать канву для дальнейшего обсуждения:  🔵 исходный контекст и данные; 🔵 варианты решения и их стоимость; 🔵 возможные последствия и риски по каждому варианту, в том числе в денежном выражении; 🔵 необходимые для проверки вопросы.  Это позволяет сделать логику выбора ясной для всех участников. 5️⃣ Найдите способ проверить самое дорогое неизвестное Недостаток каких данных может привести к самой дорогой ошибке в выборе решения? В нашем случае это может быть вопрос о клиенте: действительно ли для заключения сделки нужна полноценная интеграция или основную потребность можно закрыть минимальной версией или даже ручной обработкой данных?  Может быть вопрос о рынке: нужна ли интеграция с этим сервисом еще кому-то из стратегически важного сегмента?  Или технический вопрос: сколько реально будет стоить решение и можно ли сделать его проще и дешевле? На этом этапе важно понять, какой сценарий может сделать решение ошибочным, и найти самый дешевый способ это проверить. 6️⃣ Зафиксируйте, какой вариант выбрали и чем будете жертвовать, если компромисс невозможен Предположим, вы выбрали делать частичную интеграцию для одного клиента с ручными процессами на начальном этапе. Потому что стратегическая ценность клиента очевидна, но другим представителям целевого сегмента интеграция с конкретным сервисом может не понадобиться.  Если стоимость такой разработки все равно высока, нужно понять, с какой инициативы будет переброшен ресурс, который пойдет на интеграцию. А также зафиксировать, в каком случае возможен пересмотр решения. Проделав все шаги, вы получите не только матрицу оценки вариантов и рисков, но и план принятия решений для дальнейших инициатив. Если через месяц отдел продаж снова предложит сделать полноценную интеграцию, не придется заново все обсуждать: понятно, какое решение приняли, на каких основаниях и что должно измениться, чтобы его пересмотреть. @productsense

Кстати помните пост что Codex доводит задачу до конца даже если кончился лимит? Фичу убрали... 🥰 Из-за того что в твиттере одна девушка выложила харнесс чтобы абузить лимиты, превращая последний ответ в бесконечную сессию. Через такой механизм: 1/ Codex как обычно начинает выполнять задачу 2/ Получает инструмент wait_for_user_input 3/ Когда задача готова, не заканчивает вывод, а вызывает этот тул и ждет 4/ Юзер отправляет новое сообщение 5/ Codex ловит его как результат тула, не прерывая свою работу То есть, не смотря на лимит юзер кое как всё равно мог ставить новые задачи и получать ответы агента Я даже сам успел потестить, но выкладывать это не решился Забавно что после того как пост стрельнул, она удалила все твиты и свой репо, еще и написала:

надеюсь команда Codex сможет это проверить и забанить эти аккаунты, тогда мы все в безопасности 😔

Не кусай руку которая тебя кормит.. @tips_ai

Хакнула запись к врачу. В Португалии, как и во многих странах Европы, очень трудно попасть к врачу, особенно, узкопрофильному. На прошлой неделе мне понадобилось попасть на УЗИ. У меня платная страховка. Во всех крупнейших сетях частных клиник предложили запись на ноябрь- декабрь 😏 и то, сначала надо попасть к гинекологу и взять у него направление. И только потом ловить окошки на УЗИ. Меня, конечно, такой расклад не устроил. Ну как это - ждать УЗИ полгода? После безуспешных попыток назначить себе что-то через обзвон клиник, я вспомнила, что я, вообще-то, вайбкодер😎 И тем же вечером построила агента, который с моих аккаунтов автоматом ловил слоты в двух крупнейших сетях клиник к англоязычным врачам. Открытой записи к ним не было на полгода вперед, но если внезапно кто-то отменялся - мой агент тут как тут меня записывал. К трем врачам из недоступных записал прям на следующий день. Я даже повыбирала лучшего по отзывам. Правда эту систему я хакнула лишь на половину - запись на УЗИ все равно через регистратуру. Но с направлением от врача это уже попроще и побыстрее. Почему в Европе это ТАК сложно?? До меня не доходит. Спрос бешенный, страховка платная, клиники частные - и не попасть… А в качестве видео вам сегодня кусочек Голландии. Поля, каналы, птички, коровки и очень аккуратные домики. Любовь на удаленке | Оля Сохнева #ии_наудаленке

«Как я случайно записала сотни тысяч телефонных звонков на военные базы» Технология ENUM связывала телефонные номера с адресами в сети, но так и не взлетела и сегодня, по сути, мертва. Исследовательница безопасности сканировала эту заброшенную систему и наткнулась на три зоны телефонных кодов, делегированные на сервер имён, домен которого давно протух. Она купила его за 5€ и получила контроль над DNS телефонной инфраструктуры трёх британских территорий. Теоретически это открывало возможность вклиниваться в чужие звонки посредником. Трафика поначалу не было вовсе, так что домены она просто оставила себе для экспериментов. А через полгода заглянула в логи и обнаружила там сотни тысяч запросов. Почти все они вели на военные базы, а адреса источников были в основном американскими: https://u.habr.com/6LzUD

🧮 Какие доли остались у основателей Dwelly после раунда на $170 млн Британский стартап Dwelly, который делают Илья Дроздов, Дан Лифшиц и Дмитрий Хануков, в июле анонсировал раунд на $170 млн. И это был уже не первый раунд. Было интересно, какие же доли остались у основателей. Теперь появилась возможность это подсчитать. Dwelly занимается тем, что скупает британские агентства по аренде недвижимости, а затем оптимизирует их работу с помощью AI. В июле у них было 17 купленных агентств и 15 000 объектов под управлением. Суммарная выручка — $465 млн в год. В феврале этого года проект анонсировал раунд на £69 млн ($93 млн) — займ на £37 млн и £32 млн в капитал. Но, вероятно, этот раунд случился еще в 2025-м. А в конце июля был раунд на $170 млн — займ на $75 млн и $95 млн в виде инвестиций. Плюс были еще более ранние раунды. Буквально на днях Dwelly опубликовала в британском реестре свежий список акционеров. И теперь можно подсчитать, какие доли остались у основателей. 🌸 Кто сейчас крупнейший совладелец? Это фонд General Catalyst, который лидировал два последних раунд. Его доля — 28,4%. 🌸 Сколько осталось у основателей: Илья Дроздов — 14,7% Дан Лифшиц — 12,9% Дмитрий Хануков — 9,3% 🌸 Кто крупнейшие инвесторы: General Catalyst — 28,4% Odin Investments — 9,7% EQT Growth — 8,6% Роман Буздалин — 7% S16 Fund — 3,6% Begin Capital — 3,6% Это не все инвесторы, но у остальных доля меньше 1%. Среди них, например, фонд DVC Марины и Николая Давыдовых с 0,3%. Интересно, почему они не стали наращивать долю в последнем раунде? И еще момент — у Dwelly несколько классов акций. И голосующая доля может отличаться от доли в капитале. Проценты в посте подсчитаны по доле в капитале. Нормально осталось у основателей или маловато? 👍 — Нормально! 👎 — Маловато! @TheEdinorogBlog — тот самый канал про стартапы🦄

📌 Palomar - реестр проверенных LEAN-доказательств Последние месяцы доказательства, сгенерированные ИИ, посыпались валом как для новых результатов, так и для старых, причем часть из них формализована на Lean и проверить такой репозиторий непросто, особенно если ты не эксперт. Нужно убедиться: 🟠что заявленные формальные утверждения действительно имеют доказательства, проходящие проверку типов; 🟠что в доказательствах нет жульничества; 🟠что формальные утверждения по смыслу совпадают с тем, что описано словами. Под эту задачу и Теренс Тао запустил Palomar - реестр математики, верифицированной на Lean. Инициативу вырастили Lean FRO и ICARM. Прием заявок уже идет, чтобы в него попасть, в репозитории должно быть три вещи: 🟢challenge file с коротким и читаемым человеком описанием заявленных результатов на Lean; 🟢solution module с доказательством любой длины; 🟢файл formalization.yaml, где те же результаты изложены обычным языком и собраны метаданные и раскрытия. Снимок поданного репозитория проверяют двумя этапами. Сначала инструмент Comparator смотрит, что solution module типизируется и доказывает ровно то, что заявлено в challenge file. После этого языковая модель сверяет, похоже ли неформальное описание в на то, что заявлено формально. Прошел оба - попал в реестр. Принимают формализации и старых результатов, и новых. Кто автор доказательства - человек, ИИ или оба вместе - значения не имеет. @ai_machinelearning_big_data #news #ai #ml

IT-гадалка подъехала Короче, почитал одно исследование и узнал, что 74% стартапов, которые закрылись, погибли именно из-за преждевременного масштабирования

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

Разница в цифрах ебанутая Компании, которые масштабировались вовремя, росли в 20 раз быстрее тех, кто поторопился И ни одна преждевременно масштабировавшаяся компания в выборке не перешагнула отметку в 100 000 пользователей Ты мне скажешь: ну ок, да, круто, а как понять-то, что уже можно в масштаб? Найм оправдан, когда есть минимум 3 месяца предсказуемой выручки, которая уже покрывает текущие расходы плюс 1.3 стоимости нового сотрудника - сверху закладываются налоги и оформление Если этого запаса нет, то бюджет (или подушка) уходит почти мгновенно. А когда деньги закончатся и вопрос всё равно придётся решать, времени и денег на эксперименты останется меньше Ну и вопрос на обсуждение:

если бы ты сейчас делал (а может, уже делаешь) свой стартап - когда бы шел в найм команды?

источники: ➖ Startup Genome: 74% интернет-стартапов гибнут от преждевременного масштабирования ➖ Forbes: разбор исследования ➖ Правило 1.3x на первый найм в бутстрапе