Back to school last Thursday after almost two week off. Twenty four hours later - Snow Day. I know this sounds a bit hokey, but I really would have rather had school. I love a good snow day as much as the next guy, but after a big vacation, I was really ready to get back to work with the kids.

Saturday, hacking sessions were set to resume. Being in Manhattan, getting around was pretty easy but we've got hackers from all over the city from Staten Island to the Bronx. Needless to say, some boroughs were easier to get around in than others.

So, we were a small group - we were down two instructors and a TA but Batya and Zach were in from college and helping out so instructors actually outnumbered students!!

What did we do? Since the hackers are just starting on their projects, this was a great opportunity to work one on one with them. Two of us went over Javascript and SVG as an alternative to the HTML Canvas, Zach worked with a couple of people on a Markov chain text generator and so on. Even though the turn out was low, I'm really glad we got back to business. Weather permitting, we should be back at full capacity this coming Saturday.

I think it's finally time to start talking to them about git.

I've never been one for New Year's resolutions.

If I'm working on something specific, I might set a goal to finish it, but the idea of goals for a year never struck a chord with me.

It's one of the things that I find absurd about the current teacher rating system - I have to decided on my three goals for the year. I always have one goal with respect to my profession - to be better at it.

In any event, even though I don't have specific overall goals for me, there are some projects that I plan on pouring myself into this year.

The year closed with a lot of national hype over CS Ed. What remains to be seen is where we go with it.

I'll continue to try to work within the system - try to convince the new administration that supporting and replicating Stuy CS is something worth doing but I've been burnt enough to know not to put all my eggs in that basket.

Consequently, I'm hoping to put a lot of time into CSTUY. We're just about a year old and it's been a slow road but we're making some real progress - and this is just as a grass roots organization - it's just us and the StuyCS Alumni family.

So, what are the plans?

More Hacking Sessions

We started Hacking Sessions in October. Twenty New York City public high school students getting together to geek out and do CS every Saturday. We're off to a great start but there's a lot of work to be done. We'd love to get more students involved in the coming semester.

Start Summer Hackers

This is the big effort. A summer program. Since we designed and implemented Google CAPE NYC back in 2010, I've known the effect you can have with a strong summer program taught by master teachers.

We've got the teachers and the program, but it's still going to take a lot of work.We have yet to finalize on a location (we have a tentative offer for space but I'm hesitant to say anything until it's more concrete) and we have to do it early enough so that we can get to the students.

If we can get CSTUY's Summmer Hackers off the ground I'm pretty sure we can use that to launch a community of both hackers and teachers just as we've done at Stuy.

Get more people involved

I said that so far CSTUY has been grass roots only. In order for us to succeed, we'll need to grow our community. The hope and plan is to get the NY Tech community behind our efforts. I'm hoping that when they see us taking our proven programs out from Stuy to the greater public they'll come out in droves.

At least that's the hope.

So, those are my goals for the year.

Should be exiting.

We're practically at the close of 2013 and it's high time I wished everyone wonderful things for the year to come.

It's also time for a new look to this blog.

Why the rewrite? Partly because I was tired of the look, but mostly because, when I put it together, it was the first time I used that toolset and was just figuring things out.

I'm still no expert, but I thought it was time to clean things up.

It's still a jekyll generated blog hosted on GitHub pages but instead of using Twitter Bootstrap I decided to use Ivory. It's much smaller and only does the basics. Even the menu I'm using was the result of some online searching for CSS stuff. I figure that this way, I'll actually learn more about styling.

This should be an interesting year. I've got a number of projects that I'm working on. Some within Stuyvesant, some revolving around CSTUY, and some I can't talk about right now. Hopefully I'll be able to write about some of them in the coming weeks.

I'm also hoping to write more this year. I only posted 30 times this past year. On the other hand, that's up from 18 times in 2012 and only 4 posts in 2011.

In addition to updates on CSTUY, pedagogical posts and the occasional rant, I'd like to do a series on how I use tools like the Linux shell and Emacs.

We'll see how things go.

For now, I wish you all a happy and healthy new year.

In spite of the Java based annoyances I mentioned last time, I decided to go ahead and do Radix sort with my AP students. I usually don't cover it in AP Computer Science, but I like getting the kids to think about using arrays as buckets as it's a new way of thinking for them and it does give a non-trivial application that combines ararys and ArrayLists.

It's a nice little algorithm. You start with an Array of integers:

Then, place them in buckets based on the least significant digit:

We then copy the numbers from the buckets back into the original array, keeping the order of the buckets (0->9).

We then repeat this process on the 2nd least significant digit:

And so on until we're done:

It's a nice algorithm to teach on a number of fronts.

First, we get to combine Arrays and ArrayLists. Since we'll always have 10 digits, the "bucket list" is of fixed size, while the individual bucket lengths vary. This leads to the Array of ArrayLists and we've got a single platform to compare and contrast the two. Which is better when and why?

The algorithm itself is also worth talking about.

• It's relatively simple - we did it by hand before implementing it.
• It's got some history worth discussing.
• There are a number of other questions we can approach
• How can we deal with negatives?
• What about strings?
• Will it always work (what about floating point numbers).

Finally, we can talk about speed -- they're testing that now and we'll discuss our Radix sort vs the built in Arrays.sort() on Monday.

We'll do the n^2 and nLog(n) sorts a little later, but I think this was a detour well worth taking.

Java's never been my favorite language either for using or for teaching.

As a programmer, after starting with languages like Fortran and Pascal, I really cut my teeth with C. More recently, Python has been my go to language to get real work done.

From a teaching point of view most languages have good points and bad ones. When the AP class went from Pascal to C++ I lamented losing the simplicity and the low cost of entry. On the other hand, C++ gave us objects (not that I'm a big OOP guy), separate files, the ability to use tons of real world libraries and more.

Moving to Java simplified things in a number of ways but removed memory management. If we didn't teach that along with the stack frame in our Systems class, I think our kids would be missing something very important.

I was reminded of some of Java's limitations as a teaching language over the past couple of days.

As posted earlier, I had my AP students create their own class to mimic the Java ArrayList. Before introducing the ArrayList in Java, I wanted to introduce generics:

public class myList<T> {
  T[] data;
  public myList() {
    data = new T[10];
  }
  // much more not shown 
}

Turns out, you can no longer do this.

After doing some searching, there does appear to be a way to get this effect but it was certainly not something I wanted to do with my classes. I was looking for something more pedagogically sound - an easy way to show the concept and a way to springboard to an ArrayList.

Oh well...

So, we finished ArrayLists and I was mapping out a plan for Monday. I thought Radix sort would be cool -- we already introduced using an array to tally votes when we did the mode. This seemed to be a natural extension. It would combine Arrays and ArrayLists and illustrate when each is appropriate.

First the kids would set up an array of 10 buckets, each being an ArrayList:

public class Buckets {
  ArrayList<Integer>[] buckets;
  public Buckets() {
    buckets = new ArrayList<Integer>[10];
    for (int i=0;i<10;i++)
      buckets[i] = new ArrayList<Integer>();
  }
  // much more not shown 
}

Unfortunately, Java type safety once again reared its ugly head. OK, maybe not ugly to a programmer, but ugly to a teacher. You can't do it. You can do it with an old school ArrayList without the generic: ArrayList[] buckets = new Arraylist[10]; but of course, this leaves you open to type mismatch problems.

Once again, Java provides a convoluted workaround that might be fine for a professional programmer, but for a student, it would be nuts.

I might go ahead with the Radix sort lesson anyway, we'll see, but it would be nice if I could teach this level of course without having to fight the implementation language.

The subtitle of this post is:

and why my students are going to hate me tomorrow.

When my good friend Gerry Seidman talks to my classes, he frequently says "never use a data structure or algorithm you couldn't build yourself."

This doesn't mean that you have to write everything from scratch, just that you should have some knowledge as to what's going on under the hood. I find that all too often young programmers just rely on APIs and libraries and really don't know how their computers and programs are working.

And it's never too early to start.

We've been spending time talking about arrays recently. Now, most of my students have some exposure to Python and so we started talking about the flexibility and power of the Python list vs the limited facilities of the Java array.

How to solve the problem and make Java easier to work with? Let's write our own list class. We started simple:

public class myList {
  private int[] data;
  private int numItems;

  public myList() {
    data = new int[5];
    numItems = 0;
  }

  // append to the end of the list
  public add(int d) {
    if (numItems >= data.length) {
      tmp = new int[data.length+data.length/2];
      for (int i=0;i<numItems;i++)
        tmp[i]=data[i];
      data = tmp;
    }

    data[numItems]=d;
    numItems = numItems + 1;
  }
}

from there we added functionality such as:

• Inserting in arbitrary locations
• Removing items from the list
• Searching for an item
• Setting the item at a location to a value

And of course we were also able to talk about things like refactoring out growing the array into a private method.

And tonight the classes are changing the internal array from int[] to String[].

Of course, what we're building is an ArrayList. Tomorrow we'll reveal that little fact and of course the classes will all hate me, but then, they'll really understand what's going on under the hood.

Week 5.

Last week, I lamented over the difficulties with only meeting once a week. We went over a log of new material last week and I was happy when today rolled around and the hackers would be able to start putting things together.

When writing a web app, you've got to know about all sorts of things - for us it's HTML, CSS, Python, and the microframework, flask. That's quite a bit, particularly when working with a group with a wide range of experience coming in.

So, what did we do? We put together two partial web sites.

One had all the Python code, but was missing the HTML and CSS.

The other had the HTML and CSS, but the Python logic was all missing.

It was our hacker's mission to fill in the missing pieces.

We liked the setup for a few reasons:

• Each Hacker came in with different strengths and weaknesses. With this project, they could start with something they knew (picking the part with the "hard part" filled in) and then moving to a more challenging piece.
• By looking at the other half of the project, they could find sample code for the pieces they were working on.
• The hackers also had last weeks code as a reference.

We also introduced the hackers to pair programming - something I love from a pedagogical point of view - but more on that in another post.

Overall I think the day went very well.

We also gave out our first assignment -- over the weeks, the hackers will finish up their projects - next week we'll demo and give prizes for the best.

We just finished week 4 of CSTUY's Hacking Sessions.

I'm really happy with how our hackers are doing - they're a great bunch and even if they don't realize it yet, are making great progress.

Meanwhile, as an instructor and program designer I'm noticing the differences between a once a week program and having a class every day (note - I'm not the sole designer or instructor. I have a great team - JonAlf, Sam, and Topher are three of the best teachers I've had the privilege of working with - this post, however, is based on my observations).

Once a week vs every day

This is a big adjustment. In class, we only have 40 minutes but we get it 5 days a week. Here we have 3 hours, but only on a single morning. This means we can spend time on a large activity but once noon rolls around, it's over.

If a student is confused, that confusion can fester for a week and by the time we get to the next session we might not remember to clear things up until the problem arises again.

They can run away

In class, I know I have my students for a full term. We can bore them or even annoy them a bit as long as we win them back.

Some of what we teach is boring. Other things are difficult and can be frustrating for students until we dedicate enough time for things to click.

When you know you have the kids all term, you don't have to worry about a bad day on your part or on the students. They'll be back tomorrow. Meeting with people every day makes it much easier to develop connections.

In a once a week voluntary program you have to be more careful.

We can't count on work over the week

I'm hoping that once we get a little further along the hackers will want to work on projects over the week. That said, we know that Hacking Sessions is extra curricular so when the hackers have big assignments, SAT exams and the like, we have to take a back seat.

So, the default for a Saturday program is that it's a partial restart every week. That's a challenge.

Communication is tough

This is the one that's vexed me most.

Since we're only meeting once a week, it would be really great if we can generate some online dialog in between. So far, it's been tough.

Even in class, over the years, I've had mixed levels of success with online communication. Some classes, some years, I've gotten great buy in to an online class community. The dialog is consistent, varied, and great. Other times, it's just the bare minimum.

In my classes I usually use a Google group but I'm becoming less and less happy with that as a solution. For Hacking Sessions we've been using Piazza so far but in spite of its popularity at colleges, I'm not feeling it. I find it both cluttered and limiting. I think we're going to try Vanilla forums next. It's pretty easy to host and fairly flexible.

I'm hoping that in a few weeks we'll get past the basic tools and onto some neat project and it'll be easier to encourage talk throughout the week.

Overall

So, this is a new challenge but a fun one - designing and implementing a once a week program. Bottom lining it - I think the hackers are doing great and we're off to a really strong start. We'll make some mistakes along the way but as long as we keep looking at what we're doing we can adjust as we move along we'll continue to build a great program.