Quick thoughts on web tech for research
Once upon a time I worked on a web-hosted research platform for human-robot interaction. My colleague and I partnered to make a nice series of games which could phone home, log results, and show data.
It was built on JS, jQuery, Rails on the backend, and hosted on Heroku. I’d later rewrite the backend to be a much smaller node-based one. I think we may have been the first group to get ruby on Rails into an ICRA paper!
Now, part of the reason for this rewrite was to isolate the future generations of maintainers from having to learn Ruby, learn some Rails, and more on top of needing to know CSS/JS for their normal work.
Academic computing work, at least from what I’ve observed when using undergrads, happens very organically. There is no great continuity of project management, there is no great chance to refactor–it’s going to be copy-and-paste with minor alterations.
If you want to create a research tool in such an environment, you need to pare it down to the bare minimum of what gets the job done, preferably with as few dependencies and high-minded architecture patterns as possible. You basically want to make a Toyota Hilux, not a Ferarri. You want something the kids can hack on and understand.
Even in spite of this, notice that the DB connection to Swarmcontrol is broken. It looks like it has reverted to a free-tier of hosting. It’s hard to imagine how this could survive another ten years. :(
That incidentally is one of the reasons I despair so much for modern web tech and trends in a research environment:
- Keeping complicated systems up-to-date is hard.
- Students rotate through twice a year, possibly more frequently. Tribal knowledge is nil.
- Anything that requires “patterns” not self-contained in the work is going to be overgrown or thrown out.
- Modern web stack just requires knowledge of a lot of moving parts, which is fine, and very few resources seem interested in teaching the sum of those moving parts, which is not.
All that said, it was still a fun project. :)