Erie Canal Day 1

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)

 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

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:

1. 2 cups whole wheat flour
2. 1 cup water
3. 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

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

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

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

In my experiences talking to teachers and students who cut there teeth using languages like Java, C, or C++, much of the discussion deals with the actual partitioning of the array. Comparing elements, swapping them and arriving in the middle. One might end up with something like this 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 level movement of data within the array . This is important – good stuff, but it takes the emphasis away from the higher level elegance of the algorithm.

The quicksort can be described as:

1. If the size of the list is <= 1, return.
2. 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 tool with which we can describe the quicksort in terms much closer to the description (allowing for the fact that this doesn't deal with multiple 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 and focus on things like selecting a good pivot or the analysis of the run time. I believe this makes it much easier to really understand what's going on.

Having discussed it in this functional context, we can also look at the 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 list manipulation.

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

Just some food for thought.

What's Next

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:

1. What does the audience know?
2. 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:

1. What do we know so far?
2. 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?

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

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!!!!!