C'est la Z

Musing about education, computer science and maybe a few other miscellaneous topics.

Circumnavigating the Island (mostly)June 20

 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 t

FlatbreadsMay 2

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. 

Sorting from the top and from the bottomMarch 14

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:

What's NextFebruary 18

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.

They teach programming, don't they?February 15

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 th