Re: "modeled and configured and not programmed".

My personal interest in this question is long-term. I had the experience 20
years ago of the company I worked for trying to replace their customisable
product with a highly configurable one. I left soon after as the
configurable one looked very good.

I think that for a purely data-management application, configuration is
usually going to be more cost-effective than programming, even with Isis.

For CRUD OO code doesn't actually add alot of benefit, as REST and the
success of the WWW ably demonstrate

In fact as configurable systems get more and more complex, the need for
programming disappears, to be replaced by 'configurators' (business
analysts?) tweeking workflow and rules engines.

This seems to me to be a break with the OO dogma of objects with behaviour
and going back to an older procedural approach. Contributions in Isis seem
to be of this nature.

But for me Isis is of interest for systems where modelling and
encapsulating behaviour is important, to build complex systems that can be
maintained long-term. I suspect that configurable systems, when taken
beyond a point of complexity become unmanageable, the spreadsheet syndrome.
The configurators become the point of weakness.

The Naked Object pattern seems to me a bit like the constraints of REST,
there for a reason, to provide a particular kind of system with specific
strengths.

However, I do wonder if Isis can also become a configurable system, when
necessary, that you could define the meta-model independantly from the Java
OO model and use it as a means of configuring a RESTful CRUD system.

I see this as meta-model controlling the generated UI, and speaking
directly to a database. All the pieces are there it would seem.

You might win some RAD competitions, but so?

I guess is depends on whether you like being a programmer or a configurator.

:)








On Sun, Oct 4, 2015 at 12:57 AM, Dan Haywood <[email protected]>
wrote:

> On Sept 25th and 26th we (Jeroen van der Wal & Dan Haywood) took part in
> the Original RAD Race competition. This is a competition staged each year,
> this year (as in previous years) hosted and sponsored by Cap Gemini, and
> held in their offices in Utrecht, Netherlands.
>
> The competition consists of teams of exactly two team members; there were
> eight in total. The competition is held under very strict conditions: 8
> hours of development on the first day, and a further 4 hours of coding the
> next. If you do the maths you’ll work out that means a sum total of 24
> hours (2 team members x 12 hours), or 3 person-days.
>
> We asked and were granted permission to develop our application as open
> source; our entry is in a github repo [1]. If you look through the commit
> history you’ll see that all the work was done in those 12 hours (8 on 25
> Sept 2015, a further 4 on 26 Sept).
>
> All the other teams used proprietary tools such as NoutBuilder, ThinkWise,
> Progress, SalesForce, Uniface and Mendix. We were the only open source
> entry, using Apache Isis [2] (along with supporting modules in Isis Addons
> [3]); in fact we think we are the first open source entry in the 17 years
> history of the competition.
>
> OK, we didn’t win…​  but we got the impression we were mid-table, which we
> think is pretty good in the face of the competition. But you can judge for
> yourself; either download and build the code, or simply take a look at the
> various screenshots/our commentary on the README of the repo [1].
>
> The README also has some of our "learnings" that we concluded from taking
> part in the competition.
>
>
> [1] https://github.com/incodehq/radrace2015
> [2] http://isis.apache.org/
> [3] http://www.isisaddons.org/
>

Reply via email to