[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