As opposed to Spark, the microcontroller platform. As opposed to Spark, the resilient distributed data system. As opposed to Spark, the open source IM client.
Is it really that hard to add 5 lines of boilerplate to your nginx conf? You can probably just copy-paste an existing server{} block or sites-available file and change the root directory. As a bonus, you'll learn a bit about how to configure the same tool you'll use later in production.
I'm so sick of seeing this pattern of 1) person makes tool they find useful, 2) person releases tool publicly for free, 3) other person comes across tool but doesn't find it useful, 4) other person publicly denigrates tool as being universally not-useful.
@dangerlibrary simply says: Do not re-invent the wheel. I cannot see any real-world production environment where this new server is better approach then activating a tiny config file. Thus, it is a very good lesson to the author: Use what is out there and build what is missing.
I very rarely see a "hey I made this!" post here that doesn't include one or more comments along the lines of "this already exists!". I don't mind these sorts of comments when they tell me something I didn't know - "you can achieve something similar by doing coodle with well-known tool doodle!", "there is somewhat-obscure tool foodle that does exactly this!" - there are some comments like that in this thread. What I dislike is when these sorts of comments are along the lines of, "you should have just done the thing that you made the tool to avoid having to do!". It is just dismissal and leaves nobody the wiser.
It seems delusional to think that this sort of comment is somehow a good learning experience for a library author. Everyone knows that you shouldn't reinvent the wheel, but there are reasonable disagreements on what exactly that means.
It's your tone more than anything. I read some of your previous posts to see if you were a d-bag and I came to the conclusion that you're not[1]. This reads more like the post was a button-pusher for you. I can relate. :)
Unfortunately, even with the tone removed, the comment hits that "top-voted middlebrow" button for many of the other people on the site. I would however say that for TFA itself as well.
[1] the opinion of some random interdweeb carries a lot of weight, I know. :)
Your initial comment, however, is filled with a denigrating tone. It is that tone your parent is addressing. Not so much the content. The tone. It is unkind.
You still need to stop the existing web server to get spark to take over port 80, and restart it when you are done, so it's not quite that simple.
Also, it's not hard to keep a maintenance conf file around, pointing to a different directory. At least, it's certainly no harder than downloading a second web server. Then it's just "sudo ln /etc/sites-available/maintenance /etc/sites-enabled/conf"
Except, that's not the use case for Spark so it's an apt comparison.
> Emergency web server
> For those occasions when your webserver is down and you want to display a quick maintainance note. Or just want to quickly demo a static site. Or whatever :)
Yes it is. The use case is when your site is down and you want to tell people that. If you have even a small amount of traffic `python -m http.server` is going to die, this isn't.
Yes, but, trivial c programs statically linked with glibc can be in the ballpark of 500KiB, trivial c programs statically linked with uclibc or similar can be in the ballpark of 100KiB, and trivial go programs (always statically compiled) can be 2-5 MiB. They're huge.
I can't see anywhere in the code so assume this returns a 200 code for requests. If was using this to show maintenance for my website would want it to return 503.
you have to get used to get go's backwards type declaration. This is defining a method on h which is a byteHandler struct called serve which takes a http.ResponseWriter and Request and returns nothing.
This is from the http.Handler interface, so defining this method causes byteHandler to conform to the http.Handler interface.
byteHandler is not a struct it's a byte slice. This is actually somewhat important since it highlights a nice feature of go where you can declare methods on any baseType by aliasing them to your own type.
There is no struct involved here and there doesn't need to be which is nice.
I've found that when discussing Go, the terms `struct` and `type` are usually used interchangeably. Yes it's factually incorrect, but the message is at least intelligible.
