dont laugh

[Jason Cunliffe]

Hi Will

thanks for your further interest on this

> What would have worried me would have been the low resolution of video,
> since text plays such an important role in programming.

 yes agreed

> This addresses my concern about video resolution. If source code is
> legible, that's the main thing.

I have found even over the shoulder with current SonyDV camera that I can
zoom in quite well to regular type sizes. Most videos like I said are plain
dumb/sloppy about all this. They either use cheap rgb->video converters and
end up with some pale fuzzed-out screen translation or they point a camera
at monitor and get hideous sync scrolling. These days things have improved a
lot. I have not actually checked recently with latest video output quality.
And LCD laptops do much better than most monitors. My Sony VAIO has a
beautiful bright sharp screen + a direct NTSC video out which I have not
even tested yet.

There are all manner of ways to sync computer to camera and monitor but they
are usually only for bigger budget TV or Hollywood and hopefully not needed
if one is smart. Even they had headaches and resort to all manner of fakery
and hokum to avoid the problems. Typically this is why you almost never see
people and screen close-ups in the same shot. Instead it is cuts - from
actor to screen to actor to screen with establishing shots of protagonist
looking serious leaning into some screen dynamics. They also use exaggerated
type sizes which works well because everyone can read, but rather removes
the 'realism' they want to make the action compelling.. all the way from
'Dougie Howser' via 'Jurasssic Park' to 'The NET'... 'The Matrix' of course
had the budget and savvy to do what they wanted...

As it turns out a tripod and a carefully matched camera pointing a  screen
with a reasonable amount of zoom can do a very good job. The advantage of
hand-held is one can follow the movement of hand and eye [expression = the
meaning between the meaning]. For following typing  it can be great, because
on can match the viewers attention  to the mental POV of the writer. In
other words, when you are typing you are mentally very zoomed in on the
words your are typing. A Camera style which follows this can do be very
good. but typically there is too much movement to be comfortable for any
audience over a period of time. To balance good 'story-telling' with
'information' , I recommend one sets up a dual monitor with a camera and
tripod well placed to capture all of  the screen cleanly. Then one is free
with 2nd Hand-held camera to follow 'the story', interview and occasional on
screen 'action'. Later you edit together and have the best of both worlds.

I just did a test with PythonWin adjusting font sizes and styles for both
the interactive shell and editor windows. This way one can increase size
enough to have much better legibility. Tweaking preferences one can also
make color, font parameters the best for both camera and making distinction
between code sections. At present it defaults to gray highlighting of
selected text . This should probably be changed.

Like anything to do with cameras, a few sensible tests in advance - video,
digitize, view on TV monitor, on computer as DV, etc should mean one is very
well prepared for best result. Obviously the aim is to be able to conduct
'interviews' in as relaxed and natural condition as possible, minimal fuss
or technical interruption.

If the second monitor [LCD] were a problem, one could of course dump session
to log file and sort out in a studio setup later, but advantage of doing it
live is you have all the sound and context to guide one.. be a shame to miss
the ambience and serendipity..

 > OK, I'm convinced, video is the way to go. Can you suggest any URLs
> about good video technique, and particularly getting good screenshots?

Not on hand - I will research myself since it has been a while since I
needed to do this and forward whatever I find to you..

> As far as doing a good job of representing the Pythonic mindset, a
> couple possibilities come to mind. One would be to ask the expert to
> construct good and bad examples, and explain what makes the good ones
> better. (In some cases, it might make sense to present a sequence of
> examples, going from horrible to adequate to elegant.)

Yes this I like this

- I would start by asking people to describe their own work and learning.
Including what they are working on right now..

- And for example a program they might have evolved.. perhaps to recreate
the step they went through.

- Another way would be to put the same programming task to everyone and just
let them get on with it in their own way to reveal styles of approach..

- One issue I think very valid to demonstrate in Python is the relationship
between pseudocode, Python and comments. Python seems very friendly to
evolve from some pseudocode towards working code. Good comments are
something some do and some don't.. but for beginners not only is it a great
habit, but it would wonderful to help people see how one begins to think and
sketch the problem..

I think very visually and carry 5x8 index cards everywhere which I use an
evolving library of ideas and design for myself and also to aid in meetings
with others. Since I often work in Europe with people and where language or
differing background may be a problem, this is a real plus. Also I find when
describing the sequence of things - how it works what happens when the user
does this or that etc  .. any architectural, abstract or structural topic is
helped by having a live dynamic drawing.. you start with blank paper and
talk and draw as you go.. later you can refer back to.. almost always if the
conversation is alive, both people will share the same paper and pens.. if
it is very productive people reach for fresh paper.. [good sign!]. I don't
know how many Python programmers use pen and paper or how many start by
typing..

I think this would be very interesting and helpful issue to follow and one
which video serves well..

Another but related is naming things.. especially in oops and python.

- Or to open up someone else's code and show how they 'read' it... break it
down and analyze. Try to explain what they do when they read new code..

- How they download open up a new module, go through demos or examples, scan
the docs, play around.. write some tests, make something, tweak something..

> The other possibility is to record an instance where the expert is
> teaching somebody of lesser expertise. Hopefully the student will ask
> all the questions that the viewer would want to ask if he were there.

Definitely  an important way to go. I am certainly a willing candidate here
for 'lesser expertise'

- Jason