Catan GUI in Elm

I’m in India, but there’s some downtime and I’ve been using it to play a with a toy project – a Settlers of Catan game built in the pure FRP web language Elm. Well, perhaps “game” is to strong of a word for what I’ve done thus far – lets say Settlers of Catan GUI.

Click the image to see the code/try it out!

Click the image to see the code code/try it out!

I really liked using a boardgame to try out Elm. It’s a fun thing to try BUT the mechanics of the game itself force you to confront real problems. The examples on the very nice elm website are cool, but once I tried to actually engage with a data model more complex than just a few coordinates, things got pretty crazy.

One thing I can say is that the mechanics of FRP really encourage you to come up with a can GUI/model seperation. I eventually came up with this idea of hoverable stuff – which in theory the model can communicate to the GUI all the board objects that can be manipulated, then the GUI itself does the highlighting, then when the user clicks the selected object is communiated back to the model – which adjusts its internal state and then gets re-rendered. Not bad.

Some of the other stuff is not so fun. Some of is just book keeping – variables are not mutable, so when the state needs to be updated you can’t just update it. Instead you need to return a fully new model object, based on the old model object but with the variable changed. But when your model actually is complex, this is very annoying – the value you need to change is one variable in a record in a dictionary in the overall model. So you need a function that takes a record and returns a new record, a function that takes a dictionary and returns a new dictionary, and a function that takes a model and returns a new model. Also, if you have dictionaries of various keys and values, these functions are not easily reusable – although maybe you could do something with type parameterization somehow.

Other stuff is more than annoyance. Every function must be pure, so random numbers are hard. In elm, you need a random “signal”. But unfortunately, signals don’t have values at initialization time – they only exist when your program is actually “running” (i.e. a very funky pure functional transformation of input signals to GUI signals). So if your board arranged randomly – prepare for some serious sadness. I did figure out a way around it, but it was anything but pretty.

Anyways, I had some fun with elm. I’m not sure if I am actually going to complete the catan game – most of the rest of it seems unlikely to teach me new stuff and board games have a lot of complexity. But I did learn a lot, and I think I may ask students to build a (much smaller project) in elm as part of an upcoming programming language course I’ll be teaching in the winter.


(Contains 1 attachments.)

ICER 2014: How CS Undergraduates Make Course Choices

So the second main part of my dissertation research was accepted into ICER 2014! Here’s a pre-publication version if you’re interested.

Students in most CS curricula have to make a wide variety of educational decisions including what courses to take. Frequently, they must make these decisions based on a very limited knowledge of the content of the topics they are choosing between. In this paper, I describe a theory of CS undergraduate course choices, based on 37 qualitative interviews with students and student advisors, analyzed with grounded theory. Most students did not have specific educational goals in CS and, as long as their classes were enjoyable, tended to assume that any course required by the curriculum had useful content (even if they could not articulate way). Particularly enjoyable or frustrating courses caused them to make long term course/specialization decisions and use a more strategic goal–oriented approach.

My Summer Vacation: Programming at Groupon

After focusing on teaching and research for the last few years, I wanted to get back to the swing of things and write some real code. Lucky for me, my good friend Ben twisted a few arms and got me a summer job with his team at Groupon (lest you doubt Groupon’s hiring practices…yes there were some technical interviews in there too). I worked on the Breadcrumb Pro team. Our app looked like this:

Capture

It’s a restaurant point-of-sale application – the system restaurants use to enter in everybody’s orders, track employee hours, generate reports, etc. This is part of Groupon’s big plans to create a vast and profitable empire in business software. From a technical side, we’re talking a 100% classic client server app – iOS on the frontend, python on the back.

Ok, I admit a sense of pride looking at my commit history.  Good to see I can still code when the situation requires it! :)

Ok, I admit a sense of pride looking at my commit history. Good to see I can still code when the situation requires it! :)

I had a great time and was pretty productive. I was initially worried three months might not be enough ramp-up time for me to be of value to my team. Within a month I coding fast and signing up for high priority stories just like everybody. It actually sort of helped that I was not particularly familiar with either iOS or python…I took stories on both sides and that really help me understand the overall architecture. Especially on the fast development cycles we were on, there wasn’t a heck of a lot of spec design. So oftentimes a single story would require a change all the way from the DB to the frontend – just understanding every layer and changing it was way easier than attempting to coordinate a hand off.

I think I’ll definitely give my students even more practice with understanding big systems – maybe even toss in one or two multilingual codebases. At the very least I managed to get a few more war stories to tell them about. By then end of it, both me and Ben were wondering why summer internships at other companies wasn’t standard practice for professional software engineers.

Of course, even though I had a great time at Groupon, I’m still very much looking forward to teaching again in a few weeks.

ICER 2013: Undergraduate Conceptions of the Field of Computer Science

I had a great time at this year’s ICER conference – met up with some old friends and talked with some new ones about all sorts of CS education stuff. I also published a paper entitled Undergraduate Conceptions of the Field of Computer Science:

Students come to CS from a variety of backgrounds and with a variety of preconceptions. Some initially select CS with a very vague idea of the field they are majoring in. In this paper, I describe CS undergraduates’ view of the field of Computer Science. The approach was qualitative and cognitive: I studied what students think CS is and how students reasoned about their courses and curriculum. Through the use of grounded theory in 37 qualitative interviews with students and student advisors, I extracted three different conceptions about CS found in undergraduate CS majors using Grounded Theory. Overall, students had reasonable views of CS at a high level but lacked specifics. Students had difficulty describing subfields of CS or anticipating the content of courses they selected.

You can download a copy if you’re curious, or see all the good stuff from ICER 2013 from the complete proceedings.

My students are awesome: CSSE 376 Board Games

So in my quality assurance course, I ask my students to form groups of 2-3 and build computerized versions of board games. I selected board games in particular because I knew board game logic was both understandable AND tricky enough that it could generally benefit from robust unit testing (which was what I was mainly asking them to practice for this project).

I was very happy with what my students produced. Every team worked well and reliably turned out code week after week – perhaps partly because they knew I was monitoring their github commits :) . These games are really quite complex…if you look at these videos I think you’ll see tons of detailed (and tricky to implement) logic.

And…lest you think I was slacking on the testing…each of these games has greater than 75% code coverage…not at all bad when you consider the complexity of the GUIs which are mostly untested.

Anyways, check out their stuff!

CivilizationMovieFinal from Spencer Murphy on Vimeo.

Reflection on Summer 2012 GHP Classes

I’m a big believer in student feedback. Even though students often can’t articulate the source of problems, going through and reflecting is an essential part of figuring out what I want to try going forward. So even in an environment like GHP where I’m not asked to formally collect evaluations, I always do. Of course, it really helps that at GHP in particular students are relentlessly positive. Seriously my worst review this summer was “not my favorite class by any means, but still good”. I wish that’s what my worst university eval looked like.

BUT, looking at the feedback (here and here), one thing that I am struck by is how much more satisfied by student feedback that is about course content and not about me. This is something that I think the Wicked Teacher of the West said first…but I can’t find the blog post now. When I student says “It’s a really great course” that of course makes me a little happy. But when a student says “I thought it was really neat how you could prove problems are incomputable by reducing them to other incomputable problems” that makes me think I did my job. It’s always about the student’s relationship with the content, not the student’s relationship with you.

I see that a lot more in my theory of computation course than I do in my fractals class – that makes me suspect I’m doing a better job in ToC.

Theory of Computation was different this year, I think because I didn’t have the same core of super-strong students who were really loving the course. There’s definitely a class culture that develops, and I’m not yet attuned enough to think seriously about how I can help its development. The course was still good, and I think I was able to smooth out some rough edges for some students. Remaining challenging however, is the issue of the two main proof techniques we do in class: the pumping lemma and incomputability proofs. If I teach this course again I’m gonna at least crack the pumping lemma.

Fractals was better this year. I found it less stressful, and I think the students learned more. Fractal dimension seemed like a big hit this time around, so I we can explore that a little more. We kicked things off with some very simple feedback functions and Chaos – I think that helped people get on board at the get go. I think affine transformations needs more exploration discussion and play. A little tricky without computers some times.

Changing the Emacs Modeline Color in a Buffer

I wanted to have the color of my term-mode mode line switch, depending on whether I was in character mode or line mode. I’m not sure why this became an overwhelming desire of mine, but it did. Not really knowing anything about emacs font faces, themes, or anything I pulled up my debugger and started spelunking in color-theme-buffer-local. I discovered a mysterious function face-remap-add-relative designed to do exactly what I wanted – let me remap a particular part of a single buffers theme and then undo that mapping when finished.

A smarter person might have checked the emacs manual and saved himself a lot of time.

Here’s how it works:

;; set the modeline background color and save a "cookie" so the change can be undone
(setq old-term-color (face-remap-add-relative 'mode-line :background "dark goldenrod"))

;; undo that change later
(face-remap-remove-relative old-term-color)

Interestingly, I’m pretty sure this ability to change colors for a specific buffer is one of the new features of Emacs 24. Yay progress.

My Defense

So I announced my defense today. It’ll be on November 2nd at 1pm in TSRB 132.

Here’s the abstract:

Computer Science is a complex field, and even experts do not always agree how the field should be defined. Though a moderate amount is known about how precollege students think about the field of CS, less is known about how CS majors’ conceptions of the field develop during the undergraduate curriculum. Given the difficulty of understanding CS, how do students make educational decisions like what electives or specializations to pursue?

This work presents a theory of student conceptions of CS, based on 37 interviews with students and student advisers and analyzed with a grounded theory approach. Students tend to have one of three main views about CS: CS as an academic discipline focused on the mathematical study of algorithms, CS as mostly about programming but also incorporating supporting subfields, and CS as a broad discipline with many different (programming and non-programming) subfields. I have also developed and piloted a survey instrument to determine how prevalent each kind of conception in the undergraduate population.

I also present a theory of student educational decisions in CS. Students do not usually have specific educational goals in CS and instead take an exploratory approach to their classes. Particularly enjoyable or unenjoyable classes cause them to narrow their educational focus. As a result, students do not reason very deeply about the CS content of their classes when they make educational decisions.

This work makes three main contributions: the theory of student conceptions, the theory of student educational decisions, and the preliminary survey instrument for evaluating student conceptions. This work has applications in CS curriculum design as well as for future research in the CS education community.

EDIT: The defense went well and I passed. You can see the final version of my dissertation here.

Making Simple Fractals in R

In my GHP Fractals class this summer, I opted to write my sample programs in R. I selected R because it has very nice graphing libraries and built-in complex numbers. Overall, I was pleased with R; it definitely let me built some incredibly straightforward fractal code. It’s not as fast or pretty as other choices might have been, but it highlighted the underlying math which was most important to me.

King's Dream Strange Attractor (parameters from Chaos In Wonderland)

.

You can see an example on the left, rendered by R. The source of this particular fractal comes from Clifford Pickover’s Chaos in Wonderland. The graph is made by repeatedly iterating a simple function of x and y based on sine and cosine.

You can see the code in R here:

  a <- -0.966918
  b <- 2.879879
  c <- .765145
  d <- .744728
  pointsToPlot <- 100000
  
  
  x <- .1
  y <- .1
  allXs = rep(0,pointsToPlot)
  allYs = rep(0,pointsToPlot)
  for(i in 1:pointsToPlot) {
    newx <- sin(y*b) + c*sin(x*b)
    newy <- sin(x*a) + d*sin(y*a)
    x <- newx
    y <- newy
    allXs[i] <- x
    allYs[i] <- y
  }
  
  plot(allXs, allYs, pch=".", col="red",
       main="Strange Attractor: King's Dream")

Here’s a few more pretty pictures:


(Contains 7 attachments.)

Feedback from my First Semester Teaching

So Duke Spring 2012 is finished, and grades are in; it’s time for me to become an ordinary graduate student again. But before I do that, I think it’s reasonable to reflect just a bit on how the semester went.

All and all, I am happy but not ecstatic with how my first semester turned out. In general I think students enjoyed my classes and they learned a lot (and my course feedback reflects this). I was able to try out some techniques I thought would work well, and in general I had good success. Of course it also helped that my students were almost always enthusiastic and extremely conscientious.

One main thing I learned this semester is that I have to be a little bit more careful about how I manage my time outside the classroom. As a professor, there’s a lot I can do to help students and in the beginning it was really easy to put in a lot of extra hours. Not that I mind putting in extra hours for the students, but time away from relaxing and sleeping takes it’s toll. Towards the end of the semester, I just got exhausted and then I really couldn’t put in time sometimes when I really needed to.

Well, enough vagueness. Here’s what my students said in their written feedback, crudely summarized by me:

I’ve also attached the official numerical feedback summaries below.


(Contains 3 attachments.)