Ubuntu Unity is pretty much unusable in 2 GB RAM.


California-sponsered open textbooks

Via Creative Commons: California passes groundbreaking open textbook legislation.

Hopefully we’ll get at least one solid CS textbook out of this. There are open texts for CS0, CS1, and data structures, but the air gets pretty thin once you get into higher altitudes.

I’ll be following this as it develops, since it might be a way to move forward on the open, accessible algorithm textbook idea I’ve been kicking around on the backburner.

Also, I’m happy to see they went with CC-BY, a well-established and permissive license, rather than introducing Yet Another Watered-Down Open License.

Visual Studio, foot, gun

For some reason, if you’re debugging in Visual Studio and step past the end of main(), the debugger keeps on trucking, and lets you step through all sorts of weird low-level system code related to shutting down managed VMs, or something equally arcane.

And, for some reason those low-level system source code files are all user-editable and writeable.

So, you’re one typo-and-save away from ruining your whole Visual Studio installation.

Today a student did that. And, woefully he changed a header file to include itself. So he kept getting an error message about the preprocessor exceeding a recursion depth limit, and not anything remotely helpful.

I’m usually an advocate of teaching programming with real-world tools, but that approach is not without its flaws.

(And I can’t resist pointing out that Linux/Unix file permissions would have nipped this in the bud with an apropos write access failure. One of the hundreds of little reasons why Unix is a friendlier development environment.)

Kinesiology interdisciplinary app

Anthony Darmiento, a CSUF Kinesiology grad student, is looking to collaborate on a project. This could be a suitable MS Project/Thesis topic. Anthony writes:

My name is Anthony Darmiento and I am currently graduate student at CSU Fullerton studying Kinesiology. Per graduation requirements I am working on a project and require some collaborative help. The project involves creating a device related to sport performance and exercise. Specifically, the device measures kinematics of a barbell (weightlifting bar) in a way that no device out there is currently capable of matching. This device will have practical application related to Olympic Weightlifting, Powerlifting, Crossfit, Sport Performance, Strength and Conditioning and many other areas of fitness, exercise and training. If you have one or more of the skills desired below and are interested in collaborating on the design and creation of a state of the art device please contact Anthony Darmiento at Darmiento.anthony@gmail.com

Individuals with experience in one or more of the following areas are the best fit:

  • Microcontroller programming (C language preferred)
  • Digital/Analog Filter Design.
  • Experience with wireless communication protocols (Wifi, Bluetooth…)
  • PCB Design experience.
  • Objective-C (iPhone app/iOS development)
  • SQL or other querying language (database creation and integration)

“Computer science is a liberal art”

So says Eugene Wallingford. I can’t say I disagree with his thesis. A similar argument is made in the preface of How to Design Programs (a classic!).

(Hat tip to Daniel Lemire.)

Conference talk crash course

If you got a paper published in a research conference, someone needs to give an oral presentation, conventionally with digital slides, at the conference. This can be intimidating, but remember that this is a good problem to have. Your work went through a rigorous and selective process, and was chosen to be one of the few topics showcased at the conference. Some of the most esteemed members of the international research community will set aside time to hear your ideas. Exciting!

Conferences typically operate on a compressed time frame that only gives presenters a few short weeks to prepare their presentation. Generally, in a student-faculty collaboration, the student gives the talk, since they are in greater need of notoriety and public speaking experience. So, it’s not uncommon for a student to need to learn how to give conference talks, and develop their presentation, in a very limited amount of time.

Here is my crash course on how to do that:

  1. Read this page in its entirety.
  2. If you haven’t been to a CS research conference before, watch at least 2-3 videos of academic research talks. You can find many on the FOCS website. The goal of this exercise is to observe the tone and pacing of conference talks, and reflect on what seems to work, or not work. Keep the advice in (1) in mind, and critique the extent to which the talk was clear, interesting, and received well.
  3. Pick a presentation software package and write a rough draft of your slides. I prefer using LaTeX to create slides, since that lets me copy math notation and figures directly from the paper manuscript. The most popular LaTeX packages for slides seem to be Beamer, Prosper, and  seminar. You could also use a GUI program such as PowerPoint, OpenOffice Impress, or Apple Keynote, but you may need to reformat your math and figures, which has the potential to become a time-wasting distraction. This decision is not crucially important, so don’t spend too long on it. Whatever you use, generate a PDF file, since that is more likely than a proprietary format such as PPT to be seamlessly compatible with the podium computer.
  4. Follow the Generic Conference Talk Outline in (1). That outline is a conservative, uncontroversial structure that will work fine. It’s a “nobody ever got fired for buying IBM” sort of deal. In my opinion it’s a bit cliché and tired, but your first talk is not the place for avant garde experimentation.
  5. Check the conference website to see how long your talk should be. 20 minutes is common. Budget about 3 minutes for audience questions and interjections, and 1 minute for the logistics of transitioning to the next speaker, leaving about 16 minutes for you to present content.
  6. Based on that time limit, and the heuristic of 2 minutes/slide, you will be limited to about 8-10 content slides, not counting front matter such as title, outline, or acknowledgement slides.
  7. Iterate. Get feedback on your slides from your coauthors, adviser, or peers. Conference talks are expected to be polished, and to achieve that you’ll need to go through several rounds of revisions.
  8. Practice. Go through the entire talk, speaking out loud, at least twice. Pay attention to your running time, pacing, and areas where you tend to stumble. Speakers almost always run longer than they expect; speech is slower than internal dialogue. Ideally, you will have a chance to practice at least once in private and once in front of a critical audience.
  9. Try to have fun.

Programming project submission web application

I teach courses involving programming, but I don’t have a good way of collecting and evaluating student submissions. I think a web application would be a great way of doing this. I’m inspired by the Project Euler and UVa Online Judge systems, which allow users to submit short programs, which are then tested and scored automatically by the system. Those sites don’t work in the educational setting, though, where instructors need to evaluate submissions by their own criteria, enforce deadlines and plagiarism policies, and protect student privacy.

Implementing and supporting a complete system with every feature on my wishlist is far more than a one-semester project. I’d expect that a student could implement a prototype, with a minimal set of essential features, as a project. Then other students could add features and improvements in the future.

I think the minimal requirements for a one-semester prototype are

  1. Represent the following as first-class objects: user, class, class section, assignment, submission attempt, instructor assessment.
  2. Roles: site administrator, instructor, student.
  3. Instructors create, edit, delete, and administer classes, sections, and assignments.
  4. Students can associate with sections, view assignments, and submit assignment attempts.
  5. An assignment attempt is a single source code file for the C++ language.
  6. Assignments may have deadlines, after which submissions may not be made.
  7. The system validates the source code, to sanity check that it resembles C++ source, is of an appropriate size, and is not obviously malicious.
  8. Code that passes validation is compiled with g++.
  9. Code that compiles without errors is run, and tested for correctness against a set of instructor-provided input/output text files.
  10. Submitted code is run in some kind of sandbox to prevent attackers from doing something like deleting the entire filesystem. A chroot or FreeBSD jail is probably the easiest way of doing this.
  11. Code that runs too long must be killed to prevent a denial-of-service attack from infinite loops.
  12. The verdict of each submission is emailed to the student and visible to the student and instructor on the website. Possible verdicts are: upload error, failed validation, did not compile, exceeded timeout, incorrect output.
  13. Instructors may convert verdicts to numeric scores and export them to CSV files for the purposes of grading.
  14. All activity should be logged to a text file.
  15. Data should be stored in a form (e.g. database) that can be backed up, migrated to a different host, and exported to a human-readable form.
  16. Language must be something that I, and a critical mass of other CSUF students, know. Preferably Python, but I’m open to Java, C++, C#, Scheme, or Haskell if there’s a compelling reason. No PHP.
  17. Host code in a public source code control system (e.g. SourceForge or Google Code) under an open source license.

Future projects could add other important features:

  1. Support for Python, and possibly other, submission languages.
  2. More elaborate security precautions, such as running each submission in its own virtual machine, and reporting suspected malicious submissions to the site admin.
  3. Support multiple C++ compilation environments (Visual Studio, Xcode, *nix g++, *nix clang).
  4. Synchronizing user lists with Moodle.
  5. Synchronizing grades with Moodle.
  6. Automated plagiarism detection, perhaps using MOSS.
  7. Use CSUF usernames/passwords for authentication.
  8. More elaborate submission correctness tests. Perhaps incorporate ideas from unit testing. Or allow the instructor to provide a reference implementation.
  9. Fuzzy output correctness testing; ignore whitespace and capitalization differences, interpret “1” and “01” as the same thing, be robust to floating point rounding errors, etc.
  10. Runtime correctness testing; allow the instructor to provide a timeout value for specific queries. Even better, allow them to provide a big-O time bound.
  11. Group submissions.
  12. Additional roles: grader, guest instructor, guest student.
  13. A failure viewer that shows students the discrepancies in their program’s output that is causing it to fail. Incorporate ideas from diff viewers such as highlighting differences and collapsing identical sections.
  14. Multiple-file submissions.
  15. Support instructor-supplied data files that are moved into each submission’s working directory.
  16. Output file formats other than text; especially media such as images or sound files.
  17. Allow assignments to require supporting materials, such as a lab report in PDF format.
  18. Allow instructors to clone classes or assignments.
  19. Allow instructors to edit assignments offline.

There are a lot of ways to go with this. But right now I have nothing, so I’m more interested in getting the ball rolling than any of the particular requirements listed above.

UPDATE (10/16/2012): I’ve learned about two similar projects:

  1. Kattis
  2. moodle-local_onlinejudge

Rather than writing something from scratch, it may make more sense to build on one of those projects.