Так она и базируется, только бухгалтерские жрецы, придумавшие балансовую модель БУ, нам про это забыли рассказать. Мол, не нужна простым бухгалтерам (и даже не очень простым, вроде главных бухгалтеров) сложная (на уровне школьной геометрии / стереометрии / тригонометрии и алгебры) математика. Те иногда даже с корнем квадратным не дружат, а мы им про математические аксиомы их «науки» говорим…
«Моделирование бизнеса» это круто, но как бы реально смоделировать чего-нибудь попроще? Например, сформулировать математические аксиомы балансовой модели бухгалтерского учета (БУ). На уровне модели Лука Пачоли, которой уже более 500 лет. Интересно, БУ есть, а матмодели его нет. Это могут быть не более десятка аксиом, как в геометрии Евклида (пять аксиом) или в аксиоматике натуральных чисел Пеано (девять аксиом) и т.п. Из этих аксиом можно было бы вывести балансовое уравнение и другие известные свойства БУ. Но похоже бухгалтера с математиками не дружат, хоть бери сам сочиняй эти аксиомы :).
Крис Касперски – яркий пример одержимости. Настолько, что появился повод сказать: «Одержимость важнее образования!». Он был, безусловно, яркой личностью, жаль только, что обычно, кто сильно горит, тот быстро сгорает.
Наверное, он опубликовал не все, что мог, однако забудут его нескоро,
Новая «вечная тема» для современных реалий. Можно спорить долго, но главная проблема – личная. Но даже с собственной психологией не будет конфликта, если у человека достаточно высокий уровень адекватности. Ибо все наши беды от недостатка адекватности.
Чтобы быть успешным, нужно не столько образование и опыт, сколько энергия. В таких случаях я всегда говорю: «Одержимость важнее образования!». Это в плане достижения материальных благ и широкой известности. Пример, Крис Касперски (который недавно вроде как случайно(?) погиб) Но если целью является серьезный результат, то только тогда на первом месте будет качественное образование и только на втором одержимость. Однако в любом случае без одержимости делов не будет. Даёшь адекватную одержимость – вот главный лозунг.
Тем, у кого мало собственной энергии, можно дать совет. Энергию порождает Намерение и Воля. Ни то, ни другое энергии не требуют. Однако выбирать нужно ту деятельность, уже сам процесс от которой вызывает удовлетворение. Тогда можно рассчитывать на Результат.
Попутно замечу, что Желание Энергию не порождает, но Желание может служить основой Намерения, что немаловажно. Собственной Энергией обладает Страсть, хотя страсть может быть не только положительной, но отрицательной. Некоторые отрицательные эмоции тоже могут порождать Энергию. Такие как Месть, Зависть, Ненависть, Жадность и т.п. Но это уже скорее разрушительная энергия, чем созидательная, которая часто служит основой для Хищного Творчества или Творчества Хищников.
Что по сути статьи, но проблем будет меньше, если программировать ради удовольствия, а не за деньги, тем более которые не особо стремятся платить чуть ли не всем «кому за 30». Есть места, где хороших специалистов мало, например, у нас здесь в ЛНР / ДНР. Все одержимые уехали в Россию, профессиональной конкуренции практически нет, если не брать крупные фирмы в Донецке и Луганске (да и там вакансии имеются). Платят, правда, немного, зато есть свободное время, которое можно тратить на самообразование и программирование ради удовольствия. А стремиться надо к Интернет бизнесу, благо технические возможности для этого сейчас имеются. Единственное ограничение неразвитая межбанковская связь. Но этот вопрос, думаю, решится в ближайшие годы. А пока ничто не мешает самосовершенствоваться :).
>> Так вот это неулучшаемое представление кода в виде максимально упорядоченного линейного связного графа с левыми и правыми связями и есть тот самый «irreducible CFG»
> Нет, это совершенно другой термин. Irreducible (неприводимый?) граф — это такой граф выполнения, который не может быть выражен средствами структурного программирования, т.е. без использования goto. Посмотрите статьи на эту тему.
Не понимаю, где вы здесь увидели противоречие? Смотрим перевод «irreducible» в Multilex-2.0:
Это все варианты. В общем, то они говорят об одном и том же. Далее, смотрим определение cfg в википедии: https://en.wikipedia.org/wiki/Control_flow_graph
«A control flow graph (CFG) in computer science is a representation, using graph notation, of all paths that might be traversed through a program during its execution.» В переводе с буржуйского: «Граф потока управления (ГПУ) в информатике – это представление, с помощью графической нотации, всех путей, которые могут быть пройдены в рамках программы в ходе ее выполнения.»
Отсюда следует, что «Irreducible CFG» это неупрощаемый (неулучшаемый, неприводимый, несводимый, минимальный, канонический и т.п.) граф потока управления программного кода.
Кстати, причем здесь оператор GoTo? Направленный граф это просто кружочки со стрелочками. Ему может соответствовать код как с goto, так без него. Для графа это безразлично. В указанной вами статье «боннских товарищей» есть хороший пример cfg на рис. 3 (по сути это «Irreducible CFG», поскольку упростить этот граф уже нельзя). Смысл статьи в том, что авторы декомпилируют этот низкоуровневый «код» в псевдокод высокого уровня с помощью программы DREAM (рис. 5.1), а рядом (рис. 5.2) приводят псевдокод получаемый хорошо известным Hex-Rays от IdaPro Ильфака Гильфанова. Мол, вся фишка в том, что у Hex-Rays псевдокод использует оператор goto, а псевдокод от DREAM, goto не использует.
Но все дело в том, что я веду речь на уровне самого «графа потока управления». Да, когда этот cfg стал «иридьюсаблым», то тогда уже совершенно ультрафиолетово какой декомпилятор к нему применить. Если речь идет о Яве, то можно использовать ваш Fernflower, если о байт-коде 1С8х, то декомпилятор Авы, например, если об ассемблере, то Hex-Rays, либо DREAM (но когда он станет доступным, хотя бы в триале, это большой вопрос).
У меня задача другая, дан обфусцированный «неиридьюсаблый» граф потока управления. Мне нужно из него получить «иридьюсаблый» граф. Говоря по-русски, обфусцированный (перепутанный, намеренно усложненный) граф превратить в граф наиболее простого вида, далее уже неулучшаемого, несводимого, неприводимого и т.п. И только затем я буду применять к нему декомпилятор. В случае байткода 1С можно использовать даже собственный декомпилятор, построенный на базе идей Форт-машины.
>> При этом обфусцированный, а частности, сильно запутанный или перепутанный относительно связей код, будет содержать огромное количество как левых, так и правых связей (переходов).
> Это не обфускация, а обыкновенное перемешивание блоков. Оно не имеет никакого значения, так как мы работаем с графом, а не с линейным порядком. Хотя примитивные декомпиляторы (типа jad'a) могут и споткнуться.
Судя по всему, вы здесь проблемы не видите. Я не знаю, что из себя представляет байт код Явы, но в 1С нормально декомпилировать обфусцированный байт код пока никому явно не удается (по крайней мере, на эту тему нет публикаций), хотя с декомпиляцией необфусцированного байт кода проблем не возникает. Причем, неважно даже будет декомпилированный код с операторами гото или без них. Иногда гото позволяет упростить ситуацию, скажем, прямой выход из глубокого многомерного цикла, изредка я им даже сам пользуюсь, если только при этом логика программирования не усложняется.
Тот же байт-код 1С, даже необфусцированный, оператор гото (условный и безусловный) использует сплошь и рядом. Удобно, при собственной декомпиляции, на эту тему сильно не заморачиваться. Главное, чтобы декомпилированный код был работоспособным. Если цель состоит в том, чтобы подрегулировать что-либо только в одном месте, то полученного результата вполне достаточно. Если же нужно полное восстановление прикладного кода 1С, то просто внимательно читаем, осмысливаем, вычищаем и документируем полученный код. Эта задача относительно трудоемкая, но обозримая. За день можно таким образом обработать до 100 КБ кода высокого уровня.
Насчет линейного порядка. Узлы любого плоского графа (а может быть даже и многомерного, не проверял) можно уложить на прямую линию, полностью сохраняя топологию направленных связей. Относительно узлов любой граф линеен. Он нелинеен (плоский) относительно своих связей. Это достаточно очевидно для cfg (гпу). Тот же ассемблерный листинг бинарного кода, это линейно упорядоченный набор операторов. Другое дело, что множество переходов (связей) уже будет нелинейным. И то же самое для любого программного кода.
А обфускация это не только перепутывание и перемешивание. Просто распутывание кода, одна из самых сложных операций. Такого же уровня сложности может быть шифрование данных и кода, полиморфизм (динамическое изменение кода) и любые другие методы усложняющий анализ кода человеком, коих может быть не так уж и мало. А вот обфусцирование на уровне ЯВУ (языков высокого уровня) более простая задача, не требующая привлечения особо сложных алгоритмов.
Кстати, если вы попытаетесь декомпилировать несвязный граф, то может выйти облом, поскольку байт код не получающий управление может быть, просто абсолютно бессмысленным, но при этом выполняющимся (дефектные ветви ведь не получают управления, а на уровне исполнения байт-кода его синтаксических проверок уже может не предусматриваться, как в том же 1С8х).
> Где-то году в 2008 я написал решение на примере Явы — декомпилятор Fernflower
Круто! Я знаком с вашим декомилятором, скачал где-то из просторов Интернет и даже немного пользовался им. Впечатления очень хорошие, правда, к самой Яве я быстро охладел, все-таки с++ с фреймворками мне импонирует немного больше.
> Хм… сомневаюсь, что мы говорим об одном и том же, но все может быть.
Речь идет об абстрактных структурах. Любой программный код с точки зрения связей это ориентированный граф, узлы которого (линейные операторы либо даже произвольные блоки кода) можно упорядочить на прямой (тот же ассемблерный код), со связями перехода. Если представить себе эти связи резиновыми, а узлы фиксированными (по принципу «чёрного ящика»), то, очевидно, код, без нарушения логики работы можно упорядочивать на прямой многими разными способами. При этом обфусцированный, а частности, сильно запутанный или перепутанный относительно связей код, будет содержать огромное количество как левых, так и правых связей (переходов). В том числе он может быть сильно перемешан с кодом, который никогда не получит управления. В таком случае мы имеем несвязный граф из которых нас интересует только та связная часть графа, которая получает управление.
Исходя из сказанного, все же есть разница между декомпиляцией и деобфускацией. Например, байт код может быть не декомпилирован, но и не обфусцирован. А может быть не декомпилирован, но обфусцирован. Пока нас даже не интересует декомпиляция (скажем ассемблера в Си, как в IdaPro). Независимо от того, можем мы декомпилировать ассемблер в Си или не можем, важно сначала деобфусцировать запутанный код, а декомпилировать имеет смысл только регулярный, неулучшаемый уже в смысле распутывания либо максимального упорядочивания код.
Так вот это неулучшаемое представление кода в виде максимально упорядоченного линейного связного графа с левыми и правыми связями и есть тот самый «irreducible CFG», судя по Википедии. Понятно, что при этом количество левых связей будет минимально возможным (при направлении потока управления слева направо). Например, бесконечный оператор, ссылающийся сам на себя, может быть представлен в виде двух линейных операторов, с одной левой и одной правой связью и одной входящей связью на любой из этих операторов. Очевидно, что это уже не улучшаемое представление, в данном случае, типичный пример «irreducible CFG».
В случае обфусцированного кода, наша задача получить его сначала в виде «irreducible CFG». Как это сделать это уже другой вопрос. Еще раз подчеркну, пока о декомпиляции речь вообще не идет.
Боннская статья, на которую вы ссылаетесь, похоже рассматривает только необфусцированный код, но нам его еще нужно получить из обфусцированного кода.
У меня есть работающий алгоритм по получению неулучшаемого представления кода в виде упорядоченного связного линейного графа. В частности, байт-код 1С8х, обфусцированный Wise Advise он неплохо деобфусцировывает, а, следовательно, и позволят декомпилировать. С деобфускацией байт-кода от Awa сложностей немного больше. Но это не алгоритмические сложности, а технические, Уж очень изощренные методы применяет этот Ава. Но чисто декомпиляция Awa кода меня интересует абстрактно, просто как хорошее тестирование моего алгоритма. Главное, для меня найти математическое доказательство, что алгоритм работает всегда, а не только в данных частных случаях. Тогда можно будет и статью наваять, аналогичную как у «боннских товарищей» :).
Я бы лично в качестве манифеста опенсорса выдвинул был идею Цифрового Коммунизма Сергея Хапрова. Можно было бы говорить даже о победе Цифрового Коммунизма (ЦК) над отдельно взятой коммерческой программой, это когда проприентарный код выкладывается в открытый доступ. А также над ползучей победой ЦК во всем мире :).
Более того, со стороны государства я бы даже спонсировал, явно или неявно, некоторые общественно-полезные программные продукты вроде ReactOS и бесконечное множество других. Критерием успешности проектов могла бы быть интенсивность их использования пользователями и программистами. А государства могли бы иметь на это средства в т.ч. и за счет относительно небольшого цифрового налога взимаемого со всех, кто получает какой-либо доход.
Да, я знаю, что Rushmore изобрели не в M$, но по факту она актуальна только для VFP. Что самое смешное, никто наверняка не знает, что это за зверь. Некоторые предполагают, что она как-то очень эффективно использует матрицу индексов. Известно, что эта технология демонстрирует очень высокую производительность в запросах VFP. Думаю, что не сильно ошибусь, предположив, что целью мелкософта была именно Rushmore. Выкупив эту технологию, они в итоге убрали ее подальше, как дешевую альтернативу их sql-монстрам. Даже Access не покрывает всех возможностей и удобств VFP. Достаточно сравнить их популярность.
Относительно лицензии на Visual FoxPro, недавно эта тема подымалась на тематическом форуме sql.ru. И вроде удалось найти удовлетворительное решение.
Сейчас актуально использование runtime-библиотек VFP в c++ проектах. Причем можно даже обойтись без OLE и COM, подключившись к его dll-кам напрямую. Далее уже возможны варианты. Либо использовать VFP как DDE-сервер, либо как псевдо-COM контейнер (без регистрации в реестре).
>... любое искусство существует для того, чтобы вызвать у нас эмоции.
> Печаль, радость, злость, страх — читатель должен сопереживать героям.
Это называется «производство впечатлений» (аналогичные визуальные впечатления дают «зрелища»). Только к этому не сводиться литература (о ней, как бы речь). Здесь идет речь о воздействии на эмоциональный уровень человека. А кроме этого существуют еще ментальный и духовный уровни. Высокое искусство работает больше в этом направлении.
Дети, например, много читают (по крайней мере, читали) не столько ради новых впечатлений, сколько ради получения нового жизненного опыта. Сейчас, правда, книги заменяют мультимедиа. А вот взрослые читают меньше, жизненного опыта у них, как правило, уже достаточно и в обычных книгах они уже не находят ничего интересного для себя. Зато вполне могут читать что-то полезное для себя, например, техническую документацию, учебники, научные статьи и т.п.
У кого своего уникального жизненного опыта много – стремятся поделиться им с окружающими, хотя бы на уровне мемуаров, дневников или там технических книг и статей. Можно написать, скажем, про свою любовь, но чтобы эти банальности были интересны окружающим, надо хорошо постараться, а именно, описать свои любовные похождения (и не только!) КРАСИВО.
Другими словами, даже красиво описанные жизненные банальности это уже Литература. Не зря говорят, что красота спасет мир.
Автор через литературу может эффективно пропагандировать свои идеи. Вспомним, например, цикл произведений К. Кастанеды про Дона Хуана и магию тольтеков. Эти мексиканские учения, почему-то нашили большой отклик у русских в «лихие девяностые». Магией увлеклись сотни тысяч, причем настолько, что очень многие кончили очень плохо. Достаточно почитать об этом книги Странника и поискать информацию о «хакерах сновидений».
Но главных слов автор статьи так и не сказал. Компьютерные технологии еще не скоро составят конкуренцию литературному творчеству, но ПОМОЧЬ начинающему литератору могут уже сейчас.
Вот смотрите, есть такая бесплатная замечательная программа Blenler. По сути это электронный помощник художника, даже очень-очень начинающего. Если у вас есть идеи что-то нарисовать, ну там морской шторм, туман в горах, живой огонь и много чего еще, ограниченное только собственной фантазией, то Blender вам с относительной легкостью (после нескольких недель или месяцев тренировки) поможет это сделать. Он научит вас даже ваять мультфильмы с качеством максимально приближенным к реальности (как в современных видеоиграх). В интернете можно найти замечательные видеоролики со 100%-но сгенерированной реальностью, например на тему фэнтези, сделанные с помощью Блэндера.
Если бы существовал такой же, но литературный Blender, то проблема повышения эффективности создания литературных произведений была бы полностью решена. Зачем нужен Искусственный Интеллект для создания книг, если вполне достаточно создать литературный аналог программы Blender? И все, автор только генерит идеи, а всю черновую работу по наведению марафета (т.е., КРАСОТЫ) осуществляет электронный литературный помощник. Мне лично кажется, что подобная программа уже существует, где-то в недрах Голливуда. Другое дело, что маститые авторы из США не слишком заинтересованы в ее широком распространении.
> Обфускация здесь не имеет значения, проблема решена в том числе и для irreducible CFG.
Ну, что ж, это ключевое замечание. Как там, у Мольера, Журден очень удивился, когда узнал, что всю жизнь говорил прозой. У меня этот «irreducible CFG» назывался «ориентированный циклический плоский граф (DCG), с минимальным количеством левосторонних связей». Соответственно свой алгоритм по его получению я назвал «Алгоритм минимизации левосторонних связей ориентированного плоского графа (циклического, в общем случае)». Может быть, вы подскажите, как называется соответствующий алгоритм в вашем случае?
У меня тоже было написано выше: «Известно, что байт-код 1С8х относительно легко декомпилировать». Т.е., по смыслу, речь шла не о декомпиляции, а о деобфускации байт кода. Другими словами, если байт код 1С8х не обфусцирован, то легко декомпилируется (имеются обработки в открытом доступе от Awa), но если обфусцирован, то декомпилировать его весьма нетривиально. Тот же декомпилятор Авы обфусцирован, поэтому сам себя не компилирует, да и код 1С8х обфусцированный Wise Adbvise тоже не берет.
1. Да, готовый продукт в исходниках на 400 МБ это очень сложно. Тем более, что судя по позиционированию бизнес решений в области: «Розничная торговля», «Аптеки», «Кафе и рестораны», «Салоны красоты», «Фитнес клубы и спортивные центры», «Небольшое производство», речь идет о, в терминах 1С77, «малых и средних предприятиях». Если, скажем, воспользоваться Qt, то аналогичные исходники будут, наверняка, в несколько десятков раз меньше. Что, теоретически, уже будет под силу наваять одному человеку. Главное правильно выбрать концепцию разработки.
2. А вот с этим можно поспорить. Та же «семерка» в бинарниках весит всего 10-15 МБ. Это позволяет на стареньком сервере с двумя гектарами памяти спокойно держать в терминалке на гигабитной сети 25-30 человек, а с ОЗУ 4Гб – до 50 человек одновременно. В этом смысле распределенные приложения на «семерке» часто выигрывают по производительности и особенно в стоимости с аналогичными решениями на «восьмерке», которая, позволяет одновременно обслуживать до 500 пользователей и выше, вопрос только какой ценой.
«Семерка» реализована на примитивнейшей СУБД на базе DBase-IV и позволяет, благодаря всяким разным пользовательским внешним компонентам, достигать приемлемой производительности. Уверен, что она еще просуществует минимум 20-30 лет, хотя ее поддержка официально прекращена в 2006 году.
Я уверен, что файл-серверные СУБД вполне могут конкурировать с клиент-серверными по соотношению цена – производительность, их просто искусственно принуждают забыть, новое поколение программистов знакомо с файловыми СУБД только на уровне мифов. Вот технология Rushmore в Visual FoxPro, до сих пор никем не превзойдена, но VFP благополучно сливается самим M$, потому, что это слишком дешевая и эффективная система. Не зря в мире широко используются опен-сорсные аналоги вроде xHarbour и др., хотя им до VFP, как Киеву до безвиза.
А «скоростью работы в многопользовательской среде» вполне можно управлять концептуально правильно написанным кодом.
3. Группы в справочниках (по аналогии с каталогами, папками и файлами) это реально круто. Это сильно упрощает бизнес-логику. Также очень удобен в «семерке» быстрый поиск (перемещение по первым символом набора), вполне хорош также отбор в справочниках. И много чего хорошего и удобного по мелочам, а все ляпы фирмы 1С легко лечатся поддержкой внешних компонент, которые способны залезать (недокументированная возможность!) в самое нутро 1С.
В итоге, в 1С можно делать чудеса, при прямых руках, даже при отсутствии их исходников :).
1. Народ привык к 1С, хотя часто критикует его. Поэтому какая-то логическая совместимость должна быть. Сильные вещи в 1С – конфигуратор (позволяющий разрабатывать пользовательские бизнес-решения) и поддержка иерархической группировки (грубо говоря, деревья с таблицами вместо листьев) в таблицах (справочниках). Откровенно говоря, если бы вы реализовали «семерку» (1С77) один в один и выложили бы ее код, до она сразу бы обрела популярность и стала бы конкурентом «восьмерки» (1С8х), по словам ее отца-основателя – Бориса Нуралиева.
2. А почему файл-серверные СУБД вам не нравятся?
3. Это похоже на поддержку файловой системы в Total Commander либо Windows-Explorer.
Я уже закачиваю вашу систему, буду разбираться. В слепую, пока несколько вопросов:
1. Вы ни разу ни упомянули 1С. Как ваша система с ней соотносится, или вообще не пересекается никаким боком?
2. Какой движок БД используется? Думаю, что что-то из sql-серверов только. Это так?
3. Еще не видел вашей системы, но почему-то уверен, что в ее справочниках (в терминах 1С) нет поддержки групп на уровне интерфейса, разве что непосредственный sql отбор / фильтрация и т.п. Это так?
> Это бесценные знания, база, которая будет с Вами на протяжении всей карьеры разработчика.
Согласен, профессиональная база знаний у вас серьезная. Интересно, что вы думаете по поводу структуры индексных cdx-файлов для dbf-файлов базы данных Visual FoxPro? Это, судя по всему, B+-деревья с двойными списками на всех уровнях (судя по хилой картинке от M$). Смогли бы реализовать API для работы с ними? Похоже на то, что там реализованы, в т.ч., динамические массивы со свойствами связных списков. Что бы вы предложили для реализация этих самых «динамических массивов со свойствами связных списков»?
Еще вопрос, который меня интересует чисто с теоретической точки зрения. Известно, что байт-код 1С8х относительно легко декомпилировать. А вы сможете, хотя бы для себя (это не надо публиковать) декомпилировать обфусцированный, скажем от Wise Advise или от Авы (Awa) байт-код? Здесь уже нужно изобретать нетривиальные алгоритмы по топологической сортировке циклических(!) плоских графов. Еще точнее, там нужны немножко другие малоизвестные алгоритмы, которые без хорошего знания математики вряд ли придут в голову.
Никаких ответов, содержащих программный код, не требуется, только общие идеи.
Интересно было обнаружить ваш сайт, в том смысле, что я давно занимаюсь похожими идеями. Только я реализовал интерактивный звук (независимое прослушивание произвольных фраз аудиокниг) в локальной программе. У вас сетевой вариант, что имеет определенные преимущества для сетевых / мобильных пользователей. Недавно я обновил свою программу «Scholium» («Сколиум») до версии 1.02 и разместил на новой площадке: scholium.webservis.ru. Старую версию программы можно найти на сайте: scholium.narod.ru/Programs/Scholium_Adultly.htm. Идеология новой версии программы будет немного другая (можно почитать материалы на сайте), поэтому старую версию со временем удалю. Я добавил такой активный элемент, как «запоминание руками», что позволяет лучше усваивать письменный иностранный язык.
Странно, что вы не даете никакой контактной информации о себе. Кроме номеров счетов для поддержки вашего проекта. Да и хостовый сервер размещен в Германии. Это своеобразная защита от наезда правообладателей?: ).
Если будет желание, то мне можно будет ответить на e-mails, опубликованные на моих сайтах.
Удачи, в вашем проекте! Я могу вполне ценю ваш труд!
Очень интересный для новичка материал. Можно поучиться модульности программирования во flex / air, использованию сторонних библиотек, узнать новое об «использовании паттернов», организации последовательной обработки событий и вообще профессиональному стилю программирования. Только вот, какая бочка меда без ложки дегтя?
Я реагирую на Вашу статью как новичок во flex / air, но имеющий некоторый опыт программирования в других языках.
Помимо указанных плюсов, бросаются в глаза явные минусы. Вместо того чтобы писать собственно о своей программе, Вы пишите в основном об абстрактных концепциях программирования, имеющих разные названия в разных языках, но, по сути, являющиеся общим местом. У Вас это называется «схемой MVC», реализацией паттернов «Chain of responsibility», «Command», аналога «Memento». Хотя про паттерны я ничего толком у Вас не узнал, благо Интернет помог. Если Ваша личная заслуга в собственной реализации известных шаблонов программирования, то пишите об этом, а не о программе, которое практически никак не реализована, либо безжалостно урезана.
Я так понимаю, что известные фреймворки Вам, по разным причинам, не подошли. Вы не захотели использовать ни Mate, ни PureMVC, ни какие другие. А спрашивается, зачем? Топология Вашей «цепи» событий описана так, как будто Вы говорите о чужой технологии, а не своей собственной. Вместо нее вполне можно использовать родной механизм событий, реализованный во флэксе по умолчанию. Тем более, для такой простой «программы», как Ваша.
Про свою программу Вы практически ограничиваетесь парой фраз в паре мест. Типа, «непонятно, но здорово!». Ваша бизнес-логика нарисована странно и, вероятно, не соответствует действительности. Почему-то не показаны связи вьюеров и билдеров с энджинами, а чтобы понять работу конвейера по обработке событий, нужно, скорее всего, изучать Ваш код непосредственно. Однако он не компилируется, поскольку не все файлы Вами предоставлены, зато есть явно не нужные, типа сертификата и текстового файла к нему. Чтобы скомпилировать Ваш проект, нужно докачивать файлы из интернета, а один файл можно получить только хакерскими методами. Наверно, желающих компилировать Ваш проект было не слишком много.
Теперь собственно про Вашу программу. И если реализация на уровне кода сделана достаточно профессионально, то на уровне идеи – ниже всякой критики. И чему Вы гордитесь? Что отображаете профессионально две таблицы (грида), в которых можно рисовать «бревна»? Больше ничего Ваша демо делать не умеет. О чем это говорит?
Во-первых, о том, что Ваши «манагеры», не умеют работать с клавиатурой, им даже числа в поля надо вводить мышкой. Это, судя по скринам, в реальном опубликованном коде нет даже этого. И эти «манагеры» управляют профессиональными программистами?
Ясно, что функционал программы Вы покоцали. Чтобы никто на него не позарился? Но именно этот функционал идейно очень слаб, а сильна именно формальная сторона организации программы, которой воспользоваться можно без проблем. Правда, я бы Вашей последовательной обработке событий предпочел бы параллельную, реализованную в Мэйт. Если вьюер3 или энджин3 или дайэтер3 захочет передать сообщение 2-кластеру или как Вы там его называете, то как он сможет это сделать по Вашей схеме? В Мэйт, либо в родном обработчике событий флэкс это делается без проблем.
Во-вторых, Вы что-то намекнули про: «Группировать проекты по заказчикам, добавить возможности перетаскивания связей между проектами, перетаскивания сотрудников и проектов по папкам.. .». И вежливо промолчали дальше. А ведь это уже типичная база данных, которые удобнее решать именно средствами базы данных без понтового драг-энд-дропа.
В-третьих, а с отчетами то как? Они не нужны? Или выгружаем все в эксель и печатаем там? Это профессионально?
Знаете, подобные Вашей, базы данных реализуются в два хлопка на старой доброй 1С77. Да, там нет понтов с «перетаскиванием» мышкой, и «бревен» в гридах, но зато можно элементарно строить отчеты и легко учитывать сложнейшую схему взаимосвязей сотрудников – проектов – заказчиков – расчета стоимости – печати и т.д. и т.п. А какие у Вас преимущества, кроме реализации блажи бестолковых менеджеров? Откуда у них деньги оплачивать Ваши проекты? За счет фирмы? С такой эффективностью, зачем они вообще нужны?
Прошу не обижаться за критику, ничего личного, исключительно признание Вашего профессионализма, там, где он есть и недостатков, там, где они тоже присутствуют. А одно без другого не бывает, как две стороны одной медали.
Наверное, он опубликовал не все, что мог, однако забудут его нескоро,
Вечная память!
Как ускорить создание макетов сложных печатных форм?
Чтобы быть успешным, нужно не столько образование и опыт, сколько энергия. В таких случаях я всегда говорю: «Одержимость важнее образования!». Это в плане достижения материальных благ и широкой известности. Пример, Крис Касперски (который недавно вроде как случайно(?) погиб) Но если целью является серьезный результат, то только тогда на первом месте будет качественное образование и только на втором одержимость. Однако в любом случае без одержимости делов не будет. Даёшь адекватную одержимость – вот главный лозунг.
Тем, у кого мало собственной энергии, можно дать совет. Энергию порождает Намерение и Воля. Ни то, ни другое энергии не требуют. Однако выбирать нужно ту деятельность, уже сам процесс от которой вызывает удовлетворение. Тогда можно рассчитывать на Результат.
Попутно замечу, что Желание Энергию не порождает, но Желание может служить основой Намерения, что немаловажно. Собственной Энергией обладает Страсть, хотя страсть может быть не только положительной, но отрицательной. Некоторые отрицательные эмоции тоже могут порождать Энергию. Такие как Месть, Зависть, Ненависть, Жадность и т.п. Но это уже скорее разрушительная энергия, чем созидательная, которая часто служит основой для Хищного Творчества или Творчества Хищников.
Что по сути статьи, но проблем будет меньше, если программировать ради удовольствия, а не за деньги, тем более которые не особо стремятся платить чуть ли не всем «кому за 30». Есть места, где хороших специалистов мало, например, у нас здесь в ЛНР / ДНР. Все одержимые уехали в Россию, профессиональной конкуренции практически нет, если не брать крупные фирмы в Донецке и Луганске (да и там вакансии имеются). Платят, правда, немного, зато есть свободное время, которое можно тратить на самообразование и программирование ради удовольствия. А стремиться надо к Интернет бизнесу, благо технические возможности для этого сейчас имеются. Единственное ограничение неразвитая межбанковская связь. Но этот вопрос, думаю, решится в ближайшие годы. А пока ничто не мешает самосовершенствоваться :).
> Нет, это совершенно другой термин. Irreducible (неприводимый?) граф — это такой граф выполнения, который не может быть выражен средствами структурного программирования, т.е. без использования goto. Посмотрите статьи на эту тему.
Не понимаю, где вы здесь увидели противоречие? Смотрим перевод «irreducible» в Multilex-2.0:
1. Не поддающийся упрощению, улучшению;
2. (мат.) Несократимый; неприводимый, несводимый;
3. Минимальный;
4. Непревратимый (в иное состояние);
5. (мед.) Невправимый;
6. (книжн.) Непреодолимый.
Это все варианты. В общем, то они говорят об одном и том же. Далее, смотрим определение cfg в википедии: https://en.wikipedia.org/wiki/Control_flow_graph
«A control flow graph (CFG) in computer science is a representation, using graph notation, of all paths that might be traversed through a program during its execution.» В переводе с буржуйского: «Граф потока управления (ГПУ) в информатике – это представление, с помощью графической нотации, всех путей, которые могут быть пройдены в рамках программы в ходе ее выполнения.»
Отсюда следует, что «Irreducible CFG» это неупрощаемый (неулучшаемый, неприводимый, несводимый, минимальный, канонический и т.п.) граф потока управления программного кода.
Кстати, причем здесь оператор GoTo? Направленный граф это просто кружочки со стрелочками. Ему может соответствовать код как с goto, так без него. Для графа это безразлично. В указанной вами статье «боннских товарищей» есть хороший пример cfg на рис. 3 (по сути это «Irreducible CFG», поскольку упростить этот граф уже нельзя). Смысл статьи в том, что авторы декомпилируют этот низкоуровневый «код» в псевдокод высокого уровня с помощью программы DREAM (рис. 5.1), а рядом (рис. 5.2) приводят псевдокод получаемый хорошо известным Hex-Rays от IdaPro Ильфака Гильфанова. Мол, вся фишка в том, что у Hex-Rays псевдокод использует оператор goto, а псевдокод от DREAM, goto не использует.
Но все дело в том, что я веду речь на уровне самого «графа потока управления». Да, когда этот cfg стал «иридьюсаблым», то тогда уже совершенно ультрафиолетово какой декомпилятор к нему применить. Если речь идет о Яве, то можно использовать ваш Fernflower, если о байт-коде 1С8х, то декомпилятор Авы, например, если об ассемблере, то Hex-Rays, либо DREAM (но когда он станет доступным, хотя бы в триале, это большой вопрос).
У меня задача другая, дан обфусцированный «неиридьюсаблый» граф потока управления. Мне нужно из него получить «иридьюсаблый» граф. Говоря по-русски, обфусцированный (перепутанный, намеренно усложненный) граф превратить в граф наиболее простого вида, далее уже неулучшаемого, несводимого, неприводимого и т.п. И только затем я буду применять к нему декомпилятор. В случае байткода 1С можно использовать даже собственный декомпилятор, построенный на базе идей Форт-машины.
>> При этом обфусцированный, а частности, сильно запутанный или перепутанный относительно связей код, будет содержать огромное количество как левых, так и правых связей (переходов).
> Это не обфускация, а обыкновенное перемешивание блоков. Оно не имеет никакого значения, так как мы работаем с графом, а не с линейным порядком. Хотя примитивные декомпиляторы (типа jad'a) могут и споткнуться.
Судя по всему, вы здесь проблемы не видите. Я не знаю, что из себя представляет байт код Явы, но в 1С нормально декомпилировать обфусцированный байт код пока никому явно не удается (по крайней мере, на эту тему нет публикаций), хотя с декомпиляцией необфусцированного байт кода проблем не возникает. Причем, неважно даже будет декомпилированный код с операторами гото или без них. Иногда гото позволяет упростить ситуацию, скажем, прямой выход из глубокого многомерного цикла, изредка я им даже сам пользуюсь, если только при этом логика программирования не усложняется.
Тот же байт-код 1С, даже необфусцированный, оператор гото (условный и безусловный) использует сплошь и рядом. Удобно, при собственной декомпиляции, на эту тему сильно не заморачиваться. Главное, чтобы декомпилированный код был работоспособным. Если цель состоит в том, чтобы подрегулировать что-либо только в одном месте, то полученного результата вполне достаточно. Если же нужно полное восстановление прикладного кода 1С, то просто внимательно читаем, осмысливаем, вычищаем и документируем полученный код. Эта задача относительно трудоемкая, но обозримая. За день можно таким образом обработать до 100 КБ кода высокого уровня.
Насчет линейного порядка. Узлы любого плоского графа (а может быть даже и многомерного, не проверял) можно уложить на прямую линию, полностью сохраняя топологию направленных связей. Относительно узлов любой граф линеен. Он нелинеен (плоский) относительно своих связей. Это достаточно очевидно для cfg (гпу). Тот же ассемблерный листинг бинарного кода, это линейно упорядоченный набор операторов. Другое дело, что множество переходов (связей) уже будет нелинейным. И то же самое для любого программного кода.
А обфускация это не только перепутывание и перемешивание. Просто распутывание кода, одна из самых сложных операций. Такого же уровня сложности может быть шифрование данных и кода, полиморфизм (динамическое изменение кода) и любые другие методы усложняющий анализ кода человеком, коих может быть не так уж и мало. А вот обфусцирование на уровне ЯВУ (языков высокого уровня) более простая задача, не требующая привлечения особо сложных алгоритмов.
Круто! Я знаком с вашим декомилятором, скачал где-то из просторов Интернет и даже немного пользовался им. Впечатления очень хорошие, правда, к самой Яве я быстро охладел, все-таки с++ с фреймворками мне импонирует немного больше.
> Хм… сомневаюсь, что мы говорим об одном и том же, но все может быть.
Речь идет об абстрактных структурах. Любой программный код с точки зрения связей это ориентированный граф, узлы которого (линейные операторы либо даже произвольные блоки кода) можно упорядочить на прямой (тот же ассемблерный код), со связями перехода. Если представить себе эти связи резиновыми, а узлы фиксированными (по принципу «чёрного ящика»), то, очевидно, код, без нарушения логики работы можно упорядочивать на прямой многими разными способами. При этом обфусцированный, а частности, сильно запутанный или перепутанный относительно связей код, будет содержать огромное количество как левых, так и правых связей (переходов). В том числе он может быть сильно перемешан с кодом, который никогда не получит управления. В таком случае мы имеем несвязный граф из которых нас интересует только та связная часть графа, которая получает управление.
Исходя из сказанного, все же есть разница между декомпиляцией и деобфускацией. Например, байт код может быть не декомпилирован, но и не обфусцирован. А может быть не декомпилирован, но обфусцирован. Пока нас даже не интересует декомпиляция (скажем ассемблера в Си, как в IdaPro). Независимо от того, можем мы декомпилировать ассемблер в Си или не можем, важно сначала деобфусцировать запутанный код, а декомпилировать имеет смысл только регулярный, неулучшаемый уже в смысле распутывания либо максимального упорядочивания код.
Так вот это неулучшаемое представление кода в виде максимально упорядоченного линейного связного графа с левыми и правыми связями и есть тот самый «irreducible CFG», судя по Википедии. Понятно, что при этом количество левых связей будет минимально возможным (при направлении потока управления слева направо). Например, бесконечный оператор, ссылающийся сам на себя, может быть представлен в виде двух линейных операторов, с одной левой и одной правой связью и одной входящей связью на любой из этих операторов. Очевидно, что это уже не улучшаемое представление, в данном случае, типичный пример «irreducible CFG».
В случае обфусцированного кода, наша задача получить его сначала в виде «irreducible CFG». Как это сделать это уже другой вопрос. Еще раз подчеркну, пока о декомпиляции речь вообще не идет.
Боннская статья, на которую вы ссылаетесь, похоже рассматривает только необфусцированный код, но нам его еще нужно получить из обфусцированного кода.
У меня есть работающий алгоритм по получению неулучшаемого представления кода в виде упорядоченного связного линейного графа. В частности, байт-код 1С8х, обфусцированный Wise Advise он неплохо деобфусцировывает, а, следовательно, и позволят декомпилировать. С деобфускацией байт-кода от Awa сложностей немного больше. Но это не алгоритмические сложности, а технические, Уж очень изощренные методы применяет этот Ава. Но чисто декомпиляция Awa кода меня интересует абстрактно, просто как хорошее тестирование моего алгоритма. Главное, для меня найти математическое доказательство, что алгоритм работает всегда, а не только в данных частных случаях. Тогда можно будет и статью наваять, аналогичную как у «боннских товарищей» :).
Более того, со стороны государства я бы даже спонсировал, явно или неявно, некоторые общественно-полезные программные продукты вроде ReactOS и бесконечное множество других. Критерием успешности проектов могла бы быть интенсивность их использования пользователями и программистами. А государства могли бы иметь на это средства в т.ч. и за счет относительно небольшого цифрового налога взимаемого со всех, кто получает какой-либо доход.
Относительно лицензии на Visual FoxPro, недавно эта тема подымалась на тематическом форуме sql.ru. И вроде удалось найти удовлетворительное решение.
Сейчас актуально использование runtime-библиотек VFP в c++ проектах. Причем можно даже обойтись без OLE и COM, подключившись к его dll-кам напрямую. Далее уже возможны варианты. Либо использовать VFP как DDE-сервер, либо как псевдо-COM контейнер (без регистрации в реестре).
> Печаль, радость, злость, страх — читатель должен сопереживать героям.
Это называется «производство впечатлений» (аналогичные визуальные впечатления дают «зрелища»). Только к этому не сводиться литература (о ней, как бы речь). Здесь идет речь о воздействии на эмоциональный уровень человека. А кроме этого существуют еще ментальный и духовный уровни. Высокое искусство работает больше в этом направлении.
Дети, например, много читают (по крайней мере, читали) не столько ради новых впечатлений, сколько ради получения нового жизненного опыта. Сейчас, правда, книги заменяют мультимедиа. А вот взрослые читают меньше, жизненного опыта у них, как правило, уже достаточно и в обычных книгах они уже не находят ничего интересного для себя. Зато вполне могут читать что-то полезное для себя, например, техническую документацию, учебники, научные статьи и т.п.
У кого своего уникального жизненного опыта много – стремятся поделиться им с окружающими, хотя бы на уровне мемуаров, дневников или там технических книг и статей. Можно написать, скажем, про свою любовь, но чтобы эти банальности были интересны окружающим, надо хорошо постараться, а именно, описать свои любовные похождения (и не только!) КРАСИВО.
Другими словами, даже красиво описанные жизненные банальности это уже Литература. Не зря говорят, что красота спасет мир.
Автор через литературу может эффективно пропагандировать свои идеи. Вспомним, например, цикл произведений К. Кастанеды про Дона Хуана и магию тольтеков. Эти мексиканские учения, почему-то нашили большой отклик у русских в «лихие девяностые». Магией увлеклись сотни тысяч, причем настолько, что очень многие кончили очень плохо. Достаточно почитать об этом книги Странника и поискать информацию о «хакерах сновидений».
Но главных слов автор статьи так и не сказал. Компьютерные технологии еще не скоро составят конкуренцию литературному творчеству, но ПОМОЧЬ начинающему литератору могут уже сейчас.
Вот смотрите, есть такая бесплатная замечательная программа Blenler. По сути это электронный помощник художника, даже очень-очень начинающего. Если у вас есть идеи что-то нарисовать, ну там морской шторм, туман в горах, живой огонь и много чего еще, ограниченное только собственной фантазией, то Blender вам с относительной легкостью (после нескольких недель или месяцев тренировки) поможет это сделать. Он научит вас даже ваять мультфильмы с качеством максимально приближенным к реальности (как в современных видеоиграх). В интернете можно найти замечательные видеоролики со 100%-но сгенерированной реальностью, например на тему фэнтези, сделанные с помощью Блэндера.
Если бы существовал такой же, но литературный Blender, то проблема повышения эффективности создания литературных произведений была бы полностью решена. Зачем нужен Искусственный Интеллект для создания книг, если вполне достаточно создать литературный аналог программы Blender? И все, автор только генерит идеи, а всю черновую работу по наведению марафета (т.е., КРАСОТЫ) осуществляет электронный литературный помощник. Мне лично кажется, что подобная программа уже существует, где-то в недрах Голливуда. Другое дело, что маститые авторы из США не слишком заинтересованы в ее широком распространении.
Ну, что ж, это ключевое замечание. Как там, у Мольера, Журден очень удивился, когда узнал, что всю жизнь говорил прозой. У меня этот «irreducible CFG» назывался «ориентированный циклический плоский граф (DCG), с минимальным количеством левосторонних связей». Соответственно свой алгоритм по его получению я назвал «Алгоритм минимизации левосторонних связей ориентированного плоского графа (циклического, в общем случае)». Может быть, вы подскажите, как называется соответствующий алгоритм в вашем случае?
2. А вот с этим можно поспорить. Та же «семерка» в бинарниках весит всего 10-15 МБ. Это позволяет на стареньком сервере с двумя гектарами памяти спокойно держать в терминалке на гигабитной сети 25-30 человек, а с ОЗУ 4Гб – до 50 человек одновременно. В этом смысле распределенные приложения на «семерке» часто выигрывают по производительности и особенно в стоимости с аналогичными решениями на «восьмерке», которая, позволяет одновременно обслуживать до 500 пользователей и выше, вопрос только какой ценой.
«Семерка» реализована на примитивнейшей СУБД на базе DBase-IV и позволяет, благодаря всяким разным пользовательским внешним компонентам, достигать приемлемой производительности. Уверен, что она еще просуществует минимум 20-30 лет, хотя ее поддержка официально прекращена в 2006 году.
Я уверен, что файл-серверные СУБД вполне могут конкурировать с клиент-серверными по соотношению цена – производительность, их просто искусственно принуждают забыть, новое поколение программистов знакомо с файловыми СУБД только на уровне мифов. Вот технология Rushmore в Visual FoxPro, до сих пор никем не превзойдена, но VFP благополучно сливается самим M$, потому, что это слишком дешевая и эффективная система. Не зря в мире широко используются опен-сорсные аналоги вроде xHarbour и др., хотя им до VFP, как Киеву до безвиза.
А «скоростью работы в многопользовательской среде» вполне можно управлять концептуально правильно написанным кодом.
3. Группы в справочниках (по аналогии с каталогами, папками и файлами) это реально круто. Это сильно упрощает бизнес-логику. Также очень удобен в «семерке» быстрый поиск (перемещение по первым символом набора), вполне хорош также отбор в справочниках. И много чего хорошего и удобного по мелочам, а все ляпы фирмы 1С легко лечатся поддержкой внешних компонент, которые способны залезать (недокументированная возможность!) в самое нутро 1С.
В итоге, в 1С можно делать чудеса, при прямых руках, даже при отсутствии их исходников :).
2. А почему файл-серверные СУБД вам не нравятся?
3. Это похоже на поддержку файловой системы в Total Commander либо Windows-Explorer.
1. Вы ни разу ни упомянули 1С. Как ваша система с ней соотносится, или вообще не пересекается никаким боком?
2. Какой движок БД используется? Думаю, что что-то из sql-серверов только. Это так?
3. Еще не видел вашей системы, но почему-то уверен, что в ее справочниках (в терминах 1С) нет поддержки групп на уровне интерфейса, разве что непосредственный sql отбор / фильтрация и т.п. Это так?
Согласен, профессиональная база знаний у вас серьезная. Интересно, что вы думаете по поводу структуры индексных cdx-файлов для dbf-файлов базы данных Visual FoxPro? Это, судя по всему, B+-деревья с двойными списками на всех уровнях (судя по хилой картинке от M$). Смогли бы реализовать API для работы с ними? Похоже на то, что там реализованы, в т.ч., динамические массивы со свойствами связных списков. Что бы вы предложили для реализация этих самых «динамических массивов со свойствами связных списков»?
Еще вопрос, который меня интересует чисто с теоретической точки зрения. Известно, что байт-код 1С8х относительно легко декомпилировать. А вы сможете, хотя бы для себя (это не надо публиковать) декомпилировать обфусцированный, скажем от Wise Advise или от Авы (Awa) байт-код? Здесь уже нужно изобретать нетривиальные алгоритмы по топологической сортировке циклических(!) плоских графов. Еще точнее, там нужны немножко другие малоизвестные алгоритмы, которые без хорошего знания математики вряд ли придут в голову.
Никаких ответов, содержащих программный код, не требуется, только общие идеи.
Странно, что вы не даете никакой контактной информации о себе. Кроме номеров счетов для поддержки вашего проекта. Да и хостовый сервер размещен в Германии. Это своеобразная защита от наезда правообладателей?: ).
Если будет желание, то мне можно будет ответить на e-mails, опубликованные на моих сайтах.
Удачи, в вашем проекте! Я могу вполне ценю ваш труд!
Я реагирую на Вашу статью как новичок во flex / air, но имеющий некоторый опыт программирования в других языках.
Помимо указанных плюсов, бросаются в глаза явные минусы. Вместо того чтобы писать собственно о своей программе, Вы пишите в основном об абстрактных концепциях программирования, имеющих разные названия в разных языках, но, по сути, являющиеся общим местом. У Вас это называется «схемой MVC», реализацией паттернов «Chain of responsibility», «Command», аналога «Memento». Хотя про паттерны я ничего толком у Вас не узнал, благо Интернет помог. Если Ваша личная заслуга в собственной реализации известных шаблонов программирования, то пишите об этом, а не о программе, которое практически никак не реализована, либо безжалостно урезана.
Я так понимаю, что известные фреймворки Вам, по разным причинам, не подошли. Вы не захотели использовать ни Mate, ни PureMVC, ни какие другие. А спрашивается, зачем? Топология Вашей «цепи» событий описана так, как будто Вы говорите о чужой технологии, а не своей собственной. Вместо нее вполне можно использовать родной механизм событий, реализованный во флэксе по умолчанию. Тем более, для такой простой «программы», как Ваша.
Про свою программу Вы практически ограничиваетесь парой фраз в паре мест. Типа, «непонятно, но здорово!». Ваша бизнес-логика нарисована странно и, вероятно, не соответствует действительности. Почему-то не показаны связи вьюеров и билдеров с энджинами, а чтобы понять работу конвейера по обработке событий, нужно, скорее всего, изучать Ваш код непосредственно. Однако он не компилируется, поскольку не все файлы Вами предоставлены, зато есть явно не нужные, типа сертификата и текстового файла к нему. Чтобы скомпилировать Ваш проект, нужно докачивать файлы из интернета, а один файл можно получить только хакерскими методами. Наверно, желающих компилировать Ваш проект было не слишком много.
Теперь собственно про Вашу программу. И если реализация на уровне кода сделана достаточно профессионально, то на уровне идеи – ниже всякой критики. И чему Вы гордитесь? Что отображаете профессионально две таблицы (грида), в которых можно рисовать «бревна»? Больше ничего Ваша демо делать не умеет. О чем это говорит?
Во-первых, о том, что Ваши «манагеры», не умеют работать с клавиатурой, им даже числа в поля надо вводить мышкой. Это, судя по скринам, в реальном опубликованном коде нет даже этого. И эти «манагеры» управляют профессиональными программистами?
Ясно, что функционал программы Вы покоцали. Чтобы никто на него не позарился? Но именно этот функционал идейно очень слаб, а сильна именно формальная сторона организации программы, которой воспользоваться можно без проблем. Правда, я бы Вашей последовательной обработке событий предпочел бы параллельную, реализованную в Мэйт. Если вьюер3 или энджин3 или дайэтер3 захочет передать сообщение 2-кластеру или как Вы там его называете, то как он сможет это сделать по Вашей схеме? В Мэйт, либо в родном обработчике событий флэкс это делается без проблем.
Во-вторых, Вы что-то намекнули про: «Группировать проекты по заказчикам, добавить возможности перетаскивания связей между проектами, перетаскивания сотрудников и проектов по папкам.. .». И вежливо промолчали дальше. А ведь это уже типичная база данных, которые удобнее решать именно средствами базы данных без понтового драг-энд-дропа.
В-третьих, а с отчетами то как? Они не нужны? Или выгружаем все в эксель и печатаем там? Это профессионально?
Знаете, подобные Вашей, базы данных реализуются в два хлопка на старой доброй 1С77. Да, там нет понтов с «перетаскиванием» мышкой, и «бревен» в гридах, но зато можно элементарно строить отчеты и легко учитывать сложнейшую схему взаимосвязей сотрудников – проектов – заказчиков – расчета стоимости – печати и т.д. и т.п. А какие у Вас преимущества, кроме реализации блажи бестолковых менеджеров? Откуда у них деньги оплачивать Ваши проекты? За счет фирмы? С такой эффективностью, зачем они вообще нужны?
Прошу не обижаться за критику, ничего личного, исключительно признание Вашего профессионализма, там, где он есть и недостатков, там, где они тоже присутствуют. А одно без другого не бывает, как две стороны одной медали.