[x3d-public] We are VERY successful!

John Carlson yottzumm at gmail.com
Thu Dec 30 06:20:54 PST 2021


Summary:  Start at # 21.

1.  I believe in creating test cases and testing early, even during 
development.   This is often called "Unit Testing"

2. The way X3D in the past has been to create or receive a example file 
and have users test it with a provided validator. This unappealing to 
users who don't want to learn a software development tool (like 
designers), who used to be X3D's main users.

3.  X3D created a validator test pages.

4.  Most people do not want to create bad pages.  The earlier the errors 
are caught, the best, money-wise. The more instantaneous the better.

5.  Typical testing on old style apps was done after development 
finished.  This was the waterfall model

6. No one want wants to read reams and reams of error statements, either 
in email or in IDEs.

7.   All my test reports should be considered "In development" as I an 
pulling items from sourceforge and not official web pages.

8.  Most organizations have a formal test process and tools.

9.  I do not test released products. I do not do releases nor do I 
receive released builds. You might call my position DevTest, or 
Developer in Test.

10. Don diffs his build logs to determine regressions.  I do not have a 
permanent checked in build log yet.  I diff result examples, and try to 
figure out what went went wrong.   Thus, I test products, and Don tests 
processes.  Probably we have good coverage between the two of us.

11. Everyone wants to look at "cool stuff."   Everyone wants to build 
cool stuff.

12.  X3DJSAIL and x3d.py work on the plumbing of X3D.

13.  I want to work on cool stuff in the plumbing of X3D.   This is 
called software visualization AFAIK, or software analytics. Software 
reports. One has to collect data from the reports.

14. The purpose of X3D is to build a standard, not great software.   We 
are not really a software organization, more of a standards 
organization, so we're more along the lines of a verification and 
validation organization for the standards. People pay us to make sure 
their browsers and authoring tools are compliant.

15.  I do not know how X3D got into the conversions market. Probably by 
building nice looking HTML pages with annotated examples.

16.  Our validators are insufficient (plus they require clicking a 
button or going to  web site), so we're converting our schema into 
source code artifacts in Java, which show errors in X3D-Edit.   So code 
artifacts are good for people who use IDEs. Eclipse keeps a nice real 
time table of errors. (I don't recall what IntelliJ uses).

17.   IDEs are insufficient if errors cannot be captured and reported 
on.   Maven and Ant are also used for error collection. Don uses Ant.

18.  I use an adhoc collection of tools for error collection.

19. People do not feel comfortable seeing lots of errors.  At my last 
company, they purposefully disabled my error collection maven plugin.

20. I go around collecting all the "bad" files into X3DJSONLD. That's 
4.5% of our examples.

21. We have a stunning 95.5% success rate. Maybe even more than that 
with Savage Defense.  We may be even higher than that because most of 
the examples have been fixed.

22. That's an A in schools.

23.  We strive for perfection, whereas most commercial companies are 
striving for money.

24.  If you were in school and got a 95.5% on your test, Would you be 
happy or sad?

25.  Did you like your teacher because your teacher gave you a good 
grade, or because your teacher pointed out areas where you needed to 
improve?




More information about the x3d-public mailing list