From the day we filed the paperwork to create CSTUY, we knew we wanted to run a summer program. In fact, we started looking for a space during the 2012/2013 school year. We were hoping to run SHIP for the first time in the summer of 2013 but we all knew it wasn't really a realistic goal.

Our original plans required at least one classroom sized space, and up to three for full days for a month. We figured this would be a hard sell for a tech company, after all, what company is going to take a room, let alone three, off line for half the summer.

So, we turned to institutions of higher learning. I started talking to friends at a CS program in one of our city's colleges. They loved the idea of hosting a CSTUY program. Problem was that once the plans went up through the college channels, the administrative side wasn't as hot to host us. While the CS people really wanted us, the administrative side was perfectly willing to give us space as long as we paid an amount that really was much more than we could afford. To be honest, this really irritated me. Here we have a supposedly non-profit college that's supposed to support the community and the public good nickle and diming another non profit that really is trying to do some good.

We ended up speaking to a number of educational institutions across the city and the situation was the same. Sure you can have space. Here are our rates…..

Now, you might wonder, why not just use high school space? Because it was important to be hosted at what should be the "next level" for the participants.

In the mean time, I met Bill McAllister, CS Professor at St. Joseph's College on Long Island. He hosts a terrific annual high school programming competition. Bill referred me to David Seppala-Holtzman the Math and CS Chair at the Brooklyn Campus.

David and I clicked and one thing led to another and in the end, having overlapping visions and goals, St. Joseph's College in Brooklyn decided to host us.

I couldn't ask for a better partner. They provided us with all the facilities we needed from rooms for the classes, to lounge space, to access to the cafeteria (and got us a great rate on food to boot).

The whole St. Joseph's family made everything so easy for us. At one point one of our instructors commented "wow, this is such a friendly campus."

Without the help and support of St. Joseph's college, SHIP doesn't happen. It was a great partnership and we're looking forward to working together on SHIP 2.0 next year.

SHIP ended last week. So, how did we do? Time to look at outcomes.

Outcomes can be tricky. There are lots of programs out there and they all claim amazing results. Unfortunately, it seems to me, that everyone's so concerned with good PR that, well, you know, lies, damned lies, statistics.

First you've got claims like "learn how to make a mobile app in under n weeks." I always chuckle at this. If it was that easy, why do we have a tech talent shortage? I'm immediately skeptical of any program that claims that kids go from nothing to making full featured web apps or some amazing professional quality game in just a few weeks. Learning takes time. The only way you get these miracle results is by using frameworks, simplified tools, or scaffolding of some kind. True learning, retention, and the ability to transfer knowledge is minimal.

Then we have assorted stats. Here's one of my favorites.

Our students outperform other students who take APCS. We see this from screened programs. Now, I have no problem with screening – we do this at CSTUY, just don't imply that you're just taking everyone who applies. If you have an application or an interview, you're screening and starting ahead of the game. Since kids have to elect to come to our programs they certainly have a good deal of interest. So, what this claim is really saying is that a kid who likes CS enough to spend their summers and or after school time doing it is likely to do better than a kid who isn't going to spend this time doing CS. Big surprise.

So, how do we measure our outcomes.

We can start with the work the shipmates did. We use processing and the shipmates learned from the ground up. That is, they wrote everything from scratch. Some of the groups taught themselves how to use processing libraries if they needed facilities like a web API or accessing a camera, but since they built everything up from simple statements, if they successfully completed good projects, we could be pretty sure they've moved from neophytes to programmers.

The projects were terrific

The screen shots are just two samples but all the shipmates put together great projects and since we used real tools, the shipmates are well prepared for their next courses be they with us, in school, or elsewhere.

The Stewards also completed projects. I talked a bit about them in my previous post.

We also looked at surveys. We did ask some of the soft questions that I alluded to above. Are you more likely to explore CS after SHIP? How has SHIP influenced your opinion of CS and Tech? The answer to the first was an overwhelming yes and the second was also overwhelmingly positive.

The money questions though, were did they want to come back for a Saturday program and one next summer. Other than the shipmates that lived too far away, again, the vast majority want to return.

Combine the programs they made and the fact that they want to come back with great unsolicited feedback from parents and the shipmates themselves and I think we can say that SHIP was a tremendous success.

Now we have to figure out how to raise the funds for the Saturday program and next summer.

Tomorrow is the last day of SHIP and we'll be capping the whole thing off with a day of demos, science fair style.

Both the shipmates and the stewards will be showing off their work and I can't wait. I've intentionally stayed away from the shipmates because I want to be surprised but I've seen what the stewards have been doing and I can't tell you how proud I am of their work. I was going to say amazed, but actually, I'm not amazed at all – I know they're all awesome.

I'll put up pictures, descriptions and hopefully video after the event but here's a quick summary of what they've done:

3d network augmented reality pong - A 3d depth perception networked pong that you play using your hand as *the paddle. The program uses the camera and blob recognition to control the game.

Augmented Reality Board Game - It started with the stewards taking a picture of a maze and then having their program solve it but it evolved into a game. The computer continually takes a picture of the board and plays against a human opponent who makes moves on the physical board.

Painting identifier (pictured above) - Take a picture of a painting and the program will try to identify it.

Seam Carving Image editor - Look it up on youtube - it's really neat.

Photo Booth - A little more cut and dry than the above but one of the instructors has a wedding coming up and so we needed to build the photo booth.

All these projects are awesome and what's more they're all done from scratch. Early on Gerry was visiting and commented on an early version of the pong game. He said "they're writing their own blob detection, right?" Of course. They can use libraries later. Now it's about learning neat things.

I can't wait to see the stewards show these off tomorrow and also to see the shipmates projects.

On a side note, I've started to go through the comments the shipmates have been writing down about the program - they just confirm what I already knew - I'm lucky to be working with the best group of educators out there.

We're almost at the end of CSTUY SHIP's first journey. The Shipmates and stewards will be showing off their work in another day or so and I'm excited to see their finished projects.

But what toolset are they using.

With knew we would be working with two rooms of relative beginners. We needed something that allowed us to develop the shipmates CS skills while also having a low cost of entry. At the same time, we had to use an environment that our Stewards would be comfortable with as they would be both supporting the shipmates and developing their own projects.

Those of you that know me know that I'm not a fan of drag and drop languages. I've looked at them time and again. I even made a concerted effort while exploring a version of the new proposed AP course earlier this year ¹. Languages such as scratch require almost no ramp up but for kids that are old enough for a traditional text based language I've found the following:

• After a short time, my students find DnD languages restrictive and slow. They can get more done more quickly by typing.
• Many kids work on laptops with small screens. Small screens and DnD languages are not a good match.
• It's much easier to look things up in a text based language.
• I'm not convinced that starting with a DnD is in any way better prepares a student for a text based language.

Bottom line, I've had to rescue a number of kids who were turned off by the "toy" factor of languages like scratch and appinventor.

DnD languages are probably fine for younger kids who are experimenting and playing around but for my kids, I want something more real.

So what did we use? Processing. Processing is a wrapper and IDE around Java. It's really simple to get started with and it makes all sorts of graphics work very easy. Here's a simple processing program that creates a circle wherever you click the mouse:

void setup() {
  size(400,400);
}

void mouseClicked() {
    fill(color(random(255),random(255),random(255)));
    ellipse(mouseX,mouseY,20,20);
}

void draw() {

}

That's it. No public static void main… or anything like that, but it's legit Java, has types and classes plus:

• great online documentation.
• it's used to interface with arduino.
• it has libraries for web cams, music, internet APIs, and more.

By using something like processing, the shipmates learn a real language with sufficient depth to do something real and there's also enough of an online community so that they can continue to work on their own if they can't avail themselves of our future programs.

While we were convinced that processing was the right choice for the shipmates. I wasn't 100% sold on it as the best choice for the stewards. Python would probably have been better for them but most of them will be doing advanced Python (as well as Javascript) in their classes in the fall and I didn't want to teach them something now and reteach it to them in another month. On the other hand, they all already knew Java and there was still plenty of neat things for them to explore with processing. In the end, I think we made the right choice.

We've got a few more topics to cover in the Building a SHIP series. We still have to cover:

• The Crew
• Curricular Choices
• The long term plan
• Site and funding

But for today, we'll talk outreach.

Outreach proved to be particular challenge for SHIP. Our entire crew is made up of teachers. That meant that we couldn't communicate with schools during business hours. That made things particularly tough. I could send emails after hours or set up emails to be sent at specific times during the day, but we couldn't call while at our day jobs. As a result, this led to a vary long communication loop and we could never be sure that information about SHIP was getting to the right people.

We did have a small number of non-teacher volunteers and they were invaluable but they had limited knowledge from the teaching side.

So, we had the volunteers try to call schools during the day and we followed up by emailing a flyer and link to a web site. We tried to emphasize that we needed help from the schools in finding the right students – that is students who might not have even considered something like SHIP but where we could potentially turn them on to something new.

In spite of this, we did get over 200 applicants for our 48 slots. I have no idea how this compares to similar programs.

There were many terrific applications, but there were some head scratching situations. There were some incomplete applications which I attribute to students who weren't really interested in the program, but I was surprised by two things on the student side.

First, sme times we needed a little more information from a student so we sent an email to the addresses (primary and backup) that they listed in the application. Some times students got right back to us. Other times it took days or even weeks. In one case, we weren't able to accept the student because he didn't get back to us until after the selection process was over. I know that not everyone reads or responds to emails promptly but I was surprised since these were cases of students who wanted to partake in our program.

Another thing that surprised me is that we almost lost a couple of students because they thought the program would cost too much. We tried to make it as clear as possible that we offered financial assistance and in many cases could cover all fees but apparently we weren't as clear as I had hoped.

The one really big shock to me involved recommendations. We required our applicants provide one email address for someone that agreed to write a recommendation letter and allowed for a second, optional one. We then contacted these recomenders. If we didn't hear back, we sent reminder emails and asked the applicants to prod the recommenders as well.

We had a return rate of about 10%. This cut across type of school (public, private, parochial, and charter) and grade (rising 9 through 12). As a teacher myself, I know of some colleagues who don't actually write recs they agree to write but I was shocked that we only heard back from 10%. The end result was that we could use a recommendation to help an applicant but we didn't feel that it was fair to penalize a student just because a teacher didn't send in a rec.

As a final though on outreach, it should get easier for us over time. SHIP is going great and next year, we'll be a known quantity to schools. We should also have our cadre of shipmates helping spread the word and of course, we want them back for another summer of more advanced work.

Much like the Love Boat had every week, at CSTUY SHIP, we too have our guest stars.

On the one hand, it's important to have a focused program that leaves the shipmates empowered to continue their CS studies on their own. That means the shipmates have to explore something with sufficient depth so that the learning sticks. It also means there has to be sufficient depth for the shipmates to continue their voyages after our month together has ended.

On the other hand, we want to present the big picture as well. There are a lot of interesting things in computer science and technology that we really can't get to in just a few weeks. Certainly not if we want to do justice to those topics.

Having one off lectures helps. This way, our shipmates are exposed to a wide array of voices and ideas.

Of course, scheduling the right speakers at the right time can be a challenge. Too technical too early can be a turn off. So can too simple.

We're lucky enough to have some amazing guest stars on our ship. We started with a great talk on UX by Cynthia Koo. UX is something I wish kids were more exposed to and I think it was great that Cynthia was able to talk to the shipmates about it before they embark on their own projects. If we set the seeds early and have user experience in the back of the shipmates heads before they start building things, I suspect that the end results will show it.

Cynthia talked about user needs and business needs and used looked at Instagram and Snapchat as case studies.

The talk got the shipmates thinking about apps in a way they had never considered before.

Today we had our second guest star. Edgar Troudt. Edgar talked about innovation, disruption, crowd consumption and more.

Later on, we'll drill down with more technical talks.

For now, though, these talks were meant to give a broader view and to inspire. I think they did.

I thought I'd share some thoughts on how we designed SHIP. I'll try to talk about curriculum choices, tools and more in the coming week but first, let's talk about our stewards.

When we first designed SHIP, we knew we wanted to run two rooms each with around 24 shipmates and two teachers. We also figured that we'd want a few of student teaching assistants, which I decided to name Stewards - Natan wanted to call them Tars in tribute to the British Navy, but he was outvoted.

We had some questions:

• what do we do with them when they're not working with the shipmates
• how old should they be
• what should they know

We knew that we'd be using Processing as our development environment for the shipmates ¹ so we wanted the Stewards to know Java. We also knew that when the shipmates worked on their group projects we'd want to have one Steward mentor each group. That meant at least 12 Stewards. We went with 14. We also decided that we'd take kids that just finished our AP CS classes at Stuyvesant since they were already well versed in our lunacy and would help seed the culture we're looking to grow.

What to do with them when they weren't working with the shipmates?

Most of the stewards will be in my SoftDev class come the fall so I didn't want to just teach them that material

How about shepherding them through some advanced projects using the tools that the shipmates would be using.

So, we had a plan. We'd have the stewards work in small groups on interesting projects when they weren't working with the shipmates.

How has it gone so far? Pretty well I think.

I first asked them to figure out how to work with the webcam and images in processing – at this point they can figure things out like that on their own.

We then talked about edge detection and they coded it up. This also proved to be a nice demo for the shipmates.

After that I asked them to come up with their own algorithms for blob detection. They came up with some interesting solutions after which I let them look up techniques on line.

Why the image processing work? Many of the projects they want to work on are going to need to do image processing.

Now they're hammering out project proposals and getting to work. So far I'm happy with what they're doing and delighted with the support their giving the shipmates.

I don't know if other programs have teaching assistants and how they use them but I'm pretty happy with our arrangement.

• Go to Google Drive
• Make a form
• Send the form out to the students
• Wait

All the data gets dumped into a Google spreadsheet. The trouble is, what to do with it once it's in the spreadsheet.

The other day, I wrote on a few basic stats for our upcoming SHIP program. The data I reported on was all collected in a spreadsheet. I also collected participant and parent emails in the spreadsheet.

So, here's the task, compute some simple numbers form the spreadsheet and also extract and use the email addresses.

I'm sure one could use some fancy spreadsheet magic to get the job done, but I'm a command line wonk – here's how I take care of tasks like these.

First, I downloaded the spreadsheet as a csv (comma separated value) file. Each line looked something like this:

last,first,email,address,gender,grade,school,...

First question, how many applicants did we have:

cat cstuy.csv | wc -l

Which gave:

47

The |, or pipe means take the output of the first command and send it to the next one. Cat just outputs the original file and wc -l counts all the lines in the file.

Next, how many young ladies:

cat cstuy.csv | grep female | wc -l

The results:

17

How many schools? Well, that's a little trickier. Here, I use a few extra commands:

• cut - this will cut out one column from the csv file - in this case the school column (the -d, says use a comma as delimiter and -f7 for field 7).
• sort - takes the lines and sorts them.
• uniq - eliminates duplicate lines in a sorted file

Putting it all together:

cat cstuy.csv | cut -d, -f7 | sort | uniq | wc -l

Results:

30

Thirty different schools.

Finally I needed the emails - here I wanted to be able to paste them into Gmail's bcc field. I could have just used cat and cut and then used the mouse, but instead:

cat cstuy.csv | cut -d, -f3 | xclip -sel clip

Then I can just do a Ctrl-v in Gmail and I'm good to go.

The cool thing is that the tools here - cut, sort, uniq, grep - are all general purpose tools that do simple text manipulations. Once you know them and a few others, you can really quickly and efficiently do all sorts of data processing without even thinking about it. I still go to the spreadsheet for data collection ad also for when I need more hardcore formulas but for day to day manipulations, I'll take the command line.

• We have 47 students and 14 student teaching assistants (stewards)
• We have 4 amazing teachers, 1 mentor for the TAs, me, and one official program mom.
• Most of the shipmates claim little or no programming experience.
• Our students come from 30 different schools. Mostly NYC but a few from beyond.
• 36% of our shipmates are girls

Yesterday the team spent the morning at St. Joseph's College setting up the rooms.

Now all we have to do is wait for Monday morning to roll around.