doctest from Vim

I want to become comfortable with the Vim way of editing, I'm convinced it will save me much time, since I seem to be on a path which involves lots of keyboarding.

A new member of the zcadoc project recently pointed out that Baiju's choice for an example application has the potential to be confusing. It's a hotel app, which handles guest registrations. The ZCA involves registering components, so the word is used in 2 ways.

Maybe we can change the spelling of a couple terms to avoid the confusion.

So.

izca.txt holds the book in ReStructured text, with the examples in doctest format.

I need to do text replacements, running doctest on the results to see what broke. This seems like a common enough use case to take the time to study how to do it efficiently. I can picture a Vim expert making the changes, running the tests, tweaking the changes ... all from the keyboard, using few keystrokes.

All that's required to run the doctests in the book is::

import doctest; doctest.testfile('izca.txt')

I made a file ``dtbook`` in the book directory::

#!/usr/bin/python
import doctest
doctest.docfile('izca.txt')

now, if I enter the following while in Vim normal mode::

:r! ./dtbook

The file tests run, and any tracebacks are pasted into the file.
I can do {lineno}G to jump to each problem line, delete the tracebacks
when finished.

Next, start renaming.

The first time

In the spirit of 'docubi' my branding for Documentation that is Ubiquitous, I created a gmail account, docubi, where I will send things I want to be remembered / documented.

- urls
- notes
- emails
- command results

It was the last which gave me a spooky experience, success without the obligatory failures / debugging.

Vim is pretty Ubiquitous, a Windows install offers 'Edit with Vim' from an explorer rclick, fine on Linux. I like the Vim feature
:r!
which runs a command and places the output in the file.

So.

If I do an install, configure or some such from Vim, saving the output, I want to send that file to the docubi mail account for later processing. And I want the lowest possible denominator for the tools to do it.

Starting with Windows, which I expect to be problematic, some options.

- a Vim script
- I don't want to learn Vim scripting

- a Python via
:py mailThisFile.py
- requires Python, not available on Windows machines, I'm ok with adding my c:\bin dir and installing Vim, but I'd prefer not to install Python on every machine I sit down at.

- A native binary and a batch file

A search turned up
http://www.beyondlogic.org/solutions/cmdlinemail/cmdlinemail.htm

`BeyondLogic` sounds familiar, I think I've been led there before.

Here's the scary part. I downloaded and put in c:\bin bmail.exe, a 44k file. I then typed::

C:> bmail -s {my smtp server} -t {the docubi address at gmail} - f {a return address} -a testing bmail -d


And it worked. First time. Not that it shouldn't, but IT NEVER DOES.

Hello? ... Errors? ... Where are you?

The only explanation I can think of is that, because the workstation I just migrated to seems to have irrecoverably scrambled it's registry upon my plugging in a USB stick, I've somehow earned a glimpse into a parallel universe.

Exposure

Last night, in the sauna, I realized the code fragment in the last post is dead wrong, a good demonstration of how far I am from grasping ZCA.

My initial feeling of embarrassment passed, and was replaced by interest in how and why I am so wrong in my understanding. I need to overcome my resistance to exposing ignorance if I'm going to hang in this blogosphere place.

====

I instantiated an interface. Discussions of interfaces tend to start with the fact that you do not instantiate interfaces. Why has that never sunk in?

My understanding of object oriented programming has class definition at the top, an object is created from the class, the object does things. Since ZCA explanations start with Interfaces, in my mind I associated them with classes.

It's as though there's a tree with many bird nests in it. There's a nest for classes, methods, attributes, functions etc. When *reading* about Interfaces they just roost on any available branch. *Writing* about them requires putting them in a nest. Since there isn't a nest for them, they ended up with classes.

I kind of like that analogy. I realize it's pretty basic stuff, we have notions which we try to understand the world with.

I like it because of the similarity to one of my favorite analogies. In a class on Native American languages I read a description of a Native American understanding of time. The writer described being in a bubble of the *manifest*, floating in a sea of the *unmanifest*. The bubble is generally considered "here and now". There are ways to access that which is outside the bubble. This in stark contrast to the European concept of time consisting of a journey along a line, with the future ahead, the past behind.

I am finding it useful to consider my little mind a bubble of things known floating in a sea of things unknown. This lines up nicely with ADD issues. I know with great certainty that my learning is not linear, but consists of struggling to pull items into my bubble.

When I come to understand something it has a nest in the tree. In the case of Interfaces, I need to understand that the existing nests don't meet the needs at hand.

I've heard that people learn object oriented programming more quickly if they haven't already learned procedural. I wonder if it would be easier to learn component based programming without a background in objects.

Future photos

I do a lot of digital photography, and as a student of programming, I have lots of ideas about software which would be useful for dealing with my photos.

I am currently studying zope component architecture via some editing of Baiju's book, I would like to begin a project applying ZCA to a real issue.

So, given ShotInFuture.jpg an image with a bad date::

>>> import ZCAImageTool
>>> batch = ZCAImageTool(storage=memory)
>>> imref = batch.add('ShotInTheFuture.jpg')
>>> print imref.filedate(year), ' ', imref.exifdate(year)
2008 2008

>>> imref.filedate(year) = imref.exifdate(year) = 2007
>>> print imref.filedate(year), ' ', imref.exifdate(year)
2007 2007

I really want to change all the files::

>>> batch.clear()
>>> batch.add('/home/ktenney/photos/nextyear')
>>> batch.filedate(year) = batch.exifdate(year) = 2007
>>> print batch.filedate(year)
2007

batch.filedate(year) would have some smarts::

>>> batch.filedate['bad.jpg'] = 2008
>>> print batch.filedate(year)
Mixed batch.
bad.jpg = 2008, others = 2007

I would like to lure Baiju and anyone else that might be interested, into helping put code behind these tests. The process would involve, among other things;

- deciding what existing interface to extend
- designing the interface
- writing the date/EXIF code in a ZCA-agnostic style
- registering the components
- ...

Background item #1
==============

My wonderful old Nikon Coolpix 990 has a dead memory battery, so every time I change the AA batteries I need to reset the date and a few other things. I tend to hurry through the setting process.

It turns out the latest batch of photos I've shot were shot in 2008. The photos are landscapes and such, no stock reports or newspapers, so I have nothing to gain by this glimpse into the future. It will, however, foul up photo managing software, where linear time is assumed.

So, I want to reset the year on the files, both on the file and in EXIF.

Background item #2
==============

A few years back I read some posts about a project that a C++ coder was doing, a tutorial based on email exchanges with a student learning C++ from scratch. I only followed it briefly, but I really liked what I read, and have continued to consider it a really effective approach, a revealling examination of the learning process.

zcadoc at Launchpad

Baiju's book is now available in a branch of the Launchpad zcadoc project

There's also a zcadoc team. I don't yet understand just how these elements work together.

I did a bit of branding for each.

The photo for zcadoc is one of my favorites, at least one friend saw it the way I intended; I walked the field collecting as many different seed heads as I could find, the photo means to explain *these are the grasses in this field*


For some reason I have this belief that there is considerable untapped potential in using images for explanations.

I'm not sure how well the large one for the team works, it is a photo of a team in action. Again the field, this time Kathy, Scott and Shunka the dog working together to roll a hay bale.



The 64 and 14 pixel images are of keyboard keys spelling out zcadoc crossword style. I have high hopes for it, it has lots of potential for monkeying with a larger version; embedding images into the blank keys etc. I also thought it might scale down to 14x14, staying recognizable due to the simple geometry and color.



Again *We'll See*