I've always lamented the fact that we don't have the time or structure to really teach our kids to program.

In their early classes, they learn syntax, algorithms, and  some ways of storing data and while they  will probably work on some larger projects as they study CS, kids seem to be mostly left on their own in terms of how to take a project from problem or idea to completion.

This frequently leads to poorly designed projects that are harder for the kids to write, debug, and modify. They end up with huge functions/methods no overall plan or design and everything's pretty much a mess

To try to address this, and having finished  most of the A.P. curriculum and not wanting to diverge from the other teachers, I figured we'd develop a class project before I gave the class time for their final projects.

I'm not a huge game person, but since they decompose well, we decided on writing connect 4 - a game that can be described as tic-tac-toe but with four in a row, on a larger board, and WITH GRAVITY!!!!!!

Actually, the choice of project didn't matter that much so long as it was the right size -- this was more about how we develop a program than about the actual program itself.

I started by giving my classes about ten or so minutes to talk among themselves to design the program -- no guidance was given. About seven minutes in, I asked them to reflect on whatever they were discussing - if they were discussing a data structure, why? If class design, why? What was so important about whatever they were discussing that made it their first order of business.

After a while, we started to share thoughts as a group. Most suggestions revolved around details -- how to you check for a winner, how do you make a move. This made sense - we've spent much of the term dealing with writing code fragments to do things and not too much time thinking about overall design.

This lead to a healthy discussion of looking at things from the top down as well as bottom up.

By the end of the class, we had identified the key classes we'd need (Board, Player, UI, Game Driver) and had some idea as to how they would relate to each other. By the next morning, we added a data structure for the board.

Over the next few days we filled in the missing pieces. We moved up and down levels of abstraction being careful to discuss why we designed things the way we did and adapting pieces as needed.

By the end of the project we were able to accomplish the following:

• Students saw how to have classes refer to each other - that is, the Player class had an instance variable to hold the board, while the Game class had instances for Players as well as the Board). 
• We were able to use different user interfaces for the program -- starting with simple console input and then moving to a GUI -- all we had to do was extend the UI class.
• Likewise, implementing a computer player (albeit a rather limited one) was trivial.
• I also tried to show frequent testing and the idea of developing one concept at a time.
• We discussed the idea that while design is important, there's a point where you can over design. Be aware of the scope of a project, what can generalize, and what shouldn't.
• With a good design, it was also trivialize to change things like game rules, how to move, board size. etc.

Based on preliminary feedback, I think the students have a much better ideas as to how to break down, design, and build up a project from design to implementation.

If any one's interested, the code is available here.

We'll see if it helps with the final projects, but I'm optimistic.  Spending time highlighting the design and development process while building a project can only help.

Anyone else have interesting mid-size projects they do with their classes?

Now that the ML and AI courses are at an end, here are some of the things I would do moving forward.

Both courses already have a basic track where students just watch the lectures and do the in lecture quizzes and an advanced track where students also complete weekly assignments. I think we can be certain that there were students who just watched a few lectures, many who completed every assignment, and those who fell at all points in between.

On top of this, there were students who made use of the on line discussion groups and those who didn't.

This means there ware a wide range of experiences to be had.

With this in mind, here's what I would do.

Suggestions dealing with basic site content:

More practice problems, particularly in AI


While there were in video quizzes each week that provided practice, it would have been nice if there was a link to additional optional problems (preferably with solutions available).  This would be easy to implement. The ML class would also benefit from this, but since you could retake the weekly assignments and get some variation on the questions, it would be as necessary.

Better reference materials

Reference sections would be nice as well. The AI staff posted related sections from the text, but there were a number of great on line resources I discovered by reading the discussion groups. Perhaps some of these could be linked to from the main site.

Grading


I'm pretty sure that having weekly assignments that were actually graded helped keep me honest.  The fact that the ML course was submit as many times as you want and the AI course was one shot didn't matter. I put the same effort into both classes. In a way I preferred the ML course.  I was frustrated a few times when I mis-entered something on a homework or forgot to convert units and got a lower grade than I thought I should have (I know, the grade doesn't really count).

I'd actually kind of like the AI course to move more towards the ML class model. The grades don't really count for anything anyway, and if they did, there are so many X-factors.

For example, if some one has to do the weekly assignment early due to obligations later in the week, he or she can't make use of clarifications. Likewise, students probably had widely varying amounts of time to dedicate towards the course. Contrast that to the traditional undergrad student probably has a similar workload to the other people in their classes. In the ML class, it all really didn't matter.

Office Hours:


I wasn't a huge fan of the office hour questions in the AI class but I very much liked the idea of seeing the profs directly answering weekly questions, it helped connect the instructors and the class. This was lacking in the ML class and should be added.


On running the class in the future:

What made these classes different from other on line lectures was that these were "live" with a staff releasing new content, opening and closing assignments, and adjusting as the course progressed. Each class also had a large number of people taking the class at the same time. Far different than say someone arbitrarily to watch videos from an Open Class Ware course.

I'd like to believe that the live staff, real deadlines, and large cohorts had a significant psychological effect.  I've started on line courses in the past but rarely finished them. I think the weekly deadlines and "live" aspect of the course got me to start early each week and forced me to stay up to date.

With this in mind, Stanford could just run the courses again in a similar manner, possibly with some one else acting as "instructor" to field office hours and oversee the course.

In addition I'd allow people to take the courses in the following ways:

Solo:


Since many people probably didn't avail themselves of the discussion groups, there's no reason not to allow someone to start at any time. All that would be needed is the ability to have them submit projects, quizes, etc. If the system could do that, Anyone could take the course at any time, albeit without interaction with others.

Cohort:


People could sign up with a start date or number of students in mind. When that's reached, a cohort group can start the class. The discussion pages could be modified so that a cohort can go to it's own discussion page and the system can dole out lectures and assignments on a pre-determined schedule. This would allow the course to start at a range of times while making sure that students had a community of learners to support each other via discussion groups.

Facilitated:


Similar to Cohort but someone would sign up as a facilitator. They would moderate the discussion group and control the flow of lectures and assignments. There could even be a way of "licensing" facilitators so they could run official versions of the classes. This way, a local group or school could run the class on their schedule.


So, there you have it. How I'd modify Stanford's great educational experiment. Next time, I'll share my thoughts on on-line education and how it's (mis) used in our high schools.

This is the first in a three part series.

Part 1 talks about my take on how the courses were presented.
in Part 2, I'll discuss my take on how to improve the experience
and finally, in part 3, we'll look at on line education with an emphasis on the high school market.



As some of you know, I've been taking the on line Machine Learning and Artificial Intelligence courses offered by Stanford this semester. I took my AI class a hundred years ago and I never formally studied ML so I figured this would be a fun way to keep current.

Lots of people have already "reviewed" the courses, compared the instructors, assignments, and what have you. Now that the courses are almost over, I thought I'd try to look at it a little differently, wearing my hat as a high school CS educator rather than just a consumer.

I've enjoyed both courses tremendously and I'd like to thank everyone involved in making them available to the public.

Teaching style:


Every teacher has their own style.  Here's my take on our three instructors. I don't think any one style is universally better than any other, rather different styles speak to different students.

Peter Norvig: 

While watching Professor Norvig's videos, I felt that he was the learned sage imparting information. He's the wise man in the village that everyone turns to for answers.

Andrew Ng:

I felt like I was with a tutor or a coach, everything was gently presented and at the end of the lecture I looked back and said "wow, I got all of that, it made sense." As he was the only lecturer for the ML class, I'll explain in more detail in the next section.

Sebastian Thrun:

I can't come up with an analogy for Profressor Thrun, but I could feel him saying "let's try something neat, make some mistakes, explore neat things, and learn a whole bunch as a result." It took a while to get used to this, particularly when being asked questions before given enough information to approach them. Once used to the technique, however, I really enjoyed his approach to teaching.

Conclusions: I would love to have the opportunity to sit in on live classes with all three as sitting in on a class can be very different from watching a video, but being on the east coast, I don't think that will happen any time soon.


In the ML lectures, Prof. Ng gently guided the viewer through the topics. Generally first by describing the various parts of the topic in question and then by bringing it all together, completely describing the algorithm or technique.

There are points in the lectures where Prof Ng states that the material is hard and that he had a tough time with some of it. This empathy and his assurances go a long way. I found the lectures easy to absorb and didn't generally have to think too hard. By itself this might have limited the educational experience, but combined with the assignments, it worked great.

The AI class had a different approach. The class was frequently tasked with solving problems before material was presented. This turned me off early on. As the class progressed, the professors started to emphasize the fact that your quiz scores didn't matter (they appear on the web site but aren't calculated in the final grade, not that the final grade matters anyway) and that these questions were to get you thinking about the topic more deeply. Once I started looking at the approach from this point of view, I enjoyed the class much more.

That said, I found the ML class lectures much more self contained and found myself looking for additional resources to learn the "base" material at times in the AI class.

The AI lectures forced  me to think more than the ML class which is probably a good thing since there were no programming projects to take up the slack.

Conclusions: Styles differ but both can be effective. I could make as much or as little a mental effort as I wanted for the ML class and I'd get out of it what I put in. The AI required more effort to get anything out of it -- the approach forced you to think where the ML class encouraged you to think. In the end, I put comparable amounts of time into both and got about the same amount out of each.

Homework and Projects:


Both classes had weekly homework assignments. Without these, I would probably have slacked off on the videos.

In the AI class, these were submitted over the course of the week and then graded. Results and explanation videos were provided after grading was done. The process was fine but I found the interface occasionally frustrating. There were some complaints on the message boards about losing points due to mis-entry or insufficient accuracy of answers. I  had a few problems with both but since I wasn't obsessed with getting a perfect score, it didn't bother me too much.

I'm not sure how great the assignments were in terms of assessments but attempting them and then watching the video explanations turned out to be a strong pedagogical approach. I would recommend including the explanation videos in the regular sequence for the in lecture quizzes. I frequently gleaned a tidbit or two from them even when I answered the questions correctly.

The only downside to the AI class quizzes and homeworks is that they were all in video form. A PDF of the midterm was published and something similar, at least for the weekly homework assignments would be a plus.

The ML class also had weekly assignments. They were in the form of an interactive five question quiz. You could attempt them up to 100 times and your top score would count towards your grade.

The real value added to these assignments was the explanations when you answered one wrong. There were even a couple of times I answered a question or two incorrectly on purpose to see the explanations provided.  This style of assessment provided a feedback loop that could really help a student to be sure they understood the work.

The one thing the AI class lacked that the ML class included was programming assignments. Probably a good thing for me since I don't think I would have had the time to be able to complete both courses with that added burden. That said, I loved the ML class programming assignments.

For the most part, they were extremely well constructed, stepping the student through all of the weeks topics. By the end of each project, we had a working system and a good understanding of the weeks concepts. You could take shortcuts and finish the assignments by merely copying and coding up formulas but if you did it right, you'd learn a lot.

The only assignment that I felt was less than stellar was the SVM project. Even then, it had redeeming features. For part of the project we had to process emails and build a table of word counts. Not directly related to SVMs but something that's frequently done with data to be processed and therefore still worthwhile.

Conclusions: The programming projects really reinforced the lecture content in the ML class and I would imagine that adding them to the AI class would benefit students. Even without them, one could go to the actual Stanford class'es web site and work on their projects.






Other random thoughts:


Both courses used the web site, email, and twitter to periodically communicate information, but the AI did one thing the ML class didn't. They periodically sent messages of congratulations and encouragement. They also repeatedly mentioned how well we were all doing in the lectures and in the office hours. Prof. Ng also provided encouraging words, but they seemed more self contained and generic.


On the other hand, I wasn't happy with the large numbers of hints and deadline extensions that the AI class offered. I felt that it rewarded people who left things to for the last minute and gave them an advantage over students who were more diligent or had to complete the weeks work early and could not take advantage of the last minute hints and extensions. Ultimately it doesn't matter, but that's the type of thing that pushes my buttons.

Conclusions: Again, both courses were great, but the AI course seemed to do a better job in connecting with the class, that is, making me feel like I'm part of the class rather than just watching.


Wow, that was long. I hope some one finds this interesting. In the next installment, I'll talk about what I would do if I were moving these projects ahead.

Ok, it's a word search.

We're always looking for interesting applications to build lessons around. Over the years, I've tried different things when teaching 2 dimensional arrays. Simple game boards, representing a crossword puzzle, tables of various sorts, etc.

This year, JonAlf, one of my amazingly talented colleagues, decided to go with building a word search. I decided to steal the idea. It's a great one.

I thought I'd use this post to go through the project and why I like it.

Ultimately, the students end up with a program that will generate an n by m word search filled with random words from a dictionary. We gave the kids a skeleton of the base class. The only actual code we had to supply was the method that loaded a dictionary file into memory. You can check out the assignment here and the finished code here (we updated the repository as the project developed).


The first part of the project are pretty mundane. The kids write a couple of constructors and toString. Basically just practice traversing a 2D array. The project starts to get interesting at part 2, when they write the methods that add words into the grid. First horizontally:



After they write the method to add words vertically, we can start to refine things. We notice that the routines are essentially the same. The only difference between adding a word horizontally and vertically is  what we add  to the row and column each time. For one, there is a delta column of + 1, for the other it's a delta row. Further, they realize that adding diagonal words just needs both deltas. This leads us to factoring out the common aspects of the code and writing something like:



All of a sudden, they've written one piece of code that can add words in 8 orientations.

After filling the rest of the grid with random letters, we turn our attention to building a random puzzle.

This part of the project involves using an ArrayList of words. Our students frequently mix up array and ArrayList notation early on so by having a project that uses both but in clearly delineated areas, the students can be more comfortable with each.

For this piece, the code is again straight forward. Students run a loop that gets a random word from our dictionary and tries to place it in our grid at a random location choosing one of our possible orientations randomly. We get to see another nice little refinement again when we move from the typical first take at building a random puzzle which uses a three (or more) way if statement to select how to add words:



to using our more general addWords method described above:




When we're all done, we had some time to project the word search on the board and fun was had by all.

Peter, another one of our CS teachers had a great suggestion that I think I'll try. Start a competition to have the students modify the program so that it generates as densely packed  a wordsearch  as possible (giving higher scores first for longer words, then number of words).

Between the way the project broke down, the topics covered and the little refinements, I really enjoyed working with my classes on this project -- I'm hoping they enjoyed it as well.

A couple of weeks ago, I attended the K-12 workshop at the Grace Hopper Celebration of Women in Computing Conference. It was great to reconnect with some old friends, make some new ones, and talk shop for the weekend.

One result was that I promised to start blogging again.

I've got a number of ideas for posts lined up. Some on pedagogy, some technical, and some cultural. Hope you enjoy them.

Earlier today Ben Chun tweeted about this post: http://worrydream.com/SomeThoughtsOnTeaching/.  To summarize -- teachers should practice what they preach. In the post, Bret Victor wonders if there are calculus teachers who spend their evenings doing calculus.

I know a number of math teachers who spend a considerable amount of their free time working on problems and refining their math skills, I also know many who don't.

I know wonderful, inspirational teachers in both camps. I've also known weak teachers that fall into both categories. Great teachers in both categories also spend large amounts of time working on how to best deliver instruction.

Before I started developing the computer science program at Stuyvesant, there were one or two sections of A.P. Computer Science. They were taught by a terrific teacher -- one of my mentors and role models, but he was a math guy and not passionate about CS. When I took over, the enrollment immediately shot up. Not because I was any great shakes, and Dave, the previous teacher was legendary. Rather, the students knew I loved CS. Part of that love was that I enjoy solving problems with computers, coding and what have you. The students can tell.

The fact that I code is a byproduct of my passion and part of the whole package that defines me as a teacher and a person. Whatever success I achieve is a result of this package. It's something I enjoy, and it also keeps me current with the field.

I've seen "naturals" who are just great teachers and get by without a passion for their subjects. More often than not, there's a ceiling in terms of what they can give their students either in terms of content, or more importantly, in terms of inspiration. Some times the ceiling is high enough that there isn't a problem.

Over the years, my "practice" has taken different shapes. Early on, while my students were working on USACO problems. I figured I had better be able to represent, so I started doing them. Later on, I would write systems to support my teaching.

More recently, I've been lucky enough to be surrounded by a number of like minded educators. We frequently share little projects we work on.

This semester, I've been taking the Stanford on line AI and ML classes -- both have been lots of fun.

This is just what I do and who I am and it is reflected in how I teach.

Of course, time and job constraints make coding difficult during the school year. With ~150 students, lesson planning, grading, and ancillary responsibilities take their tolls.

So, I guess I'm an example of what Bret Victor was talking about. I'm not sure I fully agree with his thesis, but it seems to work for me.

Now for the rest of the trip.

Rome to Little Falls

We had some trouble getting out of Rome. As always, once we're on trail, it's pretty easy to follow, but entering and leaving towns and cities, with the exceptions of canal side towns like Lockport, can be a challenge. During the day, we found that we could either follow the official Erie Canal Trail signs or the pink trail blazes painted on the streets for the Erie Canal Tour (that preceded us by a week). As we get to towns, the blazes are of little use since they lead to rest stops and camp sites rather than through. We also had the Cycling the Erie Canal book. It's terrific and I recommend it to anyone riding the canal. It does, however, have one problem. When the path is on the road, it doesn't actually name the road (rather, it superimposes the path line). This made getting out of Rome a chore. Fortunately, we only added one mile to our day before we found our way out.


Leaving town we saw Rome's beautifully restored train station:



Also, the Fort Herkimer Church:


The rest of the ride was relatively uneventful.

We spent the night in Little Falls. Stayed in the "Canal Side Inn," a small in with three rooms. Our's was both huge and gorgeous.  It has a connected restaurant. Fine French/American fare. Everything on the menu looked delicious, but after a day of riding, it was a little much. They also had a less expensive, less elaborate grill menu with items like Steak Frites, or scrod in an almond crust served in the lounge. As the lounge was booked, they offered us the grill menu in the main dining room. Food was excellent, including the deserts -- chocolat pot de creme, a meringue filled with strawberries and ice cream, and a blueberry bread pudding.

If you ever get to Little Falls, eat at the Canal Side Inn.

Then it was time to turn in.


Miles today: 44.5
Miles total: 313.5

Little Falls to Amsterdam:
 
As Little Falls was right next to the canal, leaving town was easy. Just outside of town, we passed the high point of the canal. At the point, a lock with what I think was the canal's largest altitude change.

It looked to be another uneventful day. More beautiful views that have become de rigueur and more crushed stone path that was more like biking through sand.

It looked like our two most promising lunch spots were at around 15 miles (too early) and 30 miles (too late). At 15 miles, at Canajoharie, we stopped for ice cream:


This was the first time all trip we were able to find mid-day ice cream!!!!!!

Canajoharie is another one of those small towns we passed through, but they set up a little information stand right where the trail crosses main street. The young man working there directed us to the ice cream.

One of the things that surprised me throughout was the lack of signage at the towns, particularly the small ones. While the traffic on the trail isn't great, a couple of signs pointing to food and refreshments at the trail heads would cost next to nothing and maybe draw a few more people into the towns.

Refreshed and refueled, we continued on. After lunch at Fultonville, we soldiered on. A few miles out of Amsterdam, we got to the Schoharie crossing:


Here, you can see the remains Schoharie aqueduct from the barge canal in the distance:



The Schoharie crossing is the one location where there are remnants from all renditions of the canal and one can also see the I90, where the bridge collapsed some 20 years ago.

It also turns out that this was the site of other historic places:


We arrived in Amsterdam a short time later. We stayed at the America's Best Value hotel. The only one in town. Looks like new ownership is doing some serious renovations but the rooms were spacious, clean, and nice. BIL Mike and SO Maria live nearby and joined us for dinned. We ate at the on site indian restaurant -- naan and saag paneer -- mmmmm.

One more day of riding.

Miles today: 49
Miles total: 362.5


Amsterdam to Albany:

Last day of riding. We estimated about 50 miles. Best lunch possibility was Cohoe s, about 30 miles away. We were hoping to find a snack along the way but figured we'd make it on Nuun and Cliff Bars if needs be. The mileage looked to be formidable, but we also new the whole day would be on paved roads and paved trail.

Leaving Amsterdam, we saw a couple more historic sites:






Sad to say, even here, there are ghost bikes:



Some final pretty views along the way:



















New and old locks:























A fallen Rock zone complete with fallen rock:



 This bridge that just rose out of nowhere:



 And a family picture sans me:


And we were at the Cohoes falls:


We stumbled upon a bike shop that recommended we go to "Bread and Jam" for lunch.










After lunch, we were down to our last 10 miles.

Along the way we saw this:


Clearly owned by the third pig.

Finally, to the Hudson river, our river:





We got to Albany early enough that we were able to switch our train tickets, cancel our hotel reservation and get home by 7:00.

Miles today: 55
Miles total: 417.5
Plus the miles to reconcile with Devorah's count give us: 420

That's 420 miles in 10 days, right across the state. 46.6 miles a day on average for the ride days.

We're all a little tired but feeling a sense of pride.

Next, some reflections on the tour and touring.

No wifi last night.hopefully tonight.

Got in to Amsterdam NY a few hours ago. Just finished mapping out tomorrow's route. Hope to get all the details and pictures for the past three days up tomorrow or Sunday. Too sleepy to do it now.

Miles Yesterday: 44.5
Miles Today: 49
Total: 362.5 (but I think I lost a handful of miles somewhere).

Tomorrow we make our way to Albany.

Today figured to be one of our longer days mileage wise, we didn't think it would be that tough or tricky to navigate.

We checked out of our hotel at about 8:30 and hit the road. Streets through Syracuse, up a few hills towards the outskirts of town. Our directions and actual streets didn't quite jive so we had a little trouble finding our way back to the canal path, but once we did we figured it would be smooth sailing. Most of today was along the "Old Erie Canal State Park." A 36 mile linear park stretching from Syracuse to Rome.  Just about all of it is off road.




About 17 miles in we got to Chitenango, birthplace of L. Frank Baum of "Wizard of Oz" fame.  We spent some time at their "Canal Boat Museum." It's on the site where they built and repaired canal boats. They've been working to restore as much of the site as possible. This includes the drydocks:




as well as an 80% sized canal boat they're building:



Back on the trail, we spotted the remains of sunken canal boat (note the rebar tracing out the boat in the water):


Continuing on, there were more locks:


and bridges:


After lunch in Canastota, we set out on the second 25ish miles of the day. We found our way back onto the path, the stone dust was fine and even some of the road was paved. This lulled us into a sense of security. About 15 miles into the afternoon ride, we crossed path with what appeared to be a trail resurfacing machine. Not a good thing. The next few miles had us hugging the one good edge of the trail. The rest was soft and full of holes. The whole trail was also full of runs of dirt and gullies. All hazardous to us.

We struggled through and made it to the outskirts of Rome. We followed the last few miles of path, but the path kept degrading. First to a rocky surface, then to one with pools of water, then to no path at all!!!! Fortunately, there was an outlet to a road nearby. We worked our way to it and followed the roads the rest of the way in.

We had made it to Rome.


After lunch in Canastota, we set out on the second 25ish miles of the day. We found our way back onto the path, the stone dust was fine and even some of the road was paved. This lulled us into a sense of security.

After checking into the hotel and a cooling dip in the pool, we walked over to fort Stanwix, dating back to the French and Indian war.




Dinner at the Franklin Hotel (appropriately, Italian food. As they say, when in Rome...).

Tomorrow we head off to Little Falls.

Today: 49.5
Total:   269

Yesterday we left Seneca Falls and headed back north up to Syracuse. Our fifth day in a row of riding. Figured it could be one of the tougher days between the changing terrain and the return of the heat and humidity.  Apparently, there's no shade in northern NY.

Turned out to be true. The first part of the ride was mostly on road. Easy surface, but up and down.  When we got to the old canal path, it was more gravely than crushed stone. Felt like we were riding through mush.


Stopped about 20 mile in for lunch at Jordan. Just about our halfway point of the day and of the trip.



Unlike other days when we were able to find nice local eateries, today we hat to resort to a single pizza place. Truth be told, it was pretty good but as the pizzeria was hot, we were actually better off eating at the picnic table in the sun out front.

Back on the trail, there were some nice sights, including remnants from the old canal.







After 42.5 tough miles, we ended up in Syracuse.



Hearty appetites in tow, we decided to sample Dinosaur Bar-B-Que. Good. Personally, I prefer the burnt ends at Rub and the overall meal at Hill Country, and those are just a couple of blocks from our house.




Today was our rest day. Hot and humid -- would have been brutal to ride, but it wasn't a lot of fun walking around town. Not much to tell, just a quiet day. Most things we hoped to see were closed. We did get to the Erie Canal museum -- In the last remaining WeighLock house (sorry, no pictures, accidentally erased what was on my phone). To pay for the original canal as well as it's expansion, tolls were levied on good passing through. To determine the toll, canal boats had to be weighted. At the beginning of each season, weights were determined for each boat. Then, as they moved through the canal, they would enter a weighlock, the water would drain, depositing the boat on a huge wooden cradle which was part of a scale. The boat would be weighed and the toll assessed.

Here's a picture from wikipedia:



Note the road in front -- that used to be the old canal. Other than the weigh lock building and a few other artifacts, there's nary a trace.

The rest of the day was spent walking around and taking it easy.





Miles from the previous day: 42.5
Total: 219.5

Tomorrow: All roads lead to Rome.