Python - Editor or IDE

Earlier today I read Garth Flint's latest post on choosing a Python environment for his classes. While our classes and populations are different it looks like Garth and I share a lot of thoughts on the subject.

I started to write a comment to leave on Garth's blog but since it was getting a little long I thought I'd write it up as a post.

The question of development environment can be an important one and can make a big difference. When I designed the intro course at Stuy, the fact that Dr. Scheme existed made the use of Scheme in the class an option. Without it as a supportive and simple environment for the students I probably wouldn't have been able to use Scheme even though I really liked it as a teaching and learning tool.

Garth writes about issues relating to choosing a local development environment so that's what I'm going to stick to here. If you want an online environment check out Codesters - a terrific online Python environment with lots of educational support materials and features and repl.it - an online environment that supports many languages and is also developing great teacher and class support – I very much like both of these platforms.

The first question is editor or IDE?

As a user, I'm very pro editor. Learn a tool that you can customize to your tastes and that will work for all sorts of text editing chores from coding to document preparation to scheduling and more and you're in great shape. Personally, I'm an Emacs wonk but there are other choices as well.

As a teacher, though, Emacs or another programmers editor can be overwhelming for younger students and rank beginners.

This can make IDEs attractive.

Some IDEs are too big and cumbersome and can add even more cognitive load than an editor - think Eclipse for Java development. If you think writing

public static void main(String[] args)

is a lot of overhead, just wait until you have a novice try to start a Java project in Eclipse.

Other IDEs are more streamlined. One common choice is Idle. It's big advantage is that it's always available and is "part" of Python. On the other hand, it doesn't seem to add much to a bare editor and I've found that it can be somewhat confusing.

Garth seems to have settled on PyCharm from JetBrains. It's pretty streamlined and really easy to get up and running. JetBrains also provides a free community edition as well as a heavier professional one available for purchase. Garth notes that it's a Python only IDE but JetBrains has similar IDEs for a whole bunch of languages and I seem to recall you can add plugins across their IDEs to basically make them multi-language development environments.

I really like the JetBrains products and if I used an IDE I'm pretty sure I'd use their products. As a teacher though, I find their IDEs a little too powerful for my tastes. I want a learner IDE to provide the bare minimum of features - an interactive REPL, a code window, run and debug buttons, some completion and help - but to make those features really easy to use. JetBrains does a little too much.

What I ended up using in the past is Dr Python. For me it hit the sweet spot. As an added bonus we were already using Dr. Racket (nee Dr. Scheme) and Dr. Java so our students had a similar environment across languages and even NetLogo looked and behaved similarly.

Is there a right answer? Probably not. Just as with choosing a first language there are always trade offs. Besides, if you don't have the right solution, there will be another one next week. Just recently I saw this project. A new beginners IDE for python. It looks interesting and worth checking out.

The right IDE can make a big difference while keeping the overhead low and giving just the right amount of support. For me, the last time around it was Dr. Python. For Garth, it looks like PyCharm fits the bill. Looking at the overall plan, I usually start the kids off with a simple learners IDE and then transition them to a programmers editor like Emacs as they gain more comfort and experience.

As a postscript, let me share these links on how I use Emacs for Python development (each with a video) as well as my series on how I use Emacs in general:

Designing a course with constraints

One of the hats I wear at Hunter is to build a new CS Honors program and to bring my particular brand of insanity to Hunter College CS as a whole.

Yesterday was my last class for the semester so I thought I'd write a bit about the course.

For the Fall semester, I taught an intro programming course to the entire cohort. For some in the cohort, this was their first exposure to CS. Others had one or more classes under their belt. It was a Python based programming class and a big part of it was to start building the cohort into a community. I'm going to work on tweaking what I taught for next time around but the constraints of designing such a course are pretty common – an intro course where the students all want to be there the level of previous experience varies to some degree.

Second semester was more of a challenge. The "next" course was CSCI 135, CS 100 - like APCS but in C++. I could teach that but since some of my students had APCS credit, they didn't need 135. This would break up the group. There was also the issue of the students getting credit for the course without showing any proficiency in C++.

Fortunately, Hunter requires students in 135 to take CSCI 136. A 1 credit programming lab. It meets once a week in a computer lab and the students complete a weekly programming assignment. The lab meets for 2 hours. The instructor goes over anything that's needed for the lab that hasn't been covered yet and then the students work independently (with the instructors support) on the lab. Overall it works well. It makes sure the students are spending at least a couple of hours a week coding in a supported environment.

How did 136 help me? I taught a 3 credit course where 1 day was basically the lab component (what the students were to do in 136) and one day was enrichment - the stuff I was going to do with them. This enabled us keeping the cohort together and it also made sure that by taking the class, the honors cohort members with AP credit would indeed get up to speed in C++.

I was happy with the basic structure. I was able to cover some topics in project development, testing, debugging, and software engineering but the designing and teaching the class proved to be challenging for a number of reasons.

One was timing. The lab class meets 1 day a week for 1 hour. My class, 2 days a week for 1 hour 15. This meant that if we were to keep the lab to one day either the students would have less time or I'd have to impose on them to stay late or come early. I wasn't happy with that but given the inconsistency in the way the other sections handled lab timings, I think it worked out OK.

Some of the other difficulties included:

The language was C++:

Since the labs were to be done in C++, I had to use that as the language for the class. That meant no "fun" libraries or frameworks.

The labs were solo assignments:

Since the labs were solo projects and there was one per week it made it very difficult to structure group experiences. I wanted to cover things like group development, code review, working off of other peoples code bases but this proved difficult with an outside separate lab being handed down each week.

Someone else dictated the language sequence:

The labs were designed to support what the students were learning in 135 and were only distributed a day or two before the week was to start. This meant that I couldn't plan too far ahead and had to adjust frequently. This should be easier next year.

Labs didn't match the supplemental material:

The best example of this was when we were talking about testing. We ended up using Catch as a testing framework. The problem was that right afterwards the lab (and also 135 project) didn't lend themselves to using a testing framework like catch.

There were more challenges but overall I think the class went fairly well. I'll know more when I get feedback from the students and when we all look back next year with some perspective.

It's been an interesting experience designing a class that had to interleave with another, existing class. I've designed many classes over the years and I know that whatever you plan, it probably changes once you're actually in the classroom and working with the kids, or as Mike Tyson said: "Everyone has a plan until they get punched in the mouth." This has been a little more of a challenge but I think the first go through went well and that the course will get better and be better defined as we go through a couple more iterations.

It feels good to be helpful

I got some nice feedback today from a couple of disparate places. It was another reminder that being a teacher isn't just about the kids currently in your class but it's about who you are and everyone you interact with. It's not just about teaching a subject but rather about helping people get to where they can potentially go.

About a year ago I started putting together a series of posts and videos showing how I use Emacs. There were a couple of motivating factors. One, I wanted to put together some resources for my students - something that would take them from the Emacs tutorial to a point where they would hopefully see the power of the environment and not buy into the IDE or editor of the month hype but either really use Emacs proficiently or use another editor (Atom, Vim) in a similar fashion.

The other reason was that I wanted to give something back to the Emacs community. I don't create Emacs packages or otherwise contribute but I figured, I'm a teacher, I can do what I do.

So, earlier today I got an email thanking me for my videos and also noticed that over on irreal.org, jcs wrote about moving over to dumb-jump after seeing one of my videos. It's been nice seeing that I've been of some value to jcs since I've learned a lot from his blog. Emails, comments, and notes like this have driven me to continue the series (even though It's been a busy couple of months). It's gratifying that even without writing a line of code, one can give something back to a community that they've found value in for years.

A month or so ago, I had a chat with a former student who's finishing up his last year in college. He was having trouble finding a job, I couldn't figure out why he wasn't getting offers - he's really talented. I tried to give him words of encouragement and reminded him that I was available to help him - as I try to be for the entire "family" in any way I could.

Fast forward to today - I got an email telling me that he got a job that he's very excited about. He felt the interviews with this company were going well so he was waiting for them to resolve before reaching out to me. He also told me that our talk was very helpful to him.

Sometimes it's not just in a class where we can have a positive effect but sometimes just a talk on the side. Sometimes many years later.

Learning about VC

peter-boyce-talk.jpg

Figure 1: Peter Boyce imparting VC Wisdom on the Daedalus Scholars

Yesterday, the Daedalus Scholars were visited by Peter Boyce. Peter's been a friend for years and is my go to guy when I'm looking talk startups, venture capital and many things tech. Peter's with General Catalyst Partners and is a co-founder of Rough Draft Ventures - a fund that invests in student entrepreneurs.

I'm teaching Hunter's first class of Daedalus Scholars - Hunter's new CS Honors program. They're young and just getting their feet wet and have unlimited potential and possibilities in front of them. It helps if they have some idea as to what some of those possibilities can be.

Everyone knows you can work for a big tech company or a bank but few really know or understand how the tech startup ecosystem works. That's why I was so excited when Peter agreed to visit.

Peter talked about his path. About how he and a group of friends, while in college, got together once night a week to work on their own projects. Not on problem set, assignments, or studying but specifically to work on something else. He talked about struggling to balance grades, early projects and relationships and how much he learned and grew from the experience. He talked about his path to being a VC and he told the class about possibilities.

If the class left one tenth as inspired as I was the day was a resounding success. Based on the brief conversations I had with a few of my students after class and last night on email, I'm pretty sure it was.

One thing that struck me was what Peter seemed to be most proud of was his ability to help others realize their goals and their dreams. I've gotten to know a few venture capitalists and investors over the years and the ones I like and identify best with seem to have this trait. They're investing in people. I seem to recall Fred Wilson, a VC I very much admire telling me that when talking to young entrepreneurs he very much looks at the people as much (maybe more) than the product. The product might not be right but if the people and team are, at some point they'll hit.

As a teacher, my whole career has been about trying to enable others. I spent a lot of time yesterday thinking about the parallels between some of the investors that I know, like, and respect and the best teachers I know and while we work in very different arenas, in some ways we're driven by similar voices.

Using Emacs - 33 - projectile, dumb-jump

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.

A new first language? What's the follow up plan?

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.

GitHub as a tool for education

When I started using git and GitHub with my students it was a natural progression having started with started with CVS and then, as technology changed moving through Subversion and then Mercurial. It was all about using sensible professional software development techniques while making it easier for students to submit work and for me to evaluate their submissions.

Over time, I found that git and GitHub in fact provided some extra support for educators right out of the box.

In my last github post I talked about using the results of git log and looking at diffs. Both provide ways of seeing what a student did and when. The commit log and history make it easier to hold students accountable to working through a project and not leavings for the last minute. The diffs make it easier to see what's changed both to see progress and also to help support students as they develop their projects.

If you use Emacs, as I do, you can use the git timemachine package which does a great job visualizing changes:

timemachine.gif

Other editors might have a similar feature.

The contribution graphs also provide a quick snapshot which shows what team members are contributing and when:

githubgraph.png

The punchcard graph is also useful to see when students actually do their work.

githubgraph2.png

GitHub also make it easy to set up starter code or to have students "take over" each others projects by forking.

I'm very happy using git and GitHub as is but if you want more support, check out GitHub Classroom. Had it existed when I started, I'd probably have used it but since I had already gotten used to my work flows I've stuck with raw git and github.

In case you missed the earlier posts describing the process I use to introduce github to my classes here they are:

I'm hoping some of you have found this set of four posts useful or at least interesting.

A free multi-state clicker with built in redundency

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?

fonzup.jpg

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.

fonztwo.jpg

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.

SIGCSE 2017 - a path to github part 3

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.

SIGCSE 2017 - a path to github part 2

Note:

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.

Post starts here:

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.




Enter your email address:

Delivered by FeedBurner

Google Analytics Alternative