I’ve been a Professor for almost 13 years. During these 13 years, I have seen investment in routine academic IT infrastructures decrease steadily, while at the same time being encouraged/pushed to use commercial infrastructures. Academic administrators seem to be mostly preoccupied with the 1% of academic work that requires high performance computing, large clusters and super high speed networks, and don’t pay much attention to the everyday needs of the other 99% of academic work. This puts research integrity at risk, but hey! — it’s hard to attract money for a vanilla storage system that is used for everyday computing, and for the sys admin that goes with it, especially when so many commercial cloud providers give things for free to Universities; you need to add bells and whistles and throw in a few buzz words like “cloud” and “big data” to get people impressed. Fair enough.
I finally got fed up with commercial solutions, for reasons that I explain later, and decided to set up my own IT infrastructure that fits exactly my needs and those of my group. I thought I’d write down my take on this. I suspect lots of colleagues have the same struggles. Continue reading
Quote from an email I received from a prospective PhD student:
I get the impression that if doing a PhD is really going to help push me forward on this, I’ll have to be working closely with people from that whole milieu surrounding the ’80s/’90s Common Lisp scene and the heyday of PARC. There seem to be not too many still around who are still doing work along the same lines and who could serve as thesis advisors. I joke with my friends that it’s like trying to train under an old Jedi master – you’ve got to find their hideout in the swamps of Dagobah.
Sit down, younglings. Let me tell you the story of the Jedi Masters.(*)
A Long Time Ago in a Galaxy Far, Far Away…
This is a post about CS education. It is prompted by a series of posts by Mark Guzdial in which he criticizes the pervasive belief among CS educators that when it comes to programming, there’s not much an instructor can do: some students get it, others don’t; it’s all in genetics or other external factors that CS educators can’t influence (aka the Geek Gene Hypothesis). I am with Mark on this, but I feel a bit stronger about it than he does. I think that attitude is bullshit, and the studies supporting it are unsound by means of making conjectures ignoring an enormous number of confounding factors.
Throughout history, and even today in certain parts of the world, attitudes like this have been the basis for keeping entire segments of the population uneducated (“teaching women to read and write?! seriously, they can’t do it, look how much longer it takes for them to learn” or “blacks in Universities?! seriously, they can’t do it, look how their grades are so much lower”). This is basically the attitude of a class of educators who live so much inside the box of convention and intellectual lazyness that they are uncapable of seeing the big picture. I know this, because of two things. First, after the first few years of being a professor, my conclusion was the same: there’s nothing I can do, some students get it others don’t. I’ve learned a few things since then, and I know I was completely wrong. I was being a “Null Professor” at the time. Now I know better. Second, looking back at my own experience as a college student I was one of those students who “didn’t get it” at first. In fact, I had no idea what I wanted to do when I grew up, and in my Electrical and Computer Engineering program, programming was one of many topics that came my way; understanding and learning to love programming was a slow process that came only in my 3rd year of college.
Let me expand on these two points. Continue reading
I just came back from a week at Hacker School in New York — they invited me to join them as a resident. I thoroughly enjoyed the experience and, before I forget, here are my impressions and a bit of a comparison with the more traditional educational programs that I’m used to.
I have been meaning to put a few of the chapters of my book here. The Code Golf Style is one of my favorites; fun too, and a crowd pleaser! I’ll start with it. Here is the complete Code Golf chapter.
Before I do that, here is the post I wrote some time ago explaining what the book is about; you may want to read it. TL;DR: 33 different styles of writing a term-frequency program — count words in a text file, excluding stop words, print the 25 most-frequently occurring words in decreasing order. The emphasis of the book is on the constraints behind each style, as the task itself is trivial on purpose. All the code is in github. In my courses, my students go through these exercises one by one, rewriting them in their favorite programming language. It’s… a challenge!
Back in September, I blogged about one of the the most amazing conference experiences I ever had, the OpenSimulator Community Conference (OSCC’13). This was a 2-day, purely virtual conference with a total of 360 attendees, held on an OpenSimulator virtual environment hosted here on one of my super-duper servers. I’m one of the core developers of OpenSimulator; I do it partly to keep my work in software research real [by means of being in the trenches of a complex server with a relatively large user community] and partly because I love to use virtual reality environments, and use my vLab on a daily basis.
This post explains some of the optimizations that I made to OpenSimulator last summer so that it could actually support this event. This is the summary of a paper that will be presented at the Summer Simulation Conference, joint work with my student Eugenia. The preprint, pre-revision, version of the paper is available here.
(The work described in the paper and this post focuses on only one of many improvements that were made last summer by several developers.)
I’m happy to announce that my book Exercises in Programming Style is now available for pre-order from Amazon, and that it will be shipping starting June 9! This is the book behind the talks I gave last year at StrangeLoop and GOTO. This is the story of how this book came to life, the inspirations behind it, and what the book is trying to do that is different from the hundreds of textbooks about programming.
I’m officially making up these new words, because they correspond to activities that I do on a regular basis and that I need to convey to my students. I hope that by giving these concepts their very own words, they will lose the threatening overtone that these remarks usually come with — because students will realize that these are all very common problems indeed!
One of the most brutal things to adapt in life after college is the sheer amount of feedback, criticism and rejection that come with real life. This happens in just about any direction one decides to go: graduate school, industry, public service or self-employment. It may not feel that way for students, but school is an overly protective environment; getting a C or even an F may seem like the end of the world at the time, but that’s nothing compared to doing the best we can in a project/job, giving it all we have, just to hear from someone we respect that what we’re doing is not good enough. I’ll talk about Academia because that’s what I know best, but these observations apply in general.