jquery vs dojo vs yui etc

[David Mark]

[...]

An example of this is seen in the opening lines to Sencha:

| window.undefined = window.undefined;

Yes, I can't believe that breakthrough "HTML5 framework" opened with
that old groaner.

Another is in dojo:
dojo.isArray = function(it) {
   return it&&(it instanceof Array||typeof it=="array");

};

Is that *still* there?! If so, there is truly no hope for them.
IIRC, I explained to one James Burke that it was gobbledygook (and why
that was the case) and he asked me to show him a browser where it
"fails".

If the only justification for a line of code is that it appears to get
the right result, then that line of code has no place in a production
system. You've got to have at least some semblance of an idea of
*why* it should be expected to work.

For very good reason, programming has never been about mindless
observation. Rather it is about understanding abstractions. Testing
programs does involve observation, but only to confirm that there were
no misunderstandings. And in this business, a thousand positive test
results do not mean the code will work everywhere. That's where
experience and a knowledge of history come into play.

The authors of Ext-js and dojo may have more experience than I do.

No, they are mostly Ajax-era greenhorns. Have you seen ExtJS? Er,
Ext-js. Or was it Ext JS? Whatever. Maybe the name change wasn't
such a bad idea after all (other than breaking a million Google search
results of course).

What
does that say when they continue to publish code that shows a lack of
knowledge?

That they are ignorant. No news there. The usual "excuse" is that
they don't have time to learn. You've got to wonder why so many
developers are keen to use their scripts. Oh wait... We are talking
about Dojo and ExtJS after all. Of course, jQuery is just as
mystically silly and, inexplicably, Prototype was once popular. Then
there's MooTools...

Somebody asked me recently whether there was any framework I *do*
like. They asked in a nice enough way, but I could sense their
implication that I was a serial doubter. Of course, I asked them "a
framework for what?" The answer was: well, something like Dojo or YUI
or jQuery... In other words, something that makes outrageous false
claims about making browser scripting accessible to the masses.

Code may be obscurely written, have an unrecognized flaw that applies
exclusively to the situation (perhaps only in an uncommon case), provide
a workaround to something irrelevant, contain misleading or obsolete
comments, be mostly irrelevant, and can be full of bugs that exist in
code paths that are untested but never reached. The same code may also
fulfill the requirements.

Hence, "show me where it fails" is the rallying cry for incompetent JS
developers. Show them anything but the latest versions of three or
four major desktop browsers (in their default configurations) and they
assert that they don't "care" about those cases. Of course, it's
insanity to project the cares of deluded Web developers onto the
general public (who just want working documents).

The author is of such code may be overlooking important considerations
of code quality including clarity, efficiency, extensibility, etc.

....competence, sanity, etc.

Sufficient criteria for the assessment of front end skill has not been
formally established. You, I, and Cornford all have seem to have
expressed that to some degree.

Then there are things like Dojo. I think most can agree that it does
not demonstrate skill on the part of its developers. Delusions yes,
proficiency no.

A precursor to making assessments of front end skill is the ability to
make assessments of the quality of front end code.

That much is clear.

For that, I have been
working on the code guidelines document.

<http://jibbering.com/faq/notes/code-guidelines/>

I think I skimmed it at some point.

This document can be improved and I would like more feedback on it.

One thing that I have wanted to change is the "Avoid modifying objects
you don't own. ". While that is a nice trite phrase, it doesn't cover
the aspects of defining cohesive objects.

I think it gets the point across. It's very easy to by accident (or
in haste).

"Define cohesive objects" is better but that does not imply that doing
the opposite is wrong.

In contrast, I don't know what that means; so the first one is
definitely better.

"Avoid interdependencies" is better

But something else altogether.

and expounding on host object in
that section is still appropriate, however some interdependencies make
sense, so I can't say I'm satisfied with that, either.

Well, you can't satisfy everybody.

 

[Garrett Smith]

What makes anyone think that F1 is Help? Or that "you can add this link
to your favorites (sic) by typing ctrl-d" or whatever it is? The former
applies to nothing on my computer and the latter to only one out of five
browsers I have.

Well, sure, F1 might not be help, ctrl + D might not be a bookmark,
backspace might perform scrolling, navigation, or nothing at all.

Those things depends on the app. The point I was trying to make, and
what Richard's popup feedback survey example showed, was that such
features may not be as well tested as the rest of the application.

Additionally help is often a failed user experience. When the user gets
to that point, it can often be considered a problem. User usually does
not want to launch help. Help takes time to launch and use. Even if it
is only 10 seconds, that is still a lot of time for the user. Help also
changes context and focus of what he was doing and might not even have
the answer for what he's trying to get done.

Things such as as "help" or "surveys" tend to be not as well-tested.
They are sometimes irrelevant and may be an indication that the
application developers are out of touch.

This is generally the case with foreseeresults, which opens windows in
popups (that can fail), asks questions that are irrelevant (if the user
ever sees them) using marketing lingo. They rely on cookies to determine
if the customer has been provided with the survey and since that can
fail, the user can get the same survey again and again.

Any company that uses foreseeresults is clearly out and using
foreseeresults won't help change that.

Sorry if that was too long-winded. In short, F1 could be anything and
web surveys and help are usually indicators of a company that is out of
touch with the user.

 

[Kenneth Tilton]

Yep and it does indeed. Avoid like the plague.

I agree. And we would be in de facto agreement over JS libraries were it
not for qooxdoo (and possibly the proprietary library I gather qooxdoo
was modelled after). Most JS libraries are bad beyond salvation by
bugfix. But engineering is like that: eventually someone gets it right.

One thing they got right is hiding HTML/CSS so a new generation of
developers need not mess with those. ie, The library is not an
additional learning curve, it replaces several.

Until I see a widget set like qooxdoo's and other things like the
messaging mechanism and their databinding mechanism and their
sophisticated layout API in some raw HTML/CSS library, I'll be using
qooxdoo.

And I am an NIH kinda developer, preferring to roll my own rather than
sort through someone else's mess in the time I could develop my own.

kt

 

[David Mark]

I agree. And we would be in de facto agreement over JS libraries were it
not for qooxdoo (and possibly the proprietary library I gather qooxdoo
was modelled after).

And it is likely not a coincidence that you have hitched your wagon to
qooxdoo's star. Perhaps you have a special place in your psyche for
that one?

http://en.wikipedia.org/wiki/Cognitive_dissonance

Most JS libraries are bad beyond salvation by
bugfix.

That's 100% correct. Most developers realize that trying to solve
every problem for every conceivable context is the wrong approach.
Scripts must be downloaded, JS is single-threaded, etc. Logic says
that context-specific scripts are needed to make non-trivial scripts
download and execute fast enough. Furthermore, solving every problem
for every *browser* is virtually impossible, so it is necessary to
design around some problems, which you can't do if the stated goal is
to tackle everything at once.

So it follows that working on such projects is left to inexperienced
and/or hopelessly deluded developers who clearly have no shot at
making such omnipotent designs a reality. They carry on year after
year, giving up on last year's browsers and redirecting their efforts
to the latest in a never-ending quest to do the impossible. They are
cheered on by have-nots (typically non-programmers or fellow
greenhorns) who desperately want to develop cross-browser scripts, but
require a magical solution to handle every conceivable cross-browser
issue for them. Inevitably, with time and experience, rational
developers realize that the "anti-library zealots" were right all
along.

But engineering is like that: eventually someone gets it right.

You don't seem to understand the basic concept, which is that the
library authors are chasing an ill-advised and untenable goal. You
can never get a wrong design right.

And seeing as IE6 came out around the turn of the century, it is not
2010 and none of the "major" efforts (presumably with armies of
developers behind them) haven't gotten close to getting that browser
"right". Same for IE7. The inevitable "solution" is for them to
throw in the towel (which many are now advocating). Doesn't that tell
you something?

Furthemore, the major browsers (the only ones these efforts seek to
"fix") have been converging for years (recently and most dramatically
illustrated by the preview of IE 9) further reducing the need for
monolithic libraries to "smooth over" the ever-decreasing differences.

As for widget frameworks, they are invariably built atop incompetently-
written libraries, so can be dismissed out of hand. And as HTML5
creeps in to the picture, they will become increasingly less
attractive (who needs a qooxdoo date picker if the browser has one
built-in?)

Predictably there are already "HTML5 frameworks" popping up, even
before the recommendation is finalized. And predictably they are
taking the usual approach of ignoring built-in degradation mechanisms
(which they can't can and brand) in favor of dubious hacks (e.g.
browser sniffing).

One thing they got right is hiding HTML/CSS so a new generation of
developers need not mess with those.

As you've been told repeatedly, "hiding" HTML/CSS means short-
circuiting built-in browser behavior (e.g. layout) and then trying to
rebuild it all with (single-threaded) scripts. That's obviously
folly.

One pervasive example is the "CSS reset" which wipes out default
styles and then tries to build an "ideal" set that will be appropriate
for every agent. That clearly makes no sense as default styles are
chosen by browser developers to suit specific environments (e.g.
desktop, phone, tablet).

Another much-maligned practice is sizing everything with pixel units,
which breaks accessibility. For example, the text zooming feature in
IE breaks completely. The framework developers know this, but
typically argue that the user should simply use the general zoom
feature and stop getting in the way of their quest to control every
aspect of the browser. Of course, zooming *everything* causes
horizontal scroll bars, which futher impairs readability.

In reality, they are simply trying to compensate for their ill-advised
GP scripts which are predictably overwhelmed by the diversity of
browsers. Then there is the antiquated notion that every document
must look exactly the same in every browser (when in fact the goal
should be to leverage each agent as best as possible without breaking
accessibility).

Also, qooxdoo does not have a monopoly on such ill-advised and
overbearing strategies (see ExtJS, Cappuccino, etc.) The authors of
these scripts just don't get it. Either that or they refuse to get it
as that would get in the way of book sales.

ie, The library is not an
additional learning curve, it replaces several.

It certainly is an additional learning curve and it (sort of) replaces
many built-in and standard features that you could have gotten for
free with dubious and ever-shifting scripts that cost dearly in terms
of performance and usability. In short you are learning the wrong
things.

Until I see a widget set like qooxdoo's and other things like the
messaging mechanism and their databinding mechanism and their
sophisticated layout API in some raw HTML/CSS library, I'll be using
qooxdoo.

The widgets are slow, bloated, over-engineered junk and nothing you
are writing needs the overkill of messaging and data-binding
mechanisms. As for the "sophisticated" layout API, it is demonstrably
less sophisticated (and far less useful) than the built-in mechanisms
it aspires to replace. And these pipe dreams come at a price that is
prohibitive (as evidenced by your recent "train wreck" example).

And I am an NIH kinda developer, preferring to roll my own rather than
sort through someone else's mess in the time I could develop my own.

In the time you've spent sorting through qooxdoo (with no end in
sight), you could have learned how to leverge the browser's built-in
layout engine, XHR, etc. to create your algebra application in
something far less than 1MB. Also, unlike qooxdoo, those represent
marketable skills.

 

[Kenneth Tilton]

And it is likely not a coincidence that you have hitched your wagon to
qooxdoo's star. Perhaps you have a special place in your psyche for
that one?

http://en.wikipedia.org/wiki/Cognitive_dissonance


That's 100% correct. Most developers realize that trying to solve
every problem for every conceivable context is the wrong approach.

See straw. See man. See straw man.

Scripts must be downloaded, JS is single-threaded, etc. Logic says
that context-specific scripts are needed to make non-trivial scripts
download and execute fast enough. Furthermore, solving every problem
for every *browser* is virtually impossible, so it is necessary to
design around some problems, which you can't do if the stated goal is
to tackle everything at once.

So it follows that working on such projects is left to inexperienced
and/or hopelessly deluded developers who clearly have no shot at
making such omnipotent designs a reality. They carry on year after
year, giving up on last year's browsers and redirecting their efforts
to the latest in a never-ending quest to do the impossible. They are
cheered on by have-nots (typically non-programmers or fellow
greenhorns) who desperately want to develop cross-browser scripts, but
require a magical solution to handle every conceivable cross-browser
issue for them. Inevitably, with time and experience, rational
developers realize that the "anti-library zealots" were right all
along.


You don't seem to understand the basic concept, which is that the
library authors are chasing an ill-advised and untenable goal. You
can never get a wrong design right.

Nonsense. You think you can work around browser variability, ergo anyone
can. QED. If you think you are so blessed by the hand of G*d that no one
else can achieve what you have, then that includes me so if you don't
mind I'll get to work with these mortals over here.

And seeing as IE6 came out around the turn of the century, it is not
2010 and none of the "major" efforts (presumably with armies of
developers behind them) haven't gotten close to getting that browser
"right". Same for IE7. The inevitable "solution" is for them to
throw in the towel (which many are now advocating). Doesn't that tell
you something?

Furthemore, the major browsers (the only ones these efforts seek to
"fix") have been converging for years (recently and most dramatically
illustrated by the preview of IE 9) further reducing the need for
monolithic libraries to "smooth over" the ever-decreasing differences.

I am sorry, but you are being dense: I want to work on this:

http://teamalgebra.com/

Not "how to program the web". Do you have one spare neuron to get that?

As for widget frameworks, they are invariably built atop incompetently-
written libraries, so can be dismissed out of hand.

You keep making things up to defend your disappearing employability, and
I'll keep responding: I have dug into their code to understand and/or
fix stuff. It is quite solid (and I almost never like OP code.)

In case you are wondering, yes, I am a better programmer than you: I
know because I do not make things up to generate work.

And as HTML5
creeps in to the picture, they will become increasingly less
attractive (who needs a qooxdoo date picker if the browser has one
built-in?)

Predictably there are already "HTML5 frameworks" popping up, even
before the recommendation is finalized. And predictably they are
taking the usual approach of ignoring built-in degradation mechanisms
(which they can't can and brand) in favor of dubious hacks (e.g.
browser sniffing).


As you've been told repeatedly, "hiding" HTML/CSS means short-
circuiting built-in browser behavior (e.g. layout) and then trying to
rebuild it all with (single-threaded) scripts. That's obviously
folly.

It works great. I know that kills you, but we should draw the truth into
this thread at some point.

One pervasive example is the "CSS reset" which wipes out default
styles and then tries to build an "ideal" set that will be appropriate
for every agent. That clearly makes no sense as default styles are
chosen by browser developers to suit specific environments (e.g.
desktop, phone, tablet).

Another much-maligned practice is sizing everything with pixel units,
which breaks accessibility. For example, the text zooming feature in
IE breaks completely. The framework developers know this, but
typically argue that the user should simply use the general zoom
feature and stop getting in the way of their quest to control every
aspect of the browser. Of course, zooming *everything* causes
horizontal scroll bars, which futher impairs readability.

In reality, they are simply trying to compensate for their ill-advised
GP scripts which are predictably overwhelmed by the diversity of
browsers. Then there is the antiquated notion that every document
must look exactly the same in every browser (when in fact the goal
should be to leverage each agent as best as possible without breaking
accessibility).

Also, qooxdoo does not have a monopoly on such ill-advised and
overbearing strategies (see ExtJS, Cappuccino, etc.) The authors of
these scripts just don't get it. Either that or they refuse to get it
as that would get in the way of book sales.


It certainly is an additional learning curve and it (sort of) replaces
many built-in and standard features that you could have gotten for
free with dubious and ever-shifting scripts that cost dearly in terms
of performance and usability. In short you are learning the wrong
things.

What on earth makes you think I was not messing with raw HTML/CSS before
trying JS libraries? I have seen the enemy, and it is not me.

The widgets are slow, bloated, over-engineered junk and nothing you
are writing needs the overkill of messaging and data-binding
mechanisms.

Just keep saying that. Bush got us into Iraq with that approach, so you
have a good shot.

As for the "sophisticated" layout API, it is demonstrably
less sophisticated (and far less useful) than the built-in mechanisms
it aspires to replace.

Oh, I see you have never used them.

And these pipe dreams come at a price that is
prohibitive (as evidenced by your recent "train wreck" example).

It's kinda sad when someone of your supposed intellect and expertise
tries a cheap shot like that. A moment of silence for your self-respect.

In the time you've spent sorting through qooxdoo (with no end in
sight), you could have learned how to leverge the browser's built-in
layout engine, XHR, etc. to create your algebra application in
something far less than 1MB. Also, unlike qooxdoo, those represent
marketable skills.

I am not a web application developer, I am changing the way kids
experience Algebra: http://teamalgebra.com/

ie, You just don't get it, or you do not want to: you want to obsess all
day over MTML/CSS/browser variability. Good for you! But if you want the
attention of us working on higher-order problems, you have to produce
something that competes with qooxdoo.

But I think you know that by now. I sure hope you know that by now.

kt

 

[David Mark]

See straw. See man. See straw man.

See the loveli lakes.

Nonsense. You think you can work around browser variability, ergo anyone
can. QED.

Certainly I can better than most (as should be evident by now). As
for *anyone*, in the context of a general-purpose do-everything
framework, I'm going to have to disagree. As evidence, we have
roughly five years of jQuery, Prototype, Dojo, etc. and not one of
them has come close to "solving" IE6, which predates their existence
by about five years. Do the math. And I'm not talking about obscure
bugs and minor mistakes, but well-known issues and blunders so obvious
they practically jump off the screen.

If you think you are so blessed by the hand of G*d that no one
else can achieve what you have, then that includes me so if you don't
mind I'll get to work with these mortals over here.

The wonderful telephone system.

I am sorry, but you are being dense: I want to work on this:

     http://teamalgebra.com/

Then work on it. But don't blame me when your chosen monolith
explodes. I warned you (as did many others).

Not "how to program the web". Do you have one spare neuron to get that?

A moose once bit my sister...

<sigh>




You keep making things up to defend your disappearing employability, and
I'll keep responding: I have dug into their code to understand and/or
fix stuff. It is quite solid (and I almost never like OP code.)

More like you keep making things up to prop up your disappearing self-
image. And the more deluded clods out there the better. Eventually
omebody has to clean up their messes.

In case you are wondering, yes, I am a better programmer than you: I
know because I do not make things up to generate work.

Mynd you, moose bites Kan be pretti nasti...

It works great. I know that kills you, but we should draw the truth into
this thread at some point.

"It works great" is a bit vague for a technical discussion. And
coming from the engineer of one of the worst train wrecks ever
reported...

What on earth makes you think I was not messing with raw HTML/CSS before
trying JS libraries? I have seen the enemy, and it is not me.

Again with the "raw HTML" reference. What does that even mean? And
I'm sure you were messing up HTML/CSS long before you started messing
up JS. Is that supposed to be a defense?

Just keep saying that. Bush got us into Iraq with that approach, so you
have a good shot.

I know I'll regret asking this, but what approach? And what am I
supposed to be aiming at?

Oh, I see you have never used them.

I don't need to use them to see that they are useless.

It's kinda sad when someone of your supposed intellect and expertise
tries a cheap shot like that. A moment of silence for your self-respect.

You are the one who labeled it a "train wreck", remember? I'm just
pointing out the irony that you seem to have been emboldened by the
experience.

I am not a web application developer, I am changing the way kids
experience Algebra:http://teamalgebra.com/

Kids are notoriously impatient. I predict your application is going
to drop dead.

ie, You just don't get it, or you do not want to: you want to obsess all
day over MTML/CSS/browser variability. Good for you!

Do you read these ravings before you post them? You come off like a
babbling psychotic.

But if you want the
attention of us working on higher-order problems, you have to produce
something that competes with qooxdoo.

I could do very well without your attention, thanks.

But I think you know that by now. I sure hope you know that by now.

Best of luck with your "higher-order" problems!

 

[Tim Streater]

I am not a web application developer, I am changing the way kids
experience Algebra: http://teamalgebra.com/

1) What's with the non-standard scroll-bars?

2) What's with all the keys with nothing on them in the typing tutorial?

Firefox shows fewer blank keys than Safari but not many.

 

[Kenneth Tilton]

You are the one who labeled it a "train wreck", remember? I'm just
pointing out the irony that you seem to have been emboldened by the
experience.

Yeah, I did, in reference to the ongoing development on my end. So it's
a cheap shot to present that as qooxdoo being a problem, given that I
was at the same time raving about qooxdoo (and linking to non-rave
experiences with other JS libraries).

I'll give you the benefit of the doubt that you lost that context.

kt

 

[Kenneth Tilton]

1) What's with the non-standard scroll-bars?

Define "standard".

2) What's with all the keys with nothing on them in the typing tutorial?

Firefox shows fewer blank keys than Safari but not many.

That's where I do raw HTML/CSS.

The keys are rendered by HTML generated by jsMath. I have an outstanding
issue I hope to defer in re the positioning done by jsMath, and if that
is in play the keys are being rendered outside the buttons. Or it could
be something to do with you likely not having jsMath fonts installed.

That said, I just checked FF, Chrome, and Safari on Windows and Mac and
Ubuntu, with and without installed jsMath fonts on the Mac, cannot recreate.

kt

 

[Kenneth Tilton]

1) What's with the non-standard scroll-bars?

2) What's with all the keys with nothing on them in the typing tutorial?

Firefox shows fewer blank keys than Safari but not many.

btw, if you click on any yellow area (it should turn white) and type the
keys: E = m c 2 does E=mc^2 appear? OK, or mostly off the top? If you
then click on a different yellow area does the formula shift vertically?

btw #2: Thx for the report.

kt

 

[Tim Streater]

btw, if you click on any yellow area (it should turn white) and type the
keys: E = m c 2 does E=mc^2 appear? OK, or mostly off the top?

Looks OK in Safari 5.0 Mac.

If you then click on a different yellow area does the formula
shift vertically?
No.

btw #2: Thx for the report.

np.

 

[Tim Streater]

Define "standard".

As provided by the host OS.

That's where I do raw HTML/CSS.

The keys are rendered by HTML generated by jsMath. I have an outstanding
issue I hope to defer in re the positioning done by jsMath, and if that
is in play the keys are being rendered outside the buttons. Or it could
be something to do with you likely not having jsMath fonts installed.

Whatever they may be

That said, I just checked FF, Chrome, and Safari on Windows and Mac and
Ubuntu, with and without installed jsMath fonts on the Mac, cannot recreate.

I'll see if I can e-mail you a screenshot and I'll try those other
browsers.

 

[Kenneth Tilton]

As provided by the host OS.


Whatever they may be

http://www.math.union.edu/~dpvc/jsMath/download/jsMath-fonts.html

Sposed to be faster/prettier with those installed.

I dragged them out of Mac Fonts folder, restarted, reset Safari, still
OK. I bet you are timing out waiting for the fallback image fonts. Just
now they all came up blank and a good 750ms later got filled in.

kt

 

[David Mark]

Yeah, I did, in reference to the ongoing development on my end.

Yes. Seems appropriate.

So it's
a cheap shot to present that as qooxdoo being a problem, given that I
was at the same time raving about qooxdoo (and linking to non-rave
experiences with other JS libraries).

Except that it's been well-established that qooxdoo was the root of
your woes. Your "ravings" notwithstanding.

 

[Kenneth Tilton]

Yes. Seems appropriate.


Except that it's been well-established that qooxdoo was the root of
your woes. Your "ravings" notwithstanding.

Well so much for giving people the benefit of the doubt.

I'll prove you wrong when I have my next release ready and need an
excuse to post again. Adding persistence now so kids can "level up" in
Algebra and save their work.

Here's the DB I am using: http://www.franz.com/agraph/allegrograph/

kt

 

[David Mark]

Well so much for giving people the benefit of the doubt.

So much for assuming you can understand reason.

I'll prove you wrong when I have my next release ready and need an
excuse to post again.

ISTM you are never short of excuses.

 

[Kenneth Tilton]

ISTM you are never short of excuses.

Don't sell yourself short: you are the wind beneath my spam.

kt

 

[Jukka Lahtinen]

http://www.math.union.edu/~dpvc/jsMath/download/jsMath-fonts.html
Sposed to be faster/prettier with those installed.

Don't expect everybody to have every possible font installed.
Whenever a site needs some specific font, it should say so on the front
page and provide a download link.

 

[Kenneth Tilton]

Don't expect everybody to have every possible font installed.
Whenever a site needs some specific font, it should say so on the front
page and provide a download link.

Right. I said "Sposed to be" deliberately: looks good and goes fast
without them.

Agreed: adding "link to fonts for serious users" to do list, but I am
working under the assumption that users will not have the fonts installed.

kt

 

[Kenneth Tilton]

Bad Qooxdoo/Lisp looking better/faster all the time:

http://teamalgebra.com/

1. Registering can be ignored for now. It will be needed to do Missions,
but that's not ready yet. Recovering login does not work yet (forgot to
remove that option).

2. Should load faster. Curious how folks far from US east coast do.

3. If you do register, your info will be stored using AllegroGraph!

4. qooxdoo continues to rock, as does qooxlisp. I could file a bug or
rfe against qooxdoo every four hours, but so far it's superficial stuff
easily worked around at the cost of some UI elegance. (You'll laugh if
you try tabbing through the fields of the registration form.

5. Enjoy. And tell your Algebra teacher friends I am looking for local
schools interested in being guinea pigs.

kt