1. | Welcome | ToC | FAQ | Resources | Courses | Projects | Mail Lists | Members | Misc |
2. | Spotlight | About The MOST | History | Etiquette | Site Credits | Copyright |
3. | Ed #1 to Ed #4 | Ed #5 | Ed #5a | Ed #5b | Ed #5d | Ed #6 |

Education #6

Subject: Education #6 - The MEAT
From:radar@SMT-Inc.com
Date: Wed, 6 Mar 1996 21:20:15 -0400

THE APPROACH

We will agree on the contents of the INITIAL "Hello Mac Universe" project soon. We won't put EVERY technology into the pilot program, but I DO want to conceptually determine what SHOULD be there in future enhancements before we do the initial code. The initial subset MUST constitute a meaningful Mac program which incorporates all of the core Mac technologies - pretty much as defined by Bill in a previous note. I'll work directly with the other mentors in this effort to define THAT as a starting point. Please advise me EXPLICITLY if you want to assist in this specific task.

In MY mind, we MUST approach this with a CLEAR line drawn between the sample code itself and the supporting instructional materials. The CONCEPTS one must understand to program the Mac are platform independent and can be illustated using whatever dev environment is available. By settling on the FUNCTIONALITY of the "Hello Mac Universe" program without regard to the language used to produce it, we will facilitate our focus on helping understanding the Mac OS and its APIs rather than tying that understanding to any particular implementation. I believe that is the best approach because the tools are changing so fast that it is better to insure an understanding of the core than concentrating on how to implement it in any particular dev env. I've changed dev envs a number of times over the years. YOU will also :-).

Once we agree on the functions that we expect the program to perform, we will need to turn that design into working code for the various environments that we support. We should make it a goal to provide modular plugins for the lesson plan for each major dev environment rather than tying the plan to any specific environment. Otherwise, we disenfranchise those who have selected a different set of tools than we happen to prefer, and our curriculum becomes COMPLETELY useless every time the vendor releases a major upgrade to the dev environment.

Each of the lesson plans in the curriculum will be

[Re: Debugging techniques]
I consider this a whole separate area of focus that should get attention in the FIRST pass of the program. I am NOT particularly strong in this area, so i will require a LOT of assistance in bringing this particular area into better focus. I DO think it needs attention, though, and want to focus a BIG spotlight on it. My MAIN concern here is to make sure that our students understand the concepts needed to effectively troubleshoot their work, and that they are aware of the range of tools available from Apple and other commercial sources for these purposes. We should also provide a specific focus from each of the dev env experts to explain the use of the debugging tools that come with the environments.

I will directly work on whatever parts of the above fit MY skills, but will simultaneously be co-ordinating the various efforts into a comprehensive, but highly modularized, curriculum for study. Once complete, the ENTIRE package will be placed on our web pages for free access, AND I'll look for additional volunteers to help me to mentor the first 'class', with MANY of us as students, some as teachers, and some as BOTH depending on the specific module.

When the pilot class is over, we'll critique it heavily and make appropriate improvements. I'll then attempt to work with the mentors AGAIN to augment the "Hello Mac Universe" program to add things that we didn't incorporate at first. Eventually, we should have one heck of a complete vanilla application/self-study guide available in all of the major dev environments to allow people to concentrate on what makes THEIR app unique instead of wasting time on reuse code.

USE OF RESOURCES NOT CREATED BY THE MOST IN THE CURRICULUM

There are a number of excellent books available that provide a very similar set of info as what i am proposing here. Also, Apple computer publishes the Inside Mac series, which IS available in a number of formats, etc. and presumably is out on the net somewhere. I believe that we should have a place on our pages where we recommend ANY reference materials, books, periodicals, etc. that support each of the various areas, as sources for ADDITIONAL study/reference, but that we should NOT tie our OVERALL curriculum to any specific book, training class, etc. except to consider that IM should be a 'constant' in everyone student's ref library. That doesn't mean they have to buy a copy themselves, just that we should be free to reference it and expect that our students can access the reference.

I believe that WE should produce the ENTIRETY of the curriculum ourselves, rather than tying it to someone else's training book, etc. for the OVERALL course. We want it to tie to the HMU (Hello Mac Universe) program, so we'll have to customize the curriculum anyway. However, there is ONE specific exception to this general principle: the providers of each tool, dev environment, utility, framework, etc. will themselves be providing tutorials, demos, etc. to assist their customers in using their products. OUR curriculum would certainly include a place to insure that the student knows how to use (for example) Constructor, but i see nothing to benefit from insisting on writing our own tutorial for that tool if MW provides one already as part of the package. In cases like that our curriculum should just say something like: "To better understand the use of Constructor, work through the tutorial on pages xxx-yyy of the 'Blah Blah' manual that came with your environment. Feel free to contact MW technical support at ccccc@hhhhh, or one of our mentors, for further clarification of any points covered therein".

I have a similar perspective on our coverage of things already well covered by other groups. We DON'T need to do all of this ourselves, folks. Rather, i see us as tying together everything else that IS available and filling in any holes that remain so a wanna-be-Mac-developer can come to US first to see where ELSE he/she needs to go for the WHOLE picture. We'll also cover the parts that aren't 'glamorous' to insure full coverage. This will take YEARS to evolve, and by then the technologies will have evolved anyway, so we'll be working on this forever. That's OK. I think it will be a GREAT way to GET current, and then STAY current!

OUR FOCUS

The primary focus of this endeavor is to create a "method" and a complete set of supporting examples, documentation, sample code, etc. that will allow individuals/groups to rapidly get up to speed in learning how to program for the MacOS - and to take advantage of ALL of its ancillary technologies as desired. As a side benefit, we will provide the Mac development community with shell programs that will help them to implement Apple technologies with minimal wasted coding time in a variety of envs.

I foresee the VAST majority of our students as falling into THREE distinct categories. Members of each category have different needs and resources available to them. I THINK that the approach I am taking will actually work very effectively for all three of the categories.

The three groups are:

  1. College students/hobbiest programmers.
    These folks will have little money to spend on books, etc. and will probably need access to mentors for guidance/assistance with anything that they are having trouble teaching to themselves. They will know little about the Mac and will have few contacts in the Mac dev community to help them find out what they need to get started. We'll provide a FULL range of support to this audience.
  2. Other platform developers.
    Similar issues as the above group, but with specific commercial reasons to want to cut their learning curve. We will provide them with a way to economically evaluate the complexity associated with porting their work to the Mac and with a free place to learn/ask questions if they choose to do so.
  3. Current Mac professionals...
    ...who want to learn a specific technology that they don't already know. I fit here, and I assume that i'm going to benefit IMMEDIATELY from this exercise as the other mentors and I share info about the core technologies. I'm adequate on the basics of the mac, but i couldn't handle Apple Events today to save my life. I expect to change that.

ONE THING WE WILL NOT TRY TO DO

I DON'T see this as a place to come for individuals to ask specific ad hoc questions. I believe that the newsgroups that currently exist are EXACTLY suited to that function. I believe that we will better serve the community by spending OUR time producing a general purpose curriculum/reference/referral facility than by taking our member's time trying to personally answer every little nit-picky question that anyone ever has about the Mac.

FOCUS. We need to keep it.

HELP FROM APPLE? / PROMOTING THE MOST?

I've seen suggestions that i contact Apple for support in this effort.

For now, I don't think we NEED it and I'm NOT asking for it. I'm a BIG believer in having something to talk about before opening my mouth TOO far. I believe that we should proceed as if WE are the only resources that we need to make this happen and not worry about getting attention or publicity/support from anyone except for those who just want to volunteer for the sake of DOING this. This doesn't mean that I won't try to get individual Apple engineers to assist in creating this - I keep telling you people that i'm NOT a complete fool - but I don't expect Apple to do anything official to support us, and I never WILL expect that. As it happens, Apple engineers happen to be some of the nicest folks on the planet, and I suspect that we'll end up with MORE volunteers from among them once we get the word out about this project. But they'll be acting on their OWN in those cases, not as an indication of official support from Apple.

Some have suggested that we require people to 'credit' The MOST when they use any of our sample code. As I've said, the MOST will NEVER be looking for money from anyone, so it doesn't NEED publicity/advertising as such except to make sure people know we're here to be USED. I'd rather see the ACTUAL people who write the sample code, etc. credited for THEIR efforts than assign it to the nebulous entity "The MOST". I'm trying to resist having there be a REASON for the MOST to be an 'entity'.

As to FUTURE INTERACTION with Apple, MW, etc., my perspective is that we just proceed as we are and get something in place. If what we produce is so great that Apple wants to include it on their developer mailings, or MW, Symantec, etc. want to include the pertinent parts with THEIR products then that would be JUST peachy and they'd be welcome to do so. If we could arrange some kind of recompense for the specific authors, GREAT, but if NOT, NO BIGGEE. Remember, we're doing this for the Mac Dev community's benefit, NOT for money. If Apple, MW, etc. like what we produce enough to include it with their products, then we've just managed to get free distribution for our efforts to the audience that needs it the most. Isn't THAT what we're really trying to do here?

Copyright © 1996, 1997, 1998. Last Update to This Page: 1998/04/22
This Page Maintained by: radar pangaean * * * Original Author: radar pangaean
The MOST web site is built and maintained by the voluntary efforts/donations of our members.