C'est la Z

CS Stress

2012-01-29T17:06:00.000-08:00

I've been mostly underwater for the last couple of weeks.

End of term issues combined with the Academy of Software Engineering announcement has pretty much eaten up all of my out of class time.

It's going to be a week or so before I can finish writing the posts I was planning on, but it looks like a storm is brewing around Stuyvesant and Computer Science so I thought I'd put up this short semi-related post.

Stuyvesant has a reputation of being something of a pressure cooker. The day can be as long as ten periods and it's not uncommon for a student to take three or more AP classes, even before the senior year. The question of student workload and stress has been a hot topic for a number of years.

There's frequently tension over how many courses and which courses a student should be allowed to take. Usually, this revolves around the school placing a limit on the number of classes, or more specifically, the number of A.P. classes a student can take. Most recently, the conversation looks to be turning to the number of classes a student can take overall.

Given that most A.P. classes fall within a Stuyvesant student's required sequence of classes - that is, Calculus is just "the next math class" and A.P. U.S. History is slotted in place of a students regular U.S. History course, limiting the number of classes a student can take, A.P. or otherwise could have a major impact on Computer Science at Stuyvesant.

What's most disturbing is that limiting student options in terms of courses may not do anything to decrease stress and workload. No one has looked at what is actually going on in student's required classes.

I decided to collect some information from our students. I sent out a survey to five of our seven A.P. C.S. classes (three of mine, two of JonAlf's -- the other two classes don't have a mailing list). I asked them to rate the work load and stress factor for A.P. CS, their typical Stuy course and their typical Stuy A.P.course. So far, I've gotten 80 responses (out of about 150 students emailed). Here's what we got (ratings were on a 1-10 scale):

	A.P. C.S.	Reg. Class	A.P. Class
Workload avgs	4.97	6.65	7.13
Workload dev	1.94	1.41	1.52
Stress avgs	4.67	6.39	6.94
Stress dev	2.24	1.63	1.64

I know this isn't really hard data, but it seems that our A.P. C.S. classes are considered to be both easier and less stressful than other classes at Stuyvesant. Given that our kids do very well at C.S., we're probably doing something right and it will be a shame if student opportunities become limited. I'll certainly write more on this as the situation develops.

For you educators out there, is stress an issue at your schools and how do you deal with making room for students to take CS at your schools?

My Favorite Student

2012-01-15T05:32:00.000-08:00

Fred Wilson and me at #SOTC2012

Last week I was given the honor of attending the State of the City address. The mayor was announcing a new school for the fall. An Academy for Software Engineering. This has been in the works for a while and has a long way to go but the announcement was a major step. The project really got its start a couple of years ago. I'd been working hard for years prior trying to get the city to help me grow the program I developed at Stuyvesant, but until Fred got involved, there was no movement. Fred has to receive much of the credit for any good that we do as a result of this and I'd like to publicly thank him. If you don't follow Fred, you can read his post on the school here.

It was pretty neat to be on stage for the announcement, but those of you who know me know that I'm not a self promoter and these types of events aren't "me."

What I found really special, were the emails and tweets I got from my former students over the next day or so. As a teacher, we'd like to think we are in some way a "force for good" in our student's lives and we rarely get to really see what impact we do or don't have. To hear from so many and such gracious comments brought tears to my eyes. Thanks guys.

I've been thinking a lot about my career as a teacher recently. I decided to leave industry over twenty years ago. As teachers, particularly teachers with technical backgrounds we leave a financially lucrative field to enter one with very few financial rewards. It's also a field very much under attack, particularly in recent years. The current line of thought seems to be that teachers are to blame for everything bad in education and government and private interests, everything good. As a senior teacher, I'm particularly worthless, at least according to what I've heard on the radio over the past year.

So, what do I get out of the deal?

Well, when I hear form my graduates, I know that I've made a difference.

Also, the friendships I've developed over the years.

Stuy '84, '95, 2013, 2015 and families

A few weeks ago, we were catching up with a few of the Stuy '95 crew. We do it far too infrequently. They were students, they're now friends. I've had the privilege of seeing many young people grow to adulthood, get married, have children and in a small way I've been able to share in their lives. This is the upside of my career choice.

Maybe this is a result of being a computer science teacher who tries to keep a foot in the tech world. Maybe something else.

From the college student who stops by just to say hello to the graduate living across the country who drops a line to say how they're doing. That's the upside of the teaching profession.

Recently I thought it would be a good idea to organize the Stuy CS family. Collect email addresse and get a network going. I posted on facebook and sent out a few emails two days ago. So far, 240+ signups.

A while ago someone asked me who was my favorite student?

They're the ones that I'm still in touch with many years after they graduate.

Pretty sneaky, Sis

2012-01-11T10:10:00.000-08:00

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?

Stanford classes -- what I'd do next

2011-12-15T17:51:00.001-08:00

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.

ML and AI Courses - how they were taught

2011-12-08T17:36:00.001-08:00

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.

Lecture style:

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.

Where's Waldo - Text style

2011-12-03T09:49:00.001-08:00

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.

Reboot

2011-11-27T13:03:00.001-08:00

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.

The Rest of the Trip

2010-08-15T16:49:00.000-07:00

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.

Too tired to blog

2010-08-13T18:01:00.000-07:00

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.

No wifi

2010-08-13T07:19:00.001-07:00

No wifi last night.hopefully tonight.

All roads may lead to Rome, but not all are paved

2010-08-11T17:41:00.000-07:00

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

Nothing to see here

2010-08-10T14:58:00.000-07:00

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.

Day 5

2010-08-09T12:22:00.000-07:00

Angel 1: What are the Zamansky's doing next to that bridge?

Angel 2: Maybe they're pondering if their lives have had any meaning in this world.

Angel 1: Do you think we should send Clarence to straighten them out? He seemed to do a good job
the last time we had a troubled person on that bridge. He even earned his wings.

Angel 2: I don't know, maybe they're just trying to decide on where to go to dinner.

Yep there we were, on the bridge in Bedford, I mean Seneca Falls. The bridge and town that was purportedly used as a model for Frank Capra's "It's a Wonderful Life." But how did we get there? Maybe we should start at the beginning.

We left our intrepid adventurers last night in Palmyra. After posting, we went to look at the Joseph Smith farm and Sacred Grove, passing the Mormon Temple and Church along the way. This morning after breakfast with what appeared to be a number of "pilgrims" getting ready to worship, we set off.

Requisite pretty pictures here:

Passing through all the "port" towns, each with the canal neatly manicured. Straight banks and a narrow channel it's easy to forget that the whole project tied together a number of NY waterways. At points like in the above picture, it's much wider and the banks much more natural.

We stopped at a hotel in Newark NY for the facilities. Natan noticed this:

The sign instructs to flush up for liquid waste, down for solid. We decided not to ask. Tim, I don't know if you read this blog, but I think you had a story about this.

From there we moved from the canal path to the road. After a few miles on Bike Route 5, we ended up in Clyde. Ate at "Brickoven" a restaurant that used to be an industrial bakery.

Perfect stop for lunch. The corned beef hash I had wasn't great -- tasted like canned. Maybe that's just coming off of the hash I had at the diner in Tonowanda which was truly exceptional. Everything else was terrific and the staff and clientèle as friendly as could be.

From there it was on route 414 until we got to Seneca Falls. We did some road riding on our first day, but this was our most extensive. We had some stretches of six foot shoulders, but some of three and some of none. Since the roads weren't that busy it wasn't too nerve wracking.

Interesting though, to see how motorists treat you. Most motorists made attempts to slow down and shift at least partly into the neighboring lane (where oncoming traffic sometimes made this impossible). Every now and then, however, a car would blow by right next to us.

I particularly noticed a three car caravan that whooshed passed us. The first and third cars were no surprise -- a big honkin SUV and a red sports car. The car in the middle was an ice cream truck -- you know the kind. The small ones that park on a street corner to dispense Good Humor Bars. Complete with those big SLOW
emblems on it. In all fairness to the SUV's most of them gave us wide berth.

Forty two miles after we started, we ended up in Seneca Falls. It's noted for a number of things including the women's rights movement. There are a number of plaques noting important achievements of women including Amelia Bloomer, Elizbeth Cady Stanton, and others.

We walked part of the town, passing the church where the first equal rights amendment was proposed:

The Cayuga - Seneca canal:

And a neat sculpture garden:

After dinner, we walked back to our inn. So tired from the day, only 42 miles, but with a fair number of hills that we got a laugh out of this sign:

Only to realize that it was just poor typesetting:

Now back at the inn for a good night's sleep.

Today: 42 miles
Total: 177
Tomorrow: Syracuse

Weak wifi last night

2010-08-09T04:45:00.001-07:00

Weak wifi last night so I wasn't able too post a full report. Hopefully tonight from syracuse. 42 miles yesterday for a total of 177.

Brockport to Palmyra

2010-08-07T16:49:00.000-07:00

Beautiful weather today, just like yesterday. Forgot to mention yesterday that Clarence Birdseye started his quick freezing experiments in Brockport.

Let's start with the requisite canal pics:

And a picture of my trusty steed:

We originally figured we'd get lunch at Rochester -- about 18 miles into the ride. If we felt good, we'd try to push on to Pittsford. We were pretty excited when we saw:

Of course, the entire canal path in Rochester is in park so we rode right through without thinking about it.

At mile 25, we finally stopped for lunch.

Pittsford has a nice little park right on the canal. A Bike shop, a couple of other shops, and a few restaurants. We wanted to try the Crepe place, but long lines led us to a third day of medeteranian food. Not bad, and a pretty view of the canal. Besides, since we were eating outdoors, we didn't even have to lock up the bkes.

We were making much better time than our first two days, but today was a tough one for Batya. She just felt weak all day. On top of that, porta-potties were at a premium. Throughout the trip, we've been surprised by the cleanliness of the porta-potties on the canal route. We've been equally surprised by the irregularity of their spacing. Some times they're at every lift bridge, some time much further apart. Today, there was nothing from shortly after we set out up until lunch. In the afternoon, Batya was ecstatic to find:

Other than the scenic ride, not too much today en route. We did see the lift bridge in Fairport. It's unique in that it has no right angles and that the two banks are at different levels:

We also saw:

I'm also continually amazed at the design and engineering of the canal. We got to one of the locks just as it was about to go into action. Moving water from here:

To here, and then abck in just a couple of minutes.

We finished the day in Palmyra where the Mormons got their start. Known for it's "four corners" an intersection with a churh on each of the four corners.

All in all, a 50 mile day -- new touring best.

Total Miles: 135

Tomorrow we head off the canal and down to Seneca Falls.

Lockport to Brockport

2010-08-06T17:33:00.000-07:00

Day 3. From Lockport to Brockport.

Lockport is "famous" for it's locks -- the two channel 5 step ones. Brockport is famous for it's... brocks?

After a reasonable nights sleep and breakfast at Hambleton House, our BnB, we were off.

Here's one of the many lift bridges that cross the canal. Right now it's down. It's raised when a boat has to pass under. Back in the day, as there was much less road traffic, the bridges stayed in the raised position so boats and barges could pass. Stairways took pedestrians to the raised pathway to cross at any time. The bridge only had to be lowered when vehicular traffic had to cross.

The entire day was spent right along the canal providing for some very pleasant scenery:

And more lift bridges:

Crossing a canal aqueduct.

And here, this aqueduct is the only point at which a road passes under the canal.

And then to the northern most point of the canal:

About 22 or so miles in, we stopped at Albion for lunch. After riding around the historic downtown and seeing the cobblestone buildings, we stopped at a coffee shop for lunch, picking up one of their famous SchnickleFritz cookies for a snack later on.

Here's another lift bridge -- in the up position this time.

This lift bridge was the sight of a circus stunt gone terribly awry.

Making it to Holley NY, we realized that we've actually covered a fair amount of ground:

This was at a park that had a really nice waterfall, but alas, I don't have a shot worthy of sharing.

From there five more miles to Brockport, the Victorian Inn, showers and dinner at a Greek restaurant.

Mileage for the day: 47
Total: 85

This beats both our touring one day total of 42 from McKeesport PA to Connelsville, PA and two day touring total: Mkeesport PA to Ohiopyle PA, 58 miles. It doesn't beat our top day which was 88 miles -- the NY Century (75 mile ride plus an extra 13 afterwards).

Tomorrow to Palmyra.

Erie Canal - Day 2

2010-08-05T18:25:00.000-07:00

Surpassing our day 1 total of 1 mile wasn't going to be hard. We set out for breakfast. Rode down by the Niagara River and over the Rainbow Bridge. I was a little surprised not to find Asgard on the other side.

Back in New York, we continued on. Our first stretch was on Bike Route 5:

Paved but cragly and full of holes. Not very scenic either, at least not until we got closer to Tonowanda where we found the Seabee's memorial:

What else did we find in Tonowanda?

The Carousel Museum

Apparently, Carousel's were made in Tonowanda. One can learn all about them -- making the animals, the Wurlitzer organs, motors, construction, etc. Worth it if you're in the area.

After lunch at a local diner, the kind where everyone knows everyone and the hash is homemade and tasty, we finally found our way to the canal!!!!!!

We rode for miles along the canal with brief detours out to the road.

In this picture, all that green is actually on the canal. It's water chestnuts waiting to be harvested.

After a stop at the Amherst museum for bathrooms and a cold drink of water, we continued on. A few miles later,
we were in Lockport. Our destination for the night. Lockport is best known for having a two channel five step lock. One side has been replaced with a two step lock and the other is no longer functional but it's still pretty neat.

From there to our BnB:

Pizza and pasta for dinner, and now for a good night's sleep.

Total miles for the day: 37 for a grand total of 38.

Tomorrow: 42 miles to Brockport.

Erie Canal Day 1

2010-08-05T18:07:00.000-07:00

Yesterday we started on a 12 day adventure. From Niagara Falls, Ont to Albany, mostly along the Erie Canal Tow path all by bike. A little more ambitious than our four day excursion outside of Pittsburgh last year.

Bright and early we set out -- at Penn Station by 6:00am. That's where we had our first scare -- the Amtrak agent said we couldn't bring out bikes. Amtrak policy say's otherwise (folding bikes that fold to within a certain size are allowed at any time according to their on line regulations. We also checked by calling). The agent checked and we were allowed to board.

]

After a long day on the train including about an hour waiting for customs, we got off at Niagara Falls, Ontario. After checking in to the hotel, we went down to the falls. Had dinner at an OK middle eastern place -- good Schwarma, so-so falafel.

We then walked back to the hotel for the night.
Total milage: 1 (.5 from home to Penn Station and .5 from The Niagara Falls station to the hotel).

We did walk 2 to 3 miles though.

Circumnavigating the Island (mostly)

2010-06-20T17:19:00.000-07:00

Been a while since my last post but summer's coming so I think I'll have more time and energy. For today, a break from CS and Education issues and something on one of my other passions, bicycling.

Having not gone on a substantial ride for a while, yesterday, we decided to do a modified circumnavigation of NYC. Starting from home, we rode east over to first avenue. From there North...

First stop, the UN. Here in front of the St. George and the Missile Dragon sculpture.

Typically NY, the first guy we asked to take our picture said no.

At 84th street, we made our way Carl Shurz park. A beautiful little park on NY's upper east side. Home to Gracie Mansion and a number of quiet spots.

Here, along the bike path, you can see the Triboro bridge (no, not the RFK bridge) in the background as well as the Hell Gate Bridge, that's the one in the background. It served as the model for the Sydney Harbour bridge in Australia.

Unfortunately, the waterside path ends at about 120th street or so, so we turned into Harlem:

A Hariet Tubman monument

and Hamilton Grange.

Up at 155th, you can get back by the river by the Harlem River Drive. You can see in the distance both the Highbridge aquaduct as well as the Highbridge water tower:

At the north end of the Harlem River Drive bike path is Swindler's Cove. One of the quietest, most beautiful secret nooks in Manhattan:

From there, up to Spuyten Dyuvil. Here from Inwood park with a view of the Henry Hudson Bridge:

Having reached our northmost point, we headed south. We of course had to stop at the Little Red Lighthouse by the Great Grey Bridge:

From here, it was a quick stop at Fairways and then home.

About 27 miles total on an amazingly beautiful day.

Next week we're thinking of riding across the GWB and into NJ.

Flatbreads

2010-05-02T17:09:00.000-07:00

I made chapati the other day. Based on a couple of recipe requests and the fact that this blog has been dormant for a while, I thought I'd post the recipe here.

To start -- Chapati is an Indian flatbread. I guess what I made is technically Pulka but it's really easy to make and quite tasty.

Ingredients:

2 cups whole wheat flour
1 cup water
1 tsp salt

Mix all the ingredients together to form a dough. Don't add too much water (I did this time) or it will be hard to roll the dough. Use a spoon at first but then use your hands.

The dough should be soft and maybe just a little sticky:

Knead the dough for a few minutes then wrap in plastic wrap and rest for at least 15 minutes or up to a couple of hours.

Now, head a griddle or fry pan to medium high heat (I set the electric griddle to 400 degrees).

Separate the dough into eight pieces and roll them into balls.

Roll a ball out and place it on the griddle.

Cook for about a minute, then flip and cook for another minute.

Now the fun part -- take the bread and put it over an open burner:

This will cause the bread to puff up and parts will blacken.

Remove from flame and eat.

Sorting from the top and from the bottom

2010-03-14T16:21:00.000-07:00

Sorting from the top and from the bottom

I've been meaning to write this post for a couple of weeks, but sometimes life just gets in the way.

I've always thought it important to arm students with as manydifferent tools with which to attack problems as possible. As such,the courses I teach use a number of different languages, eachhighlighting a different paradigm and thought process. The hope isthat by the end of the sequence, they can look at problems from manydifferent angles.

In my advanced placement classes, we recently studied sortingalgorithms. It think the quicksort is a good example of a problemthat can be looked at from multiple points of view.

In my experiences talking to teachers and students who cut there teethusing languages like Java, C, or C++, much of the discussion deals withthe actual partitioning of the array. Comparing elements, swappingthem and arriving in the middle. One might end up with something likethis as a first cut:


 1:  public void qsort(int[] a,int l, int h)
 2:  {
 3:  if (l>=h)
 4:    return;
 5:  
 6:  /* Just use lowest index as pivot for now */
 7:  int pivot = a[l];
 8:  int low=l;
 9:  int high=h;
10:  
11:  /* partition the data set around the pivot value */
12:  while (l<=h)
13:  {
14:    while (a[l]<pivot)
15:      l++;
16:    while (a[h]>pivot)
17:      h--;
18:    if (l<=h)
19:    {
20:      int tmp=a[l];
21:      a[l]=a[h];
22:      a[h]=tmp;
23:      l++;
24:      h--; 
25:    }
26:  }
27:  
28:  /* sort items below and above the pivot */
29:  qsort(a,low,l-1);
30:  qsort(a,l,high);
31:  
32:  }

A fair amount of time and detail is spent dealing with the low levelmovement of data within the array . This is important – good stuff,but it takes the emphasis away from the higher level elegance of thealgorithm.

The quicksort can be described as:

If the size of the list is <= 1, return.
1. Select a pivot element
2. Generate the list L of items smaller than the pivot
3. Generate the list H of items larger than the pivot
4. the sorted list is qsort(L)+pivot+qsort(R)

Having seen some scheme in their intro class, our students have a toolwith which we can describe the quicksort in terms much closer to thedescription (allowing for the fact that this doesn't deal withmultiple values equal to the pivot correctly):


 1:  (define makefilter
 2:    (lambda (op x)
 3:      (lambda (n) (op x n))))
 4:  
 5:  (define qsort 
 6:    (lambda (l)
 7:      (cond ((null? l) '())
 8:            (else (append (qsort (filter (makefilter > (car l)) l))
 9:                          (list (car l))
10:                          (qsort (filter (makefilter < (car l)) l)))))))

This allows us to discuss the quicksort at a much higher level andfocus on things like selecting a good pivot or the analysis of the runtime. I believe this makes it much easier to really understand what'sgoing on.

Having discussed it in this functional context, we can also look atthe same thing in a scripting language such as python:


1:  def qsort(l):
2:      if len(l)<=1:
3:          return l
4:      else:
5:          return qsort([x for x in l[1:] if x <= l[0]]) + [l[0]]+\
6:              qsort([x for x in l[1:] if x > l[0]])
7:

Again, the focus is on the algorithm, not the array or listmanipulation.

Looking at the problem from both the more abstract side, which in thiscase functional languages allow, and the more concrete, as we did inJava gives our students more tools with which to attack problems.

Just some food for thought.

What's Next

2010-02-18T15:34:00.000-08:00

Just a short follow up on the last post.

In thinking about how I frequently programs, once I have a plan, I work on one part of the project, and then ask myself "what's next?" That is, what is the next step towards completion.

It reminded me about a guest speaker we had a about a year and a half ago at one of our "professional development" days. For the past two years, our school has had "writing across the curriculum" as one of it's goals. While it's a laudable idea, I find the rationale for this goal to be poorly communicated to our faculty and the implementation weak at best.

Regardless, the guest speaker, William Zinsser, made a few good points.

The most important reason for most of us to write is to convey ideas or arguments. In short, communication. Many students have problems organizing and ordering their thoughts and as a result, their writing is all over the place. Zinsser simplified it to the following:

What does the audience know?
What do they need to know next?

That drives your next sentence. You continue this 1-2 punch until you've communicated your ideas.

This makes loads of sense, but here I was 40 years old and it was the first time I heard writing explained this way. What really struck me, however was that this concept wasn't new at all. Every ninth or tenth grader goes through this process time and time again.

Think about geometric proof. We have some given information and a conclusion we wish to prove. At each step along the way its:

What do we know so far?
What's the next step to get us closer to the conclusion?

Same idea.

The same can be said for program development.

Of course this makes tremendous sense since all thee things: writing, proof, and programming, are methods of communication.

Just something to think about.

They teach programming, don't they?

2010-02-15T13:51:00.000-08:00

One evening, many years ago, when I was in college, I had an epiphany. Maybe not as enlightening as the epiphany I had while watching "The Mummy Returns" many years later, but that's a story for another day.

While working on some class project, I realized that soon, within a couple of years, I'd be working for a real company and I'd actually have to write code that REALLY works. Not just something that gets past the grader, or answers all the test cases. Something well designed, well written, maintainable, and reliable. Scary thought.

I've thought about this a lot since I started teaching computer science. We teach programming languages, algorithms, and assign projects. Maybe the students hear something like "comment your code," or "use good variable names," but we never really give them the tools to take a project from description to completion.

Too often young programmers rush to the keyboards and write copious amounts of code without any plan and with little discipline. In short they do everything they can to set themselves up for a difficult road ahead.

There are probably a number of reasons for this. When we teach introductory programming, assignments are so short and simple that we can't easily model good programming techniques, and if we do, it's difficult to get students to "buy in" since it's hard for them to see the value. As complexity increases, we're faced with limited time to actually cover the prescribed course content, leaving little room for a protracted unit on "program development."

I'm certainly not going to be so bold as to say that I have the answer to the problem, but I've tried some things to help address it.

We'll take a few class days to take a project from beginning to end. Something that can be done incrementally but isn't particularly difficult.

This semester, I attempted this with my AP students. We wrote a series of text filters in Java. I lifted the topic from Kernighan and Plauger's "Software Tools." We wrote versions of character count, word count, detabbing a file, run length encoding and a simple version of tr. Nothing too heavy, but it allowed us to focus on the development piece rather than coming up with clever algorithms and data structures (which is what the rest of the class is for). The problem may be a little contrived, but I hope the benefits outweighed any issues with the choice of problem.

We start by talking about the importance of understanding the problem, which includes finding out what "the client" wants and not making our own assumptions. Some times, I try to leave a little ambiguity to give us a platform to discuss the "what the client wants" issue.

From there comes design, which might be mixed with writing some code to make sure we understand certain aspects of the problem and the environment we'll be working in.

Once we have a design and a plan we can start incremental development. This is what I think is most important for the youngsters. I try to model and emphasize the idea of coding one "concept" at a time. Frequently testing that concept and only moving on once it's completed.

I'll also talk about things that have worked for me along the way. I always like to put consistent comment blocks at the top of my functions, trying to keep functions a "screen length" or shorter, my preferences for naming, indentation, etc. Of course, I'm careful to emphasize that my way works for me, but it's just one approach. I try to present alternatives when possible.

Other ideas I try to emphasize is actually reading ones code and having others read it. Last semester I experimented with "pair programming" and while I have no idea how good it is as a professional development technique, I like it from a pedagogical point of view.

I think presenting these ideas while actually developing the project helps to drive in the concepts.

I'd like to think adding units like this helps to develop stronger programmers. Any teachers out there -- your thoughts?

In an unrelated note, yesterday was valentines day. We don't really do anything to celebrate it, but in anticipation of her new loom, Devorah had to clear off some room in the apartment. She stumbled upon love letters sent between my parents back in the fifties. If you'd like a small taste of the past, you can see here post on squidknits here.

Although we have gained all this immediacy with the electronics age, it sometimes feels that somethings been lost.

Subversion for Homework part II and the start of the new term

2010-02-01T16:30:00.000-08:00

Starting the new semester tomorrow and I've got a whole bunch of interesting topics to blog about. Some about pedagogy, some technical, and some that I can't really catagorize.

For now, though, just a brief follow up on using Subversion for homework collection.

The basic model used in New York City for teacher improvement and evaluation is the official "observation." Either your supervisor or the principal sits in on one of your classes. Afterwards you meet and discuss the lesson and a report is written up. Basically, there are two possible outcomes: satisfactory or unsatisfactory.

Untenured teachers are generally observed three times a semester. Tenured teachers, once a year.

In all cases, this system is severely flawed. The supervisor sees a 40 minute snapshot out of context and is supposed to evaluate the teacher and make recommendations for teacher improvement. It's generally of limited value at best.

Because of this, years ago, I started to ask my students to evaluate me. For quite some time now, I've used a custom written web app that allows students to complete long questionnaires over a period of weeks. The system allows me to know who submitted an evaluation while maintaining anonymity.

I've found these evaluations to be incredibly valuable and I've used them to try to improve my classes and my teaching over the years.

Having just wrapped the semester, I've gone through my students responses and the vast majority liked using subversion for homework. As I figured, some felt that it was a little confusing at first and there was a learning curve but most felt it was either as good as any other method and many said it was superior.

This combined with the fact that it makes me more efficient confirms that it's a win.

It was also interesting that I had hardly any suggestions for alternative ways of collecting homework.

Recently, I've been using Git for my personal development work and I'm planning on experimenting with it in one of my classes, so we'll see how that goes.

Now, on to the new semester!!!!!

Subversion in the classroom

2010-01-19T16:47:00.000-08:00

Ok, not subversion, rather subversion, the version control system.

I've used subversion as a way for students to hand in their projects for years. I haven't used it with my intro classes as I think the learning curve is a little steep and the benefits few, but for A.P. and beyond (juniors and seniors) it's worked very well as a method of collection and I think it's good to get the kids in the habit of using versioning systems.

A versioning, or revision control system let's an individual frequently save versions of their files, in our case, on a central server. One can easily go back to earlier versions as well as manage changes made by multiple developers. Once one's in the habit of using a revision control system, it can greatly improve productivity.

For my classes, I would create a repository for a project, give the kids a little version control primer, and they would create projects in the repository.

There are usually a few bumps in the road.

At first the kids go kicking and screaming. They create the repository, and neglect it until the last minutes. I'd wake up on a project due date, check out the repository and seem maybe 4 out of 60 projects only to see them mystically appear as the closing time approached.

As we move through the year and work on more projects, things get better.

Students start to update their projects more frequently. Not as frequently as I like, partly because SVN gets really slow on our system, but it's still an improvement. Invariably, it saves a student or two when they accidentally delete all their files. Also, when things become a real mess, being able to go back a few versions is a godsend. A much better alternative than what they had to do in the past, which was restarting the entire project.

What I find really interesting is how wonderful a tool svn is from my point of view as an educator.

By looking at the log files, I can see who made changes and when. By looking at the diffs, I can look at the projects progress much as an english teacher might look at drafts.

Version control for projects turns out to be a win across the board.

Recently, I've been using SVN for homeworks as well. Homework collection has always been difficult for me as I'm disorganized and forgetful. SVN has made things much easier. At the start of the semester, I made a homework repository for each student. They then check it out at home.

Whenever a student does a homework, he or she just names it according to our conventions (HW1-name, HW2-name, etc.), put it in their checked out repository, add the file(s) and commits. With tortoiseSVN under windows it's trivial.

This lets me easily see all of the homeworks for a student as well as all submissions for a specific assignment. Again it's an overall win.

Next semester I'm going to be experimenting with GIT as a replacement for SVN.

If you're looking for a way to collect and track assignments, I'd highly recommend using a revision control system.

Cold Weather Commuting

2010-01-15T04:31:00.000-08:00

That's me with my trusty Bike Friday New World Tourist. Love the bike. Love riding. It's the fastest, most pleasant way to get around the city. My commute by bike, door to door is 12 minutes. Subway is 20 - 25. Walking about 45.

One certainly can't let winter weather get in the way.

I've got the body covered with my Assos Fugu jacket. With just a cheap long sleeve duofold shirt it's great to about 16 degrees. It feels a little boxy off the bike, but as soon as you're riding, it fits like a glove. Expensive, but well worth it.

My real problem has always been my hands. Especially on a short commute when I don't have time to generate body heat.

Most recently, I've been using Pearl Izumi Inferno Gloves. They're ok, but sub 20 degress, they don't do it, particularly since I like riding the hoods where I'm right up against cold metal.

Last year, my wife made a wonderful discovery....

Moose Mitts!!!! They velcro on over the handlebards. You stick your hands in when you ride.

This year, AMF Threadworks designed a set that fit on drop bars. Two weeks ago my set arrived!!!

Last week we were consistantly 20 degress or below in the mornings, I used these $10 hytrel gloves from campmor:

Along with my new moose mitts:

They were terrifice. My hands stayed wram and I have the benefit of being able to regulate temperature by pulling my hands up to the cross bar or out entirely.

If you ride in the cold, check out Moose Mitts!!!!

Towers of Hanoi

2010-01-10T13:53:00.000-08:00

Closed out last week teaching the Towers of Hanoi. It's a wonderfultopic. Not because it's so interesting in and of itself, but as aplatform from which you can explore any number of interesting topics.

Many books appropriate for the AP (AB) curriculum mention the towers,but to my knowledge most only scratch the surface. I randomly grabbedtwo books that I consider good from the shelf before writing this. Onethat I actually use when I teach AP comp sci and another moreappropriate for a follow up course. Both discuss the towers, butmerely show a solution and talk about the run time a little.

So manypossibilities left out.

I usually do these lessons with my sophomores but since many of my APstudents (juniors) hadn't ever seened the problem, I felt it was worthcovering.

By looking at a few small examples, 1 disk, two disks, three disks,four disks, it's easy to notice the symetry in the solutionsultimately leading the this short routine:

 1:  hanoi(n,src,dst,tmp) {
 2:    if (n==1)
 3:      System.out.println("Move from "+src+" to "+dst);
 4:    else
 5:    {
 6:      hanoi(n-1,src,tmp.dst);
 7:      hanoi(1,src,dst,tmp);
 8:      hanoi(n-1,tmp,dst,src);
 9:    }
10:  }

Now, the fun can really start:

We want to talk about the correctness of our algorithm and also howmany moves it will take, that is, the run time. First, we'll useinductive ideas to show our algorithm is correct. This "proof" (we doit somewhat informally) can be enlightening. As sophomores, the onlyproofs students have seen are those statement/reason things they do inmath class. Here we can introduce them to the idea that proof is justan "irrefutable argument" and apply it in a more practical setting.

From there we look at run time, that is, how many moves will it taketo solve the n disk problem. It's easy to see the pattern of T(N) = 2T(n-1)+1. Students will usually see that we can rewrite thisas T(N)=2^N-1 which we can also prove by induction.

Now we can see the ramifications of the run time. At 1 million movesper second, it works out to close to 600,000 years. This in and ofitself is revealing, we can't just "get a faster computer." Here wecan discuss Moore's Law and the physical limits on our computers,making sure to make appropriate reference to Grace Hopper and hernanosecond.

This leads to a discussion alternate approaches such as parallelprocessing, but that doesn't work if our problem can only be solvedsequentially.

The rest of the class is used discussing other hardproblems and other approaches including heuristics, probabalistic,randomized, and anything else that comes up.

So, there you have it. From this one simple problem we get tointroduce students to:

Alternate forms of proof (specificall induction)
Intractable problems
Unsolvable problem
Moores law and the limits of our computing power
Alternate approaches to computing
- Parallel programming
- Protein based computers
- Randomized algorithms
- Probabalistic algorithms
- Heuristics

Who is this man?

2010-01-07T17:43:00.000-08:00

Who is this man?

I showed this to Devorah last night and she immediately said "Hey, that's the metal filing guy!!!" Yes, you got it -- Wooly Willy!!! Everybody's favorite party toy.

Why did this come up? Well, yesterday, Rick put this together at work. So much for any productivity after that.

It's amazing all the time sinks you can throw together with just a few lines of code and NetLogo.

Talking Shop

2010-01-06T17:32:00.000-08:00

During my first few years teaching computer science, I frequently feltisolated. As pretty much the only CS guy I really didn't have any oneto "talk shop" with. It's hard to bounce pedagogical ideas off of yourcolleagues when they teach subjects that are tangentially related, atbest.

I now consider myself extremely fortunate that I have four terrificfriends and colleagues teaching CS with me. Now we have the sameadvantage that other teachers have enjoyed for years.

Today I started one of my favorite topics in my AP classes,recursion. Our students have already done recursion during the schemeunit of our intro class so today was at some levels, a review. Most ofthe students were fine with the basic concepts, but I wanted to makesure they had a solid foundation before we moved to more advancedproblems.

I realized even though I "got" recursion back when I was starting outas a CS student those many years ago, no one ever really explained howthe call stack worked. When you're calling functions and methods all over the place, how does the system know to return to the right place at the right time. It was alluded to when we expanded a recursion:

fact(4) –> 4*fact(3) –> 3*fact(2) –> 2*fact(1) –> 1*fact(0) –> 1

but never in the general sense of function calls. I thought it mightmake sense to try to "demystify" the computer and explain how thingsreally worked.

I outlined a basic memory layout, stack, heap, data segment androughly defined a stack frame (storing parameters, local variables,and a return address). We then looked at a code snippet such as:


a()
{
  b();
  c();
}

b()
{
  c();
}

c()
{
}

main()
{
  a();
  b();
}

and traced through the stack. We then did this with a couple of simplerecursive examples. Only time will tell if this was helpful, but Ithink it was worth the time.

What I particularly enjoyed was later that day when I was talking shopwith my fellow AP teacher. He wasn't planning on explaining the stackin this kind of detail but he liked the idea and planned to use thatpart of my lesson. I look forward to hearing how it went.

I have likewise borrowed ideas from his and our other colleaguesclasses.

Any CS teachers out there, I'm sure we'd all love to hear classroomtechniques that have and haven't worked.

First Day Back

2010-01-04T17:09:00.000-08:00

First day back after a break is always hard. By the last day ofvacation, I'm actually sleeping a little later and shifting the bodyclock back is rather harsh.

It's tough enough getting started again, but it's even worse whenyou're thrown a curve ball.

I got in at my usual 7:00, made my coffee, and started getting mylessons ready for the day. At about 7:30 we lost power in half of theroom. Unfortunately, it was the half with the CS servers. The machinesthat provide log in and file services as well as svn, our web server,mail server, wiki and other services.

Now, on top of my teaching duties (four classes of 32 students andanother of about 20), I basically run the computer services for our CSprogram. I used to do the whole network, but I stopped that a fewyears ago. I receive some help from colleagues, but it's still mostlyme.

For our CS program we have two Linux labs of about 31 computers each(all running Linux) and a bunch of servers running the same.

After spending about 20 minutes to find the circuit breaker, mostservices came back up. Terror struck 10 minutes later when we saw thatall of the students home directories had disappeared!!!!!

After a brief period of panic and a few stressful minutes of scouringfile systems for evidence of the missing directories I found theproblem. The answer, as with so many other problems, is that I wasbeing an idiot. About a month earlier, I had installed a new drive forthe student directories. I had mounted it, but neglected to change thefstab file. This is what happens when you have to do all your sysadminwork on live systems in brief periods of time between classes. When welost power today, the old drive was mounted, not the new one. It'sfixed now.

It would be nice if there we actually had people to run our systems,but since that's not going to happen, I've spend time over the yearsto try to make the whole thing somewhat do able. Using common toolssuch as NFS, NIS, Apache and the like help, and we've currently movedto using kvm for virtual machines so we can easily experiment with newsystems and cleanly and have a one "machine" per service mentality,but system administration still can't really be done as a part timejob.

Any one out there have any war stories or suggestions as part timesysadmins?

Looking for interesting questions

2010-01-03T10:25:00.000-08:00

For the winter break, I assigned this set of A exam questions(actually, just the three that don't deal with the case study) to myAP classes. I wanted to assign something that wasn't particularlyheavy but I didn't want my students to forget everything over break.

As with most AP exam questions, they're long, wordy, and somewhatbrain dead. They take a long time to read, but they frequently takeyou step by step through what they want you to do.

I remember the first time I really thought about this. It was backwhen the exam was given in Pascal. The curriculum required thatclasses cover one of the nlogn sorts but didn't specify which one.One of the free response questions literally walked the students, stepby step, through the merge sort. Part one had them split an array into two parts, part two had them write a routine that merged two sortedarrays (and explained step by step how to do it). You could get aperfect score and still know nothing about the algorithm, or even aboutwriting a recursive routine (since the question told you exactly whatto do).

I hate these types of questions. The exam tests coders, not computerscientists. Programming competition problems (such as from the USACO)are much more interesting, but from a beginners point of view theyhave their own problems. Beginners might not have enough tools toattack them, and at times they're all or nothing – they're not set upto develop a simple, working solution that you can then improve on.

So, I'm always looking for interesting questions for mystudents. Problems that a student can attack with a minimal skillset, but can be refined through analysis or upon studying moreadvanced techniques.

I guess the first problem of this nature that I usually do with my AP students, usually deals with counting frequencies of test student testscores, identifying students by their four digit ID number. Moststudents start by creating a huge list all the tests for all thestudents, but some, and soon all, realize that by using the ID numberas an index into an array, they can solve this type of problem muchmore efficiently. Looking at this technique early also sets the stagefor looking at topics such as radix sorting and hashing later on.

This weekend I stumbled upon this problem and we'll probably look atin in class some time this week. I like it because you can easily geta naive solution, but it lends it self to a step wise refinement thatworks well in the classroom.

A few years ago, I also discovered a wonderful article by David Ginat,titled "Effective binary perspectives in algorithmic problem solving"which you can get if you are an ACM member here.

Both the stuff in Ginat's piece and the bowling ball article are nicebecause they can be handled naively with brute force approaches usingarrays, but with a little cleverness you can do much better.

Of course, as students progress through our classes, we have moreflexibility as to types of questions. For example, once we do searchand other recursive algorithms a few weeks from now, I can presentproblems that lead to dynamic programming solutions.

I'd love to hear any interesting accessible problems you've comeacross in your computing careers.

Welcome

2010-01-02T11:36:00.000-08:00

Over the past twenty years or so, I've mulled, discussed, and argued various aspects of education, computer science, and of course computer science education with friends, students, and colleagues.

This past summer, I had the privilege to get to meet and briefly work with comp sci educators from around the country and started to thing that there were other like minded people, but we didn't have a forum with which to communicate.

I also started to think that maybe some of the things I've discovered over the past twenty years might be useful to some one if only it were available.

So, there you go. The plan is to regularly post about items of interest that I've come up with ranging from pedagogical techniques, to facilities management, to interesting class topics, to anything else that seems relevant. I'd imagine that some of my other interests, notably food, biking, and family will also creep in.

Hope others find this interesting and relevant.