[Tutor] Volunteer teacher

[dn]

On 24/07/2022 07.27, Mats Wichmann wrote:
> On 7/23/22 13:14, Dennis Lee Bieber wrote:
>> On Sat, 23 Jul 2022 04:53:22 -0500, Leam Hall <leamhall at gmail.com>
>> declaimed the following:
>>
>>>
>>> For the latter, Python Object Oriented Programming (https://www.amazon.com/Python-Object-Oriented-Programming-maintainable-object-oriented/dp/1801077266).
>>>
>>
>> 	<snicker>
>>
>> 	A rather unfortunate name... Acronym POOP... "Object Oriented
>> Programming in Python" avoids such <G>
>>
>> 	Of course -- my view is that, if one is going to focus on OOP, one
>> should precede it with an introduction to a language-neutral OOAD textbook.
> 
> 
> Maybe... I haven't looked at one for so long, but I'd worry that they'd
> nod too much to existing implementations like Java which enforce a
> rather idiotic "everything must be a class even if it isn't, like your
> main() routine".


+1 (here, and +1 with @Alan's post)

and +1 to the 'paralysis through analysis' syndrome @Leam mentions. The
best way to 'learn' is to 'do'! Reading the same facts in similar
books/sources is unlikely to improve 'learning' as much as you might hope!


As a trainer (my $job is not in Python) my colleagues and I struggle
with trying to find a balance between 'doing stuff' with code, and
learning the more academic theory 'behind' ComSc and/or
software-development. It's a lot easier if one only covers 'Python', and
not the theory behind OOP (or example). However, professionals will
(usually) benefit from both.

Worse, there are a number of topics, eg Source Code Management,
Test-Driven Development, O-O, even 'modules' and (the infamous)
'comments'; which are/will always be problematic topics at the 'Beginner
level' - because if one is only writing short 'toy' program[me]s, there
is no *apparent* need or purpose - which makes it very much an exercise
in theory!


We are running something of a (pedagogical) experiment at our Python
Users' Group. The PUG consists of many 'groups' of folks, including
hobbyists and professionals, ranging from 101-students and 'Beginners',
through to 'Python Masters' - so it is quite a challenge to find
meeting-topics which will offer 'something for everyone'.

Currently, we have Olaf running a Presentation-based series on "Software
Craftsmanship". Accordingly, he talks of systems at a 'high level'. For
example 'inversion of control' is illustrated with 'Uncle Bob's' very
theoretical "The Clean Architecture" diagram (which I call 'the circles
diagram':
https://image.slidesharecdn.com/cleanarchitectureonandroid-160528160204/95/clean-architecture-on-android-11-638.jpg?cb=1464451395

In complementary (and complimentary) fashion, I am working 'bottom up'
on a series of 'Coding Evenings' called "Crafting Software" using the
ultimate practical 'code-along-at-home' approach. This has started with
using the REPL (PyCharm's Python Console - our meetings feature a 'door
prize', sponsored by JetBrains - thanks guys!). We commenced
implementing a very (very) simple Business Rule/spec, and immediately
launched into grabbing some input data. Coders who 'dive straight in'
make me wince, so you can only imagine the required manful
self-discipline...

Newcomers were learning how to use input() - that's how 'low' we
started! The object of this series is to build a routine and then
gradually expand and improve same. Along the way we will quickly
discover the hassles of changing from a single (constant) price (for
1KG/2lb of apples), to (say) an in-code price-list, to having product
detail stored in a database. Hopefully there will be realisation(s): 'we
should have asked that question before warming-up the keyboard', as well
as 'if we design with change in-mind, our later-lives will be a lot
easier'... 'SOLID by stealth'!

So, the series' aim is to show that a bit of thought (essentially the
implementation of U.Bob's diagram showing 'inversion', independence,
cohesion, and coupling) up-front is a worthwhile investment - as well as
demonstrating 'how to do it' in Python, and a bunch of paradigms and
principles, etc, along-the-way.


Relevance to the OP:
is to get-going, and realise that any 'later' "refactoring" is not a
crime/sin - indeed may be a valuable part of the learning-experience.


Relevance to you/more details about the two series:
- Olaf's series runs bi-monthly (s/b mid-August*), but Coding Evenings
monthly
* KiwiPyCon will be held (in-person and also on-line) 19-21 August
(after three postponements! https://kiwipycon.nz)
- the PUG gathers for two meetings pcm
- meeting-details are published through
https://www.meetup.com/nzpug-auckland/
- although the labels say "New Zealand" and "Auckland", we are no-longer
'local', running in the virtual world
- accordingly, relative time-zones are the deciding-factor, so we often
refer to ourselves as 'UTC+12' (or the PUG at the end of the universe?)
- all welcome - learners and contributors alike!


PS are looking at introducing git (or...) as part of the "Crafting
Software" series, and UML to ease Olaf's 'load'. Would you please
volunteer a 'lightning talk' and demo on one/the other/both subject(s)?
-- 
Regards,
=dn