If you keep Emacs open all the time you end up accumulating lots of buffers. That can make navigating a little bit awkward.

Projectile is a really nice package that makes navigating in and between projects much easier. I also have counsel-projectile installed.

Here's my configuration:

;; projectile
(use-package projectile
  :ensure t
  :config
  (projectile-global-mode)
(setq projectile-completion-system 'ivy))

(use-package counsel-projectile
  :ensure t
  :config
  (counsel-projectile-on))

Projectile considers a sub-directory tree to be a project if it's a git or other source control repo, if it's created by tool like lein, maven, or sbt, or if you put an empty file named .projectile in the root directory of the project.

Projectile learns about projects when you open a file in that project and then stores that information in an Emacs bookmark file in your .emacs.d directory.

You can switch between projects using C-c p and when in a project, load another file using C-c f. If you use the which-key package as I do, just type C-c - the projectile prefix and then which-key will bring up help.

The video goes through some of my favorite features and you can find the full documentation can be found here.

The other package I show is dumb-jump. It's basically a zero (or almost zero) configuration tags replacement. Really nice.

Here's my current config:

(use-package dumb-jump
  :bind (("M-g o" . dumb-jump-go-other-window)
	 ("M-g j" . dumb-jump-go)
	 ("M-g x" . dumb-jump-go-prefer-external)
	 ("M-g z" . dumb-jump-go-prefer-external-other-window))
   :config (setq dumb-jump-selector 'ivy) ;; (setq dumb-jump-selector 'helm)
  :ensure)

  :config 
;; (setq dumb-jump-selector 'ivy) ;; (setq dumb-jump-selector 'helm)
:init
(dumb-jump-mode)
  :ensure
)

Enjoy.

Relevant links:

• Video series overview page:
  • http://cestlaz.github.io/stories/emacs
• Code:
  • https://github.com/zamansky/using-emacs/tree/master

This morning, Mark Guzdial wrote about Stanford possibly moving away from Java as their intro language. This comes on the heels of a semi-regular thread on one of the lists I'm on asking about what languages are used at assorted colleges around the country. Invariably the Pascal -> C++ -> Java progression of APCS turns up in these threads.

There are plenty of arguments to be made both for and against pretty much any language or platform. There's no single best universal answer. Each choice giveth and each choice taketh away.

What I'm really curious about is who's looking at intro languages in the context of complete programs or even complete educations that could span multiple institutions.

Early language choices can make a big difference in engaging and exciting newcomers but there are ramifications later on that few seem to consider.

Take the APCS change from C++ to Java. It removed memory management from the first year course. It also simplified issues relating to pass by value vs pass by reference (or, rather, passing address by value), bought much more strongly into OOP and moved more towards using built in implementations of data structures like Lists rather than rolling your own.

Removing memory management from the first year course in and of itself isn't a problem as long as it's taught and taught effectively somewhere later on. It could be argued that "memory is already covered in our required systems course." That could be the case, but there are many concepts that kids don't get the first time around. Is an institution that covered memory management in CS1/2 and then came back to it in a later Systems course giving their students the same understanding now that they've eliminated the CS1/2 experience?

What about OOP buy in. Personally, I've never been a big OOP fan but that's neither here nor there. What I have found is that depending on how a student is exposed to programming in CS1/CS2 can have a big influence on how they approach problems later. Did the move to Java cause more of our students to try to use shoehorn OOP into a problem that really shouldn't be approached in an OOP manner?

I suspect that the use of built in data structures has had a negative impact. A few years after the switch to Java, I was talking to a senior tech worker. He was having a bad day - interviewing potential internees and full time engineers. My friend was complaining that the kids couldn't come up with solutions to what he thought were pretty straightforward questions. He felt that had the kids actually implemented algorithms like the nlogn sorts rather than just learning java .sort method and just talking about the algorithm they'd be better prepared. I've heard this sentiment repeated over and over throughout the years.

This is not to say that Java is a horrible language or horrible for teaching - that's another debate. The point is that you can't just look at the intro class and who it draws in. You have to consider how it will prepare students for the next level and you have to look at the big picture – will our students get everything they need by the time they leave us.

Many schools have moved to Python. Will that effect students take on type systems later on? Will the flexibility and constructs like list comprehensions make it harder to teach recursion since there are "easier" ways to do it?

None of these are really problems so long as the CS1/2 (or even CS0) isn't taught in a vacuum.

I fear, however that too often we're paying attention to the intake of the pipe and not so much the output.

Last Friday, Mark Guzdial wrote about the woes of using clickers in a class. The amount of effort required to use his school's approved clicker technology sounds ridiculous so while we need tools to better engage students in large class settings we need better tools that can be integrated into our classes more easily.

I've never used clickers. On top of stories like Mark's, there are a number of problems with using clickers in a public school.

You can't force students to buy them and in NYC, until recently, students couldn't use their phones (which they also might not have). Forgetting the expense, if the school provides them, is it one per student? If so, who's going to administer the clicker to student mapping and how will that be communicated to the teachers. If college tech infrastructures are sometimes lacking, high schools are orders of magnitudes worse. The resources just aren't there. Then we have to deal with loss and breakage.

If a teacher somehow gets a class set of clickers, they have to deal with mapping clickers to students for all of their classes and make sure the right student has the right clicker. Again, loss and breakage is a problem.

Then you have to create the question content and hope that everything works in class.

The value added given the overhead just doesn't seem worth it particularly since high school classes, while large, are not in the hundreds and there are other methods of student engagement.

Here's what I use instead. It's not perfect but it's low cost and low effort with a pretty high return.

The basic configuration, is a simple three state broadcast device.

It's not without its problems and I don't think it would work as well in a large lecture but given the cost, it's well worth it.

So, what is it?

Thumbs.

Periodically, I'll poll my class.

Thumb to the side? Everything's OK. Keep going as you're going. I get it. Basically, things are good.

Thumb up? Speed up, you're going too slow, I got it five minutes ago or some similar big positive.

Thumb down? I have no idea what you're talking about.

It's cheap, easy, quick, and once you can get your class to buy in, you can get a quick sense of the class.

The downsides?

• The class has to have a level of comfort so that students vote honestly and don't just give you positive feedback.
• No data collection.

The upsides?

• quick
• cheap
• works on any topic on the fly
• even if the votes are artificially skewed towards positive, it does forces the class to be at least a little attentive and to engage in some physical response
• can get analog responses by allowing students to adjust wrist rotation

As to the redundancy? I've never had a kid leave their thumb at home or lose it and even if they did, they've got a second hand.

This also works in extreme environments. Try using a clicker or mobile app with gloves or mittens on or underwater.

I don't teach large lectures so I don't know how this would work in a huge class. I'd imagine it's still worth it given that it's so low friction and low cost of entry even if it's not perfect.

I wanted to write this up earlier but, as so frequently happens all my dormant work projects decided it was time to rise up and demand instant attention.

When we left off, we had students pulling code and submitting homework via github.

Form here, it's an easy step to have them working on a small project in their own repo. In fact, sometimes, I'll jump right to a two person project where one person creates the repo and invites the other (and me) as a collaborator.

Once here, it's important to emphasize the normal workflow:

1. git pull
2. edit stuff with an occasional git add, git rm, or got mv
3. commit
4. and an occasional git push

Regardless of how much you emphasize the workflow you're now going to have to cover merges as well how to recover from problems by going to an earlier revision.

For going back to earlier versions or otherwise recovering from disasters, I don't show them the "right" way of doing things. I show them a way that's easy to remember and reliably works without tons of searching for answers.

First, given some repo, I have them clone a version under another name:

git clone git@github.com:hunterdaedalus/classcode.git newdirname

Now, they have the original repo and a clone under the directory newdirname.

I have them go into that new copy and use git log to go through the logs to find an earlier version that they want to go back to.

The log will look something like this:

commit 67eceb5e0a01ca5f5fb54ace65a4fe134f71edae
Author: Mike Zamansky <zamansky@gmail.com>
Date: Sat Feb 25 12:32:26 2017 -0500

    updated Makefile

commit 7efed10eb6015276b0cb82874ce786dc68a683ae
Author: Mike Zamansky <zamansky@gmail.com>
Date: Sat Feb 25 08:45:34 2017 -0500

    broke out main –> main and shapes

commit e8b5c240123a7cb17920d52b4aba9cf5787ddab2
Author: Mike Zamansky <zamansky@gmail.com>
Date: Sat Feb 25 08:36:29 2017 -0500

    added lab3 code

commit 6d5bcf866306334ddc5c6a48e8f49fb39ddbcb18
Author: Some other coder <somone@somewhere.net>
Date: Sun Feb 19 19:29:51 2017 -0500

Find the hash that they want to get back to and checkout that version (you normally only have to use the first few characters of the hash):

git checkout 7efed10

Now they can grab what they want, copy it into the working copy of the repo, commit the changes and push them back.

For Merging, I start by having them do it manually. I'll have them load the file in question into their editor and look for the chunks that look like this:

<<<<<<< A
lines in file A
=====
lines in file B
>>>>>>> B

They'll manually make the changes, then save, commit and push back.

Later, I'll show them a couple of tools to help along the way. I usually show ediff in emacs along with meld.

Once they've been doing this for a while, it's easy to expand group sizes. After that, I'll introduce issues via the github interface.

The last big topic is branches.

First I show basic branches and merging. Here's a pretty good run through. Afterwards, I'll show how branching works in conjunction with github. This is also a good time to emphasize that students have to actually read the messages that git gives them when things don't go well. In most cases, the message will contain the exact thing to type to fix the problem (such as linking a branch with a branch up on github).

Now is also the time to introduce pull requests and how to use them to support code review. The general setup I recommend is one branch per group member and a main "deployment" branch with group members creating more branches as they see fit.

That's about it. I've followed this process, more or less, over a semester, over a year, and over multiple years. It's worked for me, I hope some of this helps you as well.

In the next and probably last git/github post I'll talk about the educational benefits that I've discovered along the way. After that, I'll get back to some emacs videos, other SIGCSE stuff and my normal rants.

Just for some quick context. The process I started to describe in the last post and continue here chronicles what I did at Stuy with high schoolers. Now that I'm at Hunter college, I'm adapting the process but the overarching themes remain the same.

Now that your students have been pulling the classcode repo regularly it's time to move to the next step - adding and pushing files to a repo.

I don't claim to do this the "right way" or the best way but it's worked for me and it's gotten my students up to speed.

I ease my students into adding and pushing files using git through homework submission. I create a single repo, usually named submissions and make a folder for each student underneath looking something like this:

.
└── submissions
    ├── abram_sarah
    ├── chen_stuart
    └── thompson_steve

Before going any further, let me clear up one thing. The repo is public so all the students have access to each others work. I'm OK with that. We could have each student make their own repo and use git submodules to make a submissions repo but administration is much trickier and we lose the chance to build a culture of cooperation and trust. We can lock down our submission systems as much as we want. If students want to share assignments there's nothing we can do about it.

My preference is to try to build a culture that minimizes bad behavior and rewards good behavior. I'd rather see an incorrect homework so that I can tell what we need to work on than a copied perfect assignment. I'd rather see students cite each other, share properly, and support each other than copy in the shadows.

I'm not naive enough to believe that copying doesn't happen in my classes but I still prefer erring on the side of openness.

Once the repo is set up, I give all the students access. This is a little onerous since I have to type each of their GitHub usernames under the collaborators section of the submissions repo but I only have to do this once a semester.

Then I teach the workflow. Assignments go into a file or folder under their directory named ##_name where ## is the assignment number (01,02,03, etc) and name is the assignment name. The student workflow is:

1. git pull
2. git add (sometimes)
3. git commit
4. git push

Since every student is working in their own directory, things basically work.

The first issue that students come up with is when another student pushes before another student. The second student merely has to do another git pull before proceeding. This provides an easy introduction to dealing with the distributed nature of git.

There will occasionally be other issues when students don't follow procedure exactly so I'll have to fix the repo every now and then but nothing too bad and each time is a opportunity to show the class:

1. you can pretty much always restore and fix things once you commit them.
2. the specifics to fix things.

There will be a few bumps in the road but after a few assignments the sailing will be pretty smooth.

At the end of the day, the students are a little closer to being fully fluent using git, they're hopefully using each others code as resources but in a proper way and since the students are all using a consistent assignment naming convention I can use simple scripts and shell commands to do all sorts of processing on assignments.

That's the end of phase two. The next step brings us to small projects using git.

Both at and prior to SIGCSE 2017, I promised to write up the steps I take to introduce and use revision control systems in my classes.

This series is not meant to be a git or GitHub tutorial. There are plenty of those already (two of which I've linked to below). This is about the process I use with my students to get them up to speed.

As with any new tool, there will be some resistance but once git saves them once, they get religion. There will also be some bumps in the road but at the end of the day, the students will be using a valuable and necessary tool.

I was also surprised at the ancillary benefits I got as a teacher by using GitHub in particular. I'll talk about that at the end of the series.

Here's part one.

I'm doing this with git and GitHub but there's no reason why other systems and hosts can't be used. I'd also recommend that any educator or student sign up for the assorted discounts offered by GitHub.

I've followed this basic idea multiple times and done it over the course of a single semester, a year, and even two years. Regardless of time frame, the idea is the same. Make each step simple and relevant and introduce complexity and roadblocks a piece at a time.

To start, I don't even talk about version control. We start with code distribution. For years, I've looked for efficient ways of sharing code with my classes. Both code developed in class and code for assignments.

I've tried things like NFS, Dropbox, online code repositories like the files section of systems like Moodle or Blackboard.

At Stuy, we've always had efficiency problems with NFS and Dropbox has multiple problems ranging from students not being able to install the client on school machines to the problems of the network hit when a room full of kids are syncing at the same time.

Uploading to a CMS system was also problematic - I'm a command line wonk and hate going through slow web page menus to navigate a filesystem and upload files. I also had to remember to get the files off of whatever machine I was working on in class and then transfer them to the CMS when I had a free moment.

Enter git. Now, of course, if you're going to use git in the classroom you have to know it. There are plenty of resources out there. Online courses, articles, videos, and tutorials. Here are a couple:

• https://try.github.io/
• https://www.youtube.com/watch?v=0fKg7e37bQE

I also want to point out that I just use raw command line git along with native GitHub. GitHub has rolled out GitHub Classroom which adds a layer of support for educators. I don't use it because, as I said, I'm an old school command line wonk and also because I figured out a sequence that worked for me and my students before GitHub Classroom existed. Were I starting now, I'd take some time to look at their current offerings before jumping in.

As a high school teacher, I was never able to attend SIGCSE, the conference of the ACM's Special Interest Group on Computer Science Education. Between the number of instructional days I would lose and the cost, I could never justify going. Instead I looked over the proceedings and read many of the papers.

Now that I'm at Hunter, I was finally able to attend. This year in Seattle, the conference ran from Wednesday through Saturday. I was part of a panel on "Tools we can't live without." Over the next few weeks, I hope to blog about a number of things I thought and talked with people about over the conference including:

• The path I use to teach git and why GitHub a good teaching tool (my talk).
• The relationship of different CS Ed stakeholders - teachers, researchers, organizations, etc.
• Teaching at the high school level vs college - perceptions and reality.
• The challenges of tech tool adoption in schools.
• What's going on in K12 CS Certification.
• Maybe some other stuff.

Today, some overall thoughts.

As with many conferences, the "hallway track" along with receptions sponsored by the CS4All consurtium, TEALS, Code.org were terrific. I was able to finally meet in person many people who I've only known virtually and got to know many more as well. I left the conference with a much larger address book and a long list of follow up items. Being in Seattle, I also enjoyed being able to spend time with people from TEALS and Code.org, two of the CS Ed groups working hard to do some real good (yes - I do like and support these guys even though I call them out on things I disagree with, but that's the subject of another post).

I attended sessions on CS certification, teacher preparation, assessments, POGIL based instruction to name a few. They ranged from valuable to interesting and to be honest, a couple of "what were they thinking" but the overall experience was very much worth the trip. I also got to speak to a number of wonderful students at the poster sessions.

The keynotes are also well worth a read (sorry if you don't have ACM digital library access). Jeannette Wing talked about the importance of probability and statistics in CS Ed, and aspects of Gail Chapman's talk "Inspire, Innovate, and Improve…" keynote and Mitch Resnick's "Fulfilling Papert's Dream" both spoke to the educator inside me.

The biggest downside to me was that I found very little value added in a number of the paper sessions over just reading the papers. Part of this is probably because of my own over-inflated expectations given the number of years I've waited to attend. Part of it though, was the fact that sessions were so tightly packed that I didn't have time to follow up with presenters before having to run to the next thing. Unfortunately, in some cases, it was because the presenter merely "read" the paper much as a professor sometimes just reads the slides or the book to his class.

One paper presentation I very much liked was Exam Wrappers: Not a Silver Bullet presented by Michelle Craig and Ben Stephenson. I actually came in late since I was hustling over from the Code.org lunch. The result was that I didn't actually know what "Exam Wrappers" were until well after the talk when I ran into Jim Huggins. Exam wrappers, in short, are merely when you require the students fill out something for some credit when picking up their exams. The funny thing is that it's a strategy that high school teachers have used for years without a special name and we already knew the good and bad of it without the research but that's not what I want to get at here. What I loved about the talk, besides the fact that Ben and Michelle are clearly strong presenters is that this was a negative result that was being presented. I also loved the fact that they didn't present their research as gospel but rather pointed out the strengths and weaknesses of their approach - they made a case to what and why we should pay attention to and what should be taken with a grain of salt.

This was a major breath of fresh air after being exposed to so much education 'research' over the course of my life that the author or presenter felt was just as strong as a mathematical proof rather than an indication based on a specific experience or small set of experiences.

I also felt a little weird at times during the week when west coast people seemed to know me. I know I'm a loud mouthed curmudgeon and I go on my periodic ed rants but given the dearth of comments on this blog I was really surprised to get as many as "great to meet you in person after reading your blog" or "we know you and your work" all week. It was weird and somewhat humbling.

Finally, another highlight f`or me was that I got to catch up with some of family.

Already planning to submit something to present at SIGCSE 2018 in Baltimore.