Разработка on kenji.blog

История создания LogicPad

Wed, 30 Jul 2025 23:51:35 +0900

Инструмент для тех, кто «не умеет писать код, но обладает логикой». Почему я создал LogicPad

Здравствуйте, я kenji. Я создатель low-code инструмента «LogicPad». В этот раз, вместо того чтобы представлять продукт, я хотел бы немного с личной точки зрения написать об истории его создания: «почему я решил это сделать?» и о своих собственных чувствах.

Честно говоря, это была не просто разработка инструмента. Мое прошлое, разочарования на работе, мои навыки и тлеющее желание «однажды я хочу создать свой собственный продукт» ―― Результатом пересечения всего этого и стало рождение LogicPad.

Другими словами, это также «главный проект всей моей жизни» для меня. Я напишу об этой предыстории настолько честно и страстно, насколько смогу.

Честно говоря, я хотел продукт, о котором мог бы с гордостью сказать: «Я сделал это»

Если честно, это был самый первый мотив.

С давних пор я любил писать код, как на работе, так и в качестве хобби. Я участвовал в различных разработках. Но однажды я вдруг понял. «У меня нет продукта, который я бы выпустил в мир под своим именем и под свою ответственность».

Конечно, вещи, которые мы делаем в команде, имеют ценность, и было много работы, которой я гордился. Но где-то было и чувство пустоты: «Неужели я так и закончу свою карьеру под чьим-то чужим именем?»

Хотя бы раз. Я хочу оставить что-то, о чем я смогу с гордостью сказать: «Я создал это». С этой мыслью я начал продумывать концепцию LogicPad. Это было около 6 лет назад (примерно в 2019 году). (Сама первоначальная идея появилась около 2015 года, когда я узнал о Blueprints, языке визуального программирования в Unreal Engine.)

Вы не можете участвовать, потому что не умеете писать код. Разве это не потеря?

На моей работе было много талантливых людей.

Они могут выстраивать логику. Они свободно используют функции Excel и могут видеть суть проблемы. Но ―― их руки останавливаются на этапе «написания кода».

«Я выполняю эту работу, каждый раз глядя в руководство, разве мы не можем это автоматизировать?» «Да, можем. Но… для этого нужно написать код…»

Такие разговоры происходили много раз.

Каждый раз я думал. «Хотя они понимают логику, это действительно потеря, что они останавливаются перед стеной кода».

Выбор low-code редактора

На самом деле, на моей предыдущей работе я разрабатывал 2D CAD программу, которая работала через графический интерфейс (GUI). В CAD вы собираете фигуры с помощью мыши, не так ли? Другими словами, это мир «построения логики через операции» .

Я подумал: «Это очень хорошо сочетается с low-code».

Если заглянуть еще дальше в прошлое, со студенческих времен я всегда занимался обработкой изображений, числовой обработкой, инструментами Windows, инструментами автопостинга в SNS и т. д. Всякий раз, когда у меня появлялась идея, я сразу же писал код и массово создавал небольшие программы. Я думаю, их более 600. Они до сих пор хранятся на GitHub.

В то время я не задумывался о смысле. Это было просто «я делаю это, потому что хочу». Вот и все.

Но теперь, создавая LogicPad…

Я действительно почувствовал, что точки соединились в линию.

Простой в использовании, но мощный. Сложность баланса

Продвигаясь в разработке, я всегда думал о том, «как сделать его интуитивно понятным, но в то же время по-настоящему мощным инструментом» .

Если вы добавите функции, то увеличите то, что можно сделать. Но он станет сложным в использовании. Если сделать его простым, то любой сможет им пользоваться. Но тогда найдутся люди, которым этого будет недостаточно.

Чтобы люди не говорили: «Low-code инструменты — это просто игрушки, верно?» Но и чтобы не говорили: «В конце концов, все равно нужно писать код, так?»

Я постоянно боролся на этой тонкой грани между интуитивностью и выразительностью.

Я много раз переделывал пользовательский интерфейс, много раз отказывался от него, и когда я наконец приблизился к форме, которая заставила меня подумать: «Это сработает», я был по-настоящему счастлив.

Меня спасло первое слово «пользователя»

Первым человеком, которому я дал LogicPad, была моя бывшая коллега. Она не сильна в IT и боится кода. Но она хороша в логике.

Я немного объяснил и дал ей попробовать… Слова, которые она сказала через несколько минут, я не могу забыть до сих пор.

«Если это так, я думаю, что тоже смогу это сделать!»

Я чуть не расплакался. Это было то, что я хотел ей дать.

Не просто работающий инструмент, а чувство «я смогла создать это сама!» . Я убедился, что в этом и заключается истинная ценность LogicPad.

Если больше людей смогут создавать, общество станет намного интереснее

Я действительно считаю, что «демократизация технологий» очень важна.

Технологии способны изменить мир. Но круг людей, которые могут с ними обращаться, ограничен.

Что если бы вы могли создать приложение, просто «понимая логику»?

Больше людей смогут перейти на сторону «создателей». И я верю, что то, что родится оттуда, превзойдет наше нынешнее воображение.

Если бы LogicPad мог стать этим входом. Я хочу, чтобы это был инструмент, который превращает «я хочу создать» в «я могу создать».

Это мое желание.

В заключение

LogicPad все еще находится в бета-версии и не завершен. Есть еще горы того, что нужно улучшить, и того, что я хочу сделать.

Но я вложил все «точки» моей жизни в этот инструмент . Теперь я могу сказать это с гордостью.

«Это продукт, который я создал» .

👇 Бонус: что вы можете делать с LogicPad

Построение процессов с помощью перетаскивания (Drag & Drop)
Управление условными ветвлениями и переменными через GUI
Подготовлены различные узлы для интеграции с ИИ
Возможность расширения для опытных пользователей путем вставки скриптов
Высокоточные математические функции и обработка данных (например, вычисления с бесконечной точностью)
Обширные сочетания клавиш для опытных пользователей
Поддержка более 90 языков

Что я хочу сделать в будущем

Интеграция с ИИ для генерации логики из естественного языка
Механизм, позволяющий пользователям создавать собственные узлы
Создание платформы, где можно будет делиться созданными узлами и логикой

✍️ Послесловие

Большое спасибо, что дочитали до этого момента. Это была не просто разработка инструмента, а вызов, в который я вложил свой собственный опыт, страсть и частички своей жизни.

«Не умею писать код, но обладаю логикой». Будущее, в котором такие люди смогут «создавать» своими силами. Я хочу продолжать стремиться к этому с помощью LogicPad.

Если это заставило вас хотя бы немного подумать: «Я хочу это использовать», я буду очень рад. Если вам интересно, пожалуйста, попробуйте LogicPad.

И если у вас есть какие-либо мысли или вы что-то заметили после его использования, неважно насколько это незначительно. Ваш голос станет огромной движущей силой для следующего шага этого продукта.

Спасибо за вашу постоянную поддержку.

Стена разработки ИИ

Sun, 20 Jul 2025 21:52:42 +0900

Стена разработки ИИ

〜 Мы добрались до 8-й станции, но потом начался ад 〜

Всем привет, это kenji.

В последнее время я очень часто слышу: “Я попросил ИИ, и он сделал мне приложение!” Мы прошли эпоху no-code и low-code и вступили в фазу “vibe-coding” (написание кода по атмосфере).

Например, если вы скажете: “Создай приложение, которое может редактировать изображения и публиковать их в соцсетях”, ИИ выдаст код и даже пользовательский интерфейс. Вы подумаете: “Ух ты, нам больше не нужны люди, да?”

Но знаете, это как спуститься на 8-ю станцию горы Фудзи в сандалиях.

До 8-й станции кажется, что это “проще простого”

Разработка с помощью ИИ поначалу действительно кажется легкой. Файловый ввод-вывод? Пока что работает. Сеть? Ну, подключается. База данных? JSON сойдет. UI? ChatGPT выдал код на React. Оплата? API Stripe можно просто скопировать и вставить.

На этом этапе у вас возникает иллюзия: “А не инженер ли я уже?” Но настоящий ад начинается именно здесь.

Почему мы застреваем?

Причина проста: “ИИ делает что-то похожее на правду, но финальная доработка полностью ложится на плечи человека”.

Данные теряются при файловом вводе-выводе
Нормализация БД слабая, поэтому поиск работает медленно
UI не интуитивно понятен
Нагрузочное тестирование не проводилось, поэтому при наплыве посетителей все падает
Отказ при проверке Apple/Google
Нарушение юридических требований и (почти) скандал

Иными словами, ИИ хорош в создании прототипов, которые выглядят как готовые, но доведение их до состояния “продукта, который можно выпустить в мир”, до сих пор остается работой человека.

Но есть парадокс

Здесь мы замечаем один парадокс.

Что, если в будущем ИИ действительно сможет делать всё? То есть, что, если “безопасность, биллинг и проектирование — всё это будет идеально обрабатываться ИИ”?

В этот момент необходимость в том, чтобы человечество создавало приложения, может отпасть сама собой.

Потому что, если пользователь напрямую скажет ИИ: “Я хочу сделать то-то”, задача будет выполнена мгновенно без какого-либо приложения.

🌀 Например

Раньше мы “запускали приложение калькулятора, чтобы посчитать”, а теперь достаточно сказать: “Привет, Siri, сколько будет 12×32?”, и всё готово.

Точно так же, если вы скажете: “ИИ, отредактируй фотографию и поделись ею”, процесс может быть завершен без использования UI или API приложения.

Иными словами, когда цель “создать приложение с помощью ИИ” будет достигнута, может наступить мир, в котором сами приложения станут не нужны.

В итоге, что мы можем сделать сейчас

Итак, что же нам делать?

Пока что “всё, что выше 8-й станции” — это территория человека, поэтому давайте оттачивать эти навыки.
Сосредоточиться на фундаментальном понимании пользователей и проектировании сервисов.
Думать о том, что “имеет ценность”, а не о том, что “можно сделать”.
Искать способы предоставления ценности, которые “не ограничены форматом приложения”.

ИИ — это инструмент, лифт, а иногда и конкурент. Но вопросы “что создавать” и “зачем это создавать” по-прежнему остаются вопросами для нас, людей.

Заключение:

Стена разработки ИИ — это не технологии, а структурный парадокс.

Мы живем в эпоху, когда каждый может добраться до 8-й станции горы Фудзи. Но именно после этого начинается самое интересное.

И, возможно, когда мы достигнем вершины, нас будет ждать будущее, в котором мы спросим себя: “А нужно ли вообще было лезть на эту гору?”

Market-in и Product-out

Tue, 15 Jul 2025 20:18:22 +0900

Market-in и Product-out

Привет, это Кенджи.

Иногда в бизнес-книгах или проектных предложениях я вижу что-то вроде:

“У нас стратегия market-in.” “Это модель product-out.”

Такие вещи говорят, но…

Нет, market-in? Product-out? Что круче???

Разве не так?

Так что на этот раз я постараюсь разобрать эти “market-in” и “product-out” как можно проще и посмотреть на них немного критически.

Короче говоря…

Market-in : Прислушиваться к голосу рынка (market) и создавать продукты в соответствии с ним.
Product-out : Создавать то, что мы (product) считаем хорошим, и выпускать это в мир.

Вот и все. Просто.

Например, в раменной…

Раменная в стиле market-in: “В последнее время популярен иэкей рамен. Отлично, добавим побольше жира и чеснока!” — вот так.

Раменная в стиле product-out: “Этот соево-базиликовый соленый рамен, который я приготовил, просто великолепен, так что ешьте” — вот так.

Что правильнее… Оба варианта правильные

Market-in ориентирован на потребности клиентов, поэтому “вероятность продаж высока”, но прорывные идеи или инновации рождаются редко.

Product-out — это “воплощение справедливости, в которую мы верим”, поэтому он острый и привлекательный, но если промахнуться, это никого не зацепит.

iPhone похож на product-out

В эпоху, когда говорили “смартфоны не нужны”, Apple выпустила iPhone.

Это уже абсолютно успешный пример product-out .

Если бы они слушали пользователей, им бы сказали “Телефон без клавиатуры? Ни за что”, и на этом бы все закончилось.

Но product-out легко может стать “самодовольством”

Иногда есть компании или люди, которые говорят: “Мы типа product-out”, но

Нет, разве это не просто игнорирование пользователей?

Иногда я так думаю.

“Сделал, потому что хотел. Но не продалось” — это не product-out, а “эгоистичный out”, не так ли?

У market-in тоже есть ловушки

С другой стороны, market-in тоже не идеален.

Если говорить: “Мы сделаем все, что просят пользователи!”, суть продукта размоется, и в итоге он никого не зацепит.

Вы добавляете всё новые функции, и вдруг понимаете, что это какой-то хаотичный инструмент.

По-настоящему удивительны те, кто “делает и то, и другое”

Удивительные продукты — это те, которые четко показывают: “то, что пользователи действительно хотели, но не могли выразить словами”.

Другими словами, “получить сочувствие в стиле market-in, используя идею product-out”.

Сказать это легко, но сделать невероятно сложно. Но если вы сможете это сделать, он мгновенно станет “божественным продуктом”.

Вывод: реакция пользователей решает всё, а не слова

Market-in или product-out. Вопрос о том, что правильнее, не имеет особого смысла.

“Достигло ли это сердца пользователя?” — вот и всё , я думаю.

“У нас стратегия похожа на это” — я считаю, что достаточно, если мы сможем написать это позже в маркетинговых материалах.

Вот и вся история про market-in и product-out!

Не поддаваясь влиянию странных иностранных слов, думать “в конце концов, как я могу сделать людей счастливыми?” — это самое здравое, как мне кажется.

Пока-пока~.

Преимущества и недостатки создания программ с использованием Win32API + C++

Sat, 12 Jul 2025 12:30:35 +0900

Привлекательность и проблемы разработки с Win32API + C++

Для тех, кто хочет освоить разработку приложений под Windows, Win32API + C++ по-прежнему остается мощным выбором. Эта комбинация, позволяющая взаимодействовать с ОС на минимальном расстоянии, сочетает в себе высокую скорость и гибкость.

С другой стороны, поскольку она сильно отличается от современных стилей разработки, для ее освоения потребуется решимость.

На этой странице, с точки зрения действующего разработчика приложений под Windows , мы наглядно объясним ее преимущества и недостатки.

Преимущества

Сверхбыстрое нативное выполнение

Поскольку C++ и Win32API работают на уровне, наиболее близком к ОС, лишних накладных расходов практически нет. Эффективность использования процессора и памяти чрезвычайно высока, и она может похвастаться подавляющей скоростью выполнения .

Высокая гибкость и свобода

Вы можете самостоятельно и детально контролировать любое поведение приложения, такое как управление окнами, асинхронная обработка, интеграция COM и управление процессами. Также возможно создание специализированных инструментов и собственных фреймворков.

Легкость распространения без среды выполнения

Поскольку не требуются внешние среды выполнения, такие как .NET или Java, приложение можно распространять в виде одного исполняемого файла . Проблемы при распространении возникают редко, и привлекает то, что его легко запустить даже без установщика.

Возможность создания легковесных приложений

Поскольку требуется лишь минимальная конфигурация, характерной чертой является то, что объем используемой памяти очень мал . Приложение будет комфортно работать даже на ПК с низкими характеристиками и в средах виртуальных машин.

Возможен расширенный контроль на уровне ОС

Также можно реализовать управление, которое сложно выполнить с помощью обычных языков и библиотек , такое как глобальные хуки мыши и клавиатуры, тонкая настройка стилей окон и операции с системным меню.

Недостатки

Низкая эффективность разработки

Создание графического интерфейса пользователя (GUI) также должно выполняться полностью с помощью кода, и для создания одной кнопки могут потребоваться десятки строк кода . Внесение изменений при перепроектировании также затруднено, а производительность ниже по сравнению с разработкой с использованием фреймворков UI.

Склонность к снижению ремонтопригодности

Содержит много кода со специальной структурой , такого как циклы сообщений и оконные процедуры, что затрудняет его чтение и повторное использование. Есть также аспекты, которые делают его непригодным для командной разработки или долгосрочной поддержки.

Адаптация к современному UI хлопотна

Сложно адаптироваться к UX, востребованному в последние годы , такому как поддержка высокого DPI, сенсорных интерфейсов, специальных возможностей и темного режима. Каждый из них нужно обрабатывать вручную, что требует больших усилий.

Не поддерживает кроссплатформенность

Поскольку это API исключительно для Windows, его невозможно перенести на macOS или Linux . Если предполагается развертывание на нескольких платформах, потребуется выбрать другую технологию.

Очень высокая стоимость обучения

Вы должны понимать концепции и механизмы, которые редко используются сегодня , такие как дескрипторы (handles), GDI, COM и OLE. Многие документы также устарели, а обучение требует времени и терпения.

Подходящие применения

Легковесные инструменты , такие как средства запуска файлов и помощники по горячим клавишам
Системные утилиты , такие как управление буфером обмена и управление IME
Приложения для нативного контроля , такие как глобальные хуки и захват окон
Вспомогательные инструменты для драйверов , тесно связанные с аппаратным обеспечением

Неподходящие применения

Приложения для обычных потребителей , где важен современный UI / UX
Создание прототипов и разработка MVP , где приоритетом является скорость
Крупномасштабные проекты , предполагающие долгосрочную эксплуатацию и командную разработку
Кроссплатформенные продукты , которые должны поддерживать несколько ОС

Итоговая оценка

Критерий	Оценка
Скорость выполнения	◎ Очень быстро
Эффективность памяти	◎ Отлично
Скорость разработки	× Медленно
Ремонтопригодность	× Низкая
Кроссплатформенность	× Не поддерживается
Поддержка современного UI	× Слабая
Свобода контроля ОС	◎ Подавляюще высокая

Заключение

Win32API + C++ — это инструмент, подходящий для разработчиков, которые «хотят обрабатывать все в ОС самостоятельно». Хотя его мощь огромна, обучение и использование требуют соответствующей решимости.

Стоит ли делать такой «осознанный выбор», зависит от характера приложения, которое вы стремитесь создать.

Погрузиться в мир #include <windows.h> , не полагаясь на фреймворки GUI или современные языки — этот выбор по-прежнему имеет смысл.