Mike Hewner's Homepage

So this summer, I’m working on a interesting pilot project with the folks at Rose-Hulman Ventures (http://www.rhventures.org/). Basically, I’ll be acting as technical lead for a group of Rose-Hulman students working on programming contract work. So in the morning, I’ll be basically a professional programmer/mentor and in the afternoon I’ll be teaching a course for the students.

I just finished the first set of technical interviews for the students and we made offers this week. I’m actually really impressed with how the students did…I used a modified version of my old SDE interview script from my Amazon days and I was really impressed by how well the students did. Honestly, I’m not sure they’ll need all that much mentoring on my part to be productive.

Only downside: we’d ideally like at least one more contract-work software development project for the students to work on. You’d have to pay…but because of some grants we’ve got from Rose-Hulman the cost is very reasonable. Plus, you get the software and a chance to interact with some great students who presumably could be recruited for internships or full-time in future years. Plus, I’ll be on the programming team too, if that carries any weight.

If you’ve got any projects you think would be a good fit (or know someone who would) let me know! (all my contact info is here)

This summer I had a fun opportunity to program in a space I’ve never really explored before: medical data analysis. The company was Indigo Bioautomation. They build cloud-based software for analyzing mass spectrometer data. Here’s a pretty good introduction if you’re curious:

Despite medical tech’s reputation for somewhat old-school and slow software approaches, Indigo definitely feels like a startup. They are using new technology: TokoMX, a heavily modified ruby-on-rails stack, Backbone.js, etc. They also have an agile in-house process pretty similar to other places I’ve worked.

One thing that was different though: automated testing. The Indigo guys are totally on board and have tons of automated tests for everything. It’s a different mindset: I definitely had to be reminded to write more tests several times during my tenure. There’s a lot of good, but also some bad – in particular, long test runtimes (like 5+ minutes) are a huge problem there despite a lot of careful design work to optimize. And of course bugs still slip through in various places…though they definitely tended to be more obscure and less “this feature doesn’t even sort of work” like I’ve seen elsewhere. My views on automated testing have definitely become a lot more nuanced – and I’m constantly thinking of ways I want to revise what we talk about in the SE curriculum to reflect that.

Indigo really let me explore their system. I worked on a big command line tool, in their Java-based rules engine, writing MongoDB queries, front-end javascript, and lots of ruby coding both on webservers and services. The opportunity to get down-and-dirty with ruby was particularly fun: I really think I see now how it differs from python in actual practice.

Overall I learned plenty and I think Indigo is happy with what I produced for them. I’m missing my students and looking forward to being back at Rose in a few weeks though.

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.

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.)

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:

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 . From a technical side, we’re talking a 100% classic client server app – iOS on the frontend, python on the back.

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.

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.

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.

.

You can see an example on the left, rendered by R. The source of this particular fractal comes from Clifford Pickover’s . 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.)

The final project for my game AI course was to build an AI for a modern board game.  My team selected Pandemic, a cooperative board game in which players need to both travel around preventing diseases as well as hoarding cards to “cure” diseases.

Emboldened by the success of my very simple AI for Mario Brothers, my team opted to use a simple search-based algorithm for evaluating pandemic moves.  In our implementation, game-state objects represented the state of the game, and had the ability to return all the legal moves available in a particular state.  These various moves could generate new GameState objects that represented the state after the move was performed.  This let the AI avoid understanding the many effects of various moves – the AI could simply “simulate” the move and then evaluate the “goodness” of the resultant game state.

I think this a perfect example of the sort of solution that is quite obviously a dumb idea in retrospect.  To see why, consider the answer to these two questions:

1. How many moves are possible in any given game state?  Answer: approximately 10, as long as you eliminate certain high-branching moves.
2. How many moves do you have to look ahead to plausibly identify good states?  Answer: About 20-40.

If you pause to consider the magnitude of 10 quintillion for a second, I’m sure you can identify the problem with my team’s AI.  As a result, the search tree has to be pruned aggressively.  As a result of that, the AI adopts a short-term greedy stratgey that can’t win:

Pandemic AI Video from Michael Hewner on Vimeo.

In retrospect, I wish the instructor for this class has given us a more constrained problem for a final project.  Ninety percent of my team’s time was spent on details of implementing the game itself.  For a similar project difficulty, I could have implemented 4 more sophisticated AI approaches.

You can see the code here:

As part of the Game AI class I’m, I built an AI for playing levels of Super Mario Brothers (using this framework here…I didn’t make the mario game itself). This Mario AI trains on one specific Mario level somewhere between 1000 and 100000 times. It may seem pretty cool, but imagine how cool you would be if you played the same level of Mario every day for 275 years. I bet you’d learn a few tricks too.

If you want to see how I did it, check out the document here. But prepare to be disappointed: this algorithm is really super dumb, despite the fact that I used many unnecessary greek letters to describe it.

My Q-Learning Mario AI in Action from Michael Hewner on Vimeo.

So I have a new homepage at hewner.com. I’ve been thinking for a while that I ought to have a page with my various research, teaching, and programming stuff that I would be comfortable pointing folks to, so I’ve upgraded the old buffaloblog into your one-stop Mike info-porium.

One of the consequences of this is a new url for my blog (hewner.com/blog for the blog and hewner.com/feed for the RSS)…but if you’re reading this through your feed reader then all the redirecting worked as I intended it. One thing I did discover in this process is that WordPress supports category specific feeds – so if you’d rather never again hear me wax philosophical about my attempt teach P/NP to cats .

I’ve had a lot of fun playing with WordPress in the past few days; WP strikes a nice balance between giving you the configuration features you need and letting you have at the code when that needs to be done. The plugins I ended up using are:

• Akismet and Bad Behavior – Avoid blog spam
• List Category Posts – Lets me put blog post summaries on the Teaching and Programming pages
• Excluding Pages from Navigation – Lets me have extra pages that don’t appear in the navigation. I really don’t know why this feature doesn’t exist by default.
• Online Backup for WordPress – Backup WordPress DB
• Syntax Highlighter Evolved – For code snippets
• Twitter for WordPress – Twitter feed on the side
• This post helped me set up the old buffaloblog urls to redirect to the new hewner.com urls

Anyways, feel free to check out the new homepage and let me know what you think.

So I was digging through my archives as I revamp the venerable buffaloblog to serve as my main homepage. I found a video we had to produce as part of the 2007 Ubiquitous Computing course where my group designed a bluetooth keyboard device. And it is so bad.

I’ve heard that Thad shows this video (or perhaps a later, slightly revised version of it) to current students as an example of a good project. Scary.

Video About the BlueTwiddler BlueTooth Chording Keyboard from Michael Hewner on Vimeo.