Comments 42
Давно подобное напрашивалось. Автору респект!
Если честно, мне кажется не удобным подобный способ программирования, однако видео выглядит офигенно и я очень хочу увидеть код этого чуда.
Может его стоит делать не как полный стек для создания сайтов, а как фреймворк для создания таких компоновочных интерфейсов? Местами такие вещи очень нужны, но готовых решений мне не попадалось, а объём работы огромный и останавливает от создания подобных интерфейсов.
Может его стоит делать не как полный стек для создания сайтов, а как фреймворк для создания таких компоновочных интерфейсов? Местами такие вещи очень нужны, но готовых решений мне не попадалось, а объём работы огромный и останавливает от создания подобных интерфейсов.
Возможная проблема подобных решений, которые фактически являются генераторами кода, это версионный контроль, т.к. сгенерированный код может постоянно изменяться, сводя на нет попытки использования VCS. Какие файлы предполагается хранить под версионным контролем, а какие генерировать на их основе? Является ли ваше решение SaaS или же это библиотека\фреймворк?
Какие файлы предполагается хранить под версионным контролем, а какие генерировать на их основе?
помимо сгенерированного скрипта, у каждой сцены есть файл, который хранит структуру сцены. эти пары файлов и планируется использовать при работе с VCS.
Является ли ваше решение SaaS или же это библиотека\фреймворк?
скорее всего это будет open source решение. сейчас — это просто набор файлов, которые находятся в корневой директории проекта. никаких внешних подключений не требуется.
Имхо, замечательная идея и многообещающая реализация.
Визуализация логических зависимостей в коде — это очень интересно.
Но есть несколько вопросов.
1. Автор фактически предлагает свой шаблонизатор. Однако есть Smarty и Twig, причем и в готовых решениях используются они широко, и у разработчиков есть свои наработки на базе этих шаблонов. Возможно ли использование, например, Smarty в той иерархии, которая описывается?
2. Хочется узнать о реализации механизма работы с БД. PDO?
Визуализация логических зависимостей в коде — это очень интересно.
Но есть несколько вопросов.
1. Автор фактически предлагает свой шаблонизатор. Однако есть Smarty и Twig, причем и в готовых решениях используются они широко, и у разработчиков есть свои наработки на базе этих шаблонов. Возможно ли использование, например, Smarty в той иерархии, которая описывается?
2. Хочется узнать о реализации механизма работы с БД. PDO?
1. Автор фактически предлагает свой шаблонизатор. Однако есть Smarty и Twig, причем и в готовых решениях используются они широко, и у разработчиков есть свои наработки на базе этих шаблонов. Возможно ли использование, например, Smarty в той иерархии, которая описывается?
1. В системе есть возможность подключать другие готовые решения. Была идея встроить готовый фреймворк, например Kohana. На счет шаблонизаторов — не сложно будет создать адаптер для файлов, работающих в Smarty.
2. Хочется узнать о реализации механизма работы с БД. PDO?
2. Да, используется PDO
Для разработчиков навряд ли будет интересно, вам по моему лучше ориентироваться на школы и всякие кружки, обучающие курсы, где нужна наглядность.
Для быстрого проектирования приложения и создания рабочего прототипа, на мой взгляд очень даже крутой и полезный инструмент.
Сомневаюсь, что это позволит сделать что-то более менее серьёзное за вменяемое время. Наглядно — да, а вот быстро — вряд ли.
Не представляю серьёзного разработчика, который будет мышкой составлять sql-ки.
Не представляю серьёзного разработчика, который будет мышкой составлять sql-ки.
Да, на серьезное возможно нет, если например надо решить какую сложную задачу в рамках большой работы и ты «застрял», то такое наглядное программирование вполне может помочь — по крайней мере получить новые варианты и сочетания без переписывания и копипаста кучи кода. Жду выхода и планирую попробовать сию чудо штуку. Может быть как раз для таких как я — программирую не часто, но иногда приходится решать нетривиальные задачки и для этого лопатить интернет. А тут бах — соединил и готово, особенно что касается логических операций.
Наглядность тоже под большим вопросом. Хотел бы я посмотреть как будет выглядеть ya.ru в этих блоках, хотя бы без скриптов :)
Бывает такое что «заказчик» не может внятно объяснить что он от вас хочет, иногда потому, что он сам не до конца понял что ему нужно, мне почему-то кажется, что этот инструмент как раз будет выручать в таких случаях.
Сомневаюсь, чтобы «заказчик», не умея объяснить, смог бы сформулировать задачу в блоках.
Но может я что-то упускаю. Можете привести конкретный пример?
Но может я что-то упускаю. Можете привести конкретный пример?
я тут имел ввиду, что на основании полученных данных от заказчика, исполнитель делает «эскиз» с помощью этого инструмента и показывает заказчику.
Например, есть какая-то система, работая в этой системе, пользователи стали жаловаться на то, что нет определенного функционала. Стали поступать жалобы, предложения, пожелания. Проанализировав все входящие, менеджер проекта(или тот кто работает с клиентами) понял что этот функционал крайне необходим и принял решение, что нужно срочно добавить новый функционал. Он знает, что должно получиться на выходе и понял картину в целом, но есть некоторые участки, в которых менеджер проекта пока еще не разобрался.
В итоге Менеджер проекта(«заказчик») идет к программистам и ставит перед ними задачу, не скрывая что он не знает как лучше сделать вот это… это и это. Построив схему, будет проще понять друг-друга и придумать решение для тех участков функционала которые показались наиболее сложными в реализации.
Например, есть какая-то система, работая в этой системе, пользователи стали жаловаться на то, что нет определенного функционала. Стали поступать жалобы, предложения, пожелания. Проанализировав все входящие, менеджер проекта(или тот кто работает с клиентами) понял что этот функционал крайне необходим и принял решение, что нужно срочно добавить новый функционал. Он знает, что должно получиться на выходе и понял картину в целом, но есть некоторые участки, в которых менеджер проекта пока еще не разобрался.
В итоге Менеджер проекта(«заказчик») идет к программистам и ставит перед ними задачу, не скрывая что он не знает как лучше сделать вот это… это и это. Построив схему, будет проще понять друг-друга и придумать решение для тех участков функционала которые показались наиболее сложными в реализации.
То есть менеджер должен понимать блоки, которые по сути конструкции языка, следовательно и текст программы он понимает. Я правильно понял?
Он их может даже не видеть и не знать про них, он будет видеть результат который система сгенерит.
Если менеджер не увидит блоков, то какая от них польза и кому?
Если все создавать вручную — да. Но если отдельные типовые решения можно объединять в блоки и задействовать целиком — это может оказаться даже быстрее.
Такая мысль у меня проскочила, но по моему для какой-то обобщенной блок схемы тут слишком большая детализация, а более-менее серьезный прототип наоборот слишком сложным и большим для такого метода разработки окажется.
Спорить не буду, может у каких-то разработчиков встречаются задачи где-то посередине, где нужна высокая наглядность и подобная детализация, но лично я таких задач представить не могу.
Спорить не буду, может у каких-то разработчиков встречаются задачи где-то посередине, где нужна высокая наглядность и подобная детализация, но лично я таких задач представить не могу.
Yahoo Pipes здесь уже вспоминали?
Мне кажется, что лучше ориентироваться не на программистов, т.к. они и сами способны тоже самое написать в любимом редакторе. Поэтому я бы работу с хтмл(как минимум) перевел на человеческий язык: h1 -> заголовок, p -> абзац, img -> изображение и т.д.
Я давно мечтаю об инструменте, который позволил бы мне программировать с минимальным взаимодействием с клавиатурой. И даже не мышкой тыркать, а прямо пальцем по экрану водить и собирать программу как конструктор, время от времени вбивая названия переменных и всякие константы…
Мне кажется, вышеозначенный инструмент пока не достаточно удобен для таких вещей, но тема очень интересная.
Интересно, что этот нодовый интерфейс — это, фактически, отдельный язык программирования, который автоматически транслируется в несколько других. И, в общем-то, трансляция именно в PHP и MySQL вовсе не принципиальна — вполне можно и в другие языки. Полагаю, что больше всего для нодов подходят функциональные языки, потому что функциии самодостаточны, а значит перекрестных связей будет гораздо меньше, чем в императивных языках.
Основная проблема мне видится в том, что у подобного редактора будут те же болезни, что у любого ВИЗИВИГа, т.е. много мусора, неоптимальный код, трудность с наведением порядка при изменении структуры кода (например, надо закомментить часть функционала — как это будет отоборажаться).
И еще, от этого проекта было бы на порядок больше пользы, если бы он умел генерировать свою (адекватную!) карту на основе уже существующего кода, но это, конечно, намного больше работы требует для реализации.
Мне кажется, вышеозначенный инструмент пока не достаточно удобен для таких вещей, но тема очень интересная.
Интересно, что этот нодовый интерфейс — это, фактически, отдельный язык программирования, который автоматически транслируется в несколько других. И, в общем-то, трансляция именно в PHP и MySQL вовсе не принципиальна — вполне можно и в другие языки. Полагаю, что больше всего для нодов подходят функциональные языки, потому что функциии самодостаточны, а значит перекрестных связей будет гораздо меньше, чем в императивных языках.
Основная проблема мне видится в том, что у подобного редактора будут те же болезни, что у любого ВИЗИВИГа, т.е. много мусора, неоптимальный код, трудность с наведением порядка при изменении структуры кода (например, надо закомментить часть функционала — как это будет отоборажаться).
И еще, от этого проекта было бы на порядок больше пользы, если бы он умел генерировать свою (адекватную!) карту на основе уже существующего кода, но это, конечно, намного больше работы требует для реализации.
Я давно мечтаю об инструменте, который позволил бы мне программировать с минимальным взаимодействием с клавиатурой.
А, наверное вот это имели ввиду?)
ням
Как Scratch?
Accsess — воскрес!
Язык программирования Дракон. Язык ДРАКОН создан в ракетно-космической отрасли: ru.wikipedia.org/wiki/ДРАКОН
Как вариант сделать свое IDE для планшетов. На айпаде программить не удобно из-за отсутствия клавиатуры, тут эта проблема решена. Тач скрин для нод подходит идеально.
Очень интересно, выражаю уважение автору.
Вопрос у меня такой: я или пропустил во время чтения или не понял, но имеется ли возможность переворачивать ноды?
Например, для того, чтобы иерархия росла вниз, а не в сторону — субъективно мне, так удобнее рассматривать большие цепочки.
Вопрос у меня такой: я или пропустил во время чтения или не понял, но имеется ли возможность переворачивать ноды?
Например, для того, чтобы иерархия росла вниз, а не в сторону — субъективно мне, так удобнее рассматривать большие цепочки.
И ещё: где и как можно пощупать?
Пощупать пока негде. Я только готовлю к выходу бета-версию. Можно подписаться на новости на сайте проекта.
Спасибо! В большинстве случаев мы используем альбомную ориентацию монитора и движение слева направо изначально мне показалось логичным. Кроме того, в редакторе есть возможность прятать части цепочек в специальные ноды-группы, что дает возможность увеличить «глубину» схемы, при этом разгрузить ее визуально и упростить читаемость. Однако в процессе работы добавилось много вспомогательных панелей, которые съели пространство по краям рабочей области и я тоже задумался о вертикальном движении.
И, раз такой вопрос возник, теперь я буду думать над тем, чтобы добавить возможность менять направление )
И, раз такой вопрос возник, теперь я буду думать над тем, чтобы добавить возможность менять направление )
Вообще, очень похоже на архитектуру Dataflow. Единственный момент — при большом объеме кода ориентироваться будет, мне кажется, сложновато. Есть возможность объединить группу нод в одну, чтобы уменьшить размер и, соответственно, сложность? То есть, вместо плоской карты нод — иерархическая, с вложенными нодами.
О, не заметил ответ выше, вопрос снимается, будем ждать, чтобы пощупать ;)
О, не заметил ответ выше, вопрос снимается, будем ждать, чтобы пощупать ;)
Как дела с проектом?
Редко встречаются такие проекты, отходящие в сторону от «накатанных дорожек»… Очень очень хочется попробовать,
Есть смысл ждать или уже нет?..
Редко встречаются такие проекты, отходящие в сторону от «накатанных дорожек»… Очень очень хочется попробовать,
Есть смысл ждать или уже нет?..
Sign up to leave a comment.
Mooha — нодовый интерфейс для PHP