The reXume and GanttMagic web apps have been modified such that they can be configured to process a hardwired reXume file rather than only uploaded files.
My hand coded Interactive Resume web site ( http://rexume.dyndns.org/resume ) is being replaced with a new version based on the std. reXume and GanttMagic web apps ( http://rexume.dyndns.org/reXume/RBWrexume.html ) that also acts as a demonstration of using reXume for personal resume sites.
The WAR files are currently deployed on JRun 3.0 but have been tested on Tomcat 4.1 as well.
Saturday, November 29, 2003
Monday, October 6, 2003
Announcing RDDL file for GanttMagic XML Namespace...
There is a first major stab at publishing an RDDL file documenting the XML namespace I've defined for the GanttMagic XML input data. It is at http://www.polyglotinc.com/NS/GanttMagic/.
Soon (hopefully) there will be a similar one for the reXume data XML namespace [ http://www.polyglotinc.com/NS/reXume ].
Soon (hopefully) there will be a similar one for the reXume data XML namespace [ http://www.polyglotinc.com/NS/reXume ].
Sunday, September 21, 2003
How to Pick a Science Fair Experiment
Presented is a set of intuitive classroom assignments that lead students
to pick better quality science fair projects, and in the process, teaching
them the "Scientific Process" and how it is something that they already
intuitively know.
Students are often impeded with the notion that "thinking like a scientist"
is so different from the way they normally think that they don't know how
to proceed. The given approach starts students with intuitive activities
with which they are already familiar then shows them how to merely "fine tune"
their thinking rather than viewing science as "speaking a foreign language".
In a nutshell, I propose that choosing a topic for a science fair project
and designing its experiment properly are the equivalent to the intuitive
activities of making a list of “Whenever THIS then THAT” statements and then
choosing the best “bar bet” that can be constructed from the list.
One intuitively makes observations and constructs theories to explain them
whenever a “Whenever THIS then THAT” statement is made. One intuitively
evaluates the quality of a science experiment whenever one evaluates the
quality of a bet. I.E. the same things that make a good bet make good science.
Namely:
* - you think you know something about the world that the other guy
doesn’t know (otherwise he won’t take the bet if he knows it too)
* - you think you understand it well enough to explain it (otherwise it is
not a safe bet)
* - you think you can demonstrate a prediction about it (i.e. the bet itself)
in such a way that the outcome will be clear (otherwise there will be
an argument over who won the bet).
* - you have controlled the conditions of the demonstration (otherwise it
makes the outcome of the bet be affected by things you can’t predict).
* - someone else can perform the bet if need be (otherwise people will think
you’ve rigged the game).
-------------------
The Approach
-------------------
0) Preview the Scientific Process to students
a) observations about the world are made
b) theories are created that explain those observations
c) predictions are made from those theories
d) experiments to verify the predictions are made
e) the results of the experiments either confirm the
predictions and therefore the theory, or they don't,
in which case one goes back to (b) taking into account
the new observations made by this experiment.
0) Preview some factors that make “good science”
*) observations are new
*) observations are surprising
*) theories make predictions that can be tested
*) experiments produce results that are conclusive
*) experiments are repeatable by others
1) Observations and Theories
[Use the intuition students exhibit, to both make observations
and generate theories to explain them, whenever they use
sentences like "Whenever THIS then THAT".]
(a) Assignment 1: make a list of things you know/believe about the world
“Everyone make a list of things that they have noticed (or been told
or read) about the world.
(At least 5 things and extra credit for each extra item up to 20 items).
The items in the list should all be in one of the following forms:
* - Whenever THIS happens (or not),
then THAT seems to always happen (or not).
* - Whenever THIS situation exists (or not),
then THAT seems to always happen (or not).
Examples of form:
* - I've noticed that whenever I let go of something I'm holding,
it seems to always fall to the ground.
* - I've noticed that whenever I drop a rock in water,
it never floats.
* - I've noticed that whenever people are with their friends,
they are louder than when they are alone or with strangers.
* - I've been told that whenever plants get too much water,
they die.”
(b) follow up discussion to Assignment 1: review how students made both
observations *and* theories to explain them.
* - By putting beliefs (whether inspired by direct observation or
having been informed by others) into the form "when this then that",
it filtered out simple observations that had no theory attached.
E.G. "I noticed that the sky is usually blue" is an observation, but
there is no theory to explain it. In order to say "if A then B",
one had to already have enough of an idea about cause and effect to
make the statement, whether the statement itself was correct or not.
But people/students makes statements like this all the time and
therefore are producing theories whether they realized it or not.
2) Experiment Selection and Design
[Use the intuition students exhibit, to choose interesting science
experiments and to design them to produce a clear result, whenever
they use sentences like "I'll bet you!".]
(a) Assignment 2: make bets out of the theories
Part 1: Everyone take their list of observations, and for each one, make
a bet out of it.
Examples:
* - I'll bet you that if I let go of this ball,
it will fall to the floor.
* - I'll bet you that if I throw this rock in the water,
it won't float.
* - I'll bet you that if we measure the noise level of 3 friends
eating together in the lunchroom it will be louder than if we
measure 3 people eating together that don't know each other.
* - I'll bet you that if I give this houseplant way more water
than the gardening book says it should get, it will die.
Part 2: Take your list of bets and rate each one for the factors below.
Add these factors together to get the quality score for each bet.
For safety, add the practicality factor 3 times instead of once.
The higher the score, the better the quality.
* - How non-obvious is this? (i.e. will anyone take this bet?)
Rank from 1 to 10 where 10 is "nobody knows this but me"
and 1 is "everyone on the planet knows this"
* - How well do you understand your theory (i.e. how sure of
the bet are you?). Rank from 1 to 10 where 10 means "I'm
sure I'll win the bet" and 1 means "I'm just guessing
what will happen."
* - How practical is it? (i.e. is there a way to actually
make a bet out of this?) Rank from 1 to 10 where 10 means
"this is easy to perform" and 1 means "this will take
a UN resolution to actually do."
* - How obvious will the outcome be? (i.e. how obvious will
it be who won the bet?) Rank from 1 to 10 where 10 means
"obvious result" and 1 means "we'll be in an argument
all day over who won, was it fair, is it a do-over, etc."
Part 3: Make any changes you can to the description/design of each
bet to improve its quality score before settling on the final
quality score for each bet. Take the top 3 bets and rank
each for the following factors:
* - How well can I control things that might affect the result?
(i.e. will I lose the bet because of something I can't
predict or control?). Rank from 1 to 10 where 10 means
"nothing should foul up the works if I specify when/where/
how/etc" and 1 means "every time the air conditioner
comes on it blows down my house of cards".
What conditions can be added that will make it more of a
sure bet? After adding them, make a final rank for this
factor.
* - How well can I describe the procedure? (i.e. how easy will
it be for a 3rd party to perform the bet?) Rank from 1 to
10 where 10 means "even a trained monkey could do this
correctly" and 1 means "I'm the only one who can ever
make this work".
How can the procedure and description be simplified and
improved such that others can get the same results every
time? After making the improvements, make a final rank for
this factor.
Part 4: Add the factors from part 3 to those from part 2 for the top
3 bets and pick the one with the highest quality score as your
choice for an experiment.
to pick better quality science fair projects, and in the process, teaching
them the "Scientific Process" and how it is something that they already
intuitively know.
Students are often impeded with the notion that "thinking like a scientist"
is so different from the way they normally think that they don't know how
to proceed. The given approach starts students with intuitive activities
with which they are already familiar then shows them how to merely "fine tune"
their thinking rather than viewing science as "speaking a foreign language".
In a nutshell, I propose that choosing a topic for a science fair project
and designing its experiment properly are the equivalent to the intuitive
activities of making a list of “Whenever THIS then THAT” statements and then
choosing the best “bar bet” that can be constructed from the list.
One intuitively makes observations and constructs theories to explain them
whenever a “Whenever THIS then THAT” statement is made. One intuitively
evaluates the quality of a science experiment whenever one evaluates the
quality of a bet. I.E. the same things that make a good bet make good science.
Namely:
* - you think you know something about the world that the other guy
doesn’t know (otherwise he won’t take the bet if he knows it too)
* - you think you understand it well enough to explain it (otherwise it is
not a safe bet)
* - you think you can demonstrate a prediction about it (i.e. the bet itself)
in such a way that the outcome will be clear (otherwise there will be
an argument over who won the bet).
* - you have controlled the conditions of the demonstration (otherwise it
makes the outcome of the bet be affected by things you can’t predict).
* - someone else can perform the bet if need be (otherwise people will think
you’ve rigged the game).
-------------------
The Approach
-------------------
0) Preview the Scientific Process to students
a) observations about the world are made
b) theories are created that explain those observations
c) predictions are made from those theories
d) experiments to verify the predictions are made
e) the results of the experiments either confirm the
predictions and therefore the theory, or they don't,
in which case one goes back to (b) taking into account
the new observations made by this experiment.
0) Preview some factors that make “good science”
*) observations are new
*) observations are surprising
*) theories make predictions that can be tested
*) experiments produce results that are conclusive
*) experiments are repeatable by others
1) Observations and Theories
[Use the intuition students exhibit, to both make observations
and generate theories to explain them, whenever they use
sentences like "Whenever THIS then THAT".]
(a) Assignment 1: make a list of things you know/believe about the world
“Everyone make a list of things that they have noticed (or been told
or read) about the world.
(At least 5 things and extra credit for each extra item up to 20 items).
The items in the list should all be in one of the following forms:
* - Whenever THIS happens (or not),
then THAT seems to always happen (or not).
* - Whenever THIS situation exists (or not),
then THAT seems to always happen (or not).
Examples of form:
* - I've noticed that whenever I let go of something I'm holding,
it seems to always fall to the ground.
* - I've noticed that whenever I drop a rock in water,
it never floats.
* - I've noticed that whenever people are with their friends,
they are louder than when they are alone or with strangers.
* - I've been told that whenever plants get too much water,
they die.”
(b) follow up discussion to Assignment 1: review how students made both
observations *and* theories to explain them.
* - By putting beliefs (whether inspired by direct observation or
having been informed by others) into the form "when this then that",
it filtered out simple observations that had no theory attached.
E.G. "I noticed that the sky is usually blue" is an observation, but
there is no theory to explain it. In order to say "if A then B",
one had to already have enough of an idea about cause and effect to
make the statement, whether the statement itself was correct or not.
But people/students makes statements like this all the time and
therefore are producing theories whether they realized it or not.
2) Experiment Selection and Design
[Use the intuition students exhibit, to choose interesting science
experiments and to design them to produce a clear result, whenever
they use sentences like "I'll bet you!".]
(a) Assignment 2: make bets out of the theories
Part 1: Everyone take their list of observations, and for each one, make
a bet out of it.
Examples:
* - I'll bet you that if I let go of this ball,
it will fall to the floor.
* - I'll bet you that if I throw this rock in the water,
it won't float.
* - I'll bet you that if we measure the noise level of 3 friends
eating together in the lunchroom it will be louder than if we
measure 3 people eating together that don't know each other.
* - I'll bet you that if I give this houseplant way more water
than the gardening book says it should get, it will die.
Part 2: Take your list of bets and rate each one for the factors below.
Add these factors together to get the quality score for each bet.
For safety, add the practicality factor 3 times instead of once.
The higher the score, the better the quality.
* - How non-obvious is this? (i.e. will anyone take this bet?)
Rank from 1 to 10 where 10 is "nobody knows this but me"
and 1 is "everyone on the planet knows this"
* - How well do you understand your theory (i.e. how sure of
the bet are you?). Rank from 1 to 10 where 10 means "I'm
sure I'll win the bet" and 1 means "I'm just guessing
what will happen."
* - How practical is it? (i.e. is there a way to actually
make a bet out of this?) Rank from 1 to 10 where 10 means
"this is easy to perform" and 1 means "this will take
a UN resolution to actually do."
* - How obvious will the outcome be? (i.e. how obvious will
it be who won the bet?) Rank from 1 to 10 where 10 means
"obvious result" and 1 means "we'll be in an argument
all day over who won, was it fair, is it a do-over, etc."
Part 3: Make any changes you can to the description/design of each
bet to improve its quality score before settling on the final
quality score for each bet. Take the top 3 bets and rank
each for the following factors:
* - How well can I control things that might affect the result?
(i.e. will I lose the bet because of something I can't
predict or control?). Rank from 1 to 10 where 10 means
"nothing should foul up the works if I specify when/where/
how/etc" and 1 means "every time the air conditioner
comes on it blows down my house of cards".
What conditions can be added that will make it more of a
sure bet? After adding them, make a final rank for this
factor.
* - How well can I describe the procedure? (i.e. how easy will
it be for a 3rd party to perform the bet?) Rank from 1 to
10 where 10 means "even a trained monkey could do this
correctly" and 1 means "I'm the only one who can ever
make this work".
How can the procedure and description be simplified and
improved such that others can get the same results every
time? After making the improvements, make a final rank for
this factor.
Part 4: Add the factors from part 3 to those from part 2 for the top
3 bets and pick the one with the highest quality score as your
choice for an experiment.
Monday, September 15, 2003
The GanttMagic webapp works separately from reXume now....
The multiple web app WAR files previously published for GanttMagic have been consolidated into a single GanttMagic.war which can be deployed on any web container and has been tested with Tomcat 4.1 (J2EE 1.3) and JRun3.0 (J2EE 1.2). For older J2EE web containers running on JDK 1.3, you may need
to install the following library jar file into the shared library area (e.g. for JRun3.0 it is at [jrun_install]/lib/ext/ ).
Also with this release, this GanttMagic webapp may be deployed and used separately from the new release of the reXume webapp. Previously the two had to be deployed within a single webapp to work properly.
This code is running and available online at http://rexume.dyndns.org/GanttMagic/
where is runs on my old Pentium II system with RedHat6.x and JRun3 (so don't expect lightning speed).
The demo installation is still found at this test page.
to install the following library jar file into the shared library area (e.g. for JRun3.0 it is at [jrun_install]/lib/ext/ ).
Also with this release, this GanttMagic webapp may be deployed and used separately from the new release of the reXume webapp. Previously the two had to be deployed within a single webapp to work properly.
This code is running and available online at http://rexume.dyndns.org/GanttMagic/
where is runs on my old Pentium II system with RedHat6.x and JRun3 (so don't expect lightning speed).
The demo installation is still found at this test page.
The reXume webapp works separately from GanttMagic now....
The multiple web app WAR files previously published for reXume have been consolidated into a single reXume.war which can be deployed on any web container and has been tested with Tomcat 4.1 (J2EE 1.3) and JRun3.0 (J2EE 1.2).
Also with this release, this reXume webapp may be deployed and used separately from the new release of the GanttMagic webapp. Previously the two had to be deployed within a single webapp to work properly.
This code is running and available online at http://polyglotinc.dyndns.org/reXume/ where is runs on my old Pentium II system with RedHat6.x and JRun3 (so don't expect lightning speed).
The demo installation is found at this interactive resume page.
Also with this release, this reXume webapp may be deployed and used separately from the new release of the GanttMagic webapp. Previously the two had to be deployed within a single webapp to work properly.
This code is running and available online at http://polyglotinc.dyndns.org/reXume/ where is runs on my old Pentium II system with RedHat6.x and JRun3 (so don't expect lightning speed).
The demo installation is found at this interactive resume page.
Monday, September 8, 2003
Things I learned today while fighting the MSBlaster worm...
(1) what looks like normal problems with Charter cable modem
service being flaky can actually be caused by MSBLASTER.
(1.5) It is hard to diagnose anything over Charter these days
because they have disabled all ICMP (i.e. ping/traceroute)
messages in a vain attempt to fight viruses. Earthlink
happily does not block ICMP so you can dial out to Mindspring
to ping Charter boxes.
(2) I found that one of my Win2K systems was infected by seeing
"msblast.exe" in the Task Manager display.
(3) searching Yahoo I found a good page about the blaster worm
which told me how to fix it and had a link to the patch
to prevent getting it in the future.
(4) while I normally am immune to these problems because of
my firewall, it didnt take long for the worm to find and
infect me while I was dialed into Mindspring/Earthlink
which puts my computer directly on the Internet (only the
cable modem goes thru the router/firewall [Netgear RP614]).
(4.5) I see that when I dial directly to the net via Earthlink,
I am constantly SMURF attacked which doesn't happen when
behind the firewall when connecting via the cable modem.
(4.6) Even though the Netgear router lets you set up a static
IP address but still set it to "ask for DNS server addresses",
it doesnt work (at least with Charter) which makes sense
since DHCP which gives you a dynamic IP address, also gives
you the DNS addresses and if you dont ask for one, you wont
get the other either.
(5) searching my Linux box's various logs to see what all that
network activity was about, I saw in the Apache logs (which
I never look at) that there were lots of failed requests
via the web for "default.ida" which is the symptom of other boxes
with the Code Red virus trying to attack me. Good little
discussion of it here.
(6) Just because you see the Norton AntiVirus running its auto-
update feature every day or so to update its virus definitions,
that doesn't mean it is scanning for viruses too. That is
scheduled separately (and it hadn't scanned my system since
the last time I did it manually about 8 months ago.)
service being flaky can actually be caused by MSBLASTER.
(1.5) It is hard to diagnose anything over Charter these days
because they have disabled all ICMP (i.e. ping/traceroute)
messages in a vain attempt to fight viruses. Earthlink
happily does not block ICMP so you can dial out to Mindspring
to ping Charter boxes.
(2) I found that one of my Win2K systems was infected by seeing
"msblast.exe" in the Task Manager display.
(3) searching Yahoo I found a good page about the blaster worm
which told me how to fix it and had a link to the patch
to prevent getting it in the future.
(4) while I normally am immune to these problems because of
my firewall, it didnt take long for the worm to find and
infect me while I was dialed into Mindspring/Earthlink
which puts my computer directly on the Internet (only the
cable modem goes thru the router/firewall [Netgear RP614]).
(4.5) I see that when I dial directly to the net via Earthlink,
I am constantly SMURF attacked which doesn't happen when
behind the firewall when connecting via the cable modem.
(4.6) Even though the Netgear router lets you set up a static
IP address but still set it to "ask for DNS server addresses",
it doesnt work (at least with Charter) which makes sense
since DHCP which gives you a dynamic IP address, also gives
you the DNS addresses and if you dont ask for one, you wont
get the other either.
(5) searching my Linux box's various logs to see what all that
network activity was about, I saw in the Apache logs (which
I never look at) that there were lots of failed requests
via the web for "default.ida" which is the symptom of other boxes
with the Code Red virus trying to attack me. Good little
discussion of it here.
(6) Just because you see the Norton AntiVirus running its auto-
update feature every day or so to update its virus definitions,
that doesn't mean it is scanning for viruses too. That is
scheduled separately (and it hadn't scanned my system since
the last time I did it manually about 8 months ago.)
Thursday, September 4, 2003
Announcing GanttMagic from PolyGlot, Inc....
I've finally gotten around to making my Gantt chart software available to others as either a product or an open-source-project (haven't decided which yet).
As with the reXume project (which uses GanttMagic to produce the "experience charts"), there is lots of web-accessible documentation to still to produce and the code published today is a first baby step.
GanttMagic produces a gantt chart (often misspelled as "gannt") given data in the GanttMagic XML format. (Here is the small example data file that the test program mentioned below uses.)
It currently can produce the chart image in SVG, JPG, and PNG formats.
It is implemented in Java using the Apache Batik SVG library.
I have broken out and cleaned up my GanttMagic code and packaged it into a JavaBean that includes all of the basic functionality, a standalone application to use the bean via a command line, and a J2EE web application to make the functionality available from any JSP/Servlet engine.
I have produced the following three varieties of WAR file for loading into the appropriate J2EE servers. [Tested on Tomcat and JRun]
1) GanttMagic3.war - tested on Tomcat3.3 and JRun3.0 (both J2EE 1.2 compliant)
2) GanttMagic40.war - tested on Tomcat4.0 (J2EE 1.3 compliant)
3) GanttMagic41.war - tested on Tomcat4.1 (J2EE 1.3 compliant)
This code is running and available online at http://rexume.dyndns.org/GanttMagic/
where is runs on my old Pentium II system with RedHat6.x and JRun3 (so don't expect lightning speed).
I'll add documentation soon, but for now, try using the test page to experiment with. Choose which type of image you want (SVG,JPG,PNG) and hit the "show me" button. The other controls are not interesting for now. JPG is the most universal format. To see the SVG, you'll need either a standalone viewer or a browser plugin. I've heard new IE browsers may already have an SVG plugin installed. Otherwise follow the links to install an SVG viewer browser plug-in to see the raw SVG rendered. Without an SVG viewer, you can see the raw SVG source which is just an XML text file.
As with the reXume project (which uses GanttMagic to produce the "experience charts"), there is lots of web-accessible documentation to still to produce and the code published today is a first baby step.
GanttMagic produces a gantt chart (often misspelled as "gannt") given data in the GanttMagic XML format. (Here is the small example data file that the test program mentioned below uses.)
It currently can produce the chart image in SVG, JPG, and PNG formats.
It is implemented in Java using the Apache Batik SVG library.
I have broken out and cleaned up my GanttMagic code and packaged it into a JavaBean that includes all of the basic functionality, a standalone application to use the bean via a command line, and a J2EE web application to make the functionality available from any JSP/Servlet engine.
I have produced the following three varieties of WAR file for loading into the appropriate J2EE servers. [Tested on Tomcat and JRun]
1) GanttMagic3.war - tested on Tomcat3.3 and JRun3.0 (both J2EE 1.2 compliant)
2) GanttMagic40.war - tested on Tomcat4.0 (J2EE 1.3 compliant)
3) GanttMagic41.war - tested on Tomcat4.1 (J2EE 1.3 compliant)
This code is running and available online at http://rexume.dyndns.org/GanttMagic/
where is runs on my old Pentium II system with RedHat6.x and JRun3 (so don't expect lightning speed).
I'll add documentation soon, but for now, try using the test page to experiment with. Choose which type of image you want (SVG,JPG,PNG) and hit the "show me" button. The other controls are not interesting for now. JPG is the most universal format. To see the SVG, you'll need either a standalone viewer or a browser plugin. I've heard new IE browsers may already have an SVG plugin installed. Otherwise follow the links to install an SVG viewer browser plug-in to see the raw SVG rendered. Without an SVG viewer, you can see the raw SVG source which is just an XML text file.
Friday, August 29, 2003
announcing reXume from PolyGlot, Inc....
I've finally gotten around to making my interactive resume available to others and I grabbed a couple of domain names to lock in the product/open-source-project (haven't decided which yet) name: "reXume" (pronounced "resume" following a trend to replace 's' with 'x' in names and to be a reference to the XML nature of the product).
So, peruse www.rexume.org or www.rexume.net and see the one and only page so far. It lets one upload one's resume in my reXume XML format, and then it returns it back to you all pretty formatted and filtered a la my interactive resume.
Somebody in Hong Kong already has rexume.com but they haven't even hooked up a "parked" web page for it. I grabbed the name because a google search showed virtually zero hits for it which makes it a great brand name.
I'll add documentation soon, but for now, try uploading my rexume file to experiment with.
BTW, I got the domain names including free forwarding from goDaddy for ~$8/yr per name.
So, peruse www.rexume.org or www.rexume.net and see the one and only page so far. It lets one upload one's resume in my reXume XML format, and then it returns it back to you all pretty formatted and filtered a la my interactive resume.
Somebody in Hong Kong already has rexume.com but they haven't even hooked up a "parked" web page for it. I grabbed the name because a google search showed virtually zero hits for it which makes it a great brand name.
I'll add documentation soon, but for now, try uploading my rexume file to experiment with.
BTW, I got the domain names including free forwarding from goDaddy for ~$8/yr per name.
Tuesday, February 25, 2003
Navigation missing from MVC paradigm?
After playing with Struts and seeing its notion of what Model-View-Controller means (versus traditional "fat client" MVC), I think that MVC needs to add an explicit model for Navigation. A so-called NMVC design pattern.
In traditional MVC, Views are individual pages/dialog-boxes/panes/etc. and Controllers are geared towards translating (mouse/keyboard/clock) events into transaction requests against some data Model.
The large item left out is the universal need to define Navigation between views using controllers that are geared towards "movement" i.e. transactions against a Navigation model. In other words, a data model specifically geared towards user interface control is needed that is separate from the data models managing "business/domain/application data".
Since UI navigation (especially in a web site context) usually maps well onto a finite state machine, a navigation model geared towards FSMs (with the definition of the state-transition graph specified in an external config-file maybe?) would take out some of the grunt work of UIs.
Can Psychology help Framework Designs?
There is a continuum of component sets (i.e. frameworks) that range between "simple" sets containing fewer more universal components versus "complex" sets containing more specialized components. For example, compare old school Lego pieces that were generic shapes that built anything, versus new style Legos that build only one particular type of Jedi Starfighter.
These frameworks tend to not integrate very well with other frameworks. It is simpler to pick one as a standard, but how does it affect those that prefer the one not picked? What is the overall cost/benefit of picking one vs the other [vs not picking one at all, and doing the more complicated work of supporting both]?
It would be interesting to perform a series of psych experiments to determine whether people have clear preferences between simple vs complex component sets and how well they can adapt to their non-preferred choice. Also, do the choices change based on time pressure, organization, documentation of the sets, appropriateness of the components to the overall goal?
For example...
*) - Ask people to build a "plane" from the provided components.
Let people pick between a simple vs complex set of components (e.g. specialized legos vs generic tinkertoys). Measure time taken, and "quality" of result (both self evaluation and objective third party evaluation), and "how well they liked it" i.e. "how fun was it" i.e. "would they like to do another one". Compare the success and quality rates overall for simple vs complex when used by those preferring each.
1) variation: mixed pile of components
2) variation: pile of mixed simple and separate pile of mixed complex
3) variation: organized piles
4) variation: various time limits
5) variation: make complex parts clearly "plane related"
6) variation: make complex parts clearly unrelated to overall goal
*) - Ask people to build another goal object, but require them to use the opposite of their preference in the first test. Compare measurements to those of when using their preferred components. Use similar variations to above (especially for various time limits). Compare the success/quality rates of simple vs complex overall when used by those not preferring it.
Overall goals: determine whether:
1) success rate is significantly different between simple vs complex
2) quality rate is significantly different between simple vs complex
3) time taken is significantly different between simple vs complex
4) do people have strong preferences vs weak (what is the distribution each)
5) are people more able to use either simple or complex better when it is not preferred
*) i.e. can one pick simple vs complex as a standard or must both be avail and integrated with each other??
Another variation to try is having the simple and complex component sets be compatible with each other (as opposed to the previous example of special-legos/tinkertoys that can not be used together). E.G. generic legos vs specialized legos. Goal: see if the choices made between simple/complex are as strong and the effects of the choices as strong when there is less of a consequence to starting with one set or the other.
Also, add variations to previous experiments that vary the size of the "simple" set and the "complex" set and see what the size boundaries are to these categories. See what the performance curve is when graphed against set size for the various categories of people.
Sunday, February 23, 2003
Abstract Unit Tests
I WANT TO UNIT TEST Requirements, Specifications, Use Cases, etc, and not just fully coded Implementations!
I believe that there needs to be a language that allows sufficiently abstract logic to be specified/programmed such that tests can be written against use cases, high level specifications, etc that are very general. An example of a high level use case might be "customer can get account balance from the ATM".
In other words, I'd like to write, compile, and lock away in a test suite, a test that verifies that if joeBlow has $10 in his account, the result he gets from requesting his balance is $10, even though no user interface, extra details like logging in first, etc have been decided.
Then later refinements of the system details can be "plugged in" such that the test can still run without being rewritten. Traditionally, tests must be written at a level of detail that is very specific such that it can interact with the actual system being tested, user interface screens, UI testing tools, etc.
On the other hand, "high level tests" have traditionally been written as high level test plans in (possibly structured) English; just as the use case descriptions themselves were in English. A language is needed that can capture this logic (in either spec or test-case form) that is precise enough to be "compilable", and have a robust enough notion of "interfaces" that future detailed implementations can be passed at test runtime as "implementors of those abstract interfaces".
E.G. If test cases can take the system-being-tested itself as an explicit parameter (even though the system is normally the ultimate of implicit parameters), that explicit parameter's type is an abstract interface, and the system-being-tested is defined as implementing that interface. [Ed. note: the rest of the world will later get this idea and call it dependency-injection!]
The abstract interfaces must be able to be associated with the more specific interfaces that make up the various levels of abstraction that are captured as the system design is fleshed out.
So, at the very high level (described in the use case above), the interface provides a simple "get balance" request that returns a "number". Eventually, the actual system has a whole sequence of interaction required to login, navigate to account, request balance, receive formatted display, logout which is encapsulated in a test case defined at that level of abstraction but which none the less can "implement" the getBalance() interface and return the dollar formatted amount as a "number". So, the specific test case implementation "subclasses" the abstract test case implementation.
QUESTION: when (i.e. at what level of abstraction) does the "interface" analogy get replaced by the "subclass" analogy?
ANSWER: silly rabbit, each level of abstraction is really a framework that defines interfaces for the more detailed level(s) to implement, and defines "subclasses" to implement the interfaces defined by the framework(s) of the higher level(s) of abstraction. [Ed. note: don't confuse frameworks with implementation-via-subclassing. They can use other mechanisms than subclassing to override generic default behavior with specific behavior.]
Tuesday, February 4, 2003
Musing on Events
"Events" are a subclass of "Data" where there is one required attribute, namely, a time-stamp. Arbitrary amounts of other data may be included in an Event but they all have a time-stamp.
The canonical use of Events is for them to act as a trigger for some action to occur. They secondarily may be logged for audit/replay/etc. Many systems do not care what the actual time-stamps are, but only that they are sorted in chronological order.
Examples of events are; keystrokes, message receipt, mouseclick, etc.
Since the only requirement for an event is that it has a time-stamp, the clock itself can generate events that consist of nothing more than the time-stamp.
"Actors" are generators of events. Having a "thread of control" means "being able to generate events" rather than only being able to react to events.
Since events only need time, people often overlook the fact that a "clock" can be an "actor" and therefore the source of events in a system.
Objects are usually described as containing both behavior and state. State is data. Behavior is a sequence of events. Control flow is the proscription of how to decide which events are to be generated. So, if objects can be modelled as state change diagrams, the states represent the possible instances of the object data, and the events represent the arcs that trigger a change from one state to another.
Programs represent a planned source of events, and "external actors" represent an unplanned (i.e. unpredictable) source of events.
Subscribe to:
Posts (Atom)
