(not the author, but I'm an Urbit core developer, so I can read this pretty easily)
You're pretty much correct. lib/server.hoon doesn't "set up" the server exactly, that's built into Urbit. In general, apps communicate by sending commands ("poke") and subscribing to data ("watch"). A normal HTTP request is just a poke of type "handle-http-request". The js frontend can also subscribe to your app.
lib/server.hoon is a (mostly standard) library of helper functions that mostly convert from various internal types to HTTP responses, so they add the the HTTP response code, mimetype, octet-stream length, etc. There's also a function that wraps an HTTP response handler to redirect to the login page if they're not logged in. Most apps that have a web interface use these functions, though I think the author may have added a few more filetypes.
app/canvas.hoon, as you guessed, manages the main state of the app and syncs it to other urbits. An app's commands can be seen in +on-poke, which in this case calls +handle-canvas-action, where you can see all the different commands this app takes. For example, %join subscribes to the "canvas" app on another urbit on path /canvas/foo where "foo" is the name of the image. The rest of the commands can be traced in the same away. +process-remote-paint is the part that actually processes a new list of strokes from either another ship or the %paint poke; it updates its own state and gives updates on /canvas/foo.
app/canvas-view.hoon is the app that serves the html/cs/jss and handles browser requests. It has a similar set of pokes, and most of them are just forwarded to app/canvas.hoon, but some of them are handled directly. This is a different app from canvas.hoon to keep separate the essential logic of the app from the work needed to serve it to a browser. One could imagine writing a command-line app which used canvas.hoon, and it wouldn't need to talk to canvas-view.hoon.
Probably a few months for a really usable version of it, though seeing stuff like this makes me really want to finish that work. I'm working on it, but first we're reworking the software update process in general. That work is getting pretty close.
I recommend trying out stuff like this on moons, so you can just throw them away if it breaks.
That's what I'm currently using, but I think a gif/video would work better for my program. My recording is supposed to run at ~10fps and the asciinema web player can't keep up. I get less than 1fps on the first play-through, and it dips as low as 2fps on subsequent plays.
Very cool. One of my formative programming experiences was learning the "hashlife" algorithm, which lets you do very large maps and zoom forward millions of iterations very quickly.
Seven weeks ago there were ~100 cases in Wuhan, now there's 60k. What's to stop that from happening in Seattle, or the Bay, or anywhere else in the developed world that isn't taking the precautions China did?
Absolutely nothing. It is likely that Seattle is already out of control. But, we won't know how bad its going to be for a week or two. King County buying a motel to house sick people is rather telling. Its an action that suggest they know it is going to be bad but don't want to say so and freak people out.
I think it is going to be worse in the US than China. We have an individualist culture that routinely goes to work sick.
It's frustrating. We have no office hours and staff can work anywhere with internet - and anytime so long as they get work done. They are salaried no incentive to show up at offie whatsoever. We've sent emails, reminded at in person meetings. Yet they still show up coughing. One employee like every minute a dry cough.. We talked to them in person, sent them home. And then they show up two days later same cough if not worse! The excuse: i had an in person meeting!!!
drives me insane. I can only do so much and really feels like the only thing I can control is my exposure but I don't want to over react and become a hermit
if we cant get our salaried staff who can already work from anywhere to stay home I feel scared that there's no way in hell hourly service workers would do it.
There are at least 6 people on my team who come into work when they are sick. All of us can work from home, have excellent medical insurance, and are on salary. I asked in a staff meeting and was told that telling or suggesting people go home violates their right to privacy.
This is going to be the real issue, in my opinion. People will go to work sick because they have no other choice. And it'll spread. And, who knows, we might even have some crazy-ass cult here that purposefully goes in sick and tries to spread it (I read an article that Korea had a cult like that).
Can't read the article because the captcha won't load, but this reply doesn't make any sense. What can the browsers do without the cooperation of the server? You don't really need encryption to deal with that specific problem, but you do need signatures, which means you need a certificate anyway. It's quite a strange attitude toward the problem.
Notably, this thread is full of people blaming SB Nation for not converting IC's to employees, which is exactly what they say they're going to do, though not everyone will end up with a job at the end of it.
You're probably right, but I see nothing about them not hiring some people in the announcement. They do say some people will probably not want to leave their current jobs. They also say everyone will get some amount of money for notice. Sounds overall pretty good of them, if they actually do it
You're pretty much correct. lib/server.hoon doesn't "set up" the server exactly, that's built into Urbit. In general, apps communicate by sending commands ("poke") and subscribing to data ("watch"). A normal HTTP request is just a poke of type "handle-http-request". The js frontend can also subscribe to your app.
lib/server.hoon is a (mostly standard) library of helper functions that mostly convert from various internal types to HTTP responses, so they add the the HTTP response code, mimetype, octet-stream length, etc. There's also a function that wraps an HTTP response handler to redirect to the login page if they're not logged in. Most apps that have a web interface use these functions, though I think the author may have added a few more filetypes.
app/canvas.hoon, as you guessed, manages the main state of the app and syncs it to other urbits. An app's commands can be seen in +on-poke, which in this case calls +handle-canvas-action, where you can see all the different commands this app takes. For example, %join subscribes to the "canvas" app on another urbit on path /canvas/foo where "foo" is the name of the image. The rest of the commands can be traced in the same away. +process-remote-paint is the part that actually processes a new list of strokes from either another ship or the %paint poke; it updates its own state and gives updates on /canvas/foo.
app/canvas-view.hoon is the app that serves the html/cs/jss and handles browser requests. It has a similar set of pokes, and most of them are just forwarded to app/canvas.hoon, but some of them are handled directly. This is a different app from canvas.hoon to keep separate the essential logic of the app from the work needed to serve it to a browser. One could imagine writing a command-line app which used canvas.hoon, and it wouldn't need to talk to canvas-view.hoon.