(WARNING: this post contains an unavoidable marketing component, but i'm more interested in feedback on what i want to try as a whole new way to teach OE/yoctoproject. and so, to work.)
over the last while, i've taught a small number of OE/yocto courses to some commercial clients, and i've never been happy with the standard approach of writing a typical manual, having to lock it down shortly before the course to facilitate printing it, grappling with typesetting issues, worrying about how much sample code i can include without getting carried away and making a section too long, realizing partway through the course that what's in the manual is already out of date but the class is stuck with it as it's already in their manual, etc, etc, grrrrrrrr. so i have another OE/yocto course coming up shortly and i'm going to try a totally different approach. i'm going to teach the entire course off of online wiki pages. rather than waste my time tweaking format and aesthetics for the paper manual i would normally give out, and *knowing* it will be out of date in short order, i'm going to use my existing and many additional wiki pages and build some structure around them, and spend the 4 days simply displaying wiki page after wiki page, and having students follow along with the countless code excerpts and sample commands they contain. at the risk of linking to a currently chaotic work-in-progress, here's my new top-level page: http://www.crashcourse.ca/wiki/index.php/OE which even contains an active TO DO list that is changing by the hour as i write/update existing pages, check off some items and add others. here's my take on why i'm trying this approach and its advantages in my opinion, and i'm interested in feedback. first, no messing with stupid paper manuals and worrying about fonts and spacing and aesthetics. it's a wiki page and i can immediately see what it looks like, and writing wiki pages is easy. and i've got lots to work with as a starting point. next, it's easy to update on *very* short notice. i used this approach for some sections in a different course a couple weeks back, and it worked very well for staying current. i literally, in the evenings, over lunch and even over a couple coffee breaks, snuck in updated or entirely new content when i noticed something had changed. and when i found a typo on a wiki page, i simply fixed it right in front of the class and moved on. no big deal. the biggest benefit in my opinion is that, now that i no longer have to worry about the length of the generated paper manual, i can be as verbose as i want on any wiki page, and include as much code and as many examples as i want until i feel i've made my point. i want to emphasize lots and lots and lots of code snippets from the OE/yocto source code. for example, here's a page in progress where i explain how to develop a new BSP: http://www.crashcourse.ca/wiki/index.php/OE_Developing_a_New_BSP if i was writing this for a regular paper manual, i'd be trying to skimp on the sample code i was including to not make the section too long. on the other hand, because it's a wiki page, who cares? if i want to include 500 lines of code because i think it's worth it, i'll include 500 lines of code -- i'll include as much as i need until i think i've made my point. if i want to demonstrate how intel defines the BSP for their crownbay, i will happily reproduce every single relevant file on the wiki page and walk through each one. finally, all of the pages will be totally publicly available, so not just the students but anyone is welcome to peruse them whenever they want. and students will know that if things change after they take the course, i'll do my best to update the wiki pages to keep up. no paper-based obsolescence. and the downside? well, there is one place i *would* skimp, and that's the normal, fluffy, arm-waving intro and connecting text for each topic that you normally find in a paper manual or official documentation. my plan is to be *very* terse -- i wouldn't invest a lot of time in trying to make this content readable from a standalone perspective. i would select a topic to write about, create a new page and just jump right into showing how to do it with sample commands and code excerpts. so even though all of the content would be publicly available, it wouldn't necessarily be *comprehensible* for an independent reader -- i would be writing it for the classroom. but i don't see that as a major drawback. in my experience, most techies aren't interested in filler. they just want to see the code and enough working examples to get the idea. and the plan is for the wiki pages to contain *lots* of sample commands and *lots* of source code ripped straight from the code base. anyway, i think i've rambled sufficiently so ... thoughts? comments? criticism? starting monday next week, i'm going to find out just how well this works as i do this for the first time at a client site. it should be exciting. rday -- ======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ======================================================================== _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
