These are some questions I've been asked often. Before asking me a question, please check if it's already answered on here.
I don't really care which, to be honest, so don't spend too much time worrying about it. However, if it's very obviously Math Advance related (MAT, MAST, etc) you probably should email the Math Advance email. It may be worth noting that I'm getting more newsletter emails on email@example.com, since personal stuff defaults to there,
If any of the following conditions are met:
I am willing to help you setup mapm, migrate to it, etc. We've got decent adoption of mapm inside of Math Advance, I want to see if I can get a couple groups outside to use it.
If you're running a non-math contest and want assistance with mapm, my offer still stands. (Though of course I can't help from a non-technical standpoint, since I don't know anything besides math well enough to do so.)
Probably not (unless you go through MAST). Note that MAST is an AIME program, so if you/your student aren't quite at that level, I won't be able to instruct them. My hands are full with MAST at the moment, so I won't be teaching anything else in the school year. Email me anyway though, my schedule should clear up during the summer and I want to try a new introductory geometry textbook I've been writing, if you don't mind that sort of thing.
Yes; in fact, please do. I couldn't even stop you if I wanted to, that's the point of open source. (If I didn't want you to use it, I wouldn't have made it public, would I?)
I'm curious by disposition though, so if you're using one of my projects, I'd appreciate it if you sent an email letting me know. That way I know which of my projects has the most reach, which is one of the factors I consider when deciding what to work on.
I use the following stack for frontend:
Node JS + React JS + Next JS + Tailwind CSS + MDX
Perhaps some of these tools are unfamiliar to you. Here's a quick summary on what each of them do.
Now, it's important to understand that each piece in a stack is orthogonal. They are not related to each other at all. Sure, there are integrations that make them play together better. But if you don't like a certain piece, just substitute it for something else. And above all, understand the general role that each piece of the stack serves.
As for backend, we use Firebase in the MAT website, and MongoDB for the MAST website. We have our own server for the MAST website, and we're not using Mongo Atlas.
Before you ask "how" ask "if" you have to. Programming is agony, but websites are especially horrid.
If you have to do something complex (typically the measure for "complex" I use is: does anyone need to have an account on your website?) then the whole Node JS ecosystem might be justified. If you don't have a server and don't want to pay for one, then use Firebase. Otherwise you can run a server-side instance of Mongo or whatever database strikes your fancy.
I regret using Next JS for my API. JS is far too unreliable a language for this sort of thing, you should use something sane like Rust to construct your API. Django also seems worth trying, given that it is super batteries included.
No matter what you choose, you can't get away with not knowing the fundamentals of server-client communication. (Hint: your website is the client.) Assume all actors are malicious, be aware that your server is basically an amnesiac, all data must be stored somewhere and that somewhere is the server, etc.
TeX Live hands down. Particularly if you are using Windows, which is probably the reason you'd ask such a question. The installation/setup process has a lot less hiccups, particularly with Asymptote.
Also, if you are using Windows, you might want to consider not?
I'd use IRC and would for most other projects but want mapm to be a little more beginner friendly. Plus, I can't be bothered to set up an IRC bouncer and I don't want to, chat is ephemeral. Speaking of beginner friendly, I also mean culture-wise: Zulip is a lot closer to Discord than IRC is. In particular, copy-pasting long code snippets is frowned upon in IRC and not in Zulip (at least as far as I know). ↩
If we're splitting hairs, React is really more of a library than a framework. ↩