4 ms·

> each MD post is generated on request so I can update easily > if needed. You mean each client socket? If so that would be awfully slow for high volume traff

by bArray 7y ago

> each MD post is generated on request so I can update easily > if needed. You mean each client socket? If so that would be awfully slow for high volume traffic. > Only requirement is I have to restart the server to > rebuild the list of available posts in memory. This seems quite undesirable too, where does this requirement come from? > pull changes in on the serving machine Is this manually pulling or do you fetch in a loop? > will gladly do the work to share in a gist if anyone’s > curious. I'm certainly curious now to see exactly how this Go program works.

52-6F-62 7y ago
Like I said, my site isn’t and likely won’t be in high demand. But to your point: yes. Performance would be bad at high demand. (Also to note in case of confusion, when I said generated I meant rendered from MD to HTML) Each time I start the server, it gathers the posts by searching the post tree which is a directory ordered something like Posts > YYYY > MM So that it can display the list of available posts and generate the urls for each of them. For the changes I just manually pull them and restart the server. This wasn’t done as a proper engineering project. Just to learn some basic mechanics of the language. If you’re expecting a proper scalable, professional project you’ll be dismayed. That said I’ll happily see if I can get it cleaned up and add a link.
52-6F-62 7y ago
Haha oh man, I was speaking to you from a few versions ago and didn't realize it. I've been so caught up in other projects that I've forgotten some of the changes I've made. They don't make a ton of difference, but deployments were slightly smoother than I mentioned. I didn't include directory structure or any views, but I'm sure they can be derived—I wanted it simple. I also used Spectre CSS + overrides for the front so any inline HTML can be assumed to be using classes related to that for any styled elements. There is a couple elements hard-coded into the server itself for the home page. Definitely not an effort in best practices! But have at it, and happy to hear if you have any input if you're more versed in Go (probable): https://gist.github.com/robertfairley/f061df3a6a2fe15d429f824a5c38d089 https://gist.github.com/robertfairley/f061df3a6a2fe15d429f82... edit: Also—SSL is handled by Nginx. And god help us all if anybody uses this file as a model for any business web server
- bArray 7y ago
  If it works then it's not silly! Thanks for sharing :) If I understand it correctly, you build locally and then upload to the server? I have this setup for a few webservers that I have limited control over, so just FTP/POST documents to upload content. When I have proper control over the server, I much prefer to have the server build the documents. The benefit is that I can simply write a new blog or something from my mobile whilst in a meeting, commit and the server auto-generates the new content. I just need a web browser, GitLab, GitHub and BitBucket all support some form of basic editor for markdown. Interesting take anyway. My feeling is that I want to do more experimentation on my server and build more "rough and ready" web projects, with the knowledge they will probably fall over more easily and have security flaws. The service goign down is one thing, the entire server being compromised is quite another. I think this points towards introducing some container system. I'll have to learn me some docker.
  - 52-6F-62 7y ago
    Yeah you pretty much summed up what I was doing. Fun to learn a new language, make something work to some low expectation I had. And it did/does. I'll probably try and rewrite in another language again soon. The former version that looked the same was done in Django—but I wanted less overhead. But yeah, I build locally via that script, but upload all relevant files via `deploy.sh`. For "rough and ready" projects, I've enjoyed playing with ipkn/crow—I wish it was still maintained. https://github.com/ipkn/crow https://github.com/ipkn/crow And yeah, your take has been similar to mine. I'm okay with it goes down. But the Django system I ran before I was more susceptible to someone breaking in. This one is pretty well untouchable—which is reassuring. I can safely as rarely look at or update it as necessary without worry—and I appreciate the opportunity to be humbled if I'm wrong! Also yeah—my current setup would also be made smoother by docker, I was way too lazy to dig into it as I don't use it often.

by bArray 7y ago

52-6F-62 7y ago

Like I said, my site isn’t and likely won’t be in high demand. But to your point: yes. Performance would be bad at high demand. (Also to note in case of confusion, when I said generated I meant rendered from MD to HTML) Each time I start the server, it gathers the posts by searching the post tree which is a directory ordered something like Posts > YYYY > MM So that it can display the list of available posts and generate the urls for each of them. For the changes I just manually pull them and restart the server. This wasn’t done as a proper engineering project. Just to learn some basic mechanics of the language. If you’re expecting a proper scalable, professional project you’ll be dismayed. That said I’ll happily see if I can get it cleaned up and add a link.

52-6F-62 7y ago

Haha oh man, I was speaking to you from a few versions ago and didn't realize it. I've been so caught up in other projects that I've forgotten some of the changes I've made. They don't make a ton of difference, but deployments were slightly smoother than I mentioned. I didn't include directory structure or any views, but I'm sure they can be derived—I wanted it simple. I also used Spectre CSS + overrides for the front so any inline HTML can be assumed to be using classes related to that for any styled elements. There is a couple elements hard-coded into the server itself for the home page. Definitely not an effort in best practices! But have at it, and happy to hear if you have any input if you're more versed in Go (probable): https://gist.github.com/robertfairley/f061df3a6a2fe15d429f824a5c38d089 https://gist.github.com/robertfairley/f061df3a6a2fe15d429f82... edit: Also—SSL is handled by Nginx. And god help us all if anybody uses this file as a model for any business web server

bArray 7y ago
If it works then it's not silly! Thanks for sharing :) If I understand it correctly, you build locally and then upload to the server? I have this setup for a few webservers that I have limited control over, so just FTP/POST documents to upload content. When I have proper control over the server, I much prefer to have the server build the documents. The benefit is that I can simply write a new blog or something from my mobile whilst in a meeting, commit and the server auto-generates the new content. I just need a web browser, GitLab, GitHub and BitBucket all support some form of basic editor for markdown. Interesting take anyway. My feeling is that I want to do more experimentation on my server and build more "rough and ready" web projects, with the knowledge they will probably fall over more easily and have security flaws. The service goign down is one thing, the entire server being compromised is quite another. I think this points towards introducing some container system. I'll have to learn me some docker.
- 52-6F-62 7y ago
  Yeah you pretty much summed up what I was doing. Fun to learn a new language, make something work to some low expectation I had. And it did/does. I'll probably try and rewrite in another language again soon. The former version that looked the same was done in Django—but I wanted less overhead. But yeah, I build locally via that script, but upload all relevant files via `deploy.sh`. For "rough and ready" projects, I've enjoyed playing with ipkn/crow—I wish it was still maintained. https://github.com/ipkn/crow https://github.com/ipkn/crow And yeah, your take has been similar to mine. I'm okay with it goes down. But the Django system I ran before I was more susceptible to someone breaking in. This one is pretty well untouchable—which is reassuring. I can safely as rarely look at or update it as necessary without worry—and I appreciate the opportunity to be humbled if I'm wrong! Also yeah—my current setup would also be made smoother by docker, I was way too lazy to dig into it as I don't use it often.