cocalc

Probably LISTEN/NOTIFY. I explain in detail how I migrated from RethinkDB to PostgreSQL using LISTEN/NOTIFY + tons of additional work here http://blog.sagemath.com/2017/02/09/rethinkdb-vs-postgres.ht... I've continued working on this codebase, even pushing commits this week like this one: https://github.com/sagemathinc/cocalc/commit/c20a62446b6e43c...

I recently built a complete node.js Jupyter server on top off https://github.com/nteract/spawnteract (also used by nteract). There is no Python involved at all unless you connect to a Python kernel. Some of the code of what I wrote: https://github.com/sagemathinc/cocalc/tree/master/src/smc-pr... I'm not suggesting you use what I wrote. I'm just pointing out that there exist alternatives to the Python-based Jupyter server that accomplish the same goal. And I strongly agree with you -- it would be great to have even more implementations of the server part of the Jupyter stack!

I’m also a software dev who has been painfully dogfooding an iPad Pro 10.5 fulltime for development of CoCalc/SageMath for the last few weeks. I even opened (and fixed) a bunch of bugs in our site as a result: https://github.com/sagemathinc/cocalc/issues?utf8=&q=label%3... I’ve been using iOS 11 beta3. Surprisingly, there actually exist some clear advantages over most laptops: Physical Hardware Advantages over laptops (not over surface pro): - More cameras (e.g., an extra 12MP camera on back); you can easily snap a picture or shoot video. - The iPad 10.5 weighs 1 pound, which is way less than most notebooks; it is EXTREMELY portable. - Portrait mode (i.e., rotate screen) with no keyboard, which is useful, e.g., for reading pages of technical documentation. - No trackpad, so the keyboard/bottom takes up much less space, meaning you can

The price for g1-small also increased from $0.021/hour to $0.0257/hour. Here's the diff for where I track this: https://github.com/sagemathinc/smc/commit/13edcd3772daf07d0d...

This is a very valuable article about what it would take to do such a migration. I also work on a large CoffeeScript + React codebase (https://github.com/sagemathinc/smc), write a lot of new CoffeeScript every day, and I have no plans to do a rewrite. I just don't see the value of doing a rewrite, given how hard it would be. I like CoffeeScript, find it expressive, and I think it would be easier to fix or maintain the relevant CoffeeScript tooling than to do a rewrite (just because a rewrite would be so damned difficult). Also, CoffeeScript really is sufficiently close to Javascript, and it interoperates effectively enough for now. CoffeeScript is not totally dead. There's pretty regular activity this month (see https://github.com/jashkenas/coffeescript/commits/master). That said, personally, I find the stability of CoffeeScript to b

> EDIT: after thinking about this for a while, I wonder if the RethinkDB changefeed scenario is doable with the tools in PostgreSQL: get initial user data, then get all subsequent changes to that data, with no race conditions. It's easier if you do things in the other order, and can make assumptions about the structure of your data. In my implementation, I have to first start listening for changes, then do the initial query (relevant code: https://github.com/sagemathinc/smc/blob/ce594ff0574ce781bf78...). As you say, race conditions aren't an issue for some applications. For me, (slightly simplifying) the main table that involves changefeeds is a table of (timestamp, patch) pairs, and for it, race conditions aren't an issue -- you get the data in whatever order you want and merge it on the client. I'm definitely making no claims to have

I also had to write JSONB deep merging as part of this RethinkDB --> PostgreSQL rewrite. Here's the code I wrote https://github.com/sagemathinc/smc/blob/ce594ff0574ce781bf78... That code constructs a single complicated query; I wonder whether I should write it as a stored function in the database instead. (I'm the author of the blog post.)

I added code to my clients to do "SET enable_nestloop TO off" anytime they connect to the database. This sets a global flag for that session, which disables nestloop query planning. It could indeed impact other unrelated queries, which is deeply disturbing, but I don't know any way to disable nestloop query planning only for a specific query (aside from constantly setting and unsetting that flag?). Incidentally, here is an example of the query that causes all the trouble: "SELECT * FROM file_use WHERE project_id = any(select project_id from projects where users ? '25e2cae4-05c7-4c28-ae22-1e6d3d2e8bb3') ORDER BY last_edited DESC limit 100;" Search for nestloop in https://github.com/sagemathinc/smc/blob/master/src/smc-hub/p... to see my relevant client code.

Author actually linked in the following paragraph, I believe the referenced bit is mostly here: https://github.com/sagemathinc/smc/blob/master/src/smc-hub/p... Looks pretty nice!

The flexbox bugs: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=flexbox... E.g., "Firefox slow to the point of hanging when rendering nested flexbox layout with overflow-y: scroll", which is trivial to reproduce, and which all other modern browsers handle fine. In fact, anybody who visits our product's site using Firefox is given a warning to use any other browser: https://github.com/sagemathinc/smc/issues/1314