Re: OFF TOPIC: Introduction

[Dale Newfield]

On Dec 5, 2019, at 8:58 PM, Zahid Rahman  wrote:
> 
> I dislike the concept of Javadoc for same reason that documents are
> generated from the code which flies in the face of best software
> development practice as I understand it.

Are well written javadoc on a Java Interface a reasonable compromise?

-Dale

-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org

Re: OFF TOPIC: Introduction

[Zahid Rahman]

The code had already undergone two tests.
1. Electrical Rig tests.
2. Physical Rig Tests.
Which showed the code meets the  customer requirements.

The unit test step was the third step . Unit tests are written by
independent  developers. But not by looking at the procedure parameters and
return values from code.

But from the specification document where the algorithms  were detailed for
each procedure and each variable.

That is to say detailed documents on code. Before code.

The unit tests are to make sure the developer followed the documents.

I think the problem here on this email line is that detailed documents of
code before code is written is a challenging concept to grasp. This is also
is known as best practice.

Underlying my point that programmers want to dive into code. Then later
they get unstuck.

I dislike the concept of Javadoc for same reason that documents are
generated from the code which flies in the face of best software
development practice as I understand it.







On Thu, 5 Dec 2019, 22:00 Martin Gainty,  wrote:

> DOB correct
>
> if the dev isnt willing to verify their code works with at least one unit
> test then whats the point of development?
>
> dave did you see the case of the pacemaker's recording of heart electrical
> activity solved a homicide in Australia?
>
> https://www.smh.com.au/national/pacemakers-electrical-memory-that-foiled-a-murderers-alibi-in-court-20030120-gdg4uz.html
>
> best regards
> m.
>
> 
> From: Dave Newton 
> Sent: Tuesday, December 3, 2019 11:31 AM
> To: Struts Users Mailing List 
> Subject: Re: OFF TOPIC: Introduction
>
> On Tue, Dec 3, 2019 at 9:43 AM Zahid Rahman  wrote:
>
> > If the developer  tests his own code then there is a danger that he will
> > pass his misunderstanding of specification.
> >
>
> Correct.
>
>
> > Anyway in the safety critical environments the one who wrote the code
> does
> > not do the testing.
> >
>
> That's simply not the case across the board: there are multiple tiers of
> testing, and the onus is on the developer to do the initial testing.
>
> For example, when I was writing pacemakers--you better believe we tested
> the *crap* out of our code. Were we the *only* ones testing? Of course not;
> there were *many* levels of testing--but it *started* with us.
>
>
> > Tests are also done on hardware electrical rigs ,  simulating feed to
> > sensors.
> >
>
> Yep. And when I was writing fuel pump controllers not only did *I* have a
> set of tests, so did the hardware guys, so did the combination of HW/SW
> guys, so did the verification group, so did whoever gave us our
> certification, etc.
>
> It's not entirely clear to me what your point is, or if you're just arguing
> for the sake of arguing.
>
> Testing is, by necessity, the responsibility of everyone involved in the
> project, which includes the developer.
>
> d.
>

Re: OFF TOPIC: Introduction

[Martin Gainty]

DOB correct

if the dev isnt willing to verify their code works with at least one unit test 
then whats the point of development?

dave did you see the case of the pacemaker's recording of heart electrical 
activity solved a homicide in Australia?
https://www.smh.com.au/national/pacemakers-electrical-memory-that-foiled-a-murderers-alibi-in-court-20030120-gdg4uz.html

best regards
m.


From: Dave Newton 
Sent: Tuesday, December 3, 2019 11:31 AM
To: Struts Users Mailing List 
Subject: Re: OFF TOPIC: Introduction

On Tue, Dec 3, 2019 at 9:43 AM Zahid Rahman  wrote:

> If the developer  tests his own code then there is a danger that he will
> pass his misunderstanding of specification.
>

Correct.


> Anyway in the safety critical environments the one who wrote the code does
> not do the testing.
>

That's simply not the case across the board: there are multiple tiers of
testing, and the onus is on the developer to do the initial testing.

For example, when I was writing pacemakers--you better believe we tested
the *crap* out of our code. Were we the *only* ones testing? Of course not;
there were *many* levels of testing--but it *started* with us.


> Tests are also done on hardware electrical rigs ,  simulating feed to
> sensors.
>

Yep. And when I was writing fuel pump controllers not only did *I* have a
set of tests, so did the hardware guys, so did the combination of HW/SW
guys, so did the verification group, so did whoever gave us our
certification, etc.

It's not entirely clear to me what your point is, or if you're just arguing
for the sake of arguing.

Testing is, by necessity, the responsibility of everyone involved in the
project, which includes the developer.

d.

convention plugin Issue

[Zahid Rahman]

Hi,

On this page
https://struts.apache.org/plugins/convention/#setup

if I have  com.example.actions.HelloWorld.java
and
uk.mypackage.actions.HelloWorld.java
with  url http://localhost:8080/hello-world
then
uk.mypackage.actions.HelloWorld.java  execute is run.

If I have
uk.example.actions.HelloWorld.java
and
com.example.actions.HelloWorld.java
then  com.example.actions.HelloWorld.java  execute is run.

uk.mypackage.actions.HelloWorld,java overrides the other two.

Re: Black Box Tesing v White Box Testing

[Zahid Rahman]

Hi,

> "None of us are resistant to new ideas or ways of looking at
things"
  Happy LEARNING

  https://www.robotshop.com/uk/37-modules-sensor-kit-arduino.html
https://www.raspberrypi.org/
https://beagleboard.org/bone




On Wed, 4 Dec 2019 at 14:11, Dave Newton  wrote:

> On Wed, Dec 4, 2019 at 07:56 Zahid Rahman  wrote:
>
> > The space and defence don't share what they are doing.  So I don't think
> > yours is reasonable  statement that you know what is happening  in the
> > aerospace  and defence industry.
>
>
> Hm. I don't think your assumption that I haven't done defense contracting
> is a reasonable one, but we'll agree to disagree on that one. (If you're
> wondering, encrypted radio systems, and consulting on guidance systems. And
> I still know the people I worked with--and people that use the systems or
> their descendents.)
>
> FWIW: you're going to find people with a pretty wide background in this
> group, many with decades of experience across a full spectrum of domains.
> Speaking for myself, I come from both embedded and application development
> going on 30+ years now. I know others here have similar time in the
> trenches. None of us are resistant to new ideas or ways of looking at
> things--but we have an appreciation for factual claims and accurate
> representations.
>
> Anyway you jumped to a conclusion of reverse engineering  when I was
> > referring to the benefit of traceability when using interpretive code.
>
>
> I "jumped" to reverse engineering because you specifically said an
> advantage of Java was decompilation (not unique to Java), and that's a
> primary component of reverse engineering almost by definition.
>
> d.
> --
> em: davelnew...@gmail.com
> mo: 908-380-8699
> tw: @dave_newton 
> li: dave-newton 
> gh: davelnewton 
> so: Dave Newton 
> bl[0]: Bucky Bits 
> bl[1]: Maker's End Blog 
> sk: davelnewton_skype
>

Re: Black Box Tesing v White Box Testing

[Zahid Rahman]

On one occasion I had to make use of external procedure (dynamic link
library (DLL)) on a database.

The Oracle  documents showed,Oracle database provides two ways of
interacting with host operating system.
PL/SQL which can create and write files to disk or a developer can create
dll (in C or other 3rd generation language).

There were code example in the documents  showing how to use PL/SQL for one
way interaction with OS , but no example showing C dll interface code .Any
way I decided to give it go nonetheless.

The first problem was every time I tried to install the C/C++ IDE. It would
crash with an incomprehensible error message  i.e. ("OX56F...).

Then I asked myself how did the IDE vendor compile the ide on that
operating.

I asked my internal support staff for any patches for available. It was a
fully licenced environment, so he had a CD delivered with the patches. I
loaded the patches and the IDE installed with out any issues.

Then the DLL wouldn't produce the expected results.

I contacted Oracle  support because we had a support contract.  The
Database Vendor support said we don't support it on that operating system.
Hmmm...

So it would appear the reason there was no sample code in the documents is
because the database vendor couldn't  install the IDE.














On Wed, 4 Dec 2019, 14:11 Dave Newton,  wrote:

> On Wed, Dec 4, 2019 at 07:56 Zahid Rahman  wrote:
>
> > The space and defence don't share what they are doing.  So I don't think
> > yours is reasonable  statement that you know what is happening  in the
> > aerospace  and defence industry.
>
>
> Hm. I don't think your assumption that I haven't done defense contracting
> is a reasonable one, but we'll agree to disagree on that one. (If you're
> wondering, encrypted radio systems, and consulting on guidance systems. And
> I still know the people I worked with--and people that use the systems or
> their descendents.)
>
> FWIW: you're going to find people with a pretty wide background in this
> group, many with decades of experience across a full spectrum of domains.
> Speaking for myself, I come from both embedded and application development
> going on 30+ years now. I know others here have similar time in the
> trenches. None of us are resistant to new ideas or ways of looking at
> things--but we have an appreciation for factual claims and accurate
> representations.
>
> Anyway you jumped to a conclusion of reverse engineering  when I was
> > referring to the benefit of traceability when using interpretive code.
>
>
> I "jumped" to reverse engineering because you specifically said an
> advantage of Java was decompilation (not unique to Java), and that's a
> primary component of reverse engineering almost by definition.
>
> d.
> --
> em: davelnew...@gmail.com
> mo: 908-380-8699
> tw: @dave_newton 
> li: dave-newton 
> gh: davelnewton 
> so: Dave Newton 
> bl[0]: Bucky Bits 
> bl[1]: Maker's End Blog 
> sk: davelnewton_skype
>