Comments on: Scared of annotation hell http://almaer.com/blog/scared-of-annotation-hell blogging about life, the universe, and everything tech Sat, 08 Sep 2012 07:06:53 -0700 http://wordpress.org/?v=2.8.4 hourly 1 By: James Strachan http://almaer.com/blog/scared-of-annotation-hell/comment-page-1#comment-4350 James Strachan Mon, 05 Jul 2004 05:30:35 +0000 http://almaer.com/blog2/scared-of-annotation-hell#comment-4350 I agree... http://radio.weblogs.com/0112098/2004/05/15.html#a481 its time for lightweight annotations :) I agree…

http://radio.weblogs.com/0112098/2004/05/15.html#a481

its time for lightweight annotations :)

]]> By: Scott Stirling http://almaer.com/blog/scared-of-annotation-hell/comment-page-1#comment-4349 Scott Stirling Sat, 03 Jul 2004 00:03:45 +0000 http://almaer.com/blog2/scared-of-annotation-hell#comment-4349 I disagree with the first user about the stability of d.b. schemas. Sounds good in theory, but in practice we use views in Oracle, which allow a great deal of flexibility above the schema. Most of our app code queries views because it allow DBAs to write views that enable simpler queries than querying the underlying tables. As for the underlying schema, it too evolves in response to requirements, and we have upgrade procedures for rolling out schema changes to clients. I agree with Dion's point that annotations, like aspects, will inevitably require standards, patterns, conventions and idioms. And developers will need to be disciplined in their use of this stuff so as not to write unmaintainable, unintelligible code. Speaking of fashionable technology, I have personally been lukewarm to bringing in aspects to one of our (workscape.com) larger projects because of the total lack of attention the strongest advocates have paid to the impact that aspects will have on all our developers' IDEs, source code organization, build scripts, coding standards, etc. Not doubt I will probably be one of the first to use aspects on my job, in part because I happen to be partly or mostly responsible for a bunch of those concerns, so I will have to resolve them as part of the decision. Another thing I've noticed is that the most eager, zealous advocates of using aspects or annotations bring them up as ad hoc solutions to minor problems and don't have them in mind as solutions for architectural or systematic problems. You need discipline and you need to see the bigger picture. Again, I would say code and project maintenance and intelligibility are the two biggest areas where business users of these technologies need to be careful (of course, if you're just hacking away on Sourceforge or something, go nuts!). Some folks believe IDEs will solve these problems for us, and they will some, but not all (particularly not the source code and build management parts). I disagree with the first user about the stability of d.b. schemas. Sounds good in theory, but in practice we use views in Oracle, which allow a great deal of flexibility above the schema. Most of our app code queries views because it allow DBAs to write views that enable simpler queries than querying the underlying tables. As for the underlying schema, it too evolves in response to requirements, and we have upgrade procedures for rolling out schema changes to clients.

I agree with Dion’s point that annotations, like aspects, will inevitably require standards, patterns, conventions and idioms. And developers will need to be disciplined in their use of this stuff so as not to write unmaintainable, unintelligible code.

Speaking of fashionable technology, I have personally been lukewarm to bringing in aspects to one of our (workscape.com) larger projects because of the total lack of attention the strongest advocates have paid to the impact that aspects will have on all our developers’ IDEs, source code organization, build scripts, coding standards, etc. Not doubt I will probably be one of the first to use aspects on my job, in part because I happen to be partly or mostly responsible for a bunch of those concerns, so I will have to resolve them as part of the decision.

Another thing I’ve noticed is that the most eager, zealous advocates of using aspects or annotations bring them up as ad hoc solutions to minor problems and don’t have them in mind as solutions for architectural or systematic problems. You need discipline and you need to see the bigger picture. Again, I would say code and project maintenance and intelligibility are the two biggest areas where business users of these technologies need to be careful (of course, if you’re just hacking away on Sourceforge or something, go nuts!). Some folks believe IDEs will solve these problems for us, and they will some, but not all (particularly not the source code and build management parts).

]]>