Pull to refresh

Comments 31

У вас много конкурентов: FoxPro, Access, Oracle Forms…
Для всех этих систем требуется знания из области программирования. Т.е. проекты в них строятся от деталей к общему. В моем случае человеку не требуется абсолютно таких знаний. Как может служить для автолюбителя конкурентом самолет? (На данном этапе автомобилем выступает моя система, а самолетами — вышеперечисленные. Но могу сказать, что самолет совершенно не требуется, если преодолеть расстояние в 100 км.)
Не вижу, чем ваша система проще access'a? Необученный человек все равно не разберется.
В жизни ничего нельзя сделать, не получив минимальных знаний. Конечно, необученный человек не сможет ничего сделать в этой системе. И я не предлагаю таким людям разбираться в ней. Вопрос в том, насколько быстро можно решить поставленную задачу, имея такой инструмент в своем арсенале.
Клеви :) Чем-то походит на 1С.
Сами делаем сейчас похожее решение под кастомный MDM (master data management) для электронных архивов.

Скажите, а как вы решали вопрос миграции данных? Может ли быть так, что после конструирования новой версии существующие данные будут препятствовать обновлению БД — скажем, мешают ключи или констрейнты?
С 1С мне лично работать не доводилось, хотя как мне недавно сообщили, в 8-ой версии у них появилось нечто похожее. Сам не проверял, но думаю это неплохо, что в воздухе витают схожие идеи.
Вопроса с миграцией в чистом виде не решали — задача хоть и создавалась полгода, но на это времени пока не хватило. На данный момент возможен импорт/экспорт всех объектов через Excel — тут изменение структуры никак не помешает.
Нет, индустрия давно уже ушла от кустарных самоделок. Я молчу про сайты, где царят CMS. SAP или OS можно соорудить в очередном конфигураторе. Проблема в том что умножая возможности системы усложняется конфигуратор и в конце концов ничем не отличается от программирования его на ЯП, кроме проприетарности необходимых знаний для этого.
Любая идея всегда начинается как кустарная самоделка.
Кстати наш проект можно рассматривать как CMS для систем учета. Пускай CMS-ки не пользуются уважением, зато они пользуются спросом! )
И в результате вы получите очередной access-опед. ;)
На жизнь не стоит смотреть, как на сплошную полосу неудач и разочарований.
Любая идея будет настолько жизнеспособна, насколько вы вложите в нее свою душу и энергию.
В моем случае идея развивалась много лет, было несколько попыток создать что-то особенное, и лишь когда я понял, что ничего подобного создать нельзя — все получилось. )
Посмотрите, может вам понравится. ;)
Ага, развивалась много лет. Со времён выхода 1С 7.7 как минимум ;)
В целом, статья заставляет вспомнить сладкие наивные времена первого курса, да.
— добавление любого количества рисунков каждой записи объекта;
— работа в сети;


Основные принципы построения программы:
это вообще шедевр абстрактной живописи…

Преимущества такого «программирования» очевидны: не требуется постановка задачи
… шёл четвёртый год внедрения, подрастали первенцы у ПМа и ведущего разработчика…

На основе данного конструктора на данный момент сделано около двух десятков проектов.
Единственное что заставляет присмотреться к статье. Хотя деталей можно и побольше.
1С живет и процветает, а программисты каждый день изобретают свои «новенькие» велосипеды. А ведь даже 1С не удалось завоевать рынок разработки бизнес-ПО.

Что касается данного «конструктора», то как только появится чуть более серьезный проект — данное ПО придет в негодность и не сможет обеспечить выполнение реальных бизнес-требований заказчика. Максимум, что от него в данный момент можно добиться — использование в низкобюджетных проектах за $50 для «знакомого из соседнего киоска».
Степень «серьезности» конструктора скрыта в его реализации. Это и отличает действительно «легкие» продукты — кажущаяся видимость простоты.
1. аналогия с конвейерами в начале статьи интересная, но ведь кто-то должен и сами конвейеры собирать. если продолжить аналогию, Вашу систему, вероятно, можно рассматривать как конвейер, но только для производства одного типа автомобилей, для решения широкого спектра задач (которые могут быть решены традиционными ЯП) она не предназначена.
2. как правильно заметил Wott, при расширении функционала система будет все больше и больше усложняться, и в результате все более станет напоминать традиционную систему программирования.
3. если вернуться опять к утверждениям Брукса, то то, что он называл «существенной» сложностью программирования, т.е. определение абстракций, установление отношений между сущностями и т.п., Ваша система не преодолевает (но Вы вроде бы на это и не претендовали), хотя и, похоже, существенно облегчает жизнь программисту в данной проблемной области (я автоматизацией управленческого учета никогда не занимался, поэтому судить могу лишь приблизительно)

в целом, как попытка создать более простую систему программирования, идея внимания заслуживает, но, боюсь, подобного рода системы всегда будут иметь очень узкую специализацию. о конкурентах рассуждать не берусь, т.к. сам с ними по роду деятельности не сталкивался
1. абсолютно верно – данный проект не претендует на универсальность. На данном этапе реализации его предназначение – предельно быстро (!) создать программу, которая реализует требуемый объем функционала в узкоспециализированной области. И в принципе я не вижу отрицательных моментов в данной работе – ведь производители, к примеру, автомобилей не стремятся создать универсальную технику для снегоуборочных работ и гонок формулы 1. Замечания в мой адрес, что я создаю новый велосипед, имеют место быть, если рассматривать идею с такой же позиции.
2. жизнь покажет – насколько потребуется расширение функционала в конкретной области. Она, конечно, потребуется, но возможно качество его расширения будет значительно выше, чем функционал, предназначенный для общего программирования (тут мне сложно объяснить – лучше продемонстрировать на реальном примере).
3. еще раз повторюсь – данный проект не предназначен для программиста, хотя и может быть им успешно использован. Да – самая большая сложность в моей идее после упрощения построения структуры данных было именно установление отношений между сущностями (в моем случае – это объекты и операции). Их явной настройки (в привычном понимании программиста) в проекте нет вообще. :)
если не программиста, то кого Вы видите в роли пользователя Вашей системы? хотя это и не обязательно будет показателем, но кто создавал упомянутые Вами проекты с помощью этого «конструктора»?
Все проекты, выложенные на нашем сайте, мы создавали сами.
Проекты, которые создавали наши клиенты, требовать от них не стали — кто-то принципиально не хотел, чтобы они были выложены для общего пользования.
Среди клиентов есть как программисты и системные администраторы, так и люди далекие от сферы IT.
так кто все-таки создает проекты (кроме программистов)?
В большей степени — пока только я. Работаю с заказчиками у них в офисе и создаю задачи по их требованиям. Еще мне помогают пару человек, но как создатель, я быстрее нахожу возможности решения требований клиента. В одной компании автоматизацию делает финансовый директор, но в большей степени этим занимаются непосредственно руководители своих маленьких предприятий. Есть еще пару человек, просто юзеры.
кстати, раз пользователями являются не программисты, Вы не думали о создании варианта системы специально для программистов? описанная Вами концепция «объектов и операций» очень хорошо соотносится с парадигмой ООП, и можно было бы в качестве выхода системы («проекта») создавать не исполняемый модуль, а генерировать код на каком-нибудь языке программирования, поддерживающем эту парадигму. соответственно, такой код можно потом неограниченно «допиливать» под более сложные требования заказчика
Все верно! Это есть в идеях. Более того — текущая версия останется в таком виде, какой есть сейчас, а следующая будет превосходить по возможностям и внутренней структуре. Там то мы и планируем создать механизмы для программистов, которые на базе ядра смогут делать все что угодно. И даже концепция изменится… :)
Принципиально неверное понимание сути конвейера и программирования: конвейерное производство позволило создавать много ОДИНАКОВЫХ машин по ГОТОВОМУ проекту. Как все знают, проблем с тиражированием готовых продуктов в ИТ нет и не предвидится, проблема именно в создании проектов — и она не решается тривиально.

В целом, придумал помесь адынэса с SAP'ом. Нежизнеспособно.
Не могу согласиться с утверждением «проблем с тиражированием готовых продуктов в ИТ нет и не предвидится».
а это смотря как глядеть.
Если говорить именно про тиражирование — то клонирование является одной из самых простых операций. Если же говорить про интеграцию — так это и не тиражирование вовсе. Это часть процесса разработки, проводимая на стороне клиента и при его участии. Что поделать, ERP-like системами сложно управлять тремя педалями и рулем.
Принципиально неверное понимание сути конвейера и программирования: конвейерное производство позволило создавать много ОДИНАКОВЫХ машин по ГОТОВОМУ проекту.


аналогия с конвейером была приведена автором, чтобы показать, как я понял, что создание проекта представляет собой сборку из готовых «типовых» блоков. в таком контексте она вполне уместна, но не стоит углубляться и понимать ее более буквально
Это отличное решение по соотношению цена/качество для мелкой конторки, у которой 10-15 человек штата и лишние 50 баксов.
Люди IT – это специалисты очень высокого уровня, и им привычно решать серьезные задачи. Да, этот проект в первую очередь направлен на удовлетворение спроса небольших организаций. И делаю я это качественно и быстро. Любая работа, пусть даже маленькая – должна приносить удовлетворение. :)
Добавлю, что можно условно провести параллель с инди-играми: внешне простая, но качественно сделанная программа, расчитанная на определенный круг людей.
Вы про TIBCO ещё не слышали, вот где «конструктор».
Жаль, что ваш конструктор может создавать только подобные базам данных программы, если бы туда можно было добавить что-то еще, было бы намного круче.

Например, чтобы любой мог состряпать себе плеер или прожигалку дисков — это вряд ли будет востребовано, а вот определенная работа с текстом и другими форматами была бы кстати, можно что-то типа Automator на MacOS сделать, только не в плане написания скриптов для дальнейшего запуска из этой программы, а самостоятельных приложений с четкой грамотно построенной структурой и нормальным внешним видом. Начать подобное нужно с решения ряда однотипных задач, в которых что-то будет отличаться.

PS: Конструктор понравился.
Ваша идея интересная. Мне просто больше приходилось работать с базами данных — поэтому данную тему и развивал. По поводу четкой структуры я хочу сейчас написать третью статью, в которой опишу, собственно почему родилась такая идея. Спасибо.
Sign up to leave a comment.

Articles