diff options
Diffstat (limited to 'etc/ACE-tutorials.html')
| -rw-r--r-- | etc/ACE-tutorials.html | 83 |
1 files changed, 0 insertions, 83 deletions
diff --git a/etc/ACE-tutorials.html b/etc/ACE-tutorials.html deleted file mode 100644 index 63df8e7df59..00000000000 --- a/etc/ACE-tutorials.html +++ /dev/null @@ -1,83 +0,0 @@ -<TITLE>ACE Beginners' Guide</TITLE> -<BODY text = "#000000" link="#000fff" vlink="#ff0f0f" bgcolor="#ffffff"> - -<HR><P> -<H3>The Beginners' Guide to ACE</H3> - -The <A HREF="http://www.cs.wustl.edu/~schmidt/ACE-members.html">ACE -development team</A> is creating a set of tutorials to help ACE -newcomers learn how to use the framework effectively. <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE_wrappers/etc/tutorials/index.html">Follow -this link to the tutorials.</A> <P> - -<HR> -<H3>Developing New Tutorials</H3> - -Here are some general guidelines for creating tutorials: <P> - -<UL> -<LI> Choose a topic that you know very well or are just learning. -<P> - This isn't really a conflict... -<P> - If you know a topic very well, you're likely to know what is most - important to the novice and what can be left until later. If you're - just learning a topic, then you know what questions you have that - must be answered before you can continue. -<P> -<LI> Keep it simple. -<P> - Don't try to use a lot of really cool ACE features along the way. Stick - to the basic stuff and show that. Try to use a minimum of ACE objects - that are not the direct target of the tutorial. -<P> - (For instance, don't get all caught up in ACE_Singleton<> if you're - trying to show how to use an ACE_Reactor.) -<P> - If you want to show something really cool that happens to depend on - another ACE feature, do a tutorial on that other feature first! I've - found that folks will tend to get stuck on *anything* they don't - understand even if it isn't directly relevant to what you're trying - to teach. -<P> -<LI> Document the heck out of it! -<P> - There's no such thing as too much documentation. Don't worry about - repeating yourself along the way. Assume that the reader knows nothing - at all about the topic at hand and explain even the parts that you feel - are painfully obvious. -<P> - If you feel that sticking a bunch of comments in the code makes it harder - to read then stick in a label and document at the end of the file or - something. Alternately, create both a well-documented version and a - sparsely-documented version. Then folks can choose between 'em. -<P> -<LI> Over-teach it. -<P> - If there's a tutorial created for a topic that you feel strong in, - create another one anyway. Everybody tends to code a little differently. - Perhaps your tutorial style will "feel" better to some newcomers - than an existing tutorial. You won't hurt anybody's feelings if - you present the same material in a different way. -<P> -<LI> Steal existing code. -<P> - The ultimate form of code reuse :-) Seriously... grab one or more - of the existing ACE tests or examples. Then strip it down to the - bare bones & add heaps of comments. I don't think the software-police - will be coming after anyone for that! -</UL> -<P> -If this thing takes off, I'll start to organize the tutorials into -groups. For now, lets concentrate on quantity & quality. Organization -can come later... -<P> - -<HR><P> -Back to the <A -HREF="http://www.cs.wustl.edu/~schmidt/ACE-documentation.html">ACE -documentation</A> page. - -<!--#include virtual="/~schmidt/cgi-sig.html" --> -</BODY> -</HTML> |