8 weeks and 60 students with Cloud9 June 11, 2014
I would like to finish my series on teaching web programming with a report on how the online IDE Cloud9 helped improve my students productivity.
As you might know if you read French newspapers, UVSQ is a university on a low budget. The department has only one computer room, and it is best avoided. Students bring their own laptops to tutorials, or they can borrow one from the library.
When I gave my course the first year, several precious tutoring hours were lost installing, configuring and debugging WAMPs, LAMPs and virtual machines. The switch to Node.js eased things up: installation was generally smooth, apart for some version problems on Ubuntu machines and missing SQLite interfaces for Windows. Both years, I had to teach the students, especially those not on Linux, how to launch and use a terminal.
Having decided to go back to PHP, I absolutely wanted to avoid the painful installation of Apache and stacks. The cloud IDE Cloud9 looked like a promising alternative, lifting the burden of handling dozens of different configurations.
Cloud9 is a commercial product, offering free unlimited workspaces for public development, plus one private workspace. It has some integration with GitHub, BitBucket and Heroku, and some limited history and collaboration features are also available for free accounts. It can natively execute and debug Node.js instances, or run PHP applications via Apache (other runtimes are also supported). It includes a MySQL and a MongoDB server for development.
Thanks to Cloud9, the only problems left to solve on the first tutorial were laptops not connecting to the network, and students having confirmation emails from Cloud9 delayed or blocked by their provider.
Once they were connected to the Cloud9 dashboard, the students could get started coding immediately by cloning the project skeleton I had hosted for them on GitHub. From then on they could work on their project (no knowledge of git required), while I could update their configuration files by asking them to pull. Some students eventually managed to mess with their local git clone, but fixing it was a minor annoyance overall.
Previewing static html files and running apps is as easy as a button click: all students quickly caught the workflow, although some of them were slow to grasp the difference between viewing static files and running apps.
Because all projects are public, I could connect to the students’ workspaces at any time and observe their work live. This was useful in the classroom, but even more important when addressing help requests out of the class. The embedded chat room was also very useful when helping students from home. Beyond the IDE front-end, each workspace also offers a publicly accessible webdav directory. This let me easily crawl and download all the students’ work for local examination and grading. I found this very convenient for the first part of the course, where only client code was involved. At least in one case, my local copy also served as a back-up save for a student who had accidentally erased all her work.
However, visitors to workspaces do not have the rights to run processes, hence they cannot run server code. When the students started writing server code and using SQL, reproducing their environment locally turned out to be too painful. Thus, I had to resort to asking them for write permissions on their workspaces, which also turned out to be a very convenient way to help them fixing Cloud9 glitches from a distance. In retrospect, I should have asked write permissions from the beginning.
Finally, some comments on cheating. Yes, any student could see any other student’s work, if he could guess his colleague’s login and workspace name. This is in my opinion very good, and most students used it constructively: taking example from their comrades’ code, using the chat to help each other, and even collaborating on code. Obviously some students didn’t refrain from using it to cheat, and some went even as far as creating Cloud9 accounts with logins similar to mine, so to not awake suspicions in their comrades. In reaction, some of the good students created accounts with unguessable usernames, or used the one free private project.
However it wasn’t too hard to unmask the cheaters. My own plagiarism detection scripts helped me narrow down the hunt, Cloud9 history tool did the rest: by rewinding history, I could easily know when the students had been working, when the copy-paste had happened, and what variables had been renamed. Not only I had a very easy time detecting cheating, but I even had irrefutable proofs of it.
Cloud9 wasn’t all joys and wonders. For one, it requires a good network connection to function properly. Wifi connections, such as eduroam, are likely to give a horrible experience. As obvious as this may sound, some students kept forgetting or refusing to bring ethernet cables: I had to always bring a stock with me.
Even on a wired connection, though, most students experienced serious problems. The IDE would often lock one file or freeze completely, the only solution being reloading. Before I prompted the students to enable auto-saving, network errors would occasionally destroy one hour worth of work. After they enabled auto-saving, some students experienced severe slow-downs of the interface, and even then some work was occasionally lost. Sometimes, after recovering from a freeze, some files would be empty; a peak at the history would usually yield all the contents back, but restoring previous versions is horribly clumsy in the free version of Cloud9.
About a dozen of workspaces got locked at some point, with the interface simply not able to read the filesystem. This required the intervention of Cloud9 staff, often holding the student from working for the rest of the day. In March, we were also unlucky enough to experience a major platform problem affecting POST requests right before a submission deadline.
Overall the use of Cloud9 turned out to be very frustrating for some students. I wonder if the time gained by not having to install anything locally wasn’t compensated by the time lost fighting Cloud9 glitches. Thankfully, Cloud9 staff was very kind and responsive, and usually solved all problems in one day’s time.
To my surprise, more than 50% of the students thought very well of Cloud9, grading it 4/5 or 5/5. In the end, I think the experiment turned out well, and, whatever platform I am going to use next year, there is no going back to the dear old local install. Beyond being stable and not loosing data, my ideal platform would:
- Use Cloud9 IDE as front-end, or similar.
- Let me manage my group of students, view their projects, and automatically grant me write privileges on their repositories.
- Keep history robustly and often (e.g., using auto-save and Git).
- Do not allow the students to create multiple logins, and force them to be connected in order to use the platform.
- Simplify some workflows (e.g., using the MySQL database).
- Redirect PHP logs to the IDE console.
Maybe this can be achieved by installing the open source version of Cloud9 on a university server with a customized back-end. I will likely be experimenting with this before next year’s course.
For reference, I report here some non-trivial configuration details and bug fixes that I had to apply during the course.
Due to bugs in Cloud9, or to bugs in the students code, the interface may freeze repeatedly. While it is not guaranteed to work, adding
php.inifile is placed in a Cloud9 workspace, its settings supersede the global ones. This has various uses: activate sessions, printing errors, etc. One important use for Silex: the PHP package manager Composer wants the setting
date.timezoneto be set.
Integration with PHPMyAdmin is sure in the plans for Cloud9, but not ready yet. The simplest solution for me was to ship a lightweight open source MySQL manager, SqlBuddy, together with the project skeleton.
One of the most annoying bugs, happening almost systematically, prevents the MySQL server from starting after a workspace freeze. This is a known bug with a fix documented here, but, had I known it before, it would not have hold so many students for the entire tutorial following spring break (during which many workspaces froze).
Finally, one of the most random problems was caused by GitHub. The students working with Silex had to install it in Cloud9, together with its dependencies. I had given a
composer.jsonfile, so that they just had to run Composer in the Cloud9 terminal in order to download and install everything. Composer connects to GitHub’s API, and GitHub limits anonymous requests to 60 per hour per IP. Since every user in Cloud9 has the same IP, chances are that some student may get rate limited. Fortunately Composer will fail with a meaningful error message, and will ask for a GitHub login in order to solve the problem. Unfortunately, the average student will not have a GitHub account, and will not understand what the message is asking for, so if this happens outside the class, expect an email. I was lucky: this happened only once. Another fix is described here.