When Bruce gave me CS373: Software Engineering to teach in 2008, he asked that I make my students aware of the various software-development tools used in industry.
I barely knew any, but I’ve learned about many of them from my students and sometimes from the guest speakers from industry that have visited.
I’m now currently using the following:
git and GitHub for source control: I also now use this as a substitute for the old turnin program. Students provide us with a git SHA and we pull that particular commit to grade.
GitHub for issue tracking, too: Issue tracking tracks bugs and enhancements to the software. There’s also a very nice connection between git commits in GitHub and the closing of issues in GitHub.
pylint (Python) and clang-check (C++) for static code analysis: These provide additional checks beyond what the interpreter or compiler would provide.
unittest (Python) and Google Test (C++) for unit testing: Both are very much like JUnit. And probably the single most important thing that I teach my students is to write tests BEFORE writing code!
coverage (Python) and gcov (C++) for test coverage: It’s important to know what percentage of your code your tests are actually testing.
valgrind (C++) for memory checking: I only rarely allow my students to use new and delete, directly, but when they do, valgrind is invaluable.
cProfile (Python) and gprof (C++) for code profiling. This is of very limited value in my class, because none of my programming projects is compute intensive.
pydoc (Python) and Doxygen (C++) for automated documentation: Both are very much like javadoc.
autopep8 (Python) and clang-format (C++) for automated formatting: Everyone has their own favorite coding style. It’s very convenient when we grade for all submissions to have the same style.
NumPy (Python) and Boost (C++) for third-party libraries: Writing real software without making use of libraries is almost impossible, so I show a tiny bit of each of these.
Travis CI for continuous integration: The second most important thing that I teach my students is to set up a system that will automatically run all regression tests as a result of a commit. It’s also invaluable for students to get their software running on “naked” systems that they have to configure with all the dependencies that their software needs (e.g. all of the above).
Now, I’d like to tell you about my latest find. It’s hardly new, but however much I try to stay on top of things, it sometimes still takes me a while to become aware of a very cool tool out there for a particular purpose.
Docker is free and runs on Linux, OS X, and Windows, but it will not run on the CS machines, because it has to run as root.
Docker creates light-weight Linux virtual machines to run on top of your non-virtual machine.
Like Travis CI, the value to the student is again to get their software running on “naked” systems that they have to configure with all the dependencies that their software needs.
But, now, there’s another value, and this time it’s to the instructor.
It is often the case that my students don’t have the most up-to-date versions of the interpreter or the compiler or some tool on their laptop. When that happens I point them to the CS machines, and dictate that their submissions will be graded there, as well.
Now, with Docker, I can configure an image with a particular set of versions (some even more up-to-date than the CS machines have), I can publish that image to DockherHub (again, free, for public images), and I can ask students to get their software running with that image and we can later grade their submissions with that image.
I think that’s huge.
And I wanted to share it with all of you.