Contact
CoCalc Logo Icon
StoreFeaturesDocsShareSupport News AboutSign UpSign In
| Download
Views: 2730

CoCalc talk (1 hour)

  • 20 minute live demo of cocalc itself

    • show list of all installed software: https://cocalc.com/doc/software.html

    • open demo project

    • create a jupyter notebook (with sage) and draw a plot (?), show time travel + collab

    • create a terminal and run Macaulay 2 (say) or Maxima or Axiom, and so something

    • sagetex

    • Rmarkdown

    • chat

    • add a collaborator

    • encourage people in audience to play around in this project, invite nearby people

  • 20 minute -- how cocalc works

    • small group/dev mode and scalable kubernetes-based mode

    • backend node.js server

    • frontend react.js application (tons of javascript - CoffeeScript and now Typescript)

    • realtime collab

      • custom implementation from scratch; undergone numerous complete rethinks based on usage.

      • first just for strings using the google diff-match-patch library and xxx's algorithm

      • replaced xxx's algorithm by revlog (with timestamp) algorithm I came up with; uses "changefeeds" (RethinkDB), and now LISTEN/NOTIFY in PostgreSQL

      • then database of structured objects with efficient update of strings

    • jupyter:

      • sheffield and R

      • realtime collab

        • monkey patched vanilla jupyter in iframe (and fallback)

          • first using strings

          • have to factor our large output and images

          • switched to a structured JSON format

        • new custom jupyter completely from scratch

        • timetravel

    • sage worksheets:

      • single document mode, rather than "cells" with lots of editors: fully leverage using a single documents (e.g., multiple cursors, find replace, range selection, etc)

    • code editor:

      • arbitrarily many simultaneous views on a document with a tree structure, like in Emacs (say).

      • sophisticated code formatting for many languages (like gofmt)

    • latex editor

      • code editor along with extra pdf previews, build info, etc.

      • special code for dealing with multiple users compiling simultaneously

    • Terminal

      • took term.js and added color themes, support for "open filename", different char sets, etc.

    • markdown/html/wiki editors with previews

    • Software stack:

      • Hundreds of gigabytes

      • Have to update every few days attomically, even though thousand+ of projects running

  • 5 minutes: business model (slides)

    • I hosted "online pari/Magma calculator" and "the modular forms calculator" at Harvard 2000-2005.

    • I developed, maintained and hosted sagenb.org (the Sage Notebook) 2007--2014, and learned a lot about the challenges of hosting something like this at a University:

      • attacks by hackers

      • malware

      • periodically getting our intenet connection automatically cut by the University

      • legal: terms of service violation by users (at a state university there are strict rules on "use of university resources").

  • I started SageMathCloud (later named cocalc) as a commercial project, not an academic one, to:

    • generate money to support sage development (so far cocalc has lost hundreds of thousands of dollars, unfortunately)

    • be sustainable (not depend on grants)

    • I personally work much better when I focus fulltime on things, and grants only reduce my teaching at best to 3 courses a year.

    • avoid issues with university hosting

    • I couldn't get grants anymore anyways, for some reason.

  • 5 minutes:

    • getting your software in cocalc

    • using cocalc to make your software and OSS more accessible

  • 5 minute - back to interactive demo with audience and Q&A

--------------------------

Ideas from @hal/@hsy:

explain how you can ensure software you write is available in CoCalc

Lots of potential here. You could expand this. Ways to make your software more student-friendly. Does not have to be a CoCalc infomercial. Horror stories integrating things into the CoCalc stack. One or two of these. Will be memorable if told with humor.

  • haskell (packaging system ?)

  • julia

  • gap kernel

  • swirl

Stuff that uses

  • nonstandard toolchain to build

  • esoteric dependencies

  • funky version control (hg, svn)

There are things that make software hard to use in any exploratory & collab setting:

  • console interaction (swirl again)

  • widgets

Things that invite students to fall into traps or get frustrated:

  • ballooning memory allocation without warning

  • or any other use of resources that doesn't play well with others - like jupyter notebooks running and running, which is why we put in the halt button on ours

  • crap error messages or just crashing on failure

  • going away for minutes at a time - am I working hard or stuck

  • no safety rails so a student can call the app with parameters that blow it up inexplicably

Teacher can make life easier for self (this could make some good conversations around the event):

  • write homework that is easy to grade in online setting

  • don't create materials deeply tied to teaching framework UI details - these change a lot - or isolate in separate short content that's easy to update

  • what sort of sample problems are more fun in collaborative setting?


sketch of current architecture

Highlight the cool things rather than going for completeness. The story of how CoCalc got where it is, and where is going (much of which we don't know yet) is amazing. It includes hard problems, drama, suspense, and some triumph. Maybe explore the state diagram for compute states in yesterday upgrades. How we use innovative combinations of storage and containers to make all this software available to users on-demand and cost-effectively, in a way that supports concurrency and robustness.


I think the cocalc talk could be about taking away basic "worries" ... for teachers, researchers and students. that covers installed software, but also having a safety nets for various aspects. e.g. my own computer isn't going to hang if it uses too much memory, data loss, much less overhead for sharing among collaborators, keeping one's own software stack healthy, being able to go back in time to a previous state of my worksheet/document in case something is broken, etc. teacher's don't have to deal with the computers of students, which I bet is still a huge overhead.