Что общего у комментариев к статье на Хабре и дополнительных опций при покупке машины?



С точки зрения моделирования данных, и то, и другое — “вложенные” сущности, которые не имеют самостоятельного значения в отрыве от родительского объекта.

В Yii (php framework) есть Gii — встроенный генератор кода, который позволяет в несколько кликов мышкой создавать базовые CRUD-интерфейсы по модели данных, которые значительно ускоряют разработку, но применимы только для самостоятельных сущностей, как статья или машина в примерах выше.

Было бы здорово, чтобы можно было сгенерировать что-то подобное для “вложенных” объектов данных, верно? Теперь — можно, добро пожаловать под кат за подробностями.

Понятие BPM (Business Process Management) все более плотно входит в жизнь больших и малых корпораций. Суть его в том, чтобы рассматривать бизнес-процессы компании, как активы, используя которые можно увеличить прибыльность своего бизнеса. Инструмент, который вы для этого используете, может быть любым: лист бумаги, текстовый документ, Visio или любое другое средство создания диаграмм… Но есть класс инструментов, которые специально предназначены для того, чтобы послужить инструментом для трансформации вашего бизнеса — это BPM-платформы.
Задача для такой платформы ставится двояко: с одной стороны необходимо визуализировать бизнес-процесс, а с другой стороны — его нужно исполнить.



Я не буду описывать весь рынок таких платформ, это неплохо сделано в статье независимого агентства Gartner, откуда я взял иллюстрацию выше (полный текст можно скачать с сайта Pega или IBM, но потребуется регистрация, или нагуглить самостоятельно по заголовку: “Gartner BPM Magic Quadrant 2014”).
Цель же данной статьи — провести сравнение технических возможностей двух лидирующих платформ, Pega и IBM BPM, доступных на текущий момент (осень 2014), с точки зрения опыта их использования в проектах по автоматизации бизнес-процессов.

Если вы задумали трансформировать свой бизнес или вам нужно IT-решение, которое позволит достичь бизнес-целей, поставленных высшим руководством, или вы просто интересуетесь BPM-решениями, то добро пожаловать под кат.

Недавно команда Whistling Kite Framework выпустила в релиз очередную игру, на этот раз — Змейку, написанную на Unity3D. Как и в большинстве игровых проектов, при решении вопроса о том, насколько детально нужно проектировать приложение, критическим фактором было время. В нашем случае причина проста: т.к. разработка велась в свободное от основной работы время, то идеальный подход к проектированию отложил бы релиз ещё на год. Поэтому, составив первоначальное разделение на модули, мы закончили проектирование и приступили к разработке. Под катом описание того, что из этого получилось, а также пара уроков, которые я вынес для себя.


Осторожно, картинки!

Помните начало фильма «Я — робот»? Там профессор читает лекцию о явлении «Души» в коде программы:

«Когда программа растет, особенно когда ею занимаются много людей, неизбежно начинают встречаться куски так называемого „мертвого кода“. Это оставшиеся функции, которые оказались заменены более новыми или просто тестовый код, забытый программистом.
Когда таких кусков накапливается некоторая критическая масса, это может привести к неожиданным действиям в алгоритме, которые на сторонний взгляд можно назвать проявлением своей воли или „Душой“ программы»

Цитата не претендует на точность, но смысле таков. В свете этого и недавних топиков на хабре о том, чтобы проверять имена переменных на разные значения в разных языках (простите, не смог найти линк), я решил описать маленький случай, произошедший со мной. Возможно, если кто-нибудь так же встречался с «проявлениями души», которые на проверку оказывались самыми банальными ошибками в коде, то он захочет скинуть пример в комментарий или дать мне инвайт.