[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16952634#comment-16952634 ] Alexander Dolgunin edited comment on ISIS-1303 at 11/1/19 11:07 AM: Apache Rubedo (the final stage of the Great Work) [https://en.wikipedia.org/wiki/Rubedo] sounds better than *Rubato* to me. Also liked Adept tag lines and series of associations. On another hand, Isis is good as in: priests of Isis (highly cognizant/conscious individuals as I can judge from your 2017 IsisCon write-up) just replace Isis with one of: Dendera (largest and best-known temple dedicated to Isis among others), Nephthys (her sister which rescued Osiris in cooperation with her), Ankh (an important symbolic attribute), Sistrum (another divine accessory) or Candace (a royal figure closely related to Isis). It will be clear to the _literati_ that Dendera/Nephthys/Ankh/Sistrum/Candace is probably a framework previously known as Isis :) If Nephthys spells awkwardly to anyone, just look at some other software names... was (Author: alexander.d): Apache Rubedo (the final stage of the Great Work) [https://en.wikipedia.org/wiki/Rubedo] sounds better than *Rubato* to me > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Daniel Keir Haywood >Priority: Major > Fix For: 2.4.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, > ApacheGestalt.jpg, Offset-curves-of-sinus-curve.svg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidat
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16056020#comment-16056020 ] Oscar Bou edited comment on ISIS-1303 at 6/20/17 4:15 PM: -- Hi all, +1 for Apache Alma for the following reasons: - It's sorter. - It's meaningful and fully aligned with the Domain being the "soul" of your project. - It's an alliteration, meaning we will have greater visibility! - Being Spanish the second/third most used language (if considering not only native people but also people with low, but a bit, knowledge, and also number of countries with it as official language) many people will immediately know the meaning and catch the simile, retaining it in memory, - It sounds better! ha ha Cheers! was (Author: oscarbou): Hi all, +1 for Apache Alma for the following reasons: - It's sorter. - It's meaningful and fully aligned with the Domain being the "soul" of your project. - It's an alliteration, meaning we will have greater visibility! - Being Spanish the second/third most used language (if considering not only native people but also people with low, but a bit, knowledge, and also number of countries with it as official language), - It sounds better! ha ha Cheers! > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood > Fix For: 1.20.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, > ApacheGestalt.jpg, Offset-curves-of-sinus-curve.svg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architect
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16045866#comment-16045866 ] Dan Haywood edited comment on ISIS-1303 at 6/16/17 6:39 AM: At IsisCon 2017, held in Amsterdam in June, we had some great discussions about who to pitch the framework to (as well as possible inhibitors). We agreed, I think, that the pitch is to IT Managers/CTOs, who understand the needs of the business, and either know enough about technology to make the call or (probably more likely) would rely on a trusted "technical" leiutenant to help make the call about whether to explore our framework. But we don't pitch to the techies directly. (There is a separate discussion about what to do to ensure that those technical leiutenants don't "veto" our framework for unimportant reasons... won't address here). Anyway, with respect to a pitch to a business aware IT Manager/CTO, we only want to talk to those who *"want to allow the business change"*, who see that *requires a feedback loop* (because one can't know a priori that every change is a good change), would understand our philosophy that *IT is not a cost centre but is a profit centre*, that IT systems should be sized as the *minimum needed to run your business* (software is expensive to own, so have as little as possible of it). If those ideas fall flat, then better to fail fast on that prospect and find someone else to talk to. But for those for whom the above ideas do resonate, then we have a target audience and can start the conversation. In general there seemed to be an appetite to change the name of the framework; apart from its (current) negative connotations, the name "Isis" doesn't actually mean very much, so not having an apposite name (and corresponding strapline) is a missed opportunity in terms of introducing the framework On that note, here were some additional names that came out: * _Apache Shortcut_ : rapid development. Possible negative connotations though? (hacky, bodge) * _Apache Loop_ : as in feedback loops. * _Apache Alma_ : "Alma" is Spanish for soul, it's also the rod in the middle of a string instrument that connects the bridge to the body, so that the instrument resonates. Nice and alliterative. *"The soul of your business"* * _Apache Kokoro_: picking up on the soul idea, "Kokoro" is Japanese that combines the (in the Western culture) concepts of soul and heart and mind. So again, the "soul of your business". * _Apache Soul_: same idea, also Soul Jazz. * _Apache Affknaai_ - tongue in cheek suggestion, given our history of "unfortunate names" ... a framework formerly known as apache isis The top candidates, with possible straplines, we ended up with are: * *Apache Kokoro*: _"the soul of your business"_ (or maybe: _"the essence of your business"_ ) * *Apache Alma*: _"the soul of your business"_ * *Apache Rubato*: _"play your own tune"_ (or maybe: _"play freely"_) * *Apache Tailor*: _"fit for business"_ FWIW I've listed these in my own preference order was (Author: danhaywood): At IsisCon 2017, held in Amsterdam in June, we had some great discussions about who to pitch the framework to (as well as possible inhibitors). We agreed, I think, that the pitch is to IT Managers/CTOs, who understand the needs of the business, and either know enough about technology to make the call or (probably more likely) would rely on a trusted "technical" leiutenant to help make the call about whether to explore our framework. But we don't pitch to the techies directly. (There is a separate discussion about what to do to ensure that those technical leiutenants don't "veto" our framework for unimportant reasons... won't address here). Anyway, with respect to a pitch to a business aware IT Manager/CTO, we only want to talk to those who *"want to allow the business change"*, who see that *requires a feedback loop* (because one can't know a priori that every change is a good change), would understand our philosophy that *IT is not a cost centre but is a profit centre*, that IT systems should be sized as the *minimum needed to run your business* (software is expensive to own, so have as little as possible of it). If those ideas fall flat, then better to fail fast on that prospect and find someone else to talk to. But for those for whom the above ideas do resonate, then we have a target audience and can start the conversation. In general there seemed to be an appetite to change the name of the framework; apart from its (current) negative connotations, the name "Isis" doesn't actually mean very much, so not having an apposite name (and corresponding strapline) is a missed opportunity in terms of introducing the framework On that note, here were some additional names that came out: * _Apache Shortcut_ : rapid development. Possible negative connotations
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16046532#comment-16046532 ] Dan Haywood edited comment on ISIS-1303 at 6/16/17 6:36 AM: +1 for Kokoro and Rubato. I think I prefer Rubato of the two (but defintely don't intend to make things even more complicated ;) ) was (Author: jwgmeligmeyling): +1 for Kikoro and Rubato. I think I prefer Rubato of the two (but defintely don't intend to make things even more complicated ;) ) > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood > Fix For: 1.20.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, > ApacheGestalt.jpg, Offset-curves-of-sinus-curve.svg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI (data/context/interactions). > - "clean" "pure" "essential" pojo programming model > - agile, lean > - breaking down barriers between IT and business > Of these, I think that hexagonal architecture looks the best fit; it is well > regarded as a concept among the "cognoscenti", but there are surprisingly no > open source frameworks out there (at least in the Java space) that position > themselves as being t
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16045866#comment-16045866 ] Dan Haywood edited comment on ISIS-1303 at 6/16/17 6:30 AM: At IsisCon 2017, held in Amsterdam in June, we had some great discussions about who to pitch the framework to (as well as possible inhibitors). We agreed, I think, that the pitch is to IT Managers/CTOs, who understand the needs of the business, and either know enough about technology to make the call or (probably more likely) would rely on a trusted "technical" leiutenant to help make the call about whether to explore our framework. But we don't pitch to the techies directly. (There is a separate discussion about what to do to ensure that those technical leiutenants don't "veto" our framework for unimportant reasons... won't address here). Anyway, with respect to a pitch to a business aware IT Manager/CTO, we only want to talk to those who *"want to allow the business change"*, who see that *requires a feedback loop* (because one can't know a priori that every change is a good change), would understand our philosophy that *IT is not a cost centre but is a profit centre*, that IT systems should be sized as the *minimum needed to run your business* (software is expensive to own, so have as little as possible of it). If those ideas fall flat, then better to fail fast on that prospect and find someone else to talk to. But for those for whom the above ideas do resonate, then we have a target audience and can start the conversation. In general there seemed to be an appetite to change the name of the framework; apart from its (current) negative connotations, the name "Isis" doesn't actually mean very much, so not having an apposite name (and corresponding strapline) is a missed opportunity in terms of introducing the framework On that note, here were some additional names that came out: * _Apache Shortcut_ : rapid development. Possible negative connotations though? (hacky, bodge) * _Apache Loop_ : as in feedback loops. * _Apache Alma_ : "Alma" is Spanish for soul, it's also the rod in the middle of a string instrument that connects the bridge to the body, so that the instrument resonates. Nice and alliterative. *"The soul of your business"* * _Apache Kokoro_: picking up on the soul idea, "Kokoro" is Japanese that combines the (in the Western culture) concepts of soul and heart and mind. So again, the "soul of your business". * _Apache Soul_: same idea, also Soul Jazz. * _Apache Affknaai_ - tongue in cheek suggestion, given our history of "unfortunate names" ... a framework formerly known as apache isis The top candidates, with possible straplines, we ended up with are: * *Apache Kokoro*: _"the soul of your business"_ * *Apache Kokoro*: _"the essence of your business"_ * *Apache Alma*: _"the soul of your business"_ * *Apache Rubato*: _"play your own tune"_ * *Apache Rubato*: _"play freely"_ * *Apache Tailor*: _"fit for business"_ FWIW I've listed these in my own preference order was (Author: danhaywood): At IsisCon 2017, held in Amsterdam in June, we had some great discussions about who to pitch the framework to (as well as possible inhibitors). We agreed, I think, that the pitch is to IT Managers/CTOs, who understand the needs of the business, and either know enough about technology to make the call or (probably more likely) would rely on a trusted "technical" leiutenant to help make the call about whether to explore our framework. But we don't pitch to the techies directly. (There is a separate discussion about what to do to ensure that those technical leiutenants don't "veto" our framework for unimportant reasons... won't address here). Anyway, with respect to a pitch to a business aware IT Manager/CTO, we only want to talk to those who *"want to allow the business change"*, who see that *requires a feedback loop* (because one can't know a priori that every change is a good change), would understand our philosophy that *IT is not a cost centre but is a profit centre*, that IT systems should be sized as the *minimum needed to run your business* (software is expensive to own, so have as little as possible of it). If those ideas fall flat, then better to fail fast on that prospect and find someone else to talk to. But for those for whom the above ideas do resonate, then we have a target audience and can start the conversation. In general there seemed to be an appetite to change the name of the framework; apart from its (current) negative connotations, the name "Isis" doesn't actually mean very much, so not having an apposite name (and corresponding strapline) is a missed opportunity in terms of introducing the framework On that note, here were some additional names that came out: * _Apache Shortcut_ : rapid development. Possible negative c
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15314047#comment-15314047 ] Dan Haywood edited comment on ISIS-1303 at 6/3/16 12:40 PM: Just to say, haven't forgotten about this ticket/initiative. If anyone wants to do the trademark searches for their favorite, and update the wiki page (https://cwiki.apache.org/confluence/display/ISIS/Name+ideas), that would be peachy. Meantime, I have one further suggestion, namely *"Apache Tailor"*. Why? because we're about building bespoke/custom systems that fit the business (compare to an off-the-peg system where the business has to bend/be constrained by that package software). This is directly tackling the "build vs buy" argument, which is one of the most fundamental questions that needs to be answered. And "tailoring" is a metaphor that non-technical people can readily understand. was (Author: danhaywood): Just to say, haven't forgotten about this ticket/initiative. If anyone wants to do the trademark searches for their favorite, and update the wiki page (https://cwiki.apache.org/confluence/display/ISIS/Name+ideas), that would be peachy. Meantime, I have one further suggestion, namely "Apache Tailor". Why? because we're about building bespoke/custom systems that fit the business (compare to an off-the-peg system where the business has to bend/be constrained by that package software). This is directly tackling the "build vs buy" argument, which is one of the most fundamental questions that needs to be answered. And "tailoring" is a metaphor that non-technical people can readily understand. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.15.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, > ApacheGestalt.jpg, Offset-curves-of-sinus-curve.svg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to de
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15154218#comment-15154218 ] Jörg Rade edited comment on ISIS-1303 at 4/22/16 12:47 PM: --- The Rodin Thinker is already used by http://sculptorgenerator.org/ Torsten Juergeleit (from sculptor) contributed https://libraries.io/github/vaulttec/isis-script My current favorites are: Razor (like in Occams Razor). Amp, Ippon, Hajime, and Root. An Amp logo could look like !Offset-curves-of-sinus-curve.svg! in Isis or Apache colors. Using an alliteration name gives a push in sorting as well. was (Author: joerg.rade): The Rodin Thinker is already used by http://sculptorgenerator.org/ Torsten Juergeleit (from sculptor) contributed https://libraries.io/github/vaulttec/isis-script My current favorites are: Amp, Ippon, Hajime, and Root. An Amp logo could look like !Offset-curves-of-sinus-curve.svg! in Isis or Apache colors. Using an alliteration name gives a push in sorting as well. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.15.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, > ApacheGestalt.jpg, Offset-curves-of-sinus-curve.svg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objec
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15154218#comment-15154218 ] Jörg Rade edited comment on ISIS-1303 at 2/19/16 1:46 PM: -- The Rodin Thinker is already used by http://sculptorgenerator.org/ Torsten Juergeleit (from sculptor) contributed https://libraries.io/github/vaulttec/isis-script My current favorites are: Amp, Ippon, Hajime, and Root. An Amp logo could look like !Offset-curves-of-sinus-curve.svg! in Isis or Apache colors. Using an alliteration name gives a push in sorting as well. was (Author: joerg.rade): The Rodin Thinker is already used by http://sculptorgenerator.org/ Torsten Juergeleit (from sculptor) contributed https://libraries.io/github/vaulttec/isis-script My current favorites are: Amp, Ippon, Hajime, and Root. An Amp logo could look like [Offset-curves-of-sinus-curve.svg] in Isis or Apache colors. Using an alliteration name gives a push in sorting as well. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, > ApacheGestalt.jpg, Offset-curves-of-sinus-curve.svg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recog
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152182#comment-15152182 ] Ged edited comment on ISIS-1303 at 2/18/16 1:41 PM: Adept: "an individual identified as having attained a specific level of knowledge, skill, or aptitude." I like that. h1. Apache Adept h2. Amplifying Knowledge, Skill & Aptitude. was (Author: ged.by...@gmail.com): Adept: "an individual identified as having attained a specific level of knowledge, skill, or aptitude." I like that. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI (data/context/interactions). > - "clean" "pure" "essential" pojo programming model > - agile, lean > - breaking down barriers between IT and business > Of these, I think that hexagonal architecture looks the best fit; it is well > regarded as a concept among the "cognoscenti", but there are surprisingly no > open source frameworks out there (at least in the Java space) that positio
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152179#comment-15152179 ] Ged edited comment on ISIS-1303 at 2/18/16 11:27 AM: - * For Humans Solving Business Problems: Faster, Further and Better. ... my suggestion, paraphasing Engelbart. was (Author: ged.by...@gmail.com): * For Humans Solving Business Problems: Speedier, Faster and Further. ... my suggestion, paraphasing Engelbart. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI (data/context/interactions). > - "clean" "pure" "essential" pojo programming model > - agile, lean > - breaking down barriers between IT and business > Of these, I think that hexagonal architecture looks the best fit; it is well > regarded as a concept among the "cognoscenti", but there are surprisingly no > open source frameworks out there (at least in the Java space) that position > themselves as being the natural choice. > Therefore, I think a name - a
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152179#comment-15152179 ] Ged edited comment on ISIS-1303 at 2/18/16 11:27 AM: - * For Humans Solving Business Problems: Speedier, Faster and Further. ... my suggestion, paraphasing Engelbart. was (Author: ged.by...@gmail.com): * For Humans Solving Business Problems: Speedier, Faster and Further. --- my suggestion, paraphasing Engelbart. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI (data/context/interactions). > - "clean" "pure" "essential" pojo programming model > - agile, lean > - breaking down barriers between IT and business > Of these, I think that hexagonal architecture looks the best fit; it is well > regarded as a concept among the "cognoscenti", but there are surprisingly no > open source frameworks out there (at least in the Java space) that position > themselves as being the natural choice. > Therefore, I think a na
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15149145#comment-15149145 ] Dan Haywood edited comment on ISIS-1303 at 2/16/16 7:25 PM: Been mulling over some further name ideas, riffing on the idea of our being a framework for connoisseurs, not hipsters. So one idea is simply "Apache Connoisseur"... but it's difficult to spell and somewhat pretentious. Looking for synonyms, I found "adept", which I like quite a lot : "Apache Adept". That days something about both the framework and the short of developers for whom it is intended. It even alludes to the business users, our "problem solvers, not process followers" Changing tack slightly, was also thinking about the gearing metaphor, which led me to amplification... this "Apache Amp". I do quite like the way that sounds, too. Have added them all to the wiki page. was (Author: danhaywood): Been mlling over some further name ideas, riffing on the idea of our being a framework for connoisseurs, not hipsters. So one idea is simply "Apache Connoisseur"... but it's difficult to spell and somewhat pretentious. Looking for synonyms, I found "adept", which I like quite a lot : "Apache Adept". That days something about both the framework and the short of developers for whom it is intended. It even alludes to the business users, our "problem solvers, not process followers" Changing tack slightly, was also thinking about the gearing metaphor, which led me to amplification... this "Apache Amp". I do quite like the way that sounds, too. Have added them all to the wiki page. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134896#comment-15134896 ] David Tildesley edited comment on ISIS-1303 at 2/5/16 8:42 PM: --- Hi All, My suggestion: Apache Jedu JEDU is "Just Enough Design Upfront" - sweet spot for Apache ISIS as a tool to aid consensus based domain modelling - which is JEDU in practice. N.B. - removed the reference to Czech translation - I got that wrong - sorry. As a Czech sounding verb equivalent, apparently it may mean "go" / "take a ride". Remarkably, while easy to pronounce, it really doesn't have any meanings in languages according to Google search apart from the Czech verb reference. David. was (Author: davotnz): Hi All, My suggestion: Apache Jedu JEDU is "Just Enough Design Upfront" - sweet spot for Apache ISIS as a tool to aid consensus based domain modelling - which is JEDU in practice. N.B. - removed the reference to Czech translation - I got that wrong - sorry. David. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recogni
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134896#comment-15134896 ] David Tildesley edited comment on ISIS-1303 at 2/5/16 8:23 PM: --- Hi All, My suggestion: Apache Jedu JEDU is "Just Enough Design Upfront" - sweet spot for Apache ISIS as a tool to aid consensus based domain modelling - which is JEDU in practice. N.B. - removed the reference to Czech translation - I got that wrong - sorry. David. was (Author: davotnz): Hi All, My suggestion: Apache Jedu "Jedu" is Czech for "Jet" which invokes the idea of "rapid", "speed". JEDU is "Just Enough Design Upfront" - sweet spot for Apache ISIS as a tool to aid consensus based domain modelling - which is JEDU in practice. David. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI (data/context/interactions). > - "clean" "pure" "essential" pojo programming model > - agile, lean > - breaking down barriers between IT and bus
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134478#comment-15134478 ] Cesar Lugo edited comment on ISIS-1303 at 2/5/16 5:04 PM: -- If voting helps, my personal votes: Apache Ippon "Win. Now." Reason: Elegant, straight to the main point, sounds cool. Slogan / tagline derived from meaning avoids the need for explanations. Calls to action. Apache Reflect "From Prototype to Business" or "Domain. Prototype. Business" Reason: Dan explained reflection over the business domain. Combined a little two of the slogans / taglines. Apache XA6on "Don´t be square" Reason: Emphasis on augmentation through the multiplier effect of the hexagonal architecture (Your App X 6 ). Slogan calls to think twice the way you do things now (vs other leading frameworks). Cesar. was (Author: cesar.l...@sisorg.com.mx): If voting helps, my personal votes: Apache Ippon "Win. Now." Reason: Elegant, straight to the main point, sounds cool. Slogan / tagline derived from meaning avoids the need for explanations. Calls to action. Apache Reflect / Reflex "From Prototype to Business" or "Domain. Prototype. Business" Reason: Dan explained reflection over the business domain. Combined a little two of the slogans / taglines. Apache XA6on "Don´t be square" Reason: Emphasis on augmentation through the multiplier effect of the hexagonal architecture (Your App X 6 ). Slogan calls to think twice the way you do things now (vs other leading frameworks). Cesar. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15133414#comment-15133414 ] Steve Cameron edited comment on ISIS-1303 at 2/5/16 1:56 AM: - I like this discussion, to choose a name I suggest to forget about the technical side (e.g hexagon) for a bit and think of something that has more 'mojo', find a name with good association, even a made-up name (e.g Microsoft, Facebook). I've previously suggested Apache Driver (Driven, Driverseat, Highway, Freeway) to Dan and Jeroen. Driver reflects the NO and DDD heritage (does the software drive the business or the business drive the software, well hopefully both). In terms of marketing, in general the goal is to provide people with what they want or think they want (i.e. get a rabbit costume), they are out shopping, have money to spend (figuratively speaking), your advertising has worked, now you just have to convince them that what you are offering represents the best value amongst competing alternatives. Good sales-persons can be creative with the truth to achieve this, but I don't think that is the approach to take here! The buyers will have some technical nouse, but "closing the sale" is still necessary, you have to get a "decision to action". Again, I've suggested offering 1 day training courses as one way to do this, as help to "try-before-you-buy" (the videos that Dan does are a start but can be built upon further). Maybe Apache River (as in something that flows through a Valley), that might have been the original thought? was (Author: steve cameron): I like this discussion, to choose a name I suggest to forget about the technical side (e.g hexagon) for a bit and think of something that has more 'mojo', find a name with good association, even a made-up name (e.g Microsoft, Facebook). I've previously suggested Apache Driver (Driven, Driverseat, Highway, Freeway) to Dan and Jeroen. Driver reflects the NO and DDD heritage (does the software drive the business or the business drive the software, well hopefully both). In terms of marketing, in general the goal is to provide people with what they want or think they want (i.e. get a rabbit costume), they are out shopping, have money to spend (figuratively speaking), your advertising has worked, now you just have to convince them that what you are offering represents the best value amongst competiting alternatives. Good sales-persons can be creative with the truth to achieve this, but I don't think that is the approach to take here! The buyers will have some technical nouse, but "closing the sale" is still necessary, you have to get a decision to action. Again, I've suggested offering 1 day training courses as one way to do this, as help to "try-before-you-buy" (the videos that Dan does are good, but can be built upon further). Maybe Apache River (as in something that flows through a Valley), that might have been the original thought. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the syst
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15133414#comment-15133414 ] Steve Cameron edited comment on ISIS-1303 at 2/5/16 12:37 AM: -- I like this discussion, to choose a name I suggest to forget about the technical side (e.g hexagon) for a bit and think of something that has more 'mojo', find a name with good association, even a made-up name (e.g Microsoft, Facebook). I've previously suggested Apache Driver (Driven, Driverseat, Highway, Freeway) to Dan and Jeroen. Driver reflects the NO and DDD heritage (does the software drive the business or the business drive the software, well hopefully both). In terms of marketing, in general the goal is to provide people with what they want or think they want (i.e. get a rabbit costume), they are out shopping, have money to spend (figuratively speaking), your advertising has worked, now you just have to convince them that what you are offering represents the best value amongst competiting alternatives. Good sales-persons can be creative with the truth to achieve this, but I don't think that is the approach to take here! The buyers will have some technical nouse, but "closing the sale" is still necessary, you have to get a decision to action. Again, I've suggested offering 1 day training courses as one way to do this, as help to "try-before-you-buy" (the videos that Dan does are good, but can be built upon further). Maybe Apache River (as in something that flows through a Valley), that might have been the original thought. was (Author: steve cameron): I like this discussion, to choose a name I suggest to forget about the technical side (e.g hexagon) for a bit and think of something that has more 'mojo', find a name with good association, even a made-up name (e.g Microsoft, Facebook). I've previously suggested Apache Driver (Driven, Driverseat, Highway, Freeway) to Dan and Jeroen. Driver reflects the NO and DDD heritage (does the software drive the business or the business drive the software, well hopefully both). In terms of marketing, in general the goal is to provide people with what they want or think they want (i.e. get a rabbit costume), they are out shopping, have money to spend (figuratively speaking), your advertising has worked, now you just have to convince them that what you are offering represents the best value amongst competiting alternatives. Good sales-persons can be creative with the truth to achieve this, but I don't think that is the approach to take here! The buyers will have some technical nouse, but "closing the sale" is still necessary, you have to get a decision to action. Again, I've suggested offering 1 day training courses as one way to do this, as help to "try-before-you buy" (the videos that Dan does are good, but can be built upon further). Maybe Apache River (as in something that flows through a Valley), that might have been the original thought. > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the syste
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15133166#comment-15133166 ] Ged edited comment on ISIS-1303 at 2/4/16 10:21 PM: !ApacheFarthing.jpg! was (Author: ged.by...@gmail.com): !ApacheFarthing.jpg|thumbnail! > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheFarthing.jpg, ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI (data/context/interactions). > - "clean" "pure" "essential" pojo programming model > - agile, lean > - breaking down barriers between IT and business > Of these, I think that hexagonal architecture looks the best fit; it is well > regarded as a concept among the "cognoscenti", but there are surprisingly no > open source frameworks out there (at least in the Java space) that position > themselves as being the natural choice. > Therefore, I think a name - and appropriate short tag line - based around > this idea of hexagonal architecture should be considered. > Candidate names: > - hex (might hit trademark issues) > - hexagon >
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15133166#comment-15133166 ] Ged edited comment on ISIS-1303 at 2/4/16 10:19 PM: !ApacheFarthing.jpg|thumbnail! was (Author: ged.by...@gmail.com): !ApacheFarthing.jpg! > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheFarthing.jpg, ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI (data/context/interactions). > - "clean" "pure" "essential" pojo programming model > - agile, lean > - breaking down barriers between IT and business > Of these, I think that hexagonal architecture looks the best fit; it is well > regarded as a concept among the "cognoscenti", but there are surprisingly no > open source frameworks out there (at least in the Java space) that position > themselves as being the natural choice. > Therefore, I think a name - and appropriate short tag line - based around > this idea of hexagonal architecture should be considered. > Candidate names: > - hex (might hit trademark issues) > - hexagon > - hexagn (delibera
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132189#comment-15132189 ] Richard Pawson edited comment on ISIS-1303 at 2/4/16 11:33 AM: --- Given that Isis was a (mutually agreed and beneficial) split off from Naked Objects, I wouldn't normally offer an opinion on this, but Dan invited me to, so ... In understand the desire not to base the name on DDD or 'naked objects', because neither has gained much popular traction (much to my disappointment). Personally, I have never really seen the big deal about the Hexagonal architecture, and, even aside from that, I just don't like the name 'hex' at all - perhaps because of its rather sinister meaning, as in 'put a hex on something' (meaning put a curse on it). I think that dropping Isis in favour of Hex* would be an odd move! One thing that I hope we all still agree on is the central idea of objects - real objects, with rich behaviours. I have long argued, in my PhD thesis and elsewhere, that Naked Objects, and hence Isis also, are a better reflection of the OO ideal than anything that has been done since the early '70s. So how about a name that reflects the commitment to objects in some way. This could be the some reference or play on something that historical that was very significant in OO e.g.: Stimula (for Simula) Norway (origin of OO) Park (as in Xerox Parc) LargeTalk (I'm sure I don't need to explain that one) or some important technical idea in OO: Reflect (I quite like this idea, as reflecting over the model is a key idea), or Reflector or some acronym with OO in it e.g. ROOT (Real Object Oriented Technology) ROOF (Framework) Finally, and unrelated, I always like classical names e.g. Prometheus (stole the fire from heaven and give it to mere mortals) Narcissus (reflection again) or if you want to be really ironical: Procrustes (the innkeeper who insisted that customers should fit his bedstead either by stretching them on a rack, or sawing their legs off. The original 'opinionated framework'?) Richard Pawson was (Author: rpawson): Given that Isis was a (mutually agreed and beneficial) split off from Naked Objects, I wouldn't normally offer and opinion on this, but Dan invited me to, so ... In understand the desire not to base the name on DDD or 'naked objects', because neither has gained much popular traction (much to my disappointment). Personally, I have never really seen the big deal about the Hexagonal architecture, and, even aside from that, I just don't like the name 'hex' at all - perhaps because of its rather sinister meaning, as in 'put a hex on something' (meaning put a curse on it). I think that dropping Isis in favour of Hex* would be an odd move! One thing that I hope we all still agree on is the central idea of objects - real objects, with rich behaviours. I have long argued, in my PhD thesis and elsewhere, that Naked Objects, and hence Isis also, are a better reflection of the OO ideal than anything that has been done since the early '70s. So how about a name that reflects the commitment to objects in some way. This could be the some reference or play on something that historical that was very significant in OO e.g.: Stimula (for Simula) Norway (origin of OO) Park (as in Xerox Parc) LargeTalk (I'm sure I don't need to explain that one) or some important technical idea in OO: Reflect (I quite like this idea, as reflecting over the model is a key idea), or Reflector or some acronym with OO in it e.g. ROOT (Real Object Oriented Technology) ROOF (Framework) Finally, and unrelated, I always like classical names e.g. Prometheus (stole the fire from heaven and give it to mere mortals) Narcissus (reflection again) or if you want to be really ironical: Procrustes (the innkeeper who insisted that customers should fit his bedstead either by stretching them on a rack, or sawing their legs off. The original 'opinionated framework'?) Richard Pawson > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15131926#comment-15131926 ] Dan Haywood edited comment on ISIS-1303 at 2/4/16 8:25 AM: --- All the comments so far have been great, really thoughtful and useful. >From reading them it occurs to me that focusing hexagonal architecture is >really an implementation detail; focusing instead on our principles and values >and USP might be better. The risk with the latter is that it can sometimes >get a little bit "motherhood and apple pie". One thing I realize I haven't >thought about sufficiently is figuring out what sort of audience we are >looking to immediately connect with - bluntly, techies or business folk. Anyway, Vladimir's last comment suggested one further possible strapline: "do the right thing". And for a name, another one that popped into my head (not sure if I like it or not) is "Apache Headroom". was (Author: danhaywood): So, Vladimir's comment suggests one possible strapline: "do the right thing". > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130587#comment-15130587 ] Cesar Lugo edited comment on ISIS-1303 at 2/3/16 9:57 PM: -- Hello. I agree that, from a marketing perspective, this is a very good initiative, Despite how elegant Isis might sound, the other Isis is making too much noise to you, and you need to be heard. I have been involved in a few professional marketing processes when marketing some of our products to US, Europe and Latin America, and the marketing experts pointed out more or less the following (in my own words, sorry about that): The name must be memorable (easy to remember). The name should quite simply represent the main properties (not features) of your product (no explanations needed, almost obvious) . The properties are the ones in the minds of your potential customers and actual customers. They also suggested we considered names coming from Latin roots. This helps when addressing non-English spoken people, mostly likely it will be the same or very similar word in many languages, at least Latin root languages. That said, let me share with you which ones I think might be your main competitors, direct or indirect, and their main property in my mind: - Spring Framework. (Comprehensive, de facto standard to many, mature / old?) - Spring Framework. (ups!) - Grails. (Fast) - OpenXava. (Faster) - Vaadin. (Elegant, Beautiful UI, for the Java-only guys) - Play. (Fast?) - Django?. (Yes Python, still a competitor, almost a de facto standard) - RoR? (Ruby on Rails) (Yes Ruby, still a competitor, de facto standard) - Cubicweb?. (Python, fast, semantic) Now, let me share with you the ones I think are the properties that really make a difference in your Framework, at least in my mind, and in the ones I could infer from the mailing list, success stories and quotes. Number 1: Faster development. Faster business results. (Fast implies lower cost in people´s minds, maybe) Number 2: Business oriented (the more business add ons you create the better for your product, IMHO, much more than the technical stuff, where you have done a great job so far). Number 3: Eases IT-business users communication (via prototyping, not paper, users don´t have imagination). Number 4, 5, 6, 7 Great support, nice documentation, and a lot more, but it does not matter: It´s hard to remember more than 2 or three things when you are new to something. I don´t want to suggest a name, Apache Speedy Gonzalez, the latest might be well known but doesn´t necessarily have the desired image or reputation (LOL, just kidding!). A slogan should be short and simple. Don´t you like things like Home Depot´s "More Saving, More Doing" or Walmart´s "Save Money. Live Better"? Something like "Prototype. Deliver. Fast!" or "Business. Results. Now." might work?. I hope that helps. Cesar. was (Author: cesar.l...@sisorg.com.mx): Hello. I agree that, from a marketing perspective, this is a very good initiative, Despite how elegant Isis might sound, the other Isis is making too much noise to you, and you need to be heard. I have been involved in a few professional marketing processes when marketing some of our products to US, Europe and Latin America, and the marketing experts pointed out more or less the following (in my own words, sorry about that): The name must be memorable (easy to remember). The name should quite simply represent the main properties (not features) of your product (no explanations needed, almost obvious) . The properties are the ones in the minds of your potential customers and actual customers. They also suggested we considered names coming from Latin roots. This helps when addressing non-English spoken people, mostly likely it will be the same or very similar word in many languages, at least Latin root languages. That said, let me share with you which ones I think might be your main competitors, direct or indirect, and their main property in my mind: - Spring Framework. (Comprehensive, de facto standard to many, mature / old?) - Spring Framework. (ups!) - Grails. (Fast) - OpenXava. (Faster) - Vaadin. (Elegant, Beautiful UI, for the Java-only guys) - Play. (Fast?) - Django?. (Yes Python, still a competitor, almost a de facto standard) - RoR? (Ruby on Rails) (Yes Ruby, still a competitor, de facto standard) - Cubicweb?. (Python, fast, semantic) Now, let me share with you the ones I think are the properties that really make a difference in your Framework, at least in my mind, and in the ones I could infer from the mailing list, success stories and quotes. Number 1: Faster development. Faster business results. (Fast implies lower cost in people´s minds, maybe) Number 2: Business oriented (the more business add ons you create the better for your product, IMHO, much more than the technical stuff, where you have do
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130231#comment-15130231 ] Ged edited comment on ISIS-1303 at 2/3/16 11:02 AM: Another potential name on this theme is Apache Gestalt, based on this slide from Shyman Sankar's TED Talk !ApacheGestalt.jpg! Gestalt means "an organized whole that is perceived as more than the sum of its parts." According to the equation the Analytic Capability is increased as the friction in human-computer interaction is reduced. Apache [Isis|Gestalt|...] reduces this friction. was (Author: ged.by...@gmail.com): Another potential name on this theme is Apache Gestalt, based on this slide from Shyman Sankar's TED Talk !ApacheGestalt.jpg! Gestalt means "an organized whole that is perceived as more than the sum of its parts." > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI (data/context/interactions). > - "clean" "pure" "essential" pojo programming model > - agile, lean > - breaking down bar
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130231#comment-15130231 ] Ged edited comment on ISIS-1303 at 2/3/16 10:59 AM: Another potential name on this theme is Apache Gestalt, based on this slide from Shyman Sankar's TED Talk !ApacheGestalt.jpg! Gestalt means "an organized whole that is perceived as more than the sum of its parts." was (Author: ged.by...@gmail.com): Another potential name on this theme is Apache Gestalt, based on this slide from Shyman Sankar's TED Talk !ApacheGestalt.gif! Gestalt means "an organized whole that is perceived as more than the sum of its parts." > Rename the project to better describe its values and purpose > > > Key: ISIS-1303 > URL: https://issues.apache.org/jira/browse/ISIS-1303 > Project: Isis > Issue Type: Wish >Affects Versions: 1.11.1 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: 1.13.0 > > Attachments: ApacheGestalt.jpg > > > In the past there have been a couple of discussions regarding renaming the > project, the reason generally cited being the potential embarrassment of > sharing a name with the jihadist militant group [1] currently prominent in > the headlines. After due discussion on the mailing lists the prevailing view > has been to retain our name: "we were here first". > Until now I've concurred with that view also... after all, I originally came > up with the name "Isis", originally based on the name of the Thames as it > flows through Oxford [2] (many of the original authors of the framework live > within Oxfordshire, UK). > Separately to that discussion, we have the issue of marketing. Originally we > marketed ourselves as a framework implementing the "naked objects" pattern > [3]; the original name of the framework (prior to Apache) was of course the > Naked Objects Framework. However, this pattern is either not well-known or > is misunderstood (only a low proportion of developers that encounter the idea > immediately "get it"). The crudity of the original user interfaces didn't > help. And the name also, of course, can cause embarrassment in some cultures. > Then, when domain-driven design [4] came along as a movement, that seemed an > obvious platform upon which to position the framework: we obviously share the > core belief that the domain is the most important bit of the system. However > - and I still find this surprising - despite attempts otherwise we haven't > really made too much of an impression in that community. The fact that the > DDD community got massively sidetracked for a while by the CQRS pattern is > perhaps part of it. I also often detect the view that DDD should imply not > using a framework. The irony of course is that in rejecting framework such > developers actually have to write more infrastructure code vs business domain > code. > Also, the fit is perhaps not all that good after all. In the DDD community I > don't see anyone talking about modules... one of the named patterns, and a > major focus of our framework, but missing from DDD talks. Instead they get > side-tracked talking only about aggregate roots or bounded contexts; all well > and good, but over-emphasised). > [Aside: Indeed, I raised the topic of modules with Eric Evans himself (in > person), and he agreed there was little emphasis. When I described our > framework's use of domain events to hook modules together (along with vetoing > behaviour we support) he admitted it was a new approach/pattern to him...] > Anyway, so DDD - which looked so promising - hasn't delivered. They might > come around to us one day, but it's probably time to define our own > individual space. Also, in the same way that everyone takes agile > development for granted as the "de facto", we ought to simply take DDD for > granted too... "of course you will be doing DDD, but are you doing it well?" > What we need to better market the framework is some other pattern or concept > or hook, and become known as the framework that best supports that idea. > There are several candidates: > - hexagonal architecture (also called ports and adapters, or the onion > architecture, and related to the clean architecture) > - don't repeat yourself principle > - aspect oriented programming (naked objects pattern is really the > recognition that UI presentation is a cross-cutting concern) > - the general concept of modularity > - DCI (data/context/interactions). > - "clean" "pure" "essential" pojo programming model > - agile, lean > - breaking down barriers between IT and business > Of these, I think that hexagonal architecture looks the best fit; it is well > regarded as a concept among the "cognoscenti", but there are s
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120 ] Ged edited comment on ISIS-1303 at 2/3/16 10:13 AM: My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a form of user interaction that maximizes the overall effectiveness of the users in fulfilling their broader responsibilities.* This means giving the users more control, for example over the order in which capabilities are invoked in order to achieve a goal. We should also design systems that allow users to become more expert as they learn, rather than constraining everyone to the lowest common denominator. | | http://www.nakedobjects.org/book/section7.html (emphais added) | So the Naked Objects approach is not about developing UIs faster or any type of architecture. Those are just enablers that helps us reach the goal of augmenting human activities. Augmenting the human activities that both develop and use software systems. Engelbart was the pioneer of using computers for human augmentation. His goal was the "boosting mankind’s capability for coping with complex, urgent problems". Reenskaug's forward to Pawson's thesis includes this quote: | By "augmenting human intellect" we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems. . . Increased capability in this respect is taken to mean a mixture of the following: more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex, speedier solutions, better solutions, and the possibility of finding solutions to problems that before seemed insoluble. | | http://www.dougengelbart.org/pubs/augment-3906.html | Engelbarts 'Mother of all Demos' is essential viewing: https://www.youtube.com/watch?v=yJDv-zdhzMY I believe that Apache Isis also suffers from being to ahead of it's time, as Engelbart was. Here's an interesting retrospect on how Engelbart came to see his career as a failure: http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/ I believe that this change of name should be taken as an opportunity to return to this goal of human augmentation as the central theme for the project, keeping alive the vision of Pawson and Engelbart. By focusing on allowing humans to do more by augmenting their capabilities rather than seeking to have humans do less by automating what they do. h1. Apache Engelbart * speedier solutions * better solutions * solutions to problems that were once insoluble Engelbart also helps us understand how DDD fits into all this, with his emphasis on comprehension: "more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex" I feel that DDD has lost it's way because the focus has been on the second half - the patterns for implementation. The real power of DDD is in the first half: Knowledge Crunching. The implementation patterns are just enablers for achieving better comprehension, progressively gaining more insight into complex domains. I would also recommend looking into Shyam Sankar https://www.ted.com/speakers/shyam_sankar If there is a problem with the Engelbart name, can I also suggest Apache Farthing. This is a play on Penny Farthing and Steve Jobs 'A Bicycle for the Mind.' Also, I think a Penny Farthing will make for a cool logo. was (Author: ged.by...@gmail.com): My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120 ] Ged edited comment on ISIS-1303 at 2/3/16 9:56 AM: --- My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a form of user interaction that maximizes the overall effectiveness of the users in fulfilling their broader responsibilities.* This means giving the users more control, for example over the order in which capabilities are invoked in order to achieve a goal. We should also design systems that allow users to become more expert as they learn, rather than constraining everyone to the lowest common denominator. | | http://www.nakedobjects.org/book/section7.html (emphais added) | So the Naked Objects approach is not about developing UIs faster or any type of architecture. Those are just enablers that helps us reach the goal of augmenting human activities. Augmenting the human activities that both develop and use software systems. Engelbart was the pioneer of using computers for human augmentation. His goal was the "boosting mankind’s capability for coping with complex, urgent problems". Reenskaug's forward to Pawson's thesis includes this quote: | By "augmenting human intellect" we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems. . . Increased capability in this respect is taken to mean a mixture of the following: more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex, speedier solutions, better solutions, and the possibility of finding solutions to problems that before seemed insoluble. | | http://www.dougengelbart.org/pubs/augment-3906.html | Engelbarts 'Mother of all Demos' is essential viewing: https://www.youtube.com/watch?v=yJDv-zdhzMY I believe that Apache Isis also suffers from being to ahead of it's time, as Engelbart was. Here's an interesting retrospect on how Engelbart came to see his career as a failure: http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/ I believe that this change of name should be taken as an opportunity to return to this goal of human augmentation as the central theme for the project, keeping alive the vision of Pawson and Engelbart. By focusing on allowing humans to do more by augmenting their capabilities rather than seeking to have humans do less by automating what they do. h1. Apache Engelbart * speedier solutions * better solutions * solutions to problems that were once insoluble Engelbart also helps us understand how DDD fits into all this, with his emphasis on comprehension: "more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex" I feel that DDD has lost it's way because the focus has been on the second half - the patterns for implementation. The real power of DDD is in the first half: Knowledge Crunching. The implementation patterns are just enablers for achieving better comprehension, progressively gaining more insight into complex domains. I would also recommend looking into Shyam Sankar https://www.ted.com/speakers/shyam_sankar was (Author: ged.by...@gmail.com): My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120 ] Ged edited comment on ISIS-1303 at 2/3/16 9:55 AM: --- My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a form of user interaction that maximizes the overall effectiveness of the users in fulfilling their broader responsibilities.* This means giving the users more control, for example over the order in which capabilities are invoked in order to achieve a goal. We should also design systems that allow users to become more expert as they learn, rather than constraining everyone to the lowest common denominator. | | http://www.nakedobjects.org/book/section7.html (emphais added) | So the Naked Objects approach is not about developing UIs faster or any type of architecture. Those are just enablers that helps us reach the goal of augmenting human activities. Augmenting the human activities that both develop and use software systems. Engelbart was the pioneer of using computers for human augmentation. His goal was the "boosting mankind’s capability for coping with complex, urgent problems". Reenskaug's forward to Pawson's thesis includes this quote: | By "augmenting human intellect" we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems. . . Increased capability in this respect is taken to mean a mixture of the following: more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex, speedier solutions, better solutions, and the possibility of finding solutions to problems that before seemed insoluble. | | http://www.dougengelbart.org/pubs/augment-3906.html | Engelbarts 'Mother of all Demos' is essential viewing: https://www.youtube.com/watch?v=yJDv-zdhzMY I believe that Apache Isis also suffers from being to ahead of it's time, as Engelbart was. Here's an interesting retrospect on how Engelbart came to see his career as a failure: http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/ I believe that this change of name should be taken as an opportunity to return this goal of human augmentation as the central theme for the project, keeping alive the vision of Pawson and Engelbart. By focusing on allowing humans to do more by augmenting their capabilities rather than seeking to have humans do less by automating what they do. h1. Apache Engelbart * speedier solutions * better solutions * solutions to problems that were once insoluble Engelbart also helps us understand how DDD fits into all this, with his emphasis on comprehension: "more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex" I feel that DDD has lost it's way because the focus has been on the second half - the patterns for implementation. The real power of DDD is in the first half: Knowledge Crunching. The implementation patterns are just enablers for achieving better comprehension, progressively gaining more insight into complex domains. I would also recommend looking into Shyam Sankar https://www.ted.com/speakers/shyam_sankar was (Author: ged.by...@gmail.com): My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a fo
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120 ] Ged edited comment on ISIS-1303 at 2/3/16 9:53 AM: --- My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a form of user interaction that maximizes the overall effectiveness of the users in fulfilling their broader responsibilities.* This means giving the users more control, for example over the order in which capabilities are invoked in order to achieve a goal. We should also design systems that allow users to become more expert as they learn, rather than constraining everyone to the lowest common denominator. | | http://www.nakedobjects.org/book/section7.html (emphais added) | So the Naked Objects approach is not about developing UIs faster or any type of architecture. Those are just enablers that helps us reach the goal of augmenting human activities. Augmenting the human activities that both develop and use software systems. Engelbart was the pioneer of using computers for human augmentation. His goal was the "boosting mankind’s capability for coping with complex, urgent problems". Reenskaug's forward to Pawson's thesis includes this quote: | By "augmenting human intellect" we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems. . . Increased capability in this respect is taken to mean a mixture of the following: more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex, speedier solutions, better solutions, and the possibility of finding solutions to problems that before seemed insoluble. | | http://www.dougengelbart.org/pubs/augment-3906.html | Engelbarts 'Mother of all Demos' is essential viewing: https://www.youtube.com/watch?v=yJDv-zdhzMY I believe that Apache Isis also suffers from being to ahead of it's time, as Engelbart was. Here's an interesting retrospect on how Engelbart came to see his career as a failure: http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/ I believe that this change of name should be taken as an opportunity to return this goal of human augmentation as the central theme for the project, keeping alive the vision of Pawson and Engelbart. By focusing on allowing humans to do more by augmenting their capabilities rather than seeking to have humans do less by automating what they do. h1. Apache Engelbart * speedier solutions * better solutions * solutions to problems that were once insoluble Engelbart also helps us understand how DDD fits into all this, with his emphasis on comprehension: "more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex" I feel that DDD has lost it's way because the focus has been on the second half - the patterns for implementation. The real power of DDD is in the first half: Knowledge Crunching. The implementation patterns are just enablers for achieving better comprehension, progressively gaining more insight into complex domains. I would also recommend looking into Shyam Sankar https://www.ted.com/speakers/shyam_sankar was (Author: ged.by...@gmail.com): My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a fo
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120 ] Ged edited comment on ISIS-1303 at 2/3/16 9:53 AM: --- My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a form of user interaction that maximizes the overall effectiveness of the users in fulfilling their broader responsibilities.* This means giving the users more control, for example over the order in which capabilities are invoked in order to achieve a goal. We should also design systems that allow users to become more expert as they learn, rather than constraining everyone to the lowest common denominator. | | http://www.nakedobjects.org/book/section7.html (emphais added) | So the Naked Objects approach is not about developing UIs faster or any type of architecture. Those are just enablers that helps us reach the goal of augmenting human activities. Augmenting the human activities that both develop and use software systems. Engelbart was the pioneer of using computers for human augmentation. His goal was the "boosting mankind’s capability for coping with complex, urgent problems". Reenskaug's forward to Pawson's thesis includes this quote: | By "augmenting human intellect" we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems. . . Increased capability in this respect is taken to mean a mixture of the following: more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex, speedier solutions, better solutions, and the possibility of finding solutions to problems that before seemed insoluble. | | http://www.dougengelbart.org/pubs/augment-3906.html | Engelbarts 'Mother of all Demos' is essential viewing: https://www.youtube.com/watch?v=yJDv-zdhzMY I believe that Apache Isis also suffers from being to ahead of it's time, as Engelbart was. Here's an interesting retrospect on how Engelbart came to see his career as a failure: http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/ I believe that this change of name should be taken as an opportunity to return this goal of human augmentation as the central theme for the project, keeping alive the vision of Pawson and Engelbart. By focusing on allowing humans to do more by augmenting their capabilities rather than seeking to have humans do less by automating what they do. h1. Apache Engelbart * speedier solutions * better solutions * solutions to problems that were once insoluble Engelbart also helps us understand how DDD fits into all this, with his emphasis on comprehension: "more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex" I feel that DDD has lost it's way because the focus has been on the second half - the patterns for implementation. The real power of DDD is in the first half: Knowledge Crunching. The implementation patterns are just enablers for achieving better comprehension, progressively gaining more insight into complex domains. I would also recommend looking into Shyam Sankar https://www.ted.com/speakers/shyam_sankar was (Author: ged.by...@gmail.com): My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a for
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120 ] Ged edited comment on ISIS-1303 at 2/3/16 9:45 AM: --- My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a form of user interaction that maximizes the overall effectiveness of the users in fulfilling their broader responsibilities.* This means giving the users more control, for example over the order in which capabilities are invoked in order to achieve a goal. We should also design systems that allow users to become more expert as they learn, rather than constraining everyone to the lowest common denominator. | | http://www.nakedobjects.org/book/section7.html (emphais added) | So the Naked Objects approach is not about developing UIs faster or any type of architecture. Those are just enablers that helps us reach the goal of augmenting human activities. Augmenting the human activities that both develop and use software systems. Engelbart was the pioneer of using computers for human augmentation. His goal was the "boosting mankind’s capability for coping with complex, urgent problems". Reenskaug's forward to Pawson's thesis includes this quote: | By "augmenting human intellect" we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems. . . Increased capability in this respect is taken to mean a mixture of the following: more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex, speedier solutions, better solutions, and the possibility of finding solutions to problems that before seemed insoluble. | | http://www.dougengelbart.org/pubs/augment-3906.html | Engelbarts 'Mother of all Demos' is essential viewing: https://www.youtube.com/watch?v=yJDv-zdhzMY I believe that Apache Isis also suffers from being to ahead of it's time, as Engelbart was. Here's an interesting retrospect on how Engelbart came to see his career as a failure: http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/ I believe that this change of name should be taken as an opportunity to return this goal of human augmentation as the central theme for the project, keeping alive the vision of Pawson and Engelbart. By focusing on allowing humans to do more by augmenting their capabilities rather than seeking to have humans do less by automating what they do. h1. Apache Engelbart * speedier solutions * better solutions * solutions to problems that were once insoluble I would also recommend looking into Shyam Sankar https://www.ted.com/speakers/shyam_sankar was (Author: ged.by...@gmail.com): My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a form of user interaction that maximizes the overall effectiveness of the users in fulfilling their broader responsibilities.* This means giving the users more control, for example over the order in which capabilities are invoked in order to achieve a goal. We should also design systems that allow users to become more expert as they learn, rather than constraining everyone to the lowest common denominator. | | http://www.nakedobjects.org/book/section7.html (emphais added) | So the Naked Objects approach is not about developing UIs faster or any type of architecture. Those are j
[jira] [Comment Edited] (ISIS-1303) Rename the project to better describe its values and purpose
[ https://issues.apache.org/jira/browse/ISIS-1303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15130120#comment-15130120 ] Ged edited comment on ISIS-1303 at 2/3/16 9:45 AM: --- My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical difference between Apache Isis and JHipster. * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a form of user interaction that maximizes the overall effectiveness of the users in fulfilling their broader responsibilities.* This means giving the users more control, for example over the order in which capabilities are invoked in order to achieve a goal. We should also design systems that allow users to become more expert as they learn, rather than constraining everyone to the lowest common denominator. | | http://www.nakedobjects.org/book/section7.html (emphais added) | So the Naked Objects approach is not about developing UIs faster or any type of architecture. Those are just enablers that helps us reach the goal of augmenting human activities. Augmenting the human activities that both develop and use software systems. Engelbart was the pioneer of using computers for human augmentation. His goal was the "boosting mankind’s capability for coping with complex, urgent problems". Reenskaug's forward to Pawson's thesis includes this quote: | By "augmenting human intellect" we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems. . . Increased capability in this respect is taken to mean a mixture of the following: more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex, speedier solutions, better solutions, and the possibility of finding solutions to problems that before seemed insoluble. | | http://www.dougengelbart.org/pubs/augment-3906.html | Engelbarts 'Mother of all Demos' is essential viewing: https://www.youtube.com/watch?v=yJDv-zdhzMY I believe that Apache Isis also suffers from being to ahead of it's time, as Engelbart was. Here's an interesting retrospect on how Engelbart came to see his career as a failure: http://www.zdnet.com/article/the-shocking-truth-about-silicon-valley-genius-doug-engelbart/ I believe that this change of name should be taken as an opportunity to return this goal of human augmentation as the central theme for the project, keeping alive the vision of Pawson and Engelbart. By focusing on allowing humans to do more by augmenting their capabilities rather than seeking to have humans to less by automating what they do. h1. Apache Engelbart * speedier solutions * better solutions * solutions to problems that were once insoluble I would also recommend looking into Shyam Sankar https://www.ted.com/speakers/shyam_sankar was (Author: ged.by...@gmail.com): My name suggestion: Apache Engelbart This is in tribute to computer pioneer Douglas Engelbart: https://en.wikipedia.org/wiki/Douglas_Engelbart Please let me explain why. I notice from the tonuge in cheek examples that you want to distinguish ISIS from the main competition: JHipster. Here is the critical different between JHipster and Apache Isis * Apache Isis is a framework for *AUGMENTATION* * jHipster is a framework for *AUTOMATION* If we return to the Isis' Naked Object roots and the principles that Richard Pawson set out in his thesis and book. When defining the Naked Object approach the second principle put the human in control: | Instead of pursuing optimal efficiency in the execution of each of a finite set of scripted tasks, design *a form of user interaction that maximizes the overall effectiveness of the users in fulfilling their broader responsibilities.* This means giving the users more control, for example over the order in which capabilities are invoked in order to achieve a goal. We should also design systems that allow users to become more expert as they learn, rather than constraining everyone to the lowest common denominator. | | http://www.nakedobjects.org/book/section7.html (emphais added) | So the Naked Objects approach is not about developing UIs faster or any type of architecture. Those are jus
