Using Emacs Episode 47 - Magit

I've been holding off on doing a Magit video for a while. Mostly because I wasn't using it exclusively and also because there are already a number of good Magit videos and resources out there.

What changed? Along with the new version of Magin, Jonas Bernoulli wrote up a walkthrough of the Magit interface. For whatever reason, it all finally clicked.

In spite of what the documentation says, Magit is not an interface for git. Magit is a command and control center for git. You can launch it just to execute some git commands but you can also leave it up and running in an Emacs window or frame as a constant project overview.

Wow. Mind blown!!!

If you use Emacs for Deveopment, you have to use Magit. If you don't use Emacs, you can load it on the side for Magit. If you're not a developer, learn to code so you can use Magit!!!!!

I tried to do justice to the package in the video. Magit along with Org Mode are arguably Emacs killer apps - enough in and of themselves to justify using Emacs.

Check out the video:

Competitions and Hackathons

Today's the last day of spring break. After the weekend it's back to the grind. It really hasn't been much of a spring break. The rain and the snow made for very little spring and between working on the Hunter / CUNY2X Internship program and reviewing applications for my Hunter Daedalus CS Honors program there has been very little break.

Today was no exception - I spent much of the day working but I did take a few hours to head over to Cornell Tech on Roosevelt Island. Why? To check out the Cornell High School Progrmaming Contest - first time in NYC.

I was invited by my friend and organizer Diane Levitt. I only stayed for an hour or so but it was shaping up to be a great event. It looked like around a hundred kids from maybe a dozen or so schools and it was run simultaneously with high schoolers on the Ithaca campus where the competition has been running for a few years.

The format was similar to other high school programming competitions I've been to. Teams of two or three sharing a single computer to solve a number of programming problems that varied in difficulty. You can check out a few "warm up" problems on the competition site.

The competition reminded me of the St. Joseph's High School Programming Competition held every spring but in NYC so more convenient for city dwellers. I went to the St. Joseph's competition a few times and I'm a big fan. I particularly like the awards luncheon after the competition. If I were to make one suggestion to the organizers there it would be to mix the seating at the luncheon so that kids get to sit with and spend time with kids from different schools.

These competitions contrast nicely with hackathons like StuyHacks for which I acted as a judge a couple of months ago. Competitions are, well, competitive. Hackathons can be but don't have to be. Competitions are about solving problems, hackathons, building things. Each can speak to a different kind of student.

Both competitions and hackathons have problems as well. On the competition side we have:

  • Schools with more developed CS programs dominate
  • A single strong student can carry a team
  • Some kids don't like or do well in the competitive environment

And on the hackathon side:

  • 24 hours of straight work is just a bad idea and a bad thing to encourage.
  • Big advantage to teams that bring prefab code.
  • Big advantage to kids with experience.

Both types of events are great opportunities for young programmers. They're celebrate academic work, bring tech kids together as a community and when done right are something of a CS party. Neither type of event speaks to all kids so it's great to have both competitions and hackathons to go along with other types of events available for our kids.

Another thing I love abut the Cornell and St, Joseph's competitions along with StuyHacks is that they're open to all schools and hence all students. There's room for the novice and also the expert and you don't have to be in a particular school or program to participate.

There are other events beyond these three. There are online competitions like the USACO, competitions on HackerRank and Topcoder, Halite along with it's hackathon which is great but specialized and in person ones that are farther away like the PClassic in Philidelphia and Rowan's HS programming competition in New Jersey but it's great to see great local opportunities like these emerging and hopefully running for years to come.

Tools and Complexity

Alfred Thompson wrote about CS education tools earlier today. I've also been meaning to write on the topic but from a different point of view.

I do my best to keep up with the latest and greatest in the CS world both on the academic side as well as the professional one. That's not really possible, but I do my best. When I have a small project to work on I'll some times use it as an excuse to play with some recent technology. Over December, I wanted to write an application viewer to use for company / student internship matching. I started by looking at React but ended up using Vue.js which I liked much more for a variety of reasons.

The viewer served it's purpose but I think it can be turned into a much more comprehensive student / employer internship platform. I tried to steal a few minutes over this past week's spring break to start a rewrite using another toolset, Clojure, Clojurescript and Reagent. I'm really liking the Clojure stack and using Emacs and Cider for the IDE is really blowing me away.

What I've noticed is that for every new language of framework you also have to learn a whole set of ancillary tools.

It didn't used to be that way. Back in the day, things were much simpler. I remembering doing work at Goldman Sachs, it was as simple as typing something on the command line like cc file1.c file2.c file3.c. I of course had to be cutting edge and use fancy modern tools like Make. What's more, the tools I used in industry were very similar to what I used in college.

We now live in very different times.

If you go to the getting started guides for React or Vue it's pretty easy to get hello world up and running but beyond that you start to fall in to the Javascript tooling hole. To start you need either npm or yarn just to manage packages and dependencies. Then you need a build system or bundler like webpack, browserify, or parcel and that's not even considering older options like gulp and grunt and ancillary tools like babel.

A typical React or Vue project is going to need a project.json and webpack.config.js file and sometimes some other files as well. Check out the links. They're from a simple project template I found online. Far from simple.

When I was playing with Vue.js a couple of months ago, I ended up using Webpack to convert the source code into the final JS, take care of live-reloading, and in general manage the project. I still have no idea how most of it works. I don't know if it's just me but I'm very uncomfortable relying on tools that I really don't fully understand to build my systems.

The Clojure world is little better with Leiningen and Boot. If you don't believe me, try to make heads or tails of this.

While it's true that as a professional you'll likely use one set of tools on a day to day basis and you'll eventually get to know them that doesn't mean it's not a good idea to prepare kids for what's to come.

On the K12 side we have drag and drop languages, specialized learning IDEs like BlueJ, simple cut down IDEs like Dr Racket and completely online environments like repl.it. All great starter tools that insulate beginners from the complexities to come. College's might get closer to the "real world" but just a tad.

Don't get me wrong, I like many of the tools used in K12 classes and there's far too much complexity in the professional world to throw at beginners. If we look at a student's entire school career, classes are already so packed with material it would be hard to really prepare kids for the real world within their classes. You could take that tried and true teacher / professor technique of just requiring it and having the kids figure it out on their own but that's really just downright abusive.

I don't have an answer for this one.

I have my kids use tools like Git and GitHub early along with using testing frameworks and external libraries. I also try to move my students to a general purpose programmable platform like Emacs or Vim. I think these are sound practices but students will still have a big learning curve when they finally get to industry.

What I really would love it to see the tooling become simpler and documentation better. Parcel, a Javascript bundler is one of the newer kids on the block and is much simpler and cleaner than alternatives like Webpack. The new version of Clojure has it's own command line tool which is also simpler than the alternatives. Maybe we are already moving in the right direction and this entire rant will become moot in a couple of years.

Do It The Dumb Way

There's so much to like in the shape drawing lessons I talked about in my refactoring post that I thought I'd share a little more here.

It can be argued that the most important things for a program to do is work. The most clever, elegant, creative program is worthless if it doesn't produce the desired result. All too often, beginners and hot shot beginners in particular try to be too clever too early and get themselves into trouble.

When doing the shape drawing lessons the first couple of shape are pretty easy


| ****            |    | *               |
| ****            |    | **              |
| ****            |    | ***             |
| ****            |    | ****            |
| ****            |    |                 |
|                 |    |                 |

but things get more interesting with the right justified triangle:

----*       *
---**      **
--***     ***
-****    ****
*****   *****

For this triangle, students want to come up with the formula for the number of spaces. They usually figure out something like this with h-i-1 spaces and i+1 stars:

std::string tri2(int h){
    std::string r = "";
    for (int i = 0; i < h; ++i) {
      r = r + line(h-i-1,"-") + line(i+1,"*") + "\n";
    }
    return r;
  }

The formulas become harder to figure out as the shapes become more complex and sometimes students get stymied.

The truth is that while they're struggling to find the perfect solution, it's sometimes better to do it the dumb way.

Consider drawing a trapezoid like this example of height 5 and starting width 12:

************
 **********
  ********
   ******
    ****

A student could come up with the "formulas" for spaces and stars but sometimes there's a more straightforward way.

Consider the number of spaces on each line on the left hand side of the shape. First line is 0 then 1, 2 etc. Why not start a variable spaces at 0 and increment it on each loop iteration.

For the number of stars, it's starting at the width and being reduced by 2 each time.

This leads to a solution similar to this (using the line routine from the earlier refactoring post):

std::string trap(int height, int width){
  std::string r = "";

  int spaces = 0;
  int stars = width;
  for (int i = 0 ; i < height; ++i) {
    r = r + line(spaces," ") + lines(stars,"*") + "\n";
    spaces = spaces + 1;
    stars = stars - 2;
  }
  return r;
}

This solution is simple to construct, simple to understand, and quite frankly, hard to get wrong.

It can also lead a student to discovering a pattern or "formula" such as what was used to solve the earlier problems.

This might seem to some as a cheap way out, the dumb approach - creating extra variables and have them count along the way but I don't. There's nothing wrong with simple and straightforward. Yes, you could come up with an elegant formula but the bottom line is you need something to count 0,1,2,3… so create a variable to do it. You need something to count 12,10,8,… create one for that as well.

Now, I'm not advocating writing 100 if statements rather than a loop but I think you get the idea.

The best solution is one that works and Sometimes the "dumb" approach is the best approach.

Ethics In CS Education

I've been meaning to write about ethics in CS education for a while. Probably since I saw this article in the NY Times but got sidetracked.

I was reminded when I saw this tweet by Hadi the other day:

I think we can all agree that bringing ethics and digital citizenship and, frankly, citizenship in general to our students is important. What I wonder is what approaches will lead to meaningful results and what methods will lead us to checking off the "covered that" box.

I'm skeptical of throwing an ethics course into the curriculum as some places seem to be doing. A class might be required, might fulfill an elective requirement or it might just be an extra course. If it's required, what does it replace or are you just going to add more to the student load. If it fulfills an elective credit, will it be perceived as "the easy course" as opposed to say, theory and if it's just an extra course, who's going to take it? Will it just become preaching to the choir.

Better is what Hadi mentioned in his tweet - embed ethics throughout all of your courses and while I think this type of embedding is important and I'd argue necessary, I'm still betting it won't be enough to make a difference.

When teaching a course, teachers cover the curriculum but when you drill down to where they focus their time, it comes down to:

  • what they think is important for the kids to know.
  • what they think the kids will need for that high stakes exam.

If a teacher feels embedding ethical concerns is important they'll spend time on it, if not, it will be lip service. Even if it's on the high stakes exam, unless the teacher really believes that this is important it will just be teaching to the test.

I'd argue that it has to go even further since teachers can only do so much. How many schools have honor codes and how many of us know graduates from those schools who exhibit less than ethical behaviour.

So what do we do?

Well, of course we do have to embed ethical concerns across the curriculum. Teachers should be armed with both the materials and time needed to address ethical concerns but beyond that, we need teachers for which ethical CS is important.

My friend Saber Khan has been facilitating a monthly #ethicalCS twitter chat for close to a year now. I don't take part in too many twitter chats but do recognize that they're important in raising both awareness and community. I've also seen ethical CS issues more frequently appear as conference sessions and professional development.

The next big step is to start at the beginning - pre service teacher training and in my opinion, not with a course but rather embedding ethical issues throughout teacher preparation.

If we want to crack this nut it can't just be from curriculum and from the choir. Pre service CS teacher training is in it's infancy and has not yet really found its form.

Much to my chagrin, a lot of CS Ed has gone the way of other Ed: Math Ed, Science Ed, etc. and not in a good way. Let's see if we can make sure that pre service CS teacher preparation develops to attract and create great teachers for which ethical CS is part of their core.

Sigcse2018 Proof

Next up from SIGCSE2018 is Connect the Dots to Prove It presented by Mark McCartin-Lim. This paper was presented during the same papers session as MacCormick paper I wrote up previously and my reaction to this one was similar to my reaction to MacCormick's.

My reaction to MacCormick was - "This is awesome but while he's talking about redesigning existing theory courses, I think we can get a lot of mileage out of bringing these ideas into lower level CS courses."

I felt similarly about this paper.

The premise is simple - proof is hard and teaching proof is hard. Students don't know how to begin, what's allowed, what's not allowed, what's sufficient etc. McCartin-Lim and his team developed a software tool to present proof as a puzzle and to provide students with necessary support.

The tool allows students to interactively construct a graph of their proof. The graph helps students visualize the proof and the relationships between the assumptions and assertions.

Here's an example:

sigcse2018-proof1.png

And a more complex one:

sigcse2018-proof2.png

My immediate thought was that this should be reskinned as a high school product and rolled out in Geometry classes. I've written before about the fact that proof is rarely taught and rarely taught well even though it's supposed to be the star topic between Algebra and Trigonometry. A tool like this could probably help. This made me think further of the disconnect between K12 and higher education. McCartin-Lim talked about students having difficulty learning proof but lost in the conversation is that students should start building there proof related foundations in high school and supporting them in those early years can go a long way to alleviate problems that only surface at the college level.




Enter your email address:

Delivered by FeedBurner

Google Analytics Alternative