Re: MVC Architecture and transactions

Yes, there is no excuse for that. Bugs happen; they slip into the code, but
once you are made aware of them, you must fix them. To do otherwise is not
acceptable.

DFU should be *persona non grata* for the users. You might as well give out
the password to QSECOFR.

Everyone here is a limited user (except fpr an emergency profile which is
audited and requires approval to activate). Nobody can do anything outside
of menu options.

As for testing, we either peer test before it goes to production, or a
QC-only person tries to "break" the application.


On 8/22/07, Ron Power <RPower@xxxxxxxxxx> wrote:

I don't normally get into debates, but I have to put in my two cents for
what it's worth based on the comment:
"I won't try to make excuses for soft code, but I will say that time
constraints placed on projects significantly limit the developer's ability
to "harden" their applications. These common pressures result in immature
code that is prone to failure. (This is, of course, an issue for
management to address...)"
If I as a developer allowed code to be put in place that allowed failure,
I'd have my a$$ handed to me by my fellow developers, not to mention
management. I for one cannot, for any reason, see any excuse for an
application that is not buttoned down completely. Time constraints or
otherwise, I think it is foolhardy to release an application that is not
ready. It is better to be late and have a solid product, than to be on
time with a buggy one. How many of us have complained about Microswift
and there buggy code. And as far as time constraints go... that is the
fault of either the PM or the developer for either not giving themselves a
proper timeline, or allowing the project scope to be changed too much
without adding extra time. I don't buy the whole "we didn't have time to
test it" bit. Thus, if the application is developed correctly, you
shouldn't have issues with the data. Now the only way the data can be
messed up is through another source, such as directly accessing it.
So, what Joe says is correct, if you can't control the data going in and
coming out of the database, and have security around the database setup so
that end users can't DFU data, then the database is doomed. If you let
users DFU the data, or delete or insert records that cannot be verified
thru the application, then you are doomed to have application issues when
the data is extracted and used.

Of course, this is only my opinion....

Ron Power
Programmer
Information Services
City Of St. John's, NL
P.O. Box 908
St. John's, NL
A1C 5M2
709-576-8132
rpower@xxxxxxxxxx
http://www.stjohns.ca/

___________________________________________________________________________
Success is going from failure to failure without a loss of enthusiasm. -
Sir Winston Churchill
Freedom is the right of all sentient beings. - Optimus Prime



"DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
2007/08/22 12:11 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the AS400 / iSeries" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: MVC Architecture and transactions






Wow, what a statement!

"This I don't buy. If you have people doing "unexpected" things to your
database that could cause transactions to fail, then you have completely
lost control of your database. And at that point, no amount of commitment
control will save you; it will in fact be a false sense of security."

Really Joe, you need to get out in the real world more often... People
doing unexpected things to the database is unfortunately a common
occurance, at least in MY experience. These issues have only increased as
more transactions are distributed across the networks. I won't try to
make excuses for soft code, but I will say that time constraints placed on
projects significantly limit the developer's ability to "harden" their
applications. These common pressures result in immature code that is
prone to failure. (This is, of course, an issue for management to
address...)

We've all heard the old mantra "if it ain't broke, then don't fix it"....
As always, the real trouble comes from how you interpret "broke". The
code might be a shambles of two dozen different contractors over the last
ten years, but if it somehow makes its way through its processes without
puking its guts out, then "it ain't broke". Of course, this leads to
"unexpected" things happening to the database.....

Sorry,
Eric



--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.







This email communication and accompanying documents is intended only for
the individual or entity to which it is addressed and may contain
information that is confidential, privileged or exempt from disclosure under
applicable law. Any use of this information by individuals or entities other
than the intended recipient is strictly prohibited. If you have received
this in error, please notify the sender and delete all the copies
(electronic or otherwise) immediately.
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.